LibroBPM Sergio

BPM (Business Process Management). Cómo alcanzar la agilidad y eficiencia operacional a través de BPM y la empresa orientada a procesos.

José Ramón Pais Curto Colección Conceptos Clave BPM Editorial:

BPM (Business Process Management). Cómo alcanzar la agilidad y eficiencia operacional a través de BPM y la empresa orientada a procesos. Edición original en español 

José Ramón Pais Curto, 2013. Todos los derechos reservados.

Foto cubierta: José Ramón Pais Curto © Editor: Pedro Robledo, 2013 © BPMteca.com, 2013 www.BPMteca.com email: [email protected] Todas las marcas y nombres de productos mencionados en este libro son marcas comerciales o marcas de servicio de sus respectivas compañías. Cualquier omisión o mal uso no debe ser considerada como la intención de infringir la propiedad de otros. El editor reconoce y respeta todas las marcas utilizadas por las empresas, los fabricantes y los desarrolladores como un medio para distinguir sus productos. Ni el editor, ni el autor, ni BPMteca.com, aceptan ninguna responsabilidad por pérdidas o daños ocasionados a cualquier persona o propiedad mediante el uso del material, instrucciones, métodos o ideas contenidas en el presente, o actuar o dejar de actuar como consecuencia de dicho uso. Todos los derechos reservados. Fabricada la versión digital en español en España. Queda rigurosamente prohibida, sin la autorización escrita de los titulares del copyright, bajo las sanciones establecidas en las leyes, la reproducción total o parcial de esta obra por cualquier método o procedimiento, comprendidos la reprografía y el tratamiento informático, excepto en el caso de citas breves incluidas en artículos críticos y revisiones. Queda prohibida también la distribución de ejemplares de ella mediante alquiler o préstamos públicos. Este libro está publicado en formato digital. El contenido completo de este libro está protegido por derechos de autor y no debe ser distribuido o sus datos extraídos sin autorización por escrito del publicador. Usted está autorizado a imprimir una copia para uso personal. Información sobre Catalogación por el Editor ISBN: 978-84-616-3854-3 Versión Digital

A Sandra, Aida y Malena.

INDICE ACERCA DEL AUTOR ..................................................................................... 11 INTRODUCCIÓN............................................................................................ 13 Acerca de la Certificación OCEB. .......................................................... 31 ESTRUCTURA DEL LIBRO............................................................................... 23 PARTE 1. FUNDAMENTOS DE LA GESTIÓN POR PROCESOS ......................... 29 Capítulo 1. La gestión de procesos........................................................... 31 La empresa como sistema.................................................................... 31 Gestión de procesos............................................................................. 42 Técnicas y Herramientas de análisis de procesos. ............................... 66 Capítulo 2. Los caminos hacia BPM.......................................................... 77 Orígenes de la gestión empresarial:..................................................... 78 TQM (Total Quality Management)....................................................... 83 Six Sigma............................................................................................... 85 BPR (Business Process Reenginering)................................................... 90 Teoría de las Limitaciones. (TOC). ........................................................ 97 Hacia una teoría unificada.................................................................. 101 Capítulo 3. Tecnología, Innovación y Modelos de Negocio. .................. 107 Evolución tecnológica:........................................................................ 107 Innovación.......................................................................................... 118 Modelos de negocio ........................................................................... 126

PARTE 2. BPM (BUSINESS PROCESS MANAGEMENT)................................. 135 Capítulo 4. BPM (Business Process Management)................................. 137 Qué es BPM ........................................................................................ 137 Ciclo de Vida de BPM.......................................................................... 138 Componentes principales de BPM ..................................................... 141 Principios, prácticas y ventajas de BPM. ............................................ 146 El Modelo de Madurez para la gestión de procesos. ......................... 155 La organización Orientada a Procesos................................................ 159 El Pensamiento Sistémico................................................................... 166 Capítulo 5. Modelado de Negocios. ....................................................... 173 Valor y Ventaja competitiva. .............................................................. 175 La Cadena de Valor. ............................................................................ 178 Estrategia, procesos y tecnología. ...................................................... 186 Arquitectura empresarial. .................................................................. 189 Frameworks, Estándares y Modelos de Referencia. .......................... 193 El Business Motivation Model (BMM)................................................ 204 Capítulo 6. Modelado de procesos. BPMN............................................. 215 Elementos principales de BPMN. ....................................................... 217 Tipos de Modelos BPMN: ................................................................... 233 BPMN ANALÍTICO: .............................................................................. 234 BPMN 2.0:........................................................................................... 252 PARTE 3. IMPLEMENTACIÓN DE BPM. ....................................................... 253 Capítulo 7. IMPLEMENTACIÓN DE BPM. ................................................ 255 Entorno de Negocio............................................................................ 259 Levantamiento de procesos. .............................................................. 261 Datos del proceso y Reglas de negocio. ............................................. 284 Mejora de procesos............................................................................ 289

Medidas, indicadores y análisis del proceso: ..................................... 302 Simulación de procesos:..................................................................... 302 Implementar el proceso: .................................................................... 325 Puesta en Marcha del proceso:.......................................................... 327 Control del proceso y Mejora Continua. ............................................ 328 TOC, Lean y Six Sigma dentro de un proyecto de BPM...................... 331 Gestión del proyecto:......................................................................... 337 Factores críticos de éxito de un proyecto BPM.................................. 348 Capítulo 8. Tecnología BPM. BPMS........................................................ 352 Módulos principales de un BPMS:..................................................... 357 Modelador gráfico de procesos. ........................................................ 361 Entorno de Integración. (Integration Developer) .............................. 368 Servidor de procesos.......................................................................... 371 Ejecución del proceso......................................................................... 374 Monitorización de procesos............................................................... 377 Arquitectura tecnológica. BPM y SOA................................................ 379 Gestión de casos................................................................................. 387 Bibliografía ................................................................................................. 390

ACERCA DEL AUTOR José Ramón Pais Curto tiene una larga experiencia en la implantación de sistemas de información, gestión de la innovación, la aceleración del cambio a través de TI y la gestión por procesos en diferentes empresas y administraciones públicas. Es Certified Expert in Business Process Management por Object Management Group (OMG). Además de autor, ofrece servicios de consultoría y acompañamiento a las organizaciones en la implementación de proyectos de BPM así como de distintos tipos de formación en esta materia, en la que se pone en práctica los conceptos teóricos de este libro con casos reales y prácticos sobre distintas plataformas software de BPM. Para contactar con el autor o realizar cualquier tipo de consulta o comentario: Mail: [email protected] Linkedin: http://es.linkedin.com/in/josepaiscurto Twitter: @josepaiscurto

Introducción

INTRODUCCIÓN “Cualquier tecnología lo bastante avanzada es indistinguible de la magia.” Arthur C. Clarke

La necesidad de adecuación a nuevos modelos de negocio y mercados, exige de las empresas más y mejores innovaciones y formas de hacer las cosas que sólo podrán ser realizadas adoptando una nueva forma de pensar las organizaciones. BPM (Business Process Management), es un conjunto de métodos y tecnologías estructuradas para la gestión de procesos de negocio, usado por organizaciones de todos los tipos y sectores, que considera que los procesos son los activos más importantes de la empresa para crear valor a nuestros clientes. Esta perspectiva ha existido siempre en todas las organizaciones y teorías de la gestión empresarial, sin embargo, no ha sido hasta ahora que las empresas han dedicado la atención y cuidado necesarios a sus procesos de negocio, con los cuales, podemos afrontar la gestión del cambio, la innovación, el aprovechamiento de la tecnología y la eficiencia de nuestras operaciones empresariales a través del rediseño o la mejora de los procesos con los que las empresas ejecutan sus estrategias de negocio. BPM nos descubre una nueva forma de gestionar las organizaciones desde la perspectiva de que éstas serán tan eficientes como lo sean sus procesos, por lo que el diseño, la medición, la mejora, simulación, control y 13

BPM (Business Process Management)

monitorización de estos procesos de negocio, se ha convertido en el reto principal para la mejora de las organizaciones y asegurar su éxito en un entorno altamente cambiante y competitivo. Todas las organizaciones desean mejorar sus beneficios, mejorar los productos y servicios ofrecidos a sus clientes, reducir sus costes y mantener satisfechos a sus empleados y esto sólo podrá ser realizado si todos los procesos de la empresa funcionan de forma eficiente y sincronizada. BPM es una metodología sistemática y holística para la mejora de los procesos de negocio de la organización que se apoya en la gestión unificada de procesos de negocio, personas y tecnología como forma de alcanzar y mejorar los resultados empresariales. BPM nos proporciona la forma de diseñar nuestra empresa a partir de la visión de negocio que tengamos de la misma para sobre esta visión, construir todas las herramientas (Procesos, Personas y Tecnología) que nos permitan llevar esta visión adelante de forma que todos los sistemas y personas dentro de la organización sepan lo que tienen qué hacer, cuándo y cómo hacerlo, de forma lógica y coordinada y con la capacidad de poder rectificar y adaptar nuestros procesos al entorno cambiante en cualquier momento sin incurrir en proyectos de reestructuración a largo plazo. Imaginemos cómo nos gustaría que fuese nuestro negocio y con BPM podremos implementar esa visión. Muchas veces entendemos BPM como una nueva herramienta o producto software. Sin embargo, BPM no es sólo tecnología sino una nueva forma de entender cómo la tecnología da soporte a la verdadera razón de ser de las empresas, que es hacer negocio a través de una serie de operaciones y procesos de negocio. Hoy en día no concebimos ningún negocio que no se apoye o esté directamente basado en la tecnología y en el caso de BPM, para poder alinear los proceso de negocio con las estrategias empresariales, necesitaremos herramientas tecnológicas para medir y controlar los mismos en tiempo real y poder monitorizar el desempeño y grado de cumplimiento de nuestros procesos de negocio con los objetivos de negocio planteados, de forma que podamos trabajar en la mejora continua y en la optimización de nuestro modelo y procesos de negocio que operamos. En BPM siempre trabajaremos antes con “papel y post-its” para entender y mejorar nuestros procesos para finalmente, como último eslabón de la cadena, apoyarnos en la tecnología para automatizar y poder entre otras cosas medir, monitorizar, gestionar y rediseñar los procesos diseñados. Aunque muchas veces se usen las herramientas tecnológicas de BPM sin encuadrarlas dentro del contexto de la gestión tradicional de las empresas o de la gestión por procesos, no debemos olvidar que BPM es la tecnología aplicada de 14

Introducción

forma racional a como ejecutamos nuestro negocio y creamos valor, haciendo uso no sólo de los componentes tecnológicos, sino de todas las técnicas y herramientas necesarias para el negocio (Reingeniería, gestión empresarial, finanzas, TQM, Six Sigma, TOC, modelos y estándares de negocio, arquitecturas empresariales, etc.), sobre las cuales diseñamos y construimos nuestros negocios apoyándonos en las personas y la tecnología para obtener un todo coordinado e integrado que permita transformar la visión empresarial en realidad. Esta perspectiva y posicionamiento de BPM como modelo de gestión organizacional orientado a la gestión por procesos, ha llevado al Gartner Group, la multinacional líder en investigación tecnológica, a manifestar que el modelo BPM y sus tecnologías asociadas son los de mayor crecimiento y el de mayor proyección de futuro y son el motivo por el que compañías tan relevantes como IBM, Oracle, Microsoft o SAP están dirigiendo hacia BPM todas sus inversiones en plataformas de gestión empresarial. El haberme dedicado estos últimos años a profundizar en BPM y los BPMS (Business Process Management Systems) y el haberme decidido a escribir este libro, viene del profundo convencimiento de que estos sistemas y la metodología que los soporta, son la manera más efectiva y racional de alinear el negocio y la tecnología y de gestionar conjuntamente los procesos de negocio empresariales y la tecnología dentro de las organizaciones, para generar valor, optimizar las infraestructuras de TI, poder innovar y adaptarse al cambio y trabajar en la mejora continua. Sin embargo, debo reconocer mi escepticismo inicial. Cuando los sistemas BPM empezaron a desarrollarse, me parecieron demasiado buenos como para ser reales. Hasta entonces, todas las herramientas y metodologías que conocía estaban asociadas a la implementación de la tecnología desde una perspectiva tecnológica y no de negocio. La aproximación de BPM a los procesos me pareció una forma inteligente de asociar estos dos mundos, hasta entonces aislados uno del otro. Tecnológicamente, la posibilidad de diseñar visualmente un proceso y poder añadirle datos de recursos, costes, tiempos y medidas e indicadores para analizar su funcionamiento; integrar los procesos diseñados con los demás sistemas informáticos para orquestar personas y sistemas en torno a los procesos; poder simular el funcionamiento de los mismos y realizar modificaciones sobre el modelado que se trasladasen en tiempo real al entorno de ejecución sin tener que escribir una sola línea de código; me pareció pura magia, pretenciosa e incluso amenazadora para la gente de TI. 15


Durante varios años, he dirigido y desarrollado soluciones TIC en distintos ámbitos, muchas veces sin considerar el entorno organizacional, los objetivos o planes estratégicos de las empresas sobre la que debía implementar la solución tecnológica. Estos aspectos no estaban incluidos en el proyecto, la empresa deseaba implementar un software, muchas veces porque el gerente de la empresa había visto la misma implementada en otra organización, leído sobre ella, o simplemente había sido convencido por un comercial. De cualquier de las maneras, esta solución no siempre estaba alineada con los objetivos de la empresa; nos abstraíamos de esa parte. Las soluciones software no eran vistas y analizadas como un brazo más de la empresa, sino como un organismo aparte del mismo y sobre el que se esperaban unos resultados extraordinarios. En estos casos, un analista o comercial realizaba la toma de requisitos de una persona de la empresa y traducía estos a código fuente ejecutable y que cumplía con las especificaciones dadas por el cliente, fuesen éstas las más apropiadas y correctas o no. Con la aparición de internet esta situación se ha agravado todavía más. Las empresas, en su afán de adaptación al nuevo medio como forma de incrementar sus ingresos, se han lanzado al desarrollo de plataformas en internet sin tener su gestión y sistemas preparados para afrontar las exigencias que este nuevo medio demanda. Con los años he comprobado que faltaba planificación desde la base misma de las organizaciones en su orientación estratégica, de forma que internet fuese una herramienta más de la empresa, el resultado de una lógica empresarial que permitiese aprovechar este medio para la consecución de sus objetivos de negocio. Son muchas las empresas que todavía hoy diseñan sus estrategias comenzando por las redes sociales, dejándose llevar por modas y tendencias, que si bien pueden producir satisfacción a corto plazo, pronto se revelarán como actuaciones aisladas, no alineadas con la empresa y con la forma en que esta crea valor a sus clientes. Internet no sólo ha producido nuevas oportunidades y modelos de negocio, sino que ha desvelado las debilidades e ineficiencias en las infraestructuras y sistemas de información de muchas organizaciones. Muchas veces, las actuaciones en redes sociales obedecen a campañas de marketing y promoción debido a los efectos de la estrategia y las tácticas empresarial que vemos en las redes sociales, unos efectos a veces buenos y a veces malos, pero que no atacamos mirando hacia las causas de los problemas que vemos en estas redes y que al final se encuentran en las estrategias y sistemas que están por debajo. No podremos, por ejemplo, gestionar las reservas online de nuestro hotel o pretender introducirnos en canales de comercialización online, si por “debajo” gestionamos las reservas y la 16

Introducción

ocupación de nuestro hotel en un libro “físico” de reservas. O tal vez podamos hacerlo al principio, pero con un poco de volumen de reservas que tengamos, con sus cancelaciones, pre-reservas y anulaciones, la gestión de éstas se volverá ingestionable y no produciremos más que insatisfacción en nuestros clientes y serios problemas dentro de nuestra empresa, difíciles de solucionar por muchas campañas de comunicación que hagamos y que dañarán seriamente la imagen de nuestra empresa en un entorno tan competitivo como el de las reservas hoteleras online. Lo mismo cabe decir de muchas plataformas de comercio electrónico, donde internet les ha lanzado a vender online, o sea, a vender en cualquier parte del mundo o un territorio donde el volumen de clientes y su diversidad es mucho mayor, por lo que muchas empresas han fracasado al no disponer de sistemas informáticos, de gestión logística o capacidad de atender las demandas de los clientes. Pero no son sólo los modelos de internet los que descubren estas ineficiencias, sino también los modelos organizacionales y culturas empresariales. Hoy ninguna empresa puede prescindir de la tecnología y en muchos otros casos, los proyectos tecnológicos han fracasado al pretender implementar soluciones y tecnologías avanzadas sobre modelos de negocio y filosofías organizacionales más propias del siglo XIX, sobre las que la automatización y la tecnología, no ha hecho otra cosa que automatizar y replicar esas ineficiencias. Las necesidades de acceso a la información, de interconexión de datos y aplicaciones entre empresas, clientes, partners y colaboradores, se han convertido también en un prerrequisito para cumplir con los requerimientos de prácticamente cualquier tipo de negocio y han provocado el desarrollo de nuevas arquitecturas informáticas como arquitecturas orientadas a servicios y aplicaciones en la nube, heredadas de los sistemas Middleware, y que los sistemas BPM recogerán en su arquitectura, no sólo para dar respuesta a estas necesidades de almacenamiento, gestión y compartición de datos, sino también para darles su razón de ser, la cual vendrá dictada por la lógica de los procesos de negocio sobre los que se sustenta la organización, pues sin un contexto para la interpretación de estos datos y un propósito, no tendrán valor ni serán de utilidad para la organización, sus clientes y colaboradores. Con BPM se reduce el distanciamiento entre negocio y tecnología y las personas de estos dos mundos, encontrarán en BPM un punto en el que trabajar conjuntamente en el diseño de procesos. Ya no hablamos de aplicaciones, departamentos y tareas independientes, sino de procesos. Todo está enlazado, aplicaciones, sistemas, datos, personas, procesos y tecnolo17


gías. La informática ha cambiado de las estructuras de datos a la estructura de procesos. BPM presenta muchas ventajas para las organizaciones que decidan adoptarla en términos de flexibilidad y capacidad de adaptación al cambio, reducción de costes, eficiencia, integración, visibilidad y control de los procesos y resultados operacionales, pero requerirá de una serie de retos y condiciones para poder realizar esta transición. En primer lugar las empresas deberán reconocer a los procesos como activos fundamentales de la empresa para aportar valor a sus clientes. Que estos procesos son transversales a la organización y atraviesan múltiples unidades de negocio, departamentos y sistemas informáticos de la organización, por lo que será necesario el intercambio de información entre los mismos y romper con los “silos” departamentales y de información, afrontando sin tapujos el reto de convertir las organizaciones departamentales y orientadas a funciones en organizaciones orientadas a clientes y a procesos. La perspectiva de BPM exigirá también del alineamiento de negocio y tecnología, de forma que ambos aspectos de la organización y las personas que los integran, colaboren conjuntamente en el diseño e implementación de los procesos de negocio de la organización, rompiendo con el tradicional aislamiento existente entre estos dos mundos. BPM requerirá también de un compromiso con las personas, pues éstas serán al final las que utilizarán los procesos y ejecutarán las actividades especificadas en los mismos para que estos funcionen y por ello BPM prestará especial atención a este aspecto así como al del liderazgo de estas personas en los proyectos que emprendamos. Deberemos asumir también un compromiso con las metodologías de gestión de proyectos que garanticen el buen gobierno de los proyectos, con la necesidad de innovación y la adaptación al cambio como algo natural e intrínseco a las organizaciones. Este carácter multidisciplinar, requerirá de nuevos roles relacionados con la gestión de procesos y con BPM, así como la adaptación de muchos de los roles existentes en las organizaciones a esta disciplina, exigiéndose de los trabajadores, que conozcan no sólo las tareas bajo su responsabilidad o de su departamento concreto, sino que tengan una visión general de todo el proceso de negocio que genera valor para el cliente. Este libro refleja la naturaleza holística de BPM desde un planteamiento de creación de valor hacia el mercado y sus clientes, la cual comienza con la 18

/RVSURFHVRVVRQ$FWLYRV )XQGDPHQWDOHVGHOD HPSUHVD

Introducción

empresa como Sistema y con los Modelos de Negocio y Arquitecturas Empresariales que sustentan la estrategia de la empresa, continúa con el sistema de creación de valor, el diseño de los procesos que soportarán esa estrategia y finalmente las tareas y actividades que ejecutarán el diseño realizado en los procesos. En este camino, se repasan teorías como TQM, Six Sigma o la Reingeniería de Procesos, sobre las que se asientan las bases teóricas de BPM. La Cadena de Valor, los Modelos de Negocio, las Arquitecturas Empresariales o la evolución de las Tecnologías de la Información (TI). Se estudian entre otros, distintos frameworks y estándares de negocio como SCOR o TOGAF, el BMM (Business Motivation Model), la notación BPMN (Business Process Model Language) para el modelado de procesos, los sistemas BPMS (Business Process Management Systems) y las arquitecturas tecnológicas como SOA, sobre las que basar nuestros proyectos de BPM. Pero además, añadimos disciplinas como la gestión de la Innovación, la Teoría de las Limitaciones (TOC) de Goldratt , metodologías de gestión de proyectos así como otras disciplinas relacionadas: el pensamiento sistémico o la impredecibilidad inherente a todo proceso empresarial, como conceptos importantes y relacionados a la hora de gestionar nuestros procesos y proyectos en BPM. Este recorrido permitirá que el lector comprenda como enfocar el análisis y diseño de procesos así como la estrategia para gestionar unificadamente Procesos, Personas y Tecnologías y tomar las riendas de nuestros negocios a través de la gestión de sus procesos y el control de sus resultados. El libro se dirige a estudiantes y profesionales interesados en BPM: responsables de calidad, de organización, de procesos, de innovación y de sistemas. Consultores, jefes de proyecto, analistas y empleados de diferentes áreas de la empresa que busquen gestionar sus organizaciones de una forma mucho más integrada a través de una visión de las organizaciones centrada en los procesos, como palanca sobre la que actuar para conseguir agilidad empresarial, mejorar sus resultados y adaptarse al cambio. Mi objetivo no es adoctrinar sobre esta materia y convertirla en un dogma o en la nueva sigla de moda, sino acercar al lector al pensamiento de la organización orientada a procesos, para una vez visualizada esta perspectiva, que el lector pueda comprobar sus potencialidades a través de las capacidades de modelización (desvelar como funcionan nuestros procesos de negocio), mejorar nuestros procesos actuales, realizar simulaciones (de datos y escenarios para saber cómo se comportarán los prototipos de procesos que diseñemos) y las capacidades de control y monitorización de procesos que nos permitirán analizar de nuevo estos procesos para volver a 19


mejorarlos. El lector entenderá como enfocar metodológicamente el análisis y diseño de procesos así como la estrategia para gestionar unificadamente procesos, personas y tecnologías, involucrar la estrategia en el diseño de procesos, detectar fuentes de ventaja competitiva y oportunidades de mejora en los procesos antes de proceder a su automatización, realizar el diseño y modelado de procesos en la notación BPMN y desplegar soluciones BPM con las plataformas BPMS. El reto formativo es grande, pues BPM es multidisciplinar y requerirá de conocimientos en distintas materias relacionadas, tanto de gestión de negocios como de aspectos técnicos, además de la adopción de nuevas habilidades, técnicas, herramientas y filosofías de gestión, como la negociación, la gestión de personas, de proyectos y la gestión del cambio, que de forma holística, nos permitirán entender qué hacemos, como camino para mejorar y dirigirnos hacia nuestros objetivos empresariales. Este libro ha sido el resultado de la preparación de distintos cursos de formación en BPM para distintos organismos públicos y privados, que comenzando como breve manual para estos cursos, ha evolucionado a medida que profundizaba en esta materia y creo que servirá tanto para iniciarse y disponer de una perspectiva global de BPM, como para preparar el examen de certificación OCEB (OMG Certified Expert in BPM) de OMG (Object Management Group).

20

Introducción

Acerca de la Certificación OCEB. La certificación OCEB (OMG Certified Expert in Business Process Management) otorgada por OMG (Object Management Group) es la más prestigiosa certificación actualmente en el campo de BPM (Business Process Management – Gestión de Procesos de Negocio). El programa OCEB consiste en cinco exámenes que conceden cinco certificaciones y donde cada nivel tiene su propio examen. El primer examen cubre los elementos básicos y los puntos esenciales en: Gestión de Negocio, Modelización de Negocio, Gestión de Procesos de Negocio, Modelización de Procesos y los “frameworks” y estándares más utilizados en la industria. Los que consiguen la certificación OCEB Fundamental, han demostrado que poseen el conocimiento y las habilidades de modelización para ser miembros de un equipo de proyecto BPM, tanto desde el punto de vista de negocio como técnico. El examen se realiza online a través de un centro Pearson VUE. El contenido del examen está en inglés. El examen contiene 90 preguntas y dura 90 minutos (en España la duración se alarga hasta 120 minutos por razones lingüísticas).

21

Estructura del libro

ESTRUCTURA DEL LIBRO La primera parte del libro está formada por tres capítulos en los que se introducen una serie de conceptos y teorías importantes previas a la introducción del concepto de BPM. Capítulo 1: La gestión de procesos. Este capítulo comienza describiendo los sistemas y las organizaciones como sistemas. BPM involucra una gran cantidad de módulos, soluciones software, disciplinas de management y otras técnicas y herramientas que nos harán ver la empresa como un sistema formado por distintas partes y que sólo tendrán sentido y aportarán valor bajo la perspectiva de la organización como un sistema cuyo resultado es mayor que la suma de sus partes por separado. Los modelos y arquitecturas empresariales que veremos en el resto de capítulos, se basarán en la premisa de entender la organización como un sistema, que existe para producir una salida de valor y la necesidad de adaptación al medio en el que se desenvuelve. Veremos distintas características de los sistemas que nos ayudarán a comprender su comportamiento, las bases del pensamiento sistémico y el indeterminismo como entorno tanto de la teoría general de sistemas como filosofía alrededor de la cual giraran bastantes aspectos de BPM. Se describen en este ca23


pítulo las bases de la Gestión de Procesos, sus características y propiedades, como identificarlos, clasificarlos y mejorarlos y la importancia de su correcto diseño, ejecución y monitorización de forma que estos sean lo más eficientes posibles. Al final del capítulo se hace un repaso a las principales técnicas y herramientas estadísticas utilizadas en la gestión y control de procesos y que constituirán la base para la toma de medidas y establecimiento de indicadores de rendimiento y eficiencia de los procesos para el posterior monitorización, análisis y mejora de los procesos en BPM. Capítulo 2: Los caminos hacia BPM. BPM puede ser visto como las ramas de un árbol cuya parte visible se levanta frondosa pero que se sustenta en sus raíces subterráneas, las cuales le proporcionan la estabilidad y elementos vitales que necesita y que serán las que veremos en este capítulo, en el que realizaremos un repaso histórico de las principales ideas sobre eficiencia organizacional sobre las que se basa BPM, a fin de entender cómo se ha llegado hasta esta teoría de gestión por procesos de negocio. Estas raíces son las Teorías de Organización de Adam Smith, Frederick Taylor y Henry Ford, la Teoría de la Calidad total (TQM), Six Sigma, la Reingeniería de Procesos de Negocio (BPR, en inglés) y la Teoría de las Limitaciones (TOC) de Goldratt. Finalmente acabaremos esta revisión histórica poniendo de manifiesto como en todas estas teorías subyace la orientación a procesos y la necesidad de un modelo de gestión que tome los procesos como base y condición imprescindible para el diseño y gestión de modelos empresariales de éxito, adecuados a las necesidades actuales de unos clientes cada vez más exigentes y necesitados de mayores innovaciones que sólo podrán ser satisfechas a través de la capacidad de nuestra empresa de adoptar e implementar esos cambios. Capítulo 3: Tecnología, Innovación y Modelos de Negocio. Este capítulo resume la evolución de las Tecnologías de la Información (TI) para comprender la evolución de estos sistemas y tecnologías y cómo a lo largo de los últimos años, estas han realizado el acercamiento y las adaptaciones necesarias hacia los aspectos de negocio hasta converger finalmente en BPM como disciplina y los BPMS (Business Process Management Systems) como la tecnología software que los hace posible. Dedicamos un apartado también a la innovación, de vital importancia para la gestión del cambio, la diferenciación y la búsqueda de ventajas competitivas y que estará estrechamente ligada a la mejora de procesos. Para finalizar 24


veremos la importancia de los modelos de negocio sobre los que se sustentarán las estrategias, las tácticas, las metas y los objetivos empresariales que conformarán el diseño de nuestros procesos y que según lo creativos e innovadores que hayamos sido en el diseño de estos modelos, dependerá el éxito o fracaso de la empresa. En la segunda parte del libro, se introduce la disciplina de BPM así como al modelado de negocios y de procesos a través de diferentes metodologías y estándares. Capítulo 4: BPM (Business Process Management) De la convergencia de las teorías de gestión de las organizaciones y de la tecnología, surge una nueva forma de ver la empresa bajo el prisma de los procesos. Bajo la mirada de este prisma surgirá una nueva teoría, el BPM, a través de la cual podremos diseñar, modelar, implementar y medir los procesos de negocio de nuestra organización para la mejora del rendimiento, la eficiencia y la excelencia empresarial. Este capítulo nos introduce el concepto de BPM con sus principios y ventajas. Estudiaremos el ciclo de vida de BPM y los componentes principales sobre los que se asienta esta disciplina y veremos importantes aspectos relacionados con BPM como la organización orientada a procesos, el pensamiento sistémico, estudiaremos los cinco niveles del modelo de madurez de BPM, el papel que deben jugar los departamentos de TI dentro de esta nueva visión empresarial y como a través de BPM podemos reducir el distanciamiento existente entre negocio y tecnología. Capítulo 5: Modelado de Negocios. En este capítulo abordamos el diseño de modelos y arquitecturas de negocio a partir de la estrategia empresarial, como paso previo a la definición de los procesos operativos que ejecutarán la estrategia. La recomendación será la de comenzar los proyectos por la visión y la estrategia y alinear ésta con los procesos en una estrategia Top-Down. Repasaremos la importancia de la creación de valor a nuestros clientes y la búsqueda de ventajas competitivas sostenibles a través de la cadena de valor de Porter y los distintos niveles de detalle (estratégico, táctico y operacional), con los que describir nuestros procesos de negocio. Veremos las arquitecturas empresariales que nos permitirá alinear negocio y tecnología y dentro de ellas diferentes estándares, frameworks y modelos de referencia como TOGAF, que nos ayudarán en la especificación de nuestros procesos de negocio. Para finalizar, analizaremos el BMM (Business Motivation Model) como 25


estándar de OMG (Object Management Group) para el establecimiento de la estrategia empresarial. Capítulo 6. Modelado de procesos. BPMN. Este capítulo se dedica íntegramente a la descripción de la notación BPMN (Business Process Model Notation) como estándar para la descripción de procesos. A lo largo del capítulo se describen los distintos elementos que forman parte de BPMN y se muestran ejemplos de su utilización en distintos escenarios de forma que el lector pueda a través de esta notación, implementar distintos tipos de procesos en base a los ejemplos y plantillas de uso más común. La tercera parte del libro se ocupa de la implementación de un proyecto BPM y los puntos que debemos considerar en esta implementación. Si antes hemos visto como alinear la estrategia con los procesos ahora alinearemos los procesos con la tecnología a través de las herramientas BPMS (Business Process Management Systems) que utilizaremos para implementar los proyectos de BPM. Capítulo 7. Implementación de BPM. Este es el capítulo más extenso del libro, pues en el recopilamos todo lo visto con anterioridad de una forma práctica y dirigida hacia la implementación de un proyecto de BPM. En base a un ciclo de aprendizaje y mejora continua, describimos las distintas fases de este ciclo de implementación, las actividades y herramientas a utilizar en cada fase, los objetivos a alcanzar en cada fase e indicaremos las tareas de gestión de proyecto más importantes que deberemos considerar en cada una de ellas. Al final del capítulo hablaremos un poco más de la importancia de la gestión de proyectos y describiremos algunas de las áreas de esta disciplina que deben ser gestionadas globalmente para todo el proyecto, independientemente de la etapa del mismo en que nos encontremos y veremos los principales factores críticos de éxito para un proyecto de BPM. Capítulo 8. Tecnología BPM. BPMS. En este capítulo describiremos los BPMS (Business Process Management Systems) y las tecnologías y arquitecturas informáticas que hacen posible la implementación de estas soluciones. Entenderemos la evolución de las plataformas de workflow y sistemas EAI´s y Middleware y su convergencia en los BPMS. Atendiendo al ciclo de vida de los procesos, se descri26


ben los principales módulos de estos sistemas: el modelador gráfico de procesos, el entorno de integración con aplicativos y sistemas informáticos, el servidor de procesos, la ejecución de los procesos y su simulación y la monitorización de los procesos implementados. El capítulo termina con un repaso a la arquitectura SOA (Service Oriented Architecture) y su sinergia con BPM. Para entender como se ha llegado a BPM, representamos en forma de árbol los principales conceptos, teorías, estándares, modelos y herramientas que han conducido a BPM y que desarrollaremos a lo largo del presente libro.

27

PARTE 1. FUNDAMENTOS DE LA GESTIÓN POR PROCESOS Cap. 1. La gestión por procesos. Cap. 2. Los caminos hacia BPM. Cap. 3. Tecnología, Innovación y Modelos de Negocio.

Capítulo 1. La gestión de procesos

Capítulo 1. La gestión de procesos.

La empresa como sistema. Uno de los principios fundamentales de BPM es que los procesos de negocio son activos fundamentales de la empresa para aportar valor a nuestros clientes y que analizando, midiendo y controlando estos procesos, podemos proveer a nuestra organización de mejora continua y flexibilidad en la adopción del cambio. Vamos ahora a visualizar y entender una organización desde el prisma de BPM. La idea fundamental es pensar en nuestra organización como una organización orientada a procesos, donde dejaremos atrás la visión departamental de la misma, en la que cada departamento tiene sus propias funciones y responsabilidades. Para ello, pensaremos “holísticamente”, es decir, pensaremos en la organización como un todo, en el que las actividades y departamentos de nuestra organización están relacionados unos con otros en un sentido lógico y con el único objetivo de alcanzar unos objetivos de negocio y proveer de valor a nuestros clientes. En esta visión, veremos los procesos de negocio como un conjunto de actividades y decisiones que se inician por la ocurrencia de un evento específico y que ejecutadas de forma coordinada, permiten alcanzar ese objetivo de negocio. BPM (Business Process Management) o gestión por procesos de negocio, es una disciplina de management (gestión) que se basa en la coordinación y colaboración de todas las actividades y tareas necesarias para realzar un proceso de negocio que entiende que diseñando, analizando,

31


gestionando y monitorizando los procesos que opera nuestra organización, podemos influir sobre ellos y en consecuencia sobre sus resultados. El no centrarnos en las partes o áreas funcionales del sistema por separado, como cadenas de causa-efecto y centrarnos por el contario en el conjunto, en el estudio de las relaciones e interacciones entre las partes del sistema, nos permitirá extraer propiedades esenciales y características que no tienen las partes del sistema cuando las consideramos aisladamente, y nos conducirá a esta visión holística y sistémica, que nos introducirá en el cambio de paradigma que implicará BPM. Por definición, un sistema es algo compuesto por partes independientes, cuya existencia se mantiene a través de la interacción mutua entre las partes que lo componen y en el que la comprensión de estos sistemas, sólo se produce cuando se estudian globalmente. Esta teoría aplicada al mundo de la organización empresarial, significa que una empresa está compuesta por una serie de partes, pero que del análisis de estas partes, no podemos explicar suficientemente el funcionamiento de toda la empresa. Es decir, que aunque nuestra empresa tenga un magnífico departamento de producción, pero esta falla en la venta de sus productos, no servirá de nada lo bien que produzcamos nuestros productos, pues estos no llegarán a los clientes que deberían pagar por ellos y nuestra empresa fracasará estrepitosamente. De la Teoría General de Sistemas (TGS), los sistemas se clasifican en sistemas abiertos y cerrados. Los sistemas abiertos, son aquellos que se comunican con el entorno y que precisan de éste para subsistir. De este entorno, los sistemas abiertos reciben una serie de entradas (recursos financieros, recursos humanos, materias primas, electricidad, etc.), que a través de unos procesos de transformación, convierten estas entradas en unas salidas que devuelven al entorno en forma de servicios o productos terminados y que suelen además convertirse en entradas para otros sistemas. Los sistemas cerrados, por el contrario, son aquellos autosuficientes, que no precisan de realizar intercambio con el entorno para subsistir, y esta característica los hace ser determinísticos, es decir, que conociendo su estado en un momento determinado, podemos predecir su estado futuro. La visión de la organización como sistema cerrado y determinístico ha sido la visión de la teoría estructuralista tradicional, sin embargo, los sistemas empresariales no son cerrados y determinísticos, sino abiertos, probabilísticos, dinámicos e indeterminados y al igual que los seres humanos que gobiernan estos sistemas, sólo pueden aspirar a una racionalidad limitada, debido a la incertidumbre de un entorno en el que no podemos disponer de toda la 32


información. Estos sistemas abiertos marcarán el entorno en el que nos movamos en el presente libro, pues comparten con las organizaciones muchas propiedades y características que sobrevolaran a lo largo del libro, las cuales describiremos para ayudar a entender este tipo de sistemas y su comportamiento. Holismo: El todo es superior a las suma de las partes, el sistema no puede explicarse sino en su totalidad. Las organizaciones son partes de una sociedad o sistema mayor y frecuentemente son vistas como sistemas dentro de sistemas mayores o súper-sistemas, formando un todo que no puede ser comprendido tomando las partes independientemente y donde el cambio en una de las partes del sistema afectará al todo. Esta visión holística globalizadora que toma en cuenta la interacción entre las partes, se opone al enfoque analítico tradicional y será un concepto muy ligado a la disciplina de BPM. Retroalimentación: La retroinformación es una característica indispensable para la supervivencia de los sistemas abiertos y para que estos puedan desarrollarse en su entorno modificando su comportamiento en función de las exigencias del entorno. La retroalimentación (feedback, en inglés), se produce cuando las salidas del sistema vuelven a ser entradas del sistema, permitiendo el control por parte del mismo, para que este tome medidas de corrección en base a la información retroalimentada. La retroalimentación constituye el concepto fundamental sobre el que se basará otro aspecto importante en BPM como es la automatización.

En la retroalimentación, la salida de un proceso puede modificar o influir en aquello que lo causa y por las propiedades de los sistemas, si un elemento modifica su condición, se modificará en consecuencia las condiciones de los demás elementos que componen el sistema y en consecuencia también el conjunto del sistema, por lo que la operativa en la retroalimentación deberá ser de tal forma que el sistema regule las entradas en función de la 33


información producida por la retroalimentación y de esta forma, ajustar las salidas a los criterios y estándares establecidos o deseados en lo que denominamos un “bucle de retroalimentación”. Existen dos tipos de retroalimentación: -

-

Retroalimentación negativa: cuando el sistema se desvía de su normal comportamiento, la retroalimentación advierte de esta variación al sistema y toma las medidas necesarias para corregir su comportamiento. Retroalimentación positiva: más proactiva que la negativa, y que actúa sobre las entradas para prevenir desviaciones en la salida. Este tipo de retroalimentación también se denomina “Feed-forward” (alimentación hacia delante, en español) donde el control se realiza a la entrada del sistema, asegurándonos de que este no tenga entradas corruptas o malas y de esta forma, los errores no serán consecuencia de las entradas sino de los procesos mismos que componen el sistema. Esta retroalimentación positiva será la que permita la transformación radical en las organizaciones.

Trasladando la retroalimentación de los sistemas a los procesos, podemos presentar un gráfico más elaborado del comportamiento de los procesos en el que vemos la retroalimentación circulando de los clientes y partners al proceso así como del proceso a los proveedores para optimizar las entradas:

Entropía: La teoría de sistemas toma este concepto de la segunda ley de la Termodinámica para medir el equilibrio de un sistema. La entropía es la tendencia natural de los sistemas a consumirse, desorganizarse y morir, y me34


dirá el desgaste que el sistema presenta por su funcionamiento en el transcurso del tiempo. Debido a la entropía, los sistemas deben ser permanentemente controlados debido a la tendencia natural de estos a aumentar su entropía y el grado de desorden cuando son dejados “a su aire”. A diferencia de los sistemas cerrados, en los cuales la entropía es siempre positiva, en los sistemas abiertos ésta puede ser estabilizada o reducida a través del intercambio con el entorno, por lo que para sobrevivir, las organizaciones deben asegurarse una provisión continua de entropía negativa en forma de recursos materiales y humanos. Morfogénesis: Relacionado con la retroalimentación y el aumento de entropía, algunos sistemas disponen de la capacidad de modificar sus estructuras básicas para adaptarse al entorno y sobrevivir en él y es por ello, una de las principales características identificadoras de los sistemas abiertos. Neguentropía: Como fuerza que se opone a la Entropía y a la acción del segundo principio de la termodinámica, tenemos la Neguentropía, que es el uso de la información como medio o instrumento para producir mayores niveles de orden y aumentar las probabilidades de supervivencia de los sistemas abiertos. Cuando añadimos información a un sistema, lo que estamos haciendo es ordenando los elementos que lo componen, de forma que a través del intercambio de información con el entorno, el sistema se auto-regula, ordenando y controlando la tendencia al caos, a diferencia de los sistemas cerrados, sin intercambio de información con su entrono y que acaban muriendo debido al aumento de la entropía, del desorden y el caos. Las herramientas de gestión de la información desempeñarán un importante papel en esta tarea de reducir la entropía y la mejora de la eficiencia de la organización, tanto a nivel de procesos y recopilación de datos para ser convertidos en información como a nivel de la necesaria comunicación de la visión y misión de la organización desde el nivel estratégico y directivo a los niveles intermedios y más bajos de la misma. Recursividad: Concepto muy utilizado en matemáticas y computación y que se refiere a cómo obtener conceptos nuevos empleando el mismo concepto que in35


tenta describir. La recursividad la utilizamos para resolver problemas reduciendo estos a uno o más sub-problemas que son idénticos en su estructura al problema original, pero más simples de resolver. Se dice que un proceso es recursivo si forma parte de sí mismo, es decir, se define en función de sí mismo. Isomorfismo: Que significa de “igual forma”, para referirse a la construcción de modelos de sistemas similares al original, pudiéndose reducir el estudio de un sistema al estudio de su isomorfo, pues los principios que rigen el comportamiento de uno en algunos aspectos pueden regir el comportamiento de otro. Homomorfismo: Concepto similar al anterior pero en el que dos sistemas son iguales pero sólo probabilísticamente. Este modelo se aplica en sistemas muy complejos y probabilísticos. Homeostasis: Es la propiedad de un sistema que define su nivel de respuesta o adaptación al contexto. La Homeostasis o “estado de equilibrio” es una característica de los sistemas mediante la cual estos regulan su funcionamiento interno para mantener una condición estable y constante de sus variables (disminuir su entropía), manteniendo el equilibrio por ajuste constante o anticipación y cambiando parámetros de su estructura interna mediante mecanismos de auto-regulación en los que participan todos los sistemas de un organismo vivo o de una organización. Atendiendo a esta propiedad de determinados sistemas podemos hablar de un tercer tipo de clasificación de los sistemas como adaptativos y que al final del libro describiremos al hablar de la gestión de casos (Adaptive Case Management). Teleología: O doctrina de las causas finales, es la atribución de una finalidad u objetivo último a procesos concretos. En la explicación teleológica, el resultado de un sistema se explica por aquello que produce, por sus efectos y no por sus causas.

36


Equifinalidad: Es una característica de los sistemas abiertos en los que el resultado puede alcanzarse por diversos caminos. Existen diversas formas en que los sistemas pueden producir un resultado u objetivo y en consecuencia muchos sistemas no se caracterizan en su comportamiento por las condiciones iníciales de las entradas para producir unos resultados sino por como diseñemos el camino en el proceso de transformación. Emergencia: Otra característica importante y que veremos más adelante en el libro, es la de la emergencia como una característica de los sistemas complejos por la cual los elementos más simples constituyentes del sistema se autoorganizan para formar sistemas más complejos. Cibernética: Hemos visto al hablar de la entropía de los sistemas, como estos siguen la segunda ley de la Termodinámica, según la cual, estos presentan una tendencia creciente hacia estados cada vez más desorganizados o de caos cuando no existe ninguna intervención o control sobre los mismos. Vimos también la Neguentropía como el uso del intercambio de información para reducir este desorden. Relacionado con ambos conceptos tenemos la cibernética. La cibernética (del griego Kybernos: timón, gobierno, control), se refiere a los sistemas autónomos capaces de ser guiados o controlados por alguien o algo fuera del sistema. La cibernética es la disciplina que estudia la comunicación y el control en animales y máquinas y su línea de estudio y trabajo es como obtener la respuesta deseada de los humanos y de las máquinas a través de proporcionar a estos las instrucciones y guías precisas para tomar futuras acciones mediante mecanismos de control y de autocorrección, principalmente a través de la Retroalimentación, de forma que contrarrestemos la tendencia natural hacia la desorganización. La circularidad que se da en la retroalimentación, será una característica de todo ser vivo que se auto-regule o tenga la capacidad de reorientarse o replantearse continuamente su funcionamiento para llegar a una meta u objetivo (principio de equifinalidad), o de mantenerse en unos rangos limitados (principio de homeostasis), a pesar de verse estos sistemas sometidos a las presiones del entorno.

37


La cibernética, desarrollada por Norbert Wiener (1894-1964), estudia los problemas y comportamientos de la organización y los procesos de control y transmisión de información en las máquinas y los seres vivos para permitir a los sistemas auto-dirigirse, auto-regularse y cambiar de estados en función del comportamiento y los cambios en el entorno y de esta forma mantener su equilibrio Homeostático. Wiener pretendía encontrar las razones que permitían el automatismo en las máquinas al igual que ocurre en los seres vivos, mediante el control de una máquina por otra a través de sensores instalados en la segunda para retroalimentar a la máquina controladora. Esta cibernética de Wiener se basaba en la retroalimentación negativa para adaptarse al medio conservando su estructura, pero Magoroh Maruyama fue un paso más allá al ampliar la cibernética con la retroalimentación positiva y permitir a los sistemas adoptar nuevas organizaciones, transformarse radicalmente y cambiar sus estructuras (Morfogénesis) en lo que ha dado en llamarse “cibernética de segundo orden”. Los mecanismos de control que utilizan los sistemas cibernéticos constan de cuatro elementos: -

Una meta u objetivo deseado. Un mecanismo de medición del estado actual del sistema. Un mecanismo de comparación. La toma de decisiones para emprender acciones que afectarán al funcionamiento del sistema.

La cibernética, basándose en los organismos vivos como modelo ideal de comportamiento, se dedicará al estudio del comportamiento de las máquinas y los seres vivos para producir procesos cada vez más automáticos, eficientes y adaptables, y en este sentido, estará íntimamente relacionada con la automatización de procesos que veremos a lo largo del presente libro y con la adaptación al cambio, hasta tal punto que algunos autores denominan a la cibernética como la ciencia de control del cambio. Resulta obvio que si los sensores de nuestra máquina no mostrasen ninguna variación (Retroalimentación nula), el sistema no deberá hacer nada y en consecuencia la base de la cibernética será el cambio y las variaciones que se produzcan en el entorno. Esta propiedad es la que observamos en los conocidos sistemas de automatización industrial denominados SCADA (acrónimo de Supervisory Control And Data Adquisition), sistemas software para el control y supervisión de procesos industriales que facilitan la retroalimentación en tiempo real y 38


el control e intervención de estos procesos productivos de forma automática. Además de las propiedades ya vistas, otras características y propiedades importantes de los sistemas son: -

-

-

-

-

-

Sinergia: Es el grado de concertación de las partes de un sistema. Expresa el grado de organización de los elementos del sistema y es función del tipo de relaciones que los vinculan. Cuanto más armoniosamente un sistema logre su función más sinérgico será. Permeabilidad: La permeabilidad de un sistema mide la interacción que éste recibe del medio y en consecuencia a mayor permeabilidad el sistema será más abierto. Integración: Un sistema es integrado cuando un cambio en cualquiera de sus partes produce cambios en las demás partes del sistema. Centralización: Un sistema se dice centralizado cuando tiene un núcleo que dirige a todos los demás y estos dependen para su activación del primero, ya que por sí solos no son capaces de generar ningún proceso. En los sistemas descentralizados este n úcleo está formado por varias partes del sistema. Adaptabilidad: Es la propiedad que tiene un sistema para aprender y modificar un proceso o estado, a través de un mecanismo de adaptación y en función de las modificaciones del entorno. La adaptabilidad no podemos conseguirla sin tener una relación de intercambio con el entorno. Mantenibilidad: Es la propiedad de un sistema de mantenerse constantemente en funcionamiento. Estabilidad: Un sistema es estable cuando puede mantenerse en equilibrio a través del flujo continuo de entradas y salidas del sistema. Éxito: Es la medida en que los sistemas alcanzan sus objetivos.

Sistemas y necesidad de adaptación al cambio. En todas las características y propiedades que hemos visto de los sistemas, vemos como para mantener un sistema abierto en equilibrio, debemos luchar constantemente contra el desorden entrópico, reduciendo el mismo de manera neguentrópica y a través de una retroalimentación negativa, de forma que el sistema no pierda su organización. Trasladado a los sistemas empresariales, es fácil deducir que una de las principales caracte39


rísticas de estos sistemas será el cambio constante, debido a las condiciones del entorno y la influencia que este entorno puede tener sobre el sistema, por lo que la empresa estará obligada a cambiar y adaptarse constantemente a este nuevo entorno para alcanzar el equilibrio deseado y poder sobrevivir. El cambio existe, no podemos hacer otra cosa que aceptarlo, pues ignorarlo nos conducirá al fracaso. Ante este cambio, podemos adoptar tres tipos de posturas o actuaciones, una postura “reactiva” reaccionando ante el mismo cuando aparezca, una postura “proactiva”, anticipándonos al mismo y previendo la nueva situación que se avecina para posicionarnos ventajosamente ante el nuevo entorno o también podemos ser nosotros los inductores del cambio y dirigirlo para convertirnos en los líderes y controladores del cambio. De todas ellas la mejor sin duda alguna es la tercera, pero esta requiere de experiencia, un fuerte liderazgo y una actitud innovadora en toda la organización, no siempre fácil de conseguir. El poder llegar a esta última posición es en lo que la disciplina de BPM puede ayudarnos y alrededor de esta idea de adaptación al cambio de forma ágil y flexible, girarán prácticamente todas las partes y capítulos de este libro.

Niveles de Actividad organizacional. En la concepción de las organizaciones como sistemas, todos los elementos de la misma están conectados e interrelacionados: clientes, proveedores, estructura organizativa, tecnología, etc. Para poder abarcar esta comprensión, podemos dividir esta estructura o sistema en tres niveles de actividad interconectados: -

-

-

40

El nivel organizacional: el cual especifica la estructura básica y las funciones que la integran así como el ambiente en el que actúa la organización. El nivel de procesos: especificará la forma en que se realiza el trabajo y se producen los bienes y servicios que la organización ofrece a sus clientes. Este nivel describirá el flujo de tareas o secuencia de actividades necesarias para realizar las funciones de la organización. El nivel de puesto de trabajo: es el nivel donde los empleados ejecutan las tareas descritas en los procesos de la organización. Las personas y el cómo realicen sus tareas reflejará finalmente la calidad de la organización y los procesos.


Los tres niveles son importantes para el éxito de nuestra organización y al principio del capítulo ya comentábamos que si nuestra empresa es muy buena en el proceso de producción, pero no consigue llevar los productos a sus clientes, la excelencia y los esfuerzos en producción no serán suficientes para evitar el fracaso de la empresa como un “Todo”. De igual manera, la queja de un cliente puede tener su causa en cualquiera de los tres niveles que acabamos de describir: un empleado que no cumplió su tarea en el nivel de Puesto de Trabajo, el mal funcionamiento o diseño de un proceso interno de la empresa en el nivel de Procesos o la falta de objetivos claros por parte de la empresa en el nivel Organizacional. Al igual que en los sistemas, una empresa no puede ser descrita por sus partes independientes, la empresa es un sistema abierto y su comprensión se produce al estudiarla globalmente, por lo que la ineficiencia en uno de los niveles provocará la ineficiencia del conjunto. A lo largo del presente libro, nos moveremos continuamente entre estos tres niveles. Hablaremos de la Estrategia de las organizaciones, de la importancia de la misma y de la necesidad de disponer de una metas, objetivos y estructuras organizacionales claras y bien definidas; de las Personas, que finalmente son las que ejecutarán las tareas definidas en los procesos y de la correcta gestión de estas personas y su importancia para el éxito de la empresa, pues es en este punto donde fallan muchos proyectos empresariales y de BPM. Y por supuesto, hablaremos también de los Procesos y de estos como nexo de unión entre la estrategia y la ejecución, siendo en este nivel de procesos donde centremos toda nuestra atención, al ser los proce41


sos, en última instancia, los responsables de cumplir con la estrategia de nuestra organización y de alcanzar los resultados esperados por nuestros clientes.

Gestión de procesos. Si definimos un negocio como una serie de recursos humanos, materiales y económicos que organizados en base a una serie de procesos, realizan unas transacciones que generan un valor al cliente y un beneficio a la empresa, podemos extraer que un proceso, al igual que los sistemas, es un conjunto de actividades que recibiendo una serie de entradas (inputs) produce unas salidas (outputs) que producen un beneficio para la organización que ejecuta el proceso y generan un valor a quién recibe esas salidas. El que un trabajo o serie de pasos operativos necesarios para realizarlo, se puedan describir como un proceso que podemos mejorar, no es algo nuevo y casi sin pretenderlo, este procedimiento se ha ido imponiendo en todas las prácticas de gestión empresariales de los últimos años. La gestión de procesos ha estado siempre presente a lo largo de la historia de la gestión moderna de las organizaciones y de alguna forma, todas las empresas se estructuran entorno a procesos más o menos formales. En la época de Frederick Taylor y hasta bien entrado el siglo XX, los procesos se percibían como acciones independientes dentro de áreas funcionales de la organización, relacionados por un principio de causa-efecto para producir un determinado producto o servicio. Con el desarrollo de las distintas teorías y prácticas de gestión empresarial, el escenario ahora es el de una visión holística de los procesos de negocio y su reconocimiento como claves para lograr la eficiencia operacional, la excelencia, la mejora continua, la adaptación al cambio y en definitiva el éxito empresarial. Esta evolución ha dado origen a una disciplina específica para la gestión por procesos denominada BPM. En el día a día de nuestras organizaciones, no pensamos en cómo realizamos el negocio en nuestra empresa. Por ejemplo, si queremos crear una empresa para vender tomates y obtener un beneficio con ello, hemos de diseñar los procesos que ejecutará esa empresa para producir valor a sus clientes, es decir, el beneficio lo obtenemos a través de una serie de transacciones para las cuales diseñamos los procesos que han de soportar esas 42


transacciones: compramos las semillas, preparamos la tierra, plantamos las semillas, regamos y después y si el tiempo nos acompaña, recogemos los tomates, los almacenamos y distribuimos a nuestros clientes obteniendo un beneficio. Una vez diseñados estos procesos que nos conducirán a poder vender los tomates, adquirimos los recursos económicos y materiales necesarios para poder ejecutar todos estos pasos así como contratar a las personas que nos harán falta para poder realizar las tareas asociadas a estos. Este negocio de tomates, aunque ideal, no es trasladable a la gran mayoría de negocios que operan hoy en día, ni resultarán tan obvios en su ejecución, ni tan siquiera para un negocio de venta de tomates, dominado por las grandes cadenas de alimentación y donde vender tomates obteniendo un beneficio por ello puede resultar hasta ilusorio. Sin pretender desalentar a nadie que desee cultivar y vender tomates, la realidad es que los procesos, funciones y secuencias de tareas que debemos ejecutar para crear valor y cómo debemos ejecutar estos procesos, son cada vez más complejos y ocurren cada vez más, fuera de los límites de nuestra empresa, por lo que requeriremos de mejores funciones, más optimizadas y eficientes así como de procesos cada vez más complejos, para poder llevar nuestro negocio a buen puerto. La gestión por procesos ha surgido como una forma de dominar esta creciente complejidad a partir de una serie de teorías y prácticas de gestión que comenzando con Adam Simith y su teoría de la especialización del trabajo, llegan hasta nuestros días, pasando por las teorías de la calidad total, six sigma, la reingeniería, las tecnologías de la información (TI) y un largo etcétera que veremos en el siguiente capítulo. Los procesos en la época industrial, fueron utilizados para la mejora de la eficiencia en entornos de producción y fabricación, pero han evolucionado hacia la búsqueda de la mejora en los niveles tácticos y estratégicos, en los cuales, mucho más que en los niveles operacionales, radican las posibilidades de mejora de los resultados empresariales. El poner el foco no sólo en los resultados operacionales, tradicionalmente asociados a metodologías como Six Sigma, sino también en los estratégicos, nos conducirá a la necesidad de alinear el diseño de los procesos con los modelos de negocio. Vemos pues como los procesos son algo intrínseco a las empresas, aunque no siempre sean percibidos como tales, y que estas no hacen otra cosa sino ejecutar procesos de negocio, que pueden estar más o menos diseñados y automatizados, pero lo que si sabemos con certeza, es que las empresas deben ejecutar estos procesos y gestionarlos, lo cual implica diseñarlos de acuerdo a los modelos de negocio, vincular a los actores que participan en 43


los mismos y seguir la evolución de los indicadores de negocio asociados a estos procesos. En este primer capítulo nos centramos en la base de la teoría de procesos y en cómo estos conforman lo que nuestra organización hace y cómo lo hace, hasta el punto que podemos decir que una empresa es tan eficiente como lo son los procesos que ésta opera. El poner el foco en los procesos de negocio y la importancia de centrar la atención en estos, fue apareciendo de forma gradual a medida que se avanzaba en los modelos organizativos y de gestión empresarial, por su capacidad de responder a los requisitos del mercado y atender a los cambios que se producen en el entorno de la empresa. De esta forma, en cada avance y evolución en las prácticas de gestión empresarial y en cada evolución de los mercados, estas teorías se fueron aproximando cada vez más hacia la idea de centrase en los procesos de negocio, al principio, viendo los procesos de forma individualizada y centrando la atención sobre aquellos de mayor importancia para la operativa de las empresas, generalmente los procesos relacionados con la producción y manufactureros, para más tarde, pasar a un pensamiento integral de la empresa, vista como un sistema, en lo que se ha venido en llamar “process thinking” o pensamiento orientado a procesos, que ve la empresa de forma holística (el todo es más que la suma de las partes que lo componen) y que conforma la organización orientada a procesos. Desde la época de la producción en masa, se ha establecido una cultura empresarial encaminada a producir el mayor número de unidades de producto en el menor tiempo y con el menor coste posible. Para alcanzar estos niveles de productividad, las organizaciones han sido gestionadas de acuerdo a principios basados en la división del trabajo y la especialización en departamentos o unidades funcionales, en las que el organigrama organizacional establecía la cadena de mando de forma descendente, las máquinas marcaban el ritmo de producción y las personas se agrupaban en departamentos según el tipo de trabajo que realizasen. Esta división configuró empresas departamentales o funcionales, más preocupadas de los objetivos de sus departamentos que de los flujos y procesos de negocio que atraviesan toda la organización y cuyo resultado es el que finalmente perciben los clientes. En la nueva visión de la orientación a procesos, esta organización jerárquica no nos permitirá producir mejoras hacia unos clientes que no podemos situar en ningún punto de nuestro diagrama organizacional, pues

44


las unidades departamentales rompen la secuencia de actividades que producen valor a estos clientes. Para romper con esta orientación a funciones y antes de dirigirnos hacia BPM y la organización orientada a procesos, que serán dos de los aspectos fundamentales de este libro, podemos realizar una aproximación a este entorno, viendo los departamentos como sistemas o procesos con sus respectivas entradas, salidas, procedimientos internos y con sus clientes y proveedores, que pueden ser internos (otros departamentos) o externos (donde pueden estar incluidos los clientes finales).

Ampliando más el estudio, podemos simplificar todavía más esta visión organizacional y reducirla a uno o varios procesos transversales, que serán los procesos de negocio centrales de la empresa, sobre los cuales añadiremos y estableceremos las mismas relaciones cliente-proveedor, con los procesos de apoyo (financiero, recursos humanos, tecnológicos, etc.) que aunque no aporten valor al cliente final, serán necesarios para el funcionamiento de estos procesos y de la empresa, pues estos procesos también tiene clientes, aunque en este caso son clientes internos de la organización y como procesos que son también crean valor.

Para estos procesos centrales de negocio, deberemos, además de la necesaria identificación de los mismos, identificar sus entradas y salidas, los responsables de cada uno de los procesos, los clientes, la misión y objetivos del proceso, los procedimientos internos, instrucciones de funcionamiento, tareas que deberá desarrollar así como los subprocesos que pueda conte45


ner e identificar los indicadores que nos permitan realizar el seguimiento de la eficiencia de estos procesos. Hemos avanzado en este apartado muchas de las ideas que se desarrollarán en los siguientes capítulos, en especial la idea de la organización orientada a procesos, donde se reconoce la existencia de la transversalidad de los procesos y donde el trabajo se orienta hacia la satisfacción de las necesidades y expectativas de los clientes mediante el diseño y optimización de los procesos de negocio que crearan valor añadido a estos clientes. En este cambio, se trastocarán las estructuras de la organización tradicional hacia un nuevo tipo de organización en el que las áreas funcionales pasarán de ser sistemas cerrados a sistemas abiertos, los flujos de información pasarán de ser verticales y manuales a horizontales y automatizados, donde se sustituirán las órdenes de trabajo por reglas de negocio que guiarán el comportamiento de los procesos y donde el control del trabajo y del desempeño se realizará en base a indicadores medibles y en tiempo real y no mediante la presencia física de supervisores. Estos cambios en la estructura organizacional supondrán también una reestructuración de las tradicionales arquitecturas informáticas aisladas del negocio, que dejarán de servir a departamentos concretos y pasarán a formar parte de los procesos.

Esta orientación a procesos, no es algo nuevo. En los últimos años y gracias al desarrollo de los sistemas ISO de calidad, se ha desarrollado la visión de la empresa orientada a procesos y los modelos y metodologías de gestión por procesos como capacitadores no solo para alcanzar la excelencia empresarial, sino también la capacidad innovadora y de adaptación al cambio que el nuevo entorno empresarial requiere. Los avances en gestión empresarial del pasado siglo, especialmente los modelos japoneses de mejora continua, la innovación, la reingeniería, la orientación al cliente y la adecuación de los modelos operacionales de las empresas a las actuales necesidades de los mercados, ya apuntaban la im46


portancia de los procesos como base para la gestión organizacional y su capacidad de contribuir a los resultados. Este abordaje que comenzó con TQM (Total Quality Management) y la mejora continua, comenzó a ser insuficiente en un entorno donde las exigencias de los clientes y sus necesidades están en continuo cambio. En los modelos anteriores, la orientación al cliente y el cómo satisfacer sus necesidades y expectativas cobran especial importancia y la gestión por procesos es incluida en todos ellos como buenas prácticas o principios de excelencia para conseguir una visión ágil para producir productos y servicios que no sólo se adapten a las necesidades de los clientes, sino que puedan responder a las cambiantes necesidades y expectativas de los mismos. En la norma ISO 9001:2000 se especifica en el apartado 4.1a: “identificar los procesos necesarios para el sistema de gestión de la calidad y su aplicación a través de la organización”. En el apartado 4.1b: “determinar la secuencia e interrelación de estos procesos” y en el apartado 7.1: “la organización debe planificar y desarrollar los procesos necesarios para la realización del producto”. El Modelo Europeo de Excelencia (EFQM) dedica íntegramente unos de sus módulos a la gestión de procesos enunciado: “La satisfacción del cliente, la satisfacción de los empleados y un impacto positivo en la sociedad se consigue mediante el liderazgo en política y estrategia, una acertada gestión de personal, el uso eficiente de los recursos y una adecuada definición de los procesos, lo que conduce finalmente a la excelencia de los resultados empresariales”, y en el punto número 5, el EFQM establece como la organización diseña, gestiona y mejora sus procesos con objeto de apoyar su política y su estrategia y para generar valor de forma creciente a sus clientes y sus otros actores. De la orientación al cliente como catalizadora de la gestión de procesos, surge la idea de ver la organización en sí misma como un proceso, la cual realiza una serie de operaciones encaminadas a satisfacer a esos clientes y se plantea el diseño de procesos orientados al cliente, independientemente de la estructura organizacional de la empresa. La gestión de procesos se conforma como una herramienta capaz de alcanzar los objetivos expuestos por TQM en un entorno como el descrito, es decir, permite implementar de forma rápida y ágil estos problemas de adaptación al cambio y focalización en el cliente. Los procesos son extremadamente importantes para la empresa y el cuidado en su diseño y funcionamiento operativo resulta crucial para el funcionamiento de las empresas, pues son repetitivos, lo que implica que si 47


su funcionamiento no es todo lo eficiente que podría ser, provocarán ineficiencias también repetitivas y de igual manera, si estos son eficientes, provocarán que la empresa sea también cada vez más eficiente y es por ello que adoptaremos un planteamiento de mejora continua de nuestros procesos mediante la mejora o transformación radical de estos y prestaremos especial cuidado en el diseño y vigilancia de su funcionamiento, de forma que la operativa empresarial de estos procesos de negocio sea lo más eficiente posible. Para hacernos una idea de su importancia y como las empresas se conforman entorno a procesos, podemos enumerar algunos de los procesos empresariales más comunes en las organizaciones: -

Gestión de órdenes de venta, Gestión de devoluciones. Gestión de gastos de viajes. Gestión de Reclamaciones. Órdenes de compra. Gestión de recursos compartidos. Generación de Informes de gastos. Solicitudes de reembolso. Facturación a clientes. Diseño de nuevos productos. Encuestas de empleados, clientes. Evaluaciones de personal. Solicitud y gestión de vacaciones. Hojas de tiempo. Solicitudes de empleados (vacaciones, permisos, etc.) Informes de control de calidad, certificaciones. Preparación de presupuestos. Gestión de proyectos, etc.

De la importancia que para las empresas tiene la gestión de procesos, surge la necesidad de entenderlos, documentarlos y conocer su funcionamiento para poder hacer estos procesos lo más eficientes y competitivos posible respecto a los de nuestra competencia, por lo que necesitaremos además mejorarlos continuamente mediante la mejora de procesos, el rediseño y reingeniería de estos, así como automatizarlos y monitorizar su operativa en base a indicadores de gestión y rendimiento e integrarlos con nuestra infraestructura de TI (Tecnologías de la Información). Sobre todo este camino es sobre lo que trata BPM, pero antes describiremos algunas 48


características básicas de la Teoría General de Procesos como son el cómo definir los procesos de nuestra organización, las principales características y propiedades de estos, cómo identificarlos y clasificarlos para poder trabajar en su mejora, pues identificar y modelar los procesos será el primer paso para que estos puedan ser analizados. Para ello deberemos saber qué personas estarán involucradas en el proceso, qué tecnología usan, donde comienzan y terminan los procesos y las interrelaciones que tienen con otros procesos, quién se verá afectado por el funcionamiento del proceso y una serie de datos del proceso que nos ayudarán a su identificación y entendimiento. Las personas con las que deberemos contar para la realización de esta tarea serán aquéllas que trabajan directamente sobre el proceso o aquéllas que se puedan ver afectadas por su funcionamiento, pues estos perfiles serán más sensibles a los distintos pasos y operativas del proceso que los perfiles más gerenciales.

Definición de proceso: Existen varias definiciones sobre qué es un proceso, por lo que diremos varias de estas definiciones que nos ayudarán a entenderlos: -

-

-

Conjunto de actividades organizadas para conseguir un fin, desde la producción de un objeto o prestación de un servicio hasta la realización de cualquier actividad interna. Conjunto de recursos y actividades interrelacionados que transforman elementos de entrada en elementos de salida. Secuencia de actividades que van añadiendo valor mientras se produce un determinado producto o servicio. Conjunto de actividades relacionadas que transforman entradas en salidas o resultados. Conjunto de acciones y tareas que se realizan de forma secuencial y que en su conjunto, proporcionan valor añadido a los clientes. Un proceso es la mezcla o transformación de unas entradas en un rendimiento de mayor valor.

En todas ellas observamos como subyacente el mismo concepto: que los procesos son un conjunto de tareas para ofrecer un producto o servicio con mayor valor añadido a un cliente y que un proceso es una secuencia ordenada y lógica de actividades de transformación que parten de unas entradas para alcanzar unos resultados programados que se entregan a clientes. 49


Características, Propiedades y Requisitos de los procesos: Dos son las propiedades más características y observables en los procesos: su variabilidad y repetitividad como clave para su mejora. Variabilidad de los procesos: Cada vez que repetimos un proceso, éste presenta variaciones tanto en la ejecución de sus actividades como en las salidas del proceso que pueden repercutir en la satisfacción del cliente. Todos los procesos tienen una variabilidad inherente que puede evaluarse por métodos estadísticos y mostrarse en forma de gráficos de control que nos muestren la variabilidad y de esta forma poder trabajar en la mejora del proceso para reducir y controlar su variabilidad y mejorar sus niveles de eficacia y eficiencia:

Repetitividad del proceso: En última instancia los procesos se crean para poder ser repetidos y esta característica nos permitirá trabajar sobre el proceso para su mejora de forma que cuantas más veces repitamos el mismo, más conoceremos su funcionamiento y las posibles variaciones sobre el mismo para poder mejorar sus resultados esperados. 50


De la definición de proceso, inferimos que esta serie de actividades ha de ser repetitiva y medible de forma que podamos predecir la transformación de las entradas en salidas y alcanzar los niveles de estabilidad requeridos por el proceso. Otras características importantes de los procesos son: -

-

Responden a alguna acción o evento específico. Producen resultados específicos que son entregados a clientes o “stakeholders” (personas que puedan verse afectadas positiva o negativamente por el desarrollo de un proyecto o del propio proceso) Cruzan uno o varios departamentos o límites funcionales de la organización. Se pueden describir sus entradas y sus salidas. Pueden ser medidos para evaluar la eficiencia y rendimiento de los mismos. Los procesos describen como se realiza el trabajo y son observables, medibles, mejorables y repetitivos.

Los procesos también presentan una serie de propiedades como por ejemplo: -

-

Capacidad: es la carga máxima que puede soportar el proceso. Productividad: la relación entre las entradas y las salidas. Eficacia: es la medida con la que los resultados cumplen con los objetivos especificados para el proceso y que el cliente reciba lo que espera. Flexibilidad: medida de la adaptabilidad a las circunstancias y los cambios imprevistos que puedan surgir en el proceso.

Entre los requisitos que deben ofrecer los procesos podemos enumerar: -

Todos los procesos deben tener un responsable asignado que asegure su cumplimiento y eficacia. Todos los procesos deben cubrir el ciclo PDCA (Plan-Do-CheckAct) que veremos en este capítulo y en capítulos posteriores. Un sistema de indicadores que permita evaluar la eficacia de los procesos. Una estructura coherente de procesos que describa el funcionamiento de la organización o de una parte de la misma. 51

BPM (Business Process Management) -

Los procesos tienen que ser fácilmente comprendidos por cualquier persona de la organización, sin importar a que departamento pertenezca o función que desempeñe en la organización y sean estas personas perfiles de negocio o técnico de dentro de la organización. En este sentido y como veremos a la hora de identificar los procesos en la fase de levantamiento de procesos, es importantísimo conseguir la implicación y participación de las personas de la organización desde las fases más tempranas para conseguir su implicación también en las fases posteriores, evitando imposiciones, buscando acuerdos y conciliando las distintas soluciones y problemas.

Modelado de procesos. Un modelo es una representación esquemática o conceptual de los procesos de la organización y de las relaciones entre estos, que representa de forma secuencial, como funcionarán los procesos y como se realizan las tareas que producirán la salida de un producto o servicio. Con esta representación simplificada a alto nivel de los procesos, se pretende disponer del conocimiento de las actividades que producen valor a nuestros clientes e identificar aquellas que no aporten valor o sean ineficientes en su funcionamiento así como comprender su operativa para poder reducir costes, tiempos de proceso, optimizar el uso de los recursos, coordinar las actividades de los participantes en el proceso y trabajar en la mejora de los mismos. El modelado nos ayudará a pensar más clara y coherentemente y a visualizar las mejores opciones y oportunidades de que disponemos en los procesos que ejecuta nuestra empresa. Sin embargo, y aunque los modelos nos resulten idóneos para entender muchas situaciones y escenarios, debemos partir de la premisa de que los modelos empresariales y organizacionales no serán siempre perfectamente explicables, como puedan ser los modelos matemáticos o físicos, pues en los modelos empresariales, tendremos que contar con el componente humano que forma parte de todos estos sistemas y los humanos, aprendemos, nos adaptamos, mejoramos, interaccionamos y experimentamos sin seguir unas reglas fijas, provocando un comportamiento más probabilístico que determinista, por lo que nunca podremos construir modelos que cubran todas estas posibilidades y deberemos hacer uso de nuestra inteligencia, visión e intuición para predecir el comportamiento de estos sistemas y procesos.

52


Para realizar el modelado, deberemos realizar una serie de tareas como son la identificación de los procesos, su selección y clasificación, con objeto de disponer de un mapa de procesos de la organización que será lo primero que deberemos tener para implantar la gestión por procesos. Este mapa de procesos será como nuestra hoja de ruta, la cual deberá ser lo suficientemente detallada para poder entender los procesos, pero sin perdernos en detalles que puedan dificultar su comprensión. El sustituir muchas veces todo el conocimiento, procedimientos y normativas “escritas” por un modelo gráfico y visual como el mapa de procesos facilitará la comprensión de los mismos en todos los niveles de la organización. La recomendación para realizar este mapa de procesos es centrarse en las actividades y procesos que aporten valor al cliente, seleccionar procesos que empiecen y finalicen en el cliente y no tanto en los procesos de producción o aquellos dirigidos a corregir errores, en su lugar deberemos atacar las causas de esos errores, pues como clientes, por ejemplo, siempre preferiremos no tener problemas con los productos que adquiramos a disponer de un buen servicio de atención de reclamaciones. La mejora de procesos consistirá precisamente en cómo hacer las cosas mejor y no en ser capaces de apagar los fuegos cuando estos aparezcan, para lo cual trabajaremos en la coordinación entre los diferentes procesos, suprimiendo aquellos procesos o pasos de los mismos que no aporten valor, la eliminación de errores, ineficiencias y la reducción de los ciclos de proceso y la incorporación de las TI para mejorar su grado de gestión y control. El identificar los procesos será una tarea primordial y previa a cualquier proyecto encaminado hacia la mejora de procesos o de BPM. Esta tarea se encaminará a conocer los procesos sobre los que queremos trabajar, por lo que deberemos hacernos una idea sobre qué trata de resolver el proceso, qué pretende alcanzar y por qué existe el proceso, así como el grado de importancia que éste tiene para la organización y para sus clientes. Indagaremos también en cómo funciona el proceso actualmente (lo que más tarde veremos como el As-Is, en la fase levantamiento de procesos) y especificaremos el mapa de procesos conjunto de la organización, dónde comienza y termina cada proceso, quiénes son los participantes y unidades de negocio que participan en los distintos procesos y cuáles son sus responsabilidades, las razones por las que se pretende analizar y/o trabajar en la mejora del proceso, así como el valor que se pretende conseguir con este trabajo. Analizaremos la información que fluye por los distintos procesos y cómo se 53


produce el intercambio de ésta, con qué sistemas internos y externos interactúan los procesos, las reglas de negocio que rigen el comportamiento de los procesos y en general, toda la información que podamos recabar sobre los procesos objeto de nuestro proyecto. Aunque en capítulos posteriores profundizaremos en muchos de estos puntos dentro de BPM, listaremos ahora una serie de puntos necesarios para una correcta identificación y especificación previa de los procesos.

Entradas y Salidas: En todo proceso hay dos importantes agentes que no podemos olvidar: clientes y proveedores. Los rendimientos o salidas del proceso pueden ser un producto, un servicio o la conclusión de una tarea. Las entradas del proceso pueden ser: personas, materiales, equipo, información, técnicas, métodos, procedimientos, políticas, tiempo, dinero, etc. A través de los procesos de transformación, el proceso producirá los productos y servicios que constituirán la salida de los procesos. La salida de todo proceso va a los clientes, sean estos internos (que trabajan en nuestra empresa) o externos (que trabajan fuera de ella). Los clientes son la parte más importante de cualquier proceso, pues son quienes comprarán o recibirán las salidas de nuestro proceso y la satisfacción de sus necesidades y expectativas será la razón última de los procesos y el motivo por el que trabajaremos en su mejora. Cuando trabajamos con procesos, debemos concentrarnos en el resultado ofrecido al cliente priorizándolo sobre las tareas y actividades individuales que realicemos para producir ese resultado y considerar los requisitos de calidad exigidos a los productos o servicios producidos por los procesos de forma que estos cumplan con las exigencias establecidas. De los clientes debemos escuchar sus opiniones y retroalimentar el proceso en función de éstas, mientras que de los proveedores debemos también obtener retroalimentación pero debemos entre otras cosas vigilar atentamente la calidad para asegurarnos correctas entradas en nuestros procesos. Además de a los clientes, no debemos olvidar a los demás stakeholders (promotores, partners, socios o personas involucradas o afectadas por el proceso), sobre las cuales debemos prestar atención pues éstas pueden afectar o influenciar sobre el proceso positiva o negativamente y en consecuencia deben ser tenidos en cuenta para no generar insatisfacción y pérdidas de eficiencia. 54


La misión: Esta será la razón de ser y el motivo por el cual se asignen recursos y esfuerzos para poner en marcha un proceso. ¿Para qué hacemos el proceso?, ¿Para quién lo hacemos? y ¿Cómo la hacemos?

Objetivos del proceso: Los resultados que queremos alcanzar con el proceso. En la medida en que cada proceso se realiza para cumplir con unos objetivos, debemos asegurar la consistencia entre lo que los procesos hacen, los objetivos y metas organizacionales y las salidas del proceso.

Los Clientes: Aunque ya hemos hablado de su importancia, los clientes serán personas u organizaciones que utilizarán los productos y servicios fruto del proceso y que en función de sus necesidades y expectativas aprobaran finalmente su resultado y es por ello que será imprescindible tener claramente identificados a estos clientes y gestionar sus necesidades y expectativas. Las expectativas de los clientes son las creencias que estos tienen sobre las salidas del proceso (que para ellos serán entradas) y pueden ser muy diversas y no siempre ajustadas a lo que el proceso producirá. Los análisis de variabilidad y control de los procesos así como otras técnicas y herramientas para la medición de los procesos, serán de gran importancia a la hora de cumplir con los requerimientos exigidos y las necesidades de los clientes. Propietario del proceso: Designado por el promotor y que actuará como director de proyecto siendo responsable de la gestión del proceso y de la mejora continua del 55


mismo. Este responsable debe conocer en profundidad el proceso que va a liderar, poseer conocimientos de calidad, six sigma, reingeniería, gestión de procesos y gestión empresarial y estar más centrado en los aspectos de Negocio que en los de TI (Tecnologías de Información). Además debe tener capacidad para la toma de decisiones y para asignar o retirar recursos así como habilidades interpersonales de liderazgo, comunicación y negociación. Promotor del proceso: Será la persona que asignará los recursos necesarios, definirá la misión y objetivos del proceso y realizará el seguimiento y evaluación del mismo.

Actividades: Es la descripción de las acciones y tareas que deberá realizar el proceso para conseguir los resultados y salidas esperadas por el cliente. A través de estas tareas y actividades transformaremos las entradas en salidas del proceso. Las actividades las identificamos, desglosamos en paquetes de trabajo, secuenciamos, estimamos los recursos necesarios para las mismas, estimamos su duración y las controlamos. Recursos: Todos aquellos elementos materiales o de información que el proceso consume o necesita para ejecutar sus actividades y producir la salida del proceso. Alcance y límites del proceso: Definir el alcance del proceso (qué está incluido en el mismo y que no lo está) y garantizar que incluya todo el trabajo requerido para completarlo con éxito y producir los resultados esperados. Esto incluye también definir los límites del proceso, dónde empieza y termina la secuencia de actividades relacionadas con el proceso y definir los límites de entrada y de salida. Indicadores: Los indicadores nos permitirán hacer una medición y seguimiento de cómo opera el proceso y si éste se orienta hacia su cumplimiento y objeti-

56


vos, conocer su evolución y tendencia y de esta forma planificar los valores deseados para el proceso. El establecimiento de indicadores alineados con los objetivos del proyecto nos servirá para medir el rendimiento del proceso, gestionar, controlar y mejorar los mismos y medir el grado de cumplimiento de los objetivos planteados siendo anticipadores de los resultados en las salidas de los procesos y la variabilidad de los mismos. Estos indicadores deben ser claros, fáciles de entender, importantes, medibles, consistentes en el tiempo de ejecución del proceso, fáciles de obtener, objetivos, fiables, comparables, representativos del proceso que miden y deben ser explicados a los miembros del equipo, para que todos entiendan qué medimos y porqué lo medimos. Entre otros tipos, los indicadores pueden ser de eficacia, de eficiencia, que analizará los resultados alcanzados (salidas) en relación a los recursos invertidos (entradas), de percepción de clientes o de adaptabilidad y nos proporcionarán el grado con que el proceso ha contribuido a la consecución de los objetivos estratégicos de la organización. Otro indicador muy frecuente e importante es el de la adaptabilidad del proceso el cual nos dará una medida de la capacidad para el cambio y anticipación al mismo con la que cuenta el proceso. Los indicadores nos permitirán medir las variaciones que se producen en el proceso y comprobar que se encuentran en el rango de tolerancia permitido para los mismos. La medida de la variabilidad será importante en la medida en que repercutirá en las salidas del proceso y en consecuencia en los clientes. Para las medidas de variabilidad y el establecimiento de márgenes de tolerancia se utilizan los gráficos de control y otras herramientas de análisis estadístico que veremos al final de este capítulo. Variables de Control: Las variables de control serán aquellos parámetros sobre los que tenemos capacidad de poder modificar y alterar el funcionamiento o comportamiento del proceso. Una vez documentada toda la información sobre los procesos, podemos realizar la representación gráfica de los mismos, las entradas, salidas y el conjunto de actividades y tareas necesarias para la ejecución del proceso. Esta representación visual del proceso nos ayudará a asignar recursos, secuenciar actividades, identificar hitos y puntos de medida de indicadores, pudiendo realizar simulaciones y suposiciones que nos orienten a la hora de mejorar estos procesos mediante la variación de las variables de control 57


internas y externas del proceso, pudiendo tomar decisiones sobre los parámetros de actuación. Para esta representación se suele usar la metodología IDEF en 5 niveles pero que no analizaremos aquí por ser el objeto de este libro la disciplina BPM, el cual cuenta con su propia notación para la representación de procesos (BPMN). El lector puede consultar en otras fuentes información sobre la metodología IDEF.

Clasificación de los procesos. Tras realizar la identificación y definición de los procesos, realizaremos la clasificación de los mismos. Puesto que no todos los procesos que ejecuta una empresa tienen la misma influencia en los costes o en la satisfacción de los clientes, podemos clasificar los procesos en función del impacto de los mismos sobre la organización en: Procesos Estratégicos, Operativos y de Apoyo: -

-

-

58

Procesos Estratégicos: están orientados a las actividades estratégicas de la empresa para planificar, organizar y controlar los recursos y guiar a las organizaciones para incrementar la calidad de sus servicios. Se realizan para cumplir los objetivos estratégicos de la organización, dar valor a sus clientes, orientación al modelo de negocio y directrices para el resto de procesos. Procesos Operativos: son los más cercanos al cliente y los que finalmente producen valor añadido a los mismos y en consecuencia, serán los de mayor impacto sobre la satisfacción de los clientes al pertenecer a la parte principal del negocio. Procesos de Apoyo: generan los recursos que necesitan los demás procesos, apoyando a los procesos operativos y ayudando en su coordinación.


Otra clasificación que podemos hacer de los procesos y a la que recurriremos en distintas partes del libro es la siguiente: -

-

Centrados en Humanos (human-centric), usados para guiar las actividades desarrolladas por personas (que son los típicos usados por las herramientas de workflow), Centrados en Documentos (document-centric), basados en documentos y su procesamiento, Centrados en Decisiones (decisión-centric), basados en decisiones tomadas por personas.

Cuando veamos el estándar BPMN (Business Process Model Notation), la notación estándar en BPM para modelar procesos de negocio y los BPMS (Business Process Management Systems), los entornos software a través de los cuales modelaremos e implementaremos los procesos, veremos que podremos clasificar nuestros procesos de distintas maneras simultaneando las clasificaciones que acabamos de ver. A la hora de trabajar con BPM y en especial en las fases de modelado, nos centraremos más en que lo procesos estén bien definidos, que estén estandarizados según el tipo de industria en la que estemos desarrollando el proceso y que estos se basen en la cadena de valor. Por ejemplo, la American Productivity and Quality Centre´s Process Classification Framework (APQC) clasifica los procesos en procesos centrales o que añaden valor, como procesos operacionales y el resto de procesos como de gestión y apoyo, siguiendo el modelo de cadena de valor de Porter.

Mejora de procesos: El objetivo de la identificación y clasificación de los procesos que hemos visto, es realizar un mapa de procesos, que será una representación gráfica que refleje con claridad la secuencia de tareas, la información que comparten, la estructura de los procesos y las interacciones más importantes entre ellos, para a través de este mapa, poder trabajar en el análisis y la mejora de los procesos que actualmente opera la organización. El trabajar en la simplificación y mejora de los procesos es algo que las organizaciones siempre han realizado convencidas de que incrementando la eficiencia de estos procesos alcanzarán mejores formas de “hacer las cosas” y una mayor satisfacción de clientes y empleados. 59


Trabajar en la mejora de los procesos significará ejecutar y poner a funcionar los procesos según el diseño establecido para comprobar que este opera según se ha especificado y medir las desviaciones y variaciones que se produzcan de forma que si en la operativa del mismo detectamos variaciones, puntos fuera de control en el gráfico de control, no satisfacciones de clientes, despilfarro de recursos, tiempos fuera de lo establecido o cualquier otra incidencia no deseable para el comportamiento del proceso, podamos adaptar el mismo aplicando mejoras que solventen estos problemas o mejoren los indicadores de rendimiento del proceso. Aunque veremos más adelante dentro de BPM distintas técnicas y herramientas para la mejora de procesos, en este capítulo podemos apuntar como metodología las siguientes etapas indicadas por Kaoru Ishikawa como Método Sistemático para la mejora de procesos, en el que resalta el continuo llamamiento a la medición de los procesos como método científico para la mejora de los mismos y que será una constante tanto en la Gestión de Procesos como en la disciplina de BPM: 1. Identificación y definición del proceso real: detectar lo que desean y necesitan nuestros clientes. Describir el proceso y las medidas que soporta el mismo. 2. Medición y análisis del proceso: analizar las medidas y detectar oportunidades de mejora. 3. Identificar oportunidades de mejora: diseñar el proceso mejorado y medir los resultados para comprobar que se produce la mejora en los resultados. 4. Normalización del proceso: ajustar el proceso y documentar las mejoras. 5. Plan de revisión y mejora continua: diseñar medidas para el seguimiento del proceso y las acciones para la mejora de los resultados. De forma general y antes de proceder con la mejora de los procesos identificados, a la hora de diseñar nuestros procesos, deberemos tener en cuenta los siguientes criterios: -

-

60

Eliminar todas las actividades y tareas que no aporten valor. Buscar los datos asociados con los procesos, pues sin ellos no podremos realizar las mediciones sobre las que basar las mejoras sobre los procesos. Evitar la departamentización de los procesos y verlos de forma horizontal atravesando a toda la organización.


-

Hacer los procesos simples y entendibles. Considerar todos los aspectos internos y externos que puedan afectar a los procesos: medioambientales, técnicos, legales, de negocio, etc.

Para la mejora de procesos existen un sinfín de herramientas y técnicas derivadas principalmente de TQM y Six Sigma. En este capítulo describiremos dos de las metodologías más usadas para la mejora general de procesos: PDCA (Plan-Do-Check-Act; por sus siglas en inglés) y DMIAC derivada de Six Sigma.

Metodologías PDCA y DMIAC: Los resultados de un proceso dependerán no sólo de la correcta identificación y definición de los mismos sino también de la correcta gestión de estos. Para esta gestión podemos utilizar la metodología PDCA (Plan, Do, Check, Act), asociada a casi todos los proyectos de mejora continua y que será como veremos la columna vertebral del ciclo de vida y de implementación de los proyectos de BPM. El método PDCA, también conocido como ciclo de Shewhart, es una metodología de resolución de problemas con un enfoque de ensayo-error muy apropiado cuando abordamos proyectos de mejora continua y de mejora de procesos. El método PDCA consta de las siguientes fases: -

-

-

Planificar (Plan): definir qué, quién y cuándo se van a realizar las actividades. Definir los objetivos del proceso y los datos e información del proceso así como medidas de su rendimiento actual para poder con posterioridad compararlo con las acciones de mejora que llevemos a cabo, identificar stakeholders (interesados), costes, tiempos, recursos necesarios, riesgos, adquisiciones y en general definir el curso de acción necesario para alcanzar los objetivos. Desarrollar (Do): llevar a cabo las actividades y completar el trabajo definido en la fase de planificación. Esta fase implica coordinar personas y recursos y realizar las actividades planificadas. Controlar (Check): analizar los resultados obtenidos mediante el procesado y análisis de los datos obtenidos en las mediciones, comprobar y evaluar las desviaciones y grado de cumplimiento 61


-

de los objetivos con el fin de tomar medidas correctoras o de mejora de la operativa de los procesos. Actuar (Act): ajustar y llevar a cabo acciones de mejora según las mediciones obtenidas en la fase de control, las cuales serán enviadas a la fase de planificación para evaluar el impacto de las mismas sobre el proceso para su aprobación o rechazo.

Otra metodología para la gestión de procesos es DMIAC, propuesta por la metodología Six Sigma y que consta de los siguientes pasos: -

-

-

62

Definir: el cometido del proceso, su representación gráfica y la operativa del proceso para poder evaluarlo antes de su implantación. Medir: obtener información de los indicadores que se hayan definido. Analizar: a partir de la información proporcionada por los indicadores, el comportamiento del proceso y su grado de cumplimiento respecto a los objetivos planteados. Mejorar: los procesos en función de las medidas de rendimiento. Controlar: la ejecución del proceso interviniendo si es necesario para asegurar su eficacia y eficiencia.


Ventajas de la gestión de procesos: El enfoque basado en procesos en las organizaciones es la forma más eficaz de desarrollar acciones que satisfagan a usuarios internos de la organización y a los clientes de la misma, de una forma coherente y estructurada y permitir la mejora continua por medio de la monitorización de los procesos. Pero además, la organización que implemente la gestión de procesos, obtendrá ventajas como: la medición del desempeño organizacional y de la satisfacción de los clientes, la identificación de redundancias y actividades que no aportan valor, dirigir y enfocar la organización a alcanzar una metas y objetivos comunes y orientará a la organización a resultados y no a tareas departamentales. Pero en la implementación de la gestión por procesos, nos encontraremos con que los procesos cruzan los límites organizativos y funcionales de la empresa, transitando por la misma horizontal y verticalmente e interactuando por el camino con otros procesos y recursos necesarios para su operación. Esta evidencia en el comportamiento de los procesos nos obligará a considerar el cambio cultural y de paradigma que representa para la organización el pasar de una organización funcional a una organización orientada a procesos, en la que todos los esfuerzos y cultura corporativa se centrarán en maximizar el valor aportado a los clientes a través del proceso y no los distintos pasos o etapas individuales que atraviesa el proceso en su flujo hacia el cliente. La gestión por procesos y el ver la empresa no ya desde una perspectiva funcional y departamental, sino bajo el prisma de los procesos que la organización ejecuta para producir valor a sus clientes, nos proporcionará numerosos beneficios internos y también nuevos retos para las empresa que la implanten, como será la reducción del protagonismo de los departamentos en pos de una visión más comunicativa y participativa de forma que se coordinarán todos los esfuerzos en la consecución de un objetivo final común, más allá de los intereses particulares de cada departamento y que permitirá simplificar la gestión y agilizar la empresa aumentando su capacidad de adaptación al cambio. Al mismo tiempo, las personas que trabajan en la organización bajo esta orientación a procesos, adquieren un conocimiento mayor de la empresa, al necesitar conocer y comprometerse con los procesos de principio a fin, y no sólo con partes concretas del mismo, lo que requerirá de estas personas mayor interdisciplinaridad, habilidades y conocimientos en la organización orientada a procesos que las requeridas en las organizaciones jerárquicas y funcionales. Además, la gestión por procesos 63


nos permite centrarnos en los clientes y en los procesos que aportan valor a estos, por lo que del rendimiento que obtengamos en la gestión de nuestros procesos obtendremos en consecuencia no sólo mayor satisfacción de nuestros clientes sino también una mayor rentabilidad económica. La estrategia de reducción de costes. Una de las tendencias más comunes al implantar la gestión por procesos es el de usarla para la reducción de costes. La rentabilidad de una empresa la podemos definir como “input/output”, lo que ingresamos dividido entre lo que nos cuesta producirlo y entregarlo a nuestros clientes. Lo normal, y sobre la parte de la ecuación sobre la que normalmente han trabajado las empresas, es trabajar sobre el denominador de esta ecuación, sobre los costes. Pero en este libro, aunque no descartamos ni menospreciamos esta perspectiva, consideraremos también la otra perspectiva, que consideramos como la realmente importante para poder alcanzar ventajas competitivas a largo plazo como es la de incrementar el numerador de la ecuación, o sea, las ventas. Esta tendencia a centrase en el denominador y en la reducción de costes, es la tendencia a centrarse sobre lo que creemos que tenemos control, en la parte que podemos controlar y no sobre el mercado, las ventas, la búsqueda de nuevas fuentes de ventaja competitiva y la innovación, que vemos como incógnita sobre la que tenemos poco control, pero sin las cuales ninguna empresa existiría. Este es el caso de las empresas perfectamente organizadas, estructuradas y dónde todo está perfectamente controlado y gestionado para que no se escape ni un solo céntimo, pero que luego, al no actuar sobre los mercados con productos y soluciones innovadoras y competitivas, acaban perdiendo cuota de mercado e ingresos, por lo que ese modelo de control se viene abajo por su propio peso. Estas estrategias de reducción de costes, pueden producir resultados positivos a corto plazo, pero con ellas, tenemos un límite por debajo del cual no podremos reducir más y a largo plazo, presentarán poco margen de mejora y se convertirán en estrategias de supervivencia y no de crecimiento, por lo que la mejora de procesos, no debe ser usada sólo y exclusivamente para implementar estrategias de reducción de costes, pues estos representan sólo una parte de la ecuación, importante, sin duda alguna, pero no lo suficientemente seguras y valiosas como para centrarnos y poner todos nuestros esfuerzos en sólo esta faceta y descartar las oportunidades que en la mejora de procesos se nos presentarán para 64


proporcionar mayor valor a nuestros clientes, innovar y afrontar nuevos mercados y modelos de negocio. En las estrategias de reducción de costes, siempre haremos cosas que no beneficiarán a nuestros clientes y que de alguna manera siempre tendrán efectos negativos sobre estos. Este es el motivo por el que estas estrategias están siendo cada vez más cuestionadas y vistas no ya como estrategias, sino como tácticas de supervivencia. Vivimos en un mundo sistémico en el que las decisiones que tomamos no sólo nos afectan internamente sino también al entorno que nos rodea. Las políticas de reducción de costes, si bien producen en primera instancia un aumento de los beneficios, estas deterioran la calidad y en consecuencia se reducirán las ventas, lo que implicará una reducción de ingresos y de beneficios, al tiempo que incrementarán la ineficiencia de nuestras operaciones, que redundará en un aumento de costes. Es el flujo mostrado en el siguiente gráfico, el cual deberemos valorar a la hora de tomar decisiones sobre la aplicación de este tipo de estrategias.

Por el contrario, en las estrategias de crecimiento, innovación y desarrollo, se marcará la diferencia en la rentabilidad que las empresas obtienen a través de la correcta e innovadora manera que tengan éstas de gestionar sus procesos y producir salidas de los mismos que aporten valor y ventajas competitivas duraderas. Bajo esta consideración, asumimos que diseñando y gestionado las transformaciones y secuencias de actividades en nuestros procesos, seremos capaces de producir salidas de valor, dado que las entradas, en un mundo globalizado como el actual, están al alcance y son prácticamente las mismas para todos. Como veremos al estudiar la cadena de valor de Porter, el Valor y no el Coste, deberá ser lo que usemos al diseñar nuestra estrategia y analizar nuestra posición competitiva en el mercado y de la elección que hagamos a la hora de gestionar nuestra empresa 65


(trabajar sobre el numerador o el denominador de la ecuación, la reducción de costes o la diferenciación), dependerá el modelo y el estilo de gestión con el que gestionaremos nuestra empresa. El propio Deming, padre del concepto de Calidad Total, nos advertía que: “los costos no son la causa, son la consecuencia de una forma de hacer”. El centrar la visión en los balances y cuentas de resultados, o sea sobre los efectos de nuestra gestión y no sobre las causas que producen estos resultados económicos, se demuestra cada vez más como un error, cuya subsanación pasa por entender como todos los recursos de la empresa se interrelacionan entre sí en una visión sistémica y orientada a procesos.

Técnicas y Herramientas de análisis de procesos. Antes de avanzar en la gestión por procesos y en BPM, daremos un repaso a las diferentes técnicas y herramientas estadísticas utilizadas para el control y monitorización de procesos, de forma que el lector tenga presente la existencia de las mismas y de sus capacidades a la hora de evaluar y monitorizar los procesos. Estas herramientas nos permitirán obtener datos e información sobre los procesos, identificar problemas en los mismos, determinar las causas que generan estos problemas y el impacto que la modificación o mejora de estos pueda tener. Aunque no pretendemos profundizar en las distintas técnicas y herramientas para control de procesos, sí queremos que el lector no familiarizado con el uso de éstas, tenga una idea de las más utilizadas, para que sepamos en qué entorno nos moveremos y qué fundamentos estadísticos estarán detrás de muchas de las soluciones que utilizamos cuando analizamos y monitorizamos el rendimiento de los procesos en un BPMS (Business Process Management System). Estos BPMS, son el software que emplearemos para el diseño, gestión y monitorización de nuestros procesos en BPM, en los cuales, haciendo uso de muchas de las técnicas y herramientas que analizaremos y partiendo de medidas y cálculos estadísticos, haremos uso de las herramientas de generación de indicadores, medición de resultados y rendimientos de los procesos para evaluar y diagnosticar los mismos, y obtener datos e información confiable que nos permita identificar los problemas, los cuellos de botella y las causas que los generan. Gran parte de estas técnicas y herramientas de análisis estadístico para el control de procesos, surgieron en los años 60 con el incremento de la 66


capacidad tecnológica y especialmente en los años 70 y 80 con el uso de los ordenadores y el desarrollo en Japón de los métodos de calidad, el “Just in Time” y el cambio de paradigma hacia la orientación a procesos con la consiguiente necesidad de medir y evaluar los mismos. El origen de prácticamente todas las técnicas y herramientas que veremos se encuentran en los entornos industriales de producción y en el control estadístico de procesos. Estos sistemas de control se basan en sistemas de retroalimentación de información cuyo foco es la recogida y análisis de la información sobre el proceso para poder mejorar el mismo. En estos sistemas de control, mediremos parámetros de una muestra de la salida generada por el proceso y sobre estas medidas, realizaremos los ajustes sobre el mismo para corregir el proceso y evitar que estos errores vuelvan a producirse. Existe también el control adaptativo de procesos, que veremos la final de este libro, basado en el análisis de series temporales y utilizado para predecir futuros valores en las variables del proceso y ajustar el mismo antes de que estas variables se encuentren fuera de control. El lector encontrará suficientes tratados y manuales sobre estas herramientas en fuentes de internet y libros específicos sobre la materia y en especial en aquellos dedicados a Six Sigma. Aunque existen un gran número de técnicas, en este capítulo daremos un repaso a las principales técnicas y herramientas para la medida y análisis de procesos. Según Ishikawa, otro de los padres de la Calidad Total (TQM), con el uso de un grupo de sencillas herramientas podemos resolver el 80% de los procesos de una organización. Ishikawa identifico siete herramientas básicas: -

Diagrama de Pareto Diagrama Causa-Efecto Histograma Hoja de datos Gráfico de control Diagrama de dispersión Estratificación

A las que posteriormente se añadieron otras herramientas como: -

Diagrama de flujo Tormenta de ideas (o Brainstorming) Diagrama de Gantt, de afinidad, de árbol, matricial, etc.

Las técnicas y herramientas vistas en este apartado serán utilizadas en distintas fases de nuestros proyectos BPM, algunas en fase de levantamien67


to y diseño de procesos (como el brainstorming o diagramas de Ishikawa) y otras bajo el uso de herramientas software de análisis de datos dentro de los BPMS y más concretamente en las herramientas de que estos disponen de Business Analisys (BA). A la hora de analizar nuestros procesos, y aunque al final será el equipo de dirección de proyecto el que decida que técnicas y herramientas serán más apropiadas en cada caso, en una primera etapa es aconsejable utilizar técnicas como el Brainstorming, el diagrama de procesos, de afinidades, interrelaciones o el de causa y efecto, con las que podremos abordar los problemas mediante una aproximación consensuada con los participantes en el proceso e identificar desviaciones o problemas que pueden resultar obvios y/o necesiten de análisis numéricos y estadísticos.

Brainstorming: También llamada lluvia o tormenta de ideas, es una técnica utilizada para generar un gran número de ideas de forma rápida con el objetivo de identificar, comprender y dimensionar los problemas así como determinar sus causas y posibles soluciones. El brainstorming se realiza en dos etapas, en la primera se desarrollan las ideas y en la segunda se mejoran las mismas. Esta técnica, utilizada para generar ideas sobre un tema y obtener información sobre ese tema o proceso, se realiza tomando las ideas del personal que está más familiarizado con la operativa del proceso que tratamos, promoviendo la participación y generando entusiasmo al hacer partícipe al personal en la identificación de problemas, las áreas de mejora, la resolución de problemas o el diseño de los procesos y planes de acción. El brainstorming se basa en la generación de ideas en un ambiente de trabajo en grupo en el que no se permite la crítica. El objetivo es que los comentarios de otras personas actúen como estímulos de las propias ideas. Todas las ideas son bienvenidas, pues no se busca la crítica de estas ni su evaluación durante el proceso de brainstorming, sino el generar el mayor número de ideas posibles hasta que estas se agoten. Es importante que en estas sesiones haya un responsable principal del proceso así como otra persona que dirija y coordine estas sesiones. El que dirige la sesión formula el problema y estimula los comentarios del resto del grupo en busca de la generación de ideas. El brainstorming los podemos realizar de dos formas: 68


-

-

Estructurado: en este método, cada persona del grupo debe dar alguna idea cuando le toca el turno de participar. Este sistema fuerza a participar a personas tímidas, pero a su vez crea cierta presión a contribuir. Desestructurado: donde los miembros del grupo aportan ideas tan pronto como les vienen a la cabeza, creando una atmosfera más relajada pero donde corremos el riesgo de que participen sólo los más extrovertidos.

Benchmarking: El Benchmarking nos proporcionará información sobre las actividades en otras áreas o sectores iguales o similares a los que opera nuestra organización y nos permitirá identificar, comparar, comprender, evaluar lo que estamos haciendo y nuestras capacidades con respecto a los de la competencia, de forma que podamos adaptar las mejores prácticas y procesos que sabemos que funcionan en otras organizaciones. El Benchmarking es muy recomendable hacerlo siempre que vayamos a trabajar en la mejora de nuestros procesos, pues constituye una excelente fuente de ideas y aprendizaje. Existen tres tipos de benchmarking para comparar y medir continuamente a una organización y tomar las medidas necesarias para mejorar sus procesos: -

Benchmarking interno, basado en el análisis y comparación de procesos similares dentro de la organización. Benchmarking competitivo, basado en la comparación de nuestros procesos con los de otras organizaciones similares. Benchmarking de líderes, en el que comparamos nuestros procesos con los de las organizaciones líderes que han alcanzado altos niveles de excelencia.

Histograma: El histograma es un gráfico que vuelve visible la dispersión de datos de un proceso y nos ayuda a definir posibles acciones requeridas para su control. Los histogramas sumarizan en un gráfico de barras verticales la distribución de los datos en busca de datos atípicos o distribuciones anormales no esperadas en el comportamiento de los procesos. 69


Diagrama de Pareto: También llamado curva 80-20, estos diagramas son utilizados para representar la contribución relativa de cada causa o componente al problema que estudiemos por lo que esta técnica puede ser usada para analizar las ideas surgidas en las sesiones de brainstorming e identificar los principales problemas que causan el mayor impacto en nuestros problemas. Los diagramas de Pareto son histogramas cuyas frecuencias se encuentran en orden descendente de izquierda a derecha y que contienen en el mismo gráfico de barras una curva de frecuencias acumuladas en porcentuales.

El gráfico de Pareto es un tipo de histograma que se construye dividiendo el alcance de los datos en grupos. El eje vertical es el porcentaje acumulativo y el horizontal son las variables de respuesta de los grupos. La gráfica de Pareto nos permite asignar un orden de prioridades para la toma de decisiones dentro de una organización y está relacionada con la ley de Pare70


to que establece que un número relativamente pequeño de causas provoca la gran mayoría de los problemas o defectos, conocido este principio como el de 80/20, donde el 80 por ciento de los problemas son debidos al 20 por ciento de las causas, lo que significa que hay unas pocas variables vitales y muchas triviales. Esta regla del 80/20 es usada para conseguir grandes mejoras, identificando las mayores causas de problemas, de forma que podamos dirigir nuestra atención y esfuerzos a los problemas realmente importantes. Al realizar el análisis de Pareto debemos tener en cuenta que hay variables que no pueden ser controlables (el tiempo, la inflación, etc.) que aunque puedan repercutir en el resultado no deben formar parte del análisis por no ser controlables. Para elaborar un Diagrama de Pareto podemos seguir los siguientes pasos: 1. Identificar las causas que están provocando un problema o defecto. 2. Seleccionar el número de veces que ocurre el problema, número de defectos, número de rechazos, etc. 3. Seleccionar un rango de tiempo a ser estudiado. 4. Ordenar las causas de mayor a menor frecuencia o importancia y calcular el porcentaje que representa sobre el total. 5. Construir el gráfico de barras y la curva acumulada.

Diagramas de Causa-Efecto: También conocidos como diagramas de Ishikawa o de espina de pescado, son usados para ilustrar como diferentes factores pueden estar vinculados con un problema o defecto potencial. Estos diagramas se utilizan para representar la relación entre algún efecto y todas las posibles causas que lo influyen. Para su construcción se sitúa el efecto o problema en el lado derecho del diagrama y las influencias o causas a su izquierda, trazando una línea horizontal a la cual, y como “espinas de pez”, van llegando líneas oblicuas que representan las causas valoradas como tales por las personas que participan en el análisis del problema en cuestión. Estas líneas de posibles causas pueden a su vez recibir otras líneas de causa o causas secundarias.

71


Esta técnica permite un análisis participativo en grupos de mejora o grupos de análisis, que reunidos pueden abordar la resolución de un problema y de las causas que lo originan.

Diagramas de Control: Basados en la recopilación y análisis de datos para indicar el estado de calidad de los procesos, el modo en que estos se comportan a lo largo del tiempo y las posibles variaciones que estos procesos puedan tener. Los gráficos de control se usan para medir si el proceso se encuentra dentro de los límites deseados, en cuyo caso decimos que están bajo control. Aunque su aplicación es muy frecuente en procesos industriales, estos gráficos nos servirán para otros muchos tipos de procesos. Los diagramas o gráficos de control, son una herramienta fundamental en el control de procesos para vigilar la variación de los mismos, controlar y mejorar su rendimiento. Su objetivo es medir variables de salida de los procesos, para comprobar que estos están funcionando consistentemente, para ello buscamos puntos fuera de control, valores fluctuantes, saltos repentinos o tendencias que puedan ser causa de desviación de los valores esperados para el proceso. En los diagramas de control, se establecen unos límites superiores e inferiores de la especificación y límites superior e inferior de control. Cuando las medidas están dentro de estos límites, se dice que el proceso está bajo control y si las medidas quedan fuera de estos límites, el proceso deberá ser ajustado. Se establece la regla que dice que si un punto excede un límite de control o si tenemos siete puntos consecutivos por encima o por debajo de la media, el proceso está fuera de control. 72


Donde los círculos nos indican: -

Un punto fuera de control (en el círculo pequeño). 7 puntos fuera de la media (en el círculo grande). Es la Regla del 7, según la cual, 7 puntos o más cerca de los límites de control, exige una revisión de los mismos.

Los diagramas de control recopilan y analizan los datos monitorizando las salidas del proceso para evaluar en qué medida las salidas del proceso se ajustan a los requerimientos de calidad. Estos diagramas representan el comportamiento de un proceso a lo largo del tiempo y cuando un proceso tiene puntos fuera de control, saltos repentinos o una tendencia hacia la variación. Estas medidas pueden ser utilizadas para la toma de decisiones en el análisis y diseño de procesos, evaluar o comparar procesos, corregir variaciones en los procesos que puedan afectar a la calidad, reducir deshechos, etc. Cuando un proceso está dentro de los límites aceptables, se dice que está bajo control y no requiere de ajustes. Por otra parte, si tenemos puntos por encima o por debajo de los límites de control o una sucesión de puntos consecutivos fuera de los límites, entonces el proceso debe ser ajustado. Ϭ siendo 1Ϭ una Normalmente los límites superior e inferior se fijan en desviación estándar. Además de los diagramas de control, existen también los diagramas de comportamiento, que son como los diagramas de Control, pero sin establecer límites al proceso, de forma que sólo se muestran los puntos de datos medidos para mostrar tendencias o variaciones en los procesos.

73


Diagramas de Dispersión: Son una representación gráfica de los datos recogidos sobre dos variables para poder estudiar si existe relación de causa efecto entre ellas y muestran la tendencia entre estas dos variables para identificar la posible relación entre ambas.

Matriz de Valor Agregado: Permite analizar cada una de las actividades del proceso a partir de dos dimensiones: -

Agrega valor al proceso. Es o No es necesaria para el proceso.

Las combinaciones de estas dos dimensiones son: -

Sí agrega valor y Sí es necesaria. No agrega valor pero Sí es necesaria. Sí agrega valor pero No es necesaria. No agrega valor y No es necesaria.

Y utilizamos la siguiente tabla para determinar si una actividad agrega o no valor al proceso y que hacer en cada caso.

74


Diagramas de Flujo: Muy utilizados en las fases de análisis y levantamiento de procesos para compartir con distintos usuarios involucrados en el proceso, dibujar conjuntamente el flujo de éste y poder visualizar mejoras o defectos sobre los procesos de forma gráfica.

Los diagramas de flujo representan las relaciones entre las etapas de un proceso donde lo importante es mostrar los puntos de decisión (mediante rombos), las actividades (cuadrados) y la secuencia de estos, ayudándonos a anticipar problemas que puedan ocurrir en los procesos.

75


76

Capítulo 2. Los caminos hacia BPM

Capítulo 2. Los caminos hacia BPM.

El cómo se ha llegado hasta BPM es fruto de un largo recorrido tanto en disciplinas de gestión y organización de empresas, como tecnológicas, de desarrollo de estándares y de metodologías, donde la columna vertebral de esta evolución, o el ADN que la ha dirigido, ha sido la innovación y la focalización en el cliente. Haciendo una comparación con la teoría de la evolución de Darwin, si ésta ha sido dirigida por la selección natural, la evolución en las teorías de gestión que han llevado al desarrollo de BPM ha sido dirigida principalmente por la orientación a un cliente cada vez más valioso pero también más exigente. Howarth Simth y Peter Fingar en su importante libro “Business Process Management: The Third Wave”, describen el camino hasta llegar a BPM como el resultado de tres olas: -

-

Primera Ola: que comenzó en la primera parte del siglo XX y centrada en la búsqueda de eficiencia en las operaciones del día a día. Los trabajos de Frederick Taylor y de Henry Ford en las líneas de montaje con la especialización del trabajo. Segunda Ola: con la paquetización de las aplicaciones de software empresarial (ERP, CRM, SCM, HR, etc.) y la utilización de los procesos de negocio en estas aplicaciones. 77


-

Tercer Ola: con la integración de los esfuerzos anteriores y la creación del BPM como visión holística para la comprensión y gestión del comportamiento y operativa de las empresas para ganar en eficiencia y competitividad. Pasando en esta tercera ola de la visión centrada en los datos y funcional de las organizaciones, a la visión de esta tercera ola centrada en los procesos de negocio y en la organización orientada a procesos.

Orígenes de la gestión empresarial: Como hemos visto en el capítulo anterior, la gestión por procesos es algo que consciente o inconscientemente todos hacemos en nuestras organizaciones y la idea de tomar el control de las actividades empresariales a través de los procesos que ésta ejecuta para alcanzar sus objetivos, no es nueva y muchos aspectos del actual BPM comenzaron a gestarse ya en el siglo XVIII con el famoso economista Adam Smith (1723-1790) y su teoría de la especialización del trabajo. Posteriormente, Frederick Taylor (1856-1915) introdujo los principios iníciales de los métodos de gestión científicos y Henry Ford (1863-1947), la idea de la cadena de montaje para la producción en masa. Alrededor del año 1950, los ordenadores comenzaron a influenciar sobre los procesos de negocio, lo que resultó en un gran cambio en la organización del trabajo que facilitó nuevas formas de hacer negocios pero también, una mayor dependencia de los sistemas informáticos y la tecnología por la creciente complejidad de los nuevos modelos de negocio que iban surgiendo. Con el avance de las teorías de gestión, los procesos iban al mismo tiempo adquiriendo mayor relevancia como disciplina a través de la cual gestionar la complejidad de las organizaciones y su entorno cada vez más cambiante. Al principio, las primeras aproximaciones a BPM fueron muy simples y estaban centradas básicamente en la mejora de procesos productivos y de manufactura, hasta que en los años 90, se produjo un salto importante de acercamiento a BPM con la aparición de BPR (Business Process Reenginering) y su búsqueda de la reducción de tiempos, costes y la eliminación de las tareas que no aportaban valor al cliente. Pero los problemas en la implementación de BPR, por su falta de visión global, alejamiento de las personas y la dificultad de trasladar los requerimientos de negocio a especificaciones de TI (Tecnologías de la Información), contribuyeron a ace78


lerar el camino hacia una aproximación más holística y conjugadora de BPR con otras teorías de gestión que finalmente conducirían a BPM. Adam Smith. La teoría de Adam Smith es la teoría de la especialización del trabajo a través de la definición de puestos y tareas desempeñados por diferentes personas. Adam Smith, entendió que la producción en masa requería de nuevos métodos de organización del trabajo. En su libro “The Wealth of Nations” (1776), Smith reconocía que la división del trabajo era esencial para incrementar la productividad de los trabajadores. Sus teorías se gestaron mientras observaba a los trabajadores en una fábrica de alfileres en Francia. Smith observo que si en lugar de que un trabajador hiciera todos los alfileres, dividía el trabajo, especializando a los trabajadores en diferentes tareas específicas del proceso de producción, conseguía mejoras en la producción, debido principalmente a la mayor destreza de los trabajadores en sus tareas y obteniendo como resultado de ese cambio producir 240 alfileres más en el mismo tiempo y con el mismo número de trabajadores. Adam Smith fue uno de los primeros en describir los procesos señalando los métodos de producción, los objetivos y medidas en los procesos. Sus teorías transformaron completamente los métodos productivos creando una auténtica revolución en la reorganización de empresas e industrias que todavía sobrevive después de más 200 años.

Frederick Taylor. La siguiente gran revolución en las teorías de gestión fue la de Frederick Taylor. Taylor expandió la idea de la especialización del trabajo de Smith con la introducción de métodos científicos para la medida de los procesos productivos y de manufactura. En su libro “The Principles of Scientific Managament” (1911), Taylor comentó la necesidad de las empresas de eliminar ineficiencias de producción y mejorar la división del trabajo, proponiendo técnicas y herramientas de gestión científicas para distintos aspectos de la gestión empresarial: estandarización de procesos y tiempos productivos, estandarización de materiales, equipamientos y métodos de trabajo, métodos para seleccionar a los mejores trabajadores para cada tarea, proporcionarles la formación necesaria y el entrenamiento específico para los distintos perfiles de trabajadores, de forma que estos ejecuten las tareas repetitivas que cada uno tiene que realizar en el proceso de la forma más eficien79


te y proponiendo el alineamiento del salario de los trabajadores a sus niveles de producción. Taylor abogaba por la simplificación de los procesos, por la experimentación e investigación sobre estos y por la toma de medidas para su evaluación en la búsqueda del mejor camino para ejecutar los negocios, centrándose en las tareas de manufactura y en el uso de herramientas estadísticas para evaluar estas tareas con objeto de maximizar los beneficios, mejorar la eficiencia y minimizar los costes. Al igual que las ideas de Adam Smith, las propuestas de Taylor fueron abordadas por prácticamente todas las empresas del mundo y sus ideas todavía se siguen utilizando. Sin embargo, la realidad hoy, es que las teorías de Smith y Taylor fueron muy útiles en el siglo XIX, donde los productos necesitaban pocos pasos para ser elaborados, pero usar las teorías de Smith y Taylor en las empresas modernas ha resultado ser ineficiente, principalmente por la interrelación entre los distintos pasos para elaborar un producto o servicio al cliente. Actualmente los trabajadores necesitan de un conocimiento global de los distintos pasos, mayores habilidades y competencias y donde la información sobre la totalidad del proceso resulta vital para poder atender las demandas de producción y servicio al cliente.

Henry Ford. Henry Ford encontró distintos usos para las teorías de Taylor. Cuando fundó Ford Motor Company en 1913, Ford se propuso llevar el automóvil a las masas ofreciendo un coche competitivo y asequible. Para lograr este objetivo, ofreció un sólo modelo de coche para todos los clientes, el Modelo T “de color negro”, igual para todos. Esta idea junto con la adopción de la cadena de montaje en la que se movía el coche en lugar de moverse los trabajadores, el diseño de un proceso (una secuencia de actividades) que le permitía fabricar coches más rápidamente y a precios asequibles, revolucionó el sector del automóvil, permitiendo fabricar grandes cantidades de automóviles que rápidamente se popularizaron y le permitieron llegar a un gran mercado de masas.

80


Teorías Modernas de Gestión de Procesos. Las ideas de Adam Smith y la especialización del trabajo, de Henry Ford y la cadena de montaje, y de Frederick Taylor con sus métodos científicos de producción, fueron exitosas en la era industrial, dominada por los monopolios de mercado y la producción en masa, en la que los clientes no tenían acceso a la información de otros productos y servicios existentes en el mercado y la competencia apenas existía. Estos modelos productivos fueron exitosos en su época pero no resultan eficientes para las empresas de hoy en día donde superada la era industrial, nos enfrentamos a nuevos retos de mercados mucho más competitivos en los que los clientes son cada vez más exigentes y demandan mayores niveles de calidad e innovación. Los nuevos mercados requieren de organizaciones más flexibles y rápidas en adaptarse a las exigencias constantes del mercado, la competencia y los clientes. Después de la Segunda Guerra Mundial, los Estados Unidos de América, con el Plan Marshall, lograron convertirse en la primera economía mundial, proveyendo de productos y servicios a una Europa devastada por la guerra. Se fabricaba y vendía de todo y en grandes cantidades, por lo que apenas había requerimientos de calidad. Pero este período de crecimiento en los Estados Unidos, terminó con la crisis de los años 70, el entorno económico cambió, y la competencia se incrementó principalmente por parte de empresas japonesas y alemanas. La economía mundial estaba en crecimiento y el número de personas con poder adquisitivo aumentó extraordinariamente, por lo que los consumidores comenzaron a demandar productos y servicios cada vez más innovadores y de mayor calidad. Los consumidores ya no estaban satisfechos con lo que les vendían las empresas (la idea del coche Modelo T de color negro para todos, de Henry Ford, ya no era válida para estos nuevos clientes). Esta nueva situación produjo cambios en la forma en que las empresas operaban hasta entonces, pues requería de la orientación a un cliente que demanda cada vez mayores niveles de servicio, atención, tiempos de entrega más cortos y productos de alta calidad que satisfagan sus necesidades y experiencias de compra. Es en este nuevo entorno donde se produjo el giro de las empresas hacia un replanteamiento de sus organizaciones y procesos de negocio para hacer frente a estas exigencias en un camino que todavía hoy no ha finalizado. En este camino del desarrollo empresarial que siguió a la segunda guerra mundial, aparecen teorías como la de Peter Drucker en 1954, sobre los 81


trabajadores del conocimiento, en contraste a los trabajadores especializados de Taylor y sus teorías sobre la dirección por objetivos. Se desarrollan los conceptos de gestión de la calidad de William Edwards Deming, que más que centrarse en el enfoque productivo, se centraban en el aprovechamiento y mejora de la calidad. En 1985 Michael E. Porter introdujo por primera vez el concepto de cadena de valor, mediante el cual se descompone la empresa en sus partes constitutivas, buscando identificar fuentes de ventaja competitiva en aquellas actividades que generan valor y las cuales se consiguen cuando la empresa desarrolla e integra las actividades de su cadena de valor de forma menos costosa y más diferenciada que sus rivales. Otra persona, cuyos estudios aportaron importantes teorías sobre cómo organizar las empresas, diseñar los procesos y los puestos de trabajo y avalaron fuertemente la orientación a procesos fue Geary Rummler en los años 80. Rummler era un psicólogo que investigaba sobre temas de mejora de las capacidades de las personas en las empresas, llevando sus conclusiones hacia la necesidad de ver las organizaciones como sistemas y la necesaria orientación a procesos para evitar los problemas que surgen en las organizaciones funcionales. Las teorías de Rummler y en especial la de la organización de la empresa entorno a procesos, fueron la primera aproximación hacia la revolucionaria propuesta de Michael Hammer y James Champy de la reingeniería de procesos o BPR (Business Process Reenginering), aparecida en los años 90. Según Hammer y Champy, la reingeniería es: “la revisión fundamental y el rediseño radical de procesos para alcanzar mejoras espectaculares en medidas críticas y contemporáneas de rendimiento, tales como costos, calidad, servicio y rapidez”. La reingeniería surge como herramienta para la mejora de procesos partiendo de un cambio radical en los mismos. Esta teoría fue la precursora en señalar la necesidad de la tecnología y de las TI en particular, para la mejora de los procesos, la automatización de los mismos y el aumento de la productividad. Hoy en día a nadie escapa esta necesidad de las TI para la competitividad de todo tipo de negocios, en especial con el avance de internet y el surgimiento de nuevos modelos de negocios surgidos a través de esta tecnología, pero en el momento en que apareció la reingeniería, las TI no estaban tan evolucionadas como hoy en día y sus posibilidades en consecuencia eran mucho menores. La reingeniería, sin embargo, junto con la cadena de valor de Porter, sentaron las primeras bases de la necesidad de

82


una visión holística de los procesos para la obtención de ventajas competitivas. Otro personaje importante en recalcar la necesidad de las TI para hacer frente a este nuevo entorno es Tomas H. Davenport, el cual demostró el importante papel e importancia que las Tecnologías de la Información ofrecen como facilitadoras y conductoras de la innovación, la reingeniería de procesos y la mejora continua.

TQM (Total Quality Management). Total Quality Management (TQM) ha sido una de las principales teorías que ayudaron a las empresas a competir en este nuevo mercado orientado a los clientes. Propuesta por William Demming en1940, TQM desarrolló los métodos de control de calidad haciendo uso de las teorías de control estadístico e identificando la gestión por procesos como uno de los métodos de gestión fundamentales. Demming no pudo convencer a los americanos sobre la importancia de sus teorías de gestión de la calidad, por lo que se fue a Japón como asesor de un grupo de americanos para ayudar a levantar el país nipón tras la segunda guerra mundial y fue en este país, donde Demming consiguió implementar sus métodos, consiguiendo que en los años 70, las empresas japonesas comenzaran a obtener muy buenos resultados, por lo que recabo el interés de las empresas americanas que comenzaron a prestar atención a sus métodos y prácticas relacionadas con la Gestión de la Calidad Total (en inglés, TQM: Total Quality Management), relacionadas entre otras con la importancia de la dirección general, el foco en el cliente, los círculos de calidad, la mejora continua, las aproximaciones bottom-up y el compromiso de todos los miembros de la organización en la mejora de la calidad, los procesos y productos ofrecidos a clientes. Los principios fundamentales sobre los que se asienta TQM son: -

Foco en los procesos de trabajo. Analizar la variabilidad: las variaciones incontroladas son la primera causa de problemas de calidad y deben ser controladas por los trabajadores en primera línea.

83


-

-

-

-

-

-

“Management by fact”: los sistemas de calidad deben estar basados en datos reales y recogidos sistemáticamente. Aprendizaje y mejora continua: el entrenamiento de los trabajadores es una de las bases de la mejora de la calidad y de la mejora continua. Satisfacción del cliente: el principio más importante en TQM. Mejora continua: esencial para el sostenimiento de la empresa de forma que la empresa esté constantemente mejorando su calidad, productividad y eficiencia. El coste de una baja calidad es mucho mayor que el de su implementación. La dirección general es la que tiene la responsabilidad de la gestión de la calidad y su compromiso es crucial para el éxito de implementar políticas de calidad en la empresa. Empleo de métodos científicos para monitorizar la calidad e identificar áreas de mejora. (Pareto: usado para determinar los pocos factores que contribuyen de forma significativa a los problemas de calidad, diagramas de flujo, brainstorming, diagramas causa-efecto, benchmarking, método Delphi, etc.) Crear un entorno donde no exista el miedo al error o la vergüenza. Eliminar las recompensas a los trabajadores (en TQM estas se ven como denigrantes para el trabajador). Sin requerimientos de clientes (internos o externos), es muy difícil alcanzar los requisitos de calidad que estos requieren. Elección de proveedores en función de su calidad y no de su precio. Deben existir equipos en la empresa que atraviesen todos los departamentos en busca de mejoras de calidad de toda la organización, según Demming muchos de los problemas de las empresas están en estos cross-boundaries, y es en estos donde se generan los principales problemas de los clientes.

Un principio fundamental de TQM es el papel de los clientes como árbitros de la calidad. La calidad total busca la satisfacción de los clientes y mediante ésta su fidelización. Como consecuencia, el diseño de los productos y servicios, su fabricación, sistema de entrega a los clientes y servicios de atención a los mismos, han de ser considerados de máxima importancia y cuidados en extremo. Pero puesto que las necesidades de los clientes cambian cada vez con mayor frecuencia, por la presión entre otras de la competencia, los procesos con los que proveemos de esta calidad deben ser constantemente modificados para adaptarse a los nuevos requisitos. Kaoru Ishikawa, uno de los mentores de la calidad total, ideo un “Método sistemáti84


co de mejora de procesos” basado en su famoso diagrama de “espina de pez” o diagrama de Ishikawa, en busca de las causas posibles de defectos para su posterior perfeccionamiento y con el cual numerosas empresas han conseguido mejorar sus resultados. El esquema de este método es el mostrado en el siguiente gráfico:

Six Sigma. Six Sigma es una metodología para la identificación y eliminación de defectos en procesos de manufactura y procesos de negocio, cuyo objetivo es obtener un 99,99966% de salidas del proceso sin defectos. Esta disciplina también es utilizada para la mejora de procesos, a través de la reducción de la variabilidad de los mismos, consiguiendo reducir o eliminar los defectos en la entrega de un producto o servicio al cliente. Six Sigma fue desarrollada por Motorola en los 80 mientras introducían TQM, a veces es llamada como “TQM con esteroides” y se convirtió en una muy popular teoría de management cuando fue adoptada por Jack Welch 85


en General Electric. Six Sigma es una metodología para la resolución de problemas basada en técnicas estadísticas y en este sentido puede ser vista como una evolución de TQM. Aunque las teorías para la mejora de las operaciones comenzaron ya con Frederick Taylor, el cual estaba obsesionado con las medidas de todos los pasos del proceso productivo y con experimentar nuevas formas de llevar a cabo estos procesos, estas teorías continuaron evolucionando principalmente tras el éxito en Japón de las teorías de calidad de Demming y sus prácticas de control y aseguramiento de la calidad, las cuales se extendieron a todas las organizaciones, desarrollándose iniciativas de control de calidad como el Control Estadístico de Procesos (SPC: Statistical Process Control), TQM y Just-in-Time (JIT). Six Sigma, aunque es una metodología basada en el control de calidad, se nos presenta actualmente como la más completa y más moderna de las metodologías anteriores y ha evolucionado no sólo hacia el control de calidad, sino también hacia la mejora de procesos. Six Sigma es muy buena en identificar defectos y buscando soluciones para mejorar los procesos. Su fuerte es analizar muchos factores que puedan influir en un defecto o problema, buscando el factor exacto que lo produce y encontrando la solución y es por ello que se integra perfectamente con BPM, resultando en una combinación perfecta usando por ejemplo Six Sigma para la mejora de procesos que luego serán automatizados y gestionados en BPM y utilizando el potencial de las herramientas de medición de Six Sigma, para determinar medidas e indicadores de los procesos. Además BPM se alinea perfectamente con Six Sigma adquiriendo conjuntamente un gran potencial, al agilizar las herramientas de BPMS una de las tareas más tediosa y difícil de Six Sigma como es la recolección de datos y donde las plataformas de BPMS disponen de potentes soluciones para la realización de esta tarea. Como vemos, la premisa principal para Six sigma es el uso del análisis riguroso de datos en busca de las fuentes de error que provocan variaciones en los procesos. La metodología más empleada por Six Sigma es DMAIC, por sus siglas en inglés de Define, Measure, Analyze, Improve y Control: -

86

Define: Definir los requerimientos de clientes para el proceso. Qué debemos conseguir con el proyecto, el alcance del mismo y los objetivos a alcanzar, para lo que deberemos entender el proceso sobre el que trabajaremos y las mejoras que se esperan del mismo, poniendo especial énfasis en como satisfacer los re-


-

-

-

-

querimientos de los clientes. En esta fase el equipo de mejora de procesos llega a acuerdos sobre en qué área centrarse, sobre los problemas existentes y como los actuales procesos y sus salidas fallan en satisfacer las necesidades de los clientes. Measure: Medir los resultados existentes y compararlos con los requerimientos de clientes. Las medidas establecidas nos deberán permitir conocer en qué medida satisfacemos los requerimientos de los clientes. El objetivo principal de esta fase es identificar la localización o el origen de los problemas, para lo que debe entender todo el proceso y las distintas condiciones en las que opera, de forma que acote los problemas para identificar el problema y se desarrolle una línea base de mínimos exigidos al proceso a partir de la cual se identifiquen los problemas que se salgan de esa línea base. Analyze: Analizar los procesos existentes y el valor que cada actividad del proceso aporta al mismo, buscando las causas de los problemas y realizando análisis estadísticos de los datos para conocer que variables aportan más valor, reducen errores e incrementan la calidad y eficiencia de los procesos. En esta fase analizamos las raíces de las causas de los problemas, que pasarán a ser mejoradas en la siguiente fase. Improve: Mejorar el diseño de los procesos e implementarlos, por lo que primero deberemos comprobar que las mejoras planteadas en la fase anterior resuelven los problemas identificados. Control: Controlar los resultados. Las soluciones implementadas pueden resolver los problemas en un momento puntual, pero mediante el control, nos aseguraremos de que los problemas no vuelvan a producirse y de esta forma podamos seguir trabajando en la mejora de los procesos.

La metodología DMAIC de Six Sigma es una metodología iterativa que nos muestra el camino a seguir para la mejora de procesos. Esta metodología ha sido aplicada a todo tipo de organizaciones y se centra en hacer los procesos de negocio más predecibles y estables, minimizando las variaciones en las salidas de los procesos y siendo por tanto su misión principal la mejora de los procesos. Aunque esta metodología se centra en la mejora de los procesos existentes, existe otra metodología denominada DFSS (Design for Six Sigma), que se centra en el diseño completo de nuevos procesos o en el total redi87


seño de los procesos existentes. Muchos autores y consultores de Six Sigma recomiendan BPM utilizando Design for Six Sigma (DSS) para el rediseño de procesos y DMIAC para la mejora de procesos. Lean Six Sigma. Six Sigma se asienta sobre una serie de técnicas estadísticas para la medida de mejoras en los procesos, basándose en las medidas tomadas en las salidas de estos y realizando modificaciones sobre los mismos para comprobar las mejoras. Sin embargo, el hecho de que Six Sigma se centre sólo en el control de calidad y en la consistencia de las salidas de los procesos, siempre ha sido criticado por no abordar la mejora de procesos, por lo que ha surgido un movimiento que además de estas actividades de mejora, centra también su atención en la mejora del flujo de procesos y en la generación de valor al cliente a través de la reducción de los tiempos de entrega y de los costes de los procesos mediante la eliminación de “desperdicios”. Mientras TQM y Six Sigma se centran en procesos individuales, la metodología Lean lo hace en toda la cadena de valor, o sea, en todas las actividades que una empresa debe realizar para producir y entregar sus productos y servicios a clientes. Este movimiento, denominado Lean, se mantuvo de forma independiente a Six Sigma, aunque ambos parecen ahora ir de la mano bajo la denominación de Lean Six Sigma. Lean Six Sigma dispone de una empresa llamada “Flow Kaizen” que se encarga del rediseño y mejora de procesos de alto nivel en la organización a través de una visión de su cadena de valor y una metodología denominada “Process Kaizen” para la eliminación de estos desperdicios en las actividades y de las tareas en los procesos que no aportan valor. Kaizen, del japonés “Kai” que significa continua, y “Zen” que significa mejora, más que una técnica es una filosofía para la mejora continua, constante e incremental. Metodología Lean. La metodología Lean es una de las metodologías más en boga hoy en día y su objetivo es reducir el tiempo desde el pedido de un cliente hasta el cobro (“time-to-cash”), eliminando todos los desperdicios (waste) que no produzcan valor. Existen 7 tipos de desperdicios que aparecen en los sistemas: 1. Sobreproducción: producir más de lo necesitado o demandado por los clientes.

88


2. Esperas: el tiempo durante el cual ningún valor es aportado al producto o servicio. 3. Transporte: el movimiento innecesario de piezas o movimientos repetitivos que tampoco aportan valor al producto o servicio. 4. Inventario: materia prima innecesaria o almacenamiento de productos terminados. 5. Movimiento innecesario de personas que tampoco añade valor. 6. Sobre-procesado: añadir pasos o procesos que no aportan valor, creyendo que por trabajar más en algo tendremos más calidad. 7. Defectos: el trabajo que debe volver a hacerse. El empleo de la metodología Lean nos ayuda a entender e identificar estos desperdicios que pueden ayudarnos en los esfuerzos de mejora de procesos. Los 5 principios de Lean son: 1. Especificar el valor. El valor es el punto crítico de comienzo para el Lean Thinking. El valor sólo puede definido a través del cliente y sólo toma significado cuando es expresado en términos de un producto específico que cubre las necesidades del cliente en un momento y a un precio específico. La pregunta que nos deberemos hacer es: ¿entendemos verdaderamente el valor desde la perspectiva del cliente? 2. Identificar los pasos en la cadena de valor. El mapeo de la cadena de valor es el proceso de detallar y analizar el flujo de materiales e información para producir un producto o servicio al cliente. De esta cadena de Valor, podremos identificar que acciones producirán valor y cuales no. Las que produzcan valor pueden ser definidas como aquellas por las cuales el cliente pagaría por ellas si conociese los procesos internos de nuestra organización. Las que no produzcan valor serán aquellas que consuman tiempo, recursos o espacio y no añadan valor al producto y en consecuencia, tampoco al cliente. Identificar la cadena de valor expondrá muchas actividades que no aportan valor. 3. Crear un flujo. Una vez entendamos los pasos para la creación de valor, el siguiente paso es crear un flujo continuo que reduzca el tiempo y los desperdicios.

89


4. El principio Pull. Una vez conseguidos los tres principios anteriores, podemos poner el sistema para producir lo que el cliente requiera, el “Pull System” en oposición al “Push” basado en predicciones. 5. Buscar la perfección. Lean dice que debemos entender continuamente el valor a través de los ojos de nuestros clientes y refinar nuestra cadena de valor para incrementar el flujo basado en la demanda de los clientes. Deberemos movernos hacia la perfección. El proceso de mejora nunca termina.

BPR (Business Process Reenginering) El planteamiento que veremos ahora es más radical que los anteriores de TQM y Six Sigma. Aunque estas últimas son metodologías que tienen varias décadas de recorrido en las empresas y han evolucionado hacia una aproximación más integral basada en procesos, ambas tienen sus raíces en los procesos industriales y de manufactura, muy orientados a costes y centradas en tareas y estructuras organizativas más que en procesos. Mientras estas metodologías han abordado tradicionalmente la mejora de procesos mediante la erradicación de errores y a través de mejoras incrementales de los mismos, la reingeniería de procesos o BPR que veremos en este apartado, propuesta a finales del siglo XX por Hammer y Champy, supone una revisión fundamental de las estructuras de la empresa a través de los procesos, del rediseño radical de estos y el replanteamiento de los procesos que ejecuta la empresa para conseguir mejoras espectaculares en el rendimiento de las organizaciones. En ocasiones las empresas debemos plantearnos objetivos ambiciosos, no alcanzables mediante la mejora continua y que suponen un cambio radical en los procesos de nuestra empresa que afectarán a las actividades que realizamos y a los recursos que utilizamos. Este cambio puede suponer un cambio radical dentro de la organización y del posicionamiento estratégico de la misma, pero puede proporcionar mejoras espectaculares en los resultados de la empresa. Este es el punto de partida de la reingeniería de procesos (BPR), cuya base fundacional, al igual que en la gestión de procesos parte del análisis de las necesidades de los clientes y la transformación de la empresa para dar soporte a los procesos, de forma que estos maximicen el valor aportado a los clientes y minimice todo aquello que no aporta valor. El BPR se orienta fundamentalmente en aspectos relacionados con los procesos de la empresa y su mejora como la búsqueda sistemática de cambios que hagan a los procesos cada vez más eficientes y eficaces o el reem90


plazo de procesos secuenciales en procesos paralelos de forma que concentremos los recursos en un solo punto, reduzcamos el número de transformaciones, simplifiquemos el proceso y eliminemos los “cuellos de botella” y “tiempos muertos”. BPR es la metodología preferida por aquellos que quieren realizar cambios radicales en sus organizaciones mediante el rediseño o reingeniería. Muchas empresas han optado por la reingeniería o el rediseño completo de sus procesos empresariales con la idea de que los procesos empresariales con los que operan son más el resultado de un accidente, de un cúmulo de circunstancias o de la herencia histórica de la empresa que el resultado de una planificación lógica y consciente. El BPR se suele utilizar para repensar los modelos de negocio de las empresas, implementar nuevas tecnologías o introducir nuevos procesos, enfatizando mucho el aprovechamiento de oportunidades y búsqueda de ventajas competitivas a través de una visión Top-Down, en lugar de centrarse en el ahorro de costes y en la mejora de las actividades de bajo nivel. Para conseguir la reingeniería de los procesos empresariales, se siguen una serie de prácticas y principios como los siguientes: -

-

Organizarse en torno a los resultados y a como estos se generan y no en torno a las tareas. Hacer que los que utilizan las salidas del proceso sean quienes trabajen en el rediseño del mismo. Llevar los puntos de decisión al lugar donde se realiza el trabajo, para evitar interrupciones en el flujo de trabajo por la necesidad de aprobaciones que se encuentran fuera de donde realmente se realiza el trabajo. Capturar la información en el origen y una sola vez para evitar la duplicidad de información. Evitar el realizar el rediseño de procesos empresariales como un re-empaquetado de lo que ya existía en la empresa.

El BPR puede ser de dos formas: -

-

Fundamental: donde pensamos en por qué hacemos las cosas, si existen formas mejores de hacerlas y nos cuestionamos los fundamentos sobre los que se asienta nuestra empresa. Radical: donde nos planteamos hacer las cosas de forma completamente diferente y abandonamos los antiguos procesos, lo que implica transformar la organización para realizar las cosas 91


de forma completamente distinta: abandonamos lo viejo, descartamos lo existente y transformamos los procesos existentes de forma radical para llegar a formas completamente nuevas de hacer las cosas. Muchos autores recomiendan usar BPR sólo para realizar cambios radicales más que para hacer arreglos en los cuellos de botella o problemas que podamos encontrar en los procesos, y dejar estas tareas para metodologías como Six Sigma. Autores como Peter Drucker y Tom Peters abogaron por la Reingeniería de Procesos como herramienta para lograr el éxito en un mundo dinámico, pero fueron Thomas Davenport y James R. Short quienes más desarrollaron esta metodología y la enlazaron con las Tecnologías de la Información, afirmando que de esta combinación de TI y reingeniería de procesos, se podría transformar las organizaciones y mejorar sus procesos de negocio a un nivel parecido al que supusieron las teorías científicas de Taylor un siglo antes. Davenport y Short elaboraron una metodología en 5 pasos para BPR: 1. Establecer la visión de negocio y los objetivos de procesos: en lugar de racionalizar las tareas para eliminar problemas y cuellos de botella, como se hacía en anteriores rediseños de procesos, ellos sugieren que el rediseño se debe realizar en los procesos para alcanzar la visión de negocio y los objetivos planteados. 2. Identificar los procesos que deben ser rediseñados: parecido al análisis de Pareto practicado en TQM y consistente en no rediseñar todos los procesos, sino por el contrario, centrarse en los procesos clave que mayor impacto tienen en la organización. 3. Entender y medir los procesos existentes: entender los problemas y crear una línea base para medir las futuras mejoras. 4. Identificar como podemos apoyarnos en las TI para el rediseño de procesos. 5. Implementar un prototipo del proceso: antes de su implementación, el cual deberá servir como base para las futuras mejoras. Al mismo tiempo que Davenport y Short publicaban sus ideas sobre TI y reingeniería de procesos, Michael Hammer publicaba su radical concepción de BPR sentenciando: “la racionalización de procesos y esfuerzos de automatización de los pasados años no han significado grandes mejoras en la productividad”. Hammer creía que las empresas estaban sólo automatizando procesos diseñados con anterioridad al uso de los ordenadores y este 92


tipo de automatización tiene limitaciones, por lo que las empresas necesitan cambiar radicalmente sus procesos de negocio para sacar todas las ventajas de los ordenadores. Al mismo tiempo, Hammer consideraba que la mayor parte del trabajo que estaban haciendo las empresas no agregaba valor a los clientes, por lo que estas tareas y procesos debían ser eliminados y no ser acelerados en su desarrollo a través de la automatización. Hammer abogaba por que la reingeniería fuese cross-functional (atravesar las unidades funcionales de la empresa) y utilizar las TI para poder obtener beneficios de los esfuerzos de reingeniería. En el libro “Reenginering the Corporation: A Manifesto for Business Revolution” escrito por Hammer conjuntamente con Champy, estos autores desmitificaban la teoría de la especialización del trabajo de Adam Smith y la organización funcional jerárquica inherente a ésta. Establecían que la nueva economía post-industrial que comenzó en los años 80, es diferente a la economía de producción en masa anterior y en esta nueva economía, los clientes tiene la sartén por el mango, la competencia se ha intensificado y el cambio constante es algo normal en la gestión de las empresas. Hammer y Champy afirmaban que para competir en esta nueva economía, las empresas deben reinventar el cómo realizan sus tareas y en lugar de abordar mejoras incrementales en sus procesos de negocio, necesitan inventar mejores formas de realizar estos, para lo que es necesario realizar cambios radicales que les permitan alcanzar grandes mejoras en aspectos como costes, calidad, servicio, velocidad y agilidad para poder llegar al mercado y sobrevivir en este. El objetivo último de BPR era la organización orientada a procesos, la empresa organizada alrededor de los procesos y no de las tareas, funciones o departamentos. En estas organizaciones, los trabajadores deben ser preparados y formados para desarrollar todas las tareas del proceso y no sólo las de los pasos intermedios del mismo. En otras palabras, la especialización del trabajo expuesta por Smith, Taylor y Ford, debía ser desmantelada. En su forma más radical, la empresa centrada en los procesos es aquella que elimina la estructura funcional a favor de una estructura exclusivamente basada en procesos, en la que desaparecen los departamentos en beneficio de los equipos de procesos y donde la excelencia funcional de los departamentos, las unidades de negocio y la especialización del personal de los departamentos, es sustituida por la mejora de la comunicación y colaboración entre las personas involucradas en el proceso de negocio y la sensibilidad a los requerimientos del cliente.

93


En esta visión de la reingeniería, podemos ver reflejada la visión holística de la empresa que nos conducirá a BPM, a través del prisma de la organización horizontal y orientada a procesos, donde los procesos se convierten en los principales instrumentos de la empresa para proporcionar los productos y servicios a sus clientes. Para la reingeniería, el rediseño radical de estos procesos es el camino hacia el éxito en las empresas, el camino de la diferenciación, de la agregación de valor y de la búsqueda de ventajas competitivas a través de la atención a los requerimientos del mercado.

BPR Revisionista: La reingeniería, como vemos, es una metodología apropiada no sólo para revisar y rediseñar procesos enfocándose en agregar valor a cada uno de los pasos de un proceso y eliminar aquellos que no aporten valor, sino también para catalizar la generación de organizaciones horizontales y orientadas a procesos. Sin embargo, BPR no consiguió cumplir en muchas de sus implementaciones con las grandes mejoras que prometía en las empresas. Aunque en las implementaciones donde tuvieron éxito, este fue impresionante, muchas de las soluciones de reingeniería fracasaron o fueron simplemente empleadas para justificar el despido de personas en base a la optimización de los procesos. Visto en el tiempo, la principal causa de fracaso de BPR ha sido el no acompañar estos cambios radicales propuestos con prácticas de gestión de personas, gestión del cambio, de mentalidad y cultura corporativa, comprobándose en especial, la fuerte resistencia de los trabajadores de primer nivel y mandos intermedios a los cambios propuestos por la reingeniería. La falta de foco en el lado humano del cambio (la gestión del cambio y las personas) ha sido el mayor problema para afrontar los proyectos de BPR con garantías suficientes de éxito. De este lado humano y de gestión del cambio no fue consciente Michael Hammer en sus estudios y será un aspecto que recogerá con fuerza BPM hasta el punto de considerarlo más importante incluso que las propias soluciones BPM que se vayan a implementar. De los fracasos ocurridos en las implementaciones de BPR, surgió el llamado BPR Revisionista, el cual prestaba más atención al entorno cultural de la empresa y en especial a las personas y la gestión del cambio, envolviendo en los proyectos de BPR a la reingeniería, la tecnología y el entorno cultural de la empresa. Este BPR Revisionista limitó también el alcance de las soluciones e implementaciones a realizar con BPR. Mientras BPR piensa en 94


cambiar toda la organización y en el rediseño completo de la misma y la forma en que esta realiza su negocio, lo cual muchas veces ha sido visto como demasiado arriesgado y radical, el BPR Revisionista tiene menor alcance, se centra en proyectos más pequeños y piensa sólo en cambiar una pequeña parte o aspecto de la organización. Sobre la conveniencia de uno u otro (BPR vs. BPR Revisionista), podemos hablar largo y tendido, pero todo dependerá del entorno y la necesidad de cambio que requiera cada negocio o empresa. En algunos casos nos bastará con el BPR Revisionista para mejorar la eficiencia de algún aspecto o proceso específico de la organización y en otros, generalmente por las circunstancias y exigencias del mercado, requeriremos de cambios más profundos que rediseñen y re-posicionen nuestra empresa en el mercado, transformando radicalmente sus productos, servicios y procesos. Lo que sí es seguro, es la necesidad de contar con las personas y una correcta gestión del cambio, algo simple de decir pero muy difícil de implementar, pues muchas veces se requerirá para ello de un cambio cultural e incluso de mentalidad, que no todas las organizaciones serán capaces de afrontar. Con frecuencia hablamos de innovación en las empresas, pero esta innovación requerirá de dinámicas innovadoras, hablamos también de cambio, pero no nos planteamos cambios estructurales, aún sabiendo de su necesidad como única salida a una situación del entorno completamente nueva y diferente en la que no encaja nuestro modelo de negocio tradicional. Los cambios no son siempre bienvenidos, o lo son sólo cuando los planteamos de arriba hacia abajo en la estructura organizacional, pero no cuando estos atañen a las bases mismas de la empresa, sus modelos de negocio, su cultura y estructura organizacional, y en esta barrera de los niveles superiores de la empresa es donde el BPR también ha chocado, pues no sólo encontró dificultades en los empleados y mando intermedios como antes comentábamos, sino también en los niveles directivos y gerenciales, que lo utilizaron para transformar las estructuras intermedias y bajas de la organización donde esta metodología resultó idónea para la optimización de sus procesos y la eliminación de puestos de trabajo.

La irrupción de la Tecnología: Aunque Michael Hammer criticó el uso de las TI para la automatización de procesos cuando éste se realizaba previamente a la creación primero de más modernos y eficientes procesos, tanto Hammer como Davenport y el 95


movimiento de BPR en general, enfatizaron la tecnología y más concretamente la informática, como imprescindible para la gestión de procesos y la gestión del cambio, considerándola esencial en la nueva era industrial. Anteriormente, e incluso durante la época en la que se desarrolló el BPR, las Tecnologías de la Información estaban diseñadas para satisfacer a departamentos concretos o unidades de negocio a través de soluciones específicas para cada una de éstas. Esta especialización tecnológica por departamentos creó barreas organizacionales, pues los datos quedaban en “silos” departamentales, ocultos al resto de la organización, que además complicaban enormemente las arquitecturas informáticas necesarias para el establecimiento de las necesarias comunicaciones entre datos y aplicativos desarrollados “ad hoc” y aislados unos de otros. El desarrollo de las bases de datos relacionales y el uso de bases de datos comunes ayudó a eliminar estas barreras y ofreció la posibilidad de rediseñar los procesos completos de la empresa sin las limitaciones de los sistemas informáticos y departamentos funcionales, dejando las TI de ser percibidas únicamente como el back-office y el repositorio de datos que no contribuía a la mejora y la competitividad de las empresas. El empujón definitivo a las TI como actores importantes para la gestión de las organizaciones y de los procesos, lo dio Michael Hammer en sus últimos trabajos, donde hablaba de la gestión por procesos como el paraguas bajo el cual TQM, Six Sigma y BPR podían trabajar juntos, afirmando que el paraguas bajo el que se producirá esta convergencia seria BPM, en el que las tres metodologías se unirán a las TI para dar inicio a un nuevo paradigma tecnológico, donde los diseñadores de procesos de negocio estarían directamente involucrados en el diseño de sistemas y soluciones de TI y viceversa. En BPM, nos encontramos con diferentes perspectivas que más que fusionar o centrarnos en alguna de ellas (TQM, Six Sigma, BPR, BPR Revisionista, TI, etc.), deberemos escoger lo mejor de cada una de ellas según lo que necesitemos hacer en cada momento y escenario. Cuando corren tiempos difíciles, las metodologías de ahorro de costes adquieren protagonismo y cuando la economía está en crecimiento, las empresas lanzan nuevos proyectos, compran empresas y se introducen en nuevos mercados, sin embargo, debemos tomar la recomendación de Michael Hammer de que hay momentos en los que son necesarios grandes cambios y en otros cambios graduales, y en función de ello, podremos optar por una u otra perspectiva y combinar por ejemplo perspectivas Bottom-Up de Six Sigma, con otras 96


Top-Down como en BPR y añadiendo metodologías de TI. En la práctica, la gente de TI se ha sentido más cómoda con BPR, pues es una tendencia de los analistas y programadores el preferir hacer las cosas desde cero que modificar o corregir lo ya realizado (especialmente cuando son otros lo que lo han realizado) y el rediseño radical y centrado en nuevos proyectos planteado por BPR, resultó más abarcable y realizable desde el punto de vista de la ingeniería de software. No me gustaría dejar este recorrido sin hablar de la Teoría de las Limitaciones, que si bien no suele acompañar a BPM en los manuales sobre esta disciplina, si considero que puede ayudar al lector a disponer de una perspectiva más amplia sobre la gestión por procesos.

Teoría de las Limitaciones (TOC). La Teoría de las Limitaciones (TOC - Theory of Constraints), fue creada en 1970 por el físico Eliyahu M. Goldratt en su famosa novela empresarial “La Meta”. TOC ha sido aplicado con éxito en multitud de empresas y organizaciones, habiéndose obtenido muy buenos resultados con su aplicación en la reducción de inventarios, incremento de ventas, cumplimiento de fechas de entrega y otros ámbitos relacionados con la gestión y mejora de procesos. Las enseñanzas y libros de Goldratt son extremadamente ilustrativos al respecto, en “La Meta”, a la pregunta de cuál es el objetivo de cualquier empresa, se deja claro que no se puede mejorar si no se sabe cuál es el objetivo último que se persigue con la mejora y resolviendo que la meta de una empresa es ganar dinero ahora y en el futuro y que todo lo que se haga para acercarnos a esa meta estará bien y todo lo que se aleje, será negativo para la misma. Goldratt analiza los obstáculos que impiden a una empresa acercarse a esos objetivos y que son las restricciones o cuellos de botella que marcan el ritmo del proceso. El objetivo de esta teoría es que las empresas ganen dinero para lo cual: -

Las empresas deben maximizar sus ventas (throughput) asegurando su presencia en el mercado. Reducir los inventarios (el coste de los materiales almacenados). 97


-

Minimizar los gastos operacionales (los gastos asociados a transformar los inventarios en throughput), que incluye los costes directos, indirectos y de los activos de la empresa.

Goldratt expone en su teoría los pasos a seguir en orden correlativo, que nos permitirán alcanzar ese objetivo: 1. Identificar las restricciones del sistema y que limitan el proceso. Estos son los recursos con capacidad limitada y según Goldratt, sólo existe un único recurso con la capacidad más pequeña. Para identificarlo, analizaremos el cociente entre la carga (la suma del tiempo de procesamiento) y la capacidad de los recursos (el tiempo del que dispone el recurso para realizar esa tarea). 2. Decidir como explotar estas restricciones y como obtener el mayor rendimiento posible de estas y de los cuellos de botella, de forma que estos pasen a operar al 100% de su capacidad. 3. Subordinar todo a la decisión anterior, de forma que todo el proceso vaya al ritmo (Drum; Tambor, en inglés) de la restricción y utilizando un Buffer de tiempo para proteger al cuello de botella. 4. Elevar la capacidad de las restricciones del sistema, por ejemplo comprando más maquinaria o contratando más personal, para aumentar la capacidad de la restricción. 5. Si en los pasos anteriores se ha eliminado una restricción, como era el objetivo, regresar al paso 1 en busca de nuevas restricciones, pero nunca permitir la inercia del proceso, trabajar en la mejora continua de los procesos y seguir buscando los siguientes cuellos de botella. Como vemos, en TOC se trabaja en la optimización de la producción y los recursos en base a los cuellos de botella o restricciones y en la forma en que estos se gestionan. En lugar de maximizar el rendimiento individual de todos los recursos (pensamiento cartesiano), opta por el pensamiento sistémico, según el cual, el rendimiento máximo de un sistema no se alcanza mediante el rendimiento individual de cada uno de los recursos, sino que sólo unos pocos tendrán que funcionar al máximo de su capacidad para obtener todo lo que se espera del sistema, de forma que maximicemos los ingresos (el throughput), al tiempo que reducimos los inventarios y los gastos operativos (al no tener que tener todas las unidades de negocio y recursos al máximo de su capacidad), ya que sólo algunos de los recursos, los cuellos de botella o restricciones, condicionarán la salida de toda la produc98


ción. Estas restricciones o cuellos de botella son los llamados Drums (tambores), pues serán ellos los que marcarán el ritmo de producción. Para entender esta operativa, podemos recurrir a un ejemplo bastante ilustrativo narrado por Goldratt en su primer libro titulado “La Meta”, donde se cuenta la experiencia de un grupo de Boy Scouts que deben realizar una marcha con un inicio y un final en un determinado tiempo. El problema que se les presenta es que uno de los niños presenta sobrepeso, su marcha es más lenta que la de los demás, por lo que siempre va el último y el resto de compañeros deben esperar por él. Como el objetivo es que lleguen todos al mismo tiempo, Goldratt demuestra que la mejor solución es poner al niño más lento como el primero en la marcha, pues este es el que marca el ritmo, y por muy rápido que los demás vayan, si este primero no llega, no se cumplirá el objetivo de la misión de llegar todo el grupo junto. ¿Para qué hacer correr al resto de miembros del grupo (sobre-producción), si cada cierto tiempo estos deben esperar por el niño más lento (cuello de botella)? Este ejemplo lo compara Goldratt con lo que ocurre en muchas fábricas en su ritmo de producción, por ejemplo, en los retrasos por falta de material o debidos a una avería, que se convierten en los cuellos de botella o restricciones del proceso. Según la teoría de Goldratt existen dos tipos de limitaciones en los sistemas: -

Limitaciones políticas: todas aquellas que evitan que la empresa alcance su meta (restricciones laborales que no nos permitan hacer horas extras o restricciones comerciales como no poder vender a plazos). Para identificar y resolver estas limitaciones el Instituto Goldratt propone varias técnicas como son: o El árbol de realidad: para mostrar los efectos indeseables observados en el proceso por medio de relaciones de causa-efecto. o Exploración en nubes: para eliminar conflictos, en los que no se busca la negociación a un problema sino identificar los cambios que pueden eliminar el conflicto (evaporar la nube). o Árboles de realidad futura: que utiliza el ciclo de Deming para evaluar soluciones. o Árboles de pre-requisitos: para identificar y relacionar los obstáculos que se encontraron al implementar la solución 99


Árboles de transición: para una vez identificadas las causas raíz de los efectos indeseables y sabiendo donde queremos estar en el futuro, se determinan las acciones necesarias para alcanzar los objetivos y se establecen los objetivos intermedios. El árbol de transición es el árbol de “como haremos” para pasar del estado actual al futuro deseado. Limitaciones físicas: como equipos, instalaciones, escasez de materias primas o recursos humanos que evitan que el sistema cumpla con su meta de negocio y se identifican después de las restricciones políticas. Existen dos maneras de explotarlas: o Añadir mayor capacidad (contratar más personal o adquirir más equipos). o Aprovechar al máximo la capacidad del sistema (mejorar la eficiencia en la gestión) o

-

TOC dispone también de indicadores para los procesos como son el throughput para el dinero que ingresa, indicadores para para el inventario y para los gastos operativos. Estos indicadores nos permitirán medir el avance hacia los objetivos en la medida que se aumente el throughput y se disminuyan el Inmovilizado y los gastos operativos. -

-

Throughput: es la velocidad a la cual es sistema genera dinero a través de las ventas. También denominado Valor Generado (VG). Inventario: es todo el dinero que el sistema ha invertido en comprar cosas que espera vender o tiene la posibilidad de vender. Gastos de operación: el dinero que la empresa gasta en transformar el inventario en througput.

Como vemos, TOC tiene una estrecha relación con la gestión por procesos, tanto a nivel de indicadores de medida de procesos, como en el establecimiento de reglas de negocio. Además, las técnicas para identificar cuellos de botella en nuestras tareas y procesos, nos ayudarán en la tarea de mejorar estos procesos. El throughput, visto como la salida del proceso menos las entradas del mismo, puede ser utilizado para maximizar el rendimiento de nuestros procesos y si vemos que el throughput es menor de lo esperado o requerido por el proceso, identificar en que partes del proceso se están consumiendo tiempo o dinero, utilizando las metodologías y herramientas de TOC, de forma que consigamos obtener buenos procesos

100


funcionando y que según TOC, serán aquellos capaces de producir un alto throughput por unidad de tiempo sin consumir excesivos recursos.

Hacia una teoría unificada. Desde un punto de vista teórico, todas las teorías y disciplinas vistas en este capítulo, tienen al cliente como foco principal y se centran en la mejora de procesos como el camino que las empresas deben usar para su mejora competitiva. En todas las teorías analizadas anteriormente subyace la orientación a procesos, en las más antiguas de forma tímida y como críticas a las teorías de Taylor de la organización del trabajo, pero a medida que avanzamos en el tiempo y las teorías se adaptan y desarrollan, esta orientación, como si de una epifanía se tratase, parece consolidarse. Una de las primeras filosofías que empezó a cuestionarse la tradicional organización funcional propuesta por Frederick Taylor fue el “Just in Time”, que mediante su búsqueda de la excelencia mediante la continua eliminación de todo lo que no agrega valor al producto, proponía el eliminar el desperdicio en los procesos por la reducción del tiempo de ciclo, defectos, inventarios, etc. Más tarde se vuelve a hablar de procesos con la Calidad Total, en donde Ishikawa replanteaba el viejo concepto de “Control Total de la Calidad” por el concepto de “Control de Calidad Total a lo largo y ancho de toda la empresa”. Ishikawa dice: “la siguiente etapa en el proceso es su cliente” y “no se trata de inspeccionar totalmente los productos al final de la línea, lo que se necesita es el control de los procesos.” El control estadístico de procesos dio otro fuerte impulso a la gestión por procesos, Deming dijo: “Escuchar la voz de los procesos”, comenzó el control estadístico de los procesos que hoy sigue con Six Sigma. Hammer y Champy ofrecieron la reingeniería, que no era otra cosa que hacer de los procesos el centro de todo. Después de su famoso libro, Hammer y Champy reconocerían la poca importancia que habían dado a los procesos en “Beyond Reengineering” donde se decían cosas como: “estaba equivocado, la palabra clave en la definición de reingeniería es proceso y no radical”, “las empresas tienen que hacer de los procesos el centro de atención”, “para una organización centrada en procesos todo tiene que ser replanteado.” En la Norma ISO 9000 se retoma el tema de procesos. En la 9004:2000 se aplica el principio de enfoque basado en procesos: “Un resultado desea101


do se alcanza más eficientemente cuando las actividades y los recursos relacionados se gestionan como un proceso”, principio este que se refuerza con el de “Identificar, entender y gestionar los procesos interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una organización en el logro de sus objetivos”. En la norma ISO 9001:2000 se dice “promueve la adopción de un enfoque basado en procesos cuando se desarrolla, implementa y mejora la eficacia de un sistema de gestión de la calidad, para aumentar la satisfacción del cliente mediante el cumplimiento de sus requisitos…Para que una organización funcione de manera eficaz, tiene que identificar y gestionar numerosas actividades relacionadas entre sí.” En la teoría de Balance Scorecard o Cuadro de Mando Integral, en donde se busca establecer una relación de causa efecto entre las diferentes perspectivas: financiera, clientes, procesos, aprendizaje y crecimiento, se reconoce que el valor de una organización se crea en los procesos, y que estos son un activo intangible de las empresas que en combinación con sus recursos humanos, potenciará las competencias organizacionales. Norton y Kaplan, los desarrolladores de esta teoría de Cuadro de Mando Integral, dicen: “cada empresa tiene un conjunto único de procesos para crear valor para los clientes y optimizar resultados financieros” y es aquí donde consiguen los objetivos financieros y se hace realidad la “propuesta de valor” que dará diferenciación ante los clientes. El punto de vista de este libro es el de integrar todas las metodologías de gestión en una visión que recoja las mejores prácticas y experiencias de partes del mismo, en función de las necesidades y requisitos que tengamos en cada momento o proyecto. En este sentido puede ser de aplicación una determinada teoría para el análisis de un proyecto o partes del mismo y otras teorías para la implementación, otras para la medición y otras para el análisis de resultados, pues debido a la complejidad en la que se mueven actualmente las organizaciones, sería ilógico que toda la gestión recayese sobre una única metodología y que esta fuese la panacea o solución a todos nuestros problemas. Al igual que en el mundo de la física, no existe teoría integradora que explique el funcionamiento del universo a todas las escalas y según en qué dimensión nos encontremos, dispondremos de una teoría que explica los fenómenos observables y funciona en esa área concreta, por lo que siguiendo a los científicos, usaremos unas teorías u otras según nos encontremos en el mundo de la física de partículas o en el de la cosmología, según necesitemos unas cosas u otras en nuestro proyecto, pues de lo contra102


rio, no lograremos alcanzar las mejoras que cada una de ellos nos puede aportar e incurriremos en errores, al tratar determinados problemas con metodologías no aplicables a ese ámbito de actuación. En este sentido, por ejemplo, podremos usar TOC para identificar y mejorar las limitaciones de nuestros sistemas o procesos, Six Sigma para eliminar la variabilidad de las salidas producidas por nuestro proceso o BPR para rediseñar completamente los mismos. Esta visión integradora no producirá conflictos cuando la realicemos de forma armónica y por el contrario producirá sinergias entre las distintas teorías y prácticas utilizadas, que aumentarán el valor de nuestro proyecto y resultará más recomendable que adoptar una única metodología, sea esta TQM, Six Sigma o BPR, pues ninguna de ellas por si solas dispone de todas las soluciones y herramientas para sostener la completa gestión y mejora de los procesos. Más aún, las interdependencias entre teorías de mejora de procesos como TOC, Lean y Six Sigma se complementan perfectamente con la metodología BPM y los BPMS a la hora de controlar, monitorizar y automatizar las acciones y prácticas que estas teorías desarrollan, al tiempo que BPM, puede aprovecharse de estas para trabajar en la mejora de procesos. De esta forma, bajo el paraguas de BPM, podemos aprovechar estas sinergias para unificar los esfuerzos de mejora de procesos, resultando esta opción mucho más ventajosa que la de escoger una única teoría o metodología para solucionar un problema concreto. Así por ejemplo, podemos usar TOC en el inicio de los proyectos para identificar y tratar las restricciones de la empresa y centrar el trabajo en lo que realmente importa, Lean para mejorar el flujo de los procesos, identificar desperdicios (“waste”), eliminar las actividades que no aportan valor y encontrar vías de mejora para hacer nuestros procesos más efectivos y Six Sigma para reducir o eliminar la variabilidad y defectos de nuestros procesos y hacerlos de esta forma más sostenibles. BPM actuará como metodología integradora que nos permitirá aprovechar las potencialidades de cada una de las metodologías en las distintas fases del proyecto de mejora de procesos, haciendo además que todo el equipo sepa que tiene que hacer, cuando y como hacerlo y nos ayudará a desarrollar la solución propuesta, a implementarla, automatizarla, gestionarla y monitorizarla. BPM tendrá su origen en estos intentos de gestionar los procesos en las organizaciones, pero lo hará sin sustituir a todas estas teorías anteriores, sino complementándolas, unificándolas e integrándolas también con las modernas teorías de gestión del cambio, de la innovación y de la gestión de personas, así como con los avances tecnológicos basados en web services, las arquitecturas orientadas a servicios (SOA), los sistemas de workflow, los ERP´s, los sistemas de integración de aplicaciones y otras tecnológicas y 103


conocimientos como la orquestación de servicios, los cuadros de mando y el uso de métricas y reglas de negocio, de forma que dispongamos de todos los ingredientes para operar los procesos de negocio de nuestra organización. En el siguiente gráfico mostramos un recorrido histórico de las principales teorías y aproximaciones, áreas y disciplinas que han conducido a BPM.

Integración de BPM con las teorías de TOC, Lean y Six Sigma (TLS). La integración de la metodología BPM con las metodologías TLS, parece ser uno de los caminos en los que más se está trabajando actualmente dentro de BPM. Estas teorías tienen en común con BPM el foco en los procesos, la mejora continua, reducir costes, aumentar beneficios, mejorar relaciones con clientes y las tres creen que el trabajo de una organización está en los procesos y que estos son su negocio. Estas teorías, fundamentales para las tareas de identificación, descripción, análisis y mejora de procesos se integran perfectamente dentro del ciclo de vida de un proyecto de BPM, haciendo uso de TOC para disponer de una visión global e identificar y tratar las restricciones de la empresa para centrar los esfuerzos de mejora en los procesos que realmente importan, Lean para mejorar el flujo de los procesos, identificar desperdicios, eliminar las actividades que no aportan valor y encontrar vías de mejora para hacer nuestros procesos más eficientes y Six Sigma y su ciclo DMAIC para reducir o eliminar las variaciones y defectos en nuestros procesos y hacerlos de esta forma más sostenibles. 104


Al mismo tiempo que BPM se beneficia de estas teorías para trabajar en la mejora de procesos, estas tres teorías pueden beneficiarse de BPM a a la hora de controlar, monitorizar y automatizar las acciones y prácticas que estas desarrollan de forma que bajo el paraguas de BPM podemos aprovechar las sinergias entre estas teorías para integrar y unificar los esfuerzos de mejora de procesos.

105


106

Capítulo 3. Tecnología, Innovación y modelos de negocio

Capítulo 3. Tecnología, Innovación y Modelos de Negocio.

Para completar el recorrido de aproximación a BPM de esta primera parte del libro, veremos tres aspectos fundamentales que debemos conocer para comprender el recorrido hacia BPM y que ya hemos apuntado en el capítulo anterior. Estos son: la tecnología, la innovación y los modelos de negocio.

Evolución tecnológica: El rápido camino de las TI. Al tiempo que surgía y se desarrollaba la reingeniería de procesos (BPR), las tecnologías de la información (TI) tuvieron un amplio desarrollo y resultaron claves para la gestión de las organizaciones y de sus procesos de negocio. Este camino tecnológico comenzó con el uso de los primeros ordenadores en los años 70, utilizados para la automatización de tareas hasta entonces desarrolladas de forma manual y basadas enteramente en las personas (programas de nóminas, pedidos, facturas, etc.). Estas automati107


zaciones de procesos empresariales se realizaban en ordenadores de válvulas de vacío, con relés y enormes discos duros magnéticos como elementos electrónicos principales hasta que con el desarrollo de la microelectrónica y la incorporación de los transistores, microchips y circuitos integrados, los ordenadores fueron ganando en eficiencia y reduciendo su tamaño. Paralelamente se fueron desarrollando los lenguajes de programación y el software utilizado por los ordenadores, los cuales tuvieron también su propia evolución desde los primeros lenguajes de bajo nivel (por su cercanía al hardware), como el lenguaje en código máquina, basado en el lenguaje binario de ceros y unos que es el único que entiende el hardware, hasta los lenguajes de alto nivel, más cercanos al lenguaje de los humanos, que nos permiten abstraernos del hardware con lenguajes como Pascal o Cobol hasta los denominados lenguajes de cuarta generación como los RAD (Rapid Application Development) y los orientados a objetos como Java o C++ . Las bases de datos para almacenar datos y poder acceder a ellos también pasaron de un modelo de simple archivo “plano”, al gran salto en la ciencia informática que supuso el modelo relacional de bases de datos. Antes del modelo relacional, las aplicaciones informáticas almacenaban los datos en ficheros externos, por lo que los aplicativos tenían muchos de estos datos replicados, al tiempo que consumían gran cantidad recursos informáticos para el almacenaje y acceso a estos ficheros. Con la aparición del modelo relacional, además de disponer de una base de datos global y estructurada de la organización, pudimos separar los datos de las aplicaciones (arquitectura en dos capas), por lo que manteníamos los datos aislados y salvaguardados, pudiendo desarrollar y modificar las aplicaciones que accedían a estos datos sin necesidad de “tocar” los sistemas de archivos específicos para esas aplicaciones. A través del desarrollo de SQL (Structured Query Language), como lenguaje común de comunicación con casi todas las bases de datos, disponíamos además de independencia para usar distintas bases de datos y de esta forma, poder acceder a través de este lenguaje a los datos que ahora podían ser utilizados por múltiples aplicaciones cuando así lo precisasen.

Los ERP´s y las soluciones de integración. El salto al modelo relacional de bases de datos provocó que el desarrollo de aplicaciones se volviese más rápido y eficiente, permitiendo el desarrollo de las complejas aplicaciones tal y como las conocemos hoy en día. Comen108


zaron de esta manera el desarrollo de aplicaciones más avanzadas y específicas para distintas áreas funcionales de la empresa (finanzas, nóminas y gestión de almacenes principalmente), pero que por la falta de integración entre ellas, se traducían en altos costes de implementación y de formación a las personas encargas de gestionar estos sistemas. Para paliar este aislamiento entre aplicativos, surgen a principios de los años 90 los ERP (Enterprise Resurce Planning), como soluciones globales para la gestión de empresas. Sin embargo, los ERP, aunque comercializados como la panacea para todos los problemas de la empresa, no resultaron en las grandes mejoras de productividad y eficacia que las empresas esperaban, principalmente por la falta de adaptación de estos sistemas a las necesidades particulares de las empresas, resultando más bien en todo lo contrario y siendo las empresas las que finalmente debían adaptarse a los ERP de los distintos fabricantes. Hoy la tecnología se ha socializado y cualquier empresa o competidor puede acceder a soluciones informáticas impensables hace apenas unos años. Sin embargo, los principales vendedores de soluciones ERP siguen basando hoy su estrategia en ofrecer en sus soluciones software los mismos procesos predefinidos y de forma empaquetada para los distintos sectores y mercados, resultando que todos las empresas disponen de los mismos procesos y opciones en cuanto a la gestión de los mismos que los de su competencia, limitando enormemente las posibilidades de innovar en modelos de gestión, modelos de negocio, adaptación al cambio y mejora de procesos. Para agravar aún más las cosas, si queremos realizar nuestros propios procesos, modelos de gestión, de negocio o nuevas formas de hacer las cosas, somos nosotros los que tenemos que diseñar los modelos en función de los módulos a los que tenemos acceso, poniéndonos además los fabricantes de estas soluciones paquetizadas, grandes trabas económicas y de tiempo de implementación para realizar esos cambios y adaptaciones necesarias sobre “nuestros” sistemas, modificaciones estas que no son siempre bienvenidas por parte de los fabricantes, por lo que la mayoría de las empresas optan por amoldarse a sus sistemas ERP y no estos al modelo de negocio y de gestión que desea o ejecuta la empresa como parecería lógico. Este es el motivo por el cual cualquier implantación de un sistema de gestión en nuestra empresa necesita de grandes partidas dedicadas a formación, para que nuestro personal pueda operar y adaptarse a los modelos y procedimientos estándar del fabricante software. Toda esta operativa se pone en contra de la innovación, de la mejora de procesos y de la posibili109


dad de alcanzar ventajas competitivas para nuestra empresa a través de un arma tan estratégica para la consecución de estas como es el diseño de procesos personalizados y particularizados para nuestra empresa y su modelo de negocio y el poder adaptar nuestros sistemas informáticos a los cambios y nuevos modelos a los que nuestra empresa deba hacer frente. La situación descrita llevó a que a las empresas ya no les bastase sólo con soluciones ERP, sino que fuesen adquiriendo otras soluciones específicas de distintos fabricantes para gestionar distintas áreas organizacionales. De esta forma surgieron los CRM (Customer Resource Manager) para la gestión de las relaciones con los clientes, soluciones financieras, de gestión de la cadena de valor y de provisión, soluciones de gestión de compras, de comercio electrónico, de recursos humanos y así un largo etcétera de aplicativos para satisfacer las necesidades particulares de determinados departamentos y unidades de negocio, pero el talón de Aquiles de todos ellos, estaba en su funcionamiento como partes aisladas y no como un todo regido por la estrategia y objetivos de negocio comunes, en función de los cuales se diseñase toda la cadena de valor, de forma que no hubiera cuellos de botella, falta de integración, de coherencia y unificación entre los distintos sistemas de información que conformaban la organización. Todos estos sistemas, funcionando en las empresas de manera simultánea, agravan además el problema de la redundancia de datos distribuidos en diferentes sistemas y la falta de integridad de la información. Cada aplicativo de los mencionados accede a su propia fuente de datos, produciéndose una réplica a nivel aplicativos y sistemas informáticos de la organización funcional, donde cada departamento dispone de su propio silo de datos y donde cada aplicación ha sido personalizada para cada departamento. Aunque los sistemas estén conectados, no lo están en su lógica de datos y esta visión puede ser comparada con la estructura Taylorista de las empresas separadas en departamentos funcionales, impidiendo ver el flujo de datos que atraviesan los distintos departamentos y que conforma el proceso de negocio completo. En los años 90, con la reingeniería de procesos, las empresas comenzaron a resolver la problemática de los procesos que atravesaban la organización de forma horizontal, por lo que comenzaron a desarrollar sistemas para que estas aplicaciones se comunicasen entre ellas. Comenzó entonces el desarrollo de herramientas para conectar sus distintos módulos y poder así desplegar sus procesos de negocio, introduciendo sobre los ERP de que disponían, de capas de integración de datos para solucionar los problemas 110


de esa falta de integración. De esta forma, la complejidad de los sistemas de información empresariales creció y se hizo más heterogénea, coexistiendo en ellas diferentes sistemas y aplicativos utilizados para gestionar distintas áreas de la empresa, junto con soluciones para la integración de datos y sistemas: Middleware, EAI (Enterprise Application Integration) y capas de intermediación así como soluciones y procesos de estandarización de datos y protocolos de comunicación entre sistemas que permitiesen a los sistemas compartir información entre ellos para permitir la coexistencia de los diferentes aplicativos. Las soluciones basadas en EAI y Middleware´s, aunque solucionasen el problema de la falta de integridad de datos, presentaban el problema de la multiplicación en los canales de comunicación o el denominado problema de “NxN” cuando hacemos conexiones punto a punto, donde el número de interfaces a desarrollar es el cuadrado del número N de aplicaciones que deben ser integradas, y aunque no siempre tengamos que comunicar a todos con todos, el esfuerzo en desarrollo y mantenimiento de estos sistemas es muy elevado, debido a las tareas de reprogramación cuando cambia alguno de los aplicativos. Esta es la situación expuesta en el siguiente gráfico para conectar cinco tipos de aplicativos empresariales.

Donde el número de canales de comunicación es: N x (N-1)/2, siendo N el número de aplicativos a conectar, que en el caso del ejemplo será: 5 x (51)/2, resultando en 10 canales de interconexión de datos. La solución para minimizar el número de canales de comunicación necesarios fue el trasladarlo a un modelo de Hub o concentrador:

111


El cual resulta en tan sólo 5 canales de comunicación, la mitad que el anterior y esto sólo para cinco aplicativos, por lo que si este número aumenta, el número de requerimientos de conexión crecerá exponencialmente por lo que vemos que en las conexiones punto a punto, debemos establecer un número mucho mayor de sistemas de comunicación entre aplicativos que en las soluciones en Hub, donde la mayor dependencia la tendremos de los adaptadores para conectar el Hub con las aplicaciones existentes en la empresa. Las soluciones de integración basadas en Hub son en este sentido mucho más ágiles y eficientes, permitiéndonos minimizar el número de conexiones a realizar y son una seria aproximación a los sistemas BPMS, las as arquitecturas informáticas orientadas a servicios (SOA) y los ESB (Enterprise Service Bus) utilizados por SOA y con la misma filosofía que los HUB, en cuanto a la lógica de hacia dónde dirigir las soluciones informáticas en la empresa en cuanto a soluciones de integración y que combinadas con las soluciones de workflow y las teorías de gestión de procesos, confluirán en los BPMS y las arquitecturas SOA tal y como las conocemos hoy en día.

Internet y las nuevas arquitecturas informáticas: A finales de los años 90 se desarrollan las tecnologías basadas en internet y con ellas las necesidades de atender a los clientes en este nuevo entorno, así como aprovechar las capacidades que esta tecnología ofrecía para la comunicación entre aplicaciones en entornos geográficamente dispersos. Los negocios crecen y las peticiones de información en el ecosistema empresarial e inmediatez en la prestación de servicios crecen también 112


con ellos. Surgen nuevos y variados modelos de negocio, aparecen nuevos clientes, partners y oportunidades de negocio que exigen mayor interconexión e inmediatez en el intercambio de datos y aplicaciones. Surgen los portales de internet, el despegue del comercio electrónico y las necesidades de integración entre plataformas web y los aplicativos de la empresa, los negocios se abren al mundo y surge todo un abanico de soluciones (B2C: Business To Consumer, B2B: Business To Business, B2E: Business To Employe, etc). Es en este entorno donde se retoma la perspectiva de la gestión por procesos y se desarrolla la disciplina de BPM para ayudar a dar respuesta a esta complejidad creciente y permitir a las organizaciones aportar nuevos productos y servicios al mercado de forma más rápida, adaptando los modelos y los procesos de negocio y tecnologías que sustentan estos modelos a los cambio o demandas del mercado. De las soluciones EAI y de integración, pasamos con internet a las comunicaciones y conectividades “muchos-a-muchos”, por lo que se desarrollan nuevos estándares y protocolos de comunicación para este nuevo canal (HTTP, HTML, XML, SOAP, etc.) que proporcionarán de los servicios de comunicación y la flexibilidad necesaria para la transformación y el entendimiento entre aplicativos y datos de diferentes sistemas, convirtiendo a internet en el medio por excelencia para las comunicaciones entre sistemas y negocios, tanto a nivel interno como externo. Esta evolución de internet y sus sistemas de comunicación llegó hasta la tecnología de los web services y las arquitecturas orientadas a servicio SOA (Service Oriented Architecture), siendo la perspectiva de estos últimos una perspectiva de negocio y basada en las arquitecturas empresariales, de forma que son estas arquitecturas las que definirán las funcionalidades y servicios ofrecidos por los sistemas informáticos y los servicios web. Más concretamente, podemos decir que serán los procesos los que dirigirán la operativa de SOA y los web services y los que describirán como estos deben producir valor. Haciendo una comparación con la programación orientada a objetos, podemos decir que los web services y las arquitecturas SOA son como los objetos y los procesos como los métodos. SOA surge para posibilitar la flexibilidad de los sistemas informáticos en los entornos tecnológicos actuales, donde la interoperabilidad de datos entre empresas y sistemas independientemente de la tecnología utilizada por cada de ellos es un imperativo. Con SOA y el uso de web services, se facilitará y racionalizará enormemente las posibilidades de integración y 113


comunicación eficiente entre servicios de diferentes sistemas informáticos, de tal forma que estos pueden ser invocados por clientes o consumidores de estos servicios sin necesidad de conocer la lógica interna del servicio al que invocan. El disponer y poner al servicio de nuestros clientes, partners, proveedores y en general, a cualquier otro sistema con el cual nuestra empresa interaccione, la información necesaria para interactuar con nuestro negocio y el permitirnos exponer sólo aquello que deba ser expuesto por parte de nuestra empresa (datos o servicios), así como hacerlo sólo con quien corresponda, según los derechos y permisos de que dispongamos para acceder a estos servicios, simplificará las comunicaciones y la provisión de información de nuestra empresa de una forma totalmente racional y segura. El entorno típico en el que se presentan estas arquitecturas orientadas a servicios, es el de dar solución a los requerimientos de negocio a empresas con diversidad de aplicativos y sistemas heredados, operando en un mismo entorno y que en muchos casos no fueron construidos para operar fuera de los muros de la empresa y a las que no les resulta fácil integrar en ellos a partners, clientes y proveedores con distintas tecnologías cada uno de ellos y en el que cada integración o cambio en las necesidades de negocio o comunicación, requiere de duros esfuerzos técnicos, humanos y financieros para afrontar estos retos y oportunidades. Para ayudar en esta búsqueda del orden tecnológico en las organizaciones, SOA se presentará como el principal aliado tecnológico a la hora de afrontar las necesarias integraciones informáticas asociadas a nuestros procesos de negocio y es por ello que los proyectos de BPM y SOA, serán abordados generalmente de forma conjunta y como iniciativas de transformación global y no como proyectos aislados de TI, de forma que nos beneficiemos de una arquitectura de sistemas racional, alineada con la estrategia de la empresa y capaz de afrontar los cambios y requerimientos de negocio. Este alineamiento partirá del principio de que de nada nos servirán las inversiones en Tecnología de la Información, si no tenemos unos procesos de negocio perfectamente definidos, optimizados y medibles (parte esta de la que se encarga BPM), de forma que nuestros sistemas estén al servicio de estos procesos y no a la inversa, disponiendo de unos magníficos sistemas informáticos pero que operan sobre procesos y organizaciones más propias del siglo XIX y que resultarán en un desaprovechamiento de la inversión en TI y de oportunidades de negocio. A partir del año 2004 disponemos ya de todo tipo de soluciones informáticas que sustentan todas las actividades de negocio de las empresas en un entorno altamente competitivo y complejo, el cual requiere de inversiones 114


en el soporte de los sistemas de información sobre los que se sustentan de forma ineludible las empresas y sus nuevos modelos de negocio. En este ambiente, además de las arquitecturas orientadas a servicios (SOA), se desarrollan también la computación en la nube y nuevas arquitecturas empresariales para dar soporte a los requisitos de negocio. Hasta aquí, las empresas se apoyaban en la tecnología para gestionar sus negocios y hacer crecer los mismos, pero ahora, las empresas retoman la dirección y el control de sus negocios y definen la arquitectura tecnológica para dar soporte a sus negocios y es en este entorno de ver los recursos tecnológicos de la empresa como un todo homogéneo e integrado al servicio del negocio, donde aparecen las Suites BPMS (Business Process Management Suites), en las que la gente de negocio define y modela sus procesos y los implementa en la misma plataforma, reduciéndose la brecha entre los requerimientos del negocio y la solución tecnológica final.

Alineamiento de negocio y tecnología. Los BPMS. Con el cambio de siglo, comenzaron a surgir las soluciones a esta complejidad de sistemas distribuidos e interconectados a través de distintas capas de intermediación. Este camino de ordenación vino del reconocimiento de la arquitectura empresarial y los procesos de negocio que rigen su comportamiento, como los verdaderos conductores de las arquitecturas tecnológicas. De la evolución de las plataformas de workflow (desarrolladas para gestionar procesos de gestión documental y de seguimiento del flujo de tareas de empleados) y de los sistemas EAI (desarrollados para resolver la falta de comunicación entre aplicativos departamentales e integrar los datos de los mismos), surgieron las primeras concepciones de los BPMS que nos permitirán gestionar procesos en los que intervienen personas (heredados de los workflow) y aplicativos (heredados de los sistemas de integración de los Middleware y los EAI). Sobre estos sistemas de workflow e integración, se añadieron capacidades de análisis de datos asociados a las actividades de los procesos (completando de esta forma a los workflow), capacidades de modelado de procesos así como otras tecnologías y funcionalidades orientadas a la gestión por procesos de negocio, su control y monitorización y una notación específica para modelar los procesos y poder convertir estos modelos en aplicaciones de software ejecutables.

115


Las plataformas de Workflow, predecesoras de los actuales BPMS, gestionan una secuencia de tareas ejecutadas en serie o en paralelo por dos o más individuos y proveen de soluciones de automatización en procesos basados principalmente en la gestión documental, controlando el flujo de un documento de un punto a otro y conservando todos los estados por los que este ha pasado y que suele tener una representación como la del siguiente gráfico.

Los workflow tienen innumerables beneficios en la representación de procesos, sin embargo, su evolución se encuentra ahora dentro de los BPMS, que además de las capacidades de modelado y workflow, permiten la ejecución y control de los procesos así como la integración con aplicativos e interfaces humanas para la gestión del ciclo de vida completo de los procesos. De forma resumida, las herramientas BPMS permitirán diseñar los procesos de negocio en un entorno gráfico, especificando los pasos y actividades a realizar, los puntos de control sobre este flujo de tareas y actividades, las reglas de negocio que regirán su comportamiento, las alertas que impondremos sobre el flujo del proceso y condiciones del mismo, los roles y personas asignados a cada actividad y las integraciones con otros sistemas y aplicativos necesarios para el funcionamiento del proceso. Además, en los BPMS podremos simular el comportamiento de los procesos, para una vez validados, asegurarnos de que su comportamiento se ajusta a lo esperado, implementarlos en un entorno de producción y monitorizar su comportamiento en base a indicadores. En los BPMS, como podemos vislumbrar, los usuarios de negocio tienen ahora la posibilidad de definir y modelar sus procesos y traducirlos directamente a software ejecutable para que realice las acciones requeridas a través de distintos motores de procesos (de workflow, de reglas de negocio y de integración), que ejecutarán el código generado a partir del modelado en tiempo real. De esta forma, y a diferencia de 116


los anteriores sistemas informáticos, difíciles de modificar una vez implementados, el negocio ya no depende de la informática ni de tener que esperar por ella para implementar cambios en los procesos que estemos ejecutando y podrá abordar nuevos modelos y procesos de negocio, simular el comportamiento de determinadas modificaciones en la operativa de negocio y mejorar los procesos existentes de forma rápida y sin interrumpir el normal funcionamiento de estos. Los inconvenientes que deberemos afrontar para poder disfrutar de todas estas ventajas serán principalmente las personas y la gestión del cambio organizacional que supondrá el nuevo paradigma de la organización orientada a procesos. Sobre el cambio, sabemos desde los griegos que éste existe y es inevitable: “todo cambia, nada permanece”, por lo que la mejor estrategia que podemos abordar ante este es asumirlo y aceptarlo. Sobre las personas, incidiremos en diferentes partes del libro sobre su importancia y necesidad de gestión del cambio en las personas para afrontar los proyectos con éxito. Como ya hemos visto al hablar de BPR, muchas veces los problemas de las personas con las TI vienen por cómo estas se han implantado en las organizaciones, usando a las personas para dar soporte a los sistemas de información y no a la inversa, de forma que los niveles gerenciales dispusiesen de mayor información y control de las personas para la toma de decisiones y no haciendo a las personas partícipes del diseño de los sistemas y de los procesos de negocio, de forma que ellos también puedan verse beneficiados en sus tareas diarias del sistema a implementar. La perspectiva que abordaremos en este libro respecto a las personas y los sistemas, es que estos últimos deben ayudar y apoyar en su día a día al usuario y facilitar sus tareas, de forma que los usuarios y los sistemas se entiendan y convivan en armonía y no imponiendo el uso y adecuación a una determinada herramienta informática. Como vemos, los BPMS representan un cambio radical al pasar de las aplicaciones basadas en funciones y objetos a la orientación a procesos, integrando personas, aplicaciones y datos en torno a procesos y proveyendo de las capacidades para poder diseñar e implementar los mismos. Con este paso, pasaremos de la eficiencia a la agilidad, de la eficiencia operacional proporcionada por los ERP, a la agilidad de negocio, suponiendo este paso un cambio de paradigma al pasar los sistemas informáticos de la empresa de estar centrados en la información y trabajar a partir de esta, a estar centrados en los procesos de negocio que rigen y gobiernan el negocio. Esto no significa ni mucho menos la desaparición de los ERP o cualquier otro software utilizado por la empresa, a día de hoy es muy difícil por no 117


decir imposible que un BPMS pueda realizar las funciones de un ERP. Los BPMS vienen de alguna manera, a añadir una nueva capa, la capa de procesos de negocio, a través de la cual podemos gestionar el resto de sistemas y capas (de aplicaciones, datos y presentación) pero manteniendo el mapa de procesos de negocio como referencia para cumplir con los objetivos y estrategias de la empresa y poder modificar estos mapas de forma rápida y flexible para trabajar en la mejora continua y la búsqueda de ventajas competitivas. Los BPMS, a diferencia de otros sistemas como los ERP, son lo que se denominan sistemas PAIS (Process-Aware Information System), es decir, sistemas de información conscientes de los procesos, a diferencia de los anteriores sistemas como los ERP, CRM, SCM, etc. donde cualquier modificación en el proceso requiere reprogramar las aplicaciones y testear el resultado consumiendo gran cantidad de recursos. Aunque en muchos ERP dispongamos de un sistema de workflow integrado en los mismos para facilitar la personalización de los procesos de negocio dentro de estos sistemas, estos sistemas de workflow son componentes del propio ERP y están diseñados para poder realizar algunas funciones, pero siempre dentro de un campo limitado de posibilidades predefinidas dentro del propio entorno del ERP.

Innovación. La gestión de la innovación y la actitud innovadora será un tema que trataremos en distintos puntos de este libro, como necesaria para alcanzar resultados satisfactorios tanto en la gestión y mejora de nuestros procesos de negocio como en la gestión del cambio y su liderazgo dentro de nuestras organizaciones. En el libro abordamos la orientación a procesos y clientes y ponemos el foco en estos, no sólo como base para alcanzar los objetivos y estrategias empresariales, sino también como forma más eficiente de abordar los cambios e innovaciones a las que ineludiblemente tendremos que hacer frente a través del rediseño, la reingeniería y la mejora de los procesos de la empresa. La propia gestión por procesos, como ya hemos visto, cruza las barrearas funcionales y departamentales de las organizaciones, forzando en este tránsito a la cooperación entre las partes, al establecimiento de una cultura más abierta y participativa, más orientada al cliente, a la obtención de re118


sultados y a la innovación constante que al mantenimiento de estructuras funcionales estáticas y de privilegios dentro de ellas.

El entorno económico. Todas las empresas necesitan de la innovación para crecer. La innovación no es algo nuevo y la historia social y económica del mundo está plagada de claros ejemplos de cómo esta ha sido la catalizadora del progreso de la sociedad y su bienestar. Transcurridos varios siglos de historia económica, social y política, acompañadas de sendas revoluciones en la forma de gestionar las empresas, (revolución industrial, revolución de los métodos productivos en los años 70 y revolución en las formas de gestión de las organizaciones), nos encontramos actualmente en la revolución que viene dirigida por el conocimiento, el talento de las personas y la tecnología. Las fuentes de ventaja competitiva actuales ya no están en la utilización de mano de obra barata o en la obtención de recursos naturales a bajo coste. Los tiempos de una sociedad de masas ávida de consumir todo tipo de productos y servicios como era la sociedad después de la segunda guerra mundial y que precisaba de empresas manufactureras capaces de producir todo lo que consumían estos mercados, han sido sustituidos por un nuevo entorno en el que la oferta es mayor que la demanda y donde los recursos con los que contamos hoy para poder hacer frente a esta situación son el talento de las personas, el conocimiento con el que cuenten estas personas, la creatividad y la innovación para poder convertir las ideas en valor y el conocimiento (know-how) en resultados (cash-flow). En la época de la producción en masa de la segunda mitad del siglo XX, las empresas recurren a la tecnología y a la automatización para hacer frente a las necesidades de producción a gran escala, pero a finales de siglo el mercado de muchos de estos productos comienza a dar signos de agotamiento, provocando que empresas perfectamente optimizadas y con altísimos índices de productividad, se encuentren con una demanda en claro descenso. Esta situación se ve agravada por la competencia de los países emergentes (los BRIC: Brasil, Rusia, India y China principalmente), que con sus bajos costes de producción provocan la saturación del mercado y el despertar de un cliente cada vez más exigente y sensible al precio y que

119


además dispone, gracias a internet, de información de distintos precios y productos en todo el mundo.

Competencia destructiva: Ante esta situación nada alentadora para muchas empresas, que hasta ahora habían funcionado sin problemas, este nuevo escenario socioeconómico en el que nos encontramos provoca incertidumbre en las empresas, que no saben muy bien qué línea seguir. La solución abordada por la mayoría de empresas ha sido el de la reducción drástica de costes con objeto de poder mantener sus productos en el mercado en base a unos bajos precios que les permitan conservar a unos clientes cada vez más escurridizos y difíciles de conservar, pero esta reducción de e costes se hace a costa de reducir la calidad y los márgenes de beneficio sobre sus productos y servicios. Esta situación es la denominada “competencia destructiva”, en la que las empresas basan su supervivencia en el mercado exclusivamente en el precio a base de reducir costes. Otra denominación para este tipo de mercados, es la descrita por W. Chan Kim en su libro “Blue Ocean Strategy” y que en contraposición a los océanos azules donde es fácil pescar peces, Chan nos habla de “Océanos Rojos”, para referirse al color de la sangre surgida de la lucha encarnizada en un océano infestado de competidores que se desangran entre ellos por unos pocos peces (clientes), para los cuales el precio se ha convertido en el principal factor de elección entre una u otra empresa. Estos océanos rojos o escenarios de competencia destructiva presentan además una particularidad que debería hacernos reflexionar y es que en la guerra de bajos costes sólo puede ganar uno (el que sea capaz de ofrecer el precio más barato), siendo la misma situación que en los denominados juegos de suma nula (donde para que uno gane, otro debe perder; como en el ajedrez o en el tenis). Retomando las ideas de Goldratt, el mundo del coste es el que predomina a la hora de actuar en las empresas y el que lleva a las empresas a esa competencia destructiva y a los océanos rojos. En TOC, al igual que en BPM y prácticamente en todas las teorías de management, el objetivo de cualquier empresa es ganar dinero y según lo libros de Goldratt, para alcanzarlo, tenemos tres flujos de dinero que podemos manejar: -

120

Gastos Operativos (GO): todos los gastos de la empresa necesarios para mantener la actividad de la misma: salarios, alquileres, maquinaria, etc.


-

Inversiones (I) que se realizan en la empresa y que no se pueden recuperar a corto plazo. Valor Generado (VG): el dinero que genera la empresa con la venta de sus productos y que calculamos restando al precio de venta de un producto o servicio todos los costes imputables a ese producto o servicio.

Al final de un periodo obtenemos un beneficio (B) con nuestras operaciones que es la diferencia entre el Valor Generado (VG) y los gastos operativos (GO): B=VG-GO Para mejorar el beneficio de una empresa podemos actuar de dos maneras: -

Aumentando el Valor Generado (VG) Disminuyendo los Gastos Operativos (GO)

Como ya hemos visto en el primer capítulo, la variable sobre la que decidamos actuar para aumentar los beneficios dirá mucho sobre la forma que tenemos de gestionar nuestra empresa. Como ya vimos, normalmente las empresas escogen actuar sobre los gastos (GO), por ser esta la opción sobre la que tenemos un mayor control, mientras que la mayoría rechaza actuar sobre los ingresos (VG). Sin embargo, esta decisión de actuar sobre los gastos operativos lleva a las empresas a obtener buenos resultados sólo en el corto plazo, pues a medio y largo plazo, los márgenes de mejora se estrechan, pues llega un momento en el que ya no podemos actuar más sobre los costes sin perder en otros aspectos como la calidad. Es la situación descrita en la “Triple Restricción” del Project Management (TiempoCostes-Alcance), pero aplicada a los costes: no podemos aumentar los beneficios, reducir los costes y mejorar el servicio al mismo tiempo. Mejorar el servicio aumenta los costes, aumentar los ingresos aumenta los costes y si reducimos costes, el servicio prestado empeora. La salida a esta situación, sobre la que ya alertamos en el primer capítulo, pasa por la búsqueda de los “Océanos Azules”, esos océanos donde no existe todavía la competencia y se pueden todavía pescar peces (clientes), sin tener que imitar lo que los demás hacen o seguir la peligrosa estela de los bajos costes. Estos océanos azules o paraísos de mercado para cualquier empresa existen, pero pasan ineludiblemente por la innovación y la diferenciación, por la predisposición al cambio y por la velocidad con la que 121


adoptemos el mismo, por la búsqueda constante de ventajas competitivas, de nuevos nichos de mercado y clientes que en la saturación de mercado actual, todavía pueden ser sorprendidos por nuevos y mejorados productos y servicios, pues esta será la única forma de dejar que el cliente sólo vea el precio.

Gestión de la innovación: Podemos ver la innovación como el encuentro entre los problemas y el conocimiento y de esta visión extraer que si estamos de acuerdo en que los problemas que afectan a nuestra empresa pasan por hacer frente a este entorno descrito de competencia destructiva y que nunca tanto conocimiento y talento a estado a nuestra disposición como lo está ahora, entonces este es el momento idóneo para que surjan nuevos modelos e ideas innovadoras. Lo que tendremos que hacer en nuestras organizaciones es provocar este encuentro entre los problemas y el conocimiento para que se produzca la colisión generadora de innovación. Para ello, deberemos crear los mecanismos y usar las metodologías, tanto para que el conocimiento pueda desarrollarse como para acercar los problemas al conocimiento y no mantenerlos aislados de este en los niveles directivos de la empresa como si estos fuesen los únicos poseedores del conocimiento. Esta actitud y visión de buscar el conocimiento en todas las partes de la organización, tanto en los niveles directivos, como mandos intermedios y operativos de los niveles más bajos de la organización, será una característica de los proyectos de BPM. Hace unos años se creía que la innovación era algo Top-Down, los de arriba piensan y los de abajo ejecutan, el departamento de I+D diseña y la cadena de montaje implementa, pero ahora sabemos que esto ya no funciona así. En nuestros proyectos de BPM, mezclaremos la visión Top-Down con la Bottom-Up, con el ánimo de recabar toda la información necesaria y conocimientos de la organización y su entorno, independientemente de donde esta se encuentre, para confrontarla con los problemas que hayamos encontrado. Pero lograr este encuentro entre los problemas y el conocimiento, requerirá de un cambio de mentalidad y de cultura organizativa para poder llevarlo a buen puerto y será necesario el desarrollo de nuevos estilos de liderazgo, más abiertos y participativos y donde prime la transparencia, el conceder mayor importancia a las personas, que son las poseedoras del 122


conocimiento y en consecuencia las que disponen de la capacidad de resolver los problemas e identificar nuevas oportunidades y mejoras. Deberemos crear los mecanismos que permitan recabar, comprender y compartir la información de forma transparente y abierta, en un entorno creativo y de participación constructiva, donde se prime la participación y el aporte de ideas y no donde estas ideas se escondan por miedo a las consecuencias. Así mismo, deberemos aprovechar también el potencial de las nuevas tecnologías para recabar información sobre los problemas y las posibles soluciones, y en especial, aquellas relacionadas con la web 2.0 y que nos permitan convertir el conocimiento tácito en conocimiento implícito y aprovechar de esta forma todo el potencial con el que cuenta nuestra empresa. El proceso para abordar estos cambios comienza en la llamada innovación en procesos, donde las empresas se plantean el hacer las cosas de forma diferente y que fruto de colisionar conocimientos y problemas, nos conducirá con posterioridad a la innovación en modelos de negocio y la innovación en mercados, que conformarán la denominada Innovación Tridimensional (procesos, negocios y mercados). Estos tres tipos de innovación se presentan en ese orden por no empezar la casa por el tejado: no afrontar un nuevo mercado sin un modelo de negocio sólido que pueda hacerle frente y no diseñar un modelo de negocio cuyos procesos no son todo lo eficientes y rentables que pudieran ser. Sin embargo los tres tipos de innovación se refuerzan unos a otros y al final, no innovamos en una sola área, sino que lo hacemos en todas al mismo tiempo, unas se llaman a otras y una innovación que nos permita reducir los tiempos de entrega, nos permitirá por ejemplo abordar nuevos mercados y modelos de negocio no considerados hasta entonces.

Innovación en Procesos. En el entorno económico descrito anteriormente, altamente competitivo y sobrecargado de productos y servicios, la innovación en procesos (como hacemos las cosas), será tan importante como la innovación que realicemos en los productos y la innovación en mercados. Por definición, la innovación en procesos es la revisión fundamental y el rediseño radical de procesos a través de las TIC para alcanzar mejoras espectaculares en medidas críticas de rendimiento, tales como costos, calidad, servicio y rapidez. Esta definición de innovación en procesos, tiene una diferencia respecto a la reingeniería y es la palabra “espectacular”. Las me123


joras que implican innovación en procesos deben ser espectaculares, cruzando los problemas con el conocimiento para encontrar nuevas formas de hacer las cosas que supongan grandes saltos en el rendimiento y la mejora de la eficiencia de nuestras operaciones. Con BPM contaremos con una poderosa herramienta para diseñar, gestionar y monitorizar nuestros procesos de negocio en base a datos y al análisis de los mismos. Sin embargo en este libro, aunque damos importancia a la monitorización y control de procesos, consideraremos otras vías más allá de las del análisis y control, que si bien conformarán la base sobre la que gestionar, analizar y proponer mejoras en nuestros procesos, no serán las únicas, y dejaremos una vía para la innovación, la creatividad y la valentía a la hora de plantear nuevos modelos de negocio y de procesos. Como decía Peter Drucker: “el mejor medio de predecir el futuro es creándolo”. Este planteamiento nos obligará a replantear no sólo la forma en que hacemos las cosas, sino también replantearnos las bases estructurales de muchas empresas operando con esquemas y prácticas heredados del Taylorismo, donde muchas de las actividades implementadas son realizadas únicamente para satisfacer exigencias internas de la propia organización y que nada tienen que ver con la orientación al cliente y los mercados. Estas estructuras de hace más de doscientos años, no hacen sino ponernos barreras ante los retos a los que actualmente debemos hacer frente, por lo que deberemos empezar de cero, para generar nuevos modelos organizativos bajo los que nos replanteemos los diseños y operativas de nuestros procesos y el cómo hacemos las cosas, pues más que en los productos, será en el cómo hagamos esos productos donde radicará la diferencia entre una y otra empresa. En esta transición, innovar en procesos significará replantearnos nuestros procesos desde las bases, partiendo de una clara orientación hacia los clientes, de forma que los procesos se adapten y estén totalmente dirigidos a la satisfacción de sus necesidades, eliminando ineficiencias y todo lo que no aporte valor a ese cliente para satisfacer sus necesidades y expectativas. Para conseguir la innovación en procesos debemos considerar dos aspectos que se han demostrado como grandes catalizadores de la innovación: el uso de las tecnologías de la información y la presión de la competencia. Hoy todos conocemos como el uso de las TI ha supuesto autenticas revoluciones en infinidad de modelos de negocio y empresas que han sabido 124


adoptar las mismas para innovar en procesos y mercados y no sólo han utilizado las mismas para el ahorro de costes y mejora de procesos. Sin embargo, y según ha demostrado en un estudio la consultora McKinsey, es la presión de la competencia la que fuerza realmente a las empresas hacia la innovación que haciendo uso de las TI permiten alcanzar esos resultados espectaculares. La presión de la competencia se ha revelado como la gran catalizadora de la innovación y que en su ausencia, las empresas no innovan, se dejan llevar por la inercia, sin plantearse la introducción de cambios. Edgar Schein, revela en sus estudios como las organizaciones sólo cambian cuando sienten que este es el único camino que tienen para poder sobrevivir. Schein compara este proceso con los prisioneros de un campo de concentración y la diferencia entre la mentalidad conservadora de los que aceptan la situación y no afrontan los riesgos y repercusiones de una posible fuga y los que se resisten a esta situación y buscan constantemente como escapar de ella, conscientes de que si no la hacen, jamás saldrán vivos del campo. Las comparaciones de esta metáfora del campo de concentración, son aplicables a entornos como el aprendizaje, donde este se produce sólo cuando la ansiedad de supervivencia es mayor que la necesidad de aprendizaje, o en el entorno empresarial, donde el aprendizaje y la innovación sólo se producen ante la presión de la competencia, de los mercados y la necesidad de supervivencia de las empresas, por lo que si queremos provocar la innovación tan necesaria en las empresas, deberemos desarrollar el ambiente y entorno adecuado para provocar la urgencia y ansiedad de supervivencia. En la innovación en procesos deberemos también tener en cuenta que el conocimiento de nuestra organización asociado hoy a un proceso, puede quedar obsoleto mañana. Aunque hablemos de estandarizar procesos, estos deberán ser constantemente repensados y analizados. Peter Drucker, afirmaba: “el conocimiento es distinto a todos los demás recursos. Este se hace obsoleto constantemente, por lo que el conocimiento avanzado de hoy es la ignorancia de mañana”. Al igual que el cambio, la obsolescencia del conocimiento inyectado en nuestros procesos de negocio es otra realidad que deberemos vigilar, pero para ello, contaremos con el compromiso de nuestra organización en la mejora continua y la mejora constante de procesos a través de una disciplina como BPM, que nos permitirá de una forma rápida y no traumática la adaptación al cambio y la adopción de nuevos conocimientos mejorados de nuestra organización en los procesos de negocio que regirán el funcionamiento de la misma.

125


Modelos de negocio Para la consecución de nuestros objetivos empresariales, comenzaremos nuestro camino no trabajando directamente sobre nuestros procesos, sino en una parte mucho más creativa que se iniciará con el diseño del modelo de negocio y que continuará con el diseño de las estrategias, tácticas, metas y objetivos de negocio, las cuales trasladaremos finalmente al diseño de los procesos que soportarán en su operativa los propios modelos de negocio que hayamos definido y permitirán la permanencia de estos modelos en el mercado así como el poder adaptarlos a los cambios y a las necesidades cambiantes de nuestros clientes y mercados. Los modelos de negocio podemos definirlos como el sistema interconectado e interdependiente de actividades que determinan como una empresa hace negocio creando valor a sus clientes. El modelo de negocio es la representación resumida de una empresa, son los planos generales en los cuales aparecen aquellos elementos relevantes para que el negocio exista y en el que se describe que ofrecemos a nuestros clientes, como nos relacionamos con ellos, como ganamos dinero y como crearemos valor. Veamos el Ciclo de Vida de la empresa: 1. Planificar que voy a hacer en mi negocio. El modelo. 2. Qué voy a necesitar para implementar ese modelo. 3. Transformar los recursos (inputs), para convertirlos en el resultado de mi negocio (outputs). 4. Entregar los productos y/o servicios. 5. Monitorizar y evaluar qué hemos comprado, transformado y entregado y verificar que esto se ajusta a lo planificado para retroalimentar al punto primero. En todo este ciclo tenemos varios flujos que conformaran el modelo de negocio de nuestra organización: financieros (cuanto me cuestan los recursos y que dinero percibo por los productos que vendo), flujos de compras, de productos, de ventas, tecnológicos, etc. y que conjuntamente conformarán nuestro modelo de negocio. Normalmente partimos de una idea de negocio, pero que tendremos que conformar para pasar del “qué” vamos a hacer, al más difícil de “cómo” vamos a hacerlo. Existen varias herramientas y metodologías para ayudarnos a diseñar nuestros modelos de negocio, pero probablemente la herramienta más 126


influyente sea el Business Model Canvas del libro “Business Model Generation” de Alexander Osterwalder y Yves Pigneur. Este modelo parte de nueve bloques básicos relacionados entre sí, que describen diferentes aspectos de la idea de negocio necesarios para que una empresa pueda aspirar a ganar dinero, estos nueve bloques cubren las cuatro áreas principales de un negocio: clientes, oferta, infraestructura y financiera conformando el plano general de la estrategia a implementar a través de las capacidades y estructuras de la organización. Los nueves bloques sobre los que se basa este modelo son: segmento de clientes, propuesta de valor, canales, relaciones con clientes, corrientes de ingresos, recursos clave, actividades clave, partners clave y estructura de costes. El uso de esta herramienta es más que recomendable para la generación de modelos de negocio y es recomendable dedicar algo de tiempo a completar este Canvas (lienzo) para tener una idea mucho más clara de nuestras ideas de negocio. Para profundizar en el Business Model Canvas podemos recurrir a la lectura del libro de sus creadores: “Business Model Generation”.

Nuevos modelos para nuevos mercados: Para muchos la época del marketing tradicional ha llegado a su fin. Los negocios de hoy en día requieren que una vez analizada la posición que queremos en una determinada cadena de valor, podamos hacer experimentos de mercado, pues no podremos saber a ciencia cierta que va a tener éxito y que no lo va a tener, necesitamos poder “prototipar” modelos de negocio, evaluar muchas variables y entornos y “jugar” con los modelos de negocio antes de lanzar una idea o empresa. El diseño del modelo de negocio que realicemos para nuestra empresa ya no es, según hemos aprendido en las escuelas de negocio, un proceso lineal en el que podemos analizar numéricamente el plan de negocio y los resultados esperados, de forma que podamos predecir claramente el éxito o el fracaso de un proyecto. Incluso las grandes empresas que han crecido en base a un modelo de negocio concreto, ahora se están dando cuenta que estos modelos están agotándose e intentan crear nuevos modelos de negocio que les permitan mantener sus posiciones en el mercado, pero el error ocurre cuando se pretende realizar este cambio basándose en la misma mentalidad y cultura corporativa que las hizo desarrollarse y crecer, por lo que fracasan en la generación de estos nuevos modelos.

127


El diseño de los nuevos modelos de negocio requiere no sólo del análisis, sino también de una nueva cultura corporativa, la predisposición a la innovación en todas sus áreas y a la creatividad aplicada al diseño de negocios, pues son en estas facetas en las que más tiempo y habilidades debemos emplear si queremos llegar a buen puerto con el proyecto o modelo de negocio que emprendamos. En este camino, debemos recordar lo visto en el apartado anterior de innovación sobre como el precio y los productos son hoy en día fácilmente imitables por su homogenización. La diferencia hoy se encuentra en las experiencias de usuario que proporcionemos a nuestros clientes con nuestros nuevos y mejorados productos, capaces de sorprender a los clientes y en como analicemos e identifiquemos las necesidades y expectativas de estos clientes para encontrar nuevas oportunidades y posibilidades de mejora.

Escuchar a los clientes: Una de las principales características que distingue a las personas que están detrás de muchos de los productos más exitosos es su capacidad de ver sus productos y procesos de negocio a través de los ojos de sus clientes, haciéndose constantes preguntas sobre su eficiencia y grado de cumplimiento con las necesidades y expectativas de estos clientes. Esta orientación marcará el funcionamiento de toda la empresa para adaptar nuestros productos y servicios a estos clientes mediante la eliminación de los puntos débiles e ineficiencias en los procesos productivos para obtener productos que enamoren y seduzcan a sus clientes. Las preguntas que nos podemos hacer son: ¿qué odio de este producto o de la empresa que lo comercializa?, ¿qué me resulta irritante? ¿por qué escojo a esta empresa y no a otra?, ¿qué mejoraría mi experiencia como usuario?. La clave estará en diferenciar a los distintos tipos de clientes, reconocer sus particularidades y en observarlos y conocerlos en profundidad, pues estos no siempre transmiten lo que sienten u opinan sobre nuestra empresa y sus productos, de forma que podamos reducir el gap entre lo que nuestros clientes compran y lo que realmente desean. Las empresas invertimos el 90% de los presupuestos en dirigirnos a los clientes en lugar de escucharlos. Una vez cerramos la venta, dedicamos poco o ningún esfuerzo para continuar al lado del cliente y prestamos poca o nula atención a proveerle de un buen servicio post-venta. Es como si una 128


vez realizada la venta, huyésemos del cliente para no mantener una relación duradera con este en el tiempo que nos permita aprender de él, recabar información sobre sus nuevos gustos y expectativas y mantener abiertas nuevas oportunidades de venta. La gran innovación del marketing actual reside en la transformación del mismo de un enfoque outbound (saliente): de la empresa hacia el cliente, a un enfoque inbound (entrante): de los clientes hacia la empresa. En estas segundas, las inbound, existe un elemento diferenciador de gran valor: la atención y predisposición del cliente que ha tenido la voluntad de iniciar el contacto y dirigirse a nuestra empresa y este movimiento debemos aprovecharlo, pues tiene todavía más valor que el producido por nuestra empresa para acercarnos al cliente. Bajo esta perspectiva se han desarrollado nuevos paradigmas como SCO (Succesful Customer Outcomes), en el que el principio fundamental es que todo lo que hace la empresa debe contribuir al SCO y lo que no contribuya, es susceptible de ser eliminado. SCO pone al cliente en el centro del mapa, es una filosofía de management que rechaza la idea de que toda actividad debe ser vista como una línea de producción de izquierda a derecha con los clientes al final o fuera del gráfico, e incluye métodos como CEMMEthod (Customer Expectation Management Method) y conceptos como Enterprise Process Maturity. El cliente es cada vez más el centro de nuestros procesos y las empresas deberán dejar de ver solo hacia sus procesos productivos y la mejora de los rendimientos empresariales y extender la visión hacia afuera, para abarcar e involucrar en los procesos a los clientes más allá de los límites de la organización.

Escoger Modelos de negocio: Existen infinidad de empresas con diferentes modelos de negocio que han sido probados con éxito, por lo que dispondremos de infinidad de modelos en los que encontrar patrones que adaptar, modificar y mejorar para nuestros propios modelos. A continuación presentamos algunos modelos genéricos que pueden ser de aplicación: 1. Long tail: O lo que es lo mismo, vender más cantidad aunque los beneficios sean menores. Hasta la irrupción de Internet, la máxima era que pocos productos daban la mayoría de los beneficios. El paradigma de long tail o "cola larga", introducido por Chris Anderson, lo que nos dice es que lo que impor129


ta es vender muchos productos de nicho que al final serán los que nos darán los mayores beneficios, y esto es posible gracias a la tecnología que conecta oferta y demanda y que permite nuevos modos de distribución. Un ejemplo de este tipo de modelo de negocio es el de Amazon donde el negocio se hace disponiendo de acceso a millones de libros de todas la temáticas, como Amazon guarda stock mínimo y la mayoría de pedidos los tramita desde el proveedor, la verdadera ventaja sobre el negocio tradicional de libros está en vender mucho, aunque sean ediciones muy cortas. 2. Plataformas: Es el negocio de entre otros Google. Es decir poner en comunicación una oferta con una demanda. Pero también es el modelo de las redes sociales como Facebook, ebay, etc. 3. Gratuito: Este es el modelo de negocio que actualmente triunfa en Internet. Los clientes que no pagan por el contenido. En este caso se puede financiar esta gratuidad por medio de la publicidad o por el modelo freemium, es decir, el cliente no paga por servicios básicos pero paga por servicios Premium. 4. Abiertos: Son los modelos de negocio en los que se hace uso de las relaciones con otras entidades para generar valor. Tiene mucho que ver con el concepto de innovación abierta. Se puede hacer uso de ideas, propiedad intelectual, productos que vengan de entidades externas, o se puede explotar los productos propios, sean intelectuales o tecnológicos ofreciéndolos al mercado. Pero no debemos de ver estos patrones de modelos de negocio como islas. La combinación es también un patrón reconocible. ¿Qué tal si juntamos los modelos gratuitos con los basados en plataformas? ¿o el modelo Long tail y el abierto? Este juego puede reportarnos muchas ideas sobre a dónde dirigirnos al plantear nuevos modelos de negocio y pueden ser unidos también a los nuevos modelos basados en la movilidad y que nos ayudarán a atender a clientes independientemente de su localización geográfica, o modelos basados en la nube o en redes sociales.

130


Otra recomendación que podemos hacer es el probar los modelos de negocio antes de su lanzamiento, para comprobar su validez, realizar los ajustes necesarios sobre el mismo y minimizar los riesgos y la incertidumbre asociados al lanzamiento de cualquier negocio. En BPM haremos un uso intensivo de las herramientas de simulación de procesos, las cuales nos podrán ayudar a evaluar los procesos antes de su implementación y nos podrán servir de aproximación al comportamiento de estos procesos. Sin embargo, en el área de simulación de modelos de negocio, no existe una herramienta que podamos adquirir para comprobar el grado de éxito de un modelo de negocio, el cual requerirá además de este análisis, de otros muchos factores internos y externos y habilidades (liderazgo, visión, emprendimiento, innovación, intuición, oportunidad y suerte). Creemos de todas maneras que pronto aparecerán herramientas basadas en teoría de juegos que nos permitirán “jugar” con estos modelos a la hora de simular los mismos y ayudarnos a la elección del modelo más adecuado para nuestro negocio y que servirán de complemento a las ideas y modelos de Canvas (lienzos, pizarras) de nuestros modelos de negocio, que al final, son sólo eso: ideas y pizarras de un modelo de negocio diseñado, pero que desde luego no aseguran su éxito. Pero mientras estas herramientas no se desarrollan, la traslación de nuestro modelo de negocio a procesos, puede servirnos para probar el comportamiento de estos modelos en base a procesos, además, veremos en los siguientes capítulos, varias utilidades, herramientas y estándares que nos permitirán avanzar en la idea y del modelo de negocio a una especificación más detallada de este modelo (arquitecturas empresariales, modelos de madurez, de referencia y mejores prácticas) tanto en lo relativo a procesos como a entornos de negocio. Acción y velocidad: Aunque las ideas y modelos de negocio que desarrollamos no nos pueden asegurar científicamente su éxito, existe un componente fundamental para cualquiera de estos modelos que si juega un papel fundamental en las posibilidades de éxito o fracaso de estas ideas y modelos que es la predisposición a la acción y la velocidad con la que ejecutemos estos modelos. Por desgracia, muy pocas personas y empresas en la historia toman las riendas de su destino para lanzar una empresa de éxito y la razón principal suele encontrase en la falta de acción. Son muchas las empresas que a pesar de disponer de una magnífica estrategia, metas y objetivos de negocio, estos nunca llegan a materializarse. Algunas veces, esta inacción ocurre por 131


exceso de dedicación a los detalles previos a un lanzamiento que nunca llega a materializarse y por la necesidad de tener todo perfectamente controlado. Como decía Mario Andretti, el famoso piloto de Fórmula 1: “si todo está bajo control, es que vas demasiado lento”. Pero la mayor parte de las veces, esta parálisis es debida a que no se toman las medidas para que las cosas ocurran y se lleven a cabo los objetivos planificados. A pesar de contar con un buen modelo de negocio, una estrategia para llevarlo a cabo y unos procesos perfectamente definidos para obtener los resultados esperados, la falta de acción lleva a que todo este trabajo se pierda en el tiempo sin llegar nunca a materializarse. Muchas veces desglosamos todas las fases y paquetes de trabajo de nuestro proyecto de forma perfectamente definida y estudiada, estimamos los recursos, los tiempos y las actividades necesarias para alcanzar las metas que nos hemos propuesto y luego dejamos caer estas actividades en el saco de los olvidos. Los conocimientos e inteligencia que ponemos en planificar y saber cómo hacer las cosas resultan inútiles, si luego no implementamos las acciones necesarias para llevarlas a cabo. El implementar la gestión por procesos o innovar se hace actuando, y para poder actuar con la energía necesaria, necesitamos motivación, creer en lo que estamos dispuestos a hacer (“primero fue el pensamiento”) y esta es la única manera de realizar nuestros sueños personales y empresariales, por encima de los conocimientos e inteligencia que aportemos a los mismos. En el reconocido como mejor libro de gestión de todos los tiempos “En Busca de la Excelencia” de Tom Peters, el lema principal del libro decía: La excelencia tiene que ver con el enfoque en las Personas, los Clientes y la Acción. Tom Peters revisó 20 años después este libro donde actualizó y replanteó los “8 principios de la excelencia”, afirmando que la idea de permanencia está muerta y que cualquier modelo de negocio o estructura organizativa basada en la permanencia está condenada al fracaso. Tom Peters vaticinaba la necesidad de una decidida apuesta por el talento, por la búsqueda constante de la innovación, de la excelencia en todo lo que hacemos y de las ilimitadas posibilidades que ofrece internet. En este libro, Peters avanza que ya no valen las antiguas reglas, hay que reinventarse día a día y concluía que la ausencia de una predisposición a la acción sigue siendo hoy en día el mayor problema de las grandes organizaciones, que piensan y planifican demasiado.

132


Al hablar de los modelos de negocio, resaltábamos la importancia de la parte creativa sobre la de análisis y de la necesidad de habilidades humanas asociadas a esta para el diseño de modelos de negocio exitosos. Esta práctica o necesidad es necesaria no sólo en el diseño de los modelos de negocio, sino en todos los aspectos tanto de negocio como de la vida y así, por ejemplo, la solución a una mala situación económica dentro de nuestra empresa tiene muchas veces más que ver con la actitud y predisposición a la acción que tengamos para resolver el problema que con el análisis de los números y variables económicas que podamos analizar. Como hemos visto las organizaciones innovadoras convierten las ideas (mediante la confrontación de los problemas con el conocimiento) en valor. Pero esta capacidad ya no es suficiente por si sola si no somos capaces de hacerlo con velocidad y de forma constante. No se puede concebir la innovación sin velocidad y constancia, porque sin estas, las ideas resultarán efímeras o serán copiadas por alguna otra empresa más rápida que nosotros y no seremos capaces de mantener las ventajas competitivas alcanzadas mediante la innovación. Innovar no es tan sencillo como parece y tan importante como innovar y ser capaces de generar valor, es ser capaces de hacerlo de forma permanente y más rápido que nuestros competidores. Tanto la necesidad de acción como la velocidad para lanzar nuestras innovaciones y proyectos requerirán de un liderazgo innovador y efectivo. Hablaremos más adelante de este liderazgo así como del necesario compromiso de los niveles directivos con los proyectos que emprendamos, pues requeriremos de ambos para nuestros proyectos de BPM y sin estos, resultarán inútiles todos nuestros esfuerzos por extraer lo mejor de las personas de nuestra organización para generar ideas, innovar, trabajar en la mejora de procesos o adaptarnos al cambio. Pero ha llegado el momento de adentrarnos en BPM, donde todas las ideas vistas en esta primera parte del libro nos ayudarán a entender esta nueva disciplina y a extraer el mayor partido de los proyectos que emprendamos.

133

PARTE 2. BPM (BUSINESS PROCESS MANAGEMENT) Cap. 4. Qué es BPM. Cap. 5. Modelado de Negocios. Cap. 6. Modelado de procesos. BPMN

Capítulo 4. BPM (Business Process Management)

Capítulo 4. BPM (Business Process Management).

Qué es BPM Al igual que con la definición de procesos, existen numerosas definiciones de qué es BPM. Esto es debido en gran parte a que BPM es muchas cosas al mismo tiempo y abraza un gran número de prácticas, teorías de management y tecnologías, por lo que proporcionaremos una definición global de BPM como: “La metodología que orienta los esfuerzos para la optimización de los procesos de negocio de la empresa, en busca de la mejora de la productividad, la eficacia y la eficiencia de la misma por medio de la gestión sistemática de los procesos que deben ser modelados, automatizados, integrados, monitorizados y optimizados de forma continua”. Como creo que esta definición, es tan completa como extensa y para consolidar un poco más el término, proponemos algunas definiciones complementarias: -

BPM también puede ser visto como una filosofía de gestión que tomando como foco los procesos, propone la gestión, medición y mejora de los mismos para la mejora del rendimiento y la excelencia empresarial. 137


-

-

-

-

BPM es una estrategia para gestionar y mejorar la operativa de negocio mediante la mejora continua de los procesos de negocio que permite modelar, automatizar, ejecutar, gestionar, optimizar los mismos y medir los resultados. BPM es una filosofía de management que maximiza la agilidad de negocio, facilitando la planificación estratégica de los objetivos de negocio, la mejora continua de procesos y la aplicación de la tecnología. BPM es un conjunto de métodos, herramientas y tecnologías utilizados para diseñar, representar, analizar y controlar procesos de negocio operacionales, combinando las tecnologías de la información con metodologías de gestión por procesos. Para Johan Nelis, BPM es: “Alcanzar los objetivos de una organización a través de la mejora, la gestión y el control de los procesos esenciales de negocio”.

Como vemos, todas estas definiciones son una tautología, donde el núcleo duro, el objetivo último de BPM es la mejora de los productos y servicios que comercializa una empresa mediante una aproximación estructurada a la realización de mejoras, centrada en el diseño sistemático y en la gestión de los procesos de negocio.

Ciclo de Vida de BPM. El ciclo de vida de BPM es parecido al ciclo de vida de Six Sigma (DMAIC) que hemos visto anteriormente. Este ciclo de vida permite a las organizaciones crecer y evolucionar en sus procesos sobre la base de que los procesos deben cambiar, pues los negocios cambian, crecen y evolucionan. En BPM asumimos la realidad de que en los procesos de negocio y en los negocios de hoy en día, cada vez se involucran un mayor número de actores: distintas personas, agentes, partners, colaboradores y tecnologías, que implican la gestión de distintos tipos de relaciones persona a persona, sistemas a sistemas y personas a sistemas, por lo que la gestión de nuestros procesos debe involucrar todos estos tipos de transacciones. Las fases del ciclo de vida de BPM que seguiremos son: -

138

Diseñar: entender los procesos actuales y los sistemas de información involucrados para diseñar y mejorar los procesos que


-

-

-

reducirán los problemas actuales y prevendrán los futuros. Esta fase debe basarse en un análisis efectivo y definición clara de requerimientos e incluirá las reglas de negocio, los interfaces y enlaces con otros sistemas involucrados en los procesos. Modelado: la mejor forma de entender los procesos será mediante el modelado de los mismos y su simulación, donde analizaremos los escenarios posibles para analizar cómo estos afectan al resultado o salida del proceso. Ejecutar: implementar la solución en un entorno de producción. Monitorizar: monitorizar los procesos determinando que debemos monitorizar y medir en los procesos durante su ejecución: tiempos, costes, retrasos, rendimiento, etc. Optimizar: analizando los datos monitorizados, identificar posibles fuentes de problemas y mejoras sobre los procesos para trabajar en la mejora continua de los procesos.

Modelar

Ejecutar

Diseñar

Optimizar

Monitorear

BPM como paraguas de otras teorías: BPM retomará las teorías de gestión empresarial anteriores de autores como Taylor, Drucker, Hammer, Porter, Davenport, Demming y otros autores para hacer uso de los resultados alcanzados por la evolución en el desarrollo de los sistemas de información empresarial y construir un modelo 139


sobre el cual desarrollar los fundamentos de la organización y gestión empresarial, que poniendo el foco en la gestión de los procesos, permitirá el uso a través de ella de todo tipo de prácticas, métodos y teorías de gestión empresarial como puedan ser Six Sigma, TQM o Reingeniería, adaptándose perfectamente al uso de estas teorías, no porque haya sido diseñado para ello, sino porque al centrarse en los procesos ha resultado que todas estas teorías han encontrado en ellos una vía no sólo de expresión sino también de implementación. Vimos en el capítulo anterior como el propio Deming ya hablaba de la gestión por procesos como uno de los siete conceptos centrales de TQM y como Michael Hammer afirmaba que la gestión por procesos es el paraguas sobre el que TQM, Six Sigma y BPR podrían trabajar conjuntamente. Aunque BPM permita englobar a todas estas teorías, el catalizador principal y lo que constituyó el fundamento para el desarrollo y la adopción de BPM como disciplina, ha sido la capacidad de este no sólo de adaptarse a estas teorías según fuese necesario en distintos puntos de un proyecto, sino la flexibilidad y agilidad para adaptarse al cambio y aprovechar las oportunidades de mercado, al permitir la monitorización, la modificación y la mejora de los procesos en tiempo real.

BPM y los sistemas de Workflow: Además de las teorías anteriores, a nivel tecnológico los sistemas workflow se presentan como los herederos tecnológicos más naturales de las actuales plataformas de BPM, los BPMS. Los workflow utilizados para la automatización de procesos en donde los documentos, información o tareas se pasan de un participante a otro para que realicen alguna acción de acuerdo a un conjunto de reglas definidas en el flujo, han evolucionado hasta las actuales plataformas de BPM que incluyen a estos sistemas de workflow en una visión mucho más amplia. Aunque visualmente las herramientas de workflow y los sistemas BPM puedan resultarnos parecidas, BPM es mucho más que un workflow y muchas veces se les considera una evolución de estos sistemas a los que se les han añadido las funcionalidades de las que estos carecían: -

140

Soporte no sólo para personas sino también integración con aplicativos y web services. Las soluciones de workflow se limitaban al flujo de tareas realizadas por personas y documentos.


-

Incorporación de un motor de reglas de negocio. Arquitectura web. Ejecución paralela. Ejecución dinámica. Capacidad de simulación. Estándar en la notación: BPMN. Lenguaje BPEL para transformar el modelado en aplicaciones ejecutables.

Como hemos visto en capítulos anteriores, la gestión por procesos no es algo nuevo y antes del advenimiento de BPM a principios del siglo XXI, ya se usaban los procesos, sin embargo, su uso se limitaba a la mera representación de los mismos para mejorar la comprensión y el entendimiento de los procesos por parte de las personas que participaban en su diseño. Era un uso a nivel de comunicación, sin las capacidades de gestión, monitorización y control que tenemos actualmente en BPM.

Componentes principales de BPM Tradicionalmente, los componentes sobre los que se basa BPM son: Procesos, Personas y Tecnología.

Sin embargo en este libro y siguiendo a Johan Nelis, añadiremos un cuarto componente: la gestión de proyectos. Si en BPM analizamos y estudiamos los procesos como cíclicos y repetibles, cuando hablamos de implementar BPM hablaremos de un proyecto, que como tal, será único, con un inicio y un final y en el que reuniremos recursos durante un periodo de tiempo determinado para conseguir un propósito determinado. El uso de esta metodología de gestión de proyectos será sobre la que se asienten los procesos, las personas y la tecnología para el éxito de nuestro proyecto BPM.

141


Partiendo del axioma que el éxito de cualquier proyecto radica en su correcta gestión, los proyectos BPM son también proyectos que deben ser gestionados de forma metodológica. Los proyectos de BPM, por involucrar a personas, procesos y tecnologías, son proyectos complejos y sin una correcta gestión del proyecto, más allá de los aspectos directamente relacionados con BPM, será difícil conseguir el éxito en su implementación. Por su importancia, trataremos los aspectos relacionados con la gestión de proyectos y la metodología del PMI (Project Management Institute) en el Capítulo 7 dedicado a la implementación de proyectos BPM. Johan Nelis ilustra la importancia de la gestión de proyectos en BPM como un taburete de tres patas (procesos, personas y tecnología), en el que la gestión de proyectos representa el sustento para las tres patas del taburete y sin la cual todo el proyecto se derrumbaría.

Otros autores y/o empresas amplían este número de elementos principales a otros aspectos no menos importantes y relevantes como son: -

-

142

La estrategia: pues de esta partirá el diseño y mejora de nuestros procesos y marcará todo el ciclo de vida de estos, por lo que siempre deberemos velar por el correcto alineamiento de esta estrategia con nuestros procesos para pasar de la gestión de procesos a la gestión por procesos. Gobernanza: la cual establecerá los roles y responsabilidades en la ejecución y seguimiento de los procesos. Métodos: el conjunto de métodos, técnicas y herramientas que nos permitirán el desarrollo de las actividades a lo largo del ciclo de vida de los procesos como las herramientas de modelado de procesos, Six Sigma, TOGAF, etc.


-

Cultura: asociada a la empresa y su orientación a procesos y que se ha demostrado como de vital importancia para el éxito de los proyectos de BPM.

No discutiremos cuales son más o menos importantes, desde luego que todas lo son y tal vez los elementos primeros: procesos, personas y tecnologías puedan y deban ser siempre tenidos en cuenta, pero sin obviar al resto de elementos que deberán también ser considerados, dependiendo de la organización y del proyecto en que trabajemos, sabiendo que son igual de importantes, aunque por “ligereza”, consideremos los tres básicos como centrales y serán los que describamos a continuación con más detalle.

Procesos: Para el éxito de un proyecto de BPM debemos reconocer la importancia de los procesos dentro de la organización, la necesidad de su correcto diseño y medición de su operativa para poder afrontar la posterior mejora de los mismos. Aunque variando el alcance y el punto de vista utilizado, muchos de los términos y teorías de la gestión por procesos vistos en el Capítulo 1 forman parte también de BPM en la medida en que BPM trata principalmente sobre la gestión de procesos de negocio. Si en el Capítulo 1 nos centramos únicamente en el enlace entre las actividades realizadas por personas y sistemas para proporcionar una salida que aporte valor al cliente, en BPM proporcionamos un marco de trabajo a partir de una estrategia y orientación hacia la mejora continua a través de la optimización de sus procesos de negocio, siguiendo un ciclo de vida de modelado, ejecución y medida de los procesos y en consecuencia, elevaremos BPM a la categoría de disciplina de gestión. Bajo una perspectiva más amplia que la vista para la gestión de procesos, trabajaremos a partir de ahora con la definición de un proceso de negocio como una serie de actividades realizadas para implementar una estrategia o alcanzar un resultado u objetivo empresarial.

143


Personas: Las personas serán sobre las que se sustenté el proyecto y marcarán el grado de éxito del proyecto antes, durante y después de su implementación. La importancia de las personas radica en que éstas serán los usuarios del proyecto y como es lógico, todo el esfuerzo realizado en el proyecto no tendrá sentido si finalmente los usuarios no utilizan y ejecutan las tareas y operaciones especificadas en el proceso. Más aún, en BPM no sólo necesitaremos de su compromiso para ejecutar estas tareas con diligencia y responsabilidad, sino que buscaremos su implicación en los resultados del proceso y del proyecto desde las fases más tempranas del mismo para colaborar, participar y recompensar el trabajo en la búsqueda de soluciones y mejoras de los procesos. El compromiso de las personas de nuestro equipo, será el principal atributo capaz de realizar la transformación de la visión en un proyecto real con resultados. Los proyectos de BPM no son proyectos sencillos y tienen asociado un fuerte componente de cambio y de nuevas formas de hacer las cosas dentro de las organizaciones en que se implanta, por lo que será necesaria una actitud proactiva frente a búsqueda de soluciones y mejoras y no reactiva a la espera de que surjan los problemas o el proyecto fracase. Otro aspecto característico e importante en los proyectos de BPM es el de la colaboración entre el personal de negocio y el personal de TI en los proyectos. En los proyectos de BPM pueden y deben colaborar conjuntamente la gente de negocio y de tecnología para producir procesos de negocio más eficientes, ágiles, veloces y transparentes. BPM unifica los departamentos de negocio y tecnología para trabajar conjuntamente entorno a los procesos de negocio de la empresa, de forma que ambos colaboren en el diseño, implementación, análisis y optimización de los procesos de negocio. Esta colaboración se producirá principalmente a través de la herramienta de modelado de procesos y por la compartición de un lenguaje de notación de procesos entendible tanto para los perfiles técnicos como de negocio, de forma que ambos puedan colaborar en el diseño, el análisis y mejora de procesos y pudiendo desde la propia herramienta de modelado implementar estos procesos sin necesidad de conocimientos de programación. Sobre esta herramienta de modelado, podemos establecer las reglas de negocio que regirán el comportamiento de los procesos, establecer los indicadores y medidas sobre los procesos y los datos y valores asociados a los mismos para posteriormente ser evaluados para analizar su eficacia y una vez analizados, aprobados y puestos en producción, poder ser monitorizados y controlados a través de la misma herramienta. 144


Esta colaboración entre los perfiles de negocio y de TI para alinear negocio y tecnología para la consecución de los objetivos y el cumplimiento de las estrategias empresariales, proporcionará una nueva dimensión llena de posibilidades para reducir el histórico gap existente entre estos dos aspectos de la empresa y será una de las claves fundamentales sobre las que se basarán los proyectos de BPM.

Tecnología: La tecnología por sí sola no implica la mejora en la gestión empresarial ni en la gestión de procesos de negocio, en la competitividad o en los resultados empresariales. Esta tecnología deberá estar alineada con el negocio y de ahí que BPM adopte este alineamiento como punto de partida para todas sus iniciativas de mejora de los resultados empresariales a través de los procesos de negocio como hilo conductor. En los proyectos de BPM no seguiremos el camino directo de implementar las TI “a machete” para la mejora del negocio, repitiendo errores del pasado en la implantación de TI sin considerar los aspectos de negocio ni la colaboración con el personal de esta área de conocimiento de la organización. En BPM, sin perder la perspectiva tecnológica, alinearemos previamente las soluciones de TI con los aspectos de negocio, no sólo para la optimización y rentabilización de nuestras inversiones en TI, sino para que estas hagan lo que deben hacer: dar soporte y mejorar los modelos y estrategias de negocio. Este camino es el ilustrado en el siguiente gráfico.

BPM es una disciplina basada en pensar primero en como ejecutar correctamente los procesos y objetivos de negocio para posteriormente utilizar la tecnología para automatizar y controlar los procesos diseñados. Esto 145


implica que la tecnología será imprescindible para BPM y si ella no podrá realizarse BPM. A menudo se dice que un proyecto BPM es un 60% estrategia y un 40% tecnología. Las herramientas tecnológicas que posibilitarán BPM son los BPMS (Business Process Management Systems), que serán las herramientas tecnológicas que herederas de los avances en tecnologías de la información, de la orientación a procesos y del entendimiento de estas como necesarias para alcanzar los objetivos y estrategias empresariales, nos permitirán modelar, automatizar, gestionar, medir y mejorar los procesos de negocio. Los BPMS nos facilitarán las necesarias tareas de integración con los sistemas ya existentes en la empresa: ERP, CRM, etc. sin necesidad de reemplazar la infraestructura de TI existente en nuestra empresa ni realizar modificaciones sobre estos sistemas, por lo que minimizamos en consecuencia el impacto económico de los cambios producidos por los proyectos de BPM. Tal vez la característica visualmente más atractiva de los BPMS es que al igual que hace unos años teníamos los sistemas WSIWYG (What You See Is What You Get) en las Suites para desarrollo de aplicaciones informáticas, con BPM tenemos WYMIWYR (What You Model Is What You Run), pues no sólo tenemos el modelo de proceso y la posibilidad de evaluar y analizar su comportamiento, sino que además podemos ejecutarlo y modificarlo en un entorno visual tantas veces como queramos, sin necesidad de crear un nuevo proyecto informático para cada cambio o modificación en nuestras necesidades de negocio.

Principios, prácticas y ventajas de BPM. Como espero que el lector descubra a largo del presente libro, BPM ofrece a las organizaciones de cualquier tipo de una completa disciplina para la mejora de los resultados empresariales. Como hemos visto en las estrategias de reducción de costes, la evaluación de una empresa a partir del análisis de los resultados financieros, suele ser comparado como conducir mirando constantemente por el espejo retrovisor, observando por donde ya hemos pasado. La perspectiva de BPM es más parecida a encender los focos de nuestro coche para visualizar el camino por el que deberemos ir, y donde estos focos que iluminan el camino serán representados por la búsqueda de la excelencia, la eficiencia y la mejora de procesos. Pero para poder encender estos focos, deberemos entender primero los principios sobre los que se asienta BPM y las ventajas que esta disciplina pueden aportar. 146


Principios de BPM: -

-

-

-

-

-

-

Los procesos son los activos más importantes de nuestra empresa y crean valor a nuestros clientes lo que justifica su existencia en la empresa. Las empresas deben invertir en los procesos como la hacen en otros activos de la empresa. Midiendo, monitorizando, controlando y analizando los procesos de negocio, una empresa puede dar valor a sus clientes de forma continua y dispondrá de la base para la mejora de procesos y su reutilización. Es necesaria la involucración de la gente de negocio y no sólo de TI, en el diseño de soluciones de automatización y mejora de procesos. La simulación del comportamiento de los procesos ayuda a la optimización de estos. BPM lo podemos usar para mejorar procesos, optimizar nuestras inversiones en TI, implementar arquitecturas SOA o transformar el negocio. Al igual que en TQM y Six Sigma, cuando los procesos son monitorizados, podemos identificar las variaciones que producen inconsistencias. Puesto que los procesos son activos clave de la empresa, estos deben ser gestionados y mejorados constantemente para proveer valor continuamente a los clientes. Las TI son esenciales para implementar BPM, al proveer de información en tiempo real de la operativa de los procesos.

Prácticas de BPM: -

Buscar una estructura de la organización orientada a procesos: una organización proceso céntrica es aquella que reconoce la centralización de sus procesos para la mejora de su negocio, los valora, invierte en ellos y los mejora constantemente. En una organización orientada a procesos los empleados son parte de los procesos y la meta de la organización orientada a procesos es crear valor a sus clientes. 147


-

-

-

-

Los proyectos más exitosos de BPM resultan cuando estos son alineados con las metas y objetivos de la empresa. Una vez que conocemos estas metas y objetivos es posible determinar los procesos que mejor se alinean con ellos para luego diseñarlos, implementarlos y gestionarlos con BPM. Para conseguir este alineamiento es necesaria la implicación de la alta dirección de la empresa que debe apoyar y dirigir la ejecución estos proyectos. Utilizar una aproximación bottom-up para identificar los procesos, tener en cuenta a los empelados desde el primer momento nos ayudará a que el proyecto sea más exitoso al haber diseñado desde el principio los procesos con estos trabajadores que tras la implementación deberán mantener los procesos y participar en su mejora. Establecer quiénes son los responsables de los procesos. Trabajar en colaboración con los partners de negocio, proveedores y colaboradores, conscientes de que los procesos atraviesan no sólo a nuestra organización, sino que también traspasan los límites de esta. Además de involucrar a los empleados, velar por su formación y preparación constante, será clave para el éxito del proyecto. Alinear las recompensas a empleados con la realización de los procesos. Utilizar tanto metodologías incrementales (Six Sigma) como radicales (BPR) para implementar la mejora de procesos. Diseñar los procesos alrededor de las salidas de los mismos y no de las tareas. Corregir y mejorar los procesos antes de automatizarlos. Estandarizar procesos en la empresa.

Ventajas de BPM: Con BPM y las tecnologías que le dan soporte, los BPMS (Business Process Management Suites) podremos: -

148

Modelar los procesos de nuestra organización abarcando la cadena de valor y coordinar los roles, personas, sistemas y recursos que participan en los mismos. Ganar en visibilidad de los procesos.


-

-

-

-

Mayor flexibilidad y agilidad para adaptarse al cambio. Integrar información de distintas fuentes. Dirigir los esfuerzos de la empresa de forma planificada y alineada con los objetivos y estrategias empresariales. Reducir costes. Cuando los procesos son eficientes, estos ven reducido el coste requerido para obtener las salidas del proceso. Mejorar la eficiencia. Mediante la reducción de las pérdidas de tiempo, mano de obra o exceso de trabajo en el funcionamiento del proceso. Mejorar la satisfacción de clientes. Ejecutando nuestros procesos de forma más rápida, eficiente y efectiva, los clientes recibirán no sólo mejores productos y servicios, sino también una mejor experiencia de compra. Integrar sistemas de información y aplicativos externos y de terceros. Ejecutar y convertir los modelos en aplicaciones ejecutables. Monitorizar y realizar el seguimiento y control del rendimiento de los procesos en base a indicadores. Controlar y responder a eventos de procesos dependiendo de las distintas situaciones.

Estas funcionalidades proporcionarán importantes ventajas a distintos perfiles de la empresa, que sin BPM serían difíciles de lograr: -

-

-

-

Directores de TI: de forma que estos puedan aplicar sus habilidades y recursos de forma más directa en las operaciones de negocio. Directores de negocio: que podrán más directamente controlar y responder a todos los aspectos de los procesos de negocio, acortando el “Gap” existente entre negocio y TI y en consecuencia, hacer que los sistemas respondan de forma más eficiente a los requerimientos de negocio. Empleados: que podrán alinear mejor sus esfuerzos y mejorar su productividad y rendimiento, al disponer de medidas y resultados visibles de las tareas que ejecutan asociadas a los procesos globales de la empresa y en las que han participado desde el inicio en la definición de estas tareas, de los procesos de las que forman parte y en la mejora de su eficiencia y rendimiento. La empresa en general: podrá responder más rápido a los cambios para cumplir sus objetivos de negocio. 149


La adopción de BPM como disciplina y la implementación de soluciones BPM es utilizada dentro de las organizaciones para: -

-

-

-

-

Ganar en eficiencia, reducción de costes, reducir los ciclos de proceso, eliminar o reducir la entrada manual de datos y los errores provocados por estas entradas manuales así como la eliminación de costes rutinarios a través de la automatización de los procesos de negocio. Mejorar el diseño de productos. Desarrollar productos más innovadores y mejorar la calidad de estos, haciendo uso de las herramientas de simulación de BPM para comprobar su eficiencia y comportamiento y asegurándonos de que nada falle antes de su lanzamiento. Mayor efectividad en nuestras operativas de negocio. Las empresas ven que pueden incrementar beneficios si mejoran sus procesos o crean un nuevo proceso que les ahorre costes y aumente el beneficio y la satisfacción de sus clientes. Alinear procesos y TI optimizando la inversión en estas últimas y racionalizando los sistemas informáticos de la empresa para trabajar en base a procesos y objetivos de negocio. Poder trabajar realmente en la mejora continua de procesos. Ganar en agilidad, aumento de productividad y competitividad, alcanzar el liderazgo en productos y servicios, aumentar la velocidad en la creación e implementación de nuevos procesos y modelos de negocio y mayor alineamiento de los mismos con los procesos ya existentes.

Aunque son muchas las ventajas que podemos obtener de la adopción de BPM, el lector irá configurando su propio cuadro de ventajas a medida que profundicemos en los detalles de BPM y su implementación y adaptando éstas a las particularidades de cada organización para aprovechar las distintas posibilidades que BPM pueda ofrecerles.

Reducir el Gap entre tecnología y negocio. En su libro “Business Process Management: The Third Wave, Peter Fingar y Howard Smith decían: “Don´t bridge the business-IT divide, obliterate it”, que traducido de forma libre viene a significar: “No establezcas un 150


puente entre el negocio y las TI, elimínalo”. Esta frase produjo que algunos profesionales de TI lo considerasen una ofensa, interpretando que esto significaba hacer desaparecer las TI, cuando lo que realmente pretendían decir los autores y que explicaron en un artículo posterior, es que eliminemos el puente que divide el negocio y las TI. El reducir este distanciamiento, será uno de los objetivos y características principales sobre las que se basarán los proyectos de BPM. Esta división entre negocio y TI ha prevalecido desde las primeras implantaciones informáticas hasta nuestros días. Estas implementaciones de TI tradicionales en las que los analistas de TI y los de negocio vivían en mundos paralelos pero distintos y en la que unos dicen lo que hay que hacer y otros lo traducen a código ejecutable, se encuentran cada vez más alejadas de la realidad. Las empresas no quieren tecnología, sino resultados de negocio y esto es algo que tanto el personal de negocio como el de TI tienden a olvidar, centrándose cada uno en sus respectivos mundos y preocupados por sus propios resultados individuales más que por los resultados globales de la empresa. Con BPM la contribución de las TI debe ser distinta a la tradicional, en la que los analistas de TI capturan los requerimientos tecnológicos, pasando por alto los requerimientos de negocio. Los sistemas de información representan un importante papel en la gestión de las empresas y organizaciones en la actualidad y cada vez más actividades de negocio se basan en estos sistemas para ser ejecutados. Ambos mundos: el de negocio y el de TI, deben aliarse, entenderse y comprenderse para trabajar conjuntamente en las soluciones y problemas empresariales y al igual que en la innovación, el problema no estará en cómo abordar y desarrollar nuevas ideas, sino en cómo olvidar las viejas y conseguir que ambos perfiles comprendan y asuman este necesario acercamiento. Hoy no concebimos una empresa en la que el negocio pueda ir por delante de la tecnología o viceversa. Si el negocio va por delante y la tecnología no le acompaña, difícilmente el negocio alcanzará los resultados esperados y de igual manera, si la tecnología va por delante y el modelo de negocio no le sigue, resultará en un despilfarro y desaprovechamiento de una oportunidad tecnológica y en cualquiera de los casos, se producirá un “Gap” entre lo que el negocio quiere y como las TI implementan lo que el negocio quiere.

151


Esta situación es similar a la conocida en el mundo del desarrollo software en la toma de requisitos, donde lo que los clientes tienen en mente no suele coincidir con la imagen de la solución según la entienden los programadores y que tantos problemas, revisiones, depuraciones, reespecificaciones y retrasos provocan en los proyectos de software.

Peter Fingar hace referencia a los programadores, que haciendo uso de lenguajes no entendibles por el personal de negocio, como puedan ser Cobol, C++, Java o UML, pertenecen a una época totalmente alejada de la realidad actual de los negocios, en la que estos lenguajes y metodologías de abstracción, no facilitan ni provocan el acercamiento entre TI y negocio. Michael Hammer iba un poco más lejos y decía que los profesionales de TI estaban demasiado enfrascados dentro del mundo de los sistemas, sin ser capaces de reconocer nuevas oportunidades, enfatizando más lo que no se puede hacer que lo que se puede hacer y recomendaban apartar a estos profesionales de TI de las primeras fases en el diseño de procesos de negocio. Recientemente, David Chappell afirmaba en una entrevista: “Creo que en los próximos años, muchas personas trabajando en TI deben involucrarse en los procesos de negocio de forma mucho más explícita, sino, mejor que hagan sus maletas y se vayan a Bangalore en India”. La aceleración de nuevas y diferentes formas de hacer negocio, cada vez más basadas en la tecnología, la comunicación, la colaboración y el intercambio de datos entre empresas y donde prima la velocidad y la automati152


zación de actividades frente al desempeño manual de las mismas, hace necesaria la coordinación entre personas, recursos y sistemas de información y con ellas una adaptación a nuevas estructuras y modelos de forma ágil para poder mantenerse en los mercados. Independientemente de la existencia de negocios basados exclusivamente en la tecnología o “pure players”, el reducir el Gap entre negocio y tecnología es cada vez más necesario en la medida en que el entorno en el que se desarrollan los negocios es cada vez más cambiante a la vez que basado en la tecnología. No podemos dejarnos llevar por la tecnología y perder el foco en los aspectos de negocio, por el contrario, debemos extraer de la tecnología el verdadero valor que debe aportar y ponerla al servicio del negocio, sea este la explotación de una nueva tecnología o el comercio de plantas ornamentales. En este camino, los negocios no pueden encontrar trabas y cuellos de botella a su desarrollo en los sistemas informáticos (vitales para la consecución de estos objetivos), donde cada cambio o modificación en los sistemas de información es costosa, requiere tiempo y no siempre es capaz de traducir los requerimientos de negocio de forma ágil y veraz. BPM busca eliminar ese GAP involucrando a los directivos de negocio y personal de TI en el diseño conjunto de los procesos de negocio y de las soluciones tecnológicas que soportarán estos procesos y proporciona el marco para conjuntar la forma en que se relacionan el negocio y la tecnología y reducir lo que la consultora Gartner denomina el “Gap de Rigidez”.

Con BPM podemos reducir este Gap entre lo que el negocio necesita y lo que las tecnologías de la información son capaces de proporcionar a estos 153


requerimientos de negocio, poniendo al personal de negocio y de TI a analizar, diseñar, implementar y monitorizar conjuntamente los procesos de negocio, haciendo uso de la metodología de BPM, de sus herramientas de modelado, que pueden ser entendidas tanto por personal técnico como de negocio, de forma que ambos puedan colaborar conjuntamente en la diagramación y diseño de procesos, en su implementación, monitoreo y mejora a través de las plataformas de gestión de procesos (BPMS). De esta forma, BPM permitirá que los negocios sean gestionados por quienes tienen el conocimiento de los negocios, para desde su definición, realizar de forma ágil y flexible, la informatización, automatización y los cambios necesarios sobre los sistemas para dar soporte en todo momento a las necesidades de mercado y requerimientos de negocio y clientes.

Cuándo implementar BPM Los objetivos y motivaciones por las que una empresa adopta la disciplina de BPM pueden ser muy distintos. Algunas empresas lo harán centrándose en la eficiencia que supone el poder ejecutar sus actividades y procesos de negocio con objeto de conseguir los mismos resultados con menos recursos de tiempo, materiales o económicos. Otras empresas lo harán con objeto de conseguir mayor agilidad y capacidad de respuesta al cambio, o por pasar de una operativa funcional a una basada en procesos. Sea por estos u otros motivos, existen multitud de situaciones en los que la adopción de BPM puede ayudar a las empresas a alcanzar sus objetivos. Entre estos posibles escenarios podemos citar los siguientes: -

154

Cuando existe un alto volumen de tareas simultáneas y repetitivas. Necesidad de hacer muchos cálculos en tiempo real. La existencia de tareas críticas en el tiempo. Tareas o transacciones que necesitan ser accesibles por varios participantes y/o sistemas al mismo tiempo. Fusiones o adquisiciones de empresas, en las que se suele necesitar conjugar procesos de varias organizaciones. Reorganización de empresas o cambios en la dirección operacional. Cuando los objetivos y metas de la empresa no son alcanzados. Cumplimiento de nuevas normas o regulaciones: Sarbanes, Basel II, RSC (Responsabilidad Social Corporativa), etc.


-

-

La necesidad de dar mayor agilidad al negocio para responder a cambios y oportunidades. Necesidad de mayor control en operaciones y procesos. Necesidad de maximizar el ROI y las inversiones en TI. Necesidad de ajustes debidos a recortes en los presupuestos. Necesidad de aumentar las capacidades del personal para el desempeño de sus tareas. Falta o poca calidad en los productos y servicios. Falta de procesos de negocio y métodos estandarizados. Ante la introducción de un nuevo software, arquitectura de TI, nuevas inversiones en tecnología o cuando estas no producen los resultados esperados o sus costes están fuera de control. Ante la Introducción de arquitecturas basadas en web services, cloud computing o SOA, para racionalizar los procesos, como paso previo y necesario a este tipo de implementaciones tecnológicas si queremos racionalizar y sacar el máximo provecho de las mismas.

El Modelo de Madurez para la gestión de procesos. Muchas organizaciones emplean los modelos de madurez (Maturity Models) para comprobar como de bien sus organizaciones gestionan sus procesos. Uno de los modelos de madurez más populares es CMMI (Capability Maturity Model Integration), el cual identifica cinco niveles de madurez, sugiriendo en que tareas deben enfocarse en sus siguientes pasos las empresas para avanzar en este modelo de madurez. CMMI fue inicialmente un modelo para la mejora de los procesos de desarrollo software. Este modelo definía cinco estados, a través de los cuales, una organización podía pasar de un modelo inmaduro, a un modelo maduro en el desarrollo de software, permitiendo a las organizaciones definir en qué punto se encuentran y ayudarles a llegar al estado en el que les gustaría estar. Basándose en el modelo del CMMI, el OMG (Object Management Group) desarrolló el BMM (Business Maturity Model) para guiar a las organizaciones en la Gestión por Procesos. Este modelo puede ser seguido como guía por las empresas y organizaciones de cualquier tipo para identificar el

155


estado en que se encuentran en cuanto a la gestión de sus procesos y ayudarles a madurar en la gestión y la mejora de estos.

Los 5 niveles de madurez del BMM. Al igual que en CMMI y prácticamente todos los demás modelos de madurez, el BMM se divide en 5 niveles que representan los diferentes estadios a través de los cuales una organización mejora en sus capacidades de gestión de procesos. Estos niveles son los indicados en el siguiente gráfico:

Nivel 1. Inicial (Initial): Los procesos de negocio son implementados de forma inconsistente, algunas veces de forma “ad hoc”, con resultados que son difíciles de predecir. El alcance de las iniciativas de BPM es muy limitado, los empleados están poco involucrados en la gestión por procesos y la empresa tiene pocos procesos automatizados. Aunque existan algunos procesos automatizados, se actúa de forma reactiva, “apagando fuegos” cuando estos aparecen, más que controlando los procesos de forma proactiva. En este primer nivel, los procesos existentes no son medidos para evaluar su calidad y necesidades de mejora y el éxito en estas organizaciones depende de las competencias y esfuerzos individuales de personas de la organización y no de la eficacia y eficiencia debida a procesos bien diseñados. 156


Nivel 2. Gestionada (Managed): La empresa consigue estabilizar el trabajo dentro de una unidad de trabajo o departamento, asegurando que el trabajo pueda ser realizado de forma repetitiva y cubriendo las exigencias del grupo o departamento en el que se implanta. Sin embargo, unidades de trabajo dentro de la organización que realizan tareas similares, pueden estar usando diferentes procedimientos a los de estas unidades. En esta fase las empresas reconocen la importancia de BPM, se automatizan procesos principalmente relacionados con la gestión documental en las unidades de trabajo que se involucran en la gestión por procesos y adoptan metodologías y el uso de estándares. Nivel 3. Estandarizada (Standarized): Se estandarizan y sintetizan los procesos con los procedimientos y prácticas identificadas en las unidades de trabajo del nivel anterior. Estos procesos estandarizados pasan a proveer de economías de escala y la base para aprender y mejorar. Nivel 4. Predecible (Predictable): Las capacidades de los procesos estandarizados son explotadas e integradas en las unidades de trabajo. Los procesos son manejados estadísticamente siguiendo el workflow de los mismos para entender y controlar las variaciones de forma que las salidas de los procesos pueden ser predichas de los estadios intermedios. Nivel 5. Innovación (Innovating): En este último nivel, la empresa busca innovaciones que acorten el GAP entre las actuales capacidades de la empresa y las capacidades para alcanzar sus objetivos de negocio. Cada nivel de los anteriores, está diseñado para alcanzar objetivos concretos e incluyen para cada uno de ellos las mejores prácticas para indicar qué se debe realizar en cada nivel. Aunque se describe el estado a alcanzar en cada nivel, este modelo permite que cada organización pueda definir sus propios métodos para alcanzar los objetivos en cada uno de los niveles. El sentido de este modelo de madurez en la gestión por procesos es que a medida que una organización asciende en los niveles de madurez, la infraestructura y la cultura de la empresa se vayan transformando para dar soporte a los métodos y prácticas establecidos en cada uno de los niveles y 157


alcanzar mayores niveles de madurez y excelencia en la gestión de sus procesos de negocio. Excepto para el nivel 1, para el resto de niveles en el BMM, se describe en la especificación del OMG, el propósito de cada nivel, las metas que se persiguen y las buenas prácticas que la empresa necesita implantar para alcanzar las metas y propósitos establecidos en cada fase. Para avanzar en los niveles de madurez en la gestión de procesos, nuestra empresa debe ser capaz de implementar las prácticas asociadas a cada nivel para alcanzar los objetivos del mismo, moviéndonos de los niveles de inmadurez e inconsistencia en la gestión de procesos, a niveles de madurez y disciplina de forma incremental a través de los cinco niveles, de tal manera que cada nivel sienta las bases para poder alcanzar el siguiente nivel. El BMM es un magnífico modelo que debemos considerar a la hora de iniciar cualquier proyecto de gestión por procesos, de mejora de los mismos o proyecto de BPM y puede ser usado por las organizaciones para: -

Describir el estado de cómo está nuestra organización, sus fortalezas y debilidades en relación a la gestión por procesos. Prescribir el camino que debemos seguir para avanzar en la gestión por procesos y la mejora de los mismos. Comparar el estado de nuestra organización respecto a estándares y a otras organizaciones y como herramienta de benchmarking.

Los principios sobre los que se basa el BMM son: -

-

-

158

Los atributos de los procesos pueden ser evaluados para determinar la capacidad de los mismos y para contribuir a los objetivos organizacionales. Los procesos no pueden sobrevivir en la organización a no ser que esta sea suficientemente madura como para soportarlos. La mejora en procesos se realiza mejor dentro de un programa de cambio de la empresa, en el que sucesivamente se alcancen nuevos estadios de predictibilidad. Cada estadio o nivel de madurez requiere de una base en su estadio anterior sobre la cual construir las futuras mejoras.


La organización Orientada a Procesos. Una organización orientada a procesos es aquella que, siguiendo los principios de BPM, reconoce la importancia de los procesos para su negocio, se ocupa de la gestión de los mismos y los trata como activos de la empresa que deben ser cuidados, mantenidos y gestionados correctamente, consciente de que es su objetivo último, crear valor a sus clientes a través de los procesos que ejecuta. Una de las causas principales de la insatisfacción de los clientes y sobre la que no siempre solemos reparar, es la debida a la falta de comunicación entre los departamentos de nuestra empresa. La experiencia final de nuestros clientes está basada en muchas transiciones y actividades distintas que atraviesan la empresa, y este flujo, continuo o discontinuo, eficiente o ineficiente, no es percibido por el cliente, ni tiene porque ser comprendido por él. Al cliente no le importa si no nos hablamos con el departamento financiero o si los departamentos de marketing y de servicio técnico tienen una visión distinta sobre cómo solucionar sus problemas. El cliente, sólo quiere el mejor servicio, calidad y atención a sus problemas y demandas. A ninguno de nosotros nos interesan los procesos internos que debe recorrer nuestra solicitud a un banco cuando pedimos un préstamo, lo que queremos es una rápida respuesta a esa solicitud, para poder tomar nuestras decisiones. Para conseguir esta orientación al cliente, precisaremos del compromiso y la cooperación de todos los departamentos y unidades de negocio de la empresa, trabajando de forma alineada y orientada, hacia la prestación del mejor servicio y no cuando estas áreas funcionales están más inmersas en sus pequeñas parcelas, con trabajadores centrados exclusivamente en sus tareas atómicas y comprometidos con mantener sus estatutos y privilegios que en los procesos globales de la empresa que son los que finalmente darán respuesta a las necesidades y expectativas de sus clientes. La gestión por procesos y BPM implicarán analizar las organizaciones desde un punto de vista funcional, entendiendo estas como un conjunto de procesos vinculados entre sí y superando la imagen departamental a la que estamos acostumbrados. Esta organización funcional no presentará la orientación a clientes requerida separando drásticamente en unidades funcionales la secuencia de actividades para añadir valor y los adecuados niveles de servicio a nuestros clientes. Para proveer de estos niveles de servicio a clientes resultará mucho más lógico tomar una perspectiva entorno a la secuencia de actividades que van añadiendo valor y hacen avanzar al proceso desde el proveedor al cliente. Para conseguir esta orientación, las organizaciones de 159


todo tipo deben reconocer la necesidad de alinear a los trabajadores de todos los niveles y departamentos con la estrategia de la organización, de forma que entiendan su trabajo y como este contribuye a los resultados de la compañía, visualizando no las pequeñas parcelas de trabajo sino el “Big Picture” de toda la empresa. Comenzamos así a ver la organización de forma holística (el todo es más que la suma de las partes), pasamos a pensar en la empresa en términos de sistemas, procesos de negocio y cadenas de valor, más que en departamentos aislados. Esta visión tendrá implicaciones en las estructuras organizacionales y en los trabajadores de la empresa, los cuales no deberán pensar en cómo realizar mejor las tareas que actualmente realizan, sino en por qué y para quien hacen ese trabajo, pues la satisfacción del cliente y la eficiencia del proceso, vendrá determinada por la coherencia en el desarrollo del proceso completo y no en la de cada una de sus partes constituyentes por separado. Las organizaciones también deberán abordar cambios en sus estructuras en la adopción de esta visión, en la que la importancia del proceso en su conjunto es mayor que la organización que los sustenta y muchas veces, esta estructura organizacional no coincidirá o será la más apta para el desarrollo del proceso, por lo que con frecuencia deberemos rediseñar y reunificar las actividades del proceso que fueron fragmentadas por la propia estructura de la organización.

Empresa funcional vs. Orientada a procesos. Las empresas tradicionalmente se han organizado en torno a departamentos basados en las funciones que realiza cada uno de ellos y dirigidos por directivos especializados en las áreas de conocimiento necesarias para el departamento que dirigen. Estas organizaciones herederas de las teorías de Adam Smith y que han sobrevivido por más de 200 años, se asientan sobre el organigrama de la empresa como modelo funcional del negocio. Este tipo de organización empresarial divide la organización en departamentos o silos funcionales, cada uno de los cuales dispone de sus propios recursos, presupuestos y objetivos, independientes de los de otros departamentos y donde las tareas y responsabilidades de cada departamento se encuentran perfectamente definidas.

160


Esta forma de ver la empresa se conoce también como pensamiento o cultura de silos y es la generadora de que los trabajadores asignados a departamentos de la empresa se pregunten: “¿Por qué debería ocuparme de lo que hacen los otros, cuando ya tengo bastantes problemas con lo mío?”. De esta cultura se deriva el considerar a unos departamentos más importantes que otros (generalmente al que nosotros pertenecemos), cuando la realidad es que todos los departamentos dentro de la empresa son importantes; los de ventas, suelen pensar que son ellos la pieza fundamental que sostiene la empresa, pero si otros departamentos no fabrican, distribuyen y prestan servicio a los clientes, el castillo se desmoronará y los clientes no recibirán el valor esperado de la función de ventas. Suele ocurrir que estos departamentos que se consideran insustituibles, son los que más pegas ponen a la implementación de la gestión por procesos y generalmente aquí radica el principal problema para llevar a delante las iniciativas de BPM: las personas y su actitud ante el cambio, por lo que al igual que para conseguir muchas de las innovaciones en las empresas, en ocasiones no nos quedarán más remedio que seguir las estrategias del palo o de la zanahoria para recompensar la adaptación al cambio. Las organizaciones funcionales presentan ventajas respecto a las orientadas a procesos como la concentración del saber hacer, la máxima eficiencia y los menores costes dentro de cada departamento. Sin embargo, como comentaba Rummler de forma muy visual, en este tipo de organizaciones funcionales y más concretamente en sus organigramas, veía el flujo de informes y responsables, pero no veía al cliente en esos organigramas, ni el 161


flujo necesario entre los distintos departamentos que componen la empresa para proveer de valor a ese cliente. Además y como ya hemos visto, los sistemas informáticos dentro de estas estructuras funcionales, generalmente proveen de soluciones para estos departamentos, muchas veces sin integración o comunicación con otros departamentos, lo que complica e interfiere todavía más con el cliente.

La realidad es que para ejecutar un proceso de negocio (por ejemplo vender un producto), la información asociada a esa transacción atraviesa distintos departamentos y sistemas informáticos de forma horizontal, y al estar cada departamento centrado en sus propias tareas, no existe visibilidad para todo el proceso desde el inicio del proceso hasta su fin. Dicho de otra manera, el proceso se encuentra fragmentado y requiere del intercambio de información entre los sistemas aislados. Esta situación se agrava aún más con el crecimiento en el número de interfaces con clientes (mail, web, redes sociales, teléfono, sms, etc.), el aumento de los aplicativos especializados en funciones concretas de la empresa y el número de intermediarios con los que colaboran las empresas. El mercado actual, caracterizado por altos niveles de exigencia de los clientes en cuanto a niveles de servicio, tiempos de entrega y calidad, convierten al cliente no ya en el rey, sino en un tirano (“esto es lo que quiero y lo quiero ahora”), los clientes chocan constantemente con los silos de información departamentales de las empresas funcionales, provocando du162


plicados de información, incoherencias e ineficiencias, debido a la rotura de los procesos y de la cadena de valor interna de la empresa. Todos los departamentos tienen alguna parte del proceso, pero ninguno lo tiene o contempla en su totalidad, pues el proceso original ha sido fraccionado dentro de la propia estructura departamental. En esta situación, los silos sólo son buenos para almacenar grano, pero no para mantener una arquitectura organizacional competitiva y orientada a procesos y clientes. Ante la realidad de unos procesos que atraviesan la organización, surge la gestión por procesos y BPM como disciplina para tomar esta perspectiva proceso-céntrica, orientada al cliente y a la satisfacción del mismo. La visión de procesos resulta sumamente poderosa al proporcionar una perspectiva acorde con la lógica con la que realizamos el negocio y satisfacemos a nuestros clientes, haciéndonos cargo de la totalidad del proceso de principio a fin, en contraste con el modelo funcional, en el que nadie tenía la responsabilidad de todo el proceso y que más bien, si algo fallase, nos dedicaríamos a buscar un departamento culpable del fallo, cuando la realidad es que la gran mayoría de los fallos se producen por no considerar los procesos en su totalidad. Los procesos que utilizaremos en nuestros proyectos de BPM atravesarán generalmente las unidades departamentales de la organización en cuanto a tareas, funciones, personas y sistemas de información involucrados, proveyendo en todo el proceso no sólo de la visión estratégica, organizativa y cultural necesarias para afrontar este reto, sino también de las técnicas, herramientas y metodologías para diseñar, modelar, medir, monitorizar y controlar estos procesos. La orientación a procesos y más concretamente BPM y su idea principal de que una organización es la suma de todos sus procesos de negocio, significaran un cambio de paradigma en la forma de pensar las organizaciones e implicarán un cambio estructural para reinventar la forma en que llevamos a cabo los procesos de negocio y es la razón por la que empresas como GE, Google, Virgin, Toyota, Dell, eBay, Amazon, Samsung y muchas otras han llevada adelante este cambio. El planteamiento de esta visión de procesos no es tan radical como pueda parecer en un principio y ambos planteamientos, el funcional y el de procesos, pueden ser complementarios y de hecho lo son en la mayoría de implementaciones de BPM, en las que mantenemos la estructura departamental de la empresa, pero reorganizando las estructuras y los recursos, para que estos adopten un compromiso con la totalidad del proceso de inicio a fin bajo la consideración de que el proceso en su conjunto es más 163


importante que sus partes por separado. En estos proyectos, será importante asignar un responsable del proceso completo y transmitir el compromiso y la necesidad de esta visión a todo el equipo involucrado, de forma que todos remen en la misma dirección de empujar el proceso para producir una salida que sea lo más eficiente posible y aporte el mayor valor al cliente.

Como vemos en el gráfico anterior, la gestión de procesos de negocio se origina con el cliente, atravesando distintos departamentos funcionales dentro de la compañía y finalmente regresando de nuevo al cliente. En este viaje, el proceso completo atraviesa no sólo los departamentos de la empresa, sino también los sistemas y aplicaciones existentes en estos departamentos. Al igual que en los proyectos de BPM comentábamos la no necesitaremos eliminar toda la estructura de la empresa para su implementación, BPM tampoco elimina las aplicaciones informáticas asociadas a cada departamento, sino que las integra. En este sentido, BPM además de manejar el flujo del proceso y actividades, las personas involucradas y la monitorización del proceso, actúa también como un Middleware o EAI de aplicativos y sistemas informáticos, proveyendo de una capa de proceso, la cual integra aplicaciones independientes que necesitan ser ejecutadas dentro del proceso o de las cuales podemos precisar datos y consultas. La evolución que haremos con BPM en cuanto a la integración de sistemas, es pasar de un modelo de datos a un modelo en el que los datos se encuentran integrados y consolidados entorno a los procesos. Para ilustrar la orientación a procesos, podemos usar como ejemplo el proceso de Alta de un nuevo empelado en una empresa y los posibles canales de interconexión que tiene este proceso:

164


En este caso, podemos replicar el problema de los NxN canales de comunicación que vimos al hablar de los sistemas Middleware, pero aplicado ahora a un proceso que atraviesa varios departamentos de una organización como es este caso de Alta de un nuevo empelado. Para el desarrollo del proceso y la integración de sus sistemas, podemos organizar las tareas de cada departamento con las correspondientes conectividades entre ellos, lo que resultaría en una tarea enorme, o podemos ordenar nuestra organización desde la perspectiva de procesos, simplificando y ganando con ello muchas ventajas, para lo cual añadiremos una capa de procesos, encargada de esta integración de datos, tareas y aplicaciones, donde en lugar de definir y establecer todas las interrelaciones entre departamentos y sistemas, lo organizamos entorno a procesos.

Las organizaciones de tipo funcional resultaron altamente eficaces para abordar las operaciones especializadas en empresas manufactureras, indus165


triales y de producción en masa, pero han chocado con la visión de una organización orientada a procesos, que requiere de la cooperación entre todos los departamentos de la empresa y de una cultura distinta, más abierta, participativa y menos jerárquica y donde el foco se encuentre en ofrecer resultados a los clientes. El cambio hacia la orientación a procesos implicará un cambio cultural y en la forma de pensar y trabajar y que frecuentemente resultará en una nueva estructura organizacional. Esta visión, implicará romper con la visión atómica y departamental de empleados y unidades “ad hoc”, especializadas sólo en determinadas tareas puntuales, con poca e ineficiente comunicación entre departamentos y que han conducido a la poca eficiencia global de la empresa y de sus procesos así como a trabajadores más ocupados de defender sus privilegios que del resultado global de los procesos de negocio que ejecuta la empresa. En este recorrido hacia la organización orientada a procesos, al principio se optó por escoger determinados procesos, generalmente de producción o manufactureros, para analizar y mejorar estos procesos individuales, pero todavía no se pensaba en la empresa como sistema integral de procesos y es esta última aproximación, la que veremos en los siguientes apartados a través del pensamiento sistémico primero y las teorías de Peter Fingar después.

El Pensamiento Sistémico. Enlazando con muchos de los conceptos vistos de la organización orientada a procesos, el System Thinking o Pensamiento Sistémico, es una visión también centrada en el todo y no en las partes que conforman un sistema. Es de nuevo la visión holística como herramienta para alcanzar resultados que sumen más que las partes que los componen, mediante el análisis a partir de los límites de los componentes, la organización de estos y en el estudio de las conexiones de unas partes con otras. El pensamiento sistémico surgió tras la segunda guerra mundial, como un anhelo por mejorar la condición humana ante la complejidad de los problemas que la humanidad afrontaba tras la devastadora II Guerra Mundial. Su origen se encuentra en el campo de los sistemas dinámicos, estudiados por Jay Forrester en 1956, quien alegaba la necesidad de estudiar los sistemas sociales como sistemas de ingeniería, de forma que pudiésemos en166


tenderlos para poder mejorarlos. Esta nueva forma de pensar pretendía unificar las ciencias bajo un modo de pensar holístico que permitiera comprender el mundo como una totalidad armónica. W. Edward Deming, el padre de la calidad, ya puntualizó hace muchos años que: “el problema es el sistema”. Al igual que en un coche no se mueven cada una de sus partes por separado, sino que se mueve el coche en su conjunto por la interrelación entre sus diferentes partes (carrocería, motor, sistema eléctrico, etc.), los procesos de negocio que atraviesan horizontalmente una organización son también sistemas dinámicos, pero las personas que dirigen y ejecutan los procesos en estas organizaciones, no estamos preparados para comprender este pensamiento sistémico. El objetivo del pensamiento sistémico es resolver la complejidad y aplicado a la gestión de empresas, resolver la complejidad debida a un entorno de mercado cada vez más complejo. La relación de este pensamiento con BPM viene de la necesidad de dominar este tipo de pensamiento para poder construir organizaciones gestionadas por procesos, obtener una comprensión más profunda de los sucesos y sus relaciones y poder de esta manera influir o interactuar con ellos. Una de las principales diferencias entre el pensamiento tradicional y el sistémico es que el tradicional usa una visión lineal, mientras que el sistémico hace uso de una visión circular para ayudarnos a establecer las relaciones entre las partes.

167


El pensamiento sistémico es distinto del tradicional en la medida en que no estudia las partes separadas que componen un sistema sino que se centra en las interacciones entre las partes del sistema. En lugar de aislar y reducir a piezas cada vez más pequeñas las distintas partes del sistema para poder entenderlo, se centra en las interacciones entre las partes. Este foco en las interacciones entre las partes, viene de reconocer la importancia de estas interrelaciones para el comportamiento del sistema en su conjunto, a sabiendas de que del estudio de las partes de forma aislada, no podemos extraer información relevante para comprender el sistema en su conjunto. La vida misma encuentra muchas veces su entendimiento y explicación cuando es vista desde la perspectiva del intercambio de materia, energía e información entre las partes que la forman. Traducido a un entorno empresarial, conscientes de que las empresas no pueden existir aisladamente ni son sistemas cerrados, su comprensión sólo toma sentido cuando analizamos cómo interactúan sus partes componentes, con otras empresas, con la competencia y con los mercados. El pensamiento tradicional basado en la lógica del análisis, la descomposición y síntesis de las distintas partes de un sistema en partes cada vez más pequeñas y que ha marcado el pensamiento analítico y científico, ha funcionado en la mayoría de situaciones en que lo hemos empleado, cuando trabajamos con procesos o sistemas lineales y con secuencias simples de causa y efecto. Sin embargo, cuando trabajamos con personas o con sistemas dinámicos, donde las variables del sistema se influyen mutuamente, estos análisis no son tan fáciles de realizar o de reducir a expresiones matemáticas exactas. Estos sistemas pueden ser comparados con un puzle, en el que todas las piezas encajan de una única forma posible, lo que facilita su composición, pero en los que si introducimos en alguna pieza la posibilidad de poder combinarse con más de una sola pieza (lo convertimos en un sistema dinámico), aumentamos exponencialmente el número de soluciones posibles, pasando este a una complejidad dinámica, donde las soluciones analíticas tradicionales ya no nos sirven para explicar y encontrar soluciones rápidas y efectivas a esta complejidad. El pensamiento sistémico nos ofrece una nueva visión de las cosas, o por lo menos nos recuerda la posibilidad de hacerlo, de abordar nuevas perspectivas para la comprensión de los sistemas y resolver los problemas. Muchas veces se compara con la visión de que dispone un astronauta de la tierra desde el espacio, o las distintas visiones que podemos tener de un sistema si ascendemos en helicóptero a distintas alturas para observar el

168


mismo, donde a cada nueva altura que alcancemos, tendremos una visión distinta del problema pues cada vez involucraremos a un entorno mayor. Puesto que como sistema puede ser visto prácticamente cualquier cosa, esta visión sistémica a veces traspasa los límites de la matemática y del comportamiento de sistemas dinámicos para ser llevada a numerosos escenarios, algunos familiares para el lector como el concepto de Gaia (el planeta Tierra visto como un sistema biológico) o a visiones más místicas y filosóficas, como ampliar esta visión al Cosmos, las relaciones de pareja, la psicología, la salud, la economía, la ecología, la naturaleza, etc. bajo la premisa de que “todo está conectado”. Entender la complejidad del mundo que nos rodea es un primer paso para poder cambiar el mismo y el pensamiento sistémico afronta de forma decidida esta complejidad a través de una perspectiva novedosa y una serie de técnicas y herramientas teóricamente fundamentadas, para afrontar los problemas que nos rodean. Para entender un poco más esta teoría citamos a continuación algunas ideas y principios surgidos del mismo: -

-

-

-

-

Todo sistema se basa en la interacción entre sus partes y esta propiedad es más determinante que la cantidad de partes que lo compongan y su tamaño. Lo obvio, a veces no es tan obvio, ni los criterios mayoritarios son siempre los más acertados. Para poder influir sobre el sistema, debemos conocer su estructura, lo cual pasa por comprender la complejidad de los procesos que lo conforman. Causa y efecto no siempre están relacionados en el tiempo y en el espacio, por lo que no podemos actuar como si así fuese, tendiendo relaciones lineales de causa y efecto y pasando por alto otras muchas interacciones. Con la descomposición de un sistema en sus partes esenciales no siempre podremos comprender ni predecir su comportamiento. Un sistema no puede crecer indefinidamente sin ajustar el mismo en su funcionamiento. Lo que funciona bien en una magnitud, no siempre funciona bien aumentando esa magnitud y un mayor tamaño no implica un mejor funcionamiento. Los sistemas tienen su tamaño óptimo.

169


-

-

-

Nos es difícil determinar las consecuencias de nuestras acciones si estas no se visualizan a corto plazo, lo cual nos crea problemas a largo plazo. De igual manera, el no tener una visión global, la tendencia a estructurar y simplificar, nos causa problemas en otras áreas de la empresa que no hemos predicho. Las propiedades emergentes son intrínsecas a todo sistema complejo y pueden afectar al sistema en distintos sentidos. Considerar siempre los distintos puntos de vista es fundamental para comprender los sistemas. Cuantas más partes e interconexiones tenga un sistema más estable será el mismo. Cuantas más conexiones entre sistemas tengamos, más estables y redundantes serán los mismos. Los sistemas mantienen su estabilidad en base al feedback que obtienen de su entorno. Influenciamos y somos influenciados por los sistemas de los que formamos parte.

El tener en cuenta esta visión del pensamiento sistémico nos ayudará a disponer de nuevas perspectivas a la hora de analizar y pensar tanto nuestras organizaciones como sus procesos de negocio y puede que de esta visión salgan nuevas soluciones a los entornos económicos y empresariales que nos rodean. Como decía Albert Einstein “no podemos hacer siempre lo mismo y esperar resultados diferentes”.

Peter Fingar y la empresa como sistema. Antes vimos como BPM puede ayudar a eliminar el Gap entre negocio y TI en lo que Peter Fingar y Howard Smith denominaban eliminar el puente que los divide. Así mismo vimos como algunos autores recomendaban incluso el apartar a los programadores y personal de TI de las fases de diseño y análisis de procesos de negocio, afirmación esta que seguramente haya enervado a más de un lector e inducirle a abandonar la lectura de este libro. Sin embargo, en un artículo posterior de Peter Fingar en BPTrends titulado “The Core Competency for BPM”, Fingar ahondaba en la necesidad de una visión de la empresa como sistema y señalaba a los programadores y profesionales de TI como los principales poseedores de esta visión a la hora de pensar en sistemas globales de la empresa, pues consideraba que los 170


perfiles de personal de otros departamentos como el de marketing, legal o financiero, se encuentran limitados a tareas específicas de la empresa y no preparados en consecuencia para este tipo de pensamiento global y sistémico. Para Peter Fingar, los trabajadores de hoy en día continúan la senda Taylorista de la especialización en el trabajo, viendo sólo partes de la empresa, privados de la visión global de negocio y de los resultados de sus acciones individuales, por lo que Fingar reclamaba para ellos una perspectiva de astronauta (los cuales pueden ver toda la tierra), de forma que conozcan los efectos de su trabajo y dispongan de una visión de los procesos de principio a fin y del modelo de negocio del cual forman parte. Fingar llamaba en este artículo a abrazar el Pensamiento Sistémico (System Thinking), como medio para manejar la complejidad tecnológica y de los negocios para entender el entorno en el que nos movemos a través del estudio de las interconexiones e interrelaciones entre las partes. Fingar abogaba por BPM, como el conjunto de herramientas que permitirán implementar esta visión: descubrir las múltiples interrelaciones entre las partes y sistemas de la empresa y comprender las variables que afectan a los procesos de negocio y los efectos a largo plazo de los mismos, mediante la poderosa herramienta de simulación de procesos en BPM, que nos permitirá descubrir errores y posibles implicaciones en los procesos antes de su ejecución en el mundo real. Para Fingar, no podemos tratar más a los procesos y actividades de negocio dinámicos como repositorios de datos y algoritmos de cálculo, coincidiendo con otro autor de BPM, Martyn Ould, quien afirmaba que nos movemos de la Era de la Información a la Era de los Procesos, del procesamiento de información al procesamiento de procesos, donde el objetivo es el negocio y no el manejo de datos e información. La empresa gestionada por procesos no es una nueva “Killer application” y requiere de una nueva visión de los sistemas de información y de los departamentos de informática y su papel en la empresa. Los analistas y programadores software no pueden hablar de negocios en términos de diagramas entidad-relación, diagramas de clases o UML. A pesar de ser el personal informático los mejor adaptados para disponer de esa visión global de la empresa, necesitan explotar esa capacidad y complementarla con la visión de negocio, de forma que puedan alcanzar nuevos niveles de abstracción y abandonar la visión exclusiva de la empresa como un sistema de información. Al igual que el resto de los trabajadores, el personal y departamentos de TI, deben abordar el pensamiento sistémico, en el que todo está 171


conectado con todo y reconocer que forman parte de un sistema mayor, en el que su trabajo sólo tiene sentido al verse en conjunto y no de manera individualizada. Ahora que hemos introducido qué es BPM así como las bases metodológicas y de pensamiento sobre las que basar nuestros proyectos, podemos pasar a diseñar y modelar las organizaciones y los procesos que darán cobertura a la implementación de esta visión, y que formarán el contenido de los siguientes dos capítulos.

172

Capítulo 5. Modelado de Negocios

Capítulo 5. Modelado de Negocios.

Normalmente nos encontramos con problemas y situaciones complejas que escapan a nuestra comprensión o capacidad de entender y resolver los mismos y es por ello que construimos modelos simplificados que nos permitan estudiar estos problemas y realizar simulaciones. El modelado y simulación suelen ser operaciones seguidas en un ciclo iterativo: desarrollamos el modelo, lo simulamos, aprendemos de su comportamiento y refinamos el modelo en función de lo que hayamos aprendido, volviendo a desarrollar el modelo y repitiendo este ciclo tantas veces como sea necesario, hasta llegar a un nivel de entendimiento y comportamiento del modelo que consideramos adecuado. La realización de este ciclo será todavía más útil cuando tratemos con sistemas dinámicos, debido a que la influencia del “tiempo” en los mismos, dificultará poder predecir su comportamiento y evolución. Los modelos de negocio, como los mapas, nos guiarán a nuestro “destino estratégico”, nos mostrarán rutas alternativas y posibilidades, nos marcarán obligaciones y restricciones con las que tenemos que contar en nuestro camino y nos ayudarán a comunicar a nuestros compañeros de viaje el recorrido que pretendemos realizar, para consensuar con ellos la ruta y los motivos del viaje. Al igual que los turistas con los mapas, las organizaciones usarán el modelado para entender, controlar y describir la complejidad así como para poder planificar y tomar las decisiones más acertadas en cada momento.

173


El comenzar nuestro recorrido en BPM por el diseño y modelado de los modelos y no directamente de los procesos de negocio, se fundamenta en la realidad del entorno empresarial actual en el que las empresas pueden ganar más dinero diseñando sus arquitecturas, sistemas empresariales y modelos de negocio que diseñando los procesos manufactureros y de producción y que la base sobre la que deberemos diseñar nuestros distintos procesos operativos, deberá fundamentarse y ser fiel reflejo de este modelo de negocio. Este es el caso de conocidas empresas como Apple, Nike y muchas otras que gana más dinero pensando que fabricando: “Designed in California; Assambled in China”. En la visión de BPM, los gerentes de empresas, más que ser responsables del diseño, producción y venta de los productos, serán diseñadores de modelos de empresas y responsables de crear y mantener estos modelos, sobre los cuales las empresas diseñan sus productos, los producen y los venden, por lo que estos directivos deberán encargarse de que estos modelos y procesos se encuentren siempre perfectamente optimizados, continuamente mejorados, coordinados, que todo el personal sepa lo que tiene que hacer en cada momento y de que las tecnologías den el mayor soporte a estos modelos para aumentar la eficiencia de los mismos. Los modelos de negocio son la representación de la realidad de una organización y son utilizados para entender cómo se organiza una empresa, cómo interactúa, que objetivos y estrategias persigue, cuáles son las tareas y el trabajo que debe realizar para conseguir esos objetivos y como la empresa creará valor a sus clientes. BPM hará uso de las herramientas de modelado de negocios porque son una herramienta perfecta para analizar, planificar y tomar decisiones sobre la estrategia, la táctica, los objetivos, operaciones y actividades que realiza la empresa y como alinear estas metas y objetivos empresariales con el diseño de los procesos que darán soporte a esta estrategia y la tecnología que a su vez dará soporte a los procesos. A través de los modelos que realicemos, podremos comprender como operamos y se desarrollan nuestros procesos y modelos de negocio y mediante la transformación de estos modelos, podremos identificar oportunidades y mejoras sobre estos procesos en términos de eficiencia, rendimiento y adaptación al cambio. El modelado de negocio nos resultará además una herramienta muy valiosa en nuestros proyectos de BPM para comunicar a otros miembros de la organización, otras empresas, clientes y partners con los que interactuemos, acerca de lo que pretendemos con el proyecto y buscar el consenso con estos actores para la ejecución del modelo. 174


Los modelos de negocio representan de forma gráfica o verbal uno o más aspectos de una empresa como: -

Su propósito. Estructura. Funcionalidad. Dinámica. Lógica de negocio. Componentes: fines, procesos, reglas de negocio, actores, etc.

En este capítulo nos adentraremos en los modelos de negocio y en especial en los frameworks y modelos de referencia utilizados por diferentes sectores industriales para planificar, definir y diseñar los distintos elementos que necesitaremos para alinear nuestra estrategia con los procesos y la tecnología. Al contar BPM con una notación específica para modelar procesos como es BPMN y al disponer en las plataformas software de BPM de herramientas visuales de modelado de procesos para esta notación, muchos usuarios tiene como primer impulso el ir directamente a esta herramienta de modelado, sin embargo, debemos advertir que modelar un proceso de negocio no es algo sencillo, requiere de habilidades y conocimientos no sólo técnicos y de la notación BPMN, sino también de lo que está por encima de estos procesos y que constituye la razón final de por qué trabajamos en ellos y que marcarán el camino a seguir por los procesos de forma que estos sean un fiel reflejo de lo que queremos alcanzar. Este espacio previo al diseño de procesos se refiere al cómo se conforman las estrategias y arquitecturas empresariales, la cadena de valor, las tecnologías y su relación con los procesos que opera la empresa y será el contenido único de este capítulo.

Valor y Ventaja competitiva. El actual entorno económico, altamente dinámico, competitivo y turbulento nos obliga a cambios y transformaciones constantes para poder adaptarnos a los requerimientos de los nuevos y viejos clientes (pues estos también cambian). Ningún negocio va a tener éxito haciendo las cosas de forma estándar. Necesitamos buscar ventajas competitivas que nos diferencien respecto a la competencia y demás productos y servicios del mercado y en esta búsqueda, el “Valor” que aportemos a nuestros clientes por esos pro175


ductos y servicios y que constituirá la razón última por la que nos paguen nuestros clientes, resultará importantísima para poder sobrevivir y tener éxito en este entorno. Hoy no existe tolerancia con el error y la ineficiencia, ya no nos vale con hacer las cosas bien o hacer más de lo mismo bajo la premisa de que esto siempre nos ha funcionado. Las empresas deben ahora hacer más con menos e incrementar el valor aportado a los clientes, a los empleados (para poder retener el talento), a los accionistas, y a la sociedad en general. Ya no nos basta con ser sólo el más barato o el que más calidad aporta, como si de por sí, esto fuese sencillo, ahora, además de precio y calidad, debemos ofrecer a nuestros clientes la mejor de las experiencias en cuanto a calidad de servicio, tiempos de entrega y servicio post venta. Para poder competir en este entorno, es preciso realizar importantes cambios, repensar y rediseñar la forma de trabajar, de forma que esta sea lo más inteligente y eficiente posible. La caída de la demanda y los requisitos para hacer frente a periodos de decrecimiento y falta de financiación, requiere de personas y organizaciones más orientadas a resultados, capaces de adaptar y modificar sus procesos de negocio o incluso reinventarlos completamente, en función del entorno en el que operan en cada momento. Es necesaria una mirada innovadora sobre los procesos de negocio, asegurándonos de que estos aporten valor y el pensar constantemente en nuevos modelos de negocio, mercados y oportunidades. Ser capaces de con los recursos que tenemos, gestionar los nuevos proyectos, cambios e iniciativas que nos planteamos de una forma correcta y eficiente, centrándonos en lo que realmente importa y no en pretender ser más grandes, con más empleados o mayor facturación, sino centrarnos en aquello que aporte valor al cliente, que es por lo que obtenemos finalmente un beneficio como empresa. A lo largo de la historia, han existido diferentes formas de aportar valor a los clientes, pero hoy en día, existe un mecanismo importantísimo para poder aportar valor y es el disponer de una ventaja competitiva, es decir, que para poder tener éxito, nuestra empresa debe hacer algo mejor que otras empresas, pudiendo encontrarse esta ventaja en la orientación al cliente, en la mayor calidad de sus productos, en precios de venta más baratos o en una posición de monopolio en el mercado. Sobre qué podemos hacer mejor que otros, debemos recordar a Tracey y Weisman (1997) cuando decían que una empresa, para poder ser compe176


titiva debe escoger de entre alguno de estos aspectos, aquellos que le permitan ser mejor que ninguna otra: -

-

Cercanía al cliente. Liderazgo en clientes: con altos grados de calidad y servicio hacia los clientes y su satisfacción. Excelencia operacional. Liderazgo en Costes. Alta eficiencia y mejora continua y en consecuencia, menores costes de producción de los productos y servicios ofrecidos a los clientes. Liderazgo en producto. Tener el mejor producto, con mejores características e innovaciones que los de la competencia.

Pero según estos mismos autores, no es posible ser buenos en las tres estrategias al mismo tiempo. Debemos escoger el liderazgo en alguna de ellas, pues de otra forma, según Michael Porter, nos estrellaremos irremediablemente. Además de esta elección entre alguna de estas fuentes de ventaja competitiva, debemos tener en cuenta que debido a la presión de los mercados y la competencia, muchas de las antiguamente consideradas ventajas competitivas, son consideradas hoy en día por los clientes como algo que se debe dar obligatoriamente, por lo que la única solución que nos queda es la rapidez con que seamos capaces de encontrar y adaptarnos constantemente a nuevas ventajas competitivas diferenciadoras, haciendo uso de la capacidad creativa y de gestión de la innovación de la que disponga nuestra empresa. En los proyectos de BPM que emprendamos, la propuesta de valor del proyecto nos asegurará que el beneficio de la implementación de un proceso este alineado con los objetivos de negocio, que los procesos aporten valor a nuestros clientes y stakeholders (personas que de alguna u otra forma puedan verse afectadas por el funcionamiento del proceso), en términos de aumento de ingresos, reducción de costes, mayor grado de innovación en la organización, fidelización y satisfacción de clientes. Los procesos en sí mismos, pueden ser considerados como cadenas de aportación de valor, en el sentido de que en la secuencia de tareas de nuestro proceso, dirigidas a obtener un producto o servicio de valor para nuestros clientes, cada uno de estos pasos o tareas debe añadir valor al paso precedente. Si no conseguimos aportar valor a través de los procesos que implementamos, no habremos conseguido los objetivos del proceso, por lo que será obligación del equipo de proyecto y de sus promotores, asegurar y comprobar que estos cumplan con la propuesta de valor especificada en el modelo de negocio y la estrategia.

177


La Cadena de Valor. Según Michael Porter (1985), la ventaja competitiva de una empresa radica en las muchas actividades que esta desarrolla en el diseño, producción, marketing y venta de sus productos, donde cada una de estas actividades puede crear la base para la diferenciación. Según Porter, para analizar las fuentes de ventaja competitiva, es necesario examinar todas estas actividades y cómo interactúan entre ellas, disgregando la empresa de sus actividades estratégicas para comprender los orígenes de esta diferenciación. Para la realización de este análisis de las fuentes de ventaja competitiva, Porter introduce el concepto de Cadena de Valor, como el conjunto de actividades que realiza la empresa para diseñar, producir, llevar al mercado, entregar y apoyar sus productos. Las Cadenas de Valor, según Porter, son “la forma en que la empresa desempeña sus actividades individuales, son un reflejo de su historia, de su estrategia, de su enfoque para implementar la estrategia y las economías fundamentales para las actividades de la misma.” Según Porter, quien proporciona la ventaja competitiva son los procesos que ejecuta la empresa y es por ello que estas buscan siempre nuevas formas de realizar sus procesos mejor que sus rivales. La clave del éxito para alcanzar ventajas competitivas en una empresa, radica en escoger bien su estrategia y centrase en ella, no desviando su atención hacia otras estrategias, de forma que en la estrategia que escoja, optimice sus procesos y sea líder en la estrategia escogida, diseñando su propia cadena de valor y unos procesos que sean únicos y difíciles de replicar por otras empresas, de forma que así, esta pueda mantener sus ventajas competitivas en el tiempo. Sobre la elección de la estrategia y los procesos que la soportarán, podemos recordar la pregunta que le hicieron a Ricardo Reti, un gran maestro de ajedrez, sobre cuantas jugadas podía calcular de una vez en el tablero, a lo que este respondió: “Ninguna”. Con esta respuesta, Reti se refería a que la eficacia del ajedrez no reside en calcular variantes de muchísimos movimientos posibles, que por supuesto ha de saber realizar, sino centrarse en las que realmente tienen importancia y vale la pena analizar, pues son estas de las que podrá extraer valor y ventajas en la partida. Lo que los grandes maestros del ajedrez hacen es elegir una estrategia cribando las ramas y posibilidades estériles y en las que no vale la pena ahondar. En esta capacidad de saber identificar las variantes ganadoras, radica la diferencia entre los grandes jugadores y los aficionados. Los aficionados, no tienen la capacidad o el arte de poder seleccionar qué líneas son las más interesantes, 178


con mayores posibilidades de éxito y en las que vale la pena profundizar en su análisis, por lo que al no hacer esta criba o selección inteligente de las ramas o variantes, no les quedará otro remedio que hacer uso de la fuerza bruta de la capacidad de cálculo de nuestro cerebro o de los ordenadores para calcular todas las posible jugadas y valorar las ventajas y desventajas de cada una de ellas. Este ha sido el caso de Blue Deep, el superordenador de IBM que consiguió vencer a Kasparov a fuerza del poderío de cálculo de sus procesadores. En el análisis de nuestros procesos, podremos hacer uso también de la fuerza bruta de nuestros ordenadores y herramientas de análisis matemático, pero siguiendo la regla de Pareto, el 80% de lo que observemos será producido por el 20% de las fuentes, y es en este 20% hacia el que deberemos dirigir no sólo el análisis matemático y estadístico sino también nuestras habilidades creativas y de intuición que apliquemos a los procesos. La Cadena de Valor, es un modelo teórico que permite describir las actividades de una organización para generar valor al cliente final y a la propia empresa. Describiremos a continuación la Cadena de Valor y los distintos elementos que la forman para poder escoger y diseñar una buena estrategia sobre la que basar nuestros procesos. La Cadena de Valor de una empresa se representa por una serie de funciones de negocio (gestión de compras, recursos humanos, etc.), las cuales se pueden descomponer en unidades funcionales más pequeñas. La Cadena de Valor se basa en la organización funcional de la empresa, donde las actividades están organizadas en funciones de negocio. Las funciones de negocio pueden ser divididas en funciones primarias (que contribuyen directamente a alcanzar una ventaja competitiva en la empresa) y funciones de soporte a estas funciones primarias. La cadena de Valor básica está formada por: -

Actividades Primarias: son aquellas que tienen que ver con el desarrollo del producto, su producción, su venta, la logística y comercialización así como los servicios de post-venta. o Logística Interna: almacenamiento, inventarios, recibos. o Operaciones: actividades de transformación. o Logística externa: actividades de recopilación, almacenamiento y distribución física, procesamiento de pedidos y entrega. o Marketing y ventas: actividades para facilitar los medios de compra. 179


Servicio Postventa: actividades para realizar y mantener valor. Actividades de Apoyo: que sustentan las actividades primarias y se apoyan entre sí, como las de recursos humanos, compras de bienes, materias primas y servicios, el desarrollo tecnológico, etc. o Aprovisionamiento: función de compras de abastecimientos. o Recursos Humanos: selección, contratación, formación y desarrollo de personal. o Tecnológicos: procedimientos, equipamiento, I+D, etc. o Infraestructura: que apoyan a la cadena completa: administración, finanzas, contabilidad, calidad, sistemas de información, legal, etc. o

-

Gráficamente la Cadena de Valor se representa de la siguiente forma: Infraestructura Recursos Humanos Tecnología

Logística de Entreda

Operaciones

Logística de Externa

Marketing y Ventas

MARGEN

Aprovisionamiento

Servicio Psotventa

Este gráfico de la Cadena de Valor nos muestra lo que ocurre en la empresa entre el momento en que recibimos un pedido de un cliente y el momento en que le entregamos ese producto. Todas las funciones que participan en la elaboración de ese producto, tanto las funciones principales como las de apoyo, conforman la cadena de valor y es esta cadena la que determina cuanto nos cuesta producir el producto y que margen obtenemos tras su venta. En la cadena de valor, todas las actividades que la forman añaden valor al producto final para conseguir la satisfacción del cliente y de alguna forma, a la pregunta de ¿si el cliente conociese todos los pasos de esta cadena de valor, estaría de acuerdo en pagar por todos y cada uno de los pa180


sos incluidos en ella? Podríamos quedarnos tranquilos, sabiendo que todas ellas son necesarias y eficientes en su operativa y el cliente las aceptaría como necesarias para producir los productos y servicios que satisfagan sus necesidades. El sentido último de esta visión de la cadena de valor de Porter es identificar actividades que no aportan valor y que deben ser eliminadas. Para Porter, el recorrido que va del pedido del cliente a su entrega, es un proceso completo en el que la empresa debe centrarse y no debemos pensar esta cadena como procesos separados que ocurren en distintos departamentos de la empresa, pues este es un error que no optimiza la cadena de valor. En la teoría de Porter, una empresa es mucho más que la suma de sus actividades (otra vez la visión holística), donde la cadena de valor es un sistema de actividades interrelacionadas entre sí (pensamiento sistémico) por lo que adquirir una ventaja competitiva exige que la Cadena de Valor se gestione como un sistema y no de forma separada. En la teoría de Porter, además de la Cadena de Valor de una empresa, tenemos que contemplar también las cadenas de otras empresas, pues las empresas colaboran unas con otras en sistemas abiertos, en la que cada una intenta alcanzar sus objetivos y en consecuencia, sus Cadenas de Valor también están interrelacionadas. A este ecosistema de Cadenas de Valor interrelacionadas lo denominamos Sistema de Valor y estará formado por Cadenas de Valor interrelacionadas, cada una de las cuales está asociada con una empresa. Este Sistema de Valor, considera que la empresa está envuelta en un conjunto de actividades realizadas por un gran número de actores diferentes: proveedores que tienen sus propias Cadenas de Valor y crean y entregan insumos en nuestra Cadena de Valor, diferentes canales de distribución en su camino hacia el cliente, a través de los que entregamos los productos y que generalmente afectan a estos clientes y a sus propias cadenas cuando el producto pasa a formar parte de este, etc. y en donde todos ellos conformarán el denominado Sistema de Valor.

Desde el punto de vista del sistema de valor, podemos tener: 181


-

-

-

Cadena de valor de los proveedores: crean y aportan los abastecimientos o insumos que nuestra empresa necesita. El costo y la calidad de estos abastecimientos influyen en los costos y la calidad de nuestra cadena de valor y en consecuencia en su capacidad para adquirir ventajas competitivas. Cadenas de valor de los canales: a través de los cuales entregamos los productos a nuestros clientes y cuyos costos y márgenes de distribución, forman parte del precio que pagará finalmente el cliente y afectarán por tanto a la satisfacción de este. Cadenas de valor de compradores: son la fuente de diferenciación por excelencia, puesto que en ellas la función del producto determinará las necesidades del cliente.

Los pasos generales a seguir para la construcción de la cadena de valor son los siguientes: 1. Diseñar la cadena de valor: capturando todo lo que se realice dentro de la empresa. Dividiendo y aislando las actividades, atendiendo a las que tengan economías diferentes, tengan un alto potencial de diferenciación o aquellas que tengan un alto impacto en el costo. 2. Analizar las conexiones: puesto que la cadena de valor no está formada por actividades independientes, sino que estas son interdependientes, analizaremos las conexiones y relaciones entre ellas, buscando las ventajas competitivas en la optimización y coordinación de las distintas actividades y que nos puede conducir a la eliminación de actividades innecesarias. 3. Realizar benchmarking con nuestros competidores. 4. Evaluar el sistema de valor en su conjunto y las conexiones de nuestra cadena de valor con las de proveedores y canal, pues en este análisis pueden aparecer oportunidades de mejora, reducción de costes y diferenciación para aumentar nuestra ventaja competitiva coordinando y optimizando sus interrelaciones. 5. Analizar la cadena de valor del cliente, pues la diferenciación y creación del valor de una empresa estará en como esta se relacione con la cadena de valor del cliente. El diseño de nuestra cadena y sistema de valor nos resultará de gran utilidad a la hora de definir los procesos de nuestra empresa cuando iniciemos un proyecto de BPM y nos facilitará la tarea de entender las relaciones entre las distintas actividades internas y externas de la empresa y como estas 182


están conectadas con otros recursos y actividades. En especial, este análisis de la Cadena de Valor será más útil cuando la información se encuentra distribuida en diferentes hojas de cálculo, documentos, personas y sistemas, en diferentes herramientas y metodologías y atravesando diferentes unidades de negocio y silos de información, ya que requerirá de una visión holística e integrada de toda esta información para poder priorizar y seleccionar las áreas y actividades con mayor potencial de agregación de valor, diferenciación y ventajas competitivas.

Niveles de detalle en los Procesos de Negocio. Los buenos modelos de procesos deben disponer de diferentes vistas, de forma que al comunicar los mismos al resto de la organización, podamos mostrar diferentes niveles de detalle. No es lo mismo mostrar a un operario de los niveles más bajos de la organización el nivel más alto, con la estrategia de posicionamiento en la Cadena de Valor sobre la cual poco podrá aportar para su mejora, que mostrar esta a un analista de negocio o ejecutivo de la empresa, conocedor del día a día de cómo opera esa Cadena de Valor. De igual manera, mostrar detalles operacionales sobre las tareas de una determinada actividad desarrollada por un operario, no tendrá interés ni aportará conocimiento si se la mostramos para su opinión a un directivo de la empresa, por lo que dependiendo de nuestro puesto en la organización, visualizaremos mejor unos niveles u otros. A la hora de modelar los procesos de negocio, podemos hacerlo con diferentes niveles de detalle, donde la suma de todos ellos, con su descomposición, conformará el “mapa de procesos”. -

-

-

En el nivel estratégico definimos los procesos que son necesarios, los procesos más generales, la arquitectura y coordinación ente los mismos y con otros procesos. En el nivel táctico nos centramos en como diseñar y gestionar los procesos, generalmente son procesos que se encuentran dentro de un departamento o unidad de negocio. En el nivel operacional, vemos ya toda la complejidad y variaciones de los procesos, detallamos las actividades a nivel de personas o sistemas que deberán realizar las actividades y que serán el nivel más detallado del modelado. En este punto pasamos de describir un proceso a describir las tareas finales que deberá realizar una persona o un software. 183


El análisis de la Cadena de Valor es el proceso más amplio del que podemos hablar en la empresa. Es un proceso de negocio de alto nivel que realizamos a nivel estratégico:

Como hemos visto, la Cadena de Valor cubre todas las interacciones con clientes desde que recibimos el pedido, nos proveemos de materiales, los procesamos, los vendemos, hasta que cobramos y emitimos la factura, por lo que incluye las principales actividades que producen valor a nuestros clientes. La Cadena de Valor la ponemos a nivel estratégico porque en BPM no podemos hacer nada sin que la dirección defina la estrategia y nos diga que cosas queremos hacer. A nivel táctico, decidimos como diseñar y gestionar los procesos así como la coordinación entre los mismos. Aquí es donde se definen los procesos, siguiendo la lógica de la cadena de valor: qué hacer, como lo hacemos, quiénes son los responsables de hacerlo y como se comunican entre ellos. De esta forma, determinamos los procesos de negocio que cubrirán todas las actividades de principio a fin para generar valor a nuestros clientes y definirán como hacemos el trabajo dentro de nuestra organización. En este proceso, vamos desgranando la cadena de valor, definiendo los procesos de negocio que descompondremos en procesos operacionales y sub-procesos más pequeños así como la coordinación entre estos y que conjuntamente, 184


mostrarán la operativa de las diferentes áreas de la empresa. Esta descomposición llegará hasta el nivel de actividades o tareas, que serán los elementos más pequeños que podamos describir. El resultado de esta descomposición conformará la arquitectura de procesos, como la mostrada en el siguiente gráfico a partir de la descomposición de la Cadena de Valor, donde vemos la jerarquía de procesos y los tres niveles de detalle.

El proceso de descomposición a partir de la cadena de valor para crear la arquitectura de procesos sigue los siguientes pasos: -

Identificar una cadena de valor Determinar los objetivos estratégicos que pretende la cadena de valor. Determinar cómo vamos a medir esos objetivos. Subdividir la cadena de valor en procesos. Determinar para cada proceso como lo mediremos, los recursos necesarios para el mismo y demás detalles del proceso.

Aunque Porter no identifica en la tarea de descomposición el papel de los procesos, estos encajan perfectamente en la Cadena de Valor, siendo las funciones de negocio que desarrolla la empresa en el contexto de un Siste185


ma de Valor, identificadas como procesos de negocio. BPM como disciplina nos permitirá gestionar esta Cadena de Valor, ganando en agilidad y adaptabilidad, al poder gestionar, monitorizar y controlar de forma continua la Cadena de Valor en tiempo real. El modelo de referencia para la gestión de la Cadena de Valor y donde podremos encontrar estas cadenas aplicadas a distintos tipos de empresas y sectores para la mejora de nuestra propia cadena de valor es el Value Reference Model (VRM), en el que se describen Cadenas de Valor horizontales con las interdependencias entre los distintos procesos: estratégicos, tácticos, operacionales, actividades y tareas para distintos tipos de empresas y sectores. En la página web del VRM (www.value-chain.org), podremos encontrar valiosa información sobre distintas cadenas de valor y detalles de cada una de ellas que nos ayudarán al diseño de nuestra propia Cadena de Valor.

Estrategia, procesos y tecnología. La estrategia define como una empresa va a competir, como creará valor a sus clientes, que metas tendrá y que políticas desarrollará para alcanzar sus objetivos. Su importancia para BPM es tal, que ningún proyecto debería comenzar sin una definición clara de la estrategia que se pretende. La estrategia de la empresa no siempre se tiene en cuenta y esto es algo que solemos olvidar cuando implementamos no sólo distintos tipos de proyectos empresariales, sino también proyectos de gestión por procesos. Al inicio de cualquier proyecto de BPM, debemos preguntarnos por las metas y objetivos que tenemos para los procesos y por lo menos, los objetivos deberían estar definidos, pues sin ellos, no podemos trabajar en la mejora de los procesos asegurando que añadan valor o contribuyan a la organización. Sin esta definición previa, ni tan siquiera sabremos si vamos en la dirección correcta. Lo recomendación en estos casos es relegar la mejora de procesos hasta conocer la estrategia y objetivos de la empresa y no iniciar ningún proyecto sin esta definición previa. Otro aspecto importante relacionado con la estrategia es que esta debe ser entendida por todos los miembros del equipo de proyecto y de la organización, por lo que debe ser comunicada y “vendida” a todos los miembros del proyecto, de forma que estas personas comprendan y vivan la estrategia que se pretende con pasión. 186


Íntimamente ligada con la estrategia se encuentra la táctica. Mientras la estrategia transfiere la visión en un plan a largo plazo, la táctica definirá los pasos específicos para implementar dicha estrategia, pero veamos los pasos generales para realizar una correcta planificación estratégica: -

-

-

Definir objetivos: de forma amplia para considerar todas las posibilidades. Analizar el entorno: económico, de mercado, regulatorio, analizar todas las oportunidades y amenazas. Considerar los recursos: analizándolos por fortalezas y debilidades: beneficios por productos, personas, educación, habilidades, capacidades de producción, canales de venta, etc. Identificar acciones: o lista de tareas que deberá llevará a la empresa a cumplir sus objetivos. Implementar el Plan. Calendarizar, monitorizar y seguir hitos. Implementar acciones. Monitorizar el progreso.

Este paso de la estrategia a la táctica para la implementación del proyecto, puede todavía ser extendido hacia una arquitectura de la organización, que incluya el conjunto de elementos (objetivos, estrategias, modelos de negocio, procesos, etc.) que alineados entre sí, permitirán conformar la Cadena de Valor entregada a los clientes. Esta alineación comienza con los niveles más altos (estratégicos) hasta los más bajos (operativos) siguiendo un camino como el siguiente: -

-

-

-

Misión: es el nivel más alto y explica por qué existe la empresa. Estrategia: lo que tenemos que hacer para cumplir con la misión. Se suele hacer uso del análisis SWOT de fortalezas, debilidades, oportunidades y amenazas, para decidir cuál es el mejor camino que debe seguir la estrategia. Modelo de negocio: cómo vamos a hacer el negocio para obtener un beneficio ofreciendo una propuesta de valor a nuestros clientes. Nuestra propia propuesta de valor. Procesos de negocio: estos son las secuencias de actividades que relacionadas entre sí reciben unas entradas y producen unas salidas. Estos procesos pueden ser automatizados. Tecnología: necesaria para apoyar los procesos.

En este despliegue de la estrategia, vemos como para alcanzar sus objetivos, todas estas áreas deben actuar en armonía y perfectamente alineadas 187


entre sí y donde cada vez más, nos encontramos con la necesidad de alinear el negocio y la tecnología a partir de la estrategia empresarial, para no implementar las tecnologías de la información de forma aislada, como si en la tecnología por sí misma, en un ERP, en el desarrollo de un aplicativo específico, una aplicación para dispositivos móviles o una campaña en redes sociales, estuviese la única clave o tabla de salvación de nuestra empresa. Hoy en día asistimos al surgimiento de las denominadas “redes sociales”, que las empresas están usando de una forma programática. Tratamos de introducirlo en nuestros negocios a través de nuevos modelos tecnológicos asociados al marketing online, pero no cambiando nuestros procesos, modelos y estructuras organizacionales para orientarlas a esta nueva realidad y aprovechar todas sus oportunidades. En las redes sociales, por ejemplo suelen verse los efectos de nuestros procesos empresariales, a veces en forma de alabanzas y otras en forma de críticas. Cuando estas últimas exceden lo razonable para la empresa, esta suele optar por contratar una campaña en redes sociales, de mejora de reputación online o a un community manager que resuelva el problema, pero lo que está haciendo la empresa es actuar sobre los efectos visibles y no sobre las causas que originan ese problema, el cual estará relacionado a un mal producto o servicio prestado por la empresa, que a su vez estará asociado a un proceso ineficiente que de no fallar, y si este cumpliese con aquello para lo que fue diseñado, no generaría el problema que vemos reflejado en las redes sociales. El atacar el problema por arriba, por los efectos y no por las causas del mismo, sería como comprar un coche, no por su calidad o garantías de buen funcionamiento, sino que lo hiciésemos por disponer la empresa de un magnífico servicio de reparaciones, cuando lo ideal sería que nuestro coche no fallase nunca. Alguien dijo en cierta ocasión: "there are not it projects, only business process that relay on it” para que no olvidemos las bases sobre las que se asienta nuestro negocio, la necesidad de una estrategia y unos buenos procesos que la soporten, pues en su correcto funcionamiento, nos ahorraremos muchos problemas, que a veces intentamos resolver mediante parches en otras batallas que no atacarán el origen del problema, por lo que este es probable que vuelva a reproducirse. Esta tendencia a recurrir a la solución tecnológica como salvavidas de urgencia para muchos problemas empresariales, sin analizar los aspectos de negocio, es un error en el que caen muchas empresas, invirtiendo grandes cantidades de dinero y recursos en soluciones no alineadas con el negocio y que si bien a corto plazo pueden camuflar los problemas, a medio y largo plazo conducirán a estructuras de TI y culturas organizacionales totalmente desestructuradas. 188


No quisiera dejar este apartado sobre la estrategia sin llamar la atención sobre la importancia de su implementación. Uno de los métodos más usados para la elección de la estrategia, la especificación y medición de los objetivos, el modelo de negocio y los principios que deberán regir el comportamiento de la organización es el Balanced Score Card. Aunque hablaremos más adelante de esta metodología, recordaremos aquí a Kaplan, uno de los autores que crearon esta metodología, cuando afirmaba que por un lado las empresas tienen que definir sus estrategias y por otro lado tienen que implementarlas, y que es en esta segunda parte donde las empresas tienen las mayores dificultades. A pesar de que resulte obvio, al igual que las buenas intenciones, las buenas estrategias, si no se implementan, no sirven de nada y no pasarán de ser simplemente un conjunto de buenas intenciones. En muchas ocasiones culpamos a la estrategia cuando nuestro proyecto fracasa, cuando lo que casi siempre falla es la implementación de esa estrategia, o lo que es lo mismo, los procesos, pues son estos los encargados de implementar la estrategia en la organización y el éxito de nuestro modelo de negocio estará en unos pocos procesos, que alineados con la estrategia y objetivos de la empresa y haciendo uso de la tecnología y las herramientas de mejoras de procesos, permitirán que la empresa desarrolle todas sus capacidades y potencial. Sobre como alinear la estrategia con los procesos y la tecnología es sobre lo que trataremos en los restantes apartados de este capítulo.

Arquitectura empresarial. De la necesidad de alinear la estrategia con la tecnología y conseguir que los procesos de negocio de la empresa sean soportados y facilitados por la tecnología para que estos sean más eficientes y poder alcanzar las metas de negocio, surgen las Arquitecturas Empresariales (AE). El desarrollo de estas arquitecturas y los frameworks que nos ayudarán en su diseño y definición, se dirigen tanto a orientar las iniciativas tecnológicas, de forma que estas apoyen el cumplimiento del los procesos y la estrategia, como también nos sirvan como referencia para las empresas que quieran implantar una solución informática que integre el negocio, los datos, las aplicaciones y la tecnología, para cubrir las necesidades actuales y futuras del negocio y reducir la brecha que anteriormente comentábamos entre las áreas de negocio de las de TI. 189


La AE englobará a todos los aspectos de la organización para diseñar como los distintos bloques de esta, junto a los elementos que la componen, pueden de forma sistémica, estructurarse y organizarse para ejecutar la estrategia en forma de procesos operacionales, que serán en última instancia los que conviertan en realidad esa estrategia. En este proceso, la Estrategia decide la dirección que debe tomar la organización, la Arquitectura de Negocio especifica el diseño organizacional necesario para cumplir con esa estrategia y los Procesos y operaciones de la empresa ejecutarán esta arquitectura de negocio.

Las Arquitecturas Empresariales (AE) representan un acercamiento holístico e integral a las organizaciones que cubre los procesos de negocio, los sistemas de información, la infraestructura tecnológica y las personas, para describir como estas se integran y trabajan conjuntamente como un todo y servirán de ayuda para gestionar la creciente complejidad tecnológica de las organizaciones. Esta visión integral proporcionada por las AE, nos permitirá capturar la complejidad asociada a las empresas, identificando todos y cada uno de los componentes que la forman, para producir un todo coherente y articulado, con el cual afrontar los cambios sin temor a adoptar los procesos y tecnologías necesarios para poder llevar adelante estos cambios, así como el diseño de la configuración que precisaremos para convertir esta estrategia en iniciativas claras y concretas. Las AE, inicialmente se plantean desde una perspectiva en tres niveles: estrategia, procesos y sistemas de información, en el que la estrategia define sus mercados, productos, servicios, objetivos y metas qué se quieren alcanzar, los procesos proporcionan los medios operativos para alcanzar los objetivos definidos en la estrategia y en el nivel de los sistemas de informa190


ción se automatizan estos procesos apoyándose para ello en la infraestructura tecnológica. Sin embargo, actualmente se divide la AE en cuatro vistas o perspectivas: -

-

-

-

Arquitectura de Negocio: que traduce las estrategias y objetivos de alto nivel en requerimientos para el negocio y describe la estructura organizacional, de procesos, sistemas de planeación y control, mecanismos de gobierno, políticas y procedimientos. Arquitectura de Información: referida a los activos físicos y lógicos de los datos, fuentes y tipos de información que existen en la empresa para garantizar la calidad de estos datos y que cualquier persona de la organización pueda acceder a estos y la integre a su propio conocimiento. Esta arquitectura será la que permita la gestión de los recursos de información y representará el flujo y modelado de la información en toda la organización a través del diseño de los modelos entidad-relación y de bases de datos. Arquitectura de Sistemas: o de aplicativos funcionales de apoyo al negocio, que define que aplicaciones son relevantes para la empresa. Arquitectura Tecnológica: el marco tecnológico de plataformas hardware, servidores, redes, firewalls, de bases de datos y dispositivos de almacenamiento y copias de seguridad que soportarán a las distintas soluciones de negocio.

Estas cuatro perspectivas permiten entender los distintos elementos que forman una empresa y como estos se interrelacionan para crear un entorno de TI unificado que de soporte a la estrategia de la empresa. Para la definición de la AE, detallaremos los elementos que compondrán la misma y especificaremos las relaciones entre estos componentes, identificando y definiendo qué hacemos y que productos y servicios ofrecemos a nuestros clientes y como los producimos. En este proceso, traduciremos la visión de la empresa y su estrategia, a través de la conformación de una AE que describa la manera en que la organización y la tecnología operarán para ejecutar las operaciones de negocio. Esta arquitectura incluirá la estrategia y objetivos de la organización, objetivos organizados jerárquicamente, las capacidades de los que disponga la organización, los procesos y las salidas que producen, modelaremos la cadena de valor que ejecuta la empresa y en especial los procesos que representan su “core” de negocio, la estructura de la organización, el modelo de datos, las aplicaciones e infraestructura 191


de TI de toda la empresa de una forma sencilla y fácil de entender, de forma que dispongamos de los componentes principales de la organización y la relación entre los mismos para conseguir los objetivos de negocio. Las Arquitecturas de Procesos Empresariales son usadas muchas veces como guía en muchos proyectos de calidad, Six Sigma y Lean, así como de punto de partida de proyectos en BPM. La Arquitectura de Negocio y BPM pueden operar conjuntamente para llevar adelante una estrategia empresarial, donde la Arquitectura de Negocio proporcionará el contexto para indicar qué se debe hacer y BPM, como disciplina centrada en los procesos de la empresa, recogerá esta orientación e implementará la definición de la estrategia en iniciativas, de forma que se cierre la brecha entre la estrategia y su ejecución.

Además de las Arquitecturas de Negocio para describir cómo operan los negocios vía su estructura organizativa y acciones que deben ser realizadas, existen también otros tipos de arquitecturas y especificaciones que nos pueden ayudar a definir y especificar nuestras arquitecturas organizacionales y de procesos como la Business Process Architecture (BPA), la cual define la arquitectura a alto nivel de todos los procesos de negocio y las relaciones entre ellos. BPA es mucho más amplio que los modelos e incluye los subprocesos y actividades de negocio a través de la cadena de valor, las interacciones entre procesos y los recursos humanos y materiales así como los indicadores para la medición de los procesos. De esta forma BPA conecta la estrategia de negocio con los procesos, proveyendo no sólo de un entendimiento de cómo realmente funciona el negocio sino también de un marco sobre el cual sugerir mejoras. Para la realización de las Arquitecturas Empresariales, veremos a continuación distintos frameworks, estándares y modelos de referencia que nos ayudarán en este proceso. 192


Frameworks, Estándares y Modelos de Referencia. Dependiendo del tamaño de nuestra organización y si esta es pequeña, es posible que una sola persona o un reducido número de ellas puedan realizar el modelado de procesos de nuestra organización, pero si nuestra empresa es más grande y además interactúa con otras, necesitaremos de modelos organizacionales y de procesos con indicadores de medidas sobre los mismos para orientarnos en como operar y diseñar nuestros propios procesos. El modelado de negocios no está enfocado a la generación de un solo modelo capaz de representar toda la empresa, por lo que existen tipos de modelos o vistas, centradas cada una de ellas en alguna dimensión específica de la empresa: procesos, organizacional, de sistema de información, etc. Para el desarrollo de nuestros propios modelos, deberemos realizar benchmarking y buscar modelos de Arquitecturas Empresariales dentro de los numerosos marcos de referencia (frameworks), estándares y modelos de referencia, los cuales deberemos integrar para la definición de nuestras propias arquitecturas y modelos de negocio y seguir la cascada, para desde la definición de la estrategia, definir y acelerar el despliegue de la arquitectura de procesos de negocio de nuestra organización. Los Frameworks definen un conjunto estandarizado de conceptos, prácticas y criterios para enfocar una problemática concreta, que sirven de referencia para enfrentar y resolver problemas similares. Por otra parte, los Modelos de Referencia son una representación gráfica, matemática o verbal, de forma simplificada, de un concepto, fenómeno, relación o estructura de algún aspecto del mundo real y que también nos servirán para representar los procesos de negocio. Los Modelos de Referencia contienen conceptos, axiomas y relaciones relacionados con un dominio particular de un problema y es independiente de estándares, tecnologías o cualquier otro detalle. La complejidad de cualquier empresa o sector hoy en día es enorme. En los negocios y a pesar de la tecnología, se cumple la paradoja de la productividad, según la cual, existe una gran brecha entre el desarrollo de la potencia en los ordenadores y el relativamente lento aumento de la productividad empresarial. Las empresas son cada vez más complejas de gestionar y cada vez es más difícil controlar todos los procesos en los que interviene nuestra empresa. Recordando lo que Peter Senge entendía por complejidad dinámica: “cuando una acción tiene una serie de consecuencias locales y 193


otras muy diferentes en otras partes del sistema, estamos hablando de complejidad dinámica, o sea, cuando acciones obvias en una parte tiene consecuencias no obvias.” y lo que un colega de Senge, John Sterman, entendía como necesario para solucionar esta complejidad: “solucionar la complejidad consiste en encontrar la mejor solución entre un número ilimitado de posibilidades, el número de componentes o combinaciones que debemos considerar en un sistema para tomar una decisión.” Si asumimos el entorno empresarial actual como de una complejidad dinámica, entonces, una de las mejores prácticas que podemos llevar a cabo para reducir esta complejidad y no realizar experimentos empresariales arriesgados con una infinidad de posibilidades, será el recurrir a los estándares y modelos de referencia para conocer las mejores prácticas emprendidas por otras empresas en distintos sectores, para a través de su experiencia, diseñar nuestros negocios y nuestras propias Arquitecturas Empresariales.

Frameworks: Los procesos generalmente no son diseñados desde cero sino que se identifican en la propia organización o se extraen de mejores prácticas y estándares existentes como los que veremos a continuación. Los Business Process Frameworks son parte de las BPA y describen como las cadenas de valor de una empresa son expresadas vía una red de procesos de negocio. Estos Frameworks son una descripción de un conjunto de actividades y procesos de alto nivel asociados con métricas para poder medir su rendimiento, buenas prácticas de gestión y que describen como opera un negocio en una determinada cadena de valor e incluyen un desglose hasta los niveles más bajos de actividades, convirtiéndose en una valiosa herramienta para organizar un negocio y describir sus procesos y tareas de forma más rápida y eficiente, basándonos en las mejores prácticas de distintos sectores. Existen varias metodologías, frameworks y especificaciones de procesos para la realización de estas Arquitecturas Empresariales, de forma que podamos conceptualizar y describir los elementos que la componen como el framework de Zachman, desarrollado en 1980 en IBM y uno de los primeros en abordar la especificación de las Arquitecturas Empresariales. Este framework, que todavía sigue siendo de los más utilizados, mapea en una matriz las preguntas: Qué, Dónde, Cuando, Por qué, Quien y Cómo, para facilitar la comprensión de la empresa, y representar su arquitectura pero es un 194


framework que no está orientado a procesos. En los primero años del siglo XXI, comenzaron a desarrollarse otros framewoks, no sólo enfocados en TI sino también en como las TI deberían dar soporte a los procesos de negocio. Los CIO (Chief Information Office), pasaron a involucrarse en las áreas de negocio y en la forma en que la tecnología podía mejorar de los procesos de negocio. Comenzaron así a desarrollarse los frameworks más conocidos y que veremos a continuación. La idea con todos ellos es que no reinventemos la rueda y nos basemos para el diseño de nuestros procesos en las mejores prácticas y procesos ya probados, para aplicarlos en nuestra organización, pues seguro que de todos ellos sacamos ideas para nuestros procesos de negocio por lo que deberían siempre ser consultados antes de diseñar nuestros propios procesos.

Modelos de Referencia: Un modelo de referencia es algo que contiene la idea básica de algo y que se puede establecer como referencia para múltiples propósitos. Los “Process Reference Models” integran los conceptos de reingeniería de procesos, benchmarking y mejoras prácticas dentro de un ambiente específico como se muestra en el siguiente gráfico. BPR

Capturar el estado actual de los procesos de negocio y obtener el como deberían ser mejorados.

Benchmarking

Best Practices

Process Reference Model

Capturar el estado actual de los procesos de negocio y obtener el como deberían ser mejorados. Cuantificar las mejoras operacionales de empresas similares. Conocer los que mejor hacen sus procesos.

Cuantificar las mejoras operacionales de empresas similares. Conocer los que mejor hacen sus procesos.

Conocer las mejores prácticas de gestión y soluciones software existentes.

Conocer las mejores prácticas de gestión y soluciones software existentes.

195


TOGAF: TOGAF (The Open Group Arquitectural Framework), presenta una metodología y procesos detallados para el diseño y especificación de Arquitecturas Empresariales, la cual mostramos de forma resumida en el siguiente gráfico:

TOGAF se basa en cuatro dimensiones: -

-

-

Arquitectura de Negocios o de procesos de negocio: la cual define la estrategia de negocio, la gobernabilidad y los procesos clave de la organización. Arquitectura de aplicaciones: la cual provee de un plano para cada uno de los sistemas de aplicación que se quieran implementar, las interacciones entre estos sistemas y sus relaciones con los procesos de negocio. Arquitectura de Datos: la cual describe la estructura de los datos físicos y lógicos y los recursos de gestión de estos datos. Arquitectura tecnológica: que describe la estructura de hardware, software y redes requerida para dar soporte a la implementación de las aplicaciones principales.

Para TOGAF, la Arquitectura Empresarial es un requisito previo para poder trabajar en la arquitectura de empresa desde otros puntos de vista y es por ello la primera que debe ser analizada antes que otras arquitecturas 196


como la de la información, de datos, aplicaciones, tecnológicas, organizacionales o de recursos. TOGAF es un modelo de referencia que puede ser usado libremente (sin costo) por cualquier organización.

APQC Process Classification Framework: APQC (American Productivity & Quality Center), utilizado para conocer mejores prácticas, investigación y benchmarking. Dispone de modelos estándar de industrias específicas. Tiene 12 niveles de categoría de procesos (5 operacionales y 7 de soporte a procesos) y 4 niveles de detalle: -

Categoría 1.0 Grupo de procesos 1.1 Procesos 1.1.1. Actividad 1.1.1.1

197


Los procesos se agrupan en dos categorías: Operacionales y de Gestión y Soporte. Como vemos en el diagrama, donde hay 12 procesos de negocio identificados. Es bastante recomendable el visitar su página web para cada proceso que iniciemos en nuestra organización, en busca de procesos y buenas prácticas que nos puedan ayudar e inspirar en la definición y diseño de nuestros procesos.

SCOR: Es un marco de referencia y una metodología para la evaluación y construcción de cadenas de sumninistro en la que interviene varias empresas. El modelo SCOR (Supply Chain Operations Reference model, SCORmodel) nos permite representar, analizar y configurar una cadena de sumnistro. Desarrollado en 1996 por el Supply-Chain Council, SCOR se centra en la definición de los procesos centrales de la organización y une los procesos de negocio, los indicadores de gestión, las mejores précticas y las tecnologías, en una estructura unificada para apoyar la comunicación entre los intervinientes en una cadena de suministro y sus actividades relacionadas y puede ser utilizado tanto para cadenas simples como las muy complejas. El modelo SCOR dispone además de KPI´s (Key Performmance Indicators) o Indicadores de rendimiento, para comparar diferentes alternativas y estrategias de los participantes en la cadena de suministro. SCOR está organizado entorno a cinco procesos principales de gestión: Planificación (Plan), Aprovisionamiento (Source), Manufactura (Make), Distribución (Deliver) y Devolución (Return), de forma que el modelo abarca todas las interacciones con clientes, las transacciones de materiales con los proveedores hasta “los clientes de los clientes” e interacciones con el mercado. SCOR contiene tres niveles de detalle: -

198

Nivel Superior (Tipos de Procesos): se analizan las bases competitivas (Basis of Competion) y se establecen los objetivos de rendimiento competitivo (Competitive Performance


-

-

Targets), se comparan estos indicadores con los de otras empresas y sectores y se califican como: iguales, con ventaja o superiores, de forma que podamos situar nuestra organización y como se encuentra esta para priorizar los proyectos en que debemos trabajar. Nivel de Configuración (Categorías de Procesos): en este nivel existen 26 categorías de procesos: 5 de Plan, 3 de Aprovisionamiento, 3 de Manufactura, 4 de Distribución, 6 de Devolución y 5 de Apoyo. En este nivel se representa el estado actual de los procesos, para después establecer, como estos deberían ser, el estado deseado, usando las 26 categorías de procesos y los Diagrams de Hilos (Thread Diagram) también denominado Mapa de Procesos de SCOR. Nivel de elementos de Procesos (Descomposición de los Procesos): en este nivel se descomponen las categorías en elementos de procesos (Process Elements) que se presentan en secuencia lógica con sus entradas y salidas para cada uno de ellos y se evalúa el rendimeinto de cada proceso mediante el uso de indicadores.

Para los tres niveles, SCOR proporciona indicadores de rendimeinto asociados a: Fiabilidad (Reliability), Flexibilidad (Flexibility), Velocidad de atención (Responsiveness), Coste (Cost) y Activos (Assets). SCOR no incluye los siguientes aspectos: ventas y marketing, desarrollo de producto, Investigación y desarrollo y algunos elementos de servicio post-venta. El uso del modelo SCOR nos puede ayudar a identificar indicadores, encontrar oportunidades de mejora e identificar mejores prácticas antes de desarrollar nuestros propios procesos. Además, SCOR ofrece amplias descripciones en sectores industriales que pueden ayudar a una empresa a comparar sus medidas con las de otras empresas. SCOR, aunque diseñado para la optimización de la cadena de valor, es generalmente utilizado para describir procesos en muchos tipos de organziaciones. Existe una aproximación alternativa a SCOR que es el VRM (Value Reference Model).

199


CobIT: Control Objectives for Information and related Technologies (CobIT), creado por el IT Governance Institute (ITGI), es una serie de guías para ayudar a las organizaciones en la mejora de la gobernanza de TI con la creencia de que la gestión efectiva de TI producirá mejoras en el desarrollo de las empresas. Todas las organizaciones tienen la necesidad de información, la cual es utilizada por los procesos de negocio para alcanzar los objetivos de negocio y quien provee de esta información son los sistemas de TI gestionados por los proceso de TI. CoBIT establecerá que procesos debo gestionar de TI en mi organización y cómo puedo controlarlos, para lo cual y partiendo de una alineación con los procesos de negocio define y especifica los objetivos que deben tener los procesos de TI y los controles que debo tener sobre estos procesos, estableciendo además que criterios debe tener esa información, que recursos deben existir en la organización, que procesos se deben ejecutar, que requerimientos y validaciones deberé tener para el ingreso de datos en el proceso, la transformación y salida de estos para impedir que la información sea errónea o que los datos pasados no puedan ser manipulados o modificados. CobIT, siguiendo el ciclo de Demming, presenta 4 niveles o dominios de control por objetivos de TI: Planificación y organización, Adquisición e implementación, Entrega y soporte y Monitorización, sobre los cuales se pueden establecer objetivos de control e implementar controles automatizados. Este control por objetivos es un propósito o resultado deseable como por ejemplo: garantizar la continuidad de las operaciones ante contingencias, para la cual, podremos implementar uno o varios controles indicados en el modelo, por ejemplo: realizar copias de seguridad, realizar copias redundantes, etc. En CobIT se organizan las actividades dentro de un marco general aceptado que establece los controles de gestión sobre los objetivos perseguidos, enlazando TI con requerimientos de negocio. CobIT tiene 34 objetivos de alto nivel que cubren 215 objetivos de control, clasificados en los cuatro niveles que hemos visto, con los cuales determina un conjunto de mejores prácticas para la seguridad, la calidad, la eficacia y la eficiencia de TI, alineando la tecnología con el negocio al tiempo que nos permite identificar riegos, dar valor al negocio con las TI, gestionar los recursos y medir su desempeño. CobIT proporciona además indicadores, procesos y mejores prác200


ticas para ayudar a maximizar la inversión en TI, su control y gobernanza en la empresa. CobIT se ha convertido en un estándar para el buen gobierno de los sistemas de información, se ofrece gratuitamente y está realizado con el esfuerzo de cientos de voluntarios de todo el mundo. Objetivos de Negocio

CoBIT INFORMACIÓN

MONITOREAR Y EVALUAR RECURSOS

PLANEAR Y ORGANIZAR

ENTREGAR Y DAR SOPORTE ADQUIRIR E IMPLANTAR

CobIT proporciona, como ya comentamos, indicadores para valorar la madurez de la organización y presenta unos niveles para la misma: -

-

Nivel 0: proceso incompleto, no existe o no cumple con los objetivos. Nivel 1: proceso ejecutado. Nivel 2: proceso gestionado, el proceso no sólo se encuentra en funcionamiento, sino que es planificado, monitorizado y ajustado. Nivel 3: proceso definido, el proceso, los recursos, lo roles y responsabilidades se encuentran documentados y formalizados. Nivel 4: proceso predecible, se han definido técnicas de medición de resultados y controles.

201


-

Nivel 5: proceso optimizado, todos los cambios son verificados para determinar el impacto, se han definido mecanismos para la mejora continua, etc.

Balance Score Card (BSC): En 1992, Robert Kaplan y David Norton introdujeron la idea del Cuadro de Mando como medio para monitorizar y ayudar en la gestión de los negocios. Estos mismos autores desarrollaron la idea de los mapas estratégicos, para ayudar en la creación de los cuadro de mando, estos mapas muestran los objetivos estratégicos para la generación de valor, mostrando las causas y efectos de esos objetivos sobre la estrategia. Estos objetivos eran clasificados según las cuatro áreas del Cuadro de Mando o Balance ScoreCard. Balance Scorecard (BSC), provee de un marco para traducir la visión y estrategia de la empresa en datos reales. Está organizada en cuatro niveles o perspectivas: financiera (beneficio, cash-flow), clientes (satisfacción, retención, nuevos clientes, mercados), procesos internos de negocio (procesos críticos, innovación en procesos, nuevos procesos), aprendizaje y crecimiento (personas, sistemas, procedimientos organizacionales). En el entorno de BPM, usaremos Balanced Scorecard, pero siempre partiendo de la estrategia y de la alineación de BSC con los objetivos de negocio, definiendo previamente la arquitectura de procesos para usar BSC como herramienta ideal para las medidas de cumplimiento de los objetivos tanto de los procesos individuales como de toda la cadena de valor. Otros estándares: Basel II: Muy de moda ahora en España, es un estándar internacional sobre los requisitos mínimos de capital y el dinero que un banco tiene que guardar y no prestar para ser solventes. Sarbanes-Oxley: A pesar de ser una normativa de obligado cumplimiento para organismos financieros, representa una oportunidad para las empresas para la mejora y entendimiento de sus procesos.

202


Sarbanes-Oxley formaliza los controles internos y procesos que deben regular la información financiera que publica una empresa, con objeto de proteger a sus inversores, socios y clientes, de tal manera que estos organismos dispongan de procesos exactos sobre como manejan esta información, asegurando que esta información que publiquen sea cierta y que no ocurran casos como Enron, Worldcom o Tyco donde la manipulación de los sistemas de información permitió un gran fraude que resultaron en grandes pérdidas y crisis en la confianza de los inversores. La información de los estados financieros y del balance de una organización so hoy en día proporcionados por los sistemas de información. Si los sistemas de información son los que proveen de los datos financieros, a quien vamos a auditar para saber si estos datos son ciertos y no han sido modificados o manipulados, pues obviamente a TI, por lo que el instrumento que usamos hoy para asegurar que la información dentro de una organización sea la que tiene que ser: correcta, exacta, fiable, confiable, disponible, etc. es CoBIT que nos proporcionará gobierno y control de las TI. De hecho CoBIT comenzó como una herramienta de auditoría que ha ido evolucionando hasta convertirse en una herramienta de management. Regulaciones como Sarbanes-Oxley requieren que las empresas sean capaces de controlar sus procesos e indicadores precisos de los mismos para cumplir con estas regulaciones gubernamentales y reglas de negocio. Entre las regulaciones que establecen se encuentran por ejemplo, el que los informes financieros sean revisados y firmados y que estos representen la situación real de la compañía, de sus resultados y situación financiera. Sarbanes Oxley obliga a que las empresas provean también de información detallada de sus sistemas de control y auditorías, la obligación de comunicar y hacer pública cualquier cambio en su situación financiera y otras regulaciones cuyo incumplimiento pueden acarrear penas de prisión. Otros Frameworks que pueden resultar de utilidad en determinados sectores son: eTOM (eBusiness Telecom Operations Map) en empresas de telecomunicaciones, VRM para la cadena de valor, ACORD para el sector de los seguros, EFQM el cual es un estándar de calidad europeo para las empresas, el SEi (Software Engineering Institute) o ITIL y CMMI (Capability Maturity Model) para la evaluación de procesos de TI. Estos estándares y framewoks deben ser consultados en busca de acelerar la adpoción de los procesos y arquitecturas de procesos que más se ajusten a nuestro negocio, pues al igual que un médico no prescribe la 203


misma receta a distintos tipos de pacientes, no todas las organizaciones son iguales y todas tienen sus particularidades, por lo que los modelos vistos en este capítulo, nos servirán de inspiración para desarrollar nuestros propios frameworks en base a que hacen otras organizaciones y a modelos que han sido probados y considerados como buenas prácticas.

Modelos organizacionales. Las Arquitecturas Empresariales, incluyen también las estructuras organizativas, por lo que en su especificación incluiremos un modelado de la organización, de cómo esta se organiza en unidades de negocio y como se relaciona con otras empresas, pero no en como realiza su trabajo, pues esto lo haremos en procesos. En los modelos organizacionales describiremos los grupos de trabajo y departamentos, quien interacciona con quien, jerarquías en el reporte de información (quien informa a quien), los roles de las personas involucradas en la misma, sus responsabilidades y que hace cada una dentro de la organización. Con toda esta información crearemos un Modelo Organizacional que puede ser usado para representar como es actualmente la organización así como la descripción de cómo será tras el cambio o la realización de un proyecto de BPM, lo cual nos ayudará para la gestión del cambio y la comunicación durante el desarrollo del proyecto. Para la realización de estos modelos organizacionales, no existen estándares y cada organización uso sus propios modelos. El modelo tal vez más aproximado a un estándar es el de Rummler-Brache.

El Business Motivation Model (BMM). El Business Motivation Model (BMM), es una especificación del OMG (Object Management Group) establecida en el año 2006 y convertida en estándar para capturar y definir la estrategia empresarial como paso previo al diseño y modelado de los procesos de negocio. El BMM es un meta-modelo que define los principales elementos que integran un plan de negocio y que proporciona las bases para planificar nuestros procesos de negocio, asegurando que estos estén alineados con la estrategia y los objetivos de negocio. Para ello el BMM, desde una perspectiva de negocio, permite identificar y definir los principales factores que moti204


van el desarrollo de un plan de negocio y las interrelaciones entre estos como paso previo al diseño de soluciones técnicas y como base sobre la que desarrollar las mismas. En el BMM podremos definir los elementos que integraran nuestros planes de negocio y establecer unas relaciones claras entre las políticas, las reglas, los fines y los medios que empleará la empresa para conseguir sus objetivos empresariales. Como ya venimos indicando, uno de los problemas al que nos enfrentamos a la hora de comenzar un proyecto de BPM es por donde empezar el proyecto y aquí nuestra recomendación es comenzar por arriba, por la visión y la estrategia de la organización, para alinear esta estrategia con el diseño de los procesos, las personas y la tecnología. EL BMM está desarrollado desde una perspectiva de negocio y de esta forma, los planes de negocio que generemos con el BMM, serán la base fundacional para el diseño de sistemas y el desarrollo técnico, conectando la solución tecnológica con la de negocio. Al comenzar con nuestro proyecto, las preguntas que debemos hacernos y que nos ayudará a contestar el Motivation Model son: ¿por qué existe nuestra empresa?, ¿cuál es su razón de ser?, ¿qué metas desea alcanzar? y ¿qué usará nuestra empresa para conseguir estos resultados? Estas preguntas sobre el por qué, qué, cómo, cuándo y dónde, deberíamos realizarlas en cualquier organización que desee alinear sus implantaciones de TI con la visión, las metas, los objetivos, estrategias, tácticas, reglas y procesos de su negocio, de forma que estos aspectos de negocio se conecten con las especificaciones software y de sistemas de una forma coordinada y estructurada. Esta sincronización entre negocio y TI toma ahora más importancia que nunca con la aparición de las arquitecturas orientadas a servicios (SOA), los web services y la computación en la nube, donde a partir del BMM podremos trazar las relaciones de negocio con los servicios y arquitecturas software que les darán soporte. Los siguientes apartados que describen el BMM nos ayudarán a diseñar y entender la estrategia sobre la que fundamentar la implementación de una gestión por procesos, de forma que pasemos de ser unos observadores de los resultados, que con posterioridad modifican y rediseñan estos procesos, a tomar las riendas de nuestro negocio y gestionar los procesos y posteriormente controlar los resultados.

205


El Business Motivation Model tendrá también un importante valor como herramienta para comunicar la estrategia a los stakeholders, al equipo de proyecto y al resto de la organización, así como para analizar y comparar esta estrategia con la de otras empresas e incluso simular el funcionamiento de la misma para buscar mejoras, estrategias alternativas o problemas en el diseño realizado. NOTA: en toda la descripción del BMM, hemos preferido mantener las siglas y conceptos en inglés utilizadas en el BMM por el OMG, por ser mejor entendidas de esta forma los conceptos descritos en el mismo y por considerar que con la descripción dada de cada uno de ellos, se entenderán perfectamente los términos y conceptos descritos en este modelo. La estructura general del BMM es la mostrada en el siguiente diagrama:

Los puntos básicos del modelo son: -

206

Ends (Finalidades): cosas que la empresa quiere alcanzar: Visión, Goals and Objectives. Means (Significados): cosas que la empresa empleará para alcanzar esos Ends: Mission, Strategy, Tactics, Business Policies and Business Rules. Maneras para lograr esas cosas. Cosas que nos influyen.


-

Influencers (Influenciadores): cosas que nos pueden influir y que dan forma a los elementos del Business Plan. Assesments (Valoraciones): decisiones que tomamos sobre los Influencers. Los conforman los impactos que los Influencers tienen en los Ends y los Means. Evaluaciones, opiniones, análisis. Lo que aplicamos a los Influencers en función del impacto que estos pueden tener sobre los objetivos.

Ends, Means e Influencers están conectados unos con otros para responder a la siguiente pregunta: ¿qué necesito para alcanzar lo que la empresa desea alcanzar? A continuación vemos en detalle cada uno de las partes del modelo.

Ends.

Los Ends describen el estado ideal futuro de la empresa: incluyen Vision y Desired Result, que contiene Goals y Objectives.

207


Vision (Visión): Es un estado futuro que desea alcanzar la empresa, probablemente inalcanzable. Podría ser visto como lo que otras personas nos gustaría que viesen de nuestra empresa, por ejemplo, ser líderes de mercado, innovadores, etc. Desired Results (Resultados Deseables): al contrario que la Visión, los resultados deseables deben ser alcanzables y más específicos. Incluyen los Goals y Objectives. Goals (Metas): Una Meta es simplemente algo que la empresa desea alcanzar, un resultado final de la estrategia. Las Metas son aspiraciones más específicas de la empresa, soportan a la Visión y suelen ser vistas a largo plazo, concretas, de forma que podamos definir objetivos sobre estas metas. Pueden tener una descomposición jerárquica y se definen de forma cualitativa más que cuantitativa. Objectives (Objetivos): Los objetivos son los pasos para alcanzar las metas y el progreso hacia estas, deben tener fechas de finalización y criterios para determinar si son alcanzados o no, por lo que deben ser alcanzables, medibles y con un tiempo definido para su realización. Las metas por sí mismas no son suficientes, pues estas no son precisas en cuanto a los tiempos en que deben ser alcanzadas y es por ello que las metas son completadas por los objetivos. Los objetivos son resultados finales deseados como las metas, pero cambian con más frecuencia que estas, son específicos en cuanto a tiempos y deben ser medibles. Los objetivos los crearemos pensando en las metas y en las medidas que deberemos asociar a los mismos y pueden ser descompuestos también jerárquicamente. Comparados con los objetivos, las metas son a largo plazo, cualitativas (más que cuantitativas) y generales (más que específicas). Comparadas con las metas, los objetivos son a corto plazo y cuantitativos. Los objetivos se diferencian en que siempre tienen una fecha para su cumplimiento, son medibles y nos dan la medida de si nos acercamos o no a la meta. Los objetivos deben ser SMART (Specific, Measurables, Attainable, Relevant y TimeBased; o sea: Específicos, Medibles, Alcanzables, Relevantes y Basados en el tiempo). Los Desired Result son soportados por los Courses Of Action, que 208


pueden ser Estratégicos o Tácticos. Generalmente las Metas son soportadas por la estrategia y los objetivos por la Táctica. Ejemplos de Meta y Objetivo: -

Poner en marcha una tienda on-line para aumentar las ventas de máquinas. (META) Conseguir 100 nuevos clientes y 300 ventas en los primeros tres meses con la tienda online (Objetivo)

Ejemplos de Objetivos: - Financieros: o Obtener una cuota de mercado del X% en Y meses. o Aumentar las ventas en la región X un Y% en Z meses. o Alcanzar un ROI del X% en Y meses. - No financieros: o Alcanzar una satisfacción de clientes de al menos el X% en Y meses. o Reducir los tiempos de respuesta a X en Y% de llamadas. Means.

Lo que una empresa a decidido hacer para ser lo que desea ser. Son los mecanismos mediante los cuales los Ends son alcanzados. Los componentes de los Means son: La Misión, la Estrategia, la Táctica y las Directivas.

209


Mision (Misión): Estado general de la empresa, una generalización del valor que quiere producir. La Misión indica lo que una empresa hace. (Ejemplo: proporcionar material de oficina a empresas). Debe ser lo suficientemente amplia para que cubra todo el rango de actividades que pueda realizar la empresa. En su definición debe contener sólo los siguientes puntos (1 Acción (proveer), 1 Producto o Servicio (pizzas), 1 mercado o clientes (oficinas de ciudad)) Course of action (Curso de Acción): Los Course of Action son similares a los resultados deseados (metas y objetivos) en el sentido en que ambos son algo que la empresa desea alcanzar, pero los Course of Action son los medios con los que la organización alcanzará sus metas y objetivos para alcanzar unos fines determinados. Los Courses of Action pueden ser Estrategias o Tácticas. Las estrategias son más largas y difíciles de cambiar que las tácticas. Las empresas establecen estrategias y tácticas al tiempo que definen metas y objetivos. Las tácticas y estrategias también pueden ser descompuestas jerárquicamente. Los Course of Action que incluye estrategias y Tácticas, representan los elementos básicos del Plan para alcanzar los Desired Results. Los Course of Actions definen lo que se debe hacer, no lo bien que se deben hacer (esto irá en objetivos). Cada estrategia (a largo plazo) es implementada por las tácticas, que suelen más cortas. Las estrategias son seleccionadas para mover a la empresa hacia sus metas y son implementadas por la tácticas que deben ser seleccionadas para asegurar que se cumplen los objetivos. Strategy (Estrategia): Es un plan o aproximación para soportar la Misión y alcanzar los Ends. Particularmente con foco en los Goals. Tactics (Tácticas): Específicos, acciones a corto plazo que soportan las estrategias. Las Tácticas normalmente se centran en los objetivos. Directives (Directivas): Definen restricciones o requerimientos en cómo debemos dirigir nuestro negocio. Incluyen Policies y Rules.

210


Business Policies (Políticas de Negocio): Reglamentos de alto nivel. Existen para gobernar, controlar, guiar y dar forma a las Estrategias y Tácticas definiendo que se puede hacer y los límites de lo que se puede hacer.

Rules (Reglas): Reglas o Restricciones específicas en las operaciones de nuestro negocio. Deben ser concretas y derivadas de las Business Policies.

Influencers (Influenciadores):

Fuentes u orígenes de efectos que deben ser considerados en Assesments y planificados, pues afectan a la empresa. Los Influencers pueden afectar a la dirección del negocio positiva o negativamente, pero no tiene acción directa o control. Son las cosas que pueden suceder en el entorno de la empresa y pueden tener un impacto sobre la misma y que pueden incluir tendencias, competidores, activos o hábitos de la empresa. Una empresa puede tener cientos de Influencers potenciales, por lo que no podremos tenerlos todos en cuenta y deberemos seleccionar aquellos con mayor potencial de acontecer y que más relevancia tengan sobre nuestras tácticas y estrategias, metas y objetivos de negocio. Estos Influencers pueden ser Internos (de dentro de la empresa; recursos, calidad, infraestructura, hábitos) o Externos (de fuera de la empresa; clientes, mercados regulaciones, competencia).

211


Internal Influencing: Cosas dentro de la empresa, como la cultura, actitudes, infraestructura, creencias y capacidades que influencian la dirección del negocio. External Influencing: Pueden ser de una gran variedad como competidores, clientes, reglas gubernamentales o tecnológicos. Los cambios en estos influencer pueden tener un gran impacto sobre la empresa, en las oportunidades de negocio o la viabilidad de la empresa. Influencing Organization: Una organización externa que puede afectar a nuestra empresa.

Assessments (Valoraciones):

Assessment

Potential Influencer Risk Potential Reward

Assessment

Se encarga de la evaluación de los impactos (positivos o negativos) y factores que pueden influir en la empresa. Los Influencers, junto con las estrategias, tácticas y planes de transformación, son entradas a estos Assesments para su evaluación y consideración. Un Assesment determinará el potencial impacto de los Influencers, que incluirán evaluaciones de riesgos y recompensas potenciales. Los Assesment se basan en un juicio acerca de la influencia en la empresa de los Influencers y a menudo son asesorados por herramientas de Business Intelligence, SWOT y de análisis de riesgos. Las salidas de estos Assesments son decisiones acerca de los Ends y los Means. 212


Potential Influencer: Captura el resultado de los Assesments potenciales considerando sin son para ganar o perder. Risk: No todos los Influencers que afectan a las metas o estrategias de la empresa pueden considerarse oportunidades. Una amenaza o Threat puede ser como una oportunidad pero que puede ser negativo para la empresa, un Threat juzga un Influencer sobre como el Influencer puede afectar al negocio. La empresa reconoce un Influencer y juzga si este es un Threat. Un influencer es simplemente algo que puede estar pasando pero las oportunidades Threats (amenazas) son juicios acerca de cómo un Influencer afecta a la empresa. Potential Reward: Son situaciones favorables para nuestros negocios para alcanzar sus objetivos y que pueden ser explotadas para alcanzar estos objetivos. Assessment: Amenazas y oportunidades son muy parecidos, ambos son juicios. Un juicio es una evaluación de un Influencer que puede afectar a la empresa. Los Assessments pueden ser SWOT (Stregth, weakness, opportunity, threat) por lo que usaremos con frecuencia este análisis. Strengths y Weaknesses son internos a la organización. Un influencer interno puede ser juzgado como Strength si ayuda a la organización a alcanzar sus metas y estrategias o Weakness si no lo hace. El BMM y los estándares vistos en este capítulo, nos servirán para evaluar nuestra empresa y comprobar cómo se encuentra la misma ahora, como podría ser en cuanto a su arquitectura estratégica y las transformaciones que podemos llevar adelante para la mejora de su propuesta de valor y los riesgos que podemos tener en el camino.

213


214

Capítulo 6. Modelado de procesos. BPMN

Capítulo 6. Modelado de procesos. BPMN.

Tal vez una de las partes más atractivas de BPM y de las plataformas BPMS más concretamente, sea la capacidad de reducir el distanciamiento existente entre los requerimientos de negocio y los de desarrollo de software a través de una notación de modelado de procesos de negocio común y fácilmente entendible, tanto para los perfiles de negocio como los de TI. Esta notación es BPMN (Business Process Model Notation), que integrada en la gran mayoría de soluciones BPMS, nos permitirá modelar y ejecutar los procesos de negocio para su posterior monitorización y control en un entorno gráfico. Una vez vistos los distintos modelos para la definición de la estrategia y los modelos de negocio, pasamos al modelado de procesos, los cuales describirán como deberán ser realizadas las distintas tareas necesarias para la ejecución del proceso, la secuencia de ejecución de las mismas, qué trabajo será preciso realizar, con qué sistemas deberá integrase para su funcionamiento y cuándo y quién realizará ese trabajo. Este modelo de procesos será fundamental para comunicar a la organización y especialmente a los trabajadores que trabajarán sobre el proceso, cómo se deberá realizar el trabajo especificado en el diseño. Para coordinar esta secuencia de tareas, procesos y mensajes fluyendo entre distintos agentes y participantes, se ha diseñado BPMN, una notación 215


específica para el modelado de los procesos de negocio, que describe la lógica de los pasos dentro de un proceso de negocio. BPMN provee de una notación común para que las personas relacionadas con los procesos puedan expresarlos gráficamente de una forma más clara, estandarizada y completa, facilitando no sólo la estandarización de los procesos dentro de la organización, sino que además, amplía el campo de acción para que estos puedan ser compartidos y entendidos entre los diferentes socios de negocio y perfiles de la empresa tanto técnicos como de negocio. El estándar BPMN fue publicado en el año 2004 por el Business Process Management Initiative (BPMI) y posteriormente adoptado por el OMG como especificación en el año 2006, habiendo sido adoptado como estándar por todo tipo de organizaciones y fabricantes de software. El modelado de procesos es una de las bases y características fundamentales de los proyectos de BPM. Durante los últimos años se han realizado grandes esfuerzos para consensuar una notación o lenguaje de modelado capaz de describir los requisitos de negocio y que a la vez fuese trasladable a sistemas informáticos para su ejecución. Dos estándares parecen haberse posicionado como estándares para esta misión: BPMN y BPEL, los cuales se han convertido en estándares usados por prácticamente todos los fabricantes de soluciones BPMS. De esta forma, BPMN es un lenguaje formal que permite modelar, simular y eventualmente, ejecutar procesos de negocios. Su sintaxis está basada en elementos gráficos, pero tales elementos tienen una relación uno a uno con instrucciones del lenguaje BPEL, lo cual permitirá generar código ejecutable BPEL a partir de un modelo en la notación BPMN así como modificar este código haciendo uso del modelado gráfico en BPMN. Una vez analizados y entendidos los procesos de negocio que operará nuestra organización, el lenguaje BPMN nos ayudará a expresar formalmente los procesos y describir los mismos según el grado de detalle que se requiera. Aunque su principal objetivo es ser simple y fácil de usar tanto para gente de negocio como técnica, BPMN nos permitirá expresar procesos complejos y poder ejecutarlos directamente en una solución BPMS hacia un lenguaje ejecutable como BPEL. Otras notaciones para modelar procesos de negocio son: -

216

Redes de Petri: es el lenguaje de modelado más antiguo. Son la base formal y matemática sobre la que se asienta BPMN. Las re-


-

des de Petri pueden ser ejecutadas y existen diversas técnicas para analizarlas. YAWL (Yet Another Workflow Language): es un lenguaje de modelado y un software open source de workflow. EPC (Event-Driven Process Chains): es la notación soportada por fabricantes como ARIS y SAP R/3. EPC cubre un subconjunto de BPMN y YAWL, pero usa una notación gráfica dedicada.

Niveles de Uso en BPMN. -

-

-

Nivel 1. Descriptivo: usado para comunicar procesos a través de la organización. Esta descripción de alto nivel, describe los flujos esenciales del proceso de negocio ignorando complejidades e incluso las reglas de negocio. Nivel 2. Analítico: describe todas las actividades, decisiones y excepciones necesarias para analizar un proceso completamente y crear requerimientos detallados. Expresar toda la lógica de negocio y las reglas de negocio. Nivel 3. Ejecutable: modelar a este nivel depende mucho de las capacidades del BPMS que utilicemos. Actualmente para ejecutar se utiliza el lenguaje BPEL.

Elementos principales de BPMN. NOTA: al igual que hicimos con BMM, para la descripción de la notación BPMN, hemos preferido mantener las siglas en inglés utilizadas en la especificación del BPMN por OMG, incluyendo entre paréntesis su traducción recomendada por BPMteca.com. Para la representación de la notación BPMN se han utilizado los símbolos de Bizagi Process Modeler, una herramienta de modelado de procesos gratuita que forma parte de la plataforma de BPMS de Bizagi. Los elementos principales que usaremos para diagramar nuestros modelos de procesos en BPMN son: -

Flow Objects (objetos de flujo): que serán los elementos principales del diagrama. 217


-

-

-

o Event (evento) o Activity (actividad) o Gateway (compuertas de decisión) Connecting objects (objetos de conexión): elementos de comunicación entre objetos de flujo. o Sequence flow (flujo de secuencia) o Message flow (flujo de mensaje) o Association (asociación) Swimlanes (canales): para organizar los procesos. o Pool (contenedor) o Lane (calle) Artifacts (artefactos): para documentar el modelo.

A continuación pasamos a describir en detalle cada uno de estos elementos acompañándolos de ejemplos sencillos sobre su uso.

Flow Objects (Objetos de Flujo): Son los elementos que definen el comportamiento básico de los procesos. Eventos: Event (Evento)

218

Algo que ocurre durante el proceso de negocio. Los eventos afectan al flujo del proceso y suelen tener una causa (trigger) o un impacto (resultado) y se representan con un círculo. Todo proceso de negocio tiene un principio y un fin. Todos los procesos comienzan con un evento de Inicio y finalizan con un evento de Fin, entre los cuales ocurren todas las actividades con las que cuente el proceso. También pueden existir eventos intermedios, generalmente asociados a retrasos. Los eventos tienen descripciones de los mismos y atributos como por ejemplo de qué manera son iniciados. Los eventos de Inicio generalmente se inician con la recep-


ción por parte del evento de un mensaje.

De acuerdo con el momento en que los eventos afectan al flujo en BPMN disponemos de tres tipos de eventos: inicio, intermedio y fin: Evento Inicio

de

Para indicar cuando comienza el proceso y se inicia su flujo y activación. Se representa por un círculo con una sola línea. Ningún flujo puede llegar a un evento de inicio. Existen seis tipos de eventos de inicio que pueden iniciar un proceso.

Evento intermedio

Un evento que ocurre entre el inicio y le final del proceso y que se representa por un circulo con dos líneas. Los eventos intermedios indican donde ocurre algo durante la ejecución del proceso y afectan al flujo del proceso.

Evento de fin

Indica donde finaliza el proceso y se representa por una línea gruesa. Los eventos de fin no tiene ninguna salida de flujo y son usados además de para indicar el final de un proceso, para enviar un mensaje.

Actividades: Las actividades representan trabajo o tareas realizadas por miembros de la organización, las cuales pueden ser manuales o automáticas, realizadas por un usuario o por un sistema externo. Una Actividad es un pieza de trabajo que tiene un principio y un final, es realizada una o varias veces en un proceso y normalmente son pasos de un proceso de negocio mayor. Las actividades muestran un nombre y opcionalmente el tipo de actividad de que se trata. Toda actividad tiene atributos que describen los detalles del trabajo que realizan, como puede ser la descripción de la actividad, el tiempo que se necesita para completar la actividad, si puede tener re-

219


trasos o tiempos de espera, la persona que realizará la actividad, el coste de ejecutar la actividad, si es ejecutada por un software, etc. Una actividad puede ser atómica o compuesta. Los tipos de actividades que tenemos son: Procesos, Sub-procesos y Tareas. Activity or Actividad o tarea simple utiTask lizada cuando el trabajo que (Actividad o representa en el proceso no Tarea) puede desglosarse en un nivel mayor de detalle o unidades más pequeñas. Estas tareas son realizadas por humanos y tienen que ser realizadas en una determinada cantidad de tiempo. Automatic Desarrollada por un ordenaActivity (Ac- dor, programa informático o tividad Au- web service. tomática) Receive Task Es una tarea simple para que (Tarea Reci- llegue un mensaje. Una vez que el mensaje es recibido la tarea bir) es completada. También existe la tarea enviar (send task), para el envío de mensajes y una vez enviados la actividad está completada. User Activity Desarrollada por una perso(Actividad na. Usuario)

220


Manual Task Desarrollada por una perso(Tarea Ma- na manualmente, por ejemplo, archivar informes manualmennual) te. Script Task Es una tarea que ejecuta una (Tarea Códi- pieza de código en un lenguaje go) definido.

Rule Task Tarea de Reglas de Negocio. (Tarea Regla) Es una tarea que verifica una regla de negocio del proceso.

Sub Process Es un conjunto de activida(Subproceso) des incluidas dentro de un proceso. Puede desglosarse en diferentes niveles de detalle denominados tareas. Los suprocesos, son actividades descompuestas dentro del proceso que usamos para organizar y simplificar los modelos. Algunas actividades son bastante simples y no requieren de demasiado detalle sobre su implementación, pero si queremos extender una actividad, de forma más detallada por su complejidad lo podemos hacer con subprocesos que pueden ser descritos como procesos. Los subprocesos se distinguen de las actividades por te221


ner un signo “+” que nos indica que la actividad se pude descomponer y pulsando sobre el signo nos desplegaría el proceso completa que encierra en detalle. Sub Process Ad Hoc (Subproceso ad hoc)

Representan un grupo de actividades en un subproceso que no tienen relación entre ellas, son actividades aisladas que el responsable de ejecutarlas decide como se llevarán a cabo.

Veamos un ejemplo de cómo usar los subprocesos:

Y el mismo proceso con el primer subproceso desplegado:

Niveles de Precisión: Según hemos visto en los niveles de uso de BPMN al principio del capítulo, a la hora de modelar los procesos solemos empezar con actividades de alto nivel, para luego ir bajando hacia mayores niveles de detalle. Por ejemplo es normal comenzar un modelado a alto nivel representando subprocesos que luego vamos desplegando para indicar el nivel de detalle de cada uno de ellos, o representar en un primer modelo los Pools sin detallar las actividades de los mismos que luego detallaremos. 222


Gateways Los gateways (o compuertas de decisión), los usamos para modelar alternativas en el flujo de secuencia del proceso dependiendo de una condición. Se representan por un diamante y se emplean para controlar la divergencia o convergencia de la secuencia de flujo que determinarán bifurcaciones, combinaciones y fusiones en el proceso. Existen varios tipos y combinaciones para estos gateways, pero los dos tipos más simples y usados que veremos ahora son: Gateway Exclusive Decisión (Compuerta Decisión Exclusiva)

Donde sólo una de las alternativas puede ser escogida. Equivalen a la sentencia lógica “OR”.

Gateway Pararellel Decision (Compuerta Decisión Paralela)

Donde todas las opciones deben ser activadas. Todos los flujos que salgan deben ser realizados para que el proceso pueda continuar. Estos gateways se usan para sincronizar los flujos cuando todos los brazos o caminos deben ser realizados antes de la siguiente actividad y equivalen a la sentencia lógica “AND”.

El modelo para representar un Gateway exclusivo en el que sólo una de las alternativas debe ser escogidas es de la siguiente forma:

223


Veamos un modelo para el Gateway paralelo en el que los dos caminos deben ser escogidos y ambos deben finalizar para poder continuar el proceso. Este modelo de Gateway paralelo puede ser expresado de las dos formas que mostramos a continuación y ambas son equivalentes, sin embargo muchas herramientas de modelado consideran una buena práctica el usar la notación con el diamante para este tipo de flujos.

El Gateway paralelo podemos usarlo también para realizar sincronización de tareas, como en el siguiente modelo:

224


Conecting Objects (Objetos de Conexión): Que usaremos para conectar los Flow Objets. Estas conexiones pueden ser de tres tipos: Sequence Flujo de secuencia para indicar el Flow (Flujo orden de las actividades que serán de Sequen- realizadas en el proceso. Es la cocia) nexión más común para representar la secuencia entre dos Actividades y mostrar que una es realizada antes que otra. Este flujo se representa como una línea sólida con una flecha. Message Para mostrar el flujo de mensajes Flow (Flujo entre los participantes en el proceso. de Mensaje) Estos flujos de mensajes serán los únicos medios de comunicación entre los participantes o entre procesos en diferentes “pools”. Association (Asociación)

Para asociar información a través de los Artifacts (texto y otros objetos) a los objetos de flujo y proporcionar información adicional sobre distintos puntos del proceso.

Ahora que disponemos de los principales elementos con los que modelar procesos, podemos mostrar un ejemplo del uso conjunto de los mismos para describir un proceso simple de recibir un pedido, realizar el trabajo y decidir si lo enviamos al cliente o este lo recoge en nuestra tienda:

225


En el cual tenemos un evento de inicio, un flujo de proceso que sale de este a la tarea de recibir el pedido, del cual sale a un Gateway exclusivo (uno u otro, pero no los dos a la vez), en el cual se toma la decisión de si el pedido se envía al cliente o se recoge en la tienda, por lo que salen dos posibles flujos del proceso y finalmente, tenemos un evento de fin con el cual concluye el proceso. Veamos ahora el mismo ejemplo con un Gateway paralelo, donde para finalizar el proceso se debe enviar el pedido y la factura al cliente:

En este caso, para que el proceso pueda finalizar, las dos actividades que salen del Gateway (“Enviar pedido” y “Enviar factura”) deben ser realizadas y finalizadas de forma que el proceso no finaliza hasta que ambas son completadas. Podemos ver otro ejemplo en el que combinamos los dos tipos de Gateway (exclusivo y paralelo) en el caso de un proceso para el procesamiento de pedidos:

226


En este ejemplo, una vez recibimos el pedido, tenemos un Gateway en el que decidimos si se acepta o no el pedido. Si el pedido es aceptado, preparamos el mismo, tras lo cual el flujo después de esta actividad se divide en dos, por un lado enviamos el pedido y por otro enviamos factura y realizamos el cobro. Sólo cuando estos dos caminos se han completado en el Gateway paralelo puede continuar el proceso para el cierre del pedido. Swimlanes (Canales): Que usaremos para agrupar los elementos del proceso mediante Pools y Lanes. Pool

Representan un proceso desde el punto de vista de un participante en el mismo (generalmente una empresa) y es un contenedor de las actividades que esa empresa realiza. Los Pool representan todo el proceso.

Lane

Los Lanes en el proceso de negocio representan los roles de las personas u organizaciones que realizan las actividades. Es una partición dentro de un Pool (gráficamente puede ser vertical u horizontal) y los usamos para organizar y categorizar las actividades en roles o departamentos. Gráficamente un mode227


lo de proceso de negocio muestra quien realiza las actividades. Cada Rol que realiza estas actividades tiene un Lane.

Algunas veces las actividades dentro de un proceso deben interactuar con otros procesos, las interacciones entre estos procesos las modelamos usando Pools. Un Pool es un contenedor de procesos que contiene actividades, eventos y gateways. Los Pools son como los Lanes, excepto que los Pool pueden contener Lanes.

Veamos el uso de un Pool que engloba todo un proceso con los Lanes dentro del mismo para indicar que hace cada uno dentro del proceso:

En este ejemplo una incidencia en un producto es recibida y registrada por el servicio de atención al cliente, si el problema es conocido, se comuni228


ca al cliente y finaliza el proceso. Si el problema no es conocido, se envía al departamento técnico que identifica el problema y si este es conocido se documenta y si no lo es, se recurre a soporte técnico. Veamos ahora otro ejemplo para un proceso de solicitud de vacaciones que el lector podrá interpretar fácilmente por sí mismo:

Artifacts (Artefactos): Son usados para proporcionar información adicional acerca del proceso, aunque no afectan al flujo de estos. Existen tres tipos estándar de Artifacts, pero podemos añadir tantos como sean necesarios para aportar esa información adicional aunque no recomendamos esta práctica. Data Objects (Objetos de Datos)

Proveen de información acerca de documentos y datos.

Groups (Grupos)

Proporcionan una relación visual de un conjunto de actividades.

229


Text Proporciona información adicional Anotation del modelo. Es un texto añadido para (Anotación ayudar a comprender alguna parte o textual) actividad del proceso.

Hasta aquí hemos descrito los elementos básicos de BPMN. A continuación ampliaremos distintos elementos y técnicas de modelado. Event Type Message (Mensaje Tipo Evento): Son eventos de inicio como los vistos anteriormente pero asociados al intercambio de mensajes. Su principal uso es para establecer las comunicaciones con los participantes del proceso que están fuera del mismo (en diferentes Pools) para lo que disponemos de los eventos de tipo mensaje y distinguimos entre mensajes recibidos y enviados. Los eventos de mensaje indican una comunicación sin especificar si esta es por vía telefónica, mail o verbal. Start Message (Mensaje de Inicio) End Messsage (Mensaje de Fin)

Recibe el mensaje y se inicia el proceso.

Se envía el mensaje y se acaba el proceso.

Debemos tener en cuenta un punto muy importante: que la comunicación entre Pools es siempre y únicamente a través de mensajes. Veamos un ejemplo de esta comunicación:

230


En este ejemplo vemos la comunicación entre Pools a través de mensajes (Message Flow). Cada reclamación de incidencia de un cliente inicia el proceso en la empresa. El proceso termina cuando la incidencia es resuelta y enviada al cliente. El subproceso “Gestionar incidencia” desplegado, bien podría ser el ejemplo usado anteriormente. Una buena práctica de modelado es que cuando comencemos un proceso con un mensaje de un cliente finalicemos también con un mensaje a este. Veamos ahora otro ejemplo en el que usaremos algunos Artifacts para documentar el proceso y comunicación a través de mensajes entre distintos Pools:

231


En este ejemplo vemos como el proceso en el Dept. de RR.HH se inicia con la llegada de un mensaje que incluye un CV (Curriculum Vitae) el cual es visto por el personal del departamento que decide si es aceptado o no. En las dos salidas del Gateway, tanto si el CV es aceptado como si no, se incluye un evento intermedio de mensaje al candidato, tras lo cual finaliza el proceso. En este ejemplo además hemos añadido dos Artefactos de texto para documentar el envío de los mensajes de aceptación o denegación. Otro ejemplo parecido puede ser el siguiente entre un profesor y sus alumnos para recomendar libros de lectura, que el alumno haga un resumen de los mismos, el profesor comente el resumen, el alumno lo mejore y finalmente el profesor asigne una nota. A través de todo el proceso tendremos dos Artifacts de Objetos de Datos para indicar el libro y el resumen:

Event Type Timer (Temporizador Tipo Evento): Timer (Temporizador)

Para los eventos de tipo Timer, sólo tenemos evento de inicio e intermedio pero no de finalización, estos últimos no están permitidos en BPMN, por lo que sólo podremos “recibir” un evento de tipo de Timer. Un Evento de inicio Timer inicia a una hora y fecha especificada un proceso de forma automática

232


Veamos un ejemplo de evento tipo Timer:

En este caso el proceso se inicia el día 2 de cada mes, por lo que se inicia el subproceso de generar facturas y finaliza el proceso con el envío de la factura al cliente.

Tipos de Modelos BPMN: Private (Privado): Procesos internos dentro de una organización. Cada proceso está dentro de un único Pool.

Abstract (Abstracto): Procesos públicos que incluyen interacciones entre un proceso del tipo “Private” y otros procesos o participantes y en el que sólo vemos las actividades del proceso privado y las comunicaciones con otro proceso, pero sin saber que realiza este otro proceso internamente.

233


Collaboration (Colaboración): Procesos globales. Todos los procesos son visibles y todo el mundo sabe lo que hacen los demás.

BPMN ANALÍTICO: Hasta aquí hemos visto los elementos principales de BPMN. Ahora veremos BPMN en mayor detalle, pasando al BPMN analítico en el que describiremos en detalle los procesos, todas las actividades, decisiones y excepciones que puedan ocurrir en el proceso. Start Events (Eventos de Inicio): Evento de inicio sin especificar.

234


Message (Mensaje): Un mensaje llega de un participante. Timer (Temporizador): Un ciclo de una hora o fecha específica, por ejemplo: todos los días a las 16:00 h, a la que se activará el proceso. Conditional (Condicional): Lanzado cuando una determinada condición es verdadera. Parallel (Paralelo): Evento de inicio paralelo. Este evento crea e inicia una instancia de un proceso por todos los eventos de inicio definidos. Signal (Señal): Una señal es difundida por otro proceso para que todos los procesos puedan usarla para arrancar. No es un mensaje. Multiple (Múltiple): Existen múltiples formas de lanzar el proceso y sólo una de ellas será necesaria para lanzarlo.

235


End Events (Eventos de Fin): Evento de fin sin especificar.

Message (Mensaje): Un mensaje se envía a un participante. Error (Error): Un error debe ser generado y este debe ser recepcionado por alguien. Signal (Señal): Se lanza una comunicación. Terminate (Terminador): Todas las actividades del proceso deben finalizar inmediatamente. Multiple (Múltiple): Múltiples sucesos de finalización del proceso. Todos ellos deben ocurrir. Por ejemplo: avisar al cliente, al proveedor y enviar factura a cliente.

236


Eventos Intermedios: Los eventos intermedios se encuentran entre los eventos de inicio y final del proceso. Los eventos intermedios pueden “esperar” por algo (por ejemplo a recibir un mensaje) o “lanzar” algo (enviar un mensaje). “Espera”

“Lanza” Message (Mensaje): Usado para esperar por un mensaje que debe llegar o para enviar un mensaje a un participante. Timer (Temporizador): Usado para retrasar el flujo del proceso hasta una hora y fecha específicas. Como vemos no tiene lanzador, pues el tiempo pasa independientemente de lo que haga. Error (Error): Se usa siempre en el borde de una actividad para recoger un error generado dentro de otra actividad o subproceso. Conditional (Condicional): Lanzado cuando una determinada condición es cierta. Signal (Señal): Usado para esperar por una señal cuando lo ponemos en el borde de una actividad o para lanzar una señal.

237


Multiple (Múltiple): Usado para esperar cuando lo ponemos en el borde de una actividad (y sólo una condición es suficiente para lanzarlo) o para lanzar múltiples consecuencias. Link (Enlace): Usado como un “go to” (ir a) para conectar dos secciones de un proceso o entre páginas de un proceso cuando no todo el diseño del proceso entra en una sola página. Veamos un ejemplo de evento intermedio del tipo Timer:

En este ejemplo vemos un proceso para recordarnos que debemos enviar un informe de ventas en el cual si la actividad “elaborar informe de ventas” se realiza en menos de 7 días, el evento intermedio Timer no es activado y no se ejecuta la actividad “enviar recordatorio”, pero si la tarea no se realiza en 7 días, entonces se activa la ruta de excepción y el recordatorio es enviado.

238


Ejemplo de evento intermedio de Error:

En este ejemplo, si la actividad “Recibir harina” se completa antes de 8 horas no se activa la ruta de excepción, sin embargo si la harina no se recibe antes de las 8 horas necesarias para realizar la actividad “Fabricar pan”, entonces se activa la ruta de excepción y se prosigue con la actividad “Notificar a proveedor”. Ejemplo de evento de Error o Excepción:

En este caso vemos una excepción de negocio como es el que la tarjeta sea rechazada por la entidad bancaria y el pago no pueda realizarse normalmente y en consecuencia se activa la ruta de excepción generando el error.

239


Ejemplo evento Múltiple:

En este ejemplo, el proceso se inicia con un evento múltiple que puede ser iniciado todos los meses o a petición de la Dirección y como se trata de un evento múltiple, con el solo cumplimiento de una de las condiciones, se activará el proceso. Este evento múltiple lo documentamos con un Artefacto de Texto, al igual que el evento múltiple de fin, para expresar que acciones se llevarán a cabo. Ejemplo evento Signal:

En este ejemplo, cuando entra un nuevo coche para ser reparado, el sistema lanza una señal. Esta señal es recibida para proceder al envío de piezas para la reparación del coche. 240


Decision Gateways (Compuertas de Decisión): Exclusive (Exclusivo)

Basado en eventos, sólo uno de las rutas asociada con el evento será activada. El comportamiento para las entradas en este Gateway es el mismo que en el Gateway exclusivo normal, pero en las salidas, la decisión está basada en eventos que ocurren en ese punto del proceso, generalmente en función de mensajes que llegan a estas rutas de salida y determinan cual de las rutas se seguirá. Por ejemplo si la respuesta que llega de un cliente es Si o No.

Inclusive or Todas las alternativas o ninguna de Conditional las alternativas deben ser considera(Inclusivo o das, sin embargo se debería marcar Condicional) alguna como la opción por defecto, pues si ninguna de las condiciones es verdadera, el modelo se considerará No Válido.

Complex (Complejo)

Usada en situaciones complejas cuando varias alternativas deben ser combinadas.

241


Ejemplo de uso de eventos intermedios para un proceso típico de toma de decisión basada en Eventos:

En este ejemplo, una de las típicas situaciones para gestionar respuestas, hacemos uso de la decisión exclusiva basada en eventos para decidir qué hacer en función de los diferentes tipos de respuesta que podamos obtener. En el punto 1: si llega mensaje de aceptación se prepara el pedido y finalizamos el proceso. En el punto 2: si llega mensaje de denegación analizamos las causas de la no aceptación y finalizamos el proceso con el envío de un mensaje a alguien. En el punto 3: si pasan más de 7 días y no tenemos respuesta de aceptación o denegación decidimos que hacer y finalizamos también con un evento de finalización tipo mensaje. Veamos otro ejemplo en el que solicitamos ofertas a tres proveedores distintos y escogemos la del primero que responda, pero en este caso, supongamos que nos importa más el tiempo de respuesta que otras características de la oferta. En este ejemplo haremos uso de dos tipos de Gatways, el paralelo y el basado en eventos.

242


Flujo por defecto y condicional: Flujo por defecto

Se escogerá un camino si ninguno de los otros caminos es verdadero.

Flujo condicional

Es un flujo de secuencia con una condición que debe cumplirse para poder seguir ese camino. Este flujo se representa con un pequeño diamante al inicio. Si el flujo sale de un Gateway, no se indica el diamante, pues ya establecemos las condiciones en el Gateway.

243


Ejemplo Decisión Condicional usando un Inclusive gateway:

En este ejemplo tenemos varias opciones que el cliente puede escoger para configurar su móvil y en el que pueden ser activados varios caminos según los deseos del cliente. Así mismo indicamos la opción “con cámara” como camino por defecto, mediante la raya en su flujo de secuencia, lo que significa que si ninguna otra opción es escogida, se escoge por defecto esta y nos aseguramos de que el modelo sea válido. El Gateway inclusive o condicional es como vemos en el ejemplo anterior usado también para sincronizar distintas rutas.

El modelo para el flujo condicional es equivalente al que hemos usado en el Gateway Condicional, pero en el siguiente ejemplo, usamos el flujo condicional para expresar las condiciones de cada uno de los posibles caminos:

244


En el siguiente ejemplo, mostramos dos modelos equivalentes para expresar una decisión condicional.

Loops (Bucles) y Multiple Instance (Instancia Múltiple): Loop (Bucle)

Un subproceso Loop, repite las actividades varias veces. Los atributos que indiquemos en el proceso determinan las condiciones de las repeticiones. También podemos crear Loops conectando un flujo de secuencia a un objeto predecesor.

Multiple Instance (Instancia Múltiple)

Indica que una actividad es repetida varias veces y se indica con unas rayas paralelas.

245


Seguir el testigo (Token): Los procesos diseñados en BPMN haciendo uso de una herramienta de BPMS se ejecutarán en el motor de procesos. Este motor de procesos seguirá el flujo del proceso como un “testigo” que se irá pasando a través de los objetos de nuestro diagrama, desde el evento de inicio hasta el evento de fin. Cuando el proceso comienza, se activan todos los caminos y el testigo comienza a recorrer los caminos diseñados hasta alcanzar el evento de fin. Los procesos son iniciados manual o automáticamente, pero requieren de un lanzador (trigger, en inglés) de información, el cual es añadido o manipulado por el proceso hasta que este se completa. Algunas veces este lanzador serán datos o actividades automatizadas por sistemas software, otras acciones físicas realizadas por una persona o un mail que recibimos y otras veces serán acciones que ocurran durante la ejecución del proceso. Como ejercicio proponemos al lector seguir el “testigo” del siguiente proceso colaborativo para un servicio de urgencias sanitarias.

Distintos tipos de Flujo: Hasta aquí hemos visto los flujos normales de proceso, como el anterior en los que seguimos el “testigo” (Token) de forma secuencial desde el evento de inicio a través de las actividades y gateways hasta el evento de fin. Este es el denominado Flujo normal de proceso y que podemos representar de la forma:

246


Sin embargo podemos tener otros tipos de flujo que describiremos a continuación.

Exception Flow (Flujo de Excepción): Es el flujo que ocurre fuera del flujo normal del proceso y que suele ocurrir debido a un evento intermedio que aparece durante el proceso. Estos eventos intermedios, que usamos por ejemplo para esperar por un mensaje, los asociamos a una actividad o un subproceso, en el borde de la actividad, crean una ruta de excepción.

En este ejemplo creamos un evento intermedio que interrumpe el flujo normal y el funcionamiento del proceso. Si en 2 días no pedimos los suministros, entonces se activa la ruta de excepción y tendremos que ir a la actividad “Revisar Suministros”. Otro ejemplo de ruta de excepción puede ser con un error:

247


En Este caso, cuando la actividad automática genera un error, se invoca la ruta de excepción para generar manualmente la factura. Transaction Subprocess (Subproceso de Transacción): Las transacciones son un tipo especial de subprocesos que aseguran que todas las partes de un proceso de negocio serán completadas y si no es así (no todas las actividades se completan de forma exitosa), todas serán canceladas y revisadas hacia atrás en el flujo. Las transacciones se usan cuando diferentes partes del sistema (por ejemplo partners y proveedores) son necesarios para completar las actividades del proceso. Las transacciones están basas en el principio de “todo o nada” de la gestión de bases de datos. Deberemos finalizar todas las tareas con todo completado y si no es así deberemos deshacer todo lo realizado si alguna de las partes no ha completado su parte. Nada debe quedar en una inconsistencia. Los subprocesos de Transacción se representan como subprocesos pero con doble línea en los bordes.

Este proceso se realiza en combinación con el Compensation Subprocess y el Cancellation Event que veremos a continuación.

248


Compensation Subprocess (Subproceso de Compensación): Describe las acciones que se deben realizar cuando una actividad de una Transacción debe ser cancelada. Es como el “deshacer”, que genera un movimiento de compensación. Estas compensaciones podríamos hacerlas sin usar el mecanismo de compensación que describiremos, pero tendríamos que “llenar” nuestro modelo con una cantidad enrome de gateways tras cada una de las actividades. Algunas actividades producen efectos o salidas complejas. Si estas salidas pueden tener efectos no deseados como pueda ser una cancelación, entonces será necesario “deshacer” las actividades realizadas hasta ese punto, que es lo que denominamos “compensación”. Una actividad que pueda necesitar compensación necesitará de una actividad aparte que será usada para almacenar los efectos de la actividad inicial y que denominaremos la “actividad de compensación”. Esta actividad de compensación no tendrá ningún flujo de entrada ni de salida, ya que no seguirá el flujo del proceso, sino que será una actividad aparte (de ahí que se asocie con la actividad que puede requerir de compensación mediante un flujo de asociación y no de secuencia de flujo normal). En este caso asociamos un evento intermedio de compensación al borde de la actividad para indicar que una compensación puede ser necesaria para esa actividad. Para que una actividad pueda ser compensada, esta debe estar completamente finalizada, no se puede producir la compensación antes de que esta finalice.

249


Ejemplo Transacción:

En este ejemplo, supongamos que tenemos que reservar habitaciones de hotel para varias personas y posteriormente aprobar el presupuesto para estas habitaciones. Si se aprueba el presupuesto, finaliza el proceso, pero si este no se aprueba entonces deberemos cancelar las habitaciones que hemos solicitado y notificar al cliente las malas noticias. Ejemplo de compensación:

250


En esta transacción de un Sistema de Reservas de vuelo y hotel, tenemos tres posibles finalizaciones: 1. Que se finalice normalmente la transacción, en el ejemplo: que haya disponibilidad de vuelo y de hotel, entonces la transacción transcurre de forma normal y se procesa la reserva. 2. Si alguna de las actividades “Reservar Vuelo” (punto 2) o “Reservar Hotel” (punto 3) que pueden necesitar compensación, necesitan esta compensación por no poder reservarse cualquiera de ellas, entonces se cancelará la transacción en el punto 4. Este Evento intermedio de cancelación sólo puede ser usado en subprocesos de transacciones y no en actividades o subprocesos normales. Supongamos que se ha podido reservar el vuelo pero no el hotel, en este caso será necesario deshacer las dos actividades. El evento intermedio de compensación asociado a las actividades Reservar Vuelo y Reservar Hotel, se utiliza para activar el flujo de excepción. Por ejemplo si se ha podido reservar el vuelo pero no el hotel el evento de compensación se activará y se activarán las actividades de la compensación para cancelar el vuelo y el hotel. Al compensar las actividades del subproceso, el proceso principal no seguirá el flujo normal y se activará el evento intermedio de cancelación una vez finalizadas las actividades de compensación y se habilita un flujo de excepción para el proceso principal. 3. Error en el punto 5. Esto quiere decir que algo ha ido mal y que ni tan siquiera la cancelación es posible. Cuando ocurre este error, las actividades quedan interrumpidas sin compensación y el flujo continuará desde el evento intermedio de error. Como vemos, el final de un subproceso de transacción es muy diferente de un subproceso normal, pues el subproceso transaccional debe verificar que todos los participantes han completado sus actividades. En la realidad, los modelos de procesos que modelemos, serán no más complejos que los casos vistos en este capítulo, pero si mucho más extensos y en general, podemos decir que el 80% del trabajo en un proyecto de BPM será empleado en las tareas de realizar este modelado.

251


BPMN 2.0: En Junio de 2010 el Object Management Group (OMG) lanzó la nueva versión BPMN 2.0. En este capítulo hemos descrito los elementos de BPMN 1.1 y mostrado varios ejemplos sobre su utilización con los que el lector puede manejar los principales elementos de BPMN para modelar sus procesos. Aunque hemos introducido algunos de los principales elementos de la versión 2.0, esta presenta algunos cambios significativos que describiremos en este apartado. En la nueva versión, BPMN 2.0, recogiendo demandas de la comunidad de usuarios de BPMN, se recogen algunos nuevos elementos de actividades, eventos y subprocesos para soportar tanto modelos de negocio generales como verticales (seguros, finanzas, etc.). Los principales esfuerzos sin embargo se han hecho en estandarizar esta notación, que parece dirigirse en un futuro cercano a poder ejecutar directamente desde BPMN de los modelos diseñados. En este sentido, en esta nueva versión se encuentra el poder hacer los diagramas directamente ejecutables en un motor de procesos. Con la versión anterior de BPMN 1.1, trasladar un modelo de procesos de una plataforma a otra pasaba por exportar el XML generado (BPEL, XPDL, JPDL) a partir del modelo en BPMN, lo que implicaba tener que dibujarlo de nuevo. En la nueva versión disponemos de un nuevo meta-modelo de intercambio basado en diagramas de clases de UML para el intercambio de los modelos BPMN que resuelve este problema. Otra importante incorporación en la nueva versión es la de un nuevo tipo de tareas, las Business Rule Task, que proporcionan un mecanismo en el que se puede enviar o invocar y recibir datos de reglas de negocio establecidos en un motor de reglas de negocio. Este nuevo tipo de actividades representan unas tareas automatizadas que no realizan ninguna acción en el modelo del proceso y sólo devuelven el resultado de la regla de negocio que será usado dentro del flujo del proceso. En la versión BPMN 2.0 se añaden algunos nuevos elementos además de los ya comentados, como un nuevo tipo de actividades, las Service Task, como tareas que utilizan algún tipo de servicio como pueda ser un web service o aplicación, las Call Activities y algunos nuevos tipos de eventos. Para una descripción completa de esta nueva especificación, el lector puede recurrir a la página del OMG indicada al final del libro.

252

PARTE 3. IMPLEMENTACIÓN DE BPM. Cap. 7. Implementación de BPM. Cap. 8. BPMS (Business Process Management Systems)

Capítulo 7. Implementación de BPM

Capítulo 7. IMPLEMENTACIÓN DE BPM.

Como hemos visto, es a través de los procesos como las organizaciones realizan el trabajo especificado en la estrategia de la organización, agregando valor a sus productos y servicios. Los procesos, tienen en consecuencia un fuerte impacto en la eficiencia y los resultados de la empresa por lo que éstas deben analizar y mejorar continuamente sus procesos a través de un ciclo de vida que permita definir, ejecutar, monitorizar y optimizar sus procesos de negocio. Este ciclo de vida en un proyecto de BPM seguirá el siguiente camino clásico:

255


-

-

-

-

Definición: donde se definen los modelos, métricas y reglas de los procesos. Esta fase requerirá de la colaboración entre el personal de negocio y de TI, así como hablar e intercambiar opiniones con expertos sobre la materia y el proceso que estemos tratando, recogiendo la especificación de los procesos en una notación como BPMN, hasta alcanzar un modelo validado por todos. En esta fase suele ser la gente de negocio la que domina en la definición, especificando lo que se debe hacer. Ejecución: aunque la gente de negocio y de TI colaboran a lo largo de todo el proyecto, en esta fase, la gente de TI implementa la especificación realizada en la fase anterior, implementándola en un motor de procesos de un BPMS, el cual ejecutará y controlará el flujo de los procesos, nos proveerá de información sobre cómo funcionan, su rendimiento, tiempos de ejecución, donde están los cuellos de botella y los problemas, etc. Monitorización: donde también a través de un BPMS, controlamos los procesos y asignamos alertas a eventos de estos para controlar su funcionamiento para utilizar estos datos y medidas de rendimiento en la mejora de nuestros procesos de negocio. Optimización: donde vemos, qué podemos hacer para mejorar las cosas en una búsqueda continúa de la excelencia de nuestros procesos y búsqueda de ventajas competitivas, utilizando en esta búsqueda la información de los datos y medidas de los procesos recabados en la fase anterior para redefinirlos y volver de esta forma de nuevo a la primera fase de definición para continuar el ciclo.

Ciclo de aprendizaje y mejora continua. En este capítulo dedicado a la implementación de BPM, usaremos las fases principales del ciclo clásico que acabamos de presentar, pero ampliando el mismo para dar cabida a todas las fases y subfases que podemos realizar en una implementación completa de BPM, en un ciclo que denominamos de aprendizaje y mejora continua de procesos. Este ciclo es el representado en la siguiente gráfica.

256


A continuación describimos brevemente cada una de estas fases que ampliaremos y detallaremos en el resto de este capítulo. 1. Entorno de negocio. Partiendo del modelo de negocio, de la estrategia, del Business Motivation Model (BMM) y de la arquitectura empresarial, desarrollaremos las metas y objetivos de negocio que deben cumplir nuestros procesos. 2. Levantamiento de procesos. Conocer el As-Is o como son los procesos actuales de la organización, para lo cual realizaremos el levantamiento de procesos para realizar el inventario de los procesos existentes en la empresa, identificaremos los problemas y requisitos de estos, los modelaremos, identificaremos las medidas asociadas a estos procesos y documentaremos para proceder a ordenarlos por importancia y clasificarlos en función de su impacto y valor que aportan a la organización. 3. Datos y reglas de negocio. Sobre los procesos seleccionados introduciremos datos e información asociada a los mismos así como las reglas de negocio que rigen su comportamiento. 4. Mejora de procesos. Realizar el To-Be, o como deberían ser los procesos, rediseñando los procesos, para lo que emplearemos diversas técnicas de mejora de procesos. 5. Medidas, indicadores y análisis del proceso. Establecer medidas e indicadores de negocio que nos permitan evaluar el comportamiento y rendimiento de los procesos. 257


6. Simulación. Simular la operativa de los procesos, para evaluar su comportamiento y si las medidas e indicadores se ajustan a los valores deseados para el proceso. 7. Implementación. Desarrollar e Implementar el proceso rediseñado en un entorno de desarrollo, comprobar el correcto funcionamiento de las integraciones con sistemas transaccionales, realizar pruebas de carga y estrés y testear el funcionamiento del proceso. 8. Puesta en marcha del proceso, en un entorno de producción. 9. Control del proceso y mejora continua, a través de cuadros de mando que nos permitan seguir y monitorizar el comportamiento y eficiencia del proceso en busca de mejoras en su rendimiento. Al tratarse de un ciclo, continuamos el mismo volviendo al punto 2, pues los negocios cambian y en consecuencia, los procesos también, por lo que deberán ser de nuevo analizados pues pueden existir cambios tácticos o estratégicos que afecten al proceso. En la implementación de este ciclo que acabamos de describir para una implementación de BPM, será importante aprender a gestionarlo sin perder nunca la búsqueda de la mejora continua de nuestros procesos y evitar quedarnos en la “zona de confort”. Generalmente cuando hemos alcanzado un nivel razonable de desempeño en alguna materia o proyecto, tendemos a estancarnos, considerando que hacemos suficientemente bien las cosas y nos instalamos en esa zona de confort en la cual consideramos que tenemos las condiciones suficientes para satisfacer nuestras necesidades y dejamos de espolearnos para ir más allá en la búsqueda de mejoras, de experimentar nuevas formas de hacer las cosas o evaluar nuevas oportunidades. Consideramos aceptables los resultados alcanzados, nos fijamos sólo en lo que funciona, aprendemos sólo de los éxitos alcanzados y no de los fracasos que pasamos por alto y nuestra capacidades y habilidades corren el riesgo de quedarse obsoletas desplazándonos del mercado. Esta “actitud”, la podemos ver reflejada en el diagrama del ciclo de vida de implementación de BPM que acabamos de dibujar, el cual debe ser visto bajo una perspectiva de búsqueda continua de nuevas oportunidades para nuestra empresa. En este gráfico vemos como las líneas punteadas nos indican que desde cualquier punto del ciclo de vida, podemos volver al punto 2, para el modelado de los procesos, es decir, el ciclo de vida se debe retroalimentar constantemente, recogiendo datos, analizándolos e imple258


mentando nuevas teorías de lo que funciona o de lo que no, y esta importante práctica es fácilmente realizable en las soluciones BPMS en las que siempre podremos volver al modelado para modificar o corregir aspectos del funcionamiento del proceso así como seguir las distintas versiones que tengamos de los procesos para recuperar o modificar versiones anteriores. Es decir, los BPMS nos permitirán “chatarrear” con los procesos, sin miedo a incurrir en sobre-costos para poder implementar las soluciones experimentales que consideremos. A continuación pasamos a describir las distintas fases de este ciclo de BPM más detalladamente.

Entorno de Negocio. En esta primera parte del ciclo de vida de la implementación de la gestión de procesos y antes de capturar, definir y mejorar los procesos actuales con los que opera la empresa nos aseguraremos de disponer de la visión, de la estrategia, las metas y objetivos de negocio, de forma que todos los miembros del equipo y stakeholders del proyecto dispongan de un claro entendimiento de esta estrategia y objetivos así como del modelo de negocio que guiará y sustentará el proyecto para lo cual podremos hacer uso del Business Motivation Model (BMM) que vimos en el capítulo 5.

Los proyectos son creados para crear valor, y si el proyecto no dispone de esta propuesta de valor, no debería existir como proyecto. Como ya hemos comentado al hablar de la estrategia, generalmente pasamos por alto la definición y desarrollo de la estrategia y de su propuesta de valor, centrándonos en el análisis de variables técnicas y no de negocio y enfocándonos desde las primeras etapas en las soluciones tácticas, con la intención de resolver los problemas cuanto antes. El seguir este camino rápido en busca de la solución y obviar la estrategia, provocará el que no seamos capaces de resolver los problemas e ineficiencias en el medio y largo plazo, por lo que siempre estaremos actuando a corto plazo, retocando los procesos en una estrategia de “apagar fuegos” y desconociendo el origen último de los problemas e ineficiencias que observamos en nuestros procesos.

259


El enfoque de como realizamos la toma de requerimientos al trabajar con procesos, es completamente distinto al utilizado en la perspectiva del desarrollo software, en el que existe la tendencia a dirigirnos demasiado rápidamente a la solución técnica. En BPM modelaremos los procesos descomponiendo los mismos siempre a partir de la estrategia y del análisis de la cadena de valor de la organización, para desarrollar productos y servicios que cumplan con los objetivos organizacionales. Aunque las metodologías de ingeniería software han evolucionado hacia una orientación a servicios, las herramientas usadas como casos de uso y diagramas entidad-relación son sólo comprendidas por personal técnico y de TI de la organización, por lo que no nos servirán a la hora de comunicar el proyecto al resto de miembros de la organización y alcanzar el necesario acuerdo entre los miembros de la organización que finalmente deberán trabajar con los procesos y participar en su mejora continua. Muchas veces ocurre que los planes de empresa derivados del análisis del entorno quedan en el cajón del olvido pero no se siguen los mismos y resultan en documentos estáticos e inamovibles en años. Con la disciplina de BPM, tenemos la obligación de ponerlos en marcha y ejecutarlos, pues de su definición y desarrollo partiremos para con el lenguaje de cuadrados, flechas y rombos de los procesos, poder descubrir muchas cosas útiles sobre nuestra empresa, describir como operamos, cómo podemos mejorar y nos permitirán descubrir nuevos procesos y nuevas formas de hacer negocios, hasta el punto de poder cambiar la cultura y la tecnología de la organización. Al análisis del entorno de negocio y de los cambios u oportunidades que puedan suceder en éste, así como de los nuevos stakeholders que puedan surgir en el transcurso del proyecto, siempre volveremos en el ciclo de implementación de BPM, en busca de la orientación estratégica y redefinición de metas y objetivos para nuestros procesos. El retorno a esta fase será ineludible, bien sea por la naturaleza cambiante y dinamismo existente en los entornos de negocio o el debido los cambios que surjan en el mercado o aquellos provocados por el propio funcionamiento de los procesos, pues, en ambos casos, el modelo de procesos requerirá de cambios, adaptaciones, mejoras y de la implementación de nuevas necesidades demandadas por el cliente y el negocio. Esta necesidad de adaptación al cambio se verá facilitada enormemente por las capacidades de los sistemas BPMS y del lenguaje BPMN, a la hora de gestionar de forma flexible y en tiempo real las modificaciones y cambios sobre nuestros procesos.

260


Puesto que hemos detallado en los capítulos anteriores bastantes detalles sobre el entorno de negocio y el Motivation Model sobre los que se asentarán nuestros procesos de negocio, no nos detendremos más en esta fase y pasaremos a la fase de levantamiento de procesos.

Levantamiento de procesos. Esta fase es probablemente la más importante dentro del ciclo de vida de BPM, el levantamiento de procesos es la fase en la que desvelaremos los detalles y operativa de los procesos que actualmente ejecuta la empresa y sobre los que se fundamentarán las posteriores mejoras. Aunque es una imagen demasiado utilizada, la situación que nos encontraremos a la hora de llevar adelante esta fase en las organizaciones, puede ser comparada con un iceberg en el que sólo vemos lo que está por encima, el 10% de la realidad, ésta es la parte visible de los procesos que coincide con la parte que ven nuestros clientes como salidas de nuestros procesos y no la parte oculta, que representa el 90% de los procesos y que dificultará el poder conocer todos los detalles de los procesos que operan la empresa. Pero si bien es cierto que a nuestros clientes no les importa la parte oculta, y lo que quieren es que seamos capaces de darles el resultado de lo que hacemos por debajo del agua, a nosotros, como responsables de la mejora de los procesos de la empresa, nos importa y mucho lo que acontece en la parte sumergida y el desvelar la realidad de lo que ocurre por debajo será una de las tareas más importantes que asumiremos para limitar los riesgos y conseguir el éxito en nuestros proyectos de BPM.

261


Las empresas muchas veces no saben o no son capaces de describir cómo hacen las cosas de forma precisa y detallada. La realidad sobre cómo funcionan las cosas y las excepciones que puedan acontecer en su funcionamiento, están normalmente escondidas dentro de determinadas personas o programas informáticos dentro de la organización, pero ocultas para el analista de procesos y para gran parte de los miembros de la organización, por lo que es difícil descubrir estos procesos con todos los detalles de su operativa. En la gran mayoría de las organizaciones, los trabajadores conocen sólo las actividades que realizan y son de su responsabilidad, pero carecen o no disponen de una visión global de todos los procesos y operaciones de la compañía de principio a fin, estando estos fraccionados en las mentes individuales de distintas personas, donde cada una de ellas dispone de una visión local de una parte del proceso. Ni tan siquiera el omnisciente director general fundador de la empresa, ni el responsable de sistemas, disponen del nivel de detalle y del conocimiento de cómo se realizan todas las tareas de la empresa. El principal reto en esta fase de levantamiento de procesos, consistirá en hacer explícitos los procesos, el desvelar los procesos y sacarlos a la superficie, de forma que tengamos un entendimiento global de toda la estructura de procesos, para lo que tendremos que recabar todo el conocimiento existente en la organización y convertir éste de tácito en explícito para poder incorporarlo a la organización, retenerlo, monitorizarlo y gestionarlo.

Obtener el “As Is”. Durante el Levantamiento de Procesos (Process Discovery, en inglés), es donde especificaremos la arquitectura de procesos de la organización y las reglas y principios que rigen los procesos a través de los cuales la empresa implementa actualmente su modelo de negocio. Los modelos As-Is (Cómo es actualmente) y To-Be (Cómo debería ser), funcionan y podrán ser utilizados para cualquier tipo de modelado que realicemos, tanto para el modelado de procesos como del Motivation Model o del modelo organizacional. El modelado del As-Is nos permitirá conocer dónde estamos y el To-Be describirá donde nos gustaría estar, de forma que comparando ambos, podamos evaluar que actividades son diferentes, cuales no son necesarias o que nuevas actividades debemos añadir al modelo para mejorar su rendimiento y eficiencia. Cuando analizamos los procesos de nuestra organización y describimos el As-Is, describimos lo que está su262


cediendo en la misma para una vez que dispongamos del entendimiento y descripción de este modelo, generar alternativas al mismo, que llamaremos los Could-Be (Podrían Ser), que cuando escojamos los que satisfacen los objetivos y resultados del proceso, convertiremos en To-Be que pasarán entonces a convertirse en los nuevos As-Is.

La realidad hoy es que este ciclo del As-Is al To-Be es cada vez más corto, debido al constante cambio en el que las organizaciones se ven inmersas, las mejoras obtenidas sobre los procesos tienen cada vez una menor vida media y en consecuencia, nos vemos obligados a revisar los nuevos As-Is y repetir este ciclo iterativo de mejora continua. Capturamos el “As Is” de los procesos existentes para una vez obtenido, analizarlo para descubrir debilidades o cuellos de botella y basándonos en este diagnóstico, diseñamos el “To Be”, que corrige esas debilidades. En este punto realizamos un nuevo análisis para comparar los procesos del “To Be” con los del “As Is”, si este análisis indica que los beneficios justifican el coste, la organización implementa el “To Be”, que se convierte ahora en el nuevo “As Is”, con lo que iniciamos de nuevo el proceso. Aunque veremos las distintas partes de este ciclo, el Levantamiento de Procesos marcará el inicio del mismo y en el realizaremos el inventario de los procesos actuales de la organización, con el objeto de priorizar los mismos e identificar en cuáles de ellos debemos centrarnos en primer lugar para trabajar en su mejora. Para ello y al igual que hicimos en el capítulo 1, haremos la lista de procesos, crearemos los criterios de priorización y aplicaremos estos criterios a cada proceso identificado, con lo que obtendremos una lista de procesos priorizados y sabremos por dónde empezar a trabajar. Para la identificación de procesos revisaremos las actividades de nuestra empresa, hablando con los trabajadores o realizando cuestionarios. Aunque en el levantamiento de procesos cualquier metodología es válida para el objetivo de identificar los procesos, las sesiones de levantamiento de procesos para obtener el As-Is serán una técnica de especial utilidad que deberemos aplicar para obtener los mejores resultados de una forma eficiente y estructurada. Estas sesiones se organizan generalmente en torno a reuniones de trabajo con el equipo de proyecto en las que un analista va dibujando en papel, o mejor aún, modelando sobre una herramienta de modelado en BPMN, los procesos que entre todo el equipo se van descri263


biendo y detallando, de forma que sobre este mismo modelo, los miembros del equipo puedan realizar modificaciones y depuraciones sobre la información recolectada por todos ellos. En el modelado del As-Is, podremos ir introduciendo además del flujo de procesos, datos e información relativos al proceso, como tiempos para cada actividad, coste asociado a cada una de ellas, recursos necesarios, etc. Estos datos nos servirán para ir tomando medidas de comportamiento del proceso actual, el As-Is, y evaluar la eficiencia del mismo. Como hemos comentado en el capítulo anterior, la gran ventaja de modelar sobre un lenguaje como BPMN es que en estas reuniones, así como en las que veremos en mejora de procesos, todo el equipo, sea este de negocio o de TI, puede entender lo que estamos modelando, colaborar conjuntamente en el levantamiento de procesos y reducir el distanciamiento entre los requerimientos de negocio y los de TI a la hora de modelar los procesos existentes en la empresa. Existen diferentes metodologías y aproximaciones a la hora de realizar el levantamiento de procesos: Centralizada vs. Descentralizada: -

-

Centralizada: El analista de procesos invita a los expertos a sesiones en grupo y actúa como un facilitador buscando el consenso entre los participantes. Descentralizada: El analista habla con los expertos por separado, donde este captura las partes del proceso que cada uno de estos conoce.

Top-Down vs. Bottom-Up: -

-

Top-Down: Realiza el análisis comenzando a un alto nivel (la cadena de valor) y descompone los procesos hacia abajo hasta llegar a las tareas. Bottom-Up: Comienza el análisis por abajo, recopilando información local y construye el modelo hacia arriba.

Forma Libre vs. Estructurada: -

264

Forma libre: Aplica técnicas como el “brainstorming”, donde se deja a los expertos describir libremente los procesos y los problemas para luego compilar la información de forma estructurada.


-

Estructurada: Los expertos responden a preguntas predefinidas en base a un cuestionario o entrevista.

De estas tres posibles metodologías u orientaciones, a la hora de realizar el levantamiento de procesos, la recomendación a seguir es la mostramos en el siguiente gráfico:

Donde para obtener el mayor aprovechamiento de la fase de Levantamiento de Procesos seguiremos tanto una perspectiva Top-Down (de arriba hacia abajo) como Bottom-Up (de abajo hacia arriba) y no sólo la perspectiva tradicional Top-Down, alejada del compromiso con la innovación en la que los de arriba sólo piensan y los de abajo ejecutan las ordenes que viene de arriba. Esta fase de levantamiento de procesos es como comentábamos tal vez la más importante y en la que más tiempo emplearemos en el proyecto y no sólo nos servirá para describir el As-Is de los procesos, sino que aprovecharemos la misma para ir conociendo detalles e información sobre la mejora de los procesos, medidas que podamos utilizar o estrategias a seguir para la mejora del rendimiento de los procesos, por lo que la actitud innovadora, el contar con todos las personas involucradas en los procesos y el barajar las distintas posibilidades y formas de hacer las cosas, deben también ser tenidas en cuenta en esta fase de levantamiento de procesos. En este sentido debemos mantener reuniones tanto con los miembros del equipo como con SMEs (Subject Matter Expert: Expertos en un determina265


do campo) y trabajadores del nivel más bajo, para obtener todos los detalles de los procesos. En estas reuniones de equipo o en las entrevistas individuales que mantengamos, deberemos estar atentos no sólo a describir el As-Is visto por cada uno de los miembros que entrevistemos, sino también identificar las quejas de estos sobre la operativa de los procesos y las posibles mejoras que estos puedan señalar, aprovechando estas sesiones de levantamiento de procesos para recabar información para la fase de mejora de procesos. Como comentábamos, este aspecto de involucrar a todas las personas, no es sólo funcional sino también psicológico, a la hora de gestionar el cambio e involucrar a todas las personas de la organización en el levantamiento y futura mejora de los procesos, pues son estas personas las que al final deberán usar el proceso, por lo que buscaremos su complicidad con el proyecto desde las fases iníciales del mismo. Para obtener el As-Is comenzaremos por los procesos de alto nivel y de forma parecida a una estructura de desglose del trabajo, que utilizamos para subdividir los paquetes de trabajo del proyecto, desglosaremos estos procesos de alto nivel en subprocesos más pequeños y manejables hasta llegar a las actividades, de forma que los procesos modelados puedan ser entendidos por todo el equipo y podamos observar las posibilidades de mejora a realizar sobre estos o las deficiencias con que cuentan los procesos en el As-Is. Tras este desglose y llegados al nivel más bajo de actividades, deberemos dar un nombre a cada una de éstas, describir su operativa, de forma que todos los miembros del equipo la entiendan, especificar las reglas de negocio aplicables a los procesos, si van a ser realizadas por una persona, automatizadas por un software o una combinación de ambas y quien será en última instancia el responsable de gestionar la actividad o subproceso en el día a día de su operativa. Así mismo, deberemos identificar las actividades clave, los responsables, los problemas que afectan al trabajo y las metas y objetivos afectados por los procesos así como los atributos de estos procesos según vimos en la gestión de procesos del primer capítulo. Esta especificación será importante pues sin ella no podremos medir y comparar con posterioridad las mejoras o avances logrados sobre los procesos. Todas estas tareas requerirán de un duro trabajo, en el cual deberemos enfrentaremos a la organización y perseguir los datos e información relevante asociada a los procesos, buscando debilidades o cuellos de botella en los mismos, entendiendo las interrelaciones e integraciones de cientos de datos y documentos existentes en la empresa, procurando crear procesos estandarizados para nuestra cadena de valor y la convergencia de múltiples procesos paralelos ejecutados por distintos departamentos en un único proceso estándar de toda la empresa. 266


Una vez tengamos todos los procesos clasificados, el siguiente paso será determinar que procesos serán críticos para la organización, en el sentido de la capacidad que tengan de proporcionar una ventaja competitiva a la misma y crear valor. Por esta razón, los procesos no deben ser sólo descritos y definidos, sino que necesitan también ser demostrados, por lo que pasaremos a definir los criterios para su priorización y estableceremos una forma para medir cada uno de estos criterios que pueden estar clasificados por: -

Impacto: en la organización y como afectan a la misma. Facilidad de implementación: o de poder realizar cambios y mejoras sobre el proceso. Estado actual: como está funcionando actualmente el proceso. Valor: de retorno para la empresa, que podemos obtener mejorando el proceso.

Estos u otros criterios pueden ser definidos para priorizar los procesos, cada organización usará aquellos criterios más adecuados según los intereses que esta tenga en el proyecto, pero el objetivo es hacer la clasificación de los procesos para identificar, del largo listado de procesos, los criterios que nos dirán que procesos aportarán más valor a la organización. A continuación nombramos algunos ejemplos de medidas sobre los criterios de priorización: -

-

-

Impacto: o Personas afectadas por el proceso: si afecta a muchos empleados tendrá más impacto que si afecta a pocos. o Nivel de las personas afectadas. Implementación: o El tiempo que tardaremos desde que concebimos el producto o servicio hasta que lo sacamos al mercado. El “Time to Market”. o Complejidad en el proceso. o Problemas con los que nos podemos encontrar. o Disponibilidad de recursos para la mejora del proceso. o Presupuesto que necesitaremos para implementar el proceso, etc. Estado actual: o Satisfacción de las personas con el proceso actual. o Cómo de bien funciona el proceso en la actualidad. 267


-

Valor: o Beneficio de la implementación del proceso o ROI

Sobre estos criterios de clasificación de procesos, determinaremos la escala que vamos a usar para medir cada criterio y desarrollaremos la plantilla en forma de tabla que usaremos para evaluar los distintos procesos, donde apuntaremos los valores para cada criterio y obtendremos el total de las medidas para los distintos procesos. Una vez tengamos esta lista de procesos priorizados, puede ser que tengamos que aplicar pesos relativos a los mismos, debido a influencias de la organización, en el sentido de dar más peso a unos procesos que a otros. Podemos usar medidas porcentuales o valoraciones numéricas para dar más peso a unos u otros criterios. Como resultado final de este proceso de priorización, tendremos la tabla de procesos claramente priorizados y sabremos por dónde empezar a trabajar, mostraremos a nuestros superiores y al resto de personal involucrado en el proyecto los criterios y valorizaciones que hemos realizado para seleccionar los procesos y dispondremos además de un buen documento de trabajo para empezar a hablar sobre los procesos con el resto del equipo del proyecto. Uno de los beneficios que obtendremos con la implementación de BPM, será el poder medir la mejora de los procesos, por lo que para medir con posterioridad las mejoras, deberemos medir primero los As-Is, para conocer de donde partimos y saber si mejoraremos o no con el rediseño de los procesos. Una vez finalizado el As-Is y antes de su aprobación y paso a la fase de rediseño, revisaremos el mismo para buscar su aprobación y repasaremos su alineación con los objetivos y metas de negocio, las restricciones que podamos incumplir, las reglas de negocio que hayamos podido pasar por alto, las medidas utilizadas y los supuestos que se puedan dar en el mismo y no hayamos considerado en esta fase. Como veremos en la fase de implementación, algunas veces y en organizaciones conservadoras y que no deseen asumir excesivo riesgo en los proyectos de BPM, será conveniente escoger proyectos de pequeño alcance primero o procesos concretos sobre los que podamos demostrar las capacidades de mejora con BPM, de forma que nos aseguremos su éxito por la 268


importancia que pueda tener esta primera implementación para la realización de futuros proyectos de BPM. Llegados a este punto y al igual que hicimos en Gestión de Procesos en el Capítulo 1, procederemos ahora a describir el proceso sobre el cual hemos decidido centrar nuestros esfuerzos. Esta descripción se convertirá en la línea base del proceso, servirá como guía para su desarrollo e implementación e incluirá entre otros información básica del proceso como: -

-

-

-

Nombre del proceso. Propietario del proceso: la persona responsable del desarrollo y mejora del proceso. Cliente y sus necesidades, quien recibirá el resultado del proceso y que necesidades y expectativas hemos identificado que debemos satisfacer con el resultado del proyecto. Descripción del proceso, de forma resumida, clara y sencilla, para que cualquier persona pueda entender el proceso. Personal interesado en el proceso (stakeholders), además de los clientes, qué otras personas u organizaciones pueden verse afectados por el desarrollo del proceso, por su implementación y por los resultados de este. Alcance del proceso y límites del mismo (Inicio y Final): que está incluido y que no en el trabajo necesario para desarrollar el proyecto. Medidas que vamos a emplear para medir el proceso.

Una de las tareas que realizaremos en esta fase será la asignación de personas o equipos a actividades o subprocesos, para la cual nos será útil la utilización de una matriz de asignación de responsabilidades, donde se muestren todas las actividades asociadas con una persona a fin de evitar confusiones. Un ejemplo de esta matriz es la matriz RACI, cuyas siglas en inglés significan: -

-

Responsible (R): la persona responsable de realizar el trabajo, tarea o función. Accountable (A): sólo puede ser una, que es la que rinde cuentas y aprueba el trabajo. Debe ser el CEO, el cual tiene toda la responsabilidad y delega autoridad para ejecutar determinadas funciones y actividades. Consulted (C): que debe ser consultada de la realización de los trabajos. 269


-

Informed (I): informada de los trabajos.

Un ejemplo de esta matriz puede ser la siguiente: Persona Actividad

Alberto

Carlos

Sandra

Jorge

Analizar

A

R

I

I

Implementar

C

A

C

R

El uso de esta matriz es importante y debemos realizarla al inicio de nuestros proyectos, pues si no lo hacemos, la echaremos en falta cuando implementemos el proyecto y comencemos el despliegue de portales e informes asociados a los procesos.

Sesiones de Levantamiento de Procesos. Las sesiones para el levantamiento de procesos y la metodología y liderazgo que como responsables del proyecto utilicemos en estas sesiones, serán una actividad fundamental para alcanzar los objetivos pretendidos en la fase de levantamiento de procesos. El director del proyecto deberá disponer de especiales habilidades y conocimiento de la metodología de estas sesiones para sacar el máximo provecho de las mismas y poder desvelar el funcionamiento y operativa de los procesos que ejecuta la empresa. La importancia de una correcta planificación y conducción de estas sesiones tomará más relevancia considerando que no sólo las utilizaremos para el levantamiento de procesos sino que aprovecharemos las mismas para ir adelantando trabajo en cuanto a la recopilación de la información para la mejora de procesos, su posterior implementación y la implicación de los trabajadores y personal involucrado en el proyecto de mejora de procesos, por lo que el resultado de estas sesiones lo utilizaremos durante todo el proyecto y no sólo durante la fase de levantamiento de procesos. Las sesiones o workshops de levantamiento de procesos, son reuniones en las que trabajaremos con grupos de personas: SMEs, stakeholders, tra270


bajadores y partners relacionados con los procesos sobre los cuales estamos trabajando, para obtener información sobre los procesos actuales de la empresa y su mejora, buscando alcanzar acuerdos consensuados con todos los miembros de la organización. Estas sesiones requerirán de gestión y moderación de las mismas y para ello deberán ser dirigidas por una persona, normalmente el jefe del proyecto, que gestionará y liderará a los participantes y escuchará las opiniones de todos los miembros para alcanzar los objetivos de estas sesiones y obtener el modelado de los procesos, tanto de los As-Is como de los posibles Could-Be y el To-Be final, por lo que será importante dirigir las reuniones hacia la consecución de estos resultados, hablando con todos los participantes y describiendo la información que recibimos en un modelo que iremos puliendo con los participantes para obtener finalmente su validación final. Estas sesiones o workshops, las podremos usar tanto para modelar, recoger información, evaluar alternativas tanto de procesos como estratégicas, alinear la tecnología con la estrategia, buscar soluciones para la mejora de procesos, tomar especificaciones, requerimientos y reglas de negocio como para comunicar y validar resultados, conseguir que todos comprendan la importancia del proyecto y el impacto que este supone para la organización, así como también para proporcionar formación a los participantes. Para aprovechar todas las ventajas que nos ofrecen los workshops y dada su importancia para el resto de tareas que nos quedarán por hacer en el proyecto de BPM, deberemos ser metodológicos en su realización, por lo que planificaremos y preparemos las mismas desarrollando técnicas, herramientas y nuestras propias habilidades personales para la gestión de estas sesiones. Antes del workshop realizaremos la planificación del mismo, definiremos los objetivos que queremos de la reunión, el alcance de la misma y que queremos conseguir con ella y prepararemos el material necesario que usaremos durante el workshop. En esta fase, especificaremos los perfiles, roles y personas que deberán asistir y prepararemos una agenda previa de la reunión, la cual habremos enviaremos previamente a los participantes. Algunos de los participantes en estas sesiones pueden ser los siguientes perfiles: -

Sponsor: ejecutivo que define el alcance del proyecto, los objetivos, explica los problemas con que nos podemos encontrar, identifica los procesos que no funcionan o pueden ser mejora271


-

-

dos, establece el calendario y proporciona los recursos para alcanzar los objetivos del proyecto. SME (Subject Matter Expert): directores o trabajadores que realizan determinadas tareas involucradas en los procesos y poseen conocimientos específicos sobre determinados aspectos de los procesos que tratamos. Analista: responsable de compilar, organizar, analizar y presentar la información reunida de los SMEs.

Como jefes de proyecto dirigiremos las sesiones en busca de consenso sobre las soluciones y gestionaremos los conflictos, recordando lo que vimos al hablar de innovación sobre la importancia de estos conflictos o problemas como potenciales generadores del cambio. Nuestra actitud como líderes en estas sesiones no será la de fagocitar las reuniones con nuestro conocimiento, sino que esta será de escucha activa, detectivesca, sin actuar como expertos en el proceso o alguna parte del mismo. Nuestro objetivo es recabar todos los datos y posibles soluciones a los procesos planteados, por lo que seremos más investigadores que expertos en la materia y la única materia en la que deberemos ser expertos será en la de dirigir estas reuniones y a sus participantes para alcanzar los objetivos planteados: gestionar la reunión, a los participantes, los tiempos, la recopilación de información y el modelado de los procesos y soluciones que surjan durante las reuniones. Es una buena práctica, ya comentada, el utilizar una herramienta de modelado de procesos o la propia de modelado de un BPMS, para recoger la información de los modelos y sus diferentes versiones de forma que podamos conservar las mismas para futuras revisiones. El modelado debería ser realizado por otra persona, un analista de procesos o alguien con conocimientos de modelado y BPMN, de forma que el jefe de proyecto pueda centrarse en dirigir la reunión mientras esta persona modela “por detrás”. El jefe de proyecto debe también actuar como un psicólogo en las reuniones y sesiones de trabajo durante el levantamiento de procesos, conociendo las diferentes personalidades de los participantes y moderando la participación de estos, tanto si son demasiado activos y pretenden convertirse en los expertos que conocen todas las partes del proceso y no necesitan de la ayuda de nadie para definir o mejorar los mismos (situación esta nada deseable), como si se mantienen en la sombra, apenas participan y dejan el peso de las especificaciones del proceso a los demás participantes. Liderar estas reuniones a lo largo del proyecto no es algo fácil, pero es una tarea crítica para el proyecto y en la que empelaremos el mayor número de horas durante el desarrollo del proyecto. Generalmente, un solo workshop 272


no será suficiente en un proyecto y estos serán iterativos, recogiendo información en los primeros, para en los siguientes pulir y depurar esta información recabada en forma de modelos elaborados y realizando los informes sobre las reuniones, para con posterioridad, realizar nuevos workshops para mejorar y validar los modelos planteados en los primeros. Por la importancia que tiene para el proyecto y por el tiempo que dedicaremos en estas reuniones, deberemos ser muy hábiles en la gestión de éstas y en especial en la gestión de las personalidades que participan en las mismas. Debemos recordar que lo más importante en un proyecto de BPM es la gestión del cambio organizacional y las personas implicadas (“People in the trenches”, las personas en las trincheras, en expresión de Michael Hammer), pues son estas personas las que van a determinar el éxito o el fracaso del proyecto. Al igual que con otros muchos proyectos (de TI por ejemplo), podemos tener los mejores procesos en nuestra organización, pero si las personas que los van a usar no están implicados con la importancia y necesidad de estos, si no entienden su lógica y la razón de su uso, no podremos esperar su responsabilidad a la hora de usarlos y comprometerse con su mejora para sacar la máxima eficiencia de los mismos y en consecuencia, no tendremos nada, el resultado de toda la estrategia de negocio y los esfuerzos en la mejora de los procesos de negocio, no habrán valido para nada. Para hacer levantamiento de procesos debemos buscar el consenso en que los procesos que escojamos para su diseño o mejora, cuentan con la aprobación de toda la organización y no sólo en su diseño, sino también en que estos los más importantes para implementar. Deberemos evitar la situación tantas veces repetida en los proyectos de TI donde la dirección estima la necesidad de un desarrollo o aplicativo, que una vez ya contratado, debe ser asumido por los trabajadores de la empresa, con los cuales no se contó ni para su elección ni para su especificación, por lo que será difícil el compromiso de estos con su utilización y mejora y que en muchos casos resultará en una actitud de sabotaje por parte de estos usuarios forzados a su utilización. De lo bien que lo hagamos y del consenso que alcancemos con las personas que formarán parte de los procesos y de lo en cuenta que las tengamos en el diseño y mejora de los mismos, nos estaremos asegurando el éxito futuro en la implementación del proyecto de BPM. En general, en la fase de levantamientos de procesos, los principales problemas con los que nos encontraremos estarán relacionados con el cómo llevemos a cabo estas sesiones de trabajo y en conseguir la participa273


ción activa de las personas implicadas en su posterior utilización. Entre estas dificultades, las más comunes suelen ser la Imposibilidad de hablar con todos los SMEs implicados o los problemas de agenda para poder sentarlos en sesiones conjuntas o el recelo de algunos participantes a la hora de compartir la información “secreta” que conocen sobre su tarea específica. Este secretismo se debe muchas veces por miedo al cambio, otras veces por no desvelar que lo que hacen es una tontería o que no tiene sentido para el buen funcionamiento de la organización y otras, porque saben que lo que hacen lo realizan de forma ineficiente (“pero es como siempre lo he hecho”) y temen por su reputación. Por todo la anterior, si queremos llevar adelante nuestro proyecto de mejora de procesos, u optamos por la vía del BPR (Reingeniería) y no perdemos el tiempo con esta fase de levantamiento de procesos, rompiendo con todo, diseñando todos los procesos desde el principio y empezando desde cero, o nos comprometemos con el proyecto y las personas, aplicando todos nuestros conocimientos y habilidades para sacar lo mejor de estas. Existe una realidad en los proyectos de BPM y es la relacionada con la automatización de procesos y en consecuencia de puestos de trabajo. Hoy en día, en un momento de grave crisis económica mundial y de recesión, las empresas y los gobiernos han comprendido la necesidad de dar un giro de 180 grados a los planteamientos y actuaciones de las anteriores épocas de bonanza económica y no oímos otra cosa más que necesidad de eficiencia, rentabilidad en las operaciones, optimización del gasto, competitividad, austeridad y ahorro. Sin embargo, las personas no parecen atender a este nuevo planteamiento, nos aferramos a lo que tenemos y no queremos perder privilegios y ventajas, ocultando nuestras ineficiencias, no velando por el bien común o el de la mejora de nuestras empresas, pretendiendo que nada cambie, por si nuestras condiciones laborales puedan verse afectadas. Tanto en el levantamiento de procesos como en todas las fases del ciclo de vida de nuestros proyectos en BPM y en general en cualquier proyecto dirigido a la mejora de la eficiencia operacional de una empresa, nos encontraremos con la “paradoja” de que nadie en su sano juicio propondrá ideas de mejora que puedan hacer peligrar su puesto de trabajo o el de algún compañero e incluso, si las mejoras han sido impuestas, encontrarnos con prácticas de sabotaje. Ante esta situación sólo podemos luchar con una actitud abierta al diálogo, al compromiso con nuestros trabajadores, haciéndoles ver el “big picture” y procurando que entiendan la realidad de la actual economía, en la cual, debido a las altas exigencias de eficiencia y racionalización, los puestos de trabajo son sensibles al cambio, lo que pueda ser 274


automatizado será automatizado, el cambio será una constante y oponerse al mismo por mantener el “status quo”, sólo acelerará este cambio, al sacar más rápidamente a la luz las posibles ineficiencias. Los trabajadores de la nueva economía deben comprender esta situación y así debemos transmitirla haciendo ver que en ella también existen nuevas oportunidades, pero que éstas pasan por la preparación, el compromiso por los buenos resultados globales y la actitud innovadora y participativa sin temores en la búsqueda de soluciones y mejoras en los procesos de la empresa y que cuanto antes abordemos esta actitud, menos sufriremos en el cambio. Podemos encontrar infinidad de libros y consejos sobre cómo extraer el máximo provecho de estas reuniones, sobre las dinámicas de las mismas y sobre la gestión de personas, no trataremos aquí en detalle estas teorías y técnicas, pero si me gustaría como mejor consejo, recomendar las palabras de Carl G. Jung: “Conozca todas las teorías. Domine todas las técnicas. Pero al tocar un alma humana, sea apenas otra alma humana”.

Preguntas a cliente para empezar: Son muchas las preguntas con las que abordaremos a los participantes en las sesiones de trabajo y que buscarán principalmente conocer detalles acerca de los clientes de la empresa, del As-Is y de cómo debería ser el futuro To-Be. Estas preguntas serán del tipo: -

-

-

-

¿Cómo es actualmente el proceso y qué se pretende conseguir con él? Para ayudarnos a comprender los procesos y su relevancia. ¿Cómo funciona el proceso? Para obtener información más detallada de su funcionamiento. ¿Qué personas, sistemas o unidades de negocio participan en el proceso? Para identificar stakeholders, roles o sistemas con los que interaccione el proceso. ¿Cómo debería ser el proceso? Donde ya nos adentramos en el To-Be, para comenzar a recabar datos sobre las posibilidades de mejora del proceso. ¿Cómo empieza y termina el proceso? Para conocer los límites del mismo y donde nos encontraremos con que la gente tiene ideas diferentes de donde termina el mismo en función de la visión local o más global que tengan del proceso.

275


-

¿Cuál es la información y datos que se manejan en el proceso y que reglas de negocio sigue? ¿Qué informes y burocracia siguen los procesos?, etc.

La perspectiva Bottom-Up y los sistemas emergentes. Hemos recomendado para el Levantamiento de procesos el comenzar con una perspectiva Top-Down y continuar con una Bottom-Up. Para la primera, seguiremos una visión más estratégica desde la dirección de la organización pero la segunda perspectiva de Bottom-Up, resultará fundamental para el éxito del proyecto e implicará escuchar y entender también a las partes de más abajo de la organización. No debemos caer en la creencia de pensar que las personas en niveles operacionales de la organización no tienen nada que aportar a la estrategia, objetivos de la empresa, mejora de procesos o actividades necesarias para desarrollar los procesos. La historia de la innovación está llena de ejemplos de lo contrario y no sólo debemos buscar la implicación de estos perfiles en el proyecto, pues como venimos diciendo, son los que finalmente deberán usar el proceso y en consecuencia formarán el talón de Aquiles para el éxito del mismo, sino también por la importante información que estos nos puedan proporcionar, al ser unos stakeholders de primer orden para el proyecto y a no ser que todas las personas en la organización conozcan y nos transmitan su opinión sobre los procesos y el proyecto, no podremos conocer las implicaciones del cambio que pretendemos realizar. La perspectiva Bottom-Up, nos ayudará no sólo a entender y ver la organización desde otro punto de vista, sino que además, podremos encontrar con mayor facilidad que en ninguna otra parte, la impredecibilidad, la serendipia o la “solución sorprendente y de alto impacto”, propia de los sistemas emergentes, en las que al igual que en las colonias de hormigas, las reglas y comportamientos de d las entidades más simples regirán el comportamiento del sistema en los niveles más altos basándose en la autoorganización formar algo más complejo. La propiedad de emergencia, característica de todo sistema, significa que de las interacciones entre las partes que componen un sistema, surgen nuevas características y propiedades que no pueden ser encontradas en las partes individuales del sistema. Esta situación es similar a la del comportamiento emergente de muchos sistemas, como le de las hormigas y en cómo 276


éstas, pensando localmente dentro de la colonia, producen un comportamiento global en el que la inteligencia deriva del conocimiento local. El estudio del comportamiento emergente, ha sido perfectamente descrito por Steven Johnson en su libro: “Sistemas emergentes: o qué tiene en común hormigas, neuronas, ciudades y software”. En el cual el autor enumera cinco principios que se deben seguir para construir un sistema que aprenda desde los niveles más bajos y que nos pueden servir de advertencia y orientación: 1. Más es mejor. A mayor cantidad de individuos, mayor número de interacciones y mejor apreciaremos el comportamiento colectivo. Si observamos dos hormigas no apreciaremos el comportamiento emergente pero observando a miles de ellas sí que podremos percibirlo. 2. La ignorancia es útil. Es mejor construir un sistema con elementos simples y altamente interconectados y dejar que aparezcan conductas paulatinamente. Aunque el lenguaje de feromonas de las hormigas nos parezca sencillo, es perfectamente válido y a veces complicando. 3. Fomentar los encuentros casuales. Los sistemas descentralizados dependen fuertemente de las interacciones casuales, sin órdenes específicas y predefinidas, como los encuentros arbitrarios entre hormigas. 4. Buscar patrones en los signos. Sin contar con un vocabulario y lenguaje sintáctico elaborado, las hormigas dependen de los patrones químicos que detectan. 5. Prestar atención a tus vecinos. “La información local conduce a la sabiduría global”. El mecanismo primario de la colonia de hormigas es la interacción entre vecinos que entrecruzan sus rastros de feromonas. El aspecto fundamental de estos sistemas emergentes está en que son capaces de generar conductas o procesos innovadores y disponen de un mayor poder de adaptación a los cambios que los sistemas jerárquicos o más rígidos. Estos sistemas, aparentemente complejos y desorganizados, pueden dar lugar a un comportamiento colectivo, coherente y consistente, propios de sistemas auto-organizados: las hormigas crean colonias, los habitantes de una ciudad crean barrios, un software aprende a recomendar viajes o libros, dos células reproductivas crean una célula que a su vez crea un organismo completo, etc. Y en este sentido, cabe preguntarse si las fuerzas ascendentes y no las descendentes son las que rigen el comportamiento 277


de las organizaciones y si resultan finalmente determinantes para el éxito de estas. Muchos de estos patrones emergentes pueden encontrarse también en conductas sociales, redes sociales y ecosistemas digitales y empresariales y podremos también tenerlos en consideración al tratar la organización orientada a procesos, des-jerarquizada y flexible, pues de estas organizaciones resultarán también propiedades emergentes, capaces de resolver sus problemas y de auto-organizarse a pesar del aparente desorden y asilamiento de sus partes componentes y que no requerirán de una inteligencia centralizada en forma de leyes o instrucciones, sino que podrán funcionar de forma ascendente (Bottom-Up) a partir de elementos relativamente simples.

Las Personas. Como venimos advirtiendo en distintos apartados de este libro, las personas serán la piedra angular sobre la que se sostenga nuestro proyecto, pudiendo además ser consideradas como una herramienta competitiva más en los proyectos de BPM, donde partiremos de la consideración de que si cuidamos a la gente, la gente cuidará de la organización, por lo que como jefes de proyecto, dedicaremos la mayor parte del tiempo a las tareas de comunicación entre las personas involucradas en el mismo. El negocio lo mueven los procesos y las tareas, pero quién lo ejecuta son las personas, partners y proveedores de la empresa y el éxito del proyecto no estará en tener los mejores modelos de procesos o la mejor automatización de estos, el éxito de un proyecto, estará en que las personas de nuestra organización usen la solución desarrollada y que nuestros clientes se beneficien de esa soluciones en los productos y servicios que reciban. Como decía Michael Hammer, “tener las ideas es fácil, pero hacer las tareas que tenemos que hacer, es la parte más difícil. El lugar donde estas reformas mueren es abajo, en las trincheras” y los que están en las trincheras, son las personas de la organización, que finalmente son las que tendrán que implementar el trabajo. Los recursos humanos, las personas, como prefiero llamarlas, son el centro y la clave de todo proyecto, no sólo de BPM sino de cualquier otro tipo de proyecto y no sé por qué razón, pero esto es algo sobre lo que nos percatarnos siempre demasiado tarde, tal vez sólo con la experiencia o mejor 278


dicho, con las malas experiencias de no haber dado a las personas la importancia que en todo proyecto deben tener, caemos en la cuenta de su importancia. Ya hemos hablado de la necesidad de implicar desde las primeras fases del proyecto a las personas, que con su implicación y compromiso las necesitaremos en todas las fases del proyecto, desde el levantamiento de procesos, su mejora, la implementación y por supuesto la puesta en marcha de los procesos, pues al final, cuando hayamos implementando los procesos, serán las personas las que día a día estarán con él y si hemos contado con ellas y nos hemos asegurado su implicación, ejecutarán correctamente los procesos implementados, buscarán su mejora continua y la catalización de nuevas ideas y proyectos. Para conseguirlo, las personas deben ser consultadas, escuchadas, formadas y preparadas, para que desde las primeras aproximaciones que la organización realice hacia el proyecto, estas comprendan el mismo, su importancia y los motivos por los que se lleva adelante. Una situación muy común en los proyectos de BPM es, por la naturaleza misma de este tipo de proyectos, la relacionada con que las personas se sientan vigiladas. BPM y la gestión por procesos significa gobernanza de las tareas, actividades y procesos que ejecuta la organización así como el control y seguimiento del rendimiento de los procesos y en consecuencia de la organización, por lo que se establecerán indicadores y medidas de este rendimiento que no siempre pueden ser bien percibidos por los trabajadores. La necesidad de esta medición debe ser transmitida a las personas como algo necesario, como algo no destinado para vigilar su actividad y resultados (que también), sino para poder conocer el rendimiento global de la organización y si esta está en el camino correcto y cumpliendo con sus objetivos estratégicos. Para ello deberemos establecer un diálogo honesto acerca de lo que está pasando en el mercado y con los competidores y dar razones convincentes para que la gente participe en las mejoras y esté abierta a los cambios. En BPM esta consideración de la importancia de las personas como factor clave del éxito o fracaso de un proyecto, toma mayor importancia al considerar a las personas antes, durante y después del proyecto como claves en todo el proceso. Antes, porque son las personas y no los sistemas y las organizaciones las que disponen del conocimiento sobre los procesos de la empresa. No tener en cuenta en el proyecto y en el modelado de procesos a los usuarios e interesados en el proceso, será una de los más graves 279


errores que podemos cometer en un proyecto de BPM. Durante, porque serán las personas las encargadas de llevar a cabo y ejecutar los procesos que hemos diseñado y después, pues son las personas las que deberán controlar, medir, evaluar y mejorar los procesos en marcha en la organización. Y después, porque como ya hemos comentado, al final serán las personas las que ejecutarán el trabajo establecido en los procesos. La capacitación y formación así como el coaching, resultarán también decisiva. La implementación de BPM implica nuevos roles y puestos, los cuales deben comprender e interiorizar la filosofía subyacente a BPM y conocer los distintos aspectos que componen un proyecto de este tipo, de forma que toda la empresa comprenda que se va a hacer y porqué. Así mismo, los perfiles de personal involucrado en un proyecto de BPM deberán conocer todas las partes del proceso en el cual están involucrados y no sólo las partes del mismo en el cual están implicados, requiriéndose en consecuencia de estos perfiles un mayor abanico de conocimientos, habilidades y polifacetismo, para comprender todas las partes constituyentes del proceso. Toda la organización debe conocer y estar formada en BPM, pues no es sólo tecnología o la adquisición de una herramienta software de BPM (BPMS) lo que conducirá al éxito del proyecto, sino que estos proyectos implican un conjunto de conocimientos, técnicas de modelización, de diseño, análisis, monitorización, gestión del cambio y metodologías, que deben ser entendidas e interiorizadas por todo el equipo, que deberán estar abierto al cambio y a compartir sus conocimientos y experiencia, a pensar y reflexionar mucho sobre el sentido de por qué se hacen las cosas, el porqué se hacen de una forma determinada y si es posible hacerlas de otras formas distintas. Como sabemos, los procesos atraviesan los departamentos y los bordes mismos de la organización, lo cual tiene consecuencias sobre los roles, los puestos de trabajo, las comunicaciones y las medidas del desempeño. Los niveles de participación y colaboración entre equipos y personas se tornan distintos a los de la empresa departamental, en la que cada uno tiene funciones claras y definidas. En BPM y en las organizaciones orientadas a procesos, exigiremos a las personas entender esta transversalidad de los procesos. Dentro de estas nuevas exigencias para estos nuevos trabajadores comprometidos con la gestión por procesos, el personal de TI, por la idiosincrasia de su puesto en la organización y la necesidad de estos de disponer de una compresión global de los procesos de la empresa, debe comprender que ya no es un ente aislado que recibe unos requisitos y genera código fuente, sino que debe implicarse en el diseño y mejora de los proce280


sos globales de negocio de la empresa, siendo participativo sobre todo a la hora de aportar soluciones también en el área de negocio y no limitarse al análisis, desarrollo y mantenimiento del software de la empresa únicamente en su vertiente técnica. Este personal de TI deberá romper con la tradicional división entre gente de negocio y gente de TI en las organizaciones, pues esta línea divisoria será cada vez más difusa a medida que las herramientas TI y las filosofías de management se aproximan más a la realidad de los nuevos entornos de negocio. De esta forma los CIO (Chief Information Officer) y los responsables de TI de las organizaciones, deben ser transformados en gestores de mejora de procesos, más alineados con los objetivos de la empresa y ser capaces de proporcionar y optimizar las herramientas de negocio que permitan la gestión, control y monitorización de esos procesos de negocio. En este libro abogamos en muchos puntos sobre la necesaria adaptación y acercamiento sin complejos de la gente de negocio a las TI así como de estas a las áreas de negocio, de forma que ambos crucen la frontera que los separa como vía para afrontar la realidad de los negocios y mercados actuales. No hay nada que más alejado de la realidad que la del programador en su torre de marfil al que la gente de negocio pasa unas especificaciones por debajo de la puerta. La popularización de la informática y su fácil disponibilidad, la han convertido en un “commodity”, en el que el valor ya no se encuentra en el propio software, en el mantenimiento de las infraestructuras informáticas o en los procesos de soporte a operaciones y gestión del día a día que se supone deben encontrarse resueltos y automatizados, sino que ese valor estará en cómo la informática sea capaz de servir a los procesos que dan soporte al crecimiento y búsqueda de ventajas competitivas en las organizaciones. Por último, no debemos olvidar otro elemento clave como es la implicación de la gente de negocio y de la dirección de la empresa. Los proyectos de BPM significarán en muchas ocasiones cambios importantes en la organización y en su estructura, que deben ser apoyados por la dirección de la empresa, por lo que no deberíamos iniciar un proyecto sin el apoyo de los CEO (Chief Executive Officer). Los CEO deberán atender al proyecto, proporcionar los recursos y dinero necesario para la ejecución de los proyectos y prestar apoyo e implicación al mismo. Deben ser conscientes del esfuerzo y energía necesarios para implementar un proyecto de BPM y de que estos proyectos deben ser mantenidos en el tiempo. Este apoyo de los niveles más altos de la organización al proyecto, resultará en el aumento de las probabilidades de éxito o fracaso del mismo, siendo muy difícil que un proyecto alcance sus objetivos sin el apoyo y entendimiento del proyecto por parte de estos niveles ejecutivos de la organización. 281


Liderazgo. Para extraer lo mejor del proyecto y de las personas, será necesario un fuerte liderazgo del proyecto por parte del responsable del mismo, un liderazgo moderno e innovador, basado en la influencia y no en la autoridad, capaz de escuchar a todas las partes e involucrarlas en la búsqueda conjunta de soluciones a los procesos y la mejora de los mismos. El liderazgo en los proyectos de BPM no será del CEO, del cual ya hemos indicado su importante papel y función en el proyecto, sino que corresponderá al jefe de proyecto liderar el mismo, definir, planear, guiar, asistir y asesorar el trabajo del resto de miembros del equipo y del personal, proveedores y partners de la empresa, pues será el responsable último de los resultados del proyecto. Entre otras funciones, un líder o director de proyecto debe dirigir y catalizar las políticas y estrategias organizacionales, los recursos, las personas y los propios procesos. Deberán crear un ambiente que facilite el trabajo en equipo, motivar, gestionar la comunicación y retroalimentación entre los miembros, convertir el conocimiento de la organización en valor, asegurarse de que todos sepan su papel y lo que tienen que hacer en cada momento, resolver los conflictos de manera constructiva con objeto de lograr un mejor desempeño del proyecto, e inspirar a las personas para alcanzar los objetivos del proyecto. Sé que todo lo que acabo de decir es de “superhéroe”, pero esto y mucho más es precisamente lo que es y debe ser un Jefe de Proyecto y hablaremos todavía más al final del capítulo sobre otras cuestionas relativas a la gestión del proyecto que este “superhéroe” deberá también gestionar.

Gestión del conocimiento: La gestión del conocimiento implica la identificación y retención de información relevante para el negocio y de su correcta gestión, dependerá el que seamos capaces de incorporar el mismo a nuestros procesos. Para Peter Drucker, el conocimiento debe ser constantemente mejorado, cuestionado e incrementado o de lo contrario desparecerá.

282


El conocimiento está en las personas y otra vez son las personas, en última instancia, de donde extraeremos la información sobre la operativa de los negocios, los procesos y las tareas. En el transcurso del proyecto, deberemos identificar a las personas con los conocimientos que precisemos y aplicar técnicas de motivación e incentivos si fuese necesario, para asegurarnos la colaboración y participación de estas personas relevantes en el proyecto. La información y el conocimiento necesario para nuestros procesos, generalmente se encuentra dispersa en la organización, en las cabezas de sus trabajadores y en distintos formatos a lo largo de la organización (mails, hojas de cálculo documentos, bases de datos, aplicativos, etc.). Durante las reuniones de trabajo y especialmente en las de levantamiento de procesos, una de nuestras tareas más importantes será la de recopilarla y darle la coherencia necesaria para ponerlo a disposición de las personas de la organización. Así mismo no deberemos olvidar el usar buenas prácticas de gestión de proyectos como recoger al finalizar cada proyecto de BPM, las lecciones aprendidas durante el mismo y que nos permitirán en sucesivos proyectos no repetir errores y aprovechar el conocimiento y experiencias de anteriores proyectos. En este proceso de modelado del To-Be, modelaremos los procesos como nos gustaría que fuesen. Este camino es lo que denominamos el “Happy Day”, el camino feliz o escenario perfecto en el que el flujo del proceso nos lleva a cumplir nuestros objetivos. Sin embargo, existirán excepciones a este camino “Happy Day” en el que las cosas no siempre acaben bien y que denominamos los “Rainy Day” o días lluviosos, en los que el flujo del proceso no cumple sus objetivos y este termina con un error o un camino de excepción. Como vimos en los ejemplos descritos en el capítulo anterior de BPMN, estos casos son contemplados por la propia notación, pudiendo ser descritos y modelados, sin embargo existen otros posibles “Rainy Day” que pueden encontrase fuera del modelo diseñado. Este es el caso, por ejemplo, de algunas corporaciones que habiendo sustituido a todo el equipo que anteriormente gestionaba una infraestructura para externalizar su gestión, todo falló en este paso y nada funcionó según lo esperado, creando grandes problemas a la organización, pues esta no tenía todos los “Rainy Days” documentados, el conocimiento sobre la gestión de la infraestructura también estaba en las personas y este no estaba representado en los modelos de la infraestructura a gestionar.

283


Datos del proceso y Reglas de negocio. Llegamos en este punto, en el que tenemos la definición del As-Is, con los procesos seleccionados y modelados, al momento en el que debemos asignar datos e información a los mismos para poder conocer el rendimiento del As-Is y poder compararlo con posterioridad con el proceso mejorado o To-Be y decidir sobre la conveniencia o no de realizar el cambio o mejora del proceso. Los datos del As-Is los habremos ya recopilado durante el levantamiento de procesos, aunque si estos no están completos o nos falta alguna información o dato necesario para la completa especificación del proceso, este será el momento de recabarla. Si disponemos de una herramienta BPMS (que es lo recomendable), pulsando sobre cada una de las actividades de nuestro proceso, podremos introducir estos datos de forma rápida y sencilla.

Datos del proceso. Asignaremos recursos a las actividades y subprocesos y realizaremos el cálculo de tiempo y costes del proceso As-Is para calcular las líneas base de Tiempo y Costes. Estas líneas base nos serán de gran utilidad a la hora de realizar mejoras sobre los procesos para reducir su duración y/o su coste. En este apartado revisaremos las principales técnicas y herramientas para el cálculo de costes y tiempos. Estas técnicas derivadas de metodologías de gestión de la calidad, six sigma y de la gestión de proyectos, nos permitirán poder realizar estos cálculos con la mayor exactitud, a fin de disponer de una descripción lo más fiel posible de la realidad. Estas técnicas debemos conocerlas y usarlas para posteriormente y sobre los BPMS que veremos en el capítulo siguiente, poder introducir los datos de tiempo y costes sobre el modelado del proceso y poner en marcha toda la potencia de BPM en la herramienta de simulación y de ejecución de procesos, para analizar bajo distintos escenarios los resultados de estos tiempos y costos y poder tomar decisiones para sus mejoras.

Roles: La asignación de roles al proceso asignará responsabilidades y conducirá a los usuarios en el cumplimiento de sus tareas de forma que todos sepan 284


lo que tiene que hacer, cuándo y cómo hacerlo. De esta forma, al estar el proceso gobernado por estados, transiciones, flujos, responsables y reglas de negocio, operará tal cual ha sido especificado su comportamiento y donde el proceso dirigirá el desempeño de los trabajadores asignados al proceso. La asignación de roles al proceso, puede realizarse en la fase de modelado junto con las tareas que cada uno de estos roles deben ejecutar y permitirán al trabajador disponer de la información y retroalimentación necesaria para el desempeño de sus tareas y la coordinación de las mismas con el resto de roles participantes en el proceso. Para ayudarnos en esta tarea de asignación de roles, podremos hacer uso de la información recogida en la matriz RACI de asignación de roles a los distintos perfiles y usuarios del proyecto. Debemos tener en cuenta que estos roles pueden ser realizados por personas o sistemas informáticos. Para las tareas ejecutadas por personas, los BPMS usarán formularios web para interactuar con estas personas, al estar prácticamente todas las soluciones BPMS desplegadas en portales web y para los ejecutados por sistemas, dispondremos de las herramientas de integración que veremos un poco más adelante en este capítulo al hablar de las integraciones. Estos distintos tipos de roles pueden colaborar produciéndose interacciones entre ellos del tipo persona-persona, personasistema y sistema-sistema, que a su vez pueden ser de la misma empresa o unidad de negocio o de otras distintas, produciéndose en estos casos modelos basados en coreografía y orquestación de las que hablaremos en el siguiente capítulo. Para la asignación de roles o recursos humanos para la ejecución de las tareas, muchos BPMS disponen de funcionalidades para la gestión de recursos y capacidad de asignación de criterios, por ejemplo asignaciones por carga de trabajo, secuenciales o por primero disponible.

Tiempos: Haciendo un recorrido por las actividades del proceso que hemos modelado, podemos hacer el cálculo de la línea base del tiempo que llevará el proceso y sobre la cual podremos hacer mejoras de tiempos en el proceso.

285


Las dificultades en el cálculo de tiempos suelen venir de las personas a las que consultamos sobre la duración de las actividades, pues las personas suelen cubrirse en sus estimaciones y quedarse tanto por encima como por debajo de las duraciones reales, por lo que con frecuencia, solemos preguntar sobre la duración de una determinada actividad a varias personas y realizar luego una media de las estimaciones recogidas. Además de estas estimaciones, disponemos también de distintas técnicas para el cálculo de tiempos como el basado en históricos de tiempos de las distintas actividades para estimar su duración o el Método de Montecarlo, implementado perfectamente por los BPMS en las herramientas de simulación, para ejecutar la actividad repetidas veces por parte del motor de procesos y estimar las medias de tiempos empleadas por las mismas. Una vez sepamos el tiempo de cada actividad por los distintos métodos que hayamos escogido, podremos sumar los mismos según el modelo de procesos que hayamos dibujado y calcular el tiempo total de ejecución de un ciclo del proceso de Inicio a Fin, sobre el cual, todavía deberemos añadir tiempos de espera y retrasos que hayamos introducido en el proceso.

Costes: El coste total del proyecto será la suma de costes de las personas que realizarán el trabajo, el coste de los recursos que emplearemos en el mismo y costes varios de soporte al proyecto. Generalmente emplearemos la metodología ABC (Activity-Based Costing), mediante la cual se asignan costes a las actividades que realiza la organización, para luego calcular los costes totales de ejecutar todas las actividades. El coste podremos asignarlo a los procesos como un atributo más, contabilizando el costo de las distintas actividades, los cuales serán monitorizados como indicadores del proceso al igual que el tiempo de ciclo de proceso. Una vez hayamos finalizado con el cálculo de tiempo y costes del proceso, dispondremos de una valiosa herramienta para sentarnos de nuevo con el equipo para confirmar la exactitud del flujo de actividades, los tiempos y costes asociados al proceso.

286


Documentación del proceso. En el modelado del proceso podremos incluir también la documentación asociada al mismo y llevar una completa gestión documental asociada al proceso, de forma que esta gestión documental pase de ser un archivo masivo sin utilidad a convertirse en una herramienta de análisis de la información y gestión del conocimiento. Estas soluciones de gestión documental, pueden estar dentro de los BPMS o enlazadas con aplicativos externos, pero en cualquiera de los casos, deben proporcionar gestión de archivos y documentos electrónicos y físicos, imágenes, sonidos, vídeo, e-mail, ficheros ofimáticos, informes, etc. así como capacidades de firma electrónica, seguimiento de circuitos de aprobación y verificación, confidencialidad y seguridad de los archivos y documentos.

Reglas de negocio. Otro aspecto a modelar será el de las reglas de negocio, las cuales regirán el comportamiento del negocio, indicando qué estará permitido y qué no lo estará, así como las consecuencias de la violación de estas reglas. En todo negocio u organización tenemos reglas de negocio que debemos tener en cuenta en nuestros modelos, tanto a la hora de diseñar la estrategia como al realizar los modelos organizacionales o los de procesos. En todos los casos, existen reglas de negocio asociadas a la prevención de riesgos laborales, la salud de los trabajadores, al trato con clientes, las legislaciones aplicables a cada negocio y un largo etcétera de reglas que debemos respetar. Las reglas de negocio se formarán como construcciones semánticas (ordenes o consejos) que regirán el comportamiento del negocio: “esto no se puede hacer”, “aquello debe ser tenido en cuenta”, etc. Estas reglas nos indicarán, qué es necesario hacer, que es imposible que hagamos o qué es posible hacer bajo ciertas condiciones y vendrán casi siempre derivadas de las Políticas de negocio establecidas en el Business Motivation Model, donde recordemos que las reglas de negocio gobiernan los Course of Action del Maturity Model y gobiernan y limitan la estrategia en la medida en que dan forma a como la estrategia puede ser lograda, por lo que trasladada esta estrategia a nuestros modelo de procesos, cuando establezcamos las reglas de negocio que debemos respetar en las actividades o gateways de nuestro diseño en BPMN, estas reglas marcarán el diseño de nuestros procesos y en consecuencia de nuestra estrategia. 287


De esta forma, regidas por la estrategia, las reglas de negocio pueden, y en muchos casos suele ser así, contener todo el conocimiento de la organización, necesario para implementar completamente los procesos de la misma y es por ello necesaria una completa definición de las mismas para disponer de un correcto modelado de los procesos de negocio. Modelar los procesos basándonos en las reglas de negocio, permite a la gente de negocio entender y expresar los requerimientos, asegurando la consistencia en las operaciones y cumplimiento de las legislaciones y nos permitirá expresar un proceso sin necesidad de definir todas sus configuraciones posibles, pues las reglas marcarán el camino. La consideración de las reglas de negocio tendrá un importante papel en la mejora de procesos que veremos en la siguiente fase de este capítulo, en la que deberemos asegurarnos de que las mejoras a implementar no contraponen aspectos legales y/o normativos, pues de no hacerlo, corremos el riesgo de que la mejora no pueda ser implementada o cause graves prejuicios a la organización. Para la composición de reglas de negocio existe un estándar SBVR (Semantics of Business Vocabulary and Business Rules), en el cual podremos ver la semántica de las distintas reglas de negocio que a diferencia de otros tipos de modelado de negocios, no tiene una representación gráfica. SBVR es un estándar traducible a software, es también un estándar del OMG desde el año 2008 e incluye versiones en distintos idiomas. Existen seis formas de reglas de negocio: -

-

288

Obligatorias: son las más comunes de las reglas de negocio y son usadas cuando queremos asegurar que algo sea verdad. Prohibitivas: realizadas para prevenir determinadas actuaciones. “Está prohibido hacer esto”. Restrictivas: permite algo excepcionalmente, pero establece una restricción bajo ciertas condiciones en cuyo caso no puede ser permitida. Necesarias: cuya estructura es de la forma: “es necesario que”, ocurra una situación “si” se establece una condición. Imposibles: con la estructura semántica: “es imposible que” ocurra algo que no debe suceder “si” una condición. Posiblemente restrictivas: que describen que puede ser verdadero pero sólo bajo determinadas condiciones: “es posible que” una situación ocurra “sólo si” restricción.


A la hora de escribir nuestras reglas de negocio deberemos escoger de entre estos tipos las más convenientes para cada situación.

Mejora de procesos. Ahora que disponemos del “As-Is” del proceso de nuestra organización con su modelado, roles, tiempos, costes y reglas de negocio, estamos en disposición de producir el “To-Be” del mismo, efectuando mejoras en la eficacia y eficiencia del proceso. Durante el levantamiento de procesos del “As-Is”, ya habremos sin duda recogido información e ideas sobre cómo mejorar posteriormente el proceso. Toda esta información, junto con la descripción del proceso y en especial la información sobre el alcance del proyecto, requisitos de stakeholders y del proceso, nos servirán de hoja de ruta sobre la cuál encaminar nuestros pensamientos a la hora de mejorar el proceso en cuestión. Un aspecto muy importante será el moverse rápidamente desde la fase de levantamiento de procesos hacia esta fase de mejora, para que el proyecto no se duerma en el cajón del olvido y aprovechar los esfuerzos realizados en la fase anterior y la inercia ejercida sobre el proyecto, la organización y las personas, para continuar el mismo rápidamente hacia la mejora de procesos. Es más fácil ir rápido ahora que pasado el tiempo, y aprovechar ahora la disposición del equipo de proyecto, las ideas y oportunidades recogidas en la fase de levantamiento de procesos para saltar rápidamente hacia el camino de la mejora de estos. Como decía el famoso físico Erwin Schrodinger, los sistemas dejados a su aire durante mucho tiempo acaban inmovilizándose y uniformando su temperatura y al final todo el sistema se disuelve en una masa material totalmente inerte. En las empresas, solemos pasar la mayor parte del tiempo en las actividades del día a día, dejando poco tiempo para analizar el funcionamiento de nuestros procesos, medirlos, mejorarlos, optimizarlos o buscar soluciones innovadoras sobre los mismos que redunden en beneficio de nuestros clientes y en la eficiencia de la organización. En BPM, cambiamos esta actitud por otra en la que los responsables de negocio deberán pasar más tiempo trabajando en la monitorización, mejora y optimización de los procesos de la organización, en la medida que consideran a los procesos como activos fundamentales de la empresa para alcanzar sus objetivos de negocio y en consecuencia son conscientes de la necesidad de su mejora y optimización continua. 289


Al igual que en la fase anterior, esta fase se realizará también en base a reuniones de trabajo, siguiendo el modelo que utilizamos durante el levantamiento de procesos, para que con la colaboración de todo el equipo de proyecto y la ayuda de un analista que reúna las opiniones de todo el equipo y modele y documente las aportaciones de los mismos, vayamos dirigiendo y modelando el To-Be. Una vez conocido y desvelado el As Is lo descomponemos y analizamos los procesos en detalle y diagnosticamos las debilidades, cambiando a un mejor modelo de procesos que corrija esas debilidades. Luego comparamos el To-Be con el As-Is para ver si mejoramos. Al igual que en la fase anterior deberemos cargar sobre el modelo los datos, información y medidas sobre los procesos mejorados que vayamos diseñando, con objeto de ir comparando los resultados con el As-Is y los Could-Be realizados y analizar las mejoras alcanzadas. En este punto podremos hacer uso de las herramientas de simulación como las proporcionadas por las plataformas BPMS que describiremos en las siguientes fases. Finalmente una vez alcanzado el To-Be, desarrollaremos un plan de acción para evaluar los costes de implementar el nuevo modelo, conseguir el entendimiento y la comprensión sobre las mejoras propuestas en el proceso por parte de todo el equipo, las ventajas que este nuevo modelo ofrece y la necesidad de su implementación para obtener la aprobación y apoyo de los patrocinadores del proyecto y, si los beneficios de su implementación superan a los costes, procederemos a implementar el nuevo modelo con lo cual ya tenemos un nuevo y mejorado As-Is. El levantamiento de procesos, como ya explicamos, es un proceso iterativo y no es un ejercicio que se haga una sola vez. Una vez que hemos empezado a implementar procesos, estaremos constantemente trabajando en su mejora y en consecuencia, también en el nuevo To-Be consensuado por la organización que pasará a ser el nuevo As-Is. El procedimiento a seguir en esta fase, una vez seleccionado el proceso sobre el que trabajaremos, atendiendo a los criterios vistos en la fase de levantamiento de procesos, será obtener el acuerdo de los miembros del equipo y de los sponsor sobre la elección del proceso a mejorar, para luego dar por iniciada la fase y los trabajos para la mejora de procesos o el diseño de un nuevo proceso. Esta fase puede ser vista y gestionada como un nuevo proyecto, para el cual deberemos elaborar un plan de proyecto aparte, que incluya cuando menos los objetivos y el alcance de la mejora que se pre290


tende llevar a cabo, así como los tiempos, los costes, los recursos necesarios para ejecutarla y un análisis del el impacto de estas mejoras sobre la organización. Como acompañamiento a este plan de proyecto de mejora de procesos, deberíamos disponer de un diagrama que muestre el modelado del nuevo proceso y si es posible, una simulación del comportamiento de este y de los posibles resultados que se obtendrán con su implementación. Así mismo, deberíamos tener ya establecidas las medidas e indicadores que utilizaremos para el control y monitoreo del proceso, pues estas nos ayudarán a determinar si las mejoras sobre el proceso satisfacen los requerimientos de la organización y de sus clientes en cuanto a eficacia y eficiencia. Un aspecto importante al entrar en esta fase, es el de no tener la tendencia a ir directamente a la herramienta de modelado o a un BPMS a diseñar los rectángulos y diamantes de los procesos sin haber dedicado el tiempo suficiente a las tareas de diseño de la estrategia y el desglose de la misma, según hemos visto en el Motivation Model. Este es el caso de los programadores software con poca experiencia en proyectos, que tras una conversación de requisitos globales con un cliente, se lanzan directamente a escribir líneas de código sin haber diseñado, contrastado, analizado y consensuado previamente la solución final con el cliente, con el consiguiente riesgo de pérdida de tiempo y calidad en el proyecto. Muchas veces las mejoras y soluciones sobre nuestros procesos, al igual que le ocurre al intrépido programador de antes, nos parecen obvias y creemos saber perfectamente qué nuevos procesos o mejoras sobre los existentes son necesarias realizar. Estas mejoras surgirán sin mayor esfuerzo por el propio personal de la empresa cuando identifican un problema crítico y conocido, una oportunidad potencial de cambio o una nueva manera de hacer las cosas, por lo que ya en la fase de Levantamiento de Procesos, tendremos identificado o una aproximación muy cercana al To-Be deseado. En estos casos, las fases de levantamiento y mejora de procesos pueden ser realizadas al mismo tiempo, sin embargo este no será el caso normal, sino que estas fases se realizarán por separado. De todas formas y aunque estas mejoras tan directas resulten obvias, deberemos revisar las mismas, en especial en la alineación de estas mejoras con los objetivos organizacionales, asegurándonos de que estos son alcanzables y derivan de la estrategia de la organización. Deberemos pensar no sólo en los procesos sino también en términos de Arquitectura de Procesos, que es algo mucho más amplio e incluye a toda la organización, su modelo de negocio, la estrategia y los objetivos de negocio, así como todos los procesos y las relaciones entre ellos. Es de nuevo el pensamiento sistémico e integrador bajo el 291


que debemos considerar los distintos elementos, las relaciones entre los mismos y el entorno que conforman en lo que denominamos “sistema”. En esta visión, surge la variedad interpretativa, de forma que pueden existir diversas visiones de la organización dependiendo de quien la vea y como la vea y comprenderemos con mayor profundidad los problemas de la esta, sus múltiples causas y consecuencias, pues todos los departamentos de la empresa, tecnologías, clientes, proveedores y sistemas que la conforman, están interrelacionados y en consecuencia, existen muchos procesos que la sustentan, donde la suma de todos ellos y no los procesos aislados, es lo que conformará su cadena de valor. Esta fase de análisis del As-Is en la búsqueda de mejoras sobre el mismo, es la fase más creativa y en la que mayores dosis de innovación serán requeridas de los miembros del equipo y de toda la organización en general para intentar alcanzar los resultados más espectaculares posibles. El papel del director de proyecto en esta fase ya no será el de la fase anterior de guiar hacia la consecución del objetivo de obtener el As-Is que refleje lo más fielmente posible la realidad de los procesos de la organización, sino que ahora el director de proyecto deberá ser un motivador, con habilidades en dirección de equipos creativos e innovadores, que sea capaz de dirigir el mismo hacia las mejores transformaciones posibles sobre el proceso y no se quede en las mejoras obvias, alcanzadas rápidamente, sino que procure persistentemente nuevas y mejores soluciones. Para esta tarea, el poseer experiencia en la gestión de la innovación y metodologías de gestión de equipos innovadores, resultará de especial importancia. Además de las mejoras sobre los procesos, es decir sobre el modelado de la secuencia de actividades que deberán ser ejecutadas para que el proceso pueda ser implementado y por la naturaleza cambiante de las empresas, deberemos revisar y analizar también los procesos al más alto nivel de la organización, como el modelo de negocio sobre el cual consideraremos distintos tipos de análisis: -

292

Análisis de mejora: los negocios pueden ser siempre mejorados, los negocios cambian y las oportunidades y amenazas pueden ser aprovechadas o deben ser controladas. Con el análisis de mejora del negocio se busca mejorar el modelo de negocio y no el modelado del proceso, para ello haremos uso extensivo del Motivation Model, que puede llevarnos a tener que realizar cambios en la estrategia, definición de metas, objetivos o tácticas necesarias para conseguir los resultados esperados.


-

-

-

Análisis de Transformación: para apoyar una trasformación o reingeniería en la empresa debido a cambios en el modelo de negocio. Análisis de impacto: conocer las consecuencias de un cambio propuesto sobre el negocio, para lo cual usaremos técnicas como las de análisis de riesgos, identificación de los mismos y su análisis cualitativo y cuantitativo para medir y evaluar su impacto. Análisis de adquisición: para ayudar en la toma de decisiones sobre adquisiciones o fusiones de empresas, que suelen tener amplias repercusiones tanto en las estructuras organizacionales de las mismas, como en los modelos de negocio surgidos de estas fusiones y adquisiciones y las nuevas reglas y procesos integrados que serán necesarios para la operativa de la nueva organización.

Técnicas de mejora de procesos. A continuación describimos las seis técnicas de mejora de procesos en forma de rueda de mejora de procesos descritas por Susan Page, las cuales deben ser realizadas comenzando con la Burocracia y continuando con las restantes en el sentido de las agujas del reloj, con el fin de ir avanzando en un proceso lógico hasta la última de las técnicas que es la Automatización.

293


1. Eliminar la burocracia: La burocracia es la administración que realizan las unidades funcionales mediante el procesamiento de información y que ha alcanzado tan mala fama que en los diccionarios nos encontramos con una definición de la misma en la que se dice que es la influencia excesiva de los empleados públicos en los negocios del estado. La mayor parte de los procesos con los que nos encontremos y que no funcionan correctamente son debidos bien a que los procesos funcionan en silos departamentales, donde no existe un responsable de todo el proceso en su conjunto y los problemas debidos a la burocracia con la que se encuentran los trabajadores en su día a día y que consume gran parte de sus jornadas laborales, pero que es en muchos casos de obligado cumplimiento a pesar de las quejas de estos. Estas tareas burocráticas frecuentemente consisten en cargas de datos o en la elaboración de documentos, siguiendo una serie de pasos para reportar a niveles superiores de la organización. A la hora de analizar el impacto de la burocracia sobre nuestros procesos, debemos pensar como Jack Welch, quien denominaba a la burocracia como la enemiga de la productividad y en este sentido, pensar en ella como el enemigo a eliminar de nuestros procesos de negocio, por lo que el procedimiento que seguiremos con esta técnica será el identificar en nuestro modelo de procesos las tareas burocráticas, haciendo a los usuarios participes en la identificación de estas tareas y fijarnos en casos típicos de burocracia como los informes y necesidades de aprobación. En la eliminación de la burocracia debemos indagar sobre aprobaciones, pues algunas pueden ser reducidas o eliminadas en el caso de que se encuentren fuera de los límites del proceso sobre el que estamos trabajando, si se toman las decisiones en los lugares adecuados y si estas son necesarias para el proceso, el número de copias de documentos que circulan por el proceso, a cuantas personas necesitamos enviarlos, si esta información que enviamos es realmente necesaria y no es redundante y si las reglas y regulaciones que acatamos son necesarias para el proceso. La actitud es la de preguntarse constantemente por la necesidad de los procedimientos burocráticos, si se encuadran en los límites del proceso, su necesidad real, si consumen tiempo y dinero y valorar si aportan valor al cliente. En el proceso de eliminar tareas burocráticas, la mayor dificultad la encontraremos en la “costumbre” de la organización de realizar muchos de estos pasos, por lo que los consideraran necesarios y nos dificultará el convencer a la misma para su eliminación. 294


En esta eliminación de la burocracia deberemos prestar especial atención y evaluar las actividades denominadas SALT (Statutory; Audit; Legal; Tax) pues estás no deberían ser eliminadas y permanecer en la proceso. -

Statutory (Estatutaria): que la actividad sea una legislación o estatuto de algún gobierno. Audit (Auditora): para chequear el cumplimiento con determinadas reglas. Legal (Legal): que la actividad esté relacionada con el cumplimiento de una ley. Tax (Impuestos): que la actividad implique el pago de tasas o impuestos.

2. Generar Valor: Analizar la cadena de valor del negocio e identificar actividades que no aporten valor o satisfagan las necesidades de nuestros clientes, siendo implacables en la eliminación de las actividades que no aporten valor. Para decidir que tareas no aportan valor, debemos pensar en las necesidades o demandas de nuestros clientes en términos de calidad, costo, tiempo de entrega y servicio y revisar las actividades de la cadena de valor. El procedimiento para la identificación de estas actividades puede ser parecido al siguiente:

295


Muchas veces en BPM pensaremos a la hora de definir procesos en ¿qué pensaría el cliente sobre el proceso si conociese el funcionamiento interno del mismo? y nos haremos la pregunta: ¿si el cliente conociese estos detalles del proceso, pagaría por el producto o servicio? Al cliente sólo le interesa el producto o servicio resultado del proceso y no los pasos intermedios y procesos internos que la empresa realiza para proporcionarle ese producto o servicio. La gestión por procesos, el análisis de la cadena de valor que realicemos y de cómo cada actividad contribuye a la generación de valor a nuestros clientes para la eliminación de las actividades que no aportan valor, nos permitirá tener la seguridad de que toda la organización se dirige hacia la optimización de sus procesos y en consecuencia a la satisfacción de sus clientes. Para la generación de valor, deberemos facilitar que los procesos reciban o aporten datos de su operativa y de los sistemas con los que se integran, analizando las medidas e indicadores establecidos para el proceso, analizando las tareas repetitivas y que no aportan valor y centrándonos en las tareas productivas para reducir los tiempos de operación.

296


3. Eliminar duplicados: Generalmente estas duplicidades las encontraremos en el reporte de información, la carga de datos o en las tareas desempeñadas por máquinas, sistemas o personas que realizan la misma tarea. En otros casos los duplicados ocurren en las organizaciones funcionales y departamentales, donde varios de estos departamentos se ven involucrados en un proceso sin integración entre ambos departamentos y donde cada uno gestiona sus datos sin ser conscientes de que los datos son redundantes con otros departamentos o por el hecho de que cada departamento quiera conservar sus propios datos. En este caso, tenemos además de la posibilidad de reducir y simplificar el proceso, la oportunidad de trabajar hacia una integración de datos o de evolucionar administrativamente hacia una organización orientada a procesos.

4. Simplificar: Reducir o eliminar la complejidad de las actividades o del proceso en su conjunto de forma que este sea más eficiente, que eliminemos la complejidad con la que tendemos a diseñar nuestros procesos y negocios, convirtiéndolos en auténticos dinosaurios y que provocará que en muchos casos, para eliminar la complejidad pueda ser necesario rediseñar completamente el proceso o subdividir el mismo. Los modelos que diseñemos deben ser simples, pero manteniendo todo su significado y sin pérdidas de información. Desde luego que crear modelos simples es mucho más difícil que crearlos complejos, pero la simplicidad, la necesitaremos para que todo el mundo entienda lo que estamos modelando y describiendo, desde los modelos organizacionales, a los estratégicos y los modelos de procesos. Para esta simplicidad nos centraremos en lo importante de los modelos, omitiendo los elementos innecesarios y que no aporten valor. Entre las técnicas para realizar la simplificación se encuentran: la revelación selectiva y la descomposición jerárquica, la primera usada para mostrar los diagramas por partes, de forma que en cada uno de ellos mostremos parcelas de realidad en lugar de mostrar todo sobre un mismo diagrama que lo hará mucho más ininteligible y la segunda para simplificar la representación mediante el agrupamiento en niveles jerárquicos.

297


Esta simplificación la llevaremos no sólo al diseño de los procesos, sino también a las arquitecturas empresariales, la estrategia y el Motivation Model, de forma que todos puedan entender estos modelos y podamos usarlos como herramientas efectivas de comunicación en las distintas versiones de los modelos durante el desarrollo del proyecto. En BPM, como en la arquitectura, y recordando la frase del famoso arquitecto Ludging Mies van der Rohe, que revolucionó el diseño arquitectónico a nivel mundial: “menos es más” o la versión de Bertrand Russel sobre la Navaja de Ockham: “La explicación más simple suele ser la mejor”.

5. Reducir el Tiempo: Los tiempos de ejecución del proceso son percibidos tanto por la empresa ejecutante del proceso como por los clientes, siendo ambos bastante sensibles a largos tiempos y esperas. El objetivo en esta fase de la mejora de procesos es buscar y reducir la duración de aquellas actividades que consuman demasiado tiempo y responder de forma más rápida a nuestros clientes, buscando las causas de los retrasos e identificando alternativas que puedan implicar un aumento del personal y de los costes para poder hacer frente a tiempos de entrega y de proceso más cortos. En este punto, y antes de pasar a la automatización, podremos retomar la aplicación de las técnicas de Lean Six Sigma que nos ayudarán en estas tareas de reducción de tiempos y complementarán a otras actividades para la mejora de procesos. Como vimos al hablar de Lean Six Sigma, esta metodología, además de centrarse como Six Sigma en el control de procesos, aborda también el diseño y mejora de los procesos en base a una metodología para la eliminación de las tareas que no aportan valor y que denomina “desperdicios”, analizando las actividades y tareas en los niveles más bajos del proceso en busca de estos desperdicios y centrándose en actividades del tipo: -

-

298

actividades de Superproducción: que por falta de feedback de otras actividades, continúan produciendo salidas una vez han sido paradas. actividades En Espera: tiempos de inactividad en las actividades debidos a los tiempos de entrega de otras actividades. actividades de Transporte: debidos al innecesario movimiento de materiales o almacenamiento innecesario de los mismos.


-

actividades de Extra-procesado: actividades extra realizadas por el proceso. actividades de Inventariado: exceso de materia prima o bienes terminados. actividades de Movimiento: debidos a pasos ejecutados que no son necesarios en el proceso o actividad. actividades de Defectos: productos no conformes que provocan que se tenga que volver a realizar una actividad o todo el proceso.

6. Automatización: Analizaremos qué puede ser automatizado para hacer el proceso más eficaz y eficiente a través de la tecnología, atendiendo a si es la tecnología la que dirigirá el proceso o es el proceso quien dirigirá la tecnología. Bill Gates, el gran apologista de las TIC reconoció en cierta ocasión la importancia de los procesos como paso previo a la automatización y el empleo de las TI, según Gates: “La primera regla de cualquier tecnología es que la automatización aplicada a una operación eficiente magnifica su eficiencia. La segunda regla es que aplicada a una operación ineficiente la hará más ineficiente.” Este enunciado de Bill Gates, pasará a convertirse en una de las máximas de los proyectos de BPM y del fundamento de la necesidad de la correcta optimización y gestión por procesos como paso previo a su automatización y no como suele ocurrir en muchos proyectos de BPM, donde la primera tendencia es automatizar el As-Is, escogiendo además el proceso más importante de la empresa. Aunque esto nos pueda funcionar, donde obtendremos los mejores resultados será corrigiendo los cuellos de botella, duplicados de procesos e información y otras medidas de mejora de procesos, más que en la simple automatización. Si un proceso por sí mismo es erróneo, automatizarlo sólo conseguirá producir errores con mayor rapidez. Con BPM disponemos de una herramienta única para la automatización pero no debemos olvidar hacerlo sólo cuando estos se encuentren perfectamente optimizados y probados. En los últimos años hemos automatizado todo lo que hemos podido en las empresas: facturas, inventarios, ventas, sistemas de workflow y de gestión documental. La tendencia es a automatizar todo lo posible o automatizable en las organizaciones (soluciones simples a problemas complejos), pero esta automatización aplicada a procesos 299


no eficientes, hará fracasar la automatización y esta ya no será la solución a nuestros ineficientes procesos. Tal vez un buen recordatorio de esta necesidad de disponer de unos procesos perfectamente definidos, optimizados y derivados de la estrategia y metas empresariales como paso previo a su automatización, la tendremos recordando lo ocurrido en las masivas implementaciones de ERP´s y porque estas no han significado los aumentos de eficiencia, productividad y competitividad esperados. ¿Por qué las soluciones software fallan en muchos casos y no se obtienen los resultados esperados? La respuesta puede recaer en lo que decía Bill Gates. Automatizar algo no resuelve los problemas de ese algo, sólo ayuda a que ese algo ocurra más rápidamente y con más frecuencia, pues esta es la base de la automatización. Si automatizamos un proceso ineficiente, este se ejecutará automática e ineficientemente todas las veces que recurramos a él. En los procesos o sistemas se dice que “Garbage in, Garbage out” (Basura entra, basura sale), para indicar que si las entradas son “basura”, saldrá “basura” y los resultados que producirán el caos y la ineficiencia automatizada serán catastróficos para la organización. Entonces ¿por qué las organizaciones no resuelven sus procesos antes de mirar hacia la automatización? Principalmente porque estas organizaciones, las personas y los procesos que la sustentan, se han mantenidos inmutables durante décadas. El pensamiento es que da lo mismo que los procesos no sean muy eficientes, funcionan y ya está, ¿para qué vamos a cambiar algo que funciona y correr el riesgo de que deje de funcionar? La consecuencia de este pensamiento es que no se trabaja en la optimización y mejora de los procesos previamente a su automatización, se automatiza sin más, como una apuesta a ciegas. Muchas veces, esta automatización se realiza para apartar a personas de determinados procesos, es la solución sencilla, compro una solución software y me quedo tranquilo, ya no tengo que preocuparme del proceso ni de las personas, ¡he pagado por una solución! y me desvinculo del problema. Es el comportamiento del consumista y su visión idealizada de lo que necesita frente a lo que realmente contrata. La palabra automatización viene del griego “automatos” que significa “semejante a la forma en que trabaja tu mente”. La automatización es lo primero que nos viene a la cabeza cuando pensamos en mejorar y simplificar los procesos, sin embargo, la gran mayoría de mejoras pueden ser alcanzadas sin automatización, simplemente centrándonos en pensar en nuestra organización, en su arquitectura, modelo de negocio y analizando y

300


mejorando los procesos que desarrolla, buscando las causas de los problemas y no poniendo tiritas sobre los sistemas observados en el día a día. La automatización, no significa cambiar o sustituir todos los sistemas actuales que operan en la empresa, sino de dotar a los mismos de la capacidad de integrarse con el proceso de negocio, de forma que esta automatización hable y se entienda con el proceso. Al hablar de automatización, realizaremos una reflexión profunda sobre la necesidad y ventajas de la misma y como llevarla a cabo, analizando los costes asociados, si se hará en varias fases o de golpe, subcontratando o haciéndola internamente, etc. En este sentido, podemos seguir la recomendación seguida en la implantación de sistemas TI y ERP´s de no hacer la automatización de golpe y permitir la evolución de los sistemas y automatizaciones desde las más básicas y funcionales a las más complejas. De la lectura de este apartado, el lector puede quedarse en una situación de estancamiento respecto a la automatización, o pensar que existen dudas sobre la conveniencia de realizar o no la misma. No es esta nuestra intención y por supuesto, abogamos por la automatización de procesos como el factor más relevante a la hora de mejorar la competitividad de las empresas y en BPM en particular, dispondremos de las herramientas para esta automatización, pero la intención es transmitir al lector la premisa básica de la automatización de que esta debe ser realizada sólo sobre procesos eficientes. A partir de aquí y si los procesos son correctos, nos encaminaremos hacia la automatización que nos permitirá dar el gran salto en la composición de nuestros procesos y negocios gracias a unas capacidades tecnológicas cada vez más fiables y avanzadas. Otro aspecto al hablar de automatización es el del papel de las personas. Decía Warren G. Bennis, que las empresas del futuro tendrán dos empleados: un hombre y un perro. El hombre estará allí para alimentar al perro; el perro estará para que el hombre no toque los equipos y sistemas. Pero mientras este hipotético futuro no ocurre, deberemos prestar especial atención a las personas, pues con la automatización, tendemos a olvidarnos a no considerarlas y sean los procesos manuales o automáticos, serán las personas en última instancia las que van a hacer que los procesos funcionen o no, sin importar el grado de automatización de los mismos. Sino implicamos a las personas que disponen del conocimiento de los procesos en el análisis y diseño de los mismos, la automatización no será tampoco todo lo eficiente que debería ser.

301


Visión holística A la hora de optimizar el proceso no debemos perder la visión de mejora de “todo” el proceso y no sólo de determinadas partes del mismo. Recurrimos de nuevo a la visión holística de la organización, a la visión de la organización orientada a procesos y no a la organización departamental orientada a funciones específicas. La mejora de determinadas partes del proceso, actividades o aspectos locales del proceso propuestas por los expertos (SME´s) de determinados departamentos, no implicará siempre la mejora del proceso global, que es la meta que perseguimos. Esta situación es parecida al “Equilibrio de Nash”, que debe su nombre al matemático John Forbes Nash y sobre el que se rodó la película protagonizada por Rusell Crow “Una mente maravillosa”. En el equilibrio de Nash, se describe una situación en que todas las partes intentan maximizar sus beneficios sin cooperar ni tener en cuenta las consideraciones de las otras partes y donde vemos, al igual que en el dilema del prisionero, que esta estrategia en la que las ganancias de uno implican grandes pérdidas para otro, no siempre es la mejor solución (juegos de suma Nula, donde la victoria de un jugador implica la derrota de otro) y existen opciones para que todos puedan ganar si cooperan en la solución de problema. Para alcanzar el consenso, el equilibrio de Nash o que el resultado del proceso global sea lo más eficiente posible para todas las partes, todos los involucrados en las distintas partes del proceso deben colaborar, y el director de proyecto, a través de las reuniones de trabajo que realice, debe fomentar esta colaboración, y no los intereses particulares de unos departamentos específicos, o que unos más que otros, fagociten las reuniones o centren toda la atención del proceso global en su parcelas de especialización, pues esta es una tendencia muy común y fácilmente observable en muchas de las personas desde las primeras reuniones de trabajo que llevemos acabo en el proyecto.

Medidas, indicadores y análisis del proceso: Llegamos al punto en el que hemos mejorado nuestro proceso, habiendo obtenido un nuevo As-Is mejorado. El siguiente paso será aplicar las medidas que vamos a tomar para medir y controlar que el proceso se com302


porta según los objetivos planteados sobre el mismo y alcanzamos los resultados esperados. Para ello, tendremos que identificar y desarrollar esas medidas, medirlas en el proceso, ver que podemos hacer para mejorar esas medidas, si existen desviaciones en las mismas e implementar los cambios para volver a medir y decidir si los resultados son conforme a lo esperado o tenemos que rediseñar el proceso. El proceso de medición lo deberemos contemplar desde las fases más tempranas, tanto en el Levantamiento de Procesos, identificando las medidas e indicadores de los mismos, como en la fase de mejora de procesos, al ser las medidas e indicadores el único medio por el cual podemos diagnosticar y evaluar el funcionamiento del proceso y sus resultados en relación con el cumplimiento de los objetivos por los que fue diseñado. El medir el rendimiento de los negocios no es algo nuevo y ha sido siempre utilizado desde hace siglos para el control de las operaciones por parte de individuos, departamentos y empresas y revisar el cumplimiento de objetivos respecto a lo inicialmente planificado. El tipo de medidas utilizadas por las organizaciones ha evolucionado desde las más simples y las meramente financieras, a medidas más desarrolladas que nos permitan hacer frente a los retos de futuro de la empresa, seleccionando para ello los indicadores no sólo financieros sino también aquellos necesarios para alcanzar los objetivos estratégicos. Estas medidas e indicadores asociados a las operaciones, rendimiento y cumplimiento de la estrategia de la organización, son de vital importancia para la misma y su selección debe ser cuidadosamente realizada y comunicada a los miembros de la organización de forma que todos comprendan como sus comportamientos, actitudes y actividades afectan a los buenos resultados de estas medidas. Otro aspecto a tener en cuanto en la elaboración de medidas, es que muchas de estas, y tal vez las más importantes, se establecen sobre los resultados globales de la empresa y el cumplimiento de su estrategia, por lo que tenemos aquí una estrategia más para derribar los silos de información de la empresa funcional, estableciendo medidas e indicadores conjuntos del proceso y no recabando estas medidas asociadas a departamentos o personas concretas de la organización. Esto implica que los indicadores que definamos para nuestros procesos deben estar directamente relacionados con algún aspecto de la estrategia de la empresa siguiendo el camino: Indicador-> Metas -> Objetivos -> Estrategia. 303


La información sobre los resultados y rendimiento de las organizaciones es como sabemos fundamental para el control de la misma y de alguna manera, todas las organizaciones miden y monitorizan su actividad con más o menos indicadores de rendimiento y beneficio y con más o menos frecuencia. Todas las empresas son conscientes de que disponer de esta información lo más actualizada y fiel posible a la realidad, es importantísimo para la gestión de la misma y poder corregir a tiempo los problemas, errores o malos resultados que obtengamos de esas medidas. De la herencia de la contabilidad de costes, las empresas están acostumbradas a medir sólo sus resultados financieros, pero este tipo de medidas, a pesar de seguir siendo importantes para evaluar los resultados económicos de la empresa, no son suficientes cuando queremos evaluar el rendimiento de los procesos asociados a nuestra cadena de valor y de los cuales dependen los resultados financieros. Kaplan y Norton, los creadores del concepto de Balanced Scorecard, apuntaban que estos indicadores financieros podían incluso llevarnos a error, cuando enfocamos nuestros objetivos en aspectos como la mejora continua y la innovación. El establecimiento de métricas y la recogida sistemática de información sobre los procesos, debe centrarse en los focos de los problemas y por ello, las mediciones deben ser sobre aspectos relacionados con el negocio. Estas mediciones deberán ser analizadas y comparadas para establecer tendencias, informes estadísticos de los procesos, identificar cuellos de botella o comportamientos no deseados para optimizar su ejecución y aplicar cambios al modelo que favorezcan la mejora continua.

Indicadores de negocio. “No podemos gestionar lo que no medimos”. Sin las medidas no podemos controlar los procesos, sino controlamos los procesos, no podemos gestionarlos y si no podemos gestionarlos no podemos mejorarlos. Los Indicadores de Negocio (KPI: Key Performmance Indicators, en inglés) son medidas cuantificables que reflejan las metas de negocio e indican si cumplimos o no los objetivos planteados para la organización. Los indicadores están asociados a los procesos, que a su vez están asociados a los objetivos que queremos alcanzar, por lo que sobre los indicadores estableceremos qué queremos medir cualitativa y cuantitativamente (por lo que deben ser SMART: Specific, Measurable, Achievable, Relevant y Timely) y 304


poder de esta forma analizar estos indicadores, su grado de avance, sus variaciones y ajustar los procesos en consecuencia. Los KPIs son esenciales para entender los procesos, su comportamiento, los riesgos asociados a los mismos y las posibilidades de mejora que tenemos sobre ellos. Con los indicadores podemos monitorizar la actividad de los procesos, los niveles de servicio, diagnosticar el comportamiento de un proceso y gracias a ellos podemos comunicar los resultados de los procesos a toda la organización, motivarla e involucrarla en la mejora de los indicadores y en consecuencia de los procesos y del negocio. En una reciente encuesta se afirmaba que sólo el 14% de los empleados conocen la estrategia de la organización, reduciéndose esta a informes mensuales o anuales muchas veces con resultados financieros no entendibles para la gran mayoría de ellos. Esta situación de alejamiento de la realidad y objetivos que persigue la empresa, hace que los trabajadores se concentren todavía más en sus tareas especializadas, sin participar en el cumplimiento de los objetivos y procesos globales de la empresa. Compartiendo la información en tiempo real de las medidas e indicadores de los procesos, proporcionaremos material para el control de sus tareas, motivos para trabajar en la mejora de estos y tener una actitud abierta al cambio y a la innovación en base a la retroalimentación proporcionada por estos indicadores. La visión innovadora es necesaria al analizar las métricas asociadas a los procesos y en este análisis, deben participar todos los agentes internos y externos de la organización implicados en el proyecto para plantear simulaciones de procesos, mejoras en la eficiencia de los mismos o plantear que opciones e indicadores serán los más adecuados. Para establecer las medidas e indicadores, diferenciaremos, siguiendo a Paul Harmon, entre medidas externas e internas. -

-

Las medidas externas: son los resultados de medidas del resultado de un proceso o cadena de valor y finalmente serán estas las medidas del éxito o fracaso del proceso global. Ejemplos: ingresos, satisfacción del cliente, crecimiento del mercado. Las medidas internas: son las que suceden dentro del proceso o cadena de valor y son las más fácilmente medibles. Ejemplos: costes y tiempos de producción, eficacia de una determinada función o proceso, etc. 305


Estos dos tipos de medidas conforman un ciclo de retroalimentación como el siguiente:

La recomendación para establecer las medidas es la siguiente: fijar primero las medidas externas y después ir a mejorar las medidas e indicadores internos, de forma que nos aseguremos de que los resultados que alcancemos en las medidas internas resultarán beneficiosas para la organización, pues lo serán para el mercado y los clientes. Esta, sin embargo, no es la práctica con la que normalmente actuamos al realzar nuestro trabajo, prefiriendo por comodidad centrarnos en los resultados internos sin abordar la problemática de los factores externos sobre los cuales creemos tener menor control. En consecuencia, deberemos estar atentos a las señales del mercado y los clientes, retomando la visión de la empresa orientada al cliente, por lo que será preferible a la hora de tomar nuestras medidas, centrarnos en las medidas de salida del proceso, pues serán estas las que más directamente afectarán a la satisfacción del cliente y no tanto en las medidas internas del proceso, pues si el cliente no va a estar satisfecho con el resultado, da igual lo eficientes que seamos en los distintos pasos del proceso. A la hora de considerar las medidas de salida del proceso, podemos usar como referencia la clasificación en tres categorías de los requerimientos de los clientes realizada por el Dr. Noriako Kano, un experto en control de calidad, -

306

Requerimientos básicos: lo mínimo que esperan los clientes del producto o servicio. Satisfactorios: medidas del servicio que agradan al cliente y de las que cuantas más tengamos, más contento estará este. Placenteras: cosas que el cliente no se espera.


Respecto a que estrategia seguir para la identificación de indicadores, al contrario que en la fase de Levantamiento de procesos, que resaltábamos la importancia de la perspectiva Bottom-Up, para la identificación de indicadores, inclinaremos la balanza hacia la perspectiva Top-Down. La perspectiva Bottom-Up para los indicadores, utilizada para el desarrollo de sistemas de inteligencia de negocio y reporting, es una perspectiva muy tecnológica, en la que mandan los datos y nos vemos inmersos en montones de estos datos, de distintos orígenes y sistemas, por lo que tendremos que movernos hacia la creación de un modelo de datos que ordene esa maraña y que muy probablemente no reflejará las necesidades de negocio. La perspectiva Top-Down para la identificación de medidas e indicadores, pone sin embargo a los objetivos y requerimientos de negocio por encima de los datos, realizando una operación de reingeniería inversa para, en función del modelo de negocio, establecer qué se necesita medir y que datos serán necesarios recabar, identificando los orígenes de datos existentes para esas medidas o creando nuevos orígenes de datos para poder disponer de ellos y de sus combinaciones, lo que con frecuencia resultará en la necesidad de modificación de determinados procesos o partes de los mismos. Por supuesto que ambas perspectivas, al igual que en la fase de Levantamiento de procesos, coexistirán durante este análisis de medidas e indicadores, sin embargo, en este punto se nos hace más lógico el predominio de la perspectiva Top-Down, por ser mucho más flexible a las necesidades de negocio y los cambios que en este puedan producirse. Recordando una cita de Martin A. Gould: “Nos estamos moviendo de la sociedad de la información a la sociedad de los procesos en la que la información (los datos) es sólo el aceite que mueve la rueda de los procesos.” Los KPIs se monitorizan en las plataformas BPMS a partir de información proveniente de múltiples fuentes, bases de datos y sistemas, presentándose la misma en forma de gráficos e informes denominados “dashboards” o tableros de mando, orientados a diversas áreas de la empresa (finanzas, recursos humanos, gerencia, etc.) así como otros más específicos y los relacionados con la operativa de procesos concretos.

Six Sigma y Balance Scorecard. Tal vez la metodología más usada para la medida de procesos es Six Sigma por su especialización en el análisis estadístico de procesos. Six Sigma no nos dice como analizar o diseñar procesos, sino que suele trabajar sobre 307


los resultados de procesos ya existentes, sin embargo, Six Sigma es tal vez la mejor metodología para medir los procesos a través del análisis estadístico de las salidas de los procesos para poder decidir sobre su estado y necesidades de mejora o corrección. Generalmente los proyectos de mejora de procesos con Six Sigma se realizan sobre subprocesos o sobre actividades, aplicando el ciclo DMAIC ya descrito con anterioridad al hablar de Six Sigma, en busca de la mejora de procesos en base al establecimiento de medidas y la captura y análisis de las mismas para la mejora del proceso. La aplicación de Six Sigma debe ser vista como una meta en la reducción de la variabilidad del proceso, de forma que este se ajuste a los requerimientos del cliente y a los resultados deseados para el mismo. Al tomar medidas nos centraremos en: -

Inputs: medir las entradas para asegurarnos de que no tenemos problemas con las entradas del proceso. Medidas del proceso: como costes, tiempos, valor, trabajo. Outputs: medidas de salida del proceso y satisfacción de los clientes.

George Eckes, un autor de Six Sigma recomienda 3 reglas a la hora de realizar las mediciones: -

Medir sólo lo que es importante para el cliente. Medir sólo las salidas de los procesos sobre las que podamos realizar mejoras. No medir una salida para la cual no disponemos de datos históricos de insatisfacción del cliente.

Como vemos, existe una clara orientación al cliente y a la satisfacción del mismo (empresas cliente céntricas) en las que las medidas que establezcamos para el rendimiento de los procesos además de permitirnos evaluar la calidad y eficiencia del proceso deben estar alineadas con esta visión cliente céntrica como foco central. Una vez dispongamos de las medidas asociadas a las distintas actividades del proceso estaremos en posición de analizar las mismas para conocer el grado de valor que cada una de las actividades aporta al proceso, evaluar el grado de acercamiento a los objetivos planteados y si el proceso está cumpliendo o no con lo esperado. Este análisis nos resultará trivial en muchos casos, en los que en la fase de levantamiento de procesos habremos identificado ya medidas no correctas, por lo que podremos resolver el aná308


lisis de forma rápida, sin embargo, estos casos no serán los más frecuentes, por lo que necesitaremos de unos análisis más profundos de las medidas que obtengamos, así como realizar simulaciones para obtener la causa de estas y sus posibles soluciones. Estas soluciones requerirán en algunos casos del rediseño de los procesos y en otros de cálculos estadísticos más complejos, como análisis de regresión o diagramas de dispersión, para evaluar el valor que cada actividad aporta al proceso, así como analizar los resultados del mismo en función de distintas variables asociadas al proceso. En muchos de estos casos utilizaremos los diagramas de espina de pez de Ishikawa o diagramas de causa-efecto para encontrar las causas de los problemas o desviaciones en el proceso y nos encontraremos también con frecuencia con la regla del 80/20 donde el 20% de las causas generan el 80% de los problemas. Con los resultados de las medidas de los procesos y establecida también una línea base de mediciones en las que estas se encuentren en los rangos correcto para producir los resultados esperados del proceso, volveremos a la fase de mejora de procesos, para analizar de cada actividad, si aporta valor al cliente, si aporta valor a otra actividad en el proceso o por el contrario no aporta ningún valor y es una perfecta candidata para ser eliminada. Otro aspecto a considerar en las medidas e indicadores que establezcamos es tener cuidado con la frecuencia de estas medidas, en especial con las que involucran medidas de tiempo, pues pueden ser recogidas en tiempo real, de forma diaria, mensual, anualmente o en periodos concretos de tiempo, por lo que la recogida de estos indicadores puede y suele estar condicionada por su disponibilidad en el tiempo. Además de Six Sigma, muchos de los frameworks y estándares vistos en el capítulo anterior como SCOR, en la cadena de valor, Sarbanes-Oxley, para indicadores financieros, VRM (Value Reference Model), APQC, etc. ofrecen multitud de medidas e indicadores para los procesos que describen cada uno de ellos y nos pueden resultar de gran utilidad a la hora de definir las medidas más apropiadas para nuestros procesos y la forma de medirlas y controlarlas en base a estándares y buenas prácticas ya contrastadas. Uno de estos frameworks, y el más utilizado para definir y controlar las medidas es el Balance Scorecard (BSC), introducido por Robert Kaplan y David Nolan en la década de los noventa para ayudar a las organizaciones a alinear, comunicar y hacer un seguimiento del progreso en la estrategia, 309


metas y objetivos de negocio. Este modelo de Cuadro de Mando no sustituye los métodos de gestión existentes ni elimina las medidas e indicadores actuales, sino que los complementa, ordena y les da una mayor coherencia. El BSC o Cuadro de Mando Integral, en español, se estructura en cuatro pasos de implementación: -

Convertir la visión corporativa en metas de funcionamiento, Comunicar la visión y vincularla con el desempeño individual, Planificación de negocios, y Retroalimentación, aprendizaje y reajuste de la estrategia.

El Cuadro de Mando Integral propone cuatro tipos o perspectivas de medidas: financieras, medidas internas de negocio, medidas de innovación y aprendizaje y medidas de clientes. -

-

-

-

310

Perspectiva financiera: basados en los indicadores financieros de la empresa. Debido a que estos indicadores se basan en el pasado de las empresas, algunos autores dicen que es como conducir un coche a 100 km/h mirando por el retrovisor. Algunos indicadores de este tipo son: índice de liquidez, índice DuPont, rendimiento del capital invertido, flujo de caja, ROI, etc. Perspectiva del cliente: cómo ve el cliente a la organización y qué debe hacer la empresa para retenerlo como cliente, independientemente de cómo vayan los resultados financieros. Se miden las relaciones con clientes y las expectativas que estos tiene sobre la empresa. Perspectiva del proceso interno: analiza los procesos internos usados para satisfacer a clientes y poder lograr los niveles de rendimiento financiero, para ello se analizan en que procesos debemos mejorar para satisfacer a clientes y accionistas. Se clasifican en: Procesos de operaciones, de gestión de clientes, de innovación y de medioambiente y de comunidad. Ejemplos de indicadores en esta perspectiva son: número de actividades, tasa de oportunidad de éxito, efectividad del equipamiento, etc. Perspectiva de innovación y aprendizaje: basada en intangibles, analiza cómo puede la organización seguir mejorando para crear valor en el futuro, son los indicadores que dotan a la organización de la capacidad de mejorar y aprender. En esta perspectiva se critica la visión de la contabilidad tradicional, que considera la formación como un gasto y no como una inversión. Indicadores de este tipo son: satisfacción de empleados, pro-


ductividad, necesidades de formación, bases de datos estratégicas, patentes y copyrights, iniciativa de las personas, capacidad de trabajar en equipo, tasas de enfermedad de empleados, porcentajes de promoción interna, rotación de empleados, relación de género, etc. Cada organización adecuará estas perspectivas de acuerdo a sus propias estrategias, donde lo esencial no es analizarlo todo, sino la forma en que vinculamos las distintas perspectivas de forma que tengamos un equilibrio entre las mismas (pues las acciones sobre una variable tendrán consecuencias sobre otras variables e indicadores) y en este sentido, tener unos magníficos resultados en una de las perspectivas y no en otras, afectará de forma negativa a los resultados globales.

El Cuadro de Mando Integral requiere por parte de la empresa para su implementación de una cultura participativa, transparencia en la comunicación de la información y motivación de los empleados. Aunque cada empresa debe diseñar su propio conjunto de indicadores y medidas, existen una serie de indicadores utilizados en la mayor parte de los Cuadros de Mando que nos pueden servir de guía: -

-

Indicadores Financieros: o ROI (Retorno de la Inversión) o Valor Añadido económico o Cash Flow Indicadores de Clientes: o Satisfacción Global o Retención de clientes o Penetración de mercado 311


-

-

o Cuota de mercado Indicadores de Procesos Internos: o Tiempos de respuesta o Calidad o Coste Indicadores de Innovación y Aprendizaje: o Innovación o Introducción de nuevos productos o Satisfacción de empleados o Capacidad de los empleados o Sistemas de Información

BPM, a modo de Cuadro de Mando Integral, concede muchísima importancia al control y monitorización de la actividad empresarial, y en este aspecto radica una de sus principales fortalezas, al permitir crear modelos de procesos que pueden ser testeados y evaluados antes de su implementación, monitorizar lo procesos mientras estos se ejecutan, establecer indicadores y medir y analizar el rendimiento de nuestros procesos, integrando las soluciones de cuadro de mando e inteligencia de negocio en la misma suite donde modelamos y ejecutamos nuestros procesos. Pero dejaremos para el último capítulo dedicado a los BPMS los detalles de cómo lo realiza y trataremos en el siguiente apartado una técnica más para el análisis de los procesos como es la simulación de los mismos y que unida a la capacidad de establecer indicadores y medidas para los procesos, convierten a BPM y a los BPMS en herramientas extremadamente poderosas para el análisis y control de la actividad empresarial. BPM concede muchísima importancia a los indicadores y medidas del proceso, hasta el punto que recomienda no comenzar ningún proyecto si no podemos establecer medidas e indicadores para luego comprobar las mejoras sobre los mismos. Esta perspectiva debemos sin embargo tratarla con cautela, pues existen situaciones como puedan ser la reingeniería, transformación o cambio radical, en las que podemos partir de cero. Así mismo, trabajando incluso en mejora de procesos, no debemos perder el objetivo final de BPM y caer en el error de convertir nuestros procesos en meras herramientas para la recogida de datos o que las medidas no nos sirvan para re-planificar y poder tomar decisiones sobre la estrategia y rumbo a seguir por nuestra empresa.

312


Simulación de procesos. En esta fase validaremos el funcionamiento del proceso para comprobar que este funciona y cumple con los objetivos para los que fue diseñado. El objetivo en esta fase es identificar cuellos de botella y prevenir “bugs” y errores antes de su puesta en marcha, simulando la operativa del proceso y escenarios de funcionamiento en los que incluiremos a las personas y roles que participarán en el mismo, los datos (que en estos momentos pueden ser reales o ficticios, si aún no disponemos de los mimos), comprobar el correcto funcionamiento de las integraciones y aplicativos externos que necesitará el proceso para realizar su cometido, realizar pruebas de carga, comprobar las herramientas de medición y control y asegurarnos de que los indicadores del proceso se ajustan a la línea base establecida para los mismos. Cuanto más complejos y grandes sean los procesos, más recurriremos a la simulación para analizar sus resultados. En un proceso simple podremos calcular sin mayores dificultades el tiempo total del proceso sumando las pocas actividades con las que cuente, sin embargo en procesos más complejos, este resultado no será tan obvio y dependerá de múltiples combinaciones, posibles retrasos e incertidumbres asociadas al proceso, por lo que el ejecutar varias simulaciones del proceso nos permitirá calcular una media ponderada de tiempos del proceso. Podemos hacer una comparación del proceso de simulación y del comportamiento del diseño de un proceso con el mundo de la biología a la hora de predecir el comportamiento de un proceso. Esta comparación con la biología hace referencia a la diferencia entre “genotipo” y “fenotipo”. El “genotipo” se refiere a la dotación genética de un individuo, a toda la información genética que posee un organismo, y el “fenotipo” es la expresión en el individuo de ese genotipo, junto con las variaciones ambientales que pueden influir sobre el mismo y que puede manifestarse, o no. De esta forma, genotipo y fenotipo no están siempre relacionados el uno con el otro, algunos genotipos sólo se expresan bajo determinadas condiciones y algunos fenotipos pueden ser el resultado de varios genotipos. En BPM podemos de alguna manera considerar al modelo en BPMN y su código BPEL como el “genotipo” del proceso, el cual una vez ejecutado y puesto en funcionamiento, puede para un observador externo, reflejar el comportamiento exacto del “genotipo” o modelado realizado, o puede que no, y que este no se ajuste al comportamiento esperado o diseñado debido al entrono en el que se desarrolla el proyecto, y por ello, la simulación deberá no sólo 313


ajustarse al diseño del proceso (lo cual nos lo asegura la herramienta de BPMS que utilicemos) sino que deberá emular en la medida de los posible, el entorno y ambiente en el cual se desarrollará el proceso, para que podamos evaluar el mismo bajo las condiciones más reales posibles. La base sobre la que se apoyan los simuladores empleados en BPM es ejecutar los procesos miles de veces, desde el evento inicial hasta el final del proceso, recorriendo todos los posibles caminos del proceso, actividades y decisiones que puedan ser tomadas en los mismos y teniendo en cuenta los recursos y personas necesarios en cada paso. En el transcurso de la simulación, los datos del proceso son recogidos y analizados con herramientas estadísticas siendo los resultados de esta simulación del tipo: Número de veces que cada actividad es ejecutada en un proceso. Duraciones medias de las actividades. Costes calculados para cada actividad. El número de horas que un recurso ha trabajado en cada actividad. Los tiempos de espera en las distintas actividades. La utilización de recursos. El trabajo realizado por cada recurso. El coste de los recursos utilizados. La distribución de la carga de trabajo en las distintas actividades. Los tiempos totales de ejecución del proceso. Los costes totales del proceso. La evolución en la tecnología y algoritmos utilizados por los simuladores está en constante desarrollo y una de las áreas que más ha hecho evolucionar estas tecnologías de simulación es la de los videojuegos. Estos desarrollos comenzaron con el conocido juego de SimCity, un juego en el que debemos crear y gestionar una ciudad de forma que esta sea capaz de prosperar. Como toda simulación, esta parte de un modelo, la ciudad con la que comenzamos el juego, donde vemos como esta evoluciona a medida que avanza el tiempo. De lo bien que gestionemos nuestra ciudad: construyamos carreteras, hospitales, escuelas, industrias, recogida de basuras, agua, energía, etc. y gestionemos las entradas y salidas de dinero que tengamos, dependerá el éxito o fracaso de nuestra ciudad en el juego.

314


SimCity es un juego desarrollado por MAXIS y distribuido por EA Games, que hace uso de la simulación de las relaciones causa-efecto de un sistema urbano y que es utilizado por numerosas universidades y urbanistas para simular el comportamiento de las ciudades. Este juego y sus derivados (existen múltiples versiones del juego aplicados a distintos entornos incluidos los sociales: los Sims), hacen uso de las propiedades emergentes de los sistemas, es decir, aquellos sistemas cuyo comportamiento es regido desde los niveles más bajos hacia los más altos, desde la simplicidad a la sofisticación. Algunos ejemplos de sistemas emergentes son: las colonias de hormigas, las ciudades o el cerebro humano, en los que a partir de componentes simples del sistema, sus interacciones, y siguiendo unas simples reglas, surgen comportamientos complejos y difíciles de explicar debidos a un comportamiento ascendente que provoca la inteligencia colectiva. En el caso de SimCity, la ciudad y muchas de sus unidades, se auto-organizan. Aunque nosotros como jugadores diseñemos y construyamos ciudades, estas evolucionan de manera impredecible a partir de algoritmos simples (ver el estado del vecino y actuar en consecuencia) y dejando al ordenador hacer los miles de cálculos. En SimCity se expresa perfectamente la complejidad auto-organizada, como un modo de expresar la evolución y desarrollo de las ciudades y sistemas urbanos, donde estas no son el resultado de un proceso planificado y simplemente se desarrollan reconociendo patrones, aprendiendo y remodelándose una y otra vez como todo sistema complejo. Las herramientas de simulación del comportamiento de los procesos y las organizaciones operan de forma parecida a SimCity, analizando por ejemplo como cambiando determinadas reglas de negocio se producen cambios en el comportamiento de los procesos. Es de esperar que las herramientas de simulación harán uso y alcanzarán rápidamente los niveles utilizados en estos juegos para analizar nuestros modelos de procesos e incluso de negocio y del Business Motivation Model, que también podrá ser simulado para comprobar los resultados de las estrategias definidas y que dada la importancia que este tipo de simulaciones tiene para la empresa, muchos fabricantes de software están desarrollando herramientas de simulación para este tipo de modelos. Aunque de lo descrito sobre las herramientas de simulación podamos inferir el dejar esta tarea para ser realizada enteramente por las herramientas informáticas sin apenas intervención humana, esta intervención humana será necesaria y fundamental para la toma de buenas decisiones relativas a 315


nuestros procesos y sus posibilidades de mejora. Si bien debemos reconocer que los humanos no somos perfectos a la hora de tomar las mejores decisiones, estas frecuentemente se encuentran sesgadas y nos dejamos llevar por errores de apreciación y evaluación. El cálculo probabilístico, por ejemplo, nos proporciona mucha información como los posibles resultados o sus frecuencias, pero al mismo tiempo, esta visión, nos esconde la comprensión de otras partes del problema que estudiamos y a veces, es preferible disponer de menos información, pero que esta sea más valiosa, como pueda ser la del resultado más probable. Nuestras diferencias de pensamiento respecto a las máquinas siguen siendo muy significativas, y muchos planteamientos empresariales no podrán ser simulados completamente por los sistemas informáticos, pues incluso en la resolución de algunos problemas lógico-matemáticos, los ordenadores no cuentan con la capacidad de “salirse del sistema” y abordar nuevas perspectivas y visiones del problema necesarias para la resolución de muchos de estos algoritmos.

Esperar lo inesperado. Los procesos empresariales medianamente complejos son impredecibles debido a las expectativas que puedan tener los clientes, los cambios políticos y de mercado o innovaciones tecnológicas que nos llevarán a considerar no sólo los aspectos controlables y analíticos de los procesos, sino también su impredecibilidad. La mayoría de los modelos son representaciones estáticas de una situación, y muchas veces es difícil comprender todas las situaciones e interacciones que pueden afectar a un modelo y sus consecuencias por muchas técnicas, herramientas y conocimientos que usemos para su predicción. De hecho, muchos de los grandes negocios y mejoras de procesos han surgido por casualidad, o fruto del azar en la combinación de distintas posibilidades y configuraciones de modelos de negocio y diseño de procesos. Es por ello que no desperdiciaremos las posibilidades que la simulación nos ofrece para conocer las distintas implicaciones, tanto internas como con otros sistemas, combinando estas con la capacidad de implementar y simular nuestros propios modelos de negocio que nos proporcionan las plataformas de BPM. Durante la simulación de nuestros procesos, entramos en terrenos altamente innovadores y creativos, que requerirán del equipo de proyecto el poner a prueba estas capacidades en la búsqueda de soluciones innovadoras para analizar y mejorar los procesos simulados. La enorme potencia de 316


las herramientas computerizadas de simulación, nos permitirán ejecutar los procesos miles de veces, para analizar los resultados y poder modificar las variables del proceso para probar otras soluciones y configuraciones posibles, lo cual nos ayudará mucho en este proceso, permitiéndonos “chatarrear” con las distintas posibilidades y configuraciones. Nassim Nicholas Taleb decía en su libro “Los cisnes negros” que estaba en desacuerdo tanto con los seguidores de Marx como con los de Adam Smith, pues según él, la razón por la que funcionaba el libre mercado es porque permitía a la gente ser afortunada gracias a la posibilidad de que cualquiera pudiese hacer pruebas de ensayo y error, y que en este proceso no era necesario que el estado diese incentivos o premios. La estrategia en consecuencia es “chatarrear” todo lo que podamos sobre nuestros procesos y modelos de negocio en busca de los cisnes negros de los que habla Taleb, esos hechos fortuitos (como los cisnes negros), imposibles de calcular, antes de ser percibidos, en base a la información disponible mediante métodos estadísticos y probabilísticos y que sus efectos suelen ser sorprendentes y de impacto desproporcionadamente grande. En este libro, altamente recomendable, Taleb nos descubre los errores que cometemos en los procesos de razonamiento cuando los humanos nos enfrentamos a la complejidad, la incertidumbre y la aleatoriedad y nos advierte de los errores en los que podemos incurrir al analizar los procesos y en cómo no solemos percatarnos de las situaciones inesperadas que escapan a nuestro análisis, en las soluciones innovadoras, capaces de producir esos resultados sorprendentes y de ahí la metáfora del cisne negro: acostumbrados a vivir en el hemisferio norte del planeta, pensamos que todos los cisnes son blancos, sin embargo en Australia existen cisnes negros. Sobre estos errores que cometemos, Taleb nos describe como a mayor frecuencia de ocurrencia de un hecho, menor sensibilidad tendremos frente a lo inesperado y como inconscientemente buscamos siempre lo que esperamos obtener, como el borracho que habiendo perdido una moneda en un callejón oscuro, la buscaba debajo de una farola porque allí había más luz. Medimos lo que esperamos medir en nuestros procesos y por esta tendencia, estableceremos las medidas e indicadores de lo que queremos medir, seleccionando únicamente los hechos que encajan en nuestras teorías, pues así es como funcionan nuestros cerebros, que necesitan tener todo perfectamente ordenado y comprensible. Esta situación es la vista cuando hemos analizado el establecimiento de medidas e indicadores de nuestros procesos, donde la tendencia tradicional era medir exclusivamente indicadores financieros, basados en resultados pasados de la empresa y muy vulnerables a los cambios del mercado. Si medimos únicamente resultados financieros, obtendremos 317


resultados financieros, por lo que ya en el Balanced Scorecard, hemos ampliado esta perspectiva financiera a otras perspectivas para alcanzar objetivos más allá de los meramente financieros y que redunden en una mayor sostenibilidad y posibilidades de supervivencia de la empresa. En el proceso de análisis y mejora de nuestros procesos, debemos aprovechar las herramientas de simulación y todo su potencial, por el ahorro de tiempo que producen a la hora de testear nuestros prototipos y no dejarnos llevar por las conclusiones obvias y superficiales apoyadas en una mínima cantidad de datos. Aunque la simplificación es buena, para ordenar lo complejo, debemos explorar también nuevos caminos no estructurados y comprensibles, pues la realidad, las empresas y los entornos en los que se desarrollan, son muchas veces desordenados, complejos e impredecibles. Al hablar de mejora de procesos hemos enumerado varias prácticas, entre ellas, la de la simplicidad, como vía para reducir la complejidad. Esta práctica sigue por supuesto siendo correcta a la hora de diseñar y mejorar nuestros procesos, sin embargo, debemos tener en cuenta a la hora de analizar, simular y buscar soluciones a problemas en nuestra organización, que esta simplicidad no significa que la explicación más sencilla sea siempre la mejor, por la misma razón que decirle a un niño que los bebés vienen de París para explicarles porque nacen los bebés, aunque sea mucho más sencillo de explicar que el proceso de reproducción biológica, no implica que esta hipótesis sea la correcta. En otros casos, creeremos que por disponer de un mayor volumen de datos y medidas, dispondremos de una mayor comprensión sobre el problema a analizar, cuando muchas veces, un mayor volumen de datos sólo implicará un mayor “ruido” que perturbará la elección de la mejor opción o solución. A pesar de lo metodológicos y estructurados que seamos en la gestión de nuestros procesos, las grandes mejoras e innovaciones en nuestros procesos no siempre vendrán de una correcta planificación, estrategia o mejor gestión de la innovación. Por mucho análisis que hagamos, no existe la predicibilidad exacta en los procesos empresariales medianamente complejos, pues aspectos como las expectativas de nuestros clientes, cambios políticos y económicos, innovaciones tecnológicas o movimientos de nuestra competencia, no podrán ser siempre predichos, controlados y trasladados a nuestros modelos y reglas de procesos, y muchas de las soluciones y caminos sorprendentes, serán descubiertas por casualidad (serendipia), que como a los artistas, sólo nos aparecerán trabajando, “chatarreando” con nuestros modelos estratégicos, con nuestros procesos y simulando escenarios en busca siempre de la excelencia y la mejora continua y como hemos adverti318


do al hablar de levantamiento de procesos, escuchando a las personas y considerando la perspectiva Bottom-Up. A la vista de la realidad económica y empresarial y la creciente complejidad del mundo en el que las empresas se desarrollan, la correcta gestión y organización de los sistemas empresariales y tecnológicos debe ser tenida en cuenta, pero no convertida en patológica, de forma que dejemos siempre un camino abierto a lo inesperado, más que para predecirlo, para estar preparados por si acontece. Esta idea que acabamos de exponer, está relacionada con el concepto científico y filosófico del determinismo, según el cual, absolutamente todos los fenómenos de la naturaleza, incluido el comportamiento humano, pueden ser predichos con exactitud por las leyes de Newton, es decir, que conociendo las condiciones iníciales de estos fenómenos, sean estos: eclipses solares, que me van a regalar en mi próximo cumpleaños, cuando se me caerá el pelo o si mi nuevo negocio va a tener o no éxito en el mercado. Como presuponemos, las leyes de Newton son de aplicación en algunos sistemas y entornos, pero no en todos y una visión determinista de las personas o de los procesos empresariales es algo que sabemos no podemos asumir como cierto. Como vemos, a pesar de lo bien que realicemos la mejora de procesos y lo constantes que seamos en la mejora continua, siempre existirán factores sobre los cuales nuestros procesos no podrán predecir su comportamiento a partir de las variables y reglas de negocio descritas en el mismo: la competencia, entorno político y económico, nuevas innovaciones tecnológicas, etc. por lo que siempre tendremos la impredecibilidad como una espada de Damocles sobre nuestra empresa y requeriremos no sólo de mejora continua de procesos sino de la agilidad y flexibilidad para adaptarnos a los cambios surgidos en el entorno. Ni BPM, aunando todas las metodologías y disciplinas de management y tecnológicas, será capaz de gestionar esta impredecibilidad, por lo que deberemos pasar más tiempo realizando benchmarking, analizando, evaluando, proyectando y observando nuestros procesos, que gestionando el día a día de los mismos y utilizar la disciplina de BPM y los BPMS, no sólo como herramientas de gestión y reporte, sino como herramientas de análisis y de ayuda a la toma de decisiones por parte de las personas, que son las que finalmente dirigirán los procesos. Las mejores innovaciones y mejoras sobre nuestros procesos vendrán de las personas, de su creatividad y capacidad dentro de la organización para compartir, experimentar y generar ideas, tanto desde los niveles más altos como desde los intermedios y los más bajos de la estructura de la organización. 319


Gestión del cambio e innovación. En todas las organizaciones existen cosas que no funcionan, cosas que todo el mundo conoce su ineficiencia o los problemas que causa al resto de la organización, pero a las cuales no se les hace frente. La causa de este dejar correr las cosas se encuentra principalmente en que muchas veces desconocemos el impacto real de ese mal funcionamiento y las implicaciones que tiene, no lo medimos ni analizamos (“no vaya a ser peor de lo que esperamos”), por lo que continuamos trabajando con él. Otras veces es el miedo (que surge de preguntarnos constantemente: “¿qué pasaría si…?”), o la vergüenza a ser nosotros quien identifiquemos un problema (“no voy a ser yo quien lo diga”), la no predisposición a solucionar el problema (“que igual me toca a mi arreglarlo”…”mejor me ocupo sólo de lo mío”), las tareas del día a día o la burocracia que nos restan el tiempo y recursos necesarios para encarar, analizar y buscar soluciones a nuestros problemas. Las personas, sin duda alguna, pero también las culturas organizacionales asociadas a empresas jerarquizadas, que ya hemos analizado en la organización orientada a procesos, más ocupadas de la burocracia y las políticas internas que en afrontar nuevos retos y cambios de paradigmas, tienen mucha culpa de estos miedos, no ya al cambio, sino a reconocer y buscar soluciones a los problemas, en especial cuando estos se salen de “mi departamento” y afectan a toda la organización (como es el caso de los procesos), creando de forma inconsciente, organizaciones estáticas que evitan constantemente ser modificadas. La realidad es que la solución a este problema en las organizaciones es mucho más sencilla que tener que pasar por el miedo, el escaqueo o la vergüenza, pues el problema raíz de estas situaciones suele estar en los procesos mal diseñados y no en las personas que los ejecutan, por lo que si transmitimos una cultura y compromiso con la mejora de los procesos, descargamos la culpa en el diseño de estos y no en las personas, que pasarán a ser partícipes de la mejora de procesos. “Blame the process, not the people”, que traducido es “culpa al proceso, no a la persona”, es una frase que oímos con bastante frecuencia al hablar de procesos, pero que aunque no tenga su falta de razón, pues aunque resulta obvio que en un buen diseño de procesos y de la correcta definición de las actividades y tareas que deberán realizar las personas (trabajadores, directores de áreas, líderes de proyectos y responsables empresariales), se fundamentará la correcta imple320


mentación de los procesos de negocio de la empresa, no podemos negar que en el lado humano, en la complejidad intrínseca de las personas, en especial cuando deben interactuar entre ellas, en las diferentes personalidades, escalas de valores y egos personales, se encuentran también muchos de los problemas de nuestras organizaciones. Ya hemos visto como debido a los cambios en el entorno de negocio y por consecuencia de que las organizaciones desarrollan sus actividades en un entorno cambiante e inestable, los procesos deben someterse a continuos cambios que deberemos asumir. Hacer cosas cambia las cosas; no hacer nada deja las cosas como están, y la principal resistencia para la implementación de estos cambios la encontraremos sin duda alguna en las personas. La resistencia de las personas al cambio es uno de los factores que más comúnmente ponen en riesgo la implementación de cualquier proyecto y los de BPM en particular, por su capacidad de alterar las estructuras de la empresa. Esta resistencia se presenta tanto en los cuadros directivos como en los operacionales, pues los proyectos BPM afectan a todas las personas de la organización. Salir de las posiciones de comodidad en las que estamos, es algo que nos cuesta a todas las personas, e inconscientemente, opondremos resistencia a estos cambios, aún cuando la implementación de estos cambios produzcan un estado más beneficioso que el anterior. Para el éxito del proyecto, ya hemos visto como las personas no sólo se verán afectadas por el cambio que se produzca en los procesos en los que estén involucradas, sino que además deberán participar activamente en la mejora de estos y aportar a lo largo del ciclo de vida del proyecto, sus conocimientos e involucración con el mismo, y este último punto es fundamental para poder especificar tanto los procesos actuales como las mejoras sobre los mismos. Hablar de BPM y de gestión por procesos es mucho más que hablar únicamente de procesos, de entradas, transformaciones y salidas. Hablar de BPM significa orientación a cliente, de eficiencia operativa, flexibilidad y adaptabilidad a los requerimientos y necesidades del mercado y en consecuencia de cambio organizacional, por lo que deberemos romper con la cultura establecida y la inercia de ocuparnos de nuestras tareas repetitivas del día a día y abordar un pensamiento más abierto al cambio. BPM permite una respuesta mucho más rápida al cambio, proporcionando la agilidad necesaria para la mejora y adaptación continua. En este 321


sentido, los sistemas BPM (BPMS) nos proporcionan un entorno sin igual en el que visualmente modificamos los procesos, evaluamos su operativa en un entorno de pruebas y los ponemos en producción una vez validados. BPM trata sobre el cambio, sobre los modelos actuales de negocio y procesos con los que opera la empresa pero fundamentalmente, de cómo mejorar la eficacia y eficiencia de estos procesos, de su mejora continua y de su transformación para adaptarse al cambio. El asegurarnos de que las personas comprendan los cambios, las implicaciones que estos tienen para su trabajo y que estas acepten los cambios será el talón de Aquiles de los proyectos en que nos embarquemos. Muchos proyectos fracasan por la resistencia de las organizaciones al cambio, por eso es importante conocer la gestión del cambio y de las personas para asegurar el éxito del proyecto y es uno de los motivos de porqué han fracasado muchos proyectos de BPR y por el cual muchas veces se escogen proyectos de pequeño alcance al inicio de los proyectos formados por procesos pequeños. Para gestionar el cambio, deberemos alinear el proyecto con los objetivos y estrategia de la empresa de forma que podamos dirigir el proyecto hacia un claro destino entendido por toda la organización. Deberemos asegurarnos el compromiso de la alta dirección con el proyecto y la involucrando a todo el equipo y stakeholders internos y externos y preparar la organización para el cambio, elaborando los planes de formación necesarios para todo el personal involucrado en el proyecto y realizar reuniones de trabajo para explicar qué, cuándo, cómo y por qué vamos a llevar el proyecto adelante. Así mismo será importante identificar a los líderes o personas con amplios conocimientos de la organización y sus procesos y que dispongan de la suficiente influencia en la organización, para que nos acompañen en la transmisión de la importancia del proyecto y actúen como líderes del cambio. Estos líderes dentro del proyecto deberán ser formados en gestión de procesos, en BPM, en metodologías, diseño y modelado de procesos y en el uso de las herramientas BPMS. La innovación junto a la gestión de proyectos y la gestión del cambio la tendremos en cuenta en todo el proyecto, pero será en esta fase de simulación de los procesos, previa a su implementación, cuando esta actitud deba tener mayor preponderancia, pues es en esta fase en la que realizaremos todo tipo de análisis técnicos, económicos y de negocio para determinar las mejores opciones de implementación y las implicaciones de los cambios. Así mismo, puede que en esta fase realicemos ajustes en los procesos, añadamos o modifiquemos métricas e indicadores y en la que dispongamos de 322


una visión más real de los que será el proceso una vez implementado, por lo que aprovecharemos esta fase para aplicar todas las capacidades de innovación y creatividad, haciendo uso de las herramientas de simulación para evaluar las mejores optimizaciones y mejoras sobre nuestros procesos. Para la gestión del cambio y la innovación, las teorías más conocidas y utilizadas son el Modelo de Kotter, para la gestión del cambio y la metodología TRIZ para la gestión de la innovación. Modelo de Kotter: John Kotter, profesor de Harvard, presenta en su libro “Liderando el cambio”, publicado en 1995, una metodología en ocho pasos hacia el cambio.

Paso 1: Crear sentido de urgencia: Desarrollar un sentido de urgencia alrededor de la necesidad de cambio, despertando la motivación inicial para lograr el movimiento. Paso 2: Formar una poderosa coalición: Bajo el liderazgo del jefe de proyecto, formar una coalición o equipo identificando a las personas líderes de diferentes perfiles y niveles dentro de la organización, con la suficiente influencia dentro de la organización y compromiso para trabajar conjuntamente en la continua construcción de la urgencia e impulsar el cambio. Este equipo debe estar formado por diferentes perfiles y niveles dentro de la empresa. 323


Paso 3: Crear una visión para el cambio: Crear una visión que la gente pueda entender y recordar fácilmente recogiendo las ideas y soluciones dispersas. Esta visión ayudará a que todos entiendan la necesidad del cambio, determinando los valores que fundamentan el cambio, visualice el futuro de la organización y se acompañe de una estrategia para ejecutar la visión. Paso 4: Comunicar la visión: La visión no bastará con crearla, habrá que comunicarla con fuerza y la frecuencia suficiente para transmitirla a toda la organización así como transmitirla a través del ejemplo en nuestras actuaciones, aplicándola a todos los ámbitos en los que trabajemos. Paso 5: Eliminar los obstáculos: Comprobar constantemente la barreras que puedan dificultar el cambio: estructura organizacional, personas, departamentos, sistema de recompensas, etc. que puedan afectar al mismo y adoptar medidas para eliminar estas barreras, analizar el por qué de su resistencia y ayudarles a compartir la visión. Paso 6: Asegurarse triunfos a corto plazo: Procurar pequeñas victorias en las fases más tempranas del proceso de cambio buscando proyectos de éxito asegurado y que aseguren la continuidad de la inversión, para motivar al equipo y a la organización en el cambio y convencer a los que se oponen a este. Paso 7: Construir sobre el cambio: Kotter sostiene que muchos proyectos de cambio fallan porque se declara la victoria muy tempranamente, cuando las victorias son sólo el comienzo de lo que se necesita para lograr lo cambios a largo plazo, por lo que deberemos construir progresivamente sobre lo que salió bien y mejorarlo. Paso 8: Anclar el cambio en la cultura de la empresa. Asegurarnos la continuidad en los planteamientos de cambio apoyándonos en los éxitos anteriores y convenciendo del modelo exitoso alcanzado.

324


TRIZ (Teoriya Reshniya Izobretate Zadatch): Más relacionada con la innovación y como una de las principales metodologías para la gestión de esta, tenemos TRIZ surgida a partir de Six Sigma. TRIZ es el acrónimo en ruso de Teoría Inventiva de Resolución de Problemas, una metodología para analizar los problemas y buscar soluciones innovadoras a los mismos que ha sido asumida por muchos consultores de Six Sigma. TRIZ dispone de ocho marcos evolutivos para la guía de decisiones estratégicas, 76 soluciones estándar para elementos de ingeniería en un sistema, 39 parámetros para caracterizar problemas y 40 principios innovadores para solucionar contradicciones. En TRIZ hay dos metodologías, una para problemas tácticos y otra para problemas estratégicos. Aunque es una metodología bastante compleja y no fácilmente aplicable para la gestión de la innovación en pequeñas y medianas empresas, es una de las teorías más elaboradas y contrastadas para la gestión de la innovación.

Implementar el proceso: En esta fase procederemos a implementar el proceso mejorado, el To-Be que hayamos alcanzado, que pasará a convertirse en el nuevo As-Is. Para ello adquiriremos los recursos humanos y materiales necesarios, formaremos a los trabajadores y personal involucrado en el proyecto y seleccionaremos las herramientas tecnológicas que vamos a utilizar para implementar, gestionar y monitorizar los procesos. Como hemos visto, el interfaz a través del cual interactuaremos con el proceso será generalmente un frontal web, desplegado desde el BPMS en forma de portal y a través del cual los usuarios y roles asignados al proceso podrán realizar su trabajo. Las interacciones a través de este portal se realzarán principalmente en forma de “lista de tareas” pendientes por realizar de los distintos usuarios. Esta lista dispone con sus correspondientes criterios de priorización y capacidades para gestionar la lista de tareas: consultar las tareas tanto realizadas como pendientes, gestión de alertas, estado de cada una de las actividades y del proceso en su conjunto o el traspaso de tareas entre distintos participantes atendiendo a reglas de negocio previamente definidas. La seguridad para el acceso a la intranet, extranet o portal web para la gestión de los procesos por parte de los distintos usuarios se gestionará 325


normalmente desde fuera del BPMS a través de un directorio LDAP aunque desde dentro del BPMS tendremos la posibilidad de definir derechos y permisos de acceso a usuarios o grupos de estos. Debemos recordar aquí que la implementación no será únicamente una implementación de TI o de un BPMS concreto, pues como hemos visto, un proyecto de BPM no es sólo tecnología. Aunque es en esta fase de implementación en la que el personal de TI estará más involucrado y asumirá gran parte del peso de la implementación que recaerá en la plataforma BPMS y sin la cual no podremos implementar el proyecto, lo fundamental en toda implementación de BPM será entender la visión de la organización orientada a procesos, interiorizarla y adaptarla a nuestra organización, comprendiendo el cambio de paradigma y cultural que supone, pues este conocimiento y experiencia supondrá el 75% de las posibilidades de éxito del proyecto. La gestión ideal por procesos o el escenario ideal en el que implementar BPM y alcanzar resultados espectaculares, es aquel en el que los responsables de negocio y tecnológicos de la organización se embarcan conjuntamente en la transformación de los procesos de negocio de la empresa, abandonando las acciones aisladas en proyectos de BPM y de mejora de los procesos, a un proyecto de transformación global de los procesos de negocio y la empresa, dirigido y soportado por los directivos y donde estos disponen de una visión y pensamiento orientado a procesos que trasladan a lo largo y ancho de la organización. Dependiendo de cómo hayamos rediseñado los procesos, dispondremos de un modelo del proceso mejorado que queremos implementar, modelado en BPMN sobre una herramienta de modelado de un BPMS, en cuyo caso la implementación será prácticamente inmediata. En otros casos dispondremos de información documentada sobre el proceso a implementar, en cuyo caso tendremos que trasladar esta especificación a la herramienta de modelado del BPMS. El personal que participe en el proyecto, deberá ser formado y capacitado tanto sobre la herramienta BPMS como sobre el proceso y su operativa, por lo que desarrollaremos los manuales específicos para cada puesto y proveeremos de la formación necesaria a todo el personal involucrado, así como de la motivación y compromiso de estos con el proyecto, que a pesar de haber contado con este compromiso en las fases anteriores, deberemos mantener también ahora en la implementación. 326


Realizaremos también los test del proceso sobre la plataforma BPMS, así como las pruebas de carga, realizando las modificaciones y depuraciones necesarias para comprobar que todo funciona perfectamente antes de pasar a la puesta en marcha. Para ello, será una buena práctica el realizar un prototipado lo más real posible, para en un entorno de pruebas, validar el proceso operando correctamente y prestando especial atención a las integraciones y procesos automatizados que requieran de orígenes de datos externos. Puesto que la implementación del proyecto recae principalmente en los BPMS, dejaremos para el siguiente capítulo dedicado a estos sistemas los detalles de esta implementación.

Puesta en Marcha del proceso: ¡Y ya tenemos todo listo para funcionar! En la puesta en marcha, deberemos disponer de un plan de implementación para desplegar todos los sistemas, planes formativos e implementación de todos los aspectos relacionados con la puesta en marcha del proyecto. Esta es una fase delicada, en la medida en que muchas organizaciones llegan a este punto y al final no se deciden a poner en marcha el proyecto. Los motivos pueden ser varios, pero principalmente, la resistencia al cambio, es lo que retraerá a las personas a finalmente conservar lo que ya tienen y no querer cambiarlo por algo nuevo, aunque este algo ofrezca ventajas y mejoras sobre lo ya existente. Es por ello que hemos insistido en todo el proceso en la gestión del cambio, en la formación y en la implicación del personal desde la fase de iniciación y de levantamiento de procesos, buscando su implicación y comprensión de los motivos del cambio desde la visión estratégica hasta los resultados de las medidas asociadas a los procesos, pues son las personas en última instancia las que deberán hacer uso del proceso y sin la implicación de las mismas, será imposible sacar adelante el proyecto e implementar los procesos mejorados en la organización. En este sentido son muchas las metodologías de implementación de procesos que abogan por el establecimiento de incentivos entre el personal de la empresa asociados al éxito en la implementación y a la adopción, buen manejo y continuidad de los nuevos procesos.

327


Control del proceso y Mejora Continua. En esta fase nos aseguraremos de haber alcanzado los objetivos por los cuales se puso en marcha el proyecto de BPM y realizaremos las comprobaciones e informes sobre las metas alcanzadas. Así mismo, nos aseguraremos de mantener el esfuerzo en la mejora de los procesos mediante la continuidad del proyecto en otros proyectos de mejora, para dar continuidad al ciclo de vida de los procesos y no dejarnos llevar por la inercia de dejar los procesos abandonados una vez finalizado el proyecto. Una vez implementado el proceso, el trabajo no finalizará en este punto, pues constantemente debemos monitorizar y controlar la operativa del proceso. Así, en esta fase de control del proceso, repasaremos cada punto de estos para identificar que puede ir mal en el mismo y establecer en esos puntos, medidas y alertas de control. Una vez tengamos todos los problemas identificados, buscaremos la manera de evitarlos o mitigarlos, discutiendo con el equipo involucrado en el proceso la forma de poder evitar la aparición de estos problemas. Mejora Continua es un término derivado de la gestión de la Calidad que significa que constantemente debemos monitorizar los procesos de negocio y realizar ajustes para asegurarnos de que el proceso es continuamente mejorado. Esto implica recoger las mediciones del proceso y los datos de indicadores del mismo, evaluar la satisfacción de los usuarios y clientes del proceso, revisando sus necesidades y expectativas, motivar al equipo de trabajo y proporcionar la formación necesaria a los mismos, así como mantener las líneas de comunicación abiertas con el equipo en busca siempre de la mejora y la innovación continua, a sabiendas de que siempre podemos hacer mejor las cosas y por encima de todo velar por que el proceso no caiga en el saco del olvido y que continuamente ofrezca valor y utilidad a los clientes. La mejora continua, como vimos al hablar de calidad, la realizaremos según el ciclo de mejora continua, en este caso dirigido a los procesos:

328


-

-

-

Evaluar: todos los aspectos del proceso de negocio, identificar oportunidades de mejora, cuellos de botella, efectividad del proceso, revisar necesidades y expectativas de los clientes, que las medidas e indicadores sigan siendo los apropiados, pues a medida que los proyectos y los procesos avanzan en su día a día, surgen nuevas necesidades, se crean nuevas expectativas y surgen nuevas oportunidades tanto de mejora de los procesos como de nuevos modelos de negocio y productos y servicios más innovadores, para todo lo cual, deberemos crear un plan para la implementación de los errores, debilidades y oportunidades identificadas, para haciendo uso de la flexibilidad de los BPMS poder implementarlos de manera ágil. Planificar: testear las mejoras que vayamos a introducir en el proceso antes de implementarlas, asegurándonos de que cumplen con todos los aspectos asociados con el proceso tanto técnicos como de negocio. Verificar: vigilar que los cambios aporten valor. Actuar: ejecutar los cambios en la organización.

Este ciclo de mejora continua se realizará principalmente a través de TQM, Six Sigma, BPR y haciendo uso de los propios sistemas BPMS. BPR y Six Sigma pueden ser utilizados para la mejora de procesos que no cumplen con las especificaciones de los clientes, Six sigma y TQM son utilizados ge329


neralmente para la mejora de los procesos y los BPMS serán la herramienta tecnológica a través de la cual podemos diseñar e implementar las mejoras sobre los procesos. La mejora continua y el control de la operativa de los procesos suele ser costosa y consume recursos, pero es necesaria para una correcta gestión de los procesos. Sin embargo, con BPM y la informatización de la gestión por procesos, esta tarea resulta mucho más sencilla y exacta, en especial en el control del ciclo de vida de los procesos y el monitoreo de los mismos en base a indicadores y medidas de cumplimiento de su eficiencia y valor ofrecido a clientes. Estas herramientas tecnológicas, sin las cuales no podemos implementar BPM serán los BPMS y son los que veremos en el siguiente capítulo.

Social BPM. Con este término de Social BPM, nos referimos a las posibilidades que en todo el ciclo de vida de BPM tienen los conceptos y herramientas de la denominada web 2.0 y como estos pueden ser usados para el diseño y mejora de procesos, su implementación y su posterior control. Estas herramientas son una extensión de las herramientas de software colaborativo, en las que haciendo uso de foros, wikis, blogs, redes sociales abiertas o cerradas y herramientas de votación, nos permitirán gestionar este entorno colaborativo y sus comunicaciones. Estas herramientas tendrán especial relevancia a la hora de gestionar el conocimiento e ideas aportadas por los distintos miembros en entornos geográficamente dispersos o donde podamos necesitar del anonimato de los empelados , partners de negocio, clientes y stakeholders del proyecto en general, para el establecimiento de esta colaboración y aprovechar las ventajas de las aproximaciones Bottom-Up, la inteligencia colectiva, la mejora de la experiencia de usuario y la innovación en las distintas fases del proyecto. Así, podemos usar estas herramientas en la fase de levantamiento de procesos, donde tanta importancia tiene la colaboración que establezcamos con los miembros de la organización y el equipo de proyecto a la hora de seleccionar los procesos y recabar todos los detalles sobre estos y sus posibilidades de mejora, lo cual mejorará la productividad en el desarrollo del proyecto y generará un entorno propicio 330


para el intercambio de ideas y la innovación. En la fase de modelado a la hora de discutir y aportar inteligencia colectiva al modelo. En la fase de análisis y mejora de procesos, donde tal vez nos sean más útiles estas herramientas para el aprovechamiento de esa inteligencia colectiva o en las fases de ejecución del proceso donde los usuarios pueden requerir de estos entornos colaborativos a la hora de tomar decisiones o en la fase de monitorización y control de procesos, para la compartición de opiniones y posibilidades de mejora sobre los resultados obtenidos.

TOC, Lean y Six Sigma dentro de un proyecto de BPM. A continuación daremos un repaso a como cada una de estas teorías (TOC, Lean y Six Sigma) se integra dentro de un proyecto de BPM. A la hora de aplicar estas tres metodologías dentro de un proyecto BPM enlazaremos las mismas en distintos puntos del ciclo de vida de un proyecto BPM.

TOC (Theory of Constraints): Partiendo de la estrategia, una de las primeras acciones que llevaremos a cabo es la selección de los procesos sobre los que trabajar. Con TOC (Theory of Constraints), partimos de una visión a alto nivel de todos los procesos para investigar donde están los problemas e identificar las restricciones existentes o potenciales. Esta visión holística, tan utilizada por BPM, nos permitirá focalizarnos en aquellos procesos que requieran mejoras a nivel de sistema, en contraposición a optimizar sólo determinados departamentos o áreas aisladas. La identificación de estos procesos centrales es la clave para los activos de negocio que son fuente de ventajas competitivas y tienen un profundo impacto para alcanzar las estrategias y objetivos de negocio. Si no ponemos el foco en los procesos clave, corremos el peligro de usar luego las metodologías de mejora de procesos como Lean y Six Sigma sólo para la mejora de determinadas partes del proceso o trabajar en procesos irrelevantes para el negocio y aquí TOC hace de paraguas de las metodologías Lean y Six Sigma. TOC establece que siempre existe una restricción que marcará las salidas de la organización y que esta generalmente está relacionada con la organización funcional, gestionada en partes y no en su globalidad y a no ser que 331


veamos la empresa como una generadora de valor en su conjunto y nos centremos en eliminar las restricciones clave del sistema, el impacto de nuestro trabajo en mejora de procesos no será relevante para el conjunto de la organización. La metodología de TOC mirará primero cuales son las causas de los problemas y hará uso de la lógica de causa-efecto para entender los problemas, validarlos y corregirlos. TOC buscará estas raíces y seguirá un proceso para dar respuesta a las siguientes preguntas: ¿Qué cambiar?, ¿Hacia qué cambiar? y ¿Cómo causar el cambio? TOC requiere que primero entendamos el sistema, sus objetivos y medidas para después aplicar los 5 pasos: 1. 2. 3. 4. 5.

Identificar las restricciones Decidir como explotar las restricciones. Subordinar todo a estas restricciones. Si es necesario elevar las restricciones del sistema. Si se ha eliminado la restricción, ir al primer paso en busca de otra restricción y no dejar que la inercia sea la limitación

El concepto básico de TOC es a menudo descrito a través de la analogía de la cadena: “una cadena es tan fuerte como lo sea el eslabón más débil de la misma”. TOC se centra en el comportamiento del sistema en su conjunto y después en cómo las diferentes partes del sistema intervienen en el conjunto para alcanzar mejoras en todo el sistema y no sólo en determinadas partes del mismo, por lo que tendremos primero que entender toda la cadena y no sólo sus partes aisladas, identificar las barreras o puntos débiles de la cadena y aislar y fortalecer el rendimiento de ese punto débil para mejorar el rendimiento global. Las mejoras que no mejoren el rendimiento de este eslabón más débil, deberán se subordinadas a la restricción, pues las mejoras en estas sólo nos llevarán a realizar trabajo adicional sin relevancia para los objetivos de negocio. La perspectiva de TOC proporciona predictibilidad y estabilidad al centrarse en proteger y gestionar las restricciones de todo el sistema y centrar los esfuerzos de mejora en los procesos correctos. Una vez hemos seleccionado los procesos correctos sobre los que trabajar, podemos aplicar los esfuerzos de mejora para finalmente sostener las mejoras alcanzadas en el tiempo.

332


Lean: Una vez escogidos los procesos clave, podemos usar Lean para centrarnos en las mejoras del sistema, eliminar el desperdicio de los procesos seleccionados y mejorar su flujo. El objetivo de la metodología Lean es reducir el tiempo desde la orden de un cliente hasta el cobro (“time-to-cash”), eliminando todos los desperdicios (waste) que no produzcan valor. En Lean existen 7 tipos de desperdicios que aparecen en los sistemas: sobreproducción, esperas, transporte, inventario, movimientos innecesarios, sobre-procesados y defectos. Lean nos ayudará en las fases de Levantamiento de procesos y en la de mejora de procesos para entender exactamente cómo operan los procesos del As-Is, clasificar los procesos o actividades de estos de estos que no añadan valor, generen desperdicios, ineficiencias, cuellos de botella o restricciones para identificar donde fallan y asegurarnos de arreglar los procesos erróneos. Usamos la metodología Lean para entender e identificar estos desperdicios y ayudarnos en los esfuerzos de mejora. 1. Especificar el valor. La pregunta que nos deberemos hacer es: ¿entendemos verdaderamente el valor desde la perspectiva del cliente? El valor añadido (el esfuerzo que los clientes están dispuestos a pagar por estos avances), debe ser identificado a través del mapa de procesos de la cadena de valor. 2. Identificar los pasos en la cadena de valor. Hacemos el mapeo de la cadena de valor para detallar y analizar el flujo de materiales e información para producir un producto o servicio al cliente. De esta cadena de Valor, podremos identificar que acciones producirán valor y cuáles no. Identificar la cadena de valor expondrá muchas actividades que no aportan valor. Las que no produzcan valor serán aquellas que consuman tiempo, recursos o espacio y no añadan valor al producto y en consecuencia, tampoco al cliente. 3. Crear un flujo. Una vez entendamos los pasos para la creación de valor, el siguiente paso es crear un flujo continuo que reduzca el tiempo y los desperdicios.

333


4. El principio Pull. Una vez conseguidos los tres principios anteriores, podemos poner el sistema para producir lo que el cliente requiera, el “Pull System” en oposición al “Push” basado en predicciones. En este punto y paralelamente, podríamos considerar también la aplicación de las 5S´s de Lean (Sort, Simplify, Scrub,Standarize, Sustain) así como otras herramientas de Lean como puedan ser : -

-

Kaizen event: proyectos de mejora continua centrados en incrementar el valor de los procesos y reducir desperdicios. Mapa de la cadena de valor: representación gráfica de los pasos en el proceso para producir un producto o servicio. Lead Time Analysis: el tiempo total desde que una tarea, proceso o servicio comienza hasta que se completa. Gemba: ver dónde se realiza el trabajo. Revisar por ejemplo el As-Is de cómo se realiza actualmente el trabajo. 5 Why´s: método iterativo para preguntar por qué para obtener las causas raíces. Para ver dónde están los problemas, preguntando por qué existen los problemas. Es una de las mejores maneras de identificar los problemas y sus orígenes para después trabajar en su mejora. Spaguetti Diagram: para mostrar el transporte o movimiento de productos y servicios. SIPOC: una evaluación de Supplier/Input/Process/Output/Customer para obtener una visión centrada en el cliente del proceso. 6 S´s: Un ejercicio usado para crear y mantener un espacio de trabajo organizado: Sort, Set in order, Shine, Standardize, Sustain y Safety.

Six Sigma: Con los pasos anteriores, tendremos establecido un proceso mejorado sobre el que podremos predecir su comportamiento y resultados esperados y entraremos ahora en la fase de optimización del proceso para reducir las variaciones en el mismo y alcanzar los resultados con el menor desperdicio y re-trabajo. Entramos en los puntos 5 y 6 de Lean de perseguir la perfección e implementar con agilidad, refinando continuamente nuestra propuesta y cadena de valor en un proceso iterativo.

334


En este punto una vez establecida la configuración de nuestro proceso, necesitamos estandarizar las operaciones, procedimientos y mecanismos de control para lo que podremos usar la metodología de Six Sigma. Esta metodología inicialmente usada como sistema de medición y de reducción de defectos asociados a procesos manufactureros y de producción, ha evolucionado hasta convertirse en una metodología de management para la mejora continua y centrada en cómo las variaciones afectan a los resultados deseados por la organización y la satisfacción de clientes. El objetivo de Six Sigma es reducir los defectos, los tiempos de ciclo y aumentar la productividad y la satisfacción del cliente a través de la reducción de variaciones en los productos y los procesos y proporcionando a las organizaciones una ventaja competitiva. La reducción de defectos proporcionará mayor satisfacción de clientes, menores costes de calidad y aumento de los beneficios. El ciclo básico para la resolución de problemas y las variaciones en nuestros procesos utilizado por Six Sigma es DMAIC, el cual nos permitirá identificar y aislar las fuentes de desviación en los procesos para minimizarlos o eliminarlos sistemáticamente. Durante el ciclo DMAIC, podemos simular y comparar unos modelos de procesos con otros para determinar cuáles cumplen mejor con los objetivos de throughput, costes, tiempos y recursos que precisamos. Qué aporta BPM a TOC, Lean y Six Sigma: Como vemos, TOC, Lean y Six Sigma se centra en comprender y analizar las deficiencias en los procesos y en cómo mejorarlos mientras BPM se centra en la automatización, la gestión y el control de los procesos mejorados así cómo en la recolección de datos e información, proporcionando a los equipos de mejora de procesos de la rapidez y flexibilidad necesarias para poder alcanzar ventajas competitivas. Y producirá un matrimonio perfecto entre todas las metodologías. BPM ayuda además a los equipos de TOC, Lean y Six Sigma a actuar proactivamente y a trabajar constantemente sobre los procesos en la organización orientada a procesos y no en acciones de mejora de procesos aisladas, proporcionando el contexto para poder realizar las tareas asociadas al proceso, mantener a las personas informadas y proporcionando las herramientas para poder medir y analizar la operativa de los procesos en tiempo real. Una de las áreas de BPM en las que mayores beneficios encontrarán TOC, Lean y Six Sigma es en la de simulación Con las capacidades de simula335


ción de BPM, TOC, Lean y Six Sigma pueden modelar los procesos, evaluar y testear alternativas de procesos en aspectos como costes, tiempos de ciclo, cuellos de botella y restricciones que serán difíciles de ver sin recoger datos y simulando el sistema,. La simulación facilitará también el análisis de tareas que no aportan valor y desperdicios que podrán ser analizados durante la simulación para determinar la configuración del proceso que mejor cumpla con los requerimientos del negocio y minimizar los riesgos de una implementación a un coste mucho menor que realizando experimentos físicos. Las capacidades de automatización de procesos en BPM, proporcionarán tanto durante las simulaciones como en entornos de producción, la retroalimentación en tiempo real de datos, información y métricas de los procesos necesaria para las entradas de Lean y Six Sigma y que esta metodologías puedan continuar sus ciclos de mejora continua, acelerando la recogida y recepción de datos para validar los procesos, analizar los mismos e identificar áreas de oportunidades y necesidades de mejora en menos tiempo y con menos esfuerzo que sin BPM. Además la simulación, BPM proporcionará también los beneficios de disponer de un Cuadro de Mando para la monitorización en tiempo real de los procesos y sistemas de alertas para eventos específicos de los procesos, proporcionando la información correcta, en el momento correcto en un entorno gráfico y amigable para la monitorización y análisis de los procesos de forma que los expertos en mejora de procesos pueda aprovecharse de la rapidez y flexibilidad para redefinir o modificar los procesos. Otras ventajas para TOC, Lean y Six Sigma de la utilización de un BPM son:

336

-

Acceso a datos y métricas.

-

Reglas de negocio y entorno gráfico en el que podemos de forma fácil definir y modificar los procesos para simularlos y ejecutarlos, de forma que un experto en Six Sigma podrá diseñar e implementar un proceso y automatizarlos sin necesidad de conocimientos de programación aprovechándose de las ventajas que BPM ofrece.

-

Capacidades de BAM, Monitorización, control, estandarización.

-

Visibilidad del proceso,


-

Eficiencia en implementar futuros estados del proceso, gestionar y simular versiones de procesos, pudiendo construir nuevos procesos más rápidamente,

-

Automatización de workflows para gestionar interacciones humanas y de sistemas,

-

Edición de reglas de negocio que reemplacen a las decisiones manuales, etc.

Gestión del proyecto: La principal causa de fracaso de los proyectos (de cualquier tipo) se encuentra principalmente en aspectos como: -

Mala especificación de requerimientos o una mala gestión de las expectativas de los usuarios o clientes, para traducir estas expectativas en necesidades y requerimientos claros, precisos, medibles, reales y alcanzables en el tiempo.

-

La no implicación de los usuarios, que ya hemos visto como lograrla, principalmente a través de su implicación en las fases más tempranas del proyecto de forma que participen también en el diseño del mismo, tanto para aportar conocimiento y experiencia como para ganarnos su complicidad en el resto del proyecto al haber sido participes del diseño y configuración del mismo.

-

Falta de recursos técnicos y humanos para poder llevar el proyecto a cabo.

-

Falta de planificación.

-

Falta de control de calidad, de control de los cambio en el proyecto, etc.

Pero uno de los aspectos que se apunta como primordial para asegurar el éxito del proyecto es el la utilización de una metodología en la gestión de proyectos y la involucración de un Director de Proyecto o Project Manager, en inglés que lidere el proyecto, lo coordine, se responsabilice del mismo, 337


sirva de escudo protector del mismo y lo proteja de todo aquello que pueda amenazar los objetivos del proyecto, sea intendente para garantizar la disponibilidad de recursos, agente de seguros, que se ocupa de la gestión de riesgos del proyecto, perito que mida y evalúe el trabajo realizado, inspector del compromiso con los hitos y entregables del proyecto, entrenador que se ocupa del desarrollo y capacitación del equipo, concentrador de toda la información, documentación y comunicaciones del proyecto y que junto a sus habilidades personales de liderazgo, negociación, empatía y proactividad consiga llevar el proyecto a buen puerto. ¡Vamos, un superman!, que si bien no tiene por que ser un experto en BPM o en la materia o sector del que trate el proyecto si debe conocer estos aspectos pero actuará sobre todo como Jefe de Proyecto y en consecuencia sus habilidades y conocimientos en la dirección de proyectos serán las más importantes. La Gestión de Proyectos (Project Management) será un requisito esencial para el éxito de cualquier proyecto y en consecuencia también para los proyectos que emprendamos en BPM y la mejora de procesos, pues será la correcta gestión del proyecto la que sustente el proyecto en sí, que debe ser gobernado, dirigido y controlado por una correcta metodología de gestión de proyectos para asegurar que el proyecto de BPM progrese adecuadamente y alcance sus objetivos. Las metodologías de gestión de proyectos asumen que existe un punto inicial, una serie de pasos y un resultado seguido de la evaluación del mismo. Estos pasos, en concreto, serán la gestión unificada de personas, procesos y tecnología para convertir los inputs (misión, personas y recursos) en outputs que aporten valor (cumplir las metas y objetivos del proyecto) y serán las principales áreas que deberemos gestionar en el proyecto. Como venimos presumiendo desde el inicio de este libro, los proyectos de BPM implican cambios en las organizaciones y las personas que deben ser gestionados correctamente, no son sólo proyectos que se basen en la implantación de una herramienta software, sino que esta herramienta sumada a cómo diseñemos o rediseñemos los procesos de la organización para formar la arquitectura de procesos, conformaran un todo alineado con la estrategia de la empresa para reducir el gap entre personas, procesos y tecnología. Existen distintas metodologías de implementación perfectamente descritas por organizaciones como BPTrends para la gestión de proyectos en BPM. Nosotros no las describiremos todas, pero si realizaremos una breve descripción de la gestión de un proyecto BPM desde la perspectiva del 338


PMBOK (Project Management Book of Knowledge) del PMI (Project Management Institute), considerando los aspectos clave que debemos gestionar en nuestros proyectos de BPM. Estos puntos clave de cualquier proyecto serán: -

¿qué vamos a hacer, qué producto o servicio vamos a producir o entregar?, conocer el Alcance del proyecto.

-

¿qué estándares deberemos cumplir? Calidad.

-

¿Qué tiempo vamos a emplear en cada tarea y en la totalidad del proyecto? Duración prevista.

-

¿Qué costes vamos a tener? Costo.

-

¿Qué seguridad tenemos de poder obtener el producto o servicio con el Alcance los Tiempos, y la Calidad requerida por el proyecto? Riesgos.

-

¿Qué necesitamos para poder llevar el proyecto adelante? Recursos Humanos. Adquisiciones

-

¿Cómo combinamos todo lo anterior? Gestión de la información y las comunicaciones.

Basándonos en este estándar del PMI para la gestión de proyectos y de forma resumida, pues no veremos en este apartado todas las áreas de conocimiento y grupos de procesos que deben ser considerados para la gestión de proyectos, tendremos en cuenta los siguientes aspectos importantes a la hora de realizar la implementación: -

Seguir el ciclo de vida de gestión de los proyectos, procurando ser metodológicos en su cumplimiento:

339


-

-

340

Acta de Constitución del proyecto: correspondiente al grupo de procesos de iniciación, ningún proyecto debería comenzar sin una aprobación formal por parte del patrocinador o cliente que autorizo el proyecto y el poder comenzar a dedicar recursos, tiempo y dinero al proyecto. Esta fase de inicio al igual que la de cierre (sobre todo en cuanto a recoger lecciones aprendidas durante el proyecto), son fases que se suelen obviar o saltar en todos los proyectos. Gestión de cambios o atención al proceso denominado en el PMBOK como “Control Integrado de Cambios”. Sabemos que el cambio es algo intrínseco a todo proyecto y los de BPM serán especialmente susceptibles de cambio, tanto por el gran número de grupos y personas involucradas en el proyecto como por los distintos ciclos y etapas por los que pasará el proyecto, lo que nos obligará a ser metodológicos y estrictos en cuanto al tratamiento, control y gestión de los cambios que puedan surgir durante el desarrollo del proyecto y nunca integrar ninguna solicitud de cambio sin analizar y evaluar el impacto que este cambio pueda tener en el proyecto y en áreas como el Alcance, el Tiempo, el Coste del proyecto y la Calidad.


-

-

-

Gestionar los Riesgos: como Jefes de Proyecto nos mantendremos siempre alerta ante los riesgos que puedan amenazar al proyecto, tanto los que identifiquemos en las fases más tempranas del mismo como en fases posteriores y aquellos que no hayamos predicho, por lo que esta identificación, clasificación, evaluación y análisis de impacto de los riesgos la realizaremos a lo largo de todo el ciclo de vida del proyecto. Una buena práctica para la gestión de riesgos es el uso de la matriz RBS (Risk Breakdown Structure) en la que representaremos la probabilidad (alta-baja) y el impacto (alto-bajo) que los distintos riesgos puedan tener sobre el proyecto y en función de esta estableceremos planes de contingencia y planes de respuesta a riesgos. En esta gestión de riesgos, recordar que los riegos que los riesgos pueden ser positivos o negativos por lo que muestra misión será eliminar o mitigar el efecto de los riesgos negativos o amenazas y explotar los positivos u oportunidades, que serán aquellas que puedan afectar positivamente al proyecto. Plan de comunicación: importantísimo para el éxito de la implementación. Será la función principal del Director de Proyecto pues en esta tarea pasará la mayor parte del tiempo dedicado a la gestión del proyecto. Plan de formación: que capacidades y habilidades serán necesarias para el personal involucrado en el proceso y en el proyecto.

En todo este apartado de gestión de gestión del proyecto, debemos distinguir entre el ciclo de vida del proyecto y el ciclo de vida del producto. El 341


ciclo de vida del proyecto es la ejecución de los trabajos necesarios para obtener los entregables del mismo, mientras que el ciclo de vida del producto, está referido a los procesos y se prolonga desde su concepción (la definición de los procesos) hasta la retirada del mismo (cuando el proceso es retirado, rediseñado o sustituido por otro proceso). El ciclo de vida del producto puede contener muchos proyectos. Los proyectos de BPM normalmente son fases de un proyecto más grande y rara vez alcanzaremos los objetivos planteados en un solo proyecto. Necesitaremos mejora continua y la implementación de varios proyectos para alcanzar los resultados esperados mediante la medida continua de indicadores y la depuración y optimización de estrategias y procesos. En el recorrido descrito en este capítulo hemos indicado aspectos de la gestión del proyecto relevantes en las distintas etapas que hemos visto como la necesidad de la realización y aprobación por parte del CEO del Acta de Constitución del Proyecto, la elaboración del Plan de Proyecto, etc. Sin embargo hay áreas importantes de la gestión de proyectos no descritas y que debemos considerar para implementar el proyecto con éxito y que describimos a continuación. Jefe de Proyecto: Hemos hablado mucho del jefe del proyecto en todo el libro y le hemos atribuido demasiadas tareas, habilidades y responsabilidades, que todas juntas nos vienen a indicar cual deberá ser su papel principal en el proyecto. La importancia del responsable del proceso y del gestor del proyecto, que pueden no ser la misma persona, y debería ser así, asignando una persona como gestora del proyecto y responsable última del éxito en su implementación y que desaparecerá después de la misma, al ser el proyecto de implementación un proyecto con una fecha de inicio y final y no como el responsable del proceso que deberá permanecer mientras continúen los procesos en funcionamiento. El jefe de proyecto deberá mantener todas las áreas y aspectos del proyecto unidos, sean estas partes tecnológicas, de procesos, de negocio o relacionadas con aspectos externos de la organización. Es el “super héroe” del que hablábamos antes, que sin realizar un trabajo real relacionado directamente con el proyecto, se encarga de coordinar todas sus partes y de asegurar el éxito del proyecto resolviendo los problemas y conflictos que 342


surjan durante el mismo, tomar las decisiones para que el proyecto avance en la dirección adecuada e implicar a todos los participantes para que todos sepan qué tienen que hacer, cuando y como para que todas las acciones tengan sentido dentro del proyecto, se ejecuten en la secuencia adecuada y de esta forma obtener el mayor rendimiento del proyecto y alcanzar los resultados. El entorno en el que se moverá el jefe de proyecto será el de una lista de tareas (To-Do´s) relacionadas con el alcance del proyecto, los tiempos y cronogramas, los costes, los riesgos, la calidad del proyecto y el manejo de la información y las comunicaciones asociadas al proyecto, realizar informes de seguimiento, verificaciones y controles del progreso del proyecto.

El Plan de Dirección del Proyecto: El recorrido que vamos a realizar debe comenzar, siguiendo la metodología del PMI (Project Management Institute), por la realización del Acta de Constitución del Proyecto, que autorice formalmente el mismo y el inicio de los trabajos, identifique a los stakeholders interesados en el proyecto y los requisitos que debe satisfacer el proyecto (no el proceso) para satisfacer a estos stakeholders. La aprobación del Acta de Constitución del proyecto debe ser realizada por el promotor o sponsor, que es quien solicita la ejecución del proyecto de diseño o mejora de los procesos existentes, e indica ya en esta fase los procesos con los que cuenta la organización y las mejoras que pretende sobre estos procesos. En esta fase el director de proyecto, responsable de cumplir con los objetivos del proyecto en tiempo, calidad y coste, debería estar ya seleccionado y asignado al proyecto. Este director de proyecto será además el interlocutor entre el equipo del proyecto y el sponsor o patrocinador del mismo. El papel del director del proyecto será el de un integrador y comunicador, encargado de coordinar todas las actividades del proyecto de forma cohesionada, de forma que se consigan los objetivos para los que fue iniciado el proyecto. El Director de proyecto deberá integrar adecuadamente los elementos clave (alcance, tiempo, coste, calidad y riesgo) y disponer de conocimientos sobe gestión de proyectos y habilidades para manejar los recursos, la incertidumbre y los riesgos intrínsecos a todo proyecto, gestionar los conflictos, motivar a los equipos de trabajo, tomar decisiones, cum343


plir los requerimientos del proyecto y alcanzar los objetivos del proyecto así como mantener un código ético de conducta en sus decisiones. Al comienzo del proyecto es fundamental asegurarnos de que la estrategia, la visión, las metas y objetivos del proyecto son comprendidas por todos los miembros del equipo y asegurarnos su compromiso y en especial el del CEO de la organización. Un aspecto importante a analizar por el director del proyecto es la estructura organizativa sobre la que vamos a implementar el proyecto. Los proyectos de BPM son grandes generadores de cambio, pues implican el paso de un proceso a otro proceso nuevo, con lo que nos encontraremos con personas con mayor o menor resistencia al cambio y configuraciones organizacionales más o menos diseñadas para aceptar estos cambios. En capítulos anteriores hemos visto la organización orientada a procesos. Este tipo de organización facilitará mucho este proceso de cambio por la simbiosis entre los procesos y la estructura de la organización, pero normalmente nos encontraremos organizaciones más funcionales y departamentales donde como directores de proyecto, tendremos serias dificultades de comunicación transversal y de disposición de recursos para llevar adelante el proyecto que en organizaciones más orientadas a proyectos, sobre las que podremos desarrollar el proyecto más fácilmente. En esta fase de iniciación del proyecto seleccionaremos también al equipo de diseño del proyecto, el cual puede estar formado por analistas de procesos, personal de TI y de negocio y directores de departamento o unidades de negocio involucrados en los procesos sobre los que vamos a trabajar. Una vez disponemos de la autorización formal para autorizar el proyecto y en consecuencia, el director de proyecto tiene autoridad para asignar recursos al proyecto, nos reuniremos con el equipo de proyecto para planificar el proyecto: conocer el alcance del mismo, definir claramente el problema que queremos resolver, saber por qué queremos realizar este cambio, describir la situación actual, los objetivos que se pretenden conseguir con el proyecto y como estos están alineados con la estrategia de la empresa, las mediciones de las que disponemos del proyecto actualmente y que mediciones se esperan alcanzar, o sea, la calidad que se espera del proyecto. Definiremos también cual será el alcance del proyecto, los límites entre los que nos podemos mover, qué recursos serán necesarios en la organización para ejecutar el proyecto y si estos serán internos y/o externos. Planifi344


caremos el tiempo en el que el proyecto debe estar finalizado y su correspondiente cronograma, el presupuesto del que disponemos, si podremos hacer todo el trabajo internamente o necesitaremos subcontratar determinadas actividades, identificar y valorar todos los riesgos y oportunidades que podemos tener y los entregables que deberemos obtener al finalizar el proyecto, como se gestionarán los cambios a lo largo del proyecto, etc. Todas estas preguntas conformarán el Plan de Dirección del Proyecto, el cual nos guiará a lo largo de la fase de implementación y definirá la manera en que se ejecutará el proyecto, se monitoriza, se controla y se cerrará el mismo. Este Plan de Proyecto es un documento vivo a lo largo de la vida del proyecto, el cual puede ser actualizado a través del control integrado de cambios al Plan de Dirección de Proyecto e incluye entre otros: -

-

Las líneas base del proyecto: o Línea base del cronograma. o Línea base de costos. o Línea base del alcance. El plan de gestión del alcance. El plan de gestión de requisitos. El plan de gestión del cronograma. El plan de gestión de costos. El plan de gestión de la calidad. El plan de gestión de recursos humanos. El plan de gestión de las comunicaciones. El plan de gestión de riesgos. El plan de gestión de las adquisiciones.

Para su gestión debemos tener en cuanta un aspecto fundamental de todo proyecto como es la “Triple Restricción” en el tiempo, el coste y el alcance, de tal forma que la modificación de una de ellas tiene un claro impacto en las otras dos y no podremos por ejemplo aumentar la calidad del proyecto sin aumentar su coste, o reducir el tiempo de entrega del mismo sin por ejemplo reducir su alcance.

345


Al

ca

nc

e

o mp Tie CALIDAD

Coste

Una buena práctica para el desarrollo de este Plan de Dirección del Proyecto es la realización de la EDT (Estructura de Desglose del Trabajo), para subdividir los entregables del proyecto en paquetes de trabajo más manejables que puedan ser asignados a personas o equipos de trabajo. La EDT es una herramienta de descomposición jerárquica orientada a entregables que incluye todo el trabajo necesario para realizar el producto e incluye el propio trabajo de gestión del proyecto. A partir de la EDT nos será más fácil calcular y realizar estimaciones de tiempo y costes para el proyecto. Otro aspecto importante a tener en cuenta en la gestión de proyectos son las restricciones y supuestos del proyecto. Las restricciones pueden limitar las opciones del equipo en cuanto a presupuesto, hitos del cronograma o legislaciones gubernamentales. Así mismo, los supuestos que puedan acontecer deben ser identificados y documentados, para analizar el impacto que pueden causar en el proyecto en el caso de que sean ciertos. Entre los supuestos que suelen aparecer se incluyen: disponibilidad de recursos, software, equipos o personas para la realización de determinadas tareas o cambios en los precios de estos recursos y que en caso de no poder contar con ellos, pueden causar un impacto negativo en el proyecto. Sobre este Plan de Dirección de Proyecto deberemos alcanzar el mayor consenso posible dentro de la organización para asegurarnos el compromiso de todos los miembros, explicarles este plan y hacer todas las correcciones necesarias sobre el mismo, pues en esta fase es donde menos costosos serán los cambios.

346


Alcance del proyecto: El modelado de procesos también nos servirá para comunicar el Alcance del proyecto y delimitar donde comienza y acaba el mismo o partes del mismo y saber de esta forma, qué está incluido y qué no lo está dentro del proceso sobre el que estemos trabajando, que partes son subcontratadas y cuales realizadas por la propia organización, etc. Tener en cuenta que un proyecto sólo se completa cuando la razón por la cual fue iniciado el proyecto se alcanza o supera. En general, para la gestión del proyecto necesitaremos conocer el esfuerzo que llevará realizar el As-Is y determinar el To-Be asociado con los objetivos del proyecto, qué vamos a necesitar para conseguir este To-Be y cuanto costará en términos de coste, tiempo y recursos pasar del As-Is al To-Be así como su implementación y puesta en marcha y los riesgos que asumimos con esta transformación.

Gestión de las Comunicaciones: Durante el proyecto necesitaremos un buen plan de gestión de las comunicaciones, pues son proyectos en los que tendremos gran número de stakeholders y por las características particulares de los proyectos BPM, deberemos gestionar muy bien la gestión del cambio y de las personas involucradas en el mismo para el éxito del proyecto. En este sentido, deberemos explicar muy bien el proyecto y, como vimos en la fase de levantamiento de procesos, involucrar a las personas desde el primer momento en el diseño de procesos, haciéndolas partícipes del mismo y asegurándonos su complicidad durante las fase de implementación y posterior puesta en marcha del proyecto incluyendo su gestión en el día a día. La comunicación será fundamental. Como vimos en el Capítulo dedicado al modelado de procesos, la principal utilidad del modelado es la comunicación con nuestro equipo, el resto de miembros de la organización, nuestros clientes y nuestros partners. Los modelos se crean principalmente para comunicar, y la complejidad creciente de los negocios globalizados y altamente informatizados hacen del modelado una herramienta indispensable para representar que y como lo hacemos y cómo podemos mejorar y transformar nuestras organizaciones, por lo que el modelado de procesos, los As-Is, Could-Be y To-Be de los procesos mejorados, serán todos ellos

347


herramientas fundamentales en nuestras actividades de comunicación antes, durante y después de la realización del proyecto. En la comunicación usaremos también el Business Motivation Model para comunicar la estrategia al resto de la organización así como el modelado organizacional representando la estructura de la organización, quien hará las tareas, a quien reportará, etc. de forma que mostremos a las personas involucradas en el proceso los cambios que repercutirán en su día a día. Todo este material utilizado para gestionar las comunicaciones del proyecto nos servirá no sólo para comunicar a empleados sino también para persuadir de la necesidad y ventajas del proyecto a los patrocinadores del mismo. La comunicación regirá toda la vida del proyecto desde su la concepción inicial y nos servirá también para la gestión del conocimiento dentro de la organización, documentando toda la información relativa al proyecto de quien y como se realizarán los trabajos, cómo interactúan las personas dentro del mismo, las habilidades y conocimientos necesarios para realizar los trabajos y los distintos procesos. No vamos a extendernos mucho más en este importante aspecto de la gestión de proyectos pues el lector dispone de abundante material en internet y en otras fuentes tanto de la metodología PMI (Project Management Institute) como CMMI, que también disponen de abundante información sobre la gestión de proyectos.

Factores críticos de éxito de un proyecto BPM. Como resumen de este capítulo dedicado a la implementación de un proyecto de BPM, recurriré a una metáfora para la implementación de BPM descrita por John Nelis en su libro “Business Process Management”. Esta metáfora representa el esfuerzo conjunto de un proyecto de BPM mediante la imagen de un equipo de remo, comandado por un director de proyecto o timonel.

348

Capítulo 7. Implementación de BPM Resultado

Personas Recursos Organización

Procesos

Tecnologías de la Información. (TI)

Información

Dirección de Proyecto / Timonel.

Objetivo

Según Nelis, los factores críticos de implementación de un proyecto de BPM son, realizando una metáfora con esta embarcación son: -

-

-

-

-

Velocidad: es crucial. El objetivo general es ganar valor y se gana si y solo si, se es el primero y sé es el primero siendo más rápido. Ya no nos valen aquí esas eternas e inacabables implementaciones de ERP´s tan traumáticas para tantas empresas. Eficiencia: asegurando que toda la energía y entusiasmo disponible sea usada óptimamente para alcanzar los resultados esperados. Extraer lo mejor del equipo y las personas de la organización. Asegurando que todos contribuyan suficientemente. Equilibrio: para evitar que el barco se escore hacia los lados, equilibrando la fuerza, el peso y la experiencia de todos los participantes. Cohesión: entre todos los miembros del equipo para asegurar que todos remen al mismo ritmo y técnica, que es lo que da la velocidad. Procesos: son lo primero y los que dictan la velocidad de los demás remeros. En un proyecto BPM, los procesos de negocio deben liderar y la tecnología y las personas seguirles. Management: Project manager o Jefe de Proyecto. Hace mantener el barco en la línea correcta hacia la meta de forma que este no se vaya mucho hacia las personas y la tecnología o hacia las personas y los procesos.

349


Además de esta metáfora de Nelis para la implementación de BPM, podemos recomendar como buenas prácticas en los proyectos de BPM las siguientes: -

-

-

-

-

350

Formar al equipo: BPM es una nueva disciplina que requiere de habilidades y formación que pueden ser difíciles de conseguir, sobre todo a la hora de interiorizar la nueva forma de pensamiento, combinando sus conocimientos de negocio y TI con las herramientas de BPM disponibles en el mercado y la capacitación del personal en las mismas. Sensibilizar, informar y formar debidamente a las personas que participarán en el proceso nos asegurará en gran medida el éxito del mismo. Involucrar al equipo directivo: a las personas responsables de resolver los problemas que deben convertirse en evangelistas de BPM. Gestionar las expectativas: los proyectos de BPM involucran a muchos stakeholders y cada uno tiene sus propias expectativas. Comenzar con pequeños pasos, completar los proyectos a tiempo, evitar inflar las expectativas y demostrar las ventajas del proyecto. Seguir una metodología: Si existe una como Six Sigma, usarla para facilitar la introducción de BPM. Si no existe establecer una. Usar una metodología de gestión de proyectos. Disponer del compromiso de la Alta Dirección para la ejecución del proyecto, así como de la asignación de recursos y tiempo para el proyecto. Hacer una buena selección de la herramienta BPMS que vayamos a utilizar. No implementar BPM como un sistema de gestión paralelo, es mejor escoger un proceso y trabajar sobre él para implementarlo. Acometer proyectos pequeños al principio, de forma que podamos alcanzar resultados tangibles en áreas concretas, reducir costes y obtener resultados a corto plazo. No retrasar demasiado tiempo la puesta en marcha por querer considerar todos los detalles. Planear y gestionar el cambio: lo que mata a los desarrolladores de software son los requisitos que cambian en los proyectos. Esto siempre va a ocurrir, acepta el cambio, BPM se monta para poder cambiar fácilmente. BPM es un cambio en sí mismo, un cambio de filosofía y en la manera de pensar que se crea para poder adaptarse y gestionar el cambio.


351


Capítulo 8. Tecnología BPM. BPMS

Los sistemas BPMS (Business Process Management Systems) suponen una auténtica revolución en la industria del software al proveer bajo una misma plataforma, un conjunto de servicios y herramientas que facilitan el modelado, despliegue, gestión y seguimiento de los procesos de negocio siguiendo el ciclo de vida de estos, con la capacidad de diseñar estos procesos, simularlos, ejecutarlos y monitorizarlos, al tiempo que integramos estos procesos con personas y con los sistemas y aplicaciones informáticas internas y externas de nuestra empresa para controlar su flujo de trabajo. Los BPMS incluyen módulos funcionales, capacidades técnicas e infraestructuras de apoyo integradas en un único entorno y que convierten a los BPMS en la herramienta tecnológica que nos permitirá implementar BPM en nuestra organización, de forma ágil y con la suficiente flexibilidad para poder modificar los procesos según cambian las necesidades de negocio. Esta unificación en un mismo entorno, permite por ejemplo convertir un modelo en BPMN en ejecutable y poder modificar la lógica de negocio de nuestros procesos en ejecución y sus aplicaciones, sin necesidad de rehacer el código fuente. Workflow: Como comentamos, los BPMS contemplan soporte para interacción humana, e integración de aplicaciones, y esta integración con sistemas es 352


una de las principales diferencias con los sistemas WorkFlow existentes hasta ahora. Los sistemas de workflow tradicionales, permiten el modelado y ejecución de procesos, pero no la definición de criterios que puedan ser usados para determinar si estamos ejecutando correctamente los procesos. Los BPMS pueden ser vistos como una extensión de los workflow, pero de una forma mucho más amplia, pues las soluciones de workflow representan sólo uno de los diez módulos interrelacionados con los que puede contar un BPMS. En la práctica, un flujo BPM (o modelo de proceso BPM) visualmente es muy parecido a un WorkFlow, pero la diferencia está en que en que en los BPMS ciertas actividades son realizadas por personas, y otras son actividades automatizadas y ambas aparecen en el flujo.

Las soluciones tradicionales del tipo WorkFlow, se limitaban a definir el flujo de actividades humanas, o de documentos, y con esto obtener el seguimiento de los procesos, pero en estos casos, si un participante del proceso requería como parte de sus actividades ingresar datos de una aplicación externa, debía salir del entorno del WorkFlow, ir a la aplicación, para después volver al WorkFlow y registrar el cambio. En BPM todo está integrado en el mismo flujo, lo que es más natural para un participante, pues este completa su actividad dentro del flujo BPM, y por detrás se actualizan los sistemas necesarios para la ejecución del proceso.

353


Menos programación: Otro aspecto que suele llamar la atención, en especial para enfadar a los programadores, es el que afirma que no es necesario escribir una sola línea de código, “cualquiera puede realizar las aplicaciones software”. En BPM los procesos no se programan, sino que se modelan gráficamente, permitiendo que sea más sencilla su modificación sin tener que programar o recurrir a código intermedio, pues modificando el modelo, esta modificación se refleja en la aplicación web resultante. Otras veces, en lugar del modelado podremos hacer uso de BPEL, con el cual, como hemos visto al inicio de este capítulo, podremos también modelar procesos de negocio sin necesidad de programar y que gracias a BPEL4People, como una capa superior de BPEL, podremos incluir en el modelado la interacción humana resultando en que los procesos modelados en BPEL al final quedarán expuestos como servicios web (web services). Si bien esto es cierto para algunos tipos de implementaciones y procesos, no es así para todo ellos, e independientemente, siempre necesitaremos programadores para las integraciones que realicemos con aplicativos y web services externos. Además, nuestra recomendación es la de contar siempre con el equipo de sistemas, por la visión ya comentada que estos tienen sobre el conjunto de la organización. Al igual que con la notación BPMN, un BPMS puede ser usado por prácticamente cualquier perfil dentro de la organización, tanto personal de TI como de negocio y aquí radica otra de sus ventajas. La gente de negocio y los analistas crean conjuntamente los modelos y definen los datos a ser usados para gestionar y monitorizar un proceso, reduciendo la brecha entre los requerimientos de negocio y como estos son implementados por la tecnología, al reducir y prácticamente eliminar las necesidades de programación de código fuente, tanto en la concepción inicial del sistema, como en posteriores fases de mejora, depuración y mantenimiento, involucrando a la gente de negocio en estas tareas hasta ahora restringidas a analistas y programadores expertos en desarrollo software y pudiendo generar código ejecutable directamente desde los requerimientos de negocio modelados en un entorno gráfico. Los BPMS pueden ser definidos como herramientas de desarrollo de alto nivel orientadas al desarrollo rápido de aplicaciones, alineadas con los procesos de negocio de la empresa, sin embargo la orientación de los BPMS es que el propio proceso sea la aplicación. Los BPMS, además de cómo entor354


no de desarrollo e integración para aplicaciones orientadas a procesos de negocio, se están convirtiendo (mediante la estandarización de procesos), en aplicaciones empresariales “per se” que ofrecen innumerables ventajas frente a los entornos tradicionales de desarrollo en cuanto a tiempos de implementación, alineación con objetivos empresariales, flexibilidad, mayor capacidad de diseño funcional de las aplicaciones, modificación de las aplicaciones en tiempo real y donde no es necesario el conocimiento de un lenguaje de programación sino de un lenguaje de notación como BPMN. En este aspecto del desarrollo software, no debemos confundirnos y creer que los BPMS son herramientas de desarrollo software, BPM no trata de desarrollo de aplicaciones y su interés es la gestión de procesos de negocio y para poder gestionar estos, BPM debe apoyarse y alinearse con la tecnología, pero no es sólo tecnología y en consecuencia no debemos perder el foco y saber que debemos centrarnos también en la parte de negocio y en cómo ésta hará uso de la tecnología. BPM ayudará a la toma de los requerimientos tecnológicos y sobre todo nos ayudará tras la implementación tecnológica a medir y evaluar el uso de la misma en nuestros procesos. El mayor reto que afrontaremos con nuestros proyectos de BPM será equilibrar los tres pilares sobre los que se sustentará el proyecto: Personas, Tecnología y Procesos y suele ocurrir que normalmente uno de estos siempre sobresale y suele ser el tecnológico. Los BPMS son en este sentido una nueva categoría de software, una tecnología implícita a BPM sobre la que se sustenta la gestión de procesos, que permiten a las organizaciones modelar, implementar y gestionar sus procesos de negocio, que cumplen con todos los requerimientos de escalabilidad, seguridad, flexibilidad, agilidad, tolerancia a fallos y calidad de servicio, pero no deben ser vistos como entornos de desarrollo software. Así mismo, los BPMS no vienen a reemplazar los sistemas de información existentes en las empresas sino que coordinarán estos sistemas para la ejecución y control de los procesos empresariales. En BPM, el modelo del proceso se convierte en el núcleo de la implementación del proceso como solución tecnológica. El modelo del proceso de negocio (su diseño), que realiza el área de negocios de una empresa, es “en si” lo que se ejecuta sobre el “servidor de procesos” (el motor de BPM). Dicho en otras palabras: la “lógica de negocio” principal que antes bajo la tecnología tradicional se debía programar, y colocar sobre un “servidor de aplicaciones” (tradicional), ahora se reemplaza por un modelo que se sube al “servidor de procesos” con mucho menos intervención del área de TI (menos programación). 355


En la práctica, una buena solución de BPM debería poder ejecutar un proceso modelado por el área de negocio, sin la necesidad de que el departamento de TI tenga que programar una sola línea de código, y obtener como solución algo equivalente a un WorkFlow Tradicional (sin integración de sistemas). Luego el área de TI debería tomar este “workflow”, e implementarle los formularios de entrada (de interacción con usuarios), y los “servicios” (las actividades automatizadas e integraciones con otros sistemas) para completarlo en un flujo BPM. Como espero que haya quedado claro a lo largo de los capítulos anteriores, la adquisición de una plataforma BPMS no implica el implementar un proyecto BPM y sin una correcta gestión del cambio, metodología de gestión de proyectos, gestión de personas, liderazgo y alineamiento estratégico de nuestros procesos eficientes y optimizados, pocas son las ventajas que extraeremos de la implementación de la herramienta tecnológica. En este punto, vuelvo a que es y que no es BPM y repasando todo lo visto con anterioridad, debemos concluir que BPM no es una teoría de gestión, no es una herramienta de modelado de procesos, no es una metodología de gestión de personas, no es un software, no es una metodología para la mejora de procesos y sin embargo, es todas ellas en conjunto, vistas desde una perspectiva holística. Bajo los BPMS se producirá la convergencia de las teorías de gestión empresarial y de gestión de procesos con distintas tecnologías software en una única plataforma.

Smith y Fingar comparaban los BPMS con los sistemas gestores de bases de datos (SGBD). Al igual que estos gestionan los datos en bases de datos externas a las aplicaciones para poder modificar estas sin necesidad de modificar el modelo de datos y como esto significó un enorme salto en el desarrollo de las aplicaciones. Un salto de magnitud similar se ha producido con la separación de los procesos de negocio de las aplicaciones, para que 356


cualquier cambio en la lógica de los procesos no suponga modificar las aplicaciones. El uso de los BPMS resultará imprescindible para llevar a cabo nuestros proyectos de BPM, pero además de para la gestión y control de procesos y la integración con los sistemas existentes en la empresa, con los BPMS obtendremos un mayor control sobre los sistemas informáticos de nuestra empresa bajo una visión unificada orientada por los procesos, aumentando el valor de los sistemas y recursos en la organización, reduciendo los costes operativos, la optimización de los costes de TI, mejoras en la gestión de la calidad, producción, servicio a clientes, gestión de compras, tiempos de procesos, flexibilidad en la adaptación al cambio y requerimientos de negocio y reducción de errores debidos a procesamiento manual de datos y operaciones. Los BPMS resultan en este sentido en una auténtica revolución que nos lleva de una orientación a datos a una orientación a procesos y que nos permitirá arquitecturas e infraestructuras más ágiles y adaptables a los cambios en los ecosistemas empresariales. En este capítulo analizaremos primero los distintos módulos que conforman las plataformas BPMS para en el siguiente apartado ver las arquitecturas orientadas a servicios: SOA (Service Oriented Architecture), como la arquitectura tecnológica que nos permitirá racionalizar y agilizar este cambio.

Módulos principales de un BPMS. Hay bastantes opiniones y no existe un consenso sobre lo que debe o no debe incluir un BPMS y cada vendedor (Oracle, Microsoft, IBM, SAP, etc.) ofrece sus particularidades y requisitos, por lo que en este libro describiremos las funcionalidades básicas que consideramos deben contener para poder realzar el ciclo de vida de los procesos de negocio, considerando la capacidad de realizar este ciclo como el mínimo exigible a cualquier plataforma BPMS, pues en el seguimiento de este ciclo radicará toda la potencia de los BPMS, al poder analizar, modelar los procesos, efectuar simulaciones de los mismos, integrar aplicaciones, ejecutar los procesos, medir y monitorizar dichas ejecuciones y modificar los procesos ejecutados nuevamente a través del modelado para implementar mejoras o modificaciones en los mismos. En el capítulo anterior sobre la implementación de BPM hemos dado bastantes detalles operativos de cómo será un proyecto de este tipo, y el 357


lector seguramente se habrá hecho una idea de cómo debería ser un BPMS, siguiendo los distintos pasos descritos en la implementación, por lo que en este apartado, describiré los BPMS y los módulos que lo conforman ciñéndome a la herramienta software y no a los detalles de su implementación. Cada módulo de un BPMS tiene una funcionalidad y todas las etapas son importantes para el desarrollo y despliegue de un proceso, por lo que una de las cosas que debemos exigir a un BPMS como recomendación es que cuente con todas las etapas o módulos necesarios integrados en su suite. Esto no quiere decir que no podamos realizar por ejemplo el modelado en una herramienta específica de modelado y luego trasladarlo a otra suite para transformar el modelo en código ejecutable o gestionar el proceso, sin embargo, nuestra recomendación es la de procurar la integración de estos módulos y funcionalidades en un mismo producto. Aquí debemos aplicar un pensamiento holístico similar al usado en la estrategia de BPM, pero está holística la aplicamos ahora para integrar todos los módulos que componen el BPMS pues es en esta integración donde residirá la verdadera potencia del BPMS y del proyecto BPM en definitiva. Al final modelamos procesos para luego simularlos, implementarlos, medirlos y controlarlos y ninguna de estas actividades por separado tienen la potencia de las mismas cuando las pensamos, planeamos y ejecutamos de forma aislada, pues el ciclo de vida de BPM está en continuo movimiento de una fase a otra: modelando, automatizando, administrando y mejorando las actividades y procesos de negocio. Con esta recomendación nos referimos a la capacidad que debe tener el BPMS de gestionar el ciclo de vida de los procesos y mantener el contexto de trabajo entre las distintas etapas, pero no implica que debamos adoptar un paquete cerrado al estilo ERP sobre el cual no podamos salirnos para aprovechar las posibilidades de las mejores herramientas especializadas en la gestión de distintas áreas de la empresa a través de las capacidades de integración entre las distintas soluciones. De la misma manera, podremos por ejemplo diseñar una solución BPMS integrando la misma en una misma implementación con una plataforma de gestión documental como por ejemplo Alfresco, con una herramienta para la gestión de reglas de negocio y con una herramienta de ETL y Business Intelligence como Pentaho para el análisis de datos de nuestros procesos. Estas combinaciones son perfectamente válidas e incluso recomendables para aprovechar la potencia y capacidades de las mejores soluciones del mercado o aquellas con las que nuestra empresa tenga mayor experiencia en su manejo.

358


A la hora de seleccionar una plataforma de BPMS podemos establecer las siguientes recomendaciones: -

Capacidad de cubrir todo el ciclo de vida de los procesos. Capacidad de simulación y optimización de los procesos. Soporte para SOA. Soporte a tareas humanas.

La mayoría de BPMS se sustentan en el ciclo de vida de los procesos de negocio que ya hemos analizado. Atendiendo a este ciclo de vida de Diseñar – Modelar – Ejecutar – Monitorizar - Optimizar, mostraremos los diferentes módulos con los que cuentan las plataformas BPMS para permitir ejecutar todas las operaciones del ciclo de vida de los procesos. De forma general, las acciones y módulos que utilizaremos en un BPMS son: -

-

-

-

-

Modelador de Procesos: Donde realizaremos el diseño y modelado de los procesos de negocio, se crean o diseñan los procesos o se modifican y mejoran los ya existentes para su optimización. En esta etapa, el principal involucrado corresponde a un perfil de negocio que generalmente es el Analista de negocio. En el Modelador podremos validar el proceso y simular el funcionamiento del mismo tras introducir los datos, roles y reglas de negocio necesarios para describir su funcionamiento y operativa. Entorno de Integración: donde se integran los componentes externos necesarios para la ejecución del proceso. El principal involucrado aquí corresponde a gente de TI. Dentro del motor de integración, tendremos también los Motores de Orquestación que permiten coordinar la secuencia de actividades según los flujos y reglas del modelo de procesos. Servidor de Procesos: para el despliegue y ejecución de los procesos, donde se ponen a funcionar los procesos diseñados y recolectamos información de los mismos. Monitorización: donde seguimos y monitorizamos los procesos para analizar su información (indicadores, caminos críticos, cuellos de botella, rendimiento, etc.) para poder realizar la evaluación y optimización de los procesos. Vuelta al primer paso de Diseño (y Re-Diseño) y Modelado de procesos cerrando el ciclo.

359


Las fases del ciclo de vida no tienen por qué ser ejecutadas en el orden indicado, sino que estas pueden ser concurrentes y podemos pasar de una a otra en cualquier momento según lo necesitemos. No describiré en este libro el uso de ninguna plataforma en concreto, como venimos diciendo, prácticamente todas permiten realizar el ciclo de vida de los procesos con ligeras variaciones en la arquitectura de cada BPMS. En los siguientes apartados describiré los distintos módulos genéricos de una plataforma BPMS siguiendo tanto el ciclo de vida de los procesos como el siguiente ciclo de implementación directa en una plataforma BPMS: 1. 2. 3. 4. 5. 6. 7. 8. 360

Modelar el proceso. Introducir datos del proceso. Crear los formularios web de interacción con personas. Establecer las Reglas de Negocio. Asignar los recursos. Integración con otros sistemas. Verificar el proceso. Implementar el proceso.


Modelador gráfico de procesos. Para modelar el proceso que queremos implementar utilizaremos una herramienta de modelado, haciendo uso de nuestro conocimiento y habilidades en BPMN. Lo más importante es que antes de trasladar al modelador el diseño de nuestro proceso, este modelo sea correcto, alineado con los objetivos de la empresa, que lo hayamos seleccionado como importante para la organización, hayamos trasladado al equipo la importancia de su implementación y que éste se encuentre perfectamente optimizado, de forma que contemos con las mayores probabilidades de éxito posibles en su implementación dentro de la organización. Para el modelado, dispondremos en la herramienta de modelado de una paleta con los distintos elementos de BPMN, los cuales iremos trasladando al diagrama hasta obtener el modelo. Durante este proceso, dispondremos de ayuda para verificar el correcto modelado en BPMN y utilidades como “drag and drop” que nos harán más rápida la tarea de modelado. Dentro de la herramienta de modelado, pulsando sobre los distintos elementos de BPMN de la paleta, podremos especificar los tipos de actividades (automáticas, manuales, etc.), eventos (inicio, fin, mensaje, etc.) y flujos de nuestro modelo así como textos de ayuda y comentarios sobre los distintos elementos o partes del modelo y que ayudaran al usuario final del proceso a entender la actividad que está modelando. Las herramientas de modelado de procesos incluidas en los BPMS nos permitirán crear descripciones de procesos de negocio más rápidamente, comprobar que los modelos sean correctos y consistentes, expresar los procesos y sus detalles, poder entender los mismos para entender su complejidad y utilizarlos para comunicarnos con el resto del equipo en las distintas versiones de los modelos. A partir de la estrategia y objetivos de la organización, modelaremos los eventos, los procesos privados y públicos, los roles, definiremos las reglas de negocio, los indicadores para medir el rendimiento y la alineación de estos con la estrategia empresarial. El modelador permitirá modelar los procesos a través del estándar BPMN (Business Process Model Notation) el cual permite expresar de forma gráfica las actividades, eventos y el flujo que le indicarán al sistema cómo comportarse y como ejecutarse, que pasos tendrá que dar, que decisiones tomar y que hacer en caso de que ocurra alguna excepción. Además podremos sobre la misma herramienta de mo361


delado, asociar al modelo la información y datos de recursos, tiempos, costes, mensajes, entradas y salidas de cada proceso, de forma que el BPMS almacene estos datos y documentación asociada a los modelos. Como hemos visto en la estrategia de implementación de BPM, el modelado lo realizaremos tanto del As-Is (como son nuestros procesos actuales) como del To-Be, para describir el proceso mejorado, en base a reuniones con el equipo de proyecto para gradualmente ir modelando el proceso que estemos tratando en cada momento. La herramienta de modelado no tiene porque ser un BPMS completo, existen en el mercado tanto soluciones de pago como “open source” para realzar estos modelados, algunas dedicadas en exclusiva a esta operación de modelado y otras que forman parte de los BPMS. Herramientas de modelado hay muchas, pero la gran diferencia entre ellas está en las que tiene orientación a procesos y las que no. Muchos de los BPMS más conocidos del mercado suelen ofrecer de forma gratuita su herramienta de modelado, sin embargo debemos exigir a estas herramientas un mínimo de funcionalidades y características como son: soporte para BPMN y validez de los modelos diseñados en el mismo, posibilidad de asociar datos a procesos (entradas y salidas de las actividades, recursos empleados por la actividad, costes, unidades producidas, defectos, etc..), implementación de reglas de negocio y capacidad de simulación de procesos y generación de código (algunos modeladores soportan UML, de forma que los programadores puedan coger el modelado y generar el código, pero en general hoy en día a un modelador le exigiremos capacidad de generar directamente código BPEL). Además de estas características, podemos encontrarnos modeladores orientados a distintos estándares o metodologías, por ejemplo, con altas capacidades de análisis para proyectos más centrados en Six Sigma o con plantillas específicas por ejemplo para SCOR, de forma que nos sea mucho más fácil y rápido implementar este tipo de procesos y las medidas típicas asociadas a estos entornos de implementación. En la práctica el modelador de procesos nos va a permitir modificar con facilidad el flujo, los datos y reglas de negocio de nuestro proceso. Esta funcionalidad adquiere mayor importancia cuando la vemos desde la fase de simulación o ejecución, cuando nos encontramos en una suite BPMS, donde a partir de los resultados de una simulación o por los cambios en los requerimientos de un proceso, podremos modificar el proceso sobre la herramienta de modelado, encargándose el BPMS de realizar las modificaciones en los ejecutables, sin necesidad de escribir una sola línea de código. 362


Esta capacidad junto con la filosofía de gestión subyacente a BPM y el lenguaje de modelado BPMN, confieren a BPM la posibilidad de unir al personal de negocio y de TI en el desarrollo conjunto de procesos y poder modificar, de acuerdo a la naturaleza cambiante de los negocios, los procesos y proyectos que debamos emprender. La característica principal de las herramientas de modelado es la capacidad de generar aplicaciones software, integrar sistemas, datos y personas para gestionar y controlar los flujos del proceso y la de poder remodelar nuestros procesos sin necesidad de reprogramar los aplicativos. Esta propiedad se consigue mediante la transformación del modelo por parte de las herramientas de modelado en código BPEL, de forma que nos saltamos la fase de desarrollo software, transformando el modelado directamente en código BPEL ejecutable y reduciendo la brecha entre el modelado de procesos de negocio y su implementación en los BPMS. Este generador de código ejecutable BPEL a partir del modelado en BPMN, viene a ser como una herramienta de desarrollo de software de Quinta Generación (5GL) para el desarrollo de aplicaciones a muy alto nivel que considera los modelos de datos, formularios, consultas e integraciones con otras plataformas, para desarrollar la solución de software final. Podríamos hacernos la pregunta de si una herramienta de modelado que ejecuta código BPEL pasaría el Test de Touring, de forma que no podamos distinguir si es un programador humano o la máquina quien realiza el código. Esta capacidad se verá facilitada además por la adopción de una arquitectura tecnológica como SOA, la cual nos proporcionará la agilidad necesaria para movernos entre nuestras arquitecturas de negocio y tecnológicas. Una vez comenzamos a modelar en nuestro entorno gráfico en el estándar BPMN, el propio BPMS realiza las tareas de conversión a los lenguajes de ejecución. Estos lenguajes son: -

-

XPDL (XML Process Definition Language) que es la representación XML del proceso modelado en BPMN y que puede ser usado para intercambiar modelos de procesos entre distintas herramientas. Tiene sus raíces en los sistemas de workflow y de hecho está basado en WPDL (Workflow Process Definition Language) BPEL es el nombre acortado de BPEL4WS (Business Process Execution Language for web services). BPEL es un lenguaje de ejecución de procesos de negocio basado en XML desarrollado por BEA, IBM y Microsoft. BPEL es el lenguaje empleado por el mo363


tor de procesos para la ejecución de los procesos y que opera a nivel de “máquina” y surge del XPDL. BPEL está ampliamente difundido y es soportado por la mayoría de herramientas como lenguaje de ejecución. BPEL está inspirado en XLANG y WSFL y es un lenguaje centrado en el proceso por lo que no considera las interfaces humanas y es por ello que se desarrolló BPEL4People (BPEL for People) que es una extensión de IBM y SAP, propuesta en el año 2005 y por tanto posterior a muchos BPMS actualmente en el mercado.

Este modelo es parecido al usado para el desarrollo de aplicaciones informáticas en la gestión de datos:

El estándar BPEL está centrado en el proceso (Process-centric) y no en las tareas del usuario (user-centric), por lo que se propuso la extensión BPEL4People en el año 2005. Muchas plataformas BPMS no incluyen esta 364


extensión y en consecuencia para manejar interacciones humanas, cada plataforma da una serie de extensiones para poder diseñar y generar interfaces humanas en base a formularios web, en las que los usuarios puedan introducir datos y acciones, interaccionar con otros usuarios y aplicativos integrados en el proceso. Con los modeladores usados por los BPMS, podemos no sólo modelar diagramas de comportamiento y procesos de nuestra organización, como lo hacíamos antes, sino que podemos añadirles información, para luego a través de BPEL, ser ejecutados. Esta información se refiere a costos, descripciones de los procesos y actividades, tiempos, roles de usuarios, formularios, tareas automatizadas o humanas y reglas de negocio que nos permitirán además simular el comportamiento de los procesos previamente a su implementación.

Datos del proceso: Continuando dentro de la herramienta de modelado, introduciremos los datos requeridos por nuestro proceso. Esta es probablemente la tarea más ardua y laboriosa que realizaremos en el BPMS y dependiendo del tamaño del proceso, su complejidad, y del número de variables y datos asociados al mismo, es la que consumirá más tiempo en la especificación del mismo. Entre las propiedades que podemos especificar (normalmente pulsando el botón derecho del ratón sobre una actividad) tenemos entre otras: el nombre del proceso, la descripción, el coste y la duración, para las cuales introduciremos los datos asociados a los distintos elementos de nuestro proceso. Pulsando sobre las propiedades de las actividades de nuestro modelo, podemos completar los datos de cada actividad, así como crear nuevos atributos personalizados para el mismo y de esta forma, además de los datos genéricos como coste y duración de la actividad, podremos diseñar nuestros propios tipos de datos como longitud, fechas, unidades vendidas y aquellos específicos de las actividades de nuestro proceso, indicando para cada uno de estos nuevos atributos el tipo de que se trata (Integer, String, Date, etc.).

365


Para ayudarnos en este proceso, en algunos BPMS contaremos con un modelador de datos, que es una representación gráfica del modelo entidadrelación, sobre la que podremos trabajar todos estos datos de forma visual. Ejemplo de Lista de Atributos: Nombre Visual Nombre Factura Factura Importe Importe Nº Factura Nº Factura Fecha Factura Fecha Pagada? Pagada

Tipo Archivo Moneda Número Fecha Booleano (Si-No)

Creación de los formularios web: Estos serán los formularios a través de las cuales los usuarios que participen en el proceso interactuarán con el mismo, registrando la información necesaria para la ejecución del proceso y visualizando los datos que puedan necesitar para poder ejecutar las tareas que se le soliciten. Durante el flujo de nuestros procesos, necesitaremos en muchas ocasiones involucrar a personas en las actividades del mismo, por lo que haremos uso de los formularios web para interactuar con estas personas. Estas intervenciones de personas en el proceso serán generalmente lanzadas por algún tipo de alerta o notificación que apunten a las tareas o actividades que cada usuario deba realizar. Para ayudarnos con este paso, los BPMS cuentan con un modelador de formularios, en el cual podremos diseñar los formularios asociados a las actividades que hayamos especificado como manuales. En el modelador de formularios, encontraremos una paleta con los distintos elementos que pueden formar parte de un formulario y los distintos atributos del modelo de datos para de forma gráfica, ir componiendo y asociando el formulario con los atributos y especificar cada uno de los campos: requerido, editable y visible, así como sus valores por defecto. Editor de Reglas de Negocio: Las reglas de negocio que representan la lógica en la toma de decisiones del proceso, se definen a través del motor de reglas en la etapa de modelado. Este editor es una herramienta gráfica que nos permite diseñar las 366


reglas de negocio que regirán el funcionamiento del proceso, de forma que este pueda funcionar de forma distinta según el valor de las variables de entorno. Estas reglas las podremos establecer en los “rombos” de decisión de BPMN de nuestro modelo o en los flujos de secuencia, para verificar que se cumple una condición específica y que devolverán valores de verdadero o falso. Sobre la herramienta de modelado y pulsando sobre una compuerta de decisión o flujo de secuencia, nos llevará a un editor de reglas de negocio, donde podremos establecer las condiciones de verdadero o falso y las expresiones booleanas asociadas a las reglas que establezcamos para nuestro flujo de proceso. En el editor de reglas de negocio, además de poder editar las reglas sobre las condiciones y flujos del proceso, también podremos establecer condiciones, validaciones y normas que deben seguir las actividades del mismo mediante la asignación de acciones al “entrar” o “salir” de las actividades y de esta forma controlar el flujo del proceso y acciones relacionadas. Aunque las herramientas de modelado permitan hacerlo, no es recomendable modelar las reglas de negocio en el flujo de proceso, sino que es más recomendable identificar donde se utilizarán estas reglas y gestionarlas en las herramientas específicas para reglas de negocio. Los BPMS incluyen sofisticadas herramientas para la gestión de estas reglas como parte de sus sistemas, permitiendo de esta manera la automatización de los procesos de negocio. Algunos editores de reglas de negocio, en lugar de este entorno gráfico, ofrecen un entorno de programación para la especificación de estas reglas y casi todos los BPMS disponen de hojas de cálculo para el establecimiento y definición de las mismas la cuales pueden ser de dos tipos: -

-

Reglas de flujo: decisiones automáticas basadas en opciones del proceso (si el pedido es superior a 3.000 € entonces un gestor debe aprobar el pedido). Reglas de negocio: independientes del proceso (hacemos un descuento del 5% cuando el total de pedidos sea superior a 5.000 €).

367


Asignación de recursos: Esta es una fase muy importante donde definiremos y asignaremos los recursos humanos responsables de la realización de cada uno de las actividades así como otro tipo de recursos necesarios para la ejecución del proceso. Para esta asignación de recursos, los BPMS cuentan con una herramienta específica para ello a través de la cual seleccionaremos la actividad y asignaremos o crearemos nuevos recursos utilizados por el proceso.

Entorno de Integración. (Integration Developer) Los procesos rara vez operan aislados o parten de la nada, sino que más bien, estos deben integrarse con los sistemas existentes en los que recalan los repositorios de datos e información necesaria para poder ejecutar los procesos. Los procesos de negocio no se limitarán al modelado que realicemos y generalmente, muchas partes de estos procesos se encontrarán en aplicativos que ya existen dentro la empresa como los ERP, CRM, SCM y otras aplicaciones informáticas. Otras veces, estas partes de los procesos, de su lógica, datos o información, se encontrarán dentro de capas de intermediación o middleware. Cuando en el modelado del proceso definimos una actividad como automática, es con el motor de integración de los BPMS con lo que proveemos de los datos necesarios para el funcionamiento del proceso e indicaremos a qué sistema o base de datos deben conectarse las actividades incluidas en el mismo para obtener dichos datos y poder ser ejecutadas. Los BPMS recogen toda la evolución de los sistemas EAI y Middelware para proveer de mecanismos y herramientas para integrar con todo tipo de aplicaciones empresariales existentes en la empresa o fuera de ella, invocando a aplicaciones y bases de datos cuando así lo requiera el proceso descrito en la herramienta de modelado. Entre las utilidades de integración de los procesos con las aplicaciones tendremos web services, conexiones ODBC y JDBC, APIs, librerías, etc. aunque como veremos al final de este capítulo, esta integración será mucho más ágil y efectiva haciendo uso de arquitecturas SOA, al permitirnos estas reutilizar componentes de software distribuidos en múltiples aplicaciones para armar y modificar los procesos, de manera que la integración de aplicaciones se vuelva casi transparente y mucho más reutilizable. 368


Todo BPMS necesita gestionar las integraciones con aplicativos externos asociados al proceso. Casi todos los BPMS comerciales basan su motor de integración en sistemas middleware como el Java Server de IBM, WebSphere o BizTalk de Microsoft. Además prácticamente todos los ERP y sistemas CRM ofrecen APIs en sus programas para poder conectarse con ellos como el NetWeaver de SAP para el acceso a los módulos de SAP. Recurriendo al módulo de integración de nuestro BPMS, se nos presentarán las tareas indicadas como automáticas para que podamos establecer las integraciones necesarias de estas actividades, mostrándonos en una interfaz las tablas del modelo de datos de la actividad seleccionada y la de los datos del servicio web o aplicativo al que nos conectemos para que realicemos la configuración entre ambas y donde podremos también definir qué hacer en caso de error o falta de comunicación como pueda ser el lanzamiento de una excepción. Podemos clasificar los procesos en función del tipo de interacción en: -

-

Sistema a Sistema: entre aplicativos y orígenes de datos. Son los más comunes y establecen su comunicación a través de mensajes, conectores de bases de datos, APIs de las aplicaciones o web services. En este último caso de los web services, disponemos de la capacidad de llamar a servicios web externos u ofrecer las funcionalidades a sistemas externos a través de los mismos. Los BPMS aunque permiten la integración con orígenes de datos (ODBC, JDBC, etc.), vienen orientados hacia la integración con aplicaciones, las cuales resultan mucho más seguras y trasladan la lógica de las aplicaciones a las integraciones. Persona a Persona: son las más complicadas, en ellas varias personas colaboran en una transacción. Persona a Sistema: de personas que crean transacciones sobre aplicativos, en ellos, una persona desde una interfaz web provoca una transacción sobre un aplicativo como por ejemplo un ERP.

Como vemos, con estas tres posibilidades de integración, los motores de integración nos permitirán coordinar la secuencia de actividades según los flujos y reglas establecidas en el modelo, manejando simultáneamente integraciones de sistemas informáticos y humanos. En las integraciones Sistema a Sistema haremos uso de las herramientas de integración proporcionadas por los propios BPMS. Para las integraciones Persona a Persona y 369


Persona a Sistema, los BPMS utilizarán herramientas de creación de formularios web, a través de los cuales los usuarios introducen sus datos o decisiones que son integradas directamente en los procesos o en otros sistemas. Para la integración con sistemas externos, el motor de integración debe además de proveer de capacidades de transformación de datos que en muchas ocasiones son herramientas ETL (de extracción, transformación y carga de datos: Extract, Transformation, Load, en inglés) utilizados por muchos aplicativos, cuadros de mando y sistemas de business intelligence para proveerse de datos de otros sistemas, extraer sus orígenes de datos, realizar las transformaciones necesarias sobre estos datos y la carga de los mismos ya transformados al sistema que hará uso de ellos, siendo en muchas ocasiones los BPMS utilizados para integrar información empresarial dispersa en distintos sistemas empresariales. Para la ejecución de estas tareas de integración, los motores de integración de los BPMS cuentan para ello con todas las APIs y protocolos de comunicación, estándares, drivers para bases de datos, procedimientos de llamada remota, workflow y mensajería, para que los BPMS interoperen y se comuniquen entre ellos y con otras aplicaciones. En este sentido, se puede integrar prácticamente con cualquier tipo de aplicativo o base de datos externa, invocar servicios web externos o que otros sistemas invoquen servicios web del BPMS, integrar con servidores de correo electrónico, plataforma de gestión de contenidos (ECM), ERP´s, CRM´s, etc. Así por ejemplo podemos tener en un proceso una actividad especificada en el modelado como automática que contenga distintos conectores. Por ejemplo, supongamos un proceso para la gestión de incidencias por parte de clientes. Dentro de nuestro proceso podemos conectar este con un CRM para registrar y/o obtener los datos del cliente, podemos registrar el incidente con una plataforma de gestión documental, podremos también conectar el proceso con una plataforma de Business Intelligence para recoger los datos del proceso y enlazar la misma con un motor de reglas de negocio que puedan ser consumidas por el proceso en forma de web service expuesto. Estas conectividades típicas con estas plataformas en entornos reales, podemos hacerlas usando los conectores nativos de las plataformas BPMS o desarrollar nuestros propios conectores por ejemplo con en Java con NetBeans para crear nuestros propios web services.

370


Coreografía y orquestación: Existen dos marcos sobre los que pueden trabajar las empresas para la combinación de servicios entre distintos participantes y que se realizan, como hemos visto en BPMN, exclusivamente a través de mensajes entre los procesos. Estas dos formas de interacción son la Coreografía y la Orquestación. En la orquestación, un “conductor” le dice al resto qué tiene que hacer y se asegura de que estos lo hagan, es decir, un conjunto de servicios son coordinados por otro que controla las interacciones, de modo que los coordinados no tienen conocimiento de que forman parte del sistema. En este caso, una empresa impone los sistemas de información y tecnologías que serán utilizados para llevar a cabo el proceso, esta empresa posee el BPMS que controla todo el proceso y hace uso de los sistemas de las demás. La coreografía es la interacción de dos o más procesos de negocio e indica la ausencia de un agente central que controle las actividades. La coreografía define sólo las interacciones entre los participantes y no como cada uno de estos realiza sus actividades internamente. Son como bailarines que deben ponerse de acuerdo en una coreografía común: durante el baile cada bailarín realiza su danza, pero en determinados puntos, debe ponerse de acuerdo con otros bailarines. En la coreografía, cada participante juega su papel de forma independiente en un plan predefinido, no existe un coordinador centralizado, sino que cada servicio colabora con el resto y conoce con quien puede interactuar. En este caso, en vez de un único coordinador, cada empresa dispone de su propio BPMS y colaboran conjuntamente en un proceso.

Servidor de procesos. El servidor o motor de procesos es el corazón de los BPMS y es el encargado de interpretar el código BPEL en tiempo real y automatizar los procesos modelados. Este servidor de procesos es el que hace que se mueva todo el engranaje: dirigir a los usuarios que participan en las diferentes actividades, gestionar el estado de los procesos y los datos asociados a estos, controlan las integraciones internas y externas que participan en el proceso, la lógica diseñada en el flujo del modelado y los puntos de intervención de los

371


usuarios y sistemas, permitiendo no sólo ejecutar sino también poder realizar cambios en tiempo de ejecución o controlar las versiones del proceso. El servidor de procesos recibe la definición del proceso en código BPEL (generado por el modelador, que transforma la notación en lenguaje ejecutable) y ejecuta instancias del proceso como una serie de pasos indicados en el modelo. El servidor de procesos nos permite monitorizar de forma dinámica el estado de los procesos a través de herramientas visuales (generalmente sobre el propio diagrama visual en BPMN) que nos muestran las actividades en ejecución y permite acciones típicas como el arranque, parada y eliminación de actividades y procesos.

El motor de procesos, siguiendo el diseño del proceso desarrollado en el modelador de procesos y transformado por este motor al lenguaje BPEL, ejecuta el modelo de acuerdo al flujo especificado, identificando entradas, salidas, roles de participantes, datos y servicios software, integrando a personas, datos y servicios, para lograr la ejecución de cada proceso. Es necesario antes de realizar el despliegue de nuestro modelo en el servidor de procesos, que dispongamos del diseño y estructura de los frontales web, tanto los que usaremos para interacción con humanos como con servicios externos, web services o aplicativos con los que nos vayamos a conectar. Como comentábamos al hablar de BPEL, antes de la aparición de BPEL for People, los fabricantes de BPMS desarrollaron sus propias extensiones para suplir la falta de orientación a humanos en el lenguaje BPEL, por 372


lo que en algunos BPMS, los formularios para interacción con humanos se despliegan como web services y en otros como XForm o simples formularios. El Motor de Procesos gestiona y coordina tres tipos de motores: -

-

Motor de Flujo de Procesos: que gestiona el flujo de ejecución según el diseño del proceso. Motor de Integración: el cual gestiona y coordina las aplicaciones necesarias para la ejecución del proceso y gestiona los datos asociados a estas integraciones. Motor de Reglas de Negocio: para la gestión y mantenimiento de las reglas de negocios descritas en el diseño.

Dentro del servidor de procesos dispondremos también de un administrador de usuarios con capacidades de integración con DA y LDAP para administrar los usuarios y sus relaciones funcionales. Prácticamente todos los BPMS del mercado operan sobre una arquitectura web como la mostrada en el siguiente gráfico:

Las interacciones con usuarios son a través de frontales web desde cualquier dispositivo con acceso a internet y la plataforma BPM le proporcionará todos los datos y la información necesaria para poder completar sus tareas. Al ser internet un medio pasivo, para poder continuar un proceso, muchas veces se requerirá de la acción de una persona para que el proceso 373


pueda continuar, por lo que se hace uso de la mensajería para avisar/alertar a esa personas sobre la acción que debe tomar, de forma que será el diseño de los procesos de negocio quien dirigirá el motor de procesos. En BPM se parte de la consideración de que la información debe buscar al actor para que este responda y se pueda continuar el flujo del proceso y no que los actores reporten datos al sistema para que algo ocurra. Dentro de estos flujos del proceso, disponemos también de mecanismos para la asignación de tareas por parte de una persona a otra persona o la de consulta para que esa persona pueda consultar a otra sobre qué acción tomar y el servidor web envíe los mensajes de interacción con los clientes al servidor BPMS. El servidor de procesos del BPMS tiene acceso a una base de datos propia o repositorio donde almacena datos de ejecución de los procesos, mantiene los componentes y recursos de los procesos (definiciones, modelos, reglas, etc.) y permite su disponibilidad para ser reutilizados en otros procesos, al tiempo que se comunica con aplicativos y bases de datos externas (ERP, CRM, etc.) para poder ejecutar la monitorización y análisis de procesos. Como es de esperar, estos motores de los BPMS, son los que más recursos hardware consumen, en especial si los comparamos con las suites de workflow. Esto es así principalmente por el motor de integración, por lo que cuando ejecutemos estos motores necesitaremos de grandes servidores capaces de correr estos motores de procesos.

Ejecución del proceso. Finalmente, una vez modelado el proceso, introducidos los datos asociados al mismo, las reglas de negocio, los recursos y realizadas las integraciones necesarias, estaremos en disposición de ejecutar el proceso, el cual podremos ejecutar en un entorno de pruebas y desarrollo o directamente en un entorno de producción. La ejecución del proceso se presentará en casi todas las plataformas en un entorno web, a través del cual tanto los administradores como los usuarios del proceso podrán interactuar con el mismo. La ejecución del proceso se realizará sobre la máquina en la que hayamos diseñado y configurado el proceso, aunque podremos indicar otras localizaciones geográficas para el servidor de procesos y trabajar remotamente. 374


Simulación. Los procesos generalmente no son deterministas, en el sentido de repetir siempre los mismos comportamientos, sino que más bien serán del tipo estocástico, es decir, tienen cierto grado de incertidumbre, pues al repetir la simulación con los mismos datos iniciales varias veces, los resultados no son siempre los mismos y es por ello que esta funcionalidad de simulación como hemos visto en el capítulo anterior, es fundamental en BPM a la hora de permitir simular procesos, de forma que podamos estudiar diferentes alternativas para nuestros procesos, predecir su comportamiento, fallos, cuellos de botella y posibilidades de mejora para evaluar y dar respuesta a situaciones y escenarios antes de su implementación, obtener explicaciones, tomar decisiones y comprobar cómo se comportarán los procesos bajo diferentes situaciones. Debemos recordar que los BPMS tuvieron su origen en los sistemas de workflow, estos sistemas aparecidos en los años 80 para la automatización de actividades, evolucionaron hacia los actuales BPMS por su capacidad de realizar análisis tanto cuantitativos como cualitativos de los datos del proceso, así como de integrar en los procesos otras aplicaciones. Por lo fundamental que es para los proyectos de BPM y la potencia que ofrecen estos simuladores, todos los BPMS incorporan o deberían incorporar esta funcionalidad de forma tal que sobre la misma herramienta de modelado podamos simular la ejecución y rendimiento de los procesos modelados, variando los escenarios, los recursos, costes, tiempos etc. para la optimización del proceso en función de los distintos parámetros y simular un cambio en cualquier parámetro que deseemos y obtener información sobre el comportamiento del proceso para decidir si cambiar o no el mismo. Puesto que la simulación (o Debug, como se denomina en algunos BPMS) puede involucrar a un gran número de personas, agentes y sistemas informáticos especificados en nuestros procesos, algunos BPMS permiten el detener la ejecución de los componentes que especifiquemos durante la simulación con objeto de no tenerlos en cuenta durante la simulación si todavía no tenemos activados a estos agentes o por cualquier motivo, no deseamos incluirlos en este análisis. En los BPMS, una vez que se introducen los datos, la simulación produce aleatoriedad en el modelo del proceso, ejecutando el mismo varias veces y por diferentes caminos del flujo diseñado y realizando los cálculos asociados al proceso. Esta simulación incluye el cálculo de probabilidades, funciones de simulación, de distribuciones, análisis estadístico, cálculo de tiempos 375


y recursos utilizados por las diferentes actividades del proceso, proporcionándonos informes de posibles problemas, cuellos de botella, impacto y debilidades que tengamos en el proceso diseñado (tiempos de ciclos de proceso, tiempos de espera, costes, etc.), para que podamos volver al modelo y corregir estos errores. Hay dos principales tipos de simulación: -

Simulación continua: donde el estado cambia a lo largo del tiempo del proceso. Simulación discreta: donde los estados del proceso no cambian a largo del tiempo sino a través de eventos.

Muchos BPMS permiten identificar las variaciones en los procesos automáticamente así como buscar soluciones a estas variaciones y comportamientos de los procesos. Una vez ponemos nuestros procesos en marcha en la simulación, el BPMS nos proporcionará información de los datos capturados en los procesos, mostrándonos las discrepancias entre los datos obtenidos y los deseados, sin embargo, no debemos olvidar que la optimización es una tarea de las personas de negocio, ningún sistema puede tomar ciertas decisiones sino que debe ayudarnos a la toma decisiones y a cómo mejorar nuestros procesos, respondiendo a preguntas del tipo: -

¿Cómo mejorar la eficiencia de nuestros procesos? ¿Cómo identificar cual de las posibles variantes de un proceso será mejor para alcanzar los resultados deseados? ¿Cómo predecir los requerimientos de recursos que vamos a tener en distintos escenarios? ¿Dónde están los cuellos de botella que afectan a la experiencia de nuestros clientes? ¿Cómo podemos maximizar los beneficios?

A estas preguntas responderemos con ayuda de la herramienta de simulación analizando el comportamiento dinámico de los procesos, repitiendo muchas veces los procesos sobre distintos escenarios, probando los To-Be y evaluando la eficiencia de los mismos antes de incurrir en el coste y el riesgo de implementarlos sin haberlos simulado y sin haber predecido su comportamiento, simulando los procesos muchas veces con diferentes datos, testeando diferentes niveles y volúmenes de carga de trabajo y ajustando los recursos y tareas para medir los resultados, estimar costes y tiempos y definir escenarios (inicio, fin, calendarios de trabajo, coste de los recursos, 376


duración de las actividades, etc.), es decir, como decíamos al hablar de innovación: “chatarreando” con nuestros procesos.

Monitorización de procesos. Generalmente vemos como los sistemas y aplicativos informáticos no evolucionan según los requerimientos de negocio y de mercado por la dificultad y el costo humano y monetario que implica el realizar cambios sobre algo que “ya funciona”, por lo que nos adaptamos a la herramienta informática o simplemente no monitorizamos el resultado de los procesos, pues de antemano, sabemos que no vamos a realizar cambios. En cierta manera podemos decir que los BPMS han venido para permitirnos salir de este agujero, dando un giro de 180 grados a la forma en la que pensamos sobre nuestros procesos de negocio y los sistemas de TI que los soportan. El valor más obvio de los sistemas BPMS es la monitorización en tiempo real de las actividades del proceso y de los aplicativos externos integrados con el mismo, visualizando los datos e indicadores de nuestros procesos de forma que podamos mejorar la visibilidad de los mismos, el control de las operaciones y la ejecución de sus actividades en busca de ineficiencias y cuellos de botella que puedan empeorar el servicio a clientes y el propio negocio. En la monitorización, los BPMS se comportan de forma similar a los sistemas SPC (Statistical Process Control) utilizados en las plantas de producción para proporcionar datos e información de lo que acontece en la operativa de los procesos productivos para ser analizada. En los BPMS disponemos de distintas herramientas para el análisis de negocio como los BAM (Business Activity Monitoring), incluidos en la mayoría de plataformas de BPMS o herramientas de BI (Business Intelligence) y de Cuadro de Mando, pero independientemente del punto de vista que definamos para medir o de las herramientas que usemos para visualizar las medidas, el aspecto más importante es la capacidad de monitorizar el proceso y ver que su comportamiento se ajusta a lo planeado para el mismo, así como la agilidad para poder responder a los cambios observados, disponiendo de una herramienta que nos permita tomar las mejores decisiones para la modificación y mejoras que exijan los procesos y poder implementarlas en la herramienta 377


de modelado de forma rápida, sin necesidad de lanzar grandes proyectos de TI para su modificación. BAM (Business Activity Monitoring) es un término acuñado por Gartner Group que proporciona el seguimiento en tiempo real de las actividades del proceso, los indicadores de negocio (KPIs) y los SLAs (Service Leve Agreement), pudiendo además definir alertas de acuerdo a eventos que sucedan en el proceso de negocio o medidas del resultado del proceso que establezcamos. Estos módulos son muy parecidos a cuadros de mando personalizados que nos muestran el comportamiento de los procesos y sus informes asociados derivados del monitoreo del proceso (BAM). Un proceso diseñado bajo el estándar BPMN y convertido en ejecutable a través de BPEL con una Suite BPMS, puede proveer de información en tiempo real de la ejecución del proceso, lo que permite una Monitorización de las Actividades de Negocio (BAM, por sus siglas en inglés) por lo que los datos estarán disponibles a partir de la información histórica del proceso. Esta información puede venir de métricas de calidad, Six Sigma y otros datos de monitorización del proceso: tiempos de proceso o de etapas del mismo, aprobaciones, capacidades del proceso, defectos, gráficos de Pareto, etc. que vimos en las herramientas de análisis de procesos en el Capítulo 1. Generalmente los monitores de procesos incluyen herramientas de análisis así como de generación de documentación e informes sobre los procesos. Los análisis se realizan a partir de datos históricos almacenados en la base de datos del servidor de procesos, para la identificación de patrones de comportamiento que permitan predecir resultados y mejoras en el funcionamiento de los procesos. Generalmente este análisis se realiza con herramientas de BI (Business Intelligence) que permiten ver los datos históricos y los KPI agrupados para analizarlos en profundidad, cuadros de mando, hojas de Excel y todo tipo de gráficas a partir de los indicadores y métricas definidas para el proceso. Las capacidades de monitorización de datos de procesos son todavía hoy muy limitadas para la mayoría de plataformas BPMS, limitándose esta monitorización a información relativa a las actividades del proceso. Para obtener sistemas de monitorización de negocio más potentes, necesitaremos combinar la información de estos procesos con otras fuentes de datos, además de los históricos de datos, para poder desarrollar capacidades de análisis y predicción sobre la monitorización, por lo que necesitaremos de 378


sistemas como los Data Mining, de cuadro de mando o Business Intelligence, que si bien todavía no han sido implementadas en la mayoría de las plataformas BPMS, la evolución de las mismas parece ir en este sentido, en la medida que la mayor parte de los fabricantes que ya disponen de suites de Business Intelligence y Cuadro de Mando como IBM, Microsoft u Oracle están procediendo a la integración de éstas con plataformas de BPMS. Aunque algunas plataformas BPMS disponen ya de soluciones BPM completamente integradas con herramientas avanzadas de monitoreo como Cuadros de Mando y Business Intelligence, en general, en todas las plataformas disponemos de herramientas suficientes para monitorizar los procesos desplegados y ejecutados por el servidor de procesos, así como herramientas visuales para la interpretación de los resultados tanto a niveles altos de la empresa o niveles ejecutivos para analizar por ejemplo el número de transacciones realizadas, tiempos de ejecución y respuesta, errores producidos, etc. así como en niveles más bajos y operativos, por ejemplo, para los departamentos de ventas, producción o TI, interesados en observar el comportamiento de los procesos y actividades a estos niveles. Como vemos los plataforma BPMS nos permiten tanto el modelado, la carga de datos y reglas de negocio, la integración con los sistemas de la empresa y la monitorización de los procesos, pudiendo además ser utilizados conjuntamente con herramientas de ETL para la integración de datos dispersos de la empresa que puedan participar también en el monitoreo y el análisis de los datos. De esta forma los BPMS permiten realizar completamente el ciclo de vida de los procesos así como realizar automáticamente el ciclo DMIAC para la mejora de procesos que vimos al hablar de Six Sigma, generando la documentación de los resultados del estudio y de hecho los BPMS son una herramienta ideal para realizar estos ciclos DMIAC de Six Sigma, al ser estos en sí mismos un proceso que puede ser implementado en los BPMS, los cuales, además nos facilitan la tarea de recogida de datos gracias al uso de las herramientas de integración y ETL con que cuentan los BPMS.

Arquitectura tecnológica. BPM y SOA. La optimización de procesos es sólo la mitad de la batalla de nuestro proyecto, la otra parte corresponderá a la implementación del BPMS y en especial a la parte de las integraciones con sistemas y aplicativos internos y 379


externos de nuestra empresa (ERP, CRM, conectividad con partners y proveedores, etc.) y serán en estas tareas de integración donde más recursos de TI y tiempo necesitaremos para implementar los BPMS y la solución BPM. Como venimos comentando, debemos considerar la combinación de BPM como disciplina de gestión de procesos de negocio como método para modelar la realidad de las organizaciones junto con SOA (Service Oriented Architecture o Arquitectura Orientada a Servicios) como la orientación tecnológica a servicios y como forma de integrar de forma flexible y adaptable las aplicaciones, al ser muchas veces el entorno en el que se desarrollan y operan los procesos de negocio complejos en cuanto a la integración de datos y aplicaciones. SOA es una arquitectura tecnológica para el desarrollo e integración de sistemas, basada en composición y orquestación de servicios independientes, para alcanzar agilidad, flexibilidad y reutilización en nuestras implementaciones y en especial por la simplificación que nos aporta SOA en la gestión del cambio. SOA nos permitirá diseñar, construir, desplegar e integrar los servicios independientemente del lenguaje en que estén programados y de las plataformas sobre los que estos servicios se ejecuten, de forma que podremos vincular los servicios entre sí a través de los procesos de negocio para realizar las funciones empresariales. La sinergia entre BPM y SOA es tal que aunque dependiendo de la envergadura del proyecto y su complejidad, en especial en lo relativo a la integración con sistemas y aplicativos, es impracticable hoy en día en un ecosistema de software moderno, desarrollar un proyecto de BPM sin una arquitectura SOA. La arquitectura orientada a servicios SOA es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio para permitir la creación de sistemas de información altamente escalables que reflejan el negocio de la organización de forma bien definida, mediante la exposición e invocación de servicios web, lo cual facilita enormemente la interacción entre diferentes sistemas propios o de terceros. Sin embargo no debemos pensar que SOA son web services. Lo que SOA hace es definir un modelo para la ejecución de un determinado proceso, que podemos construir a través de web services o de alguna otra manera, pero no sólo con web services, aunque con ellos nos resulte más sencillo adaptar los sistemas a los cambios en los procesos y los negocios y sea esta la razón por la que son utilizados en casi todas las implementaciones SOA. 380


Lo que SOA nos va a permitir es la abstracción de los procesos, de forma que podamos trabajar directamente sobre los procesos en un entorno de negocio en lugar de tener que hacerlo considerando también los aspectos tecnológicos.

Como arquitectura software, SOA viene a resolver muchos de los problemas comentados en el Capítulo 3 en relación a la integración de datos y sistemas y la complejidad en estas integraciones en un entorno de mercado cada vez más interconectado. La idea principal de SOA es capturar las funcionalidades más relevantes del negocio a través de interfaces bien definidos, a través de web services, encapsulando la funcionalidad existente en las aplicaciones en servicios, es decir, ocultando la lógica de negocio y proveyendo sólo los datos o funcionalidades para los que fueron diseñados los web services, de forma que puedan ser usados para la comunicación e integración con otros sistemas y usuarios, interactuando proveedores y consumidores de servicios de forma desacoplada para realizar procesos de negocio. Como vimos en la evolución de las herramientas tecnológicas hasta llegar a BPM en el Capítulo 3, de la necesidad de integrar aplicativos departamentales sin conectividad de datos entre ellos, surgieron las plataformas EAI y el desarrollo de los Middleware. Con el avance de internet y especial381


mente de los protocolos de comunicación asociados a esta tecnología (XML, SOAP, UDDI y WSDL), surgieron nuevas posibilidades de integración de datos y aplicaciones que ahora sí podían comunicarse por la web. Este desarrollo ha ido evolucionado y estandarizándose hasta llegar a SOA, basado en estándares de interoperabilidad e independientes de la tecnología utilizada y que racionalizan no sólo las infraestructuras informáticas mediante una orientación a servicios, sino que permite a los negocios la realización de una idea que ha sobrevolado todo este libro como es el poder de tomar decisiones de negocios apoyadas en tecnología y no determinas por las limitaciones o restricciones de esta. Ganar en agilidad y capacidad de respuesta de las TI a las necesidades de negocio escapando de la esclavitud y obsolescencia de diferentes soluciones sobre diferentes plataformas, repletas de parches para suplir una mala arquitectura de interoperabilidad e información redundante y que resultaba tan costosa en su mantenimiento que los departamentos de TI preferían empezar algo de cero que intentar entender o arreglar las partes ya desarrolladas. Pero para poder implementar SOA, lo primero que deberemos hacer es determinar que sistemas vamos a exponer. SOA viene a ser una evolución de las APIs que usamos para la integración entre aplicaciones pero basándose en los web services para su despliegue. Un web service o servicio es un componente software que puede ser invocado remotamente y que se describen a través de un archivo WSDL (Web Services Definition Language). Para invocar estos servicios se usa el protocolo SOAP (Simple Object Access Protocol) como protocolo de comunicación y sistema de mensajería entre web services, el cual es un documento XML para transportar los parámetros de entrada y salida entre una aplicación y un servicio web. Para el transporte de estos mensajes se pueden utilizar otros protocolos de comunicación como HTTP, SMTP, FTP o mediante colas de mensaje como protocolo más seguro. Además existen los UDDI (Universal Description Discovery and Integration) un estándar para la administración de los servicios web WSDL.

382


Solicitante de Servicio

SOAP

WSDL

Proveedor de Servicio

WSDL Registro de Servicio

-

-

SOAP: define un protocolo de comunicación XML para la comunicación entre servicios. WSDL: es un formato para especificar web services y puede proporcionar información de cómo puede ser usado ese web service. UDDI: provee de la infraestructura para publicar información acerca de los servicios y sus proveedores.

Para los servicios que deban ser expuestos y/o consumidos por usuarios, se utilizan generalmente los frontales web que se conectan a los servicios a través de un bus de servicios. En SOA, a diferencia de las integraciones tradicionales a través por ejemplo de Middleware, las integraciones se realizarán mediante los ESB (Enterprise Service Bus) para convertir los aplicativos en web services. Aunque los ESB no implementan una arquitectura orientada a servicios SOA nos permite el poder implementar al ser el encargado del enrutamiento de los mensajes a las aplicaciones apropiadas y la transformación a través de adaptadores de los mensajes en una arquitectura SOA Como vemos, los web services son el mecanismo a través del cual implementamos actualmente las arquitecturas orientadas a servicios SOA. Los web services pueden ser publicados o invocados por otras aplicaciones a través de la web para ofrecer sus funcionalidades. Los servicios que publiquemos o invoquemos proveerán de los datos, la lógica y las reglas de negocio relacionados con algún aspecto de este, especificando que se puede y que no se puede realizar con ellos y con quien, por lo que a menudo se acompañan de un contrato que establece estos permisos y restricciones. Volviendo a uno de los ejemplos de proceso utilizados en BPMN, podemos ver como un web service puede ser visto como una tarea o subproceso

383


al que recurrimos en tareas automatizadas cuando requerimos de datos o servicios de otros aplicativos y sistemas:

Todo sistema puede interpretarse como un conjunto de servicios. SOA no es un software o lenguaje de programación, es un marco de trabajo conceptual para la integración de datos y la lógica de negocio de sistemas separados a nuevos componentes en forma de servicios. La orientación a servicios, igual que la orientación a procesos, requiere para poder tener éxito, que los analistas y desarrolladores software se orienten hacia esta mentalidad de crear servicios orquestados y un compromiso con el modelado y diseño para aplicaciones orientadas a servicios. SOA nos va a permitir agilidad en el sentido de que podemos cambiar nuestras aplicaciones e integraciones con otros sistemas de forma rápida sin necesidad de reprogramar nuestros aplicativos, sistemas EDI o Middleware, mejorando los tiempos en la realización de cambios en los procesos al poder sustituir las arquitecturas informáticas sin necesidad de cambiar los modelos de procesos, facilitarnos la evolución ordenada a nuevos modelos de negocio y arquitecturas informáticas y permitir la integración de nuestros sistemas y web services con proveedores, clientes y partner de negocio de forma clara y segura. La combinación de BPM y SOA resultará en una perfecta simbiosis entre los niveles más altos y centrados en el negocio y los más bajos, centrados en las implementaciones finales de TI. BPM permitirá el desarrollo y la automatización de los procesos de negocio, a través de la eficiencia y mejora de sus procesos, mientras que SOA, como nuevo paradigma para el desarro384


llo, paquetización, despliegue y consumo de funcionalidades TI, proporcionará los elementos clave para la transformación de las distintas aplicaciones existentes en las organizaciones y en TI (como por ejemplo, ERP, CRM y SCM), en servicios reutilizables, basados en estándares de integración, resultando la combinación en que los procesos de negocio podrán hacer uso (“consumir”) los servicios definidos en SOA. La sinergia entre BPM y SOA ayudará en gran medida a reducir la complejidad de las tecnologías de la información, acelerando la automatización de los procesos en las organizaciones y posibilitando un desarrollo más rápido de las aplicaciones de negocio, a la vez que contribuye a hacer los procesos de negocio más ágiles y flexibles. Aunque podamos enumerar las grandes ventajas que nos aportará SOA a la hora de proceder con nuestras integraciones, debemos tener en cuenta que será muy difícil implementarlas de golpe e incluso este no será el escenario ideal, sino que deberemos interiorizar esta nueva filosofía e implementarla a pasos, mientras hacemos nuestro camino en BPM y SOA. BPM y SOA son totalmente independientes, BPM no requiere SOA, pero si simplifica su implementación, sobre todo a la hora de conectar con aplicaciones y servicios propios y de terceros, proveyendo de mayor nivel de control y gobernanza sobre la infraestructura TI. Como dice Paul Harmmon, BPMS no necesita SOA pero SOA necesita BPMS, pues los servicios no tienen ningún sentido sin el contexto que ofrecen los procesos de negocio. Esto mismo puede ser de aplicación a la tan de moda “Cloud” de aplicaciones en la nube, donde estas aplicaciones necesitan de SOA para racionalizar sus operaciones y proveer de las demandas de flexibilidad y escalabilidad que estas demandan y poder aprovechar así todas las ventajas que estas aplicaciones en la “nube” ofrecen. BPM no es tecnología y hay muchas mejoras que se pueden alcanzar con BPM sin tecnología. Muchas organizaciones piensan que por adquirir un software de BPM ya tiene sus problemas solucionados. No repitamos errores como los descritos en la implementación de soluciones ERP, estas soluciones son herramientas tecnológicas, pero debemos recordar que BPM es en esencia el análisis y mejora de los procesos de negocio de la empresa que podrán o no ser implementados haciendo uso de la tecnología, pero no pongamos todas nuestra esperanzas en una herramienta tecnológica que no vaya dirigida por un proyecto de BPM que tenga en cuenta los procesos y sus posibilidades de mejora, las personas, que busque la implicación de la dirección, el liderazgo, la cultura y demás conceptos vistos en este libro. La 385


importancia de un proyecto de TI no se mide en función del precio pagado por la herramienta o el tamaño de la empresa a la que subcontratemos su implementación. A la hora de adquirir una solución BPM, los vendedores normalmente son empresas de software o tecnológicas y son ellos los primeros en decirnos que BPM es tecnología, pero no debemos olvidar exigirle su demostrada capacidad para ver el lado de negocio al considerar una implementación o estrategia de BPM y no sólo el lado tecnológico. Ya puestos, podemos exigir independencia tecnológica, que no estén atados a una determinada herramienta o tecnología que dirija sus análisis de negocio, pues en muchas ocasiones, podremos reutilizar nuestros actuales sistemas de TI para un proyecto de BPM o escoger nuevas plataformas más acordes a las necesidades y capacidades de nuestra empresa y que como hemos visto, no siempre tienen por qué incluir todos los módulos necesarios en un único paquete software.

La capa de procesos: Los BPMS incluyen una capa de procesos sobre la tradicional arquitectura en 3 capas, de forma que podemos separar las aplicaciones y sus datos de la gestión de los procesos pudiendo realizar modificaciones rápidamente y de forma económica sobre los procesos sin modificar las aplicaciones.

En la arquitectura en tres capas la integración con aplicaciones es realizada punto a punto, desarrollándose interfaces de comunicación para cada una de las necesidades de integración por lo que cuando precisamos de muchas integraciones, que suele este ser el caso de la mayoría de necesi386


dades de negocio actuales, esto se vuelve ingestionable, además de consumir una gran cantidad de recursos para las integraciones y su mantenimiento en cuanto a integridad de datos. Con la capa de procesos, podemos realizar estas integraciones en base al diseño de procesos modelado, pudiendo especificar por ejemplo una transacción en un aplicativo externo de la organización sin necesidad de desarrollar una interfaz de comunicación con él mismo, usando los conectores y adaptadores de que disponen los BPMS para estas integraciones con diferentes aplicaciones y fuentes de datos externas. Esta capa de procesos que separa los procesos de las aplicaciones, es la que permite a la gente de negocio participar en el desarrollo de aplicaciones software e integraciones, modelando ellos mismos los procesos de negocio con todo lo necesario para que estos funcionen y reduciendo el distanciamiento que comentábamos entre negocio y departamentos de TI, al tiempo que permite la mejora continua de los procesos y la simulación de los distintos escenarios para obtener medidas de comportamiento del proceso previamente a su implementación. Las arquitecturas de TI tradicionales disponen de tres capas: datos (bases de datos), aplicaciones (la lógica de proceso) y presentación (donde interactúa el usuario). En la estructura de 4 capas, la capa de procesos se sitúa entre la de presentación y la de aplicaciones. En la de 3 capas, la interacción entre el usuario y las aplicaciones es realizada punto a punto. Cuando una aplicación necesita datos de otra aplicación, se crea una nueva interfaz para transferir esos datos. Según va creciendo el negocio y los requisitos de información, las aplicaciones tienen que ser modificadas y se crean nuevas aplicaciones, por lo que el número de interfaces de presentación crece exponencialmente, surgiendo muchos problemas de sostenibilidad de estas aplicaciones punto a punto, pues requieren de un ejército de programadores para mantenerlas y unos altos costes de mantenimiento.

Gestión de casos En los últimos años se ha desarrollado y discutido en muchos foros de internet sobre la gestión de casos como alternativa a la gestión por procesos o como nueva perspectiva sobre la mirar estos proyectos, por lo que no quisiera dejar este capítulo sin comentar esta visión.

387


Un “caso”, al igual que los procesos, consiste en un conjunto de actividades, pero donde no existe un flujo secuencial entre estas actividades, pues este flujo viene determinado por cada caso, o por las decisiones que tomen los encargados de realizar las actividades, y es por ello que hablamos de Gestión Dinámica de Casos (Dynamic Case Management) o de Adaptive Case Management. Los Casos son en consecuencia asuntos puntuales a resolver en una organización en un determinado periodo de tiempo, que provienen de solicitudes (internas o externas): incidencias, peticiones, solicitudes de compra, etc. En BPM y en los procesos de negocio existe un flujo o modelo predefinido de comportamiento del proceso de principio a fin, pero en la gestión de casos, desaparece esta ruta, la cual seguirá las directrices de decisiones tomadas en el transcurso del proceso por personal experto o eventos, tanto internos como externos, que puedan acontecer durante su desarrollo y que determinarán en tiempo de ejecución las actividades que se deben desarrollar y almacenando y documentando toda la información referente al caso. El modelo genérico de BPMS que hemos visto en este capítulo, puede comportarse perfectamente para realizar la gestión de casos, pues al final, el comportamiento del proceso dependerá de la intervención de distintos usuarios a través de los formularios y sistemas con los que se integre el proceso, por lo que lo que no existe tal rigidez en BPM como para impedir la gestión de casos, sin embargo, para completar algunas funcionalidades de esta gestión de casos, en especial la asociada a la documentación de los mismos, que es donde se centra la gestión de casos, algunos BPMS contemplan ya este tipo de gestión a través de la capacidad de un proceso de irse configurando en torno a un caso específico. Un aspecto concerniente a la gestión de casos es que un simple caso puede involucrar a varios procesos, por lo que los BPMS deberán ser capaces desviar la corriente de unos procesos a otros.

388


389


Bibliografía Libros: Addy, Rob. Effective IT Service Management – to ITIL and Beyond! Springer, 2007. Age, Susan, The Power of Business Improvement, 2010, ISBN-13: 978-08144-1478-1 Boar, Bernard H. Practical Steps for Aligning Information Technology with Business Strategies. Wiley, 1994. Bridgeland, David & Zahavi, Ron. Business Modeling: A Practical Guide to Realizing Business Value.- MK/OMG Press, 2008. Champy, James. Reengineering Management: The Mandate for New Leadership. Harper Business Book, 1995. Chang, James F. Business Process Management Systems- Auerbach, 2006. ISBN-10: 084932310X Chopra, Sunil and Peter Meindl. Supply Chain Management: Strategy, Planning and Operations. Prentice Hall College Division, 2000. Cummins, Fred. Building the Agile Enterprise with SOA, BPM, and MBM Morgan Kaufmann/OMG Press, 2009 Curtis, Bill, William E. Hefley and Sally A. Miller. The People Capability Maturity Model: Guidelines for Improving the Workforce. AddisonWesley, 2002. Damelio, Robert. The Basics of Process Mapping. 1996, ISBN 0-527-76316-0 Davenport, Thomas. Process Innovation: Reengineering Work through Information Technology. H. Harvard Business School Press, 1993. 390

Bibliografía

Davenport, Thomas H. Mission Critical: Realizing the Promise of Enterprise Systems. Harvard Business School Press, 2000. Debevoise, Tom. Business Process Management with a Business Rules Approach, 2007. ISBN 978-1-4196-7368-9 Debevoise, Tom & Geneva, Rick. The Microguide to Process Modeling in BPMN - Tipping Point, 2008 Eckes, George The Six Sigma Revolution: How General Electric and Others Turned Process into Profits. John Wiley. 2001. Fischer, Layna (Ed.). The Workflow Paradigm: The Impact of Information Technology on Business Process Reengineering (2nd Ed.). Future Strategies Book, 1995. Grover, Varun and William J. Kettinger. Business Process Change: Reengineering Concepts, Methods and Technologies. Idea Group Publishing, 1995. Hammer, Michael & Champy, James. Reengineering the Corporation: A Manifesto for Business Revolution. Harper Business Book, 1993. Hammer, Michael. Beyond Reengineering: How the Process-Centered Organization Is Changing Our Work and Our Lives. HarperBusiness, 1997. Harmon, Paul. Business Process Change: A Manager's Guide to Improving, Redesigning and Automating Processes. Morgan-Kaufmann. Harmon, Paul. Business Process Change, Second Edition - Morgan Kaufman, 2007. Harrington, H. James. Business Process Improvement: The breakthrough Strategy for Total Quality, Productivity, and Competitiveness. McGraw-Hill, 1991 Hiatt, Jeffrey and Creasey, Timothy. Change Management: The People Side of Change - Prosci, 2003. Jeston, John & Nelis, Johan. Business Process Management Practical Guidelines to Successful Implementations, Second Edition Elsevier, 2008. Johansson, Henry J., Patrick McHugh, A. John Pendlebury and William A. Wheeler III. Business Process Reengineering: Breakpoint Strategies for Market Dominance. Wiley, 1993. Kaplan, Robert S. & Norton, David P. The Balanced Scorecard: Translating Strategy into Action - Harvard Business School Press, 1996. ISBN10: 0875846513 Keller, Paul, Six Sigma DeMYSTiFieD. ISBN 0-07-144544-7 Kubeck, Lynn C. Techniques for Business Process Redesign: Tying It All Together. Wiley-QED Publichation, 1995.


Morgan, Tony. Business Rules and Information Systems: Aligning IT with Business Goals. Addison-Wesley, 2002. Ould, Martyn. Business Process Management: A Rigorous Approach Meghan-Kiffer, 2005. ISBN-10: 0929652274 Osterwalder, Alexander & Pigneur, Yves. Business Model Generation. Wiley, 2010. ISBN: 978-0470876411 Parmenter, David. Key Performance Indicators: Developing, Implementing,and Using Winning KPIs. Wiley, 2007 Paulk, Mark C., Charles V. Weber, Bill Curtis and Mary Beth Chrissis (Principal contributors and Editors). The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, 1995. Porter, Michael E. Competitive Advantage: Creating and Sustaining Superior Performance. Free Press, 1985. Project Management Institute. A Guide to the Project Management Body of Knowledge, Fourth Edition (PMBOK Guides), 2008. Rosen, Michael. Applied SOA: Service-Oriented Architecture and Design Strategies - Wiley, 2008 Ross, Ronald. Principles of the Business Rule Approach - Pearson, 2003. Ross, Jeanne W. et al Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. - Harvard Business School Press, 2006 Ross, Ronald. Business Rule Concepts: Getting to the Point of Knowledge, 2nd edition - BRF, 2005. Rummler, Geary & Alan Brache. Improving Performance: How to Manage the White Space on the Organization Chart. (2nd Ed.). Jossey-Bass, 1990. Sayer, Natalie & Williams, Bruce. LEAN for Dummies. - Wiley, 2007 Senge, Peter M. The Fifth Discipline: The Art & Practice of the Learning Organization. Currency Doubleday, 1994. Smith, Howard & Fingar, Peter. Business Process Management: The Third Wave, Fourth Anniversary Edition - Meghan-Kiffer, 2007. ISBN-10: 0929652347

392

Bibliografía

Especificaciones de OMG: Todas estas especificaciones podemos descargarlas en la página de OMG (Object Management Group) en: www.omg.org. -

Business Process Maturity Model (BMM) Specification, V1.0 Business Motivation Model (BMM) Specification, V 1.0 Business Process Model Notation (BPMN), V1.1 Organization Structure Metamodel Specification Draft Business Process Definition Metamodel specification, Beta 2 Semantics of Business Vocabulary and Business Rules Specification (SBVR), V1.0. Web Services Choreography Description Language Version 1.0.

Otros Frameworks y especificaciones: Realizando una simple búsqueda en Google, podemos acceder también a la consulta o descarga de distintos estándares y frameworks: -

APQC Process Classification Framework, V 5.0.3 eTOM Supply Chain Council's Supply-Chain Operations Reference model (SCOR), v9.0 Introduction to the Value Reference Model (VRM) SOA Consortium case studies.

LibroBPM Sergio

Recommend Documents