La última entrega de mi serie sobre el CMMI SVC. Como en la anterior, me enfoco en una de las dos áreas de gestión de trabajo que son exclusivas del modelo SVC, en este caso continuidad de servicios (SCON)

1. El CMMI de Servicios Está Aquí (cont. 5)
Y porqué esto le tiene que importar.
Jorge Boria, Liveware
Quinta parte: Sobrevivir a la Catástrofe
Finalmente nos ocuparemos ahora del área de procesos que contiene las prácticas que permiten
planificar y realizar las actividades de sobrevivir a una catástrofe. Para comenzar, definamos algunas de
las palabras clave que se usan en el modelo de servicios: incidente, riesgo, problema y catástrofe. Las
definiciones acá presentadas son mi traducción e interpretación de las que contiene el glosario del
modelo CMMI-SVC o, cuando la definición no está en el glosario (como es el caso de ‘riesgo’), extraída
del material informativo en el mismo. Las definiciones ofrecidas surgen de las implementaciones
razonables de las prácticas del modelo. Por ejemplo, Work Management se ocupa de problemas,
mientras que Incident Resolution se ocupa de incidentes. Si definimos los incidentes como problemas no
es claro cómo tratarlos.
Incidente: En el glosario se encuentra “incidente de servicio”, con la indicación de que se puede reducir
a “incidente” si el contexto hace que el significado sea inequívoco. Se lo define como una indicación de
una interferencia actual o potencial con la prestación de un servicio. Ejemplos son la falta de un
ingrediente para un plato en un restaurante (potencial), o la demora en entregar un plato que hace que
le llegue frío al cliente (actual). Compararemos esta definición con la definición de problema y riesgo
más adelante.
Incidente

2. Problema: Una situación actual que interfiere con las prestaciones normales. Los incidentes que
mencionamos como ejemplo derivan de problemas del sistema. Generalmente se habla de problema
cuando se identifica una situación que reduce las prestaciones del sistema, y de incidente cuando se
refiere a la afectación del servicio. No siempre un problema se traduce en un incidente, por ejemplo
cuando hay redundancia en el sistema. Si el restaurante tiene dos cámaras frigoríficas la caída de una
(problema) puede no registrarse como incidente porque la otra permite continuar con las prestaciones
normales del servicio. Compararemos esta definición contra la definición de riesgo enseguida.
Problema
Riesgo: No hay una definición en el modelo, pero la definición “oficial” la tomo del material del curso
Introduction to the CMMI. Ahí los riesgos se los identifica como problemas potenciales que puedan
surgir que interfieran con el funcionamiento normal del sistema. Siguiendo los ejemplos anteriores, la
caída de la primera cámara frigorífica es un problema que genera un riesgo, el de que se caiga la
segunda cámara frigorífica con consecuencias graves. El problema es siempre actual, el riesgo es
siempre potencial. El incidente no es un riesgo, es un evento actual. Los incidentes surgen de problemas
en el sistema. Un riesgo no origina incidentes, salvo que se materialice, es decir, que deje de ser riesgo y
se convierta en problema.
Riesgo

3. Catástrofe: Un problema que tiene volumen suficiente para afectar gran parte del sistema y afectar la
prestación de servicios con potencial de cerrarla totalmente. La diferencia entre un problema y una
catástrofe es que el primero es frecuente y no impide la prestación total de los servicios, mientras que la
segunda lo hace casi imposible. Toda catástrofe es un problema, pero no todo problema es una
catástrofe. Los riesgos se pueden transformar en problemas y, ocasionalmente, en catástrofes.
Catástrofe
La principal diferencia entre incidente, problema y catástrofe está en la frecuencia de ocurrencia y el
tratamiento que se hace de cada uno. Se espera que haya incidentes con cierta frecuencia y, si son
demasiados o muy concentrados, se espera que se opere sobre el sistema para prevenirlos en el futuro.
(el área de procesos de Incident Resolution and Prevention se ocupa de esto, con la creación y análisis
de “workarounds” cuando apliquen).
Workaround
En general se espera que la recuperación de un incidente no sea muy cara ni demorada. Un problema se
manifiesta en el sistema, pudiendo provocar incidentes, o serlo en sí, pero arreglar el problema implica

4. un plan de acción. Un problema puede ser muy grande y afectar muchísimas componentes, hasta
dificultar el funcionamiento normal del sistema. Por ejemplo, en una isla aislada del continente, la
explosión del generador de energía eléctrica es un problema catastrófico, arrastrando al sistema
completo en su caída.
Un riesgo es un problema en potencia y se lo trata con diferentes herramientas. El área de proceso Risk
Management se ocupa de describir las prácticas que se aplican para identificar, clasificar y administrar
los riesgos. Un riesgo de catástrofe merece un tratamiento especial. Este es el tema que aborda el área
que nos ocupa.
Service Continuity (SCON) (Continuidad del Servicio)
Como antes con CAM, el propósito de esta área de procesos se desprende de su nombre, es establecer y
utilizar planes para asegurar la continuidad de los servicios durante y después de una disrupción
significativa de las operaciones normales. Puesto que se trata de planificar con antelación en prevención
de lo que pueda ocurrir, los paralelos con el área de proceso de gestión de riesgos son evidentes. La
implementación de las prácticas de gestión de riesgos ayuda, pero no completa las necesidades que
cubre SCON. Estas son una especialización de aquellas, pero para situaciones muy especiales,
catastróficas. Las prácticas de SCON son indispensables para identificar estos riesgos altísimos por su
impacto y realizar el tratamiento correspondiente. Estas son la prácticas específicas de SCON dentro de
sus objetivos específicos:
SG 1 Identificar Dependencias Esenciales de Servicio
SP 1.1 Identificar y Priorizar Funciones Esenciales
SP 1.2 Identificar y Priorizar Recursos Esenciales
SG 2 Prepararse para la Continuidad del Servicio
SP 2.1 Establecer Planes de Continuidad del Servicio
SP 2.2 Establecer Capacitación en Continuidad del Servicio
SP 2.3 Proveer y Evaluar Capacitación en Continuidad del Servicio
SG 3 Verificar y Validar Planes de Continuidad del Servicio
SP 3.1 Prepararse para la Verificación y Validación de los Planes de Continuidad del Servicio
SP 3.2 Verificar y Validar Planes de Continuidad del Servicio
SP 3.3 Analizar los Resultados de la Verificación y Validación de los Planes de Continuidad del Servicio
Lo primero es lo primero. ¿Cuáles son las funciones esenciales de los servicios que brindamos? Tuve
oportunidad de ver este análisis (y algunas de las prácticas que siguen) materializadas en un viaje que
realicé a Monterrey cuando la asoló un huracán. El hotel en que paraba no contaba con restaurantes,

5. pero compensaba el que estaba en una plaza donde había varios. Todo estaba bien hasta que el huracán
(quiero creer que me acuerdo de su nombre, y que era Kathryna) asoló la región, provocando
inundaciones y caídas de puentes. La ciudad se paralizó. Un colega con una 4x4 me acercó al hotel
después de una odisea a través de calles anegadas, pero una vez en el hotel me asaltó la duda: ¿Podría
encontrar un restaurante abierto para la cena? Con pocas esperanzas dejé la seguridad de mi habitación
para caminar hasta el sector de restaurantes, a unos cien metros bajo la lluvia. De todos los restaurantes
el único abierto era Aplebee’s. Menciono a la cadena por su nombre porque merece ser reconocida. Al
entrar nos recibió el gerente, disculpándose por las molestias que deberíamos sufrir porque el lugar
estaba parcialmente inundado y la falta de personal, lo que restringiría fuertemente nuestra posibilidad
de elección. De más está decir, en vez de molestos estábamos muy agradecidos. El gerente había
comprendido que su función era dar un servicio de comidas a viajeros que de otra manera hubiéramos
cenado galletas secas en nuestros cuartos, y actuado en consecuencia. El servicio esencial de su
restaurante era alimentar a los hambrientos. Lo demás, servicios de mesa, postres, o variedad en la
oferta, eran superfluos bajo las circunstancias.
Independientemente de la realización de este ejercicio mental para identificar los servicios
fundamentales, toda organización debería conocer cuáles son los servicios esenciales que presta para
poder mejorar sus prestaciones. Una vez conocidos los servicios esenciales identificar cómo se
relacionan con las componentes del modelo es indispensable para comprender donde invertir para
mejorar la capacidad y la posibilidad de seguir brindando el servicio en circunstancias excepcionales. En
el caso de mi ejemplo en Monterrey, son pocas las componentes del sistema que son indispensables
bajo la definición de servicios esenciales. Podemos proceder sin hornos ni anafes si servimos ensalada.
Podemos no tener refrigeración si los ingredientes sobreviven sin ellos (por ejemplo, el arroz o las
zanahorias). Podemos prescindir de la luz eléctrica si contamos con un sistema de iluminación
alternativa (velas, lámparas de kerosene o a pilas). Podemos no tener mesas si hay un mostrador donde
se pueda poner la comida. Pero si el restaurante completo hubiera estado sumergido bajo el agua no
podría haber ofrecido ningún servicio. ¿O sí? Dejamos al lector el ejercicio de listar categorías de servicio
(piensen en las categorías de los menú en los restaurante, por ejemplo sopas, carnes, bebidas, postres,
ensaladas) y asociar en una segunda columna los elementos que son indispensables para ofrecer el
servicio correspondiente. Con gusto compartiremos los resultados en el grupo de LinkedIn de CMMI
para Servicios y el de Mejora de Procesos.
Una vez que sabemos qué es lo esencial debemos imaginar cómo continuar brindando los servicios,
todos o algunos, completos o en parte. En la disciplina de la cuál provengo (Sistemas Operativos de
Software) se habla de “degradación ágil”. El sistema brinda tantos servicios como puede. En la medida
que sus componentes dejan de funcionar los servicios dependientes de estos dejan de ser ofrecidos. El
plan no es un plan en el sentido PMI BoK, con tareas asignadas en el tiempo, sino que es un plan de
contingencias, con la excepción del plan de capacitación que permita operar los planes de contingencia.
Los planes de contingencia se “disparan” según las situaciones. El plan de capacitación debe permitir
reconocer las situaciones de emergencia y enseñar a aplicar las acciones para darle continuidad a los
servicios. En situaciones extremas es posible que haya que realizar acciones de recuperación, como ser
escurrir el agua del piso y secar los conectores antes de volver a conectar la energía eléctrica a la red. El

6. plan de capacitación debe ser llevado a cabo y las acciones derivadas ensayadas para garantizar que las
operaciones darán el resultado esperado. Si se cuenta con una representación del sistema como
resultado de haber implementado las prácticas del modelo se puede utilizar este con provecho para
correr simulaciones en las que las distintas componentes van siendo sacadas de servicio.
Conclusiones
El plan de continuidad es un buen ejemplo de disponibilidad. A medida que van saliendo de servicio
componentes las funcionalidades correspondientes dejan de ser ofrecidas. El sistema se degrada, pero
no de manera terminal. Los restaurantes que cerraron en el huracán me perdieron como cliente, pese a
que prefería su cocina, porque le di preferencia a aquel que me entendía como mi proveedor. En
consecuencia, la degradación de servicios, cuando es la mejor solución en una mala situación, es una
buena manera de ganar la fidelidad del cliente.
Acerca de Liveware Inc.
Liveware Inc. es un miembro destacado de la comunidad de afiliadas del CMMI Institute, especializada
en ayudar a empresas de todos los tamaños y mercados a mejorar su productividad. Con experiencia en
todos los niveles de madurez, entre sus clientes más destacados se encuentra la empresa que desarrolló
el software para el trasbordador espacial, United Space Alliance. En conjunto, Liveware Inc. ha realizado
más de cincuenta SCAMPI en siete países y en cuatro idiomas, así como ha dictado más de ochenta
cursos oficiales del SEI sobre el CMMI, tanto de desarrollo como de servicios.
Si bien Liveware Inc. tiene los mismos fundadores que Liveware ISSA de Argentina, sus caminos se han
separado y ya no se representan una a la otra. El representante de Liveware Inc. en Sud América es
ESCAMPI S.A.
Acerca del Autor
Jorge Boria es Certified CMMI Instructor del CMMI Institute para los cursos Intro DEV y SVC, los
suplementos de un día de DEV y SVC, y CMMI for Practitioners ML2 y ML3 . Es asimismo Certified High
Maturity SCAMPI Lead Appraiser del CMMI Institute. Fue durante seis años Certified Scrum Master de la
Agile Alliance. Desde 2004 al 2012 fue SEI Visiting Scientist y desde el 2008 Senior Advisor del MPS-Br
(Modelo de Procesos de Software Brasileño). Sus credenciales docentes son extensas. Algunos
comentarios sobre su capacidad docente expresan esto de manera contundente:
“Tomaría cualquier curso que dicte [Jorge Boria]” Austin, TX, 2011
“Jorge es el epítome del docente, sus cursos son claros y precisos” Omaha, NE, 2001
“Excelente tu webinar, […], pero ya me tienes acostumbrado a [tu] nivel” Monterrey, MX, 2013
“Como en otros contextos y sobre otros contenidos, sigo admirando tu capacidad de describir de manera simple lo que otros
prefieren mantener difícil.” Córdoba, Argentina, 2012.