El título de esta entrada lo he tomado de un artículo de Harvard Business Review que describe un caso de éxito de transformación de sistemas bancarios en Japón.
Esta es una entrada donde se muestran dos ejemplos de proyectos de IT, un fracaso (truncamiento de cheques en Canadá) y un éxito (transformación de capacidades de sistemas en Japón).
Cuando leí la noticia de Canadá dije, otra vez más de los mismo, en el mundo hay montones de experiencias de sistemas de truncamiento de cheques funcionado (lo tiene Argentina desde hace unos cuantos años) y la gente de Canadá quiso inventar la rueda.
La noticia no deja muy claro si los problemas fueron de tecnología o de procesos pero, si deja claro que se cumplió la ley de desarrollo de sistemas que pregona Don Peppers (gurú del marketing uno a uno);
“No importa lo que te prometan, saldrá el doble, tardará el doble y tendrá la mitad de las funciones”
En el caso de Canadá, ni siquiera lograron cumplir la ley.
Pero en el artículo de HBR, se comenta un caso exitoso de transformación de capacidades y procesos de un banco japonés que para mí muestra claramente algunos factores de éxito;
- A partir de la transformación del negocio, se necesitaron transformar las capacidades de IT.
- Se logro solo porque se trabajo en conjunto (CEO – CIO – Unidades de Negocio), no porque se alineó IT con el negocio.
- Las restricciones de fondos y la visión del CEO fueron fundamentales para guiar el proceso.
- El trabajo del CEO junto al CIO ofrecieron una clara visión de adonde ir.
- El equipo de trabajo del CIO ya era conocido por él y tenía un fuerte liderazgo sobre este equipo.
- Clara interpretación del escenario competitivo del banco.
- Transformaron las capacidades sin modificar los hábitos de trabajo iniciales y dejaron que se modifiquen a partir de la utilización de las nuevas funcionalidades.
- Utilizaron soluciones tecnológicas sencillas y baratas.
- El foco fue como se utiliza la tecnología y no la tecnología en si misma.
Comparando ambos casos, resulta muy claro dónde y porque motivos una organización de IT pudo demostrar el valor de IT y otra no logró ni siquiera poder implementar el sistema.
Resulta extraño leer en estos días casos de fracaso tan rotundo como el de Canadá, hay miles de artículos, libros y consejos sobre gestión de proyectos, pero pese a esto, parece que nada sirvió. Para complicarla un poco más, se enfrentan a un juicio por una patente que no tenían. Posiblemente este caso demuestre con mucha fuerza la importancia de las personas en los equipos de trabajo, escuchar que el director del proyecto dice que no cumplían los plazos una vez y otra y otra posiblemente muestre una falta de gestión muy importante.
Finalmente a través de este caso queda cada vez más claro que la tecnología en sí misma no genera ningún valor, es como las personas de una organización la utilizan y como esas mismas personas pueden liderar un proceso de transformación de capacidades posibilitadas por IT.
A continuación las dos noticias.
Los bancos perdieron millones de dólares en proyecto de cheques digitales
Un proyecto multimillonario en dólares de los bancos más importantes de Canadá y cooperativas de crédito, que habría reducido las emisiones de carbono y ahorrado dinero, ha sido suprimido a causa de numerosos retrasos y complicaciones.
La propuesta del sistema de compensación digital habría terminado la práctica costosa de trasladar cerca de tres millones de cheques en todo el país por cada día para su procesamiento.
«Cuando un banco pierde dinero en un proyecto de gran envergadura como éste, el costo debe ser descrito en alguna parte», dijo Blair Smith, un ex jefe de proyecto de un banco, que trabajó en el sistema en Vancouver por tres años.
«Ellos tienen la responsabilidad de decirle al consumidor o al accionista donde fallaron.»
El proyecto se inició a través de la Asociación de Pagos Canadiense en 2002 y apodado “truncamiento y presentación electrónica de cheques” o TECP. Los fondos para su financiación se obtuvieron de todas las instituciones financieras miembros de la asociación.
“Hemos decidido reducir nuestras pérdidas«, dijo el portavoz de la asociación Geoffroi Montpetit. «Este fue un proyecto muy complejo, desde los recursos humanos a la infraestructura».
Montpetit no quiso revelar el costo del proyecto que fracasó, pero confirmó que estaba en varios millones de dólares.
«Nosotros no publicamos datos financieros de cualquiera de nuestros proyectos, por lo que no se publicaran estos datos», dijo.
«Un montón de dinero, perdido,» dijo Smith. «Miles de horas se invirtieron en este proyecto».
Decenas de personas de 11 instituciones financieras trabajado en el sistema de intercambio de información digital, en representación de todos los grandes bancos y cooperativas de crédito. La industria, incluso presionó con éxito al gobierno federal a modificar la Ley sobre Letras de Cambio en 2007 para dar cabida al nuevo sistema dentro de la ley.
El ex director de proyecto Blair Smith dice que los clientes deben saber que los bancos desperdiciaron tiempo y dinero en este proyecto y no cumplieron.
Para construir el nuevo sistema, se compró Tecnología que luego tuvo que ser retirada del servicio cuando se desechó el proyecto.
Para complicar más las cosas, resulta que las instituciones financieras de Canadá no tienen una patente para la tecnología que se utiliza para construir el nuevo sistema digital. DataTreasury, una empresa de EE.UU., pretende mantener la patente y demandó a seis bancos de Canadá, basado en la infracción de patentes en curso.
«Una vez que los plazos de tiempo no se cumplieron, y otra vez y otra vez, te pones a pensar ¿Por qué estamos haciendo esto? «, Dijo Smith.
IT Radicalmente simple
por David M. Upton y Bradley R. Staats
A través del diseño e implementación de sistemas en una forma diferente, el banco Shinsei de Japón transformó IT desde una restricción a una plataforma para el crecimiento.
Los proyectos de IT de las empresas – tanto los enlatados como los desarrollados “un talle único para todo» siguen siendo un dolor de cabeza para los líderes empresariales. El problema fundamental de estos sistemas es que en su mayor parte, están construidos con lo que el programador y campeón del código Abierto, Eric Raymond llama el enfoque de la catedral. Como los grandes edificios que los europeos construyeron en la Edad Media, los proyectos de IT de las empresas son costosos, toman una gran cantidad de tiempo, y ofrecen valor sólo cuando se ha completado el proyecto. Al final, se producen sistemas que son inflexibles y anclan a las compañías en la forma de funcionar en que la empresa trabajó varios años atrás, cuando empezó el proyecto. A pesar de las recientes mejoras en la flexibilidad de los paquetes de software, las empresas suelen encontrar un precio desorbitante y la dificultad de modificar sus sistemas empresariales a fin de aprovechar nuevas oportunidades de negocio.
En lugar de construir sistemas que son legados desde el día en que se comienzan a operar, los gerentes pueden y deben desarrollar sistemas que pueden mejorados – rápida y continuamente – después que han sido puestos en producción. Durante la última década, hemos estudiado el diseño y aplicación de sistemas de IT en las empresas y asistido a numerosas de ellas con el proceso. A través de nuestro trabajo, hemos identificado un enfoque que no sólo reduce los costos de una empresa, sino que apoya el crecimiento de los negocios existentes y el lanzamiento de otros nuevos. Nosotros lo llamamos un enfoque «basado en el camino”, porque en lugar de intentar definir todas las especificaciones de un sistema antes de que se ponga en marcha el proyecto, las empresas se centran en proporcionar un camino para que el sistema se desarrolle en el tiempo. El enfoque se basa en que es difícil y costoso poder trazar todos los requisitos antes de que un proyecto se inicie, porque la gente muchas veces no puede especificar todo lo que necesita de antemano. Además, las necesidades imprevistas se presentan casi siempre una vez que el sistema está en funcionamiento. Y persuadir a la gente a utilizar y «ser dueño de» después que el sistema está en funcionamiento es mucho más fácil decirlo que hacerlo.
En nuestra investigación, hemos descubierto una empresa destacada entre las que aplican el método basado en el camino: Shinsei Bank de Japón. Tuvo éxito en el desarrollo y la implementación de un sistema completamente nuevo en la empresa en un año a un costo de $ 55 millones: Es un cuarto del tiempo y alrededor del 10% del costo de la instalación de un sistema envasado tradicional. El nuevo sistema no sólo sirve como una plataforma eficiente de bajo costo para la administración del negocio existente, sino también lo suficientemente flexible como para apoyar el crecimiento de la compañía en nuevas áreas, como banca minorista, financiación al consumo, y un joint-venture para vender fondos de inversión de la India en Japón.
Los principios aplicados por Shinsei en el diseño, la construcción e implementación del sistema – fuerza en conjunto, no sólo la alineación de la estrategia del negocio y IT – utilizando la tecnología más simple posible, haciendo el sistema verdaderamente modular, dejando que el sistema se venda solo a los usuarios y, permitir a los usuarios influir en las futuras mejoras – son un modelo para otras empresas. Algunos de estos principios son variaciones sobre viejos temas, mientras que otros a su vez voltearon la sabiduría convencional.
Nacida de la necesidad
Shinsei surgió cuando el Long-Term Credit Bank, fundado por el gobierno japonés para ayudar en la reconstrucción de las industrias del país después de la Segunda Guerra Mundial, fue a la quiebra en 1998, con casi $ 40 mil millones en préstamos en mora. La empresa fue nacionalizada, y luego vendida en 2000 a Ripplewood Holdings, un fondo de capital privado de EE.UU., y renombrado Shinsei, que significa «nuevo nacimiento». Los ejecutivos de Ripplewood convencieron a Masamoto Yashiro, ex presidente de Citibank Japón – retirado -, que dirija a Shinsei. Además de decidir modernizar las operaciones comerciales existentes, Yashiro formuló un plan para revolucionar la banca minorista en Japón, ofreciendo una propuesta de valor única en el país en ese momento: productos de alta calidad y servicios prestados en un forma fácil y conveniente en su utilización y de bajo costo. La estrategia de Shinsei ofrecería servicios que entonces eran poco frecuentes en Japón, incluyendo los cajeros automáticos disponibles 24 / 7 gratis, banca por Internet, negociación en línea con bolsas del exterior, banca en línea bilingüe, servicio rápido y con el apoyo de la reconciliación en tiempo real de bases de datos (es decir, cuentas de los clientes que se actualizan inmediatamente después de cada transacción).
Yashiro consideró que el banco necesitaba moverse rápidamente para aprovechar la oportunidad en la banca minorista. Sin embargo, los actuales sistemas de IT eran anticuados y no podían ni siquiera apoyar los negocios existentes de manera adecuada. Para abordar estas cuestiones, Yashiro contrató a su ex colega Dhananjaya «Jay» Dvivedi, que había dirigido las operaciones de IT en el Citibank de Japón, para ser director de información. Al asumir el cargo, Dvivedi rápidamente se rodeó de un equipo con talento, la mayoría de los cuales habían trabajado con él anteriormente. Puesto que el banco de recuperación había limitado los fondos para inversión, Yashiro Dvivedi dio el mandato de revolucionar, pero entendiendo que su equipo tenía que hacerlo «rápido» y «barato». Reconociendo plenamente que no podía saber lo que la operación de venta al por menor necesitaría, los dos hombres acordaron que el objetivo debe ser crear un sistema que pudiera ampliarse con el crecimiento y adaptarse a las nuevas oportunidades que el dinámico negocio crearía.
Las opciones convencionales para la construcción del sistema eran dos: el planteamiento de un «big bang» para sustituir el sistema actual con un sistema totalmente nuevo y los procesos a la vez o, el método incremental de mejorar o reemplazar el actual sistema de a una sola pieza pequeña por vez. Dvivedi y su equipo estaban recelosos de tomar el camino del Big Bang, creyendo que era demasiado arriesgado dada las limitaciones de efectivo del banco y sabiendo muy bien los problemas endémicos de este tipo de proyectos. El curso incremental, sin embargo, probablemente tomaría de tres a cinco años, y sería demasiado lento. Así que decidieron abrir un tercer camino. Se pondría en marcha una nueva infraestructura modular que, en primer lugar, funcionaría en paralelo con la función actual, pero finalmente la sustituiría. De acuerdo con el pensamiento tradicional de IT, esto era una locura. Gran parte del software de transición tendría que ser desarrollado para abarcar lo viejo y lo nuevo, lo que requeriría un enorme esfuerzo.
Pero Dvivedi conocía de su trabajo previo y sus conversaciones con otros CIOs que los problemas técnicos no eran casi nunca la razón de que los nuevos sistemas fracasen. Son los problemas humanos. La gente normalmente se resiste a adoptar nuevos sistemas, a menudo porque el costo (esfuerzo), supera los beneficios. Para abordar esta cuestión, Dvivedi utilizó soluciones tecnológicas simples e innovadoras para evitar la dolorosa experiencia de salir en vivo. Por ejemplo, imitando la forma e interface del viejo sistema por un tiempo, Dvivedi y su equipo pudieron acelerar la adopción del nuevo sistema.
Copyright © 2008 Harvard Business School Publishing Corporation. All rights reserved.