Para ti que NO eres del área de TI, y piensas que “ahí dentro” están todos locos (II)

Esta es la continuación de este post de Juan Manuel Espinoza, colaborador habitual de Proactivanet. ¿Cuál es su fórmula para que el área de TI cumpla con su función de manera optimizada?
Empecemos por el principio
Veamos. Si bien el cliente tiene claro que necesita ayuda y que quiere mejorar, muchas veces no será consciente de cuánta ayuda necesita realmente, por tanto, lo mejor es sincerar el escenario. Hay que evaluar realmente su situación actual desde diferentes ángulos, y ver en qué parte adolece más. Es decir, identificar cuál es su problema realmente para poder luego plantear el plan de acción. Muchos clientes dirán que ya saben que se encuentran mal, y que no pagarán porque alguien les diga algo que ya saben. Sin embargo, no es lo mismo tener gripe que pulmonía. Ni el tratamiento es el mismo, ni las implicancias se parecen. Salvando las enormes distancias con los médicos, el contar con un buen diagnóstico es importante y esa es tu primera tarea.
Te encontrarás con clientes escépticos que digan no, eso no me ocurre realmente, y aunque la negación es lo primero que debes esperar, también debes poder rebatir esta situación con los argumentos más adecuados. La realidad es que el cliente no se encuentra bien, y aunque depende realmente de él, tu deber es dejarle clara la situación. Luego el cliente decidirá qué hace o qué no hace, pero en ti no quedará y así por lo menos dormirás en paz. Esta parte requiere de mucha, como decía un ex jefe, mano izquierda. Yo prefiero ser directo, claro y conciso, pero no a todo el mundo le gusta que le digan las cosas de esa manera. En lo personal considero que una mala noticia es una mala noticia, te la digan cantando o te la digan silbando. Ya depende de cada caso. El hecho es que debes lograr que el cliente lo tenga claro.
Imagina que el cliente lo tiene claro, y se dejará ayudar. Después de agradecer al cielo, empieza la parte simpática del asunto. Es ahora cuando empezamos a hablar de sabores. ¿Recuerdan que les dije que existen muchas maneras de resolver las cosas, o que existen muchos caminos para llegar al mismo lugar? Pues eso. Ahora es cuando, según la necesidad y situación del cliente, identificas con qué marco alinearte. En esta ocasión hablaremos de gestión de servicios, así que veamos:
Primer paso. El cliente brinda servicios al resto de su organización, pero no tiene los servicios establecidos ni elaborados. Más allá de su árbol de categorías no ha llegado (y aún se pregunta por qué tiene el caos que tiene, y por qué maneja tan poca información). Como si habláramos de un restaurante, lo primero a definir es la carta (el menú). Es cierto, esta inicialmente será una lista simple de platos que yo creo que deberíamos ofrecer; sin embargo, esta lista luego irá generando más y mejor información (y nutriéndose de esta).
Muchas veces el cliente no tiene claro qué es un servicio y lo relaciona únicamente con las actividades que realiza (error), y dice algo así como mi catálogo de servicios es: soporte al office, soporte al Windows, soporte al Outlook, soportar a los usuarios. Aunque parezca que sí, ese no es un catálogo. Ahora tú dices ¿por qué?, pues porque no hay nada detrás de cada frase. Necesitas saber qué hay detrás de soporte al Office. Cosas como, qué recursos necesito para poder brindar este servicio, o en que horario se brindará este servicio, o quizás quienes son los clientes, o con que proveedores cuento (¿manejamos algún contrato? ¿cuál? ¿qué dice?). ¿Riesgos quizás? ¿Costos asociados? ¿Políticas que seguir o cumplir? ¿Qué niveles de servicio hay comprometidos? ¿Qué habilidades se requieren para brindar este servicio? ¿Este servicio se relaciona con algún otro?, y una lista de etcéteras enorme. Evidentemente todo esto debe ir en un documento vivo (que se actualizará mil veces durante su vida), y cada línea en tu catalogo debe estar igual de documentada y sustentada.
Ahora vas y dices ¿y para qué? Pues para que luego puedas obtener información real y consistente. Información como, por ejemplo: ¿Cuál fue el servicio más consumido? ¿Cuál fue el área que más/menos consume mis servicios y cuáles son estos? ¿Cuál es el horario en el que se requieren más mis servicios? ¿Cuál es el proveedor que mejor/peor nos atiende? ¿Cuáles son los riesgos que más se materializan? ¿Cuáles son los servicios más costosos y los que menos? ¿Cuál es el agente que más carga tiene ¿O cuál es el agente más eficiente y eficaz?, quizás que servicios fueron solicitados adicionalmente cada vez que solicitaron el servicio x?, etcétera, etcétera. ¿Te imaginas todo lo que podrías hacer con esa información? ¿Te imaginas la cantidad de decisiones que podrías tomar? Quizás podrías dar de baja servicios que nadie consume, o asignar mayor cantidad de recursos a servicios que todo el mundo pide, o quizás sincerar tiempos de atención (y con ello reducir capacidad ociosa), y mil cosas más.
La información es clave. Tú lo sabes. Entonces, lo primero es estructurar tu arquitectura de servicio pensando en toda la información que vas a querer obtener, cómo la vas a querer agrupar y explotar, y en el conocimiento que pretendes generar para tu organización. Cómo verás, no es tan simple como listar las cosas que haces, si no hay que darle un sentido y una lógica que vaya más allá.
Segundo paso. Tenemos los servicios definidos en una arquitectura inicial. Sabemos cómo los queremos gestionar, y los tenemos orquestados para tal fin; sin embargo, tenemos que ir más allá. Aquí es donde entra la necesidad de generar relaciones y dependencias entre los recursos que soportarán a los servicios de los que hablábamos líneas arriba.
Imagínate que ya sabes que venderás pizzas, pero además de saber qué pizzas vas a vender, necesitas tener claro que ingredientes componen a cada una de estas, y que tan importantes son realmente (según la especialidad de la casa, por ejemplo). En medio de los ingredientes podemos encontrar fácilmente una lista interminable, entre orégano, tomate, queso, pepperoni, aceitunas, etcétera; sin embargo ¿son todos igual de importantes? ¿acaso mi reacción deberá ser la misma frente a la falta de unos u otros? ¿debo darles el mismo tratamiento a todos los ingredientes por igual? ¿a qué le pondré foco? ¿qué hacer en cada caso? ¿en qué me basaré para hacerlo? Imagina una pizza hawaiana, sin duda su distintivo es la piña, pero dime, ¿eso convierte a la piña en un ingrediente relevante? ¿De qué dependerá? ¿siempre será así? Ni hablar…
Espero que te hayas sentido identificado durante la lectura, y te agradezco que hayas llegado hasta aquí.
Mantente atento, de seguro nos veremos pronto 😉
Un saludo
Juan Manuel Espinoza
Te recordamos que esta entrada es la continuación de esta que habíamos publicado anteriormente.


¿Te los Perdiste? Estos Son los 5 Posts Favoritos de Nuestro Blog

¿Buscando una herramienta ITAM/ITSM? Gartner, GigaOm y Quadrant Knowledge te ayudan a decidir
