CMMI® for Development, CMMI for Acquisition y CMMI for Services

Por David Arteaga

Procesos y Mejora de Procesos
La expriencia acumulada de tres décadas puede resumirse en una premisa que todo esfuerzo de mejora de procesos debe considerar “La calidad de un sistema, está altamente influenciado por la calidad del proceso usado para adquirirlo, desarrollarlo y mantenerlo(1). Esta premisa es válida para todas las industrias, pues las lecciones aprendidas nos enseñan que para mejorar el producto o servicio debemos mejorar la calidad del proceso usado para construir, dar mantenimiento o adquirir el producto.
Muchas veces esta premisa no se entiende o no se acepta por los malos entendidos existentes alrededor del concepto de proceso y de mejora de proceso. Cuando hablamos de proceso muchas personas se imaginan algo prescindible: documentación extensa con gráficos y flujo, que no siempre se usa y al que pocos le ven el valor. Veamos si podemos ayudar a corregir esta falsa percepción o mito. Debemos entender que el proceso son los pasos o actividades que seguimos para realizar nuestras responsabilidades y cumplir nuestro rol. Al hacer nuestro trabajo, todos seguimos un proceso. No podemos evitarlo. La pregunta es ¿qué proceso seguimos? La primera recomendación es que tengamos una descripción documentada del proceso que seguimos al hacer nuestro trabajo. Esto permite que nuestra organización realice actividades consistentes y tenga el medio imprescindible para mejorar. Para que la descripción documentada del proceso y para que el proceso proporcionen valor, deben cumplirse las siguientes condiciones:

• La descripción del proceso debe reflejar la forma real de trabajar, sino se convierte en un ejercicio teórico sin mayor utilidad. Es por esto que en la elaboración de una descripción de proceso, los participantes más importantes con los ejecutores del proceso. Sin ellos, el proceso documentado se convierte en un ejercicio teórico sin utilidad.
• El proceso debe ser el medio para capturar y compartir conocimiento, a través de las experiencias de los distintos participantes en la ejecución del proceso. Los ejecutores del proceso, deben, periódicamente, tomarse un tiempo para revisar la manera como trabajan, es decir, deben tomarse un tiempo para revisar la descripción del proceso. Deben analizarlo y mejorarlo, compartiendo sus experiencia, incorporando las lecciones aprendidas en el proceso.
• El proceso debe reflejar nuestra mejor forma de hacer las cosas. La descripción del proceso debe ser revisada y enriquecida periódicamente, por quienes ejecutan el proceso. Los ejecutores del proceso deben compartir sus experiencias y la luz de las mismas enriquecer el proceso.
• Los dos puntos anteriores quieren decir que un proceso y la descripción del proceso no son estáticos, no deben permanecer fijos año tras año. Deben ser dinámicos, deben actualizarse apropiadamente, deben mejorarse, deben tangibilizar el know-how de la organización y por tanto ser el medio para aprender.
• La mejora de procesos es un proceso de aprendizaje, pasamos del aprendizaje individual (hago las cosas como mejor me parece o según mi experiencia) al aprendizaje grupal (seguimos un proceso, que lo revisamos y lo mejoramos entre todos los que ejecutamos el proceso compartiendo nuestras lecciones aprendidas: qué hay que repetir en el siguiente proyecto, operación o servicio, que debemos dejar de hacer, aprendo también de los demás, no tengo que cometer los errores de los demás para aprender). Y luego del aprendizaje grupal al aprendizaje organizacional (los procesos deben funcionar de manera sincronizada y son los que permiten que la organización cumpla su misión, visión y sus estrategias, los procesos deben priorizarse y medirse).

La mejora de procesos busca que nuestros procesos sean procesos de calidad, en la medida que nuestros procesos son de calidad, el resultado de la ejecución del proceso, es decir, el producto o servicio, será de calidad. Eso es lo que busca la mejora de procesos, entregar productos y servicios de calidad. Ahora bien, ¿qué significa productos y servicios de calidad?
Como muchos dicen, la calidad es muy subjetiva a la persona que opina acerca de la calidad del producto o servicio que está usando. Eso es correcto, sin embargo, la experiencia nos dice cuáles son las características principales que debe tener un producto o servicio para que lo consideremos de calidad:

• No debe fallar de manera tal que haga que no podamos usar u operar el producto o servicio o que dejemos de usarlo. En algunas industrias, como la automotriz, aviación y medicina, buscaremos cero defectos, en otros como los servicios bancarios buscaremos tener la menor cantidad de defectos en la mayoría de aplicaciones, y habrá otros contextos, como los juegos de computadora, en los que puede suceder que el producto que usamos, sabemos que tiene muchos defectos, sin embargo, lo usamos, nos sirve y estamos inclusive dispuestos a pagar por él.
• Plazo y disponibilidad. El producto y servicio debemos tenerlo en el plazo acordado o cuando lo necesitamos. De nada sirve un producto o servicio que está listo cuando ya no lo necesitamos.
• Costo razonable y eficiencia. El costo para construir, mantener y operar un producto y servicio tiene las limitaciones que las restricciones presupuestales o precio de mercado imponen. Por tanto es importante que el costo de desarrollar, mantener y operar un producto y servicio sea el menor posible. Un factor importante que afecta este costo es la productividad de las personas, es entonces muy importante que midamos y mejoremos la productividad.
• Proporcionar la funcionalidad deseada. Un producto o servicio será valioso en la medida que funcione como queremos y en la medida que podamos operarlo o usarlo.

Al mejorar procesos logramos productos y servicios de calidad. Durante este camino de la mejora de procesos, es importante corroborar que el proceso está mejorando. La forma correcta de hacer esto, es midiendo el desempeño del proceso, esto incluye medidas de proceso así como medidas del producto o servicios producido. Cuando hablamos de medir el desempeño del proceso no nos estamos refiriendo a las métricas ó indicadores usuales que tienen las organizaciones y que la mayoría de las veces no están documentados, no se entienden, no se usan o se manipulan inapropiadamente. El desempeño de un proceso se refiere a medir la variabilidad de características del proceso y/ del producto o servicio del proceso. La variabilidad es inevitable, lo que logramos con la mejora de procesos es conocer la variabilidad, controlarla (predecirla dentro de límites razonables conocidos) y mejorarla (por ejemplo aminorar la variabilidad o trasladarla a valores superiores o inferiores).
Resumiendo lo explicado hasta aquí, las organizaciones y profesionales deben entender la importancia y beneficio de seguir un proceso e invertir inteligentemente en la mejora de procesos.
Ahora bien, ¿cómo podemos mejorar nuestros procesos? Pues hay el camino empírico, es decir, a prueba y error, que tiene muchos partidarios, básicamente por el desconocimiento que tienen de los modelos de mejora o porque han sido mal informados y/o mal capacitados al respecto. Cuando alguien dice no quiero saber nada de CMMI, ISO, ITIL o cualquier otro modelo de mejora, en realidad no sabe exactamente lo que está diciendo. Como dijimos al principio, queramos o no, todos seguimos un proceso. Y en un mundo racional, no conozco a alguien que diga no debemos mejorar nuestra forma de trabajo. De hecho todos estamos de acuerdo en que hay que mejorar los procesos, es decir, todos estamos de acuerdo en que hay que mejorar nuestra forma de trabajar, hacerla más rápida, mas eficiente, con menos fallas. Mejorar nuestra forma de trabajar es realizar esfuerzos de mejora de procesos. El CMMI, ISO, ITIL o cualquier otro modelo de mejora tiene ese propósito, mejorar nuestros procesos. Ningún modelo de mejora de procesos tiene como propósito hacer nuestros procesos burocráticos, lentos, ineficientes o no eficaces. Es absurdo. Sin embargo, muchos piensan así, y repito, eso se debe básicamente al desconocimiento de los modelos o porque han sido mal informados o mal capacitados, entre otras diversas razones.
La segunda forma de mejorar nuestros procesos es usar los modelos de mejora de procesos existentes, por ejemplo, el CMMI. Usar un modelo de mejora de procesos nos da el beneficio de aprovechar las lecciones aprendidas de miles de profesionales y organizaciones que ya recorrieron exitosamente el camino de mejora de procesos que queremos iniciar y de los que podemos aprender. Las lecciones aprendidas incluyen qué hacer y qué no debemos hacer.
No querer usar un modelo de mejora de procesos para mejorar los procesos me recuerda a cuando tengo conversaciones sobre la problemática de adolescentes. En la vida hay dos formas a prender: el estilo del adolescente, que dice: yo aprendo de mis experiencias y de lo que yo experimento. Es una forma válida de aprender pero tiene dos problemas: (i) está limitada a nuestras experiencias, no siempre tendremos la oportunidad de experimentar todas las posibles situaciones y vivencias, es imposible y además (ii) es peligrosa, a veces muy peligrosa. Este estilo significa que para decidir no consumir drogas pues primero habrá que probarlas, experimentar y luego concluir que es nocivo! De hecho a nadie le recomiendo ese estilo de aprendizaje. El otro estilo es el de la persona más experimentada: yo aprendo de mis experiencias pero también aprendo de los demás, de las experiencias de amigos, colegas o de las que hay en los buenos libros. No necesito cometer el mismo error que otros han cometido para aprender y puedo aprovechar las lecciones aprendidas de otros para aprender. Este segundo estilo de aprendizaje también tiene riesgos, hay que buscar buenas fuentes de conocimiento y de lecciones aprendidas y además hay que hacerlo con inteligencia. No podemos concluir que lo que es bueno para una organización, también será bueno replicándolo exactamente en otra organización.
Por tanto, hay que combinar ambos estilos de aprendizaje. Esto se aplica en la mejora de procesos. Si no usamos modelos de referencia, estamos limitados a nuestras vivencias, que no son todas, re-inventaremos la rueda constantemente y no aprovecharemos el avance que al respecto ha logrado la industria. Muchos de los productos y servicios que hoy nosotros como consumidores usamos tienen el grado de calidad que exigimos gracias a la mejora de procesos en dichas industrias. Nosotros somos usuarios y exigimos esos beneficios. Es paradójico que lo exijamos pero que no queramos que nuestros clientes y usuarios nos lo exijan en nuestro trabajo.

CMMI
Pasemos ahora el CMMI.
En sus inicios, el CMM para Software, allá por los años 80 tuvo un gran éxito y produjo el reconocimiento que hoy tiene el CMMI. Al lado del CMMI para Software surgieron otros CMMs. Al día de hoy, el ahora llamado CMMI, es una suite de productos y servicios que sirven para mejorar los procesos de las organizaciones. El CMMI for Development es el modelo más usado, más reconocido y de mayor éxito en la mejora de los procesos para los proyectos de ingeniería de software e ingeniería de sistemas de las organizaciones en el mundo. Sin embargo, poco o nada se sabe ahora acerca del alcance del CMMI. Hoy en día, el CMMI va mucho más allá que solo mejorar procesos de software. De hecho, la mayoría de organizaciones que en nuestro país y región usan el CMMI, usan el CMMI-DEV ó CMMI para Desarrollo (CMMI for Development) sólo para mejorar sus procesos de software. Sin embargo se desconoce que el CMMI para Desarrollo puede usarse también para mejorar los procesos de desarrollo y mantenimiento de productos y servicios que no son de software.
Por otro lado se desconoce también el alcance del CMMI para Adquisición y del CMMI para Servicios que a continuación explicaremos brevemente.

CMMI for Acquisition
Hoy en día la mayoría de organizaciones no producen completamente solas los productos y servicios que ofrecen a sus clientes, usuarios y mercados. Es común y mas aún para productos y servicios complejos, que las organizaciones se apoyen en proveedores para el desarrollo, mantenimiento y operación de los productos y servicios que ofrecen.
Uno de los primeros mitos que hay que corregir es considerar que con el uso de proveedores, de las actividades y procesos que realizarán los proveedores ya no tenemos responsabilidad alguna como organización adquiriente (quien contrata) y que finalmente el trabajo se reduce pues hay muchas cosas que ahora hace el proveedor. Si bien es cierto, en muchos contextos la participación del proveedor es buena, saludable, estratégica, recomendable y de beneficio mutuo, las dos conclusiones anteriores son falsas. Expliquemos porqué.
Primer argumento: “con el uso de proveedores, de las actividades y procesos que realizarán los proveedores ya no tenemos responsabilidad alguna como organización adquiriente (quien contrata)”. Falso. (i) El proveedor no puede tener absoluta libertad en cómo hace su trabajo, debe cumplir los estándares y restricciones que la organización adquiriente establecer y (ii) la organización adquiriente debe tener visibilidad oportuna y apropiada de los procesos del proveedor. Si bien es cierto, contratamos al proveedor por su expertise en ciertas actividades, el producto o servicio que el proveedor desarrolla finalmente será usado por la organización adquiriente y debe en algún pasar a formar parte de la operación de la organización adquiriente o deberá interactuar con otros procesos, servicios u operaciones de la organización adquiriente. Por tanto, la organización adquiriente no sólo debe establecer desde el inicio los requerimientos de los usuarios y requerimientos contractuales sino también durante la actuación del proveedor realizar revisiones de la solución técnica que el proveedor implementa, confirmar técnicamente el progreso del proveedor y que los requerimientos contractuales se satisfacen y finalmente asegurarse que las interfases o interacciones con otros procesos, operaciones y/o áreas de la organización se realiza (realizará) correctamente.
En cuanto a la visibilidad, esta no debe ser invasiva, debemos evaluar el aspecto costo beneficio y tiene como propósito identificar de manera temprana posibles problemas o riesgos de manera que los evitemos o resolvamos oportunamente.
Por ejemplo, si decidimos contratar a un proveedor para que nos desarrolle un aplicativo de software, no podemos dejar que él elija unilateralmente la tecnología a usar para el desarrollo, debemos asegurar la interoperabilidad del sistema que nos entregue con los sistemas que nuestra organización ya tiene.
Por ejemplo, si tenemos un proveedor que atiende a nuestros clientes, debemos tener visibilidad de cómo atiende las quejas o reclamos que nuestros clientes le hacen llegar, o cómo resuelve los problemas y defectos que el mismo proveedor identifica al proporcionarnos el servicio.
Segundo argumento: “finalmente el trabajo se reduce pues hay muchas cosas que ahora hace el proveedor”. Falso. Antes que el proveedor inicie sus actividades, durante la actuación del proveedor y al terminar la relación con el proveedor deben realizarse procesos nuevos, procesos que no son necesarios ejecutar si todo el trabajo lo hiciésemos nosotros (recursos propios), pero que son imprescindibles si trabajamos con los proveedores. Recordemos que el objetivo principal del proveedor es lograr  rentabilidad, lo cual es lícito y bueno, pues hace que sea eficiente y efectivo. Por otro lado el objetivo de la organización que contrata al proveedor, del proyecto o área que usa al proveedor es diferente, el objetivo es satisfacer los requerimientos de los usuarios y clientes. Debemos trabajar para alinear ambos objetivos. No podemos asumir que se alinearán automáticamente. De hecho si no trabajamos en ello, inevitablemente surgirán conflictos, pues son objetivos distintos. El uso de proveedores requiere que la organización adquiriente (quien contrata) implementa procesos “adicionales” o “nuevos”:

• Planear la adquisición, que incluye definir la estrategia de adquisición: objetivos de la adquisición, restricciones, recursos y tecnologías, método de adquisición, términos y condiciones, consideraciones de riesgo, soporte y alcance del proyecto entre otros.
• Solicitar, que incluye identificar posibles proveedores, preparar los requerimientos a enviar a los posibles proveedores para que entiendan el trabajo solicitado, esto incluye la captura, identificación, especificación, análisis y validación de los requerimientos de cliente y contractuales al nivel de detalle apropiado, definir el criterio para evaluar a los proveedores y sus propuestas
• Evaluación de los proveedores, de sus propuestas y selección del proveedor con la propuesta apropiada
• Seguimiento a las actividades y avance del proveedor
• Seguimiento (visibilidad) de los procesos críticos del proveedor
• Aceptación de los productos y servicios que proporciona el proveedor
• Transición de los productos y servicios que proporciona el proveedor

Esto tiene un impacto importante en la definición de los tiempos y esfuerzos requeridos. Necesitamos incorporar estas actividades en nuestro plan de actividades así como el esfuerzo que estas actividades demandará.

El CMMI for Acquisition contiene las buenas prácticas o características que deben tener los procesos de las organizaciones que tienen proveedores, de cualquier tipo. Estamos hablando de organizaciones en las que la intervención de proveedores es crítica en los distintos procesos organizacionales. Por ejemplo al contratar un outsourcing de servicios de tecnología.
Un tema adicional a incorporar aquí es qué debe hacer una organización adquiriente cuando nuestro proveedor nos dice: yo ya he implementado el CMMI for Development y soy una organización con un Nivel de Madurez “x”. Muchas veces frente a esto, la organización adquiriente no sabe qué hacer específicamente. Es correcto que esto genere una expectativa hacia la organización adquiriente, pero lo que está claro es que debe esperarse. Es un error asumir que esto es suficiente y no hay que hacer nada. De hecho, es un error. Recordemos que por más nivel de madurez que tenga nuestro proveedor su objetivo principal será siempre rentabilidad, lo cual está bien, es legítimo y es muy bueno, pues hace que sea eficiente y eficaz. Sin embargo, como organización adquiriente debemos trabajar para alinear el esfuerzo de mejora de procesos del proveedor con los objetivos que como organización adquiriente tenemos, en el proyecto o área que usará al proveedor. No podemos asumir que el proveedor lo hará.

CMMI for Services
Los servicios constituyen hoy en día más del 80% de la economía mundial. De hecho en nuestra vida diaria y en nuestras actividades profesionales, recibimos y proporcionamos muchos servicios y en muchos sectores ha aumentado considerablemente el uso y contratación de servicios.
Muchas organizaciones que producen y proporcionan servicios, usan CMMI y otros modelos, y están haciendo su propia interpretación al respecto, reinventando la rueda una y otra vez. El CMMI for Services contiene las buenas prácticas para desarrollar, mejorar y madurar el servicio que se proporciona al cliente, logrando un buen desempeño del servicio, aumentando la satisfacción del cliente y la rentabilidad. Para eso está diseñado el CMMI for Services.
Todas las prácticas del modelo CMMI for Services enfocan en las actividades de la organización que proporciona el servicio (service provider). El CMMI for Services usa como fuente los conceptos y prácticas de otros estándares y modelos orientados a servicios incluyendo el ITIL (            Information Technology Infrastructure Library), el ISO/IEC 20000: Information Technology – Service Management, el CobiT (Control Objects for Information and related Technology), el          Information Technology Services Capability Maturity Model® (ITSCMM) entre otros. No se requiere familiaridad con estos u otros estándares de servicios para comprender y usar el CMMI for Services, y el CMMI for Services no se ha estructurado con la intención de cumplir los requisitos de cualquier de los otros modelos o estándares de servicios mencionados.
El CMMI for Services abarca las actividades requeridas para establecer, entregar y gestionar servicios. En el contexto CMMI, un servicio es simplemente un producto intangible y que no puede almacenarse. El CMMI for Services se ha desarrollado de modo que es compatible con esta definición amplia y por tanto sus prácticas son potencialmente relevantes a cualquier organización que proporciona servicios, por ejemplo empresas en sectores tales como tecnología de información, salud, finanzas y transporte entre otros.
Antes de explicar el contenido del CMMI for Services, regresemos a aclarar con un poco más de detalle qué es un servicio en el contexto CMMI y otros conceptos básicos que suelen prestarse a confusión.

Servicio
Lo primero a resaltar es que un servicio es un tipo de producto. Muchas personas piensan rutinariamente que los productos y servicios son categorías mutuamente excluyentes. Sin embargo, en los modelos CMMI, productos y servicios no son categorías sin aspectos comunes, de hecho un servicio se considera una variedad especial de producto. Cualquier referencia a producto puede asumirse también como una referencia a un servicio. Si usted necesita referirse a una categoría de producto que no sea servicios puede usar la palabra bienes. Se suele utilizar la frase “bienes y servicios”.
Un segundo posible punto de confusión es entre servicios y procesos, especialmente porque ambos términos se refieren a entidades que son por naturaleza intangibles y no almacenables y porque ambos conceptos están intrínsecamente unidos. Sin embargo, en los modelos CMMI, los procesos son actividades, mientras que los servicios son el resultado, útil, de valor, de ejecutar dichas actividades. Por ejemplo, una organización que proporciona servicios de capacitación ejecuta procesos de capacitación (actividades) con la intención de dejar a los receptores de la capacitación en un estado de más conocimiento. El estado: “ser más conocedor” es el servicio que el proveedor de capacitación entrega o intenta entregar. Si los procesos de capacitación se ejecutan pero se falla en hacer que el receptor llegue a tener más conocimiento (quizás porque la capacitación está pobremente diseñada o porque los receptores de la capacitación no tienen algunos conocimientos previos necesarios), entonces el servicio – el resultado útil y de valor – realmente no se ha proporcionado. Los servicios son los resultados de los procesos, los servicios no son los procesos.
Una posible confusión que veremos finalmente en el significado de servicio aparece para aquellos quienes tienen un background (experiencia) en tecnología de información, especialmente aquellos familiarizados con disciplinas como SOA (Services Oriented Architecture) o Software as a Service (SaaS). En el contexto de software, los servicios se entienden usualmente como métodos, componentes o bloques de un sistema automatizado mayor, en vez del resultado producido por el sistema. En los modelos CMMI, un servicio es el resultado de valor intangible y no almacenable que se proporciona a través de la operación de un sistema de servicio, que puede o no contener componentes automatizados. Veamos que es un sistema de servicio (service system).

Sistema de servicio (service system)
Un servicio se proporciona a través de la operación de un sistema de servicio (service system), que se define como una combinación integrada e interdependiente de recursos componentes que satisfacen el servicio. El uso de la palabra sistema en “sistema de servicio” no implica necesariamente el uso de tecnología de información. Esta interpretación es muy restrictiva. De hecho es posible que un sistema de servicio no use tecnología de información, aunque esto es cada vez menos frecuente. Por ejemplo: un sistema de entrega de paquetes, un sistema de salud, un sistema educativo son ejemplos de sistemas de servicio con una amplia variedad de recursos componentes integrados e interdependientes.
Un sistema de servicio incluye todo lo necesario para entregar el servicio, por ejemplo, entregables intermedios, procesos, herramientas, infraestructura, materiales consumibles y recursos humanos. Algunos de estos recursos pueden pertenecer a los clientes o proveedores y algunos pueden ser transitorios (en el sentido que sólo son parte del sistema de servicio por un tiempo limitado). Todos estos recursos son parte del sistema de servicio si de alguna manera son necesarios para proporcionar el servicio.
Los proveedores de servicios que suelen no usar este enfoque de pensamiento en sus métodos, herramientas y personal para proporcionar servicios desde una perspectiva de sistemas pueden requerir invertir algún esfuerzo para reformular su concepto de entrega de servicio para adecuarse a esta perspectiva. Sin embargo, los beneficios de hacer esto son grandes porque los recursos críticos y aquellos no identificados y las dependencias entre recursos se hacen visibles. Esta visión le permite al proveedor de servicios organizar sus operaciones de manera efectiva evitando ser tomado por sorpresa o evitando el despilfarro de recursos al abordar de manera incompleta el problema.
El modelo CMMI for Services explica conceptos básicos adicionales como Requerimiento de Servicio (Service Request) y Incidente de Servicio (Service Incident) entre otros.
En resumen, ¿qué tipos de servicios cubre el CMMI for Services? La respuesta es por ejemplo servicios de tecnología de información, servicios de transporte, servicios financieros, servicios de salud o servicios de educación entre otros.
Los servicios se diferencian de otros tipos de productos en que son intangibles y no almacenables, por ejemplo, operaciones, mantenimiento, logística y tecnología de información.
Los servicios implican relaciones continuas gobernadas por acuerdos de servicio (service agreements). Los servicios se proporcionan o entregan a través de la operación de un sistema de servicio. Los servicios se producen y consumen simultáneamente. Y tienen un ritmo de negocios diferente. A diferencia de otros tipos de producto, en los servicios se suele invertir relativamente poco o menos tiempo en desarrollar el servicio y más tiempo en entregar el servicio.
El CMMI for Services contiene las buenas prácticas para mejorar los procesos necesarios para desarrollar, gestionar y proporcionar servicios. Estas buenas prácticas incluyen:

• La gestión estratégica del servicio (strategic service management), es decir, decidir cuáles servicios deberíamos proporcionar, estandarizarlos y hacer que las personas los conozcan.
• El desarrollo del sistema de servicio (service system, development), es decir, asegurarnos que tenemos todo lo necesario para proporcionar el servicio, incluyendo personas, procesos, materiales consumibles y equipamiento. Si el desarrollo del sistema de servicio no es una tarea trivial, debemos usar para esto el CMMI for Development.
• Transición del sistema de servicio (service system transition), es decir, lograr que el nuevo sistema esté en su lugar, cambiar sistemas existentes, retirar sistemas obsoletos y todo lo necesario para asegurar que no existan errores graves al proporcionar el servicio.
• Entrega del servicio (service delivery), es decir, establecer acuerdos, atender las solicitudes de servicio y operar el sistema de servicio.
• Gestión de la capacidad y disponibilidad (capacity and availabilty management), es decir, asegurar que tenemos los recursos necesarios para proporcionar el servicio y que están disponibles cuando se necesitan a un costo apropiado.
• Prevención y resolución de incidentes (incident resolution and prevention), es decir, manejar lo que suceda mal y en primer lugar prevenir errores si es posible.
• Gestión de la continuidad del servicio (service continuity management), es decir, estar listos para recuperarse de un desastre y retomar la entrega del servicio.

Veamos un ejemplo, aplicando estos conceptos a un servicio de salud, la gestión de capacidad y disponibilidad significa planear y monitorizar de manera regular para asegurar que están disponibles recursos suficientes tales como doctores, medicamentos, equipamiento de modo que sea posible proporcionar medicamentos, realizar atenciones y cuidados a un costo razonable. La continuidad del servicio significa que el equipo debe hacer un plan y ensayar cómo restaurar el servicio después de un desastre natural, pandemia o ataque terrorista. El desarrollo el sistema de servicio significa construir y/o habilitar la infraestructura tal como habitaciones, farmacias, laboratorios, equipo necesario para medir, entregar medicamentos y proporcionar atención y cuidado; incluye doctores, enfermeras, terapeutas y especialistas técnicos (personas); materiales consumibles tales como medicamentos, oxígeno; y procesos tales como diagnosticar, prescribir, preparar medicamentos, programar, planear, presupuestar y realizar el tratamiento, atenciones y cuidado. En cuanto a la transición del sistema de servicio suponga que se emite una ley en la que las enfermeras ya no pueden suministrar ciertos medicamentos excepto en la presencia de un farmacéutico. Las prácticas de transición del sistema de servicio deben invocarse para realizar los cambios requeridos en las personas y procesos de modo que se cumpla con la ley y se continúe proporcionando el servicio de salud. La entrega del servicio significa preparar un calendario de citas para los doctores, para prepara y entregar los medicamentos, monitorizar la provisión de medicamentos, comprar materiales, gestionar solicitudes, hacer seguimiento a la satisfacción del cliente, dar mantenimiento a la infraestructura, entre otros. Para estos servicios, debe haber una solicitud de servicio por ejemplo la prescripción de una receta, la solicitud de consulta o atención de un doctor o la llegada de un niño con asfixia a emergencias. Prevención y resolución de incidencias significa atender incidentes, ejemplo de un incidente puede ser cuando se prescribe un medicamento en la dosis incorrecta o cuando un equipo médico falla cuando se le necesita al atender la emergencia de un paciente con un ataque de asma. La gestión estratégica del servicio significa establecer un rango de servicios estándares para satisfacer las necesidades de los clientes y analizar periódicamente datos estratégicos de mercados y clientes para actualizar estos servicios de modo que satisfagan dichas necesidades. Los servicios estándares pueden incluir acuerdos de niveles de servicio que pueden especificar por ejemplo, tiempos de respuesta para tratamientos de emergencia y para la entrega de medicamentos.

Conclusión
Consideramos imprescindible hoy en día que los profesionales, no sólo de tecnología de información sino también de otras industrias y sobre todo los ejecutivos, gerentes y directores de organizaciones, conozcan de procesos, de mejora de procesos y de cómo la suite de productos CMMI puede ayudarlos a que sus organizaciones proporcionen productos y servicios de calidad. Les recomendamos llevar una capacitación en CMMI, que al día de hoy incluye no sólo CMMI para Desarrollo sino también CMMI para Adquisiciones y CMMI para Servicios.
La suite de productos CMMI contiene abundante información que trae beneficios a las organizaciones. Pero debemos capacitarnos. La información allí contenida debe usarse inteligentemente. Muchas veces escuchamos decir, pero el CMMI pide muchos requisitos y mucha documentación, por eso, no sirve. Este argumento, es similar al siguiente comentario: un buen bisteck o un buen plato de comida (sano, nutritivo y balanceado) no sirve para nada, inclusive es dañino, porque mi bebé de 4 meses no lo puede comer, le haría mucho daño. Que les puedo decir, necesitamos un poco de sentido común para entender que a un bebé de 4 meses no se le da como alimento un buen bisteck o un buen plato de comida. Lo mismo pasa con el CMMI, quien dice es mucho, quiere comerse un elefante de un solo bocado, no sólo no debe hacerlo sino puede morir en el intento. No todos quieren tener desempeños internacionalmente competitivos (esto requiere otro tipo de discusión, no?).
Alertamos a nuestra comunidad de servicios de capacitación y asesoría en CMMI que son proporcionados por personas u organizaciones, usualmente bien intencionadas, pero que infringen derechos de propiedad intelectual, derechos de marcas registradas y que generan mas confusión que aclaración a quienes reciben esa información pues son están capacitadas ni acreditadas para proporcionar dicho servicio. Pondré un ejemplo para aclarar esto mejor. Imagine usted que conoce un amigo que ha sido recientemente operado de apendicitis. Entonces luego de pasar esta experiencia, este amigo se entera que su hijo tiene apendicitis y requiere una operación, entonces se le acerca y le dice, pero oye te cuento que a mi ya me ha pasado esto, yo puedo ayudarte, yo puedo operar a tu hijo, aquí tengo las recetas y análisis que me hicieron, tengo anotado todo lo que el doctor me dijo, pregunté bastante y me ha quedado muy claro lo que hay que hacer, hasta he filmado la operación y puedo hacerlo! ¿Dejaría usted que su amigo opere a su hijo? La respuesta es evidente. Ninguno de nosotros lo haríamos, es más, estoy seguro que su amigo tampoco lo haría con su hijo! De hecho primero hay que estudiar para ser doctor, luego hay que rendir exámenes y seguir residencias, finalmente hay que tener experiencia, recibir autorización y estar permanentemente actualizado para realizar operaciones. También debemos anotar que no todos los pacientes son iguales y no todas las apendicitis son exactamente iguales, de hecho hay similitudes tanto entre pacientes como en las enfermedades, pero no siempre situaciones idénticas, solamente el profesional capacitado y experimentado puede reconocer y resolver esto.
Lo mismo sucede con la capacitación, asesoría y evaluaciones CMMI. Se requiere que quien proporcione dichos servicios, haya recibido la capacitación requerida, tenga la acreditación requerida y tenga la experiencia apropiada.
Si usted está interesado en acceder información del CMMI directamente de los propietarios del modelo consulte la página web del SEI norteamericano en http://www.sei.cmu.edu/cmmi. Si usted desea tener información acerca de capacitación, consultoría y evaluaciones CMMI en Perú puede consultar nuestra página web www.processconsulting.net o puede enviar cualquier consulta a david.arteaga@processconsulting.net
Queremos invitarlos a los siguientes cursos organizados por Process Consulting a realizarse en la ciudad de Lima en las siguientes fechas:

Estos cursos se dictan no sólo en el contexto del CMMI for Development sino también en el del CMMI for Acquisition y CMMI for Services. Process Consulting y su equipo de instructores tiene las acreditaciones requeridas para proporcionar las capacitaciones y la experiencia de haber proporcionado servicios de capacitación, asesoría y evaluación a más de 1,000 personas y más de 120 organizaciones en más de 10 países.
Si desea más información puede llamar al 349-0104.

(1) Esta premisa está basada en Basado en los principios de TQM (Total Quality Management, Gestión de la Calidad Total) de Shewhart, Juran, Deming y Humphrey.
® CMMI, Capability Maturity Model y CMM están registradas en la Oficina de Marcas y Patentes de los Estados Unidos por la Universidad Carnegie Mellon