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.
Esta web utiliza cookies propias para su correcto funcionamiento. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad