La patología de las tecnologías en fase de prueba
Haciendo que las TI funcionen
Si no es posible extender o escalar fácilmente una tecnología en prueba, conviene no molestarse siquiera en instalarla, para empezar.
Una compañía de servicios financieros mundial, con la que la mayoría mantiene relaciones, tiene un historial extraordinario con sus tecnologías en fase de prueba. Casi nunca fracasan.
Se trata de una excelente gestión de la Tecnología de la Información? Es muy probable que no. Ese historial excelente tiene un fallo: sólo una pequeña parte de esas tecnologías en prueba son desplegadas con éxito en toda la empresa. La compañía está llena de costosas implementaciones de éxito reducido: software, hardware, redes y aplicaciones que funcionan perfectamente bien en los departamentos de prueba designados, pero prácticamente en ninguna otra parte.
La mayoría de estas tecnologías en prueba –incluyendo un sistema experto de detección de fraudes, que no lo era tanto, y un data mart para gestión CRM– no duraron más de un año o dos. Y las que duraron se han convertido en objeto de permanentes batallas presupuestarias sobre quién debe pagar por ellas y realizar su mantenimiento. Una situación desagradable.
Esta patología de las Tecnologías de la Información en prueba es tan global como la innovación TI misma. Los escenarios corporativos de las grandes empresas mundiales están llenos de los restos de tecnologías en prueba que no pudieron, no fueron capaces o no debieron escalar. En realidad, demasiadas tecnologías en prueba han sido diseñada sin pensar lo más mínimo en esa posibilidad de extenderse más allá o escalar. Las compañías se concentran en hacer que sus tecnologías en prueba sean más manejables y efectivas que escalables. En otras palabras, optimizan el éxito de la tecnología piloto a expensas de optimizar el conocimiento necesario para escalar de forma económica. Así, las tecnologías en prueba se convierten en un fin, y no en un medio.
Esta disfunción económica tiene lugar por motivos totalmente lógicos. El más importante es que a nadie le gusta el fracaso. Cuando una compañía invierte dinero real y horas-hombre en una base de datos o en un sistema CRM en prueba, no desea declarar esa inversión como un gasto inútil. Así, las compañías intentan asegurarse de que la tecnología en prueba “funciona”. El departamento TI y el departamento designado harán lo necesario para garantizar que los beneficios de la tecnología en prueba superen su coste.
Lo cual conduce de forma natural al motivo siguiente: Para garantizar que la tecnología en prueba tiene éxito, el departamento TI y su departamento designado conspiran para hacer que resuelva algún conjunto específico de problemas comerciales. Estos problemas tienden a estar tan localizados y a ser tan especializados que requieren más adaptación a medida que estandarización. Adivínese lo que resulta más caro de escalar.
Al igual que la firma de servicios financieros mundial mencionada arriba, los departamentos disponen en todo el mundo de excelentes soluciones puntuales a sus problemas específicos. Sin embargo, en realidad, el enfoque adoptado por la compañía ha dado lugar a ausencias de economías de escala que han generado una inversión inútil de cientos de millones de dólares en menos de una década.
Las tecnologías en prueba que funcionan sin tener la escalabilidad como una prioridad no son proyectos de Tecnología de la Información: son simple investigación. No hay nada malo en realizar investigación sobre ofertas TI innovadoras. Sin embargo, hay que asegurarse de que las empresas vendedoras – y no los accionistas o los empleados – paguen su cuota justa por ello.
La cuestión más importante a la que se enfrentan los directores de información o CIOs que están considerando tecnologías innovadoras no es en qué medida funcionarán bien, sino ¿en qué medida escalarán bien? En lugar de preguntarse cómo hacer que la tecnología en prueba funcione mejor, el departamento TI deberá plantearse: ¿Cómo podría afectar esa sugerencia para mejorar la tecnología en prueba afectar a la forma en que podremos escalar?
En muchos casos, una tecnología puede escalar bastante bien, pero no así la forma en que sea utilizada organizacionalmente. Continuamente se sorprende uno ante departamentos TI que han resuelto los problemas de escalabilidad técnica al nivel departamental pero fracasan totalmente en apreciar – y mucho menos documentar – cuánto tiempo requirieron las personas en el departamento para dar cabida a los cambios técnicos. Por ejemplo, la tecnología de claves de criptología o “cripto keys” puede escalar bien técnicamente, pero la efectividad de sus implementaciones varía considerablemente. Algunas compañías dejan esto a cargo del departamento TI, otras al de Recursos Humanos, y aún otras hacen responsables a departamentos específicos. Esto último es una receta segura para el fracaso.
La enorme ventaja de las arquitecturas centradas en la Internet es que pueden redefinir los factores económicos en la experimentación en Tecnología de la Información. Realizar una prueba de, por ejemplo, un software de automatización de la fuerza de ventas puede resultar lento y costoso. Utilizar la intranet para emular la funcionalidad clave de ese software no lo es. Nunca debería implementarse un despliegue de automatización de fuerza de ventas sin probarlo en una intranet para ver cómo lo utilizan en realidad los vendedores.
La oportunidad de ensayar implementaciones de tecnología instalándolas primero en una intranet o extranet resultará tan atractiva como económica. Hacerlo así reduce al mínimo la posibilidad de que el departamento TI o la compañía queden atrapados intentando hacer que una aplicación funcione a un nivel excesivamente local. Y además estas redes son un lugar más económico para cometer errores.
La situación económica actual no permite ya el lujo de realizar “tests piloto”. La capacidad del departamento TI para experimentar con mayor rapidez, mejor y más económicamente, para comprender los costes reales de la implementación, representa una opción estratégica, y no sólo una oportunidad técnica. El mensaje organizacional es sencillo: si no escala, no se vende. Si no podemos hacerlo escalar económicamente, no deberemos llevarlo a cabo. Esa es una filosofía de implementación que podría ser conveniente implementar.
Una compañía de servicios financieros mundial, con la que la mayoría mantiene relaciones, tiene un historial extraordinario con sus tecnologías en fase de prueba. Casi nunca fracasan.
Se trata de una excelente gestión de la Tecnología de la Información? Es muy probable que no. Ese historial excelente tiene un fallo: sólo una pequeña parte de esas tecnologías en prueba son desplegadas con éxito en toda la empresa. La compañía está llena de costosas implementaciones de éxito reducido: software, hardware, redes y aplicaciones que funcionan perfectamente bien en los departamentos de prueba designados, pero prácticamente en ninguna otra parte.
La mayoría de estas tecnologías en prueba –incluyendo un sistema experto de detección de fraudes, que no lo era tanto, y un data mart para gestión CRM– no duraron más de un año o dos. Y las que duraron se han convertido en objeto de permanentes batallas presupuestarias sobre quién debe pagar por ellas y realizar su mantenimiento. Una situación desagradable.
Esta patología de las Tecnologías de la Información en prueba es tan global como la innovación TI misma. Los escenarios corporativos de las grandes empresas mundiales están llenos de los restos de tecnologías en prueba que no pudieron, no fueron capaces o no debieron escalar. En realidad, demasiadas tecnologías en prueba han sido diseñada sin pensar lo más mínimo en esa posibilidad de extenderse más allá o escalar. Las compañías se concentran en hacer que sus tecnologías en prueba sean más manejables y efectivas que escalables. En otras palabras, optimizan el éxito de la tecnología piloto a expensas de optimizar el conocimiento necesario para escalar de forma económica. Así, las tecnologías en prueba se convierten en un fin, y no en un medio.
Esta disfunción económica tiene lugar por motivos totalmente lógicos. El más importante es que a nadie le gusta el fracaso. Cuando una compañía invierte dinero real y horas-hombre en una base de datos o en un sistema CRM en prueba, no desea declarar esa inversión como un gasto inútil. Así, las compañías intentan asegurarse de que la tecnología en prueba “funciona”. El departamento TI y el departamento designado harán lo necesario para garantizar que los beneficios de la tecnología en prueba superen su coste.
Lo cual conduce de forma natural al motivo siguiente: Para garantizar que la tecnología en prueba tiene éxito, el departamento TI y su departamento designado conspiran para hacer que resuelva algún conjunto específico de problemas comerciales. Estos problemas tienden a estar tan localizados y a ser tan especializados que requieren más adaptación a medida que estandarización. Adivínese lo que resulta más caro de escalar.
Al igual que la firma de servicios financieros mundial mencionada arriba, los departamentos disponen en todo el mundo de excelentes soluciones puntuales a sus problemas específicos. Sin embargo, en realidad, el enfoque adoptado por la compañía ha dado lugar a ausencias de economías de escala que han generado una inversión inútil de cientos de millones de dólares en menos de una década.
Las tecnologías en prueba que funcionan sin tener la escalabilidad como una prioridad no son proyectos de Tecnología de la Información: son simple investigación. No hay nada malo en realizar investigación sobre ofertas TI innovadoras. Sin embargo, hay que asegurarse de que las empresas vendedoras – y no los accionistas o los empleados – paguen su cuota justa por ello.
La cuestión más importante a la que se enfrentan los directores de información o CIOs que están considerando tecnologías innovadoras no es en qué medida funcionarán bien, sino ¿en qué medida escalarán bien? En lugar de preguntarse cómo hacer que la tecnología en prueba funcione mejor, el departamento TI deberá plantearse: ¿Cómo podría afectar esa sugerencia para mejorar la tecnología en prueba afectar a la forma en que podremos escalar?
En muchos casos, una tecnología puede escalar bastante bien, pero no así la forma en que sea utilizada organizacionalmente. Continuamente se sorprende uno ante departamentos TI que han resuelto los problemas de escalabilidad técnica al nivel departamental pero fracasan totalmente en apreciar – y mucho menos documentar – cuánto tiempo requirieron las personas en el departamento para dar cabida a los cambios técnicos. Por ejemplo, la tecnología de claves de criptología o “cripto keys” puede escalar bien técnicamente, pero la efectividad de sus implementaciones varía considerablemente. Algunas compañías dejan esto a cargo del departamento TI, otras al de Recursos Humanos, y aún otras hacen responsables a departamentos específicos. Esto último es una receta segura para el fracaso.
La enorme ventaja de las arquitecturas centradas en la Internet es que pueden redefinir los factores económicos en la experimentación en Tecnología de la Información. Realizar una prueba de, por ejemplo, un software de automatización de la fuerza de ventas puede resultar lento y costoso. Utilizar la intranet para emular la funcionalidad clave de ese software no lo es. Nunca debería implementarse un despliegue de automatización de fuerza de ventas sin probarlo en una intranet para ver cómo lo utilizan en realidad los vendedores.
La oportunidad de ensayar implementaciones de tecnología instalándolas primero en una intranet o extranet resultará tan atractiva como económica. Hacerlo así reduce al mínimo la posibilidad de que el departamento TI o la compañía queden atrapados intentando hacer que una aplicación funcione a un nivel excesivamente local. Y además estas redes son un lugar más económico para cometer errores.
La situación económica actual no permite ya el lujo de realizar “tests piloto”. La capacidad del departamento TI para experimentar con mayor rapidez, mejor y más económicamente, para comprender los costes reales de la implementación, representa una opción estratégica, y no sólo una oportunidad técnica. El mensaje organizacional es sencillo: si no escala, no se vende. Si no podemos hacerlo escalar económicamente, no deberemos llevarlo a cabo. Esa es una filosofía de implementación que podría ser conveniente implementar.
