GVAL-SIS-EN-Arquitectura Tecnica v1 0

TECHNICAL PROCESS DESIGN
DOCUMENT
ARQUITECTURA TECNICA
Identificación de Documento
DETALLE
Proyecto: Frente de Sistema Escenario de Negocios

Programa de Transformación Empresarial ARQUITECTURA DE TECNICA
Líder de Sistemas – VALOREM Líder Frente Técnico - SAP Nombre del Proceso – VALOREM
Santiago Silva Eduardo Contreras ARQUITECTURA
Historia Documento
AUTORES Y PARTICIPANTES
Rol Nombre
Líder Frente Técnico – SAP Eduardo Contreras
HISTORIAL REVISIÓN
Fecha Versión Documento Descripción Revisión Documento Autor
6 Febrero 2014 1.0 Eduardo Contreras
REVISIÓN Y APROBACIÓN
Nombre Cargo Fecha Aprobado
1
INDICE
IDENTIFICACIÓN DE DOCUMENTO ................................................................................................................................ 1

HISTORIA DOCUMENTO .................................................................................................................................................. 1
INDICE ....................................................................................................................................................................... 2
TABLA DE ILUSTRACIONES ........................................................................................................................................... 5
1. INTRODUCCION .......................................................................................................................................... 6
1.1. OBJETIVO ..................................................................................................................................................... 6
1.2. ENFOQUE Y ALCANCE ............................................................................................................................... 6
1.3. SUPUESTOS ................................................................................................................................................ 6
2. ARQUITECTURA LÓGICA .......................................................................................................................... 7
2.1. ESQUEMA GENERAL ................................................................................................................................. 7
2.1.1. OBJETIVO ..................................................................................................................................................... 7
2.1.2. SUPUESTOS ................................................................................................................................................ 7
2.1.3. DESCRIPCIÓN ............................................................................................................................................. 7
2.2. FASES & OLAS ............................................................................................................................................ 8
2.2.1. OBJETIVO ..................................................................................................................................................... 8
2.2.2. SUPUESTOS ................................................................................................................................................ 8
2.2.3. CONCEPTO .................................................................................................................................................. 8
2.2.3.1. FASE: ............................................................................................................................................................ 9
2.2.3.2. OLAS: ............................................................................................................................................................ 9
2.2.3.3. BIGBANG: ................................................................................................................................................... 10
2.2.4. ESTRATEGIA.............................................................................................................................................. 10
2.3. FASE I ......................................................................................................................................................... 10
2.3.1. OBJETIVO ................................................................................................................................................... 10
2.3.2. SUPUESTOS .............................................................................................................................................. 10
2.3.3. COMPONENTES ........................................................................................................................................ 10
2.4. FASES POSTERIORES ............................................................................................................................. 11
2.5.1. OBJETIVO ................................................................................................................................................... 11
2.5.2. SUPUESTOS .............................................................................................................................................. 12
2.5.3. COMPONENTES ........................................................................................................................................ 12
2.5. MANDANTE ................................................................................................................................................ 13
2.5.1. OBJETIVO ................................................................................................................................................... 13
2.5.2. SUPUESTOS .............................................................................................................................................. 14
2.5.3. MANDANTE ................................................................................................................................................ 14
2.5.3.1. SISTEMA ÚNICO-MANDANTE: ................................................................................................................. 14
2.5.3.2. SISTEMA MULTI-MANDANTE: .................................................................................................................. 14
2.5.3.3. MULTI-SISTEMA:........................................................................................................................................ 15
2.5.4. ESTRATEGIA:............................................................................................................................................. 15
2.5.4.1. NUMERO DE MANDANTES: ...................................................................................................................... 15
2.5.4.2. PROS & CONTRAS .................................................................................................................................... 15
2.5.4.3. GESTIÓN DEL CAMBIO ............................................................................................................................ 16
2.5.3.1. OBJETIVO................................................................................................................................................... 17
2.5.3.2. SUPUESTOS .............................................................................................................................................. 17
2.5.3.3. TRANSPORTES ......................................................................................................................................... 17
2.5.3.3.1. POLÍTICAS .................................................................................................................................................. 18
2.5.3.4. NOMENCLATURA DE TRANSPORTES .................................................................................................... 19
2.5.3.5. ADMINISTRACIÓN DE TRANSPORTES ................................................................................................... 19
2.5.4.4. MANDANTES ESTÁNDAR ......................................................................................................................... 20
MANDANTE 000 (REFERENCIA - SAPR): ...................................................................................................................... 21
MANDANTE 001 (EJEMPLO - SAPS): ............................................................................................................................. 21
MANDANTE 066 (EARLYWATCH - SAPE): .................................................................................................................... 21
2.5.4.5. MANDANTES NO-ESTÁNDAR .................................................................................................................. 21
2
24 Marzo 2014
MANDANTE 100 (CUSTOMIZING - VED): ...................................................................................................................... 21
MANDANTE 110 (PRUEBAS UNITARIAS - VED): .......................................................................................................... 21
MANDANTE 120 (SANDBOX - VED): .............................................................................................................................. 21
MANDANTE 130 (MIGRACIÓN DE DATOS - VED): ....................................................................................................... 22
MANDANTE 300 (PRUEBAS INTEGRALES - VEQ): ...................................................................................................... 22
MANDANTE 400 (ENTRENAMIENTO - VEQ): ................................................................................................................ 22
MANDANTE 300 (PRODUCCIÓN - VEP): ....................................................................................................................... 22
2.5.4.6. CONFIGURACIÓN DE LOS MANDANTES ................................................................................................ 23
2.5.4.6.1. CONFIGURACIÓN MANDANTES AMBIENTE DESARROLLO ................................................................. 23
2.5.4.6.2. CONFIGURACIÓN MANDANTES AMBIENTE CALIDAD .......................................................................... 23
2.5.4.6.3. CONFIGURACIÓN MANDANTES AMBIENTE PRODUCCIÓN ................................................................. 23
2.5.4.7. GOBERNABILIDAD ERP ............................................................................................................................ 24
2.5.4.7.1. AMBIENTE DESARROLLO ........................................................................................................................ 24
2.5.4.7.2. AMBIENTE CALIDAD ................................................................................................................................. 24
2.5.4.7.3. AMBIENTE PRODUCCIÓN ........................................................................................................................ 24
2.5.4.8. GOBERNABILIDAD BO .............................................................................................................................. 25
2.5.4.9. GOBERNABILIDAD JAVA STACK ............................................................................................................. 25
2.6. SOLUCIONES DE INDUSTRIA .................................................................................................................. 26
2.6.1. OBJETIVO ................................................................................................................................................... 26
2.6.2. AGRUPACIÓN POR SOLUCIÓN DE INDUSTRIA ..................................................................................... 26
2.7. SERVICIOS ................................................................................................................................................. 28
2.7.1. RESPALDO Y RECUPERACIÓN............................................................................................................... 28
2.7.1.1. OBJETIVO ................................................................................................................................................... 28
2.7.1.2. SUPUESTOS .............................................................................................................................................. 28
2.7.1.3. ESTRATEGIA DE BACKUP ........................................................................................................................ 28
2.7.2. ALTA DISPONIBILIDAD Y RECUPERACIÓN ANTE DESASTRES ........................................................ 29
2.7.2.1. OBJETIVO ................................................................................................................................................... 29
2.7.2.2. SUPUESTOS .............................................................................................................................................. 29
2.7.2.3. REQUERIMIENTOS.................................................................................................................................... 29
2.7.2.4. ALTA DISPONIBILIDAD ............................................................................................................................. 30
2.7.2.4.1. REQUERIMIENTOS: .................................................................................................................................. 31
2.7.2.5. DISASTER RECOVERY ............................................................................................................................. 31
2.7.2.5.1. REQUERIMIENTOS: .................................................................................................................................. 32
2.7.3. SYSTEM LANDSCAPE DIRECTORY ........................................................................................................ 32
2.7.3.1. OBJETIVO ................................................................................................................................................... 32
2.7.3.2. CONCEPTO ................................................................................................................................................ 32
2.7.4. IMPRESIÓN ................................................................................................................................................ 33
2.7.4.1. OBJETIVO ................................................................................................................................................... 33
2.7.4.2. SUPUESTOS .............................................................................................................................................. 33
2.7.4.3. ESTRATEGIA.............................................................................................................................................. 33
2.7.4.4. ESTADÍSTICAS DE IMPRESORAS ........................................................................................................... 34
2.7.5. SEGURIDAD ............................................................................................................................................... 35
2.7.5.1. OBJETIVO ................................................................................................................................................... 36
2.7.5.2. POLÍTICAS DE SEGURIDAD ..................................................................................................................... 36
2.7.5.2.1. SUPUESTOS .............................................................................................................................................. 36
2.7.5.2.2. NIVEL DE SEGURIDAD BASE ................................................................................................................... 36
2.7.5.2.2.1. CUENTAS DE USUARIO POR DEFECTO ................................................................................................ 36
2.7.5.2.2.1.1. SEGURIDAD USUARIO SAP* .................................................................................................................... 36
2.7.5.2.2.1.2. SEGURIDAD USUARIO TMSADM ............................................................................................................. 36
2.7.5.2.2.1.3. SEGURIDAD USUARIOS EARLYWATCH Y SAPCPIC............................................................................. 37
2.7.5.2.2.2. POLÍTICAS DE CLAVE ............................................................................................................................... 37
2.7.5.2.2.3. BORRAR CLIENTES NO UTILIZADOS ..................................................................................................... 37
2.7.5.2.3. GESTIÓN DE USUARIOS Y AUTORIZACIONES ..................................................................................... 38
2.7.5.2.3.1. OBJETIVO ................................................................................................................................................... 38
2.7.5.2.3.2. USUARIOS .................................................................................................................................................. 38
2.7.5.2.3.3. AUTORIZACIONES .................................................................................................................................... 38
3
24 Marzo 2014
2.7.5.2.3.4. ESTRATEGIA.............................................................................................................................................. 39
2.7.5.3. AUTENTICACIÓN....................................................................................................................................... 40
2.7.5.3.1. OBJETIVO................................................................................................................................................... 40
2.7.5.3.2. SUPUESTOS .............................................................................................................................................. 40
2.7.5.3.3. ESTRATEGIA.............................................................................................................................................. 40
2.7.5.3.4. SINGLE SIGN ON ....................................................................................................................................... 40
2.7.5.3.4.1. OBJETIVO ................................................................................................................................................... 40
2.7.5.3.4.2. CONCEPTO ................................................................................................................................................ 40
2.7.5.3.4.3. ESTRATEGIA.............................................................................................................................................. 41
2.7.5.3.4.4. REQUERIMIENTOS.................................................................................................................................... 41
2.7.5.3.4.5. CONSIDERACIONES ................................................................................................................................. 42
2.7.6. ARCHIVING ................................................................................................................................................ 42
2.7.6.1. OBJETIVO ................................................................................................................................................... 42
2.7.6.2. CONCEPTO ................................................................................................................................................ 42
2.7.6.3. ESTRATEGIA.............................................................................................................................................. 43
3. ARQUITECTURA FÍSICA ........................................................................................................................... 45
3.1. SISTEMAS OPERATIVOS Y VIRTUALIZACIÓN ...................................................................................... 45
3.1.1. OBJETIVO ................................................................................................................................................... 45
3.1.2. SUPUESTOS .............................................................................................................................................. 45
3.1.3. ESTRATEGIA.............................................................................................................................................. 45
3.2. SAP GUI ...................................................................................................................................................... 46
3.2.1. OBJETIVO ................................................................................................................................................... 46
3.2.2. SUPUESTOS .............................................................................................................................................. 46
3.2.3. PLATAFORMAS SOPORTADAS SAP GUI ................................................................................................ 46
3.2.4. ESTRATEGIA DE DISTRIBUCIÓN SAP GUI CON SAP GUI INSTALLATION SERVER ......................... 46
3.2.5. REQUERIMIENTOS “SAP GUI INSTALLATION SERVER” ....................................................................... 47
3.3. SIZING ........................................................................................................................................................ 48
3.3.1. OBJETIVO ................................................................................................................................................... 48
3.3.2. SUPUESTOS .............................................................................................................................................. 48
3.3.3. CONCEPTOS.............................................................................................................................................. 48
3.3.3.1. SIZING ........................................................................................................................................................ 48
3.3.3.2. SAPS ........................................................................................................................................................... 48
3.3.3.3. HERRAMIENTAS DE SIZING..................................................................................................................... 49
3.3.4. ESTRATEGIA.............................................................................................................................................. 50
3.3.4.1. CUANDO SE DEBE HACER UN SIZING? ................................................................................................. 50
3.3.4.2. FACTORES QUE INFLUYEN EL SIZING .................................................................................................. 51
3.3.4.3. METODOLOGÍA.......................................................................................................................................... 52
3.3.4.3.1. ROLES Y RESPONSABILIDADES ............................................................................................................. 52
3.3.4.4. CUESTIONARIOS DE SIZING ................................................................................................................... 52
3.3.4.4.1. USUARIOS .................................................................................................................................................. 52
3.3.4.4.2. PROCESOS (ELEMENTOS DE SIZING) ................................................................................................... 53
3.3.4.5. RESULTADOS ............................................................................................................................................ 54
3.3.4.6. TABLA DE SIZING POR ELEMENTO Y EMPRESA .................................................................................. 57
3.3.4.7. LECCIONES APRENDIDAS ....................................................................................................................... 59
4. BITÁCORA DE AJUSTES .......................................................................................................................... 60
4
24 Marzo 2014
Tabla de Ilustraciones
Ilustración 1 - Esquema General ........................................................................................................................................ 7
Ilustración 2 - Fases, Olas, & BigBang ............................................................................................................................... 9
Ilustración 3 - Fases ............................................................................................................................................................ 9
Ilustración 4 - Fase I ......................................................................................................................................................... 11
Ilustración 5 – Fases Posteriores a la Fase I .................................................................................................................... 12
Ilustración 6 - Mandante ................................................................................................................................................... 14
Ilustración 7 - Estrategias de salida en vivo consideradas ............................................................................................... 15
Ilustración 8 - Gestión del Cambio .................................................................................................................................... 17
Ilustración 9 - Ambientes .................................................................................................................................................. 18
Ilustración 10 - Enhanced Change and Transport Management .................................................................................... 20
Ilustración 11 - Estrategia de Mandantes ......................................................................................................................... 24
Ilustración 12 - Manejo de Cambios en BO ...................................................................................................................... 25
Ilustración 13 - Manejo de Cambios en SAP Java ........................................................................................................... 26
Ilustración 14 - Línea de Transportes PO ......................................................................................................................... 26
Ilustración 15 - Soluciones industriales por empresas ..................................................................................................... 27
Ilustración 16 - Evolución de las soluciones en SAP ........................................................................................................ 27
Ilustración 17 - Causas de Desastres ............................................................................................................................... 29
Ilustración 18 - Alta Disponibilidad (HA) ........................................................................................................................... 30
Ilustración 19 - Disaster Recovery .................................................................................................................................... 32
Ilustración 20 - Arquitectura propuesta SLD ..................................................................................................................... 33
Ilustración 21 - Impresoras Locales y Remotas................................................................................................................ 34
Ilustración 22 - Agenda Diseño de Seguridad .................................................................................................................. 39
Ilustración 23 - SSO con Kerberos ................................................................................................................................... 41
Ilustración 24 - Archiving................................................................................................................................................... 43
Ilustración 25 - Estrategia de Archiving ............................................................................................................................ 44
Ilustración 26 - Distribución de Actualización de SAP GUI .............................................................................................. 47
Ilustración 27 - Herramientas de Sizing ............................................................................................................................ 49
Ilustración 28 - Sizing Recomendados por Proyecto ........................................................................................................ 50
Ilustración 29 - Sizing Recomendado por Cambios.......................................................................................................... 50
Ilustración 30 - Factores que Influencian el Sizing ........................................................................................................... 51
Ilustración 31 - Dimensionamiento por Usuarios y/o por Rendimiento ............................................................................ 51
Ilustración 32 - Agenda Sizing Business Blueprint ........................................................................................................... 52
Ilustración 33 - Elementos de Sizing ................................................................................................................................ 53
Ilustración 34 - Impacto de las compañias sobre los Recursos ....................................................................................... 55
Ilustración 35 - Ancho de banda por compañia ................................................................................................................ 55
Ilustración 36 - Recursos x Elementos de Sizing ............................................................................................................. 56
5
24 Marzo 2014
1. INTRODUCCION
1.1. Objetivo
Este documento tiene como propósito proveer a alto nivel las definiciones y una descripción sobre la arquitectura
técnica requerida para la implementación de la soluciones de sistemas del Grupo Valorem, donde se han capturado
las decisiones arquitectónicas para la arquitectura propuesta, basado en las mejores prácticas y experiencia de los
consultores SAP.
1.2. Enfoque y alcance
El ecosistema de la arquitectura tecnológica está compuesto por las diferentes aplicaciones que interactúan con el
sistema SAP ECC.
1.3. Supuestos
▪ SAP ECC será el aplicativo donde se centralizara el Backoffice

▪ Es un documento vivo que debe ser actualizada a medida que pasa el tiempo, para adaptarse a la evolución
de las tecnologías, servicios, y directrices del Grupo Valorem
▪ La información contenida en este documento describe las definiciones de la arquitectura acordadas denle el
primer trimestre del año 2014
6
24 Marzo 2014
2. ARQUITECTURA LÓGICA
Es el modelo que describe los componentes de aplicaciones y servicios.
2.1. Esquema general
2.1.1.Objetivo
Representación a alto nivel de las áreas que son cubiertas por el proyecto, para dimensionar el reto que
representa la integración de la arquitectura técnica en términos de dominios, impresión, y redes de las
diferentes compañías que hacen parte del Grupo Valorem.
2.1.2.Supuestos
▪ Los componentes fueron nombrados de forma general para poder ser comprendidos por cualquier usuario
▪ Un componente lógico puede corresponder a más de un componente SAP, por ejemplo: REPORTES está
cubierto por el “SAP BO BI PLATFORM 4.1” y por el “SAP BW7.4 + BPC”
▪ ERP representa el Backofice donde se alojarán los procesos de negocios homologados (Backoffice) para
las diferentes empresas del Grupo Valorem
2.1.3.Descripción
La “Ilustración 1 - Esquema General” representa una vista lógica del tipo de componentes que hacen parte del
“Programa de Transformación Empresaria” del Grupo Valorem.
Ilustración 1 - Esquema General
En esta imagen se representan las capas de presentación, aplicación, integración. En la capa de presentación
estarán los usuarios de cada compañía accediendo por medio de los aplicativos front (SAP GUI, Web browser,
Adobe Reader) a los aplicativos SAP. En la capa Corporativa se encuentran los componentes lógicos, estos
representan:
▪ ERP: Es el Sistema donde se centralizaran los procesos de negocio conocidos como Backoffice.
7
24 Marzo 2014
▪ Reportes: Son los sistemas que proveerán los diferentes reportes basados en los datos del ERP
(Backoffice)
▪ Solución de Industria: Son componentes adicionales de software especializados en un tipo específico de
proceso de negocios, por ejemplo la solución de industria de “Media” que cubre procesos de negocio en
temas relacionados a TV, Cine, Revistas, y Periódicos.
▪ Migración de Datos: Son los aplicativos que migraran los datos desde un sistema legado al nuevo sistema.
▪ Integración: Son los aplicativos que integran a través de interfaces los datos entre sistemas. Este sistema
además de transferir información, puede transformar datos y manejar procesos entre sistemas.
En la capa de Compañías se encuentran las diferentes empresas que forman parte del Grupo Empresarial
Valorem, aquí pueden existir diferentes retos de integración de las compañías en una red, como:
▪ Dominios con diferentes niveles de seguridad, nomenclaturas (ej. usuarios, computadoras)
▪ Redes desde donde se deben consumir servicios y extraer datos (ej. dos empresas del grupo pueden
poseer los mismos juegos de IP, lo cual generaría un conflicto)
▪ Impresoras con diferentes niveles de requerimiento de impresión (ej. algunas solo deben ser accedidas
para tareas específicas con formatos especiales)
▪ Sistemas en diferentes segmentos de red (ej. Algún sistema pueden localizarse en proveedores que
hacen parte de otras redes y debemos poder acceder a ellos para extraer dato)
2.2. Fases & Olas
2.2.1.Objetivo
Describir las estrategias que se están estudiando para la implementación y salida en vivo en cuanto a etapas.
2.2.2.Supuestos
▪ Existen alrededor de 40 empresas que necesitan salir en vivo para el 31 de Diciembre

▪ Algunas de las compañías solo funcionan como entidades legales.
▪ Las interfaces de algunas compañías representan un nivel más alto de complejidad que otras
▪ Existen empresas en diferentes áreas de negocio
▪ Las definiciones de Fases, Olas, y BigBang mencionadas en este documentó tiene estrecha relación
al concepto que se definió por el proyecto.
▪ Existen entre 5 a 6 meses para la salida en vivo de las olas
2.2.3. Concepto
Los conceptos de Faces, Olas, y BigBang pueden ser entendidos de diferente forma dependiendo del contexto
y del proyecto, por esta razón definiremos en relación a este proyecto cada uno de estos conceptos, siguiendo
el apoyo visual de la “Ilustración 2 - Fases, Olas, & BigBang” que representa dos estrategias de salida en vivo
(Olas & BigBang) por Fase.
8
24 Marzo 2014
Ilustración 2 - Fases, Olas, & BigBang
2.2.3.1. Fase:
Son las etapas en las que irán saliendo nuevas funcionalidades y/o aplicativos como se
muestra en la “Ilustración 3 – Fases”, cada fase comprende el tiempo desde análisis/diseño
hasta el momento de la salida en vivo.
Ilustración 3 - Fases
2.2.3.2. Olas:
9
24 Marzo 2014
Representa una estrategia de salida en vivo, que sucede dentro de una Fase, en la cual salen
en vivo en diferentes momentos, diferentes grupos de compañías dependiendo de un estudio
funcional y técnico, en relación a su tamaño, procesos, interfaces y demás índices de decisión,
permitiendo tener salidas en vivo controladas que habilitan más oportunidades de
aprendizaje. Actualmente se ha definido la estrategia de Olas para la fase I del programa, para
mejorar el proceso de cada salida, disminuyendo el riesgo en cada ola.
2.2.3.3. BigBang:
Representa una estrategia de salida en vivo, en la cual, independiente de los análisis
realizados, se decide que todas las empresas deberán salir en el mismo momentos de tiempo,
definida como única salida en vivo de la fase I del programa. Es una estrategia riesgosa ya
que tiene menos oportunidades de aprendizaje, sin embargo, representa un solo esfuerzo
unificado donde se simplifican muchas tareas.
2.2.4. Estrategia
Actualmente la estrategia está definida por olas, pero esta definición puede cambiar según los hallazgos
encontrados durante la fase de diseño. Posteriormente se hará un conceso dentro del proyecto para confirmar
o no la estrategia de Olas. Dentro de la estrategia de olas se han considerado diferentes modelos, como:
▪ De Pequeñas a Grandes: Salir primero con las empresas más pequeñas y en olas posteriores ir
saliendo con olas más grandes, pero esto deja a las empresas con más interfaces de última y se
puede tornar en un cuello de botella.
▪ De Grandes a Pequeñas: Salir primero con las empresas más grandes y/o complejas en cuanto a
interfaces y en olas posteriores ir saliendo con empresas más pequeñas y/o de menos complejidad en
cuanto a interfaces, esta estrategia permite tener más tiempo para resolver inconvenientes.
▪ Mixta: Hacer la primera Ola de 3 a 6 empresas pequeñas y después seguir con la estrategia de
Grandes a Pequeñas en las siguientes olas.
2.3. Fase I
2.3.1.Objetivo
El objetivo de este punto, es representar los componentes y arquitectura de software recomendada para la
Fase I del proyecto “Programa de Transformación Empresarial”
2.3.2.Supuestos
▪ Se va a implementar Identity Management y Federación de Dominios

▪ Se utilizara Process Orchestration 7.4 en vez de PI 7.3
▪ No se representa el número de servidores, por lo contrario solo los componentes lógicos
▪ La Fase I debe concluir por tarde el 31 de Diciembre del 2014
▪ La instalación de algunos componentes de la Fase I pueden ser requeridos para realización, pero
algunos no hacen parte de la instalación inicial soportada por el SOW del Blueprint
2.3.3.Componentes
En la imagen “Ilustración 4 - Fase I” se observan los diferentes grupos lógicos de componentes de software
según la arquitectura de SAP definida para la Fase I. En el área de “Aplicaciones de Negocio” localizamos el
“SAP ERP (Backoffice)” que está conformada por el SAP Business Suite. Aquí se encuentran los diferentes
ambientes de ERP “SAP ECC 6.0 – EhP7” y un ambiente sandbox solo para pruebas “SAP ECC 6.0 – EhP 6
IDES”. En el área de “Inteligencia de Negocios” encontramos el “Business Intelligence”, que se encarga de
presentar reportes, y el “SAP Business Warehouse”, que se encarga de la planeación y consolidación. En el
10
24 Marzo 2014
área de “Plataforma de Integración”, encontramos el “Process Orchestration 7.4 (PO)”, el cual se encarga de
integrar diferentes aplicativos, archivos, e interfaces con el ERP. En el área de “Plataforma Netweaver”,
encontramos el “SAP NetWeaver Developer Infraestructure (NWDI)”, que se encarga de controlar los
desarrollos del PO. En el área de “Educación”, encontramos al “SAP Work Performance Builder”, que es el
aplicativo que se encarga de generar material de entrenamiento para los usuarios finales. En el área de
“Infraestructura” encontramos al “Sybase Power Designer”, que se encarga de documentar los flujos de
procesos, y el “SAP Solution Manager”, que es el aplicativo que se encarga del manejo de todo el flujo de vida
de los diferentes aplicativos SAP, entre estas tareas puede llevar el monitoreo, el control de cambios, la
documentación del proyecto entre otro.
Ilustración 4 - Fase I
En la siguiente tabla aparecen las versiones de los componentes que serán requeridos por ambiente. Esta
imagen no representa el número de servidores que se requerirá para la Fase I, sí no el número de
componentes, y versiones por ambiente.
Componente Desarrollo Calidad Producción

SAP Solution Manager ۷ ۷
SAP ECC 6.0 - Core (EhP7) ۷ ۷ ۷
SAP ECC 6.0 – IDES ۷
SAP NW PO (JAVA) ۷ ۷ ۷
SAP BW (+BPC) ۷ ۷ ۷
SAP Power Designer ۷
SAP BO/BI Business Intelligence ۷ ۷ ۷
SAP WPB - Work Performance Builder ۷
SAP NWDI ۷
2.4. Fases Posteriores
2.5.1.Objetivo
11
24 Marzo 2014
Representar los componentes y arquitectura de software definidos para las Fases Posteriores a la Fase I del
proyecto “Programa de Transformación Empresarial”
2.5.2.Supuestos
▪ Las Fases posteriores a la Fase I cubrirán nuevas funcionalidades para el BackOffice y nuevos
aplicativos SAP.
▪ Las Fases posteriores se iniciaran a partir del 1 de Enero del 2015
▪ La imagen muestra la vista lógica de las instancias, no del número de servidores, que hacen parte de
la arquitectura
2.5.3.Componentes
Aparte de los componentes ya descritos en el punto “2.3.3 Componentes” en la imagen “Ilustración 5 – Fases
Posteriores a la Fase I” aparecen nuevos aplicativos, los cuales han sido demarcados en color rojo y blanco,
algunos de ellos aplican para todas las empresas y otros no, en algunos casos se tendrá que determinar
cuándo serán implementados según las necesidades corporativas o individuales de las empresas a las que les
aplique.
Ilustración 5 – Fases Posteriores a la Fase I
En el área “Capa Web”, encontramos el “SAP Enterprise Portal”, que se encarga de presentar algunas
interfaces web de los diferentes aplicativos que componen la arquitectura. En el área de “Aplicación de
Negocios” encontramos nuevos aplicativos como, “SAP Environment, Health, and Safety Mng”, que determina
la el nivel de contaminación ambiental que producen cada uno de los equipos que utiliza una empresa, esto
permite sacar estadística que identifican el cumplimiento, normatividad y responsabilidad corporativa en
cuanto a contaminación ambiental; el “SAP EECM Open Text”, que permiten la gestión de forma sistemática
12
24 Marzo 2014
del contenido, para que sea fácil de encontrar, gobernar, usar y compartir; el “SAP ERP (Vertical)”, que se
encarga de las soluciones de negocio más especializadas en un área como es Media; el “SAP CRM”, el cual
se encarga del manejo de las relaciones con los clientes; el “SAP Contract Lifecycle Mng”, que se encarga del
ciclo de vida de los contratos. En el área de “Movilidad” existen cinco aplicativos que se encargan del manejo
de los dispositivos móviles y sus aplicaciones, como “SAP Afaria”, “Sybase Unwired Platform”, “SAP Sybase
SQL Anywhere”, “Sybase Mobile Workflow”, y “SAP Mobile Platform”. En el área de “Plataforma NetWeaver”,
encontramos el “SAP NW Gateway”, que sirve para conectar dispositivos, entornos y plataformas de software
de SAP basadas en estándares de mercado; el “SAP Single Sign On”, que se encarga de la autenticación de
los usuario utilizando el LDAP del directorio activo como base de autenticación. En el área de “Inteligencia de
Negocios” se encuentran aplicativos que apoyan el estudio de datos y reportes como son el “SAP HANA” y el
“SAP Strategy Management”. En el área de “Infraestructura” encontramos el “SAP Identity Management”, que
se encarga de crear el repositorio de usuario y asignación de roles; el SAP Master Data Management”, que se
encarga de la homologación de datos entre los diferentes aplicativos, y el “SAP Data Services”, que se
encarga de migrar los datos entre los sistemas legados y los nuevos aplicativos SAP. En el área de
“Educación” se encuentra el “Knowledge Acceleration Software” que son contenidos pre-construidos que
apoyan el entrenamiento de usuario en módulos específicos.
En la siguiente tabla aparecen las versiones de los componentes que serán requeridos por ambiente en las
fases posteriores. Esta imagen no representa el número de servidores que se requerirá para siguientes fases,
sí no el número de componentes, y versiones por ambiente.
Componente Desarrollo Calidad Producción

SAP Netweaver Portal ۷ ۷ ۷
SAP Strategy Management ۷ ۷
SAP Notes Management ۷ ۷
SAP Governance, Risk and Compliance ۷ ۷
SAP CRM – SAP 360 Customer ۷ ۷ ۷
SAP Contract Lifecycle Managementt ۷ ۷ ۷
SAP AFARIA ۷ ۷
SYBASE Unwired Platform ۷ ۷
SAP Sybase SQL Anywhere ۷ ۷
Sybase Mobile Workflow ۷ ۷
SAP Mobile Platform ۷ ۷
SAP ERP – SAP for Media ۷ ۷ ۷
SAP NW Gateway ۷
SAP Single sign –on ۷ ۷
SAP Master Data Management ۷ ۷ ۷
SAP Identity Management ۷ ۷ ۷
Knwoledge Acceleration Software
SAP Data Services ۷ ۷
2.5. Mandante
2.5.1.Objetivo
Explicar las estrategias de mandante definidas y su gobernabilidad, además, de mostrar los pros y contras de
las diferentes estrategias que se estudiaron para la implementación.
13
24 Marzo 2014
2.5.2.Supuestos
▪ Existen alrededor de 40 empresas que se configurarán en un solo mandante

▪ Existen empresas en diferentes áreas de negocio que deben manejar los procesos de BackOffice de
forma homogénea
▪ Existen entre 5 a 6 meses para la salida en vivo de las olas
▪ Existirán tres ambientes por sistema (Desarrollo, Calidad, y Producción)
▪ El ambiente de calidad y producción tendrán el mismo número de sistema para facilitar las copias y
homogenización de sistemas
2.5.3. Mandante
Es una unidad lógica que agrupa a una o varias sociedades bajo un campo “MANDT” dentro de algunas
tablas, permitiendo de esta forma tener diferentes grupos lógicos de datos dentro de una misma tabla.
Los datos en un sistema SAP puede estar divididos en dos categorías: Data dependiente de mandante
(Client Specific) y Data independiente de mandante (Cross-client).
Dependiente de Mandante: Son las tablas que contienen el campo “MANDT” como las tablas de usuarios
maestros y data de aplicación, estos datos solo afectaran al mandante donde se encuentre.
Independiente de Mandante: Son las tablas que no contienen el campo “MANDT” y estos registros afectan a
todos los mandantes, como el Repositorio de Objetos.
En la “Ilustración 6 - Mandante" podemos observar que el “Customizing Independiente de Mandante” y el

“Repositorio R/3” afectan indiferentemente al “Mandante 000” y al “Mandante ###”, pero la información
contenida en las tablas del “Customizing”, “Data Transaccional”, y “Usuarios” solo afectara al mandante donde
hayan sido generadas.
Mandante 000 Mandante ###
Ilustración 6 - Mandante
2.5.3.1. Sistema Único-Mandante:

Es cuando en un mismo mandante se configuran todas las compañías que harán parte del
proyecto, compartiendo funcionalidades y permitiendo la homologación de ciertos procesos.
Esta estrategia es la recomendada para ambientes productivos ERP.
2.5.3.2. Sistema Multi-Mandante:

Es cuando se define que en un mismo sistema, existan diferentes mandantes por
sociedad(es)/empresa(s). Esta estrategia solo aplica para sistemas ERP ya que en otros
14
24 Marzo 2014
aplicativos SAP solo se maneja un mandante. Esta estrategia es normalmente recomendada
para ambientes no productivos.
2.5.3.3. Multi-Sistema:
FASE 1
Es cuando se define que para un aplicativo, como el ERP, se van a tener cada una de las IM
MODELO
sociedades/empresas en un BACKOFFICE – IFRS
sistema diferente.
RE
2014
En Fb Mz Ab My Jn Jl Ag Sp Oc Nv Dc
Release 1
2.5.4.Estrategia: Diseño procesos
2.5.4.1. Numero de Mandantes: OLA 1 Estabilización y soporte pr
OLA 2
Actualmente se ha definido una estrategia de un único mandante para el ERP, ya que
representa el mayor número de beneficios para el Grupo Valorem, los escenarios que se
OLA 3
estudiaron están representados en la “Ilustración 7- Estrategias de salida en vivo
consideradas”
OLA 4
Escenario 1 Escenario 2 Escenario 3 E1
BPC BPC BPC
BW BW BW
SAP SAP SAP SAP SAP SAP
 1 sistema  1 sistema  Varios sistemas

 1 mandante  Varios cada uno con
mandantes su mandante
Ilustración 7 - Estrategias de salida en vivo consideradas
2.5.4.2. Pros & Contras
15
24 Marzo 2014
En el siguiente cuadro se pueden observar los pros y contras de cada una de las estrategias descritas
anteriormente:
PROS CONTRAS
UNICO- ▪ Control Central ▪ Complejidad de implementación global

MANDANTE ▪ Fácil de administrar y mantener ▪ Riesgo Performance, tamaño
(RECOMENDADA) ▪ Costos administrativos ▪ Flexibilidad de la solución
▪ Homologación de Procesos Backoffice ▪ Propiedad compartida
▪ Reportes de sistema Integrados (Globales) ▪ Ventana de bajada de sistemas
▪ Simplificación en Implementación & Mantenimiento ▪ Incompatibilidad en requerimientos del
▪ Fluidez en el manejo de los datos negocio
▪ Data Maestra Armonizada y Consistente ▪ Costos de Infraestructura de redes
▪ Recomendado ambiente Productivos ERP
MULTIPLES ▪ Control Central ▪ No existe sinergia

MANDANTES ▪ Fácil de administrar y mantener ▪ Riesgo Performance, tamaño
▪ Costos administrativos ▪ Complejidad de implementación global
▪ Armonización y Estandarización (Datos ▪ No hay procesos globales
independiente Mandante) ▪ Flexibilidad de la solución
▪ Reportes e integración ▪ Propiedad compartida
▪ Flexibilidad en Configuración dependientes de ▪ Ventana de bajada de sistemas
Mandante ▪ Costos de Infraestructura de redes
▪ Recomendado ambientes No-Productivos ERP o
Productivos Multi-Tenant
MULTI-SISTEMA ▪ Libertad y flexibilidad de elección local ▪ No existe sinergia
▪ Mínimo esfuerzo en Re-ingeniería ▪ Costos administrativos
▪ Configuración Independiente ▪ Redundancia entre Sistemas e Interfaces
▪ Independencia de elección de infraestructura ▪ Redundancia en Implementación &
▪ Globalmente no existe un solo punto de falla Mantenimiento
▪ Ausencia de incompatibilidad en requerimientos del ▪ Complejidad en armonización de procesos
negocio globales o estándares
▪ Autonomía en Línea de negocios ▪ No existe identidad corporativa
▪ No hay visión de futuro
▪ Costo de Infraestructura de sistemas
2.5.4.3. Gestión del Cambio
En la “Ilustración 8 - Gestión del Cambio” se observa el control de cambios que debe tener la gestión de
los cambios de cada aplicativo, con un control especifico de requerimientos, pruebas, y aprobaciones que
16
24 Marzo 2014
debe seguirse antes de que los cambios lleguen al ambiente productivo, todos estos cambios deben estar
centralizados desde el CTS+.
SOLUTION MANAGER (CTS+)
 ERP
 BW
DESARROLLO CALIDAD PRODUCCION
 PO
 BO
 DS
(*)
Generar el
Pruebas integrales y Paso a
requerimiento de
proceso de aceptación
cambio y/o nueva producción
de la nueva versión.
funcionalidad.
Ilustración 8 - Gestión del Cambio
2.5.3.1. Objetivo
Proveer a alto nivel recomendaciones, definiciones, y una descripción sobre el control y manejo de los
cambios a través de transportes entre los diferentes ambientes.
2.5.3.2. Supuestos
▪ Existirá un comité de cambios

▪ El manejo de transportes será centralizado en el Solution Manager con CTS+
▪ Los líderes del corporativo son los responsables del manejo de cambio en sus áreas
▪ El mandante de Calidad y Producción tendrán el mismo número de sistema
2.5.3.3. Transportes
Los transportes son paquetes de software que contienen los cambios generados en los ambientes de
desarrollo de los aplicativos SAP. El manejo de los transportes será centralizado en el Solution Manager,
desde donde se distribuirán los cambios a los otros ambientes del mismo aplicativos. La herramienta
dentro de Solution Manager que se encargara de la administración y distribución de transportes mediante
“Enhanced Change and Transport System” (CTS+).
17
24 Marzo 2014
2.5.3.3.1. Políticas
▪ El Landscape del proyecto está conformado por 3 ambientes por sistema como ejemplo se
muestra la “Ilustración 9 – Ambientes” que ejemplifica los ambientes del ERP, y que sirve de base
para el manejo de los transportes en cada uno de los diferentes aplicativos SAP, donde :
▪ Ambiente de Desarrollo: Configurar las especificaciones del cliente y/o crear nueva
funcionalidad.
▪ Ambiente para el Aseguramiento de la Calidad: Probar la funcionalidad y verificar las
configuraciones.
▪ Ambiente de Productivo: Ejecución de actividades productivas y datos empresariales.
ERP
DESARROLLO CALIDAD PRODUCCION
Ilustración 9 - Ambientes
▪ En los ambientes de desarrollo es donde existe un mandante sobre el cual se deben realizar todas
las parametrizaciones y los desarrollos para el aplicativo. Sobre este mandantes se crean las
órdenes de transportes.
▪ La actualización de desarrollos y/o parametrización al ambiente de Calidad se debe realizar

únicamente con las órdenes de transportes generadas en el ambiente VED-100.
▪ Sólo los consultores, líderes funcionales y desarrolladores deben estar autorizados para solicitar el
transporte de órdenes sobre el ambiente de Calidad.
▪ Es requisito indispensable el diligenciamiento del formato “GVAL-SIS-FR-

TRANSORTES_V0.1.docx” para solicitar transportes al ambiente VEQ-300 y/o VEP-300.
GVAL-SIS-FR-TRANSORTES_V0.1.docx
Microsoft Word
Document
18
24 Marzo 2014
▪ La actualización del ambiente productivo se realiza únicamente con las órdenes de transportes
generadas en el ambiente de Desarrollo que anteriormente fueron probadas en el ambiente de
Calidad, y aprobadas por el personal autorizado.
2.5.3.4. Nomenclatura de Transportes
Para diferenciar las órdenes y poder asociar estas a un proyecto y al módulo al que pertenecen, se definió
una nomenclatura, basado en proyectos y en las compañías que actualmente componen el “Proyecto de
Transformación”, donde entre cada área estará el símbolo “_”:
DESCRIPCIÓN DE LA NOMENCLATURA
De existir un proyecto este será el código a poner, en su ausencia sí el transporte es corporativo llevara el
nombre de “GVAL”, de lo contrario llevara el nombre de la compañía a la que pertenece:
TRANSF: Programa de Transformación
GVAL: Grupo Valorem (Corporativo)
VAL: Valorem S.A
Proyectos, Compañías y CCO: Cine Colombia S.A
su SUP: Suppla S.A
Nombre DIT: Compañía de Distribución y Transporte S.A-Ditransa
RFC: Reforestadora de la costa
SUG: Sugranel
CRC: Caracol
CMN: Comunican S.A
ICC: ICCK NET S.A
TRN: Terranum S.A
CCL: Canal Clima
FAT: Fundación Amigos Teatro Julio Mario Santo Domingo
BC Basis / Notas
FI Finanzas
CO Control
Tema / Modulo TR Tesorería
MM Manejo de Material
SD Venta y Distribución
PP Planificación de la Producción
HCM Recursos Humanos
PO Process Orchestration
BO Business Objects
SM Solution Manager
Descripción Nombre del transporte, el cual debe ser claro y conciso.
Ejemplo: Un transporte para aplicar la nota “1382685” durante el proyecto “Programa de Transformación”
debe llevar un nombre con las siguientes características según la nomenclatura definida
“TRANSF_BC_<Descripción>”, por lo tanto el nombre del transporte puede ser “TRANSF_BC_Nota
1382685 - SE 729 Cust.Incor.Maint.”
2.5.3.5. Administración de Transportes
Todos los transportes estarán centralizados en Enhanced Change and Transport Management (CTS+),
como se muestra en la “Ilustración 10 - Enhanced Change and Transport Management”, la cual permite
transportar objetos Java y aplicaciones no relacionadas con SAP ABAP en su infraestructura de sistemas,
junto con los objetos ABAP. También puede administrar los sistemas no ABAP en un dominio de
transporte CTS en SAP NetWeaver Application Server ABAP.
19
24 Marzo 2014
Ilustración 10 - Enhanced Change and Transport Management
El CTS+ puede transportar:

▪ Objetos de tipo SAP NetWeaver Java:
▪ Java-based and J2EE-based objects:
▪ Software Component Archives (SCAs)
▪ Enterprise Application Archives (EARs)
▪ Software Deployment Archives (SDAs)
▪ Objetos de tipo SAP NetWeaver Portal (EP)

▪ Enterprise Portal Archives (EPAs)
▪ Enterprise Portal Applications (PARs)
▪ Knowledge Management objects (KM Content and KM Configurations)
▪ Objetos Non-ABAP de tipo SAP NetWeaver PI/PO (Process Integration/Process Orchestration):

▪ Integration Builder objects (TPZs)
El CTS+ puede transportar diferentes objetos junto con objetos ABAP en un único requerimiento de
transporte. Al ejecutar la importación en el Sistema de Gestión de Transporte (TMS), el sistema realiza el
paso de implementación adecuada de forma automática.
Las excepciones o limitaciones a esta información se documentan en la nota SAP 1003674.
2.5.4.4. Mandantes Estándar
En todos los sistemas ERP o NetWeaver basados en ABAP, existen 3 mandantes estándar, los
cuales se describen en el siguiente cuadro:
Cliente Nombre Descripción

000 SAPR Mandante de Referencia
001 SAPS Mandante de Ejemplo
066 SAPE Mandante EarlyWatch
20
24 Marzo 2014
Mandante 000 (Referencia - SAPR):
Este mandante está considerado por la industria como un modelo neutral en relación a tipo de
industria. Para crear un nuevo mandante, es recomendado utilizar como fuente de la copia al
mandante 000.
Mandante 001 (Ejemplo - SAPS):

Este mandante es idéntico al mandante 000 al momento de la instalación, pero normalmente como
en cualquier otro mandante de un sistema R/3, no contendrá nuevas entradas después de que
suceda alguna actualización, en el caso que esta información sea requerida en el mandante 001,
estos datos deberán ser transportados.
Mandante 066 (EarlyWatch - SAPE):

Este mandante provee un servicio de soporte proactivo para revisar el performance del sistema
bajo diferentes criterios de performance. La configuración de este servicio permite un reporte
donde se integran los resultados de los diferentes criterios de performance.
2.5.4.5. Mandantes No-estándar
Aparte de los mandantes estándar que vienen por defecto en el sistema se han definido para el
proyecto los siguientes mandantes:
Cliente Ambiente Nombre Descripción

100 VED Customizing Configuración y Desarrollo
110 VED Pruebas Unitarias Pruebas de Configuraciones y Desarrollos
120 VED Sandbox Cliente de Practica
130 VED Migración de Datos Pruebas de Migración de Datos
300 VEQ Calidad Pruebas de Integración
400 VEQ Entrenamiento Entrenamiento de usuarios
300 VEP Producción Producción
Mandante 100 (Customizing - VED):

Este mandante nace como copia del mandante 000, en este mandante se configuran/parametrizan
las definiciones y se desarrollan las aplicaciones que sirven como prototipo de la solución. Las
configuraciones, parametrizaciones, y desarrollos de este ambiente pueden ser transportados
usando copias de clientes o por transportes, después de su validación exitosa en los ambientes de
desarrollo y calidad, puede ser autorizada la distribución de estos cambios al ambiente productivo.
En este mandante no debe ser ingresarse data maestra o transaccional.
Mandante 110 (Pruebas Unitarias - VED):

Es el mandante de pruebas que se crea como copia del mandante 100, donde las copias de los
cambios de customizing son movidas para ejecutar el set de pruebas unitarias. Este mandante es
usado para hacer las pruebas de los cambios y los desarrollos que han sido generados. En este
mandante se debe ingresar data de la aplicación y sirve para verificar las configuraciones,
parametrizaciones, y desarrollos antes de mover los cambios a un ambiente de calidad.
Mandante 120 (Sandbox - VED):

Es un mandante de pruebas aisladas que se crea como copia del mandante de referencia 100. Se
utiliza para familiarizase con el sistema y para realizar transacciones, configuración y datos
maestros de prueba que no repercutirán en otros mandantes ya que los cambios aquí ejecutados
no son transportables. Los usuarios autorizados tendrán libre acceso a este mandante para
experimentación y pruebas de nueva configuración, antes de realizar la parametrización o
21
24 Marzo 2014
configuración definitiva en el mandante 100 (Customizing). Se puede usar la transacción SCC1
para pasar a través de transportes, los cambios en parametrización realizados en el mandantes
100.
Mandante 130 (Migración de Datos - VED):

Es un mandante de pruebas de datos que se crea como copia del mandante de referencia 100. A
este mandante solo entraran el equipo de la migración de datos y los administradores.
Mandante 300 (Pruebas Integrales - VEQ):

Es un mandante creado inicialmente por copia del mandante 000 y luego se le aplican los
transportes liberados en el mandante 100 que ya han sido probados exitosamente en el mandante
110 del ambiente de desarrollo, cada Líder Funcional debe entrega a la Gerencia de Proyecto su
lista de transportes con el orden correcto de aplicación, donde la Gerencia generara un listado
consolidado de las órdenes a aplicar, la cual será enviada a los Administradores BASIS para su
ejecución.
Este mandante es empleado para pruebas integrales de cada uno de los procesos de la empresa,
simulando el futuro ambiente productivo. Todos los procesos serán probados en conjunto en este
mandante, realizando pruebas del prototipo diseñado y probando de manera integrada:
Configuración inter-módulos, programas de carga de datos maestros definitivos, interfaces y
desarrollos ABAP.
Mandante 400 (Entrenamiento - VEQ):

Es un mandante creado inicialmente por copia del mandante 000 y luego se aplican los transportes
aprobados en el mandante 300 de Calidad. En este mandante se preparan los ejercicios de los
cursos, para capacitar a los usuarios finales en las diferentes transacciones, incluyendo interfaces
y desarrollos ABAP.
Los usuarios finales tendrán acceso restringido, según el perfil de autorizaciones que tengan
asignado.
Mandante 300 (Producción - VEP):
Es un mandante creado inicialmente por copia del mandante 000 y luego con la aplicación de los
transportes aprobados en el mandante 300 de Calidad, con posterior carga de datos maestros y
saldos.
Se utiliza este mandante para la operación en productivo del sistema ERP. En este mandante se
encuentran las transacciones y datos maestros reales de la operación en vivo del negocio.
Antes de que los usuarios finales comiencen su trabajo en el sistema, todos los datos maestros y
datos históricos deben haber sido cargados. Para esto, los miembros del equipo de proyecto
deben garantizar que los procedimientos de carga o transferencia de datos hayan sido probados
en cualquiera de los mencionados mandantes 110 VED y 300 VEQ.
La configuración y los desarrollos en este mandante no están disponibles para modificaciones, por
lo que este mandante deberá estar siempre cerrado para modificaciones. Cualquier solicitud de
apertura que se haga, deberá ser justificada con una Nota o un Mensaje SAP que apruebe dicha
apertura.
Ninguna configuración (parametrización) o desarrollo debe ser transportado a este mandante, sin
antes haber sido probado exhaustivamente en los otros sistemas de Desarrollo y Aseguramiento
de la Calidad. Solamente desarrollos y cambios en configuración que hayan sido aprobados,
deberían ser transportados a este mandante. Los cambios deben haber sido aprobados por el
equipo de aseguramiento de la calidad, después de haberse realizado pruebas en el mandante
300 VEQ de pruebas integrales.
22
24 Marzo 2014
Inicialmente los miembros del equipo tendrán acceso a la creación, modificación y visualización de
transacciones funcionales en la primera etapa de la salida en productivo. Posteriormente se
restringirán los accesos y sólo será posible la consulta en modo visualización únicamente.
Los usuarios finales tendrán los accesos de acuerdo al desempeño de sus labores, es decir, según
el perfil de autorizaciones asignado.
2.5.4.6. Configuración de los Mandantes
Cada mandante debe quedar definido según las siguientes recomendaciones descritas en las
tablas:
2.5.4.6.1. Configuración Mandantes Ambiente Desarrollo
Configuración Customizing (100) Unitarias (110) Sandbox (120) Datos (130)

Changes to Automatically recording No changes allowed No changes allowed No changes allowed
client-specific of changes
objects
Changes to Changes to Repository No changes to No changes to No changes to

cross-client and cross-client Repository and cross- Repository and cross- Repository and cross-
objects Customizing allowed client Customizing objs client Customizing objs client Customizing objs
Client copy Protection level 1: Protection level 1: Protection level 0: Protection level 1:
protection No overwriting No overwriting No restrictions No overwriting
Client role Customizing Test Test Test
2.5.4.6.2. Configuración Mandantes Ambiente Calidad
Configuración 300 (Calidad) 400(Training)

Changes to client-specific objects No changes allowed No changes allowed
Changes to cross-client objects No changes to Repository and No changes to Repository and

cross-client Customizing objs cross-client Customizing objs
Client copy protection Protection level 1: Protection level 0: No restrictions
No overwriting
Client role Test Training
2.5.4.6.3. Configuración Mandantes Ambiente Producción
Configuración 300 (Producción)
Changes to client-specific objects No changes allowed

No changes to Repository and cross-
Changes to cross-client objects
client Customizing objs
Protection level 1:
Client copy protection
No overwriting
Client role Production
23
24 Marzo 2014
2.5.4.7. Gobernabilidad ERP
La estrategia de mandantes según los diferentes ambientes ERP, está definida en la “Ilustración 11
- Estrategia de Mandantes” donde se puede observar que en cada ambiente existen un numero
variable de mandantes.
Ilustración 11 - Estrategia de Mandantes
Cada mandante tiene una configuración diferente de acuerdo a su función dentro del sistema.
El número del mandante puede ser cualquier número desde 002 hasta 999 (los números 000, 001
y 066 son reservados para SAP y no se pueden utilizar
Cada mandante tiene una configuración diferente de acuerdo a su función dentro del sistema:
2.5.4.7.1. Ambiente Desarrollo
▪ El role del sistema de desarrollo (VED), es donde se hacen las configuraciones

personalizadas (customizing) y los desarrollos necesarios para la solución.
▪ El mandante de Customizing es donde son hechos “todos” los desarrollos y customizing,
las configuraciones que van ser transportadas para el mandante de calidad y después de
producción no pueden ser hechas en otro mandantes, este mandante es también conocido
como “Gold Client” de Customizing;
▪ El mandante de Sandbox es donde se pueden hacer configuraciones de prueba que no
van ser transportadas para otros sistemas;
▪ El mandante de Pruebas Unitarias es utilizado para pruebas unitarias, sin necesariamente
tomar en cuenta las integraciones con otros procesos de negocio;
▪ El mandante de Data Migration va ser utilizado para pruebas de migración de datos
2.5.4.7.2. Ambiente Calidad
▪ La rol del sistema de QAS (Control de Calidad) es utilizado para pruebas integradas y
todas las pruebas necesarias de los desarrollos, customizing, antes de ser transportadas al
sistema de producción;
▪ No se pueden hacer cambios de configuraciones y desarrollos en el sistema de QAS.
▪ En el sistema de calidad se puede tener un cliente de pruebas y un cliente de
entrenamiento dependiendo de la necesidad de entrenamiento del cliente.
2.5.4.7.3. Ambiente Producción
▪ La role del sistema de PRD (Producción) es de ser el sistema que el cliente utilizará para
procesar sus operaciones como ventas, compras, contabilidad, finanzas, etc.
▪ No se pueden hacer cambios de configuraciones y desarrollos en el sistema de PRD;
24
24 Marzo 2014
▪ No es recomendable tener más que un cliente (mandante) en el sistema de producción
2.5.4.8. Gobernabilidad BO
La estrategia de transportes de BO es aplicable para las dos soluciones, Data Services y Business
Intelligence BO. La estrategia definida para mantener el control de las órdenes solo puede ser
implementada usando el CTS+. En la “Ilustración 12 - Manejo de Cambios en BO” aparecen 4
aplicativos, donde existen 3 “Business Objects” (BO), un “Life Cycle Management” (LCM), y el
“Solution Manager”. El primer BO es donde se desarrolla y sus cambios son promovidos a través
del LCM el cual carga al CTS+ localizado en el “Solution Manager” la orden de transporte, que
posteriormente puede ser desplegada en los diferentes BO siguiendo los controles de pruebas y
autorizaciones apropiados.
Ilustración 12 - Manejo de Cambios en BO
2.5.4.9. Gobernabilidad JAVA Stack
La estrategia definida para mantener el control de las órdenes en sistemas SAP basados en Java
Stack aplica para “Process Orchestration” (PO), “Enterprise Portal” (EP), “Composition
Environment” (CE), y otros sistemas basados en “NetWeaver Java”. El control de estas órdenes
de cambio será manejado por CTS+. En la “Ilustración 13 - Manejo de Cambios en SAP Java”
aparecen 5 aplicativos, donde existen 3 ambientes basados en “NetWeaver Java” (DEV, TEST,
PROD), un “Java Debelopment Environment” (NWDI), y el “Solution Manager”. El primer ambiente
“NetWeaver Java” DEV es donde se desarrolla, el manejo centralizado de los cambios, que esta
soportado por el NWDI, desde donde son promovidos las ordenes de cambio al CTS+ localizado
en el “Solution Manager”, que puede desplegar estos cambios a los otros sistemas basados en
“NetWeaver Java” siguiendo los controles de pruebas y autorizaciones apropiados.
25
24 Marzo 2014
Ilustración 13 - Manejo de Cambios en SAP Java
En la “Ilustración 11 - Línea de Transportes PO” se muestra el proceso de transportes entre los

ambientes PO. El envío de los cambios será controlado centralizadamente desde el CTS+ y
NWDI, al igual que se expone en la “Ilustración 14 - Línea de Transportes PO”.
Ilustración 14 - Línea de Transportes PO
2.6. Soluciones de Industria
2.6.1.Objetivo
Representar la agrupación lógica de las empresas que conforman el proyecto según la base del tipo de
negocio que representan
2.6.2.Agrupación por Solución de Industria
En la imagen “Ilustración 15 – Soluciones industriales por empresas” aparece solo a modo informativo los
cinco grupos en los cuales se distribuyeron cada una de las empresas según el tipo de industria al que
pertenecen. Del estudio se identificaron cinco soluciones a las cuales se pueden adaptar cada una de las
compañías por tipo de industrias que harán parte del “Programa de Transformación Empresarial”. De las
26
24 Marzo 2014
diferentes soluciones industriales se ha identificado que solo la solución de industria “Media” sería la única que
se implementaría, esta maneja TV, Periódicos, y Revistas.
Ilustración 15 - Soluciones industriales por empresas
En la fase de diseño se estudiaron las diferentes estrategias de implementación de las Soluciones de

Industria, las cuales pueden ser observadas en las Fases II y III de la “Ilustración 16 - Evolución de las
soluciones en SAP”, de las estrategias expuestas se definió que las Soluciones de Industria serán
implementadas por fuera del ERP.
IS 2 IS 1 IS 2 Análisis de esfuerzos “What if…”

1+ Vertical Bajo Alto
IS 1
FO
FASE 3
MO
Evolución de los procesos de negocio
BO
IS
1 Vertical
IS
FO
MO
FASE 2
BO
Si ? No
¿Conveniencia o
FO factibilidad de
arquitectura
MO integrada?
BO
FASE 1
BO No
aplica
Estandarización Ampliación de Compra de cías ó cambios

FO: Frontoffice de Backoffice funcionalidades que requieren Verticales
MO: Middleoffice 10
BO: BAckoffice Evolución en las soluciones en SAP
Ilustración 16 - Evolución de las soluciones en SAP
27
24 Marzo 2014
Esta estrategia se basó en:
▪ No se puede activar más de una Solución de Industria en un sistema
▪ No se pueden de-activar las Soluciones de Industria después de haber sido activadas
▪ La lista actual de IS Add-On correspondiente a las “Business Function Sets” en el “SAP ECC”
soportadas se encuentran el nota “838003 - Industry add-ons integrated into SAP ECC 6.0”
▪ Escalabilidad de las empresas nuevas
▪ Consideraciones de compra y venta de empresas
▪ Complejidad de entrada y salida de empresas en diferentes fases de implementación
Esta estrategia permite la entrada y salida de empresas, permitiendo el crecimiento de estas dentro de la
corporación.
2.7. Servicios
2.7.1.Respaldo y recuperación
2.7.1.1. Objetivo
Establecer una estrategia de Respaldo y Recuperación efectiva que cumpla con los requerimientos del
negocio, la cual provea continuidad en el caso de pérdida de los datos en un sistema.
El propósito de un backup es asegurar que la base de datos pueda ser restaurada a un estado correcto y
consistente después de haber sufrido un daño.
2.7.1.2. Supuestos
▪ Definición actual para sistemas no productivos

▪ Cualquier recomendación está basada en que los sistemas no son 7x24
▪ Durante la noche existen ventanas de tiempo para apagar los sistemas y hacer los backup
▪ Los ambientes no ABAP o JAVA Stack serán apagados manualmente para hacer los backup
offline
2.7.1.3. Estrategia de Backup
La estrategia de Backup está contenida en el documento “GVAL-SIS-EN_Estrategia de Bakcup Ambientes

ABAP_v1.2.2.docx”, este documento contiene la información sobre los datos a respaldar, plataforma
tecnológica, herramientas, frecuencia, y retención de los backup, planeación de tapes, data en reposo, y
restauración.
GVAL-SIS-EN_Estrategia de Bakcup Ambientes ABAP_v1.2.2.docx
Microsoft Word
Document
28
24 Marzo 2014
2.7.2.Alta disponibilidad y recuperación ante desastres
2.7.2.1. Objetivo
Dar continuidad a los procesos de negocio, especialmente a los procesos críticos. En esta área se
presentan las definiciones para poder dar continuidad en el caso de una falla, como se muestra en la
“Ilustración 17 - Causas de Desastres”
Errores físicos
(Falla de hardware)
Factores Externos Errores lógicos

(Daños por incendio o agua) (Borrado de tabla)
PERDIDA
INFORMACIÓN
Una buena estrategia de respaldo de datos previene la

perdida de información y minimiza el tiempo de inactividad
Plan de Procedimiento
y Escalamiento
Ilustración 17 - Causas de Desastres
2.7.2.2. Supuestos
▪ No se tendrá Alta Disponibilidad (HA) o Disaster Recovery (DR) en los ambientes No-Productivos,
excepto en situaciones especiales como la ejecución de pruebas durante las actualizaciones.
▪ Se utilizara replicación de logs para la bases de datos
▪ Alta disponibilidad solo existirá dentro del mismo Centro de Computo
▪ Disaster Recovery y Replicación de BD existirá solo entre diferentes Centros de Computo
▪ Solo el ERP y PO son lo suficientemente críticos para requerir soluciones de HA y DR
▪ La identificación de un nuevo sistema crítico, requerirá que sea adherido a esta estrategia
▪ Existen dos Centros de Computo (DC), Triara (DC1) y Corporativo (DC2)
▪ En Triara estarán localizados los ambientes productivos y en el Centro de Computo Corporativo se
localizara la recuperación de desastres y los ambientes no productivos
▪ En paralelo se manejara el envío de los tapes en el caso de un desastre
▪ En los dos Centros de Computo existirá la misma solución de respaldo “TSM”
▪ Los nombres de los servidores físicos y virtuales del DR no son los definitivos y están a modo de
referencia
2.7.2.3. Requerimientos
Es un requerimiento corporativo la necesidad de dar continuidad a la operación y procesos de negocio

críticos, por esta razón el ERP y PO son los ambientes que actualmente están identificados como críticos,
a los cuales se les aplicara Alta Disponibilidad y Disaster Recovery
29
24 Marzo 2014
2.7.2.4. Alta Disponibilidad
Alta disponibilidad sucede dentro de un Data Center y ofrece continuidad operacional a sistemas críticos
siempre que no exista una causa de desastre, es un proceso automático, donde la falla de un servidor
donde se localiza un aplicativo SAP puede ser remplazada por otro servidor que supla continuidad al
proceso de este aplicativo SAP. De esta forma se asegura al usuario final la habilidad de poder acceder
al sistema y continuar con sus tareas de trabajo.
En la “Ilustración 18 - Alta Disponibilidad (HA)” se muestra la solución definida para el manejo de alta
disponibilidad donde existen cuatro servidores físicos, de los cuales dos de ellos manejan las bases de
datos (SRV1, SRV2) y los otros dos manejan las instancias SAP (SRV3, SRV4), a parte existen otros
cuatro servidores virtuales alojados dentro de los servidores físicos, de los cuales dos de ellos se
encargan del manejo de las bases de datos (SRV5, SRV6), y los otros dos se encargan del manejo de las
instancias SAP (SRV7, SRV8). Los datos en la base de datos están alojados en unos storages que
también tienen redundancia que permite la continuidad en el caso de presentarse una caída en uno de
ellos.
Data Center 1
SRV1 SRV2
DB Instance Storage DB Instance
Windows Windows
Cluster Cluster
PO ECC PO ECC
ECC
SRV5 SRV6 SRV5 SRV6
ERS ERS ERS ERS
ASCS SCS ASCS SCS
Primary Application Additional Application Primary Application Additional Application

Server Instance Server Instance Server Instance Server Instance
PAS PAS (Java) PAS PAS (Java)
SRV7 - ECC SRV8 - PO SRV7 - ECC SRV8 - PO
SRV3 SRV4
WebDispatcher WebDispatcher
SAP GUI SAP GUI SAP GUI SAP GUI SAP GUI SAP GUI
Logon Logon
Balance Balance
Web Web
Web
Ilustración 18 - Alta Disponibilidad (HA)
En el caso de presentarse la caída de uno de los servidores físicos, la IP virtual, hostname virtual, y
algunos directorios de la SAN contenido dentro de este servidor físico navegara al servidor físico alterno,
habilitando de forma automática la disponibilidad de los servicios, y garantizando de esta forma la
continuidad de los procesos de las empresas.
30
24 Marzo 2014
Por otro lado el aplicativo F5 direccionara los servicios de integración web al Webdispatcher que se
encarga del balanceo de cargar a los servicios del Process Orchestration.
2.7.2.4.1. Requerimientos:
▪ Los sistemas críticos de la solución deben estar configurados bajo el concepto de alta
disponibilidad.
▪ La alta disponibilidad será entregada mediante la configuración de clúster.
▪ Se deben configurar clústeres independientes para las capas de aplicación y base de datos.
▪ El proceso de cambio hacia el servidor alterno debe ser totalmente automático.
▪ Se debe garantizar que al momento de caída de un servidor, los usuarios puedan conectarse
al servidor alterno, sin configuraciones adicionales.
▪ Se debe garantizar un tiempo máximo de 5 minutos en el proceso de cambio hacia el servidor
alterno.
▪ El proceso de retorno a la normalidad de los servicios se realizará dentro de una ventana de
tiempo controlada.
2.7.2.5. Disaster Recovery
Disaster Recovery sucede entre diferentes Centros de Cómputo, entre los que existe una replicación de la
data de los servidores críticos, esto permite ofrecer continuidad operacional a los sistemas críticos ante
una causa de desastre (ej. Terremoto, explosión), es un proceso semi-automático, donde la
indisponibilidad de un Centro de Computo genera un proceso de alarma donde un equipo definido para
tomar el control ante un desastre, tiene que proceder a activar la contingencia y acceso a los sistemas
críticos replicados en el Centro de Computo alterno.
.
En la “Ilustración 19 - Disaster Recovery” se representa la solución definida para el manejo de la
contingencia ante desastre, donde se tiene inicialmente replicado el kernel de los aplicativos SAP y Base
de Datos, posteriormente se utiliza Oracle Data Guard para replicar los logs de la base de datos entre los
dos Centros de Cómputo. En el caso de un desastre que impida al Centro de Cómputo 1 y según la
autorización de los equipos de contingencia ante desastres, se procedería a levantar las réplicas de los
sistemas críticos como el ERP y el PO en el Centro de Cómputo 2, para dar disponibilidad a las empresas
del uso de estos aplicativos y así dar continuidad con las tareas diarias.
Alternamente, se maneja que los backup tomados en el Centro de Computo 1 puedan ser enviados y
restaurados al Centro de Computo 2 para poder manejar un nivel de redundancia ante cualquier
eventualidad.
31
24 Marzo 2014
Centro de Computo 1 Centro de Computo 2
DB
DB
ABC
Replicación a nivel Software Log Shipment
ABC´ Semi
DATA GUARD
Automático
Solución ABC Solución ABC
Restore
Backup
Envío de Tapes al DR Manual
Ilustración 19 - Disaster Recovery
2.7.2.5.1. Requerimientos:
▪ Los sistemas críticos de la solución deben estar replicados a centro de cómputo alterno, que
permitan desarrollar una estrategia de disaster recovery.
▪ Se debe garantizar total consistencia y soporte de SAP sobre las herramientas utilizadas.
▪ El proceso de réplica no puede tener una latencia mayor a 5 minutos para la base de datos.
▪ El proceso de réplica para las capas de aplicación y base de datos son independientes.
▪ El proceso de cambio hacia el centro de cómputo alterno, debe estar alineado con las
actividades definidas en el plan de contingencia ante desastres y las respectivas
autorizaciones.
▪ Al momento de estabilizar la plataforma en el sitio alterno, de acuerdo a los protocolos de
acceso establecidos en el plan de contingencia, los usuarios definidos se podrán conectar a
los servicios recuperados sin necesidad de configuraciones adicionales en los clientes.
▪ En el plan de contingencia ante desastres, deben estar contenidas las actividades necesarias
que permitan reestablecer el servicio en el centro de cómputo principal de forma controlada
(retorno a la normalidad)
2.7.3.System Landscape Directory
2.7.3.1. Objetivo
Describir a alto nivel la arquitectura definida del System Landscape Directory
2.7.3.2. Concepto
El System Landscape Directory (SLD) es la fuente central de información de los sistemas relevantes para
la gestión del ciclo de vida de los sistemas SAP. Es un directorio que comprende información sobre todo el
software instalado de un landscape de sistemas, donde se mantienen los datos actualizados de forma
automática. Esta información es utilizada principalmente por SAP PO y Solution Manager.
32
24 Marzo 2014
En la “Ilustración 20 - Arquitectura propuesta SLD” se describen los sistemas y las relaciones, que
actualmente van a trabajar con el SLD.
Ilustración 20 - Arquitectura propuesta SLD
Dentro de las recomendaciones se encuentran:

▪ Configurar un SLD para los sistemas no-productivos y otro para los sistemas productivos.
▪ Por experiencia de consultoría SAP, es recomendable configurar el SLD central en SAP PO y
configurar un “SLD Data Suppliers”/“Bridges de SAP PO” para Solution Manager, hasta que
instale SAP PO, puede utilizar SAP Solution Manager como SLD central y cambiar posteriormente
la configuración del SLD central a SAP PO, cuando esté instalado.
2.7.4.Impresión
2.7.4.1. Objetivo
Definir a alto nivel la estrategia de impresoras
2.7.4.2. Supuestos
▪ El corporativo implementara Federación de Dominios y Identity Management

▪ Existen algunas empresas que no tienen dominio y que serán embebidas por el dominio Corporativo
▪ El corporativo hizo pruebas de impresión SAP con algunas empresas del Grupo Valorem, las cuales
fallaron aparentemente por problemas de integración entre dominios y/o redes
▪ Impresora Local: Imprimir con las impresoras que cada usuario tiene configuradas en su equipo
▪ Impresora Remota: Las impresoras que estarán listadas en SAP, independientemente de que la
impresora este físicamente adherida al computador desde donde se solicita la impresión.
2.7.4.3. Estrategia
Se definió para la estrategia de impresión:

▪ Configuración mixta entre impresoras accedidas directamente desde SAP e impresoras Frontend
▪ Se manejara impresión Frontend sobre impresoras no soportadas por SAP
▪ Los usuarios de la compañía no imprimirán en las impresoras de otras compañías
33
24 Marzo 2014
▪ Los servidores SAP pueden comunicarse con los servidores de impresión que hayan sido definidos en
cada una de las compañía
▪ Se implementara niveles de seguridad a través de roles y perfiles para dar a cada usuario
autorizaciones a imprimir sobre las impresoras que estén autorizados a usar.
▪ Se recomienda utilizar servidores de impresión en el caso que persistan los problemas de impresión
por las redes, de igual forma se pueden configurar directamente las impresoras en SAP sí no
persisten los inconvenientes.
Durante la fase de diseño se envió un formato donde cada compañía identifico sus datos estadísticos de
las impresoras que posee, donde se definieron 286 impresoras que se integraran con SAP, definidas solo
como impresoras Láser, Tinta, y de Matriz de Punto.
En la “Ilustración 21 - Impresoras Locales y Remotas” se describe a alto nivel las impresiones locales y
remotas.
Ilustración 21 - Impresoras Locales y Remotas
2.7.4.4. Estadísticas de Impresoras
Los siguientes cuadros estadísticos contienen la información suministrada por cada una de las empresas
que conforman el Grupo Valorem sobre las impresoras que poseen y que tendrán relación a los sistemas
SAP, esta información es útil para poder definir la estrategia y uso de estas impresoras por los usuarios de
los sistemas SAP. La información se recogió de los formatos entregados por cada una de las empresas.
De las 421 impresoras descritas en el formato, solo 286 fueron clasificadas que tendrán interacción con
SAP.
Estas 286 impresoras fueron organizadas por tipo y por modelo. Según el tipo de impresoras quedaron
organizadas en:
DotMatrix Laser Inkjet Térmicas Plotter
Total 26 258 2 0 0
En la siguiente tabla aparecen las impresoras organizadas por marca y modelo, donde aparece la
cantidad, sí el modelo es soportado por SAP, y en que compañías están localizadas. Las impresoras no
soportadas por drivers de SAP serán configuradas por la estrategia de impresión Frontend.
34
24 Marzo 2014
Marca Modelo Cantidad Modelos Soportados SAP Compañías
CANON BJC-2000 1 NO SUPPLA
DELL 5310n 1 NO REFOCOSTA
EPSON FX-890 4 SI CARACOL, SUPPLA
EPSON FX-1170 6 SI SUPPLA
EPSON LQ-2180 4 SI REFOCOSTA
EPSON LX-300 4 NO ICCKNET, SUPPLA
EPSON STYLUS T24 1 NO CARACOL
HP Laserjet 400 color MFP 1 NO ICCKNET
HP Laserjet 500 Color M575F MFP 2 NO CARACOL
HP Laserjet 600M 602 3 SI CARACOL
HP Laserjet CM1410 1 NO CANAL CLIMA
HP Laserjet CM4540 MFP 2 SI CARACOL
HP Laserjet CP3525 23 NO TEATRO MAYOR
HP Laserjet M1130 1 NO DATAIFX
HP Laserjet M1319F 1 NO SUPPLA
HP Laserjet M3035 MFP 3 SI CARACOL
HP Laserjet M4555 MFP 3 SI CARACOL
HP Laserjet M9050 MFP 23 SI TEATRO MAYOR
HP Laserjet Pro 400 M401DN 2 NO CARACOL
Toshiba Studio4520 1 SI REFOCOSTA
XEROX 3600_DN 50 SI SUPPLA
XEROX 3635MFP 98 SI SUPPLA
XEROX 4250/4260 28 SI SUPPLA
XEROX 4600/4620 4 SI SUPPLA
XEROX 7125_TD 7125 1 SI SUPPLA
XEROX DEMO 3250 1 SI SUPPLA
XEROX WC 5335 5 SI SUPPLA
XEROX WC 5755 3 SI SUPPLA
XEROX 4510 1 SI SUPPLA
*ver notas relacionadas por marca de impresoras en la nota “1097990 - List of Printer Vendor Wizard Notes”
Las impresoras soportadas por SAP son modelos de impresoras soportados para ser usados desde su
compra en sistemas SAP basados en ABAP.
En el siguiente cuadro se listan las impresoras que deben quedar configuradas con impresión segura,
según los requerimientos de las diferentes compañías.
EMPRESA Modelos Marca Quien Usa la Impresora? Color/BW Cantidad

CARACOL Laserjet 500 Color M575F MFP HP STOCK MODELS BOGOTA COLOR 1
CARACOL LaserJet CM4540 MFP HP COMPRAS COLOR 1
CARACOL LaserJet CM4540 MFP HP POSTPRODUCCION COLOR 1
CARACOL Laserjet M3035MFP HP EVENTOS DEPORTIVOS B/N 1
CARACOL Laserjet M3035MFP HP NUEVAS PLATAFORMAS B/N 1
CARACOL Laserjet M4555 MFP HP ADMINISTRATIVA B/N 1
CARACOL Laserjet M4555 MFP HP FINANCIERA B/N 1
Se recomienda utilizar impresión segura, roles, y autorizaciones para el manejo de impresiones de

cheques y cualquier otro tipo de impresión que requiera un control y monitoreo fuera de lo normal.
2.7.5.Seguridad
35
24 Marzo 2014
2.7.5.1. Objetivo
Definir a alto nivel los diferentes conceptos de la seguridad de la plataforma SAP.
2.7.5.2. Políticas de Seguridad
2.7.5.2.1. Supuestos
▪ Nueva implementación
▪ Las seguridad nace como un requerimiento del negocio
2.7.5.2.2. Nivel de Seguridad Base
Esta sección contiene conceptos y recomendaciones para la seguridad del servidor de aplicaciones.
2.7.5.2.2.1. Cuentas de Usuario por Defecto
Por defecto existen diferentes usuarios creados en diferentes mandantes de un sistema SAP, los
usuarios creados por defecto en todo sistema ABAP son SAP*, DDIC, EARLYWATCH, SAPCPIC,
y TMSADM.
Es importante cambiar la clave que viene por defecto en estos usuarios, en cada uno de los
mandantes existentes. El reporte RSUSR003 o el SAP EarlyWatch Alert, pueden ser usados para
verificar que las claves han sido cambiadas.
2.7.5.2.2.1.1. Seguridad Usuario SAP*
Para asegurar que no existan ingresos con usuario SAP*, se recomienda:

▪ Revisar que el parámetro “login/no_automatic_user_sapstar” está configurado al valor “1”
▪ Ejecutar reporte RSUSR003 para revisar sí SAP* existe en los diferentes clientes y
verificar que su clave no es trivial. Sí el usuario SAP* no existe en un cliente se
recomienda crearlo. Sí el usuario SAP* tiene la clave “PASS” o “06071972” se recomienda
cambiarla, por una clave no trivial.
▪ Se recomienda bloquear al usuario SAP*
2.7.5.2.2.1.2. Seguridad Usuario TMSADM
El usuario TMSADM es necesario para la administración de transportes, por lo cual necesita

un cuidado especial, por esta razón se recomienda:
▪ Usar el reporte “RSUSR003” para verificar que la clave del usuario TMSADM no es
“Password” o revisar que el valor del campo BCODE en la tabla USR02 para el usuario
BCODE no es “942B9DC0F2394D85” o “B7E2F82C0A3E54C4”, o que PASSCODE es
“C9AA19DA354DC8397D7AC8EA8B4C04DF49CB58FF” o
“A6BF38EE57F90B78C8D88A5212BBF1BA9A966ABB”. De lo contrario la clave debe ser
modificada con el reporte TMS_UPDATE_PWD_OF_TMSADM para cambiar la clave del
usuario TMSADM.
36
24 Marzo 2014
2.7.5.2.2.1.3. Seguridad Usuarios EARLYWATCH y SAPCPIC
Las cuentas EARLYWATCH y SAPCPIC nunca son utilizadas, o son utilizadas raramente.
Para asegurar estas cuentas de usuarios, se recomienda:
▪ Usar el reporte RSURS003 para revisar sí alguna de las claves de estos usuarios está
configurada al valor por defecto.
▪ Sí alguno de los usuarios tiene la clave por defecto, se recomienda cambiar la clave del
usuario en el mandante especifico.
▪ Bloquear estos usuarios en el mandante donde se encuentren.
2.7.5.2.2.2. Políticas de Clave
SAP recomienda crear una política de claves, las cuales deben ser validas en los diferentes
sistemas, para esto SAP recomienda:
▪ Usar el reporte RSUSR003 para revisar que los parámetros del perfil están configurados:
▪ login/min_password_lng ≥ 8
▪ login/min_password_letters ≥ 1
▪ login/min_password_digits ≥ 1
▪ login/min_password_lowercase ≥ 1
▪ login/min_password_uppercase ≥ 1
▪ login/password_expiration_time ≤ 180
▪ login/password_history_size ≥ 5
▪ login/password_change_waittime ≥ 1
▪ login/password_compliance_to_current_policy = 1
Con estos valores las políticas de clave, cumplen con el estándar de seguridad SAP. Estos
valores pueden ser adaptados para cubrir las necesidades y estándares corporativos.
▪ También existen los siguientes parámetros que pueden ser configurados para mejorar la
seguridad:
▪ login/min_password_diff = 1
▪ login/min_password_specials = 1
▪ login/password_max_idle_initial = <# de días de validez de una clave inicial>
▪ login/password_max_idle_productive = <# de días que una clave sin uso puede
seguir valida>
Estas políticas de clave no tienen conflicto con las políticas de clave de un Single Sign On, ya que
las políticas de clave de un Single Sign On son independientes de las políticas configuradas por
estos parametros.
2.7.5.2.2.3. Borrar Clientes no Utilizados
SAP recomienda borrar todos los mandantes no utilizados, excepto por el mandante 000. Incluso
los mandantes 001 y 066 pueden ser borrados. Antes de borrar un mandante se recomienda:
▪ Si se considera borrar el mandante 001 y/o 066, se debe revisar la nota 1749142 “How to
remove unused clients including client 001 and 066”
▪ Revisar que el mandante a borrar no es requerido por ningún usuario
37
24 Marzo 2014
▪ Bloquear el mandante ante accesos de dialogo, ejecutando el reporte
SCCR_LOCK_CLIENT. Para desbloquear el cliente, se debe ejecutar el reporte
SCCR_UNLOCK_CLIENT. Este tipo de bloqueo no previene accesos RFC.
▪ Borrar el cliente, ingresando al mandante a borrar y ejecutando la trx. SCC5
2.7.5.2.3. Gestión de Usuarios y Autorizaciones
2.7.5.2.3.1. Objetivo
Presentar conceptos y la metodología de roles y usuarios.
2.7.5.2.3.2. Usuarios
El maestro de usuarios es mantenido mediante la transacción SU01, donde se pueden definir

diferentes tipos de usuarios, como:
▪ DIALOGO: Es el tipo más común de usuario y pueden ingresar al sistema para trabajar de
forma interactiva, estos usuarios están restringidos por las políticas de tiempo y validez de
claves.
▪ SISTEMA: Este tipo de usuario está definido para ejecutar los procesos de fondo. Son
usuarios que no pueden ingresar al sistema en dialogo, ni trabajar interactivamente, estos
usuarios están excluidos de la política de tiempo de validez de clave
▪ COMUNICACIONES: Este tipo de usuario es el utilizado para comunicaciones sin diálogo
utilizando comunicaciones de tipo RFC o CPIC entre distintos sistemas.
▪ REFERENCIA: Son usuarios que no son asignados a una persona en particular, se
utilizan para asignar autorizaciones adicionales a usuarios de diálogo y del cual estos
últimos heredarían nuevos permisos.
▪ SERVICIO: Este tipo de usuario permite múltiples ingresos, el sistema no valida las
políticas de claves en cuanto expiración o cambio de clave inicial. Este tipo de usuarios
puede ser utilizado para accesos anónimos desde internet
2.7.5.2.3.3. Autorizaciones
Son los permisos que conceden que un usuario ejecute determinada actividad en el sistema,
existen diferentes conceptos de autorización:
▪ ROLE: Son un conjunto de transacciones y/o autorizaciones relacionadas a uno o más

usuarios con el fin de realizar una función.
▪ OBJETO DE AUTORIZACION: Son los elementos que permite la seguridad en el sistema,
estos pueden básicamente restringir una cantidad y/o valor. Cada transacción en SAP
tiene internamente un conjunto de objetos de autorización, que son necesarios para
permitir el acceso al usuario.
▪ CAMPOS DE AUTORIZACION: Contiene los valores que se definen como restricción en
un objeto de autorización.
▪ PERFILES: Es una agrupación de autorizaciones. Por tanto, si el perfil es asignado a un
usuario, éste tendrá acceso a todas las autorizaciones definidas en el perfil.
38
24 Marzo 2014
Los roles pueden dividirse en tres tipos:
▪ ROLE GENERICO: Son un conjunto de transacciones y autorizaciones que definen una
unidad lógica de trabajo (función).
▪ ROLE DERIVADO: Son usados cuando el mismo rol genérico necesita tener diferentes
versiones con el fin de restringir actividades a nivel de la estructura organizativa o a nivel
de mecanismos de control de la aplicación. Técnicamente son creados a partir de un rol
genérico.
▪ ROLE COMPUESTO: Conjunto de roles genéricos y/o derivados que combinan todas las
autorizaciones que son requeridas para una posición.
2.7.5.2.3.4. Estrategia
La estrategia de roles y perfiles está basada en la definición de un modelo de Seguridad SAP,

donde se cubren temas, como:
▪ Revisión de documentación de procesos
▪ Definición de nomenclatura / Chequeo de detalles de seguridad
▪ Elaboración de matrices
▪ Revisión de matrices y definición técnica
▪ Elaboración de entregables
▪ Validación / Confirmación de definiciones y entregables
▪ Ajustes de entregables
▪ Presentación del Modelo de Seguridad SAP definido
Esta estrategia está enmarcada en sesiones, que actualmente están programadas según la
“Ilustración 22 - Agenda Diseño de Seguridad”, donde se observa la programación propuesta de
actividades a ser cubierta.
Ilustración 22 - Agenda Diseño de Seguridad
De esta sesiones saldrán como resultado las matrices de roles y perfiles.
39
24 Marzo 2014
2.7.5.3. Autenticación
2.7.5.3.1. Objetivo
Definir y alinear los requerimientos de autenticación con los que ingresaran los usuarios a los sistemas
SAP.
2.7.5.3.2. Supuestos
▪ Los sistemas operativos de los servidores donde se alojaran los aplicativos SAP son Microsoft
Windows 2008 Server R2
▪ Los diferentes ambientes de los aplicativos SAP estarán virtualizados en HYPER-V
▪ Se usara Identity Management (IDM), desde donde se tendrá el repositorio de usuarios
▪ Se harán pruebas de IDM solo en Calidad y Producción
▪ La mesa de ayuda asignara manualmente los roles y perfiles
▪ Un usuario que no hace parte del dominio, utilizaran usuario/clave en vez de SSO
▪ La asignación de Roles y Autorizaciones se hara de forma manual por la mesa de ayuda
▪ La autenticación de los ambientes de Desarrollo será con usuario y clave
▪ El licenciamiento de IDM debe cubrir todas las empresas
▪ El IDM soportara las autenticaciones por Kerberos de los diferentes aplicativos SAP, de lo
contrario se debe estudiar con aplicativos no ABAP o JAVA diferentes soluciones de SSO
2.7.5.3.3. Estrategia
Todos los usuarios se autenticaran utilizando usuario y clave mientras se define e implementa el
Single Sign On (SSO). Se ha definido que los usuarios que no hagan parte de alguno de los dominios
de las empresas integradas, ingresaran con usuario/clave a los sistemas SAP.
2.7.5.3.4. Single Sign On
2.7.5.3.4.1. Objetivo
Definir y alinear los requerimientos de Single Sign On (SSO) que se necesitan para autenticar a
los usuarios de las diferentes compañías del grupo y los sistemas SAP.
2.7.5.3.4.2. Concepto
Es un procedimiento de autenticación que habilita al usuario a acceder a diferentes sistemas con

una sola instancia de identificación, básicamente es un sistema centralizado de autenticación y
autorización.
Entre las características de SSO están:

▪ Reduce costos y esfuerzo por manejo de una sola clave por usuario
▪ Refuerza centralizadamente las políticas de clave
▪ Soporta una variedad de aplicativos SAP
▪ Soporta Digital Signatures
▪ Puede ser integrado por:
▪ Kerberos
▪ Certificados X.509 (PKI)
▪ SAML 1.1 o 2.0
▪ SAP Logon Tickets
40
24 Marzo 2014
La “Ilustración 23 - SSO con Kerberos” es una representación del proceso de autenticación de los
usuarios y sistemas SAP utilizando como verificador el maestro de usuarios del dominio de
Windows a través de Kerberos.
Ilustración 23 - SSO con Kerberos
Kerberos, básicamente es un protocolo de autenticación de redes de ordenador que permite a dos

ordenadores en una red insegura demostrar su identidad mutuamente de manera segura, el cual
brinda autenticación mutua: tanto cliente como servidor verifican la identidad uno del otro..
2.7.5.3.4.3. Estrategia
Se ha definido utilizar una estrategia mixta para la autenticación usando SSO, donde entre
sistemas SAP existirán autenticaciones usando “SAP Logon Ticket”, y entre usuarios y aplicativos
SAP se utilizara “Kerberos”. Dependiendo de las necesidades futuras, pueden utilizarse otros
protocolos de SSO, en este caso deberá incluirse esta información a la estrategia.
2.7.5.3.4.4. Requerimientos
El requerimiento de SSO nace de la necesidad del Grupo Valorem, de tener una solución que
permita la autenticación de usuarios entre las soluciones SAP y los diferentes dominios usando
LDAP.
Los requerimientos para la implementación de SSO por Kerberos están definidos, por:
▪ Tener uno o más Active Directories bajo Windows Server 2003 R2 o superior
▪ Los usuarios de los dominios y SAP deben ser iguales
▪ Las cuentas de <sid>adm y SAPService<SID> deberán correr bajo alguno de los dominios de
LDAP
▪ Los dominios proveídos para SAP Kerberos estarán siempre en MAYUSCULAS
▪ Implementar y habilitar los paquetes de software del SSO para SAP en los componentes de
software donde se requiera
▪ Los sistemas SAP debe poder tener acceso cada uno de los dominios/LDAP
41
24 Marzo 2014
▪ Tener usuarios en cada LDAP con suficientes autorizaciones
2.7.5.3.4.5. Consideraciones
Se debe tener en cuenta, que puede ser necesario:

▪ Un Trust entre diferentes los dominios que conformen esta arquitectura o un ADFS 2.0
▪ Un aplicativo que centralice el maestro de usuarios como un IDM o CUA
▪ Usar el dominio en el usuario
▪ Configurar Parámetros de SSO en donde sean requeridos
▪ Configurar la transacción SU01 el "SNC"
▪ Habilitar el SSO en los Front de SAP GUI
▪ Enlazar Usuarios LDAP con Usuarios SAP
2.7.6.Archiving
2.7.6.1. Objetivo
Preparar y alinear las estrategias del Grupo Valorem para poder identificar e iniciar proyecto de Archiving.
2.7.6.2. Concepto
El término “Data Archiving” se refiere a mover datos de la base de datos de un aplicativo SAP por medio
de un programa de archivado a un repositorio externos donde estos pueden ser guardados comúnmente
como archivos planos. El sistema utiliza un programa de archivado que se basa en objetos de archivado
(Archiving Objects), donde se consideran los grupos de Archiving Objects a las tablas que están
lógicamente enlazadas a un objeto de negocio. Esto asegura que toda la información relacionada a un
objeto de negocio en el ERP sea escrita a un archivo plano y borrado posteriormente de la base de datos.
El acceso a los datos en el Archiving es posible usando reportes del aplicativo, usando la información del
sistema de Archiving, o usando DART (Data Retention Tool). También se pueden crear reportes
personalizados que exploten los datos en el Archiving.
En la “Ilustración 24 – Archiving” se describe a alto nivel el proceso de archivado de datos y el acceso a

estos datos archivados externamente desde el aplicativo SAP.
42
24 Marzo 2014
Ilustración 24 - Archiving
Es importante considerar para el Archiving:

▪ Normalmente puede iniciarse después 2 años de haber salido en vivo
▪ Se debe estudiara el impacto de:
▪ Ingreso/salida de empresas
▪ Adición de funcionalidad
▪ Entrada de nuevas Fases
▪ Llevar al Archiving solo datos consolidados que no van a ser cambiados, que tengan una
antigüedad considerable
▪ No considerar el Archiving como la última solución a un colapso del sistema
▪ Asegurar que el performance del sistema se mantiene eficiente antes de iniciar un proyecto de
Archiving
▪ Requiere un alto nivel de cooperación entre usuarios funcionales y el equipo de IT
▪ Considerar Re-Sizing bajo nuevos cambios en sistema
▪ Estudio Funcional y Técnico sobre los objetos de archiving
▪ Evaluar el uso de herramientas de archive, tales como: Archivelink, Opentext, NLS
▪ Demostrar el uso y necesidad de Archiving
▪ Identificar los objetos de Archiving
▪ Estimar el costo y el esfuerzo para el Archiving
2.7.6.3. Estrategia
En la “Ilustración 25 - Estrategia de Archiving” se puede observar los puntos clave que pueden ser
utilizados como una ruta de estrategia de Archiving, a la hora de que el Grupo Valorem decida ejecutar un
proyecto de Archiving sobre los aplicativos SAP.
43
24 Marzo 2014
Ilustración 25 - Estrategia de Archiving
El siguiente diagrama puede ser utilizado como modelo para la identificación oportuna de la necesidad de
implementar Archiving.
44
24 Marzo 2014
3. ARQUITECTURA FÍSICA
3.1. Sistemas operativos y virtualización
3.1.1.Objetivo
Definir las tecnologías de virtualización soportadas para ambientes productivos SAP y Oracle 11.2 en
ambientes Windows
3.1.2.Supuestos
▪ Los sistemas a virtualizar son ERP, BW+BPC, PO, DS, BO, y Solman
▪ La base de datos definida es Oracle 11G
▪ El sistema operativo definido es Windows 2008 Server (R2), debido a que se asegura la
compatibilidad con otros aplicativos, tanto para la base de la virtualización como en los servidores
virtualizados.
▪ El aplicativo de Virtualización es HYPER-V
3.1.3.Estrategia
Por temas de compatibilidad con aplicativos de las diferentes empresas se utilizara Windows Server 2008 R2
como el sistema operativo, como base de datos fue definida Oracle 11.2, y como sistema de virtualización se
utilizara Hyper-V corriendo en Windows Server 2012, los cuales están soportados para el manejo de
virtualizaciones de ambientes productivos. Siempre y cuando se sigan las recomendaciones y restricciones de
las notas nombradas.
SAP & HYPER-V ORACLE (11.2,11.2 RAC) x HYPER-V

(Aplican Restricciones-ver notas) (Aplican Restricciones-Ver Notas)
Windows Server 2008 R2 SI (como Virtualización) SI
Es importante revisar sí han sucedido cambios y/o nuevas restricciones que puedan impactar el proyecto,
especialmente sí se piensa implementar algún nuevo producto de SAP, por esta razón es bueno ver la
siguiente documentación:
▪ En Oracle ir a la nota 1563794.1

▪ El SAP Products Availability Matrix PAM: http://service.sap.com/pam
▪ Las virtualizaciones están soportadas para ciertos hardware listados en el link http://www.saponwin.com
▪ Los aplicativos SAP NetWeaver '04 SR1 y Superiores están soportados mientras se implemente
“Enhanced Monitoring” para virtualización
▪ Notas:
▪ 1329848 - Oracle Support for Windows Server 2012 Hyper-V
▪ 1492000 - General Support Statement for Virtual Environments
▪ 1409608 - Virtualization on Windows
45
24 Marzo 2014
3.2. SAP GUI
3.2.1.Objetivo
Explicar según las características del proyecto, que definiciones han surgido en cuanto a la instalación del
software de Frontend de SAP (SAP GUI). El SAP GUI es la interface que permite interactuar los sistemas
SAP basados en ABAP Stack (ej. ERP) con los usuarios finales.
3.2.2.Supuestos
▪ El Corporativo ha definido que solo soportara las versiones de Windows iguales o superiores a la
versión de Windows 7 o Windows Server 2003 (R2)
▪ SAP GUI esta soportado para Windows 7, 8, y 8.1 en el momento que se generó esta definición
▪ Sistemas Operativos diferentes a Windows podrán correr el SAP GUI para JAVA 7.30 con ciertas
restricciones
▪ Cada empresa se encargara de distribuir las actualizaciones del SAP GUI usando el “Installation
Server de SAP GUI” o utilizando algún aplicativo propio de distribución.
▪ Cada empresa localizara en la red corporativa las nuevas versiones de SAP GUI que distribuirá
3.2.3.Plataformas Soportadas SAP GUI
SAP GUI 7.30 para Windows esta soportado para la mayoría de las plataformas Microsoft Windows:
▪ Windows 7, 8, y 8.1
▪ Windows Server 2003 y 2008
SAP GUI for Java 7.30
▪ Windows 7, 8, 8.1
▪ Windows Server 2003, 2003 R2, 2008, 2008 R2, 2012, 2012 R2
▪ Apple Macintosh
▪ Unix
▪ Linux
Es importante revisar al menos cada seis meses en el Service Market Place (http://service.sap.com/notes) la
Notas SAP Números 66971 “Supported SAP GUI platforms” y 26417 “SAP GUI Resources: Hardware and
software”, estas notas hablan de las plataformas soportadas para SAP GUI.
3.2.4.Estrategia de Distribución SAP GUI con SAP GUI Installation Server
Cada empresa será avisada por el corporativo donde puede descargar los archivos de actualización del SAP
GUI a ser distribuidos, posteriormente cada empresa en su red interna se encargara de distribuir el SAP GUI
con el aplicativo de su preferencia. En el caso de utilizar el “SAP GUI Installation Server”, se utilizara una
estrategia similar a la que se puede observar en la “Ilustración 26 - Distribución de Actualización de SAP GUI”,
la cual representa como el “Installation Server” distribuye los paquetes de actualización a los front del cliente y
administrador, desde el “Distribution Service” que es el que aloja los archivos de actualización dentro de la red
46
24 Marzo 2014
de la empresa. Es importante recalcar que el “Installation Server” y “Distribution Service” se pueden encontrar
en el mismo o en diferentes servidores.
Ilustración 26 - Distribución de Actualización de SAP GUI
Se ha definido al “Installation Server” utilizar la opción de instalación sin interacción del usuario (unattended)
ya que no requiere mayor conocimiento del proceso por parte de los usuarios finales, haciéndolo transparente
y amigable el proceso de actualización.
3.2.5.Requerimientos “SAP GUI Installation Server”

El Servidor para Instalaciones de Servicio debe:
▪ Ser accesible a todos los usuarios dentro de la empresa en cualquier momento, incluso después de
que se complete la instalación, esto es requerido para propósito de mantenimiento y distribución de
parches.
▪ Tener una conectividad de red banda ancha de alto rendimiento
▪ Tener al menos 2 gb de espacio libre en disco
▪ Usar Windows 2008 Server o Windows 2003 Server
47
24 Marzo 2014
3.3. Sizing
3.3.1.Objetivo
Ser un documento vivo que debe ser actualizado a medida que pasa el tiempo, para adaptarse a la evolución
de las tecnologías, servicios, y directrices del Grupo y obtener los resultados que sirven para:
▪ Representar Requerimientos de HW según Procesos de Negocio
▪ Proyectar Requerimientos de Recursos en el Tiempo
▪ Estimar Capacidad de Crecimiento
▪ Planificar Inversión/Soporte
▪ Garantizar Desempeño y Tiempos de Respuesta
3.3.2.Supuestos
▪ Las empresas son responsables de diligenciar los datos según el concepto de cada elemento de
sizing
▪ Cada empresa entregara el formato de sizing diligenciado
▪ Cada empresa intentara proyectar su AS-IS al TO-BE de lo que serán sus procesos de negocios, de
no conocer el TO-BE será suficiente con los datos estadísticos del AS-IS para la fase de diseño
▪ Los líderes de empresa son responsables de entregar el formato de sizing al equipo técnico de
proyecto
▪ Los resultados del sizing son basados en las mejores prácticas y no cubren desarrollos
3.3.3.Conceptos
3.3.3.1. Sizing
Busca representar requerimientos en base a recursos como CPU, Disco, Memoria, y I/O, de una máquina
que pueda soportar los procesos de negocios descritos en el sizing. Las medidas entregadas por el sizing
están representadas en SAPS, Memoria GB, Espacio en Disco en GB, y I/O en iops.
3.3.3.2. SAPS
Significa “SAP Application Performance Standard” (SAPS) y es una unidad independiente de hardware
que describe el performance de una configuración de un ambiente SAP. Es derivada de un Benchmark
basado en la Distribución de Ventas (SD), donde 100 SAPS representa el poder computar completamente
2,000 partidas de negocios por hora.
48
24 Marzo 2014
3.3.3.3. Herramientas de Sizing
Como se aprecia en la “Ilustración 27 - Herramientas de Sizing” existen 5 métodos para hacer un sizing.
Método de
Cálculo Inicial
Usuario Experimentado
T-Shirt Sizing
Algoritmos simples con
muchos supuestos
Fórmulas
Simples y Complejas C=X*N*D¨0.25
Cuestionarios
Sin Fórmulas
Preguntas Estructuradas
Quick Sizer
Soporta base usuarios y
base rendimiento
Ilustración 27 - Herramientas de Sizing
▪ Método de Cálculo Inicial: Es el cálculo hecho por un experto y sirve para hacer un cálculo
presupuestal al inicio del proyecto.
▪ T-Shirt Sizing: Es una de las dos opciones cuando un aplicativo SAP no está cubierto por el
quicksizer. Básicamente es un documento que propone recursos (CPU, Memoria, Disco, I/O, y/o
Red) según unas características a las cuales el aplicativo se adapta según las necesidades del
proyecto.
▪ Formulas: Al igual que T-Shirt Sizing es una de las dos opciones cuando un aplicativo SAP no
está cubierto por el quicksizer. Básicamente es un documento que propone recursos contiene
fórmulas que ayudan a calcular valores que se representaran en (CPU, Memoria, Disco, I/O, y/o
Red)
▪ Cuestionarios sin Formulas: Es un formato en archivo Excel, similar al quicksizer en cuanto a

contenido y resultados, que nos permite obtener resultados según las estadísticas de los procesos
de negocio representadas en los diferentes elementos de sizing. Los resultados son
representados en (CPU, Memoria, Disco, I/O, y/o Red)
▪ QuickSizer: Es un formato en línea disponible 7x24 que nos permite obtener resultados según las
estadísticas de los procesos de negocio representadas en los diferentes elementos de sizing. Los
resultados son representados en (CPU, Memoria, Disco, I/O, y/o Red)
49
24 Marzo 2014
3.3.4.Estrategia
3.3.4.1. Cuando se debe hacer un Sizing?

Un sizing es una tarea que se debe hacer en diferentes momentos en el tiempo, las mejores prácticas de
SAP recomiendan hacer los sizing y seguir una estrategia según Proyecto o Cambios.
En la “Ilustración 28 - Sizing Recomendados por Proyecto” aparecen los momentos en los que se
recomienda hacer el sizing cuando hay un proyecto nuevo de implementación.
Preparación Business Preparación Go Live &

Realización
Proyecto Blueprint Final Soporte
Ilustración 28 - Sizing Recomendados por Proyecto
Según estos momentos en el tiempo de ejecución de un Proyecto:

▪ Preparación Proyecto: Es el primer sizing que se hace en un proyecto y su objetivo es mas de
orden presupuestal, normalmente es muy simple y no contiene las características completas de un
sizing. Generalmente este sizing se hace bajo el método de “Método de Cálculo Inicial”.
▪ Business Blueprint: Normalmente es el primer sizing que contiene datos más cercanos a las
necesidades del cliente, ya que las personas envueltas en el proceso de sizing ya conocen los
procesos y seguramente los requerimientos que tienen sobre la plataforma SAP.
▪ Realización: Este sizing tiene la función básica de solicitar el hardware de producción, por esta
razón es importante que suceda con suficiente tiempo para poder hacer el diligenciamiento del
ambiente productivo.
▪ Preparación Final: Este sizing tiene el objetivo de confirmar que el sizing de Realización y las
características del servidor de producción siguen siendo las mismas o muy cercanas, para evitar
problemas de performance al salir en vivo.
▪ Go Live & Soporte: Este sizing tiene el objetivo de adaptar los requerimientos de maquina no
cubiertos por el sizing, ya que el sizing no estima desarrollos ni otras condiciones particulares que
se salen del estándar.
En la “Ilustración 29 - Sizing Recomendados por Cambios” aparecen los momentos en los que se
recomienda hacer el sizing cuando se van a generar cambios importantes en el sistema SAP.
Unidades de Cambios
Actualización Migración
Negocio Funcionales
Ilustración 29 - Sizing Recomendado por Cambios
Según los Cambios:

▪ Actualización: Siempre que se haga una actualización es recomendado hacer un sizing para ver el
impacto que puede tener este upgrade sobre los requerimientos de hardware.
▪ Migración: Siempre que se haga una migración hay que hacer un sizing para ver que el hardware
donde estamos migrando tengas las condiciones necesarias en cuanto a recursos para soportar
los procesos del negocio.
▪ Unidades de Negocio: El adherir nuevas unidades de negocio puede requerir nuevas
características en cuanto a recursos de máquina, por lo que es importante dimensionar el impacto
del ingreso de esta nueva unidad de negocio sobre el sistema.
50
24 Marzo 2014
▪ Cambios Funcionales: Un cambio funcional al igual que los cambios anteriormente descritos
pueden afectar los requerimientos de maquina necesarios para el manejo adecuado de los
procesos de negocio, por esta razón es importante hacer un sizing bajo estas condiciones.
3.3.4.2. Factores que influyen el Sizing
Existen muchos factores que influencian un sizing, como se muestra en la “Ilustración 30 - Factores que
Influencian el Sizing”, por esta razón es importante que se tomen en cuenta:
Negocio Hardware QuickSizer
 Recomendado para
 CPU
 Tiempo de Sizing Inicial
 Procesos
procesamiento  No contiene todas las
 Transacciones
 Volumen aplicaciones SAP
 Tiempo de
transaccional  Considera las
Respuesta
 # de Registros versiones actuales
 DISCO
 # de  Cuestionario en línea
 Nuevos
Transacciones  Disponibilidad 7x24
Procesos
 Reprocesamiento  Resultados en SAPS,
Número de Usuarios  Datos en Línea
 Memoria, Disco, y I/O
Superposición de  Protección de
  Fuera del Alcance:
procesos Fallas (RAID)
 Post Go-Live
Archiving  REDES
 Sizing
Archivos cargados en  Transmisión
  Configuración
la base de datos Datos
 Arquitectura
 # de Interfaces
 Códigos Z
Ilustración 30 - Factores que Influencian el Sizing
Como se muestra en la existen diferentes formas de aproximarse a un sizing según las metodologías de
“Cuestionario sin Formulas” y “QuickSizer”, en la cual se puede utilizar un “Dimensionamiento en base a
Usuarios”, “Dimensionamiento en Base Rendimiento”, y “Mixto Usuarios & Rendimiento”.
Dimensionamiento base Usuarios Dimensionamiento base Rendimiento
Ventajas Ventajas
 Es relativamente fácil de determinar los  Escenarios, transacciones
usuarios  Basado en los objetos y escenarios
 La memoria esta manejada en el contexto de actuales del negocio
usuario  Dimensionamiento sobre Picos y
Retos Promedios
 Definir los usuarios Retos

 Determinar los patrones de carga por usuario  Obtener las estadísticas reales
 Dimensionamiento de crecimiento por
usuarios
Ilustración 31 - Dimensionamiento por Usuarios y/o por Rendimiento
51
24 Marzo 2014
Se ha definido para esta y las subsiguientes faces hacer un sizing mixto, para asegurar que el
performance de la maquina cubrirá todos los requerimiento del negocio en cuanto a procesos estándar.
3.3.4.3. Metodología
La metodología presentada para la fase de Blueprint está basada en presentaciones y entrevistas

particulares con cada una de las compañías, para que estas puedan entregar los datos más cercanos a la
realidad actual de la empresa. Por esta razón se ha generado una programación, como se puede
observar en la “Ilustración 32 - Agenda Sizing Business Blueprint”, con las tareas y los responsables de
cada una de las partes.
24 FEB 28 FEB 5 MAR 6 MAR 7 MAR 10 MAR 11 MAR 13 MAR
- Lanzamiento - Recepción - Entrevista MM - Entrevista HCM - Recepción - Recepción - Recepción - Presentación

Formatos Formatos MM Formatos HCM Formatos Resultados del
Interface y Sizing
- Entrevista - Entrevista
FI/CO/TRM
FI/CO/TRM Interfaces
Ilustración 32 - Agenda Sizing Business Blueprint
3.3.4.3.1. Roles y Responsabilidades
Líder Líder Líderes de Consultores Líderes Gerencia &

Corporativo Funcional Tema Técnicos Infraestructura
Empresa Cliente
Guía o Responsable de Diligenciar y Apoyar con el Guiar el Dar continuidad al

lineamiento asegurar que los localizar los concepto funcional proceso de proceso de sizing y
funcional del líderes de tema de datos y dar un Sizing, cargar solicitar a los
tema su empresa hayan estadísticos de entendimiento de los formatos al proveedores de
cargado los datos su empresa los datos que QuickSizer, y hardware la propuesta
en el formato de según el/los buscamos presentar los según el proyecto de
sizing y Tema(s) al que diligenciar en el resultados al sizing
encargarse de la este(n) formato de sizing final del
entrega de estos asignado(s) ejercicio.
formatos.
3.3.4.4. Cuestionarios de Sizing
El cuestionario de sizing contiene varias preguntas que pueden ser de mayor o menor complejidad. Por
esta razón en esta área queremos ayudar a simplificar y homologar el entendimiento de algunas
preguntas, que pueden salir en el Formato de Sizing o en el QuickSizer.
3.3.4.4.1. Usuarios
Con respecto al tema de Usuarios, se debe colocar usuarios el número de usuarios concurrentes en el
sistema según Low, Medium, y High, estos deben se define según el número de interacciones que
tienen el sistema, pero en el caso de desconocer este valor se puede hacer un cálculo promedio en
base a porcentaje de usuarios.
52
24 Marzo 2014
LOW MEDIUM HIGH
Usuarios 60 % 30 % 10 %
Interacciones 12 x hora 120 x hora 360 x hora
Concurrencia 10 % 10 % 10 %
Sí desconocemos el número de interacciones que nuestros usuarios tendrán en un sistema y

conocemos el número total de usuario, podemos calcular en promedio los valores. Ej. Tenemos 30
usuarios FI donde podemos decir que 20 son Low 6 son Medium y 4 son High, y su concurrencia en el
sistema será de 2 Low, 1 Medium, 1 High.
3.3.4.4.2. Procesos (Elementos de sizing)
En la “Ilustración 33 - Elementos de Sizing” se observan los elementos del sizing y las preguntas que
común mente se hacen sobre los procesos.
Ilustración 33 - Elementos de Sizing
Por esta razón definimos cada una de las áreas:
▪ Element: Para identificar los elementos de sizing. Colocando el mouse en la parte superior
despliega el detalle
▪ A/P - (A) Promedio o (P) Pico: Determinar los niveles promedio y pico de cada elemento de
sizing. Con el promedio se calcula principalmente la utilización de disco y con el pico se
calcula mayormente el CPU, Memoria y I/O.
▪ TI – Intervalo de Tiempo: Muestra el tiempo en el que se debe estimar este pico o promedio y
está representado por:
▪ (Y)ear: Número de objetos por año:
▪ Peak (P)eriod: Número de objetos por según as horas definidas de ejecución
▪ (S)nap shot: Número de objetos en cualquier momento
▪ Objects – Número de Objetos: Los objetos pueden ser órdenes, proyectos, registros,
documentos, etc.
▪ Items: Sub-objetos como son las partidas, elementos, campos llave, … por objeto
▪ % chg: Numero de cambios de un objeto en %
▪ % dsp: Numero de visualizaciones de un objeto en %.
▪ Mon: Mese que residirá la data en el sistema
▪ Arch: Proyecto de Archiving planificado
▪ S.t.: Hora de Inicio del proceso
▪ E.t Hora de Fin del proceso
▪ ID: Identificador para revisar cálculos y promedios
▪ Short text: Texto de comentarios
53
24 Marzo 2014
3.3.4.5. Resultados
Se generó el proyecto “GVAL_2014_FASE1” bajo el “Customer no: 629286”, con los datos suministrados
por las diferentes compañías que conforman el proyecto en la Fase I.
El alcance de este sizing:
▪ Todas las soluciones de Fase I con sus ambientes

▪ El ERP cubre solo el backoffice
▪ 3 Años de crecimiento solo backoffice
▪ No incluye Comunican ni Cine Colombia
▪ Datos recibidos de las empresas
▪ BO y DS se basó su sizing en usuarios y reportes de tipo Webi
▪ Los sistemas de Calidad y Desarrollo están basados en expert sizing
▪ Los resultados del PO serán basados en el PI 7.3
Los resultados obtenidos para el ERP y PO el primer año, son:
El impacto que tuvo cada compañía sobre los recursos (CPU, Memoria, Disco) requeridos está
representado en la “Ilustración 34 - Impacto de las compañias sobre los Recursos”, donde se puede
observar como afectaron porcentualmente cada una de las empresas cada uno de los recursos.
54
24 Marzo 2014
Ilustración 34 - Impacto de las compañias sobre los Recursos
En la “Ilustración 35 - Ancho de banda por compañía” se puede obsevar los requerimientos de ancho de
banda por cada una de las compañías, en color azul está representado el requerimiento minimo y en rojo
el valor pico de red que puede ser requerido en la Fase I.
Ilustración 35 - Ancho de banda por compañia
En la “Ilustración 36 - Recursos x Elementos de Sizing” se puede observar como cada uno de los recursos
del sizing son afectados por cada uno de los modulos de SAP, que actualmente hacen parte de la Fase I.
55
24 Marzo 2014
Ilustración 36 - Recursos x Elementos de Sizing
En la siguiente tabla se puede observar el sizing con el crecimiento a tres años solo de la Fase I:
COMPONENTES AMBIENTE USUARIOS SAPS Memoria GB SWAP GB DISCO GB I/O Tecnica

SAP ERP ECC 6.07 + RDS PRD 801 17000 36 64 1800 6400 Quicksizer
SAP ERP ECC 6.07 + RDS QAS 50 9000 24 48 900 4000 Expert
SAP ERP ECC 6.07 + RDS DEV 5 4000 24 48 320 2000 Expert
SAP ERP ECC 6.07 IDES DEV 20 2000 16 32 500 2000 Exper
Process Orchestration PRD 5 4000 24 48 320 2000 Quicksizer
Process Orchestration QAS 5 3000 12 36 320 1500 Expert
Process Orchestration DEV 5 2000 12 36 320 1500 Expert
Business Objects BI PRD 50 11500 16 32 320 2000 Quicksizer
Business Objects BI QAS 10 9000 16 32 320 1500 Expert
Business Objects BI DEV 5 8500 16 32 320 1500 Expert
SAP Solution Manager 7.1 PRD 40 13218 32 64 600 2000 Expert
SAP Solution Manager 7.1 DEV 20 5520 24 48 386 1500 Expert
BW PRD 100 20000 96 120 598 6400 Expert
BW QAS 30 8000 32 64 470 4800 Expert
BW DEV 10 4000 24 48 320 2000 Expert
NWDI DEV 5 2000 16 48 320 1500 Expert
WPB DEV 20 2000 4 8 120 2000 Expert
Power Designer DEV 5 2000 8 8 120 1500 T-shirt
Totales 1186 126738 432 816 8374 6400
56
24 Marzo 2014
Nota: El sizing de Solman cubre los monitoreos de los sistemas satélites FASE I, CHARM, y Help Desk.
3.3.4.6. Tabla de Sizing por Elemento y Empresa
La siguiente tabla contiene los valores por cada uno de los elementos de sizing por empresa, estos
valores permiten comparar y entender los resultados en las gráficas.
Element A/P A/P-text S.t. E.t. SAPS (total) Memory (total, MB) DB Disk (GB, total) Short text
CO A Average/year 8 18 5 12 23 CARACOL
CO P Peak time 8 18 54 144 0 CARACOL
FIN-BAC A Average/year 8 18 4 8 23 CARACOL
FIN-BAC P Peak time 8 18 41 111 0 CARACOL
MM-IM A Average/year 8 18 4 8 1 CARACOL
MM-IM P Peak time 8 18 4 8 0 CARACOL
MM-PUR A Average/year 8 18 4 8 3 CARACOL
MM-PUR P Peak time 8 18 4 8 0 CARACOL
TV-RECEIPT A Average/year 8 18 4 8 1 CARACOL
TV-RECEIPT P Peak time 8 18 5 12 0 CARACOL
129 327 51 CARACOL
CO A Average/year 8 18 4 8 1 DataIFX
CO P Peak time 9 12 4 8 0 DataIFX
FIN-BAC A Average/year 8 18 4 8 1 DataIFX
FIN-BAC P Peak time 9 12 8 20 0 DataIFX
HCM-PT A Average/year 8 18 2 4 1 DataIFX
HCM-PT P Peak time 9 12 4 8 0 DataIFX
HCM-PY A Average/year 8 18 4 8 1 DataIFX
HCM-PY P Peak time 9 12 4 8 0 DataIFX
MM-IM A Average/year 8 18 4 8 1 DataIFX
MM-IM P Peak time 12 13 11 29 0 DataIFX
MM-PUR A Average/year 8 18 4 8 1 DataIFX
MM-PUR P Peak time 12 13 14 37 0 DataIFX
67 154 6 DataIFX
CO A Average/year 8 18 4 8 1 ICCKNET
CO P Peak time 14 18 34 90 0 ICCKNET
FIN-BAC A Average/year 8 18 4 8 1 ICCKNET
FIN-BAC P Peak time 14 18 28 74 0 ICCKNET
HCM-PT A Average/year 8 18 4 8 1 ICCKNET
HCM-PT P Peak time 8 12 4 8 0 ICCKNET
HCM-PY A Average/year 8 18 4 8 1 ICCKNET
HCM-PY P Peak time 8 12 4 8 0 ICCKNET
MM-IM A Average/year 8 18 4 8 1 ICCKNET
MM-IM P Peak time 8 12 23 61 0 ICCKNET
MM-PUR A Average/year 8 18 4 8 1 ICCKNET
MM-PUR P Peak time 8 12 19 49 0 ICCKNET
136 338 6 ICCKNET
CO A Average/year 8 18 4 8 1 FATM
CO P Peak time 8 18 14 37 0 FATM
FIN-BAC A Average/year 8 18 4 8 1 FATM
FIN-BAC P Peak time 8 18 13 33 0 FATM
HCM-PT A Average/year 8 18 2 4 1 FATM
HCM-PT P Peak time 8 18 4 8 0 FATM
HCM-PY A Average/year 8 18 4 8 1 FATM
HCM-PY P Peak time 8 18 4 8 0 FATM
MM-PUR A Average/year 8 18 4 8 1 FATM
MM-PUR P Peak time 8 18 4 8 0 FATM
57 130 5 FATM
CO A Average/year 8 18 7 16 5 REFOCOSTA
CO P Peak time 7 24 13 33 0 REFOCOSTA
FIN-BAC A Average/year 8 18 4 8 6 REFOCOSTA
FIN-BAC P Peak time 7 24 5 12 0 REFOCOSTA
HCM-PT A Average/year 8 18 4 8 1 REFOCOSTA
HCM-PT P Peak time 7 24 4 8 0 REFOCOSTA
HCM-PY A Average/year 8 18 2 4 1 REFOCOSTA
HCM-PY P Peak time 7 24 4 8 0 REFOCOSTA
MM-IM A Average/year 8 18 4 8 1 REFOCOSTA
MM-IM P Peak time 7 24 4 8 0 REFOCOSTA
MM-PUR A Average/year 8 18 4 8 1 REFOCOSTA
57
24 Marzo 2014
MM-PUR P Peak time 7 24 4 8 0 REFOCOSTA
59 129 15 REFOCOSTA
CO A Average/year 8 18 5 12 18 SUPPLA GRA
CO A Average/year 8 18 4 8 10 SUPPLA CAR
CO A Average/year 8 18 4 8 9 SUPPLA SIA
CO A Average/year 8 18 4 8 1 SUPPLA SRT
CO A Average/year 8 18 4 8 1 SUPPLA VEN
CO P Peak time 8 22 23 61 0 SUPPLA GRA
CO P Peak time 8 22 8 20 0 SUPPLA CAR
CO P Peak time 8 22 4 8 0 SUPPLA SIA
CO P Peak time 8 22 5 12 0 SUPPLA SRT
CO P Peak time 8 18 4 8 0 SUPPLA VEN
FIN-BAC A Average/year 8 18 4 8 10 SUPPLA CAR
FIN-BAC A Average/year 8 18 5 12 19 SUPPLA GRA
FIN-BAC A Average/year 8 18 4 8 10 SUPPLA SIA
FIN-BAC A Average/year 8 18 4 8 1 SUPPLA SRT
FIN-BAC A Average/year 8 18 4 8 1 SUPPLA VEN
FIN-BAC P Peak time 8 22 7 16 0 SUPPLA CAR
FIN-BAC P Peak time 8 22 19 49 0 SUPPLA GRA
FIN-BAC P Peak time 8 22 4 8 0 SUPPLA SIA
FIN-BAC P Peak time 8 18 7 16 0 SUPPLA SRT
FIN-BAC P Peak time 8 18 4 8 0 SUPPLA VEN
MM-IM A Average/year 8 18 5 12 5 SUPPLA SIA
MM-IM A Average/year 8 18 4 8 1 SUPPLA VEN
MM-IM A Average/year 8 18 4 8 2 SUPPLA GRA
MM-IM A Average/year 8 18 4 8 1 SUPPLA CAR
MM-IM A Average/year 8 18 4 8 1 SUPPLA SRT
MM-IM P Peak time 7 22 4 8 0 SUPPLA SIA
MM-IM P Peak time 7 18 4 8 0 SUPPLA VEN
MM-IM P Peak time 7 22 8 20 0 SUPPLA GRA
MM-IM P Peak time 7 22 5 12 0 SUPPLA CAR
MM-IM P Peak time 7 18 4 8 0 SUPPLA SRT
MM-PUR A Average/year 8 18 4 8 2 SUPPLA CAR
MM-PUR A Average/year 8 18 4 8 2 SUPPLA GRA
MM-PUR A Average/year 8 18 4 8 2 SUPPLA SIA
MM-PUR A Average/year 8 18 4 8 1 SUPPLA SRT
MM-PUR A Average/year 8 18 4 8 1 SUPPLA VEN
MM-PUR P Peak time 7 22 5 12 0 SUPPLA CAR
MM-PUR P Peak time 7 22 7 16 0 SUPPLA GRA
MM-PUR P Peak time 7 22 5 12 0 SUPPLA SIA
MM-PUR P Peak time 7 22 4 8 0 SUPPLA SRT
MM-PUR P Peak time 7 18 4 8 0 SUPPLA VEN
218 490 98 SUPPLA
CO A Average/year 8 18 4 8 1 CANAL CLIMA
CO P Peak time 8 12 4 8 0 CANAL CLIMA
FIN-BAC A Average/year 8 18 4 8 1 CANAL CLIMA
FIN-BAC P Peak time 8 18 4 8 0 CANAL CLIMA
HCM-PT A Average/year 8 18 0 0 1 CANAL CLIMA
HCM-PT P Peak time 12 17 4 8 0 CANAL CLIMA
HCM-PY A Average/year 8 18 2 4 1 CANAL CLIMA
HCM-PY P Peak time 12 17 4 8 0 CANAL CLIMA
MM-PUR A Average/year 8 18 4 8 1 CANAL CLIMA
MM-PUR P Peak time 8 18 4 8 0 CANAL CLIMA
TV-RECEIPT A Average/year 8 18 2 4 1 CANAL CLIMA
36 72 6 CANAL CLIMA
CO A Average/year 8 18 4 8 1 VALOREM
CO P Peak time 12 13 21 53 0 VALOREM
FIN-BAC A Average/year 8 18 4 8 2 VALOREM
FIN-BAC P Peak time 12 13 16 41 0 VALOREM
HCM-PT A Average/year 8 18 2 4 1 VALOREM
HCM-PT P Peak time 8 18 4 8 0 VALOREM
HCM-PY A Average/year 8 18 4 8 1 VALOREM
HCM-PY P Peak time 8 18 4 8 0 VALOREM
MM-IM P Peak time 12 13 4 8 0 VALOREM
MM-PUR A Average/year 8 18 4 8 1 VALOREM
MM-PUR P Peak time 12 13 13 33 0 VALOREM
80 187 6 VALOREM
58
24 Marzo 2014
3.3.4.7. Lecciones Aprendidas
Es importante aclarar algunos conceptos que son importantes para el diligenciamiento del sizing según lo
que se ha visto en experiencias pasadas:
▪ Diligenciar los dos tipos de elementos de sizing:
▪ Promedio Anual
▪ Pico por Periodo
▪ No se tiene el mismo concepto por cada elemento de sizing o del contenido que deben ingresar
▪ Menos tiempo para un proceso de negocio significa más requerimientos de maquina (CPU,
Memoria, Disco)
▪ El pico corresponde al día del año donde se procesan más documentos, donde deben indicar las
horas en que se procesa, esto no corresponde a un promedio
▪ Sí un proceso de negocio se repite en diferentes horas del día, se puede configurar esta
representación en el quicksizer
59
24 Marzo 2014
4. BITÁCORA DE AJUSTES
VER FECHA AUTOR REVIEWER/APROBADOR OBSERVACIONES
1.0 Marzo 31, 2014 Eduardo Contreras Fernando Gaitan Primera versión.
60
24 Marzo 2014

GVAL-SIS-EN-Arquitectura Tecnica v1 0

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

GVAL-SIS-EN-Arquitectura Tecnica v1 0

Cargado por

Copyright:

Formatos disponibles

TECHNICAL PROCESS DESIGN

Proyecto: Frente de Sistema Escenario de Negocios

Fecha Versión Documento Descripción Revisión Documento Autor

6 Febrero 2014 1.0 Eduardo Contreras

Nombre Cargo Fecha Aprobado

IDENTIFICACIÓN DE DOCUMENTO ................................................................................................................................ 1

1.2. Enfoque y alcance

▪ SAP ECC será el aplicativo donde se centralizara el Backoffice

Es el modelo que describe los componentes de aplicaciones y servicios.

2.1. Esquema general

Ilustración 1 - Esquema General

2.2. Fases & Olas

▪ Existen alrededor de 40 empresas que necesitan salir en vivo para el 31 de Diciembre

▪ Se va a implementar Identity Management y Federación de Dominios

Componente Desarrollo Calidad Producción

2.4. Fases Posteriores

Ilustración 5 – Fases Posteriores a la Fase I

Componente Desarrollo Calidad Producción

▪ Existen alrededor de 40 empresas que se configurarán en un solo mandante

En la “Ilustración 6 - Mandante" podemos observar que el “Customizing Independiente de Mandante” y el

2.5.3.1. Sistema Único-Mandante:

2.5.3.2. Sistema Multi-Mandante:

SAP SAP SAP SAP SAP SAP

 1 sistema  1 sistema  Varios sistemas

2.5.4.2. Pros & Contras

UNICO- ▪ Control Central ▪ Complejidad de implementación global

MULTIPLES ▪ Control Central ▪ No existe sinergia

2.5.4.3. Gestión del Cambio

SOLUTION MANAGER (CTS+)

Ilustración 8 - Gestión del Cambio

▪ Existirá un comité de cambios

DESARROLLO CALIDAD PRODUCCION

▪ La actualización de desarrollos y/o parametrización al ambiente de Calidad se debe realizar

▪ Es requisito indispensable el diligenciamiento del formato “GVAL-SIS-FR-

2.5.3.4. Nomenclatura de Transportes

2.5.3.5. Administración de Transportes

El CTS+ puede transportar:

▪ Objetos de tipo SAP NetWeaver Portal (EP)

▪ Objetos Non-ABAP de tipo SAP NetWeaver PI/PO (Process Integration/Process Orchestration):

Las excepciones o limitaciones a esta información se documentan en la nota SAP 1003674.

2.5.4.4. Mandantes Estándar

Cliente Nombre Descripción

Mandante 001 (Ejemplo - SAPS):

Mandante 066 (EarlyWatch - SAPE):

2.5.4.5. Mandantes No-estándar

Cliente Ambiente Nombre Descripción

Mandante 100 (Customizing - VED):

En este mandante no debe ser ingresarse data maestra o transaccional.

Mandante 110 (Pruebas Unitarias - VED):

Mandante 120 (Sandbox - VED):

Mandante 130 (Migración de Datos - VED):

Mandante 300 (Pruebas Integrales - VEQ):

Mandante 400 (Entrenamiento - VEQ):

Mandante 300 (Producción - VEP):

2.5.4.6. Configuración de los Mandantes

2.5.4.6.1. Configuración Mandantes Ambiente Desarrollo

Configuración Customizing (100) Unitarias (110) Sandbox (120) Datos (130)

Changes to Changes to Repository No changes to No changes to No changes to

2.5.4.6.2. Configuración Mandantes Ambiente Calidad

Configuración 300 (Calidad) 400(Training)

Changes to cross-client objects No changes to Repository and No changes to Repository and

2.5.4.6.3. Configuración Mandantes Ambiente Producción

Configuración 300 (Producción)

Changes to client-specific objects No changes allowed