TI radicalmente sencilla

Los proyectos de TI empresarial (sistemas personalizados y empaquetados de «talla única») siguen siendo un gran quebradero de cabeza para los líderes empresariales. El problema fundamental de estos sistemas es que, en su mayor parte, se construyen con lo que el programador y campeón del código abierto Eric Raymond denominó un enfoque catedralicio. Al igual que los grandes edificios que los europeos erigieron en la Edad Media, los proyectos de TI empresariales son costosos, llevan mucho tiempo y solo ofrecen valor cuando el proyecto está terminado. Al final, crean sistemas que son inflexibles y hacen que las empresas funcionen como lo hacían sus negocios hace varios años, cuando se inició el proyecto. A pesar de las recientes mejoras en la flexibilidad del software empaquetado, a las empresas les suele resultar exorbitante caro y difícil modificar sus sistemas empresariales para aprovechar las nuevas oportunidades de negocio.

En lugar de crear sistemas que sean heredados del día en que se encienden, los gerentes pueden y deben desarrollar sistemas que se puedan mejorar (de forma rápida y continua) mucho después de su puesta en marcha. Durante la última década, estudiamos el diseño y la implementación de sistemas de TI empresariales y hemos ayudado a numerosas empresas en el proceso. A través de nuestro trabajo, hemos identificado un enfoque que no solo reduce los costes de la empresa, sino que también apoya el crecimiento de las empresas existentes y el lanzamiento de otras nuevas. Lo llamamos enfoque «basado en rutas», porque en lugar de intentar definir todas las especificaciones de un sistema antes del lanzamiento del proyecto, las empresas se centran en proporcionar una ruta para que el sistema se desarrolle con el tiempo. La premisa del enfoque es que es difícil y costoso planificar todos los requisitos antes de que comience un proyecto, ya que las personas no suelen especificar todo lo que necesitan de antemano. Además, casi siempre surgen necesidades imprevistas una vez que el sistema está en funcionamiento. Y persuadir a la gente de que usen y sean «dueños» del sistema una vez que esté en funcionamiento es mucho más fácil decirlo que hacerlo.

En nuestra investigación, descubrimos una empresa destacada entre las empresas que utilizan el método basado en rutas: el Banco Shinsei de Japón. Logró desarrollar e implementar un sistema empresarial completamente nuevo en un año con un coste de 55 millones de dólares: una cuarta parte del tiempo y alrededor del 10% del coste de instalar un sistema empaquetado tradicional. El nuevo sistema no solo servía como una plataforma eficiente y de bajo coste para gestionar el negocio existente, sino que también era lo suficientemente flexible como para apoyar el crecimiento de la empresa en nuevas áreas, como la banca minorista, la financiación al consumo y una empresa conjunta para vender fondos de inversión indios en Japón.

Los principios basados en rutas que Shinsei aplicó al diseñar, crear y desplegar el sistema (forjar juntas, no solo alinear, las estrategias empresariales y de TI; emplear la tecnología más simple posible; hacer que el sistema sea realmente modular; permitir que el sistema se venda solo a los usuarios; y permitir a los usuarios influir en las mejoras futuras) son un modelo para otras empresas. Algunos de estos principios son variaciones de temas antiguos, mientras que otros dan la vuelta a la sabiduría convencional.

Nacido de la necesidad

Shinsei se creó cuando Long-Term Credit Bank, fundado por el gobierno japonés para ayudar a reconstruir las industrias del país tras la Segunda Guerra Mundial, quebró en 1998 con casi 40 000 millones de dólares en préstamos morosos. La firma se nacionalizó y, en 2000, se vendió a Ripplewood Holdings, un fondo de capital privado estadounidense, y pasó a llamarse Shinsei, que significa «nuevo nacimiento». Los ejecutivos de Ripplewood convencieron a Masamoto Yashiro, el expresidente de Citibank Japan, de su jubilación para dirigir Shinsei. Además de decidir modernizar las operaciones de banca comercial existentes, Yashiro formuló un plan para revolucionar la banca minorista en Japón con una propuesta de valor única en el país en esa época: productos y servicios de alta calidad ofrecidos de forma práctica, fácil de usar y de bajo coste. La estrategia consistía en que Shinsei ofreciera servicios que entonces eran poco comunes en Japón, como cajeros automáticos disponibles las 24 horas del día, los 7 días de la semana sin cargo, la banca por Internet, la negociación de divisas en línea, la banca bilingüe en línea y un servicio rápido respaldado por la conciliación de bases de datos en tiempo real (lo que significaba que las cuentas de los clientes se actualizaban inmediatamente después de cada transacción).

Yashiro pensó que el banco tenía que actuar con rapidez para aprovechar la oportunidad de la banca minorista. Sin embargo, los sistemas de TI actuales de la empresa eran anticuados y ni siquiera podían respaldar adecuadamente el negocio corporativo actual del banco. Para abordar estos problemas, Yashiro contrató a su antiguo colega Dhananjaya «Jay» Dvivedi, que había dirigido las operaciones de TI en Citibank Japan, como director de información. Al aceptar el puesto, Dvivedi se rodeó rápidamente de un equipo central con talento, la mayoría de los cuales habían trabajado para él anteriormente. Como el banco en recuperación tenía fondos de inversión limitados, Yashiro le dio a Dvivedi el mandato de revolucionar la TI, pero con el entendimiento de que su equipo tenía que hacerlo «rápido» y «barato». Al darse cuenta de que no podían saber del todo lo que necesitaría la operación minorista, los dos estuvieron de acuerdo en que el objetivo debía ser crear un sistema que pudiera crecer con el crecimiento y adaptarse a las nuevas oportunidades que crearía una empresa dinámica.

Las opciones convencionales para crear un sistema empresarial importante eran dos: el enfoque «a lo grande» de reemplazar el sistema actual por un sistema y procesos completamente nuevos a la vez o el método gradual de mejorar o reemplazar el sistema existente, pieza a pieza. Dvivedi y su equipo estaban recelosos de tomar el camino de la gran explosión, ya que creían que era demasiado arriesgado dadas las restricciones de efectivo del banco y conocían muy bien los problemas endémicos de este tipo de proyectos. Sin embargo, el curso gradual, que probablemente tardaría de tres a cinco años, sería demasiado lento. Así que decidieron abrir un tercer camino. Crearían una nueva infraestructura modular que al principio funcionaría en paralelo con la infraestructura actual, pero que eventualmente sustituiría a la infraestructura actual. Según el pensamiento tradicional de TI, fue una locura. Habría que desarrollar gran parte del software puente para abarcar lo antiguo y lo nuevo, lo que requeriría un esfuerzo enorme.

Pero Dvivedi sabía por sus trabajos anteriores y por sus conversaciones con otros directores de TI que los problemas técnicos casi nunca eran la razón por la que los nuevos sistemas de TI fracasaban. Los problemas humanos eran. La gente suele resistirse a adoptar nuevos sistemas, a menudo porque el coste (el esfuerzo) supera a los beneficios. Para solucionar este problema, Dvivedi utilizó soluciones tecnológicas sencillas pero innovadoras para evitar la desgarradora experiencia de puesta en marcha. Por ejemplo, al imitar el aspecto del sistema anterior al menos durante un tiempo, Dvivedi y su equipo pudieron acelerar la adopción del nuevo sistema.

Si bien la unidad minorista aún no ha caído con fuerza en números negros (debido a los gastos necesarios para construir el negocio y al difícil entorno económico y reglamentario de Japón), el nuevo sistema de TI empresarial fue fundamental para que Shinsei se convirtiera rápidamente en un actor importante en el mercado de la banca minorista en Japón. Para el 30 de junio de 2007, Shinsei tenía más de 2 millones de clientes minoristas, frente a los menos de 50 000 de 2001, cuando su negocio minorista se limitaba a clientes adinerados. El diario de un banquero asiático nombró a Shinsei el mejor banco minorista de Japón en 2004 y 2005, y Nihon Keizai Shimbun, uno de los periódicos de negocios más influyentes de Japón, proclamó a Shinsei como el número uno en satisfacción de los clientes entre los bancos de Japón en 2004, 2005 y 2006.

Analicemos más de cerca el enfoque basado en los caminos de Shinsei.

No se limite a alinear las estrategias empresariales y de TI, sino que frújelas juntas

La idea de que la estrategia empresarial y la estrategia de TI deben estar alineadas y, por lo tanto, que los usuarios empresariales deben participar en el diseño de los sistemas empresariales ha sido ampliamente aceptada. Sin embargo, hacerlo ha demostrado ser tremendamente difícil, por varias razones. Por un lado, los líderes de TI se esfuerzan por entender realmente el contexto empresarial. Es más, los líderes empresariales no invierten el tiempo necesario para apreciar el poder y los desafíos de la tecnología y tienden a tratar al personal de TI como proveedores de servicios de segunda clase. Incluso cuando los dos grupos se reúnen para hablar de un proyecto, esas ocasiones tienden a ser aisladas, eventos únicos, en lugar de formar parte de una discusión continua. Sin embargo, nos guste o no, los sistemas de información son una parte integral de la estrategia empresarial en casi todos los sectores actuales. Si los líderes empresariales ven al personal de TI como un actor auxiliar y no como un socio, la transferencia de conocimientos entre los dos grupos se verá afectada, lo que se traducirá en la pérdida de oportunidades y en un rendimiento subóptimo.

Para complicar la situación, cuando las empresas adoptan paquetes de software estándar, suelen acabar adaptando la empresa a la tecnología. Sin duda, esto a veces significa que las empresas abandonan los procesos ineficientes e instituyen las mejores prácticas integradas en el software. Pero la mayoría de las veces, los directores sacrifican las capacidades idiosincrásicas y competitivas que el sistema podría hacer posibles, ya que desarrollarlas aumentaría el tiempo y el coste de llevar a cabo un proyecto ya de por sí caro y que requiere mucho tiempo.

Entonces, ¿qué debe hacer una empresa para integrar sus estrategias empresariales y de TI? Antes de empezar la planificación de un proyecto, los directores generales deben asegurarse de que el personal de TI entiende el negocio y desempeña un papel central en la organización. Una forma de asegurarnos de que esto suceda es hacer que el director de TI dependa del CEO o el COO (como hace Dvivedi en Shinsei) en lugar del CFO, como es común en muchas grandes empresas. La percepción de la importancia a menudo se convierte en realidad.

Los directores de negocios también deben entender lo que puede hacer la TI. En Shinsei, Yashiro y su sucesor, Thierry Porté, dedicaron una cantidad considerable de su tiempo a aprender sobre TI. Porté habla con Dvivedi con frecuencia, se reúne con él formalmente como mínimo una vez a la semana y visita el centro de TI y operaciones de la empresa al menos una vez al mes. Porté cree que, como CEO, «tengo que ser capaz de explicar la TI a mis clientes y empleados para que podamos satisfacer las necesidades empresariales de nuestros clientes y ofrecer valor en el futuro».

En el desarrollo de proyectos, el primer paso es centrarse en los objetivos empresariales previsibles, no en el entorno existente. Con demasiada frecuencia, las empresas dedican todo su tiempo a pensar en cómo funcionan los sistemas existentes y en los procesos actuales que se utilizan para completar una tarea. Esto da como resultado que se pavimenten los antiguos caminos de tierra. Cualquiera que haya intentado conducir por las confusas calles de Boston o Londres comprenderá las consecuencias de este enfoque.

El primer paso es centrarse en los objetivos empresariales previsibles, no en el entorno existente. Con demasiada frecuencia, las empresas dedican su tiempo a pensar en cómo funcionan los procesos actuales.

Tras identificar los objetivos empresariales previsibles, los directores deben crear una estrategia de TI que se adapte a ellos. Debe ser un esfuerzo continuo: debe haber una interacción constante entre los grupos empresarial y de TI en relación con los objetivos empresariales y las decisiones y restricciones de TI. Al entablar debates iterativos, las dos partes van hablando poco a poco el mismo idioma. A medida que los usuarios empresariales eduquen al personal de sistemas sobre sus necesidades y el personal de TI les ponga prototipos por delante, surgirán nuevas soluciones potenciales.

La estrecha relación entre los grupos de TI y empresarial ayudó a Shinsei a aprovechar al máximo la tecnología en su esfuerzo por transformar la experiencia de los clientes en las sucursales del banco. Por ejemplo, los cajeros Shinsei estaban equipados con dos pantallas: una orientada hacia el cajero y la otra orientada hacia el cliente. La pantalla del cliente era la misma que la del sitio de banca por Internet, mientras que la pantalla del cajero mostraba ese contenido e información adicional sobre el cliente. Cuando un cliente hacía una transacción, el cajero le enseñaba literalmente al cliente cómo ejecutar la transacción ella misma (sin decirle al cliente que estaba siendo entrenada para realizar futuras transacciones en un ordenador personal de su casa o en un cajero automático). Los cajeros no tenían efectivo. Si un cliente quería depositar o retirar dinero, el cajero se dirigía a un cajero automático con el cliente y volvía a ejecutar la transacción con la participación del cliente. Los clientes nunca se vieron obligados a atenderse solos, pero a través de sus sistemas de TI y otras infraestructuras (sucursales, cajeros automáticos, cajeros), Shinsei podía ofrecer un servicio de alto nivel y, al mismo tiempo, capacitar y alentar a los clientes a gestionar determinadas transacciones por sí mismos.

Los cajeros también pudieron ver de primera mano los tipos de transacciones que molestaban a los clientes, lo que generó una serie de ideas para mejorar los sistemas. Por ejemplo, cuando los clientes realizaban tareas como abrir una cuenta y transferir fondos, tenían que rellenar formularios en papel y entregarlos a los cajeros, quienes, a continuación, introducían la información en el sistema. Los cajeros se dieron cuenta de que los clientes solían elegir los formularios incorrectos o los rellenaban de forma incorrecta. Para solucionar este problema, Shinsei cambió su proceso. Los cajeros ahora toman la información necesaria de los clientes, la introducen en el sistema y presentan una confirmación generada por ordenador al cliente para su verificación inmediata.

Esfuércese por lograr una sencillez extrema

Guillermo de Ockham, el filósofo medieval, dijo que las teorías deberían ser lo más simples posible. El mismo principio se aplica a los sistemas de TI empresariales: deben diseñarse con el menor número posible de estándares (como protocolos de red, sistemas operativos y plataformas), idealmente uno de cada uno. Si bien las organizaciones suelen empezar con un puñado de estándares, la mayoría permite que se multipliquen con el tiempo como resultado de las adquisiciones y las iniciativas individuales de las empresas. Además, la tecnología elegida o desarrollada para satisfacer necesidades específicas debe ser lo más simple posible, debe suponer que habrá fallos técnicos y tener formas de mitigarlos y, en la medida de lo posible, debe ser reutilizable.

Estándares mínimos.

La estandarización de un conjunto pequeño de componentes es fundamental para un enfoque basado en rutas. Así como Southwest Airlines se ha beneficiado de volar solo con Boeing 737, la simplificación de la infraestructura de TI permite a la empresa reducir la complejidad, profundizar la experiencia especializada y aumentar las posibilidades de reutilización de elementos del sistema, lo que acelera el desarrollo y reduce los costes de mantenimiento. Además, la estandarización de los componentes permite a las organizaciones dedicar menos tiempo a mantener la calidad y más a crear nuevas funciones.

De hecho, una de las principales fuentes de valor añadido que pueden aportar los grandes proveedores de software externos es a menudo que limitan los estándares que se utilizan en una organización a su propio conjunto propietario. La mayoría de los directores de TI no tienen el poder ni la disciplina a largo plazo para mantener la línea por sí mismos. Eso significa que los directores de empresa deben entender la tecnología para apreciar las ventajas y desventajas y ayudar a evitar las excepciones que pueden balcanizar los sistemas de TI.

Los directores de negocios deben entender la tecnología para apreciar las desventajas y ayudar a evitar las excepciones que pueden balcanizar los sistemas de TI.

Dvivedi impulsó sin piedad la estandarización en Shinsei. Solicitó la opinión de los actores pertinentes, pero no esperó al consenso para actuar. Una de sus decisiones más radicales fue eliminar los sistemas de mainframe de Shinsei, la columna vertebral tradicional de la TI de un banco, y sustituirlos por servidores basados en Intel. Esto supuso un cambio significativo con respecto a la práctica predominante entre los bancos de Japón y la mayoría de las firmas de servicios financieros de todo el mundo, a las que les encantaban las altas velocidades de rendimiento y el fiable tiempo de actividad de los mainframes. El problema era que los sistemas de mainframe eran caros y difíciles de mantener (el coste anual de mantenimiento de un ordenador central típico es del 15 al 20% del precio de compra original). El software de los sistemas basados en mainframes más antiguos normalmente se escribe en lenguajes propietarios arcanos, que son difíciles de descifrar incluso si encuentra programadores familiarizados con el código. El cambio a una plataforma basada en servidores ahorró inmediatamente al banco 40 millones de dólares en gastos al año. Además de seleccionar una plataforma de servidor único, Dvivedi y su equipo eligieron otros estándares, como los ordenadores Dell, Microsoft Windows, Internet, los teléfonos IP y la mensajería estándar entre sistemas empresariales.

Soluciones sencillas y reutilizables.

Como no quería que el nuevo banco (las unidades minorista, comercial y de banca de inversión) se dejara encadenar por las capacidades de la tecnología existente, Dvivedi trabajó con su equipo para crear una arquitectura que permitiera a Shinsei abordar los problemas empresariales a medida que surgieran. Esto implicó un proceso sencillo que siguieron de forma coherente. Tras identificar primero un problema empresarial, el equipo lo dividía en sus componentes y, a continuación, determinaba una solución tecnológica para cada uno de ellos. Para ello, primero ahondaron en su kit de herramientas de módulos y componentes estándar para comprobar si ya existía una solución. Si no tenían una solución interna, buscaban una solución disponible en el exterior. Si no hubiera ninguno disponible, recurrirían a uno de los cinco o seis socios independientes de servicios de software de la India para desarrollar la capacidad.

La invención y el despliegue de la red de cajeros automáticos completamente nueva de Shinsei son un excelente ejemplo de este enfoque. En el año 2000, otros bancos japoneses cobraban comisiones por el uso de sus propios cajeros automáticos, así como los de la competencia, y ofrecían servicios de cajero automático solo durante el horario comercial de las sucursales. Shinsei se dio cuenta de que si quería ofrecer transacciones gratuitas las 24 horas del día, no podría crear una réplica de las costosas redes de cajeros automáticos de otros. En consecuencia, el equipo del proyecto formado por personal de negocios e TI identificó con precisión la funcionalidad que tenían que ofrecer y, a continuación, desglosó los problemas en cuestión en la medida de lo posible. Eso les permitió resolver los problemas de formas nuevas y más rentables. Por ejemplo, tradicionalmente, los cajeros automáticos estaban conectados a los sistemas de back-end del banco a través de costosas líneas arrendadas. El equipo se dio cuenta de que Internet podía cumplir la misma función. Sin embargo, el tiempo de actividad o la fiabilidad de una conexión a Internet eran peores que los de una línea arrendada. La solución más sencilla: diseñe el sistema para que espere los fallos y se ocupe de ellos instalando dos conexiones a Internet de dos proveedores diferentes. Esto ofrecía una mayor fiabilidad que una línea arrendada a una décima parte del coste. En conjunto, el nuevo enfoque permitió a Shinsei ofrecer a los clientes cajeros automáticos que estaban siempre disponibles y ofrecían más funciones que las redes tradicionales de la competencia a una fracción del coste.

Otro ejemplo de una solución ingeniosamente sencilla es la cura del equipo de TI para los fallos derivados de la pérdida de memoria. Cualquier sistema operativo puede ser propenso a pérdidas de memoria, que se producen cuando una aplicación no libera la memoria que utilizaba una vez finalizada una tarea. Con el tiempo, es posible que el sistema operativo se quede sin memoria, se vuelva inestable y se bloquee. La solución más común es diseñar herramientas sofisticadas de gestión y depuración de la memoria para tratar de evitar todas las fugas de memoria. Sin embargo, estas herramientas no pueden tapar todas las fugas de forma fiable. Shinsei decidió simplemente suponer que la memoria se filtraría en sus servidores y hacer que realizaran un reinicio escalonado a intervalos frecuentes, una solución burda pero eficaz y económica.

Tanto si el personal de Dvivedi desarrollaba un componente internamente como si le pedía a un proveedor externo que se lo proporcionara, el componente tenía que ser reutilizable en otros proyectos de Shinsei, si era posible. Para ello, el equipo especificó claramente la función requerida del componente y las interfaces estándar para garantizar que pudiera «comunicarse» con cualquier otro módulo existente o futuro. Por ejemplo, el personal empresarial y de TI de Shinsei se dio cuenta desde el principio de que la verificación crediticia era un proceso clave en varios servicios que ofrecía el banco. Por lo tanto, el equipo desarrolló un módulo reutilizable para la verificación de crédito que se podía implementar en todos los productos. Hoy en día, más del 90% de los componentes tecnológicos se utilizan en más de un lugar.

Modularidad, no solo módulos.

Si bien la opinión predominante de que los grandes programas y sistemas de TI deben consistir en módulos no es nueva, a menudo se malinterpreta el concepto de modularidad. El hecho de que un desarrollador de software afirme que las distintas partes de sus aplicaciones son módulos no significa que realmente sean modulares. La modularidad implica especificar claramente las interfaces para que el trabajo de desarrollo pueda realizarse dentro de cualquier módulo sin afectar a los demás. Las empresas suelen pasar por alto ese punto cuando desarrollan sistemas empresariales. Por ejemplo, conocemos una empresa de automóviles que tenía equipos que trabajaban en varios módulos de un nuevo sistema empresarial y afirmaba tener un diseño modular. Sin embargo, un equipo se encargaba de las interfaces y las cambiaba constantemente. Cada modificación de este grupo obligaba a los demás grupos a dedicar enormes cantidades de tiempo a rehacer la obra que ya habían realizado. En lugar de limitar el impacto de los cambios mediante la adopción de la modularidad, ¡esta empresa había amplificado los problemas!

Una arquitectura verdaderamente modular permite a los diseñadores centrarse en crear soluciones a los problemas locales sin perturbar el sistema global. Con piezas pequeñas y modulares, la organización puede comprar soluciones listas para usar o recurrir a desarrolladores internos o externos para obtener una pieza determinada, lo que acelera la velocidad del desarrollo. La arquitectura modular también facilita la actualización de la tecnología dentro de los módulos una vez que el sistema esté en funcionamiento.

Una arquitectura verdaderamente modular permite a los diseñadores centrarse en crear soluciones a los problemas locales sin perturbar el sistema global.

Desglosar y resolver los problemas de esta manera ofrece una serie de ventajas más allá de la rapidez. Permite al equipo de TI concentrarse en obtener la solución más económica para cada pieza y (al dividir el trabajo) reduce el impacto de un único punto de fallo. Especificar claramente las funciones de los módulos y las interfaces facilita la creación de un módulo que se pueda reutilizar en otras aplicaciones.

El enfoque modular fue una parte fundamental para lograr la estrategia del banco, tal como la describió Dvivedi, «de ampliar y expandirse a nuevas actividades con facilidad, para poder atender las necesidades de la organización a medida que pasa de ser un bebé a un adulto… y evitar crear capacidad antes de que la necesitemos». Tomemos como ejemplo las capacidades de procesamiento de préstamos. El equipo del proyecto implementó las capacidades en pequeñas etapas por tres razones: para demostrar a la dirección que el sistema informático funcionaría según lo prometido, para evitar abrumar a los gerentes y usuarios con demasiada automatización de una sola vez y para poder abordar cualquier problema técnico rápidamente a medida que surgiera. En consecuencia, el equipo inicialmente intentó demostrar que el sistema podía aprobar correctamente el crédito para un número reducido de préstamos (de 20 a 30 al día). Luego, el equipo desarrolló la capacidad de procesar completamente de 200 a 300 préstamos al día. A medida que el negocio crecía, Shinsei eliminó el trabajo manual para alcanzar la capacidad de tramitar 6 000 préstamos al día.

Gracias a la estructura modular del sistema automatizado, Shinsei puede simplemente sustituir una parte (las funciones de solicitud de préstamo o verificación de crédito, por ejemplo) sin afectar al resto. Es más, la modularidad ha permitido a Shinsei cambiar su TI cuando ha sido necesario o ha sido necesario sin correr el riesgo de molestar a los clientes. Puede mantener las interfaces de los clientes (como las páginas web o el formato de la pantalla del cajero automático) iguales al cambiar los sistemas de fondo.

Dar (algo) de poder al pueblo

Muchos de los fracasos de los grandes proyectos de TI se deben a la resistencia organizacional (los usuarios torpedean los nuevos sistemas) más que a una tecnología que no funciona. A veces, el problema es que la empresa trata de imponer el sistema a su gente y estos se rebelan; la mayoría de las veces, la gente simplemente no ve una razón de peso para hacer el esfuerzo de aprender a operar el nuevo sistema.

En general, las empresas no deberían tener que vender nuevos sistemas a los usuarios, sino que deberían crear sistemas que los usuarios adopten voluntariamente. Esto no quiere decir que todos los miembros de la organización vayan a adoptar todas las tecnologías con entusiasmo. Pero si un sistema es odiado universalmente mucho después de la etapa de «conocerlo», es probable que el sistema necesite una mejora significativa o que deba desecharse.

Cuando Shinsei lanza un nuevo sistema, inicia el proceso con una interfaz o formato de pantalla similar al del sistema anterior. Un empleado de Shinsei que empezara a utilizar el nuevo sistema para introducir las solicitudes de préstamo podía ir a una página que era una réplica exacta de la pantalla de entrada de datos del sistema anterior. Sin embargo, si el nuevo formulario de solicitud de préstamo requería información (el número de teléfono móvil de un cliente, por ejemplo) que no estaba incluida en la pantalla anterior, el empleado tendría que ir a la nueva pantalla de entrada de datos para escribir la información. Al ir y venir de esta manera, el usuario se acostumbraría al nuevo sistema. Solo después de que la gran mayoría de los usuarios hagan la transición al nuevo sistema, el equipo de Dvivedi apagará las antiguas pantallas de entrada de datos. Este enfoque aumentará los costes a corto plazo, pero Dvivedi cree que es un precio pequeño a pagar por una adopción más rápida y entusiasta del nuevo sistema.

Mejora continua.

La creencia de Dvivedi en el poder de los usuarios va más allá de la fase de lanzamiento. También se aplica a la mejora continua. Un principio fundamental es que cualquier esfuerzo de mejora continua fracasará sin la participación comprometida de los usuarios. Shinsei solicita activamente las ideas de los usuarios para mejorar sus sistemas empresariales, los hace participar en la experimentación diaria y se esfuerza por hacer que sientan que sus aportaciones son importantes. Se da cuenta de que si las personas no sienten que sus ideas son escuchadas y que se actúan en consecuencia con rapidez, dejan de ofrecerlas.

Con ese fin, Dvivedi y su equipo crearon un sistema para abordar los comentarios y las solicitudes de los clientes, los usuarios empresariales y los usuarios técnicos. En los últimos meses, estos comentarios y solicitudes han tenido una media de unos 100 al día. Tanto las sugerencias como los fallos del sistema generan órdenes de trabajo electrónicas, que se envían al personal correspondiente y se elevan a los niveles superiores de la organización si permanecen abiertas durante demasiado tiempo. Cuando se resuelve un problema, se notifica a la persona que lo planteó.

Cuando la mejora continua es una parte integral del trabajo diario, la necesidad de lemas pegadizos que inspiren a la fuerza laboral y de una resolución heroica de problemas disminuye considerablemente.

Por ejemplo, el sistema de comentarios ayudó a los líderes empresariales a detectar que algo andaba mal en el negocio hipotecario. Cuando los clientes que solicitaban préstamos hipotecarios se quejaban de que ya habían enviado los documentos solicitados a Shinsei y que el sistema mostraba como pendientes, se notificó automáticamente a los gerentes del problema y se asignó a un equipo de personal empresarial y de TI que encontrara la causa principal y la solucionara. Cuando el equipo estudió el tema, descubrió que el verdadero problema era que el banco había estado enviando a los clientes una lista de los documentos que debían presentar, pero los clientes no estaban seguros de cuáles eran los documentos (por ejemplo, no sabían qué aspecto tenían sus escrituras). Como resultado, los clientes enviaron los documentos incorrectos. La solución del equipo: hacer que el sistema de TI identifique automáticamente el conjunto único de documentos que el cliente tiene que enviar y, a continuación, envíe al cliente muestras de esos documentos, ni más ni menos. Al asegurarse de que los clientes envían los documentos correctos la primera vez, Shinsei ha reducido el tiempo que tardan tanto los clientes como el banco en procesar los documentos y ha aumentado la satisfacción de los clientes. Puede que todo esto no suene como un gran avance, y ese es precisamente el punto. Cuando la mejora continua es una parte integral del trabajo diario, la necesidad de lemas pegadizos que inspiren a la fuerza laboral y de una resolución heroica de problemas disminuye considerablemente.• • •

Las empresas gastan actualmente alrededor del 5% de sus ingresos en TI. Si bien hay una gran variación en esta cifra, hay una variación aún mayor en los beneficios que las empresas obtienen de su TI. En todo caso, la ya abrumadora tarea de elegir los sistemas de TI correctos (aquellos que puedan respaldar la estrategia empresarial, ofrecer una ventaja competitiva y servir de plataforma para el crecimiento) es cada vez más difícil. Esto se debe a que las opciones son mayores, cambian más rápido y se hacen más complejas con la llegada de la potencia de procesamiento barata, la capacidad de red y los sofisticados proveedores de TI en las economías en desarrollo.

En un mundo así, las empresas deben centrarse en crear sistemas de TI que no puedan dejar de mejorar. Esta perspectiva puede resultar muy inquietante para el gerente tradicional, que piensa que construir un sistema de TI importante es como construir un almacén: lo construye y luego está terminado. Pero eso ya no funciona para TI. Si adopta ese enfoque para crear sistemas empresariales, obtendrá sistemas rígidos y costosos que quedan anticuados desde el día en que se ponen en marcha. Si adopta un enfoque basado en rutas, obtendrá sistemas flexibles que pueden cambiar según las exigencias de la empresa y que pueden hacer que la TI pase de ser una simple plataforma para las operaciones existentes a una plataforma de lanzamiento para nuevas funciones y nuevos negocios.