Entrega de valor de un servicio

(repost) Originalmente Publicado el 23 marzo, 2014

Cuando se trabaja en la definición de un servicio, un punto importante es identificar como aporta valor al negocio.
Conversando con un colega, descubrimos que teníamos una visión bastante diferente del concepto, no por un error de interpretación de los modelos o estándares, léase ISO 20000, ITIL o CMMI-SVC, sino por el contexto de la organización proveedora de servicios respecto a la organización receptora de los mismos.
Planteemos 2 escenarios:

  • Caso 1. La organización proveedora de servicios es interna. Por ej., un área de IT de una empresa X, donde X es una constructora, una oficina gubernamental, un hospital, etc.

  • Caso 2. La organización proveedora es externa. Es decir, puede tener uno o más clientes, que consumen sus servicios. Por ejemplo una empresa de soluciones de IT, que vende servicios de tecnología a la constructora, la oficina de gobierno, el hospital.

En el caso 1, el valor que el servicio aporta al negocio es más directo de identificar, ya que el conocimiento del dominio y el plan de negocios de la organización brindan el marco.
En el caso 2, también tenemos que buscar el valor al negocio de nuestro cliente que estamos aportando. Puede que no tengamos tantas herramientas como si fuese un área interna, pero el objetivo del servicio sigue siendo proveer valor al negocio de quien recibe el servicio.
La gran diferencia en nuestro caso, es que el mismo servicio tendrá diferente valor según cada dominio de cliente, y aun dentro de cada dominio, por cada cliente diferente.
¿Pero debemos quedarnos ahí? ¿Viendo al servicio como algo compartimentado, sin tener en cuenta el valor que entrega a nuestro negocio, como proveedor de soluciones tecnológicas? Creo que no, que debemos definir un marco de valor de negocio interno, donde tal vez tengamos en cuenta la importancia del cliente para nosotros, o del servicio si queremos posicionarnos como proveedores world class, etc., y a todo esto sumarle el valor que le estamos dando al negocio de nuestro propio cliente.
Obviamente, esto nos suma complejidad a la hora de definir el servicio, pero eso es lo que diferenciará la organización seria de las mediocres.

Un error común al interpretar SSD

(repost) Originalmente Publicado el 6 marzo, 2014

El área de procesos SSD (Service System Development) tiene un paralelismo importante con las áreas de ingeniería del modelo CMMI for Development. Esto es porque quienes  definieron el modelo de servicios entendieron que definir un servicio desde cero, puede verse, en cierto sentido, de forma análoga al desarrollo de un software.
El servicio tiene que pasar por una fase de captura y análisis de requisitos, donde se identifica el alcance y las necesidades que vendrá a cubrir este nuevo servicio, luego por una fase de diseño, construcción, verificación…esto es, probar que el servicio cumple con sus requisitos y finalmente, validar que es el servicio cumple las expectativas del cliente, o recibe el valor que esperaba del mismo.
Si aplicamos el modelo a una organización que brinda servicios no IT, SSD no presenta inconvenientes en su interpretación. ¿O sí?
Pero si vamos a las organizaciones que proveen servicios relacionados con software, comienzan las confusiones y conflictos.
Por eso, siempre hay que volver al comienzo: la definición del servicio, y de sus requisitos.
Si brindamos servicios de AM, o mantenimiento de una aplicación X, podríamos simplificar un escenario diciendo que, independientemente del cliente, los requisitos del servicio son los mismos: se necesitan recursos de infraestructura, personas con ciertos skills y los parámetros de capacidad, disponibilidad y continuidad ofrecidos/acordados. Esos son los requisitos de mi servicio AM para la aplicación X.
Si lo vemos con el enfoque de desarrollo de software, los requisitos serían todos los pedidos de corregir, ampliar o cambiar una porción de código de la aplicación X… en cambio, para el servicio, estas son peticiones de servicio.
¿Se entiende por qué lo que es un requisito desde el modelo de desarrollo (CMMI-DEV), no es requisito para servicios (CMMI-SVC)?