Você está na página 1de 68

FACULTAD DE INGENIERÍA

Carrera de Ingeniería Informática y de Sistemas

OPTIMIZACIÓN DEL RENDIMIENTO DE LA


INFRAESTRUCTURA TECNOLÓGICA DEL ERP
SAP DE UNA EMPRESA AUTOMOTRIZ

Trabajo de Suficiencia Profesional para optar el Título


Profesional de Ingeniero Informático y de Sistemas

CECILIA NERIDA IBAÑEZ CAMPOS

Asesor:
Mg. Martin Sebastián Gonzales

Lima – Perú
2018
INDICE

INTRODUCCION ...........................................................................................................1
DESARROLLO ...............................................................................................................3
GENERALIDADES DE LA EMPRESA.......................................................................3
Datos Generales .............................................................................................................3
MITSUI EN EL MUNDO ............................................................................................... 5
Nombre y Razón social de la empresa. ..........................................................................5
Ubicación de la empresa (dirección, teléfono y mapa de ubicación). ........................... 5
Giro de la empresa. ........................................................................................................6
Tamaño de la empresa ...................................................................................................6
Breve reseña histórica de la empresa .............................................................................6
Organigrama de la empresa ........................................................................................... 6
Misión, Visión y Política ............................................................................................... 7
Productos y Clientes ......................................................................................................7
Premios y Certificaciones .............................................................................................. 8
Relación de la empresa con la sociedad .........................................................................8
PLANTEAMIENTO DEL PROBLEMA QUE FUE ABORDADO ......................... 10
Caracterización del área que participo .........................................................................10
Antecedentes y definición del problema ......................................................................10
Objetivos: General y específicos .................................................................................15
Justificación .................................................................................................................16
Alcance y limitaciones .................................................................................................16
MARCO CONCEPTUAL............................................................................................. 17
DESARROLLO DEL PROYECTO ............................................................................26
Metodología para el Desarrollo de la Tesis .................................................................26
ANALISIS Y RESULTADOS ...................................................................................... 42
Indicadores de Mejora.................................................................................................42
CONCLUSIONES .........................................................................................................46
RECOMENDACIONES ............................................................................................... 47
REFERENCIAS ............................................................................................................48
ANEXOS ........................................................................................................................ 49
INDICE DE TABLAS

Tabla 1 Comparativo Tiempos – Servicio Express ......................................................... 12


Tabla 2 Identificación de Causas – Diagrama Ishikawa ............................................... 14
Tabla 3 Distribución de Arquitectura – ERP SAP ......................................................... 29
Tabla 4 Análisis de tiempos en las transacciones Estándares ....................................... 32
Tabla 5 Análisis de tiempos en las Sentencias TOP ....................................................... 32
Tabla 6 Análisis de Nodos Usuarios SAP....................................................................... 33
Tabla 7 Análisis de Red - SAP - MITSUI........................................................................ 34
Tabla 8 Análisis Parámetros SAP .................................................................................. 34
Tabla 9 Análisis de tiempos en las transacciones Estándares ....................................... 35
Tabla 10 Especificación Técnicas – Nuevo Hardware MITSUI..................................... 39
Tabla 11 SLO Proveedor de Hosting.............................................................................. 52
Tabla 12 Indicadores de performance SRV PRD Dic 2009 ........................................... 59
Tabla 13 Medido de usuarios en el Sistema Actual SRV PRD Dic 2009 ....................... 60
Tabla 14 Medido de usuarios SRV PRD 2006 ................................................................ 60
Tabla 15 Comparativo Infraestructura Inicial vs Infraestructura Final ........................ 62
INDICE DE FIGURAS

Figura 1. Venta e Inmatriculación de Vehículos Livianos (ene-dic 2017) ...................... 3


Figura 2. Market Share Concesionarios Toyota del Perú - Nacional .............................. 4
Figura 3. Market Share Concesionarios Toyota del Perú – Lima. ................................... 4
Figura 4.Ubicación de Mitsui –Local Principal – La Molina. ......................................... 5
Figura 5. Organigrama MITSUI AUTOMOTRIZ año 2010 - Gerencias ....................... 6
Figura 6. Organigrama MITSUI AUTOMOTRIZ - Sistemas año 2010 ....................... 10
Figura 7. Fotografía Taller – Servicio Express .............................................................. 11
Figura 8. Diagrama de Flujo – Servicio Express ........................................................... 12
Figura 9. Diagrama Ishikawa – Servicio Express .......................................................... 13
Figura 10. Árbol de Problemas – Servicio Express ....................................................... 15
Figura 11. Metodología ASAP ...................................................................................... 18
Figura 12. Hoja de trabajo análisis de procesos ............................................................. 21
Figura 13. Símbolos Diagrama de flujo ......................................................................... 21
Figura 14. Matriz Urgencia / Impacto del Proveedor de Hosting .................................. 24
Figura 15. Ciclo de Vida del Servicio ............................................................................ 26
Figura 16.Actividades de Incidencia /Problema y RFC–Degradación de Performance 38
Figura 17. Cumplimento SLA - Feb 2011 – Jul 2011. ................................................. 42
Figura 18. Uso Promedio Procesador Diario Jul 2011. ................................................ 43
Figura 19. Uso Promedio Procesador Mensual Jul 2011. ............................................. 44
Figura 20. Uso Promedio Memoria Diario Jul 2011. ................................................... 44
Figura 21. Uso Promedio Memoria Mensual Jul 2011. ............................................... 45
Figura 22. Porcentaje Histórico Uso FileSystem Jul 2011. .......................................... 45
Figura 23. Diagrama de proceso y actividades – Servicio Express ............................... 49
Figura 24. Proceso de Gestión de Incidentes ................................................................. 50
Figura 25. Proceso de Gestión de Problemas................................................................. 51
Figura 26. Tiempo de Respuesta SRV PRD Dic 2009 .................................................. 58
Figura 27. Tiempo de Pasos de dialogo SRV PRD Dic 2009 ........................................ 59
Figura 28. Diagrama de Red y Comunicaciones ........................................................... 61
Figura 29. Diagrama de Red y Comunicaciones entre Sedes ........................................ 61
1

INTRODUCCION

En la actualidad, las empresas buscan mantenerse competitivas en el mercado,


optimizando sus procesos y servicios hacia el cliente. La manera de alcanzar estos
objetivos se da bajo la adquisición de recursos tecnológicos que soportan sus procesos,
siendo la mayoría de ellos los que se desarrollan bajo sistemas de planificación de
recursos empresariales llamados también ERP’s; El principal objetivo de un ERP es
brindar a la empresa apoyo en los procesos administrativos, tiempo de respuesta
oportunos, mejor toma de decisiones, consolidar la información, ahorro dentro de los
costos totales de la operación y centralizar la información dentro de la organización.

La implementación del ERP SAP en MITSUI AUTOMOTRIZ se realizó a inicios


del 2006, siendo la implementación desarrollada por una consultora SAP y el servicio de
hosting SAP con un proveedor de servicio hosting, el cual fue adaptado por primera vez
en Perú a la industria automotriz.

El presente informe de tesis describe la solución al problema que presento la


empresa a finales del año 2009 cuando el área de servicios de MITSUI lanzó el servicio
de mantenimiento express (Mantenimiento preventivo vehicular periódico realizado en
menos de 1 hora), donde el cliente espera por su vehículo en los ambientes
acondicionados denominados “VIPs”. Este servicio se vio afectado en las tareas de
recepción y entrega de los vehículos en el proceso de servicio de mantenimiento express
causando lentitud en dichas actividades, así como el deterioro del desempeño del sistema
ERP SAP, en referencia a su capacidad, continuidad y disponibilidad del servicio; Esto
afectó al usuario final causando malestar y reclamos reiterados en los clientes por no
cumplir con el tiempo establecido por la promoción, así como también se evidenciaba
gastos no planificados, debido al alto número de promociones que la empresa asumía el
costo de los servicios al no cumplir con la promoción “ Sino está listo en una hora el
servicio es gratis”.

El análisis del problema se realizó estableciendo en primera instancia el mapa de


procesos a fin de lograr entendimiento sobre la estructura y articulación de los mismos,
así como también el uso de las herramientas de análisis de procesos: Diagrama de
2

Ishikawa y Diagrama de árbol; Una vez identificado el problema “Demasiado tiempo de


espera en la recepción/entrega del vehículo en el servicio express”.
Dicho análisis finalmente condujo a la validación y optimización de la
infraestructura tecnológica del ERP SAP (SAP ALL IN ONE); Esta validación tuvo como
consecuencia el análisis detallado de los dos frentes que tenía el ERP SAP, por el servicio
de asistencia técnica del aplicativo (ERP- SAP) y el servicio Hosting a nivel de
infraestructura tecnológica; ambos servicios con diferentes proveedores.
3

DESARROLLO

GENERALIDADES DE LA EMPRESA
Datos Generales
Sector Automotor : El sector automotor se divide en tres tipos:
 Vehículos Menores (Motocicletas y Trimotos).
 Vehículos Livianos (Automóviles, Station Wagon, SUV, Camionetas hasta
16 pasajeros, Pick Up).
 Vehículos Pesados (Camiones, Tractocamiones y Buses).

Toyota del Perú (TDP) actualmente cuenta con una participación del 18.1% en los
vehículos livianos a nivel nacional.

Según las últimas cifras publicadas por la Asociación de Automotores del Perú en
el año 2017 los vehículos nuevos y su inmatriculación en registros públicos fueron de
163, 668 unidades (Ver Figura 1.1)

Figura 1. Venta e Inmatriculación de Vehículos Livianos (ene-dic 2017)


Fuente: Asociación Automotores del Perú – SUNAT
4

Mitsui Automotriz S.A es el concesionario líder de Toyota en el Perú (TDP),


cuenta en la actualidad con un mercado objetivo de 47.9 % en Lima y 35.8 % a nivel
nacional. (Ver figura 1.2 y 1.3)

Figura 2. Market Share Concesionarios Toyota del Perú - Nacional


Fuente: Mitsui

Figura 3. Market Share Concesionarios Toyota del Perú – Lima.


Fuente: Mitsui
5

MITSUI EN EL MUNDO
Mitsui &Co. es una empresa que presta múltiples servicios de comercialización
global. Es uno de los conglomerados más grandes de Japón, desempeñándose como una
"Sogo Shosha", que significa "compañía de comercio integral". Al ser la primera empresa
en instituir este tipo de organización comercial posteriormente adoptada por otras
empresas, se caracteriza por contar con una amplia variedad de productos y servicios con
un gran valor agregado, que cubren las diversas industrias del mercado, de acuerdo a las
cambiantes necesidades del mundo comercial de nuestro tiempo.
HITOS:
1673 El Sr. Takatoshi Mitsui inicio su tienda de kimono en Edo
1876 La antigua Mitsui & Co se estableció como la primera compañía japonesa de
comercio.
1947 Se establece Daiichi Bussan Kaisha, Ltd (Inicio de la nueva Mitsui & Co).
1959 Cambia su razón social a Mitsui & Co, Ltd
Nombre y Razón social de la empresa.
Nombre: MITSUI AUTOMOTRIZ
Razón Social: MITSUI AUTOMOTRIZ S.A
Numero de RUC: 20256211310
Tipo de Contribuyente: SOCIEDAD ANONIMA
Ubicación de la empresa (dirección, teléfono y mapa de ubicación).
Mitsui en la actualidad cuenta con seis (6) locales comerciales, distribuidos en
lima y provincias; Donde la oficina Principal se encuentra ubicada en el distrito de la
Molina, en la dirección, Av. Javier Prado Este Nro. 6042 Urb. San Cesar; Central
Telefónica: (511) 6253000.

Figura 4.Ubicación de Mitsui –Local Principal – La Molina.


Fuente: Google Maps.
6

Giro de la empresa.
Según SUNAT, la empresa cuenta con las siguientes actividades económicas:
 Venta de Vehículos y automotores
 Mantenimiento y reparación de vehículos automotores
Incorporado en el régimen de Buenos Contribuyentes en el 2017, agentes de
retención de IGV en el año 2002 y excluido de régimen de agente de percepción de IGV
– Venta Interna en el año 2016.
Tamaño de la empresa
Mitsui Automotriz es considerada una empresa grande, la cual cuenta con lo
presencia local y Mundial distribuida de la siguiente manera.
Presencia Local:
Empleados: 650 empleados y Ventas anuales: 500 MM de soles.
Presencia Mundial:
Mitsui & Co con presencia en 67 países y 151 oficinas, donde cuenta con 410
subsidiarias y asociadas, activos totales por 101.7 billones de dólares y 45, 148
empleados consolidados.
Breve reseña histórica de la empresa
Mitsui Automotriz S.A. es una empresa de capital japonés que opera en el Perú
desde 1971 comercializando vehículos y repuestos originales Toyota.
Es en la actualidad es considerado el concesionario líder de la marca Toyota en el
Perú, ofrece una cadena de productos y servicios completa, dentro del rubro automotriz.
Los altos estándares alcanzados en todos sus procesos lo han llevado ser considerados
modelo de concesionario en el mundo.
Organigrama de la empresa

CEO

DIRECTORIO

CONTABILIDAD Y
LEGAL PLANIFICACION ADMINITRACION VENTAS POST - VENTAS
FINANZAS

CONTROL INTERNO

SISTEMAS

Figura 5. Organigrama MITSUI AUTOMOTRIZ año 2010 - Gerencias


Elaboración: Propia.
7

Misión, Visión y Política


MISIÓN
Su misión está dirigida en tres aspectos, como concesionario de Toyota en el Perú,
como Filial de Mitsui & Company y como empresa del Perú, descritas respectivamente:

COMO CONCESIONARIO DE TOYOTA EN EL PERÚ


Concesionario Nro. 1 para contribuir a Toyota en el Perú.
COMO FILIAL DE MITSUI & CO
Concesionario automotriz modelo de Mitsui & CO en el mundo.
Contribuir a la cadena de valor conjuntamente con Toyota del Perú y MAF.
COMO EMPRESA DEL PERÚ
Empresa que contribuye al desarrollo del País.
VISIÓN
“Ser reconocida como la empresa automotriz líder, focalizada en el cliente con un
equipo humano integrado, altamente capacitado y motivado”.
POLITICA
La política de Mitsui Automotriz está basada en los siguientes valores:
Cliente Primero: “Comprender a plenitud a los clientes y diferenciarnos en lo esencial
otorgando un servicio de calidad”.
Autodisciplina: “Compromiso y determinación de hacer las cosas correctas.
Cumplimiento de normas, procedimientos, principios y valores de la empresa. Valor de
vida que nos ayuda a trabajar con prevención. Una buena reputación es fundamental para
que los negocios se lleven a cabo, y solo a través de un debido cumplimiento pueden
mantenerla.”
Mejora Continua –Kaizen: El mejoramiento continuo de sus procesos para alcanzar la
excelencia; Mejora continua en la búsqueda de ser más eficientes, comprometidos con la
frase “Hoy mejor que ayer, mañana mejor que hoy”
Productos y Clientes
Productos:
1. Venta de Vehículos Nuevos, Usados.
2. Alquiler de Vehículos y Soporte de Flotas. (Leasing o Renting).
3. Venta de Repuestos.
4. Carrocería y Pintura.
8

5. Mantenimiento Preventivo y Express.


Clientes:
Existen (2) tipos de clientes:
Cliente Mostrador, es el cliente eventual (Natural / Jurídico), el cual toma
cualquiera de los servicios de venta de vehículo, venta de repuesto, alquiler,
mantenimiento y/o carrocería y pintura.
Cliente Flota, Son aquellos clientes por lo general compañías (Jurídicos) que
toman los servicios de venta de vehículo, venta de repuesto, alquiler, mantenimiento y/o
carrocería y pintura para una cierta cantidad de unidades.
Premios y Certificaciones
Cuenta con las certificaciones de Toyota, tales como:
 TSM Kodawari (Toyota Customer Service Workshop Management)
 TSM Advanced (exclusivo para concesionarios con servicio de mantenimiento
express)
 DERAP (Dealer Environmental Risk Audit Program) por el cuidado al medio
ambiente.
 Personal Técnico capacitado con calificación TMC (Toyota Motor Corporation
del Perú).
Asimismo, Mitsui Automotriz ha recibido una serie de premios en los concursos
organizados por Toyota del Perú de manera anual donde premian el nivel de atención en
la venta de vehículos, servicios post-venta y premios de habilidad mecánica a nivel
Nacional.

Relación de la empresa con la sociedad

La satisfacción de sus clientes es el pilar de sus operaciones. “Cliente Primero”


supone considerar la experiencia total del cliente, desde el momento de la compra,
pasando por la experiencia de conducción y de uso, hasta el momento de reciclaje del
vehículo. Miden la satisfacción del cliente a través de los concesionarios, esto exige que
tengan en cuenta lo que ocurre en cada eslabón de la cadena de valor.
Consideran en todos los procesos la prevención y planificación actividades
inherentes en cada actividad que realizan dentro y fuera de sus instalaciones para asegurar
de esta manera la seguridad y salud operacional de sus colaboradores.
9

Para Mitsui es importante la armonía con el medio ambiente donde se desarrollan


sus actividades es por esta razón que mantienen un control exhaustivo de los residuos
peligrosos que se generan hasta la disposición final del mismo.
Tienen el compromiso de aportar el desarrollo sostenible de las comunidades
vecinas donde se encuentran presentes, parte de este compromiso es brindar oportunidad
laboral en los talleres mineros a jóvenes con espíritu de crecimiento y desarrollo
10

PLANTEAMIENTO DEL PROBLEMA QUE FUE ABORDADO

Caracterización del área que participo

Durante el desarrollo del proyecto, me desempeñe como Analista de Sistemas


dentro del Área de Sistemas, el cual pertenecía a la gerencia de administración.
El cargo que desempeñaba en el proyecto era de gestor técnico de las cuentas de
SAP y Hosting.
CEO

DIRECTORIO

CONTABILIDAD Y
LEGAL PLANIFICACION ADMINITRACION VENTAS POST - VENTAS
FINANZAS

CONTROL SISTEMAS

JEFATURA

ANALISTA 1

ANALISTA 2

Figura 6. Organigrama MITSUI AUTOMOTRIZ - Sistemas año 2010


Elaboración: Propia.
Antecedentes y definición del problema

MITSUI AUTOMOTRIZ, implemento el ERP SAP en el año 2006, con una


inversión aproximadamente de 1M de dólares.
Eran finales del año 2009, época en cual la empresa se encontraba en una etapa de
expansión de locales en lima y provincias y tendría la exclusividad de la nueva marca de
lujo (LEXUS) en la oficina principal.
El área de Servicios lanzó el servicio de Mantenimiento Express, servicio de
mantenimiento periódico realizado en menos de 1 hora, donde el cliente espera
cómodamente en una sala de espera.
Este servicio del punto de vista de producción adoptaba el concepto del Sistema
de Producción Toyota, basados en su filosofía y tenía como objetivo principal la
11

satisfacción del cliente al 100%; Hacia uso de un equipamiento especial donde un equipo
de 3 técnicos se encarga exclusivamente del mantenimiento del vehículo.
Este servicio Express, solo se realizaba para el mantenimiento de los modelos
Yaris, Corolla y Avensis, en los mantenimientos de 5,000 a 100,000 Kms; donde el
costo del servicio promedio se encontraba en el rango de S/. 300 a S/1500.

Figura 7. Fotografía Taller – Servicio Express


Fuente: Mitsui.
Este servicio express se vio afectado, cuando se producían tiempos de espera
prolongados en la atención de los vehículos que ingresaban o retiraban por dicho
mantenimiento; Este tiempo de espera se reflejaba en una lentitud excesiva del tiempo
estipulado del servicio (una hora) en los horarios denominados “pico” en las mañanas
(7:00 – 10:00) y en las tardes (4:00 – 6:00), donde el cliente ingresaba o retiraba el
vehículo por servicios de mantenimiento express.

Las consecuencias de este problema, se identificaron a través de reclamos


reiterados de los clientes porque el servicio no cumplía con el tiempos estipulados, hubo
impactos monetarios debido que la promoción indicaba “Su TOYOTA listo en una hora
o el servicio es Gratis” por lo que la empresa estaba asumiendo dichos costos; Se generó
una mala imagen del servicio, además la empresa había invertido en elementos de
Marketing en los principales medios de comunicación (prensa escrita, radio y eventos
12

institucionales), por lo que esto se traducía a gastos no planificados o perdida de inversión


esperada.
Para poder identificar los responsables de cada actividad, resultados y aspectos
relativos al proceso “servicio de mantenimiento express”, se utilizó las herramientas de
análisis : Hoja de trabajo para el análisis de procesos (Ver Anexo 1) que permitió
validar las actividades que generaban cuellos de botella, así como también permitió
elaborar el Diagrama de Flujo del proceso del servicio express , generando un cuadro
comparativo del antes y después (del problema) para cuantificar los tiempos de atrasos
identificados dentro del proceso.

Figura 8. Diagrama de Flujo – Servicio Express


Elaboración: Propia

El diagrama de flujo permitió identificar los cuellos de botella que se daban en


las actividades: realizar recepción de vehículos y realizar entrega de vehículos, donde
ambas generaban un documento físico de orden de servicio y documento de pago
respectivamente al momento de interactuar con el sistema del ERP (MySAP ALL in One).
Tabla 1
Comparativo Tiempos – Servicio Express

ANTES DESPUES (CON EL


PASO SIMBOLO PROBLEMA)
PASOS MINUTOS PASOS MINUTOS
13

OPERACION
5 28 min. 5 28 min.

TRASLADO
2 35 min. 2 35 min.

DEMORA
0 0 min. 2 20 min.

VERIFICACION
2 7 min. 2 7 min.

ARCHIVO
1 2 min. 1 2 min.

TOTAL 10 72 min. 12 92 min.

Elaboración: Propia

Como se puede observar en el comparativo, el proceso del servicio express, tenía


un incremento del 28%, donde se identificaba dos actividades con tiempo de espera mas
elevados de lo habitual, esto ocasionaba una demora significativa en el tiempo de ciclo
de vida del proceso, que al momento del problema contaba con 20 minutos adicionales.
Una vez identificado los cuellos de botella del proceso, se planteó realizar la
identificación del problema mediante el Diagrama CAUSA - EFECTO o Diagrama
ISHIKAWA, la finalidad de esta herramienta fue ayudar a detectar los diferentes tipos de
causas que influían en el problema de “Demasiado tiempo de espera en la atención de
vehículos en el servicio express”, para de esta manera seleccionar los principales y
jerarquizarlos.

Figura 9. Diagrama Ishikawa – Servicio Express


Elaboración: Propia
Para este análisis de Ishikawa, se determinó los siguientes pasos:
Definición del Problema:
Demasiado tiempo de espera en la atención de vehículos en el servicio express.
Determinación del conjunto de causas:
14

 Infraestructura Tecnológica
 ERP – SAP
 Personal
 Infraestructura Operativa

Participación de los integrantes del grupo en una sesión de lluvia de ideas:


Las personas que participaron en esta lluvia de ideas pertenecían a las áreas de
Servicios y Sistemas conformado por equipo técnico de infraestructura y aplicación,
equipo operativo del negocio y gestión de TI.
Revisión de ideas
De la revisión realizada, se identificó que el problema estaba relacionado con el
desempeño del ERP, el cual tenía como posibles causas la infraestructura tecnológica o
el aplicativo (ERP - SAP). Sobre estas (2) causas se basó el análisis y desarrollo del
proyecto.
Mitsui contaba con contratos de servicios para el tema de la infraestructura
tecnológica con un servicio de hosting que adquirió en el año 2006 con un proveedor de
servicio hosting y para el tema del aplicativo con un proveedor de soluciones integrales
de negocio y tecnología de información con los servicios de: asistencia técnica,
consultoría y mejora continua del ERP SAP; Se tuvo que realizar un análisis en paralelo
de ambos proveedores para determinar cuál era la causa del problema y plantear la
solución. Del análisis se identificaron las posibles causas del problema, estas se analizarán
en mayor en detalle en el capítulo de desarrollo del proyecto:

Tabla 2
Identificación de Causas – Diagrama Ishikawa
15

INFRAESTRUCTURA TECNOLOGICA ERP -SAP


Escalabilidad Limitada Ajustes de parámetros pendientes en el aplicativo
(performance tunning)
Ajustes de parámetros pendientes en la plataforma Programación deficiente en programas no estándares.
(afinamiento de desempeño)
Enlace de Red Saturado Falta de aplicación de Notas OSS recomendadas por
SAP
Falta de monitoreo en los umbrales de los componentes No se realiza la aplicación de parches de kernel.
(tiempo de respuesta, crecimiento de Base de Datos,
Utilización de procesadores, etc.)
Tareas paralelas ejecutándose (horario de antivirus, Tareas paralelas ejecutándose (Jobs diarios).
sistema de backup).

Elaboración: Propia

Adicionalmente, complementando al diagrama de Ishikawa se elaboró el


diagrama de árbol que confirmó el problema planteado.

Disminución de la
Perdida de Utilidad Personal Desmotivado
participación del mercado

Costos asumidos por la


Perdida de Imagen de la Cliente Insatisfecho por el
empresa al no cumplir la
empresa servicio
promoción

Tiempo de espera > a 15 minutos en la recepcion / entrega del


Vehiculo en el servicio express

No se cumple con los


Aumento de quejas y Deterioro del desempeño del
parámetros de la
reclamos hechos por cliente. sistema (lentitud excesiva)
promoción de 1 hora.

Figura 10. Árbol de Problemas – Servicio Express


Elaboración: Propia

Objetivos: General y específicos


Objetivo General
16

Optimizar los procesos relacionados en el servicio de mantenimiento express para


alcanzar la satisfacción del cliente en la hora pactada.
Objetivos Específicos

 Reducir el tiempo de espera a 20 minutos para las tareas de recepción y salida de


vehículos en el servicio de mantenimiento express.
 Comprobar que las tareas del servicio express estén dentro de los parámetros de
la hora pactada.
 Certificar la efectividad del servicio express realizando validaciones de
rentabilidad en dicho servicio.
 Planificar la correcta escalabilidad y disponibilidad de los sistemas que
intervienen en el servicio express, asegurando que estos parámetros sean
utilizados en el momento requerido.

Justificación
El Deterioro del desempeño (performance) del sistema ERP SAP en el proceso de
atención al cliente del servicio express, representaba para la empresa perdida de manera
monetaria y deterioro de imagen de los servicios que se brindaban.

Alcance y limitaciones
Alcance: Proceso de atención al cliente del servicio express del departamento de
servicios.
Limitaciones:
 Las limitaciones están referidas por la disponibilidad de horarios y personal del
servicio para realizar: el análisis, diseño, ajustes requeridos al sistema y pruebas
de usuario y capacidades de los equipos involucrados
 Se contaba con un horario: 8:00 am – 6:00 pm, para los trabajos y/o pruebas.
 Disponibilidad de usuarios para pruebas: 1 por el área de servicios.
 Horario de Ventana al sistema (Ajustes y reinicios): A partir de las 9:00 pm. Hasta
las 2:00 am.
17

MARCO CONCEPTUAL

ERP
ERP, siglas en Ingles de Enterprise Resource Planning (Planificación de recursos
empresariales) son sistemas de gestión de información que automatizan muchas de las
prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa,
básicamente es una arquitectura de software para empresas que facilita e integra la
información entre las diversas operaciones de la empresa (ventas, finanzas, compras, rrhh,
comercio electrónico, etc.).
Actualmente, un ERP se ha convertido en un aspecto diferenciador y con valor a
través del tiempo para las empresas que lo implementan, asimismo es un factor
importante en la elaboración y gestión de una estrategia empresarial debido que ahorra
tiempo y dinero.
El uso de un ERP, permite a la organización los siguientes beneficios:
 Apoyo en los procesos administrativos.
 Optimizar el Tiempo de respuesta.
 Mejorar la toma de decisiones.
 Consolidar la información.
 Ahorro (Personas, Sistemas).
 Centralización de la información.
SAP
SAP siglas en ingles de Systems, Applications, Products in Data Processing
(Sistemas, Aplicaciones y Productos en Procesamiento de datos), SAP fue creado en
Alemania por ex ingenieros de IBM a finales de los años 70, en la actualidad es la mayor
compañía mundial del negocio del Software con más de 1000 procesos de negocios
consideradas las mejores prácticas empresariales por eso es considerado como primera
elección de un sistema de negocios.
SAP es un sistema informático basado en módulos integrados, que abarca todos
los aspectos de la administración empresarial de forma simple, robusta y fiable; donde la
información se comparte entre todos los módulos implementados que la necesiten y que
tengan acceso a ella de manera oportuna.
18

SAP en el Perú
Al tener una enorme gama de módulos, no solo la gama estándar de contabilidad
sino también módulos de compras, ventas, distribución, producción, servicio al cliente,
recursos humanos, CRM; todos integrados con el sistema contable central, motivó a las
organizaciones nacionales optimizar sus procesos y de esta manera unificar en un solo
sistema las operaciones con el fin de estar a la vanguardia de las organizaciones a nivel
mundial.
Beneficios:
 Mejora la coordinación de las estrategias y las operaciones de la organización.
 Escalabilidad e innovación.
 Permite identificar y retener al personal que ofrece un mayor rendimiento.
 Optimizar el gasto en TI.
 Proporciona acceso inmediato a información empresarial
Metodología ASAP
ASAP es la solución de SAP, para acelerar los proyectos de implantación. ASAP
optimiza tiempo, calidad y una utilización eficiente de los recursos focalizándose en los
elementos que hacen una implantación exitosa.

Figura 11. Metodología ASAP


Fuente: Internet Gráficos “ASAP”
19

Transacción en SAP
El termino transacción, es referido como el procesamiento de un grupo de
unidades que provee una función específica. Las cuales tienen cuatro principales
características; la letra inicial de estas características forman el acrónimo (ACID).
ACID es un conjunto de características o propiedades que garantizan que las
transacciones en una base de datos son fiables. En el contexto de bases de datos, una
transacción es una única operación sobre los datos.
 Atómico (Atomic), esta propiedad asegura que una operación se realiza o no se
realiza, por lo tanto no puede quedar el sistema a medias, donde cualquier cambio
que produce una transacción es atómico.
 Consistente (Consistent), propiedad que asegura que una transacción, no romperá
la integración de la base de datos.
 Aislado (Isolated), propiedad que asegura que no afectaran entre si las
transacciones.
 Durable (Duradero), propiedad que asegura la persistencia de una transacción, es
decir, una vez que la transacción quedó aceptada no podrá deshacerse aunque falle
el sistema.
Un ejemplo de una transacción simple es la creación de datos maestros (clientes,
proveedores, etc.), una transacción más compleja es la transferencia de fondos de una
cuenta a otra, la cual implica múltiples operaciones individuales.
Jobs en SAP
Jobs son un conjunto de uno o más programas que se lanzan consecutivamente en
proceso de fondo en SAP. En el ambiente SAP, un proceso de fondo es considerado
procesos no interactivos, que se ejecutan detrás de las operaciones interactivas normales
sin afectar los tiempos de interactivos de procesamiento habitual del sistema, estos pueden
ser programados y priorizados según su ejecución (Alta, media o baja).
Ventajas del uso de Jobs:
 Reduce el esfuerzo manual y automatiza la tarea.
 El tiempo de procesamiento es ilimitado.
 Puede ser programado.
 Reduce la interacción del usuario y se puede ejecutar sin problemas en segundo
plano sin intervención del usuario.
20

 Ideal para los programas que requieren mucho tiempo / uso intensivo de recursos
que pueden ser programados para ejecutarse en horario extendido (cuando la
carga del sistema es baja).

Índices en SAP
Los índices son estructura de datos que mejora la velocidad de las operaciones, el
cual permite un rápido acceso a los registros de una tabla en una base de datos.
Se crean índices sobre una tabla de diccionario de programación en SAP cuando
en uno de los programas nos vemos obligados a realizar búsquedas de información, pero
el acceso a dicha información no se encuentra como campo clave referenciado en la
misma tabla.
Transacciones Estándares y Zetas (Z’s):
Existen dos tipos de transacciones en SAP:
Las transacciones estándar que son las que vienen por defecto en la instalación del
software y las transacciones a medida o también denominadas transacciones “Z”.
Los 2 tipos de transacciones se identifican en SAP por un nombre y por un código
alfanumérico.
Las transacciones Z son desarrolladas por cada organización, es decir, que no
vienen por defecto con la instalación del software sino que es la empresa quien desarrolla
una transacción para realizar una actividad específica del proceso empresarial. Estas
transacciones, como bien su nombre indica siempre empiezan por Z. Algunos ejemplos
son: ZSD003 (Reporte de Ventas), ZSD38 (Pantalla rápida de creación de Pedidos y
Órdenes de Servicio).
Hoja de trabajo para el análisis del proceso (SER y DEBE SER)
Esta herramienta nos permite identificar de manera gráfica aquellas actividades
del proceso que no agregan valor y las áreas de oportunidad de para implementar acciones
de mejora.
En la hoja de trabajo para el análisis de procesos (SER y DEBE SER) se registra
a todas las actividades al proceso y se aplica el criterio de valor agregado, a fin de detectar
desperdicio del proceso, eliminar actividades que no agreguen valor, optimizar las que
agreguen valor e identificar actividades donde se presentan problemas.
21

Para la aplicación de esta herramienta se utilizan diferentes símbolos que


representaran el tipo de actividad que se realiza, con los cuales analizaremos las
actividades del proceso.

OPERACIÓN VERIFICACION

TRASLADO ARCHIVO

DEMORA CORRECCION R

Figura 12. Hoja de trabajo análisis de procesos


Fuente: Propia
La mecánica de aplicación de esta herramienta consiste en:
 Diagramar el proceso y listar sus actividades
 Identificar el tipo de operación que se realiza en cada actividad (operación,
traslado, demora, verificación, archivo o corrección).
 Identificar el tiempo que se utiliza para desarrollar cada actividad.
Diagrama de flujo de procesos
Un diagrama de flujos es una representación gráfica de los pasos de un proceso,
útil para determinar cómo funciona realmente el proceso para producir un resultado. El
resultado puede ser un producto, un servicio, información o combinación de los tres.
El diagrama de flujo se aplicar en cualquier aspecto del proceso, desde el flujo de
materiales hasta los pasos para hacer una venta u ofrecer un producto

Símbolos del Diagrama de flujo:

Inicio Proceso
Documento
Fin Proceso

Actividad Base de Datos

Decision Proceso
predefinido

Figura 13. Símbolos Diagrama de flujo


Elaboración: Propia
22

Diagrama de Ishikawa
Conocido como diagrama causa efecto o diagrama de espina de pez, es una
herramienta de análisis de procesos que describe la representación gráfica de las
relaciones lógicas que existen entre las causas y suba causas que producen un efecto
determinado.
La finalidad de esta herramienta es ayudar a los equipos de mejora a detectar las
diferentes tipos de causa que influyen en un problema, seleccionar los principales y
jerarquizarlos.
Pasos:
 Definición del Problema.
 Determinación de conjunto de causas.
 Participación de los integrantes del grupo en una lluvia de ideas.
 Revisión de Ideas
Infraestructura Tecnológica – Arquitectura para el ERP SAP
La arquitectura es brindada por el servicio de hosting con el proveedor de servicio
hosting el cual consiste en los dos servidores / particiones para los ambientes de
producción (aplicación y base de datos) y un servidor para los ambientes de desarrollo,
pruebas y respaldo.

Variables SAP Pasos de Dialogo


Es una pantalla SAP R/3, que representa una dynpro. Una dynpro o programa
dinámico, se compone de una pantalla y toda su lógica de proceso asociada.
Tiempo de respuesta
El momento en que un proceso de diálogo envía una solicitud a un proceso de
trabajo del distribuidor y el cuadro de diálogo se completa y los datos se transfieren a la
capa de aplicación. El tiempo de respuesta no incluye el tiempo para transferir los datos
del extremo frontal de SAP al servidor de aplicaciones.
Tiempo de CPU
Un proceso de trabajo utiliza la CPU.
Servicio de Hosting de Hardware
Soporte de mantenimiento de hardware, Con parches, actualizaciones y soporte
técnico experto.
23

Base de Datos de Gestión de Configuración (CMDB)


Repositorio de información centralizada que contiene los elementos de
configuración (CI) y las relaciones y dependencias existentes entre ellos. Mediante un
descubrimiento electrónico en el ambiente de TI, se recaban componentes de
infraestructura, para luego configurar aplicaciones y definir servicios.
Notas SAP
Es una comunicación de SAP a sus clientes, donde se explica un posible error,
mejora o funcionalidad; En los casos de los errores suele contener la solución implícita
que se puede implementar directa o manualmente en nuestro sistema para corregir el error
dado. Las notas contienen el sistema al que aplican y la versión de parche (support
package) en la que se incluye. Las notas correctivas suelen ser el resultado de errores
identificados por los clientes en sus sistemas; En analogía con la empresa Microsoft, se
podría decir que son como los parches de actualizaciones de Windows.
Reporte Early Watch
Es la herramienta de SAP que permite al cliente mantenerse al tanto del estado de
sus sistemas y tomar decisiones ante los problemas críticos que se detecten, garantizando
así el buen funcionamiento de sus sistemas SAP. Es capaz de dar la prestación de servicios
de soporte SAP, la optimización de instrumentos SQL y evaluación de la gestión de
soluciones.
Orden de Servicio
Es el documento que se genera en el proceso de inventario físico del vehículo, en
este documento, se encuentra los datos del cliente, vehículo, los servicios a realizar así
como los repuestos asociados al trabajo y la conformidad del cliente de la recepción de
su vehículo.
Documento de Pago
Son los formularios legales (Facturas y remisiones):
 Facturas de venta.
 Boletas de venta.
 Notas de Crédito.
 Notas de Débito.
Backup
El backup o copia de seguridad, es la copia total o parcial de información
importante como respaldo frente a eventualidades.
24

Acuerdo de Nivel de Servicio


Un Acuerdo de Nivel de Servicio o SLA (Service Level Agreement) es un acuerdo
contractual entre cliente y proveedor para niveles de atención en la gestión de un servicio.
TSRM permite medir los tiempos de atención y solución de un requerimiento de servicio
o incidente, en base a su prioridad y a un horario de trabajo establecido, siempre y cuando
estos acuerdos hayan sido definidos previamente en un contrato de servicios.
Matriz de Urgencia Vs Impacto
La urgencia es la celeridad con la que es necesaria atender un requerimiento,
incidente o problema. Este valor es asignado automáticamente de acuerdo al servicio que
solicita el usuario. Por ejemplo, un pase a producción o un posible incidente, suelen ser
más urgentes que una solicitud de información.
El impacto es la cuantificación de la importancia que tiene el CI para el negocio
del cliente. Se puede medir en base a la cantidad de usuarios afectados, o en base al valor
monetario que podría generar ante el negocio del cliente.
La prioridad es la combinación entre la urgencia y el impacto. Es de acuerdo a la
matriz de impacto y urgencia que se obtiene la prioridad, la cual dicta el tiempo de
atención de un ticket.
¿Cómo se obtiene la prioridad según la urgencia e impacto?
La prioridad es el resultado de la combinación de los 3 niveles de impacto y los
3 niveles de urgencia. Entre ambos dan una matriz con 4 prioridades para incidentes, y 5
para requerimientos. (1 = Crítica, 2 = Alta, 3 = Media, 4 = Baja y 5 = Planeada)
SERVICIO

URGENCIA

1 2 3

1 1 2 3
IMPACTO

2 2 3 4

3 3 4 5
CI

Figura 14. Matriz Urgencia / Impacto del Proveedor de Hosting


Elaboración: Propia

Contrato de Prestación de Servicios


25

Este documento es un modelo de contrato de prestación de servicios o contrato de


arrendamiento de servicios, es decir, un contrato de carácter mercantil por el cual una
parte, el prestador, se compromete frente a la otra parte, el cliente que lo contrata, a prestar
un servicio a cambio de un precio.
VA01
Transacción estándar de SAP para crear un Pedido de Venta a un cliente ya
existente.
VA02
Transacción estándar de SAP para modificar un Pedido de Venta a un cliente ya
existente.
IW32
Transacción estándar de SAP para modificar un Orden de Servicio a un cliente
ya existente.

MPLS
Significa Multi Protocol Label Switching MPLS y es un mecanismo que permite
"forwardear" paquetes a través de una red usando información contenida en etiquetas
añadidas a los paquetes IP, esto permite dar prioridad los paquetes de datos, video o voz
según las necesidades de la organización.
26

DESARROLLO DEL PROYECTO

Metodología para el Desarrollo de la Tesis

La metodología que soporta el desarrollo del proyecto está basada en las mejores
prácticas del enfoque ITIL dentro del ciclo de vida de la gestión del Servicio,
específicamente en los contextos de: Gestión de la Operación del servicio en el análisis
de la plataforma tecnología y las aplicaciones que vienen hacer las operaciones que se
realizan en el día a día y Gestión de la Transición del servicio en la implementación del
cambio en la plataforma tecnológica del servicio.

Figura 15. Ciclo de Vida del Servicio


Fuente: ITIL Service Operation
En la gestión de operaciones, se trabajó bajo las buenas prácticas los procesos
de: Gestión de Incidentes y Gestión de Problemas que se encuentran alineados a las
buenas prácticas de ITIL, los cuales fueron brindados por el proveedor del Servicio de
Hosting dentro del servicio contratado. A continuación se describe los procesos gestión
de incidentes y Problemas de MITSUI.
27

GESTIÓN DE INCIDENTES.
Se entiende por incidente, cualquier evento que no sea parte normal de la
operación de un servicio TI y que puede significar la interrupción o disminución de la
calidad de los servicios TI. El objetivo la Administración de Incidente consiste en
restaurar la operación normal del servicio, tan pronto como sea posible, minimizando
el impacto adverso, sobre las operaciones del negocio, asegurando mantener los niveles
óptimos posibles de calidad y disponibilidad del servicio. (Ver Anexo 2 – Proceso de
Gestión de Incidentes)
Se debe considerar como operación normal cuando el servicio está operando
dentro de los límites del Acuerdo de Nivel de Servicio (SLA). Las etapas del proceso
son las siguientes:
Etapa 1: Detección y Registro
Los analistas de la Mesa de Ayuda atenderán y registrarán todos los incidentes,
requerimientos y peticiones de información o ayuda de los usuarios en el sistema de
reportes definido para ello.
Etapa 2: Clasificación
El incidente deberá ser categorizado según su prioridad, tipo de aplicación o dispositivo
afectado, o tipo de usuario.
Etapa 3: Diagnóstico
Los analistas efectuarán un diagnóstico inicial del incidente reportado comparándolo
con la base de datos de errores conocidos incorporada en la base de conocimientos, éste
diagnóstico detallado debe quedar registrado en el sistema de registro.
Etapa 4: Solución y Recuperación
Los analistas harán el mejor esfuerzo por resolver durante el primer contacto la mayoría
de los incidentes y asegurar la continuidad operacional del usuario a través de
soluciones transitorias o definitivas.
Etapa 5: Cierre de los incidentes
Una vez que los servicios han sido restablecidos y el usuario puede operar normalmente,
el analista cerrará el incidente en el sistema, documentando todos los eventos y la
solución en el sistema de registro.
Etapa 6: Propiedad, Seguimiento y Comunicación
Mientras el incidente no esté resuelto, el analista nunca perderá la propiedad sobre él,
para lo cual deberá monitorear y seguir el incidente ya sea esté en nivel 2 o resolutores
28

externos hasta asegurar su solución, durante esta etapa deberá mantener al usuario
plenamente informado del estado de su incidente.
Un Ticket u orden de servicio no será considerado cerrado, hasta que el usuario otorgue
su conformidad.

GESTION DE PROBLEMAS:
La Administración de Problemas se hace cargo del análisis de los incidentes
reportados con el fin de descubrir su causa raíz y convertirlos en errores conocido y así
facilitar la solución de los incidentes en el primer y/o segundo nivel de soporte. (Ver
Anexo 3)
El proceso de administración de problemas considera 2 etapas: control de
errores y control de problemas.
Etapa 1: Control de Problemas
Esta etapa se hace cargo del registro e investigación de los problemas, los cuales se
originan sobre la base de una serie de incidentes sin causa conocida. Una vez que la
causa raíz es establecida se levanta un error conocido en la base de datos de
conocimientos.
Etapa 2: Control de Errores
Esta etapa se hace cargo de registrar los errores cuya solución pasa por un cambio
estructural y se requiere dar inicio a un proceso de cambio para su solución.
Junto a lo anterior, el proceso de administración de problemas también realiza las
siguientes actividades:
1) Apoyo para el manejo de incidentes mayores.
2) Prevención proactiva de problemas, a través de análisis de tendencias.

En la Gestión de Transición, se trabajó bajo las buenas prácticas de ITIL en la Gestión


de Cambios, el cual fue alineado por MITSUI con el proveedor del Servicio de Hosting
dentro del servicio contratado. (Ver Anexo 5).
29

DESARROLLO DEL PROYECTO

Para el servicio de Infraestructura tecnológica, Mitsui contaba con un proveedor


de servicios de hosting de servidores y administrador de SAP. Este proveedor gestionaba
los procesos de las operaciones diarias del Centro de Servicios Informático, teniendo
como meta la excelencia en la calidad de todos los procesos asociados, considerando las
mejoras prácticas de ITIL. (Ver Anexo 8).
Con la siguiente distribución de equipos para procesamiento del ERP SAP:

Tabla 3
Distribución de Arquitectura – ERP SAP
Ambiente / Memoria Sistema
Aplicación Procesador RAM Capacidad Efectiva de Disco Operativo
Producción - Base 2 procesadores Xeon 145 GB (RAID 1) 1,168 GB Windows Server
de Datos 2.8 Ghz 13 GB (RAID 5) 2003
Producción - 2 procesadores Xeon Windows Server
Aplicación 2.8 Ghz 13 GB 72 GB (RAID 1) 2003
QA/Desarrollo / 2 procesadores Xeon 145 GB (RAID 1) 1,168 GB Windows Server
Fileover 3.2 Ghz 13 GB (RAID 5) 2003
1 procesadores Xeon Windows Server
Solution Manager 3.2 Ghz 1 GB 73 GB (RAID 1) 2003

Elaboración: Propia

Los discos contaban con protección, al estar configurados en arreglos tipo RAID
1 (para discos de sistema operativo, archive log y transaction log) y RAID 5 (para los
datos) y tienen fuentes de poder redundantes conectadas. Con disponibilidad 24 x 7 hasta
culminación del contrato con el proveedor.

Internet y Red de Comunicaciones


En el 2011, se contaba con banda de Internet, 1 Mbps contratados con el proveedor de
telefonía en el site de hosting.
Enlace de Red entre sedes (Proveedor Hosting y MITSUI), donde el enlace principal era
por radio Enlace de 47 Mbps y el enlace de contingencia por fibra óptica en 3Mbps,
Se contaba con el servicio de MPLS que ofrecía el proveedor de comunicaciones para las
interconexiones entre las Sedes de MITSUI, las cuales estaban distribuidos con calidades
de servicio de (Voz, data y Video); Cabe precisar que MITSUI antes de migrar a ERP
30

SAP, realizo él una inversión en el proyecto de cableado estructurado en todos las Sedes
de MITSUI para garantizar la performance de la red, organizar de manera eficiente y
estándar el cableado de red de la empresa, que sirvió como base para la migración de
Telefonía IP en el 2008 y soportando la infraestructura física de los servidores en Hosting;
Dichos enlaces contaban con las siguientes especificaciones técnicas de : Cableado
Ethernet de Categoría 6 con velocidad de Red 1000 MB, Switches CISCO administrables
y distribuidos en cascada.
Asimismo, en el lado del proveedor de Hosting, se tenía una Configuración de Red
Multiservicio, donde existen diversos proveedores de comunicación y servicios internos
del proveedor de Hosting; El cual incluía un router con fuente redundante, con un sistema
operativo que soportaba funcionalidades avanzadas y firewall y dos switches con fuente
redundante , con la capacidad de soportar enlaces de enlaces Ethernet, Fast Ethernet y
GigaEthernet , ambos switches están configurados bajo el esquema redundantes hacia el
router.
Dicha red ofrecía funcionalidades de firewall, los cuales protegían a MITSUI de accesos
no autorizados por parte del personal del proveedor del Hosting y de personal de otros
clientes y viceversa.
Se contemplaba un plan de continuidad operacional (Ver Anexo 6) y con acuerdos de
niveles de servicio (Ver Anexo 4), los cuales fueron evaluados al momento del análisis
de los reportes generados al momento de las validaciones.
La herramienta usada para esta gestión era Tivoli Service Request Manager V7.2.1;
Tivoli Service Request Management (TSRM), era uno de los módulos de ISM que
permitía la gestión de requerimientos, incidentes, cambios y problemas. Esta herramienta
se encontraba basada en las mejores prácticas de ITIL v3 y los procesos regionales con
los que contaba el proveedor del servicio para la mejora del delivery del servicio; Con
relación a la problemática “Demasiado tiempo de espera en la atención de vehículos en
el servicio express”, esta herramienta permitió registrar en la Base de Datos de gestión de
Configuración (CMDB) , el registro de los incidentes reportados hacia la mesa de ayuda
refiriéndose a lentitud excesiva del sistema al momento de grabar y generar ordenes de
servicio o emisión de documentos de pago en el área de Servicios ( mantenimientos de
vehículos) durante varios días; convirtiéndose posteriormente en un problema con
prioridad 2 ( ALTA) debidamente identificado, el cual requirió un análisis en el proceso
31

de Gestión de Incidencias y posteriormente Gestión de Problemas hasta llegar a la


solución.

Descripción del Incidente / Problema y Análisis a nivel de infraestructura y


aplicación
MITSUI bajo el esquema de gestión de servicios, reportaba al proveedor del hosting que
el sistema SAP producción venia presentando de manera regular degradación en los
tiempos de respuesta entre los horarios de 7:00 am. - 10:00 am. y 4:00 pm. – 6:00 pm.
Se coordinó con el equipo de rendimiento de SAP, que constaba de (1) usuario Basis de
Proveedor Hosting de modo remoto y (1) Usuario ON SITE en campo para realizar una
revisión integral al sistema, dicha revisión tuvo una duración aproximada de tres semanas,
en dicho análisis intervinieron adicionalmente (2) especialistas SAP (Casa Matriz) y el
proveedor de asistencia técnica del aplicativo.

1. Detalles Preliminares:
A. Consideraciones previas :

El servidor de base de datos e instancia central llegaba a tener un consumo de


memoria entre 80% y 90% mientras que el servidor de aplicación llegaba hasta un 20%,
sin embargo, el uso del CPU permanece entre un 10 y 30%, todos estos valores son
tomados en dicho horario.
Los procesos de backups concluían alrededor de las 4.30am, tiempo muy anterior
a la degradación del tiempo de respuesta.

A continuación, se muestran los informes realizados por la herramienta


EarlyWatch Alert (EWA), que fue habilitada a partir del periodo de análisis, la cual
realizo un análisis automatizado de los datos según unos parámetros estándares definidos
por SAP. Las alertas indicaban situaciones críticas y brindaban soluciones para mejorar
el rendimiento y la estabilidad; Durante la etapa de análisis se realizó el relevamiento de
información considerando los siguientes tópicos:

1. Promedios del tiempo de respuesta


2. Estado de los componentes generales.
32

3. Configuración del sistema.


4. Recursos de hardware.
5. Gestión de base de datos.

Durante las pruebas de trazas, SAP analizó el comportamiento de las transacciones


estándares VA01, VA02 e IW32. Estas transacciones eran utilizadas por personal de
Mitsui, en sus labores habituales de atención al cliente (Servicios). El resultado de las
mediciones era el siguiente:
Tabla 4
Análisis de tiempos en las transacciones Estándares
Tiempo
Transacción Tiempo. Resp Tiempo wps Tiempo DB CPU Time Espera Tiempo GUI
VA01 12806ms 11369ms 5148ms 5788ms 157ms 1374ms
VA02 3838ms 3750ms 1047ms 2140ms 16ms 65ms
IW32 13707ms 2989ms 1043ms 1425ms 16ms 11195ms

Elaboración: Team Performance SAP

Se encontró un tiempo GUI muy alto para la transacción IW32.


Para el caso de las TOP sentencias se encontró que el acceso a la tabla A678
representa el 27% del tiempo de uso de DB. Y al revisar el número de registros
seleccionados por cada ejecución se identificaba una selección de registros muy alta por
cada ejecución (40776).

Tabla 5
Análisis de tiempos en las Sentencias TOP
Execs Duration Records Time/exec Rec/exec. AvgTime/R.Obj. Nombre
4 1.754.100 163.104 438.525 40.776,0 11 A678
971 374.92 971 386 1,0 386 CUOB
1 272.311 2.288 272.311 2.288,0 119 PLPO
2 162.24 200 81.12 100,0 811 TVBST
2 146.692 734 73.346 367,0 200 T77EV
2 121.961 6 60.981 3,0 20.327 T777E
1 115.371 62 115.371 62,0 1.861 M_DEBID
86 94.422 8.514 1.098 99,0 11 ZTBCONSTANTES

Elaboración: Team Performance SAP


33

A nivel de análisis GUI, SAP recomendó ejecutar el reporte


PROFGEN_CORR_REPORT_5, para determinar el número de nodos de menú que cada
usuario tiene. El resultado de la ejecución a esa hora fue el siguiente:

Tabla 6
Análisis de Nodos Usuarios SAP
Username Num Nodos
ZMALDONADO 56.535
VPORTUGAL 56.387
MBARRETO 56.246
APORTOCARRER 56.04 56.04
FZUNIGA 55.942
EYOKOYAMA 55.93
AOBANDO 55.928
LHIGA (* ) 55.928
EGAVIDIA 55.927
CPEDRAZA 55.919
ATOLEDO 55.918
AGARCIA 55.906
LRUIZ 55.892
LCHANG 55.891
EPONCE 55.883
(*) usuario traced

Elaboración: Team Performance SAP

La recomendación es que el número de nodos no supere las 1000 entradas por


cada usuario, debido que un número muy alto implica el consumo de memoria extendida
en el servidor de aplicación y también impacta el tiempo de respuesta para los menús.
Así mismo, sugirió la verificación del low speed connection en los GUI de los
clientes realizar la siguiente configuración en sus respectivos GUI.
Adicionalmente recomendó utilizar las últimas versiones del SAP GUI (saplogon)
en las PCs del Cliente.
34

A nivel de análisis de red.- Se verifico la calidad de la red con una serie de pruebas, los
Resultados fueron los siguientes:

Tabla 7
Análisis de Red - SAP - MITSUI
Servername Server-IP Min (ms) Avg (ms) Max (ms) Loss %
cajaservicio 172.17.4.194 59 98 160 0
finmol01 172.17.0.87 37 43 52 0
L08RPT04 172.22.0.3 75 87 104 0
ppintura 172.17.12.175 41 55 68 0
PYPMOL05 172.17.0.65 45 60 70 0
RPTMOL01 172.17.3.114 39 55 71 10
sapcaja 172.17.2.205 47 57 61 0
ServCan05 172.18.0.45 69 71 82 0
srvmol16 172.17.6.20 40 64 72 0
VehExtCan01 172.17.0.42 40 58 71 0
VenExtpc19 172.17.15.194 38 51 62 0

Elaboración: Team Performance SAP

 T red Lan (interna a PROVEEDOR DE SERVICIO HOSTING) < 1 ms ->


Resultados Óptimos
 T red Wan fast & slow < 4ms / 43 ms -> Resultados Óptimos
 Se recomendó, analizar la perdida de paquetes dentro de la red interna.

A nivel de análisis de parámetros SAP. - Se recomendó realizar un ajuste (tunning) a los


siguientes parámetros SAP:

Tabla 8
Análisis Parámetros SAP
Instancia MITSUIAPP_MTP_00
Parameter Current Recommended
rsdb/obj/buffersize 12288 15000
rsdb/cua/buffersize 12000 14000
Instancia MITSUIP_MTP_00
Parameter Current Recommended
rsdb/obj/buffersize 12288 15000

Elaboración: Team Performance SAP


35

Situación del sistema


En esta sección se resume el estado del sistema en general.
Resumen del sistema
Tabla 9
Análisis de tiempos en las transacciones Estándares
Area Indicadores Valor Tendencia
Active Users 163 constante
Avg. Response Time in Dialog Task 682 ms down
System Performance Max. Dialog Steps per Hour 15922 constante
Avg. Response Time at Peak Dialog Hour 675 ms constante
Avg. Availability per Week 100% constante
Avg. DB Request Time in Dialog Task 312 ms down
Database Performance
Avg. DB Request Time in Update Task 133 ms down
DB Size 158.75 GB constante
Database Space Management
Last Month DB Growth 5.27 GB Up

Elaboración: Team Performance SAP

Kernel y Support Packages


A nivel de Kernel, el sistema se encontraba con una versión de kernel al día. Por el
momento no se requería su actualización. Sin embargo, a nivel de SP se recomienda su
actualización (upgrade).

DB status
Al analizar la carga de trabajo para los procesos de dialogo y de update se encontró que
las transacciones de usuario representaban el 9.3% del tiempo total de respuesta. Al
restringir el análisis de carga para los procesos en lote (batch) y de impresoras (spool), se
encontró que representaban el 21.2% del tiempo total de respuesta; Se reevaluó el análisis
en función de la carga a la DB y se encontró que para los procesos de dialogo de
actualizaciones (update) representaban 16.9% del tiempo total de DB y para los procesos
en lote (batch) y de impresoras (spool) el 77.8%.
36

Estatus de los espacios de tablas (Tables Spaces)

Analizar el estatus de las tablas (tables) se encontró algunos que estaban alcanzando
valores críticos de almacenamiento. Se recomiendo profundizar su análisis ya que se
podían convertirse en un factor de degradación de desempeño (performance).
Entre las tareas que se podrían realizar para superar esta observación, tenemos: efectuar
una reorganización y/o incrementar el espacio físico en discos.

A continuación, se detalla las tareas que se realizaron para levantar las observaciones y
recomendaciones indicadas por SAP.

Tareas - Proveedor de Hosting

1.- Realizar el tunning de parámetros. Para ello se requirió una ventana de 0.5 horas en el
servidor de producción de Mitsui, donde los cambios serán precargados, para que tomen
efecto se requirió un reinicio de las instancias.
2. Proceder a descargar la tabla A678 de memoria. Para esta tarea, se requirió una ventana
de 2 horas en el servidor de producción Mitsui.
3. Actualizar los SP a las últimas versiones disponibles. Para esta tarea, se requirió una
ventana de 8 horas primero en MTD, luego a MTQ y finalmente a MTP.
4. Planificar un estudió de tables spaces. Para esta tarea no hay tiempo definido. La
ventana para la reorganización se realizó después del ajuste de los parámetros del
Proveedor SAP.

Tareas – Proveedor SAP


1. Realizar el estudio de networking (Lan – WAN) para optimizar los tiempos GUI tan
altos encontrados y la perdida de paquetes.
2. Realizar una mejora al cliente GUI instalado en las PCS de sus usuarios, para ello deben
realizar un download de la última versión del saplogon.
3. Realizar la configuración del low gui en los sap-logon de las PCs de los usuarios
después de haber actualizado el saplogon con la última versión disponible.
4. Realizar una optimización de los programas zetas indicados en los informes anteriores.
37

Plan de Trabajo Nro. 1 – Análisis de Infraestructura y Aplicación (ERP SAP)

Nombre de tarea Duración Comienzo Fin

Análisis a nivel de infraestructura y aplicación 62 días lun 21/09/09 mar 15/12/09

Recolección de Datos de desempeño del sistema 10 días lun 21/09/09 vie 2/10/09

Ejecución de Transacciones SAP – Trazas

Tiempos de Respuesta desde la WAN al proveedor Hosting

Tiempos de respuesta desde la LAN al proveedor Hosting

Activación de los monitores de performance de S.O

Replicar Prueba de Recolección de Desempeño 7 días lun 5/10/09 mar 13/10/09

Extracción de datos SAP (Escalamiento) 20 días mie 14/10/09 mar 10/11/09

Evaluación Trazas

Evaluación de Sentencias

Evaluación de GUI - Numero de Nodos

Análisis de RED de WAN a Hosting y viceversa

Análisis Parámetros SAP

Performance BD, Space and Processing

Actualización de SAPGUI

Longo Group en las estaciones

Analysis Kernel y Support Packages

Estatus de los tables spaces

Tareas MITSUI 7 días vie 13/11/09 lun 23/11/09

Informe de Uso de Red - Consumo de Ancho de Banda

Actualización de SAPGUI

Logon Group en las estaciones

Tareas Proveedor Hosting y SAP 15 días mié 25/11/09 mar 15/12/09

Actualización de Kernel

Aplicación de Nota 1009297

Detalle de las opciones de respaldo diario TSM.

Revisión de configuración de antivirus en los 3 servidores

Evaluación de la transacción ZSD38


38

Del análisis desarrollado en la sección de análisis del problema y los ajustes realizados
en los planes de trabajo detallados anteriormente sobre las plataformas de infraestructura
y aplicativo respectivamente se determinó que si bien después de los ajustes se mejora el
tiempo de respuesta, la infraestructura tecnológica, requería de una actualización
(upgrade) de la plataforma tecnológica por las capacidades de memoria y disco que se
venían saturando e incrementando proporcionalmente. (Ver Anexo 7).
Todas estas estadísticas mencionadas y detalladas en dicho informe, indicaban que la
necesidad del Upgrade Tecnológico de la plataforma era la solución requerida, siendo
esta decisión respaldada, después del análisis de capacidades donde se evidencio que el
dimensionamiento inicial fue cambiando significativamente (incremento de usuarios que
elevaron las consultas al sistema); Asimismo con la gestión de la Demanda se llegó a
cuantificar parámetros de control de la infraestructura que se generaron en los reportes
de disponibilidad y desempeño del servicio a través de la representación gráfica de las
principales métricas (dashboard) relevados en el análisis, complementando de esta
manera la decisión de compra de los recursos tecnológicos hacia la gerencia de MITSUI.
Según premisas acordadas con el proveedor (contrato de servicios), cualquier
requerimiento de hardware y/o servicios se manejarían a través de un control de cambios.
Siguiendo con la metodología bajo el enfoque ITIL se procedió con el control de cambios,
bajo la modalidad de modificación. (Ver Anexo 5).

Figura 16.Actividades de Incidencia /Problema y RFC–Degradación de Performance


Elaboración: Propia
39

El Upgrade de la infraestructura tecnológica, requirió de una optimización de servidores


de Windows a AIX, con las siguientes características:
System P:
Tabla 10
Especificación Técnicas – Nuevo Hardware MITSUI
Capacidad efectividad de almacenamiento
Ambiente Procesador RAM interno
136GB ( con discos de 146 GB/15 K SAS en
SAP Producción 6 cores Power 7 de 3.3 Ghz 48GB RAID1 ) Para sistema operativo
SAP Desarrollo QA y 136GB ( con discos de 146 GB/15 K SAS en
Failover 6 cores Power 7 de 3.3 Ghz 48GB RAID1 ) Para sistema operativo

System X
Capacidad efectividad de almacenamiento
Ambiente Procesador RAM interno
1 procesador Xeon Quad 272 GB ( con discos de 146 GB / 15 K SAS
Sap Solution Manager Core de 2.66 Ghz 6GB Raid 5)

Elaboración: Propia

Plan de Trabajo Nro. 2. Actualización Plataforma AIX


Nombre de tarea Duración Comienzo Fin Nombres de los recursos
Actualización de SAP ECC6 a SAP ECC6
69 días lun 19/04/10 Jue 8/07/10
EHP5
Actualización de Support Packages SOLMAN 10 días lun 19/04/10 lun 30/04/10
Proveedor Hosting /
Backup Offline Sistema SOLMAN 1 día
Mitsui
Proceso de actualización de Support Packages 1 día Proveedor SAP
Proveedor Hosting /
Nuevo Backup de SOLMAN
Mitsui
Copia Homogenea para DEV y QAS 13 días lun 3/05/10 mié 19/05/10
Actualización SAP ECC6 EHP5 Desarrollo 15 días jue 20/05/10 mié 9/06/10
Backup Offline Sistema Desarrollo Proveedor Hosting /
2 días
(contingencia) Mitsui
Preparación Ambiente SAP Desarrollo 3 días Proveedor SAP
Proveedor Hosting /
Habilitación de espacio en disco y nuevos FS 4 días
Mitsui
Proveedor Hosting /
Desactivación Modo ArchiveLog BD MTD 2 días
Mitsui
Proveedor Hosting /
Aplicación de FIX5 para db2 2 días
Mitsui
Proveedor Hosting /
Creación de nuevos Tablespaces en la BD 1 día
Mitsui
Proceso de Actualización Desarrollo 3 días Proveedor SAP
Proveedor Hosting /
Activación Modo ArchiveLog BD MTD 1 día
Mitsui
Proveedor Hosting /
Nuevo Backup Offline Sistema Desarrollo 1 día
Mitsui
Actualización SAP ECC6 EHP5 Calidad 11 días 11 días jue 10/06/10
40

Backup Offline Sistema Calidad Proveedor Hosting /


1 día
(contingencia) Mitsui
Preparación Ambiente SAP Calidad 1 día Proveedor SAP
Proveedor Hosting /
Habilitación de espacio en disco y nuevos FS 4 días
Mitsui
Proveedor Hosting /
Desactivación Modo ArchiveLog BD MTQ 1 día
Mitsui
Proveedor Hosting /
Aplicación de FIX5 para db2 1 día
Mitsui
Proveedor Hosting /
Creación de nuevos Tablespaces en la BD 1 día
Mitsui
Proceso de Actualización Calidad 4 días Proveedor SAP
Proveedor Hosting /
Activación Modo ArchiveLog BD MTQ 1 día
Mitsui
Proveedor Hosting /
Nuevo Backup OfflineSistema Calidad 1 día
Mitsui
Entrega de Sistemas MTD y MTQ
Actualización SAP ECC6 EHP5 Producción 20 días vie 25/06/10 jue 22/07/10
Proveedor Hosting /
Habilitación de espacio en disco y nuevos FS 7 días
Mitsui
Permisos totales para el usuario mtpadm Proveedor Hosting /
5 días
/SUM/ y /SPEHP5 Mitsui
Backup Offline Sistema Producción Proveedor Hosting /
1 día
(contingencia) Mitsui
Preparación Ambiente SAP Producción 5 días Proveedor SAP
Proveedor Hosting /
Desactivación Modo ArchiveLog BD MTP 1 día
Mitsui
Proveedor Hosting /
Aplicación de FIX5 para db2 1 día
Mitsui
Proveedor Hosting /
Creación de nuevos Tablespaces en la BD 1 día
Mitsui
Proceso de Actualización Producción 2 días Proveedor SAP
Proveedor Hosting /
Activación Modo ArchiveLog BD MTP 1 día
Mitsui
Proveedor Hosting /
Entrega de sistemas SAP PRD 1 día jue 22/07/10 jue 22/07/10
Mitsui

Consideraciones de la Infraestructura a la nueva arquitectura que se migraba:


El migrar hacia los procesadores Power 7, permitía:
 Reducir Costos.
 Mejoramiento del Servicio.
 Mejora la gestión de Riesgos.
Este tipo de procesadores permitían recolectar información de la performance para
permitir tomar decisiones que involucren el tipo de crecimiento se requiere a futuro, el
impacto en la capacidad y la demanda del procesador o la adquisición de un nuevo
procesador en el caso sea requerido. Asimismo, contaba con un acceso interactivo, donde
brindaba información histórica del desempeño de la data, facilitando la verificación de
estos ambientes (utilización y capacidad) de los últimos 24 meses.
En el caso de Sistema Operativo de AIX, las ventajas que se consideraron fueron:
41

 Seguridad.
 Tiempo de funcionamiento (Rendimiento).
 Escalabilidad.
Todas estas consideraciones mencionadas, permitían garantizar que la
infraestructura a la que se migraba sea segura, altamente disponible y adaptable para
cubrir las cambiantes demandas del negocio, siendo estos factores de decisión. (VER
ANEXO 9).
Según lo indicado previamente Mitsui contaba con un contrato de hosting, que
tenía un cargo mensual de US$ 6530 (Seis mil quinientos treinta y 00/100 Dolares de
los Estados Unidos) por 5 años.

Costo del Proyecto:


 Actualización (Upgrade) de la plataforma tecnológica de Xseries a Pseries.
 Adenda (control de cambio): Cargo Mensual de la actualización (Upgrade) fue de
$ 7800 prolongando a 5 años más. Con un cargo inicial de US$ 3500 dólares por
concepto de instalación, implementación de la nueva plataforma.
 Implementado en Julio 2010
42

ANALISIS Y RESULTADOS
Indicadores de Mejora

Al cabo de un año de haber realizado la migración de la plataforma tecnológica


de procesadores Power 7 y Sistema Operativo AIX y habiendo realizado el tunning de
los componentes tanto de arquitectura como aplicativo, se obtenían los siguientes
indicadores de SLA, memoria, procesamiento y capacidades:

Leyenda:

Figura 17. Cumplimento SLA - Feb 2011 – Jul 2011.


Fuente: Informe Mensual de Operación Jul 2011
Observaciones generales SLA:
Respecto a las transacciones no estándar (transacciones “Z”), se observo una
importante disminución en el tiempo promedio de respuesta en comparación a meses
anteriores. Sin embargo siguen siendo superiores al tiempo de respuesta de las
transacciones estándares. Era importante que Mitsui Automotriz continúe ejecutando un
plan de acción apropiado para evitar se eleven los tiempos de respuesta de las
transacciones “Z”.
Con respecto al tiempo de respuesta del mes de Abril 2011, se evidencio que este
error correspondía a una consulta directa a la base de datos al generar reportes de
43

auditoria, la cual fue realizada sin considerar parámetros. Se corrigió realizando


restricciones al momento de la generación de los reportes enviados.

Utilización de procesador

En los siguientes cuadros se muestra el porcentaje de uso de los servidores AIX


para los ambientes PRD y DEV.
Los niveles de utilización de % CPU deberán procurar no exceder el 75% de la
capacidad del servidor.

Figura 18. Uso Promedio Procesador Diario Jul 2011.


Fuente: Informe Mensual de Operación Jul 2011

El uso de procesador diario se encontraba dentro del umbral recomendado (75%).


44

Figura 19. Uso Promedio Procesador Mensual Jul 2011.


Fuente: Informe Mensual de Operación Jul 2011

El uso de procesador diario así como el comportamiento mensual, se encontraba dentro


del umbral recomendado (75%).
Utilización de memoria MITPRO
En los sistemas operativos Linux/AIX, el consumo de la memoria real es alto debido a
que la administración de memoria se basa en reservas, es decir reserva el espacio total de
memoria para sus aplicaciones y procesos, por tanto su alto consumo no tiene mayor
impacto en la performance del servidor; por el contrario, un alto consumo de memoria
virtual o swap impacta directamente a la performance del servidor, por ello se considerará
alertado el uso de memoria cuando el consumo de memoria swap supere el umbral
recomendado (40 % del total asignado).

Figura 20. Uso Promedio Memoria Diario Jul 2011.


Fuente: Informe Mensual de Operación Jul 2011
45

Figura 21. Uso Promedio Memoria Mensual Jul 2011.


Fuente: Informe Mensual de Operación Jul 2011

El uso de memoria virtual se encontraba dentro de los umbrales recomendados.

Utilización de FileSystem MITPRO


En las siguientes tablas se muestra el uso y capacidad de almacenamiento de las unidades
de disco instalados en los servidores. Los niveles de utilización de las unidades de disco
deberán procurar no exceder el 85% de la capacidad de unidad de disco.

Figura 22. Porcentaje Histórico Uso FileSystem Jul 2011.


Fuente: Informe Mensual de Operación Jul 2011
El porcentaje de uso de los filesystems se encontraba dentro del umbral recomendado
(85% del espacio asignado).
46

CONCLUSIONES

 La optimización planteada en el presente proyecto, fue implementada mediante


la compra de una nueva arquitectura, la cual permitió brindar el servicio en la hora
pactada y cumplir con los objetivos de la empresa y del servicio.
 El contar con un mapa de procesos actualizados, permitió un análisis eficiente y
de esta manera reducir los costos de no cumplir con el servicio.
 El contar con una metodología de servicios, permitió poder priorizar incidentes o
problemas y responder de manera oportuna ante la necesidad del negocio.
 Una mala gestión de capacidades al inicio del proyecto, impacta de manera directa
a la gestión de la demanda y operación de sistema a largo plazo.
 Los indicadores de rendimiento fueron determinantes para la gestión del problema
y en adelante permitirán a la empresa identificar oportunidades de mejora y
mantenerse líder dentro de su negocio.

a) Resultados Obtenidos:

 Mejora de Performance del ERP.


 Migramos de una plataforma Windows a una plataforma AIX que permitió a
la empresa la escalabilidad de su infraestructura por los próximos 5 años.

b) Logros:
o Mejoramiento de la performance del ERP que venía teniendo problemas de
capacidad y de almacenamiento.
o Satisfacción al Cliente en el Servicio Express, brindando el servicio en la hora
pactada.
o Escalabilidad y Disponibilidad de los sistemas que intervienen en el servicio
express y ERP.
o Actualización de la versión del ERP con la finalidad de preparar el sistema
para las nuevas funcionalidades que ofrecía SAP, entre ellas: implementar
Business Intelligence (BI) y mejorar el Warehouse Management (WMS)
que ya teníamos implementado y la apertura de nuevos locales en lima y
provincias.
47

RECOMENDACIONES

a) Se recomendó que durante los primero meses de implementación se realizara


el tunning (adecuamiento) de los parámetros del sistema para garantizar el
funcionamiento óptimo del ERP y la infraestructura.

b) Para garantizar la disponibilidad del servicio se recomendó realizar el Early


Watch de SAP, al menos dos veces al año, para garantizar el correcto desempeño
del ERP.

c) Se recomendó realizar un estudio de dimensionamiento de las capacidades en


función su demanda a partir del segundo año de la implementación para de esta
manera garantizar la infraestructura.

d) Solicitar al proveedor de servicio de tecnología, acerca del desempeño de acuerdo


a los niveles de servicio requeridos, mediante reportes mensuales y reuniones
periódicas.

e) Solicitar al proveedor de servicio de tecnología, notificar cualquier falla o


problema que afecte la disponibilidad de servidores o equipos de comunicación
provistos por el Hosting.
48

REFERENCIAS
Libros

Van Bon, J., De Jong, A., Kolthof, A., Pieper, M., Tjassing, R., Van der Veen, A., &
Verheijen, T. (2008) Guía de gestión Operación del Servicio Basada en ITIL (1
a . ed.). Holanda : Van Haren Publishing, Zaltbomme.

Steinberg, R. (2011) ITIL Service Operation (1 a . ed.). United Kingdom : TSO (The
stationery Office).

SAP. (2005).TADM10_1 SAP Web AS Implementation & Operation, Participant


Handbook, Alemania : SAP Copyright.

Páginas Web

La Gestión de Servicio ITIL. (2008, 26 Noviembre). Recuperado de:


http://geeks.ms/blogs/mojeda/archive/2008/11/26/191-que-es-itil-information-
technology-infrastructure-library.aspx

Glosario y abreviaturas de ITIL. (2008). Recuperado de: www.itil-


officialsite.com/InternationalActivities/ITILGlossaries.aspx

SAP Note 584952 - DB6: DB2 UDB Version 8 Standard Parameter Settings. (2008).
Recuperado de: https://support.sap.com (SNumber / Service market place login
will be required)

IBM Power Systems Performance Report. (2018, 04 Diciembre). Recuperado de:


https://www-01.ibm.com/common/ssi/cgibin/ssialias?htmlfid=POO03017USEN

Intel® Xeon® Scalable Processors World Record Benchmarks. (2017, 06 Noviembre).


Recuperado
de: https://www.intel.com/content/www/us/en/benchmarks/server/xeon-
scalable/xeon-platinum-world-record.html
49

ANEXOS
ANEXO 1: HOJA DE TRABAJO PARA EL ANALISIS DE PROCESOS – SERVICIO
EXPRESS

# PASOS SIMBOLOS DE MINUTOS R


FLUJO
CLIENTE: Solicita
1 cita de 2 min.
mantenimiento
Express
AUX.MKTG:
2 Genera Cita 3 min.

ASESOR SRV:
3 Realiza recepción 10 min.
del Vehículo

ASESOR SRV:
4 Realiza Checklist 5 min.
del Vehículo

ASESOR SRV:
Generación de 10 min.
5 orden de servicio en
el sistema

MECANICO:
6 Ingresa Vehículo al 30 min.
Taller y realiza
mantenimiento

MECANICO:
7 Realiza lavado del 10 min.
vehículo

ASESOR SRV:
8 Realiza entrega del 5 min.
vehículo

ASESOR SRV:
9 Genera documento 10 min.
de pago

AUX.MKTG:
Cancela
10 documentos y emite 2 min.
salida del vehículo

CLIENTE:
11 Recepción del 3 min.
documento y da
salida al vehículo.

AUX.MKTG:
12 Archiva documento 2 min.
de pago

Figura 23. Diagrama de proceso y actividades – Servicio Express


Elaboración: Propia
50

ANEXO 2: Proceso de Gestión de Incidentes bajo del enfoque ITIL.

Figura 24. Proceso de Gestión de Incidentes – Imagen Referencial


Fuente: Proveedor Hosting
51

ANEXO 3: Proceso de Gestión de Problemas bajo el enfoque ITIL.

Figura 25. Proceso de Gestión de Problemas - Imagen Referencial


Fuente: Proveedor Hosting
52

ANEXO 4: Objetivos e indicadores de Niveles de Servicio con el proveedor de Hosting.

Tabla 11
SLO Proveedor de Hosting
Objetivos de Niveles de Servicio
Disponibilidad efectiva del servidor y sistema operativo ( no se incluyen paradas
99.50%
programadas)

Tiempo de atención ante problemas de hardware y sistemas operativos 2 horas en promedio

Disponibilidad efectiva del sistema SAP y la base de datos ( no incluyen paradas


99.00%
programadas o fallas en la propia aplicación)

Tiempo de atención ante problemas de SAP y Base de Datos 2 horas en promedio

Disponibilidad del enlace de comunicaciones provisto en uso por IBM 99.50%

Tiempo máximo de pardas programadas por mes 5 horas

Tiempo de Recuperación ante una falla en el servidor SAP Producción : 6 Horas

Tiempo de respuesta promedio por transacción estándar de SAP (*) 0.8 segundos

Elaboración: Proveedor Hosting

Tareas Programadas:
Actividades coordinadas entre MITSUI y el proveedor de servicio hosting que
pueden originar interrupciones del servicio, las mismas que no serán consideradas para el
cálculo de la disponibilidad del servicio. Estas interrupciones se encuentran especificadas
y serán las causadas por:
 Ejecución de Full backups.
 Aplicación de Fixes
 Mantenimientos Preventivos
Requerimientos adicionales relacionados a posibles interrupciones deberán ser tratados
por los Gerentes de Proyecto de MITSUI y el proveedor de servicios de Hosting.
53

Indicadores de Niveles de Servicio


A. Gerencia de Proyecto
Reporte Mensual
El Gerente de Proyecto proveedor de servicio hosting entregará a MITSUI, mensualmente
dentro de los primeros diez (10) días calendarios de cada mes, el “Informe de Gestión”
que contiene el resumen de los niveles de servicio del mes inmediatamente anterior.
Mensualmente, o según se acuerde con MITSUI, el Gerente de Proyecto de proveedor de
servicio hosting se reunirá con el Gerente de Proyecto de MITSUI para revisar los SLAs
del “Informe de Gestión”. La entrega del “Informe de Gestión” podrá ser en formato
electrónico, enviado a través de un email, o en formato físico.

B. Disponibilidad efectiva del Servidor y del Sistema Operativo:


La disponibilidad se refiere al porcentaje efectivo de tiempo de servicio sin cortes, durante
el periodo de medición. La medición de la disponibilidad no considera las interrupciones
programadas. Dentro de los servicios se han estimado interrupciones programadas, las
mismas que no serán consideradas para el cálculo de la disponibilidad del servicio. Estas
interrupciones serán las causadas por:
 Ejecución de “Full backups”: Se recomienda ejecutar uno (1) a la semana,
el cual tiene una duración esperada de una (1) hora por cada 70 GB de
datos copiados.
 Aplicación de Fixes: Se estima que cada interrupción puede tomar un
máximo de cuatro (4) horas. El número de interrupciones puede variar de
acuerdo a los requerimientos del aplicativo SAP.
 Mantenimientos preventivos: Se estima que se pueden hacer dos (2) cortes
de dos (2) horas por año.
Requerimientos adicionales relacionados a posibles interrupciones deberán ser tratados
por los Gerentes de Proyecto de MITSUI e proveedor de servicio hosting.
El porcentaje de disponibilidad es efectivo sobre el servicio de producción, el cual no
considera las interrupciones programadas y se mide mensualmente.

El servicio de Hosting contempla diferentes mecanismos de medición de disponibilidad


del sistema, los cuales se mencionan a continuación:
a) Sistema Operativo y Hardware
54

Se revisan los mensajes de error del sistema operativo, los cuales indican los
mensajes de alertas o problemas encontrados a nivel de Sistema Operativo y de
componentes de Hardware.

b) Reporte Mensual
Reporte que contiene las principales ocurrencias de Operación y las estadísticas
de disponibilidad del servicio. Así como los indicadores de desempeño del
servicio, los cuales se describen a continuación:
 Uso de procesador
 Uso de memoria
 Utilización de disco

C. Tiempo de atención a problemas de Hardware y Sistema Operativo:

El proveedor de servicio de hosting, cuenta con recursos que brindan atención ante alguna
falla de acuerdo al procedimiento de monitoreo establecido dentro de la operación del
servicio. Esta atención permite el escalamiento necesario ante problemas en los equipos
propuestos, de acuerdo a los procedimientos estándares de proveedor de servicio hosting.
Se entiende como tiempo de atención al tiempo tomado desde que el problema es
reportado a proveedor del servicio hasta que la persona responsable contacta a la persona
responsable en MITSUI para recopilar la información necesaria acerca del problema
presentado.

D. Disponibilidad efectiva del Sistema SAP y la Base de Datos:


La disponibilidad se refiere al porcentaje efectivo de tiempo de servicio sin cortes, durante
el periodo de medición. La medición de la disponibilidad no considera las interrupciones
programadas (ejecución de “Full backups”, aplicación de fixes, mantenimientos
preventivos). Se excluyen de esta medición las paradas o cortes producidos por fallas o
errores en la propia aplicación SAP o la Base de Datos.

E. Tiempo máximo de paradas programadas por mes:


55

Las paradas programadas por mes, se refieren a las interrupciones debido a la ejecución
de “Full backups”, aplicación de Fixes y mantenimientos preventivos. En caso se requiera
una actividad programada de mayor duración, ésta será acordada entre los Gerentes de
Proyecto de proveedor de servicio hosting y MITSUI y este tiempo será excluido de la
medición de los Niveles de Servicio.

F. Tiempo de recuperación ante una falla en el servidor:


Es la ventana de tiempo de recuperación ante una eventualidad operativa en el ambiente
de producción, contadas a partir de la declaración de contingencia, tiempo después del
cual, MITSUI tendrá sus sistemas nuevamente disponibles en el ambiente de
contingencia.
Este esquema no contempla la recuperación de los sistemas en un Centro de Cómputo
Alterno, en caso de desastre en el Centro de Cómputo principal de proveedor de servicio
hosting.

G. Tiempo de respuesta promedio por transacción estándar de SAP:


Los tiempos de respuesta de transacciones desarrolladas dentro del aplicativo (como parte
de la parametrización de SAP) es de 0.8 seg. por transacción estándar de SAP.

ANEXO 5: Procedimiento De Control De Cambios – Contrato Inicial


56

Control de Cambios - Generalidades


Dimensionamiento de las capacidades de procedimiento requeridas considera una carga
de 1300 SAPS en versión 5.0, el cual es el resultado de la siguiente distribución de 80
usuarios proporcionada por el cliente.
Cualquier incremento de cantidad de usuarios concurrentes será manejado de acuerdo al
Procedimiento de Control de cambios
Alcance: El proveedor de Hosting será responsable por la instalación, configuración,
licenciamiento, mantenimiento y soporte únicamente del soporte provisto en uso por
proveedor de servicio hosting.
Inicialmente -> 60 meses.
El alcance y el costo de los servicios materia de la presente propuesta será susceptible de
cambio si alguna de las anteriores premisas no se cumple
Procedimiento de Control de Cambios
Cualquier requerimiento que implique cambios en las funciones y/o características de los
servicios descritos en el presente contrato, será tratado según lo establecido en el presente
procedimiento, denominada “Procedimiento de Control de Cambios”.
Solicitud de Cambio
Un cambio podrá ser originado por iniciativa de cualquiera de las Partes. Para asegurar
un tratamiento uniforme, se usará un formato con el siguiente contenido:
 Solicitud de Cambio
 Descripción del Cambio
 Justificación
 Identificación preliminar de los componentes de servicio afectados.

Calificación del Cambio


Las solicitudes de cambio serán canalizadas al Gerente de Proyecto de la otra parte, con
quien se efectuará un análisis preliminar para calificar el cambio.
Para las MODIFICACIONES se aplicarán las siguientes estipulaciones:
En cualquier momento de la vigencia de este Proyecto, cualquiera de las Partes podrá
solicitar MODIFICACIONES al proyecto, solicitando tal(es) MODIFICACION (ES) por
escrito a la otra Parte. Dentro de los treinta (30) días hábiles de recepción con tal solicitud,
la parte receptora enviara una respuesta a la otra parte. Si la solicitud de modificación fue
57

originada por el CLIENTE, el proveedor de servicio hosting comunicara por escrito a EL


CLIENTE si la MODIFICACION puede ser hecha y su efecto en los Apéndices, Cargo y
otros términos y condiciones de este Proyecto.
Para la incorporación de las modificaciones, ajustes o revisiones a este Proyecto,
observara las siguientes reglas:
 No podrán modificarse la naturaleza u objeto de este proyecto.
 No podrá alterarse o gravarse, en grado tal que resulte excesivamente oneroso, el
objeto de las prestaciones de futuro cumplimiento a cargo de una de las Partes
 Deben mantenerse sustancialmente las condiciones técnicas para la ejecución del
Proyecto
 Debe guardarse el equilibrio financiero del Proyecto para ambas Partes.
 Ambas partes deberán firmas una autorización escrita para implementar cualquier
mejora, cambio o modificación.

ANEXO 6: Procedimiento Interno de Continuidad Operacional


58

Antes una falla de la base de datos, se contempla el uso del server de DEV/QAS
como servidor de contingencia. En el momento de la contingencia, este servidor de
DEV/QAS se conectaría a la torre de discos de base de datos, mientras dure la
contingencia. Dejando el servidor de DEV/QA temporalmente inhabilitado, hasta poner
operativo el server de base de datos.
El servidor de DEV/QA, mantendrá instalado y en standby una instancia de Producción
que se activaría al momento de la contingencia. Este sistema permitirá tener la
recuperación del ambiente de producción de 6 horas ante eventualidades operativas
En el caso que ocurra un problema en el server de aplicación, el server de base de datos
podrá asimilar la carga adicional mientras dure la contingencia

ANEXO 7: Informe parámetros SAP después recomendaciones SAP


Promedios de Tiempos de Respuestas:

Figura 26. Tiempo de Respuesta SRV PRD Dic 2009


Fuente: Informe Mensual de Operación Dic 2009

Del gráfico, se visualiza que el tiempo de respuesta se encuentra por encima del umbral
recomendado; La tarea de optimización de programas SAP se realizó satisfactoriamente
pero aun así no se logró mejorar esta estadística, por lo que la necesidad de mayor
procesador es requerida.

Recursos de Hardware:
59

Figura 27. Tiempo de Pasos de dialogo SRV PRD Dic 2009


Fuente: Informe Mensual de Operación Dic 2009

Del gráfico, se evidencia la tendencia de crecimiento de interacciones o pasos de dialogo,


esto es debido a la cantidad de usuarios conectados y las tareas realizadas; Este
crecimiento se mantendrá a futuro debido que MITSUI, abrirá nuevos locales en
provincia.

Estado de componentes Generales:


El siguiente cuadro, muestra indicadores relevantes de varias áreas del sistema
(Indicadores de Performance).

Tabla 12
Indicadores de performance SRV PRD Dic 2009

Área Indicadores Valor Tendencia


Usuarios Activos 171 Baja
Promedio de tiempo de respuesta en tareas de
dialogo 1107 ms Alta
Desempeño del Sistema Máximos Pasos de Dialogo por hora 14534 Baja
Promedio de tiempo de respuesta en horas de
dialogo pico 778 ms Alta
Promedio de disponibilidad por semana 99% Estable
Promedio de requerimiento de Base de Datos en
Desempeño de la Base de tareas de dialogo 700 ms Alta
Datos
Promedio de requerimiento de Base de Datos en
tareas de actualización 79 ms Baja
Tamaño de Base de Datos 278.6 GB Estable
Gestión del espacio de la Base
de Datos Crecimiento del último mes de la Base de datos 6.15 GB Alta
Fuente: Informe Mensual de Operación Dic 2009
60

A comparación de la validación inicial, se mantiene el crecimiento de la BD y los tiempos


de respuestas.

Carga de Trabajo actual – Medición:

Tabla 13
Medido de usuarios en el Sistema Actual SRV PRD Dic 2009

Usuarios Actividad Baja Actividad Media Actividad Alta Total Usuarios


Medido en el Sistema 49 137 34 220

Fuente: Informe Mensual de Operación Dic 2009

Dónde:
Usuario con actividad baja, 1 dialog step (cambios de pantalla en SAP) cada 6 minutos.
Usuario con actividad media, 1 dialog step (cambios de pantalla en SAP) cada 30
segundos.
Usuario con actividad alta, 1 dialog step (cambios de pantalla en SAP) cada 10 segundos
Carga de Trabajo Proyectada – Inicio del Proyecto

Carga de Trabajo Proyectada – Inicio del Proyecto:

Tabla 14
Medido de usuarios SRV PRD 2006
Total
Usuarios Actividad Baja Actividad Media Actividad Alta Usuarios
Medido en el Sistema 0 48 32 80

Fuente: Contrato de Servicios Proveedor Hosting

La cantidad de usuarios se ha incrementado en 275% con respecto al dimensionamiento


inicial de 80 usuarios.
El dimensionamiento de las capacidades de procesamiento requerida consideraba una
distribución de los 80 usuarios expresados en el cuadro mencionado en la Carga de
Trabajo Proyectada.
61

ANEXO 8. Diagrama de Red / Servidores y Comunicaciones MITSUI y entre sedes.


Internet
TELMEX
CID 40838
512 Kbps
9
/2
HOSTING 40 Internet
4.
2 MITSUI TELMEX
15
Centro de Computo Producción 4. MOLINA
24
La Molina 6.
21

Proxy Web
216.244.154.0/24

Vlan 100
Mitsui DMZ
10.54.6.0/28 2801
10.54.3.0/24 .12 .13 Primario .1 152.17.0.0/16
.10
VLAN 316 Mitsui

.3
.4 .3 .2
.1
.1 .2 .3
APP DEV PRD Mail
.1 10.54.6.0/28
172.17.0.0/16
.1 .2 Router/
.4 Vlan 10
Router/ Firewall
Firewall
TELMEX
2801
CID 34365 Primario
Mitsui
.3 .5 .4 .7 3 Mbps
.6 .9 10.54.2.0/30
Segmento Mitsui .13
10.54.1.0/24
VLAN 54

APP2 Sol. Man. Intranet

Canada: 172.18.0.0/16
Habich: 172.31.0.0/24
Iquitos: 172.22.0.0/24
Raimondi: 172.25.0.0/24
SMP : 172.34.0.0/24
Arequipa : 172.28.0.0/24
Hosting Sta. Anita : 172.32.0.0/16
Mitsui
Telmex

Figura 28. Diagrama de Red y Comunicaciones


Fuente: DashBoard Proveedor Hosting

Figura 29. Diagrama de Red y Comunicaciones entre Sedes


Fuente: MITSUI
62

ANEXO 9. Comparativo Infraestructura Inicial vs Infraestructura Final MITSUI


Tabla 15
Comparativo Infraestructura Inicial vs Infraestructura Final

CARACTERISTICAS INFRAESTRUCTURA INICIAL INFRAESTRUCTURA FINAL


Sistema Operativo Windows Server 2003 AIX
PRD BD → 13 GB
PRD → 48 GB
PRD APP → 13 GB
QAS / DEV / FAILOVER → 48 GB
QAS / DEV / FAILOVER → 13 GB
SOLMAN → 6G
Memoria RAM SOLMAN → 1G

PRD BD → 2 Procesadores Xeon 2.8 Ghz PRD → 6 cores Power 7 de 3.3 Ghz
PRD APP → 2 Procesadores Xeon 2.8 Ghz QAS / DEV / FAILOVER → 6 cores Power 7 de
QAS / DEV / FAILOVER → 2 Procesadores 3.3 Ghz.
Xeon 3.2 Ghz SOLMAN → 1 procesador Xeon Quad Core de
Procesador SOLMAN → 1 Procesador Xeon 2.8 Ghz 2.66 Ghz.

PRD → 136GB (con discos de 146 GB/15 K


PRD BD → 145 GB (RAID 1) 1,168 (RAID 5) SAS en RAID1 ) Para sistema operativo.
QAS / DEV / FAILOVER → 136GB ( con
PRD APP → 72 GB ( RAID 1)
discos de 146 GB/15 K SAS en RAID1 ) Para
QA → 145 GB (RAID 1) 1,168 (RAID 5) sistema operativo.
SOLMAN → 272 GB (con discos de 146 GB /
SOLMAN → 73 GB (RAID 1)
Capacidad Efectiva 15 K SAS Raid 5).
Elaboración: Propia
63

ANEXO 10. DIAGRAMA ISHIKAWA – MANTENIMIENTO EXPRESS

Diagrama Ishikawa – Servicio Express


Elaboración: Propia

Você também pode gostar