Propuesta de una arquitectura empresarial

para la empresa Adecco Perú S.A.

Item Type info:eu-repo/semantics/bachelorThesis

Authors Ramirez Larzo, Marco Antonio; Rojas Arellano, Cristhian

Alexander

Publisher Universidad Peruana de Ciencias Aplicadas (UPC)

Rights info:eu-repo/semantics/embargoedAccess

Download date 11/09/2021 06:12:27

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

 UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

FACULTAD DE INGENIERÍA

DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS

CARRERA DE INGENIERÍA DE SISTEMAS

PROPUESTA DE UNA ARQUITECTURA

EMPRESARIAL PARA LA EMPRESA ADECCO PERÚ
S.A.

PROYECTO PROFESIONAL PRESENTADO POR :

MARCO ANTONIO RAMIREZ LARZO
CRISTHIAN ALEXANDER ROJAS ARELLANO

PARA OPTAR POR EL TÍTULO DE INGENIERO DE SISTEMAS

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

Lima, marzo de 2017

Dedicamos el presente trabajo a nu estros seres queridos , quienes también se
verán impactados positivamente por este esfuerzo.

2
 AGRADECIMIENTOS

El equipo de trabajo dirige sus agradecimientos a todas las personas asociadas a la institución
que nos acogió, orientó y nos dio la oportunidad durante estos años de desarrollarnos
profesionalmente en la carrera de ingeniería de sistemas. Igualmente, no está demás
mencionar a todas aquellas personas ajenas a la institución, que con su cuota de experiencia
nos brindó su apoyo para poder afinar el presente trabajo profesional y las ideas aquí
expuestas. Esta dedicación conjunta nos sirvió como soporte para poder sostener la idea final,
darle forma y poder sustentarla como una opción de mejora al negocio objetivo seleccionado
y como iniciativa profesional con orientación firme.

3
TABLA DE CONTENIDO

CAPÍTULO 1: FUNDAMENTOS TEÓRICOS ...................................................................... 18

MARCO TEÓRICO............................................................................................................. 18
Arquitectura Empresarial ................................................................................................. 18
Métodos Ágiles para el desarrollo del Software .............................................................. 26
Historia de ITIL ............................................................................................................... 30
OBJETO DE ESTUDIO ...................................................................................................... 33
ORGANIZACIÓN OBJETIVO ....................................................................................... 33
MISIÓN ........................................................................................................................... 42
VISIÓN ............................................................................................................................ 42
OBJETIVOS ESTRATÉGICOS ...................................................................................... 42
ORGANIGRAMA ........................................................................................................... 45
ALCANCE DEL PROYECTO ........................................................................................ 49
OBJETIVOS DEL PROYECTO ......................................................................................... 50
OBJETIVO GENERAL ................................................................................................... 50
OBJETIVOS ESPECÍFICOS .......................................................................................... 50
BENEFICIOS DEL PROYECTO........................................................................................ 51
BENEFICIOS TANGIBLES ........................................................................................... 51
BENEFICIOS INTANGIBLES ....................................................................................... 51
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL ............................................................. 53
INTRODUCCIÓN ............................................................................................................... 53
ALCANCE ........................................................................................................................... 53
Amplitud .......................................................................................................................... 54
Profundidad ...................................................................................................................... 54
Periodo de Tiempo ........................................................................................................... 54
Dominios de Arquitectura ................................................................................................ 54
PRELIMINAR ..................................................................................................................... 55
Principios de Negocio ...................................................................................................... 56

4
 Principios de Datos .......................................................................................................... 57
Principios de Aplicaciones ............................................................................................... 59
Principios de Tecnología.................................................................................................. 60
Petición de Trabajo de Arquitectura ................................................................................ 61
Descripción de la situación actual del Negocio sobre el Proceso de Compras ................ 63
Descripción de la situación actual de la arquitectura/TI sobre el proceso de Compras ... 64
VISIÓN DE LA ARQUITECTURA ................................................................................... 66
Declaración de Trabajo de Arquitectura .......................................................................... 66
Roles, responsabilidades .................................................................................................. 69
Entregables ....................................................................................................................... 70
Estructura de Gobierno .................................................................................................... 71
Procesos del Proyecto ...................................................................................................... 72
Criterios de Aceptación.................................................................................................... 74
Cronograma tentativo....................................................................................................... 75
Interesados y sus preocupaciones .................................................................................... 76
Lista de asuntos / escenarios que deben abordarse .......................................................... 78
ARQUITECTURAS DE LA LÍNEA BASE (AS IS) .......................................................... 80
Arquitectura de Negocio de Línea Base .......................................................................... 80
Arquitectura de Sistemas de Información de Línea Base ................................................ 89
Arquitectura Tecnológica de Línea Base ......................................................................... 96
FUNDAMENTO Y JUSTIFICACIÓN DEL ENFOQUE ARQUITECTÓNICO............. 102
ARQUITECTURAS DE LA LÍNEA DESTINO (TO BE) ............................................... 103
Arquitectura de Negocio de la Línea Destino ................................................................ 103
Arquitecturas de Sistemas de Información de la Línea Destino .................................... 113
Arquitectura Tecnológica de Línea Destino .................................................................. 121
ANÁLISIS DE BRECHAS................................................................................................ 128
Proceso de Gestión de Compras .................................................................................... 128
Análisis de Brechas por Arquitectura de Negocio ......................................................... 129
Análisis de Brechas por Arquitectura de Datos ............................................................. 130
Análisis de Brechas por Arquitectura de Aplicación ..................................................... 131
Análisis de Brechas por Arquitectura de Tecnología .................................................... 132
Evaluación del Impacto.................................................................................................. 133

5
 OPORTUNIDADES Y SOLUCIONES ............................................................................ 138
Estructura de desglose del trabajo.................................................................................. 139
Cuadro resumen del plan de Migración ......................................................................... 140
CONCLUSIONES ............................................................................................................. 145
CAPÍTULO 3. MÉTODOS ÁGILES PARA EL DESARROLLO DE SOFTWARE .......... 146
INTRODUCCIÓN ............................................................................................................. 146
OBJETIVOS ...................................................................................................................... 146
OBJETIVOS DEL CAMBIO PARA EL PROCESO DE COMPRAS ......................... 147
BENEFICIOS DEL CAMBIO PARA EL PROCESO DE COMPRAS........................ 147
METODOLOGÍAS EVALUADAS .................................................................................. 148
SCRUM.......................................................................................................................... 148
KANBAN ...................................................................................................................... 160
COMPARATIVA ENTRE SCRUM y KANBAN ........................................................ 163
JUSTIFICACIÓN DE LA METODOLOGÍA ELEGIDA ............................................. 165
IDENTIFICACIÓN DE FORTALEZAS Y DEBILIDADES ........................................... 169
DIAGNÓSTICO DEL GRUPO ......................................................................................... 171
Diagnóstico y problemas identificados en el Proceso actual ......................................... 176
IDENTIFICACIÓN DE LAS DINÁMICAS PROPUESTAS ........................................... 178
EL SPRINT .................................................................................................................... 179
SPRINT PLANNING (Planeamiento del sprint) ........................................................... 180
SCRUM TEAM MEETING (Reunión de equipo de scrum) ......................................... 180
BACKLOG REFINEMENT (Refinamiento del backlog) ............................................. 180
SPRINT REVIEW (Revisión del sprint) ....................................................................... 181
RETROSPECTIVE (Retrospectiva del sprint) .............................................................. 181
DEFINICIÓN DE LAS HERRAMIENTAS A UTILIZAR .............................................. 181
Historias de Usuario /User Stories ................................................................................. 181
Backlog de Producto/Product Backlog .......................................................................... 186
Backlog del Sprint/Sprint Backlog ................................................................................ 187
El Panel de Tareas/The Taskboard ................................................................................ 190
COMPOSICIÓN DE LOS GRUPOS DE TRABAJO ....................................................... 192
TÉCNICAS E INSTRUMENTOS ..................................................................................... 198
DINÁMICA PARA ESTIMACIÓN DE TIEMPOS ..................................................... 198

6
 DINÁMICA PARA REUNIONES DE EQUIPO .......................................................... 199
DINÁMICA PARA HACER RETROSPECTIVAS ..................................................... 199
TABLERO SCRUM ...................................................................................................... 203
COSTOS PARA EL DESARROLLO DE SOFTWARE .................................................. 204
COSTOS PARA ENTRENAMIENTO DEL EQUIPO ..................................................... 205
CONCLUSIONES ............................................................................................................. 206
CAPÍTULO 4. GESTIÓN DE SERVICIOS EN TI............................................................... 207
INTRODUCCIÓN ............................................................................................................. 207
EVALUACIÓN ESTRATÉGICA ..................................................................................... 209
PLAN DE ACCIÓN ...................................................................................................... 209
ESTRATEGIA DE NEGOCIO...................................................................................... 210
ESTRATEGIA DE TI .................................................................................................... 212
Descripción del Servicio ................................................................................................ 213
PLANIFICACIÓN ESTRATÉGICA ................................................................................ 214
SERVICIOS IDENTIFICADOS ................................................................................... 214
REQUERIMIENTO DEL SERVICIO IDENTIFICADO ............................................. 219
EVALUACIÓN FINANCIERA .................................................................................... 223
EVALUACIÓN DE RIESGOS ..................................................................................... 229
DISEÑO DEL SERVICIO ................................................................................................. 234
REQUERIMIENTO DE NIVEL DE SERVICIO (SLR)............................................... 234
ACUERDO DE NIVEL DE SERVICIO (SLA) ............................................................ 237
NIVEL DE SERVICIO OPERACIONAL..................................................................... 245
TRANSICIÓN DEL SERVICIO ....................................................................................... 279
GESTIÓN DEL PORTAFOLIO DEL SERVICIO............................................................ 285
GESTIÓN DEL NIVEL DEL SERVICIO ........................................................................ 294
GESTIÓN DE CAMBIOS ................................................................................................. 303
GESTIÓN DE ACTIVOS Y GESTIÓN DE LA CONFIGURACIÓN ............................. 312
GESTIÓN DE INCIDENTES............................................................................................ 320
CONCLUSIONES ............................................................................................................. 330
CAPÍTULO 5: ESTRUCTURA PROPUESTA .................................................................... 331
INTRODUCCIÓN ............................................................................................................. 331
ESTRUCTURA PROPUESTA ......................................................................................... 332

7
 TRAZABILIZAD PARA LA PROPUESTA .................................................................... 332
DESCRIPCIÓN DEL MAPA DE TRAZABILIDAD ................................................... 334
EVALUACION DE RIESGOS ......................................................................................... 339
ANÁLISIS DE RENTABILIDAD .................................................................................... 342
CONCLUSIONES DE LA PROPUESTA ........................................................................ 346
CONCLUSIONES ................................................................................................................. 347
RECOMENDACIONES ........................................................................................................ 349
GLOSARIO DE TÉRMINOS................................................................................................ 350
SIGLARIO ............................................................................................................................. 353

8
ÍNDICE DE TABLAS

Tabla 1 - Lista de Frameworks de AE ..................................................................................... 20

Tabla 2 - Metodologías tradicionales vs metodologías Ágiles ................................................ 28
Tabla 3 - Matriz de Objetivos Estratégicos vs. Procesos de Negocio ..................................... 44
Tabla 4 - Principios de Negocio de AE ................................................................................... 57
Tabla 5 - Principios de Datos de AE ........................................................................................ 58
Tabla 6 - Principios de Aplicaciones de AE ............................................................................ 59
Tabla 7 - Principios de Tecnología de AE ............................................................................... 61
Tabla 8 - Roles y Responsabilidades de Arquitectura ............................................................. 69
Tabla 9 – Entregables de Arquitectura..................................................................................... 70
Tabla 10 - Procesos clave de Arquitectura .............................................................................. 73
Tabla 11 – Criterios de aceptación para entregables ............................................................... 74
Tabla 12 - Identificación de Interesados .................................................................................. 77
Tabla 13 - Matriz de Objetivos Estratégicos vs. Proceso de Negocio de Línea Base ............. 81
Tabla 14 - Matriz RACI del Proceso Compras de Línea Base ................................................ 88
Tabla 15 - Cuadro detalle de entidades de Línea Base ............................................................ 92
Tabla 16 - Matriz de Datos del Proceso vs Procesos del Negocio de la Línea Base ............... 93
Tabla 17 - Matriz de Aplicaciones Proc. seleccionado vs Proc. de Negocio Línea Base ........ 95
Tabla 18 - Especificaciones de Hardware y Red de Línea Base ............................................ 101
Tabla 19 - Matriz Objetivos del Negocio vs. Proceso seleccionado de la Línea Destino ..... 104
Tabla 20 - Matriz RACI de la Línea Destino ......................................................................... 112
Tabla 21 - Cuadro detalle de entidades de la Línea Destino.................................................. 117
Tabla 22 - Matriz Datos del Proceso vs Procesos del Negocio de la Línea Destino ............. 118
Tabla 23 – Matriz Aplicaciones del Proceso vs Procesos de Negocio Destino ..................... 120
Tabla 24 - Especificaciones de Red y Hardware de Línea Destino ....................................... 127
Tabla 25 - Matriz de Análisis de Brechas por Arquitectura de Negocio ............................... 128
Tabla 26 - Brechas identificadas por Arquitecturas de Negocio ........................................... 130
Tabla 27 - Matriz Análisis de Brechas por Arquitectura de Datos ........................................ 130

9
Tabla 28 - Brechas identificadas por Arquitectura de Datos ................................................. 131
Tabla 29 - Matriz de Análisis de Brechas por Arquitectura de Aplicación ........................... 131
Tabla 30 - Brechas identificadas por Arquitectura de Aplicación ......................................... 132
Tabla 31 - Matriz de Análisis de Brechas por Arquitectura de Tecnología........................... 132
Tabla 32 - Brechas identificadas por Arquitectura de Tecnología ........................................ 133
Tabla 33 – Cuadro resumen del plan de migración ............................................................... 140
Tabla 34 - Tablas de Estimación de Costos del Plan de Migración....................................... 144
Tabla 35 - Diferencias entre Scrum y Kanban ....................................................................... 164
Tabla 36 - Tabla cruce Fortalezas vs. Debilidades ................................................................ 170
Tabla 37 - Fortalezas y Debilidades de equipo ...................................................................... 174
Tabla 38 - Historias de Usuario ............................................................................................. 185
Tabla 39 - Backlog del Producto ........................................................................................... 187
Tabla 40 - Sprint Backlog (Iteración 1) ................................................................................. 189
Tabla 41 - Gobierno, Roles Scrum y habilidades a reforzar .................................................. 195
Tabla 42 - Propuesta para la evaluación de costos para los Sprint ........................................ 204
Tabla 43 - Costos para entrenamiento de equipo ................................................................... 205
Tabla 44 - Portafolio de Servicios Internos ........................................................................... 217
Tabla 45 - Portafolio de Servicios de Soporte ....................................................................... 218
Tabla 46 - Datos previos Adecco para Evaluación Financiera .............................................. 223
Tabla 47 - Datos usados para Evaluación Financiera del Proyecto ....................................... 224
Tabla 48 - Proyección de Ingresos (Revenue US$ Millones) ................................................ 225
Tabla 49 - Estimación de VAN y TIR del Proyecto .............................................................. 226
Tabla 50 - Matriz de Riesgos ................................................................................................. 233
Tabla 51 - CI´s Asociados al Hardware ................................................................................. 283
Tabla 52 - CI's asociados al Software .................................................................................... 284
Tabla 53 - Tabla detalle de trazabilidad ................................................................................. 338
Tabla 54 - Matriz de Riesgos de la propuesta ........................................................................ 341
Tabla 55 - Tabla de interpretación VAN y TIR ..................................................................... 344

10
ÍNDICE DE FIGURAS

Figura 1 - Evolución cronológica de los frameworks de Arquitectura Empresarial ................ 21

Figura 2 - Componentes de la AE ............................................................................................ 22
Figura 3 – Fases del Ciclo del ADM ....................................................................................... 24
Figura 4 - Ciclo de vida de los procesos ITIL ......................................................................... 31
Figura 5 - Mapa de Procesos Adecco Perú S.A. ...................................................................... 38
Figura 6 - Organigrama Adecco Perú ...................................................................................... 45
Figura 7 - Alcance ADM del Proyecto .................................................................................... 55
Figura 8 – Límite Organizacional de Adecco Perú S.A........................................................... 62
Figura 9 – Flujo para cambios de Alcance............................................................................... 67
Figura 10 – Solicitud para Cambio de Alcance en la Arquitectura ......................................... 68
Figura 11 – Estructura de Gobierno - Stakeholders ................................................................. 71
Figura 12 – Cronograma tentativo ........................................................................................... 75
Figura 13 - Matriz Interés vs. Poder ........................................................................................ 78
Figura 14 – Proceso de negocio de compras ............................................................................ 82
Figura 15 – Diagrama de Actividades de Compras Internas de Línea Base ............................ 84
Figura 16 – Diagrama de Actividades de Compras Externas de Línea Base ........................... 86
Figura 17 - Modelo de Datos de Línea Base............................................................................ 90
Figura 18 – Diagrama de Aplicaciones de Compras de Línea Base ........................................ 94
Figura 19 – Componentes de Tecnología y los Sistemas de información de Línea Base ....... 96
Figura 20 – Plataforma de tecnología y su descomposición de Línea Base ............................ 98
Figura 22 - Diagrama de Red de Línea Base ........................................................................ 101
Figura 23 – Proceso de Compras de la Línea Destino ........................................................... 105
Figura 24 – Proceso de Compras Internas de la Línea Destino ............................................. 106
Figura 25 – Proceso de Compras Externas de la Línea Destino ............................................ 109
Figura 26 - Modelo de Datos de Línea Destino (Microsoft Dynamics GP) .......................... 114
Figura 27 - Modelo de Datos de Línea Destino (Nueva Plataforma) .................................... 115
Figura 28 – Diagrama de Aplicación de Gestión para Compras de la Línea Destino ........... 119

11
Figura 29 – Componentes de tecnología y Sistemas de información de Línea Destino ........ 121
Figura 30 – Plataforma de tecnología y su descomposición de Línea Destino ..................... 124
Figura 31 – Ambientes y ubicaciones informáticas de Línea Destino................................... 125
Figura 32 - Diagrama de Red de Línea Destino .................................................................... 127
Figura 33 – Estructura de desglose del trabajo ...................................................................... 139
Figura 34 - Visión general del proceso SCRUM ................................................................... 150
Figura 35 - Roles Scrum ........................................................................................................ 154
Figura 36 - Modelo de Tuckman ........................................................................................... 155
Figura 37 - Ejemplos de Kanban Board ................................................................................. 162
Figura 38 – Escala prescriptiva/adaptativa de algunas metodologías .................................... 165
Figura 39 - Matriz FODA ...................................................................................................... 169
Figura 41 - Agility Calculator ................................................................................................ 172
Figura 42 - Proceso general de atención a Nuevos Requerimientos ...................................... 175
Figura 43 - Equipos Scrum para un proyecto ........................................................................ 178
Figura 44 - Sprint de cuatro semanas ..................................................................................... 179
Figura 45 - Scrum Taskboard ................................................................................................ 191
Figura 46 - Características deseadas de los roles principales de Scrum ................................ 193
Figura 47 - Descripción general de los roles de Scrum ......................................................... 194
Figura 48 – Estimación online con Planitpoker ..................................................................... 198
Figura 49 - Dinámicas para retrospectivas ágiles - Barco de vela ......................................... 201
Figura 50 – Grafico Radar ..................................................................................................... 202
Figura 51 – Trello - Herramientas para uso del tablero Scrum.............................................. 203
Figura 52 – Modelo de gestión de TI basado en ITIL ........................................................... 208
Figura 53 - Identificación de servicios internos del proceso de gestión de compras ............. 212
Figura 54 - Identificación de los servicios internos y de soporte de gestión de compras ...... 215
Figura 55 - Proceso de Gestión del Portafolio del Servicio ................................................... 293
Figura 56 - Proceso de Gestión del Nivel de Servicio ........................................................... 298
Figura 57 - Proceso de Gestión del Cambio .......................................................................... 307
Figura 58 - Proceso de Gestión de Activos de Servicio y Gestión de la Configuración ....... 316
Figura 59 - Proceso de Gestión de Incidentes ........................................................................ 324
Figura 60 - Mapa de Trazabilidad.......................................................................................... 333
Figura 61 - Gráficos de progreso VAN y TIR ....................................................................... 342

12
Figura 62 - Gráfico del Punto de Equilibrio .......................................................................... 345

13
 RESUMEN

El presente trabajo profesional desarrolla la propuesta de una Arquitectura Empresarial para

cubrir la necesidad de mejora del proceso de compras en la empresa Adecco Perú. Para
concretar este análisis, se desarrolla una estructura estratégica definida en los ámbitos
relacionados a la práctica de Arquitectura Empresarial, Métodos Ágiles y la Gestión de
Servicios para TI.

La necesidad del estudio, análisis y desarrollo del trabajo profesional se sostiene con la
puesta en práctica de las habilidades académicas adquiridas por los autores y con el apoyo de
metodologías, herramientas y buenas prácticas para proponer una solución a la problemática
identificada en el objeto de estudio.

El planteamiento del objetivo general y los específicos del proyecto sostienen la propuesta de
cambio en la forma actual de ejecutar el proceso de compras, identificando mejoras,
incrementando el grado de satisfacción de los clientes internos y externos de la organización
y brindando el soporte tecnológico a las soluciones planteadas. El cumplimiento de estos
objetivos determina el éxito de la presente propuesta y de su relevancia dentro del objeto de
estudio.

Acerca del desarrollo, el primer capítulo abarca la fundamentación teórica de la propuesta e

información de la organización objetivo. El segundo capítulo cubre el desarrollo de
Arquitectura Empresarial bajo el marco de trabajo TOGAF. El tercer capítulo define el
análisis necesario para cerrar las brechas identificas en el capítulo anterior mediante un
software cuya propuesta se apoya en una metodología ágil. El cuarto capítulo establece el
diagnóstico de la gestión de servicios de TI para soportar la propuesta de un producto
software con la aplicación de las mejores prácticas de ITIL.

Finalmente, el quinto capítulo describe de manera estructurada y consolidada la propuesta de

una Arquitectura Empresarial para la empresa Adecco Perú S.A. con el sustento de los
resultados obtenidos en los capítulos anteriores y poder cerrar las brechas que impiden
cumplir con los objetivos estratégicos.

14
 INTRODUCCIÓN

Adecco Perú S.A. desde su proceso de TI, así como las organizaciones con una clara
estrategia de tecnología y las desarrolladoras de software en general, conocen que un buen
producto o entregable radica en la efectividad del relevamiento, de una correcta gestión del
proceso de software y del apoyo de metodologías que aseguren una mejora continua, ya que
existe una correlación directa entre la calidad de todo el proceso y la del producto obtenido a
partir de éste.

El presente trabajo profesional está enfocado en la necesidad de replantear la ejecución del

proceso actual de compras, sobre la base del análisis resultante de la Arquitectura
Empresarial propuesta para la empresa Adecco Perú S.A. con la finalidad de alinear los
objetivos y estrategias de negocio con las tecnologías de información. Los objetivos de su
elaboración se sustentan en conseguir un planteamiento comprobable y viable, dando uso a
un conjunto de metodologías, marcos de trabajo y buenas prácticas que permitan demostrar
que las conclusiones en torno al análisis sobre el proceso objetivo, sostienen una
argumentación razonable para proponer la ejecución de la Arquitectura Empresarial.

El objeto de estudio es Adecco Perú S.A. subsidiaria de Adecco Group, multinacional

consultora dedicada a la gestión y consultoría en Recursos Humanos que ofrece una cartera
de servicios especializados orientados a atender esta necesidad a las empresas clientes que lo
requieran. Este conjunto de soluciones centra sus operaciones en el ámbito de Lima
Metropolitana. Adecco Perú S.A. enfoca sus esfuerzos para llevar a cabo una política
agresiva de expansión y consolidación hacia el interior del país.

15
Para la presentación de la propuesta, se desarrolla en el primer capítulo el levantamiento de
información y análisis del proceso, donde refleja la existencia de una marcada problemática
para poder disponer de información confiable, oportuna y relevante para la toma de
decisiones informadas, específicamente identificada en el proceso de compras que merma el
cumplimiento de las estrategias de la organización. Frente a estas necesidades del proceso, se
propone una solución fundamentada por el marco teórico y que presenta las bases sobre las
que se sostiene esta propuesta.

El segundo capítulo presenta la aplicación de arquitectura empresarial donde el marco de

trabajo de referencia es TOGAF, que nos permite relevar y aterrizar toda la información de
negocio y de tecnología orientada hacia una estrategia clara para lograr proponer soluciones.
Una de las principales motivaciones de su aplicación, es lograr el alineamiento negocio con
TI para facilitar el cumplimiento de la estrategia corporativa. Esto se alcanza siguiendo un
análisis minucioso de la situación actual y la esperada, para posteriormente identificar las
brechas, problemas y plantear las soluciones en beneficio del proceso objetivo.

Sobre el tercer capítulo, establecida ya la base arquitectónica, surge la necesidad de cerrar las
brechas identificadas y para ello se propone el desarrollo de un software con una
planificación y dinámica de trabajo respaldada por la metodología ágil seleccionada, que de
acuerdo a resultados de la evaluación es SCRUM. Este marco de trabajo propone las pautas y
lineamientos para la generación del software esperado, donde se recogen las oportunidades de
mejora y cambios en los flujos de información necesarios, automatizando los procedimientos
manuales existentes y aplicando las mejores prácticas, para proponer la resolución de los
problemas de compras y poder contribuir al logro de los objetivos estratégicos de la
compañía. La correcta realización de las dinámicas y herramientas permiten contemplar la
adopción fija de este marco de trabajo para proyectos futuros, además de fortalecer las
debilidades identificadas del grupo de trabajo en su desenvolvimiento actual.

16
En el cuarto capítulo se establece una propuesta para la gestión de servicios en TI a través de
ITIL y poder soportar los servicios de implementación del software identificado. Cada uno de
los procesos establecidos y su correcta gestión permiten al planteamiento actual asegurar la
efectividad y la eficiencia en la ejecución de los servicios identificados. Es importante
conocer, que sobre el presente capitulo se realiza la evaluación financiera de la propuesta
actual, que permite responder a las dudas de viabilidad o cuestionamientos referidos sobre su
planteamiento y puesta en marcha desde la perspectiva financiera.

Finalmente, el quinto capítulo presenta la propuesta estructurada e integradora de los

capítulos de Arquitectura Empresarial, Metodologías Ágiles y Gestión de Servicios en TI
sobre un esquema que demuestra la correcta trazabilidad en la consecución de los objetivos
establecidos. Este capítulo resulta de vital importancia, ya que muestra la dinámica
integradora utilizada y los resultados que se esperan obtener para beneficio de la
organización.

Esta propuesta apoya el logro de los objetivos estratégicos de la organización Adecco Perú
S.A. y de la estrategia corporativa global, mediante la solución a las dificultades actuales del
proceso de compras y, por consiguiente, proponer un cambio metodológico y cultural en la
gestión y desarrollo para este tipo de planteamientos e iniciativas de mejora.

17
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS

MARCO TEÓRICO

Arquitectura Empresarial
La Arquitectura Empresarial (AE) es una metodología que, basada en una visión integral de
las organizaciones, permite alinear procesos, datos, aplicaciones e infraestructura tecnológica
con los objetivos estratégicos del negocio o con la razón de ser de las entidades. 1 De acuerdo
a esta definición, se entiende que debemos tener una visión macro capaz de integrar las
fuentes indicadas que generan valor en las organizaciones y obtener un resultado a partir del
ordenamiento requerido para buscar el cumplimiento y soportar el plan estratégico de las
entidades.

Según Cobo Ortega Ángel, Vanti Adolfo (2015) [1] indica también, “La AE podría definirse
además como la organización lógica de los procesos de negocio, información y capacidades
TI que se reflejan en la integración y estandarización de requerimientos del modelo de
negocios de la compañía.”

Para buscar consolidar los conceptos de AE y redondear la idea, Zea Restrepo Claudia,
Atuesta V. María (2007) [2] indican en su compilación “El concepto de arquitectura
empresarial surge con el propósito de proveer un marco de trabajo unificado en el que
confluyen tanto los intereses de una organización (objetivos, actores, procesos e
infraestructura organizacional), como las estrategias de TI (software, datos, infraestructura
tecnológica) que apalancan y soportan los procesos y lineamientos de la organización”.

El concepto de arquitectura empresarial se remonta hacia el año 1987 con la publicación de J.

Zachman en el diario IBM Systems cuyo título fue: “Un marco para la arquitectura de
sistemas de información.” Según establece Arango Martín, Londoño Jesús y Zapata Julián

1
Definición obtenida de la revista CIO@GOV No.2, publicación del Ministerio TIC de Colombia (2013)

18
(2010) [3] basados en la publicación de J. Zachman (1987) “En este documento, Zachman
establece tanto el desafío como la visión de la arquitectura empresarial, que sirve para
orientarla durante los siguientes años y hasta nuestros días. En esencia, el reto consistía en
administrar la creciente complejidad que representaba el surgimiento de información,
soportados en sistemas computacionales”. Según J. Zachman (1987) [4] “El éxito del negocio
y los costos que ello conlleva dependen cada vez más de sus sistemas de información, los
cuales requieren de un enfoque y una disciplina para la gestión de los mismos”. Este enfoque
fue influyente para uno de los primeros intentos que realizó el Departamento de Defensa de
los Estados Unidos para crear Arquitectura Empresarial, siendo conocido como “Technical
Architecture Framework for Information Managment - TAFIM” siendo publicado en 1994.
En 1998, el “CIO Council” consejo creado para la supervisión de la ley “Reforma a la
Gestión de las Tecnologías de la Información” por el congreso de los Estados Unidos, cambia
el nombre al modelo de referencia de AE “TAFIM” por “FEAF – Federal Enterprise
Architecture Framework”, siendo publicado en el año 1999. Una nueva dependencia del
gobierno de los Estados Unidos “OMB – Office of Managment and Budget”, en el año 2002,
termina de renombrar a este framework como “FEA- Federal Enterprise Architecture”,
conservándose a la fecha. The Open Group, en el año 1995, retoma el trabajo realizado por
TAFIM y crea el nuevo framework “TOGAF – The Open Group Architectural Framework”
la cual llega a su versión 9.1. Sobre el 2005, la OMB de los Estados Unidos con su
framework FEA, se convierte en el estándar para las empresas del sector gubernamental. Por
este mismo año, Gartner Group, adquiere Meta Group y publica su propio modelo de
referencia “GEAF – Gartner Enterprise Architectural Framework”. Todas estas publicaciones
y generación de marcos propios de trabajo dirigían su aplicación sobre entidades
gubernamentales de los Estados Unidos, donde solo a partir del año 2003 aparecen versiones
comerciales desarrolladas de otros frameworks de arquitectura, siendo adoptadas por distintas
industrias en el mundo. Algunas que se pueden resaltar bajo este contexto son: Zachman,
TOGAF 8.0, E2AF, FEAF, DoDAF (Departamento de Defensa de los Estados Unidos).2

2
Resumen cronológico adaptado de “Arquitectura empresarial – Una visión general” - Universidad de Medellín

19
Zachman Zachman Framework for Enterprise Architeture

http://www.zachman.com/

E2AF Extended Enterprise Architecture Framework

http://www.enterprise-architecture.info/

TOGAF The Open Group Architecture Framework

http://www.opengroup.org/subjectareas/enterprise/togaf

GEAF Gartner Enterprise Architecture Framework

https://www.gartner.com/doc/486650/gartners-
enterprise-architecture-process-framework

FEAF Federal Enterprise Architecture Framework – U.S.

https://www.whitehouse.gov/omb/e-gov/FEA

Tabla 1 - Lista de Frameworks de AE

Fuente: Adaptación de “Arquitectura Empresarial – Una visión general” [3]

Se plasma la evolución cronológica de los frameworks de Arquitectura Empresarial en la

siguiente ilustración:

20
 Figura 1 - Evolución cronológica de los frameworks de Arquitectura Empresarial
Fuente: Adaptación de “Arquitectura Empresarial – Una visión general” [3]

A continuación, se presentan los componentes en los que se soporta la Arquitectura

Empresarial con una breve descripción de cada una de ellas:

21
 Figura 2 - Componentes de la AE
Fuente: Adaptación de Colombia Digital del gráfico desarrollado por Amazing Consultores

Cada uno de estos pilares genera un conjunto de artefactos relacionados de especificaciones

integradas, incluyendo tablas, matrices, gráficos, documentos textuales entre otros. Según
DAMA International (2015) [5] “Estos describen como la organización funcional y consume
recursos en diferentes grados de detalle. Las especificaciones se deben alinear con metas y
objetivos que apoyan y cumplen los estándares empresariales de contenido y presentación.
Pocas organizaciones tienen una arquitectura empresarial que incluye cada componente
potencial y artefacto”.

Asimismo, DAMA International (2015), resuelve a la arquitectura empresarial como “un

importante activo de conocimiento que proporciona varios beneficios.” Define a la AE como
una herramienta de planificación, gobierno de TI y gestión de cartera. Estos beneficios se
traducen en los siguientes puntos:

22
 Habilitar la integración de datos, procesos, tecnologías y esfuerzos.
 Alinear los sistemas de información con estrategias de negocios.
 Activar la coordinación y uso eficaz de recursos.
 Mejorar la comunicación y entendimiento a través de la organización.
 Reducir el costo de gestión de infraestructura de TI.
 Guiar la mejora de procesos de negocio.
 Habilitar a las organizaciones para responder eficazmente a las oportunidades de
mercado.

Para la ejecución de esta metodología y los lineamientos planteados se hace uso del marco de
arquitectura TOGAF que a continuación se detalla.

TOGAF
Como indica Andrew Josey (2013) [6] “TOGAF es un marco de referencia de arquitectura.
En términos simples, TOGAF es una herramienta para asistir en la aceptación, creación, uso
y mantenimiento de arquitecturas. Está basado en un modelo iterativo de procesos apoyado
por las mejores prácticas y un conjunto reutilizable de activos arquitectónicos existentes.”

Como se revisó anteriormente la AE estaba conformada por 4 pilares Arquitectónicos (Datos,

Negocio, Aplicación y Tecnológica), estos son cubiertos en desarrollo por TOGAF.

El componente principal de TOGAF es el ADM (Método de Desarrollo de la Arquitectura) y

como eje central proporciona la manera de obtener la Arquitectura Empresarial específica a la
empresa objetivo y poder responder a los requerimientos del negocio. El ADM describe:

 Un modo confiable y probado para desarrollar y utilizar una AE.

 Un método para desarrollar arquitecturas en diferentes niveles (pilares arquitectónicos)
que permiten asegurar que un conjunto complejo de requerimientos se aborde de manera
exitosa.
 Un conjunto de guías y técnicas para el desarrollo de arquitectura. 3

3
Puntos basados de la documentación TOGAF® Versión 9.1

23
A continuación, se detallan y describen brevemente las fases que comprenden el ADM para
obtener el desarrollo de la Arquitectura esperada:

Figura 3 – Fases del Ciclo del ADM

Fuente: TOGAF® Versión 9.1 – Guía de Bolsillo

Fase Preliminar
Preparación de la organización. Comprende la iniciación y preparación requeridas para crear
la capacidad arquitectónica adaptando TOGAF, además se realiza la selección de
herramientas y definición de principios de arquitectura.

24
Fase Visión de Arquitectura
Establece alcance, limitaciones y expectativas del proyecto. Identifica interesados, valida el
contexto del negocio y genera el Statement of Architecture Work.

Fases Arquitectura de Negocio, Sistemas de Información y Tecnológica

Desarrolla las arquitecturas en los siguientes dominios: Negocio, Sistemas de Información –
Aplicaciones, Sistemas de Información – Datos, Tecnología. Para cada caso analiza el AS IS
y el TO BE, encontrando las brechas entre ambas.

Fase Oportunidades y Soluciones

Abarca la planificación de la implementación 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.

Fase Planificación de la Migración

Desarrollo del plan detallado de implementación y migración que indica como pasar de la
Arquitectura AS IS a la Arquitectura TO BE.

Fase Gobierno de la Implementación

Brinda supervisión arquitectónica para la implementación. Genera los contratos de
Arquitectura. Asegura que la implementación se encuentre acorde a lo planteado en la
Arquitectura.

Fase Gestión de Cambios de la Arquitectura

Proporciona seguimiento y proceso de gestión de cambios para asegurar que la arquitectura
responda a la estrategia de la empresa y se maximice el valor generado para el negocio.

25
Métodos Ágiles para el desarrollo del Software

Las metodologías para desarrollo de software analizadas para este proyecto están
representadas por un conjunto de procedimientos, herramientas, técnicas, y entregables
documentados que permiten contribuir con el equipo de trabajo. Estas metodologías están
representadas por las metodologías tradicionales y las metodologías ágiles:

Metodologías Tradicionales: Estas metodologías exigen un riguroso cumplimiento de

disciplinas durante los procesos de desarrollo del software, para garantizar un producto
eficiente. Para ello, se dedica muchos esfuerzos durante la planificación del proyecto y luego
se inicia el desarrollo del software. Una metodología tradicional centra sus esfuerzos en el
control del proceso con una adecuada definición de roles, actividades, herramientas,
entregables y definición de notaciones estandarizadas, de acuerdo a lo sostenido por Marcela
Daniele. [7]

Metodologías Ágiles: Estas metodologías soportan flexibilidad para adaptarse a la realidad

de cada equipo y proyecto. Existe comunicación constante con el cliente (requiere un
representante de él durante el desarrollo). Exige equipos altamente colaborativos y adaptables
a cambios frecuentes (cambios de alcance en los requerimientos), ciclos cortos para los
entregables y la retroalimentación por parte del cliente. Es aplicado al producto y al proceso
que permite una mejora continua, de acuerdo a los sostenido por Santanu Ghosh. [8]

El Manifiesto Ágil: Durante el año 2001 se crea el Manifiesto por el desarrollo ágil de
software, documento en el que se acuerdan cuatro principios básicos para el desarrollo de
software, que establece prioridades y marca diferencias de fondo frente a los sistemas tradi-
cionales: individuos e interacciones, por encima de procesos y herramientas; software
funcionando, por encima de documentación extensiva; colaboración con el cliente, por
encima de negociación contractual; y respuesta ante el cambio, por encima de seguir un plan,
según lo establecido en el Manifiesto Ágil. [9]

26
Los 12 principios del Manifiesto Ágil de Fowler y Highsmith (2001) son los siguientes:

1) Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua

de software con valor.

2) Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los
procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3) Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con
preferencia al periodo de tiempo más corto posible.

4) Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana

durante todo el proyecto.

5) Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y
el apoyo que necesitan, y confiarles la ejecución del trabajo.

6) El método más eficiente y efectivo de comunicar información al equipo de desarrollo y

entre sus miembros es la conversación cara a cara.

7) El software funcionando es la medida principal de progreso.

8) Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores

y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9) La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10) La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11) Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12) A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a
continuación ajustar y perfeccionar su comportamiento en consecuencia.

27
 Metodologías Tradicionales versus Metodologías Ágiles

Tradicionales Ágiles
Predictivos Adaptativos
Orientados a procesos Orientados a personas
Proceso rígido Proceso flexible
Se concibe como un proyecto Un proyecto es subdividido en varios
proyectos más pequeños
Poca comunicación con el cliente Comunicación constante con el cliente
Entrega de software al finalizar el Entregas constantes de software
desarrollo
Documentación extensa Poca documentación
Tabla 2 - Metodologías tradicionales vs metodologías Ágiles
Fuente: Revisión de metodologías ágiles para el desarrollo de software [10]

Justificación de la metodología elegida: El acelerado desarrollo de software y la pronta

entrega del proyecto dirigido al proceso de compras para la compañía Adecco Perú, es una
necesidad donde además se exige la culminación exitosa para un producto software de gran
valor alineado a los objetivos estratégicos de la organización, es muy importante que los
equipos cumplan sus objetivos. Debido a ello, es de vital importancia la selección de una
metodología ágil específica, robusta y flexible para que el equipo cumpla las metas, y
satisfaga más allá de las necesidades definidas al inicio del proyecto. La complejidad del
sistema a desarrollar, la complejidad del proceso de compras, la cantidad de requisitos y
cantidad de datos administrados para este proceso, son también factores para valorar durante
la elección de la metodología ágil especifica.

A continuación, los factores específicos para decidir por una la metodología ágil:

 El cambio de alcance: Con los ciclos de planificación cortos para las entregas, resulta
fácil de incluir y aceptar cambios en cualquier momento durante el proyecto. Se garantiza

28
 la oportunidad para mejorar y cambiar las prioridades de los requerimientos, puesto que el
proceso de compras puede incluir nuevos alcances por cambios en las normativas legales
y/o tributarias.

 Entregables rápidos y con alta calidad: Las iteraciones (unidades manejables) permite
al equipo centrarse en el desarrollo y pruebas de alta calidad. La realización de las
pruebas durante cada iteración identifica los bugs de aplicación tempranamente y serán
resueltos con rapidez. Ello como respuesta al proceso de compras que requiere cuanto
antes validar y utilizar el software desde la primera iteración.

 Fuerte interacción del equipo: Se ve valorado la comunicación frecuente y las

interacciones cara a cara. El equipo es capaz de asumir responsabilidades y serán piezas
claves durante el proyecto para responder inquietudes de cualquier interesado del
proyecto para el proceso de compras.

 Stakeholders siempre informados: El dueño de procesos de compras, directivos y

auditores, tendrán muchas oportunidades de ver el trabajo que se entregó, comparten sus
opiniones sobre algún impacto real en el producto final. Ellos ganan sentido de propiedad
cuando el dueño del proceso trabaje estrechamente con el equipo del proyecto.

 La mejora continua: El proyecto adopta el espíritu ágil para fomentar la

retroalimentación de los usuarios del sistema y los miembros del equipo durante el
proyecto, donde las lecciones aprendidas se utilizan para mejorar las futuras iteraciones.

29
Historia de ITIL
Se considera a ITIL como un marco de referencia cuyo contenido describe las mejores
prácticas como recomendaciones para la adecuada administración de los servicios de
tecnologías de información en las organizaciones dirigidos a la administración de procesos
con los esfuerzos orientados hacia la satisfacción del usuario. ITIL se desarrolló en el Reino
Unido a partir de un mandato del gobierno británico que determinó una comisión para
investigar una manera de alinear las posibilidades de TI para optimizarlas y hacerlas
eficientes. A inicios de la década de los noventa, este marco ya había influido sobre las
entidades del gobierno y las organizaciones privadas de algunos países europeos y
americanos. Este éxito motivo a la comisión responsable del desarrollo a continuar con las
mejoras y de esta manera surgieron nuevas versiones de ITIL que, desde su desarrollo inicial,
contó con el apoyo de IBM, PA Consulting, CSC y ICL. Gracias al aporte de estas
compañías, ITIL logró mejorar la calidad de los servicios de TI. [24]

La compañía Pink Elephant desde 1989, se interesó en comprender ITIL para luego
difundirlo a nivel mundial y convertirse en el número uno como proveedor mundial de
educación, conferencias y servicios de consultoría de ITIL e ITSM. Pink Elephant ahora es
propietario de los estándares de ITIL y de sus actualizaciones, ofrece la certificación
PinkVERIFY con reconocimiento mundial por su alta exigencia alineada a la optimización de
servicios de TI y se otorga a las compañías que ofrecen servicios de TI y logran la aprobación
de esta evaluación. [24]

“ITIL es hoy en día una necesidad, y se ha expandido a muchos países y a muchos ámbitos
organizacionales. Ofrecer servicios de TI que cuenten con la garantía de una certificación
también es indispensable, pues como todo lo que crece tanto, ITIL también puede desviarse
de su visión original. Este proyecto que empezó hace 25 años es ahora parte del servicio de
TI en todo el mundo.”4

4
Referencia obtenida de © Dexon Software Posted In: Basic concepts, Certifications, ITIL marzo 10 – 2015, en
http://dexon.org/?p=515

30
Ciclo de vida del Servicio ITIL
El ciclo de vida del servicio consta de cinco fases que corresponden con los actuales libros de
ITIL® y se citan de manera breve a continuación:5

1) Estrategia del Servicio: propone tratar la gestión de servicios no sólo como una capacidad
sino como un activo estratégico.
2) Diseño del Servicio: cubre los principios y métodos necesarios para transformar los
objetivos estratégicos en portafolios de servicios y activos.
3) Transición del Servicio: cubre el proceso de transición para la implementación de nuevos
servicios o su mejora.
4) Operación del Servicio: cubre las mejores prácticas para la gestión del día a día en la
operación del servicio.
5) Mejora Continua del Servicio: proporciona una guía para la creación y mantenimiento del
valor ofrecido a los clientes a traces de un diseño, transición y operación del servicio
optimizado.

Figura 4 - Ciclo de vida de los procesos ITIL

Fuente: Ciclo de vida de los procesos ITIL - SAT Microsystems© 2015

31
Definición de Servicio
De acuerdo a lo establecido por Kotler Philip, Armstrong Gary (2003) [25], los servicios son
“actividades o beneficios que se ofrecen a la venta y que son básicamente intangibles y no
tienen como resultado la propiedad de algo. Como ejemplo podemos citar los servicios de los
bancos, líneas aéreas, hoteles, contadores y técnicos que reparan aparatos domésticos.” Bajo
esta definición, es necesario entender el contexto de negocio sobre el que se desarrolla
Adecco Group a nivel mundial y específicamente sobre el objeto de estudio en el país.

El ámbito de desarrollo de los servicios otorgados por Adecco Perú gira sobre 2 entornos
específicos, el interno y el externo, y para ello es necesario definir el elemento principal de
estos entornos, tales como los clientes a quienes se les brinda este servicio. Es así que Juran
J.M. [26], nos ayuda a definir a los clientes bajo estos entornos de la siguiente forma:

Clientes Externos: “Se utiliza aquí para designar a las personas u organizaciones que no
forman parte de nuestra empresa, pero sobre quienes repercuten nuestras actividades.”
Además, es necesario indicar que son la razón de ser del negocio y cuyo aseguramiento de su
satisfacción depende el éxito de los ingresos de la compañía.

Clientes Internos: “Se utiliza aquí para designar a los que forman parte de nuestra empresa y
sobre los que también repercuten nuestras actividades.” Adicionalmente, se puede indicar que
resultan siendo el soporte de las actividades realizadas por el negocio para la generación de
los servicios otorgados por Adecco y cuyo desempeño, con las herramientas indicadas,
aseguran el éxito de la ejecución de los servicios.

5
Fases referenciadas de http://itilv3.osiatis.es/ciclo_vida_servicios_TI.php

32
OBJETO DE ESTUDIO
El objeto de estudio del presente trabajo profesional es la empresa Adecco Perú S.A., cuya
información organizacional se aborda en los elementos siguientes.

ORGANIZACIÓN OBJETIVO
La empresa Adecco Perú forma parte de Adecco Group siendo este último el proveedor líder
mundial en soluciones de Recursos Humanos sustentadas en las siguientes cifras: atención
diaria a 700,000 personas para encontrar oportunidades de trabajo en la red actual de 28,000
empleados a tiempo completo y contando con 5,500 sucursales en 60 países alrededor del
mundo6.

A nivel nacional, Adecco Perú cuenta con divisiones de negocio especializadas con más de
600 compañías clientes en sus 15 años de experiencia local. Cuenta con certificación ISO
9001 y es miembro de la Asociación de Buenos Empleadores.

Adecco Perú S.A. ofrece nuevas líneas de negocio soluciones orientadas a la atención de los
sectores minería, hidrocarburos y energía. Su presencia está posicionada actualmente en 10
departamentos representativos de dichos sectores donde se prestan servicios para atender las
demandas operativas y de gestión que requieren los clientes. Adecco Perú con miras a
sostener su crecimiento vienen ejecutando un conjunto de estrategias que le permitan
consolidar un crecimiento sostenido al interior del país.

Acerca del ámbito de servicios y soluciones, Adecco Perú ofrece un servicio integral en el
área de Recursos Humanos, con el compromiso de proveer soluciones eficaces y
competitivas. A continuación, se brinda una vista rápida de las soluciones que se ofrece.

6
Cifras obtenidas del boletín corporativo en www.adecco.com

33
 Intermediación Laboral

Esta es una herramienta que le brinda mayor flexibilidad a las empresas, permitiéndole
destacar personal a realizar labores temporales, complementarias y/o especializadas,
ajustándose al marco normativo local vigente. Esta flexibilidad también le permite adaptar su
planilla a la temporalidad de contratación de personal.

Esto resulta un reductor de tiempo y de costes derivados de los procesos de:

 Reclutamiento
 Selección
 Contratación
 Proceso de nómina
 Contingencias laborales
 Termino de contrato laboral

Outsourcing de Procesos

Busca aportar los recursos y los medios técnicos y humanos necesarios para la correcta
realización del servicio subcontratado, responsabilizándose globalmente de la actividad. Bajo
este concepto se tienen los siguientes tipos:

 Outsourcing Industrial
Se implementan y ejecutan los procesos y sub procesos, relacionados con las áreas de
logística, producción, mantenimiento y manufactura; mediante las líneas de negocio en:
industria, minería y cleaning.

 Outsourcing de Ventas
Especialización en los servicios de promoción, impulso y fuerza de ventas, gestionando de
manera eficiente su canal presencial de ventas y alcanzando el logro de sus objetivos en picos
de campaña.

34
 Permanent Placement

División enfocada en reclutamiento, selección y evaluación de personal que ofrece una

estrategia de búsqueda personalizada en función al volumen del requerimiento y
especialización de cada perfil solicitado.

Los servicios se encuentran enfocados en:

 Selección de personal
o Personal de Soporte Operativo.

o Personal Administrativo y Técnico.

o Profesionales.

o Posiciones de Coordinación y Supervisión.

o Jefaturas.

 Evaluación de personal
 Assessment center
 Outsourcing de selección de personal

Adecco Professional

De acuerdo a las características del perfil requerido, Adecco ofrece un canal de búsqueda y
metodología de selección de personal para las posiciones más exigentes, especializadas y
estratégicas del mercado, con las siguientes consideraciones:

Segmentación de perfiles:
 Adecco Professional

o Posiciones Middle Management:

 Jefaturas

35
  Gerencias medias

 Adecco Executive

o Posiciones Top Management:

 Altas gerencias y posiciones directivas

Líneas de especialización

Administración y Finanzas

Marketing y Ventas

Producción y Operaciones

Minería y Energía

Human Capital Solutions

Se ofrecen soluciones integrales para el desarrollo del talento humano, de acuerdo a los
siguientes servicios:

 Consultoría

Descripción de Puestos

Perfiles por Competencias

Evaluación por Competencias

Escala Salarial

Clima Laboral

 Formación

36
 o Talleres In Company
o Teambuilding y Outdoor Training
o Cine Foro
o Coaching Ejecutivo y Coaching de Equipos
o Talleres E-Learning
o Talleres Abiertos al Público
o Eventos Especiales
o Plan de Capacitación

Payroll

Servicio especializado a través del cual se delega la administración de la nómina de la

empresa (cliente), sin perder el control ni flexibilidad de la misma. Los procesos involucrados
se manejan con la confidencialidad en el manejo de la información y atención personalizada.
Este servicio se encuentra a cargo de especialistas constantemente actualizados sobre los
cambios en la legislación laboral e impositiva. Los servicios ofrecidos:

 Outsourcing de Nóminas

 Auditoría de Recursos Humanos

 Outsourcing de Nóminas Contratas

37
A continuación, se muestra un mapa de los procesos del objeto de estudio que van a soportar
las soluciones ofrecidas.

Figura 5 - Mapa de Procesos Adecco Perú S.A.

Fuente: Sistema de Gestión de Calidad Adecco Perú S.A.

Descripción del Mapa de Procesos de Adecco Perú S.A.

Se resalta con líneas punteadas de color rojo, el proceso de soporte “Compras” que pertenece
al objeto de estudio.

Gestión de la Mejora: En este proceso estratégico Adecco desarrolla continuamente sus

actividades en búsqueda del mejoramiento del sistema de gestión de calidad (SGC) y de sus
procesos. Como fuentes de alimentación para la mejora continua de Adecco se consideran, la
revisión anual del Sistema de Gestión de la Calidad y lo que ello comprende, auditorías
internas y externas, análisis de datos y las medidas correctivas y preventivas.

38
Gestión Financiera: Este proceso es el responsable de conseguir, mantener y utilizar
financiamiento, sea físico o a través de cheques, tarjetas de crédito u otros instrumentos. Este
proceso se convierte en la visión y misión en operaciones monetarias y del manejo crítico de
las finanzas de la empresa.

Planeamiento Estratégico: El planeamiento estratégico en Adecco es un proceso que se

mantiene unido al equipo empresarial para traducir la misión, visión y estrategias en
resultados tangibles.

Auditoría Interna: Adecco realiza auditorías internas con el propósito de establecer y

asegurar el cumplimiento de las disposiciones planificadas que se alinean con la Norma ISO
9001:2008 y los propios establecidos por la organización.

Asesoría Legal: Este proceso brinda a la compañía la posibilidad de absolver las consultas en
temas diversos, como son: contratos, cumplimiento de obligaciones, declaratorias de
inmuebles, separación de bienes, etc.

Atención al cliente: En este proceso Adecco crea una serie de procedimientos ágiles y
flexibles que permiten facilitar la tarea de atención al cliente para evitar causar problemas
sobre la base de desarrollar una adecuada capacidad de reacción ante situaciones de conflicto.

Satisfacción del cliente: En este proceso, el analista de organización y métodos es

responsable de evaluar la satisfacción de los clientes de los diferentes servicios ofrecidos por
Adecco. Las respuestas obtenidas para cada encuesta son comunicadas a los gerentes de
sucursal para la elaboración del Plan de Acción. El Director General, define actividades de
mejora en base a los resultados obtenidos del análisis de satisfacción, canalizado a través de
planes de trabajo, medidas correctivas u otros medios.

Gestión Comercial: En este proceso se garantiza la buena relación entre Adecco y sus
canales de ventas. El objetivo de este proceso es maximizar el resultado de la compañía,
vendiendo la mayor cantidad de servicios, para el mayor número de clientes y al precio que
maximice el margen de utilidad esperado. Este objetivo se busca con mínimo costo y de
manera sostenible a largo plazo. Se realiza el seguimiento de los indicadores del proceso
comercial a través del CRM, por cada gerente de sucursal y ejecutivo comercial.

39
Selección de personal: En Adecco este proceso es considerado como uno de los elementos
centrales de la estrategia empresarial. Semanalmente, se reporta en el informe de dotación el
estatus de los procesos, emitiendo los tiempos de cobertura de primera fase y de cobertura
total que permiten cubrir esta necesidad de selección continua. El administrador clave de la
cuenta maneja como indicador el nivel de rotación mensual.

Outsourcing de Nóminas: Este proceso dirige sus esfuerzos para satisfacer las necesidades
de todo tipo de compañías para que se ocupe en la gestión y control de sus nóminas de
personal.

Consultoría y Formación: Adecco desde este proceso, oferta servicios de consultoría

especializada en las distintas estructuras organizacionales y formación de equipos laborales.
Se ocupa de temas directamente relacionados a fortalecer habilidades y mejorar la
productividad de las personas para un mercado en constante crecimiento y en busca de
especialistas.

Facturación: Este proceso constituye parte de un conjunto de procesos de negocio que

incluyen la colocación y aceptación de una orden, el procesamiento de la orden, la entrega de
la mercancía y el pago final por la venta de bienes o servicios.

Tesorería: Desde este proceso se gestionan las tareas y procedimientos relacionados con las
operaciones de flujos monetarios. Incluye la administración del flujo de caja chica, así como
de las distintas operaciones bancarias para pago de nóminas, pago de tributos, etc.

Comunicaciones internas y externas: Desde este proceso se gestionan las comunicaciones

internas (dirigida a empleados, dirección, representantes laborales, las sucursales, los
accionistas, etc.) y las comunicaciones externas dirigidas hacia el mercado (público,
profesionales, proveedores) y entorno social (gobierno, financiero y opinión pública).

Gestión Humana: Desde este proceso se asigna personal competente a las diferentes
actividades de Adecco en el Perú en base a su formación, experiencia laboral, habilidades y
entrenamiento, basando su incorporación con el cumplimiento de la descripción de puesto.

40
IT: Procesos ocupados en la gestión de tecnologías de la información. Está agrupado en tres
niveles: Estratégico (procesos de estrategia y gobierno de TI), Operativo (gestión de la
demanda, proyectos, aplicaciones, explotación, infraestructura y servicio) y Soporte
(procesos transversales de soporte, monitorización y de gestión de proveedores).

SSOMA (Seguridad, Salud Ocupacional y Medio Ambiente): Es el proceso responsable de

dar a conocer y hacer cumplir a los empleados, las normas y el programa de seguridad, salud
ocupacional y medio ambiente que rige en las áreas, sucursales y operaciones, así como
también los procedimientos de seguridad para la clase de trabajo que se ejecuta y velar
también por el cumplimiento de estas.

Contabilidad: La finalidad básica del proceso contable es suministrar información para

analizar, interpretar y poder tomar decisiones. Registra y procesa todas las operaciones que se
realizan en Adecco, desde donde se siguen procedimientos relacionados unos con otros y
secuenciales en cada ciclo contable.

Cobranzas: En este proceso se asegura la eficiencia de las cobranzas en Adecco, traducido

en menores plazos de cobro. Se encarga de la comunicación con los clientes en caso de
presentarse retrasos en las cobranzas respectivas.

Compras: Este proceso contempla la aplicación de procedimientos para compras a nivel de

servicios (externo) y para personal interno. Adecco considera crítica la adquisición de
productos o servicios para sostener el desarrollo y entregas de calidad a sus clientes. Para
asegurar la calidad de las prestaciones, los proveedores asociados pasan por un proceso de
evaluación y de calificación anual. Estos procesos se encuentran descritos en la “Guía de
Selección y Calificación de Proveedores” y son controlados por el Jefe de Compras.

41
 MISIÓN

“Identificar y desarrollar personas para acompañar y satisfacer las necesidades de nuestros

interlocutores (clientes - candidatos - trabajadores - proveedores - accionistas), brindando
soluciones de capital humano, empleabilidad y trabajo que impacten en forma positiva y
generen efectividad en las organizaciones, basándonos en los valores que guían nuestro
actuar.”7

VISIÓN

“Alcanzar y mantener una posición de liderazgo en nuestros negocios, con un sólido y

sustentable desempeño, con base en la excelencia y calidad del servicio que ofrecemos,
superando las expectativas de nuestros asociados-clientes, nuestra gente, accionistas y la
comunidad en la que vivimos y nos desenvolvemos.”8

OBJETIVOS ESTRATÉGICOS

Se plantean los siguientes objetivos estratégicos dentro de la organización objetivo y

seguidamente se presenta la Matriz Objetivos vs. Procesos planteados:

 OE1: Optimizar los procesos de servicios, mejorando la calidad y distribución de estos a

través de la aplicación de mejoras al SGC y el cumplimiento de los indicadores actuales.

7
Fuente: www.adecco.com alineado a la estrategia corporativa global
8
Fuente: www.adecco.com alineado a la estrategia corporativa global

42
 OE2: Facilitar la disposición de mejores herramientas a los colaboradores para crear una
cultura empresarial ágil, sostenible y responsable, incrementando la inversión en estos
medios en un 45%.

 OE3: Consolidar las nuevas líneas de negocio al interior del país de manera sostenible,
incrementando la cobertura actual en un 30%.

 OE4: Incrementar el valor de los accionistas y de las utilidades en un 15% para el

ejercicio en curso.

 OE5: Participar activamente en la estructuración de un modelo de negocio sostenible para

el cliente sosteniendo el 85% del indicador del SGC.

 OE6: Conservar la fidelidad de los clientes actuales e incrementar la cartera de los

mercados objetivos identificados en un 15%.

 OE7: Fortalecer y ampliar los canales de comunicación interna para la recepción y

retroalimentación correcta a consultas, quejas, reclamaciones como fuente principal de
información y de mejora reduciendo el indicador de incidencias al 10%.

 OE8: Incrementar la inversión en un 25% destinada a capacitación, mejorando la

satisfacción de los colaboradores, aumentando los incentivos trimestrales y el paquete de
beneficios actual con alianzas estratégicas.

Luego de establecer los objetivos estratégicos de la organización y mostrar sus procesos en

diferentes niveles: estratégicos, operativos y de soporte, se plantea la matriz de justificación
de Objetivos Estratégicos versus Procesos.

43
 Procesos de la Organización
Estratégicos Operativos Soporte

Seguridad, Salud Ocupacional y

Operaciones de Outsourcing

Administración de Personal

Comunicaciones Internas y
Planeamiento Estratégico

Outsourcing de Nóminas
Consultoría y Formación

Satisfacción del Cliente

Selección de Personal
Gestión de la Mejora
Gestión Financiera

Atención al Cliente

Gestión Humana
Auditoría Interna

Medio Ambiente
Asesoría Legal

Contabilidad
Facturación

Cobranzas
Tesorería
Temporal

Compras

Externas

IT
Objetivos Estratégicos de la Organización
Financiero

Incrementar el valor de los accionistas y de las utilidades en un 15% para el ejercicio en curso. X X X X X X X X X

Participar activamente en la estructuración de un modelo de negocio sostenible para el cliente sosteniendo el

X X X X
85% del indicador del SGC.
Cliente

Conservar la fidelidad de los clientes actuales e incrementar la cartera de los mercados objetivo identificados en
X X X X X X X X X X
un 15%.
Optimizar los procesos de Servicios, mejorando la calidad y Distribución de estos a través de la aplicación de
X X X X X X X
mejoras al SGC y el cumplimiento de los indicadores actuales.
Fortalecer y ampliar los canales de comunicación interna para la recepción y retroalimentación correcta a
consultas, quejas, reclamaciones como fuente principal de información y de mejora reduciendo el indicador de X X X X X
Interno

incidencias al 10%.
Facilitar la disposición de mejores herramientas a los colaboradores para crear una cultura empresarial ágil,
X X X X X X X X
sostenible y responsable, incrementando la inversión en estos medios en un 45%.
Consolidar las nuevas líneas de negocio al interior del país de manera sostenible, incrementando la cobertura
X X X X X X X
actual en un 30%.
Aprendizaje y
Crecimiento

Incrementar la inversión en un 25% destinada a capacitación, mejorando la satisfacción de los colaboradores,

X X X X
aumentando los incentivos trimestrales y el paquete de beneficios actual con alianzas estratégicas.
TOTAL OBJETIVOS CUBIERTOS 5 1 3 1 0 7 2 3 3 5 3 1 5 3 2 3 2 1 1 2 1

Tabla 3 - Matriz de Objetivos Estratégicos vs. Procesos de Negocio

Fuente: Elaboración Propia

44
ORGANIGRAMA

Figura 6 - Organigrama Adecco Perú

Fuente: SGC - Gestión Humana - Organigrama General 2016

45
Descripción del Organigrama

El Director General. – Encargado de organizar, mandar, coordinar y controlar las

actividades de la organización.

Asistente de Dirección. - Es el apoyo del Director General, es el enlace entre el Director y

los equipos gerenciales y directivos. Presenta informes periódicos acerca de los avances de la
compañía.

Auditor Interno. - Es el profesional que trabaja continuamente en el ámbito interno de la

empresa. Identifica áreas de mejora, prioriza acciones de optimización, establece políticas y
procedimientos, apoya a la Dirección General en la búsqueda de alternativas factibles para
alcanzar los objetivos estratégicos de Adecco.

Jefe de Marketing. - Responsable de diseñar e implementar el plan de marketing, definir las

estrategias de marketing para la oferta de servicios que vende Adecco, analizar las acciones
del departamento y evaluar y controlar los resultados de las mismas.

Gerente de TI. - Es la persona responsable de la gestión de la plataforma tecnológica de

Adecco, optimiza las capacidades del negocio mediante el uso de tecnologías de información
y resuelve las necesidades informáticas mediante la coordinación y la planificación
estratégica.

Gerente de HR (Gestión Humana). – Encargado de los procesos de gestión del recurso

humano en la organización. Otra condición especial a mencionar es que en Adecco se tiene
dispersión geográfica, es por ello que esta posición tiene la tarea estratégica de actuar como
enlace entre el área recursos humanos, los empleados y la línea de mando.

Legal. – Actualmente, esta terciarizado y cumple la función de aplicar las leyes vigentes, así
como también las disposiciones, normas y procedimientos internos de Adecco con el
propósito de representarla en cualquier acto legal, de tal manera que se garantice la
protección de sus intereses y buen funcionamiento.

46
Director de A&F (Administración y Finanzas). - Es el responsable de asegurar el
cumplimiento de los principios de administrativos y contables, mantener y cumplir los
lineamientos del Sistema de Gestión de la Calidad y velar el cumplimiento de las normas de
la organización.

Director Comercial. - Es la persona responsable de gestionar los diferentes canales

comerciales, reclutar, seleccionar y formar al personal de ventas para que consigan los
objetivos de revenue trazados por la organización.

Director Adecco Outsourcing. - Responsable de llevar a cabo la implantación, prospección

y desarrollo de negocio de la división de Outsourcing y de todas las operaciones de esta línea
de negocio en el Perú.

Director de Selección, Bienestar y Desarrollo. - Responsable de la selección y contratación

de personal idóneo según el perfil del puesto, en coordinación permanente con las unidades
orgánicas solicitantes de personal. Propicia el clima y ambiente favorable para el desarrollo
del personal trabajador de Adecco.

Director Adecco Professional. - Es el responsable de la adecuada gestión de la división

especializada en la búsqueda, reclutamiento y evaluación de personal de nivel medio,
ejecutivo y altas gerencias, que cuenta con el soporte de un equipo con experiencia en
selección de competencias.

Gerente Región Lima. - Responsable de garantizar la implementación y ejecución de todas

las estrategias de venta de la compañía, mediante acompañamiento, desarrollo, seguimiento y
medición de acciones de la fuerza de ventas para mantener los presupuestos de la
organización en la región Lima.

Gerente Región Provincias. - Responsable de garantizar la implementación y ejecución de

todas las estrategias de venta de la compañía, mediante acompañamiento, desarrollo,
seguimiento y medición de acciones de la fuerza de ventas para alcanzar los objetivos de la
organización en las distintas locaciones al interior del Perú.

47
Gerente Sales & Marketing y BPO. - Es el responsable de ofrecer crecimiento de primera
línea a través de la venta de servicios y la optimización de canales, con el apoyo del área de
marketing y la gestión de procesos de negocio de outsourcing.

Gerente Industria & Facility Management. - Es responsable de la gestión de los servicios

que suelen dividirse en gestión de servicios para clientes del rubro industrial y dirigido a
clientes consumidores de servicios de facility management (ejemplo servicios de
mantenimiento de infraestructura de inmuebles, etc).

Gerente Minería Hidrocarburos & Energía. - Es responsable de la gestión de los servicios

dirigidos a los clientes que pertenecen al rubro de minería, hidrocarburos y energía con el
objetivo de impulsar el inicio de proyectos mineros de gran envergadura en la economía
nacional y regional.

Gerente Grupo Gloria. - Es el responsable de la gerencia de la división para clientes del

rubro industrial, que, debido a la gran envergadura, complejidad en los procesos e
importancia de esta cartera, tiene responsabilidades asociadas para destinar mejores
capacidades de gestión y asegurar poder brindar su atención con detalle y exclusividad.

Gerente de Payroll. - Esta gerencia lidera el equipo de trabajo priorizando la entrega de altos
estándares de servicio de nóminas construyendo relaciones positivas hacia los clientes. Tiene
el desafío de generar una plataforma de servicios sólida que permita mejorar los servicios de
PayRoll.

Gerente de HCS (Human capital solution). – Gestiona los procesos de búsqueda de

ejecutivos y reclutamiento profesional con el propósito de generar un valor significativo a
través de su plataforma de negocios. Proporciona a las organizaciones clientes, soluciones
estratégicas y tácticas para sus propósitos.

48
ALCANCE DEL PROYECTO

El alcance se orienta en la evaluación del Proceso de Compras de la organización Adecco

Perú S.A. Esta evaluación inicial se lleva a cabo usando el marco de referencia TOGAF y que
sitúa como eje central al Método de Desarrollo de Arquitectura (ADM). El desarrollo de la
Arquitectura Empresarial establece la realización del análisis necesario para asegurar el
alineamiento del proceso indicado y su soporte tecnológico con la estrategia de negocio.

Además, se establece la selección de un método ágil para el desarrollo del software

propuesto. Esto conlleva ejecutar el análisis de la situación actual de la fábrica de software de
Adecco y la orientación de su alineamiento a esta metodología. Se desarrollan los cambios
necesarios para adoptar el marco de desarrollo seleccionado.

Asimismo, la Gestión de los Servicios de TI deben estar alineados a alcanzar los objetivos
corporativos, dando uso al marco propuesto por ITIL y al conjunto de procesos que establece
para asegurar la ejecución correcta de los servicios identificados en la propuesta.

Finalmente, se consolida una propuesta que busca la implementación de los cambios

tecnológicos y de negocio necesarios para aportar a los objetivos estratégicos locales y
sostener la estrategia corporativa global.

49
 OBJETIVOS DEL PROYECTO

OBJETIVO GENERAL
Proponer una arquitectura empresarial para la empresa Adecco Peru S.A. con el propósito de
mejorar el proceso de compras y permitir el cumplimiento de los objetivos estratégicos
impactados directamente mediante la implementación de un software y soportado por la
gestión de los servicios de TI.

OBJETIVOS ESPECÍFICOS
 Utilizar el marco de trabajo TOGAF solo hasta la quinta fase del método ADM, para
poder establecer la Arquitectura Empresarial dentro de los plazos estipulados.

 Identificar las brechas resultantes luego del análisis ASIS y TOBE del proceso de
compras para reconocer los problemas como oportunidades de mejora y proponer
soluciones potenciales a través de una cartera de proyectos que aborden la problemática.

 Realizar la evaluación de metodologías ágiles para integrar a la propuesta actual y cubrir

los aspectos metodológicos del desarrollo de software que permitan cerrar las brechas
identificadas.

 Evaluar y proponer las herramientas relacionadas a la aplicación correcta de la

metodología ágil elegida para permitir el desarrollo del grupo de trabajo y garantizar el
cumplimiento de sus funciones.

 Realizar la evaluación y planificación estratégica de los servicios brindados por el

proceso de TI con la aplicación de las mejores prácticas propuestas por ITIL.

 Justificar la viabilidad de inversión de esta propuesta mediante la evaluación de

parámetros financieros y el análisis de rentabilidad resultante.

50
 BENEFICIOS DEL PROYECTO
Se identifican los siguientes beneficios resultantes de la ejecución del proyecto. Estos se
dividen en las siguientes categorías considerando aspectos cuantitativos y cualitativos
respectivamente.

BENEFICIOS TANGIBLES
 Reducción de un 55% del tiempo total de gestión de compras regulares, permitiendo
ofrecer agilidad en la atención requerida por los clientes.

 Cumplimiento en el plazo de 30 días como máximo, estipulado por política, para el pago
de proveedores, salvaguardando la relación con los mismos e indirectamente con el
cliente.

 Eliminación de las órdenes de compra por regularización y tratamiento como órdenes de

pago permitiendo suprimir el sobre esfuerzo generado en los recursos y lograr tener
visibilidad de este tipo de procesos para tomar decisión.

 Lograr que las compras por el flujo negociado representen hasta un 90% del total de
compras estableciendo acuerdos contractuales por precios negociados con los
proveedores.

BENEFICIOS INTANGIBLES
 Satisfacción para los clientes externos e internos de la organización.

 Incrementar la productividad a través de la reestructuración del flujo de atenciones por

regularización de compras.

 Mejorar las relaciones con los proveedores de la organización, especialmente los que se
encuentran alejados en operaciones de provincias.

 Incrementar la productividad a través de la automatización del flujo de compras

negociadas con los proveedores.

51
 Mejorar la interacción de los roles responsables con los procedimientos de compras.

 Propiciar al proceso de compras el poder de negociación con los proveedores por

volumen de compra, aprovechando oportunidad de ahorro en las operaciones.

52
CAPÍTULO 2: ARQUITECTURA EMPRESARIAL

INTRODUCCIÓN
En este capítulo se describen los elementos básicos desde el punto de vista conceptual,
necesarios para poder definir el modelo general del “framework de arquitectura” con la
utilización del marco de trabajo TOGAF que permite proponer, como resultado del análisis
realizado, la implementación de Arquitectura Empresarial (AE) sobre el proceso de compras,
identificado como uno de los procesos de soporte de la organización Adecco Perú. Se inicia
con la Fase Preliminar donde se define el ámbito de la organización, luego desde la Fase de
Visión de Arquitectura, se establece el proyecto de arquitectura junto con el alcance de la
iniciativa de la AE, posterior a ello, desde las siguientes fases Arquitectura de Negocios,
Arquitectura de Sistemas de Información y Arquitectura de Tecnología se presenta la
arquitectura de línea base y se propone la arquitectura de destino, mediante el análisis de
brechas y finalmente desde la Fase Oportunidades y Soluciones, se define la planificación de
la arquitectura objetivo, la arquitectura de transición y la estrategia de alto nivel para la
implementación y la migración a la arquitectura TO-BE. Todo ello, dirigido como respuesta a
la visión estratégica de la organización.

ALCANCE
Para la identificación de las dimensiones y poder definir y limitar el alcance de la propuesta
de Arquitectura Empresarial se ha tomado como base el marco de referencia de arquitectura
empresarial TOGAF, siguiendo el método ADM. Estas son:

53
Amplitud
Acorde al ámbito de la organización Adecco Perú, y centrado en la actividad de arquitectura,
se centran los esfuerzos en el proceso de compras (considerado como uno de los procesos de
soporte de la compañía).

Profundidad
Durante el estudio, para comprender el proceso de compras de la compañía Adecco Perú, se
identificó que un punto neurálgico y del cual dependen las solicitudes de atención de
requerimientos de compras son las fases de atención de requerimientos, la generación de las
órdenes de compra y las órdenes de pago.

Periodo de Tiempo
El periodo de tiempo para definir la Visión de la Arquitectura está establecido en tres
semanas para completar los lineamientos generales. El periodo total para la elaboración de la
propuesta de Arquitectura debe completarse en un periodo no mayor a 2 meses.

Dominios de Arquitectura
Con las consideraciones que la aplicación del método de desarrollo de la arquitectura ADM
es modular, la misma que permite sub dividir las arquitecturas dentro de una misma
compañía o áreas de ésta por dominios, se elige como dominio las cinco primeras fases (A.
Visión de Arquitectura, B. Arquitectura de Negocio, C. Arquitectura de Sistemas de
Información (Aplicaciones y Datos), D. Arquitectura Tecnológica y E. Oportunidades y
Soluciones).

54
 Figura 7 - Alcance ADM del Proyecto
Fuente: TOGAF 9.1 ADM cycle (The Open Group, 2011)

Para todos los casos se analizan los escenarios AS IS y TO BE a fin de ejecutar el Análisis de
Brechas entre ambos planteamientos.

PRELIMINAR
Principios de Arquitectura

Los principios de la arquitectura definen las normas generales y directrices para el uso y
despliegue de todos los recursos y activos de TI en toda la empresa. Además, reflejan un
nivel de acuerdo entre los elementos de la organización, conformando la base para la toma de
futuras decisiones relacionadas a TI.9

Estos se subdividen en Principios de negocio, Principios de datos, Principios de aplicaciones

y Principios de tecnología que se plantean a continuación bajo el ámbito del proyecto actual.

55
Principios de Negocio
Los siguientes principios de negocio que rigen sobre el ámbito de Adecco, están basados en:
maximización de los beneficios de la empresa, gestión de la información, continuidad del
negocio, utilización de aplicaciones comunes, orientación al servicio y cumplimiento de la
ley y normas del Estado10.

Nombre Minimizar costos operativos

Enunciado Seguir una estrategia alineada de reducción de costos a través del
análisis y optimización de los procesos.
Fundamento Desarrollo de los canales de atención y mejora en la orientación del
servicio.
Repercusiones Incremento en la satisfacción de clientes internos y externos.

Nombre Tracking efectivo a la satisfacción del cliente

Enunciado Establecer mejores procedimientos para obtener un feedback adecuado
de parte del cliente interno y externo en búsqueda de mejorar los
servicios.
Fundamento Sensación de mejora en los procesos internos, fidelización de clientes
externos.
Repercusiones Evitar fuga de clientes por servicios dilatados o mal ejecutados.

Nombre Innovación continua y excelencia de servicios

Enunciado Llevar a cabo el seguimiento adecuado a la ejecución de las políticas
establecidas para promover la innovación y la consecuente excelencia
de los servicios.
Fundamento Fomentar la creación de iniciativas de desarrollo en la organización.
Repercusiones Organizar y planificar de mejor manera un Roadmap de iniciativas para

9
Alineado a la planteado en http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap29.html
10
Aspectos tomados como base de TOGAF (2009)

56
 sustentar los gastos de la organización.

Nombre ROI en TI asegurable y comprobable

Enunciado Asegurar que las inversiones en TI tengan el retorno esperado y
medido conforme a la ejecución de proyectos asociados.
Fundamento Toma de decisión correcta en la ejecución de proyectos de TI,
asegurando la inversión aprobada.
Repercusiones Mayor seguimiento y control a los proyectos tecnológicos de
desarrollo.
Tabla 4 - Principios de Negocio de AE
Fuente: Elaboración Propia

Principios de Datos
Los principios que rigen a continuación se basan en los siguientes aspectos: Datos como
activos, datos compartidos, datos accesibles, datos son administrados, vocabulario y
definición de datos comunes y datos seguros.11

Nombre La información y los datos son un activo para el negocio

Enunciado Brindar la relevancia debida a los datos y la información resultante de
su procesamiento como parte importante de los activos de la
organización.
Fundamento Los datos y la información, permiten a los diferentes niveles de
gestión tomar decisiones fundamentales para guiar el rumbo de la
empresa.
Repercusiones Incrementar la cultura de administración de datos, designar
responsables con autoridad para la ejecución de la administración de
este importante activo.

11
Aspectos tomados como base de TOGAF 2009

57
Nombre Disponibilidad continua a los datos e información del negocio
Enunciado Contar con accesibilidad y disponibilidad a los datos e información de
la empresa para sus responsables identificados y directos.
Fundamento La disponibilidad para contar con el acceso a los datos permite a los
roles estratégicos mejorar la calidad y la eficiencia en la toma de
decisiones oportunas.
Repercusiones Incrementar la inversión en adecuar operaciones o soluciones que
permitan cumplir con el presente principio. Analizar y ejecutar
acciones que permitan mejorar los modelos actuales de acceso a los
datos y la información para mejorar su disponibilidad.

Nombre Seguridad de Datos en la organización

Enunciado Mantener e implementar mecanismos adicionales que permitan el
aseguramiento y protección de los datos e información de la
organización.
Fundamento Considerando que estos 2 aspectos son manejados como activos de la
organización y propios de la misma, su divulgación puede permitir
especulaciones, mala interpretación y uso inapropiado fuera del
ámbito de la organización, incrementando el riesgo de resultados
negativos para el desenvolvimiento de la empresa dentro del mercado.
Repercusiones Alinear los mecanismos y procedimientos actuales a la legislación
local e internacional de protección y regulación de datos. Identificar
brechas en las operaciones actuales que incrementen el riesgo de fuga
de información o sustracción inapropiada de datos de la compañía.
Tabla 5 - Principios de Datos de AE
Fuente: Elaboración Propia

58
Principios de Aplicaciones
Principios basados en las siguientes consideraciones: Independencia de la Tecnología y
Facilidad de Uso12. La adecuación a la organización actual se presenta a continuación:

Nombre No estimular la dependencia de la relación tecnología/Aplicación

Enunciado Estimular la independencia de las opciones tecnológicas existentes en
el mercado, permitiendo al negocio optar por diferentes opciones.
Fundamento Contar con opciones para la selección de soluciones y soporte
tecnológico actual que le permitan a la empresa negociar y contar con
una variedad de productos que se ajusten al presupuesto actual y
destinado para este tipo de inversiones.
Repercusiones Incrementar la portabilidad e Inversión destinada a la implementación
de este tipo de soluciones.

Nombre Optimización y reutilización en el uso de los recursos

Enunciado Los recursos mencionados aplican a todo nivel tanto como a los de
TI, permitiendo construir sobre lo ya existente.

Fundamento Optimización de gastos para los Centros de Costos.

Repercusiones Disminución de gastos e incremento de las utilidades.

Tabla 6 - Principios de Aplicaciones de AE

Fuente: Elaboración Propia

12
Aspectos tomados como base de TOGAF 2009

59
Principios de Tecnología
Son aquellos principios cuya consideración gira en torno a: Cambios basados en los
requisitos, Gestión del Cambio Responsable, Control técnico de la diversidad y la
Interoperabilidad13. Su adecuación al presente desarrollo de Arquitectura Empresarial se
presenta a continuación:

Nombre Dinamismo en la ejecución de cambios en respuesta a los

requerimientos del negocio
Enunciado Promover el dinamismo de los cambios resultantes de los
requerimientos que plantean los usuarios/clientes internos y los
mismos que nacen de la necesidad y exigencia en respuesta al time to
market actual.
Fundamento El entorno de soporte tecnológico debe cambiar en respuesta a las
demandas del negocio y del mercado, en lugar de que el negocio se
adecué en respuesta a los cambios de TI. Los cambios correctamente
evaluados y justificados pueden convertirse en oportunidades de
mejora potenciales para enfrentar los retos del mercado actual.
Repercusiones Adopción y elección de nuevos procesos o una metodología que
proporcione dinamismo a los cambios que demanda el negocio.

Nombre Apertura y apuesta por soportes tecnológicos efectivos

Enunciado Explotar la partida existente para promover la inversión a soluciones
tecnológicas que mejoren la gestión diaria.
Fundamento Fomentar la inclusión presupuestaria de nuevo soporte tecnológico
permitiendo la mejora continua a la gestión.
Repercusiones Desarrollo de la organización a través del planteamiento y ejecución
de iniciativas.

13
Aspectos tomados como base de TOGAF 2009

60
 Nombre Cultura ecológica y de cuidado del ambiente con TI
Enunciado Fomentar el cuidado del medioambiente a través del uso continuo de
medios que no afecten directamente al sistema ambiental.
Fundamento Reducción de gastos a través de la aplicación de la cultura digital.
Repercusiones Reducción de medios físicos, incentivando los medios digitales.
Aplicación de políticas de ahorro energético.

Nombre Interoperabilidad de desarrollo en TI

Enunciado Permitir el intercambio de fuentes de información y de comunicación
para obtener una normalización entre los servicios y procesos.
Fundamento Potenciar el esquema de soluciones actual para fomentar un canal
único y cruzado de información.
Repercusiones Mayores fuentes de información organizacional y tecnológica para
mejores tomas de decisiones.
Tabla 7 - Principios de Tecnología de AE
Fuente: Elaboración Propia

Petición de Trabajo de Arquitectura

En esta sección se define la salida de la fase preliminar, a consecuencia de la arquitectura de
las solicitudes de cambio aprobadas, o términos de referencia para el trabajo de la
arquitectura procedente de planificación para Adecco Perú.

 Límites de tiempo: El plazo que se tiene para el desarrollo de la arquitectura es de 2

meses.

 Limitaciones Organizacionales: El desarrollo de la arquitectura está afectado por las

siguientes limitaciones organizacionales: Gobierno, Legal, Tributario, etc.

61
 Figura 8 – Límite Organizacional de Adecco Perú S.A.
Fuente: Elaboración Propia

La línea punteada central delimita la organización. En ese entorno, Adecco Perú ejerce
dominio sobre sus políticas, procedimientos, prácticas y sus resultados financieros. Fuera del
límite organizacional, están otros actores e interlocutores ejerciendo presión para obtener el
mayor beneficio posible y restándole valor a la organización.

Limitaciones financieras: Se dispone de $ 280,000 para la implementación de un conjunto

de iniciativas de mejora para los procesos actuales de Adecco Perú. A corto plazo y ante la
necesidad de generar la propuesta, se destina fondos de un proyecto relacionado para aportar
al presupuesto total. Este es de $ 50,000 para apoyar al planteamiento de la propuesta de la
arquitectura empresarial desde el proceso de Compras con la inmediata atención para el logro
sus objetivos estratégicos. Todo el financiamiento indicado proviene del presupuesto anual
aprobado por Adecco Group Corporate para este propósito.

62
Limitaciones externas, limitaciones de negocio: Se utiliza los lineamientos y políticas
establecidas con la aprobación vigente de Adecco Group Corporate y evaluación de los
procesos definidos desde Adecco Argentina. Esta dependencia externa se ve comprometida
por las regulaciones tributarias, legales y declaradas por el gobierno de Perú.

Descripción de la situación actual del Negocio sobre el Proceso de Compras

Problemática
En la actualidad, alrededor de 3,000 órdenes de compras son generadas de manera mensual,
todas registradas como si fueran compras regulares dentro del ERP no permitiendo identificar
cuales fueron por regularizaciones y cuales realmente fueron por compras regulares.

Cada comprador genera 700 órdenes de compra en promedio cada mes, el tiempo que dedica
a la regularización de compras es el triple del tiempo dedicado a una compra regular. Para
cumplir con esta cuota, los compradores frecuentemente se afectan con horas extras que
significan sobre esfuerzo laboral. El 70% de órdenes de compra que se generan, corresponde
a regularización de compras y el 30% son por compras regulares.

Las órdenes de compra que requieren aprobación de la dirección financiera o dirección

general, tardan en promedio un día en ser aprobadas, puesto que debe cumplir los sustentos
de adquisición del bien o servicio para obtener la conformidad de la dirección mediante una
firma manual (estos sustentos y órdenes se presentan en formato físico). Esta demora afecta
directamente a las operaciones (responsables de la gestión de servicios para los clientes de
Adecco Perú S.A.). Así como el retraso de pago a los proveedores (por regularización de
órdenes de compra) por lo general de operaciones fuera de Lima.

63
Durante el año 2014 y 2015, Adecco Perú S.A. le compró a más de 1,000 proveedores entre
bienes y servicios. A varios de estos proveedores se les compró un mismo bien o servicio
entre proveedores recurrentes y no recurrentes. Esta diversidad de proveedores con precios
ofrecidos sin negociación, no permite realizar ahorros desde las operaciones.

Requerimientos
Se requiere implementar funcionalidades que permitan agilizar los procedimientos de
regularización de compras y centralización de sus sustentos probatorios de ello.

Evitar la fatiga a los compradores con horarios de sobre esfuerzo durante la tarea de
generación de órdenes de compra para regularización de órdenes.

Automatizar las aprobaciones de la dirección financiera y dirección general de órdenes de

compra para no depender de sus firmas manuales, para atender oportunamente a las
operaciones y no descuidar las urgencias de los clientes.

Evitar retrasos en los pagos a los proveedores generados por la lentitud de los procedimientos
manuales.

Disminuir el número de proveedores y otorgarle poder de negociación al proceso de compras

para obtener mejores precios en función a compras concentradas por mayores volúmenes.

Descripción de la situación actual de la arquitectura/TI sobre el proceso de

Compras

Problemática
El proceso de TI brinda el soporte tecnológico al proceso de compras con un sistema
Dynamics ERP de la firma Microsoft en un entono cliente/servidor, desarrollado con
arquitectura cerrada, con costos de mantenimiento muy elevados y con desfases en dos
versiones. Sobre este antecedente se implementó un sistema legacy en entorno web integrado
a este ERP para agilizar algunas tareas de generación de requerimientos. Los usuarios

64
acceden desde una red VPN privada con deficiencias en velocidad, los sistemas están
alojados en servidores con prestaciones limitadas en un data center alquilado.

Requerimientos
El proceso de compras requiere que se resuelva sus quejas por la lentitud en la ejecución de
tareas desde el sistema Dynamics ERP, reclama la posibilidad de accesos fuera de la red VPN
e incrementar la cantidad de usuarios admitidos al ERP, puesto que está restringido al número
de licencias adquiridas y sobre el proceso de compras demanda solucionar los problemas
declarados en la Descripción de la situación actual del Negocio sobre el proceso de Compras.

65
VISIÓN DE LA ARQUITECTURA

Declaración de Trabajo de Arquitectura

Descripción del proyecto de arquitectura y alcance

Este proyecto de arquitectura se centra en el Proceso de Compras de la organización Adecco

Perú. El proceso de compras es el responsable de realizar las compras para clientes internos y
compras para clientes outsourcing (externos), asegurando el abastecimiento oportuno, y el
cumplimiento de las especificaciones de compras y adquisición de bienes y servicios.

A pesar que Adecco Perú existe hace más de 15 años, el sistema de información que apoya a
los procesos del negocio, tiene alto grado de obsolescencia tecnológica, ha sufrido constante
rediseño forzado y sin documentación para responder a las particularidades de los procesos y
para permitirle su integración con otros sistemas (dentro de la organización y externos como
los sistemas de entidades regulatorias). En este sistema, el Proceso de Compras ejecuta
algunos procedimientos lentos, tediosos y otros irregulares, para tratar de cumplir con los
lineamientos declarados por el Sistema de Gestión Calidad para la Gestión de Compras.

Sobre la base de esta declaración, se requiere desarrollar una arquitectura empresarial

flexible, acorde al proceso de Compras que le permita alinearse con la visión, misión y los
objetivos empresariales de Adecco Perú S.A. Esta arquitectura debe apoyarse en un marco de
trabajo como herramienta que pueda asistir con un modelo iterativo y con las mejores
prácticas. Es así que se propone el diseño de una arquitectura empresarial soportado por
TOGAF para el proceso de Compras de la organización Adecco.

La justificación de la elección de TOGAF se da en apoyo a lo mencionado por Dietz, J., &

Hoogervorst, J. (2011) [11] “se ha convertido en la herramienta más utilizada para la
implementación de EA, siendo considerado el estándar de facto para el desarrollo e
implementación de una iniciativa de este tipo”.

Las dimensiones de la Arquitectura que corresponden a Adecco Perú y su ERP (Comprende

los requerimientos de mejora del proceso de Compras), Base de Datos GP Microsoft SQL
Server 2008 R2 Enterprise, Sistema ERP Microsoft Dynamics GP / Ambiente cliente servidor

66
y el modelo de arquitectura de software se apoya en las aplicaciones .NET, así como la
tecnología HP para los servidores y otros como canales de comunicación, redes de fibra
óptica, etc.

Procedimientos específicos para cambios de alcance

Durante la definición e implementación de la arquitectura para el proceso y organización

objetivo, podrán aparecer más condiciones y hechos que la definición en curso y requisitos no
cubren o son suficientes para completar la implementación de la solución. En estas
circunstancias, es necesario contemplar las desviaciones necesarias del enfoque
arquitectónico inicial sugerido, considerándolo además un proceso iterativo y permitiendo
solicitar extensiones al alcance planteado.

De acuerdo a lo planteado en la Petición de Trabajo de Arquitectura, existirán limitaciones

organizacionales, factores externos y de mercado que obliguen al esfuerzo de definición
inicial aplicar cambios en la estrategia de negocios o nuevas oportunidades tecnológicas para
ampliar y afinar lo inicialmente definido.

En este sentido, se necesita ordenar este proceso de Solicitud de Cambio para ser presentado,
evaluado y aprobado con el fin de poner en marcha un nuevo ciclo de trabajo de arquitectura.
Se establece a continuación, el siguiente procedimiento y un formato (ver Anexo 2.1) que
debe contener mínimamente la información exigida para llevar con orden el presente
procedimiento:

Figura 9 – Flujo para cambios de Alcance

Fuente: Elaboración Propia

67
Formato para Solicitud de Cambios de Alcance en la Declaración de Trabajo de Arquitectura
“ANEXO 01”

Figura 10 – Solicitud para Cambio de Alcance en la Arquitectura

Fuente: Adaptación marco TOGAF

68
Roles, responsabilidades
Nombre Rol Responsabilidad
Gustavo Rufini CIO Lidera el proyecto de cambio, genera sinergias
y asegura el alineamiento Negocio-TI con las
posiciones estratégicas del negocio.
Ali Reátegui Arquitecto Es el nexo entre el negocio y TI. Responsable
Empresarial del logro de la estrategia de negocio, a través
de una gestión de la información y de las
soluciones de TI. Ejerce funciones de
gobierno y regula normas para la
comunicación entre los interesados y
participantes.
Sergio Aguirre Arquitecto de Negocio Responsable de analizar sistemáticamente el
proceso de negocio identificado y abordado
por la propuesta actual.
Juan Quispe Arquitecto de TI Encargado de desarrollar las arquitecturas de
aplicación, información, infraestructura e
integración. Desarrolla las soluciones con
base en TI y las estrategias necesarias para
abordar la construcción.
Tabla 8 - Roles y Responsabilidades de Arquitectura
Fuente: Elaboración Propia

69
Entregables
Entregable Información Medio Destinatario Responsable
Principios de Información de Escrito mediante Gerente de Gerente General
Arquitectura contenido a alto informe (formal) administración
nivel del
entregable
Petición de Información de Escrito mediante Gerente de Gerente General
Trabajo de contenido a alto informe (formal) administración
Arquitectura nivel del
entregable
Declaración de Información de Escrito mediante Gerente de Gerente General
Trabajo de contenido a alto informe (formal) administración
Arquitectura nivel del
entregable
Visión de la Información de Escrito mediante Gerente de Gerente General
Arquitectura contenido a alto informe (formal) administración
nivel del
entregable
Documento de Información de Escrito mediante Gerente de Gerente General
Definición de contenido a alto informe (formal) administración
Arquitectura nivel del
entregable
Plan de Información de Escrito mediante Gerente de Gerente General
Implementación contenido a alto informe (formal) administración
y Migración nivel del
entregable
Tabla 9 – Entregables de Arquitectura
Fuente: Elaboración Propia

70
Estructura de Gobierno
Se muestra la estructura del equipo de proyecto, a través del siguiente organigrama donde se
reflejan los roles y las líneas de reporte en el ámbito del proyecto.

Figura 11 – Estructura de Gobierno - Stakeholders

Fuente: Elaboración Propia

71
Procesos del Proyecto
Se establece el siguiente esquema para los procesos identificados como claves del proyecto y
que apoyan en la gestión de toda la información relacionada con la Arquitectura. De esto
depende el éxito del nivel de auditoría que se establezca para seguimiento a las decisiones
tomadas.

Proceso Detalle de alto nivel

Reuniones periódicas Se establece llevar reuniones periódicas de 1
semana para realizar seguimiento al avance del
planteamiento de la arquitectura.
Se involucra a los interesados directos de cada
entregable de Arquitectura definidos en la
estructura de gobierno.
Se agenda vía correo corporativo las reuniones
semanales y se agrega la disponibilidad de Webex
como medio de conferencia telefónica para los
participantes virtuales.
El resultado de estas reuniones debe ser plasmado
en el acta de reunión respectiva siguiendo la
plantilla exigida para este tipo de situaciones.
Tableros de dirección Se definen los temas claves y los resultados de su
ejecución para su seguimiento y control.
Abordan en su mayoría el control de los
entregables para cada fase de la Arquitectura.
Deben medir la “temperatura” en un momento
determinado de control para el seguimiento de las
actividades.
Los indicadores deben estar alineados a la
estructura definida por el SGC.
Repositorio de Documentación Toda la documentación generada en la etapa de

72
asociada Arquitectura debe mantener el formato definido
acorde al marco TOGAF definido.
Esta documentación debe contar con el
versionamiento respectivo y el control de cambio
asociado.
El repositorio oficial para la documentación esta
implementado en la solución SharePoint de
Microsoft cuya administración está bajo la
influencia de TI.
Los privilegios administrativos son definidos por
el Director de Proyecto y asignados a los roles
estratégicos de la presente etapa.
Gestión de Configuración Este proceso será asumido en su totalidad por el
Sistema de Gestión de Calidad de Adecco Perú
bajo los estándares ya definidos en la
organización. Bajo esta consideración SGC asume:
Control de versiones de los entregables de
Arquitectura.
Control de Cambios de los entregables generados
en esta etapa.
Proceso de Escalamiento Los procesos de escalamiento quedan definidos
alineados a la estructura de gobierno definida.
La centralización de los escalamientos está
asignadas al Director del Proyecto.
El Director de Proyectos informa el estado
resultante de los incidentes, falta de definición,
etc. para su respectiva asignación y solución.
Tabla 10 - Procesos clave de Arquitectura
Fuente: Elaboración Propia

73
Criterios de Aceptación
Entregables Criterio Descripción
Cumplimiento Se debe realizar un seguimiento constante al
de actividades cumplimiento de las actividades definidas en
del plan el plan de elaboración de la arquitectura a fin
de poder constatar la finalización de cada una
de las actividades y la integridad de la
 Principios de Arquitectura
información aquí generada.
Control de Se debe mantener un control de las versiones
 Petición de Trabajo de
versiones de de los entregables que sean generados de
Arquitectura
Entregables acuerdo a las peticiones de trabajo de
arquitectura, y en concordancia con las
 Declaración de Trabajo de
expectativas del plan estratégico empresarial.
Arquitectura
Presentación La presentación de los entregables sin
de Entregables excepción debe ser conforme al plan
 Visión de Arquitectura
establecido. No es considerado como
cumplimiento, versiones parciales o
 Documento de definición de
preliminares de los entregables.
Arquitectura
Revisión Es requisito para la aceptación de los
previa de los entregables que esté previamente revisado
 Plan de Implementación y
Entregables (contenido y forma) por el especialista en
Migración
Arquitectura empresarial.
Medios de Se debe enviar las versiones finales de los
entrega entregables generados, ya sea en medio
electrónico o magnético, según se requiera
para cada entregable o grupo de entregables.
Tabla 11 – Criterios de aceptación para entregables
Fuente: Elaboración Propia

74
Cronograma tentativo

Figura 12 – Cronograma tentativo

Fuente: Elaboración Propia

75
Interesados y sus preocupaciones
Para la identificación de los interesados y sus principales preocupaciones se plantean el
siguiente cuadro con el detalle respectivo:

Nombre Rol Principales preocupaciones

Héctor Castillo Director Financiero El planteamiento de Arquitectura resultante
debe permitir establecer la base para el
cumplimiento de los objetivos del proyecto.
Con la problemática identificada, busca
maximizar el ahorro y minimizar los gastos
generados por los procedimientos
engorrosos en el ámbito del proceso de
compras.
Gisela Lopez Auditora Interna Velar por el cumplimiento de las normativas
y los lineamientos establecidos por la
organización. Realizar el seguimiento
respectivo en cada fase clave detectada para
evitar desviaciones en el cumplimiento del
plan trazado.
Ali Reátegui Gerente de Sistemas Como Líder del Proyecto establece los
lineamientos tecnológicos en apoyo a los
objetivos del negocio para el presente
proyecto. Debe establecer el seguimiento
respectivo periódico a los recursos
destinados para cumplir el propósito general.
Eduardo Noriega Director de Proyectos Gestionar adecuadamente los recursos del
proyecto y el establecimiento de la presente
arquitectura. Evitar las desviaciones en
tiempo y costo de las tareas a llevar a cabo y
sustentar adecuadamente el avance de las
tareas y mantener el compromiso de los

76
 involucrados para el éxito.
Diego Ramos Consultor de Sistemas Obtener satisfacción de los involucrados
durante el proceso de relevamiento de
información para el planteamiento de la
Arquitectura actual y destino.
Eduardo Ortiz Analista de Sistemas Obtener disponibilidad continua e idónea de
las herramientas de apoyo. Obtener
planteamientos adecuados del análisis de la
situación actual base para los planteamientos
futuros y de mejora del proyecto.
Juan Quispe Asistente de TI Velar por la Arquitectura tecnológica
relacionada al proyecto y plantear soluciones
de TI reutilizables o de nueva
implementación en apoyo del proyecto.
Sergio Aguirre Jefe de Compras Alcanzar subsanar las deficiencias del
proceso de compras actual. Disponer de los
recursos en apoyo al análisis de la
problemática.
Ivan Alejos Comprador Senior Cubrir las expectativas y demandas de la
sección para mejorar los resultados e
indicadores del proceso actual.
Eva Garcia Comprador Obtener mejoras en el día a día del proceso
que se lleva a cabo. Cumplir con la
disponibilidad requerida para apoyo al
planteamiento de mejora.
Tabla 12 - Identificación de Interesados
Fuente: Elaboración Propia

77
 Para mantener la claridad del involucramiento y nivel de influencia relacionado al presente
proyecto de Arquitectura, se establece a continuación la Matriz Interés vs. Poder para la
clasificación de los interesados previamente descritos.

+
Mantener Satisfecho Gestionar de cerca
Auditora Interna Director Financiero
Gerente de Sistemas
Director de Proyectos
PODER

Monitorear (esfuerzo mínimo) Mantener Informado

Analista de Sistemas Consultor de Sistemas
Asistente de TI Jefe de Compras
Comprador Senior
Comprador

- INTERÉS +

Figura 13 - Matriz Interés vs. Poder

Fuente: Elaboración Propia

Lista de asuntos / escenarios que deben abordarse

 Se debe abordar el replanteamiento del proceso actual de compras y las tareas ejecutadas
por los actuales usuarios.

 Acotar el proceso actual de selección de proveedores, permitiendo al negocio identificar

puntualmente el mejor proveedor y el precio idóneo para el cumplimiento de determinado
fin.

78
 Los procedimientos manuales de los niveles de autorización deben ser eliminados a fin de
poder agilizar los procedimientos de pago a proveedores.

 Mejorar la satisfacción de los clientes debido a la disconformidad en tiempo de atención,

otorgando dinamismo de coyuntura del mercado actual.

 Obtener las aprobaciones para otorgar el presupuesto que demanden los cambios en los
procesos tanto en recursos humanos como tecnológicos, previa presentación y aprobación
del planteamiento de arquitectura actual.

79
ARQUITECTURAS DE LA LÍNEA BASE (AS IS)
Adecco Perú consciente de la necesidad de mejorar sus procesos, inició desde el año 2014 la
implementación de oportunidades para la definición de políticas y procedimientos para la
alineación e integración de todas las áreas de la organización dirigidas desde el Sistema de
Gestión Calidad - SGC, con el fin de cumplir las exigencias del grupo corporativo global
dirigida a la ejecución de los planes, programas y proyectos del proceso de compras
sintonizados con la visión del plan estratégico empresarial. En este sentido, se aborda el
análisis de la arquitectura en su estado actual.

Arquitectura de Negocio de Línea Base

Matriz de Objetivos del Negocio vs Proceso

Con la finalidad de mantener la trazabilidad de lo planteado, se muestra la matriz mencionada
enmarcada en el proceso de compras abordado. Se observa que el proceso seleccionado se
alinea en total con 3 objetivos estratégicos de la organización destino.

80
 Procesos de la Organización
Estratégicos Operativos Soporte

Seguridad, Salud Ocupacional y

Operaciones de Outsourcing

Administración de Personal

Comunicaciones Internas y
Planeamiento Estratégico

Outsourcing de Nóminas
Consultoría y Formación

Satisfacción del Cliente

Selección de Personal
Gestión de la Mejora
Gestión Financiera

Atención al Cliente

Gestión Humana
Auditoría Interna

Medio Ambiente
Asesoría Legal

Contabilidad
Facturación

Cobranzas
Compras

Tesorería
Temporal

Externas

IT
Objetivos Estratégicos de la Organización
Financiero

Incrementar el valor de los accionistas y de las utilidades en un 15% para el ejercicio en curso. X X X X X X X X X

Participar activamente en la estructuración de un modelo de negocio sostenible para el cliente sosteniendo el

X X X X
85% del indicador del SGC.
Cliente

Conservar la fidelidad de los clientes actuales e incrementar la cartera de los mercados objetivo identificados en
X X X X X X X X X X
un 15%.
Optimizar los procesos de Servicios, mejorando la calidad y Distribución de estos a través de la aplicación de
X X X X X X X
mejoras al SGC y el cumplimiento de los indicadores actuales.
Fortalecer y ampliar los canales de comunicación interna para la recepción y retroalimentación correcta a
consultas, quejas, reclamaciones como fuente principal de información y de mejora reduciendo el indicador de X X X X X
Interno

incidencias al 10%.
Facilitar la disposición de mejores herramientas a los colaboradores para crear una cultura empresarial ágil,
X X X X X X X X
sostenible y responsable, incrementando la inversión en estos medios en un 45%.
Consolidar las nuevas líneas de negocio al interior del país de manera sostenible, incrementando la cobertura
X X X X X X X
actual en un 30%.
Aprendizaje y
Crecimiento

Incrementar la inversión en un 25% destinada a capacitación, mejorando la satisfacción de los colaboradores,

X X X X
aumentando los incentivos trimestrales y el paquete de beneficios actual con alianzas estratégicas.
TOTAL OBJETIVOS CUBIERTOS 5 1 3 1 0 7 2 3 3 5 3 1 5 3 2 3 2 1 1 2 1

Tabla 13 - Matriz de Objetivos Estratégicos vs. Proceso de Negocio de Línea Base

Fuente: Elaboración Propia

81
 Proceso de Compras
Se presenta el esquema a alto nivel del proceso clave del proyecto a fin de poder asegurar que
los artefactos de arquitectura y contratos, principios y acuerdo de nivel operativo se
monitoreen continuamente para ser auditados de todas las decisiones que se tomen en la
ejecución del proyecto.

El proceso clave de negocio seleccionado es el proceso de Compras, específicamente en los

sub procesos Compras Regulares, Compras Negociadas y Regularización de Compras.

Figura 14 – Proceso de negocio de compras

Fuente: Elaboración Propia

Descripción
El proceso de compras de línea base, presenta la secuencia de procesos donde no existe un
contrato marco negociado con los proveedores.

 El proceso inicia con la necesidad de adquirir un bien o servicio que requiere el cliente.

 Esta necesidad se traduce como requerimiento que demanda aprobación.

 Esta aprobación supone la conformidad para iniciar la búsqueda de proveedores

potenciales.

 Los proveedores emiten sus propuestas (cotizaciones).

82
La conformidad de una cotización, permite generar una orden de compra, cuya aprobación,
supone la decisión de compra, por esta razón se envía al proveedor una petición de atención
de orden de compra.

83
Diagrama de Actividades para Compras Internas (línea base)

Figura 15 – Diagrama de Actividades de Compras Internas de Línea Base

Fuente: Elaboración Propia

84
 A continuación, se describen los lineamientos del proceso gestión de compras internas:

 El cliente interno (genera los requerimientos considerados como gastos para la compañía)
registra el requerimiento y solicita su aprobación (todo solicitante tiene asignado un
aprobador de solicitudes).

 El aprobador interno valida la solicitud de requerimiento para decidir su aprobación y

notificar al comprador responsable de las compras internas, en el caso supuesto que
existiera desaprobación del requerimiento, el aprobador rechaza el requerimiento y por
consiguiente se debe anular el requerimiento.

 El comprador es el responsable de buscar el proveedor, solicitar y evaluar las cotizaciones

de estos; si confirma la aprobación de la cotización, entonces genera la orden de compra
para luego solicitar su aprobación a la jefatura de compras, si por el contrario no aprueba
la cotización, contacta a otro proveedor para una nueva cotización.

 La jefatura de compras recibe solitudes que requieren la aprobación de órdenes de

compra, que podría rechazarlos y por consiguiente se tendría que anular su requerimiento
asociado y terminaría el flujo, si por el contrario, la orden fuera aprobada y esta no supera
los $ 5,000, entonces se envía la orden de compra al proveedor, este atiende y termina el
flujo. Si la orden es superior a $5,000, el jefe de compras solicita la aprobación a la
dirección financiera.

 La dirección financiera debe validar todas las órdenes que superan los $ 5,000, donde las
que son rechazadas, generan en consecuencia la anulación de su requerimiento asociado
culminando el flujo. Si, por el contrario, la dirección financiera aprueba la orden,
entonces se envía este documento al proveedor para su atención y el flujo concluye.

85
Diagrama de Actividades para Compras Externas (línea base)

Figura 16 – Diagrama de Actividades de Compras Externas de Línea Base

Fuente: Elaboración Propia

86
 A continuación, de describe los lineamientos del Proceso gestión de compras externa:

 El cliente externo (genera los requerimientos considerados costos para la compañía)

registra un requerimiento para luego solicitar la aprobación por parte de su jefatura
directa.

 El cliente solicitante externo, tiene asignado un aprobador, quien decide si procede la

aprobación del requerimiento.

 El aprobador de requerimiento externo, valida la solicitud de aprobación de requerimiento

pudiendo aprobarlo o rechazarlo. En el caso supuesto que existiera desaprobación del
requerimiento, se procede con su anulación. Si por el contrario el requerimiento fuera
aprobado, entonces se notifica al comprador para su atención.

 A partir de un requerimiento aprobado, el comprador busca el proveedor, solicita la

cotización y envía al cliente solicitante externo para que pudiera ser evaluado por este, si
esta fuera aprobada, entonces se genera la orden de compra y se solicita la aprobación de
la jefatura de compras, si por el contrario no aprueba la cotización, el cliente vuelve a
contactar a compras para solicitar una nueva cotización.

 La jefatura de compras recibe solitudes que requieren la aprobación de órdenes de compra

u órdenes de pago, que podría rechazarlos y por consiguiente se anula su requerimiento
asociado, culminando con el flujo respectivo. Si, por el contrario, la orden fuera aprobada
y esta no supera los $ 5,000, entonces se envía la orden de compra al proveedor, este
atiende y termina el flujo. Si la orden es superior a $5,000, el jefe de compras solicita la
aprobación a la dirección financiera.

 La dirección financiera debe validar todas las órdenes que superan los $ 5,000, donde las
que resultaran rechazadas asocian la anulación de su requerimiento original y el flujo se
da por concluido. Si, por el contrario, la dirección financiera aprueba la orden, entonces
se envía este documento al proveedor para su atención y el flujo concluye.

87
Roles de Negocio: Matriz RACI
Se elabora la Matriz indicada con la finalidad de identificar a los responsables participantes
del proceso seleccionado y poder indicar su grado de injerencia sobre las actividades propias
de Compras.

Director Financiero (Sponsor)

RACI CHART

Comprador Senior

Cliente Aprobador
Jefe de Compras
Auditora Interna

Cliente Externo
Cliente Interno
Comprador

Proveedor
Actividades
Registrar requerimiento I I I R R
Solicitar aprobación del requerimiento I I I I R R
Validar requerimiento I I I I A R R
Anular requerimiento I I I I I R R
Buscar proveedor I I R R
Solicitar cotización I R R I
Generar cotización I I R
Enviar cotización I I R
Evaluar cotización I I A A
Confirmar aprobación de cotización I R R
Generar orden de compra I C R R
Solicitar aprobación de orden de compra A R R
Validar orden de compra C A I I
Rechazar orden de compra R R I I I I
Solicitar aprobación de dirección A R I I
Verificar orden de compra R I I I
Enviar orden de compra I R I I
Atender orden de compra I I I I R

Leyenda: R (Responsable), A (Aprobador), C (Consultado) e I (Informado)

Tabla 14 - Matriz RACI del Proceso Compras de Línea Base

Fuente: Elaboración Propia

88
Arquitectura de Sistemas de Información de Línea Base

Arquitectura de Datos

Modelo de datos

89
Figura 17 - Modelo de Datos de Línea Base
Fuente: Elaboración Propia

90
A continuación, se brinda el detalle de las entidades plasmadas en el modelo, pero acotado a
la identificación de aquellas que trabajan principalmente y de manera fundamental en el
proceso de compras seleccionado.

ID ENTIDAD DESCRIPCIÓN
GP_ARTICULOS Entidad que contiene los datos
E001 relacionados a los artículos requeridos
en el proceso.
GP_CATEGORIA_ARTICULO Entidad que contiene las categorías de
E002
los artículos.
GP_CLIENTES Entidad, maestro que contiene los datos
E003
de los clientes
GP_PROVEEDORES Entidad, maestro que contiene los datos
E004
de los proveedores
GP_TIPO_OC Entidad que contiene datos de los tipos
de las órdenes de compras (compra
E005
nacional, compra importación, compra
servicios, activos fijos)
GP_TIPO_PERSONA Entidad que contiene datos de los tipos
E006 de personas (persona natural, persona
jurídica, sujeto no domiciliado)
IV00101 Entidad que contiene datos del maestro
E007
de artículos
IV00103 Entidad que contiene datos del maestro
E008
de proveedor de artículo
IV40400 Entidad que contiene datos de la
E009
configuración de las clases de artículos
POP00101 Entidad que contiene datos del maestro
E010
de comprador
POP40600 Entidad que almacena la configuración
E011
de moneda de artículo no inventariado

91
 (soles /dólares)
REQ_ESTADO Entidad que almacena los posibles
E012
estados de los requerimientos
REQ_NODOS Entidad que almacena los nodos (por lo
E013 general están representados por áreas,
sucursales o jefaturas)
REQ_NODOS_USUARIOS Entidad que almacena los nodos
E014 (solicitantes de requerimientos
agrupados por sus aprobadores)
REQ_PRIORIDAD Entidad que almacena los niveles de
E015 prioridad en la que deben ser atendidas
los requerimientos
REQ_REQUISICION_CABECERA Entidad que almacena los datos de
E016
cabecera de los requerimientos
REQ_REQUISICION_DETALLE Entidad que almacena los datos de los
E017
detalles de los requerimientos
REQ_REQUISICION_ORDEN_GP Entidad que almacena los datos de las
E018 órdenes de compra (compuesto por uno
o más requerimientos)
REQ_TIPOREQUERIMIENTOS Entidad que almacena los datos de los
E019 tipos de requerimientos (por artículos,
servicios, activos, entregas a rendir)
REQ_USUARIOS Entidad que almacena los datos de los
E020 usuarios identificados como solicitantes
o como aprobadores de requerimientos
Tabla 15 - Cuadro detalle de entidades de Línea Base
Fuente: Elaboración Propia

92
Matriz de datos del proceso seleccionado vs procesos del Negocio
Procesos de la Organización
Estratégicos Operativos Soporte

Seguridad, Salud Ocupacional y

Operaciones de Outsourcing

Administración de Personal

Comunicaciones Internas y
Planeamiento Estratégico

Outsourcing de Nóminas
Consultoría y Formación

Satisfacción del Cliente

Selección de Personal
Gestión de la Mejora
Gestión Financiera

Atención al Cliente

Gestión Humana
Auditoría Interna

Medio Ambiente
Asesoría Legal

Contabilidad
Facturación

Cobranzas
Tesorería
Temporal

Compras

Externas

IT
Entidades del Proceso
GP_ARTICULOS X
GP_CATEGORIA_ARTICULO X
GP_CLIENTES X X X X
GP_PROVEEDORES X X
GP_TIPO_OC X X X X
GP_TIPO_PERSONA X
IV00101 X
IV00103 X
IV40400 X
POP00101 X
POP40600 X
REQ_ESTADOS X
REQ_NODOS X
REQ_NODOS_USUARIOS X
REQ_PRIORIDAD X
REQ_REQUISICION_CABECERA X
REQ_REQUISICION_DETALLE X
REQ_REQUISICION_ORDEN_GP X
REQ_TIPOREQUERIMIENTOS X
REQ_USUARIOS X X

Tabla 16 - Matriz de Datos del Proceso vs Procesos del Negocio de la Línea Base
Fuente: Elaboración Propia

93
Arquitectura de Aplicación de Línea Base

Diagrama de Aplicaciones y Descripción

Microsoft Dynamics GP

Personalizaciones

Financiero Administración Inventario

Consultas y
Reportes

Ventas Compras SmartList

Figura 18 – Diagrama de Aplicaciones de Compras de Línea Base

Fuente: Elaboración Propia

Microsoft Dynamics GP 2010 es el software ERP implementado en Adecco Perú con seis
módulos habilitados, un módulo de personalizaciones (adecuaciones para el mercado local,
comerciales, legales, tributarios) que permite potenciar y optimizar los procesos de las áreas
(Finanzas, Contabilidad, Tesorería, Compras, Facturación y Cobranzas) Microsoft Dynamics
GP en su módulo de compras, permite brindar información crítica de manera rápida pero
poco eficiente, las funcionalidades del módulo de compras no permite adaptarse a las
políticas declaradas para este proceso, por ello no se garantiza que se pueda contar con la
información precisa y en tiempo real para tomar decisiones oportunas dentro del proceso de
compras.

Matriz de Aplicaciones del proceso seleccionado vs procesos del Negocio

Una vez identificadas las aplicaciones que se ven impactadas por el proceso, se define la
siguiente matriz para poder trazar su impacto y trazabilidad en el negocio.

94
 Aplicaciones del Proceso Seleccionado

Microsoft Dynamics GP - Módulo

Compras
Procesos de Negocio
Gestión de la Mejora X
Estratégicos

Gestión Financiera X
Planeamiento Estratégico
Auditoría Interna X
Asesoría Legal
Atención al Cliente
Selección de Personal
Operaciones de Outsourcing
Operativos

Outsourcing de Nóminas
Consultoría y Formación
Administración de Personal Temporal
Facturación
Satisfacción del Cliente
Compras X
Comunicaciones Internas y Externas
Gestión Humana
Soporte

IT
Seguridad, Salud Ocupacional y Medio Ambiente
Contabilidad X
Cobranzas
Tesorería X

Tabla 17 - Matriz de Aplicaciones Proc. seleccionado vs Proc. de Negocio Línea Base

Fuente: Elaboración Propia

95
Arquitectura Tecnológica de Línea Base
Componentes de tecnología y sus relaciones con los sistemas de información

FRONT OFFICE
Suite
<<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information

Services
Servidor:SUITE

<<Web Application>>
SUITE

MIDDLE OFFICE

Satélite Comercial Facturación Electrónica

ER – Entregas a Rendir
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2 <<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
Services Instancia: Services Instancia: <<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard
Servidor:SUITE DBSQLONE\GPPROD Servidor:MSPEADECC032 DBSQLONE\FEPROD
<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
Services Instancia:
<<data base>> <<data base>> Servidor:MSPEADECC032 DBSQLONE\GPPROD
<<Web Application>> <<Web Application>>
Satelite SATELITE SGDPER MercurioBD
<<data base>>
GPPAC
<<Web Application>>
ER <<data base>>
GPPAI
<<Mobile Application>> <<data base>>
ERMOVIL GPPAP

Fractal Integrador
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard
Microsoft Dynamics GP
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2 <<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard
Services Instancia:
Servidor: FRACTAL DBSQLTWO\FRACTAL
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Application>> <<data base>>

FRACTAL <<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
PAYROLL
Services Instancia:
<<Web Application>> <<data base>> Servidor:SUITE DBSQLONE\GPROD
FRACTAL FRACTALHIST
<<data base>> <<data base>>
<<Web Application>> DYNAMICS GPPAI
HISTÓRICO
<<C/S Application>> <<data base>> <<data base>>
Dynamics.exe GPIN GPPAP

<<data base>>
GPPAC

Asistencia BL
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard

Dynamics CRM
<<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2

Services Instancia:
Servidor:SUITE DBSQLONE\LEGACYS

Adecco Top <<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard
<<Web Application>> <<data base>>
BL-Asis LegacyDB
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2

Services Instancia:
Servidor:SUITE DBSQLONE\CRM
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard <<C/S Application>>
Dynamics.exe <<data base>>
<<data base>> SCRM_CONFIG
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard ADECCO_PERU_
S_A_MSCRM <<data base>>
<<database system>> SQL Server 2008 R2 CRMIN
<<Web Server>> Internet Information
Services Instancia:
<<data base>>
Servidor:SUITE DBSQLONE\LEGACYS
Demo_MSCRM

<<Web Application>> <<data base>>

AdeccoTOP LegacyDB

Gestión Desempeño
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard
Bonos y Comisiones
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2

Services Instancia: <<device>> Windows Server 2008 R2 Standard
<<device>> Windows Server 2008 R2 Standard
Servidor:MSPEADECC032 DBSQLONE\LEGACYS

<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Application>> <<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
SGDPER <<data base>> Instancia:
Services
LegacyDB DBSQLONE\LEGACYS
Servidor:SUITE

<<Web Application>>
Bonos&Comisiones <<data base>>
LegacyDB

BACK OFFICE
Workflow GP
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2

Services Instancia:
Servidor:SUITE DBSQLONE\GPPROD

<<Web Application>>
DynamicsWorkFlowGP <<data base>>
WSS_CONTENT

Figura 19 – Componentes de Tecnología y los Sistemas de información de Línea Base

Fuente: Tecnologías de la Información – Adecco Perú

96
 Esta es la representación de los componentes de tecnología que sirven de soporte a todos los
procesos de la compañía Adecco Perú.

 Suite: es una aplicación de frontoffice que contiene los accesos directos a todos los
sistemas de la capa middleoffice.

 Satélite comercial: es una aplicación que contiene todos los detalles de los contratos
establecidos entre Adecco Perú y sus clientes (servicios, operaciones, re-facturación,
adendas, distribución de centros de costos, periodos facturables, margen de utilidad, etc.).

 Facturación electrónica: es una aplicación que permite intercambiar comprobantes

electrónicos con los clientes y SUNAT, es el soporte de los procesos facturación y
contabilidad, contribuye a la mejora del medio ambiente y su valor agregado es el acceso
a beneficios financieros, a través del factoring electrónico.

 ER-Entregas a Rendir: es una aplicación que está orientado a los reembolsos por gastos
de movilidad, alimentación, estadía que un empleado pudiera haber incurrido durante las
tareas laborales. Así también, permite a los responsables de la gestión de los fondos de la
organización informar, justificar y ser responsables de la aplicación de los recursos
puestos a su disposición.

 Fractal: es una aplicación que permite automatizar y gestionar la nómina interna de

manera rápida y efectiva con la configuración de múltiples tipos de planilla y la
posibilidad de gestionar varias empresas desde una sola solución.

 Asistencia BL: es una aplicación que permite capturar la hora de ingreso y salida del
personal, estos datos son enviados al sistema Fractal.

 Microsoft Dynamics GP: es el ERP que soporta seis procesos de la organización y

permite extender y conectar con aplicaciones de Microsoft.

 Adecco Top: es una aplicación legacy desarrollada por la compañía con la finalidad de
automatizar distintos procesos propios del negocio.

97
 Microsoft Dynamics CRM: es una aplicación sobre la que se soporta Adecco para lograr
los objetivos centrados en la relación con sus clientes durante las fases de adquisición y
de fidelización.

 Gestión de Desempeño: es una aplicación que permite medir el esfuerzo aplicado a los
empleados de Adecco Perú para evaluar su gestión encaminada al cumplimiento de la
misión a partir de la mejora de los procesos.

 Bonos y comisiones: es una aplicación que permite configurar los parámetros para el
cálculo de los bonos de los directivos de Adecco y la asignación de comisiones que la
organización realiza a un empleado por los servicios que prestan.

 WorkFlow GP: es una aplicación BackOffice que permite controlar los flujos de trabajo
definidos en Microsoft Dynamics GP.

Plataforma de tecnología y su descomposición

Capa de Capa de Presentación
Seguridad
APLICACIONES WEB
(.NET)

Capa Middleware
CAPA DE SEGURIDAD DE LA INFORMACION Y CONTROL DE ACCESOS

Capa de
Administración
APLICACIONES CLIENTE- SERVIDOR
(.NET, Dexterity)

APLICACIONES WEB
(.NET)
ADMINISTRACIÓN

Capa de base de datos

BASE DE DATOS DE ALTA DISPONIBILIDAD BASE DE DATOS DE PROCESOS NO CRITICOS

Figura 20 – Plataforma de tecnología y su descomposición de Línea Base

Fuente: Elaboración Propia

98
La capa de seguridad, es donde residen las aplicaciones para administrar y controlar los
accesos de los usuarios que interactúan con los sistemas en Adecco.

La capa de presentación sitúa la tecnología para soportar las aplicaciones de presentación. Se

cita por ejemplo a la “Suite de Adecco”.

La capa middleware en Adecco, facilita la interacción entre las aplicaciones, bases de datos,
redes, hardware y sistemas operativos.

La capa de base de datos aloja y permite administrar los datos y están separados en función a
su alta disponibilidad (por ejemplo, Fractal, GP, Satélite y CRM) y las de procesos no críticos
(Bonos y comisiones y Entregas a Rendir)

La capa de administración en Adecco permite organizar la distribución de la red y el estado

de los equipos clave. Así como por ejemplo para obtener estadísticas de red.

Ambientes y ubicaciones

Agrupamiento de las tecnologías requeridas para cada ambiente informático

Construcción y ¿Existe
Desarrollo

documentación iteración?
Proceso General de desarrollo

Informe de implementación

Pruebas de ¿Existe
Pruebas

aceptación iteración?

Registro de aceptación

¿Existe
Paso a producción
iteración?
Producción

Plan de Registro de Aceptación

implementación capacitación del cambio

Figura 21 – Ambientes y ubicaciones para cada ambiente informático de Línea Base

Fuente: Elaboración Propia

99
El ambiente de desarrollo, dispone de Visual Studio .NET 2010, SQL Server 2008 R2, una
bitácora logging y herramientas para monitoreo de desempeño y debugginng. Este ambiente
tiene características similares en software e infraestructura a los ambientes de pruebas y
producción. Este ambiente está alojado en servidores de un proveedor que presta servicios de
hosting. El nombre de dominio, se diferencia por el prefijo DESA. Todos los requerimientos
están documentados, los desarrolladores usan este ambiente en exclusividad (no los otros
ambientes directamente). Contiene datos de prueba y en este ambiente se tiene una rutina que
trasforma los datos sensibles obtenidos desde pruebas o producción.

El ambiente de pruebas, se destina directamente para ejecutar los escenarios de pruebas,

cuyos datos, documentación y demás artefactos asociados y destinados a esta operación
residen en el servidor compartido y no en las computadoras de los desarrolladores. Este
servidor usa nombre de dominio. Este ambiente tiene características muy similares al
ambiente de producción y también se encuentra alojado en los servidores de un proveedor
que otorga el hosting. A diferencia del ambiente de desarrollo, este servidor tiene capacidad
para atender a múltiples audiencias para la ejecución de pruebas por ejemplo a
administradores, usuarios finales y desarrolladores. El nombre de dominio, se diferencia por
el prefijo QA. Los desarrolladores no tienen privilegios para hacer cambios en este ambiente,
se almacenan datos de prueba y en este ambiente también se cuenta con una rutina que
transforma los datos sensibles, traídos desde producción. Existe un administrador que es el
único que despliega los cambios solicitados y existe un registro para control de cambios que
soporta el rastro de las modificaciones.

El ambiente de producción, es el ambiente donde radican las aplicaciones finales, aquí se

dispone de un entorno donde perfectamente se despliegan las aplicaciones siguiendo los
procedimientos de pase a producción autorizados por dueño de procesos afectados y por el
jefe de sistemas. Este servidor está desplegado en un datacenter de un proveedor que otorga
el servicio de hosting. En Adecco existen protocolos establecidos para la definición de
calendarios para la realización de pases a producción sobre este ambiente.

100
Comunicaciones Físicas

Figura 22 - Diagrama de Red de Línea Base

Fuente: Elaboración Propia

Especificaciones de hardware y red

Host Virtual Machine
Content
IP VM Name Use Processor Family CPU (Cores) RAM Disk IP Content
Intel Xeon E5-
MSPEADECC029 Aplication Server 6 32 GB 1 TB 192.0.20.50 MS Dynamics GP MS Dynamics GP ERP aplication
192.0.20.20 2600 v3 3.5 GHz
ProLiant 360DL Intel Xeon E5-
DBSQLONE Database Server 8 64 GB 3 TB 192.0.30.32 ERP Database MS Dynamics GP ERP Database
2600 v3 3.5 GHz

WorkSations
IP Use Processor RAM Disk Content
192.0.XX.XX Estación Intel Core i5-6300U 2.40 GHz 8 GB 250 GB ERP Access

Equipos de comunicación
Cantidad Use Descripción Capacidad Locación
1 Comunicaciones Switch Cisco Nexus 56128P 2.56 Tbps Site HP
1 Comunicaciones Router Cisco 4431 Site HP
1 Comunicaciones Switch Cisco Nexus 5672UP 1.44 Tbps Site Adecco
1 Comunicaciones Router Cisco 4331 Site Adecco

Tabla 18 - Especificaciones de Hardware y Red de Línea Base

Fuente: Elaboración Propia

101
FUNDAMENTO Y JUSTIFICACIÓN DEL ENFOQUE
ARQUITECTÓNICO

Cuando las compañías no alinean sus procesos de tecnologías de información a los objetivos
estratégicos, suelen desaprovechar recursos que afectan su competitividad. Por esta razón
Adecco Perú se apoya en TOGAF como herramienta empresarial que le permite afrontar de la
mejor manera los continuos cambios.

Adecco Perú está desarrollando Arquitectura Empresarial (AE) a nivel del proceso de
compras, razón por la cual se afectará de manera positiva las tareas rutinarias actuales, siendo
así que se justifica el presente trabajo para este tipo de organizaciones.

En la organización objetivo no se encuentran antecedentes de ejecución o aplicación de AE

para ninguno de sus procesos, por esta razón también existe una justificación para la
realización del diseño de arquitectura empresarial y la adopción continua de esta
metodología.

Existen muchas compañías en el mundo que exitosamente implementan arquitectura

empresarial. Adecco Perú, busca dotar a su proceso de negocio de compras, marcos de
referencia como TOGAF que le permita dar valor al análisis resultante y fortalecer la base de
estudio del proceso indicado.

El objetivo principal es establecer un diagnostico actual de la AE aplicado al proceso de

compras de Adecco Perú (ASIS), con ello se inicia la presentación de una propuesta (TOBE)
y se espera a mediano plazo, la implementación de AE en los distintos procesos de negocio
de la compañía para su beneficio.

102
ARQUITECTURAS DE LA LÍNEA DESTINO (TO BE)
El desarrollo de esta parte del trabajo busca plantear las arquitecturas ya no desde el punto
base actual de la organización, sino más bien se plantean las arquitecturas destino que se
establecen como parte de la estrategia de la propuesta de solución.

Arquitectura de Negocio de la Línea Destino

Matriz de Objetivos del Negocio vs Procesos

Luego de dar pie al análisis base e identificar las mejoras a los procesos actuales, se plantea la
matriz mencionada, donde para este caso, se determina que su alineación cubre en
expectativa a 2 objetivos estratégicos adicionales de la organización, como a continuación se
detalla.

103
 Procesos de la Organización
Estratégicos Operativos Soporte

Seguridad, Salud Ocupacional y

Operaciones de Outsourcing

Administración de Personal

Comunicaciones Internas y
Planeamiento Estratégico

Outsourcing de Nóminas
Consultoría y Formación

Satisfacción del Cliente

Selección de Personal
Gestión de la Mejora
Gestión Financiera

Atención al Cliente

Gestión Humana
Auditoría Interna

Medio Ambiente
Asesoría Legal

Contabilidad
Facturación

Cobranzas
Compras

Tesorería
Temporal

Externas

IT
Objetivos Estratégicos de la Organización
Financiero

Incrementar el valor de los accionistas y de las utilidades en un 15% para el ejercicio en curso. X X X X X X X X X

Participar activamente en la estructuración de un modelo de negocio sostenible para el cliente sosteniendo el

X X X X
85% del indicador del SGC.
Cliente

Conservar la fidelidad de los clientes actuales e incrementar la cartera de los mercados objetivo identificados en
X X X X X X X X X X
un 15%.
Optimizar los procesos de Servicios, mejorando la calidad y Distribución de estos a través de la aplicación de
X X X X X X X
mejoras al SGC y el cumplimiento de los indicadores actuales.
Fortalecer y ampliar los canales de comunicación interna para la recepción y retroalimentación correcta a
consultas, quejas, reclamaciones como fuente principal de información y de mejora reduciendo el indicador de X X X X X
Interno

incidencias al 10%.
Facilitar la disposición de mejores herramientas a los colaboradores para crear una cultura empresarial ágil,
X X X X X X X X
sostenible y responsable, incrementando la inversión en estos medios en un 45%.
Consolidar las nuevas líneas de negocio al interior del país de manera sostenible, incrementando la cobertura
X X X X X X X
actual en un 30%.
Aprendizaje y
Crecimiento

Incrementar la inversión en un 25% destinada a capacitación, mejorando la satisfacción de los colaboradores,

X X X X
aumentando los incentivos trimestrales y el paquete de beneficios actual con alianzas estratégicas.
TOTAL OBJETIVOS CUBIERTOS 5 1 3 1 0 7 2 3 3 5 3 1 5 3 2 3 2 1 1 2 1

Tabla 19 - Matriz Objetivos del Negocio vs. Proceso seleccionado de la Línea Destino
Fuente: Elaboración Propia

104
 Proceso de Compras de la Línea Destino

Figura 23 – Proceso de Compras de la Línea Destino

Fuente: Elaboración Propia

Descripción:
El proceso de compras de línea destino, presenta la secuencia de procesos donde existe un
contrato marco por precios negociados con los proveedores, posibilidad de regularizar una
compra anticipada, manejada ya como órdenes de pago y la existencia de un flujo de
aprobaciones por montos de las órdenes.

 El proceso inicia con la necesidad de adquirir un bien o servicio que requiere el cliente.

 Esta necesidad se traduce como requerimiento que demanda aprobación.

 Esta aprobación supone la conformidad para elegir al proveedor con precios negociados,
si no existiera un contrato vigente se inicia la búsqueda de proveedores potenciales.

 Los proveedores sin contratos por precios negociados, emiten propuestas (cotizaciones)

 La conformidad de una cotización, permite generar una orden de compra, cuya

aprobación ingresa a un flujo de aprobaciones en función a rangos de los montos de las
órdenes.

Las ordenes aprobadas a la salida del flujo de aprobación, suponen la decisión de compra, por
esta razón envía al proveedor una petición de atención de orden de compra.

105
Diagrama de Actividades para Compras Internas (línea destino)

Figura 24 – Proceso de Compras Internas de la Línea Destino

Fuente: Elaboración Propia

106
 A continuación de describe los lineamientos del proceso gestión de compras externas de la
línea destino:

 El cliente interno (genera los requerimientos considerados como gastos para la compañía)
registra el requerimiento y solicita su aprobación (todo solicitante tiene asignado un
aprobador de solicitudes).

 El aprobador interno valida la solicitud de requerimiento para decidir su aprobación y

notificar al comprador responsable de las compras internas, en el caso supuesto que
existiera desaprobación del requerimiento, el aprobador rechaza el requerimiento y por
consiguiente se debe anular el requerimiento asociado.

 El aprobador de requerimiento interno, valida la solicitud de aprobación de requerimiento

y podría aprobarlo o rechazarlo, si luego de la aprobación de la orden, se identifica que es
una regularización (compra realizada con anticipación), entonces se genera la orden de
pago para luego solicitar su aprobación por parte de la jefatura de compras, que podría ser
rechazada, es entonces que provoca la anulación automática del requerimiento asociado a
esta orden de pago.

 Si el requerimiento aprobado, fuera para un proveedor con contrato negociado, entonces

se genera una orden de compra y se solicita la aprobación por parte de la jefatura de
compras.

 Si el requerimiento aprobado, fuera para un proveedor sin contrato negociado vigente, el

comprador elige el proveedor para atender el requerimiento, solicita la cotización al
proveedor, evalúa la cotización y decide su aprobación que, si resulta aprobada, entonces
se genera la orden de compra y solicita la aprobación de la misma a la jefatura de
compras, si, por el contrario, la cotización no fuera aprobada, entonces se debe volver a
contactar a otro proveedor para una nueva cotización.

 La jefatura de compras recibe solitudes de aprobación de órdenes que, si decide

rechazarlos, entonces anulan automáticamente el requerimiento asociado a este y
culminan el flujo, si, por el contrario, la orden fuera aprobada y esta no supera los $ 5,000
entonces se envía la orden de compra al proveedor, esta se atiende y termina el flujo. Las

107
 órdenes de compra o de pago que superan los $5,000 requieren la aprobación de parte de
la dirección financiera.

 La dirección financiera valida todas las órdenes de compra y de pago que superan los $
5,000, si fueran rechazados, entonces se anula el requerimiento asociado a estas órdenes
de manera automática y este flujo culminaría. Si la dirección financiera aprueba las
órdenes, entonces se envía este documento al proveedor para su atención y el flujo
concluye.

 El procedimiento de aprobación para órdenes de compra o de pago que superan los

$5,000, son establecidas por la dirección financiera, en función al siguiente flujo y
parámetros definidos:

 Se requiere la evaluación para su aprobación por parte de la dirección financiera

cuando los montos de las órdenes están dentro del rango de $ 5,000 hasta $
100,000.

 Se requiere la evaluación para su aprobación por parte de la dirección financiera y

la dirección general cuando los montos las órdenes oscilan en el rango de $
100,000 hasta $ 380,000.

 Se requiere la evaluación para su aprobación por parte de la dirección financiera,

dirección general y el director corporativo cuando los montos de las órdenes son
superiores a $ 380,000.

108
Diagrama de Actividades para Compras Externas (línea destino)

Figura 25 – Proceso de Compras Externas de la Línea Destino

Fuente: Elaboración Propia

109
 A continuación, se describen los lineamientos del proceso gestión de compras externas de la
línea destino:

 El cliente externo (genera los requerimientos considerados costos para la compañía)

registra un requerimiento para luego solicitar la aprobación por parte de su jefatura
directa.

 El cliente solicitante externo, tiene asignado un aprobador, quien decide si procede la

aprobación del requerimiento.

 El aprobador de requerimiento interno, valida la solicitud de aprobación de requerimiento

que podría aprobarlo o rechazarlo, en el caso supuesto que existiera desaprobación del
requerimiento, el aprobador rechaza el requerimiento y por consiguiente se ejecuta la
anulación de manera automática. Si por el contrario el requerimiento fuera aprobado,
entonces se notifica automáticamente vía correo al comprador para su atención. Si luego
de la aprobación de la orden, se identifica que se trata de una regularización (compra
realizada con anticipación), entonces se genera la orden de pago para luego solicitar la
aprobación de la jefatura de compras. Si esta orden es rechazada, entonces provoca la
anulación automática del requerimiento asociado a esta orden y termina el flujo.

 Si el requerimiento aprobado, fuera dirigido a un proveedor con contrato negociado y

vigente, entonces se genera una orden de compra y solicita la aprobación de la jefatura de
compras.

 Si el requerimiento aprobado, fuera para un proveedor sin contrato negociado vigente, el

comprador puede elegir a otro proveedor para atender el requerimiento, solicita la
cotización al proveedor o potencial proveedor, luego la cotización recibida la reenvía al
usuario solicitante para que pueda ser evaluado por este último y si esta cotización fuera
aprobada, el solicitante confirma dicha aprobación al comprador para que este genere la
orden de compra y solicite la aprobación de la jefatura de compras. Si, por el contrario, el
usuario externo no aprueba la cotización, entonces solicita al comprador contactar a otro
proveedor para realizar una nueva cotización.

110
 La jefatura de compras recibe solitudes que requieren la aprobación de órdenes de compra
u órdenes de pago, que puede rechazar y por consiguiente anular su requerimiento
asociado, terminando el flujo. Si, por el contrario, la orden fuera aprobada y esta no
supera los $ 5,000, entonces se envía la orden de compra al proveedor, este atiende y
termina el flujo. Si la orden es superior a $5,000, el jefe de compras solicita la aprobación
a la dirección financiera.

 La dirección financiera debe validar todas las órdenes que superan los $ 5,000, donde las
que resulten rechazadas, anulan su requerimiento asociado y el flujo concluye. Si, por el
contrario, la dirección financiera aprueba la orden, entonces se envía este documento al
proveedor para su atención y el flujo culmina.

 El procedimiento de aprobación para órdenes de compra o de pago que superan los

$5,000, son establecidos por la dirección financiera y se ejecuta el siguiente flujo en
función a los parámetros definidos de la siguiente manera:

 Se requiere la evaluación, para aprobación por parte de la dirección financiera, cuando

los montos las órdenes oscilan en el rango de $ 5,000 hasta $ 100,000.

 Se requiere la evaluación, para aprobación por parte de la dirección financiera y la

dirección general, cuando los montos de las órdenes oscilan en el rango de $ 100,000
hasta $ 380,000.

 Se requiere la evaluación para aprobación por parte de la dirección financiera, la

dirección general y el director corporativo, cuando los montos las órdenes son
superiores a $ 380,000.

111
Roles de Negocio: Matriz RACI
Se elabora la Matriz indicada con la finalidad de identificar a los responsables participantes
del proceso seleccionado en el ámbito del TO BE y poder indicar su grado de injerencia sobre
las actividades propias de este proceso. Se resaltan las nuevas actividades consideradas en la
presente matriz.

RACI CHART Director Financiero (Sponsor)

Comprador Senior
Cliente Aprobador
Jefe de Compras
Auditora Interna

Cliente Externo
Cliente Interno
Comprador

Proveedor
Actividades
Registrar requerimiento I I I I R R
Solicitar aprobación del requerimiento I I I I R R
Validar requerimiento I I A I I R R
Generar Orden de Pago I I A R R
Anular requerimiento I I I I I R R
Elegir proveedor I I R R
Solicitar cotización I R R I
Generar cotización R
Enviar cotización R
Evaluar cotización I I A A
Confirmar aprobación de cotización I R R
Generar orden de compra I C R R
Solicitar aprobación de orden de compra A R R
Validar orden de compra C A I I
Rechazar orden de compra R R I I I I
Solicitar aprobación de dirección A R I I
Notificar Solicitud de aprobación I I I I
Solicitar una aprobación R
Solicitar doble aprobación R C C C
Solicitar triple aprobación R C C C
Notificar Aprobación R I I I
Enviar orden de compra I R I I
Atender orden de compra I I I I R

Tabla 20 - Matriz RACI de la Línea Destino

Fuente: Elaboración Propia

112
Arquitecturas de Sistemas de Información de la Línea Destino

Arquitectura de Datos

Modelo de datos (Proceso de compras Microsoft Dynamics GP)

Se mantiene el modelo original del AS IS.

113
Figura 26 - Modelo de Datos de Línea Destino (Microsoft Dynamics GP)
Fuente: Elaboración Propia

114
Modelo de datos (Proceso de compras Nueva Plataforma)

Figura 27 - Modelo de Datos de Línea Destino (Nueva Plataforma)

Fuente: Elaboración Propia

115
ID ENTIDAD DESCRIPCIÓN
Entidad que contiene los datos de configuración de
E021
AnaliticaConfiguracion centros de costos (cliente, operación, sucursal)
Entidad que contiene los datos de configuración de
E022 aprobación de órdenes de compra por rangos de
AprobacionOC montos
Entidad que contiene los datos de grupos por
E025
AprobadorUsuarioRQ aprobadores y solicitantes de requerimientos
E028 Categoria Entidad que contiene los datos categoría de articulo
Entidad que contiene los datos de contratos de precios
E031
ContratoProveedor negociados
Entidad que contiene los datos de detalles de contratos
E034
ContratoProveedorDet de precios negociados
Entidad que contiene los datos el estado de los
E037
EstadoContrato contratos (trabajo, anulado, vencido)
Entidad que contiene los datos de estados de las
E040 órdenes de compra (trabajo, enviado, aprobado
EstadoOrdenCompra parcialmente, aprobado, rechazado)
Entidad que contiene los datos de estados de los
requerimientos (trabajo, solicitado, aprobado parcial,
E041
aprobado, atendido completo, atendido parcial,
EstadoRequerimiento anulado, rechazado)
Entidad que contiene los datos de grupos organizados
E042
Grupo por áreas, jefaturas, etc.)
Entidad que contiene los datos de las notificaciones
E043
Mensaje por correos
Entidad que contiene los datos de las ordenes de
E044
OrdenCompra compras
Entidad que contiene los datos de detalles de las
E045
OrdenCompraDet órdenes de compra
E046 OrdenCompraAprobacion Entidad que contiene los datos de órdenes de compra

116
 que requieren aprobación de la dirección
Entidad que contiene los datos de prioridad de los
E047
Prioridad requerimientos (alta, media, baja)
E048 Requerimiento Entidad que contiene los datos de requerimientos
Entidad que contiene los datos de los detalles de
E049
RequerimientoDet requerimientos
Entidad que contiene los datos de artículos solicitados
E050
RequerimientoAsi y atendidos
Entidad que contiene los datos de dimensión asignada
E051
RequerimientoDim a los requerimientos (cliente, operación, sucursal)
Entidad que contiene los datos de (cliente interno o
E052
TipoConsumo cliente externo)
Entidad que contiene los datos de tipos de contratos
E053 (contratos de precios negociados y contratos de
TipoContrato alquileres)
Entidad que contiene los datos de tipo de orden de
E054
TipoOrdenCompra compra (artículos, activos, servicios)
Entidad que contiene los datos de tipo de
E055
TipoRequerimiento requerimiento (artículos, activos, servicios)
Entidad que contiene los datos de tipo por categoría de
E056
TipoRequerimientoCategoria requerimientos
Entidad que contiene los datos de requerimientos que
E057
RequerimientoAprobacion requieren aprobación y seguimiento
Entidad que contiene los datos de multiempresa,
E058 soportado en una fase dos (donde se espera el soporte
Empresa multicompañía)
Entidad que contiene los datos de la configuración
E059
EnvioCorreo para notificaciones vía correo
E060 Usuario Entidad que contiene los datos del usuario
Tabla 21 - Cuadro detalle de entidades de la Línea Destino
Fuente: Elaboración Propia

117
Matriz de datos del proceso seleccionado vs Procesos del Negocio
Procesos de la Organización
Estratégicos Operativos Soporte

Seguridad, Salud Ocupacional y

Operaciones de Outsourcing

Administración de Personal

Comunicaciones Internas y
Planeamiento Estratégico

Outsourcing de Nóminas
Consultoría y Formación

Satisfacción del Cliente

Selección de Personal
Gestión de la Mejora
Gestión Financiera

Atención al Cliente

Gestión Humana
Auditoría Interna

Medio Ambiente
Asesoría Legal

Contabilidad
Facturación

Cobranzas
Tesorería
Temporal

Compras

Externas

IT
Entidades del Proceso
AnaliticaConfiguracion X X
AprobacionOC X
AprobadorUsuarioRQ X X
Categoria X
ContratoProveedor X
ContratoProveedorDet X
EstadoContrato X
EstadoOrdenCompra X X X
EstadoRequerimiento X
Grupo X
Mensaje X
OrdenCompra X X X
OrdenCompraDet X X
OrdenCompraAprobación X X
Prioridad X
Requerimiento X
RequerimientoDet X
RequerimientoAsi X
RequerimientoDim X
TipoConsumo X
TipoContrato X
TipoOrdenCompra X
TipoRequerimiento X
TipoRequerimientoCategoria X
RequerimientoAprobacion X X
Empresa X
EnvioCorreo X
Usuario X

Tabla 22 - Matriz Datos del Proceso vs Procesos del Negocio de la Línea Destino
Fuente: Elaboración Propia

118
Arquitectura de Aplicación

Diagrama de Aplicaciones y Descripción

Microsoft Dynamics GP
linked server GC
Personalizaciones

Financiero Administración Inventario

Consultas y
Reportes

Ventas Compras SmartList

Gestor de Compras

Seguridad Configuración Órdenes Integración con GP

linked server GP

Requerimient
Aprobación Reportes
o

Figura 28 – Diagrama de Aplicación de Gestión para Compras de la Línea Destino

Fuente: Elaboración Propia

Este diagrama representa la propuesta de aplicación como soporte al proceso de gestión de

compras para permitir cumplir las políticas que exige este proceso (los recuadros en color
rojo representa el componente afectados en Microsoft Dynamics GP 2010 y los componentes
en el nuevo sistema Gestor de Compras), para este cumplimiento se actualiza el componente
de personalizaciones de Microsoft Dynamics GP 2010 donde continua la centralización de
órdenes de compras y para el alineamiento de las funcionalidades del sistema con las políticas
del proceso de compras, se implementará un sistema Gestor de Compras, integrado a

119
Microsoft Dynamics GP 2010 para garantizar la continuidad de los procedimientos de los
demás procesos posteriores al proceso de compras.

Matriz de Aplicaciones del proceso seleccionado vs Procesos del Negocio

Aplicaciones del Proceso

Seleccionado

Microsoft Dynamics GP -

Gestor de Compras
Procesos de Negocio Módulo Compras
Gestión de la Mejora X
Estratégicos

Gestión Financiera X
Planeamiento Estratégico
Auditoría Interna X X
Asesoría Legal
Atención al Cliente X
Selección de Personal
Operaciones de Outsourcing
Operativos

Outsourcing de Nóminas
Consultoría y Formación
Administración de Personal Temporal
Facturación
Satisfacción del Cliente X
Compras X X
Comunicaciones Internas y Externas
Gestión Humana
Soporte

IT
Seguridad, Salud Ocupacional y Medio Ambiente
Contabilidad X
Cobranzas
Tesorería X

Tabla 23 – Matriz Aplicaciones del Proceso vs Procesos de Negocio Destino

Fuente: Elaboración propia

120
Arquitectura Tecnológica de Línea Destino
Componentes de tecnología y sus relaciones con los sistemas de información

FRONT OFFICE
Suite
<<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information

Services
Servidor:SUITE

<<Web Application>>
SUITE

MIDDLE OFFICE

Satélite Comercial Facturación Electrónica

ER – Entregas a Rendir
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2 <<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
Services Instancia: Services Instancia: <<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard
Servidor:SUITE DBSQLONE\GPPROD Servidor:MSPEADECC032 DBSQLONE\FEPROD
<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
Services Instancia:
<<data base>> <<data base>> Servidor:MSPEADECC032 DBSQLONE\GPPROD
<<Web Application>> <<Web Application>>
Satelite SATELITE SGDPER MercurioBD
<<data base>>
GPPAC
<<Web Application>>
ER <<data base>>
GPPAI
<<Mobile Application>> <<data base>>
ERMOVIL GPPAP

Fractal Integrador
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard
Microsoft Dynamics GP
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2 <<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard
Services Instancia:
Servidor: FRACTAL DBSQLTWO\FRACTAL
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Application>> <<data base>>

FRACTAL <<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
PAYROLL
Services Instancia:
<<Web Application>> <<data base>> Servidor:SUITE DBSQLONE\GPROD
FRACTAL FRACTALHIST
<<data base>> <<data base>>
<<Web Application>> DYNAMICS GPPAI
HISTÓRICO
<<C/S Application>> <<data base>> <<data base>>
Dynamics.exe GPIN GPPAP

<<data base>>
GPPAC

Asistencia BL
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard

Dynamics CRM
<<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2

Services Instancia:
Servidor:SUITE DBSQLONE\LEGACYS

<<Web Application>>
BL-Asis
<<data base>>
LegacyDB Adecco Top <<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard

<<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard

Gestor de Compras
<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
Services Instancia:
Servidor:SUITE DBSQLONE\CRM
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard <<C/S Application>> <<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard
Dynamics.exe <<data base>>
<<data base>> SCRM_CONFIG
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard ADECCO_PERU_ <<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard
S_A_MSCRM <<data base>>
<<database system>> SQL Server 2008 R2 CRMIN <<database system>> SQL Server 2008 R2
<<Web Server>> Internet Information <<Web Server>> Internet Information
Services Instancia: Services Instancia:
<<data base>> DBSQLONE\LEGACYS
Servidor:SUITE DBSQLONE\LEGACYS Servidor:MSPEADECC032
Demo_MSCRM

<<Web Application>> <<data base>> <<Web Application>>

AdeccoTOP LegacyDB GESCOM <<data base>>

Gestión Desempeño GESCOM

<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard
Bonos y Comisiones
<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2

Services Instancia: <<device>> Windows Server 2008 R2 Standard
<<device>> Windows Server 2008 R2 Standard
Servidor:MSPEADECC032 DBSQLONE\LEGACYS

<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Application>> <<Web Server>> Internet Information <<database system>> SQL Server 2008 R2
SGDPER <<data base>> Instancia:
Services
LegacyDB DBSQLONE\LEGACYS
Servidor:SUITE

<<Web Application>>
Bonos&Comisiones <<data base>>
LegacyDB

BACK OFFICE
Workflow GP
<<device>> Windows Server 2008 R2 Standard <<device>> Windows Server 2008 R2 Standard

<<OS>> Windows Server 2008 R2 Standard <<OS>> Windows Server 2008 R2 Standard

<<Web Server>> Internet Information <<database system>> SQL Server 2008 R2

Services Instancia:
Servidor:SUITE DBSQLONE\GPPROD

<<Web Application>>
DynamicsWorkFlowGP <<data base>>
WSS_CONTENT

Figura 29 – Componentes de tecnología y Sistemas de información de Línea Destino

Fuente: Tecnologías de la Información – Adecco Perú

121
 El gráfico anterior presentado es la representación de los componentes de tecnología de
destino que sirven de soporte a todos los procesos de la compañía Adecco Perú. En este se
puede observar que el único cambio en relación a los componentes de tecnología de línea
base, es la implementación de un nuevo sistema Gestión de Compras.

 Suite: es una aplicación de front oficce que contiene los accesos directos a todos los
sistemas de la capa muidle office.

 Satélite comercial: es una aplicación que contiene todos los detalles de los contratos
establecidos entre Adecco Perú y sus clientes (servicios, operaciones, re-facturación,
adendas, distribución de centros de costos, periodos facturables, margen de utilidad, etc.)

 Facturación electrónica: es una aplicación que permite intercambiar comprobantes

electrónicos con los clientes y SUNAT, es el soporte de los procesos facturación y
contabilidad, contribuye a la mejora del medio ambiente y su valor agregado es el acceso
a beneficios financieros, a través del factoring electrónico.

 ER- Entregas a Rendir: es una aplicación que está orientado a los rembolsos por gastos de
movilidad, alimentación, estadía que un empleado pudiera haber incurrido durante las
tareas laborales. Así como también permite a los responsables de la gestión de los fondos
de la organización poder informar, justificar y ser responsables de la aplicación de los
recursos puestos a su disposición.

 Fractal: es una aplicación que permite automatizar y gestionar la nómina interna de

manera rápida y efectiva con la configuración de múltiples tipos de planilla y la
posibilidad de gestión varias empresas desde una sola solución.

 Asistencia BL: es una aplicación que permite capturar la hora de ingreso y salida del
personal, estos datos son enviados al sistema Fractal.

 Microsoft Dynamics GP, es el ERP que soporta seis procesos de la organización y

permite extender y conectar con aplicaciones de Microsoft y de terceros.

 AdeccoTop: es una aplicación legacy desarrollada por la compañía con la finalidad de

automatizar distintos procesos propios del negocio de la compañía.

122
 Microsoft Dynamics CRM: es una aplicación sobre la que se soporta Adecco para lograr
los objetivos centrados en la relación con sus clientes en las fases de adquisición y de
fidelización.

 Gestión de Desempeño: es una aplicación que permite medir el esfuerzo aplicado a los
empleados de Adecco Perú para evaluar su gestión encaminada al cumplimiento de la
misión a partir de la mejora de los procesos.

 Bonos y comisiones: es una aplicación que permite configurar los parámetros para el
cálculo de los bonos de los directivos de Adecco y la asignación de comisiones que la
organización realiza a un empleado por los servicios que prestan.

 WorkFlow GP: es una aplicación Back Office que permite contralar los flujos de trabajo
definidos en Microsoft Dynamics GP.

 Gestor de Compras: es una aplicación que implementa las funcionalidades declaradas

para el proceso de compras (declaración de negociaciones de precios con proveedores,
flujos de aprobaciones por rangos de precio, generación de órdenes de pago por
regularización de compras).

123
Plataforma de tecnología y su descomposición

Capa de Capa de Presentación

Seguridad
APLICACIONES WEB
(.NET)

Capa Middleware
CAPA DE SEGURIDAD DE LA INFORMACION Y CONTROL DE ACCESOS

Capa de
Administración
APLICACIONES CLIENTE- SERVIDOR
(.NET, Dexterity)

APLICACIONES WEB
(.NET)

ADMINISTRACIÓN
Capa de base de datos

BASE DE DATOS DE ALTA DISPONIBILIDAD BASE DE DATOS DE PROCESOS NO CRITICOS

Figura 30 – Plataforma de tecnología y su descomposición de Línea Destino

Fuente: Elaboración Propia

En esta plataforma el TOBE no se modifica en comparación al ASIS.

La capa de seguridad, es donde residen las aplicaciones para administrar y controlar los
accesos de los usuarios que interactúan con los sistemas en Adecco.

La capa de presentación sitúa la tecnología para soportar las aplicaciones de presentación

siendo una de estas la “Suite de Adecco”.

La capa middleware en Adecco, facilita la interacción entre las aplicaciones, bases de datos,
redes, hardware y sistemas operativos.

124
La capa de base de datos aloja y permite administrar los datos y están separados en función a
su alta disponibilidad (por ejemplo, Fractal, GP, Satélite y CRM) y la de los procesos no
críticos (Bonos y comisiones y Entregas a Rendir).

La capa de administración en Adecco permite organizar la distribución de la red y el estado

de los equipos clave, así como por ejemplo para lograr obtener estadísticas de red.

Ambientes y ubicaciones
Agrupamiento de las tecnologías requeridas para cada ambiente informático

Construcción y ¿Existe
Desarrollo

documentación iteración?
Proceso General de desarrollo

Informe de implementación

Pruebas de ¿Existe
Pruebas

aceptación iteración?

Registro de aceptación

¿Existe
Paso a producción
iteración?
Producción

Plan de Registro de Aceptación

implementación capacitación del cambio

Figura 31 – Ambientes y ubicaciones informáticas de Línea Destino

Fuente: Elaboración Propia

Estos ambientes y ubicaciones del TOBE no se modifican con respecto al ASIS.

El ambiente de desarrollo, dispone de Visual Studio .NET 2010, SQL Server 2008 R2, una
bitácora logging y herramientas para monitoreo de desempeño y debugginng. Este ambiente

125
tiene características similares en software e infraestructura que los ambientes de pruebas y
producción. Este ambiente está alojado en servidores de un datacenter provisto por un
proveedor. El nombre de dominio, se diferencia por el prefijo DESA. Todos los
requerimientos están documentados, los desarrolladores usan este ambiente en exclusividad
(no los otros ambientes directamente), donde se tienen datos de prueba y donde se ejecutan
rutinas que trasforma los datos sensibles que son traídos desde pruebas o producción.

El ambiente de pruebas, dispone de los artefactos que se usan para las pruebas, residen en el
servidor compartido y no en las computadoras de los desarrolladores. Este ambiente tiene
características muy similares al ambiente de producción. Está alojado en servidores de un
datacenter provisto por un proveedor. Este ambiente tiene capacidad para atender a múltiples
audiencias para la ejecución de pruebas por ejemplo a administradores, usuarios finales y
desarrolladores. El nombre de dominio, se diferencia por el prefijo QA. Los desarrolladores
no tienen privilegios para hacer cambios en este ambiente, donde se ubican datos de prueba y
donde se tiene una rutina que trasforma los datos sensibles que son traídos desde producción.
Existe un administrador que es el único que despliega los cambios solicitados, existe un
registro para control de cambios que soporta el rastro de las modificaciones.

El ambiente de producción, es el ambiente donde radican las aplicaciones finales, aquí se

dispone de un entorno donde perfectamente se despliegan las aplicaciones siguiendo los
procedimientos de pase a producción autorizados por el dueño de los procesos afectados y
por el jefe de sistemas. Este servidor está desplegado en un centro de datos brindado por un
proveedor de tecnología. En Adecco existen protocolos establecidos para la definición de
calendarios y poder realizar el pase a producción.

126
Comunicaciones físicas (red)

Figura 32 - Diagrama de Red de Línea Destino

Fuente: Elaboración propia

Especificaciones de hardware y red

Host Virtual Machine
Content
IP VM Name Use Processor Family CPU (Cores) RAM Disk IP Content
MS Dynamics GP MS Dynamics GP ERP aplication
Intel Xeon E5-
MSPEADECCO32 Aplication Server 8 32 GB 1 TB 192.0.20.50 Plataforma de Gestión Plataforma de Gestión
2600 v3 3.5 GHz
192.0.20.20 de Compras (In House) de Compras (In House)
ProLiant 360DL ERP Database MS Dynamics GP ERP Database
Intel Xeon E5-
DBSQLONE Database Server 12 64 GB 3 TB 192.0.30.32 Plataforma de Gestión Plataforma de Gestión
2600 v3 3.5 GHz
de Compras (In House) de Compras (In House)

WorkSations
IP Use Processor RAM Disk Content
192.0.XX.XX Estación Intel Core i5-6300U 2.40 GHz 8 GB 250 GB ERP Access

Equipos de comunicación
Cantidad Use Descripción Capacidad Locación
1 Comunicaciones Switch Cisco Nexus 56128P 2.56 Tbps Site HP
1 Comunicaciones Router Cisco 4431 Site HP
1 Comunicaciones Switch Cisco Nexus 5672UP 1.44 Tbps Site Adecco
1 Comunicaciones Router Cisco 4331 Site Adecco

Tabla 24 - Especificaciones de Red y Hardware de Línea Destino

Fuente: Elaboración Propia

127
ANÁLISIS DE BRECHAS
Análisis de Brechas por Arquitectura de Negocio

Proceso de Gestión de Compras

Arquitectura de Destino
Solicitar Confirmar Generar Solicitar Validar Rechazar Solicitar Solicitar Solicitar Enviar Atender
Regis trar Anular Validar Elegir Solicitar Generar Enviar Evaluar Notificar Solicitar una Notificar
aprobación aprobación orden de aprobación orden de orden de aprobación a triple doble orden de orden de
requerimiento requerimiento requerimiento proveedor cotización cotización cotización cotización s olicitud aprobación aprobación
requerimiento cotización compra a Jefatura compra compra Dirección aprobación aprobación compra compra
Regis trar
M
requerimiento
Solicitar aprobación
M
requerimiento
Anular requerimiento M
Validar requerimiento M
Bus car proveedor A
Solicitar cotización M
Generar cotización M
Enviar cotización M
Reenviar cotización
Arquitectura de Linea Base

Evaluar cotización M
Confirmar aprobación
M
cotización
Generar orden de
M
compra
Solicitar aprobación
M
Jefatura
Validar orden de
M
compra
Rechazar orden de
M
compra
Solicitar aprobación
M
Dirección
Verificar orden de
compra
Enviar orden de compra M
Atender orden de
M
compra
NUEVO I I I I I

Leyenda M: Mantener A: Actualizar E: Eliminar I: Implementar

Tabla 25 - Matriz de Análisis de Brechas por Arquitectura de Negocio

Fuente: Elaboración Propia

128
Análisis de Brechas por Arquitectura de Negocio
Los GAP identificados en el análisis de las Arquitecturas de Negocio son los siguientes:

ID BRECHA DESCRIPCIÓN
Las búsquedas de los proveedores y ofertas en
adquisición de productos y servicios son extensas, lo
que incrementa el periodo de gestión de compra. Se
busca implementar una herramienta donde se
GAP001 Tratamiento de Proveedores
configuren contratos preestablecidos, con precios
previamente negociados y definidos, además de
posibilitar el registro y selección de los distintos
proveedores con los que cuenta el negocio.
Las solicitudes de aprobación pasan en la actualidad
por perseguir a los roles aprobadores con un medio
físico y una acción manual (firma del documento).
Estas solicitudes muchas veces no son atendidas en
el momento requerido, siendo aplazadas por
actividades prioritarias y traspapeladas en alguna
bandeja de atención que finalmente puede ocasionar
una pérdida del documento. Se busca implementar
GAP002 Manejo de Notificaciones
una plataforma que permita contar con
notificaciones automáticas que involucren un nivel
de configuración para las prioridades definidas por
el negocio. Además, dicha solución debe permitir
administrar y almacenar el sustento digital para
aprobación, permitiendo al rol aprobador
correspondiente pueda realizar, vía sistema, la
acción final de aprobación.
Disponibilidad de Las acciones actuales de aprobación actualmente
GAP003 información para demandan exceso de material físico (papeles) para
aprobaciones revisión y tomar decisión sobre la aprobación. En

129
 muchas ocasiones la persecución para la obtención
de firmas termina con un traslado incompleto de la
documentación y la perdida de oportunidad para
ejecutar la generación de las órdenes de compra. Se
requiere incorporar una herramienta que permita
digitalizar y centralizar la información de sustento,
además de poder configurar con facilidad los montos
de aprobación definidos, permitiendo asignar
automáticamente esta configuración a los roles
aprobadores correspondientes.
Tabla 26 - Brechas identificadas por Arquitecturas de Negocio
Fuente: Elaboración Propia

Análisis de Brechas por Arquitectura de Datos

Arquitectura de Destino

Model o de Da tos Mi cros oft Dyna mi cs GP Model o de Da tos Integra do Propues ta Pl a taforma
Arquitectura de Linea Base

Model o de Da tos
Mi cros oft M
Dyna mi cs GP

Nuevo I

Leyenda M: Ma ntener A: Actua l i za r E: El i mi na r I: Impl ementar

Tabla 27 - Matriz Análisis de Brechas por Arquitectura de Datos

Fuente: Elaboración Propia

130
 El GAP identificado durante el análisis de las Arquitecturas de Datos es el siguiente:

ID BRECHA DESCRIPCIÓN
El Modelo de Datos actual, soporte de la ERP de la
organización, no otorga las facilidades esperadas
resultantes del análisis y el time to market requerido
Esquema personalizable para para dedicar el servicio a los clientes internos y
GAP004
Gestión de Compras externos del negocio. Se requiere elaborar un nuevo
modelo que soporte un desarrollo in house para
cubrir la demanda interna de mejora del servicio en
los procesos de Gestión de Compras actuales.
Tabla 28 - Brechas identificadas por Arquitectura de Datos
Fuente: Elaboración Propia

Análisis de Brechas por Arquitectura de Aplicación

Arquitectura de Destino
Mi cros oft Mi cros oft
Sa tél i te Fa ctura ci ón ER-Entrega s Ges tión de Bonos y WorkFl ow Ges tor de
Sui te Fra ctal Dyna mi cs AdeccoTop Dyna mi cs
comerci a l el ectróni ca a Rendi r Des empeño comi s i ones GP Compra s
GP CRM
Sui te M

M
Sa tél i te comerci a l
Fa ctura ci ón
M
el ectróni ca
ER-Entrega s a
M
Arquitectura de Linea Base

Rendi r
Fra ctal M
Mi cros oft
A
Dyna mi cs GP
AdeccoTop M
Mi cros oft
M
Dyna mi cs CRM
Ges tión de
M
Des empeño
Bonos y
M
comi s i ones
WorkFl ow GP M
Nuevo I

Leyenda M: Ma ntener A: Actua l i za r E: El i mi na r I: Impl ementar

Tabla 29 - Matriz de Análisis de Brechas por Arquitectura de Aplicación

Fuente: Elaboración Propia

131
 Los GAP identificados durante el análisis de las Arquitecturas de Aplicación son los
siguientes:

ID BRECHA DESCRIPCIÓN
Adecuaciones requeridas a la solución Microsoft Dynamics GP
Cambios en el para su alineamiento a las políticas de mejoras del proceso de
GAP005 módulo de gestión de compras. El desarrollo in house planteado demanda
compras algunas adecuaciones mínimas con la finalidad de integrarla con
esta nueva plataforma personalizada.
El análisis resultante busca registrar la ejecución de los procesos
Configuración en
actuales de la gestión de compras para aplicar dinamismo en el
GAP006 el módulo de
proceso macro. Se busca redefinir el proceso actual alineándolo
compras
a una propuesta que otorgue mejor nivel de configuración.
Tabla 30 - Brechas identificadas por Arquitectura de Aplicación
Fuente: Elaboración Propia

Análisis de Brechas por Arquitectura de Tecnología

Arquitectura de Destino
Servidor de
Servidor de
Aplicaciones Servidor Físico
Base de Datos
(Virtual) Proliant 360DL
(Virtual)
IIS Framework 4.0
Servidor de
Arquitectura de Linea Base

Aplicaciones
(Virtual) A
IIS Framework 3.5
Servidor de
Base de Datos A
(Virtual)
Servidor Físico
Proliant 360 DL M
Nuevo

Leyenda M: Mantener A: Actualizar E: Eliminar I: Implementar

Tabla 31 - Matriz de Análisis de Brechas por Arquitectura de Tecnología

Fuente: Elaboración Propia

132
 Los GAP identificados durante el análisis de las Arquitecturas de Tecnología son los
siguientes:

ID BRECHA DESCRIPCIÓN
La demanda de mejoras en la plataforma actual, obliga a la
Limitaciones de
incorporación de una nueva solución soportada por la
software del servidor
GAP007 versión IIS Framework 7.0. Se debe realizar la evaluación
de aplicaciones web
de las aplicaciones actualmente soportadas por la versión
IIS
3.0 y programar una homologación de ser necesario.
La propuesta actual involucraría el alojamiento de una
Limitaciones de nueva solución y su correspondiente base de datos. Es
GAP008 infraestructura de indispensable la evaluación para que el proveedor destine
servidores más recursos a los servidores virtuales que alojan la actual
solución.
Tabla 32 - Brechas identificadas por Arquitectura de Tecnología
Fuente: Elaboración Propia

Evaluación del Impacto

Objetivo Estrategico: Incrementar el valor de los accionistas y de las utilidades en un 15% para el
ejercicio en curso
Escala de Impacto en la organización
Consideraciones de la propuesta Línea Destino Muy Bajo Bajo Moderado Alto Muy Alto
Aumento del costo
Aumento del costo Aumento del costo Aumento del costo Aumento del costo
1. Plantear un nuevo proceso para la gestión de Costo operativo
operativo < 10% operativo < 20% operativo > 40% operativo > 50%
compras. insignificante
2. Proponer el uso de una nueva plataforma de Incremento
Incremento de Incremento de Incremento de Incremento de
gestión de compras. Tiempo impercetible de las
operación < 10% operación < 20% operación > 40% operación > 50%
operaciones

Evaluación:

La propuesta de un nuevo proceso y uso de una nueva plataforma pueden impactar en las
variables costo y tiempo, definidas sobre el objetivo identificado. La primera al proponer un
nuevo proceso puede demandar el involucramiento de mayores recursos para completar el
flujo, esto conlleva a incrementar el presupuesto actual planificado. De la misma forma, el
incremento en tiempo de uso de la nueva plataforma podría incrementar negativamente los
servicios que se brindan al cliente, esto supone una reacción adversa de los mismos y dejar de

133
percibir los ingresos económicos esperados. Ambos casos, dentro de las escalas identificadas
(Alto y Muy Alto) impactarían negativamente sobre la organización y el cumplimiento de los
objetivos definidos.

Objetivo Estrategico: Participar activamente en la estructuración de un modelo de negocio sostenible

para el cliente sosteniendo el 85% del indicador del SGC
Escala de Impacto en la organización
Consideraciones de la propuesta Línea Destino Muy Bajo Bajo Moderado Alto Muy Alto
Participación Participación Participación
Participación activa Participación baja
Tiempo dedicada de parcial de imperceptible de
1. Plantear un nuevo proceso para la gestión de de involucrados involucrados
involucrados involucrados involucrados
compras.
Completar Indicadores de Seguimiento Indicadores de
2. Proponer el uso de una nueva plataforma de Indicadores de
lineamientos de calidad parcial a la calidad calidad
gestión de compras. Calidad calidad no han sido
calidad a las tareas completados a un de los completados en un
referenciados.
de la propuesta 90% planteamientos 50%

Evaluación:

En base al objetivo planteado y las consideraciones de la propuesta destino, se manejan las

variables tiempo y calidad para la evaluación de impacto. Sobre tiempo se declara la
participación de los involucrados e interesados en la elaboración de la propuesta. La
participación baja e imperceptible son de Alto y Muy Alto impacto negativo sobre la
organización para la consecución de lo planteado que permite sostener de mejor manera el
proceso de compras para asegurar la satisfacción del cliente. De igual forma, la calidad
relacionada a los indicadores requeridos por el Sistema de Gestión de Calidad (SGC) de
Adecco, exige cumplir con ciertas políticas en el desarrollo de los proyectos internos. No
cumplir a cabalidad con estos indicadores se resumen también en un impacto negativo para la
organización.

Objetivo Estrategico: Conservar la fidelidad de los clientes actuales e incrementar la cartera de los
mercados objetivos identificados en un 15%.
Escala de Impacto en la organización
Consideraciones de la propuesta Línea Destino Muy Bajo Bajo Moderado Alto Muy Alto
Presupuesto No se concreta la
completado para Presupuesto Presupuesto Presupuesto planificación para
Costo
aplicación de ejecutado > 90% ejecutado al 60% ejecutado < 50% ejecutar el
1. Plantear un nuevo proceso para la gestión de mejoras presupuesto.
compras. Incremento del
Ejecutar la Incremento del Incremento del Tiempo de
2. Proponer el uso de una nueva plataforma de tiempo de
Tiempo propuesta en el tiempo de tiempo de ejecución excedido
gestión de compras. ejecución en un
plazo de 4 meses ejecución < 20% ejecución > 50% en un 100%
3. Invertir en tecnología para la adecuación de 40%
la plataforma propuesta. Se cubre solo el
Extender mejoras a Adecuación de Adecuación al 60% Adecuaciones
50% de clientes a
Alcance clientes antiguos y mejoras solo a la de clientes imperceptibles
los nuevos
nuevos cartera actual. actuales para clientes
procesos

134
Evaluación:

La evaluación gira sobre tres variables costo, tiempo, alcance para el total de consideraciones
de la propuesta. El planteamiento del nuevo proceso, uso de nueva plataforma e inversión en
la tecnología relacionada, en primer lugar, lleva a evaluar el nivel de presupuestado
ejecutado, con respecto al tiempo, el plazo de ejecución de la propuesta y sobre el alcance, la
aplicación de mejoras al total de clientes actual de la organización. Estas condiciones llevan a
asegurar la cartera actual de clientes y extender posibilidades sobre mercados objetivos
adicionales tomando en consideración la satisfacción del cliente.

Objetivo Estrategico: Optimizar los procesos de servicios, mejorando la calidad y distribución de

estos a través de la aplicación de mejoras al SGC y el cumplimiento de los indicadores actuales
Escala de Impacto en la organización
Consideraciones de la propuesta Línea Destino Muy Bajo Bajo Moderado Alto Muy Alto
Mediciones
Resultados de
satisfactorias del Resultados de Resultados
1. Plantear un nuevo proceso para la gestión de Resultados de encuesta de
Calidad nivel de encuesta de insatisfactorios y <
compras. niveles > al 80% calidad entre el
satisfacción al servicio < 70% 50%
70% y 80%
cliente

Evaluación:

Esta evaluación gira en torno a la variable calidad sobre el cambio de proceso propuesto. Su
optimización y la aplicación de mejoras al SGC permiten obtener información acerca de la
satisfacción al cliente y organizar la gestión de la misma. En este sentido, el planteamiento
del nuevo proceso debe ir alineado a la gestión de calidad de la organización y permitir
obtener indicadores de satisfacción del cliente, siendo de impacto negativo y muy alto para
Adecco que los resultados sean inferiores a la meta trazada.

Objetivo Estrategico: Fortalecer y ampliar los canales de comunicación interna para la recepción y
retroalimentación correcta a consultas, quejas, reclamaciones como fuente principal de información y
de mejora reduciendo el indicador de incidencias al 10%
Escala de Impacto en la organización
Consideraciones de la propuesta Línea Destino Muy Bajo Bajo Moderado Alto Muy Alto
Propuesta Propuesta Operaciones de
Operaciones No existe canal de
integrada con el parcialmente atención al cliente
Alcance manuales para atención en la
proceso de integrada con cubiertas
2. Proponer el uso de una nueva plataforma de atender al cliente implementación
atención al cliente atención al cliente parcialmente
gestión de compras.
Porcentaje
3. Invertir en tecnología para la adecuación de Número de
considerable de Porcentaje de Incidencias no
la plataforma propuesta. incidencias < 10%
Calidad cobertura a incidencias > al 10% Incidencias > 50% cubiertas con la
con respecto al
solución de y menor al 40% propuesta
periodo anterior
incidencias

135
Evaluación:

Considerando el objetivo de mejorar la comunicación de cara al cliente y establecer un

proceso que permita dar un feedback adecuado con el planteamiento de la propuesta, se
establecen las variables alcance y calidad basadas en el uso de la nueva propuesta tecnológica
y la inversión tecnológica que involucra. El alcance de dicha propuesta debe llegar a
concretar los lineamientos de comunicación para luego de su implementación permita brindar
el conocimiento de lo que se está haciendo bien y mal en el nuevo esquema. El impacto de no
establecer adecuadamente estas operaciones resulta en un impacto negativo alto y muy alto
para la organización. Con respecto a la calidad se espera que esta sea cubierta en los rangos
de porcentaje establecidos para medir los resultados en implementación de esta propuesta y el
nivel de incidencias históricas y nuevas a resolver. El nivel de incidencias por encima del
50% con respecto al periodo inmediato anterior orienta a resultados altos y muy altos de
impacto negativo para la presente propuesta.

Objetivo Estrategico: Facilitar la disposición de mejores herramientas a los colaboradores para crear
una cultura empresarial ágil, sostenible y responsable, incrementando la inversión en estos medios
en un 45%
Escala de Impacto en la organización
Consideraciones de la propuesta Línea Destino Muy Bajo Bajo Moderado Alto Muy Alto
No es viable la
2. Proponer el uso de una nueva plataforma de La inversión se inversión por
El aumento en la La inversión bordea
gestión de compras. incrementa en un La inversión es superar
Costo inversión no es el 10% de lo
3. Invertir en tecnología para la adecuación de 5% de lo mayor al 60% considerablemente
considerable proyectado
la plataforma propuesta. proyectado el lineamiento
fijado.

Evaluación:

Se usa la variable costo para la consideración de la inversión proyectada. Se considera que la

propuesta no debe superar el valor en inversión del 45% proyectado para el ejercicio en
curso. Acometer los esfuerzos en implementación de la propuesta por encima del 60% ya
resulta de impacto negativo alto y muy alto para la organización pudiendo resultar en su
inviabilidad para el negocio.

136
Evaluación:

Solo la variable alcance es considerada para la propuesta alineada al objetivo indicado. La

propuesta debe permitir cumplir con el objetivo de incremento en la cobertura actual del
negocio potenciando las nuevas líneas de negocio y la satisfacción del cliente sobre el total
del mercado. No cubrir las plazas identificadas con la presente propuesta impacta
negativamente en el lineamiento del objetivo fijado por la organización.

Objetivo Estrategico: Incrementar la inversión en un 25% destinada a capacitación, mejorando la

satisfacción de los colaboradores, aumentando los incentivos trimestrales y el paquete de beneficios
actual con alianzas estratégicas
Escala de Impacto en la organización
Consideraciones de la propuesta Línea Destino Muy Bajo Bajo Moderado Alto Muy Alto
Se establecen otros
1. Plantear un nuevo proceso para la gestión de métodos
compras. Cubierta la Inversión objetivo contingentes para
2. Proponer el uso de una nueva plataforma de capacitación sobre es superada en 5% Inversión objetivo Inversión por capacitar sobre la
Costo
gestión de compras. la nueva propuesta para alinear a los es igual al 40% encima al 50% nueva propuesta
3. Invertir en tecnología para la adecuación de e implementación nuevos procesos pero sin alinearse a
la plataforma propuesta. las expectativas
iniciales.

Evaluación:

Se alinea el costo con la propuesta y el objetivo planteado en inversión sobre capacitación.

Este no debe exceder las expectativas planteadas para permitir cumplir con las expectativas y
venta de las mejoras al interno de la organización.

137
OPORTUNIDADES Y SOLUCIONES

Desglose de la Implementación de Proyectos y Carteras

En Adecco existen proyectos orientados a la aplicación de la arquitectura empresarial.

Proyectos declarados para los siguientes procesos de negocio:

 Gestión Financiera: libros y registros electrónicos para SUNAT

 Auditoría Interna: pistas de auditorías y asignaciones de privilegios

 Selección de Personal: integración con servicios de Reniec

 Operaciones de Outsourcing: administración de inventarios de operaciones

 Compras: flujos de aprobaciones, negociaciones con proveedores y órdenes de pago

 Gestión Humana: evaluaciones de desempeño

 SOMA: regularizaciones de servicios por evaluaciones médicas

 Tesorería: integraciones con host bancarios

138
Estructura de desglose del trabajo

Figura 33 – Estructura de desglose del trabajo

Fuente: Elaboración propia

139
Cuadro resumen del plan de Migración
ID Brecha Proyecto Problema Solución Potencial Costos
Riesgos de la Solución
No mantener
actualizada la base de
SOL1: Disponer de información de
PB1: Búsqueda de
Tratamiento de funcionalidad para el manejo de proveedores,
GAP001 proveedores extensa y $11,184.80
Proveedores contratos negociados con contratos y precios
manual negociados afecta la
proveedores
evaluación de la
compra.
Directorio
SOL2: Disponer de desactualizado de
PB2: Notificaciones
funcionalidad que facilite poder cuentas de correo
Manejo de manuales para
GAP002 contar con notificaciones a todo $17,356.90 para solicitantes y
Notificaciones aprobaciones de las
nivel y otorgar los niveles de aprobadores de
órdenes de compra órdenes de compras
aprobación requerido
retrasa la aprobación.

Falta de digitalización
SOL3: Disponer de información de sustentos
PB3: Exceso de
centralizada y digitalizada de la requeridos para las
Disponibilidad de documentación física
documentación para facilitar su aprobaciones de las
GAP003 información para para los sustentos de $9,507.30
acceso y agilizar las órdenes de compra y
aprobaciones aprobación de órdenes
aprobaciones de órdenes de órdenes de pago
de compra genera observaciones
compra
o rechazos.

La ausencia de dueños
PB4: Alto costo en de datos durante la
Esquema
cambios al modelo de SOL4: Implementar un modelo definición del alcance
GAP004 personalizable para $9,794.40
datos por su poca de datos flexible y mantenible podría no cubrir todas
Gestión de Compras Plataforma de
flexibilidad las necesidades del
Gestión de
modelo.
Compras
Los cambio excesivos
PB5: Alto costo por posteriores a las
SOL5: Ejecutar cambios mínimos
parte del proveedor definiciones iniciales
Cambios en el y puntuales al ERP actual para
GAP005 para cambios $33,633.60 podrían generar
módulo de compras llevar a cabo las mejoras
funcionales en el ERP sobrecostos y
propuestas replanificación de los
actual
entregables.
La inadecuada
PB6: Limitaciones de configuración de
SOL6: Permitir establecer flujos
configuración en el flujos de aprobación
Configuración en el configurables para solicitudes y
GAP006 ERP para establecer $44,763.40 podrian generar
módulo de compras aprobaciones de órdenes de
flujos de trabajo para aprobaciones no
compra por montos alineadas al proceso
las aprobaciones
de compras.
La actualización del
PB7: Imposibilidad de servidor sin el soporte
Limitaciones de SOL7: Migrar la versión del de un especialista
software del servidor desplegar una solución
GAP007 framework del servidor IIS de $9,678.90 podria conllevar a
de aplicaciones web con característica
v3.0 a v7.0 importantes riesgos
IIS multiplataformas de seguridad y de alto
costo
La ausencia de una
PB8: Recursos SOL8: Actualizar la capacidad de evaluación de los
Limitaciones de componentes a
insuficientes para hardware de los servidores
GAP008 infraestructura de $15,000.00 incorporarse podría
servidores
alojar nuevas virtuales para soportar nuevas afectar el desempeño
soluciones iniciativas de mejora o la disponibilidad
del servidor
TOTAL $150,919

Tabla 33 – Cuadro resumen del plan de migración

Fuente: Elaboración Propia

140
Los costos relacionados al esfuerzo ejecutado al interno de la organización han sido
calculados en base al costo por hora aproximado de cada recurso interno (y proveedor para
cambios en el ERP). Además, se incluye el factor de riesgo para la estimación de tiempos. A
continuación, se presentan los cálculos realizados por GAP (El valor plasmado a alto nivel
para el GAP008 es aproximado al alquiler establecido por hosting):

Project Description Plataforma de Gestión de Compras

Solution Funcionalidad para selección de Proveedores - GAP001

PS Resource Hourly Cost Total Hrs. Total Cost

Business Analyst $ 30.00 40 $ 1,200.00
SW Architect $ 39.00 40 $ 1,560.00
Developer Sr. $ 45.00 80 $ 3,600.00
QA Engineer $ 30.00 32 $ 960.00
SW Support $ 20.00 32 $ 640.00
Project Manager $ 69.00 32 $ 2,208.00
$ - $ -
256 $ 10,168.00

SubTotal ( without Risk ) $ 10,168.00

Risk 10% 10168.00 $ 1,016.80
Total Project COST $ 11,184.80

Role 2016 - Cost Rate 2012 PSA

SW Architect $ 39.00
IT Architect $ 40.00
Business Analyst $ 30.00
Developer Sr. $ 45.00
Project Manager $ 69.00
QA Engineer $ 30.00
SW Support $ 20.00
Proveedor MCS $ 20.00

141
Project Description Plataforma de Gestión de Compras
Funcionalidad para notificaciones automaticas de aprobación -
Solution
GAP002

PS Resource Hourly Cost Total Hrs. Total Cost

Business Analyst $ 30.00 80 $ 2,400.00
SW Architect $ 39.00 56 $ 2,184.00
Developer Sr. $ 45.00 120 $ 5,400.00
QA Engineer $ 30.00 40 $ 1,200.00
SW Support $ 20.00 40 $ 800.00
Project Manager $ 69.00 55 $ 3,795.00
$ - $ -
391 $ 15,779.00

SubTotal ( without Risk ) $ 15,779.00

Risk 10% 15779.00 $ 1,577.90
Total Project COST $ 17,356.90

Role 2016 - Cost Rate 2012 PSA

SW Architect $ 39.00
IT Architect $ 40.00
Business Analyst $ 30.00
Developer Sr. $ 45.00
Project Manager $ 69.00
QA Engineer $ 30.00
SW Support $ 20.00
Proveedor MCS $ 20.00

Project Description Plataforma de Gestión de Compras

Solution Centralización y digitalización de documentación - GAP003

PS Resource Hourly Cost Total Hrs. Total Cost

Business Analyst $ 30.00 40 $ 1,200.00
SW Architect $ 39.00 32 $ 1,248.00
Developer Sr. $ 45.00 52 $ 2,340.00
QA Engineer $ 30.00 32 $ 960.00
SW Support $ 20.00 24 $ 480.00
Project Manager $ 69.00 35 $ 2,415.00
$ - $ -
215 $ 8,643.00

SubTotal ( without Risk ) $ 8,643.00

Risk 10% 8643.00 $ 864.30
Total Project COST $ 9,507.30

Role 2016 - Cost Rate 2012 PSA

SW Architect $ 39.00
IT Architect $ 40.00
Business Analyst $ 30.00
Developer Sr. $ 45.00
Project Manager $ 69.00
QA Engineer $ 30.00
SW Support $ 20.00
Proveedor MCS $ 20.00

142
Project Description Nuevo Modelo de Datos Plataforma de Gestión de Compras
Solution Modelo de Datos para soporte de nueva plataforma - GAP004

PS Resource Hourly Cost Total Hrs. Total Cost

Business Analyst $ 30.00 80 $ 2,400.00
SW Architect $ 39.00 96 $ 3,744.00
Project Manager $ 69.00 40 $ 2,760.00
$ - $ -
216 $ 8,904.00

SubTotal ( without Risk ) $ 8,904.00

Risk 10% 8904.00 $ 890.40
Total Project COST $ 9,794.40

Role 2016 - Cost Rate 2012 PSA

SW Architect $ 39.00
IT Architect $ 40.00
Business Analyst $ 30.00
Developer Sr. $ 45.00
Project Manager $ 69.00
QA Engineer $ 30.00
SW Support $ 20.00
Proveedor MCS $ 20.00

Project Description Mejoras en Microsoft Dynamics GP

Solution Adecuaciones para integridad de información - GAP005

PS Resource Hourly Cost Total Hrs. Total Cost

Business Analyst $ 30.00 120 $ 3,600.00
Proveedor MCS $ 98.00 200 $ 19,600.00
QA Engineer $ 30.00 72 $ 2,160.00
SW Support $ 20.00 40 $ 800.00
Project Manager $ 69.00 64 $ 4,416.00
$ - $ -
496 $ 30,576.00

SubTotal ( without Risk ) $ 30,576.00

Risk 10% 30576.00 $ 3,057.60
Total Project COST $ 33,633.60

Role 2016 - Cost Rate 2012 PSA

SW Architect $ 39.00
IT Architect $ 40.00
Business Analyst $ 30.00
Developer Sr. $ 45.00
Project Manager $ 69.00
QA Engineer $ 30.00
SW Support $ 20.00
Proveedor MCS $ 98.00

143
Project Description Plataforma de Gestión de Compras
Solution Desarrollo Integral de Plataforma Complementos - GAP006

PS Resource Hourly Cost Total Hrs. Total Cost

Business Analyst $ 30.00 160 $ 4,800.00
SW Architect $ 39.00 136 $ 5,304.00
Developer Sr. $ 45.00 360 $ 16,200.00
IT Architect $ 40.00 40 $ 1,600.00
QA Engineer $ 30.00 120 $ 3,600.00
SW Support $ 20.00 80 $ 1,600.00
Project Manager $ 69.00 110 $ 7,590.00
$ - $ -
1,006 $ 40,694.00

SubTotal ( without Risk ) $ 40,694.00

Risk 10% 40694.00 $ 4,069.40
Total Project COST $ 44,763.40

Role 2016 - Cost Rate 2012 PSA

SW Architect $ 39.00
IT Architect $ 40.00
Business Analyst $ 30.00
Developer Sr. $ 45.00
Project Manager $ 69.00
QA Engineer $ 30.00
SW Support $ 20.00
Proveedor MCS $ 98.00

Project Description Actualización de Servidor WEB

Solution Labores de migración a versión IIS 4.0 - GAP007

PS Resource Hourly Cost Total Hrs. Total Cost

SW Architect $ 39.00 32 $ 1,248.00
IT Architect $ 40.00 40 $ 1,600.00
Developer Sr. $ 45.00 16 $ 720.00
Proveedor MCS $ 98.00 40 $ 3,920.00
Project Manager $ 69.00 19 $ 1,311.00
$ - $ -
147 $ 8,799.00

SubTotal ( without Risk ) $ 8,799.00

Risk 10% 8799.00 $ 879.90
Total Project COST $ 9,678.90

Role 2016 - Cost Rate 2012 PSA

SW Architect $ 39.00
IT Architect $ 40.00
Business Analyst $ 30.00
Developer Sr. $ 45.00
Project Manager $ 69.00
QA Engineer $ 30.00
SW Support $ 20.00
Proveedor MCS $ 98.00

Tabla 34 - Tablas de Estimación de Costos del Plan de Migración

Fuente: Elaboración Propia

144
CONCLUSIONES

Adecco Perú adopta desde su inicio tecnología con la que viene trabajando durante sus años
de servicio en el mercado peruano. La tecnología adoptada no le ha permitido desarrollarse
en crecimiento por diversos factores, de los cuales se resalta el dinamismo en la operación
diaria (time to market) que permita responder a las exigencias del mercado.

Si bien es cierto, Adecco Perú ha implementado un conjunto de normas y procedimientos a

los procesos actuales de su organización, a través del Sistema de Gestión de Calidad (SGC),
los cuales han sido formalizados a través de un conjunto de documentos oficializados a través
de su canal de comunicaciones internas, estos deben ir acompañados de una política de
inversión tecnológica alineada a las exigencias del negocio que le permita a la organización
hacer frente a la demanda interna de mejores herramientas para facilitar otorgar resultados de
calidad.

La organización afronta además un planteamiento de recambio total tecnológico, pero la

propuesta actual asume la ejecución de una Arquitectura Empresarial como base, reforzado
con algunos procedimientos sistémicos, y con una propuesta de implementación para la
gestión de compras que otorgue solo los puntos claves adicionales a la operación de usuario y
que otorgue la flexibilidad y el dinamismo que se demanda.

Los proyectos identificados a partir del cruce entre brechas y su relación directa con las
soluciones potenciales definidas resultan, hasta este desarrollo, en una valorización final
estimada de US$ 150,000 contra los US$ 280,000 presupuestados para cubrir iniciativas o
propuestas tecnológicas de mejora actual, lo que hasta el momento permite considerar la
viabilidad en costos de la presente propuesta de Arquitectura Empresarial.

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

INTRODUCCIÓN
En este capítulo se define la metodología propuesta para el desarrollo de software y lograr
automatizar y optimizar el proceso de compras de la compañía Adecco Perú como respuesta
al diagnóstico identificado, mediante la aplicación de dinámicas para potenciar los grupos de
trabajo, el soporte de herramientas ágiles y el apoyo de la metodología SCRUM, elegida bajo
evaluación.

OBJETIVOS
Desarrollar una propuesta de desarrollo de software como solución para el proceso de
Compras de Adecco Perú, alineado con el cumplimiento de los objetivos estratégicos de la
organización y la aplicación de Scrum como metodología del desarrollo de software ágil.

Los beneficios desde la perspectiva de la metodología ágil dirigido a este proyecto son las
siguientes:

 Aceleración del cumplimiento de objetivos, al propiciar un clima auto-gestionado, trabajo

en equipo y adaptado al cambio.

 Disminuir costos con la automatización y optimización, eliminando los cuellos de botella

generados en el proceso de compras y la garantía del cumplimiento de las políticas
establecidas.

 Satisfacción del equipo de compras, con el involucramiento de este, durante la

planificación y ejecución del proyecto, generando sinergias y escatimando recursos.

146
OBJETIVOS DEL CAMBIO PARA EL PROCESO DE COMPRAS

1) Disminuir la carga de trabajo por regularización de compras.

2) Mejorar el desempeño actual del proceso de compras.

3) Optimizar los niveles de aprobación en la gestión de compras.

4) Mejorar e incluir la gestión de contratos con el proveedor.

BENEFICIOS DEL CAMBIO PARA EL PROCESO DE COMPRAS

Se nombran a continuación los beneficios tangibles esperados a partir del planteamiento de
cambio para el proceso en mención:

 Reducción de un 55% del tiempo total de gestión de compras regulares, permitiendo

ofrecer agilidad en la atención requerida por los clientes.

 Cumplimiento en el plazo de 30 días como máximo, estipulado por política, para el pago
de proveedores, salvaguardando la relación con los mismos e indirectamente con el
cliente.

 Eliminación de las órdenes de compra por regularización y tratamiento como órdenes de

pago permitiendo suprimir el sobre esfuerzo generado en los recursos y lograr tener
visibilidad de este tipo de procesos para tomar decisión.

 Lograr que las compras por el flujo negociado representen hasta un 90% del total de
compras estableciendo acuerdos contractuales por precios negociados con los
proveedores.

147
METODOLOGÍAS EVALUADAS
La presente propuesta se concentra en el uso de metodologías ágiles para la consecución del
proyecto. El sustento de la selección se presenta a continuación tomando en cuenta que se
procedió a la evaluación de otras metodologías símiles.

SCRUM
Es una metodología de adaptación, iterativa, rápida, flexible y eficaz, diseñada para ofrecer
un valor significativo de forma rápida en todo el proyecto. Scrum garantiza transparencia en
la comunicación y crea un ambiente de responsabilidad colectiva y de progreso continuo. El
marco Scrum está estructurado de tal manera que es compatible con los productos y el
desarrollo de servicio en todo tipo de industrias y en cualquier tipo de proyecto,
independientemente de su complejidad.14

Tomando como base lo indicado por Jeff Sutherland (2016) [12] se presentan los siguientes
planteamientos, que a consideración son importantes y característicos de esta metodología y
redondean la idea de este marco:

 “Scrum, representa un cambio radical respecto a las metodologías prescriptivas y

verticales de gestión de proyectos del pasado. Scrum se asemeja en cambio a los sistemas
evolutivos, adaptativos y capaces de autocorregirse.”

 “Scrum incorpora los conceptos de mejora continua y productos mínimos viables para
obtener realimentación inmediata de los consumidores, en lugar de esperar hasta que un
proyecto concluya.”

 “Este nuevo enfoque se llama Scrum. Hay dos formas de hacer las cosas: el antiguo
método “en cascada”, que gasta cientos de millones de dólares sin lograr nada, y el nuevo
modo que, con menos personas y en menos tiempo, permite hacer más con mayor calidad
y a menor costo.”

14
Definición tomada de SBOK Guide edición 2016

148
 “Scrum pregunta porque hacer algo implica tanto tiempo y esfuerzo y porque somos tan
malos para calcular cuánto tiempo y esfuerzo absorberá.”

 “Scrum abraza la incertidumbre y la creatividad. Dota de estructura al proceso de

aprendizaje, lo que permite a los equipos evaluar qué crearon e, igualmente importante,
como lo hicieron.”

 “Scrum se vale del trabajo real en equipo y brinda a este último las herramientas
necesarias para organizarse y aumentar en poco tiempo tanto la rapidez como la calidad
de su trabajo.”

 “Scrum se basa en una idea simple: cada vez que se ejecuta un proyecto, ¿Por qué no
revisar con regularidad para ver si lo que se está haciendo sigue la dirección correcta y es
lo que la gente quiere? ¿Por qué no revisar si se puede hacer mejor y más rápido y que lo
impide?”

 “El resultado final de Scrum son equipos que aumentan considerablemente su

productividad.”

Planteados estos puntos podemos concluir inicialmente que Scrum es una metodología
evolutiva y adaptable que busca la mejora continua con las revisiones constantes que se
logran con el trabajo en equipo. Se enfoca en hacer más con menos sin dejar de hacerlo bien,
con el seguimiento iterativo respectivo del avance del trabajo, dotando de los instrumentos
necesarios para conseguirlo. Finalmente, obtenemos mejores equipos, definidos por sus
habilidades y que se vuelven más productivos para la organización.

Visión general del proceso SCRUM

Definido ya como un marco de trabajo iterativo e incremental, Pete Deemer (2012) [13]
brinda una visión general del proceso SCRUM para el desarrollo de proyectos donde “el
desarrollo se estructura en ciclos de trabajo llamados Sprints (también conocidos como
iteraciones). Estas iteraciones no deben durar más de cuatro semanas cada una (siendo dos
semanas la duración más habitual) y tienen lugar una tras otras sin pausa entre ellas. Los

149
Sprints están acotados en el tiempo, finalizan en una fecha determinada independiente de si el
trabajo ha finalizado por completo o no, y jamás se prorrogan. Normalmente los equipos
Scrum escogen una duración de Sprint y la mantienen para todos sus Sprints hasta que
mejoran y pueden emplear ciclos más cortos. Al principio de cada Sprint, un Equipo cross-
funcional (de en torno a siete personas) selecciona elementos (peticiones del cliente) de una
lista priorizada. El equipo acuerda un objetivo colectivo respecto a los que creen que pueden
entregar al final del Sprint, algo que sea tangible y “terminado” por completo. Durante el
Sprint no se pueden añadir nuevos elementos; Scrum se adapta a los cambios en el siguiente
Sprint, pero el pequeño Sprint actual está pensado para concentrarnos en un objetivo
pequeño, claro y relativamente estable. Todos los días el Equipo se reúne brevemente para
inspeccionar su progreso y ajustar los siguientes pasos necesarios para completar el trabajo
pendiente. Al final del Sprint, El Equipo revisa el Sprint con los diferentes Stakeholders y
realiza una demostración de lo que han desarrollado. Se obtiene feedback que pueda ser
incorporado en el siguiente Sprint. Scrum enfatiza un producto “funcionando” al final del
Sprint que está realmente “terminado”. En el caso del software, esto significa un sistema que
está integrado, testeado, con la documentación de usuario generada y potencialmente
entregable.”

El resumen gráfico de lo narrado en la Visión se presenta a continuación:

Figura 34 - Visión general del proceso SCRUM

Fuente: Publicación “Una introducción básica a la teoría y práctica de Scrum”

150
Este proceso basado en Sprints debe obtener lo siguiente:

 Incremento de Producto: nuevas o mejoras de funcionalidades existentes.

 Estabilidad: cada entrega debe estar lista para entrega al usuario, siendo un entregable
parcial que puede ser usado y no tiene errores.

 Valor de Negocio: relevancia de cada entregable, realmente se necesitaba.

La no obtención de lo anteriormente declarado y que es el resultado del trabajo en Sprints,

puede generase debido a las siguientes causas15:

 Falta de claridad en la funcionalidad a implementar. Falta de criterios de aceptación.

 Falta de habilidades técnicas para entender el esfuerzo requerido. Fallar al estimar la

cantidad de trabajo que se puede construir en un Sprint.

 Fallar en dividir el trabajo en porciones pequeñas. Uno de los desafíos está en partir la
funcionalidad en porciones pequeñas, manteniendo la característica de "Valor de
Negocio". Para esto la técnica de "User Stories" juega un papel fundamental.

 Duración del Sprint demasiado corta.

 Falta de motivación y compromiso del Equipo Scrum.

 Falta de entendimiento del sentido de Scrum.

 Interrupciones o distracciones externas que alejen al equipo de su objetivo.

 Falta de trabajo colaborativo en equipo.

 Poca madurez como equipo.

15
Causas y beneficios obtenidos de http://www.caminoagil.com/2015/01/la-magia-de-los-sprints-y-sus-
ventajas.html

151
Los beneficios y propósito de trabajar en Sprints son:

 El usuario se beneficia al utilizar las nuevas funcionalidades desde temprano y con

frecuencia.

 Se recibe feedback de usuarios reales de manera frecuente. El feedback puede ser directo
del usuario o análisis del comportamiento del usuario. Esta información ayuda a tomar
mejores decisiones de producto basadas en datos reales.

 El equipo de desarrollo encuentra una fuente de motivación al entender el impacto del

producto construido durante la iteración en los usuarios. Genera mayor responsabilidad
por la calidad el producto.

 El Product Owner y el Cliente se benefician de poder verificar consistentemente como el

producto desarrollado satisface las expectativas, validando el trabajo realizado.

 El equipo de desarrollo mitiga los riesgos de tecnología verificando con frecuencia como
el producto construido responde en el ambiente real productivo.

 Mayor previsibilidad del equipo y mayor confianza con el resto de la empresa.

 Con Sprints, hay un fuerte sentido de compromiso de entregar al final del Sprint el trabajo
comprometido. El compromiso no viene solo, pero los Sprints proveen el contexto
adecuado para ello.

 Los Sprints permiten verificar la efectividad del equipo para entregar, de manera fácil y
frecuente.

 Trabajar orientado a objetivos es más productivo, motivante y provee alineamiento y

dirección. Completar con el Sprint es el objetivo del equipo. Es recomendable además
incluir una oración que resuma el objetivo a alto nivel.

 Es fácil recolectar métricas (como la velocidad del equipo) y comparar en el tiempo cómo
esas métricas mejoran.

152
 Las planificaciones y predicciones se basan en datos reales empíricos de software
funcional entregado en iteraciones previas.

 El equipo se puede auto-organizar alrededor del trabajo. El equipo es libre de tomar

decisiones técnicas y estrategias para cumplir con el Sprint. Paralelizar trabajo, cambiar el
orden de las tareas, etc. Esto es posible sabiendo cual es el trabajo y sabiendo que no va a
cambiar durante la iteración.

 El equipo se libera de la sobrecarga organizacional sabiendo que el trabajo a realizar no

va a cambiar durante el desarrollo de la iteración. Permite al equipo a focalizarse en el
objetivo e incrementar la productividad.

 Es motivante para el equipo comenzar cada Sprint. No importa cómo fue el Sprint
pasado; este es uno nuevo, con nuevas tareas. Provee una sensación de "nuevo
comienzo". Limpiar el tablero físico y tirar las viejas User Stories completadas da una
sensación de alivio. El mismo alivio de cuando se termina un proyecto o una etapa,
especialmente si el trabajo hecho fue trabajo duro.

 Los Sprints dan la oportunidad de ver los resultados del esfuerzo y dan una razón para
celebrar y reconocer el buen trabajo. Refuerza la motivación y la buena voluntad de
comprometerse a otro Sprint.

 El Sprint permite un ritmo de trabajo constante, sin sobrecargar o estresar al equipo de

desarrollo, lo que permite una productividad mayor a largo plazo y mayor previsibilidad.

 Terminar un Sprint permite adaptar no solo el producto sino también el proceso que se
sigue para construirlo. Esto significa que en cada Sprint el equipo mejora en la forma de
trabajo.

 El trabajo en Sprint permite sincronizar el trabajo del equipo de desarrollo con el Product
Owner. Mientras el primero está construyendo el producto del Sprint actual, el Product
Owner está preparando el Sprint siguiente.

153
 Permite sincronizar el trabajo entre distintos equipos de desarrollo, sabiendo cuándo cada
equipo, va a entregar su parte.

Definidos el entorno de trabajo Scrum, los problemas en su aplicación y los beneficios

otorgados se describen los roles necesarios para la aplicación de este marco de trabajo.

Los Roles
De acuerdo a lo definido por la International Scrum Institute [14] existen 3 roles bien
definidos:

 El Scrum Team
 Scrum Master
 Scrum Product Owner
Estos se encuentran interrelacionados estrechamente en el siguiente gráfico, para el
entendimiento de su rol de trabajo. Se visualiza la relación existente entre el Producto Owner
y los usuarios que establece el alcance de las necesidades del proyecto. El Producto Owner es
el principal canal de comunicación para la definición del trabajo en conjunto que se realiza
con el Scrum Master y el equipo Scrum para la consecución de los objetivos planteados.

Figura 35 - Roles Scrum

Fuente: International Scrum Institute

154
Se realiza a continuación una descripción de los roles establecidos.

El equipo Scrum: Es una colección de personas que trabajan juntas para entregar los
incrementos de productos solicitados y comprometidos. Es importante que como equipo:

 Se siga un objetivo común.

 Cumplir las mismas reglas y normas.

 Mostrar un respeto mutuo.

Es indispensable conocer que ningún equipo nuevo en formación ofrece su mejor rendimiento
posible desde un inicio. Es indispensable que luego de conformado el equipo se pase por
determinadas fases, tal como lo establece el modelo de Tuckman:

Figura 36 - Modelo de Tuckman

Fuente: International Scrum Institute

155
Como bien describe Ricardo Zamora Enciso (2011) [15], estas fases son aplicables al proceso
de formación del equipo Scrum. Tuckman “identificó cuatro fases fundamentales que
resumían adecuadamente el proceso de desarrollo de grupos”. A continuación, se brinda un
breve detalle de las fases del modelo para la identificación y conocimiento del proceso de
transición del equipo.

Forming: Desde la óptica del desarrollo de las actividades hacia el cumplimiento de tareas,
los miembros del grupo tratan de identificar la tarea en términos de sus parámetros más
relevantes y de la manera como la experiencia del grupo utiliza para completarla. El grupo
debe decidir qué tipo de información necesita y como debe obtenerla.

Storming: Llamada también etapa de conflicto intragrupal. Algunos miembros pueden

resistirse a la formación de grupo. Puede ser una respuesta emocional a las demandas de las
tareas a cumplir y discrepan sobre la orientación para cubrir tales demandas.

Norming: Es la etapa de desarrollo de cohesión de grupo, donde se aceptan a sí mismos como

grupo y a las diferentes idiosincrasias de sus miembros. Aparece el deseo de mantener y
perpetuar el grupo, a través de normas asegurando la existencia del equipo. Las actividades
toman forma de discusión entre uno mismo y los otros miembros del equipo.

Performing: El grupo se ha establecido como entidad y puede convertirse en un instrumento

de resolución de problemas. Las relaciones se han consolidado y es constante los intentos
constructivos de contribuir al éxito de la tarea.

Revisadas las fases por las que transitan los equipos Scrum, se listan las características con
las que deben contar:

156
 Los miembros comparten las mismas normas y reglas.

 El equipo, como un todo, es responsable de los entregables.

 El equipo debe estar empoderado.

 Su trabajo debe ser tan autónomo como sea posible.

 Se auto organiza.

 Las habilidades de los miembros deben estar equilibradas.

 Los equipos deben ser pequeños y no deben existir subequipos.

 El trabajo de los miembros del equipo debe ser a tiempo completo.

Las responsabilidades del equipo se engloban en la siguiente lista:

 Deben desglosar los requerimientos, crear tareas, estimarlas y distribuirlas. Esto

corresponde a la creación del Sprint Backlog.

 Tienen que realizar reuniones diarias y cortas correspondientes al Sprint.

 Deben asegurarse de que al final de cada Sprint se entregue la funcionalidad

comprometida.

 Tienes que actualizar el estado y los esfuerzos restantes para sus respectivas tareas,
permitiendo la creación del Sprint Burndown Diagram (gráfico que representa
diariamente la cantidad de trabajo restante en la iteración).

El Scrum Master: Es parte del Scrum Team y se asegura que el mismo se adhiera a la teoría,
prácticas y reglas de Scrum. Es el líder del servicio para el Scrum Team. Al principio
desempeña un trabajo a tiempo completo lo que imposibilita en cierta medida contribuir

157
directamente con los resultados del Sprint. Sin embargo, después de algunos Sprints, los
procesos se resuelven de modo que la carga de trabajo disminuye, pudiendo contribuir
activamente en el cumplimiento de los objetivos de cada Sprint.

Dentro de sus responsabilidades tenemos:

 Proteger al equipo Scrum de las solicitudes externas e interrupciones.

 Actuar como agente de cambio y adaptar procesos para maximizar la productividad del
equipo.

 Es el coach del equipo.

 Eliminar los impedimentos para el equipo Scrum (Facilitador).

 Asegurar una comunicación eficiente entre el equipo Scrum y el Product Owner.

 Facilitar los diversos eventos Scrum definidos (Daily Scrum Meetings, Sprint Planning
Meetings, Sprint Review Meetings, Sprint Retrospective Meetings).

Para la efectividad de estas responsabilidades es necesario que el Scrum Master cuente con
las siguientes habilidades:

 Moderación

 Coaching

 Know-How de desarrollo

Product Owner: Es uno de los roles centrales de Scrum. Es un rol híbrido de las
responsabilidades de un Product Manager clásico y un Project Manager. Representa al cliente
final o a otras partes interesadas en la consecución del proyecto, siendo responsable de
maximizar el valor del producto asegurando que el trabajo correcto se haga en el momento

158
adecuado. Como consecuencia, esto significa que el propietario del producto Scrum tiene que
trabajar muy de cerca con el Team Scrum y coordinar sus actividades durante toda la vida del
proyecto.

Sus responsabilidades son:

 Gestión del Scrum Product Backlog:

o Crear, mantener y clarificar la descripción de ítems del Product Backlog.

o Priorización de los ítems para la consecución de la misión y objetivos planteados.

o Aseguramiento del entendimiento por parte del Team Scrum con respecto a los
ítems del Backlog.

 Gestión de Releases:

o Responsable de alcanzar las metas del proyecto, crea y mantiene el plan de

lanzamiento y decide sobre las entregas y funcionalidades, además de los costos
del proyecto.

 Gestión de Stakeholders:

o Recopila y discute las funcionalidades necesarias con los distintos interesados, los
cuales son filtrados por prioridad para su entrega al equipo Scrum. Él debe ser el
único canal de comunicación directa entre el quipo Scrum y los clientes.

 Trabajo estrecho con el equipo Scrum:

o Asegurar entendimiento de lo que se requiere.

Esta metodología hace uso de diversas herramientas, instrumentos y entregables para seguir
ordenadamente el trabajo. En adelante, se justifica la selección de Scrum como marco base
para la presente propuesta. A lo largo del presente capitulo se aborda el uso de dichas
herramientas ajustadas a la aplicación del objeto de estudio y el éxito del proyecto.

159
KANBAN

Kanban proviene de las palabras kan “visual” y ban “tarjeta” o “tablero” y es una herramienta
que proviene de la filosofía Lean. Para este caso los recursos toman el trabajo cuando estén
listos en lugar de tener que ser recibidos desde el exterior. Esta metodología se basa en la
optimización de procesos continuos y empíricos. Al igual que Scrum comparte la idea de
crear un Backlog del producto con un conjunto de ítems (user stories, características, etc.)
priorizados, siendo una de las principales diferencias es que en Kanban no existen las
iteraciones de tipo timebox. Kanban controla el WIP (Work in Progress) y en el caso de ser
este bajo se van añadiendo los ítems priorizados del Backlog controlando que no se supere el
WIP definido. Esta herramienta resulta buena para la visualización del proceso a través del
Kanban Board donde en lugar de capturar continuamente el estado de proyecto a través de
informes de estado, este provee una visualización comprensible para todo el mundo,
permitiendo a la gente a pensar por sí mismos y obtener expectativas razonables.16

Proceso Kanban17

1) Visualizar el Workflow

 Dividir el trabajo en piezas y escribir cada una de ellas en tarjetas que se colocan en el
Kanban Board.

 Utilizar columnas con nombres para ilustrar donde se encuentra dentro del proceso o
workflow cada ítem o tarea.

2) Limitar el “WIP” (Work in Progress)

16
Adaptado de Kanban, su uso en el desarrollo de software por Norberto Figuerola
17
Obtenido de https://articulosit.files.wordpress.com/2011/11/kanban.pdf

160
 Asignar limites específicos de cuantos ítems pueden estar siendo procesados a la vez
dentro de cada columna del workflow.

3) Medir el “Lead Time” (Cycle Time)

 Este tiempo es el promedio para completar un ítem o tarea, o sea, que el mismo haya
pasado por todas las columnas del workflow hasta llegar al final. El objetivo de Kanban
es optimizar el proceso para hacer el lead time lo más pequeño y predecible que se pueda.

Dinámica de Trabajo Kanban

De acuerdo a lo detallado por Pablo Lledó (2014) [16] “La dinámica de trabajo se da de
manera continua, tal cual el flujo del proyecto lo propone.” De esta manera, se establece en
esta dinámica lo siguiente:

“Las solicitudes van llegando a la lista, en donde se priorizan. El equipo de trabajo va

sacando de la lista las solicitudes a ser trabajadas. Las mismas van fluyendo a través del flujo
de trabajo definido. Se controla que no se superen los límites definidos. Si en algún caso
(estado) se llega a un límite, el equipo se preocupa por descomprimir los cuellos de botella,
por sobre el tomar nuevas solicitudes”. Podemos observar entonces que en este punto se va
priorizar el cumplimiento de las actividades y tareas por encima de la recepción de más
requerimientos para asegurar lo comprometido.

“¿Cómo se coordinan las actividades?:

 Primero a través de un tablero visible para todo el equipo.

 Luego a partir de reuniones rápidas de seguimiento, en la cual un facilitador controla los

siguientes aspectos:

o ¿El tablero representa la realidad?

o ¿Existe alguna solicitud que esté bloqueando el trabajo?

161
 o ¿Se presentan cuellos de botella en algún estado?

o ¿Se está cerca de superar algún límite definido?

 Luego de la reunión se actualizan los indicadores (tiempo de respuesta y ciclo) y el

tablero”.

A continuación, algunos ejemplos de cómo puede lucir un Kanban Board:

Figura 37 - Ejemplos de Kanban Board

Fuente: https://articulosit.files.wordpress.com/2011/11/kanban.pdf

Los principios y reglas que rigen Kanban serían las siguientes:

 Eliminar los desperdicios en el sistema e incrementar la calidad.

 Determinar el flujo de valor del workflow.
 Remover las demoras en el flujo de trabajo aumentando la velocidad al acortar el “cycle
time”.
 Controlar el WIP dado que el exceso incrementa tanto el riesgo como los desperdicios.

162
 Evitar el Multi-Tasking de los recursos.
 Entrega de valor lo más rápido posible para incrementar el ROI, descomponiendo el
producto en características mínimas de valor.
 Visualización del flujo de trabajo a través del Panel Kanban.

COMPARATIVA ENTRE SCRUM y KANBAN

Se acuerdo a lo indicado por Henrik Kniberg y Mattias Skarin (2010) [17] se listan los
siguientes puntos en común entre ambas metodologías:

 Ambos son Lean y Ágiles.

 Ambos emplean sistemas de planificación “pull”.

 Ambos establecen límites WIP.

 En ambos la visibilidad del proceso es la base de su mejora.

 Ambos tienen como objetivo la entrega temprana y frecuente de software.

 Ambos trabajan con equipos auto-organizados.

 Ambos necesitan la división del trabajo en partes.

 Ambos revisan y mejoran de forma continua el plan del producto en base a datos
empíricos (velocidad/tiempo de entrega).

Establecidos estos puntos se puede concluir que ambas tienen puntos en común que pueden
permitir su uso en conjunto aprovechando los mejores aspectos aplicados de la metodología
Ágil. A continuación, en el siguiente cuadro se aborda las diferencias:

163
SCRUM KANBAN
Las iteraciones deben ser de tiempo fijo. El tiempo fijo en las iteraciones es opcional,
esto en función del plan de producto y la
mejora del proceso.
El equipo asume un compromiso de trabajo El compromiso es opcional.
por iteración.
La métrica por defecto para la planificación En este caso la métrica es el Lead Time
y la mejora del proceso es la Velocidad. (tiempo de entrega o tiempo medio que tarda
una petición en salir del ciclo).
Los equipos deben ser multifuncionales. En este caso pueden ser multifuncionales o
especializados.
Las funcionalidades deben dividirse en No hay prescripción en cuanto al tamaño de
partes que puedan completarse en un sprint. las divisiones.
Deben emplearse gráficos Burndown. No se prescriben diagramas de seguimiento
concretos.
Se emplea una limitación WIP indirecta (por Se emplea una limitación WIP directa
sprint). (marcada por el estado del trabajo).
Se deben realizar estimaciones. Las estimaciones son opcionales.
No se pueden añadir tareas en medio de una Siempre que exista capacidad disponible, se
iteración. pueden añadir tareas.
La pila del sprint pertenece a un equipo Varios equipos o personas pueden compartir
determinado. la misma pizarra Kanban.
Se prescriben 3 roles (Product Owner, Scrum No hay roles prescritos.
Master y Equipo Scrum).
En cada sprint se limpia el tablero de El tablero Kanban es persistente.
seguimiento.
La pila del producto debe estar priorizada. La priorización es opcional.
Tabla 35 - Diferencias entre Scrum y Kanban
Fuente: Kanban y Scrum – obteniendo lo mejor de ambos

164
JUSTIFICACIÓN DE LA METODOLOGÍA ELEGIDA
Se establece entonces que la metodología que regiría el curso del proyecto es SCRUM, para
ello se fundamenta su uso en base a las responsabilidades, características y ventajas de las
metodologías revisadas, además de plantear algunos puntos principales sobre los que gira la
presente justificación.

“Scrum resulta más prescriptivo que Kanban”

Se utiliza en este caso 2 características, prescriptivo como la condición de “más reglas a
seguir” y adaptativo como “menos reglas a seguir”. De manera resumida y relativa Scrum
resulta más restrictivo que Kanban estableciendo más limitaciones y dejando menos opciones
abiertas. Scrum, por ejemplo, usa iteraciones de duración fija que Kanban no.

A continuación, se posicionan algunas metodologías con la cantidad de herramientas por cada

una de ellas y que las clasifican entre prescriptivas y adaptativas:18

Figura 38 – Escala prescriptiva/adaptativa de algunas metodologías

Fuente: Kanban y Scrum – obteniendo lo mejor de ambos

18
Adaptación de Kanban y Scrum – obteniendo lo mejor de ambos por Henrik Kniberg y Mattias Skarin

165
Conclusión orientada a la propuesta y objeto de estudio: En la actualidad, el equipo de
proyectos trabaja con herramientas ya definidas, documentación alineada a la metodología
tradicional y una manera sumamente ordenada de trabajar. Este orden desemboca muchas
veces en la inflexibilidad para continuar las etapas que rigen los proyectos. Si bien es cierto
Kanban resulta más adaptativo para este tipo de situaciones, la propuesta fundamenta que en
base a la forma de trabajo actual (metodología tradicional) y Kanban, la transición entre uno
y otro puede generar resistencia a la alineación y adopción de esta forma. Scrum con las
herramientas proporcionadas y definidas puede ajustarse a la realidad actual sosteniendo el
orden aplicado actualmente y la probable adecuación de algunos elementos usados en la
actualidad.

“Scrum define roles”

De acuerdo a lo revisado, Scrum define 3 roles principales para la ejecución de dicha
metodología, Kanban no establece ningún rol en absoluto. Si bien es cierto, Kanban no
realiza esta definición, no indica que se puedan reutilizar los roles actuales o adaptar alguno
de una nueva metodología. Es necesario realizar una evaluación de los roles existentes y si
estos realmente añaden valor y no entran en conflicto con otros elementos del proceso. Como
se establece, la orientación tanto de Scrum como de Kanban es “menos es más”.

Conclusión orientada a la propuesta y objeto de estudio: Los roles actuales heredados del
uso de la metodología tradicional pueden resultar obsoletos impidiendo el dinamismo en la
ejecución de los proyectos. En la necesidad de mantener orden y alinear una metodología
concreta con herramientas y definiciones concretas, se establece Scrum considerando que los
roles definidos son los necesarios y que agregan valor a la ejecución de las tareas. No se
requiere invertir esfuerzo en la creación de nuevos roles y que en su homologación actual
cumple con lo esperado para el ámbito del proyecto.19

19
Adaptación de Kanban y Scrum – obteniendo lo mejor de ambos por Henrik Kniberg y Mattias Skarin

166
“Scrum y el tiempo fijo”
Scrum delimita el tiempo fijo para las iteraciones durante un periodo de tiempo, combinando
3 actividades distintas: la planificación, la mejora de procesos e idealmente la entrega. En
Kanban no se establece este periodo de tiempo fijo. Se elige el momento de la realización de
las 3 actividades mencionadas, haciéndolas de manera regular o bajo demanda.

Conclusión orientada a la propuesta y objeto de estudio: El ámbito organizacional actual

demanda la propuesta de una metodología ordenada y dinámica. La propuesta de uso de
Scrum se acopla más a lo requerido, estableciendo deadlines para las tareas que se llevan a
cabo durante la ejecución del proyecto. Las expectativas de la línea de mando es tener
claridad en fechas para la exigencia de cumplimiento. El equipo de desarrollo actual se
encuentra alineado a esta expectativa y la presente propuesta cumple en mejor proporción lo
deseado.20

“Scrum y los cambios durante la iteración”

En Scrum el Product Owner no podría tocar el tablero definido una vez asumido el
compromiso del equipo a completar un conjunto de elementos en la iteración, pero se
consideran pilas de requerimientos a considerar para el próximo sprint. En Kanban este
trabajo es más flexible añadiendo restricciones sobre cuando las priorizaciones de
cumplimiento de estos elementos deban ser cambiadas.21

Conclusión orientada a la propuesta y objeto de estudio: Este punto habla de la flexibilidad

que se orienta mucho mejor en Kanban. Sin embargo, el gobierno de proyecto considera
establecer el cumplimiento tangible de los elementos del proyecto de acuerdo a las
definiciones y priorizaciones inicialmente establecidas. Para ello debe existir un compromiso
de realizar un relevamiento correcto que permita definir correctamente los entregables
además de asegurar que el equipo de desarrollo se enfoque en lo que tiene que cumplir y
evitar posibles desviaciones surgidas por cambios de último minuto.

20
Adaptación de Kanban y Scrum – obteniendo lo mejor de ambos por Henrik Kniberg y Mattias Skarin

167
“Scrum y el trabajo en equipo multifuncional”
La responsabilidad de los cambios en el tablero Scrum recae sobre el equipo Scrum y ellos
son los únicos responsables de estos eventos. El equipo es un conjunto de personas con
conocimientos necesarios para completar todos los elementos de una iteración. Kanban por el
contrario asume esto como opcional y su tablero está relacionado no necesariamente con el
flujo de trabajo de un equipo. Los tableros resultan así la única herramienta para administrar
el compromiso de las iteraciones.22

Conclusión orientada a la propuesta y objeto de estudio: Se considera para el mejor

desenvolvimiento del proyecto, lo establecido en Scrum y que el control y responsabilidad
del tablero recaiga sobre un único rol como lo es el equipo Scrum. Múltiples visiones pueden
admitir diversas variaciones a controlar y se pretende asegurar lo correctamente definido en
el tiempo comprometido necesario. El equipo actual de desarrollo cuenta con las aptitudes y
conocimientos exigidos y dicha consideración se basa fundamentalmente en las experiencias
previas de la atención de requerimientos históricos dentro de la organización.

En resumen, todas estas consideraciones revisadas, permiten al equipo resolver sobre una
única metodología adoptada como lo es Scrum, siendo la que mejor se amolda al trabajo ya
definido previamente y la experiencia para acometer el presente proyecto. Es así también que,
se ha realizado la revisión de trabajar ambas metodologías juntas, aprovechando las mejores
prácticas de cada una, lo que no resulta un imposible, sino más bien por experiencias
revisadas, traen un mejor beneficio al desarrollo de los proyectos. Como evento inicial se
adopta y evalúa la puesta en práctica de Scrum y mediante las lecciones aprendidas y la
retrospectiva necesaria, se evalúe a futuro realizar la combinación de estas dos metodologías
ágiles.

21
Adaptación de Kanban y Scrum – obteniendo lo mejor de ambos
22
Adaptación de Kanban y Scrum – obteniendo lo mejor de ambos por Henrik Kniberg y Mattias Skarin

168
IDENTIFICACIÓN DE FORTALEZAS Y DEBILIDADES

Se identifican las fortalezas y debilidades de la organización a través de la matriz de análisis

FODA. Como se menciona, se realiza el análisis incidiendo sobre las fortalezas y debilidades
consolidadas del objeto de estudio.

Figura 39 - Matriz FODA

Fuente : Elaboración Propia

La siguiente matriz cruza las debilidades identificadas contra la fortalezas asociadas que
puede hacer frente a superar la misma y el planteamiento en solución que se debe adoptar
para abordarlas.

169
Debilidades Fortaleza asociada Planteamiento
Estrategia de marketing no Organización Alineamiento a las mejores
consolidada. corporativa con buenas prácticas del grupo Adecco,
prácticas. heredando casos de éxito
adaptados a la realidad país.
Política agresiva de Corporativa global para La organización requiere el
reducción de costos, el incentivo en planteamiento de mejoras a
debilitando la imagen inversión de TI. determinados procesos de
interna. servicios y atención al cliente. Se
debe aprovechar la propuesta de
incentivo global para aprovechar
la inversión en TI para la
adopción o generación de nuevas
herramientas que faciliten la labor
diaria.
Desconocimiento en las Corporativa global para Comunicación extensiva local de
políticas de innovación que el incentivo en propuestas para recepción de
frena el crecimiento de inversión de TI. iniciativas de mejora en los
iniciativas. procesos de negocio actuales.
Herramientas y procesos Corporativa global para Propuesta actual para el
adoptados inicialmente el incentivo en mejoramiento del proceso de
perduran en la organización inversión de TI. compras y la adopción de una
impidiendo adecuarse al nueva plataforma que agilice la
dinamismo del mercado atención actual de cara al cliente.
PETI corporativo y no Organización Planteamiento local de PETI con
alineado a la realidad de corporativa con buenas miras a planificar
gobierno local. prácticas. estratégicamente los servicios de
TI local.
Tabla 36 - Tabla cruce Fortalezas vs. Debilidades
Fuente : Elaboración Propia

170
DIAGNÓSTICO DEL GRUPO
El diagnóstico inicia con la identificación del nivel de madurez de la organización para
dirigirlo a donde se quiere llegar a través de la ejecución de planes, gestión de proyectos y
tareas. Esto permite la orientación y evolución del objeto de estudio corrigiendo o
fortaleciendo la adopción de la metodología a utilizar. Para llevar a cabo la identificación, se
utilizan los niveles de madurez de Gartner que a continuación se presenta.

Figura 40 - Niveles de Madurez de Gartner

Fuente: Gestión de Stakeholders – Diplomado de Dirección de Proyectos ESAN

De acuerdo a lo identificado, Adecco Perú se encontraría en un nivel proactivo basados en la

percepción empírica de los miembros del proyecto y con sustento en el análisis realizado
previamente. En este ámbito, existe planificación de tareas, algún nivel de automatización de
procesos, análisis de procesos y cambios, además de los rendimientos medibles a través del
Sistema de Gestión de Calidad de la organización. Estableciendo lo anterior, el objetivo de la
adopción de nuevas metodologías permite a la organización posicionarla en un nivel de
Servicio y posteriormente al nivel de Valor con el alineamiento de los planes de TI y del
Negocio como estrategia de desarrollo de Adecco.

171
Establecida la posición de la organización, se plantea de manera general un cuestionario para
hacer un diagnóstico general del nivel de agilidad con la que cuenta el equipo de trabajo
actual. Esta es una herramienta simple proporcionada por la empresa VERSIONONE para de
manera general obtener un indicador y poder entrar en el detalle del diagnóstico del equipo de
trabajo.

Figura 41 - Agility Calculator

Fuente: Obtenido de http://info.versionone.com/Agility-Calculator-Tool.html

172
Esta herramienta brinda una ligera orientación y evaluación general de la situación actual del
equipo de trabajo y la ausencia, en algunos casos, de consideraciones para la práctica correcta
de algunos principios agiles, y que sirven de guía para la adecuación de la metodología y
forma de trabajo que se adopta en adelante. La dinámica de esta herramienta introductoria es
brindar una calificación a los criterios establecidos para la evaluación de Agilidad del equipo,
enmarcado en el siguiente score:

Los 29 puntos obtenidos en esta evaluación nos da una orientación de que el grupo se
encuentra actualmente lejos de ejecutar practicas y principios ágiles, permitiendo tomar las
medidas necesarias para su correcta adopción.

De esta primera evaluación, se puede concluir que si bien es cierto la organización se

encuentra ubicada en un nivel proactivo con medición de rendimiento de los procesos, cierto
nivel de automatización y planificación de tareas, la evaluación de equipo nos permite
identificar inicialmente que se debe ampliar el alcance de estas condiciones dirigiéndolas a
mejorar ciertas capacidades ágiles otorgando dinamismo, orden, seguimiento y habilidades
que apoyen además a la organización a alcanzar los niveles esperados en beneficio de obtener
el nivel de valor alineado a la estrategia TI-Negocio.

A continuación, se determina las características de equipo (fortalezas y debilidades) para su

identificación y posterior fortalecimiento con miras a establecer y adoptar correctamente la
metodología seleccionada.

173
 Diagnóstico de equipo de trabajo
Fortalezas Debilidades
Comunicación continúa entre miembros del Equipo distribuido (equipo local y desarrollo
equipo, usando todos los medios con presencia en Argentina)
tecnológicos posibles (Cisco Webex, Skype,
videoconferencia).
Predisposición a la mejora continua. El nivel de aplicación de metodologías ágiles
es bajo.
Decisiones conjuntas son alineadas y Las actividades ejecutadas por el equipo de
adoptadas sin variaciones que impidan su desarrollo tienen poco nivel de transparencia
ejecución. (caja negra) de cara al usuario.
Las líneas de mando cuentan con un buen Las ejecuciones de cambios a los
nivel de proactividad para destrabar requerimientos recaen en procedimientos
situaciones de conflicto. engorrosos, hay cierta tendencia del equipo
de desarrollo a dilatar los tiempos.
Alto nivel de experiencia en el uso de Localmente, no se cuenta con un equipo
tecnologías para la elaboración y desarrollo técnico de desarrollo que aporte con
de productos software (Argentina). sugerencias a la formación de las soluciones.
Lo desarrollado se adopta obligatoriamente.
Tabla 37 - Fortalezas y Debilidades de equipo
Fuente: Elaboración Propia

En la actualidad, la atención de requerimientos locales por parte del equipo de trabajo se rige
por un proceso definido a la interna de la organización y no sigue una metodología definida,
esta lleva años de ejecución y es la manera como se atienden las necesidades de software
actual. A continuación, se brinda un mapa del flujo de este proceso:

174
 Figura 42 - Proceso general de atención a Nuevos Requerimientos
Fuente: Elaboración propia

Proceso de Estimaciones

 Roles que intervienen: Usuario, Business Analyst, Software Architect

 Descripción: El usuario define su necesidad y el alcance del mismo. El Business Analyst

valida la factibilidad y llega al entendimiento de dicha necesidad, esto es plasmado en un
documento de requerimiento (ver Anexo 3.1). El Software Architect conjuntamente con
el Business Analyst realizan la estimación del esfuerzo para la atención del
requerimiento.

Proceso de Planificación

 Roles que intervienen: Project Manager y Usuario

 Descripción: El Project Manager recibe el requerimiento aterrizado con las estimaciones

en tiempo y costo para su cumplimiento. Elabora la planificación y entrega la misma al
usuario a través de una carta Gantt. El usuario aprueba la planificación.

175
Proceso de Desarrollo

 Roles que intervienen: Software Architect, Developer Sr.

 Descripción: En esta etapa se elabora el diseño de la solución por parte del arquitecto de
software y realizan la evaluación y el impacto en conjunto con el Developer Sr. Se
procede con el desarrollo del producto y las tareas propias de testing unitario.

Proceso de QA y Piloto

 Roles que intervienen: QA Engineer, Software Support, Usuario, Project Manager

 Descripción: El producto es entregado por parte del área de desarrollo. El Ingeniero de

QA recepciona el producto y conjuntamente con el Soporte realizan la implementación.
En esta etapa se realizan las pruebas iniciales e integradas (de ser el caso), además de las
pruebas funcionales conjuntas con el usuario. Se realiza un piloto planificado de la
solución en coordinación entre el Project Manager y el usuario.

Estos roles son asumidos por los distintos miembros de la organización, equipo de desarrollo
y analistas locales para la atención de las etapas del proceso indicado.

Diagnóstico y problemas identificados en el Proceso actual

 Durante el proceso de entendimiento de la necesidad, las iteraciones son múltiples y
suelen ser extensas. Los principales problemas que se afrontan son el factor tiempo,
donde se establecen revisiones cada 2 semanas entre el Business Analyst y el Software
Architect para la atención de las necesidades del país. Muchas veces se generan
observaciones múltiples por parte del Software Architect, que el Business Analyst debe
resolver con el Usuario. Existe una brecha de contacto entre el Usuario y el equipo de

176
 desarrollo ya que el Business Analyst se convierte en el único canal de contacto entre
ambos roles.

 Acerca de la Planificación esta es muy pocas veces flexible. El Usuario demanda rapidez
en la entrega de las soluciones requeridas. Existe una alta demanda de requerimientos
corporativa, ya que el equipo de desarrollo con sede en Argentina atiende los
requerimientos de la región LATAM para el desarrollo de los productos software. Esto
determina que los plazos de entrega y de cada una de las etapas definidas se extienda y
genere malestar en el Usuario, concluyendo en una aprobación forzada de los plazos
establecidos.

 La percepción local del área de sistemas es que el proceso de desarrollo se convierte en

una caja negra y no se tiene visibilidad de las actividades del equipo en Argentina. La
planificación muchas veces no tiene el detalle necesario para realizar un trabajo de
gestión de actividades lo que permitiría identificar o resolver periodos más cortos para la
entrega al Usuario. El nivel de gestión muchas veces tiene que escalar la atención de
necesidades para establecer una revisión conjunta entre sistemas y el área de desarrollo.

 Para la etapa de testing, no existe una metodología clara para llevar a cabo dicho proceso.
El QA Engineer muchas veces elabora casos de prueba a criterio propio, considerándose
una labor en conjunto con el Business Analyst. Los casos de prueba se vuelven
insuficientes lo que decanta en múltiples errores durante las pruebas funcionales del
Usuario. La iteración con el área de desarrollo se vuelve constante, alargando e
impidiendo el cumplimiento de los plazos establecidos inicialmente.

177
IDENTIFICACIÓN DE LAS DINÁMICAS PROPUESTAS

A continuación, se presenta una ilustración que proporciona una visión de alto nivel del
proyecto Scrum para permitir identificar las dinámicas convenientes con la finalidad de
potenciar las fortalezas y eliminar las debilidades, aplicables al proyecto.

Figura 43 - Equipos Scrum para un proyecto

Fuente: Branching for scrum - William Bill Heys (Senior Consultant-Microsoft)

178
EL SPRINT
El Sprint como unidad básica de trabajo para el equipo Scrum, en este proyecto inicia con un
compromiso de trabajo a realizar y finaliza con la demostración de un entregable. Se propone
la planificación de cuatro Sprints con una duración de cuatro semanas para cada Sprint:

Figura 44 - Sprint de cuatro semanas

Fuente: Adaptación de Branching for scrum - William Bill Heys, 2011

Sprint 1.- Proceso de identificación de usuarios, seguridad y perfiles, configuraciones de

información y negociación con los subprocesos de la Plataforma de Compras, definición y
configuración de nodos para solicitantes y aprobadores.

Sprint 2.- Procesos de negociación de contratos con proveedores, integración con el Sistema
ERP Microsoft Dynamics GP, digitalización de documentos, flujo de generación de órdenes
de compra regulares y notificaciones y controles de aprobación por montos.

Sprint 3.- Flujo de generación de órdenes de pago para regularizaciones de compra, manejo
de órdenes de pago y flujo de generación de órdenes por precios negociados.

Sprint 4.- Alertas y seguimiento de órdenes de compras y pagos, reportes para monitoreo de
solicitudes y ordenes atendidas.

179
Durante el desarrollo de cada Sprint para el presente proyecto, se sugiere llevar a cabo cinco
eventos (Scrum Events) que a continuación, se detalla la manera de su implementación:

SPRINT PLANNING (Planeamiento del sprint)

Esta reunión se realiza antes de cada sprint, el propietario del producto (Sergio Aguirre -
Jefatura del proceso de compras) presenta los elementos principales de la cartera de pedidos
al equipo y asigna la priorización correspondiente para luego cada integrante estima y elige la
tarea que puede completar durante el sprint correspondiente. Es así como definiremos el
tiempo de duración del Sprint, finalmente el dueño de tarea mueve el trabajo de la pila de
producto para el sprint backlog (que es una lista de tareas a completar en el sprint).

SCRUM TEAM MEETING (Reunión de equipo de scrum)

Estas reuniones se realizan diariamente en la oficina de proyectos de 8:30 am a 8:45
am. (Horario Lima-Perú) y el equipo de desarrollo ubicado en Argentina vía video
conferencia. Cada miembro del equipo debe responder tres preguntas simples, citadas a
continuación:

¿Qué hiciste ayer?

¿Qué tienes planeado hacer hoy?

¿Qué obstáculos encontraste en el camino?

Estas reuniones sirven para que todos los miembros del equipo se apoyen mutuamente y
también permiten gestionar los riegos que pudieran identificarse.

BACKLOG REFINEMENT (Refinamiento del backlog)

El Product Owner sería el revisor de cada uno de los elementos del Product Backlog con la
finalidad de esclarecer posibles dudas que pudieran surgir por parte del equipo de desarrollo.
Es este el evento donde se permitiría volver a estimar el tiempo y esfuerzo que dedica a cada
requerimiento.

180
SPRINT REVIEW (Revisión del sprint)
Todos los miembros del equipo Scrum se reúnen para revisar el trabajo de desarrollo de
software que esta implementado dentro del Sprint. La presentación está dirigida por el Scrum
Master y validada por el Product Owner.

RETROSPECTIVE (Retrospectiva del sprint)

Todos los miembros que componen el equipo Scrum, se reúnen para dialogar sobre las
ocurrencias acontecidas durante el actual Sprint de ese momento. En esta reunión deben
tratarse, como aspectos principales, las respuestas para las siguientes interrogantes:

¿Qué oportunidades se identificó durante el Sprint para poder mejorar el próximo?

¿Qué se hizo bien para continuar en el rumbo hacia el éxito?

¿Qué inconvenientes afectaron y evitaron avanzar acorde a la planificación del sprint?

DEFINICIÓN DE LAS HERRAMIENTAS A UTILIZAR

Historias de Usuario /User Stories

A continuación, se plantea el formato donde se describen las historias de usuario producto de
los requerimientos del Product Owner (Sergio Aguirre – Jefe de Compras Adecco Perú) y de
cómo debe comportarse el producto software a entregar.

Descripción de campos definidos

 ID de la historia: Identificador asignado para las historias de usuario definidas por el

Product Owner.

 Rol: Es el rol que desempeña el usuario de Adecco (Compras) cuando use el sistema.

 Características/Funcionalidad: Determina la función que el rol asignado necesita

ejecutar con el sistema que se desarrolla.

181
 Razón/Resultado: Es el resultado a lograr cuando el rol ejecute la funcionalidad definida.

 Criterios de aceptación: Complementan a los requerimientos en la forma de como el

producto debe comportarse al ejecutar la funcionalidad. Estos registros van definidos con
los siguientes campos:

 Número de escenario: Identifica al escenario que va asociado a la historia de usuario

definida.

 Título del criterio de aceptación: Breve descripción del criterio definido.

 Contexto: Contextualiza las condiciones en las que se ejecuta el escenario definido.

 Evento: Acción ejecutada por el usuario de la plataforma de compras.

 Resultado/Comportamiento Esperado: Es la consecuencia del contexto y la ejecución

llevada a cabo por el usuario de la plataforma.

182
 Enunciado de la Historia Criterios de Aceptación
Número Resultado
ID de la Criterio de Aceptación
Rol Característica/Funcionalidad Razón/Resultado de Contexto Evento /Comportamiento
historia (Título)
Escenario Esperado
El sistema deberá mostrar la
En caso de que el usuario
Cuando ingrese sus pantalla inicial de bienvenida
1 Acceso correcto este correctamente
credenciales correctas con las opciones del rol
registrado
Con la finalidad de poder correspondiente.
Como Usuario acceder al Sistema de El sistema deberá mostrar el
UH-001 Necesito poder identificarme En caso de que el usuario Cuando intente
General Compras y las opciones 2 Usuario Inexistente mensaje "Usuario No
no este registrado identificarse
por rol. Registrado".
El sistema deberá mostrar el
En caso de que el Cuando el usuario intente
3 Password incorrecto mensaje "Password
password sea incorrecto identificarse
Incorrecto".
En el caso de que se
Registro de Dimensión ingrese correctamente el Cuando el usuario pulse el El sistema deberá mostrar el
1
correcto Id y el código de la botón "Registrar" mensaje "Registro exitoso".
dimensión
Como
Necesito poder configurar los Con la finalidad de dar En el caso que se ingrese El sistema alertará sobre la
UH-002 Administrador de Registro de Dimensión
un código de dimensión
Cuando el usuario antes de
datos de Dimensión uso a Analítica. 2 ya existencia del código
Compras duplicado pulsar Registrar
ya existente digitado.
En el caso de que se Cuando el usuario pulse la
Listar Dimensiones El sistema deberá mostrar
3 requiera listar las opción "Buscar" sin
existentes todos los registros existentes.
dimensiones existentes ingresar criterio alguno

En el caso se ingrese
Registro de Grupo Cuando el usuario pulse el El sistema deberá mostrar el
1 correctamente la
correcto botón "Registrar" mensaje "Registro exitoso".
descripción del grupo
Con la finalidad de
Como
Necesito poder configurar los seleccionar los grupos En el caso que se ingrese El sistema alertará sobre la
UH-003 Administrador de Registro de Grupo Cuando el usuario antes de
datos de Grupo que interactuarán con el 2 una definición de grupo ya existencia del grupo a
Compras duplicado pulsar "Registrar"
aplicativo. ya existente registrar.
En el caso de que se Cuando el usuario pulse la
El sistema deberá mostrar
3 Listar Grupos existentes requiera listar los grupos opción "Buscar" sin
todos los registros existentes.
existentes ingresar criterio alguno
En caso de que el usuario
Cuando pulse el botón El sistema deberá mostrar el
1 Registro de OT exitoso complete todos los
"Registrar" mensaje "Registro exitoso".
Con la finalidad de poder campos requeridos
Necesito poder registrar las
UH-004 Como Comprador atender los El sistema deberá indicar
Ordenes de Trabajo (OT) En caso que el usuario no
requerimientos asociados. Cuando pulse el botón mediante un indicador los
2 Registro OT incompleto ingrese todos los campos
"Registrar" campos obligatorios a
requeridos
completar.

Registro de Contrato En el caso se ingresen los Cuando el usuario pulse el El sistema deberá mostrar el
1
correcto campos requeridos botón "Registrar" mensaje "Registro exitoso".

El sistema deberá mostrar un

Con la finalidad de mensaje de confirmación
Como Necesito poder configurar los En el caso se seleccione "Esta seguro que desea
asociarlos a un Cuando el usuario pulse la
UH-005 Administrador de contratos acordados con los 2 Anulación de Contrato un contrato con un eliminar el contrato vigente?"
requerimiento opción "Anular"
Compras proveedores proveedor no vigente y permitir al usuario la
determinado.
confirmación de dicha
operación.
El sistema deberá permitir
En el caso se seleccionen Cuando el usuario pulse la adjuntar y alamcenar
3 Adicionar Sustentos
archivos sustento opción "Adjuntar Sustento" cualquier archivo sustento
adjuntos al registro del presente acuerdo.
El sistema deberá mostrar un
Necesito poder configurar los Con la finalidad de
Como Cuando el usuario mensaje "Esta seguro de
grupos y jerarquías de asociarlos a un Asignación correcta de En el caso de seleccionar
UH-006 Administrador de 1 posicione al grupo en el colocar al grupo en esta
aprobación para el Workflow de requerimiento jerarquías un grupo determinado
Compras arbol de jerarquias posición?" permitiendo la
Requerimientos determinado.
colocación respectiva.

En el caso de ingresar los El sistema deberá mostrar el

Registro de aprobador Cuando el usuario pulse la
1 datos requeridos para mensaje "Usuario registrado
exitoso opción "Registrar"
aprobador exitosamente".
Con la finalidad de
Como Necesito poder configurar los
asociarlos a un grupo y En el caso de ingresar el El sistema deberá mostrar el
UH-007 Administrador de aprobadores para las Ordenes de Registro de Rangos Cuando el usuario pulse la
establecer los montos 2 rango de los montos de mensaje "Rango de Montos
Compras Compra aprobatorios en soles opción "Registrar"
respectivos. aprobación requeridos registrados exitosamente"
El sistema deberá mostrar el
En el caso de registrar
Registro de usuario Cuando el usuario pulse la mensaje "Aprobador de
3 aprobadores de
aprobador de reemplazo opción "Registrar" Reemplazo registrado
reemplazo
exitosamente".

183
 En el caso de ingresar
El sistema deberá mostrar el
Registro de requerimiento todos los datos Cuando el usuario pulse la
1 mensaje "Registro de
exitoso obligatorios del opción Registrar
requerimiento exitoso".
formulario

En el caso de listar los Cuando el usuario

Listar aprobadores de El sistema debe permitir su
Con la finalidad de 2 aprobadores asociados seleccione el(los)
requerimiento asociación.
realizar la atención de al requerimiento aprobador(es) requeridos
Necesito poder registrar los
UH-008 Como Comprador solicitudes de articulos El Sistema deberá confirmar
Requerimientos
y/o servicios de los la operación con un mensaje
En el caso que el Cuando el usuario
clientes. "Se realizó el envío de la
3 Solicitar Aprobación requerimiento demande seleccione la opción
aprobación" y enviará un
Aprobación Solicitar aprobación
correo con dicha solicitud al
usuario correspondiente.
En el caso se necesite
Cuando el usuario
Asociación a Orden de asociar un El sistema deberá permitir
4 seleccione la lista de
Trabajo Requerimiento a una dicha asociación.
Ordenes de Trabajo
Orden de Trabajo

En el caso de ingresar
El sistema deberá mostrar el
todos los datos
Registro de requerimiento Cuando el usuario pulse la mensaje "Registro de
1 obligatorios del
y clasificación exitosa opción Registrar requerimiento urgente
formulario de registro
exitoso".
del requerimiento
Con la finalidad de
priorizar las atenciones El sistema debe iniciar el flujo
inmediatas a solicitudes posterior para la
Necesito poder registrar los
de articulos y/o servicios En el caso se identifique regularización, envío de mail
Como Usuario Requerimientos clasificandolos Cuando el usuario marque
UH-009 que demandan los clientes Clasificación por y seleccione el de aprobación inmediata de
Solicitante como Urgencias y generar 2 el chek de este tipo de
ante eventualidades y que Regularización requerimiento como requerimiento, envío de mail
Ordenes de Compra Automáticas requerimiento
sean soportados por Regularización de aprobación de orden de
contratos con precios ya compra y registro en el
negociados. sistema GP.
En el caso se identifique El sistema debe permitir
el requerimiento como Cuando el usuario continuar con el flujo de
3 Generación Automática urgente y se seleccione el seleccione la opción generación de orden de
proveedor respectivo con Generación Automática compra y enviarla vía mail al
contrato ya negociado proveedor seleccionado.

El sistema deberá mostrar el

En el caso se necesite Cuando el usuario
Listar Pendientes por listado de los requerimientos
1 verificar los pendientes seleccione la opción
Aprobar en dicho estado y catalogados
de Aprobación Pendientes por aprobar RQ
por flujo respectivo.

En el caso se necesite El sistema permitirá acceder

Verificar detalle del verificar los datos y Cuando el usuario al detalle del requerimiento y
2 requerimiento pendiente documentoación seleccione el identificador la documentación adicional
de aprobación adicional de un del requerimiento solo con la opción de poder
requerimiento visualizar.
Con la finalidad de poder El sistema deberá emitir un
Necesito poder visualizar y validar mis pendientes y mensaje "Está seguro de
UH-010 Como Aprobador
aprobar los requerimientos continuar con el flujo del Cuando el usuario realizar la aprobación?"
En el caso se necesite
proceso de compras. seleccione dicho permitiendo confirmar,
3 Aprobar Requerimiento aprobar el requerimiento
requerimiento y pulse la cambiar el estado del
revisado
opción "Aprobar" requerimiento a aprobado y
enviar un correo con dicha
acción.
El sistema deberá emitir un
mensaje "Está seguro de
Cuando el usuario rechazar el requerimiento?"
En el caso se necesite
seleccione dicho permitiendo confirmar,
4 Rechazar Requerimiento rechazar el
requerimiento y pulse la cambiar el estado del
requerimiento evaluado
opción "Rechazar" requerimiento a rechazado y
enviar un correo con dicha
acción.
En el caso se necesite
El sistema debera listar por
visualizar el listado de Cuando el usuario pulse la
Listar requerimientos por defecto los requerimientos en
1 requerimientos opción Lista de
prioridad orden de prioridad de Alta a
pendientes de generación Requerimientos pendientes
Baja (descendente).
de OC
En el caso se necesite Cuando el usuario pulse la
El sistema deberá listar
Bucar requerimientos visualizar un opción Buscar e ingrese los
2 el(los) requerimiento(s)
especificos requerimiento en criterios necesarios de
respectivo(s).
especifico búsqueda
El sistema deberá validar los
privilegios del rol que desea
realizar dicha operación, si
En el caso exista la Cuando el usuario
Con la finalidad de son correctos emitir el
Necesito poder listar los Modificación de detalle necesidad de eliminar seleccione el item
proseguir con el proceso y 3 mensaje "Esta seguro de
UH-011 Como Comprador requerimientos pendientes que requerimiento algún item del respectivo y pulse la
generar la Orden de eliminar el item
han sido aprobados requerimiento opción "Anular Item"
Compra (OC) respectiva. seleccionado?" y permitir
confirmar la operación al
usuario.
El sistema deberá emitir un
mensaje "Seguro que desea
Cuando el usuario
generar la OC asociada al
seleccione un registro de la
En el caso se necesite requerimiento?" permitiendo
lista generada, valide la
generar una OC asociada la confirmación del usuario,
4 Generación de OC información respectiva,
a un determinado enviando un mail con el
seleccione el proveedor
requerimiento estado respectivo y
respectivo y pulse la
requiriendo la aprobación
opción "Generar OC"
por Monto al rol
correspondiente.

184
 En el caso se necesite
visualizar un El sistema deberá emitir un
Cuando el usuario pulse la
determinado listado de los requerimientos
Con la finalidad de poder
1 Visualizar Requerimientos opción "Seguimiento RQ-
requerimiento, su estado respectivos consignando el
OC"
Necesito poder visualizar a hacerle seguimiento y asociación a una flujo respectivo y su estado.
UH-012 Como Comprador detalle la asociación automático y poder determinada OC
Requerimiento-Orden de Compra generar las alertas El sistema desplegará un
En el caso que el usuario
respectivas. listado de las OC´s asociadas
Visualizar asociación de desee visualizar la Cuando el usuario pulse el
2 a dicho requerimiento, su
requerimientos asociación de un link al id del requerimiento
detalle y el estado de dichas
requerimiento a una OC
OC´s.

En el caso que el usuario

Cuando el usuario pulse la El sistema deberá mostrar
Listar Ordenes de Compra desee listar las OC´s
1 opción "Pendientes por solo los registros asociados
pendientes de Aprobación pendientes de
Aprobar OC" al rol respectivo.
aprobación

En el caso de que se
Con la finalidad de poder Cuando el usuario
Visualizar el detalle de la desee visualizar el El sistema deberá mostrar el
continuar el flujo del 2 seleccione el link del id de
Necesito poder visualizar los OC registrada detalle de la OC detalle de la OC registrada.
Como Jefe de proceso de Compras y la OC respectiva
UH-013 pendientes por Aprobar Orden de rergistrada
Compras poder atender los El sistema deberá mostrar el
Compra En el caso de que se
requerimientos de los Cuando el usuario pulse la mensaje "Esta seguro de
clientes. 3 Aprobar OC valide correctamente la
opción "Aprobar OC" Aprobar la OC?" permitiendo
información de una OC
al usuario confirmar.
El sistema deberá mostrar un
En el caso de que la mensaje "Esta seguro de
información de la OC Rechazar la presente OC?"
generada sea incorrecta Cuando el usuario pulse la permitiendo al usuario
4 Rechazar OC
o no se ajuste a las opción "Rechazar OC" confirmar la operación,
politicas de aprobación además de ingresar el detalle
de OC´s necesario del motivo del
rechazo.
Con la finalidad de poder
alertar en el debido En el caso que el usuario El sistema deberá mostrar el
Necesito poder visualizar los Cuando el usuario pulse la
momento retrasos en el Listar Ordenes de Compra desee listar las OC´s total de registros pendientes
UH-014 Como Comprador pendientes por Aprobar Orden de 1 opción "Pendientes por
flujo del proceso de pendientes de Aprobación pendientes de de aprobación y solo con la
Compra Aprobar OC"
Compras y emitir las aprobación opción de visualización.
alertas respectivas.
El Sistema deberá mostrar un
En el caso de que se
Cuando el usuario pulse la listado de Ordenes de
requiera listar las OC
1 Listar Ordenes de Compra opción "Listar Ordenes de Compra, ordenadas por fecha
con un estado general de
Compra" y mostrando el estado en el
las mismas
que se encuentren.
El sistema aperturá una
Necesito poder listar las Ordenes Con la finalidad de poder ventana emergente con el
En el caso de que se
UH-015 Como Comprador de Compra, que no se encuentren realizar modificaciones de detalle de la OC respectiva y
requiera realizar una
sincronizadas con GP último momento. permitirá realizar
modificación de último Cuando el usuario
Modificar Ordenes de determinadas modificaciones
2 minuto a determinada OC seleccione el link del id de
Compra dependiendo del rol que lo
y no se encuentre la OC
ejecute. El usuario podrá
enviada Sincronizada
grabar el registro respectivo a
con el ERP
través de la habilitación de la
opción del sistema.

En el caso que se desee El sistema listará todos los

listar los requerimientos Cuando el usuario pulse la requerimientos que cumplan
Listar requerimientos no
1 registrado que tengan un opción "Actualizar con estas carácterísticas,
asociados a OC
Con la finalidad de poder comprador asociado, Comprador" ordenados por fecha y con el
dar continuidad al flujo pero no una OC dato del comprador asociado.
de compras en caso de
Como Necesito poder reasignar un En el caso que se desee El sistema pertimitirá
indisponibilidad del Cuando el usuario pulse el
UH-016 Administrador de determinado comprador a un Cambiar comprador cambiar el comprador seleccionar un determinado
Compras requerimiento
comprador asignado 2 link del id del
asociado asociado a un comprador y grabar la
inicialmente y no afectar requerimiento respectivo
requerimiento actualización del registro.
las solicitudes de los
El sistema deberá notificar
clientes.
Cuando el usuario pulse la por correo al comprador
Reportar actualización de En el caso se reasigne un
3 opción "Modificar Cambio correspondiente para que
comprador comprador
de Comprador" continue con el flujo de
compra correspondiente.
El Sistema deberá confirmar
la operación con un mensaje
En el caso que el usuario
Con la finalidad de poder "Se realizó el envío de la
Necesito poder solicitar desee solicitar Cuando el usuario
Como Jefe de continuar con el flujo de solicitud aprobación" y
UH-017 aprobación adicional a las 1 Solicitar Aprobación aprobación adicional seleccione la opción
Compras atención a los enviará un correo al siguiente
ordenes de compra generadas por restricciones de Solicitar aprobación
requerimientos. nivel de aprobación, enviado
monto
un correo al aprobador
correspondiente.
El Sistema deberá confirmar
En el caso que el usuario
Con la finalidad de poder Cuando el usuario la operación con un mensaje
Necesito poder validar las desee validar la
continuar con el flujo de Validar Ordenes de seleccione la opción "Se realizó la operación con
UH-018 Como Director ordenes de compra 1 aprobación adicional
atención a los Compra aprobar o rechazar la éxito" y enviará un correo al
recepcionadas por restricciones de
requerimientos. orden de compra usuario que solicitó la
monto
aprobación.

Tabla 38 - Historias de Usuario

Fuente: Plantilla base tomada de www.pmoinformatica.com

185
Backlog de Producto/Product Backlog
Luego de establecer las historias de usuario, se da uso al siguiente formato para la definición
del Backlog del Producto que nos permite ubicar los requerimientos definidos como historias
y donde se puede brindar principalmente una visión del estado, el esfuerzo estimado, la
iteración donde se planifica su desarrollo y una de las partes principales la prioridad que de
manera principal resulta ser el nivel de valor que le da cada requerimiento al negocio. Esta
prioridad es el resultado del consenso y definición con el Producto Owner del proyecto.

Descripción de campos definidos

 Identificador (ID) de la Historia: Identificador definido en la plantilla Historias de

Usuario

 ID Item Product Backlog: Identificador asignado a cada historia de usuario para la Pila de
Producto o Backlog.

 Enunciado de la Historia: Es la historia de usuario concatenada del formato de Historias

de Usuario.

 Estado: Identifica los estados de la historia de usuario durante el ciclo de vida del
proyecto. Se plantean utilizar: Vacío (aún no asignada a Sprint), Planificada (asignada a
un sprint), En proceso (la historia ya se encuentra en desarrollo), Hecho (la historia ya fue
desarrollada) y Descartada (en caso de no ser relevante para el negocio).

Para el presente proyecto, ya se asignaron los estados respectivos y se brindó el estado de

“Planificada” para las historias correspondientes y que se completan en el Primer Sprint del
proyecto de Plataforma de Gestión de Compras.

 Esfuerzo: Es el esfuerzo estimado y consensuado con el equipo de desarrollo de Adecco

para llevar a cabo el desarrollo de cada de una de las historias definidas.

 Iteración (Sprint): Definición de los Sprints donde se completan los requerimientos

definidos. Para el presente proyecto se definieron 4 Sprints para la presente fase.

186
 Prioridad: Asignada por el Product Owner del proyecto bajo el criterio de valor al
negocio que le brinda cada uno de los requerimientos.

Identificador (ID) ID Item Product Esfuerzo

Enunciado de la Historia Estado Iteración (Sprint) Prioridad
de la Historia Backlog (Semanas)
Como Usuario General necesito poder identificarme con la finalidad de poder acceder al Sistema de
UH-001 PB-001 Planificada 1 1 Baja
Compras y las opciones por rol.
Como Administrador de Compras necesito poder configurar los datos de dimensión con la finalidad
UH-002 PB-002 Planificada 1 1 Media
de dar uso a Analítica.
Como Administrador de Compras necesito poder configurar los datos de grupo con la finalidad de
UH-003 PB-003 Planificada 1 1 Media
seleccionar los grupos que interactuarán con el aplicativo.
Como Comprador necesito poder registrar las Ordenes de Trabajo (OT) con la finalidad de poder
UH-004 PB-004 Vacío 2 2 Alta
atender los requerimientos asociados.
Como Administrador de Compras necesito poder configurar los contratos acordados con los
UH-005 PB-005 Vacío 3 2 Alta
proveedores con la finalidad de asociarlos a un requerimiento determinado.
Como Administrador de Compras necesito poder configurar los grupos y jerarquias de aprobación
UH-006 PB-006 para el Workflow de Requerimientos con la finalidad de asociarlos a un requerimiento Planificada 1 1 Alta
determinado.
Como Administrador de Compras necesito poder configurar los aprobadores para las Ordenes de
UH-007 PB-007 Planificada 1 1 Media
Compra con la finalidad de asociarlos a un grupo y establecer los montos respectivos.
Como Comprador necesito poder registrar los Requerimientos con la finalidad de realizar la
UH-008 PB-008 Vacío 2 2 Alta
atención de solicitudes de artículos y/o servicios de los clientes.
Como Usuario solicitante necesito poder registrar los Requerimientos clasificandolos como
Urgencias y generar Ordenes de Compra automáticas con la finalidad de priorizar las atenciones
UH-009 PB-009 Vacío 3 2 Alta
inmediatas a solicitudes de artículos y/o servicios que demandan los clientes ante eventualidades y
que sean soportados por contratos con precios ya negociados.
Como Aprobador necesito poder visualizar y aprobar los requerimientos con la finalidad de poder
UH-010 PB-010 Vacío 1 3 Alta
validar mis pendientes y continuar con el flujo de proceso de compras.
Como Comprador necesito poder listar los requerimientos pendientes que han sido aprobados con
UH-011 PB-011 Vacío 1 2 Alta
la finalidad de proseguir con el proceso y generar la Orden de Compra (OC) respectiva.
Como Comprador necesito poder visualizar a detalle la asociación Requerimiento-Orden de
UH-012 PB-012 Compra con la finalidad de poder hacerle seguimiento automático y poder generar las alertas Vacío 2 3 Alta
respectivas.
Como Jefe de Compras necesito poder visualizar los pendientes por Aprobar Orden de Compra con
UH-013 PB-013 la finalidad poder continuar el flujo del proceso de Compras y poder atender los requerimientos de Vacío 1 3 Alta
los clientes.
Como Comprador necesito poder visualizar los pendientes por Aprobar Orden de Compra con la
UH-014 PB-014 finalidad poder alertar en el debido momento retrasos en el flujo de proceso de Compras y emitir Vacío 1 3 Alta
las alertas respectivas.
Como Comprador necesito poder listar las Ordenes de Compra que no se encuentren sincronizadas
UH-015 PB-015 Vacío 2 4 Media
con GP con la finalidad de poder realizar modificaciones de último momento.
Como Administrador de Compras necesito poder reasignar un determinado comprador a un
UH-016 PB-016 requerimiento con la finalidad de poder dar continuidad al flujo de compras en caso de Vacío 2 4 Baja
indisponilidad del comprador asignado inicialmente y no afectar las solicitudes de los clientes.
Como Jefe de Compras necesito poder solicitar aprobación adicional a las ordenes de compra
UH-017 PB-017 Vacío 1 4 Alta
generadas con la finalidad de poder continuar con el flujo de atención a los requerimientos.
Como Director necesito poder validar las ordenes de compra recepcionadas con la finalidad de
UH-018 PB-018 Vacío 1 4 Alta
poder continuar con el flujo de atención a los requerimientos.

Tabla 39 - Backlog del Producto

Fuente: Plantilla base tomada de www.pmoinformatica.com

Backlog del Sprint/Sprint Backlog

Es el resultado de la planificación ejecutada en el Sprint Planning con la participación del
Product Owner, Scrum Master y Scrum Team. El objetivo de esta fase es poder planificar el
Sprint 1 y todas las tareas que se lleva a cabo para el cumplimiento de los requerimientos
definidos. Es necesario indicar, que el Scrum Team (equipo de desarrollo de Adecco) atiende
requerimientos a la región LATAM, en base a esto, el objetivo del Product Owner es que el

187
cumplimiento del Sprint 1 debe darse en el periodo de 4 semanas. El Scrum Team planifica la
ejecución (no lineal) de las tareas que se llevan a cabo, acorde a su disponibilidad y la no
desatención del resto de requerimientos de la región.

Se propone para el control y cumplimiento del formato siguiente y se detalla la definición de

los campos completados:

Descripción de campos definidos

 Identificador (ID) de ítem del Product Backlog: ID definido en la Pila de Producto

relacionado a las historias (requerimientos) de usuario.

 Enunciado del ítem del Product Backlog: Enunciado del requerimiento de la Pila de
Producto.

 Tarea: Es el elemento mínimo, la desagregación en tareas de cada ítem del Product

Backlog. Se debe cumplir cada una de estas para considerar el cumplimiento de cada ítem
del Product Backlog.

 Dueño/Voluntario: Responsable de la ejecución de la tarea definida en el Sprint.

 Estatus: Se define, Por Iniciar, en proceso y completado. Para esta etapa, se definen a
todas las tareas “Por Iniciar” para completar la presente iteración del proyecto actual.

 Horas estimadas totales: Tiempo definido por el equipo Scrum durante el Sprint
Planning, acorde a la disponibilidad actual y la carga de trabajo para la atención de
requerimientos de la región.

División del tiempo:

 Semana n: Semana planificada, total 4 semanas para la ejecución de la presente iteración.

 Cons.: Tiempo total consumido en cada división del tiempo.
 Rest.: Tiempo restante para el cumplimiento de la tarea.
 Total: Brinda una visibilidad del progreso y el tiempo consumido para la ejecución y
finalización de la tarea.

188
 Semana 1 Semana 2 Semana 3 Semana 4 Total
Identificador (ID)
Enunciado del item de Product Dueño / Horas estimadas
de item de Tarea Estatus Cons. Rest. Cons. Rest. Cons. Rest. Cons. Rest. Cons. Rest.
Backlog Voluntario totales
product backlog
6 6 6 6 0 6
Diseño de pantalla de Matias
Por iniciar 6
login Plaza

Diseño de pantalla de Matias 6 6 6 6 0 6

Como Usuario General necesito Por iniciar 6
bienvenida Plaza
poder identificarme con la finalidad
PB-001 Generación de lógica Matias 16 16 16 16 0 16
de poder acceder al Sistema de Por iniciar 16
de autenticación Plaza
Compras y las opciones por rol.
Generación y Matias 8 8 8 8 0 8
ejecución de pruebas Plaza Por iniciar 8
unitarias
Generación de scripts Matias 4 4 4 4
Por iniciar 4
de Base de Datos Plaza
Diseño de pantalla Sebastian 8 8 8 8 0 8
para acceso a opción Fontana
Por iniciar 8
de Configuración de
Dimensión
Como Administrador de Compras Codificación para Sebastian 18 18 18 18 0 18
necesito poder configurar los datos registro de opciones Fontana Por iniciar 18
PB-002
de dimensión con la finalidad de dar de Analítica
uso a Analítica. Generación y Sebastian 8 8 8 8 0 8
ejecución de pruebas Fontana Por iniciar 8
unitarias
Generación de scripts Sebastian 6 6 6 6
Por iniciar 6
de Base de Datos Fontana
6 6 6 6 0 6
Diseño de pantalla
para acceso a opción Bruno
Por iniciar 6
de Configuración de Mancuso
Como Administrador de Compras Grupos
necesito poder configurar los datos
Codificación para Bruno 18 18 18 18 0 18
PB-003 de grupo con la finalidad de Por iniciar 18
registro de grupos Mancuso
seleccionar los grupos que
Generación y Bruno 8 8 8 8 0 8
interactuarán con el aplicativo.
ejecución de pruebas Mancuso Por iniciar 8
unitarias
Generación de scripts Bruno 8 8 8 8
Por iniciar 8
de Base de Datos Mancuso
6 6 6 6 0 6

Diseño de Pantalla
Bruno
para acceso de opción Por iniciar 6
Mancuso
WorkFlow RQ
Como Administrador de Compras
necesito poder configurar los grupos Codificación para Bruno 20 20 20 20 0 20
y jerarquias de aprobación para el establecer jerarquias Mancuso
PB-006
Workflow de Requerimientos con la de aprobación y Por iniciar 20
finalidad de asociarlos a un solicitud de
requerimiento determinado. requerimientos
Generación y Bruno 6 6 6 6 0 6
ejecución de pruebas Mancuso Por iniciar 6
unitarias
Generación de scripts Bruno 8 8 8 8
Por iniciar 8
de Base de Datos Mancuso
8 8 8 8 0 8

Diseño de Pantalla
Sebastian
para acceso de opción Por iniciar 8
Fontana
WorkFlow OC

Como Administrador de Compras

Codificación para 16 16 16 16 0 16
necesito poder configurar los
establecer y registrar
aprobadores para las Ordenes de
PB-007 criterios de aprobador Javier
Compra con la finalidad de asociarlos Por iniciar 16
y montos de ordenes Gonzales
a un grupo y establecer los montos
de compras y
respectivos.
asociación a grupos
Generación y 6 6 6 6 0 6
Javier
ejecución de pruebas Por iniciar 6
Gonzales
unitarias
Generación de scripts Sebastian 10 10 10 10 0 10
Por iniciar 10
de Base de Datos Fontana

Tabla 40 - Sprint Backlog (Iteración 1)

Fuente: Plantilla base tomada de www.pmoinformatica.com

189
El Panel de Tareas/The Taskboard
Se propone como uso el panel de tareas brindado por Trello. Se conoce que los miembros del
equipo de proyecto actualmente se encuentran ubicados en Perú como en Argentina. Esta
herramienta sirve para tener visibilidad de los progresos ante la ubicación distinta de los
miembros del equipo. No obstante, el Scrum Team, puede manejar alternativas físicas para el
planteamiento de tareas en el TaskBoard, sin embargo, todos los cambios deben ser reflejados
en la herramienta virtual de Trello para ser consultadas por el Product Owner y el Scrum
Master posicionados localmente.

A continuación, una definición de los sectores definidos en la presente herramienta:

No Planificado: Sector que contiene todos los ítems del Product Backlog que aún no han sido
planificados y que no conforman parte del presente Sprint.

Mejora continua: A futuro, es el sector donde se podrían colocar tareas de mejoras

identificadas y resultantes de las reuniones de retrospectiva, a fin de darle un valor agregado
al producto.

Objetivos del Sprint: Sector donde se ubican los ítems del Product Backlog que han sido
planificados para el Sprint 1 definido y cuya finalización es objetivo del primer entregable
priorizado por el Product Owner.

Pendientes: Sector donde se ubican todas las tareas a realizar para completar cada objetivo
(requerimiento) del presente Sprint. Estas tareas ya se encuentran asignadas a cada
responsable en la herramienta.

En Proceso: Tareas que se vienen ejecutando en el momento. Actualmente, en este sector se

tiene en blanco, pues solo se propone la planificación para la ejecución del Sprint 1.

Terminado: Sector para todas las tareas culminadas.

Impedimentos: Se ubican los riesgos identificados o cualquier elemento crítico a resolver, que
se encuentran fuera del alcance del Scrum Team y que son asignadas al Scrum Master en su
tarea facilitadora.

190
Retrospectiva: Zona a colocar para las cuestiones que se vienen realizando bien y
correctamente (lecciones aprendidas) y las situaciones a mejorar.

Figura 45 - Scrum Taskboard

Fuente: Herramienta de libre uso brindada por https://trello.com/

191
COMPOSICIÓN DE LOS GRUPOS DE TRABAJO

Para la composición del grupo de trabajo vamos a tomar como referencia parte de los roles
definidos en la estructura de gobierno – Stakeholders de la iniciativa, siendo los siguientes:

Jefe de Compras (Sergio Aguirre)

Rol establecido en la estructura de gobierno actual que pertenece al objeto especifico de

estudio (Compras). Trabaja conjuntamente con el Business Analyst plasmando el
entendimiento de los requerimientos actuales que se generen en el área y trabaja directamente
en la planificación de las tareas conjuntas con el Project Manager.

Director de Proyectos (Eduardo Noriega)

Rol establecido por la organización para cumplir la planificación y control de la propuesta de

proyecto. Ejecuta las labores propias de un Project Manager y es el orquestador de las
actividades actuales ejecutadas en los proyectos. Su función resulta altamente negociadora
entre lo definido por el usuario y el equipo de desarrollo.

Equipo de Desarrollo (Líder Javier Gonzales)

Desarrolla las labores de Software Architect en la organización y trabaja en conjunto con el

Business Analyst para el entendimiento y composición de la solución. A su cargo se
encuentra el staff de desarrollo que construye las soluciones para la atención de los
requerimientos. El Staff está compuesto por:

Bruno Mancuso (Desarrollador Senior)

Sebastian Fontana (Desarrollador Senior)

192
 Matias Plaza (Desarrollador Junior)
El nivel otorgado a los miembros del equipo es asignado por el Líder, acorde al nivel de
Seniority con el que cuenta cada uno, y esto en relación a la experiencia en participación de
proyectos de envergadura en la corporación Adecco y los skills tecnológicos con los que
cuentan cada uno de ellos.

Comprendidos los roles del esquema actual de trabajo se detalla la composición del grupo de
trabajo bajo la adopción de la metodología SCRUM, para lo cual inicialmente se definen las
características y habilidades blandas requeridas en cumplimiento de la metodología. Los roles
y características requeridas son las siguientes:

Figura 46 - Características deseadas de los roles principales de Scrum

Fuente: Información obtenida de la guía de conocimiento SBOK de SCRUMStudy

El Product Owner/Propietario del producto es la “voz del cliente” y el responsable de

maximizar el valor del negocio para el proyecto articulando requisitos y manteniendo una
justificación equilibrada. Desarrolla, mantiene y prioriza las tareas en el backlog.

193
El Scrum Master es el responsable de asegurarse que el trabajo del equipo vaya bien
siguiendo las bases de Scrum y además de asegurar el éxito del proyecto contando con un
ambiente propicio para el desenvolvimiento de las actividades. Se encarga de remover
cualquier obstáculo que pueda encontrar el equipo de desarrollo con sus tareas propias de
facilitador.

El Equipo Scrum/Development Team Members comprenden los requerimientos del

negocio, la estimación de las historias de usuario y la creación final de los entregables del
proyecto. Son los encargados de escribir y probar el código generado para la generación del
producto esperado.

A continuación, se presenta un resumen de los roles principales del Equipo Scrum:

Figura 47 - Descripción general de los roles de Scrum

Fuente: Información obtenida de la guía de conocimiento SBOK de SCRUMStudy

194
Definidos los roles de gobierno actual y los roles Scrum a adoptar, se establece el siguiente
cuadro que define las habilidades que se deben reforzar por rol para cumplir con las
características y expectativas requeridas de cada rol de Scrum:

Tabla 41 - Gobierno, Roles Scrum y habilidades a reforzar

Fuente: Elaboración propia

Del cuadro establecido se puede determinar que existe poco conocimiento en la metodología
Scrum a practicar. Se propone el establecimiento de dinámicas grupales previas al inicio del
proyecto para reforzar la metodología propuesta. Esta debe ser llevada a cabo por una
empresa externa especializada en la institucionalización de este tipo de prácticas agiles.

En líneas generales, se denota que la participación de los roles es preferentemente a tiempo

completo. En este caso, el equipo de desarrollo es corporativo y atiende requerimientos a
nivel LATAM, por lo que se sugiere escalar la participación activa en el mayor tiempo
posible para las dinámicas grupales Scrum y el avance correcto del proyecto. Los perfiles
adicionales al ser interesados propios de la consecución exitosa del proyecto pueden
destinarse a tiempo completo.

Las habilidades a reforzar identificadas son tomadas a partir de la experiencia previa en la

atención de requerimientos, producto de la percepción del usuario interno de la organización
e identificado en el proceso de diagnóstico grupal previo. El reforzamiento debe ser llevado a

195
cabo también previamente al inicio del proyecto y en conjunto con la empresa externa
seleccionada para el proceso de institucionalización y elaborando dinámicas grupales para la
interiorización de las habilidades identificadas y requeridas.

De igual forma, se sugiere la ejecución de las siguientes actividades/dinámicas para mantener

y reforzar las habilidades blandas identificadas:

 Dinámica Cubos Solidarios23

El grupo debe construir un número determinado de cubos a demanda de una empresa de

juguetes. Para ello, se debe dividir al grupo en tres subgrupos.

Cada grupo debe realizar 15 cubos de 5×5 en una hora y el material que tienen es el siguiente:

Grupo 1: 2 cartulinas, 1 regla, 2 lápices, 3 tijeras, 1 pegamento

Grupo 2: 2 cartulinas, 1 regla, 2 lápices, 2 tijeras y 1 pegamento

Grupo 3: 2 cartulinas, 2 reglas, 2 lápices, 1 tijera, 1 pegamento

Se valora la calidad de los cubos.

Se ponen en evidencia determinados comportamientos como la competitividad, la

individualidad y la forma como los miembros del equipo se interrelacionan para conseguir un
objetivo común fortaleciendo el trabajo en equipo. Finalizada la dinámica se hace un debate
en grupo para comentar todo ello.

 El Muro24

Se divide a los participantes en dos grupos iguales y a cada uno se le da la consigna por
separado. Uno va a formar el muro, por eso se eligen los compañeros más fuertes y se les
pide que se tomen de los brazos. Entre ellos se pueden hablar. No pueden soltarse, sólo
avanzar o retroceder 3 pasos. Al otro se les explica que deben intentar atravesar el muro y el

23
Obtenido de http://www.lifeder.com/dinamicas-de-trabajo-en-equipo/

196
que lo logre obtiene un premio, que no pueden hablar ni pasar por los extremos. Tienen un
minuto para intentarlo.

En la reflexión final es importante analizar qué significa el muro y qué el premio; cómo
influyeron las consignas de cada grupo sobre la acción conjunta; pensar qué pasó entre los
intereses particulares y el interés colectivo. Ver la importancia de la planificación y la acción
organizada para aplicarlo a la vida cotidiana del grupo.

El muro son los obstáculos y el premio, los objetivos. Al principio cada uno busca distintas
estrategias, que, a veces, logran. El juego puede complementarse con una segunda vuelta
donde, el grupo que no podía hablar, ahora puede hacerlo. En esta segunda experiencia se
observa la importancia de la planificación y la organización de los participantes.

 Dibujo compartido25

Dinámica para reflexionar sobre la necesidad del diálogo y la comunicación para un buen
funcionamiento del equipo. Se trata de hacer que el grupo salga de la habitación y entre sólo
uno de ellos. En la habitación con pizarra, el primer participante del grupo comienza un
dibujo. Posteriormente, lo taparemos dejando al descubierto sólo una parte de su dibujo y
haremos pasar al siguiente participante, que debe seguir con el dibujo de su compañero. Así
sucesivamente hasta que todos hayan participado.

24
Obtenido de http://dinamicasgrupales.blogspot.pe/2008/06/dinmicas-grupales-3-organizacin-y.html
25
Obtenido de http://www.lifeder.com/dinamicas-de-trabajo-en-equipo/

197
TÉCNICAS E INSTRUMENTOS

DINÁMICA PARA ESTIMACIÓN DE TIEMPOS

Para este proyecto la estimación es una labor donde el equipo Scrum debe usar Planning
Poker, puesto que al inicio nadie sabe quién debe implementar cada historia de usuario, pero
si debe saber el detalle de cada una de estas. Si existen estimaciones altamente diferenciadas
para una misma historia, se debe descubrir el detalle al principio. Planning Poker es un
método descrito a detalle por Mike Cohn en su libro Agile Estimating and Planning [18].

Aplicación: El desarrollo de software de este proyecto tiene un equipo distribuido (Perú -

Argentina), por ello se propone realizar las estimaciones utilizando plannig poker, pero
soportado por una herramienta web denominada Planitpoker sobre la base de experiencia
personal en la compañía Adecco Perú.

Figura 48 – Estimación online con Planitpoker

Fuente: Planningpoker - http://www.planitpoker.com/

Frecuencia: Se realiza antes de iniciar la implementación de cada Sprint.

198
Logro: Este tipo de estimación ágil crea conciencia de equipo. Todos participan, tienen voz y
voto. Cuando se produce una equivocación en una estimación, se ha equivocado todo el
equipo, según la propuesta de Xavier Quezada [19].

DINÁMICA PARA REUNIONES DE EQUIPO

Aplicación: Estas reuniones tienen la finalidad de mejorar las dinámicas para un adecuado
equipo de trabajo, dirigido a mejoras en las relaciones humanas, identificación de mejores
métodos de trabajo y oportunidades de aplicación de técnicas favorables para el equipo
scrum. Esta dinámica esta soportada sobre la base de experiencia personal en Adecco Perú.

Frecuencia: Se realiza después de cada entregable, a manera de encuentros de integración.

Se propone también aplicarse como encuentro ocasional para resolver un tema en particular.

Logro: Se logra potenciar el equipo de trabajo, se fortalece la confianza, mejora la

comunicación, se estimula la creatividad, agiliza la reflexión conjunta y motiva la acción en
sinergia, según Ingrid Astiz [20].

DINÁMICA PARA HACER RETROSPECTIVAS

EL BARCO DE VELA
La aplicación de la técnica del barco de vela es importante para reflexionar sobre
oportunidades, riesgos y problemas que pueden identificarse durante cada sprint del proyecto,
según Ana María del Carmen García Oterino [21].

Aplicación: La aplicación de esta dinámica se describe a continuación bajo la misma

propuesta de García Oterino [21].

 Se dibuja un barco en una pizarra que va hacia la tierra prometida, siendo también este
último otro elemento que se dibuja. La tierra prometida es la visión de lo que el equipo
quiere llegar a ser, la meta, qué es lo que quieren llegar a conseguir como equipo a nivel
de procesos, desarrollo, etc.

199
 Todo el equipo viaja en el barco hacia la tierra prometida. En la pizarra también se dibuja:

o Un sol: Las cosas que nos iluminan y alegran el camino.

o Un ancla (dibujada saliendo del barco hacia el suelo): las cosas que nos frenan.
o Rocas: los riesgos que nos encontramos en el camino.
o Viento: aquellas cosas buenas que nos empujan y acercan a la tierra prometida.
 Después de culminar el dibujo y explicar el significado cada elemento, durante cinco
minutos, los miembros del equipo individualmente escriben en post-its los hallazgos de
cada elemento al finalizar el sprint. Dado el número del equipo se requiere como mínimo
tres hallazgos de cada tipo.

 Luego, por turnos, cada miembro del equipo coloca sus post-it alrededor de cada
elemento (sol, ancla, etc.) y explica el detalle del hallazgo contenido en los post-it. El
equipo hace las agrupaciones de post-it que sean oportunas si coinciden en algunos
hallazgos de los post-it.

 Cuando todos los hallazgos están reflejados, se discute sobre dichas ocurrencias y se
define planes para mejor el siguiente sprint. Si hubiera muchos hallazgos que requieren
solución, cada miembro vota por el más prioritario a solucionar. Los de alta prioridad,
acordados por debate, son los que se solucionan.

 Para culminar, se define las acciones para resolver los hallazgos priorizados, las fechas de
culminación y los responsables de ejecución de cada actividad.

Frecuencia: Esta dinámica de retrospectiva se realiza al finalizar cada sprint.

200
 Figura 49 - Dinámicas para retrospectivas ágiles - Barco de vela
Fuente: Javier Garzas – 2015 – Dinámicas para hacer retrospectivas agiles

GRÁFICO RADAR
Esta herramienta se implementa permitiendo una visualización compartida sobre cómo está el
equipo y como se desea estar. Se propone esta herramienta para que nos permita reconocer
las diferentes percepciones de los integrantes, establecer metas de crecimiento, buscar
sinergia en la acción y hacer seguimiento de los avances.

Aplicación Se aplica como dinámica de equipo para la mejora continua, soportado sobre la
adaptación de la propuesta de Ingrid Astiz [22].

1) Factores, ¿en qué queremos mejorar?: se define como mínimo tres criterios sobre los que
se desea mejorar.

2) Situación inicial, ¿cómo estamos?: Cada integrante del equipo establece un valor del 1 al
10 a cada factor, de forma privada (para evitar influencia mutua). El valor 1 se considera
totalmente insatisfecho, valor el 8 es satisfacción plena. Cuando todos completan los
valores, se comparte y se escribe el valor promedio. Si en algún criterio hubiera varios
puntos de diferencia, se revisa el motivo puesto que puede ser por distinta percepción de
la realidad o se tuviera expectativas muy diferentes.

201
3) Situación deseada, ¿cómo queremos estar?: En la situación deseada es importante el
acuerdo del grupo, esto funciona como motivación cruzada. Se establece la fecha de la
siguiente revisión del gráfico, para que se realicen las acciones de cambio antes de esa
fecha.

4) Revisión de avance, ¿cómo vamos?: Al tiempo, volver a reunirse y responder a ¿cómo

estamos? de forma privada y luego se comparta y escriba el promedio. De esta forma se
puede visualizar si hubo cambios en relación a la situación inicial (revisiones periódicas)
y en relación a la situación deseada. Si se está avanzando por buen camino, los cambios
implementados son acertados, sino se avanzó, se debe tomar una acción para que el nivel
de satisfacción mejore, de acuerdo a la adaptación de Ingrid Astiz [22].

Figura 50 – Grafico Radar

Fuente: Adaptación de Ingrid Astiz – 2012 – Grafico radar

202
TABLERO SCRUM
Trello es una herramienta que tiene gran potencial que sirve como soporte para el control de
tareas (se establece esta herramienta como resultado la experiencia personal sobre los
proyectos de software en Adecco Perú), para cuyo seguimiento se propone establecer
reuniones diarias (Daily Scrum Meetings), sobre Trello estarían representadas gráficamente
como una serie de post-it en una pizarra dividida en columnas para representar el estado de
las tareas. Los miembros del equipo scrum, puede acceder online desde donde estén. Las
notas no son simples post-it pegados a una pizarra, estos son elementos para comentar
opiniones, establecer listas de tareas detalladas, adjuntar archivos, etc. Se propone llevar a
cabo los Daily Scrum Meetings con el uso Hangout y un panel Scrum en Trello.

Figura 51 – Trello - Herramientas para uso del tablero Scrum

Fuente: Elaboración propia sobre la plataforma Trello

203
COSTOS PARA EL DESARROLLO DE SOFTWARE
En esta sección se presenta una tabla como una propuesta para la estimación del costo de
implementación del primer sprint, para esto se usa como referencia el diseño de un método
para la evaluación de la gestión de costos en la metodología ágil SCRUM, cuyo objetivo se
sostiene como necesidad de normalizar el proceso del software con respecto a los costos, y
disminuir las variaciones presupuestales. [23]

Este costo generado por el desarrollo del software, está cubierto por el sueldo del equipo de
desarrollo.

Tabla 42 - Propuesta para la evaluación de costos para los Sprint

Fuente: Adaptación de Evaluación de la Gestión de Costos para la Metodología Ágil [23]

204
COSTOS PARA ENTRENAMIENTO DEL EQUIPO
Miembro Capacidades y habilidades a desarrollar Costo
Product  Capacitar en metodología Scrum con énfasis en la definición de rol y $ 650.00
Owner funciones como Product Owner.
 Fortalecer su habilidad referido a la facilidad de comunicación en las
relaciones interpersonales para interpretar las necesidades del proceso de
compras para traducirlo en "objetivos de valor para el producto" y para
transmitirlo así al Scrum Team.
Scrum  Capacitar en metodología Scrum para capacitarse como auténtico líder, $ 800.00
Master para asignarle la responsabilidad de fomentar e instruir sobre los
principios ágiles de Scrum a todo el equipo de interesados del negocio.
 Desarrollar la habilidad para resolver los conflictos que entorpezcan el
progreso del proyecto y mejora de carisma para las negociaciones.
 Fortalecer su habilidad para crear un clima de trabajo colaborativo,
fomentar la auto-gestión del equipo e impedir la intervención de terceros
en la gestión del equipo.
Scrum  Capacitar en metodología Scrum al equipo multidisciplinario, para $ 2,500.00
Team que pueda desarrollar el producto de manera auto-organizada,

 Entrenamiento en el uso de las herramientas ágiles y comprensión de la

interacción con los artefactos y aplicación de las dinámicas de scrum
dentro de las actividades de desarrollo que se les confía.
Costo de entrenamiento $ 3,950.00
Tabla 43 - Costos para entrenamiento de equipo
Fuente: Elaboración Propia

205
CONCLUSIONES

La definición y especificación del plan para el desarrollo de software propuesto para el

proceso objetivo (proceso de compras) de la organización Adecco Perú S.A. Apoyado sobre
la base de las metodologías ágiles, permite garantizar el cumplimiento de los estándares
internacionales de calidad, y de esta manera poder crear el producto software que responda
las expectativas de los stakeholders alineados al logro de los objetivos estratégicos.

Se espera que la aplicación de la metodología Scrum permita cultivar el capital humano del
equipo responsable de la implementación para mantenerlo satisfecho y con óptimo
rendimiento durante la implantación.

La identificación del equipo humano, las dinámicas especificadas, las herramientas que se
utilizan y las técnicas definidas ha determinado nivel de detalle en esta capitulo, busca
asegurar la construcción del software para permitir obtener resultados fiables y eficientes.

206
CAPÍTULO 4. GESTIÓN DE SERVICIOS EN TI

INTRODUCCIÓN

En este capítulo, se presenta la propuesta de implementación de procesos para la gestión de

servicios en tecnologías de la información alineados a los objetivos estratégicos de la
compañía Adecco Perú S.A. desde su servicio de atención de compras, se presenta el
resultado de las evaluaciones estratégicas de negocio y de TI para luego proponer una
solución que siga una planificación estratégica, diseño y transición de servicios de los
procesos ITIL sugeridos para su implementación.

207
MODELO DE GESTIÓN DE PROCESOS ITIL

Figura 52 – Modelo de gestión de TI basado en ITIL

Fuente: Modelo de gestión de TI basado en ITIL 2011 – Tohkin©. Mexico 2012

208
EVALUACIÓN ESTRATÉGICA

PLAN DE ACCIÓN

El Plan de acción esta soportado por las bases de las buenas prácticas de ITIL en sus 5 fases
para Adecco Perú, sobre el precedente de ser requerido por la dirección general que, a partir
de su implementación, exige a todos los empleados contribuir con el cumplimiento de los
procesos y los procedimientos que se implementan como producto de los cambios que se
ejecutan en este proyecto.

La implementación de este plan, conlleva a la definición de nuevas políticas dentro de la

organización en la procura del mejor desempeño y alto posicionamiento de la compañía que
incluso contempla la demanda de determinados empleados con certificados en ITIL como
garantía para la adecuada continuidad.

209
ESTRATEGIA DE NEGOCIO

Visión
(Definido en el Capítulo 1 – Fundamentos Teóricos sobre la revisión del Objeto de Estudio)

Misión
(Definido en el Capítulo 1 – Fundamentos Teóricos sobre la revisión del Objeto de Estudio)

Objetivos Estratégicos
(Definido en el Capítulo 1 – Fundamentos Teóricos sobre la revisión del Objeto de Estudio)

Prioridades de la Organización
En la actualidad, Adecco se encuentra posicionada en el mercado local con presencia en
recursos humanos y servicios para organizaciones de gran envergadura. Sin embargo, la falta
de dinamismo en algunas de sus operaciones, como en el del objeto de estudio siendo el de
gestión de compras, ha involucrado insatisfacción de sus clientes y la pérdida de algunos
contratos de servicios importantes para la organización.

Adecco direcciona sus esfuerzos, reforzados por las políticas corporativas y el sustento local,
a incentivar la inversión en TI y a buscar consolidar su posición en el sector pequeña y
mediana empresa, además al interior del país.

“Actualmente, en el Perú, las micros y pequeñas empresas aportan, aproximadamente, el 40%

del PBI y son una de las mayores potenciadoras del crecimiento económico del país.”26 Bajo
esta consideración, es innegable asumir que las PYMES son fuente principal de la generación
de empleo. Adecco Perú busca afianzar su presencia en este sector y lograr incorporar su
cartera de servicios y productos, para ello, la organización es consciente del dinamismo de
este mercado y la necesidad de incrementar escalonadamente la inversión en TI para la
atención de las necesidades de este negocio.

26
Referencia tomada de http://asep.pe/mypes-aportan-el-40-del-pbi/

210
En este sentido, lograr un buen posicionamiento en el mercado objetivo indicado en conjunto
con una buena inversión en TI y en la mejora de procesos, logra un impacto positivo sobre los
objetivos estratégicos de la organización, tales como:

 Incremento de negocio enfocado en pymes impacta positivamente en las utilidades de la

organización.

 Mejoras en TI y procesos, permiten brindar un servicio adecuado a los clientes pymes

afianzando su fidelidad.

 La inversión en TI y la visión para mejorar los procesos actuales se alinean a la intención

corporativa de mejorar a nivel global.

 Buen porcentaje de las pymes se encuentra ubicada al interior del país, lo que le permite a
Adecco cubrir esa presencia al interior, incrementando su cobertura a las ya existentes
líneas de negocio.

Estas serían algunas consideraciones de impacto positivo sobre los objetivos estratégicos de
la organización, resultantes de la inversión y la intención de cubrir el mercado y sector
económico indicado.

Foda
(Establecido en el Capítulo 3 – Identificación de Fortalezas y Debilidades)

Servicios de Negocio Ofrecidos

(Establecido en el Capítulo 1 – Fundamentos Teóricos sobre la revisión del Objeto de
Estudio)

211
ESTRATEGIA DE TI

Servicios Internos y Externos identificados

A continuación, se presente un esquema donde se identifican los servicios internos y externos
del proceso objeto de estudio. Se determina acorde al esquema que no existen procesos
externos identificados y se esquematizan los internos y de soporte respectivos.

Figura 53 - Identificación de servicios internos del proceso de gestión de compras

Fuente: Elaboración propia

212
Descripción del Servicio

Servicios Internos
Servicio de Atención de Compras. - Servicio que brinda el producto de la presente propuesta.
Su propósito es poder atender el proceso de gestión de compras interno y externo a la
organización Adecco Perú, otorgándole flexibilidad y agilidad a la atención de los
requerimientos de los distintos usuarios.

Servicio de Compras Microsoft Dynamics GP. - Plataforma que brinda actualmente el

servicio de gestión de compras y que se recomienda su reemplazo por el propuesto. Pasa a un
segundo plano en utilización de usuario, pero existen componentes propios del ERP que
sirven de base para el funcionamiento de la propuesta actual.

Prioridades de Inversión
En la actualidad, Adecco no aprueba los presupuestos de inversión presentados para aplicar
mejoras al sistema actual de Compras Microsoft Dynamics GP, y lograr que se adecue a las
necesidades actuales de los clientes. Estratégicamente, el negocio considera muy elevados los
costos presentados para aplicar cambios a este servicio brindado por la herramienta
mencionada. Con esta consideración, se ha recomendado evaluar opciones de inversión para
otorgar un nuevo servicio complementario, basado en las capacidades actuales y de fácil
ajuste para otorgar el dinamismo requerido en el mercado de servicios. Con ello, basado en el
planteamiento de objetivos estratégicos, resumidamente se busca:

 Reducir los gastos y empujar el crecimiento de las utilidades del negocio.

 Elaborar el modelo de servicio otorgado por el planteamiento de la solución actual que

permita a los clientes externos mejoras sostenibles en sus operaciones del día a día.

 Con la mejora del servicio, se mantienen clientes satisfechos y la fidelidad de los mismos.

213
 Enfoque en la optimización del proceso de gestión de compras y de la calidad que este
servicio debe otorgar, acorde a las demandas de calidad exigidas por el negocio.

 Fortalecer el proceso de compras, adicionando niveles de comunicación para mantener

informado a los actores durante todo el proceso y asegurar el cumplimiento de sus
actividades para evitar caer en incumplimiento que afecte el servicio.

 Esta propuesta de inversión permitiría fortalecer la cultura de la organización de otorgar

mejores herramientas a los colaboradores para la ejecución de sus actividades.

 Un servicio adecuado, consolida la relación con los clientes actuales y podría incorporar a
otros más, enfocando los mercados objetivos al interior del país.

 Otorgar poder de negociación de cara al desarrollo de proveedores, permitiendo

capacidad de ahorro en las operaciones de compra futuras.

PLANIFICACIÓN ESTRATÉGICA
Planificar los servicios de TI identificados, correctamente priorizados. Identificar necesidades
de inversión, así como oportunidades de mejora. Conformar el portafolio de servicios de la
organización, identificando los objetivos de negocio que soporta y el impacto.

SERVICIOS IDENTIFICADOS

SERVICIOS INTERNOS Y DE SOPORTE

Complementando la identificación de servicios internos realizada, se esquematizan los
servicios de soporte identificados a continuación:

214
 Figura 54 - Identificación de los servicios internos y de soporte de gestión de compras
Fuente: Elaboración Propia

Los servicios internos fueron detallados al inicio de la estrategia y se complementa esta

información con el detalle de los Servicios de Soporte.

Servicios de Soporte

Servicio de Red. – Componente que otorga flexibilidad en uso a la solución de la presente

propuesta. Brinda el servicio de comunicación a la plataforma para su acceso desde cualquier
punto, por medio de la VPN de la organización y a través de un acceso adecuado en la
intranet de Adecco.

Servicio de Servidor de Aplicaciones. – Son todas aquellas componentes que van alojadas
en el servidor de aplicaciones y que soportan a la aplicación Web producto del desarrollo
actual de la presente propuesta. En el presente caso es representado por el producto IIS de
Microsoft que brinda el servicio de soporte tecnológico a la actual plataforma.

215
Servicio de Base de Datos. – Soporte actual de la ERP. Brinda el servicio de alojamiento de
información mediante la implementación de un nuevo esquema que soporte la solución
propuesta de gestión de compras. Alojada en la misma instancia de la solución ERP.

Servicio de Correo. – Otorga el servicio de alertas automáticas que genera el nuevo proceso
y flujo de compras ejecutado en la plataforma propuesta de Compras.

216
Portafolio de Servicios

Definición de lista de Servicios Internos

Horas de
Código Servicio Versión Descripción Tipo Propietario Cliente Servicios de Soporte U. Negocio Impacto Prioridad Servicio

- Penalidades por incumplimiento en

el otorgamiento de un servicio que
Lunes a
Servicio Base otorgado dependa de algún bien por adquirir
Viernes (8:30
por la plataforma ERP para el desarrollo de la labor
SERVICIO DE -Interno: Departamentos de a 18:30)
indicada para la Todas las requerida.
COMPRAS Adecco - Recursos de Red Excepciones
PS-ADE-SI-001 1 ejecución de los Interno Jefe de Compras Unidades de - Perjudicar la ejecución de las CRÍTICO
MICROSOFT - Externo: Clientes del - Base de Datos por compras
procesos de gestión de Negocio. actividades asociadas a la
DYNAMICS GP negocio de urgencia
compras de Adecco adquisición de un activo para
(todos los
Perú. Adecco.
días)
- Deterioro de la imagen de la
empresa.

Lunes a
Servicio propuesto Viernes (8:30
complementario a la - Interno: Departamentos a 18:30)
SERVICIO DE Todas las
solución actual ERP de Adecco - Recursos de Red Excepciones
PS-ADE-SI-002 ATENCIÓN DE 1 Interno Jefe de Compras Unidades de Mismo impacto al implementar CRÍTICO
para la ejecución de la - Externo: Clientes del - Base de Datos por compras
COMPRAS Negocio.
gestión de compras con negocio de urgencia
funcionalidad mejorada. (todos los
días)

Tabla 44 - Portafolio de Servicios Internos

Fuente: Elaboración Interna

217
Definición de lista de Servicios de Soporte

U.
Código Servicio Versión Descripción Tipo Propietario Cliente Servicios de Soporte Negocio Impacto Prioridad Horas de Servicio

- Sin disponibilidad para accesar a la

Administrar las tareas de monitoreo para
plataforma desde la intranet.
garantizar no existan perdidas de enlace y Jefatura de
PS-ADE-SS-001 SERVICIO DE RED 1 SOPORTE Gerente de TI - Otorgados por el proveedor Todas - Imposibilidad de ejecutar las ALTA
de servicio de internet otorgadas por el Compras
labores de gestión de compras Los 365 días, 24 *
proveedor Telefónica del Perú.
pendientes. 7

Realizar las tareas de administración de - Monitoreo de aplicación de

los servidores IIS en los que se alojaría la Gestión de Compras
SERVICIO DE
solución, tales como disposición de Jefatura de - Monitoreo de errores en los de - Indisponibilidad de plataforma de
PS-ADE-SS-002 SERVIDOR DE 1 SOPORTE Gerente de TI Compras ALTA
espacio, monitoreo de logs, operatividad Compras servidores web gestión de compras.
APLICACIONES
correcta de las aplicaciones deployadas en - Disponibilidad de espacio en Los 365 días, 24 *
dicho servidor. disco 7

- Brindados por la organización,

específicamente por un DBA
que se encargue de la
Gestionar la Base de Datos asociada a la
administración.
SERVICIO DE plataforma de gestión de compras Jefatura de - Indisponibilidad de plataforma de
PS-ADE-SS-003 1 SOPORTE Gerente de TI - Monitoreo a los servicios de Compras ALTA
BASE DE DATOS propuestas y las laboras que demanda la Compras gestión de compras.
BD y a los espacios requeridos.
administración de la misma.
- Tareas de tunning de BD para
optimizar los tiempos de Los 365 días, 24 *
respuesta de la BD. 7

Envío automático de correos relacionados - Indisponibilidad de alertas

SERVICIO DE a las operaciones de la plataforma de Jefatura de - Brindados por el área de automáticas a los usuarios que
PS-ADE-SS-004 1 SOPORTE Gerente de TI Todas MEDIA
CORREO compras y las alertas correspondientes a Compras Tecnología de la organización. participan en los procesos de gestión Los 365 días, 24 *
los destinatarios vía correo. de compras. 7

Tabla 45 - Portafolio de Servicios de Soporte

Fuente: Elaboración propia

218
REQUERIMIENTO DEL SERVICIO IDENTIFICADO
Se completa la plantilla de ficha de alcance de servicio (Ver Anexos 4.1) donde se describen
los requerimientos del Servicio Interno.

GAS-
Código:
ADE001
Ficha de Alcance de Servicio

Versión 1.0

INTRODUCCIÓN

Propósito

Este documento presenta el Alcance del Servicio que nace mediante un requerimiento del
cliente. Así como el alineamiento con los objetivos de la organización.

Cliente

El cliente es interno del área de compras de la compañía Adecco Perú.

Alcance

Este alcance es una guía para el jefe de este proyecto en las decisiones de añadir, cambiar o
eliminar trabajo del proyecto para el proceso de Mantenimiento y Desarrollo de Software.

Objetivos

 Apoyar al área de compras de la compañía Adecco Perú S.A. con sus labores de
mantenimiento y mejora del software para gestión de compras con la finalidad de optimizar
sus recursos y afinar sus procesos.

 Garantizar el desempeño adecuado del software para responder eficientemente a los

cambios que el proceso de compras demande.

 Entregar valor en la gestión de software como socio estratégico de transformación del

219
 negocio.

 Alcanzar los niveles de excelencia en la calidad de los servicios de TI.

 Automatizar los procesos del área de compras de la organización.

 Mejorar el grado de fidelización de los usuarios de compras.

PREREQUISITOS

En esta sección se responde las siguientes preguntas de tal manera que se tenga un estado de
la oportunidad de negocio.

 ¿Cómo calificaría el servicio?

( ) Servicio Nuevo

( X ) Mejora de un Servicio Existente

( ) Servicio Específico para un cliente

 ¿El cliente cuenta con un presupuesto para concretar la oportunidad de negocio?

Si, se cuenta con un presupuesto inicial de US$ 280,000

 ¿El cliente tiene una fecha de cuándo debe estar operativo el requerimiento
solicitado?

Si, se requiere la operatividad del servicio desplegado desde 15/05/2017

 ¿El cliente cuenta con la infraestructura adecuada para operar el servicio solicitado?

Si, se tiene equipos de cómputo (PC), teléfonos y servicios de correo y accesos a internet.
Además de parte de la plataforma base de producción es reutilizada y repotenciada para dicho
fin. Se planifica la adquisición de equipos para los ambientes de desarrollo y testing.

 ¿Cuál es la proyección de ventas de unidades?

Se proyectan ahorros generados en promedio de hasta US$ 148,000 anuales, proyectados a 5

años.

FUNCIONALIDAD

220
 Se brinda cobertura a los requerimientos a detalle demandados por los usuarios.

 Se garantiza que la implementación del servicio no interferir con las funcionalidades

adecuadas existentes.

 Se reduce significativamente el número de incidentes presentados en el ambiente de

Producción.

Requerimiento: Servicio de Gestión de Compras

Descripción

El requerimiento del servicio, actualmente brinda soporte a los procesos de Adecco Perú SA y
su justificación de beneficio futuro, responde específicamente para optimizar el servicio que
pertenecen al proceso de gestión de compras.

ALINEAMIENTO ESTRATÉGICO

Desde el análisis interno, así como la evaluación de los procesos de compras, se identifican y
priorizan los servicios de TI requeridos por Adecco Perú SA como respuesta dirigida a la
alineación estratégica de la organización interno con el cumplimiento de sus objetivos.

ENTREGABLES

Los entregables que se entregaran como parte del proceso de implementación del desarrollo
de Software listados a continuación:

N° ENTREGABLE REQUERIDO
(SI/NO)

1 Cotización SI
2 Documento de Análisis SI
3 Documento de Diseño SI
4 Empaquetado de Software SI
5 Plan de Pruebas SI
6 Casos de Pruebas Unitarias NO
7 Casos de Pruebas Modulares/Integrales SI
8 Pruebas de Stress NO
9 Pruebas Automatizadas NO

221
 11 Informe de Pruebas SI
12 Manual del Nuevo Software SI
13 Videos de Nuevo Software NO
14 Documento de Despliegue SI
15 Actualización de Menú de Operaciones SI
16 Términos de Soporte Técnico SI
17 Términos de Garantía NO

A continuación, se lista los entregables necesarios (elementos hardware) para la implantación

del servicio.

N° ENTREGABLE REQUERIDO
(SI/NO)

1 Guía de Recepción de Equipo SI

2 Instalación SI

3 Configuración SI

4 Resultado de Pruebas SI

5 Términos de Soporte Técnico SI

6 Términos de Garantía SI

222
EVALUACIÓN FINANCIERA
Se realiza, a continuación, la evaluación financiera orientada a sustentar la viabilidad de la
propuesta de solución, basados en el cálculo de la VAN y TIR.

Datos previos de la organización

Años
Totales 2012 2013 2014 2015 2016 Promedio
anual
Cantidad Clientes 38 34 34 31 29

Revenue Servicios (US$) 4,358,278.00 3,983,115.00 4,198,691.00 4,023,382.00 4,511,496.00 4,214,992.40

Contratos no renovados (US$) 58,991.00 210,001.00 297,714.00 489,991.00 532,119.00 317,763.20 8%
Compras por servicios (US$) 1,114,221.00 981,007.00 1,062,551.00 1,232,962.00 1,390,004.00 1,156,149.00 27%
Compras Internas - GA (US$) 632,119.00 358,010.00 832,771.00 215,005.00 232,986.00 454,178.20
Meta revenue anual (5%) 4,737,070.80 4,973,924.34 5,222,620.56 5,483,751.58 5,757,939.16

Tabla 46 - Datos previos Adecco para Evaluación Financiera

Fuente: Elaboración Propia

Detalle

Los datos presentados pertenecen a un periodo de 5 años y tiene las siguientes características:

 Cantidad de clientes: Es la cantidad de clientes con la que cuenta la cartera de Adecco y a

la que se le ofrece Servicios de nivel operativo y que en la mayoría de ocasiones
demandan el uso de herramientas para la ejecución de su labor. Se percibe de los datos
una disminución en dicha cantidad.

 Revenue Servicios: Son los ingresos reales por año, resultado de la venta de servicios a
clientes externos como parte de la razón de ser del objeto de estudio.

 Contratos no renovados: Son los ingresos anuales perdidos por contratos que no fueron
renovados por los clientes. Para efectos de la evaluación financiera estos ingresos
representaron el 8% del Revenue Promedio Anual.

 Compras por servicios: Son los montos anuales en los que se incurrió por la ejecución de
compras por material, herramientas, etc. para la ejecución de los servicios a los clientes

223
 externos. Para efectos de la evaluación financiera estas compras representaron el 27% del
Revenue Promedio Anual.

 Compras Internas (GA): Son los montos anuales por la ejecución de compras requeridas
por los clientes internos y considerados como montos por gastos administrativos. Con el
cálculo del monto promedio anual incurrido se establece el meta porcentual objetivo del
3% anual.

 Meta revenue anual: La organización Adecco fija como meta por la venta de servicios un
incremento del 5% anual con respecto al revenue alcanzado en el ejercicio inmediato
anterior. La tabla muestra la proyección de dicha meta a 5 años.

DATOS DEL PROYECTO

Plataforma de Gestión de Compras

DATOS
DESCRIPCIÓN VALOR

Plazo evaluado (Años) 5

Tasa de Descuento 20%

COSTOS

Costo de Mantenimiento Anual HW 4,632.91 USD

Costo Fase 2 - Adecco Consulting 30,000.00 USD

Costo Fase 3 - Aplicación Mobile 55,000.00 USD

Costo Soporte-Monitoreo (Anual) 14,281.00 USD

INVERSIÓN INICIAL

Software 170,253.26 USD

Hardware 64,788.00 USD
Otros
Recursos humanos - USD

Tabla 47 - Datos usados para Evaluación Financiera del Proyecto

Fuente: Elaboración Propia

224
Detalle

 La evaluación se realiza sobre la proyección a un plazo de 5 años.

 La tasa referencial usada es del 20%.
 Se establecen los costos proyectados tales como:
o Servicio de mantenimiento anual de Hardware adquirido para el proyecto.
o Incorporación de gestión de compras de empresa Adecco Consulting en Fase 2.
o Desarrollo de aplicación Mobile para Fase 2, enfocada en aprobaciones de nivel
ejecutivo remoto.
o Servicio anual de soporte y monitoreo de equipos servidores alojados en HP.
 La inversión inicial está compuesta básicamente por: Desarrollo y adquisición de
Software, además del Hardware que soporta la solución.

PROYECCIÓN REVENUE SERVICIOS

Plataforma de Gestión de Compras
Año AÑO 1 AÑO 2 AÑO 3 AÑO 4 AÑO 5
Revenue anual 4,737,070.80 4,973,924.34 5,222,620.56 5,483,751.58 5,757,939.16

Tabla 48 - Proyección de Ingresos (Revenue US$ Millones)

Fuente: Elaboración Propia

Detalle

La proyección de ingresos fue realizada con un horizonte de 5 años, tomando en cuenta la

meta anual de +5% sobre el revenue total del ejercicio anterior inmediato. Estas son metas
trazadas por la corporación y la estrategia comercial de Adecco Corp. alineada además con
una estrategia de incentivos y bonos.

225
 FLUJO DE EFECTIVO
INVERSIÓN
AÑO 0 AÑO 1 AÑO 2 AÑO 3 AÑO 4 AÑO 5
INGRESOS
Venta de Servicios (Revenue proy.) 4,737,070.80 4,973,924.34 5,222,620.56 5,483,751.58 5,757,939.16
Aseguramiento de contratos por servicios externos 17,856.10 USD 18,748.91 USD 19,686.35 USD 20,670.67 USD 21,704.20 USD
Eficiencia y desarrollo de proveedores en Servicios externos 38,980.57 USD 40,929.59 USD 42,976.07 USD 45,124.88 USD 47,381.12 USD
Ahorro promedio por compras internas 13,625.35 USD 13,625.35 USD 13,625.35 USD 13,625.35 USD 13,625.35 USD
Dias adicionales de facturación por eficiencia 65,792.65 USD 69,082.28 USD 72,536.40 USD 76,163.22 USD 79,971.38 USD
TOTAL DE INGRESOS 0.00 USD 136,254.67 USD 142,386.13 USD 148,824.17 USD 155,584.11 USD 162,682.05 USD
EGRESOS
Inversión en Hardware 170,253.26 USD
Inversión en Software 64,788.00 USD
Fase 2 - Incorporación Adecco Consulting 30,000.00 USD
Fase 3 - Desarrollo Mobile 55,000.00 USD
Mantenimiento Anual HW 4,632.91 USD 4,632.91 USD 4,632.91 USD 4,632.91 USD 4,632.91 USD
Soporte y Monitoreo 14,281.00 USD 14,281.00 USD 14,281.00 USD 14,281.00 USD 14,281.00 USD
TOTAL EGRESOS 235,041.26 USD 18,913.91 USD 48,913.91 USD 73,913.91 USD 18,913.91 USD 18,913.91 USD
FLUJO DE EFECTIVO -235,041.26 USD 117,340.76 USD 93,472.22 USD 74,910.26 USD 136,670.20 USD 143,768.14 USD
FLUJO ACUMULADO -235,041.26 USD -117,700.50 USD -24,228.28 USD 50,681.98 USD 187,352.18 USD 331,120.32 USD

VAN 94,691.63 USD

TIR(Tasa Interna de Retorno) 36.56%

Tabla 49 - Estimación de VAN y TIR del Proyecto

Fuente: Elaboración Propia

Para la determinación de los valores VAN y TIR sobre los que gira la evaluación financiera
de la propuesta actual se ha realizado un trabajo previo de análisis. Esta labor consiste en
determinar los ingresos generados por la ejecución de la propuesta, proyectados a un
horizonte de 5 años. Es necesario indicar, que esta no ejecuta una venta directa de servicios
(core del negocio) ni tampoco se considera como algún bien negociable, en ese sentido, se ha
tenido que contemplar los objetivos siguientes asociados que se brinda durante su ejecución y
que permite impactar positivamente sobre los ingresos de las ventas de servicios y gastos
administrativos contemplados.

Sobre el cuadro de Flujo de Efectivo se tiene:

Ingresos

Determinado por la suma de lo siguiente:

Aseguramiento de contratos por servicios externos

De los datos previos analizados, se determina que el 8% del Revenue Promedio Anual
(periodo 2012-2016) significó contratos no renovados (véase tabla 41). Esto corresponde a la
decisión del cliente de no continuar contratando el servicio por inconvenientes generados

226
durante la ejecución del mismo (inconvenientes con las herramientas de trabajo, con la
reposición de las mismas, por solicitud de material de trabajo adicional con demora, entre
otros factores) que han generado malestar de los clientes. Esta percepción y finalmente
experiencia mala de servicio ha sido recogida por Adecco mediante el uso de encuestas de
satisfacción del cliente (SGC) orientadas a este tipo de casos.

Como objetivo, se establece que durante la ejecución de la propuesta se asegura el 5% de

dicho monto, resultado de las mejoras por eficiencia operativa y el cambio de percepción de
los clientes, evitando la fuga de los mismos, además de capturar y ampliar mercados
objetivos. Este valor es un aporte directo a las Ventas de Servicio.

Eficiencia y desarrollo de proveedores en Servicios Externos

De los datos previos (véase tabla 41), se establece que el 27% del Revenue Promedio Anual
(periodo 2012-2016) significaron costos (compras) asociados a la Venta de Servicios
(herramientas, materiales, entre otros para la ejecución de los distintos servicios).

Como objetivo, se establece que durante la ejecución de la propuesta se asegura el 3% de

ahorro de los montos proyectados en 5 años. Este aporte a los costos es el resultado de la
relación eficiencia-costo-calidad en el manejo de desarrollo de proveedores que provee la
implementación de la plataforma.

Ahorro promedio por compras internas

Del análisis previo, se obtuvo que en promedio se tiene US$ 454,178.20 como monto
asociado al Gasto Administrativo (atención de compras internas Adecco).

Como objetivo, de este promedio, se plantea un ahorro fijo del 3% de durante el horizonte de
5 años de puesta en producción de la propuesta. Esto significa un ahorro promedio por año de
US$ 13,625.35 resultado también del desarrollo de proveedores como concepto manejado en
la plataforma propuesta.

Días adicionales de facturación por eficiencia

227
La ejecución del análisis previo, permite determinar la facturación diaria por servicios con el
dato proyectado del revenue.

Como objetivo, se plantea que se puede obtener 5 días facturables adicionales por periodo
resultado también de la eficiencia operativa otorgada por la ejecución de la propuesta actual.
La consideración de estos días adicionales se da, por ejemplo, en los casos en los que se
tuviera que colocar un recurso, a demanda urgente de un cliente, y cuya ejecución e inicio de
labores está asociada a la adquisición de material o herramientas asociadas a su labor y que
por posibles demoras en la gestión impidan dicho inicio, impactando en la propuesta de inicio
del servicio.

Análisis de VAN y TIR obtenidas

Es importante, como resultado de esta evaluación financiera, conocer la capacidad de este
proyecto de inversión para generar rendimiento, dicho en otras palabras, riqueza, a lo largo
del horizonte establecido.

Para esta evaluación tenemos:

VAN= US$ 94,691.63 > 0; lo que nos indica que el proyecto puede ser rentable.

TIR=36.56%; es la tasa de rentabilidad obtenida por llevar a cabo la presente propuesta.

228
EVALUACIÓN DE RIESGOS
La evaluación de los riesgos durante la implementación del servicio “atención de compras” están definidos en la siguiente matriz de evaluación
de riesgos con el propósito de valorar los criterios de probabilidad e impacto y así calcular la exposición al riesgo para gestionar el riesgo
mediante un plan.

MATRIZ DE RIESGOS

FECHA DE INICIO: 02/01/2017

FECHA DE TÉRMINO PROPUESTA: 04/03/2017

Fecha Tipo Tipo

ID Riesgo Estado Impacto Probabilidad Exposición Respuesta
Detección Riesgo Respuesta

El alcance del proyecto podría verse

En caso de la existencia de un
afectado de forma negativa al existir
cambio en el entorno, por
un cambio en el entorno (por 25% 50% ejemplo, un cambio de
01 ejemplo, un cambio en alguna 02/01/17 1. Vigente Positivo 13% Aceptar
normativas, se debe convocar al
normativa legal o interna que afecte (Muy Baja) (Baja)
comité de Gestión de Cambios y
al funcionamiento de las consultorías
efectuar los ajustes que fueran
de gestión humana)
necesarios sobre las restricciones

229
 del proyecto.

Mantener un procedimiento
actualizado de la Gestión del
Proyecto, considerando una
persona responsable de aprobar
Se podría impactar de forma negativa
50% 25% las defunciones de los
las restricciones del proyecto debido
02 02/01/17 1. Vigente Negativo 13% Aceptar requerimientos antes que sean
a cambios en las definiciones
(Baja) (Muy Baja) implementados. Se debe generar
originales de los requerimientos
un procedimiento de escalamiento
donde es requerida la aprobación
del requerimiento para luego
implementarse.

Se podría incidir en una falsa En Adecco Perú se realiza sesiones

expectativa por parte de los usuarios de entendimiento en los cuales

50% 25% pueda explicar las consideraciones
debido al errado entendimiento de
03 02/01/17 1. Vigente Negativo 13% Aceptar
los supuestos y restricciones tomadas antes de cada
(Baja) (Muy Baja)
definidos en el Plan de Gestión del implementación de procesos de

Proyecto manera que los usuarios

autorizados para la definición de

230
 los procedimientos tengan
claridad respecto de estos.

Se debe establecer un
procedimiento para aprobaciones
automáticas, cuando existan
entregables no aprobados dentro
La demora en la aprobación de los
del periodo de tiempo esperado,
entregables podría determinar que 50% 50%
este entregable sería dado por
04 los siguientes entregables se puedan 02/01/17 1. Vigente Negativo 25% Mitigar
válido bajo la responsabilidad del
ver afectados, que debido a posibles (Baja) (Baja)
aprobador. Si sobre la aprobación
dependencias no podrían iniciar.
automática existieran
observaciones, se procedería a
evaluar un procedimiento de
Gestión de Cambios.

El tiempo de aprobaciones podría Se debe establecer un número

25% 25% máximo de iteraciones
verse afectado de forma negativa al
05 02/01/17 1. Vigente Negativo 6% Aceptar
tener recurrencia en observaciones considerando las revisiones
(Muy Baja) (Muy Baja)
parciales de los entregables. parciales. Esto aplica para los
artefactos que tengan más de una

231
 observación no identificada
durante las revisiones previas.

Evaluar la posibilidad de incluir a

La no inclusión de la Dirección 25% 25% la Dirección General en el alcance
06 General podría comprometer de 10/01/17 1. Vigente Negativo 6% Aceptar del proyecto y considerar la
forma negativa las expectativas de TI (Muy Baja) (Muy Baja) ejecución del proceso de control
de cambio.

La inclusión de los procedimientos Evaluar la posibilidad de incluir a

para la gestión de los procesos ITIL 25% 25% la Dirección General en el alcance
07 podría ampliar el alcance, 10/01/17 1. Vigente Negativo 6% Aceptar del proyecto y considerar la
comprometiendo de forma negativa (Muy Baja) (Muy Baja) ejecución del proceso de control
el cumplimiento de los entregables. de cambio.

No contar con el documento de En caso que el documento de

procedimientos de Gestión del procedimientos de Gestión del
Cambio (preliminar) que debiera ser 75% 75% Cambio no se reciba antes del
08 12/01/17 1. Vigente Negativo 56% Trasferir
provisto por IT, podría generar una 16/01/2017, todo retraso que se
(Alta) (Alta)
deviación respecto de la definición de tenga sobre la implementación del
procedimientos que retrase la proceso de Gestión del cambio, no
implementación de este proceso es imputable al equipo

232
como un entregable. responsable de implementación.

Tabla 50 - Matriz de Riesgos

Fuente: Elaboración Propia

233
DISEÑO DEL SERVICIO
En esta sección se presentan los artefactos generados durante el diseño de servicios.

REQUERIMIENTO DE NIVEL DE SERVICIO (SLR)

El Requerimiento de Nivel de Servicio (SLR por sus siglas en inglés, Service Level
Requirements) - (Ver Anexos 4.2), tiene como propósito ejecutar las siguientes actividades:

 Detallar los servicios que se van a prestar.

 Definir los requisitos y objetivos de negocio del cliente.
 Documentar requerimientos en SLR.
Con el propósito de cumplir de los siguientes objetivos para proponer un SLA adecuado:
 Ofrecer el nivel de servicio alineado a las necesidades del cliente.
 Utilizar el SLR como referente principal para la definición del SLA.
 Definir los requisitos del cliente en términos de características del servicio.

SLR-
Código:
ADE001
Requerimiento de Nivel de Servicio (SLR)

Versión 1.0

Por favor, complete el siguiente cuestionario para poder identificar los requerimientos del
negocio para brindar continuidad, disponibilidad y rendimiento de los servicios ofrecidos.

Datos del solicitante.

Área / Razón Social: Compras / Adecco Perú S.A.
Responsable: Sergio Aguirre Mercado
Email / Teléfono: Sergio.aguirre@adecco.com/(511) 611-4444 Ext 410

234
Indique el nombre del requerimiento
Servicio de atención de Compras

Realice una breve descripción del requerimiento.

Se debe generar la lista de servicios a prestar y para este logro, se define los servicios a
prestarse:
 Se debe revisar el catálogo de servicios.
 Se debe analizar el servicio para establecer los que satisfacen las expectativas del
cliente.
 Se establece los servicios que se presta al cliente
Se debe generar la lista de requisitos a partir de la definición de los objetivos y requisitos de
negocio del cliente, para ello se ejecuta las siguientes actividades:
 Se debe convocar a reuniones con el cliente para la definición de objetivos y requisitos.
 Se analiza los datos recopilados para declarar los requisitos de manera concisa,
consistente y sin ambigüedades.
Se debe generar el SLR que incluye la documentación de los requerimientos a partir de las
siguientes tareas:
 Se revisa y si es posible se refina los requerimientos para evaluar su factibilidad.
 Se determina la criticidad de los requisitos desde el punto de vista del cliente.
 Se analiza la posible solución e impacto que genera el cumplimiento de los requisitos.
 Se documenta los requerimientos en un SLR para pactar entre el cliente y el proveedor.

Indique el horario en el cual desea tener disponible el servicio.

 Lunes a Viernes ( )
 24 x 7 ( Sí )
 Otros ( ) Especifique: ______________________________________

Por cuánto tiempo puede estar “no disponible” el servicio antes de cualquier
implicación contractual o regulatoria?
La definición de disponibilidad para el cliente significa lo siguiente:
 < 4 horas ( Sí )

235
 < 8 horas ( )
 < 24 horas ( )
 Otros ( ) Especifique: ______________________________________
 .

Indique los tiempos de respuesta que desea obtener después de registrar una
solicitud, incidencia o problema del servicio en el Sistema de Gestión de Tickets.

Nivel de
Inmediata < a 4 horas < a 6 horas < a 8 horas
impacto
Crítica Sí Sí
Grave Sí
Leve Sí
.

Indique que y como desea medir el servicio

Se mide el grado de realización y de cumplimiento con los que actúan los responsables del
nivel de servicio y se desea medir de la siguiente manera:
 Estadísticas de rendimiento del servicio ( Sí )
 Tiempos de respuesta a tickets según prioridad ( Sí )

Indique como desea monitorear el servicio

Para asegurar una prestación óptima del servicio se debe analizar y reportar las metas del
nivel de servicio, verificar el cumplimiento de los acuerdos de soporte y elaborar los informes
de monitoreo.
 Reportes en el Sistema Service Now (Sí)
 Alertas en correo electrónico (Sí)
 Otros (Si) Especifique: Servicio de Monitoreo Nagios para
infraestructura Hardware que soporta la plataforma.

Equipo de procesos de TI

236
ACUERDO DE NIVEL DE SERVICIO (SLA)
El acuerdo de nivel de servicio (SLA por sus siglas en inglés, Service Level Agreement) –
(Ver Anexo 4.3), es el acuerdo contractual entre el proveedor del servicio y el cliente del
servicio. En este acuerdo se describe el servicio de TI y se especifica las responsabilidades
del proveedor y del cliente del servicio. A continuación, se presenta el SLA establecido entre
el objeto de estudio y el cliente Adecco Perú S.A. para el servicio de mantenimiento y
desarrollo de software:

SLA-
Código:
ADE001
Acuerdo de Nivel de Servicio (SLA)

Versión 1.0

CONDICIONES GENERALES

El presente documento especifica los términos del Acuerdo de Niveles de Servicio bajo los
cuales Adecco Perú S.A. se compromete a brindar el servicio definidos a continuación. Así
mismo Adecco Perú S.A. posee las facultades para modificar, actualizar o complementar este
Acuerdo de Niveles de Servicio en cualquier momento, informándose al cliente sobre los
mismos por escrito (un correo electrónico se considera suficiente).

DEFINICIONES

Gestión de Tickets

El cliente puede acceder al módulo de gestión de incidentes del Sistema Service Now desde
el siguiente enlace https://adecco.service-now.com/ sitio donde debe ingresar su usuario y
contraseña para hacer uso del aplicativo web, en donde pude registrar solicitudes y/o
incidencias de cualquiera de los servicios de TI para Adecco.

237
Si el cliente no contara con usuario y contraseña, debe solicitarlo al área de TI de Adecco,
indicando los datos del usuario para quien se solicita los accesos para generarles las
credenciales de acceso.

Excepcionalmente, el cliente puede comunicar su solicitud y/o incidencia mediante correo

electrónico o llamada telefónica; los mismos que son registrados en el Sistema Service Now
por un personal interno en representación del cliente.

Mediante el uso del Sistema Service Now, el cliente puede realizar el seguimiento de su
solicitud y/o incidencia reportada, ya que al menos recibe comunicaciones en 04
oportunidades:

 Notificación de la confirmación de registro.

 Notificación de la asignación a responsable de la solución.

 Notificación de atención en proceso.

 Notificación de la solución del ticket.

 Notificación de conformidad para el cierre del ticket.

Tiempo promedio de respuesta (TAT: Time for Average Turnaround)

El tiempo promedio de respuesta para dar solución a una solicitud o incidente está
relacionado directamente con su impacto: Leve, Critica y Grave.

El nivel de prioridad para la atención de incidentes se basa esencialmente en dos parámetros:

 Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los
procesos del negocio y/o del número de usuarios afectados.

238
 Urgencia: depende del tiempo máximo de demora aceptado por el cliente para la
resolución del incidente.

En el caso de que se tenga que dar solución a varias solicitudes o incidencias a la vez, se
considerara el parámetro “urgencia” para determinar el orden de atención.

+ 5%
+
+
Critica 10%
20%
IMPACTO

-50%
-45% -15%
Grave
-35% -10%
-25%
Leve
1h 2h 3h 4h 5h 6h 7h 8h
URGENCIA

Los factores con porcentaje positivo son puntuaciones a favor del proveedor como agilidad
en la solución hasta la tercera hora y los factores con porcentaje negativo corresponde a
puntuaciones como penalidad que aplica el cliente al proveedor desde la quinta hora hasta la
octava hora de haber sido reportado.

Impacto Crítico: las incidencias que, en el marco de la prestación del servicio, afectan
significativamente al negocio (celdas en color rojo).

Impacto Grave: las incidencias que, en el marco de la prestación del servicio, afectan
moderadamente (celdas en color amarillo).

Impacto Leve: las incidencias que se limitan a entorpecer la prestación del servicio en forma
no crítica (celdas en color celeste).

239
Disponibilidad

La disponibilidad implica la posibilidad del cliente de hacer uso de los servicios que brinda el
área de TI de Adecco Perú. Hay dos componentes fundamentales que determinan la
disponibilidad del servicio:

Disponibilidad de alimentación de red eléctrica

Garantiza la provisión permanente de alimentación de corriente alterna al/los Servidor/es

dedicado/s de Adecco Perú para brindar los servicios a los clientes.

Disponibilidad de la plataforma Adecco Suite

Garantiza la provisión permanente de la plataforma de acceso hacia las distintas aplicaciones

del negocio en al ámbito local y global. La definición de tiempo de inactividad de la suite, no
incluye los tiempos de inactividad planificados debidos al mantenimiento programado o por
razones de seguridad. La falta de respuesta exitosa al requerimiento ejecutados por los
comandos “ping / tracert / ssh” es considerada como “falta de disponibilidad” a menos que la
misma sea causada por problemas en la infraestructura de Adecco Perú.

Tiempo medio de restauración (MTTR: Mean time to repair)

Es el tiempo transcurrido entre la hora de detección del problema (por parte del proveedor del
servicio o por una notificación del cliente mediante el Sistema Service Now) y la hora de
restablecimiento del servicio.

El tiempo medio de restauración se calcula obteniendo el promedio de los tiempos de

restauración del mes.

MTTR = (Tiempo total de inactividad) / (no fallos)

A continuación, se presenta a manera de ejemplo un caso donde el servidor de aplicaciones

web ha sufrido 4 caídas en los últimos 5 meses. Las dos primeras caídas se solucionaron en
10 minutos, las dos últimas caídas tuvieron un tiempo de inactividad de 20 y 35 minutos.

240
4 fallos en 5 meses

5 meses -> 5 x 30 x 24 x 60 = 216000 minutos

4 fallos -> 10 + 10 + 20 + 35 = 75 minutos

216000 – 75 = 215925 minutos de funcionamiento correcto

MTTR = 75 min / 4 = 18.75 minutos

El porcentaje de disponibilidad que tuvo el servidor será:

(Tiempo funcionamiento / Tiempo total) x 100% = (129515 / 129600) x 100% = 99,93%

Mantenimiento programado

El mantenimiento programado es un tipo de interrupción realizado para reemplazar / agregar

servicios o instalar elementos a la red a fin de ampliar y mejorar permanentemente el servicio
brindado por el proveedor al cliente. El mantenimiento programado es notificado previamente
al cliente (como máximo hasta 48 horas de anticipación) y cuyo lapso de duración es 23
minutos, siendo el horario de mantenimiento entre la 22:00 y las 03:00 horas.

COMPROMISOS

Tiempo de respuesta (TAT: Time for Average Turnaround)

Compromiso :

Nivel de Descripción Tiempo de respuesta (TAT)

impacto
Critica Indisponibilidad total o con Máximo 4 horas laborables sin
consecuencias graves para la penalidades, a partir de la creación
operación del negocio del cliente o el del incidente. A partir de la 5 hora, se
servicio se encuentra severamente genera penalidades. No puede
degradado causando un impacto exceder de 8 horas desde la creación

241
 significativo en las operaciones y del incidente.
productividad del cliente.
Grave Las operaciones y productividad del Máximo 6 horas laborables, a partir
cliente se ven levemente degradadas. de la creación del ticket. A partir de
Los incidentes derivados del la 7 hora se genera penalidades. No
mantenimiento se incluyen dentro de puede exceder de 8 horas de creación
este nivel de impacto. del incidente.
Leve Ni las operaciones ni la Cuando un incidente aún no tiene
productividad del cliente se ven definida una complejidad ni tiempo
afectadas por el incidente. Los de resolución.
requerimientos de modificaciones y
actualizaciones se incluyen dentro de
este nivel de impacto.
Si la solución de un incidente comunicada no tuviese confirmación del cliente hasta dentro de
24 horas, se considera por aceptada la solución brindada y se cerrara el incidente. En caso de
reclamo posterior al cierre, el cliente puede reaperturar el incidente desde el Sistema Service
Now.

Adicionalmente, el área de TI de Adecco Perú (proveedor de servicio) mantiene un operador

de Soporte Tecnológico de turno fuera del horario de oficina para la atención de incidentes
con nivel de impacto “Critico”, y así cumplir con el tiempo de respuesta pactado.

Disponibilidad

Compromiso : 99.9% del tiempo

Compensación: De estar fuera de servicio por más de 0.1% (7.5 horas), la interrupción
en cuestión está considerado dentro del rubro “falta de disponibilidad”.

Porcentaje de disponibilidad Día de 8 horas

99.9% 7,50 horas

242
Tiempo medio de restauración (MTTR)

Compromiso : Menor a 30 minutos

Compensación: De superarse el valor comprometido, está considerado dentro del rubro

“falta de disponibilidad”.

Mantenimiento programado

Compromiso: Sólo se realizan trabajos de mantenimiento en el horario de 22:00 a

03:00 horas, notificando con 48 horas de anticipación al cliente.

Compensación: De no cumplirse con las normas indicadas para el mantenimiento

programado, el lapso fuera de servicio por la interrupción en cuestión está considerado dentro
del rubro “falta de disponibilidad”.

COMUNICACIÓN

Los clientes pueden comunicarse con el área de TI de Adecco Perú (proveedor de servicio)
según los medios y horarios siguientes:

Área Alcance Medio de Horario de

comunicación Atención
 Dirección General  Suite de aplicaciones Primer Canal: L - V de 8:30 a
 Auditoria Interna  Satélite comercial https://adecco.service- 18:30
 Marketing  Facturación electrónica now.com/ Exclusiones:
 Gestión Humana  ER-Entregas a Rendir (Sistema Service Now) Dom y Feriados
 Administración y Finanzas  Fractal
 Dirección Comercial  Asistencia BL Segundo Canal:
Soporte.peru@adecco.c
 Outsourcing  Microsoft Dynamics GP
om
 Selección, Bienestar y  Adecco Top
Desarrollo  Microsoft Dynamics
Tercer Canal: Por
 Dirección Professional CRM teléfono
 Gerencia Regional  Gestión de Desempeño (511) 611-4444 Ext 414
 Gerencia Industria &  Bonos y comisiones
Facility Management  WorkFlow GP
 Gerencia Minería
Hidrocarburos & Energía
 Gerencia Grupo Gloria
 Gerencia de Payroll
 Gerencia de HCS (Human
capital solution)
 Outsourcing  Adecco Suite, portal de Primer Canal: 24 horas, los 365
 Gerencia Industria & acceso a las aplicaciones https://adecco.service- días del año.
Facility Management de Adecco Perú now.com/
 Gerencia Minería (Sistema Service Now)
Hidrocarburos & Energía

243
  Gerencia Grupo Gloria
 Gerencia de Payroll
 Gerencia de HCS (Human
capital solution)

EXCLUSIONES

Quedan excluidas del cálculo para los respectivos compromisos las siguientes situaciones:
 La falla sea debida a causas atribuibles al cliente.
 Intervenciones de mantenimiento programado, según fue definido en el ítem
correspondiente.
 Declaración de zona de desastre el área involucrada en la prestación del servicio.
 Casos debidos a fuerza mayor.
 Cualquier caso en el que el área de TI de Adecco (proveedor de servicio) no sea directa o
indirectamente responsable.
LIMITACIONES

 El área de TI de Adecco (proveedor de servicio) no es responsable de los daños y

perjuicios que se deriven del mal uso o inhabilidad del cliente para utilizar los servicios
(ejemplo: errores de configuración o similares, habilidades computacionales de los
operadores, etc.).

 El área de TI de Adecco (proveedor de servicio) no es responsable por el resultado de

interrupciones, demora en la operación o transmisión o cualquier falla en el desempeño de
la red global Internet o celular, más allá de su red propia.

Firmado en la ciudad de Lima a los seis días del mes de enero de 2017

PROVEEDOR DE SERVICIO CLIENTE DE SERVICIO

Ali Reátegui Laines Héctor Castillo

Gerente de TI Director Financiero
Adecco Perú S.A. Adecco Perú S.A.

244
NIVEL DE SERVICIO OPERACIONAL
A continuación, se establecen los OLA (Ver Anexo 4.4) para los servicios de soporte
identificados.

OLA-
Formato Código
ADE001

Versión 1.0
Acuerdo de Nivel Operacional (OLA)
Página X de Y

ACUERDO DE NIVEL OPERACIONAL (OLA)

Servicio de Internet

CONDICIONES GENERALES

El presente documento especifica los términos del Acuerdo de Nivel Operacional (también
llamado OLA, Operational Level Agreement en inglés) bajo los cuales la Gerencia de TI se
compromete a brindar el /los servicio(s) especificado(s) a los Clientes Internos de Adecco
Perú.

Un representante de cualquiera de las partes puede solicitar de manera escrita la revisión del
presente acuerdo en cualquier momento. De no mediar una solicitud de revisión, se
establecen una frecuencia anual. La organización de la reunión de revisión está a cargo de la
Gerencia de TI, la cual debe hacerse efectiva antes del 5to día hábil del año correspondiente.
De las reuniones de revisión sale una minuta con lo acordado en las mismas, también firmado
por las partes e indicando la fecha propuesta para la próxima revisión.

PARTES

Las partes afectadas y que intervienen en la definición y establecimiento de este acuerdo son:

Cliente Interno Responsable Datos Contacto

Jefatura de Compras Sergio Aguirre saguirre@adecco.com.pe
Administración y Héctor Castillo hcastillo@adecco.com.pe
Finanzas

245
 Proveedor Interno Responsable Datos Contacto
Gerencia de TI Ali Reátegui areategui@adecco.com.pe
Proveedor Externo Responsable Datos de Contacto
Telefónica del Perú Eduardo Domínguez e.dominguez@telefonica.com.pe
(Ejecutivo Comercial)

VIGENCIA

Este acuerdo es válido desde el 01 de agosto del 2016 y hasta que una de las partes Clientes
Internos o Área de TI indiquen la necesidad de modificarlo o sustituirlo. En ese caso, la fecha
de finalización de la vigencia del presente documento se establece oportunamente y de
común acuerdo.

DEFINICIONES

Sistema de Gestión de Tickets

Los Clientes Internos puede reportar al Sistema de Gestión de Tickets (Service Now) vía
telefónica, en donde puede registrar solicitudes, incidencias y/o problemas de cualquiera de
los sistemas o aplicativos que da soporte el Área de TI y que estén relacionados con el
servicio de internet brindado por Telefónica del Perú.

Mediante el reporte en Service Now, los clientes internos reciben notificaciones vía correo
del estado y el seguimiento a su solicitud, incidencia y/o problema reportado, ya que al
menos recibe comunicaciones en 04 oportunidades:

 Notificación de la recepción y asignación del número de ticket.

 Notificación de estado de ticket

 Notificación de la solución del ticket.

 Notificación de conformidad para el cierre del ticket.

246
Tiempo de respuesta (TAT)

El tiempo de respuesta para dar solución a una solicitud, incidente o problema está
relacionado directamente con su prioridad: Baja, Media, Alta y Urgente.

En el caso de que se tenga que dar solución a varias solicitudes, incidencias o problemas a la
vez, se considerara la variable “complejidad” para determinar el orden de atención: Baja,
Media, Alta y Por definir.

Disponibilidad

La disponibilidad implica la posibilidad del cliente interno de hacer uso del servicio de
internet que brinda el Área de TI y Telefónica del Perú, por lo que se garantiza la provisión
permanente del servicio de internet de Adecco Perú.

Tiempo medio de restauración (MTTR)

El tiempo de restauración es el tiempo transcurrido entre la hora de detección del problema

(por parte del Área de TI o bien a través de la notificación del cliente interno mediante el
Sistema de Gestión de Tickets - Service Now) y la hora de restablecimiento del servicio.

El tiempo medio de restauración se calcula obteniendo el promedio de los tiempos de

restauración del mes.

Mantenimiento programado

El mantenimiento programado es un tipo de interrupción realizado para reemplazar / revisar,

mantener servicios asociados a la provisión de internet brindada a la empresa, en momentos
de baja o nula actividad, a fin de ampliar y mejorar permanentemente el servicio de Internet
que brinda el Área de TI y Telefónica del Perú como proveedor externo.

El mantenimiento programado es notificado previamente al cliente interno (con más de 48

horas de anticipación) y cuyo lapso de duración es de 120 minutos, siendo el horario de
mantenimiento entre la 00:00 y las 05:00 horas.

247
SISTEMAS / APLICATIVOS SOPORTADOS

Sistema / Proveedor Descripción Servidor Plataforma /

Aplicativo BD
InternetWork Telefónica Router Cisco Serie No Aplica InternetWork
del Perú 2621XM (IOS)

RESPONSABILIDADES DE LAS PARTES INVOLUCRADAS

Clientes internos

Los clientes internos se comprometen a:

 Seguir / Cumplir los procedimientos correspondientes de comunicación de solicitudes,

incidentes o problemas en los sistemas o aplicativos.
 Requerir con 02 días de anticipación servicios especiales tales como: baja / alta de nuevos
usuarios, instalaciones de equipos o accesorios nuevos, soporte fuera de horario, etc.
 Conocer y cumplir las políticas de uso de los recursos informáticos.
 Estar dispuesto y disponible para ampliar información crítica dentro de los 60 minutos de
reportado el incidente o problema. Varía para el caso de clientes internos que están fuera
de oficina.

Área de TI

El Área de TI se compromete a:

 Cumplir con los tiempos de respuesta asociados con cada nivel de prioridad asignado.

 Generar y entregar a los clientes internos reportes de gestión periódicos para monitorear
el avance del cumplimiento de los objetivos.

 Mantener y disponer de personal entrenado técnicamente en el sistema o aplicativo a

soportar.

248
 Brindar capacitaciones específicas a clientes externos de acuerdo a cronogramas
previamente pactadas.

 Realizar copias de seguridad de las bases de datos asociados a los sistemas o aplicativos.

 Realizar mantenimientos preventivos a los servidores / equipos en donde se tengan

instalados los sistemas o aplicativos.

Proveedor Externo

 Cumplir con todas las responsabilidades, acciones, medidas y compromisos pactados en

el Contrato de Prestación de Servicio INFOINTERNET y de ARRENDAMIENTO DE
EQUIPOS establecido entre Adecco Perú y Telefónica Empresas.

 Disponibilidad a tiempo completo del Ejecutivo Comercial asignado a la cuenta.

COMPROMISOS

Tiempo de respuesta (TAT)

El Área de TI se compromete a dar respuesta a las solicitudes, incidencias o problemas de los

clientes internos dentro de los siguientes tiempos:

Nivel de Descripción Tiempo de respuesta

prioridad (TAT)
Urgente Indisponibilidad total o con consecuencias Inmediata
graves para la operación del cliente interno.
Alta El servicio se encuentra severamente Máximo 5 horas
degradado causando un impacto significativo laborables, a partir de la
en las operaciones y productividad del creación del ticket en
cliente interno. Service Now.

249
 Media Las operaciones y productividad del cliente Máximo 10 horas
interno se ven levemente degradadas. Los laborables, a partir de la
problemas derivados del mantenimiento se creación del ticket en
incluyen dentro de este nivel de prioridad. Service Now.
Baja Ni las operaciones ni la productividad del Máximo 30 horas
cliente interno se ven afectadas por el laborables, a partir de la
problema. Los requerimientos de creación del ticket en
modificaciones y actualizaciones se incluyen Service Now.
dentro de este nivel de prioridad.

Si la solución de un ticket comunicada no tuviese confirmación del cliente interno hasta

dentro de 10 horas, se considera aceptada la solución brindada y se cierra el ticket. En caso de
reclamo posterior al cierre, el cliente interno puede solicitar la reapertura.

Adicionalmente, el área de TI mantiene un operador de Soporte Tecnológico de turno fuera

del horario de oficina para la atención de problemas con nivel de prioridad “Urgente”, y así
cumplir con el tiempo de respuesta pactado.

Disponibilidad

El Área de TI se compromete a asegurar la disponibilidad de los sistemas o aplicativos que

emplean los clientes internos, según:

Sistema / Aplicativo Disponibilidad Cliente Interno

Servicio de Internet – Operatividad 99.90% Toda la organización

Router Cisco 2621XM

Sistema de Gestión de Tickets – Service 99.90% Toda la organización

Now (Corporativo)

250
Tiempo medio de restauración (MTTR)

El Área de TI se compromete a brindar un tiempo medio de restauración menor a 30 minutos.

Mantenimiento programado

El Área de TI se compromete a sólo realizar trabajos de mantenimiento en el horario de 00:00

a 05:00 horas, notificando con 48 horas de anticipación a los clientes internos.

COMUNICACION

Debido a la criticidad de los sistemas / aplicativos indicados en este acuerdo, el Área de TI

atiende a las incidencias o problemas reportados por los clientes internos 24 x 7.

Sistema / Aplicativo Responsable

Servicio de Internet Danilo Ávila – Coordinador de Operaciones y de
IT (davila@adecco.com.pe)
Router – Internet Work Eduardo Domínguez – Ejecutivo Comercial TP
(e.dominguez@telefonica.com.pe)
Sistema de Gestión de Tickets Casilla Help Desk Corporativo (helpdesk-
– Service Now itcorp@adecco.com)

EXCLUSIONES

Quedan excluidas del cálculo para los respectivos compromisos las siguientes situaciones:

 La falla sea debida a causas atribuibles al cliente interno.

 Intervenciones de mantenimiento programado, según fue definido en el ítem

correspondiente.

 Declaración de zona de desastre el área involucrada en la prestación del servicio.

 Casos debidos a fuerza mayor.

 Cualquier caso en el que el Área de TI no sea directa o indirectamente responsable.

251
LIMITACIONES

 El Área de TI no es responsable de los daños y perjuicios que se deriven del mal uso o
inhabilidad del cliente para utilizar los servicios (ejemplo: errores de registro de datos en
los sistemas o aplicaciones, habilidades computacionales de los operadores, etc.). En caso
de detectarse limitaciones, se debe emitir un informe al responsable del área involucrada.

 El Área de TI no es responsable por el resultado de interrupciones, demora en la

operación o transmisión o cualquier falla en el desempeño de la red global Internet, Fija o
celular, más allá de su red propia.

OLA-
Formato Código
ADE002

Versión 1.0
Acuerdo de Nivel Operacional (OLA)
Página X de Y

ACUERDO DE NIVEL OPERACIONAL (OLA)

Servicios Web IIS

CONDICIONES GENERALES

El presente documento especifica los términos del Acuerdo de Nivel Operacional (también
llamado OLA, Operational Level Agreement en inglés) bajo los cuales la Gerencia de TI se
compromete a brindar el /los servicio(s) especificado(s) a los Clientes Internos de Adecco
Perú.

Un representante de cualquiera de las partes puede solicitar de manera escrita la revisión del
presente acuerdo en cualquier momento. De no mediar una solicitud de revisión, se
establecen una frecuencia anual. La organización de la reunión de revisión está a cargo de la
Gerencia de TI, la cual debe hacerse efectiva antes del 5to día hábil del año correspondiente.

252
De las reuniones de revisión sale una minuta con lo acordado en las mismas, también firmado
por las partes e indicando la fecha propuesta para la próxima revisión.

PARTES

Las partes afectadas y que intervienen en la definición y establecimiento de este acuerdo son:

Cliente Interno Responsable Datos Contacto

Jefatura de Compras Sergio Aguirre saguirre@adecco.com.pe

Administración y Finanzas Héctor Castillo hcastillo@adecco.com.pe

Proveedor Interno Responsable Datos Contacto

Gerencia de TI Ali Reátegui areategui@adecco.com.pe

VIGENCIA

Este acuerdo es válido desde el 02 de enero del 2017 y hasta que una de las partes Clientes
Internos o Área de TI indiquen la necesidad de modificarlo o sustituirlo. En ese caso, la fecha
de finalización de la vigencia del presente documento se establece oportunamente y de
común acuerdo.

DEFINICIONES

Sistema de Gestión de Tickets (Service Now)

Los Clientes Internos pueden reportar al Sistema de Gestión de Tickets (Service Now) vía
telefónica, en donde podrán registrar solicitudes, incidencias y/o problemas de cualquiera de
los sistemas o aplicativos que da soporte el Área de TI y que estén relacionados con los
servidores web bajo la plataforma IIS y sus servicios relacionados.

253
Mediante el reporte en Service Now, los clientes internos reciben notificaciones vía correo
del estado y el seguimiento a su solicitud, incidencia y/o problema reportado, ya que al
menos recibe comunicaciones en 04 oportunidades:

 Notificación de la recepción y asignación del número de ticket.

 Notificación de estado de ticket

 Notificación de la solución del ticket.

 Notificación de conformidad para el cierre del ticket.

Tiempo de respuesta (TAT)

El tiempo de respuesta para dar solución a una solicitud, incidente o problema está
relacionado directamente con su prioridad: Baja, Media, Alta y Urgente.

En el caso de que se tenga que dar solución a varias solicitudes, incidencias o problemas a la
vez, se considerara la variable “complejidad” para determinar el orden de atención: Baja,
Media, Alta y Por definir.

Disponibilidad

La disponibilidad implica la posibilidad del cliente interno de hacer uso de la plataforma de

gestión de compras soportada por el servidor WEB IIS que brinda el Área de TI, por lo que se
garantiza la provisión permanente de la plataforma indicada de Adecco Perú.

Tiempo medio de restauración (MTTR)

El tiempo de restauración es el tiempo transcurrido entre la hora de detección del problema

(por parte del Área de TI o bien a través de la notificación del cliente interno mediante el
Sistema de Gestión de Tickets - Service Now) y la hora de restablecimiento del servicio.

El tiempo medio de restauración se calcula obteniendo el promedio de los tiempos de

restauración del mes.

254
Mantenimiento programado

El mantenimiento programado es un tipo de interrupción realizado para reemplazar / revisar,

mantener los servicios web brindada a la empresa y específicamente a la solución de la
plataforma de gestión de compras, en momentos de baja o nula actividad, a fin de ampliar y
mejorar permanentemente el servicio de la plataforma indicada que brinda el Área de TI.

El mantenimiento programado es notificado previamente al cliente interno (con más de 48

horas de anticipación) y cuyo lapso de duración es de 120 minutos, siendo el horario de
mantenimiento entre la 00:00 y las 05:00 horas.

255
SISTEMAS / APLICATIVOS SOPORTADOS

Sistema / Proveedor Descripción Servidor Plataforma /

Aplicativo BD
IIS - Interno Servidor Web que soporta MSPADECCO32 Microsoft
Microsoft las aplicaciones de la – 192.0.20.20 Windows
plataforma de Gestión de Server 2012
Compras.
NET Interno Framework Microsoft MSPADECCO32 Microsoft
Framework – 192.0.20.20 Windows
4.0 Server 2012
ASP.NET Interno Framework Microsoft MSPADECCO32 Microsoft
– 192.0.20.20 Windows
Server 2012

RESPONSABILIDADES DE LAS PARTES INVOLUCRADAS

Clientes internos

Los clientes internos se comprometen a:

 Seguir / Cumplir los procedimientos correspondientes de comunicación de solicitudes,

incidentes o problemas en los sistemas o aplicativos.

 Requerir con 02 días de anticipación servicios especiales tales como: baja / alta de nuevos
usuarios, instalaciones de equipos o accesorios nuevos, soporte fuera de horario, etc.

 Conocer y cumplir las políticas de uso de los recursos informáticos.

 Estar dispuesto y disponible para ampliar información crítica dentro de los 60 minutos de
reportado el incidente o problema. Varía para el caso de clientes internos que están fuera
de oficina.

256
Área de TI

El Área de TI se compromete a:

 Cumplir con los tiempos de respuesta asociados con cada nivel de prioridad asignado.
 Generar y entregar a los clientes internos reportes de gestión periódicos para monitorear
el avance del cumplimiento de los objetivos.
 Mantener y disponer de personal entrenado técnicamente en el sistema o aplicativo a
soportar.
 Brindar capacitaciones específicas a clientes externos de acuerdo a cronogramas
previamente pactadas.
 Realizar copias de seguridad de las bases de datos asociados a los sistemas o aplicativos.
 Realizar mantenimientos preventivos a los servidores / equipos en donde se tengan
instalados los sistemas o aplicativos.

COMPROMISOS

Tiempo de respuesta (TAT)

El Área de TI se compromete a dar respuesta a las solicitudes, incidencias o problemas de los

clientes internos dentro de los siguientes tiempos:

Nivel de Descripción Tiempo de respuesta

prioridad (TAT)

Urgente Indisponibilidad total o con consecuencias Inmediata

graves para la operación del cliente interno.

Alta El servicio se encuentra severamente Máximo 5 horas

degradado causando un impacto laborables, a partir de la
significativo en las operaciones y creación del ticket en
productividad del cliente interno. Service Now.

257
 Media Las operaciones y productividad del cliente Máximo 10 horas
interno se ven levemente degradadas. Los laborables, a partir de la
problemas derivados del mantenimiento se creación del ticket en
incluyen dentro de este nivel de prioridad. Service Now.

Baja Ni las operaciones ni la productividad del Máximo 30 horas

cliente interno se ven afectadas por el laborables, a partir de la
problema. Los requerimientos de creación del ticket en
modificaciones y actualizaciones se Service Now.
incluyen dentro de este nivel de prioridad.

Si la solución de un ticket comunicada no tuviese confirmación del cliente interno hasta

dentro de 10 horas, se considera aceptada la solución brindada y se cierra el ticket. En caso de
reclamo posterior al cierre, el cliente interno puede solicitar la reapertura.

Adicionalmente, el área de TI mantiene un operador de Soporte Tecnológico de turno fuera

del horario de oficina para la atención de problemas con nivel de prioridad “Urgente”, y así
cumplir con el tiempo de respuesta pactado.

Disponibilidad

El Área de TI se compromete a asegurar la disponibilidad de los sistemas o aplicativos que

emplean los clientes internos, según:

Sistema / Aplicativo Disponibilidad Cliente Interno

Servidor Web IIS 99.90% Compras

Sistema de Gestión de Tickets – Service 99.90% Toda la organización

Now (Corporativo)

Tiempo medio de restauración (MTTR)

258
El Área de TI se compromete a brindar un tiempo medio de restauración menor a 30 minutos.

Mantenimiento programado

El Área de TI se compromete a sólo realizar trabajos de mantenimiento en el horario de 00:00

a 05:00 horas, notificando con 48 horas de anticipación a los clientes internos.

COMUNICACION

Debido a la criticidad de los sistemas / aplicativos indicados en este acuerdo, el Área de TI

atiende a las incidencias o problemas reportados por los clientes internos 24 x 7.

Sistema / Aplicativo Responsable

Servidor Web IIS Danilo Ávila – Coordinador de Operaciones y de IT

(davila@adecco.com.pe)

Sistema de Gestión de Casilla Help Desk Corporativo (helpdesk-

Tickets – Service Now itcorp@adecco.com)

EXCLUSIONES

Quedan excluidas del cálculo para los respectivos compromisos las siguientes situaciones:

 La falla sea debida a causas atribuibles al cliente interno.

 Intervenciones de mantenimiento programado, según fue definido en el ítem
correspondiente.
 Declaración de zona de desastre el área involucrada en la prestación del servicio.
 Casos debidos a fuerza mayor.
 Cualquier caso en el que el Área de TI no sea directa o indirectamente responsable.

259
LIMITACIONES

 El Área de TI no es responsable de los daños y perjuicios que se deriven del mal uso o
inhabilidad del cliente para utilizar los servicios (ejemplo: errores de registro de datos en
los sistemas o aplicaciones, habilidades computacionales de los operadores, etc.). En caso
de detectarse limitaciones, se debe emitir un informe al responsable del área involucrada.

 El Área de TI no es responsable por el resultado de interrupciones, demora en la

operación o transmisión o cualquier falla en el desempeño de la red global Internet, Fija o
celular, más allá de su red propia.

OLA-
Formato Código
ADE003

Versión 1.0
Acuerdo de Nivel Operacional (OLA)
Página X de Y

ACUERDO DE NIVEL OPERACIONAL (OLA)

Servicio de Base de Datos

CONDICIONES GENERALES

El presente documento especifica los términos del Acuerdo de Nivel Operacional (también
llamado OLA, Operational Level Agreement en inglés) bajo los cuales la Gerencia de TI se
compromete a brindar el /los servicio(s) especificado(s) a los Clientes Internos de Adecco
Perú.

260
Un representante de cualquiera de las partes puede solicitar de manera escrita la revisión del
presente acuerdo en cualquier momento. De no mediar una solicitud de revisión, se
establecen una frecuencia anual. La organización de la reunión de revisión está a cargo de la
Gerencia de TI, la cual debe hacerse efectiva antes del 5to día hábil del año correspondiente.
De las reuniones de revisión sale una minuta con lo acordado en las mismas, también firmado
por las partes e indicando la fecha propuesta para la próxima revisión.

PARTES

Las partes afectadas y que intervienen en la definición y establecimiento de este acuerdo son:

Cliente Interno Responsable Datos Contacto

Jefatura de Compras Sergio Aguirre saguirre@adecco.com.pe

Administración y Héctor Castillo hcastillo@adecco.com.pe

Finanzas

Proveedor Interno Responsable Datos Contacto

Gerencia de TI Ali Reátegui areategui@adecco.com.pe

VIGENCIA

Este acuerdo es válido desde el 02 de enero del 2017 y hasta que una de las partes Clientes
Internos o Área de TI indiquen la necesidad de modificarlo o sustituirlo. En ese caso, la fecha
de finalización de la vigencia del presente documento se establece oportunamente y de
común acuerdo.

DEFINICIONES

Sistema de Gestión de Tickets (Service Now)

Los Clientes Internos pueden reportar al Sistema de Gestión de Tickets (Service Now) vía
telefónica, en donde pueden registrar solicitudes, incidencias y/o problemas de cualquiera de

261
los sistemas o aplicativos que da soporte el Área de TI y que estén relacionados con los
Servicios de base de datos que dan soporte a la plataforma de gestión de compras.

Mediante el reporte en Service Now, los clientes internos recibirán notificaciones vía correo
del estado y el seguimiento a su solicitud, incidencia y/o problema reportado, ya que al
menos recibe comunicaciones en 04 oportunidades:

 Notificación de la recepción y asignación del número de ticket.

 Notificación de estado de ticket

 Notificación de la solución del ticket.

 Notificación de conformidad para el cierre del ticket.

Tiempo de respuesta (TAT)

El tiempo de respuesta para dar solución a una solicitud, incidente o problema está
relacionado directamente con su prioridad: Baja, Media, Alta y Urgente.

En el caso de que se tenga que dar solución a varias solicitudes, incidencias o problemas a la
vez, se considerara la variable “complejidad” para determinar el orden de atención: Baja,
Media, Alta y Por definir.

Disponibilidad

La disponibilidad implica la posibilidad del cliente interno de hacer uso de la plataforma de

gestión de compras cuya información y datos están soportados bajo los servicios de base de
datos que brinda el Área de TI, por lo que se garantiza la provisión permanente de la
plataforma indicada de Adecco Perú.

Tiempo medio de restauración (MTTR)

El tiempo de restauración es el tiempo transcurrido entre la hora de detección del problema

(por parte del Área de TI o bien a través de la notificación del cliente interno mediante el
Sistema de Gestión de Tickets - Service Now) y la hora de restablecimiento del servicio.

262
El tiempo medio de restauración se calcula obteniendo el promedio de los tiempos de
restauración del mes.

Mantenimiento programado

El mantenimiento programado es un tipo de interrupción realizado para reemplazar / revisar,

mantener los servicios asociados a la provisión de base de datos brindada a la empresa, en
momentos de baja o nula actividad, a fin de ampliar y mejorar permanentemente el servicio
de base de datos que brinda el Área de TI.

El mantenimiento programado es notificado previamente al cliente interno (con más de 48

horas de anticipación) y cuyo lapso de duración es de 120 minutos, siendo el horario de
mantenimiento entre la 00:00 y las 05:00 horas.

SISTEMAS / APLICATIVOS SOPORTADOS

Sistema / Proveedor Descripción Servidor Plataforma /

Aplicativo BD

SQL Server Interno Servicio de Gestión de la DBSQLONE SQL Server

2012 Base de Datos – 192.0.20.20 2012
(MSSQLSERVER) que
soporta la plataforma de
gestión de compras.

SQL Interno Herramienta de DBSQLONE SQL Server

Managment administración de la Base – 192.0.20.20 2012
Studio 2012 de datos de la plataforma
de gestión de compras

RESPONSABILIDADES DE LAS PARTES INVOLUCRADAS

Clientes internos

263
Los clientes internos se comprometen a:

 Seguir / Cumplir los procedimientos correspondientes de comunicación de solicitudes,

incidentes o problemas en los sistemas o aplicativos.

 Requerir con 02 días de anticipación servicios especiales tales como: baja / alta de nuevos
usuarios, instalaciones de equipos o accesorios nuevos, soporte fuera de horario, etc.

 Conocer y cumplir las políticas de uso de los recursos informáticos.

 Estar dispuesto y disponible para ampliar información crítica dentro de los 60 minutos de
reportado el incidente o problema. Varía para el caso de clientes internos que están fuera
de oficina.

Área de TI

El Área de TI se compromete a:

 Cumplir con los tiempos de respuesta asociados con cada nivel de prioridad asignado.
 Generar y entregar a los clientes internos reportes de gestión periódicos para monitorear
el avance del cumplimiento de los objetivos.
 Mantener y disponer de personal entrenado técnicamente en el sistema o aplicativo a
soportar.
 Brindar capacitaciones específicas a clientes externos de acuerdo a cronogramas
previamente pactadas.
 Realizar copias de seguridad de las bases de datos asociados a los sistemas o aplicativos.
 Realizar mantenimientos preventivos a los servidores / equipos en donde se tengan
instalados los sistemas o aplicativos.
 Realizar el análisis constante de la BD indicada a fin de poder ejecutar labores de tunning
y mejorar la performance en tiempo de respuesta a las consultas realizadas a dicha base.

264
COMPROMISOS

Tiempo de respuesta (TAT)

El Área de TI se compromete a dar respuesta a las solicitudes, incidencias o problemas de los

clientes internos dentro de los siguientes tiempos:

Nivel de Descripción Tiempo de respuesta

prioridad (TAT)

Urgente Indisponibilidad total o con consecuencias Inmediata

graves para la operación del cliente interno.

Alta El servicio se encuentra severamente Máximo 5 horas

degradado causando un impacto significativo laborables, a partir de la
en las operaciones y productividad del creación del ticket en
cliente interno. Service Now.

Media Las operaciones y productividad del cliente Máximo 10 horas

interno se ven levemente degradadas. Los laborables, a partir de la
problemas derivados del mantenimiento se creación del ticket en
incluyen dentro de este nivel de prioridad. Service Now.

Baja Ni las operaciones ni la productividad del Máximo 30 horas

cliente interno se ven afectadas por el laborables, a partir de la
problema. Los requerimientos de creación del ticket en
modificaciones y actualizaciones se incluyen Service Now.
dentro de este nivel de prioridad.

Si la solución de un ticket comunicada no tuviese confirmación del cliente interno hasta

dentro de 10 horas, se considera por aceptada la solución brindada y se cierra el ticket. En
caso de reclamo posterior al cierre, el cliente interno puede solicitar la reapertura.

265
Adicionalmente, el área de TI mantiene un operador de Soporte Tecnológico de turno fuera
del horario de oficina para la atención de problemas con nivel de prioridad “Urgente”, y así
cumplir con el tiempo de respuesta pactado.

Disponibilidad

El Área de TI se compromete a asegurar la disponibilidad de los sistemas o aplicativos que

emplean los clientes internos, según:

Sistema / Aplicativo Disponibilidad Cliente Interno

Servicios de Base de 99.90% Compras

Datos SQL

Servicio de 99.90% Compras

Administración de BD
SQL

Sistema de Gestión de 99.90% Toda la organización

Tickets – Service Now
(Corporativo)

Tiempo medio de restauración (MTTR)

El Área de TI se compromete a brindar un tiempo medio de restauración menor a 30 minutos.

Mantenimiento programado

El Área de TI se compromete a sólo realizar trabajos de mantenimiento en el horario de 00:00

a 05:00 horas, notificando con 48 horas de anticipación a los clientes internos.

COMUNICACION

Debido a la criticidad de los sistemas / aplicativos indicados en este acuerdo, el Área de TI

atiende las incidencias o problemas reportados por los clientes internos 24 x 7.

266
 Sistema / Aplicativo Responsable

Servicio de Base de Datos Danilo Ávila – Coordinador de

SQL Operaciones y de IT
(davila@adecco.com.pe)

Servicio Managment Studio Danilo Ávila – Coordinador de

SQL Operaciones y de IT
(davila@adecco.com.pe)

Sistema de Gestión de Tickets Casilla Help Desk Corporativo (helpdesk-

– Service Now itcorp@adecco.com)

EXCLUSIONES

Quedan excluidas del cálculo para los respectivos compromisos las siguientes situaciones:

 La falla sea debida a causas atribuibles al cliente interno.

 Intervenciones de mantenimiento programado, según fue definido en el ítem

correspondiente.

 Declaración de zona de desastre el área involucrada en la prestación del servicio.

 Casos debidos a fuerza mayor.

Cualquier caso en el que el Área de TI no sea directa o indirectamente responsable.

LIMITACIONES

 El Área de TI no es responsable de los daños y perjuicios que se deriven del mal uso o
inhabilidad del cliente para utilizar los servicios (ejemplo: errores de registro de datos en

267
 los sistemas o aplicaciones, habilidades computacionales de los operadores, etc.). En caso
de detectarse limitaciones, se debe emitir un informe al responsable del área involucrada.

 El Área de TI no es responsable por el resultado de interrupciones, demora en la

operación o transmisión o cualquier falla en el desempeño de la red global Internet, Fija o
celular, más allá de su red propia.

OLA-
Formato Código
ADE004

Versión 1.0
Acuerdo de Nivel Operacional (OLA)
Página X de Y

ACUERDO DE NIVEL OPERACIONAL (OLA)

Servicio de Correo Corporativo

CONDICIONES GENERALES

El presente documento especifica los términos del Acuerdo de Nivel Operacional (también
llamado OLA, Operational Level Agreement en inglés) bajo los cuales la Gerencia de TI se
compromete a brindar el /los servicio(s) especificado(s) a los Clientes Internos de Adecco
Perú.

Un representante de cualquiera de las partes puede solicitar de manera escrita la revisión del
presente acuerdo en cualquier momento. De no mediar una solicitud de revisión, se
establecen una frecuencia anual. La organización de la reunión de revisión está a cargo de la
Gerencia de TI, la cual debe hacerse efectiva antes del 5to día hábil del año correspondiente.

268
De las reuniones de revisión salir una minuta con lo acordado en las mismas, también
firmado por las partes e indicando la fecha propuesta para la próxima revisión.

PARTES

Las partes afectadas y que intervienen en la definición y establecimiento de este acuerdo son:

Cliente Interno Responsable Datos Contacto

Jefatura de Compras Sergio Aguirre saguirre@adecco.com.pe

Administración y Héctor Castillo hcastillo@adecco.com.pe

Finanzas

Proveedor Interno Responsable Datos Contacto

Gerencia de TI Ali Reátegui areategui@adecco.com.pe

VIGENCIA

Este acuerdo es válido desde el 02 de enero del 2017 y hasta que una de las partes Clientes
Internos o Área de TI indiquen la necesidad de modificarlo o sustituirlo. En ese caso, la fecha
de finalización de la vigencia del presente documento se establece oportunamente y de
común acuerdo.

DEFINICIONES

Sistema de Gestión de Tickets (Service Now)

Los Clientes Internos pueden reportar al Sistema de Gestión de Tickets (Service Now) vía
telefónica, en donde pueden registrar solicitudes, incidencias y/o problemas de cualquiera de
los sistemas o aplicativos que da soporte el Área de TI y que estén relacionados con los

269
Servicios de Correo brindados por la corporación y en cuya operación se soporta la
plataforma de gestión de compras.

Mediante el reporte en Service Now, los clientes internos reciben notificaciones vía correo
del estado y el seguimiento a su solicitud, incidencia y/o problema reportado, ya que al
menos recibe comunicaciones en 04 oportunidades:

 Notificación de la recepción y asignación del número de ticket.

 Notificación de estado de ticket
 Notificación de la solución del ticket.
 Notificación de conformidad para el cierre del ticket.

Tiempo de respuesta (TAT)

El tiempo de respuesta para dar solución a una solicitud, incidente o problema está
relacionado directamente con su prioridad: Baja, Media, Alta y Urgente.

En el caso de que se tenga que dar solución a varias solicitudes, incidencias o problemas a la
vez, se considerara la variable “complejidad” para determinar el orden de atención: Baja,
Media, Alta y Por definir.

Disponibilidad

La disponibilidad implica la posibilidad del cliente interno de hacer uso de la plataforma de

gestión de compras y en cuyas etapas se reciben las notificaciones respectivas por el uso de la
casilla genérica gestión-compras@adecco.com.pe brindada por el Área de TI.

Tiempo medio de restauración (MTTR)

El tiempo de restauración es el tiempo transcurrido entre la hora de detección del problema

(por parte del Área de TI o bien a través de la notificación del cliente interno mediante el
Sistema de Gestión de Tickets - Service Now) y la hora de restablecimiento del servicio.

270
El tiempo medio de restauración se calcula obteniendo el promedio de los tiempos de
restauración del mes.

Mantenimiento programado

El mantenimiento programado es un tipo de interrupción realizado para reemplazar / revisar,

mantener los servicios asociados a la provisión de base de datos brindada a la empresa, en
momentos de baja o nula actividad, a fin de ampliar y mejorar permanentemente el servicio
de base de datos que brinda el Área de TI.

El mantenimiento programado es notificado previamente al cliente interno (con más de 48

horas de anticipación) y cuyo lapso de duración es de 120 minutos, siendo el horario de
mantenimiento entre la 00:00 y las 05:00 horas.

SISTEMAS / APLICATIVOS SOPORTADOS

Sistema / Proveedor Descripción Servidor Plataforma /

Aplicativo BD

Servicio de Interno Servicio de Correo Mailing corp Microsoft

Correo corporativo en la que la
Corporativo plataforma de gestión de
compras se apoya para el
envío de notificaciones a
través de la casilla gestión-
compras@adecco.com.pe

RESPONSABILIDADES DE LAS PARTES INVOLUCRADAS

Clientes internos

Los clientes internos se comprometen a:

271
 Seguir / Cumplir los procedimientos correspondientes de comunicación de solicitudes,
incidentes o problemas en los sistemas o aplicativos.

 Requerir con 02 días de anticipación servicios especiales tales como: baja / alta de nuevos
usuarios, instalaciones de equipos o accesorios nuevos, soporte fuera de horario, etc.

 Conocer y cumplir las políticas de uso de los recursos informáticos.

 Estar dispuesto y disponible para ampliar información crítica dentro de los 60 minutos de
reportado el incidente o problema. Varía para el caso de clientes internos que están fuera
de oficina.

Área de TI

El Área de TI se compromete a:

 Cumplir con los tiempos de respuesta asociados con cada nivel de prioridad asignado.
 Generar y entregar a los clientes internos reportes de gestión periódicos para monitorear
el avance del cumplimiento de los objetivos.
 Mantener y disponer de personal entrenado técnicamente en el sistema o aplicativo a
soportar.
 Brindar capacitaciones específicas a clientes externos de acuerdo a cronogramas
previamente pactadas.
 Realizar copias de seguridad de las bases de datos asociados a los sistemas o aplicativos.
 Realizar mantenimientos preventivos a los servidores / equipos en donde se tengan
instalados los sistemas o aplicativos.

COMPROMISOS

Tiempo de respuesta (TAT)

272
El Área de TI se compromete a dar respuesta a las solicitudes, incidencias o problemas de los
clientes internos dentro de los siguientes tiempos:

Nivel de Descripción Tiempo de respuesta

prioridad (TAT)

Urgente Indisponibilidad total o con Inmediata

consecuencias graves para la
operación del cliente interno.

Alta El servicio se encuentra severamente Máximo 5 horas

degradado causando un impacto laborables, a partir de la
significativo en las operaciones y creación del ticket en
productividad del cliente interno. Service Now.

Media Las operaciones y productividad del Máximo 10 horas

cliente interno se ven levemente laborables, a partir de la
degradadas. Los problemas derivados creación del ticket en
del mantenimiento se incluyen dentro Service Now.
de este nivel de prioridad.

Baja Ni las operaciones ni la productividad Máximo 30 horas

del cliente interno se ven afectadas laborables, a partir de la
por el problema. Los requerimientos creación del ticket en
de modificaciones y actualizaciones se Service Now.
incluyen dentro de este nivel de
prioridad.

Si la solución de un ticket comunicada no tuviese confirmación del cliente interno hasta

dentro de 10 horas, se considera por aceptada la solución brindada y se cierra el ticket. En
caso de reclamo posterior al cierre, el cliente interno puede solicitar la reapertura.

273
Adicionalmente, el área de TI mantiene un operador de Soporte Tecnológico de turno fuera
del horario de oficina para la atención de problemas con nivel de prioridad “Urgente”, y así
cumplir con el tiempo de respuesta pactado.

Disponibilidad

El Área de TI se compromete a asegurar la disponibilidad de los sistemas o aplicativos que

emplean los clientes internos, según:

Sistema / Aplicativo Disponibilidad Cliente Interno

Servicios de Correo 99.90% Toda la organización

Disponibilidad de cuenta gestion- 99.90% Compras

compras@adecco.com.pe

Sistema de Gestión de Tickets – 99.90% Toda la organización

Service Now (Corporativo)

Tiempo medio de restauración (MTTR)

El Área de TI se compromete a brindar un tiempo medio de restauración menor a 30 minutos.

Mantenimiento programado

El Área de TI se compromete a sólo realizar trabajos de mantenimiento en el horario de 00:00

a 05:00 horas, notificando con 48 horas de anticipación a los clientes internos.

COMUNICACION

Debido a la criticidad de los sistemas / aplicativos indicados en este acuerdo, el Área de TI

atiende a las incidencias o problemas reportados por los clientes internos 24 x 7.

Sistema / Aplicativo Responsable

274
 Servicio de Correo y cuenta de correo Danilo Ávila – Coordinador de
gestión-compras@adecco.com.pe Operaciones y de IT
(davila@adecco.com.pe)

Sistema de Gestión de Tickets – Casilla Help Desk Corporativo (helpdesk-

Service Now itcorp@adecco.com)

EXCLUSIONES

Quedan excluidas del cálculo para los respectivos compromisos las siguientes situaciones:

 La falla sea debida a causas atribuibles al cliente interno.

 Intervenciones de mantenimiento programado, según fue definido en el ítem
correspondiente.
 Declaración de zona de desastre el área involucrada en la prestación del servicio.
 Casos debidos a fuerza mayor.
 Cualquier caso en el que el Área de TI no sea directa o indirectamente responsable.

LIMITACIONES

 El Área de TI no es responsable de los daños y perjuicios que se deriven del mal uso o
inhabilidad del cliente para utilizar los servicios (ejemplo: errores de registro de datos en
los sistemas o aplicaciones, habilidades computacionales de los operadores, etc.). En caso
de detectarse limitaciones, se debe emitir un informe al responsable del área involucrada.

 El Área de TI no es responsable por el resultado de interrupciones, demora en la

operación o transmisión o cualquier falla en el desempeño de la red global Internet, Fija o
celular, más allá de su red propia.

275
CONTRATOS DE PROVEEDORES (UNDERPINNING CONTRACTS)

En esta sección se presenta el contrato con proveedor (UC) – (Ver Anexo 5.5), donde se
detalla la información complementaria al CONTRATO DE PRESTACIÓN DEL SERVICIO
INFOINTERNET Y ARRENDAMIENTO DE EQUIPOS celebrado con Telefónica
Empresas y Adecco Perú y que establece el marco contractual del servicio de comunicación
para soportar las funciones de la Plataforma de Gestión de Compras.

UC-
Formato Código
ADE-001

Contrato de Soporte (UC) Versión 1.0

Proveedor de Servicios externo Telefónica

Página X de Y
del Perú

Datos del Proveedor

Razón Social: Telefónica del Perú S.A.A.

Nro. R.U.C.: 20100017491

Dirección: Av. Benavides Nro. 661 piso 1, Miraflores-Lima

Teléfono: 0800-16600

Horario: 24 horas

Datos del Contacto (1)

Nombres y Apellidos: Eduardo Domínguez

276
Cargo: Ejecutivo Comercial – Cuenta Adecco Perú

Correo Electrónico: e.dominguez@telefonica.com.pe

Datos del Contacto (2)

Nombres y Apellidos: Mariano Carrillo

Cargo: Gerente Comercial – Telefónica Grandes Empresas

Correo Electrónico: m.carrillo@telefonica.com.pe

Servicio que brinda

Servicio de acceso a Internet a través de su red IP MPLS (acceso simétrico digital

dedicado), denominado comercialmente “Infointernet”, y; el arrendamiento de equipos
terminales.

Soporte que brinda

Haciendo referencia al punto 5.5 del contrato celebrado entre Adecco Perú y Telefónica del
Perú se extrae lo siguiente:

“El mantenimiento y soporte del Servicio se contempla en varios niveles. En el más bajo de
ellos, el mantenimiento de primer nivel facilita la reparación “in situ” de la avería, y
actuación directa sobre la línea dedicada. En el soporte técnico de segundo nivel,
Telefónica del Perú también resuelve problemas que requieren un grado mayor de
experiencia y conocimiento. Telefónica del Perú ofrece también, como parte integral del
Servicio, el esquema de mantenimiento de primer nivel, con unos tiempos de atención y
reparación acordes a la disponibilidad de medios de comunicación e infraestructuras del
país. Para tal efecto Telefónica del Perú cuenta con: Personal calificado para brindar el
soporte oportuno y óptimo a la red. Atención del Servicio durante todo el año. El esquema

277
de mantenimiento no incluye averías no imputables Telefónica del Perú, por ejemplo,
problemas por daños ocasionados por terceros, en la acometida externa o de robo de cable
que involucren cambios de las facilidades técnicas en el CLIENTE. El precio del esquema
de mantenimiento está incluido en el precio de alquiler de los equipos, sin embargo, en el
caso que los equipos sean vendidos al CLIENTE, ellos deben asumir el costo de
mantenimiento de los equipos.”

Compromiso de Garantía

Haciendo referencia al punto 3.4.1 del contrato celebrado entre Adecco Perú y Telefónica
del Perú se extrae lo siguiente:

“Telefónica del Perú establece su garantía de servicio en torno a los siguientes puntos:

 Personal especializado y de experiencia para dar el soporte técnico necesario,

distribuidos a nivel nacional para cualquier eventualidad que se pueda presentar.

 Centro de Gestión de servicios IP, el cual desempeña permanentemente un papel

proactivo de manera que se garantice la calidad del servicio comprometido, monitoriza
la performance del enlace y los equipos de acceso.

 Opcionalmente, los resultados de los parámetros monitorizados por cada enlace

pueden ser visualizados vía Internet o InfoVía a través de una cuenta personalizada de
acceso al Servidor de Calidad de Servicio de TELEFÓNICA.

 Permite un ahorro del 10% del consumo de ancho de banda en comparación a las
demás tecnologías del mercado (ATM).

 Garantía de disponibilidad y calidad de ancho de banda contratado.

 Redundancia en los enlaces internacionales.

 Acceso rápido a contenidos locales pues TELEFÓNICA pertenece al NAP.”

278
TRANSICIÓN DEL SERVICIO
El propósito durante la fase de Transición del Servicio es lograr que los servicios definidos
durante la fase de Diseño del Servicio se puedan integrar dentro del ambiente de producción
y de esta manera permitir la accesibilidad a estos servicios para los usuarios autorizados por
el cliente. Los objetivos de esta fase son supervisar y brindar el soporte al proceso de cambio
del servicio y garantizar que los servicios cumplan los estándares y requisitos establecidos
durante las fases de Estrategia y la de Diseño.

A continuación, se presentan los artefactos definidos durante los procesos de Gestión de

Cambios y Gestión de Activos del Servicio y Gestión de la Configuración.

REQUERIMIENTO DE CAMBIO (RFC)

Una solicitud de cambio (RFC, request for change por sus siglas en inglés) – (ver Anexo 4.6)
es una propuesta formal para hacer un cambio que incluye los detalles propuestos, este
artefacto puede ser en formato impreso (papel) o electrónico, en algunas ocasiones este
término es confundido para referirse al registro de algún cambio y/o al cambio en sí mismo.

En Adecco Perú, evaluando el proceso servicio atención de compras, considera que las
razones para realizar este cambio son para el desarrollo de nuevos servicios y para la mejora
de los servicios existentes.

A continuación, se define el Procedimiento con el RFC

 El proceso inicia con el trámite administrativo de un RFC por parte del cliente del
servicio que solicita algún cambio y lo envía a su departamento de Gestión de Cambios,
donde realizan la valoración, evaluación y decisión para aceptar, rechazar u observar
(solicitar la actualización en el RFC).
 Aquellos cambios que son calificados, son categorizados de acuerdo a su nivel de
impacto.
 Si el RFC es aceptado, se planifica su ejecución, se comunica la decisión y se ejecuta,
luego el cliente, determina si el resultado fue exitoso.
 El proceso finaliza cuando el administrador de cambios valida el cambio y cierra el RFC.

279
 Código: RFC-ADE001
Requerimiento de Cambio (RFC)
Versión 1.0

Datos del solicitante

* Nombre del Solicitante Sergio Aguirre Mercado
* Aprobador/es Héctor Castillo Alfonso
⃝ Emergencia
⃝ Simple
* Categoría del cambio
⃝ Mediano
⃝ Complejo

Identificación del cambio

* Descripción del cambio Servicio de atención de compras
* Proyecto Relaconado Ninguno

* Urgencia ʌ Alta

* Impacto ʌ Alto

* Entorno ʌ Producción
Servicios afectados Compras, Contabilidad, Facturación, Auditoria intena, TI
Áreas implicadas Compra, Contabilidad, Facturación, Auditoría interna, Legal, TI
Microsoft Dynamics GP, GP Data Base
Elementos de
Manual de usuario / Sistemas / Pase QA.PROD /Arquitectura/
configuración afectados
Arquitectura de aplicaciones y Base de datos
Afecta nivel de servicio Si
Fecha límite 21.ene.2017
N° usuarios afectados 100

Detalle del cambio

* Motivo del cambio Se requiere implementar
Disminuir la carga de trabajo por regularización de compras
Mejorar el desempeño actual del proceso de compras
Optimizar los niveles de aprobación en la gestión de compras
* Objetivo del cambio Mejorar la gestión de contratos con el proveedor

280
 Aceleración del cumplimiento de objetivos, al propiciar un clima auto-
gestionado, trabajo en equipo y adaptado al cambio.
Disminuir costos con la automatización y optimización de los embudos del
proceso de compras y la garantía del cumplimiento de políticas del proceso de
Detalles del impacto
compras.
Satisfacción del equipo de compras con la implicación de este, durante la
planificación y ejecución del proyecto, generando sinergias y eliminando el
derroche de recursos.
Efectos de la no No se cumpliría el alineamiento del Servicio de Atención de Compras con los
implementación objetivos estratégicos de la organización
Inicio previsto 01.feb.2017
Finalización prevista 01.jul.2017
Mantenimiento evolutivo
⃝ Nueva funcionalidad
⃝ Nueva versión
⃝ Nuevo servicio
⃝ Paso de un entorno a otro
* Clasificación del cambio
Mantenimiento preventivo
⃝ Mantenimiento
⃝ Mejora de servicio
⃝ Mantenimiento adaptativo
⃝ Mantenimiento correctivo

Temas a realizar
Flujo del proceso (orden)
* Tarea 1 Seguridad de accesos, negociación de precios y configuración de perfiles
* Tarea 2 Integración con el Sistema ERP Microsoft Dynamics GP
* Tarea 3 Generación de órdenes de pago y órdenes de compras
* Tarea 4 Alertas de órdenes de compras, pagos y reportes para monitoreo

Plan de pruebas
Acciones a realizar para comprobar la ejecución correcta del cambio
Tarea 1 Seguridad de accesos, negociación de precios y configuración de perfiles
Tarea 2 Integración con el Sistema ERP Microsoft Dynamics GP
Tarea 3 Generación de órdenes de pago y órdenes de compras

281
Tarea 4 Alertas de órdenes de compras, pagos y reportes para monitoreo

Plan de contingencia
Acciones a realizar en caso de errores
Tarea 1 Habilitar los accesos a los usuarios solicitantes/aprobadores en ERP GP
Tarea 2 Habilitar la funcionalidad de solicitud de requerimientos en ERP GP
Tarea 3 Aprobaciones manuales de órdenes de compra y pago
Tarea 4 Envío manual de órdenes de servicio y órdenes de compras por correo

Documentación asociada al cambio

 Prototipos  Plan de Prueba  Manual de Sistemas
 Modelo de Datos  Informe de migración  Manual de Usuario
 Arquitectura Software  Informe de Pruebas  Manual de Instalación
 Informe de construcción  Código Fuente  Cronograma de proyecto

(*) Campos con asterisco son obligatorios a cumplir por el solicitante

282
ELEMENTOS DE CONFIGURACIÓN

A continuación, se listan los elementos de configuración relacionados a la propuesta:

Dirección(es) Dirección(es) IP Propio o

Código CI Tipo CI Estado CI Nombre de CI Descripción CI Tipo de Relación CI asociado Ubicación Responsable / Usuario Marca Modelo Sistema Operativo Versión Comentarios
IP Privada Pública Alquilado?
Servidor físico para alojar las
HW-001 Servidor Físico Planificado MSPEADECCO aplicaciones para ambiente de HP - Data Center 192.0.10.10 Windows Server 2012 R2 Standard Propio
desarrollo y testing. Rolando Poma HP Proliant ML110
Servidor virtual de aplicaciones para
216.244.141.36 Rolando Poma/Javier
HW-002 Servidor Virtual Planificado MSPEADECCO028 DESARROLLO que alojará la suite ERP Se ejecuta en HW-001 HP - Data Center 192.0.10.11 Windows Server 2012 R2 Standard Propio
Gonzales Virtualización realizada
y la nueva plataforma de compras.
en Hyper-V
Servidor virtual de aplicaciones para
216.244.141.37 Rolando Poma/Eduardo
HW-003 Servidor Virtual Planificado MSPEADECCO029 TESTING que alojará la suite ERP y la Se ejecuta en HW-001 HP - Data Center 192.0.10.12 Windows Server 2012 R2 Standard Propio
Ortiz Virtualización realizada
nueva plataforma de compras.
en Hyper-V
Servidor físico para alojar las BD's
HW-004 Servidor Físico Planificado DBSQLADECCO como ambiente de desarrollo y HP - Data Center 192.0.10.15 Rolando Poma HP Windows Server 2012 R2 Standard Propio
testing. Proliant ML110
Servidor virtual para DESARROLLO
216.244.141.40 Rolando Poma/Javier
HW-005 Servidor Virtual Planificado DBSQLADECCO030 que alojará la BD de ERP y de la Se ejecuta en HW-004 HP - Data Center 192.0.10.16 Windows Server 2012 R2 Standard Propio Virtualización realizada
Gonzales
nueva plataforma de compras. en Hyper-V
Servidor virtual para TESTING que
216.244.141.41 Rolando Poma/Eduardo
HW-006 Servidor Virtual Planificado DBSQLADECCO031 alojará la BD de ERP y de la nueva Se ejecuta en HW-004 HP - Data Center 192.0.10.17 Windows Server 2012 R2 Standard Propio Virtualización realizada
Ortiz
plataforma de compras. en Hyper-V
Servidor físico para alojar los
servidores virtuales que brindarán Ali Reategui/Sergio
HW-007 Servidor Físico Activo MSPEADEPROD HP - Data Center 192.0.20.20 HP Proliant 360DL Windows Server 2012 R2 Enterprise Propio
servicio en producción a la Aguirre
plataforma de compras.

Servidor virtual para PRODUCCIÓN

216.244.145.66 Ali Reategui/Sergio
HW-008 Servidor Virtual Activo MSPEADECCO032 que aloja la suite ERP y alojará la Se ejecuta en HW-007 HP - Data Center 192.0.20.50 Windows Server 2012 R2 Standard Propio
Aguirre Virtualización realizada
nueva plataforma de compras.
en Hyper-V

Servidor virtual para PRODUCCIÓN

que aloja la BD deL ERP y alojará el 216.244.145.67 Ali Reategui/Sergio
HW-009 Servidor Virtual Activo DBSQLONE Se ejecuta en HW-007 HP - Data Center 192.0.30.32 Windows Server 2012 R2 Standard Propio
nuevo esquema de la nueva Aguirre
plataforma de compras. Virtualización realizada
en Hyper-V
TI - Data Center TI Corporativo/Toda la Servidor corporativo de
HW-010 Servidor Físico Activo GLOBAL-MAILCORP Servidor de correo corporativo
Corporativo organización correo

Tabla 51 - CI´s Asociados al Hardware

Fuente: Elaboración propia

283
 Tipo de Responsable /
Código CI Tipo CI Estado CI Nombre de CI Descripción CI CI asociado Ubicación Comentarios
Relación Usuario
Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en HW-002
SW-001 Microsoft Dynamics GP ERP ambiente de desarrollo HP Data Center Javier Gonzales con Nueva GESCOM
Instalación orientada a pruebas de integración
Aplicación Planificado Se ejecuta en HW-003
SW-002 Microsoft Dynamics GP ERP ambiente de testing HP Data Center Eduardo Ortiz con Nueva GESCOM
Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en HW-002
SW-003 Internet Information Services Servidor Web que alojará la nueva GESCOM HP Data Center Javier Gonzales con Nueva GESCOM
Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en
SW-004 Net Framework 4.0 Migración de framework ERP HW-002 HP Data Center Javier Gonzales con Nueva GESCOM
Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en
SW-005 ASP.NET Framework de desarrollo Nueva GESCOM HW-002 HP Data Center Javier Gonzales con Nueva GESCOM
Instalación orientada a pruebas de integración
Aplicación Planificado Se ejecuta en HW-003
SW-006 Internet Information Services Servidor Web que alojará la nueva GESCOM HP Data Center Eduardo Ortiz con Nueva GESCOM
Instalación orientada a pruebas de integración
Aplicación Planificado Se ejecuta en
SW-007 Net Framework 4.0 Migración de framework ERP HW-003 HP Data Center Eduardo Ortiz con Nueva GESCOM
Instalación orientada a pruebas de integración
Aplicación Planificado Se ejecuta en
SW-008 ASP.NET Framework de desarrollo Nueva GESCOM HW-003 HP Data Center Eduardo Ortiz con Nueva GESCOM
Instalación planificada de la nueva plataforma
Aplicación Planificado Se ejecuta en
SW-009 NEO GESCOM Nueva Plataforma de Gestión de Compras HW-002 HP Data Center Javier Gonzales de compras
Instalación planificada de la nueva plataforma
Aplicación Planificado Se ejecuta en HW-003
SW-010 NEO GESCOM Nueva Plataforma de Gestión de Compras HP Data Center Eduardo Ortiz de compras
BD para ambiente de desarrollo, alojará ERP Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en
SW-011 SQL SERVER 2012 y NEO GESCOM HW-002 HP Data Center Javier Gonzales con Nueva GESCOM
BD para ambiente de testing, alojará ERP y Instalación orientada a pruebas de integración
Aplicación Planificado Se ejecuta en
SW-012 SQL SERVER 2012 NEO GESCOM HW-003 HP Data Center Eduardo Ortiz con Nueva GESCOM
Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en HW-002
SW-013 HYPER-V Plataforma de virtualización desarrollo HP Data Center Danilo Ávila con Nueva GESCOM
Instalación orientada a pruebas de integración
Aplicación Planificado Se ejecuta en HW-003
SW-014 HYPER-V Plataforma de virtualización testing HP Data Center Danilo Ávila con Nueva GESCOM
SO para servidor físico desarrollo que aloja Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en HW-002
SW-015 Microsoft Windows Server 2012 virtuales HP Data Center Danilo Ávila con Nueva GESCOM
SO para servidor físico testing que aloja Instalación orientada a pruebas de integración
Aplicación Planificado Se ejecuta en HW-003
SW-016 Microsoft Windows Server 2012 virtuales HP Data Center Danilo Ávila con Nueva GESCOM
SO para servidor virtual de aplicaciones para Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en HW-002
SW-017 Microsoft Windows Server 2012 desarrollo HP Data Center Danilo Ávila con Nueva GESCOM
SO para servidor virtual de BD para Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en HW-005
SW-018 Microsoft Windows Server 2012 desarrollo HP Data Center Danilo Ávila con Nueva GESCOM
SO para servidor virtual de aplicaciones para Instalación orientada a labores de desarrollo
Aplicación Planificado Se ejecuta en HW-003
SW-019 Microsoft Windows Server 2012 testing HP Data Center Danilo Ávila con Nueva GESCOM
SW-020 Aplicación Planificado Microsoft Windows Server 2012 SO para servidor virtual de BD para testing Se ejecuta en HW-006 HP Data Center Danilo Ávila Instalación orientada a labores de desarrollo
SO para servidor físico PRODUCCION que Ali Reategui / Sergio Instalación orientada a labores de desarrollo
Aplicación Activo Se ejecuta en HW-007
SW-021 Microsoft Windows Server 2012 aloja virtuales HP Data Center Aguirre con Nueva GESCOM
SO para servidor virtual PRODUCCION - Ali Reategui / Sergio Virtual aplicaciones que brinda servicio a
Aplicación Activo Se ejecuta en HW-008
SW-022 Microsoft Windows Server 2012 Aplicación ERP HP Data Center Aguirre producción y que alojará NEO GESCOM
SO para servidor virtual PRODUCCION - BD Ali Reategui / Sergio Virtual BD que brinda servicio a producción y
Aplicación Activo Se ejecuta en HW-009
SW-023 Microsoft Windows Server 2012 ERP HP Data Center Aguirre que alojará nuevo esquema NEO GESCOM
Ali Reategui / Sergio Motor de BD Producción ERP y que soportará
Aplicación Activo Se ejecuta en HW-009
SW-024 SQL SERVER 2012 BD PRODUCCION ERP HP Data Center Aguirre esquema NEO GESCOM
SW-025 Aplicación Activo SQL Managment Studio 2012 Consola de administración BD SQL SERVER Ali Reategui Consola de administración SQL Server
Consola de administración BD SQL SERVER
Aplicación Planificado
SW-026 SQL Managment Studio 2012 para desarrollo y testing Ali Reategui Consola de administración SQL Server
Implementación de Nueva Plataforma de
Aplicación Planificado Se ejecuta en HW-002
SW-027 NEO GESCOM Gestión de Compras desarrollo HP Data Center Javier Gonzales Nueva Plataforma de Gestion de Compras
Implementación de Nueva Plataforma de
Aplicación Planificado Se ejecuta en HW-003
SW-028 NEO GESCOM Gestión de Compras testing HP Data Center Eduardo Ortiz Nueva Plataforma de Gestion de Compras
Implementación de Nueva Plataforma de Ali Reategui / Sergio
Aplicación Planificado Se ejecuta en HW-008
SW-029 NEO GESCOM Gestión de Compras PRODUCCIÓN HP Data Center Aguirre Nueva Plataforma de Gestion de Compras
Tabla 52 - CI's asociados al Software
Fuente: Elaboración Propia

284
GESTIÓN DEL PORTAFOLIO DEL SERVICIO
A continuación, se detalla el proceso y modelo base a seguir para la Gestión del Portafolio
del Servicio:

CI SGC-R001
PROCESO DE GESTIÓN DEL PORTAFOLIO
Versión 1.0
DE SERVICIO
Fecha 15/12/2016

PROCESO DE GESTIÓN DEL PORTAFOLIO DEL SERVICIO

Actualizado a

Diciembre del 2016

285
Contenido

 OBJETIVO
 ALCANCE
 REFERENCIAS
 DEFINICIONES
 RESPONSABILIDADES
 CONDICIONES GENERALES
 DESARROLLO
 REGISTROS
 DIAGRAMA DEL PROCESO

ADVERTENCIA: Prohibido reproducir sin la autorización de Auditoría

Página X de Y
Interna

HISTORIAL DE LAS REVISIONES

Responsable
de Revisión
Ítem Versión Fecha Autor Descripción Estado
y/o
Aprobación

01 1.0 15/12/2016 Gisela Versión inicial del Aprobado Ali Reátegui

Lopez proceso. Carlos San
Román

286
OBJETIVO

El presente documento establece las pautas para realizar adecuadamente la Gestión del
Portafolio de Servicio de Adecco Perú, para generar el máximo valor controlando los
riesgos y costes.

ALCANCE

El presente procedimiento está dirigido a toda el Área de Tecnologías de Información y

describe las tareas para evaluar los requisitos de calidad y costes de los servicios.

REFERENCIAS

ITIL 2011.

DEFINICIONES

 Portafolio de Servicio: Listado completo y detallado de los servicios administrados

por la organización, describiéndolos en términos de valor del negocio.

 Proyección de Servicios (Service Pipeline): Fase 1 del Portafolio de Servicios, que

incluye tan sólo los servicios que están en fase de estudio o desarrollo.

 Catálogo de Servicios (Service Catalogue): Fase 2 del Portafolio de Servicios, que

incluye tan solo aquellos servicios que la organización está prestando actualmente
de cara a los clientes.

 Servicios Retirados (Retired Services): Fase 3 del Portafolio de Servicios, que

incluye tan solo los servicios que hayan sido retirados o estén próximos a su baja.

287
 Es importante conservar la documentación de estos servicios puesto que otros
puedan verse en la necesidad de recurrir a ella.

 ROI (Return on Investment): El Retorno sobre la Inversión es una herramienta para

analizar el rendimiento que la empresa tiene desde el punto de vista financiero
(utilidad en base a la inversión).

 RFC (Requirement for change): Solicitud formal para la implementación de un

cambio. En el caso de Adecco Perú, éste es registrado como un ticket en el Sistema
de Gestión de Tickets.

 Sistema de Gestión de Tickets: Aplicativo web en donde se puede registrar también

el RFC para que internamente se pueda hacer el seguimiento (cambios de estados)
correspondiente.

RESPONSABILIDADES

La Gerencia de Tecnologías de Información es el responsable de asegurar la correcta

aplicación del presente procedimiento.

CONDICIONES GENERALES

No aplica.

DESARROLLO

1. Recibir requerimientos de servicio y crear Ficha del alcance del servicio (inicial)

Gerencia de TI

1.1 Recibe las solicitudes de los clientes, los cuales pueden ser nuevos servicios o
modificaciones a los ya existentes en el Portafolio de Servicios.

1.2 Crea la Ficha del alcance del servicio con información inicial para que sea evaluado por
el Gestor de Portafolio de Servicios.

288
1.3 En caso de que la solicitud se tratase de una baja de un servicio vigente en el Portafolio
de Servicios, la siguiente tarea es la mencionada en el punto 4.

2. Actualizar la Ficha del alcance del servicio

Gestor del Portafolio de Servicios

2.1 En base al alcance del servicio determinado por la Gerencia de TI, el Gestor del
Portafolio de servicios complementa la información actualizando la Ficha del alcance del
servicio.

3. Evaluar el alineamiento estratégico del servicio

Gerencia de TI

3.1 Evalúa que el servicio este alineado a la estrategia del negocio de Adecco Perú, según
lo indicado en la Ficha del alcance del Servicio.

3.2 Si como resultado de la evaluación la Gerencia de TI decide rechazar el requerimiento

del cliente, se comunica a éste mediante correo electrónico; de lo contrario, se continua con
la siguiente tarea.

4. Identificar los riesgos del servicio

Gestor del Portafolio de Servicio

4.1 Elabora una Matriz de Riesgos en la que se identifiquen los posibles impactos y
probabilidades que implicaría la implementación del servicio requerido, por ejemplo:
relación con otros servicios (en fase de desarrollo o ya vigentes), tiempos de
implementación, recursos disponibles, etc.

4.2 Una vez que se tenga la Matriz de Riesgos del servicio, se envia al Gerente de TI para
su evaluación.

5. Evaluar la factibilidad técnica del servicio

289
Gerencia de TI

5.1 Evalúa la factibilidad técnica del servicio en base a la Ficha del alcance del servicio y la
Matriz de Riesgos.

5.2 Si el análisis de factibilidad técnica es viable, se continua con la siguiente tarea; de lo

contrario, la Gerencia de TI indica las limitaciones o motivos por los cuales no se puede
cumplir con lo solicitado por el cliente.

Gestor del Portafolio de Servicios

5.3 En caso de rechazo, el Gestor de Portafolio de Servicios comunica al cliente, mediante

correo electrónico, que el requerimiento de servicio no es factible técnicamente.

6. Identificar el flujo financiero de servicio

Gestor del Portafolio de Servicio

6.1 Elabora el Flujo de Caja proyectado donde se indica el plan de ingresos, egresos y
saldos de efectivo necesarios para el requerimiento del cliente.

7. Evaluar la factibilidad del servicio

Dirección General y Dirección de Administración de Finanzas

7.1 Evalúan la factibilidad del servicio en base a los documentos: Ficha de Alcance del
Servicio, Matriz de riesgos del servicio y Flujo de Caja proyectado.

7.2 Si todas las direcciones mencionadas aprueban la factibilidad del servicio, entonces, se
continúa con la siguiente tarea, de lo contrario, se indican las limitaciones o motivos por los
cuales no es factible el requerimiento del cliente.

Gestor del Portafolio de Servicios

7.3 En caso de rechazo, el Gestor de Portafolio de Servicios comunica al cliente, mediante

correo electrónico, que el requerimiento de servicio no es factible técnicamente.

290
8. Elaborar y enviar la propuesta económica

Dirección de Administración y Finanzas y Gerencia de TI

8.1 Elabora y envía la propuesta económica al cliente siempre y cuando se tratase de un

requerimiento de servicio específico para el cliente.

8.2 Una vez que se tenga la aprobación del cliente, la siguiente tarea es la mencionada en el
punto 9., caso contrario, el proceso se considera por concluido.

9. Registrar el RFC

Gestor del Portafolio de Servicio

9.1 Registra el RFC en el Sistema de Gestión de Tickets, en base a la Ficha del Alcance del
Servicio ya aprobado por las Direcciones General y de Administración y Finanzas.

9.2 Una vez que se tenga el RFC, el documento es enviado a los procesos de:

9.2.1 Diseño de Servicios - Gestión de Proveedores: Para solicitar la cotización oficial del
desarrollo del servicio (nuevo o modificado).

9.2.2Transición de Servicios - Gestión del Cambio: Para evaluar y planificar el proceso de

cambio que implica la implementación del servicio.

10. Actualizar el Portafolio de servicio.

Gestor del Portafolio de Servicio

10.1 Actualiza el Portafolio de Servicios, según la fase en la que se encuentre el servicio:

Proyección de Servicios, Catálogo de Servicios o Servicios Retirados. Adicionalmente,
indica el estado en la que se encuentra el servicio: Retención, Sustitución, Racionalización,
Refactorización, Renovación, Retirada.

REGISTROS

291
 Ficha del Alcance del Servicio (Ver formato base en Anexos 4.1)

 Matriz de Riesgos del Servicio

 Flujo de Caja proyectado

 RFC (Ver formato base en Anexos 4.6)

292
DIAGRAMA DEL PROCESO

Figura 55 - Proceso de Gestión del Portafolio del Servicio

Fuente: Elaboración Propia

293
GESTIÓN DEL NIVEL DEL SERVICIO
A continuación, se detalla el proceso y modelo base a seguir para la Gestión del Nivel del
Servicio:

CI SGC-R002
PROCESO DE GESTIÓN DEL NIVEL DEL
Versión 1.0
SERVICIO
Fecha 16/12/2016

PROCESO DE GESTIÓN DEL NIVEL DEL SERVICIO

Actualizado a

Diciembre del 2016

294
Contenido:

 OBJETIVO

 ALCANCE

 REFERENCIAS

 DEFINICIONES

 RESPONSABILIDADES

 CONDICIONES GENERALES

 DIAGRAMA DEL PROCESO

 DESARROLLO

 INDICADORES

 REGISTROS

 ANEXOS

ADVERTENCIA: Prohibido reproducir sin la autorización de Auditoría

Página X de Y
Interna

HISTORIAL DE LAS REVISIONES

295
 Responsable de
Ítem Versión Fecha Autor Descripción Estado Revisión y/o
Aprobación

02 1.0 16/12/2016 Gisela Versión inicial del Aprobado Ali Reátegui

Lopez proceso. Carlos San
Román

OBJETIVO

El presente documento establece las pautas para realizar adecuadamente la Gestión del Nivel
de Servicio de TI, alineando la tecnología con los procesos de negocio de Adecco Perú.

ALCANCE

El presente procedimiento está dirigido a toda el Área de Tecnologías de Información y

describe desde la definición de los requerimientos de Nivel de Servicio hasta su
implementación y comunicación.

REFERENCIAS

ITIL 2011.

DEFINICIONES

 SLA (Service Level Agreement): Un Acuerdo de Nivel de Servicio es un contrato

escrito entre un proveedor de servicio de TI y su cliente con el objeto de fijar niveles
de calidad de los servicios acordados.

296
  SLR (Service Level Request): Un Requisito de Nivel de Servicio es un documento
que recoge la información detallada de las necesidades del cliente y sus expectativas
de rendimiento y nivel de servicios.

 OLA (Operational Level Agreement): Un Acuerdo de Nivel Operacional es un

documento interno de la organización donde se especifican las responsabilidades y
compromisos de los diferentes departamentos de la organización de TI en la
prestación de un determinado servicio.

 UC (Underpinning Contract): Un Contrato de Soporte es un acuerdo con un

proveedor externo para la prestación de servicios no cubiertos por la propia
organización de TI.

RESPONSABILIDADES

El Gerente de Tecnologías de Información es el responsable de asegurar la correcta

aplicación del presente procedimiento.

CONDICIONES GENERALES

No aplica.

297
DIAGRAMA DEL PROCESO

Figura 56 - Proceso de Gestión del Nivel de Servicio

Fuente: Elaboración propia

298
DESARROLLO

1. Antecedentes

Gerencia de TI

1.1 Recibe las solicitudes de los clientes, los cuales pueden ser nuevos servicios o
modificaciones a los niveles de calidad de los servicios vigentes.

2. Determinar requisitos del servicio (nuevo / cambio)

Gerencia de TI

2.1 Elabora el SLR en base a la solicitud del cliente, ya sea para incluir o modificar el SLA
estándar.

3. Identificar UC’s relacionados al servicio

Gestor del Nivel de Servicio

3.1 Identifica los proveedores que participan en la prestación del servicio.

3.2 Por cada proveedor, verifica las clausulas en los contratos que hagan referencia a los
niveles de servicio recibidos.

4. Identificar OLA’s relacionados al servicio

Gestor del Nivel de Servicio

4.1 Identifica las Áreas Internas que participan en la prestación del servicio.

4.2 Por cada Área Interna, verifica los acuerdos internos que hagan referencia a los niveles
de servicio a prestarse a los clientes.

5. Análisis de factibilidad del SLR

299
Gestor del Nivel de Servicio

5.1 Elabora el análisis de factibilidad del SLR.

5.2 Si el análisis de factibilidad es viable, propone las opciones para alcanzar los nuevos
términos del SLA; de lo contrario indica las limitaciones o motivos por los cuales no se
pueden cumplir lo solicitado.

6. Evaluar y proponer las opciones para SLA

Gestor del Nivel de Servicio

6.1 Convoca a reunión con las gerencias involucradas para comunicar y evaluar las opciones
para aceptar o rechazar los nuevos términos del SLA. Como resultado de esta reunión, se
indica si se procede con la elaboración / modificación de SLA (estándar o a medida).

7. Elaborar / Modificar el SLA a medida

Gestor del Nivel de Servicio

7.1 Si en el SLR se indica que el cliente solicita una modificación especial al SLA estándar,
entonces, el Gestor de Nivel de Servicio elabora un SLA tomando como base el SLA
estándar.

7.2 Una vez que se tenga el SLA a medida, el documento es enviado para aprobación de la
Dirección Comercial, Dirección de Administración y Finanzas, Dirección General y
Gerencia de TI.

8. Modificar el SLA estándar

Gestor del Nivel de Servicio

8.1 Si en el SLR se indica una modificación al SLA estándar, ya sea porque se necesita
incluir un nuevo servicio o es un cambio a lo ya existente, entonces, el Gestor de Nivel de
Servicio realiza los ajustes necesarios al SLA estándar.

8.2 Una vez que se tenga el SLA standard modificado, el documento es enviado para

300
aprobación de las Dirección General, Dirección de Administración y Finanzas y Auditoria.

9. Aprobar el SLA

Dirección General, Dirección de Administración y Finanzas y Auditoria

9.1 Las Direcciones General, Administración y Finanzas y Auditoria son los responsables de
aprobar o rechazar los SLA’s (Estándar o a medida).

9.2 Si alguna de las Direcciones rechaza el SLA, debe indicar las observaciones de su
rechazo.

9.3 El Gestor de Nivel de Servicio debe realizar las modificaciones correspondientes en base
a las observaciones dadas por las Direcciones.

10. Comunicar los cambios realizados en el SLA

Gestor del Nivel de Servicio

10.1 Comunica a todos los interesados en el cumplimiento del SLA (Estándar o a medida),
ya sea internos como externos: Clientes, Servicio de Atención y Satisfacción al Cliente y
Gerencia Comercial.

11. Actualizar OLA

Gestor del Nivel de Servicio

11.1 Actualiza el(los) OLA’s que estuvieran relacionados al SLA aprobado (Estándar o a
medida).

INDICADORES

SGC-R002-IND001 Porcentaje de satisfacción en la percepción del cliente según el SLA.

SGC-R002-IND002 Porcentaje de incumplimiento de SLA

301
SGC-R002-IND003 Porcentaje de incidentes escalados y resueltos en cada nivel de servicio

REGISTROS

TIEMPO DE DISPOSICIÓN
CÓDIGO TITULO RESPONSABLE LUGAR
RETENSIÓN FINAL

SLR – Requerimiento Gestor del Nivel de Oficina Gerencia

SLR-ADEXXX 5 años Triturado
de Nivel de Servicio Servicio de TI

SLA – Acuerdo de Gestor del Nivel de Oficina Gerencia

SLA-ADEXXX 5 años Triturado
Nivel de Servicio Servicio de TI

OLA – Acuerdo de Gestor del Nivel de Oficina Gerencia

OLA-ADEXXX 5 años Triturado
Nivel Operacional Servicio de TI

ANEXOS

SLR (Ver formato base en Anexos 4.2)

SLA (Ver formato base en Anexos 4.3)

OLA (Ver formato base en Anexos 4.4)

302
GESTIÓN DE CAMBIOS
A continuación, se detalla el proceso y modelo base a seguir para la Gestión de Cambios:

CI SGC-R003

PROCESO DE GESTIÓN DEL CAMBIO Versión 1.0

Fecha 17/12/2016

PROCESO DE GESTIÓN DEL CAMBIO

Actualizado a

Diciembre del 2016

303
Contenido:

 OBJETIVO

 ALCANCE

 REFERENCIAS

 DEFINICIONES

 RESPONSABILIDADES

 CONDICIONES GENERALES

 DIAGRAMA DEL PROCESO

 DESARROLLO

 INDICADORES

 REGISTROS

 ANEXOS

ADVERTENCIA: Prohibido reproducir sin la autorización de Auditoría

Página X de Y
Interna

Responsable de
Ítem Versión Fecha Autor Descripción Estado Revisión y/o
Aprobación

01 1.0 17/12/2016 Gisela Versión inicial del proceso. Aprobado Ali Reátegui
Lopez Carlos San
Román

304
OBJETIVO

El presente documento establece las pautas para realizar adecuadamente la Gestión del Cambio
para poder supervisar y aprobar la introducción o modificación de nuevos servicios, siguiendo
los procedimientos establecidos y asegurando en todo momento la calidad y continuidad de los
servicios.

ALCANCE

El presente procedimiento está dirigido a toda el Área de Tecnologías de Información y describe

cómo gestionar convenientemente los cambios de los servicios prestados desde la planificación,
evaluación, pruebas, implementación y documentación de los mismos.

REFERENCIAS

ITIL 2011

DEFINICIONES

 Incidencia: Cualquier evento que no forma parte de la operación estándar de un servicio

y que causa o puede causar una interrupción o una reducción de calidad del mismo.

 Problema: Causa subyacente, aún no identificada, de una serie de incidentes o un

incidente aislado de importancia significativa.

 CAB (Change Advisor Board): Órgano interno compuesto por representantes del área de
TI, la organización, y en algunos casos, también proveedores estratégicos. El CAB se
encarga de aprobar / rechazar una solicitud de cambio, previa evaluación, priorización y
programación de los mismos.

 ECAB (Emergency Change Advisor Board): Órgano interno que toma decisiones

305
 relacionadas con cambios de emergencia cuyo impacto es significativo (naturaleza /
urgencia).

 RFC (Requirement for change): Solicitud formal para la implementación de un cambio.

En el caso de Adecco Perú, éste es registrado como un ticket en el Sistema Service Now.

 Sistema Service Now: Aplicativo web en donde se puede registrar también el RFC para
que internamente se pueda hacer el seguimiento (cambios de estados) correspondiente.

RESPONSABILIDADES

El Gerente de Tecnologías de Información es el responsable de asegurar la correcta aplicación

del presente procedimiento.

CONDICIONES GENERALES

No aplica.

306
DIAGRAMA DEL PROCESO

Figura 57 - Proceso de Gestión del Cambio

Fuente: Elaboración propia

307
DESARROLLO

1. Antecedentes

1.1 La solicitud del cambio ha sido previamente registrada en el Sistema de Service Now.

1.2 La solicitud del cambio puede provenir de los procesos de Gestión de Portafolio de
Servicios, Gestión de Eventos, o Gestión de Problemas.

2. Evaluar y aceptar alcances de RFC

Gestor del cambio

2.1 Evalúa los alcances del RFC, así como se verifica que éste tenga la prioridad correcta.

2.2 Si el RFC cumple con todos los requisitos, es incluido en la lista de solicitudes de
cambio a evaluarse en el CAB semanal y se continúa con la tarea descrita en el paso 3; de
lo contrario se da por concluido el proceso de Gestión del Cambio.

3. Aprobar y planificar el cambio

Gerente de TI / Director General

3.1 Se lleva a cabo el comité semanal del CAB, en donde se expone las RFC’s para
aprobación.

3.2 Una vez que el Gerente de TI y Director General aprueben un cambio, se continúa con
la tarea descrita en el paso 4; de lo contrario se da por concluido el proceso de Gestión del
Cambio.

4. Actualizar cronograma de cambios

Gestor del cambio

4.1 Actualiza el cronograma de cambios para realizar el seguimiento de los mismos.

308
4.2 Si el cambio aprobado requiere gestionar la adquisición de hardware, software o algún
servicio, se envía el RFC al proceso de Gestión de Proveedores; quedándose a la espera una
respuesta para continuar con la tarea descrita en el punto 5.

4.3 Si el cambio aprobado no requiere gestionar ninguna adquisición, se continúa con el

proceso de Gestión de Despliegue y Pruebas.

5. Enviar RFC

Gestor del cambio

5.1 Deriva el RFC al proceso de Gestión de Proveedores cuando el problema requiere

gestionar una adquisición (hardware/software/servicio).

6. Recibir adquisición de hardware, software o servicio

Gestor del cambio

6.1 El proceso de Gestión de Proveedores confirma que se ha procedido con la compra, por
lo que el gestor de problemas recepciona el hardware, software o servicio adquirido para
reenviarlo al proceso de Gestión de Despliegue y Pruebas.

7. Actualizar estado de RFC

Gestor del cambio

7.1 El proceso de Gestión de Gestión de Despliegue y Pruebas confirma si el hardware,

software o servicio ha sido desplegado o cancelado para poder actualizar el estado del RFC
en el Sistema Service Now.

8. Proponer acciones para cambio de emergencia

Gestor del cambio

8.1 Si la solicitud de cambio corresponde a una emergencia, el Gestor de Problemas

propone acciones a ser evaluadas y aprobadas por el ECAB como respuesta inmediata al

309
cambio.

9. Evaluar y aprobar acciones de cambio de emergencia

Gerente de TI

9.1 Evalúa y aprueba las acciones propuestas por el Gestor de Problemas para responder lo
más pronto posible al cambio de emergencia.

9.2 Si el cambio de emergencia aprobado requiere gestionar una compra (hardware,

software o servicio), se envía el RFC al proceso de Gestión de Proveedores; quedándose a
la espera una respuesta para continuar con la tarea descrita en el punto 8.5.

9.3 Si el cambio aprobado no requiere gestionar una compra (hardware, software o

servicio), se continúa con el proceso de Gestión de Despliegue y Pruebas.

INDICADORES

KPI (key performance

Código Descripción
indicator

CM-KPI- Cantidad de cambios defectuosos debido a

Reducción de cambios
01 especificaciones erróneas o gestión de
por defectos
impacto pobre y/o incompleto.

CM-KPI- Tiempo medio transcurrido desde la

Reducción de tiempo
03 solicitud de una RFC (Solicitud de Cambio)
para autorización para
a la Gestión de Cambios hasta la
cambios
autorización para el cambio

310
 CM-KPI- Ratio de aceptación de
Cantidad de RFC's aceptadas vs. rechazadas
04 cambios

CM-KPI- Cantidad de cambios urgentes evaluados por

Reducción de cantidad
05 el ECAB (Consejo Consultor para Cambios
de cambios urgentes
de Emergencia)

REGISTROS

TIEMPO DE DISPOSICIÓN
CÓDIGO TITULO RESPONSABLE LUGAR
RETENSIÓN FINAL

INC000 Sistema Carlos

1 hora Arequipa Resuelto
1 Service Now Mimbela

RFC

ANEXOS

No aplica.

311
GESTIÓN DE ACTIVOS Y GESTIÓN DE LA
CONFIGURACIÓN
A continuación, se detalla el proceso y modelo base a seguir para la Gestión de Activos del
Servicio y Gestión de la Configuración:

CI SGC-R004
PROCESO DE GESTIÓN DE ACTIVOS DEL
SERVICIO Y GESTIÓN DE LA Versión 1.0
CONFIGURACIÓN
Fecha 18/12/2016

PROCESO DE GESTIÓN DE ACTIVOS DEL SERVICIO Y GESTIÓN DE LA

CONFIGURACIÓN

Actualizado a

Diciembre del 2016

312
Contenido

 OBJETIVO

 ALCANCE

 REFERENCIAS

 DEFINICIONES

 RESPONSABILIDADES

 CONDICIONES GENERALES

 DIAGRAMA DEL PROCESO

 DESARROLLO

 INDICADORES

 REGISTROS

ADVERTENCIA: Prohibido reproducir sin la autorización de Auditoría

Página X de Y
Interna

Responsable de
Ítem Versión Fecha Autor Descripción Estado Revisión y/o
Aprobación

313
 01 1.0 18/12/2016 Gisela Versión Aprobado Ali Reátegui Carlos
Lopez inicial del San Román
proceso.

OBJETIVO

El presente documento establece las pautas para realizar adecuadamente la Gestión de la

Configuración y Activos de TI de Adecco Perú, llevando un registro actualizado de todos los
elementos de configuración de la infraestructura de TI junto con sus interrelaciones.

ALCANCE

El presente procedimiento está dirigido a toda el Área de Tecnologías de Información y

describe como obtener el máximo provecho del detalle de la infraestructura de TI, brindando
información precisa y fiable para servir de apoyo a otros procesos como Gestión de
Incidencias, de Problemas y de Cambios.

REFERENCIAS

ITIL 2011.

DEFINICIONES

 CI (Configuration Item): Un Elemento de Configuración es todo activo, servicio,

componente de servicio o cualquier ítem que es o está bajo el control de la Gestión
de la Configuración.

 CMDB (Configuration Management Database): La Base de Datos de la Gestión de la

Configuración contiene la información detallada de cada CI y sus diferentes
interrelaciones o interdependencias tanto físicas como lógicas con otras CI’s.

314
RESPONSABILIDADES

El Gerente de Tecnologías de Información es el responsable de asegurar la correcta

aplicación del presente procedimiento.

CONDICIONES GENERALES

No aplica.

315
DIAGRAMA DEL PROCESO

Figura 58 - Proceso de Gestión de Activos de Servicio y Gestión de la Configuración

Fuente: Elaboración Propia

DESARROLLO

1. Antecedentes

Especialista de Infraestructura

1.1 Realiza este proceso de forma quincenal, para mantener actualizada la CMDB ante
cambios o mejoras en la infraestructura del área de TI.

1.2 Los procesos relacionados como input: Gestión del Cambio (RFC).

2. Identificar HW / SW y Servicios de TI

316
Especialista de Infraestructura

2.1 En base a la información generada por la aplicación de Inventarios (Service Now –

Inventory Managment), se identifican los cambios o nuevas adiciones de Hardware /
Software dentro de la infraestructura de TI.

2.2 En cuanto a los Servicios, se toma como referencia el RFC.

3. Clasificar CI’s

Especialista de Infraestructura

3.1. Clasifica el HW / SW y Servicios de TI para poder determinar su criticidad y definirlos

como CI’s.

3.2 Si el cambio o mejora en la infraestructura del área de TI no está considerado o

asociado a un CI, se da por concluido el proceso.

4. Actualizar el Listado de CI’s

Especialista de Infraestructura

4.1 Actualiza el Listado de CI’s, donde se incluyen sus atributos o características:

Fabricante, Fecha de Compra, Estado, Ubicación, Sistema Operativo, Versión, etc. Para el
caso de HW /SW, la información puede obtenerse de la aplicación de Inventarios (Service
Now – Inventory Managment).

4.2 También se deben considerar los tipos de relaciones lógicas y físicas entre CI’s o
subcomponentes registrados independientemente.

5. Actualizar el Diagrama de Infraestructura de TI

Especialista de Infraestructura

5.1 Actualiza el Diagrama de Infraestructura de TI en base a las relaciones establecidas en

el Listado de CI’s.

317
5.2 El Diagrama de Infraestructura de TI es enviada al Jefe de Infraestructura para su
validación.

6. Validar el Diagrama de Infraestructura de TI

Jefe de Infraestructura

6.1 Si el Diagrama de Infraestructura de TI es válido, se actualiza el documento en la

CMDB; de lo contrario es devuelto al Especialista de Infraestructura con los motivos del
rechazo, regresándose a la tarea mencionada en el punto 5.

7. Monitorizar y Controlar los estados de los CI’s

Especialista de Infraestructura

7.1 Monitoriza y controla los estados de los CI’s a través de la herramienta Nagios.

7.2 En el caso de que se haya realizado una baja, adición o cambio en los CI’s, estos
deberán actualizarse en la herramienta de monitoreo.

7.3 Cuando se tenga una alerta en la herramienta Nagios, debe informarse a los procesos de
Gestión de la Capacidad o Gestión de la Disponibilidad.

INDICADORES

 SGC-R004-IND001 Incremento en la reutilización y redistribución de recursos y

activos poco usados

 SGC-R004-IND002 Mejorar los tiempos de ejecución del mantenimiento de los

ítems de configuración

 SGC-R004-IND003 Mejorar el radio de licencias empleadas vs licencias adquiridas

 SGC-R004-IND004 Mejorar el radio de software instalado vs software autorizado

318
REGISTROS

TIEMPO DE DISPOSICIÓN
CÓDIGO TITULO RESPONSABLE LUGAR
RETENSIÓN FINAL

Especialista de
Listado de CI’s 5 años Gerencia de TI Triturado
Infraestructura

RFC

319
GESTIÓN DE INCIDENTES
A continuación, se detalla el proceso y modelo base a seguir para la Gestión de Incidentes:

CI SGC-R005

PROCESO DE GESTIÓN DE INCIDENTES Versión 1.0

Fecha 19/12/2016

PROCESO DE GESTIÓN DE INCIDENTES

Actualizado a

Diciembre del 2016

320
Contenido:

 OBJETIVO

 ALCANCE

 REFERENCIAS

 DEFINICIONES

 RESPONSABILIDADES

 CONDICIONES GENERALES

 DIAGRAMA DEL PROCESO

 DESARROLLO

 INDICADORES

 REGISTROS

 ANEXOS

ADVERTENCIA: Prohibido reproducir sin la autorización de Auditoría

Página X de Y
Interna

HISTORIAL DE LAS REVISIONES

Responsable de Revisión
Ítem Versión Fecha Autor Descripción Estado
y/o Aprobación

01 1.0 19/12/2016 Gisela Versión Aprobado Ali Reátegui Carlos San

inicial del

321
 Lopez proceso. Román

OBJETIVO

El presente documento establece las pautas para realizar adecuadamente la Gestión de

Incidentes para poder resolver, de la manera más rápida y eficaz posible, cualquier incidente
que cause una interrupción en los servicios en Adecco Perú.

ALCANCE

El presente procedimiento está dirigido a toda el Área de Tecnologías de Información y

describe como restaurar los servicios para cumplir con los niveles de servicios acordados
(SLAs, OLAs) mejorando así la satisfacción general de sus clientes y usuarios.

REFERENCIAS

ITIL 2011.

DEFINICIONES

 Evento: Todo suceso detectable que tiene importancia para la estructura de la

organización de TI, para la prestación de un servicio o para la evaluación del mismo.

 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.

 Excepción: Tipo de evento que indica que un servicio está operando de manera

322
 irregular y puede representar un fallo total, un cese de funcionalidad o una
disminución del rendimiento.

 KEDB (Known Error Data Base): Base de datos de errores conocidos.

 FAQ (Frequently Asked Questions): Listado de preguntas y respuestas de uso

frecuente respecto a un tema en particular.

 RFC (Requirement for change): Solicitud formal para la implementación de un

cambio. En el caso de Adecco Perú, éste será registrado como un ticket en el Sistema
de Gestión de Tickets (Service Now).

 Sistema de Gestión de Tickets: Aplicativo web en donde se puede registrar también

el RFC para que internamente se pueda hacer el seguimiento (cambios de estados)
correspondiente.

RESPONSABILIDADES

El Gerente de Tecnologías de Información es el responsable de asegurar la correcta

aplicación del presente procedimiento.

CONDICIONES GENERALES

No aplica.

323
DIAGRAMA DEL PROCESO

Figura 59 - Proceso de Gestión de Incidentes

Fuente: Elaboración Propia

324
DESARROLLO

1. Antecedentes

1.1 El incidente ha sido previamente registrado en el Sistema de Gestión de Tickets (Service

Now).

1.2 Se considera como cliente, tanto a los usuarios internos como a los clientes externos, a
los cuales se les brinda servicios.

2. Evaluar incidente

Soporte nivel 1

2.1 Evalúa el incidente y verifica que éste tenga la categoría o prioridad correcta en el
Sistema de Gestión de Tickets.

2.2 En el caso de que la categoría o prioridad del incidente tenga que ser modificada, se
procede con la tarea descrita en el punto 3, de lo contrario, continúa con la tarea descrita en el
punto 4.

3. Actualizar Ticket de incidente

Soporte nivel 1

3.1 Actualiza la categoría o prioridad del incidente en el Sistema de Gestión de Tickets.

4. Realizar diagnóstico inicial del incidente

Soporte nivel 1

4.1 Realiza el diagnóstico inicial del incidente, identificando las posibles causas y
determinando las posibles acciones para solucionarlo en el más breve plazo.

4.2 Si para la solución del incidente es necesario solicitar el apoyo de un especialista técnico
(soporte nivel 2), se continua con la tarea descrita en el punto 9, de lo contrario, continúa con

325
la tarea descrita en el punto 6.

4.3 En el caso de que el incidente esté afectando a aplicaciones críticas para clientes externos
y/o internos, y el restablecimiento de los mismos no es automático, se procede con la tarea
intermedia descrita en el punto 5.

5. Comunicar el incidente a clientes externos / internos

Soporte nivel 1

5.1 Comunica el incidente a los clientes externos y/o internos, teniéndose las siguientes
alternativas:

a) Si se trata de un incidente que afecta a todos los clientes externos, se coordina con la
Jefatura del Service Desk para que se envíe un comunicado vía correo electrónico, a la lista
de distribución correspondiente, informando sobre el incidente.

b) Si se trata de un incidente que afecta a los clientes internos, se comunica el incidente a los
usuarios ya sea por correo electrónico, llamada telefónica o personalmente.

5.2 Finalmente, proceda con la tarea descrita en el punto 6 o 9.

6. Ejecutar pasos de solución de incidente

Soporte nivel 1

6.1 Ejecuta los pasos de solución del incidente consultando el FAQ correspondiente en el
KEDB.

6.2 Si se trata de un incidente repetitivo o la solución brindada no es la definitiva, se deriva el

incidente al proceso de Gestión de Problemas, de lo contrario, continúa con la tarea descrita
en el punto 7.

7. Cerrar ticket de incidente

Soporte nivel 1

326
7.1 Ingresa al Sistema de Gestión de Tickets y actualiza el estado del ticket del incidente a
“Cierre”, para así dar por terminado el proceso de Gestión de Incidentes.

7.2 En el caso de que el incidente haya afectado a aplicaciones críticas para clientes externos
y/o internos, se procede con la tarea descrita en el punto 8.

8. Comunicar la solución del incidente a clientes externos / internos

Soporte nivel 1

8.1 Comunica la solución del incidente a los clientes externos y/o internos, teniéndose las
siguientes alternativas:

a) Si se trata de un incidente que afectó a todos los clientes externos, se coordina nuevamente
con la Jefatura del Service Desk para que se envíe un comunicado vía correo electrónico, a la
lista de distribución correspondiente, informando que el incidente ha sido resuelto.

b) Si se trata de un incidente que afectó a los clientes internos, se comunica a los usuarios
que el incidente ha sido resuelto, ya sea por correo electrónico, llamada telefónica o
personalmente.

9. Actualizar ticket con acciones iniciales

Soporte nivel 1

9.1 Actualiza el ticket del incidente ingresando al Sistema de Gestión de Tickets, y

documenta las primeras acciones realizadas, en base al diagnóstico inicial y que no surgieron
efecto para la solución.

10. Realizar diagnóstico técnico del incidente

Soporte nivel 2

10.1 Realiza el diagnóstico técnico del incidente, identificando las posibles causas y
determinando las posibles acciones de solución, teniendo como referencia las primeras
acciones realizadas por el Soporte nivel 1.

327
10.2 Si una vez realizado el diagnóstico, se determina que el incidente es un problema, se
procede con la tarea descrita en el punto 11.

10.3 Si para la solución del incidente es necesario solicitar el apoyo o depende del proveedor
de servicios (telecomunicaciones, desarrollo de software, etc.), se está al pendiente de una
respuesta antes de continuar con la tarea descrita en el punto 12.

11. Actualizar ticket con acciones técnicas

Soporte nivel 2

11.1 Actualiza el ticket del incidente ingresando al Sistema de Gestión de Tickets, y

documenta las acciones técnicas realizadas y que no surgieron efecto para la solución, siendo
el incidente derivado al proceso de Gestión de Problemas.

12. Ejecutar pasos de solución de incidente

Soporte nivel 2

12.1 Ejecuta los pasos de solución del incidente, los mismos que puede estar determinados o
sujetos al proveedor de servicios (telecomunicaciones, desarrollo de software, etc.).

13. Documentar solución de incidente

Soporte nivel 2

13.1 Documenta los pasos de solución del incidente como FAQ para que sea archivado en el
KEDB.

13.2 Si se trata de un incidente repetitivo o la solución brindada no es la definitiva, se deriva

el incidente al proceso de Gestión de Problemas, de lo contrario, continúa con la tarea
descrita en el punto 7.

INDICADORES

SGC-R005-IND001 Número de incidentes resueltos fuera del tiempo de resolución

328
SGC-R005-IND002 Resultados de encuestas de satisfacción en porcentajes (respuestas x
pregunta)

SGC-R005-IND003 Número de encuestas de satisfacción respondidas vs. enviadas

SGC-R005-IND004 Número de incidentes procesados por Soporte nivel 1 y 2

REGISTROS

Tiempo de
Código Título Responsable Lugar Disposición Final
Retensión

Sistema de Gestión
de Tickets (Service
Now)

RFC

ANEXOS

No aplica.

329
CONCLUSIONES

Como conclusión se declara la necesidad de implementar una gestión para los servicios de
tecnología de información con el propósito de asegurar la continuidad del proceso de
“compras” y la disponibilidad de bases de datos, aplicaciones e infraestructura de tecnología
de la compañía Adecco Perú S.A. Para satisfacer esta necesidad se propone una solución que
genera valor al proceso con el propósito de permitirle cumplir los objetivos estratégicos
impactados directamente desde el proceso de compras.

La propuesta de implementación de procesos para la gestión de servicios en tecnologías de la

información se apoya en el resultado de las evaluaciones estratégicas de negocio y de TI para
presentar una solución que sigue una planificación estratégica, diseño y transición de
servicios de los procesos ITIL para su implementación.

Para una prolija implementación de ITIL se propone automatizar los servicios, así de esta
manera se agilizaría la implementación con el uso de herramientas adaptables claramente a
las necesidades de la compañía Adecco Perú con el propósito de responder en los tiempos
razonables que demanda el cliente.

Finalmente, ITIL como marco de referencia para los procesos operativos, carente de una
metodología de adopción o implementación, agiliza su adopción, pero es necesario e
importante identificar el tamaño real de la adopción de ITIL. Así como las consideraciones a
tener en cuenta para elegir una métrica o unidad de trabajo estandarizada para medir el
esfuerzo de su implementación, las unidades de trabajo serían los servicios que se diseñaron
como propuesta para la adopción de ITIL.

330
CAPÍTULO 5: ESTRUCTURA PROPUESTA

INTRODUCCIÓN

Este capítulo presenta una propuesta de arquitectura empresarial estructurada e integrada para
Adecco Perú S.A. que reúne los resultados de los capítulos previos y así permitir a la
organización alinearse a sus objetivos estratégicos. Desde el área de compras, se establece
este propósito que asegura el cumplimiento del objetivo general y los específicos constituidos
para este proyecto.

Cumplir con cada uno de los objetivos específicos permite garantizar, que, mediante las
iniciativas de una solución de software, se logre el cierre de brechas que evitan el
cumplimiento de las estrategias de negocio. La propuesta para el desarrollo de software se
apoya en el marco de trabajo Scrum para conseguir agilidad en el flujo de trabajo de los
entregables resultantes y desarrollo de habilidades del equipo de proyecto que la organización
demanda.

La gestión de servicios en TI, por su parte, se apoya en las mejores prácticas de ITIL para
soportar los servicios de implementación del producto software.

Finalmente, se incluye la evaluación de riesgos asociados a la propuesta para poder

controlarlos y la justificación de la viabilidad financiera con el análisis de rentabilidad que la
organización exige.

331
ESTRUCTURA PROPUESTA

Con el propósito de asegurar la trazabilidad entre el cumplimiento de los objetivos

estratégicos de Adecco Perú S.A., las soluciones de software propuestas para el cierre de
brechas resultantes de la Arquitectura Empresarial y el soporte que brinda la gestión de
servicios en TI, se plantea el mapa trazable que permita otorgar visibilidad en la integración
de la necesidad con los resultados obtenidos en cada uno de los capítulos precedentes, esto
para asegurar la aceptación de la propuesta con el cumplimiento de los objetivos general y
específicos declarados en este proyecto.

TRAZABILIZAD PARA LA PROPUESTA

A continuación, se presenta la integración trazable de la propuesta:

332
Figura 60 - Mapa de Trazabilidad
Fuente: Elaboración Propia

333
DESCRIPCIÓN DEL MAPA DE TRAZABILIDAD

Adecco Perú S.A. establece un conjunto de objetivos estratégicos con miras a su alineación
con la estrategia corporativa. El análisis resultante del desarrollo de la Arquitectura
Empresarial, desde el Proceso de Compras, identifica las brechas que impactan directamente
a los siguientes objetivos estratégicos:

OE1: Optimizar los procesos de servicios, mejorando la calidad y distribución de estos a

través de la aplicación de mejoras al SGC y el cumplimiento de los indicadores actuales.

OE2: Facilitar la disposición de mejores herramientas a los colaboradores para crear una
cultura empresarial ágil, sostenible y responsable, incrementando la inversión en estos
medios en un 45%.

OE3: Consolidar las nuevas líneas de negocio al interior del país de manera sostenible,
incrementando la cobertura actual en un 30%.

Se observa que la organización ha trazado metas porcentuales en 2 objetivos para asegurar el

cumplimiento de los mismos. Este cumplimiento debe ser alcanzado por todas las unidades
organizacionales y las iniciativas de mejora que se propongan en Adecco Perú. La presente
propuesta sobre el proceso de compras busca aportar al cumplimiento de dichas metas.

. En el mapa trazable se podrá observar la siguiente relación:

Objetivo Estratégico Brecha Identificada Definición del Solución propuesta

(OE) (GAP) problema (PB) (SOL)

334
Esta relación asegura el cierre de las brechas identificadas (GAP001...GAP008) con las
soluciones propuestas (SOL1…SOL8) y con la alineación a los objetivos estratégicos que el
negocio exige.

Las brechas identificadas en la arquitectura de tecnología (GAP007, GAP008) no permiten el

cumplimiento de los objetivos estratégicos (OE1, OE2 y OE3) por los problemas (PB7, PB8)
que requieren cerrarse con las soluciones definidas como (SOL7, SOL8) a partir de la
atención de un RFC generado en el ServiceNow (implementado sobre la base de ITIL).

La propuesta de Arquitectura Empresarial orienta las decisiones que toma actualmente TI

hacia las necesidades del negocio. En este sentido, el MAPA DE TRAZABILIZAD muestra
las brechas (GAP001…GAP006) cuyo cierre se propone estableciendo las soluciones
(SOL1...SOL6) soportada por un producto software (AP) que se apoya en Scrum como
respuesta a la orientación requerida. La solución de software es concebida como una
plataforma para la gestión de compras (AP) cuya implementación se cubre en la definición de
los Sprints (Sprint1...Sprint 4) como parte de la aplicación del marco de trabajo Scrum y cuya
aplicación oriente la implementación de las soluciones identificadas a los problemas
declarados (PB1...PB6).

El mapa también plantea como soporte, la aplicación de las mejores prácticas de ITIL, que, a
través de las acciones definidas para la gestión de servicios, determina una mejor propuesta
con este soporte. Bajo esta consideración se establecieron los servicios internos identificados
(SI1, SI2) que responden a la implementación de la solución y cuya correcta gestión en
conjunto con los servicios de soporte (SS1…SS4) aseguran la mejora continua. El
crecimiento de funciones, dificultades e importancia que se brinda, hace necesario que el área
de TI de Adecco Perú se convierta en un proveedor de servicios de TI de correcta gestión,
enfocado en el negocio, cliente, los procesos y en la tecnología; con la definición de acuerdos
de niveles de servicios. Todo esto trae consigo una serie de beneficios como el incremento de
la calidad de los servicios, la normalización de procesos y la satisfacción del cliente, entre
otros.

335
Explicados los campos sobre los que gira el mapa trazable, de manera complementaria se
define la siguiente tabla (ver tabla 50) que refuerza el aseguramiento de la trazabilidad y que
está basado en responder las siguientes cuestiones:

¿Cuál es el problema?  Para definir con exactitud el problema relacionado a la brecha

identificada.

¿A qué objetivo estratégico impacta?  Para reconocer el impacto directo que tiene la brecha
sobre el objetivo respectivo.

¿Por qué existe la brecha?  Para explicar el problema, los impedimentos y demás
condiciones que nos permiten llegar a la situación esperada (TO BE).

¿Cuál es la solución?  Para definir la solución que aporta al cierre de la brecha.

¿Cómo abordamos la solución?  Para identificar los procesos, funcionalidades y

operaciones tecnológicas que debemos ejecutar para el cierre de cada una de las brechas.

336
Brecha identificada ¿Cuál es el problema? ¿A que objetivo estratégico impacta? ¿Porque existe la brecha? ¿Cuál es la solución? ¿Como abordamos la solución?

Porque no permite al proceso de compras ser óptimo en la atención al

OE1: Optimizar los procesos de servicios,
servicio requerido por los clientes impidiendo gestionar correctamente las Disponer de funcionalidad para Generando funcionalidades como
mejorando la calidad y distribución el manejo de contratos “Proceso de negociación de
operaciones relacionadas con los proveedores.
negociados con proveedores contratos con proveedores”, "Flujo
OE2: Facilitar la disposición de mejores
Búsqueda de Porque genera sobreesfuerzo a los colaboradores para la evaluación y que permita realizar una de generación de órdenes por
Tratamiento de herramientas a los colaboradores para crear
proveedores es extensa decisión de compra. selección y evaluación rápida, precios negociados", "Flujo de
Proveedores una cultura empresarial ágil
y manual disminuya el sobreesfuerzo de generación de órdenes de pago
Porque la evaluación y decisión de compra se prolonga más de lo los compradores y permita para regularizaciones de compra"
OE3: Consolidar las nuevas líneas de negocio necesario, y hoy el negocio define una estrategia de consolidación al agilizar el proceso global de planteados en los Sprint 2 y 3
al interior del país de manera sostenible interior del país, lo que demanda una mejor atención del servicio en las compras. propuestos.
locaciones alejadas.
Porque no permite al proceso de compras calificar como óptimo
OE1: Optimizar los procesos de servicios,
impidiendo al servicio realizar un correcto seguimiento y notificación a las Generando funcionalidades como
mejorando la calidad y distribución
aprobaciones requeridas. “Notificaciones y controles de
Disponer de funcionalidad que
aprobación por montos”, "Alertas
Notificaciones manuales OE2: Facilitar la disposición de mejores Porque las acciones de notificación y aprobación son informales y muchas facilite poder contar con
Manejo de y seguimiento de ordenes de
para aprobaciones de las herramientas a los colaboradores para crear veces no trazables dificultando el desarrollo regular del proceso y notificaciones a todo nivel y
Notificaciones compra y pago" y "Monitoreo de
órdenes de compra una cultura empresarial ágil exigiendo un esfuerzo adicional para cumplir con las politicas de compra. otorgar los niveles de solicitudes y ordenes atendidas"
aprobación requerido.
planteadas en los Sprint 2 y 4
OE3: Consolidar las nuevas líneas de negocio Porque impacta en la continuidad ágil del flujo de compras impactando en planteados.
al interior del país de manera sostenible la entrega del servicio al interior del país.

Porque no le permite al proceso de compras calificar como óptimo

OE1: Optimizar los procesos de servicios,
restando agilidad a las aprobaciones por el manejo excesivo de
mejorando la calidad y distribución
documentación para evaluar los sustentos de aprobación. Disponer de información
Exceso de
centralizada y digitalizada de la
Disponibilidad de documentación física OE2: Facilitar la disposición de mejores Porque se continua manejando exceso de evidencia física propensa a Generando la opción de
documentación para facilitar
información para para los sustentos de herramientas a los colaboradores para crear deterioro o pérdida afectando al comprador o al aprobador que debe “Digitalización de Documentos” a
su acceso y agilizar las
aprobaciones aprobación de órdenes una cultura empresarial ágil brindar su aprobación evaluada. implementar en el Sprint 2.
aprobaciones de órdenes de
de compra
compra
OE3: Consolidar las nuevas líneas de negocio Porque continua exigiendose la evidencia física, incluso en operaciones
al interior del país de manera sostenible lejanas al interior del país dilatando las regularizaciones y aprobaciones.

Porque no se cuenta con un diccionario de datos y documentación que Implementando una plataforma de
Esquema Alto costo en cambios al
OE1: Optimizar los procesos de servicios, facilite proponer mejoras al modelo actual y que en su defecto, los cambios Implementar un modelo de gestión de compras que soporte las
personalizable para modelo de datos por su
mejorando la calidad y distribución considerados, demandan un alto costo por los servicios profesionales datos flexible y mantenible opciones identificadas y se base en
Gestión de Compras poca flexibilidad
requeridos. el modelo propuesto.

337
 Brecha identificada ¿Cuál es el problema? ¿A que objetivo estratégico impacta? ¿Porque existe la brecha? ¿Cuál es la solución? ¿Como abordamos la solución?

OE1: Optimizar los procesos de servicios, Por no alcanzar la optimización deseada que involucra cambios pero estos
mejorando la calidad y distribución serían limitados por el presupuesto con la que se cuenta. Analizando, planificando y
Alto costo por parte del OE2: Facilitar la disposición de mejores Porque el elevado costo de los servicios profesionales del proveedor actual Ejecutar cambios mínimos y ejecutando los cambios mínimos
Cambios en el proveedor para cambios herramientas a los colaboradores para crear del proveedor impiden planificar la implementación de mejoras a la puntuales al ERP actual para requeridos para llevar a cabo las
módulo de compras funcionales en el ERP una cultura empresarial ágil solución actual. llevar a cabo las mejoras mejoras funcionales identificadas
actual propuestas en una nueva implementación
OE3: Consolidar las nuevas líneas de negocio Porque no se puede sostener el crecimiento requerido sin mejorar el ERP soportada por la versión actual.
al interior del país de manera sostenible actual

OE1: Optimizar los procesos de servicios, Porque no se pueden aplicar cambios a los flujos actuales contando con un Generando funcionalidades como
mejorando la calidad y distribución mínimo nivel de configuración impidiendo agilizar las aprobaciones. “Configuración de nodos para
solicitantes y aprobadores”, "Flujo
Limitaciones de OE2: Facilitar la disposición de mejores Porque no se facilita la labor con la disponibilidad de realizar cambios que
Permitir establecer flujos de generación de órdenes de
configuración en el ERP herramientas a los colaboradores para crear se identifiquen en los flujos y se apliquen de manera ágil en la solución
Configuración en el configurables para solicitudes compra", "Flujo de generación de
para establecer flujos de una cultura empresarial ágil actual.
módulo de compras y aprobaciones de órdenes de órdenes de pago", "Flujo de
trabajo para las
compra por montos generación de órdenes de pago
aprobaciones
OE3: Consolidar las nuevas líneas de negocio Porque tambien impacta a la rapidez con la que se debe entregar la para regularizaciones de compra"
al interior del país de manera sostenible demanda de productos y servicios generando malestar a los clientes. planteados en los Sprint 1, 2 y 3
propuestos.

OE1: Optimizar los procesos de servicios, Porque la limitante tecnológica existente no da cabida a contemplar
Planificando las tareas de
mejorando la calidad y distribución optimización y mejoras.
migración tecnológica requerida,
OE2: Facilitar la disposición de mejores Porque la limitante tecnológica no permite contemplar otorgar contemplando una homologación
Limitaciones de Imposibilidad de
herramientas a los colaboradores para crear consideraciones multiplaforma o consideraciones mobile para facilitar la Migrar la versión del con lo que actualmente se dispone
software del servidor desplegar una solución
una cultura empresarial ágil labor actual del proceso de compras. framework del servidor IIS de con sustento en la propuesta de
de aplicaciones web con característica
v3.0 a v7.0 mejora esperada y requiriendo un
IIS multiplataforma
Porque la limitante tecnológica no permite expander las capacidades de la cambio a través de la gestión de
OE3: Consolidar las nuevas líneas de negocio
solución actual permitiendo fortalecer el servicio que se otorga a los servicio TI para su canalización
al interior del país de manera sostenible
clientes. correspondiente.

OE1: Optimizar los procesos de servicios, Porque plantear optimizar el proceso demanda cambios funcionales que
mejorando la calidad y distribución exigen a la plataforma de hardware actual un crecimiento en recursos. Analizando los recursos en
hardware necesarios para aplicar
Actualizar la capacidad de
Limitaciones de Recursos insuficientes OE2: Facilitar la disposición de mejores cambios con sustento en la
Porque la situación actual del hardware productivo limita planificar la hardware de los servidores
infraestructura de para alojar nuevas herramientas a los colaboradores para crear propuesta de mejora planteada y
implementación de mejores herramientas. virtuales para soportar nuevas
servidores soluciones una cultura empresarial ágil requiriendo un cambio a través de
iniciativas de mejora
la gestión de servicio TI para su
OE3: Consolidar las nuevas líneas de negocio Porque para sostener el crecimiento requerido y mejora del servicio al canalización correspondiente.
al interior del país de manera sostenible interior del país se necesita crecer en infraestructura.

Tabla 53 - Tabla detalle de trazabilidad

Fuente: Elaboración Propia

338
EVALUACION DE RIESGOS
Esta evaluación de riesgos propone identificar y mitigar los riesgos en el entorno de la
propuesta, así como la valoración de la urgencia para actuar sobre ellos.

339
340
Tabla 54 - Matriz de Riesgos de la propuesta
Fuente: Elaboración propia

341
ANÁLISIS DE RENTABILIDAD

Esta propuesta necesita respaldarse en una evaluación de rentabilidad positiva que permite
tomar decisión al negocio, por esta razón se establece a continuación la viabilidad económica,
donde, a través de los resultados obtenidos del cálculo de la TIR y el VAN, se puede asegurar
que la rentabilidad resultante de la ejecución del proyecto se garantiza. En este sentido, se
obtuvieron los siguientes resultados del análisis financiero en un horizonte de 5 años. Este
periodo de tiempo se da, puesto que la política financiera de Adecco Perú S A. establece para
el año 2017, que todo proyecto de inversión superior a $ 230,000.00, debe generar
rentabilidad a partir del 5to año

VAN= US$ 94,691.63 > 0; El proyecto es rentable.

TIR=36.56%; es la tasa de rentabilidad obtenida.

Analizando todo el periodo de tiempo indicado se tiene:

Figura 61 - Gráficos de progreso VAN y TIR

Fuente : Elaboración Propia

342
Del gráfico “Análisis de la TIR” podemos concluir que la TIR supera a la tasa de descuento
establecida (20%) a partir del 4to año.

Del gráfico “Análisis del VAN” podemos concluir que en Valor Actual Neto es positivo a
partir del 4to año.

343
Con los parámetros establecidos dentro de todo el horizonte requerido se puede interpretar:

Tasa descuento 20.00%

Inversión inicial 235,041.26

Flujo
Años efectivo VAN TIR Interpretación de resultados

1 117340.76 -137,257.30 -50.08% Se rechaza invertir, porque el VAN es negativo y la TIR también es negativa

2 93472.22 -72,346.03 -7.22% Se rechaza invertir, porque el VAN es negativo y la TIR también es negativa

Se rechaza invertir, porque el VAN es negativo y la TIR es menor a la tasa de

74910.26 -28,995.19 11.35%
3 descuento

Si conviene invertir, porque el VAN es positivo y la TIR es superior a la tasa de

136670.20 36,914.44 28.08%
4 descuento

Si conviene invertir, porque el VAN es positivo y la TIR es superior a la tasa de

143768.14 94,691.63 36.56%
5 descuento

Tabla 55 - Tabla de interpretación VAN y TIR

Fuente : Elaboración Propia

Para determinar el momento exacto en que el proyecto de inversión se vuelve rentable,

analizamos el punto de equilibrio sobre el flujo acumulado:

344
 Figura 62 - Gráfico del Punto de Equilibrio
Fuente: Elaboración Propia

Se establece que el punto de equilibrio es igual a 0 (Cero) y donde se interpreta que los
ingresos generados son iguales a los egresos contemplados y determinar el momento donde el
proyecto de inversión comienza a generar rentabilidad. En este caso, se determina que dentro
del periodo del 2do y 3er año el proyecto de inversión genera la rentabilidad esperada.

Este análisis justifica la inversión en la PROPUESTA DE UNA ARQUITECTURA

EMPRESARIAL PARA LA EMPRESA ADECCO PERU S.A. al demostrar que existe una
TIR de 28.08% a partir de una inversión de $ 235,041.26 y al obtener un VAN de $
36,914.44 para así demostrar que el dinero invertido se recupera e incluso se obtiene
rentabilidad sobre este, dentro del cuarto año con el uso de una tasa de descuento de 20%.
También se demuestra que este tiempo de inversión (4 años) supera las expectativas
establecidas por el negocio (5 años).

345
CONCLUSIONES DE LA PROPUESTA

Asegurar la trazabilidad, en la presente propuesta, permite conocer la ubicación de los

elementos resultantes de cada análisis realizado y la trayectoria que la organización debe
seguir obligatoriamente para cumplir con los objetivos de la propuesta y completar
exitosamente el alineamiento a la estrategia de negocio requerida. Esquematizar la propuesta
otorga una mejor visibilidad de dicha trazabilidad para enfocar la obtención de los resultados.

Los proyectos tecnológicos demandan soporte de una adecuada evaluación financiera y de

rentabilidad. Estos no son vistos simplemente como proyectos de TI sino ampliando el
concepto, como proyectos de inversión que deben garantizar un retorno sobre la inversión
que el negocio está dispuesto a asumir. Los indicadores y niveles establecidos para este tipo
de evaluaciones deben otorgar una visión general de la viabilidad del proyecto, si estos no
son los esperados, simplemente no existe base que soporte el sustento de su ejecución.

346
CONCLUSIONES

A partir de la aplicación de Arquitectura Empresarial con el uso del marco TOGAF, se

reconocieron las bondades de esta metodología, que en combinación con el amplio
conocimiento del proceso de compras, del objeto de estudio y sus lineamientos con el proceso
de TI, se declara la necesidad de la capacidad a plenitud y el involucramiento de las personas
idóneas identificadas en este proyecto para aprovechar las ventajas de la AE y así evitar las
altas probabilidades de fracasar durante su ejecución y la posibilidad de obtener resultados
apropiados para la solución de los problemas reales.

La dinámica para la identificación de brechas, la definición de los problemas y las propuestas

de solución, confluyen en la necesidad de desarrollar un ROADMAP de producto software
como propuesta, amparada en la investigación de metodologías, herramientas y buenas
prácticas. De esta manera, se demuestra que esta debe ser la forma en que toda organización
debe establecer una visión a largo plazo, apalancando con medios tecnológicos la estrategia
de negocio que se defina. Para Adecco Perú S.A. sin duda alguna, esta primera experiencia
debe ser la base de aplicación futura para la puesta en marcha de iniciativas de mejora en la
organización.

En síntesis, para la organización objetivo, es indispensable responder al TIME TO MARKET

y el dinamismo que exige el mercado actual, especialmente para hacer frente a la
competencia existente y sostener su crecimiento al interior del país. Ante esto, la adopción de
metodologías de trabajo, como SCRUM, se orientan a mejorar la flexibilidad ante cambios
con incertidumbre y obtener resultados rápidos alineados a la estrategia, para permitir obtener
una capacidad de reacción y mantener la ventaja competitiva que espera obtener Adecco Perú
S.A. en el mercado.

347
Finalizado el análisis para la gestión de los servicios en TI, se concluye que ITIL contiene las
mejoras prácticas que brinda beneficios y por consiguiente aplica un cambio de mentalidad
para los colaboradores de la organización. Este cambio de mentalidad pasa por reconocer
ahora al área de TI de Adecco como una proveedora de servicios y no como una “entidad de
soporte tecnológico” como se venía considerando. Con la definición de un catálogo de
servicios brindado por TI, está tendrá que responder adecuadamente a la exigencia que
demanda el servicio de gestión de compras y no escatimar en conseguir los recursos
necesarios para asegurar el nivel de servicio esperado, en apoyo a los objetivos trazados y la
consecución de los beneficios resultantes de la implementación.

El resultado del análisis general del trabajo permite reconocer que, si bien es cierto, el
proceso de compras se encuentra considerado como un proceso de soporte y no estratégico
del negocio, este puede alcanzar un mayor nivel de relevancia dentro de la organización. Se
puede concluir, que los resultados de la aplicación estructurada e integrada entre AE,
metodologías ágiles y la gestión de servicios de TI a través de ITIL, los procesos decantan en
ubicarse en una posición trascendental dentro del objeto de estudio.

348
RECOMENDACIONES

Se recomienda ampliar el análisis del proyecto a los procesos estratégicos para permitir el
cumplimiento de todos los objetivos estratégicos establecidos por Adecco Perú y así
identificar las oportunidades de mejora y ampliar sus fortalezas de aquellos procesos que no
formaron parte del análisis de este trabajo.

Llevar a cabo una revisión conjunta retrospectiva del plan de proyecto actual para determinar
si desde el punto de vista de arquitectura empresarial se pueden adaptar más herramientas del
marco TOGAF, que permitan incrementar las fortalezas de la base sólida del análisis base
para completar con éxito las etapas siguientes del proyecto.

En esta propuesta se adopta Scrum como única metodología Ágil a aplicar dentro del marco
del proyecto. A partir de la investigación actual realizada, se concluye que Scrum es
totalmente aplicable junto a las herramientas que la soportan y que también se propone en
este documento, logrando obtener una sinergia en su funcionamiento y lo mejor de la
aplicación de esta metodología. Sin embargo, se recomienda revisar y profundizar en el uso
de otras dinámicas y herramientas que puedan acompañar de manera complementaria a las ya
propuestas en esta metodología ágil durante la ejecución de este proyecto.

Obtener la financiación para la consecución de los proyectos complementarios considerados a

la presente propuesta, estas son: Incorporación de Adecco Consulting a la plataforma de
Compras, para fortalecer otra línea de negocio en el mercado, e Implementación de
Aplicación Mobile para que los roles estratégicos de aprobación cuenten con la
disponibilidad de la herramienta y volver aún más eficiente el proceso estudiado.

349
GLOSARIO DE TÉRMINOS

ADM: Método de desarrollo de la arquitectura (ADM por sus siglas en ingles), pilar
fundamental del éxito de TOGAF.

AS IS: Línea Base o Estado actual para contemplar el diseño.

DEADLINE: Fecha limite o plazo asignado para el cumplimiento de una tarea, actividad o
presentación de algún entregable pendiente.

HANGOUT: Aplicación multiplataforma desarrollada por la compañía Google, permite

establecer comunicación mediante video llamadas y llamadas de voz gratuitas, mensajes de
texto, y sostener conversaciones con una persona o un grupo.

ISO 9001: Es la base del sistema de gestión de la calidad como norma internacional y que se
centra en todos los elementos de administración de calidad con los que una empresa debe
contar para tener un sistema efectivo que le permita administrar y mejorar la calidad de sus
productos o servicios.

ITIL: Es un marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de

servicios de tecnologías de la información (TI) de alta calidad.

MICROSOFT SQL SERVER: Base de datos relacional usado para el almacenamiento de los
datos.

ORDEN DE COMPRA: Documento que emite el comprador para pedir mercaderías al

proveedor, indicando cantidad, detalle, precio, condiciones de pago, entre otras cosas.

ORDEN DE PAGO: Orden que se da por escrito para que tesorería efectúe el pago al
proveedor.

350
OUTSOURCING: Método de subcontratación usado en las organizaciones.

POST-IT: Cinta de papel adhesivo que pueda despegarse con facilidad sin estropear las
páginas del libro.

REQUERIMIENTO - Petición de artículos, servicios o activos que se considera necesario

para atender una necesidad dentro de la compañía o para responder una necesidad originada
en el cliente.

ROADMAP: Es una hoja de ruta que especifica la planificación del desarrollo de distintos
softwares con objetivos a corto y largo plazo.

SCRUM: Metodología de gestión de proyectos de software

SENIORITY: Proviene de la palabra senior, está vinculado a la experiencia, y a la

veteranía, y a una forma de estar en el mundo más.

SISTEMA LEGACY: Sistema Informático que ha quedado desfasado pero que sigue siendo
utilizado por el usuario y cuya dificultad de actualizar es Muy Alta.

SOLICITANTE EXTERNO: Persona que solicita artículos, servicios, activos que son
considerados como costos, aplica para atender alguna solicitud originada en el cliente.

SOLICITANTE INTERNO: Requirente que solicita artículos, servicios, activos que son
considerados para consumo interno (gastos).

STAKEHOLDERS: conjunto de actores afectados de alguna manera, como consecuencia de

las decisiones de una organización (accionistas, empleados, clientes, proveedores, etc.)

TIME TO MARKET: Capacidad de reacción de las empresas que, en base al tiempo de

colocación de un producto o servicio, tienen para crear o mantener ventajas competitivas en
los retos que se presenta en el mercado objetivo.

TO BE: Línea Destino o Estado esperado para la propuesta.

351
TOGAF: The Open Group Architecture Framework (TOGAF por sus siglas en inglés) es la
herramienta más utilizada para la implementación de EA.

352
SIGLARIO

AE: Arquitectura Empresarial

BA: Business Analyst

BD: Base de Datos

CAB: Change Advisor Board

ECAB: Emergency Change Advisor Board

CI: Configuration Item

CMDB: Configuration Management Database

DBA: Database Administrator

EA: Enterprise Architecture

ERP: Enterprise Resource Planning

FAQ: Frequently Asked Questions

GA: Gasto Administrativo

HP: Hewlett Packard

IIS: Internet Information Server

ITIL: Information Technology Infrastructure Library

ITSM: Information Technology Service Managment

KEDB: Knowledge Emergency Database

353
KPI: Key Performance Indicator

MTTR: Mean time to repair

OLA: Operational Level Agreement

PBI: Producto Bruto Interno

PC: Personal Computer

PYMES: Pequeña y Mediana Empresa

QA: Quality Assurance

ROI: Return on Investment

SA: Sociedad Anónima

SGC: Sistema de Gestión de Calidad

SLR: Service Level Requirement

SLA: Service Level Agreement

SSOMA: Seguridad y Salud Ocupacional y Medio Ambiente

SUNAT: Superintendencia de Administración Tributaría

UC: Underppining Contracts

VAN: Valor Actual Nero

VPN: Virtual Private Network

TAT: Time for Average Turnaround

TI: Technology Information

TIR: Tasa de Interés de Retorno

354
BIBLIOGRAFÍA

[1] COBO ORTEGA ÁNGEL, VANTI ADOLFO (2015) Gobernanza empresarial de

tecnologías de la información, Ed. Universidad de Cantabria, 4 set. 2015, (pág. 639)

[2] ZEA RESTREPO CLAUDIA, ATUESTA V. MARIA DEL ROSARIO (2007) Hacia una
comunidad educativa interactiva, Universidad Eafit 2007, (pág. 95)

[3] ARANGO SERNA MARTÍN, LONDOÑO SALAZAR JESÚS, ZAPATA CORTÉS

JULIÁN (2010) Arquitectura Empresarial – Una visión General, Revista Ingenierías –
Universidad de Medellín, (pág. 104)

[4] ZACHMAN J. (1987) A Framework for Information Systems Architecture, The IBM
Systems Journal vol.26, No. 3, (pág. 454)

[5] DAMA INTERNATIONAL (2015) The DAMA Guide to the Data Management Body of
Knowledge, Technics Publications, Punto 4.2.1.1, (pág. 470)

[6] ANDREW JOSEY (2013) TOGAF® Versión 9.1 – Guía de Bolsillo, The Open Group,
Van Haren Publishing, (pág. 21)

[7] DANIELE MARCELA (2005) Análisis y Diseño de Sistemas, Universidad Nacional de

Río Cuarto, Argentina

[8] GHOSH SANTANU (2012) Systemic comparison of the application of EVM in

traditional and agile software project - Indian Institute of Technology Delhi

[9] KENT BECK, MIKE BEEDLE, ARIE VAN BENNEKUM, ALISTAIR COCKBURN,
WARD CUNNINGHAM, MARTIN FOWLER, JAMES GRENNING, JIM HIGHSMITH,
ANDREW HUNT, RON JEFFRIES, JON KERN, BRIAN MARICK, ROBERT C.
MARTIN, STEVE MELLOR, KEN SCHWABER, JEFF SUTHERLAND, DAVE THOMAS
(2001). Manifiesto for Software Agile Development [Internet], Disponible desde
http://agilemanifesto.org/ [Consulta 16 de noviembre].

355
[10] ANDRÉS NAVARRO CADAVID, JUAN DANIEL FERNÁNDEZ MARTÍNEZ,
JONATHAN MORALES VÉLEZ (2013) - Revisión de metodologías ágiles para el
desarrollo de software - Grupo de investigación i2T, UNIVERSIDAD ICESI, (pág. 21)

[11] DIETZ, J & HOOGERVORST, J (2011) A critical investigation of TOGAF-based on

the enterprise engineering theory and practice (pág. 76-90)

[12] SUTHERLAND JEFF (2016) Scrum: El arte de hacer el doble de trabajo en la mitad de
tiempo, Editorial Océano (pág. 220)

[13] DEEMER, PETE. (2012) Una introducción básica a la teoría y práctica de Scrum,
InfoQueue. Enterprise Software Development Series (pág. 3)

[14] INTERNATIONAL SCRUM INSTITUTETM:www.scrum-institute.org “Scrum Revealed:

The only Book you can simply learn Scrum” (pág. 51)

[15] ZAMORA ENCISO, RICARDO (2011) Cooplexity: Un modelo de colaboración en

complejidad para la gestión en tiempos de incertidumbre y cambio, (pág. 207)

[16] LLEDÓ, PABLO (2014) Gestión Lean y ágil de proyectos, Trafford Publishing (pág.
188)

[17] KNIBERG, HENRIK & SKARIN MATTIAS (2010) Kanban y Scrum – Obteniendo lo
mejor de ambos, C4Media Editores, (pág. 106)

[18] COHN, MIKE (2005), Agile Estimating and Planning

[19] XAVIER QUESADA (2009), Quinto encuentro Ágil en Barcelona

[20] INGRID ASTIZ (2012), FUERZATRES - Retrospectivas ágiles (Reuniones de equipo)

[21] ANA MARÍA DEL CARMEN GARCÍA OTERINO (2015), Software Development
Engineer in Test Amazon

356
[22] INGRID ASTIZ (2012), FUERZATRES, Gráfico radar

[23] JORGE MAURICIO MOGOLLON PICO (2014) Una propuesta para la Evaluación de
la Gestión de Costos para la Metodología Ágil - Método de Evaluación de Costos para Scrum
(MECS) - Universidad de Pamplona

[24] DEXON SOFTWARE © (2015) : http://dexon.org/?p=515 “Historia de la Gestión del

Servicio de TI (Itil y Pink Elephant)”

[25] KOTLER PHILIP, ARMSTRONG GARY (2003) Fundamentos de Marketing, (pág. 7),
Pearson Educación, (599 págs.)

[26] JURAN J.M. (1996) Juran y la calidad por el diseño (pág. 56), Ediciones Díaz de Santos,
(604 págs.)

357
ANEXOS

ANEXO 2.1 – Cambio de alcance en Declaración de Trabajo de Arquitectura

Solicitud de Cambio de Alcance

Nombre de proyecto:

Preparado por: Versión:

Título: Fecha (versión de

documento):

Revisado por: Fecha de Revisión:

Número de Versión Fecha de Versión Revisado por Descripción Nombre de Archivo

Descripción del cambio solicitado

Justificación de la propuesta de modificación

Evaluación del impacto del cambio propuesto

358
Evaluación del impacto del cambio propuesto

(Se deberá indicar: Referencia a los requerimientos específicos, prioridad de los Stakeholders de los requerimientos
hasta la fecha, fases que deben ser revisadas, fase para dirigir en la priorización de requerimientos, resultados de las
investigaciones de fase y las prioridades revisadas, recomendaciones sobre la gestión de los requerimientos.)

Evaluación del cambio Nombre Firma

Líder del proyecto

Persona que solicita el cambio

Responsable de

Aceptado ( ) Rechazado ( )

Fecha

Seguimiento

Responsable

Fecha programada para el cambio

Fecha de aplicación

359
ANEXO 3.1 – Documento de definición de Requerimientos

Solicitud de Nuevo Desarrollo

Nombre Requerimiento

ID Requerimiento NDAAMMDD-XXXX

Usuario Solicitante Área Cargo

Preparado por Área Cargo

Derivado a Área Cargo

Fecha Requerimiento Descripción

Revisión Fecha Responsable Fecha Rpta. Responsable Observaciones

Emisión

CIERRE

DETALLADO

360
1 Justificación y Alcance (Usuario)

Justificación y alcance del proyecto

2 Detalle y Especificación del Requerimiento (Usuario)

Detalle de la especificación

3 Módulos Intervinientes (Usuario)

Completar el impacto del cambio solicitado en los módulos intervinientes.

4 Funcionalidades intervinientes (Usuario)

Completar el impacto del cambio solicitado en las funcionalidades existentes.

5 Servicios Intervinientes (Usuario)

Completar el impacto del cambio solicitado en los Servicios intervinientes.

6 Reportes Intervinientes (Usuario)

Detallar los reportes afectados por la funcionalidad a modificar.

7 Interfases Afectadas (Usuario)

Completar el impacto del cambio solicitado en los Interfases afectadas.

8 Aclaraciones para Staff Técnico

8.1 Dimensionamiento

Completar de acuerdo a las especificaciones no funcionales del requerimiento, como ser

tiempos de respuestas, tipo de conexión, cantidad de conexiones, cantidad de registros,
cantidad de clientes, cantidad de archivos a manipular, etc.

361
 8.2 Resumen para Personalización

Esta sección del documento no debe ser completada por el Business Analyst, sino por el
Especialista Técnico único encargado de la presente definición.

9 Aclaraciones de la Solución Propuesta (Desarrollo)

Completar de acuerdo a las mejoras propuestas por el equipo de diseño, en caso de que en
revisión interna se encuentre una mejora se especificará en esta sección del documento el
detalle de la misma.

9.1 Supuestos (Desarrollo)

Completar de acuerdo con las premisas que se tuvieron en cuenta al realizar el análisis del
requerimiento y son necesarias para estimar el presente control de cambios.

9.2 Dependencias (Desarrollo para El Usuario y/o Terceros)

Completar de acuerdo a la información adicional que debe el usuario, para poder realizar el
control de cambio.

Realizar revisión de Alcance y Supuestos asumidos en la estimación Inicial de Alto Nivel,

hasta generar la Revisión de Cierre Detallado del Requerimiento

10 Compromiso de Entrega de la Solución del requerimiento (Desarrollo)

Tiempo estimado: XX días hábiles

Aclaración: El tiempo estimado es unitario y lineal, solo referencial al esfuerzo de horas

hombre. No está relacionado a la calendarización definitiva de la personalización, luego de
aprobada.

Entregables

Ejecutables (junto con servicios y/o archivos de configuración si aplica).

362
Release Letter (Incluye listado de nuevos desarrollos y/o fixes que componen el paquete
entregado, instructivo de instalación, detalles técnicos de ejecutables, archivos,
configuraciones y procedimientos que correspondan).

Forma y Lugar: En laboratorio de QA.

Si no se puede concretar la instalación en la fecha acordada, ya sea por problemas

concernientes a la disponibilidad del laboratorio, falta de información requerida para
completar la configuración o temas de terceros, Desarrollo entrega la versión al Usuario en
medio magnético y esa fecha es considerada como equivalente a la entrega formal del
entregable en laboratorio.

En ese caso, es responsabilidad del Usuario instalarla y configurarla en su laboratorio, cuando

subsane los inconvenientes.

Fecha de entrega: A definir a partir del cumplimiento de los siguientes hitos

Aprobación de ejecución

Cumplimiento de las dependencias detalladas.

Aprobación de la Revisión de Cierre Detallado del Requerimiento

Aclaración: En caso de que el presente requerimiento forme parte de un conjunto de

requerimientos, si bien se estimaran en forma separada, la calendarización de la entrega se
maneja en una fecha única para conformar un paquete.

363
11 Hitos

Hitos:

Conforme de Entrega:

En cualquier caso, el cliente debe firmar la recepción de la versión el día en el que el personal
de Desarrollo concrete la entrega.

Conforme de Criterios de Aceptación:

Luego de la entrega, se debe validar los criterios de aceptación definidos, luego de lo cual el
usuario debe firmar su aprobación por escrito en la correspondiente Carta de Aceptación.

A partir de la fecha definida en el Conforme de entrega, el usuario cuenta con un plazo

máximo de XX días calendario para realizar las pruebas del paquete entregado y elevar sus
observaciones al equipo de desarrollo.

Todo bug reportado durante dicho periodo es resuelto a la brevedad por desarrollo durante el
mismo período de QA.

Cumplido dicho plazo, desarrollo considera la Conformidad de Aceptación del

Usuario.

13 Aprobación (Usuario/Project Manager)

13.1 Aprobación de Estimación (Usuario/Project Manager)

364
Usuario Project Manager

Por: ________________________________ Por: _______________________________

Firma: ______________________________ Firma: _____________________________

Cargo: _______________________________ Cargo: _____________________________

Fecha: _______________________________ Fecha: _____________________________

13.2 Aprobación de Revisión de Cierre Detallado (Usuario/Project Manager)

Usuario Project Manager

Por: _________________________________ Por: _________________________________

Firma: ________________________________ Firma: _______________________________

Cargo: ________________________________ Cargo: ________________________________

Fecha: ________________________________ Fecha:_________________________________

365
ANEXO 4.1 – Plantilla Ficha de Alcance de Servicio

GAS-
Código:
ADEXXX
Ficha de Alcance de Servicio

Versión X.X

INTRODUCCIÓN

Propósito

Cliente

Alcance

Objetivos

PREREQUISITOS

¿Cómo calificaría el servicio?

( ) Servicio Nuevo

( ) Mejora de un Servicio Existente

( ) Servicio Específico para un cliente

¿El cliente cuenta con un presupuesto para concretar la oportunidad de negocio?

¿El cliente tiene una fecha de cuándo debe estar operativo el requerimiento solicitado?

¿El cliente cuenta con la infraestructura adecuada para operar el servicio solicitado?

366
¿Cuál es la proyección de ventas de unidades?

FUNCIONALIDAD

Requerimiento:

Descripción

ALINEAMIENTO ESTRATÉGICO

ENTREGABLES

Los entregables que se entregaran como parte del proceso de implementación del
desarrollo de Software listados a continuación:

N ENTREGABLE REQUERIDO
° (SI/NO)

1 Cotización

2 Documento de Análisis

3 Documento de Diseño

4 Empaquetado de Software

5 Plan de Pruebas

6 Casos de Pruebas Unitarias

7 Casos de Pruebas Modulares/Integrales

8 Pruebas de Stress

9 Pruebas Automatizadas

367
 1 Informe de Pruebas
1

1 Manual del Nuevo Software

2

1 Videos de Nuevo Software

3

1 Documento de Despliegue
4

1 Actualización de Menú de Operaciones

5

1 Términos de Soporte Técnico

6

1 Términos de Garantía
7

A continuación, se lista los entregables necesarios (elementos hardware) para la

implantación del servicio.

N ENTREGABLE REQUERIDO
° (SI/NO)

1 Guía de Recepción de Equipo

2 Instalación

3 Configuración

368
 4 Resultado de Pruebas

5 Términos de Soporte Técnico

6 Términos de Garantía

ANEXO 4.2 – Plantilla Requerimiento de Nivel de Servicio (SLR)

Código SLR-
Requerimiento de Nivel de Servicio : ADEXXX
(SLR)
Versión X.X

Por favor, complete el siguiente cuestionario para poder identificar los requerimientos
del negocio para brindar continuidad, disponibilidad y rendimiento de los servicios
ofrecidos.

Datos del solicitante.

Área / Razón Social:

Responsable:

Email / Teléfono:

Indique el nombre del requerimiento

369
Realice una breve descripción del requerimiento.

Indique el horario en el cual desea tener disponible el servicio.

Lunes a Viernes ( )

24 x 7 ( )

Otros ( ) Especifique: ______________________________________

Por cuánto tiempo puede estar “no disponible” el servicio antes de cualquier
implicación contractual o regulatoria?

La definición de disponibilidad para el cliente significa lo siguiente:

< 4 horas ( )

< 8 horas ( )

< 24 horas ( )

Otros ( ) Especifique: ______________________________________

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.

370
 Nivel de
Inmediata < a 4 horas < a 6 horas < a 8 horas
impacto

Crítica

Grave

Leve

Indique que y como desea medir el servicio

Se mide el grado de realización y de cumplimiento con los que actúan los

responsables del nivel de servicio y se desea medir de la siguiente manera:

Estadísticas de rendimiento del servicio ( )

Tiempos de respuesta a tickets según prioridad ( )

Indique como desea monitorear el servicio

Para asegurar una prestación óptima del servicio se debe analizar y reportar las metas
del nivel de servicio, verificar el cumplimiento de los acuerdos de soporte y elaborar
los informes de monitoreo.

Reportes en el Sistema Service Now ()

Alertas en correo electrónico ()

371
 Otros () Especifique:

ANEXO 4.3 – Plantilla Acuerdo de Nivel de Servicio (SLA)

SLA-
Código:
ADEXXX
Acuerdo de Nivel de Servicio (SLA)

Versión X.X

CONDICIONES GENERALES

DEFINICIONES

COMPROMISOS

COMUNICACIÓN

EXCLUSIONES

LIMITACIONES

PROVEEDOR DE SERVICIO CLIENTE DE SERVICIO

372
ANEXO 4.4 – Plantilla Acuerdo de Nivel Operacional (OLA)

OLA-
Formato Código
ADEXXX

Versión X.X
Acuerdo de Nivel Operacional (OLA)
Página X de X

ACUERDO DE NIVEL OPERACIONAL (OLA)

Nombre de Servicio

CONDICIONES GENERALES

PARTES

VIGENCIA

DEFINICIONES

SISTEMAS / APLICATIVOS SOPORTADOS

Sistema / Proveedor Descripción Servidor Plataforma /

Aplicativo BD

RESPONSABILIDADES DE LAS PARTES INVOLUCRADAS

COMPROMISOS

COMUNICACIÓN

373
 Sistema / Aplicativo Responsable

EXCLUSIONES

LIMITACIONES

ANEXO 4.5 – Plantilla Contrato de Proveedores (UC)

UC-
Formato Código ADE-
XXX

Contrato de Soporte (UC) Versión X.X

Nombre Proveedor Página X de X

Datos del Proveedor

Razón Social:

Nro. R.U.C.:

Dirección:

Teléfono:

374
Horario:

Datos del Contacto (1)

Nombres y Apellidos:

Cargo:

Correo Electrónico:

Datos del Contacto (2)

Nombres y Apellidos:

Cargo:

Correo Electrónico:

Servicio que brinda

Soporte que brinda

Compromiso de Garantía

375
ANEXO 4.6 – Requerimiento de Cambio (RFC)

RFC-
Código:
ADEXXX
Requerimiento de Cambio (RFC)

Versión X.X

Datos del solicitante

* Nombre del Solicitante

* Aprobador/es

() Emergencia

() Simple
* Categoría del cambio
() Mediano

() Complejo

Identificación del cambio

* Descripción del cambio

* Proyecto Relacionado

* Urgencia

* Impacto

* Entorno

376
Servicios afectados

Áreas implicadas

Elementos de
configuración afectados

Afecta nivel de servicio

Fecha límite

N° usuarios afectados

Detalle del cambio

* Motivo del cambio

* Objetivo del cambio

Detalles del impacto

Efectos de la no
implementación

Inicio previsto

Finalización prevista

* Clasificación del cambio Mantenimiento evolutivo

377
 () Nueva funcionalidad

() Nueva versión

() Nuevo servicio

() Paso de un entorno a otro

() Mantenimiento preventivo

() Mantenimiento

() Mejora de servicio

() Mantenimiento adaptativo

() Mantenimiento correctivo

Temas a realizar

Flujo del proceso (orden)

* Tarea 1

* Tarea 2

* Tarea 3

* Tarea 4

Plan de pruebas

Acciones a realizar para comprobar la ejecución correcta del cambio

Tarea 1

378
Tarea 2

Tarea 3

Tarea 4

Plan de contingencia

Acciones a realizar en caso de errores

Tarea 1

Tarea 2

Tarea 3

Tarea 4

Documentación asociada al cambio

379