Usando la CMDB en conjunto por toda la empresa

Contenido

Hace algún tiempo que se leen comentarios como que ITIL está muerto o ya no es válido. Desde TecnoEstrategia pensamos que la filosofía es siempre aprovechar el conocimiento, el sentido común y quedarnos con lo que nos interesa para poder “mapear” lo que existe y crear algo que sea útil para cada uno de nuestros clientes.

En este caso retomamos un ejemplo que se realizó en un cliente y que después hemos extendido (con las lógicas modificaciones, pero en esencia la idea es la misma) a otros, se trata de generar una CMDB particular, peculiar y desde un punto de vista diferente.

Una CMDB se podría traducir como una base de datos de configuración, o en otras palabras un modelo donde se encuentran todos los elementos de un departamento de IT (servicios, hardware, proveedores, documentación, BD de bugs, sistemas de soporte, procedimientos, protocolos, etcétera).

Bueno, pues nosotros pensamos que en la mayoría de empresas que se dedican al software (entendido como un producto/servicio ofertado a un cliente final) no van a poder implementar cosas como las que se describen aquí -> http://www.bmc.com/experts/reference-books/cmdb-books/cmdb-step-by-step.html no por capacidad, sino porque tal vez el esfuerzo no les compensa en el momento de hacerlo (esto es un detalle muy importante).

En líneas generales se acaban usando las CMDB como grandes (o pequeñas) bases de conocimiento dentro de las empresas, aunque distinguimos entre empresas de mantenimiento informático sin ser factory software y las que SÍ se dedican a desarrollar o dar servicios sobre él. Lo que vamos a comentar se refiere a este ultimo caso: una empresa que posee software propio y/o de terceros pero que ofrece el soporte final (al cliente y usuario último) sobre este.

Al lío, la propuesta que hemos implementado parte de tres grandes pilares:

– Formación multidisciplinar de todos los usuarios de la CMBD (comercial, desarrollo, soporte, testing, etcétera)
– Estructura limpia, o al menos ordenada del código, que “se vende” o sobre el que se da soporte.
– Clasificación más o menos clara, organizada y estructurada del feedback e interacciones, tanto internas como externas.

Trabajando cada pilar como algo fundamental, el objetivo buscado es plantear una visión concreta de los problemas y/o “gaps” de toda la organización y en ambas direcciones; Interno externo, esto se consigue de la siguiente manera:

– Se tienen identificadas las funcionalidades de la aplicación por todas las personas de la empresa.

Es imprescindible que aunque no se toque código o no se visiten a clientes (cosa con la que podemos discrepar pero eso da para otro debate) por la importancia en tu trabajo dentro de la organización sepas perfectamente qué hace y por qué lo hace la aplicación/es sobre las que trabajas. Esto que puede parecer una perogrullada, creernos, no lo es.

Si disponemos de ese conocimiento dentro de la empresa ya tendremos algo que es realmente complicado, pero a nuestro parecer a veces vale la pena invertir (siempre entendido como algo global) en formación “interna” y no tanto en tendencias. Pensamos que esto último se hace mejor mediante un modelo madurativo/formativo individual.

– Toda la organización conoce la forma de trabajo de los demás miembros.

A priori que un comercial y un tester conozcan sus trabajos de manera reciproca puede sonar hasta incongruente, pero es importante saber, con detalle a nivel funcional, qué hace otra persona que forma parte y te influye en tu trabajo. Ojo que entendemos que un comercial (si lo sabe, mejor) no debería invertir mucho tiempo en analizar los detalle técnicos sobre mocks y stubs y,a su vez un tester tampoco en los modelos de prospección (ídem, si lo conoce mejor).

El asunto está en que si conoces los procesos, motivaciones, dificultades, etcétera de las otras personas que forman parte de tu propio trabajo conocerás mejor en que te afectan y como puedes complementar/ayudar para que el resultado final obtenga mejores resultados.

De esta manera tanto comerciales, como testers, personal técnico de soporte , desarrolladores, analistas de UX, diseñadores, etcétera conocen por qué es importe y de qué manera influyen en el producto/servicio final que percibe el cliente basándose en el trabajo externo y en el propio.

– Se dispone de un modelo de código “maduro”

La idea es que al menos podemos identificar controles, clases, funciones, etcétera y versiones/revisiones. Lo ideal es un escenario donde una gestión de la configuración está bien implementada junto con un modelo de control de versiones y métricas de calidad, además de centrarse en un modelo de análisis documentado (pudiendo ser historias de usuario o cualquier otro sistema, no se trata de marcar requisitos con un cliente, sino de tener claro por qué se ha implementado X funcionalidad o X forma de trabajo).

Una vez esto se comprende y se usa la capacidad de cruzar datos y obtener “fotos” para una toma de decisiones correcta, por tanto; se pasa de “apagar fuegos” a crecer hacia un modelo cualitativo donde el aumento de productividad, eficiencia y eficacia sea hacen tangibles, el ejemplo de uso mediante una CMDB unificada y usada por todos es sencillo de representar en diferentes supuestos, por ejemplo:

Un comercial aporta una venta fallida por una funcionalidad donde la competencia tiene una mejor aceptación, para ese cliente esa funcionalidad es clave.

Si conocemos los esfuerzos de toda la organización en esa funcionalidad podremos tomar decisiones correctas, pero claro esto incluye desde las clases, herencias, etcétera que dependen de dicha funcionalidad, como el esfuerzo en hacer (por ejemplo) un refactoring, o el número de incidencias abiertas desde soporte en algo relacionado y por supuesto reportando el feedback de los clientes y las objeciones que se encuentra un comercial, o un consultor en el momento de implementación de la herramienta, motivaciones de venta/compra, etcétera.

Creciendo en este modelo se puede llegar a identificar incluso el evento de un control que reporta porcentajes concretos de quejas, influencia en ventas perdidas, retrabajo a los desarrolladores, número de tests fallados, dificultades  y un número importante de variables que nos proporcionara una visión muy buena de la realidad, y no únicamente de un modelo de soporte, o de desarrollo o de ventas, sino de una percepción general interna y externa de los puntos claves de nuestro producto/servicio.

Esto no solo se debe enfocar desde un punto de vista de los errores-problemas-defectos, sino también de que nos resulta más productivo, y una vez más hacemos foco en la globalidad de esta información, esa productividad o eficiencia la podemos ver en horas de desarrollo, en facilidad de ventas, en calidad del soporte y fidelización de clientes y por supuesto: en generar un ambiente laboral (tanto interno como externo) que se sienta como útil y donde vale la pena hacer esfuerzos ya que al final hay recompensa.

La idea de usar una CMDB común parte de estas premisas, en el siguiente diagrama se puede apreciar la idea expuesta siguiendo un modelo de soporte técnico que enlaza con un repositorio de código, un modelo de proyecto similar a Redmine / BaseCamp y con parte de un CRM.