Cada proceso de negocio posee un cliente bien definido -una persona o grupo que recibe el resultado (por ejemplo: una idea, un informe, un diseño, un producto X . Además, los procesos de negocio cruzan los límites organizativos. Requieren que distintos grupos de la organización participen en las «tareas lógicamente relacionadas » que definen el proceso.
Todo sistema es en realidad una jerarquía de subsistemas.
Cada uno de los sistemas de negocios (también llamados función de negocios) están compuestos por uno o más procesos de negocio, y cada proceso de negocio está definido por un conjunto de subprocesos.
La RPN se puede aplicar a cualquier nivel de la jerarquía, pero a medida que se amplía el ámbito de la RPN (esto es, a medida que se asciende dentro de la jerarquía) los riesgos asociados a la RPN crecen de forma dramática. Por esta razón, la mayor parte de los esfuerzos de la RPN se centran en procesos o subprocesos individuales.
Principios de reingeniería de procesos.
En muchos aspectos, la RPN tiene un objetivo y un ámbito idéntico al proceso de la ingeniería de la información . Lo ideal sería que la RPN se produjera de forma descendente, comenzando por la identificación de los objetivos principales del negocio, y culminando con una especificación mucho más detallada de las tareas que definen un proceso específico de negocios.Hammer sugiere una serie de principios que nos guiarán por las actividades de la RPN cuando se comienza en el nivel superior (de negocios):
Organización en torno a los resultados, no en torno a las tareas:
Hay muchas compañías que poseen actividades de negocio compartimentadas, de tal modo que no existe una Única persona (u organización) que tenga la responsabilidad (o el control) de un cierto resultado de negocio. En tales casos, resulta difícil determinar el estado del trabajo e incluso más difícil depurar los problemas de proceso cuando esto sucede. La RPN deberá diseñar procesos que eviten este problema.
Hay que hacer que quienes utilicen la salida del proceso lleven a cabo el proceso:
El objetivo de esta recomendación es permitir que quienes necesiten las salidas del negocio controlen todas las variables que les permitan obtener esa salida de forma temporalmente adecuada. Cuanto menor sea el número de personas distintas implicadas en el proceso, más fácil será el camino hacia un resultado rápido.
Hay que incorporar el trabajo de procesamiento de información al trabajo real que produce la información pura. A medida que la TI se distribuye, es posible localizar la mayor parte del procesamiento de información en el seno de la organización que produce los datos. Esto localiza el control, reduce el tiempo de comunicación y la potencia de computación se pone en manos de quienes tienen fuertes intereses en la información producida.
Hay que manipular recursos geográficamente dispersos como si estuviesen centralizados. Las comunicaciones basadas en computadoras se han sofisticado tanto que es posible situar grupos geográficamente dispersos en una misma «oficina virtual». Por ejemplo, en lugar de emplear tres turnos de ingeniería en una única localización, toda la compañía podrá tener un turno en Europa, un segundo turno en Norteamérica y un tercer turno en Asia. En todos los casos, los ingenieros trabajarán durante el día y se comunicarán empleando redes de un elevado ancho de banda.
Hay que enlazar las actividades paralelas en lugar de integrar sus resultados. Cuando se utilizan diferentes grupos de empleados para realizar tareas en paralelo, es esencial diseñar un proceso que exija una continuación en la comunicación y coordinación. En caso contrario, es seguro que se producirán problemas de integración.
Hay que poner e1 punto de decisión en el lugar donde se efectúa el trabajo, e incorporar el control al proceso. Dentro de la jerga del diseño del software, esto sugiere una estructura organizativa más uniforme y con menos factorización.
Hay que capturar los datos una sola vez, en el lugar donde se producen. Los datos se deberán almacenar en computadoras, de tal modo que una vez recopilados no sea necesario volver a introducirlos nunca.
Todos y cada uno de los principios anteriores representan una visión dotalmente general» de la RPN. Una vez informados por estos principios, los planificadores de negocios y los diseñadores de procesos deberán empezar a procesar el nuevo diseño. En la sección siguiente, se examinará el proceso de RPN más detalladamente.
Un modelo de RPN.
Al igual que la mayoría de las actividades de ingeniería, la reingeniería de procesos de negocio es iterativa. Los objetivos de negocio, y los procesos que los logran, deberán adaptarse a un entorno de negocio cambiante. Por esta razón, no existe ni principio ni fin en la RPN -se trata de un proceso evolutivo.
No hay comentarios:
Publicar un comentario