Reingenieria

La Reingeniería de procesos de negocio, RPN (Business Process Reingineering, BPR2) va más allá del ámbito de las tecnologías de la información y de la ingeniería del software. Entre las muchas definiciones (la mayoría de ellas, algo abstractas) que se han sugerido para la RPN, se cuenta con una publicada en la revista Fortune [STE93]: «. . .la búsqueda e implementación de cambios radicales en el proceso de negocios para lograr un avance significativo». Ahora bien ¿cómo se efectúa la búsqueda, y cómo se lleva a cabo la implementación? O lo que es más importante, ¿cómo podemos estar seguros de que el «cambio radical» que se sugiere va a dar lugar realmente a un «avance significativo» en lugar de conducimos a un caos organizativo?

Procesos de negocios

Un proceso de negocio es «un conjunto de tareas lógicamente relacionadas que se llevan a cabo para obtener un determinado resultado de negocio» [DAV90]. Dentro del proceso de negocio, se combinan las personas, los equipos, los recursos materiales y los procedimientos de negocio con objeto de producir un resultado concreto. Entre los ejemplos de negocio se incluyen el diseño de un nuevo producto, la adquisición de servicios y suministros, la contratación de nuevos empleados o el pago a proveedores. Cada una requiere un conjunto de tareas y se basa en diversos recursos dentro del negocio.

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). 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.

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

(Capítulo 10). 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 [HAM90] 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.

Reingeniería del Software

Este escenario resulta sumamente conocido: Una aplicación ha dado servicio y ha cubierto las necesidades del negocio de una compañía durante diez o quince años.

A lo largo de este tiempo, ha sido corregida, adaptada y mejorada muchas veces. Las personas se dedicaban a esta tarea con la mejor de sus intenciones, pero las prácticas de ingeniería del software buenas siempre se echaban a un lado (por la urgencia de otros problemas). Ahora la aplicación se ha vuelto inestable. Sigue funcionando, pero cada vez que intenta efectuar un cambio se producen efectos colaterales graves e inesperados.

¿Qué se puede hacer? La imposibilidad de mantener el software no es un problema nuevo. De hecho, el gran interés por la reingeniería del software ha sido generado por un «iceberg» de mantenimiento de software que lleva creciendo desde hace más de treinta años.

Un modelo de procesos de reingeniería

La reingeniería requiere tiempo; conlleva un coste de dinero enorme y absorbe recursos que de otro modo podrían emplearse en preocupaciones más inmediatas. Por todas estas razones, la reingeniería no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos años. La reingeniería de sistemas de información es una actividad que absorberá recursos de las tecnologías de la información durante muchos años. Esta es la razón por la cual toda organización necesita una estrategia pragmática para la reingeniería del software.

Una estrategia de trabajo también acompaña al modelo de procesos de reingeniería.

La reingeniería es una tarea de reconstrucción, y se podrá comprender mejor la reingeniería de sistemas de información si tomamos en consideración una actividad análoga: la reconstrucción de una casa. Consideremos la situación siguiente:

Suponga que ha adquirido una casa en otro lugar.

Nunca ha llegado a ver la finca realmente, pero la consiguió por un precio sorprendentemente reducido, advirtiéndosele que quizá fuera preciso reconstruirla en su totalidad. ¿Cómo se las arreglaría?

· Antes de empezar a construir, sería razonable inspeccionar la casa. Para determinar si necesita una reconstrucción, usted (o un inspector profesional) creará una lista de criterios para que la inspección sea sistemática.

· Antes de derribar y de construir toda la casa, asegúrese de que la estructura está en mal estado. Si la casa tiene una buena estructura, quizá sea posible remodelarla sin reconstruirla (con un coste muy inferior y en mucho menos tiempo).

· Antes de empezar a reconstruir, asegúrese de que entiende la forma en que se construyó el original. Eche una ojeada por detrás de las paredes. Comprenda el cableado, la fontanería y los detalles internos de la estructura. Aunque vaya a eliminarlos todos, la idea que haya adquirido de ellos le servirán de mucho cuando empiece a construirla.

· Si empieza a reconstruir, utilice tan solo los materiales más modernos y de mayor duración. Quizá ahora le cuesten un poquito más, pero le ayudarán a evitar un mantenimiento costoso y lento en fecha posterior. Si ha decidido reconstruir, tenga una actitud disciplinada. Utilice prácticas que den como resultado una gran calidad -tanto hoy como en el futuro.

Aunque los principios anteriores se centran en la reconstrucción de una casa, son aplicables igualmente a la reingeniería de sistemas y aplicaciones basados en computadoras.

Tomado de: Ingenieria.del.Software.Un.Enfoque.Practico.-.Roger.S.Pressman.V.Edicion.McGraw-Hill