 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|||||||||||||||||||||||||
 |
 |
 |
|
|||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
 |
 |
|
|||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
 |
 |
|
|||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
 |
 |
 |
 |
|
|||||||||||||||||||||
 |
 |
|
||||||||||||||||||||||||
 |
 |
 |
 |
 |
|
|||||||||||||||||||||
 |
 |
|
||||||||||||||||||||||||
 |
 |
 |
 |
|
||||||||||||||||||||||
 |
 |
|
||||||||||||||||||||||||
 |
 |
 |
|
|||||||||||||||||||||||
 |
 |
|
||||||||||||||||||||||||
 |
 |
 |
|
|||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
 |
 |
 |
|
||||||||||||||||||||||
 |
 |
|
||||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
 |
 |
|
|||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
 |
 |
|
|||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
 |
|
||||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
 |
 |
|
||||||||||||||||||||||||
 |
|
|||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
||||
 |
 |
 |
 |
 |
|
||||||||
 |
 |
|
|||||||||||
 |
|
||||||||||||
 |
|
||||||||||||
 |
|
||||||||||||
 |
|
||||||||||||
|
Rediseño
de Negocios Usando Patrones 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.
|
