MEHGEST - Características de Explotación

Dentro del apartado de Características de Explotación entran aquellos puntos que harán más llevadera la explotación de los datos que vayamos entrando en el sistema.

Reporting

Si miramos cualquiera de los diagramas resumen de los libros de ITIL, veremos que todos y cada uno de los procesos involucrados en la Gestión de Servicios genera reports como mínimo para las tareas de control y seguimiento de los resultados del proceso. Consecuentemente, nuestra herramienta debe proporcionar un sistema de reporting potente, flexible y fácil de utilizar o, mejor aún, debe poderse integrar con la herramienta de reporting que utilicemos en la empresa, de tal forma que nuestro equipo de BI no deba aprender a utilizar nuevas herramientas.

La integración con herramientas de reporting externo pasa normalmente por la definición de un modelo de meta-datos que facilita la extracción de los datos (como ya habíamos comentado anteriormente, en un entorno multi-empresa y multi-idioma la cosa se puede llegar a complicar bastante). Así, requeriremos que ya sea el fabricante o bien partners cualificados proporcionen los modelos de metadatos necesarios para nuestra herramienta de reporting.

Modelo de Base de Datos documentado

En el peor de los casos, podremos sustituir estos modelos de metadatos por una buena documentación del modelo de datos, las relaciones entre los diferentes elementos e incluso conjuntos de vistas SQL que permitan obtener la información.

Otra utilidad de disponer de un modelo bien documentado es el tunning de la base de datos, la correcta distribución en volumenes para conseguir rendimientos óptimos y la posibilidad de realizar consultas ad-hoc cuando sea necesario (espero que sea poco necesario, pero siempre puede aparecer la necesidad).

"Transportes"

Hemos aprovechado la nomenclatura SAP para referirnos a la necesidad de que exista un mecanismo que nos permita mantener un sistema de desarrollo en el que se realicen las parametrizaciones necesarias, se prueben, se monitoricen y evalúen y cuando estén aprobadas, se puedan traspasar al entorno productivo sin tener que volver a realizar todos los cambios uno por uno.

Este tipo de utilidades nos va a permitir reducir los costes de paso a producción, desarrollar paquetes pre-parametrizados para distribuir a oficinas remotas u otras empresas del grupo o incluso externalizar las tareas de desarrollo sobre la herramienta a terceros.

Archivado de datos históricos

Con el paso del tiempo tendremos toneladas de datos históricos almacenados en nuestro sistema, tanto incidencias, como cambios relacionados, personal, elementos de configuración, servicios, etc etc etc. Todos estos registros estarán relacionados entre ellos, de tal forma que no podremos hacer un borrado de datos antiguos sin que las relaciones "estiren" de datos de múltiples entidades (eliminar un registro de persona de un empleado que ya no trabaja en la compañía afectará a los registros de incidencias en los que aparece esta persona como interlocutor, al tiempo que esas incidencias estarán relacionadas con Elementos de Configuración y con problemas y así sucesivamente).

Llegado el momento, tenemos que poder hacer algo con estos datos antiguos, ya sea eliminarlos definitivamente, archivarlos a una base de datos con menor rendimiento y costes de almacenamiento o marcarlos como "obsoletos" para que no aparezcan en las vistas de usuarios.

Instalación de Parches

Cuando tengamos distribuidos los clientes (si existen) será necesario contar con un sistema de distribución de parches, hotfixes o nuevas versiones que no obligue al departamento a realizar instalaciones presenciales en todos los puestos de trabajo de las personas que utilicen la herramienta (y que en ocasiones pueden no pertenecer a la propia compañía si contamos con servicios externalizados de atención de llamadas, por ejemplo).

Facilidad de Uso en entornos distribuidos

¿Cómo se comporta la aplicación que estamos evaluando en un entorno distribuido con líneas de comunicación que pueden no ser de banda ancha?

En organizaciones en las que hayan equipos de trabajo en las ubicaciones remotas, estos equipos tendrán la necesidad de soportar el trabajo del día a día sobre la herramienta de Gestión de Procesos, por lo que es importante que la herramienta se comporte bien bajo estas condiciones de dispersión geográfica.

Es necesario también preguntarse cuáles son los requisitos de comunicaciones que la herramienta necesita para dar un rendimiento aceptable y contar con cuánto ancho de banda disponible podemos contar.

MEHGEST - Usabilidad

Las características de usabilidad van ligadas a la sensación que tiene el usuario cuando utiliza la herramienta. A primera vista podrían parecer futiles o carentes de una importancia capital, pero la experiencia nos dice que habitualmente estas herramientas se implantan aproximadamente al mismo tiempo que se hace la implantación de los procesos. En esos momentos, la organización TI está sometida a una fuerte presión psicológica por todos los cambios que se están produciendo (cambios organizativos, cambios en la forma de trabajar, cambios en los roles y responsabilidades, cambios en la forma de medir y evaluar el trabajo realizado, etc.) y es importante conseguir que la experiencia del usuario sea lo más agradable posible para evitar rechazos conscientes o inconscientes provocados por la herramienta en sí.

Idioma

 El idioma en que este presentado el interfaz de usuario debería ser el nativo de las personas que lo van a utilizar o, en su defecto, el estandard de la compañía, para facilitar la adopción de las nuevas formas de trabajo.

No debemos olvidar evaluar no sólo el idioma en el que se presenta el interfaz de usuario, sino tambien el idioma de

• Manuales de usuario
• Manuales de administración
• Ayudas online
• Globos de ayuda
• Cursos de formación

Multi-idioma

Para aquellos casos en que la herramienta no esté disponible en el idioma que necesitamos o bien para aquellos casos en que la corporación necesite trabajar en idiomas diferentes sobre la misma instalación, es obligatorio que la herramienta soporte configuración de multiidioma y que permita asociar a un perfil de usuario qué idioma por defecto empleará.

Por otra parte, es recomendable que no sólo proporcione la capacidad de multiidioma sino que además el fabricante proporcione varios paquetes de localización, así como herramientas cómodas para localizar el producto según nuestras necesidades.

Otro de los factores a tener en cuenta es la capacidad de traducción (y de mantenimiento en "modo multi-idioma") de los campos adicionales, mensajes, pop-ups, etc que podamos añadir según nuestra parametrización (por ejemplo, formularios, campos adicionales, notificaciones por email, etc)

Documentación

La calidad de la documentación disponible es de vital importancia, sobre todo para facilitar el paso a producción del entorno implantado. Así mismo, es importante asegurarse de que disponemos de manuales de administracion y de usuarios con ejemplos claros que ayuden al usuario o administrador de la herramienta a realizar su trabajo.

En el caso de que la herrmaienta disponga de procesos externos de integracion, APIs, módulos adicionales para enlaces con otros productos, etc... debemos asegurarnos de que existe una buena documentación al respecto de cada una de estas piezas.

Web de Soporte

El fabricante de la herramienta ha de proporcionar el soporte técnico sobre la misma. Habitualmente este soporte se proporciona mediante contratos de soporte que habilitan el acceso a un sitio web con documentacion, notas técnicas, parches, etc. Asegurarse de que la calidad de estos contenidos es la apropiada se verá recompensado cuando en los momentos más críticos podamos resolver problemas o incidencias relacionadas con el producto de una forma sencilla.

Un aspecto importante de estas webs de soporte es que existan foros de usuarios donde se comparta informacion "no oficial". ya que muchas veces nos encontraremos con que no somos los únicos que padecen determinada problemática y podremos contactar con personas que ya las han sufrido.

Por último, una característica interesante (aunque puede ser suplida con otras vías de comunicación con el fabricante) es la posibilidad de crear Solicitudes de Cambio para proponer mejoras, cambios o nuevas funcionalidades al producto y que nos permitan saber el estado en el que se encuentran estas solicitudes.

Motor de Búsqueda y KBase

Una de los conceptos claves de ITIL se resume en un antiguo proverbio chino:  "La experiencia del pasado, si no cae en el olvido, sirve de guía para el futuro. "  Por esta razón, disponer de un motor de búsqueda potente y de una base de conocimientos que aproveche toda la información presente en los diferentes registros de la aplicación será la clave para que el personal perciba rápidamente el ROI de implementar los procesos y de seguir las nuevas pautas de trabajo.

MEHGEST - Seguridad / Confidencialidad

Como en cualquier otro entorno, la confidencialidad es uno de los requerimientos de la información básicos que debemos cumplir. En una herramienta en la que almacenaremos información de todo tipo, es necesario garantizar que las personas sólo ven aquello que deben ver.

Roles

 En cualquier entorno medianamente complejo y que vaya a tener un número de usuarios medianamente alto, en lugar de gestionar los permisos de acceso individualmente lo haremos mediante roles o perfiles de seguridad. Así, el perfil de técnico de primer nivel tendrá unos niveles de acceso a la información diferentes a los del gestor de configuraciones.

Permisos de Acceso

Asociado directamente a los perfiles, tendremos los permisos de acceso. Aquí si que creo que es importante tener cuanta mayor granularidad, mejor. Luego es posible que no utilicemos la granularidad proporcionada (por ejemplo, llegar a determinar que un rol determinado puede o no ver determinado campo bajo determinadas condiciones), pero cuando necesitemos esos niveles de detalle es bueno tenerlos a nuestra disposición.

Acceso en función del contenido

Esta es una de esas funcionalidades poco corrientes, pero que vienen bien, sobre todo en entornos complejos. La idea es que la herramienta nos permita definir permisos de acceso a los diferentes items u objetos no sólo en función del rol o perfil de acceso sino además en función de los contenidos. Por ejemplo, puedo definir que un técnico de primer nivel no puede modificar los contenidos de una llamada de servicio que no esté asignada a él, o que un gestor de configuraciones que tiene asignadas las responsabilidades del mantenimiento de la CMDB en el área de software no pueda modificar un CI de tipo Router.

Autenticación de Usuarios

Aquí es necesario evaluar las capacidades de autenticación de los usuarios y las facilidades en la gestión de los mismos. ¿Tiene controles de fecha/hora de logon? ¿Tiene posibilidad de bloquear a un usuario? ¿Tiene posibilidad de "caducar" las contraseñas?

Integración con Directorios Externos (LDAP / MS-AD / etc)

En aquellos entornos en los que tengamos una gran cantidad de usuarios o bien en los que la rotación de usuarios sea demasiado frecuente, la integración de los sistemas de autenticación de usuarios con los directorios corporativos no es sólo un requisito estético, sino que se convierte en una verdadera necesidad para reducir los costes de administración. Esta integración se puede realizar de dos formas principalmente:

• Integración completa, de tal forma que en el momento en que vamos a realizar el logon en la aplicación las credenciales son validadas directamente en el directorio externo
• Integracion por réplicas, donde se sincroniza periodicamente la información del directorio corporativo con la base de datos de usuarios propia de la herramienta. Esta es una integración más débil que la anterior, pero bastante frecuente.

Single Sign-On

Una vez que disponemos de un sistema de integración con el directorio corporativo, el siguiente paso es que el sistema nos permita realizar un logon único adaptado al logon ya realizado en el sistema operativo, ya sea de forma nativa o bien utilizando software de terceros.

MEHGEST - Seguridad / Integridad

En un entorno que seguramente va a ser complejo y con multitud de usuarios diferentes, las reglas de integridad que aseguren que todas las relaciones se mantienen correctamente y que los datos entrados son correctos son de vital importancia.

Campos Obligatorios

En toda implantación de herramientas necesitaremos poder especificar qué campos son obligatorios y cuándo lo son. Como mínimo, las herramientas nos suelen exigir toda una serie de campos obligatorios; las que son un poco más avanzadas nos permiten seleccionar qué campos son obligatorios para nuestra definición del proceso y, por último, las más avanzadas nos van a permitir indicar cuándo es obligatorio un determinado campo. Así, en un registro de incidencia el campo Interlocutor debería ser obligatorio siempre, mientras que el campo Impacto podría ser obligatorio a partir del momento en que se haya realizado el análisis de impacto de la incidencias y el campo Solución lo será a partir del momento en que demos la incidencia por cerrada.

La obligatoriedad o no de un campo no tiene que venir dada únicamente por el punto en el ciclo de vida (estado) en el que nos encontremos; también es interesante que se pueda forzar la obligatoriedad de un campo de forma dinámica en función de los valores presentes en otros campos. Así, por ejemplo, podremos decir que el valor de Tiempo Dedicado sea obligatorio siempre y cuando el tipo de Llamada de Servicio sea Solicitud de Instalación In-Situ y el Estado sea Finalizado.

Controles de Coherencia

Es posible que se entren datos en un registro que no sean coherentes. Lógicamente, no podremos aplicar todos los controles de coherencia posibles, pero si la herramienta nos permite definir reglas que evalúen la coherencia de los contenidos, podremos definir aquellos controles más importantes.

Integridad Referencial

A estas alturas no deberíamos tener la necesidad de preguntarnos si una aplicación mantiene la integridad referencial o no en las relaciones entre objetos, pero nunca se sabe. Tal y como se plantean este tipo de productos, tendremos una base de datos en la que vamos a almacenar elementos de configuracion, llamadas de servicio, problemas, personas, organizaciones, contratos... y todos estos tipos de objetos estarán relacionados entre si, de tal forma que tendremos personas en las llamadas de servicio, CIs en los contratos y en las llamadas, etc. ¿Qué pasa cuando se borra un CI? ¿Qué ocurre con todas las llamadas en las que está presente ese CI? ¿Qué ocurre con todos los contratos? ¿Y con los problemas que están relacionados con las llamadas que a su vez están relacionadas con los CI's?

Esto nos lleva normalmente a no poder borrar nada y, por lo tanto, debemos tener mecanismos que permitan "borrar pero sin borrar", dejar estos registros en el limbo de los datos referenciados.

Campos "Read-Only"

En realidad este punto debería llamarse "niveles de acceso a los campos", pero eso es un nivel de seguridad que pocas herramientas permiten. Así que como mínimo deberíamos poder establecer que determinados campos son de solo lectura para garantizar que no nos los modifiquen.

MEHGEST - Ampliación de Funcionalidades

Siempre es interesante contar con una herramienta que nos permita aumentar o adaptar las funcionalidades de las que dispone, de tal forma que podamos terminar de adaptarla a nuestras necesidades. Aquí entran en juego muchos factores, sobre todo si tenemos en cuenta que cuanto más flexible sea una herramienta, más cara será (ya sea en coste de adquisición o en coste de mantenimiento) y mayor será la complejidad de su mantenimiento. Por esta razón, lo más probable es que cuanto más madura sea la organización TI en lo relativo a la Gestión de Servicios, mayores serán las necesidades de flexibilidad de las herramientas utilizadas.

API

La primera aproximación a la ampliación de funcionalidades de las herramientas viene dada por la existencia de APIs que nos permitan desarrollar extensiones a la aplicación. En este sentido, hay que evaluar en qué lenguaje tendremos que desarrollar para hacer un uso adecuado de estas APIs, si existen APIs para el cliente o sólo para el servidor , la amplitud de estas APIs (¿todas las funcionalidades que proporciona el producto se pueden acceder a través de las APIs? ) y la calidad de la documentación y ejemplos existentes para el desarrollo.

Integración en el propio cliente:

Cuando desarrollamos nuevos módulos con las APIs, normalmente estos módulos se ejecuntan como aplicaciones a parte, separadas de la ejecución del cliente. A veces es necesario que estas nuevas funcionalidades se puedan integrar directamente en el cliente o en el interfaz de usuario.

MEHGEST - Canales de Acceso

La forma en que los usuarios (del departamento de TI) van a acceder a la aplicación va a determinar en gran medida la capacidad de trabajar en un entorno distribuido o quizás en un entorno con gran movilidad.

En este aspecto, no nos debería dar una mayor o menor puntuación el hecho de que la herramienta nos proporcione unos canales de acceso que en nuestra organización no se van a utilizar, pero es importante que la herramienta nos permita accederla utilizando las plataformas de las que disponemos.

Cliente Propietario

Es bastante habitual que las herramientas utilicen un cliente propio que implemente, por ejemplo, la ejecución de toda la parte de inteligencia “local” que se necesita en los automatismos a nivel de formulario. Ahora bien, es importante evaluar correctamente las funcionalidades que nos aporta este cliente propietario frente a los requisitos de instalación de esta aplicación:

• plataformas soportadas
• requisitos de memoria y de disco
• facilidad para la distribución automatizada del cliente a todos los usuarios
• facilidad para la distribución automatizada de parches y nuevas versiones
• etc.

Cliente Ligero

Lo normal sería que nuestra herramienta permitiese el acceso por clientes ligeros (navegador Internet) y que permitiera utilizar todo el conjunto de funcionalidades necesarias (muchas veces encontraremos que el cliente propietario es capaz de dar mayor potencia que el cliente por navegador).

Por otra parte, un acceso por navegador para los usuarios finales también es necesario, aunque no necesitaremos todo el paquete de funcionalidades completo sino únicamente las destinadas a usuario final.

Terminal Services / Citrix

Es importante que el cliente propietario esté desarrollado de forma que sea compatible con las plataformas más comunes de consolidación (en realidad es necesario que sea compatible con nuestra plataforma de consolidación).

PDA

De cara a facilitar la movilidad de los técnicos de campo, muchas veces es útil la compatibilidad del cliente (ya sea el propietario o bien el de navegador) con el acceso desde un dispositivo móvil tipo PDA o SmartPhone.

Debido a las limitaciones de este tipo de dispositivos, no siempre tiene que ser una conexión “on-line”, por lo que también es recomendable que exista la posibilidad de documentar los registros (normalmente de CIs y Llamadas de Servicio como mínimo) y posteriormente sincronizar esta información con el servidor.

MEHGEST - Integraciones

La capa de integraciones es la pieza fundamental para que cualquier herramienta que seleccionemos se pueda convertir en un componente “activo” dentro de nuestra infraestructura. Las integraciones deberán ser en ambos sentidos, es decir tanto integraciones que permitan a herramientas o sistemas externos interactuar con nuestro sistema de Gestión de Servicios TIC como integraciones que le permitan interactuar con el exterior.

Correo Entrante

La capacidad de que el usuario final pueda comunicarse con el departamento de TI enviando mensajes de correo electrónico a direcciones específicas que están integradas en la herramienta es algo muy común.

Correo Saliente

Esta es una característica fundamental del sistema de Gestión de Servicios TIC. Nos va a permitir comunicarnos con el usuario final, así como notificar asignaciones, alertas, modificaciones, etc. a los diferentes miembros de los equipos TIC. Esta funcionalidad debe ser combinable con las capacidades de automatización, de tal forma que la herramienta pueda, por ejemplo, enviar automáticamente un e-mail al usuario cuando registre una incidencia o enviar automáticamente un mail al responsable de la Gestión de la Configuración cuando se registre un nuevo contrato de soporte.

Integraciones Bidireccionales

En muchos casos vamos a requerir que las integraciones con otros sistemas de información sea bidireccional. Para ello es necesario que en ambos extremos de la integración quede alguna pieza de información que nos permita “ligar” los dos entornos.

Un ejemplo de este tipo de requerimientos es una integración de la CMDB entre nuestra herramienta y una herramienta de descubrimiento de la red: para poder distinguir cada uno de los elementos es necesario que haya un identificador único en los dos sistemas de tal forma que el objeto descubierto sea el mismo en los dos extremos y una modificación en el objeto pueda ser propagada.

Integraciones CTI

La capacidad de integración con el mundo de la telefonía tiene una importancia cada vez mayor. Uno de los requisitos más habituales que se solicita es la capacidad de presentar un formulario de registro de llamada de servicio pre-relleno de forma automática al operador en el momento en que la centralita pasa la llamada.

En el otro sentido de la integración aparece la necesidad de interacturar con el “soft-phone” de tal forma que el operador pueda iniciar directamente la llamada desde el interfaz de usuario de nuestra herramienta.

Por último, nos encontramos con la posible necesidad de disponer de un sistema que, similar a un buzón de voz, permita registrar una llamada de servicio con un archivo anexo con el mensaje de voz que nos ha dejado el usuario final.

Integracion Masiva (batch)

Podemos distinguir dos tipos de integración de datos de entrada en nuestro sistema: aquellas integraciones que registran o modifican un único elemento (el registro de una llamada desde la integración CTI antes mencionada, por ejemplo) o bien aquellas que son masivas y que sirven para la sincronización de datos con fuentes externas (importar los datos de organización desde el entorno de Recursos Humanos).

En el caso de las integraciones masivas, es importante saber los diferentes tipos de datos que podemos incorporar, el mecanismo de desarrollo/parametrización de estas integraciones y, sobre todo, si disponemos de una herramienta de tipo ETL que nos permita Extraer los datos desde las fuentes originales, Transformar estos datos para que se correspondan a nuestras necesidades y Cargar (Load) estos datos en nuestra herramienta, con los controles de integridad necesarios.

A primera vista puede parecer innecesario el disponer de estas herramientas de carga masiva, pero este es uno de los apartados más complicados que conozco en la implantación técnica de sistemas de gestión de este tipo.

Integracion por Eventos

El otro tipo de integración, tal y comentábamos anteriomente, es la integración unitaria o por eventos. Este tipo de integración nos va a permitir crear o modificar un único objeto puntualmente y se suele ejecutar por las aplicaciones externas cuando detectan un cambio o cuando se produce una situación que debe ser registrada. El ejemplo más típico es la integración con nuestra herramienta de gestión de red: cuando se detecta que un elemento de la red está caido, querremos registrar una incidencia con todos los datos relativos al CI afectado.

MEHGEST - Vistas

La forma en la que accedemos y consultamos la información en nuestra herramienta va a tener una gran importancia cuando haya pasado un tiempo y nos encontremos con que en nuestra base de datos hay miles (o cientos de miles) de registros. Necesitaremos que la herramienta nos proporcione vias de búsqueda y de consulta de esta información de una forma flexible y ágil.

Entendemos por vistas precisamente esta forma de presentar la información no detallada (que la veremos en el formulario) sino global.

Flexibles

Lógicamente, querremos que las vistas sean flexibles, parametrizables tanto por los administradores del sistema como por el propio usuario, de forma que cada uno de los miembros del equipo de soporte de primer nivel (por ejemplo) pueda organizarse las incidencias abiertas asignadas a su grupo de especialidad como quiera: unos querrán ver el usuario, el impacto y la descripción y otros querrán ver la organización, el usuario, el servicio afectado y la fecha objetivo de cierre.

Dinámicas

Las vistas no deben proporcionar una información estática, sino que deben actualizarse automáticamente (ya sea periódicamente o en base a eventos de forma “on-line”) de tal forma que tengamos la certeza de que el usuario ve la información actualizada.

Tipos (listado, gráfico, árbol…)

A diferentes tipos de información y diferentes objetivos en la presentación, diferentes tipos de vistas. El técnico de primer nivel quiere tener un listado en pantalla con sus llamadas abiertas, mientras que el coordinador de soporte quiere ver un gráfico con el tamaño de las colas de asignación de llamadas y el responsable de la CMDB quiere ver un arbol con las categorías de elementos de configuración y los elementos que contiene cada una de estas categorías. ¿Será la herramienta que estamos evaluando lo suficientemente flexible como para presentar estos tipos de vista? ¿Y lo podremos hacer de una forma sencilla?

Drill-Down

En la presentación de la información también triunfa “la ley del embudo”: ancho para los de arriba y estrecho para los de abajo. Normalmente en la presentación de información querremos ir desde niveles altos de abstracción o generalismo al detalle último, de tal forma que a partir de una vista que muestre información genérica (como aquella del coordinador de soporte, con una gráfica que indica el tamaño de asignación de colas) querremos ir navegando hacia una información más detallada (los técnicos que atienden cada una de las colas) y más detallada aún (las llamadas asignadas a cada técnico) hasta llegar al nivel más atómico de detalle (el formulario en el que vemos todos los campos de la llamada en concreto que estamos analizando).

MultiNivel

Vistas multinivel son aquellas que pueden presentar información de varios tipos o entidades relacionadas entre sí. Por ejemplo, una vista en la que mostramos el árbol de categorías de elementos de configuración, para cada categoría mostramos los elementos de configuración presentes en dicha categoría, para cada elemento mostramos las llamadas de servicio que se han recibido relativas a ese elemento, para cada llamada los problemas relacionados y para cada problema los cambios relacionados con ese problema.

Hemos liado bastante la vista, pero da una idea clara de lo que significa tener la capacidad de crear vistas multinivel.

MEHGEST - Automatización

La capacidad de una aplicación de Gestión de Servicios TIC para realizar acciones automáticas es crítica para facilitar la implementación de los procesos. Las acciones ejecutadas pueden ser de todo tipo, desde el lanzamiento de scripts hasta el relleno automático de campos en una entidad relacionada y nos encontraremos que cada herramienta tiene diferentes “habilidades”.

Acotar contenido de campos:

No es exactamente la ejecución de una acción automática, pero es una característica muy útil: se trata de que el contenido de un campo (normalmente un desplegable o “lista de valores”) quede acotado de forma automática en función del valor de otro campo. Así, en el caso de una llamada de servicio de tipo “Queja”, los posibles valores del campo “Prioridad” se vean restringidos. Otra utilidad para aquellos entornos en los que el flujo de estados no está restringido por una tabla de transiciones es precisamente el forzar la lista de transiciones posibles de un estado a otro.

Ejecutar acciones externas (cliente):

La posibilidad de ejecutar cualquier comando o script externo a la aplicación de forma automática como un evento nos va a permitir realizar todo tipo de integraciones, como puede ser el lanzamiento de popups de notificación, arranque de aplicaciones externas de control remoto, etc.

Ejecutar acciones externas (servidor):

Todas aquellas acciones automáticas que tengan que ver con integraciones a nivel de datos entre diferentes entornos se suelen programar para ser ejecutadas desde el/los servidores en lugar de ser ejecutadas desde los clientes, de tal forma que tenemos centralizadas y controladas estas ejecuciones.

Un ejemplo típico de este tipo de automatización es la integración con los entornos de monitorización de la tecnología, de tal forma que cuando se cierra una incidencia que haya sido generada por estos entornos, se actualiza inmediatamente el estado en el entorno de monitorización mediante la ejecución de un script.

Actualizar contenidos del formulario

En determinadas ocasiones puede ser necesario actualizar el contenido de uno o más campos de un formulario como respuesta a un evento (actualización de un campo, pulsación de un botón, etc.).

Actualizar (o crear) otros items

Esta es una funcionalidad que suele ser muy útil a la hora de establecer formas de trabajo. Por ejemplo, podemos querer crear un registro de Problema de forma automática cuando cerramos una Llamada de Servicio de tipo Incidencia con un código de cierre “Solución Temporal”.

Actualizar items relacionados

Una característica similar a la anterior, pero con la variación de que estamos modificando “todos los items de tipo X relacionados con el actual”. Por ejemplo, podemos tener varios registros de Problema relacionados con un registro de Cambio y queremos cambiar el estado de todos los problemas cuando el cambio esté implementado.

Uso de entidades estándar (plantillas)

Desde mi punto de vista, esta es una funcionalidad crítica para la buena aceptación del producto por parte de los usuarios. Una gran parte del trabajo de registro (de CIs, de Llamadas de Servicio, etc) y el 100% del registro de cambios pre-autorizados es repetitivo: los datos de una llamada en la que nos solicitan el reseteo de una contraseña son siempre iguales a excepción del usuario que llama y algún que otro campo más. El uso de plantillas nos permitirá disponer de formularios pre-rellenados con toda esta información.

MEHGEST - Formularios

La capacidad de parametrizar el aspecto y contenido de los formularios de nuestra herramienta de Gestión de Servicios TIC nos va a permitir adecuarla a nuestras necesidades funcionales y a nuestras necesidades visuales, permitiendonos añadir y quitar campos, reordenarlos, agruparlos, etc.

Parametrización

La evaluación en cuanto a la capacidad de parametrización de los formularios la deberíamos hacer teniendo en cuanta cuán flexible es la herramienta y el grado de sencillez que representa cambiar los formularios: no significará el mismo nivel de dificultad cambiar un formulario utilizando una herramienta “drag and drop” que una herramienta que nos exija cambiar el código fuente. Así mismo, y de cara al futuro mantenimiento que obligatoriamente tendremos que realizar sobre la herramienta, el nivel de especialización o de conocimientos necesarios en el personal tambien será importante.

Parametrización Dinámica

En algunos casos es deseamble que los formularios cambien de aspecto de forma dinámica, en función de la persona que los está utilizando, o del contenido de ciertos cambios. Un ejemplo tradicional de esta funcionalidad se da cuando queremos que un equipo de personas registre las Llamadas de Servicio en la primera línea de atención telefónica y luego otro equipo realice las tareas de resolución de cada una de estas llamadas.

Obviamente, el conjunto de campos que necesita una persona del primer equipo no es el mismo que el conjunto de campos que necesita el segundo equipo, así que conseguir un formulario que muestre a cada uno lo que necesita facilitará el trabajo del primer equipo.

Otro ejemplo claro de este tipo de cambio “al vuelo” se da en el caso del registro de Llamadas de Servicio de diferentes tipos en un Service Desk: es posible que haya campos que sean necesarios para el tratamiento de una queja y que no sean necesarios para el tratamiento de una Petición de Documentación o viceversa.

Tipos de Objeto

Los fabricantes de herramientas nos dirán probablemente que su herramienta es completamente parametrizable y que podemos añadir y quitar los campos que queramos en los formularios. Ahora bien, uno de los factores a tener en cuenta también es el tipo de objetos que podemos personalizar: ¿puedo añadir una pestaña al formulario? ¿y un campo de tipo “radio-button”? ¿Y un botón? ¿Y puedo parametrizar lo que ocurre cuando pulso el botón?

Actualización de datos SOA

Este es un requisito que normalmente no es imprescindible y seguramente sólo será utilizado en entornos muy maduros, pero viene bien tenerlo en cuenta por si lo llegamos a necesitar. La idea es que los datos que se me presentan en el formulario no tienen que ser obligatoriamente extraidos de la Base de Datos propia de la herramienta, sino que es posible que necesite “irme fuera” a consultarlos. Un ejemplo típico es el saber el estado operativo de un determinado elemento de configuración: cuando consulto el CI veo datos estáticos como puede ser su nombre, asset number o descipción, pero si quiero ver su estado operativo actual, la herramienta debe poder realizar una consulta SOA (bueno, no es obligatorio que sea SOA, pero es un estandard que nos puede servir para esto) a la herramienta de monitorización.

La posibilidad de realizar consultas a entornos externos hoy por hoy no es una funcionalidad muy extendida, pero estoy seguro de que con el paso del tiempo se convertirá en algo estandard ya que es la fuente de una CMDB federada.

Checklists

Una utilidad interesante de cara a rellenar los campos de los formularios es la posibilidad de utilizar checklists o árboles de preguntas que vayan guiando al operador en las preguntas importantes que debe realizar al usuario. Esto quizás es un criterio de cara a la función de ServiceDesk, pero como es interesante también para otros ámbitos (por ejemplo la creación de nuevos Elementos de Configuración) se ha añadido como un criterio general.

Anexos

Por supuesto, cualquier herramienta debe permitir el anexado de archivos de todo tipo a los diferentes formularios: necesitaremos anexar documentación a la CMDB, anexar “pantallazos” a las incidencias, enlaces web a los registros de problemas, etc..

Características diferenciadoras entre las diferentes herramientas incluyen:

• ¿Donde se realiza el almacenamiento de estos anexos?
• ¿Cómo viaja el anexo desde el PC cliente hasta la ubicación de almacenamiento?
• ¿Hay utilidades de archivado histórico?
• ¿Hay mecanismos de compresión automáticos?

MEHGEST - Códigos

Parametrización

Una de las características importantes de nuestra herramienta será la posibilidad de configurar o parametrizar todas las tablas de códigos existentes en la herramienta. Por ejemplo, si la vamos a utilizar para implementar la función de ServiceDesk, una de las primeras tablas de códigos que tendremos que tocar será la que indica los diferentes tipos de llamada que podemos recibir (consultar post anterior Service Desk o Gestión de Incidencias? ).

Otro ejemplo típico de parametrización en las tablas de códigos es el conjunto de categorías de los Elementos de Configuración (lo que se conoce como Ambito de la Gestión de Configuraciones) o bien algo tan simple como las diferentes prioridades que podemos asignar a la resolución de un problema.

A primera vista parece obvio que es necesario disponer de mantenimientos y capacidad de modificar estas tablas pero no en todas las herramientas es posible. Sobre todo aquellas orientadas a la Pyme que plantean un modelo rígido en la ejecución de los procesos (y que por lo tanto son herramientas en las que es la organización TI la que debe adaptarse a la definición de procesos estabecida por el fabricante) suelen carecer de esta flexibilidad.

Nuevos

Una cosa es que la herramienta nos permita parametrizar una tabla de códigos, cambiando los valores o incluso añadiendo nuevos valores y otra cosa es que la herramienta nos permita definir nuevas tablas de código.

Siguiendo con el ejemplo anterior de las prioridades asignadas a la resolución del problema, es posible que nuestra aplicación venga de fábrica preconfigurada con los valores “Alto”, “Medio” y “Bajo” para las prioridades de un Problema y nuestra implementación requiera de la prioridad “Urgente”. Esto es parametrizar la tabla de prioridades añadiendo nuevos valores.

Pero lo que posiblemente nos va a ocurrir es que tengamos que crear una nueva tabla de códigos para indicar, por ejemplo, el tipo de empleado para los registros de usuario, y este tipo de empleado sea una tabla de códigos que puede tomar los valores “Temporal”, “Sustitución”, “Permanente” o “VIP”.

Jerarquías

Muchas veces nos encontraremos con que los códigos que empleamos son jerárquicos. Un ejemplo muy habitual es el de el Ambito de la Gestión de Configuraciones, donde definiremos las diferentes categorías de CIs y estas categorías son códigos jerárquicos que se suelen representar en forma de árbol ( Hardware —> Servidor —> HOST o Hardware —> Servidor —> Wintel )

Tipos

Bajo este criterio debemos preguntarnos de qué diferentes tipos de códigos dispone la aplicación para ver si dispondremos de un amplio abanico de posibilidades o no. Por ejemplo, las tablas de códigos pueden ser de tipo Jerárquico, de tipo lista, de tipo booleano, etc.

El nacimiento de MEHGEST

A la vuelta de vacaciones habrá que plantearse nuevos retos, nuevos proyectos y posiblemente nuevos presupuestos para el siguiente año. Algunos de estos nuevos retos incluirán el pensar seriamente en escoger una herramienta adecuada para implantar una buena gestión de servicios, y uno nunca sabe por dónde empezar; así que si el tiempo lo permite empezaremos con una serie de consejos para tener al menos unos criterios válidos para escoger una de las muchas herramientas que propone el mercado (o decidirse a desarrollar una herramienta propia que se adapte a lo que queremos).

Para poder escribir este post con “cara y ojos”, primero pensé que debía hacer un índice de todos aquellos requisitos o características que se deben mirar en una herramienta, listarlos y luego ir desarrollando cada uno de los temas en sucesivos posts, pero a medida que iba haciendo la lista se fue haciendo más y más grande, así que me emocioné, cambié del Word al Excel, y casi sin darme cuenta me he montado la primera versión de la Matriz de Evaluación de Herramientas de Gestión de Servicios TIC (MEHGEST).

El trabajo que queda por hacer ahora se “reduce” a puntos como pueden ser:

• Explicar detalladamente qué significa cada uno de los criterios de evaluación que aparecen.
• Ampliar la herramienta con los criterios generales que cada uno de los lectores o usuarios propongan
• Ampliar la herramienta con una pestaña por cada proceso (con criterios específicos para el proceso)

Por lo pronto, MEHGEST queda a disposición del público bajo una licencia Common Rights de tal forma que puedes usarla y modificarla siempre y cuando compartas las modificaciones y cites la fuente.

Espero comentarios sobre su uso y cualquier tipo de sugerencia al respecto, pero has de saber que no soy ningún experto en Excel y no implementaré grandes virguerias porque no se me da.