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.