DOCUMENTACION

 

Usando Confluence para documentar procesos y requerimientos

0 comments. Top.

Catalogo Funciones de NegocioComo ejemplo del uso de nuestra metodología de documentación de procesos descrita en varios otros artículos de este blog (ver aquí), la siguiente serie de 3 videos muestran muestran cómo se aplicó esta metodología junto con la plataforma Confluence para realizar el rediseño de un proceso y aplicación core de una empresa en Chile, del rubro caja de compensación.

El desa­rro­llo de los entre­ga­bles de este pro­yecto cubrió todos los con­cep­tos meto­do­ló­gi­cos que abarca nues­tra meto­do­lo­gía. El proyecto abarcó un periodo de 5 meses de docu­men­ta­ción, de los cua­les 2 meses se dedicaron a la parte I y II y 3 meses a la III. Los videos mues­tra cómo se fueron refi­nando las fun­cio­nes de nego­cio docu­men­ta­das en la parte II con los meca­nis­mos de imple­men­ta­ción docu­men­ta­dos en la parte III. En estos últimos se encuentran los requerimientos de sistema de la (nueva) aplicación.

Durante la ejecución del proyecto se buscó la trans­pa­ren­cia y facilitar el acceso a los entre­ga­bles a todos los invo­lu­cra­dos (Área de Operaciones). Para ello Con­fluence (más el addon Gliffy) jugó un rol clave para faci­li­tar esta comunicación.

Parte I: Visión del proyecto

Parte II: El catalogo de funciones

Parte III: Procedimientos y requerimientos de sistema

 

Procesos, Mecanismos y Procedimientos de Negocio

0 comments. Top.

En el artículo anterior de esta serie vimos el rol central que juega el Catalogo de Funciones de Negocio para organizar una metodología de documentación de procesos que permitiese abordar los errores y falencias más usuales en que incurren los analistas de procesos:

Catalogo Funciones de Negocio

En este artículo vamos a continuar desarrollando esta metodología, y para ello vamos a definir los siguientes conceptos:

Función de negocio O simplemente función, representa una actividad o a un conjunto coherente de actividades, que una organización debe poder realizar para lograr sus objetivos y continuar existiendo.Las funciones representan lo que la empresa debería estar haciendo.
Mecanismo de negocio O simplemente mecanismo, es la definición del medio por el cual se implementa una función. Una función se puede realizar a través de diferentes mecanismos. Los mecanismos representan el como la empresa lo hace.
Proceso de negocio O simplemente proceso, es la definición de una secuencia de ejecución de funciones en respuesta a un evento con el objetivo de lograr un resultado. Tanto los eventos como los resultados deben estar definidos, o sea, los procesos no responden al azar y sus resultados son conocidos. Los procesos de negocio representan una conceptualización del  funcionamiento de una organización.
Procedimiento de negocio O simplemente procedimiento, es la definición de una secuencia de ejecución de mecanismos correspondientes a las funciones contenidas en un proceso especifico. Los procedimientos de negocio representan la implementación concreta del funcionamiento de una organización.

 

Los mecanismos de negocio

Un mecanismo de negocio es la formalización del COMO se implementa una función. Si la función dice “Registrar reclamos de clientes”, un mecanismo de esta función puede ser “Utilizar formulario web de reclamos” o también “Utilizar teléfono 600 600 de reclamos”. También podríamos “Utilizar sucursal de reclamo” y la lista podría seguir con cada forma de implementación del concepto de registrar reclamos de clientes. Esta relación de uno a muchos representa  una faceta que diferencia al QUE del COMO.

La manera más simple de documentar mecanismos es mediante una tabla donde se anota el nombre del mecanismo, su descripción y la función de negocio que implementa. Esto es lo básico, pero en la práctica podemos comenzar a adosar una serie de atributos, como roles, aplicaciones, casos de uso, etc. ya que estamos documentando una implementación.

Los procesos de negocio

Cuando usamos la palabra proceso, estamos implícitamente representando una secuencia de ejecución y de decisiones. Lo que se ejecuta son funciones de negocio y como estas representan conceptos (agnósticos de cualquiera forma o mecanismo de implementación), tenemos entonces que los procesos representan una visión conceptual.  Es muy importante entender que al referirnos a procesos no estamos haciendo referencia a cómo las cosas se hacen actualmente, sino que a lo que se debería estar haciendo. En el post Los 5 errores fatales de los analistas de procesos, vimos que este es el principal error en el que caen los analistas.

Por lo tanto, antes de documentar procesos debemos tener definido el catalogo de funciones, al menos es una parte importante. Pero además necesitamos saber a qué eventos esperamos que la organización responda y qué resultados debería producir, ya que por definición el proceso describe la secuencia de pasos y decisiones para pasar de un evento a un resultado.

Como se documentan los procesos de negocio? A diferencia del catalogo de funciones, donde la descripción de cada función es suficiente, los procesos representan secuencias, y por lo tanto un diagrama de flujo puede ser complementario – pero nunca será un substituto – de una descripción precisa y completa de lo que se esta capturando como evento y produciendo como resultado en el proceso. Esta substitución es otro de los errores mas comunes en que caen los analistas: abdicar de la necesaria definición textual, reemplazándola por representaciones visuales.

Antes de hacer diagramas de proceso, necesitamos:

  1. Saber lo que la organización debería hacer, vía el Catalogo de Funciones
  2. Saber a lo que la organización debería responder, vía una lista de eventos relevantes
  3. Saber lo que la organización debería producir, vía una lista de resultados relevantes

La figura muestra un proceso de negocio a partir de la función “Vender producto tipo B” identificada en el Catalogo de Funciones. La flecha verde es un evento relevante y la roja un resultado relevante para la organización:

(hacer click para ver completa)

Este formato de secuencia lineal es tipico de los procesos de negocio, ya que lo que nos interesa es mostrar la forma en que las funciones de negocio se organizan para cumplir con un objetivo, pasar de un evento a un resultado relevante (QUE) sin entrar en detalles de implementación (COMO). Para esto último están los procedimientos de negocio.

Los procedimientos de negocio

Cuando usamos la palabra procedimiento, estamos implícitamente representando una secuencia de ejecución y de decisiones. A diferencia de los procesos de negocio, lo que se ejecutan son mecanismos y no funciones, y como estos representan una implementación especifica de una función, tenemos que los procedimientos de negocio son la representación del funcionamiento actual de una organización.

Y es aquí donde comienzan los problemas…ya que en la realidad una organización puede tener cientos o miles de procedimientos.

La racionalización de procesos, la reingeniería, la mejora de procesos, etc., se alimentan de esta realidad. Si una organización es ordenada, muchos de estos procedimientos están estandarizados y se hacen igual en diferentes lugares y por diferentes personas. De lo contrario, cada persona  en cada lugar puede representar por si muchos procedimientos distintos.

Las aplicaciones son una componente clave de los procedimientos de negocio. La integración de aplicaciones, SOA, BPM, etc. no son otra cosa sino conceptos/productos que buscan crear/automatizar nuevos procedimientos a partir de la gran diversidad de procedimientos existentes, con lo cual el inventario de procedimientos aumenta en vez de disminuir!!

El volumen y diversidad de los procedimientos hacen de su administración o gestión un tema cuya complejidad siempre tenderá a subestimarse. Al estar también muy asociados a las aplicaciones, la dificultad aumenta exponencialmente ya que en la práctica debemos documentar aplicaciones, en especial sus casos de uso (i.e. la interacción usuario con aplicación). También en este nivel nos vamos a encontrar con múltiples y variadas nomenclaturas y simbologías que conforman el lenguaje de Informática o Sistemas: UML, BMPN, ERD, etc.

Por lo anterior, al entrar al terreno de los procedimientos de negocio usted debe tener claro que: a) la complejidad y volumen aumenta exponencialmente en relación a las funciones y procesos de negocio, b) debe necesariamente relacionarse con las aplicaciones y por ende con el área de Informática y Sistemas y c) está en contacto con lo que la organización actualmente hace, lo cual puede distar mucho de lo que realmente debería estar haciendo.

La figura muestra un procedimiento de negocio a partir de la función “Vender producto tipo B” señalada anteriormente. Los recuadros amarillo son mecanismos de negocio (se muestra la descripción de uno de ellos, “Registrar Prospecto”, que implementa la función “Identificar Prospecto”):

(hacer click para ver completa)

Note que una descripcion clara y precisa es imprescindible y nunca puede ser substituida por un diagrama. En este ejemplo, el diagrama ayuda a entender la manera asíncrona en que la aplicación y los agentes se coordinan para realizar el procedimiento, junto con visualizar las alternativas de decisión representadas mediante el símbolo de rombo.

Y el modelo de información?

Hasta ahora solo hemos hablado de procesos, pero qué pasa con la información? sus datos? (este es el lado derecho del primer diagrama). A la par de un modelo de procesos, debemos ir configurando un modelo de información que representa la memoria de los procesos, lo que se registra para su uso futuro. En un próximo articulo abordaremos la forma de armar este modelo y, muy importante, la manera de buscar la integración entre ambos.

Por ahora dejo este link a una excelente presentación sobre procesos y su estrecha relación con los datos…o mejor dicho con la información representada en los datos.

Cartografía de Aplicaciones: descubriendo aplicaciones e interfaces

0 comments. Top.

Este es el primero de dos artículos destinados a cubrir el desarrollo de una cartografía de aplicaciones (también conocida como mapa de aplicaciones). Veremos primero cómo identificar y documentar las aplicaciones y sus interfaces, y en el segundo cómo representar gráficamente la cartografía.

 

Cuando usted necesita llegar a un lugar que no conoce, qué es a lo primero que recurre?

Cuando usted necesita reemplazar una aplicación obsoleta o cuando necesita conectar una existe con otras, qué es a lo primero que recurre?

Con certeza la respuesta a la primera pregunta es un mapa. Casi con certeza la respuesta a la segunda es…un signo de interrogación.

Nadie con sentido común optaría por iniciar un viaje a un lugar desconocido sin antes tener un mapa confiable. Sin embargo, algunas organizaciones emprenden “viajes” (cambios o migraciones de sus aplicaciones) virtualmente a ciegas, confiando en encontrar guías y señas en el camino. Si las aplicaciones están muy acopladas entre sí y cambios a una acarrean efectos no previstos (o desconocidos) en otras, el viaje puede tomar un rumbo impredecible y terminar en un lugar equivocado (ejemplos ver aquí o aquí).

En este contexto, la necesidad de contar con la documentación completa, rigurosa y actualizada del conjunto de aplicaciones operacionales de una empresa – la Cartografía de Aplicaciones – está fuera de discusión, o al menos debería estarlo para una organización que se mueva con parámetros de racionalidad, ya que los riesgos que se corren son enormes si no se cuenta con ella.

Identificando aplicaciones

El primer paso para construir una cartografía de aplicaciones es…identificar las aplicaciones. Lo cual nos lleva a una pregunta fundamental: qué es una aplicación? Algunas definiciones previas:

Ejecutable = un archivo que puede ser ejecutado en una CPU.
Componente de software = instancia de una composición de ejecutables.
Aplicación = instancia de una composición de componentes de software y visible para un usuario o área usuaria.

De esta definición se deduce que lo que verdaderamente diferencia a una aplicación de una componente o ejecutable es su visibilidad: esto es, el impacto que produce su funcionamiento (o falta de) dentro del contexto de un proceso de negocio de una empresa. También podemos deducir que una aplicación es una o agregación o suma de partes más simples, por lo que una característica fundamental de las aplicaciones es que son jerárquicas.

Un servidor de aplicaciones (Tomcat por ejemplo) es una aplicación? No, pero sí lo son las aplicaciones que soporta o contiene, siempre que estas sean visibles para algún área usuaria. Lo mismo podemos decir de una base de datos.

Estas definiciones son importantes, ya que son la guía para identificar y clasificar las piezas de la cartografía: En un primer nivel ubicamos a las aplicaciones y en un segundo a las componentes de software que estas emplean. Si fuese necesario podríamos llegar hasta identificar las instancias de ejecutables usadas por las componentes, pero esto quizá haría que nuestra cartografía llegase a tener miles en lugar de solo unas docenas de ítems:

Cómo se descubren las aplicaciones? La respuesta depende del tipo de organización y su grado de (in)madurez. Lo más probable es que no exista documentación formal alguna, por lo que se debe recopilar la información que permita identificar a los potenciales candidatos. El punto de partida es entrevistar a las áreas usuarias ya que según nuestra definición las aplicaciones son visibles a estas. No es una buena idea recurrir al área de Informática o Sistemas (IT) en esta fase de descubrimiento. Solo cuando ya tenemos la visión de las áreas usuarias podemos confirmar o complementar nuestros hallazgos con IT.

Cuando si es necesario recurrir al área IT es cuando tenemos que identificar de que están hechas las aplicaciones, o sea, identificar instancias de componentes de software. Pero antes debemos tener claro cuáles son los diferentes tipos de componentes que conforman la arquitectura de aplicaciones de la organización. Para ello debemos contar con un esquema de cartografía, que identifique cada tipo y sus relaciones, similar a un modelo de datos lógico. El beneficio de hacer esto es que nos va a permitir guiar la búsqueda de información y asignar la categoría correcta a cada instancia de componente a medida que se vayan descubriendo. Este es diagrama es un ejemplo real de un esquema de cartografía (hacer click para visualizar completo):

Cuál es el formato más práctico de documentación? Una planilla Excel es suficiente, donde podemos organizar en hojas los distintos ítems de nuestra cartografía (aplicaciones y componentes) . Las componentes de puede dividir según su tipo: base de datos, servidor de aplicaciones, middleware, etc.

Cuáles son los datos básicos para documentar una aplicación?

Nombre Nombre con la cual es conocida a aplicación en la organización (o el nombre asignado por el fabricante)
ID Identificador único asignado a la aplicación
Descripcion Descripcion de la funcionalidad que ofrece a aplicación al área usuaria, en termino de los procesos de negocio que atiende
Numero de usuarios Cantidad de usuarios que usan a aplicación
Responsable funcional/operacional Persona encargada que la aplicacion cumpla con los requerimientos del área usuaria/que la aplicacion este operativa

Adicionalmente la documentación de la aplicación puede hacer referencia a: SLAs comprometidos, fabricante, versión, año de actualización, etc. También es necesario identificar las instancias de componentes de software que requiere la aplicación para funcionar (recordemos que las aplicaciones son esencialmente jerárquicas). Estas instancias se documentan en hojas separadas dentro de la misma planilla y de acuerdo a la definición dada por el esquema de cartografía que se tenga (base de datos, servidor de aplicaciones, web service, etc.).

Identificando interfaces

Identificar las interfaces de una aplicación es definitivamente una tarea más compleja que identificar aplicaciones y lo que justifica el nombre cartografía. En una organización las aplicaciones no existen en forma aislada: se interrelacionan o integran entre sí a través de múltiples fronteras o interfaces. En los últimos años las aplicaciones han debido integrarse a un ritmo acelerado y de forma cada vez más compleja, ya que el volumen de los requerimientos de negocio supera el ritmo de adaptación de estas. Esto explica el surgimiento de un sinnúmero de tecnologías de integración: SOAP via HTTP (también llamado web service), REST, RPC (cliente/servidor), etc. junto a modelos conceptuales como SOA y BPM a nivel de integración de procesos de negocio.

Un par de definiciones previas:

Canal = medio de encapsulamiento y transporte de datos.
Interfaz = representación de los recursos o datos que una aplicación A intercambia con una aplicación B a través de uno o más canales.

Si tenemos clara esta definición podremos identificar y representar clara y fielmente las interfaces de nuestras aplicaciones. Pero, dónde buscamos las interfaces? Aquí estamos forzados a recurrir al área IT de la organización, ya que son ellos quienes implementan las interfaces entre aplicaciones, no las áreas usuarias. Como principio general debemos asumir que no existe documentación formal de estas, por lo que tendremos que recurrir a una verdadera labor de arqueología para escudriñar cualquier vestigio que nos indique la presencia de interfaces: si tenemos suerte, las personas que las construyeron están disponibles y podremos recurrir a ellos. De lo contrario debemos revisar directamente los programas, algo que puede resultar bastante complejo y largo: documentar las interfaces de la cartografía puede llegar a ser una tarea titánica!

Cuáles son los datos básicos para documentar una interfaz?

ID Identificador único asignado a la interfaz
Nombre Nombre relacionado con el flujo que soporta la interfaz
Descripcion Descripcion del flujo de datos que circula por la interfaz
Aplicación origen ID de la aplicacion origen de los datos
Aplicación destino ID de la aplicacion destino de los datos

Adicionalmente la documentación de una interfaz puede incluir atributos tales como: las componente o ejecutables que implementan la interfaz, la frecuencia con que se ejecuta la interfaz entre las aplicaciones, el tipo de seguridad asociada a la interfaz, etc. Al igual que para las aplicaciones, el esquema de la cartografía define qué se debe documentar para el caso de las interfaces.

Con esto hemos logrado identificar y documentar aplicaciones y sus interfaces en planillas Excel. Sin embargo, la cartografía necesariamente requiere de una componente gráfica para poder visualizar las aplicaciones y entender sus relaciones (interfaces), cosa que abordaremos en la segunda parte de este artículo, junto con alternativas para distribuir, mantener y actualizar la cartografía de aplicaciones.

El Catalogo de Funciones de Negocio

0 comments. Top.

En el artículo Los 5 errores fatales de los analistas de proceso buscamos descubrir cuáles eran los errores más frecuentes a que se ven expuestos los analistas de procesos. En este segundo artículo vamos a centrar el foco en comenzar a desarrollar una metodología que permita evitar estos errores o al menos aminorar su impacto.

Allí el primer error citado fue: Analizar lo que se hace en lugar de lo que se debería hacer. La representación de lo que la organización (cuando hablamos de organización nos referimos a la empresa en su conjunto o a una parte significativa de esta) debería estar haciendo se encuentra en el Catálogo de Funciones de Negocio. Este entregable representa el punto de partida del modelamiento de los procesos de una organización: es el QUÉ dentro de la relación QUÉ/CÓMO.

Catalogo Funciones de Negocio

Qué es una función de negocio?

Una función de negocio es un conjunto de actividades que se debe completar para que la organización pueda funcionar y cumplir con sus objetivos. Dado que deben cubrir todo el quehacer de una organización, estas funciones son esencialmente jerárquicas, y se pueden descomponer en tareas y actividades cada vez más específicas.

Por lo tanto, un catálogo de Funciones de Negocio lo podríamos representar como gran diagrama jerárquico, con varios niveles de desagregación. Cada nodo del diagrama corresponde a una función. Aquellas que no tienen más desagregación son funciones elementales, esto significa que una vez que se inician no se detienen hasta llegar a un resultado final, o se devuelven hasta su estado original, no habiendo estados intermedios relevantes. Si hay niveles intermedios relevantes, no es una función elemental y se puede desagregar más todavía.

La organización debiera mantener visible una ficha por cada función del catálogo: nombre, descripción y objetivo deberían ser sus atributos descriptivos esenciales. El catálogo de funciones de negocio es el punto de encuentro entre los analistas de negocio y el resto de la organización, por lo tanto todo el mundo debe poder consultar y entender lo que allí dice. Excepto quizá por un diagrama jerárquico, organizado convenientemente para la visualización, búsqueda y consulta de funciones, el Catalogo no contiene diagramas.

El Catálogo de Funciones de Negocio representa para una organización el punto de partida para el análisis y modelamiento de sus procesos.

Descubriendo funciones de negocio

Cómo se identifican las funciones que conforman el catálogo? El input principal es la visión que proviene de la dirección de la organización. Ellos son los que tienen claro qué es lo que la organización debería estar haciendo para responder a los requerimientos de sus clientes, organismos reguladores y accionistas. En  Los 5 errores fatales de los analistas de proceso citamos la falta de Visión como uno de los errores fatales en que caen los analistas de procesos, porque no llegan a entender lo que la organización debería estar haciendo, ya sea por inmadurez, por desidia de la dirección organizacional o por que simplemente esta no sabe lo que la empresa debería estar haciendo y se limita a controlar el día a día.

El material que se emplea para identificar y documentar las funciones de negocio proviene fundamentalmente de entrevistas a la gerencia y análisis de documentos estratégicos. Los manuales y procedimientos actuales, documentados o no, no representan un input válido, ya en el mejor de los casos nos dicen lo que organización hace actualmente. Nuestro foco debe estar en lo que esta debería hacer.

Con este input como punto de partida el analista de procesos genera una lista de frases que contienen acciones y objetos claves. Estas se ordenan jerárquicamente y a partir de aquí se pueden ir identificando las funciones de negocio. A medida que recorre a lo “ancho y alto” la visión que proviene de la gerencia, el Catalogo de Funciones crece con nuevos niveles de desagregación. Esta metodología es esencialmente recursiva y podemos llegar así hasta nivel de funciones elementales. A esta altura el Catálogo puede haber crecido desde unas decenas hasta cientos de funciones y pasar de semanas a meses en su desarrollo.

El analista debe determinar cuándo cuenta con el catálogo que satisface las expectativas de su audiencia: mientras mas homogénea sea el catálogo es más compacto, con menos niveles de desagregación. Si es mas heterogénea, el catalogo comienza a crecer en forma explosiva y se hace necesario contar con alguna herramienta de software que permita organizar este crecimiento.

Un ejemplo

La figura (hacer click para una visualización completa) muestra un ejemplo de un catálogo de funciones y cómo se identificaron funciones de negocio para una rama (Vender productos tipo B) a partir de frases claves que se identificaron en entrevistas con la gerencia de la organización y que aparecen en el recuadro de la derecha. El recuadro de la izquierda muestra la identificación de una de las funciones de negocio de la rama, Evaluar Prospectos.

En un primer nivel tenemos funciones completamente genéricas (como Vender en este caso). A partir de entrevistas con el gerente comercial por ejemplo, nos damos cuenta que esta empresa vende según el tipo de producto. Por ello en el segundo nivel hacemos mención específica al tipo de producto. Otras organizaciones pueden vender en función del canal o segmento de clientes, o pueden tener una manera común para vender y las diferencias por canal o segmento se establecen más abajo en jerarquía (son funciones más especificas). El catálogo de funciones debe reflejar estas diferencias. Finalmente para este ejemplo, en un tercer nivel identificamos las 3 funciones que la empresa debería implementar para vender productos del tipo B. Cada función debe estar documentada en su ficha (como Evaluar Prospectos en el ejemplo).

• • • • • •

En el próximo artículo de esta serie veremos cómo a partir de las funciones de negocio diseñamos los mecanismos y procedimientos que implementan las funciones del catálogo: o sea, pasamos del QUÉ al CÓMO…justo donde empiezan los desafíos y problemas para los analistas.

Los 5 errores fatales de los analistas de procesos

0 comments. Top.

A pesar de todo lo que se ha dicho y escrito sobre procesos desde hace mucho tiempo, la función de un Analista de Procesos sigue representando una incógnita en términos del rol que debiese cumplir dentro de una organización. Es este solo un nuevo nombre para los tradicionales analistas de sistema de los 80 y 90? En muchas organizaciones la respuesta es que sí, particularmente en aquellas donde los analistas de procesos son un apéndice del área de Sistemas o Informática. En otras, donde ya existe un área formal de procesos, su rol puede llegar a ser incluso más difícil de precisar, debido al poco claro papel que juegan estas áreas dentro de la organización.

Quizás una forma de evaluar su verdadero rol e impacto dentro de una organización sea identificando los errores que cometen al enfrentar el análisis. Así podemos determinar si estamos realmente frente a un genuino analista de procesos. Y de paso saber si la organización que los emplea está haciendo gestión de procesos efectiva o…efectista (ojo que ambas son perfectamente válidas, pero lo importante es tener claro cuando estamos frente a una u otra y sus efectos en el largo plazo).

Cuáles son los 5 errores fatales que pueden cometer los analistas de procesos?

1. Analizar lo que se hace en lugar de lo que se debería hacer

En general, la manera más simple de fallar en cualquier emprendimiento o proyecto es partir mal, partir desde el lugar equivocado o con el enfoque errado.

En nuestro caso esto se traduce en analizar (documentar, modelar, diagramar, etc.) poniendo el foco en lo que la organización hace en el “día a día” (a lo que algunos se refieren también como el “as is”), creyendo que esto es lo que la organización debería estar haciendo.

Esto es una completa pérdida de tiempo y recursos. Lo que la organización actualmente hace no necesita ser modelado, ya que no es lo que esta necesita!…Documentado si, mejorado tal vez, pero lo que la organización realmente necesita es saber lo que debería estar haciendo para cumplir con sus objetivos. Este es el real valor del análisis y modelamiento de procesos.

Aunque podemos demostrar grandes logros en términos de cantidad de entregables (cualesquiera ellos sean, desde simples documentos hasta complejos diagramas), el proyecto de modelar (o levantar) lo que existe es un esfuerzo inútil. No entender ni aplicar esta simple regla es inaceptable para un verdadero analista de procesos ya que impacta en toda su labor.

Lo que primero debemos descubrir es lo que se debería hacer (referido también por algunos como el “to be”) en una organización para cumplir con sus objetivos. Es muy difícil llegar a definir esto a partir de lo que actualmente se hace. Lamentablemente muchas organizaciones han despilfarrado una gran cantidad de recursos en proyectos de levantamiento de procesos por no entender esta simple regla.

No es lo que hoy se hace lo que nos debe guiar, sino lo que la organización debería estar haciendo para cumplir con sus objetivos

2. Carecer de Visión

Ya sea por inmadurez del analista que se siente intimidado por personas que están siempre “ocupadas” y termina recurriendo a los que mantienen la operación actual buscando entender lo que se debería hacer, o por exceso de confianza del mismo que se se siente seguro de lo que se debería hacer sin tener que preguntarle a nadie, o por desidia de la “plana gerencial”, que simplemente abdica de su responsabilidad de transmitir y validar junto a los analistas la Visión de lo que se debería hacer, lo concreto es que la inercia organizacional puede llegar a hacer imposible tomar la altura necesaria para entender lo que la organización necesita para cumplir con sus objetivos.

Qué pasa si no es posible tener la Visión suficiente para entender lo que se debería hacer? Este es un camino seguro a un fracaso (o a un desastre dependiendo del tamaño del proyecto).

Si no es posible obtener de la organización la Visión para entender lo que se debería hacer, cancele el proyecto

3. Modelamiento de procesos = diagramas de flujo

Este error dice que cuando piense en procesos, piense en diagramas. Y no solo en algunos pocos, sino en decenas o incluso cientos y mientras más símbolos y conectores contengan tanto mejor, así nadie los entiende (partiendo muchas veces por el mismo que los hizo), son imposibles de visualizar o imprimir (conocí un caso donde los diagramas se debían imprimir con plotters para planos debido a su tamaño) y por lo tanto queda el beneficio de la duda. Esto, que suena a una total pérdida de tiempo, es lo que lamentablemente ocurre dentro de muchas empresas que han incorporado la gestión de procesos (o en siglas, BPM) en los últimos años.

Y hablando de siglas y acronismos, la notación BPMN (que muchos en forma equivocada asocian como sinónimo de modelamiento de procesos) no ha hecho sino echar más leña a la hoguera, ya que agregan más símbolos visuales a la paleta, sin control sobre su uso (o abuso) por parte de analistas compulsivos.

Qué pasó con los diagramas Jerárquicos (se acuerda de la descomposición funcional , que era LA técnica de los cursos de SIA de los años 80) ? Los DFD ( Data Flow Diagram, diagramas de flujos de datos ) ? Los diagramas de Estado ? Los diagramas del Modelo de Datos ?

Reducir el modelamiento a elaborar diagramas de un solo tipo, y que muchas veces carecen de una mínima descripción textual, es un error fatal. Los diagramas son tan solo un complemento de una descripción cuando esta se torna difícil de seguir por la gran cantidad de decisiones que se pueden dar en un proceso. Aquí no aplica el conocido refrán “una imagen vale más que mil palabras”, ya que la misión de un analista no es despertar la imaginación de su audiencia, sino reducir la ambiguedad de las distintas interpretaciones que surgen cuando se recorren los diagramas de un modelo.

No obstante esta advertencia, el modelamiento de procesos si requiere de una combinación de diferentes tipos de diagramas que sean capaces de capturar la complejidad de los procesos de una organización. Cuáles son estos tipos y cuándo se deben aplicar ? La respuesta está en la metodología que se use.

Metodología tiene su origen en tres palabras de origen griego: metà (“más allá”), odòs (“camino”) y logos (“estudio”), o sea, el estudio de los caminos que nos conducen a lograr un objetivo. En nuestro caso, qué técnicas (i.e. diagramas) usar y cuando. Sin metodología el proyecto avanzará sin rumbo ni curso.

El modelamiento de procesos requiere de una metodología que dicte el tipo y la oportunidad de los documentos y diagramas a usar según el tipo de proyecto

4. Cómo antes del Qué

Los errores 1, 2, 3 anteriores se amplifican en el cuarto error de la lista: representar el Cómo antes del Qué, o sea, modelar mal lo que no se debe modelar, representando cómo la organización hace lo que actualmente hace….You are doing the wrong thing in the wrong way!!

Desde la perspectiva del modelamiento de procesos, representar cómo se hacen las cosas en una organización es importante, pero siempre que se haga en el momento correcto. Y el momento correcto es una vez que ya entendemos lo que la organización debería estar haciendo.

Siempre modele lo que se debería hacer antes de cómo se debería hacer: Qué primero, Cómo después

No modele cómo la organización hace lo que actualmente hace pretendiendo que esto es lo que debería hacer

Si sigue estas 2 simples reglas se ahorrará mucho tiempo y esfuerzo invertidos en modelos de valor marginal, ya que se genera un gran volumen de diagramas que no permiten entender lo que se debería hacer, produciendo en cambio modelos mucho más compactos y valiosos para la organización, que nos muestran con claridad lo que la ella debería hacer para cumplir con sus objetivos.

5. Separar los procesos de la data

El quinto error dice relación con separar el modelamiento de procesos del de los datos. Mientras que los analistas de proceso piensan que no tienen porque involucrarse con los datos, los analistas de datos piensan lo mismo…de los procesos. Resultado: una pobre infraestructura de datos de la organización, con múltiples instancias de un mismo concepto repartida en muchas bases de datos distintas.

La causa de esto es que la gestión de los datos es propiedad del área IT/Sistemas de una organización y la de procesos de la de Procesos (si existe): lamentablemente ambas están (totalmente) desconectadas. También influye la capacidad de los analistas para enfrentar tanto el modelamiento de procesos como el de datos.

Ante esta realidad, las organizaciones han debido crear procedimientos, personal y sistemas redundantes para poder convivir con este divorcio entre data y procesos.

La data y los procesos son inseparables. La data que requiere mantener una organización es la necesaria para soportar sus procesos de negocio, nada más ni nada menos

• • • • • •

Si bien en algunos de los errores de esta lista no hay mucho que un analista pueda hacer (como la falta de visión de la organización sobre lo que debería estar haciendo para cumplir con sus objetivos), en temas metodológicos si hay mucho que se puede aprender. En otros artículos ( El Catalogo de Funciones de Negocio y Procesos, Mecanismos y Procedimientos de Negocio) veremos como abordar varios de estos errores desde la perspectiva de una Metodología de Modelamiento de Procesos.

(Este artículo está inspirado en el post  “BAFFEs: Business Analysts’ Five Fatal Errors” de John Owens, Integrated Modelling Method)