Propuesta de una arquitectura empresarial para una empresa de ...
Transcript of Propuesta de una arquitectura empresarial para una empresa de ...
Propuesta de una arquitectura empresarial para una empresa deconsultoría de sistemas
Item type info:eu-repo/semantics/bachelorThesis
Authors Oré Alvarado, Erick Alexander; Valdespino Alvarez,Claudia Fiorella
DOI 10.6084/m9.figshare.3398950
Publisher Universidad Peruana de Ciencias Aplicadas (UPC)
Rights info:eu-repo/semantics/openAccess
Downloaded 5-Mar-2018 08:07:38
Link to item http://hdl.handle.net/10757/605431
1
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 UNA EMPRESA DE
CONSULTORÍA DE SISTEMAS
PROYECTO PROFESIONAL PRESENTADO POR:
ORÉ ALVARADO, ERICK ALEXANDER
VALDESPINO ALVAREZ, CLAUDIA FIORELLA
ASESORES:
SAMANTHA LÓPEZ
EDUARDO MENDÍVIL
JUAN CARLOS TORRES
Lima, Enero de 2016
DEDICATORIA
El presente proyecto está dedicado a nuestros padres , amigos y educadores,
quienes siempre nos han alentado a seguir adelante para alcanzar el éxito en
nuestro camino profesional.
AGRADECIMIENTOS
Además, el presente proyecto no hubiera podido realizarse de no ser por el apoyo de nuestros
profesores, quienes nos brindaron las mejores enseñanzas y las herramientas necesarias para
desarrollar un trabajo de investigación de calidad de acuerdo a las mejores prácticas del
mercado empresarial.
De igual manera, una mención especial a la Gerencia de nuestra organización TSNET S.A. y
al área administrativa, quienes compartieron sus conocimientos dentro y fuera del horario de
oficina brindándonos una visión estratégica de la organización que va más allá del desarrollo
de proyectos.
Y por sobre todas las cosas, gracias a Dios, por darnos la oportunidad de trabajar juntos una
vez más.
RESUMEN
El presente trabajo desarrolla la propuesta de implementación de una arquitectura empresarial
integrada con la gestión del recurso profesional y la gestión de servicios en TI, para lo cual se
van a poner en práctica los conceptos teóricos aprendidos a lo largo del Programa de
Actualización Profesional.
Asimismo, el trabajo está conformado por cinco capítulos. El primero de ellos abarca la
fundamentación del marco teórico en donde se detallan los conceptos principales que ayudan
a comprender el entorno de trabajo de la organización, se presenta el objeto de estudio, y los
objetivos y beneficios del proyecto.
El segundo capítulo aborda la relación entre los proyectos de software y el recurso
profesional en donde se identifica el nivel de madurez del equipo tomando como marco de
trabajo el P-CMM. Por otro lado, se identifican los elementos que no permiten asegurar la
permanencia en un determinado nivel de madurez, y finalmente se presentan los estándares
PSP y TSP que soportan la arquitectura de personal.
El tercer capítulo detalla la gestión de servicios en TI bajo el marco de trabajo propuesto por
en ITIL, lo cual busca fortalecer y mejorar la calidad de los servicios.
El cuarto capítulo presenta un análisis detallado de la arquitectura de línea base y la
arquitectura objetivo de la organización, empleando para ello el marco de referencia TOGAF.
El quinto capítulo define una propuesta de solución en la cual se integren los proyectos de
software y el recurso profesional, la gestión de servicios en TI, y la arquitectura empresarial.
El documento cierra su contenido con la presentación de las conclusiones finales,
recomendaciones, glosario de términos, siglario, bibliografía, y anexos.
ÍNDICE
DEDICATORIA ........................................................................................................................ 2
AGRADECIMIENTOS ............................................................................................................. 4
RESUMEN ................................................................................................................................ 5
ÍNDICE ...................................................................................................................................... 7
INTRODUCCIÓN ................................................................................................................... 11
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS ...................................................................... 12
MARCO TEÓRICO............................................................................................................. 12
OBJETO DE ESTUDIO ...................................................................................................... 24
ORGANIZACIÓN OBJETIVO ....................................................................................... 24
MISIÓN ........................................................................................................................... 25
VISIÓN ............................................................................................................................ 25
OBJETIVOS ESTRATÉGICOS ...................................................................................... 25
ORGANIGRAMA ............................................................................................................. 1
ALCANCE DEL PROYECTO .......................................................................................... 1
OBJETIVOS DEL PROYECTO ........................................................................................... 2
OBJETIVO GENERAL ..................................................................................................... 2
OBJETIVOS ESPECÍFICOS ............................................................................................ 2
BENEFICIOS DEL PROYECTO.......................................................................................... 3
BENEFICIOS TANGIBLES ............................................................................................. 3
BENEFICIOS INTANGIBLES ......................................................................................... 4
CAPITULO 2. LOS PROYECTOS SOFTWARE Y EL RECURSO PROFESIONAL ........... 5
INTRODUCCIÓN ................................................................................................................. 5
OBJETIVOS .......................................................................................................................... 5
IDENTIFICACIÓN DEL NIVEL DE MADUREZ DEL EQUIPO ...................................... 6
IDENTIFICACIÓN DE ATRIBUTOS.................................................................................. 8
ELEMENTOS DE RIESGO Y PROBLEMAS ..................................................................... 9
ARQUITECTURA DE PERSONAL .................................................................................. 17
TSP y PSP ............................................................................................................................ 34
CONCLUSIONES ............................................................................................................... 54
CAPÍTULO 3. GESTIÓN DE SERVICIOS EN TI................................................................. 56
INTRODUCCIÓN ............................................................................................................... 56
EVALUACIÓN ESTRATÉGICA ....................................................................................... 56
PLANIFICACIÓN ESTRATÉGICA .................................................................................. 83
DESCRIPCIÓN DEL PROCESO DE MANTENIMIENTO DE SOFTWARE ................. 94
HERRAMIENTAS Y PLANTILLAS: ............................................................................ 98
ACUERDOS DEL NIVEL DE SERVICIO (SLA) ........................................................... 104
PLAN DE CAPACIDAD .................................................................................................. 110
PROCESOS DE GESTIÓN DE CAMBIOS ..................................................................... 118
HERRAMIENTAS Y PLANTILLAS ........................................................................... 121
PROCESOS DE PRUEBA DEL SERVICIO .................................................................... 124
HERRAMIENTAS Y PLANTILLAS: .......................................................................... 127
CONCLUSIONES ............................................................................................................. 129
CAPÍTULO 4: ARQUITECTURA EMPRESARIAL ........................................................... 130
INTRODUCCIÓN ............................................................................................................. 130
ALCANCE ......................................................................................................................... 130
METAS, CUMPLIMIENTOS Y LIMITACIONES .......................................................... 131
RIESGOS Y PROBLEMAS .............................................................................................. 132
ARQUITECTURA LINEA BASE (AS IS) ....................................................................... 136
ARQUITECTURA DE NEGOCIO (AS IS) .................................................................. 136
ARQUITECTURA DE DATOS (AS IS) ...................................................................... 174
ARQUITECTURA DE APLICACIONES (AS IS) ....................................................... 181
ARQUITECTURA TECNOLÓGICA (AS IS) .............................................................. 183
ARQUITECTURA DE SEGURIDAD (AS IS) ............................................................. 186
FUNDAMENTACIÓN Y JUSTIFICACION DE LA ARQUITECTURA PROPUESTA
............................................................................................................................................ 187
ARQUITECTURA OBJETIVO (TO BE) ......................................................................... 189
ARQUITECTURA DE NEGOCIO (TO BE) ................................................................ 190
ARQUITECTURA DE DATOS (TO BE) ..................................................................... 202
ARQUITECTURA DE APLICACIONES (TO BE) ..................................................... 206
ARQUITECTURA TECNOLÓGICA (TO BE) ............................................................ 207
ARQUITECTURA DE SEGURIDAD (TO BE) ........................................................... 209
ANALISIS DE BRECHAS................................................................................................ 211
ARQUITECTURA DE NEGOCIO ............................................................................... 211
ARQUITECTURA DE DATOS .................................................................................... 220
ARQUITECTURA DE APLICACIONES .................................................................... 227
CONCLUSIONES ............................................................................................................. 228
CAPÍTULO 5: ESTRUCTURA PROPUESTA .................................................................... 229
INTRODUCCIÓN ............................................................................................................. 229
ENFOQUE DE LA PROPUESTA .................................................................................... 229
METAS Y OBJETIVOS .................................................................................................... 229
SITUACIÓN ACTUAL (AS IS) ....................................................................................... 230
SITUACIÓN OBJETIVO (TO BE) ................................................................................... 231
ANÁLISIS DE LA PROBLEMÁTICA ENCONTRADA ................................................ 231
DESCRIPCIÓN DE LA PROPUESTA ............................................................................. 235
ESTRATEGIA DE IMPLEMENTACIÓN: .................................................................. 236
ARQUITECTURA DE APLICACIONES (TO BE) ..................................................... 245
ARQUITECTURA TECNOLÓGICA (TO BE) ............................................................ 246
ANALISIS DE BRECHAS................................................................................................ 248
ARQUITECTURA DE NEGOCIO ............................................................................... 248
ARQUITECTURA DE DATOS .................................................................................... 255
ARQUITECTURA DE APLICACIONES .................................................................... 260
GESTIÓN DE RIESGOS .............................................................................................. 261
PROCESO DE MANTENIMIENTO Y DESARROLLO DE SOFTWARE .................... 265
PROCESO DE GESTIÓN DE CAMBIOS........................................................................ 270
ELEMENTOS DE CONFIGURACION SUJETOS A CAMBIOS .............................. 270
PROCESO DETALLADO ............................................................................................ 270
HERRAMIENTAS Y PLANTILLAS ........................................................................... 272
PROCESO DE PRUEBA DEL SERVICIO ...................................................................... 274
HERRAMIENTAS Y PLANTILLAS: .......................................................................... 276
COSTOS Y RECURSOS REQUERIDOS ........................................................................ 278
CONCLUSIONES ............................................................................................................. 295
CONCLUSIONES ................................................................................................................. 296
RECOMENDACIONES ........................................................................................................ 298
GLOSARIO DE TÉRMINOS................................................................................................ 299
SIGLARIO ............................................................................................................................. 300
BIBLIOGRAFÍA ................................................................................................................... 302
ANEXOS ............................................................................................................................... 304
INTRODUCCIÓN
En la actualidad, las organizaciones, independientemente de su tamaño y del sector de su
actividad, deben hacer frente a mercados competitivos para conciliar la satisfacción de sus
clientes con la eficiencia económica de sus actividades. Por ello, toda organización debe
dedicar un mayor esfuerzo a la optimización de sus procesos y recursos, y mediante la
adopción de estándares y mejores prácticas, asegurar el alineamiento con sus objetivos
estratégicos.
TSNET S.A., objeto de estudio del presente documento, es una empresa encargada de brindar
servicios de consultoría de sistemas que busca ampliar su posicionamiento en el mercado de
Tecnologías de la Información. Si bien es cierto que el crecimiento de la organización se ha
sostenido en los últimos años, no ha sido posible que éste alcance los niveles esperados
debido a un inadecuado alineamiento entre sus estrategias de negocio, sus procesos y su
principal activo, el recurso humano. El enfoque de la propuesta circunscrita en el presente
documento está orientada a resolver la problemática de los dos principales procesos que
conforman el pilar de la estrategia de crecimiento de la organización: Gestión Comercial y
Gestión de Proyectos, además del proceso de soporte de Gestión de Facturación que
interviene entre ambos.
Para ello, se establecerá un modelo de Arquitectura Empresarial, basado en el marco de
trabajo TOGAF, para facilitar la trazabilidad y monitoreo de los componentes involucrados
en cada uno de los procesos previamente mencionados. Este modelo estará soportado por el
proceso de Mantenimiento y Desarrollo de Software el cual, basado en las mejores prácticas
ITIL y la redefinición de sus puestos de trabajo mediante la aplicación del estándar P-CMM,
se encargará de asegurar el correcto funcionamiento de dichos procesos.
CAPÍTULO 1: FUNDAMENTOS TEÓRICOS
MARCO TEÓRICO
1. PSP
El Personal Software ProcessSM1
está diseñado para enseñar a los profesionales de software a
planificar y dar seguimiento a su trabajo, utilizar un proceso definido y medible, establecer
objetivos medibles, y dar seguimiento al cumplimiento de los mismos.
Además, enseña al personal a gestionar la calidad desde el inicio de su trabajo, analizar los
resultados, y emplearlos de manera que se mejore el proceso para el siguiente proyecto.
Los principios de planeamiento y calidad sobre los cuales está diseñado el PSP son los
siguientes:
Cada ingeniero es diferente. Para ser más efectivos deben planificar su trabajo y deben
basar sus planes en sus propios datos personales.
Para mejorar continuamente su desempeño, el personal debe utilizar procesos bien
definidos y medibles.
Para producir productos de calidad, el personal debe sentirse responsable de la calidad de
sus productos.
Cuesta menos encontrar y arreglar defectos antes de en un proceso que luego del mismo.
Es más eficiente prevenir defectos que encontrarlos y arreglarlos.
La manera correcta de hacer un trabajo es siempre la más rápida y barata.
1 Personal Software Process, PSP es marca de servicio de la Universidad Carnegie Mellon.
2. TSP
El Team Software ProcessSM2
está diseñado para guiar a los equipos de trabajo en la
identificación de necesidades de negocio críticas, asegurar la gestión de la calidad, y reducir
los tiempos. Además, puede ser empleado en todos los aspectos de desarrollo de software:
definición de requerimientos, diseño, implementación, pruebas, y mantenimiento.
Los principios sobre los cuales está diseñado el TSP son los siguientes:
Los ingenieros conocen más del trabajo y pueden desarrollar mejores planes.
Cuando los ingenieros planifican su propio trabajo, están comprometidos con el plan.
El seguimiento de un proyecto requiere planificación detallada y datos exactos.
Solo las personas que hacen el trabajo puede obtener datos precisos.
Para optimizar tiempos, los ingenieros deben equilibrar su carga de trabajo.
Para maximizar la productividad, se debe enfocar primero en la calidad.
3. P-CMM
El People Capability Maturity Model®3
es una guía para la implementación de prácticas que
ayuden a mejorar la capacidad de la fuerza de trabajo de una organización.
Debido a que esta guía no se puede implementar de la noche a la mañana, el P-CMM presenta
niveles progresivos que conllevan a una transformación única de la cultura organizativa
mediante la utilización de poderosas prácticas para atraer, desarrollar, organizar, motivar y
retener a la fuerza de trabajo.
2 Team Software Process, TSP es marca de servicio de la Universidad Carnegie Mellon.
4. Habilidades Blandas
Representan los rasgos de personalidad, comunicación, lenguaje y desenvolvimiento que son
innatos al ser humano y que van más allá de un perfil profesional u oficio. Además, estas
habilidades cuentan con una capacidad de adaptación que varía de acuerdo a cada persona; es
decir, son evolutivas y mejorables. Algunos ejemplos de habilidades blandas son:
comunicación asertiva, escucha activa, respeto a las opiniones, empatía, sociabilidad,
proactividad, capacidad de análisis, orden, capacidad de redacción, entre otros.
5. Habilidades Duras
Representan las exigencias técnicas o profesionales de una determinada posición o perfil de
trabajo. También pueden ser definidas como los conocimientos que se adquieren en
instituciones educativas, como institutos o universidades, para el desarrollo profesional de un
individuo generando propuestas de valor mediante la aplicación de sus conocimientos.
Las habilidades duras se ajustan a un perfil, por ejemplo: una persona experta en
programación ABAP4, un gerente de proyectos con conocimientos en gestión de proyectos,
un analista con experiencia en modelamiento UML5, entre otros.
6. Taxonomía de Bloom6
Sistema de clasificación de habilidades que se caracteriza por ser jerárquico; es decir, asume
que el aprendizaje a niveles superiores depende de la adquisición del conocimiento y
habilidades de ciertos niveles inferiores.
3 Copyright 2001 de la Universidad Carnegie Mellon.
4 Advanced Business Application Programming, lenguaje de programación para desarrollar
soluciones en SAP.
5 Unified Modeling Language, estándar para modelar soluciones orientadas a objetos.
6 Benjamín Bloom, psicólogo y pedagogo estadounidense que realizó contribuciones
significativas a la taxonomía de objetivos de la educación.
La taxonomía de Bloom presenta 6 niveles que se presentan en orden ascendente:
Conocimiento: Observar y tener noción de hechos específicos.
Comprensión: Entender la información, captar su significado.
Aplicación: Hacer uso del conocimiento nuevo.
Análisis: Encontrar patrones, identificar componentes, organizar datos.
Síntesis: Utilizar ideas para crear otras nuevas, establecer conclusiones.
Evaluación: Comparar y discriminar ideas, presentar resultados basándose en argumentos
razonados.
7. Inteligencia
Conforma la capacidad que tiene cada persona para utilizar de manera adecuada sus
conocimientos e ideas y, de esta manera, proponer soluciones de calidad de acuerdo a la
complejidad de las situaciones que enfrentan en su día a día.
Existen diversos tipos de inteligencia como, por ejemplo: Social, verbal, personal, creativa,
numérica, espacial, entre otras.
8. ITIL
El IT Infraestructure Library (ITIL) es un marco de trabajo basado en buenas prácticas para la
gestión de servicios de tecnologías de la información. Este marco de trabajo ha sido adoptado
con éxito en organizaciones a nivel mundial y ha contribuido de manera óptima en el
desarrollo de la calidad y la eficiencia de los servicios entregados por el área de TI.
Para ello, define el ciclo de vida de un servicio7 en 5 etapas:
7 Introducción a ITIL: El marco para la gestión de servicios TI.
Figura 1 – Ciclo de vida del Servicio ITIL
Fuente: http://www.re-inventa.com/introduccion-a-itil/
Estrategia del Servicio:
En esta etapa se realiza la selección, definición y posicionamiento de los servicios que se
ofrecen o van a ofrecerse. Su principal objetivo es alinear los servicios con las necesidades de
negocio del cliente para asegurar la aportación de valor añadido.
Incluye los procesos de: Gestión del Portfolio de Servicios, Gestión de la Demanda y Gestión
Financiera.
Diseño del Servicio:
En esta etapa se realiza el diseño del servicio y de los elementos que le darán soporte. Incluye
la gestión de: Catálogo de servicios, Niveles de servicio, Disponibilidad del servicio,
Capacidad del servicio, Continuidad del servicio, Seguridad del servicio y de la Gestión de
Proveedores.
Transición del Servicio:
Esta etapa está relacionada a la introducción de nuevos servicios y la gestión de cambios en
los servicios ya ofrecidos. Incluye procesos de: Gestión de cambios, Gestión de
configuración, Gestión de entregas (releases) y despliegues (deployments), Planificación de
la transición, Validación y testeo, Evaluación y gestión del conocimiento.
Operación del Servicio:
Esta etapa se refiere a la fase en que el servicio está operando y se ocupa de que el servicio
opere dentro de los parámetros definidos. Algunos de los procesos incluidos son: Gestión de
incidencias, Gestión de problemas, Gestión de eventos, Gestión de peticiones de servicio y la
Gestión de accesos.
Mejora Continua:
Esta etapa está enfocada a garantizar el perfeccionamiento continuo del servicio mediante la
aplicación de métodos que aseguren la gestión de la calidad con la finalidad de aprender de
los éxitos y fracasos del pasado.
9. Arquitectura Empresarial
Se define como Arquitectura Empresarial (AE) a la 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.
La Arquitectura Empresarial señala un esquema o un mapa de navegación, que incluye los
procesos, componentes y políticas de una organización y debe servir de apoyo en la toma de
decisiones estratégicas. En consecuencia, permite a la alta gerencia entender mejor el papel
de la tecnología en su estrategia general, establecer el ROI de la inversión en TI y revalorizar
la importancia estratégica de las áreas de tecnología en la organización.
El modelo de arquitectura empresarial esta soportada en 4 arquitecturas:
Figura 2 – Modelo Arquitectura Empresarial
Fuente: http://www.amazing.com.co/arquitectura-empresarial.php
1. Arquitectura de Negocio:
Define la estrategia de negocio, la estructura organizacional y los procesos clave de la
organización.
2. Arquitectura de Datos:
Describe la estructura de los datos físicos y lógicos de la organización y sus modelos de
gestión.
3. Arquitectura de Aplicaciones:
Provee la definición funcional para cada uno de los sistemas de información requeridos, las
interacciones entre estos sistemas y sus relaciones con los procesos de negocio CORE de la
organización.
4. Arquitectura Tecnológica:
Describe la estructura de hardware, software y redes requerida para dar soporte a la
implantación de las aplicaciones principales y de misión crítica de la organización.
Arquitectura Empresarial potencia a las empresas con un abanico de oportunidades para
mejorar su desempeño y crecimiento. Entre algunos de los beneficios que proporciona su
establecimiento dentro de las organizaciones8, podemos resaltar los siguientes:
8 Artículo de Arquitectura Empresarial publicado en la revista CIO@gov de Colombia.
(Diciembre 2013)
Lleva a definir un verdadero plan estratégico de la organización, teniendo en cuenta los
cuatro componentes básicos (negocio, información, aplicaciones e infraestructura
tecnológica).
Permite conocer el estado ideal al que podría llegar la organización y el papel de la
tecnología para soportar los procesos de negocio necesarios para alcanzarlo.
Permite identificar oportunidades de integración y reutilización de aplicaciones de
recursos en toda la organización.
Establece trazabilidad entre procesos, datos, aplicaciones e infraestructura tecnológica.
Da flexibilidad. Lleva a la organización a estar en la capacidad de responder rápida y
acertadamente ante retos y oportunidades que presenta el mercado, los cambios
tecnológicos y cualquiera otra circunstancia proyecta e inesperada.
Impulsa el desarrollo de TI en la organización pues es más evidente la importancia de la
tecnología y del CIO en el cumplimiento de la misión y en el negocio.
De acuerdo a los beneficios que proporciona la Arquitectura Empresarial en las
organizaciones, es necesario contar con un marco de trabajo que nos ayude en su
establecimiento y gestión. El marco propuesto por TOGAF (The Open Group Architecture
Framework) proporciona un conjunto detallado de métodos y herramientas para la
aceptación, producción, uso y mantenimiento de arquitecturas empresariales dentro de una
organización basándose en un modelo de proceso iterativo soportado por un conjunto de
buenas prácticas y un conjunto reutilizable de activos arquitecturales existentes9.
TOGAF hace uso del método ADM (Architecture Development Method) para el desarrollo y
la gestión del ciclo de vida de una arquitectura empresarial. Este método es iterativo en todo
el proceso y está compuesto de 8 fases:
Figura 3 – Fases del método ADM de TOGAF
Fuente: http://www.opengroup.org/
A continuación se presenta la descripción de cada una de las fases del método ADM de
TOGAF10
:
9 TOGAF® Version 9.1, an Open Group Standard
(http://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html)
10 TOGAF® Versión 9.1, Guía de Bolsillo
Fase Preliminar: Emprende las actividades de iniciación y preparación requeridas para
crear la capacidad arquitectónica incluyendo la adaptación de TOGAF, la selección de
herramientas y la definición de los principios de arquitectura.
Gestión de Requerimientos: Cada etapa del proyecto de TOGAF está basada en los
requerimientos del negocio, incluyendo su validación. Los requerimientos se identifican,
se almacenan y se gestionan al ingreso y egreso de las fases relevantes del ADM, las
cuales eliminan, abordan y priorizan los requerimientos.
Visión de la Arquitectura: Establece el alcance, las limitaciones y expectativas de un
proyecto de TOGAF. Crea la visión de la arquitectura, identifica a los interesados, valida
el contexto del negocio y crea la declaración de trabajo de la arquitectura. Obtiene
aprobaciones.
Arquitectura de Negocio: Esta arquitectura provee las bases para el entendimiento del
entorno del negocio y que servirán, posteriormente, para el alineamiento de las estrategias
de la empresa con procesos e iniciativas de TI.
Arquitectura de Sistemas de la Información: Esta arquitectura provee un mapa de
trazabilidad entre aplicaciones y datos de la organización.
Arquitectura Tecnológica: Esta arquitectura provee un mapa de componentes de TI
(hardware y software) requeridos para mantener las aplicaciones implantadas en la
organización.
Oportunidad y Soluciones: Realiza la planificación de la implementación inicial y la
identificación de medios de entrega para los bloques de construcción identificados en las
fases anteriores. Determina si se requiere un enfoque incremental, y sí así fuera, identifica
las arquitecturas de transición.
Planificación de la migración: Desarrolla el plan detallado de la implementación y
migración que aborda como moverse de la arquitectura de línea base a la arquitectura
destino.
Gobierno de la implementación: Proporciona supervisión arquitectónica para la
implementación. Prepara y publica contratos de arquitectura. Asegura que el proyecto de
implementación este en conformidad con la arquitectura.
Gestión de cambios de la arquitectura: Proporciona seguimiento continuo y un proceso de
gestión de cambios para asegurar que la arquitectura responda a las necesidades de la
empresa y que se maximice el valor de la arquitectura para el negocio.
10. Microsoft Dynamics CRM (Customer Relationship Management)
De acuerdo a lo citado por Microsoft en su página web, es una solución de negocios para la
administración de las relaciones con los clientes que impulsa la productividad en las ventas y
la eficacia del marketing11
.
11. E-Business Suite(EBS) Project
De acuerdo a lo citado por Oracle en su página Web, EBS Project proporciona a los
administradores de proyectos la visibilidad y el control que necesitan para entregar sus
11 http://www.microsoft.com/es-pe/dynamics/CRM.aspx
proyectos con éxito, mejorar la rentabilidad y operar de manera más eficiente. Este consolida
la siguiente información de proyecto en un repositorio: WorkPlan, progresos, problemas,
cambios, documentos, información de costos, presupuestos, previsiones, rendimientos e
informes de estado. Asimismo, permite planificar el trabajo, asignar recursos, provisionar y
mantener comunicados a los stakeholders12
.
12. XRAY
Es un software ERP de propiedad de TSNET S.A. desarrollado en Oracle que permite la
posibilidad de gestión empresarial avanzada para empresas medianas y en crecimiento.
Maneja de manera eficientemente procesos Comerciales, Logísticos, Financieros y contables,
Planillas, Planeamiento de la Producción y Planeamiento de Compras13
.
OBJETO DE ESTUDIO
ORGANIZACIÓN OBJETIVO
TSNET S.A. es una empresa de consultoría orientada a apoyar a las organizaciones en el
despliegue exitoso de las estrategias empresariales que permita hacerlas más grandes, más
fuertes y más ágiles. Para ello, evalúa, diseña e implementa sistemas de información
utilizando las mejores marcas de software a nivel mundial: SAP, ORACLE, MICROSOFT e
IBM.
12 http://www.oracle.com/us/products/applications/ebusiness/projects/053961.html
13 http://www.oracle.com/us/products/applications/ebusiness/projects/053961.html
MISIÓN
“Ser una compañía global de Consultoría y Gestión de Servicios de tecnología
de información. Servimos a los clientes que valoran la excelencia en sus
procesos a través de la implantación y operación de soluciones innovadoras
sostenibles en el largo plazo, que incorporan las mejores prácticas de negocio
y lo mejor de la tecnología de información”.
VISIÓN
“Ser socios de largo plazo en tecnologías de información de las compañías
más exitosas de la región, a través de nuestra habilidad reconocida para crear
alto valor, alineando la tecnología a las estrategias de negocio”.
OBJETIVOS ESTRATÉGICOS
Incrementar las ventas y reducir costos de proyectos mediante una mejor gestión de los
mismos.
Alcanzar los niveles de excelencia en la calidad de los servicios de tecnología de
información.
Mejorar el posicionamiento de la organización en el mercado competitivo de tecnologías
de información.
Liderar el sector financiero con relación a tecnologías de información.
Fortalecer el grado de fidelización de los clientes.
Promover el desarrollo personal y profesional de los trabajadores de la organización.
Los objetivos estratégicos deben estar alineados con los procesos de negocio de la
organización, los cuales se presentan en la siguiente figura. Cabe mencionar que la
clasificación de los mismos será debidamente fundamentada en el Capítulo 4: Arquitectura
Empresarial.
Figura 4 – Mapa de Procesos de la Organización
Fuente: Elaboración Propia
A continuación, se presenta la matriz de justificación de los objetivos estratégicos con
relación a los procesos de negocio de la organización previamente mostrados.
1
Procesos Estratégicos Procesos Tácticos Procesos
Operativos
Objetivos Estratégicos
Ges
tión d
e C
arte
ra
de
Pro
duct
os
y S
ervic
ios
Ges
tión C
om
erci
al
Ges
tión d
e P
royec
tos
Ges
tión d
e R
ecurs
os
Hum
anos
Ges
tión d
e In
frae
stru
ctura
e In
form
ació
n
Ges
tión d
e C
om
pra
s
Ges
tión A
dm
inis
trat
iva
Ges
tión d
e F
actu
raci
ón
Ges
tión
de
Ase
sorí
a L
egal
1. Incrementar las ventas y reducir costos de
proyectos mediante una mejor gestión de los mismos. X X X X
2. Alcanzar los niveles de excelencia en la calidad de
los servicios de tecnología de información. X X X X X
3. Mejorar el posicionamiento de la organización en el
mercado competitivo de tecnologías de información. X X X X X X X
4. Liderar el sector financiero con relación a
tecnologías de información. X X X
Procesos Estratégicos Procesos Tácticos Procesos
Operativos
Objetivos Estratégicos
Ges
tión d
e C
arte
ra
de
Pro
duct
os
y S
ervic
ios
Ges
tión C
om
erci
al
Ges
tión d
e P
royec
tos
Ges
tión d
e R
ecurs
os
Hum
anos
Ges
tión d
e In
frae
stru
ctura
e In
form
ació
n
Ges
tión d
e C
om
pra
s
Ges
tión A
dm
inis
trat
iva
Ges
tión d
e F
actu
raci
ón
Ges
tión
de
Ase
sorí
a L
egal
5. Fortalecer el grado de fidelización de los clientes. X X X X X X
6. Promover el desarrollo personal y profesional de
los trabajadores de la organización.
X X X X X X
Tabla 1 – Matriz de Objetivos Estratégicos vs. Procesos de Negocio
Fuente: Elaboración Propia
1
ORGANIGRAMA
Figura 5 – Organigrama de la empresa
Fuente: Área de Recursos Humanos
ALCANCE DEL PROYECTO
El alcance general del presente proyecto está orientado en el análisis y la elaboración de una
propuesta de Arquitectura Empresarial enfocado al proceso de Desarrollo y Mantenimiento
de software dentro de la empresa TSNET S.A.
El análisis a desarrollar contemplará:
La gestión del Recurso Profesional mediante el modelo propuesto por P-CMM.
La gestión de Servicios TI mediante la aplicación del marco de trabajo propuesto por
ITIL.
La evaluación de las arquitecturas de negocio y TI, y su alineamiento con los objetivos
estratégicos de la organización de acuerdo al marco de trabajo TOGAF.
OBJETIVOS DEL PROYECTO
OBJETIVO GENERAL
Elaborar una propuesta de Arquitectura Empresarial que permita la optimización del proceso
de Mantenimiento y Desarrollo de Software enfocado en los procesos estratégicos de la
organización.
OBJETIVOS ESPECÍFICOS
OE1: Analizar el contexto de la organización y validar el alineamiento existente entre
objetivos estratégicos y procesos de negocio.
OE2: Realizar el análisis de dos procesos estratégicos identificando los componentes que
conforman cada una de las dimensiones de Arquitectura Empresarial: Negocio,
Aplicaciones, Datos y Tecnología.
OE3: Elaborar un análisis de brechas entre la situación actual y esperada de los procesos
estratégicos abordados para así dimensionar el GAP entre ellos.
OE4: Optimizar el proceso de Mantenimiento y Desarrollo de Software mediante la
utilización de un aplicativo para la gestión de incidentes.
OE5: Medir, hacer seguimiento y asegurar la calidad del servicio brindado en función de
los niveles de acuerdo de servicio establecidos.
OE6: Realizar el análisis y redefinición de perfiles para cada uno de los roles
identificados dentro del proceso de Mantenimiento y Desarrollo de Software.
OE7: Elaborar un plan de desarrollo de capacidades que permita, a cada rol analizado en
el proceso de Mantenimiento y Desarrollo de Software, acercarse a la nueva definición
del perfil asociado y potenciar sus habilidades de autogestión.
OE8: Establecer métricas que permitan hacer seguimiento al desarrollo de las capacidades
de cada uno de los roles analizados, e implementar procedimientos que aseguren el
cumplimiento de las prácticas propuestas por P-CMM.
BENEFICIOS DEL PROYECTO
BENEFICIOS TANGIBLES
Lograr el desarrollo de habilidades blandas y duras en el 40% del personal.
Optimizar en un 25% la productividad del personal.
Reducir en un 30% la rotación del personal de manera que se disminuyan los costos de
reclutamiento.
Reducir en un 50% las pérdidas de talento humano.
Reducir en un 90% los tiempos muertos del personal.
Optimizar en un 90% los tiempos de respuesta en atención de requerimientos de acuerdo
al nivel de servicio establecido con los clientes.
Reducir en un 80% las correcciones de requerimientos devueltos por el cliente a causa de
errores o fallas de desarrollo.
Alcanzar la satisfacción del 90% de los clientes por los servicios prestados.
Cumplir en un 80% con los tiempos estimados en el desarrollo de proyectos.
Reducir en un 100% la información redundante para la toma de decisiones.
Reducir en un 100% la labor manual para la emisión de informes de costos de proyectos y
análisis de rentabilidad.
Cumplir en un 80% con la rentabilidad estimada de los proyectos.
BENEFICIOS INTANGIBLES
Identificación del personal con la organización.
Creación de ambientes de trabajo inspiradores.
Mejora en la comunicación y trabajo en equipo.
Mejora en la gestión del conocimiento al interior de la organización.
Incremento de productividad en áreas operativas y estratégicas de la organización.
Incremento de la calidad en el servicio de mantenimiento y desarrollo de software.
Satisfacción del cliente.
CAPITULO 2. LOS PROYECTOS SOFTWARE Y EL
RECURSO PROFESIONAL
INTRODUCCIÓN
El presente capítulo tiene como finalidad identificar el nivel de madurez del equipo tomando
como marco de trabajo el P-CMM. En este sentido, se realizará un análisis de atributos y de
los principales elementos de riesgos que conllevan a la pérdida del nivel de madurez en que
se encuentra la organización actualmente. Finalmente, se presentará la arquitectura del P-
CMM y la integración del PSP con el TSP para el equipo que conforma el proceso de
mantenimiento de software de la organización.
OBJETIVOS
Establecer un proceso formal que permita alinear y equilibrar de manera adecuada los
requerimientos técnicos de un perfil profesional con las habilidades y capacidades de las
personas que se presenten al proceso de reclutamiento de una organización. Para ello, se
propone implantar una estrategia de sostenimiento y mejora del nivel de madurez de la
organización.
IDENTIFICACIÓN DEL NIVEL DE MADUREZ DEL EQUIPO
El SEI14
ha desarrollado el P-CMM, una guía para implementar prácticas que continuamente
mejoran las capacidades de la fuerza de trabajo de una organización.
Además, esta guía cuenta con cinco niveles de madurez los cuales son evolutivos y
complementarios con los niveles anteriores. De esta manera, la organización puede evitar
introducir alguna práctica para la cual su personal no esté debidamente preparado para
implementar.
A continuación, se presentan las características de cada uno de los cinco niveles. A partir
estas definiciones se identificará el nivel de madurez del objeto de estudio TSNET S.A.
Nivel 1 – Inicial: La organización no cuenta con documentación, políticas, y las prácticas
son inconsistentes y/o no están formalizadas.
Nivel 2 – Gestionado: Se establecen los perfiles del puesto.
Nivel 3 – Definido: Se analizan las competencias que posee cada persona respecto al
perfil del puesto de trabajo y se evalúan los gaps.
Nivel 4 – Predecible: Se asocia al desarrollo de las habilidades. Ayuda a pronosticar lo
que puede ocurrir para evitar la pérdida de la competitividad de la fuerza de trabajo.
Nivel 5 – Optimizado: Gestión del cambio para la mejora continua.
14 Software Engineering Institute, http://www.sei.cmu.edu/
Figura 6 – Niveles de Madurez del P-CMM
Fuente: People Capability Maturity Model Version 2.0
Luego de presentar las características de cada nivel de madurez, se puede determinar que el
nivel de madurez del objeto de estudio TSNET S.A. corresponde al nivel 1 – Inicial. Ello se
debe a que la organización tiene serias dificultades para mantener a sus talentos fidelizados,
de manera que se proyecten a desarrollar una línea de carrera dentro de la organización.
Muchas veces, a pesar de darle valor al personal, las prácticas establecidas por la
organización son inconsistentes o simplemente no se cuenta con la presencia de personal que
pueda ejecutarlas, evaluarlas y mejorarlas.
8
IDENTIFICACIÓN DE ATRIBUTOS
A continuación, se presenta un diagrama de actividades con los atributos asociados al objeto de estudio TSNET S.A.
Figura 7 – Diagrama de Actividades del Objeto de Estudio
Fuente: Elaboración propia
9
Jefe de Proyecto: Responsable de crear las condiciones adecuadas para un trabajo
eficiente en equipo, con la finalidad de alcanzar los objetivos y mantener una buena
comunicación en todos los niveles de la organización. Además, garantiza las exigencias
de calidad, tiempos y costos.
Consultor Senior: Responsable de definir las especificaciones técnicas con detalle y
contribuir directamente a la creación y/o modificación de sistemas de software.
Asimismo, garantiza que los resultados respondan a los requisitos tanto técnicos como
funcionales. Finalmente, se hace cargo de la producción de la documentación para el
usuario final.
Desarrollador: Responsable de participar de manera activa en los proyectos de desarrollo,
especialmente en la definición del modelo de datos, control y optimización de
prestaciones de base de datos, y en el soporte para satisfacer las exigencias de extracción
y análisis de datos.
ELEMENTOS DE RIESGO Y PROBLEMAS
Los procesos de mejora exitosos deben contar con una adecuada planificación, correcta
asignación de responsabilidades, y seguimiento continuo a los logros alcanzados para
asegurar la permanencia en un nivel de madurez.
Sin embargo, dentro de cualquier organización existen elementos que ponen en riesgo la
estabilidad de un determinado nivel de madurez, llegando muchas a perderlo por completo.
Los principales elementos de riesgo identificados son:
Falta de soporte gerencial: Cuando la gerencia de la organización no se involucra con los
objetivos de un proceso de mejora del personal.
Desconocimiento de la problemática laboral: Cuando la organización está más enfocada
en generar rentabilidad que no se da cuenta de los problemas alrededor de su fuerza de
trabajo. Además, si no se cuenta con la participación de al menos una persona de cada
unidad de la organización para que exponga la problemática de su equipo de trabajo, no
se pueden evidenciar dichas dificultades y el grado de criticidad de las mismas.
Conformismo con el nivel de madurez 3 - Definido: Cuando las organizaciones deciden
poner fin al crecimiento de su madurez en el nivel 3 porque creen haber alcanzado un
estado operativo estable luego de haber definido las competencias de su personal. Sin
embargo, ni este ni ningún otro nivel es estable ya que sin la constante y debida
actualización de las competencias del personal, éstas quedarán obsoletas y sin uso durante
el desarrollo de sus actividades diarias.
Fiebre del nivel de madurez: Cuando llegar a un determinado nivel de madurez se vuelve
más importante que lograr las mejoras de las prácticas de manera consciente. En
consecuencia, preparar una evaluación formal se vuelve más importante que asegurar que
las prácticas implementadas actualmente en la organización tengan resultados
significativos.
Salto de nivel de madurez: Cuando algunas organizaciones tratan de pasar a niveles de
madurez superiores mediante la implementación de políticas y fortalecimiento de
prácticas sin construir una buena infraestructura o cumplir con las prácticas de los niveles
de madurez inferiores. Por ejemplo, una organización que trate de implementar un
esquema de compensación que relacione bonos a favor del personal con resultados del
negocio. Si no existe un fundamento o base de dicho esquema que sea medible de acuerdo
al cumplimiento de objetivos, retroalimentación y comunicación, el esquema corre el
riesgo de fallar.
Descarte de áreas de proceso: Cuando las organizaciones se encuentran con áreas de
proceso difíciles de implementar y las descartan de manera precipitada. Todas las áreas de
proceso deberían considerarse relevantes en un proceso de mejora, salvo que no se
encuentre una aplicación apropiada para ninguna de las prácticas de dicha área de
proceso. Por lo tanto, ignorar un área de proceso puede poner en riesgo la efectividad de
otras áreas de proceso de madurez superiores al eliminar prácticas que pueden ser
fundamentales o críticas.
Implementación de prácticas obviando la secuencia del nivel de madurez: Cuando las
organizaciones deciden implementar prácticas de un nivel de madurez mayor a aquel en
el que actualmente se encuentra la organización. El modelo P-CMM no restringe un orden
de implementación de prácticas; no obstante, la organización debe considerar los riesgos
y hacerse responsable por la ausencia de prácticas de niveles inferiores.
Para evaluar dichos elementos de riesgo, se emplea la matriz de probabilidad e impacto
definida por el PMBOK.
Figura 8 – Matriz de Probabilidad e Impacto
Fuente: Guía del PMBOK
Donde las escalas para la probabilidad e impacto son:
Escala Relativa Probabilidad Escala Relativa Impacto
Nada probable 0.10 Muy bajo 0.05
Poco probable 0.30 Bajo 0.10
Medianamente probable 0.50 Moderado 0.20
Bastante probable 0.70 Alto 0.40
Muy probable 0.90 Muy alto 0.80
Tabla 2 – Escalas de Probabilidad e Impacto
Fuente: Guía del PMBOK
A continuación, se presenta la matriz de riesgos identificados para la implementación del
proyecto, donde la columna Resultado define la prioridad de atención de acuerdo a los
siguientes colores:
Figura 9 – Importancia de los Riesgos
Fuente: Guía del PMBOK
Matriz de Elementos de Riesgo
N° Elemento de
Riesgo
Probab. Impacto Resultado Estrategia de mitigación
1 Falta de soporte
gerencial 0.50 0.40 0.20
Concientizar a la gerencia sobre la
necesidad de mejorar el desempeño laboral
mediante la implementación de un modelo
de madurez de capacidades del personal.
2
Desconocimient
o de la
problemática
laboral
0.30 0.40 0.12
Formar un comité, con la participación de
un representante de cada unidad de la
organización, para identificar y evaluar los
problemas de la fuerza de trabajo.
3
Conformismos
con el nivel de
madurez 3 -
Definido
0.30 0.40 0.12
Evaluar de manera continua las
competencias del personal para verificar el
cumplimiento de las prácticas de dicho
nivel.
4 Fiebre del nivel
de madurez 0.50 0.40 0.20
Revisar el propósito, objetivos, prácticas y
compromisos de un nivel de madurez para
determinar si se cumplen. Caso contrario,
no se puede aspirar a dicho nivel.
5 Salto de nivel de
madurez 0.30 0.40 0.12
Evidenciar el cumplimiento de todos los
requisitos de un determinado nivel de
madurez antes de pasar al siguiente.
6 Descarte de
áreas de proceso 0.70 0.40 0.28
Mejorar la implementación de las áreas de
proceso de manera que se evalúen a detalle
antes de tomar una decisión precipitada.
7 Implementación
0.70 0.40 0.28 Respetar el orden de implementación de las
Matriz de Elementos de Riesgo
N° Elemento de
Riesgo
Probab. Impacto Resultado Estrategia de mitigación
de prácticas
obviando la
secuencia del
nivel de madurez
prácticas de acuerdo al nivel de madurez de
la organización.
Tabla 3 – Matriz de Elementos de Riesgo del Nivel de Madurez
Fuente: Elaboración propia
A partir de la identificación y comprensión del impacto de cada uno de los elementos de
riesgo, se propone un proceso que impida la pérdida del nivel de madurez de la organización
objeto de estudio TSNET S.A.
Este proceso propuesto se basa en el modelo “IDEAL” desarrollado por el SEI (Software
Engineering Institute), que a su vez se basa en el P-CMM. Cabe mencionar que este modelo
presenta un ciclo de vida comprendido por cinco fases incrementales dependientes cada una
de la anterior.
1. Inicialización: Se busca el apoyo de la alta gerencia y se constituye un equipo de acción
conformado por un representante de cada unidad de la organización y personal que
evaluará la problemática en el entorno laboral.
Es indispensable que se tenga asegurada la participación y compromiso de la alta gerencia
para dar inicio al programa de mejora. Además, cabe resaltar que el equipo de acción debe
contar con la participación del área de recursos humanos como del área de desarrollo de
software, ya que ambas se complementan para la propuesta de mejoras de la gestión del
personal de acuerdo a la evaluación de sus habilidades personales y capacidades técnicas.
Una vez asegurada la participación y compromiso de la alta gerencia, se procede a
agendar reuniones para que el equipo de acción tome conocimiento de los problemas
manifestados por los representantes de cada unidad de la organización. Asimismo, se
presenta a la alta gerencia los beneficios de los programas de mejora basados en P-CMM,
se define el esfuerzo avalado por un plan de trabajo, y se establecen las responsabilidades
de cada participante del equipo de acción.
Representante Unidad SAP
RepresentanteUnidad Oracle
Representante Unidad Microsoft
Representante Recursos Humanos
TSNET
Equipo de AcciónAlta Gerencia Apoya
Conformado por
Figura 1 – Fase de Inicialización del modelo IDEAL
Fuente: Elaboración propia
2. Diagnóstico: El equipo de acción junto con los representantes de cada unidad de la
organización, identifica los problemas a ser resueltos.
3. Establecimiento: El equipo de acción selecciona algunos de los problemas más críticos,
los prioriza, y lo valida con la alta gerencia para proceder a desarrollar un plan de acción.
El desarrollo y seguimiento de un plan de acción es uno de los factores que distingue a un
equipo de acción.
4. Acción: Por lo general, las prácticas que han sido definidas deben ser probadas antes de
ser implementadas en la organización para asegurar que funcionan según lo esperado.
Luego de ello, pueden ser puestas en marcha, documentadas y difundidas formalmente a
toda la organización.
5. Levantamiento: El equipo de acción evalúa las lecciones aprendidas respecto al desarrollo
e implementación de mejoras, e inician la planificación de la siguiente implementación
del ciclo IDEAL para aplicar una nueva ronda de mejoras.
Figura 11 – Modelo IDEAL
Fuente: People Capability Maturity Model Version 2.0
ARQUITECTURA DE PERSONAL
Los componentes de la estructura del P-CMM son:
Niveles de madurez: Establecen fundamentos para mejorar continuamente el talento,
desarrollar una fuerza de trabajo efectiva, y gestionar de manera exitosa el capital humano
de una organización. Cada nivel de madurez está compuesto por varias áreas de proceso
que, a su vez, contienen objetivos.
Áreas de proceso: Grupo de prácticas que, al ejecutarse de manera colectiva, satisfacen un
grupo de objetivos de un determinado nivel de madurez. Las áreas de proceso identifican
las capacidades que deben ser institucionalizadas para alcanzar un nivel de madurez, y las
prácticas que una organización debe implementar para mejorar la capacidad de su fuerza
de trabajo.
En total existen 22 áreas de proceso entre los 5 niveles de madurez, a excepción del nivel
1 (Inicial). Cada área de proceso ha sido definida para existir en un solo nivel de madurez.
Objetivos: Son los requerimientos que una organización debe lograr al implementar la
prácticas de la fuerza de trabajo dentro de un área de proceso. En conjunto indican el
alcance, los límites, y el propósito del área de proceso.
Cuando los objetivos de todas las áreas de proceso de un nivel de madurez han sido
alcanzados, la organización habrá logrado el nivel de madurez correspondiente y habrá
establecido un nuevo nivel de capacidad en la gestión de su fuerza de trabajo.
Prácticas: Constituyen las actividades esperadas para resultar en el logro de objetivos de
un área de proceso. Además, describen los elementos de infraestructura y fuerza de
trabajo que contribuyen a la exitosa implementación e institucionalización de su área de
proceso.
A continuación, se mencionan algunas de las prácticas sugeridas por P-CMM para las
áreas de proceso del Nivel 2 – Gestionado:
Área de Proceso Staffing
- Los individuos planifican y coordinan las actividades del personal de acuerdo a
políticas documentadas y procedimientos.
- Cada unidad analiza su trabajo propuesto para determinar el esfuerzo y habilidades
requeridas.
- Individuos y grupos de trabajo se hacen responsables del desempeño de su trabajo.
Área de Proceso Comunicación y Coordinación
- La información requerida para llevar a cabo el trabajo es compartida entre las
unidades involucradas a tiempo.
- Las opiniones de los individuos son vistas en eventos periódicos.
- Se desarrollan habilidades comunicativas requeridas para establecer y mantener
relaciones de trabajo efectivas dentro y fuera de los grupos de trabajo.
Área de Proceso Ambiente de Trabajo
- El ambiente físico y recursos requeridos para desarrollar el trabajo son identificados
en cada unidad.
- Con las mejoras en el ambiente de trabajo se mejora la performance del personal.
- Se provee el ambiente físico requerido para desarrollar el trabajo asignado.
Figura 12 – Áreas de Proceso del P-CMM
Fuente: People Capability Maturity Model Version 2.0
Figura 13 – Estructura del P-CMM
Fuente: People Capability Maturity Model Version 2.0
En la figura 13 se muestra la relación entre los componentes del P-CMM. Como resultado se
obtiene la capacidad organizacional la cual describe el nivel de conocimiento, habilidades y
capacidades de la fuerza de trabajo de la organización.
Dado que el nivel de madurez actual del objeto de estudio TSNET S.A. es el nivel 1 - Inicial,
se pretende alcanzar el siguiente nivel 2 – Gestionado para lo cual se analizarán cada una de
las prácticas de las tres primeras áreas de proceso de dicho nivel.
Para aquellas prácticas que no se cumplan actualmente, se propone un plan de acción para
alcanzar el logro de las mismas. De esta manera, se podrá asegurar su correcto cumplimiento
para avanzar al siguiente nivel de madurez.
21
1. Personal: Su propósito es establecer un proceso formal mediante el cual los recursos calificados sean reclutados, seleccionados y asignados a
un determinado puesto de trabajo.
Objetivo 1: Los grupos de trabajo deben comprometerse a equilibrar la carga de trabajo con el personal adecuado.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
P1. Los individuos planifican y coordinan las
actividades del personal de acuerdo a
políticas documentadas y procedimientos.
SI No aplica. Se maneja un cuadro de asignación del
personal en el que se detalla el periodo de
participación de los recursos en los
proyectos.
Se emplea un plan de trabajo para dar
seguimiento al cumplimiento de las
actividades del proyecto.
P2. Cada unidad analiza su trabajo propuesto
para determinar el esfuerzo y habilidades
requeridas.
SI No aplica.
P3. Individuos y grupos de trabajo se hacen
responsables del desempeño de su trabajo. SI No aplica.
P4. Cada unidad elabora compromisos de
trabajo que equilibren su carga laboral con el
personal disponible y otros recursos
requeridos.
NO
Dimensionar la carga laboral de acuerdo a las
actividades proyectadas por cada persona. De
manera que si se evidencia que no se va a
poder cumplir con los plazos de una actividad,
Las Líneas de Negocio manejan su propio
staff de consultores, los cuales no son
compartidos en algunos casos para dar
apoyo a otras Líneas.
Objetivo 1: Los grupos de trabajo deben comprometerse a equilibrar la carga de trabajo con el personal adecuado.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
se pueda tomar como plan de acción la
asignación de un recurso de apoyo.
Tabla 4 – Mapeo de Prácticas y Objetivos del Área de Proceso de Personal – Objetivo 1
Fuente: Elaboración propia
Objetivo 2: Seleccionar personal para las posiciones abiertas en la organización.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
P6. Las posiciones abiertas dentro de una
unidad son analizadas, documentadas y
aprobadas.
NO
Elaborar un procedimiento junto con recursos
humanos para documentar los requerimientos
de las posiciones abiertas e identificar las
habilidades críticas de cada una. De esta
No se cuenta con una definición formal y
documentada de los perfiles requeridos en
la organiación.
Objetivo 2: Seleccionar personal para las posiciones abiertas en la organización.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
manera, en una siguiente convocatoria se toma
como material de consulta.
P7. Las posiciones abiertas son difundidas
dentro de la organización. SI No aplica.
Las posiciones abiertas son comunicadas
en la intranet de la organización para
conocimiento de todo el personal.
P8. Unidades con posiciones abiertas reclutan
individuos calificados. SI No aplica.
El proceso de reclutamiento está basado
principalmente en la evaluación de
habilidades duras, y en menor grado de
habilidades blandas.
P9. Las actividades de reclutamiento externo
son planificadas y coordinadas con los
requerimientos de cada unidad.
SI No aplica.
El proceso de reclutamiento se da en
función de los proyectos solicitados por el
cliente.
Tabla 5 – Mapeo de Prácticas y Objetivos del Área de Proceso de Personal – Objetivo 2
Fuente: Elaboración propia
Objetivo 3: Las asignaciones de trabajo están basadas en una evaluación de calificaciones y otros criterios válidos.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
P10. Un proceso de selección y criterios de
selección apropiados son definidos para cada
posición abierta.
NO Redefinir y documentar los perfiles del
personal de acuerdo al rol requerido.
No se cuenta con una definición formal y
documentada de los perfiles requeridos en
la organiación.
P11. Cada unidad, junto con recursos
humanos, encamina un proceso de selección
para cada posición que pretende ocupar.
NO
Involucrar al área de recursos humanos en el
proceso de reclutamiento de personal para que
compartan sus conocimientos de la gestión del
recurso humano.
Cada Línea de Negocio es la encargada de
realizar su propio proceso de
reclutamiento y selección de personal, sin
involucrar al área de Recursos Humanos.
P12. Las posiciones son ofrecidas al
candidato cuyas habilidades y calificaciones
calcen mejor con la posición abierta.
SI No aplica.
Se realiza una evaluación de personal de
acuerdo a las características del rol. Sin
embargo, no se cuenta con una
documentación de dicho proceso de
evaluación.
P15. Miembros representantes de una unidad
participan en las actividades de su personal. SI No aplica.
Se realizan actividades de integración que
involucran a todo el personal de la
organización con la finalidad de fomentar
Objetivo 3: Las asignaciones de trabajo están basadas en una evaluación de calificaciones y otros criterios válidos.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
la confraternidad de las áreas.
Tabla 6 – Mapeo de Prácticas y Objetivos del Área de Proceso de Personal – Objetivo 3
Fuente: Elaboración propia
Objetivo 4: El personal es colocado y rotado de posiciones de manera ordenada.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
P5. Las asignaciones de trabajo equilibran el
trabajo entre individuos y unidades. SI No aplica.
Antes de realizar las asignaciones del
personal a los proyectos, se validan sus
capacidades para garantizar un mejor
desempeño de actividades.
P13. La organización actúa de manera
oportuna para conseguir al candidato NO
Gestionar un procedimiento de requerimiento
de talentos de manera anticipada, con la
Actualmente, el proceso de reclutamiento
de personal se da a puertas del inicio de
Objetivo 4: El personal es colocado y rotado de posiciones de manera ordenada.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
seleccionado. finalidad de contar con la asignación de
recursos de manera oportuna.
los proyectos, por lo que muchas veces no
se cuenta con la disponibilidad del
personal a tiempo.
P14. El candidato seleccionado es inducido
en la nueva posición. NO
Implementar un proceso de inducción de
personal que permita presentar un panorama de
la cultura de la organización, de manera que se
formen lazos de fidelidad con la organización.
El personal contratado es asignado
directamente a los proyectos.
P17. Descargos por insatisfacción de
desempeño u otras razones válidas son
ejecutadas de acuerdo a las políticas y
procedimientos de la organización.
SI No aplica.
Existe un canal de comunicación directo
entre el personal y los jefes inmediatos
superiores.
P18. Causas de renuncia voluntaria son
identificadas y direccionadas. NO
Llevar un control de las inconformidades
expuestas por el personal que influyen en su
salida de la organización.
No existe un plan de mitigación de riesgos
asociado a las inconformidades
presentadas por el personal. Asimismo, no
existe un repositorio que almacene los
motivos y/o causas de renuncia del
Objetivo 4: El personal es colocado y rotado de posiciones de manera ordenada.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
personal
Tabla 7 – Mapeo de Prácticas y Objetivos del Área de Proceso de Personal – Objetivo 4
Fuente: Elaboración propia
2. Comunicación y Coordinación: Su propósito es asegurar la comunicación a tiempo dentro de la organización y, además, que la fuerza de
trabajo tenga las habilidades para compartir información y coordinar sus actividades de manera eficiente.
Objetivo 1: La información es compartida dentro de la organización.
Prácticas Cumple Plan de Acción para cumplir la práctica Evidencia
P1. Las políticas y prácticas de la
organización son comunicadas a la fuerza de
trabajo.
NO
Documentar y difundir las políticas, valores,
metas y buenas prácticas a toda la
organización, sobretodo haciendo incapié
El personal no tiene conocimiento de las
políticas y prácticas de la organización.
Objetivo 1: La información es compartida dentro de la organización.
Prácticas Cumple Plan de Acción para cumplir la práctica Evidencia
P2. La información sobre los valores de la
organización, eventos y condiciones son
comunicados a la fuerza de trabajo.
cuando se logra alcanzar nuevas prácticas que
constituyen un logro para la organización.
P3. La información requerida para llevar a
cabo el trabajo es compartida entre las
unidades involucradas a tiempo.
SI No aplica. Existe un directorio centralizado para la
gestión de documentos de los proyectos.
Tabla 8 – Mapeo de Prácticas y Objetivos del Área de Comunicación y Coordinación – Objetivo 1
Fuente: Elaboración propia
Objetivo 2: La información es compartida dentro de la organización.
Prácticas Cumple Plan de Acción para cumplir la práctica Evidencia
P4. Las opiniones de los individuos son vistas
en eventos periódicos. SI No aplica.
Una vez al año se da una reunión para la
presentación de resultados del ejercicio
Objetivo 2: La información es compartida dentro de la organización.
Prácticas Cumple Plan de Acción para cumplir la práctica Evidencia
P5. Individuos o grupos pueden expresar sus
preocupaciones de acuerdo a un
procedimiento documentado.
NO
Estandarizar y formalizar un procedimiento
documentado para dar a conocer las
inquietudes del personal.
anterior, así como el plan a seguir para el
año en curso. En dicho evento se da
oportunidad al personal para expresar sus
inquietudes y opiniones sobre diversos
aspectos de la organización de manera
verbal.
P6. Seguimiento a las actividades
relacionadas a la resoluciones de
preocupaciones.
NO
Tomando como partida el plan de acción del
P5, se puede contar con una herramienta de
consulta para dar seguimiento al estado de una
preocupación reportada.
El personal sigue reportando inquietudes
expresadas con anterioridad.
Tabla 9 – Mapeo de Prácticas y Objetivos del Área de Comunicación y Coordinación – Objetivo 2
Fuente: Elaboración propia
Objetivo 3: Individuos y grupos de trabajo coordinan sus actividades para cumplir con su trabajo.
Prácticas Cumple Plan de Acción para cumplir la práctica Evidencia
P7. Se desarrollan habilidades comunicativas
requeridas para establecer y mantener
relaciones de trabajo efectivas dentro y fuera
de los grupos de trabajo.
NO Implementar talleres que permitan desarrollar
la capacidad de comunicación del personal.
Existe personal que no se desenvuelve
adecuadamente (introversión, inseguridad,
timidez) dentro de sus equipos de trabajo.
P8. Se maneja de manera apropiada los
problemas o conflictos interpersonales que
degradan la calidad de las relaciones de
trabajo.
NO
Desarrollar talleres de apoyo al personal para
tener conocimiento de los problemas que
pueden atacarlo y, por consiguiente, lo lleven a
reducir su nivel de desempeño en el ámbito
profesional y personal.
De vez en cuando se presentan bajas
injustificadas en el desempeño del
personal.
P9. Individuos y grupos de trabajo coordinan
sus actividades para cumplir con su trabajo. SI No aplica.
Cumplimiento del cronograma de trabajo
dentro de los tiempos establecidos. P10. Individuos y grupos de trabajo
monitorean y coordinan las dependencias
involucradas en su trabajo.
SI No aplica.
Tabla 10 – Mapeo de Prácticas y Objetivos del Área de Proceso de Comunicación y Coordinación – Objetivo 3
Fuente: Elaboración propia
3. Ambiente de Trabajo: Su propósito es establecer condiciones de trabajo físicas y proveer recursos que permitan a los individuos y grupos de
trabajo desarrollar sus tareas de manera eficiente y sin distracciones innecesarias.
Objetivo 1: Disponer de un ambiente físico y recursos requeridos por la fuerza de trabajo para desarrollar sus actividades.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
P1. El ambiente físico y recursos requeridos
para desarrollar el trabajo son identificados
en cada unidad.
SI No aplica.
Conformidad por parte del personal
respecto a los recursos asignados y
ubicación física de trabajo.
P2. Se provee el ambiente físico requerido
para desarrollar el trabajo asignado. SI No aplica.
P3. Espacios de trabajo proveen un
ambiente de trabajo adecuado para el
desarrollo del mismo.
SI No aplica.
P4. Los recursos requeridos para cumplir
con el trabajo están disponibles a tiempo. SI No aplica.
P5. Con las mejoras en el ambiente de
trabajo se mejora la performance del SI No aplica.
Objetivo 1: Disponer de un ambiente físico y recursos requeridos por la fuerza de trabajo para desarrollar sus actividades.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
personal.
Tabla 11 – Mapeo de Prácticas y Objetivos del Área de Proceso de Ambiente de Trabajo – Objetivo 1
Fuente: Elaboración propia
Objetivo 3: Minimizar las distracciones en el ambiente de trabajo.
Prácticas Cumple Plan de Acción para cumplir a futuro con la
práctica Evidencia
P6. Factores ambientales que degraden o
pongan en peligro la salud o seguridad de la
fuerza de trabajo son identificados y
corregidos.
SI No aplica. Se cuentan con la aprobación de Defensa
Civil en materia de seguridad.
P7. Factores físicos que degraden la SI No aplica.
Objetivo 3: Minimizar las distracciones en el ambiente de trabajo.
efectividad del ambiente de trabajo son
identificados y direccionados.
P8. Fuentes de interrupción frecuente o
distracciones que degraden la efectividad
del ambiente de trabajo son identificadas y
minimizadas.
NO
Identificar, documentar y difundir a toda la
organización los elementos que ponen en riesgo
la efectividad del ambiente de trabajo. Por
ejemplo: Exceso de llamadas telefónicas y
reuniones, constante sociabilización, tareas
administrativas innecesarias, entre otros.
Incumplimiento de actividades, no se
localiza al personal en su ubicación de
trabajo, entre otros.
Tabla 12 – Mapeo de Prácticas y Objetivos del Área de Proceso de Ambiente de Trabajo – Objetivo 3
Fuente: Elaboración propia
Cabe resaltar que el último objetivo de cada área de proceso del P-CMM no está relacionado a ninguna práctica. Ello se debe a que el último
objetivo está relacionado directamente a los compromisos, habilidades, métricas y verificación de los resultados de las prácticas detalladas en
cada área de proceso.
34
TSP y PSP
De acuerdo al análisis realizado al servicio de Outsourcing ofrecido por la empresa TSNET
S.A., se identificaron 3 roles sobre los que se enfocaría la aplicación de los estándares PSP y
TSP. Estos son: Jefe de Proyectos, Consultor Senior y Desarrollador.
A continuación, se presenta cada una de las actividades que se requieren implementar para
asegurar la base sobre la que se desarrollaran los estándares PSP y TSP.
Aplicación del Estándar PSP:
Teniendo en consideración que al ser TSNET S.A. una empresa dedicada a la consultoría de
sistemas, su principal activo es el recurso humano. Por ello, se propone un listado de
habilidades y capacidades necesarias que permitan identificar y reclutar el personal idóneo
para cada uno de los roles identificados en el servicio de Outsourcing.
A continuación, se presentan el conjunto de habilidades blandas y duras, inteligencias y el
nivel dentro de la Taxonomía de Bloom requerido para cada perfil, que permitirá identificar
el GAP entre la situación actual y la deseada.
35
Habilidades Blandas:
Habilidades Blandas
Situación Actual (AS IS) Situación Objetivo (TO BE)
Jefe de
Proyecto
Consultor
Senior Desarrollador
Jefe de
Proyecto
Consultor
Senior Desarrollador
Comunicación Asertiva 2 2 2 3 3 2
Determinación de metas 2 1 1 3 2 2
Escucha activa 2 3 3 3 3 3
Respeto a las opiniones 2 3 3 3 3 3
Sociabilidad 2 2 2 3 3 2
Empatía 1 3 2 3 3 2
Trabajo en equipo 2 3 3 3 3 3
Capacidad para resolver problemas 2 3 3 3 3 2
Proactividad 2 2 3 3 3 3
Capacidad de redacción 2 3 2 3 3 3
Capacidad de análisis 2 3 3 3 3 3
Seguridad Personal 1 2 2 3 3 2
Tolerancia a la presión 1 2 3 3 2 2
Orden 3 2 2 3 3 3
Habilidades Blandas
Situación Actual (AS IS) Situación Objetivo (TO BE)
Jefe de
Proyecto
Consultor
Senior Desarrollador
Jefe de
Proyecto
Consultor
Senior Desarrollador
Liderazgo 1 2 1 3 3 2
(Leyenda: 1 = Básico, 2 = Intermedio, 3 = Avanzado)
Tabla 13 – Matriz de Habilidades Blandas vs. Roles
Fuente: Elaboración propia
37
La descripción para cada una de las habilidades blandas listadas en la tabla anterior se
describe de la siguiente manera:
- Comunicación Asertiva: Habilidad para poder transmitir y recibir mensajes de manera
oportuna respetando la posición propia y de los involucrados.
- Determinación de metas: Habilidad dirigida al compromiso y a la búsqueda del logro
de resultados.
- Escucha activa: Habilidad para atender y entender el mensaje desde la posición del
comunicador.
- Respeto a las opiniones: Habilidad para establecer y mantener un entorno de
entendimiento y armonía en el marco de un intercambio de ideas sobre un hecho
puntual.
- Sociabilidad: Habilidad para cultivar relaciones interpersonales que comparten
intereses mutuos y/o ideas encaminadas hacia un fin común.
- Empatía: Habilidad que permite conocer y comprender los sentimientos de las
personas que nos rodean, centrando nuestra atención en estas últimas.
- Trabajo en equipo: Habilidad que permite establecer sinergia de esfuerzos para la
búsqueda y alcance de un objetivo en común.
- Capacidad para resolver problemas: Habilidad que permite identificar y entender
conflictos de manera tal que la determinación de la solución sea la más óptima y
oportuna posible.
- Proactividad: Actitud que permite tomar el control de situaciones de manera activa,
tomando iniciativa en el desarrollo de actividades para la generación de mejoras.
- Capacidad de redacción: Habilidad para plasmar ideas de carácter técnico en términos
que puedan ser entendidos e interpretados.
- Capacidad de análisis: Habilidad para poder identificar, examinar y plantear
soluciones a situaciones complejas.
- Seguridad personal: Habilidad de generar autoconfianza frente a situaciones de
carácter complejo o dubitativo.
- Tolerancia a la presión: Capacidad de poder desempeñar el trabajo encargado de
manera eficiente y eficaz en condiciones adversas.
- Orden: Capacidad de mantener objetos de manera organizada con la finalidad de
poder hacer seguimiento de ellos.
- Liderazgo: Capacidad de dirigir equipos de trabajo, potenciando sus habilidades y
desarrollando sus competencias, orientándolos hacia el alcance de un bien común.
Habilidades Blandas tales como: Ética y responsabilidad, no se listaron por considerarse
inherentes al rol.
39
Habilidades Duras:
Habilidades Duras
Situación Actual (AS IS) Situación Objetivo (TO BE)
Jefe de
Proyecto
Consultor
Senior Desarrollador
Jefe de
Proyecto
Consultor
Senior Desarrollador
Organización y Planificación 2 2 2 3 2 1
Negociación y Habilidades Comerciales 2 1 1 3 2 1
Dirección de equipos de trabajo 2 2 2 3 2 1
Pensamiento Analítico 2 2 2 3 2 2
Diagnóstico 2 2 2 3 3 2
Diseño 2 2 2 2 3 3
Implementación 2 2 2 3 2 2
(Leyenda: 1 = Básico, 2 = Intermedio, 3 = Avanzado)
Tabla 14 – Matriz de Habilidades Duras vs. Roles
Fuente: Elaboración propia
40
La descripción para cada una de las habilidades duras listadas en la tabla anterior se describe
de la siguiente manera:
- Organización y Planificación: Capacidad de reconocer eficazmente los objetivos a
alcanzar. Planificándose, determinando prioridades y los recursos necesarios. Incluye
también la capacidad de distribuir correctamente su tiempo para cumplir con las
diferentes tareas. Implica la implementación de mecanismos de seguimiento y
verificación. Así como la capacidad de anticiparse elaborando planes de contingencia.
- Negociación y Habilidades Comerciales: Capacidad para generar un ambiente de
colaboración que permita llegar a acuerdos Comerciales duraderos a través del
intercambio de información, debate de ideas y utilización de estrategias efectivas con
personas o grupos de intereses diversos, diferentes a los nuestros o incluso
contrapuestos.
- Dirección de equipos de trabajo: Capacidad de desarrollar, consolidar y conducir un
equipo alentando a sus miembros a trabajar con autonomía y responsabilidad.
- Pensamiento Analítico: Capacidad de entender una situación, dividiéndola en
pequeñas partes o identificando paso a paso sus implicaciones. Incluye la
organización sistemática de las partes de un problema o situación, la comparación
entre diferentes elementos o aspectos, y el establecimiento racional de prioridades.
También incluye la sucesión de hechos en una secuencia y las relaciones causa –
efecto de los hechos.
- Diagnóstico: Está asociado a la capacidad de análisis de las personas para la
identificación de la naturaleza o esencia de una situación o problema y de su posible
causa, es el análisis de la naturaleza de algo.
- Diseño: Está relacionado a la capacidad de definir la arquitectura de hardware y
software, componentes, módulos y datos para satisfacer los requerimientos.
- Implementación: Está relacionado a la capacidad de una persona para llevar a cabo la
ejecución de un plan, idea, modelo, especificación o programa.
Inteligencias:
Inteligencias
Situación Actual (AS IS) Situación Objetivo (TO BE)
Jefe de
Proyecto
Consultor
Senior Desarrollador
Jefe de
Proyecto
Consultor
Senior Desarrollador
Social 2 2 2 3 3 2
Verbal 2 2 2 3 3 2
Personal 2 2 2 3 3 3
Creativa 1 2 2 2 3 2
(Leyenda: 1 = Básico, 2 = Intermedio, 3 = Avanzado)
Tabla 15 – Matriz de Inteligencias vs Roles
Fuente: Elaboración propia
La descripción de cada una de las inteligencias listadas en la tabla anterior se describe a
continuación:
- Social: Talento para trabajar de manera colaborativa con los integrantes de su equipo
de trabajo garantizando y promoviendo la armonía dentro de éste.
- Verbal: Talento de expresar ideas e inquietudes de una manera asertiva, clara y
precisa.
- Personal: Capacidad de demostrar seguridad y confianza de sí mismo, así como de
mantener el control de las emociones para evitar que estas interfieran en el normal
desempeño de actividades.
- Creativa: Capacidad de detectar, proponer y promover opciones de mejora,
mantenimientos preventivos y/o correctivos en los servicios ofrecidos por la
compañía a fin de buscar colmar las expectativas de los clientes.
Nivel requerido de acuerdo a la Taxonomía de Bloom:
En los siguientes cuadros se presenta, de acuerdo a los niveles de la Taxonomía de Bloom,
cada una de las condiciones que se deben cumplir para los roles identificados:
43
- Jefe de Proyectos:
Nivel Descripción de Actividades Habilidades Blandas
Conocimiento Experiencia en Gestión de Proyectos y Gestión de Personal.
Comunicación Asertiva.
Determinación de metas.
Escucha activa.
Sociabilidad.
Empatía.
Respeto a las opiniones.
Trabajo en equipo.
Capacidad para resolver
problemas.
Capacidad de análisis.
Liderazgo.
Comprensión
Creación de condiciones adecuadas para un trabajo eficiente de equipo, con la finalidad
de alcanzar los objetivos y mantener una eficiente comunicación a todos los niveles.
Analiza y planea la ejecución de proyectos estableciendo metas de cumplimiento en
concordancia con los objetivos generales de los mismos.
Identifica y programa la adquisición de nuevo personal, bienes y/o servicios necesarios
para el desarrollo del proyecto.
Comunicación Asertiva.
Determinación de metas.
Capacidad de análisis.
Capacidad para resolver
problemas.
Nivel Descripción de Actividades Habilidades Blandas
Identifica riesgos que puedan complicar la correcta ejecución de los proyectos.
Establecer métodos, técnicas y herramientas a utilizar por el equipo del proyecto.
Definir perfiles para que el equipo del proyecto y las responsabilidades de cada uno.
Definir métricas para medición de rendimiento de proyectos y miembros del equipo.
Aplicación
Selección de personal basado en análisis de habilidades y competencias.
Administración eficiente de recursos humanos, materiales y presupuestos asignados al
proyecto.
Aplicación de metodología ASAP para la implementación de proyectos.
Mitigación de riesgos mediante aplicación de planes definidos de acuerdo al tipo de
vulnerabilidad.
Proactividad.
Capacidad de análisis.
Seguridad Personal.
Tolerancia a la presión.
Liderazgo.
Análisis
Identificación y análisis de puntos críticos en el desarrollo de cada fase del proyecto.
Identificación y análisis de causas de retraso en los proyectos y las alternativas de
solución a aplicar para ello.
Evaluación de factores internos y externos que puedan desestabilizar la armonía del
equipo de trabajo.
Escucha activa.
Capacidad para resolver
problemas.
Capacidad de análisis.
Orden.
Síntesis Formulación de propuestas de mejora, basado en lecciones aprendidas, para afinar la
calidad del servicio de consultoría y el proceso de desarrollo de proyectos.
Capacidad de redacción.
Orden.
Evaluación Evaluación de metodologías y tecnologías que soporten las propuestas de mejora Capacidad de análisis.
Nivel Descripción de Actividades Habilidades Blandas
planteadas.
Evaluación de métricas de rendimiento de proyectos y personal.
Orden.
Tabla 16 – Actividades del Jefe de Proyecto por Nivel de la Taxonomía de Bloom
Fuente: Elaboración propia
De no alcanzarse el nivel de Evaluación dentro de la Taxonomía de Bloom, se debería iterar al nivel de Análisis, ya que este nivel proporciona la
base para la definición de propuestas de mejora y evaluación de métricas. Asimismo, se deberán reforzar las habilidades blandas asociadas a
dicho nivel.
- Consultor Senior:
Nivel Descripción de Actividades Habilidades Blandas
Conocimiento
Experiencia de nivel funcional en los módulos de SAP y/o conocimiento avanzado de su
lenguaje de programación ABAP.
Capacidad para gestión de proyectos y personal.
Comunicación Asertiva.
Escucha activa.
Sociabilidad.
Empatía.
Respeto a las opiniones.
Trabajo en equipo.
Capacidad para resolver
problemas.
Capacidad de análisis.
Liderazgo.
Comprensión
Planteamiento de soluciones que permitan satisfacer los requerimientos recibidos del
cliente.
Elaboración de plan para el seguimiento de atención de los requerimientos.
Definir la arquitectura de hardware y software, componentes, módulos y datos para
satisfacer los requerimientos del proyecto.
Comunicación Asertiva.
Capacidad para resolver
problemas.
Capacidad de análisis.
Orden.
Aplicación Atención de requerimientos de acuerdo a lo planificado.
Coordinación y ejecución de acciones en apoyo a la gestión de proyectos.
Proactividad.
Capacidad de análisis.
Nivel Descripción de Actividades Habilidades Blandas
Seguridad Personal.
Tolerancia a la presión.
Liderazgo.
Análisis
Identificación de alternativas de solución a problemáticas encontradas en el relevamiento
de procesos, evaluando la factibilidad de su aplicación.
Inspección y detección de errores en entregables.
Investigación de nuevas tendencias tecnológicas que permitan incrementar el valor de los
entregables y la calidad del servicio.
Análisis de propuestas de mejora del equipo de trabajo.
Escucha activa.
Capacidad para resolver
problemas.
Capacidad de análisis.
Síntesis
Elaboración de plan de mejoras continuas adaptable al proceso de mantenimiento de
software.
Establecer un registro de lecciones aprendidas que permita identificar futuros problemas
en el desarrollo del proceso de mantenimiento de software.
Capacidad de redacción.
Orden.
Evaluación Descripción del plan de mejoras continúa con los Jefes de Proyecto argumentando
ventajas de su implementación.
Capacidad de análisis.
Orden.
Tabla 17 – Actividades del Consultor Senior por Nivel de la Taxonomía de Bloom
Fuente: Elaboración propia
De no alcanzarse el nivel de Evaluación dentro de la Taxonomía de Bloom, se debería iterar al nivel de Análisis, ya que este nivel permite
identificar opciones de mejora en función de las lecciones aprendidas en el desarrollo de los proyectos. Asimismo, se deberán reforzar las
habilidades blandas asociadas a dicho nivel.
- Desarrollador:
Nivel Descripción de Actividades Habilidades Blandas
Conocimiento Conocimiento del lenguaje de programación ABAP y mejores prácticas de
programación.
Comunicación Asertiva.
Escucha activa.
Respeto a las opiniones.
Trabajo en equipo.
Capacidad para resolver
problemas.
Capacidad de análisis.
Comprensión Planteamiento de soluciones aplicables a los requerimientos asignados.
Capacidad para resolver
problemas.
Capacidad de análisis.
Orden.
Nivel Descripción de Actividades Habilidades Blandas
Aplicación
Atención de requerimientos de acuerdo a lo planificado de acuerdo a los estándares
manejados por la organización.
Elaboración de documentación de calidad que soporte el desarrollo realizado para cubrir
la atención de los requerimientos.
Proactividad.
Capacidad de análisis.
Tolerancia a la presión.
Análisis
Identificación de alternativas de solución a problemáticas encontradas en el relevamiento
de procesos, evaluando la factibilidad de su aplicación.
Análisis de performance y oportunidades de mejora en desarrollos propios y/o del
cliente.
Escucha activa.
Capacidad para resolver
problemas.
Capacidad de análisis.
Síntesis Elaboración de propuestas que permitan mejorar la calidad de los entregables. Capacidad de redacción.
Orden.
Evaluación No requerido
Tabla 18 – Actividades del Desarrollador por Nivel de la Taxonomía de Bloom
Fuente: Elaboración propia
50
De no alcanzarse el nivel de Síntesis dentro de la Taxonomía de Bloom, se debería iterar al
nivel de Comprensión con la finalidad de entender de manera adecuada la problemática
planteada por el cliente, y redefinir la solución a aplicar. Asimismo, se deberán reforzar las
habilidades blandas asociadas a dicho nivel.
Aplicación del Estándar TSP:
Dado que el objetivo fundamental de TSP es formar equipos de trabajo de alto rendimiento
basado en personal alineado al PSP, es necesario conocer cómo se establece la integración de
ambos y el proceso que se debe aplicar a los equipos de trabajo basados en TSP.
Figura 14 – Elementos del TSP y PSP
Fuente: The Team Software Process SM (TSPSM) in Practice: A Summary of Recent Results
De acuerdo a la figura 14, la base para la aplicación de TSP es PSP. “El objetivo del PSP es
colocar a profesionales de software a cargo de su trabajo y hacerlos sentir responsables de la
calidad de sus productos. El objetivo del TSP es proveer un ambiente de equipos de trabajo
que soporte la labor del PSP y construir y mantener equipos auto-dirigidos. PSP y TSP son
herramientas poderosas que proveen habilidades, disciplinas y compromisos requeridos para
proyectos de software exitosos.”15
Cabe mencionar que el éxito de la implementación de TSP depende de sobremanera en la
madurez que haya alcanzado el personal guiado por PSP.
Teniendo en cuenta que ya se ha alcanzado un nivel robusto de madurez del personal que
interviene en el proceso de mantenimiento de software, se propone la implementación de un
proceso que asegure un correcto alineamiento de los equipos de trabajo con la propuesta de
TSP. Dicho proceso se encontrara orientado a la conformación de equipos y planes de trabajo
y a la gestión de los mismos.
1. Conformación de equipos y planes de trabajo: Define el conjunto de actividades que
permitirán integrar al personal que mejor ajuste sus habilidades con los roles requeridos
por los proyectos y a la conformación de planes que permitan el óptimo cumplimiento de
los mismos.
Es necesario tener en cuenta, como ya se había mencionado anteriormente, que es
necesario contar con personal alineado a PSP y con amplia capacidad de analizar y
autogestionar su propio trabajo.
Para poder alcanzar la conformación ideal de los equipos de trabajo es necesario
enumerar las actividades que se deben tener en cuenta:
15 The Team Software Process
SM (TSP
SM) in Practice: A Summary of Recent Results.
Los equipos de trabajo deben tener un claro entendimiento acerca de los objetivos del
negocio y la propuesta de valor del servicio a ofrecer. La participación del Comité
Ejecutivo de la organización es importante en este punto.
Se debe establecer una definición precisa de las responsabilidades que comprende cada
uno de los roles que intervendrá en el proceso de mantenimiento de software.
Se debe llevar a cabo la selección de personal de acuerdo a los perfiles descritos para cada
rol. Para ello se deberá tener en cuenta al personal cuyas habilidades se acerquen más a lo
requerido por dichos perfiles. Esta información será tomada de acuerdo a la
documentación actualizada que se debe mantener de habilidades y competencias del
personal.
Se debe mantener correctamente establecido los procedimientos y las estrategias que
seguirá el equipo de trabajo en el desarrollo del proceso de mantenimiento de software.
Se debe establecer los objetivos de calidad que espera alcanzar el equipo de trabajo y las
herramientas de medición que se llevaran a cabo para ello.
La elaboración de planes de trabajo se realizará de manera conjunta con el equipo de
trabajo, identificando tareas y responsabilidades. Para cada tarea ingresada en el plan de
trabajo, se deberá identificar la existencia de algún riesgo que impida su correcta
ejecución y elaborar planes de contingencia para mitigarlos.
Cada responsable debe elaborar un plan de trabajo más detallado de las actividades que
comprende cada una de sus tareas. Esto con la finalidad de poder hacer un seguimiento
más minucioso de sus tareas.
Finalmente, se debe elaborar un cronograma que permita juntar los miembros del equipo
de trabajo para conocer el avance de sus tareas y el estado de los proyectos.
2. Gestión de equipos de trabajo: Define el conjunto de actividades que permitirá gestionar
de manera eficiente no solo el desarrollo de los proyectos sino el desempeño de cada uno
de los miembros que conforman los equipos de trabajo.
Dentro de las actividades a realizar se encuentran:
Seguimiento y análisis del plan general del proyecto con periodicidad semanal o de
acuerdo a lo planificado en la etapa de conformación de equipos. En esta actividad se
deberá tomar registro de la situación de avance planificado vs real, así como del
desempeño de cada uno de los integrantes del equipo de trabajo.
Análisis de progreso tanto a nivel de equipo de trabajo como a nivel individual. Para ello,
se plantea el análisis de los siguientes indicadores:
- Tiempo promedio de encolamiento de requerimiento y las causas de demora en su
atención.
- Tiempo promedio de atención de requerimientos por complejidad y módulo funcional.
- Número de observaciones alcanzadas por el cliente posterior a la atención de los
requerimientos. Este análisis deberá estar acompañado de un registro que permita
identificar si las observaciones tienen responsabilidad del lado del cliente o de los
miembros del equipo de trabajo
- Tiempo promedio de atención de correcciones posterior a atención de los
requerimientos. Esto, con la finalidad de medir el impacto de las posibles omisiones
del lado del cliente o del equipo de trabajo.
- Porcentaje de atención de requerimientos por módulo funcional
Se recomienda establecer análisis comparativo de estos indicadores:
- Con periodicidad mensual.
- Entre proyectos.
- A nivel de personal.
Análisis y seguimiento del estado de los riesgos de los proyectos.
CONCLUSIONES
La aplicación de PSP en la definición de los perfiles asociados a los roles involucrados en
el proceso de mantenimiento de software ha permitido tener un horizonte más amplio de
las habilidades que cada uno de estos requiere, contribuyendo de manera positiva en el
análisis y mejora de cada uno de los perfiles del equipo de trabajo.
PSP ha permitido conocer el estado actual de cada uno de los roles dentro del equipo de
trabajo mediante la comparación de habilidades del perfil deseado vs el perfil actuado.
Esto ha permitido tener un enfoque de las habilidades que se deberían potenciar y
desarrollar en el mediano y largo plazo.
Se ha logrado comprender la influencia que tiene PSP en la implementación de TSP y
como éste utiliza los indicadores de autogestión para la conformación de equipos de
trabajo e identificación de puntos que pueden aumentar la performance del desarrollo de
proyectos.
El registro y seguimiento del desarrollo de habilidades y capacidades se debe considerar
como una tarea de suma importancia, ya que proporciona la fuente de información para la
conformación de equipos de trabajo.
Se ha comprendido que para garantizar el nivel de éxito de la implementación de PSP y
TSP es necesario que estas se encuentren asociadas con las prácticas propuestas por el
estándar P-CMM. Sin embargo, es necesario establecer una implementación progresiva
de estas prácticas para lograr el establecimiento de una cultura de adaptación y mejora
constante que convenza al personal de su aplicación.
Finalmente, se ha interiorizado y visto con buen agrado la propuesta de desarrollar las
capacidades de autogestión por parte de la Alta Gerencia, estableciendo un compromiso
de alinear de manera paulatina las prácticas propuestas por el modelo P-CMM.
CAPÍTULO 3. GESTIÓN DE SERVICIOS EN TI
INTRODUCCIÓN
En este capítulo se presentará un análisis de los servicios ofrecidos por la organización, tanto
a nivel interno como externo, y su alineamiento con los objetivos estratégicos. Asimismo, se
asegurará la correcta gestión de éstos mediante la aplicación del marco de trabajo propuesto
por ITIL.
EVALUACIÓN ESTRATÉGICA
A partir de un análisis interno y externo, así como la evaluación de los espacios de mercado,
se identifican y priorizan los servicios de TI requeridos por la organización objeto de estudio.
Asimismo, se presenta un análisis FODA con el estudio de su situación actual.
Análisis del entorno interno:
El presente análisis detalla los servicios que, actualmente, brinda la organización y su
justificación de beneficio futuro. Además, los servicios pertenecen a la Unidad SAP.
Servicios Existentes:
Servicio
existente
Criticidad actual
para el Negocio
(Alta/Media/Baja)
Potencial de
beneficio futuro
para el negocio
(Alto/Medio/Bajo)
Justificación de beneficio
futuro
Implementación
ERP16
Media Alto
Crecimiento de empresas que
están adquiriendo o migrando a
SAP.
Training Baja Bajo No es parte del giro del negocio.
Outsourcing
(In house) Alta Alto
Principal servicio del negocio con
el que se tiene mayor
participación en el mercado.
Localizaciones Alta Alto Requerimiento de normas legales
SUNAT.
Help Desk Alta Alto Servicio en crecimiento durante
los últimos años.
Gestión de
Procesos Baja Alto
No existen en el mercado muchas
empresas que realicen tareas de
análisis y evaluación de procesos
en SAP.
Data Integration Baja Medio
Necesidad de las empresas de
migración y centralización de
datos.
Hosting Baja Baja No es parte del giro del negocio.
(Leyenda: Baja = Servicio Esporádico, Media = Servicio en Crecimiento, Alta = Servicio Core del negocio)
Tabla 19 – Servicios Existentes
Fuente: Elaboración propia
Análisis Financiero:
A continuación, se presentan los costos estimados mensuales de los recursos individuales
requeridos por cada servicio. En casos particulares el costo se expresa en horas.
Servicio existente Comentarios generales sobre análisis financiero
Implementación ERP Jefe de Proyecto (1) – US$ 4,000.00
Project Manager (1) = US$ 3,000.00
Consultor Senior (1) = US$ 5,000.00.
Arquitecto ABAP (1) = US$ 3,500.00
Desarrollador (1) = US$ 2,500.00
Training Consultor Senior (1) = US$ 3,500.00
Arquitecto ABAP (1) = US$ 3,500.00
Outsourcing Consultor Senior (1) = US$ 350.00 por día.
Desarrollador (1) = US$ 150.00 por día.
Localizaciones Jefe de Proyecto (1) = US$ 3,500.00
Consultor Senior (1) = US$ 4,000.00
Arquitecto ABAP (1) = US$ 2,500.00
Desarrollador (1) = US$ 1,500.00
Help Desk Consultor Senior (1) = US$ 50.00 por hora.
Desarrollador (1) = US$ 30.00 por hora.
Gestión de Procesos Jefe de Proyecto (1) = US$ 5,000.00
Consultor de Procesos (1) = US$ 3,500.00
Analista de Procesos (1) = US$ 2,000.00
Data Integration Jefe de proyecto (1) = US$ 5,000.00
Consultor Senior (1) = US$ 3,500.00
Arquitecto ABAP (1) = US$ 2,000.00
Desarrollador (1) = US$ 1,500.00
16 Enterprise Resource Planning, sistema integral de gestión empresarial que está diseñado
para modelar y automatizar la mayoría de los procesos en una organización.
Servicio existente Comentarios generales sobre análisis financiero
Hosting Basis SAP (1) = US$ 50,00 por hora.
Tabla 20 – Análisis Financiero de los Servicios Existentes
Fuente: Elaboración propia
Recursos Humanos:
Antes de presentar el detalle de los perfiles manejados por cada servicio, es necesario conocer
las consideraciones que se mantienen en la organización con respecto a la gestión del
personal. Estas son aplicables a todos los servicios.
Reclutamiento:
El proceso de reclutamiento está a cargo de los Gerentes de Línea de Negocio quienes
realizan el proceso de convocatoria a través de herramientas como Aptitus, LinkedIn o a
través de publicaciones directas en bolsas de trabajo de universidades e institutos.
Plan de Sucesión:
Dentro de la organización no existe un plan de sucesión definido y documentado.
Compensaciones:
El sobretiempo dentro de la organización es compensado con tiempo de descanso no
laborable siempre que se haya incurrido en un tiempo de trabajo mayor a las 48 horas
semanales.
A continuación se presentará el detalle de los perfiles requeridos para cada uno de los
servicios ofrecidos por la organización.
Servicio: Implementación ERP
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
Jefe de
proyecto
Experiencia en gestión de
proyectos y del personal,
liderazgo, planificación,
dirección de equipos de trabajo y
capacidad para resolución de
problemas.
Contratado 1 Alta
PM17
Organización y control respecto
al avance del proyecto.
Contratado
/ Tercero 1 Media
Consultor
Senior
Experiencia técnico-funcional en
módulos de SAP, trabajo en
equipo, capacidad de análisis y
diseño.
Contratado
/ Tercero
Mínimo 3
consultores que
cubran los
módulos
principales de
SAP: Finanzas,
Logística y
Ventas.
Alta
Arquitecto
ABAP
Conocimiento avanzado de
lenguaje ABAP, estimación,
validación y verificación de
desarrollos.
Contratado
/ Tercero 1 Alta
Desarrollador Conocimiento de lenguaje
ABAP, diseño y propuesta de
Contratado
/ Tercero 4 Alta
17 Project Manager, encargado de darle seguimiento al proyecto para cumplir con los
objetivos y tiempos trazados.
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
soluciones bajo la aplicación de
mejores prácticas de
programación.
(Leyenda: Contratado = Forma parte del staff de la Organización, Tercero = Contratado exclusivamente para brindar el
servicio)
Tabla 21 – Recursos Humanos requeridos por el Servicio de Implementación ERP
Fuente: Elaboración propia
Servicio: Training
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
Consultor
Senior
Experiencia técnico-funcional en
módulos de SAP, comunicación
asertiva, escucha activa y
empatía.
Contratado
/ Tercero
1 especialista de
cada módulo Alta
Arquitecto
ABAP
Conocimiento avanzado de
lenguaje ABAP, comunicación
asertiva, escucha activa y
empatía.
Contratado
/ Tercero 1 Alta
Tabla 22 – Recursos Humanos requeridos por el Servicio de Training
Fuente: Elaboración propia
Servicio: Outsourcing y Help Desk
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
Consultor
Senior
Experiencia técnico-funcional en
módulos de SAP, trabajo en
equipo, capacidad de análisis y
diseño.
Contratado
/ Tercero
De acuerdo a la
necesidad del
cliente.
Alta
Desarrollador
Conocimiento de lenguaje
ABAP, diseño y propuesta de
soluciones bajo la aplicación de
mejores prácticas de
programación.
Contratado
/ Tercero
De acuerdo a la
necesidad del
cliente.
Alta
Tabla 23 – Recursos Humanos requeridos por el Servicio de Outsourcing y Help Desk
Fuente: Elaboración propia
Servicio: Localizaciones
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
Jefe de
proyecto
Experiencia en gestión de
proyectos y del personal,
liderazgo, planificación,
dirección de equipos de trabajo y
capacidad para resolución de
problemas.
Contratado 1 Alta
Consultor
Senior
Experiencia técnico-funcional en
módulos de SAP, trabajo en
equipo, capacidad de análisis y
Contratado
/ Tercero 1 Alta
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
diseño.
Arquitecto
ABAP
Conocimiento avanzado de
lenguaje ABAP, estimación,
validación y verificación de
desarrollos.
Contratado
/ Tercero 1 Alta
Desarrollador
Conocimiento de lenguaje
ABAP, diseño y propuesta de
soluciones bajo la aplicación de
mejores prácticas de
programación.
Contratado
/ Tercero
De acuerdo al
paquete a instalar.
(*)
Alta
(*) Los paquetes a instalar se pueden clasificar en: Libros Legales, Retenciones, Detracciones y PDTs.
Tabla 24 – Recursos Humanos requeridos por el Servicio de Localizaciones
Fuente: Elaboración propia
Servicio: Gestión de Procesos
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
Jefe de
proyecto
Experiencia en gestión de
proyectos y del personal,
liderazgo, planificación,
dirección de equipos de trabajo y
capacidad para resolución de
problemas.
Contratado 1 Alta
Consultor de Experiencia en el uso de Contratado 1 Alta
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
Procesos metodologías estándares para el
adecuado análisis de procesos.
Asistente de
Procesos
Manejo adecuado de
herramientas de modelamiento
de procesos como Rational Rose,
Bizagi Modeler, Visio, entre
otras.
Contratado 1 Alta
Tabla 25 – Recursos Humanos requeridos por el Servicio de Gestión de Procesos
Fuente: Elaboración propia
Servicio: Data Integration
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
Jefe de
proyecto
Experiencia en gestión de
proyectos y del personal,
liderazgo, planificación,
dirección de equipos de trabajo y
capacidad para resolución de
problemas.
Contratado 1 Alta
Consultor
Senior
Experiencia técnico-funcional en
módulos de SAP, trabajo en
equipo, capacidad de análisis y
diseño.
Contratado
/ Tercero
De acuerdo a la
necesidad del
cliente.
Alta
Arquitecto
ABAP
Conocimiento avanzado de
lenguaje ABAP, estimación,
Contratado
/ Tercero 1 Media
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
validación y verificación de
desarrollos.
Desarrollador
Conocimiento de lenguaje
ABAP, diseño y propuesta de
soluciones bajo la aplicación de
mejores prácticas de
programación.
Contratado
/ Tercero
De acuerdo a la
necesidad del
cliente.
Alta
Tabla 26 – Recursos Humanos requeridos por el Servicio de Data Integration
Fuente: Elaboración propia
Servicio: Hosting
Perfil Habilidades y capacidades de
RRHH necesarias Tipo
Cantidad
requerida Criticidad
SAP Basis
Experiencia técnica en
instalación, configuración y
soporte de servidores SAP,
además de la administración de
base de datos.
Contratado
/ Tercero 1 Alta
Tabla 27 – Recursos Humanos requeridos por el Servicio de Hosting
Fuente: Elaboración propia
Relacionamiento con las Unidades de Negocio:
Al ser el objeto de estudio una empresa dedicada a brindar servicios de TI para externos, las
unidades de negocio la constituyen cada uno de sus clientes. Ante ello, es necesario preservar
el correcto relacionamiento con estos, teniendo en cuenta dos aspectos importantes:
El servicio de Implementación ERP está orientado al desarrollo y configuración de estos
sistemas en servidores de cliente. Actualmente, se cubre la atención de este servicio con
consultores freelance contratados por la duración del proyecto en cuanto a temas
funcionales se refiere. De ser necesario, se contrata, también, consultores para temas de
desarrollo si la capacidad instalada no cubre la demanda.
El servicio de Training está orientado a la capacitación del personal de cliente en
funcionalidades propias del estándar SAP. Este servicio es el menos demandado, y sólo
para temas funcionales se contratará personal externo de la organización.
El servicio de Outsourcing se brinda en sus dos modalidades: In house y Off Site.
Actualmente, este servicio es ofrecido mediante la contratación de personal tercero a la
organización para hacer frente a temas funcionales o especializados. Se asegura que para
la modalidad “In House” el personal contratado cuente con el debido expertise.
El servicio de Localizaciones está orientado a la implementación de reportes legales
solicitados por SUNAT. Este servicio es el más demandado y el que consume la mayor
capacidad de los consultores por lo que puede generar problemas o retrasos en respuesta
de atención a requerimientos de otros clientes.
El servicio de Help Desk es brindado por un solo consultor, el cual forma parte de la mesa
de ayuda del cliente. No se ha observado problemas que puedan afectar la relación con
éste
El servicio de Gestión de Procesos está orientado a apoyar a las organizaciones cliente en
el análisis y mejora de sus procesos de negocio. Este servicio es nuevo dentro de la
organización y se recomienda alta capacidad analítica en los consultores a cargo de su
entrega.
El servicio de Data Integration está encargado de establecer comunicación entre
servidores SAP y, SAP - NO SAP; así como ayudar en el proceso de migración de datos.
Actualmente, el equipo encargado de brindar el servicio es subcontratado.
El servicio de Hosting está encargado de brindar alojamiento virtual de servidores. Se
cuenta con una persona a cargo para la realización de tareas de soporte, actualización y
backup de datos.
A continuación, se presenta una matriz de los servicios brindados y su relación con las
Unidades de Negocio correspondientes:
68
CLIENTES
SERVICIOS EXISTENTES
LA
P
AU
NA
ME
TS
O
GR
UP
O S
AM
RIP
LE
Y
GL
OR
IA
PE
CS
A
SA
N M
AR
TIN
ME
AD
JO
HN
SO
N
VO
TO
RA
NT
IM
ME
TA
IS
CH
INA
LC
O
INK
AF
AR
MA
CO
GA
CA
UD
AL
OS
A
BA
SF
ES
SA
LU
D
PE
TR
OB
RA
S
TO
TA
L
SE
RV
ICIO
S
Implementación ERP
X
X
X
3
Training
X
1
Outsourcing X X
X X X
X X
7
Localizaciones X
X X X
X X
X
X X
9
Help Desk
X
1
Gestión de Procesos
X
1
Data Integration
X
X
2
Hosting
X 1
TOTAL SERVICIOS POR CLIENTE 2 1 1 4 2 1 1 2 1 2 2 1 1 1 1 1 1 25
Tabla 28 – Cuadro de Relacionamiento de Servicios con los principales Clientes
Fuente: Elaboración Propia
69
Recursos y Capacidades Disponibles:
Los recursos requeridos y capacidades disponibles están directamente relacionados con la
sección 1.3. Recursos Humanos.
Servicio existente
Recursos y
capacidades
disponibles
Nivel de uso
Implementación
ERP
1 Jefe de Proyecto Uso al 100% durante todo el desarrollo del
proyecto.
1 PM
Uso al 100% para que notifique cualquier
desviación del plan en cualquier etapa del
proyecto.
3 Consultores Senior
Uso al 100% para que configure el módulo
SAP que tiene a cargo y haga las
coordinaciones necesarias con los consultores
de los otros módulos (integración).
1 Arquitecto ABAP Uso al 100% para que estime y valide los
desarrollos.
4 Desarrolladores Uso al 100% para atender los requerimientos
de la etapa de construcción del proyecto.
Training
1 Consultor Senior
Uso al 100% para que esté disponible al
público asistente al curso de capacitación de
un determinado módulo SAP.
1 Arquitecto ABAP
Uso al 100% para que esté disponible al
público asistente al curso de capacitación del
lenguaje de programación ABAP.
Outsourcing y Help
Desk
1 Consultor Senior Uso al 100% para atender cualquier tipo de
requerimiento. 1 Desarrollador
Localizaciones 1 Jefe de Proyecto Uso al 80% para monitorear el avance de las
Servicio existente
Recursos y
capacidades
disponibles
Nivel de uso
adecuaciones y pruebas con los usuarios.
1 Consultor Senior
Uso al 80% para realizar ajustes en la
configuración de SAP o establecer alguna
definición con los usuarios.
1 Arquitecto ABAP Uso al 100% para que estime y valide las
adecuaciones al paquete de localizaciones.
Desarrollador
Uso al 100% para realizar los ajustes al
paquete de acuerdo a la forma de trabajo del
cliente. La cantidad es de acuerdo al paquete a
instalar (*). Por ejemplo: Existen más de 30
Libros Legales requeridos por SUNAT, por lo
cual la cantidad de desarrolladores puede
variar dependiendo de los libros que el cliente
solicite implementar.
Gestión de Procesos
1 Jefe de Proyecto
Uso al 80% para monitorear el avance del
proyecto y evaluar riesgos o retrasos que se
puedan presentar durante el proyecto.
1 Consultor de Procesos
Uso al 100% para recopilar, evaluar y diseñar
o rediseñar procesos planteados por los
usuarios.
1 Asistente de Procesos
Uso al 100% para realizar labores específicas
de modelado de procesos empleando
herramientas que optimicen el diseño de los
mismos.
Data Integration
1 Jefe de Proyecto Uso al 100% durante todo el desarrollo del
proyecto.
Consultor Senior Uso al 100% para que haga las coordinaciones
necesarias con los responsables del sistema
Servicio existente
Recursos y
capacidades
disponibles
Nivel de uso
origen y destino.
1 Arquitecto ABAP Uso al 100% para que estime y valide los
desarrollos.
Desarrollador
Uso al 100% para atender los requerimientos
de extracción, conversión y carga de datos al
sistema destino. La cantidad es de acuerdo a la
necesidad del cliente.
Hosting 1 SAP Basis Uso al 100% para controlar y dar seguimiento
al funcionamiento de los servidores SAP.
(*) Los paquetes a instalar se pueden clasificar en: Libros Legales, Retenciones, Detracciones y PDTs.
Tabla 29 – Recursos y Capacidades Disponibles de los Servicios Existentes
Fuente: Elaboración propia
Operación del Servicio:
Servicio existente ¿Qué tan eficiente y efectivo es el servicio en la organización? ¿Qué
tan eficiente es el uso de tecnología en cada servicio?
Implementación
ERP
Servicio eficiente. Para el óptimo cumplimiento del servicio se
consideran recursos tecnológicos como servidores de desarrollo,
servidores de integración y prueba (que deben contar con la última
versión SAP ECC18
6.0.), laptops, impresoras, conexiones VPN y, de ser
necesario, video llamadas vía Skype.
18 ERP Central Component, versión sucesora de SAP R/3 que brinda mayor soporte a SAP
Netweaver Business Warehouse para el uso de aplicaciones Web.
Servicio existente ¿Qué tan eficiente y efectivo es el servicio en la organización? ¿Qué
tan eficiente es el uso de tecnología en cada servicio?
Training Servicio eficiente y efectivo. Para la adecuada capacitación a usuarios en
los diversos módulos de SAP se emplea la conexión a servidores de
entrenamiento.
Outsourcing Servicio eficiente y efectivo. Soporte adecuado y oportuno para llevar a
cabo actividades de análisis y mejora en los desarrollos y procesos de los
clientes.
Localizaciones Servicio eficiente y efectivo. Solución paquetizada que ayuda a las
empresas a cumplir con los requerimientos legales establecidos por
SUNAT facilitando las tareas de fiscalización. Para el caso de los Libros
Legales, se cuenta con la aplicación gratuita PLE19
de SUNAT vigente
(Versión 4.0.9.) para hacer simulaciones de carga y consistencia de
datos.
Help Desk Servicio eficiente y efectivo. Atención oportuna de incidencias
reportadas en las diferentes áreas del cliente.
Gestión de Procesos Servicio eficiente. Uso adecuado de herramientas para el modelado de
procesos, así como estándares y políticas para el análisis y propuestas de
mejora de los mismos.
Data Integration Servicio eficiente y efectivo. Se emplean plantillas, programas de
extracción, conversión y carga de datos para la integración de datos de
un determinado sistema origen al ERP de SAP.
Hosting Servicio eficiente. Se emplean herramientas tecnológicas para la
virtualización y monitoreo de servidores de datos y aplicaciones.
Tabla 30 – Operación del Servicio
Fuente: Elaboración propia
19 Programa de Libros Electrónicos, permite que los contribuyentes puedan manejar de
manera electrónica sus libros y registros vinculados a asuntos tributarios.
Análisis del entorno externo:
El presente análisis detalla aspectos a considerar de los clientes, proveedores, competencias y
tecnología. Al finalizar, se presenta un análisis FODA20
de la organización objeto de estudio.
Análisis de la industria y el mercado:
El desarrollo de la industria, el crecimiento del mercado, la abundante competencia, y la
constante demanda en la prestación de servicios obligan a las empresas a estar a la
vanguardia de la tecnología y la mejora de sus procesos, de manera que día a día el
desempeño de sus actividades sea más eficiente y obtengan el deseado nivel de
posicionamiento.
Una de las modalidades de prestación de servicios más difundidas y solicitadas en la
actualidad es la tercerización, la cual brinda a las empresas beneficios directos que facilitan
sus labores diarias y permite a las empresas concentrarse en la razón de ser de su actividad
económica, reduciendo significativamente sus costos de operación y manteniendo la calidad
de sus servicios o productos.
Existen diversos tipos de tercerización:
Bodyshop: También conocida como venta de capital humano, es la práctica de empresas
de consultoría que reclutan personal de tecnología de información con la finalidad de
contratar sus servicios por un corto plazo.
Outsourcing: Proceso en el cual una empresa identifica una parte de su proceso de
negocio que podría ser desempeñada de manera más eficiente y efectiva por otra empresa,
20 Fortalezas, Oportunidades, Debilidades y Amenazas, metodología de estudio de la
situación de una empresa o proyecto.
la cual es contratada para atender dicha necesidad. Esto libera a la primera empresa para
enfocarse directamente en el Core de su negocio.
Llave en mano: Un único proveedor implementa una solución global, agrupando una gran
variedad de actividades.
La tendencia de los tipos de tercerización de servicios de tecnología de información, se
inclina al outsourcing, ya que por lo general las empresas no se podrían arriesgar a que un
solo proveedor brinde un determinado servicio, ni a “comprar” o contratar personal porque
justamente lo que buscan es que un tercero se ocupe de la gestión de sus procesos que no
forman parte del Core del negocio.
Clientes:
TSNET S.A. busca orientar a los clientes en el beneficio de sus negocios. Para ello, las
soluciones que provee cuentan con un primer nivel técnico, un segundo nivel funcional o de
procesos, y un tercer nivel de resultados de negocio.
Debido al alto nivel de profundidad en las soluciones que se desarrollan, es muy fácil
desviarse y proponer soluciones que se basan en un nivel técnico o de procesos. Sin embargo,
el nivel más importante está encima de ambos, y es el beneficio del negocio. Para ello, se
evalúa el impacto de la solución sobre los estados financieros y el bienestar del personal. El
efecto que se logra en el cliente se incrementa por el valor percibido.
A continuación, se muestra una representación del efecto que se busca lograr en los clientes:
Antes Ahora
Prestación de un servicio. Vivir una experiencia.
Lo que se hizo funciona. Lo que se hizo tiene valor para el negocio.
Cliente satisfecho. Miembro de un club.
Antes Ahora
Cliente que busca nuestros servicios Agente de marketing, boca a boca.
De acuerdo con los ofrece que ofrece. De acuerdo con el enfoque de trabajo.
Tabla 31 – Efecto que se busca en los Clientes
Fuente: Elaboración propia
Asimismo, para lograr cambios exitosos en las empresas, TSNET S.A. ha desarrollado
múltiples habilidades y conocimientos en las diferentes industrias, con las mejores prácticas
de negocio y manejo de herramientas tecnológicas para alcanzar los resultados esperados por
los clientes.
Los principales clientes con los que trabaja TSNET S.A. son:
Minería: Chinalco, Caudalosa, Volcan, Votorantim Metais, Hochschild, Glencore.
Construcción: Metso, San Martin.
Combustibles: Pecsa, Petrobras.
Aeroportuario: LAP.
Industria Química: BASF.
Alimentos: Mead Johnson, Alicorp, Gloria, Braedt.
Financiero: Banco de Crédito del Perú.
Salud: Essalud, AUNA.
Farmacia: Inkafarma.
Los servicios que se brindan a cada uno de estos clientes se pueden ver en la tabla 20 del
punto 1.4 Relacionamiento con las Unidades de Negocio, de la sección de análisis del entorno
interno.
Proveedores:
Como se ha mencionado en secciones anteriores del presente documento, TSNET S.A. al ser
una empresa que brinda servicios de consultoría no cuenta con proveedores de servicios
directos o permanentes. Por el contrario, cuando TSNET S.A. no cuenta con personal
disponible para la atención de algún servicio solicitado por el cliente recurre a la colaboración
de empresas proveedoras del mismo rubro de consultoría con quienes ya tiene experiencia
trabajando y tiene un alto nivel de confianza.
Los principales proveedores de consultores SAP son:
BizPartner21
: Ofrece servicios de alta calidad para el análisis, diseño y optimización de
procesos y operaciones.
NetSolutions22
: Brinda, entre otras cosas, servicios de consultoría de tecnología de
información y desarrollo móviles.
CSTI23
: Brinda servicios de consultoría de Business Inteligence, plataformas móviles,
integración y desarrollo, y outsourcing de profesionales en TI.
HCC24
: Brinda servicios de programación ABAP y consultoría en el módulo de Recursos
Humanos.
21 http://www.bizpartner.biz/
22 http://www.nspsac.com/
23 http://www.csticorp.biz/
Competencia:
La experiencia y reconocimiento de TSNET S.A. en la prestación de servicios de consultoría
le ha permitido alcanzar un nivel de posicionamiento en el mercado que le permite
diferenciarse de la competencia directa, entre ellos destacan nuestros principales proveedores
de consultores SAP: BizPartner, NetSolutions, CSTI y HCC.
TSNET S.A. se diferencia de la competencia por sus:
Valores: Transparencia, integridad, compromiso, ética, orientación al cliente, calidad de
trabajo, iniciativa, innovación, flexibilidad.
Pasión: Por la excelencia, el cambio y el conocimiento.
Talento: Hábitos y habilidades personales y profesionales del personal.
Tecnología:
La presencia de nuevas tecnologías cambiarán los servicios que proveemos en el sentido que
contaremos con un nuevo abanico de oportunidades y servicios a ofrecer a los clientes.
Dentro de las tendencias tecnológicas en SAP se puede mencionar:
Success Factors: Gestiona el ciclo de vida completo del recurso humano, desde la
contratación hasta el retiro, e incluye un conjunto completo de soluciones de gestión del
talento estrechamente integradas, análisis y planificación de fuerza laboral robustos, así como
una solución de Recursos Humanos de nueva generación.
24 http://www.grupohcc.com/
Figura 15 – Success Factors: Gestión del Recurso Humano
Fuente: http://www.softtek.com/es/tecnologias/sap-successfactors
FIORI: Tecnología optimizada para el consumo móvil y desplegada en la nube para ofrecer a
los clientes una solución que les permita relacionarse con sus usuarios desde cualquier
dispositivo.
Figura 16 – Fiori: Tecnología Adaptable
Fuente: http://salvadorgimeno.com/sap-fiori-vs-sap-gui-who-said-user-efficiency-does-not-
matter/
HANA25
: Plataforma de datos en memoria que se puede implementar de manera local o en la
nube. Además, ayuda a las empresas a realizar la transición digital ya que se necesita una
infraestructura de TI que sea ágil, abierta, segura y absolutamente de confianza.
Figura 17 – HANA: Provisionamiento de Datos
Fuente: http://www.slideshare.net/SAPTechnology/inmemory-database-platform-for-big-data
Luego de haber realizado el análisis del entorno interno y externo presentado previamente; a
continuación, se muestra el análisis FODA de la organización.
25 High Performance Analytic Appliance
Figura 18 – Análisis FODA de TSNET S.A.
Fuente: Elaboración Propia
Definir los espacios de mercado:
Los espacios de mercado constituyen las oportunidades en las que un proveedor de servicios
puede ofrecer valor a sus clientes. Para determinarlos es fundamental que primero se
identifiquen los activos y los arquetipos de servicio que brinda la empresa, de manera que se
obtenga como resultado de este análisis una matriz de oportunidades existentes a potenciar y
de nuevas oportunidades.
En la siguiente matriz se diferencian los activos, representados por proyectos, procesos,
información, hardware, áreas de la organización y productos relacionados a SAP, a los cuales
se ha diferenciado por el color naranja para indicar las áreas en las que TSNET S.A. es
especialista, y por el color verde para indicar que son áreas de oportunidad en las que no se
cuenta con experiencia previa. No obstante, representa un nuevo espacio de mercado a
abordar.
Tabla 32 – Matriz de Espacios de Mercado
Fuente: Elaboración Propia
Objetivos:
Como resultado de la presente estrategia, TSNET S.A. orienta sus servicios al cumplimiento
de los siguientes objetivos:
ACTIVOS
Pro
yec
tos
Pro
ceso
s
Info
rmac
ión
Ser
vid
ore
s
Áreas de la Organización Productos
ARQUETIPOS DE
SERVICIOS
Rec
urs
os
Hu
man
os
Fin
anza
s
Lo
gís
tica
Ven
tas
Su
cces
s
Fac
tors
FIO
RI
HA
NA
BI
CR
M
E-F
acto
rin
g
Unid
ad S
AP
Implementación ERP
Optimización Tecnológica
Training
Outsourcing
Localizaciones
Help Desk
Gestión de Procesos
Data Integration
Hosting
Otr
o
Gestión de Proyectos
Áreas especializadas
Áreas de oportunidad
Servicio Objetivo
Implementación
ERP
Brindar a los clientes una herramienta que les permita automatizar
sus procesos y facilitar sus labores operativas, de manera que
puedan contar con la información que necesitan de manera precisa y
oportuna. Este servicio será medido mediante la verificación del
cumplimiento del alcance establecido en el BBP de la prestación del
mismo.
Training Cumplir con las expectativas del cliente con relación a los procesos
manejados en cada módulo de SAP.
Outsourcing Brindar el soporte adecuado y oportuno a los clientes para llevar a
cabo actividades de análisis y mejora en sus desarrollos y procesos.
Localizaciones
Proveer al cliente una herramienta que le permita generar
información que le permita cumplir con los requerimientos de las
normas legales establecidas por SUNAT.
Help Desk Brindar al cliente una atención oportuna y efectiva de incidencias
reportadas en sus diferentes áreas.
Gestión de
Procesos
Brindar al cliente un análisis sobre el estado de sus procesos y
proponer alternativas de solución que ayuden a mejorar la calidad
de los mismos.
Data Integration Proporcionar al cliente una herramienta para asegurar la integridad
en la conversión y transferencia de datos.
Hosting
Apoyar al cliente con la reducción de costos con relación al
mantenimiento de servidores, brindándoles confiabilidad,
disponibilidad y resguardo de su información.
Tabla 33 – Objetivos de los Servicios
Fuente: Elaboración Propia
PLANIFICACIÓN ESTRATÉGICA
Una estrategia es el medio para identificar oportunidades de servicios y saber cómo
aprovecharlos de la mejor manera. Asimismo, para alcanzar los objetivos del negocio se debe
seguir el lineamiento de las 4P’s de la estrategia: Perspectiva, Posicionamiento, Planes y
Patrones.
Perspectiva:
Visión de la Organización:
“Ser socios de largo plazo en tecnologías de información de las compañías más exitosas de la
región, a través de nuestra habilidad reconocida para crear alto valor, alineando la tecnología
a las estrategias de negocio”.
Misión de la Organización:
“Ser una compañía global de Consultoría y Gestión de Servicios de tecnología de
información. Servimos a los clientes que valoran la excelencia en sus procesos a través de la
implantación y operación de soluciones innovadoras sostenibles en el largo plazo, que
incorporan las mejores prácticas de negocio y lo mejor de la tecnología de información”.
Plan:
Nuevos Servicios Identificados:
Se han identificado 3 servicios relevantes para el negocio: Optimización tecnológica,
Localizaciones de E-Factoring y Gestión de Proyectos.
84
Servicio Objetivos del negocio que soporta Prioridad en el negocio Estrategias para lograrlos
Horizonte de
tiempo para
implementac.
Optimización
Tecnológica
Alcanzar los niveles de excelencia en la
calidad de los servicios de tecnología de
información.
Mejorar el posicionamiento de la
organización en el mercado competitivo de
tecnologías de información.
Fortalecer el grado de fidelización de los
clientes.
Promover el desarrollo personal y profesional
de los trabajadores de la organización.
La constante competencia y
exigencia del mercado
impulsan a las empresas a
actualizar y optimizar de la
mejor manera sus recursos
tecnológicos.
Estrechar el relacionamiento
con SAP en relación a los
productos: Success Factors,
FIORI, HANA, BI y CRM.
Generar alianzas
estratégicas con socios
especializados.
Organizar eventos de
presentación a clientes
potenciales.
Desarrollar el talento
interno mediante
capacitaciones SAP.
Mediano plazo
Localizaciones de E-
Factoring
Mejorar el posicionamiento de la
organización en el mercado competitivo de
tecnologías de información.
Solución que ayudará a los
clientes en el cobro de sus
facturas pendientes de pago,
Reforzar el relacionamiento
con los clientes que a los
que se les ha implementado
Corto plazo
Servicio Objetivos del negocio que soporta Prioridad en el negocio Estrategias para lograrlos
Horizonte de
tiempo para
implementac.
Liderar el sector financiero con relación a
tecnologías de información.
Fortalecer el grado de fidelización de los
clientes.
Promover el desarrollo personal y profesional
de los trabajadores de la organización.
de manera que se evite el
manejo de documentos
físicos, y dinero en efectivo.
Ello conlleva a la
disminución de procesos
administrativos y a un mejor
manejo de tasas de
financiamiento.
la solución paquetizada de
localizaciones.
Organizar eventos de
presentación a clientes
potenciales.
Gestión de proyectos Mejorar el posicionamiento de la
organización en el mercado competitivo de
tecnologías de información.
Fortalecer el grado de fidelización de los
clientes.
Promover el desarrollo personal y profesional
de los trabajadores de la organización.
Las empresas requieren de
una adecuada gestión de
proyectos que les permita
llevar un control detallado y
minucioso de los mismos, con
la finalidad de disminuir
costos, maximizar el uso de
recursos, identificar y mitigar
Establecer visitas a los
clientes para conocer su
portafolio de proyectos y
proponer un servicio de
soporte que ayude a la
gestión de los mismos.
Establecer alianzas con
empresas especializadas en
Corto plazo
Servicio Objetivos del negocio que soporta Prioridad en el negocio Estrategias para lograrlos
Horizonte de
tiempo para
implementac.
riesgos a tiempo, y velar por
el cumplimiento de los
objetivos propuestos.
la implementación de
proyectos.
Tabla 34 – Nuevos Servicios Identificados
Fuente: Elaboración Propia
87
Inversiones en Activos Necesarias:
A continuación, se presentan las inversiones mensuales requeridas en activos en un horizonte
de tiempo, clasificadas por servicio.
Servicio Activo Sustento
Horizonte de
tiempo para
adquisición
Valor
aproximado
(alto nivel o
rango)
Optimización
tecnológica
Consultor
Success Factors
Actualmente, la
organización no cuenta
con consultores
especializados en la
configuración e
implementación del
producto.
Mediano plazo US$ 6,500.00
Consultor SAP-
FIORI Mediano plazo US$ 5,500.00
Consultor SAP-
HANA Largo plazo US$ 5,500.00
Consultor SAP-
BI/BO Corto plazo US$ 7,000.00
Consultor SAP-
CRM Mediano plazo US$ 5,500.00
Servidor de
entrenamiento
de Business
Objects
Es requerido para la
generación de
dashboards y demos de
presentaciones.
Corto plazo US$ 50,000.00
Licencia
SAP-HANA
Es requerido para la
utilización del servicio. Mediano plazo
Servicio Activo Sustento
Horizonte de
tiempo para
adquisición
Valor
aproximado
(alto nivel o
rango)
Licencia
SAP-BO
Corto plazo
Licencia
SAP-CRM
Mediano plazo
Gestión de
proyectos
Gestor de
proyectos con
certificación
PMI
La organización no
cuenta con un consultor
especializado. Corto plazo US$ 3,000.00
Help Desk
Aplicación Web
para la solicitud
y gestión de
requerimientos
Es requerido para el
adecuado control y
seguimiento de los
requerimientos de los
clientes.
Corto plazo
US$ 6,000.00
–
US$ 9,000.00
Tabla 35 – Inversiones en Activos Necesarias
Fuente: Elaboración Propia
Oportunidades de Mejora:
Alianzas con Socios Especializados:
Se encuentra una oportunidad de mejora en la formación de alianzas con socios
especializados en servicios tecnológicos que cuenten con un enfoque global y tengan respaldo
internacional. De esta manera, se aspira llegar a mercados fuera de nuestra frontera.
Certificaciones Internacionales:
Se encuentra una oportunidad de mejora en la capacitación y certificación internacional de
los consultores. De esta manera, se garantiza el grado de conocimiento profesional de los
mismos.
Portafolio de Servicios:
A continuación, se codifican los objetivos del negocio sobre los cuales se soportan los
servicios que brinda la organización:
O1: Alcanzar los niveles de excelencia en la calidad de los servicios de tecnología de
información.
O2: Mejorar el posicionamiento de la organización en el mercado competitivo de tecnologías
de información.
O3: Liderar el sector financiero con relación a tecnologías de información.
O4: Fortalecer el grado de fidelización de los clientes.
O5: Promover el desarrollo personal y profesional de los trabajadores de la organización.
90
Nombre del
Servicio Descripción del Servicio Clientes
Objetivos de
negocio que
soporta
Estado del
Servicio
Impacto en
el Negocio
Dueño del
Servicio
Dueño del
Negocio
Implementación
ERP
Servicio que forma parte del Core
del negocio y consiste en proveer
al cliente de un sistema integral de
gestión empresarial que le permita
modelar y automatizar los
procesos de su organización.
San Martin,
Votorantin Metais,
Caudalosa
O1, O2, O4, O5. Existente Medio
Gerencia
Unidad
SAP
Gerente
Comercial
Optimización
Tecnológica
Servicio que provee al cliente del
uso de nuevas tecnologías con la
finalidad de facilitar el análisis de
grandes volúmenes de datos en un
entorno amigable y a la medida.
Por el momento
ninguno. O1, O2, O4, O5. Propuesto Medio
Gerencia
Unidad
SAP
Gerente
Comercial
Training
Servicio orientado a la gestión del
conocimiento de los módulos de
SAP (nivel funcional) y a la
aplicación de buenas prácticas de
programación (nivel técnico).
Grupo SAM O1, O2, O4, O5. Existente Bajo
Gerencia
Unidad
SAP
Gerente
Comercial
Nombre del
Servicio Descripción del Servicio Clientes
Objetivos de
negocio que
soporta
Estado del
Servicio
Impacto en
el Negocio
Dueño del
Servicio
Dueño del
Negocio
Outsourcing
Servicio que busca brindar un
soporte adecuado y oportuno al
cliente para llevar a cabo
actividades de análisis y mejora
en sus desarrollos y procesos.
LAP, AUNA,
Grupo SAM,
Inkafarma, Ripley,
Gloria, Chinalco.
O1, O2, O4, O5. Existente Alto
Gerencia
Unidad
SAP
Gerente
Comercial
Localizaciones
Servicio que provee al cliente de
una herramienta que le permite
generar información para cumplir
con los requerimientos de las
normas legales establecidas por
SUNAT.
LAP, Metso, Grupo
SAM, Ripley, San
Martin, Mead
Johnson, Chinalco,
BASF, Essalud
O1, O2, O3, O4,
O5. Propuesto Alto
Gerencia
Unidad
SAP
Gerente
Comercial
Help Desk
Servicio que brindar al cliente una
atención oportuna y efectiva de
incidencias reportadas en sus
diferentes áreas de negocio.
COGA O1, O2, O4, O5. Existente Alto
Gerencia
Unidad
SAP
Gerente
Comercial
Nombre del
Servicio Descripción del Servicio Clientes
Objetivos de
negocio que
soporta
Estado del
Servicio
Impacto en
el Negocio
Dueño del
Servicio
Dueño del
Negocio
Gestión de
Procesos
Servicio orientado al
entendimiento del negocio del
cliente, análisis, diagnóstico y
propuesta de alternativas de
solución que ayuden a mejorar la
calidad de sus procesos.
PECSA O1, O2, O4, O5. Existente Bajo
Gerencia
Unidad
SAP
Gerente
Comercial
Data Integration
Servicio de gestión de datos que
asegura la integridad de la
extracción, conversión y carga de
datos de un sistema origen a una
plataforma SAP.
Grupo SAM,
Votorantim Metais O1, O2, O4, O5. Existente Bajo
Gerencia
Unidad
SAP
Gerente
Comercial
Hosting
Servicio de alojamiento y
mantenimiento de servidores de
datos que brinda confiabilidad,
disponibilidad y resguardo de
información al cliente.
Petrobras O1, O2, O4, O5. Existente Bajo
Gerencia
Unidad
SAP
Gerente
Comercial
Nombre del
Servicio Descripción del Servicio Clientes
Objetivos de
negocio que
soporta
Estado del
Servicio
Impacto en
el Negocio
Dueño del
Servicio
Dueño del
Negocio
Gestión de
Proyectos
Servicio que orienta y apoya al
cliente en el adecuado manejo de
proyectos mediante la aplicación
de las mejores prácticas y
estándares internacionales.
Por el momento
ninguno. O2, O4, O5. Propuesto Bajo
Gerencia
Unidad
SAP
Gerente
Comercial
Tabla 36 – Portafolio de Servicios
Fuente: Elaboración Propia
94
DESCRIPCIÓN DEL PROCESO DE MANTENIMIENTO DE
SOFTWARE
Dado que el objeto de estudio es una empresa encargada de brindar servicios de consultoría,
específicamente sobre SAP ERP, es necesario precisar que el presente proceso de desarrollo y
mantenimiento de software está orientado a la atención de los requerimientos alcanzados por
parte de los clientes de la empresa mediante el uso del lenguaje de programación ABAP. La
atención de estos requerimientos se lleva a cabo aplicando las mejores prácticas de desarrollo
y bajo el estándar de programación definido por el objeto de estudio. Si la empresa cliente
contara con su propio estándar de programación, se respetará éste último.
Al finalizar la atención de todo requerimiento se deberá realizar la entrega de los siguientes
documentos:
Documento Técnico: Documento que contiene el detalle técnico de la solución
desarrollada.
Documento Funcional: Documento que contiene el detalle de configuración y/o
parametrización realizada en el sistema.
Documento de Pruebas Unitarias: Documento que contiene el detalle de las pruebas
realizadas por el Consultor Senior y/o Desarrollador con respecto a la atención de los
requerimientos alcanzados. Este documento se utilizará, además, como sustento para
corroborar la realización de las pruebas indicadas por el usuario en el detalle del
requerimiento entregado.
Manual de Usuario: Documento que detalla los pasos a seguir para llevar a cabo ciertos
procesos y/o desarrollos. La actualización de este documento estará en función del
cambio que se solicite.
Objetivos que el servicio brinda:
1. Apoyar a las organizaciones con sus labores de mantenimiento y mejora continua de
productos de software, permitiéndoles optimizar recursos y afinar procesos.
2. Garantizar el buen desempeño de productos de software respondiendo de manera
eficiente a los cambios que las organizaciones demanden.
3. Ser considerado como agente estratégico de transformación del negocio mediante la
entrega de valor en la gestión de productos de software.
Objetivos del negocio que apoya:
1. Alcanzar los niveles de excelencia en la calidad de los servicios de tecnologías de la
información.
2. Mejorar el posicionamiento de la organización en el mercado competitivo de tecnologías
de información.
3. Fortalecer el grado de fidelización de los clientes.
Proceso Detallado:
El presente flujo de actividades representa el nuevo modelo propuesto (TO BE) para el
proceso de Mantenimiento y Desarrollo de Software. La diferencia con respecto al modelo
actual, presentado en la Figura 3 del presente documento, radica en lo siguiente:
1. Se utilizará una aplicación web para el registro y solicitud de atención de requerimientos
de parte del cliente. Esta aplicación permitirá contar con lo siguiente:
Llevar un control adecuado de los requerimientos atendidos por cada cliente al que se
preste el servicio de desarrollo y mantenimiento de software.
Conocer en tiempo real, tanto del lado de la empresa prestadora del servicio como del
cliente, el estado de atención de los requerimientos.
Generar reportes que permitan identificar el nivel de atención dedicado a los
requerimientos.
Tomar medidas correctivas oportunas que permitan asegurar el cumplimiento del nivel de
servicio pactado.
2. La documentación técnica, funcional, de pruebas y los manuales de usuario se
mantendrán registrados dentro de un directorio centralizado que permita una correcta
gestión y ubicación de los mismos. Esto marca un punto importante con respecto al
modelo actual en donde gran parte de la documentación se encuentra incompleta o
inubicable. La centralización de la documentación, además, facilitará significativamente
la atención de requerimientos de características similares en otros clientes, permitiendo
mejorar los niveles de servicio acordados y la calidad en la atención de los
requerimientos.
3. Se ha otorgado autonomía a los roles de Consultor Senior y Desarrollador para que
puedan estimar el tiempo a invertir en la atención de los requerimientos, sin la
intervención del Jefe de Proyectos en su aprobación. De esta manera podremos potenciar
su capacidad de autogestión de acuerdo a lo recomendado por el estándar PSP. Se debe
precisar que si bien es cierto que el Jefe de Proyectos ya no participa de manera directa en
la aprobación de tiempos de atención de requerimientos, éste deberá realizar de manera
constante tareas de seguimiento a fin de poder garantizar la integridad de la autonomía de
los consultores en cuanto a estimación de requerimientos se refiere. Asimismo, podrá
hacer uso de los reportes de gestión contenidos en la Aplicación Web para analizar la
calidad del servicio que se está brindando.
97
Figura 19 – Proceso Detallado del Servicio de Mantenimiento y Desarrollo de Software
Fuente: Elaboración Propia
98
HERRAMIENTAS Y PLANTILLAS:
Herramientas:
1. SAP GUI 7.3 es el software que nos permitirá acceder al entorno SAP del cliente para
llevar a cabo las tareas de mantenimiento y desarrollo de software.
2. Software VPN para poder establecer una conexión segura hacia la red del cliente a través
de internet. En caso de que el cliente no trabaje con dicho tipo de software, éste deberá
especificar la cadena SAP Router que se ha de usar para poder acceder hacia su entorno
SAP.
3. Aplicación Web para registro de solicitudes de atención de requerimientos. Esta
aplicación cuenta con la información básica y necesaria para la correcta gestión del
servicio de mantenimiento y desarrollo de software.
Plantillas:
1. Cada solicitud de atención de requerimiento deberá realizarse a través del formato
establecido por el objeto de estudio, el cual se presenta en la sección de Anexos.
2. La documentación funcional, técnica y manual de usuario se deberá realizar en el formato
establecido por el objeto de estudio, el cual se presenta en la sección de Anexos.
MÉTRICAS PARA CONTROLAR EL SERVICIO:
Métrica 1: Respuesta de atención ante un requerimiento.
Descripción breve:
Esta métrica permite analizar qué tan eficiente es el servicio de atención de requerimientos
una vez que se ha ingresado su solicitud de atención. El tiempo máximo de respuesta de
atención estará en función de la prioridad de éstos:
Prioridad Tiempo máximo de respuesta
(A razón de 8 horas diarias)
Urgente 2 horas
Alto 16 horas
Medio 30 horas
Bajo 48 horas
Tabla 37 – Prioridad de Métrica 1 para Controlar Servicios
Fuente: Elaboración Propia
Urgente: Solicitud con un tiempo de atención crítico e importante que afectan o podrían
afectar la operación del sistema.
Alto: Solicitud con un tiempo de atención importante que no afecta directamente la
operación del sistema pero es necesario para cerrar alguna transacción.
Medio: Solicitud con un tiempo de atención intermedio. Son los requerimientos generales
que normalmente no afectan a la operación del sistema.
Bajo: Solicitud con un tiempo de atención menor, es decir, que puede programarse y
coordinarse con LAP.
Objetivo de medición:
Medir la eficiencia del servicio en la atención de requerimientos dentro del nivel de servicio
acordado con el cliente.
Fuentes de información:
Para la medición del nivel de servicio prestado se tomará en cuenta la información del
Aplicativo Web utilizado para el registro de requerimientos. La medición se realizará en base
a todos los requerimientos registrados en el mes que se desee evaluar.
Fórmula:
Las presentes fórmulas son aplicables a los 4 niveles de prioridad establecidos:
Tiempo de Respuesta = (Fecha y Hora de fin de atención) - (Fecha y Hora registro del
requerimiento).
Posteriormente, se medirá el porcentaje de atención de requerimientos dentro del tiempo
establecido.
X(%) = (Cantidad de requerimientos atendidos dentro del tiempo establecido) / (Total de
requerimientos reportados).
Interpretación:
X = Porcentaje de cumplimiento del nivel de servicio.
Interpretación Rango de aceptación
Eficiente 95% <= X <= 100%
Normal 85% < X < 95%
Crítico X < 85%
Tabla 38 – Interpretación de Métrica 1 para Controlar Servicios
Fuente: Elaboración Propia
Roles involucrados:
Usuario: Encargado de reportar y registrar el requerimiento a atender.
Consultor Senior: Encargado de estimas y atender los requerimientos de carácter
funcional.
Desarrollador: Encargado de estimar y atender los requerimientos técnicos.
Jefe de Proyectos: Encargado de generar, analizar y reportar las métricas de cumplimiento
de nivel de servicio.
Métrica 2: Tiempo de corrección de incidentes reportados.
Descripción breve:
Esta métrica permite analizar el tiempo utilizado en la atención de un desarrollo y/o
configuración solicitada. El tiempo máximo de corrección de errores estará en función de la
prioridad de estos:
Prioridad Tiempo máximo de respuesta
(A razón de 8 horas diarias)
Urgente 0.5 horas
Alto 4 horas
Medio 8 horas
Bajo 16 horas
Tabla 39 – Prioridad de Métrica 2 para Controlar Servicios
Fuente: Elaboración Propia
Objetivo de medición:
Medir la eficiencia del servicio en la atención de una solicitud de desarrollo y/o adecuación
de acuerdo al nivel de servicio acordado con el cliente.
Fuentes de información:
Para la medición del nivel de servicio prestado se tomará en cuenta la información del
Aplicativo Web utilizado para el registro de requerimientos. La medición se realizará en base
a todos los requerimientos registrados en el mes que se desee evaluar.
Fórmula:
Las presentes fórmulas son aplicables a los 4 niveles de prioridad establecidos:
Tiempo de Corrección = (Fecha y Hora de fin de corrección) - (Fecha y Hora de inicio de
corrección).
Posteriormente, se medirá el porcentaje de correcciones realizadas dentro del tiempo
establecido:
X(%) = (Cantidad de correcciones dentro de tiempo establecido) / (Total de solicitudes de
corrección reportadas)
Interpretación:
X = porcentaje de cumplimiento del nivel de servicio.
Interpretación Rango de aceptación
Eficiente 80% <= X <= 100%
Normal 70% < X < 80%
Crítico X < 70%
Tabla 40 – Interpretación de Métrica 2 para Controlar Servicios
Fuente: Elaboración Propia
Roles involucrados:
Usuario: Encargado de reportar y registrar el requerimiento a atender.
Consultor Senior: Encargado de estimas y atender los requerimientos de carácter
funcional.
Desarrollador: Encargado de estimar y atender los requerimientos de carácter técnico.
Jefe de Proyectos: Encargado de generar, analizar y reportar las métricas de cumplimiento
de nivel de servicio.
ACUERDOS DEL NIVEL DE SERVICIO (SLA)
El acuerdo de nivel de servicio consiste de un documento contractual entre el proveedor de
servicios y el cliente en el que se fijan los niveles acordados para la medición de calidad del
servicio. Dicho documento permite cubrir aspectos tales como: El alcance del acuerdo,
horario de atención, disponibilidad, funcionalidad, confiabilidad, desempeño, continuidad y
seguridad del servicio.
A continuación, se presenta el Acuerdo de nivel de Servicio establecido entre el objeto de
estudio y el cliente Lima Airport Partners para el Servicio de Mantenimiento y Desarrollo de
Software:
ACUERDO DE NIVEL DE SERVICIO
Este acuerdo se realiza entre TSNET S.A. y LIMA AIRPORT PARTNERS (LAP)
El acuerdo cubre la provisión para el soporte del servicio de Mantenimiento y desarrollo de
software, que consiste en mantener en óptimas condiciones el funcionamiento del sistema
SAP atendiendo requerimientos de usuario, en estrecha coordinación con la Gerencia de
Tecnologías de la Información de LAP.
Este acuerdo permanecerá valido por 12 meses contados desde 01/01/2015 y 31/12/2015. El
acuerdo será revisado anualmente. Cambios menores serán registrados en el formato final del
presente acuerdo, siempre y cuando sean aprobados por ambas partes, y lo cambios hayan
sido gestionados a través del proceso de gestión de cambios.
Firmas:
Nombre: ……………………….. Cargo: ……………………….. Fecha:……………
Nombre: ……………………….. Cargo: ……………………….. Fecha:……………
Descripción del Servicio
El servicio consiste en la realización de tareas de mantenimiento y desarrollo de software en
los diversos módulos SAP con los que cuenta LAP. Estas tareas serán atendidas mediante la
aplicación de altos estándares de calidad y excelencia a través de la asignación de
profesionales altamente calificados y comprometidos a garantizar la operatividad del sistema.
El detalle de atención de cada uno de los requerimientos alcanzados se deberá entregar de
manera mensual, especificando los tiempos incurridos y documentación que incluya:
Cambios realizados.
Programas y transacciones afectadas por los cambios y mejoras realizadas.
Impacto de los cambios y mejoras realizadas.
Listado de órdenes de transporte.
Recomendaciones
Manuales de usuario, y cualquier otra información relevante al servicio.
Alcance del acuerdo
El alcance del servicio comprende:
Soporte de Segundo Nivel a Usuarios: Comprenderá todo tipo de consultas de usuario sobre
el funcionamiento del sistema, solución de problemas, corrección de errores y ayuda en
general para optimizar el uso de los módulos SAP implementado en LAP y los que se
implementen durante la vigencia del presente documento y del sistema SAP en general. El
soporte de primer nivel (local e inmediato) será proporcionado por el personal técnico de la
Gerencia de Sistemas de LAP; los casos no resueltos por el personal de Sistemas de LAP
serán elevados a TSNET S.A. para su resolución.
Los módulos a considerar son los que actualmente se encuentran en el ambiente de
Producción SAP y comprende:
Módulo de Contabilidad y Finanzas (FI)
Módulo de Costos y Presupuesto (CO)
Módulo de Ventas y Facturación (SD), incluye Facturación Electrónica.
Módulo de Rentas y Concesiones (RC) desarrollado a la medida por LAP (programación
Z).
Módulo de Operaciones Aeroportuarias (OA) desarrollado a la medida por LAP
(programación Z).
Módulo de Logística (MM)
Módulo de Mantenimiento (PM)
Módulo de Activos Fijos (AM)
Módulo de Inversiones (IM)
Módulo de Project System (PS)
Módulo de Flujos de Trabajo (Workflow)
El tiempo de respuesta esperado para la atención de incidentes, desde que se reporta hasta que
se notifica la resolución de los mismos, estará en función a su prioridad:
Prioridad Tiempo máximo de respuesta
(A razón de 8 horas diarias)
Urgente 2.5 horas
Alto 6 horas
Medio 12 horas
Bajo 24 horas
Tabla 41 – Tiempo Máximo de Atención por Prioridad
Fuente: Elaboración Propia
1. Mantenimiento de Software: Se realizarán cambios de configuración, correcciones y
mejoras del software empleando el lenguaje ABAP y siguiendo la metodología
recomendada por SAP, empleando los ambientes de desarrollo y QAS. El mantenimiento
debe incluir la realización de pruebas unitarias e integrales.
2. Desarrollo de Software: Se realizará el desarrollo de nuevos módulos, rutinas y funciones
empleando el lenguaje ABAP y siguiendo la metodología recomendada por SAP,
empleando los ambientes de desarrollo y QAS. Comprenderá además desarrollo de
interfaces con otros sistemas. El desarrollo debe incluir el análisis de la problemática en
conjunto con el área de sistemas, el desarrollo de la solución, la realización de pruebas
unitarias e integrales y ejecución de capacitaciones si se requiere.
Con respecto a este punto se debe tener en cuenta que a efectos de iniciar un óptimo
proceso de mantenimiento y desarrollo de software, TSNET S.A. se compromete en
realizar la revisión de la configuración actual de los módulos estándar SAP y los módulos
a medida LAP implementados en el ambiente de Producción; lo que también ayudará a
proponer la implementación de nuevos escenarios o mejora de estos de acuerdo a las
necesidades actuales.
Para la atención de proyectos de mejora continua, TSNET S.A. debe presentar Planes de
Implementación que incluyan: Cronograma de actividades, relación de recursos humanos
involucrados y recursos técnicos requeridos, contemplando como mínimo las siguientes
actividades:
- Confirmación de requerimientos de usuario (Confirmación de la definición y alcance
del Proyecto).
- Presentación de propuestas de mejora a la configuración, procesos, accesos, lógica de
programas y nuevos flujos de trabajo.
- Entrega de documentación de mejoras a la configuración, procesos, accesos, lógica de
programas y nuevos flujos desarrollados.
- Capacitación y entrenamiento a usuarios y personal técnico.
3. Documentación del sistema y de todos los servicios realizados.
Nota: No comprende el servicio BASIS ya que este es proporcionado por el proveedor de
Hosting.
Condiciones del Servicio
Las licencias SAP que utilizara TSNET S.A. serán otorgadas por LAP.
TSNET S.A. debe asumir todos los costos inherentes a:
- Recursos Humanos de su empresa para la provisión del servicio.
- Computadoras para su propio personal para la adecuación y/o desarrollo del software.
- Carga de datos básicos y parámetros del sistema.
- Capacitación de los usuarios.
- Viáticos y viajes de los consultores.
Horario del Servicio
El horario de trabajo se en horario de oficina de 8:30 am a 18:30 de lunes a viernes.
Funcionalidad
A continuación se presenta el número de errores permitidos por prioridad, aplicable tanto a
configuración como desarrollo, antes de considerar el SLA como incumplido:
Prioridad Número de errores permitidos
Urgente 0
Alto 2
Medio 5
Bajo 10
Tabla 42 – SLA: Número de Errores permitidos por Prioridad
Fuente: Elaboración Propia
Disponibilidad del Servicio:
La disponibilidad del servicio se mantendrá de acuerdo al horario establecido, de Lunes a
Viernes de 08:00am a 06:00pm, y bajo los tiempos acordados según la prioridad del
requerimiento. En caso excepcional y de suma urgencia se considerará la atención los días
sábado, domingo y/o feriados, previo acuerdo con el consultor a cargo.
Seguridad
Todos los cambios y mejoras sin excepción son propiedad del cliente, por lo que TSNET S.A.
no podrá exigir ningún derecho de compensación a su favor ni copiar o reproducir modelos
de negocio y/o desarrollos del cliente implementados por terceros.
Centro de servicios
El equipo de mantenimiento y desarrollo de software puede ser contactado al 710-4400 o
escribiendo al correo [email protected].
PLAN DE CAPACIDAD
La Gestión de la Capacidad tiene como finalidad establecer las condiciones mínimas que
permitan asegurar el correcto funcionamiento de los servicios de TI. A continuación se
presentará el Plan de Capacidad diseñado para el proceso de mantenimiento y desarrollo de
software para el objeto de estudio:
NOMBRE DEL SERVICIO:
Proceso de mantenimiento y desarrollo de software
ANTECEDENTES:
TECNOLOGÍA Y RECURSOS ACTUALES UTILIZADOS
El equipo de trabajo que brinda el servicio de mantenimiento y desarrollo de software está
compuesto de: 3 Jefes de Proyectos, 5 Arquitectos ABAP, 3 Consultores Senior y 3
Desarrolladores. La definición de los perfiles asociados a los cada uno de los puestos de
trabajo son descritos en la sección Arquitectura de Personal del capítulo 2 en el presente
documento.
A continuación presentamos los conocimientos y capacidades técnicas requeridas para cada
uno de los puestos de trabajo mencionados:
Jefe de Proyecto:
Experiencia mínima de 3 años en gestión de proyectos.
Certificación PMI (opcional)
Certificación ITIL Foundation (opcional).
Arquitecto ABAP:
Experiencia mínima de 6 años en proyectos ABAP.
Certificación ABAP con SAP Netweaver 7.31
Consultor Senior:
Experiencia mínima de 4 años en proyectos ABAP, para consultores de perfil técnico.
Experiencia mínima de 4 años en áreas operativas y 3 proyectos de implementación, para
consultores de perfil funcional.
Certificación ABAP con SAP Netweaver 7.31, para consultores de perfil técnico.
Certificación en módulo SAP, para consultores de perfil funcional.
Desarrollador:
Experiencia mínima de 1 años en proyectos de desarrollo ABAP.
Certificación ABAP con SAP Netweaver 7.31 (deseable).
Las herramientas a utilizar para brindar el servicio de mantenimiento y desarrollo de software
son:
SAP GUI 7.3: Aplicativo que permite acceder a los sistemas SAP del cliente y realizar las
tareas de soporte.
Software VPN: Aplicación que permite establecer conexión a la red del cliente y acceder
al entorno SAP del mismo. Este software solo será necesario si el cliente manejará el
acceso a su red a través de este método; de lo contrario, podría establecer la conexión vía
cadena de conexión SAP Router.
Aplicación Web para registro de solicitudes de atención de requerimientos cliente.
Para garantizar una correcta ejecución del servicio es necesario que el cliente cuente como
mínimo con los siguientes servidores:
Servidor de Desarrollo: Ambiente sobre el cual se realizaran tareas de configuración y
desarrollo de programas.
Servidor de Calidad: Ambiente sobre el cual se realizaran tareas de testing y validación de
cambios realizados.
Servidor de Producción: Ambiente operativo sobre el que se aplica finalmente las
adecuaciones y mejoras realizadas al sistema.
Cada persona dentro del equipo de trabajo del proceso deberá contar con una laptop
acondicionada a la labor encargada. El número de tareas de mantenimiento es de al menos 1
vez al año y su renovación se realizará cada 3 años.
NIVELES ACTUALES DE CAPACIDAD
Los niveles actuales de capacidad se vienen dando por lo siguiente:
El promedio de requerimientos atendidos de manera mensual es de 80.
El porcentaje de requerimientos cerrados dentro del mes de reporte es del 99%.
El número promedio de requerimientos que no cumple con el SLA establecido es de 1
mensual y solo para aquellos requerimientos de prioridad Alta.
Atención en horario de oficina de 09:00am a 07:36pm (48 horas semanales) de Lunes a
Viernes.
El número de horas hombres diarias asignadas a la atención de requerimientos, por
cliente, es el siguiente:
Puesto Número de horas hombre
por unidad de tiempo
Jefe de Proyecto 1.0h/día
Arquitecto ABAP 9.6h/día
Consultor Senior 9.6h/día
Desarrollador 9.6h/día
Tabla 43 – Niveles de Capacidad por Puesto
Fuente: Elaboración Propia
El promedio de atención de requerimientos por prioridad en un mes es el siguiente:
Prioridad Tiempo promedio de atención
Urgente 01:23:00
Prioridad Tiempo promedio de atención
Alto 09:41:41
Medio 16:29:00
Bajo 08:30:00
Tabla 44 – Promedio de Atención de Requerimientos por Prioridad
Fuente: Elaboración Propia
PROBLEMAS ACTUALES RELACIONADOS POR EXCESO O FALTA DE
CAPACIDAD
Se han presentado ocasiones, generalmente en el último tercio del año, que es la época con
mayor solicitud de atención de requerimientos por cierre del año, en la que se ha evidenciado
falta de recursos para atender proyectos de mejora continua por temas del entes fiscalizador
SUNAT, tales como: Facturación Electrónica o presentación de información contable. Ante
esto, se ha tenido que recurrir a la atención en doble turno, que si bien es cierto disminuye la
tasa de requerimientos en cola, no termina por cubrir el completado de atención demandante.
ESCENARIOS DE NEGOCIO:
En el presente año TSNET S.A. viene atendiendo requerimientos de manera continua a
clientes de las industrias: Financiera, Gobierno, Minería, Ingeniería y Construcción, Industria
y Comercio, y Servicios.
El plan de la empresa para el presente año no ha sido únicamente el de mejorar el crecimiento
del ticket promedio de atención, sino el de crecer como socio estratégico de las
organizaciones a través de la participación en proyectos de expansión tales como Roll-Outs
(2) e Implementaciones de SAP ERP (1).
De igual manera, se ha logrado tener una mayor participación en el mercado mediante la
implementación de nuevos productos SAP, tales como: Fiori (2) y SuccessFactors (1).
RESUMEN DE RECURSOS:
USO ACTUAL DE RECURSOS
El equipo actual de trabajo permite a la fecha cubrir las necesidades de atención de
requerimientos de los clientes.
Sin embargo, ante las últimas adecuaciones solicitadas por el ente fiscalizador SUNAT, y que
se deben tener preparadas para inicios del año 2016, se ha visto la necesidad de incrementar,
en el corto plazo, la cantidad de desarrolladores en 2. Asimismo, con la finalidad de continuar
con el objetivo de crecer en participación de mercado a través de la entrega de nuevos
productos y servicios, se presenta a continuación el cuadro con la ampliación de recursos para
el mediano y largo plazo:
Recurso Uso actual Corto Plazo Mediano Plazo Largo Plazo
Jefe de Proyecto 3 3 3 3
Arquitecto ABAP 5 5 5 5
Consultor Senior 3 3 4 5
Desarrollador 3 5 5 5
Tabla 45 – Uso actual de Recursos
Fuente: Elaboración Propia
PROYECCION DE RECURSOS
De acuerdo a la tendencia de los proyectos atendidos en el año anterior y el presente, se ha
evidenciado un incremento en la demanda de proyectos de Mantenimiento y desarrollo de
software, específicamente: 2 Roll-outs y 1 implementación. De mantenerse la tendencia, será
necesario contar con nuevos recursos que permitan seguir atendiendo la demanda del
servicio.
Si bien es cierto que se espera seguir creciendo en cuanto a la prestación del servicio, es
necesario precisar que dicho crecimiento es incierto debido al factor económico que las
organizaciones atraviesen en el siguiente año. Sin embargo, en el presente cuadro
presentaremos los recursos que serán necesarios si la demanda del servicio aumenta:
Tipo de Proyecto Recurso Cantidad Requerida
Roll Out Jefe de Proyectos 1
Consultor Senior - MM 1
Consultor Senior – FI 1
Consultor Senior – SD 1
Consultor Senior – CO 1
Desarrollador 2
Implementación ERP Jefe de Proyectos 1
Consultor Senior - MM 1
Consultor Senior – FI 1
Consultor Senior – SD 1
Consultor Senior – CO 1
Consultor Senior – HR 1
Desarrollador 4
Implementación
SuccessFactors
Consultor SuccessFactors 1
Analista de Procesos 1
Implementación SAP Fiori Consultor SAP Fiori 1
Desarrollador 1
Implementación SAP HANA Consultor SAP Hana 1
Hardware Laptops (*) 6
Tabla 46 – Proyección de Recursos
Fuente: Elaboración Propia
(*) Solo se considera laptops para el personal con perfil de Desarrollador. El Consultor
Senior podrá contar con su laptop personal como herramienta de trabajo.
RECOMENDACIONES:
De acuerdo a la información y la experiencia recabada durante los proyectos ejecutados en el
presente año, se recomienda realizar lo siguiente:
1. Gestionar la documentación de los requerimientos atendidos en un repositorio central, de
manera que sean fáciles de ubicar y de reutilizar en la futura atención de requerimientos
con características similares.
2. Realizar cursos de capacitación interna sobre tecnologías nuevas aplicadas con éxito en
los diversos clientes de la unidad, de manera que el personal se encuentre en la capacidad
de dar soporte y atender futuras necesidades de nuevos clientes sin la necesidad de contar
siempre con los mismos consultores especializados.
3. Aprovechar el material disponible de los nuevos productos adquiridos por SAP, como
SuccessFactors, en la generación de proyectos internos con la finalidad de fomentar la
investigación y el desarrollo de nuevas capacidades.
4. Fomentar la autogestión del personal en la realización de tareas y asignaciones de trabajo
para formar capacidades como el sentido de responsabilidad, productividad y calidad de
trabajo.
PROCESOS DE GESTIÓN DE CAMBIOS
Tal como lo indica el PMBOK26
, el proceso de Gestión de Cambios tiene como principal
objetivo asegurar que los cambios requeridos en la organización se notifiquen, clasifiquen en
función de su impacto y nivel de riesgo, prioricen, autoricen, implementen, prueben de
manera controlada, y documenten bajo un procedimiento estandarizado. Asimismo, estos
cambios deben aportar valor al cliente el cual, de acuerdo a ITIL, está representado por el
nivel de servicio que cubre las expectativas del cliente.
Es en este proceso donde encontramos la fórmula para garantizar el valor de un servicio:
VALOR = UTILIDAD + GARANTÍA. La utilidad asegura que se cumplan con los requisitos
del cliente, mientras que la garantía asegura que el servicio cumpla los niveles de calidad
acordados.
NOMBRE DEL PROCESO: GESTION DE CAMBIOS DEL SERVICIO DE
MANTENIMIENTO Y DESARROLLO DE SOFTWARE
ELEMENTOS DE CONFIGURACION SUJETOS A CAMBIOS
Los elementos de configuración constituyen cualquier producto cuyo cambio pueda resultar
crítico para el desarrollo del proyecto. Además, no solo se deben tomar en cuenta los
productos finales que se entregan al cliente como el mantenimiento y desarrollo de software,
sino también productos que son elaborados a lo largo del desarrollo del proyecto como lo es
la documentación.
Los elementos de configuración cuyos cambios son gestionados a través de este proceso son:
26 Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK
®) Cuarta
Edición.
Requerimientos de desarrollo de software (RFC27
).
Diseño de prototipos.
Código fuente.
Plan de integración del software.
Plan de pruebas: Unitarias, de integración, de sistemas, de aceptación de usuario (UAT28
).
Plan de instalación y mantenimiento.
Informe de cierre de proyecto.
PROCESO DETALLADO
La consultora TSNET S.A., quien brinda servicios de consultoría, no lleva a cabo la gestión
de cambios ya que es un proceso manejado directamente por el lado del cliente. Sin embargo,
a continuación se presenta un diagrama genérico del proceso de gestión de cambios que
aplica a cualquier empresa cliente.
27 Request For Change, documento formal que contiene la propuesta de cambio de algún
producto o servicio.
28 Unit Acceptance Testing, documento formal de las pruebas de aceptación de usuario con
relación a la implementación o adecuación de un producto o servicio.
120
Figura 20 – Diagrama de Flujo Detallado del Proceso de Gestión de Cambios
Fuente: Elaboración Propia
121
HERRAMIENTAS Y PLANTILLAS
Herramientas:
Actualmente, no se cuenta con una herramienta que permita el ingreso de solicitudes de
cambio. No obstante, se propone el uso de una aplicación centralizada para cumplir con este
cometido.
1. Aplicación Web: Permite el ingreso y actualización continua de las solicitudes de cambio.
De esta manera, el rol interesado puede darle seguimiento en línea a la situación de cada
solicitud de cambio.
Plantillas:
1. Formato de RFC: Cada solicitud de cambios notificada por el cliente se describe y detalla
debidamente en un documento llamado Request For Change (RFC). Ver anexo 3.
MÉTRICAS PARA CONTROLAR EL SERVICIO:
Métrica 1: Porcentaje de RFCs registrados que hayan sido atendidos fuera del tiempo
estimado.
Descripción breve:
Permite medir el porcentaje de solicitudes de cambio que no han sido atendidas dentro de los
tiempos estimados.
Objetivo de medición:
Identificar las solicitudes de cambio que han excedido el tiempo estimado de implementación
para un determinado periodo de tiempo.
Fuentes de información:
De lo registrado en la Aplicación Web se toman los siguientes datos:
1. Todos los RFC, registrados en un periodo, cuya fecha de cierre se encuentre fuera de la
fecha límite estimada.
2. Se obtienen los elementos de configuración, el motivo del desfase de tiempos, el tipo de
impacto y riesgos considerados.
Fórmula:
X(%) = (Cantidad de RFC registrados en un período y cerrados fuera de fecha) / (Cantidad de
RFC registradas en un período).
Interpretación:
X = Porcentaje de RFCs cerrados fuera de fecha.
Interpretación Rango de aceptación
Normal 0% <= x <= 10%
Observado 10% < x <= 25%
Crítico x < 25%
Tabla 47 – Interpretación de Métrica 1 para controlar el Servicio – Control de Cambio
Fuente: Elaboración Propia
Roles involucrados:
Iniciador: Rol que reporta la necesidad de cambio. Por ejemplo:
Usuario clave de un proceso que requiere una mejora de alto o mediano impacto.
Administrador de base de datos que identifica la lentitud de un proceso, convirtiéndose en
cuello de botella de otros procesos.
Responsable de calidad que notifica que no se cumplen con los procedimientos y
documentación para la eficiente operatividad de un determinado proceso.
Jefe de Proyecto: Rol que elabora el RFC y lo envía al gestor de cambio para su
evaluación. Cabe mencionar que el RFC debe contemplar al menos la fecha y motivo de
la solicitud de cambio, elementos de configuración, prioridad, plan de implementación y
plan de RollBack.
Gestor de Cambio: Rol que realiza el análisis del RFC, teniendo en consideración el
alcance, impacto y riesgos del mismo.
Comité de Gestión de Cambio: Rol que evalúa el RFC y lo aprueba o rechaza.
TSNET: Rol que realiza el análisis técnico-funcional y le envía al gestor de cambio la
estimación de tiempos, recursos requeridos y costos.
PROCESOS DE PRUEBA DEL SERVICIO
En la siguiente sección describiremos el proceso de realización de pruebas tanto para
requerimientos funcionales como técnicos. Es necesario precisar, que al ser el objeto de
estudio una empresa de consultoría, la realización de pruebas integrales se encuentra del lado
del cliente con soporte del consultor o desarrollador a cargo.
Servicio Asociado
Servicio de Mantenimiento y desarrollo de software.
Objetivos de la prueba
Validar que la atención de los requerimientos cubra cada uno de los puntos detallados por
el usuario.
Validar que las adecuaciones realizadas no interfieran con funcionalidades ya existentes.
Minimizar el número de incidentes que se producen en el ambiente de Producción.
Pre-requisitos para la realización de la prueba
Los casos de prueba deben acompañar el requerimiento alcanzado por el usuario.
Se debe contar con datos en el ambiente de Desarrollo y/o Calidad, dependiendo del
ambiente destinado por el cliente, para la realización de las pruebas unitarias.
Características del ambiente de pruebas
Para la realización de pruebas de los requerimientos atendidos es necesario contar con
ambientes que garanticen la correcta ejecución de:
Pruebas Unitarias: Realizadas por el Consultor Senior y/o Desarrollador en función de los
casos de prueba alcanzados como parte del requerimiento a atender.
Pruebas de Integración: Realizadas por el Consultor Senior y/o Desarrollador cuando la
atención del requerimiento pueda afectar a funcionalidades ya existentes o se vea
comprometida la integración de otros módulos.
Pruebas de Sistemas: Realizadas por el usuario con datos similares a los del ambiente de
Producción.
Pruebas de Aceptación: Realizadas por el usuario para dar la conformidad de lo realizado.
Se debe tener en cuenta que la realización de estas pruebas se debe realizar dentro de un
ambiente con datos y escenarios de prueba tan iguales a los del ambiente Productivo. La
asignación de servidores estará en función del landscape del cliente.
Proceso Detallado
En este proceso participan los roles de:
Tester, que es la persona encargada de realizar atender el requerimiento y llevar a cabo la
realización de pruebas unitarias. Esta persona puede ser el Consultor Senior o el
Desarrollador.
Usuario, que es la persona encargada de realizar las pruebas de aceptación de lo realizado.
Figura 21 – Diagrama de Flujo Detallado del Proceso de Prueba del Servicio
Fuente: Elaboración Propia
HERRAMIENTAS Y PLANTILLAS:
Herramientas:
1. Para el manejo centralizado de la documentación de pruebas se utilizará Microsoft
SharePoint.
Plantillas:
1. Los requerimientos, además de ser registrados dentro de la Aplicación Web destinada
para dicho fin, se deberán de especificar dentro del formato establecido por el objeto de
estudio. Este formato es establecido dentro de la sección de Anexos.
2. Scripts de pruebas.
MÉTRICAS PARA CONTROLAR EL SERVICIO:
Métrica 1: Número de rechazos por pruebas integrales.
Descripción breve:
Esta métrica permite analizar la calidad del servicio entregado al cliente y que tan minuciosas
son las tareas de análisis y pruebas de parte del equipo de Mantenimiento y Desarrollo de
software. La medición se realizará desglosando la información de los requerimientos por
módulo SAP y nivel de prioridad.
Objetivo de medición:
Medir la eficiencia del servicio de atención de requerimientos.
Fuentes de información:
Para el análisis de la métrica se tomará en cuenta la información del Aplicativo Web utilizado
para el registro de requerimientos. La medición se realizará en base a todos los
requerimientos registrados en el mes que se desee evaluar.
Fórmula:
La presente fórmula es aplicable a todos los módulos de SAP y a los 4 niveles de prioridad
establecidos (Urgente, Alto, Medio y Bajo):
X = número de rechazos registrados / número de requerimientos alcanzados
Interpretación:
X = Promedio de rechazos registrados.
Nivel de Prioridad
Interpretación Urgente Alto Medio Bajo
Eficiente X = 0 X <= 1 X <= 2 X <= 4
Normal X = 0 X = 2 2 < X <= 4 X = 5
Crítico X >= 1 X > 2 X > 4 X > 5
Tabla 48 – Nivel de Prioridad de Métrica 1: Número de rechazos por pruebas integrales
Fuente: Elaboración Propia
Roles involucrados:
Usuario: Encargado de registrar, reportar y llevar a cabo las pruebas de sistemas y
aceptación de los requerimientos a su cargo.
Tester: Encargado de realizar la atención del requerimiento y de llevar a cabo las pruebas
unitarias e integración de lo realizado.
Jefe de Proyectos: Encargado de generar y analizar la métrica definida para gestión de
pruebas.
CONCLUSIONES
1. La aplicación del marco de trabajo propuesto por ITIL en el proceso de mantenimiento y
desarrollo de software del objeto de estudio, ha permitido comprender la importancia de
entregar no solo un servicio que cubra lo que el cliente espera, sino que además
contribuya a que estos reconozcan a su proveedor de servicios como potencial socio en la
transformación de sus procesos de negocio.
2. ITIL ha contribuido a la identificación de debilidades existentes en el actual proceso de
Mantenimiento y Desarrollo de Software, tales como: Una inadecuada gestión de
requerimientos, falta de definición de métricas para evaluación de servicios, y falta de
detalle en la definición de SLAs con los clientes; lo que ha permitido proponer soluciones
que ayuden a fortalecer y mejorar la calidad del servicio y los entregables que lo
acompañan.
3. Se ha visto a bien la adopción del procedimiento definido por ITIL para la identificación
de nuevos espacios de mercado y la definición de servicios que los cubran, ya que en la
actualidad éstos se vienen definiendo de manera empírica, lo que en su mayoría ha
contribuido al mal uso de recursos y que incluso, sea detenidos en el camino.
4. Se ha logrado comprender que si bien es cierto, una adecuada gestión de servicio asegura
la calidad de su entrega, ésta se puede ver potenciada por el personal que viene detrás.
Para ello, se complementará el marco de trabajo propuesto por ITIL con el modelo de
buenas prácticas propuestos por el estándar PCMM.
CAPÍTULO 4: ARQUITECTURA EMPRESARIAL
INTRODUCCIÓN
En el presente capítulo se presentará el análisis realizado para la implementación de
Arquitectura Empresarial sobre dos de los procesos estratégicos de la organización y un
proceso de apoyo, utilizando a TOGAF como marco de referencia para el análisis de brechas
entre la situación actual de estos (ASIS) y la situación de mejora a la que se espera llegar
(TOBE).
ALCANCE
El presente documento muestra la definición de Arquitectura Empresarial para la
organización objeto de estudio: TSNET S.A. La solución a plantear está enfocada sobre los
procesos estratégicos de Gestión Comercial y Gestión de Proyectos, extendiendo su alcance
al proceso de apoyo de Gestión de Facturación, y abarca las cuatro vistas de arquitectura
empresarial: Negocio, Aplicaciones, Datos e Infraestructura.
Sobre los procesos mencionados se presentará el análisis de brechas realizado entre la
situación actual de estos (ASIS) y la situación destino a la que se espera llegar (TOBE).
METAS, CUMPLIMIENTOS Y LIMITACIONES
Metas y cumplimientos
Integrar en una única plataforma los procesos de Gestión Comercial, Gestión de
Proyectos y Gestión de Facturación.
Asegurar la rentabilidad del 100% de los proyectos mediante la implementación de un
sistema de alertas que permita detectar y notificar posibles desviaciones en costes y
tiempos de proyectos.
Proporcionar reportes en línea que permitan conocer la situación real del 100% de los
proyectos manejados por la empresa.
Reducir en un 100% la labor manual en cuanto a la elaboración de reportes de costes y
tiempos de proyectos.
Estandarizar y documentar el 100% de las actividades dentro de los procesos de Gestión
de Proceso, Gestión de Proyectos y Gestión de Facturación.
Limitaciones
Falta de integración entre sistemas que soportan procesos estratégicos de la empresa.
Duplicidad de información y tareas entre los sistemas que soportan los procesos
estratégicos de la empresa.
Poca interacción de responsables con el sistema de Gestión de Proyectos.
El sistema para Gestión de Proyectos no proporciona alertas ni herramientas para conocer
situación real del proyecto en cuanto a cumplimiento de tareas y seguimiento de
responsables.
Alta dependencia de Hojas de Alta en formato Excel para análisis de costos y rentabilidad
de proyecto.
Elaboración manual de reportes relacionados a la toma de decisiones.
No contar con un área de innovación dedicada a la investigación de nuevas tecnologías y
desarrollo de productos.
RIESGOS Y PROBLEMAS
Para identificar los factores de riesgo que pueden poner en peligro el desarrollo del proyecto
se emplea la matriz de probabilidad e impacto definida por el PMBOK.
Figura 8 – Matriz de Probabilidad e Impacto
Fuente: Guía del PMBOK
Donde las escalas para la probabilidad e impacto son:
Escala Relativa Probabilidad
Nada probable 0.10
Poco probable 0.30
Medianamente probable 0.50
Bastante probable 0.70
Muy probable 0.90
Tabla 2 – Escalas de Probabilidad e Impacto
Fuente: Guía del PMBOK
A continuación, se presenta la matriz de riesgos identificados para la implementación del
proyecto, donde la columna Resultado define la prioridad de atención de acuerdo a los
siguientes colores:
Figura 9 – Importancia de los Riesgos
Fuente: Guía del PMBOK
Escala Relativa Impacto
Muy bajo 0.05
Bajo 0.10
Moderado 0.20
Alto 0.40
Muy alto 0.80
134
Matriz de riesgos
N° Riesgo Descripción Probabi. Impacto Resultado Estrategia de mitigación
1
No disponibilidad de
recursos al 100% para
el desarrollo del
proyecto.
Debido a que la integración es un proyecto interno
de la organización, la asignación de los consultores
podría verse afectada por la necesidad de su
participación en proyectos externos facturables.
Ello podría conllevar a una desviación de tiempos
estimados para el proyecto.
0.50 0.80 0.40
Proponer un esquema de
trabajo de doble turno para no
afectar los tiempos del plan de
proyecto.
2
Falta de
involucramiento de
usuarios clave.
Los usuarios clave son los gerentes de línea de
negocio, la PMO, la asistente contable, y la
asistente de recursos humanos, quienes muchas
veces debido a su carga laboral diaria no pueden
participar al 100% en las definiciones del proyecto.
0.50 0.80 0.40
Establecer cronogramas de
reuniones con los usuarios
clave de manera semanal o en
momentos donde la carga
laboral no sea tan exigente para
ellos.
3 Posibles problemas de
infraestructura.
El mantenimiento de los servidores de Oracle no
está a cargo del personal de TI de la organización
sino que se da de manera externa. Ello ocasiona que
algunas veces la atención de problemas con los
servidores no sea inmediata.
0.30 0.40 0.12
Implementar operaciones de
mantenimiento preventivo de
los servidores.
Matriz de riesgos
N° Riesgo Descripción Probabi. Impacto Resultado Estrategia de mitigación
4 Resistencia al cambio.
Actualmente, los Gerentes de Línea de Negocio
están habituados al manejo de sus tareas de manera
manual e independiente, por lo que se puede
presentar un malestar respecto a los nuevos
procedimientos a considerar en la integración de las
aplicaciones.
0.30 0.40 0.12
Concientizar a los Gerentes de
las Líneas de Negocio sobre la
importancia y los beneficios
que trae consigo la integración
de la información en una única
plataforma.
5
Definición incorrecta
del alcance del
proyecto.
Falta de compromiso o desconocimiento de algunas
tareas por parte de los involucrados al momento de
establecer las definiciones de los requerimientos del
proyecto.
0.30 0.40 0.12
Establecer reuniones de control
una vez por semana para
revisar los avances del
proyecto.
6
Rotación de los
usuarios clave del
proyecto.
Asignación de usuarios clave a actividades ajenas al
proyecto, que puedan generar retrasos en el plan de
trabajo, o conllevar a la definición errada de
requerimientos.
0.10 0.40 0.04
Coordinar con las áreas
correspondientes para asegurar
la participación ininterrumpida
de los usuarios clave.
Tabla 49 – Matriz de Riesgos
Fuente: Elaboración Propia
136
ARQUITECTURA LINEA BASE (AS IS)
Existen diversos frameworks29
que buscan que la arquitectura a desarrollarse e implementarse
apoye a los objetivos y requerimientos del negocio. Para ello, primero se debe identificar la
situación actual de la organización, luego determinar la situación deseada y, finalmente, hacer
el análisis de brechas correspondiente.
A continuación, se muestra el detalle de los 4 dominios de la arquitectura, que soportan a la
organización, contemplados en el ADM30
de TOGAF, mencionado en el marco teórico del
capítulo 1.
ARQUITECTURA DE NEGOCIO (AS IS)
En esta arquitectura se definen y clasifican los procesos clave para la organización, los cuales
se clasifican empleando la siguiente ponderación:
RANGO INFERIOR RANGO SUPERIOR CATEGORÍA DE PROCESO
1% 30% Operativo
31% 60% Táctico
61% 100% Estratégico
Tabla 50 – Clasificación de Procesos de Negocio
Fuente: Elaboración Propia
29 Marcos de referencia conformados por componentes que actúan como base para la
estructuración y ensamble de componentes en construcciones más complejas.
30 Architecture Development Method, provee el paso a paso para el desarrollo e
implementación de la arquitectura empresarial.
En base a la arquitectura de negocios actual de la organización se presenta la matriz de
Objetivos Estratégicos vs. Procesos de Negocio.
Procesos Estratégicos Procesos Tácticos Procesos
Operativos
Objetivos Estratégicos
Gesti
ón de
Carte
ra de
Prod
uctos
y
Servi
cios
Ges
tión
Co
mer
cial
Ges
tión
de
Pro
yect
os
Gesti
ón de
Recu
rsos
Hum
anos
Gestió
n de
Infraest
ructura
e
Inform
ación
Ges
tión
de
Co
mpr
as
Gesti
ón
Admi
nistra
tiva
Gestió
n de
Factura
ción
Ges
tión
de
Ase
sorí
a
Leg
al
1. Incrementar las ventas y reducir
costos de proyectos mediante una
mejor gestión de los mismos.
1 1 1 1 0 0 0 0 0
2. Alcanzar los niveles de excelencia
en la calidad de los servicios de
tecnología de información.
1 1 1 1 1 0 0 0 0
3. Mejorar el posicionamiento de la
organización en el mercado
competitivo de tecnologías de
información.
1 1 1 1 1 1 1 0 0
4. Liderar el sector financiero con
relación a tecnologías de información. 1 1 1 0 0 0 0 0 0
5. Fortalecer el grado de fidelización de
los clientes. 1 1 1 1 0 0 0 1 1
Procesos Estratégicos Procesos Tácticos Procesos
Operativos
Objetivos Estratégicos
Gesti
ón de
Carte
ra de
Prod
uctos
y
Servi
cios
Ges
tión
Co
mer
cial
Ges
tión
de
Pro
yect
os
Gesti
ón de
Recu
rsos
Hum
anos
Gestió
n de
Infraest
ructura
e
Inform
ación
Ges
tión
de
Co
mpr
as
Gesti
ón
Admi
nistra
tiva
Gestió
n de
Factura
ción
Ges
tión
de
Ase
sorí
a
Leg
al
6. Promover el desarrollo personal y
profesional de los trabajadores de la
organización.
0 1 1 1 1 1 1 0 0
Resultado 5 6 6 5 3 2 2 1 1
Tabla 51 – Matriz de Objetivos Estratégicos vs. Procesos de Negocio
Fuente: Elaboración Propia
En base a la matriz de justificación anterior se ha categorizado a los procesos de la siguiente
manera:
PROCESOS ESTRATÉGICOS
Gestión de Cartera de Productos y Servicios: 83.33%
Gestión Comercial: 100.00%
Gestión de Proyectos: 100.00%
Gestión de Recursos Humanos: 83.33%
PROCESOS TÁCTICOS
Gestión de Infraestructura e Información: 50.00%
Gestión de Compras: 33.33%
Gestión Administrativa: 33.33%
PROCESOS OPERATIVOS
Gestión de Facturación: 16.67%
Gestión de Asesoría Legal: 16.67%
El porcentaje indicado previamente expresa la participación de cada uno de los procesos de
negocio en los objetivos estratégicos de la organización.
A continuación, se muestra el mapa de procesos de la organización que consiste en la
representación gráfica de todos los procesos que constituyen la actividad de la empresa.
Figura 4 – Mapa de Procesos de la Organización
Fuente: Elaboración Propia
141
ID Proceso Función Descripción de la función Tipo de Proceso
P001 Gestión de Cartera de
Productos y Servicios
Gestionar el portafolio de
productos y servicios, y
la cartera de clientes.
Determinación de los productos y servicios que generen valor a la
organización, así como la identificación de los clientes potenciales
para la organización a partir de la evaluación de las principales
necesidades del mercado en materia de tecnología de la
información.
Estratégico
P002 Gestión Comercial Gestionar las ventas de
los productos y servicios.
Elaboración y presentación al cliente de propuestas de servicios,
generación de hoja de alta de los mismos, y elaboración de los
contratos de aceptación de los proyectos en base a los
requerimientos expuestos por los clientes.
Estratégico
P003 Gestión de Proyectos Gestionar los proyectos
de la organización.
Registro y actualización de los datos requeridos para la
identificación y seguimiento de un proyecto, tales como: Fecha de
inicio y fin, recursos a emplear, tiempos, gastos, presupuesto, etc.
Estratégico
P004 Gestión de Recursos
Humanos
Gestionar a la fuerza de
trabajo de la
organización (personal).
Reclutamiento y selección del personal a través de la debida
evaluación de habilidades duras y blandas para cada rol requerido
en la organización. Además, evaluación física y psicológica del
personal (Salud Ocupacional) para garantizar su óptimo desempeño.
Estratégico
P005 Gestión de Infraestructura e
Información
Gestionar la
infraestructura,
Mantenimiento de servidores (correo, aplicaciones, base de datos),
administración de recursos para el personal: Tecnológicos
Táctico /
Operativo
ID Proceso Función Descripción de la función Tipo de Proceso
comunicación, e
información.
(computadoras, laptops, impresoras, proyectores), de comunicación
(anexos, teléfonos con línea corporativa), usuarios (cuentas de
correo, cuentas de red), y ambientes de trabajo (oficinas, escritorios,
salas de reuniones, salas de capacitación).
P006 Gestión de Compras
Gestionar la logística de
los materiales de la
organización.
Adquisición y distribución de insumos como útiles de escritorio,
libros de gestión y tecnología, merchandising para los clientes,
equipos, servidores, etc., que permitan un buen desempeño y
desarrollo del personal.
Táctico /
Operativo
P007 Gestión Administrativa Gestionar temas
administrativos.
Administración de clientes y proveedores, determinación del
presupuesto, evaluación del Estado de Ganancias y Pérdidas de la
organización.
Táctico /
Operativo
P008 Gestión de Facturación Realizar la facturación a
los clientes.
Emisión de facturas por pagar y por cobrar, registro de anticipos,
reembolso de gastos, reposición de caja chica, conciliación
bancaria, control de flujo de caja.
Soporte /
Apoyo
P009 Gestión de Asesoría Legal Gestionar temas legales
de la organización.
Definición de cláusulas específicas en los contratos con los clientes,
proveedores y personal.
Soporte /
Apoyo
Tabla 52 – Descripción Detallada de Procesos de Negocio
Fuente: Elaboración Propia
Para un mejor entendimiento de la responsabilidad que asume cada área de la organización con relación a los procesos de negocio, se desarrolla
una matriz RAM31
, utilizada generalmente en la gestión de proyectos para relacionar actividades con recursos de manera que se garantice que
cada uno de los componentes del alcance esté asignado a un individuo, equipo o área.
Procesos / Áreas
Ger
enci
a G
ener
al
Ger
enci
a de
Adm
inis
trac
ión y
Fin
anza
s
Rec
urs
os
Hum
anos
Ase
sorí
a L
egal
Conta
bil
idad
Ger
enci
a de
Oper
acio
nes
TI
PM
O
Ger
enci
a de
Pro
yec
tos
SA
P
Ger
enci
a de
Pro
yec
tos
Ora
cle
Ger
enci
a
Com
erci
al
Gestión de Cartera de Productos y Servicios I
C
R R A
Gestión Comercial I
R R A
Gestión de Proyectos I C
C I
R I I I
Gestión de Recursos Humanos I A R C I
I
A A
Gestión de Infraestructura e Información I A
I C R
Gestión de Compras I R
I
C
Gestión Administrativa I R
C
31 Matriz de Asignación de Responsabilidades, llamada también RACI por sus siglas en inglés (Responsible, Accountable, Consulted, Informed).
Procesos / Áreas
Ger
enci
a G
ener
al
Ger
enci
a de
Adm
inis
trac
ión y
Fin
anza
s
Rec
urs
os
Hum
anos
Ase
sorí
a L
egal
Conta
bil
idad
Ger
enci
a de
Oper
acio
nes
TI
PM
O
Ger
enci
a de
Pro
yec
tos
SA
P
Ger
enci
a de
Pro
yec
tos
Ora
cle
Ger
enci
a
Com
erci
al
Gestión de Facturación I I
R
C C
Gestión Legal I I I R
(Leyenda: R = Responsible, A = Accountable, C = Consulted, I = Informed)
Tabla 53 – Matriz RACI
Fuente: Elaboración Propia
Los procesos “Gestión de Cartera de Productos y Servicios” y “Gestión Comercial” presentan doble asignación de responsable debido a que
corresponden a dos Áreas de Negocio diferentes: SAP y Oracle.
145
Procesos seleccionados:
A continuación se describirán cada uno de los procesos que cubre el alcance del presente
capítulo:
Proceso de Gestión Comercial:
El proceso de Gestión Comercial tiene como objetivo el registro y seguimiento de las
actividades que realiza el equipo de ventas; esto, con la finalidad de poder establecer tareas
de análisis que permitan identificar oportunidades de venta y captación de potenciales
clientes.
El proceso, actualmente, es soportado por la herramienta Microsoft Dynamics CRM y los
responsables de la información que se maneja en el software son el Director Comercial y los
Gerentes de Línea de Negocio, quienes constituyen el equipo de ventas de la organización.
Gestión de Ventas:
El proceso da inicio con la creación de Oportunidades de Venta para los clientes registrados
en el sistema; si estos aun no lo estuvieran, será necesaria su creación para la asignación
correspondiente de las mismas. A cada oportunidad de venta registrada en el sistema se le
deberá asignar un importe estimado como valor de oportunidad; ello permitirá realizar
análisis de ingresos perdidos por oportunidad rechazada y hacer proyecciones de ventas de
futuros compromisos.
Una vez que se han identificado y asignado las oportunidades de venta, se procede a elaborar
un plan de acercamiento a los clientes. Normalmente, este acercamiento se realiza a través de
reuniones directas con el cliente; y salvo casos excepcionales, se planifican eventos para
captación masiva. El plan deberá presentar la agenda de visitas, los clientes involucrados y el
equipo encargado de realizar la presentación de los productos y servicios de la compañía.
Esta actividad hasta el momento se viene realizando de manera informal, es decir, no existe
procedimiento definido para ello, por lo que queda a criterio del Gerente de Línea de Negocio
la forma en como la lleva a cabo, por ejemplo: Algunos controlan la agenda de visitas en
Gmail, otros en Outlook y otros dentro de la misma herramienta, pero incluso estos últimos
colocan información breve y/o incompleta para tareas de seguimiento posteriores.
Cuando un cliente solicita la cotización de algún servicio, los Gerentes de Línea de Negocio
elaboran la Hoja de Alta correspondiente. Ésta, es una plantilla en formato Excel para la
proyección de los Ingresos y Gastos que se incurrirán en la prestación del servicio
demandado por el cliente. Así mismo, permite conocer cuál será la rentabilidad final del
servicio, teniendo en consideración de que aquellos con un valor por debajo del 40% (valor
de rentabilidad esperado por la empresa), necesitarán de la aprobación del Director Comercial
para la emisión de la propuesta al cliente.
El cliente evaluará la propuesta de servicios alcanzada e indicará su decisión al Gerente de
Línea de Negocio. Si esta fuera positiva, deberá emitir la orden de compra correspondiente a
fin de proceder con la creación del contrato que enmarque los lineamientos y alcances del
servicio. Si la respuesta fuese negativa, se le solicitará feedback acerca del motivo de su
decisión a fin de que esta sea registrada en el CRM y colabore con la mejora de propuestas
futuras.
Para toda propuesta aprobada, se deberá actualizar el estado de la oportunidad ganada en
CRM y posteriormente, solicitar a la PMO la creación de un proyecto dentro de EBS Project
para asegurar el cumplimiento de las proyecciones estimadas en la Hoja de Alta
correspondiente.
Seguimiento de ventas:
Para el seguimiento de las ventas dentro de la organización, la Gerencia de Operaciones y los
Gerentes de las Unidades de Negocio SAP y Oracle, cuentan con un Dashboard alimentado
directamente con los datos de CRM. Esta es su principal fuente de información para la toma
de decisiones y/o determinación de estrategias que apoyen en el cumplimiento de las metas
trazadas. La información presentada en el Dashboard comprende:
Cuadro comparativo de facturación comprometida vs real, por mes.
Facturas pendientes de cobro por mes y a cuánto ascienden.
Porcentaje de facturación en soles y dólares.
Ingresos y pérdidas por oportunidad definida, ganada o perdida.
148
Figura 22 – Diagrama del Proceso de Gestión Comercial - AS IS
Fuente: Elaboración Propia
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT.
DURACIÓN
(horas)
1 Datos del cliente Validar existencia de
cliente
Existencia de
cliente validada
Se verifica si el cliente ya
ha sido registrado
previamente en el sistema.
Gerente de
Línea de
Negocio
Automatizada 0.50
2 Datos del cliente Registrar cliente Registro de
cliente
Creación del cliente en el
sistema.
Gerente de
Línea de
Negocio
Manual 2.00
3 Datos del Cliente Registrar
oportunidad de venta
Registro de
Oportunidad de
Venta
Esta actividad se centra en
el registro de la
oportunidad de venta
asociada al cliente.
Gerente de
Línea de
Negocio
Manual 1.00
4
Datos del cliente
Oportunidad de venta
Definir plan de
visitas a clientes Plan de visitas
Se define la programación
de visitas y actividades a
realizar para establecer
contacto con el cliente y
presentar los productos y
Gerente de
Línea de
Negocio
Manual 3.00
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT.
DURACIÓN
(horas)
servicios manejados por la
empresa.
5
Datos de clientes
Datos de proyecto
Datos de consultores
propios y terceros
Costos de hora por
consultor
Período de participación
de consultores
Gastos directos e
indirectos del proyecto
Elaborar Hoja de
Alta en Excel
Hoja de Alta
con detalle de
ingresos, costos
y gastos
asociados al
servicio
solicitado por el
cliente
Esta actividad es realizada
para conocer los ingresos y
gastos que generará la
prestación del servicio,
permitiendo medir el grado
de rentabilidad del
proyecto.
Gerente de
Línea de
Negocio
Manual 6.00
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT.
DURACIÓN
(horas)
Información de
vacaciones
6 Hoja de Alta Solicitar aprobación
de Hoja de Alta
Solicitud para
evaluación y
aprobación de
Hoja de Alta
Petición que se realiza al
Director Comercial para la
revisión y aprobación de
Hojas de Alta que no
alcanzan el porcentaje de
rentabilidad esperado
(40%).
Gerente de
Línea de
Negocio
Manual 0.50
7 Hoja de Alta Evaluar Hoja de Alta Hoja de Alta
validada
Revisión del contenido de
la Hoja de Alta llevado a
cabo por el Director
Comercial.
Director
Comercial Manual 1.00
8 Hoja de Alta Aprobar Hoja de Hoja de Alta
Aprobación de la Hoja de
Alta por parte del Director Director
Manual 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT.
DURACIÓN
(horas)
Alta aprobada Comercial. Comercial
9 Hoja de Alta Solicitar ajuste de
Hoja de Alta
Notificación
para corrección
de Hoja de Alta
con detalle de
observaciones a
atender
Petición de corrección de
la Hoja de Alta según las
observaciones realizadas
por el Director Comercial.
Director
Comercial Manual 0.50
10 Hoja de Alta Corregir Hoja de
Alta en Excel
Hoja de Alta
corregida
Corrección de la Hoja de
Alta en función de las
observaciones alcanzadas
por el Director Comercial.
Gerente de
Línea de
Negocio
Manual 2.00
11 Hoja de Alta Elaborar y enviar
propuesta a cliente
Propuesta para
atención de
servicios
Creación y envío de
propuesta de servicios al
cliente en función de sus
Gerente de
Línea de
Negocio
Manual 4.00
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT.
DURACIÓN
(horas)
requerimientos.
12 Orden de Compra del
Cliente.
Recepcionar Orden
de Compra
Orden de
Compra
validada y
aceptada
Recepción de la Orden de
Compra enviada por el
cliente como conformidad
a la propuesta de servicios
presentada.
Gerente de
Línea de
Negocio
Manual 0.50
13
Propuesta de Servicios
Hoja de Alta
Elaborar Contrato Contrato de
Servicios
Generación del contrato de
servicios que sella el
vínculo de trabajo entre la
empresa y el cliente.
Gerente de
Línea de
Negocio
Manual 3.00
14
Datos del Cliente
Oportunidad
Actualizar estado de
oportunidad.
Oportunidad
ganada
Actualización del estado
de la oportunidad dentro
del sistema. El nuevo
estado será “Ganada”.
Gerente de
Línea de
Negocio
Manual 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT.
DURACIÓN
(horas)
15 Hoja de Alta Solicitar creación de
proyecto
Solicitud de
creación de
proyecto en
EBS
Petición de creación de
proyecto en EBS. Esta
petición se realiza vía
correo electrónico y
teniendo como fuente de
datos a la Hoja de Alta.
Gerente de
Línea de
Negocio
Manual 0.50
Tabla 54 – Cuadro de Entradas y Salidas del Proceso de Gestión Comercial – AS IS
Fuente: Elaboración Propia
Figura 23 – Modelo de Dominio Empresarial del Proceso Gestión Comercial
Fuente: Elaboración Propia
156
Proceso de Gestión de Proyectos:
El proceso de Gestión de Proyectos tiene como objetivo principal el hacer seguimiento de los
proyectos contratados como servicios por parte del cliente y asegurar que la rentabilidad
estimada de éstos se cumpla.
El proceso, actualmente, es soportado por EBS Project y la persona responsable del control
del software es la PMO quien finalmente reporta la situación de los proyectos a la Gerencia
de Operaciones y a los Gerentes de Proyectos.
Para un mejor entendimiento del proceso, se presentan las principales actividades en este:
Creación de Proyectos:
El proceso de Gestión de Proyectos inicia con la creación de éstos. Para ello, es necesaria la
entrega de la Hoja de Alta por parte del Gerente de Línea de Negocio. Una vez entregada, se
verificará la rentabilidad de ésta, validando que cuente con la aprobación del Director
Comercial cuando sea menor a 40%. Parte del proceso de validación es verificar que el
cliente asociado al proyecto a crear, se encuentre registrado en EBS; de no ser así, se dará de
alta en el sistema y se procederá con la creación del proyecto.
Para cada nuevo proyecto que se registre en EBS se deberá completar, con los datos
contenidos en la Hoja de Alta, la siguiente estructura de información:
Recursos: En este grupo se realizará la asignación de las personas que participaran en el
proyecto y el período de tiempo que estarán en él.
WorkPlan: En este grupo se registra la información de Tiempos y Gastos del proyecto.
En la información correspondiente a Tiempos, se especificará la cantidad de horas de
participación de los recursos asignados; mientras que en Gastos, la información de
gastos por conceptos de viáticos, transportes, contrato a personal de terceros, entre otros.
Se deberá validar que los costos finales de los recursos asignados (cantidad de horas de
participación por el costo por hora del recurso) se correspondan con los calculados en la
Hoja de Alta. Debido a que en algunos casos, los clientes solicitan renegociar la tarifa de
los recursos que brindaran el servicio, es que los ingresos indicados en la Hoja de Alta no
coinciden con los que se calculan de manera automática en EBS; ante ello, se realiza un
ajuste de costos en éste último para estar alineados con los importes que se indican en la
Hoja de Alta. Asimismo, se debe tener en consideración de que los importes deberán ser
convertidos a soles dentro de EBS, ya que el sistema se encuentra configurado de dicha
manera y dado que las Hojas de Alta se elaboran en dólares.
Así mismo, se valida que el importe total de Gastos ingresado en EBS sea el correcto en
concordancia con lo especificado en la Hoja de Alta.
La finalización de la creación del proyecto se realiza con el registro de su presupuesto dentro
de EBS y la publicación del proyecto. Una vez que el proyecto ha sido publicado, los
recursos asignados a éste podrán cargar sus horas de trabajo a él; esto, dentro del período de
participación que se indicó en el momento de la asignación de recursos. El registro de horas
se realiza a través del TimeSheet de EBS, y aunque el registro diario no es de carácter
obligatorio, si lo es de manera semanal.
Seguimiento de Proyectos:
El seguimiento de la situación de los proyectos se realiza cada 2 semanas validando el tiempo
planificado de trabajo vs el tiempo real (obtenido del EBS TimeSheet). Cualquier desviación
en cuanto a lo planificado y que impacte en los costos del proyecto, es notificado al Gerente
de Proyectos y al Directorio para tomar las decisiones correspondientes que impidan que la
rentabilidad del proyecto se vea afectada.
Así mismo, con carácter mensual se presenta al Directorio un reporte por cada línea de
negocio para conocer el detalle de los costos en función de las horas reales de trabajo, los
gastos incurridos y los ingresos generados a partir de la cobranza de las facturas asociadas a
cada proyecto. Este reporte es generado de manera manual en MS Excel con información
descargada en formato “.txt” del propio sistema.
159
Figura 24 – Diagrama del Proceso de Gestión de Proyectos – AS IS
Fuente: Elaboración Propia
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
1 Hoja de Alta Validar datos de
Hoja de Alta
Hoja de Alta
validada
Verificación manual
realizada para asegurar de
que la información
necesaria para la creación
del proyecto se encuentre
en la Hoja de Alta y de que
ésta cuente con la
aprobación del Director
Comercial.
PMO Manual 2.00
2 Hoja de Alta
Datos del Cliente Registrar cliente
Registro de
cliente
Creación del cliente dentro
del sistema. PMO Manual 2.00
3 Hoja de Alta Crear proyecto Registro de
proyecto
Creación del proyecto
dentro del sistema. PMO Manual 1.00
4 Hoja de Alta Validar consultores Consultores
validados
Validación de existencia
de los consultores
indicados en la Hoja de
Alta dentro del sistema.
PMO Automatizada 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
5
Consultores no
registrados en el
sistema
Solicitar creación
del consultor
Solicitud para
registro del
consultor en el
sistema
Solicitud vía correo
electrónico al área de
Recursos Humanos para
que se realice el registro de
los consultores que aún no
están en el sistema.
PMO Manual 0.50
6
Datos de consultores
no registrados en el
sistema
Registrar consultor
en el sistema
Registro de
consultores
Creación de consultores en
el módulo de Recursos
Humanos de EBS.
Asistente de
Recursos
Humanos
Manual 0.75
7
Consultores
registrados en el
sistema
Notificar registro
de consultor
Notificación
de registro del
consultor en el
sistema
Notificación que se hace a
la PMO por el registro de
los consultores en el
sistema. Esta notificación
es enviada vía correo
electrónico.
Asistente de
Recursos
Humanos
Manual 0.50
8 Hoja de Alta Asignar
consultores a
Consultores
asignados a
Asignación de los
consultores al proyecto en PMO Manual 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
proyecto proyecto creación.
9 Hoja de Alta Crear Workplan Workplan
elaborado
Registro de los tiempos y
períodos de participación
de los consultores en el
proyecto, y de los gastos
directos e indirectos de
este.
PMO Manual 2.00
10 Datos de Workplan
Hoja de Alta
Verificar costos del
proyecto
Costos en el
sistema
homologados
con los de
Hoja de Alta
Validación que se realiza
sobre los costos del
proyecto y los ajustes que
se requieren realizar para
que los importes en el
sistema sean iguales a los
especificados en la Hoja de
Alta. Se debe tener en
consideración, además, los
ajustes requeridos que se
PMO Manual 3.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
deben realizar debido a
que EBS maneja los costos
de proyectos en soles;
mientras que la Hoja de
Alta en dólares.
11 Hoja de Alta Ingresar
presupuesto
Presupuesto
registrado
Registro del presupuesto
del proyecto en el sistema. PMO Manual 0.50
12 Código de Proyecto Publicar proyecto Proyecto
publicado
Habilitación del proyecto
en el sistema. Una vez que
el proyecto haya sido
publicado, los consultores
asignados a él podrán
cargar las horas de trabajo
a éste y en función de ello
se irá midiendo el avance
de costos y el
cumplimiento de la
PMO Automatizada 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
rentabilidad estimada.
13 Código de Proyecto Notificar creación
de proyecto
Notificación
de creación de
proyecto
Notificación que se envía
vía correo electrónico al
Gerente de Línea para
informar que el proyecto
ya ha sido habilitado en el
sistema.
PMO Manual 0.50
Tabla 55 – Cuadro de Entradas y Salidas del Proceso de Gestión de Proyectos – AS IS
Fuente: Elaboración Propia
165
Figura 25 – Modelo de Dominio Empresarial del Proceso Gestión de Proyectos
Fuente: Elaboración Propia
Proceso de Gestión de Facturación:
El proceso de Gestión de Facturación tiene como objetivo principal el registro, emisión y la
coordinación de la entrega de facturas a los clientes.
El proceso, actualmente, es realizado en XRAY, que es un software propio de la organización
para la gestión logística y financiera de la empresa.
Para un mejor entendimiento del proceso, se presentan las principales actividades en este:
Registro de Factura:
Los Gerentes de Línea de Negocio son los encargados de dar inicio al proceso con el registro
de la facturación para cada servicio dentro de Microsoft Dynamics CRM. Este registro genera
un enlace con los datos que deberán ser consignados en la factura, el cual es alcanzado al
Asistente Contable para que se encargue de elaborar la impresión de la factura.
El Asistente Contable validará que el proyecto y cliente a facturar se encuentren registrados
en XRAY; de no ser así, se les dará de alta en el sistema. Una vez que los datos han sido
validados, se procede a realizar lo siguiente:
Se actualiza el estado de la factura en Microsoft Dynamics CRM a “Facturado” y se
asigna el número de documento físico correspondiente.
Se crea el registro de facturación dentro de EBS.
Se crea e imprime la factura correspondiente en XRAY.
Se realiza la coordinación para la entrega de las facturas a los clientes.
Es necesario precisar que en muchas ocasiones por el gran volumen de facturas a emitir, se
omite accidentalmente la actualización de datos de facturación en Microsoft Dynamics CRM
o EBS, generando distorsiones entre estos aplicativos y XRAY; por ello, existe un gran nivel
de desconfianza en analizar datos en tiempo real de dichos aplicativos.
Reportes de Facturación:
Para la generación de los reportes de facturación mensual, se debe realizar un comparativo
entre la información manejada en las aplicaciones Microsoft Dynamics CRM, EBS Project y
XRAY a fin de garantizar que los tres manejan la misma información. Para ello, se descarga
la información de los tres aplicativos, se consolida en MS Excel y se analiza de manera
manual por cada proyecto y/o servicio prestado.
167
Figura 26 – Diagrama del Proceso de Gestión de Facturación – AS IS
Fuente: Elaboración Propia
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
1 Hoja de Alta
Registrar detalle de
facturación en
CRM
Registro de
factura en el
sistema.
Registro de la facturación
del servicio en el sistema.
Gerente de
Línea de
Negocio
Manual 0.50
2 Datos de facturación Solicitar emisión
de factura
Solicitud para
emisión de
factura física
Esta actividad hace
referencia al envío de un
correo electrónico al
Asistente Contable para que
realice la impresión y envío
de la factura al cliente. Los
datos de facturación son
anexados al correo
electrónico en un
hipervínculo que lleva
directamente hacia CRM, el
cual ha de presentar la
información necesaria para
la elaboración de la factura.
Gerente de
Línea de
Negocio
Manual 0.25
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
3 Datos de facturación
Verificar existencia
de cliente en
XRAY
Cliente
validado
Esta actividad hace
referencia a la verificación
de que el cliente para el cual
se solicita la emisión de
factura se encuentre
registrado en XRAY.
Asistente
Contable Automatizada 0.50
4 Datos del Cliente Registrar cliente en
XRAY
Registro de
Cliente
Creación del cliente dentro
de XRAY.
Asistente
Contable Manual 0.75
5 Datos de facturación
Verificar existencia
de proyecto en
XRAY
Proyecto
validado
Esta actividad hace
referencia a la verificación
de que el proyecto para el
cual se solicita la emisión de
factura se encuentre
registrado en XRAY.
Asistente
Contable Automatizada 0.25
6 Datos de Proyecto Registrar proyecto
en XRAY
Registro de
proyecto
Creación del proyecto
dentro de XRAY.
Asistente
Contable Manual 0.50
7 Datos de facturación Validar datos para Datos Se valida que la información Asistente Manual 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
emisión de factura validados para facturación (fecha de
documento, glosa, subtotal,
IGV e importe total) se
encuentren correctos.
Contable
8 Datos de facturación Solicitar corrección
de datos
Solicitud para
corrección de
datos de
facturación
Envío de correo electrónico
solicitando la revisión y
corrección de datos de
facturación al Gerente de
Línea de Negocio.
Asistente
Contable Manual 0.50
9 Datos de facturación Corregir datos de
facturación
Datos de
facturación
corregidos
Corrección de datos de
facturación en CRM.
Gerente de
Línea de
Negocio
Manual 0.50
10 Datos de facturación Actualizar estado
de factura en CRM
Facturación en
CRM
actualizada
Se actualiza el estado de
facturación a “Facturado” y
se asigna el número de
documento físico
correspondiente.
Asistente
Contable Manual 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE ACT. DURACIÓN
(horas)
11 Datos de facturación Crear registro de
factura en EBS
Registro de
facturación
Se crea el registro de
facturación asociado al
proyecto correspondiente,
en el sistema.
Asistente
Contable Manual 0.50
12 Datos de facturación Crear registro de
factura en XRAY
Registro de
facturación
Se crea el registro de
facturación en el sistema.
Asistente
Contable Manual 0.50
13 Registro de
facturación
Realizar emisión de
factura
Factura
impresa
Se realiza la impresión de la
factura en formato pre-
impreso de acuerdo a los
datos que se ingresaron en
XRAY.
Asistente
Contable Manual 0.25
14 Factura Impresa Coordinar entrega
de factura
Plan de entrega
de factura
Coordinación realizada con
el conserje para la entrega
de facturas en el cliente.
Asistente
Contable Manual 3.00
Tabla 56 – Cuadro de Entradas y Salidas del Proceso de Gestión de Proyectos – AS IS
Fuente: Elaboración Propia
172
Figura 27 – Modelo de Dominio Empresarial del Proceso Gestión de Facturación
Fuente: Elaboración Propia
N°
PROCESO
ENTIDAD
Ges
tió
n d
e C
art
era d
e
Pro
du
ctos
y S
ervic
ios
Ges
tión
Com
erci
al
Ges
tión
de
Pro
yec
tos
Ges
tión
de
Fact
ura
ción
Ges
tión
de
Rec
urs
os
Hu
man
os
Ges
tión
de
Infr
aes
tru
ctu
ra
e In
form
aci
ón
Ges
tión
de
Com
pra
s
Ges
tión
Ad
min
istr
ati
va
Ges
tión
de
Ase
sorí
a L
egal
1 Cliente X X X X X
2 Propuesta
3 Proyecto X X X X X
4 Personal X X
5 Workplan X
6 Factura X X X X
N°
PROCESO
ENTIDAD
Ges
tión
de
Cart
era d
e
Pro
du
ctos
y S
ervic
ios
Ges
tión
Com
erci
al
Ges
tión
de
Pro
yec
tos
Ges
tión
de
Fact
ura
ción
Ges
tión
de
Rec
urs
os
Hu
man
os
Ges
tión
de
Infr
aes
tru
ctu
ra
e In
form
aci
ón
Ges
tión
de
Com
pra
s
Ges
tión
Ad
min
istr
ati
va
Ges
tión
de
Ase
sorí
a L
egal
7 Condición Pago X X X
8 Moneda X X X X X X
9 Línea Negocio X X X X X X
10 Ciudad X X X X
11 Región X X X X
12 País X X X X
13 Oportunidad X X
14 Estado X X X X X X
15 Prioridad X X
16 Responsable X X X
17 Centro Costo X X
18 Proveedor X
19 Orden Compra X
Tabla 57 – Matriz Entidad vs. Procesos de Negocio – AS IS
Fuente: Elaboración Propia
Los principales stakeholders que participan de los procesos de negocio son:
N°
PROCESO
STAKEHOLDER
Ges
tión
Co
mer
cial
Ges
tión
de
Pro
yec
tos
Ges
tión
de
Fa
ctu
raci
ón
Ges
tión
de
Ca
rter
a d
e
Pro
du
ctos
y S
erv
icio
s
Ges
tión
de
Rec
urs
os
Hu
ma
no
s
Ges
tión
de
Infr
aes
tru
ctu
ra e
Info
rma
ció
n
Ges
tión
de
Co
mp
ras
Ges
tión
Ad
min
istr
ati
va
Ges
tión
de
Ase
sorí
a L
egal
1 Gerente de Línea
de Negocio X X X X
2 Director Comercial X X
3 PMO X
4 Asistente de
Recursos Humanos X X X
5 Asistente Contable X X X X
6 Gerente de
Operaciones X
Tabla 58 – Matriz Stakeholders vs. Procesos de Negocio – AS IS
Fuente: Elaboración Propia
ARQUITECTURA DE DATOS (AS IS)
En esta arquitectura se define la estructura de datos lógicos y físicos que posee la
organización, así como sus recursos de gestión de datos.
En base a la arquitectura de datos actual de la organización, se presenta el diagrama del
modelo conceptual para cada una de las aplicaciones empleadas en los procesos de negocio:
Gestión Comercial, Gestión de Proyectos, y Gestión de Facturación.
Microsoft Dynamics CRM – Proceso de Gestión Comercial
Figura 28 – Modelo Conceptual del Proceso Gestión Comercial – AS IS
Fuente: Elaboración Propia
ID Objeto de Negocio Descripción
E001 Oportunidad Posible proyecto para un cliente.
E002 Tipo Tipo de oportunidad: Outsourcing, mantenimiento, licencias, etc.
E003 Proyecto Servicio que se lleva a cabo para un cliente.
E004 Cliente Empresa que tiene una necesidad y a quien se le ofrece y/o vende
un proyecto.
E005 Factura Contiene los datos de cabecera de la factura.
E006 Detalle_Factura Contiene las posiciones o detalle de la factura.
E007 Prioridad Nivel de importancia de un proyecto, categorizado en: Alta,
media y baja.
E008 Estado Indica el estado de la oportunidad, proyecto o factura.
E009 Moneda Indica la moneda en que se estima la oportunidad, así como la
moneda en que se emite la factura.
ID Objeto de Negocio Descripción
E010 Línea_Negocio
Línea de negocio que desarrolla una oportunidad con el cliente.
Actualmente existen 3 líneas de negocio para la Gerencia de
Proyectos SAP y 4 para la Gerencia de Proyectos Oracle.
E011 Responsable Persona encargada de la gestión de la oportunidad y del proyecto.
E012 Condición_Pago Condición de pago de la factura. Puede ser a 30, 60, 90, 120 días,
dependiendo de la negociación con el cliente.
E013 Unidad_Medida Unidad de medida del bien o servicio indicado a nivel de
posición de la factura.
E014 Ciudad Ciudad de origen del cliente y donde se desarrolla el proyecto.
E015 Región Región o estado de origen del cliente y donde se desarrolla el
proyecto.
E016 País País de origen del cliente y donde se desarrolla el proyecto.
Tabla 59 – Entidades del Modelo Conceptual del Proceso Gestión Comercial – AS IS
Fuente: Elaboración Propia
177
Oracle E-Business Suite – Proceso de Gestión de Proyectos
Figura 29 – Modelo Conceptual del Proceso Gestión de Proyectos – AS IS
Fuente: Elaboración Propia
ID Objeto de Negocio Descripción
E001 Proyecto Servicio que se lleva a cabo para un cliente.
E002 Cliente Empresa que tiene una necesidad y a quien se le ofrece y/o
vende un proyecto.
E003 Industria Indica la industria a la que pertenece el cliente: Minería,
Salud, Finanzas, Construcción, Entretenimiento, etc.
ID Objeto de Negocio Descripción
E004 Mercado Indica si el cliente representa una pequeña, mediana o gran
empresa.
E005 Gestor Responsable de gestionar el proyecto y elaborar la hoja de
alta.
E006 Estado Indica el estado de la hoja de alta, proyecto, workplan, o
recurso en un proyecto.
E007 Prioridad Nivel de importancia de un proyecto y recurso en un proyecto,
categorizado en: Alta, media y baja.
E008 Ciudad Ciudad de origen del cliente, donde se desarrolla el proyecto,
y donde se asigna a un recurso.
E009 Región Región o estado de origen del cliente, donde se desarrolla el
proyecto, y donde se asigna a un recurso.
E010 País País de origen del cliente, donde se desarrolla el proyecto, y
donde se asigna a un recurso.
E011 Unidad_Negocio Unidad de negocio de la organización a la que pertenece el
recurso.
E012 Línea_Negocio
Línea de negocio a la que pertenece un proyecto. Actualmente
existen 3 líneas de negocio para la Gerencia de Proyectos SAP
y 4 para la Gerencia de Proyectos Oracle.
E013 Moneda
Indica la moneda en que se estima la hoja de alta, proyecto,
así como la moneda en que se consideran los costos de los
recursos asignados al proyecto.
E014 Rol Rol que tiene un recurso.
E015 Recurso Recurso humano de la organización.
E016 Recurso_Proyecto Asignación de un recurso a un determinado proyecto.
E017 Workplan Plan de trabajo que se define por cada proyecto.
E018 Tarea Actividades a registrar en el plan de trabajo.
E019 Factura Contiene los datos de cabecera de la factura.
E020 Detalle_Factura Contiene las posiciones o detalle de la factura.
E021 Condición_Pago Condición de pago de la factura. Puede ser a 30, 60, 90, 120
ID Objeto de Negocio Descripción
días, dependiendo de la negociación con el cliente.
E022 Unidad_Medida Unidad de medida del bien o servicio indicado a nivel de
posición de la factura.
E023 Centro_Costo Centro de costo donde se imputan los gastos de una factura.
Tabla 60 – Entidades del Modelo Conceptual del Proceso Gestión de Proyectos – AS IS
Fuente: Elaboración Propia
XRay – Proceso de Gestión de Facturación
Figura 30 – Modelo Conceptual del Proceso Gestión de Facturación – AS IS
Fuente: Elaboración Propia
ID Objeto de Negocio Descripción
E001 Cliente Empresa a quien se le brinda un servicio.
E002 Proyecto Servicio que se lleva a cabo para un cliente.
E003 Factura Contiene los datos de cabecera de la factura.
E004 Detalle_Factura Contiene las posiciones o detalle de la factura.
E005 Línea_Negocio
Línea de negocio a la que pertenece un proyecto. Actualmente
existen 3 líneas de negocio para la Gerencia de Proyectos SAP
y 4 para la Gerencia de Proyectos Oracle.
E006 Moneda Indica la moneda de la factura.
E007 Estado Indica el estado del proyecto y de la factura.
E008 Condición_Pago Condición de pago de la factura. Puede ser a 30, 60, 90, 120
días, dependiendo de la negociación con el cliente.
E009 Unidad_Medida Unidad de medida del bien o servicio indicado a nivel de
posición de la factura.
E010 Centro_Costo Centro de costo al que se imputa la factura.
E011 Ciudad Ciudad de origen del cliente y donde se desarrolla el proyecto.
E012 Región Región o estado de origen del cliente y donde se desarrolla el
proyecto.
E013 País País de origen del cliente y donde se desarrolla el proyecto.
E011 Responsable Persona encargada de la gestión de la oportunidad y del
proyecto.
Tabla 61 – Entidades del Modelo Conceptual del Proceso Gestión de Facturación – AS IS
Fuente: Elaboración Propia
ARQUITECTURA DE APLICACIONES (AS IS)
En esta arquitectura se definen las soluciones o aplicaciones tecnológicas y sus relaciones con
los procesos de negocio principales de la organización.
En base a la arquitectura de aplicaciones actual de la organización, se presentan las
aplicaciones empleadas en los procesos de negocio: Gestión Comercial, Gestión de
Proyectos, y Gestión de Facturación.
Figura 31 – Arquitectura de Aplicaciones – AS IS
Fuente: Elaboración Propia
ID Componente Descripción
A001
Microsoft
Dynamics
CRM
Herramienta empresarial para la gestión de relaciones con clientes que
busca mejorar el marketing, aumentar las ventas y enriquecer las
interacciones de servicio al cliente. En la organización, es utilizado
directamente por los gerentes de cada línea de negocios.
ID Componente Descripción
Además, en él se ingresan las oportunidades que luego de un
levantamiento de información con el cliente se traducen en propuestas.
Luego de ser aceptadas por el cliente se convierten en compromisos y,
finalmente, al establecer un contrato con el cliente pasa a ser un
proyecto.
A002 Microsoft
Excel
Herramienta empleada para el ingreso de hojas de alta de los proyectos.
Por otro lado, en Excel se integra y compara los datos del CRM y el
EBS para generar reportes gerenciales con la menor complejidad posible
y una visión real de la situación de los proyectos.
Cabe mencionar que la generación de este reporte en Excel toma de dos
a tres días, siendo un proceso 100% operativo.
A003 Oracle E-
Business Suite
Herramienta empleada para el registro de los proyectos así como de las
horas de trabajo del recurso humano asignado a cada proyecto.
A004 XRay Sistema de facturación desarrollado de manera interna por el personal de
la organización.
Tabla 62 – Descripción de Componentes de Aplicaciones – AS IS
Fuente: Elaboración Propia
Adicionalmente, se presenta una matriz que permite identificar de manera clara las
aplicaciones tecnológicas empleadas en cada proceso de negocio de la organización.
Aplicación / Proceso de
Negocio
Ges
tión
de
Cart
era d
e
Pro
du
ctos
y S
ervic
ios
Ges
tión
Com
erci
al
Ges
tión
de
Pro
yec
tos
Ges
tión
de
Rec
urs
os
Hu
man
os
Ges
tión
de
Infr
aes
tru
ctu
ra e
Info
rmaci
ón
Ges
tión
de
Com
pra
s
Ges
tión
Ad
min
istr
ati
va
Ges
tión
de
Fact
ura
ción
Ges
tión
de
Ase
sorí
a
Leg
al
Excel X
X
X X
X
Microsoft Dynamics CRM
X
X
Oracle E-Business Suite
X X
X
XRay
X
Tabla 63 – Matriz de Aplicaciones vs. Procesos de Negocio
Fuente: Elaboración Propia
ARQUITECTURA TECNOLÓGICA (AS IS)
En esta arquitectura se definen las capacidades de Software y Hardware con las que cuenta la
organización para apoyar la implementación de servicios de negocio, datos y aplicación. En
ella se incluyen redes, comunicaciones e infraestructura.
En base a la arquitectura tecnológica actual de la organización, se presentan los componentes
de infraestructura empleados en los procesos de negocio: Gestión Comercial, Gestión de
Proyectos, y Gestión de Facturación.
Figura 32 – Arquitectura Tecnológica del Proceso de Gestión Comercial – AS IS
Fuente: Elaboración Propia
Figura 33 – Arquitectura Tecnológica del Proceso de Gestión de Proyectos – AS IS
Fuente: Elaboración Propia
Figura 34 – Arquitectura Tecnológica del Proceso de Gestión de Facturación – AS IS
Fuente: Elaboración Propia
ID Componente Descripción
C001 Servidor IIS 7 Servidor de Internet que permite la publicación de aplicaciones
Web como Microsoft Dynamics CRM y Oracle E-Business Suite.
C002 Windows Server
2008 Standard
Sistema Operativo sobre el cual se soporta la aplicación Microsoft
Dynamics CRM para la gestión de clientes y oportunidades de
proyectos.
C003 SQL Server 2008
R2
Servidor de Base de Datos empleado por la aplicación Microsoft
Dynamics CRM.
C004 Red Hat Enterprise
5.3 x86_64
Sistema Operativo sobre el cual se soporta la aplicación Oracle E-
Business Suite para la gestión de proyectos.
C005 Oracle versión
10.2.0.4.0
Servidor de Base de Datos empleado por la aplicación Oracle E-
Business Suite.
C006 Linux Enterprise
Release 5.5
Sistema Operativo sobre el cual se soporta el ERP XRay para la
gestión de facturación.
C007 Oracle 10g Servidor de Base de Datos empleado por el ERP XRay.
Tabla 64 – Descripción de Componentes de la Arquitectura Tecnológica – AS IS
Fuente: Elaboración Propia
ARQUITECTURA DE SEGURIDAD (AS IS)
Adicionalmente a las arquitecturas ya mencionadas, se considera la arquitectura de seguridad
que permite marcar una trazabilidad desde la estrategia de negocio hasta la tecnología
empleada.
En base a la arquitectura de seguridad actual de la organización, se presenta el esquema para
garantizar la seguridad de las conexiones a internet y a diversas aplicaciones.
Figura 35 – Arquitectura de Seguridad de la Organización – AS IS
Fuente: Elaboración Propia
Como se observa en el diagrama, se cuenta con un router central para interconectar las
diversas redes dentro de la organización. Actualmente, se cuenta con tres redes de trabajo
para los consultores y una red de servidores. Por otro lado, se tiene un firewall para
monitorear y controlar el tráfico de red entrante y saliente basado en reglas de seguridad
predeterminadas.
Además, presenta un router balanceador que actualmente soporta dos puertos WAN (de una
capacidad de cuatro), ofrece capacidades máximas de ancho de banda, y una conectividad a
internet confiable.
El túnel de Americatel es una salida protegida a las VPNs de tres clientes específicos de la
organización, el resto sale directamente por internet. El túnel óptico es una conexión de
respaldo.
FUNDAMENTACIÓN Y JUSTIFICACION DE LA
ARQUITECTURA PROPUESTA
En base a la arquitectura empresarial AS IS y el proceso analizado, se definen los principales
problemas y/o requerimientos a resolver en la propuesta de arquitectura empresarial TO BE.
Problemática del proceso:
No existe una integración de las aplicaciones que soportan los procesos de Gestión
Comercial, Gestión de Proyectos y Gestión de Facturación, de manera que existen
diversos repositorios de información con datos redundantes.
No existe una segmentación de clientes que permita fortalecer relaciones a largo plazo
con clientes estratégicos.
El área de contabilidad no cuenta con una retroalimentación por parte del área comercial
respecto a la actualización de datos de clientes, lo que conlleva en ocasiones a la emisión
de facturas con datos erróneos.
Debido a que el proceso de facturación se realiza en XRay y se debe replicar
posteriormente en Microsoft Dynamics CRM y Oracle E-Business Suite, en algunas
oportunidades se ha obviado la actualización de la información en dichas aplicaciones lo
que origina que la información se distorsione e impida conocer la situación real de las
ventas y los proyectos.
La hoja de alta se maneja manualmente en formato Excel, luego se registran los mismos
datos en el Oracle E-Business Suite, lo que representa una duplicidad de actividades.
Alta dependencia en las hojas de alta por parte de los Gerentes de Línea de Negocio para
la generación de proyecciones y medición de la rentabilidad.
La hoja de alta se gestiona en dólares mientras que en el Oracle E-Business Suite la
moneda para la gestión de proyectos es soles. Ello origina descuadre de importes por
diferencia en cambio.
Al darse promociones al personal, los Gerentes de Línea de Negocio no actualizan los
nuevos costos de los recursos en la hoja de alta, lo que impide tener una visión real de la
rentabilidad del proyecto.
No existen indicadores de gestión de proyectos que permitan analizar en tiempo real la
situación de los mismos y tomar medidas preventivas o correctivas según sea el caso.
Los reportes de seguimiento de proyecto son elaborados en formato Excel con
información que se descarga en archivos de texto desde el Oracle EBS.
Cruce mensual de datos de facturación de las 3 aplicaciones para la detección de
inconsistencias.
No existen restricciones en Oracle EBS para evitar la modificación de las horas de trabajo
de periodos ya informados a la Alta Dirección de la organización
Principales requerimientos:
Contar con una solución integrada para la Gestión Comercial, Gestión de Proyectos y
Gestión de Facturación que disminuya y optimice la ejecución de actividades.
Contar con un indicador de gestión de proyectos que permita identificar posibles
sobrecostos.
Contar con un indicador de gestión de proyectos que permita conocer el avance del
mismo en relación a lo planificado.
Contar con un Dashboard que permita por línea de negocio:
- Conocer el avance de los ingresos reales en relación a lo comprometido
- Conocer el avance de la facturación real respecto a lo estimado a facturarse
mensualmente.
- Dar seguimiento a la evolución de las oportunidades.
Contar con niveles de seguridad en Oracle EBS para controlar el acceso a las
transacciones de acuerdo a los roles definidos.
Definir un esquema de segmentación de clientes por volumen de ingresos.
Automatizar la gestión de hojas de alta dentro de Oracle EBS.
Automatizar los canales de comunicación para agilizar el desarrollo de actividades.
ARQUITECTURA OBJETIVO (TO BE)
A continuación, se presenta la propuesta de solución ante los requerimientos y/o problemas
definidos en los procesos: Gestión Comercial, Gestión de Proyectos, y Gestión de
Facturación.
ARQUITECTURA DE NEGOCIO (TO BE)
En base a la arquitectura de negocios objetivo de la organización se presenta la propuesta de
negocio para los procesos mencionados previamente, y su representación gráfica en
diagramas de proceso con las mejoras respectivas para cada uno de ellos.
Procesos seleccionados:
A continuación se describirán cada uno de los procesos que cubre el alcance del presente
capítulo:
Proceso de Gestión Comercial:
La propuesta consiste en la integración de las aplicaciones Microsoft Dynamics CRM y
Oracle E-Business Suite para evitar la redundancia de información que, muchas veces, puede
llevar a un incorrecto análisis y toma de decisiones a partir de una fuente de información
desactualizada. Además, en el mercado existe una solución CRM integrada propia de Oracle,
lo que refuerza aún más la propuesta de integración.
Los principales cambios o mejoras que se proponen para el proceso de Gestión Comercial se
listan a continuación:
Registrar cliente: Actividad mejorada ya que se trabajará de manera centralizada en el
Oracle E-Business Suite, evitando tareas duplicadas.
Registrar hoja de alta en el sistema: Ya no manejará en formato Excel, se ingresará
directamente en el Oracle E-Business Suite.
Solicitar aprobación de hoja de alta: Actividad automatizada que se llevará a cabo
mediante un workflow32
de aprobaciones.
Solicitar ajuste de hoja de alta: Actividad automatizada que se llevará a cabo mediante un
workflow de aprobaciones.
Aprobar hoja de alta: Actividad automatizada que se llevará a cabo mediante un
workflow de aprobaciones.
Corregir datos de hoja de alta en el sistema: Las correcciones de datos en la hoja de alta
ya no se manejarán en formato Excel, se realizarán directamente en el Oracle E-Business
Suite.
Solicitar creación de proyecto: Actividad automatizada que se llevará a cabo mediante un
workflow de aprobaciones.
32 Flujo de trabajo a seguir para la realización de actividades de un proceso de negocio de
manera secuencial.
192
Figura 36 – Diagrama del Proceso de Gestión Comercial – TO BE
Fuente: Elaboración Propia
Las entradas y salidas por actividad de proceso de Gestión Comercial se mantienen tal cual se muestra en la figura 44 del AS IS.
193
Proceso de Gestión de Proyectos:
La propuesta consiste en el ingreso directo de la hoja de alta en el Oracle E-Business Suit de
manera que se prescinda del uso de un formato Excel, lo que actualmente representa una
duplicidad de actividades.
Los principales cambios o mejoras que se proponen para el proceso de Gestión de Proyectos
se listan a continuación:
Validar datos de hoja de alta: Validación interna de los consultores, en el Oracle E-
Business Suite. Por ejemplo, un recurso pudo haber sido considerado en una hoja de alta
y luego pudo haber sido dado de baja en el sistema. Al momento de seleccionar la hoja de
alta para la generación del proyecto, el sistema alertará que el recurso ya no puede ser
utilizado.
Actualizar hoja de alta: La actualización de la hoja de alta ya no manejará en formato
Excel, se actualizará directamente en el Oracle E-Business Suite.
Generar proyecto: Ya no existe la necesidad de crear un workplan (que contiene los
recursos a emplearse en un proyecto), verificar costos e ingresar presupuesto, ya que
forman parte de la hoja de alta. En esta actividad, la PMO solo busca en el sistema la hoja
de alta previamente registrada para generar el proyecto.
Notificar creación de proyecto: Actividad automatizada que se llevará a cabo mediante un
workflow de aprobaciones.
Figura 37 – Diagrama del Proceso de Gestión de Proyectos – TO BE
Fuente: Elaboración Propia
195
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE
ACT.
DURACIÓN
(horas)
1 Hoja de Alta Validar datos de Hoja
de Alta
Hoja de Alta
validada
Verificación interna de los
consultores en el sistema al
momento de seleccionar la
hoja de alta previamente
ingresada.
PMO Manual 3 segundos
2
Consultores no
registrados en el
sistema
Solicitar creación de
consultor
Solicitud para
registro del
consultor en el
sistema
Se refiere a la solicitud vía
correo electrónico al área
de Recursos Humanos,
para que se realice el
registro de los consultores
que aún no están en el
sistema.
PMO Manual 0.50
3
Datos de consultores
no registrados en el
sistema
Registrar consultor en
el sistema
Registro de
consultores
Creación de consultores en
el módulo de Recursos
Humanos del Oracle EBS.
Asistente de
Recursos
Humanos
Manual 0.75
4 Consultores
registrados en el
Notificar registro de
consultor
Notificación
de registro del
Se refiere a la notificación
que se hace a la PMO por
Asistente de
Recursos Manual 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE
ACT.
DURACIÓN
(horas)
sistema consultor en el
sistema
el registro de los
consultores en el sistema.
Esta notificación es
enviada vía correo
electrónico.
Humanos
5 Hoja de Alta Actualizar Hoja de Alta Hoja de Alta
actualizada
Actualización de los
consultores requeridos
para el proyecto.
PMO Manual 0.25
6 Hoja de Alta Generar proyecto Proyecto
creado
Se selecciona una Hoja de
Alta ingresada
previamente en el sistema
para proceder a crear el
proyecto.
PMO Manual 0.50
7 Código de Proyecto Publicar proyecto Proyecto
publicado
Se refiere a la habilitación
del proyecto en el sistema.
Una vez que el proyecto
haya sido publicado, los
PMO Manual 0.50
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE
ACT.
DURACIÓN
(horas)
consultores asignados a él
podrán cargar las horas de
trabajo a éste y en función
de ello se irá midiendo el
avance de costos y el
cumplimiento de la
rentabilidad estimada.
8 Código de Proyecto Notificar creación de
proyecto
Notificación
de creación de
proyecto
Se refiere a la notificación
que se envía vía correo
electrónico al Gerente de
Línea para informar que el
proyecto ya ha sido
habilitado en el sistema.
PMO Manual 0.50
Tabla 65 – Cuadro de Entradas y Salidas del Proceso de Gestión de Proyectos – TO BE
Fuente: Elaboración Propia
198
Proceso de Gestión de Facturación:
La propuesta consiste en dar de baja a la aplicación XRay desarrollada por la organización
para realizar la gestión de facturación directamente desde el Oracle E-Business Suite. De esta
manera, se evita la redundancia en el ingreso de datos.
Cabe mencionar que la aplicación XRay se encuentra obsoleta ya que en la actualidad no
cuenta con un mantenimiento por parte de la organización, y su funcionalidad de facturación
se ajusta con los beneficios brindados por la aplicación de Oracle.
Los principales cambios o mejoras que se proponen para el proceso de Gestión de
Facturación se listan a continuación:
Solicitar emisión de factura: Actividad automatizada que se llevará a cabo mediante una
notificación vía workflow para la emisión de la factura.
Generar factura: Actividad mejorada ya que se trabajará de manera centralizada en el
Oracle E-Business Suite, evitando tareas duplicadas.
Asignar numeración e imprimir factura: Actividad nueva a implementarse en el Oracle E-
Business Suite. De esta manera, las facturas tendrán una numeración correspondiente al
documento físico y se podrán imprimir. Esta numeración incluye el tipo, serie y número
de comprobante con relación al documento físico.
Figura 38 – Diagrama del Proceso de Gestión de Facturación – TO BE
Fuente: Elaboración Propia
200
N° ENTRADA ACTIVIDAD SALIDA DESCRIPCIÓN RESPONSABLE TIPO DE
ACT.
DURACIÓN
(horas)
1 Datos de facturación Solicitar emisión de
factura
Solicitud para
emisión de
factura física
Notificación vía workflow
hacia la Asistente Contable
para que genere la factura en
el sistema.
Gerente de
Línea de
Negocio
Manual 0.05
2 Solicitud para emisión
de factura física Generar factura
Creación de
factura
Creación de la factura en el
sistema.
Asistente
Contable Manual 0.25
3 Factura Asignar numeración e
imprimir factura
Factura
numerada
Numeración correspondiente
al documento físico de la
factura
Asistente
Contable Manual 0.25
4 Factura Impresa Coordinar entrega de
factura
Plan de entrega
de factura
Coordinación realizada con el
conserje para la entrega de
facturas al cliente.
Asistente
Contable Manual 3.00
Tabla 66 – Cuadro de Entradas y Salidas del Proceso de Gestión de Facturación – TO BE
Fuente: Elaboración Propia
201
N°
PROCESO
ENTIDAD
Ges
tión
de
Cart
era d
e
Pro
du
ctos
y S
ervic
ios
Ges
tión
Com
erci
al
Ges
tión
de
Pro
yec
tos
Ges
tión
de
Fact
ura
ción
Ges
tión
de
Rec
urs
os
Hu
man
os
Ges
tión
de
Infr
aes
tru
ctu
ra e
Info
rmaci
ón
Ges
tión
de
Com
pra
s
Ges
tión
Ad
min
istr
ati
va
Ges
tión
de
Ase
sorí
a L
egal
1 Cliente X X X X X
2 Propuesta
3 Proyecto X X X X X
4 Personal X X
5 Workplan X
6 Factura X X X X
7 Condición_Pago X X X
8 Moneda X X X X X X
9 Línea_Negocio X X X X X X
10 Ciudad X X X X
11 Región X X X X
12 País X X X X
13 Oportunidad X X
14 Estado X X X X X X
15 Prioridad X X
16 Responsable X X X
17 Centro_Costo X X
18 Proveedor X
19 Orden_Compra X
20 Hoja_Alta X
Tabla 67 – Matriz Entidad vs. Procesos de Negocio – TO BE
Fuente: Elaboración Propia
Los principales stakeholders que participarían de los procesos de negocio son:
N°
PROCESO
STAKEHOLDER
Ges
tión
Co
mer
cial
Ges
tión
de
Pro
yec
tos
Ges
tión
de
Fa
ctu
raci
ón
Ges
tión
de
Ca
rter
a d
e
Pro
du
ctos
y S
erv
icio
s
Ges
tión
de
Rec
urs
os
Hu
ma
no
s
Ges
tión
de
Infr
aes
tru
ctu
ra e
Info
rma
ció
n
Ges
tión
de
Co
mp
ras
Ges
tión
Ad
min
istr
ati
va
Ges
tión
de
Ase
sorí
a L
egal
1 Gerente de Línea de
Negocio X X X X
2 Director Comercial X X
3 PMO X
4 Asistente de
Recursos Humanos X X X
5 Asistente Contable X X X X
6 Gerente de
Operaciones X
Tabla 68 – Matriz Stakeholders vs. Procesos de Negocio – TO BE
Fuente: Elaboración Propia
ARQUITECTURA DE DATOS (TO BE)
Luego de analizar el modelo conceptual AS IS de los procesos de negocio Gestión
Comercial, Gestión de Proyectos y Gestión de Facturación, se evidenció la redundancia en el
manejo de información de proyectos, clientes y facturas.
La propuesta TO BE para la arquitectura de datos sugiere dar de baja a la aplicación XRay
desarrollada por la organización para realizar la gestión comercial y la gestión de facturación
directamente desde el Oracle EBS. Con esta propuesta, todas las entidades empleadas en el
AS IS se integrarán en un solo modelo de datos estandarizado, de manera que se garantice
que la arquitectura de datos TO BE esté alineada con los requerimientos del negocio.
A continuación, se presenta la propuesta de arquitectura de datos TO BE:
204
Figura 39 – Modelo Conceptual – TO BE
Fuente: Elaboración Propia
205
ID Objeto de Negocio Descripción
E001 Oportunidad Posible proyecto para un cliente.
E002 Tipo Tipo de oportunidad: Outsourcing, mantenimiento, licencias,
etc.
E003 Cliente Empresa a quien se le brinda un servicio.
E004 Proyecto Servicio que se lleva a cabo para un cliente.
E005 Industria Indica la industria a la que pertenece el cliente: Minería,
Salud, Finanzas, Construcción, Entretenimiento, etc.
E006 Mercado Indica si el cliente representa una pequeña, mediana o gran
empresa.
E007 Gestor Responsable de gestionar el proyecto.
E008 Línea_Negocio
Línea de negocio que lleva a cabo el proyecto con el cliente.
Actualmente existen 3 líneas de negocio para la Gerencia de
Proyectos SAP y 4 para la Gerencia de Proyectos Oracle.
E009 Estado Indica el estado del proyecto, recurso en el proyecto, y
factura.
E010 Prioridad Nivel de importancia de un proyecto y del recurso en un
proyecto, categorizado en: Alta, media y baja.
E011 Moneda Indica la moneda en que se estima el proyecto, se costea al
recurso y se genera la factura.
E012 Ciudad Ciudad de origen del cliente, donde se desarrolla el proyecto,
y donde se asigna a un recurso para un proyecto.
E013 Región Región o estado de origen del cliente, donde se desarrolla el
proyecto, y donde se asigna a un recurso para un proyecto.
E014 País País de origen del cliente donde se desarrolla el proyecto, y
donde se asigna a un recurso para un proyecto.
E015 Rol Rol que tiene un recurso.
E016 Recurso Recurso humano de la organización.
E017 Recurso_Proyecto Asignación de un recurso a un determinado proyecto.
E018 Concepto_Participación Concepto o motivo de la participación de un recurso en un
proyecto.
ID Objeto de Negocio Descripción
E019 Factura Contiene los datos de cabecera de la factura.
E020 Posición_Factura Contiene las posiciones o detalle de la factura.
E021 Condición_Pago Condición de pago de la factura. Puede ser a 30, 60, 90, 120
días, dependiendo de la negociación con el cliente.
E022 Unidad_Medida Unidad de medida del bien o servicio indicado a nivel de
posición de la factura.
E023 Centro_Costo Centro de costo al que se imputa la factura.
E024 Hoja_Alta Contiene los datos para gestionar un proyecto.
E025 Participación_Personal Detalle de la participación de un recurso en un proyecto,
expresada en porcentaje, horas y costos.
E026 Rentabilidad_Proyectada Proyección de la rentabilidad a considerarse en una hoja de
alta.
Tabla 69 – Entidades del Modelo Conceptual – TO BE
Fuente: Elaboración Propia
ARQUITECTURA DE APLICACIONES (TO BE)
La propuesta TO BE para la arquitectura de aplicaciones sugiere la centralización y
adecuación de los procesos Gestión Comercial, Gestión de Proyectos y Gestión de
Facturación bajo el esquema de Oracle EBS. Con esta propuesta, no solo se busca la
integración de los procesos de negocio mencionados anteriormente sino la optimización de
actividades o procedimientos internos en la organización.
A continuación, se presenta la propuesta de arquitectura de aplicaciones TO BE:
Figura 40 – Arquitectura de Aplicaciones – TO BE
Fuente: Elaboración Propia
ID Componente Descripción
A001 Oracle E-Business
Suite
Herramienta empleada para la gestión de clientes, proyectos,
y facturación. Contando además con un tablero de mando
que permita la generación de reportes y la evaluación de
indicadores de gestión.
Tabla 70 – Descripción de Componentes de Aplicaciones – TO BE
Fuente: Elaboración Propia
ARQUITECTURA TECNOLÓGICA (TO BE)
Los componentes de infraestructura detallados en el AS IS se mantienen en el TO BE; es
decir, la propuesta de integración de aplicaciones está soportada por la arquitectura de línea
base de la organización.
A continuación, se presenta la propuesta de arquitectura tecnológica TO BE:
Figura 41 – Arquitectura Tecnológica – TO BE
Fuente: Elaboración Propia
ID Componente Descripción
C001 Servidor IIS 7 Servidor de Internet que permite la publicación de aplicaciones
Web como Oracle E-Business Suite.
C002 Red Hat Enterprise
5.3 x86_64
Sistema Operativo sobre el cual se soporta la aplicación Oracle E-
Business Suite para la gestión de proyectos.
C003 Oracle versión
10.2.0.4.0
Servidor de Base de Datos empleado por la aplicación Oracle E-
Business Suite.
Tabla 71 – Descripción de Componentes de la Arquitectura Tecnológica – TO BE
Fuente: Elaboración Propia
ARQUITECTURA DE SEGURIDAD (TO BE)
Al igual que la arquitectura tecnológica, la arquitectura de seguridad se mantiene bajo el
mismo esquema presentado en el AS IS, ya que la integración y eliminación de aplicaciones
no supone un cambio en el manejo de la seguridad en la organización.
A continuación, se presenta la propuesta de arquitectura de seguridad TO BE:
Figura 35 – Arquitectura de Seguridad de la Organización – AS IS
Fuente: Elaboración Propia
Como se observa en el diagrama, se cuenta con un router central para interconectar las
diversas redes dentro de la organización. Actualmente, se cuenta con tres redes de trabajo
para los consultores y una red de servidores. Por otro lado, se tiene un firewall para
monitorear y controlar el tráfico de red entrante y saliente basado en reglas de seguridad
predeterminadas.
Además, presenta un router balanceador que actualmente soporta dos puertos WAN (de una
capacidad de cuatro), ofrece capacidades máximas de ancho de banda, y una conectividad a
internet confiable.
El túnel de Americatel es una salida protegida a las VPNs de tres clientes específicos de la
organización, el resto sale directamente por internet. El túnel óptico es una conexión de
respaldo.
211
ANALISIS DE BRECHAS
A continuación se detallan las diferencias encontradas por cada una de las arquitecturas de línea base de la organización y sus correspondientes
arquitecturas objetivo.
ARQUITECTURA DE NEGOCIO
Gestión Comercial:
Arquitectura Objetivo (TO BE)
Arquitectura Línea
Base (AS IS) Val
idar
ex
iste
nci
a d
e
clie
nte
Reg
istr
ar c
lien
te
Reg
istr
ar o
po
rtu
nid
ad
de
ven
ta
Def
inir
pla
n d
e v
isit
as a
clie
nte
s
Reg
istr
ar h
oja
de
alta
en e
l si
stem
a
So
lici
tar
apro
bac
ión
de
ho
ja d
e al
ta
Ev
alu
ar h
oja
de
alta
So
lici
tar
aju
ste
de
ho
ja
de
alta
Ap
rob
ar h
oja
de
alta
Co
rreg
ir d
ato
s d
e h
oja
de
alta
en
el
sist
ema
Ela
bo
rar
y e
nv
iar
pro
pu
esta
al
clie
nte
Rec
epci
on
ar o
rden
de
com
pra
Ela
bo
rar
con
trat
o
Act
ual
izar
est
ado
de
pro
pu
esta
So
lici
tar
crea
ció
n d
e
pro
yec
to
Validar existencia de
cliente
Se
mantiene
Arquitectura Objetivo (TO BE)
Arquitectura Línea
Base (AS IS) Val
idar
ex
iste
nci
a d
e
clie
nte
Reg
istr
ar c
lien
te
Reg
istr
ar o
po
rtu
nid
ad
de
ven
ta
Def
inir
pla
n d
e v
isit
as a
clie
nte
s
Reg
istr
ar h
oja
de
alta
en e
l si
stem
a
So
lici
tar
apro
bac
ión
de
ho
ja d
e al
ta
Ev
alu
ar h
oja
de
alta
So
lici
tar
aju
ste
de
ho
ja
de
alta
Ap
rob
ar h
oja
de
alta
Co
rreg
ir d
ato
s d
e h
oja
de
alta
en
el
sist
ema
Ela
bo
rar
y e
nv
iar
pro
pu
esta
al
clie
nte
Rec
epci
on
ar o
rden
de
com
pra
Ela
bo
rar
con
trat
o
Act
ual
izar
est
ado
de
pro
pu
esta
So
lici
tar
crea
ció
n d
e
pro
yec
to
Registrar cliente
Mejorar
Registrar oportunidad
de venta Mejorar
Definir plan de visitas a
clientes Mejorar
Elaborar hoja de alta en
Excel Mejorar
Solicitar aprobación de
hoja de alta Mejorar
Evaluar hoja de alta
Se
mantiene
Solicitar ajuste de hoja
de alta Mejorar
Aprobar hoja de alta
Mejorar
Corregir hoja de alta en
Excel Mejorar
Arquitectura Objetivo (TO BE)
Arquitectura Línea
Base (AS IS) Val
idar
ex
iste
nci
a d
e
clie
nte
Reg
istr
ar c
lien
te
Reg
istr
ar o
po
rtu
nid
ad
de
ven
ta
Def
inir
pla
n d
e v
isit
as a
clie
nte
s
Reg
istr
ar h
oja
de
alta
en e
l si
stem
a
So
lici
tar
apro
bac
ión
de
ho
ja d
e al
ta
Ev
alu
ar h
oja
de
alta
So
lici
tar
aju
ste
de
ho
ja
de
alta
Ap
rob
ar h
oja
de
alta
Co
rreg
ir d
ato
s d
e h
oja
de
alta
en
el
sist
ema
Ela
bo
rar
y e
nv
iar
pro
pu
esta
al
clie
nte
Rec
epci
on
ar o
rden
de
com
pra
Ela
bo
rar
con
trat
o
Act
ual
izar
est
ado
de
pro
pu
esta
So
lici
tar
crea
ció
n d
e
pro
yec
to
Elaborar y enviar
propuesta a cliente
Se
mantiene
Recepcionar orden de
compra
Se
mantiene
Elaborar contrato
Se
mantiene
Actualizar estado de
propuesta Mejorar
Solicitar creación de
proyecto Mejorar
Tabla 72 – Análisis de Brechas - Arquitectura de Negocio del Proceso de Gestión Comercial
Fuente: Elaboración Propia
214
Los GAPs encontrados en la arquitectura de negocio del proceso de Gestión Comercial son:
GAP1: Mejorar la gestión de clientes de manera que se evite la redundancia de
información en las aplicaciones Microsoft Dynamics CRM, Oracle EBS, y XRay. Con la
implementación de la propuesta, toda la gestión de clientes quedará centralizada en
Oracle EBS.
GAP2: Mejorar el procedimiento de manejo de la hoja de alta para que los datos sean
ingresados directamente en Oracle EBS, evitando así el uso de un formato Excel que
posteriormente se tenga que ingresar al sistema.
GAP3: Mejorar la solicitud de aprobación de hojas de alta, que no alcanzan el porcentaje
de rentabilidad esperado del 40%, mediante la implementación de un workflow que apoye
con el control y seguimiento de las solicitudes. Actualmente, esta actividad se da entre el
Gerente de Línea de Negocio y el Director Comercial vía telefónica o mediante una
reunión de manera presencial.
GAP4: Mejorar la solicitud de ajuste de hojas de alta mediante la implementación de un
workflow. Actualmente, esta actividad se lleva a cabo por el Director Comercial vía
telefónica o mediante el envío de un correo electrónico al Gerente de Línea de Negocio.
GAP 5: Mejorar la aprobación de hojas de alta mediante la implementación de un
workflow de aprobaciones que permita que el Director Comercial informe el estado
aprobado de una hoja de alta al Gerente de Línea de Negocio para que pueda continuar
con la elaboración de la propuesta y demás actividades que le corresponda.
GAP6: Mejorar la solicitud de creación de proyectos mediante la implementación de un
workflow que permita al Gerente de Línea de Negocio informarle a la PMO su necesidad
de creación de un proyecto en Oracle EBS.
Gestión de Proyectos:
Arquitectura Objetivo (TO BE)
Arquitectura Línea
Base (AS IS)
Val
idar
dat
os
de
ho
ja d
e
alta
So
lici
tar
crea
ció
n d
e
con
sult
or
Reg
istr
ar c
on
sult
or
en e
l
sist
ema
No
tifi
car
reg
istr
o d
e
con
sult
or
Act
ual
izar
ho
ja d
e al
ta
Gen
erar
pro
yec
to
Pu
bli
car
pro
yec
to
No
tifi
car
crea
ció
n d
e
pro
yec
to
EL
IMIN
AR
Validar datos de hoja
de alta
Se
mantiene
Registrar cliente
Eliminar
Crear proyecto
Mejorar
Validar consultores Mejorar
Asignar consultores a
proyecto Mejorar
Solicitar creación del
consultor
Se
mantiene
Registrar consultor en
el sistema
Se
mantiene
Notificar registro de
consultor
Se
mantiene
Crear Workplan
Mejorar
Verificar costos del
proyecto Eliminar
Ingresar presupuesto
Mejorar
Publicar proyecto
Se
mantiene
Notificar creación de
proyecto Mejorar
Tabla 73 – Análisis de Brechas - Arquitectura de Negocio del Proceso de Gestión de
Proyectos
Fuente: Elaboración Propia
Los GAPs encontrados en la arquitectura de negocio del proceso de Gestión de Proyectos
son:
GAP1: Eliminar el registro de clientes del proceso de Gestión de Proyectos ya que será
centralizado en el proceso de Gestión Comercial.
GAP2: Mejorar la validación de consultores ya que, actualmente, se lleva a cabo de
manera manual revisando los datos considerados en el formato Excel de la hoja de alta.
La propuesta considera el ingreso directo de la hoja de alta en el sistema, por lo que la
validación de los datos de los consultores y en general de todos los datos de la hoja de alta
se llevará a cabo en el Oracle EBS.
GAP3: Mejorar la gestión de la hoja de alta de manera que permita actualizarla
directamente en Oracle EBS. Con ello, se cuenta con una sola fuente de información
durante la gestión de proyectos.
GAP4: Mejorar la creación de los proyectos, workplan y presupuesto que venían siendo
registrados manualmente en el sistema. Éstos serán generados automáticamente a partir
de las hojas de alta previamente registradas en el sistema
GAP5: Eliminar la verificación de costos del proyecto del proceso de Gestión de
Proyectos ya que esta verificación está contemplada al momento de ingresar la hoja de
alta en el sistema.
GAP6: Mejorar la manera en que la PMO comunica la creación de los proyectos al
Gerente de Línea de Negocio mediante la implementación de notificaciones vía
workflow.
Gestión de Facturación:
Arquitectura Objetivo (TO BE)
Arquitectura Línea Base (AS IS) So
lici
tar
emis
ión
de
fact
ura
Gen
erar
fac
tura
Asi
gn
ar n
um
erac
ión
e
imp
rim
ir f
actu
ra
Co
ord
inar
en
treg
a d
e
fact
ura
EL
IMIN
AR
Registrar detalle de facturación en CRM
Eliminar
Solicitar emisión de factura Mejorar
Verificar existencia de cliente en XRay
Eliminar
Registrar cliente en XRay
Eliminar
Verificar existencia de proyecto en XRay
Eliminar
Registrar proyecto en XRay
Eliminar
Validar datos para emisión de factura
Eliminar
Solicitar corrección de datos
Eliminar
Corregir datos de facturación
Eliminar
Actualizar estado de factura en CRM
Eliminar
Crear registro de factura en EBS
Eliminar
Crear registro de factura en XRay
Eliminar
Realizar emisión de factura
Mejorar
Coordinar entrega de factura
Se mantiene
IMPLEMENTAR
Implementar
Tabla 74 – Análisis de Brechas - Arquitectura de Negocio del Proceso de Gestión de
Facturación
Fuente: Elaboración Propia
Los GAPs encontrados en la arquitectura de negocio del proceso de Gestión de Facturación
son:
GAP1: Eliminar el registro del detalle de la facturación en CRM ya que, producto de la
integración propuesta, será registrado en Oracle EBS.
GAP2: Mejorar la solicitud de emisión de facturas mediante la generación de
notificaciones vía workflow.
GAP3: Eliminar la verificación de la existencia de clientes en XRay ya que la propuesta
considera la baja de esta solución.
GAP4: Eliminar el registro de clientes en XRay ya que la propuesta considera la baja de
esta solución.
GAP5: Eliminar la verificación de la existencia de proyectos en XRay ya que la propuesta
considera la baja de esta solución.
GAP6: Eliminar el registro de proyectos en XRay ya que la propuesta considera la baja de
esta solución.
GAP7: Eliminar la validación de datos para la emisión de facturas ya que esta actividad
será incluida en la mejora de la generación de facturas.
GAP8: Eliminar la solicitud de corrección de datos ya que esta actividad será incluida en
la mejora de la generación de facturas.
GAP9: Eliminar la corrección de datos de facturación ya que esta actividad será incluida
en la mejora de la generación de facturas.
GAP10: Eliminar la actualización de estado de facturas en CRM ya que, producto de la
integración propuesta, será actualizado en Oracle EBS.
GAP11: Eliminar el registro de facturas en EBS ya que esta actividad será incluida en la
mejora de la generación de facturas.
GAP12: Eliminar el registro de facturas en XRay ya que la propuesta considera la baja de
esta solución.
GAP13: Mejorar la generación de facturas de manera que se evite la redundancia de
información en las aplicaciones Microsoft Dynamics CRM, Oracle EBS, y XRay. Con la
implementación de la propuesta, toda la gestión de facturas quedará centralizada en
Oracle EBS.
Implementar un esquema para la asignación de numeración de facturas de manera
individual o masivamente. De esta manera, las facturas tendrán la numeración
correspondiente al documento físico y se podrán imprimir. Esta numeración incluye el
tipo, serie y número de comprobante relacionado al documento físico.
220
ARQUITECTURA DE DATOS
Gestión Comercial:
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Po
sici
ón
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
Oportunidad A
Tipo
A
Proyecto
A
Cliente
A
Responsable
A
Línea_Negocio
A
Factura
A
Detalle_Factura
A
Moneda
A
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Po
sici
ón
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
Unidad_Medida
A
Prioridad
A
Condición_Pago
A
Estado
A
Ciudad
A
Región
A
País
A
IMPLEMENTAR
I I
I
I I I
I
I I I I
(Leyenda: S = Se mantiene, A = Actualizar, I = Implementar, E = Eliminar)
Tabla 75 – Análisis de Brechas - Arquitectura de Datos del Proceso de Gestión Comercial
Fuente: Elaboración Propia
222
Gestión de Proyectos:
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Po
sici
ón
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
Proyecto S
Industria
S
Mercado
S
Cliente
S
Gestor
S
Recurso
S
Rol
S
Recurso_Proyecto
S
Hoja_Alta
Workplan
Tarea
Factura
S
Posición_Factura
S
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Po
sici
ón
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
Unidad_Medida
S
Centro_Costo
S
Condición_Pago
S
Moneda
S
Prioridad
S
Estado
S
Linea_Negocio
S
Ciudad
S
Región
S
País
S
IMPLEMENTAR
I
I I I I
ACTUALIZAR A A
(Leyenda: S = Se mantiene, A = Actualizar, I = Implementar)
Tabla 76 – Análisis de Brechas - Arquitectura de Datos del Proceso de Gestión de Proyectos
Fuente: Elaboración Propia
Gestión de Facturación:
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS
IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Po
sici
ón
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
Proyecto A
Cliente A
Factura A
Posición_Factura A
Moneda A
Condición_Pago A
Estado A
Centro_Costo A
Unidad_Medida A
Línea_Negocio A
Ciudad A
Región A
País A
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS
IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Po
sici
ón
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
IMPLEMENTAR I I I I I I I I I I I I
ACTUALIZAR A A
(Leyenda: S = Se mantiene, I = Implementar)
Tabla 77 – Análisis de Brechas - Arquitectura de Datos del Proceso de Gestión de Facturación
Fuente: Elaboración Propia
226
Al proponer una integración de aplicaciones para el mejor manejo y control de la información
de los procesos Gestión Comercial, Gestión de Proyectos y Gestión de Facturación, se está
involucrando de manera directa a la arquitectura de datos. Por ello, el análisis de brechas para
esta arquitectura se presenta a nivel global; es decir, considerando las entidades de las tres
aplicaciones que soportan los procesos previamente mencionados.
Los GAPs encontrados en la arquitectura de datos de los procesos de Gestión Comercial,
Gestión de Proyectos, y Gestión de Facturación son:
GAP1: Eliminar las entidades tipo y oportunidad que hacen referencia al proceso de
Gestión Comercial. Dichos componentes del modelo de datos no serán utilizados en la
propuesta con Oracle EBS.
GAP2: Implementar un modelo que incorpore los datos considerados actualmente en la
hoja de alta en formato Excel, ya que estos datos deberán ser ingresados directamente en
el sistema.
GAP3: Actualizar y documentar la nomenclatura de las entidades para que se cuente con
un modelo de datos estandarizado. Por ejemplo, el detalle de factura es posición de
factura, la persona que administra un proyecto es un gestor en lugar de responsable, los
proyectos hacen referencia a líneas de negocio no a unidades de negocio.
ARQUITECTURA DE APLICACIONES
Arquitectura Objetivo (TO BE)
Arquitectura Línea Base (AS IS) Oracle E-Business Suite ELIMINAR
Microsoft Dynamics CRM
Eliminar
Oracle E-Business Suite Actualizar
XRay
Eliminar
Tabla 78 – Análisis de Brechas - Arquitectura de Aplicaciones
Fuente: Elaboración Propia
Los GAPs encontrados en la arquitectura de aplicaciones son:
GAP1: Eliminar aplicaciones redundantes para la Gestión Comercial y Gestión de
Facturación.
GAP2: Actualizar la aplicación Oracle EBS para garantizar la centralización,
alineamiento y optimización de actividades de los procesos Gestión Comercial, Gestión
de Proyectos y Gestión de Facturación. Esta actualización incluye la configuración en el
sistema para la gestión de clientes, gestión de proyectos, generación de reportes de
seguimiento y avance de proyectos, y facturación.
CONCLUSIONES
1. Se ha logrado comprender el contexto del negocio y el nivel de alineamiento existente
entre objetivos estratégicos y los procesos principales de éste, lo que ha permitido
identificar las áreas y aspectos que requieren de un mayor nivel de atención y mejora.
2. Se ha logrado evidenciar duplicidad e inconsistencia de datos entre los aplicativos que
soportan los procesos principales del negocio, siendo esta la principal fuente de
información para la emisión de reportes que apoyen la toma de decisiones.
3. Se ha logrado evidenciar que los aplicativos que soportan los procesos estratégicos de la
organización se encuentra completamente incomunicados, derivando a labor manual la
integración de la información entre estos, generando un cierto grado de desconfianza la
emisión de reportes de seguimiento tanto en el aspecto comercial como en la de gestión
de proyectos.
4. Se ha logrado evidenciar la importancia de elaborar un mapa de capacidades que permita
identificar la relación entre los componentes de la arquitectura de negocio y de TI,
sobretodo en la tarea de orientar los procesos en función de la evolución de las estrategias
de la organización.
5. Se ha logrado plantear una solución alineada a los objetivos estratégicos de la
organización, que brinda información fidedigna y fomenta la colaboración entre las áreas
involucradas.
CAPÍTULO 5: ESTRUCTURA PROPUESTA
INTRODUCCIÓN
En este capítulo se presentará la propuesta final a implementar para dar soporte a la
Arquitectura Empresarial y al proceso de Mantenimiento y Desarrollo de Software manejado
dentro de la empresa TSNET S.A.
ENFOQUE DE LA PROPUESTA
El enfoque de la propuesta está orientado a resolver la problemática de los aspectos evaluados
en el presente documento: Gestión del Recurso Profesional, Gestión de Servicios en TI y
Arquitectura Empresarial; y presentar un marco de trabajo que permita su optimización e
integración de acuerdo a los estándares aplicados en cada uno de ellos: P-CMM, ITIL y
TOGAF, respectivamente.
METAS Y OBJETIVOS
Analizar las fortalezas y debilidades del equipo de trabajo de una línea de negocio
encargada de brindar soporte al proceso de Mantenimiento y Desarrollo de Software.
Desarrollar una Arquitectura de Personal que permita identificar el perfil profesional
deseado del 100% de los roles involucrados en la línea de negocio analizada previamente.
Optimizar el proceso de Mantenimiento y Desarrollo de Software en un 90%.
Alcanzar la rentabilidad estimada del 80% de los proyectos.
Definir una Arquitectura Empresarial que soporte dos procesos estratégicos de la
organización: Gestión Comercial y Gestión de Proyectos, y el proceso de soporte: Gestión
de Facturación.
SITUACIÓN ACTUAL (AS IS)
En la siguiente gráfica se muestra la situación actual de la organización, en la cual se ve
reflejada la interacción de los responsables de cada uno de los tres procesos de negocio
seleccionados para el estudio y propuesta de implementación, así como la utilización de las
respectivas aplicaciones tecnológicas.
Las flechas de color verde indican una actividad de gestión directa entre el responsable y la
aplicación, mientras que las flechas de color naranja indican una actividad solo de
visualización de información cuando sea requerida.
Figura 42 – Situación Actual (AS IS)
Fuente: Elaboración Propia
SITUACIÓN OBJETIVO (TO BE)
En la siguiente gráfica se muestra la situación objetivo a la que se desea llegar con la presente
propuesta, en la cual se ve reflejada la integración de los tres procesos de negocio
seleccionados así como la interacción de sus responsables bajo una misma aplicación: Oracle
EBS.
Figura 43 – Situación Objetivo (TO BE)
Fuente: Elaboración Propia
ANÁLISIS DE LA PROBLEMÁTICA ENCONTRADA
A continuación se indicarán los principales problemas encontrados en cada uno de los
aspectos evaluados en el presente documento:
Arquitectura Empresarial:
SITUACION PROBLEMÁTICA PROBLEMA A RESOLVER
Falta de difusión del Plan Estratégico
Empresarial (PEE).
Personal no identificado con los objetivos de
la organización, lo que genera falta de
compromiso en el alcance de las metas
propuestas.
Ineficiente alineamiento de objetivos y
procesos estratégicos.
No existe integración entre las aplicaciones
que soportan los procesos estratégicos de la
organización, lo que conlleva a redundancia
de información y tareas.
No existe reportes de trazabilidad entre la
información Comercial y de Proyectos en
tiempo real.
Las fuentes de información para el análisis
de los procesos estratégicos no son 100%
confiables para la toma de decisiones debido
a que la información no siempre se
encuentra disponible en las aplicaciones
correspondientes.
Resistencia al cambio
Los Gerentes de Línea de Negocio realizan
sus proyecciones de ingresos y medición de
rentabilidad de proyectos en base a la Hoja
de Alta manejada en formato Excel en lugar
de utilizar la aplicación Oracle E-Business
Suite destinada a dicho fin.
Ineficiente gestión de la información de
Facturación.
La información de facturación manejada en
el sistema contable XRay, debe ser
posteriormente replicada en las aplicaciones
de Microsoft Dynamics CRM y Oracle EBS.
Sin embargo, se detectan inconsistencias por
omisiones de actualización.
SITUACION PROBLEMÁTICA PROBLEMA A RESOLVER
Al finalizar cada ciclo de facturación se
deben realizar cruces de información para
validar que las tres aplicaciones estén
alineadas con la información de facturación.
Esta labor es ejecutada de manera manual.
Tabla 79 – Situación Problemática - Arquitectura Empresarial
Fuente: Elaboración Propia
Gestión de Servicios TI:
SITUACION PROBLEMÁTICA PROBLEMA A RESOLVER
Deficiente elaboración de plan de capacidad.
El número actual de consultores no da
abasto para cubrir la atención de los
requerimientos reportados por los clientes,
lo que conlleva al incumplimiento de los
niveles de servicio pactados, y muchas
veces a la pérdida de oportunidades para
concretar nuevos proyectos.
El esquema de doble turno planteado no
siempre cuenta con la disponibilidad de
los consultores.
Falta de aplicación de métricas para la
evaluación del servicio.
No se lleva un control de los tiempos de
atención de incidentes reportados por los
clientes, lo que impide hacer seguimiento
a la calidad del servicio y plantear nuevas
oportunidades de mejora en el mismo.
Inadecuada gestión de la información No se cuenta con un repositorio
SITUACION PROBLEMÁTICA PROBLEMA A RESOLVER
centralizado de documentación de los
proyectos e incidentes atendidos que
puedan servir como material de apoyo
para la atención de requerimientos.
Tabla 80 – Situación Problemática – Gestión de Servicios TI
Fuente: Elaboración Propia
Gestión del Recurso Profesional:
SITUACION PROBLEMÁTICA PROBLEMA A RESOLVER
Falta de definición de perfiles del personal de
la organización.
No se cuenta con una definición precisa
del perfil de las posiciones en la
organización que conlleva a un
inadecuado proceso de reclutamiento de
personal.
La mala conformación de equipos de
trabajo para hacer frente a los proyectos
manejados por la organización, lo que
genera en ocasiones un grado de
insatisfacción por parte del cliente.
Ineficiente proceso de evaluación continua del
personal.
No se cuenta con el compromiso de todos
los Gerentes de Línea de Negocio en el
proceso de evaluación de personal.
No siempre se cuenta con una
retroalimentación al personal acerca de su
desempeño dentro de los proyectos, lo que
SITUACION PROBLEMÁTICA PROBLEMA A RESOLVER
impide el desarrollo o mejora de sus
capacidades.
No existe un mapa de habilidades y
capacidades del personal que ayude a
conformar de manera óptima equipos de
trabajo y asignar nuevas
responsabilidades.
Ausencia de planes de capacitación.
Fomenta la migración y/o disconformidad
del personal de la organización al no
divisar oportunidades de crecimiento.
Tabla 81 – Situación Problemática – Gestión del Recurso Profesional
Fuente: Elaboración Propia
DESCRIPCIÓN DE LA PROPUESTA
De acuerdo a los problemas identificados y enunciados en el punto anterior, se presenta una
propuesta de Arquitectura Empresarial para la empresa TSNET S.A. que aborde el proceso de
Mantenimiento y Desarrollo de Software aplicable a los procesos estratégicos Gestión
Comercial y Gestión de Proyectos, y al proceso de soporte Gestión de Facturación.
La propuesta abarca la integración del estándar P-CMM para la Gestión del Recurso
Profesional, el marco de trabajo propuesto por ITIL para la Gestión de Servicios en TI, y el
marco de trabajo propuesto por TOGAF para el desarrollo e implementación de una
Arquitectura Empresarial.
Figura 44 – Propuesta de Arquitectura Empresarial
Fuente: Elaboración Propia
Cabe resaltar que la propuesta no es aplicable a la Arq. Tecnológica debido a que el enfoque
está orientado al proceso de Mantenimiento y Desarrollo de Software.
ESTRATEGIA DE IMPLEMENTACIÓN:
Para la implementación de la propuesta, es necesario tener en cuenta las siguientes
consideraciones generales:
Contar con el apoyo de la Alta Gerencia: Es necesario contar con el compromiso de la
Alta Gerencia para garantizar el éxito del proyecto en materia de presupuesto, prestación
de recursos, tiempos y participación de las áreas de la organización.
Concientización de la necesidad de mejora: Presentar el resultado del análisis de la
problemática encontrada y fomentar una campaña de concientización y adopción de la
solución propuesta dirigida al personal de la organización.
A continuación se detallan las consideraciones específicas para cada uno de los bloques que
componen la propuesta:
A nivel de Arquitectura Empresarial:
De acuerdo al análisis realizado de la problemática sobre los procesos estratégicos de la
organización, el estado de la arquitectura de línea base y la arquitectura objetivo, se plantea la
integración de las aplicaciones que soportan los procesos de: Gestión Comercial, Gestión de
Proyectos y Gestión de Facturación dentro de una única plataforma: Oracle E-Business Suite.
Para ello, se tendrá en cuenta los requerimientos de negocio y los elementos identificados
dentro de cada una de las arquitecturas que componen el modelo de Arquitectura
Empresarial.
ARQUITECTURA DE NEGOCIO (TO BE)
En base a la arquitectura de negocios objetivo de la organización se presenta la propuesta de
negocio para los procesos mencionados previamente, y su representación gráfica en
diagramas de proceso con las mejoras respectivas para cada uno de ellos.
Procesos seleccionados:
A continuación se describirán cada uno de los procesos que cubre el alcance del presente
capítulo:
Proceso de Gestión Comercial:
La propuesta consiste en la integración de las aplicaciones Microsoft Dynamics CRM y
Oracle E-Business Suite para evitar la redundancia de información que, muchas veces, puede
llevar a un incorrecto análisis y toma de decisiones a partir de una fuente de información
desactualizada. Además, en el mercado existe una solución CRM integrada propia de Oracle,
lo que refuerza aún más la propuesta de integración.
Los principales cambios o mejoras que se proponen para el proceso de Gestión Comercial se
listan a continuación:
Registrar cliente: Actividad mejorada ya que se trabajará de manera centralizada en el
Oracle E-Business Suite, evitando tareas duplicadas.
Registrar hoja de alta en el sistema: Ya no manejará en formato Excel, se ingresará
directamente en el Oracle E-Business Suite.
Solicitar aprobación de hoja de alta: Actividad automatizada que se llevará a cabo
mediante un workflow33
de aprobaciones.
Solicitar ajuste de hoja de alta: Actividad automatizada que se llevará a cabo mediante un
workflow de aprobaciones.
Aprobar hoja de alta: Actividad automatizada que se llevará a cabo mediante un
workflow de aprobaciones.
Corregir datos de hoja de alta en el sistema: Las correcciones de datos en la hoja de alta
ya no se manejarán en formato Excel, se realizarán directamente en el Oracle E-Business
Suite.
Solicitar creación de proyecto: Actividad automatizada que se llevará a cabo mediante un
workflow de aprobaciones.
33 Flujo de trabajo a seguir para la realización de actividades de un proceso de negocio de
manera secuencial.
239
Figura 36 – Diagrama del Proceso de Gestión Comercial – TO BE
Fuente: Elaboración Propia
240
Proceso de Gestión de Proyectos:
La propuesta consiste en el ingreso directo de la hoja de alta en el Oracle E-Business Suit de
manera que se prescinda del uso de un formato Excel, lo que actualmente representa una
duplicidad de actividades.
Los principales cambios o mejoras que se proponen para el proceso de Gestión de Proyectos
se listan a continuación:
Validar datos de hoja de alta: Validación interna de los consultores, en el Oracle E-
Business Suite. Por ejemplo, un recurso pudo haber sido considerado en una hoja de alta
y luego pudo haber sido dado de baja en el sistema. Al momento de seleccionar la hoja de
alta para la generación del proyecto, el sistema alertará que el recurso ya no puede ser
utilizado.
Actualizar hoja de alta: La actualización de la hoja de alta ya no manejará en formato
Excel, se actualizará directamente en el Oracle E-Business Suite.
Generar proyecto: Ya no existe la necesidad de crear un workplan (que contiene los
recursos a emplearse en un proyecto), verificar costos e ingresar presupuesto, ya que
forman parte de la hoja de alta. En esta actividad, la PMO solo busca en el sistema la hoja
de alta previamente registrada para generar el proyecto.
Notificar creación de proyecto: Actividad automatizada que se llevará a cabo mediante un
workflow de aprobaciones.
Figura 37 – Diagrama del Proceso de Gestión de Proyectos – TO BE
Fuente: Elaboración Propia
Proceso de Gestión de Facturación:
La propuesta consiste en dar de baja a la aplicación XRay desarrollada por la organización
para realizar la gestión de facturación directamente desde el Oracle E-Business Suit. De esta
manera, se evita la redundancia en el ingreso de datos.
Cabe mencionar que la aplicación XRay se encuentra obsoleta ya que en la actualidad no
cuenta con un mantenimiento por parte de la organización, y su funcionalidad de facturación
se ajusta con los beneficios brindados por la aplicación de Oracle.
Los principales cambios o mejoras que se proponen para el proceso de Gestión de
Facturación se listan a continuación:
Solicitar emisión de factura: Actividad automatizada que se llevará a cabo mediante una
notificación vía workflow para la emisión de la factura.
Generar factura: Actividad mejorada ya que se trabajará de manera centralizada en el
Oracle E-Business Suite, evitando tareas duplicadas.
Asignar numeración e imprimir factura: Actividad nueva a implementarse en el Oracle E-
Business Suite. De esta manera, las facturas tendrán una numeración correspondiente al
documento físico y se podrán imprimir. Esta numeración incluye el tipo, serie y número
de comprobante con relación al documento físico.
Figura 38 – Diagrama del Proceso de Gestión de Facturación – TO BE
Fuente: Elaboración Propia
ARQUITECTURA DE DATOS (TO BE)
La propuesta TO BE para la arquitectura de datos sugiere dar de baja a la aplicación XRay
desarrollada por la organización para realizar la gestión comercial y la gestión de facturación
directamente desde el Oracle EBS. Con esta propuesta, todas las entidades empleadas en el
AS IS se integrarán en un solo modelo de datos estandarizado, de manera que se garantice
que la arquitectura de datos TO BE esté alineada con los requerimientos del negocio.
A continuación, se presenta la propuesta de arquitectura de datos TO BE:
243
Figura 39 – Modelo Conceptual – TO BE
Fuente: Elaboración Propia
244
ID Objeto de Negocio Descripción
E001 Oportunidad Posible proyecto para un cliente.
E002 Tipo Tipo de oportunidad: Outsourcing, mantenimiento, licencias,
etc.
E003 Cliente Empresa a quien se le brinda un servicio.
E004 Proyecto Servicio que se lleva a cabo para un cliente.
E005 Industria Indica la industria a la que pertenece el cliente: Minería,
Salud, Finanzas, Construcción, Entretenimiento, etc.
E006 Mercado Indica si el cliente representa una pequeña, mediana o gran
empresa.
E007 Gestor Responsable de gestionar el proyecto.
E008 Línea_Negocio
Línea de negocio que lleva a cabo el proyecto con el cliente.
Actualmente existen 3 líneas de negocio para la Gerencia de
Proyectos SAP y 4 para la Gerencia de Proyectos Oracle.
E009 Estado Indica el estado del proyecto, recurso en el proyecto, y
factura.
E010 Prioridad Nivel de importancia de un proyecto y del recurso en un
proyecto, categorizado en: Alta, media y baja.
E011 Moneda Indica la moneda en que se estima el proyecto, se costea al
recurso y se genera la factura.
E012 Ciudad Ciudad de origen del cliente, donde se desarrolla el proyecto,
y donde se asigna a un recurso para un proyecto.
E013 Región Región o estado de origen del cliente, donde se desarrolla el
proyecto, y donde se asigna a un recurso para un proyecto.
E014 País País de origen del cliente donde se desarrolla el proyecto, y
donde se asigna a un recurso para un proyecto.
E015 Rol Rol que tiene un recurso.
E016 Recurso Recurso humano de la organización.
E017 Recurso_Proyecto Asignación de un recurso a un determinado proyecto.
E018 Concepto_Participación Concepto o motivo de la participación de un recurso en un
proyecto.
ID Objeto de Negocio Descripción
E019 Factura Contiene los datos de cabecera de la factura.
E020 Posición_Factura Contiene las posiciones o detalle de la factura.
E021 Condición_Pago Condición de pago de la factura. Puede ser a 30, 60, 90, 120
días, dependiendo de la negociación con el cliente.
E022 Unidad_Medida Unidad de medida del bien o servicio indicado a nivel de
posición de la factura.
E023 Centro_Costo Centro de costo al que se imputa la factura.
E024 Hoja_Alta Contiene los datos para gestionar un proyecto.
E025 Participación_Personal Detalle de la participación de un recurso en un proyecto,
expresada en porcentaje, horas y costos.
E026 Rentabilidad_Proyectada Proyección de la rentabilidad a considerarse en una hoja de
alta.
Tabla 69 – Entidades del Modelo Conceptual – TO BE
Fuente: Elaboración Propia
ARQUITECTURA DE APLICACIONES (TO BE)
La propuesta TO BE para la arquitectura de aplicaciones sugiere la centralización y
adecuación de los procesos Gestión Comercial, Gestión de Proyectos y Gestión de
Facturación bajo el esquema de Oracle EBS. Con esta propuesta, no solo se busca la
integración de los procesos de negocio mencionados anteriormente sino la optimización de
actividades o procedimientos internos en la organización.
A continuación, se presenta la propuesta de arquitectura de aplicaciones TO BE:
Figura 40 – Arquitectura de Aplicaciones – TO BE
Fuente: Elaboración Propia
ID Componente Descripción
A001 Oracle E-Business
Suite
Herramienta empleada para la gestión de clientes, proyectos,
y facturación. Contando además con un tablero de mando
que permita la generación de reportes y la evaluación de
indicadores de gestión.
Tabla 70 – Descripción de Componentes de Aplicaciones – TO BE
Fuente: Elaboración Propia
ARQUITECTURA TECNOLÓGICA (TO BE)
Los componentes de infraestructura detallados en el AS IS se mantienen en el TO BE; es
decir, la propuesta de integración de aplicaciones está soportada por la arquitectura de línea
base de la organización.
A continuación, se presenta la propuesta de arquitectura tecnológica TO BE:
Figura 41 – Arquitectura Tecnológica – TO BE
Fuente: Elaboración Propia
ID Componente Descripción
C001 Servidor IIS 7 Servidor de Internet que permite la publicación de aplicaciones
Web como Oracle E-Business Suite.
C002 Red Hat Enterprise
5.3 x86_64
Sistema Operativo sobre el cual se soporta la aplicación Oracle E-
Business Suite para la gestión de proyectos.
C003 Oracle versión
10.2.0.4.0
Servidor de Base de Datos empleado por la aplicación Oracle E-
Business Suite.
Tabla 71 – Descripción de Componentes de la Arquitectura Tecnológica – TO BE
Fuente: Elaboración Propia
ANALISIS DE BRECHAS
A continuación se detallan las diferencias encontradas por cada una de las arquitecturas de
línea base de la organización y sus correspondientes arquitecturas objetivo.
ARQUITECTURA DE NEGOCIO
Gestión Comercial:
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS
IS)
Reg
istr
ar c
lien
te
Reg
istr
ar o
po
rtu
nid
ad d
e
ven
ta
Def
inir
pla
n d
e v
isit
as a
clie
nte
s
Reg
istr
ar h
oja
de
alta
en
el s
iste
ma
So
lici
tar
apro
bac
ión
de
ho
ja d
e al
ta
So
lici
tar
aju
ste
de
ho
ja
de
alta
Ap
rob
ar h
oja
de
alta
Co
rreg
ir d
ato
s d
e h
oja
de
alta
en
el
sist
ema
Act
ual
izar
est
ado
de
pro
pu
esta
So
lici
tar
crea
ció
n d
e
pro
yec
to
Registrar cliente Mejorar
Registrar
oportunidad de
venta
Mejorar
Definir plan de
visitas a clientes
Mejorar
Elaborar hoja de
alta en Excel
Mejorar
Solicitar
aprobación de hoja
de alta
Mejorar
Solicitar ajuste de
hoja de alta
Mejorar
Aprobar hoja de
alta
Mejorar
Corregir hoja de
alta en Excel
Mejorar
Actualizar estado
de propuesta
Mejorar
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS
IS)
Reg
istr
ar c
lien
te
Reg
istr
ar o
po
rtu
nid
ad d
e
ven
ta
Def
inir
pla
n d
e v
isit
as a
clie
nte
s
Reg
istr
ar h
oja
de
alta
en
el s
iste
ma
So
lici
tar
apro
bac
ión
de
ho
ja d
e al
ta
So
lici
tar
aju
ste
de
ho
ja
de
alta
Ap
rob
ar h
oja
de
alta
Co
rreg
ir d
ato
s d
e h
oja
de
alta
en
el
sist
ema
Act
ual
izar
est
ado
de
pro
pu
esta
So
lici
tar
crea
ció
n d
e
pro
yec
to
Solicitar creación
de proyecto
Mejorar
Tabla 72 – Análisis de Brechas - Arquitectura de Negocio del Proceso de Gestión Comercial
Fuente: Elaboración Propia
Los GAPs encontrados en la arquitectura de negocio del proceso de Gestión Comercial son:
GAP1: Mejorar la gestión de clientes de manera que se evite la redundancia de
información en las aplicaciones Microsoft Dynamics CRM, Oracle EBS, y XRay. Con la
implementación de la propuesta, toda la gestión de clientes quedará centralizada en
Oracle EBS.
GAP2: Mejorar el procedimiento de manejo de la hoja de alta para que los datos sean
ingresados directamente en Oracle EBS, evitando así el uso de un formato Excel que
posteriormente se tenga que ingresar al sistema.
GAP3: Mejorar la solicitud de aprobación de hojas de alta, que no alcanzan el porcentaje
de rentabilidad esperado del 40%, mediante la implementación de un workflow que apoye
con el control y seguimiento de las solicitudes. Actualmente, esta actividad se da entre el
Gerente de Línea de Negocio y el Director Comercial vía telefónica o mediante una
reunión de manera presencial.
GAP4: Mejorar la solicitud de ajuste de hojas de alta mediante la implementación de un
workflow. Actualmente, esta actividad se lleva a cabo por el Director Comercial vía
telefónica o mediante el envío de un correo electrónico al Gerente de Línea de Negocio.
GAP 5: Mejorar la aprobación de hojas de alta mediante la implementación de un
workflow de aprobaciones que permita que el Director Comercial informe el estado
aprobado de una hoja de alta al Gerente de Línea de Negocio para que pueda continuar
con la elaboración de la propuesta y demás actividades que le corresponda.
GAP6: Mejorar la solicitud de creación de proyectos mediante la implementación de un
workflow que permita al Gerente de Línea de Negocio informarle a la PMO su necesidad
de creación de un proyecto en Oracle EBS.
Gestión de Proyectos:
Arquitectura Objetivo (TO BE)
Arquitectura Línea Base (AS IS)
Val
idar
dat
os
de
ho
ja d
e al
ta
Act
ual
izar
ho
ja
de
alta
Gen
erar
pro
yec
to
No
tifi
car
crea
ció
n d
e
pro
yec
to
EL
IMIN
AR
Registrar cliente
Eliminar
Crear proyecto
Mejorar
Validar consultores Mejorar
Asignar consultores a proyecto
Mejorar
Crear WorkPlan
Mejorar
Verificar costos del proyecto
Eliminar
Ingresar presupuesto
Mejorar
Notificar creación de proyecto
Mejorar
Tabla 73 – Análisis de Brechas - Arquitectura de Negocio del Proceso de Gestión de
Proyectos
Fuente: Elaboración Propia
Los GAPs encontrados en la arquitectura de negocio del proceso de Gestión de Proyectos
son:
GAP1: Eliminar el registro de clientes del proceso de Gestión de Proyectos ya que será
manejado en el proceso de Gestión Comercial.
GAP2: Mejorar la validación de consultores ya que, actualmente, se lleva a cabo de
manera manual revisando los datos considerados en el formato Excel de la hoja de alta.
La propuesta considera el ingreso directo de la hoja de alta en el sistema, por lo que la
validación de los datos de los consultores y en general de todos los datos de la hoja de alta
se llevará a cabo en el Oracle EBS.
GAP3: Mejorar la gestión de la hoja de alta de manera que permita actualizarla
directamente en Oracle EBS. Con ello, se cuenta con una sola fuente de información
durante la gestión de proyectos.
GAP4: Mejorar la creación de los proyectos, workplan y presupuesto que venían siendo
registrados manualmente en el sistema. Éstos serán generados automáticamente a partir
de las hojas de alta previamente registradas en el sistema.
GAP5: Eliminar la verificación de costos del proyecto del proceso de Gestión de
Proyectos ya que esta verificación está contemplada al momento de ingresar la hoja de
alta en el sistema.
GAP6: Mejorar la manera en que la PMO comunica la creación de los proyectos al
Gerente de Línea de Negocio mediante la implementación de notificaciones vía
workflow.
Gestión de Facturación:
Arquitectura Objetivo (TO BE)
Arquitectura Línea Base (AS IS) So
lici
tar
emis
ión
de
fact
ura
Gen
erar
fac
tura
Asi
gn
ar n
um
erac
ión
e
imp
rim
ir f
actu
ra
EL
IMIN
AR
Registrar detalle de facturación en CRM
Eliminar
Solicitar emisión de factura Mejorar
Verificar existencia de cliente en XRay
Eliminar
Registrar cliente en XRay
Eliminar
Verificar existencia de proyecto en XRay
Eliminar
Registrar proyecto en XRay
Eliminar
Validar datos para emisión de factura
Eliminar
Solicitar corrección de datos
Eliminar
Corregir datos de facturación
Eliminar
Actualizar estado de factura en CRM
Eliminar
Crear registro de factura en EBS
Eliminar
Crear registro de factura en XRay
Eliminar
Realizar emisión de factura
Mejorar
IMPLEMENTAR
Implementar
Tabla 74 – Análisis de Brechas - Arquitectura de Negocio del Proceso de Gestión de
Facturación
Fuente: Elaboración Propia
Los GAPs encontrados en la arquitectura de negocio del proceso de Gestión de Facturación
son:
GAP1: Eliminar el registro del detalle de la facturación en Microsoft Dynamics CRM ya
que, producto de la integración propuesta, será registrado en Oracle EBS.
GAP2: Mejorar la solicitud de emisión de facturas mediante la generación de
notificaciones vía workflow.
GAP3: Eliminar la verificación de la existencia de clientes en XRay ya que la propuesta
considera la baja de esta aplicación.
GAP4: Eliminar el registro de clientes en XRay ya que la propuesta considera la baja de
esta aplicación.
GAP5: Eliminar la verificación de la existencia de proyectos en XRay ya que la propuesta
considera la baja de esta aplicación.
GAP6: Eliminar el registro de proyectos en XRay ya que la propuesta considera la baja de
esta aplicación.
GAP7: Eliminar la validación de datos para la emisión de facturas ya que esta actividad
será incluida en la mejora de la generación de facturas.
GAP8: Eliminar la solicitud de corrección de datos ya que esta actividad será incluida en
la mejora de la generación de facturas.
GAP9: Eliminar la corrección de datos de facturación ya que esta actividad será incluida
en la mejora de la generación de facturas.
GAP10: Eliminar la actualización de estado de facturas en Microsoft Dynamics CRM ya
que, producto de la integración propuesta, será actualizado en Oracle EBS.
GAP11: Eliminar el registro de facturas en EBS ya que esta actividad será incluida en la
mejora de la generación de facturas.
GAP12: Eliminar el registro de facturas en XRay ya que la propuesta considera la baja de
esta aplicación.
GAP13: Mejorar la generación de facturas de manera que se evite la redundancia de
información en las aplicaciones Microsoft Dynamics CRM, Oracle EBS, y XRay. Con la
implementación de la propuesta, toda la gestión de facturas quedará centralizada en
Oracle EBS.
Implementar un esquema para la asignación de numeración de facturas de manera
individual o masiva. De esta manera, las facturas tendrán la numeración correspondiente
al documento físico y se podrán imprimir. Esta numeración incluye el tipo, serie y
número de comprobante relacionado al documento físico.
255
ARQUITECTURA DE DATOS
Gestión Comercial:
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS
IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Det
alle
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
Oportunidad A
Tipo
A
Proyecto
A
Cliente
A
Responsable
A
Línea_Negocio
A
Factura
A
Detalle_Factura
A
Moneda
A
Unidad_Medida
A
Prioridad
A
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS
IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Det
alle
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
Condición_Pago
A
Estado
A
Ciudad
A
Región
A
País
A
IMPLEMENTAR
I I
I I I
I
I I I I
(Leyenda: A = Actualizar, I = Implementar, E = Eliminar)
Tabla 75 – Análisis de Brechas - Arquitectura de Datos del Proceso de Gestión Comercial
Fuente: Elaboración Propia
257
Gestión de Proyectos:
Arquitectura Objetivo (TO BE)
Arquitectura Línea Base (AS
IS)
Op
ort
un
idad
Tip
o
Un
idad
_N
ego
cio
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
IMPLEMENTAR I I I I I
ACTUALIZAR A A
(Leyenda: S = Se mantiene, A = Actualizar, I = Implementar)
Tabla 76 – Análisis de Brechas - Arquitectura de Datos del Proceso de Gestión de Proyectos
Fuente: Elaboración Propia
258
Gestión de Facturación:
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS
IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Po
sici
ón
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
Proyecto
A
Cliente
A
Factura
A
Posición_Factura
A
Moneda
A
Condición_Pago
A
Estado
A
Centro_Costo
A
Unidad_Medida
A
Línea_Negocio
A
Ciudad
A
Región
A
Arquitectura Objetivo (TO BE)
Arquitectura
Línea Base (AS
IS)
Op
ort
un
idad
Tip
o
Pro
yec
to
Ind
ust
ria
Mer
cad
o
Cli
ente
Ges
tor
Un
idad
_N
ego
cio
Lín
ea_
Neg
oci
o
Rec
urs
o
Ro
l
Rec
urs
o_
Pro
yec
to
Fac
tura
Po
sici
ón
_F
actu
ra
Cen
tro
_C
ost
o
Mo
ned
a
Co
nd
ició
n_
Pag
o
Un
idad
_M
edid
a
Ho
ja_
Alt
a
Co
nce
pto
_P
arti
cip
ació
n
Par
tici
pac
ión
_P
erso
nal
Ren
tab
ilid
ad_
Pro
yec
tad
a
Pri
ori
dad
Est
ado
Ciu
dad
Reg
ión
Paí
s
País
A
IMPLEMENTAR
I I
I I
I I I
I I I I I
ACTUALIZAR A A
(Leyenda: S = Se mantiene, I = Implementar)
Tabla 77 – Análisis de Brechas - Arquitectura de Datos del Proceso de Gestión de Facturación
Fuente: Elaboración Propia
260
Al proponer una integración de aplicaciones para el mejor manejo y control de la información
de los procesos Gestión Comercial, Gestión de Proyectos y Gestión de Facturación, se está
involucrando de manera directa a la arquitectura de datos. Por ello, el análisis de brechas para
esta arquitectura se presenta a nivel global; es decir, considerando las entidades de las tres
aplicaciones que soportan los procesos previamente mencionados.
Los GAPs encontrados en la arquitectura de datos de los procesos de Gestión Comercial,
Gestión de Proyectos, y Gestión de Facturación son:
GAP1: Implementar un modelo que incorpore los datos considerados actualmente en la
hoja de alta en formato Excel, ya que estos datos deberán ser ingresados directamente en
el sistema.
GAP2: Actualizar y documentar la nomenclatura de las entidades para que se cuente con
un modelo de datos estandarizado.
ARQUITECTURA DE APLICACIONES
Arquitectura Objetivo (TO BE)
Arquitectura Línea Base (AS IS) Oracle E-Business Suite ELIMINAR
Microsoft Dynamics CRM
Eliminar
Oracle E-Business Suite Actualizar
XRay
Eliminar
Tabla 78 – Análisis de Brechas - Arquitectura de Aplicaciones
Fuente: Elaboración Propia
Los GAPs encontrados en la arquitectura de aplicaciones son:
GAP1: Eliminar aplicaciones redundantes para la Gestión Comercial y Gestión de
Facturación.
GAP2: Actualizar la aplicación Oracle EBS para garantizar la centralización,
alineamiento y optimización de actividades de los procesos Gestión Comercial, Gestión
de Proyectos y Gestión de Facturación. Esta actualización incluye la configuración en el
sistema para la gestión de clientes, gestión de proyectos, generación de reportes de
seguimiento y avance de proyectos, y facturación.
GESTIÓN DE RIESGOS
Para identificar los factores de riesgo que pueden poner en peligro el desarrollo del proyecto
se emplea la matriz de probabilidad e impacto definida por el PMBOK.
Figura 8 – Matriz de Probabilidad e Impacto
Fuente: Guía del PMBOK
Donde las escalas para la probabilidad e impacto son:
Escala Relativa Probabilidad Escala Relativa Impacto
Nada probable 0.10 Muy bajo 0.05
Poco probable 0.30 Bajo 0.10
Medianamente probable 0.50 Moderado 0.20
Bastante probable 0.70 Alto 0.40
Muy probable 0.90 Muy alto 0.80
Tabla 2 – Escalas de Probabilidad e Impacto
Fuente: Guía del PMBOK
A continuación, se presenta la matriz de riesgos identificados para la implementación del
proyecto, donde la columna Resultado define la prioridad de atención de acuerdo a los
siguientes colores:
Figura 9 – Importancia de los Riesgos
Fuente: Guía del PMBOK
263
Matriz de riesgos
N° Riesgo Descripción Probabi. Impacto Resultado Estrategia de mitigación
1
No disponibilidad de
recursos al 100% para
el desarrollo del
proyecto.
Debido a que la integración es un proyecto interno
de la organización, la asignación de los consultores
podría verse afectada por la necesidad de su
participación en proyectos externos facturables.
Ello podría conllevar a una desviación de tiempos
estimados para el proyecto.
0.50 0.80 0.40
Proponer un esquema de
trabajo de doble turno para no
afectar los tiempos del plan de
proyecto.
2
Falta de
involucramiento de
usuarios clave.
Los usuarios clave son los gerentes de línea de
negocio, la PMO, la asistente contable, y la
asistente de recursos humanos, quienes muchas
veces debido a su carga laboral diaria no pueden
participar al 100% en las definiciones del proyecto.
0.50 0.80 0.40
Establecer cronogramas de
reuniones con los usuarios
clave de manera semanal o en
momentos donde la carga
laboral no sea tan exigente para
ellos.
3 Posibles problemas de
infraestructura.
El mantenimiento de los servidores de Oracle no
está a cargo del personal de TI de la organización
sino que se da de manera externa. Ello ocasiona que
algunas veces la atención de problemas con los
servidores no sea inmediata.
0.30 0.40 0.12
Implementar operaciones de
mantenimiento preventivo de
los servidores.
Matriz de riesgos
N° Riesgo Descripción Probabi. Impacto Resultado Estrategia de mitigación
4 Resistencia al cambio.
Actualmente, los Gerentes de Línea de Negocio
están habituados al manejo de sus tareas de manera
manual e independiente, por lo que se puede
presentar un malestar respecto a los nuevos
procedimientos a considerar en la integración de las
aplicaciones.
0.30 0.40 0.12
Concientizar a los Gerentes de
las Líneas de Negocio sobre la
importancia y los beneficios
que trae consigo la integración
de la información en una única
plataforma.
5
Definición incorrecta
del alcance del
proyecto.
Falta de compromiso o desconocimiento de algunas
tareas por parte de los involucrados al momento de
establecer las definiciones de los requerimientos del
proyecto.
0.30 0.40 0.12
Establecer reuniones de control
una vez por semana para
revisar los avances del
proyecto.
6
Rotación de los
usuarios clave del
proyecto.
Asignación de usuarios clave a actividades ajenas al
proyecto, que puedan generar retrasos en el plan de
trabajo, o conllevar a la definición errada de
requerimientos.
0.10 0.40 0.04
Coordinar con las áreas
correspondientes para asegurar
la participación ininterrumpida
de los usuarios clave.
Tabla 49 – Matriz de Riesgos
Fuente: Elaboración Propia
265
A nivel de Gestión de Servicios TI:
Se propone la aplicación del marco de trabajo planteado por ITIL para dar soporte al servicio
de Mantenimiento y Desarrollo de Software en la integración de las aplicaciones que
soportan los procesos de Gestión Comercial, Gestión de Proyectos y Gestión de Facturación.
La medición del servicio de Mantenimiento y Desarrollo de Software, durante la fase de
implementación, se llevará a cabo mediante el control del cumplimiento de las tareas
establecidas en el plan de trabajo del proyecto. Esta actividad se realizará semanalmente de
manera conjunta con el equipo de trabajo.
Posteriormente, en la etapa de soporte del proyecto se propone el uso de una Aplicación Web
para gestionar las incidencias presentadas. Dicha aplicación deberá permitir el análisis de las
siguientes métricas:
PROCESO DE MANTENIMIENTO Y DESARROLLO DE
SOFTWARE
Métrica 1: Respuesta de atención ante un requerimiento.
Descripción breve:
Esta métrica permite analizar qué tan eficiente es el servicio de atención de requerimientos
una vez que se ha ingresado su solicitud de atención. El tiempo máximo de respuesta de
atención estará en función de la prioridad de éstos:
Prioridad Tiempo máximo de respuesta
(A razón de 8 horas diarias)
Urgente 2 horas
Alto 16 horas
Medio 30 horas
Bajo 48 horas
Tabla 37 – Prioridad de Métrica 1 para Controlar Servicios
Fuente: Elaboración Propia
Urgente: Solicitud con un tiempo de atención crítico e importante que afectan o podrían
afectar la operación del sistema
Alto: Solicitud con un tiempo de atención importante que no afecta directamente la
operación del sistema pero es necesario para cerrar alguna transacción.
Medio: Solicitud con un tiempo de atención intermedio. Son los requerimientos generales
que normalmente no afectan a la operación del sistema.
Bajo: Solicitud con un tiempo de atención menor.
Objetivo de medición:
Medir la eficiencia del servicio en la atención de requerimientos.
Fuentes de información:
Para la medición del nivel de servicio prestado se tomará en cuenta la información del
Aplicativo Web utilizado para el registro de requerimientos. La medición se realizará en base
a todos los requerimientos registrados en el mes que se desee evaluar.
Fórmula:
Las presentes fórmulas son aplicables a los 4 niveles de prioridad establecidos:
Tiempo de Respuesta = (Fecha y Hora de fin de atención) - (Fecha y Hora registro del
requerimiento).
Posteriormente, se medirá el porcentaje de atención de requerimientos dentro del tiempo
establecido.
X(%) = (Cantidad de requerimientos atendidos dentro del tiempo establecido) / (Total de
requerimientos reportados)
Interpretación:
X = Porcentaje de cumplimiento del nivel de servicio.
Interpretación Rango de aceptación
Eficiente 95% <= X <= 100%
Normal 85% < X < 95%
Crítico X < 85%
Tabla 38 – Interpretación de Métrica 1 para Controlar Servicios
Fuente: Elaboración Propia
Métrica 2: Tiempo de corrección de incidentes reportados.
Descripción breve:
Esta métrica permite analizar el tiempo utilizado en la atención de un desarrollo y/o
configuración solicitada. El tiempo máximo de atención de errores estará en función de la
prioridad de estos:
Prioridad Tiempo máximo de respuesta
(A razón de 8 horas diarias)
Urgente 0.5 horas
Alto 4 horas
Medio 8 horas
Bajo 16 horas
Tabla 39 – Prioridad de Métrica 2 para Controlar Servicios
Fuente: Elaboración Propia
Objetivo de medición:
Medir la eficiencia del servicio en la atención de una solicitud de desarrollo y/o adecuación
de acuerdo al nivel de servicio acordado con el cliente.
Fuentes de información:
Para la medición del nivel de servicio prestado se tomará en cuenta la información del
Aplicativo Web utilizado para el registro de requerimientos. La medición se realizará en base
a todos los requerimientos registrados en el mes que se desee evaluar.
Fórmula:
Las presentes fórmulas son aplicables a los 4 niveles de prioridad establecidos:
Tiempo de Corrección = (Fecha y Hora de fin de corrección) - (Fecha y Hora de inicio de
corrección).
Posteriormente, se medirá el porcentaje de correcciones realizadas dentro del tiempo
establecido:
X(%) = (Cantidad de correcciones dentro de tiempo establecido) / (Total de solicitudes de
corrección reportadas)
Interpretación:
X = porcentaje de cumplimiento del nivel de servicio.
Interpretación Rango de aceptación
Eficiente 80% <= X <= 100%
Normal 70% < X < 80%
Crítico X < 70%
Tabla 40 – Interpretación de Métrica 2 para Controlar Servicios
Fuente: Elaboración Propia
La selección de la Aplicación Web para la gestión de los requerimientos se encuentra en
proceso de evaluación.
Además, se realizará la implementación de un repositorio central para la gestión de
documentación de los requerimientos. La herramienta a emplear será MS SharePoint.
PROCESO DE GESTIÓN DE CAMBIOS
ELEMENTOS DE CONFIGURACION SUJETOS A CAMBIOS
Los elementos de configuración constituyen cualquier producto cuyo cambio pueda resultar
crítico para el desarrollo del proyecto. Además, no solo se deben tomar en cuenta los
productos finales que se entregan al cliente como el mantenimiento y desarrollo de software,
sino también productos que son elaborados a lo largo del desarrollo del proyecto como lo es
la documentación.
Los elementos de configuración cuyos cambios son gestionados a través de este proceso son:
Business Blue Print.
Requerimientos de desarrollo de software (RFC).
Diseño de prototipos.
Código fuente.
Plan de pruebas.
Informe de cierre de proyecto.
PROCESO DETALLADO
A continuación, se presenta el diagrama genérico del proceso de gestión de cambios que
aplica a la propuesta de integración.
271
Figura 20 – Diagrama de Flujo Detallado del Proceso de Gestión de Cambios
Fuente: Elaboración Propia
272
HERRAMIENTAS Y PLANTILLAS
Herramientas
Actualmente, no se cuenta con una herramienta que permita el ingreso de solicitudes de
cambio. No obstante, se propone el uso de una aplicación centralizada para cumplir con este
cometido.
1. Aplicación Web: Permite el ingreso y actualización continua de las solicitudes de cambio.
De esta manera, el rol interesado puede darle seguimiento en línea a la situación de cada
solicitud de cambio.
Plantillas
1. Formato de RFC: Cada solicitud de cambios notificada se describe y detalla debidamente
en un documento llamado Request For Change (RFC). Ver anexo 3.
METRICAS PARA CONTROLAR EL SERVICIO
Métrica 1: Porcentaje de RFCs registrados que hayan sido atendidos fuera del tiempo
estimado.
Descripción breve:
Permite medir el porcentaje de solicitudes de cambio que no han sido atendidas dentro de los
tiempos estimados.
Objetivo de medición:
Identificar las solicitudes de cambio que han excedido el tiempo estimado de implementación
para un determinado periodo de tiempo.
Fuentes de información:
De lo registrado en la Aplicación Web se toman los siguientes datos:
Todos los RFCs cuya fecha de cierre se encuentre fuera de la fecha límite estimada.
Se obtienen los elementos de configuración, el motivo del desfase de tiempos, el tipo de
impacto y riesgos considerados.
Fórmula:
X(%) =
__Cantidad de RFCs cerrados fuera de fecha__
Cantidad de RFC registradas
Interpretación:
X = Porcentaje de RFCs y cerrados fuera de fecha.
Interpretación Rango de aceptación
Normal 0% <= x <= 10%
Observado 10% < x <= 25%
Crítico x < 25%
Tabla 47 – Interpretación de Métrica 1 para controlar el Servicio – Control de Cambio
Fuente: Elaboración Propia
PROCESO DE PRUEBA DEL SERVICIO
En la siguiente sección describiremos el proceso de realización de pruebas tanto para
requerimientos funcionales como técnicos.
Objetivos de la prueba
Validar que la atención de los requerimientos cubra cada uno de los puntos detallados por
el usuario.
Validar que las adecuaciones realizadas no interfieran con funcionalidades ya existentes.
Minimizar el número de incidentes que se producen en el ambiente de Producción.
Pre-requisitos para la realización de la prueba
Los casos de prueba deben acompañar el requerimiento alcanzado por el usuario.
Se debe contar con datos en el ambiente de Desarrollo y/o Calidad, dependiendo del
ambiente destinado por el cliente, para la realización de las pruebas unitarias.
Características del ambiente de pruebas
Para la realización de pruebas de los requerimientos atendidos es necesario contar con
ambientes que garanticen la correcta ejecución de:
Pruebas Unitarias: Realizadas por el Consultor Senior y/o Desarrollador en función de los
casos de prueba alcanzados como parte del requerimiento a atender.
Pruebas de Integración: Realizadas por el Consultor Senior y/o Desarrollador cuando la
atención del requerimiento pueda afectar a funcionalidades ya existentes o se vea
comprometida la integración de otros módulos.
Pruebas de Sistemas: Realizadas por el usuario con datos similares a los del ambiente de
Producción.
Pruebas de Aceptación: Realizadas por el usuario para dar la conformidad de lo realizado.
Se debe tener en cuenta que la realización de estas pruebas se debe realizar dentro de un
ambiente con datos y escenarios de prueba tan iguales a los del ambiente Productivo. La
asignación de servidores estará en función del landscape del cliente.
Proceso Detallado
En este proceso participan los roles de:
Tester, que es la persona encargada de realizar atender el requerimiento y llevar a cabo la
realización de pruebas unitarias. Esta persona puede ser el Consultor Senior o el
Desarrollador.
Usuario, que es la persona encargada de realizar las pruebas de aceptación de lo realizado.
Figura 21 – Diagrama de Flujo Detallado del Proceso de Prueba del Servicio
Fuente: Elaboración Propia
HERRAMIENTAS Y PLANTILLAS:
Herramientas:
1. Para el manejo centralizado de la documentación de pruebas se utilizará Microsoft
SharePoint.
Plantillas:
1. Los requerimientos, además de ser registrados dentro de la Aplicación Web destinada
para dicho fin, se deberán de especificar dentro del formato establecido por el objeto de
estudio. Este formato es establecido dentro de la sección de Anexos.
2. Scripts de pruebas.
MÉTRICAS PARA CONTROLAR EL SERVICIO:
Métrica 1: Número de rechazos por pruebas integrales.
Descripción breve:
Esta métrica permite analizar la calidad del servicio entregado al cliente y que tan minuciosas
son las tareas de análisis y pruebas de parte del equipo de Mantenimiento y desarrollo de
software. La medición se realizará desglosando la información de los requerimientos por
módulo SAP y nivel de prioridad.
Objetivo de medición:
Medir la eficiencia del servicio de atención de requerimientos.
Fuentes de información:
Para el análisis de la métrica se tomará en cuenta la información del Aplicativo Web utilizado
para el registro de requerimientos. La medición se realizará en base a todos los
requerimientos registrados en el mes que se desee evaluar.
Fórmula:
La presente fórmula es aplicable a todos los módulos de SAP y a los 4 niveles de prioridad
establecidos (Urgente, Alto, Medio y Bajo):
X = número de rechazos registrados / número de requerimientos alcanzados
Interpretación:
X = Promedio de rechazos registrados.
Nivel de Prioridad
Interpretación Urgente Alto Medio Bajo
Eficiente X = 0 X <= 1 X <= 2 X <= 4
Normal X = 0 X = 2 2 < X <= 4 X = 5
Crítico X >= 1 X > 2 X > 4 X > 5
Tabla 48 – Nivel de Prioridad de Métrica 1: Número de rechazos por pruebas integrales
Fuente: Elaboración Propia
COSTOS Y RECURSOS REQUERIDOS
El costo aproximado de la implementación del proyecto de integración de Oracle EBS sería
de S/. 120,000.00 en un periodo de trabajo de 7 meses.
Además, la cantidad de recursos requeridos para llevarlo a cabo se detalla en el siguiente
cuadro:
Recurso Cantidad
Jefe de Proyecto 1
Consultor Senior
1 CRM
1 Finanzas y Compras
1 Recurso Humano
Desarrollador 2
Tabla 82 – Recursos Requeridos para Implementación de Propuesta
Fuente: Elaboración Propia
A nivel de Recurso Profesional
Se propone la realización de una implementación incremental enfocada a la Línea de Negocio
de Service Management Oracle, encargada de llevar a cabo la integración de las aplicaciones
que soportan los procesos de Gestión Comercial, Gestión de Proyectos y Gestión de
Facturación. Se debe tener en cuenta que en el capítulo 2 del presente documento se realizó el
análisis sobre los roles manejados para el proceso de Mantenimiento y Desarrollo de
Software de la Unidad de Negocio SAP aplicando el estándar PSP y TSP. El mismo análisis
será desarrollado para los roles involucrados en la Línea de Negocio de Service Management
Oracle, que son los mismos de la Unidad de Negocio SAP.
A continuación se muestra la propuesta de implementación del marco de trabajo de P-CMM,
dividido en 5 fases:
Figura 45 – Modelo de Implementación de P-CMM
Fuente: Elaboración Propia
Fase 0: Fase inicial que cuenta con las siguientes actividades:
Buscar el apoyo de la Alta Gerencia: Dar a conocer la necesidad de mejora del recurso
humano empleando las mejores prácticas de P-CMM, y realizar una presentación del plan
piloto a llevarse a cabo sobre una Línea de Negocio específica.
Establecer conciencia sobre la necesidad de mejora: Difundir al personal de la
organización sobre la propuesta presentada a la Alta Gerencia con relación al plan de
desarrollo de capacidades y competencias.
Diseñar plan de implementación:
- Identificar los roles dentro de la Línea de Negocio seleccionada para el piloto de la
implementación.
- Identificar a un representante de dicha Línea de Negocio que se encargue de
comunicar la situación actual y problemática del personal.
- Definir formatos para la evaluación de competencias del personal tanto a nivel interno
(dentro de la organización) como externo (de parte del cliente).
- Establecer métricas, periodicidad de evaluaciones, y el formato de presentación de
resultados.
Fase 1: Fase de análisis del personal que cuenta con las siguientes actividades:
Definir perfiles: Identificar las habilidades blandas, duras, inteligencias, y determinar el
nivel requerido dentro de la taxonomía de Bloom para cada uno de roles en la Línea de
Negocio seleccionada.
Realizar análisis de brechas: Verificar los gaps entre las capacidades actuales del personal
y los perfiles definidos previamente.
Presentar informe de resultados: Elaborar y dar a conocer los resultados del análisis
realizado al personal de la Línea de Negocio a la Alta Gerencia.
Comunicar resultados al personal: Dar a conocer los resultados del análisis realizado al
personal evaluado de la Línea de Negocio para generar conciencia de mejora y
participación en el proceso de desarrollo de capacidades.
Fase 2: Fase de desarrollo de capacidades que cuenta con las siguientes actividades:
Definir plan de desarrollo de capacidades: De acuerdo al análisis realizado se elabora un
plan para promover el desarrollo de capacidades que requiere el personal.
Ejecución de plan de desarrollo de capacidades: Puesta en marcha del plan definido
previamente.
Fase 3: Fase de evaluación que cuenta con las siguientes actividades:
Realizar evaluación continua del personal: Dar seguimiento al cumplimiento de las
prácticas establecidas para el desarrollo de capacidades.
Aplicar métricas: Analizar los indicadores establecidos para la medición del desarrollo
del personal. Por ejemplo:
Tiempo de respuesta de atención ante un requerimiento.
Tiempo de corrección de incidentes reportados.
Porcentaje de RFCs atendidos fuera del tiempo estimado.
Número de rechazos por prioridad en periodo de pruebas.
Elaborar y comunicar resultados: Dar a conocer los resultados obtenidos a la Alta
Gerencia y al personal de la Línea de Negocio evaluada.
Fase 4: Fase de implementación que cuenta con la siguiente actividad:
Implementar áreas de proceso y prácticas: Identificar las áreas de proceso y selección de
prácticas a implementar en la Línea de Negocio.
A continuación, se presentan el conjunto de habilidades blandas y duras, inteligencias y el
nivel dentro de la Taxonomía de Bloom requerido para cada rol de la Línea de Negocio de
Service Management Oracle, indicando el grado de dominio esperado para cada uno de estos.
Habilidades Blandas:
Habilidades Blandas Jefe de
Proyecto
Consultor
Senior Desarrollador
Comunicación Asertiva 3 3 2
Determinación de metas 3 2 2
Escucha activa 3 3 3
Respeto a las opiniones 3 3 3
Sociabilidad 3 3 2
Empatía 3 3 2
Trabajo en equipo 3 3 3
Capacidad para resolver problemas 3 3 2
Proactividad 3 3 3
Capacidad de redacción 3 3 3
Capacidad de análisis 3 3 3
Seguridad Personal 3 3 2
Tolerancia a la presión 3 2 2
Orden 3 3 3
Liderazgo 3 3 2
(Leyenda: 1 = Básico, 2 = Intermedio, 3 = Avanzado)
Tabla 13 – Matriz de Habilidades Blandas vs. Roles
Fuente: Elaboración propia
Habilidades Duras:
Habilidades Duras Jefe de
Proyecto
Consultor
Senior Desarrollador
Organización y Planificación 3 2 1
Desarrollo de Personas 3 2 1
Habilidades Duras Jefe de
Proyecto
Consultor
Senior Desarrollador
Negociación y Habilidades Comerciales 3 2 1
Dirección de equipos de trabajo 3 2 1
Pensamiento Analítico 3 2 2
Diagnóstico 3 3 2
Diseño 2 3 3
Implementación 3 2 2
(Leyenda: 1 = Básico, 2 = Intermedio, 3 = Avanzado)
Tabla 14 – Matriz de Habilidades Duras vs. Roles
Fuente: Elaboración propia
Inteligencias:
Inteligencias Jefe de
Proyecto
Consultor
Senior Desarrollador
Social 3 3 2
Verbal 3 3 2
Personal 3 3 3
Creativa 2 3 2
(Leyenda: 1 = Básico, 2 = Intermedio, 3 = Avanzado)
Tabla 15 – Matriz de Inteligencias vs Roles
Fuente: Elaboración propia
Nivel requerido de acuerdo a la Taxonomía de Bloom:
En los siguientes cuadros se presenta, de acuerdo a los niveles de la Taxonomía de Bloom,
cada una de las condiciones que se deben cumplir para los roles identificados:
285
Jefe de Proyectos:
Nivel Descripción de Actividades Habilidades Blandas
Conocimiento Experiencia en Gestión de Proyectos y Gestión de Personal.
Comunicación Asertiva.
Determinación de metas.
Escucha activa.
Sociabilidad.
Empatía.
Respeto a las opiniones.
Trabajo en equipo.
Capacidad para resolver
problemas.
Capacidad de análisis.
Liderazgo.
Comprensión
Creación de condiciones adecuadas para un trabajo eficiente de equipo, con la finalidad
de alcanzar los objetivos y mantener una eficiente comunicación a todos los niveles.
Analiza y planea la ejecución de proyectos estableciendo metas de cumplimiento en
concordancia con los objetivos generales de los mismos.
Identifica y programa la adquisición de nuevo personal, bienes y/o servicios necesarios
Comunicación Asertiva.
Determinación de metas.
Capacidad de análisis.
Capacidad para resolver
problemas.
Nivel Descripción de Actividades Habilidades Blandas
para el desarrollo del proyecto.
Identifica riesgos que puedan complicar la correcta ejecución de los proyectos.
Establecer métodos, técnicas y herramientas a utilizar por el equipo del proyecto.
Definir perfiles para que el equipo del proyecto y las responsabilidades de cada uno.
Definir métricas para medición de rendimiento de proyectos y miembros del equipo.
Aplicación
Selección de personal basado en análisis de habilidades y competencias.
Administración eficiente de recursos humanos, materiales y presupuestos asignados al
proyecto.
Aplicación de metodología ASAP para la implementación de proyectos.
Mitigación de riesgos mediante aplicación de planes definidos de acuerdo al tipo de
vulnerabilidad.
Proactividad.
Capacidad de análisis.
Seguridad Personal.
Tolerancia a la presión.
Liderazgo.
Análisis
Identificación y análisis de puntos críticos en el desarrollo de cada fase del proyecto.
Identificación y análisis de causas de retraso en los proyectos y las alternativas de
solución a aplicar para ello.
Evaluación de factores internos y externos que puedan desestabilizar la armonía del
equipo de trabajo.
Escucha activa.
Capacidad para resolver
problemas.
Capacidad de análisis.
Orden.
Síntesis Formulación de propuestas de mejora, basado en lecciones aprendidas, para afinar la
calidad del servicio de consultoría y el proceso de desarrollo de proyectos.
Capacidad de redacción.
Orden.
Nivel Descripción de Actividades Habilidades Blandas
Evaluación
Evaluación de metodologías y tecnologías que soporten las propuestas de mejora
planteadas.
Evaluación de métricas de rendimiento de proyectos y personal.
Capacidad de análisis.
Orden.
Tabla 16 – Actividades del Jefe de Proyecto por Nivel de la Taxonomía de Bloom
Fuente: Elaboración propia
De no alcanzarse el nivel de Evaluación dentro de la Taxonomía de Bloom, se debería iterar al nivel de Análisis, ya que este nivel proporciona la
base para la definición de propuestas de mejora y evaluación de métricas. Asimismo, se deberán reforzar las habilidades blandas asociadas a
dicho nivel.
Consultor Senior:
Nivel Descripción de Actividades Habilidades Blandas
Conocimiento
Experiencia de nivel funcional en los módulos de SAP y/o conocimiento avanzado de su
lenguaje de programación ABAP.
Capacidad para gestión de proyectos y personal.
Comunicación Asertiva.
Escucha activa.
Sociabilidad.
Empatía.
Respeto a las opiniones.
Trabajo en equipo.
Capacidad para resolver
problemas.
Capacidad de análisis.
Liderazgo.
Comprensión
Planteamiento de soluciones que permitan satisfacer los requerimientos recibidos del
cliente.
Elaboración de plan para el seguimiento de atención de los requerimientos.
Definir la arquitectura de hardware y software, componentes, módulos y datos para
satisfacer los requerimientos del proyecto.
Comunicación Asertiva.
Capacidad para resolver
problemas.
Capacidad de análisis.
Orden.
Aplicación Atención de requerimientos de acuerdo a lo planificado.
Coordinación y ejecución de acciones en apoyo a la gestión de proyectos.
Proactividad.
Capacidad de análisis.
Nivel Descripción de Actividades Habilidades Blandas
Seguridad Personal.
Tolerancia a la presión.
Liderazgo.
Análisis
Identificación de alternativas de solución a problemáticas encontradas en el relevamiento
de procesos, evaluando la factibilidad de su aplicación.
Inspección y detección de errores en entregables.
Investigación de nuevas tendencias tecnológicas que permitan incrementar el valor de los
entregables y la calidad del servicio.
Análisis de propuestas de mejora del equipo de trabajo.
Escucha activa.
Capacidad para resolver
problemas.
Capacidad de análisis.
Síntesis
Elaboración de plan de mejoras continuas adaptable al proceso de mantenimiento de
software.
Establecer un registro de lecciones aprendidas que permita identificar futuros problemas
en el desarrollo del proceso de mantenimiento de software.
Capacidad de redacción.
Orden.
Evaluación Descripción del plan de mejoras continúa con los Jefes de Proyecto argumentando
ventajas de su implementación.
Capacidad de análisis.
Orden.
Tabla 17 – Actividades del Consultor Senior por Nivel de la Taxonomía de Bloom
Fuente: Elaboración propia
De no alcanzarse el nivel de Evaluación dentro de la Taxonomía de Bloom, se debería iterar al nivel de Análisis, ya que este nivel permite
identificar opciones de mejora en función de las lecciones aprendidas en el desarrollo de los proyectos. Asimismo, se deberán reforzar las
habilidades blandas asociadas a dicho nivel.
Desarrollador:
Nivel Descripción de Actividades Habilidades Blandas
Conocimiento Conocimiento del lenguaje de programación ABAP y mejores prácticas de
programación.
Comunicación Asertiva.
Escucha activa.
Respeto a las opiniones.
Trabajo en equipo.
Capacidad para resolver
problemas.
Capacidad de análisis.
Comprensión Planteamiento de soluciones aplicables a los requerimientos asignados.
Capacidad para resolver
problemas.
Capacidad de análisis.
Orden.
Nivel Descripción de Actividades Habilidades Blandas
Aplicación
Atención de requerimientos de acuerdo a lo planificado de acuerdo a los estándares
manejados por la organización.
Elaboración de documentación de calidad que soporte el desarrollo realizado para cubrir
la atención de los requerimientos.
Proactividad.
Capacidad de análisis.
Tolerancia a la presión.
Análisis
Identificación de alternativas de solución a problemáticas encontradas en el relevamiento
de procesos, evaluando la factibilidad de su aplicación.
Análisis de performance y oportunidades de mejora en desarrollos propios y/o del
cliente.
Escucha activa.
Capacidad para resolver
problemas.
Capacidad de análisis.
Síntesis Elaboración de propuestas que permitan mejorar la calidad de los entregables. Capacidad de redacción.
Orden.
Evaluación No requerido
Tabla 18 – Actividades del Desarrollador por Nivel de la Taxonomía de Bloom
Fuente: Elaboración propia
292
De no alcanzarse el nivel de Síntesis dentro de la Taxonomía de Bloom, se debería iterar al
nivel de Comprensión con la finalidad de entender de manera adecuada la problemática
planteada por el cliente, y redefinir la solución a aplicar. Asimismo, se deberán reforzar las
habilidades blandas asociadas a dicho nivel.
La decisión de realizar la implementación de manera incremental permitirá realizar un
seguimiento más detallado del desempeño del personal involucrado, facilitando la
identificación y aplicación de ajustes que ayuden a garantizar el éxito de la implementación.
De esta manera, se asegura de que al replicar el modelo en las otras Líneas de Negocio, se
optimice el tiempo de implementación y se obtengan resultados positivos.
Evaluación de Habilidades Blandas
Para la evaluación de las habilidades blandas se llevarán a cabo las siguientes actividades:
Para el personal que postula:
Se solicitarán referencias de trabajos previos de manera que se cuente con una visión
general del postulante.
Se aplicarán evaluaciones de simulación de casos y juego de roles para identificar
fortalezas y debilidades.
Para el personal actual:
Se solicitarán evaluaciones de desempeño a los clientes donde han sido asignados. La
periodicidad de dichas evaluaciones dependerá de la duración de su participación en los
proyectos del cliente.
Se solicitarán evaluaciones de desempeño a los jefes inmediatos superiores. La
periodicidad de dichas evaluaciones será semestral.
Evaluación de Habilidades Duras
Para la evaluación de las habilidades duras se llevarán a cabo las siguientes actividades:
Para el personal que postula:
Se realizarán evaluaciones de conocimiento de acuerdo al perfil requerido por la
organización.
Para el personal actual:
Se realizarán evaluaciones de acuerdo a las métricas definidas para el proceso de
Mantenimiento y Desarrollo de Software, y Gestión de Cambios:
- Respuesta de atención ante un requerimiento.
- Tiempo de corrección de incidentes reportados.
- Porcentaje de RFCs registrados que hayan sido atendidos fuera del tiempo estimado.
GESTIÓN DE RIESGOS
Los principales elementos de riesgo identificados son:
294
Matriz de Elementos de Riesgo
N° Elemento de Riesgo Probab. Impacto Resultado Estrategia de mitigación
1 Falta de soporte gerencial 0.50 0.40 0.20 Concientizar a la gerencia sobre la necesidad de mejorar el desempeño laboral mediante
la implementación de un modelo de madurez de capacidades del personal.
2 Desconocimiento de la
problemática laboral 0.30 0.40 0.12
Formar un comité, con la participación de un representante de cada unidad de la
organización, para identificar y evaluar los problemas de la fuerza de trabajo.
3 Conformismos con el nivel de
madurez 3 - Definido 0.30 0.40 0.12
Evaluar de manera continua las competencias del personal para verificar el
cumplimiento de las prácticas de dicho nivel.
4 Fiebre del nivel de madurez 0.50 0.40 0.20 Revisar el propósito, objetivos, prácticas y compromisos de un nivel de madurez para
determinar si se cumplen. Caso contrario, no se puede aspirar a dicho nivel.
5 Salto de nivel de madurez 0.30 0.40 0.12 Evidenciar el cumplimiento de todos los requisitos de un determinado nivel de madurez
antes de pasar al siguiente.
6 Descarte de áreas de proceso 0.70 0.40 0.28 Mejorar la implementación de las áreas de proceso de manera que se evalúen a detalle
antes de tomar una decisión precipitada.
7
Implementación de prácticas
obviando la secuencia del
nivel de madurez
0.70 0.40 0.28 Respetar el orden de implementación de las prácticas de acuerdo al nivel de madurez de
la organización.
Tabla 3 – Matriz de Elementos de Riesgo del Nivel de Madurez
Fuente: Elaboración propia
295
Finalmente, uno de los objetivos de la propuesta planteada es asegurar el nivel de madurez
alcanzado en la organización, ya que por el tamaño de la misma no se justifica un salto de
nivel, por el momento. Esto se debe, básicamente, a que para realizar el avance de nivel se
requiere de un compromiso de tiempos y presupuesto que por el momento está destinado a
otras actividades.
CONCLUSIONES
1. La aplicación de cada uno de los estándares revisados no se puede dar en su totalidad, en
su lugar se deben seleccionar las mejores prácticas de cada uno de ellos que mejor se
ajusten a la realidad de la organización.
2. El apoyo de la Alta Gerencia constituye el más importante de los pilares para la
evaluación e implementación de la solución.
3. El mayor activo de la organización es el recurso humano; por lo tanto, es de suma
importancia la participación y el compromiso del personal de la organización en el
desarrollo de la solución propuesta.
4. Es necesario mantener una evaluación constante de cada uno de los aspectos envueltos en
la solución para identificar posibles situaciones que pongan en riesgo el cumplimiento de
los objetivos planteados.
5. Se deben definir hitos en la implementación de la solución que permitan mantener
informados a la Alta Gerencia y al personal de la organización sobre el desarrollo de la
misma.
CONCLUSIONES
1. Se ha logrado establecer una matriz que permite identificar los componentes del área de
TI que participan en los procesos estratégicos de la organización bajo los lineamientos de
Arquitectura Empresarial. Esto permitirá garantizar la trazabilidad de dichos componentes
y facilitará las tareas de mejora de los procesos con un mayor control de los riesgos
asociados. De esta manera se cumple con lo indicado en los objetivos específicos OE1 y
OE2.
2. Se ha elaborado una propuesta de Arquitectura Empresarial basado en el análisis de
GAPS existentes entre la situación actual de la organización y la situación objetivo a la
que se espera llegar. Dicha propuesta abarca procesos estratégicos, proceso de
mantenimiento y desarrollo de software y recurso humano. De esta manera se cumple con
lo indicado en el objetivo específico OE3.
3. Se ha logrado redefinir el proceso de Mantenimiento y Desarrollo de Software en base a
la inclusión de una aplicación que apoye en la gestión de los requerimientos reportados
por los clientes. De esta manera, además, se contará con métricas en tiempo real que
permitan controlar la calidad del servicio que se está brindando. De esta manera se
cumple con lo indicado en los objetivos específicos OE4 y OE5.
4. Bajo las prácticas sugeridas por el estándar P-CMM se ha conseguido redefinir los
perfiles del personal requerido para cubrir el proceso de Mantenimiento y Desarrollo de
Software, permitiendo elevar la calidad del proceso y reorientar esfuerzos en mejorar las
capacidades del personal. De esta manera se cumple con lo indicado en los objetivos
específicos OE6.
5. Se ha conseguido la aprobación de la Alta Gerencia para llevar a cabo un proyecto piloto
para el desarrollo y seguimiento de las capacidades del personal según lo indicado por el
estándar PSP y TSP. Se tomará en cuenta, además, a las métricas definidas en el proceso
de Mantenimiento y Desarrollo de Software como fuente de información para medición
de desempeño. De esta manera se cumple con lo indicado en los objetivos específicos
OE7 y OE8.
6. Se ha conseguido elaborar una propuesta de trabajo que rescata las mejores prácticas de
cada uno de los estándares revisados en el desarrollo del proyecto: P-CMM, ITIL y
TOGAF, con la finalidad de armar un marco de trabajo que se ajuste a la realidad de la
organización y que soporte el proceso de Mantenimiento y Desarrollo de Software
aplicable a los procesos estratégicos definidos en el análisis de Arquitectura Empresarial.
RECOMENDACIONES
1. Concientizar a la Alta Gerencia sobre la importancia de contar con una Arquitectura
Empresarial que permita el alineamiento de los procesos de negocio con los objetivos de
la organización. Actualmente, la gerencia de TSNET S.A. se encuentra interesada en la
implementación de la presente propuesta de solución que le permitirá mejorar sus
procesos de negocio soportados en tecnología de información.
2. Revisar y rediseñar, de ser necesario, el portafolio de servicios de TI ya que conforman la
carta de presentación hacia los clientes. Y si adicionalmente a ello no se cuenta con un
plan de capacidades bien definido o no se sabe llevar de manera adecuada una gestión del
cambio no se alcanzará el nivel esperado de satisfacción del cliente.
3. Evaluar las ventajas y desventajas de los diversos estándares o marcos de trabajo para los
diferentes propósitos de la organización: Recurso Profesional, Servicios en TI o
Arquitectura Empresarial ya que se debe tener en consideración que no necesariamente se
deben implementar en su totalidad. En su defecto, se deben tomar las mejores prácticas y
alineamientos que se ajusten a la realidad de la organización.
GLOSARIO DE TÉRMINOS
1. Framework: Marco de referencia conformado por componentes que actúan como base
para la estructuración y ensamble de componentes en construcciones más complejas.
2. PLE: Aplicativo desarrollado por la SUNAT que se instala en la computadora del
contribuyente y le permite generar el Libro Electrónico en el Sistema de Libros
Electrónicos SLE–PLE y obtener la constancia de recepción respectiva.
3. Stakeholder: Todo aquel que puede afectar o ser afectado por las actividades de los
procesos de negocio de una organización.
SIGLARIO
ADM: Architecture Development Method.
AE: Arquitectura Empresarial.
EBS: E-Business Suite.
IDEAL: Inicialización, Diagnóstico, Establecimiento, Acción, Levantamiento.
ITIL: Information Technologies Infraestructure Library.
LAP: Lima Airport Partners.
P-CMM: Personal Capability Maturity Model.
PEE: Plan Estratégico Empresarial.
PETI: Plan Estratégico de Tecnología de Información.
PLE: Programa de Libros Electrónicos.
PMBOK: Project Management Body Of Knowledge.
PSP: Personal Software Process.
RFC: Request For Change.
SAP: System, Applications and Products.
SEI: Software Engineering Institute.
SLA: Service Level Agreement.
SLE: Sistema de Libros Electrónicos.
SUNAT: Superintendencia Nacional de Aduanas y de Administración Tributaria.
TI: Tecnología de la Información.
TOGAF: The Open Group Architecture Framework.
TSP: Team Software Process.
UAT: User Acceptance Testing.
BIBLIOGRAFÍA
HUMPHREY Watts S. (2000) The Personal Software ProcessSM
(PSPSM
)
DAVIS Noopur. MULLANEY Julia (2003) The Team Software ProcessSM
(TSPSM
) in
Practice: A Summary of Recent Results
CURTIS Bill. HEFLEY William E. MILLER Sally A (2001) People Capability Maturity
Model®
(P-CMM®
) Versión 2.0
Diccionario de Competencias TSNET (2007) Documento del objeto de estudio TSNET S.A.
en el cual se describen las competencias del personal a nivel organizacional, gerencial,
funcional y técnico.
MOF: Manual Organizacional de Funciones (2007) Documento de gestión del objeto de
estudio TSNET S.A. en el cual se describen las funciones específicas de cada rol de la
organización.
Project Management Institute (2013). Guía de los fundamentos para la dirección de proyectos
(Guía del PMBOK) - Quinta Edición
TOGAF® Version 9.1, an Open Group Standard (2015)
(http://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html) Sitio web oficial;
contiene la información detallada del marco de trabajo TOGAF (Consulta 9 de diciembre).
Microsoft Dynamics CRM (2015) (http://www.microsoft.com/es-pe/dynamics/CRM.aspx)
Sitio web oficial; contiene la información detallada de la solución (Consulta 12 de
diciembre).
Oracle E-Business Projects (2015)
(http://www.oracle.com/us/products/applications/ebusiness/projects/053961.html) Sitio web
oficial; contiene información detallada de la solución (Consulta 12 de diciembre).
ANEXOS
ANEXO 1: FORMATO TÉCNICO-FUNCIONAL
ANEXO 2: FORMATO DE SCRIPTS DE PRUEBAS
ANEXO 3: FORMATO DE MANUAL DE USUARIO
ANEXO 4: FORMATO acta de aceptación del servicio
ANEXO 5: FORMATO DE REPORTE DE INCIDENCIA