NOTAS BASADAS EN LA EXPERIENCIA REAL DE GESTIÓN DE LA DEMANDA, LEJOS DE UNA VISIÓN ACADÉMICA DE LA MISMA
Aunque no está formalmente descrito en ninguna metodología TI, por un sistema de trabas entiendo a dotarse de un conjunto variado de dificultades que se le van a aplicar a nuestros usuarios-clientes. Tanto a la hora de pedirnos proyectos, solicitar evoluciones de los sistemas, o cuando quieren que resolvamos incidencias y problemas existentes en las soluciones tecnológicas.
Las dificultades pueden ser de distinto tipo: metodologías inexistentes, procedimientos poco documentados o no publicados, circuitos desconocidos, herramientas de comunicación sin ningún retorno al peticionario – sean correos electrónicos u otro tipo de herramientas que los encubran -, desconocimiento de mecanismos de priorización, sistemas sin criterios de calidad de servicio prefijados, etc. Lo que viene a ser un funcionamiento en modo caja negra y con resultados probablemente muy deficientes.
Y seguro que hay ejemplos donde este sistema de trabas evitó hacer aquel trabajo que dejó de ser necesario, y donde la compañía se ahorró un buen dinero. Pero también tendremos que buscar en otros sitios, si los hay, información de aquellos proyectos no realizados en TI que pudieran haber generado ingresos significativos. Algunos hubieran tenido valor estratégico, valor que se perdió al llegar tarde al mercado, o simplemente no llegar.
A pesar de opiniones mayoritarias contrarias a las trabas, en nuestras organizaciones a veces tenemos mecanismos de demanda con nuestros clientes internos o externos que parecen tener como objetivo que desistan. Como ya he comentado en posts anteriores, un sistema puramente administrativo de peticiones tampoco se puede considerar una solución. El hacer o no hacer tiene que responder a un criterio.
Y si estamos en el ámbito de las incidencias y problemas, el sistema de trabas es aún peor. Las trabas impiden que las cuestiones lleguen a quien las puede resolver, o a quien puede dar una alternativa. Debemos huir de esa cultura un poco paranoica donde algunos piensan que nuestros usuarios-clientes nos transmiten problemas para molestarnos, no porque existan.
Los sistemas de trabas también van contra la idea básica TI como unidad de servicio. No sé si leí o me comentaron en cierta ocasión una idea sobre el servicio informático que ha sido básica para mí desde entonces. Cuando tenemos una incidencia, petición o problema, no tenemos una sino dos: la demanda que nos comunican, y el cliente que la hace y que está afectado. Y es que, incluso sin dar solución al problema, se puede resolver la mayor parte de la cuestión atendiendo al cliente, dándole información, un plan de solución o alternativas temporales para evitar el problema. Con un mecanismo de trabas podremos en su momento resolver la incidencia, pero habremos perdido la percepción de calidad del cliente que tendría con un buen sistema de demanda.
«Debemos huir de esa cultura un poco paranoica donde algunos piensan que nuestros usuarios-clientes nos transmiten problemas para molestarnos, no porque existan.«
Otra idea a considerar es que la gestión de la demanda siempre existe, sea conocida y documentada, o bien escondida y sólo disponible para los más despiertos. Y este último escenario de “listos” creo que es demoledor para el servicio. “Listos”, o la “gestión de la demanda en la mesa del analista o del técnico de soporte” supondrá que ni se hace lo que se quiere, ni cuando se quiere, con un coste poco conocido y una previsión de ingresos inexistente.
Con lo dicho en los apartados anteriores espero que todos estemos de acuerdo con la afirmación que titula el post. El sistema de trabas será válido para aquellos pocos que gestionan con más medios de los que necesitan, y que tienen cierta despreocupación en la optimización de la gestión de demanda y de los proyectos.
¿Cómo podemos evolucionar de ese sistema de trabas a una gestión efectiva de la demanda?
- Revisar la metodología si existe. Si no existe, adaptar alguna de las existentes. No son complejas, pero deben integrar la totalidad de la demanda, insistir en la transparencia e involucrar a todos los afectados.
- Hacer un plan de implantación no saltándose pasos, y ejecutarlo. Que la metodología se apruebe por la dirección. Y que se publique. Formar a todos los intervinientes: peticionarios, gestores y encargados de la realización.
- Disponer herramientas adecuadas: estándares, que unifiquen toda la demanda TI, con funcionalidad y elementos de gestión definidos, etc. No hay que empecinarse en modificar las existentes; puede ser un buen momento para redefinir herramientas y optar por alguna de las buenas existentes en el mercado. Herramientas alineadas con las necesidades actuales, con las que están viniendo y de fácil personalización. Y de uso sencillo.
- Si es posible, pilotar metodología y herramientas. Y revisar el ciclo de metodología y herramientas hasta tener un servicio válido y efectivo para todos los intervinientes.
- Y ya que estamos preparado esta evolución para TI, pensemos siempre en el ámbito de toda la organización; es probable que el siguiente paso, después del éxito en TI, sea planificar la expansión al resto de la organización.
En Xeridia podemos plantearte evoluciones metodológicas desde distintos puntos de partida. Incluso si partes de un sistema parecido al de trabas. Será un poco más complejo el avance, pero el éxito será mayor pues mayores son las opciones.
Como Atlassian Platinium Solution Partner te podemos dar opciones para gestionar la demanda TI, poder plantear la de toda la compañía, con herramientas de fácil uso y orientadas a las necesidades presentes y futuras.
Avelino Carrizo es Gerente de Consultoría de Sector Financiero en Xeridia
