El CMMI de Servicios Está Aquí (cont. 5)
Y porqué esto le tiene que importar.
Jorge Boria, Liveware

Quinta parte: Sobrevi...
Problema: Una situación actual que interfiere con las prestaciones normales. Los incidentes que
mencionamos como ejemplo d...
Catástrofe: Un problema que tiene volumen suficiente para afectar gran parte del sistema y afectar la
prestación de servic...
un plan de acción. Un problema puede ser muy grande y afectar muchísimas componentes, hasta
dificultar el funcionamiento n...
pero compensaba el que estaba en una plaza donde había varios. Todo estaba bien hasta que el huracán
(quiero creer que me ...
plan de capacitación debe ser llevado a cabo y las acciones derivadas ensayadas para garantizar que las
operaciones darán ...
Próxima SlideShare
Cargando en…5
×

El cmmi de servicios está aquí 5

620 visualizaciones

Publicado el

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)

Publicado en: Empresariales
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
620
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
26
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

El cmmi de servicios está aquí 5

  1. 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. 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. 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. 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. 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. 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.

×