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

Indice del Capítulo

1.1 El cambio de paradigma de la década de los noventa
1.2 Replanteamiento de la estructura burocrático-funcional
1.3 El impacto de las Tecnologías de la Información
1.4 Patrones de procesos

CAPITULO 1: INTRODUCCION

1.1 El cambio de paradigma de la década de los noventa

Como consecuencia de la necesidad de ser eficientes en una economía globalizada, se está produciendo en el mundo un cambio de paradigma en la gestión de empresas e instituciones. La rígida y poco dinámica organización burocrático-funcional –con áreas funcionales y de manejo por comando y control, donde los niveles superiores planifican, dirigen, coordinan y controlan, y los inferiores ejecutan– es reemplazada por la organización en red. Esta es descentralizada, con menos niveles jerárquicos, otorga poder de decisión a los niveles operativos, está orientada a los clientes, es generadora de conocimiento y es manejada por proceso.

La última característica es una de las más distintivas, porque obliga a visualizar la organización como un conjunto de cadenas de actividades interrelacionadas que existen para cumplir con su fin: generar productos o servicios para clientes internos o externos. Estas cadenas, que son los procesos del negocio, cortan horizontalmente las áreas funcionales tradicionales y exigen un diseño que asegure un funcionamiento coordinado y eficiente del conjunto de actividades que las componen. Así, por ejemplo, la generación eficiente del producto crédito hipotecario en un banco requiere que el ejecutivo comercial, los evaluadores del crédito, los tasadores, abogados y operadores que generan el crédito, actúen como un equipo bien afiatado.

Los procesos, apoyados por Tecnología de la Información –hardware, software y redes de comunicación–, hacen fluir los documentos, facilitan la coordinación, y apoyan la realización de actividades. Es decir, son los que materializan la organización en red [9].

Los procesos existen en las empresas, pero su funcionamiento ha sido el fruto de la historia y la experiencia. Dada la naturaleza funcional de las organizaciones, ha habido cambios y mejoras puntuales en ellos, pero rara vez sistémicos y orientados al cumplimiento de los objetivos globales de los mismos, lo que hace que –en general– sean extremadamente ineficientes. Esto ha conducido a la necesidad de enfrentar su rediseño^*

El rediseño de procesos consiste en tomar las actividades de un proceso en su totalidad y someterlas a un cambio fundamental, el cual habitualmente implica un uso intensivo de Tecnologías de la Información que garantice un desempeño claramente mejorado del mismo [7]. Así, en el caso de crédito hipotecario, gracias al flujo electrónico (workflow) de los documentos se eliminan pasos y autorizaciones innecesarias. Con ello se puede reducir sustantivamente el tiempo que toma cursar una operación. También se ha usado el término reingeniería para denotar los enfoques que propugnan un cambio más radical de los procesos. Nosotros no hacemos tal diferencia y adoptamos el término rediseño para incluir en él una amplia gama de posibilidades de cambio.

La experiencia muestra que el rediseño de procesos lleva a soluciones similares en procesos del mismo tipo. Por esto, no hay razón alguna para pensar que un rediseño optimizado del proceso de crédito hipotecario debiera ser muy diferente de un banco a otro. Asimismo, el proceso de satisfacción de pedidos rediseñado en una empresa de distribución no debiera tener diferencias fundamentales de otra del mismo rubro y el proceso de atención de urgencias rediseñado en un hospital público no debería diferir del de otro.

A continuación profundizamos en los cambios enunciados en este punto.

1.2 Replanteamiento de la estructura burocrático-funcional

El primero y tal vez más fundamental de los cambios ya reseñados es el replanteamiento de la tradicional estructura burocrático-funcional de las organizaciones. En síntesis, este replanteamiento consiste en alejarse de la idea de comando y control asociada a esta estructura –en la que unos pocos, en los niveles altos de la jerarquía, dirigen y el resto ejecuta–, lo cual conduce a descentralizar las decisiones, un otorgamiento de poder a los que ejecutan las actividades operativas y a disminuir (o aplanar) los niveles de la jerarquía [23]. Esto va acompañado de un manejo por proceso, el cual consiste en que las actividades, en diferentes áreas funcionales que componen una cadena asociada a la generación de algún bien o servicio –por ejemplo, el procesamiento de una orden desde que se pide un producto hasta que éste se entrega, que involucra a ventas, crédito, bodega, distribución, etc.– se consideran como una sola unidad, a la que denominamos proceso, la cual puede analizarse y diseñarse para cumplir su propósito, optimizando su desempeño de una manera apropiada.

El enfoque de proceso es revolucionario, por cuanto rompe las barreras funcionales que típicamente existen dentro de una organización, permitiendo una coordinación explícita entre áreas que, dentro de un esquema burocrático-funcional, se manejan en forma relativamente independiente. Por ejemplo, esta coordinación permite abordar explícitamente los típicos desencuentros y conflictos que se producen entre ventas y producción/operaciones, los cuales tienen que ver con que ventas no transparente debidamente sus planes comerciales al área de producción y que ésta es poco activa para prever demandas irregulares, ocasionando pérdidas de ventas, o demasiado activa, generando inventarios innecesarios. Un manejo por proceso proveerá mecanismos explícitos y diseñados de coordinación –por ejemplo, manejo por stock mínimo o just in time– para cumplir objetivos declarados; por ejemplo, satisfacer la demanda a mínimo costo.

Otra consecuencia del manejo por proceso es que la coordinación entre las diferentes áreas funcionales que son parte de un proceso, además de ser explícita, se descentraliza y es parte de la operatoria del proceso o de la interacción entre las personas que lo ejecutan. Esto elimina funciones que tienen que ver con coordinación por jerarquía dentro de la estructura organizacional.

La experiencia de muchas empresas en el mundo es que, al adoptar un enfoque de proceso, se generan incrementos de beneficios muy significativos –por ejemplo, reducción de costos de un orden de magnitud– y que, al mismo tiempo, se mejora en el manejo de la variable humana, dada la descentralización de decisiones al grupo que maneja el proceso y su autonomía para autocoordinarse [7] . La explicación para una mejora tan sustantiva reside en el hecho de que nunca nadie ha estudiado y diseñado explícitamente los procesos, siendo más bien su operatoria el fruto de la tradición y las costumbres.

El enfoque de proceso ha conducido naturalmente a la necesidad de contar con metodologías y herramientas para realizar su reingeniería o rediseño [7] . Estos últimos términos –podemos observar– connotan que los procesos de una empresa son objeto de diseño, tal como lo son una obra civil, una planta minera o un refrigerador. Nuestra propuesta de metodología de rediseño se da en los Capítulos 6, 7 y 8.

Tal como las ingenierías tradicionales, la reingeniería o rediseño de procesos tiene sus planos, que son los modelos de los procesos –tema que profundizaremos en los Capítulos 3, 4 y 5–, los cuales llevan a explicitar de una manera clara y precisa la forma en que un proceso operará. Esto también permite su eventual simulación; es decir, procesar el modelo en un computador para evaluar el desempeño del mismo, sin tener que recurrir a prueba y error en la práctica.

1.3 El impacto de las Tecnologías de la Información

Otro lugar común hoy día es que nos encontramos en la "Era de la Información" [9]. Esto tiene también significativas implicancias para el cambio organizacional. La disponibilidad de cada vez más potentes y económicas Tecnologías de la Información (TI) hace que el manejo organizacional sea más susceptible de ser apoyado computacionalmente [9]. Esta tendencia interactúa estrechamente con la anteriormente señalada del enfoque de proceso. En efecto, las rutinas o prácticas diseñadas como parte del rediseño de un proceso se internalizan habitualmente en un sistema computacional que orienta, apoya y coordina a las personas que lo ejecutan. Así, por ejemplo, es hoy día habitual que las empresas líderes en servicio a sus clientes tengan procesos de atención altamente computarizados. Este es el caso de Dell, fabricante y distribuidor de computadores, que permite a sus clientes ordenar por medio del World Wide Web (WWW o Web), siendo todo el proceso de satisfacción de una orden ejecutado dentro de esta empresa con apoyo computacional, desde verificación de crédito, pasando por programación del ensamblaje según especificación del cliente, hasta despacho y atención de consultas del mismo; Federal Express, que apoya todo el proceso de ruteo y transporte de paquetes en un sistema computacional, el cual también permite que un cliente pueda consultar por medio del Web la situación en que se encuentra un envío; y Amazon, una empresa que permite, por el mismo medio, encargar libros de un catálogo de cientos de miles de títulos, con una entrega en pocos días apoyada en un proceso altamente computarizado.

En empresas extremadamente tecnificadas, como las descritas en los ejemplos anteriores, el proceso es, en gran medida, el sistema computacional que ejecuta las rutinas o prácticas del negocio.

En cambio, en empresas donde actividades rutinarias, como las anteriormente descritas, no son factibles, dada una naturaleza más creativa y no estructurada de las operaciones que constituyen un proceso, es también posible el apoyo de las TI, principalmente para facilitar la coordinación de las diferentes personas que intervienen en el mismo. Un proceso muy común, con estas características, es el desarrollo de nuevos productos o servicios en una empresa. Obviamente, cada actividad dentro de esta cadena es altamente creativa y no puede caer en la rutina; por ejemplo un estudio de mercado o el diseño del producto o servicio. Sin embargo, la información que se genera en el proceso –resultado de los estudios de mercado, planos de diseño, evaluaciones económicas, etc.– puede ser generada, ruteada y compartida computacionalmente. De hecho, hay software especializados que permiten hacer esto, los cuales caen en las categorías de groupware y workflow [9]. Estos software no sólo manejan información, sino que también pueden asegurar que las actividades se realizan de acuerdo a una secuencia preestablecida y en tiempos predefinidos, contribuyendo al éxito del proceso.

En todas las empresas en que las TI se utilizan para ejecutar y/o apoyar un proceso, se favorece el trabajo en grupo de los participantes en el mismo, debido a que la tecnología los interconecta –por medio de redes computacionales– y permite que intercambien y compartan información, ya sea en la forma de mensajes o documentos electrónicos de cualquier tipo. Esto facilita la descentralización mencionada al comienzo de este punto, el aplanamiento de la organización y el funcionamiento por coordinación horizontal –entre ejecutantes– en vez de hacerlo a través de la jerarquía.

1.4 Patrones de procesos

La experiencia muestra que los mismos procesos se repiten en diferentes organizaciones, de la más variada naturaleza [10], y que la manera en que ellos se realizan en las empresas líderes –de acuerdo a lo que se denominan "mejores prácticas" [30]– es muy parecida. Esto ha permitido concluir que en cualquier organización hay un número pequeño de tipos de procesos, entre 7 y 15 [7], y cada uno de ellos, además de tener una arquitectura o estructura común que comparte con los otros, es muy parecido en su esencia en diferentes contextos. Así, este autor ha demostrado que los procesos de crédito hipotecario en un banco, la satisfacción de pedidos en una empresa manufacturera, la atención de urgencia en un hospital y muchos otros, corresponden a instancias de una estructura o arquitectura común –con actividades y relaciones del mismo tipo– de un proceso que ocurre en todas las organizaciones y que genera el producto o servicio que los clientes externos demandan. A esta estructura común se la denomina patrón de proceso [10], la cual detallaremos en el Capítulo 3.

La consecuencia de definir patrones de procesos en detalle –que toman la forma de modelos gráficos de fácil comprensión– reside en que en ellos se pueden internalizar las mejores prácticas desarrolladas en muy diferentes dominios, conformando una acumulación de conocimiento normativo respecto a cómo debe realizarse la gestión. La disponibilidad de este conocimiento permitiría que numerosas organizaciones medianas y pequeñas pudieran mejorar sus procesos, sin tener que empezar desde cero, lo cual tiene obvias implicancias en cuanto a aumento de productividad.

Parece natural que el conocimiento acerca de patrones de procesos sea administrado por universidades o institutos de investigación sin fines de lucro. En esta dirección, este libro entrega una primera propuesta de patrones de procesos que resume la experiencia del autor en la materia. Estos patrones deben interpretarse como un punto de partida para una constante mejora de ellos, que proponemos sea colaborativa. Es decir, muchas empresas deberían aportar su experiencia en dominios específicos, ya sea para perfeccionar un patrón o para crear uno nuevo, los cuales quedarían disponibles para uso público. La manera en que esto puede ser llevado a la práctica se discute en el Capítulo 11.

La ventaja de un enfoque abierto, como el planteado, es que quienes desarrollan software estarían en condiciones de generar los apoyos computacionales que los patrones especifican –que componen una parte importante del costo de llevarlos a la práctica– para una comunidad de usuarios, lo cual permite usar economías de escala y reducir el costo para cada participante. Los detalles de cómo tal software se puede desarrollar se dan en los Capítulos 9 y 11.

La unión e integración de los patrones –que proveen rutinas de trabajo– y el software de apoyo –con sus rutinas computacionales– constituyen un nuevo concepto de herramienta de manejo organizacional que llamaremos Orgware. Esta "hace funcionar" la organización generando comportamientos y un desempeño apropiados. Esta idea de Orgware se expande en el Capítulo 11.

La propuesta que se desarrolla en este libro tiene relación con otros esfuerzos colaborativos en cuanto a estandarizaciones de procesos que existen a nivel mundial, entre los cuales destacamos el Manual de Procesos del MIT [43] y el Proyecto San Francisco de la IBM [12], ambos reseñados en el Capítulo 3. Sin embargo, ninguno de éstos tiene el grado de apertura y de generalidad que nosotros proponemos.

Por otro lado, algunos paquetes ERP (Enterprise Resource Planning) pueden considerarse como una manera propietaria y limitada de compartir conocimiento y experiencia de procesos. En efecto, algunos de estos paquetes proveen modelos de referencia [20], que constituyen una especie de propuesta de cómo debería manejarse cierto proceso de negocio para una situación específica; por ejemplo, satisfacción de pedidos de productos en una empresa que mantiene inventario, o manejo del recurso humano en una situación de empleo estable y baja rotación. Estos modelos constituyen un punto de partida para una empresa que quiere rediseñar sus procesos y apoyarlos computacionalmente, y le permitirían utilizar el conocimiento acumulado –envasado en modelos de referencia– de varias empresas que anteriormente han enfrentado la misma tarea. Por lo tanto, evitarían tener que partir de cero para elaborar un rediseño absolutamente particular y los correspondientes apoyos de TI.

A partir de los modelos de referencia, se pueden generar modelos de procesos especializados a las particulares características de una empresa. Tales modelos se utilizan para la adaptación del paquete de software –por medio de parámetros y programación– a los requerimientos específicos establecidos, lo cual es un trabajo humano de alto nivel técnico.

Las dificultades de adaptación del software ERP empaquetado –dada su inherente inflexibilidad– y el tiempo excesivo que ello implica –lo cual contradice el objetivo central de comprar un paquete, cual es la rapidez de implementación– ha hecho que la mayoría de las organizaciones adopte, en gran medida, las prácticas de proceso implícitas en el software; vale decir, sin asegurar que las prácticas de trabajo de los usuarios de los paquetes estén explicítamente definidas.

Existe otra razón de peso para modificar lo menos posible un software ERP, cual es el problema de las versiones. Al modificar un paquete, las versiones sucesivas del mismo deberían también adaptarse, lo cual genera un gran desincentivo.

Además, tanto los modelos de referencia como el enfoque de modelamiento para adaptarlos a un caso particular son totalmente propietarios; vale decir, no respetan estándar alguno y hay que pagar por ellos y la consultoría asociada.

Todo lo anterior hace que los paquetes ERP no tengan, en la opinión de este autor, un gran potencial –a lo menos en sus versiones presentes y modalidad actual de uso– en la mejora de procesos y en compartir conocimiento al estilo de los patrones que nosotros proponemos, aunque sí pueden ser un vehículo de implementación, como se explica en el Capítulo 8.