Martinez NR
Martinez NR
Martinez NR
Rights info:eu-repo/semantics/embargoedAccess
FACULTAD DE INGENIERÍA
ASESORES:
SAMANTHA LÓPEZ
DANIEL SUBAUSTE
JAVIER LACHERRE
EDUARDO MENDÍVIL
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
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
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.
16
TOGAF1
Marco de trabajo cuyo enfoque otorga las bases para el diseño, implementación,
mantenimiento y gobierno de una arquitectura.
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]
18
Fase de ADM Actividad
4. Tecnología
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
19
Fase de ADM Actividad
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:
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.
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:
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]
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
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.
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:
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é impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteración y
en el proyecto?
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.
Los asistentes son el Equipo Scrum y los interesados clave invitados por el Dueño de
Producto;
El Equipo de Desarrollo habla acerca de qué fue bien durante el Sprint, qué problemas
aparecieron y cómo fueron resueltos esos problemas;
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,
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]
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].
Auto-gestionado
Auto-organizado
Multi-funcional
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]
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.
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.
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.
ITIL8
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]:
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
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].
Aumentar la eficiencia.
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
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.
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.
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.
Incrementar el ensamblaje de motos en un 10% por modelo con respecto al año 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.
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.
4
ORGANIGRAMA
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.
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 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.
BENEFICIOS INTANGIBLES.
Ventaja competitiva.
4
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL
INTRODUCCIÓN
ALCANCE
5
- Motores Estacionarios
- Generadores
- Moto bombas
- Moto guadañas
- Moto fumigadoras
5
PRELIMINAR
PRINCIPIOS DE ARQUITECTURA
5
Principios de Datos
Tabla 6 : Principios de Datos PRDAT01
5
Principios de Aplicaciones
Tabla 9 : Principios de Aplicaciones PRAPL01
Principios de Tecnología
Tabla 11: Principios de Tecnología PRTEC01
5
Tabla 12: Principios de Tecnología PRTEC02
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
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.
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.
Los principales problemas identificados en la organización dentro del análisis del proceso
actual son:
Los clientes no cuentan con la información del estado de su pedido, ni con una fecha de
entrega confiable para poder proyectarse.
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.
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.
- Motores Estacionarios
- Generadores
- Moto bombas
- Moto guadañas
- Moto fumigadoras
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.
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.
Una vez aprobado cada cambio, la solución pasa a formar parte del las responsabilidades
del equipo de proyecto.
Estado Analista
Transacción/Menú -
RFC Honda
Clasificación
6
Descripción del Cambio
Escenarios de Pruebas
Plan de Despliegue
Plan de Rollback
Aprobaciones
6
Roles, responsabilidades y entregables.
Roles
Arquitecto Informacion
Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades
6
Roles
Arquitecto Informacion
Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades
Definir procedimiento de R
cambios de alcance
6
Roles
Arquitecto Informacion
Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades
Base y Destino)
6
Roles
Arquitecto Informacion
Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades
Acta de Constitución R
6
Roles
Arquitecto Informacion
Arquitecto Tecnología
Arquitecto Negocio
Arquitecto Lider
Actividades
Plan de Gestión de R
Comunicaciones
Reunión de Seguimiento y R
Control
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.
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.
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:
El diagrama de actividades del modelo de negocio debe estar aprobado por el Arquitecto
Líder
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.
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 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.
7
CRONOGRAMA TENTATIVO
7
7
7
Fuente : Elaboración Propia
7
VISION DE LA ARQUITECTURA
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.
7
Lista de Interesados
7
Parte Interesada Necesidades Interés Poder
7
Parte Interesada Necesidades Interés Poder
Conocer el proceso de
implementación de la arquitectura,
validando sus fases.
7
Parte Interesada Necesidades Interés Poder
Creación y distribución de
estándares de desarrollo.
8
Parte Interesada Necesidades Interés Poder
8
Lista de asuntos / escenarios que deben abordarse
Duplicidad de Funcionalidades
8
ARQUITECTURAS (AS IS / TO BE)
ARQUITECTURA DE LA LINEA BASE (AS-IS)
ARQUITECTURA DE NEGOCIO (AS-IS)
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.
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.
8
Roles de Negocio : Matriz RACI (AS-IS)
ROLES
Representante de Despacho
Representante de Almacén
Gerente de Operaciones
Jefe de Planificacion
SAP Dealer Portal
Jefe Logistica
Planificador
ACTIVIDADES
Priorizar pedidos R C I
Recepcionar mercadería C R A
Despacho (Picking/Packing/Load) C R A
R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO
I: INFORMADO
8
ARQUITECTURAS DE SISTEMAS DE INFORMACIÓN (AS-IS)
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)
A continuación se indica una breve descripción de los aplicativos utilizados dentro de los
procesos seleccionados.
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.
9
ARQUITECTURAS TECNOLOGIA DE LA LINEA BASE (AS-IS)
A continuación se visualiza la tecnología actual del objeto de estudio.
Figura 23: Descripción de los Componente de Tec. Vs. Sistemas informáticos (AS-IS)
9
Plataforma de tecnología y su descomposición (AS-IS).
9
Comunicaciones físicas [RED] (AS-IS)
A continuación se muestra la estructura tecnológica de Honda del Perú
9
Especificaciones de hardware y red (AS-IS)
Figura 27: Especificaciones de hardware y red (AS-IS)
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
No se cuenta con alguna funcionalidad del ERP SAP para planificar eficazmente el
aprovisionamiento de productos para atender las necesidades del cliente.
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.
Principales requerimientos
Contar con una herramienta que permita gestionar y planificar efectivamente los BackOrder.
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.
9
ARQUITECTURA DE NEGOCIO DE DESTINO (TO-BE)
9
Figura 29: Niveles de recuperación de B/O
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.
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
1
Sub Procesos : Gestionar “RECUPERACION BACKORDER” (TO-BE)
1
Sub Proceso : “RECEPCIONAR MERCADERIA”
ROLES
Representante de Despacho
Representante de Almacen
Gerente de Operaciones
Jefe de Planificacion
SAP Dealer Portal
Jefe Logistica
Planificador
ACTIVIDADES
1
ROLES
Representante de Despacho
Representante de Almacen
Gerente de Operaciones
Jefe de Planificacion
SAP Dealer Portal
Jefe Logistica
Planificador
ACTIVIDADES
Recepcionar mercadería C R A
Despacho (Picking/Packing/Load) C R A
R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO
I: INFORMADO
1
ARQUITECTURAS DE SISTEMAS DE INFORMACIÓN (TO-BE)
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)
1
ARQUITECTURA DE APLICACIÓN DEL NEGOCIO DESTINO (TO-BE)
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.
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).
1
ARQUITECTURAS TECNOLOGIA (TO-BE)
Figura 39: Descripción de los Componentes de Tec. Vs. Sistemas informáticos (TO-BE)
1
Plataforma de tecnología y su descomposición (TO-BE)
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).
1
Especificaciones de hardware y red (TO-BE)
Figura 43: Especificaciones de hardware y red (TO-BE)
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.
1
GAP 1 : Actualizar “Listar pedidos B/O para planificación”.
Descripción de la brecha:
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.
Descripción de la brecha:
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.
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:
Descripción de la brecha:
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
1
Los GAP’s encontrados en la arquitectura de datos son los siguientes
Descripción de la brecha:
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:
Propuesta: Se actualizará entidad de datos para contar con la referencia del documento de
compra del abastecimiento de las necesidades de BackOrder.
Descripción de la brecha:
Propuesta: Se actualizará entidad de datos para contar con la referencia del documento de
compra del abastecimiento de las necesidades de BackOrder.
Descripción de la brecha:
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
Propuesta:Se actualizará entidad de datos para contar con la referencia del BackOrder
abastecidos.
GAP 8 : MKPF
(DocMaterial) Descripción de la
brecha:
Propuesta: Se actualizará entidad de datos para contar con la referencia del BackOrder
abastecidos.
Descripción de la brecha:
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.
Descripción de la brecha:
1
abastecimiento, ocasionando, demoras en el proceso de atención de pedidos comerciales
pendientes de atención.
Descripción de la brecha:
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.
1
OPORTUNIDADES Y SOLUCIONES
Desglose de la implementación de proyectos y cartera
1
CUADRO RESUMEN DEL PLAN DE MIGRACION
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].
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.
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.
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.
1
D04.- Ineficiencia en la planificación de abastecimiento de mercadería para cubrir
necesidades del sector local y externo (Repuestos).
D06.-Resistencia al cambio.
Una vez identificado estos puntos, se planteará como aprovechar las fortalezas y eliminar las
debilidades.
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).
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.
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.
1
Fortalezas Aprovechamiento
implicadas.
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
D05.- Poca comunicación entre los integrantes Realizar actividades para mejorar esta
del equipo. debilidad
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.
Problemas:
Perdida de posibles clientes, ya que se la competencia podría tener este factor como una
fortaleza.
Debilidad D02.- El área de sistemas no cuenta con una metodología de trabajo definida para
el desarrollo de los proyectos de Software.
Problemas:
1
Debilidad D03.- Constante rotación del personal, lo cual genera pérdidas de conocimiento.
Problemas:
Pérdida de conocimiento.
Tiempo en encontrar a nuevo personal que cumpla con las necesidades del rol requerido.
Problemas:
Contar con sobre stock por abastecimiento de productos con poca rotación generando gastos
por almacenaje.
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.
1
Tabla 22 : Tabla de Dinámicas Propuestas para mejorar Debilidades
Debilidades Dinámica Funcionamiento
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.
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.
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
Habilidades de Comunicación 4 3
Habilidades de negociación 5 4
Accesible 4 5
Proactivo 4 4
Orientado a objetivos 5 3
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 motivación 4 5
Líder de servicio 4 5
Solucionador de problemas 4 5
Habilidades de Coordinación 4 4
SCRUM TEAM
Tabla 25 : Tabla de criterios de selección de Scrum Team
Analista Funcional
Conocimiento scrum 3 1
1
Conocimiento técnico 3 2
Responsable 4 4
Desarrollador 1 y 2
Conocimiento scrum 2 0 1
Colaborativo 4 3 4
Conocimiento técnico 5 4 5
Responsable 5 5 5
Analista de Pruebas
Conocimiento scrum 1 3
Conocimiento en estándares de 2 5
programación.
1
Responsable 5 5
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]
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
Maximiza la rentabilidad
1
Puesto Rol Actividades
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:
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
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
1
Metodología Ventajas Desventajas Tipo de
Metodología
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.
1
Metodología Ventajas Desventajas Tipo de
Metodología
programación.
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.
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.
1
Criterio Descripción
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.
1
Criterio Descripción
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.
Criterio
Presupuesto disponible 1 5 4
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
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].
1
Condiciones Evaluativas Si (1)/No(0)
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.
Criterio
Presupuesto disponible 1 5 4
Necesidad de documentación 0 0 0
Personal necesario 5 1 2
Adaptabilidad, Respuesta a 1 5 4
cambios
TOTAL 8 16 14
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.
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
1
PRODUCT BACKLOG
1
Rol Historia Tareas a Ejecutar
de
Usuario
1
Rol Historia Tareas a Ejecutar
de
Usuario
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.
1
Rol Historia Tareas a Ejecutar
de
Usuario
1
Rol Historia Tareas a Ejecutar
de
Usuario
1
Rol Historia Tareas a Ejecutar
de
Usuario
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.
1
Funcionamiento:
Cada participarte selecciona la carta con que estima un elemento y la pone boca abajo.
- 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.
- Pedir al cliente o propietario del producto que descomponga el elemento y estimar cada
uno de los elementos resultantes.
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”
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 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 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 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.
1
CODIGO NECESIDAD VALOR COSTO SPRINT
5. Compra al Proveedor
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]
1
Tabla 37 : Tabla de Tareas de la primera Iteración - Sprint 1
Tiempo
SPRINT CODIGO NECESIDAD Tareas
(hrs)
Como Planificador, deseo poder visualizar Diseñar como se mostrará la información del listado de backorders 2
1
Tiempo
SPRINT CODIGO NECESIDAD Tareas
(hrs)
Pruebas unitarias 4
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)
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
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
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.
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
1
Scrum Taskboard Propuesto
1
Tabla 39 : Formato de Lista de Retrospectiva: Listado de aspectos a mejorar
RETROSPECTIVA
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
Mejorar las ventas de repuestos al exterior en un 20% con respecto al año Alta
1
Objetivos Estratégicos Orden
2016.
Disminuir los gastos por subcontratación en un 20% con respecto al año Baja
2016.
PRIORIDADES DE LA ORGANIZACION
A continuación se indican las prioridades de inversión de la organización:
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.
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.
D06.-Resistencia al cambio.
1
D07.-Baja capacidad de investigación
Análisis Externo
OPORTUNIDAD
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.
AMENAZA
A01.- Corrupción e impunidad crecientes en el sistema político y en el estado.
1
SERVICIOS DE NEGOCIO OFRECIDOS
A continuación se listan los servicios ofrecidos por la organización relacionados al proceso del
negocio.
1
Servicios Internos del Negocio
Tabla 43 : Servicios Internos del Negocio
Procesos de Negocio Servicios ofrecidos por el Negocio
Servicio de embalaje.
Servicio de transformación.
1
Procesos de Negocio Servicios ofrecidos por el Negocio
acreedores.
ESTRATEGIA DE TI
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.
1
PLANIFICACIÓN ESTRATÉGICA
SERVICIOS IDENTIFICADOS
1
Descripción de los Servicios
Tabla 48 : Ficha del Servicio [SINT001]
[SINT0001] Versión : 01
2
Tabla 49 : Table 1 : Ficha del Servicio [SEXT001] /
[SEXT0001] Versión : 01
Descripción Brindar el soporte necesario para garantizar la disponibilidad y continuidad del servicio.
Servicios de Soporte
Propietario TI / GMD
SLA SLA Servicio de Soporte y Mantenimiento ERP SAP Horas de <L – V>
Servicio
07:00am - 22:00hoas
Contacto
2
Requerimientos del Servicio Identificado
Tabla 50 : Ficha del Requerimiento [SINT001]
[RQ-SINT0001] Versión : 01
Alcances Brinda las herramientas necesarias para planificar y comprometer de forma automática
pedido comerciales pendientes de atender por falta de stock.
Objetivos Estratégicos Mejorar las ventas de autos en un 20% con respecto al año 2016.
2
pedido para reducir el tiempo de abastecimiento de mercadería.
2
Tabla 51 : Ficha del Requerimiento [SEXT001]
[RQ- SEXT0001] Versión : 01
Alcances Brindar el soporte necesario para garantizar la disponibilidad y 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.
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
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.
VAN
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
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 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.
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
2
Figura 63: Sustento de Egreso Recursos ITIL
2
Sustento de Egresos Mensual
A continuación se sustenta los egresos mensuales del servicio propuesto
Distribución de Egreso mensual por Soporte y Mantenimiento ERP SAP relacionado al servicio identificado :
2
Distribución de Egreso mensual por Servicio de Soporte ITIL relacionado al servicio identificado:
2
EVALUACION DE RIESGOS
A continua se visualiza la matriz de riesgos en la implementación del servicio identificado
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
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.
2
DISEÑO DEL SERVICIO
Numero de SLR
SLR0000048511
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.
Servicio que permite planificar y atender todos aquellos pedidos comerciales que quedaron pendientes por falta de
stock.
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.
Urgente X
Alta X
Media X
Baja X
Fecha de generación de Pedido pendiente – Fecha de atención Pedido pendiente <= 15 días
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
Tiempos de respuesta
Nivel de Inmediata < a 9 horas < a 27 horas < a 45 horas
prioridad
Urgente X
Alta X
Media X
Baja X
2
NIVEL DE SERVICIO OPERACIONAL
Tabla 55: Acuerdo de Nivel Operacional OLA
Acuerdos de Nivel Operacional (OLA)
Proveedor Interno TI
Vigencia Desde 2/01/2017 hasta que el cliente interno o proveedor desee modificarlo o sustituirlo.
Proveedor GMD
Plataforma/BD Linux
servicio.
Realizar copias de seguridad a las base de datos para evitar perdida de información.
Compromisos
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.
Disponibilidad 99 %
2
CONTRATOS DE PROVEEDORES (UNDERPINNING CONTRACTS)
Tabla 56 : Contrato de soporte de Terceros UC
Contrato de Soporte de Terceros
Teléfono: 2136300
Mail: info@gmd.com.pe
2
Soporte que brinda
Compromiso de Garantía
2
TRANSICION DEL SERVICIO
REQUERIMIENTO DE CAMBIO
Tabla 57 : Requerimiento de Cambio RFC
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
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.
Cualquier error en esta funcionalidad podría retrasar la entrega de los pedidos pendientes de atención
Escenarios de Pruebas
Plan de Despliegue
Plan de Rollback
2
Actividad Responsable Hora Inicio Hora Fin
Aprobaciones
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.
CIH001 Servidor Servidor SAP IBM AIX 5.3 – 7.1 Honda Brasil
Listado de CI – Software
A continuación se listan los elementos de configuración – Software relacionado al servicio
identificado.
CIH002
CIH003
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.
2
Conceptos Fundamentales
A continuación se indican los conceptos fundamentales relacionados al proceso de Gestión de
Portafolio del Servicio.
Objetivos
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.
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.
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
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.
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
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”.
Supervisor Financiero
Gestor de Portafolio
Promotor Comercial
Jefe de Sistemas
ACTIVIDADES
R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO ANTES DE HACER
I: INFORMADO DESPUES DE HACER
2
Métricas
A continuación se indican los KPI’s relacionados al proceso de “Gestión del Portafolio del
Servicio”.
2
Ficha de Lista de Servicios
Tabla 63: Ficha de Listado de Servicios
Código Servicio Versión Descripción Tipo Propietario Prioridad
Ficha de Servicio
Tabla 64: Ficha de Servicio
[Código de Servicio] Versión : <Nro >
Servicios de Soporte < Listado de Servicios de Soporte Prestados por Terceros Empresas necesarios para prestar el
servicio >
2
Propietario < Responsable del 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 >
2
Ficha de Requerimiento del Servicio
Tabla 65: Ficha de Requerimiento de Servicio
[RQ-Código de Servicio] Versión : <Nro>
Objetivos Estratégicos <Listado de Objetivos Estratégicos del Negocio a quien hace referencia el Servicio >
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.
2
Conceptos Fundamentales
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.
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
3. Identificar UCs
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
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.
7. Rechaza SLR
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.
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.
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.
(Stakeholders)
Jefe de TI
ACTIVIDADES
2
ROLES
(Stakeholders)
Jefe de TI
ACTIVIDADES
Aprobar SLA R R
R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
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
Cumplimiento de niveles de servicio Cantidad de servicios/ SLA’s que cumplen con los
niveles de servicio acordados
2
Fichas de Nivel de Servicio
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.
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
2
Ficha de Nivel de Servicio (SLA)
Tabla 70: Ficha de Acuerdo de Nivel de Servicio SLA/ Fuente: Elaboración Propia
Área
Responsable
Correo de contacto
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
Monitoreo de servicio
2
Ficha de Acuerso de Nivel Operacional (OLA)
Tabla 71: Ficha de Acuerdo de Nivel Operacional OLA
Cliente Interno
Proveedor Interno
Vigencia
Sistema/aplicativo
Proveedor
Descripción
Servidor
Plataforma/BD
Responsabilidades
Clientes Internos
Responsabilidades TI
Compromisos
Urgente
Alta
Media
Baja
2
Disponibilidad
Tiempo medio de
restauración
Mantenimiento
programado
Punto de contacto
2
Ficha de Contrato de Soporte de Tercero
Tabla 72:Ficha de Contrato con Terceros UC
Contrato de Soporte de Terceros
Razón Social:
Nro. R.U.C.:
Dirección:
Teléfono:
Nombres y Apellidos:
Cargo:
Correo Electrónico:
Nombres y Apellidos:
Cargo:
Correo Electrónico:
2
Compromiso de Garantía
2
DESCRIPCION DEL PROCESO GESTION DE CAMBIOS
A continuación se muestra la propuesta del flujo del proceso de Gestión de Cambio.
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.
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.
2
ECAB (Emergency Change Advisor Board)
Órgano interno que toma decisiones relacionadas con cambios de emergencia cuyo impacto es
significativo (naturaleza / urgencia).
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
La División de Desarrollo
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
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
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
ROLES
Promotor del cambio
Comite de Cambios
ACTIVIDADES
Solicitar Cambio I I R
2
Responsable de Gestión de Cambios
Corregir observaciones I I R
R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO ANTES DE HACER
I: INFORMADO DESPUES DE HACER
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).
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.
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.
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:
2
Convocatoria del Comité de Cambios:
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.
Discusión y consenso de RFCs analizadas por los miembros del Comité de Cambios
previamente a la reunión.
Aprobación de RFCS.
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.
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:
2
Porcentaje de solicitudes de Cambio (necesidades del negocio) efectuadas a tiempo.
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
Estado Analista
Transacción/Menú -
RFC Honda
Clasificación
2
Escenarios de Pruebas
Plan de Despliegue
Plan de Rollback
Aprobaciones
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.
2
Conceptos Fundamentales
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.
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.
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.
2
Tabla 73: Matriz RACI Activos de Servicio y Gestión de Configuración
ROLES
Supervisor de Infraestructura
Analista Técnico
ACTIVIDADES
R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO ANTES DE HACER
I: INFORMADO DESPUES DE HACER
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
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.
CIH001 Servidor Servidor SAP IBM AIX 5.3 – 7.1 Honda Brasil
CIH002
CIH003
2
DESCRIPCION DEL PROCESO DE GESTION DE INCIDENTES
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.
1. Reportar Ocurrencia
Usuario
2
1. El usuario reporta la ocurrencia de algún incidente. Continúa en el punto 2.
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.
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.
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. 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.
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. 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.
2
16. El analista de soporte de incidentes de 1er nivel cierra el ticket y finaliza el proceso.
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. 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. El analista de soporte de incidentes de 2do nivel actualiza ticket con acciones técnicas,
notifica el problema y finaliza el proceso.
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. 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
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.
ACTIVIDADES
Reportar Ocurrencia A R
Notificar Problema A I R
Notificar cambio A I R
2
ROLES
Documentar solución A R
Escalar de nivel A I R
Cerrar Ticket A I R
R: RESPONSABLE DE EJECUCION
A: AUTORIDAD
C: CONSULTADO ANTES DE HACER
I: INFORMADO DESPUES DE HACER
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.
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:
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.
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.
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
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
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..
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.
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.
Propuesta:
Teniendo el siguiente stock por cada fuente de abastecimiento para cubrir la necesidad por linea
de negocio indicado en el cuadro anterior.
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.
Figura 81: Abasteciento del 20% de Pedido Comerciales Pendientes en 1er año
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)
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
VAN
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
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
2
DESCRIPCION DEL ESQUEMA GRAFICO
2
DESCRIPCION DE BRECHAS DEL NEGOCIO
A continuación se describen las brechas que se mencionan en el esquema grafico de la estructura
propuesta:
Descripción de la Brecha:
Descripción de la Brecha:
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.
2
Descripción de la Brecha:
Descripción de la Brecha:
Descripción de la Brecha:
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.
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.
3
RECOMENDACIONES
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.
arquitectura empresarial.
VAN.- Valor actual neto, indicador financiero que determina la viabilidad de un proyecto.
3
BIBLIOGRAFÍA
(Consulta: 13 de Noviembre)
(Consulta: 14 de Noviembre)
(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.
[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
Ashmore Ph.D., Sondra. Introduction to Agile Methods (p. 3). Pearson Education. Kindle
Edition.
[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)
[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)
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