La navaja suiza

A menudo se hace referencia a SolMan como la "única fuente de la verdad". Los distintos escenarios de aplicación pueden funcionar hasta cierto punto de forma independiente, pero en cuanto se requieren procesos interrelacionados, ya no es posible.

Es cierto que un service desk puede funcionar de forma autónoma, pero en cuanto entran en juego temas como la gestión de pruebas o ChaRM, solo tiene sentido una visión integrada.

El hecho es que muchas empresas ya han asignado varias funciones de Solution Manager a otros lugares. La gestión de incidencias suele estar en otras manos, y la supervisión también suele llevarse a cabo con otras herramientas.

Sin embargo, las interfaces son necesarias a más tardar cuando un incidente debe convertirse en un cambio o una alerta de seguimiento en un incidente.

Por desgracia, Solution Manager no está tan bien equipado en cuanto a interfaces. Esto probablemente se deba también a la pretensión un tanto posesiva. En última instancia, ITIL y una herramienta sólo funcionan bien si se utilizan de forma holística.

Las interfaces son siempre la segunda mejor opción en un escenario de integración y deben pensarse mucho. En el ámbito de la gestión de incidencias, existe la denominada interfaz de terceros con otros service desks, pero no es necesariamente autoexplicativa.

Los esfuerzos de implantación tampoco son precisamente nulos, sino que hay que afinarlos minuciosamente, como en todo entorno de interfaz. La semana pasada tuve que convencer a un cliente de la complejidad de esta interfaz.

Por desgracia, esta conexión "oficial" desde el exterior es también la única forma de interfaz. Todas las demás integraciones deben construirse manualmente.

En un escenario típico de un departamento de TI que quiere seguir implantando Solution Manager, ya existe un service desk. La primera base de discusión es decidir si todas las incidencias deben registrarse de forma centralizada.

En algunos casos, existe el deseo de reenviar los tickets SAP al Solution Manager y luego implementarlos allí específicamente. Tales interfaces son concebibles, pero no debe descuidarse el esfuerzo de implementación para transmitir los valores de estado de un ticket.

En el ámbito de la gestión de solicitudes de cambio, solemos implementar interfaces específicas del cliente con el servicio de asistencia técnica del cliente. De este modo, se puede crear y procesar un cambio directamente desde un incidente de otra herramienta. Si se decide por este escenario, la siguiente interfaz no está muy lejos: en cuanto TI se decida por la gestión de pruebas, también habrá que gestionar los mensajes de los casos de prueba.

La integración clásica y estandarizada prevé aquí, naturalmente, el Service Desk de Solution Manager. De este modo, por supuesto, debe crearse una solución para crear tickets en otro Service Desk. No existe un escenario de interfaz sensato para el tema de la documentación de soluciones.

Sólo el cliente puede decidir si los documentos pueden almacenarse localmente o a través de un enlace, por ejemplo, en un sharepoint. En este caso, el cliente debe decidir en última instancia dónde quiere documentar.

Cuantas más funcionalidades se vayan a utilizar en Solution Manager, más se afianzará Solution Manager de forma natural como un "pulpo de datos" y también se espera el uso significativo de los escenarios correspondientes.

Generalmente, una interfaz para conectar el Service Desk del Solution Manager. Se trata de un escenario habitual, sobre todo teniendo en cuenta que una herramienta de gestión de incidencias no puede sustituirse sin más en entornos informáticos de mayor tamaño.

Sin embargo, la forma exacta de integración debe diseñarse siempre de forma individual. Todos los demás temas deben permanecer en Solution Manager en la medida de lo posible, ya que las interfaces pueden llegar a ser arbitrariamente complejas tanto en su implementación como en su funcionamiento.