Rediseño de Negocios Usando Patrones
Compartiendo Pr�cticas para Aumentar la Productividad

Indice del Cap�tulo

11.1 El mercado del conocimiento de procesos
11.2 Un modelo digno de considerarse: open source software
11.3 El desarrollo de patrones y software de apoyo
11.4 Consecuencias para la educaci�n
11.5 Consecuencias para el desempe�o de las empresas

CAPITULO 11: CONSECUENCIAS DEL ENFOQUE PROPUESTO

En este cap�tulo examinamos algunas consecuencias que se derivan del enfoque de patrones propuesto en este libro, las cuales, as� lo estimamos, abren posibilidades insospechadas en la mejora de las pr�cticas de gesti�n y desarrollo de software de apoyo. Al mismo tiempo, entregamos nuestra percepci�n acerca de c�mo se pueden desarrollar y proyectar los patrones hacia el futuro.

11.1 El mercado del conocimiento de procesos

El conocimiento asociado a las pr�cticas de gesti�n –particularmente aquellas incorporadas en los procesos– y el software de apoyo al funcionamiento organizacional, han tenido una oferta que ha ido variando en el tiempo. As�, poco despu�s de la introducci�n del computador, en las d�cadas de los 60 y 70, este conocimiento era fundamentalmente propietario, ya que las pr�cticas de trabajo y, especialmente, el software de apoyo eran desarrollados en forma particular para cada empresa. Esto hac�a dif�cil que otras empresas pudieran profitar del tal conocimiento, ya que los mecanismos de transferencia –por ejemplo, contrataci�n de personal con experiencia en otras empresas, publicaciones profesionales e instituciones educacionales– no eran eficientes.

La situaci�n anterior cambi� significativamente en las d�cadas posteriores, en cuanto a accesibilidad al conocimiento de gesti�n, al masificarse el uso del computador y aparecer los paquetes de software de apoyo a la gesti�n –finanzas y contabilidad, producci�n, ventas, personal y otros– y al producirse una codificaci�n de la gesti�n en "mejores pr�cticas" por parte de las empresas consultoras. Sin embargo, el conocimiento sigui� siendo propietario, pero disponible para aquellas empresas que pudieran pagar, debido al costo del software y/o de la consultor�a en mejores pr�cticas. Adem�s, el mercado se segment� de acuerdo con las posibilidades de pago de las organizaciones. As�, existen soluciones econ�micas de paquetes de software de gesti�n –en el orden de unos pocos miles de d�lares– que tienen pr�cticas de trabajo impl�citas que debe descubrir y adaptar el usuario, sin apoyo de consultor�a, ya que �sta ser�a mucho m�s cara que el producto.

Un segmento intermedio –con rangos de precios de varias decenas de miles y unos pocos cientos de miles– tampoco contiene pr�cticas de trabajo expl�citas, pero el software provee una serie de par�metros y opciones que permitir�an adaptar, dentro de ciertos l�mites, el apoyo computacional a los procedimientos que la empresa utiliza o a otros redise�ados; por ejemplo, una opci�n para pagar autom�ticamente a proveedores a partir de lo consumido de bodega, para situaciones en que ellos manejan el stock que queda en consignaci�n. Sin embargo, pocas empresas usan esta posibilidad de manejo expl�cito de procesos y se conforman con implementar los paquetes en forma r�gida, eligiendo par�metros u opciones por defecto –excepto aquellos que, obviamente, deben adaptarse, como tasas de IVA, leyes sociales e impuestos y plan de cuentas de la contabilidad. Esto se debe a que el esfuerzo de analizar procesos, sin tener elementos expl�citos de referencia, es complejo, demoroso y requiere de consultores especializados que son costosos.

Por �ltimo, tenemos el segmento alto de software de gesti�n –sobre medio mill�n de d�lares–, el cual s� define pr�cticas de gesti�n expl�citas. Estas toman la forma de modelos de referencia [20] –en la terminolog�a de uno de los proveedores l�deres–, los cuales son modelos de procesos que atacan en forma superficial las pr�cticas de trabajo, enfatizando, m�s bien, el apoyo computacional al proceso. Sin embargo, proveen muchas opciones de manejo de un proceso, por medio de la posibilidad de seleccionar entre cientos de modelos de referencia alternativos –por ejemplo, para planificaci�n de producci�n en empresas que fabrican en forma discontinua (job shop) o para empresas de producci�n continua– y de adaptar un modelo de referencia particular a un caso espec�fico, junto con el software de apoyo, por medio de par�metros y opciones –por ejemplo, para manejar inventario de productos o trabajar just in time. El esfuerzo de adaptaci�n de los modelos de referencia y del software es complejo y requiere especialistas de alto nivel –teniendo muchas de las empresas internacionales l�deres de consultor�a grupos que proveen este tipo de apoyo– que son, tambi�n, de significativo costo^*. Esto ha hecho que muchas empresas grandes –que te�ricamente pueden pagar tales costos– hayan evitado el uso de los modelos de referencia y, por lo tanto, el an�lisis de los procesos, centr�ndose en la adaptaci�n indispensable del software para que calce con la situaci�n vigente. De hecho, algunos consultores de empresas internacionales declaran expl�citamente que, para asegurar el �xito en la implementaci�n de estos paquetes, deben realizarse los menos cambios posibles en el software empaquetado [18]. Adem�s, los proveedores de �stos han reaccionado ante esta tendencia proveyendo v�as r�pidas de implementaci�n que tienen como filosof�a la de m�nimo cambio en el software y, por lo tanto, en las pr�cticas del proceso.

Todo lo anterior nos lleva a concluir que el mercado del conocimiento de manejo de procesos, envasado en paquetes de software de gesti�n, tiene una oferta que –por las rigideces y dificultades de adaptaci�n de tales paquetes– no facilita ni promueve la innovaci�n en las pr�cticas asociadas a los procesos.^*

Se podr�a argumentar, no obstante, que se puede aplicar conocimiento de manejo de procesos, no envasado en software –disponible en la literatura y por medio de especialistas calificados–, para redise�arlos e implementarlos con software hecho a la medida. Sin embargo, esta posibilidad es cada d�a menos eficiente, ya que el costo de construir software desde cero tiende a encarecerse en comparaci�n al de los paquetes. Adem�s, el riesgo de que las aplicaciones a la medida funcionen con enormes demoras o, que no funcionen, es alto, de acuerdo a la experiencia, y muchas empresas est�n evit�ndolo.

�Cu�l es, entonces, el camino para sacarle partido al enorme activo de conocimiento de manejo de procesos existente, para redise�ar los procesos de una empresa y crear el software de apoyo?

El enfoque expuesto en este libro provee, en nuestra opini�n, una v�a para resolver la disyuntiva planteada. Explicamos, a continuaci�n, la manera en que proponemos que esta v�a se desarrolle.

11.2 Un modelo digno de considerarse: open source software

El concepto de software-fuente-abierto –que consiste en hacer disponible sin costo los programas-fuente– ha tenido un violento desarrollo debido a la popularizaci�n de Internet. Esto se explica por el hecho de que este canal provee un medio eficiente y barato para hacer disponible el c�digo en forma masiva.

Ahora bien, �por qu� abrir el software? La idea fundamental que lo justifica es lo que podemos llamar "desarrollo cooperativo". Es decir, al estar los programas-fuente en las manos de muchas personas, mejora la probabilidad de identificar errores en el software –uno de los problemas que no han podido solucionar ni los m�s grandes fabricantes de paquetes, el cual todos sufrimos d�a a d�a– y hace posible que muchas inteligencias contribuyan a la mejora del producto. El supuesto detr�s de esta idea es que hay gente competente dispuesta a trabajar gratis por alg�n tipo de motivaci�n: reputaci�n, entretenci�n, etc. Que esto es posible ha sido probado en el caso m�s famoso de software abierto: Linux. Este sistema operativo, derivado de UNIX –uno de los pocos que corre en m�ltiples plataformas–, ha llegado a ser tal vez el mejor en su tipo –particularmente en cuanto a su confiabilidad– con la colaboraci�n de muchos desarrolladores de todo el mundo [22].

Aparentemente, una de las motivaciones de los que han contribuido al desarrollo de Linux es poder contar con un producto perfeccionado –libre de errores, estable, eficiente– para beneficio de ellos mismos y otros. Esto no significa que no haya oportunidades de lucro asociadas a este tipo de producto: los beneficios monetarios provienen de los servicios necesarios; por ejemplo, actualizaci�n de versiones, empaquetamiento y distribuci�n, soporte y consultor�a. De hecho hay firmas comerciales que realizan estas tareas y cobran por ello [58].

Linux ha tenido tal �xito que, recientemente, los due�os de uno de los productos l�deres en el mercado de los browsers –Netscape Communicator– han hecho p�blico su c�digo fuente^*.

El modelo Linux no debe confundirse con la idea del regalo indiscriminado de software –propuesto por los adherentes al shareware–, que implica la propiedad p�blica de toda forma de software y donde, habitualmente, no hay desarrollo colaborativo y se distribuye s�lo c�digo ejecutable.

11.3 El desarrollo de patrones y software de apoyo

Examinamos, a continuaci�n, c�mo seguir con el desarrollo de los patrones y software de apoyo.

En primer lugar, consideremos el caso de grandes organizaciones que tienen muchas r�plicas del mismo proceso. Un caso presentado en este libro es t�pico al respecto: el de atenci�n de pacientes en consultorios y hospitales. Al tener grandes organizaciones –t�picamente p�blicas– que manejar un importante n�mero de unidades de servicio –por ejemplo, cientos–, es claro el beneficio de desarrollar patrones de atenci�n y software de apoyo en forma centralizada y dejar en las manos de cada unidad las peque�as adaptaciones locales y la implementaci�n. Otros casos del sector privado ser�an grandes bancos con cientos de sucursales, donde se replican varios procesos que deber�an corresponder a un patr�n y software �nicos, y grandes empresas de telecomunicaciones, donde m�ltiples centros geogr�ficos de negocios, que proveen los mismos productos y servicios, deber�an tambi�n compartir patrones de procesos y software. Un ejemplo de empresa que evidentemente ya ha hecho lo reci�n indicado –por lo menos, al nivel de las pr�cticas humanas del proceso– es McDonalds, que asegura las mismas pr�cticas de atenci�n en cada punto de venta del planeta.

En este tipo de caso reci�n descrito, es evidente que se justifica un esfuerzo particular dentro de cada una de las organizaciones para tener sus propios patrones y software.

En el caso de empresas que no tienen las econom�as de escala de las organizaciones reci�n analizadas –particularmente medianas y peque�as–, el desarrollo de patrones y software debe ser necesariamente colaborativo. Bosquejamos, a continuaci�n, c�mo creemos que deber�a ser este esfuerzo.

Primeramente, los patrones debieran tener un desarrollo abierto, al estilo de Linux, por medio de su publicaci�n en un sitio Web. Esto permitir�a el libre uso de ellos y su perfeccionamiento por medio de propuestas de mejoras de los patrones existentes, nuevas versiones por especializaci�n a dominios m�s restringidos e, incluso, especializaciones para casos particulares. La administraci�n de versiones de los patrones podr�a estar inicialmente a cargo de una instituci�n acad�mica, para, posteriormente, pasar a ser ejecutada por un consorcio de usuarios, al estilo del OMG. De hecho, ya se ha dado un primer paso en esta direcci�n y se han publicado los patrones disponibles en el sitio de este autor^*, al cual se ir�n agregando los nuevos patrones que se propongan en el futuro.

La justificaci�n del porqu� las empresas deber�an colaborar en este esfuerzo se deja para despu�s de explicar c�mo deber�a desarrollarse el software de apoyo a los patrones.

Al tener patrones p�blicos aceptados por una comunidad de usuarios, ser�a posible que empresas desarrolladoras de software dise�aran y construyeran clases de objetos con crecientes grados de especializaci�n para diversos dominios –tal como se mostr� en el Cap�tulo 9. Estas clases ser�an los m�dulos con los cuales una empresa particular –compr�ndolos en el mercado– podr�a armar una soluci�n de apoyo computacional a un redise�o de proceso, hecho a partir de cierto patr�n de dominio, por medio de especializaci�n. Este enfoque de desarrollo de software tiene un precedente en librer�as de clases que existen en el mercado –por ejemplo, APIs Java–, ampliamente usadas para construir los componentes de menor nivel de los sistemas, como men�s pull down, pantallas de ingreso de datos, botones, etc. Adem�s, existen los EJB (Enterprise Java Beans), rese�ados en el Cap�tulo 9. Estos, como se explic�, proveen un modelo ideal para desarrollar las clases orientadas al negocio que se derivan de los patrones, el cual permite que se elaboren de manera descentralizada, por m�ltiples proveedores, y que se puedan integrar por medio del software de contenedores y CORBA para su ejecuci�n.

Lo reci�n se�alado permitir�a la creaci�n de un mercado competitivo de EJB que proveer�a las clases que se derivan de los patrones de proceso, dentro del cual un usuario podr�a encontrar, eventualmente, m�ltiples opciones para la misma clase. Esto implica que la construcci�n del apoyo a un redise�o particular ser�a hecha por especializaci�n e integraci�n de componentes (clases EJB), minimizando el desarrollo de c�digo hecho a la medida.

Lo reci�n dicho es ventajoso tanto para los usuarios como para los proveedores de componentes, ya que los primeros evitar�an costosos desarrollos de software a la medida –infactibles para empresas peque�as y medianas–, teniendo una gran capacidad de adaptaci�n por especializaci�n, y los segundos, podr�an vender sus componentes m�ltiples veces.

Volvemos, ahora, a considerar la motivaci�n que tendr�a un usuario para colaborar en el desarrollo de los patrones. Esta provendr�a, fundamentalmente, de hacer factible el uso de los patrones, tanto desde el punto de vista de su disponibilidad como de la existencia de software de apoyo preconstruido. En efecto, si no hay un esfuerzo colaborativo de muchas empresas medianas y peque�as, no ser� posible que cada una de ellas cuente con patrones que les permitan mejorar sus procesos de negocios, por problemas de disponibilidad de talento y recursos financieros. Adem�s, si no existen patrones elaborados y concordados en forma colaborativa por varias empresas, no ser� factible el desarrollo de los componentes de software –que habilitan los procesos– por parte de empresas especializadas. Por lo tanto, si no hay colaboraci�n, no hay patrones ni software y, consecuentemente, mejora de procesos, lo cual pone en peligro la viabilidad de este tipo de empresas.

Esto no implica que esperemos que las empresas se agolpen para participar en una iniciativa de este tipo, ya que los beneficios que se pueden obtener son a largo plazo e inciertos. Pero creemos que se pueden formar grupos de empresas similares en un determinado sector –por ejemplo, empresas pertenecientes a asociaciones de exportadores– para desarrollar patrones y mostrar en la pr�ctica los beneficios de la colaboraci�n, cuya factibilidad fue probada por el proyecto San Francisco de la IBM, rese�ado en el Cap�tulo 3. Los patrones derivados de esta colaboraci�n no ser�an p�blicos, pero existir�a la posibilidad de vend�rselos a otras empresas, junto con el software de apoyo, siguiendo tambi�n el precedente del proyecto San Francisco. Esta idea podr�a replicarse en varios sectores –incluyendo grupos de empresas PYMES, que podr�an ser apoyadas con fondos p�blicos de fomento– lo cual, junto con la experiencia de empresas con replicaci�n –en las cuales ya se est� trabajando intensivamente en el desarrollo de patrones–, servir�a como efecto demostraci�n para que otras empresas adoptaran el enfoque.

El conjunto de un patr�n –que resume el conocimiento que existe respecto a c�mo manejar un proceso en un determinado dominio de aplicaci�n– y el software de apoyo que hace posible llevar a la pr�ctica cierto manejo –en la forma de clases de componentes que se pueden integrar en un sistema– lo hemos llamado Orgware (ver Cap�tulo 1), para denotar el hecho de que contiene rutinas de gesti�n y computacionales que "hacen funcionar" una organizaci�n, generando comportamientos y un desempe�o apropiados. El Orgware es un concepto nuevo que da la misma importancia a la definici�n expl�cita y dise�o de las pr�cticas del negocio que al dise�o y construcci�n del software de apoyo, y provee una metodolog�a para generarlas en forma coherente y unificada. Los enfoques tradicionales de desarrollo de sistemas y de paquetes de software han considerado de una manera lateral e imperfecta esta interrelaci�n, que estimamos vital para asegurar buenos dise�os de procesos y adecuado software de apoyo. Por lo tanto, creemos que nuestro enfoque ofrece una oportunidad para solucionar un problema largamente vigente en el uso de las TI en las organizaciones, cual es el divorcio entre los usuarios que manejan procesos y los especialistas que proveen soluciones computacionales. La unificaci�n de pr�cticas organizacionales y software en el Orgware hace que los usuarios y especialistas tengan un lenguaje com�n que facilita una colaboraci�n arm�nica entre ellos.

Recientemente, otro autor ha identificado un concepto similar al de Orgware; es el Messyware, que consiste en el conocimiento institucional en una cierta �rea, la experiencia del capital humano, pr�cticas de negocios, servicio, foco en la calidad y activos de TI que tiene una organizaci�n para manejar un negocio [24]. No es el producto o servicio nuclear de la empresa, sino todo lo que lo rodea y, seg�n el creador de este concepto, es el que explica el valor de muchas empresas, particularmente aquellas creadas alrededor de la Web. Si bien el concepto de Messyware puede parecer m�s amplio que el de Orgware, el conjunto de procesos y software de apoyo –desarrollados a partir de los patrones–, debidamente implementados en el contexto que provee el recurso humano de la organizaci�n, que se origina en el segundo concepto, es razonablemente equivalente a lo que incluye el primero.

La idea de Messyware ha sido elaborada s�lo para explicar el porqu� algunas empresas que ofrecen servicios en la Web –como Yahoo, Amazon, Dell y otras– est�n cambiando ciertos mercados y, a trav�s de ello, domin�ndolos. La tesis es que la ventaja competitiva de estas empresas est� en las complejas pr�cticas y otros aspectos incluidos dentro del Messyware, necesarias para intermediar con �xito entre productores y consumidores. Sin embargo, no hay una metodolog�a acerca de c�mo generar un buen Messyware. En cambio, nuestro Orgware est� centrado en la idea de c�mo generar pr�cticas y software que tengan �xito en cualquier tipo de negocio, lo cual lo hace m�s general y orientado al cambio organizacional.

11.4 Consecuencias para la educaci�n

Al tener patrones de procesos predefinidos, aceptados por muchas empresas, las universidades, que tienen carreras relacionadas con la gesti�n, pueden acceder a conocimiento p�blico respecto a las mejores pr�cticas. Esto abre varias posibilidades.

Primero, los patrones proveen una manera muy natural para integrar el conocimiento funcional que se ense�a en los diversos cursos de gesti�n –operaciones, finanzas, recursos humanos, m�todos cuantitativos– y de apreciar c�mo las teor�as funcionales y las pr�cticas que se derivan de ellas se insertan en un proceso. Esto tiene mucho valor para los alumnos, ya una duda existencial habitual de ellos es c�mo y d�nde se puede utilizar el conocimiento adquirido en un ramo.

Segundo, perfeccionando lo anterior, se podr�an desarrollar simuladores de procesos –para lo cual ya existe software apropiado, algunos de los cuales se han usado en este libro– que permitieran a los alumnos hacer operar un proceso y establecer el efecto en su desempe�o de cambios en las pr�cticas de trabajo, derivadas de un conocimiento funcional reci�n adquirido. Lo importante es que esto obliga al alumno a pensar en forma sist�mica y darse cuenta de que mejoras locales de pr�cticas pueden ser anuladas por efectos estructurales del proceso.

Tercero, lo ya dicho permite la creaci�n de cursos talleres, verdaderos laboratorios paralelos a los cursos funcionales, en los cuales los alumnos experimenten, aplicando el conocimiento funcional al redise�o de los procesos, idealmente en casos de empresas reales. Esto se vuelve muy factible hacerlo en per�odos cortos de tiempo, ya que todo el conocimiento de contexto est� predefinido en los patrones y el alumno s�lo tiene que centrarse en la aplicaci�n del conocimiento espec�fico asociado a una parte del proceso, afectada por cierto dise�o funcional.

Cuarto, por medio de los laboratorios del punto anterior, las universidades se pueden convertir en las codificadoras del conocimiento de procesos, al incorporar a los patrones conocimiento originado en propuestas funcionales y validadas emp�ricamente en casos concretos de mejora de procesos.

Por �ltimo, lo dicho puede originar una nueva especialidad en las carreras de ingenier�a: la de Ingeniero de Procesos de Negocios. Esta ser�a una mezcla de las actuales Ingenier�a Industrial o Comercial con Ingenier�a en Computaci�n, con un componente adicional que ninguna de �stas tiene actualmente, cual es un conocimiento profundo de las teor�as y metodolog�as asociadas al redise�o de procesos.

11.5 Consecuencias para el desempe�o de las empresas

Las empresas que usen un enfoque como el propuesto en este libro –en las modalidades discutidas en el punto anterior– tienen una posibilidad inmejorable de incrementar sustantivamente tanto su servicio al cliente como su productividad.

Consideremos primero el caso de las organizaciones que tienen replicaci�n. De �stas, las que no han analizado en forma unificada los procesos que se replican en m�ltiples instancias –que son la mayor�a– tienen la posibilidad de reemplazar implementaciones extremadamente ineficientes en decenas o cientos de puntos diferentes. Para demostrar este punto, tomemos los casos de hospitales y consultorios p�blicos y de una empresa de servicios de telecomunicaciones. A la luz de trabajos de redise�o de procesos hechos en hospitales espec�ficos –cuyos resultados se dan en los Cap�tulos 4, 7, y 8–, que muestran un bajo uso de la capacidad instalada, particularmente pabellones, y un enorme potencial de disminuci�n en los tiempos de servicio, es claro el valor de aplicar el enfoque propuesto. De hecho, el retorno social de un proyecto de este tipo debe ser much�simo mayor que cualquier otro proyecto de infraestructura hospitalaria, ya que estamos hablando de la posibilidad de reducir a la mitad los tiempos de atenci�n (incluido tratamiento) y de incrementar el uso de pabellones al doble por mejora en los procesos, con recursos humanos y f�sicos constantes. Asimismo, en el caso de la empresa de telecomunicaciones, un proyecto en ejecuci�n actualmente ha determinado un potencial de mejora en reducci�n del tiempo de servicio, con recursos constantes, de, a lo menos, 50% y la eliminaci�n de costos significativos asociados al inadecuado servicio.

Si extrapolarnos los casos ejemplificados a diversas instituciones p�blicas –m�ltiples puntos de atenci�n del SII, Ser vicio de Registro Civil e Identificaci�n, diversas reparticiones de ministerios, retenes de Carabineros, etc.– y empresas privadas –AFP, Isapres, bancos, compa��as de seguros, cadenas de supermercados, cadenas de farmacias, etc.–, tenemos un potencial de incremento de productividad insospechado, junto con mejoras del servicio. De las situaciones reci�n ejemplificadas, ya hay estudios preliminares de aplicaci�n de patrones en bancos y compa��as de seguros, donde se ha confirmado que es factible disminuir los tiempos de servicio significativamente, incrementando, al mismo tiempo, la productividad por mayor volumen de casos procesados.

Ahora, respecto al caso de empresas que no tienen replicaci�n –particularmente aqu�llas medianas y peque�as–, no hay precedente todav�a respecto a la mejora de procesos usando patrones. Sin embargo, otros estudios m�s tradicionales de an�lisis y mejora de pr�cticas de trabajo han entregado resultados muy desalentadores respecto al desempe�o de los procesos de ellas. As�, por ejemplo, es habitual encontrar en estas empresas un manejo informal del inventario de productos terminados y de insumos, sin criterios ni procedimientos dise�ados para producir un resultado esperado. Esta lleva, en el caso de productos terminados, a la insatisfacci�n de pedidos de clientes –con casos estudiados en que la insatisfacci�n llega a 10% de ellos– con exceso de inventario, al mismo tiempo, siendo una cifra t�pica de inventario promedio de entre dos y tres meses de venta. Por otro lado, en cuanto a insumos, se producen frecuentes paradas de las l�neas de producci�n por falta de �stos y, al mismo tiempo, hay exceso de lo que no se ocupa. Por ejemplo, un caso reciente en una importante empresa mediana, que analiz� este problema, calcul� en medio mill�n de d�lares anuales el costo asociado a la detenci�n de m�quinas por falta de insumos o repuestos.

La raz�n detr�s de muchos de los problemas ejemplificados es que en estas empresas no se hacen proyecciones informadas y rigurosas del volumen de actividades esperadas a futuro y no se planifica en base a ello –que era exactamente lo que ocurr�a en el caso de la empresa industrial del Punto 7.13–, lo cual hace necesario que trabajen "a ojo". Ahora, los patrones proponen, y esto se ha mostrado factible en la pr�ctica en innumerables casos, que se pronostique la actividad futura, usando m�todos anal�ticos universalmente disponibles en software est�ndar. Por ejemplo, hay varias decenas de casos documentados en memorias que muestran la factibilidad de pronosticar ventas futuras con un margen de error relativamente bajo, pero son poqu�simas las empresas que usan tales m�todos.

Situaciones como las descritas se reproducen en bancos –con tr�mites y demoras innecesarios en el procesamiento de transacciones–, compa��as de seguros –con sistemas computacionales inadecuados, duplicados e inconsistentes que demoran el proceso– y en la mayor�a de las empresas de servicios de todo tama�o.

Por lo tanto, el potencial de mejora de servicio y de incremento de productividad en empresas que no tienen replicaci�n es tambi�n muy significativo.

Consecuentemente, existe, lo que este he denominado, una "mina de oro" asociada a la mejora de procesos. Lo que faltaba era un enfoque que hiciera viable el explotar esta riqueza. Creemos que el enfoque de patrones provee un m�todo apropiado para convertirla en beneficio social o privado. El que se materialice tal beneficio no s�lo tiene consecuencias de mayor generaci�n de riqueza, sino que est� relacionado con el m�s trascendental objetivo de hacer las organizaciones m�s competitivas en un mundo globalizado que as� lo exige.