Tal vez sea la insistencia en que el éxito de un negocio no surge en la mayoría de los casos a partir de la tecnología de información que lo soporta, sino como es más lógico, de la validez del modelo de negocios y de la maestría con que es llevado adelante.

Tal vez sea la falta de capacidad de muchos gerentes y consultores para percibir las diferencias en los modelos y propuestas tecnológicas antes de encarar un proyecto, en función de lo complejas que se han tornado las soluciones informáticas y de lo difícil que resulta evaluar alternativas.

Tal vez sea la incredulidad de esos y otros gerentes ante los plazos incumplidos, los presupuestos largamente excedidos, y los sistemas que no llegan a colmar ni el 50% de sus expectativas, esa percepción de remar y remar para estar siempre en el mismo lugar, que genera la ilusión óptica de que todo da lo mismo.

Tal vez sea una combinación de estas y otras razones. La realidad es que con mucha frecuencia se dice y se escribe que la tecnología de información, los sistemas y programas que dan soporte a un proyecto de negocios, pueden ser consideradas un commodity. Cuando sea necesario, aparecerán múltiples proveedores con múltiples soluciones. Alcanzará con elegir uno de ellos, ni el más caro ni el más barato, y la solución tecnológica estará disponible.

Los costos ocultos de una mala solución

La visión que simplifica los problemas tecnológicos asimilándolos prácticamente a un comoditie, a un continuo uniforme de ofertas indiferenciadas, no es capaz de traer a la luz los elementos distintivos de cada enfoque tecnológico y de cómo se adapta este enfoque al problema planteado, focalizándose exclusivamente en elementos de corto plazo: precio, sistema operativo, cronograma de implementación, garantía y mantenimiento.

Las verdaderas diferencias entre una solución y otra no saldrán a la luz sino después que la solución esté en marcha.

Las verdaderas diferencias entre una solución y otra no saldrán a la luz sino después que la solución esté en marcha, y probablemente sus consecuencias, positivas o negativas, impacten sobre el proyecto de negocios generando beneficios o pérdidas mucho mayores a las diferencias de precios que presentaban las propuestas que se evaluaron antes de la implementación. Es más: mejor no es sinónimo de más caro, y no es siempre la solución de mayor costo inicial la que mejor se adapta la las necesidades del negocio. El verdadero trabajo del Gerente de Sistemas es tomar esas decisiones antes de comenzar el proyecto para permitir a la empresa cosechar los beneficios después.

Los costos ocultos, que tienen una manifestación intangible sobre el proyecto, como la dificultad para realizar cambios, la incapacidad de mejorar la performance, la falta de modularidad, la dependencia de una plataforma demasiado rígida, terminan desembocando en el cauce común de la subordinación del proyecto de negocios a las capacidades tecnológicas.

Más allá de que estas realidades se asuman cuando tocan con resignación o con la firme energía de modificarlas, sus consecuencias son nefastas y devastadoras, tanto en costos directos como en pérdida de oportunidades.

A pesar de que para la infinidad de problemas a resolver, la industria informática plantea infinidad de soluciones, es posible indicar algunas líneas de trabajo sobre las características de una solución informática moderna.

Modularidad y encastre

Dentro de las principales características de un sistema informático debe estar la modularidad. No se trata de que las distintas partes del sistema sean bautizadas como «Modulo Contable», «Modulo de Facturación» sino de una característica que cala profundo en la arquitectura de la solución propuesta.

En la informática actual, se está produciendo el proceso de «desencastre» de las distintas partes que componen un sistema informático, generando módulos independientes, que administran un área funcional del sistema y son responsables por todos los datos vinculados a esta área.

En el origen de la informática comercial, en la década del 60 y 70, los sistemas eran un gran bloque de código que accedían a un sistema de archivos «planos» ayudados por indices para mejorar el desempeño. La aparición de las bases de datos relacionales, junto con otras herramientas de programación y especificación de sistemas, permitió el primer paso: separar los datos, almacenados ahora en la base datos, de la lógica de captura y procesamiento de esos datos, dando origen a la primera generación de programas modulares. Bajo esta concepción, los distintos módulos funcionales se comunican entre sí leyendo y grabando datos de la base de datos. Así el modulo de pedidos genera tablas que luego el sistema de facturación transformará en facturas, grabando además las tablas que el sistema contable transformará en asientos. Este modelo resultó mucho más eficiente que el anterior y por ello durante la década del 80 y 90 tuvo una enorme expansión, arrastrando tras de sí la expansión de las bases de datos relacionales.

Sin embargo, este modelo conserva algunos elementos del anterior, que se apoyan en el supuesto del control total sobre los sistemas, equipos en los que se ejecutan y puestos de trabajo desde los que se accede, supuesto que la aparición y desarrollo comercial de Internet ha dejado fuera de la realidad. Derivado de este supuesto, los programas o módulos quedan «encastrados» o «enganchados» fuertemente unos con otros. Por ejemplo: el sistema de seguridad, ya sea que deriva de la base de datos, del sistema operativo o que está incluido en la propia aplicación, es un elemento indisoluble de la aplicación y a su vez ésta es incapaz de considerar otros elementos de seguridad que éstos. De este modo, un usuario manejará sólo para los sistemas internos de la empresa numerosos usuarios y contraseñas.

La sustitución de la comunicación entre módulos a través de la base de datos, por servicios de mensajería, genera un paso más en la modularización, y es el modelo de construcción modular que se ha popularizado hoy día. A diferencia del modelo anterior, si el sistema de facturación quiere conocer un pedido, no busca en una tabla de la base de datos, sino que envía un mensaje al sistema de pedidos solicitando la información. El cambio tiene como resultado módulos más independientes, más fáciles de mantener, con menos errores y lo que es más importante, con la libertad de elegir en cada instancia si desarrollarlo internamente, si comprarlo a un proveedor que lo desarrolle a medida, o si comprar un producto ya existente en el mercado.

Ni siquiera es imprescindible que los datos residan en un almacén de datos único, es aún menos trascendente el lenguaje de programación o los detalles internos de la implementación de cada módulo.

Hardware vs. Software

Desde los orígenes de la informática a nuestros tiempos, se vienen dando dos procesos inversos y complementarios: el software es cada vez más complejo y costoso y el hardware es cada vez más eficiente y barato.

Esta realidad incontestable, que nos cuenta que hace 20 años equipos con 128 kilobytes de memoria (si, 128 kilobytes) soportaban decenas de terminales, generó en el pasado una concepción del desarrollo de aplicaciones, basada en la optimización infinita del equipamiento, del ahorro sistemático de cada bit de memoria, de cada ciclo de procesador, de cada byte almacenado en disco.

Las herramientas asociadas a forma de pensar de hace 20 años siguen vigentes, y generan programas y aplicaciones más parecidos a la época en la que un bit de memoria era una pepita de oro, que a la época en la que es imposible comprar un disco de menos de 60 GB.

Esa concepción, fielmente reflejada en la literatura informática, en las herramientas de desarrollo y en las metodologías y costumbres de trabajo de los programadores, están perimidas no porque sean viejas o estén pasadas de moda, sino porque hoy la ecuación de costos se ha invertido. Afirmaciones como «todo buen programa es al final retocado en assembler» o recomendaciones de los libros sobre sentencias de programación que ahorran «un ciclo de procesador» suenan hoy vetustas. Pero las herramientas asociadas a esa forma de pensar siguen vigentes, y generan programas y aplicaciones más parecidos a la época en la que un bit de memoria era una pepita de oro, que a la época en la que es imposible comprar un disco de menos de 60 GB.

 Las herramientas de desarrollo modernas proveen mayor productividad a los programadores, al costo de ser menos eficientes a la hora de consumir equipamiento: megahertz, memoria y disco. Pero hoy en día es prácticamente siempre más económico y eficiente comprar un equipo más grande, que agrandar el equipo de desarrollo. Se cuentan con los dedos de una mano las excepciones a esta regla, y no hacen más que confirmarla.

La funcionalidad adecuada

La consolidación del mercado de aplicaciones constituye un avance dentro de la industria informática, y presenta una ventaja enorme a la hora de implementar el soporte informático para un proyecto de negocios. Pero ha traído aparejado un nuevo problema: el sobredimensionamiento funcional.

En la búsqueda de la mejor solución, las empresas se deciden por la implementación de paquetes de software que exceden largamente sus necesidades, en el entendido de que mayor funcionalidad trae necesariamente aparejados mayores beneficios.

La experiencia muestra que la funcionalidad excedente no se utiliza y por tanto no aporta valor, pero sí aporta complejidad adicional y un enorme lastre a la hora de realizar cambios y modificaciones.

La funcionalidad excedente no se utiliza y por tanto no aporta valor, pero sí aporta complejidad adicional y un enorme lastre a la hora de realizar cambios y modificaciones.

Las consecuencias de la complejidad se amplifican a medida que ésta aumenta y los problemas asociados a mantener y administrar soluciones más complejas cambian no solo cuantitativamente sino cualitativamente con el crecimiento de la complejidad de la solución. A esto se suma que en informática más tamaño es sinónimo de más complejidad.

Encontrar la medida justa, una característica que el desarrollo hecho en casa generaba en forma natural, se ha transformado en objetivo a perseguir. Movimientos como KISS (Kip It Simple Stupid) buscan reflejar esta problemática, no a través de una burda simplificación de los problemas planteados y las soluciones adoptadas, sino a través de la justificación explícita de los beneficios asociados a una solución más compleja.

Herencia y convivencia pacífica

Toda empresa existente ya tiene sistemas. Y éstos son como son, no como uno desearía que fueran. El desafío es que estos sistemas «heredados» evolucionen en la medida que se implementan nuevos proyectos, que se realizan cambios o que se incorpora nueva funcionalidad hacia un modelo de desarrollo informático más flexible y adaptado a las necesidades de negocios de la empresa.

El desafío está en cortar la inercia, y comenzar a modularizar, aislando los sistemas viejos, monolíticos, para poder incorporar sistemas con arquitecturas más livianas. No es común encontrar empresas que decidan la sustitución total de los sistemas, y cuando lo deciden, muchas veces los proyectos no llegan a buen puerto: es sano evitar todo lo que se pueda los megaproyectos. Pero esta estrategia no lo limita a reproducir siempre los sistemas que comenzó a desarrollar hace 20 años, tal como los desarrollaba hace 20 años. Es posible desencastrar áreas enteras de funcionalidad y comenzar la sustitución por módulos de software más adecuados a los requerimientos de negocios de una empresa de hoy día.

El desafío está en cortar la inercia, y comenzar a modularizar, aislando los sistemas viejos, monolíticos, para poder incorporar sistemas con arquitecturas más livianas.

Tal vez usted piense que se trata de un preciosismo teórico, tal vez crea que es un lujo que su empresa no se puede dar. Si algún día toma la decisión de postergar o sencillamente no desarrollar un negocio porque ni siquiera quiere discutir el tema con su gerente de sistemas, entonces es porque le llegó la hora de pagar los costos ocultos de un problema real y tangible que crece en importancia en la medida en que crecen en importancia los sistemas dentro de la empresa.