BPR: una visión cristalina

Es raro que los directores comerciales sean capaces de imaginar todas las formas en que las Tecnologías de la Información pueden transformar el proceso de trabajo. Sin embargo, en colaboración con los profesionales informáticos, el equipo puede rediseñar el proceso comercial y desarrollar la aplicación, todo ello a un mismo tiempo. A continuación se explica la forma en que pueden optimizar y cristalizar sus ideas.

Acabo de regresar de un viaje alrededor del mundo. Empresas y organizaciones, desde Estados Unidos al Japón, se están esforzando por ser más competitivas, racionalizar y simplificar las operaciones, aumentar el "trabajo basado en el conocimiento", y reducir el trabajo difícil y primitivo. Da lo mismo que uno lo llame reingeniería, rediseño de procesos comerciales o cualquier otra cosa que esté en boga, lo cierto es que todo el mundo está llevando a cabo este proceso de rediseño de la actividad comercial.

Dicho esto, son pocas las posibilidades de que se esté realizando correctamente. El rediseño de procesos comerciales, BPR (Business Process Redesign) debería estar promovido e impulsado por el departamento de sistemas de información, pero en un 80% de las compañías con las que he hablado no sucede así, sino que, por el contrario, los equipos BPR están formados por empleados procedentes de una variedad de departamentos y están dirigidos por un consultor/facilitador externo o interno. Una vez que han completado sus actividades de rediseño (que generalmente se documentan en forma de organigramas en papel), los equipos entregan el diseño resultante al departamento informático, con el fin de implementar y automatizar los procesos recién diseñados. No es de extrañar por lo tanto que esto no funcione correctamente.

¿Qué es lo que falla aquí?

Cuando se separan las actividades informáticas de las BPR, no se obtiene el enfoque correcto por el que se esfuerzan con frecuencia los consultores, sino que se obtiene un ámbito de visión limitada. Resulta difícil para los empleados que no son especialistas en tecnología imaginar todas las formas en las que el departamento de Sistemas de Información podría transformar su trabajo. Podrían realizar una extrapolación lineal y pensar en cosas que desearían alcanzar con la tecnología pero que no pueden llevar a cabo hoy. Sin embargo, al no comprender la forma en que el departamento informático podría transformar completamente la actividad, es imposible por lo general para ellos realizar los grandes pasos hacia adelante que son esenciales para un esfuerzo de reingeniería.

Cuando se retrasa la integración del área informática en las actividades BPR, se priva a los equipos de trabajo de una técnica extraordinariamente potente para cristalizar y optimizar sus ideas: la rápida creación y manejo de prototipos. Las compañías que han combinado el manejo rápido de prototipos con BPR, aseguran que los empleados encuentran mucho más fácil visualizar e imaginar sus nuevas funciones y tareas una vez que las ven en acción. Además, son capaces de articular nuevas reglas comerciales y eliminar pasos innecesarios en la mayoría de las operaciones.

Cuando se segrega el área informática de la actividad BPR, también se están añadiendo semanas e incluso meses al período necesario para implementar los procesos rediseñados. Algunas compañías adoptan un enfoque nuevo, consistente en diseñar nuevos procesos en vacío y preocuparse de la implementación más adelante. Como consecuencia de esto, se enfrentan generalmente a un período de 18 meses a dos años para convertir los nuevos procesos a especificaciones y transformar esas especificaciones en aplicaciones. Las compañías que adoptan un enfoque en espiral integrado e interactivo para la actividad BPR y el desarrollo rápido de aplicaciones, RAD (Rapid Application Development), son capaces por lo general de completar proyectos incluso muy ambiciosos en un plazo de nueve meses.

¿Cuál es la forma correcta de combinar BPR y Sistemas de Información?

No hay una forma correcta de integrar las Tecnologías de la Información en los proyectos BPR o de reingeniería, pero existen algunas prácticas preferidas que parecen estar surgiendo de aquellas firmas pioneras que han estado experimentando con la combinación óptima.

No resulta sorprendente que las áreas más críticas y difíciles de poner en práctica correctamente tengan que ver con el compromiso y la aceptación por las personas interesadas. Un proceso comercial rediseñado no enraizará a menos que haya sido diseñado por las personas que van a utilizarlo. Tampoco es probable que un proceso comercial rediseñado pueda ser implementado si se requieren más de dos o tres meses para que el equipo BPR vea y utilice la primera versión del nuevo proceso.

Es aquí donde el desarrollo rápido de prototipos (RAD) desempeña un papel de importancia clave. Otra sugerencia es la de trabajar "de fuera adentro" de la empresa. Para obtener el compromiso de los empleados con los resultados del proceso BPR, hay que poner el énfasis primero en los procesos promovidos o determinados por los clientes e incluir a clientes clave en el equipo BPR. Si el rediseño de procesos se centra en satisfacer las necesidades de clientes externos, es mucho más probable que alcance una aceptación general que si está dirigido únicamente a mejorar las operaciones internas de la empresa.

También hay que asegurarse de que la infraestructura técnica de la compañía puede hacer frente al desafío de soportar estas aplicaciones interdepartamentales. Las áreas clave en las que hay que centrar el énfasis son la solidez y resistencia de la infraestructura de redes y el estado de las plataformas cliente/servidor.

Las compañías que han sido capaces de pasar rápidamente a desplegar e implementar procesos comerciales rediseñados son sin excepción las mismas que han implementado ya una infraestructura LAN y WAN coherente y bien gestionada, que han estandarizado ya un conjunto común de modernas plataformas cliente/servidor, y que han comenzado ya a implementar cierto número de procesos distribuidos subyacentes, como middleware de acceso a bases de datos y/o middleware de proceso de transacciones. Esa estructura ofrecerá el fundamento que es de importancia crítica para la actividad BPR.

Patricia Seybold es presidente de la consultora P. Seybold Group

Las Mejores Prácticas

El esfuerzo BPR no está liderado por las Tecnologías de la Información, sino por los consultores BPR. Los esfuerzos BPR deberán estar liderados por la empresa y facilitados por un consultor BPR que posea la debida formación. La mayor parte de las compañías comienzan por utilizar consultorías BPR externas y después van formando gradualmente a sus propios consultores internos.

Es importante crear esta capacidad y competencia internamente, ya que la actividad BPR, lo mismo que la Gestión de Calidad Total o TQM (Total Quality Management) no es algo que se logra de una sola vez, sino que es un proceso permanente. Otro motivo por el que es importante "poseer" una competencia o capacidad BPR propia es que, con el tiempo, va a ser necesario codificar cada uno de los procesos comerciales básicos, mantenerlos y optimizarlos continuamente.

El equipo BPR interno deberá hacerse responsable de mantener un repositorio de procesos comerciales, o base de conocimientos, para la empresa. Estará formado por las personas más aptas para detectar las nuevas posibilidades de mejora y refinamiento cuando surgen dentro de la actividad, así como para impedir "reinvenciones" innecesarias de procesos ya definidos.

Las Tecnologías de la Información soportan el esfuerzo BPR mediante la creación y manejo rápido de prototipos. Lo más recomendable es una relación de dos responsables de prototipos por cada equipo BPR. Los equipos BPR son generalmente bastante pequeños, siend