[16/11/2019] Lo siguiente ha sido extraído del manual titulado There's No Such Thing as an IT Project: A Handbook for Intentional Business Change.
Para tener éxito en la era digital, los proyectos de TI deben redefinirse para ofrecer cambios en el negocio en lugar de solo productos de las tecnologías de la información. Pero debajo de esto yace un cambio más fundamental: las operaciones de TI deberían estar integradas en las operaciones del negocio de la misma forma en que las aplicaciones de TI deberían estar tan integradas en lograr el cambio del negocio.
En muchas organizaciones, TI se ejecuta como si fuera un negocio separado: un proveedor de servicios para sus clientes internos. Desafortunadamente, hacerlo crea una disfunción, tanto para las aplicaciones como para las operaciones de TI.
Parte de esto se debe a que la metáfora de 'TI como negocio' ha llevado a una práctica extraña: acuerdos de nivel de servicio (SLA, por sus siglas en inglés) negociados entre las operaciones de TI y sus clientes internos.
En los términos reales del outsourcing de TI, un SLA es una métrica entre dos partes. La primera parte es el nivel mínimo aceptable de servicio. La segunda parte enumera con qué frecuencia el subcontratista tiene que alcanzar ese nivel de servicio.
Frecuentemente, definir la primera parte de la métrica es trivial. La segunda parte, sin embargo, es más interesante. Por ejemplo, un SLA podría definir el estándar máximo aceptable para un corte de energía en una hora o menos antes de la restauración del servicio. La segunda mitad de la métrica podría especificar que el subcontratista debe alcanzar este nivel de servicio para el 99% de todos los cortes.
Si el subcontratista no cumple con sus SLA, el contrato especifica correcciones, que también son objeto de negociación. Si se supone que la TI interna debe actuar como un negocio independiente, ¿qué podría ser más lógico que negociar acuerdos de nivel de servicio con sus clientes internos?
Resulta que la respuesta es: muchas alternativas son más lógicas.
El desafío de la innovación
Los SLA internos nunca fueron una buena idea por varias razones. Primero, refuerzan el modelo de la relación entre TI y el negocio de forma incorrecta -el de la venta de TI como negocio a los clientes internos.
La segunda razón es una consecuencia de la diferencia: si TI no logra un SLA negociado, ¿qué harán sus "clientes”? ¿demandar? Los SLA sin penalizaciones por incumplimiento son inútiles. Los SLA con penalizaciones por incumplimiento fomentan la desconfianza entre las organizaciones.
La tercera es el hecho de que uno tiene lo que mide. En la mayoría de los casos, esto significa que TI mide los niveles de servicio, pero carece de cualquier métrica para la innovación.
Las operaciones de TI bien administradas se equilibran constantemente entre confiabilidad e innovación. Pero la innovación conlleva riesgos. Debido a que los SLA miran hacia atrás, solo informan las consecuencias negativas de la innovación, no sus beneficios.
Tome la conversión inicial a discos duros de estado sólido. Su fiabilidad a corto plazo y durabilidad a largo plazo fue, para los primeros usuarios, no comprobada. Sin embargo, pagaron generosamente a las organizaciones que los probaron, dándoles una ventaja de desempeño en analítica y big data.
Mantenerse a la vanguardia requiere cierta toma de riesgos y visión de futuro que los SLA, por naturaleza, desalientan.
El caso contra los SLA
Generalmente, TI asume dos tipos de responsabilidad: servicios técnicos y servicios de soporte.
Los SLA para servicios técnicos se relacionan con asuntos tales como la disponibilidad y el desempeño del sistema. ¿El problema? Érase una vez, las arquitecturas de alta disponibilidad eran una opción. Ahora no lo son.
¿Debería TI seguir los niveles de servicio para los servicios técnicos? Sí, si no le está yendo muy bien, pero solo como una herramienta para llegar a donde el seguimiento continuo sería una pérdida de tiempo.
Porque, si bien un determinado equipo puede fallar, ya no es una razón para que los sistemas estén fuera de servicio. Esa es la naturaleza de las arquitecturas de alta disponibilidad. Si un sistema alguna vez no está disponible, ese debería ser un evento lo suficientemente raro, que llevar un registro estadístico es una pérdida de tiempo.
Lo que no será una pérdida de tiempo es un análisis de la causa raíz, porque cada interrupción significa que su arquitectura de alta disponibilidad tiene un defecto de diseño que debe repararse. Lo que tampoco es una pérdida de tiempo es analizar los incidentes reportados para detectar y abordar los problemas emergentes de manera temprana, antes de que sean detectables para el negocio en general.
Los servicios de soporte, por otro lado, son lo que el personal de TI hace para ayudar a quienes trabajan en las operaciones comerciales. Los SLA de los servicios de soporte se relacionan con preguntas como 'cuánto tiempo debería esperar alguien antes de que el servicio de asistencia responda a su solicitud' y 'cuánto tiempo deben esperar hasta que se resuelva el problema'.
En cualquier día, para cualquier llamada, la mesa de ayuda responde más rápido, o menos rápido, de lo que especifica el nivel de servicio. Esta responde más rápido cuando la capacidad del personal de la mesa de ayuda supera el volumen de llamadas. Esta responde con menor rapidez cuando el volumen de las llamadas excede la capacidad del personal de la mesa de ayuda.
Por tanto, el SLA no tiene nada que ver con el desempeño. Es solo un palo que es útil para golpear al administrador de la mesa de ayuda y no mucho más.
El único momento en el que realmente importa es en la temporada de presupuesto, cuando el desempeño del nivel de servicio de la mesa de ayuda se puede utilizar para justificar la contratación de más personal.
Para ser justos, esto no es poca cosa. Pero justifica la práctica de hacer seguimiento del desempeño del servicio, no de negociar los SLA.
La única métrica de operaciones de TI que importa
Para la mayoría de las personas en gerencia, el éxito aumenta su visibilidad, lo que puede conducir a promociones, elogios y mejores salarios. La única vez que las operaciones de TI son visibles es cuando algo sale mal.
Todas las buenas métricas son representaciones numéricas de objetivos cualitativos. Por lo tanto, la métrica de operaciones de TI que mejor refleja sus objetivos es una medida de su invisibilidad. Este "índice de invisibilidad” debería ser una métrica compuesta que abarque la disponibilidad y el desempeño de la aplicación, la cantidad de llamadas a la mesa de ayuda (menos llamadas significa más invisibilidad) y alguna medida que refleje con qué frecuencia el desempeño de las operaciones de TI es un cuello de botella en los negocios, procesos y prácticas en otras áreas.
Las organizaciones de TI típicas se dividen en aplicaciones y operaciones, apps y ops, grupos que tradicionalmente desconfían entre sí por dos razones principales. Primero, apps tiene éxito al hacer cambios en la aplicación, pero cada cambio de aplicación crea un riesgo de mayor visibilidad para ops. En segundo lugar, apps necesita a ops para crear y mantener ambientes de desarrollo y prueba. Para apps, esto significa que ops es un cuello de botella. Para ops, esto significa trabajo adicional y, a menudo, no programado.
Incluya DevOps. A diferencia de la mayoría de las variantes de la metodología ágil, con DevOps, los equipos de desarrollo incluyen uno o más empleados de operaciones de TI para manejar en colaboración las responsabilidades de operaciones de TI, dentro del cronograma del proyecto, en lugar de a través de una cola de solicitud de operaciones.
Todo esto es para afirmar que, cuando hay fricción o desconfianza entre dos grupos que deben trabajar juntos, crear una combinación colaborativa de personal y procesos bajo la procedencia de cada grupo es una solución que vale la pena.
Transformación digital y el advenimiento de BusOps
Para la mayoría de las organizaciones en estos días, la transformación digital es el ritmo de la gestión. Pero ¿ha habido alguna vez una tendencia administrativa más confusa y ambigua que la transformación digital?
Detrás de toda la ambigüedad, existen tecnologías digitales específicas que crean nuevas capacidades. Las empresas pueden aprovecharlas para crear una ventaja competitiva. O bien, pueden ignorarlas, dejando que los competidores obtengan la ventaja.
La realidad digital central se encuentra detrás de los detalles: TI ya no es opcional. Es un área profundamente integrada en todos los procesos y prácticas de negocio en las que se basa su empresa para hacer negocios a diario. Como consecuencia, conceptualmente, las operaciones de TI son solo una colección de partes móviles entre muchas de las operaciones comerciales generales, lo que convierte al área en jurisdicción tanto del COO como del CIO.
Antes de que se nos adelante, como cuestión práctica, a donde sea que reporte, las operaciones de TI deben permanecer intactas. Su eficacia -y la invisibilidad consecuente- depende de la colaboración continua de una serie de especialistas técnicamente competentes, practicantes de disciplinas maduras y bien desarrolladas.
La gestión de los procesos y prácticas de los que son responsables depende, a su vez, de los gerentes que entienden su funcionamiento interno. Liderarlos depende de gerentes que puedan tener empatía con estos profesionales a medida que manejan sus responsabilidades.
También vale la pena reconocer que las reorganizaciones rara vez arreglan algo. En su mayoría, eliminan las barreras al poner a los grupos -que antes no funcionaban bien juntos- bajo una gestión común. Esto también significa que la mayoría de las reorganizaciones crean barreras entre los grupos que solían tener una gestión común, pero que ya no lo hacen.
Mover las operaciones de TI en el organigrama, para que le reporte al COO, no es ni más ni menos lógico que no mover nada. En cuanto a la reestructuración de las operaciones de TI, dividir y repartir sus responsabilidades dentro del negocio simplemente no funcionará. Sigue habiendo valor en las personas técnicas que trabajan juntas en problemas comunes.
¿Qué necesita cambiar? DevOps señala el camino. La cultura de la colaboración DevOps tiene que extenderse a la relación entre las operaciones de TI y el resto de las operaciones del negocio, al igual que lo hace entre los gerentes de negocios que desean una mejor administración y las aplicaciones de TI.
Libere al personal de su mesa de ayuda. Sin los SLA que los encadenan a sus sillas, puede alentarlos a levantarse y visitar a alguien que tenga un problema, conocer cuáles son sus desafíos y ofrecer información sobre cómo pueden aprovechar las tecnologías a su disposición.
Mientras tanto, en el lado ops de TI, la metodología ágil requiere de enmendaduras, ya que no existe algo así como un proyecto de TI: la metodología ágil, tal y como se practica actualmente, todavía se enfoca en entregar un producto y no en colaborar para lograr un cambio intencional en el negocio. A medida que repare la metodología ágil, hágalo agregando la dimensión DevOps de incluir administradores de sistemas y seguridad en los equipos de proyectos del cambio en el negocio. Sus proyectos tendrán mejores resultados, y el conocimiento adicional de lo que importa en las áreas de negocios hará que las operaciones de TI sean más efectivas en su toma de decisiones cotidiana.
Entonces, introduzcamos un nuevo término para hacerlo oficial. Así como DevOps es la combinación y colaboración de apps de TI y ops de TI, comencemos a hablar de BusOps como la combinación y colaboración de las operaciones de TI y las operaciones del negocio.
La batalla, según Sun Tzu, es siempre para los corazones y las mentes. Eso a menudo comienza con un vocabulario. Al agregarlo, es posible que se sorprenda -positivamente- de lo que se obtiene.
Bob Lewis, CIO
Bob Lewis es un alto directivo y consultor de TI en una de las principales empresas de servicios de TI a nivel mundial. Las ideas y opiniones expresadas en esta columna, sin embargo, son estrictamente suyas. También se le puede encontrar en su blog, Keep the Joint Running