lunes, 11 de noviembre de 2013

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

miércoles, 6 de noviembre de 2013

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.









miércoles, 2 de octubre de 2013

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

viernes, 27 de septiembre de 2013

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:
BPMN-GTD

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:

jueves, 19 de septiembre de 2013

Curso certificado de 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

miércoles, 18 de septiembre de 2013

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.

martes, 17 de septiembre de 2013

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 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

martes, 10 de septiembre de 2013

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.

martes, 3 de septiembre de 2013

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.

viernes, 30 de agosto de 2013

Process Live Beta Tester.

I have been selected as a beta tester for #SoftwareAG #ProcessLive. The 1st #BPM Business Process improvement in the #Cloud. I will keep you updated on my progress in http://bpmwasabi.blogspot.com



jueves, 20 de junio de 2013

Entrevista a Juan Pardo sobre el curso de BPM en la Univ. de Vigo

Entrevista a Juan Pardo, del Grupo de Investigación OSIG de la Escuela de Ingenieros Industriales de la Universidad de Vigo, que pone en marcha este año un Curso sobre BPM en su Escuela.


Universidad de Vigo. Escuela de Ingeniería Industrial:
Curso: MODELADO Y SIMULACIÓN DE PROCESOS DE NEGOCIO MEDIANTE HERRAMIENTAS BPM.
Modalidad: Presencial.

Duración: 40 horas.
Período de preinscrición 01/02/2013 00:00 - 08/07/2013 23:59
Período de matrícula 08/02/2013 00:00 - 08/07/2013 23:59
Período de docencia 15/07/2013 - 24/07/2013

Precio: 165,00 €

lunes, 13 de mayo de 2013

Orquestación de TOC (Theory of Constraints), Lean y Six Sigma con BPM.

Libro del BPM 2013
Acabamos de publicar un capítulo en el Libro del BPM 2013, un compendio de 9 capítulos escritos por pioneros y expertos en BPM y sus tecnologías y editado por Club BPM.

Este trabajo analiza tres de las principales metodologías más empleadas para la mejora de procesos como son TOC (Theory of Constraints), Lean y Six Sigma (TLS) y la integración de estas dentro del ciclo de vida de un proyecto de BPM (Business Process Management).

La mejora de procesos es una parte fundamental del ciclo de vida de BPM en la que las metodologías de TOC, Lean y Six Sigma aportan importantes prácticas, herramientas y conocimientos en las tareas de identificación, descripción, análisis y mejora de procesos. Al mismo tiempo, estas metodologías pueden beneficiarse de las capacidades de BPM para gestionar, monitorizar y automatizar las acciones y prácticas que estas desarrollan, haciéndolas más rápidas y ágiles, y aprovechando las sinergias entre estas teorías y BPM, para integrar y unificar los esfuerzos en mejora de procesos y conseguir de forma coordinada que todas ellas sean más eficientes participando del mismo ciclo de mejora continua.

Los contenidos del Libro de BPM 2013 son:
  • BPM Inteligente y Social. Por Jay Lillie, TIBCO Product Marketing
  • BPM y BRM a la hora del SocialWorld. Por Eduardo Izquierdo y Marie Claude Belda, IBM España
  • Cómo empezar con BPM: desarrollar las Iniciativas de Procesos y superarlos obstáculos para el éxito. Por Software AG
  • Los dispositivos móviles en BPM. Por Pablo Trilles Farrington, Vicepresidente de AuraPortal
  • Orquestación de TOC (Theory of Constraints), Lean y Six Sigma con BPM (Business Process Management). Por José Ramón Pais Curto, Autor del Libro BPM (Business Process Management)
  • La Gestión de Procesos integrada con GIS. Por Eliseo Martín Castro,  Responsable técnico de soporte a canal. Cibernos
  • La Inteligencia Operacional para la optimización de Smart Grids en Operadoras de Energía. Por Juan C. Palacios, Vitria Technology Inc
  • Análisis y Prospectiva del Mercado BPM a 5 Años. Por Josep Mª Cos, Director General de proceedit, “The BPM Process Factory”
  •  Situación actual BPMy la evolución de la Gestión por Procesos. Por Pedro Robledo, Director Ejecutivo de Club-BPM
El libro se puede adquirir en: http://www.club-bpm.com/Libro-del-BPM-2013.htm

jueves, 9 de mayo de 2013

Congreso BPM 2013 en Madrid.

Magnífico el congreso al que he asistido hoy de BPM. La organización, la calidad y variedad de ponentes para aportar diferentes perspectivas y el networking provocado a lo largo de toda la jornada.

martes, 7 de mayo de 2013

BPM y SOA. El ojo y la vista.


Tomo esta metáfora de Aristóteles para explicar la necesaria unión entre BPM (Business Process Management) y SOA (Service Oriented Architecture) en cualquier proyecto de BPM en el que la infraestructura informática sea medianamente compleja y se requiera de su racionalización para dar soporte a los procesos y objetivos de la empresa.

Aunque los conceptos de BPM y SOA pertenezcan a dos ámbitos bien distintos, estos no son antagónicos, ni su unión es accidental y más bien, están perfectamente adaptados el uno al otro de forma que los procesos de negocio que finalmente ejecute nuestra organización, sólo funcionarán bien, si la tecnología que les da soporte (al igual que las personas y los recursos que empleemos en el proceso), funciona bien, por lo que ambos se encuentran en una situación de influencia mutua y recíproca para alcanzar un fin concreto, que no es otro que alcanzar los objetivos y metas empresariales.

Aristóteles, para describir la relación de dependencia y unión entre cuerpo y alma (materia y forma) y cómo estas dan lugar a una sola sustancia, recurrió a la metáfora del "ojo y la vista", donde la vista no es posible sin el ojo, y el ojo sin vista no tendría razón de ser.

De igual manera, SOA sin BPM sólo sería tecnología; sin sentido o fin en si mismo y falta de toda orientación a los aspectos de negocio y por otra parte, BPM sin SOA resultaría en un esfuerzo demasiado laborioso y costoso de mantener, pues sin esta arquitectura, no alcanzaríamos la flexibilidad necesaria para el buen funcionamiento de nuestros procesos en un entorno como el actual: con diversidad de aplicativos y sistemas legacy, con múltiples partners, clientes y proveedores con los que interactuar y donde la interoperabilidad es un imperativo para afrontar los cambios y requerimientos de negocio.

¿Es posible implementar BPM sin SOA?, desde luego que si, ya que BPM incluye la gestión por procesos, las personas y la tecnología como sus tres pilares fundamentales, y en muchos casos será suficiente, pero las arquitecturas SOA se nos presentan como el principal aliado tecnológico para ayudarnos a implementar BPM, a racionalizar, como decíamos, la infraestructura tecnológica desde la misma concepción y diseño de la misma y aprovechar las sinergias entre ambas para lograr el mejor de los resultados posibles.

¿Quién utiliza BPM?

Suelo decir que la idea de tomar el control de las actividades empresariales a través de la gestión de los procesos que estas ejecutan para implementar sus estrategias y alcanzar sus objetivos de negocio, no es algo nuevo, y prácticamente todas las organizaciones, consciente o o inconscientemente, hacen uso de este "pensamiento".

Sin embargo, cada vez más, y debido al entrono cada vez más cambiante en el que se mueven las organizaciones hoy en día, los procesos han ido adquiriendo mayor relevancia como disciplina a través de la cual gestionar la complejidad, hasta llegar a lo que actualmente es BPM como metodología.

En España, son muchas las empresas y organismos públicos que han abrazado esta metodología. Principalmente los sectores de Banca, Seguros y Telcos, pero también hospitales, consultoras, retail y organismos públicos de toda índole, cuyos resultados están directamente relacionados con una correcta definición, gestión y control de sus procesos de negocio. Pero por expandir todavía más la información sobre quien usa BPM, y por que es algo que siempre me pregunta, podemos nombrar a empresas como: Apple, Google, Samsung, BMW, Bentley, Amazon, Zara, Zappos, Jaguar-Land Rover, Emirates, McDonalds, Coca-Cola, Soutwest Airlines, State Farm, Fedex Office o Singapore Airlines.

miércoles, 24 de abril de 2013

Reseña de nuestro libro de BPM en BPM-Spain.com


BPMteca.com celebra el Día del Libro con una nueva publicación digital sobre la Gestión por Procesos en español. El libro del profesor y consultor José Ramón Pais se titula BPM (Business Process Management), Cómo alcanzar la agilidad y eficiencia operacional a través de BPM y la empresa orientada a procesos.

Ver la reseña de la redacción de BPM-Spain.com

jueves, 18 de abril de 2013

BPM en Administraciones Públicas


Con BPM a mi me ocurre como a aquel que tiene un martillo y ve clavos por todas partes. Pero desde hace meses, en todos los periódicos que leo, siempre hay alguna noticia que me conciencia más de la necesidad de una metodología como la de BPM en las distintas Administraciones Públicas.

Cada vez se habla en prensa con mayor fuerza sobre la necesidad de reforma en el sector público por las duplicidades en las administraciones y sobrecostes que se producen en las distintas instituciones que componen el universo de la función pública: parlamentos, consejos asesores, universidades, observatorios aeropuertos, televisiones autonómicas, coches oficiales, embajadas, etc. y que además de el sobredimensionamiento de muchos de estos organismos, del solapamiento de políticas (sociales, de emprendimiento, de transporte, etc.) y de las ineficiencias que provocan y que han salido a la luz a consecuencia de la crisis, se calcula que cuestan la friolera cifra de un 3% del PIB.

La búsqueda de la eficiencia en los servicios públicos se está convirtiendo en una cuestión crítica para la sostenibilidad del sistema, y conscientes de ello, la propia Administración comienza a realizar planes de reestructuración para corregir esta situación y las pérdidas económicas que provoca, creando planes de choque que puedan poner coto a un sistema insostenible por mucho más tiempo.

Pero si bien es cierto que existe un sobrecoste debido al solapamiento de funciones en nuestro modelo autonómico, desde mi perspectiva como analista de procesos, las noticias que leo y que más llaman mi atención, son aquellas más relacionadas con los desperdicios, la mala gestión de los recursos públicos y las ineficiencias en la gestión de los procesos de negocio de los servicios públicos.

Los procesos de negocio en este caso son los procesos burocráticos y lo trámites públicos que realizan las Administraciones para prestar el servicio a sus ciudadanos/clientes. Bajo la visión de BPM, la Administración Pública debe ver al ciudadano como un consumidor de servicios, cada vez más exigente, que considera que el servicio público debe ser ágil, que debe responder al tipo de servicio que solicita y no a la estructura particular del ente u organismo que lo presta. Un ciudadano/cliente que ve las gestiones con la Administración como un servicio que paga, y que en consecuencia, el prestador de servicios, la Administración, deberá tomar una orientación como un proveedor de servicios, con unos recursos, que al igual que muchos otros sistemas, son cada vez más escasos, por lo que tendrán que ser optimizados para poder hacer más con menos y donde los procesos administrativos y trámites burocráticos, tanto internos como externos, no sólo se evalúan para ver que cumplan con la ley, sino que son vistos como un proceso de negocio, el cual deberemos ser capaces de modelar, gestionar, simular, mejorar en su comportamiento y eficiencia, controlar y monitorizar.

BPM por sus siglas en ingles (Business Process Management), se refiere a la Gestión por Procesos de Negocios y a todas las actividades o tareas que en dichos procesos se realizan. BPM engloba a todas los procesos que son parte del ciclo de vida de un servicio público, y de forma automática e integrada, permite la Modelización, Ejecución, Monitorización y Optimización permanente de dicho ciclo.
BPM y los BPMS (Business Process Management Systems) recogerá distintas teorías de management (TQM, Six Sigma, Lean, Reingeniería de Procesos, etc) y evoluciones tecnológicas como los sistemas de workflow, un estándar para el diseño y modelado de procesos de negocio (BPMN: Busiess Process Modeling Notation), capacidades de integrar en los procesos personas y sistemas a través de herramientas de ETL y web services, herramientas y técnicas para la simulación del comportamiento de los procesos, su gobernanza y control y la monitorización en tiempo real de los mismos con herramientas de BAM (Business Activity Monitoring). Todas estas metodologías, técnicas y herramientas, además de distintos frameworks, estándares y modelos de referencia (SCOR, COBIT, TOGAF…), conformarán una metodología unificada y una serie de soluciones tecnológicas (los BPMS), que nos permitirán, siguiendo el ciclo de vida de BPM:

  • Diseñar, implementar y realizar el diseño y seguimiento de las operaciones y procesos de negocio.
  • Garantizar las satisfacción de los ciudadanos y simultáneamente el rendimiento del ente público.
  • Comprender mejor el origen de las ineficiencias, los riesgos operativos, tiempos muertos, sobrecostes y problemas en los distintos procedimientos y procesos.
  • Ser más flexibles, eficientes y poder adaptar los procesos administrativos a las necesidades cambiantes del entorno en el que desarrollan su actividad.

Pero implementar BPM no es siempre fácil y este artículo bien podría haberse titulado: “Porque es difícil implementar BPM en la Administración”. BPM no es sólo una metodología con unas capacidades y herramientas tecnológicas para ejecutar una estrategia, sino también una filosofía de gestión que, tomando como eje los procesos, plantea gestionar, mejorar y medir los resultados de los procesos para retomar el control de los mismos y poder trabajar en su mejora continua. BPM implicará en muchos casos un cambio de paradigma que comienza con el de la organización orientada a procesos (que en muchos casos trastocará las estructuras organizacionales) y el reconocimiento de los procesos como los activos principales de la administración para ejecutar su estrategia y alcanzar los objetivos deseados.

Para poder avanzar en la implementación de una gestión por procesos efectiva en la Administración Pública, será por ello necesario abrazar distintas prácticas y cambios de paradigma, entre los que se incluirán necesariamente:

  • La orientación al cliente, el valor que aportan los procesos actuales al ciudadano y lo que implica ser un servicio público para tomar una perspectiva desde quien recibe los servicios, el ciudadano y no de quien los presta, la Administración.
  • Repensar las estructuras funcionales y departamentales, el grado de colaboración entre distintas administraciones y evaluar el grado de cobertura que estas estructuras funcionales dan a los procesos transversales que se inician y finalizan en el ciudadano u otro organismo.
  • El compromiso con la innovación en procesos y en modelo de negocio y organizativos, basados en las necesidades de los ciudadanos y en las características propias del ente que los presta y no en copiar modelos de otros organismos y lugares alejados de la realidad.
  • Medir los resultados en base al conocimiento, la eficiencia y las mejoras proporcionadas en las salidas de los procesos y no sólo las subvenciones o financiación alcanzada.
  • Eliminar la burocracia en la medida de los posible, respetando pero también revisando cuando sea necesario las normas, regulaciones, legislaciones y reglas de negocio que deben cumplir los procesos. 
  • Revisar los flujos de información, en especial los que atraviesan los distintos departamentos y organismos, las duplicidades de datos y necesidades de aprobación.
  • Buscar y centrarnos en los procesos que generan Valor. Simplificar, analizar los costes y tiempos de proceso y automatizar los procesos sólo cuando estos sean todo lo eficientes que se espera de ellos en su funcionamiento, pues automatizar procesos ineficientes, sólo provocará ineficiencias de forma automática.

miércoles, 17 de abril de 2013

Curso: Fundamentos de Business Process Management (BPM).



Magnafor Qualitas.
Lugar: Vigo
Duración: 8 horas.
Modalidad: Presencial.
Inicio: 24 de Mayo de 2013.
Fin: 25 de Mayo de 2013.
Horario: Viernes de 16:00 a 20:00. Sábado de 09:30 a 13:30
Precio: 150 € (gestionamos el crédito de formación (bonificación) de su empresa sin coste adicional.

martes, 16 de abril de 2013

Este fin de semana Seminario de BPM en IE Business School


Este fin de semana tenéis la oportunidad de inscribiros al seminario online de BPM que ofrece el IE Business School. Este seminario que comienza el viernes 19 de Abril, repasará los principales conceptos y teorías sobre la metodología BPM e incluye un test de evaluación y casos prácticos entre los cuales, el alumno realizará el diseño de un proceso haciendo uso de una herramienta de modelado de BPMN (Business Process Modeling Notation).



Seminario BPM en IE Busniess School:
Título: Introducción a Business Process Management (BPM)
Modalidad: online
Duración: 3 días 
Comienza: viernes 19 de Abril.
Finaliza: Domingo 21 de Abril.

jueves, 11 de abril de 2013

Inscribirse a curso de BPM en la Univ. de Vigo


Todavía podéis inscribiros al curso de BPM (Business Process Management) de 40 horas en la Universidad de Vigo que se realizará en el mes de Julio.

Universidad de Vigo. Escuela de Ingeniería Industrial:
Curso: MODELADO Y SIMULACIÓN DE PROCESOS DE NEGOCIO MEDIANTE HERRAMIENTAS BPM.
Modalidad: Presencial.

Duración: 40 horas.
Período de preinscrición 01/02/2013 00:00 - 08/07/2013 23:59
Período de matrícula 08/02/2013 00:00 - 08/07/2013 23:59
Período de docencia 15/07/2013 - 24/07/2013

Precio: 165,00 € (con posibilidad de bolsa de 95 €)

martes, 9 de abril de 2013

Vídeo Introducción a BPM (Business Process Management)

He realizado un vídeo de 20 minutos, en el que resumo los principales puntos de la metodología BPM y que puede servir de orientación al contenido de los cursos que imparto sobre esta materia y al libro de BPM

espero que os guste.



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



Hoy acaban de publicar mi libro sobre BPM en BPMteca.com. Para mi es una gran noticia que debo agradecer a Pedro Robledo de Club-BPM y BPMteca por el interés y el esfuerzo realizado para sacarlo a la luz.

Editorial: BPMteca.com
ISBN: 978-84-616-3854-3
Páginas: 395
Autor: José Ramón Pais
Precio: 14,05 € (iva no inlcuido)
Comprar Libro BPM


He creado una entrada en esta web dedicada al libro en: Libro BPM

Más allá de la automatización de tareas y actividades.


Las implementaciones de TI, no ha resultado en los aumentos de productividad, competitividad y eficiencia de negocio y operacional esperados y predichos por los expertos y grandes vendedores del sector TIC en los últimos años. ¿Estoy tirando piedras contra mi propio tejado? no lo creo, considero que ha llagado el momento de la racionalización a este macro sector. Si queremos que las empresas pagen por productos y servicios tecnológicos, debemos también jugar con las mismas reglas que operan en el resto de sectores, y ofrecer medidas de resultados, cumplimiento de tiempos, costes y presupuestos y adecuación de los productos y servicios a lo que el cliente demanda (sea esta demanda la automatización de una determinada tarea o la consecución de unos determinados objetivos organizacionales).
A través de las TIC hemos automatizado todo lo que hemos podido en las empresas y organizaciones: facturas, pedidos, ventas, workflow, gestión documental, etc, pero automatizar algo no resuelve los problemas de ese algo, sólo ayuda a que ese algo ocurra más rápidamente. Bill Gates, el gran apologista de las TIC, ya lo dijo: “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 ineficiente la hará más ineficiente.
Durante estos años hemos aplicado tecnología del siglo XXI en organizaciones del siglo XIX. Con la automatización hemos resuelto el problema en tareas o actividades de negocio, pero no en los procesos que se han mantenido inmutables en las organizaciones durante décadas, de alguna forma pensamos: “bueno, igual no son muy eficientes, pero funcionan y lo llevan haciendo durante años” ¿para que vamos a cambiar algo que funciona? ¿por qué los procesos de negocio se ven como algo sagrado e inmutable que nadie se atreve a tocar ni repensar? y entre tanto, vamos automatizando tareas de forma aislada y desconectada del resto de la organización, sin atrevernos a abordar en ningún momento los procesos de negocio realmente importantes de la empresa, a repensarlos, analizarlos, compararlos con los de nuestra competencia para de todo ello extraer la inteligencia de negocio y operacional que necesitamos sin que nos asusten las conclusiones que podamos extraer.
Entre tanto, decía, los directivos implementamos tecnología, nos dejamos vender tecnología por terceros, porque de esta manera nos quedamos más tranquilos: no tenemos que hablar de las personas que están detrás de la tecnología (y que realmente son las que van a marcar el éxito o fracaso de la misma), ni de los procesos (auténticos activos de la empresa que son los que en última instancia generan dinero para la empresa). Contrato el proyecto (pago por él), me desvinculo del proyecto (quiero los resultados) y dejo a la empresa (que muchas veces sólo vende su paquete software y se desvincula de la visión, misión estrategia y objetivos de la empresa) y a la gente (nuestros empleados), que se las compongan con los distintos problemas que aparezcan. Visión idealizada de lo que quiero frente a la realidad de lo que he contratado.

Mad men y los nuevos clientes

“Ya no puede confiar en sus clientes de siempre, su vida (la de los clientes) ha cambiado, ahora es prospera, con el tiempo han desarrollado nuevos gustos, son como su hija, educados, sofisticados, saben muy bien lo que se merecen y pagarán por ello”.
Traigo este video de Donald Draper en Mad Men porque a pesar de estar ambientada en plena época industrial de crecimiento, consumo masivo, producción en masa y exceso de demanda (los años 60 norteamericanos), mantiene en su discurso todo su vigor y vigencia ante los mercados y clientes actuales, dominados por la competencia y el exceso de oferta que han hecho de los clientes con sus ansias de nuevos y excelentes productos y sus cada vez mayores exigencias de calidad y servicio, no ya lo reyes, sino los tiranos de la nueva economía: “this is what I want and I want it now”.

Ya se que el tema está más que visto: necesidad de diferenciarse (detectar necesidades en los clientes que la empresa sea capaz de satisfacer mejor que ninguna otra), aportar valor a nuestros clientes (pues valor es por lo que pagan nuestros clientes y la razón por la que existen los negocios)… pero muchas veces obviamos estos puntos en nuestro día a día, no los aplicamos o no lo gestionamos, olvidando que las grandes innovaciones salen de seguir y escuchar a nuestros clientes y que para ello los procesos y modelos de negocio que desarrollemos, son los activos más importantes de nuestra empresa para crear valor a los clientes y que en consecuencia debemos medir, monitorear, controlar y analizar estos procesos para proveer de valor de forma continua a nuestros clientes.

lunes, 8 de abril de 2013

BPM y complejidad


Una de los principios de BPM es la necesaria alineación entre negocio y tecnología y es esta una de las razones por las que el modelamiento de negocios es tan compleja, pues está el modelamiento de procesos de negocio (la más conocida) que nos describe como un negocio realiza sus actividades paso a paso, pero en todo proceso de modelamiento debemos contemplar también los objetivos y estrategias del negocio (lo que el negocio quiere realizar y como lo hará), tenemos que contemplar también el modelo organizativo (quien realizará el trabajo en la organización y con quien interactuará dentro y fuera de la misma) así como las Reglas de negocio (las limitaciones externas e internas). Normalmente en los proyectos BPM nos olvidamos de las últimas, creamos los modelos de procesos de negocio e ignoramos el resto sin percatarnos de que esta descripción es muy útil, pero lo es mucho más cuando va acompañada de los objetivos y estrategias, las organizaciones que participan y las reglas de negocio para el desarrollo de esos procesos.
Nos encontramos en este proceso de modelamiento con el tema de la visión Holística. Del BPM como juego de suma no nula de cooperación entre gente de negocio y gente de IT, en el modelamiento conjunto de la organización como un todo. Las empresas son cada vez más complejas y como en todo sistema complejo existe la presencia de propiedades emergentes sobre las que debemos crear el caldo cultivo que fomenten su aparición para que tras el posterior análisis podamos decidir cuales son de interés y cuales no para nuestra organización (innovación y gestión del cambio). Estas propiedades no pueden explicarse acudiendo a las propiedades de sus componentes, las partes que los componen, pues ahí nuestro conocimiento se desvanece, existe un orden irreductible que es la esencia de lo complejo (complejidad organizada) y que se basa en la presencia de interacciones entre las partes, en la invariancia del todo pese a los cambios y fluctuaciones en las partes. Estas propiedades se encuentran en todas partes: en un hormiguero, en la autorganización de las ciudades, en el software, en nuestro cerebro y con el advenimiento de las tecnologías de la información y la globalización cada vez más también en nuestras empresas.
Por mucho que veamos el comportamiento de una hormiga, jamas llegaríamos a comprender como son capaces de realizar un hormiguero y sobrevivir, pues esto es el resultado de la inteligencia colectiva de toda la colonia. Las hormigas nos muestran a la perfección la existencia de estas propiedades emergentes pues sin un plan de trabajo predefinido ni jerarquía, la colonia es capaz a partir de información mínima intercambiada por sus componentes, de construir estructuras que de forma individual jamas llegaríamos a ver. Las hormigas individualmente carecen de la capacidad de diseñar o construir los hormigueros, sin embargo, el superorganismo formado por todas ellas sí posee esta capacidad. El orden que vemos en un hormiguero, en nuestro cerebro, la sociedad o una célula es irreductible, es decir, no podemos descomponerlo en pequeñas partes, el todo es más que la suma de las partes y el vehículo que posibilita esta organización es el intercambio de información(feromonas, impulsos eléctricos, etc.) que son la base de esa inteligencia colectiva y la base de su éxito, adaptación al medio y supervivencia.
Antes, la visión cartesiana del mundo imaginaba todo sistema como reductible a un conjunto de partes independientes, sobre la cual, se desarrollo la visión Taylorista de la empresa de los últimos 200 años, algo así como un autómata. Se creó la empresa organizada en silos o departamentos independientes, con sus propios presupuestos y medidas de rendimiento, más ocupados de sus departamentos y funciones individuales que de los resultados y eficiencia de la empresa en su conjunto. En un mundo donde las interacciones entre las partes crecen exponencialmente y se desarrollan nuevos fenómenos constantemente, no podemos comprender fenómenos a escalas superiores a partir de las escalas inferiores. BPM propugna la visión holística de la empresa, centrarnos en el todo y no en las partes de un sistema, empresa u organización. En las fronteras entre componentes y sus conexiones para de esta forma alcanzar resultados que suman más que la suma de sus partes por separado. El no continuar gestionando las empresas del siglo XXI con modelos de gestión del siglo XIX pues los principios clásicos ya no funcionan, hemos pasado del siglo de la manufactura al siglo de la innovación, de una época donde mandaba el consumo de masas, donde todo se vendía y el problema era producir en tiempo y coste, a una época de regida por la tiranía del consumidor que nos obliga a innovar y diferenciarnos constantemente.
Lo que sabemos de la complejidad es que tiene mucho más que ver con la naturaleza de las interacciones que con los elementos que interaccionan y que para comprenderla, debemos modelar el mapa de interacciones sobre el cual podamos ver nuevas realidades, amenazas y oportunidades. System Thinking!
Con la tecnología de Blogger.