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

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

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

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,

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

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.