Teoría de Restricciones para solucionar un problema en TI

Era fines de Abril del 2004 y estaba de regresó en el área de sistemas. El encargo que recibí era revertir un enorme problema con los usuarios del área Comercial. Las fuentes de insatisfacción eran muchas, por ejemplo, entre las fuentes de insatisfacción externa tenia a los usuario comerciales que se quejaban que los reportes de ventas no cuadraban con las cifras que ventas varios meses, entre las fuentes de insatisfacción interna, teníamos al personal de sistemas que dormía en la oficina a fin de cumplir con lo prometido

El personal de desarrollo trabajaba en ese entonces a través de service, y anhelaban pasar a planilla, esto no se podría sustentar a RRHH dado que no se percibían logros. La presión para completar los desarrollos eran extremos, creando un clima de constante conflicto

Dado que recién me había reincorporado al área, tenía una "breve licencia" para analizar el problema y darle la mejor solución posible. Se me ocurrió aplicar "Teoría de Restricciones" para analizar el problema de manera sistémica.

Teoría de Restricciones: Se basa en tres premisas:

Premisa 1 (Convergencia): Todo dentro de un sistema está conectado por relaciones de causa - efecto. La identificación de las causas y sus conexiones nos llevan a converger en torno a una causa central.

Premisa 2 (Consistencia): Todos los conflictos pueden resolverse sin perdidas. En la realidad no hay conflictos, sólo nuestro nivel de entendimiento y nuestras asunciones sostienen su existencia

Premisa 3 (Respeto): No existe resistencia al cambio. La gente se resiste al cambio porqué no le hemos comunicado adecuadamente cómo gana con la mejora

Si todo está conectado, podré solucionar la causa raíz que afecta a todos los otros efectos indeseables. Al analizar la situación, encontré muchas propuestas de solución, que correspondían con varios problemas (efectos). Debía hallar la relación entre todos esos problemas (efectos).

Hice una lista de los UDE (undesirable effects) y por tres días trabajé en relacionarlas, para ello indagué con el equipo de desarrollo y los gestores de proyecto cuáles eran la relación entre ellas y su correspondiente validación. 

Constaté que el sistema de UDEs se retroalimentaba generando una espiral sin salida a los problemas. El gráfico que realicé es el que se puede visualizar abajo (Árbol de Realidad Actual).

Era necesario romper con la espiral. Como se puede apreciar la causa raíz que disparaba la espiral era el establecimiento apresurado de un compromiso de entrega por parte del IT Manager, éstos compromisos se generaban sin el suficiente análisis, a esto se sumaba la ausencia de metodologías de desarrollo, desencadenando toda una serie de efectos concatenados. 

Plan de Acción

1. Negociación con la Dirección Comercial:

• No se podrá prometer ninguna fecha de entrega al usuario, a menos que hayan transcurrido 24 horas desde que solicitó el cambio, tiempo suficiente para analizar el el cambio y tener un estimado de tiempo y una clara la estrategia de datos
• Se contará con el respaldo de la Dirección de Sistemas Corporativo para que apoye el punto anterior. 
• La promesa de valor al usuario era: mayor confiabilidad y mayor calidad en la información

2. Modelo de Gestión:

• Se empleará el ciclo de Deming (PDSA) de mejora continua para la definición de roles
• Se incorporará los elementos más adecuados de “Programación Extrema” 
• Se tendrá énfasis en el análisis, en los registros y en la estrategia de datos.
• Se capacitará en el empleo de este modelo de gestión

3. Capacitación de personal:

• Se realizará una reunión de capacitación diaria de 30 minutos con todo el personal de sistemas a fin de homologar conceptos del negocio
• Se evaluará la capacitación en nuevas herramientas

La situación se revirtió. Ya no nos comprometíamos con tiempos irreales, aumentó la confiabilidad y la calidad de la información radicalmente. La mejora fue casi inmediata. Se inició el programa de capacitación en reglas del negocio y el "modelo de clases" al que estábamos migrando, la motivación del personal aumentó y se pudieron tomar mejores medidas más adelante.

Aún recuerdo el primer día que adoptamos este Plan de Acción, el líder usuario, que era muy exigente, pedía que le den una fecha en ese instante... y la respuesta era "déjanos revisarlo y en 24 horas te daremos una fecha", a lo que respondía quejándose con el Director de Sistemas Corporativo, quién le decía "pos hombre, déjalos que revisen" ;)