¿Qué hace que las organizaciones de TI fracasen? A menudo, se trata de la adopción de lo que se describe como “mejores prácticas de la industria” por parte de personas que deberían saber más, pero no lo saben, probablemente porque nunca han tenido que hacer el trabajo.
Desde establecer clientes internos hasta instituir devoluciones de cargos e insistir en el retorno de la inversión, muchos de estos consejos parecen plausibles cuando se ven desde 5,000 metros de altura o más. Sin embargo, si usted rasca la superficie, comenzará a descubrir que estas recetas infalibles para el éxito de TI son a menudo recetas para el fracaso.
1. Decirle a todos que son sus clientes
¿Busca fracasar? Bueno, asegúrese de que todos en TI le digan a todos los que están fuera de TI: “Usted es mi cliente. Mi trabajo es superar sus expectativas” (o, peor aún, “hacerle feliz”).
Los empleados ajenos a TI no son clientes de TI. Son colegas de TI, con quienes TI colabora como iguales.
Y es que, a medida que lo “digital” se ha generalizado, la tecnología de la información se ha vuelto omnipresente, incrustada en casi todos los rincones de la empresa. Es por eso que los líderes empresariales inteligentes han perdido la paciencia con toda la metáfora del cliente interno. Han descubierto que la organización de TI es una parte tan integral del negocio como la propia tecnología de la información es parte integral de los productos y servicios de la empresa.
2. Establecer SLA y tratarlos como contratos
¿Quieres hacer algún daño? Establezca acuerdos formales de nivel de servicio , insista en que sus “clientes internos” los firmen y trate estos SLA como contratos.
Y si realmente desea que TI falle, discuta si ha cumplido con sus SLA cada vez que un “cliente interno” (ahí está esa palabra nuevamente) sugiera que TI no está haciendo lo que necesita que haga. Es una excelente manera de mantener las relaciones a distancia.
Ah, y si TI no ha cumplido con sus SLA, ¿qué se supone que debe hacer su “cliente interno”? ¿Demandar?
Si prefiere el éxito, entonces recordará que las relaciones requieren confianza, que la confianza no surge a menos que reconozcas a tus colegas como personas reales, que si les agrada, trabajarán con usted para arreglar cualquier problema que salga mal y que el propósito de los contratos no es definir las relaciones, sino explicar lo que sucede cuando no hay confianza y algo sale gravemente mal.
Ah, y por cierto, después de COVID, grandes sectores de la fuerza laboral se volvieron virtuales, lo que a su vez significa que grandes sectores de la fuerza laboral dependen de ISP comerciales de consumo para su infraestructura de red.
Lo que a su vez significa que muchos de los SLA de TI ya no son algo en lo que TI pueda influir, y mucho menos controlar.
3. Instituir devoluciones de cargo
He aquí una excelente manera de desalentar el uso de la tecnología de la información: Instituir devoluciones de cargos. Tienes dos alternativas. El primero detalla cuidadosamente cada tipo de costo en el que ha incurrido cada centro de costos, desde ciclos de CPU hasta almacenamiento SAN y NAS (sepárelos, por supuesto), horas de desarrollador y llamadas al servicio de asistencia técnica facturadas en incrementos de 10 minutos.
Nada fomenta más la colaboración que discutir sobre la exactitud de las facturas que determinan en qué bolsillo corporativo debe guardarse el dinero.
El segundo tipo de contracargo toma el gasto total en TI de la empresa y lo distribuye en toda la empresa per cápita, por lo que no queda nada de qué discutir. Tampoco tiene sentido.
4. Insista en el retorno de la inversión
Claro, es maravilloso cuando un proyecto propuesto genera por sí solo un retorno financiero positivo de la inversión. Pero a medida que la TI se ha vuelto omnipresente y omnipresente, integrada en todo lo que hace la empresa, la moraleja de la historia del retorno de la inversión es que hay que poner patas arriba la antigua forma de pensar sobre las decisiones de TI: la tecnología de la información ya no se aprueba caso por caso.
Lo que necesita aprobación caso por caso es hacer las cosas manualmente. La automatización es lo que se supone.
5. Proyectos chárter de TI
¿Quiere una fórmula para la disfunción empresarial/TI? Defina los proyectos en términos de entrega de software, de modo que el trabajo de TI esté terminado cuando el software satisfaga los requisitos y cumpla las especificaciones.
De esa manera, cuando la gerencia empresarial se queja de que el software no hace lo que necesitan, usted está en una posición perfecta para argumentar que hace exactamente lo que “la empresa” dijo que debería hacer, porque cumple con las especificaciones, no ¿no es así?
Nuevamente: la TI se ha vuelto omnipresente. Eso no significa sólo que todo el mundo utilice los productos de TI. Significa que todos los que utilizan los productos de TI piensan en términos de utilizar la tecnología de la información para hacer que su parte de la empresa funcione de manera diferente y mejor.
6. Asignar patrocinadores del proyecto
Es bien sabido en los círculos de gestión de proyectos que cada proyecto debe tener un patrocinador empresarial o tendrá pocas posibilidades de tener éxito. ¿Pero quiere asegurarse de que un proyecto fracase? Asigna uno.
Los patrocinadores (patrocinadores reales, no SINO (“patrocinadores sólo de nombre”)) quieren que su proyecto tenga éxito en lo más profundo de sus entrañas, están dispuestos a asumir riesgos si es necesario para asegurarse de que sus proyectos tengan éxito y arriesgan sus nombres y reputaciones con respecto a los beneficios empresariales de sus proyectos. ¿Crees que alguien a quien se le ha asignado como patrocinador hará esas cosas? Yo tampoco.
7. Duplique su estrategia de computación en la nube
La computación en la nube no es una estrategia. Eso supone asumir la conclusión (que cada aplicación debe ejecutarse en la nube) en lugar de tomar una decisión sobre su arquitectura técnica.
Una arquitectura técnica bien definida debe definirse en términos de servicios. Los servicios son lo que necesitas. Claro, la nube podría ser una buena manera de aprovisionar algunos de ellos. ¿Todos ellos? Tal vez tal vez no.
Es una vieja regla: la forma sigue a la función. Los servicios de TI son las funciones. La nube es una forma que podrían adoptar algunos de sus servicios necesarios.
8. Sea ágil. Ir al extranjero o hacer ambas cosas al mismo tiempo
Las metodologías ágiles tienen mucho que ofrecer. Un requisito previo para el éxito es un alto nivel de participación informal del usuario, de modo que las correcciones de rumbo sean frecuentes y pequeñas, los desarrolladores vean el progreso todos los días y las pruebas de aceptación de los usuarios sean algo cotidiano.
Offshore tiene una cosa a su favor: un menor costo de mano de obra por hora. Lo que no tiene a su favor es ninguna posibilidad del alto nivel de participación informal de los usuarios del que depende Agile. Combine una diferencia de 12 zonas horarias, barreras lingüísticas, un abismo cultural e interacciones limitadas a lo que se puede manejar con conferencias web, y Agile es todo un desafío.
Es posible hacerlo funcionar, pero no es para personas débiles de corazón y ciertamente no es para organizaciones de TI que son principiantes en Agile.
¿Quiere ser ágil? ¿Quiere ir al extranjero? Elija una cosa.
9. Interrumpir las interrupciones con interrupciones
El siguiente paso para asegurar el fracaso de TI es insistir en que todos realicen múltiples tareas. Después de todo, es una habilidad muy deseable, ¿verdad?
Equivocado. Lo que realmente logra la multitarea es reducir la productividad y la calidad y, al mismo tiempo, aumentar el estrés en el intento de hacer más cosas.
Siempre que tenga la tentación de pedirle a alguien que deje lo que está haciendo para trabajar en otra cosa, recuerde: los seres humanos no realizan múltiples tareas. Lo mejor que pueden hacer es ir y venir de una tarea a otra. Cada vez que lo hacen, pierden el tiempo cambiando de marcha mental. Cuanta más concentración requiere una tarea, más tiempo pierden cuando es necesario.
¿Quiere que TI tenga éxito? Deje que la gente termine lo que está trabajando antes de pasar a otra cosa.
10. Haga malabarismos con muchos proyectos
TI nunca tiene suficiente personal para manejar todo lo que todos quieren, por lo que tiene sentido hacer todo lo posible para lograrlo de todos modos, lanzando muchos proyectos y moviendo empleados de un lado a otro entre ellos.
Es decir, si desea que todos los proyectos demoren mucho más, cuesten mucho más y proporcionen resultados deficientes.
Si desea que TI desarrolle una buena reputación, establezca esta regla: cada proyecto que se lance contará con todo el personal, donde “con todo el personal” significa que el proyecto nunca esperará a que un miembro del equipo esté disponible para trabajar en él.
Haga esto y cada proyecto terminará antes de que cualquier proyecto hubiera terminado si hubiera seguido haciendo malabarismos con todos ellos.
11. Eliminar la ‘TI en la sombra’
No hay duda de que cuando los departamentos empresariales implementan su propia TI, pueden suceder cosas malas. Éste podría parecer un argumento convincente para impedirlo, pero sólo cuenta una tercera parte de la historia. El segundo tercio: los departamentos comerciales se involucran en esfuerzos de bricolaje porque TI no tiene suficiente personal para resolver los (generalmente) problemas de las pequeñas empresas que asume la TI en la sombra. Lo que coloca a TI en la incómoda posición de obligar a los departamentos comerciales a hacer todo en Excel, incluso cuando hay alternativas superiores disponibles.
Ese es el segundo tercio. ¿El tercer tercio? Buena suerte intentando acabar con la TI en la sombra. Es tremendamente difícil incluso detectar el uso empresarial de aplicaciones basadas en la nube. ¿Y si la TI logra acabar con la TI en la sombra? Lo más probable es que la funcionalidad que TI evita se convierta en un cambio de alcance para algún otro proyecto.
12. Diga no o sí sin importar la solicitud
La última y mejor manera de garantizar el fallo de TI es decir sí o no, sin importar la solicitud. Diga no y dañará sus relaciones. Diga sí y estará haciendo promesas que no podrá cumplir porque usted y todos los demás ya tienen todo su tiempo totalmente comprometido, porque siempre dice que sí.
La respuesta correcta, si quieres tener éxito, es: “Podemos hacerlo. Esto es lo que se necesitará”.
Existe una regla inviolable en la gestión de solicitudes, ya sea que la solicitud sea un cambio en el alcance del proyecto, una mejora del software o el suministro de una tableta a alguien que no está programado para recibirla: nada es gratis.
No diga que no. No diga que sí. Explique lo que tendrá que hacer para satisfacer las solicitudes. Entonces tendrá una conversación más que una discusión.
Eso será mucho mejor.
Comments