Martinez NR

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 312

Propuesta de arquitectura empresarial para la

gestión de planeamiento (GPL) de Honda del Perú S.A.

Item Type info:eu-repo/semantics/bachelorThesis

Authors Martínez Noriega, Rensso Ali; Zevallos Lescano, Willy Jesus

Publisher Universidad Peruana de Ciencias Aplicadas (UPC)

Rights info:eu-repo/semantics/embargoedAccess

Download date 04/10/2023 03:56:54

Link to Item http://hdl.handle.net/10757/622018


UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

FACULTAD DE INGENIERÍA

CARRERA DE INGENIERÍA DE SISTEMAS

PROPUESTA DE ARQUITECTURA EMPRESARIAL


PARA LA GESTIÓN DE PLANEAMIENTO (GPL) DE
HONDA DEL PERU S.A.

PROYECTO PROFESIONAL PRESENTADO POR:


RENSSO ALI MARTÍNEZ NORIEGA
WILLY JESUS ZEVALLOS LESCANO

PARA OPTAR POR EL TÍTULO DE INGENIERO DE SISTEMAS

ASESORES:
SAMANTHA LÓPEZ
DANIEL SUBAUSTE
JAVIER LACHERRE
EDUARDO MENDÍVIL

Lima, Febrero de 2017


DEDICATORIA

A nuestros padres, quienes siempre estuvieron para alentarnos durante nuestra formación
profesional, a nuestras esposas e hijos quienes hasta en los momentos más difíciles siempre
nos apoyaron. A las empresas donde trabajamos por todas las facilidades que nos brindaron
para culminar nuestros estudios.

2
AGRADECIMIENTOS

A los profesores de la UPC, quienes fueron nuestros guías durante toda esta aventura
universitaria, por compartir con nosotros sus enseñanzas y experiencias que nos servirán no
solo para ser mejores profesionales, sino también para ser mejores personas. A mis
compañeros de carrera, porque con su apoyo ha sido posible lograr cumplir con esta meta,
debido a que muchos obstáculos fueron superados gracias al esfuerzo individual y grupal.

3
RESUMEN

Actualmente, el impacto que genera los retrasos en la entrega de pedidos comerciales a los
clientes por falta de stock, en el rubro de repuestos, es considerablemente alto, por lo que la
rapidez y eficiencia en la entrega de los pedidos comerciales es un factor crítico para la
competitividad. Es por ello, que una adecuada gestión y planificación de recuperación de
pedidos pendientes es clave para poder generar mayor satisfacción al cliente; por
consiguiente, incrementar las ventas. Dicho esto, el sector automotriz no es ajeno a ello,
debido a que la eficiencia en la entrega de pedidos comerciales incrementa la satisfacción de
los clientes, genera un mayor posicionamiento de la marca e incrementa las ganancias para
las organizaciones de este rubro. Por tal motivo, Honda del Perú, en adelante Honda, tiene la
necesidad de mejorar su servicio y diferenciarse de la competencia. Para lograr ello, se
propuso una Arquitectura Empresarial alineada a los objetivos estratégicos del negocio, en
donde se priorizó la gestión de Planeamiento de pedidos comerciales pendientes del área
Logística de Honda, con la finalidad de encontrar las oportunidades de mejora en el proceso
de Gestión de Planeamiento GPL. Para ello se utilizó el marco de trabajo de TOGAF para
estructurar las necesidades del negocio e identificar las brechas entre el AS IS y el TOBE, las
cuales se propuso que serán mitigadas con una solución de TI apoyada en las metodologías
ágiles, con la finalidad de contar con desarrollos cortos con entregas efectivas y puestas en
producción en iteraciones cortas, ya que esto permitirá trabajar de la mano con el usuario
final, lográndose una mayor calidad en los entregables y asegurando que la solución sea la
esperada por el negocio. Además, esta propuesta se complementa con las buenas prácticas de
ITIL, el cual nos dará los lineamientos para el manejo de la mejora continua de la
organización, asimismo definiremos los aspectos estratégicos de los servicio de TI. Además,
se asegura la continuidad de nuestra propuesta implementando servicios para la atención
preventiva para los procesos y servicios de Honda del Perú. Finalmente, se cuenta con una
propuesta integrada para la Gestión de Planificación de Pedidos comerciales pendientes
cumpliendo dos objetivos estratégicos priorizados por la organización; el de mejorar la ventas
y disminuir el tiempo de abastecimiento de los pedidos comerciales pendientes, mejorando la
percepción del cliente, agilizando el servicio de gestión de planeamiento de pedidos
comerciales pendientes.

4
ÍNDICE

AGRADECIMIENTOS.............................................................................................................3
RESUMEN.................................................................................................................................4
INTRODUCCIÓN...................................................................................................................15
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS......................................................................16
MARCO TEÓRICO.............................................................................................................16
ARQUITECTURA EMPRESARIAL..............................................................................16
METODOLOGÍAS ÁGILES...........................................................................................20
ITIL..................................................................................................................................33
OBJETO DE ESTUDIO......................................................................................................39
ORGANIZACIÓN OBJETIVO.......................................................................................39
MISIÓN............................................................................................................................40
VISIÓN............................................................................................................................41
MAPA DE PROCESOS...................................................................................................42
OBJETIVOS ESTRATÉGICOS......................................................................................43
MATRIZ DE JUSTIFICACIÓN DE LOS OBJETIVOS VRS LOS PROCESOS..........44
PROCESOS DEL NEGOCIO..........................................................................................45
ORGANIGRAMA...........................................................................................................46
ALCANCE DEL PROYECTO............................................................................................47
OBJETIVOS DEL PROYECTO..........................................................................................48
OBJETIVO GENERAL...................................................................................................48
OBJETIVOS ESPECÍFICOS...........................................................................................48
BENEFICIOS DEL PROYECTO........................................................................................49
BENEFICIOS TANGIBLES...........................................................................................49
BENEFICIOS INTANGIBLES.......................................................................................49
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL.............................................................50
INTRODUCCIÓN...............................................................................................................50
ALCANCE...........................................................................................................................50
PRELIMINAR.....................................................................................................................52

5
PRINCIPIOS DE ARQUITECTURA..............................................................................52
PETICION DE TRABAJO DE ARQUITECTURA........................................................56
VISIÓN DE LA ARQUITECTURA...................................................................................60
DECLARACION DE TRABAJO DE ARQUITECTURA.............................................60
CRONOGRAMA TENTATIVO.....................................................................................72
VISION DE LA ARQUITECTURA...............................................................................76
ARQUITECTURAS (AS IS / TO BE)................................................................................83
ARQUITECTURA DE LA LINEA BASE (AS-IS)........................................................83
FUNDAMENTO Y JUSTIFICACION DEL ENFOQUE ARQUITECTONICO...........95
ARQUITECTURA DE NEGOCIO DE DESTINO (TO-BE).........................................97
ANALISIS DE BRECHA..................................................................................................113
ARQUITECTURA DE NEGOCIO...............................................................................113
ARQUITECTURA DE DATOS....................................................................................117
ARQUITECTURA DE APLICACIONES....................................................................121
ARQUITECTURA DE TECNOLOGIA........................................................................122
OPORTUNIDADES Y SOLUCIONES............................................................................125
CUADRO RESUMEN DEL PLAN DE MIGRACION................................................126
CONCLUSIONES.............................................................................................................128
CAPÍTULO 3. MÉTODOS ÁGILES PARA EL DESARROLLO DE SOFTWARE...........129
INTRODUCCIÓN.............................................................................................................129
OBJETIVOS......................................................................................................................130
IDENTIFICACIÓN DE FORTALEZAS Y DEBILIDADES...........................................131
FORTALEZAS..............................................................................................................131
DEBILIDADES.............................................................................................................131
DIAGNÓSTICO DEL GRUPO.........................................................................................136
IDENTIFICACIÓN DE LAS DINÁMICAS PROPUESTAS...........................................137
COMPOSICIÓN DE LOS GRUPOS DE TRABAJO.......................................................142
PRODUCT OWNER.....................................................................................................142
SCRUM MASTER.........................................................................................................143
SCRUM TEAM.............................................................................................................143
ESTRUCTURA ORGANIZACIONAL DEL EQUIPO SCRUM.................................146
ROLES SCRUM EN EL ORGANIGRAMA DE OBJETO DE ESTUDIO..................147
ROLES SCRUM AREA DE TI (SCRUM MASTER / SCRUM TEAM).....................148

6
ACTIVIDADES DEL GRUPO DE TRABAJO............................................................149
DEFINICIÓN DE LAS HERRAMIENTAS A UTILIZAR..............................................151
CUANTIFICACIÓN DE CRITERIOS..............................................................................159
HERRAMIENTAS Y ARTEFACTOS SCRUM...............................................................162
LISTA DE PRODUCTO (PRODUCT BACKLOG).....................................................162
LISTA DE PENDIENTES DEL SPRINT (SPRINT BACKLOG)................................163
SCRUM TASKBOARD................................................................................................163
PROPUESTA AGIL DE APLICACIÓN DEL MARCO DE TRABAJO SCRUM..........164
EQUIPO SCRUM..........................................................................................................164
PRODUCT BACKLOG.................................................................................................165
PRESUPUESTO DE PROPUESTA AGIL.......................................................................188
CONCLUSIONES.............................................................................................................189
CAPÍTULO 4. GESTIÓN DE SERVICIOS EN TI...............................................................191
INTRODUCCIÓN.............................................................................................................191
EVALUACIÓN ESTRATÉGICA.....................................................................................191
ESTRATEGIA DE NEGOCIO......................................................................................191
PRIORIDADES DE LA ORGANIZACION.................................................................192
FODA.............................................................................................................................193
SERVICIOS DE NEGOCIO OFRECIDOS...................................................................195
ESTRATEGIA DE TI....................................................................................................197
PRIORIDADES DE INVERSION................................................................................198
PLANIFICACIÓN ESTRATÉGICA.................................................................................199
SERVICIOS IDENTIFICADOS....................................................................................199
EVALUACION FINANCIERA........................................................................................205
FLUJO DE EFECTIVO.................................................................................................205
DIAGRAMAS DE PUNTO DE EQUILIBRIO.............................................................206
VAN...............................................................................................................................206
TIR.................................................................................................................................207
SUSTENTO DE INGRESOS Y EGRESOS..................................................................207
EVALUACION DE RIESGOS..........................................................................................212
DISEÑO DEL SERVICIO.................................................................................................215
REQUERIMIENTO DE NIVEL DE SERVICIO..........................................................215
ACUERDO DE NIVEL DE SERVICIO.......................................................................217

7
NIVEL DE SERVICIO OPERACIONAL.....................................................................218
CONTRATOS DE PROVEEDORES (UNDERPINNING CONTRACTS).................220
TRANSICION DEL SERVICIO.......................................................................................222
REQUERIMIENTO DE CAMBIO................................................................................222
ELEMENTOS DE CONFIGURACION........................................................................225
PROCESOS ITIL...............................................................................................................226
DESCRIPCION DEL PROCESO DE GESTION DEL PORTAFOLIO DE SERVICIOS
........................................................................................................................................226
DESCRIPCION DEL PROCESO DE GESTION DEL NIVEL DEL SERVICIO.......237
DESCRIPCION DEL PROCESO GESTION DE CAMBIOS......................................252
DESCRIPCION DEL PROCESO ACTIVOS DEL SERVICIO Y GESTION DE LA
CONFIGURACION.......................................................................................................266
DESCRIPCION DEL PROCESO DE GESTION DE INCIDENTES..........................273
CONCLUSIONES.............................................................................................................284
CAPÍTULO 5: ESTRUCTURA PROPUESTA.....................................................................285
INTRODUCCIÓN.............................................................................................................285
ENFOQUE DE LA PROPUESTA.....................................................................................285
SUSTENTO DE BENEFICIOS.........................................................................................287
CASOS...........................................................................................................................287
CALCULO DE INVERSION (VAN/TIR)........................................................................292
FLUJO DE EFECTIVO.................................................................................................292
FLUJO ACUMULADO.................................................................................................292
ESQUEMA GRAFICO DE LA ESTRUCTURA PROPUESTA......................................295
DESCRIPCION DEL ESQUEMA GRAFICO..............................................................296
DESCRIPCION DE BRECHAS DEL NEGOCIO........................................................297
CONCLUSIONES.............................................................................................................299
CONCLUSIONES.................................................................................................................300
RECOMENDACIONES........................................................................................................302
GLOSARIO DE TÉRMINOS................................................................................................303
BIBLIOGRAFÍA....................................................................................................................304

8
LISTA DE IMAGENES

Figura 1: Componentes de la arquitectura empresarial............................................................16


Figura 2: Método de desarrollo de Arquitectura......................................................................17
Figura 3: Proceso SCRUM.......................................................................................................26
Figura 4: Evolución de ITIL....................................................................................................35
Figura 5: Logos de Honda........................................................................................................39
Figura 6: Mapa de Procesos.....................................................................................................42
Figura 7 : Organigrama del Objeto de Estudio........................................................................46
Figura 8: PDCA Sustento Limites de Timepo.........................................................................56
Figura 9: PDCA Sustento Limitaciones Externas y de Negocio..............................................57
Figura 11: Procedimiento para Cambios de Alcance...............................................................61
Figura 12: Cronograma tentativo del proyecto........................................................................72
Figura 13: Matriz Poder / Interes.............................................................................................76
Figura 14: Lista de Asuntos y Escenario que deben abordarse................................................82
Figura 16: Diagrama de Actividades AS-IS.............................................................................85
Figura 19: Diagrama de Aplicaciones y descripción (AS-IS)..................................................89
Figura 20: Descripción de Diagrama de Aplicaciones (AS-IS)...............................................89
Figura 21: Matriz Aplicaciones vrs procesos del Negocio. (AS-IS)........................................90
Figura 22: Componente de Tecnología vs. Sistemas informáticos (AS-IS)............................91
Figura 23: Descripción de los Componente de Tec. Vs. Sistemas informáticos (AS-IS)........91
Figura 24: Plataforma de tecnología y su descomposición (AS-IS)........................................92
Figura 25: Ambientes y ubicaciones (AS-IS)..........................................................................92
Figura 26: Mapa de comunicaciones fisicas [RED] (AS-IS)...................................................93
Figura 27: Especificaciones de hardware y red (AS-IS)..........................................................94
Figura 28: Matriz de Objetivo del Negocio vrs procesos (TO-BE).........................................97
Figura 29: Niveles de recuperación de B/O.............................................................................99
Figura 30: Diagrama de Actividades TO-BE.........................................................................101
Figura 31: Diagrama de Actividades–Sub Proceso: “Recuperación B/O” (TO-BE).............102
Figura 32: Diagrama de Actividades – Sub Proceso : “Recepción Mercadería” (TO-BE). . .103

9
Figura 33: Modelo de Datos (TO-BE)/ Fuente : Elaboración Propia....................................105
Figura 34: Matriz de datos del proceso seleccionado vrs procesos del Negocio (TO-BE)....106
Figura 35: Diagrama de Aplicaciones y descripción (TO-BE)..............................................107
Figura 36: Descripción de Diagrama de Aplicaciones (TO-BE)...........................................107
Figura 37: Matriz de Aplicaciones vs. Procesos del Negocio. (TO-BE)...............................108
Figura 38: Componente de Tec. Vs. Sistemas informáticos (TO-BE)...................................109
Figura 39: Descripción de los Componentes de Tec. Vs. Sistemas informáticos (TO-BE). .109
Figura 40: Plataforma de tecnología y su descomposición (TO-BE)....................................110
Figura 41: Plataforma de tecnología y su descomposición (TO-BE)....................................110
Figura 42: Mapa de comunicaciones fisicas [RED] (TO-BE)...............................................111
Figura 43: Especificaciones de hardware y red (TO-BE)......................................................112
Figura 44 : Analisis de Brecha – Arquitectura de Negocio...................................................113
Figura 45 : Analisis de Brecha – Arquitectura de Datos........................................................117
Figura 46 : Analisis de Brecha – Arquitectura de Aplicaciones............................................121
Figura 47 : Evaluación de Impacto (Probabilidad e Impacto)...............................................123
Figura 48 : Matriz de Probabilidad e Impacto.......................................................................124
Figura 49 : Estructura de Desgloce de trabajo.......................................................................125
Figura 50 : Cuadro Resumen del Plan de Migración.............................................................126
Figura 51 : Estructura organizacional del equipo de trabajo Scrum......................................146
Figura 52 : Estructura organizacional del Product Owner VS. Organigrama........................147
Figura 53 : Estructura organizacional del Equipo Scrum TI VS. Organigrama....................148
Figura 54 : Baraja de Plannning Poker..................................................................................171
Figura 56 : Presupuesto de la Propuesta Ágil........................................................................188
Figura 57 : Flujo de Efecto del Servicio propuesto................................................................205
Figura 58 : Flujo Acumulado del Servicio propuesto............................................................206
Figura 59 : VAN y TIR del Servicio propuesto.....................................................................207
Figura 60 : Sustento de Egresos.............................................................................................207
Figura 61: Egresos de Inversión del Equipo AE....................................................................208
Figura 62: Egreso de Inversión del Equipo de Implementación............................................208
Figura 63: Sustento de Egreso Recursos ITIL.......................................................................209
Figura 64: Egreso de Inversión del Consultor Basic de Infraestructura................................209
Figura 65 : Egreso Mensual del Servicio de Soporte y Mantenimiento ERP SAP................210
Figura 66 : Distribución de Egreso mensual por Soporte y Mantenimiento ERP SAP.........210

10
Figura 67 : Sustento de Egreso Mensual del Servicio de Soporte ITIL.................................210
Figura 68 : Distribución de Egreso mensual por Servicio de Soporte ITIL...........................211
Figura 69: Matriz de Probabilidad / Impacto para ponderar el riesgo...................................214
Tabla 56 : Contrato de soporte de Terceros UC.....................................................................220
Tabla 60: Proceso de Gestión de Portafolio de Servicios......................................................226
Tabla 66: Proceso de Gestión de Nivel de Servicio...............................................................237
Figura 70 : Proceso de gestión de cambios............................................................................252
Figura 73: Proceso de Activos del Servicio y Gestión de la Configuración..........................266
Figura 75: Listado de Necesidad de Pedido Comercial.........................................................288
Figura 76: Lista de Pedidos de Compra................................................................................288
Figura 77: Listado de Pedidos en transito..............................................................................289
Figura 78: Listado de Stock Almacen Local..........................................................................289
Figura 79: Listado de Pedidos comerciales Penndientes.......................................................290
Figura 80: Sustento de Beneficio – Abastecimiento consolidado por línea de repuesto.......290
Figura 81: Abasteciento del 20% de Pedido Comerciales Pendientes en 1er año.................291
Figura 82: Flujo de Efectivo - Inversión................................................................................292
Figura 83: Flujo Acumulado..................................................................................................293
Figura 84: VAN y TIR del Servicio propuesto......................................................................294
Figura 85: Esquema grafico...................................................................................................295

11
LISTA DE TABLAS

Tabla 1: Fases de la metodología de desarrollo de la arquitectura...........................................18


Tabla 2: Matriz de Justificación de los Objetivos vs. los procesos..........................................44
Tabla 3: Detalle de los Procesos del Negocio..........................................................................45
Tabla 4: Principios del Negocio – PRNEG01..........................................................................52
Tabla 5: Principios del Negocio...............................................................................................52
Tabla 6 : Principios de Datos PRDAT01................................................................................53
Tabla 7 : Principios de Datos PRDAT02................................................................................53
Tabla 8 : Principios de Datos PRDAT03................................................................................53
Tabla 9 : Principios de Aplicaciones PRAPL01.....................................................................54
Tabla 10: Principios de Aplicaciones PRAPL02....................................................................54
Tabla 11: Principios de Tecnología PRTEC01.......................................................................54
Tabla 12: Principios de Tecnología PRTEC02.......................................................................55
Tabla 13: Formato de Solicitud de Cambio.............................................................................62
Tabla 14: Matriz Raci Roles, responsabilidades y Entregables...............................................64
Tabla 15: Lista de Interesados..................................................................................................77
Tabla 16 : Matriz RACI de Roles de Negocio.........................................................................86
Tabla 17: Roles de Negocio : Matrix RACI (TO-BE)...........................................................103
Tabla 18 : Tabla de Fortalezas...............................................................................................132
Tabla 19 : Tabla de Debilidades.............................................................................................134
Tabla 20 : Diagnostico de Grupo...........................................................................................136
Tabla 21 : Tabla de Dinámicas Propuestas para reforzar Fortalezas.....................................137
Tabla 22 : Tabla de Dinámicas Propuestas para mejorar Debilidades...................................139
Tabla 23 : Tabla de criterios de selección de Product Owner................................................142
Tabla 24 : Tabla de criterios de selección de Scrum Master..................................................143
Tabla 25 : Tabla de criterios de selección de Scrum Team....................................................143
Tabla 26 : Tabla de Actividades del grupo de trabajo...........................................................149
Tabla 27 : Tabla de ventajas y desventajas de metodologías de desarrollo de proyectos......151
Tabla 28 : Tabla de Criterios para selección de una Metodología de desarrollo...................156

12
Tabla 29 : Cuantificación de Criterios para selección de una Metodología...........................159
Tabla 30 : Tabla de condiciones evaluativas..........................................................................160
Tabla 31 : Tabla de resumen de evaluación de marco de trabajo a utilizar...........................161
Tabla 32 : Tabla de equipo Scrum Propuesto para la Propuesta Ágil....................................164
Tabla 33 : Tabla de roles del sistema.....................................................................................165
Tabla 34 : Tabla de Historias de Usuario...............................................................................165
Tabla 35 : Priorización de Historias de Usuarios en base a Valor y Costo............................174
Tabla 36 : Tabla de Cuestionario para delimitar el Sprint.....................................................181
Tabla 37 : Tabla de Tareas de la primera Iteración - Sprint 1................................................182
Tabla 38 : Formato de Lista de Impedimentos.......................................................................187
Tabla 39 : Formato de Lista de Retrospectiva: Listado de aspectos a mejorar......................188
Tabla 40 : Objetivos estratégicos ordenados por prioridad de inversión...............................191
Tabla 41 : Priorización de inversión......................................................................................192
Tabla 42 : Servicios Externos del Negocio............................................................................195
Tabla 43 : Servicios Internos del Negocio.............................................................................196
Tabla 44 : Servicios Internos/Externos Identificados............................................................197
Tabla 45 : Descripción de los servicios identificados............................................................197
Tabla 46 : Prioridades de Inversión.......................................................................................198
Tabla 47 : Ficha de Listado de Servicios...............................................................................199
Tabla 48 : Ficha del Servicio [SINT001]...............................................................................200
Tabla 49 : Table 67 : Ficha del Servicio [SEXT001] /..........................................................201
Tabla 50 : Ficha del Requerimiento [SINT001].....................................................................202
Tabla 51 : Ficha del Requerimiento [SEXT001]...................................................................204
Tabla 52: Lista de Riesgos relacionado a la implementación del servicio identificado........212
Tabla 53: Ficha de Requerimientos de Nivel de Servicio SLR.............................................215
Tabla 54: Acuerdo de Nivel de Servicio SLA........................................................................217
Tabla 55: Acuerdo de Nivel Operacional OLA.....................................................................218
Tabla 57 : Requerimiento de Cambio RFC............................................................................222
Tabla 58: Listado de CI’s – Hardware...................................................................................225
Tabla 59: Listado de CI’s – Software....................................................................................225
Tabla 61: Matriz RACI Gestión de Portafolio de Servicios...................................................232
Tabla 62 : Métricas del Proceso de Gestión del Portafolio....................................................233
Tabla 63: Ficha de Listado de Servicios................................................................................234

13
Tabla 64: Ficha de Servicio....................................................................................................234
Tabla 65: Ficha de Requerimiento de Servicio......................................................................236
Tabla 67: Matriz RACI Gestión del Nivel de Servicio..........................................................242
Tabla 68: Métricas del Proceso de Gestión de Nivel de Servicio..........................................244
Tabla 69: de Requerimiento de Nivel de Servicio SLR.........................................................245
Tabla 70: Ficha de Acuerdo de Nivel de Servicio SLA/ Fuente: Elaboración Propia...........247
Tabla 71: Ficha de Acuerdo de Nivel Operacional OLA.......................................................248
Tabla 72:Ficha de Contrato con Terceros UC........................................................................250
Figura 71:Matriz RACI Gestión de Cambios.........................................................................257
Figura 72: Ficha de Requerimiento de Cambio RFC.............................................................264
Tabla 73: Matriz RACI Activos de Servicio y Gestión de Configuración............................270
Tabla 74: Métricas del Proceso de Activos del Servicio y Gestion de la Configuracion......271
Tabla 75: Ficha de Listado de CI’s Hardware.......................................................................272
Tabla 76: Ficha de Listado de CI’s Software.........................................................................272
Tabla 77: Matriz RACI Gestión de Incidentes.......................................................................280
Tabla 78: Listado de GAPs....................................................................................................297

14
INTRODUCCIÓN

Hoy en día la gran mayoría de empresas enfrentan el desafío de encontrar un balance entre la
innovación del negocio y la excelencia operacional. Por tal motivo, es frecuente que las
organizaciones apuesten por mejorar sus procesos operativos apoyándose de las tecnologías
de la información, pero muchas veces comenten el error de no invertir el esfuerzo adecuado
en alinear las soluciones tecnológicas a los objetivos organizacionales, de tal manera que
nuestro objeto de estudio, Honda del Perú S.A., no es ajena a ella.

En la actualidad, contamos con el servicio HUB de repuestos, que tiene como objetivo
abastecer las necesidades de repuestos a las filiales de Honda Corp. ubicadas en
Latinoamérica. Por consiguiente, es necesario realizar evaluaciones continuas para identificar
oportunidades de mejoras en los procesos operativos de abastecimiento y despacho de
productos, con el fin de satisfacer la alta demanda de la corporación, apoyados en la gestión
de planeamiento de compras que en base a proyecciones se abastece de productos que
servirán posteriormente para cubrir la demanda requerida pero en caso no contar con stock,
interviene el procesos de abastecimiento de pedidos comerciales pendientes de atención
(BackORder). Por lo expuesto anteriormente, este proyecto tiene la finalidad de presentar una
propuesta de mejora para el proceso de Gestión de Planeamiento (GPL) teniendo como
campo de acción, satisfacer de manera planificada el abastecimiento de pedidos comerciales
pendientes de atención (BackOrder). Para ello utilizaremos el marco de trabajo TOGAF para
el desarrollo de la Arquitectura empresarial.

Además, como parte del trabajo desarrollado en este proyecto se analiza como el desarrollo
ágil de software basado en el desarrollo iterativo e incremental, proponer mayor fluidez en la
gestión y desarrollo de software.

También, se detalla como los lineamientos y las buenas prácticas que propone ITIL apoyarán
en lo que respecta a la gestión de los servicios.

Al final de éste trabajo se contará con una propuesta de mejora que brindará valor al negocio
y estará completamente alineada a los objetivos estratégicos de la organización.

15
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS

MARCO TEÓRICO
El presente marco teórico desarrolla los aspectos teóricos que servirán como fundamento para
comprender todos los elementos que conformarán la propuesta de mejora del proceso de
Gestión de Planeamiento GPL.

ARQUITECTURA EMPRESARIAL
La arquitectura empresarial en el contexto de la tecnología de la información (TI) comprende
la necesidad de alinear las decisiones en tecnología de información hacia las necesidades de
la organización con la finalidad de justificar las inversiones en proyectos de tecnología de
información. Por el cual, nos permite observar como las estrategias, metas y tecnología están
relacionadas y mostrar la interdependencia entre ellas.

Figura 1: Componentes de la arquitectura empresarial

Fuente: Componentes de la Arquitectura

16
TOGAF1
Marco de trabajo cuyo enfoque otorga las bases para el diseño, implementación,
mantenimiento y gobierno de una arquitectura.

El Método de Desarrollo de Arquitectura o ADM por sus siglas en inglés, es el método


definido por TOGAF para el desarrollo de una arquitectura empresarial, este puede ser
ajustado y personalizado según las necesidades propias de la organización y una vez definido
se utiliza para gestionar la ejecución de las actividades de desarrollo de la arquitectura. El
siguiente diagrama representa el conjunto de fases que comprenden el Ciclo de Desarrollo de
la Arquitectura Empresarial:

Figura 2: Método de desarrollo de Arquitectura

Fuente: The Open Group

El proceso ADM es iterativo y cíclico. Cada paso inicia con la verificación de los
requerimientos. La fase C involucra una combinación de Arquitectura de Datos y

1
TOGAF Version 9.1 / 1a ed. Zaltbommel : Van Haren Publishing,
2011 ( 004.22 OPEN )

17
Arquitectura de Aplicaciones. Cualquier información adicional relevante que se pueda
recopilar entre los pasos B y C ayudarán a perfeccionar la Arquitectura de Información. [03]

Tabla 1: Fases de la metodología de desarrollo de la arquitectura


Fase de ADM Actividad

Prepara la organización para llevar a cabo


proyectos exitosos de arquitectura gracias al
uso de TOGAF. Emprende las actividades de
iniciación y preparación requeridas para
crear la Capacidad Arquitectónica,
incluyendo la adaptación de TOGAF, la
selección de herramientas y la definición de
Principios de Arquitectura

Cada etapa de un proyecto de TOGAF está


basada en los requerimientos del negocio,
incluyendo su validación. Los
requerimientos se identifica can, se
almacenan y se gestionan al ingreso y egreso
de las Fases relevantes del ADM, las cuales
eliminan, abordan, y priorizan los
requerimientos.

Establece el alcance, las limitaciones y


expectativas de un proyecto de TOGAF.
Crea la Visión de la Arquitectura. Identifica
a los Interesados. Valida el contexto de
negocio y crea la Declaración de Trabajo de
Arquitectura. Obtiene aprobaciones

18
Fase de ADM Actividad

Desarrolla arquitecturas en cuatro dominios:


1. Negocio

2. Sistemas de Información - Aplicaciones

3. Sistemas de Información - Datos

4. Tecnología

En cada caso, desarrolla la Arquitectura de la


Línea de Base y de Destino y analiza las
brechas entre ambas.

Realiza la planificación de la
implementación inicial y la identificación de
medios de entrega para los Bloques de
Construcción identificados en las Fases
anteriores. Determina si se requiere un
enfoque incremental, y si así fuera, identifica
las Arquitecturas de Transición

Desarrolla el Plan detallado de


Implementación y Migración que aborda
cómo moverse de la Arquitectura de la Línea
de Base a la Arquitectura de Destino.

Proporciona supervisión arquitectónica para


la implementación. Prepara y publica
Contratos de Arquitectura. Asegura que el
proyecto de implementación esté en
conformidad con la arquitectura.

19
Fase de ADM Actividad

Proporciona seguimiento continuo y un


proceso de gestión de cambios para asegurar
que la arquitectura responda a las
necesidades de la empresa y que se
maximice el valor de la arquitectura para el
negocio.

Fuente: Fases ADM

METODOLOGÍAS ÁGILES2
Las metodologías ágiles son métodos de desarrollo de software en los que las necesidades y
soluciones evolucionan a través de una colaboración estrecha entre equipos
multidisciplinarios. Se caracterizan por enfatizar la comunicación frente a la documentación,
por el desarrollo evolutivo y por su flexibilidad.

Estas metodologías surgen a principios del 2001 en respuesta a los modelos de proceso
clásicos ya existentes. La aparición de procesos ágiles se debe al hecho de haber encontrado
estos supuestos clave en desarrollos precedentes:

1. Es difícil predecir qué requisitos persistirán y cuales cambiarán, así como las prioridades
del cliente.
2. El diseño y el desarrollo de software están intercalados. Por ello se realizarán
conjuntamente, probando el diseño a medida que se crea, pues es complicado predecir
cuánto diseño es necesario antes de llegar a implementarlo.
3. El análisis, el diseño y la implementación no son predecibles desde el punto de vista de la
planificación. [04]

2
Metodologías Agiles de Desarrollo de Software, (2016)
https://es.wikiversity.org/wiki/Metodolog%C3%ADas_%C3%A1giles_de_desarrollo_software
(Consulta: 13 de Noviembre)

20
El Manifiesto Ágil3
Los Principios de las metodologías agiles son:

 Individuos e interacciones sobre procesos y herramientas

 Software funcionando sobre documentación extensiva.

 Colaboración con el cliente sobre negociación contractual.

 Repuesta ante el cambio sobre seguir un plan.

Al individuo y a las interacciones del equipo de desarrollo sobre el proceso y las


herramientas. La gente es el principal factor de éxito de un proyecto de software. Si se sigue
un buen proceso de desarrollo, pero el equipo falla, el éxito no está asegurado; sin embargo,
si el equipo funciona, es más fácil conseguir el objetivo final, aunque no se tenga un proceso
bien definido. Así mismo, las herramientas (compiladores, depuradores, control de versiones)
son importantes para mejorar el rendimiento del equipo, pero el disponer de más recursos de
los estrictamente necesarios también puede afectar negativamente.

Desarrollar software que funciona más que conseguir una buena documentación. Aunque
se parte de la base de que el software sin documentación es un desastre, la regla a seguir es
“no producir documentos a menos que sean necesarios de forma inmediata para tomar una
decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental. Si
una vez iniciado el proyecto, un nuevo miembro se incorpora al equipo de desarrollo, se
considera que los dos elementos que más le van a servir para ponerse al día son: el propio
código y la interacción con el equipo.

La colaboración con el cliente más que la negociación de un contrato. Las características


particulares del desarrollo de software hacen que muchos proyectos hayan fracasado por

3
Manifiesto para el Desarrollo Ágil de Software, (2016) http://www.agilemanifesto.org

21
intentar cumplir plazos Método Ágil Scrum Aplicado al desarrollo de un software de
Trazabilidad María Laura Citón 13 Universidad de Mendoza y costes preestablecidos al
inicio del mismo, según los requisitos que el cliente manifestaba en ese momento. Por ello, se
propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta

Colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito.

Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a
los cambios que puedan surgir a lo largo del proyecto (en los requisitos, la tecnología, el
equipo) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación debe
ser flexible para poder adaptarse a los cambios que puedan surgir. Una buena estrategia es
hacer planificaciones detalladas para unas pocas semanas y planificaciones mucho más
abiertas para unos pocos meses. [05]

Principios Metodológicos
Existe una denominada Alianza Ágil que define los siguientes 12 principios para toda
metodología ágil:

1. Satisfacer al cliente con entregas tempranas y continuas de software valioso.


2. Los requisitos cambiantes son bienvenidos, incluso en fases tardías del desarrollo.
3. Entregar con frecuencia software funcionando, -de dos semanas a dos meses,- cuanto
antes se haga mejor.
4. El cliente y los desarrolladores deben trabajar juntos a diario a lo largo del proyecto.
5. Individuos motivados. Darles el ambiente y el soporte que necesitan, y confiar en ellos
para obtener el trabajo realizado.
6. El método más eficiente y efectivo de transmitir información hacia y dentro del equipo es
la conversación cara a cara.
7. El software en funcionamiento es la medida principal de progreso.
8. El desarrollo debe ser sostenible. Los participantes deben ser capaces de mantener un
paso constante de manera indefinida.
9. Atención continúa a la excelencia técnica y a un buen diseño.
10. La simplicidad es esencial, maximizando el avance del trabajo no realizado.

22
11. Las mejores arquitecturas, los mejores requisitos y los mejores diseños emergen de
equipos auto-organizados.
12. A intervalos regulares el equipo refleja la forma en que se puede volver más efectivo,
entonces su comportamiento se ajusta y adecua en concordancia. [04]

Algunas Metodologías y marcos de trabajo agiles


A continuación citaremos algunas metodologías de desarrollo ágil más populares:

 Extreme Programming: La programación extrema o eXtreme Programming, también


conocida como XP, es una metodología de desarrollo de la ingeniería de software
formulada por Kent Beck [35].

 Scrum: Es un marco de trabajo usado para gestionar el desarrollo y el mantenimiento de


productos software [12].

 Desarrollo Adaptativo de Software: Esta es una metodología de desarrollo de software,


que surgió de una metodología de desarrollo rápido para aplicaciones impulsada por Jim
Highsmith y Bayer Sam. ASD incorpora el principio de la adaptación continua, que el
proceso de adaptación al trabajo en cuestión es el estado normal de cosas [36]

 Modelado Ágil (Agile Modeling): Modelado Ágil es una metodología basada en la


práctica para el modelado y eficaz documentación de los sistemas basados en
software[04].

 Dynamic Systems Development Method (DSDM): Es uno de los principals enfoques


agiles, que reúne la agilidad y flexibilidad necesarias para las organizaciones exitosas de
hoy en un marco del nivel adecuado de gobierno del proyecto. Además, es importante
mencionar que DSDM fue diseñado para ser fácilmente adaptado y usado en conjunto con
otros enfoques agiles como por ejemplo Scrum [37].

23
SCRUM4
Jeff Sutherland y Ken Schwaber conciben el proceso de Scrum en el principios de los 90.
Ellos codificaron Scrum en 1995 con el fin de presentarlo en la conferencia OOPSLA en
Austin, Texas (EE.UU.) y publicaron el documento "Proceso de desarrollo de software
SCRUM".

Ken y Jeff heredaron el nombre de SCRUM el cual es el término que describe una forma para
desarrollar productos iniciada en Japón donde en 1987 Ikujiro Nonaka y Hirotaka Takeuchi
usaron este término, una estrategia utilizada en rugby. Rugby es un juego que no se gana con
una super estrella; ello necesita un equipo, trabajando junto y unido para lograr el éxito. Lo
mismo aplica para el desarrollo de software. Cada miembro del equipo Scrum es de vital
importancia y debe de contribuir en el logro de todo el equipo [07].

Escogieron este nombre por las similitudes que consideraban que existían entre el juego del
rugby y el tipo de proceso que proponían: adaptable, rápido, auto-organizable y con pocos
descansos [11].

¿Qué es SCRUM?
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software en el que se
aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente,
en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan
unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.

4
Scrum Study (2016), Manual de Scrum SBOK. (Consulta 15 de noviembre 2016) (www.scrumstudy.com)

24
En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado
para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde
los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad,
la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo
que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no
es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral
de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar
ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto.

El Proceso de SCRUM
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones que
normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas,
límite máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado
completo, un incremento de producto final que sea susceptible de ser entregado con el
mínimo esfuerzo al cliente cuando lo solicite. [06]

25
Figura 3: Proceso SCRUM

Fuente: Proyectos Agiles

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como
plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le
aportan respecto a su coste y quedan repartidos en iteraciones y entregas.

Las actividades que se llevan a cabo en Scrum son las siguientes:

Planificación de la iteración (Sprint Planning)


El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene dos
partes:

1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de


requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que
surgen y selecciona los requisitos más prioritarios que se compromete a completar en la
iteración, de manera que puedan ser entregados si el cliente lo solicita. [12]
2. Planificación de la iteración (4 horas máximo). El equipo elabora las iteraciones
necesarias para desarrollar los requisitos a que se ha comprometido. La estimación de

26
esfuerzo se hace de manera conjunta y los miembros del equipo se auto asignan las
tareas.[06]
Define las tareas necesarias para poder completar cada objetivo/requisito, creando la lista de
tareas de la iteración (Sprint Backlog) basándose en la definición de completado.

Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.

Cada miembro del equipo se auto asigna a las tareas que puede realizar. [12]

Sprint5
El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o menos
durante el cual se crea un incremento de producto “Terminado”, utilizable y potencialmente
desplegable. Es más conveniente si la duración de los Sprints es consistente a lo largo del
esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la
finalización del Sprint previo.

Los Sprints contienen y consisten de la Reunión de Planificación del Sprint (Sprint Planning
Meeting), los Scrums Diarios (Daily Scrums), el trabajo de desarrollo, la Revisión del Sprint
(Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective).

Durante el Sprint:

 No se realizan cambios que puedan afectar al Objetivo del Sprint;

 Los objetivos de calidad no disminuyen; y,

 El alcance puede ser clarificado y renegociado entre el Dueño de Producto y el Equipo de


Desarrollo a medida que se va aprendiendo más.

Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes. Al igual
que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una definición de
qué se va a construir, un diseño y un plan flexible que guiará la construcción y el trabajo y el
producto resultante. [12]

27
Scrum Diario (Daily Scrum) 6
El objetivo de esta reunión es facilitar la transferencia de información y la colaboración entre
los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en
que se pueden ayudar unos a otros.

Cada miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias
entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir este
objetivo) para al finalizar la reunión poder hacer las adaptaciones necesarias que permitan
cumplir con el compromiso conjunto que el equipo adquirió para la iteración. Esto se lleva a
cabo inspeccionando el trabajo avanzado desde el último Scrum Diario y haciendo una
proyección acerca del trabajo que podría completarse antes del siguiente.

Cada miembro del equipo debe responder las siguientes preguntas en un timebox de cómo
máximo 15 minutos:

 ¿Qué he hecho desde la última reunión de sincronización? ¿Pude hacer todo lo que tenía
planeado? ¿Cuál fue el problema?

 ¿Qué voy a hacer a partir de este momento?

 ¿Qué impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteración y
en el proyecto?

Los Scrum Diarios mejoran la comunicación, eliminan la necesidad de mantener otras


reuniones, identifican y eliminan impedimentos relativos al desarrollo, resaltan y promueven
la toma de decisiones rápida, y mejoran el nivel de conocimiento del Equipo de Desarrollo.
El Scrum Diario constituye una reunión clave de inspección y adaptación. [12]

5 SCHWABER, Ken, SUTHERLAND, Jeff, The SCRUM guide [en línea], [Fecha de consulta:
16/10/2014].

2
Revisión de Sprint (Sprint Review)
Reunión informal donde el equipo presenta al cliente los requisitos completados en la
iteración, en forma de incremento de producto preparado para ser entregado con el mínimo
esfuerzo, haciendo un recorrido por ellos lo más real y cercano posible al objetivo que se
pretende cubrir.

En función de los resultados mostrados y de los cambios que haya habido en el contexto del
proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la
primera iteración, re planificando el proyecto. El Scrum Master se asegura de que el evento
se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a todos a
mantener el evento dentro del bloque de tiempo fijado.

La Revisión de Sprint incluye los siguientes elementos [12]:

 Los asistentes son el Equipo Scrum y los interesados clave invitados por el Dueño de
Producto;

 El Dueño de Producto explica qué elementos de la Lista de Producto se han “Terminado”


y cuáles no se han “Terminado”;

 El Equipo de Desarrollo habla acerca de qué fue bien durante el Sprint, qué problemas
aparecieron y cómo fueron resueltos esos problemas;

 El Equipo de Desarrollo demuestra el trabajo que ha “Terminado” y responde preguntas


acerca del Incremento;

 El Dueño de Producto habla acerca de la Lista de Producto en el estado actual. Proyecta


fechas de finalización probables en el tiempo basándose en el progreso obtenido hasta la
fecha (si es necesario);

 El grupo completo colabora acerca de qué hacer a continuación, de modo que la Revisión
del Sprint proporcione información de entrada valiosa para Reuniones de Planificación de
Sprints subsiguientes.

6
SCHWABER, Ken, SUTHERLAND, Jeff, The SCRUM guide [en línea], [Fecha de consulta:
16/10/2014].

2
 Revisión de cómo el mercado o el uso potencial del producto podría haber cambiado lo
que es de más valor para hacer a continuación; y,

 Revisión de la línea de tiempo, presupuesto, capacidades potenciales y mercado para la


próxima entrega prevista del producto.

Retrospectiva de Sprint (Sprint Retrospective) 7


La Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y antes de la siguiente
Reunión de Planificación de Sprint. Se trata de una reunión restringida a un bloque de tiempo
de tres horas para Sprints de un mes. Para Sprints más cortos se reserva un tiempo
proporcionalmente menor. Con el objetivo de mejorar de manera continua su productividad y
la calidad del producto que está desarrollando, el equipo analiza cómo ha sido su manera de
trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se
comprometió al inicio de la iteración y por qué el incremento de producto que acaba de
demostrar al cliente era lo que él esperaba o no.

El propósito de la Retrospectiva de Sprint es [12]:

 Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y


herramientas.

 Identificar y ordenar los elementos más importantes que salieron bien y las posibles
mejoras.

 Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum
desempeña su trabajo. El Facilitador se encargará de ir eliminando los obstáculos
identificados.[06]

Equipo (Scrum Team)


El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de
Desarrollo (Development Team) y un Scrum Master.

7
SCHWABER, Ken, SUTHERLAND, Jeff, The SCRUM guide [en línea], [Fecha de consulta: 16/10/2014].
Disponible en: http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

3
Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las
oportunidades de obtener retroalimentación. Las entregas incrementales de producto
“Terminado” aseguran que siempre estará disponible una versión potencialmente útil y
funcional del producto [12].

Responsable de transformar el Backlog de la iteración en un incremento de la funcionalidad


del software. Tiene autoridad para reorganizarse y definir las acciones necesarias o sugerir
remoción de impedimentos.

 Auto-gestionado

 Auto-organizado

 Multi-funcional

La dimensión del equipo total de Scrum no debería ser superior a veinte.

El número ideal es diez, más o menos dos. Si hay más, lo más recomendable es formar varios
equipos. No hay una técnica oficial para coordinar equipos múltiples, pero se han
documentado experiencias de hasta 800 miembros, divididos en Scrums de Scrums,
definiendo un equipo central que se encarga de la coordinación, las pruebas cruzadas y la
rotación de los miembros. [06]

Dueño del producto (Product Owner)


El Dueño de Producto es el responsable de maximizar el valor del producto y del trabajo del
Equipo de Desarrollo. El Dueño de Producto es la única persona responsable de gestionar la
Lista del Producto (Product Backlog). La gestión de la Lista del Producto incluye:

 Expresar claramente los elementos de la Lista del Producto.

 Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de
la mejor manera posible.

3
 Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo.

 Asegurar que la Lista del Producto es visible, transparente y clara para todos, y que
muestra aquello en lo que el equipo trabajará a continuación.

 Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al
nivel necesario.

Equipo de desarrollo (Development Team)


Construye el producto que va a usar el cliente, por ejemplo una aplicación o un sitio web. El
equipo en Scrum es “multi-funcional”, tiene todas las competencias y habilidades necesarias
para entregar un producto potencialmente distribuible en cada Sprint, y es “auto organizado”
(auto-gestionado), con un alto grado de autonomía y responsabilidad. En Scrum, los equipos
se auto-organizan en vez de ser dirigidos por un jefe de equipo o jefe de proyecto.

Los Equipos de Desarrollo tienen las siguientes características [12]:

 Son auto organizado. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo
cómo convertir elementos de la Lista del Producto en Incrementos de funcionalidad
potencialmente desplegables;

 Los Equipos de Desarrollo son multifuncionales, contando como equipo con todas las
habilidades necesarias para crear un Incremento de producto.

 Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo, todos son
Desarrolladores, independientemente del trabajo que realice cada persona; no hay
excepciones a esta regla.

 Scrum no reconoce sub-equipos en los equipos de desarrollo, no importan los dominios


particulares que requieran ser tenidos en cuenta, como pruebas o análisis de negocio; no
hay excepciones a esta regla.

 Los Miembros individuales del Equipo de Desarrollo pueden tener habilidades


especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el
Equipo de Desarrollo como un todo.

3
Facilitador (Scrum Master)
Responsable del proceso Scrum, de cumplir la meta y resolver los problemas. Así como
también, de asegurarse que el proyecto se lleve a cabo de acuerdo con las prácticas, valores y
reglas de Scrum y que progrese según lo previsto.

Interactúa con el cliente y el equipo. Coordina los encuentros diarios, y se encarga de


eliminar eventuales obstáculos. Debe ser miembro del equipo y trabajar a la par.

ITIL8

La Biblioteca de Infraestructura de Tecnologías de Información (o ITIL, por sus siglas en


inglés) es un conjunto de conceptos y buenas prácticas usadas para la gestión de servicios de
tecnologías de la información, el desarrollo de tecnologías de la información y las
operaciones relacionadas con la misma en general. ITIL da descripciones detalladas de un
extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a
lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes
del proveedor y han sido desarrollados para servir como guía que abarque toda
infraestructura, desarrollo y operaciones de TI.

8
AXELOS GLOBAL BEST PRACTICE – Consultada en: https://www.axelos.com/best-practice-solutions/itil

3
Breve resumen de la Evolución de ITIL9
Estos son los acontecimientos más importantes de la Biblioteca en su historia y evolución, el
año es una fecha de referencia [32]:

1. 1988. CCTA la Agencia Central de Computación y Telecomunicaciones presenta 52


libros en los que se documentan las mejores prácticas para gestionar tecnología en las
empresas de la administración británica.
2. 1991. El sector privado británico se interesa en la gestión de servicios TI y funda itSMF
(Information Technology Service Management Forum) con autores de los libros, esta
organización se convierte posteriormente en la mayor comunidad para la difusión y la
actualización de la biblioteca.
3. 2000. Se organizan las prácticas en 7 libros. Los más populares resultan ser el Libro de
Provisión y el libro de Entrega de servicios pues son los que documentan los procesos.
Los otros 5 libros se leen muy poco.
4. 2003. itSMF crea un método para evaluar la implantación de los procesos, se publica con
BSI como norma británica BS-15000.
5. 2004. OGC publica un octavo libro para la biblioteca, Software Asset Management,
nunca llegó a reconocerse aunque una de las principales peticiones era incluir prácticas
para el software. En este mismo año se presenta en noviembre BS-15000 a ISO para que
se reconozca como norma internacional.
6. 2005. Se publica en diciembre la Norma ISO/IEC 20000 incluye 10 procesos de ITIL y 3
de sistemas de gestión más una sección llamada “Actuar” para completar el PDCA.
7. 2007. Se publica ITIL v3, alineado al Ciclo de Vida de los Servicios TI. Las fases (libros)
de Estrategia y Mejora Continua representan el mayor cambio.
8. 2011. Se publica una revisión de ITIL v3 y la nueva publicación pasa a llamarse edición.
A partir de ahora no se usan versiones para ITIL, aunque el mercado sigue llamándole
edición 2011. El principal cambio es el refuerzo a la fase de la Estrategia por la
importancia que tiene y la baja adopción. En este mismo año se retiran todas las
referencias y publicaciones basadas en el modelo anterior a 2007.
9. 2013. Cabinet Office firma un Joint Venture con Capital para gestionar la propiedad
intelectual de forma privada y más rápida, la nueva empresa se llama AXELOS.

9
Marlon Molina (2014). Resumen de la Evolución de ITIL. (Consulta 20 de Enero de
(http://www.marlonmolina.com/2014/03/breve-resumen-de-la-evolucion-de-itil-

3
Figura 4: Evolución de ITIL

Fuente: Evolución ITIL

3
Gestión de los Servicios de Tecnología de la información10
La gestión de servicios de tecnologías de la información (en inglés IT Service Management,
ITSM) es una disciplina basada en procesos, enfocada en alinear los servicios de TI
proporcionados con las necesidades de las empresas, poniendo énfasis en los beneficios que
puede percibir el cliente final. GSTI propone cambiar el paradigma de gestión de TI, por una
colección de componentes enfocados en servicios de punta a cabo usando distintos marcos de
trabajo con las mejores prácticas, como por ejemplo la Information Technology Infrastructure
Library (ITIL) o el [eSCM] (enabled Service Capability Model ) [29].

La Gestión de Servicios de TI requiere de una integración correcta de tres factores: personas,


procesos y tecnología [30]

Los proveedores de los servicios de TI no pueden seguir manteniendo su enfoque en la


tecnología y sus propias organizaciones, ahora tienen que considerar la calidad de los
servicios que proveen y enfocarse en sus relaciones con los clientes [31].

Usualmente la gestión de servicios de TI involucra el uso de recursos externos e internos a la


organización y servicios compartidos. Es extremadamente importante mantener una base de
conocimiento amplia dentro de la organización para que estas prácticas sean exitosas.

Los objetivos de una buena gestión de servicios TI han de ser:

 Proporcionar una adecuada gestión de la calidad.

 Aumentar la eficiencia.

 Alinear los procesos de negocio y la infraestructura TI.

 Reducir los riesgos asociados a los Servicios TI.

 Generar negocio.

10
Van Bon, J., ed. (2002). The guide to IT service management. Addison Wesley. ISBN 0-201-73792-2

3
VAN11

El Valor Actual Neto (VAN) consiste en actualizar los cobros y pagos de un proyecto o
inversión y calcular su diferencia. Para ello trae todos los flujos de caja al momento presente
descontándolos a un tipo de interés determinado. El VAN va a expresar una medida de
rentabilidad del proyecto en términos absolutos netos, es decir, en nº de unidades monetarias.

El VAN sirve para generar dos tipos de decisiones: en primer lugar, ver si las inversiones son
efectuables y en segundo lugar, ver qué inversión es mejor que otra en términos absolutos.
[33]

TIR12

La Tasa Interna de Retorno (TIR) es la tasa de interés o rentabilidad que ofrece una inversión.
Es decir, es el porcentaje de beneficio o pérdida que tendrá una inversión para las cantidades
que no se han retirado del proyecto.

La tasa interna de retorno (TIR) nos da una medida relativa de la rentabilidad, es decir, va a
venir expresada en tanto por ciento. El principal problema radica en su cálculo, ya que el
número de periodos dará el orden de la ecuación a resolver. Para resolver este problema se
puede acudir a diversas aproximaciones, utilizar una calculadora financiera o un programa
informático.

11
Economipedia. Definición Valor Actual Neto (VAN) (Consulta 20 de Enero de 2017)
(http://economipedia.com/definiciones/valor-actual-neto.html)

12
Economipedia. Definición Tasa Interna de Retorno (TIR) (Consulta 20 de Enero de 2017)
(http://economipedia.com/definiciones/tasa-interna-de-retorno-tir.html)

3
Criterio de Selección TIR
El criterio de selección será el siguiente donde “k” es la tasa de descuento de flujos elegida
para el cálculo del VAN:

Si TIR > k, el proyecto de inversión será aceptado. En este caso, la tasa de rendimiento
interno que obtenemos es superior a la tasa mínima de rentabilidad exigida a la inversión.

Si TIR = k, estaríamos en una situación similar a la que se producía cuando el VAN era igual
a cero. En esta situación, la inversión podrá llevarse a cabo si mejora la posición competitiva
de la empresa y no hay alternativas más favorables.

Si TIR < k, el proyecto debe rechazarse. No se alcanza la rentabilidad mínima que le pedimos
a la inversión. [34]

3
OBJETO DE ESTUDIO

ORGANIZACIÓN OBJETIVO.

Honda del Perú S.A, fundada el 11 de Enero de 1974, se constituyó como Joint Venture, entre
Honda Motor Co. y accionistas peruanos, es una empresa líder en el Perú dedicada al
ensamblaje, importación y comercialización de automóviles, motocicletas, motocarros,
cuatrimotos, productos de fuerza y sus repuestos y accesorios. Asimismo cuenta con su red de
concesionarios, servicio técnico y repuestos a nivel nacional

Figura 5: Logos de Honda

Fuente: www.honda.com.pe

Honda del Perú S.A., ofrece al mercado peruano productos de calidad con la más alta
tecnología, dentro de las líneas de negocio tenemos, Autos, Productos de Fuerza y sus
respectivos repuestos.

 Automóviles, ofrece 5 modelos de automóviles en sus distintas versiones y colores.

 Motos, ofrece distintos modelos de motocicletas, así como motocarros y cuatrimotos.

3
 Productos de Fuerza, ofrece productos para la industria categorizados por:

- Motores Estacionarios

- Generadores

- Motobombas

- Motoguadañas

- Motofumigadoras

MISIÓN

“Honda del Perú S.A. tiene como misión permanente el ofrecer los productos de la mejor
calidad y avanzada tecnología a precios razonables para la máxima satisfacción de todos sus
clientes y usuarios.”

4
VISIÓN

“Seguir consolidándose dentro de los próximos años como la empresa líder en las diversas
líneas de negocio que ofrece en el mercado peruano, así como por sus aportaciones basadas
en la alta preparación de sus integrantes que ayudarán al ámbito económico y social del País,
gracias a un modelo innovador de ventas y servicio de calidad, el cual nos garantizará un
desarrollo sostenible y creciente.”

4
MAPA DE PROCESOS
A continuación se visualiza en representación gráfica los procesos que se encuentran en el objeto de estudio.

Figura 6: Mapa de Procesos

Fuente : Intranet Honda del Peru

4
OBJETIVOS ESTRATÉGICOS
A continuación se mencionan los objetivos estratégicos de la organización, teniendo como
concepto, impulsar las Fortalezas, aprovechar las Oportunidades, superar las Debilidades y
evitar Amenazas.

 Mejorar las ventas de repuestos al exterior en un 20% con respecto al año 2016.

 Disminuir el tiempo de abastecimiento de BackOrder (pedidos pendientes) en un 30% con


respecto al año 2016.

 Incrementar el ensamblaje de motos en un 10% por modelo con respecto al año 2016

 Incrementar la satisfacción de los empleados en los ambientes de trabajo a un 10% en


relación a la encuesta del 2015.

 Disminuir el porcentaje de renuncias en un 5% en relación al segundo periodo del 2016.

 Disminuir los gastos por subcontratación en un 20% con respecto al año 2016.

4
MATRIZ DE JUSTIFICACIÓN DE LOS OBJETIVOS VRS LOS PROCESOS
A continuación se visualiza la relación en tre los procesos de negocio y los objetivos estrategicos.

Tabla 2: Matriz de Justificación de los Objetivos vs. los procesos

Fuente: Elaboración Propia

4
PROCESOS DEL NEGOCIO
A continuación se indica un detalle a alto nivel de las funciones generarles que se realizan en cada proceso del negocio de la organización.

Tabla 3: Detalle de los Procesos del Negocio

Fuente : Elaboración Propia

4
ORGANIGRAMA

A continuación se visualizar el organigrama actual del objeto de estudio.

Figura 7 : Organigrama del Objeto de Estudio

Fuente : Elaboración Propia

4
ALCANCE DEL PROYECTO
El presente proyecto tiene como alcance realizar una propuesta de mejora para el proceso de
gestión de Planeamiento, mediante el de diseño de una arquitectura empresarial, sólo hasta la
fase E del marco de trabajo TOGAF, realizando el análisis de brechas entre el ASIS y el
TOBE.

Además, se propone la adopción el modelo de referencia SCRUM, que define un conjunto de


prácticas y roles, que serán tomadas como punto de partida para planificar el proceso de
desarrollo de la solución planteada

Así mismo, se propone complementar esta propuesta con un conjunto de conceptos y buenas
prácticas que nos provee ITIL v3. Por ello, se realizará un análisis de los servicios de negocio
impactados por las mejoras para darle una adecuada gestión bajo los lineamientos de ITIL.

Por último, se describirá una propuesta de integración de todo lo mencionado en los párrafos
anteriores.

4
OBJETIVOS DEL PROYECTO

OBJETIVO GENERAL
Diseñar una propuesta de arquitectura empresarial para la mejora del proceso operativo de
Gestión de Planeamiento (GPL) de la empresa Honda del Perú, con la finalidad de agilizar la
gestión, planificación y recuperación de los pedidos comerciales pendientes.

OBJETIVOS ESPECÍFICOS.
 Garantizar el alineamiento entre los objetivos de Negocio con respecto a los procesos de
negocio

 Identificar las limitaciones de tiempo, Organizacionales, financieras y de negocio.

 Identificar la situación actual de la arquitectura contemplando los dominios de negocio,


aplicaciones, datos y tecnología del proceso GLP.

 Identificar el impacto de modificar las aplicaciones asociadas al proceso GLP respecto a


los demás procesos de negocio.

 Identificar el impacto de modificar los datos asociadas al proceso GLP respecto a los
demás procesos de negocio.

 Identificar mediante un análisis de brecha las mejoras que necesita el proceso de “Gestión
de Planeamiento (GPL)” para estar alineado con los objetivos estratégicos de la
organización.

 Identificar las soluciones potenciales que ayuden a disminuir la brecha y los riesgos
potenciales de su implementación.

4
BENEFICIOS DEL PROYECTO
A continuación se mencionan los beneficios que obtendrá la organización cuando se logre
implementar la propuesta indicada en la arquitectura objetivo (TO-BE).

BENEFICIOS TANGIBLES
 Reducción del tiempo gestión de abastecimiento de mercancía para satisfacer las
necesidades del cliente en función a las fechas de llegada de las órdenes de compra que se
encuentran en proceso.

 Disminución de costos por horas extras del planificador de BackOrder.

 Reduce el tiempo de despacho de los BackOrder ya abastecidos.

 Contar con un gobierno de procesos, software, infraestructura y tecnología.

BENEFICIOS INTANGIBLES.
 Ventaja competitiva.

 Satisfacción de la línea de negocio de repuestos por la atención planificada de los


BackOrder.

 Mayor confianza en el equipo de Planificación al contar con una herramienta de


planificación flexible de aprovisionamiento de mercadería.

 Información disponible de fecha estimada de atención de BackOrder de manera ágil y


confiable.

 Mejorar la interacción y comunicación entre el equipo de TI y los usuarios del negocio

4
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL

INTRODUCCIÓN

En el presente capítulo se desarrolla la propuesta de Arquitectura Empresarial del proceso


operacional “Gestión de Planeamiento (GPL)” de Honda del Perú S.A. El análisis se realizara
en base al marco de trabajo TOGAF, en donde se desarrollaran las fases Preliminar, Visión
de la Arquitectura, Arquitectura de Negocio, de los Sistemas, de Tecnología y Oportunidades
y Soluciones. El resultado de este análisis nos da un panorama completo de la situación actual
del proceso analizado; identifica las brechas para alinear el proceso a los objetivos de
negocio; nos da visibilidad de la estructura de entregables de trabajo para lograr la
implementación de la propuesta y finalmente nos genera un cuadro resumen del plan de
migración, el cual nos detalla las soluciones potenciales propuestas, los costos, problemas
que soluciona, los posibles riesgos de su implementación y la brecha que estaría cubriendo la
solución potencial propuesta.

ALCANCE

El proyecto de propuesta de arquitectura es aplicado a la Industria Automotriz Honda del


Perú S.A., quien ofrece al mercado Peruano productos categorizados en las líneas de negocio
y sus respectivos repuestos:

 Automóviles, ofrece 5 modelos de automóviles en sus distintas versiones y colores.

 Motos, ofrece distintos modelos de motocicletas, así como motocarros y cuatrimotos.

 Productos de Fuerza, ofrece productos para la industria categorizados por:

5
- Motores Estacionarios

- Generadores

- Moto bombas

- Moto guadañas

- Moto fumigadoras

El esfuerzo de este proyecto está orientado específicamente a la mejora del proceso de


Gestión de Planeamiento (GPL), proceso que se encarga de la planificación y recuperación de
las órdenes de pedido pendientes por falta de stock. La mejora tiene como objetivo
“emparejar” un pedido B/O (Pedido pendiente por falta de stock) con una o más fuentes de
abastecimiento disponibles con el objetivo de garantizar la recuperación de la cantidad en
B/O con eficiencia y en el menor tiempo posible

Para lograr esta mejora, se propone la implementación de un proyecto de arquitectura


empresarial dentro del marco de trabajo TOGAF, llegando hasta la fase E del Método de
desarrollo de Arquitectura que indica el marco. Para lograr ello, se tiene planificado realizar
todo este análisis y documentación en un periodo tentativo de 100 días.

El resultado de este análisis será dimensionado en los 4 dominios de la arquitectura


empresarial; Arquitectura de Negocios, Arquitectura de aplicaciones, Arquitectura de Datos y
Arquitectura Tecnológica. Identificando finalmente las brechas, estructura de entregables de
trabajo y un cuadro resumen del plan de migración.

5
PRELIMINAR

PRINCIPIOS DE ARQUITECTURA

Principios del Negocio


Tabla 4: Principios del Negocio – PRNEG01

Fuente : Elaboración Propia

Tabla 5: Principios del Negocio

Fuente : Elaboración Propia

5
Principios de Datos
Tabla 6 : Principios de Datos PRDAT01

Fuente : Elaboración Propia

Tabla 7 : Principios de Datos PRDAT02

Fuente : Elaboración Propia

Tabla 8 : Principios de Datos PRDAT03

Fuente : Elaboración Propia

5
Principios de Aplicaciones
Tabla 9 : Principios de Aplicaciones PRAPL01

Fuente : Elaboración Propia

Tabla 10: Principios de Aplicaciones PRAPL02

Fuente : Elaboración Propia

Principios de Tecnología
Tabla 11: Principios de Tecnología PRTEC01

Fuente : Elaboración Propia

5
Tabla 12: Principios de Tecnología PRTEC02

Fuente : Elaboración Propia

5
PETICION DE TRABAJO DE ARQUITECTURA
Esta sección da inicio al ciclo de desarrollo de la arquitectura empresarial planteada para el
proceso de Gestión de Planeamiento de la empresa Honda del Perú S.A. Es aquí donde se
detallarán las principales limitaciones para lograr la implementación de ésta arquitectura
empresarial; así como también, se describirá tanto la situación actual del negocio como la
situación actual de la arquitectura.

Límites de Tiempo
La propuesta se encuentra alineado directamente con el objetivo estratégico “Consolidar el
servicio de Exportación (HUB Repuestos)” y registrado dentro del PDCA de TI. Por ello, se
tiene que identificar que la propuesta de mejoras al proceso de “Gestión de Planeamiento
(GPL)” este implementado dentro del periodo Enero – Mayo 2017

Figura 8: PDCA Sustento Limites de Timepo

Fuente : Elaboración Propia

5
Limitaciones organizacionales
La propuesta esta demarcada únicamente dentro del proceso operacional de Gestión de
Planeamiento (HUB - Repuestos) de la empresa Honda del Perú S.A. Todas las solicitudes de
compra para abastecimiento de stock de Honda del Perú S.A. son únicamente a Honda Japón.

Limitaciones Financieras
El presupuesto definido para proyectos de innovación y mejoras de procesos para el año 2016
es de 100,000 dólares asignados al proceso de negocio “Gestión de Planeamiento (GPL)”.
Estos límites no deben de ser excedidos por ningún proyecto dentro del proceso indicado.

Limitaciones externas y de negocio


La propuesta se encuentra alineado directamente con el objetivo estratégico “Consolidar el
servicio de Exportación (HUB Repuestos)” registrado dentro del PDCA de TI con fecha de
atención dentro del periodo Septiembre 2016 a Marzo 2017

Figura 9: PDCA Sustento Limitaciones Externas y de Negocio

Fuente : Elaboración Propia

5
Descripción de la Situación actual del Negocio
Actualmente Honda del Perú S.A. continúa apostando en el crecimiento y solidez de su red
de concesionarios. Este crecimiento implica que la organización debe también preocuparse y
estar preparada para soportar el crecimiento de la demanda de los clientes. Por tanto, para
lograr ello, la organización ha incorporado a sus procesos operativos y de soporte las
bondades que provee el ERP SAP.

Uno de los procesos operacionales que es soportado por SAP es el de Gestión de


Planeamiento, el cual es el proceso analizado en este proyecto de arquitectura empresarial,
que se encarga de gestionar aquellos pedidos que quedaron pendientes debido a una falta de
Stock.

Los principales problemas identificados en la organización dentro del análisis del proceso
actual son:

 Se reciben constantemente quejas de los clientes debido a las demoras en la entrega de


mercaderías.

Figura 10: Tiempo Actual de Abastcimiento de BackOrder

Fuente : Elaboración Propia

 La poca participación de TI dentro de las iniciativas de negocio es un factor que dificulta


el alineamiento estratégico y el logro eficaz de los objetivos estratégicos.

 Los clientes no cuentan con la información del estado de su pedido, ni con una fecha de
entrega confiable para poder proyectarse.

 Se verifica una necesidad de mejora dentro del proceso de Gestión de Planeamiento,


debido a que se verifica constantemente una demora en abastecimiento de mercancías que

5
se toma para la recuperación de los pedidos pendientes (B/O) debido a que sólo se toma
en cuenta con los stocks de los almacenes locales.

 Se verifica que durante la recepción de las mercancías, éstas son enviadas directamente al
stock libre local; por consiguiente estos productos pueden ser tomados por cualquier
nuevo pedido, lo cual no permite cubrir de forma eficiente una adecuada recuperación de
los pedidos pendientes.

Descripción de la situación actual de la arquitectura de TI


Actualmente, el proceso de Gestión de Planeamiento es soportado por las funcionalidades
estándares del módulo Management Material (MM) del ERP SAP R3. El proceso de gestión
de planeamiento nace con la generación de una solicitud de Pedido de mercancías
(Repuestos) desde algún concesionario a nivel regional, hasta el momento (Argentina, Brasil
y Chile), la cual es realizada mediante desde una aplicación web, llamada SAP Dealer Portal.
Este aplicativo se comunica al servidor de BD ubicada en Brasil, en donde se valida el stock
de las mercancías en los almacenes de Perú. Por consiguiente, cuando algún pedido no es
entregado en su totalidad debido a la falta de mercancías en almacén, aparece la necesidad de
planificar la recuperación de las mercancías pendientes (Backorders). Es aquí donde se
evidencia una constante demora en la recuperación del stock en almacén de las mercancías, lo
cual genera continuamente retrasos en la entrega de los productos pendientes (Backorders).
Por otro lado, la planificación que se maneja actualmente está únicamente asociada a generar
una nueva solicitud de compra y no se contemplan otras fuentes de abastecimientos como lo
son aquellas solicitudes de compra que ya se encuentran en proceso.

El ERP SAP R3 y el aplicativo SAP Dealer Portal se encuentran alojados en un servidor


Linux (SAP – IBM AIX 5.3 – 7.1) ubicado en Brasil. De igual forma, la Base de Datos que
soporta a SAP es también un servidor Linux y está ubicada en Brasil.

La planificación y recuperación de las mercaderías pendientes son realizadas desde la LAN


SAN ISIDRO en Perú.

Desde el modulo MM de SAP se pueden generar solicitudes de compra de mercancías


(Repuestos) hacia la sede principal de Honda en Japón.

5
VISIÓN DE LA ARQUITECTURA
A continuación se declara a alto nivel las capacidades y valor del negocio que se desea
obtener como resultado de la Arquitectura Empresarial propuesta.

DECLARACION DE TRABAJO DE ARQUITECTURA

Descripción del proyecto de arquitectura y alcance


El proyecto de arquitectura es aplicado a la Industria Automotriz Honda del Perú S.A., quien
ofrece al mercado Peruano productos categorizados en las líneas de negocio y sus respectivos
repuestos:

 Automóviles, ofrece 5 modelos de automóviles en sus distintas versiones y colores.

 Motos, ofrece distintos modelos de motocicletas, así como motocarros y cuatrimotos.

 Productos de Fuerza, ofrece productos para la industria categorizados por:

- Motores Estacionarios

- Generadores

- Moto bombas

- Moto guadañas

- Moto fumigadoras

El esfuerzo de este proyecto está orientado específicamente a la mejora del proceso de


Gestión de Planeamiento, proceso que se encarga de la planificación y recuperación de las
órdenes de pedido pendientes por falta de stock. La mejora tiene como objetivo “emparejar”
un pedido B/O (Pedido pendiente por falta de stock) con una o más fuentes de abastecimiento
disponibles con el objetivo de garantizar la recuperación de la cantidad en B/O con eficiencia
y en el menor tiempo posible

6
Para lograr esta mejora, se implementará un proyecto de arquitectura empresarial dentro del
marco de trabajo TOGAF, llegando hasta la fase E del Método de desarrollo de Arquitectura
que indica el marco. Se tiene planificado realizar todo este análisis y documentación en 26
días hombre.

EL resultado de este análisis será dimensionado en los 4 dominios de la arquitectura


empresarial; Arquitectura de Negocios, Arquitectura de aplicaciones, Arquitectura de Datos y
Arquitectura Tecnológica. Identificando finalmente las brechas, estructura de entregables de
trabajo y un cuadro resumen del plan de migración.

Procedimiento específico para cambios de alcance


A continuación se muestra el diagrama de procedimiento específico para realizar algún
cambio de alcance.

Figura 11: Procedimiento para Cambios de Alcance

Fuente : Elaboración Propia

 Los cambios pueden ser identificados y solicitados por cualquiera de los interesados
mediante un formato de solicitud de cambio.

 Todo cambio de alcance tiene que estar indicado en una “Solicitud de Cambio”, la misma
que sera analizada, evaluada, aprobada ó rechazada por el Comité de Cambios, integrada
por un grupo de interesados formalmente constituidos.

 La aprobación técnica tiene por finalidad validar la viabilidad del cambio, para ello el
comité se apoya en los especialistas correspondientes para esta validación, para ello

6
contempla las 4 principales dimensiones de la arquitectura, negocio, aplicación, datos e
infraestructura.

 El analisis cuantitativo del cambio, se enfoca en los factores:Tiempo, recursos y costos.

 Una vez aprobado cada cambio, la solución pasa a formar parte del las responsabilidades
del equipo de proyecto.

 EL equipo de proyecto es responsable de ajustar su planificación para contemplar los


cambios que son aprobados.

 El equipo de proyecto es el responsable de comunicar el cambio a los interesados.

Tabla 13: Formato de Solicitud de Cambio

<Nro Ticket> - < Descripción Breve Solicitud de Cambio >

1.- INFORMACIÓN GENERAL

Alta Media Baja Fecha RQ


Tema Prioridad
Emergencia

Dueño del <nombre responsable del


Sistema/Módulo MM Creador
Proceso proceso>

Estado Analista
Transacción/Menú -
RFC Honda

Clasificación

EspecificaciónFuncional SolicituddeCambio Incidente

Situación Actual Situación Deseada

Objetivos: (Cómo impacta al Negocio)

6
Descripción del Cambio

Escenarios de Pruebas

Plan de Despliegue

Actividad Responsable Hora Inicio Hora Fin

Plan de Rollback

Actividad Responsable Hora Inicio Hora Fin

Aprobaciones

Fuente: Intranet de Honda del Peru

6
Roles, responsabilidades y entregables.

A continuación se muestra la matriz de responsabilidades en el que se establece las


responsabilidades de cada rol que participa en un entregable del proyecto.

Tabla 14: Matriz Raci Roles, responsabilidades y Entregables

Roles

Arquitecto Informacion

Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider

Actividades

Definir los Principios de Negocio A/I R

Definir los Principios de Datos A/I R

Definir los Principios de A/I R


Aplicaciones

Definir los Principios de I C R


Tecnología

Generar documento de principios R


de arquitectura

Identificar restricciones para la R C C C


implementación de AE

Identificar los principales A/I R


problemas del Negocio

Analizar la situación actual de la R/A


arquitectura TI

6
Roles

Arquitecto Informacion

Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades

Generar Documento de Petición R/A C


de Trabajo de Arquitectura
Preliminar

Descripción del alcance del R/A C C C


proyecto de arquitectura

Definir procedimiento de R
cambios de alcance

Definir roles, responsabilidades y R/I C C C


entregables

Definir criterios de aceptación R/I C C C

Desarrollar cronograma tentativo R/I C C C

Generar Documento de R/A C C C


Declaración de Trabajo de la
Arquitectura

Recopilar lista de interesados y R/I C C C


Visión de la
preocupaciones
Arquitectura

Recopilar lista de asuntos a R/I C C C


abordarse

Generar Documento de Visión de R/A C C C


la Arquitectura

Generar Matriz Objetivos del A/I R


Negocio VS Procesos (Línea

6
Roles

Arquitecto Informacion

Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades

Base y Destino)

Realizar Diagrama de A/I R


Actividades y detalle del proceso
negocio analizado(Línea Base y
Destino)

Generar Matriz RACI del A/I R


Proceso seleccionado (Línea Base
y Destino)

Crear Modelo de Datos (Línea A/I R


Base y Destino)

Crear Matriz de datos del Proceso A/I C R


Analizado VS. Procesos de
Negocio (Línea Base y Destino)

Crear Diagrama de aplicaciones y A/I R


Descripción (Línea Base y
Destino)

Crear Matriz de aplicaciones de A/I C R


proceso analizado VS. Procesos
de Negocio (Línea Base y
Destino)

Detallar los Componentes de A/I C R


tecnología y sus relaciones con
los sistemas de información
Documento de
(Línea Base y Destino)
Definición de

6
Roles

Arquitecto Informacion

Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades

Arquitectura Describir la Plataforma de A/I C R


tecnología y su descomposición
(Línea Base y Destino)

Detallar los Ambientes y A/I C R


ubicaciones (Línea Base y
Destino)

Detallar las Especificaciones de A/I C R


hardware y red (Línea Base y
Destino)

Análisis de Brecha R/A C C C

Evaluación de impacto R/A C C C

Generar Documento de definición R/A C C C


de la arquitectura

Identificar entregables del R/I


proyecto

Generar Estructura de desglose R/I


del trabajo

Plan de Generar Cuadro resumen del plan R/I C C C


Implementación y de Migración
Migración
Generar Documento Plan de R/A C C C
implementación y Migración

Acta de Constitución R

6
Roles

Arquitecto Informacion

Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades

Plan de Gestión de Alcance R C C C

Plan de Gestión del cronograma R C C C

Plan de Gestión de Costos R

Plan de Gestión de Calidad R

Plan de Gestión del Personal R

Plan de Gestión de R
Comunicaciones

Plan de Gestión de Riesgos R

Plan de Gestión de Adquisiciones R C


Gestión de Proyecto
Informes de Ejecución del R
Proyecto

Reunión de Seguimiento y R
Control

Actas de Reunión de seguimiento R


y control

Acta de Cierre de Proyecto R

Fuente : Elaboración Propia

6
Descripción de Roles:
Arquitecto Líder: Es el encargado de apoyar en la estrategia de negocio, mediante una
adecuada gestión de la información y de las soluciones de TI. El arquitecto líder es la mano
derecha del gerente de TI, de modo que sus inversiones estén alineados con la estrategia de
negocio de la organización.

EL arquitecto líder cuenta con conocimientos de TI, habilidades de negociación, liderazgo y


conocimientos de gestión de proyectos. Es quien se encarga de la definición de las reglas de
negocio en los 4 dominios de la información. Además, es quien se encarga de Generar
Documento de Declaración de Trabajo de la Arquitectura y de Generar Documento Plan de
implementación y Migración.

Arquitecto de negocio: En este rol, el arquitecto tiene gran conocimiento de cómo trabaja la
organización. El arquitecto de negocio es pieza importante en el modelado de procesos de
negocio. Tienen una visión clara de cómo los sistemas de información apoyan al negocio, y
en conjunto con el arquitecto empresarial, sugieren mejoras. El arquitecto de negocio posee
conocimientos de modelado de procesos de negocio, análisis de requerimientos y de
liderazgo.

Arquitecto de Sistemas de Información: En este rol, el arquitecto de sistemas de


información planifica los elementos individuales del sistema de información. Estos elementos
contemplan a las aplicaciones y a los datos que las aplicaciones utilizan. El arquitecto de
información estudia las necesidades del cliente, hace un análisis del estado actual y futuro de
las aplicaciones.

Arquitecto de Tecnología: En este rol, el arquitecto se encarga de definir la estrategia y las


bases de una arquitectura tecnológica de TI que soportarán las distintas soluciones de
negocio. Además, tiene como tarea definir los mecanismos de almacenamiento de
información, las redes de datos y vela por la integración de los servicios de tecnología.

6
Criterios de aceptación
A continuación se describen los entregables para cada una de las dimensiones, los cuales
se constituyen en los criterios de aceptación. Los siguientes entregables deben de
contemplarse tanto para la arquitectura actual como para la de destino:

Dimensión de Negocio:

 Modelado del proceso de Negocio debe ser diseñado utilizando BPMN

 El diagrama de actividades del modelo de negocio debe estar aprobado por el Arquitecto
Líder

 Roles de Negocio deben de ser descritos en función de las responsabilidades y


entregables mediante una Matriz RACI

Métodos
Dentro de los criterios de aceptación se busca garantizar que los entregables cumplan con los
declarados dentro del marco de trabajo de TOGAF.

Dimensión de Arquitectura de Aplicaciones


Para este dominio los criterios de aceptación son definidos de acuerdo con el marco de
trabajo TOGAF en el cual se validará el cumplimiento de los siguientes entregables tanto
para la arquitectura actual como para la de destino:

 Se debe de generar en tiempo y forma el Diagrama de Aplicaciones que son parte del
alcance, para identificar sus interrelaciones y dependencias. Esta vista debe de contar con
la aprobación respectiva del arquitecto líder.

 Garantizar mediante una Matriz de Aplicaciones o Módulos del proceso seleccionado vs.
Proceso de Negocio el posible impacto sobre los procesos de negocio que podría generar

7
la modificación y/o creación de nuevas aplicaciones. Se debe de contar con la aprobación
del Arquitecto líder de este análisis.

 Contemplar el uso de las mejores prácticas definidas por los lineamientos de Honda Perú
para el diseño y desarrollo de aplicaciones.

 Se debe de contar con la aprobación del Arquitecto líder

Dimensión de Arquitectura de Datos


Dentro de los criterios de aceptación a evaluar se validará el cumplimiento de los entregables
tanto para la arquitectura actual como para la de destino.

 Se debe de generar en tiempo y forma los Diagramas de Datos Físico o Lógico, lo cuales
deben de ser aprobados por el arquitecto Líder.

 Garantizar mediante una Matriz de Datos del proceso seleccionado vs. Proceso de
Negocio el posible impacto sobre los procesos de negocio. Se debe de contar con la
aprobación del Arquitecto líder de este análisis.

Dimensión de Arquitectura Tecnológica


Dentro de los criterios de aceptación a evaluar se validará el cumplimiento de los siguientes
entregables tanto para la arquitectura actual como para la de destino. Estos entregables deben
de cumplir con las respectivas aprobaciones del arquitecto líder y deben ser entregados en los
tiempos definidos por el proyecto. Cualquier cambio debe de ser comunicado a los
interesados correspondientes:

 Componentes de tecnología y sus relaciones con los sistemas de información.

 Plataforma de tecnología y su descomposición.

 Ambientes y ubicaciones – agrupamiento de las tecnologías requeridas para cada


ambiente informático (Desarrollo, test, producción).

 Comunicaciones físicas (red)

 Especificaciones de hardware y red

7
CRONOGRAMA TENTATIVO

Figura 12: Cronograma tentativo del proyecto

7
7
7
Fuente : Elaboración Propia

7
VISION DE LA ARQUITECTURA

Interesados y sus preocupaciones


Identificar a los interesados o stakeholders es el proceso que tiene como objetivo la
identificación de todas las personas u organizaciones que se verán impactadas por el
proyecto, así como la documentación de información relevante relativa a sus intereses,
participación e impacto en el éxito del proyecto.

Es fundamental para el éxito del proyecto el identificar a los interesados desde el comienzo
del mismo, así como analizar sus niveles de interés, expectativas, importancia e influencia.
Esto permitirá incrementar el apoyo y soporte al proyecto y minimizar el impacto negativo
sobre éste.

Figura 13: Matriz Poder / Interes

Fuente : Matriz Interes/Poder [22]

7
Lista de Interesados

Tabla 15: Lista de Interesados


Parte Interesada Necesidades Interés Poder

Cliente Reducir el tiempo de entrega de sus Mucho Poco


pedidos de mercaderías.

Contar con información más segura


de los tiempos de entrega y estados
de sus pedido

Gerente Comercial Mejorar la satisfacción del cliente Mucho Mucho


del cliente

Incrementar las ventas de


mercancías.

Jefe de Planificación Mejorar los procedimientos de Mucho Medio


planificación y recuperación de B/O

Disminuir el trabajo operativo del


planificador al contar con una
herramienta que le permita
planificar la recuperación de los
pedidos pendientes (B/O).

Jefe de Logística Mejorar el aprovisionamiento de los Mucho Medio


stocks reservados y disponibles
mediante una herramienta que
permita una adecuada recuperación
de los B/O HUB.

Planificador Reducir el tiempo operativo en la Mucho Poco


gestión de planificación de B/O

7
Parte Interesada Necesidades Interés Poder

Gerente TI Velar porque los proyectos de TI se Mucho Mucho


enfoquen a los objetivos
estratégicos de la empresa.

Estandarizar los desarrollos de


soluciones TI.

Información relacionada al estado


de ejecución del proyecto y fases de
la arquitectura.

Gerente proyecto Mucho Medio

Gestionar e integrar todas las etapas


del proyecto.

Poseer una arquitectura como apoyo


de trato frente a los equipos de
trabajo de la institución.

Gestionar la adquisición de nuevas


tecnologías sin temor a
incompatibilidades con los sistemas
actuales.

Analista de Negocio Contar con un repositorio de donde Medio Poco


se puedan verificar todos los
procesos de negocio y sus
dependencias.

Analistas TI Medio Poco

7
Parte Interesada Necesidades Interés Poder

Conocer la metodología y principios


de arquitectura que acogen la
institución.

Conocer los procesos que serán


soportados por la arquitectura.

Contar una matriz de aplicaciones


vs procesos con la finalidad de
poder medir impactos con mayor
rapidez.

Analistas de calidad Medio Poco

Conocer la metodología y principios


de arquitectura que acogen la
institución.

Conocer el proceso de
implementación de la arquitectura,
validando sus fases.

Arquitecto Negocio Conocer las fases que serán Mucho Medio


desarrolladas para la
implementación de la arquitectura
empresarial.

Conocer los objetivos estratégicos


para favorecer la arquitectura
empresarial.

Implementar una adecuada

7
Parte Interesada Necesidades Interés Poder

gobernabilidad de los procesos de


negocio.

Arquitecto de Sistemas Controlar y estandarizar las Mucho Medio


de Información estructuras de datos lógicos y físicos
de la organización.

Diseñas soluciones de mejora al


requerimiento propuesto a dar
solución.

Velar por una adecuada trazabilidad


de aplicaciones vs. Procesos de
negocio.

Creación y distribución de
estándares de desarrollo.

Arquitecto de Gestionar una adecuada Mucho Medio


tecnología gobernabilidad de las tecnologías
utilizadas por la organización.

Administrador de base Medio Poco


de datos
Conocer y entender el modo de
operación de la aplicación sobre la
infraestructura de datos.

Administrar y proveer al equipo de


desarrollo y pruebas los
mecanismos de acceso respectivo a
las BDs.

8
Parte Interesada Necesidades Interés Poder

Equipo de desarrollo Poco Poco

Conocer los requerimientos


funcionales de la plataforma a
construir, su alcance, dependencias
y protocolos.

Conocer los principios de


arquitectura en cuanto a sistemas de
información (aplicaciones).

Tener sólidos conocimientos a la


hora de desarrollar o empezar a
construir la plataforma.

Equipo de Poco Poco


infraestructura
Conocer y entender el modo de
tecnológica
operación de la aplicación sobre la
infraestructura en cuanto hardware
y comunicaciones.

Proveer al equipo de desarrollo los


mecanismos de hardware que
permitan su mejor desempeño

Fuente: Elaboración Propia

8
Lista de asuntos / escenarios que deben abordarse

Figura 14: Lista de Asuntos y Escenario que deben abordarse


Incremento de
Reducir tiempo de competitividad
entrega de respecto a la
mercaderias competencia

Informar a cliente del estado de


Orientado
sus pedidos
al Proceso Gestion Planificación
Orientados a los objetivos Mejorar satisfaccion del cliente

La recuperacion de Pedidos pendientes B/O no es eficiente

Mejora de aprovisionamiento de mercaderías en la recepción de pedidos de compra

Orientado a imlementar una Arquitectura empresarial


Alinear iniciativa TI con los objetivos estrategicos

Asunto a Abordarse Mejorar la interacion de TI con el Negocio

Gobierno de Procesos de negocio

Creacion y distribucion de Estandares de Desarrollo

Gobierno de Tecnologías y Aplicaciones

Duplicidad de Funcionalidades

Fuente : Elaboración Propia

8
ARQUITECTURAS (AS IS / TO BE)
ARQUITECTURA DE LA LINEA BASE (AS-IS)
ARQUITECTURA DE NEGOCIO (AS-IS)

Matriz de Objetivo del Negocio vrs procesos (AS-IS)


Figura 15: Matriz de Objetivo del Negocio vrs procesos (AS-IS) / Fuente : Elaboración Propia

8
Procesos de negocio seleccionado y descripción (AS-IS)
El proceso de negocio seleccionado es “Gestión de Planeamiento”, el cual es un proceso
operativo encargado de atender los pedidos de los clientes Evaluar y planificar el
aprovisionamiento de mercadería requerida para las líneas de negocio.

El proceso actual inicia cuando el cliente solicita un pedido de mercancías mediante la


aplicación SAP Dealer Portal. La aplicación tiene la capacidad de validar el stock actual al
momento de generar el pedido. Si el sistema valida que hay stock disponible, éste
comprometerá las unidades correspondientes al pedido; Caso contrario, se dejara la orden en
estado pendiente “B/O” (Backorder) para ser atendida posteriormente por el Planificador.

EL Planificador mediante el modulo SAP MM (Material Management), módulo de SAP


encargado de la gestión de materiales, puede visualizar todas las ordenes pendientes B/O,
también validar el Stock disponible y en base a la decisión del Planificador priorizar y
comprometer el Stock disponible a los pedidos comerciales pendientes B/O. Por otro lado, en
caso no hay Stock disponible, este módulo permite generar un Pedido de compra
(Aprovisionamiento), previa aprobación del Jefe de Planeamiento, mediante el envío de un
mail de solicitud de pedido de compra al proveedor.

En la etapa de despacho es el personal de logística quien mediante el PDA actualizan en el


sistema los estados de las mercancías mediante las actividades de Picking, Packing y Load; así
como también, actualiza el stock local disponible por las salidas de las mercancías.

Por otro lado, en la etapa de recepción de mercancías de los pedidos de compras realizados
previamente por el Planificador, es el personal de logística quien recibe los pedidos,
apoyándose del dispositivo PDA (Personal Digital Assistant), mediante el cual se registran los
ingresos de los pedidos de compra al Stock de libre disponibilidad. Para lograr ello, éste

8
componente periférico se comunica con el SAP MM y con la BD local para actualizar las
existencias de los artículos en el almacén correspondiente.

Diagrama de Actividades (AS-IS)


Figura 16: Diagrama de Actividades AS-IS

Fuente : Elaboración Propia

8
Roles de Negocio : Matriz RACI (AS-IS)

Tabla 16 : Matriz RACI de Roles de Negocio

ROLES

Representante de Despacho
Representante de Almacén

Gerente de Operaciones
Jefe de Planificacion
SAP Dealer Portal

Jefe Logistica
Planificador
ACTIVIDADES

Valida Stock Material R

Dejar Pedido comercial pendiente (B/O) R

Listar Pedidos Pendientes B/O R

Verificar Stock Disponible local R

Priorizar pedidos R C I

Compromete Stock local disponible al pedido comercial R I

Solicitar pedido compra por B/O R A I

Aprobar Solicitud de Compra R I

Recepcionar mercadería C R A

Despacho (Picking/Packing/Load) C R A

R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO
I: INFORMADO

Fuente : Elaboración Propia

8
ARQUITECTURAS DE SISTEMAS DE INFORMACIÓN (AS-IS)

ARQUITECTURA DE DATOS DE LA LINEA BASE (AS-IS)

Modelo de datos (AS-IS)


A continuación se visualiza el modelo de datos actual, el cual integra las entidades relacionadas al proceso de negocio seleccionado.

Figura 17: Modelo de Datos (AS-IS)/ Fuente : Elaboración Propia

8
Matriz de datos del proceso seleccionado vrs procesos del Negocio (AS-IS)
A continuación se visualiza la matriz de datos actual del proceso seleccionado en relación a los procesos del negocio.

Figura 18: Matriz de datos del proceso seleccionado vs procesos del Negocio (AS-IS)/ Fuente : Elaboración Propia

8
ARQUITECTURA DE APLICACIÓN DE LA LINEA BASE (AS-IS)

Diagrama de Aplicaciones y descripción (AS-IS)


Figura 19: Diagrama de Aplicaciones y descripción (AS-IS)

Fuente : Elaboración Propia

A continuación se indica una breve descripción de los aplicativos utilizados dentro de los
procesos seleccionados.

Figura 20: Descripción de Diagrama de Aplicaciones (AS-IS)

Fuente : Elaboración Propia

8
Matriz de Aplicaciones del proceso seleccionado vrs procesos del Negocio. (AS-IS)
A continuación se visualiza la matriz de aplicaciones actuales relacionado al proceso seleccionado en relación a los procesos del negocio.

Figura 21: Matriz Aplicaciones vrs procesos del Negocio. (AS-IS)

Fuente : Elaboración Propia

9
ARQUITECTURAS TECNOLOGIA DE LA LINEA BASE (AS-IS)
A continuación se visualiza la tecnología actual del objeto de estudio.

Componentes de tecnología y sus relaciones con los sistemas de información (AS-IS).

Figura 22: Componente de Tecnología vs. Sistemas informáticos (AS-IS)

Fuente : Elaboración Propia

Figura 23: Descripción de los Componente de Tec. Vs. Sistemas informáticos (AS-IS)

Fuente : Elaboración Propia

9
Plataforma de tecnología y su descomposición (AS-IS).

Figura 24: Plataforma de tecnología y su descomposición (AS-IS)

Fuente : Elaboración Propia

Ambientes y ubicaciones – agrupamiento de las tecnologías requeridas para cada ambiente


informático (AS-IS).

Figura 25: Ambientes y ubicaciones (AS-IS)

Fuente : Elaboración Propia

9
Comunicaciones físicas [RED] (AS-IS)
A continuación se muestra la estructura tecnológica de Honda del Perú

Figura 26: Mapa de comunicaciones fisicas [RED] (AS-IS)

Fuente : Elaboración Propia

9
Especificaciones de hardware y red (AS-IS)
Figura 27: Especificaciones de hardware y red (AS-IS)

Fuente : Elaboración Propia

9
FUNDAMENTO Y JUSTIFICACION DEL ENFOQUE ARQUITECTONICO
En base a la arquitectura empresarial AS-IS y el proceso analizado, se definen los principales
problemas y requerimientos a resolver en la propuesta TO-BE.

Problemática

 Desconformidad de la línea de negocio de repuestos por la demora en el aprovisionamiento de


productos para atender las necesidades de los clientes.

 No se cuenta con alguna funcionalidad del ERP SAP para planificar eficazmente el
aprovisionamiento de productos para atender las necesidades del cliente.

 No es posible priorizar la atención de BackOrder (pedidos pendientes de atención por falta de


stock) con algún pedido que se encuentre en transito.

 No se tiene visibilidad del stock de los productos incluidos en los BackOrder de los otros
almacenes de la organización para poder realizar un traslado entre almacenes y se pueda cubrir
alguna necesidad al cliente en menor tiempo.

 Cuando se identifica stock en otros almacenes no se limita el stock máximo a utilizar y al


realizar el traslado total de la mercadería se desabastece los otros almacenes.

 En la recepción de mercadería asociado al pedido de compra generado para abastecer los


backorder, ingresan al almacén en estado de “Libre Disposición”. Ocasionando que cualquier
otro pedido comercial pueda comprometer ese nuevo stock.

Principales requerimientos
Contar con una herramienta que permita gestionar y planificar efectivamente los BackOrder.

 Contar con la facilidad de poder emparejar backorder al pedido de compra generado


obteniendo una fecha ETA de la atención.

 Poder emparejar backorder a pedidos de compra en transito a nivel de posiciones para


priorizar el abastecimiento de mercadería y atender los backorder de los clientes.

9
 Permitir emparejar las necesidades requeridas a las solicitudes de pedido para reducir el
tiempo de abastecimiento de mercadería.

 Contar con un panel general en el que se identifiquen los stock de los productos incluidos en
los backorder y realice el traslado entre almacenes de la necesidad requerida y comprometa de
forma automática los pedidos comerciales para que se inicie el despacho de la necesidad del
cliente.

 Al realizar el traslado entre almacenes debe de respetar el stock máximo de la mercadería


asignada al almacén origen para que no se quede desabastecido.

 En la recepción de mercadería se debe de identificar que el pedido de compras a recepcionar


es para cubrir la necesidades por backorder para que de forma automática se separe el stock
comprometido al almacen correspondiente de los pedidos comerciales.

 En la recepción de mercadería se debe de identificar si hay pedidos pendientes sin planificar


asociados a los productos recibidos para que de forma automática ingrese el stock en estado de
calidad y comprometa los pedidos comerciales para que se inicie el despacho de la necesidad
del cliente.

9
ARQUITECTURA DE NEGOCIO DE DESTINO (TO-BE)

ARQUITECTURA DE NEGOCIO (TO-BE)

Matriz de Objetivo del Negocio vrs procesos (TO-BE)


La propuesta de mejora va alineado a fortalecer los objetivos estratégicos sombreados (en amarillo) en relación al proceso de Gestión de
Planeamiento (GPL), tal como se visualiza en la siguiente ilustración.

Figura 28: Matriz de Objetivo del Negocio vrs procesos (TO-BE)

Fuente : Elaboración Propia


9
Procesos de negocio seleccionado y descripción (TO-BE)
El proceso de negocio seleccionado es “Gestión de Planeamiento”, el cual es un proceso
operativo encargado de atender los pedidos de los clientes Evaluar y planificar el
aprovisionamiento de mercadería requerida para las líneas de negocio. Por otro lado, el
proceso de negocio “Administrador Logística” en la funcionalidad de recepción de
mercadería, es la encargada de ejecutar las planificaciones previamente asignadas.

El proceso de negocio seleccionado y modificado por la solución planteada inicia cuando el


cliente solicita un pedido de mercancías mediante la aplicación SAP Dealer Portal. La
aplicación tiene la capacidad de validar el stock actual al momento de generar el pedido. Si el
sistema valida que hay stock disponible, éste comprometerá las unidades correspondientes al
pedido; Caso contrario, se dejara la orden en estado pendiente “B/O” (Backorder) para ser
atendida posteriormente por el Planificador.

El Planificador mediante el modulo SAP MM (Material Management), módulo de SAP


encargado de la gestión de materiales, puede visualizar todas las ordenes pendientes B/O.
Además, ahora con la mejora planteada, tendrá la capacidad de “emparejar” un pedido B/O
con una o más fuentes de abastecimiento disponibles con el objetivo de garantizar la
recuperación de la cantidad en B/O con eficiencia y en el menor tiempo posible. Asimismo,
este emparejamiento permitirá que el cliente pueda estar informado del estado y el tiempo
estimado de recuperación de su pedido B/O con mayor exactitud.

9
Figura 29: Niveles de recuperación de B/O

Fuente : Elaboración Propia

En caso no hay Stock disponible y no se haya logrado recuperar los B/O con las fuentes de
abastecimiento (1, 2, 3, 4, 5), este módulo permite generar un Pedido de compra
(Aprovisionamiento), previa aprobación del Jefe de Planeamiento, mediante el envío de un
mail de solicitud de pedido de compra al proveedor.

En la etapa de despacho es el personal de logística quien mediante el PDA actualizan en el


sistema los estados de las mercancías mediante las actividades de Picking, Packing y Load;
así como también, actualiza el stock local disponible por las salidas de las mercancías.

Por otro lado, en la etapa de recepción de mercancías de los pedidos de compras realizados
previamente por el Planificador, es el personal de logística quien recibe los pedidos
apoyándose del dispositivo PDA (Personal Digital Assistant), mediante el cual se realizan los
ingresos de los pedidos de compra a los almacenes correspondientes. Es a través de esta
herramienta, se planea “separar” la cantidad máxima posible de stock durante la recepción de
mercadería para ser destinados exclusivamente a la recuperación de B/Os HUB. Además, en
la recepción de mercadería se debe de identificar si hay pedidos pendientes sin planificar
asociados a los productos recibidos para que de forma automática éstos se ingresen al stock
en estado de calidad y se reserven para la atención de los pedidos comerciales.

9
Para lograr ello, éste componente periférico se comunica con el SAP MM y con la BD local
para actualizar las existencias de los artículos en los almacenes correspondientes.

1
Diagrama de Actividades (TO-BE)
Figura 30: Diagrama de Actividades TO-BE

Fuente : Elaboración Propia

1
Sub Procesos : Gestionar “RECUPERACION BACKORDER” (TO-BE)

Figura 31: Diagrama de Actividades–Sub Proceso: “Recuperación B/O” (TO-BE)

Fuente : Elaboración Propia

1
Sub Proceso : “RECEPCIONAR MERCADERIA”

Figura 32: Diagrama de Actividades – Sub Proceso : “Recepción Mercadería” (TO-BE)

Fuente : Elaboración Propia

Roles de Negocio: Matriz RACI (TO-BE).


Tabla 17: Roles de Negocio : Matrix RACI (TO-BE)

ROLES
Representante de Despacho
Representante de Almacen

Gerente de Operaciones
Jefe de Planificacion
SAP Dealer Portal

Jefe Logistica
Planificador

ACTIVIDADES

Valida Stock Material R

Dejar Pedido comercial pendiente (B/O) R

Listar pedidos B/O para planificación R

Compromete Stock local disponible al pedido comercial R I

Gestionar Planificación Backorders R I

Solicitar pedido compra por B/O R A I

1
ROLES

Representante de Despacho
Representante de Almacen

Gerente de Operaciones
Jefe de Planificacion
SAP Dealer Portal

Jefe Logistica
Planificador
ACTIVIDADES

Aprobar Solicitud de Compra R I

Recepcionar mercadería C R A

Despacho (Picking/Packing/Load) C R A

R: RESPONSABLE DE EJECUCION

A: AUTORIDAD

C: CONSULTADO

I: INFORMADO

Fuente : Elaboración Propia

1
ARQUITECTURAS DE SISTEMAS DE INFORMACIÓN (TO-BE)

ARQUITECTURA DE DATOS DEL NEGOCIO DESTINO (TO-BE)

Modelo de datos (TO-BE)


Luego de identificar las entidades en la arquitectura AS-IS se propone adicionar nuevas entidades que estarán
alineadas con la propuesta de mejora indicada en la arquitectura de negocio destino TO-BE

Figura 33: Modelo de Datos (TO-BE)/ Fuente : Elaboración Propia

1
Matriz de datos del proceso seleccionado vrs procesos del Negocio (TO-BE)
A continuación se muestra la relación entre los datos del proceso seleccionado versus los procesos de negocio.

Figura 34: Matriz de datos del proceso seleccionado vrs procesos del Negocio (TO-BE)

Fuente : Elaboración Propia

1
ARQUITECTURA DE APLICACIÓN DEL NEGOCIO DESTINO (TO-BE)

DIAGRAMA DE APLICACIONES Y DESCRIPCION (TO-BE)


Figura 35: Diagrama de Aplicaciones y descripción (TO-BE)

Fuente : Elaboración Propia

A continuación se indica una breve descripción de los aplicativos utilizados dentro de los
procesos seleccionados. Adicionalmente, se identifican (sombreado amarillo) las aplicaciones
relacionadas a la propuesta de mejora de los procesos seleccionados.

Figura 36: Descripción de Diagrama de Aplicaciones (TO-BE)

Fuente : Elaboración Propia

1
Matriz Aplicaciones del proceso seleccionado vrs procesos del negocio (TO-BE)
La propuesta de mejora propone adicionar nuevas funcionalidades al módulo SAP MM y SAP SD, tal como se muestra en la siguiente
ilustración (sombreado en amarillo).

Figura 37: Matriz de Aplicaciones vs. Procesos del Negocio. (TO-BE)

Fuente : Elaboración Propia

1
ARQUITECTURAS TECNOLOGIA (TO-BE)

Componentes de tecnología y sus relaciones con los sistemas de información (TO-BE).


Esta arquitectura no sufre ningún cambio en la propuesta de mejora indicada en la arquitectura
de negocio destino (TO-BE).

Figura 38: Componente de Tec. Vs. Sistemas informáticos (TO-BE)

Fuente : Elaboración Propia

Figura 39: Descripción de los Componentes de Tec. Vs. Sistemas informáticos (TO-BE)

Fuente : Elaboración Propia

1
Plataforma de tecnología y su descomposición (TO-BE)

Figura 40: Plataforma de tecnología y su descomposición (TO-BE)

Fuente : Elaboración Propia

Ambientes y ubicaciones – agrupamiento de las tecnologías requeridas para cada ambiente


informático (TO-BE)

Figura 41: Plataforma de tecnología y su descomposición (TO-BE)

Fuente : Elaboración Propia

1
Comunicaciones físicas [RED] (TO-BE)
Esta estructura tecnológica no sufre ningún cambio en la propuesta de mejora indicada en la arquitectura de negocio destino (TO-BE).

Figura 42: Mapa de comunicaciones fisicas [RED] (TO-BE)

Fuente : Elaboración Propia

1
Especificaciones de hardware y red (TO-BE)
Figura 43: Especificaciones de hardware y red (TO-BE)

Fuente : Elaboración Propia

1
ANALISIS DE BRECHA
En base a la arquitectura empresarial AS-IS y el proceso analizado, se definen los principales
problemas y requerimientos a resolver en la propuesta TO-BE.

ARQUITECTURA DE NEGOCIO
A continuación se visualiza las brechas entre la arquitectura de negocio base y arquitectura de
negocio destino.

Figura 44 : Analisis de Brecha – Arquitectura de Negocio

Fuente : Elaboración Propia

Los GAP’s encontrados en la arquitectura de negocio son los siguientes :

1
 GAP 1 : Actualizar “Listar pedidos B/O para planificación”.

Descripción de la brecha:

En la actualidad se pierda la aportunidad de abastecer pedidos B/O a tiempo, debido a que la


información de pedidos pendientes de atención no se encuentra centralizada, siendo necesario
realizar procedimientos manuales en excel.

Propuesta: Se propone contar con una consola de consulta en el que se mostrará todos los
pedidos BackOrder, indicando el estado actual de la necesidad. Además, será posible identificar
los BackOrder pendientes de abastecer para su respectiva planificación.

GAP 2 : Actualizar “Verificar stock disponible local”.

Descripción de la brecha:

En la actualidad la verificación del stock disponible en el almacén local no es real, ya que no es


posible asignar el total del stock obtenido, debido a que es necesario consultar, cual es el stock
maximo permitido a utilizar, ocasionando, demora en el abastecimiento de los pedidos B/O.

Propuesta: Se propone solo mostrar el stock disponible local a utilizar, esto quiere decir, que de
forma automatica, se omitira el stock minimo a no utilizar en el almacén local.

 GAP 3 : Actualizar “Compromete Stock local disponible al pedido comercial”

Descripción de la brecha:

Para identificar que pedidos pendientes de atención seran abastecidos es necesario consultar
archivos excel, ocasionando asignaciones incorrectas por no contar con la información
actualizada, ya que en ocasiones se cancela la necesidad.

Propuesta: Esta propuesta se encuentra alineado al GAP 1 y GAP 2, debido a que el listado de
pedidos pendientes de atención se obtiene en linea y sera abastecido por stock real disponible en
el almacén local.

1
 GAP 4 : Implementar “Gestionar Planificación BackOrders”.

Descripción de la brecha:

En la actualidad solo se abastecen los pedidos pendientes de atención elaborando un pedido de


compra por la necesidad requerida que no se a podido atender por falta de stock, ocasionando la
demora en el abastecimiento ya que la atención aprox del proveedor es de 45 dias.

Propuesta: Se propone implementar herramientas para que el planificador tenga la capacidad de


“emparejar ó referenciar” y “priorizar” un pedido BackOrder con una o más fuentes de
abastecimiento disponibles con el objetivo de garantizar la recuperación de la cantidad en B/O
con eficiencia y en el menor tiempo posible. Asimismo, este emparejamiento permitirá que el
cliente pueda estar informado del estado y el tiempo estimado de recuperación de su pedido B/O
con mayor exactitud. Además, podrá verificar stock disponible local de forma automatica de los
materiales incluidos dentro del BackOrder.

 GAP 5 : Actualizar “Recepcionar mercadería”

Descripción de la brecha:

En la actualidad al realizar la recepción de pedidos de compra que fueron generados para


abastecer pedidos comerciales pendientes de atención ingresan al stock de libre disponibilidad,
ocacionando, que otros pedidos comerciales comprometan el stock y realicen el despacho del
mismo, perjudicando al cliente que se encuentra a la espera de la llegada de la mercadería.

Propuesta: Se propone mejorar la funcionalidad de recepción de mercadería, para que permitirá


comprometer automaticamente los pedidos BackOrder asignados a las fuentes de
abastecimientos referenciados a pedidos de compras. Estas referencias se realiza en el GAP 4.

 GAP 6 : Eliminar “Priorizar pedidos”

Descripción de la brecha:

1
En la actualidad la priorización de pedidos es ineficente ya que se realiza la gestión de
abastecimiento consultando información desactualizada.

Propuesta: Se propone eliminar la actividad, debidó a que será incluida de forma automatica
dentro del GAP 2 mediante propuestas de fuentes de abastecimiento.

1
ARQUITECTURA DE DATOS
A continuación se visualiza las brechas entre la arquitectura de datos base y arquitectura de datos destino

Figura 45 : Analisis de Brecha – Arquitectura de Datos

Fuente : Elaboración Propia

1
Los GAP’s encontrados en la arquitectura de datos son los siguientes

 GAP 1:Implementar ZTSD_PLANEK_HUB (Planificación con Doc. Compras).

Descripción de la brecha:

En la actualidad no se cuenta con estructura de datos de planificación relacionado a Doc


compras, ocasionando, demora y deficiencia en el abastecimiento de pedidos comerciales
pendientes de atención.

Propuesta: Se creará entidad de datos para la planificación referenciados a documentos de


compras que abasteceran los BackOrder.

 GAP 2 : Implementar ZTSD_PLANEB_HUB (Planificación con Solped)

Descripción de la brecha:

En la actualidad no se cuenta con estructura de datos de planificación relacionado a solicitudes


de pedido, ocasionando, demora y deficiencia en el abastecimiento de pedidos comerciales
pendientes de atención.

Propuesta: Se creará entidad de datos para la planificación referenciada a solicitudes de compra


que abasteceran los BackOrder.

 GAP 3 : Implementar ZTSD_MOVINT_HUB (Traslados

Internos) Descripción de la brecha:

En la actualidad no se cuenta con estructura de datos para relacionar los movimientos internos de
abastecimiento desde el almacén local, ocasionando, demora y deficiencia en el abastecimiento
de pedidos comerciales pendientes de atención.

Propuesta: Se creará entidad de datos para relacionar los movimientos internos por
abastecimiento de BackOrder desde almacén local.

1
 GAP 4 : Actualizar VBAP (Pos DocVta)

Descripción de la brecha:

En la actualidad no se guarda relación entre el pedido comercial pendiente de atención y el


pedido de compra, ocasionando, que no sea posible la ejecuación de abastecimiento automatico
desde la recepción de la mercadería.

Propuesta: Se actualizará entidad de datos para contar con la referencia del documento de
compra del abastecimiento de las necesidades de BackOrder.

 GAP 5 : Actualizar VBBE (Necesidades Vtas)

Descripción de la brecha:

En la actualidad no se guarda relación entre la necesidad de venta comercial pendiente de


atención y el pedido de compra, ocasionando, que no sea posible la ejecuación de abastecimiento
automatico desde la recepción de la mercadería.

Propuesta: Se actualizará entidad de datos para contar con la referencia del documento de
compra del abastecimiento de las necesidades de BackOrder.

 GAP 6 : EBAN (SolPed)

Descripción de la brecha:

En la actualidad no se guarda relación entre las solicitud de pedido comercial y el pedido de


compra, ocasionando, que no sea posible la ejecuación de abastecimiento automatico desde la
recepción de la mercadería.

Propuesta: Se actualizará entidad de datos para contar con la referencia del documento de
compra del abastecimiento de las necesidades de BackOrder.

1
 GAP 7 : EKBE (Historial

DocCompra) Descripción de la brecha:

En la actualidad no es posible realizar la trazabilidad de la atención de los pedidos comerciales


en relación a los pedidos de compra generados, ocasionando, información desactualidad.

Propuesta:Se actualizará entidad de datos para contar con la referencia del BackOrder
abastecidos.

 GAP 8 : MKPF

(DocMaterial) Descripción de la

brecha:

En la actualidad no es posible realizar la trazabilidad de la atención de los pedidos comerciales


en relación a los documentos de meterilaes generados, ocasionando, información desactualidad.

Propuesta: Se actualizará entidad de datos para contar con la referencia del BackOrder
abastecidos.

 GAP 9 : MSEG (Segmento DocMat)

Descripción de la brecha:

En la actualidad no es posible realizar la trazabilidad de la atención de los pedidos comerciales


en relación a los documentos de meterilaes generados a nivel de posiciones, ocasionando,
información desactualidad.

Propuesta: Se actualizará entidad de datos para contar con la referencia del BackOrder
abastecidos.

1
ARQUITECTURA DE APLICACIONES
A continuación se visualiza las brechas entre la arquitectura de aplicaciones base y arquitectura
de aplicaciones destino.

Figura 46 : Analisis de Brecha – Arquitectura de Aplicaciones

Fuente : Elaboración Propia

Los GAP’s encontrados en la arquitectura de datos son los siguientes

 GAP 1: Actualizar “MM – Gestión de Materiales”

Descripción de la brecha:

En la actualidad no se cuenta con herramientas de apoyo en la gestión de planificación de


BackOrder en el que obtenga la información centralizada y brinde facilidades de fuentes de

1
abastecimiento, ocasionando, demoras en el proceso de atención de pedidos comerciales
pendientes de atención.

Propuesta: Se actualizará el modulo SAP MM – Gestión de Materiales, adicionando nuevas


funcionalidades en relación a la gestión de planificación de BackOrder.

 GAP 2 : Actualizar “SMP – Plataforma Movil”

Descripción de la brecha:

En la actualidad no es posible identificar la recepción de mercaderia generadas para abastecer la


necesidad de cliente referenciado, ocasionando, demora en el abastecimiento previamente
programado de forma manual.

Propuesta:Se actualizará el modulo SMP – Plataroma Movil, adicionando nuevas


funcionalidades en la recepción de mercadería alineado a la planificación de abastecimiento de
BackOrder.

ARQUITECTURA DE TECNOLOGIA
Esta arquitectura no sufre ningún cambio en la propuesta indicada en la arquitectura de negocio
destino (TO-BE). Esto quiere decir, que la arquitectura tecnológica (AS-IS) está alineado con lo
esperado.

1
EVALUACION DEL IMPACTO
Figura 47 : Evaluación de Impacto (Probabilidad e Impacto)

1
Fuente : Eleboración Propia

En el cuadro anterior se muestra una tabla con los riesgos identificados, así como su ponderación

en función a la probabilidad e impacto, la acción a seguir sobre los riesgos y la respuesta a los
riesgos identificados.

Figura 48 : Matriz de Probabilidad e Impacto

Fuente : Elaboración Propia

1
OPORTUNIDADES Y SOLUCIONES
Desglose de la implementación de proyectos y cartera

Figura 49 : Estructura de Desgloce de trabajo

Fuente : Eleboración Propia

1
CUADRO RESUMEN DEL PLAN DE MIGRACION

Figura 50 : Cuadro Resumen del Plan de Migración

1
Fuente : Eleboración Propia

1
CONCLUSIONES
Como resultado del análisis de Arquitectura empresarial aplicada a la propuesta de mejora del
proceso de Gestión de Planeamiento (GPL), es posible concluir que existe una relación entre la
habilidad de realizar una adecuada planificación para el abastecimiento de los pedidos
pendientes y los retrasos en cubrir la recuperación de los mismos, debido a algunos factores
principales; en la actualidad no es posible seleccionar distintas fuentes de abastecimiento para
recuperar los pedidos pendientes, además no es posible enlazar un nuevo pedido de compra a
pedidos pendientes específicos.

Por otro lado, durante la recepción de los productos que provienen de una solicitud de compra,
no se cuenta con las habilidades de identificar la existencia de pedidos pendientes asociados a
esos productos para que puedan ser reservados y entregados con mayor eficiencia (ver pág. 55
cap. 2).

Es debido a esto que se puede concluir que uno de los principales factores para disminuir el
tiempo de demora en la recuperación de pedidos pendientes, es que el planificador cuente con las
herramientas y funcionalidades necesarias para lograr realizar una adecuada planificación de la
recuperación de los pedidos pendientes; siendo esto en lo que se enfoca la potencial propuesta de
solución de este capítulo.

1
CAPÍTULO 3. MÉTODOS ÁGILES PARA
EL DESARROLLO DE SOFTWARE

INTRODUCCIÓN
Ágil es un término general que incluye un enfoque iterativo para el desarrollo de software que
encapsula los valores del manifiesto para el desarrollo de software ágil. Las metodologías de
desarrollo Ágil fueron diseñadas para flexibilizar y soportar las necesidades de los proyectos y la
organización, mediante un conjunto de herramientas y mejores prácticas que ayudan el desarrollo
de la organización enfocándose en la eficiencia, colaboración, calidad y la creación de valor del
cliente [16].

Un error que se ha cometido durante muchos años ha sido pensar que las metodologías ágiles, sin
adaptación al caso concreto y real sobre el que operan, eran la mejor opción para todo tipo de
proyectos. Pero la realidad dice que la cosa es más complicada, y que cada proyecto, empresa,
producto, línea de negocio, etc., requiere de una metodología específica; incluso, los padres del
manifiesto ágil, como Martin Fowler u otros especialistas en metodologías, como Phillippe
Kruchten dicen que hay una metodología concreta para cada proyecto [15].

En el presente capítulo se detallan los objetivos estratégicos a los que apunta la propuesta Ágil;
así como también, un análisis de las fortalezas y debilidades del objeto de estudio, lo cual nos
lleva a identificar algunas iniciativas de mejora en la organización que serán atacadas por un
conjunto de dinámicas propuestas.

Finalmente, se realizará el análisis correspondiente para sustentar por qué ésta propuesta apuesta
por la utilización de la metodología SCRUM para el desarrollo de la solución propuesta para la

1
mejora del proceso de Gestion de Planificación y se detallará las herramientas a utilizar por el
marco de trabajo elegido.

OBJETIVOS
La cultura organizacional es la infraestructura, el pegamento que enlaza personas y procesos para
generar resultados. La cultura debe convertirse en la mayor fuerza que empuja la organización
hacia adelante [07].

Los objetivos de la propuesta ágil son [08]:

 Incrementar la productividad: La producción de software que trabaja alrededor de las


necesidades de negocio implica ingresar conocimiento multidisciplinario en etapas
simultáneas. La metodología ágil sirve para enfocar la atención de los partidos por disciplina
en el espacio que se les necesita e inmediatamente liberar el talento para que puedan moverse
entre zonas de trabajo.

 Mejora la motivación del equipo de desarrollo: Esta mejora no es casual, las metodologías
ágiles permiten a todos los miembros del equipo conocer el estado del proyecto en todo
momento. Por consiguiente, los compromisos son negociados y aceptados por todos los
miembros del equipo y las ideas de cada integrante son tomadas en cuenta, lo cual hace que
cada integrante se sienta más comprometido con el proyecto.

 Mejora en la calidad del producto: Las metodologías ágiles permiten mejorar la calidad del
producto. La constante interacción entre los desarrolladores y los clientes tienen como
objetivo asegurar que el producto final sea exactamente lo que el cliente quiere y necesita.
Además, este enfoque permite abrazar la excelencia tecnológica, lo que permite obtener un
producto tecnológicamente superior.

 Mejor gestión de riesgo: No siempre se logra cumplir con las metas de lanzamiento cuando
se trabaja con software, mientras más lejanas sean las entregas contra cliente o equipo más se
maximiza el riesgo de potencial desviación de la entrega contra la definición del proyecto
inicial. Las metodologías ágiles permiten el manejo de ciclos continuos con entregables y
productos semi-cerrados. Por lo tanto, cuando fallan las entregas, la metodología ágil permite

1
ajustar el ciclo de trabajo para enfocar el talento en zonas de mayor o menor riesgo a
justificación de defender un proyecto en su totalidad.

IDENTIFICACIÓN DE FORTALEZAS Y DEBILIDADES


El análisis FODA pretende identificar los puntos fuertes y las debilidades de una organización y
las oportunidades y amenazas en el medio ambiente [14].

A continuación se indican las fortalezas y debilidades del objeto de estudio y se proponen la


manera de aprovechar las fortalezas y eliminar las debilidades.

FORTALEZAS
 F01.- Filosofía e historia de la compañía, que se transmite a las personas que integran la
misma y que les permite tener un óptimo ambiente laboral.

 F02.- Personal altamente calificado en los roles asignados y solidos conocimiento del
negocio, los cuales están conformados por la Alta Gerencia, Asesores, Línea de negocio y
equipo de apoyo.

 F03.- Solidez en recursos financieros.

 F04.- Alta variedad de productos.

 F05.- Innovación tecnológica.

DEBILIDADES
 D01.- No fomentar la calidad del producto y el servicio de post ventas asociado al mismo.

 D02.- El área de sistemas no cuenta con una metodología de trabajo definida para el
desarrollo de los proyectos de Software.

 D03.- Constante rotación del personal, lo cual genera pérdidas de conocimiento.

1
 D04.- Ineficiencia en la planificación de abastecimiento de mercadería para cubrir
necesidades del sector local y externo (Repuestos).

 D05.- Poca comunicación entre los integrantes del equipo.

 D06.-Resistencia al cambio.

 D07.-Baja capacidad de investigación

 D08.-Exceso de especialización en los integrantes del equipo.

Una vez identificado estos puntos, se planteará como aprovechar las fortalezas y eliminar las
debilidades.

Tabla 18 : Tabla de Fortalezas


Fortalezas Aprovechamiento

F01.- Filosofía e historia de la compañía, que Como base del Principio de la Compañía están
se transmite a las personas que integran la dos principios fundamentales: Respeto por las
misma y que les permite tener un óptimo personas y Las tres alegrías (comprar, vender,
ambiente laboral. crear).

Honda está formada por personas, con


diferentes roles, que trabajan juntos por un
objetivo común. Al desempeñar su propio rol,
se espera que cada uno manifieste libremente
sus características. El Respeto por el Individuo
se basa en los conceptos fundamentales de
iniciativa, igualdad y confianza. Por ello, los
empleados se encuentra satisfechos de trabajar
en un buen clima laboral y están
comprometidos con el trabajo en equipo por un
objetivo en común.

F02.- Personal altamente calificado en los roles El personal posee alto conocimiento del
asignados y solidos conocimiento del negocio, negocio y aceptan de buena manera adecuarse

1
Fortalezas Aprovechamiento

los cuales están conformados por la Alta a cambios sugeridos, beneficioso para el
Gerencia, Asesores, Línea de negocio y equipo objetivo estratégico de la organización, ya que
de apoyo. es el objetivo en común.

F03.- Solidez en recursos financieros. La organización cuenta con una solidez


económica en base al cumplimiento de los
objetivos de ventas al igual que respaldo
crediticio de entidades financieras. Esta solidez
transmite seguridad y respaldo al personal que
integra esta organización. Además, les permite
realizar inversiones de mejora, alineado al
objetivo estratégico de la organización.

F04.- Alta variedad de productos. La organización cuenta con una alta gama de
variedades de productos orientado a satisfacer
las necesidades del cliente. De igual manera se
mantiene en stock productos de repuestos que
garantiza el soporte oportuno de los productos
distribuidos. Por tal motivo, en atender las
necesidades del cliente de manera oportuna
fortalece la presencia de la marca en el
mercado automotriz.

F05.- Innovación tecnológica. En marzo 2013 se realizó la implementación de


ERP SAP dando respuesta a la necesidad de la
organización en contar con un sistema que
permite la integración de las operaciones de la
organización. Por ello, en la actualidad se
puede implementar mejoras de forma
integrada, beneficiando a todas las áreas

1
Fortalezas Aprovechamiento

implicadas.

Fuente : Elaboración Propia

Tabla 19 : Tabla de Debilidades


Debilidades Mejoras

D01.- No fomentar la calidad del producto y el El equipo de marketing con el apoyo del área
servicio de post ventas asociado al mismo. comercial y postventa, mediante la fortaleza
del conocimiento del negocio, deberán elaborar
estrategias para fomentar la calidad y el
servicio de post venta asociado a los productos.

D02.- El área de sistemas no cuenta con una En vista del incremento de competidores en el
metodología de trabajo definida para el mercado y con la finalidad de contar de forma
desarrollo de los proyectos de Software rápida con soluciones de calidad en el
ambiente productivo, se propone el uso de
metodología ágil SCRUM para gestionar el
proceso de desarrollo de los distintos
requerimientos y/o proyectos de TI.

D03.- Constante rotación del personal, lo cual Para mejorar esta debilidad, se propone realizar
genera pérdidas de conocimiento. dinámicas para identificar los principales
motivos por los cuales el personal se va;
además, actividades de integración para
identificar las necesidades y motivaciones
requerida por el personal que lo lleva a buscar
un cambio en alguna otra empresa. Por otro
lado, se tiene planteado guardar un registro
centralizado de lecciones aprendidas, las cuales

1
Debilidades Mejoras

permiten documentar estas situaciones,


analizar sus causas raíz, el impacto que
tuvieron en el proyecto y determinar acciones
efectivas para mitigar sus efectos en el caso de
las amenazas, y mejorarlos en el caso de las
oportunidades. Se observa que es un elemento
con frecuencia omitido, perdido en el día a día
de los equipos de trabajo y los Directores de
Proyecto.

D04.- Ineficiencia en la planificación de Realizar reuniones periódicas entre las áreas de


abastecimiento de mercadería para cubrir planeamiento, comercial y logística para
necesidades del sector local y externo analizar los indicadores de atención de
(Repuestos). Backorder, buscando mejoras continuas para
minimizar el tiempo de atención y maximizar
la satisfacción al cliente.

D05.- Poca comunicación entre los integrantes Realizar actividades para mejorar esta
del equipo. debilidad

D06.-Resistencia al cambio. Realizar dinámicas que mitiguen esta


resistencia.

D07.-Baja capacidad de investigación Promocionar beneficios por ideas creativas.

D08.-Exceso de especialización en los Generar capacitaciones internas para transferir


integrantes del equipo. los conocimientos al resto del equipo.

Fuente : Elaboración Propia

1
DIAGNÓSTICO DEL GRUPO
De acuerdo a las fortalezas y mejoras en las debilidades del objeto de estudio, se puede concluir
que el personal es altamente calificado con sólidos conocimientos del negocio. Teniendo como
fortaleza principal la filosofía del respeto a las personas y el trabajo en conjunto a beneficio del
bien común alineado a los objetivos estratégicos de la organización. Por otro lado, el personal del
área de sistemas tiene conocimientos de metodologías agiles que facilita la aceptación de la
misma.

Tabla 20 : Diagnostico de Grupo


Debilidad D01.- No fomentar la calidad del producto y el servicio de post ventas asociado al
mismo.

Problemas:

 Perdida de posibles clientes, ya que se la competencia podría tener este factor como una
fortaleza.

 Impacto en el posicionamiento de la Marca.

Debilidad D02.- El área de sistemas no cuenta con una metodología de trabajo definida para
el desarrollo de los proyectos de Software.

Problemas:

 Muchas veces no se generan documentación adecuada de las soluciones implementadas. Por


consiguiente, esto genera un gran problema al momento de la ejecución de nuevos
requerimientos o proyectos; demoras en las atenciones de incidentes en producción, se
invierte demasiado esfuerzo en el análisis de alcance e impactos para nuevas soluciones.

1
Debilidad D03.- Constante rotación del personal, lo cual genera pérdidas de conocimiento.

Problemas:

 Pérdida de personas clave en la organización.

 Pérdida de conocimiento.

 Tiempo en encontrar a nuevo personal que cumpla con las necesidades del rol requerido.

Debilidad D04.- Ineficiencia en la planificación de abastecimiento de mercadería para cubrir


necesidades del sector local y externo (Repuestos).

Problemas:

 Insatisfacción del cliente por demora en atención de sus necesidades.

 Perder la oportunidad de fortalecer y extender el servicio HUB de Repuestos.

 Poca rotación de productos.

 Contar con sobre stock por abastecimiento de productos con poca rotación generando gastos
por almacenaje.

Fuente : Elaboración Propia

IDENTIFICACIÓN DE LAS DINÁMICAS PROPUESTAS


Las dinámicas más convenientes para potenciar las fortalezas y eliminar las debilidades del
objeto de estudio son:

Tabla 21 : Tabla de Dinámicas Propuestas para reforzar Fortalezas


Fortalezas Dinámica Funcionamiento

F01.- Filosofía e El equipo En cartones o tarjetas de un color, cada participante debe


historia de la ideal [24] enumerar cinco fortalezas individuales. En tarjetas de otro
compañía, que se color, describir cinco características de las personas con

1
Fortalezas Dinámica Funcionamiento

transmite a las quienes trabaja bien en equipo. Se juntan luego las tarjetas de
personas que todos y se analiza al "equipo real" frente al "equipo ideal".
integran la Puede dibujarse o escribirse cómo es cada uno, y discutir
misma y que les acerca de las diferencias. El ejercicio permite reflexionar sobre
permite tener un fortalezas y debilidades de los individuos y la necesidad de
óptimo ambiente unirse en equipo para potenciar recursos.
laboral.

F02.- Personal Promoción Honda brinda la oportunidad de Financiar cursos de


altamente del Talento certificación para los talentos clave que desea mantener.
calificado en los
roles asignados y
solidos
conocimiento del
negocio, los
cuales están
conformados por
la Alta Gerencia,
Asesores, Línea
de negocio y
equipo de apoyo.

F05.- Innovación Capacitacio El objetivo de las capacitaciones es contribuir en la


tecnológica. nes especialización de los empleados en los diversos módulos del
internas y ERP SAP, ello con la finalidad de explotar más los beneficios
Externas de la herramienta.

Fuente : Elaboración Propia

1
Tabla 22 : Tabla de Dinámicas Propuestas para mejorar Debilidades
Debilidades Dinámica Funcionamiento

D01.- No fomentar Capacitaciones Se realizará un plan de capacitaciones a todo el equipo


la calidad del comercial para que promuevan adecuadamente los
producto y el beneficios de los productos y repuestos de Honda; así
servicio de post como también, los servicios post venta.
ventas asociado al
mismo.

D02.- El área de El expendedor Es un juego de 75 minutos para equipos a los que se


sistemas no cuenta [18] explica por primera vez Scrum. Permite que hagan una
con una simulación de creación de la lista de objetivos priorizada
metodología de (Product backlog) y de ejecución del propio proceso de
trabajo definida Scrum, de manera que puedan compararlo con el
para el desarrollo desarrollo tradicional (en cascada/waterfall),
de los proyectos de comprobando cuáles son los principales beneficios de
Software. Scrum, especialmente los referidos a alineamiento con
las expectativas del cliente, flexibilidad y retorno
anticipado de inversión.

D03.- Constante Cuartetos Los participantes se agrupan de 4 en 4. Dialogan durante


rotación del 10 minutos sobre los problemas o temas interesantes que
personal, lo cual querían tratar en primer lugar.
genera pérdidas de Un miembro de cada grupo pasa al grupo más próximo
conocimiento. de la derecha y otro al de la izquierda. Vuelven a
dialogar para poner al tanto a los recién llegados sobre el
tema y continúan profundizándolo. (15 minutos).
Se repite la operación con un nuevo intercambio (10
minutos).
Al final se pasa a cada grupo una hoja para que anoten
reflexiones y conclusiones (15 minutos).
Se realiza un plenario informativo y se reflexiona sobre

1
Debilidades Dinámica Funcionamiento

la dinámica de trabajo.

D03.- Constante Temores y A todas las personas se les pide escribir personalmente y
rotación del Esperanzas [25] sin mayor orden sus temores y esperanzas con relación
personal, lo cual a... (15 minutos).
genera pérdidas de El coordinador pide que cada cual elija dos.
conocimiento Cada persona va leyendo uno sin explicarlo, y el
coordinador lo va anotando en un papelógrafo. Hay que
motivar a la gente para que hagan el esfuerzo de
escucharse. Se hace una segunda vuelta. En la tercera se
insiste que sólo digan cosas que no se han mencionado.
Se da la consigna de que los participantes elijan las dos
que más les han impresionado; se hace por votación y se
seleccionan unos 4 o 5 temas. Conviene elegir dos
temores y dos esperanzas.
Por grupos de interés van a hacer una cartelera
sintetizando todo lo que le grupo dijo sobre el tema (30
minutos).
En Plenario se analizan los temores y esperanzas en
feed-back.

D04.- Ineficiencia Brainstorming Realizar una lluvia de ideas para identificar la


en la planificación [26] problemática y los principales puntos de mejora que
de abastecimiento pueden ser atacados.
de mercadería para
cubrir necesidades
del sector local y
externo
(Repuestos).

D05.- Poca El comunicador Dinámica mediante la cual un integrante seleccionado


comunicación por el equipo realiza un dibujo y ésta tienen que ser
entre los replicada por el resto del equipo. Para ello existe una

1
Debilidades Dinámica Funcionamiento

integrantes del [24] interacción verbal constante para que se transmita que es
equipo. lo que se debe de dibujar. Esta dinámica permite mejorar
el nivel de comunicación, al intercambiar ideas permite
escuchar al resto.

D07.-Baja Premiar ideas Consiste en que mensualmente se puede premiar


capacidad de innovadoras cualquier aporte innovador por el equipo
investigación

D08.-Exceso de Capacitaciones Las capacitaciones internas ayudaran a transferir el


especialización en de conocimiento especializado de cada persona al resto del
los integrantes del Transferencia equipo.
equipo. de
Conocimientos

Fuente : Elaboración Propia

1
COMPOSICIÓN DE LOS GRUPOS DE TRABAJO
A continuación se propone una estructura organizacional del personal que se adecuaría al objeto
de estudio. La misma que fue elegida mediante la cuantificación de criterio de selección
(Características) por rol requerido. La evaluación será realizada utilizando números enteros en el
rango de (1,5), asignando un valor de manera objetiva. [17]

PRODUCT OWNER
Tabla 23 : Tabla de criterios de selección de Product Owner
Características Luis Mitsuy Jorge Gallardo

Dominio del Negocio 5 5

Conocimiento del Proceso Gestión de Planeamiento (GPL) 5 3

Habilidades de Comunicación 4 3

Capacidad para manejar Incertidumbres 5 3

Habilidades de negociación 5 4

Accesible 4 5

Proactivo 4 4

Orientado a objetivos 5 3

Promedio 4.62 3.75

Fuente : Elaboración Propia

1
SCRUM MASTER
Tabla 24 : Tabla de criterios de selección de Scrum Master
Características Mario Ruiz Fernando Cordova

Experto de Scrum 3 5

Capacidad de liderazgo 4 4

Habilidades de comunicación 3 4

Habilidades de negociación 5 4

Habilidades de gestión de equipos 2 4

Habilidades de motivación 4 5

Líder de servicio 4 5

Solucionador de problemas 4 5

Habilidades de Coordinación 4 4

Promedio 3.7 4.4

Fuente : Elaboración Propia

SCRUM TEAM
Tabla 25 : Tabla de criterios de selección de Scrum Team
Analista Funcional

Características Juan Ullauri Edwin Pérez

Conocimiento scrum 3 1

Conocimiento del negocio 4 3

Habilidades de trabajo en equipo 5 4

1
Conocimiento técnico 3 2

Responsable 4 4

Promedio 3.8 2.8

Desarrollador 1 y 2

Características Edwin Pando Hugo Huere Juan Campos

Conocimiento scrum 2 0 1

Colaborativo 4 3 4

Habilidades de trabajo en equipo 5 5 5

Conocimiento técnico 5 4 5

Responsable 5 5 5

Promedio 4.2 3.4 4

Analista de Pruebas

Características Miguel Ríos José Isla

Conocimiento scrum 1 3

Conocimiento del negocio 2 4

Habilidades de trabajo en equipo 3 4

Conocimientos técnicas de pruebas. 3 5

Conocimiento en estándares de 2 5
programación.

1
Responsable 5 5

Promedio 2.6 4.3

Fuente : Elaboración Propia

1
ESTRUCTURA ORGANIZACIONAL DEL EQUIPO SCRUM
A continuación se muestra graficamente la estructura organizacional del personal que se adecuaria al objeto de estudio elegida mediante la
cuantificación de criterio de selección (Características) por rol requerido, propuesto por scrum. [17]

Figura 51 : Estructura organizacional del equipo de trabajo Scrum

Fuente : Elaboración Propia

1
ROLES SCRUM EN EL ORGANIGRAMA DE OBJETO DE ESTUDIO
Figura 52 : Estructura organizacional del Product Owner VS. Organigrama

Fuente : Elaboración
1
ROLES SCRUM AREA DE TI (SCRUM MASTER / SCRUM TEAM)
Figura 53 : Estructura organizacional del Equipo Scrum TI VS. Organigrama

Fuente : Elaboración
1
ACTIVIDADES DEL GRUPO DE TRABAJO
Tabla 26 : Tabla de Actividades del grupo de trabajo
Puesto Rol Actividades

Jefe de Product  Establecer claramente la vision del producto, hacia donde va


Planificación Owner el desarrollo.

 Recopilar lor requerientos

 Definir claramente las actividades en realacióna a las


expectativas de los stakeholders.

 Facilitar los canales de comunicación entre todos los


interesados.

 Apoyar y validar las historias de usuario.

 Maximiza la rentabilidad

 Determinar prioridades de las actividades a realizar.

 Participar en las retrospectivas.

 Proveer el feedback y lecciones apendidas necesarias para la


mejora constante.

 Participa de la revision del sprint.

Supervisor Scrum  Ser el entrenador del equipo


Proyectos TI Master
 Facilitar lo necesario que requerieda el equipo para el
cumplimiento de las actividades.

 Facilitar comunicación entre los miembros del equipo.

 Apooyar en las historias de usuario

 Realizar dinamias que fortalescan el trabajo en equipo

 Motivar el uso de dinamicas y herramientas scrum en el


equipo.

 Asegurar la eficiencia y multifuncionalidad del equipo

1
Puesto Rol Actividades

 Proteger al equipo de elementos externos

 Destravar definiciones o negociaciones que impactan en los


tiempos de las actividades.

Analista Scrum  Utilizar los canales de comunicación entre todos los


Funcional Sr. Team interesados.

Desarrollador  Estimar las historias de usuario.

Abap 1  Definir las tareas para el desarrollo.

Desarrollador  Ejecutar desarrollo.

Abap w2  Aplicar tecnicas de calidad para fortalecer el producto.

Analista de  Aceptar y brindar feedback que brinden valor en las mejoras


Pruebas constantes.

 Participar en retrospectivas

1
DEFINICIÓN DE LAS HERRAMIENTAS A UTILIZAR
Determine las herramientas metodológicas que se adecúan al objeto de estudio. Se debe sustentar tanto las que forman parte del grupo de herramientas
a utilizar como las que se dejan fuera de la definición.

Antes de identificar la metodología a utilizar para abordar la propuesta de desarrollo se ha realizado un análisis [09] de las ventajas y desventajas de un
subconjunto representativo de metodologías:

Tabla 27 : Tabla de ventajas y desventajas de metodologías de desarrollo de proyectos


Metodología Ventajas Desventajas Tipo de
Metodología

RUP [10]  Reducción de riesgos, dado que reiniciar un ciclo de  Para procesos relativamente pequeños resulta en un Tradicional
trabajo no implica empezar de nuevo el proceso de trabajo complejo que puede provocar sobrecostos para
desarrollo, por lo cual el consumo de recursos en caso el desarrollo.
de posibles eventualidades disminuye.
 Una aplicación indebida del modelo puede resultar
 Se centra en los casos de uso, facilitando un ineficiente y entorpecer el proceso.
entendimiento del problema para el equipo
 Los tiempos de entrega son mayores en comparación a
desarrollador, promoviendo de esta manera la calidad
metodologías ágiles
del software y la adición de valor al cliente del
 Es una metodología sensible a cambios en etapas
proyecto.
avanzadas del proyecto.
 Permite una visión clara del avance del proyecto en

1
Metodología Ventajas Desventajas Tipo de
Metodología

todo momento, permitiendo fijar metas y administrar


los recursos disponibles de acuerdo a las necesidades
de la metodología.

 Abundante creación de documentos de apoyo que dan


información acerca del software.

SCRUM [11]  El cliente está satisfecho ya que recibe lo que necesita  Si no existe una fecha definitiva de finalización del Ágil
[12]
y esperaba. proyecto es posible que se siga solicitando, y
añadiendo, nueva funcionalidad.
 El coste en términos de proceso y Management es
mínimo, llevando a un resultado más rápido y barato.  Si una tarea no está bien definida, los costes de tiempo
y dinero estimados del proyecto no serán demasiado
 Ayuda a la empresa a ahorrar tiempo y dinero.
exactos. En ese caso, la tarea se puede extender sobre
 Permite realizar proyectos en los que la documentación varios sprints.
de los requerimientos de negocios no están muy claros
 Si los miembros del equipo no están centrados y
como para ser desarrolladas
convencidos, el proyecto nunca se completara o incluso
 Se desarrolla rápidamente y testea. Cualquier error fallará.
puede ser fácilmente rectificado.
 Está bien para proyectos pequeños, de rápido
 Los problemas se identifican por adelantado en las movimiento ya que trabaja bien solo con equipos

1
Metodología Ventajas Desventajas Tipo de
Metodología

reuniones diarias y por lo tanto se pueden resolver pequeños.


rápidamente
 Esta metodología necesita solo miembros de equipo
 Hay visibilidad clara del desarrollo del proceso experimentados. Si el equipo consiste en gente que son
junior, el proyecto no puede ser completado a tiempo.
 Iterativo en su naturaleza, requiere continuo feedback
del usuario  Además de los recursos sin suficiente experiencia, la
falta de dirección firme pueden llevar a los proyectos a
 Fácil de manejar los cambios debido a los sprints tan
no completarse o incluso fallar.
cortos y el feedback constante
 La metodología Scrum funciona bien cuando el scrum
 Poco control que insiste en la información frecuente
master confía en el equipo que lleva. Si se practican
del proceso en el trabajo mediante reuniones regulares.
controles muy estrictos sobre los miembros del equipo,
 Las reuniones diarias hacen posible medir la
puede ser extremadamente frustrante para ellos,
productividad individual. Esto lleva a la mejor en la
llevando a la desmoralización y el fallo del proyecto.
productividad de cada uno de los miembros del equipo.
 Si algunos de los miembros del equipo se marcha
 Para los desarrolladores las ventajas pueden ser
durante el desarrollo puede tener un efecto negativo
motivación y satisfacción de realizar el trabajo de una
enorme en el desarrollo del proyecto.
manera eficiente.
 El control de la calidad del proyecto es difícil de
 Es fácil entregar un producto de calidad en el tiempo
implementar y cuantificar a menos que el equipo de test

1
Metodología Ventajas Desventajas Tipo de
Metodología

estipulado. puedan llevar a cabo testeo de regresión después de


cada sprint.
 Puede trabajar con cualquier tecnología o lenguaje de
programación.

 Hace el proceso del desarrollo de software más


centrado y manejable.

XP (eXtreme  Da lugar a una programación sumamente organizada.  Es recomendable emplearla solo en proyectos a corto Ágil
Programming)
plazo.
[23]  Ocasiona eficiencias en el proceso de planificación y
pruebas.  En caso de fallar, las comisiones son muy altas.

 Cuenta con una tasa de errores muy pequeña.  Requiere de un rígido ajuste a los principios de XP.

 Propicia la satisfacción del programador.  Puede no siempre ser más fácil que el desarrollo
tradicional.
 Fomenta la comunicación entre los clientes y los
desarrolladores.

 Facilita los cambios.

 Permite ahorrar mucho tiempo y dinero.

 Puede ser aplicada a cualquier lenguaje de

1
Metodología Ventajas Desventajas Tipo de
Metodología

programación.

 El cliente tiene el control sobre las prioridades.

 Se hacen pruebas continuas durante el proyecto.

 La XP es mejor utilizada en la implementación de


nuevas tecnologías.

Fuente : Elaboración Propia

El enfoque de esta sección es el análisis de las principales características, extraídas del listado de ventajas y desventajas (ver tabla 46), de los marcos de
trabajo tradicionales en comparación con los ágiles, con la finalidad de identificar las diferencias que resaltan en cada uno de ellos y que les otorgan
ciertas ventajas bajo condiciones específicas. Dado que las diversas metodologías poseen prácticas y comportamientos diferentes, se utilizan criterios
de medición basados en resultados, de esta manera podemos evaluar efectividad, obviando el proceso que cada una realice.

1
La selección de los marcos de trabajo a evaluar se realizó bajo la premisa de frecuencia de uso,
documentación existente y efectividad de la metodología. RUP es el marco de trabajo tradicional
más utilizado actualmente y sobre el cual existe la mayor cantidad de documentación. En cuanto
a metodologías ágiles, XP (eXtreme Programming) y Scrum resaltan por su gran adaptabilidad
frente a cambios y sus drásticas reducciones de los tiempos de desarrollo; además de, la alta
necesidad del compromiso del equipo de trabajo.

A continuación se realizará la discriminación de criterios [09] que servirán como base para una
futura calificación cuantitativa, de manera que sea claramente visible la diferencia en el uso de
una u otra metodología de desarrollo. Se pretende resaltar las diversas ventajas y falencias de los
marcos de trabajo analizados en cuanto al criterio seleccionado.

Tabla 28 : Tabla de Criterios para selección de una Metodología de desarrollo


Criterio Descripción

Presupuesto disponible A la hora de llevar a cabo un proyecto es de vital importancia


realizar un estimado del presupuesto que se va a destinar a este. Los
costos de implementación de cada metodología varían, dados los
requerimientos específicos que cada una de ellas posee.

Tamaño del proyecto Las metodologías tradicionales van enfocadas principalmente hacia
proyectos grandes que conlleven desarrollos a largo plazo. RUP es
una metodología pesada, orientada a los casos de uso y con
estándares que facilitan el desarrollo ordenado para proyectos
grandes, sin embargo, en proyectos relativamente pequeños puede
ocasionar algunos sobrecostos. XP y SCRUM están orientadas
principalmente a proyectos no demasiado extensos.

Tiempos limitados de Todo proyecto, independiente de su tamaño, se ve sujeto a


entrega limitaciones de tiempo, las cuales pueden llegar a marcar la

1
Criterio Descripción

diferencia entre la selección de una metodología ágil o una


tradicional. Las metodologías ágiles se caracterizan por tener
tiempos cortos de diseño e implementación por sus cortas
iteraciones. En contraposición, las metodologías tradicionales
poseen una mejor organización a la hora de la división del trabajo,
conllevando iteraciones más prolongadas. RUP requiere una
cantidad mayor de tiempo para sus iteraciones, en comparación con
una metodología ágil.

Necesidad de Para diversos equipos de trabajo, dependiendo de su tamaño y


documentación organización, se hace necesaria la creación de documentos con una
mayor o menor profundidad. No todas las empresas requieren
documentación exhaustiva sobre su software o los procesos para
llevarlo a cabo. La creación de manuales de usuario es opcional
dentro de algunas empresas.

Tanto XP como Scrum carecen del manejo de una documentación


formal para el desarrollo de los proyectos, la única documentación
que estas 2 metodologías ofrecen es el código resultado de las
diferentes iteraciones. RUP es una metodología orientada a la
creación de múltiples documentos de apoyo para los diversos
procesos.

Personal necesario Existen diferentes tamaños de proyecto, cada uno con sus
requerimientos de personal, dado el software y hardware necesario,
la necesidad de un equipo interdisciplinario y la coordinación
requerida entre cada área del desarrollo.

XP cuenta con numerosos roles para el control de los procesos en la


diferentes iteraciones y el número de personas puede aumentar
dependiendo del tamaño del grupo de programadores, aun así el total
de miembros no sobrepasa los 15. SCRUM es la metodología que
menos personal necesita ya que posee muy pocos roles y su tamaño

1
Criterio Descripción

crece dependiendo del grupo de programación que puede ir de 5 a


10 personas. RUP es una metodología con roles definidos para
grupos grandes de programadores.

Adaptabilidad, Respuesta No todo proyecto se ve sujeto a cambios repentinos durante su


a cambios planeación, pero todos deberían poseer un mecanismo de respuesta
ante estos. La posibilidad de que ocurra un cambio repentino varía
de acuerdo al tipo de proyecto y sus cualidades.

XP y Scrum como metodologías ágiles responden a uno de los


valores en los cuales son basados y esto es la flexibilidad que
poseen en respuesta a los cambios que se pueden presentar en el
desarrollo del proyecto. Las metodologías tradicionales como RUP
son sensibles a cambios, principalmente en etapas avanzadas del
proyecto.

Imposibilidad del cliente El cliente es la parte más importante en el desarrollo de cualquier


proyecto de software, dado que es él quien provee todos los
requerimientos, especificaciones y detalles del proyecto que se va a
llevar a cabo, por lo tanto la disponibilidad de tiempo del cliente
para el proyecto es un tema a poner en consideración.

Scrum como metodología ágil tiene al cliente como parte del


equipo llamándolo Product Owner, el cual participa constantemente
de las correcciones y observaciones en las diferentes entregas de los
Sprints. XP como parte de su estructura de desarrollo posee en sus
prácticas como fundamental la participación del cliente no solamente
como apoyo a los desarrolladores, sino formando parte del grupo.
RUP es un modelo incremental e iterativo, de manera que la
interacción con el cliente se realiza principalmente en etapas
tempranas de planeación y desarrollo.

Fuente : Formulación De Criterios

1
CUANTIFICACIÓN DE CRITERIOS
Teniendo en cuenta los criterios analizados anteriormente, buscamos generar valores que nos
permitan cuantificar la eficacia de cada marco de trabajo para situaciones específicas.
Procedemos así a asignar valores a cada metodología según su grado de cumplimiento con los
criterios existentes.

La evaluación será realizada utilizando números enteros en el rango de (1,5), asignando un valor
objetivo, dependiendo directamente de la necesidad específica de cada proyecto.

Los valores asignados reflejarán la aplicabilidad de la metodología en cuestión a dicho caso en


particular, siendo (5) el valor que indica el mejor cumplimiento del criterio analizado respecto a
las prácticas utilizadas dentro del marco de trabajo. En caso contrario, un valor de (1) implica
que tales prácticas resultan contraproducentes para el correcto desarrollo del proyecto dentro de
las pautas propuestas.

Tabla 29 : Cuantificación de Criterios para selección de una Metodología


Metodología RUP SCRUM XP

Criterio

Presupuesto disponible 1 5 4

Tamaño del proyecto 3 5 2

Tiempos limitados de 1 5 4
entrega

Necesidad de 5 1 3
documentación

1
Personal necesario 5 1 2

Adaptabilidad, 1 5 4
Respuesta a cambios

Imposibilidad del 4 2 1
cliente

Fuente : Formulación De Criterios

Habiendo identificado los puntos críticos de cada marco de trabajo, enumerado y cuantificado las
áreas críticas de los proyectos en general, procedemos entonces a describir un modelo de
selección que facilite la toma de decisiones acerca de la metodología a utilizar.

El modelo que aquí se plantea parte de una selección binaria que pretende resaltar las fortalezas
de las diferentes metodologías, de manera que la selección de estas sea la más adecuada posible
según la visión general que el dueño del proyecto posea de la propuesta de solución de
desarrollo[09].

Tabla 30 : Tabla de condiciones evaluativas


Condiciones Evaluativas Si (1)/No(0)

¿Posee limitaciones de presupuesto para el desarrollo del proyecto? 1

¿Puede el proyecto considerarse de tamaño grande? 0

¿Es necesario que el desarrollo del software se realice en un periodo 1


corto de tiempo en relación con el tamaño de este?

¿Se requiere un volumen amplio de documentación en las diferentes 0


etapas del proyecto?

¿El proyecto requiere ser desarrollado por un equipo amplio y 1


multidisciplinario?

1
Condiciones Evaluativas Si (1)/No(0)

¿Considera que el proyecto a realizar es susceptible a diversos cambios 1


durante su ejecución?

¿Existe alguna imposibilidad del cliente de estar presente durante todo 0


el proceso de desarrollo del proyecto?

Fuente : Formulación De Criterios

Ahora que tenemos los datos del dueño del producto podemos proceder con el cálculo del
producto entre las tablas (Tabla 48 x Tabla 49) y obtener las respectivas valoraciones de las
metodologías en base a los criterios definidos en la tabla anterior.

Tabla 31 : Tabla de resumen de evaluación de marco de trabajo a utilizar


Metodología RUP SCRUM XP

Criterio

Presupuesto disponible 1 5 4

Tamaño del proyecto 0 0 0

Tiempos limitados de entrega 1 5 4

Necesidad de documentación 0 0 0

Personal necesario 5 1 2

Adaptabilidad, Respuesta a 1 5 4
cambios

Imposibilidad del cliente 0 0 0

TOTAL 8 16 14

Fuente : Formulación De Criterios

1
Del cuadro anterior, los criterios que resulten del producto de tablas igual cero, significa que no
es un criterio que genere valor para la toma de decisión de la selección de una metodología y
esto está en función a la realidad de la organización evaluada.

Por lo tanto, de lo analizado anteriormente se define que el marco de trabajo para la propuesta
ágil será SCRUM.

El marco de trabajo Scrum consiste en los Equipos Scrum, roles, eventos, artefactos y reglas
asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y es
esencial para el éxito de Scrum y para su uso. Las reglas de Scrum relacionan los eventos, roles y
artefactos, gobernando las relaciones e interacciones entre ellos.

HERRAMIENTAS Y ARTEFACTOS SCRUM

LISTA DE PRODUCTO (PRODUCT BACKLOG)


Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un
proyecto comienza es muy difícil tener claro todos los requerimientos sobre el producto. Sin
embargo, suelen surgir los más importantes que casi siempre son más que suficientes para un
Sprint.

Existe un rol asociado con esta lista y es el del cliente o Product Owner. Si alguien quiere
realizar cualquier modificación sobre la lista por ejemplo: agregar o incrementar la prioridad de
sus elementos tiene que convencer al Product Owner.

Antes de iniciar la primera iteración, el cliente debe tener definida la meta del producto o
proyecto y la lista de requisitos creada. No es necesario que la lista sea completa ni que todos los
requisitos estén detallados al mismo nivel. En el caso del desarrollo de un producto, la lista va
evolucionando durante toda la vida del producto (los requisitos "emergen"). En el caso de un
proyecto, conforme éste avance irán apareciendo los requisitos menos prioritarios que falten
[13].

1
LISTA DE PENDIENTES DEL SPRINT (SPRINT BACKLOG)
Lista de tareas que el equipo elabora en la reunión de planificación de la iteración (Sprint
planning) como plan para completar los objetivos/requisitos seleccionados para la iteración y que
se compromete a demostrar al cliente al finalizar la iteración, en forma de incremento de
producto preparado para ser entregado.

Esta lista permite ver las tareas donde el equipo está teniendo problemas y no avanza, con lo que
le permite tomar decisiones al respecto.

Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo pendiente para
finalizarlas y la auto asignación que han hecho los miembros del equipo.

A partir de los objetivos a cumplir durante el Sprint el Scrum Team determina que tareas debe
desempeñar para cumplir el objetivo. De esto surge el Sprint Backlog. Es importante destacar
que es el equipo quien se organiza para alcanzar el objetivo. El Manager no asigna tareas a los
individuos y tampoco toma decisiones por el equipo. El equipo puede agregar nuevas tareas o
remover tareas innecesarias en cualquier momento si lo considera necesario para cumplir el
objetivo. Pero el Sprint Backlog solo puede ser modificado por el equipo. Las estimaciones se
actualizan cada vez que aparece nueva información [13].

SCRUM TASKBOARD
La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar
mediante un tablero o pizarra de tareas (Scrum Taskboard) que actúa como radiador de
información. A continuación se muestra cómo construirlo y un ejemplo de su uso.

1
PROPUESTA AGIL DE APLICACIÓN DEL MARCO DE
TRABAJO SCRUM
La propuesta Ágil de mejora del proceso de Gestión de Planeamiento bajo el marco de trabajo
SCRUM es la siguiente:

EQUIPO SCRUM

Tabla 32 : Tabla de equipo Scrum Propuesto para la Propuesta Ágil


Integrante Rol

Luis Mitsyu (Jefe de Planificación) Product Owner

Fernando Cordoba SCRUM Master

Juan Ullauri Analista de Desarrollo

Edwin Campos Desarrollador 1

Juan Pando Desarrollador 2

Fuente : Elaboración Propia

1
PRODUCT BACKLOG

Tabla 33 : Tabla de roles del sistema


Rol Descripción

Planificador Rol encargado de planificar la recuperación


de los Pedidos Pendientes (Backorders).

Jefe de planificación Aprueba las solicitudes de compra.

Representante de Almacén Encargado de la recepción de la mercadería

Sistema SAP Dealer Portal Valida el stock libre de material. Si no hay


disponibilidad, deja los pedidos en estado
pendiente; caso contrario, compromete stock
libre al pedido.

Fuente : Elaboración Propia

Tabla 34 : Tabla de Historias de Usuario


Rol Historia Tareas a Ejecutar
de
Usuario

HU01 Como Planificador, deseo poder visualizar todos mis


pedidos pendientes agrupados por materiales para poder
realizar un seguimiento.
Planificador
HU02 Como Planificador, deseo poder priorizar los pedidos
pendientes para atender los pedidos con mayor urgencia.

HU03 Como Planificador, deseo poder comprometer el stock


desde las fuentes de abastecimiento “Local” para que esos
materiales queden reservados al pedido.

1
Rol Historia Tareas a Ejecutar
de
Usuario

HU04 Como Planificador, deseo poder comprometer el stock


desde las fuentes de abastecimiento en Q” para que los
materiales de ese almacén queden reservados al pedido.

HU05 Como Planificador, deseo enlazar órdenes de compra en


tránsito con pedidos pendientes (B/Os) para reservar
aquellas mercaderías de órdenes de compra que ya están en
camino.

HU06 Como Planificador, deseo asignar órdenes de compra en


estado On-Order con pedidos pendientes (B/Os) para
reservar aquellas mercaderías de órdenes de compra que ya
fueron confirmadas pero aun no son enviadas por el
proveedor.

HU07 Como Planificador, deseo asignar Órdenes de Compra


pendiente de confirmación B/O en Prov. con pedidos
pendientes (B/Os) para reservar aquellas mercaderías de
órdenes de compra pendientes de confirmación por el
proveedor.

HU08 Como Planificador, deseo poder generar órdenes de


compra para cubrir aquellos pedidos pendientes por falta de
stock

HU09 Como Planificador, deseo poder enlazar una orden de


compra a uno o más B/Os para reservar las mercaderías de
la orden de compra para los pedidos pendientes.

HU10 Como Planificador, deseo saber las fechas estimadas de


arribo de los pedidos en tránsito para poder gestionar mejor

1
Rol Historia Tareas a Ejecutar
de
Usuario

la recepción y entrega de las mercaderías.

HU11 Como Planificador, deseo poder atender pedidos


pendientes (BackOrder) de forma distribuida entre las
diferentes fuentes de abastecimiento hasta cubrir la
necesidad requerida para poder reservar mercaderías de las
distintas fuentes de abastecimiento.

HU12 Como Planificador, deseo que el sistema pueda asociar


automáticamente los B/O pendientes a las distintas fuentes
de abastecimiento en base a un conjunto de reglas de
negocio para facilitar la planificación.

El orden de recuperación debe ser así:

1. Tomar stock en Q
2. Transito
3. On-Order
4. B/O en Proveedor.
5. Compra al Proveedor
HU13 Como planificador, deseo poder visualizar el stock en
orden de compra en Tránsito para tener visibilidad del
estado en el que se encuentran esas mercaderías y evaluar
reservarlas.

HU14 Como planificador, deseo poder visualizar el stock en


orden de compra On – order para tener visibilidad del
estado en el que se encuentran esas mercaderías y evaluar
reservarlas.

HU15 Como planificador, deseo poder visualizar el stock en


orden de compra B/O en Prov. para tener visibilidad del

1
Rol Historia Tareas a Ejecutar
de
Usuario

estado en el que se encuentran esas mercaderías y evaluar


reservarlas.

HU16 Como planificador, deseo poder visualizar el stock local


para tener visibilidad del estado en el que se encuentran
esas mercaderías y evaluar reservarlas.

HU17 Como planificador, deseo poder visualizar el stock en Q


para tener visibilidad del estado en el que se encuentran
esas mercaderías y evaluar reservarlas.

HU18 Como planificador, deseo poder re planificar


automáticamente la asociación a las distintas fuentes de
abastecimiento a demanda, en base al estado de los stocks
de las fuentes de abastecimiento para contemplar nuevos
pedidos de compra en camino y cubrir otras pedidos
pendientes (B/Os).

Jefe de HU19 Como Jefe de Planificación, deseo poder aprobar las


planificación solicitudes de compra para poder realizar un control de los
pedidos.

HU20 Como Jefe de Planificación, deseo poder contar con


informe diario del estatus actual de los pedidos pendientes
para tener un control de si éstos se están recuperando
eficientemente.

HU21 Como representante de almacén, deseo durante la


recepción de una orden de compra poder identificar
mercaderías enlazadas a pedidos pendientes (B/Os) para
agilizar la recuperación y despacho de los pedidos

1
Rol Historia Tareas a Ejecutar
de
Usuario

Representante pendientes (B/Os) asociados a esta orden de compra.


de Almacén
HU22 Como representante de almacén, deseo poder identificar en
la recepción que se trata de una orden de compra enlazada
cuando estuvo en tránsito con pedidos pendientes (B/Os)
para agilizar la recuperación y despacho de estos pedidos
pendientes.

HU23 Como representante de almacén, deseo poder identificar en


la recepción que se trata de una orden de compra enlazada
cuando estuvo en On-order con pedidos pendientes (B/Os)
para agilizar la recuperación y despacho de estos pedidos
pendientes.

HU24 Como representante de almacén, deseo poder identificar en


la recepción que se trata de una orden de compra enlazada
cuando estuvo en BO en prov con pedidos pendientes
(B/Os) para agilizar la recuperación y despacho de estos
pedidos pendientes.

HU25 Como representante de almacén, durante la recepción


deseo poder generar un documento de ingreso de
mercadería a almacén (Incrementa Stock) para poder tener
el control de los movimientos de almacen.

HU26 Como representante de almacén, deseo durante la


recepción poder identificar si hay B/Os sin planificar
asociados a los productos recibidos para que de forma
automática reservarlos como “Stock en Q”.

HU27 Como representante de almacén, deseo que durante la


recepción las B/Os pendientes que fueron recuperadas

1
Rol Historia Tareas a Ejecutar
de
Usuario

pasen a un estado de Comprometidas para que el


representante de despacho lo pueda identificar.

HU28 Como Sistema SAP Dealer Portal, deseo validar el stock de


material libre disponible para poder comprometer el stock
Sistema SAP
de los materiales disponibles o caso contrario para dejar en
Dealer Portal
B/Os los materiales no disponibles.

HU29 Como Sistema SAP Dealer Portal, se desea indicar el


estatus de los pedidos pendientes (BackOrder), indicando
fecha estimada de atención para tener visibilidad de su
recuperación.

HU30 Como Sistema SAP Dealer Portal, deseo poner los


materiales de un pedido en Backorder por falta de stock
libre disponible para luego ser recuperado.

Fuente : Elaboración Propia

Priorizar Historias de usuarios:


Para priorizar las historias de usuario se va a contemplar 3 factores claves [19]:

Valor
La valoración de las historias de usuario fue definida por el Jefe de Logística (Producto Owner)
y lo que se contempla es la importancia de cubrir esa necesidad de negocio. Los valores a
asignarse deben estar en un rango de [1 a 5] donde 1 es muy bajo y 5 es muy alto.

1
Costo
El costo de cada historia de usuario será estimado por el equipo. Para ello, se contemplará la
complejidad de las historias de usuario y nos apoyaremos en una técnica llamada “Planning
Poker”[20][27], también conocida como “Estimation Poker”, la cual usa un consenso del equipo
para estimar el esfuerzo requerido de las historias de usuario.

En esta técnica cada miembro del equipo del proyecto se le asigna una baraja de cartas. Cada
carta es numerada en una secuencia definida, la cual se basa en la serie Fibonacci[28] con cierta
variación, que representa la complejidad del problema en términos de tiempo y esfuerzo en base
a juicio experto del miembro del equipo.

Se incluye el 0 para elementos que no requieren esfuerzo y ½ para elementos muy pequeños. A
partir del 21 pasa al infinito (∞) ya que cualquier elemento (tarea) con una estimación mayor
debe dividirse en parte menores. El signo interrogación (?) significa que es imposible estimar por
falta de información o detalle y la tasa de café significa que estamos cansados y es hora de hacer
un descanso.

Para el caso del proyecto se propone la siguiente baraja de cartas que representa la complejidad
de cada tarea.

Figura 54 : Baraja de Plannning Poker

Fuente: [Internet – estratecno – Planning Poker]

1
Funcionamiento:

A continuación se detalla los criterios para la aplicación de la técnica al proyecto [27]

 Cada participante tiene un juego de cartas.

 Cada participarte selecciona la carta con que estima un elemento y la pone boca abajo.

 Cuando todos han hecho su selección, se muestra boca arriba.

 Si la estimación resulta infinito, por sobrepasar el límite máximo establecido de 21, el


elemento debe dividirse en elementos de menor tamaño.

 Si las estimaciones resultan muy dispares, quien asume la responsabilidad de gestionar la


reunión, usualmente el SCRUM MASTER, con su criterio de gestión, y basándose en las
características del proyecto, equipo, reunión, nº de elementos pendientes de evaluar, puede
optar por:

- Preguntar a las personas de las estimaciones extremas: ¿Por qué crees que es necesario
tanto tiempo?, y ¿por qué crees que es necesario tan poco tiempo? Tras escuchar las
razones, repetir la estimación.

- Dejar a un lado la estimación de ese elemento y retomar al final o en otro momento


aquellas que hayan quedado pendientes.

- Pedir al cliente o propietario del producto que descomponga el elemento y estimar cada
uno de los elementos resultantes.

- Tomar la estimación menor, mayor, o la media.

Riesgo
Determinado por el equipo. Si hay una historia con prioridad media pero que mitiga muchos
riesgos, se debería hacer más prioritaria, eso hace que las historias que mitigan menos riegos
bajen de prioridad.

1
Primero, se ordenan las historias de usuario en función al costo y al valor de cada una de ellas
[20].

 Una Historia con Alto Valor y Bajo Costo sería muy prioritaria.

 Una Historia con Bajo Valor y Alto costo sería poco prioritaria.

1
Lista de historias de usuario priorizadas y agrupadas por iteración “Sprint Backlog”

Tabla 35 : Priorización de Historias de Usuarios en base a Valor y Costo


CODIGO NECESIDAD VALOR COSTO SPRINT

Como Planificador, deseo poder visualizar todos mis pedidos pendientes agrupados por
HU01 5 1
materiales para poder realizar un seguimiento.

Como Planificador, deseo poder enlazar una orden de compra a uno o más B/Os para reservar
HU09 5 1
las mercaderías de la orden de compra para los pedidos pendientes.

Como Jefe de Planificación, deseo poder aprobar las solicitudes de compra para poder
HU19 5 1
realizar un control de los pedidos. SPRINT 1

Como Sistema SAP Dealer Portal, deseo poner los materiales de un pedido en Backorder por
HU30 5 1
falta de stock libre disponible para luego ser recuperado.

Como Sistema SAP Dealer Portal, deseo validar el stock de material libre disponible para
HU28 poder comprometer el stock de los materiales disponibles o caso contrario para dejar en B/Os 4 1
los materiales no disponibles.

1
CODIGO NECESIDAD VALOR COSTO SPRINT

Como representante de almacén, durante la recepción deseo poder generar un documento de


HU25 ingreso de mercadería a almacén (Incrementa Stock) para poder tener el control de los 5 2
movimientos de almacen.

Como Planificador, deseo poder generar órdenes de compra para cubrir aquellos pedidos
HU08 4 2
pendientes por falta de stock

Como representante de almacén, deseo durante la recepción de una orden de compra poder
HU21 identificar mercaderías enlazadas a pedidos pendientes (B/Os) para agilizar la recuperación y 4 2
despacho de los pedidos pendientes (B/Os) asociados a esta orden de compra.

Como representante de almacén, deseo que durante la recepción las B/Os pendientes que
HU27 fueron recuperadas pasen a un estado de Comprometidas para que el representante de 4 2
despacho lo pueda identificar.

Como Planificador, deseo enlazar órdenes de compra en tránsito con pedidos pendientes
HU05 5 3
(B/Os) para reservar aquellas mercaderías de órdenes de compra que ya están en camino.

SPRINT 2
Como Planificador, deseo asignar órdenes de compra en estado On-Order con pedidos
HU06 pendientes (B/Os) para reservar aquellas mercaderías de órdenes de compra que ya fueron 5 3
confirmadas pero aun no son enviadas por el proveedor.

1
CODIGO NECESIDAD VALOR COSTO SPRINT

Como Planificador, deseo asignar Órdenes de Compra pendiente de confirmación B/O en


HU07 Prov. con pedidos pendientes (B/Os) para reservar aquellas mercaderías de órdenes de 5 3
compra pendientes de confirmación por el proveedor.

Como Planificador, deseo saber las fechas estimadas de arribo de los pedidos en tránsito para
HU10 5 3
poder gestionar mejor la recepción y entrega de las mercaderías.

Como representante de almacén, deseo poder identificar en la recepción que se trata de una
HU22 orden de compra enlazada cuando estuvo en tránsito con pedidos pendientes (B/Os) para 5 3
agilizar la recuperación y despacho de estos pedidos pendientes.

Como representante de almacén, deseo poder identificar en la recepción que se trata de una
HU23 orden de compra enlazada cuando estuvo en On-order con pedidos pendientes (B/Os) para 5 3
agilizar la recuperación y despacho de estos pedidos pendientes.

Como representante de almacén, deseo poder identificar en la recepción que se trata de una
HU24 orden de compra enlazada cuando estuvo en BO en prov con pedidos pendientes (B/Os) para 5 3
agilizar la recuperación y despacho de estos pedidos pendientes.

Como Sistema SAP Dealer Portal, se desea indicar el estatus de los pedidos pendientes
HU29 5 3
(BackOrder), indicando fecha estimada de atención para tener visibilidad de su recuperación.

1
CODIGO NECESIDAD VALOR COSTO SPRINT

Como Planificador, deseo poder atender pedidos pendientes (BackOrder) de forma


HU11 distribuida entre las diferentes fuentes de abastecimiento hasta cubrir la necesidad requerida 4 3
para poder reservar mercaderías de las distintas fuentes de abastecimiento.

Como planificador, deseo poder visualizar el stock en orden de compra en Tránsito para tener
HU13 4 3
visibilidad del estado en el que se encuentran esas mercaderías y evaluar reservarlas.

Como planificador, deseo poder visualizar el stock en orden de compra On – order para tener
HU14 4 3
visibilidad del estado en el que se encuentran esas mercaderías y evaluar reservarlas.

Como planificador, deseo poder visualizar el stock en orden de compra B/O en Prov. para
HU15 4 3
tener visibilidad del estado en el que se encuentran esas mercaderías y evaluar reservarlas.

Como Jefe de Planificación, deseo poder contar con informe diario del estatus actual de los
HU20 4 3
pedidos pendientes para tener un control de si éstos se están recuperando eficientemente.

Como Planificador, deseo poder comprometer el stock desde las fuentes de abastecimiento
HU03 3 3 SPRINT 3
“Local” para que esos materiales queden reservados al pedido.

Como Planificador, deseo poder comprometer el stock desde las fuentes de abastecimiento en
HU04 3 5
Q” para que los materiales de ese almacén queden reservados al pedido.

1
CODIGO NECESIDAD VALOR COSTO SPRINT

Como planificador, deseo poder visualizar el stock local para tener visibilidad del estado en
HU16 3 3
el que se encuentran esas mercaderías y evaluar reservarlas.

Como planificador, deseo poder visualizar el stock en Q para tener visibilidad del estado en
HU17 3 3
el que se encuentran esas mercaderías y evaluar reservarlas.

Como representante de almacén, deseo durante la recepción poder identificar si hay B/Os sin
HU26 planificar asociados a los productos recibidos para que de forma automática reservarlos como 2 8
“Stock en Q”.

Como Planificador, deseo poder priorizar los pedidos pendientes para atender los pedidos
HU02 3 8
con mayor urgencia.

Como Planificador, deseo que el sistema pueda asociar automáticamente los B/O pendientes SPRINT 4
a las distintas fuentes de abastecimiento en base a un conjunto de reglas de negocio para
facilitar la planificación.

HU12 El orden de recuperación debe ser así: 2 13


1.Tomar stock en Q
2. Transito
3. On-Order
4. B/O en Proveedor.

1
CODIGO NECESIDAD VALOR COSTO SPRINT

5. Compra al Proveedor

Como planificador, deseo poder re planificar automáticamente la asociación a las distintas


fuentes de abastecimiento a demanda, en base al estado de los stocks de las fuentes de
HU18 2 13
abastecimiento para contemplar nuevos pedidos de compra en camino y cubrir otras pedidos
pendientes (B/Os).

Fuente : Agile Estimating and Planning

1
Luego, partiendo de la priorización inicial se incorpora el riesgo:

 Una historia con una prioridad media, pero que mitiga muchos riesgos al implementarse, se debería hacer más prioritaria.

 Por otro lado, las historias que mitigan menos el riesgo bajen de prioridad.

Por lo tanto, en vista que la no implementación de la historia de usuario HU26 podría generar un alto riesgo de que B/Os que no fueron planificadas por
omisión no sean recuperadas a tiempo quedándose incompleta la atención de un pedido comercial. Por tal motivo, esta historia de usuario sube de
prioridad y será contemplada en el SPRINT 3

HU26 Como representante de almacén, deseo durante la recepción poder identificar si hay B/Os sin planificar asociados a los productos recibidos par

1
Para obtener el tiempo de cada Sprint, el equipo evalúa un conjunto de criterios propuestos por
Scrum [20]

Tabla 36 : Tabla de Cuestionario para delimitar el Sprint


1 semana 2 semanas 3 semanas 4 semanas

Estimación de la duración del proyecto


5 5 5 1
de 3 meses

Existe alta disponibilidad de los usuarios 5| 3 4 1

El usuario conoce algo de Scrum 1 5 5 5

No hay barreras culturales 5 5 5 5

Hay algunos asuntos reglamentarios 3 5 5 3

La experiencia en scrum es limitada 1 3 3 5

Capacidad técnica del equipo exelente 5 5 5 1

Existe poca capacidad de


1 1 1 5
descomposición de tareas

Promedio 3 4 4.125 3.25

Fuente : Agile Estimating and Planning

1
Tabla 37 : Tabla de Tareas de la primera Iteración - Sprint 1
Tiempo
SPRINT CODIGO NECESIDAD Tareas
(hrs)

Definición de información a visualizar en el listado de backorder 2

Como Planificador, deseo poder visualizar Diseñar como se mostrará la información del listado de backorders 2

todos mis pedidos pendientes agrupados por


HU01 Elaboración de función para el listado de backorder. 4
materiales para poder realizar un
seguimiento. Desarrollo de dynpro de listado de backorder. 4

Realizar pruebas unitarias 2


SPRINT
Definición de regla para determinar el tipo de orden de compra a utilizar. 2
1

Elaboración de Estructura de Tablas de BBDD para relacionar Orden de


Como Planificador, deseo poder enlazar una 4
Compra con B/O
orden de compra a uno o más B/Os para
HU09
reservar las mercaderías de la orden de Desarrollo de dynpro que soporte el enlace entre Orden de Compra y B/O 4

compra para los pedidos pendientes.


Desarrollo de función para ejecutar el enlace entre Orden de Compra y B/O 4

Realizar pruebas unitarias 4

1
Tiempo
SPRINT CODIGO NECESIDAD Tareas
(hrs)

Definición de regla de aprobación. 2

Desarrollo de bandeja para el workflow de aprobación de solicitudes de


Como Jefe de Planificación, deseo poder 4
compra.
HU19 aprobar las solicitudes de compra para poder
realizar un control de los pedidos. Desarrollo de función que soporte la funcionalidad de aprobación. 2

Pruebas unitarias 4

Desarrollo de función para determinar los materiales que no hay en almacén


2
Como Sistema SAP Dealer Portal, deseo local como BackOrder.
poner los materiales de un pedido en
HU30 Modificar Interfaz SAP Dealer Portal para invocar a función que deja
Backorder por falta de stock libre disponible 4
materiales en Backorder cuando no hay stock libre disponible
para luego ser recuperado.
Pruebas unitarias 2

Como Sistema SAP Dealer Portal, al generar Desarrollar la función que valide el stock libre del material contra la
2
HU28 un pedido de comercial, deseo validar el necesidad requerida.
stock de material libre disponible para poder
Modificar la Web dynpro para mostrar el stock actual y stock en B/O 4
comprometer el stock de los materiales

1
Tiempo
SPRINT CODIGO NECESIDAD Tareas
(hrs)

disponibles o caso contrario para dejar en


Pruebas Unitarias 4
B/Os los materiales no disponibles.

Como representante de almacén, durante la Definir información mínima necesaria para generar documento de material 2
recepción deseo poder generar un
HU25 documento de ingreso de mercadería a Elaborar la función global que permita generar el documento de material
almacén (Incrementa Stock) para poder tener por ingreso de mercadería 4

el control de los movimientos de almacén.

Definir información mínima necesaria para generar orden de compra. 2

Diseñar la solicitud de orden de compra 2

Actualizar entidades de BBDD para relacionar los B/O con la nueva orden de
Como Planificador, deseo poder generar 4
compra.
HU08 órdenes de compra para cubrir aquellos
pedidos pendientes por falta de stock Desarrollar función de generación de orden de compra por B/O 4

Desarrollar LOG de confirmación o Error por la ejecución. 2

Pruebas Unitarias 4

1
Tiempo
SPRINT CODIGO NECESIDAD Tareas
(hrs)

Como representante de almacén, deseo Definir regla de validación para diferenciar órdenes de compra por B/O 2
durante la recepción de una orden de compra
Adecuar dynpro en la recepción de mercadería para permita diferenciar un
poder identificar mercaderías enlazadas a 4
ingreso general con un ingreso previamente planificado por BackOrder.
HU21 pedidos pendientes (B/Os) para agilizar la
recuperación y despacho de los pedidos
pendientes (B/Os) asociados a esta orden de Pruebas Unitarias 4
compra.

Desarrollar función para comprometer pedidos comerciales con la


4
mercadería ingresada previamente planificada.

Como representante de almacén, deseo que Actualizar entidades de BBDD de relación entre orden de compra con el B/O
4
durante la recepción las B/Os pendientes que para actualizar el estado a "Comprometido".
HU27 fueron recuperadas pasen a un estado de
Alertar Vía mail al área comercial de la recepción de una orden planificada.
Comprometidas para que el representante de 4
despacho lo pueda identificar.

Modificar Dynpro de recepción para que indique las cantidades ingresar por
4
planificación.

1
Tiempo
SPRINT CODIGO NECESIDAD Tareas
(hrs)

Pruebas unitarias 4

Fuente : Elaboración Propia

1
Scrum Taskboard Propuesto

Figura 55 : Scrum Taskboard Propuesto

Fuente: Manifiesto Agile

Tabla 38 : Formato de Lista de Impedimentos


IMPEDIMENTO

Pendiente En Progreso Hecho En Pruebas

Fuente: Elaboración Propia

1
Tabla 39 : Formato de Lista de Retrospectiva: Listado de aspectos a mejorar
RETROSPECTIVA

Aspecto a Mejorar Aspecto Mejorado Mejoras Pendientes

Fuente: Elaboración Propia

PRESUPUESTO DE PROPUESTA AGIL

Formula de Horas Trabajadas: (Sueldo / 30) / 8

Figura 56 : Presupuesto de la Propuesta Ágil

Fuente: Elaboración Propia

El importe aproximado a utilizar durante las 16 semanas de desarrollo es de $ 58,084.00.

1
CONCLUSIONES
Como resultado de este capítulo que detalla una propuesta de desarrollo bajo una metodología
Ágil, se puede concluir que la calidad de los entregables de un producto software, la motivación
del equipo de desarrollo y el incremento de la productividad son factores que están
completamente relacionados.

Las metodologías ágiles permiten a todos los miembros del equipo conocer el estado del
proyecto en todo momento, las ideas de cada integrante son tomadas en cuenta, lo cual hace que
cada integrante se sienta más comprometido con el proyecto. El compromiso de cada integrante
es un motor de cambio cultural que motiva al resto del equipo. La motivación es un pilar
importante en el incremento de la productividad. Por tanto, el compromiso de un equipo generara
tarde o temprano una mayor productividad.

Por consiguiente, como bien lo expone Philip Atkinson, la cultura organizacional “es la
infraestructura, el pegamento que enlaza personas y procesos para generar resultados
importantes. La cultura debe convertirse en la mayor fuerza que empuja la organización hacia
adelante” [07].

1
1
CAPÍTULO 4. GESTIÓN DE SERVICIOS EN TI

INTRODUCCIÓN
El presente capitulo presenta el marco para la gestión de servicios de tecnología de la
información que suele enmarcarse en el ámbito del denominado gobierno de TI, siguiendo el
ciclo de vida del servicio según el enfoque propuesto por ITIL relacionados a los procesos
diseñados por la organización.

EVALUACIÓN ESTRATÉGICA

ESTRATEGIA DE NEGOCIO

Visión
Ir a la sección visión del capítulo 1 para ver la descripción.

Misión
Ir a la sección misión del capítulo 1 para ver la descripción.

Objetivos estratégicos
Tabla 40 : Objetivos estratégicos ordenados por prioridad de inversión
Objetivos Estratégicos Orden

Disminuir el tiempo de abastecimiento de BackOrder (pedidos Alta


pendientes) en un 30% con respecto al año 2016.

Mejorar las ventas de repuestos al exterior en un 20% con respecto al año Alta

1
Objetivos Estratégicos Orden

2016.

Incrementar el ensamblaje de motos en un 10% por modelo con respecto Media


al año 2016

Incrementar la satisfacción de los empleados en los ambientes de trabajo Media


a un 10% en relación a la encuesta del 2015.

Disminuir el porcentaje de renuncias en un 5% en relación al segundo Media


periodo del 2016.

Disminuir los gastos por subcontratación en un 20% con respecto al año Baja
2016.

Fuente: Elaboración Propia

PRIORIDADES DE LA ORGANIZACION
A continuación se indican las prioridades de inversión de la organización:

Tabla 41 : Priorización de inversión


Descripción de Prioridad de inversión Prioridad

Mejorar de los procesos que se encargan del abastecimiento de Alta


mercaderías

Mejorar las capacidades de recepción de pedidos de compra Alta

Mejorar la capacidad del equipo de ensamblaje de motos Media

Identificar las causas de pérdidas de personal clave en la organización Media

Capacitar y promover las certificaciones SAP al personal de TI Baja

Fuente: Elaboración Propia

1
FODA
El análisis FODA pretende identificar los puntos fuertes y las debilidades de una organización y
las oportunidades y amenazas en el medio ambiente [14].

Análisis Interno

FORTALEZAS

 F01.- Filosofía e historia de la compañía, que se transmite a las personas que integran la
misma y que les permite tener un óptimo ambiente laboral.

 F02.- Personal altamente calificado en los roles asignados y solidos conocimiento del
negocio, los cuales están conformados por la Alta Gerencia, Asesores, Línea de negocio y
equipo de apoyo.

 F03.- Solidez en recursos financieros.

 F04.- Alta variedad de productos.

 F05.- Innovación tecnológica.

DEBILIDADES

 D01.- No fomentar la calidad del producto y el servicio de post ventas asociado al mismo.

 D02.- El área de sistemas no cuenta con una metodología de trabajo definida para el
desarrollo de los proyectos de Software.

 D03.- Constante rotación del personal, lo cual genera pérdidas de conocimiento.

 D04.- Ineficiencia en la planificación de abastecimiento de mercadería para cubrir


necesidades del sector local y externo (Repuestos).

 D05.- Poca comunicación entre los integrantes del equipo.

 D06.-Resistencia al cambio.

1
 D07.-Baja capacidad de investigación

 D08.-Exceso de especialización en los integrantes del equipo.

Análisis Externo

OPORTUNIDAD

 O01.- Mayor crecimiento económico mundial en países de desarrollo.

 O02.- Bonanza exportadora por mejores precios en el mercado mundial.

 O03.- Alianzas público-privado para invertir en infraestructura y retorno de capital humano


por situación económica favorable.

 O04.- Integración al mundo con TLC y con Brasil, nexo del atlántico con el pacifico.

 O05.- Crecimiento del servicio HUB para unificar y abastecer de productos a las filiales del
continente.

 O06.- Fidelización de los clientes debido a su historia y a su gran valor que posee la marca
como producto de aceptación y confianza de sus clientes.

 O07.- Los clientes conocen el producto fabricado.

 O08.- La preocupación del medioambiente, genera que se consuman productos que no


contaminen el medio ambiente.

 O09.- Exoneración tributaria en el lado oriente del país.

AMENAZA
A01.- Corrupción e impunidad crecientes en el sistema político y en el estado.

 A02.- Crecimiento de competencia con variedad de productos y costo menor al nuestro.

 A03.- Rápida innovación de los competidores.

 A04.- Tendencias volátiles: en el mercado automotriz las tecnologías cambian rápidamente.

1
SERVICIOS DE NEGOCIO OFRECIDOS
A continuación se listan los servicios ofrecidos por la organización relacionados al proceso del
negocio.

Servicios Externos del Negocio


Tabla 42 : Servicios Externos del Negocio
Procesos de Negocio Servicios ofrecidos por el Negocio

Gestión Comercial  Servicio de generación de pedidos


comerciales.

 Servicio de despacho de productos.

 Servicio de transporte de productos.

 Servicio de picking / packing de


productos.

 Servicio de consignación a clientes.

Gestión de Post Venta (PV)  Servicio de reclamo de garantía

 Servicio de mantenimiento de unidades.

Fuente: Elaboración Propia

1
Servicios Internos del Negocio
Tabla 43 : Servicios Internos del Negocio
Procesos de Negocio Servicios ofrecidos por el Negocio

Gestión de Importaciones (IMP)  Servicio de generación de orden de compras de


importación.

 Servicio de liberación automática de órdenes de


compra de importación.

 Servicio de ingreso de mercadería de importación


(Estándar / PDA).

 Servicio de recepción de facturación del acreedor.

Gestión de Planeamiento (GPL)  Servicio de planificación de pedidos comerciales


pendientes.

Gestión de Producción  Servicio de aprovisionamiento de materia prima.

 Servicio de planificación de productos a fabricar.

 Servicio de línea de producción.

 Servicio de embalaje.

 Servicio de producción de chasis.

Gestión de Calidad en la  Servicio de calidad en línea de producción.


Producción(GCP)
 Servicio de reparación y re evaluación de calidad.

Administración Logística (AL)  Servicio de aprovisionamiento de productos.

 Servicio de traslado entre centros / almacenes.

 Servicio de transformación.

 Servicio de consignación de productos de

1
Procesos de Negocio Servicios ofrecidos por el Negocio

acreedores.

Gestión de Mantenimiento de  Servicio de gestión de equipos de planta.


Planta

Fuente: Elaboración Propia

ESTRATEGIA DE TI

Servicios Internos/Externos Identificados


Tabla 44 : Servicios Internos/Externos Identificados
Servicio Tipo de Servicio Proceso del Negocio

Servicio de Planificación de Pedidos Interno Gestión de Planeamiento (GPL)


Comerciales Pendientes

Fuente: Elaboración Propia

Descripción de los Servicios


A continuación se describe a alto nivel la razón de ser del servicio identificado.

Tabla 45 : Descripción de los servicios identificados


Servicio Descripción

Servicio de Planificación de Pedidos El servicio tiene como funcionalidad planificar la


Comerciales Pendientes recuperación y atención de los pedidos comerciales
pendientes por falta de stock.

Fuente: Elaboración Propia

1
PRIORIDADES DE INVERSION
Las siguientes son las prioridades de inversión de TI respecto a los servicios identificados. Estas
prioridades toman como base los objetivos estratégicos asociados a las prioridades de la
organización.

Tabla 46 : Prioridades de Inversión


Objetivo Estrategico Prioridad de Inversión Justificacion

Disminuir el tiempo de Mejorar el Servicio de La mejora de la capacidad de


abastecimiento de Planificación de Pedidos recuperacion de los pedidos
BackOrder (pedidos Comerciales Pendientes pendientes en el menor tiempo
pendientes) en un 30% posible se alinea a cumplir el objetivo
con respecto al año estrategico del negocio relacionado.
2016.
Tambien, evita la cancelacion de los
Mejorar las ventas de Mejorar el Servicio de pedidos pendientes por demoras en la
repuestos al exterior en Planificación de Pedidos entrega de los mismos.
un 20% con respecto al Comerciales Pendientes
Mejora la satisfaccion del cliente por
año 2016.
la rapidez en la entrega de los
pedidos

Otorga mayor competitividad a la


organización.

Fuente: Elaboración Propia

1
PLANIFICACIÓN ESTRATÉGICA

SERVICIOS IDENTIFICADOS

Servicios Internos, Externos y de Soporte


Tabla 47 : Ficha de Listado de Servicios
Código Servicio Versión Descripción Tipo Propietario Prioridad

SINT0001 Servicio de 01 Planificar el Interno Área de ALTA


Planificación de abastecimiento de los Importación
Pedidos pedidos comerciales
Comerciales pendiente de atención,
Pendientes mediante 6 fuentes de
abastecimiento.

SEXT0001 Servicio de 01 Brindar el soporte Externo Área de MEDIO


Soporte y necesario para garantizar la Importación
Mantenimiento disponibilidad y
ERP SAP continuidad del servicio.

Fuente: Elaboración Propia

1
Descripción de los Servicios
Tabla 48 : Ficha del Servicio [SINT001]
[SINT0001] Versión : 01

Servicio de Planificación de Pedidos Comerciales Pendientes

Descripción Planificar el abastecimiento de los pedidos comerciales pendiente de atención, mediante 6


fuentes de abastecimiento.

Tipo INTERNO Categoría LOGISTICA

Servicios de Soporte [SEXT0001] Servicio de Soporte y Mantenimiento ERP SAP

Propietario Área de Importación

Proceso de Negocio Gestión de Planeamiento (GPL)

Impacto  Detiene la planificación de atención de Prioridad ALTA

pedidos comerciales pendientes.

 Al recepcionar pedidos de compra


planificados no podrá comprometer a los
pedidos comerciales pendientes de
atención.

SLA < SLA Servicio de Planificación de Pedido Horas de <L – V>


Comerciales Pendientes Servicio
07:00 a 22:00horas
>

Contacto [Fernando Córdova] [Jefe de TI ] [981233120] [fernando.cordoba@honda.com.pe]

[Luis Mitsuy ] [Jefe de Planificación] [976131320] [luis.mitsuy@honda.com.pe]

Fuente: Elaboración Propia

2
Tabla 49 : Table 1 : Ficha del Servicio [SEXT001] /
[SEXT0001] Versión : 01

Servicio de Soporte y Mantenimiento ERP SAP

Descripción Brindar el soporte necesario para garantizar la disponibilidad y continuidad del servicio.

Tipo EXTERNO Categoría SOPORTE

Servicios de Soporte

Propietario TI / GMD

Proceso de Negocio Soporte

Impacto Se pierde el soporte la garantía en la disponibilidad y Prioridad ALTA


continuidad del servicio.

SLA SLA Servicio de Soporte y Mantenimiento ERP SAP Horas de <L – V>
Servicio
07:00am - 22:00hoas

Contacto

[Mario Ruiz Pintado][Supervisor GMD] [987665345] [mruiz@gmd.com.pe]

[Fernando Córdova] [Jefe de TI] [981233120] [fernando.cordoba@honda.com.pe]

Fuente: Elaboración Propia

2
Requerimientos del Servicio Identificado
Tabla 50 : Ficha del Requerimiento [SINT001]
[RQ-SINT0001] Versión : 01

Servicio de Soporte y Mantenimiento ERP SAP

Proceso(s) de Negocio(s) Gestión de Planeamiento (GPL)

Propietario Área de Importación Tipo INTERNO

Alcances Brinda las herramientas necesarias para planificar y comprometer de forma automática
pedido comerciales pendientes de atender por falta de stock.

Objetivos Satisfacer la atención planificada a menor tiempo de pedidos comerciales pendientes de


atender.

Objetivos Estratégicos  Mejorar las ventas de autos en un 20% con respecto al año 2016.

 Disminuir el tiempo de abastecimiento de BackOrder (pedidos


comerciales pendientes) en un 30% con respecto al año 2016.

Funcionalidad /  Contar con una herramienta que permita gestionar y planificar


Requerimiento efectivamente los BackOrder.

 Contar con la facilidad de poder emparejar backorder al pedido de


compra generado obteniendo una fecha ETA de la atención.

 Poder emparejar backorder a pedidos de compra en transito a nivel de


posiciones para priorizar el abastecimiento de mercadería y atender los
backorder de los clientes.

 Permitir emparejar las necesidades requeridas a las solicitudes de

2
pedido para reducir el tiempo de abastecimiento de mercadería.

 Contar con un panel general en el que se identifiquen los stock de los


productos incluidos en los backorder y realice el traslado entre
almacenes de la necesidad requerida y comprometa de forma
automática los pedidos comerciales para que se inicie el despacho de la
necesidad del cliente.

 Al realizar el traslado entre almacenes debe de respetar el stock máximo


de la mercadería asignada al almacén origen para que no se quede
desabastecido.

 En la recepción de mercadería se debe de identificar que el pedido de


compras a recepcionar es para cubrir la necesidades por backorder para
que de forma automática se separe el stock comprometido al almacen
correspondiente de los pedidos comerciales.

 En la recepción de mercadería se debe de identificar si hay pedidos


pendientes sin planificar asociados a los productos recibidos para que
de forma automática ingrese el stock en estado de calidad y
comprometa los pedidos comerciales para que se inicie el despacho de
la necesidad del cliente.

Fuente: Elaboración Propia

2
Tabla 51 : Ficha del Requerimiento [SEXT001]
[RQ- SEXT0001] Versión : 01

Servicio de Soporte y Mantenimiento ERP SAP

Proceso(s) de Negocio(s) Tecnología de la Información (TI)

Propietario Área de TI / GMD Tipo EXTERNO

Alcances Brindar el soporte necesario para garantizar la disponibilidad y continuidad del servicio.

Objetivos  Garantizar el correcto funcionamiento del Servicio

 Garantizar la disponibilidad del Servicio

 Garantizar la Continuidad del Servicio.

 Garantizar el cumplimiento de UC

Objetivos Estratégicos  Brindar apoyo a todos los objetivos estratégicos del objeto de estudio
relacionados al soporte funcional SAP.

Funcionalidad /  Identificar falta de funcionalidad del servicio.


Requerimiento
 Atender consultas de procedimiento o de flujo del servicio.

 Si hubiera alguna demora o falla en el servicio, se realizará las


revisiones funcionales del caso.

 Atender las necesidades del servicio alineados al UC.

Fuente: Elaboración Propia

2
EVALUACION FINANCIERA
A continuación se detalla la inversión a realizar en relación a la propuesta del servicio identificado en el proceso seleccionado. Para ello, se muestra el
flujo de efectivo por un periodo de 5 años, en el que se indica la inversión inicial y los ingresos/egresos por año.

FLUJO DE EFECTIVO

Figura 57 : Flujo de Efecto del Servicio propuesto

Fuente: Elaboración propia.

2
DIAGRAMAS DE PUNTO DE EQUILIBRIO
A continuación se visualiza el diagrama de punto de equilibrio de la propuesta del servicio
identificado en el proceso seleccionado. En el que se observa la recuperación de la inversión inicial
antes de cumplir el segundo año, concluyendo el quinto año con una ganancia acumulada de
$291,281.

Figura 58 : Flujo Acumulado del Servicio propuesto

Fuente: Elaboración propia

VAN

Tasa de Descuento del 10%

Con el flujo de efectivo antes indicado, menos la inversión inicial y con una tasa de descuento del
10% se obtiene Valos Actual Neto de $185,942, siendo la prouesta rentable.

2
TIR

Figura 59 : VAN y TIR del Servicio propuesto

Fuente: Elaboración Propia

Con el flujo de efectivo antes indicado, se obtiene la Tasa Interna de Retorno (TIR) del 62%, siendo
el porcentaje maximo a utilizar como tasa de descuenta donde el VAN no genera perdida.

SUSTENTO DE INGRESOS Y EGRESOS

Sustento de Egresos
A continuación se indica los despachos no realizados por no contar con la propuesta de servicio
identificada en el proceso seleccionado del objeto de estudio.

Figura 60 : Sustento de Egresos

Fuente: Elaboración Propia

2
Sustento de Egresos de Inversión
A continuación se sustenta los egresos de inversión y mensual relacionados al servicio propuesto.

EGRESOS DE INVERSION

Figura 61: Egresos de Inversión del Equipo AE

Fuente: Elaboración Propia

Figura 62: Egreso de Inversión del Equipo de Implementación

Fuente: Elaboración Propia

2
Figura 63: Sustento de Egreso Recursos ITIL

Fuente: Elaboración Propia

Figura 64: Egreso de Inversión del Consultor Basic de Infraestructura

Fuente: Elaboración Propia

2
Sustento de Egresos Mensual
A continuación se sustenta los egresos mensuales del servicio propuesto

Figura 65 : Egreso Mensual del Servicio de Soporte y Mantenimiento ERP SAP

Fuente: Elaboración Propia

Distribución de Egreso mensual por Soporte y Mantenimiento ERP SAP relacionado al servicio identificado :

Figura 66 : Distribución de Egreso mensual por Soporte y Mantenimiento ERP SAP


Servicio Identificado dentro del proceso
seleccionado:

Fuente: Elaboración Propia

Figura 67 : Sustento de Egreso Mensual del Servicio de Soporte ITIL

Fuente: Elaboración Propia

2
Distribución de Egreso mensual por Servicio de Soporte ITIL relacionado al servicio identificado:

Figura 68 : Distribución de Egreso mensual por Servicio de Soporte ITIL


Servicio Identificado dentro del proceso
seleccionado:

Fuente: Elaboración Propia

2
EVALUACION DE RIESGOS
A continua se visualiza la matriz de riesgos en la implementación del servicio identificado

Tabla 52: Lista de Riesgos relacionado a la implementación del servicio identificado


ID Riesgo Probabilidad Impacto Resultado Estrategia Respuesta (Mitigar Riesgo) Responsable de
Respuesta

RI01 Que no se cumplan los BAJA MUY IMPORTANTE Mitigar Constante entrenamiento Supervisor del
SLA ALTA documentar y las Servicio
realizadas. atenciones

RI02 Incumplimiento en la BAJA MUY IMPORTANTE Mitigar Evaluar al recurso que soporte Supervisor del
atención de alguna ALTA el servicio. Servicio
incidencia.
Capacitar al recurso de las
funcionalidades del servicio.

RI03 Falla Infraestructura / BAJA MUY IMPORTANTE Mitigar Contar con los contactos de Supervisor del
Comunicación ALTA infraestructura para alertar Servicio
alguna falla de infraestructura.

2
RI04 Demora en el tiempo de BAJA LEVE TOLERABLE Mitigar Revisar y proponer mejoras de Supervisor del
respuesta del servicio. performance del servicio Servicio /
Consultor ABAP

Fuente: Elaboración Propia

2
En el cuadro anterior se muestra una tabla con los riesgos identificados al servicio como
propuesta de implementación, así como su ponderación en función a la probabilidad e impacto,
la acción a seguir sobre los riesgos y la respuesta a los riesgos.

A continuación se visualiza la matriz probabilidad / impacto que se utilizo para ponderar los
riesgos del servicio identificados.

Figura 69: Matriz de Probabilidad / Impacto para ponderar el riesgo

Fuente: Elaboración Propia

2
DISEÑO DEL SERVICIO

REQUERIMIENTO DE NIVEL DE SERVICIO

Tabla 53: Ficha de Requerimientos de Nivel de Servicio SLR


Requerimientos de Nivel de Servicio (SLR)

Numero de SLR

SLR0000048511

Datos del Solicitante

Área: PLANEAMIENTO LOGISTICO

Responsable : Luis Mitsyu

Correo: luis.mitsyu@honda.com.pe

Teléfono : 994585238

Por favor, complete el siguiente cuestionario para poder identificar los requerimientos del negocio para brindar
continuidad, disponibilidad y rendimiento de los servicios ofrecidos.

Nombre del Servicio

Servicio de Planificación y Atención de Pedidos comerciales Pendientes

Descripción del Servicio

Servicio que permite planificar y atender todos aquellos pedidos comerciales que quedaron pendientes por falta de
stock.

Indique el horario en el cual desea tener disponible el servicio

Por cuánto tiempo puede estar “no disponible” el servicio antes de cualquier implicación contractual o regulatoria?

2
Indique los tiempos de respuesta que desea obtener después de registrar una solicitud, incidencia o problema del
servicio en el Sistema de Gestión de Tickets.

Nivel de prioridad Inmediata < a 5 horas < a 10 horas < a 30 horas

Urgente X

Alta X

Media X

Baja X

Indique que y como desea medir el rendimiento del servicio

Se desea medir el Tiempo de atención promedio de un pedido comercial pendiente.

Fecha de generación de Pedido pendiente – Fecha de atención Pedido pendiente <= 15 días

Indique como desea monitorear el servicio

Mediante reportes de Abastecimiento de pedidos comerciales pendientes

Fuente: Elaboración Propia

2
ACUERDO DE NIVEL DE SERVICIO
Tabla 54: Acuerdo de Nivel de Servicio SLA
Acuerdos de Nivel de Servicio (SLA)

Área TI

Responsable Jefe de TI

Correo de contacto fernando.cordoba@honda.com.pe

Nombre del Servicio Servicio de Planificación y Atención de Pedidos comerciales Pendientes

SLR asociado SLR0000048511

Tiempo de indisponibilidad Los 365 días, 24 * 7

Tiempos de respuesta
Nivel de Inmediata < a 9 horas < a 27 horas < a 45 horas
prioridad

Urgente X

Alta X

Media X

Baja X

Modo medición de servicio Tiempo de atención promedio de un pedido comercial pendiente.

Fecha de generación de Pedido pendiente – Fecha de atención Pedido pendiente <=


15 días

Monitoreo de servicio Reporte de Abastecimiento de pedidos comerciales pendientes

Fuente: Elaboración Propia

2
NIVEL DE SERVICIO OPERACIONAL
Tabla 55: Acuerdo de Nivel Operacional OLA
Acuerdos de Nivel Operacional (OLA)

Cliente Interno Área de TI de Honda Perú

Proveedor Interno TI

Vigencia Desde 2/01/2017 hasta que el cliente interno o proveedor desee modificarlo o sustituirlo.

Sistema/aplicativo Modulo Management Material SAP

Proveedor GMD

Descripción Sistema de Planificación de Ordenes Pendientes

Servidor IBM AIX 5.3-7.1

Plataforma/BD Linux

Responsabilidades Cumplir los procedimientos correspondientes de comunicación para reportar


Clientes Internos
incidentes. Conocer las políticas de uso de los recursos.

Responsabilidades TI Cumplir en los tiempos de respuesta requeridos en el nivel del servicio.

Realizar mantenimientos preventivos para garantizar la calidad del

servicio.

Realizar copias de seguridad a las base de datos para evitar perdida de información.
Compromisos

Nivel de Descripción Tiempo de respuesta (TAT)


prioridad

Urgente Indisponibilidad total o con Inmediata


consecuencias graves para la
operación del cliente interno.

2
Alta El servicio se encuentra severamente Máximo 9 horas laborables,
degradado causando un impacto a partir de la creación del
significativo en las operaciones y ticket.
productividad del cliente interno.

Media Las operaciones y productividad del Máximo 27 horas


cliente interno se ven levemente laborables, a partir de la
degradadas. Los problemas creación del ticket.
derivados del mantenimiento se
incluirán dentro de este nivel de
prioridad.

Baja Ni las operaciones ni la Máximo 45 horas


productividad del cliente interno se laborables, a partir de la
ven afectadas por el problema. Los creación del ticket.
requerimientos de modificaciones y
actualizaciones se incluirán dentro
de este nivel de prioridad.

Disponibilidad 99 %

Tiempo medio de El Área de TI se compromete a brindar un tiempo de restauración menor a 1 hora.


restauración

Mantenimiento El Área de TI se compromete a realizar trabajos de mantenimiento en el horario de 20:00


programado a 03:00 horas, notificando con 24 horas de anticipación a los clientes internos.

Punto de contacto Jefe de TI

Fuente: Elaboración Propia

2
CONTRATOS DE PROVEEDORES (UNDERPINNING CONTRACTS)
Tabla 56 : Contrato de soporte de Terceros UC
Contrato de Soporte de Terceros

Datos del Proveedor

 Razón Social: GMD S.A.

 Nro. R.U.C.: 20100153751

 Dirección: Av. Petit Thouars 4957

 Teléfono: 2136300

 Mail: info@gmd.com.pe

 Horario: L-V 09:00 a 18:00

Datos del Contacto

Datos del Contacto (1)

 Nombres y Apellidos: Ernesto guevara

 Cargo: Gerente de Delivery TI

 Correo Electrónico: ernesto.guevara@gmd.com.pe

Datos del Contacto (2)

 Nombres y Apellidos: Herber Miranda

 Cargo: Jefe de Servicios outsourcing TI

 Correo Electrónico: herber.miranda@gmd.com.pe

Servicio que brinda

Servicio de Soporte y Mantenimiento ERP SAP

Descripción del Servicio que brinda

Garantizar la disponibilidad y continuidad del ERP SAP.

2
Soporte que brinda

Soporte Funcional en los módulos del ERP SAP

Compromiso de Garantía

Luego de la solución brindada se realiza encuesta de satisfacción al usuario atendido.

Fuente: Elaboración Propia

2
TRANSICION DEL SERVICIO

REQUERIMIENTO DE CAMBIO
Tabla 57 : Requerimiento de Cambio RFC

<Nro Ticket> - < Descripcion Breve Solicitud de Cambio >

1.- INFORMACIÓN GENERAL

Alta Media Fecha


Solicitud de RQ
Tema Prioridad 01/03/2017
Mejora
Baja

Emergencia

Dueño
Sistema/Módulo MM del Jefe de Planeamiento Creador Fernando Córdoba
Proceso

Estado Analista
Transacción/Menú - Validación Requisitos Fernando Córdoba
RFC Honda

Clasificación

EspecificaciónFuncional SolicituddeCambio Incidente

Situación Actual Situación Deseada

2
Demoras en la atención de los pedidos comerciales Con la mejora planteada, el planificador tendrá la
pendientes (backorders). Actualmente, se verifica una capacidad de “emparejar” un pedido B/O con una
necesidad de mejora dentro del proceso de Gestión de o más fuentes de abastecimiento disponibles con
Planeamiento, debido a que se visualiza una constante el objetivo de garantizar la recuperación de la
demora en el abastecimiento de mercancías para la cantidad en B/O con eficiencia y en el menor
recuperación de los pedidos pendientes (B/O). Este problema tiempo posible.
es debido a que sólo se toma en cuenta con los stocks de los
Por otro lado, en la etapa de recepción de

2
almacenes locales. mercancías se planea “separar” la cantidad
máxima posible de stock durante la recepción de
Además, se verifica que durante la recepción de las
mercadería para ser destinados exclusivamente a
mercancías, éstas son enviadas directamente al stock libre
la recuperación de los pedidos pendientes.
local; por consiguiente estos productos pueden ser tomados
por cualquier nuevo pedido, lo cual no permite cubrir de
forma eficiente una adecuada recuperación de los pedidos
pendientes.

Objetivos: (Cómo impacta al Negocio)

Cualquier error en esta funcionalidad podría retrasar la entrega de los pedidos pendientes de atención

Descripción del Cambio

Escenarios de Pruebas

Se adjunta la documentación de las evidencias de los Escenarios de Pruebas en formato .ZIP

Plan de Despliegue

Actividad Responsable Hora Inicio Hora Fin

Depliegue de objetos TI 00:00 00:30

Validación de Objetos TI 00:30 01:00

Pruebas de calidad TI 01:00 04:00

Plan de Rollback

2
Actividad Responsable Hora Inicio Hora Fin

Despliegue de objetos TI 04:00 04:30

Validacion de Objetos TI 04:30 05:00

Pruebas de calidad TI 05:00 07:00

Aprobaciones

Responsable Comité de cambios : Cesar Ortega

Jefe de TI: Fernando Córdoba

Jefe de Planificación Comercial: Luis Mitsyu

Analista de Calidad: Michael Oyola

Fuente: Elaboración Propia

2
ELEMENTOS DE CONFIGURACION
A continuación se listan los Elementos de Configuración (CI) en Hardware y Software
relacionados al servicio identificado.

Listado de CI – Hardware
A continuación se listan los elementos de configuración – Hardware relacionado al servicio
identificado.

Tabla 58: Listado de CI’s – Hardware


ID Tipo de CI Descripción de CI Ubicación

CIH001 Servidor Servidor SAP IBM AIX 5.3 – 7.1 Honda Brasil

CIH002 Servidor Servidor SAP NetWeaver Portal Honda Brasil

CIH003 Servidor Servidor de Base de Datos Honda Brasil

Fuente: Elaboración Propia

Listado de CI – Software
A continuación se listan los elementos de configuración – Software relacionado al servicio
identificado.

Tabla 59: Listado de CI’s – Software


ID Tipo de CI Descripción de CI Relación con CI Ubicación
Hardware

CIS001 Aplicación ERP SAP v. 6 CIH001 Honda Brasil

CIH002

CIH003

Fuente: Elaboración Propia

2
PROCESOS ITIL
DESCRIPCION DEL PROCESO DE GESTION DEL PORTAFOLIO DE SERVICIOS
A continuación se muestra la propuesta del flujo del procesos de Gestión del Portafolio de Servicios.

Tabla 60: Proceso de Gestión de Portafolio de Servicios

Fuente: Elaboración Propia

2
Conceptos Fundamentales
A continuación se indican los conceptos fundamentales relacionados al proceso de Gestión de
Portafolio del Servicio.

Gestión del Portafolio del Servicio


Asegurar que el proveedor de servicio tiene la combinación correcta de servicios, balanceando la
inversión en TI con la habilidad de cumplir con los resultados del negocio.

Objetivos

 Implementar un proceso y mecanismo que desarrollen habilidades organizativas para


investigar y decidir sobre qué servicios proveer, basándose en un análisis del retorno
potencial y de un aceptable nivel de riesgo.

 Mantener el portafolio definitivo de los servicios, articulando las necesidades del negocio
que cada servicio debe cumplir y los resultados de negocio que soportan.

 Proveer a la organización de un mecanismo para evaluar como los servicios permiten lograr
la estrategia y responder a los cambios en el entorno interno y externo.

 Analizar cuáles servicios no son viables y cuando deben ser retirados.

Catálogo de Servicios
Es la parte de la cartera de servicios que pueden ver los clientes. El Catalogo de Servicio es una
herramienta estratégica esencial, ya que puede considerar como la proyección virtual de las
capacidades reales del proyecto de servicio.

2
Flujo de Creación de Servicios
Incluye todos los servicios que están en fase de estudio o desarrollo para un cliente o mercado
concreto. Estos servicios deben pasar a la fase de producción a través de la fase Transición de
Servicio. El flujo de creación representa el crecimiento y la anticipación estratégica de cara al
futuro.

Servicios Retirados
Son los servicios que la organización toma la decisión de retirar del portafolio de servicio. Esto
no quiere decir que se eliminan, sino que se cambian de estado, ya que puede ser posible que el
negocio vuelva a solicitar su activación.

Ficha de Alcance de Servicio


En la ficha de alcance del servicio se registra todas las necesidades que deben cubrir el servicio y
el funcionamiento del mismo. Además, se indican datos de propietario y personas de contacto.

2
Descripción del Proceso
A continuación se detalla las actividades relacionadas al proceso propuesto de Gestión de
Portafolio de Servicios.

1. Recepcionar Solicitud de
Servicio Promotor Comercial

1. El promotor comercial recepciona y recopila las necesidades del cliente, elaborando la


Ficha del alcance del servicio con información relevante al nuevo servicio o modificación
de alguno ya existente en el Portafolio de Servicio, se continuara con la tarea descrita en el
punto 2.

2. Validar Ficha de Alcance de


Servicio Gestor de Portafolio

2. El gestor de portafolio de servicio valida la ficha de alcance de servicio, ya que debe


contar con información mínima requerida para solicitar algún nuevo servicio, actualizar o
dar de baja algún servicio existente en el portafolio de servicio. De acuerdo a la solicitud,
se evalúa la información mínima requerida. Si la validación es satisfactoria, se continuara
con la tarea descrita en el punto 5; en caso contrario, se continuara con la tarea descrita en
el punto 3.

3. Observar Ficha de Alcance del


Servicio Gestor de Portafolio

3. El gestor de portafolio de servicios, en base al tipo de solicitud se identifica la


información faltante en la ficha de alcance de servicio, indicando el motivo del mismo en
la ficha de alcance de servicio, se continuara con la tarea descrita en el punto 4.

4. Corregir Observaciones de Ficha de Alcance del Servicio


Promotor Comercial

2
4. El promotor comercial levantar las observaciones indicadas en la ficha de alcance de
servicio y las vuelve a enviar al gestor de portafolio para su validación, se continuara con
la tarea descrita en el punto 5.

5. Actualizar Ficha de Alcance de


Servicio Gestor de Portafolio

5. El gestor de portafolio de servicios, en base al alcance del servicio indicado por el


promotor comercial actualiza la ficha de alcance de servicio con información relevante a
lo solicitado, se continuara con la tarea descrita en el punto 6.

6. Identificar los Riesgos del


Servicio Gestor de Portafolio

6. El gestor de portafolio de servicios, con la ficha de alcance del servicio actualizada se


realizar la Matriz de Riesgos para identificar los impactos positivos y negativos de la
necesidad requerida. Esto quiere decir: Si solicitan dar de baja un servicio, este puede
estar relacionado otros servicios ocasionando un impacto negativo, como que también el
nuevo servicio a implementar impacte positivamente en los demás servicios ya registrados
en el portafolio de servicios, se continuara con la tarea descrita en el punto 7,

7. Evaluar Factibilidad del Servicio


Jefe de Sistemas

7. El jefe de sistemas, con la ficha de alcance de servicio y la matriz de riesgo evalúa la


factibilidad técnica del servicio a implementar o actualizar. Si la evaluación es
satisfactoria, se continuara con la tarea descrita en el punto 8; en caso contrario, se
terminara el proceso.

8. Evaluar Factibilidad Financiera del


Servicio Supervisor Financiero

2
8. El supervisor financiero evalúa la factibilidad financiera de la necesidad solicitada de
acuerdo a lo indicado en la ficha de alcance del servicio, generando el documento de flujo
de caja proyectado en el que se registra los ingresos y egresos relacionados a la necesidad
del cliente, si la validación es satisfactoria, se continuara con la tarea descrita en el punto
9; en caso contrario, se termina el proceso.

9. Aprobar
Servicio Gestor de
Portafolio

9. El gestor de portafolio procede a aprobar la ficha de alcance del servicio, se continuara


con la tarea descrita en el punto 10.

10. Registrar RFC


Gestor de Portafolio

10. El gestor de portafolio realiza el registro formal para la implementación de un nuevo


servicio, la actualización o baja de algún servicio del portafolio del servicio, se continuara
con la tarea descrita en el punto 11.

11. Actualizar Portafolio de Servicios


Gestor de Portafolio

11. El gestor de portafolio, con el registro de RFC actualiza el portafolio de servicio indicando
el estado y la fase en el que se encuentra el servicio, se termina el proceso.

2
Matriz RACI de Roles y Responsabilidades
La siguiente tabla presenta el papel o nivel de responsabilidad que cada uno de los roles
definidos desempeña en cada una de las actividades que se realizan en el proceso de “Gestión de
Portafolio de Servicios”.

Tabla 61: Matriz RACI Gestión de Portafolio de Servicios


ROLES

Supervisor Financiero
Gestor de Portafolio
Promotor Comercial

Jefe de Sistemas
ACTIVIDADES

Recepcionar Solicitud de Servicio A/R C

Validar Ficha de Alcance de Servicio A/R

Observar Ficha de Alcance del Servicio A/R

Corregir Observaciones de Ficha de Alcance del Servicio A/R

Actualizar Ficha de Alcance de Servicio A/R C

Identificar los Riesgos del Servicio A/R C

Evaluar Factibilidad del Servicio A/R

Evaluar Factibilidad Financiera del Servicio A/R

Aprobar Servicio A/R C

Registrar RFC A/R C

Actualizar Portafolio de Servicios A/R C

R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO ANTES DE HACER
I: INFORMADO DESPUES DE HACER

Fuente: Elaboración Propia

2
Métricas
A continuación se indican los KPI’s relacionados al proceso de “Gestión del Portafolio del
Servicio”.

Tabla 62 : Métricas del Proceso de Gestión del Portafolio


KPI Descripción

Cantidad de nuevos servicios planeados Porcentaje de nuevos servicios desarrollados a


iniciativa de la Gestión del Portafolio de
Servicios

Cantidad de nuevos servicios no planeados Porcentaje de nuevos servicios desarrollados


sin la iniciativa de la Gestión del Portafolio de
Servicios

Cantidad de iniciativas estratégicas Cantidad de iniciativas estratégicas lanzadas


por el proceso de la Gestión del Portafolio de
Servicios

Cantidad de clientes nuevos Cantidad de clientes nuevos adquiridos

Cantidad de clientes perdidos Cantidad de clientes perdidos a competidores


que proveen servicios

Fuente: Elaboración Propia

2
Ficha de Lista de Servicios
Tabla 63: Ficha de Listado de Servicios
Código Servicio Versión Descripción Tipo Propietario Prioridad

SINT0001 Servicio de 01 Planificar el Interno Área de ALTA


Planificación de abastecimiento de los Importación
Pedidos pedidos comerciales
Comerciales pendiente de atención,
Pendientes mediante 6 fuentes de
abastecimiento.

SEXT0001 Servicio de 01 Brindar el soporte Externo Área de MEDIA


Soporte y necesario para garantizar la Importación
Mantenimiento disponibilidad y
ERP SAP continuidad del servicio.

Fuente: Elaboración Propia

Ficha de Servicio
Tabla 64: Ficha de Servicio
[Código de Servicio] Versión : <Nro >

Nombre del Servicio

Descripción <Descripción del Servicio>

Tipo <Tipo de Servicio> Categoría < Categoría Servicio >

[Interno] [Externo] [Soporte]

Servicios de Soporte < Listado de Servicios de Soporte Prestados por Terceros Empresas necesarios para prestar el
servicio >

2
Propietario < Responsable del Servicio >

Unidad de Negocio < Unidad de Negocio a quien se le da el Servicio >

Impacto < Descripción de Impacto por si no Prioridad < Prioridad del Servicio >
está disponible el servicio >
[ALTA] [MEDIO] [BAJO]

SLA < Enlace del Documento de SLA > Horas de Servicio < Tiempo de disponibilidad
del servicio >

Contacto < Listado de todos los contactos relacionados al servicio>

[Nombre Completo] [Cargo] [Teléfono] [Mail]

[Nombre Completo] [Cargo] [Teléfono] [Mail]

[Nombre Completo] [Cargo] [Teléfono] [Mail]

Fuente: Elaboración Propia

2
Ficha de Requerimiento del Servicio
Tabla 65: Ficha de Requerimiento de Servicio
[RQ-Código de Servicio] Versión : <Nro>

Nombre del Servicio

Proceso(s) de Negocio(s) < Listado de procesos de negocio afectados >

Propietario < Responsable del Servicio > Tipo <Tipo de Servicio>

[Interno] [Externo] [Soporte]

Alcances < Detalla los Alcances del Servicio >

Objetivos < Listado de Objetivos del Servicio >

Objetivos Estratégicos <Listado de Objetivos Estratégicos del Negocio a quien hace referencia el Servicio >

Funcionalidad / < Listado de Funcionalidades del Servicio >


Requerimiento

Fuente: Elaboración Propia

2
DESCRIPCION DEL PROCESO DE GESTION DEL NIVEL DEL SERVICIO
A CONTINUACION SE MUESTRA LA PROPUESTA DEL FLUJO DEL PROCESO DE GESTION DEL NIVEL DEL SERVICIO.

Tabla 66: Proceso de Gestión de Nivel de Servicio

Fuente: Elaboración Propia

2
Conceptos Fundamentales

SLA (Service Level Agreement)


Un Acuerdo de Nivel de Servicio es un contrato escrito entre un proveedor de servicio de TI y su
cliente con el objeto de fijar niveles de calidad de los servicios acordados.

SLR (Service Level Request)


Un Requisito de Nivel de Servicio es un documento que recoge la información detallada de las
necesidades del cliente y sus expectativas de rendimiento y nivel de servicios.

OLA (Operational Level Agreement)


Un Acuerdo de Nivel Operacional es un documento interno de la organización donde se
especifican las responsabilidades y compromisos de los diferentes departamentos de la
organización de TI en la prestación de un determinado servicio.

UC (Underpinning Contract)
Un Contrato de Soporte es un acuerdo con un proveedor externo para la prestación de servicios
no cubiertos por la propia organización de TI.

Proveedor
Proveedor de servicios de TI que forma parte de una organización diferente a la de su cliente. Un
proveedor de servicios de TI puede tener al mismo tiempo clientes internos y clientes externos.

2
Registro
Documento que contiene los resultados u otras salidas de un proceso o actividad. Los registros
constituyen evidencias del hecho de que una actividad tuvo lugar y pueden estar en soporte de
papel o electrónico. Por ejemplo, un Informe de una Auditoría, un Registro de un incidente, o el
Acta de Reunión.

SIP
Por sus siglas en inglés Service Improvement Program (Programa de Mejora de Servicio). Plan
formal para implementar mejoras en un Proceso o en Servicio de TI.

Descripción del Proceso


1. Determinar/Actualizar requerimientos del nivel de servicio

Usuario de Negocio
1. El usuario de negocio determina los requerimientos de nivel del servicio para los servicios
nuevos. Si se trata de un servicio actualizado, se actualizar los requerimientos del nivel de
servicio, se continuara con la tarea descrita en el punto 2

2. Validar existencia de terceros

Gestor de nivel de Servicio


2. El gestor de nivel de servicio valida la existencia de proveedores externos a la
organización que dan soporte al servicio de negocio. Si hay proveedores externos, se
continuara con la tarea descrita en el punto 3; caso contrario, se continuara con la tarea
descrita en el punto 4

3. Identificar UCs

Gestor de nivel de Servicio

2
3. El gestor de nivel de servicio identifica los contratos con terceros para validar los
acuerdos de nivel de los servicios que proporcionan los proveedores externos. Se
continuara con la tarea descrita en el punto 4.

4. Definir /Actualizar

OLA Gestor de nivel de

Servicio
4. El gestor de nivel de servicio define lo acuerdos de nivel operacional (OLA) para aquellos
servicios de soporte brindados por áreas internas a la empresa. Se continúa con la tarea
descrita en el punto 5.

5. Validar factibilidad SLR

Gestor de nivel de Servicio


5. El gestor de nivel de servicio, valida que los requerimientos de nivel de servicio sean
consistentes y factibles de implementarse. Si el SLR es factible, se continua con la tarea
descrita en el punto 6; caso contrario, se continua en el punto 7

6. Establecer /Actualizar acuerdos

requeridos Gestor de nivel de Servicio


6. Se establece, documenta y/o actualiza los acuerdos de nivel de servicio (SLAs). Se
continúa con la tarea descrita en el punto 8.

7. Rechaza SLR

Gestor de nivel de Servicio


7. El gestor de nivel de servicio rechaza SLR luego de analizarlo y verificar que no es
factible su implementación. Se continúa con la tarea descrita en el punto 11.

2
8. Solicitar aprobación SLA

2
Gestor de nivel de Servicio
8. El gestor de nivel de servicio solicita las aprobaciones correspondientes de SLA al Jefe de
TI y al Usuario de Negocio dueño del servicio. Se continúa con la tarea descrita en el
punto 9.

9. Validar si SLA es aprobado

Gestor de nivel de Servicio


9. El gestor de nivel de servicio valida si el SLA cuenta con todas las aprobaciones
requeridas. Si cuenta con todas las aprobaciones requeridas, se continúa con la tarea
descrita en el punto 10; caso contrario, se continúa con la tarea descrita en el punto 4.

10. Comunicar Acuerdos a interesados

Gestor de nivel de Servicio


10. El gestor de nivel de servicio comunicar los Acuerdos de nivel de servicio (SLA) a todos
los interesados y finaliza el proceso.

11. Revisar impedimentos SLR

Usuario de Negocio
11. El usuario de negocio revisar los impedimentos de los requisitos de nivel de servicio y
propone ajustes. Se continúa con la tarea descrita en el punto 1.

12. Aprobar SLA

Jefe de TI
12. El jefe de TI revisa y aprueba el SLA. Se continúa con la tarea descrita en el punto 9.

Usuario de Negocio
12. El Usuario de negocio revisa y aprueba el SLA. Se continúa con la tarea descrita en el punto
9.

2
Matriz RACI de Roles y Responsabilidades
La siguiente tabla presenta el papel o nivel de responsabilidad que cada uno de los roles
definidos desempeña en cada una de las actividades que se realizan en el proceso de Gestión del
Nivel del Servicio.

Con la finalidad de crear un conjunto de roles flexible y adaptable al proceso de gestión de


cambios de cualquier organización, se han definido roles muy específicos. En la implementación
real del proceso en La Entidad, una persona puede desempeñar varios de estos roles, siempre y
cuando dichos roles no sean incompatibles entre sí.

Tabla 67: Matriz RACI Gestión del Nivel de Servicio


ROLES
Gestor de Nivel de Servicio

(Stakeholders)

Jefe de TI
ACTIVIDADES

Determinar/Actualizar requerimientos del nivel de servicio I R

Validar existencia de terceros R/A C

Identificar UCs R/A

Definir /Actualizar OLA R/A C

Validar factibillidad SLR R/A

Rechaza SLR R/A I

Establecer /Actualizar acuerdos requeridos R/A

Solicitar aprobacion SLA R/A

Validar si SLA es aprobado R/A

Comunicar Acuerdos a interesados R/A I I

Revisar impedimentos SLR C R C

2
ROLES

Gestor de Nivel de Servicio

(Stakeholders)

Jefe de TI
ACTIVIDADES

Aprobar SLA R R

R: RESPONSABLE DE EJECUCION

A: AUTORIDAD

C: CONSULTADO ANTES DE HACER

I: INFORMADO DESPUES DE HACER

Fuente: Elaboración Propia

Descripción de Roles y Responsabilidades

Gestor de Nivel de Servicio


Es responsable de la operación del proceso de Gestión de nivel de servicios. Asegura la
factibilidad de los requisitos de nivel de servicio y tiene como responsabilidad velar por que los
acuerdos de niveles de servicio estén alineados a los acuerdos de nivel operacional y los
acuerdos con terceros.

Usuario de Negocio
Se refiere a cualquier usuario de negocio dentro de la organización, quien puede determinar los
requisitos de nivel de servicio y es el principal interesado en la negociación de los objetivos de
niveles de servicio

Jefe de TI

2
Es el responsable del área de tecnología de la información. Él es quien aprueba los SLAs desde
el punto de vista de TI.

Métricas
Tabla 68: Métricas del Proceso de Gestión de Nivel de Servicio
KPI DESCRIPCION

Servicios cubiertos por los SLA’s Cantidad de servicios cubiertos por los SLA’s

Servicios cubiertos por los OLA’s/UC’s Cantidad de servicios donde los SLA’s están apoyados
por OLA’s/ UC’s

SLA’s monitorizados Cantidad de servicios/ SLA’s monitorizados que


reportan puntos débiles y contra medidas

SLA’s bajo revisión Cantidad de servicios/ SLA’s revisados regularmente

Cumplimiento de niveles de servicio Cantidad de servicios/ SLA’s que cumplen con los
niveles de servicio acordados

Cantidad de asuntos de Servicio Porcentaje de reservas de capacidad en tiempos de


demanda normal y máxima

Porcentaje de monitorización de capacidad Cantidad de asuntos, al proveer servicios, que son


identificados y tratados en un Plan de Mejoras al
Servicio (SIP)

Fuente: Elaboración Propia

2
Fichas de Nivel de Servicio

Tabla 69: de Requerimiento de Nivel de Servicio SLR


Requerimientos de Nivel de Servicio (SLR)

Solicitante

Área:

Responsable :

Correo:

Teléfono :

Por favor, complete el siguiente cuestionario para poder identificar los requerimientos del negocio para brindar
continuidad, disponibilidad y rendimiento de los servicios ofrecidos.

Datos del Solicitante

Nombre del Servicio

Descripción del Servicio

Indique el horario en el cual desea tener disponible el servicio

Por cuánto tiempo puede estar “no disponible” el servicio antes de cualquier implicación contractual o regulatoria?

Indique los tiempos de respuesta que desea obtener después de registrar una solicitud, incidencia o problema del
servicio en el Sistema de Gestión de Tickets.

2
Nivel de prioridad Inmediata < a 5 horas < a 10 horas < a 30 horas

Urgente

Alta

Media

Baja

Indique que y como desea medir el rendimiento del servicio

Indique como desea monitorear el servicio

Fuente: Elaboración Propia

2
Ficha de Nivel de Servicio (SLA)
Tabla 70: Ficha de Acuerdo de Nivel de Servicio SLA/ Fuente: Elaboración Propia

Acuerdos de Nivel de Servicio (SLA)

Área

Responsable

Correo de contacto

Nombre del Servicio

SLR asociado

Disponibilidad

Tiempo medio de
restauración

Compromisos de tiempos de
Nivel de Inmediata < a 9 horas < a 27 < a 45
respuesta para atención de
prioridad horas horas
errores

Urgente

Alta

Media

Baja

Limitaciones

Exclusiones

Modo medición de servicio

Monitoreo de servicio

2
Ficha de Acuerso de Nivel Operacional (OLA)
Tabla 71: Ficha de Acuerdo de Nivel Operacional OLA

Acuerdos de Nivel Operacional (OLA)

Cliente Interno

Proveedor Interno

Vigencia

Sistema/aplicativo

Proveedor

Descripción

Servidor

Plataforma/BD

Responsabilidades
Clientes Internos

Responsabilidades TI

Compromisos

Nivel de Descripción Tiempo de respuesta


prioridad (TAT)

Urgente

Alta

Media

Baja

2
Disponibilidad

Tiempo medio de
restauración

Mantenimiento
programado

Punto de contacto

Fuente: Elaboración Propia

2
Ficha de Contrato de Soporte de Tercero
Tabla 72:Ficha de Contrato con Terceros UC
Contrato de Soporte de Terceros

Datos del Proveedor

Razón Social:

Nro. R.U.C.:

Dirección:

Teléfono:

Horario: L-V 09:00 a 18:00

Datos del Contacto

Datos del Contacto (1)

Nombres y Apellidos:

Cargo:

Correo Electrónico:

Datos del Contacto (2)

Nombres y Apellidos:

Cargo:

Correo Electrónico:

Servicio que brinda

Descripción del Servicio que brinda

Soporte que brinda

2
Compromiso de Garantía

Fuente: Elaboración Propia

2
DESCRIPCION DEL PROCESO GESTION DE CAMBIOS
A continuación se muestra la propuesta del flujo del proceso de Gestión de Cambio.

Figura 70 : Proceso de gestión de cambios

Fuente: Elaboración Propia

2
Conceptos Fundamentales

Solicitud de cambio
Solicitud formal para la implementación de un cambio, también conocido como RFC por sus
siglas en ingles (Requirement for change). Es el medio para proponer un cambio en cualquier
componente de una Infraestructura TI o en cualquier aspecto de un Servicio TI.

Puede ser un documento o un registro donde se introduzcan la naturaleza y detalles, y la


justificación y autorización del cambio propuesto.

Incidencia
Cualquier evento que no forma parte de la operación estándar de un servicio y que causa o puede
causar una interrupción o una reducción de calidad del mismo.

Problema
Causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de
importancia significativa.

CAB (Change Advisor Board)


Órgano interno compuesto por representantes del área de TI, la organización, y en algunos casos,
también proveedores estratégicos. El CAB se encarga de aprobar / rechazar una solicitud de
cambio, previa evaluación, priorización y programación de los mismos.

2
ECAB (Emergency Change Advisor Board)
Órgano interno que toma decisiones relacionadas con cambios de emergencia cuyo impacto es
significativo (naturaleza / urgencia).

Descripción del Proceso

1. Solicitar Cambio
Promotor de cambio

1. Solicita el cambio para un servicio TI, esta solicitud puede provenir de:
Un área técnica de la Entidad

El Service Desk

Un equipo de proyecto de Infraestructuras

La División de Desarrollo

Los responsables de canalizar las necesidades de los Clientes

2. Validar Urgencia de cambio


Gestor de Cambios

2. Valida urgencia del cambio, si RFC es un cambio de emergencia, se solicita aprobación


del cambio al Responsable del proceso de cambios requisitos del RFC, se continuara con
la tarea descrita en el paso 8; caso contrario se continuara con la tarea descrita en el punto
3

3. Validar requisitos y alcances del


RFC Gestor de Cambios

2
3. Si RFC cumple con todos los requisitos, se continuara con la tarea descrita en el punto
5.2; caso contrario, se observa RFC para que el Promotor del cambio proceda a corregir
las observaciones, se continuara con la tarea descrita en el punto 5.1

4. Evaluar RFC en CAB


CAB (Comité de cambios)

4. EL comité de cambios evalúa a todos aquellos RFCs en estado “Aprobado Validación


Requisitos”. Se evalúa posibles impactos al negocio, cruces de elementos de
configuración con otros cambios; además, re valida que la solicitud contenga todos los
requisitos como aprobaciones, plan de despliegue, responsables de calidad, pruebas
unitarias, etc. Si el RFC no posee observaciones, este es aprobado, se continuara con la
tarea descrita en el punto 5.4; caso contrario, se continuara con la tarea descrita en el
punto 5.3

5. Actualizar estado
RFC Gestor de Cambios
5.1. Si RFC fue observado en el paso 3.1, se actualiza el estado de la solicitud a “Observado
Validación Requisitos” , se continuara con la tarea descrita en el punto 6
5.2. Si RFC fue aprobado en el paso 3.1, se actualiza el estado de la solicitud a “Aprobado
Validación Requisitos” , se continuara con la tarea descrita en el punto 4
5.3. Si RFC fue observado en el paso 4.1, se actualiza el estado de la solicitud a “Observado
Validación CAB”, se continuara con la tarea descrita en el punto 6
5.4. Si RFC fue aprobado en el paso 4.1, se actualiza el estado de la solicitud a “Aprobado
Validación CAB” , se continuara con la tarea descrita en el punto 7
5.5. Si RFC fue observado en el paso 8.1, se actualiza el estado de la solicitud a “Observado
RFC Emergente”, se continuara con la tarea descrita en el punto 6
5.6. Si RFC fue aprobado en el paso 8.1, se actualiza el estado de la solicitud a “Aprobado
RFC Emergente” , se continuara con la tarea descrita en el punto 7

6. Corregir Observaciones
Promotor de cambio

2
5. Si el RFC es observado en alguna de las fases dentro del proceso de Gestión de Cambio,
el Promotor debe de corregir las observaciones cuanto antes para continuar con el proceso;
caso contrario el RFC podría retrasarse y llegar a evaluación CAB en una siguiente
iteración. Si estas observaciones son corregidas y comunicadas al Gestor de cambios a
tiempo, el RFC podría ingresar al CAB de la semana en curso; caso contrario serán
evaluadas en la siguiente iteración, siempre y cuando no posea más observaciones, se
continuara con la tarea descrita en el punto 2

7. Actualizar Cronograma de
cambios Gestor de cambios

6. Se actualiza el cronograma de cambios a promoverse a producción con los RFCs cuyo


estado es “Aprobado Validación CAB”, se continuara con la tarea descrita en el punto 9.

8. Validar RFC de Emergencia


Responsable del proceso de Cambios

7. Consulta evaluación realizada por el gestor de cambios y analiza los impactos en el


negocio. Si el RFC no posee observaciones, este es aprobado, se continuara con la tarea
descrita en el punto 5.6; caso contrario, se continuara con la tarea descrita en el punto 5.5

9. Solicitar Despliegue HW/SW


Gestor de cambios

8. Solicita Despliegue de SW/HW a Proceso de Gestión Entrega y Despliegue, proceso


continúa en el punto 10.

10. Validar Estado de


despliegue Gestor de cambios

2
9. Recibe estado del despliegue del Proceso de Gestión Entrega y Despliegue y valida el
estado. Si el estado es satisfactorio cierra el RFC en estado “Cerrado Satisfactoriamente”;
caso contrario, se continuara con la tarea descrita en el punto 11

11. Solicitar Rollback


Gestor de cambios
11.1. Solicitar rollback a Gestión Entrega y Despliegue
11.2. Actualizar el estado del RFC Rollback y cerrar “Cerrado Rollback”

Matriz RACI de Roles y Responsabilidades


La siguiente tabla presenta el papel o nivel de responsabilidad que cada uno de los roles
definidos desempeña en cada una de las actividades que se realizan en el proceso de Gestión de
Cambios.

Con la finalidad de crear un conjunto de roles flexible y adaptable al proceso de gestión de


cambios de cualquier organización, se han definido roles muy específicos. En la implementación
real del proceso en La Entidad, una persona puede desempeñar varios de estos roles, siempre y
cuando dichos roles no sean incompatibles entre sí.

Figura 71:Matriz RACI Gestión de Cambios


Responsable de Gestión de Cambios

Gestor de cambios (Coordinador)

ROLES
Promotor del cambio
Comite de Cambios

ACTIVIDADES

Solicitar Cambio I I R

Validar urgencia del Cambio A/R R

Validar Requisitos y Alcances del RFC A/R R C

2
Responsable de Gestión de Cambios

Gestor de cambios (Coordinador)


ROLES

Promotor del cambio


Comite de Cambios
ACTIVIDADES

Evaluar RFC en CAB A/R C/I R C/I

Actualizar estado RFC A/R R I I

Corregir observaciones I I R

Actualizar cronograma de cambios A/R R

Validar RFC de Emergencia A/R C/I I

Solicitar despliegue HW/SW A/R R C/I

Validar estado de Despliegue A/R R I

Solicitar Rollback A/R R C/I

R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO ANTES DE HACER
I: INFORMADO DESPUES DE HACER

Fuente: Elaboración Propia

Descripción de Roles y Responsabilidades


Los roles que intervienen en el proceso de Gestión de Cambios son los siguientes:

Promotor del Cambio


Iniciador y peticionario del cambio a partir de una necesidad.

2
Detecta la necesidad de cambio en su ámbito de responsabilidad (en su caso, a partir de
necesidades de Clientes y/o Usuarios). Consecuentemente remite RFC al proceso de Gestión de
Cambios.

Podrá ser:

 Un área técnica de la Entidad: lanzará RFCs a Gestión de Cambios desde los procesos de
Gestión de Servicios TI y/o Gestión de Infraestructuras TIC donde se detecte la necesidad de
cambio (incidencias, problemas, mejoras proactivas).

 El Service Desk, a partir de una petición de Usuario: el Usuario comunicará la necesidad de


cambio al Service Desk; consecuentemente se lanzará la RFC desde el proceso de Gestión de
Contactos al proceso de Gestión de Cambios.

 Un equipo de proyecto de Infraestructuras: que lanzará RFCs a Gestión de Cambios desde el


proceso de Despliegue de Gestión de Infraestructuras TIC.

 La División de Desarrollo: que remitirá RFCs al proceso de Gestión de Cambios para


“desplegar” una nueva aplicación, un evolutivo o un correctivo (ciclo de vida de Gestión de
Aplicaciones).

 Los responsables de canalizar las necesidades de los Clientes: el Cliente canalizará sus
requerimientos a través de Gestión de Niveles de Servicio y/o Diseño y Planificación de
Gestión de Infraestructuras TIC; consecuentemente, en el caso de necesidad de un cambio, se
lanzará RFC desde estos procesos al proceso de Gestión de Cambios.

Responsable del Proceso de Gestión de Cambios


Es el titular del proceso. Es el responsable de su definición, implantación y control a través de las
diversas organizaciones o departamentos involucrados. Es también responsable de la mejora
continua del proceso.

Trabaja en función de los objetivos generales acordados con el Responsable de los Servicios TI
(Dirección de Explotación o figura de mando delegada).

2
Se le debe asignar la autoridad suficiente sobre los agentes del proceso (recursos humanos y
materiales) para que este se desarrolle según los criterios y procedimientos establecidos,
independientemente de la localización de aquellos en la estructura jerárquica de la organización.

Gestor de Cambios (Coordinador)


Es responsable de la operación del proceso de Gestión de Cambios. Asesora y apoya al titular del
proceso, colaborando en las funciones sobre las que este le delegue autoridad, asegurando que se
cumplen los acuerdos de niveles de servicio, y velando por la coordinación en el tratamiento de
los cambios.

Comité de Cambios (CAB)


El Comité de Cambios (Change Advisory Board) es el grupo representativo, con autoridad y
competencia experta en la Gestión de Cambios, que puede valorar y aconsejar la implementación
de los cambios, desde los puntos de vista técnicos y de negocio.

Habitualmente el Comité de Cambios será requerido para la valoración de cambios de alto


impacto.

El Comité de Cambios estará presidido por el Responsable de Gestión de Cambios, que convoca
y lidera dicho Comité. A fin de asegurarse una representación adecuada, dependiendo de la
naturaleza de los cambios considerados y según criterio del Responsable de Gestión de Cambios,
entre los miembros del Comité deberían estar incluidos representantes de las siguientes áreas:

 Representantes de todas las áreas importantes de los procesos de Gestión de Servicios TI y


Gestión de Infraestructuras TIC

 Clientes afectados por el cambio

 Usuarios importantes, o sus representantes

 Los grupos de desarrollo y mantenimiento de aplicaciones

 Representantes de las áreas de negocio

2
Convocatoria del Comité de Cambios:

Si se constituye un Comité de Cambios, se necesitará disponer de términos de referencia


apropiados, por ejemplo, regularidad de las reuniones, campo de influencia, vínculos con la
gestión de un programa/proyecto,...

No debería ser necesario insistir en reuniones cara a cara; muchos de los flujos de notificación
entre procesos pueden desarrollarse por medios electrónicos, herramientas web, reuniones vía
telefónica o e-mail. Sólo en los casos muy complejos, de alto riesgo o alto impacto, será
necesaria una reunión formal del Comité de Cambios. De todos modos, es una buena idea
programar reuniones regulares – cada cierto número de meses, o cuando algún proyecto
importante esté a punto de producir resultados. Las reuniones pueden utilizarse para realizar una
revisión formal y dar por terminados los cambios aprobados, una revisión de los cambios más
importantes y, por supuesto, para discutir cualquier cambio importante que se avecine. Cuando sí
resulten apropiadas las reuniones, deberían tener una agenda estándar.

Agenda estándar de un Comité de Cambios:

 Revisión de las Peticiones de Cambio pendientes:

 RFCs a evaluar por los miembros del Comité de Cambios.

 Discusión y consenso de RFCs analizadas por los miembros del Comité de Cambios
previamente a la reunión.

Aprobación de RFCS.

 Revisión de los cambios realizados desde la última reunión:

 Revisiones de cambios: generales y puntuales.

 Revisión de cambios fallidos, cambios deshechos mediante una regresión, o cambios


aplicados sin referencia al Comité de Cambios por parte de Gestión de Incidencias, Gestión
de Problemas o Gestión de Cambios.

2
Evaluación de la eficacia y eficiencia del proceso de Gestión de Cambios:

 Revisión de ajustes al proceso realizados durante el periodo que se revisa, así como los
cambios propuestos.

 Logros y frutos de la Gestión de Cambios durante el periodo que se analiza, por ejemplo una
revisión de las ventajas conseguidas para el negocio por medio del proceso de Gestión de
Cambios.

Propuestas de mejora.

 Se recomienda distribuir a los participantes la agenda de la reunión y un resumen de las


peticiones pendientes con anterioridad a la reunión. Téngase en cuenta que el Comité de
Cambios es únicamente un cuerpo consultivo. Si el Comité de Cambios no puede ponerse de
acuerdo sobre una recomendación, la decisión final sobre si autorizar los cambios y asumir
los costes implicados, es responsabilidad del mando (normalmente el Director de TI, o el
Responsable de los Servicios TI, o el Responsable de la Gestión de Cambios, como sus
representantes asignados).

Métricas Claves asociadas a los Factores Críticos de Éxito (FCEs)


Controladas mediante Indicadores Claves del Rendimiento (KPIs), que aportarán la información
necesaria para que el Responsable del proceso de Gestión de Cambios pueda determinar la
calidad global del proceso.

Los factores críticos de éxito (FCE) también llamados ‘de fracaso’ es un conjunto de factores
cuyo desempeño correcto es crítico para el buen funcionamiento del proceso. Con la finalidad de
controlar dichos factores se hace necesario medir estos factores se define un conjunto de KPIs.
Para cada FCE, se enumeran a continuación sus correspondientes KPIs:

FCE: Consolidación del proceso de cambios:

 Porcentaje de disminución de rechazos de solicitudes de cambio.

2
 Porcentaje de solicitudes de Cambio (necesidades del negocio) efectuadas a tiempo.

 Porcentaje de reducción de retrasos en Cambios.

 Disminución del porcentaje de 'vueltas a atrás' debido a fallos en las pruebas.

 Porcentaje de reducción en Cambios requeridos por fracasos de cambios anteriores.

 Porcentaje de informes producidos a tiempo.

FCE: Eficacia y exactitud de los cambios:

 Porcentaje de reducción del número de Cambios urgentes.

 Porcentaje de reducción de Cambios urgentes que provocan incidencias.

 Reducción en el porcentaje de Cambios llevado a cabo sin ser probados.

 Porcentaje de reducción de Cambios urgentes que requieren marcha atrás'.

 Porcentaje de reducción Cambios de alta prioridad o urgentes llevados a cabo sin "bussines
case" que justifiquen esta decisión.

2
Ficha de Solicitud de cambio (RFC)
Figura 72: Ficha de Requerimiento de Cambio RFC

<Nro Ticket> - < Descripcion Breve Solicitud de Cambio >

1.- INFORMACIÓN GENERAL

Alta Media Baja Fecha RQ


Tema Prioridad
Emergencia

Dueño del <nombre responsable del


Sistema/Módulo MM Creador
Proceso proceso>

Estado Analista
Transacción/Menú -
RFC Honda

Clasificación

EspecificaciónFuncional SolicituddeCambio Incidente

Situación Actual Situación Deseada

Objetivos: (Cómo impacta al Negocio)

Descripción técnica del Cambio

2
Escenarios de Pruebas

Se adjunta la documentación de las evidencias de los Escenarios de Pruebas en formato .ZIP

Plan de Despliegue

Actividad Responsable Hora Inicio Hora Fin

Plan de Rollback

Actividad Responsable Hora Inicio Hora Fin

Aprobaciones

Fuente: Elaboración Propia

2
DESCRIPCION DEL PROCESO ACTIVOS DEL SERVICIO Y GESTION DE LA CONFIGURACION
A continuación se muestra la propuesta del flujo del procesos de Activo del Servicio y Gestión de la Configuración.

Figura 73: Proceso de Activos del Servicio y Gestión de la Configuración

Fuente: Elaboración Propia

2
Conceptos Fundamentales

Gestión de Activos del Servicio y de la Configuración.


Asegurar que los activos requeridos para entregar los servicios sean controlados apropiadamente,
y que la información exacta y confiable acerca de estos activos esté disponible cuando y donde
se le necesita. Esta información incluye detalles de cómo los activos están configurados y las
relaciones entre ellos.

CI (Configuration Item)
Un Elemento de Configuración es todo activo, servicio, componente de servicio o cualquier ítem
que es o está bajo el control de la Gestión de la Configuración.

CMDB (Configuration Management DatabaseL


La Base de Datos de la Gestión de la Configuración contiene la información detallada de cada CI
y sus diferentes interrelaciones o interdependencias tanto físicas como lógicas con otras CI’s

2
Descripción del Proceso
A continuación se detalla las actividades relacionadas al proceso propuesto de Gestión de
Activos de Activos de Servicio y Gestión de Configuración.

Antecedentes

El proceso inicia con el input del RFC que se obtiene desde el proceso de Gestión de Cambio.

1. Identificar Activos del


Servicio Supervisor de
Infraestructura de TI

1. El supervisor de infraestructura de Ti recibe el RFC y procede a identificar los IC’s


referenciados al servicio, se continuara con la tarea descrita en el punto 2.

2. Clasificar los CI’s


Supervisor de Infraestructura de TI

2. El supervisor de infraestructura de TI clasifica el Harware, Sotfware y Servicio de TI para


determinar la criticidad del mismo y determinar formalmente el CI’s, se continuara con la
tarea descrita en el paso 3.

3. Solicitar Validación del Diagrama de Infraestructura


Supervisor de Infraestructura de TI

3. El supervisor de infraestructura de TI solicita al analista técnico la validar los servicios


con el diagrama de infraestructura, se continuara con la tarea descrita en el punto 4.

4. Validar Diagrama de
Infraestructura Analista Técnico

2
4. El analista técnico valida los elemento de configuración (IC’s) con el diagrama de
infraestructura. Si la validación es satisfactoria se continuara con la tarea descrita en el
punto 5; en caso contrario, se continuara con la tarea descrita en el punto 2.

5. Actualizar Lista de
CI’s Analista Técnico

5. El analista técnico actualiza el listado de CI’s que se encuentran incluidas dentro del
CMDB con características relacionadas al elemento de configuración y sus relaciones, se
continuara con la tarea descrita en el punto 6.

6. Actualiza Diagrama de Infraestructura


Analista Técnico

6. El analista técnico actualiza el diagrama de infraestructura según las relaciones


establecidas en la lista de IC’s, termina el proceso.

Matriz RACI de Roles y Responsabilidades


La siguiente tabla presenta el papel o nivel de responsabilidad que cada uno de los roles
definidos desempeña en cada una de las actividades que se realizan en el proceso de “Activos de
Servicio y Gestión de Configuración”.

2
Tabla 73: Matriz RACI Activos de Servicio y Gestión de Configuración

ROLES

Supervisor de Infraestructura

Analista Técnico
ACTIVIDADES

Identificar Activos del Servicio A/R

Clasificar los CI's A/R

Solicitar Validación del Diagrama de Infraestructura A/R

Validar Diagrama de Infraestructura I A/R

Actualizar Lista de CI's I A/R

Actualiza Diagrama de Infraestructura I A/R

R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO ANTES DE HACER
I: INFORMADO DESPUES DE HACER

Fuente: Elaboración Propia

Métricas
A continuación se indican los KPI’s relacionados al proceso de “Activos del Servicio y Gestión
de la Configuración”.

2
Tabla 74: Métricas del Proceso de Activos del Servicio y Gestion de la Configuracion
KPI Descripción

Frecuencia de verificación Frecuencia de verificaciones físicas del


contenido de CMS

Duración de verificación Duración promedio de verificaciones físicas


del contenido de CMS

Esfuerzo para verificaciones de CMS Promedio de esfuerzo de trabajo para


verificaciones físicas del contenido de CMS

Cubiertas CMS Porcentaje de elementos de configuración


cuyos datos están incluidos en la CMS

Actualización automática de CMS Porcentaje de elementos de configuración


cuyos datos en la CMS se actualizan
automáticamente

Cantidad de errores de CMS Número de ocasiones en las que se


detectaron incorrecciones en el contenido de
la CMS

Fuente: Elaboración Propia

2
Ficha de Listado de CI - Hardware
A continuación se visualiza el formato a utilizar para listar los elementos de configuración
[Hardware], relacionados al servicio identificado.

Tabla 75: Ficha de Listado de CI’s Hardware


ID Tipo de CI Descripción de CI Ubicación

CIH001 Servidor Servidor SAP IBM AIX 5.3 – 7.1 Honda Brasil

CIH002 Servidor Servidor SAP NetWeaver Portal Honda Brasil

CIH003 Servidor Servidor de Base de Datos Honda Brasil

Fuente: Elaboración Propia

Ficha de Listado de CI - Software


A continuación se visualiza el formato a utilizar para listar los elementos de configuración
[Software], relacionados al servicio identificado.

Tabla 76: Ficha de Listado de CI’s Software


ID Tipo de CI Descripción de CI Relación con CI Ubicación
Hardware

CIS001 Aplicación ERP SAP v. 6 CIH001 Honda Brasil

CIH002

CIH003

Fuente: Elaboración Propia

2
DESCRIPCION DEL PROCESO DE GESTION DE INCIDENTES

Figura 74: Proceso de Gestión de Incidentes

Fuente: Elaboración Propia

2
Conceptos Fundamentales

Incidencia
Cualquier evento que no forma parte de la operación estándar de un servicio y que causa o puede causar
una interrupción o una reducción de calidad del mismo.

Problema
Causa subyacente, aún no identificada, de una serie de incidentes o un incidente aislado de importancia
significativa.

Gestión de Problemas
Proceso ITIL, que sirve para controlar el ciclo de vida de todos los problemas. Los objetivos primordiales
son la prevención de incidentes y la minimización del impacto de aquellos incidentes que no pueden
prevenirse.

Gestión de cambios
Proceso ITIL, que sirve para controlar y dar seguimiento al ciclo de vida de todos los cambios. El
objetivo principal es viabilizar los cambios beneficiosos con unminimo de interrupciones en la prestación
de servicios TI.

Descripción del Proceso

1. Reportar Ocurrencia
Usuario

2
1. El usuario reporta la ocurrencia de algún incidente. Continúa en el punto 2.

2. Registrar y clasificar Incidente


Soporte de Incidentes de 1er
Nivel

2. El analista de soporte de incidentes de 1er nivel registra y clasifica la incidencia. Continúa


en el punto 3.

3. Validar si incidente está asociado a un Problema


Soporte de Incidentes de 1er Nivel

3. El analista de soporte de incidentes de 1er nivel verifica si el incidente está asociado a un


problema. Si el incidente no está asociado a un problema, se continuara con la tarea
descrita en el punto 4; caso contrario, se continuara con la tarea descrita en el punto 9.

4. Validar si incidente es de alto impacto


Soporte de Incidentes de 1er Nivel

4. El analista de soporte de incidentes de 1er nivel verifica si el incidente es de alto impacto


para el negocio. Si el incidente es de alto impacto, se continuara con la tarea descrita en el
punto 5; caso contrario, se continuara con la tarea descrita en el punto 7.

5. Validar existencia de problema


relacionado Soporte de Incidentes de 1er Nivel

5. El analista de soporte de incidentes de 1er nivel verifica la existencia de algún problema


relacionado al incidente. Si no existe, se continuara con la tarea descrita en el punto 6;
caso contrario, se continuara con la tarea descrita en el punto 8.

6. Notificar Problema
Soporte de Incidentes de 1er Nivel

2
6. El analista de soporte de incidentes de 1er nivel notifica el problema al responsable del
proceso de Gestión de Problemas y finaliza el proceso.

7. Validar si existen múltiples incidentes


similares Soporte de Incidentes de 1er Nivel

7. El analista de soporte de incidentes de 1er nivel verifica si existen múltiples incidentes


similares. Si existen múltiples incidentes similares, se continuara con la tarea descrita en
el punto 5; caso contrario, se continuara con la tarea descrita en el punto 9.

8. Asociar incidente al problema


Soporte de Incidentes de 1er
Nivel

8. El analista de soporte de incidentes de 1er nivel asocia el incidente a problema


relacionado, se continuara con la tarea descrita en el punto 9.

9. Investigar y Diagnosticar Solución


Soporte de Incidentes de 1er Nivel

9. El analista de soporte de incidentes de 1er nivel investiga y diagnostica la solución, se


continuara con la tarea descrita en el punto 10.

10. Validar si se identificó el cambio


Soporte de Incidentes de 1er Nivel

10. El analista de soporte de incidentes de 1er nivel verifica si se logró identificar el cambio
que soluciona el problema. Si se identificó el cambio a realizar, se continuara con la tarea
descrita en el punto 11; caso contrario, se continuara con la tarea descrita en el punto 14.

11. Notificar cambio


Soporte de Incidentes de 1er Nivel

2
11. El analista de soporte de incidentes de 1er nivel notifica el cambio a gestión de cambios,
se continuara con la tarea descrita en el punto 12.

12. Validar Solución con Usuario


Soporte de Incidentes de 1er Nivel

12. El analista de soporte de incidentes de 1er nivel verifica con el apoyo de los usuarios si se
logró solucionar el problema. Si el problema fue solucionado, se continuara con la tarea
descrita en el punto 13; caso contrario, se continuara con la tarea descrita en el punto 9.

13. Documentar solución


Soporte de Incidentes de 1er Nivel

13. El analista de soporte de incidentes de 1er nivel documenta la solución aplicada al


incidente, se continuara con la tarea descrita en el punto 16.

14. Escalar de nivel


Soporte de Incidentes de 1er Nivel

14. El analista de soporte de incidentes de 1er nivel escala el incidente con el analista
correspondiente para un análisis de segundo nivel, se continuara con la tarea descrita en
el punto 15.

15. Actualizar Ticket con acciones 1er nivel


Soporte de Incidentes de 1er Nivel

15. El analista de soporte de incidentes de 1er nivel actualiza el ticket con las acciones
tomadas como resultado del análisis de primer nivel como feedback, se continuara con la
tarea descrita en el punto 17.

16. Cerrar Ticket


Soporte de Incidentes de 1er Nivel

2
16. El analista de soporte de incidentes de 1er nivel cierra el ticket y finaliza el proceso.

17. Realizar Diagnostico técnico


Soporte de Incidentes de 2do Nivel

17. El analista de soporte de incidentes de 2do nivel realiza un diagnostico técnico del
incidente, se continuara con la tarea descrita en el punto 18.

18. Validar si es un problema 2do nivel


Soporte de Incidentes de 2do Nivel

18. El analista de soporte de incidentes de 2do nivel verifica nuevamente luego de su análisis
si se trata de un problema. Si es un problema, se continuara con la tarea descrita en el
punto 19; caso contrario, se continuara con la tarea descrita en el punto 20.

19. Actualizar ticket con acciones técnicas y notificar


Soporte de Incidentes de 1er Nivel

19. El analista de soporte de incidentes de 2do nivel actualiza ticket con acciones técnicas,
notifica el problema y finaliza el proceso.

20. Contactar a Proveedor para Solución


Soporte de Incidentes de 2do Nivel

20. El analista de soporte de incidentes de 2do nivel contacta a proveedor para solicitar
solución del incidente, se continuara con la tarea descrita en el punto 21.

21. Ejecutar pasos de solución de incidente


Soporte de Incidentes de 2do Nivel

21. El analista de soporte de incidentes de 2do nivel ejecuta los pasos proporcionados por el
proveedor para la solución del incidente, se continuara con la tarea descrita en el punto
12.

2
22. Seguimiento y verificación del proceso
Gestor de Incidentes

22. El gestor de Incidentes da seguimiento y verifica todo el proceso de gestión de incidentes


de forma paralela.

2
Matriz RACI de Roles y Responsabilidades
La siguiente tabla presenta el papel o nivel de responsabilidad que cada uno de los roles
definidos desempeña en cada una de las actividades que se realizan en el proceso de Gestión de
Incidentes.

Con la finalidad de crear un conjunto de roles flexible y adaptable al proceso de gestión de


Incidentes de cualquier organización, se han definido roles muy específicos. En la
implementación real del proceso en La Entidad, una persona puede desempeñar varios de estos
roles, siempre y cuando dichos roles no sean incompatibles entre sí.

Tabla 77: Matriz RACI Gestión de Incidentes


ROLES

Soporte de 2do Nivel


Gestor de Incidentes

Soporte de 1er Nivel


Usuario

ACTIVIDADES

Reportar Ocurrencia A R

Registrar y clasificar Incidente A C/I R

Validar si incidente está asociado a un Problema A C/I R

Validar si incidente es de alto impacto A C/I R

Validar existencia de problema relacionado A C/I R

Notificar Problema A I R

Validar si existen múltiples incidentes similares A C R

Asociar incidente al problema A C/I R

Investigar y Diagnosticar Solución A C R

Validar si se identifico el cambio A R

Notificar cambio A I R

2
ROLES

Soporte de 2do Nivel


Gestor de Incidentes

Soporte de 1er Nivel


Usuario
ACTIVIDADES

Validar Solución con Usuario A C R

Documentar solución A R

Actualizar Ticket con acciones 1er nivel A I R

Escalar de nivel A I R

Cerrar Ticket A I R

Realizar Diagnostico técnico A C R

Validar si es un problema 2do nivel A C R

Actualizar ticket con acciones técnicas y notificar A I R

Contactar a Proveedor para Solución A I R

Ejecutar pasos de solución de incidente A I R

Seguimiento y verificación del proceso R/A C C

R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO ANTES DE HACER
I: INFORMADO DESPUES DE HACER

Fuente: Elaboración Propia

2
Descripción de Roles y Responsabilidades

Usuario
Persona o grupo de personas que usa o utiliza algún servicio TI.

Gestor de Incidentes
Es el rol dueño del proceso. Se encarga de vigilar el correcto cumplimiento del proceso de
gestión de incidentes y la obtención de las métricas del proceso.

Soporte de 1er nivel


Personal de Centro de Servicios quien recibe el incidente.

Soporte de 2do nivel de incidentes


Personal de mayor experiencia que se encarga de solucionar incidentes que no pudieron ser
resueltos por el 1er nivel, puede ser proveedor, fabricante o experto. Puede ser 2do o 3er nivel.

2
Metricas
Con el objetivo de poder medir el cumplimiento progresivo del proceso de gestión de incidentes,
se ha considerado las siguientes métricas por cada período mensual:

 Número total de incidentes clasificados por tipo de prioridad reportados.

 Número de incidentes asignados a grupos de soporte clasificados por tipo de prioridad.

 Porcentaje de incidentes solucionados de acuerdo al SLA por tipo de prioridad.

Estas métricas permitirán ver el desempeño de la gestión de incidentes y conocer si los


incidentes se están resolviendo en el tiempo adecuado o si es necesario realizar un ajuste a los
SLA.

2
CONCLUSIONES

A lo largo de este capítulo se ha desarrollado los pasos propuestos para adoptar las mejores
prácticas de gestión de servicios de TI que propone ITIL. Para ello, se ordenaron las actividades
que actualmente realiza Honda dentro de su día a día, para luego asociarlas a los procesos que
propone ITIL, los cuales son; Gestión de Cambios, Gestión del Nivel del Servicio, Gestión de
Activos del Servicio y Gestión de la Configuración, Gestión de Incidentes y Gestión de
Portafolio del Servicio correspondientemente. Como resultado de ello, la organización contará
con una gestión de servicios de calidad, brindando así la disponibilidad, confiabilidad,
flexibilidad y seguridad para los servicios críticos de la organización.

Considerando los objetivos estratégicos de la organización y las prioridades determinadas por


ella, se logró identificar que las mejoras del Servicio de Planificación de Pedidos Comerciales
Pendientes, que brindará las herramientas necesarias para la gestión y recuperación de los
pedidos comerciales pendientes, aporta valor al negocio alineándose a los objetivos estratégicos.
Por tanto, se sustenta la prioridad de inversión del servicio, debido a su relación directa con los
Objetivos estratégicos.

Por consiguiente, en vista de la importancia del servicio y con la finalidad de que el área de TI
genere soluciones con mayor valor para el negocio, se puede concluir que la implementación de
los procesos ITIL para el servicio de Gestión de Planificación de pedidos comerciales
pendientes, que si bien no es un servicio crítico para la empresa, si contribuye
considerablemente al logro de los objetivos de la organización, otorgando mayor competitividad
y capacidad de reacción ante las necesidades de planificación y recuperación de pedidos
comerciales pendientes.

2
CAPÍTULO 5: ESTRUCTURA PROPUESTA

INTRODUCCIÓN
Este capítulo tiene como objetivo desarrollar un análisis integral de la propuesta de mejora del
proceso de Gestión de Planeamiento, con la finalidad de sustentar la viabilidad y los beneficios
que su aplicación otorgaría a la Organización Honda del Perú S.A.

Para lograr ello, se utilizan cuadros y diagramas, los cuales permiten visualizar como es que los
objetivos estratégicos de la organización son quienes impulsan toda iniciativa de mejora sobre
los procesos de negocio para cubrir las brechas que impiden su cumplimiento. La identificación
de brechas se apoya en la propuesta de Arquitectura empresarial bajo el marco de trabajo
TOGAF.

Por otro lado, se describe también la relación entre las brechas y los servicios de negocio que las
cubrirán; así como también, la necesidad de contar con las mejores prácticas que nos brinda
ITIL, para una adecuada gestión de servicios que permita garantizar su continuidad. Como
resultado del análisis, se contara con una visión general que muestra la trazabilidad existente
entre los objetivos estratégicos de la organización y los servicios de negocio modificados que
ayudaran a disminuir las brechas de negocio identificadas en el proceso de Gestión de
Planeamiento.

ENFOQUE DE LA PROPUESTA
El enfoque de esta propuesta se orienta a la mejora del proceso de Gestión de Planeamiento, en
adelante GPL, para la organización Honda del Perú S.A (ver cap. 1 pág. 33), el cual se encarga
de la planificación y recuperación de los pedidos pendientes por falta de stock.

2
El motivo por el cual el esfuerzo se centra en el proceso GPL no es casual, sino más bien se basa
en el logro de los objetivos estratégicos priorizados por la organización (ver cap. 1 pág. 36), de
los cuales los atacados directamente por esta propuesta son, mejorar las ventas de repuestos y
disminuir el tiempo de abastecimiento de pedidos pendientes (BackOrder) de los mismos.

Como resultado, se espera como beneficio la reducción del tiempo de abastecimiento de


mercancía para satisfacer las necesidades del cliente, los demás beneficios se detallan en la
sección correspondiente del proyecto (ver cap. 1 pág. 42).

La importancia de identificar adecuadamente las brechas, que actualmente impiden el logro de


los objetivos de la organización, es el sustento principal de la necesidad de contar con las
técnicas adecuadas para identificarlas. Por tanto, es aquí donde la propuesta de Arquitectura
Empresarial, en base al marco de trabajo TOGAF (ver cap.1 pág. 17), aplicado al proceso
operacional GPL, toma mayor valor para el negocio.

La función de la Arquitectura Empresarial, en adelante AE, aplicado a los procesos


organizacionales, en este caso al proceso GPL es el de puente entre el estado actual y lo
esperado, cuyo análisis se realiza dentro de los 4 dominios principales de la AE (ver cap. 1 pág.
17). Para ello, se realizo un análisis a través de las 5 primeras fases propuestas por el método de
desarrollo de la Arquitectura (ver cap. 1 pág. 18). El desarrollo del análisis se puede visualizar en
el capítulo 2 (ver cap.2 pág. 43). Como resultado del mismo, se identifican las brechas
delimitadas por sus respectivos dominios (ver cap. 2 pág. 98) y un cuadro resumen del plan de
migración en donde se visualizan las soluciones tentativas que las mitiguen (ver cap. 2 pág. 106);
por consiguiente, se propone lograr un cambio relevante que alinea la visión y los objetivos
estratégicos del negocio.

A fin de mitigar las brechas identificadas surge la necesidad de contar con una metodología de
desarrollo de software que apoye en la construcción de las soluciones potenciales identificadas,
metodología que ayudara en la construcción y/o modificación de aquellos servicios de negocio
que requieren ser mejorados para el logro de los objetivos estratégicos.

2
Esta propuesta, apuesta por los beneficios que las metodologías agiles proponen, para ser mas
especifico por SCRUM, pero la decisión de tomar esta metodología no fue al azar, sino más bien
se sustenta en un análisis previo que toma como referencia algunos criterios evaluativos
indispensables que permiten su elección (ver cap.3 pág. 132).

Finalmente, en vista de que la mejora del proceso GPL implica la modificación del servicio de
negocio de “Planificación de pedidos comerciales pendientes”, es requerido contar con una
adecuada gestión del servicio para asegurar su la calidad. Para ello, no hemos apoyado en las
mejores prácticas proporcionadas por ITIL (ver cap.4 pág. 162), en donde se propone la
implementación de 5 procesos ITIL que fueron adecuados a la realidad de Honda del Perú S.A.
para mantener una eficiente gestión de servicios.

SUSTENTO DE BENEFICIOS

Con el caso que se muestra a continuación se evidencia que la propuesta de mejora reduciría el
tiempo de abastecimiento de mercancía para satisfacer la necesidad del cliente.

CASOS

Caso A: Abastecimiento de pedido comercial pendiente de atención

Necesidad
Se tiene la necesidad de abastecer la mercadería indicada en el siguiente cuadro y como se
observa en el centro HUB se encuentra con stock “Cero”. Por ello, es necesario realizar la
compra al proveedor “AMERICAN HONDA MOTOR CO INC

2
Figura 75: Listado de Necesidad de Pedido Comercial

Fuente : Elaboración Propia

En la actualidad:
A no contar con stock en el almacén HUB, se generá el pedido de compra al proveedor
“AMERICAN HONDA MOTOR CO INC” para cubrir la necesidad del cliente que según
compromiso la atención se realizara en 45 dias, tal como se muestra en el siguiente imagen..

Figura 76: Lista de Pedidos de Compra

Fuente : Elaboración Propia

2
Propuesta:
A continuación se refleja como propuesta que parte de la necesidad se cubrira del arribo de otro
pedido de compra y lo faltante se obtendra desde el almacén local.

Abastecimiento por arribo de otro pedido de compra


La propuesta de mejora es contar con herramientas que le permita identificar otras fuentes de
abastecimiento para atender la necesidad requerida. En este caso, se tiene un pedido que arriba al
dia siguiente de la necesidad y con ello seria posible planificar la atencion y satisfacer la
necesidad del cliente en 1 día, tal como se muestra en la siguiente imagen.

Figura 77: Listado de Pedidos en transito

Fuente : Elaboración Propia

Abastecimiento por traslado de otro almacén (Stock Almacén Local)


En este caso, se cuenta con el stock requerido en el almacén local y con ello seria posible realizar
una translado entre almacens y satisfacer la necesidad del cliente.

Figura 78: Listado de Stock Almacen Local

Fuente : Elaboración Propia

2
Caso B : Abastecimiento consolidado por linea de repuestos
Necesidad:
Se tiene la necesidad de abastecer los pedidos comerciales pendientes de atención que se
muestran a continuación consolidado por linea de negocio.

Figura 79: Listado de Pedidos comerciales Penndientes

Fuente : Elaboración Propia

Propuesta:
Teniendo el siguiente stock por cada fuente de abastecimiento para cubrir la necesidad por linea
de negocio indicado en el cuadro anterior.

Figura 80: Sustento de Beneficio – Abastecimiento consolidado por línea de repuesto

Fuente : Elaboración Propia

Como se puede observar el stock indicado cubre el 100% de las líneas de Motos, Autos y
Producto de Fuerza. Por otro lado, solo se pudo cubrir la necesidad del 94% de la línea de
Accesorios quedando pendiente 850 unidades que serán atendidas mediante la generación de un
pedido de compra.

2
Caso C : Abastecimiento del 20% de Pedido Comerciales Pendientes en 1er año.

A continuación se muestra el sustento del 20% de abastecimiento de pedidos comerciales


pendientes en 1er año, teniendo como muestra los B/O no atendidos en el año 2016 y que se
toma como referencia para la proyección de atención.

Figura 81: Abasteciento del 20% de Pedido Comerciales Pendientes en 1er año

Fuente: Elaboración Propia

 Se evidencia en el Q1, que sí pudo ser posible atender la necesidad utilizando las fuentes de
abastecimiento “Local” y “Transito”.

 Se evidencia en el Q2, que sí pudo ser posible atender la necesidad utilizando las fuentes de
abastecimiento “Local” y “Transito”.

 Se evidencia en el Q3, que sí pudo ser posible atender la necesidad utilizando las fuentes de
abastecimiento “Local”.

2
CALCULO DE INVERSION (VAN/TIR)

FLUJO DE EFECTIVO
A continuación se muestra el flujo de efectivo del servicio propuesto del proceso seleccionado
obteniendo el VAN y TIR. De igual manera se sustenta los ingresos y egresos del servicio
propuesto. (Ver cap. 4 pag.168)

Figura 82: Flujo de Efectivo - Inversión

Fuente: Elaboración Propia

FLUJO ACUMULADO
A continuación se visualiza el diagrama de punto de equilibrio de la propuesta del servicio
identificado en el proceso seleccionado. En el que se observa la recuperación de la inversión
inicial antes de cumplir el segundo año, concluyendo el quinto año con una ganancia acumulada
de $291,281.

2
Figura 83: Flujo Acumulado

Fuente: Elaboración Propia

VAN

Tasa de Descuento del 10%

Con el flujo de efectivo proyectado a 5 años, menos la inversión inicial y con una tasa de
descuento del 10% se obtiene Valos Actual Neto de $185,942 y siendo la tasa de descuento
menor que la TIR, la propuesta es rentable.

2
TIR

Figura 84: VAN y TIR del Servicio propuesto

Fuente: Elaboración Propia

Con el flujo de efectivo antes indicado, se obtiene la Tasa Interna de Retorno (TIR) del 62%,
siendo el porcentaje maximo a utilizar como tasa de descuenta donde el VAN no genera perdida.

2
ESQUEMA GRAFICO DE LA ESTRUCTURA PROPUESTA

A continuación se muestra el esquema grafico de la estructura propuesta, donde se visualiza el


proceso seleccionado alineado a los objetivos estrategicos del negocio, identificando las brechas
del proceso que seran cerradas por la propuesta.

Figura 85: Esquema grafico

Fuente: Elaboración Propia

2
DESCRIPCION DEL ESQUEMA GRAFICO

En el esquema grafico de la estructura propuesta se visualiza los objetivos estratégicos , siendo


los pilares en el que se soporta el negocio. Por ello, luego de realizar las evaluaciones respectivas
a los procesos de negocio relacionado a cada uno de los objetivos estratégicos de la
organización, se identificó una oportunidad de mejora en el proceso “Gestión de Planeamiento
(GPL)” alineado directamente a los objetivos estratégicos “Disminuir el tiempo de
abastecimiento de BackOrder (pedidos pendientes) en un 30% con respecto al año 2016” y
“Mejorar las ventas de repuestos al exterior en un 20% con respecto al año 2016” ya que a la
fecha no cuentan con herramientas que les permita planificar el abastecimiento de pedidos
comerciales pendientes de atención por falta de stock, ocasionando perdida en ventas. Por tal
motivo, utilizando el esquema TOGAF se identificaron brechas entre la arquitectura base(AS-IS)
y la arquitectura destino (TO - BE). Por ello, para cerrar las brechas identificadas, se presenta la
propuesta de mejora que tiene como finalidad brinda las herramientas necesarias dentro del ERP
SAP, modulo MM “Material Management” para planificar de forma óptima el abastecimiento de
los pedidos comerciales pendiente de atención por falta de stock, contando con 6 fuentes de
abastecimiento. Finalmente la propuesta será organizada por el marco de las buenas prácticas de
ITIL como el servicio “Servicio de Planificación de Pedidos Comerciales Pendientes”.

2
DESCRIPCION DE BRECHAS DEL NEGOCIO
A continuación se describen las brechas que se mencionan en el esquema grafico de la estructura
propuesta:

Tabla 78: Listado de GAPs


Listado y Descripción breve de las Brechas identificadas

GAP 1 Actualizar "Listar pedidos B/O para planificación".

Descripción de la Brecha:

En la actualidad se pierda la oportunidad de abastecer pedidos B/O a tiempo, debido a que la


información de pedidos pendientes de atención no se encuentra centralizada, siendo necesario
realizar procedimientos manuales en Excel.

GAP 2 Actualizar "Verificar stock disponible local".

Descripción de la Brecha:

En la actualidad la verificación del stock disponible en el almacén local no es real, ya que no es


posible asignar el total del stock obtenido, debido a que es necesario consultar, cual es el stock
máximo permitido a utilizar, ocasionando, demora en el abastecimiento de los pedidos B/O.

GAP 3 Actualizar "Compromete Stock local disponible al pedido comercial"

Descripción de la Brecha:

Para identificar que pedidos pendientes de atención serán abastecidos es necesario consultar
archivos Excel, ocasionando asignaciones incorrectas por no contar con la información
actualizada, ya que en ocasiones se cancela la necesidad.

GAP 4 Implementar "Gestionar Planificación BackOrders".

2
Descripción de la Brecha:

En la actualidad solo se abastecen los pedidos pendientes de atención elaborando un pedido de


compra por la necesidad requerida que no se ha podido atender por falta de stock, ocasionando la
demora en el abastecimiento ya que la atención aprox del proveedor es de 45 días.

GAP 5 Actualizar "Recepcionar mercadería"

Descripción de la Brecha:

En la actualidad al realizar la recepción de pedidos de compra que fueron generados para


abastecer pedidos comerciales pendientes de atención ingresan al stock de libre disponibilidad,
ocasionando, que otros pedidos comerciales comprometan el stock y realicen el despacho del
mismo, perjudicando al cliente que se encuentra a la espera de la llegada de la mercadería.

GAP 6 Eliminar "Priorizar pedidos"

Descripción de la Brecha:

En la actualidad la priorización de pedidos es ineficiente ya que se realiza la gestión de


abastecimiento consultando información desactualizada.

Fuente : Elaboracion Própia

2
CONCLUSIONES

El enfoque de este capítulo es el de demostrar que la propuesta de mejora del Proceso de Gestión
de planeamiento GPL es rentable y está alineado con los objetivos estratégicos de la
organización. Además, de sustentar que los beneficios de reducción de tiempo de despacho,
tiempo de gestión de abastecimiento a los que apunta el proyecto tienen una base sólida y serán
logrables.

Por consiguiente, se plantea un esquema gráfico con la finalidad de mostrar que las mejoras en el
proceso GPL, sobre el Servicio de Planificación de Pedidos Comerciales Pendientes, apuntan al
logro de los dos objetivos estratégicos priorizados por la organización, es decir a disminuir el
tiempo de abastecimiento de los pedidos comerciales pendientes, en adelante backorders (B/O) y
mejorar las ventas de repuestos. Por lo tanto, se logra concluir que las mejoras identificadas
dentro del análisis de brechas, resultado del trabajo realizado con el apoyo del marco de trabajo
TOGAF, sobre el proceso GPL, efectivamente impulsan un alineamiento de los esfuerzos de TI
con el negocio y los objetivos de la organización.

Por otro lado, de acuerdo al análisis financiero realizado se concluye que la propuesta es rentable
mediante el desarrollo de flujo de caja, contemplando una proyección de 5 años, debido a que el
valor actual neto esperado luego de 5 años proporciona una ganancia importante sobre la
inversión.

Finalmente, respecto al beneficio de reducción del tiempo de despacho de B/O se puede concluir
que el contar con las herramientas que permitan enlazar los B/O con diversas fuentes de
abastecimiento para su recuperación permite que los B/O puedan ser entregados al cliente con
mayor rapidez y asegura que los nuevos pedidos comerciales no dispongan libremente de los
stocks designados para cubrir los B/O.

2
CONCLUSIONES

Se identificó que las actividades del proceso de Gestión de Planeamiento (GPL) no eran
eficiente, debido a la demora en la recuperación y despacho de los pedidos comerciales
pendientes, en adelante backorders (B/O). Además, muchas veces se consumen esfuerzos en
planificación de la recuperación de los B/O, obteniendo resultados que no son eficientes, ya que
no existen los controles adecuados en el proceso para que éstos tengan prioridad sobre los
nuevos pedidos comerciales. Así mismo, las fuentes de abastecimiento para los B/O están
limitadas al almacén local de libre disponibilidad y a la generación de una nueva solicitud de
compra; por lo cual, se concluye que son los principales factores que la falta de control que
priorice la recuperación de B/O y las limitadas fuentes de abastecimiento generan un retraso en
la recuperación y posterior despacho de estos pedidos comerciales pendientes.

El uso del marco de trabajo TOGAF permitió identificar las brechas y proponer mejoras en el
proceso de Gestión de Planeamiento GPL que direccionen hacia un alineamiento entre la
realidad implementada del proceso GPL y los objetivos a los que apunta la organización.

En base a la revisión de las ventajas y desventajas de las metodologías agiles (XP y SCRUM)
versus las tradicionales y contemplando criterios como tamaño del proyecto, tiempos de entrega,
necesidad de documentación, disponibilidad del cliente, entre otros, se concluye que la
utilización de Scrum es la que más se adecuada para obtener resultados rápidos, ya que cumple
con los criterios a los que se amolda la organización.

La implementación de la solución propuesta permitirá al área de Logística contar con un servicio


de negocio eficiente para la planificación y recuperación de los B/O de forma eficaz, logrando

3
con ello, disminuir el tiempo de despacho de los B/O a los clientes. Por lo cual, se disminuirán
las perdidas por aquellas B/O que son canceladas por los clientes por demoras en su entrega.

Considerando los objetivos estratégicos de la organización y las prioridades determinadas por


ella, se logró identificar que las mejoras del Servicio de Planificación de Pedidos Comerciales
Pendientes, que brindará las herramientas necesarias para la gestión y recuperación de los
pedidos comerciales pendientes, aporta valor al negocio alineándose a los objetivos estratégicos.
Por tanto, se sustenta la prioridad de inversión del servicio, debido a su relación directa con los
Objetivos estratégicos.

La propuesta de implementación de una arquitectura empresarial para el proceso de Gestión de


Planeamiento (GPL) efectivamente se encarga de identificar todas aquellas brechas que evitan el
alineamiento entre la realidad implementada y los objetivos de la organización. Por otro lado,
sabemos que ITIL provee las buenas prácticas y los lineamientos para una adecuada gestión de
servicios generados para mitigar las brechas, logrando con ello; la disponibilidad, confiabilidad,
flexibilidad y seguridad de los servicios críticos de la organización. Por lo tanto, se puede
concluir que tanto la Arquitectura empresarial desarrollada en esta propuesta de mejora como las
buenas prácticas y recomendaciones que se proponen con ITIL preparan a la organización para el
cambio, alineando todo esfuerzo en el cumplimiento de los objetivos de la organización.

3
RECOMENDACIONES

 A continuación se proponen algunas recomendaciones a tomar en cuenta en las siguientes


iteraciones relacionados con el proyecto que no fueron tratados en el documento.

 En base a la gestión de abastecimiento realizada, servirá como estadísticas adicionales para


identificar los materiales de mayor rotación y sirva de variable para la planificación general
de abastecimiento.

 Para minimizar los pedidos pendientes de atención se recomienda implementar estrategias de


distribución de materiales, asignando a los clientes cuotas equitativas.

 Implementar alertas de aviso cuanto el material este en el umbral de stock mínimo necesario
y requiera aplicar alguna gestión de abastecimiento.

3
GLOSARIO DE TÉRMINOS

A continuación se define el significado de cada término propio del dominio, que pudiera resultar
desconocido o confuso a los lectores.

BACKORDER.- Pedido pendiente por falta de stock.

B/O.- Pedido pendiente por falta de stock.

HUB.- Tipo de Servicio de abastecimiento de pedidos de repuestos a exportar.

Picking.- Recopilación de materiales a despachar.

Packing.- Embalaje de materiales a despachar.

ITIL. - Conjunto de prácticas estándar para el área de

Tecnología. SCRUM - Marco de trabajo para desarrollo de

proyectos ágiles. TIR.- Es la tasa de interés o rentabilidad que

ofrece una inversión TOGAF.- Marco de trabajo de una

arquitectura empresarial.

VAN.- Valor actual neto, indicador financiero que determina la viabilidad de un proyecto.

3
BIBLIOGRAFÍA

[01] Arquitectura Empresarial, (2016) https://colombiadigital.net/actualidad/articulos-


informativos/item/8123-que-es-arquitectura-empresarial.html (Consulta: 25 de Octubre)

[02] TOGAF, (2016) http://www.opengroup.org/subjectareas/enterprise/togaf (Consulta: 25 de


Octubre)

[03] Fases de TOGAF, (2016) http://www.vanharen.net/Samplefiles/9789087537104SMPL.pdf


(Consulta: 28 de Octubre)

[04] Metodologías Agiles de Desarrollo de Software, (2016)


https://es.wikiversity.org/wiki/Metodolog%C3%ADas_%C3%A1giles_de_desarrollo_software

(Consulta: 13 de Noviembre)

[05] Manifiesto para el Desarrollo Ágil de Software, (2016) http://www.agilemanifesto.org

(Consulta: 14 de Noviembre)

[06] Proyectos agiles – SCRUM, (2016) https://proyectosagiles.org/

(Consulta: 14 de Noviembre)

3
[07] Atkinson, Philip. (2012). Creating culture change. http:// www.philipatkinson.com/ Philip-
Atkinson-CreatingCultureChange.pdf.

Ashmore Ph.D., Sondra. Introduction to Agile Methods (pp. 45-46). Pearson Education. Kindle
Edition.

[08] I2B Intelligence to Business. Beneficios de aplicar Metodologías Ágiles


http://www.i2btech.com/blog-i2b/tech-deployment/5-beneficios-de-aplicar-metodologias-agiles-
en-el-desarrollo-de-software/

[09] Leonardo Florez Marin y Felipe Grisales Tobon (2014) Formulación De Criterios para la
Selección de metodologías de desarrollo de Software. Universidad Tecnológica de Pereira
Facultad De Ingenierías en Sistemas y Computación Pereira, Risaralda.

[10] JACOBSON, Ivar, GRADY, Booch y RUMBAUGH, James (2014), El proceso unificado
de desarrollo de software. Disponible en:

http://unpprogespcn.com/material/RUP/ElProcesoUnificadodeDesarrollodeSoftware.pdf

[11] SCRUM guides The History of Scrum [en línea], [Fecha de consulta: 15/10/2014].
Disponible en: http://www.scrumguides.org/history.html

[12] SCHWABER, Ken, SUTHERLAND, Jeff, The SCRUM guide [en línea], [Fecha de
consulta: 16/10/2014]. Disponible en: http://www.scrumguides.org/docs/scrumguide/v1/scrum-
guide-us.pdf

3
[13] KNIBERG, Henrik, SCRUM and XP from the trenches [en línea], [Fecha de consulta:
18/10/2014]. Disponible en:
http://wwwis.win.tue.nl/2R690/doc/ScrumAndXpFromTheTrenchesonline07-31.pdf

[14] Robert G. Dyson (2002). Strategic Development and SWOT Analysis. Disponible en:

http://web.archive.org/web/20120913032253/http://www2.egi.ua.pt/cursos/files/sad/strategic%2
0development%20and%20SWOT%20analysis.pdf

[15] Javier Garzas [en línea], [Fecha de consulta: 22/11/2016]. Disponible en:

http://www.javiergarzas.com/metodologias-agiles

[16] Sondra Ashmore and Kristin Runyan. Introduction to Agile Methods

Ashmore Ph.D., Sondra. Introduction to Agile Methods (p. 3). Pearson Education. Kindle
Edition.

[17] SATPATHY, Tridibesh (2016) Scrum Body of Knowledge. Arizona: SCRUMstudy

[18] Proyectos Agiles ORG. Garzas [en línea], (Consulta 22 de noviembre de 2016)

(https://proyectosagiles.org/2009/09/13/expendedor-juego-simulacion-scrum/)

[19] SCRUMstudy. SCRUM BODY OF KNOWLEDGE (SBOK Guide) (2016 Edition) [en
línea], (Consulta 30 de noviembre de 2016).

(http://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf)

3
[20] Cohn, Mike (2005). Agile Estimating and Planning (Robert C. Martin Series)

[21] MANIFESTO AGIL, 2014.

(Consulta 22 de noviembre de 2016) (https://manifesto.co.uk/agile-concepts-scrum-task-board/)

[22] Rocio Zelada (2013). Gestión de interesados según PMBOK. (Consulta 02 de Diciembre de
2016) (http://blog.rociozelada.com/2013/11/gestion-de-interesados-lo-que-todos.html)

[23] Ambler, Scott W. Agile modeling: effective practices for eXtreme programming and the
unified process. New York: Jhon Wiley & Sons, 2002 (005.1 AMBL)

[24] Equipo Editorial Buenos Negocios, 2016. 5 Actividades para fortalecer el trabajo en equipo
(Consulta 15 de Enero de 2017) (http://www.buenosnegocios.com/notas/254-5-actividades-
fortalecer-el-trabajo-equipo)

[25] BLOG Yovana. Tecnicas de trabajo Grupal. (Consulta 16 de Enero de 2017)


(http://tecnicasdetrabajogrupal.blogspot.pe/2010/05/objetivo-concientizar-el-grupo-en- el.html?
m=1)

[26] INNOCREATIVIDAD (2012). Técnica Creativa Brainstorming.

(Consulta 16 de Noviembre de 2017)(https://innocreatividad.com/2012/05/22/tecnica-creativa-


brainstorming/)

3
[27] estratecno (2015). Planning Poker: Como utilizar la técnica de estimacion. (Consulta 15 de
Enero de 2017) (http://www.estratecno.es/noticia/6/planning-poker-como-utilizar-la-tecnica-de-
estimacion-agil)

[28] John Hudson Tiner (2004). Exploring the world of Mathematics: From Ancients Record
Keeping to the Latest Advances in Computer. Master Books division of new Leaf Publishing
group. ISBN 9781614581550

[29] van Bon, J., ed. (2002). The guide to IT service management. Addison Wesley. ISBN 0-
201-73792-2

[30] De la Cruz, Angela; Cruz, Angela De la; Mauricio, David (2014). Una Revisión de la
Gestión de Servicios de Tecnologías de Información. Revista de investigación de Sistemas e
Informática 4 (1): 71-80. ISSN 1815-0268. (Consultado el 14 de marzo de 2016)

[31] IT Service Management Forum (2002). van Bon, J., ed. IT Service Management: An
Introduction. Van Haren Publishing. ISBN 90-806713-4-7. Emphasis added

[32] Marlon Molina (2014). Resumen de la Evolución de ITIL. (Consulta 20 de Enero de 2017)
(http://www.marlonmolina.com/2014/03/breve-resumen-de-la-evolucion-de-itil-e.html)

[33] Economipedia. Definición Valor Actual Neto (VAN) (Consulta 20 de Enero de 2017)

(http://economipedia.com/definiciones/valor-actual-neto.html)

[34] Economipedia. Definición Tasa Interna de Retorno (TIR) (Consulta 20 de Enero de 2017)

3
(http://economipedia.com/definiciones/tasa-interna-de-retorno-tir.html)

[35] Beck, Kent Andres, Cynthia Extreme programming explained: 2nd ed. Boston,
Massachusetts: Addison-Wesley, 2005. (005.1 BECK/X)

[36] Jim Highsmith (2000) New York. Adaptive Software Development: A Collaborative
Approach to Managing Complex Systems. New York: Dorset House, 392pp, ISBN 0-932633-
40-4

[37] Agile Business Consortium. What is DSDM (Consultado el 12 de Febrero de 2017)


(https://www.agilebusiness.org/what-is-dsdm)

También podría gustarte