¿Haría las paredes antes que los cimientos? Los riesgos de implementar un BPMS sin conocer la arquitectura del negocio

Los sistemas de gestión de procesos de negocio (o BPMS, por sus siglas en inglés) están recibiendo un énfasis espectacular últimamente. Evolucionados a partir de las plataformas de integración empresarial de aplicaciones (conocidas con la sigla EAI, por Enterprise Application Integration), ofrecen una serie de beneficios para el negocio desde la perspectiva tecnológica: Integrar aplicaciones disímiles en entornos no necesariamente compatibles, sorteando barreras organizacionales y partiendo del modelo de procesos de la organización, con la posibilidad de simular cambios y monitorear su ejecución en tiempo real.
Si usted piensa que los BPMS prometen mucho no se equivoca. Si bien esta promesa es técnicamente posible, las implicancias para la organización son mucho más profundas que la suma de una plataforma tecnológica más a las ya existentes.
Si vamos un poco hacia atrás, en los ochentas se hablaba de las bases de datos relacionales y los MRP (para la planificación de materiales de producción) como solución de base de los problemas empresariales; luego en los noventas se señalaba a la conectividad corporativa y los ERP como el pináculo de la integración de procesos de negocio; a principios de este siglo tuvo su auge el CRM (para la gestión del relacionamiento con clientes) y el BI (sistema para realizar inteligencia de negocios)… Ahora resuena con insistencia la sigla BPMS.
Todo proveedor de tecnología existe como consecuencia de haber encontrado una solución a un problema de negocios. Sin embargo, es muy común que con el transcurso del tiempo, ese mismo proveedor intente extender dicha solución a la resolución de problemas de negocios similares, ya sea en otras áreas de la organización o en industrias parecidas. Por otro lado, existe una tensión natural entre oferta y demanda, donde el proveedor siempre quiere lograr que su oferta tenga un alcance mayor del existente en un momento determinado, y el cliente siempre solicita más de su proveedor, al menor precio posible.
Esta tensión conduce muchas veces a la pérdida de foco, teniendo en cuenta que el fin último de cualquier solución tecnológica es resolver problemas de negocio, y no ser un fin en sí mismo. En nuestro trabajo de consultoría nos hemos encontrado ante incontables situaciones en las que el cómo había ido ganando preponderancia por sobre el qué.
El foco de toda solución tecnológica debe ser el qué, y para encuadrarla es preciso contar con un plano, con un diseño de cómo necesita la organización que la tecnología informática le dé soporte como negocio. Esto es lo que se conoce como Arquitectura de Negocios.
El objetivo que persigue la Arquitectura de Negocios (también llamada Arquitectura Empresarial) es optimizar los procesos de una organización, sean éstos manuales o automatizados, fragmentados o integrados, en un ambiente que responda ágilmente a los cambios y sirva de soporte para la ejecución de la estrategia de negocios.
Una buena Arquitectura de Negocios logra además un equilibrio adecuado entre eficiencia e innovación, no solamente otorgando flexibilidad a sus diferentes unidades operativas, sino también permitiendo el logro de sinergias en toda la cadena de generación de valor.
La organización conocida como The Open Group ha desarrollado un marco de referencia de arquitectura llamado TOGAF (The Open Group Architecture Framework) que es el resultado colaborativo de más de 300 organizaciones a nivel internacional y representa las mejores prácticas para el desarrollo de arquitecturas de negocio adaptables, flexibles y maduras. TOGAF ofrece, entre sus componentes centrales, una metodología paso a paso para el desarrollo de la arquitectura empresarial, tal y como se observa en la figura siguiente:

BPMS

En este punto es importante destacar que el orden de los cuatro primeros pasos de la metodología desarrollan una evolución sistemática tal que cada fase es precondición para el desarrollo de la siguiente. Así, la visión precede a la arquitectura del negocio, ésta precede a los sistemas de información y éstos a la arquitectura tecnológica. Una plataforma como BPMS se evalúa en esta etapa –no antes– pues de lo contrario, se estaría intentando construir las paredes antes que los cimientos.
TOGAF reconoce la manifiesta importancia de procesos tales como el gobierno y la gestión del cambio, la planificación de la migración, la identificación de oportunidades de mejora y la gestión integral de requerimientos a lo largo de todo el ciclo de vida de la arquitectura.

En e-STRATEGA estamos a la vanguardia en la aplicación y adaptación de las mejores prácticas para gobierno de TI, por lo tanto podemos ayudarlo a:

» Reducir los costos de desarrollo, soporte y mantenimiento de aplicaciones
» Mejorar la portabilidad de las aplicaciones
» Reducir la complejidad de la infraestructura de TI
» Optimizar las decisiones de compra
» Reducir el time-to-deployment
» Elaborar un Plan de Mejora en base a la visión de la Arquitectura de Negocios

Acerca del Autor

Sergio Sperat es socio de e-STRATEGA y tiene una trayectoria de más de 20 años como consultor en estrategia de áreas de TI y negocios, desarrollada en una amplia variedad de industrias en Argentina, Chile, México y Estados Unidos. Es Licenciado en Análisis de Sistemas de la Facultad de Ingeniería de la Universidad de Buenos Aires, hizo su Programa de Dirección de Empresas en el IAE Business School en 1995, completó su Maestría en Administración de Empresas en IDEA y London Business School, en Inglaterra en 2001. Fue profesor adjunto del postgrado del Master en Administración de Empresas de IDEA.
Sergio está certificado en CobiT y CGEIT y se desempeña como responsable de Aseguramiento de Calidad y Dirección de Proyectos de e-STRATEGA.