miércoles, 20 de junio de 2018

La personalidad del analista de procesos


Ya hemos visto que hacer el levantamiento de un proceso es una tarea compleja, una tarea que realiza el analista de procesos y que, en parte por la propia naturaleza de la labor, en parte por las dificultades de la misma, requiere de un perfil especial, una personalidad específica.

En primer lugar, y siguiendo las ideas que en su libro 'Fundamentals of Business Process Management' exponen Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers, a la hora de hacer un levantamiento de procesos AS-IS (process discovery) el analista de procesos debe realizar fundamentalmente tres tareas:

  • Recoger información
  • Realizar el modelado
  • Asegurar la calidad del modelo de procesos

Y debe hacer esas labores teniendo en cuenta que nuestro analista de procesos es experto en el modelado pero no (o al menos no necesariamente) en el negocio cuyos procesos está modelando. Por ello es fundamental su interacción con los expertos de negocio, su capacidad para establecer una buena relación, extraer información relevante y estructurarla. Y ello, aparte de conocimientos técnicos concretos (como, por ejemplo, el conocimiento profundo del lenguaje BPMN), necesita de unas ciertas características personales.

Un modelo que describe la personalidad es el denominado Modelo de los Cinco Factores desarrollado en el ámbito de la psicología y que incluye cinco dimensiones:

  • Apertura: capacidad de apreciar el arte, la emoción y la aventura.

  • Meticulosidad: Tendencia a la autodisciplina, el orden y el logro.

  • Extraversión: personalidad positiva, enérgica y que busca la compañía.

  • Simpatía: compasión y colaboración.

  • Neurosis: ansiedad, depresión y vulnerabilidad

Pues bien, de esas cinco dimensiones, el analista de procesos tiene que destacar especialmente en la meticulosidad y la extraversión, lo cual no nos sorprende si tenemos en cuenta que, por una parte, debe interactuar con los expertos del negocio y, por otra planificar la actividad y generar modelos detallados y rigurosos.

Además, los analistas de procesos más expertos tienen una forma de trabajar propia y diferente de los más novatos y que, según los autores mencionados más arriba, se concreta en los siguientes cuatro comportamientos:

  • Contar con las personas adecuadas: se refiere a incluir en los comités a los responsables de negocio adecuados de forma que cuando se precise la colaboración de un área y sus expertos  no aparezcan problemas.

  • Disponer de hipótesis de trabajo: se trata de un punto de partida, una lista extensiva de hipótesis de partida sobre el proceso que luego se analizan y confirman o descartan durante el análisis.

  • Identificar patrones de información: es decir, estructuras subyacentes que se repiten y de las cuales el experto del dominio no suele ser consciente pero el analista de procesos sí es capaz de identificar.

  • Prestar atención a la estética del modelo: aunque pueda parecer un aspecto menor, un modelo ordenado y estéticamente bueno, lo hace mucho más comprensible lo que ayuda, no sólo a transmitirlo a los 'stakeholders' sino también durante todo el análisis.

Ya se aprecia que, en efecto, la tarea del analista es compleja y cómo su personalidad es por tanto especial. Evidentemente, hablamos de personas y personalidades y, por ello, no hay patrones cerrados, pero las habilidades y características psicológicas reseñadas sí parecen ser adecuadas y dominantes en el caso de los analistas de procesos.


martes, 19 de junio de 2018

Colaboración: "Siete reflexiones sobre el futuro de la sociedad tecnológica" en 'A un CLIC de las TIC'


La semana pasada publiqué en A un CLIC de las TIC, blog de Telefónica, el artículo 'Siete reflexiones sobre el futuro de la sociedad tecnológica'. 

Se trata de un repaso por las principales ideas aportadas en el ciclo de conferencias y actividades titulado "Tech & Society" a lo largo de 2017 organizado por Fundación Telefónica y Aspen Institute España y recogidas en un pequeño libro que tuve el placer de leer previamente.

Se habla de empleo, de aprendizaje, de máquinas inteligentes... y se dan cita siete personalidades como son Darío Gil, Amber Case, Eli Parisier, Ryan Avent, Connie Yowell, Todd Breyfrogle o Belén Barreiro.

Si quieres profundizar, no tienes más que leer el artículo en A un CLIC de las TIC.


lunes, 18 de junio de 2018

Tres retos para el levantamiento de procesos de negocio


Una de las fases que compone el ciclo de vida de un proceso de negocio tal y como veíamos en un post anterior es el levantamiento del proceso AS-IS, lo que Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers denominan Descubrimiento de procesos ('Process Discovery') en su libro 'Fundamentals of Business Process Management'.

Es una fase importante porque ayuda al analista (creo que con frecuencia, en general, a toda la empresa) a conocer y entender realmente los procesos que se están ejecutando en el momento del análisis.

La forma habitual de trabajar es que unos analistas de procesos (o analistas de negocio) se reúnen con expertos del dominio del proceso e intentan obtener el conocimiento necesario como para entender y modelar el proceso de negocio.

Puede parecer una tarea sencilla...pero no lo es. Puede caerse en un cierto desprecio hacia los analistas atribuyéndoles lo que jocosamente se dice de los consultores: que hacen que les cuentes cómo funcionas para luego explicarte a ti lo que ya sabes. Pero eso es una falsedad: porque los expertos de negocio no saben realmente tan bien como nos podríamos imaginar, no al menos de una forma tan clara, completa y estructurada, cómo funciona realmente un proceso de negocio.

En concreto, los mismos autores que citamos más arriba y en el mismo libro, identifican tres grandes retos para el levantamiento de un proceso de negocio. Son estos:

  • Conocimiento fragmentado: no existe un experto del negocio con una visión completa y transversal de cómo funciona un proceso de negocio. Los expertos tienden a conocer en detalle cómo funciona la parte del proceso que directamente les afecta, pero no suelen tener un conocimiento completo. Eso lleva a que los analistas deban consultar a diferentes expertos y asegurarse que la visión completa del proceso es realista y que las piezas encajan.

  • Pensamiento de los expertos orientado al caso concreto: Los expertos tienden, más que a ver la estructura del proceso, a centrarse en casuísticas concretas que ocurren en el día a día. El conocimiento de esas casuísticas es valioso, pero en un análisis de proceso buscamos ante todo la estructura general.

  • Falta de familiaridad de los expertos con el lenguaje del modelado: como es lógico, los expertos conocen su negocio y su actividad pero no suelen (y realmente no tienen por qué) conocer los lenguajes de modelado. Por tanto, los analistas tienen que, o bien dedicar mucho tiempo a explicar a los expertos el significado del modelado, o bien abstraer a los expertos del negocio de ese modelado, pero eso implica el riesgo de no poder validar esos modelos con total seguridad. 

La verdad es que, leo esos retos que los autores nos plantean y me resultan tan reales, tan cercanos... Los he experimentado en propias carnes con frecuencia... y son tal cual nos los describen. Ni más, ni menos...


viernes, 15 de junio de 2018

¿Qué es y para qué vale modelar un proceso de negocio?


En los posts anteriores hemos recordado lo que es BPM,  lo que es un proceso de negocio y el ciclo de vida de gestión de un proceso de negocio. Como una actividad, que no una fase, del ciclo de vida, hablábamos de modelar procesos de negocio.

En este artículo vamos a intentar razonar para qué sirve realizar un modelado pero antes, recordemos brevemente qué es modelar en el ámbito del análisis de negocio, análisis de procesos y de la ingeniería de software. 

Podemos decir que modelar es "hacer una representación abstracta y simplificada de una realidad utilizando un lenguaje formal".

¿Qué significa eso?

Pues lo primero que significa es que el modelo siempre representa una realidad. Como tal representación debe ser fiel a esa realidad, es decir, lo que representa debe ser absolutamente cierto en el mundo real pero, al mismo tiempo es una abstracción y también una simplificación. Y el lenguaje formal significa que ese modelado utiliza unas convenciones acotadas de signos y palabras con un significado inequívoco y muy preciso.

¿Todavía parece un galimatías?

Veamos el caso de los procesos de negocio a ver si lo entendemos mejor.

Decíamos que un proceso de negocio era una relación de actividades, eventos y puntos de decisión que involucraban a un conjunto de actores y que coordinadamente generaban un resultado de valor para al menos un cliente.

Un proceso puede ser, por ejemplo, el tratamiento de una avería reportada por un cliente en que hay actividades como el registro de la avería, el diagnóstico, el envío de un técnico, los trabajos de resolución y el cierre del boletín de avería. Un punto de decisión puede ser si se envía realmente un técnico o no es necesario porque la avería ha cesado o porque la puede resolver el propio cliente guiado por teléfono; y un evento podría ser que el cliente volviese a llamar porque aún no se le ha resuelto la avería y no sabe nada. 

Esa sería la realidad. A la hora de modelar un proceso, el lenguaje formal dominante es BPMN (Business Process Model Notation) definido por el OMG (Object Managemet Group). En ese lenguaje, una actividad, por ejemplo, se representa por un cuadrado de esquinas redondeadas y un punto de decisión por un rombo.

El aspecto de un proceso modelado en BPMN es como el que se muestra en la figura:


Es más que evidente que la realidad no es el modelo, pero también es evidente que el modelo representa de una forma fiel, bien que abstracta y simplificada, el proceso real.

Espero que así, sí que se entienda que es modelar.

Ahora bien ¿para qué hacemos ese trabajo? ¿para qué esforzarnos en hacer esos 'dibujitos'? ¿tienen alguna utilidad?

La verdad es que sí, que tienen muchísima utilidad.

Si acudimos a la fuente que hemos utilizado en los últimos artículos, es decir, el libro 'Fundamentals of Business Process Management' de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers, estos autores nos aportan dos razones.

En realidad, nos dicen que hay muchas razones pero se centran en dos. En primer lugar para entender el proceso. Esto ocurre sobre todo en la fase de descubrimiento del proceso o, lo que es lo mismo, el levantamiento del proceso AS-IS. Dibujar el modelo que corresponde al proceso actual, nos ayuda a entenderlo mejor, tanto si somos los analistas como, incluso, si somos los expertos de negocio. Y es que el propio proceso de modelado te obliga a hacer preguntas y a entender las respuestas para poder dibujarlo de forma que sea un reflejo fiel de la realidad. 

La segunda razón que aportan es que ayuda a comunicar el proceso a otros. En efecto, dado  que el lenguaje formal es inequívoco (y, además, relativamente simple), el traspaso de un modelo a otra persona le hace sencillo a ésta entenderlo. 

Me atrevería a aportar alguna razón más que los autores se dejan en el tintero. 

Así, y muy relacionado con el entendimiento, diría que el modelado obliga al rigor, ya que en lenguaje natural es fácil ser ambiguo y aun así pensar que lo estamos entendiendo. El tener que expresar el modelo en un lenguaje formal elimina ambigüedades. 

Diría que, además, aparte de para entender, un modelado ayuda a pensar. Ahora no estaría pensando en el levantamiento de AS-IS (descubrimiento) sino en el TO-BE (rediseño). Y la razón es la misma: el expresarlo en un modelo formal nos exige pensar con claridad (sin ambigüedades) en el proceso futuro.

El disponer de un modelado también nos ayuda a archivar el conocimiento para uso futuro.

Incluso, y aunque en menor medida de lo que quisiéramos, el expresar un proceso en un modelo formal, puede facilitar su automatización, ya que, al tratarse el lenguaje formal de un lenguaje inequívoco, es procesable por máquinas y podemos hacer generación automática de código.

Como se puede ver, modelar no es un ejercicio teórico o académico sino que existen muchas y muy buenas razones para llevarlo a cabo.

miércoles, 13 de junio de 2018

Ciclo de vida de un proceso de negocio


En un artículo reciente aportábamos una definición de proceso de negocio y otra de BPM (Business Process Management). Aunque entonces no lo explicitábamos, la definición de BPM hacía referencia de manera indirecta al ciclo de vida de un proceso de negocio, siendo BPM, de alguna forma, la disciplina que se ocupa de gestionar ese ciclo vida.

Vamos en este post a revisar qué fases incluye ese ciclo de vida, y lo hacemos apoyándonos en la misma fuente bibliográfica que usamos para las definiciones, es decir, el libro 'Fundamentals of Business Process Management' de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers.

Estos autores proponen un ciclo de vida cuya representación gráfica es la que se muestra en la figura de abajo:


En esa figura, las distintas fases del ciclo de vida son:

  • Identificación: Una fase muy preliminar que tiene sentido cuando es la primera vez que se acomete un trabajo de procesos pero no tanto cuando ya tenemos un BPM instituido. En esta fase se identifican los procesos de negocio y se relacionan entre sí, generando lo que los autores denominan una arquitectura de procesos y que yo tendería a verlo como un subconjunto de una arquitectura empresarial.

  • Descubrimiento: Que es el popular levantamiento del proceso AS-IS, es decir, el entendimiento detallado y documentación formal del proceso de negocio tal y como funciona en el momento en que se produce dicho levantamiento. Acompañando a esta fase (y la de diseño) existe una actividad, el modelado, que ayuda a expresar y formalizar ese funcionamiento del proceso.

  • Análisis: Es el estudio de ese proceso AS-IS, identificando puntos fuertes y débiles y las oportunidades de mejora que se nos ofrecen.

  • Rediseño: Es la definición del proceso TO-BE, es decir, el proceso mejorado que aspiramos a implantar. Ese proceso TO-BE, a su vez, se modelará con lenguajes como BPMN para dejar clara y formalmente expresada, cuál es su nueva definición.

  • Implementación: Es la fase quizá más fácil de entender pero la más difícil de ejecutar. Se trata de llevara  la práctica el nuevo proceso definido. Esto normalmente constituye un proyecto por derecho propio que incluirá desarrollos sobre sistemas, comunicación, formación, etc

  • Monitorización y control: Se trata de supervisar el proceso en producción para, por una parte, ver que se ejecuta tal y como estaba definido y por otro, para medir el funcionamiento real, pudiendo con base en ello, identificar nuevas debilidades u oportunidades de mejora que se podrían acometer en un nuevo ciclo.

Un ciclo de vida, como se puede ver, que recuerda a muchos otros, incluido el conocidísimo PDCA (Plan, Do, Check, Act) de Demming y la Calidad Total, y un ciclo de vida muy claro y ordenado.

En la referencia citada, los autores utilizan este ciclo de vida como base para estructurar su libro y su exposición. Probablemente, nosotros también lo utilicemos como referencia en algún artículo futuro.


martes, 12 de junio de 2018

Colaboración "¡Que trabajen los robots! La automatización robótica de procesos (RPA)" en 'Con Tu Negocio'


El pasado 5 de Junio, publicaba en Con Tu Negocio, el blog de Telefónica dedicado al mundo de las PYMEs, el artículo titulado "¡Que trabajen los robots! La automatización robótica de procesos (RPA)"

En él, explico los fundamentos de la automatización robótica de procesos (RPA), una tecnología en auge que. sin grandes alardes técnicos, sí puede conseguir un gran impacto de negocio y sobre la que, por ello, se está poniendo mucha atención por parte dela industria.

Si quieres saber algo más sobre Robotic Process Automation, no tiene más que leer el artículo.


lunes, 11 de junio de 2018

Recordar para avanzar en transformación digital: qué es un proceso de negocio y qué Business Process Management


El interés en los procesos de negocio viene de atrás. Ya desde los años ochenta/noventa, diversas disciplinas y tendencias como la Reingeniería o la Calidad Total, seguidos por Lean Management o Six Sigma, pusieron su foco en este concepto de proceso de negocio en su gestión, y su mejora.

El fuerte desarrollo de la tecnología digital, la apertura de todas las posibilidades que a ella se asocian, hace que la mejora de los procesos de negocio se convierta en una área muy interesante e importante de la transformación digital y que convenga recordar técnicas y metodologías que nunca murieron pero que ahora despiertan con fuerza.

Y, para empezar, probablemente convenga saber de qué estamos hablando, saber contestar a la pregunta de qué es un proceso de negocio.

Acudimos para ello al libro 'Fundamentals of Business Process Management' de Marlon Dumas, Marcello La Rosa, Jan Mendling y Hajo A. Reijers y nos encontramos con esta definición:

We define a business process as a collection of inter-related events, activities and decision points, that involve a number of actors and objects and that collectively lead to an outcome that is of value to at least one customer.

La definición nos transmite la idea de una serie de tareas que coordinadas producen un valor. Pero creo que, en un nivel algo mayor de análisis, en esta muy certera definición. debemos prestar atención a cuatro elementos:

  • Las tareas, lo que se hace que, fundamentalmente son actividades pero donde también conviene incluir otras alternativas como son los eventos (acontecimientos externos) y los puntos de decisión.

  • A continuación es importante el quién lo hace y en este caso estaríamos hablando de los actores y objetos, que normalmente serán personas o sistemas.

  • Que esas tareas realizadas por actores están coordinadas (en la definición esa idea se concentra en la palabra 'collectively')

  • Y que el proceso produce un resultado (outcome) de valor para alguien, normalmente un cliente.
Alrededor de esta idea nuclear de proceso de negocio ha surgido una disciplina que se encarga de la gestión extremo a extremo del ciclo de vida de los procesos de negocio. Esa disciplina es el BPM o Business Process Management. Así nos la definen los mismos autores:

We define BPM as a body of methods, techniques and tools to discover, analyze, redesign, execute and monitor business processes.

Es decir, la gestión del cilo de vida de los procesos de negocio. En cierto sentido, podemos decir que los procesos de negocio son el objeto de gestión y BPM la disciplina de gestión propiamente dicha.

Sentadas las bases, en próximos artículos avanzaremos algo más. Y es necesario ese avance porque los procesos de negocio, aunque como concepto no sea nuevo, como elemento de transformación, de eficiencia, de experiencia de cliente, siguen siendo fundamentales, puede que lo sean más que nunca, para una efectiva aplicación de la transformación digital.