A medida que los CIO reconsideran el rol de TI en la empresa, liderar o facilitar el cambio empresarial es un aspecto fundamental. El área de TI puede y debe recuperar el centro del escenario; aquí presentamos una alternativa.

En las décadas de 1970 y 1980, TI era el impulsor reconocido del cambio comercial, aunque bajo el nombre de “procesamiento de datos”, seguido de “sistemas de información de gestión”, y luego por “sistemas de información”.

Después de haber automatizado la contabilidad general, los programadores de TI y sus amistosos suplicantes (gerentes comerciales que viven bajo presión constante para reducir costos) atacaron los procesos comerciales para automatizarlos con júbilo.

La diversión duró hasta que Joseph Juran inventó el llamado “cliente interno” y se evaporó el papel de liderazgo de TI para ayudar a la empresa y a todos en ella a ser más efectivos.

En su lugar, TI, en su papel de “área proveedora”, envió a sus emisarios analistas comerciales para averiguar qué querían estos clientes internos de los productos que estaban comprando de TI.

Fue entonces cuando todos caímos de cabeza en la perdición.

Entonces, los analistas de negocios en organizaciones de TI de la vieja escuela, de la era industrial y centradas en el cliente interno preguntaron a los gerentes de negocios cuáles eran sus requisitos, es decir, qué necesitaban que hiciera una aplicación.

Los gerentes de negocios de la era industrial de la vieja escuela se esforzaron por proporcionar respuestas útiles, aunque a sus oídos la pregunta sonaba como: “Explíquenos los roles de la materia oscura y la energía oscura para evitar que el universo se separe”.

¿Puede ver el problema? Se suponía que los gerentes comerciales no eran expertos en lo que el software puede hacer. La pregunta que querían responder, si tan sólo el analista de negocios la hubiera hecho, era: “¿Cómo quiere que su parte del negocio funcione de manera diferente y mejor?” seguido de “¿Le gustaría algo de ayuda para averiguarlo?”

El hecho de que TI no hiciera las preguntas correctas condujo a su triste transición de líder del cambio comercial a la desalentadora perspectiva de proveedor a cliente interno que continúa distorsionando nuestra industria.

También condujo al surgimiento de metodologías de optimización de procesos comerciales que prometían a los gerentes de negocios una ruta para hacer que su parte del negocio funcionara de manera diferente y mejor, sin tener que involucrar a TI.

Claro, los gerentes comerciales, alentados por los “cinturones” de optimización de procesos comerciales y respaldados por un montón de hojas de cálculo que los usuarios comerciales crean cuando “la TI que necesitan no es la TI que tienen”, pueden mejorar los procesos comerciales a futuro.

Pero no podrán mejorarlos bien si el área de TI se integra en la optimización de procesos comerciales.

¿Cómo lograrlo entonces? Comience con una imagen clara de para qué sirven las principales metodologías de optimización de procesos comerciales. Entonces, y sólo entonces, podrá mejorarlos.

Dé sentido a las metodologías de optimización de procesos

Cuatro metodologías han llegado a dominar los esfuerzos de optimización de procesos comerciales: Lean, Six Sigma, Teoría de las Restricciones (Theory of Constraints) y Reingeniería de Procesos de Negocio (Business Process Reengineering). Para tener éxito en el mundo digital actual, cada una de estas metodologías debe formar parte de los analistas de negocios de TI.

Lamentablemente, estas metodologías se han convertido en escuelas de pensamiento en competencia (¡elige la mía!) que evolucionaron hasta convertirse en religiones (¡la mía es mejor que la tuya!). Es tan sensato como discutir qué funciona mejor: un destornillador, unos alicates, un soldador o un torno.

Por eso los consultores respondemos tantas preguntas con la palabra “depende”.

Cuando se trata de apoyar el cambio empresarial, la respuesta “depende” equivale a elegir la metodología más adecuada, no la metodología en la que el analista de negocios tiene más experiencia.

Pero, por otro lado, la idea de ganar experiencia en varias de estas metodologías, puede parecerle demasiado intimidante como para molestarse en hacerlo. Elegir una de ellas para aplicarla en todas las situaciones y vivir con sus limitaciones es comprensiblemente tentador.

Pero antes de elegir alguna, tenga en cuenta las seis dimensiones de la optimización de procesos: costo fijo, costo incremental, tiempo de ciclo, rendimiento, calidad y excelencia (para refrescarse, eche un vistazo rápido a artículo “La dura verdad sobre el éxito de los procesos de TI ”) Debe mantener éstas en el centro del escenario, porque sólo puede optimizar no más de tres de ellas; las que elija tienen compensaciones, y cada metodología está diseñada para optimizar diferentes dimensiones del proceso.

Veamos en qué consiste cada una:

Lean

El enfoque central de Lean es reducir el desperdicio, lo cual significa minimizar el costo incremental. Lean también puede brindar otros beneficios, como mejorar la calidad y reducir el tiempo del ciclo, pero sólo en la medida en que no afecten la reducción de desperdicios.

Los defensores de Lean se apresurarán a señalar que también enfatiza la mejora continua. Y con razón. Sólo tenga en cuenta que Lean equipara la mejora con menos desperdicio.

Si el desperdicio es su problema, Lean es justo lo que necesita.

Six Sigma

Six Sigma es la heredera de la gestión de la calidad total. Su propósito es reducir la variación, lo cual logra al identificar y abordar las causas fundamentales de la variabilidad: las razones por las que los resultados del proceso no son idénticos y no cumplen con las especificaciones.

El enfoque de Six Sigma es mejorar la calidad. En la medida en que las salidas defectuosas se descarten o se canalicen nuevamente al proceso para su corrección, Six Sigma puede, como beneficio adicional, reducir también el costo incremental.

Pero en esencia, Six Sigma es su elección si la calidad es lo que más le importa. De lo contrario, puede resultarle decepcionante.

Teoría de las Restricciones

Theory of Constraints o ToC es la mejor metodología de optimización de procesos de la que pocos han oído hablar. Lo cual es lamentable.

Inventada por el ex físico Eliyahu Goldratt, ToC asume que su problema es un rendimiento insuficiente y que su proceso tiene cuellos de botella (restricciones) que lo limitan. Acelere o elimine los cuellos de botella del proceso y aumentará el rendimiento, es decir, la capacidad, y reducirá el tiempo del ciclo en el trato.

Si usted tiene deficiencias en un proceso empresarial y no puede satisfacer la demanda, busque ayuda en la Teoría de las restricciones.

Y aunque no forme parte de la doctrina oficial de ToC, usted puede aplicar el ciclo fundamental de ToC: encontrar cuellos de botella, corregir cuellos de botella, enjuagar y repetir a cualquier objetivo de optimización de procesos que decida que es más importante. No tiene que ser un cuello de botella de capacidad.

Reingeniería de procesos de negocio

Reengineering the Corporation, escrito por Michael Hammer y James Champy, fue el libro que enfocó a los líderes empresariales en la importancia de los procesos bien diseñados. El punto focal para la Reingeniería de Procesos de Negocios (BPR) es que el lugar correcto para comenzar es una hoja de papel en blanco.

Entonces, donde Lean, Six Sigma y la Teoría de las Restricciones buscan los pocos pasos de proceso incorrectos que causan el mayor daño y los corrigen para reducir el desperdicio, los defectos o los cuellos de botella, el impacto principal de BPR parece maximizar las horas de facturación de los consultores.

Pero esto no es del todo cierto: hay situaciones en las que BPR es su única opción, por ejemplo, cuando está subcontratando un proceso comercial previamente subcontratado.

Pero de las cuatro metodologías dominantes de optimización de procesos, BPR es la más riesgosa.

Una quinta opción

Si bien Lean, Six Sigma, ToC y BPR son las principales metodologías preferidas para la optimización de procesos de negocios, los grupos de TI que desean liderar esta mejora tienen otra alternativa disponible: ofrecer flujos de procesos integrados en aplicaciones comerciales como puntos de partida lógicos.

Y aunque los procesos integrados de una aplicación facilitan tanto la integración inicial como el mantenimiento continuo para TI, esto no es sólo una repetición del viejo y cansado argumento de “¿vainilla simple o chispas de chocolate?” que tan a menudo descarrila las implementaciones de aplicaciones.

El problema de discutir sobre las variedades de helados era… es… que son argumentos sobre si TI o “el negocio” se sale con la suya.

Pero como no existe tal cosa, un área de TI no debería permitirse discutir sobre qué tipo de software usar.

Si usted sigue el diseño de la aplicación propuesto por el proveedor también tiene un beneficio comercial adicional: nadie tiene que diseñarlo.

Además, se trata de una solución viable para comenzar a aplicar Lean, Six Sigma o ToC si no es lo suficientemente bueno desde el primer momento. Usted tiene la palabra.

Bob Lewis, CIO.com