Creación de una TI eficaz al 101%: ¿Quiere usted diseñar e implementar procesos de TI eficaces? Entonces debe establecer estos cuatro fundamentos antes de que pueda siquiera comenzar.

La clave para dirigir una organización eficaz, nos han dicho durante décadas, es entregar productos de trabajo a través de procesos bien diseñados y administrados. El proceso es aclamado como el camino hacia el nirvana organizacional, en forma de resultados repetibles y predecibles.

Pero los CIO que inician iniciativas de proceso diseñando procesos y capacitando al personal en su uso son similares a los estudiantes de matemáticas que se inscriben en cálculo diferencial sin aprobar primero álgebra y trigonometría. Para tener éxito en cualquier disciplina, primero se deben dominar los requisitos previos.

Para que cualquier iniciativa de proceso tenga éxito, existen, de hecho, cuatro requisitos previos: (1) una cultura de proceso; (2) una comprensión clara de la diferencia entre procesos y prácticas; (3) la capacidad de diseñar, gestionar e interpretar métricas de procesos; y (4) confianza entre todos los involucrados en la ejecución de los procesos.

Sin estos requisitos previos, ninguna iniciativa de proceso, ya sea una gestión de servicios de TI basada en ITIL, un ciclo de vida de desarrollo de sistemas estandarizados o un manual de fusiones y adquisiciones de TI, puede tener éxito. Ponga estos cuatro fundamentos en su lugar y el éxito es casi inevitable.

Cultura de proceso

“Cultura” es un término que se pronuncia con mucha más frecuencia de lo que se define. Para fines comerciales, piense en la cultura como la forma en que hacemos las cosas aquí. Es el conjunto de creencias y suposiciones compartidas que intervienen en las decisiones y los hábitos de trabajo de todos los empleados de una organización.

Si una organización de TI tiene una cultura de procesos, entonces, sin importar la situación que enfrenten los empleados, improvisarán sólo cuando se enfrenten a una situación para la cual no se ha definido ningún proceso o procedimiento estándar y documentado. Y cuando improvisan, documentarán lo que se les ocurrió, sus resultados y las posibles mejoras que se pueden incluir en caso de que surja una situación similar en el futuro.

Eso contrasta con una cultura construida alrededor de la premisa de que “Somos personas inteligentes. Lo resolveremos”. No es que tener la confianza para descubrir cómo manejar algo inesperado sea intrínsecamente malo. Es sólo que cuando los empleados comienzan a descubrirlo desde cero, están expresando la opinión subrepticia de que son más inteligentes que el último grupo de empleados que tuvieron que resolver lo mismo, posiblemente que son más inteligentes que todos los que alguna vez se han enfrentado a una situación similar a la que nos ocupa.

Intrínseco a las organizaciones que tienen éxito a través de procesos bien definidos es la actitud de que todos los involucrados, todo el tiempo, son responsables de perfeccionar constantemente “cómo hacemos las cosas aquí”.

Procesos vs. prácticas

Un proceso es un conjunto de tareas, ejecutadas de acuerdo con una secuencia y un flujo definidos, que produce resultados repetibles y predecibles. Los procesos son recetas: siga las instrucciones con precisión y no podrá evitar producir una deliciosa, digamos, paella.

Las organizaciones creadas para depender de procesos están, como dice el refrán, “diseñadas por genios para ser dirigidas por idiotas”, aunque “idiotas promedio”, aunque menos contundente, describe mejor a las personas que terminan haciendo el trabajo real que “idiotas”. y muchos de los diseñadores de procesos no siempre son material de Mensa.

Como la oferta de idiotas promedio generalmente excede la disponibilidad de genios, el modelo de recetas no es una mala opción para muchas situaciones comerciales.

Pero no todas las situaciones se prestan a recetas. El litigio es un ejemplo: los abogados que ejecutan exactamente los mismos pasos de la misma manera en todas las demandas es poco probable que ganen los casos cuando se oponen a un oponente más imaginativo que es un mejor juez de qué candidatos al jurado tienen más probabilidades de simpatizar con la causa de su cliente. , y quién es más imaginativo en el desarrollo de narrativas convincentes que puedan persuadir a los miembros del jurado.

Por eso nos referimos al derecho como una práctica, no como un proceso.

En TI, gran parte de lo que hacemos se ajusta al modelo de proceso, por ejemplo, la creación de un entorno de prueba.

Mucho, eso es, pero lejos de todo. Toma la gestión de proyectos. Sigue una serie de pasos, pero eso no significa que realizar cada paso de la misma manera en todos los proyectos sea una buena idea.

La gestión de proyectos implica demasiadas variables para cualquier enfoque basado en recetas de talla única: diferentes patrocinadores responden de manera diferente a los riesgos y problemas que surgen en el curso de un proyecto y, por lo tanto, los riesgos y problemas que surgen difieren de proyecto a proyecto. Lo mismo puede decirse del equipo central del proyecto (no hay dos equipos que tengan las mismas fortalezas y dinámicas internas) sin mencionar las pymes y los usuarios comerciales que componen el equipo del proyecto ampliado.

Ah, y lo que se supone que deben producir los diferentes proyectos, ya que sus productos de trabajo tampoco es uniforme: los rascacielos son fundamentalmente diferentes de los portaaviones, que tienen poco en común con las plataformas de PowerPoint o los análisis de costo / beneficio.

El propósito de todas las “funciones comerciales”, término colectivo para procesos y prácticas, es convertir las entradas en salidas. Los procesos dependen de qué tan bien los que hacen el trabajo del proceso siguen los pasos de la tarea al pie de la letra. Las prácticas dependen del conocimiento profundo, la experiencia y el juicio de los profesionales.

Comprender esta división básica y fundamental evitará que los CIO caigan en la trampa de intentar usar recetas cuando simplemente no se ajustan a la situación.

También vale la pena señalar que el proceso frente a la práctica no es una elección binaria. Son más los polos de un continuo de posibilidades. Algunas funciones comerciales se asemejan más a procesos; otros son más parecidos a la práctica, pero pocos son puramente uno u otro.

Al final, los procesos y las prácticas son herramientas diferentes e igualmente valiosas para lograr que una organización de TI (y, para el caso, no TI) realice el trabajo. Utilice el adecuado para el trabajo en cuestión.

Métrica

Si no puede medir, dice el viejo refrán, no puede administrar. Ignora la Ley de las malas métricas de Lewis, que establece que obtienes lo que mides, por lo que si, mides mal, administras mal.

La definición de métricas para ayudarlo a comprender si una función comercial es saludable o necesita una puesta a punto requiere conocimiento y rigor.

Lo que sigue es una sinopsis demasiado breve de un tema complejo:

Métricas de optimización de procesos

Los gerentes pueden optimizar un proceso para no más de tres de estas seis dimensiones:

• Costo fijo: las inversiones únicas necesarias para crear los sistemas y la infraestructura que el proceso necesita para funcionar.
• Costo incremental (también conocido como marginal): el costo adicional de procesar una sola transacción. El costo incremental no incluye los costos fijos amortizados.
• Tiempo de ciclo: el tiempo necesario para procesar una sola transacción, para convertir las entradas en una única salida.
• Rendimiento (también conocido como capacidad): el número de resultados que la función empresarial puede ofrecer en una unidad de tiempo determinada.
• Calidad: Cumplimiento de especificaciones; alternativamente la ausencia de defectos.
• Excelencia: Flexibilidad; la capacidad de adaptarse a situaciones inusuales y de adaptar o personalizar.

La definición de métricas para un proceso o práctica comienza por decidir qué dos o tres de estas dimensiones de optimización son más importantes. Estos son los que hay que medir. Solo obtiene dos o tres porque la optimización para esos invariablemente requiere compensaciones con las dimensiones restantes.

Olvídese de los acuerdos de nivel de servicio (SLA)

Los SLA son una forma popular pero equivocada de medir las funciones comerciales.

Los niveles de servicio son métricas de dos partes. Definen (1) el umbral mínimo de desempeño aceptable y (2) el porcentaje de ocurrencias que deben cumplir con ese umbral.

Por ejemplo, para los incidentes de nivel uno, el gerente de la mesa de servicio puede decidir que el tiempo del ciclo es la dimensión de optimización más importante para la primera parte de la métrica, estableciendo un tiempo para la respuesta inicial de 5 minutos y un tiempo para resolver de una hora como umbrales mínimos de desempeño aceptable. Para la parte dos, el 95% o más de los incidentes de nivel uno deben cumplir con los umbrales establecidos en la parte uno.

Los SLA son un mal necesario en los contratos de subcontratación porque tanto la empresa contratante como el subcontratista necesitan saber si el desempeño se adhiere a los requisitos contractuales.

Pero para la gestión de funciones empresariales, las métricas de la vieja escuela de media y desviación estándar son mucho más útiles.

Confianza

En mi libro Keep the Joint Running: A Manifesto for 21st Century Information Technology, presenté el “ciclo de desconfianza del proceso”. Éste nos muestra, de manera semi-satírica, las consecuencias prácticas de la desconfianza: cuando se ejecuta un proceso, en cada paso del camino, la desconfianza hace que la persona o el grupo que recibe el trabajo en progreso asuma que es defectuoso en algún aspecto. Eso conduce a quejas, retrabajo, retrasos, desperdicio y malestar general

Y, como beneficio adicional, desconfianza adicional.

Con confianza, incluso los procesos mal diseñados pueden fluir sin problemas. Sin él, ningún proceso tiene la posibilidad de producir los resultados esperados.

En conclusión

Estos cuatro pilares: una cultura de procesos, reconocimiento de las diferencias entre procesos y prácticas, la capacidad de definir y realizar un seguimiento de las métricas adecuadas y, sobre todo, la confianza entre todos los involucrados, marcan la diferencia entre una organización de TI que hace el trabajo y uno que nunca parece entregar la mercancía.

Bob Lewis, CIO.com