Este documento presenta un estudio sobre los beneficios que trae una iniciativa de mejora de procesos de desarrollo de software implementando el Modelo CMMI. Explica brevemente CMMI y el Balanced Scorecard, y propone un mapa estratégico con indicadores clave para cuantificar los resultados en las 4 perspectivas del BSC. Luego, analiza un caso real de una empresa que obtuvo la certificación de Nivel 2 de CMMI, comparando resultados antes y después para concluir sobre los beneficios de la mejora de procesos.
1. Maestría en Administración de Empresas, Mención
Dirección Estratégica de Empresas
Mejora de Proceso de Desarrollo de Software:
Su Impacto en la Empresa desde las 4 Perspectivas del
Balanced Scorecard
Autor: Marcelo Schenone
Tutor: Ana López
Cotutor: Miguel Bilello
22/06/2009
2. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 2 de 87
Tabla de Contenidos
1. Abreviaturas ...................................................................................................... 4
2. Síntesis Ejecutiva .............................................................................................. 4
3. Objetivos ............................................................................................................ 7
3.1. Objetivos Generales................................................................................................. 7
3.2. Objetivos Específicos............................................................................................... 7
4. Aspectos Metodológicos .................................................................................... 8
4.1. Diseño de la Investigación....................................................................................... 8
4.2. Fuentes de Recolección de Datos............................................................................ 8
4.2.1. Fuentes Primarias ........................................................................................................... 8
4.2.2. Fuentes Secundarias ....................................................................................................... 8
4.3. Caso de Aplicación .................................................................................................. 9
5. Mejora de Procesos con CMMI...................................................................... 10
5.1. Introducción........................................................................................................... 10
5.2. CMMI..................................................................................................................... 10
5.3. Detalle de las Áreas de Proceso de Nivel 2 .......................................................... 13
5.3.1. Planificación de Proyectos (PP) ................................................................................... 13
5.3.2. Monitoreo y Control de Proyectos (PMC) ................................................................... 14
5.3.3. Administración de Requerimientos (REQM)............................................................... 14
5.3.4. Mediciones y Análisis (MA) ........................................................................................ 16
5.3.5. Aseguramiento de Calidad de Proceso y Producto (PPQA)......................................... 17
5.3.6. Administración de la Configuración (CM)................................................................... 18
5.3.7. Administración de Acuerdos con Proveedores (SAM)................................................. 20
5.4. Resumen ................................................................................................................. 22
6. Balanced Scorecard y Mapas Estratégicos .................................................... 23
6.1. Introducción........................................................................................................... 23
6.2. Perspectivas del Balanced Scorecard................................................................... 25
6.2.1. Perspectiva Financiera.................................................................................................. 25
6.2.2. Perspectiva de Cliente .................................................................................................. 26
6.2.3. Perspectiva de Procesos Internos.................................................................................. 28
6.2.4. Perspectiva de Aprendizaje y Crecimiento................................................................... 29
6.3. Mapas Estratégicos................................................................................................ 30
6.4. Resumen ................................................................................................................. 32
7. Diseño del Mapa Estratégico para Evaluación de Performance .................. 33
7.1. Objetivos Estratégicos........................................................................................... 33
7.1.1. Descripción de los Objetivos Estratégicos de la Perspectiva Financiera...................... 34
7.1.2. Descripción de los Objetivos Estratégicos de la Perspectiva de Cliente ...................... 35
7.1.3. Descripción de los Objetivos Estratégicos de la Perspectiva de Procesos Internos...... 36
3. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 3 de 87
7.1.4. Descripción de los Objetivos Estratégicos de la Perspectiva de Aprendizaje y
Crecimiento.................................................................................................................................. 37
7.2. Mapa Estratégico con Indicadores....................................................................... 38
7.2.1. Indicadores de la Perspectiva Financiera...................................................................... 39
7.2.2. Indicadores de la Perspectiva de Cliente...................................................................... 43
7.2.3. Indicadores de la Perspectiva de Procesos Internos ..................................................... 47
7.2.4. Indicadores de la Perspectiva de Aprendizaje y Crecimiento....................................... 53
7.3. Resumen ................................................................................................................. 58
8. Beneficios de la Mejora de Procesos.............................................................. 59
8.1. Presentación del Caso............................................................................................ 59
8.2. Implementación de CMMI ................................................................................... 60
8.2.1. Planificación de Proyectos (PP) ................................................................................... 60
8.2.2. Monitoreo y Control de Proyectos (PMC) ................................................................... 62
8.2.3. Administración de Requerimientos (REQM)............................................................... 64
8.2.4. Mediciones y Análisis (MA) ........................................................................................ 67
8.2.5. Aseguramiento de Calidad de Proceso y Producto (PPQA)......................................... 68
8.2.6. Administración de la Configuración (CM)................................................................... 70
8.3. Detalle de Beneficios por Perspectiva.................................................................. 72
8.3.1. Beneficios en la Perspectiva Financiera....................................................................... 72
8.3.2. Beneficios en la Perspectiva de Cliente........................................................................ 74
8.3.3. Beneficios en la Perspectiva de Procesos Internos....................................................... 76
8.3.4. Beneficios en la Perspectiva de Aprendizaje y Crecimiento ........................................ 78
8.4. Sumario de Beneficios........................................................................................... 80
9. Conclusiones ................................................................................................... 81
9.1. Selección de CMMI como Modelo de Mejora de Proceso.................................. 82
9.2. Uso de BSC y Mapas Estratégicos ....................................................................... 82
9.3. Necesidad de Información de Procesos................................................................ 83
9.4. Recomendaciones de Uso ...................................................................................... 84
10. Referencias Bibliográficas.............................................................................. 85
10.1. Referencias Básicas............................................................................................ 85
10.2. Referencias Adicionales..................................................................................... 86
4. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 4 de 87
1. Abreviaturas
BSC: Balanced Scorecard.
CMMI: Capability Maturity Model Integration.
EBIT: Earnings before interest and taxes.
EBITDA: Earnings before interest, taxes, depreciation and amortization.
HBR: Harvard Business Review.
IT: Information Technology.
ME: Mapa Estratégico.
ROI: Return On Investment.
TIR: Tasa Interna de Retorno.
UCP: Use Case Points.
UN: Unidad de Negocio.
VAN: Valor Actual Neto.
2. Síntesis Ejecutiva
Esta tesis tiene como propósito determinar el Impacto en las Perspectivas de
Negocio del Balanced Scorecard (BSC) que tiene una Iniciativa de Mejora de
Proceso de Software en una Empresa Informática.
En el contexto de esta tesis, se define la Mejora de Proceso de Software como
un enfoque sistemático que permite ir generando procesos más eficientes, en forma
iterativa, de manera de optimizar los costos, incrementar la calidad, y mejorar el
time-to-market de productos, en una organización. Este enfoque le permite a una
organización ir mejorando gradualmente sus procesos de manera de lograr una mayor
satisfacción de los clientes.
En el presente trabajo, se plantea una ruta establecida para llevar a cabo la
Mejora de Proceso. Esta ruta está definida por el Modelo de Mejora de Proceso de
CMMI, el cual establece una guía estructurada para llevar a cabo las actividades de
mejora. CMMI se ha convertido en el modelo estándar en la industria de IT, razón
por la cual es propuesto para analizar los beneficios que trae a una organización.
5. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 5 de 87
Sin embargo, se debe mencionar que la medición de los beneficios de la
Mejora de Proceso resulta compleja, ya que es difícil definir un conjunto de métricas
que puedan cuantificar los retornos de la implementación de procesos más eficientes,
y sean significativas para el management de la organización, que es quien debe
sponsorear esta iniciativa.
Una realidad detectada frecuentemente en la industria informática, es que los
ejecutivos de las organizaciones reconocen a la Mejora de Proceso como una
iniciativa crítica para mejorar la calidad de sus productos o servicios, pero al
momento de medir si los beneficios de la misma están alineados a los resultados de
negocio, no cuentan con la información necesaria. Consecuentemente, muchas
organizaciones inician el camino de la Mejora de Proceso, pero al poco tiempo, la
iniciativa es abandonada pues no existen drivers de negocio suficientes como para
sustentarla en el tiempo.
Dada esta situación, se plantea en esta tesis usar un modelo de gestión que
permita demostrar los resultados, cuantitativos y cualitativos, de la Mejora de
Proceso. Este modelo de gestión es el BSC, el cual traduce la estrategia en operación.
El BSC será utilizado para identificar aquellos indicadores a ser medidos en las 4
perspectivas (Financiera, Cliente, Procesos Internos, Aprendizaje y Crecimiento), y
monitorear los resultados durante la ejecución de la Mejora de Proceso, en el marco
de CMMI.
La tesis comienza dando una breve introducción a los dos temas ejes: CMMI
y BSC. Sobre CMMI, se da una explicación a la estructura del Modelo CMMI,
haciendo énfasis en el Nivel 2 de Madurez. Sobre BSC, se explica cada perspectiva
indicando el mecanismo en que una se apoya sobre la otra para poder bajar de la
estrategia hacia la operación. También, se explican los Mapas Estratégicos, como
forma de visualizar los objetivos estratégicos, con sus relaciones, y el BSC de cada
perspectiva.
A continuación, se presenta una propuesta de Mapa Estratégico para una
empresa informática. El Mapa Estratégico contiene indicadores clave que
representan las 4 perspectivas. Se profundiza sobre este tema, haciéndose una
selección de las métricas que serán usadas para cuantificar los resultados de la
implementación de la Mejora de Proceso.
6. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 6 de 87
Finalmente, se desarrolla un caso real de una empresa informática en
Argentina. Utilizando el Mapa Estratégico previamente definido, se realiza una
comparación de los resultados antes y después de la ejecución de la Mejora de
Proceso bajo CMMI – centrándose en la evaluación exitosa del Nivel 2. Se concluye
mostrando las bondades de la Mejora de Proceso en relación a las perspectivas del
BSC, a partir de las mejoras en los indicadores a lo largo del tiempo.
7. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 7 de 87
3. Objetivos
3.1. Objetivos Generales
Esta tesis tiene como propósito determinar el Impacto en las Perspectivas de
Negocio del Balanced Scorecard (BSC) que tiene una Iniciativa de Mejora de
Proceso de Software en una Empresa Informática.
3.2. Objetivos Específicos
1. Indagar sobre los mecanismos que impactan en la estrategia de
negocio de una empresa, como consecuencia de la implementación del
primer nivel de madurez (Nivel 2) del Modelo CMMI DEV v1.2 de
Mejora de Proceso.
2. Diseñar una metodología para estimar los beneficios en las 4
Perspectivas del BSC, involucrados en un Proyecto de Mejora de
Proceso de las características del punto anterior.
3. Con el objetivo de evaluar la bondad de la Mejora de Proceso,
entender sus fortalezas y debilidades, así como la pertinencia de los
resultados, se desarrollará un caso real de aplicación, en una Empresa
Informática de mediano tamaño que ha obtenido la Certificación de
Nivel 2 de CMMI.
8. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 8 de 87
4. Aspectos Metodológicos
4.1. Diseño de la Investigación
Para llevar a cabo la investigación, se realizarán dos procedimientos
principales:
1. Relevamiento documental. Se realizará una investigación en todos los
repositorios de información, herramientas de gestión, y documentos
físicos que posean información sobre la Mejora de Proceso.
2. Entrevistas a stakeholders claves. En los casos en que la
documentación no entregue la información requerida, se realizarán
entrevistas con las personas de la organización que han participado en
el proceso de evaluación de Nivel 2 de CMMI. Las entrevistas tendrán
el objetivo de obtener la información requerida, y validar el uso de la
misma en el presente trabajo.
4.2. Fuentes de Recolección de Datos
4.2.1. Fuentes Primarias
Como fuente primaria se tomarán los resultados del relevamiento documental
sobre los datos operativos de la empresa. Estos servirán para analizar el impacto de la
Iniciativa de Mejora de Proceso, en forma cuantitativa.
4.2.2. Fuentes Secundarias
Como fuentes secundarias se tendrán principalmente papers, publicaciones y
libros de distintas entidades como: SEI, IEEE, ACM, CESSI. De estas, se tomará
información sobre el impacto de la Mejora de Proceso en distintas organizaciones, y
sobre el análisis de la mejora asociada a los distintos niveles de madurez del Modelo
CMMI.
9. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 9 de 87
4.3. Caso de Aplicación
Esta tesis tendrá como caso real de aplicación a una empresa de desarrollo de
software, con sede en Capital Federal, Argentina. La empresa es de mediano tamaño;
cuenta actualmente con 180 empleados, y ha tenido un fuerte crecimiento en los
últimos 4 años.
La empresa ha iniciado, a fines del 2005, la implementación de la Mejora de
Proceso bajo el modelo CMMI. En Agosto 2007, se obtiene una evaluación de Nivel
2 de CMMI DEV v1.2.
10. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 10 de 87
5. Mejora de Procesos con CMMI
5.1. Introducción
La Mejora de Procesos es una disciplina dentro de la Ingeniería de Software
que consiste en:
1. analizar los procesos existentes en una organización;
2. entender cuales de estos procesos están alineados a los objetivos de
negocio;
3. asegurar que estos procesos sean replicados en toda la organización;
4. monitorear continuamente los procesos para encontrar maneras de
mejorarlos.
Algunos de los objetivos principales detrás de la Mejora de Proceso son:
brindar predictibilidad en tiempos, costos, y calidad; incrementar la productividad
del desarrollo; minimizar costos; y mejorar la calidad. Su importancia radica en
optimizar los procesos internos de la operatoria de la organización, de manera que
contribuyan a la perspectiva financiera de maximizar la rentabilidad y minimizar los
costos, dando mayor valor a los accionistas.
En el contexto de la Mejora de Proceso, existen distintos modelos que
permiten a las organizaciones asegurar la calidad de sus procesos, y,
consecuentemente, mejorar la calidad de los productos entregados. Estos modelos
son utilizados por las organizaciones para coordinar sus esfuerzos de Mejora de
Proceso, y poder establecer un roadmap planificado para ir aumentando la madurez
de los procesos a lo largo del tiempo.
5.2. CMMI
Entre estos modelos de mejora de proceso, centraremos el trabajo de esta tesis
en el Modelo CMMI DEV (Capability Maturity Model Integration – Development),
del SEI (Software Engineering Institute), de la Universidad de Carnegie Mellon. Este
11. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 11 de 87
modelo provee un camino de mejora de proceso estructurado en niveles, del 1 al 5,
en donde el Nivel 5 es el de la Mejora Continua de Proceso.
En el Marco de Madurez de CMMI, dentro de la representación por etapas, se
establecen 5 niveles de madurez para la organización:
1. Inicial (caótico, ad hoc, heroico) es el punto de partida de una
organización sin procesos formales establecidos.
2. Gerenciado (administración de proyectos, disciplina en procesos) se
cuenta con procesos para gestionar los proyectos, y estos son usados
en forma repetitiva.
3. Definido (institucionalizado) los procesos están definido para todas
las áreas de proceso y están documentados como procesos estándar de
negocio.
4. Administrado Cuantitativamente (cuantificado) se tienen los procesos
controlados estadísticamente, y se toman a cabo mediciones para
mantenerlos dentro de los rangos aceptables.
5. Optimizado (mejora de procesos) la administración de los procesos
incluye la optimización y mejora continua de los mismos.
El Nivel 1 representa el estado actual de cualquier organización previo a
encarar una iniciativa de Mejora de Procesos. La organización realiza sus actividades
de una manera ad hoc, utilizando procesos diferentes de acuerdo a las personas y los
proyectos. En este contexto impera un alto nivel de informalidad. Rara vez se
encuentran procesos documentados, y la calidad termina dependiendo de las personas
que están involucradas en los proyectos. El Nivel 1 representa la línea base de
madurez, a partir de la cual se contrastarán los beneficios de la Mejora de Procesos.
El Nivel 2 se enfoca principalmente en temas de Gestión de Proyectos.
Por cada nivel, se tienen áreas de proceso que representan dominios de la
ingeniería de software, las cuales deben cumplirse para alcanzar dicho nivel de
madurez. Cada área de proceso tiene objetivos específicos y genéricos, los cuales son
obligatorios para garantizar el cumplimiento del área de proceso. Por cada objetivo,
tanto sea específico como genérico, se tienen prácticas – específicas o genéricas
según corresponda – esperables de ser aplicadas. Las prácticas constituyen
12. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 12 de 87
actividades concretas del desarrollo de software, y son los elementos que se evalúan
ante una instancia de certificación. A continuación, se presenta una figura que ilustra
la estructura del modelo.
Figura 1. Estructura organizativa de CMMI.
En el marco de esta tesis, se tomará el primer nivel que otorga rating oficial
en CMMI, el Nivel 2. El Nivel 2, denominado Gerenciado (Managed), posee las
áreas de proceso básicas para la gestión de los proyectos de la organización. En el
Nivel 2, se tienen individuos compartiendo buenas prácticas, y diseño de procesos a
nivel de proyectos, y, en algunos casos, a nivel organizacional. El Nivel 2 se enfoca
principalmente en temas de Gestión de Proyectos, y cuenta con 7 áreas de proceso
que deben ser cumplidas para obtener el rating:
o Planificación de Proyectos (PP)
o Monitoreo y Control de Proyectos (PMC)
o Administración de Requerimientos (REQM)
o Administración de la Configuración (CM)
o Aseguramiento de la Calidad en Proceso y Producto (PPQA)
o Métricas y Análisis (MA)
o Administración de Acuerdos con Proveedores (SAM)
13. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 13 de 87
5.3. Detalle de las Áreas de Proceso de Nivel 2
5.3.1. Planificación de Proyectos (PP)
La Planificación de Proyectos (PP) es el área de proceso más crítica del Nivel
2. El objetivo es establecer y mantener los planes de las distintas actividades que se
realizan dentro del proyecto. Esta área de proceso marca una diferencia fundamental
respecto al Nivel 1, ya que plantea establecer una definición de alcance de proyecto,
a partir de la cual se deriven las tareas necesarias para su ejecución. Para las tareas
del proyecto se establecerán: un ordenamiento a lo largo del tiempo, una estimación
de su duración, una definición de precedencias, y una asignación de recursos.
El primer paso en está área de proceso propone la definición de alcance del
proyecto. Un proyecto sin alcance delimitado, no puede ser estimado, por lo tanto,
tampoco puede ser planificado. Una vez acotado el alcance, se deben derivar las
tareas y entregables necesarios para la ejecución del proyecto. Las tareas deberán ser
estimadas para conocer el tamaño del proyecto. Este tamaño servirá como base para
calcular el esfuerzo y los costos que serán incurridos en el proyecto.
Con todas las definiciones tomadas, la planificación debe ser volcada en un
Plan de Proyecto, el cual contempla el involucramiento de todos los stakeholders1
del
proyecto. A partir del Plan de Proyecto, se deberá obtener el compromiso de todas
las partes, de manera de garantizar que las actividades sean realizadas acorde a lo
planificado.
Con la implementación de las prácticas de PP que fueron descriptas, la
gerencia de proyecto está habilitada a ejecutar un proyecto de manera ordenada y
predecible. A partir de una adecuada planificación, la gerencia de proyecto es capaz
de brindar visibilidad tanto al Equipo de Proyecto como al Cliente sobre el desarrollo
de las actividades. Es importante entender que a la par de la planificación, se deberá
monitorear adecuadamente el cumplimiento de las actividades e hitos planificados
1
Del inglés Stakeholders. Refiere a toda persona (sea física o jurídica) que se ve afectada por la
ejecución del proyecto.
14. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 14 de 87
del proyecto. El monitoreo del proyecto es, justamente, el propósito de la siguiente
área de proceso.
5.3.2. Monitoreo y Control de Proyectos (PMC)
El Monitoreo y Control de Proyectos (PMC) es la otra cara de la moneda de
la planificación. Todas las actividades que son definidas en la Planificación de
Proyectos (PP) deberán ser monitoreadas y controladas para asegurar su
cumplimiento. En caso de existir desvíos sobre la planificación, deberán ser
analizados y se deberán tomar acciones correctivas cuando corresponda. Estos son
los temas principales de PMC.
El monitoreo incluye el análisis periódico del avance del proyecto respecto a
lo planificado. En particular, serán monitoreados aquellos atributos de los proyectos
que se consideren relevantes. Entre estos podemos mencionar: tiempos, costos,
esfuerzo, calidad, compromisos, riesgos. Se contemplan dos tipos de revisiones de
avance: 1) periódicas, que son realizadas con una frecuencia determinada (semana,
quincenal, mensual), durante las que se discuten el avance de las tareas, los desvíos,
los riesgos, y las próximas tareas; 2) ante hitos, en que se alcanzan momentos del
proyecto que marcan la finalización de una secuencia de actividades que cumplen
objetivos dentro del proyecto.
El control debe acompañar al monitoreo a lo largo del proyecto, ya que en
todos los proyectos existen desvíos sobre la planificación, o riesgos que se
materializan. Ante estas situaciones, se debe analizar el desvió, identificar acciones
correctivas, y verificar que las acciones correctivas resuelvan la situación.
5.3.3. Administración de Requerimientos (REQM)
La Administración de Requerimientos (REQM) es el área de proceso cuyo
propósito es administrar los requerimientos de un proyecto, estableciendo un control
de los mismos, y monitoreando los cambios que puedan surgir durante la ejecución.
La palabra clave en REQM es el monitoreo del alcance del proyecto. Se define que
15. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 15 de 87
los requerimientos ya existen, y se debe administrar los cambios que vayan
surgiendo, manteniendo la trazabilidad bidireccional2
entre los requerimientos y el
producto. Es importante destacar que la Administración de Requerimientos parte de
requerimientos existentes. La identificación, relevamiento, análisis, y especificación
de requerimientos está contemplada en el área de proceso Desarrollo de
Requerimientos (RD), que forma parte del Nivel 3 de Madurez.
La primera práctica específica consiste en entender los requerimientos del
proyecto, y validar este entendimiento con los stakeholders. Resulta crítico que la
visión de los requerimientos sea la misma para todas las partes; de no ser así,
devendrán problemas al momento de validar la solución, ya que la misma no se
ajustará a las expectativas del cliente. Una vez que se tiene un entendimiento común,
se debe asegurar el compromiso de las partes (cliente, management, equipo de
desarrollo), con la implementación de los requerimientos. Esto permite asegurar que
se tendrán los recursos necesarios para el desarrollo, y que los mismos se
comprometen a sus responsabilidades.
A partir del compromiso de los involucrados, y la implementación de los
requerimientos, se debe hacer un monitoreo sobre los cambios que puedan surgir a
estos últimos. Los cambios a los requerimientos son bastante comunes en los
proyectos de desarrollo de software. Los factores que causan dichos cambios se
pueden dividir en dos tipos: externos e internos [1]. Los factores externos son
aquellos sobre los cuales el equipo de desarrollo no tiene control, entre estos
podemos mencionar: cambios en el negocio bajo análisis, cambios en las normativas
vigentes relacionadas al negocio, cambios en las percepciones de los usuarios,
cambios en el macroentorno. Los factores internos están afectados a los participantes
del proyecto, entre estos podemos mencionar: fallas en el relevamiento, cambios no
manejados a los requerimientos. Ante estos factores, el área de proceso propone
establecer un procedimiento de administración de cambios, que permita que la
introducción de los mismos sea planificada y consensuada.
2
En este contexto, la trazabilidad bidireccional es una asociación entre dos o más entidades lógicas,
que permite discernir las entidades en cuestión en ambos sentidos.
16. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 16 de 87
A medida que los requerimientos se van implementando, se deberá mantener
la relación que tienen con los productos generados en el desarrollo, mediante la
trazabilidad bidireccional. Cuando se encuentran problemas en el desarrollo de
software, la trazabilidad permite entender de donde surgen los requerimientos, y
poder corregir los problemas más rápido. También, sirve para analizar el impacto de
un cambio solicitado, al ver en donde afecta el mismo desde la documentación de
análisis hasta la implementación en el código de la aplicación.
La última práctica específica de REQM, propone analizar los planes del
proyecto para verificar que contemplan todos los requerimientos a implementar y los
cambios que se han realizado a los mismos.
5.3.4. Mediciones y Análisis (MA)
Mediciones y Análisis (MA) es un área de proceso que anteriormente existía
en forma de práctica común en el modelo CMM (precursor de CMMI), pero fue
definida como área de proceso independiente en el Nivel 2 de CMMI. El propósito es
definir, recolectar, y analizar métricas sobre los proyectos, que sirvan para que el
management pueda tomar decisiones.
El área de proceso describe prácticas tendientes a institucionalizar un proceso
de mediciones a nivel organizacional. MA es un área de proceso que tiene impacto
en todo el resto de las áreas de proceso, pues se espera que todos los procesos sean
medidos para validar si están cumpliendo con la performance esperada, de manera de
poder mejorarlos continuamente. Este es el foco de los Niveles 4 y 5 de CMMI, que
incorporan el control estadístico de procesos para cuantificar y plantear mejoras a los
procesos.
Las primeras prácticas específicas de MA tienen el propósito de identificar
que métricas son requeridas por el management, especificar como se recolectarán,
con que frecuencia, en donde serán almacenadas, y que análisis se hará sobre los
resultados. Se podría decir que esta es la fase de Definición, en la cual se genera la
infraestructura necesaria para el proceso de métricas.
17. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 17 de 87
Una vez que se tiene claridad sobre las métricas que se tomarán, se pasa a las
prácticas de ejecución, en lo que podríamos denominar la fase de Operación. A partir
de estas prácticas, se lleva a cabo la recolección y registro de la información; se
analizan los datos; se obtienen gráficos e indicadores; y se comunican los resultados
a las partes interesadas, principalmente al management.
5.3.5. Aseguramiento de Calidad de Proceso y Producto (PPQA)
El propósito de Aseguramiento de la Calidad de Proceso y Producto (PPQA)
es el de proveer de indicadores objetivos sobre el estado de procesos y productos. La
palabra objetivo es clave en este punto, y en el contexto de CMMI representa una
revisión efectuada mediante algún criterio que minimice la subjetividad, y
parcialidad del revisor. Un ejemplo de esto puede ser una revisión de un documento
contra los estándares de escritura del mismo, llevada a cabo por una función de
aseguramiento de calidad.
El tipo de revisiones que se espera de PPQA, suele tener que ver con el
seguimiento de los estándares definidos. En el caso de producto, se espera que se
verifiquen los productos generados siguiendo las buenas prácticas y lineamientos
definidos, y se asienten las observaciones que surjan de diferencias con los
estándares. En el caso de proceso, se espera que se verifique que los procesos sigan
los pasos de los procesos establecidos, y se asienten las observaciones que surjan de
las diferencias. Cabe remarcar, que los indicadores que serán entregados por PPQA
suelen ser sobre la forma o la adecuación a estándares de los procesos y productos, y
no sobre el contenido de los mismos. De la verificación del contenido es responsable
el área de proceso de Verificación (VER), que se encuentra en el Nivel 3 de CMMI.
Las primeras prácticas específicas proponen llevar a cabo revisiones de
procesos y productos de acuerdo a los estándares y procedimientos definidos en la
organización. Estas revisiones suelen realizarse mediante el uso de checklists de
revisión, que identifican los puntos principales que se deben verificar para cubrir la
adherencia a los estándares.
18. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 18 de 87
Una vez se realizan estas revisiones, se deben establecer mecanismos para
asentar las no conformidades, y seguirlas hasta que se resuelvan. Este es el propósito
de las prácticas específicas agrupadas bajo el objetivo específico de proveer
indicadores objetivos. Las personas encargadas de la revisión deberán notificar a
aquellos involucrados de las no conformidades detectadas, de manera que las
corrijan, asegurando que la corrección se lleve a cabo. Es importante que toda esta
información quede registrada, ya que estos indicadores serán de especial interés para
el management, por mostrar el nivel de adherencia de los proyectos a los estándares,
y el nivel de calidad de los productos que son entregados. Para el registro de esta
información, y la automatización de los procesos de PPQA, se suelen utilizar
herramientas de seguimiento de incidentes (del inglés issue tracking).
Con la implementación de las prácticas de PPQA que fueron descriptas, la
gerencia de proyecto dispone de indicadores fehacientes de la calidad en los
proyectos, los cuales permiten tomar acciones correctivas cuando hagan falta. El
asegurar que la calidad es homogénea en todos los proyectos, permite lograr altos
grados de satisfacción en los clientes, ahorrando costos causados por la variación en
procesos y productos.
5.3.6. Administración de la Configuración (CM)
El propósito de Administración de la Configuración (CM) es el de establecer
y mantener la integridad de los productos que son consumidos y generados durante
un proyecto. CM se basa en las disciplinas de identificación, control, y auditoria de la
configuración.
En esta área de proceso, existe un concepto muy utilizado que es el ítem de
configuración. Un ítem de configuración (IC) es cualquier elemento de información
que se mantiene dentro de CM – ejemplos de IC son: código fuente de una
aplicación, documentación de requerimientos, esquema de generación de base de
datos. Todos estos deben pasar por la identificación, control y auditoría.
Las primeras prácticas específicas están agrupadas bajo el objetivo específico
de establecimiento de líneas base. Una línea base es un conjunto de IC que han sido
19. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 19 de 87
acordados en un determinado momento del proyecto, a partir de la cual se continúa el
desarrollo, y esta solo puede ser cambiada mediante procedimientos de control de la
configuración. Como primera actividad dentro de CM, deberemos identificar los IC
que formarán parte de un proyecto. Estos IC formarán parte de las líneas base, serán
controlados, y auditados para asegurar su integridad.
El control de los IC se llevará a cabo mediante un sistema de administración
de la configuración. Estos sistemas involucran software y hardware destinado a
servir de repositorio de información para los IC. Existen herramientas que
automatizan el almacenamiento de las distintas versiones de un IC, a lo largo del
ciclo de vida del proyecto. Estas herramientas permiten generar líneas base,
compuestas de un conjunto de IC, y recuperar el contenido de las mismas en
cualquier momento. Una situación que ejemplifica este tema sería la de generar una
línea base con la lista de requerimientos del proyecto. Una vez acordada, se
comienza con la construcción de los requerimientos. Si posteriormente existen
cambios en los requerimientos, los mismos deberán ser controlados y analizados, ya
que impactan en la planificación del proyecto. De existir un acuerdo sobre su
incorporación, se deberá crear una nueva línea base de requerimientos.
Las prácticas específicas de seguimiento y control de cambios, se basan en la
existencia de líneas base sobre las cuales se deben controlar los cambios. Ante
situaciones de cambio, se debe solicitar un pedido de cambio formal, para analizar el
impacto del cambio sobre la planificación y los productos. Si se define que los
cambios deben ser implementados, se debe controlar que se actualicen todos los IC
que correspondan, de manera de reflejar esta nueva situación. Esto implica generar
una nueva línea base.
Por último, existen prácticas específicas de auditoria de los IC. Estas prácticas
tienen el propósito de asegurar la integridad de todos los IC puestos bajo
administración de la configuración. Para llevar a cabo se propone tener auditorias de
configuración, que establezcan el correcto funcionamiento del sistema de
configuración, y de las prácticas que fueron descriptas anteriormente.
20. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 20 de 87
Con la implementación de las prácticas de CM que fueron descriptas, la
gerencia de proyecto se asegura que todos los IC que son creados en un proyecto, son
identificados, controlados, y auditados. El control de la configuración asegura que
todas las líneas base que sean generadas, tengan los IC correspondientes,
garantizando la calidad en este aspecto. Más aún, el tener un control de cambios
sobre los elementos bajo configuración, habilita al management a poder incorporar
los cambios de manera planificada.
5.3.7. Administración de Acuerdos con Proveedores (SAM)
El propósito de Administración de Acuerdos con Proveedores (SAM) es el de
gestionar las adquisiciones de productos desarrollados por proveedores. Esta área de
proceso está enfocada en: la adquisición de productos desarrollados por terceras
partes, como estos son transferidos a la organización, y como son entregados al
cliente del proyecto.
El primer objetivo específico contiene las prácticas para establecer los
acuerdos con los proveedores. Los acuerdos serán establecidos de diferentes
maneras, de acuerdo a los productos y/o servicios adquiridos. A continuación, se
enumeran algunos tipos de adquisición:
o Compras de licencias.
o Obtención de producto mediante un contrato.
o Obtención de producto de un proveedor interno.
o Obtención de un producto del cliente.
Cabe remarcar el último punto mencionado, ya que cuando el cliente entrega
algún producto que debe ser integrado o bien debe formar parte de la solución, el
cliente pasa a ser concebido como un proveedor del proyecto, y se aplican todas las
prácticas específicas de SAM.
Una vez que se establece el tipo de adquisición, se deberán seleccionar el o
los proveedores que serán contratados entre la lista de candidatos. Para esto, se deben
21. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 21 de 87
establecer los factores de evaluación de proveedores, y, en base a los resultados
obtenidos, seleccionar aquellos que tengan los puntajes más altos.
Con el o los proveedores que han sido seleccionados, se debe establecer un
acuerdo formal para regir las actividades a realizar, y los productos que serán
entregados. Estos acuerdos, serán ejecutados y cumplidos en el siguiente objetivo
específico de SAM, en el cual existen prácticas específicas para la ejecución, el
monitoreo, la aceptación, y la transferencia de los productos desarrollados.
Los acuerdos planteados deberán ser monitoreados en su ejecución, lo que
incluye evaluar los procesos y productos de los proveedores para garantizar que
cumplan con las normas definidas por la organización. Cuando los proveedores
liberen el producto acordado, se debe establecer una aceptación formal, que incluye
validar que los puntos del acuerdo se hayan cumplido. Una vez que se da la
aceptación, se deberá transferir el producto desde el proveedor al proyecto.
Con la implementación de las prácticas de SAM que fueron descriptas, la
gerencia de proyecto está habilitada para llevar a cabo acuerdos formales con
proveedores seleccionados, pudiendo planificar y monitorear las actividades de
adquisición. Consecuentemente, las adquisiciones de productos en el proyecto, se
realizarán de manera planificada, y siguiendo los niveles de calidad definidos.
22. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 22 de 87
5.4. Resumen
A lo largo del capítulo, fue descripto el Modelo CMMI DEV, su estructura, y
las siete áreas de proceso que forman parte del Nivel 2 del modelo. Cada una de estas
áreas contribuye a brindar beneficios medibles desde las perspectivas del Balanced
Scorecard (se bajará a detalle en el BSC en el próximo capítulo). Los beneficios
estarán centrados en tres áreas principales:
o Mejora en la calidad percibida por el cliente.
o Mejora en la productividad y tiempos de entrega.
o Ahorro de costos por procesos más eficientes y reducción de
defectos/retrabajo.
Uno de los objetivos a que se apunta al implantar CMMI en una organización,
es lograr una mayor predictibilidad en los proyectos. Cada una de las siete áreas de
proceso del Nivel 2 de madurez, mejora el nivel de predictibilidad de los proyectos,
trayendo beneficios en las tres áreas mencionadas anteriormente. La predictibilidad
se traduce en: tener procesos definidos y ágiles, que permitan maximizar la
productividad, minimizando los defectos y el retrabajo; planificar sobre la base de
esos procesos, para tener claridad sobre los tiempos de entrega de producto;
mantener durante el tiempo, altos niveles de calidad en los productos que se entregan
al cliente.
23. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 23 de 87
6. Balanced Scorecard y Mapas Estratégicos
6.1. Introducción
El Balanced Scorecard (BSC) es un modelo de gestión que traduce la
estrategia en operación. Fue propuesto por Robert S. Kaplan y David P.Norton, en un
artículo en la Harvard Business Review, en Enero de 1992 [2]. El BSC permite que
la gerencia pueda ver el negocio desde cuatro perspectivas críticas, dando respuesta a
las siguientes preguntas:
o ¿Que valor da la organización a los Accionistas? – Perspectiva
Financiera
o ¿Cómo percibe el Cliente a la organización? – Perspectiva de Cliente
o ¿En que debe la organización ser excelente? – Perspectiva de Procesos
Internos
o ¿Puede la organización mejorar y crear más valor? – Perspectiva de
Aprendizaje y Crecimiento
El objetivo de Kaplan y Norton al crear el BSC, era el de proveer a la alta
gerencia de un mecanismo para monitorear la performance de su organización desde
varios puntos de vista. La analogía que ellos establecen en el artículo original de
HBR, es la de los medidores e indicadores en una cabina de un avión. Así como los
pilotos deben disponer de información detallada del status de la aeronave y de las
condiciones externas, la alta gerencia debe tener información detallada para poder
dirigir la organización acorde a su estrategia.
El BSC está organizado alrededor de cuatro perspectivas que comienzan
desde las capacidades internas de la organización, llegando hasta los resultados
financieros que permiten que la misma pueda seguir operando exitosamente en el
mercado. La lógica que impulsa el BSC se puede describir de la siguiente manera:
“Mediante eell aapprreennddiizzaajjee yy ccrreecciimmiieennttoo de la organización (Perspectiva
de Aprendizaje y Crecimiento), se preparará a las personas, para que puedan
desarrollar e implementar pprroocceessooss eeffiicciieenntteess (Perspectiva de Procesos
24. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 24 de 87
Internos), los cuales serán necesarios para darle un ccoonnjjuunnttoo ddee bbeenneeffiicciiooss
úúnniiccooss al cliente (Perspectiva de Cliente), resultando en el ééxxiittoo ffiinnaanncciieerroo de la
organización y el vvaalloorr ppaarraa llooss aacccciioonniissttaass (Perspectiva Financiera).”
Figura 2. Representación visual de la lógica del BSC.
Estas perspectivas tienen el propósito de proveer al management de
indicadores que le permiten monitorear el grado de implementación de la estrategia.
En cada una de las perspectivas, se identificarán un conjunto de objetivos que
articulan los componentes de la estrategia. Por cada objetivo, el BSC deberá
contener:
o indicadores representativos: que definirán como será medido el éxito
en el cumplimiento de la estrategia;
o metas a alcanzar: que darán el nivel de desempeño o la tasa de mejora
que espera el management durante el siguiente período;
Perspectiva de
Aprendizaje y
Crecimiento
Perspectiva de
Procesos Internos
Perspectiva de
Cliente
Perspectiva
Financiera
EEssttrraatteeggiiaa
25. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 25 de 87
o iniciativas: que describen programas de acción concretos requeridos
para cerrar la brecha entre el desempeño actual y el esperado.
Esta información se suele presentar en forma gráfica, mediante una tabla por
cada perspectiva. A continuación, se presenta un ejemplo de una tabla de BSC.
INDICADORES
META
2008
META
2009
META
2010
META
2011
META
2012
Valor Sustentable para el accionista Incremento EBIT 17,0% 17,5% 18,5% 19,5% 20,5%
Ser líderes en mercados estratégicos Market Share 4,0% 5,0% 6,0% 8,0% 10,0%
Tener ganancias predecibles Ganancias planificadas vs .Reales 80,0% 85,0% 90,0% 95,0% 95,0%
Crecer en facturación Incremento en facturación total 30,0% 33,0% 35,0% 40,0% 45,0%
Incremento en facturación por cliente 10,0% 15,0% 15,0% 15,0% 15,0%
Incremento en ventas cruzadas 5,0% 7,5% 10,0% 15,0% 15,0%
OBJETIVO
Aumentar el valor del cliente
F
I
N
A
N
C
I
E
R
O
S
Figura 3. Tabla de Objetivos-Indicadores-Metas para la Perspectiva Financiera del BSC.
6.2. Perspectivas del Balanced Scorecard
De acuerdo a Norton y Kaplan [3], las cuatro perspectivas del BSC brindan
un balance entre objetivos a corto y largo plazo, entre los resultados deseados y los
drivers de performance de esos resultados, entre medidas más objetivas/cuantitativas
y medidas más subjetivas/cualitativas.
6.2.1. Perspectiva Financiera
La Perspectiva Financiera permite tener la visión que tienen los accionistas de
la compañía. La performance en la perspectiva financiera permite medir el grado de
cumplimiento con uno de los objetivos primordiales de cualquier organización con
fines comerciales: maximizar ganancias a largo plazo. Algunos objetivos típicos de
esta perspectiva tienen relación con las ganancias, el crecimiento, la reducción de
costos, y el valor a los accionistas.
El BSC, habilita a las unidades de negocio a que relacionen sus objetivos
financieros con la estrategia corporativa. Los objetivos financieros sirven de foco
para los objetivos y mediciones en el resto de las perspectivas. Cada medición
26. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 26 de 87
seleccionada debe ser parte de una relación causa y efecto, que termine mejorando la
performance financiera de la organización.
Existen tres tópicos a nivel financiero que guían a la estrategia de negocio.
Estos son:
o Crecimiento en ingresos y mix de productos/servicios
Refiere a expandir la oferta de productos o servicios, de manera de
alcanzar nuevos mercados y clientes, yendo hacia un esquema de
ofertas de alto valor agregado.
o Reducción de costos / mejoras en la productividad
Refiere a los esfuerzos para bajar los costos directos de productos o
servicios, reducir los costos indirectos, y mejorar la productividad del
desarrollo.
o Utilización de activos / estrategia de inversión
Refiere a reducir los niveles de capital utilizados, y obtener una mayor
utilización de los activos que no están siendo utilizados al máximo de
su capacidad.
6.2.2. Perspectiva de Cliente
La Perspectiva de Cliente permite tener la visión que tienen los clientes de los
segmentos de mercado en los cuales se enfoca la compañía. La performance en esta
perspectiva estará dada por las siguientes mediciones: market share (porción de
mercado), retención de clientes, adquisición de nuevos clientes, satisfacción del
cliente, y rentabilidad por cliente. También, se recomienda incluir mediciones
específicas de las proposiciones de valor que la compañía entregará a los segmentos
de mercado en los que se encuentra.
Esta perspectiva brinda una visión desde afuera de la organización. Permite
entender si los segmentos de mercado seleccionados como foco de la estrategia, son
aquellos en donde se está generando valor. Claramente, si las unidades de negocio
deben tener una buena performance financiera, deben crear y entregar productos o
servicios valorados por sus clientes.
27. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 27 de 87
Dentro de la Perspectiva de Cliente, existen algunas mediciones que son
comunes a todas las organizaciones (debiendo ser adaptadas de acuerdo a los
segmentos de mercado elegidos):
o Market Share
Refiere a la porción de mercado que se tiene dentro de uno o más
segmentos (puede ser medida en cantidad de clientes, unidades
vendidas, o ingresos económicos). A medida se tiene un mayor market
share, se incrementan los ingresos, lo cual mejora la performance de
los indicadores financieros.
o Retención de Clientes
Refiere a la tasa a la cual una unidad de negocio retiene o mantiene
relaciones con sus clientes. En este contexto, se podrá medir el
porcentaje de crecimiento de negocio en clientes ya existentes.
o Adquisición de Nuevos Clientes
Refiere a la tasa a la cual una unidad de negocio atrae o gana nuevos
clientes o negocios. Cuando se ponen objetivos de incremento en
market share, esto se suele acompañar de una estrategia para
incrementar la base de clientes existente en un segmento de mercado.
Las mediciones pueden estar dadas por el número de nuevos clientes,
o el total de ventas a nuevos clientes en los segmentos.
o Satisfacción del Cliente
Refiere al nivel de satisfacción de los clientes, de acuerdo a criterios
de performance sobre la propuesta de valor. La satisfacción del cliente
da el feedback que necesita la organización para saber si sus
estrategias en esta perspectiva están rindiendo los frutos. Típicamente,
se utilizan encuestas de satisfacción, para medir la satisfacción del
cliente.
o Rentabilidad por Cliente
Refiere a la rentabilidad neta de un cliente, o segmento de mercado.
Permite que la organización pueda medir la rentabilidad de los
distintos negocios o segmentos en los que participa.
28. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 28 de 87
6.2.3. Perspectiva de Procesos Internos
La Perspectiva de Procesos Internos permite que la organización identifique y
mida aquellos procesos internos en que debe destacarse para poder dar su
proposición de valor. Estos procesos habilitarán a la organización a entregar valor,
para atraer y retener clientes en los segmentos de mercado en que se enfoca; y a
satisfacer las expectativas de sus accionistas dando un excelente retorno financiero.
Es importante remarcar, que el BSC propone en esta perspectiva el contar con
mediciones para los procesos de operaciones, así como los de innovación. Los
procesos de innovación permiten que las organizaciones creen productos o servicios
enteramente nuevos, que cumplan las necesidades de clientes actuales y futuros.
Dentro de la Perspectiva de Procesos Internos, existen algunos procesos de
negocio que son estándares a todas las organizaciones, y sobre los que se recomienda
tomar las mediciones para el BSC:
o Innovación
Refiere al proceso de negocio que investiga y desarrollo las
necesidades latentes de los clientes, y crea productos o servicios para
satisfacer esas necesidades. En general, las mediciones que se toman
para este proceso tienen que ver con los ingresos por nuevos
productos o servicios.
o Operaciones
Refiere al proceso de negocio donde los productos o servicios
existentes son entregados a los clientes. En este proceso se esperan
mediciones que tengan en cuenta la excelencia operacional (alta
productividad), y la reducción de costos (minimizar el retrabajo).
o Servicio Posventa
Refiere al proceso de negocio en que se brinda servicio de soporte y
mantenimiento al cliente, posterior a la venta o entrega de un producto
o servicio. Las mediciones que se pueden usar para este proceso son:
tiempos de resolución de incidentes, y eficiencia de costos de
recursos.
29. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 29 de 87
6.2.4. Perspectiva de Aprendizaje y Crecimiento
La Perspectiva de Aprendizaje y Crecimiento permite que la organización
identifique la infraestructura que debe desarrollar para crear aprendizaje y
crecimiento de las personas, a largo plazo. El aprendizaje organizacional se basa en
tres pilares: personas, sistemas, y procedimientos organizacionales.
Las otras tres perspectivas del BSC, identificarán que existe una brecha entre
la situación actual y los objetivos que se plantean. La forma en que esta brecha puede
ir reduciéndose, es mediante: la capacitación de las personas; la mejora en los
sistemas de información y de manejo del conocimiento; y el alineamiento de las
personas a la estrategia de la organización.
Las mediciones en esta perspectiva están relacionadas con la satisfacción y
los niveles de retención de los empleados, las horas de capacitación, y la evaluación
de las competencias. Los sistemas pueden ser medidos mediante el nivel de consulta
y crecimiento de la información crítica de los procesos centrales de negocio, en los
repositorios organizacionales de información. El alineamiento de las personas a la
estrategia de la organización, puede medirse mediante el uso de un BSC personal que
este asociado a los objetivos estratégicos del BSC de la organización.
Dentro de la Perspectiva de Aprendizaje y Crecimiento, existen algunas
categorías que son estándares a todas las organizaciones, y sobre las que se
recomienda tomar las mediciones para el BSC:
o Capacidades de los Empleados
Refiere a las capacidades que deben contar los empleados para
implementar en forma eficiente los procesos internos, para construir
productos o servicios que satisfagan las necesidades de los clientes.
En esta categoría, se podrá medir: la satisfacción del empleado; la
retención de empleados; la cantidad de horas de capacitación
brindada; la productividad de empleados.
o Capacidades de los Sistemas de Información
Refiere a las capacidades que se le requerirán a los sistemas de
información, para brindar la información adecuada para la toma de
decisiones en cuanto a procesos internos, clientes, y variables
30. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 30 de 87
financieras. Mediciones disponibles son: porcentaje de procesos con
información online; tasa de uso de base de conocimiento.
o Motivación, Empowerment, y Alineamiento
Refiere al clima organizacional para lograr dar motivación e iniciativa
a los empleados. En esta categoría se podrá medir: alineamiento entre
individuo y organización; performance de equipos; cantidad de
sugerencias realizadas; evaluaciones 360°.
6.3. Mapas Estratégicos
Posteriormente al artículo en Harvard Business Review [2], y al libro en que
desarrollaron el concepto del Balanced Scorecard [3], Kaplan y Norton siguieron
evolucionando este modelo de gestión y propusieron los Mapas Estratégicos –
nuevamente en un artículo de HBR [4]. Un Mapa Estratégico (ME) es una
representación visual de los objetivos críticos de una compañía y las relaciones
cruciales que existen entre estos, y que guían la performance organizacional. Uno de
sus grandes beneficios, es poder comunicar la estrategia a toda la organización.
Al igual que el BSC, un Mapa Estratégico muestra (entre otros): objetivos
financieros de incremento de ganancias o reducción de costos; segmentos y cuotas de
mercado a los que se apunta; procesos claves en que se debe tener una buena
performance; niveles de satisfacción en los empleados para mantener la motivación y
lograr el crecimiento.
El objetivo del Mapa Estratégico es tener una visualización de las relaciones
causa-efecto que existen entre los resultados requeridos y los elementos que guían
esos resultados. Está dado por la asociación, mediante relaciones, entre los distintos
objetivos de las cuatros perspectivas del BSC. El Mapa Estratégico habilita a la
organización a describir e ilustrar de manera concisa y con un lenguaje claro: sus
objetivos, iniciativas, y metas; sus mediciones para monitorear la performance; y las
relaciones que son la fundación para la dirección estratégica.
31. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 31 de 87
A modo de ejemplo, se presenta un Mapa Estratégico genérico, de una
Empresa de Software, con una estrategia de Lock-In para adquirir y retener a sus
clientes. En el mismo, se perciben:
o Las cuatros perspectivas del BSC: Financiera, Cliente, Procesos
Internos, Aprendizaje y Crecimiento.
o Los objetivos de cada perspectiva; por ejemplo: Aumentar Valor para
el Accionista, Ingresos de Nuevos Clientes, Bajar costo de
lanzamiento de nuevos productos.
o Las relaciones entres los objetivos: representados por las flechas que
indican la relación causa-efecto. Por ejemplo: dentro de la Perspectiva
de Cliente, el objetivo de Proveer canales de distribución
convenientes da soporte al logro del objetivo de Ingresos de Nuevos
Clientes, en la Perspectiva Financiera.
o Las agrupaciones temáticas asociadas a las distintas líneas estratégicas
de la empresa. Por ejemplo: Gestión de Operaciones, Gestión de
Clientes, en la Perspectiva de Procesos Internos.
32. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 32 de 87
Figura 4. Mapa Estratégico de una Empresa de Software con una estrategia de Lock-In.
Tomado como ejemplo de [6].
6.4. Resumen
A lo largo del capítulo, se ha descripto el modelo de gestión de Balanced
Scorecard y la representación visual de la estrategia mediante Mapas Estratégicos.
Estos dos elementos, propuestos por Kaplan y Norton, sirven para difundir los
objetivos estratégicos de la empresa, y monitorear la performance en el logro de
dichos objetivos. Mediante la definición de objetivos en las cuatro perspectivas del
BSC, y mediciones para evaluar el cumplimiento de estos, se busca cuantificar la
brecha que existe entre la situación actual y la situación futura a la que se desea
llegar.
En el siguiente capítulo, se presenta un Mapa Estratégico para evaluar los
beneficios de la Mejora de Procesos usando el Modelo CMMI.
33. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 33 de 87
7. Diseño del Mapa Estratégico para Evaluación de
Performance
7.1. Objetivos Estratégicos
Desde el punto de vista estratégico, la Mejora de Procesos usando el Modelo
CMMI como referencia, tiene dos objetivos que son clave para la organización: la
reducción de los costos operativos, y el incremento de los ingresos.
La reducción de los costos operativos es lograda mediante la aplicación
sistemática de las prácticas específicas de las áreas de proceso que existen en cada
nivel de CMMI. Estas prácticas específicas han sido ampliamente probadas en la
industria, y hay gran cantidad de evidencia que demuestra que logran reducir costos
operacionales.
El incremento de los ingresos es logrado mediante una mayor satisfacción del
cliente, al percibir la mejora en calidad, lo que promueve una relación de confianza
con el proveedor. Esta relación de confianza permite lograr una mejor predisposición
del cliente para seleccionar al proveedor para la adquisición de nuevos productos y
servicios, y promueve la recomendación del proveedor a otros clientes. Más aún, la
mejora de procesos permite trasladar la reducción de costos a precios más accesibles
de las soluciones ofrecidas a los clientes, lo que se traduce en un incremento en el
relacionamiento y el volumen de adquisiciones.
A partir de estos objetivos, se propone un Mapa Estratégico que será la base
del desarrollo de esta tesis. Este Mapa Estratégico contempla objetivos en las cuatro
perspectivas, cuya performance se verá beneficiada por las áreas de proceso del
Nivel 2 de CMMI.
Cabe remarcar, que el Mapa Estratégico planteado, no cubre todos los
aspectos de la cadena de valor de una empresa, sino que abarca únicamente aquellos
objetivos que se ven afectados por la Mejora de Proceso. Consecuentemente, da una
visión parcial de la implementación de la estrategia en una organización.
34. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 34 de 87
Figura 5. Mapa Estratégico con los Objetivos Estratégicos de la Mejora de Proceso en las
cuatro perspectivas.
7.1.1. Descripción de los Objetivos Estratégicos de la Perspectiva
Financiera
Los objetivos de la perspectiva financiera miden si la definición y la
ejecución de la estrategia, sirven al resultado financiero de la organización.
77..11..11..11.. Objetivo Estratégico F1 – Valor Sustentable para los
Accionistas
Este objetivo está alineado con la estrategia de continuidad de negocio en el
corto plazo de la organización: dar valor sustentable a sus accionistas. Esto es clave
para mantener la empresa operando a lo largo del tiempo, con un nivel de capital
saludable.
35. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 35 de 87
77..11..11..22.. OObbjjeettiivvoo EEssttrraattééggiiccoo FF22 –– RReedduucciirr llooss CCoossttooss OOppeerraattiivvooss
Este objetivo responde a la necesidad de reducir costos, para poder
incrementar la rentabilidad de la empresa.
77..11..11..33.. OObbjjeettiivvoo EEssttrraattééggiiccoo FF33 –– CCrreecceerr eenn FFaaccttuurraacciióónn
Este objetivo responde a la necesidad de crecer en ingresos en función de las
ventas de productos y servicios, para poder incrementar la rentabilidad de la
empresa.
7.1.2. Descripción de los Objetivos Estratégicos de la Perspectiva
de Cliente
Los objetivos de la perspectiva de cliente sirven para medir, si la Mejora de
Proceso, está alineada con la provisión de productos y servicios que agreguen valor a
los clientes.
77..11..22..11.. OObbjjeettiivvoo EEssttrraattééggiiccoo CC11 –– EEnnttrreeggaarr PPrroodduuccttooss yy SSeerrvviicciiooss
PPeerrcciibbiiddooss ppoorr eell CClliieennttee ccoommoo ddee AAllttaa CCaalliiddaadd
Este objetivo establece la necesidad del cliente de tener altos niveles de
calidad en todos los productos y servicios que adquiere.
77..11..22..22.. OObbjjeettiivvoo EEssttrraattééggiiccoo CC22 –– TTeenneerr TTiieemmppooss PPrreeddeecciibblleess ddee
EEnnttrreeggaa
Este objetivo establece la necesidad del cliente de tiempos de entrega
planificados, y predecibles.
77..11..22..33.. OObbjjeettiivvoo EEssttrraattééggiiccoo CC33 –– BBrriinnddaarr SSoolluucciioonneess aa PPrreecciiooss
AAcccceessiibblleess
Este objetivo establece la necesidad del cliente de poder acceder a productos
y servicios que sean accesibles, en relación a las especificaciones que poseen.
36. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 36 de 87
77..11..22..44.. OObbjjeettiivvoo EEssttrraattééggiiccoo CC44 –– SSeerr PPeerrcciibbiiddoo ppoorr eell CClliieennttee ccoommoo
SSoocciioo TTeeccnnoollóóggiiccoo ddee LLaarrggoo PPllaazzoo
Este objetivo establece la necesidad del cliente de tener un socio tecnológico,
que lo acompañe en el tiempo, y le provea soluciones a todas sus necesidades en el
área de tecnología de la información.
7.1.3. Descripción de los Objetivos Estratégicos de la Perspectiva
de Procesos Internos
Los objetivos de la perspectiva de procesos internos, sirven para medir si la
Mejora de Proceso está alineada con una mayor eficiencia de los procesos internos,
con los cuales se desarrollan los productos y servicios que se entregan a los clientes.
77..11..33..11.. OObbjjeettiivvoo EEssttrraattééggiiccoo PP11 –– GGeessttiioonnaarr eenn FFoorrmmaa ÁÁggiill llooss
PPrrooyyeeccttooss
Este objetivo establece la necesidad de ejecutar proyectos en forma ágil,
teniendo tiempos cortos de desarrollo, que le permitan a los clientes recibir los
productos y servicios rápidamente, estableciendo ventajas competitivas por sobre sus
competidores.
77..11..33..22.. OObbjjeettiivvoo EEssttrraattééggiiccoo PP22 –– GGaarraannttiizzaarr AAllttooss NNiivveelleess ddee CCaalliiddaadd
Este objetivo establece la necesidad de embeber la calidad en los procesos de
desarrollo, basándose en las áreas de proceso de CMMI Nivel 2. La calidad de los
procesos habilitará a construir productos de calidad.
77..11..33..33.. OObbjjeettiivvoo EEssttrraattééggiiccoo PP33 –– OOppttiimmiizzaarr PPrroocceessooss ddee DDeessaarrrroolllloo
Este objetivo establece la necesidad de optimizar los procesos internos, para
eliminar cualquier costo extra que no agregue valor, y reducir el nivel de retrabajo.
37. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 37 de 87
7.1.4. Descripción de los Objetivos Estratégicos de la Perspectiva
de Aprendizaje y Crecimiento
Los objetivos de la perspectiva de aprendizaje y crecimiento sirven para
medir si la Mejora de Proceso está alineada con la capacidad de la organización, para
aprender, mejorar, y adaptarse a las necesidades de sus clientes.
Se enfocan en tres puntos: el desempeño de los individuos, la infraestructura
tecnológica para soportar el crecimiento, y la cultura corporativa.
77..11..44..11.. OObbjjeettiivvoo EEssttrraattééggiiccoo AA11 –– DDeessaarrrroollllaarr CCuuaalliiddaaddeess TTééccnniiccaass
Este objetivo establece la necesidad de medir el desarrollo de las capacidades
técnicas de los empleados de la organización, necesarias para ejecutar los procesos
internos.
77..11..44..22.. OObbjjeettiivvoo EEssttrraattééggiiccoo AA22 –– DDeessaarrrroollllaarr CCuuaalliiddaaddeess ddee GGeessttiióónn
yy LLiiddeerraazzggoo
Este objetivo establece la necesidad de medir el desarrollo de las capacidades
de gestión y liderazgo de los empleados de la organización, necesarias para ejecutar
los procesos internos.
77..11..44..33.. OObbjjeettiivvoo EEssttrraattééggiiccoo AA33 –– CCoommppaarrttiirr BBuueennaass PPrrááccttiiccaass
Este objetivo establece la necesidad de lograr un crecimiento organizacional,
mediante la difusión y mejora de buenas prácticas que surgen de la implementación
de la Mejora de Proceso.
77..11..44..44.. OObbjjeettiivvoo EEssttrraattééggiiccoo AA44 –– AAlliinneeaarr OObbjjeettiivvooss PPeerrssoonnaalleess ccoonn llaa
EEssttrraatteeggiiaa
Este objetivo establece la necesidad de alinear los objetivos de cada individuo
con los objetivos estratégicos de la Mejora de Proceso. Para esto se define el uso de
un BSC Personal, acorde a cada persona y el rol que ocupa en la organización.
38. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 38 de 87
7.2. Mapa Estratégico con Indicadores
El Mapa Estratégico debe estar soportado por indicadores que miden el
cumplimiento de los Objetivos Estratégicos. En este punto, se establece el BSC con
los indicadores que serán utilizados a lo largo del tiempo, para validar que la Mejora
de Proceso brinda beneficios cuantitativos y cualitativos a la organización. A
continuación, se presentan los indicadores que serán utilizados por cada uno de los
Objetivos Estratégicos propuestos en el punto anterior.
Figura 6. Mapa Estratégico con Indicadores por cada Objetivo Estratégico, orientado a la
performance de la Mejora de Proceso.
Se analizará en detalle los objetivos e indicadores de cada perspectiva del
Mapa Estratégico Planteado. Por cada indicador, se presentará la información que es
detallada en la siguiente tabla:
<<NNoommbbrree ddeell IInnddiiccaaddoorr>>
Breve descripción Detallar aquí el indicador a definir.
39. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 39 de 87
Necesidades de
información que
satisface
Detallar aquí las necesidades de información que satisface
este indicador. Puede ser necesidades de información
específicas del proyecto o alguna de las mandatarias.
Tipo de decisión que
soporta el indicador
Detallar aquí que tipo de decisiones son soportadas por
este indicador. Ej. decisiones técnicas, de gestión, acerca
de recursos humanos, estratégicas u operacionales
Quién toma las
decisiones
Especificar aquí quien utilizará el indicador para tomar
decisiones.
Quién recopila los
datos
En general se detalla aquí que roles deben recopilar los
datos para soportar el indicador.
Cómo se recopilan los
datos
Aquí se debe especificar que datos, de donde se deben
obtener.
Cuándo se debe
recopilar los datos
Especificar aquí la frecuencia de los datos a recopilar:
diaria, semanal, mensual.
Cómo deben ser
analizados los datos
Detallar aquí los indicadores definidos para la toma de
decisiones que soportan a la medición, detallar las
fórmulas para obtener esos indicadores y cuales son sus
valores típicos y tolerancias.
7.2.1. Indicadores de la Perspectiva Financiera
A continuación, se describen los indicadores que se tomarán para cada
objetivo del Mapa Estratégico en esta perspectiva.
77..22..11..11.. OObbjjeettiivvoo EEssttrraattééggiiccoo FF11 –– VVaalloorr SSuusstteennttaabbllee ppaarraa llooss
AAcccciioonniissttaass
EEBBIITT
Breve descripción Es una medida que da cuenta de la rentabilidad de la
empresa. La sigla viene del inglés Earnings Before
Interest & Tax (Ingresos Antes de Intereses e Impuestos).
Se obtiene haciendo la siguiente ecuación:
EBIT = Ingresos – Costos Operativos
Necesidades de
información que
satisface
El EBIT es de vital importancia para los accionistas de la
empresa. El mismo indica en forma cuantitativa, la
rentabilidad de una empresa, sin tomar en cuenta las
estructuras de capital e impuestos usados por diferentes
compañías.
Tipo de decisión que
soporta el indicador
Si bien da una visión de corto plazo, este indicador
permite tomar decisiones de gestión a nivel estratégico.
40. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 40 de 87
Quién toma las
decisiones
El comité de dirección tomará decisiones a partir de este
indicador.
Quién recopila los
datos
En general, está información será recopilada por el área de
Administración y Finanzas de la empresa.
Cómo se recopilan los
datos
La información del EBIT forma parte de la planilla de
resumen financiero (PNL) de la empresa.
Cuándo se debe
recopilar los datos
Esta información suele obtenerse en forma semestral o
anual, cuando se hace el cierre de resultados del período.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada un incremento del EBIT, a causa del beneficio
directo en la reducción de los Costos Operativos por una
mayor eficiencia de los procesos de desarrollo que se
estandarizan con las prácticas de CMMI.
Más aún, se tiene un beneficio indirecto de aumento en los
ingresos, por mejor percepción del cliente en cuanto a la
calidad de los productos o servicios entregados.
RROOCCEE
Breve descripción Es una medida que da cuenta del retorno que se tiene
sobre el capital invertido. La sigla viene del inglés Return
on Capital Employed (Retorno sobre el Capital
Empleado). Se obtiene haciendo la siguiente ecuación:
ROCE = Ganancias Netas / Capital Empleado x 100
Necesidades de
información que
satisface
El ROCE es de vital importancia para los accionistas de la
empresa. El mismo indica en forma cuantitativa, el valor
que el negocio gana a partir de su activo y pasivo.
Tipo de decisión que
soporta el indicador
Si bien da una visión de corto plazo, este indicador
permite tomar decisiones de gestión a nivel estratégico.
Quién toma las
decisiones
El comité de dirección y la gerencia de finanzas tomarán
decisiones a partir de este indicador.
Quién recopila los
datos
En general, está información será recopilada por el área de
Administración y Finanzas de la empresa.
Cómo se recopilan los
datos
La información del ROCE forma parte de la planilla de
resumen financiero (PNL) de la empresa.
Cuándo se debe
recopilar los datos
Esta información suele obtenerse en forma semestral o
anual, cuando se hace el cierre de resultados del período.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada dos beneficios directos: 1) en el incremento de
las Ganancias Netas, lo que se deba a una reducción de
costos, dada por la mayor eficiencia de los procesos de
desarrollo que se estandarizan con las prácticas de CMMI;
2) se tiene un beneficio directo de reducción en el capital
empleado, por tener menor nivel de retrabajo en la
41. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 41 de 87
ejecución de los procesos internos, optimizando la
inversión de capital.
77..22..11..22.. OObbjjeettiivvoo EEssttrraattééggiiccoo FF22 –– RReedduucciirr llooss CCoossttooss OOppeerraattiivvooss
RReedduucccciióónn ddee CCoossttooss
Breve descripción Es la suma de todos los costos operativos de la
organización sobre los ingresos totales. En el concepto de
costos se incluye: costos de los productos o servicios
entregados, costos administrativos e indirectos,
depreciación y amortización de bienes, otros costos. Este
porcentaje debería ir disminuyendo a medida se van
implementando los procesos.
Costos Totales = Costos Operativos / Ingresos Totales
x 100
Necesidades de
información que
satisface
Los Costos Totales son uno de los aspectos críticos de las
finanzas en una organización. El poder tener una
importante reducción de costos, permite a la organización
tener mayores ganancias, y poder realizar su operatoria
con un menor nivel de flujo de caja.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a nivel
operativo.
Quién toma las
decisiones
El comité de dirección y la gerencia de finanzas tomarán
decisiones a partir de este indicador.
Quién recopila los
datos
En general, está información será recopilada por el área de
Administración y Finanzas de la empresa.
Cómo se recopilan los
datos
La información de los Costos Operativos forma parte de la
planilla de resumen financiero (PNL) de la empresa.
Cuándo se debe
recopilar los datos
Esta información suele obtenerse en forma semestral o
anual, cuando se hace el cierre de resultados del período.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio directo en una Reducción de los
Costos Totales, por la mejor eficiencia de los procesos de
desarrollo que se estandarizan con las prácticas de CMMI.
77..22..11..33.. OObbjjeettiivvoo EEssttrraattééggiiccoo FF33 –– CCrreecceerr eenn FFaaccttuurraacciióónn
IInnccrreemmeennttoo eenn FFaaccttuurraacciióónn TToottaall
Breve descripción Representa los ingresos totales de la organización, por
venta de productos y servicios.
Necesidades de La facturación total de la organización es lo que permite
42. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 42 de 87
información que
satisface
que la misma perdure en el tiempo.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo.
Quién toma las
decisiones
El comité de dirección y las unidades de negocio tomarán
decisiones a partir de este indicador.
Quién recopila los
datos
En general, está información será recopilada por el área
de Administración y Finanzas de la empresa.
Cómo se recopilan los
datos
La información de la facturación forma parte de la
planilla de resumen financiero (PNL) de la empresa.
Cuándo se debe
recopilar los datos
Esta información suele obtenerse en forma semestral o
anual, cuando se hace el cierre de resultados del período.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio indirecto en el incremento de la
facturación total, por mejor percepción de los clientes en
cuanto a la calidad de los productos o servicios
entregados.
IInnccrreemmeennttoo eenn FFaaccttuurraacciióónn ppoorr CClliieennttee
Breve descripción Representa los ingresos de la organización por venta de
productos o servicios, segmentados por cliente.
Necesidades de
información que
satisface
La facturación de la organización segmentada por cliente,
permite analizar como el nivel de ventas con cada cliente
va evolucionando, a medida aumenta el grado de
confianza entre las partes. Esto permite tener incrementos
en las ventas por cliente.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo.
Quién toma las
decisiones
Las unidades de negocio tomarán decisiones a partir de
este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por la gerencia comercial.
Cómo se recopilan los
datos
La información de la facturación por cliente, se obtendrá
del cruce de información entre la planilla de resumen
financiero (PNL) por cada unidad de negocio, y los
clientes de dicha unidad de negocio.
Cuándo se debe
recopilar los datos
Esta información suele obtenerse en forma semestral o
anual, cuando se hace el cierre de resultados del período.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio indirecto en el incremento de la
facturación por cliente, por mejor percepción del cliente
en cuanto a la calidad de los productos o servicios
43. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 43 de 87
entregados.
7.2.2. Indicadores de la Perspectiva de Cliente
A continuación, los indicadores que se tomarán para cada objetivo del Mapa
Estratégico en esta perspectiva.
77..22..22..11.. OObbjjeettiivvoo EEssttrraattééggiiccoo CC11 –– EEnnttrreeggaarr PPrroodduuccttooss yy SSeerrvviicciiooss
PPeerrcciibbiiddooss ppoorr eell CClliieennttee ccoommoo ddee AAllttaa CCaalliiddaadd
PPeerrcceeppcciióónn ddee CCaalliiddaadd ddee PPrroodduuccttoo
Breve descripción Está dada por el grado de calidad que percibe el cliente,
sobre los productos o servicios que recibe.
Necesidades de
información que
satisface
La percepción de calidad es un indicador de conformidad
del producto a los requerimientos del cliente. Establece
el grado de satisfacción de un cliente respecto a los
productos y servicios.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo, principalmente en la perspectiva de
procesos internos.
Quién toma las
decisiones
Las unidades de negocio tomarán decisiones a partir de
este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por la gerencia comercial.
Cómo se recopilan los
datos
La percepción de calidad será recopilada mediante
Encuestas de Calidad de Productos y Servicios. Estas
encuestas se harán a los clientes en los segmentos clave,
posteriormente a la entrega de productos.
Cuándo se debe
recopilar los datos
La periodicidad estará dada por criterios comerciales. O
bien se harán luego de ventas puntuales, o bien en
momentos del tiempo pre-establecidos.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio directo en una mejor percepción
de calidad del cliente.
TTaassaa ddee RReeccllaammooss
Breve descripción Está dada por la cantidad de quejas o reclamos que hace
el cliente, posterior a la entrega del producto o servicio.
Necesidades de
información que
La tasa de quejas o reclamos es un indicador de
conformidad del cliente con la solución. Está
44. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 44 de 87
satisface íntimamente relacionada con la calidad percibida por el
cliente.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo, principalmente en la perspectiva de
procesos internos.
Quién toma las
decisiones
Las unidades de negocio tomarán decisiones a partir de
este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por la gerencia comercial, el comité de proyectos, o la
oficina de proyectos (PMO).
Cómo se recopilan los
datos
La tasa de reclamos será recopilada mediante alguna
herramienta de CRM (Customer Relationship
Management), o bien de Issue Tracking (Seguimiento de
Incidentes). En estas herramientas, se registran los
reclamos que hacen los clientes, y se mantiene el
historial de diagnóstico y resolución de los mismos.
Posteriormente, se obtienen estadísticas de los niveles de
servicio que se tiene para la resolución de estos
problemas.
Cuándo se debe
recopilar los datos
La información es recopilada en forma continua, ya que
los reclamos o quejas pueden suceder en cualquier
momento del tiempo.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio directo en una reducción en la tasa
de reclamos o quejas.
77..22..22..22.. OObbjjeettiivvoo EEssttrraattééggiiccoo CC22 –– TTeenneerr TTiieemmppooss PPrreeddeecciibblleess ddee
EEnnttrreeggaa
TTiieemmppoo PPllaanniiffiiccaaddoo vvss TTiieemmppoo RReeaall
Breve descripción Está dado por el desvío en tiempos en la entrega de los
productos o servicios. Este indicador es de gran
importancia en los proyectos de desarrollo de software,
en donde se suelen detectar altos niveles de desvío. Este
indicador surge de la siguiente fórmula:
Desvío en Tiempos =
[ (Duración Real – Duración Planificada) / Duración
Planificada ] x 100
Necesidades de
información que
satisface
Los desvíos en tiempos que implican retrasos, impactan
negativamente en el grado de satisfacción de un cliente
respecto a los productos y servicios.
45. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 45 de 87
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo, principalmente en la perspectiva de
procesos internos.
Quién toma las
decisiones
Las unidades de negocio tomarán decisiones a partir de
este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por el comité de proyectos, o la oficina de proyectos
(PMO).
Cómo se recopilan los
datos
Los desvíos en tiempos serán tomados de las reuniones
de cierre de proyectos, o bien de las entregas de
productos y servicios.
Cuándo se debe
recopilar los datos
La periodicidad estará dada por los tiempos de cierre de
proyectos, o bien en momentos del tiempo pre-
establecidos.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio directo en menores desvíos en
tiempos, gracias a dos áreas de proceso de CMMI Nivel
2: PP y PMC.
77..22..22..33.. OObbjjeettiivvoo EEssttrraattééggiiccoo CC33 –– BBrriinnddaarr SSoolluucciioonneess aa PPrreecciiooss
AAcccceessiibblleess
RReedduucccciióónn eenn PPrreecciiooss ddee PPrroodduuccttooss yy SSeerrvviicciiooss
Breve descripción Está dada por el precio de los productos y servicios que se
le ofrecen al cliente. Se valorizarán los precios en función
de la percepción de los clientes, quienes analizan la oferta
del proveedor contra la de otros proveedores, al momento
de encarar un proyecto.
Necesidades de
información que
satisface
Los Costos Operativos tendrán relación directa con los
precios de los productos y servicios. El poder reducir el
nivel de costos, permite a la organización tener precios
más accesibles en sus propuestas a los clientes.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo.
Quién toma las
decisiones
Las unidades de negocio tomarán decisiones a partir de
este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por la gerencia comercial.
Cómo se recopilan los
datos
La percepción de los precios será recopilada mediante
Encuestas de Productos y Servicios. Estas encuestas se
harán a los clientes en los segmentos clave,
46. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 46 de 87
posteriormente a la entrega.
Cuándo se debe
recopilar los datos
La periodicidad estará dada por criterios comerciales. O
bien se harán luego de ventas puntuales, o bien en
momentos del tiempo pre-establecidos.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio directo en una mejor percepción de
precios de productos y servicios por parte del cliente.
77..22..22..44.. OObbjjeettiivvoo EEssttrraattééggiiccoo CC44 –– SSeerr PPeerrcciibbiiddoo ppoorr eell CClliieennttee ccoommoo
SSoocciioo TTeeccnnoollóóggiiccoo ddee LLaarrggoo PPllaazzoo
CCaannttiiddaadd ddee CCoonnttrraattooss ppoorr CClliieennttee
Breve descripción Está dada por la cantidad de contratos en el período
analizado. Los contratos estarán dados por distintos
productos y servicios que le son ofrecidos al cliente, para
atender sus necesidades. Para monitorear este indicador,
se tomará el promedio de contratos por cliente:
Cantidad de Contratos por Cliente = Cantidad de
Contratos / Cantidad de Clientes
Necesidades de
información que
satisface
La cantidad de contratos por cliente es un indicador de
cuanto se va profundizando la relación con el cliente. A
medida un cliente cierra más contratos con un proveedor,
se va generando una relación de partnership que
trasciende a lo largo del tiempo.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a nivel
operativo, principalmente en la perspectiva de procesos
internos.
Quién toma las
decisiones
Las unidades de negocio tomarán decisiones a partir de
este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por la gerencia comercial.
Cómo se recopilan los
datos
El inventario de contratos será registrado en algún sistema
de Customer Relationship Management (CRM). En el
mismo se irán cargando los nuevos contratos que vayan
surgiendo con cada cliente.
Cuándo se debe
recopilar los datos
La periodicidad estará dada por criterios comerciales. O
bien se harán luego de ventas puntuales, o bien en
momentos del tiempo pre-establecidos.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio directo en un incremento en la
cantidad de contratos por cliente.
47. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 47 de 87
PPeerrmmaanneenncciiaa MMeeddiiaa ddeell CClliieennttee eenn llaa EEmmpprreessaa
Breve descripción Está dada por el tiempo total, medido en años/meses, de
permanencia media de los clientes en la empresa. Se
entiende permanencia por el período en que un cliente
está activo mediante la adquisición de productos y
servicios. Se deberá definir cual es el lapso en
años/meses, para que un cliente pase a estar inactivo.
Necesidades de
información que
satisface
La permanencia media del cliente en la empresa es un
indicador de la satisfacción de un cliente con los
productos o servicios de la empresa. Cuanto más
permanecen los clientes en la empresa, más se va
forjando una relación de lock-in, en que las barreras de
salida del cliente para con el proveedor, pasan a ser lo
suficientemente altas como para quebrar esta relación.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo, principalmente en la atención de las
necesidades del cliente.
Quién toma las
decisiones
Las unidades de negocio y la gerencia comercial tomarán
decisiones a partir de este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por la gerencia comercial.
Cómo se recopilan los
datos
La permanencia media se podrá extraer de algún sistema
de Customer Relationship Management (CRM), en el
cual se podrán configurar los clientes activos e inactivos,
y calcular los tiempos de permanencia.
Cuándo se debe
recopilar los datos
La periodicidad estará dada por criterios comerciales.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio directo en una mayor permanencia
media de los clientes en la empresa.
7.2.3. Indicadores de la Perspectiva de Procesos Internos
A continuación, los indicadores que se tomarán para cada objetivo del Mapa
Estratégico en esta perspectiva.
48. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 48 de 87
77..22..33..11.. OObbjjeettiivvoo EEssttrraattééggiiccoo PP11 –– GGeessttiioonnaarr eenn FFoorrmmaa ÁÁggiill llooss
PPrrooyyeeccttooss
TTiimmee ttoo MMaarrkkeett
Breve descripción Está dado por el tiempo hasta que es liberado un nuevo
producto o servicio al cliente. En la realidad de negocio
actual, los clientes demandan tiempos al mercado más
rápidos. Para esto, existen una serie de metodologías
ágiles (XP, Scrum FDD), que ayudan a reducir el Time to
Market.
Necesidades de
información que
satisface
El time to market es un criterio de negocio de alta
importancia para la mayoría de los clientes. A medida los
negocios se hacen más competitivos, es necesario poder
responder rápidamente al mercado con nuevos productos
y servicios. Los proyectos informáticos no escapan esta
realidad de negocio, con lo cual debe garantizarse que se
hagan entregas rápidas.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo, principalmente en la perspectiva de
procesos internos.
Quién toma las
decisiones
Las unidades de negocio tomarán decisiones a partir de
este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por el comité de proyectos, o la oficina de proyectos
(PMO).
Cómo se recopilan los
datos
El time to market será tomado de las reuniones de cierre
de proyectos, o bien de las entregas de productos o
servicios.
Cuándo se debe
recopilar los datos
La periodicidad estará dada por los tiempos de cierre de
proyectos, o bien en momentos del tiempo pre-
establecidos.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos debería traer
aparejada el beneficio directo en time to market más
reducidos, gracias a dos áreas de proceso de CMMI Nivel
2: PP y PMC, que permiten coordinar mejor las
actividades, haciendo más eficiente el desarrollo de
software.
49. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 49 de 87
77..22..33..22.. OObbjjeettiivvoo EEssttrraattééggiiccoo PP22 –– GGaarraannttiizzaarr AAllttooss NNiivveelleess ddee CCaalliiddaadd
TTaassaa ddee DDeeffeeccttooss
Breve descripción Está dada por la cantidad de defectos que posee el
producto o servicio que es entregado al cliente. Los
defectos en aplicaciones de software reciben la
denominación de bugs. Para tener un criterio comparable
en distintos proyectos, la medida a utilizar será:
Tasa de Defectos = Cantidad de Defectos / Casos de
Uso3
Necesidades de
información que
satisface
La tasa de bugs es un indicador directo del nivel de
calidad del producto o servicio que se entrega al cliente.
Si bien existen departamentos internos de Aseguramiento
de la Calidad (QA), que se encargan de detectar los bugs,
haciendo que sean corregidos, en general las aplicaciones
son entregadas al cliente con un nivel conocido de bugs.
Estos bugs se van corrigiendo durante el período de
garantía del producto, hasta que el producto queda
estabilizado.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo, principalmente en la perspectiva de
procesos internos.
Quién toma las
decisiones
Las unidades de negocio y el área de Aseguramiento de la
Calidad (QA) tomarán decisiones a partir de este
indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada el
área de Aseguramiento de la Calidad (QA).
Cómo se recopilan los
datos
La tasa de defectos (o bugs) será recopilada mediante
alguna herramienta de issue tracking, o bien mediante el
uso de planillas. En ambos casos, se registrará la cantidad
de bugs encontrados, y el estado de los mismos.
Cuándo se debe
recopilar los datos
La información es recopilada en forma continua, ya que
los defectos pueden suceder tanto durante el desarrollo
como el mantenimiento de los productos o servicios.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos vía CMMI Nivel 2,
debería traer aparejada una tasa de defectos decreciente,
gracias principalmente al área de proceso de PPQA. Esta
área de proceso permite garantizar la calidad en procesos
3
Un Caso de Uso es un modelo estándar para especificar requerimientos funcionales de una
aplicación de software. El Caso de Uso representa una interacción completa entre un usuario y un
sistema, para que el usuario logre algún objetivo de negocio específico. Cualquier proyecto de
sistemas tendrá un alcance que estará dado por un número finito de Casos de Uso, en los que estará
concentrada toda la funcionalidad a desarrollar.
50. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 50 de 87
y productos, y controlar que los mismos se adhieran a los
estándares y buenas prácticas definidas.
77..22..33..33.. OObbjjeettiivvoo EEssttrraattééggiiccoo PP33 –– OOppttiimmiizzaarr PPrroocceessooss ddee DDeessaarrrroolllloo
TTaassaa ddee RReettrraabbaajjoo
Breve descripción Es una medida de la cantidad de retrabajo que se debe
realizar durante el desarrollo de productos o servicios,
debida a la corrección de errores o defectos que son
detectados en fases posteriores. El retrabajo está
relacionado con esfuerzo extra que se debe hacer, debido
a la corrección de errores o defectos que se filtran durante
el desarrollo de una aplicación. Para medir la tasa de
retrabajo utilizaremos la siguiente fórmula:
Tasa de Retrabajo = Horas de Retrabajo / Casos de
Uso
Necesidades de
información que
satisface
La tasa de retrabajo es un indicador directo del nivel de
calidad en los procesos que son utilizados para el
desarrollo de productos o servicios. El tener niveles altos
de tasa de retrabajo implica que se está insumiendo
mucho esfuerzo en actividades que no agregan valor.
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo, principalmente en la perspectiva de
procesos internos.
Quién toma las
decisiones
Las unidades de negocio y el área de Aseguramiento de la
Calidad (QA) tomarán decisiones a partir de este
indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
en el área de Aseguramiento de la Calidad (QA).
Cómo se recopilan los
datos
La tasa de retrabajo será recopilada mediante el análisis
de los tiempos de corrección de errores o defectos en el
ciclo de vida del proyecto.
Cuándo se debe
recopilar los datos
La información es recopilada en forma continua, ya que
los errores o defectos pueden suceder tanto durante el
desarrollo como el mantenimiento de los productos o
servicios.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos vía CMMI Nivel 2,
debería traer aparejada una tasa de retrabajo decreciente,
consecuencia del área de proceso de PPQA. Esta área de
proceso permite tener garantizar la calidad en procesos y
productos, de manera de minimizar los errores o defectos
por no adherencia a los estándares.
51. Mejora de Procesos de Desarrollo de Software 1º Cuatrimestre 2009 EENI
Marcelo Schenone Página 51 de 87
RReedduucccciióónn ddeell EEssffuueerrzzoo ddee DDeessaarrrroolllloo
Breve descripción Es una medida del esfuerzo que se realiza para la
construcción de una unidad de software. La unidad de
software que se tomará es el Use Case Point (UCP), que
está basada en una técnica algorítmica que sirve para
estimar el esfuerzo de construcción del software [8]. La
fórmula para medir el esfuerzo de desarrollo es:
Esfuerzo de Desarrollo = Horas Hombre / UCP
Necesidades de
información que
satisface
El esfuerzo de desarrollo es un indicador directo del nivel
de productividad de los equipos de trabajo. El tener una
alta productividad equivale a tener procesos eficientes de
desarrollo de productos y servicios. La reducción del
esfuerzo de desarrollo significa que cada vez se requiere
menos esfuerzo para producir una unidad de software
(medida en UCP).
Tipo de decisión que
soporta el indicador
Este indicador permite tomar decisiones de gestión a
nivel operativo, principalmente en la perspectiva de
procesos internos.
Quién toma las
decisiones
Las unidades de negocio, el área de Procesos, y el área de
Aseguramiento de la Calidad (QA) tomarán decisiones a
partir de este indicador.
Quién recopila los
datos
En general, está información será recopilada por las
mismas unidades de negocio, o bien estará centralizada
por el comité de proyectos, o la oficina de proyectos
(PMO).
Cómo se recopilan los
datos
El esfuerzo de desarrollo será recopilado mediante el
análisis de los tiempos de desarrollo versus la cantidad de
UCP que se desarrollan.
Cuándo se debe
recopilar los datos
La información es recopilada principalmente al cierre de
los proyectos, en que se obtiene una medida total del
esfuerzo en horas hombre, y se obtiene el total de UCP
que fueron construidos.
Cómo deben ser
analizados los datos
En este caso, la Mejora de Procesos vía CMMI, debería
traer aparejada un esfuerzo de desarrollo decreciente,
consecuencia de las áreas de proceso del Nivel 2. A
medida, se implementan estas áreas de proceso, se
incrementa la productividad y se producen unidades de
software con menor esfuerzo total.
TTaassaa ddee RReeuussoo ddee CCoommppoonneenntteess
Breve descripción Es una medida del nivel de reuso de componentes que se
logra en la organización. Se define componente como
cualquier pieza de documentación o de aplicación, que es