lunes, 12 de noviembre de 2018

Cinco buenas prácticas para implantar RPA (Robotic Process Automation)


Aunque RPA (Robotic Process Automation) es una disciplina o, más bien, un tipo de soluciones bastante novedosas, ya existe suficiente experiencia como para hablar de buenas prácticas para implantar RPA.Y más teniendo en cuenta que, en general, son buenas prácticas que derivan del sentido común y, sobre todo, de la innegable herencia de dos disciplinas existentes desde hace muchos años, la gestión de procesos de negocio (BPM, Business Process Management) y la Ingeniería de Software. Porque, en el fondo, no lo olvidemos, hacer un robot no deja de ser una forma algo especial de desarrollo software y porque, además, el objeto de esos desarrollos es la automatización de secciones de un proceso de negocio.

Aunque seguro que hay más consejos y buenas prácticas que vale la pena observar, en este post vamos a recoger cinco buenas prácticas que nos propone Vaibhav Jain en su libro 'Crisper Learning for UiPath'. Hay que hacer notar que el libro habla exclusivamente de RPA y, además, un RPA implementado sobre la solución de UiPath. Sin embargo, las propuestas son bastante generalistas y, además, vamos a intentar ponerlas en contexto para que se entienda mejor su sentido y la herencia de que son deudoras.

Práctica 1 - Establece el diseño del workflow antes de construir el robot


Los robots de RPA automatizan, normalmente de forma parcial, un proceso de negocio. Por tanto, esta buena práctica es muy simple: antes de ponerte a automatizar nada (esto es, antes de desarrollar), primero entiende y define bien el proceso que vas a automatizar. Esta es una buena práctica que es aplicable a cualquier automatización de procesos, la hagamos mediante la parametrización de software empresarial como un ERP o un CRM, la hagamos mediante un BPMS (Business Process Management System), la hagamos mediante un desarrollo a medida o la hagamos, en este caso, mediante RPA.

En el caso específico de RPA y UiPath se habla más de flujos o workflows que de procesos y el software que desarrollamos es un robot, de ahí la manera de formularlo: 'diseñar el workflow antes de construir el robot'. Pero la buena práctica aplica tanto a RPA como a cualquier automatización de procesos: antes de automatizar, define y optimiza bien el proceso que vas a automatizar y luego ya empieza con el software..

Práctica 2 - Divide los problemas de negocio complejos en implementaciones lógicas más simples


Esta es una buena práctica de ámbito casi general: descomponer los problemas complejos en otros más simples.

Cuando esto se lleva al ámbito de la ingeniería de software, eso conduce a la subdivisión en módulos y componentes buscando, además de tratar con problemas más simples, la posibilidad de reutilización de los componentes así definidos.

Cuando esto lo trasladamos al ámbito de RPA estamos hablando de disponer de robots que hagan tareas más sencillas y puedan ser invocados por otros. Específicamente en el caso de UiPath, una de las formas de reutilización es definir unos workflows reutilizables que luego pueden ser invocados desde otros.

Práctica 3 - Manejo de excepciones exhaustivo


Esta buena práctica la conocerán muy bien todos aquellos que se hayan enfrentado a un software real puesto en producción real.

Tendemos a definir los procesos de negocio y el software pensando en la situación más limpia, el llamado 'happy path' o 'sunny day' en que todo funciona como tiene que funcionar. Pero la experiencia demuestra que lo inesperado sucede y los errores y situaciones extrañas abundan, Y todo software, sea de automatización de procesos o no, debe estar preparado para reaccionar de una forma razonable y no catastrófica ante cualquier error que aparezca.

Lo que esta buena práctica nos está diciendo es que debemos diseñar el software, en este caso los robots, para que reacciones adecuadamente ante cualquier posible error o situación inesperada.

Cuando hablamos de una RPA basada en UiParh eso quiere decir, fundamentalmente, que tenemos que ser capaz de hacer un adecuado tratamiento de excepciones, es decir, capturar todas las excepciones posibles y prever e implementar un tratamiento adecuado.

Los mecanismos que para ello proporciona una herramienta como UiPath, las excepciones, son conceptualmente muy similares a cómo se tratan las excepciones, por ejemplo, en un lenguaje como Java.

En cualquier caso, la buena práctica nos exhorta a este tratamiento exhaustivo de errores, en este caso en forma de excepciones.

Práctica 4 - Mantener el sistema limpio


Lo que esta buena práctica quiere decir es que seamos frugales en el uso de los recursos computacionales, tanto por un mayor orden en el software como también por no agotar los recursos de la máquina.

Eso, llevado al campo de un software general nos hablaría, por ejemplo, de liberar toda memoria dinámica que ya no vayamos a utilizar, o cerrar todos los ficheros que hayamos abierto si ya hemos acabado su tratamiento.

Trasladado al caso de RPA, la idea es la misma pero se nos habla, más bien, de cerrar todas las ventanas que ya no vayamos a utilizar, todas las aplicaciones con las que ya no vayamos a interactuar o todos los ficheros cuyo tratamiento hemos finalizado.

Práctica 5 - Control de versiones y backup periódico


Esta buena práctica es bastante general para cualquier desarrollo de software. Dado que éste evoluciona, es preciso mantener un buen control de versiones, de manera que éstas sean conocidas, coherentes y se puedan gestionar, incluyendo una eventual marcha atrás si la implantación de una nueva versión nos trae problemas inesperados y graves.

¿Y qué decir del backup? Ésta es una buena práctica tan general, que apenas precisa comentario. Lo que se necesita, en realidad, es su aplicación rigurosa y continua, sea en el campo de RPA o en cualquier otro.


*****


Como se puede ver, aunque existen pequeños matices derivados del hecho de tratar con RPA y la automatización robótica de procesos de negocio, éstas buenas prácticas son mero sentido común y fruto de una experiencia de años en gestión de procesos y desarrollo de software, que antecede a RPA (Robotic Process Automation) y de la que ésta es heredera.


viernes, 9 de noviembre de 2018

Preparando SOA y BPM para el cambio con Marc Fiamante

'Dynamic SOA and BPM' es un libro de carácter netamente técnico, que explora conjuntamente los campos del BPM (Business Process Management) y SOA (Service Oriented Architecture) pero no de una forma general sino, muy expecíficamente, analizando las mejores prácticas para que ambas técnicas/tecnologías sean capaces de adaptarse con agilidad al dinamismo que se produce en la vida y negocios reales.

Se trata. además, de un libro bastante avanzado que da por sentados importantes conocimientos del lector en estos campos y no se detiene mucho en explicaciones previas sino que ataca directamente la temática que se propone. En ese sentido, no resulta un libro demasiado fácil de leer ni de entender salvo para personas expertas o al menos buenas conocedoras de estas materias.

El libro se estructura en ocho capítulos:

  • 'From simplified integration to dynamic processes': Comienza analizando errores comunes en la aplicación de BPM y SOA que limitan su valor. Luego propone una arquitectura empresarial con tres capas paralelas (infraestructura, aplicaciones y negocio) y otra transversal (información) y comenta su 'mapping' a algunos modelos de referencia como eTOM, PCF o SCOR y termina aportando unos principios para conseguir el dinamismo.

  • 'Streamlining the enterprise architecture for dynamic BPM and SOA': Un capítulo complejo en que realiza varios planteamientos a nivel de arquitectura empresarial para prepararla para la variabilidad.

  • 'Implementing dynamic enterprise information': explora técnicas que flexibilizan el tratamiento de información a diferentes niveles de detalle, desde algunos más arquitecturales, a otros en el nivel de diseño e incluso otros muy cercanos ya a la implementación de datos.

  • 'Implementing variable services': enfoca ahora la variabilidad desde el punto de vista de los servicios de negocio SOA, analizando temas como patrones de diseño, los contratos de servicios en WDSL, las arquitecturas de componentes o los servicios REST.

  • 'Implementing dynamic business processes': Se centra ahora en el nivel de procesos de negocio tratando técnicas de un modelado para la variabilidad, aspectos relacionados con reglas de negocio o eventos.

  • 'Implementing the enterprise expansion joint': Habla de los aspectos más relacionados con el nivel de infraestructura como el Enterprise Service Bus y técnicas relacionadas con la mediación entre servicios.

  • 'Tooling for dynamic SOA and BPM processes': Cambia ahora un poco la orientación analizando el tipo y casos concretos de herramientas que se pueden utilizar en las tareas vistas hasta el momento, incluyendo la gestión del ciclo de vida de la arquitectura empresarial y el modelado e implementación de sus diferentes capas como procesos, servicios e información.

  • 'Managing and monitoring a dynamic BPM and SOA environment': Finaliza hablando de aspectos más de gestión, incluyendo la monitorización, la gestión del ciclo de vida de procesos y servicios y la gestión operativa

Un libro, en fin, interesante pero de un nivel avanzado y que precisa de una lectura muy cuidadosa y experta para sacarle todo el beneficio.

Marc Fiamante

(Fuente: Traducción y ligera elaboración propia de la ficha de autor en InformIT)

Marc Fiamante
Marc Fiammante es un Ingeniero Distinguido de IBM, elegido para la IBM Academy of Technology en 2003, con amplia experiencia en la arquitectura de grandes proyectos y en desarrollo de software en múltiples entornos. Es arquitecto jefe del equipo de Enterprise Integration Solutions en Europa, Medio Oeste, África y Asia-Pacífico. Marc tiene más de veinte años de experiencia en TI. Ha registrado varias patentes en el dominio del software y ha publicado varios artículos en relación con tecnología e-business. Dirige equipos de arquitectura en grandes proyectos industriales. Tiene 'expertise' técnico y arquitectural con la arquitectura orientada a servicios, web services, Enterprise Application Integration y tecnologías orientadas a objetos y e-business, incluyendo variedad de sistemas de middleware, lenguajes de programación y estándares.

Marc es titulado por la Ecole Centrale de Paris.

Puedes saber más del autor visitando su perfil en LinkedIn.

Ficha técnica:

AUTOR: Marc Fiamante.
EDITORIAL: IBM Press Books
AÑO: 2009
ISBN: 978-0137018918
PAGINAS: 216

Artículos de este blog relacionados

miércoles, 7 de noviembre de 2018

Una definición de Robotic Process Automation (RPA) y una llamada al realismo


Como por desgracia ocurre con tantas tecnologías novedosas, especialmente cuando incorporan algo que tenga que ver con la inteligencia artificial RPA (Robotic Process Automation) es una tecnología, más bien un tipo de soluciones, sobre los que existe mucha literatura confusa, cuando no directamente exagerada. Puede venirnos bien, pues, disponer de una definición de Robotic Process Automation.

Aunque es quizá excesivamente simplificada, me ha gustado la propuesta que hace Vaibhav Jain en su libro 'Crisper learning for UiPath'. Nos dice:

Robotic Process Automation is the process of imitating the job a normal person would do in front of a computer system.

En esa seudo-definición, he resaltado en negrita dos aspectos que pueden parecer triviales pero que son muy importantes. 

El primero es el hecho de que RPA imita a un ser humano. Es decir, interactua con aplicaciones existentes, usando la pantalla, el teclado, el ratón o tratando por los mismos medios con ficheros ofimáticos, como hojas de cálculo o documentos PDF. 

Y he resaltado que es 'en frente' de un sistema de computación precisamente para hacer más patente que RPA trabaja sobre unos sistemas de información previamente existentes. Eso es muy importante entenderlo porque uno de los valores que creo mayores de RPA es que trabaja con los sistemas corporativos ya en operación, pero sin alterarlos en absoluto ya que hace exactamente lo mismo que haría un operador humano con esas mismas aplicaciones.

Y aquí una nueva llamada de atención. RPA son robots software. Es decir, cuando afirmamos que los robots de RPA interactuan con la pantalla, el teclado o el ratón, no imaginemos a un robot físico (como el que aparece en la imagen de cabecera) tecleando. Los robots de RPA interactuan con los dispositivos del ordenador a nivel de drivers o del sistema operativo. De cara a la aplicación con la que interactua, es exactamente igual que si lo hiciese una persona...pero seguimos hablando de robots software, exclusivamente software, nada de androides.

Una definición parecida a la anterior pero más completa es la que nos ofrece Roland Berger en el documento 'RPA – Tomorrow's must-have technology How robotic process automation can speed up your business'

Robotic process automation (RPA) is a software solution that simulates a "virtual employee". It interacts with existing applications in the same way that a human being would, but faster, more transparently and with greater efficiency

De nuevo, se nos habla de que RPA es un software que imita el comportamiento humano y que interactua con las aplicaciones de la misma forma que éste lo haría.

Y ahora es cuando viene al caso la llamada al realismo. Existe mucha literatura confusa, ya sea con intención o por ignorancia, que mezcla RPA con la inteligencia artificial como si RPA fuese esencialmente una tecnología de inteligencia artificial o un subconjunto de la misma. Y para aquel lector inadvertido, el nombre de este tipo de soluciones, que incluyen el término robótico, unido a la confusa mezcla con la inteligencia artificial, le pueden hacer pensar en un software que piensa como un humando, razona como un humano y decide de forma autónoma como un humano.

No es así. No exactamente así.

Las tareas que fundamentalmente resuelve hoy día RPA sen, precisamente, las menos inteligentes. Las que son masivas, repetitivas y basadas en reglas muy claras. Es decir, las tareas que la mayoría de los humanos consideramos tediosas, rutinarias, burocráticas... 

Sí que es cierto que las soluciones dominantes hoy día de RPA incluyen elementos de inteligencia artificial pero hay qué saber qué. Fundamentalmente las aportaciones basadas en inteligencia artificial se usan en el reconocimiento de imágenes, en un OCR (reconocimiento óptico de caracteres) avanzado,  y en el tratamiento del lenguaje natural. Pero todo ello, fundamentalmente para ser capaces de extraer la información de la imagen de una pantalla (especialmente en entornos virtualizados con herramientas de tipo Citrix) o para extraer información de documentos en texto libre, no estructurado. No se trata, pues, de usar una inteligencia avanzada para razonamiento creativo o toma de decisiones complejas, sino para interpretar correctamente una información desestructurada presente en pantallas y documentos. Nada más... y nada menos.

Es cierto también que se trabaja, y mucho, para incorporar más elementos de inteligencia artificial. Es cierto que la arquitectura de estas herramientas permite ya incluir scripts desarrollados por ejemplo en Python que muy bien pudieran hacer uso avanzado de machine learning, por ejemplo.

Tal vez estén a la vuelta de la esquina avances que incorporen a RPA unas capacidades cognitivas más avanzadas.Parece que así va a ser... y es muy estimulante el avance en esa dirección.

Pero, mientras eso llegue, aplica una llamada al realismo. De momento, RPA sigue aportando su valor principal en la automatización de tareas repetitivas, basadas en reglas y apoyándose siempre en sistemas existentes. Y aunque así formulado puede parecer menos 'bonito', lo cierto es que el valor que aporta a las organizaciones es muy, muy grande.

RPA tiene muchísimo valor que aportar a las empresas que lo empleen con criterio y realismo. Y es una pena que las fantasías en la formulación de lo que es RPA, pueda confundir y ahuyentar a posibles usuarios que se podrían haber beneficiado, y mucho, de ella, o en el otro extremo que se llegue a una desilusión, como se formula en la famosa curva de Gartner, por unas expectativas infladas que luego no se alcanzan.

RPA tiene mucho, muchísimo que ofrecer, y no necesita de fantasías para ello sino, todo lo contrario, necesita más bien una llamada al realismo.  

lunes, 5 de noviembre de 2018

La robotización como llamada a la inteligencia


Valoro mucho el conocimiento y admiro la inteligencia. 

El primero, el conocimiento, depende muchísimo de nosotros mismos, del esfuerzo que hayamos puesto cuando fuimos estudiantes en asimilar datos y adquirir habilidades. Y, mucho más importante aún, del empeño y dedicación que hayamos puesto en seguirnos formando cuando ya no somos esos estudiantes. O, si se prefiere, mejor aún, el empeño en no dejar de ser nunca un estudiante.

La inteligencia, sin entrar en teorías profundas, creo que tiene una parte innata y otra que se desarrolla pero, en cualquier caso, al menos parcialmente, sigue estando en nuestra mano el potenciarla.

Son virtudes, conocimiento e inteligencia, que creo nos potencian como personas y ciudadanos, que proporcionan íntimas satisfacciones al tiempo que nos preparan para afrontar retos y problemáticas de toda índole.

Y por eso vale la pena dedicarles esfuerzo.

En el ámbito específicamente laboral, y a pesar del indudable peso que tienen otros factores como el liderazgo, la capacidad de relación, la empatía y otras cualidades 'soft', no se puede negar la utilidad que el conocimiento y la inteligencia nos prestan para hacernos valiosos y para progresar.

Mucho se está hablando, normalmente, creo, de forma superficial y tópica, del impacto que la robotización y la inteligencia artificial tendrán en el empleo. Soy de los que tiende al optimismo, porque, aunque con disfunciones puntuales y también, preciso es reconocerlo, con algunos colectivos perjudicados, la tecnología siempre ha impulsado hacia adelante a la humanidad no sólo en lo meramente técnico sino también en el bienestar material y social.

Pero eso no obsta para que en la definición y aplicación de los nuevos puestos de trabajo vayamos a ver, estamos viendo ya, un indudable impacto de lo tecnológico. Y para salir 'bien librados' en este nuevo entorno tenemos dos armas conocidas: el conocimiento y la inteligencia.

El conocimiento para ser capaces de entender y aplicar las nuevas tecnologías y sacarles el mayor partido. Un conocimiento que no se va a adquirir por un esfuerzo puntual sino que implica aprendizaje continuo.

E inteligencia porque aunque las máquinas se hagan progresivamente más inteligentes, el desarrollo de nuestra propia inteligencia nos hará más valiosos y diferenciales y, además, nos ayudará también a ser capaces de reconocer situaciones y adaptarnos a ellas. 

No esperaba un canto a la inteligencia en un libro técnico pero, precisamente, leyendo 'Crisper learning for UiPath' de Vaibhav Jain, un libro muy orientado a desarrolladores en el ámbito de RPA (Robotic Process Automation) y centrado en una solución específica, UiPath,, me he encontrado en sus primeras líneas con esta afirmación:

With progression of information technology in today's era, the ask from professionals is to work smarter, not just harder.

No estoy seguro, quisiera pensar que si, de si realmente a los profesionales del futuro se les permitirá trabajar menos duro, pero de lo que me cabe poca duda es de que para tener émpleabilidad y éxito, será muy importante trabajar de forma más inteligente.

Y, al menos en lo que a mi respecta, si la llegada de los robots y la inteligencia artificial, supone una exigencia de conocimiento y una llamada a la inteligencia, bienvenida sea...


viernes, 2 de noviembre de 2018

Capas de servicios SOA


La filosofía SOA tiene todo que ver con el orden y la estructura, con la articulación inteligente y práctica de los componentes software con que se teje el entramado de los sistemas corporativos. En ese afán por poner orden, también tiene cabida la estructuración de la propia naturaleza de los servicios. Y una forma de poner orden es estructurar en Capas de servicios SOA, el conjunto de esos servicios, conforme a su diferente naturaleza.

En su libro 'Service-Oriented Architecture: Analysis and Design for Services and Microservices' Thomas Erl propone una estructura de cuatro capas de servicios SOA.

Antes de pasar a verlas conviene comentar la clasificación que menciona el autor en cuanto a servicios agnósticos y no agnósticos, basándose la diferenciación en si el servicio tiene 'conocimiento' y dependencia de su contexto y muy en concreto de la tarea en que se enmarca la funcionalidad del servicio, o es ajeno a él. En el segundo caso hablaríamos de servicio agnóstico y tienen como beneficio el hecho de ser más ampliamente reutilizables. Si existe ese 'conocimiento' y dependencia nos encontraríamos ante un servicio no agnóstico.

Según eso, y siguiendo una dirección de abajo a arriba, el autor distingue estas cuatro capas:

Capas propuestas por Thomas Erl antes de la llegada de los microservicios

  • Servicios de tarea: Un servicio no agnóstico y que en general se corresponde con una actividad o tarea de un proceso de negocio.

  • Microservicios: una capa que no se encontraba en el primer planteamiento de Erl (por eso no aparece en la figura superior) y que consiste en un servicio no agnóstico con un alcance funcional reducido. No suelen ser reutilizables de forma general, pero sí dentro de la aplicación en que se enmarcan.

  • Servicios de entidad: Un servicio agnóstico y que se relaciona con una o más entidades de negocio (por ejemplo, Cliente, Factura o Contrato). Tienen un contexto agnóstico. Por ejemplo, un servicio 'Orden de compra' tendría como contexto el procesamiento de cada orden de compra específica.

  • Servicios de utilidad: Un tipo de servicio agnóstico y reutilizable y que ofrece una funcionalidad puntual que no deriva de unas especificaciones de proceso. Suele encapsular funciones técnicas de bajo nivel como, por ejemplo, temas de seguridad o trazado (logs).

Existen otros planteamientos de tipos o capas de servicios no totalmente coincidentes con las propuestas por Erl, aunque sí bastante próximas en sus ideas.

Al final, se trata de poner orden en un conjunto amplio de servicios y diseñar de forma que se respeten algunos de los principios y objetivos de SOA como son la alta cohesión interna y bajo acoplamiento externo de los servicios y la 'reutilizabilidad' de los mismos en el contexto más amplio posible.


miércoles, 31 de octubre de 2018

Objetivos y beneficios de SOA


Aunque el tirón mediático de SOA (Service Oriented Architecture) ya hace tiempo que pasó, lo cierto es que los beneficios de SOA siguen muy vigentes y es, por tanto, un planteamiento que a nivel de arquitectura y diseño de sistemas es plenamente actual.

Cualquier organización con un mapa de sistemas suficientemente complejo debería tenerlo como un elemento rector de su arquitectura.

Incluso hoy en día con la cada vez mayor prevalencia de las soluciones cloud (PaasS y SaaS, en especial) adquiere quizá mayor sentido. Y eso tanto como arquitectura interna a usar por proveedores de cloud como en la forma de relacionarse las empresas con el software que le proporcionan esos mismos proveedores cloud.

Sabemos que la arquitectura SOA promueve la estructuración del software en forma de servicios reutilizables y con contratos bien definidos. Recoge así los tradicionales principios de la alta cohesión interna y bajo acoplamiento externo tan propios de la ingeniería software, pero llevados ahora, si cabe, a un mayor protagonismo. Aunque esa filosofía se puede implementar a nivel técnico de muchas formas, lo cierto es que lo que predomina hoy día son unos servicios que se exponen como web services ya sea con arreglo a los estándares SOAP (Simple Object Access Protocol) o REST (REpresentational State Transfer).

Pero ¿cuáles son esos beneficios que ofrece SOA y que la convierte en una arquitectura tan interesante?

En su libro 'Service-Oriented Architecture: Analysis and Design for Services and Microservices', Thomas Erl, concentra en siete los puntos a tener en cuenta, cuatro objetivos estratégicos y tres beneficios que se derivan

Los objetivos estratégicos de SOA


  • Incremento intrínseco de interoperabilidad: En ese sentido cabe recordar que SOA persigue una interoperabilidad nativa de servicios sin necesidad de trabajos adicionales de integración. En esa dirección colaboran aspectos como la estandarización de los contratos de servicio, la predecibilidad del comportamiento, la escalabilidad y la fiabilidad.

  • Incremento de la federación: recordando que por federación se entiende el que recursos y aplicaciones colaboren y se encuentren de alguna forma unidos pero manteniendo su autonomía y auto-gobierno.

  • Incremento de las posibilidades de diversificación de proveedores: ya que al basarse en estándares y promover la interoperabilidad se eliminan dependencias innecesarias de los proveedores del software.

  • Incremento del alineamiento entre negocio y tecnología: ya que SOA promueve un primer nivel de abstracción precisamente en el nivel negocio de forma que sus conceptos son naturales para ese negocio.

Los beneficios de SOA que se derivan


  • Incremento de ROI: ya que las soluciones SOA son más sencillas tanto de mantener como de evolucionar que las soluciones más a medida.

  • Incremento de la agilidad organizativa: es decir, la capacidad de las organizaciones de responder al cambio. Factores anteriores como el alineamiento con el negocio,o la reutilización facilitan mucho el evolucionar el software y por tanto responder con esa agilidad.

  • Reducción de la carga para TI: ya que las aplicaciones son más sencillas de evolucionar, la complejidad total es menor y el gobierno también resulta más sencillo.

Ni que decir tiene que las implementaciones reales en grandes empresas son complejas y que ni SOA, ni ninguna otra arquitectura alternativa van a traer 'el mundo feliz' ni a la organización de TI ni al negocio. Pero aún así, desde luego SOA es un paso decisivo en la buena dirección y los beneficios de una arquitectura SOA bien diseñada y aplicada son innegables..


lunes, 29 de octubre de 2018

Cuatro dominios para una arquitectura empresarial


El concepto de arquitectura empresarial, algo borroso y no del todo extendido, nos lleva a un modelo  estructurado de los principales elementos de gestión de una empresa desde una perspectiva de negocio pero con mucha orientación hacia sus sistemas de información. Entre los dominios para una arquitectura empresarial que podemos encontrar en la literatura se encuentran aspectos como los procesos, los sistemas, la información, la organización, etc.

En su libro, 'Dynamic SOA and BPM', el arquitecto de IBM, Marc Fiammante nos habla de cuatro dominios para una arquitectura empresarial, cuatro dominios que, además, y a modo de regla nemotécnica de naturaleza gráfica, estructura en unas capas que conforman la letra 'E' de 'Enterprise architecture'.

Los cuatro dominios que se identifican son:
  • Negocio
  • Aplicaciones
  • Infraestructura
  • Información

y se ilustran en la siguiente figura procedente del libro:




Aunque Fiammante no realiza una definición detallada, sí podemos entrever los elementos de cada nivel.

Dominio de negocio


En este dominio, hablamos del negocio con independencia de la base técnica con que se pueda operar. Elementos que se encuentran en este nivel son la organización y la asignación de responsabilidades.

Pero también, y aunque no se menciona explícitamente, los procesos de negocio. De hecho, el gráfico se ilustra con el mapa de procesos PCF (Process Classification Framework) cross-sectorial de la APQC (American Productivity and Quality Center) y en su disertación Marc Fiammante nos habla también de otros modelos de procesos como eTOM (enhanced Telecom Operations Map), propio del mundo de las telecomunicaciones o SCOR (Supply Chain Operation Reference model) para cadenas de suministro.

Dominio de aplicaciones


En este dominio se sitúa por un lado, el censo de servicios de negocio (no olvidemos que el libro habla de SOA) y el mapa de sistemas o aplicaciones de la empresa y donde se mapean esos servicios de negocio.

Como ejemplo de un modelo de aplicaciones estandarizado, el autor nos refiere a TAM (Telecom Application Map) que acompaña a eTOM pero ahora con perspectiva de aplicaciones y no procesos de negocio.

Dominio de infraestructura


Este es el dominio más técnico donde se recogen elementos como el repositorio de servicios, el Enterprise Service Bus, los servicios de infraestructrura, etc. Se trata de un dominio donde apenas existen resultados de estandarización.

Dominio de información


En la figura se delinea como transversal a las otras capas. En este caso se trata estructurar la información que se maneja en la empresa, agrupándola en dominios de información, entidades y datos concretos.

El modelo de referencia más conocido en ese sentido es SID (Shared Information Data) que, junto con eTOM a nivel de procesos y TAM en lo relativo a aplicaciones, conforman una arquitectura casi completa para el sector de las telecomunicaciones.


***

El modelo de arquitectura empresarial que propone Fiamante identifica, creo que con bastante acierto cuatro capas relevantes de la arquitectura empresarial aunque, bien es cierto que la capa de infraestructura queda algo desdibujada al no existir ningún tipo de estándar, normativa o buena práctica que se apunte y en el nivel de negocio quizá convendría una explicitación más clara de dos aspectos: la organización y los procesos.

No es, de todas formas, el concepto de arquitectura empresarial un tema sencillo por lo que cualquier modelo que proporcione una visión más o menos estructurada y comprensible, como es el caso, es de agradecer.


viernes, 26 de octubre de 2018

El enfoque riguroso para el Business Process Management de Martyn Ould

'Business Process Management. A rigurous approach' es un libro riguroso y muy bien trabajado que explica el campo del Business Process Management pero desde la perspectiva muy concreta de la metodología Riva definida por el autor.

Se trata de un libro muy cuidado y que, como anticipa el título, es realmente muy riguroso, estableciendo fronteras muy claras entre conceptos y proporcionando una sintaxis y semántica de modelado muy limpias.

El libro se estructura en trece capítulos, a saber:
  • 'Basic process concepts': explica algunos conceptos básicos como son los roles, en los que pone mucho énfasis, acciones, interacciones, objetivos del proceso y entidades

  • 'Modelling a process': Inicia la descripción formal del modelado usando la metodología Riva. Explica lo que son los RAD (Role Activity Diagram), cómo se representan en ellos los roles y sus estados, las acciones, los threads de acciones concurrentes, los distintos cursos de acción, las interacciones y disparadores (triggers). Es, en fin, un capítulo fundamental en que se explica la mayor parte de la sintaxis y semántica del modelado de procesos con Riva.

  • 'Dynamism in the process': Capítulo muy corto donde se explica algún aspecto de la dinámica de los procesos, muy especialmente cómo se inician y finalizan.

  • 'Process relationships': Otro capítulo breve, en este caso para hablar de las relaciones entre procesos y cómo reflejarlas en Riva. Se habla de interacciones, activación de procesos y encapsulación.

  • 'The three basic process types': Con este capítulo inicia la segunda parte más orientada a la aplicación de Riva en una organización y empieza razonando sobre tres tipos de procesos: tratamiento de casos, gestión de los casos y estrategia de los casos, con la filosofía de que, por cada entidad/unidad de trabajo que se identifique en una organización, podemos asumir tentativamente que existirán esos tres procesos.

  • 'Preparing a process architecture': Continuación un poco del anterior, explica ahora en detalle cómo a partir de las EBE (Esssential Business Entities), es decir, a partir de las entidades fundamentales que gestiona un negocio, pasando por las UOW (Units of Work), es decir, las unidades de trabajo habitual ligados a esas entidades, y teniendo en cuentra los tres tipos de procesos, podemos deducir la arquitectura de procesos de una organización.

  • 'Dynamism in the world': Con base en unos casos concretos, estudia cómo tratar aspectos de la dinámica de procesos.

  • 'Managing the modelling': Explica la mecánica que propone para gestionar el modelado de procesos y proporciona una receta en cinco pasos donde se incluye también un análisis bastante profundo de la operativa de un taller de procesos.

  • 'Discovering and defining processess': Un capítulo muy breve con alguna recomendación referida al descubrimiento y definición de procesos.

  • 'Analysing for process improvement': Proporciona directrices sobre la forma en que se pueden mejorar los procesos de negocio y alguna idea sobre la gestión de ese trabajo.

  • 'Designing a process': De una forma muy concisa, aporta sugerencias para el diseño de procesos cuando éstos son nuevos, en lugar de tratarse de la modificación de uno existente.

  • 'Processes and information systems': Pone Riva en contexto y relación con los sistemas de información que soportan procesos.

  • 'Processes and process systems': Razona brevemente sobre unos sistemas de información orientados al proceso y fantasea al final con futuros deseables, a través de seis visiones posibles de ese futuro.
Como aportación originales del planteamiento del libro está la introducción frecuente de unos diálogos entre un profesor y un alumno que desentrañan algunos de los aspectos más complejos o conflictivos de la gestión de procesos o de la aplicación de la metodología.

Se trata, por tanto, de un buen libro. Sin embargo, es una obra a la que creo que ha perjudicado el paso del tiempo. ¿Por qué? Porque aunque el tratamiento es interesante y riguroso, está muy, muy orientado a la metodología y notación Riva propia del autor, más que a una visión más general de la gestión de procesos. Dado que, por lo que sea, esta metodología no ha triunfado y dado que hoy en día la notación dominante es BPMN, bastante diferente de Riva, toda la lectura del libro produce esa sensación de estar viendo algo 'demodé' y 'fuera de juego'.

Para aprovechar lo que de bueno tiene este libro, es preciso, por tanto, hacer una lectura atenta y consciente y ser capaz de abstraerse de los aspectos más formales y particulares de Riva, para aprovechar el rigor, sentido común e ideas, sin duda muy valiosas, que hay detrás.

Martyn Ould

(Fuente: Ligera elaboración propia de su biografía en Technoikal.)

Martyn Ould
Martyn Ould es consultor y formador en la definición, diseño y diagnóstico de los procesos organizativos y de negocio. Ha estado activo en el ámbito de procesos de negocio durante veinte de sus más de treinta y ocho años en la industria.

Un contrato de investigación en 1986 lo llevó a desarrollar una técnica de modelado de procesos de negocio como parte de la aplicación de flujo de trabajo y sistemas de gestión de documentos. El libro 'Business Processes: Modelling and Analysis for Re-engineering' (John Wiley, 1995) describe la técnica en su forma inicial. Basándose en la experiencia de diez años extendió el trabajo para crear Riva, un método completo para la definición, diseño y diagnóstico de los procesos de negocio. Riva es el tema central de su libro 'Business Process Management. A rigurous approach' (BCS, 2005). En la actualidad asesora en la gestión de procesos de negocio para los clientes, en particular, trabaja con ellos en la adquisición de las herramientas mentales y disciplinas de Riva para construir una comprensión profunda de los procesos dentro de su empresa. Su experiencia de gestión de procesos incluye la elaboración de productos farmacéuticos y servicios públicos y los departamentos gubernamentales a nivel nacional y local. Ha trabajado con los procesos de front-office así como los de back-office, administrativos y de grupos de investigación. Su trabajo ha incluido:
  • La preparación de las arquitecturas de proceso para departamentos y organizaciones enteras.
  • El diseño de nuevos procesos para nuevos grupos.
  • El rediseño de los procesos y la reestructuración de las responsabilidades de la organización para alinearse con los nuevos procesos.
  • La adaptación de los procesos existentes para dar cabida a las nuevas tecnologías.
  • Formación en Riva.
  • Facilitación de talleres de resolución de problemas.
Su foco es la comprensión y claridad, evitando largas listas o informes. Tiene una sólida reputación en la industria y la academia. Es ingeniero colegiado y miembro de la British Computer Society.

Ficha técnica:

AUTOR: Martyn Ould.
AÑO: 2007
ISBN: 978-1-902505-60-2
PAGINAS: 346

Artículos de este blog relacionados

miércoles, 24 de octubre de 2018

Recordando las funciones de un Enterprise Service Bus


Parece que nos hubiéramos olvidado de SOA (Service Oriented Architecture) y de todo lo que supuso... y supone aún. Pero no nos debemos olvidar porque las necesidades de integración de sistemas y de arquitecturas que permitan estructurar el armazón funcional y de información siguen vivas, muy vivas. Un elemento arquitectónico muy importante a que dio lugar el desarrollo de SOA es el Enterprise Service Bus, una pieza de software, un middleware como se le dio en llamar, que se constituía en una especie de conector universal.

Definiciones académicas aparte, el Enterprise Service Bus es un software cuya misión, en esencia, es interconectar sistemas. No proporciona por sí mismo una funcionalidad para el usuario final, sino que hace más fáciles y racionales los intercambios de información y servicios entre diferentes sistemas para proporcionar funcionalidades más amplias o para, por ejemplo, implementar extremo a extremo un proceso de negocio.

El Enterprise Service Bus ofrece mecanismos tecnológicos (Web Services, colas de mensajes, conectores a aplicaciones populares, etc) para implementar servicios de interconexión pero, además, suele ofrecer funcionalidades adicionales como la traducción de datos o adaptación de formatos, la persistencia y transacionalidad de las interacciones o la implementación de pequeños workflows.

En su libro 'Dynamic SOA and BPM', Marc Fiammante agrupa en cuatro las responsabilidades de un Enterprise Service Bus:

  • Enrutado de mensajes: Cuando utilizamos un ESB la aplicación que necesita un servicio de otra, no llama directamente a esa otra aplicación sino que lo hace a través del bus y es el bus quien sabe cómo hacer llegar esa invocación a la aplicación destino. Esto constituye un primer nivel de desacoplamiento o independización entre ambas aplicaciones

  • Conversión de protocolos de transporte: Es decir, cada aplicación o servicio puede utilizar el protocolo que más le convenga y es el bus el que sabe utilizar en cada interacción el protocolo adecuado y realizar las conversiones oportunas cuando protocolo de peticionario y servidor no son iguales.

  • Transformación de formatos de mensajes: El bus realiza, si es necesario, traducciones de formatos de argumentos y contenidos de mensajes con lo que, de nuevo, independiza a las aplicaciones que no tiene por qué usar los mismos formatos.

  • Tratamiento de eventos de negocio dispares: con lo que, el mismo servicio ofrecido por una aplicación, puede ser invocado en diferentes contextos de negocio.

Como se puede ver, el Enterprise Service Bus viene a ser, dicho de forma muy sencilla, un facilitador de las interacciones entre aplicaciones, desacoplando sus lógicas, interfaces y liberando a éstas de la esclavitud e ineficiencia que suponen los acuerdos bilaterales de protocolos y formatos de mensajes en las interfaces tradicionales.

Se trata, pues, de una pieza de software injustamente olvidada, puesto que juega un papel esencial en la arquitectura de cualquier empresa con un mapa de sistemas complejo.

martes, 23 de octubre de 2018

En Pulse: La caracola: Transformación Digital y procesos


La atención que se presta a los procesos de negocio desde el punto de vista tanto tecnológico como de ‘management’ está sometido a una suerte de oleaje que los acerca y aleja alternativamente del foco de atención.

La primera oleada se produjo hace ya muchos años cuando Japón, espoleado por la necesidad de superar las consecuencias de la Segunda Guerra Mundial, adoptó las teorías norteamericanas sobre calidad y las llevó a unas enormes cotas de éxito y excelencia. Nació el TQM (Total Quality Management) y más tarde otras disciplinas o filosofías como Lean Management o Six Sigma que, aunque quizá hayan perdido algo de foco, siguen plenamente vigentes y conforman una indudable, ‘mar de fondo’.

Más tarde vino la galerna de la Reingeniería de Procesos, con su apuesta por la hoja en blanco y la reinvención radical. El temporal que generó ha amainado en parte, pero nos dejó como indudable regalo, la apuesta por las tecnologías de la información como soporte e impulso de la innovación en procesos.

Unos vientos fuertes, aunque menos racheados, acompañaron al nacimiento, primero de los sistemas empresariales como ERP y CRM que incluían automatización de procesos, y al nacimiento del BPM (Business Process Management) que confirió a los procesos de negocio el valor de un activo a gestionar y que se acompañó de novedades tecnológicas como los sistemas de workflow, posteriormente evolucionados a BPMS (Business Process Management Suites) bien flanqueados todos ellos por el concepto de SOA (Service Oriented Architecture) y ESB (Enterprise Service Bus).

Y quizá, erróneamente, nos creíamos que se había alcanzado la culminación y que ya no teníamos que prestar tanta atención a los procesos de negocio y las tecnologías que los soportan.

Pero ha salido una Luna llena llamada Transformación Digital que está haciendo más viva esa marea, que hace crecer y crecer el oleaje con nuevas tecnologías y nuevas posibilidades.

La revolución digital nos ha traído consigo la evolución del BI hacia el Big Data, la capacidad de analizar en tiempo real volúmenes inmensos de datos y obtener análisis, y conclusiones sobre muchas cosas, entre ellas los indicadores sobre los propios procesos. Y nos habilita no sólo para monitorizar, sino también para tratar eventos complejos en tiempo real o para, incluso, descubrir procesos (process mining) a partir de los la información que los ‘logs’ que los sistemas dejan como herencia.

Y la marea trae consigo también Machine Learning e Inteligencia artificial que nos permiten automatizar tareas hasta ahora vedadas a los BPMS, tareas que implican inteligencia, reconocimiento de voz, procesamiento del lenguaje natural o visión artificial y nos abren las puertas a la automatización de los procesos de relación con clientes y usuarios mediante chatbots, o asistentes digitales de voz.

Y con la marea nos llega también la automatización robótica de procesos (RPA, Robotic Process Automation) que permite digitalizaciones no intrusivas y rápidas de tareas masivas y repetitivas y que, además, se ‘entiende muy bien’ con la inteligencia artificial.

Y por detrás de la tecnología, las tareas y los procesos que esas tecnologías digitalizan y automatizan. Los procesos de negocio de los que creímos habernos olvidado y que ahora, cual regalo en forma de caracola, nos trae el mar agitado de la revolución digital.

Si. Los procesos de negocio han vuelto con fuerza. Es hora de recoger esa caracola y retomar las disciplinas de gestión de procesos que nos llevarán a gobernar de forma inteligente las nuevas tecnologías que lo digital trae consigo. Escucha dentro de la caracola. Escucha la gestión de procesos. ¿Oyes el ruido del mar? ¿Escuchas el oleaje? ¿Percibes la marea digital? ¿Estás preparado para la transformación?

*****

Artículo publicado en Pulse el 23/10/2018 y en Medium en la misma fecha
Pulse es el servicio de noticias personalizadas de la red social profesional LinkedIn


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.


viernes, 19 de octubre de 2018

Principios para el modelado de procesos


En artículos recientes hemos hablado de qué es modelar un proceso de negocio y por qué es importante. También hemos visto siete razones y media en que conviene descubrir y modelar un proceso. Antes de ir cambiando poco a poco de tercio tras muchos artículos hablando principalmente de procesos de negocio, vamos a complementar los artículos antes mencionados, con unos principios para el modelado de procesos.

Ocho principios que nos vienen de la mano de Martyn Ould y que menciona en su libro en su libro 'Business Process Management. A rigorous approach'.

  • Principio 1- Ya que hemos de hacer abstracciones, hagamos que sean significativas: al modelar pagamos el peaje de abstraer y simplificar pero, a cambio, se debe conseguir un significado inequívoco que, no sólo permite la comunicación humana sino, incluso, el poder trasladarlo a un sistema como una especie de ejecutable.

  • Principio 2- El mundo real es desordenado: más que un principio es el reconocimiento de una realidad. Ya que esa realidad es compleja y desordenada, los modelos resultantes no siempre podrán ser sencillos y nítidos. El autor emplea este principio para cargar contra los modelos jerárquicos de procesos. Esa posición de Martyn Ould es discutible y no ha sido seguida por la mayor parte de los modelos de referencia. Lo que sí es indudable es que la realidad es con frecuencia compleja y desordenada... y es casi imposible evitar que eso se traslade a los modelos detallados.

  • Principio 3- Un modelo tiene que significar una cosa y sólo una cosa: En mi opinión es quizá la característica más importante de un modelo. No es sólo que tenga significado claro, es que además ese significado es único, no interpretable. Esto es una garantía de buena comunicación y de posibilidad de automatización.

  • Principio 4- Los modelos de proceso son sobre las personas y para las personas: Por un lado, el modelo describe un proceso y, por tanto, lo que en último término hacen fundamentalmente personas. Pero, además, una de las funciones del modelo es comunicar, y esa comunicación, de nuevo, se produce esencialmente entre personas.

  • Principio 5- Existe lo que las personas hacen y lo que deberían hacer: Esa es una realidad que deben tener muy en cuenta los analistas de procesos y negocio. Con muchísima frecuencia el comportamiento en la realidad de las personas no es tan perfecto ni tan ajustado a procedimientos y objetivos como quisiéramos. A la hora de descubrir y modelar un proceso es fundamental conocer lo que realmente se hace, sea eso lo adecuado o no. Tiempo habrá luego para mejorar, pero el punto de partida debe ser la 'cruda' realidad.

  • Principio 6- Las personas trabajan en funciones pero hacen procesos: Cuando los expertos del negocio cuentan un proceso, tienden a no ver el proceso extremo a extremo, sino a tener en cuenta la actividad y punto de vista exclusivamente en su departamento, su función. Es preciso, a la hora de descubrir, modelar y mejorar procesos, ser capaces de contemplar la visión transversal de proceso a partir de esa información que con frecuencia es puramente de función.

  • Principio 7- Es lo que las personas hacen y no para qué lo hacen lo que cuenta: En este caso el autor se refiere a prestar atención a la verdadera actividad, no tanto al resultado en forma de datos que como consecuencia de esa actividad se obtiene.

Para quien no haya tenido experiencia en descubrimiento de procesos o de actividades similares como análisis de sistemas, algunos de estos principios pueden sonar abstractos, quizá extraños. Pero son la realidad pura de lo que sucede al trabajar en el descubrimiento y modelado de procesos. Tengámoslo en cuenta.


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.


lunes, 15 de octubre de 2018

La definición de Transformación Digital de Incipy


Sigo recopilando cuanta definición de Transformación Digital se me pone a tiro y consignándola en este blog, como una forma de intentar aclarar un concepto muy importante pero sin una visión compartida de forma unánime.

Las recopilo y comparo con mi propia visión de lo que la Transformación Digital es, o debe de ser.

Hace poco me he encontrado una nueva definición, en este caso la que propone Incipy y que me encontré en el informe 'Transformación e Innovación digital' firmado por Joana Sánchez y editado por el propio Incipy.

Bastante al principio de dicho informe se nos propone esta definición de Transformación Digital:

La reorientación de toda la organización, hacia un modelo eficaz de relación digital en cada uno de los puntos de contacto de la experiencia del cliente

Es una visión que pone el foco completamente en la relación con el cliente. De esta definición me gusta el uso de la palabra reorientación porque de una forma muy concisa nos hace sentir la Transformación Digital como una iniciativa que potencialmente afecta a toda la empresa u organización, que la hace virar en su orientación. Por otro lado, comparto que la relación con el cliente es uno de los puntos clave en que se puede (y debe) incidir mediante la aplicación de las soluciones digitales.

Sin embargo, comparado con mi entendimiento, esta definición se me queda corta en el alcance de la Transformación. La Transformación Digital, tal y como yo la entiendo, puede afectar a muchas más cosas que a la relación con el cliente. Puede afectar al porfolio de productos y servicios. Puede afectar a los procesos de negocio, no solo de relación con el cliente sino también de operación o soporte. Puede mejorar inmensamente los mecanismos de soporte a la decisión. Puede alterar la manera de gestionar la tecnología y los sistemas. Puede cambiar la cultura interna y la forma de colaboración de los profesionales. Puede, incluso, cambiar completamente el modelo de negocio. En fin, puede transformar casi cualquier apartado de la empresa y su gestión.

Si nos quedamos sólo transformar la relación con el cliente, no estaremos, creo, aprovechando toda la potencialidad de lo digital.

Consignada queda esta interesante definición de Incipy, pero yo prefiero mantener esa visión más amplia.


Artículos de este blogs relacionados

viernes, 12 de octubre de 2018

Un poco de Six Sigma con Craig Gygi y Bruce Williams

'Six Sigma for dummies' es un libro orientado a explicar de una forma comprensible, los principales aspectos de Six Sigma. Sin embargo, no nos debemos llamar a engaño ni por el título ni por el alegre diseño de su portada: aunque es cierto que los conceptos se explican de una forma lo más sencilla posible e intentando que se encuentre al alcance de cualquiera, se describe Six Sigma con bastante rigor y profundidad y en algunos momentos, aquellos en que se habla más del aparato estadístico de Six Sigma, es casi inevitable que la materia se convierta en algo árida y compleja.

El libro se estructura en nada más y nada menos que 26 capítulos, agrupados en seis partes:
  • PARTE 1: 'GETTING ACQUAINTED WITH SIX SIGMA BASICS': Proporciona una visión general de Six Sigma, antes de entrar en la explicación más detallada de cada uno de los pasos de su famoso esquema DMAIC, que ocupa las tres partes siguientes. 

    • 'Capítulo 1 - Better Business and Better Performance: Defining Six Sigma ': Explica lo que es Six Sigma y lo que supone desde una perspectiva de gestión.

    • 'Capítulo 2 - Linking Quality and Business: ': Cuenta el concepto de especificación, sus características y cómo éstas representan la voz del cliente. También se detiene a analizar el concepto de Calidad y la relación que guarda con la variabilidad.

    • 'Capítulo 3 - Examining the Principles and Language of Six Sigma': explica algunos fundamentos como las relaciones entre entradas y resultado, la causa-efecto y la correlación, y otros principios básicos de Six Sigma como la reducción de la variación, la medición como clave del éxito o la gestión del riesgo,

    • 'Capítulo 4 - Organizing for Improvement': Hace una introducción a la metodología DMAIC que se desarrolla en las siguientes partes y también explica el modelo de cinturones negro, verde y amarillo. Finaliza explicando las 5 fases en que se desarrolla una iniciativa Six Sigma.

  • PARTE 2: 'DMAIC: DEFINING AND MEASURING': Se ocupa de los dos primeros pasos del modelo Six Sigma a saber la Definición (D) y la medida (M). 

    • 'Capítulo 5 - Identifying and Right-Sizing projects': Explica cómo definir un proyecto Six Sigma, cómo identificar los resultados que buscamos, etc

    • 'Capítulo 6 - Launching a Project': Pasa ahora al lanzamiento del proyecto, describiendo el problema a atacar, estableciendo la aspiración en cuanto a mejora, y consiguiendo la aprobación del proyecto.

    • 'Capítulo 7 - Mapping to Identify Possible Factors': Explica cómo desarrollar un mapa de proceso, desarrollar los denominados SIPOC que describen un proceso específico y trazar los flujos de valor.

    • 'Capítulo 8 - Diagramming to Identify Possible Factors': Explica algunos modelos para obtener relaciones causa-efecto como los diagramas de afinidad, los diagramas de Ishikawa, el análisis de efectos (FMEA), etc

    • 'Capítulo 9 - Describing Performance With Numbers'. Cuenta algunas formas de describir el rendimiento con base en números, empezando por analizar los tipos de datos posibles, y explicando algunos primeros conceptos estadísticos como las distribuciones y sus medidas de centralización y dispersión

  • PARTE 3: 'DMAIC: ANALYZING': Continua, ahora, con el tercer paso del modelo Six Sigma, el análisis (A). 

    • 'Capítulo 10 - Depicting and Analyzing Data through Charts and Graphics: ': introduce algunos tipos de gráficos, como los histogramas, los whisker plots o los scatter plots.

    • 'Capítulo 11 - Analyzing for Value': presenta algunos conceptos y técnicas relacionados con la aportación de valor. Recuerda primero el concepto de desperdicio y las siete causas del desperdicio que reconoce Six Sigma. Luego presenta el framework de Kano como medio de 'escuchar' la voz del cliente y el análisis causa-efecto.

    • 'Capítulo 12 - What's Normal? Recognizing Normally-Shaped Variations': Explica en detalle la distribución normal y su importancia.

    • 'Capítulo 13 - Assessing Capability: Comparing the Voices of the Customer and the Process': presenta con bastante detalle algunas parámetros y medidas para conocer las capacidades del proceso y habla de temas como, por ejemplo, la tasa de defectos.

    • 'Capítulo 14 - Gauging Gauges: measurement System Analysis (MSA)': Analiza la medición en sí misma y las variaciones que puede introducir y presenta los análisis de los sistemas de medición (MSA).

    • 'Capítulo 15 - Mining Data and Process for Insight': explica algunas técnicas más avanzadas para intentar obtener conclusiones y así nos habla, por ejemplo, del análisis multivariante.

    • 'Capítulo 16 - Making Confident Decisions': habla de ideas y técnicas de carácter estadístico para poder conseguir conclusiones confiables y además poder caracterizar cuantitativamente esa confiabilidad. Para ello habla de conceptos como población y muestra, habla del teorema central del límite y de los intervalos de confianza.

  • PARTE 4: 'DMAIC: IMPROVING AND CONTROLLING': Se ocupa de los dos últimos pasos: la mejora (I) y el control (C). 

    • 'Capítulo 17 - Forecasting Future Performance': intenta establecer relaciones de carácter cuantitativo entre variables y resultados. Nos habla de correlación, regresión múltiple y, en general, técnicas matemáticas para establecer esas relaciones con base a fórmulas y curvas.

    • 'Capítulo 18 - Designing, Conducting and Analyzing Expriments (DOE)': Habla del diseño de experimentos, de cómo diseñarlos y gestionarlos de la mejor forma.

    • 'Capítulo 19 - Standarizing on Improvement': Habla de cómo controlar y gestionar de forma continua la mejora y nos habla de aspectos y técnicas como las 5S o el Poka-Yoke.

    • 'Capítulo 20 - Maintaining Gains through Statistical Process Control': un poco en la misma línea del control continuo nos explica ahora el control estadístico de procesos con sus curvas y sus fórmulas en las que se adentra con bastante detalle.

  • PARTE 5: 'LOOKING AT THE SIX SIGMA TECHNOLOGY TOOL LANDSCAPE': Parte ya más corta pensada para orientar al lector en las herramientas de todo tipo que se pueden utilizar en la gestión Six Sigma, algunas mediante el empleo de soluciones de propósito general y otras más específicas de Six Sigma. 

    • 'Capítulo 21 - Eyeing Process Characterization and Optimization Technologies': habla de técnicas y tecnologías para caracterizar y optimizar un proceso, empezando desde lo más trivial como el lápiz y papel, pasando por herramientas ofimáticas de propósito general y acabando en paquetes más especializados como los de inteligencia de procesos.

    • 'Capítulo 22 - Tools for Performing Six Sigma Analysis': Da un barrido ahora por herramientas de análisis, descartando en esta ocasión los mecanismos manuales, pero empezando con algo tan sencillo como una buena calculadora, pasando por hojas de cálculo y terminando con herramientas especializadas como Minitab o JMP.

    • 'Capítulo 23 - Managing Six Sigma': Por último, acomete el tema de las herramientas de gestión donde no especifica mucho pero, en general, apuesta por las herramientas de dirección de proyectos.

  • PARTE 6: 'THE PART OF TENS': Una parte que reúne una serie de conclusiones y consejos agrupados de diez en diez. 

    • 'Capítulo 24 - Ten Top Do's and Don'ts of Six Sigma': Recoge las diez cosas que se han de hacer o no en una iniciativa Six Sigma.

    • 'Capítulo 25 - Ten Ways to Gain Synergies with Lean and Six Sigma': Proporciona un decálogo que favorece la convergencia de Six Sigma con Lean Management.

    • 'Capítulo 26 - Ten Places to Go for Help': Orienta al lector sobre otros diez sitios donde obtener más información.
'Six Sigma for dummies' es un libro interesante, riguroso y con mucho empeño en explicar de una forma sencilla todos los conceptos de Six Sigma. Creo que tiene mucho mérito lo que consigue pero, aún así, no es un libro tan sencillo en algunos momentos como pudiera pensarse, especialmente cuanto se adentra en los temas más estadísticos. No es un problema achacable al libro ni sus autores: es el propio tema el que dificulta un tratamiento demasiado simple si no se quiere caer en la superficialidad.

Creo que es, realmente, un buen recurso para iniciarse en Six Sigma y, en ese sentido, cumple plenamente con lo que entiendo son sus objetivos.

Craig Gygi

(Fuente: Traducción y ligera elaboración propia de su biografía en StrategicProductivity.)

Craig Gygi
La carrera de Craig Gygi se ha enfocado en ayudar a las empresas a implementar una forma de trabajar sostenible, escalable y mejor. Su innovación, pasión, diligencia y liderazgo de operaciones, ha llevado a aquellos con los que ha trabajado a obtener una mayor satisfacción de cliente, incremento de los ingresos y valor para los accionistas, mejores márgenes y una apreciablemente mejor experiencia de los empleados y compromiso de los mismos.

Antes de fundar Strategic Productivity, Craig trabajó como ejecutivo senior, consultor y asesor de negocios. Como COO de Purple, un distribuidor de tecnología multicanal, dirigió la estrategia y ejecución del diseño de nuevos productos, procesos operativos, cadena de suministro global, fabricación, experiencia de cliente, métricas y sistemas posibilitando una valoración de 1 billón de dólares a los meses del lanzamiento.

Como vicepresidente ejecutivo de Operaciones en MasterControl, líder de software QMA en la nube, Craig condujo las operaciones globales a multiplicarse por tres al tiempo que duplicaba su productividad. Craig también ha ejercido otros roles, incluyendo el de CEO, excelencia operacional six sigma, desarrollo de software, diseño de productos, servicios analíticos, farmacia y dispositivos médicos, aerospacial, electrónica y dirección general. Craig tiene experiencia operativa internacional en el Pacífico Sur, Asia y Europa.

A Craig le encanta aprender y enseñar. Ha sido autor de varios libros superventas sobre Operaciones y mejora basadas en datos. También ha enseñado Operaciones en la Eccles School of Business en la Universidad de Utah. Cientos de profesionales se han beneficiado de su formación, coaching y mentoring en Operaciones y resolución de problemas.

Craig tiene el grado y máster en Ingeniería Mecánica de la Brigham Young University.

En su tiempo libre, disfruta en familia de la escalada, esquí alpino, bicicleta de montaña, navegar y servicios a la comunidad y la iglesia.

Puedes saber más del autor visitando su perfil en LinkedIn

Ficha técnica: