Desde que comencé a trabajar con los conceptos de Gestión de Servicios, haciendo mis primeros pinitos en la implantación de herramientas de OpenView, siempre he usado el correo como el primer ejemplo del concepto de Servicio.
Así, el correo electrónico es más que el servidor, más que el sendmail que corre sobre él y más que las líneas de comunicaciones, sino que es el concepto agregado de todo ello.
Pero siendo como es el más extendido de todos los servicios, el más usado como ejemplo y el primero en ser documentado desde todos los puntos de vista que exige una correcta gestión de servicios (desde el SLA hasta la monitorización pasando por el soporte presencial o la capacidad), es curioso que no hayamos llegado a un acuerdo sobre cómo se debe plantar el simple y vulgar correo en un catálogo de servicios.
Y es precisamente el hecho de que no esté estandarizado (aunque sea de facto) el correo ni ningún otro de los servicios más comunes (impresión, archivos compartidos, navegación Internet, telefonía...) lo que me demuestra esta increíble complejidad que se oculta tras el (simple) concepto de Catálogo de Servicios.
Cuando miras el servicio de correo desde el punto de vista del usuario, ves un buzón con algunas funcionalidades adicionales como puede ser antivirus, antispam, quota de buzon, etc.
Cuando lo miras desde el punto de vista de la operación, ves servidores, líneas, software...
Cuando lo miras desde el punto de vista del ServiceDesk, ves las incidencias y los diferentes tipos de peticiones que se pueden realizar sobre el correo: backup y restauración del buzón, reseteo de la contraseña, movimiento del buzón, etc.
Y cuando, además modernizas el servicio, resulta que te encuentras con que a ese mismo buzón el usuario accede desde un cliente pesado por MAPI, desde un cliente ligero por OWA, desde otro sistema por IMAP4 y desde una blackberry.
¿Es el mismo servicio el correo accedido desde un cliente pesado que desde una blackberry? Quizás desde el punto de vista del usuario sea lo mismo o muy similar, pero desde el punto de vista de la Gestión de la Disponibilidad no es lo mismo medir la disponibilidad del buzón (backend) que la disponibilidad del acceso Blackberry (con sus frontends y la disponibilidad de la red GPRS).
Y así podríamos seguir encontrando toneladas de pequeñas diferencias y matices que hacen que una cosa sea distinta de la otra... Así que, o llegas a un acuerdo y dejas de buscarle las cinco patas al gato, o te has tirado meses sólo discutiendo sobre el correo y aún te faltan 30 servicios más por documentar!
¿Y todo esto por qué pasa? Pues en mi humilde opinión porque ITIL define un concepto único que es el catálogo de servicios como piedra angular de la Gestión de Servicios (evidentemente, si quieres gestionar servicios necesitas saber a qué servicios te refieres, ¿No?) cuando en realidad hay que pensar en un concepto de catálogo multidisciplinar y que permita diferentes puntos de vista, a la vez que te debe permitir canalizar el diálogo con todas las partes implicadas... y eso es extremadamente difícil de lograr.
Lo fácil es tener una lista de servicios, quizás enriquecida con algunos atributos que te permitan describir de una u otra manera estos servicios, y luego tener diferentes "ampliaciones" de estos conceptos.
Así, puedes tener lo que yo llamo "carta de servicios", que es la representación del catálogo especialmente orientada a clientes, indicando qué pueden pedir o esperar de IT; o puedes tener un catálogo interno de servicios, con la arquitectura tecnológica y los conceptos de medición para el área de operaciones/explotación; y así los diferentes "sabores" de catálogo que te permitan gestionar cada una de las facetas de los diferentes servicios.
Y entonces llegan Charlie Betz y Rob England y siembran la duda cuando ya pensabas que lo tenías claro, aquí y aquí.
Tienes opiniones al respecto? Cómo es el correo en tu catálogo de servicios? Qué haces con los diferentes canales de acceso?
Aquí podríamos estar hablando durante horas, así que no dejes de añadir tu granito de arena, porque tu catálogo ¿es un catálogo de productos, de servicios TIC, de peticiones, de servicios profesionales o de buenas intenciones?
9 comentarios:
Interesante reflexión ! ...
Así a bote pronto se me ocurre: Definamos los diferentes canales de acceso a la información proporcionada por los servicios TI, como un servicio en si mismo, común y utilizable o dependiente del resto de servicios TI que lo requieran y ajustando diferentes SLA's para cada relación "Servicio Correo" <-> "Servicio Acceso 1", "Servicio Acceso 2", ... y a su vez hay que tener en cuenta que el servicio de "Acceso 1" en el caso de una PDA por ejemplo, puede ser utilizado también para pasar los pedidos o consultar los stocks de la compañía, por tanto podemos deducir, que un servicio TI (correo) podrá depender de (n) servicios de Acceso, con diferentes acuerdos para cada relación, y por tanto el servicio de Acceso, apoya a diferentes servicios TI, (Correo, Pedidos, Stock).
A bote pronto parece que si, que puede ayudar a concretar y "simplificar" (entre comillas) la definición del catalogo, ... o no !
Efectivamente, así es como yo lo estoy haciendo en la actualidad: diferentes canales implican diferentes servicios... pero eso hace que sea necesario explicar una y otra vez la diferencia entre un servicio y otro a personas "no techies" y por lo tanto no vean tan clara la necesidad de la diferenciación por canales.
Gracias!
Antonio
Haré de abogado del diablo, diferentes servicios!!! NO!!
Yo apuesto por no desviarnos del lema "menos es mas", me explico:
Un servicio se define por el proceso de negocio que habilita y no por sus canales.
Yo propongo que el canal sería una opción del servicio, y que cada canal tuviera objetivos de servicios diferentes de un mismo SLA, ya que evidentemente desde la perspectiva de monitorización del catálogo el round-trip (ida y vuelta de un email) no tardará os mismos milisegundos/segundos por GPRS que por LAN Corporativa.
jeje, bueno pues mi catálogo digamos que intenta reunir todo lo que comentas, es de productos intangibles y por tanto servicios, y todos de TIC. Pretende gestionar la demanda y también las expectativas, sentando un marco para acotar las peticiones posibles. También incluye los servicios profesionales (y no solo los "de máquina"). Y está echo con la mejor de las intenciones ;o).
Respecto al tema que comentas del correo y la problemática de la disponibilidad de sus distintas opciones, hay una buena orientación en el libro de Service Strategy, en la página 134 "Service Level Packages" y justo el diagrama del correo en la página 136.
Saludos,
Ángel Berniz.
Supongo que como en casi todo, al respuesta es: depende.
No olvidemos que el catálogo no lo queremos porque sí, sino para dar respuesta, dar soporte a un montón de procesos ITIL.
Así pues creo que cada organización debe plantearse si para dar esa respuesta necesita que el correo sea un servicio único o el servicio sea el correo-BB y el correo-IMAP y el correo-web y...
Planteemoslo así ¿qué ganamos y qué perdemos con cada una de las dos opciones?
¿Alguien se anima a pensarlo?
Angel, tu aportacion sobre el libro de Service Strategy es muy interesante. Le echare un par de lecturas detalladas a ese apartado, porque es posible que aporte algo más de luz.
Antonio
Y la relacion del catalogo de servicios y la gestion del cambio....ej. servicio. abrir un puerto en el firewall o cerrarlo.
pero esto es un cambio en un activo por tanto, sujeto a cms. O el servicio es un cambio preautorizado ?
llevadme hacia la luz.
Yo creo que antes de empezar con el catálogo se debería de tener claro para qué se quiere porque dependiendo de los objetivos que se persigan puede variar mucho... para poner límites a TI desde el punto de vista de los usuarios, para garantizar que las peticiones de servicio "aporten" al negocio y que se hagan de la mejor forma posible a través de un catálogo de peticiones asociadas a servicios, para saber cuál es la infraestructura que más hay que proteger partiendo de servicios más críticos, para saber cuánto cuesta entregar servicios y qué se ha de facturar en cada caso o analizar qué servicios son más rentables, para relacionar servicios de cliente con servicios técnicos... y se me ocurren unos cuantos usos más.
Según mi punto de vista, lo más práctico es empezar de forma sencilla teniendo muy claro cuál es el beneficio que se espera obtener.
Saludos!
nerea.
Publicar un comentario