BPM Business Process Management - José Ramón Pais #OpenExpoDay 2014
•Télécharger en tant que PPTX, PDF•
0 j'aime•2,085 vues
BPM Business Process Management - José Ramón Pais #OpenExpoDay 2014
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à BPM Business Process Management - José Ramón Pais #OpenExpoDay 2014
Similaire à BPM Business Process Management - José Ramón Pais #OpenExpoDay 2014 (20)
Plus de OpenExpoES
Plus de OpenExpoES (20)
Dernier
Dernier (16)
BPM Business Process Management - José Ramón Pais #OpenExpoDay 2014
- 1. José Ramón Pais Curto. OMG Certified Expert in BPM Profesor curso BPM en www.iebschool.com BPM Business Process Management
- 2. PROCESOS: “Conjunto de actividades secuenciales que realizan una transformación de una serie de inputs en los outputs deseados añadiendo valor” “Conjunto de actuaciones, decisiones, actividades y tareas que se encadenan de forma secuencial y ordenada para conseguir un resultado que satisfaga plenamente los requerimientos del cliente al que va dirigido”.
- 3. PARA QUE: Mejora continua de las actividades desarrolladas Reducir la variabilidad innecesaria Eliminar las ineficiencias asociadas a la repetitividad de las actividades Optimizar el empleo de los recursos
- 12. BPMN (Business Process Model Notation) XPDL (XML Process Definition Language) BPEL (Business Process Execution Language) <process name="EMailVotingProcess"> <!-- The Process data is defined first--> <sequence> <receive partnerLink="Internal" portType="tns:processPort" operation="receiveIssueList“ variable="processData" createInstance="Yes"/> <invoke name="ReviewIssueList" partnerLink="Internal" portType="tns:internalPort" operation="sendIssueList" inputVariable="processData“ outputVariable="processData"/ > <switch name="Anyissuesready"> <?xml version="1.0" encoding="UTF-8"?> <bp:process name="Shopping" xmlns="http://www.shopping.com/" xmlns:shop="http://www.shopping.com/" xmlns:bank="http://www.banking.com/" xmlns:ship="http://www.shipping.com/" xmlns:bp="http://schemas.xmlsoap.org/ws/2003/03/ business-process/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
- 15. CASO GOBIERNO CHILE: La implantación de 4 procesos operativos integrados con Gestión Documental y Firma Electrónica.
- 16. El proyecto Emisores Jurídico Visores Gabinete Directores Unid. De Presupuestos Contraloría Archivo RESOLUCIONES EXENTAS RESOLUCIONES AFECTAS MEMORANDUMS OFICIOS 4 procesos transversales
- 17. Modelado Hacemos BPM para ser implementado. Distintos niveles de modelado para distintas audiencias.
- 18. Modelado Importancia del Model Thinking. Descubrir el proceso. Los “drums” de Goldratt comienzan a sonar.
- 19. Modelado BPMN como poderosa herramienta de modelado para levantar requerimientos de procesos consensuados con Stakeholders.
- 20. Modelado 1. La clave de todo es 2. Esta como segunda 3. Tercera idea Añadimos participantes, no todos aparecen en las primeras fases de levantamiento de procesos. Implementaremos procesos sobre una organización. No dejarla para el final.
- 21. Modelado Nº expediente Nº exp.+ Rev. Juridico Nº exp.+ Obs. Visados Nº exp.+ Obs. Gabinete Nº exp.+ Obs. Directores Nº exp.+ Rev. + Obs.+Visados Nº exp.+ Rev.+ Obs.+ Visados+Gabi nete Exp ->Resolución Nº Resolución + Obs Directores + Firma Digital Resol. +Enmienda Dipres Resol.+MinEduc Nº Resolución + Obs Directores + Obs. Contraloría + Firma Digital Especificación de los documentos que acompañan al proceso.
- 22. Modelado Puntos de cancelación del proceso. Luego entraremos en detalles para considerar todas las rutas de excepción.
- 23. Modelado REVISIONES OBSERVACIONES OBSERVACIONES OBSERVACIONES OBSERVACIONES Puntos de decisión del proceso. Los distintos usuarios desconocen los caminos completos. Cada uno individualmente piensa que su modelo es el correcto.
- 24. Modelado Modelo en BPMN. Todavía entendible por usuarios.
- 25. Modelado Niveles de detalle sobre determinados aspectos del proceso.
- 26. Modelado Modelo de implementación necesario para ser llevado a un BPMS. 1 Mes para el primer proceso. 3 días para los otros 3 procesos.
- 27. Construcción Visión global de los procesos. Cascada de decisiones. Multinstanciación de las actividades.
- 28. Construcción Base de Datos Conversor a PDF Gestor Documental Firma Simple Firma Digital Avanzada Solución final con los componentes necesarios.
- 29. Construcción
- 30. Construcción Base de Datos Conversor a PDF Gestor Documental Firma Simple Firma Digital Avanzada Nº Único Control y Alertas Tiempo de Procesos
- 31. Construcción 1. La clave de todo es 2. Esta como segunda 3. Tercera idea
- 32. Aspectos clave Acoplamiento Sincronicidad Modelo de datos Reusabilidad La organización. Reglas de Negocio
- 36. Gracias! José Ramón Pais Curto OCEB (OMG Certified Expert in BPM) josepaiscurto@gmail.com @josepaiscurto
Notes de l'éditeur
- Que componentes deben tener.
- Estos 4 + Proceso Número Único + Proceso Control Tiempo… Hace poco escribí un whitepaper en le que afirmaba que la gran parte del software que desarrollamos está basado en procesos y sobre porque utilizar herramientas BPMS´s. Y aparece que algunos se lo tomaron al pie de la letra, porque empezaron a llamarme para implementar software en vez de BPM, como la nueva panacea. Caso típico para todos los que conocéis BPM. Por que nos lo piden en Londres: porque su sistema actual no puede dar respuesta a los nuevos requerimientos de clientes y es demasiado costoso cambiarlo o modificarlo, además no llegaríamos a tiempo. Y vi esto por internet, oí hablar de ello en un congreso de TI. Tienes tres semanas para implementarlo y 2 días para darme una prueba de que funciona con nuestro proyecto. En Londres: toma este proceso que es como opera el actual software de nuestra organización e implementamelo en un BPMS. Cuento esto porque en la administración pública, la chilena que es en la que he estado trabajando los últimos meses y de la que vengo a hablar hoy aquí... pues NO ha ocurrido esto. Me esperaba unos procesos perfectamente definidos. Y me encontré con que No había mapa de procesos. La gente desconocía todas las partes del proceso y en consecuencia hubo que levantarlos todos. Qué ganas tenía de hacer un As-Is!! Había materia con la que trabajar, aunque como siempre poco tiempo y ahí BPM tiene mucho que aportar.
- Sea para un proyecto de BPm o de implementar software totalmente orientado a procesos. Implementar BPM no es sencillo y tiene sus particularidades, sobre todo cuando hacemos BPM para ser implementado (único caso en el que BPM toma sentido) y no solo para modelar a alto nivel. Volviendo al proyecto de los procesos implementados en Chile. Aquí vemos Un proceso, simple, en las primeras etapas de levantamiento de procesos para entender el proceso. Como empezamos a modelar. Los psicólogos han determinado que el mejor número de elementos en los que una persona puede centrarse es 5+-2. Luego podemos usar estos con usuarios a la hora de discutir y validar modelos.
- Caminos alternativos. Estos diagramas, un poco de niño y que mis hijas pueden entender perfectamente, SON NECESARIOS. Menospreciamos la importancia del modelado (del Model Thinking, que dicho así en inglés parece mucho más importante) En mi experiencia, los mejores resultados en proyectos software se logran cuando se piensa previamente lo que vamos a hacer y cómo lo vamos a hacer. DISEÑO. Caso Becas, como se resolvió con un módulo de incidencias. Salir a pasear!!!, aquí es donde empiezan a sonar los Tambores (los drums de Goldratt). Empezamos a vivir el proceso.
- Vamos desplegando el proceso Ya en BPMN: BPMN 2.0 como la mejor herramienta que conozco (poderosísima herramienta) para consensuar procesos. Facilmente entendible por los usuarios de negocio y técnicos. como con BPMN podemos crear tanto diagramas simples con los que comunicarnos con todos los tipos de stakeholders del proyecto como diagramas detallados de ejecución del proceso.
- Añadiendo participantes… no todos aparecen en las primeras fases de levantamiento y prácticamente hasta el final ha habido modificaciones. El trabajar configurando por detrás la organización con la que finalmente vamos a trabajar, no sólo porque se a necesario para conocer detalles de los procesos, sino porque vamos a tener que implementar el proyecto sobre esa misma organziación.
- Especificación de los documentos que acompañan a cada proceso y que campos/detalles deben ser incluidos en cada uno según la etapa en que se encuentren.
- Puntos de cancelación del proceso. A muy alto nivel. Luego entraremos en detalles. en nivel de ejecución, consideramos todas las posibles rutas de excepción... Todos estos diagramas son para consensuar con clientes.
- Puntos de decisión del proceso. Que junto a los puntos de cancelación del proceso comenzarán a conformar las Rutas de excepción principales a nivel de usuario…luego habrá las que necesitemos a nivel de implementación. La gente desconoce los caminos completos. escogo este camino porque no veo el resto del proceso, pero puede haber rutas más óptimas. cada uno individulamente piensa que su modelo es el correcto... … Pero bueno por esto es por lo que modelamos, para ayudarnos a entender los procesos y el mundo, a consensuar estos en un diseño, a predecir o a que nos ayude a tomar decisiones estratégicas de mejora y guiarnos en la implementación de estas.
- Diagrama más detallado de la solución en BPMN. Ordenado, con los distintos sub-procesos, todavía puede ser entendido por usuarios.
- Aquí vamos ampliando ya los Niveles de detalle. El levantamiento de procesos junto con el diseño y análisis de la solución se mantienen vivos durante todo el proyecto. En algunos casos necesitamos detallar determinados aspectos del proceso que requieran de mayor atención: En Jurídico (el cuello de botella) el reparto de expedientes por carga de trabajo. donde el subproceso opera como una secretaria que distribuye el trabajo en función de la carga que el sistema sabe que tiene cada uno. (ESTO IMPLICA ENTRAR EN NIVEL DE DETALLE) En firma, si no se firma en el mismo día natural, hay que eliminar de PortaFirma y generar nuevo número de expediente. + Aviso cada hora de pendiente de firma. Etc… En la interacción con otros organismos externos al proceso y en la especificación de las tareas que cada uno debe hacer. Escaneo de documentos para adjuntar al expediente (con peleas por no tener que hacerla).
- Proceso final. Puede parecer complejo y realmente se tardó 1 mes en hacer el primero, pero luego en 2 días se hicieron los otros 3. Reutilización (otra vez) Este es el modelo técnico necesario para poder implementar el proceso y llevar el mismo a un BPMS. Y donde hay que ser unos expertos en apuntar las flechas a los distintas tareas.! Son distintos los modelos que usamos con los clientes para validar los procesos que los modelos que implementamos en el motor de procesos. Diferentes modelos para diferentes audiencias. Niveles: estratégico, operacional, ejecutable, y me atrevería a añadir…de especificación it y de implementacion. Especificar variables y mapeo de las mismas a los gateways, actividades y eventos del proceso, mensajes, errores, excepciones, sensores, filtros de usuarios, conectores, Aunque parezca que hemos sólo añadido complejidad también se han reducido muchas de las actividades del proceso: lo que le chocaba a los usuarios, porqué no volvía el proceso a ellos. Esto es ahora lo que preocupa, como los usuarios vana a sobrevivir sin andar ellos de un lugar a otro con los expedientes. Lo que perderán en relaciones.
- Los 4 procesos realizados en el proyecto pueden ser entendidos como una cascada de decisión. EXPLICAR. En general todos los procesos siguen un camino en cascado (de etapas), por las que pasa un expediente. Aquí los BPMS son magníficos, sobre todo para hacer modificaciones y gestionar versiones de procesos así como reutilizar procesos, subprocesos o componentes para otros procesos. Para gestionar la capa de usuarios, los flujos y reglas de negocio y la multiinstanciación. Pero para implementar este proceso que parece tan simple…..vamos a necesitar más que un simple modelo.
- Poco a poco, durante el levantamiento de procesos, se fué haciendo evidente la necesidad de utilizar distintos componentes no previstos inicialmente. Los módulos con los que se compuso la solución fueron: Motor de procesos: rige gobierna el comportamiento. Es el director de orquesta que sabe que tiene que hacer cada uno. Base de datos: quien eres, unidad y departamento y que tipo de proceso quieres hacer y que tipo de expediente quieres usar (general de presupuesto de personal), pues cada uno de ellos tiene una ruta distintas y la plantilla de documento que te debo entregar es diferente. Además debo darte un número de solicitud y más tarde un número de expediente antes de pasar a firma (y además debe ser un nº único por departamento). Reglas de negocio. Gest. Doc. (y configuración del mismo para especificar la estructura de carpetas: proceso/dia/mes/año/tipo docs,(firmados, adjuntos, etc)). Todo el repositorio de docs está aquí y los usuarios sean visadores, jurídico, gabinete, etc visualizan o descargan los docs. sobre el gest. Doc. Que mantiene las distintas versiones. Conversores de distintos formatos de documentos a pdf y la composición automática de pdf´s con variables del proceso. Pues los usuarios pueden subir cualquier tipo de doc (.doc. .txt, etc) que deben ser siempre convertidos a pdf, en especial antes de su paso a firma. – Y También la creación de pdf´s a través de plantillas con datos de BD. La composición de documentos en tiempo de ejecución. Firma simple: Firma Avanzada:
- Comentar firma simple y simple avanzada.
- Y además de todo esto: Añadimos dos procesos en paralelo: Nº único: antes dije que lo llevábamos en Base de Datos, pero luego al final surgió la necesidad (otra vez…levantamiento de procesos no finaliza nunca) de crear un proceso para gestión de nº únicos para aquellos expedientes que se realzasen por fuera del sistema o de estos procesos y mantener la integridad. Control Tiempo y Alertas. Que se hizo como un proceso paralelo vía mensajes para recibir inicios de procesos, tiempos en los que se generan los números, calcular las fechas de caducidad y alertar días antes de su finalización a usuarios así como cancelar un proceso que esté fuera de plazo. Ciclo de anulación sino se firma en dia natural, avisos de expedientes listos para firma, proximas caducidades, para que no llegen a firma docs caducos, etc. Todo asociados a eventos de los procesos.
- Servidores para: Motor BPM Gestor documental + Base de Datos Sistema Firmas Base de datos NAS Configuración versiones JDK, Jboss. Visibilidad entre máquinas. HTTPS. Todo plataformas JAVA, con lo cual tenemos pocos problemas de compatibilidad.
- Acoplamiento: Al tener tantos sistemas (gest. doc, base de datos reglas, firma simple, firma digital, conversores de formatos de docs, etc) las principales dificultades y peleas han estado en el acoplamiento entre las partes con el motor de procesos como director de orquesta y donde para que el sistema funcione en su conjunto, todas las partes deben hacerlo perfectamente. Ardua tarea de testing. La cuestión aquí es la del acoplamiento entre las partes, como las partes están acopladas unas con otras. La importancia de las dependencias entre las partes y la forma de controlarlas y poder introducir variaciones en estas partes sin cambiar las otras. La calidad del sistema vendrá dada por las técnicas de desacoplamiento que utilicemos con módulos sencillos y bien delimitados de forma que al final podamos ser inmunes a las modificaciones de las partes y a la adición de nuevas partes. Sincronizidad: tarea A --> tarea B --> etc Pero los procesos no son siempre o rara vez son A,B,C cuando los llevamos a nivel de Implementación. Los procesos no suelen ser síncronos, sino asíncrono. Cuando modelamos a Alto Nivel se ven los procesos de forma síncrona. este es el motivo por el cual siempre que el cliente nos dice: "cuando veas el proceso te vas a echar a reir" de lo fácil que es" (Bueno si es tan sencillo para que me llamas). Pues por que no son capaces de llevarlo a ejecución. A Alto nivel, ellos entienden como opera su organización y son capaces de describir el proceso, pero implementarlo es otra cosa, pues requiere nivel de detalle. Cuando simultáneamente se ejecutan varios proyectos, siempre existirán limitaciones en la disponibilidad sincronizada de los recursos. #TOC. En el nivel de ejecución no suelen ser simples "Orquestaciones" sino más bien "Coreografías" de procesos ejecutados. Variables: la gestión de las variables del sistema, locales y globales y externas. La importancia del modelo de datos y de poder gestionar las variables del proceso de forma ordenada. "para un simple proceso es increíble la cantidad de variables que manejamos cuando bajamos a ese nivel de ejecución. Vamos creándolas a medida que surge la necesidad y a al final tenemos un pollo que no nos aclaramos con todas ellas". Reusabilidad de las partes aisladas para utilizarlas en diferentes versiones de procesos u otros procesos. (aquí el tiempo en el primer proceso y en los siguientes de 2 días para tres procesos) cambio localizado: todo software o proceso necesita cambios, con lo que podemos hacer estos cambios o adaptaciones en partes más pequeñas. Organización: - Otra tarea es la de exportar la organización, cuando tenemos tantos usuarios como este tipo de procesos. Tendremos que hacer uso de LDAP, Active Directory o archivos XML y que suele consumir horas no sólo en su configuración sino también en re-ruteo de tareas. ¡No dejarla para el final! A última hora aparece una unidad de negocio, que no se consideró de importancia (no se nos comentó), por esa visión alto nivel, pero que luego vemos que si tiene importancia. Reglas de Negocio: Bueno, lo que nos encontramos aquí, es que a pesar del entorno en que se desarrolla el proyecto, las reglas no son siempre Fijas, no siempre siguen las mismas reglas, sino más bien son reglas Adaptativas en las que estas cambian en función de determinados eventos. Otra cosa interesante y que nunca había hecho, es pasar las variables de muchos de los gateways de decisión a una base de datos para regir el comportamiento del proceso. (Al llevar las variables del gateway a BD lo hice para gestionar los tipos de plantillas de documentos (distintos tipos de docs. Distintas rutas) luego sirvió también para gobernar el flujo del proceso, cambios en las rutas y a quedado como el sistema para hacer el proceso perfectamente mantenible. (ACM?) Las reglas son Fijas cuando hablamos con una sola persona, pero cuando hablamos con más personas, vemos que estas reglas deben ser más adaptativas.
- Con la adaptación de estilos de diseño. el trabajo más arduo...recorrer una y otra vez los procesos testeando las distintas configuraciones y conectores, para que todo funcione bien. Te acabas sabiendo los procesos de memoria. Se quedan clavados como las partidas de ajedrez. La pena de todo esto es que una vez implementado, cuando vemos los procesos funcionando y la facilidad con que los usuarios realizan las tareas aisladas, parece todo tan simple, que piensas en que dedicaste tanto esfuerzo. Ves a una unidad de negocio validando una parte del proceso y se aleja mucho de la complejidad del proceso. experiencia gratificante, el ver la transformación dentro de la organización de pasar de un sistema de fotocopias, visados, firmas, aprobaciones varias todo en papel, a la organización que supuso el pasar a hacerlo todo digitalmente y en el que todos saben en que situación están sus diferentes procesos y que tienen pendiente de hacer. (GTD) experiencia usuario: esta es otra forma de trabajar, vamos a dejar de andar con las fotocopias de un lado para otro y perdiendo el rastro de donde se encuentran nuestros expedientes.... Ahorro de tiempo, registro organizado y confiable de todo.
- Hemos pasado del modelado de procesos simples a modelos más complejos y hemos aumentado la complejidad con las necesidades de implementación tecnológicas de infraestructura, para finalizar con los frontales de usuario que son realmente simples. Receta de éxito: Objetivos simples, procesos claros y bien definidos. Planes complejos, para implementar, dar soporte y cubrir todas las necesidades y posibilidades. Simplicidad en la entrega del servicio.
- Llegamos al final del trabajo hemos imaginado y construido nuestros procesos y llega el momento de ponerlos en funcionamiento. Hemos realizado la travesía del desierto de construir y Documentar. Primero con los requerimientos, pues cuando trabajamos con organizaciones con tantos actores y stakeholders, las necesitaremos luego para defendernos de por qué el proceso opera de esta u otra manera, pues como sabéis, en la fase de entrega, el que nunca participó ni aportó conocimiento o experiencia sobre el proceso, ahora aparece y pretende instruirnos a todos. Y si en las primeras fases de levantamiento nos manteníamos en silencio y en escucha activa, ahora somos los abogados del proceso y mandamos sobre el mismo. Esta documentación de los requerimientos y la redacción de las reglas de que hace y no hace el proceso se convertirán en las tablas de la verdad para defender nuestro proceso. El poder del modelado. Salir a pasear y escuchar los tambores (los drums de Goldratt) del proceso que empezamos a oir al principio del proyecto. O imaginar tuberías de agua (yo lo hago con procesos, con goteras). No vayáis directamente a la herramienta de modelado o al BPMS. Creo que hasta que no tenemos nosotros mismo interiorizado el proceso y somos capaces de imaginar su comportamiento, no debemos utilizar otra cosa más que papel y lápiz. Este proceso “artístico” (me voy a atrever a llamarlo) puede tardar más o menos tiempo y dependerá del tiempo que nos lleve levantar, mapear y entender los procesos de forma consensuada. Es difícil alcanzar un mínimo punto a partir del cual tenemos algo que seguir. Pueden ser dos días o dos meses… Pero es necesario..y después de esto..y de construir el proceso..Los mismos tambores que escuchabais cuando imaginabais el proceso en sus primeras etapas, serán los que ahora oiréis, sonando al mismo ritmo e incluso mejor que cuando los imaginabais. Y esta música es la mayor satisfacción que podemos tener en nuestro proyecto. Cuando hagáis la marcha blanca, os veréis como directores de orquesta, dando entrada con la mano debajo de la mesa a los distintos actores del reparto en una sinfonía que os sabéis de memoria y tenéis totalmente interiorizada.
- Espero que os haya sido útil.