Mostrando entradas con la etiqueta Business Analysis. Mostrar todas las entradas
Mostrando entradas con la etiqueta Business Analysis. Mostrar todas las entradas

lunes, 22 de octubre de 2018

Esa 'cosa' llamada reglas de negocio


El término 'reglas de negocio' es frecuentemente utilizado en ciertos contextos: fundamentalmente, aunque no únicamente, en la gestión de procesos de negocio, en el 'business analysis' o en la especificación de software empresarial.

Se trata de un concepto importante pero, probablemente, algo ambiguo y no siempre utilizado ni con rigor ni con un significado único. Vamos a hacer una pequeña reflexión sobre el mismo esta idea de reglas de negocio y realizar algunos apuntes sobre ese concepto.

Podríamos decir, improvisando un amago de definición, que las reglas de negocio son:
directivas explícitas y detalladas sobre cómo se deben hacer ciertas cosas en una empresa u organización. 

Dos apellidos en forma de adjetivos son son aquí importantes:

  • El apellido 'de negocio' que se le pone a la palabra reglas nos hace ver que esas directivas no son de naturaleza tecnológica, sino decisiones sobre operativa al margen del soporte técnico que se pueda prestar a esas directivas.

  • El apellido 'explícitas y detalladas' que añado yo a directivas es importante para tener claro que una regla de negocio no es una 'filosofía general' acerca de cómo debe funcionar la empresa. No son indicaciones del tipo 'se debe tratar con corrección al cliente' o 'buscamos el máximo valor para el accionista'. No, las reglas de negocio son explícitas, claras, detalladas y procedimentales, es decir, no dejan margen a la duda sobre cómo se aplican. Podrían de ser del tipo: 'Sólo concedemos préstamos por encima de un importe X si el scoring crediticio del cliente se encuentra entre Y y Z'.

Aunque las reglas de negocio son, eso, de negocio, lo cierto es que al tratarse de reglas explícitas y detalladas permiten que se las implemente con tecnologías o sistemas informáticos tales como ERP (Enterprise Resource Planning) CRM (Customer Relationship Management), Workflows, BPMS (Businss Process Management System) , RPA (Robotic Process Automation), etc Y por eso se habla tanto de reglas de negocio en el contexto de la tecnología.

Las reglas de negocio puede establecerse como una condición, como una tabla, como un árbol de decisión, etc En el libro 'Dynamic SOA and BPM' su autor, Marc Fiammante, se detiene unos párrafos a hablarnos de las reglas de negocio y a proporcionar una tipología de reglas. Estos son los ocho tipos de reglas que nos identifica:

  • Regla simple: Es el esquema condicional: si se cumple una condición, se sigue una acción o consecuencia.

  • Conjunto de reglas: Se realiza la acción o consecuencia si todas las condiciones del conjunto se cumplen, sin que exista ningún tipo de orden.

  • Secuencia de reglas: Muy parecido al anterior pero en este caso las condiciones se evalúan en un orden o secuencia.

  • Tablas de decisión: La acción o consecuencia depende de más de una condición. Esta situación se modela como una tabla en cuyas columnas encontramos las condiciones y en filas las verdaderas reglas, es decir, las posibles combinaciones de condiciones y la acción o consecuencia que se sigue.

  • Plexo (red) de reglas: Consiste en un entramado de reglas donde cada regla depende de unos predecesores (más de uno; en caso contrario sería una secuencia). La acción o consecuencia depende de las reglas 'afluentes' a la última.

  • Otras reglas de inferencia: Un caso algo desestructurado en que existen varias reglas a combinar pera determinar la acción o consecuencia pero sin una estructura clara de dependencias.

  • Flujo de reglas: Es una suerte de workflow que incluye ramificaciones paralelas y puntos de decisión donde la evaluación de cada regla depende de lo que haya sucedido antes en ese workflow.

  • Procesado complejo de eventos: Caso en que se añaden dependencias temporales y de eventos.
El propio autor advierte de que no existe una clasificación estandarizada de reglas de negocio y que lo anterior es sólo un conjunto de las, a su entender, más habituales.

Se puede apreciar el carácter algorítmico que tiene esa formulación de tipología de reglas. Eso ilustra y confirma a un tiempo, por un lado, el carácter explícito y detallado y, por otro, la tendencia hacia la implementacion informática  de esa 'cosa' llamada reglas de negocio.


miércoles, 17 de octubre de 2018

Siete situaciones y media en que se necesita descubrir y modelar un proceso de negocio

Hace ya algunas semanas hablábamos de la importancia de modelar un proceso de negocio. En el artículo de hoy volvemos al tema para ver siete situaciones concretas en que nos conviene, se necesita más bien, descubrir y modelar un proceso de negocio.

Y lo hacemos de la mano del libro clásico de BPM 'Business Process Management. A rigorous approach' de Martyn Ould.


Antes de hablar de modelado, conviene recordar lo que se denomina la etapa de descubrimiento, y que no es más (ni menos) que extraer el conocimiento  acerca de lo que sucede realmente en la empresa (lo que se denomina 'elicitación' en la nomenclatura de origen sajón propia del business analysis). Se trata de un conocimiento que, evidentemente, está implícito, puesto que los profesionales que integran esa compañía ejecutan de forma constante procesos, sean conscientes de ello o no. Sin embargo, esos procesos con frecuencia no sólo no están estandarizados y gestionados sino que, incluso, no son conocidos de una forma explícita. Esa explicitación de los procesos es, precisamente, en lo que consiste el descubrimiento.

El propio Martyn Ould nos dice, de forma muy clara, lo siguiente:

It is surprisingly common for an organization not to have a clear idea - or sometimes any idea - of how certain things are done.

Así es. En el devenir del día a día, muchas veces las organizaciones no son conscientes realmente de su propio funcionamiento. De ahí la necesidad del descubrimiento.

El modelado es en realidad como un subapartado del descubrimiento (y del diseño posterior) en que se trazan los procesos descubiertos con una notación formal con su sintaxis y su semántica. Aunque dicho así lo del modelado pueda sonar muy complicado, no es más que dibujar el proceso usando unos elementos predefinidos (recuadros, rombos, flechas y cosas así) con un significado, eso si, muy preciso.

Entendido esto, veamos ya cuáles son esas situaciones que nos indica Martyn Ould en que se necesita descubrir y modelar un proceso:

  • Cuando se necesita una visión compartida sobre lo que la empresa hace y cómo lo hace

  • Cuando se necesita adoptar un método o enfoque común en toda la empresa para hacer algún tipo de trabajo o tarea. Esto puede ser, por ejemplo, consecuencia de la puesta en marcha de un sistema de gestión de la calidad o, incluso, la preparación para una certificación del tipo de ISO 9000.

  • Como parte de un programa de mejora continua, siguiendo la filosofía, por ejemplo, de la calidad total (TQM, Total Quality Management)

  • Cuando vamos a lanzar un programa de rediseño radical, de procesos , organización y operativas, siguiendo las directrices de la reingeniería de procesos (BPR, Business Process Reengineering)

  • Situaciones en que tenemos que alinear unos sistemas de información orientados al dato, con la dinámica de la empresa.

  • Situaciones en que se va a implantar un sistema de workflow para gestionar los flujos de trabajo de la empresa

  • Situaciones en que se va a implantar una nueva tecnología de proceso (como un BPMS, Business Process Management System) tanto para implementar los procesos como para dar soporte a la dirección

Como se puede observar, los tres últimos casos que menciona Martyn Ould, tienen que ver con tecnología y sistemas de información. El libro en que esto se expresa es ya algo antiguo (data de 2007 su última edición), así que no puede recoger los últimos avances en tecnología. Por eso me atrevo a enmendar ligeramente a Martyn Ould con 'media' situación adicional que, estoy seguro, el propio Ould tendría en cuenta si reescribiese hoy en día su libro:

  • Como paso previo a la realización de acciones de digitalización, automatización u optimizaciones de proceso basadas en tecnología. Esto puede abarcar, en realidad, varios casos. Así, el caso más claro sería, por ejemplo, como paso previo a la robotización de tareas usando ya RPA (Robotic Procesc Automation) o, incluso, interfaces conversacionales o chatbots. También sería el caso cuando queremos introducir tecnología de Big Data, ya sea, por ejemplo, para la obtención de 'insights' del proceso, ya sea incluso como elemento operativo mediante el CEP (Complex Event Processing). E, igualmente, sería un paso a realizar para detectar dónde introducir tecnología cognitiva (inteligencia artificial) para toma inteligente de decisiones usando, por ejemplo, machine learning o para captura avanzada de datos mediante visión artificial, reconocimiento de lenguaje natural, etc

Todas las situaciones que identifica Martyn Ould son excelentes ejemplos de cuándo realizar ese descubrimiento y modelado. Sin embargo, debo reconocer que, dado que me apasiona la tecnología, la que más me motiva e ilusiona ahora mismo en mi actividad profesional es esta última media situación que me he permitido el lujo de añadir y que, en cierto sentido, no es más que Transformación Digital aplicada a los procesos de negocio.


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.


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


lunes, 15 de diciembre de 2014

Cinco oportunidades para mejorar la operación de un negocio

Mucha literatura existe acerca de la mejora de procesos de negocio, acerca de BPM, BPI, Lean, Six Sigma, etc.

Y no sólo se trata de literatura: creo que es realmente importante que las compañías mejoren todo lo posible sus procesos de negocio en busca de la máxima calidad, eficiencia y satisfacción del cliente.

Sin embargo, la mayor parte de la literatura se centra más en generalidades y metodologías que en contar realmente cómo se mejora un proceso de negocio.

Por ello me interesa ir identificando y censando todas las técnicas o ideas al respecto.

Así lo hacía hace unas semanas, por ejemplo, en el artículo 'Ideas para mejorar procesos de negocio'

Hoy reflejo algo relacionado y que encuentro en el BABOK (Business Analysis Book of Knowledge), la 'biblia' del Business Analysis. Aunque no se centra específicamente en procesos de negocio, anda bastante cerca cuando en el capítulo dedicado a análisis de requisitos, nos identifica las oportunidades de mejora de la operación del negocio.


Éstas son las ideas que nos sugiere:

  • Automatizar o simplificar el trabajo de las personas: priorizando en la automatización las tareas sencillas sometidas a reglas estrictas.

  • Mejorar el acceso a la información: la idea es que, disponiendo los profesionales de mucha información, se disminuya la necesidad de la especialización.

  • Reducir la complejidad de las interfaces: tanto en la interfaces entre sistemas como humanas.

  • Incrementar la consistencia del comportamiento: haciendo que los profesionales se comporten de la misma manera ante la misma situación, especialmente cuando se trata de dar la cara ante clientes que no entienden las diferencias.

  • Eliminar redundancias: proporcionando la misma solución cuando diferentes stakeholders presentan necesidades comunes
Estas sugerencias siguen siendo todavía bastante genéricas. No obstante, si a partir de estas y otras parecidas propuestas somos capaces de confeccionar una suerte de checklist y ´esta se repasa de manera crítica ante cualquier proyecto de mejora de procesos, creo que puede dar buen resultado.

Seguiré, por tanto, intentando capturar estas ideas y propuestas.

Artículos de este blog relacionados

viernes, 5 de diciembre de 2014

Estudiando Business Analysis con Barbara Carkenord

'CBAP/CCBA Exam Prep' es, como su propio nombre indica, una guía de estudio para la obtención de las certificaciones CBAP y CCBA en Business Analysis que ofrece el IIBA (international Institute for Business Analysis).

Se trata de un libro que en su presentación, estilo y metodología reproduce el modelo del afamado 'PMP Exam Prep' de Rita Mulcahy en el campo de dirección de proyectos y de preparación de la certificación PMP.

Un poco sorprendente, eso sí, es que el libro no sigue el orden de temas del BABOK (Business Analysis Body of Knowledge) que es la guía oficial del IIBA sino que la autora elige un esquema más acoerde, entiendo, con su entendimiento de lo que es el Business Analysis aunque, por supuesto, mantiene una referencia continua al BABOK.

En concreto, los nueve capítulos que componen el libro son:
  • 'Tricks of the trade for studying your exam'
  • 'Business analysis key concepts'
  • 'Enterprise analysis'
  • 'Elicitation'
  • 'Requirements analysis'
  • 'Requirements management and communication'
  • 'Solution assesment and validation'
  • 'Business analysis planning and monitoring'
  • 'Putting it al together'
De la lista de capítulos anteriores se observan algunos que sí mantienen correspondencia con los del BABOK, quizá los que corresponden a las actividades nucleares como son 'Enterprise analysis', 'Elicitation', 'Requirements analysis', y'Solution assesment and validation'. A cambio, mientras el BABOK dedica capítulos enteros a las técnicas de Business Analysys y las competencias del analista, este libro diluye estos dos aspectos entre el resto de capítulos y, a cambio, dedica foco específico a la gestión y cmunicación de requsitos o a la planificación y monitorización. Una elección que, aunque desde u punto de vista de tratamiento de la materia puede ser acertado, es algo arriesgada desde un punto de vista pedagogico para un libro expresamente orientado a preparar un examen.

Se acompaña cada capítulo de los principales se una serie de preguntas de ejemplo similares a las del examen y con su respuesta correcta.

Un libro ordenado, austero y riguroso, como corresponde a su objetivo. La experiencia de los candidatos que lo utilicen como guía de estudio será la que deberá marcar, evidentemente, si cumple o no su misión.

Barbara Carkenord

(Fuente: Traducción y ligera elaboración propia a partir de perfil en IIBA)

Barbara A. Carkenord tiene más de 25 años de experiencia en Business Analysis y es una de las fundadoras de la industria de la formación en Business Analysis. Es autora del bestseller mundial 'Seven steps to mastering Business Analysis así como de 'CBAP®/CCBA® Exam Prep, Premier Edition', publicada por RMC Publications en Abril de 2012.

Puedes conocer más de la autora visitando su perfil en LinkedIn.

Ficha técnica:

EDITORIAL: RMC Publications
AÑO: 2012
ISBN: 978-1-932735-59-8
PAGINAS: 383

Artículos de este blog relacionados

miércoles, 3 de diciembre de 2014

Dirección de proyectos y democracia: una paradoja

Nunca se sabe de dónde puede salir una reflexión.

La Dirección de proyectos es una disciplina, en mi opinión, valiosísima. Interesante en su teoría y casi insustituible en su práctica. Pero no es, quizá, donde uno esperaría encontrar profundas reflexiones sobre la sociedad.

Otra disciplina, que percibo como una especie de hija adoptiva de la anterior, es el Business Analysis. En la teoría de esta disciplina, muy ligada a proyectos de mejora de procesos y, sobre todo, de desarrollo e implantación de sistemas de información,  se recogen aspectos concretos heredados de la disciplina de la dirección de proyectos.

En cierto sentido, el BABOK (Business Analysis) es heredero del PMBOK (Dirección de proyectos).

Bueno, el caso es que un aspecto concreto, de otros muchos que hay, en que he visto un casi total alineamiento entre ambos es cuando se trata de la resolución de conflictos y la decisión en grupos.

Muy en concreto, leyendo el libro 'CBAP/CCBA Exam Prep' de Barbara Carkenord, en el capítulo dedicado a elicitación y las técnicas aplicables, me encuentro los métodos de decisión en grupo.

Son estos:
  • Consenso
  • Compromiso
  • Mayoría
  • Unanimidad
  • Decisión autocrática

Sólo por sus nombres es fácil reconocer de qué nos hablan. Y si nos olvidamos que partíamos de la dirección de proyectos o del Business Anlysis reconoceremos algunos de los métodos que se utilizan en muchos ámbitos sociales y, en concreto, en los mecanismos e instituciones propios de la democracia.

Sin embargo, hay algo que me ha llamado la atención, y que motiva este post.

Cuando la fuente citada valora los diferentes métodos para conseguir una decisión en grupo ¿cuál diría el lector que considera el más desaconsejable, el que conviene evitar si es posible?

Pues el tercero: la regla de la mayoría, que es algo tan simple como adoptar como decisión lo que diga la mayoría.

¿Observa el lector la paradoja?

La mayoría es el mecanismo nuclear de la democracia. Gobierna, salvo excepciones, el partido que ha obtenido la mayoría. Y las decisiones en Parlamentos, Ayuntamientos y demás instituciones democráticas se toman... por mayoría.

Pero la dirección de proyectos nos lo desaconseja.

¿Qué tiene de desaconsejable este método? Simplificando un tanto, la sensación de ganador-perdedor. Los pertenecientes a la mayoría se sienten satisfechos, los de la minoría frustrados. No hay enriquecimiento sino una suerte de lucha. No son buenos sentimientos, no para un grupo de trabajo, no para un equipo.

¿Sí para una nación? ¿Si para una sociedad?

Hay aspectos prácticos que pueden explicar el por qué del uso de la mayoría en las instituciones democráticas pero ¿no resultan reconocibles esos sentimientos de frustración y derrota en nuestra sociedad democrática? ¿No confirman esos sentimientos los consejos de la dirección de proyectos?

Paradójico... o quizá no tanto...

miércoles, 15 de octubre de 2014

De requisitos, salvoconductos y venta consultiva

La construcción de un sistema de información, de un desarrollo de software, pasa por una fase inicial de especificación de requisitos. No importa demasiado la metodología (aunque las Agile introducen importantes matices) esta fase siempre se produce.

Esto es así, al menos en empresas grandes con cierto tamaño y con un departamento de TI capaz de de construir sus propias aplicaciones o bien en el caso de integradores trabajando para otras empresas.

La especificación de requisitos recoge las necesidades que las unidades 'usuarias' precisan del nuevo sistema. Y esa especificación constituye una guía para el equipo de análisis y construcción,una guía de lo que tiene que hacer y una guía para la estimación de esfuerzos y tiempos.

De esta forma, la especificación se constituye en una suerte de contrato entre el área usuaria, que actúa de cliente (interno o externo), y el equipo de TI (propio o integrador).

Dicho así, la cosa parece correcta, ajustada a metodología, ajustada a derecho, controlada,  documentada, planificable.

¿Si?

No

Realmente no.

No sé si se trata de una característica (una limitación) de la cognición humana, no sé si es incomprensión de lenguajes lejanos como son los del negocio frente a TI, no sé si es falta de rigor, interés, tiempo o qué, pero la experiencia enseña, al menos la mía lo hace, que una unidad de negocio no es capaz de expresar completamente lo que necesita de un sistema de información por adelantado, que no es capaz de concretar todas y cada una de sus necesidades de forma totalmente coherente y completa y que no siempre es capaz de imaginar cómo será el sistema que está demandando una vez construido.

El error: simplemente tomar nota
Por eso, cuando la unidad peticionaria ve por primera vez el sistema, o un prototipo de pantallas, o cuando en el transcurso del trabajo el equipo de TI le hace entender mejor lo que están haciendo, se producen decepciones, cambios de opinión, sustos, nuevas peticiones o enmiendas a las ya realizadas. Y eso hace daño al propio área peticionaria como al equipo de TI, un daño que se traduce en sobrecostes y retrasos... y en un coste emocional. 

Por eso, los ciclo de ingeniería software son cada de vez de naturaleza más iterativa, y por eso el auge de las metodologías agile que llevan casi al límite esa iteración e integración continua.

Pero, metodología aparte, esa realidad creo que exige de los equipos de TI, muy especialmente de los business analysts, o de los analistas funcionales, una actitud mucho más honrada y proactiva, mucho más servicial, mucho más cercana a su cliente interno o externo.

He visto, por desgracia, utilizar los requisitos como salvoconducto. Argumentar que el área usuaria pidió eso como consta en el documento de requisitos... y hacer pagar a ese área usuaria por su error. Pagar en el sentido económico y en la vergüenza de reconocer un error.

Desde un punto de vista estrictamente formal, puede que el equipo TI tenga razón...pero es un gravísimo error como unidad.

Hace ya mucho tiempo escuché la frase (no recuerdo donde) que decía: 

No vale la pena tener razón contra tu cliente

Lo mismo aplica a este caso. No le vale de nada al integrador o equipo de TI tener razón, en lo formal, frente a su cliente interno o externo, frente a las áreas usuarias porque, como decía el gran James Rumbaugh.

If the system does exactly what the customer asked for, but that does not meet the customer real needs, you will be blamed anyway.  

A corto plazo, paga el cliente con euros, tiempo, impacto en su actividad y vergüenza.

Pero a medio plazo paga la organización de TI o el integrador en forma de desconfianza, desprestigio y búsqueda de alternativas que la esquiven.

El modelo: la venta consultiva
Creo que, por honestidad, pero también por su propia supervivencia, los equipos de TI deben dejar de usar los requisitos como un salvoconducto frente a sus clientes. Deben aprender a entender a éstos sus clientes, y guiarles hacia la consecución de unos requisitos que realmente recojan las necesidades del negocio.

Y creo que el modelo podría ser el de la venta consultiva. Al igual que cuando se intenta vender productos complejos a grandes cuentas, el vendedor se convierte realmente en un consejero, un orientador de su cliente, de la misma forma los analistas deben ayudar a su cliente, el área usuaria, a elegir los requisitos que realmente necesitan. Todos los requisitos que necesitan y sólo los requisitos que necesitan y haciéndoles entender perfectamente lo que están pidiendo.

Así, hacen un favor a sus clientes... y, de paso, se hacen un favor a sí mismos.

viernes, 26 de septiembre de 2014

Explorando el BABOK Versión 2.0

La guía 'Business Analysis Body of Knowledge (BABOK)' pretende ser el compendio y la estructuración de conocimiento dentro de la disciplina llamada Business Analysis (Análisis de negocio) y material de estudio fundamental para las certificaciones CBAP y CCBA.

Es una guía heredera en su estilo y organización del afamado PMBOK (Project Management Body of Knowledge) del ámbito de la dirección de proyectos.

El enfoque de estas guías (tanto el PMBOK como este BABOK que nos ocupa) es algo especial puesto que no profundizan demasiado en el conocimiento que exponen y no incluyen ejemplos, ejercicios o cualquier otro tipo de material pedagógico. Se trata, más bien, de una forma de estructurar el conocimiento de una disciplina y su vocabulrio fijando tan solo unos pocos principios básicos, de un modo que aspira a ser riguroso pero, al tiempo, muy abierto.

Por ello, si se lee el libro sin saber realmente lo que cabe esperar, puede ser decepcionante. La profundización en el entendimiento tanto de la guía como de la disciplina en general, debe ir acompañado por un lado de experiencia real y, por otro, de la lectura o estudio de materiales complementarios más específicos.

Por otro lado, en el caso de la versión 2.0 de este BABOK, da la sensación de que tanto a la disciplina del Análisis de Negocio, como al manual en sí mismo, le falta aún un cierto grado de madurez. Nos encontramos, en apariencia, ante una disciplina aún no del todo establecida, con fronteras algo difusas con otras profesiones y con un conjunto de técnicas aún por consolidar. De hecho, en el momento de redactar estas líneas, se encuentra ya en avanzado estado de elaboración la versión 3.0.

Este 'Business Analysis Body oh Knowledge (BABOK)' es lectura (y estudio) obligado si se pretende obtener una certificación en el campo del Análisis de Negocio y una forma de conocer los conceptos e ideas que se van convirtiendo en estándar 'de facto'. No es, sin embargo, una lectura apasionante en sí misma, ni tampoco el mejor material pedagógico para profundizar en el conocimiento de los temas que aborda.

Ficha técnica:

miércoles, 10 de septiembre de 2014

Arquitectura empresarial: una definición y cuatro frameworks... más uno.

Por diversos motivos voy adquiriendo creciente curiosidad (y experiencia práctica) por el concepto de arquitectura empresarial y será un tema que de vez en cuando irá apareciendo por este blog.


A modo de aperitivo, y para ayudar a centra algo el tema, extraigo de esa fuente una definición de Arquitectura empresarial (Enterprise Architecture), una definición que, en realidad fue aportada en 2007 por el director de MIT's Center for Information Research. La definición reza: 

The organizing logic for key business process and IT capabilities reflecting the integration and standarization requirements of a firm's operating model.

No es un concepto sencillo de asimilar cuando no se ve un desarrollo real del mismo, pero añadiré a la definición el comentario de que, en general, una arquitectura empresarial abstrae y modela una compañía con especial foco en sus procesos, su información y sus sistemas. 

Es un concepto muy cercano al mundo IT y de los Sistemas de Información aunque estrictamente hablando una arquitectura empresarial puede aportar otros usos y beneficios muy relevantes.

Existen varios frameworks o modelos de referencia. El libro de Guy Sereff menciona cuatro, que son los siguientes:

Voy a atreverme a incluir un quinto modelo...aunque seguramente existan otros. Ese quinto modelo procede del sector específico de las telecomunicaciones e inició su andadura antes de que ni siquiera existiese el concepto de arquitectura empresarial, pero su evolución se ha dirigido claramente hacia convertirse en un modelo de arquitectura empresarial para el sector de las telecomunicaciones. Esta quinta arquitectura es Frameworx, un marco propuesto por TeleManagement Forum y un marco al que quizá algunos profesionales del sector seguramente reconocerán más fácilmente por el nombre de uno de sus elementos, el mapa de procesos, el popular eTOM.


Mucho más hay que decir sobre este concepto de arquitectura empresarial y los diferentes modelos, pero sirva este post como una simple introducción para centrar un poco el tema... y espero que para general alguna curiosidad.

viernes, 8 de agosto de 2014

Habilidades de supervivencia para el Business Analysis con LeAnn M. Simonson

En 'The business analyst's survival guide' su autora, que posee las certificaciones PMP (Project Management Professional) y CBAP (Certified Business Analysis Professional), ofrece una perspectiva del análisis de negocio centrada en las habilidades personales del analista, las denominadas habilidades 'soft', y con especial foco en las situaciones conflictivas que el ejercicio del análisis de negocio suele encontrarse.

Tras revisar varias de esas situaciones y cómo manejarlas, nos ofrece un sencillo marco de actuación, algo así como una metodología ligera para afrontarlas.

El libro se estructura en doce capítulos y un apéndice.

Los dos primeros capítulos sirven para centra la temática y así, en el primero, 'Interpersonal dynamics and repeat behavior patterns', resalta el carácter repetitivo de los problemas a que un analista de negocio debe enfrentarse. Ese carácter repetitivo hace que se puedan encontrar patrones de conducta. En el segundo, 'Soft-skill survival tips', nos anticipa diez pistas, diez conductas genéricas, que nos pueden ayudar a superar o evitar los conflictos (construir una buena relación, asegurarse de entender a los stakeholders, priorizar las 'batallas', etc).

En los siguientes ocho capítulos, se analizan patrones concretos generalmente a partir de una situación real. La estructura de todos estos capítulos es muy similar:
  • Se expone una situación o experiencia real frustrante
  • Se analiza por qué resultó frustrante
  • Se analiza el riesgo o problema que conllevaba
  • Se busca la situación deseada, la que nos gustaría que fuese real
  • Basada en la experiencia actual de la autora, se intenta analizar cómo hubiéra actuado sabiendo lo que ahora sabe
  • Se extraen las lecciones esenciales
  • Se busca un anti-patrón (patrón negativo), es decir una conducta genérica donde se enmarca este problema y se busca el patrón positivo para gestionar la situación
Con esa idea, se afrontan los siguientes ocho capítulos: 'They don't get business analysis' (otros profesionales como directores de proyecto o personal técnico no entienden el rol del analista de negocio), 'I am not getting the respect I deserve' (no se respeta el trabajo del analista de negocio o se intenta obtener de él algo erróneo), 'People are difficult' (problemas de relación interpersonales), 'Eliciting requirements is painful' (dificultades con los stakeholders para fijar sus requisitos), 'Working with technical staff is painful' (dificultades de relación o de diferenciación de roles con el staff técnico), 'The management of the project is driving me crazy' (dificultades con la dirección del proyecto por presiones de tiempo, malas decisiones u objetivos poco claros), 'The business analysts are not working as a team' (dificultades dentro del propio equipo de análisis de negocio por competitividad, solapes, etc) y 'I'm struggling' (dificultades por sobrecarga de trabajo, falta de formación, etc).

Tras los ejemplos vistos en los capítulos anteriores, en el penúltimo, 'The business analysis challenge response framework', la autora nos ofrece su modelo de referencia para enfrentarse al tipo de problemáticas vistas. El modelo de referencia, muy simple, consta de tres preguntas primarias con subpreguntas. El modelo pide que nos hagamos y contestemos a esas preguntas. Las preguntas son:
  • ¿Cuál es exactamente el desafío a que me enfrento? Algunas preguntas secundarias dentro de esta pregunta primeria serían: ¿Por qué me importa? ¿Qué impactos tiene en mi o en otros? ¿Qué riesgos corro? ¿qué impacto tiene en el negocio? ¿y en mi trabajo?

  • ¿Qué me gustaría que fuese cierto (a qué aspiro)? con algunas preguntas secundarias como ¿Cómo beneficiaría al negocio? ¿Cómo me beneficiaría a mi o a otros? ¿Conozco realmente la fuente del problema?

  • ¿Cómo llego hasta allí? con alguna pregunta secundaria como ¿Tengo el tiempo necesario? ¿Tengo los conocimientos necesarios? ¿Tengo las habilidades necesarias? ¿Tengo el soporte que necesito?
En el último capítulo, 'Messages not to miss from this book', se nos ofrecen unas sencillos y breves consejos como cierre.

Finalmente, se incluye un largo apéndice, 'Individual challenges and possible response strategies' en que, aplicando de una forma absolutamente sistemática (y, hay que decirlo, bastante repetitiva) el modelo de referencia, se analizan una larga serie de problemáticas (muchas de las cuales ya se habían abordado de una forma u otra en el cuerpo central del libro).

'The business analyst's survival guide' es un libro correcto aunque sin brillo cuyas dos mayores virtudes son las de destacar la importancia de las habilidades 'soft' en en análisis de negocio y el proponer un enfoque sistemático para afrontar las dificultades del día a día y usar esas habilidades 'soft' para hacerlo.

LeAnn M. Simonson

(Elaboración propia a partir de perfil en Linkedin)

LeAnn M. Simonson es una consultora norteamericana en el campo del Business Analysis y la dirección de proyectos.

Estudió en la Universidad de Minesotta-Twin Cities de donde tiene un máster en trabajo social y otro en ciencias de la computación. Además, LeAnn mantiene las certificaciones PMP del Project Management Institute y CBAP del International Institute for Business Analysis.

Inició su andadura profesional en 1991 y tras pasar por varias compañías ejerciendo como analista de negocio, desde 2011 es propietaria y consultora principal de 'Simonson Consulting' una firma dedicada a la consultoría y la formación en el campo del business analysis.

LeAnn es autora del libro 'The business analyts's survival guide'

Puedes saber más sobre el libro y el autor consultando su perfil en LinkedIn

Ficha técnica:

EDITORIAL: Create Space
AÑO: 2012
ISBN: 978-1466431768
PAGINAS: 208

Artículos de este blog relacionados

viernes, 1 de agosto de 2014

Siempre positivo. Nunca negativo.

Siempre positivo, nunca negativo...

Así sonaba (bueno, en realidad la frase era al contrario, 'siempre negativo, nunca positivo' y sonaba bastante diferente debido a su marcado acento) la famosísima frase de Louis Van Gaal, el holandés a la sazón entrenador del F.C. Barcelona...

Probablemente tuviera razones para su enfado Van Gaal, no lo recuerdo, pero sin embargo, erraba en su reacción...como casi siempre supone un error una reacción airada por más cargada de razones que eventualmente se pueda encontrar.

Los entornos laborales tienden a ser muy cerrados, y esos entornos cerrados generan amistades y afabilidades, sí, pero también enemistades, malos entendidos, rencillas, envidias... y ello puede conducir a maledicencias, a rencores y, en definitiva, a un mal funcionamiento de los equipos y las organizaciones.

Se trata de un terreno donde rozan lo profesional y lo personal pero, probablemente, cuando de un entorno laboral hablamos, todo tiene su vertiente profesional... y como tal debemos enfocarlo

En la medida en que problemas personales afectan al rendimiento individual, de un equipo o de toda la organización dejan de ser estrictamente profesionales.

No sólo nuestro equilibro e incluso felicidad personales nos piden una respuesta positiva y constructiva, también la profesionalidad nos lo exige.

Así nos lo recuerda LeAnn Simonson en su libro 'The business analyst's survival guide' que trata precisamente de las habilidades soft de un analista de negocio. Dado que la profesión de business analyst está altamente sujeta a la interacción, es terreno abonado para este tipo de rencillas.

El consejo que nos ofrece Somonson es claro:
Resist the temptation to have that internal dialogue about how frustated you are (which sometimes ends up as gossip around the water cooler). Instead, focus your internal dialogue on how you can build bridges, support strenghts, and work collaboratively to achieve goals.

¿Está claro, no?

Nada de maledicencias ni rumores, y nada de quedarse rumiando las ofensas. Al contrario, buscar acercamientos y entendimientos, tender la mano...

Ser, en fin, siempre positivo, nunca negativo...

miércoles, 30 de julio de 2014

¿Para qué vale un modelo de referencia? Ocho buenas razones.

Cuando nos enfrentamos a un trabajo de análisis o de diseño, suelen surgir como ayuda un conjunto de modelos más o menos ordenado A esos modelos los denominaré de forma algo genérica 'modelos de referencia' aunque reciben otros muchos nombres como 'framework' o, simplemente, modelo.

¿Qué entiendo por un modelo de referencia?

Necesitaría más tiempo de reflexión y de contraste con literatura técnica o empresarial de todo tipo para extraer una definición 'perfecta', pero de forma bastante improvisada, podría definir un modelo de referencia como:

Una estructuración de carácter generalmente gráfico o semigráfico de un área de conocimiento que recoge y organiza de forma compacta los aspectos más relevantes de ese área de conocimiento.

Este tipo de modelos los encontramos en muchas disciplinas pero, por intentar aclarar algo la idea elegiré varios ejemplos del mundo de la tecnología y del management (los temas que predominan en este blog).

Modelos en capas ISO/OSI
Hace ya muchos años, el sector de las telecomunicaciones dispone y utiliza frecuentemente el modelo en capas ISO/OSI que estructura en siete niveles (capas) los diferentes servicios y protocolos de comunicación. Aunque no sigue estrictamente el modelo ISO/OSI, la torre de protocolos TCP/IP sí se adapta un modelo en capas bastante cercano. Así, TCP es un protocolo del nivel 4 e IP un protocolo de nivel 3. Los muy conocidos FTP o HTTP serían protocolos del nivel 7. 

En el mundo de las tecnologías de información, y muchas veces bajo el apelativo de arquitectura, se establecen otros muchos modelos. Pongamos por caso JEE que, inicialmente impulsado por la entonces Sun Microsystems, marca un modelo de referencia para las aplicaciones java empresariales.

Matriz Boston Consulting Group
En el mundo del análisis estratégico, es muy frecuente el uso de modelos muy sencillos como pueden ser el DAFO para analizar las Debilidades y Fortalezas de una compañía y las Amenzas y Oportunidades que la rodean en su mercado. Muy conocido también, por poner otro ejemplo es la matriz de la cartera de productos del Boston Consulting Group. Dentro de este campo del análisis estratégico podríamos considerar también un modelo de referencia, por ejemplo, la cadena de valor de Michael Porter.

Modelo de procesos eTOM (TMForum)
Si nos vamos a un mundo más cercano al análisis de procesos e incluso el mundo IT, nos encontramos modelos de arquitectura empresarial que organizan las funciones e información de una compañía. Un caso especial podría ser el propuesto por TeleManagement Forum para el sector de las telecomunicaciones con su mapa de procesos (eTOM), su mapa de información (SID) y su mapa de aplicaciones (TAM). En cierto modo, el modelo de procesos que propone ITIL podría ser considerado otro modelo de referencia.

Modelo procesos ITIL
En el mundo de la dirección de proyectos, el modelo de áreas de conocimiento y fases del PMI no deja de ser otro modelo de referencia. O, en el mundo del Business Analysis el modelo que propone IIBA.

Como estos podrían encontrarse muchísimos ejemplos en todo tipo de disciplinas, se podrían tener en cuenta muchas matizaciones y seguro que podríamos incluso establecer una tipología dentro de ellos..

Pero no es, en el fondo, ni la definición rigurosa ni la clasificación de los modelos de referencia lo que más me importa en este artículo, sino su utilidad.

Y me ha inspirado a pensarlo y escribirlo una frase extraída del libro 'The business analyst's survival guide' de LeAnn Simonson en que, hablando precisamente de business analysis, y poco antes de proponernos un 'framework' para gestionar problemas interpersonales, la autora nos habla de arquetipos y 'frameworks' y nos dice:

An archetype, framework, or model can be useful in organizing thoughts and actions.

Sí, creo que esa frase recoge una de las utilidades de un modelo de referencia: ayudar a pensar, organizar el pensamiento. Pero tras una breve reflexión, yo identifico ocho. Serían las siguientes:

  • Ayuda al pensamiento: Un modelo de referencia, sobre todo, ayuda a pensar, a estructurar el conocimiento y el pensamiento en áreas que normalmente son o complejas o algo intangibles. Nos da estructura y un punto de partida.

  • Vencer el miedo al papel en blanco: precisamente ese punto de partida es otra de sus utilidades. Como ya se nos proporciona un modelo, un esquema e incluso, una primera aproximación a nuestro problema, ayuda a vencer el miedo al papel en blanco, a dar el primer paso. Ese paso ya lo ha dado el modelo por nosotros.

  • Coherencia: Los modelos de referencia, incluso los más sencillos, suelen estar muy bien pensados y debatidos. En ese sentido, suelen ser muy coherentes... y si los utilizamos correctamente nuestras conclusiones tiene más posibilidades de ser también coherentes.

  • Completitud: por la misma razón, suelen ser modelos completos, que nos garantizan no olvidarnos de aspectos importantes. Esto es muy relevante especialmente en modelos complejos como una arquitectura tecnológica o una arquitectura empresarial.

  • Reutilización de conocimiento: derivado del concepto de punto de partida, estamos reutilizando conocimiento de terceros, conocimiento que tras mucho trabajo se plasmó en el modelo de referencia. Nosotros partimos de un punto con mucho ya avanzado...y nos permite ir más allá.

  • Prestigio / autoridad: habitualmente, aparte de estar muy trabajados, los modelos de referencia están respaldados o por un gurú, una persona de mucha autoridad en su campo (ej. Michael Porter) o bien por instituciones de prestigio (PMI, IIBA, OMG,...). Eso, por un lado, nos proporciona la tranquilidad de estar haciendo algo correcto y, también prestigia nuestro trabajo con la autoridad que se le supone al modelo.  

  • Estandarización: Los modelos de referencia de más éxito se constituyen en estándares de facto o de iure (especialmente los tecnológicos). El utilizarlos nos permite una mayor facilidad de integración con otros modelos, documentos, productos, sistemas, etc. También proporciona una mayor base de personas formadas y suficientemente conocedoras del modelo.

  • Comunicación: La estandarización conlleva también una homegeneización de conceptos, estructuras y vocabulario... y eso facilita la comunicación en el equipo y con terceros.
Quien conozca algunos de los modelos que he mencionado, seguramente entienda y aprecie las ventajas que he enumerado. Para quien resulte novedosa la idea, espero al menos haber 'picado' la curiosidad y el interés ante tan interesante concepto.

¿A algún lector se le ocurren otras razones?