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.