The Infonomics Letter – Enero de 2010

¿Sabemos lo suficiente?

Hola y bienvenidos a la primera edición de The Infonomics Letter de 2010.

Hace apenas diez años, todos tuvimos un suspiro de alivio. Cuando el reloj marcó el 1 de enero de 2000, notablemente, el mundo no se acabó. Los aviones no se cayeron del cielo. Los bancos no dejan repentinamente el procesamiento de las transacciones. Ni esos mismos bancos ofrecieron  las esperanzas fantásticas de algunos que iban a llenar cada cuenta con decenas de millones de dólares, de forma gratuita. El temor del error Y2K no nos había golpeado después de todo. La inmensa inversión en los sistemas de corrección nos había salvado – ¿o lo teníamos? Muchos escépticos, incluyendo más de unos cuantos directores de empresa, siguen insistiendo en que Y2K fue un desperdicio de dinero impulsado por los profesionales histéricos de IT que habían alcanzado el pináculo de gastar dinero para no lograr un beneficio empresarial.

Ese tipo de pensamiento equivocado es increíblemente peligroso, y el 1 de enero de 2010, algunos bancos de Australia lo demostraron, cuando un remanente latente del problema del Y2K resulto en el rechazo de las transacciones Eftpos. «Prueba el Futuro», explora la situación un poco más.

Con demasiada frecuencia, se habla de estancamiento en importantes proyectos de IT debido a la falta de conocimiento de cómo operan los viejos sistemas. Y a medida que más y más de la empresa queda enterrada dentro de la tecnología de la información, los riesgos de perder el conocimiento esencial empiezan a ser más sustancial. En «¿Cómo funciona de nuevo», comenzamos a explorar la necesidad de las organizaciones de adoptar medidas positivas para garantizar la permanencia de sus conocimientos empresariales esenciales.

Muchos de los que han asistido a una de mis exposiciones o eventos educativos, recordarán que ilustro la importancia del gobierno de IT citando los casos de todo el mundo en el que las principales fallas de IT, han causado daños a la organización. Uno de estos casos es el de British Sky Broadcasting, que contrató a una importante empresa internacional para ofrecer un sistema de Customer Relationship Management. Cuando el proyecto fracasó, el lío terminó en los tribunales, y hace apenas unos días, el juez dictó su decisión. «Una decisión interesante» abre el debate sobre esta decisión muy importante.

El nuevo grupo de trabajo internacional responsable de la ISO 38500 y las normas correspondientes, está construyendo una cabeza de vapor, y el trabajo se está comenzando en varios frentes. «Fomento de la norma» ofrece una instantánea de lo que está sucediendo en este campo.

Cordiales Saludos, Mark Toomey, 31 de enero 2010

Prueba el futuro

El 1 de enero de 1997, el cajero automático operado por uno de los principales bancos de Nueva Zelanda comenzó a confiscar las tarjetas. No por primera vez, el Y2K había mordido una organización sin preparación. Inmediatamente, muchos podrían decir: «Eso fue tres años antes del cambio de milenio – ¿Cómo podría haber sido el Y2K»?

El problema era simple. Todos los bancos emiten nuevas tarjetas de cajero automático en un ciclo regular, y algunos lo hacen cada tres años. El banco había, en las semanas inmediatamente anteriores, emitido los primeros lotes de tarjetas que expiraban en el nuevo milenio – en enero de 2000. Los cajeros automáticos no entendían y se comportaban como si las nuevas tarjetas habían expirado en 1900 – confiscando el lote.

Puesta al día, 1 de enero de 2010, y las máquinas de Eftpos operadas por al menos un banco en Australia comenzó a rechazar las transacciones, reportando que las tarjetas habían expirado. Parece que las máquinas habían avanzado su fecha 31 de diciembre de 2009 hasta  1 de enero de 2016, y como casi todas las tarjetas en cuestión tienen fechas de vencimiento entre enero de 2010 y diciembre de 2013, las máquinas pensaron que habían expirado todas esas tarjetas. Las máquinas no funcionan y el banco, y sus clientes que usan las máquinas Eftpos, ¡comenzaron a perder ganancias!

La causa técnica exacta del problema no es importante. Lo más probable, es el producto de los trucos tecnológicos utilizados para ganarle vida extra al software que, de otro modo, habrían muerto en el período previo a 2000. Lo que es críticamente importante para los directores, ejecutivos de negocios y ejecutivos de tecnología, es recordar que muchas de las técnicas usadas para superar el Y2K hace diez años suponían trucos técnicos. No había ni tiempo, ni dinero, ni experiencia para reemplazar o volver a escribir cada pieza de software para que nunca más volviera a encontrarse con un problema de comprensión de fechas. El engaño significa que con el tiempo ¡el problema volverá!

Un solo incidente de un banco australiano fue noticia mundial, causado perturbaciones considerables y ansiedad, y les costará muy caro a los responsables elaborar y desplegar una corrección. Imagínese lo que habría sucedido si este problema no se limitaba a unos pocos cientos de dispositivos Eftpos, sino que, hubiera «aparecido» en los sistemas de check-in de las líneas aéreas. Hoy en día, en una medida mucho mayor que en 2000, las organizaciones dependen de la tecnología de la información para las operaciones del día a día en el punto de interacción con el cliente, así como para las tareas de rutina como la contabilidad, control de inventario y gestión de la producción. Esa dependencia amplifica la importancia de estar seguros de la viabilidad hacia delante de los sistemas clave de IT.

Para proporcionar esa seguridad, las organizaciones deben tener en cuenta:

• Los sistemas de pruebas de forma rutinaria con las fechas en el futuro, para demostrar de manera concluyente si funcionan o no correctamente. Esta prueba va más allá de solamente entrar fechas futuras de las transacciones – requiere un entorno de prueba en donde las fechas reales de funcionamiento de los equipos se fijan en el futuro – como
  son estas fechas que a menudo controlan la lógica interna de sus sistemas. Poner el reloj de dos a cinco años en el futuro debe dar un aviso de problemas inminentes, y el tiempo para solucionarlos
• Mantener un catálogo de todos los sistemas de software en uso, destacando en cada sistema si utiliza o no «trucos técnicos» para producir resultados correctos  mientras que almacena sólo dos dígitos del año en los principales fechas. La mayoría de esos «trucos técnicos» tiene una fecha de expiración propia, y después de más de diez años, algunas de las fechas de caducidad puede estar terriblemente cerca.
• Investigar el software anterior para determinar si tiene algún otro problema como los del Y2K que puedan morder en el futuro. Como un programador de la década de 1970, recuerdo claramente, por ejemplo, una técnica de almacenamiento de datos que funcionó a la perfección hasta el final de 2002, y luego fue completamente errónea.

Para asegurarse que están cumpliendo con sus obligaciones con respecto a la viabilidad operativa en curso de sus organizaciones, los directores deben hacer preguntas para confirmar que se han tomado las medidas apropiadas para garantizar que el riesgo de problemas asociados con la fecha han sido adecuadamente reconocidos y gestionados.

Para aquellos que se preguntan cómo esta situación podría producirse, puedo explicar mediante una analogía comparando la evolución de la tecnología informática a la de los automóviles. El equipo informático sobre el que hemos construido los sistemas clave de negocio en la década de 1970 y el 80 estuvo lejos de ser primitivo. Pero si consideramos que los primeros computadores como el equivalente de los primeros automóviles pesados de Benz, de Dion, entre otros, los computadores de los 1970’s y 80’s fueron más el equivalente al Modelo T de Ford y de la amplia gama de marcas que surgieron durante las tres primeras décadas del siglo pasado. En comparación con los automóviles modernos, los coches de segunda generación tenían una capacidad muy limitada, fueron notablemente diferentes de un fabricante a otro, complejos de operar, confiables y muy caros. Cuando se construyen complejos sistemas de negocios en esa generación de hardware, era esencial hacer la utilización más eficiente de los escasos y caros recursos. Es por eso que hicimos cosas que hoy parecen locas – como el almacenamiento de sólo  dos dígitos de la fecha. Por supuesto, pocos de nosotros realmente esperaba  que los sistemas diseñados siguieran  funcionando treinta o más años más tarde – pero esa es la realidad que hemos heredado de la demanda incesante de mayor capacidad de negocios que en algunos casos, reemplaza el sentido común en las decisiones que deberían haber sustituido muchos sistemas antiguos hace años!

¿Cómo funciona de nuevo?

Cerca de trece años atrás, mientras gestionaba la reparación Y2K de un sistema de la línea de gestión en una de las empresas de telecomunicación más importante, descubrí que el desarrollador de software externo había perdido el código fuente de aproximadamente el 30% del sistema. Normalmente, esto no sería un problema. La parte del sistema afectado era funcionalmente muy estable – no habían sido necesarios cambios durante un tiempo bastante largo. Pero tenía un montón de funcionalidad relacionada con la fecha que no funcionaba correctamente después del año 2000, y era esencial repararlo. Sin código fuente, la única vía posible de reparación era reescribirlo. Entonces, surgió el próximo problema – el sistema era bastante viejo, y quedo poca gente con una comprensión de cómo operaba es parte de la empresa. Hubo tiempos llenos de tensión mientras experimentábamos y producíamos un torbellino de ideas para descubrir cuál  había sido el conocimiento básico de una generación anterior de trabajadores.

La pérdida de la memoria corporativa en relación con la función de los sistemas informatizados de negocios no es un problema nuevo. Se destaca en muchas situaciones donde las organizaciones deciden sustituir un sistema de software desarrollado años antes, y fue uno de los problemas documentados por el Australian National Audit Office en su revisión de 2006 del Sistema de Gestión de cargas del Servicio de Aduanas de Australia. Muchas organizaciones carecen de la disciplina para producir un registro detallado y preciso de las reglas de negocio y las especificaciones, en su afán de producir resultados y de sus esfuerzos equivocados para ahorrar dinero. Muchos más han producido una documentación adecuada al principio, pero han
fallado en mantenerla actualizada a medida que se produjeron cambios en la empresa y el medio ambiente. Enterrado en el corazón de los sistemas de software, en muchas organizaciones grandes, hay código críptico y complejo de las primeras generaciones de informatización, que es prácticamente incomprensible para todo el mundo. El temor a romperlo causa que las organizaciones no quieran  cambiarlo, e incluso evitar reemplazarlo. Los nuevos sistemas, en lugar de remover el software antiguo, están en cambio dando vueltas alrededor de él, heredando sus limitaciones y fragilidad, y construyendo un núcleo misterioso mayor para los que en el futuro que deben implementar el cambio.

En generaciones anteriores, las organizaciones celebraron un seguro contra las pérdidas – con muchas personas pasando toda su  vida en una organización. Esa gente absorbió las formas de la organización, y la mantuvo unida cuando las cosas iban mal. Cuando las personas con los conocimientos a largo plazo desaparecen, a menudo es el caso de que las cosas empiezan a salir mal. Recuerdo la historia de un edificio y los servicios de una empresa de ingeniería vendidos
por sus fundadores a un inversor. El inversionista nombró un nuevo equipo directivo con MBA frescos, y lo primero que se hizo fue una auditoría de eficiencia – un paso natural para aquellos que buscan maximizar la rentabilidad de los fondos invertidos. La auditoría identificó un pequeño grupo de «señores» que no parecían tener ningún papel, y por lo tanto fueron despedidos. Estos eran los «defensores de la vida» que sabían cómo trabajaba toda la compañía, que podrían detectar un problema inminente a un kilómetro, y que podían entrar en la recámara en un instante para mantener el balanceo de negocios, independientemente de lo que iba mal. Sin ellos, los pequeños problemas se convirtieron rápidamente en grandes catástrofes y, fallas menores se convirtieron en costosas interrupciones. La medida del ahorro resultó contraproducente, y la empresa se perdió en el olvido.

Ahora bien, esto no es un argumento para mantener el personal por largo plazo, o para evitar el cambio. Más bien, es un argumento para invertir en la construcción y preservación de los conocimientos de cómo funciona el negocio – especialmente en su cadena de valor central.
Hoy en día, gran parte del conocimiento está enterrado dentro de los sistemas informáticos, y pocos son los que tienen una clara comprensión de los detalles. Esta escasez de los conocimientos incorporados ahora se agrava por la tendencia hacia el empleo de corto tiempo, a menudo asociado con las generaciones más jóvenes. Con más funciones de la empresa siendo tercerizadas y subcontratadas, y con individuos que persiguen objetivos económicos, sociales y de status que los tienen fuera del trabajo casi antes de entrar en él, existe un riesgo creciente de que las operaciones básicas de algunas organizaciones, se conviertan en un completo misterio. Cuando se desarrollan tales misterios, la organización puede estar en riesgo de fallos operativos imprevistos y de mayor costo, retrasos y resultados sub-óptimos en la aplicación de los cambios.

Otras acciones que las organizaciones toman parecen reforzar la percepción, si no la realidad de que las organizaciones están perdiendo la capacidad de entender cómo funcionan. Piense en su trato con un banco. Una generación atrás, podía llevar un problema para el director del banco, y sería resuelto – no necesariamente en su favor, pero por lo menos con la claridad de entendimiento sobre lo que comprendía la resolución. Hoy en día, los problemas bancarios implican interminables discusiones con el personal del centro de llamadas, supervisores y otros, muchos de los cuales evidentemente saben menos acerca de cómo opera un banco que usted, el cliente. No es difícil imaginar que en muchos casos al  tratar los problemas, algunos de los tratan no sólo no conocen el negocio y sus normas – sino que están inventando problemas sobre la marcha.

La ejecución de una organización eficiente y eficaz conlleva una demanda inherente de que sepamos cómo funciona la organización. La mejora de una organización para que sea más eficaz y más eficiente extiende la demanda, de manera que podamos planificar y ejecutar el cambio de una forma que no cree consecuencias inesperadas. Es cada vez más claro que, para comprender, gestionar y mejorar la forma en que opera una organización, es necesario disponer de un medio para mantener una imagen completa y exacta que pone todos los elementos de la operación en su contexto – que nos permite comprender el diseño de la organización.

La disciplina que establece ese conocimiento es conocida como la arquitectura empresarial (EA).

Ya en octubre de 2009, The Infonomics Letter se centró fundamentalmente en el tema de la arquitectura empresarial. He mencionado una discusión que se había desarrollado en el sitio internacional de negocios la red LinkedIn, donde cientos de puntos se habían hecho en una discusión sobre el propósito de la arquitectura empresarial. Esa discusión no ha disminuido, y ahora tiene cerca de 1.000 entradas. Para mí es evidente que muchos de los involucrados en el debate vienen desde la perspectiva de la operación. Pocos la están abordando desde el punto de vista del cliente.

La discusión en este artículo señala el problema del aumento del riesgo y la realidad de las organizaciones de perder el conocimiento importante de cómo funciona. Se sugiere que la arquitectura empresarial es una disciplina que mantiene y aporta los conocimientos pertinentes. Pero ahora, plantea una Pregunta: ¿Quiénes son los usuarios o clientes por los servicios prestados por la Arquitectura Empresarial?

Puede ser intuitivamente obvio que los clientes de la arquitectura empresarial son los que tienen la responsabilidad de mantener y desarrollar el negocio. En última instancia, este es el equipo de gestión ejecutiva y el consejo de administración. Como los responsables de dirigir, controlar y mejorar la organización, necesitan tener acceso a un conocimiento preciso sobre cómo trabaja la organización, con el suficiente detalle y claridad para que puedan mantener la estabilidad y hacer cambios cuando sea necesario, a un costo razonable y sin ningún riesgo inaceptable de consecuencias imprevistas.

Así como la tecnología de la información es una herramienta de negocios, también lo es la arquitectura de la empresa, una herramienta para los líderes de negocios. Mientras que IT permite que las empresas operen de nuevas formas, diferentes y más eficaces, la arquitectura empresarial permite a los líderes de negocios entender, adaptar, refinar y mejorar la forma en que opera la empresa. En efecto, la arquitectura empresarial proporciona un plan detallado para la empresa. Una arquitectura completa posicionará claramente a la organización en su contexto de negocio, permitiendo que los factores externos y limitaciones sean siempre entendidos cada vez que se contemple el cambio.

En una organización pequeña, puede ser posible que el conocimiento que se describe en una arquitectura empresarial permanezca en la cabeza de un individuo o un grupo pequeño. Pero, incluso en este contexto, es probable que la planificación de cambio se traduzca en al menos algo de ese conocimiento, en forma de diagramas y listas utilizando algún medio que soporta la visualización y la retención a largo plazo. ¿Cómo pueden las organizaciones más grandes mantener y comunicar esos conocimientos?

Los directores y ejecutivos de medianas y grandes organizaciones deben preguntar si tienen suficiente conocimiento preciso de cómo opera su organización, y deben asegurarse que el conocimiento puede ser utilizado efectivamente en apoyo de la planificación y ejecución del cambio, y que seguirá siendo exacto y pertinente a medida que avanza el cambio.

Una decisión interesante

Es una triste realidad que el litigio se ha convertido en un compañero de rutina en las principales iniciativas de IT. Hay muchos casos donde los problemas con un proyecto se han traducido en la organización que encargó el proyecto peleando en un tribunal con uno o más proveedores de equipos, software y servicios.

Uno de los casos de interés de alto perfil acaba de llegar a un clímax en los tribunales británicos. British Sky Broadcasting (BSkyB) demandó a EDS por el fracaso de un proyecto de Customer Relationship Management, que comenzó en el 2000. BskyB rescindió el contrato en 2002, y puso en marcha una acción legal en 2004. Las audiencias en el caso se abrieron en 2007, y la sentencia fue dictada hace unos días, el 26 de enero de 2010.

El caso BskyB es interesante por dos razones: primero porque la demanda de BSkyB fue por daños y perjuicios de £ 709m, mucho mayor que el valor de £ 48m del contrato y, segundo, porque el juicio está a favor de BSkyB!

La reclamación por £ 709m se basó en la estimación de BSkyB de los beneficios que habían perdido como resultado del fracaso de la iniciativa. Esto es significativo, ya que ofrece una rara visión del valor potencial de las inversiones en IT. Sin ahondar en los detalles de los hechos del caso, se puede ver que BSkyB esperaba mucho de esta inversión. Los comentaristas estiman que a BSkyB se le otorgarán al menos £ 200 millones, siendo cuatro veces el costo del proyecto abandonado. Uno puede inferir que BSkyB ha proporcionado pruebas concluyentes de la cantidad, al menos, de un posible retorno de la inversión, junto con las pruebas que tenía de los medios necesarios para entregar realmente el beneficio.

Según informes de prensa de Gran Bretaña, las bisagras de la sentencia gira sobre la evaluación de las declaraciones realizadas por EDS durante la etapa de pre-ventas del contrato. Según ComputerworldUK.com: «El tribunal de Justicia de Tecnología y Construcción confirmó que [BSkyB] afirma que EDS ha tergiversado de manera fraudulenta sus capacidades de hace diez años, cuando aplicaba para un contrato para entregar un sistema de £ 48 millones».

En efecto, la sentencia pone en duda las clausulas del «Acuerdo total» en los contratos, y abre la puerta a demandas de representación fraudulenta por los vendedores.

Sin duda, habrá un debate considerable en este caso, cuando los nuevos propietarios (HP) de EDS decidan si proceden o no con la apelación, y como organizaciones a nivel mundial examinan las consecuencias de sus propias situaciones.

Los directores de organizaciones que han dedicado y experimentado problemas con los proveedores externos, podrían considerar la revisión de los contratos y los comparen con relaciones anteriores antes de  contratar, para determinar si existen diferencias sustanciales y pertinentes.

Los directores de las empresas que prestan servicios podrían considerar la revisión de las prácticas y tácticas de pre-ventas, con el fin de garantizar que hay congruencia entre el contrato y los demás elementos de la oferta.

Fomento de la Norma

El grupo de trabajo internacional, formado bajo los auspicios del Comité Técnico Conjunto de la ISO y la IEC para gestionar y desarrollar las normas relativas a la gobernanza de IT  celebró su segunda reunión en Singapur en diciembre de 2009. La reunión fue amablemente organizada por el organismo de normas nacionales y acreditación de Singapur, SPRING y la Universidad Nacional de Singapur.

El grupo de trabajo ahora tiene varios proyectos en curso para desarrollar:

• Orientación para la aplicación de la norma ISO / IEC 38500;
• Una revisión y actualización de la norma ISO / IEC 38500;
• Un modelo para describir la relación entre el gobierno y la gestión en el contexto de IT;
• Un plan de negocios para el grupo de trabajo.

La próxima reunión del grupo de trabajo está prevista para Helsinki, Finlandia, del 3 a 5 mayo de 2010.

Encuesta Global sobre Gobernabilidad

El desarrollo de un plan de negocios para el grupo de trabajo internacional, requiere una comprensión de las necesidades del mercado y la demanda. Para ayudar al grupo de trabajo para desarrollar su comprensión del mercado, Infonomics ha desarrollado y en breve iniciará un estudio internacional para explorar el estado del arte en la gobernanza de IT. Las invitaciones para participar en la encuesta se distribuirán ampliamente, a través de numerosos canales, incluyendo la lista de abonados a The Infonomics Letter.

Vínculos rotos

El artículo en la edición de Diciembre de 2009 acerca de la Task Force del Gobierno de Australia 2.0, contenía comentarios y enlaces sobre la Arquitectura del Gobierno de Australia versión 1.0.
Estos comentarios y enlaces fueron escritos en una presentación ante el Grupo de Trabajo el 16 de diciembre. Quién habría pensado que en el período comprendido entre esa fecha y la publicación de Infonomics, la Australian Government Information Management Office (AGIMO) habría sigilosamente lanzado una nueva versión de la Arquitectura del Gobierno de Australia. Los detalles pueden ser encontrados en: http://www.finance.gov.au/e-government/strategy- and-governance/australian-government- architecture.html

Una búsqueda rápida revela que no hay anuncios, comunicados de prensa o informes sobre la nueva versión de la AGA. El único vínculo que se encuentra en «lista de publicaciones más reciente del Departamento». ¿Cómo pueden las agencias y sus proveedores de servicios enterarse?

Waltzing with the Elephant

¿Se ha unido a la multitud de lectores entusiastas? Vea por qué los lectores aman Waltzing with the Elephant en el sitio web de Infonomics.

“Translated, with permission, from the original at  http://www.infonomics.com.au written by Mark Toomey, Author of book “Waltzing With The Elephant”.

“Traducido, con permiso, desde el original en http://www.infonomics.com.au escrito por Mark Toomey, autor de “Waltzing With The Elephant”.

Compartir