IX Congreso Anual BPM2014 en Madrid y Barcelona.

Los próximos días 13 de Marzo en Barcelona y 25 de Marzo en Madrid, estaré presente como ponente en el congreso anual de BPM en España. Más información y agenda del evento en: http://www.club-bpm.com/BPM2014/agenda.html

Encuesta necesidades formativas en BPM

Estamos realizando un estudio sobre necesidades formativas en el área de BPM. Te agradeceríamos si puedes ayudarnos participando en la siguiente encuesta (son 15 segundos):

Enlace Permanente:
http://bpmwasabi.blogspot.com.es/p/encuesta-formacion.html

BPMN es ahora un estándar ISO.

La versión 2.0.1 de BPMN (Business Process Management Notation) desarrollada por el Object Management Group (OMG), ha sido publicada como estándar ISO/IEC 19510.2013.

Para los que conozcáis esta importante notación para el diseño y modelado de procesos, os dejo los enlaces a la especificación en la página de ISO y la especificación del OMG, aunque ambas son idénticas.

Aunque la especificación ocupa más de 500 páginas, podéis consultar algunos de nuestros cursos (ahora tenemos un curso online en TalentLMS de introducción a BPM) o solicitar uno específico sobre BPMN.

Debates sobre BPM en www.bpm.com

Esta semana me han invitado a participar en los debates sobre BPM en www.bpm.com. Os recomiendo a todos aquellos interesados en esta metodología, el que os deis un paseo por las preguntas que semanalmente propone Peter Schooff, editor de esta web, y en los que intervienen todos los expertos en BPM que siguen vivos y de los que yo tanto he aprendido.

Mi última participación ha sido en este debate sobre el momento en que se encuentra BPM en su ya larga historia:visitar discusión en BPM.com

Modelado en BPMN de proceso para gestión de tareas según sistema GTD (Getting Things Done).

He bocetado este proceso y comenzado a implementarlo porque con ello junto dos de los mundos en los que más trabajo: el de BPM y el del sistema GTD para la gestión de mis tareas. Ha sido un ejercicio divertido, pues además de refrescar mis conocimientos de GTD y de BPMN, me he dado cuenta de que estaba dentro de un bucle, el de usar una herramienta BPMS utilizada para gestionar y controlar el flujo de tareas de un proceso, para implementar un proceso de gestión de tareas.

El Proceso es el siguiente:

La imagen del modelo puedes descargarla aquí.
Si queréis llevar el modelo a algún modelador de procesos o BPMS, el XPDL puedes descargarlo aquí.

Este modelo es algo vivo, que tiene todavía muchas carencias y posibilidades de mejora, por lo que agradezco cualquier aportación, comentario o sugerencia sobre este proceso, tanto sobre su diseño en BPMN o sobre como aplicar el método GTD. Espero vuestros comentarios.

También podéis colaborar con el modelo en ProcessON:

Curso certificado de introducción a BPM

Curso Introducción a BPM.

Modalidad: online (TalentLMS).

Examen de certificación de BPM wasabi.

Precio 30,00 €
El pago es por paypal, pero si alguno desea otra forma de pago, puede ponerse en contacto conmigo: josepaiscurto@gmail.com

http://bpmwasabi.talentlms.com/catalog

Pensar primero, automatizar después.

Continuando con el post anterior "BPM. Reducir el "Gap" ente negocio y tecnología", en el que hablábamos de la necesidad de alinear negocio y tecnología...

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. 

En los proyectos de BPM reconocemos que la tecnología por sí sola no implica la mejora de la gestión empresarial, de la gestión de procesos de negocio, la competitividad o de los resultados empresariales, por lo que 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). 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. Esto implica que la tecnología será imprescindible para BPM (hoy ningún negocio se concibe sin esta) y sin ella no podrá realizarse BPM, pero podemos afirmar que un proyecto BPM es un 60% estrategia y un 40% tecnología.

BPM. Reducir el “Gap” entre negocio y tecnología.

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 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 Peter Fingar explicó en un artículo posterior, es que eliminemos el puente que divide el negocio y las TI.

El reducir este "Gap" entre negocio y TI será uno de los beneficios más destacadas que encontraremos en nuestros proyectos de BPM (Business Process Management).

La división entre los departamentos de negocio y TI ha prevalecido desde las primeras implantaciones informáticas hasta nuestros días. Las 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 alinearse, 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 requiere y como las TI implementan lo que el negocio necesita.

Esta situación es similar a la conocida en el mundo del desarrollo software en la toma de requisitos y que ilustro en la siguiente imagen, 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, re-especificaciones y retrasos provocan en los proyectos de software.

En el libro de Peter Fingar, este se refiere a los programadores, que haciendo uso de lenguajes no entendibles por el personal de negocio (como Cobol, C++, Java o UML) como situados en 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 sí se puede hacer y recomendaban apartar a estos profesionales de TI de las primeras fases en el diseño de los 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 automatizació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. 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 de 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.

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 este 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”.

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 requerimientos de negocio, es como decimos una de las principales que nos proporcionará la metodología de BPM, poniendo al personal de negocio y de TI a analizar, diseñar, implementar y monitorear conjuntamente los procesos de negocio, haciendo uso de la metodología de BPM, de sus herramientas de modelado y de la notación BPMN (Business Process Management Notation), 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: Business Process Management Systems). 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.

Lecturas recomendadas:

El libro de Peter Fingar y Howard Smith: http://www.amazon.com/Business-Process-Management-Third-Wave/dp/0929652347

El artículo de Peter Fingar: “Systems Thinking: The "Core" Core Competency for BPM”: http://www.bptrends.com/publicationfiles/09-05%20ART%20Systems%20Thinking%20-%20Fingar.pdf

BPM y Scrum

A la hora de abordar proyectos de TI, solemos encontrarnos con clientes que tienen una idea clara de qué hacer y de cómo hacerlo, del modelo de negocio que quieren lanzar, pero que necesitan verlo ¡YA! y no disponen todavía en las fases iniciales del proyecto de la capacidad de detallar el producto final, prefiriendo bajar a estos niveles de detalle en tiempo de desarrollo, al tiempo que ven el producto en entregas breves y funcionales.

Es la “Ley de Humphrey”, según la cual, los clientes no saben lo que quieren hasta que ven el software que funciona. O sea, demasiado tarde, y esta situación se repite también cuando trabajamos en mejora de procesos o sobre proyectos de BPM (Business Process Management) ya implementados.

La realidad de la gestión por procesos y de los proyectos de BPM, es que los procesos no pueden ser considerados como algo estático e inamovible, pues estos siempre están vivos, sea por los cambios en el entorno organizacional o por el trabajo de mejora continua que realicemos sobre los procesos ya implementados. El entorno de las organizaciones cambia, las estrategias cambian y los procesos en consecuencia también cambian, y las empresas quieren aprovechar las capacidades de cambio de BPM o de las plataformas BPMS, por lo que trabajan más intensivamente en reajustar sus procesos en ciclos de optimización y mejora cada vez más cortos.

A la hora de gestionar estos proyectos de software o de mejora de procesos, el problema que nos encontramos con la gestión de proyectos tradicional y su necesaria fase inicial de planificación, es que trata el proyecto como una actividad predecible, cuando la realidad de muchos de estos proyectos es que no lo es, debido principalmente a componentes asociados tanto al desarrollo software como al de mejora de procesos, como son la innovación y la creatividad, debidos a un trabajo conjunto del equipo de desarrollo con los stakeholders, y que hacen que este proceso productivo, no pueda ser fácilmente predecible y estimado de forma precisa, por lo que estos proyectos necesitan de menos planificación, al no poder contar con un análisis y diseño inicial perfectamente especificado y donde además, los requerimientos de clientes son cambiantes, dificultando todavía más la tarea de poder predecir cual será el resultado final exacto del proyecto software o de mejora de procesos.

Es en este entorno en el que conceptos como Lean, Kaizen y las Metodologías Ágiles, encajan perfectamente con esta filosofía de producir valor en lotes pequeños, agregando funcionalidades de forma incremental y no en una sola entrega final previamente planificada, cuya implementación, difícilmente se ajustará a esa planificación inicial.

Una de las metodologías ágiles, utilizada ampliamente para el desarrollo software y que puede ser de utilidad para los proyectos de BPM es SCRUM, cuyos principios fundamentales son:

• A los individuos y su interacción, por encima de los procesos y las herramientas.
• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimiento de un plan.

Estos principios encajan perfectamente con la metodología de BPM, donde los principios de mejora continua, flexibilidad y adaptación al cambio de BPM, precisan del equipo involucrado en el proyecto de una visión compartida hacia la que dirigirse, como si de un equipo de Rugby se tratase, avanzando de forma conjunta, colaborativa y cohesionadamente, hacia los objetivos pretendidos con el proyecto y no tanto de un control y planificación predictiva, a partir de una especificación detallado de los requisitos finales del proyecto y de los procesos, que pueden cambiar y evolucionar durante el transcurso del proyecto.

Una aproximación a este tipo de metodologías ágiles proporcionará a nuestros proyectos de BPM:

• Adaptabilidad, orientación al cliente, rapidez y agilidad.
• Realizar entregas rápidas en forma de procesos clave implementados. Las entregas funcionales, iterativas e incrementales, realizadas a través de sucesivas interacciones (“Sprints” de Scrum), y que son mostradas al cliente para su valoración, hasta que este da por cerrado el producto, encajan perfectamente dentro de la filosofía de BPM de impulsar la eficiencia en los procesos de la organización, dividiendo los proyectos en partes más pequeñas y priorizando las partes de mayor importancia para el negocio y el ROI del proyecto, en lugar de abordarlo desde la perspectiva de la reingeniería de procesos (BPR) de abandonar el trabajo de mejora de procesos, romper con todo y buscar un cambio radical.
• Mayor innovación y satisfacción del cliente, al recibir este entregas funcionales en periodos cortos de tiempo y poder proponer ideas y cambios sobre el proyecto en tiempo de desarrollo y no poner un muro infranqueable para estos cambios para la protección del proyecto, como sucede con las metodologías de gestión de proyectos tradicionales. En Scrum esto se realiza a través de la Pila de Producto (Product Backlog), como un documento vivo de los requisitos del cliente que evoluciona y crece continuamente, y sobre la cual vamos añadiendo los cambios solicitados que serán implementados en los siguientes Sprints, mediante la adaptación continua a las circunstancias del proyecto.
• Trabajar en la mejora continua de los procesos de negocio, ajustando el proyecto cuando sea necesario y no pretendiendo una entrega completa y final del mismo en base a una exhaustiva planificación.
• El centrarse en las personas y confiar la calidad del resultado al conocimiento explícito de estas sobre los diferentes aspectos del proyecto o del producto, al tiempo que mejoramos el comportamiento y motivación del equipo de desarrollo y reforzamos la necesaria colaboración en el proyecto entre gente de negocio y gente de TI tan fundamental en los proyectos de BPM.
• Ayudarnos a responder de forma más eficiente a las necesidades de cambio continuo, al poder aceptar e integrar los cambios que aparecerán, tanto trabajando en la mejora de los procesos como los que surjan durante la fase de implementación, pues los procesos cambian continuamente del As-Is al To-Be y los requisitos son cambiantes a medida que automatizamos y mejoramos los procesos.
• Permitir las revisiones durante todo el ciclo de vida del proyecto y no sólo a la finalización del mismo, acortando la brecha entre las expectativas del cliente y lo que este realmente necesita.

Necesidad de formación en TI para perfiles de negocio.

Todo el mundo afirma que en los negocios de hoy en día, nada se puede hacer sin tecnología, pero son muy pocos los perfiles de negocio que comprenden lo que es e implica un proyecto o implementación tecnológica, dirigiendo la subcontratación de estos proyectos como si de de la obra del nuevo local que van a abrir se tratase.

Hoy también, todos los clientes parecen conocer y ser unos expertos para el lanzamiento de proyectos de TI, pero desde una perspectiva de usuarios, explicando su proyecto como: una plataforma web "como la de bookings",  "como la de infojobs" o "parecida a facebook, pero más pequeña", con un total desconocimiento por su parte del proceso de producción software y de las dimensiones de este tipo de proyectos en cuanto a Alcance, Tiempo, Costes, Calidad y Riegos y pretendiendo los mismos en el menor tiempo y al mínimo coste.

Con el sector de la automoción, por ejemplo, todo el mundo sabe conducir, sin embargo nadie se plantea hacer un coche ni opinar tan libremente sobre la mejor configuración de motor que mejor se ajuste a sus necesidades. Sin embargo, con la industria de TI, tal vez por saber que con un simple ordenador (del que todo el mundo dispone), se puede hacer cualquier tipo de software, o porque todos podemos descargarnos apps para nuestro teléfono móvil y utilizar todo tipo de plataformas en internet, nos consideramos también capaces de diseñar y gestionar la producción de cualquier desarrollo software, viéndolo como algo totalmente factible y hasta trivial, pero sin pasar nunca del perfil de usuarios al de desarrolladores!

Esta falta de formación en tecnología (más allá del nivel de usuarios), es la causa del fracaso de muchos proyectos en los que el cliente, con una dependencia cada vez más elevada de la herramienta tecnológica para el lanzamiento de sus proyectos y partiendo de unas expectativas (que no de requerimientos de TI claros), subestima tanto la complejidad como la carga de trabajo y los costes asociados a esa parte del proyecto, y produciendo frustración, tanto en el propio cliente como en el equipo de desarrollo. Esta situación es la que me encuentro muchas veces, sobre todo en emprendedores, con modelos de negocio totalmente basados en internet o plataformas software, y en los que las empresas o equipos de desarrollo software son vistos como "commodities" de usar y tirar, tras extraer de ellos todo su jugo y que lleva a los clientes a vagar de subcontrata en subcontrata, en busca del comercial que comprenda su situación, sin darse cuenta de que a ese comercial, con esos antecedentes del cliente, ya le tiemblan las piernas.

No me refiero con ello a tener que conocer lenguajes de programación para revisar el código o algoritmos del desarrollo, o a conocer los fundamentos de bases de datos, arquitecturas o herramientas de modelado software, pero los perfiles de negocio (los MBA´s, emprendedores y en general cualquier perfil de negocio hoy en día),  cuando menos debería acercarse a conocer las metodologías de gestión de proyectos software y de TI, para disponer de una aproximación a la realidad de estos proyectos, y dentro de estas, vaya mi recomendación por las metodologías ágiles como Scrum o Extreme Programming, capaces de proporcionar de forma rápida una comprensión de las particularidades de estos proyectos y de cómo gestionar los mismos, muy diferente al de las metodologías tradicionales como la del PMI (Project Management Institute) válida para todo tipo de proyectos.