Las empresas enfrentan un entorno complicado. Por un lado, la competencia es global y se hace contra países con sueldos menores, lo que implica que las empresas deben reducir sus costos o crear mayores diferenciadores para competir. Por el otro, la situación económica adversa ha hecho que se disponga de menor cantidad de recursos y ahora es necesario hacer más con menos. Además, los clientes están más informados y cuentan con mayor poder de elección, lo cual genera más presión para venderles y retenerlos. Por si esto no fuera poco, los mercados y las condiciones cambian continuamente, requiriendo de las empresas rapidez de adaptación y una mayor flexibilidad para el cambio.
Muchas han sido las iniciativas que a lo largo de los años se han propuesto para que las empresas puedan afrontar estos retos. Desde la Gestión de Calidad Total (TQM) hasta Six Sigma (6σ), pasando por Reingeniería de Procesos de Negocio (BPR), Just in Time (JIT), Costeo Basado en Actividades (ABC), Kaizen, Supply Chain Management (SCM) y Balanced Scorecard (BSC), por nombrar algunas. Por supuesto, la tecnología de información ha estado presente con propuestas propias, que se remontan a la promesa de los Sistemas de Información Gerenciales (MIS) y la tecnología Cliente/Servidor hasta llegar a los ERP y los CRM, sin olvidar las soluciones Business to Business (B2B).
Tristemente, estas iniciativas no siempre han dado los resultados esperados. Muchas fueron las empresas que con gran ilusión se embarcaron en la ola de Reingeniería de los 90’s, obteniendo resultados muy por debajo de lo esperado. Según el propio Michael Hammer, 70% de estos proyectos resultaron en fracasos. Esto ha dado lugar a un gran escepticismo y ha creado el síndrome de cure du jour. Por el lado de los proyectos de tecnología de información, los fracasos acumulados en la industria han dado lugar a que los Directores de Sistemas enfrenten ahora una creciente presión para (a) probar que la tecnología de información entrega valor a la organización, (b) involucrar a las diferentes áreas en las decisiones tecnológicas, (c) reducir costos, y (d) mantener bajo control los riesgos, lo cual ha dado lugar al concepto de Gobernanza de TI (IT Governance).
¿Por qué estos esfuerzos no han tenido el éxito esperado? Un estudio sobre la utilización de 200 herramientas administrativas en 160 empresas durante un lapso de diez años, encontró que las empresas que alcanzan un desempeño superior son las que dominan cuatro elementos fundamentales: estrategia, cultura, estructura y ejecución, independientemente de la herramienta utilizada. Esto implica que las organizaciones, primero, deben de elaborar una estrategia adecuada, que permita aprovechar las condiciones externas y las capacidades internas. Una vez que se cuenta con ésta, la cultura —los supuestos compartidos— debe alinearse para permitir alcanzar los objetivos, al igual que debe crearse una estructura organizacional que soporte las iniciativas dentro de la organización.
Ahora bien, ¿cómo pueden las organizaciones ejecutar adecuadamente? Las organizaciones sólo cuentan con dos formas de instrumentar las estrategias: los proyectos y los procesos. Recordemos que un proyecto es “un esfuerzo temporal que se lleva a cabo para crear un producto o servicio único”, mientras que un proceso puede definirse como “un conjunto de actividades que transforman insumos en productos de valor para un cliente”. Es importante hacer notar que los proyectos, a su vez, están formados por procesos y que 80% del fracaso o éxito de los proyectos está relacionado con una buena administración. Los elementos clave para la ejecución son pues, los procesos y su administración. Si repasamos las iniciativas citadas, veremos que en todas los procesos tienen un papel clave: son un área importante dentro de un esfuerzo de TQM, son el foco central de BPR, Kaizen y 6σ, y son cruciales en JIT, ABC y BSC. Los procesos también ocupan un lugar trascendente en las iniciativas tecnológicas. Por ejemplo, ¿quién puede negar su importancia en un ERP o B2B? Los procesos son importantes porque es a través de ellos que la organización genera valor para sus clientes, integrando la participación de diferentes áreas funcionales a través de toda la cadena de valor.
En este contexto, surge con mucha fuerza una iniciativa llamada Business Process Management (BPM) que puede ayudar a consolidar todos los esfuerzos anteriores. En el año 2000, Gartner predijo que BPM sería el siguiente gran fenómeno, y posteriormente comentó que “BPM gana la triple corona por ahorrar dinero, ahorrar tiempo y añadir valor”. Otro estudio realizado por el BPM Institute arrojó que 96% de los encuestados indicaron que un enfoque centrado en procesos era crítico para el éxito de su compañía.
¿Qué es BPM?
BPM consiste administrar el ciclo de vida de los procesos, apoyándose en herramientas de automatización del flujo de trabajo, conocidas como Business Process Management Systems o BPMS. Aunque algunos opinan que BPM no necesariamente involucra un BPMS, en mi opinión esto le resta potencial a la solución y no permite distinguirla fácilmente de otras propuestas como Kaizen, por ejemplo.
El ciclo de vida de un proceso cubre su conceptualización, representación (gráfica y/o textual), optimización, automatización, simulación y prueba, e implantación en la organización. Por otro lado, la administración incluye la planeación, seguimiento, monitoreo y control.
BPMS
Para entender lo que es un BPMS, enlistemos sus componentes funcionales típicos:
- • Modelador de procesos.- Ayuda a descubrir y modelar los procesos.
• Herramientas de desarrollo.- Diseñador de formas y editor de reglas.
• Integración.- Habilita la integración para interactuar con otras aplicaciones.
• Máquina de procesos.- El motor que habilita la ejecución de procesos. Ejecuta instancias de procesos en base al estado de los objetos y las reglas definidas.
• Repositorio.- Almacena meta-definiciones de procesos, participantes e integración.
• Gestión.- Provee registros de auditoría. Adicionalmente habilita la intervención manual para redirigir, abortar o modificar la instancia de un proceso en caso de emergencia.
• Reporte y Análisis.- Permite visualizar y analizar la ejecución de los procesos.
Contraste con Paquetes
Los proveedores de paquetes y aplicaciones empresariales acostumbran argumentar que sus productos cubren prácticamente todas las necesidades de una organización. Sin embargo, sabemos que esto dista de ser verdad. Según Gartner, un ERP cubre en promedio únicamente 30% de la funcionalidad requerida en las empresas. Adicionalmente, existen muchas actividades que involucran participación y toma de decisiones por parte de las personas. Cuando estas actividades no están incluidas en las aplicaciones, se crean actividades fuera del proceso automatizado. Si el proceso requiere la intervención de varios sistemas, se crean islas de automatización que obligan a las personas a utilizar papel o paquetería de oficina para pasar de una “isla” a otra. Son famosas las historias de cómo las personas se ingenian para usar una hoja de cálculo y “darle la vuelta” a un ERP. Aún cuando a un paquete se le integre una máquina de procesos, la solución está centrada en los “recursos” o “los clientes” y no en los procesos de negocio. Así como un manejador de bases de datos está hecho para manejar bases de datos, tablas, columnas e índices, un BPMS está diseñado para manejar procesos, instancias, versiones y variantes, componentes, reglas y participantes de procesos. Esto cambia el enfoque de centrado-en-datos a centrado-en-procesos.
Impacto al área de TI
BPM tiene una repercusión importante para los roles relacionados con el software. Los proyectos de BPM serán parte del portafolio de proyectos de las áreas de Sistemas y deberán ser controlados por el Director. Los desarrollos de software a la medida incluirán cada vez más la identificación y modelado de los procesos de negocio. Los desarrollos de software basados en un BPMS requerirán que los desarrolladores entiendan los procesos de negocio y sepan usar la herramienta. Los analistas de sistemas deberán aprender sobre análisis de procesos, al igual que los usuarios. Los testers deberán realizar pruebas con una visión del proceso completo. Los administradores de bases de datos deberán incorporar bases de datos de procesos. Los administradores de redes deberán incluir en su administración servidores de procesos y considerar el ancho de banda necesario para asegurar el tráfico de la información de los procesos, no sólo a través de la organización sino también con los socios de negocio. Los administradores de configuración tendrán que considerar entre sus ítems a los procesos y sus objetos derivados. Los administradores de proyectos deberán entender las implicaciones de la participación de los usuarios de negocio y de los analistas de procesos. Los especialistas en seguridad deberán ahora brindar seguridad a todo el proceso.
Pero no todo es mayor trabajo para el personal de Sistemas. En retribución, los sistemas desarrollados tendrán una mayor visibilidad y una mayor participación de las áreas usuarias. Será posible reanimar sistemas “muertos” o poco utilizados. Los usuarios podrán contar con una interfaz común sin importar si detrás está un ERP o un sistema legado. Quizá lo más importante para nuestra industria es que se aprovecha y potencía la inversión existente en tecnología de información.
¿Cómo se relaciona BPM con los esfuerzos de mejora de procesos basados en modelos? ¿No son BPM también? Los modelos como CMMI o MoProSoft son un gran avance ya que llevan el concepto de administración de procesos a las organizaciones de sistemas/software. Existen otros modelos, como SCOR para cadena de suministro (Supply Chain), ITIL para servicio tecnológico, o COBIT para el control de los objetivos. Todos ellos se basan en procesos y considera en menor o mayor grado su administración. Las diferencias cruciales, quizá sean que BPM primero lleva estos conceptos a toda la organización, y además, tomando ventaja explícita de la tecnología para crear procesos digitalizados. Esto no significa que los esfuerzos basados en estos modelos compitan con BPM. Más bien, son un paso importante en el sentido de lo que se buscan con BPM.
Por último, más no por menos, es importante mencionar que además del expertise técnico en BPM, un esfuerzo exitoso de este tipo requiere incluir una administración efectiva de los proyectos, administrar el cambio organizacional, obtener el patrocinio suficiente, y alinearse con los objetivos estratégicos del negocio.
Referencias:
• William Joyce, Nitin Noria, Bruce Robertson. “What Really Works”. Harvard Business Review. Julio 2003
• Jim Sinur, Jess Thompson. “The Business Process Management Scenario.” Gartner Research. Junio 2003
• Thompson, Michael. “Requirements for effective BPM”, Butler Group. Junio 2003
Acerca del autor
Francisco José López Lira e Hinojo es Director Operativo de Process & Project Health Services, firma dedicada a la consultoría en BPM y mejora de proyectos, Presidente de la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS) y Vicepresidente de la Asociación BPM de México. Su correo es flopezlira@pp-hs.com
- Log in to post comments