Una perspectiva histórica de la TI (V): los sistemas integrados de gestión

Hacemos aquí una pausa para describir la arquitectura típica de sistemas en una gran organización de fines de los ´90.

Esta arquitectura normalmente giraba en torno de un ERP, que cubría, como mínimo todas las funciones de la administración contable y financiera de la Organización.  Este ERP se montaba sobre una plataforma cliente/servidor basada en tres componentes variables (por eso se la llamó arquitectura de 3 "capas" o "layers"): 

·         Software de Gestión de Base de Datos

·         Sistema Operativo de la línea Unix, Windows o propietario de IBM (OS/400)

·         Uno o más servidores para procesar acceso a aplicaciones o bases de datos

Estos tres componentes se podían combinar de diferentes maneras: podía concentrarse el procesamiento en un único servidor o distribuir en varias máquinas.  Dependiendo de cuál fuese el ERP elegido se podían seleccionar diferentes software comerciales de gestión de base de datos, pero cada ERP normalmente era compatible con varios de ellos.  Asimismo, como sistema operativo de servidor se podía visualizar diferentes opciones: las derivadas del Unix en sus diferentes variantes, la línea de Windows desarrollada por Microsoft o distintos sistemas propietarios si uno optaba por IBM, ligados a su hardware.

Arquitectura de 3 capas

 
Esta arquitectura se podía considerar casi totalmente abierta, en teoría uno podía cambiar un componente sin alterar los otros, y la cantidad de opciones a la hora de diseñar la implantación de un nuevo sistema era muy variada, lo que generaba una intensa competencia entre los proveedores de cualquiera de los componentes de la arquitectura.   La propia IBM para defender sus ingresos por servicios informático, terminó actuando como integrador de tecnologías no propietarias (aunque ofreciera, por supuesto, como primera opción sus soluciones propietarias).

En una segunda mirada observábamos que las redes de ordenadores personales habían reemplazado casi totalmente a las terminales “bobas”.  Un microcomputador ofrecía la versatilidad de ser, por un lado, terminal para el equipo central, pero además agregaba la capacidad de ocuparse de todos los otros servicios de oficina que el computador central (y sus terminales) no podían solucionar (redactar e imprimir documentos, presentaciones, planillas de cálculo, enviar mensajes, ejecutar pequeñas aplicaciones para el puesto de trabajo o el departamento).  Todas cosas que las antiguas terminales no podían hacer.

Pero también al estar conectadas en red, agregaban otras ventajas: la posibilidad de compartir archivos situados en diferentes equipos, y hacerlos accesibles desde otras posiciones, la compartición de recursos comunes (faxes, impresoras), la autonomía de la que gozaban para trabajar en su disco rígido propio o de un servidor, por privacidad, contingencia o simple comodidad.  Para el fin de la década del ´90 los costes, la fiabilidad y la velocidad de los enlaces de redes locales entre ordenadores había mejorado mucho y era muy fácil y económico tener una red al menos en cada sede de la empresa.

En una tercera mirada, los equipos mainframe o grandes minicomputadores no habían dejado de exitir, pero su utilización se había especializado hacia aplicaciones donde, por su complejidad o volumen de datos, se requerían un enorme poder de procesamiento para obtener resultados.  Grandes bancos o utilities, por ejemplo, no podían prescindir de estos grandes equipos que seguían pudiendo procesar millones de transacciones en un tiempo bastante menor que las otras líneas de productos.

Los avances en herramientas para enlazar y desarrollar interfases o emulaciones entre equipos de distinta línea también garantizaban la conectividad entre equipos de distinta tecnología y tamaño, con lo cual el hecho de tener obligadamente que hacer coexistir varias tecnologías no era necesariamente ineficiente desde ese punto de vista. 

Entre 1993 y 1998/99, la difusión de esta arquitectura creció exponencialmente en todo el mundo, ayudada también por otros factores externos que colaboraron en acelerar el proceso de cambio y abandono de las antiguas.

Uno de los factores que más influyó fue lo que llamamos la globalización.  Podemos definir es este fenómeno como el brutal proceso de internacionalización de la economía que se dio en la década del ´90 basado en dos fenómenos principales: la caída de barreras comerciales y el abaratamiento de las comunicaciones.

La caída del Muro de Berlín, el proceso de integración europea y otros procesos similares a menor escala en otras regiones (MERCOSUR) trajo como resultado que los mercados potenciales para el crecimiento de una compañía se multiplicaran.  Ahora una empresa tenía posibilidad de exportar o de instalarse en muchos más lugares con perspectivas de éxito.  Muchos países que venían de economías cerradas o dirigidas estaban ávidos de recibir nuevas inversiones, tecnologías y acceder a bienes de consumo y servicios desconocidos.

Por otro lado, las operadoras de comunicaciones, por una mejor infraestructura, la tecnología digital introducida en los ´80, las redes de satélite y cable estaban en condiciones de dar un mejor servicio para mantener “conectadas” a las filiales con su Casa Matriz.  Esto traía varias ventajas: menores costes de implantación (no se duplicaba toda la infraestructura), menores costes de supervisión e información en tiempo real de lo que sucedía en las filiales.

La consecuencia de la globalización fue la adquisición desenfrenada por parte de compañías multinacionales de más filiales en el extranjero.  Luego, la ola de fusiones y adquisiciones que siguió cuando las Compañías tuvieron que ganar economía de escala para poder competir.  La mitad de la década del ´90 nos dejó una economía mundial con menos empresas y más grandes. Esto, sobre todo, se concentró en las llamadas "economías emergentes" (a pesar de recurrentes crisis financieras).

Incremento de la inversión extranjera en países emergentes en los últimos 15 años

Este cambio operó sobre el mercado informático favoreciendo la estandarización de procesos y la homogeneidad de las arquitecturas.   La posibilidad de un liderazgo corporativo más fuerte desde las casas matrices, por las mejores comunicaciones, hizo que el management local perdiera poder e influencia para incluir soluciones locales o no homogéneas en las filiales.  Estas masivamente, sobre todo si eran empresas adquiridas, se vieron obligadas a adoptar diseños de arquitectura de sistema compatibles con sus casas matrices.

En la mayoría de los casos, sobre todo en países atrasados, este fue benéfico y favoreció la competitividad cuando las nuevas arquitecturas reemplazaron a sistemas obsoletos o ineficientes.  En otros casos, impuso soluciones que no se adaptaban totalmente a la realidad de la Compañía y les hizo perder agilidad.  Por otro lado, las operadoras de comunicaciones, por una mejor infraestructura, la tecnología digital introducida en los ´80, las redes de satélite y cable estaban en condiciones de dar un mejor servicio para mantener “conectadas” a las filiales con su Casa Matriz.  Esto traía varias ventajas: menores costes de implantación (no se duplicaba toda la estructura), menores costes de supervisión e información en tiempo real de lo que sucedía en las filiales.

En los procesos de fusión la adopción de una de las dos arquitecturas de sistemas normalmente obligaba a una racionalización de los recursos, y dada la complejidad de este proceso en grandes compañías, era más fácil de abordar en un entorno de paquetes de software.  Además, este proceso de consolidación tuvo por efecto reducir el número de clientes de la industria y aumentar su capacidad de negociación con los proveedores de software y equipos, aunque más no sea por la enorme escala que empezaron a tomar las Compañías.

Pero, al mismo tiempo, que se iban sucediendo estos cambios en las tecnologías de procesamiento central de datos, se iban produciendo avances tecnológicos y nuevas técnicas que gestión que cambiaban un poco la visión de las arquitecturas empresariales.  Estas tecnologías que se desarrollaron o alcanzaron su punto de madurez durante la década del ´90 fueron:

·         La integración de telefonía y ordenadores (Computer-Telephone Integration)

·         La tecnología de extracción de datos y patrones (Datawarehousing y Datamining)

·         La computación móvil (Mobile Computing)

·         La red Internet, concebida como herramienta masiva, y su corolario, la WWW

Estas tecnologías posibilitaron nuevas aplicaciones de negocios, inconcebibles hasta el momento, y su desarrollo tendría una enorme influencia en los años siguientes. A fines de la década del ´90 su uso era ya habitual, aunque más bien orientado a aprovechar ventajas coyunturales en la explotación de la tecnología.  En los años siguientes, estas tecnologías fueron modelando el futuro.

Una perspectiva histórica de la TI (IV):la empresa integrada

En la década de 1980, el término de moda en el Management era “calidad”.  Las regulaciones, el crecimiento de la industria del juicio en Occidente y la competencia japonesa había llevado a las organizaciones a la conclusión de que el diferencial competitivo estaba puesto en la calidad del producto o servicio.  Las empresas buscaban la excelencia como meta, procurando llegar al 0 defecto, implantando mecanismos de control de calidad y aseguramiento de calidad.

Basados en los conceptos de Deming (https://www.deming.org/theman/overview), aplicados por los japoneses durante años, las mejoras de procesos estaban limitadas a cambios incrementales, muchas veces surgidos de sistemas de sugerencias, la mayoría de las empresas había quedado estancada en el uso de la tecnología como una herramienta de productividad o de decisión, sin darle otra preponderancia.

Pero cuando la industria de Occidente se vio superada e invadida por la competencia de Japón y los “tigres” del sudeste asiático, las empresas se vieron en la necesidad de encarar una drástica mejora competitiva para evitar un colapso cierto.  Por otro lado, vieron acertadamente que la calidad había dejado de ser un diferencial.  La calidad se había “comoditizado”, ya había dejado de ser un factor diferencial, cuando el consumidor era incapaz de diferenciar la calidad de un producto “Made in USA” de otro “Made in Japan”.

Así comenzó la era de la "reingeniería", un concepto acuñado por el profesor Michael Hammer (http://eecs-newsletter.mit.edu/articles/2009-fall/remembering-michael-hammer-1948-2008/), del MIT.  Este concepto fue impulsado por un pocos directivos y gerentes creativos que actuaban a su criterio en un contexto inédito, a veces con éxito y a veces no, la experiencia luego era analizada por los “gurúes” del management, plasmada en libros y cursos de posgrado y finalmente, adoptada por consultores y asesores, que la difundieron a todas las organizaciones.  

Hammer volcó estas ideas en un artículo escrito en la Harward Business Review en 1990: "Reengineering Work: Don't Automate, Obliterate" (https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate). Los conceptos básicos luego fueron sistematizados y ejemplificados en uno de los libros más vendidos y de mayor influencia en el mundo de la empresa "Re-engineering the Corporation", escrito por Hammer en colaboración con James Champy en 1993 (http://www.fastcompany.com/1751352/why-companies-will-change-or-fail).
 

El concepto de reingeniería, tal como lo habían definido Hammer y Champy, partía de la base de la “página en blanco”, como símbolo de que en el diseño de los procesos de negocios, había que olvidarse del pasado e imaginar un esquema completamente nuevo de hacer las cosas, que permitira obtener una “mejora dramática”  en los indicadores de gestión de las organizaciones.  En la teoría una idea fascinante, pero que se topó con enormes problemas operativos.

Pinta aquella etapa un chiste tonto que circulaba por el ambiente de la consultoría.  Una cigarra iba a visitar a un consultor de estrategia y le planteaba su problema: “En el invierno, paso hambre, paso frío,y además veo que la hormiga se lo pasa fenomenal, en su casa con comida y calor ¿ Qué tengo que hacer ? El consultor tras pensarlo mucho (y cobrarle unos buenos cientos de miles de dólares a la cigarra) le indica: “Ya lo sé. Lo que tienes que hacer es transformarte en hormiga”. La cigarra no puede ocultar su alegría: “Gracias, gracias. Ya sabía que Usted me iba a ayudar. ¡ Qué buena idea !”. Cuando la cigarra, después de efusivos abrazos al consultor, se da vuelta para irse, de repente, le viene un pensamiento a la cabeza y pregunta: “Pero, ¿ Cómo hago para convertirme en hormiga ?”. El consultor, mientras cuenta los billetes, dice: “Ah, ese es un problema operativo.”

La mayoría de las organizaciones fueron incapaces de reinventar completamente sus procesos de negocios, simplemente era demasiado complejo y caro, aunque uno pudiera imaginar un diseño diferente.  La adaptación de los sistemas de información, las relaciones externas con proveedores y clientes, la resistencia al cambio de las personas, todo era demasiado peso para soportar.  Cuando la reingeniería pasó a ser un concepto usual, se descubrió que una alto porcentaje de empresas que había aplicado la técnica, estaba insatisfecho con los resultados.(http://www.brint.com/papers/bpr.htm).

Pero la necesidad de transformación seguía existiendo realmente y en ese momento la reingeniería se “reinventó” con el auxilio de la industria del software.  Fue entonces cuando explotaron los ERP (Enterprise Resource Planning), nombre asignado por Gartner Group en los ´90 para describir una nueva categoría de software (http://www.gartner.com/it-glossary/enterprise-resource-planning-erp.).

La industria del software hacía años venía avanzando hacia el concepto de “reutilización” del software.  Simplemente, construir cada vez software a medida para cada empresa empezaba a resultar demasiado caro.  Las empresas pedían resultados en menos tiempo, para mejorar su propia competitividad, y a contratar a los proveedores que podían cumplir las entregas más rápido y más barato.  El mercado de software “horizontal”, ya no controlado por los fabricantes, empezaba a hacer más competitivo.

Para muchas empresas de software era imposible esperar a que surgieran, del ámbito académico, herramientas de programación, lenguajes o metodologías de trabajo más eficientes.  Además, estos hallazgos, en caso de éxito, se difundían en cascada a toda la industria anulando cualquier ventaja competitiva.  Algunos innovadores consiguieron desarrollar sus propias herramientas, soportando altas inversiones, pero la mayoría no podía permitírselo.  Otros se dieron cuenta que la mejora de productividad de la industria no era suficiente por ese camino.

La clave para mejorar la competitividad en la industria del software y responder a la creciente demanda de menores costes y plazos de entrega de los clientes era la “reutilización”.  Este era un concepto accesible a la mayoría de las compañías, implicaba que los componentes de software desarrollados por una software-house para un tercero, debían ser reutilizados por este para el desarrollo de los sistemas de otro cliente.

Así se invertía también la tradicional relación de propiedad intelectual.  Normalmente, hasta el momento, se había interpretado que la propiedad del software pertenecía al cliente, y que la software-house era un mero “facilitador”, que traducía funciones manuales en automáticas, mediante su conocimiento de la tecnología.  A partir de entonces, la propiedad del software pasó a ser reclamada por las software-house, que se reservaban el derecho de utilizar esa tecnología en otros clientes.  La aceptación de IBM de las condiciones de Microsoft para pagar una “licencia” por cada PC que se vendiera y que llevara su sistema operativo instalado, fue una muestra de este proceso.

Aunque a los clientes pudiera molestarles que parte de sus sistemas pudiese emplearse en otras compañías, hasta incluso en sus propios competidores, la idea se fue aceptando simplemente porque era imposible evitarlo.   Los clientes de la industria del software aplicativo no tenían la capacidad de controlar que sus programas fueran reutilizados, adaptados, o que el know-how del negocio que tenían que transmitir a los desarrolladores fuese aprovechado para construir sistemas para otras empresas. 

Por supuesto, tenían la alternativa de contratar su propio staff de desarrollo y construir los sistemas con total autonomía interna, y algunos lo hacían históricamente, pero con la presión a la baja de los costes esto era prácticamente inviable para algunas empresas, sobre todo las de menor tamaño.  Así pues el mercado estaba preparado para aplicar el concepto de “reutilización” a gran escala.  Este fue el nacimiento de los “paquetes de software”.

El concepto de “paquete” implicaba la construcción de un software, que incorporara una cantidad de funciones que pudiera ser utilizada en numerosas empresas.  El comportamiento del software debía poder ser modificado no ya con modificaciones al código fuente específicas para cada cliente, sino con modificaciones sutiles en ciertos parámetros o tablas del sistema.  Este concepto ya se utilizaba masivamente para los software con funciones “de oficina” (procesadores de texto, planillas), pero nunca se había explotado masivamente para funciones empresariales más complejas como Ventas, Compras, Producción y otras.

El cliente entonces pagaba una licencia, normalmente acorde con la cantidad de usuarios, para implantar el “paquete de software” y la software house lo asistía para parametrizarlo, formar a los usuarios y transferir los datos iniciales para operar.  Luego, el cliente pagaba un “mantenimiento”, un porcentaje del valor de la inversión inicial que la software house utilizaba para dar un servicio de soporte técnico (telefónico o presencial), y le permitía al cliente acceder a nuevas “versiones” del paquete, que incorporaban errores corregidos o nuevas funcionalidades.

En teoría, la software house debía hacer una inversión inicial importante para desarrollar la primera versión del producto y luego salir a venderlo.  La realidad es que la mayoría reutilizaba los softwares desarrollados “a medida” para algunos clientes, por los cuales habían pagado cada hora de desarrollo a los programadores, y con algunas modificaciones o cosmética, para hacerlos más adaptables, los “paquetizaba” para revenderlos en el mercado.

El concepto de paquete de software se arraigó bastante durante la décado del ´80 y se transformó en ERP cuando se sumaron algunas características nuevas: el concepto de “sistema integrado” y el de “mejores prácticas”. Recordemos que los primeros paquetes de software tendían a tener las mismas características funcionales de los sistemas corporativos “a medida” (eran los mismos de hecho), eran fragmentarios, cubrían sólo necesidades departamentales y no tenían una visión íntegra de la organización.

Pero ¿ En qué consistía el concepto de sistemas integrados de gestión ? Esto es un sistema informático que cubre las necesidades funcionales de todas las operaciones básicas de una organización (comprar, vender, pagar, cobrar, producir), centralizando los datos en un único repositorio corporativo, con la tecnología de base de datos.
 

Antes del ERP

Vale decir, a partir de ese momento los procesos no se analizan a nivel de departamento (el proceso de cobros eran las actividades que se desarrollaban en el área de Cobros), sino a nivel de toda la organización (el proceso de cobros son todas las actividades que se desarrollan desde la emisión de una factura hasta la contabilización del cobro, independientemente de departamento dentro del organigrama donde se desarrolle la tarea).
 

Después del ERP

La nueva posibilidad que brindaba esta tecnología fue un hallazgo salvador para los gerentes y consultores que se veían empujados a mejoras sustanciales de performance, es decir, forzados a la reingeniería.  Ahora disponían de una herramienta para pensar los procesos de una forma diferente, pero apoyados en algo concreto, existente, un sistema informático construido y no por construir.  Pero además la industria del software tomó prestado otro concepto del management, que habría de apoyar todavía más a las empresas en transformación.

En la década de 1990 se difundió el concepto de “benchmarking”.  Este se podría definir como el proceso sistemático de comparar los indicadores de gestión de los procesos de una organización contra otras, con el fin determinar su grado de competitividad.  Un ejemplo podría ser el tiempo promedio de entrega de una cadena de pizzerías contra otra.  Luego, del análisis de los “top performers” es posible determinar los métodos por los cuáles obtienen esa ventaja competitiva, a esto se llamó “best practice” (se puede ampliar el concepto de Benchmarking, leyendo el texto canónico 
de Boxwell ("Benchmarking para Competir con Ventaja", 1994).

A priori, podría parecer que esta era una información altamente confidencial y difícil de conseguir y analizar, pero no lo era tanto. Por diferentes vías, la información se podía obtener.  Organismos de Gobierno recaban datos para sus instituciones de calidad industrial o promoción de la actividad económica, otros indicadores se publican en los informes anuales de empresas que cotizan en bolsa, otras acceden a compartir la información con el requisito de la reciprocidad de la otra parte.  Incluso dentro de la misma organización, es posible hacer una comparación cuando, por ejemplo, departamentos similares, pero en diferentes geografías, ensayan distintos métodos para hacer el mismo trabajo.

La cuestión es que a principios de los 90 existía una cantidad de “mejores prácticas” recopiladas y muchas veces implementadas en los diferentes sistemas de información de sus usuarios.  Lo que los fabricantes de software hicieron inteligentemente, es destacar que sus aplicaciones permitían (ya facilitaban) a las empresas implementar las “mejores prácticas”, reconocidas globalmente.

El valor de este concepto fue esencial para su éxito.  Los enemigos de los “paquetes de software” (una parte de las empresas, como dijimos, se resistía a aceptarlos), señalaban que estos no eran capaces de adaptarse a las características de los negocios de las empresas y que el software a medida permitía si lograr ventajas competitivas.  Ahora, las software house respondían que sus “paquetes” eran integrados e incluían las “mejores prácticas”. El mensaje fue muy bien recibido por un mercado ávido de reingeniería.

Otro factor fundamental para producir este cambio, fue la notoria pérdida de poder de los Gerentes de Sistemas.   Después de 20/30 años de tecnología aplicada a las empresas y, sobre todo, a partir de la popularización de la informática con los microcomputadores en los últimos diez, el management medio de las empresas entendía mucho más de los sistemas y estos dejaban, de a poco, de ser terreno de especialistas.  Muchos miembros de la alta dirección y mandos medios se atrevían ahora de discutir temas técnicos y eran mucho más exigentes con sus gerentes informáticos.

Debido a esto los gerentes usuarios se involucraron mucho más en las decisiones de sistemas y los conceptos nuevos “sistema integrado”, “mejor práctica”, “reingeniería”, sonaban modernos e imprescindibles. Así que, ahora los gerentes y consultores, disponían del ERP como referencia para “repensar” los procesos y, además, adecuar los mismos a las “mejores prácticas” en los procesos de negocios.  Eso sí, una reingeniería exitosa dependía de un cambio de sistema informático, basado en un ERP.

Un último factor colaboró en la explosión de los ERP: el downsizing.  Los primeros ERP requerían de ingentes capacidades de procesamiento para funcionar, por eso aparecieron primero en las empresas usuarias de mainframes o minicomputadores, pero con el correr del tiempo el aumento de la capacidad de procesamiento de los microcomputadores hizo que estos fueran una plataforma viable para los ERP.

Servidor de línea INTEL (Microcomputador)

El aumento de la capacidad de procesamiento, manteniendo bajos los costes de equipamiento, hizo que el cambio hacia una estructura de sistemas basada en ERPs fuese todavía más rentable, dado que muchas veces la implementación del mismo implicaba un “downsizing” de una línea de hardware más cara como los mainframe o minicomputadores, a una red de microcomputadores, basados en la arquitectura cliente/servidor.

Así pues, llegamos al final del camino, las diferentes fuerzas diferenciales (la madurez tecnológica, la fortaleza de la industria del software aplicativo y las necesidades empresariales) nos habían llevado a la arquitectura de sistemas predominante a fines de la década de 1990, centrada en torno de los ERP o sistemas integrados de gestión. A continuación, describiremos este modelo.