proceso de integraciÓn de una filial latinoamericana de …biblio.upmx.mx/tesis/147124.pdf ·...
TRANSCRIPT
“PROCESO DE INTEGRACIÓN DE UNA FILIAL
LATINOAMERICANA DE UN CORPORATIVO
BANCARIO ESPAÑOL MEDIANTE UN SISTEMA DE
GESTIÓN DE RECURSOS HUMANOS BASADO EN
LA APLICACIÓN PEOPLESOFT”
T E S I S
QUE PARA OBTENER EL TÍTULO DE
LICENCIADO EN INGENIERÍA INDUSTRIAL
P R E S E N T A
JUAN ALEJANDRO RODRÍGUEZ JIMÉNEZ
DIRECTOR DE TESIS:
DR. FRANCISCO ORTÍZ ARANGO
MÉXICO, D.F., 2014
Dedicatoria
A mis padres Irma y Juan.
Agradecimientos
A Marisol quién, desde el primer año de carrera, me ha ofrecido su amistad, su cariño, su sabiduría y su paciencia que han logrado hacer de mí una mejor persona y que, aún después de dieciocho años juntos, lo siga haciendo para construir nuestro proyecto de vida conjunta. A mi hermano Iván y a mi hermana Daniela por haberme soportado durante esos años. A Paco Ortíz por haberme ayudado a completar este hito. A mis compañeros y profesores de facultad. A Rodrigo Martínez por haberme alentado a cumplir mi sueño de entrar a esta universidad. A Francisco Quezada por su amistad y apoyo durante mis años de bachillerato, que fueron clave para mi formación espiritual y académica.
Índice
RESUMEN ...................................................................................................................................................... 1
INTRODUCCIÓN............................................................................................................................................ 2
A. OBJETIVO .......................................................................................................................................... 2 B. ESTRUCTURA DE LA TESIS ................................................................................................................... 2
CAPÍTULO 1. LA APLICACIÓN. ............................................................................................................. 5
1.1. INTRODUCCIÓN .................................................................................................................................. 5 1.2. SISTEMAS ERP (ENTERPRISE RESOURCE PLANNING) .......................................................................... 5
1.2.1. Definición .................................................................................................................................. 5 1.2.2. Historia ...................................................................................................................................... 7
1.3. PRODUCTOS DEL MERCADO..............................................................................................................10 1.3.1. SAP R/3 ..................................................................................................................................10 1.3.2. PeopleSoft (PS) ......................................................................................................................12 1.3.3. Oracle e-business Suite (EBS) ...............................................................................................13 1.3.4. J. D. Edwards (JDE) ...............................................................................................................14 1.3.5. Otros Sistemas .......................................................................................................................15
1.4. METODOLOGÍA .................................................................................................................................17 1.4.1. Gestión de la Iniciativa............................................................................................................17 1.4.2. Desarrollo del Producto ..........................................................................................................18 1.4.3. Gestión ...................................................................................................................................19
1.5. SISTEMAS DE GESTIÓN DE RECURSOS HUMANOS ..............................................................................19 1.5.1. HR Access ..............................................................................................................................25 1.5.2. Meta 4 .....................................................................................................................................27 1.5.3. SAP RH ..................................................................................................................................28
1.6. PEOPLESOFT ...................................................................................................................................30 1.6.1. Descripción .............................................................................................................................30 1.6.2. Ventajas ..................................................................................................................................31 1.6.3. Desventajas ............................................................................................................................33
1.7. ESTADÍSTICAS ..................................................................................................................................33
CAPÍTULO 2. EMPRESA OBJETIVO: CORPORATIVO BANCARIO ..................................................35
2.1. INTRODUCCIÓN ................................................................................................................................35 2.2. ¿POR QUÉ UN CORPORATIVO BANCARIO? .........................................................................................35 2.3. INFORMATIZACIÓN DE LOS PROCESOS ...............................................................................................36 2.4. PRESENCIA EN LATINOAMÉRICA ........................................................................................................37 2.5. IMPORTANCIA DE LA EXPANSIÓN ........................................................................................................38 2.6. ÁREA DE RECURSOS HUMANOS ........................................................................................................40
CAPÍTULO 3. GESTIÓN DEL PROYECTO ...........................................................................................42
3.1. INTRODUCCIÓN ................................................................................................................................42 3.2. GESTIÓN DE INTEGRACIÓN DEL PROYECTO ........................................................................................43
3.2.1. Desarrollo del Plan del Proyecto ............................................................................................43 3.2.2. Ejecución del Plan del Proyecto .............................................................................................45 3.2.3. Control Integrado de los Cambios ..........................................................................................48
3.3. GESTIÓN DEL ALCANCE DEL PROYECTO ............................................................................................49 3.3.1. Inicio .......................................................................................................................................50 3.3.2. Planificación del Alcance ........................................................................................................51 3.3.3. Definición del Alcance ............................................................................................................52 3.3.4. Verificación del Alcance .........................................................................................................53 3.3.5. Control de Cambios del Alcance ............................................................................................54
3.4. GESTIÓN DE TIEMPOS DE PROYECTO ................................................................................................55 3.4.1. Definición de las Actividades ..................................................................................................55 3.4.2. Definición de la Secuencia de Actividades .............................................................................56
3.4.3. Estimación de la Duración de las Actividades ........................................................................58 3.4.4. Desarrollo del Calendario .......................................................................................................60 3.4.5. Control del Calendario ............................................................................................................64
3.5. GESTIÓN DE COSTOS DEL PROYECTO ...............................................................................................65 3.5.1. Planificación de Recursos ......................................................................................................65 3.5.2. Estimación de Costos .............................................................................................................66 3.5.3. Presupuesto de Costos ..........................................................................................................67 3.5.4. Control de Costos ...................................................................................................................67
3.6. GESTIÓN DE LA CALIDAD DEL PROYECTO...........................................................................................68 3.6.1. Planificación de Calidad .........................................................................................................68 3.6.2. Aseguramiento de Calidad .....................................................................................................69 3.6.3. Control de Calidad ..................................................................................................................70
3.7. GESTIÓN DE RECURSOS HUMANOS DEL PROYECTO ...........................................................................70 3.7.1. Planificación de Recursos Humanos ......................................................................................71 3.7.2. Adquisición del Equipo de Proyecto .......................................................................................72 3.7.3. Desarrollo del Equipo de Proyecto .........................................................................................73 3.7.4. Gestión del Equipo de Proyecto .............................................................................................74
3.8. GESTIÓN DE COMUNICACIONES DEL PROYECTO .................................................................................74 3.8.1. Plan de Comunicación ............................................................................................................75 3.8.2. Distribución de la Información ................................................................................................75 3.8.3. Reporte del Desempeño .........................................................................................................76
3.9. GESTIÓN DEL RIESGOS DEL PROYECTO .............................................................................................76 3.9.1. Plan de Gestión del Riesgo ....................................................................................................77 3.9.2. Identificación de Riesgos ........................................................................................................77 3.9.3. Análisis Cualitativo de los Riesgos .........................................................................................78 3.9.4. Análisis Cuantitativo de los Riesgos .......................................................................................78 3.9.5. Plan de Respuesta al Riesgo .................................................................................................78 3.9.6. Monitorización y Control del Riesgo .......................................................................................79
3.10. GESTIÓN DE ADQUISICIONES DEL PROYECTO .................................................................................79 3.10.1. Planificar Compras y Adquisiciones ....................................................................................80 3.10.2. Planificar Contratos .............................................................................................................81 3.10.3. Solicitar Respuesta de Proveedores...................................................................................81 3.10.4. Seleccionar Proveedores ....................................................................................................82 3.10.5. Administración de Contratos ...............................................................................................82 3.10.6. Cierre de Contratos .............................................................................................................83
CAPÍTULO 4. PROCESO DE IMPLEMENTACIÓN...............................................................................84
4.1. INTRODUCCIÓN ................................................................................................................................84 4.2. FASE DE INICIATIVA ..........................................................................................................................84
4.2.1. Generación .............................................................................................................................84 4.2.2. Estudio ....................................................................................................................................85 4.2.3. Aprobación y Planificación .....................................................................................................88 4.2.4. Cierre ......................................................................................................................................89 4.2.5. Entregables .............................................................................................................................89
4.3. FASE DE ESTRUCTURA .....................................................................................................................89 4.3.1. Definición del Equipo ..............................................................................................................89 4.3.2. Definición de Entornos de Trabajo .........................................................................................92 4.3.3. Definición de Plazos ...............................................................................................................98 4.3.4. Criterios de Calidad ................................................................................................................99 4.3.5. Detección de Riesgos .............................................................................................................99 4.3.6. Documentación de Requerimientos .......................................................................................99 4.3.7. Entregables ...........................................................................................................................100
4.4. FASE DE ANÁLISIS ..........................................................................................................................100 4.4.1. Talleres de Análisis...............................................................................................................100 4.4.2. Generación de Documentos de Análisis por Módulo ...........................................................103 4.4.3. Generación de Documentos de Detalle por Modificación ....................................................103
4.4.4. Generación de los Guiones de Prueba ................................................................................103 4.4.5. Cierre y Aprobación de los Documentos ..............................................................................104 4.4.6. Cierre y Aprobación de la Fase de Análisis .........................................................................104 4.4.7. Entregables ...........................................................................................................................105
4.5. FASE DE DISEÑO TÉCNICO ..............................................................................................................105 4.5.1. Diseño de Estructura de Datos .............................................................................................106 4.5.2. Diseño de la Interfaz Visual de Usuario ...............................................................................106 4.5.3. Diseño de Procesos en Lote o “Batch” .................................................................................107 4.5.4. Revisión de Diseño ...............................................................................................................107 4.5.5. Diseño Detallado. .................................................................................................................108 4.5.6. Preparación de Entornos ......................................................................................................108 4.5.7. Diseño de Pruebas ...............................................................................................................109 4.5.8. Plan de Implantación ............................................................................................................110 4.5.9. Validación y Aprobación del Diseño .....................................................................................110 4.5.10. Entregables .......................................................................................................................111
4.6. FASE DE CONSTRUCCIÓN ...............................................................................................................111 4.6.1. Construcción del Código. .....................................................................................................111 4.6.2. Ejecución de Pruebas Unitarias. ..........................................................................................112 4.6.3. Ejecución de Pruebas de Integración entre sistemas. .........................................................112 4.6.4. Elaboración del Manual de Operación. ................................................................................112 4.6.5. Validación y Cierre de las Pruebas Unitarias. ......................................................................112 4.6.6. Entregables ...........................................................................................................................113
4.7. PRUEBAS FUNCIONALES .................................................................................................................113 4.7.1. Implementación en Entorno de Pruebas de Sistemas. ........................................................113 4.7.2. Ejecución de Pruebas Funcionales. .....................................................................................113 4.7.3. Soporte a la Ejecución de Pruebas. .....................................................................................113 4.7.4. Ejecución de Pruebas Técnicas. ..........................................................................................114 4.7.5. Validación y Cierre de la Fase de Pruebas Funcionales......................................................114 4.7.6. Entregables ...........................................................................................................................114
4.8. PRUEBAS INTEGRADAS ...................................................................................................................115 4.8.1. Implementación en Entorno de Pruebas Integrales. ............................................................115 4.8.2. Ejecución de Pruebas Integrales. .........................................................................................115 4.8.3. Elaboración del Manual de Usuario. .....................................................................................115 4.8.4. Preparación del Entorno de Producción. ..............................................................................116 4.8.5. Validación y Cierre de Pruebas Integradas. .........................................................................116 4.8.6. Entregables ...........................................................................................................................116
4.9. FORMACIÓN ...................................................................................................................................116 4.9.1. Implementación en Entorno de Pruebas de Formación. ......................................................116 4.9.2. Elaboración del Manual de Usuario. .....................................................................................116 4.9.3. Impartición de la Formación. ................................................................................................117 4.9.4. Entregables ...........................................................................................................................117
4.10. PUESTA EN PRODUCCIÓN ............................................................................................................117 4.10.1. Implementación en Entorno de Producción. .....................................................................117 4.10.1. Soporte a Usuarios. ..........................................................................................................117 4.10.2. Entregables .......................................................................................................................118
4.11. ACEPTACIÓN DEL PROYECTO ......................................................................................................118 4.11.1. Entregables .......................................................................................................................118
CONCLUSIONES.......................................................................................................................................119
BIBLIOGRAFÍA..........................................................................................................................................121
GLOSARIO ................................................................................................................................................125
Índice de TABLAS y Figuras Figura 1. Cobertura Funcional de HRa Suite 7. (Fuente: http://hraccess.com/). ..................................25 Figura 2. Mapa de Soluciones de Meta 4. (Fuente: http://www.meta4.es/) ..........................................28 Figura 3. Mapa de Soluciones de SAP. (Fuente: http://www.sap.com).................................................29 Figura 4. Integración de soluciones de todas las soluciones de SAP. (Fuente: http://www.sap.com)..29 Figura 5. Beneficios esperados de la implementación de funcionalidades de autoservicio en PeopleSoft. 32 Figura 6. BSCH - Distribución de beneficios por segmentos geográficos y de Negocio. (Fuente: https://www.bancosantander.es) ..................................................................................................................39 Figura 7. BBVA – Margen de explotación y beneficio atribuido por áreas de negocio. (Fuente: http://www.bbva.com) ...................................................................................................................................40 Figura 8. Ejemplo de Diagrama por Precedencias ................................................................................57 Figura 9. Ejemplo de Diagrama por Flechas .........................................................................................58 Figura 10. Ejemplo de Diagrama de Gantt ..............................................................................................63 Figura 11. Ejemplo de Diagrama de Red con Fechas .............................................................................63 Figura 12. Ejemplo de Diagrama de Hitos ...............................................................................................64 Figura 13. Ejemplo de Representación de Línea Base y Flujo de Efectivo ............................................67 Figura 14. Formatos para definición de Roles y Responsabilidades ......................................................72 Figura 15. Mapa de Entornos – Esquema de Máximos ..........................................................................92 Figura 16. Mapa de Entornos – Esquema de Mínimos ...........................................................................93 Figura 17. Procedimiento de trabajo en entorno de Desarrollo ...............................................................94 Figura 18. Procedimiento de trabajo en entorno de Pruebas de Sistemas .............................................96 Figura 19. Procedimiento de trabajo en entorno de Pruebas de Usuario ...............................................97 Figura 20. Ejemplo de EDT ....................................................................................................................125
1
RESUMEN
En la última década, como parte de la dinámica de evolución de la informática, las
grandes empresas han apostado por unificar sus sistemas de gestión en las
aplicaciones conocidas como ERP (Enterprise Resource Planning). Se ha progresado
desde sistemas desarrollados a medida para soluciones específicas, hacia sistemas
integrados de gestión que abarquen la mayor parte posible de los procesos de la
empresa. De esta forma se puede integrar todas las áreas o departamentos de la
compañía que apoyan para la generación de sus productos y servicios y así disponer de
información actualizada en tiempo real.
En grandes corporativos, típicamente, la solución se ha implementado inicialmente en la
Sede Central o en una empresa estratégica del grupo. De esta forma, al día de hoy
muchos de estos sistemas están en funcionamiento y estabilizados pero
proporcionando información que resulta ser parcial para una visión corporativa. Una vez
que se comienzan a percibir los resultados de esta primera implementación, se hace
imperativo ir extendiendo el uso del sistema en varias dimensiones: funcionalidad de los
procesos implementados, incorporación de nuevos procesos y alcance de la gestión
(número de empresas o divisiones del corporativo, número de empleados, etc.).
Esta tesis está dedicada al estudio y presentación de una propuesta para el proceso de
incorporación de filiales latinoamericanas de un gran corporativo del sector bancario
español a un sistema de Gestión de Recursos Humanos basado en la aplicación
PeopleSoft. El estudio se centra en la Gestión del Proyecto aunque trataremos el marco
de procedimientos del área y haremos referencia a temas específicos técnicos de la
aplicación para mejorar su entendimiento.
2
INTRODUCCIÓN
A. Objetivo
Esta tesis tiene como objetivo proponer una forma eficiente de implementar una
aplicación informática de Gestión de Recursos Humanos en funcionamiento, en
específico PeopleSoft, en nuevas filiales en Latinoamérica de una empresa española
del sector bancario.
Este tipo de empresas tienen un gran volumen de empleados, importante dispersión
geográfica, pero también mucha inversión en tecnología e infraestructura. Por otra
parte, presentan una problemática específica, pues están típicamente consolidadas a
partir de la fusión de muchas empresas. Este elemento influye considerablemente en
tanto a nivel estructural en la organización, como a nivel técnico, en el esquema de los
sistemas y calidad de la información de que se dispone.
Asimismo, el hecho de trabajar con un corporativo español en proceso de expansión a
países de Latinoamérica, presenta un reto en la gestión del cambio cultural, de
procesos y procedimientos que vivirá la organización, antes, durante y después del
proyecto.
El procedimiento que presentamos, pretende consolidar la teoría y la experiencia
adquirida, para poder llevar a cabo exitosamente estos grandes proyectos.
B. Estructura de la tesis
Para la consecución del objetivo planteado, este documento está organizado en cuatro
capítulos. La estructura de cada una de estas partes se describe a continuación:
En el capítulo Error! Reference source not found. se describen los sistemas ERP
(Enterprise Resource Planning) y en específico de los sistemas de Gestión de Recursos
Humanos. Se describe cómo se ha evolucionado hacia estas aplicaciones, las
necesidades que las empresas pretenden cubrir con ellas, y los beneficios esperados.
3
Además, se tratará sobre el conocimiento generado alrededor de los proyectos de
implementación, reflejado en las diversas metodologías existentes. Continuará con una
breve descripción de los productos disponibles en el mercado profundizando más en
PeopleSoft y se comentarán tanto sus ventajas e inconvenientes como elementos a
tener en cuenta durante el proyecto.
En el capítulo 2 se describe la empresa objetivo: un corporativo del sector bancario. Se
explica por qué se ha seleccionado este sector, de forma que estos argumentos sirvan
como punto de comparación para otros proyectos semejantes. Se comentará el marco
histórico en el que se han desarrollado estas empresas, cómo se ha llegado a su cultura
de Gestión de Recursos Humanos y cómo en paralelo se han ido desarrollando
programas y sistemas para su automatización. Se describirá el proceso de expansión
que han iniciado estas empresas y que continúa por varios años, profundizando sobre
cómo este crecimiento conlleva también necesidades de control y, por tanto, de
automatización, esta vez, traspasando fronteras y horarios, con la complejidad que este
proceso tiene implícito.
En el capítulo 3 se describe la gestión de este proyecto desde el punto de vista del PMI
(Project Management Institute). Se comentarán cada una de las fases del proyecto,
basados en la metodología y explicando la interpretación que se le debe de dar en el
marco de nuestro interés. Cada uno de estos aspectos es de crucial importancia y se
deben mantener controlados a lo largo del proyecto, haciendo que la labor del Líder de
Proyecto sea crítica para el éxito del mismo. Uno de los temas más importantes será el
efecto de las diferencias socio culturales en la gestión de los recursos y las
comunicaciones, pues es un factor crítico de éxito en un proyecto internacional. Se
tratará también cómo se deben involucrar las distintas áreas de la empresa, tanto de la
Sede Central (desde ahora se llamará “Holding”) como de la filial en país objetivo
(desde ahora se llamarán “Países”), para lograr, por un lado, el cumplimiento de los
objetivos corporativos y, por otro, el compromiso de continuidad en el uso de la
aplicación por parte del país destino.
En el capítulo 4 se describe el proceso de implementación, desde el origen de la
iniciativa, hasta su implementación. Se comentarán las tareas de cada etapa, la
4
documentación necesaria y los puntos críticos de control. Se resaltará la importancia del
control sobre la documentación en este tipo de proyectos, pues éstos suelen tener una
gran duración con un alto grado de rotación de recursos. De igual forma, se enfatizará
en la necesidad de realizar un análisis y diseño técnico de alta calidad, pues determina
en definitiva el éxito del proyecto. En este apartado se abordarán especificaciones
técnicas que se hayan detectado como críticas y de aplicación general en los proyectos.
Sin embargo, no se explicarán los detalles específicos o modificaciones a realizar para
funcionalidades muy concretas de ciertas empresas, sino que se enfocará en la visión
general de las necesidades de adaptación de la aplicación, aportando algunos ejemplos
para ilustrar nuestros argumentos.
Finalmente, se recopilan las conclusiones y posibles derivaciones de la metodología y
estructuración planteadas en este trabajo.
5
CAPÍTULO 1. LA APLICACIÓN.
1.1. Introducción
En los últimos 30 años el flujo de la información se ha convertido en un factor crítico en
la evolución de las empresas. La información, como recurso decisivo, ha cobrado una
velocidad de movimiento tal, que hace necesario disponer de tecnologías que permitan
su manejo y explotación.
En palabras de Manuel Castells (1996) en "La Era de la Información", nuestra era: “Es
un periodo histórico caracterizado por una revolución tecnológica centrada en las
tecnologías digitales de información y comunicación…”. Así, un factor clave para este
desarrollo ha sido la tecnología, reflejada tanto en hardware como software.
Sin embargo, no hay que perder de vista que estas herramientas son un apoyo que
finalmente debe facilitar las decisiones y, por tanto, acelerar la obtención de beneficios
dentro de la empresa.
En este capítulo describiremos qué es un ERP, cuáles son sus efectos dentro de las
empresas, la historia que hay detrás, y finalmente, qué oferta encontramos en el
mercado. De esta forma, esperamos aportar un panorama sobre la herramienta con la
que estamos trabajando.
1.2. Sistemas ERP (Enterprise Resource Planning)
1.2.1. Definición
Las soluciones de Planificación de Recursos Empresariales ó por sus siglas en inglés
ERP (Enterprise Resource Planning), según Kumar y Hillengersberg (2000): “son
paquetes de sistemas de información configurables que integran información y procesos
basados en información a través de áreas funcionales en una organización.”
6
Los sistemas ERP de generaciones actuales, también proporcionan modelos de
referencia o plantillas de procesos que aseguran representar las mejores prácticas de
negocio.
Como podemos ver, un ERP es primeramente un “paquete” o conjunto de programas
integrados. La integración es elemental, pues es necesario que la información fluya a
través de los distintos componentes, de forma dinámica y eficiente, evitando la pérdida,
duplicación o re-proceso de la información.
Un factor que caracteriza a estos sistemas de otras aplicaciones, es que pretenden dar
soporte a procesos completos, siguiendo su flujo a través de las distintas áreas de la
organización. De esta forma, la información que tradicionalmente tardaba mucho tiempo
en llegar de un sitio a otro, o no lo hacía, está disponible para quien la requiera, sin que
para ello se tengan que hacer esfuerzos adicionales para su envío.
Apoya áreas organizacionales tales como producción y logística, finanzas y
contabilidad, ventas y Recursos Humanos. Esto significa que se intenta contar con un
solo programa de software que satisfaga las necesidades de todos los departamentos
de la empresa. Antiguamente, cada una de las áreas contaba con su propio sistema. Lo
que un ERP hace es unificar todas las aplicaciones en un sólo software integrado que
se ejecuta sobre una sola base de datos, de tal forma que las distintas áreas puedan
intercambiar la información.
Estos sistemas crean valor añadido de dos formas:
Conectando y gestionando los flujos de información en organizaciones complejas
para que el personal de gestión y operativo puedan tomar decisiones con base
en información lo más perfecta y realista posible, que refleje el verdadero estado
actual del negocio.
Automatizando procesos complejos de transacciones, y por lo tanto, ahorrando
tiempo, dinero y recursos.
Según Kumar y Hillengersberg (2000), los ERPs se consideran el “impuesto” de entrada
para hacer negocios y, por lo menos por ahora, para estar conectado con otras
7
empresas en una economía de red. Incluso estas soluciones se han descrito como la
segunda tecnología en importancia de la última década, después de Internet.
Por su parte, Hitt, Wu y Zhow (2002), comentan: “Al paso de los años, la
implementación de los ERPs en varias empresas y los datos financieros obtenidos, se
encuentra que las firmas más grandes (y aquéllas con un ligeramente mejor
desempeño) tienden a invertir en la implementación de un ERP. A pesar de que hay
una ralentización en el rendimiento y productividad poco después de la implementación,
los mercados financieros premian constantemente a las empresas usuarias con una
valoración del mercado más alta (medido con la Q de Tobin1)”
Se prevé que el mercado global para las aplicaciones empresariales crezca hasta
$43,000 millones de dólares en 2011, con un crecimiento anual compuesto (CAGR2) del
8,3% en los siguientes 4 años. El mercado de ERP en 2007 era de $18,000 millones de
dólares, y se espera que crezca a una taza CAGR del 6,7%, hasta alcanzar $25,000
millones de dólares en 2011. (ARC Advisory Group, 2007).
Según Hitt, Wu y Zhow (2002, p.3), para un proyecto tipo de implementación de ERP,
los costos del proyecto se distribuyen de la siguiente forma: Licencias (16%), hardware
(14%), consultoría (60%), formación y otros costos internos de personal (10%).
Con esta información podemos concluir que estas aplicaciones son de gran importancia
para las empresas. Pues se invierten grandes cantidades de dinero, tanto en los
productos, como en el proceso de implementación. Este dinero se invierte en espera de
poder tomar mejores decisiones gerenciales, mejorar la gestión financiera, mejorar el
servicio y atención a clientes y aumentar la flexibilidad.
1.2.2. Historia
La historia de los sistemas ERP avanza a la par que las necesidades de gestión, el
crecimiento de las empresas y la evolución de la tecnología. Quizás una de las primeras
1 CAGR: Ver Glosario
2 Q de Tobin: Ver Glosario
8
propuestas sea la de Blumenthal (1969), que propone una arquitectura integrada y un
esquema de trabajo para sistemas de gestión de información de la organización.
Sin embargo, y a pesar de ser un objetivo constante de las organizaciones, el gran
costo y esfuerzo que se requiere para realizarlas ha derivado en mucho tiempo
desarrollar y poner en práctica estos sistemas.
Muchos de los esfuerzos de las empresas se centraron en automatizar o generar
software para procesos específicos, típicamente en contabilidad, facturación o control
de inventarios. De los primeros sistemas a medida, se pasó a aplicaciones pre-
programadas para procesos específicos, posteriormente a sistemas de planificación de
requerimientos de materiales (MRP – Material Requirements Planning), gestión de
recursos de fabricación (MRP II - Manufacture Resources Planning) y posteriormente a
la inclusión de otros procesos de la empresa tales como ventas y gestión de órdenes de
venta, marketing, compras, gestión de almacenes, gestión de finanzas y gestión
contable.
Los esfuerzos que se emprenden dentro de las empresas también tienen su reflejo en
empresas exteriores que encuentran un nicho de mercado. En 1972, empleados de IBM
fundan SAP (Systems Applications and Products in Data Processing) con el objetivo de
desarrollar una aplicación estándar para procesamiento de negocio en tiempo real. Un
año después, finalizan su primer software de contabilidad financiera. Ya en los 80’s, 50
de las 100 empresas industriales más grandes de Alemania son clientes de SAP (P.ej.,
Boeing, Mercedes-Benz y BMW).
También en los 80’s, concretamente en 1987, David Duffield y Ken Morris fundan
PeopleSoft para crear una versión cliente servidor del paquete de Recursos Humanos
de Integral Systems. A finales de la década finalizan su primera versión del producto,
que es la primera aplicación de Recursos Humanos en cliente-servidor totalmente
integrada. PeopleSoft extendió su marco de acción para incluir módulos financieros en
1992, Distribución en 1994 y Fabricación en 1996.
9
Fue en la década de los 90 cuando en realidad se llega al auge del mercado de ERP.
Tanto en Europa (principalmente con SAP) como en América (PeopleSoft, Oracle,
Siebel, JD Edwards) se logra comenzar una revolución del mercado de los ERPs
convirtiéndose en icono de los éxitos empresariales, llegando a compararlos incluso con
Microsoft. A pesar de predicciones de su posible recaída (las acciones de SAP y Baan
tuvieron una caída importante a finales de 1998), estos sistemas siguieron creciendo.
Muchos lo atribuyen a los problemas de los sistemas provocados por el efecto 2000
(Y2K), pero la venta siguió incrementándose. Y todo esto a pesar de los grandes
costos, complejidad en los procesos de implementación, y que el tiempo de obtención
de resultados positivos era muy grande. Sin embargo, las empresas comenzaban a
replantearse lo acertado de las implementaciones. La revista The Economist (1999,
ERP RIP?) cita a Tom Siebel (fundador y presidente de Siebel Systems) diciendo que
“La planificación de recursos empresariales [ERPs] es un páramo salvaje. El mercado
del back-office es simplemente horrible. Todo el mundo lo tiene y el mercado está
cerrado”.
Según este mismo artículo, la principal amenaza contra estos sistemas era Internet:
Tendrían que convivir mejor con esta tecnología, puesto que la web ofrecía grandes
posibilidades cara a futuro. De hecho, el mercado clamaba por aplicaciones más fáciles
de utilizar y con posibilidad de acceso desde todos los puntos de la empresa sin añadir
costos adicionales, ventajas que ofrecía Internet.
Y así, siguiendo el tan temido “adaptarse o morir”, todas estas aplicaciones se han ido
incorporando a versiones Internet, ajustando incluso sus listas de precios de licencias y
logrando que las empresas traspasen las fronteras de su gestión más allá de los
procesos internos hacia funciones de autoservicio para empleados, clientes y
proveedores. También se ha reforzado la integración de las aplicaciones, construyendo
una infraestructura robusta que puede ir creciendo conforme crece el negocio.
Los ERP están más establecidos en Estados Unidos, Alemania, países escandinavos y
Países Bajos. Recientemente ha comenzado a cobrar fuerza en países emergentes
como India, Brasil, China, México así como en naciones más industrializadas como
Singapur, Japón, Reino Unido y España.
10
Según Kumar y Hillengersberg (2000) los retos que estos sistemas tienen, de cara a un
crecimiento de futuro, pasan por integrar transacciones electrónicas y gestión
documental basada en multimedia para permitir que clientes, proveedores, empleados y
todas aquellas personas que interactúan con la empresa lo puedan hacer a distancia,
guardando en el sistema todos los documentos necesarios tales como documentos
escaneados, facturas, currícula de candidatos y empleados, etc. En segundo lugar, ya
que los ERP se han enfocado principalmente en el procesamiento de transacciones, un
siguiente paso natural sería reforzar las capacidades de minería de datos para facilitar
la toma de decisiones. Finalmente, deberían confluir los esfuerzos de desarrollo de los
sistemas ERP y las aplicaciones de gestión de suministro, de forma que se facilite la
integración inter-organizacional conforme nos vamos acercando a la economía de red.
Creemos que estos retos siguen vigentes, pues a pesar de que tecnológicamente se
haya podido evolucionar en este sentido, aún queda pendiente la integración de las
soluciones por parte de las empresas.
1.3. Productos del Mercado
Muchos son los productos que se encuentran en el mercado, sobre todo en últimas
fechas que se han desarrollado soluciones para PyMEs y Open Source Software. En
este capítulo describiremos los más representativos:
1.3.1. SAP R/3
Este software está distribuido por la empresa del mismo nombre, que es la quinta
compañía mundial de software. Este sistema comprende muchos módulos integrados
de prácticamente todas las áreas de la organización. Las soluciones que tiene son:
SAP ERP
SAP Customer Relationship Management
SAP Product Lifecycle Management
SAP Supply Chain Management
SAP Supplier Relationship Management
SAP Analytics
11
SAP Manufacturing
SAP Service and Asset Management
SAP solutions for mobile business
SAP xApps
Cuentan con desarrolladas verticales conocidas como IS o Industry Solution orientadas
a sectores de la industria como automotriz, defensa, productos químicos, alta
tecnología, petrolífera o telecomunicaciones. Asimismo, algunos socios de SAP han
desarrollado sus soluciones que se han incorporado al propio producto. Estas versiones
conocidas como micro-verticales se encuentran en sectores como piscifactorías, agro-
exportadoras, etc. SAP ha conquistado clientes de forma consistente para tener la cuota
del mercado global entre sus principales competidores a 22% a mediados de 2012.
(Fuente: http://panorama-consulting.com).
Adicionalmente cuenta con soluciones para la pequeña y mediana empresa:
SAP Business All-in-One
SAP Business ByDesign
SAP Business One
SAP BusinessObjects portfolio
SAP BusinessObjects Edge
Crystal Reports
Xcelsius
Free trials
Tiene su propia plataforma tecnológica SAP NetWeaver, lo que permite ofrecer versión
Web. La aplicación está basada en un lenguaje de programación propietario conocido
como ABAP (Advanced Business Application Programming), que se puede utilizar para
hacer las modificaciones y adaptaciones necesarias a la aplicación.
12
1.3.2. PeopleSoft (PS)
Actualmente distribuido por Oracle que adquirió la empresa PeopleSoft en 2005.
Originalmente ofrecían aplicaciones de Recursos Humanos y Finanzas. Al paso de los
años han desarrollado herramientas y aplicaciones para procesos de negocios
generales, tales como CRM, gestión de materiales e e-business, así como soluciones
para industrias específicas, tales como automotriz, comunicaciones y educación. En
1999 hizo un esfuerzo por cambiar el enfoque de Cliente-servidor a aplicaciones
puramente Internet (PIA – Pure Internet Architecture), lanzando al mercado PeopleSoft8
en el año 2000. La aplicación, basada totalmente en web, intenta integrar sistemas
fácilmente de forma que las empresas puedan conectar clientes, empleados y
proveedores más eficientemente y al menor costo. Una organización puede gestionar
sus operaciones desde el origen debido a que la información está disponible al
momento para muchas personas, en cualquier momento y en cualquier lugar,
incluyendo tecnología móvil como agendas electrónicas (PDA) y teléfonos móviles.
Las soluciones que Oracle ofrece en la suite de PeopleSoft son:
Gestión Financiera
Gestión de Capital Humano
Gestión de Relaciones con los Clientes
Gestión de Cadenas de Suministro
Gestión del Rendimiento de la Empresa
Automatización de Servicios Empresariales (Gestión de Proyectos)
Gestión de Relaciones con los Proveedores (Adquisición)
Gestión del Ciclo de Vida de los Activos
Campus Solutions
PeopleSoft cuenta con herramientas propias para el desarrollo de la aplicación. El
Application Designer es la aplicación central utilizada para crear y adaptar todas las
aplicaciones PeopleSoft. De igual forma, el lenguaje de programación también es
específico y propio. El PeopleCode es un lenguaje orientado a objetos, relacionado con
el entorno de las PeopleTools (basado en el Application Designer).
13
1.3.3. Oracle e-business Suite (EBS)
Distribuido por Oracle, las soluciones Oracle e-Business Suite (EBS) consisten en un
conjunto de aplicaciones ERP, CRM (Costumer Relationship Management) y SCM
(Supply Chain Management). Utiliza las bases de datos relacionales de Oracle y
contiene varias líneas de productos:
Adquisición Avanzada
Contratos
Gestión Del Rendimiento Corporativo e Inteligencia de Negocio Diaria
Gestión de Datos de Cliente y Gestión de Relaciones con los Clientes
Finanzas
Gestión de Recursos Humanos
Centro de Interacción
Gestión del Aprendizaje
Logística
Mantenimiento
Fabricación
Marketing
Gestión de Pedidos
Gestión del Ciclo de Vida de los Productos
Proyectos
Ventas y Servicio
Gestión y Ejecución de Cadenas de Suministro
Planificación de Cadenas de Suministro
Gestión del Transporte
La aplicación se modifica y se desarrolla en Oracle Forms, que es una herramienta
basada en PL/SQL que permite además generar aplicaciones nuevas sobre en bases
de datos Oracle. Oracle Forms está incluido en la suite de Desarrollo de Oracle.
14
1.3.4. J. D. Edwards (JDE)
Inicialmente comercializado a través de la empresa J.D.Edwards, fue adquirido por
PeopleSoft en 2003 y este a su vez por Oracle en 2005. Está más enfocado a pequeñas
y medianas empresas, aunque hay algunas grandes empresas que lo han adquirido e
implementado. La versión JDE EnterpriseOne está enfocada sobre todo a medianas
empresas y la versión JDE World a pequeñas empresas. JD Edwards EnterpriseOne
ofrece una lista creciente de versiones localizadas para los principales mercados de
todo el mundo.
Gestión Financiera
Gestión de Capital Humano
Gestión de Proyectos
Gestión de Cadenas de Suministro
Gestión del Ciclo de Vida de los Activos
Gestión de Relaciones con los Clientes
Gestión de Suministros (Adquisición)
OneWorld es una aplicación en plataforma independiente, con herramientas integradas
que permiten que los clientes configuren sus sistemas y aplicaciones conforme van
cambiando sus necesidades. No tiene una arquitectura predefinida, por lo que puede
correr en diversas plataformas.
Las herramientas que ofrecen utilizan lógica de negocios (se configuran como en un
flujo de proceso). De esta forma, los cambios se aplican directamente en la
representación de esta lógica y la aplicación calcula internamente el código, de esta
forma, las modificaciones no requieren un programador tradicional. Asimismo, las
modificaciones a la aplicación, nivelación de procesos, ejecución de informes y creación
de nuevas pantallas se hacen sin tener que escribir código. Cuenta también con versión
en Internet.
15
1.3.5. Otros Sistemas
Hoy en día, estos productos, que estaban reservados a gigantes empresariales con
gran capacidad de inversión, se han acercado al mercado de las empresas medianas e
incluso se encuentran versiones de Open Source Software. A continuación hacemos
una relación de software en el mercado principal:
ERP con Licencias:
1C:Enterprise de 1C Company
24SevenOffice Start, Premium,
Professional y Custom de
24SevenOffice
abas ERP de ABAS Software
Accpac de The Sage Group
Agresso Business World de Unit 4
Agresso
AMS Advantage de CGI Group
(formerly American Management
Systems)
BatchMaster ERP de BatchMaster
Software
Bowen & Groves M1 by B&G
Comprehensive Patient
Administrator
Consona Corporation - Intuitive;
Made2manage; AXIS; Cimnet;
Encompix; DTR
Epicor Enterprise de Epicor
ERP Adage (conocido como
Adage) de Infor Global Solutions
ERP LN (conocido como Baan) de
HansaWorld products
IFS Applications de Industrial y
Financial Systems
kVASy4 de SIV.AG
Kingdee de Kingdee
Lawson M3 de Lawson Software
antes Movex de Intentia
Lawson S3 de Lawson Software
Maximo (MRO) de IBM
MFG/PRO de QAD Inc
Microsoft Dynamics AX (formerly
Axapta) de Microsoft
Microsoft Dynamics GP (formerly
Great Plains) de Microsoft
Microsoft Dynamics NAV (formerly
Navision) de Microsoft
Microsoft Dynamics SL (formerly
Solomon) de Microsoft
Momentum de CGI Group
NetERP de NetSuite Inc.
Openda QX de Openda
OpenMFG de xTuple
Paradigm de Consona Corporation
16
Infor Global Solutions
ERP LX (conocido como BPCS) de
Infor Global Solutions
ERP SL (conocido como SyteLine)
de Infor Global Solutions
ERP SX.Enterprise (conocido como
SX.Enterprise) de Infor Global
Solutions
ERP VE (conocido como Visual
Enterprise) Infor Global Solutions
ERP XA (conocido como MAPICS)
de Infor Global Solutions
Global Shop Solutions One-System
ERP Solutions
Ramco e.Applications de Ramco
Systems
Ramco Ondemy erp de Ramco
Systems
MAS 90, MAS 200 y MAS 500 de
The Sage Group
SAGE ERP X3 de The Sage Group
SYSPRO de Syspro
SYS-APPS de Exclusive
Technologies
mySAP de SAP
Vantage de Epicor
Visual Enterprise de Infor Global
Solutions
Open Source Software
Adempiere, ERP basado en Java.
BlueErp, ERP basado en PHP
Compiere, ERP basado en Java
Dolibarr, ERP basado en PHP
ERP5, ERP basado en Python
GNU Enterprise
GRR, basado en PHP/MySQL
JFire, ERP basado en Java
Kuali Foundation
LedgerSMB
OFBiz ERP basado en Java
OpenBlueLab
Openbravo, ERP basado en Java
OpenERP (antes Tiny ERP)
Opentaps ERP basado en Java
OrangeHRM
Postbooks de XTuple
SQL-Ledger
Stoq
WebERP
17
1.4. Metodología
La naturaleza propia de los proyectos de sistemas ha provocado que en cada proyecto
sucesivo se perfeccione el método de implantación. El conocimiento que se ha
generado alrededor de estos proyectos se refleja en las diversas metodologías que con
distintos nombres enarbolan las empresas o equipos de implementación. Sin embargo,
en todos podemos encontrar elementos comunes aunque estén designados con
distintos nombres. En este apartado haremos una breve explicación de esta
metodología que aplica en general a todos los proyectos de sistemas. En los capítulos
siguientes explicaremos al detalle cada una de las etapas y las tareas específicas para
implementación de PeopleSoft RRHH en el proceso de expansión.
1.4.1. Gestión de la Iniciativa
Recepción: Hay un momento en concreto en que surge la idea. En algún punto de la
organización se detecta alguna necesidad que requiere una solución. En este punto se
recogen las necesidades de las áreas de negocio definiendo su viabilidad o inviabilidad
con base en las opciones posibles y delimitando el alcance de la iniciativa en términos
generales.
Estudio: Tiene como objetivo describir el futuro sistema, delimitando sus objetivos, su
alcance e impacto en otros sistemas.
Además, se identificarán a los clientes internos con los que se mantendrán las sesiones
de trabajo necesarias para definir el proceso de negocio propuesto y los requisitos que
se deriven del alcance acordado identificándose el impacto en otros sistemas.
Se estudiarán, analizarán y valorarán las diferentes alternativas que pueden existir
sobre el enfoque de desarrollo y entorno tecnológico del proyecto, así como la
identificación del impacto en procesos de negocio y actividades. Se recomienda una
opción del modelo de la solución en función de los beneficios aportados y los costos
supuestos.
18
Aprobación y Planificación: Se acepta o deniega la realización del proyecto en
función del análisis, valoración y de la disponibilidad de presupuesto. Se realiza la
priorización de la cartera de proyectos de una manera global y establecer cuándo se va
a acometer el presente proyecto.
Cierre: Aquí se formaliza el inicio del desarrollo y se efectúa el cierre de la iniciativa.
1.4.2. Desarrollo del Producto
Análisis: Tiene como objetivo delimitar el alcance del sistema, mediante modelos
iniciales de alto nivel y detallando el aspecto que tendrá el nuevo sistema de cara al
usuario.
Diseño: En él se obtiene un diseño detallado de los componentes del sistema y de la
interfaz de usuario a partir de la documentación generada durante la fase de análisis.
Construcción: Se construyen los elementos de software que conforman el sistema y
que se han diseñado en las fases anteriores. También se preparan los entornos para
cada una de las pruebas y realizar las pruebas unitarias correspondientes de cada
componente del sistema.
Pruebas Funcionales: Se aplican los distintos tipos de pruebas funcionales, de
sistema e integración, verificando que la aplicación cumple con los niveles de calidad
requeridos.
Pruebas de Usuario: Se realizan las pruebas de aceptación validando que satisface
los requisitos establecidos por el usuario y se preparan los entornos de formación y
producción.
Implantación: Se realiza la implantación de los programas, módulos, componentes y
demás elementos que forman el sistema y que han sido diseñados, construidos,
probados y validados en las fases anteriores.
19
1.4.3. Gestión
Dirección del Proyecto: Se realizan todas aquellas actividades y tareas que permitan:
La puesta en marcha del proyecto.
Su seguimiento y control.
La comprobación del correcto desempeño.
Su cierre a la finalización del proyecto.
Soporte: Se coordinan las acciones de mejora continua y certificaciones de la calidad
del proyecto necesarias.
Gestión Presupuestaria: Se lleva el control económico del proyecto, controlando las
desviaciones que puedan resultar.
1.5. Sistemas de Gestión de Recursos Humanos
La evolución continua de las empresas tiene un reflejo importante en la visión de la
gestión de los recursos humanos, como resalta Herrera Lemus (2005), “se está
intentando transformar el concepto clásico de „administración de personal‟, con la carga
administrativa y burocrática que el concepto implica, en algo moderno y eficaz que
suele denominarse administración o gestión de recursos humanos”.
El mercado laboral es cada vez más competitivo, las empresas dan un valor adicional a
la gestión del capital humano y, por tanto, necesitan más información que les permita
orientar las acciones adecuadas para asegurar “el mejor recurso, en el mejor lugar, en
el mejor momento”.
Herrera Lemus (2005), citando a Martínez y Herrera, comenta que “el descubrimiento e
implantación de nuevas tecnologías ha permitido transformar profundamente la
sociedad. La informática, la ofimática, las telecomunicaciones, la biotecnología, etc.,
han dado lugar a nuevos y variados productos y a una profunda revisión de los sistemas
de administración en las empresas.”
20
En el caso de la gestión de recursos humanos, permiten mejorar el análisis de perfiles
requeridos para los puestos, facilitar la captación de recursos, agilizar los procesos de
selección y contratación, dar seguimiento al desarrollo y crecimiento interno (a través de
la formación, evaluaciones del desempeño, gestión de las competencias) y automatizar
tareas críticas como el cálculo de salarios y pago de la nómina.
La informatización de estas tareas quita la carga de trabajo que agrega menos valor,
elimina fuentes de error y permite que las personas que están al frente de estas tareas
puedan dedicarse más a la gestión estratégica del área.
Según cita Meta 4, en los folletos de la aplicación, la revista Harvard Business Review
ha publicado:
“La organización dominante no será una empresa tradicional, con estructuras
permanentes, sino una que sea capaz de crear redes y estructuras elásticas.
Cuatro nuevos retos se han evidenciado en estos años en el universo HCM [Human
Capital Management]:
La relación usuario/aplicación y el reflejo que esta relación tiene en términos de
capacidad, inteligencia, productividad y eficiencia.
La descentralización y extensión de la gestión de RRHH, en términos
administrativos, de costo y eficiencia para los empleados y en términos más
estratégicos para los responsables.
Las herramientas de toma de decisión sobre las personas y la organización para
el Top Management, los profesionales de RRHH y altos directivos.
Human Resources Outsourcing: especialmente de los aspectos no estratégicos
de la compañía y con el menor valor como la gestión de nóminas y
administrativa, en sus diferentes modalidades: BPO (Business Process
Outsourcing), ASP (Application Service Provider), etc.
Pero el mayor reto para las organizaciones y, especialmente para los departamentos de
RRHH, es la creciente complejidad...”
21
El área de Recursos Humanos en una empresa es responsable de obtener y mantener
una fuerza de trabajo idónea, es decir, se deben preocupar de los siguientes aspectos:
Definición y mantenimiento de la estructura de la empresa.
Compensación equitativa y justa.
Ubicación de los empleados en los puestos adecuados.
Determinación de niveles realistas de desempeño.
Creación de canales de capacitación y desarrollo.
Identificación de candidatos adecuados a las vacantes.
Planeación de las necesidades de capacitación de Recursos Humanos.
Promoción de condiciones que mejoren el entorno laboral.
Evaluación de la manera en que los cambios en el entorno afectan el desempeño
de los empleados.
Eliminación de requisitos y demandas no indispensables.
Conocimiento de las necesidades reales de Recursos Humanos de una empresa.
De forma desglosada las tareas se podrían describir de la siguiente forma:
Contratación y Empleo
Reclutamiento: Captación de candidatos a cubrir puestos de la organización.
Selección: Elección de los candidatos más adecuados para cada puesto. Las
empresas utilizan diferentes sistemas y herramientas para seleccionar a los mejores
profesionales y conseguir que sean los más adecuados para cada puesto de trabajo.
Contratación: Determinación de condiciones de trabajo y elaboración del contrato.
Formación y Desarrollo
Formación: Proporcionar al empleado los cursos de formación necesaria para
desempeñar mejor su trabajo y aprender nuevas herramientas encaminadas al
crecimiento del empleado dentro de la organización. Para que el plan de formación de
22
una empresa aporte valor es fundamental alinearlo con la estrategia de negocio,
personalizarlo y que tenga flexibilidad para adaptarse a los cambios.
Trayectoria laboral: Seguimiento de la trayectoria de un empleado dentro de la
organización, los puestos que ha ocupado, el tiempo que ha estado en ellos y las
actividades que ha desempeñado. De esta manera se pueden elaborar los planes de
carrera del empleado dentro de la organización. Los planes de carrera tratan de casar la
oferta de puestos de una empresa con la demanda de perfiles internos. La gestión del
desempeño es el sistema utilizado para conseguirlo.
Control de Puestos Clave: Garantizar que los puestos clave sean ocupados por los
profesionales más idóneos y conseguir retener y motivar a los que tengan potencial
directivo, además de asegurar la óptima sucesión cuando los empleados que los
ocupan salgan de la organización.
Gestión del Desempeño: Da seguimiento al desempeño de los empleados dentro de la
organización, de manera que se pueda evaluar el cumplimiento de los objetivos de la
organización, de los objetivos del área y su desarrollo dentro del puesto. De estas
evaluaciones también se puede concluir las necesidades de desarrollo y formación del
empleado. Muchas veces esta evaluación está unida con objetivos de compensación e
incentivos o a planes de formación específicos.
Sueldos y Salarios
Análisis y valuación de puestos: Determinar el rango salarial de la persona que
ocupe un puesto de acuerdo al nivel salarial en el mercado, política salarial de la
empresa e importancia del puesto dentro de la organización.
Calificación de méritos: Definir el impacto de los méritos y antigüedad del empleado
en su compensación salarial o de beneficios.
Compensaciones: Determinar el salario de un empleado de acuerdo a la valoración de
su puesto y sus méritos. La compensación es el elemento que permite a la empresa,
entre otras cosas, atraer y retener los recursos humanos que necesita y al empleado,
23
satisfacer sus necesidades materiales, de seguridad y de ego o estatus. Tendrá que
procurar ofrecer el máximo nivel de satisfacción de las necesidades del empleado
procurando que para la empresa resulte una relación atractiva de costo-beneficio.
Beneficios: Determinar las retribuciones que se darán a un empleado como plus a su
compensación básica. Estas retribuciones pueden ser bienes, servicios u otras
retribuciones dinerarias o no dinerarias, que tendrán como objetivo fundamental motivar
a los empleados para que continúen esforzándose.
Relaciones laborales: La división de relaciones laborales de la dirección de Recursos
Humanos tiene como misión velar por el cumplimiento de los compromisos legales-
contractuales contraídos por la organización con sus trabajadores, procurando un clima
propicio para la buena marcha de las relaciones y mantenimiento de la paz laboral.
Comunicación interna: Garantizar que los empleados estén motivados e implicados
en la estrategia de la organización.
Convenios colectivos y Sindicatos: Regula las relaciones y negociaciones con los
sindicatos y el cumplimiento de los convenios colectivos que afectan a la organización.
Disciplina
Política y normativa interna: Se encarga de establecer las normas internas que
regulen el comportamiento y las relaciones del empleado y la organización que no están
especificadas dentro del contrato.
Seguridad e higiene industrial
Servicio médico: Es responsable de proporcionar la atención médica cuando algún
empleado la necesite.
Campañas de higiene y seguridad: Se asegurará de que los empleados conozcan las
normas y acciones a seguir para mantener en todo momento el más elevado nivel de
bienestar físico, mental y social de los trabajadores de todas las profesiones; prevenir
todo daño causado a la salud de éstos por las condiciones de su trabajo; protegerlos en
24
su empleo contra los riesgos resultantes de agentes nocivos para la salud; colocar y
mantener al trabajador en su empleo, conociendo sus aptitudes fisiológicas y
psicológicas y, en suma, adaptar el trabajo al hombre y cada hombre a su trabajo.
Ausentismo y accidentes: Controlará las ausencias de los empleados y sus causas.
En caso de accidentes se asegurará de que el empleado reciba la atención necesaria.
Planeación de Recursos Humanos.
La planificación de Recursos Humanos es una técnica para determinar de forma
sistemática la provisión y demanda de empleados que una organización padecerá en un
futuro más o menos próximo. La planificación de recursos humanos es el punto de
partida para diseñar las políticas de empleo, sustituciones internas, formación,
promoción, retribución, comunicación interna y servicios sociales.
Inventario de Recursos Humanos: Es la relación de todos los miembros de la
organización y todos los datos que se dispone de ellos.
Rotación: Es la relación de las salidas de personal, independientemente de su causas,
y la contratación de nuevos empleados.
Auditoria de personal: Es un conjunto de procedimientos llevados a cabo para
determinar las deficiencias que existen dentro de la organización, ayudar a evaluar si
cada empleado es el indicado en el puesto y revisar que es lo que éste puede mejorar y
de esta manera aportar más a su puesto.
Definición de la estructura: Determina la estructura necesaria para que la
organización cumpla sus objetivos de forma óptima. La estructura está compuesta por
las unidades de negocio, departamentos, puestos y sus relaciones de jerarquía.
Muchas empresas en el mercado han sacado productos informáticos, tanto ERP como
otros software de administración y nóminas, intentando vencer estos retos.
Adicionalmente a PeopleSoft, que se describe en el apartado “1.3.2 PeopleSoft (PS)”, a
continuación haremos una relación de los más relevantes:
25
1.5.1. HR Access
Este software, distribuido por la empresa homónima, en muchos casos se ha instalado
inicialmente en las empresas que buscaban una solución para el pago de nómina. Tiene
además funcionalidades para gestión de recursos humanos pero no tan desarrolladas
como otras aplicaciones. Trabaja principalmente en cliente-servidor, aunque en las
últimas versiones se ha podido trabajar cada vez más con desarrollos en Internet.
Figura 1. Cobertura Funcional de HRa Suite 7. (Fuente: http://hraccess.com/).
Como se puede ver en el cuadro “Figura 1. Cobertura Funcional de HRa Suite 7”,
extraído del folleto de la HRa Suite 7 de la página web de la empresa, el área de la
propia “Administración” de los Recursos Humanos forma parte de sus capacidades más
desarrolladas. En específico nómina y beneficios sociales. Es importante tener en
cuenta que estas áreas tienen constante evolución legislativa y social, y las posibles
fusiones y adquisiciones generan complejidad añadida. Este producto gestiona bien
26
este tipo de actualizaciones y, una vez estabilizado, las empresas pueden entrar en un
ritmo de mantenimiento de estos requerimientos adecuado a sus necesidades.
Como desventaja, podríamos resaltar que es difícil extender el producto a nivel
corporativo. Por un lado, las funcionalidades que se suelen extender son normalmente
autoservicios o funcionalidades de desarrollo de personal. La administración la suelen
llevar directamente las personas del área de administración y nóminas y se les puede
formar en el uso de la herramienta. Sin embargo, para extender el uso de la
herramienta, se necesitan funcionalidades más intuitivas y de fácil uso y extensión.
Conocemos el caso de un gran corporativo bancario que al intentar extender el uso de
la herramienta a otros países ha tenido que “paquetizar” la aplicación, de forma que
cada país tiene su propia base de datos e instalación del producto. A lo largo de los
años se ha podido comprobar que cada país ha adaptado la herramienta y desarrollado
modificaciones conforme a sus especificaciones locales, sin atender a un modelo
global. Esto es comprensible en una aplicación que soporta principalmente funciones de
nómina y administración, pues las necesidades son típicamente locales (derivadas de la
legislación). Sin embargo, nos aleja cada vez más de la solución corporativa.
En conclusión, se dispone de una herramienta potente para el pago de las nóminas,
pero no se avanza hacia una gestión global de los Recursos Humanos.
En cuanto a datos de clientes, según la propia Web de la empresa:
“HR Access cuenta con más de 600 clientes en 52 países y gestiona más de 12
millones de empleados. En España gestiona más de 1 millón de empleados en
clientes de todos los sectores, geografías y dimensiones, entre ellas un 20% de las
Compañías del IBEX.
HR Access es líder en el sector financiero con clientes como: AGF, AXA France, Banco
Popolare di Milano, Banco Popular, Basler Versicherung, Banco Santander, BBVA,
Banco de España, BCP, Banco Espirito Santo, Caja Madrid, Caixanova, , CDC, Credit
Agricole Alpes Provence, Credit Agricole Maroc, Cassa di Risparmio Parma, San Paolo
IMI, Unicaja ... »
27
1.5.2. Meta 4
Producto de origen español nacido como un software de pago de nómina, esta
aplicación ha evolucionado en un software de Gestión de Capital Humano. Según las
cifras que presenta la propia compañía en su web:
“Desde su fundación en 1991 contamos con más de 1.300 clientes que utilizan las
soluciones de Meta4 para gestionar a más de 18 millones de personas en más de 100
países repartidos por todo el mundo.
Plataforma tecnológica exclusiva para proveedores de servicios de
Outsourcing/ASP/Shared Services de nómina y recursos humanos, 20 proveedores en
Europa y América Latina ofrecen sus servicios a través de PeopleNet….
….Meta 4 dispone uno de los mayores centros de I+D localizado en Europa y América,
ofreciendo ventajas competitivas en cuanto a su especialización”.
Esta aplicación inició en tecnología cliente-servidor a 2 capas, posteriormente
evolucionó a cliente-servidor con servidor de aplicaciones o 3 Capas, posteriormente
adquirió funcionalidades HTML y, finalmente en 2005, ha incorporado funcionalidades
java y web enriquecido.
Tiene funcionalidades de autoservicio para empleados, para los responsables,
proveedores de servicios y, adicionalmente, funcionalidades específicas de usuario
profesional para los usuarios del área de RRHH.
28
Selección y
Contratación
Selección y
Reclutamiento
Selección
MasivaProcesos de
Acogida
Bolsa
de
Trabajo Planes de
Sucesión
Dir. por
Objetivos
Talento y
Productividad
Gestión de
Personas Clave
Gestión de
la Nómina
Gestión del
Tiempo
Gestión de la
RemuneraciónGestión de
Préstamos
Entornos
Colaborativos
Simulación
de la Nómina
Control de
Presencia y
Turnos
Gestión
Documental
Planificación
del Personal
Soporte a la
Gestión
Directorios
corporativos
Cuadros
de mando
Firma
Digital
Gestión de
Expatriados
Autoservicio
de Empleados
Retribución
Fija
Compensación
Gestión
presupuestaria y
simulaciones
Retribución
Variable e
Incentivos
Retribución
Flexible
Desarrollo
Profesional
Gestión por
Competencias y
Dir por ObjPlan de
Carreras
Valoración
de Puestos
Valoración
de Puestos
Formación y
Desarrollo
E-Learning
People
Smart
Metrics
Administración
de Personal
Gestión de la
Organización
Gestión de
Flujos de
trabajo
Selección y
Contratación
Selección y
Reclutamiento
Selección
MasivaProcesos de
Acogida
Bolsa
de
Trabajo Planes de
Sucesión
Dir. por
Objetivos
Talento y
Productividad
Gestión de
Personas Clave
Gestión de
la Nómina
Gestión del
Tiempo
Gestión de la
RemuneraciónGestión de
Préstamos
Entornos
Colaborativos
Simulación
de la Nómina
Control de
Presencia y
Turnos
Gestión
Documental
Planificación
del Personal
Soporte a la
Gestión
Directorios
corporativos
Cuadros
de mando
Firma
Digital
Gestión de
Expatriados
Autoservicio
de Empleados
Retribución
Fija
Compensación
Gestión
presupuestaria y
simulaciones
Retribución
Variable e
Incentivos
Retribución
Flexible
Desarrollo
Profesional
Gestión por
Competencias y
Dir por ObjPlan de
Carreras
Valoración
de Puestos
Valoración
de Puestos
Formación y
Desarrollo
E-Learning
People
Smart
Metrics
Administración
de Personal
Gestión de la
Organización
Gestión de
Flujos de
trabajo
Figura 2. Mapa de Soluciones de Meta 4. (Fuente: http://www.meta4.es/)
1.5.3. SAP RH
La aplicación SAP, en general, se ha descrito en el capítulo correspondiente. En cuanto
a su suite de RRHH podemos añadir algunos puntos adicionales. Se desarrolló a partir
del crecimiento natural de SAP desde su origen de manufactura. Han desarrollado una
solución muy completa, que sobre todo aporta el valor de integración con otras
aplicaciones en el caso de las empresas que tienen alguna otra solución.
Adicionalmente, tiene también opciones de autoservicio. Las facilidades de expansión,
tanto en número de empleados, módulos, empresas, son de las más potentes del
mercado. Estas capacidades se reflejan entre otras cosas, pues SAP es uno de los
líderes del mercado de RRHH.
29
Figura 3. Mapa de Soluciones de SAP. (Fuente: http://www.sap.com).
Figura 4. Integración de soluciones de todas las soluciones de SAP. (Fuente:
http://www.sap.com).
30
1.6. PeopleSoft
1.6.1. Descripción
Inicialmente era conocido como PeopleSoft HRMS (Human Resources Management
System) pero en su última versión ha sido rebautizado como Human Capital
Management (HCM).
Creado por veteranos de la industria, intenta combinar la tecnología con sentido común
del negocio y conocimiento de los procesos de Recursos Humanos.
Su principal visión es entregar una aplicación global, que permita dar información de
primera mano necesaria para una correcta toma de decisiones, a la par que descargar
de las tareas administrativas que quitan tanto tiempo.
Los módulos que componen PeopleSoft Recursos Humanos son:
Gestión de Fuerza de Trabajo Global
Reclutamiento de Fuerza de Trabajo
Gestión de Competencias
Gestión de la Formación
Planificación de Carreras y Sucesiones
Gestión Salarial
Compensación Variable
Compensación Total
Gestión de Automóviles de Empresa
Gestión de Ausencias
Seguimiento de Asignaciones Globales
Gestión de Relaciones Laborales
Requerimientos Regulatorios
Beneficios Básicos
Seguridad e Higiene
31
Una característica específica en PeopleSoft es la posibilidad de gestionar la estructura
de empresa por relaciones entre empleados o entre posiciones. Es decir, se puede
definir la estructura con dependencias nominales (el empleado A que depende del
empleado B) o a partir de las posiciones que ocupa cada uno (la posición X depende de
la posición Y). De esta forma la estructura de la organización se mantiene
independientemente de los movimientos de las personas, pero permitiendo de cualquier
forma conocer las dependencias entre empleados: como el empleado A ocupa la
posición X y el empleado B ocupa la posición Y, el empleado A depende del empleado
B.
El módulo de Gestión del Desempeño ayuda a evaluar las competencias de
Empleados, identificar necesidades de desarrollo y, en última instancia, crear peticiones
de puesto, planes de carrera y planes de formación.
El módulo de Gestión de Presupuesto de Formación, ayuda a ejecutar los planes de
formación mientras que se da seguimiento al presupuesto y gastos de formación.
Los módulos de Planes de Carreras y Planes de sucesiones permiten desarrollar
los planes de carreras, identificando las posibilidades de carrera por empleado, posición
o puesto, e identificar posibles sucesores para cubrir las posiciones clave.
Una de las categorías de costos más importantes en Recursos Humanos es el pago de
incentivos. Se puede diseñar el sistema de compensación incluyendo múltiples
componentes de pago, compensación variable y beneficios.
1.6.2. Ventajas
Las herramientas de desarrollo de PeopleSoft permiten hacer modificaciones con
relativa facilidad, lo que permite hacer adaptaciones o incluso desarrollar
funcionalidades completas que estén integradas con la aplicación.
PeopleSoft puede ejecutarse sobre distintas bases de datos (SQL Server, DB2, Oracle)
y con distintos servidores web. Cada empresa puede elegir la arquitectura más
adecuada según su presupuesto e infraestructura actual.
32
En cuanto a los datos, una característica importante es que todos los movimientos
relevantes en la historia de los empleados, o en la parametría de la aplicación, están
registrados por sucesos que se distinguen por la fecha en la que han ocurrido. Este
concepto se conoce como “Fecha Efectiva”, que es la fecha a partir de la cual aplica
una modificación. Esta característica permite, además de tener el registro histórico de
los sucesos, conocer qué atributos estaban activos en el momento del evento
determinado y qué atributos se harán efectivos en el futuro como cambios de puesto o
de salario. Esto es especialmente útil si tomamos en cuenta que no todos los elementos
de la empresa varían al mismo tiempo.
Con respecto a otras herramientas, una ventaja importante es la facilidad con la que se
pueden publicar las funcionalidades de autoservicio, integrar flujos de aprobación y, en
caso de que aplique, afectar a las informaciones correspondientes en la base de datos.
Las funcionalidades de autoservicio son uno de los puntos de palanca de la aplicación,
puesto que con poco esfuerzo se logra un gran impacto en la organización, permitiendo
que se conozcan y capitalicen los esfuerzos de mantenimiento de la aplicación.
Según la página de Internet de Oracle, que cita los estudios realizados por
CedarCrestone 2005 y 2006 “Workforce Technologies and Service Delivery Approaches
Survey” y “ROI Studies”, en promedio, las funcionalidades de autoservicio pueden llevar
a los siguientes ahorros:
Proceso de Negocio Costo Manual Costo de Autoservicio Ahorro
Inscripción en Beneficios $30.06 USD $4.59 USD 85%
Inscripción en Formación $9.58 USD $2.31 USD 76%
Cambio de Dirección Particular $1.58 USD $.36 USD 78%
Aplicar a un puesto $11.55 USD $6.09 USD 47%
Solicitar Cambio Salarial $4.20 USD $1.53 USD 64%
Aprobación de Promoción $3.38 USD $.87 USD 74%
Creación de Petición de Puesto $29.89 USD $9.36 USD 69%
Figura 5. Beneficios esperados de la implementación de funcionalidades de autoservicio en
PeopleSoft.
33
1.6.3. Desventajas
Aunque, según apuntábamos en el apartado anterior, es relativamente sencillo hacer
modificaciones en la aplicación, el soporte que Oracle da al producto se ve castigado
cuando se han hecho modificaciones al estándar. No entran en el soporte
funcionalidades que hayan sido modificadas, pero también es difícil conseguir apoyo
para la solución de temas que no hayan sido tocados, si quedan “cerca” de código
modificado.
El servicio de solución de problemas para aquéllas funcionalidades que no se hayan
tocado, no es muy eficiente. Y a menos de que alguien haya tenido el mismo problema
con anterioridad, suelen pasar muchos meses hasta que Oracle entrega la solución.
Normalmente, las empresas que implementan PeopleSoft cuentan con un equipo propio
y/o de consultores primero para la implementación y, posteriormente, para el soporte,
atención de incidencias y evolutivos. En España, es difícil estructurar un equipo que
tenga suficiente conocimiento y experiencia y, normalmente, son recursos caros, siendo
uno de los principales elementos de costo en el presupuesto del proyecto.
En cuanto a las herramientas, aunque en el producto se promocionan excelentes
herramientas de informes y análisis, este es uno de los puntos débiles de la
herramienta. Hay pocos informes on-line, muchos se tienen que ejecutar en proceso
batch, dificultando que usuarios en el esquema de autoservicio puedan acceder a ellos.
Una solución común es desarrollar los informes requeridos directamente en pantalla o
llamando a funciones HTML.
1.7. Estadísticas
Forrester (2006) hizo un estudio sobre proveedores de sistemas de gestión de
Recursos Humanos (HRMS – Human Resources Management System), evaluando 92
criterios, tanto para el mercado de empresas multinacionales, como para el mercado de
Estados Unidos. Del estudio, se concluye que SAP y Oracle (con los productos e-
Business Suite y PeopleSoft) son claramente los líderes para empresas
multinacionales. Para compañías de Estados Unidos, con requerimientos mínimos de
34
personal internacional, los líderes son Ultimate Software y Lawson. Una tendencia
notable, especialmente en el mercado medio, es la creciente aceptación de los
esquemas Software-as-a-service o SaaS (el software como servicio), que es el
esquema principal de Ultimate Software, así como de Automatic Data Processing (ADP)
y Employease.
Según Manning (2007), el mercado del software de Gestión del Capital Humano está
creciendo más del doble de rápido que el mercado de aplicaciones de empresa en total.
Ellos esperan que pase del límite de 10 billones de dólares en 5 años (hasta 2012),
conforme los cambios fundamentales en el mercado de trabajo global demanda más y
más que las compañías inviertan en sistemas, en sus empleados y en las mejoras de
negocio relacionadas con el personal.
Según Manning (2008), con el continuo crecimiento del mercado del software de
Gestión del Capital Humano (HCM – Human Capital Management), AMR Research
hace una proyección de expansión en los próximos 5 años al 12%. Las compañías que
están automatizando los procesos de negocio de HCM más estratégicos que son las
áreas de Adquisición de Personal y Evaluación así como aquéllas que emplean el
modelo de SaaS (Software as a Service) son las experimentan el mayor crecimiento.
35
CAPÍTULO 2. EMPRESA OBJETIVO: CORPORATIVO BANCARIO
2.1. Introducción
En este capítulo describiremos nuestra empresa objetivo y hablaremos de las razones
que nos han llevado a elegir este sector para nuestro estudio. Haremos una revisión de
los hechos históricos entre los que han surgido estas empresas. Describiremos la
evolución tecnológica que se ha vivido en todos sus procesos de negocio. Referiremos
la expansión internacional del sector bancario, en específico hacia América Latina para
los bancos españoles, y trataremos sobre cómo esta expansión influye en las
necesidades de tecnología del sector.
2.2. ¿Por qué un Corporativo Bancario?
En el capítulo anterior hablamos sobre los ERPs y se hizo una revisión general de los
proyectos de implementación. Hemos podido ver que un proyecto de estos es muy caro
y requiere un gran esfuerzo por parte de la organización. Sólo empresas con una sólida
base, amplio capital y gran crecimiento se pueden aventurar a adentrarse en este reto.
Tal como indica Castells (1986), el sector del automóvil, entre los sectores industriales,
y la banca, entre los sectores de servicios, son las dos ramas de actividad de mayor
nivel de utilización de las nuevas tecnologías. La banca juega el papel piloto de
introductor de nuevas tecnologías en el sector servicios.
Históricamente, las instituciones bancarias y financieras son las que, a nivel mundial,
revolucionan el tratamiento de la información en los servicios con base en la
introducción masiva de tratamiento informático, la conexión de ordenadores y
terminales mediante telecomunicaciones y la automatización de numerosos servicios,
tales como cajeros automáticos, tarjetas de crédito, banca a distancia.
En España, el sector bancario es uno de los principales clientes de los proveedores de
ERPs. PeopleSoft está implementado en los principales bancos: Banco Santander
36
Central Hispano (BSCH), Banco Bilbao Vizcaya Argentaria (BBVA), Banco Español de
Crédito (BANESTO), Caja Madrid, entre otros.
Nuestra experiencia de trabajo nos ha llevado a participar en varios de estos proyectos
y hemos conocido de primera mano las necesidades y las problemáticas en el sector.
Asimismo, nuestra experiencia en otros sectores con proyectos similares nos ha llevado
a confirmar que estos proyectos son representativos de los proyectos de
implementación de PeopleSoft y la experiencia se puede extrapolar a cualquier otro
sector.
2.3. Informatización de los procesos
Como se ha indicado, el sector bancario es punta de flecha en los avances tecnológicos
para el sector servicios. Como comenta Castells (1986), ya en el año 1975 el consumo
de Telecomunicaciones del sector Bancario representaba el 12,53% del total, mientras
que su peso en el PIB era del 2,24%. En el año 1983, este sector gastó por cada
empleado un total de 66,026.90 pesetas en transmisión de datos cuando la media
nacional era 2,532.90 pesetas para ese mismo año.
Entre 1980 a 1984 se produjo un proceso creciente de informatización de la Banca y,
aún más, en las cajas de ahorros. En esos años, el banco Santander acrecentó sus
gastos en informática un 269%, el Banco de Vizcaya un 209% y Caja Madrid un 300%.
Castells (1986), comentaba que:
“En suma el proceso de informatización de la banca y las cajas de ahorro es un proceso
que responde a la necesidad de adaptación a un nuevo medio tecnológico, que
incrementa considerablemente la productividad física del trabajo y que está cambiando
el tipo de servicios financieros y su forma de oferta al público. Sin embargo, los efectos
de las nuevas tecnologías sobre la rentabilidad y competitividad de las empresas y
sobre el empleo, depende de una estructura de factores mucho más amplia. El
complejo telecomunicaciones-Informática es el instrumento de trabajo indispensable de
las instituciones financieras, pero no puede salvarlas de sus errores de gestión o de su
inadecuado dimensionamiento. En cambio, cuando se utiliza en una dinámica
37
empresarial, contribuye de forma importante a la productividad y rentabilidad y,
eventualmente, a la generación de empleado, en buena parte de mayor nivel de
cualificación.
[….] Así como las nuevas tecnologías no son destructoras de empleo de por sí,
tampoco garantizan mejores resultados económicos por su sola introducción en una
empresa. De hecho, constituyen un desafío a la iniciativa empresarial, en la medida en
que su utilización amplifica considerablemente los aciertos, pero también los errores, de
la gestión.”
2.4. Presencia en Latinoamérica
Describiremos con las palabras de los González (2007), el proceso de expansión de
BBVA a Latinoamérica:
“Identidad de claves culturales y peculiaridades del mercado hispanoamericano hacen
que ésta se considerara el área con mejores perspectivas para orientar hacia ella la
nueva expansión del Grupo. América Latina, alberga un mercado potencial de más de
cuatrocientos millones de personas. Sus sistemas financieros representaban un
moderado grado de desarrollo, con baja eficiencia, retardo tecnológico y práctica
ausencia de entidades financieras multinacionales. Grandes masas de población
quedaban fuera de los circuitos financieros, situados al margen de los reducidos
estratos de la alta renta partícipes de la limitada bancarización del sistema. Tal era la
razón justificativa del inicio de un proceso expansivo que desembocaría en la actual
configuración del BBVA en Latinoamérica.
Tres han sido las etapas recorridas por el grupo en su proceso de implantación y
expansión latinoamericana. La primera va desde 1995 hasta 1998. Es la etapa de
grandes adquisiciones y construcción de franquicias. La segunda se extiende desde
1999 hasta el año 2003. Es ésta una etapa de adaptación a la realidad de cada
mercado, en la que el grupo se dota de la diversidad necesaria para ajustarse a las
peculiaridades de cada territorio. Es, además una fase que coincide con una época de
crisis económica en gran parte del continente. Finalmente, la tercera etapa se inscribe
38
en los años transcurridos desde 2004 hasta nuestros días. Esta fase bien puede
caracterizarse como una etapa de crecimiento, al hilo de la recuperación general de las
economías latinoamericanas.
Es llamativo el número de negocios bancarios, de pensiones y seguros que gestiona en
la actualidad el área de América del Sur dentro del grupo. Nada menos que once países
constituyen los dominios donde BBVA gestiona intereses de todo tipo (Argentina,
Bolivia, Chile, Colombia, Ecuador, Panamá, Paraguay, Perú, República Dominicana,
Uruguay y Venezuela). Y esto sin contar el negocio de previsión y seguros en México.
Todo lo cual se canaliza a través de ocho entidades bancarias, siete compañías
gestoras de fondos de pensiones y once sociedades de seguros. Concretamente, el
área de América del Sur gestionaba en marzo de 2007 nada menos que 66,546
millones de euros de recursos de clientes (14% del total administrado por el Grupo
BBVA). Disponía de 1,651 oficinas (22% del total del Grupo) y empleaba una plantilla de
28,641 personas (28% del total). Consecuencia natural de tan amplia y diversificada
implantación es que en los nueve primeros meses del año 2007 el área aportó al Grupo
BBVA un beneficio de 492 millones de euros”.
En cuanto a Banco Santander, tienen su expansión a partir del año 2000, en que se
incorporan al Grupo, Banespa en Brasil, Grupo Serfín en México y Banco Santiago en
Chile. Con ello se afianza la posición del Grupo como primera franquicia financiera en
Latinoamérica.
2.5. Importancia de la expansión
En este apartado veremos las cifras que demuestran el impacto de las áreas de negocio
de Latinoamérica en los resultados de BSCH y BBVA.
En 2000, después de haber hecho las adquisiciones más representativas, los grandes
bancos presentaron resultados en España y las cifras fueron impactantes. Después de
que BBVA mostrara un incremento de beneficios del 27,9%, BSCH publicó unas cifras
que arrojan un beneficio neto atribuible en 2000 de 375.000 millones de pesetas (2.253
39
millones de euros), lo que significaba un incremento respecto al ejercicio de 1999 del
43%.
En los resultados de 2008, presentados en febrero de 2009, se muestran las siguientes
cifras:
Beneficios de Santander en 2008:
Las utilidades del BSCH subieron un 10.4% en el 2008 (2,945 millones de euros en
utilidades netas). En estas gráficas podemos verificar que Latinoamérica representa el
32% del beneficio atribuido del grupo, y el 20% del resultado antes de impuestos.
Figura 6. BSCH - Distribución de beneficios por segmentos geográficos y de Negocio.
(Fuente: https://www.bancosantander.es)
Beneficios BBVA en 2008:
En esta tabla vemos que México y América del Sur representan el 48% del margen de
explotación del grupo y el 53% del beneficio atribuido.
40
Figura 7. BBVA – Margen de explotación y beneficio atribuido por áreas de negocio. (Fuente:
http://www.bbva.com)
2.6. Área de Recursos Humanos
Al tratarse de corporativos con expansión internacional, encontramos normalmente un
esquema de unidades de negocio o filiales, coordinadas por un área holding. Esta
figura, se asegura de que las distintas unidades caminan hacia los objetivos de la
empresa. Un área de Recursos Humanos Holding, establece procedimientos comunes,
define los lineamientos de las políticas retributivas, el perfil básico de empleados,
estructuración de la plantilla o headcount, estrategia de estructura, y se asegura de que
se cumpla.
Para poder expandir un sistema de control, es crucial que antes existan procedimientos
comunes y lineamientos de actuación para cada una de las filiales. Hay que tomar en
cuenta que un sistema “automatiza” procedimientos existentes, y no se puede
automatizar lo que no existe, o peor aún, si se automatiza el error se llega más
rápidamente al caos.
En el esquema que planteamos, el área de Holding debe ser el promotor del proyecto,
pues es el área que tiene la suficiente autoridad y responsabilidad para asegurarse de
que el resto cumplan con sus compromisos, y sigan la visión establecida.
Adicionalmente a este aspecto básico, el Área Holding es quien finalmente explotará los
datos registrados por las distintas unidades. Independientemente del beneficio local
41
obtenido por cada filial o unidad, el usuario final y total de la información registrada es el
holding. Podrá disponer en línea de la información de todo el grupo, sin necesidad de
hacer solicitudes oficiales de informes, con el consiguiente papeleo y riesgo existente
en la demora de la información. Este factor agrega mucho valor, pues no hay que
olvidar que hablamos de decenas de miles de empleados distribuidos geográficamente
en el mundo. Así, el hecho de poder acceder a información estadística global y datos
consolidados, le permitirá tomar mejores decisiones, orientar mejor la estrategia y
corregir posibles desviaciones en las distintas unidades.
A pesar de todo, hay que tener en cuenta que cada filial o unidad es usuaria de la
aplicación. Y como tal, debe poder resolver sus necesidades. Dentro de un esquema
global, y en el ámbito de las políticas y procedimientos corporativos, cada unidad debe
poder atender sus requerimientos legales y normativos, y cubrir aquellas otras
necesidades derivadas de la cultura o costumbres.
El principal requerimiento de cada filial será poder pagar correctamente la nómina, y
reflejar los cambios organizativos, estructurales, salariales, nuevas incorporaciones,
etc., adecuadamente en el pago a empleados. Otro aspecto muy relevante, originado en
necesidades locales, es la atención al empleado y el autoservicio relacionado. Cada
empleado debe poder resolver sus dudas, gestionar sus cambios, y asegurar que su
información esté actualizada correctamente, ya sea vía autoservicios o con contacto
directo con el área de Recursos Humanos.
42
CAPÍTULO 3. GESTIÓN DEL PROYECTO
3.1. Introducción
En este apartado hablaremos de la gestión del proyecto citando la visión del Project
Management Institute (PMI) y lo que refleja en el PMBOK Guide (Project Management
Body of Knowledge Guide), y en cada elemento describiremos la visión desde el punto
de vista del proyecto que nos ocupa.
La Guía de los Fundamentos de la Dirección de Proyectos (PMBOK Guide) es un
estándar desarrollado por el PMI, reconocido en todo el mundo como un estándar para
gestionar proyectos en el mercado de hoy. En la actualidad la mayoría de los Modelos
de Gestión de Proyectos tiene sus bases en este estándar.
El PMBOK comprende un conjunto de conocimientos de la dirección de proyectos y de
prácticas tradicionalmente aceptadas dentro de la profesión. Su objetivo es proporcionar
referencias básicas acerca de la dirección de proyectos, ya que, según el PMI, es una
profesión relativamente joven y existe cierta discrepancia en la terminología utilizada.
El PMBOK describe los procesos básicos de la dirección de proyectos a través de lo
que ha denominado “las nueve áreas del conocimiento”. Las nueve áreas del
conocimiento propuestas son:
Gestión de la Integración del Proyecto
Gestión del Alcance del Proyecto
Gestión de Tiempos del Proyecto
Gestión de Costos del Proyecto
Gestión de la Calidad del Proyecto
Gestión de los Recursos Humanos del Proyecto
Gestión de las Comunicaciones del Proyecto
Gestión de Riesgos del Proyecto
Gestión de las Adquisiciones del Proyecto.
43
Como se puede observar, se integran diversas áreas, pues desde el punto de vista de
la dirección del proyecto se tienen que tener en cuenta todos los elementos que entran
en juego durante el ciclo de vida. Esta visión se aproxima a la de un director general en
una empresa, su visión es más amplia que la del proyecto en sí.
Es crucial el esfuerzo integrador que hay desde esta perspectiva, pues cada uno de los
elementos, procesos y áreas que componen al proyecto actúan como un sistema,
donde las acciones o falta de ellas en un área específica repercuten en las demás. Así,
adicionalmente de cuidar cada área, es necesario poner atención en sus interacciones.
A continuación describiremos cada área del conocimiento, y cómo se reflejan en el
proyecto de nuestro interés.
3.2. Gestión de Integración del Proyecto
Aquí se incluyen los procesos requeridos para asegurar que los diferentes elementos de
los proyectos sean adecuadamente coordinados.
Como hemos comentado, un proyecto es un sistema cuyas áreas están
interrelacionadas. Por esto, la integración resulta importante pues es necesario
asegurar esta relación y nivelar el efecto que se genera en cada punto del proyecto por
el comportamiento de otro.
En proyectos tan grandes como el nuestro, es necesario establecer por metodología
controles y documentación para poder hacer este seguimiento. Hay que tener en cuenta
que la información necesaria para controlar la integración del proyecto se genera en
todos los puntos del proyecto, así que hay que poder recopilarla, ordenarla y
posteriormente analizarla para generar las acciones necesarias.
Los procesos principales de esta área son:
3.2.1. Desarrollo del plan del proyecto
Su objetivo es integrar y coordinar los planes de proyecto para crear un documento
consistente y coherente.
44
Se deberán integrar los planes de las áreas de sistemas corporativas y locales de cada
país, de las áreas de estructuras y recursos humanos, calendarios de formación,
comunicación corporativa, nómina y administración, tecnología e infraestructura, etc.
Cada área deberá generar su propia calendarización para posteriormente poder
coordinar los puntos críticos o hitos.
En este proyecto es especialmente importante capitalizar la experiencia de otras
implementaciones semejantes en otras empresas, o de sistemas semejantes en la
misma empresa. Es necesario tener en cuenta cómo se comporta la organización frente
a proyectos de esta índole, y qué problemas o eventualidades nos pueden venir dados
por la propia naturaleza del proyecto.
Para definir el marco dentro del que podemos actuar, se deberán de tomar en cuenta
las políticas organizacionales que pueden tener origen interno (principios, cultura,
procedimientos) o externos (legales), por lo que es imperativo tenerlas en cuenta. Una
política organizacional que no se haya analizado a tiempo puede generar graves
problemas de retraso o incluso la cancelación del propio proyecto. Por otro lado, en
nuestro proyecto las políticas organizacionales son las que dan pie a poder estandarizar
procedimientos, y por tanto iniciar este proyecto. Serán la guía de actuación que se
seguirá para coordinar las acciones y la orientación del proyecto. Un último aspecto a
tener en cuenta, es que en organizaciones tan grandes como las bancarias, las políticas
están muy arraigadas en todas las áreas en lo que comúnmente denominamos
“burocracia”. Se deben anticipar todas las aprobaciones necesarias, para que no sean
causa de bloqueo o retraso del proyecto.
Adicional al marco que nos definen las políticas organizacionales, tendremos otro tipo
de restricciones (tiempos, recursos, materiales, criterios, etc.) que se deben tener en
cuenta, y que definirán nuestro plan de proyecto. En un ejemplo básico, si tenemos una
restricción en tiempo del tipo “el proyecto tiene que estar finalizado en una fecha
específica”, seguramente deberemos pedir más recursos y/o más dinero que si
tuviéramos más tiempo. En nuestro proyecto es necesario tomar en cuenta además
restricciones generadas por la distancia y diferencia cultural.
45
La planificación se genera esperando que se den ciertas condiciones, o considerando
que en determinado momento nos encontraremos con una situación específica. Es
imprescindible listar todos los supuestos, pues el incumplimiento de cualquiera de ellos
puede llevar a desviaciones en el proyecto. En nuestro proyecto deberemos prestar
especial atención a las condiciones que esperamos encontrar en el país de destino, a
todos los niveles: procedimientos, tecnología e infraestructura, equipo de trabajo, etc.
En el supuesto de que sea una multinacional, y se tenga la previsión de repetir este
proyecto para todos los países en los que se tenga presencia, se recomienda generar
una “plantilla” de plan de proyecto, que, con poca personalización, sea válida para todos
los países.
Se puede aportar documentación adicional que sustente el plan de proyecto.
Recomendamos generar Excel de control de listas de tareas específicas y repetitivas,
por ejemplo: preparación de entornos, preparación de aulas de formación, etc.
3.2.2. Ejecución del Plan del Proyecto
Llevar a cabo el plan del proyecto desarrollando las tareas que están incluidas en él. La
mayor parte del presupuesto del proyecto se consumirá llevando a cabo este proceso.
El producto del proyecto se crea aquí. En el capítulo “Proceso de Implementación”
describiremos qué tareas se deberán incluir en el plan.
Se debe monitorear constantemente el desempeño con respecto a lo definido en la
línea base para poder prevenir desviaciones y corregirlas en el momento oportuno. Se
deberán realizar previsiones periódicas del costo y plazo final para dar soporte a este
análisis.
Se deberán seguir acciones preventivas para reducir la probabilidad de consecuencias
potenciales de los riesgos. Para generarlas es necesario estar atento a los análisis de
desempeño del proyecto, y acordar medidas de acción con los involucrados.
Recomendamos aprovechar la experiencia de los miembros del equipo para visualizar
posibles influencias en el proyecto y poder generar medidas correctivas adecuadas.
46
Recurrir a la experiencia de los consultores contratados, y sumarla a los conocimientos
de la gente de la propia organización.
Se seguirán acciones correctivas reencaminar el proyecto y asegurarse que en el futuro
cumpla con el plan. Aunque es mejor no tener que llegar a este punto, surgen
situaciones en las que hay que corregir desviaciones. Una premisa que se debe seguir
es corregir cuanto antes. El tiempo que se deje transcurrir para corregir una desviación
incrementará las dificultades para solucionarlas.
Son necesarias habilidades como liderazgo, comunicación y negociación, son
esenciales para poder llevar a cabo un proyecto. En el apartado “Proceso de
Implementación” describiremos en cada fase a qué elementos es necesario prestar más
atención. Sin embargo, a lo largo de todo el proyecto una constante será la gestión de
la política. Organizaciones tan grandes tienen política de relaciones y trabajo muy
compleja y hay que dominarla para poder salir exitoso.
Asimismo, es necesario que el equipo del proyecto tenga habilidades y conocimientos
específicos de PeopleSoft Recursos Humanos y del tema específico que tenga que
tratar. Si al inicio del proyecto no toda la gente cuenta con el conocimiento se pueden
aplicar cursos de formación, pero recomendamos ampliamente contar con un grupo de
expertos. Hemos visto varios proyectos en que todos los miembros eran novatos en su
área y tienen una tasa de fracaso muy alta.
Debe existir un procedimiento de autorizaciones, que es un procedimiento formal de
sanción del proyecto encaminado a asegurar que el trabajo se hace en el momento
adecuado y en la secuencia adecuada. Se propone principalmente los esquemas de
autorización de hitos. Limitar el inicio de un hito subsecuente a la autorización del hito
previo. De esta forma se logra registrar el avance realizado y se garantiza que se sigue
la secuencia establecida en el proyecto. Eso sí, es necesario tener cuidado en no caer
en burocracia que no aporte valor. Recomendamos establecer un mecanismo de
delegación de autorizaciones: que los hitos más pequeños los puedan autorizar niveles
medios en el proyecto y los hitos más importantes los niveles superiores. Asimismo, es
47
necesario aplicar el sentido común: establecer documentación que sea ágil y fácil de
generar, por ejemplo, notificaciones de correo electrónico.
Se deben plantear reuniones de seguimiento. Son reuniones periódicas de intercambio
de información del proyecto. Tomando en cuenta la estructura de las empresas
bancarias, deberá haber reuniones a distintos niveles:
Directivas o de comité que, con baja frecuencia y duración, son más ejecutivas y van
encaminadas a reportar el avance y solicitar apoyo directivo en los casos más críticos o
que ha sido necesario escalar. Un ejemplo de frecuencia y duración tipo, para un
proyecto de 6 meses de duración se realizan reuniones de comité cada 3 o 4 semanas
o antes si surge algún tema crítico.
De control de proyecto. Se recomienda llevarlas a cabo semanalmente. Deberá asistir el
líder de proyecto y los principales responsables de cada área del proyecto conforme se
haya establecido el organigrama. Prestar especial atención a no entrar en detalle
excesivo: estas reuniones no son para solución de temas técnicos sino para
seguimiento del proyecto. En caso de ser necesario se pueden establecer y programar
reuniones para tratamiento de detalle con los miembros del equipo necesarios. Se debe
mantener una agenda e intentar apegarse a una duración estimada (normalmente entre
1 y 2 horas). Si se extiende en demasía pierde efectividad y comenzará a haber
ausentismo de personas que posiblemente sean críticas para ciertos temas.
De detalle: para tareas específicas. No es necesario que se reúna todo el equipo de
proyecto, sino solamente aquéllos involucrados con el tema a tratar.
Se debe aprovechar la infraestructura de estas organizaciones a todos los niveles,
incluyendo los procedimientos preestablecidos que pueden resultar útiles para el
desarrollo del proyecto.
Como producto de este trabajo tendremos los entregables, que son los resultados de
las actividades desarrolladas durante el proyecto. Se incluyen entregables tangibles e
intangibles, y deben estar relacionados en el plan de proyecto para poder medir el
avance. Recomendamos no dejar largos periodos de tiempo sin entregables. Para los
48
entregables que requieren mucho esfuerzo y tiempo en generarse, hacer entregas
parciales que se puedan medir.
3.2.3. Control Integrado de los Cambios
Involucra 3 aspectos principales: asegurarse que los cambios están consensuados y
acordados en el equipo, determinar que un cambio ha ocurrido y gestionar los cambios
cuando y conforme ocurren. El control integrado de los cambios requiere:
Mantener la integridad de las líneas base para la medición del desempeño
Asegurarse que los cambios al alcance del producto se reflejan en el alcance del
proyecto.
Coordinar cambios entre las distintas áreas de conocimiento (programa, costo,
riesgo, calidad y recursos).
Se debe establecer un sistema de control de cambios, que es el conjunto de
procedimientos formales y documentados que definen cómo se monitorizará y evaluará
el desempeño del proyecto, incluye los pasos por los que se pueden modificar los
documentos oficiales del proyecto. Incluye el papeleo, sistemas de rastreo / trazabilidad,
procesos y niveles de aprobación necesarios para autorizar los cambios. En las
organizaciones bancarias seguramente existe un proceso establecido por la propia
organización para controlar los cambios en los proyectos de sistemas. Es necesario
tomar en cuenta el impacto del cambio para valorar a qué nivel se debe aprobar. Una
vez aprobado, se deberán registrar los cambios en los documentos pertinentes, para
evitar errores en cuanto a la interpretación de la información del proyecto.
Raramente los proyectos se desarrollan conforme al plan. Los cambios pueden requerir
modificaciones a las estimaciones de costos, modificar la secuencia de actividades,
calendarios, necesidades de recursos, alternativas de acción ante los riesgos, o
cualquier otro ajuste al plan. Es necesario mantener actualizado el plan y comunicarlo a
todos los implicados. Nos hemos encontrado en repetidas ocasiones que los sistemas
de cambios en las organizaciones bancarias castigan los cambios y los limitan. Sin
embargo, si estos tienen que ocurrir y se han aprobado, se deben reflejar en la
49
documentación y planificación, y comunicarlos. Hay que recordar que es posible que
sea necesario seguir largos procedimientos para gestionar los cambios, así que es
mejor comenzar cuanto antes para evitar o minimizar los impactos en la planificación.
Las causas de desviaciones, las razones detrás de las acciones correctivas elegidas, y
otro tipo de lecciones aprendidas se deben documentar, para servir de base de datos
de historia documentada y que sea antecedente para acciones dentro de éste u otros
proyectos semejantes. Este es uno de los aspectos más valiosos y con mayor impacto
en la optimización del rendimiento de los proyectos: la capitalización del aprendizaje. En
un esquema con múltiples rollouts, la experiencia del primero debe servir de base de las
cosas que hay que hacer y las que no hay que hacer en los siguientes proyectos. Esto
ayuda a optimizar el costo, el tiempo y los recursos invertidos a la vez que se mejora el
resultado del proyecto. Es decir, nos volvemos más eficientes.
3.3. Gestión del Alcance del Proyecto
Aquí se incluyen los procesos requeridos para asegurar que el proyecto incluye todo el
trabajo necesario, y sólo el trabajo necesario, para completar el proyecto exitosamente.
Principalmente se refiere a definir y controlar lo que está incluido y lo que no, en el
proyecto.
Los procesos principales incluidos son:
Inicio
Planificación del Alcance
Definición del Alcance
Verificación del Alcance
Control de Cambios del Alcance
La finalización del alcance del proyecto se controla a través del plan de proyecto, pero
la finalización del alcance del producto se mide a través de los requerimientos del
producto. Ambos tipos de alcance se deben integrar bien para asegurar que el trabajo
del proyecto generará adecuadamente el producto especificado.
50
3.3.1. Inicio
Es el proceso de autorización formal de un nuevo proyecto o de que un nuevo proyecto
deba seguir a la siguiente fase. Este inicio formal relaciona el proyecto con el trabajo
actual de la organización.
Se seguirán diferentes métodos de selección de proyecto, que se utilizan para medir el
valor o nivel de atracción al “dueño” del proyecto. Se deben considerar los criterios de
decisión y medios para calcular el valor en situaciones de incertidumbre. También aplica
a las alternativas para desarrollo del proyecto. En nuestro caso es necesario tomar en
cuenta las distintas dimensiones del proyecto: tecnología e infraestructura,
comunicaciones, áreas de recursos humanos en corporativo y en el país destino, áreas
de sistemas tanto en corporativo como en país destino, etc. Como explicaremos en el
apartado de iniciativa, esto es importante pues definirá el modelo de trabajo a seguir.
Para valorar los criterios de decisión. Es necesario contar con asesoría de personal
experto, tanto de dentro de la organización como de empresas externas. Sin embargo
recomendamos que la decisión final siempre se mantenga dentro de la organización.
De este trabajo se genera un acta del proyecto. Es un documento que autoriza
formalmente el proyecto. Debe incluir o al menos hacer referencia a otros documentos
cruciales del proyecto: definición de requerimientos y descripción del producto. Debe
ser emitido por un director externo al proyecto y con suficiente nivel de autoridad para
aplicar recursos de la organización a las actividades del proyecto. En nuestro proyecto
deberá ir firmada por el director de Recursos Humanos Corporativo, y con el visto
bueno del director de Recursos Humanos del país destino.
El líder del proyecto se debe identificar antes del inicio del proyecto, por lo que el
momento de generación de la iniciativa es buen momento. El rol que desempeñará en
nuestro proyecto es mucho más completo que en otros proyectos de sistemas, pues
deberá coordinar distintas áreas de la organización, por lo que deberá representar
suficiente autoridad como para movilizar situaciones bloqueadas. En proyectos muy
grandes puede llamarse al rol “director” de proyecto, y que tenga a su cargo líderes de
51
áreas del proyecto. Sin embargo siempre deberá existir un punto de unión en todas las
áreas y con posibilidad de acción y decisión en los momentos críticos.
3.3.2. Planificación del Alcance
Es el proceso de elaborar y documentar progresivamente el trabajo del proyecto
(alcance del proyecto) que produce el producto del proyecto. La definición del alcance,
resultante de este proceso, forma la base de acuerdo entre el equipo de proyecto y el
cliente identificando los objetivos del proyecto y sus entregables. Se pueden hacer
varios documentos de definición de alcance con distintos niveles de detalle
dependiendo del punto de descomposición del trabajo en el que nos encontremos.
Se deberá hacer un análisis del producto. Implica desarrollar un mejor entendimiento
del producto del proyecto. En el apartado Fase de Iniciativa describiremos cómo
definirlo en un primer nivel, y en el apartado Fase de Análisis describiremos sobre
cómo llevarlo a cabo a profundidad.
En el análisis costo-beneficio se deben estimar los costos y beneficios tangibles e
intangibles de distintas alternativas de proyecto para poder evaluar cuál de las
alternativas podría ser más deseable. En nuestro proyecto deberemos tener en cuenta
distintos niveles de valoración como por ejemplo, el impacto en el corporativo y a nivel
local en cada país, costos de infraestructura global y local, etc.
Se identificarán todas las posibles alternativas para llevar a cabo el proyecto. También
describiremos las distintas alternativas que se pueden seguir en nuestro proyecto
específico.
Como producto de este proceso tenemos la definición del alcance, que provee una base
documentada para futura toma de decisiones de proyecto y para conformar o
desarrollar un entendimiento del proyecto unificado entre todos los grupos de interés.
Conforme el proyecto progresa, la definición del alcance puede ser revisada o refinada
para reflejar cambios aprobados sobre el alcance del proyecto. Deberá incluir o hacer
referencia a: justificación, producto, entregables y objetivos del proyecto.
Recomendamos que la versión final de este documento esté aprobada y revisada por
52
las áreas involucradas: Holding de RH, RH local, sistemas, y cualquier otra área que
pueda resultar afectada por el proyecto.
Asimismo, en el plan de gestión del alcance se deberá describir cómo se gestionará el
alcance del proyecto y cómo se integrarán los cambios identificados. Se deberá incluir
también una valoración de la estabilidad esperada en el alcance, y una clara
descripción de cómo se gestionarán los cambios identificados. Nuestra recomendación
es definir que como norma no se aceptan cambios al alcance, a menos de que se corra
el riesgo de no cumplir algún requerimiento legal. Asimismo que cualquier cambio
detectado se debe aprobar por el comité directivo del proyecto. Esta definición limita los
cambios de alcance, sobre todo en momentos en que hay mucha tentación de pedir
muchas modificaciones. Si las peticiones se escalan hacia arriba (a nivel directivo) será
más probable que sólo pasen aquéllas que de verdad son necesarias.
3.3.3. Definición del Alcance
Implica subdividir los mayores entregables del proyecto en componentes más pequeños
y manejables para:
Mejorar la exactitud de las estimaciones de costo, tiempo y recursos.
Definir una línea base para mediciones y control del desempeño
Facilitar y clarificar las asignaciones de responsabilidades.
Una adecuada definición del alcance es un factor crítico de éxito del proyecto. Cuando
no se ha hecho adecuadamente, seguramente los costos finales del proyecto serán
mayores porque los inevitables cambios de alcance romperán continuamente el ritmo
del proyecto, ocasionarán reprocesamiento, aumentarán el tiempo del proyecto y
disminuirán la productividad y moral del equipo.
Se deben revisar las salidas de los procesos de otras áreas de conocimiento para
valorar posibles impactos en la definición del alcance del proyecto. Aquí es crítico incluir
otros proyectos de tecnología o recursos humanos en la organización. Por ejemplo, nos
hemos encontrado con que por política de la organización todas las aplicaciones de
autoservicio se deben incorporar en la intranet corporativa y funcionar con “single sing-
53
on”. En un proyecto nos ocasionaron un retraso en el proyecto e incremento del costo
estimado original.
Se puede usar como base la Estructura de Descomposición de Trabajo (EDT) de un
proyecto previo, aunque se debe tomar en cuenta que cada proyecto es único y que por
tanto se deben incorporar las características específicas del nuestro.
Finalmente, tendremos nuestra propia, que será una agrupación de componentes del
proyecto desde el punto de vista de los entregables. El trabajo que esté fuera de la EDT
está fuera del alcance del proyecto. Si se detecta alguna actividad que deba estar fuera,
pero sea necesaria, se debe incluir como supuesto. Por ejemplo, la sustitución de las
computadoras obsoletas en las oficinas de red que no permiten el acceso a Internet o el
incremento de capacidad en las líneas de comunicaciones.
3.3.4. Verificación del Alcance
Es el proceso por el que se obtiene aceptación formal del alcance del proyecto por parte
de todos los involucrados. Requiere que se revisen los entregables y el trabajo
realizado para asegurarse de que se han completado correcta y satisfactoriamente.
Este proceso se distingue de la gestión de la calidad en que aquí se garantiza la
aceptación, y en la gestión de la calidad valora el grado excelencia del producto. Estos
procesos generalmente se ejecutan en paralelo para asegurar tanto la calidad, como la
aceptación.
Se deben conocer los resultados del trabajo, identificados por los entregables que se
han finalizado total o parcialmente. Se pueden establecer hitos de verificación conforme
se va avanzando con el proyecto y cada uno lo debe validar el equipo correspondiente.
Por ejemplo, la validación de la formación impartida, se verificará en cuanto se haya
finalizado por parte del o los responsables de las personas que han recibido la
formación.
Se debe disponer, para revisión, de los entregables que describen el producto. En
nuestro proyecto, esto se puede reflejar en 2 principales entregables: El manual de
54
aplicación (con descripción técnica del funcionamiento) y el manual de usuario (con el
uso que se dará a la aplicación).
Se llevarán a cabo mediciones, exámenes, y pruebas para determinar si los resultados
se corresponden con los requerimientos. Las pruebas son factor crítico de éxito. En el
siguiente capítulo describiremos todos los tipos de pruebas que se tienen que incluir
para la validación de nuestros entregables.
Al final deberá existir una aceptación formal. Es la documentación que especifique que
el cliente o el patrocinador (sponsor) del proyecto ha aceptado el producto del proyecto
y/o los principales entregables.
3.3.5. Control de Cambios del Alcance
Este proceso principalmente involucra: Establecer controles que permitan asegurar que
los cambios están consensuados y acordados, determinar que ha ocurrido un cambio y
gestionar los cambios cuando ocurran, y si ocurren.
Las solicitudes de cambio pueden surgir de distintas formas: verbalmente o por escrito,
directa o indirectamente, opcionales o por requerimientos legales. Un cambio puede
provocar la ampliación del alcance o permitir su disminución. Debe existir un
procedimiento completo de gestión de los cambios. En las organizaciones bancarias
seguramente existirá un procedimiento establecido por los estándares internos para
gestión y registro de estos cambios. En este caso, recomendamos seguir los
procedimientos estándares definidos, y hacerlos parte activa de la gestión del alcance
del proyecto.
Se debe seguir el control de cambios de alcance, que define los procedimientos por
medio de los cuales se puede cambiar el alcance del proyecto. Incluye el papeleo,
sistemas de seguimiento y rastreo, y niveles de aprobación necesarios para continuar
con los cambios. Este proceso está completamente integrado con el proceso de
integración de cambios descrito en apartados anteriores.
55
Finalmente, se tendrán los cambios de alcance. Es cualquier cambio que se haya hecho
al alcance definido y que está reflejado en el EDT. Normalmente es que los cambios
requieran ajustes al costo, tiempo, calidad o cualquier otro objetivo del proyecto. Estos
cambios deberán ser incluidos en las planificaciones y comunicados a todas las
personas involucradas en el proyecto.
3.4. Gestión de Tiempos de Proyecto
Aquí se incluyen todos los procesos requeridos para asegurar que el proyecto se
cumple en tiempo. Los principales procesos involucrados son:
Definición de las actividades
Definición de la secuencia de actividades
Estimación de la duración de las actividades
Desarrollo del calendario
Control del calendario
3.4.1. Definición de las Actividades
Implica identificar y documentar las actividades específicas que se tienen que llevar a
cabo para generar los entregables identificados dentro del alcance y en el EDT.
Deberemos hacer descomposición de las tareas. En un trabajo similar a la EDT
explicada en apartados anteriores, con la principal diferencia de que el mínimo nivel de
detalle contiene actividades y no entregables. La EDT del alcance y el detalle de
actividades se pueden hacer simultáneamente.
Se puede utilizar como plantilla la lista de actividades de algún proyecto semejante
previo. La intención es no empezar en blanco, ni intentar re-descubrir el hilo negro.
Siempre es mejor aprovechar experiencias previas para facilitar y mejorar el resultado
del trabajo en un proyecto posterior.
Como producto de este trabajo tendremos una lista de actividades, que debe incluir
toda la lista de actividades a llevar a cabo durante el proyecto. Se debe generar como
una extensión de la EDT para asegurarse de que está completa y que no incluye
56
actividades que no son necesarias dentro del alcance del proyecto. Las descripciones
deben ser lo suficientemente claras para que los miembros del equipo entiendan lo que
se debe hacer.
Se pueden detectar entregables adicionales como resultado del análisis de actividades,
y éstos se deberán integrar dentro de la EDT y comunicar al resto del equipo. En
nuestro caso más comúnmente se referirán a casuísticas específicas de los países,
pues los procedimientos corporativos son más conocidos por el equipo y la
organización, y regularmente hay menos experiencia en expansiones internacionales y
lo que implican.
3.4.2. Definición de la Secuencia de Actividades
Implica identificar y documentar la interacción lógica entre las actividades. Es crucial
identificar claramente las relaciones y precedencias, para posteriormente lograr generar
un calendario de trabajo más exacto y alcanzable.
Frecuentemente las características del producto afectan a la secuencia de actividades,
por lo que hay mantener en mente la descripción del producto para definir la secuencia.
En los proyectos de sistemas, será importante tomar en cuenta las cargas de datos,
interfaces, etc., pues seguramente tendrán impacto en la secuencia a definir.
También habrá que contemplar las dependencias obligatorias, que son aquéllas
dependencias inherentes al trabajo que se está haciendo. Por ejemplo, no se puede
probar lo que no está desarrollado o no se pueden enviar archivos si no están
establecidas las comunicaciones. Son las primeras a tener en cuenta. Normalmente una
fuente de dependencias obligatorias es la infraestructura tecnológica y los
procedimientos legales.
Las dependencias discrecionales son aquéllas definidas por el equipo de proyecto.
Normalmente se definen basados en las “best practices” o en aspectos poco usuales
pero característicos del proyecto. Por ejemplo, no se comenzará la fase de diseño hasta
no obtener la aprobación de la fase de análisis por parte de todos los involucrados. Otro
57
ejemplo podría ser, no se darán los cursos de formación de Selección hasta no haber
finalizado los de administración de personal.
Las dependencias externas se definen por la relación de actividades del proyecto con
tareas externas a él. En nuestro caso, un claro ejemplo de dependencia externa, es que
las computadoras de todos los empleados cumplan con requisitos mínimos para acceso
a Internet. No es parte del proyecto, pero tiene que estar resuelto para poder llevarlo a
cabo
Los hitos deben ser parte de la secuenciación de actividades para asegurarse que se
cumplen todas las tareas para cumplir el hito pues ayudan a validar que se han
contemplado todas las actividades.
Se puede seguir cualquiera de los siguientes métodos para la secuenciación de
actividades:
Método de Diagrama por Precedencias (DPP): Utiliza rectángulos (nodos) para
representar actividades, y las conecta con flechas para representar las dependencias.
Se pueden representar dependencias de fin-a-inicio, de inicio-a-fin, de inicio-a-inicio, de
fin-a-fin, etc. Esta es la técnica más utilizada.
Figura 8. Ejemplo de Diagrama por Precedencias
Método de Diagrama por Flechas (DPF): Usa flechas para representar las actividades
y las conecta en nodos para mostrar sus dependencias, aunque sólo contempla
dependencias de fin-a-inicio.
58
*La línea punteada es una actividad ficticia para representar una relación
Figura 9. Ejemplo de Diagrama por Flechas
Métodos de Diagramas Condicionales: Estos métodos permiten reflejar ciclos o
ramas condicionales, cosa que ninguno de los dos anteriores lo permite. Ejemplos
comunes de estos métodos son la técnica de Evaluación y Revisión Gráfica (PERT por
sus siglas en inglés) y los modelos de dinámica de sistemas. Los diagramas de PERT
se generan automáticamente en MS Project, por lo que recomendamos utilizar esta
herramienta para generarlo.
3.4.3. Estimación de la duración de las actividades
Es el proceso por el que se toma la información del alcance y los recursos, y se
calculan las duraciones para registrarlas dentro del calendario. Normalmente las
duraciones las establecen los miembros del equipo con más experiencia en las
actividades. Lo más común es que las duraciones vayan evolucionando y se rectifiquen
progresivamente de acuerdo a la calidad y cantidad de información. Por eso, las
estimaciones son progresivamente más exactas y con mejor calidad.
Posteriormente, para calcular cuántos días laborables se tardan las actividades, es
necesario tomar en cuenta los fines de semana y festivos. Por ejemplo, si un proceso
que tarda 16 horas se ejecuta el sábado, no consumirá jornadas laborables, sin
59
embargo, si se retrasa y hay que ejecutarlo entre semana consumirá una jornada
laborable (suponiendo que se puede seguir ejecutando por la noche).
La duración total del proyecto se puede derivar de la estimación de las actividades, sin
embargo es más adecuado obtenerla de la definición del calendario.
Se deben contemplar las restricciones y supuestos. Una restricción muy importante a
tener en cuenta en los proyectos de PS es que dos personas no pueden modificar a la
vez el mismo objeto. Así, desarrollos que vayan contra los mismos objetos se deberán
poner secuenciales. Unos de los supuestos más importantes en la estimación de
duraciones sobre los niveles de respuesta de la tecnología. Pueden afectar gravemente
a la duración de las tareas, cuando por ejemplo, una máquina tenga la mitad de
memoria que la acordada, y entonces tarde más en la ejecución de los procesos.
En cuanto a requerimiento de recursos, puede ser que dos personas asignadas a la
tarea tarden la mitad de tiempo que uno solo, pero hay que tener en cuenta que en las
actividades de programación esto no es necesariamente cierto. Hay que valorar
adecuadamente cuánto es el máximo de recursos que pueden participar en una tarea,
de forma que se optimice el tiempo que se tarde. Además, en proyectos de sistemas,
los recursos son normalmente caros y escasos. Así que posiblemente tengamos
limitación de recursos, y debamos estimar en función de los recursos disponibles.
Se deben contemplar las capacidades de todos los recursos involucrados: de sistemas,
usuarios locales, corporativos, etc. En el área de sistemas y desarrollo hay que tener en
cuenta la formación de los recursos que trabajarán. Si ya se conoce el equipo,
tendremos más facilidad de hacer estimaciones correctas. Si no se conoce el equipo,
recomendamos nunca valorar sobre el tiempo que tarde el más experto, sino sobre una
capacidad promedio. En el área de usuarios locales, además del número de usuarios
disponibles, hay que tener en cuenta que normalmente además del trabajo propio del
proyecto deberán seguir trabajando sobre su día a día. Así, será necesario solicitar
disponibilidad 100% en las etapas de análisis y pruebas, pero ser conscientes de que
quizás tengan disponibilidad 20% en otras etapas.
60
La aportación de la visión de personas experiencias es factor crítico para obtener
estimaciones que sean fiables y lo más precisas posibles. Se deben incluir tanto
personas con experiencia en proyectos dentro de la organización, como personas con
experiencia en proyectos semejantes en otras empresas.
Partiendo de duraciones para una parte específica de trabajo, se deriva el tiempo que
tardará una actividad en función del número de unidades de ese trabajo que se
requieran. Por ejemplo, desarrollar una nueva página tarda 8 horas, y el componente
tiene 5 páginas nuevas, la tarea se estima en 40 horas. Dependiendo del tipo de tarea
se deberán tomar en cuenta tareas de ensamblaje (que aumentan el tiempo total) o
ahorros en tiempo por las sinergias.
Se deberá valorar si se quiere incluir tiempo de reserva, coloquialmente es conocido
como “colchón”. El equipo puede decidir incorporar un tiempo de reserva para que las
contingencias que puedan surgir no afecten al plazo inicial del proyecto. Puede ser un
porcentaje del tiempo o una duración fija. Este tiempo debe quedar documentado en los
supuestos y restricciones. Sin embargo, el tiempo de reserva siempre es punto de
discusión, pues incrementa el presupuesto estimado y la tendencia es recortar las
reservas para dar mejores estimaciones iniciales. Si esto sucede, es necesario registrar
un riesgo de que cualquier retraso en alguna actividad puede generar un retraso de
proyecto. Aún así, recomendamos siempre contemplar un factor de contingencia en
cada tarea. Por otro lado, es necesario intentar encontrar el punto de equilibrio. Es
decir, no es conveniente aumentar demasiado el tiempo del proyecto sólo por las
reservas. El proyecto será menos eficiente y el equipo puede perder credibilidad.
3.4.4. Desarrollo del Calendario
Aquí se determinan las fechas de inicio y fin de las actividades del proyecto. Si las
fechas de inicio y fin no son realistas, tampoco lo serán los plazos del proyecto. Puede
ser necesario llevar a cabo varias iteraciones del calendario, al igual que las otras
tareas de preparación de la planificación.
61
Se deberá disponer de una relación de los recursos del proyecto. Debe incluir cuándo
estará disponible cada recurso y por cuánto tiempo. Puede variar este detalle en función
de la criticidad de los recursos y de la fase en la que se esté haciendo la descripción.
Recomendamos que a lo largo del proyecto se intente disponer de una persona de
respaldo para los recursos críticos, que en cualquier momento pueda cubrirlo en caso
de necesidad.
También se debe disponer de los calendarios que identifican los periodos de trabajo
para cada recurso. Además del tradicional calendario de 8 horas al día, 5 días a la
semana, se deben tomar en cuenta los festivos, tanto corporativos como locales en el
país de destino. Adicionalmente, normalmente se deberán incluir los fines de semana
en los que se espera trabajar (por ejemplo, el fin de semana de puesta en producción).
Las principales restricciones de tiempo que se tienen son 2. La primera es por
imposiciones de calendario (es necesario que este proyecto esté finalizado para x
fecha), y la segunda es por eventos clave o hitos. En proyectos de Sistemas de
Recursos Humanos la restricción más común viene dada por las fechas de cálculo de la
nómina, tanto en el corporativo, como en el país de destino. Otras fechas críticas suelen
ser los finales de año (pago de aguinaldo u otros beneficios para empleados) y febrero /
marzo (evaluaciones del desempeño, incrementos salariales, pago de beneficios). Es
importante tenerlas en cuenta, pues además de condicionar por ejemplo, las fechas de
puesta en producción, también condicionarán la disponibilidad de las personas, tanto
del equipo de Recursos Humanos como de Sistemas.
Puede ser necesario incluir algunos anticipos o demoras en función de cada tarea. Por
ejemplo, el tiempo de aprobación de un pase a producción requerirá demorar la tarea
dependiente hasta que esté finalizada, o es necesario anticipar un mes la campaña de
comunicación del nuevo sistema de autoservicio de empleados antes de su
implementación.
Se podrá hacer un análisis matemático para calcular de forma teórica las mínimas
fechas de inicio y fin de todas las tareas del proyecto, sin importar las limitaciones del
equipo de recursos. El resultado final no es precisamente el calendario a seguir, sino
62
más bien, los periodos en que las actividades podrían ser planificadas, tomando en
cuenta las restricciones en recursos. Las más conocidas son: técnica de la cadena
crítica y PERT, aunque este último se utiliza cada vez menos.
También se puede valorar hacer en paralelo tareas que normalmente se harían en
serie. Aunque normalmente incrementa el riesgo, es útil para disminuir el tiempo del
proyecto. Un caso de trabajo en paralelo es iniciar el diseño aunque aún no esté
finalizado el análisis. Esto tiene riesgo de reprocesamiento, pues durante el cierre del
análisis pueden cambiar algunas especificaciones, sin embargo, dependiendo del punto
donde se inicie el diseño, el anticipo en el trabajo puede dar más valor que el
reprocesamiento posible. Los responsables del proyecto, con experiencia previa,
deberán valorar este riesgo y la alternativa.
Se pueden hacer simulaciones para calcular varias posibles duraciones del proyecto
combinando distintos supuestos en las actividades. Se pueden incluir escenarios con
condiciones adversas, como enfermedad de los recursos, caída de comunicaciones,
etc. Esto sirve para valorar la viabilidad del calendario bajo circunstancias no favorables
y para generar planes de actuación ante estas posibles contingencias para mitigar su
impacto.
La estimación matemática puede dar fechas mínimas anteriores pero a costa de
aumentar recursos en momentos en los que no están disponibles o a niveles que no
son manejables. Sin embargo se pueden usar métodos por tanteo, tales como, asignar
recursos escasos primero a las tareas críticas, para reflejar nuestras restricciones.
También se pueden aumentar las horas de trabajo por jornada para disminuir la
duración de tareas críticas (por ejemplo, la implantación se suele hacer en fin de
semana, para afectar el menor número de días laborables a los usuarios actuales de la
aplicación). En ciertos casos puede ser necesario planificar “hacia atrás” (de fin a inicio)
tareas relacionadas con recursos críticos o de poca disponibilidad. En nuestra
experiencia, este es el punto en el que se aproxima más al calendario final, pero que
requiere más visión del detalle para poder incorporar y contemplar todas las
restricciones.
63
Finalmente se generará el calendario de proyecto. Incluye al menos las fechas de inicio
y fin esperadas de cada una de las actividades. Hay que recordar que el calendario del
proyecto queda como borrador hasta que se confirme la disponibilidad de los recursos y
sea aprobado el plan por todos los involucrados, como veremos más adelante. Se
puede presentar en tabla (Excel o Project), aunque también se puede presentar en
forma de calendario o gráficamente como el calendario de red con fechas, el Gantt del
proyecto o diagrama de hitos:
Figura 10. Ejemplo de Diagrama de Gantt
Figura 11. Ejemplo de Diagrama de Red con Fechas
64
Figura 12. Ejemplo de Diagrama de Hitos
3.4.5. Control del Calendario
Está relacionado con encontrar los puntos para influenciar los factores que crean los
cambios para asegurarse de que están consensuados y aprobados, con el control
necesario para determinar que el calendario ha cambiado, y gestionar los cambios
reales conforme van ocurriendo. Este proceso deberá estar integrado completamente
con las otras tareas de control.
Los informes de desempeño del proyecto darán información también sobre el
desempeño contra el calendario, principalmente relacionados con el cumplimiento de
las fechas definidas. Reportará también posibles alertas para que el equipo de proyecto
las tenga en cuenta y pueda rectificar.
Pocos proyectos se desarrollan conforme al plan. Los cambios pueden requerir cambios
al plan original, modificar secuencia de actividades, o analizar calendarios alternativos.
El comportamiento de la variación del calendario aporta información crítica para el
control. Permite prevenir o detectar cambios, y evaluar el desempeño en tiempo del
proyecto. Se debe prestar especial atención a las actividades críticas.
Se debe notificar a los involucrados en el proyecto de todos los cambios ocurridos, pues
se pueden derivar cambios en otros puntos del proyecto (costos, recursos, etc.). Se
harán revisiones a las fechas del calendario y, en algunos casos más graves, se
redefinirá la línea base por completo para poder disponer de una visión real del
desempeño del proyecto sin que se vea afectada por cambios en la planificación.
65
Se deberán emprender las acciones correctivas necesarias, para que el proyecto se
comporte conforme al plan (corrigiendo la desviación). En especial, en cuanto a la
gestión del tiempo, las acciones que se hacen son las que logran que una tarea termine
a tiempo o con el menor retraso. Se debe analizar si la acción se debe aplicar sólo a la
actividad retrasada o a todas las actividades pendientes, en caso de que sea un
problema de raíz.
Se debe documentar la causa de las variaciones, los motivos que están detrás de la
elección de la acción correctiva, y otro tipo de lecciones aprendidas, para que formen
parte de la base de conocimientos de este proyecto y como base histórica de otros
siguientes.
3.5. Gestión de Costos del Proyecto
Incluye todos los procesos que sirvan para asegurarse que el proyecto se lleva a cabo
conforme al presupuesto aprobado. Principalmente trata de los costos de los recursos
asociados al proyecto, sin embargo, deberá también validar el efecto de los costos del
proyecto en el costo derivado del uso del proyecto. Por ejemplo, un diseño escaso,
puede provocar que al usar el producto se tenga que perder más tiempo, y por tanto
más dinero. Siempre será necesario tener la visión del cliente para valorar la relación
costo/beneficio sobre las acciones que se hagan y su efecto fuera del proyecto.
Las posibilidades de influir en el costo del proyecto son mayores en las fases iniciales, y
es por lo que es crítico hacer la valoración del alcance en el inicio, así como hacer el
levantamiento de requerimientos en profundidad.
3.5.1. Planificación de Recursos
Implica determinar los recursos físicos (personas, equipos, materiales) necesarios, las
cantidades en las que se requieren y el momento en el que se requieren. Está
estrechamente relacionado con la estimación de costos, pues si por ejemplo, necesitan
un tiempo de formación y entrenamiento, se deberá estimar qué costo implica.
66
Afectarán las políticas organizacionales relacionadas a la dotación de personal y
plantilla en la empresa. Afectará sobre todo en los criterios que ayuden a definir si los
miembros del equipo deben pertenecer a la propia empresa o ser subcontratados con
empresas de consultoría. También se deben tener en cuenta las políticas de
certificación de proveedores, pues en empresas grandes como las bancarias, es común
que los proveedores tengan que tener una certificación, impidiendo que empresas
pequeñas participen directamente.
Al final, obtendremos los requerimientos de recursos. Es una descripción de los tipos de
recursos requeridos y en qué cantidades, asociados al nivel más bajo de la EDT. Los
requerimientos a nivel más alto de la EDT se pueden calcular sumando el detalle. Los
recursos se obtendrán ya sea por contratación directa (incorporación a plantilla), o vía el
área de compras (consultoría).
3.5.2. Estimación de Costos
Se debe generar una relación o estimado de los costos de los recursos necesarios para
completar las actividades del proyecto. Se deben valorar las posibles causas de
cambios para valorar más exactamente los costos. De la misma manera, se deberán
valorar distintas alternativas de costos.
Se deben conocer las tarifas por unidad de recurso. Si no se conocen, se deben estimar
también. Así, con los estimados de duración de actividades, se podrán aplicar las tarifas
y de ahí derivar el costo total de cada actividad.
Se deben considerar los riesgos, puesto que pueden influir en los costos finales (tanto
para aumentar, como para disminuir). El equipo de proyecto debe decidir hasta qué
punto refleja los riesgos en la estimación final de costos.
Se pueden hacer estimaciones por analogía, siguiendo la historia de otros proyectos,
estimaciones de abajo a arriba (a partir de la EDT), o cualquier otro método de
estimación de costos. Generalmente las instituciones bancarias cuentan con métodos
establecidos que en este caso resultarán útiles, sumándolos a la experiencia del equipo.
67
3.5.3. Presupuesto de Costos
En este proceso se distribuirán los costos en hitos o paquetes de actividades, que
permitirán hacer un seguimiento del desempeño del proyecto en cuanto a costos. La
experiencia real nos puede decir que las estimaciones se hacen después de la
aprobación del presupuesto, pero se debe intentar hacerlas con anterioridad siempre
que se pueda.
Finalmente se genera un presupuesto desglosado por fases que se utilizará para medir
y monitorizar el desempeño del costo en un proyecto. Se desarrolla sumando los costos
estimados por periodo y usualmente se representa con una curva tal como se ilustra en
la figura siguiente:
Figura 13. Ejemplo de Representación de Línea Base y Flujo de Efectivo
3.5.4. Control de Costos
Está relacionado con la influencia en los factores que crean cambios de costo, para
asegurar que todos los involucrados estén conformes y enterados, determinar que el
costo ha cambiado, y gestionar los cambios que ocurran. Incluye además buscar las
causas de las desviaciones, tanto positivas como negativas, y controlar su efecto en los
otros procesos (calidad, calendario, riesgos, etc.).
68
Se debe contar con procedimientos, sistemas de seguimiento y aprobaciones para los
cambios en costo. Se debe monitorizar el comportamiento de los costos, y definir
acciones preventivas y correctivas de las desviaciones.
Finalmente, los cambios pueden derivar en revisiones a las estimaciones iniciales y
actualizaciones al presupuesto, que influirán en el monto estimado para el cierre del
proyecto. Todos estos cambios se deberán notificar a los involucrados y afectados.
3.6. Gestión de la Calidad del Proyecto
Incluye los procesos encaminados a asegurar que el proyecto satisfará las necesidades
para las que fue emprendido. Debe contemplar todas las actividades que determinen la
política de calidad, objetivos y responsabilidades y las implemente por vías tales como
la planificación de la calidad, aseguramiento de calidad, control de calidad, mejora de la
calidad, dentro del sistema de calidad. Pueden seguirse los estándares internacionales
ISO (International Standard Organization) como ISO-9000 y 10000, o TQM (Total
Quality Management).
La gestión de la calidad debe asegurar tanto la calidad del producto, como del proyecto.
Si no se hace así, las consecuencias negativas se pueden notar a cualquier nivel de las
personas involucradas.
Una definición de la calidad, es que debe satisfacer las necesidades implícitas y
explícitas. Uno de los puntos críticos en la gestión de la calidad dentro de un proyecto,
es la necesidad de convertir las necesidades implícitas en requerimientos, a través de la
definición del alcance.
Por medio de este proceso, se debe asegurar: la satisfacción del cliente, prevención de
inspecciones, gestión de la responsabilidad, y calidad de procesos dentro de las fases.
3.6.1. Planificación de Calidad
Se debe identificar qué estándares de calidad son relevantes para el proyecto y
determinar cómo cumplirlos. Se debe hacer reiteradamente, y revisar con los cambios
69
que haya. Puede impactar en la planificación definida, pues el cumplir un estándar de
calidad determinado puede implicar más tiempo o costo. Es importante mantener en
mente que la planificación de la calidad no implica inspección, pues eso se hará más
adelante. En este punto sólo se planifica.
Se debe tomar en cuenta la política de calidad, y los estándares y regulaciones
relacionados con la calidad. En empresas tan grandes como los corporativos bancarios
existen regulaciones y estándares propios que se deben seguir.
Es necesario hacer un análisis de costo/beneficio de aplicar los criterios de calidad. El
principal beneficio de la calidad es menos reprocesamiento, con más productividad,
menores costos, y mayor satisfacción. El principal costo es que las actividades de
calidad requieren más gasto.
Se pueden obtener ideas de mejora de proyectos semejantes, e incorporarlos a nuestro
proyecto para obtener mejores resultados.
Un plan de gestión de la calidad describe cómo se implementará la política de calidad.
Es decir, debe describir la estructura organizacional, responsabilidades, procedimientos,
procesos y recursos necesarios para gestionar la calidad.
En un proyecto de PS la calidad del producto se valida con las pruebas realizadas en
las diferentes fases, como se describirá en el capítulo 4.
3.6.2. Aseguramiento de Calidad
Aquí se llevan a cabo las actividades definidas en el plan de calidad. Se debe llevar a
cabo a lo largo del proyecto. Estas tareas las llevarán a cabo en una parte el propio
equipo de proyecto (aseguramiento interno), y en otra, el cliente del proyecto
(aseguramiento externo).
Se deberán hacer auditorías de calidad, que certifiquen y revisen el nivel de calidad del
trabajo hecho hasta ese momento. Pueden ser planificadas o al azar. En el caso de las
entidades bancarias, hay áreas del banco dedicadas a asegurar la calidad del proyecto
70
a través del seguimiento de la metodología establecida. Estas áreas también pueden
aplicar auditorías en distintos momentos del proyecto.
El resultado de las actividades de aseguramiento de calidad es un aumento en la
calidad tanto del producto como del proyecto, y que será percibido por todas las
personas involucradas en el proyecto.
3.6.3. Control de Calidad
Implica monitorizar determinados resultados del proyecto para determinar si cumplen
con los estándares relevantes del proyecto e identificar las causas para los malos
resultados. Se debe llevar a lo largo de todo el proyecto, y valorar tanto la calidad del
proyecto como la calidad del producto.
Se harán distintas inspecciones en distintas áreas, cuyos resultados se pueden reflejar
en gráficos de control. En el caso de los proyectos de sistemas, un medidor típico son
los índices de incidencias y errores. Estos deberían disminuir, tanto en tasa de entrada
como en número de errores pendientes de solución.
Estas acciones tendrán un reflejo en la calidad, potenciar o acelerar las decisiones de
aceptación además de que evita reproceso.
Del control de calidad se pueden derivar acciones correctivas o preventivas y corrección
de defectos, o la propia valoración y aceptación de entregables.
3.7. Gestión de Recursos Humanos del Proyecto
Incluye los procesos para gestionar y controlar los miembros del equipo del proyecto.
Se entiende como equipo de proyecto el conjunto de las personas que tienen asignados
roles y responsabilidades para desarrollar el proyecto. Aunque los roles y las
responsabilidades se asignan, es necesario que los miembros del equipo estén
involucrados en los propios procesos de toma de decisiones, pues cuanto antes se
involucren en el proyecto, mayor destreza se añade al proyecto. Conforme el proyecto
71
progresa, pueden cambiar el tipo y el número de personas asignadas. Al equipo del
proyecto también se le conoce como plantilla de proyecto.
Un subconjunto del equipo de proyecto es el equipo de gestión del proyecto, y son
responsables de las actividades de gestión tales como liderazgo del proyecto, control y
cierre. El promotor o sponsor del proyecto participa con el equipo de gestión,
típicamente con los fondos económicos, pero también clarificando dudas de alcance, e
influyendo en otros en beneficio del proyecto. Como comentábamos en un principio, el
promotor del proyecto de expansión de PS RH en el corporativo bancario será el
Holding de RH.
3.7.1. Planificación de Recursos Humanos
Determina los roles del proyecto, las responsabilidades y las dependencias (líneas de
reporte) y crea el plan de gestión de la plantilla. Este último puede incluir la forma y el
momento en que se incorporarán los miembros del equipo y cuándo saldrán, la
identificación de necesidades de formación, los planes de incentivos, viajes, y el
impacto del plan de gestión de la plantilla en la organización.
En nuestro proyecto es crítico tener en cuenta el número de viajes que se deberán
realizar, pues esto influye tanto a nivel laboral como personal en los recursos
asignados. Es necesario validar con ellos su disponibilidad, y en caso de que no estén
dispuestos a viajar, validar si es necesaria su sustitución.
Asimismo, se deben tomar en cuenta factores organizacionales, técnicos,
interpersonales, logísticos y políticos en la gestión del equipo. Y tampoco hay que
olvidar las restricciones propias de la estructura organizacional, acuerdos colectivos y/o
sindicales, o condiciones económicas.
Como estamos tratando con personas, pueden surgir una inmensa variedad de
elementos a tener en cuenta.
Se debe hacer una descripción de las posiciones disponibles la relación entre ellas
(jerarquía).
72
Figura 14. Formatos para definición de Roles y Responsabilidades
Como resultado de este trabajo, obtendremos para cada posición sus roles, su
autoridad, sus responsabilidades y su ámbito de competencia. También tendremos el
organigrama del proyecto, el plan de gestión de la plantilla, los criterios de salida de los
miembros del equipo y necesidades de formación.
Se puede incluso valorar que los propios miembros más avanzados del equipo formen a
sus compañeros más novatos, logrando así capitalizar las capacidades del equipo.
3.7.2. Adquisición del Equipo de Proyecto
Es el proceso de adquisición e incorporación de los miembros del equipo necesarios
para finalizar el proyecto.
En el mercado español este es uno de los puntos más difíciles de solventar. Hay poca
disponibilidad de recursos con experiencia, tanto para contratación directa como para
subcontratación. Los que hay suelen ser muy caros, por lo que elevan los presupuestos
del proyecto.
Para personas para las que se requiera menos experiencia (programadores básicos),
se puede acordar con los proveedores establecer un programa de formación de
becarios conjunto. Se pueden establecer acuerdos de tarifa para no incurrir los primeros
meses de formación, y comenzar a facturar a partir del inicio real del proyecto.
73
Sin embargo, es necesario asegurar la disponibilidad de algunos miembros más
expertos que puedan coordinar el trabajo del resto, y asegurar que el proyecto avanzará
en las líneas establecidas.
Este tipo de proyectos depende completamente de las personas y de su capacidad de
resolver las tareas que les son encomendadas.
Por otro lado, es necesario coordinar las labores del equipo corporativo con las del
equipo local, que también deberá incorporar nuevas personas a su equipo y asegurar
disponibilidad de ciertos miembros.
Así, en todos los niveles del equipo de proyecto, nos deberemos asegurar disponibilidad
de las personas necesarias para la finalización del proyecto.
3.7.3. Desarrollo del Equipo de Proyecto
Mejora las competencias e interacción de los miembros del equipo de proyecto para
mejorar el desempeño del proyecto. Sus objetivos son:
Mejorar las habilidades de los miembros del equipo para mejorar su capacidad de
finalizar exitosamente sus tareas en el proyecto.
Mejorar los sentimientos de confianza y cohesión entre los miembros del equipo para
aumentar su productividad a través de un mejor trabajo en equipo.
Se debe ser capaz de cooperar, por ejemplo, para balancear el trabajo cuando esté
descompensado, compartir información y recursos, etc. El mayor beneficio se obtiene
cuando estas tareas se inician antes en el proyecto, pero deben continuar a través de
todo el proyecto.
Se realiza una gestión de las habilidades de cada recurso, se gestiona un plan de
formación que puede incluir autoformación o un programa de “sombra” de recursos más
novatos sobre recursos más experimentados.
74
En el proyecto que estudiamos, hay que tener en cuenta el factor de distancia. A pesar
de que algunos miembros del equipo viajen en algún momento, normalmente habrá
distancia física entre las distintas partes del equipo de proyecto. Se debe lograr
cohesionar y coordinar los esfuerzos para el mismo fin común. Desde nuestro punto de
vista, este es uno de los mayores retos a los que nos enfrentamos.
3.7.4. Gestión del Equipo de Proyecto
En este proceso se hace un seguimiento del desempeño de cada miembro del equipo,
retroalimentando, resolviendo problemas y coordinando los cambios para mejorar el
desempeño del proyecto. El equipo de gestión del proyecto deberá observar el
comportamiento del equipo completo y valorar su desempeño.
Así como en el punto anterior resaltábamos la importancia de la distancia, aquí también
es importante. El equipo de gestión debe valorar en conjunto el desempeño de todos los
elementos del equipo, sin importar su ubicación física, y coordinar las acciones de
mejora.
En proyectos con un elevado nivel de estrés como estos, surgirán conflictos que deben
ser resueltos exitosamente, pues si no, se verá afectada la productividad del proyecto.
El nivel de conflicto se reduce asignando y comunicando adecuadamente los niveles de
autoridad de cada miembro del equipo, estableciendo normas de acción y llevando a
práctica sólidas capacidades de gestión. Bien llevados, los conflictos pueden incluso
aportar valor al proyecto, pues son puntos de generación de nuevas ideas.
3.8. Gestión de Comunicaciones del Proyecto
Esta es el área de proyecto que emplea los procesos requeridos para asegurar una
adecuada y oportuna generación, recolección, distribución y obtención de la información
del proyecto. Aquí se establecen los vínculos entre las personas y la información
necesarios para garantizar una correcta comunicación. En esta área se necesitan
herramientas y habilidades de comunicación tales como: técnicas de presentación,
gestión de reuniones, transmisión de ideas, etc. En nuestro proyecto es un reto especial
75
el uso de la tecnología para lograr tener comunicación efectiva entre los miembros del
equipo que están a distancia.
3.8.1. Plan de Comunicación
Determina las necesidades de información y comunicación para los involucrados en el
proyecto. Aunque todos los proyectos necesitan información, pueden variar los métodos
que se sigan para distribuirla. Una vez más, en el ejemplo de nuestro proyecto, al
encontrarnos con el reto de la distancia, deberemos tomar en cuenta las ayudas de la
tecnología. Sin embargo, hay que valorar qué información se debe distribuir, a quiénes
y con qué periodicidad.
Las nuevas herramientas que proporciona Internet pueden ser muy útiles: foros,
repositorios de información en la intranet, wikipedias, audio conferencias, video
conferencias, conferencias por chat, son herramientas que están disponibles en las
empresa actualmente y que cada vez entran más en funcionamiento.
Se deben analizar los requerimientos de comunicación de todos los involucrados y
establecer la infraestructura para llevarlos a cabo. Se deberá asignar a un responsable
del aseguramiento de la comunicación, frecuencia, escalado, actualización, e incluso un
glosario sobre palabras comunes. Este último punto da para muchas anécdotas en
proyectos de expansión a Latinoamérica desde España, pues aunque es el mismo
idioma, los regionalismos pueden dar lugar a equívocos o errores en el entendimiento.
3.8.2. Distribución de la Información
Son las tareas que se realizan a fin de poner la información a disposición de las
personas que la requieran. En los proyectos que estamos estudiando, prácticamente
todos los medios están relacionados con la tecnología: puntos comunes de red, intranet,
Livelink, etc. Esto se estructura sobre las responsabilidades definidas en el plan de
comunicación, pues siguiendo los flujos definidos en él, se generan los documentos que
se pondrán a disposición de las personas involucradas.
76
3.8.3. Reporte del Desempeño
En este apartado especial de la comunicación se debe recabar toda la información
necesaria para el cálculo del desempeño, y posteriormente distribuirla entre todos los
involucrados. Esta información debe incluir datos sobre el alcance, calendario, costo y
calidad.
Se deben generar formatos únicos y constantes a lo largo del proyecto, entendibles por
todos los miembros del equipo. Deben organizar y resumir la información recopilada, y
deben presentar los resultados de cualquier análisis en comparación con la línea base
del proyecto.
Se pueden generar varios, en función del nivel de detalle requerido para la audiencia
específica (comité directivo, equipo de técnicos, etc.)
Además deberán incluir previsiones, acciones recomendadas, próximos pasos, etc.
3.9. Gestión del Riesgos del Proyecto
Abarca los procesos relacionados con la gestión del riesgo, planificación, identificación,
análisis, respuesta, monitorización y control de los riesgos. La mayor parte de estos
elementos se controlan a lo largo del proyecto.
Su objetivo es aumentar la probabilidad e impacto de eventos positivos y disminuir lo de
los adversos.
Un riesgo es un evento incierto que, si ocurre, tiene un efecto positivo o negativo en al
menos uno de los objetivos del proyecto (tiempo, costo, calidad). Puede tener una o
más causas y uno o más impactos.
En nuestro proyecto hay que tener en cuenta los aspectos ambientales propios de la
organización, los de cada empresa (filial y corporativo), y los de los países (gobierno,
política, economía).
Las personas y las organizaciones tienen distintas actitudes hacia el riesgo que afectan
a la percepción y a la respuesta ante esta situación. Se debe conseguir tener una visión
77
consistente con los principios de la organización, y garantizar transparencia y
honestidad de los riesgos detectados.
3.9.1. Plan de Gestión del Riesgo
Una planificación cuidadosa y explícita mejora la posibilidad del resto de procesos de
gestión del riesgo. La planificación del riesgo es el proceso en el que se decide cómo
conducir y gestionar las actividades de gestión de riego en un proyecto. Este proceso es
importante para asegurar que el nivel, tipo y visibilidad de la gestión del riesgo están en
sintonía con los riesgos y su importancia en la organización. Este proceso se debe
cerrar al inicio del proyecto, pues puede afectar al resto de áreas.
Al ser un plan de gestión de riesgo, debe incluir metodología, roles y responsabilidades,
presupuesto, calendarización, categorías de riesgo, definiciones de riesgo e impacto.
Incluso se puede hacer una Estructura de Descomposición del Riesgo (EDR).
3.9.2. Identificación de Riesgos
Aquí se determina qué riesgos pueden afectar el proyecto y se documentan sus
características. Este es un proceso iterativo, porque pueden surgir nuevos riesgos
conforme avanza el proyecto. De la identificación se debe pasar al análisis cualitativo o
cuantitativo para preparar el plan de respuesta.
Se pueden identificar haciendo lluvia de ideas, haciendo el análisis FODA (Fuerzas,
Oportunidades, Debilidades y Amenazas), etc.
En los proyectos que hemos participado, hemos visto que es necesario coordinar a
ambos equipos (local y corporativo) para este análisis, pues muchas veces los riesgos
surgen en situaciones específicas de los países desconocidas para el personal
corporativo.
Se deberá generar un registro de riesgos, con su valoración y posibles respuestas.
78
3.9.3. Análisis Cualitativo de los Riesgos
Se seguirán métodos para priorizar y calificar los riesgos usando su posibilidad de
ocurrencia, el impacto en los objetivos del proyecto, la ventana de tiempo y la tolerancia
al riesgo de las restricciones de proyecto tales como costo, tiempo, calidad y alcance.
Hay que tener en cuenta que la criticidad de un riesgo puede aumentar por el impacto
que tenga en estos elementos.
Este análisis es rápido y efectivo a nivel de coste para determinar cuáles son los riesgos
más prioritarios, pues se define una categoría y un nivel de urgencia.
3.9.4. Análisis Cuantitativo de los Riesgos
Este análisis se realiza sobre los riesgos que se han priorizado en el análisis cualitativo.
Analiza el efecto de estos riesgos y asigna una calificación numérica al riesgo. También
ofrece una visión cuantitativa para la toma de decisiones. Se debe poder cuantificar los
posibles desenlaces de los riesgos y sus probabilidades, la probabilidad de cumplir los
objetivos del proyecto, identificar los riesgos que requieran mayor atención y determinar
las mejores decisiones en cada caso.
No hemos visto aplicada esta técnica en ninguno de los proyectos de expansión,
aunque podría ser necesaria para riesgos nuevos o con poca incidencia histórica.
3.9.5. Plan de Respuesta al Riesgo
Es el proceso de desarrollar opciones y determinar acciones para mejorar las
oportunidades de reducir las amenazas al objetivo del proyecto. Incluye el asignar a una
o varias personas responsables de la respuesta al riesgo. Se orienta a los riegos de
acuerdo a su prioridad insertando recursos y actividades en el presupuesto, calendario
y plan de proyecto conforme sea necesario.
Las respuestas al riesgo debe ser acordes a la importancia del riesgo, efectivas en
coste para enfrentar el riesgo, oportunas, realistas dentro del contexto del proyecto,
acordadas entre todos los afectados y asignadas a una persona responsable.
79
Las respuestas a los riesgos negativos se pueden clasificar en: acciones encaminadas
a evitar el riesgo, a transferirlo o mitigarlo. Las respuestas a los riesgos positivos
pueden ser: explotar, compartir o mejorar. En ambos casos se puede también aceptar el
riesgo.
Un riesgo común en este tipo de proyectos es que los equipos del país destino no
dediquen el tiempo acordado a cada tarea. Una respuesta a ese riesgo puede ser
establecer hitos de medición (evitar) y programar viajes de trabajo conjunto para
mitigarlo.
3.9.6. Monitorización y Control del Riesgo
Durante la monitorización de las tareas pueden surgir nuevos riesgos o cambiar los
existentes. En este proceso se identifican, analizan y planifican los nuevos riesgos que
surjan, se hace seguimiento sobre los riesgos identificados y aquellos en el punto de
mira, se reanalizan los riesgos existentes, se monitorizan las condiciones que disparan
los planes de contingencia, se monitorizan los riesgos residuales y se revisa la
ejecución de tareas de respuesta al riesgo evaluando su efectividad. Otros objetivos de
este proceso son determinar si:
Los supuestos del proyecto aún son válidos.
El riesgo ha cambiado.
Se están siguiendo las políticas y procedimientos de gestión del riesgo.
Se deben incrementar las reservas del plan de contingencia.
3.10. Gestión de Adquisiciones del Proyecto
Abarca los procesos relacionados con la compra o adquisición de productos, servicios o
resultados requeridos desde fuera del equipo de proyecto para poder llevar a cabo el
trabajo. Abordaremos las distintas opciones que hay para aprovisionamiento en el tipo
de proyecto que estamos analizando.
En este proceso se incluye la gestión de los contratos y de las obligaciones
contractuales contraídas. Un contrato puede ser simple o complejo, reflejando la
80
simplicidad o complejidad del objeto del contrato. Al ser documentos legales, el área de
asesoría legal del banco deberá validarlos para asegurar su correcta redacción.
Normalmente, en las organizaciones bancarias, existen contratos tipo que ya se
trabajan con los proveedores certificados, y esta gestión no será responsabilidad directa
de los miembros del equipo.
En caso de que se elija un proveedor para hacer como proyecto cerrado la expansión,
es el proveedor el que gestiona el proyecto y el banco se convierte en el promotor y
persona clave del proyecto. Sin embargo, recomendamos que siempre haya una
participación considerable por parte del banco, para asegurar el cumplimiento de las
políticas y criterios de la organización, y dar continuidad a la implementación una vez
finalizado el proyecto.
En nuestro proyecto el esfuerzo de compras de dirige principalmente a servicios:
recursos con conocimientos del producto y procesos involucrados. Sin embargo
también puede ser necesario hacer adquisiciones de tecnología (servidores,
computadoras) y comunicaciones.
3.10.1. Planificar Compras y Adquisiciones
Aquí se identifica qué necesidades se pueden satisfacer por compras o adquisiciones.
Además se determina qué, cómo, cuándo y cuánto adquirir. También incluye la
evaluación de posibles proveedores.
El plan de proyecto influirá significativamente en el proceso, pues determina cuándo se
necesitan los recursos y por cuánto tiempo.
En nuestro sector es necesario tener en cuenta la escasez de recursos con experiencia
y formación, pues el proceso de adquisición es muy lento y con riesgos que deben ser
tenidos en cuenta y valorados en los contratos con los proveedores.
81
Por esta situación puede llegar a ser necesario contratar varios proveedores, aunque
recomendamos manejar el menor número posible de proveedores, pues se favorece el
trabajo en equipo y se disminuyen las complejidades de gestión.
3.10.2. Planificar Contratos
Aquí será necesario trabajar muy en conjunto con el área de compras del banco, ya que
ellos son los que gestionan los contratos con los proveedores una vez elegidos por el
área usuaria de los servicios o productos.
Se generan documentos oficiales, y algunos derivados de la propia gestión interna.
Normalmente se pide a los proveedores un documento detallando la oferta que hacen,
que sirve como base para el contrato que se define. En España las ofertas son
documentos legales, que tienen una vigencia y la descripción del producto o servicio a
entregar.
Suelen incluir mucho detalle de los servicios a ofrecer, el lugar en que lo harán,
condiciones de viajes, etc. Las tarifas suelen estar definidas en acuerdos marcos
derivados de la certificación de cada proveedor.
Hay que tener en cuenta el nivel de servicio del área de compras para definir el plan de
contratos.
3.10.3. Solicitar Respuesta de Proveedores
Se piden propuestas y estimaciones a los posibles proveedores. Se les deberá entregar
un documento con la definición completa del servicio requerido. Si se les pide llevar a
cabo todo el proyecto se entrega un documento conocido como “cuaderno de encargos”
donde se describe completamente el requerimiento del proyecto. A partir de él, los
proveedores podrán hacer preguntas adicionales y un análisis preliminar que les
permita dar la estimación de tiempo y costo. Normalmente estas estimaciones van
enmarcadas por un conjunto de supuestos y restricciones derivadas de lo que está
definido y lo que no está definido en el cuaderno de encargos.
82
No hay muchos proveedores de PS certificados para los bancos, así que normalmente
se obtienen a lo más 3 ofertas para cada proyecto. Aunque sí puede suceder que los
equipos de estos proveedores estén formados por equipos de empresas más pequeñas
que subcontratan sus servicios.
3.10.4. Seleccionar Proveedores
Una vez obtenidas las propuestas, se aplican criterios de evaluación para seleccionar el
o los proveedores cualificados y aceptables. Normalmente se seguirá alguno de los
siguientes criterios:
Precio y costo. Aunque no siempre lo más barato es lo mejor, normalmente el
precio es un criterio de decisión.
Experiencia del proveedor y capacidad de respuesta en situaciones de
contingencia.
Posibilidades de viaje o incluso de soporte en países de destino.
Disponibilidad de los recursos (momento y número de recursos).
Una vez seleccionado, se desarrollará un contrato y se firmará cuando ambas partes
estén de acuerdo. Como comentábamos, en un banco, normalmente el área de
compras es la encargada de gestionar las tareas que surgen a partir de la selección del
proveedor.
3.10.5. Administración de Contratos
Cada parte, cliente y proveedor, se debe asegurar de que se cumplan los términos
establecidos en el contrato y que sus derechos legales estén protegidos. Ante cualquier
duda, se consultará con el área de compras o asesoría legal que darán el apoyo
necesario.
También dentro de este proceso se realizarán las revisiones o ampliaciones necesarias
derivadas de los cambios en el proyecto.
83
3.10.6. Cierre de Contratos
Se hace al cierre del proyecto y engloba todas aquellas tareas encaminadas a finalizar
la relación con el proveedor. También puede ser necesaria en caso de incumplimiento
de contrato por alguna de las partes. Siempre estarán involucrados los resultados del
trabajo, y el grado de consecución de los objetivos.
84
CAPÍTULO 4. PROCESO DE IMPLEMENTACIÓN
4.1. Introducción
En este capítulo describiremos las fases que tiene el ciclo de vida del proyecto. Aunque
los proyectos de sistemas en general tienen siempre la misma estructura, en cada fase
iremos describiendo las particularidades de un proyecto internacional de expansión de
un producto ya implementado en un corporativo de banca.
Iremos, asimismo, describiendo qué partes de la metodología suelen estar definidas a
nivel estructura en la organización.
En los casos en los que sea necesario, describiremos las distintas alternativas que se
pueden acometer para obtener el mismo resultado.
4.2. Fase de Iniciativa
En la fase de la iniciativa se incluyen las tareas desde que se genera la idea o se
detecta la necesidad, hasta que se formaliza la solicitud del servicio. El promotor o
sponsor del proyecto deberá delinear las ideas de lo que necesita. Estos requerimientos
se llevarán más a detalle en la fase de análisis, que es donde finalmente se cierra el
alcance, por lo que en la fase de iniciativa se deberán recoger los lineamientos a nivel
general.
4.2.1. Generación
Aquí se recogen las necesidades del área de recursos humanos, definiendo su
viabilidad o inviabilidad en base a las opciones posibles y haciendo una primera
delimitación el alcance del sistema. Como estas iniciativas llevan aparejado un esfuerzo
muy grande, se clasifican desde un primer momento como proyecto. Es decir, no se
clasifican como evolutivos o modificaciones a lo existente, sino como un proyecto que
implica más esfuerzo e impacto.
85
Se deberán identificar los objetivos a cubrir en relación con la iniciativa recibida. Se
analiza lo que se va a implantar y se definen los límites del proyecto, indicando áreas de
usuarios afectadas, funcionalidades englobadas en la iniciativa y cualquier otra
característica que condicione el proyecto.
Visto desde la perspectiva de la metodología del PMI, en esta fase se definen los
primeros pasos para la definición del producto, es decir, el alcance.
Normalmente se llevará a cabo una serie de reuniones donde se irá profundizando cada
vez más sobre estos requisitos. Las reuniones inicialmente se realizan dentro del área
de Recursos Humanos Holding, que pueden validar con las áreas de Recursos
Humanos de varios países representativos.
Posteriormente se puede convocar a personal del área de sistemas, para que se
familiaricen con los requerimientos desde el principio.
4.2.2. Estudio
Con los elementos recabados en el punto anterior, se hace una descripción del sistema,
delimitando más sus objetivos, alcance e impacto en otros sistemas.
Se identificarán todos los clientes internos con los que se mantendrán las sesiones de
trabajo necesarias para definir el proceso de negocio propuesto y los requisitos que se
deriven del alcance inicial acordado, identificándose el impacto en otros sistemas.
Con estos elementos se estudian, analizan y valoran a alto nivel las diferentes
alternativas que pueden existir sobre el enfoque de desarrollo y entorno de tecnología.
En este apartado se puede valorar si PeopleSoft es la herramienta que se utilizará, o
hasta qué punto deberán mantenerse los sistemas locales actuales, y por tanto su
interacción con la aplicación corporativa.
Una peculiaridad de la expansión que vamos a llevar a cabo, es que al momento en que
se genera la idea en realidad se tiene clara la herramienta que se va a utilizar. El
estudio va más bien enfocado a la infraestructura tecnológica y la estrategia de
86
expansión, pues son los que en definitiva impactarán más en los procesos de negocio,
tanto corporativos como locales, y las actividades del día a día. Se valoran los
beneficios aportados en cada caso y los costes supuestos.
Las alternativas que se presentan en esta dimensión pueden ser variaciones de 2
esquemas:
Base de Datos Única, Centralizada en el Holding: Implica utilizar la instalación
existente de PS en España, conectando a todos los países a esta misma instalación. En
esta alternativa se deben reforzar los servidores (tanto de aplicación, como de procesos
y de web) para asegurar un nivel de servicio adecuado. Además es crítico que las
líneas de comunicación entre los países sean capaces de gestionar el tráfico de
transacciones generadas por PS.
Beneficios:
No es necesario hacer una nueva instalación (que es muy caro).
Se garantiza la unicidad del sistema (pues solo hay una versión), y se puede
orientar más fácilmente a los países a seguir los principios y políticas
corporativas.
Se centralizan y controlan las modificaciones a la aplicación.
Desventajas:
Al estar centralizada la aplicación, se hace necesario tener también un único
equipo de mantenimiento, para evitar incoherencia en las modificaciones o
alternaciones en el modelo. Este aspecto puede castigar el nivel de servicio en
nuevos desarrollos y solución de incidencias.
Se requiere un equipo de soporte e implantación en el corporativo muy robusto y
con capacidad de ir atendiendo a los países que se vayan incorporando a la
aplicación. El costo se centraliza, por lo que la inversión económica debe estar
enfocada ahí. Pero a la vez, al no tener costo para los países puede perderse la
noción del “esfuerzo” y que en un dado caso no aprecien tanto el sistema. Se
debe establecer un esquema que les obligue a ellos, se genere un cargo (aunque
87
sea simbólico) para que cada país tenga un sentido de pertenencia más acusado
sobre el nuevo sistema.
Base de Datos Replicada: Implica hacer una o más implementaciones de PS en
países distintos al holding, teniendo más de una base de datos en la corporación.
Beneficios
Al tener distintos servidores, existe menos dependencia entre un país y otro. Los
efectos negativos de las incidencias quedan más aislados al haber menos
usuario por servidor.
Cada sistema puede tener su ritmo de desarrollo y evolución.
Desventajas
Es más difícil asegurar que se sigue la política corporativa, pues inevitablemente
las diversas implantaciones estarán más lejos del seguimiento del corporativo.
Con el paso del tiempo se perderá homogeneidad entre las aplicaciones,
dificultando la unificación de la información.
Se pierden las sinergias que se pueden generar de hacer un trabajo a la vez para
muchos países.
Nuestra recomendación es la primera alternativa, pues se puede garantizar más la
unificación de la visión y política corporativa, que es el detonante principal de este
proyecto. Sobre esta alternativa iremos desarrollando las siguientes fases.
Una vez analizadas todas las alternativas, en cuanto a aplicación, infraestructura,
inversión, etc., se genera un documento con el proceso de negocio propuesto o también
conocido como “cuaderno de encargos”. Este documento, además de definir una
primera versión del alcance, describe las necesidades para transmitirlas a las áreas de
sistemas que se encargarán de llevar a cabo el proyecto.
Aquí se deberá también valorar qué impacto tendrá la aplicación con otros sistemas,
tanto corporativos como locales.
88
El área de Recursos Humanos es el primer lugar en el que se registra a las nuevas
personas, los movimientos y las bajas de personal. Es por eso, que una de las
principales ventajas de estos sistemas es la alimentación automática y actualizada de
directorios corporativos, archivos de perfilado y seguridad de usuarios (LDAP), sistemas
de control de presencia y acceso a edificios, sistemas de fichaje, aplicaciones de
clientela (para las cuentas bancarias de empleados), etc.
4.2.3. Aprobación y Planificación
Aquí el promotor o sponsor y el resto de personas involucradas, aceptan o deniegan la
realización del proyecto en función del estudio, valoración y de la disponibilidad de
presupuesto. En caso de que se apruebe, se realizará la priorización de la cartera de
proyectos de una manera global y se establecerá cuándo se va a acometer este
proyecto.
Como primer paso se deben consolidar las valoraciones de las distintas alternativas
junto con la argumentación de aspectos favorables y desfavorables para cada una.
También se deberá valorar el impacto de este proyecto en otros ya iniciados, tanto a
nivel corporativo como local en el país de destino. Esta validación la puede hacer el
responsable del área de sistemas que esté apoyando en el análisis. También la puede
gestionar alguna figura de coordinación que esté dentro del área de Recursos
Humanos.
Finalmente, es el propio cliente el que deberá validar y aprobar la iniciativa. Al menos
en la alternativa elegida.
Como suele ser habitual en instituciones bancarias, a partir de este momento se
pasarán los niveles de aprobación de iniciativa y presupuestarias necesarias para
emprender el proyecto.
89
4.2.4. Cierre
Una vez recibidas todas las autorizaciones necesarias, se podrá comenzar a hacer el
trabajo de detalle sobre el proyecto. Se considera como cierre la autorización del
proyecto por parte del comité correspondiente.
4.2.5. Entregables
En esta fase se generan los siguientes entregables:
Documentación de la iniciativa con alternativas y propuesta de solución.
Aprobación del comité.
4.3. Fase de Estructura
La fase de Estructura tiene como objetivo principal entrar a más detalle sobre la
alternativa analizada a alto nivel, resolviendo las cuestiones estratégicas y logísticas de
nivel inferior. Por ejemplo, qué país será el primero, cómo se estructurará el equipo de
proyecto y los criterios para decidir qué se incluirá en el alcance. Sin embargo, se
dejará para la fase de análisis cualquier aspecto relacionado con la solución técnica y
enfoque de los desarrollos o especificaciones técnicas.
4.3.1. Definición del Equipo
Al definir el equipo de un proyecto de este tipo se tienen que tener en consideración los
siguientes aspectos:
Áreas Involucradas: Debe haber al menos una persona de contacto o representante
para cada área involucrada. Las áreas son al menos: Arquitectura y Tecnología,
Comunicaciones, Sistemas y Recursos Humanos, y de estas áreas tanto del corporativo
como del país destino (global y local). Cada área aportará el equipo, a tiempo completo
o parcial, que se requiera conforme a las necesidades evaluadas, tal y como se
describe en el apartado 3.7 Gestión de Recursos Humanos del Proyecto.
90
Relación Global / Local: Se debe establecer cuál va a ser la relación entre las áreas
locales y globales. Deberá haber interlocutores por cada área, con suficiente autoridad y
responsabilidad para tomar decisiones sobre los temas que se presenten. Esta relación
se deberá establecer en los niveles de jerarquía necesarios, para poder escalar
decisiones en caso de que no se encuentre una solución en los niveles inferiores.
Dimensión: Deberá haber un número suficiente de recursos para atender todas las
tareas del proyecto. El equipo más numeroso suele ser el de sistemas (analistas y
programadores). También será numeroso el equipo de usuarios finales, pero al no
participar activamente en la construcción del proyecto, se tratan como “personas
involucradas” o “stakeholders” (los describimos en el último punto).
Roles principales.
Líder de Proyecto: Cada una de las áreas tiene un responsable o gerente, que toma
las decisiones relacionadas con su equipo. Sin embargo, debe existir una figura de
“Líder de Proyecto” al que cada gerente haya delegado una parte de responsabilidad y
autoridad, para organizar a los equipos del proyecto. Esta persona será responsable de
controlar el plan de proyecto, y asegurar el seguimiento de la calidad, tiempo, costo y
recursos. En proyectos tan grandes, se le suele denominar “Director de Proyecto”, pues
se requiere un nivel jerárquico alto que pueda ir aparejado al nivel de autoridad que se
le exige. El líder de proyecto podrá delegar con los líderes de cada área (RRHH,
Sistemas y Tecnología).
Líder Funcional: Será responsable del equipo de analistas funcionales. Se recomienda
que sea un analista funcional el que cumpla este rol. Deberá dar seguimiento al trabajo
del equipo y asegurar que se cumple en tiempo y calidad lo especificado en el plan.
Líder Técnico: Será responsable del equipo de analistas técnicos y programadores. Se
recomienda que sea un analista técnico el que cumpla este rol. Deberá dar seguimiento
a los desarrollos técnicos y atención de incidencias asegurando que se cumple en
tiempo y calidad lo especificado en el plan.
91
Analistas Funcionales: Desde el punto de vista del proceso y procedimiento, estos
analistas aproximarán la visión del usuario a la estructura de la aplicación. Recibirán los
requerimientos de usuario, enfocarán su posible solución dentro de la aplicación y
transmitirán al equipo técnico los requerimientos. Por esto deben ser capaces de
trasmitir ideas a nivel proceso y a nivel técnico. Son también responsables de configurar
la aplicación, hacer pruebas unitarias e integradas de los desarrollos finalizados antes
de entregarlos a usuarios, impartir la formación a los usuarios clave, asistir en las
pruebas de usuarios, recoger las incidencias detectadas y hacer un análisis previo de
ellas para identificar si son técnicas o no.
Analistas Técnicos: Recibe los requerimientos de los analistas funcionales y los
traducen en requerimientos técnicos que transmitirán directamente a los programadores
o al área de arquitectura responsable del soporte de la aplicación. Genera los
documentos de diseño técnico con las indicaciones a programadores, y una vez
finalizado el trabajo de éstos, validará con pruebas de primer nivel si son correctos o no.
Da soporte a las incidencias reportadas en las pruebas funcionales y de usuario.
También es responsable de las tareas técnicas de copia de desarrollos entre entornos.
Programadores: Reciben los diseños técnicos de los analistas técnicos y desarrollan
las funcionalidades o modificaciones indicadas en ellas. Realizan pruebas unitarias de
las modificaciones y si están correctas las indican a los analistas técnicos para su
revisión. En etapas de pruebas corrigen las incidencias que les reportan.
Usuarios Clave: Deberá haber un usuario clave por cada área o módulo principal de la
implementación. Estos usuarios, designados por el responsable de cada área, deberán
tener suficiente experiencia y autoridad para tomar las decisiones de alcance y dar el
visto bueno a la aplicación después de haber hecho las pruebas pertinentes. Además
deberán tener disponibilidad a tiempo completo en las fases de análisis (para definición
de requisitos y detalle del alcance) y pruebas (para la validar y dar la aceptación del
producto final). Adicionalmente, los usuarios clave impartirán la formación a usuarios
finales.
92
Usuarios Finales: Son todos los usuarios de la aplicación, tanto de los procesos de
recursos humanos, como de las aplicaciones de autoservicio. Potencialmente serán
todos los empleados del banco. Sin embargo sí se distinguen los propios usuarios del
área de Recursos Humanos como “usuarios profesionales”, pues el uso de la aplicación
forma parte de su trabajo diario. A todos los usuarios se les deberá dar la formación
apropiada. A los usuarios profesionales con cursos específicos, y a los usuarios de
autoservicio con presentaciones de autoayuda en la Intranet y campañas de
comunicación.
4.3.2. Definición de Entornos de Trabajo
Entendemos como “entornos” o “ambientes” diferentes instancias o implantaciones de la
herramienta PeopleSoft, en distintas bases de datos, que permiten separar las tareas
de desarrollo, de las pruebas, y la aplicación que está en producción.
Variará dependiendo de la política de la empresa, el presupuesto y la infraestructura
tecnológica disponible. Sin embargo, se deberá realizar en todas las implantaciones, es
decir, si se ha decidido replicar la implantación en bases de datos diferentes por país,
cada país deberá seguir el esquema decidido.
Se debe analizar si la infraestructura de entornos existente en la implantación actual es
suficiente o es necesario hacer algún cambio. A continuación describimos una
configuración máxima, e indicaremos qué entornos podrían ser prescindibles en un
esquema de mínimos.
Figura 15. Mapa de Entornos – Esquema de Máximos
93
Figura 16. Mapa de Entornos – Esquema de Mínimos
4.3.2.1. Demo o “Vanilla”
Es una implantación de PeopleSoft estándar, sin modificaciones, y con un conjunto de
datos de prueba entregados por PeopleSoft. Esta instalación es aislada (no está en la
cadena de paso a producción), y sirve como punto de comparación, estudio y validación
de funcionalidades estándar de la aplicación. Se puede refrescar cada cierto tiempo con
la versión original, pues con las pruebas suele registrarse mucha información inservible,
errónea o confusa, o cambiar configuraciones base. También sirve para aplicar los
parches o correctivos entregados por Oracle y validar si corrigen adecuadamente las
incidencias.
4.3.2.2. Desarrollo
El entorno de Desarrollo será el único origen de los nuevos desarrollos, así como de los
evolutivos y correctivos que se lleven a cabo en la aplicación. Los desarrollos de los
programas de cargas iniciales de la información también se llevarán a cabo en este
entorno.
Será el único entorno al que se tenga acceso a través de PeopleTools, y será también
al único al que se pueda acceder directamente a través de Oracle, tanto para visualizar
como para añadir o modificar información. Esto es muy importante. Si no se establece
un orden en cuanto a dónde se modifica, quiénes y cuándo, se corre el peligro de
desnivelar entornos, sobre escribir correcciones y generar más incidencias por
desarrollos descompensados entre entornos.
94
Los principales usuarios de este entorno serán los programadores, quienes, con base
en los diseños técnicos que se les habrá suministrado, realizarán las labores técnicas
pertinentes, tanto a nivel de aplicación como a nivel de base de datos.
Tras finalizar el desarrollo, los programadores las pruebas técnicas necesarias en este
mismo entorno.
Una vez finalizadas dichas pruebas, el analista técnico realizará una revisión de los
objetos afectados, y llevará a cabo otras pruebas mínimas de calidad, antes de solicitar
el paso de proyectos a los siguientes entornos. El entorno siguiente para la copia de
desarrollos es el de pruebas de sistemas.
En origen este entorno puede ser una instalación en blanco de PeopleSoft y
parametrizado en función de las necesidades del proyecto o una copia de vanilla.
También se puede refrescar alguna vez con datos de producción, pero esto es poco
frecuente debido a que se pueden borrar desarrollos en curso, y a la confidencialidad de
los datos de producción.
Como no contiene información real, los criterios de seguridad son básicos. El
mantenimiento del entorno corre a cargo completamente del equipo de sistemas,
incluyendo la creación o perfilado de nuevos usuarios.
Figura 17. Procedimiento de trabajo en entorno de Desarrollo
4.3.2.3. Pruebas de Sistemas
El origen de pruebas de sistemas será el equipo de desarrollo. El analista técnico, una
vez validado el producto en desarrollo, deberá solicitar a los administradores de
95
PeopleSoft el paso al entorno de pruebas de sistemas. Los principales usuarios o
agentes de este entorno serán los analistas técnicos y los analistas funcionales.
En primer lugar, los analistas técnicos realizarán un ciclo de pruebas orientadas
principalmente al ámbito técnico, verificando que los desarrollos cumplen con las
especificaciones del documento de diseño técnico. Si durante las mismas se detectasen
errores o deficiencias, éstas le serían comunicadas al equipo de desarrollo, quienes
realizarían las correcciones oportunas en el entorno de desarrollo.
Tras la validación del desarrollo por parte del analista técnico, el analista funcional
deberá realizar un ciclo de pruebas para constatar que el producto se corresponde con
los requerimientos del usuario, reflejados en el documento de análisis funcional.
Si el analista funcional detecta algún error o deficiencia en el producto, debe
comunicárselo al analista técnico, quien a su vez se lo comunicará al equipo de
desarrollo, para que proceda a la corrección en el entorno de desarrollo y
posteriormente en el entorno de pruebas de sistemas.
Una vez verificado el correcto funcionamiento del producto, se determinará la fecha de
solicitud de paso del proyecto al entorno de pruebas de usuario.
Las pruebas de los programas de cargas Iniciales con información ficticia también serán
realizadas en este entorno.
Desde este entorno se pasan desarrollos al entorno de pruebas de usuario, y,
eventualmente al de cargas iniciales.
Para migrar a pruebas de usuario, el analista funcional valida las pruebas y acuerda la
fecha de paso del proyecto. La decisión de migrar proyectos a cargas iniciales es del
departamento de diseño y desarrollo, quien decide el momento de realizarlo.
Normalmente se tenderá a que cargas Iniciales esté nivelado con pruebas de sistemas.
A nivel de datos, estos están más cercanos a lo real que los de desarrollo, pero aun así
su correspondencia con producción no es elevada. Se solicitará actualización periódica
de los datos.
96
Figura 18. Procedimiento de trabajo en entorno de Pruebas de Sistemas
4.3.2.4. Pruebas de Usuario
El entorno origen es pruebas de sistemas. Hay que tener en cuenta que los proyectos
no se migrarán al entorno de pruebas de usuario inmediatamente después de la
aprobación del analista funcional, para evitar posibles subidas no deseadas a
producción; esta migración se realizará en la fecha acordada con el usuario, cercana a
las fechas en las que ellos puedan realizar las pruebas.
Este criterio podría modificarse si fuera necesario, según las dependencias con otros
desarrollos.
En este entorno realizarán las pruebas funcionales tanto de usuarios clave como
usuarios finales, y serán ellos quienes decidan la fecha de paso a los siguientes
entornos.
Los entornos destino son producción y formación.
Al entorno de producción se pasa cuando las pruebas sean aceptadas en pruebas de
usuario, con las indicaciones específicas del usuario. Al entorno de formación se
pasarían proyectos sólo en los periodos en los que se considere necesario mantenerlo
actualizado por necesidades formativas.
Los datos en el entorno de pruebas de usuario serán próximos a los del entorno de
producción, con datos sensibles encriptados, y de un colectivo de empleados de
97
departamentos específicos. Se solicitarán actualizaciones periódicas para mantener el
alto grado de similitud con real, incluyendo la parametría completa.
Figura 19. Procedimiento de trabajo en entorno de pruebas de usuario
4.3.2.5. Formación
Se preparará este entorno cuando se vayan a impartir sesiones formativas. Los
proyectos que se pasen a formación, en caso de ser necesario, tendrán como origen
pruebas de usuario.
Todos los proyectos que se migren a producción también se deberán también migrar a
formación.
Los usuarios de este entorno serán los analistas funcionales, quienes prepararán las
sesiones de formación, y usuarios, quienes recibirán las sesiones de formación.
En algunas ocasiones este entorno también se habilita para que los usuarios se
familiaricen con la aplicación. Este acceso irregular sólo se permitirá durante el tiempo
que el entorno formación no sea necesitado para otros usos, incluyendo acciones de
formación en otros países.
No se pasarán proyectos del entorno de formación a ningún otro entorno.
Cuando se vayan a realizar sesiones de formación se preparará el entorno en función
de las necesidades, valorándose junto con los usuarios.
98
4.3.2.6. Cargas Iniciales
El entorno de cargas iniciales está destinado a que el usuario realice las validaciones de
cargas iniciales. Todos los proyectos que se migren a producción también se deberán
migrar a cargas iniciales. El origen será pruebas de usuario. No se pasarán proyectos
de cargas iniciales a ningún otro entorno.
Previo al inicio de la validación de cargas iniciales, se hará una copia del entorno de
producción en este entorno, para simular una puesta en producción real. Además,
permitirá hacer pruebas de regresión sobre los países ya implementados. El nivel de
seguridad en este entorno será el mismo que en producción
4.3.2.7. Producción
Al entorno de producción se pasarán los proyectos que hayan sido validados
previamente por los usuarios en el entorno de pruebas de usuario.
Todos los proyectos que se encuentren en producción deberán estar también
obligatoriamente en cargas iniciales y formación.
Los únicos agentes que operarán en producción serán los usuarios que RRHH estime
oportuno, pues hay información sensible que debe ser tratada con la confidencialidad
adecuada.
No se pasarán proyectos del entorno de producción a ningún otro entorno.
4.3.3. Definición de Plazos
En esta etapa se hace el planteamiento inicial de los plazos, ya sea para el país en
específico o para todo el despliegue de los países. Estos plazos, que en esta etapa se
definen a modo de requerimiento, deberán ser confirmados en la etapa de análisis, tras
una valoración detallada del proyecto.
99
4.3.4. Criterios de Calidad
Normalmente en estos proyectos los criterios de calidad de definen como el
cumplimiento de los requerimientos dentro de los estándares de desarrollo definidos por
el corporativo.
En cuanto a infraestructura, tecnología y comunicaciones, se deberán seguir los
criterios de calidad establecidos en las políticas de cada tema tales como tiempo de
respuesta de la Intranet, tiempo de respuesta de PeopleSoft, capacidad de
almacenamiento, etc.
4.3.5. Detección de Riesgos
Tal como se indica en el capítulo anterior, se hará el primer esfuerzo de detección de
riesgos. Se deberán valorar todos los posibles riesgos, dado el nivel de análisis a este
momento. Se deberán identificar aquéllos inherentes a la clase de proyecto y al país. Se
deberán tomar en cuenta factores socio-políticos y externos a la empresa, pero también
aquéllos que se deriven de la cultura y política interna del país. Uno de los elementos a
tener en cuenta debe ser la diferencia horaria y la disponibilidad de los equipos.
Lo más efectivo es hacer sesiones de lluvia de ideas para completar el documento.
4.3.6. Documentación de Requerimientos
El objetivo es obtener un catálogo detallado y cerrado de los requisitos de la solución, a
partir del cual se pueda comprobar que los productos generados en las actividades de
modelado, se ajustan a los requisitos del cliente.
También se han de analizar las necesidades solicitadas por el cliente e identificar los
requisitos correspondientes a dichas necesidades.
Se estudiará el alcance con los clientes para generar el catálogo de requisitos del
cliente. Deberá prestarse especial atención en el objetivo del proyecto, utilizando un
lenguaje comprensible por el cliente.
100
Se identificarán los requisitos relacionados con las necesidades del negocio, es decir,
las funcionalidades básicas solicitadas.
Se deberán identificar, desde el punto de vista del cliente, las necesidades no
directamente relacionadas con la funcionalidad, sino con el nivel de servicio, seguridad,
interacción con el usuario y los cambios organizativos.
Para los distintos requisitos identificados, definir sus prioridades y dependencias, en
función del criterio del cliente.
Por último, se deberán garantizar que todos los requisitos se encuentran dentro del
alcance del proyecto.
4.3.7. Entregables
En esta fase se generan los siguientes entregables:
Documento de identificación de requisitos del cliente.
Conformación de infraestructura de entornos.
Documento riesgos potenciales y su valoración.
Organigrama y estructura del equipo de proyecto.
Definición inicial del alcance, con plazos.
Definición de documentos de calidad.
4.4. Fase de Análisis
El objetivo de la fase de análisis es detallar el alcance del sistema, mediante modelos
iniciales de alto nivel y detallando el funcionamiento que deberá tener cara a los nuevos
usuarios. Se hace un inventario completo de los requerimientos desglosándolos detalle
a detalle, de forma que se obtenga una lista completa de los procesos del sistema.
4.4.1. Talleres de Análisis
Se organizan talleres de análisis y levantamiento de requerimientos de detalle con los
usuarios clave y personas relevantes del área. Se realizará un taller por módulo de
101
PeopleSoft. Cada taller tendrá la duración necesaria para estudiar al detalle todos los
aspectos del proceso.
Como estos talleres se tienen que hacer con los usuarios, y pueden participar más
personas, además de los usuarios clave, se recomienda hacerlos presencialmente en el
país de destino.
Los participantes de los talleres serán:
Usuarios clave del proceso a estudiar.
Otros usuarios para el proceso, ya sea porque resulten afectados o puedan
aportar información adicional.
Líder funcional.
Analista funcional del módulo.
Líder y/o analista técnico. Aunque no es requisito, es recomendable que se vaya
familiarizando con el tipo de requerimientos que pueden surgir.
Como estos talleres se tienen que hacer presencialmente con los usuarios, y pueden
participar más personas, además de los usuarios clave, se recomienda hacerlos
presencialmente en el país de destino. Para cada taller se deberá llevar un acta de
reunión que se entregue a cada participante cada día de reunión para su validación.
4.4.1.1. Estructura de la empresa – Configuración del Sistema
Los analistas deberán conocer cuál es el funcionamiento del banco en el país destino.
Se conocerá su estructura, procedimientos, líneas de autoridad, seguimiento y apoyo a
empleados, etc. Además se deberá obtener información sobre a cuántas empresas se
les da soporte desde el área de Recursos Humanos, a cuántas empresas se les paga la
nómina, cuántos empleados por empresa, procesos en cada área, requerimientos
legales, plazos y tiempos de respuesta.
A partir de esta información se deberá poder derivar la parametría del sistema para la
incorporación del país a PeopleSoft.
102
4.4.1.2. Análisis Fit-Gap
En los talleres se llevará a cabo un análisis Fit-Gap, que tiene como objetivo comparar
la funcionalidad estándar establecida en la implantación actual, con las necesidades del
país destino, y determinar cuál es la mejor forma de resolver las diferencias. Se
recomienda hacer el menor número de modificaciones posible, pues cada variación
puede afectar al modelo global o provocar que cada país se vaya alejando de ese
modelo.
4.4.1.3. Análisis Cargas Iniciales
Adicionalmente, en los talleres se deberá validar qué información se cargará desde el
sistema anterior hacia PeopleSoft. Dentro de ese análisis se deberá incluir:
Profundidad histórica de la información a cargar: es importante tomar en cuenta que
mientras más historia se incluya, será más difícil el proceso de limpieza de información
y es más probable encontrar inconsistencias en los datos. Sobre todo tomando en
cuenta que en este tipo de empresas típicamente ha habido procesos de fusión y
compra de empresas, con su correspondiente carga inicial de información y pérdida de
calidad.
Volumen: Para cada concepto a cargar, se deberá conocer el volumen de datos a
cargar. Este dato determinará si se realiza automáticamente (por proceso) o
manualmente.
Origen: Se deberá conocer en qué sistema reside cada información. Habitualmente la
mayor parte de información se encontrará en el sistema de gestión de recursos
humanos, pero muchos otros cálculos o seguimientos de información se suelen llevar
en Excel u otras herramientas informáticas. Adicionalmente habrá que contemplar otros
sistemas de atención a empleados: autoservicios, formación a empleados, etc.
Calidad de la información: En un análisis preliminar, y a criterio de los usuarios, se
determinará el nivel de calidad de la información que existe actualmente. Los usuarios
son los que mejor conocen la información y pueden decir a qué le dedican más
103
esfuerzo. Sin embargo, es necesario confirmarlo posteriormente, en la fase de diseño,
utilizando herramientas de análisis más completo.
4.4.2. Generación de Documentos de Análisis por Módulo
Una vez finalizados los talleres, los analistas deberán consolidar toda la información
obtenida para generar los documentos con el detalle. Deberá existir una explicación,
módulo a módulo, porque este análisis ya se hace desde el punto de vista de la
aplicación y no del proceso, cuál será el uso que se le dará dentro a cada elemento del
proceso, qué información se cargará, la definición de la parametría del sistema y una
relación de las modificaciones a realizar en el sistema. Deberán describirse claramente
las modificaciones, pero a nivel general, pues se generará un documento de detalle
(descrito en el siguiente punto).
Adicionalmente, se deberán indicar los criterios de conversión para la carga inicial de la
información.
4.4.3. Generación de Documentos de Detalle por Modificación
Para cada modificación identificada en el análisis, se hará un documento de detalle.
Después de analizar el impacto de la modificación en la aplicación, se incluirán
ejemplos o prototipos de las pantallas y se describirá el detalle de su funcionamiento.
Se deberán detallar los tratamientos.
Este trabajo lo deberán desarrollar en conjunto los analistas funcionales con los
analistas técnicos, que pueden valorar a nivel técnico el impacto en la aplicación.
Conforme se vayan finalizando los deberá validar el líder funcional en conjunto con el
líder técnico.
4.4.4. Generación de los Guiones de Prueba
En función de los documentos de análisis y los detalles por módulo, se generará la
primera versión de los guiones de prueba. Las pruebas deberán asegurar que se
104
cumplen los criterios establecidos dentro de los documentos de análisis, por lo que se
pueden estructurar desde este momento.
Además de probar el funcionamiento de la aplicación y el comportamiento de las
modificaciones, se deberán incluir pruebas para la validación de la información de la
carga inicial.
4.4.5. Cierre y Aprobación de los documentos
Una vez finalizados y validados por los líderes técnicos, los documentos se le harán
llegar a los usuarios clave y los participantes adicionales de los talleres quienes
deberán dar su visto bueno del contenido o hacer comentarios y solicitar las
modificaciones pertinentes.
Finalmente se deberá obtener la aprobación de todos los usuarios clave, incluyendo los
del corporativo, pues deberán aprobar los cambios que se hagan al uso actual del
sistema y que los cambios estén dentro de la política corporativa.
El conjunto de estos documentos cierra el alcance del proyecto. Todo lo que surja
posteriormente al análisis, se valorará contra los documentos de análisis para confirmar
si es un cambio de alcance.
Esta autorización podrá ser por escrito con firma autógrafa, o por correo electrónico a
todos los involucrados adjuntando el documento que aprueba.
4.4.6. Cierre y Aprobación de la Fase de Análisis
Una vez validados los documentos de análisis, los usuarios clave, los promotores del
proyecto y el líder de proyecto deberán confirmar su aprobación de la fase de análisis y
la autorización para continuar con la fase de diseño.
Esta autorización podrá ser por escrito con firma autógrafa, o por correo electrónico a
todos los involucrados.
105
4.4.7. Entregables
En esta fase se generan los siguientes entregables:
Actas de talleres.
Documento de análisis por módulo (incluyendo parametría, relación de
modificaciones y criterios de cargas iniciales).
Documentos de detalle de modificaciones.
Guiones de pruebas.
Aprobaciones de documentos de análisis (de módulo y de detalle).
Aprobación de cierre de la fase de análisis.
4.5. Fase de Diseño Técnico
El objetivo de esta fase es obtener el diseño detallado de los componentes del sistema
a partir de la información generada durante la fase de análisis. El trabajo en esta fase
principalmente es desde el punto de vista técnico, aunque se cierran entregables de
diversos tipos.
Las modificaciones inventariadas en el análisis se estudiarán a detalle para identificar la
solución técnica idónea. Aunque los lineamientos de la solución ya se establecen desde
la fase de análisis, en el diseño técnico se investiga qué herramienta técnica es la más
adecuada para cada problema. Por ejemplo, si existe una solicitud de realizar una
consulta de datos, se puede generar un informe a medida con la herramienta Crystal
Reports, una consulta por pantalla con criterios de búsqueda o generar una consulta
con la herramienta de gestor de consultas para acceso directo por el usuario. Los
criterios para decidir la solución técnica idónea deben ser:
Grado de adecuación al estándar: Potenciando aquellas soluciones que
impliquen un menor grado de desviación con respecto al modelo base.
Desempeño de la aplicación: Asegurando que no se castigue el funcionamiento
para el propio usuario que trabaja, otros usuarios, o procesos en segundo plano.
“Usabilidad”: Buscando en todo momento que se requieran la menor cantidad de
pasos y pantallas para realizar una acción.
106
Integridad: Asegurando que se mantiene la integridad de la información.
Uniformidad: Siguiendo los lineamientos del resto de funcionalidades.
Unicidad: Evitando duplicidad de funciones o redundancia entre procesos y
procedimientos.
Los diseños técnicos se plasman en un documento que deberá contener toda la
información necesaria para que los programadores desarrollen las funcionalidades
siguiendo la siguiente estructura:
4.5.1. Diseño de Estructura de Datos
Se debe definir si es necesario realizar modificaciones a la estructura de datos existente
asegurando en todo momento que se mantiene la relación entre la información y
siguiendo los criterios que marca la aplicación. Las tareas a realizar son:
Definir la estructura de tablas indicando sus características, los atributos que la
componen y los índices por los que se accede a ellas, para nuevas tablas o
modificaciones.
Realizar una estimación aproximada del volumen de datos que se almacenará en
cada una de las tablas, el nivel de utilización, crecimiento, nivel de paginación
virtual, etc., para poder optimizar los accesos a ellas y asignar el “tablespace”
adecuado.
Detectar posibles mejoras con el fin de conseguir mejores niveles de rendimiento.
4.5.2. Diseño de la Interfaz Visual de Usuario
Para los casos en que sea necesario, se debe realizar el diseño técnico de las
pantallas, informes y todos los elementos que el usuario visualice en la aplicación. Se
deberán relacionar los objetos necesarios para su desarrollo (menús, componentes,
páginas, tablas y validaciones) y definir el comportamiento esperado. Se deberá incluir
asimismo un bosquejo del formato deseado.
107
4.5.3. Diseño de Procesos en Lote o “Batch”
Si se ha identificado la necesidad de generar programas de procesamiento en lote,
deberemos detallar sus requisitos de ejecución y los pasos que los componen.
Asimismo, deberá definirse la estructura final del proceso agrupando en cadenas los
procesos que se ejecutan en paralelo, así como su integración en los ciclos de la
instalación, con las condiciones y requisitos necesarios para su ejecución.
En esta fase se detallan todos los pasos y requisitos que describirán la ejecución del
proceso, describiendo toda la información que permita al programador realizar el
desarrollo de forma adecuada.
Debe establecerse la agrupación en cadenas de las operaciones, así como su
integración en los ciclos batch de la instalación, con las condiciones y requerimientos
necesarios para su ejecución. Definir el objetivo, características, periodicidad,
condiciones de ejecución y elementos de entrada y salida de cada una de las cadenas
definidas. Adaptar en ciclos de producción del proceso en función de los requisitos de
dependencias, horas de ejecución, periodicidad y reglas de planificación en general.
4.5.4. Revisión de Diseño
Durante las tareas anteriores y al finalizar, se deberá asegurar que el diseño físico del
modelo de datos y procesos es el adecuado para un buen rendimiento de la aplicación
en producción. También se deberá asegurar que el diseño de la aplicación encaja
adecuadamente en el ciclo diario de las aplicaciones en producción, facilitando la
explotabilidad del mismo y asegurar que el diseño del modelo de datos y procesos es el
más adecuado para cumplir los estándares de rendimiento y utilización de recursos de
la instalación.
Los equipos de desarrollo deberán contactar con los responsables de la revisión del
diseño para que analicen las mejores soluciones que se pueden aplicar a diseños
concretos y busquen incumplimientos y posibles riesgos.
108
Se aplicarán las recomendaciones de diseño y construcción de aplicaciones de la
propia organización.
En el caso de que se detecte algún punto a mejorar, se plantearán y valorarán
alternativas para solucionarlos.
4.5.5. Diseño Detallado.
Una vez revisado el diseño se deberá generar la documentación que permita a los
desarrolladores a construir la funcionalidad. Se deberán establecer buenas prácticas de
desarrollo y una nomenclatura uniforme que todos comprendan.
4.5.6. Preparación de Entornos
El objetivo de esta tarea es preparar los entornos necesarios para abordar los
desarrollos y las pruebas definidas en actividades anteriores. Las tareas a realizar son:
Preparación del entorno de desarrollo: Analizar requisitos y acciones necesarias
para la preparación del entorno, instalar hardware, herramientas software,
software de comunicaciones, repositorios, espacios de trabajo (estructura de
directorios y el objetivo específico de cada uno de ellos), así como definir puestos
de trabajo y ubicaciones de los mismos. Definir detalladamente el entorno de
desarrollo y pruebas unitarias necesario para la construcción de los componentes
del sistema de información y crear los procedimientos de trabajo y estándares de
nomenclatura a utilizar.
Preparación del entorno de pruebas: Identificados los requisitos y acciones
necesarias para la preparación del entorno, solicitar su realización al área
correspondiente y verificar que el entorno se encuentra tal y como se requiere
para la realización de las pruebas.
Preparación del entorno de certificación: Identificados los requisitos y acciones
necesarias para la preparación del entorno, solicitar su realización al área
109
correspondiente y verificar que el entorno se encuentra tal y como se requiere
para la realización de las pruebas técnicas.
Preparación del entorno de usuario: Identificados los requisitos y acciones
necesarias para la preparación del entorno, solicitar su realización al área
correspondiente y verificar que el entorno se encuentra tal y como se requiere
para la realización de las pruebas de usuario.
Preparación del entorno de formación: Identificados los requisitos y acciones
necesarias para la preparación del entorno, solicitar su realización al área
correspondiente y verificar que el entorno se encuentra tal y como se requiere
para la realización la formación.
Preparación del entorno de producción: Identificados los requisitos y acciones
necesarias para la preparación del entorno, solicitar su realización al área
correspondiente y verificar que el entorno se encuentra tal y como se requiere
para la explotación de la funcionalidad.
4.5.7. Diseño de Pruebas
El objetivo de esta tarea es diseñar las pruebas funcionales y técnicas de la
funcionalidad a desarrollar. Se deberán desarrollar los siguientes planes de pruebas:
4.5.7.1. Pruebas Técnicas.
Pruebas unitarias: Se desarrollará un plan de pruebas unitarias que garantice el
cumplimiento de los requisitos como unidad individual e indivisible desde el punto
de vista técnico.
Pruebas integradas: Se desarrollará un plan de pruebas de integración con
terceros sistemas que garantice el cumplimiento de los requerimientos de
integración técnica entre los terceros sistemas y PeopleSoft.
110
Pruebas de rendimiento: Se desarrollará un plan de pruebas de carga y
rendimiento que garantice el cumplimiento de los requisitos de desempeño del
sistema. Estas pruebas permitirán determinar el correcto dimensionamiento de
servidores y bases de datos, así como la correcta integración con terceros
sistemas.
4.5.7.2. Pruebas Funcionales.
Pruebas unitarias: Se desarrollará un plan de pruebas unitarias que garantice el
cumplimiento de los requisitos como unidad individual e indivisible desde el punto
de vista funcional.
Pruebas integradas: Se desarrollará un plan de pruebas integradas que garantice
el cumplimiento de los requerimientos funcionales de los procesos de principio a
fin.
4.5.8. Plan de Implantación
Se deberá generar un plan de implantación que describa las actividades, fases e hitos
de entrega de la construcción de la funcionalidad. Este plan de implementación debe
estar alineado al plan de proyecto general.
Dentro de las actividades del plan de implantación está la definición de procesos,
transacciones y rutinas necesarias para la instalación, mecanismos de control,
seguridad y recuperación del sistema así como la correcta carga de datos necesarios
para cada entorno.
4.5.9. Validación y Aprobación del Diseño
Se deberá asegurar que el diseño del sistema cumple con las especificaciones
solicitadas en fase de análisis de tal forma que se garantice la calidad de la
funcionalidad a desarrollar. Para ello se deberán validar los documentos de diseño
técnico, configuración de entornos, planes de pruebas e implantación.
111
En caso de existir inconsistencias en el diseño técnico, se deberán documentar como
incidencias en diseño para que sean tratadas y resueltas de forma coordinada.
4.5.10. Entregables
En esta fase se generan los siguientes entregables:
Actas de talleres.
Documento de diseño general.
Documento de diseño detallado (opcional).
Documento de configuración de entornos.
Planes de pruebas.
Plan de implantación.
4.6. Fase de Construcción
En esta fase los desarrolladores utilizan el diseño técnico detallado para construir las
funcionalidades especificadas. Esta documentación deberá describir la interfaz visual de
usuario, reglas de negocio y la información que debe manejar en cada caso.
4.6.1. Construcción del Código.
Se deberán generar los ficheros de configuración y de tablas maestras a implementar
en el sistema.
El desarrollador deberá utilizar la herramienta People Tools para generar las pantallas y
la lógica de negocio que cumpla con las especificaciones. Deberá tener en cuenta los
estándares y nomenclatura de codificación que se haya establecido en la fase de
diseño así como deberá construir los mensajes de error y ayuda al usuario en función
de las especificaciones y de los estándares del proyecto.
Adicionalmente se deberá generar la documentación de construcción y mantenimiento
de los programas desarrollados. Esta documentación deberá contener las
especificaciones técnicas del desarrollo, las condiciones de su implementación y
mantenimiento.
112
4.6.2. Ejecución de Pruebas Unitarias.
Las pruebas unitarias se ejecutarán en base a lo especificado en el plan de pruebas
unitarias el cual contiene una serie de casos de pruebas que verifican la especificación
del diseño técnico.
Estas pruebas permitirán al desarrollador garantizar el funcionamiento de los paquetes
de código de forma independiente.
4.6.3. Ejecución de Pruebas de Integración entre sistemas.
En estas pruebas se involucran todos los sistemas con los que la aplicación va a
interactuar. Por lo que se deberán ejecutar en forma conjunta para garantizar el
cumplimiento de los requisitos de integración. En esta fase se podrán realizar pruebas
con cada uno de los sistemas involucrados de forma independiente ya que no se
pretende probar la aplicación en su conjunto sino de cada una de sus partes.
Se deberán documentar las incidencias encontradas para su posterior corrección. Una
vez corregidas las incidencias se deberán ejecutar de nuevo las pruebas entre
sistemas.
4.6.4. Elaboración del Manual de Operación.
Es necesario contar con la elaboración de un manual de especificaciones técnicas del
funcionamiento de la nueva aplicación. Este manual deberá contener, además, las
tareas a realizar por parte del administrador del sistema para la puesta en marcha y
mantenimiento de la aplicación.
4.6.5. Validación y Cierre de las Pruebas Unitarias.
Una vez que se han superado satisfactoriamente las pruebas unitarias, se deberá
validar mediante un informe de resultado de pruebas que demuestre su cumplimiento.
Se deberá presentar también el manual de operaciones.
113
4.6.6. Entregables
En esta fase se generan los siguientes entregables:
Informe de ejecución de pruebas unitarias.
Manual de operación del sistema.
4.7. Pruebas Funcionales
4.7.1. Implementación en Entorno de Pruebas de Sistemas.
Para realizar las pruebas funcionales será necesaria la preparación de un entorno con
las condiciones de datos y código creado para la nueva funcionalidad. Será necesario
prever una carga inicial de datos de prueba suficiente para ejecutar el plan de pruebas
en varias veces.
4.7.2. Ejecución de Pruebas Funcionales.
La ejecución de las pruebas funcionales se debe llevar a cabo conforme a lo definido en
el plan de pruebas entregado.
4.7.3. Soporte a la Ejecución de Pruebas.
Dentro de la estructura del proyecto se deberá determinar el equipo de personas
responsables preparar los datos y casos de prueba, ejecutar las pruebas, analizar los
resultados y determinar las acciones correctivas en caso de incidencias.
Dentro de las pruebas funcionales se deberán realizar pruebas de regresión tantas
veces sea necesario hasta que el 100% de los requisitos estén comprobados. Estas
pruebas están sujetas a las modificaciones al sistema provocadas por cambios de
alcance, corrección de incidencias o mejoras en evolutivo.
Se deberá generar un informe de resultado de las pruebas que demuestren que se han
cumplido el 100% de los requisitos.
114
El manual de operación deberá ser actualizado con los cambios que pudiera sufrir el
sistema debido a cambios de alcance, modificaciones por corrección de errores o
mejoras en evolutivo.
4.7.4. Ejecución de Pruebas Técnicas.
Estas pruebas están definidas para verificar, entre otras cosas, el comportamiento del
sistema ante la concurrencia con otras aplicaciones, el rendimiento de los procesos y la
gestión de los errores.
Se realizan pruebas de volumen, estrés u otro concepto, con el fin de comprobar el
comportamiento del sistema ante estos aspectos más concretos.
Se determinará la herramienta más adecuada para la ejecución de las pruebas, de igual
forma se deberá seguir un plan de pruebas de carga y rendimiento de los sistemas
involucrados.
Se deberá generar un informe que muestre el resultado de las pruebas y su contraste
con los umbrales mínimos aceptados por el proyecto.
4.7.5. Validación y Cierre de la Fase de Pruebas Funcionales.
Una vez que se han superado satisfactoriamente las pruebas funcionales y técnicas, se
deberá validar mediante sendos informes de resultado de pruebas que demuestre su
cumplimiento.
4.7.6. Entregables
En esta fase se generan los siguientes entregables:
Informe de ejecución de pruebas funcionales.
Informe de ejecución de pruebas técnicas.
Manual de operación del sistema actualizado.
115
4.8. Pruebas Integradas
4.8.1. Implementación en Entorno de Pruebas Integrales.
Estas pruebas se caracterizan por su ejecución en colaboración de los usuarios clave
determinados en la estructura del proyecto.
El objetivo es la ejecución exhaustiva, desde el punto de vista del usuario, de toda la
funcionalidad incluyendo las integraciones con terceros sistemas.
Para ello es necesaria la preparación de un entorno adecuado que contenga toda la
funcionalidad desarrollada, juegos de datos suficientes para inducir errores controlados
y las integraciones con el resto de sistemas.
4.8.2. Ejecución de Pruebas Integrales.
Se deberá determinar el equipo de personas que ejecutarán las pruebas integradas, el
tiempo de ejecución y el acuerdo de nivel de servicio para la corrección de las
incidencias detectadas.
Se deberá ejecutar el plan de pruebas definido para la aplicación y se dará seguimiento
de las incidencias, se deberán corregir en el plazo y condiciones estipuladas en el
contrato del proyecto.
Se deberá generar un informe de resultado de las pruebas que demuestren que se han
cumplido el 100% de los requisitos.
4.8.3. Elaboración del Manual de Usuario.
En esta fase se deberá generar el manual de usuario que servirá de base para la
posterior formación de los usuarios finales.
Este manual deberá ser escrito de forma sencilla pero clara evitando el abuso de
términos muy técnicos o poco familiares para el usuario final.
116
4.8.4. Preparación del Entorno de Producción.
Superadas las pruebas integrales y habiendo detectado y resuelto las incidencias se
debe preparar el entorno de formación (en caso de que sea distinto del de pruebas) y
producción incluyendo todas las modificaciones derivadas de cambios de alcance,
incidencias o mejoras en evolutivo.
El entono de producción deberá garantizar su correcta instalación, tanto de la parte de
hardware como de los desarrollos propios de la aplicación, así como de la configuración
para integrarse con el resto de sistemas implicados.
4.8.5. Validación y Cierre de Pruebas Integradas.
Una vez que se han superado satisfactoriamente las pruebas integrales, se deberá
validar mediante un informe de resultado de pruebas que demuestre su cumplimiento.
4.8.6. Entregables
En esta fase se generan los siguientes entregables:
Informe de ejecución de pruebas integrales.
Manual de usuario.
4.9. Formación
4.9.1. Implementación en Entorno de Pruebas de Formación.
Se deberá preparar el entorno de formación a usuarios garantizando el acceso de
usuarios de formación y datos suficientes para realizar simulaciones.
4.9.2. Elaboración del Manual de Usuario.
Se deberá actualizar el manual de usuario a entregar en la fase de formación
incluyendo toda la funcionalidad así como las modificaciones derivadas de cambios de
alcance, corrección de incidencias y mejoras en evolutivo.
117
4.9.3. Impartición de la Formación.
Un equipo definido en la estructura del proyecto se encargará de impartir la formación al
usuario final. Se deberán garantizar el correcto funcionamiento del entorno de
formación, el acceso a usuarios de formación, datos suficientes y ejercicios preparados
para el usuario, así como las instalaciones y el material didáctico de apoyo a utilizar en
cada sesión.
4.9.4. Entregables
En esta fase se generan los siguientes entregables:
Manual de usuario actualizado.
4.10. Puesta en Producción
4.10.1. Implementación en Entorno de Producción.
Se deberá verificar la correcta instalación del entorno de producción, tanto de hardware
como de la funcionalidad desarrollada en el proyecto, incluyendo la configuración para
su integración con el resto de sistemas involucrados.
Se deberá definir un plan de puesta en producción que determine las tareas, las
condiciones y dependencias de instalación de la nueva funcionalidad. El plan de puesta
en producción deberá contar con las acciones a realizar en caso de fallo de instalación
para poder restaurar el punto inicial del sistema.
Se impartirá formación al equipo encargado de mantener en buen funcionamiento al
sistema basado en el manual de operación.
4.10.1. Soporte a Usuarios.
Se determinará un equipo que dará soporte a los usuarios finales resolviendo dudas de
formación y registrando incidencias del sistema.
118
4.10.2. Entregables
En esta fase se generan los siguientes entregables:
Informe de instalación del entorno productivo.
4.11. Aceptación del Proyecto
En este hito se cumple con la entrada real en producción de la nueva funcionalidad. El
cliente deberá aceptar o rechazar el proyecto conforme al cumplimiento de los
requisitos del sistema y al nivel de incidencias reportadas.
4.11.1. Entregables
En esta fase se generan los siguientes entregables:
Carta de aceptación del proyecto.
119
CONCLUSIONES
Existe una amplia oferta de soluciones en el mercado que se deben evaluar al tomar la
decisión de implementar un software de gestión de Recursos Humanos. Estos
proyectos requieren una gran inversión en tiempo, dinero y recursos, y las decisiones
no se deben tomar a la ligera.
Se deben evaluar elementos como el tamaño de la empresa, proyección internacional,
casuísticas especiales, infraestructura, necesidades de negocio, etc.
Claramente SAP y PeopleSoft ofrecen las alternativas más fuertes de mercado, sin
embargo, en el área de Recursos Humanos PeopleSoft tiene mucha más experiencia y,
por tanto, el producto que entregan a día de hoy está mucho más depurado y puede
guiar mejor hacia las “best practices” de Recursos Humanos.
Aun así, siempre hay que tener en cuenta que no hay herramientas perfectas y que en
el camino de la implementación se deberán resolver muchos problemas técnicos y
resolver diferencias entre el esquema planteado por la herramienta y las necesidades
reales.
La banca típicamente ha cumplido el rol de “punta de lanza” tecnológico en el sector
servicios. Esto es por un lado, por sus necesidades de expansión y, por otro, porque
cuenta con la infraestructura económica y tecnológica necesaria.
Esta robustez, también tiene su reflejo en la complejidad de los proyectos de sistemas a
implementar. En específico, en Recursos Humanos, esta dificultad está representada
por el volumen de empleados, la conciliación de necesidades globales y locales, y la
dispersión geográfica.
Siguiendo la metodología propuesta por el Project Management Institute pasamos por
todos los elementos del proyecto, teniendo la opción de darle a cada proceso la
relevancia que merezca según la complejidad del proyecto.
120
En una organización bancaria contamos con infraestructura técnica, organizativa, de
políticas y procedimientos que forman a la vez una base y una restricción para el
proyecto. Algunas veces ayudan y otras aportan un factor de burocracia al proyecto.
De todos estos procesos, resaltamos como más críticos la gestión del alcance y la
gestión de los recursos. El primero porque nos definirá el marco de acción alrededor del
que todos están de acuerdo y se definirán las actuaciones de toda la vida del proyecto.
No se debe iniciar el proyecto hasta no estar cerrado el alcance.
El segundo, porque los recursos PeopleSoft con experiencia en Recursos Humanos son
escasos y caros. El impacto de tener un mal equipo de proyecto es muy alto y los
riesgos en costo y tiempo son muy elevados.
En todos los procesos contamos con el factor distancia, pues a pesar de que la
tecnología acerca a la gente, aunque esté a un océano de distancia, se dificulta el
control del día a día y la diferencia horaria disminuye la ventana de tiempo de trabajo
conjunto.
Por último, hay que tener en cuenta las diferencias legales y culturales en ambos países
y lograr compaginar las políticas corporativas con las necesidades locales y el beneficio
común.
Desde el punto de vista académico, cabe destacar que los conocimientos adquiridos
durante la carrera me han permitido desarrollar esta tesis. Por una parte, la sólida base
de conocimientos informáticos con asignaturas como Programación Computacional,
Estructura de Bases de Datos o Análisis y Diseño de Sistemas ha contribuido a la
comprensión y aplicación de sistemas informáticos complejos como un ERP. Por otra
parte, la orientación propia de la carrera de Ingeniería Industrial ha permitido la
capacidad de planificación, administración, ejecución y control de proyectos de gran
escala como lo es la implementación de un ERP en un corporativo de escala mundial.
121
BIBLIOGRAFÍA
Anderson, L., & Gemini, C. (2001, EEUU). “Understanding PeopleSoft 8”. San
Francisco: Sybex Inc.
ARC Advisory Group (Junio 15, 2007), “ERP Market to Reach $25 Billion by 2011”
Supply Chain Brain magazine. http://www.supplychainbrain.com/content/nc/world-
regions/middle-eastafrica/single-article-page/article/erp-market-to-reach-25-billion-by-
2011/ (Consultada en Enero 27, 2009).
Benvenuto, A, (2006) “Implementación de Sistemas ERP, su Impacto en la Gestión de
la Empresa e Integración con Otras TIC”. Chile: CAPIC Review, Vol. 4, 2006.
(Conferencia académica permanente de Investigación Contable.
http://www.capic.cl/capic/media/ART3Benvenuto.pdf (Consultada en Enero 27, 2009).
Blumenthal, Sherman C., (1969, EEUU). “Management Information Systems: A
Framework for Planning and Control”. EEUU: Pretince Hall.
BSCH, web corporativa. www.santander.com. (Consultada en Febrero 2009).
Castells, Manuel et al (1986, España) “El Desafío Tecnológico. España y las Nuevas
Tecnologías”. España: Alianza Editorial.
Comercio Electrónico Global (Octubre 28, 2006) “ERP En España” http://e-
global.es/b2b-blog/2006/10/28/erp-en-espana/ (Consultada en Enero 28, 2009).
Cuesta, A. & Martínez, R. (1995, Cuba). “Aplicación de un modelo de gestión de
recursos humanos (grh). Acción de la ergonomía participativa y diseño de actividades
claves de grh”. La Habana: ponencia en el FORUM de Ciencia y Técnica del ISPJAE.
Cuesta, A. (1996, España) “Tendencias actuales en la gestión de recursos humanos
(grh). Necesidad del modelo funcional de grh”. En revista Factores Humanos, No 10.
Madrid. Ed: I+D Telefónica.
122
Forrester (Sept. 28, 2006). “The Forrester Wave™: Human Resource Management
Systems, Q3 2006”
http://www.forrester.com/Research/Document/Excerpt/0,7211,40072,00.html
García López, A. (1999, España). “Una historia de la banca española a través de sus
documentos”. España: Lex Nova.
García, S. (1995, España) “De la economía protegida a la economía competitiva: En la
nueva gestión de recursos humanos”, Barcelona. Ed: Gestión 2000.
González, M., Anes, R. y Mendoza I. (2007, España). “Ciento cincuenta años, ciento
cincuenta bancos”. España: BBVA.
Herrera Lemus, C. (Junio, 2005). “Sistema de Gestión de Recursos Humanos:
Caracterización Para su Aplicación En Las Empresas”, Revista Gestiopolis. Consultada
en febrero 2009. http://www.gestiopolis.com/canales5/rrhh/reaplica.htm
Hijón Neira, Raquel (2005, España): “Utilización del sistema SAP R/3” España:
Universidad Pontificia Comillas (ICAI-ICADE), Colección Ingeniería
Hitt, L., Wu D.J. y Zhou X. (2002). “ERP Investment: Business Impact and Productivity
Measures”. Journal of Management Information Systems, Volume 19, Issue 1, p.71-98,
http://grace.wharton.upenn.edu/~lhitt/erp.pdf (Consultado en Enero 27, 2009).
HR Access Solutions Corporate webpage. http://www.hraccess.es/155-
162/soluciones.htm (Consultada en Febrero 2009).
Inversiones, Blog sobre Inversiones económicas (Nov. 2006).
http://inversores.es/santander-y-latinoamerica-bbva-y-citicbank/ (consultada en Febrero
2009).
Kumar, K., y Hillengersberg, J. (2000). “Enterprise resource planning: Introduction.
Communications of the ACM”, 43(4), 22-26. http://0-
delivery.acm.org.millenium.itesm.mx/10.1145/340000/332063/p22-
123
kumar.pdf?key1=332063&key2=8889879211&coll=portal&dl=ACM&CFID=55975134&C
FTOKEN=20158783 (Consultada en Enero 27, 2009).
Manning C., et al (Junio 29, 2007). “The Human Capital Management Market Sizing
Report, 2006–2011” AMR Research.
http://www.amrresearch.com/Content/View.asp?pmillid=20502 (descargado en Febrero
2008).
Manning C., et al (Junio 23, 2008). “The Human Capital Management Market Sizing
Report, 2008–2012” AMR Research.
http://www.amrresearch.com/Content/View.asp?pmillid=21540 (descargado en Febrero
2008).
McVaney, Ed. (Diciembre 6, 2002). “C. Edward McVaney Oral History” Computerworld
Honors Program, Video de Entrevista con hecha por Daniel S. Morrow en su casa, el
Rancho McVaney Ranch, en Colorado.
http://www.cwhonors.org/archives/histories/McVaney.pdf (Consultado en Enero 28,
2009).
Meta 4 Corporate Webpage: http://www.meta4.es/. (Consultada en Febrero 5, 2009).
Name, A. y Duque, G. (2002). “Q de Tobin e información asimétrica en los mercados de
capitales: un análisis empírico”. Universidad de los Andes, Bogotá, Colombia.
http://empleados.uniandes.edu.co/dependencias/Departamentos/ingenieria-
industrial/magister/memos/sep2002/NAMQTI.pdf (Consultada en Enero 27, 2009).
Project Management Institute (2004, EEUU). “A guide to the Project Management Body
of Knowledge – (PMBOK Guide) 3rd Edition”. Pennsylvania, USA. Ed. Project
Management Institute.
The Economist, (1999, June 26) “ERP RIP? (cover story).”. (Consultada en Enero 28,
2009 de la base de datos corporativa).
124
Tobin J. (1969) "A general equilibrium approach to monetary theory", Journal of Money
Credit and Banking, Vol 1 No 1 pp 15-29.
http://www.deu.edu.tr/userweb/yesim.kustepeli/dosyalar/tobin1969.pdf
Oracle Corporate Webpage http://www.oracle.com/ ).”. (Consultada en Enero, 2009).
SAP Corporate Webpage http://www.sap.com/ (Consultada en Enero, 2009).
Vidovic Aco, et al., (2000) “JD Edwards OneWorld Implementation for AS/400”. IBM
Redbooks.
125
GLOSARIO
CAGR Compound Average Growth Rate o Tasa Compuesta de Crecimiento
Anual es una medida de la tasa de crecimiento medio a lo largo de varios años
1))_
_((
)_
1(
AñosNúmero
InicialValor
FinalValorCAGR
Q de Tobin Es una relación entre el valor de mercado de una firma contra el valor en
libros de su patrimonio. Lo desarrolló James Tobin (1969). Se calcula dividiendo el valor
de mercado de una compañía entre el costo de reposición de los activos:
)____(
)____(__
pasivoslibrovaloracciónlibrosvalor
pasivoslibrosvaloracciónmercadovalorTobindeq
EDT o WBS Estructura de Descomposición del Trabajo, en inglés Work Breakdown
Structure. Es una técnica de descomposición de alcance en tareas que deberá llevar a
cabo un equipo para generar el producto del proyecto. Organiza y define el alcance total
del proyecto. Subdivide el trabajo en partes más pequeñas y más manejables. Las
tareas del último nivel pueden ser estimadas, presupuestadas, calendarizadas,
monitorizadas y controladas, es decir, se pueden incorporar en un plan de proyecto.
Figura 20. Ejemplo de EDT