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

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.

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:

TITULO: Business Process Management. A rigorous approach

AUTOR: Martyn Ould.

EDITORIAL: British Computer Society

AÑO: 2007

ISBN: 978-1-902505-60-2
PAGINAS: 346

Artículos de este blog relacionados

• Principios para el modelado de procesos
• Siete situaciones y media en que se necesita descubrir y modelar un proceso de negocio

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.

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

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.

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.

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.

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

• ¿Qué nos dicen desde McKinsey que es la Transformación Digital?
• La "casi" definición de Transformación Digital de Raquel Roca
• Tres definiciones de transformación digital y una lista de objetivos
• #macrotweet: una definición de transformación digital

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:

TITULO: Six Sigma for dummies

AUTOR: Craig Gygi y Bruce Williams.

EDITORIAL: Jon Wiley & Sons

AÑO: 2012

ISBN: 978-1118120354
PAGINAS: 408

Artículos de este blog relacionados

• Mister Proper y los procesos de negocio. El método de las 5S
• Recordando las siete formas de desperdicio en procesos
• Tres criterios simples para reconocer la adición de valor para el cliente
• Diez formas de mejorar un proceso de negocio
• DMAIC: Recordando las cinco fases de la metodología de proyectos Six Sigma
• ¿Las especificaciones bailan la RUMBA?
• Algunas ideas fundamentales sobre Six Sigma

Mister Proper y los procesos de negocio. El método de las 5S

Si, aunque parezca mentira, Mister Proper puede hacer algo por nuestros procesos de negocio, por su eficiencia y por la calidad del conjunto. Porque aplica el método de las 5S.

Con frecuencia la mejora de los procesos de negocio puede implicar técnicas complejas, rediseños brillantes y también la aplicación de avanzadas y sofisticadas tecnologías. Así es, y así tenemos que hacerlo. Nada hay de malo en ello, sino todo lo contrario.

Pero también hay formas sencillas, muy sencillas, de mejorar nuestros procesos de negocio o el funcionamiento de nuestra empresa en su conjunto.

Muy en concreto, hay un método que podríamos denominar preventivo o, nunca mejor dicho, higiénico, que sorprende por los sencillo y elemental y que, sin embargo, produce buenos resultados. Se trata del método de las 5S nacido, como tantos otros métodos de esta índole, en Japón.

La esencia del método es muy, muy simple: mantén el orden y la limpieza en los puestos de trabajo. Y sólo con eso, se pueden obtener importantes mejoras de productividad y calidad.

El nombre del método viene, como en tantos casos, de la primera letra en Inglés de las acciones que componen el método. Esas acciones y el método en sí mismo, son las siguientes:

• (S)ort (clasificar): Se trata de revisar todos los equipos y materiales de los puestos de trabajo y determinar qué es lo que debe permanecer allí. Cualquier cosa que ocupe un lugar innecesario debe ser llevado al sitio que le corresponde o, simplemente, hay que deshacerse de ello.


• (S)traighten (ordenar): Tras el paso anterior, todo lo que queda en el puesto de trabajo es realmente esencial. Ahora, el siguiente paso, es asignar a cada cosa un sitio concreto y claramente determinado, de forma que todo deba estar en su lugar y, cuando no es así, sea muy evidente ese desorden.


• (S)crub (limpiar): Limpiar, sí limpiar, todo lo que esté en el puesto de trabajo, incluyendo, si es necesario, el barnizar o pintar.


• (S)tandarize (estandarizar): Hacer que, en la medida de lo posible, todos los puestos de trabajo sean similares, lo que facilita que distintas personas puedan adoptar el mismo lugar de trabajo


• (S)ustain (sostener): Hacer un calendario o plan de mantenimiento para aplicar de nuevo las 5S al puesto de trabajo.

¿A que, en el fondo, nos resulta familiar? Es casi, casi, lo que nuestras madres siempre nos pidieron, pero ahora llevado al puesto de trabajo. Es como acudir a Mister Proper para que mejore nuestros procesos. Pues, precisamente por lo simple, por lo que de sentido común tiene, ya nos da la pista de que debe ser bastante eficaz.

Además, es un método al alcance de cualquier empresa u organización y que, aunque inicialmente surge de entornos de fabricación, es aplicable también en oficina.

¿A qué esperamos, pues?

Yo, de momento, tras acabar este artículo, voy a ir revisando lo que tengo encima de mi mesa de despacho desde donde escribo...

En Pulse: Una Transformación Digital desde el conocimiento

No. No os creáis que la Transformación Digital es palabrería. No os confiéis pensando que se trata de un mero slogan marketiniano, propio de consultoras o ‘speakers’ en busca de la venta de sus servicios o conferencias. No cometáis el error de deciros a vosotros mismos que ‘ya pasará’ o que ‘ya nos vendrán con otra historia dentro de unos meses’.

La Transformación Digital está aquí para quedarse

No. Tal vez el término Transformación Digital pase de moda, si desde un punto de vista marketiniano y de comunicación se lo considera gastado. Es posible. Pero lo que no va a pasar de largo, en absoluto, es lo que ese término significa e implica.

La revolución digital lleva unos cuantos años entre nosotros con una cadencia creciente y todo apunta a que va a continuar a un ritmo vertiginoso durante, al menos, unos cuantos años más. Todo hace pensar que asistiremos al nacimiento, maduración y adopción de nuevas tecnologías que traerán, como consecuencia, la aparición de nuevos productos y servicios algunos inimaginables hoy día, nuevos modelos de negocio tal vez completamente disruptivos, nuevos comportamientos y culturas, cambios estructurales en sectores, en la economía y en la sociedad.

No. Eso no va a pasar ‘de largo’. En todo caso pasará ‘por encima’.

La Transformación Digital no es más (ni menos) que la forma en que las organizaciones responden a los retos y amenazas que esa revolución digital trae consigo, realizando cambios profundos por el camino.

Y esa transformación, el cambio profundo que cada empresa o administración tiene que acometer, que más le vale acometer, no se hace sólo con llamadas al cambio, con ‘frases redondas’ o con apelativos a las personas.

No.

La Transformación Digital se hace con estrategia, con esfuerzo y con el factor que quiero destacar en este artículo: el rigor y el conocimiento.

El conocimiento necesario

La Tecnología Digital no es sencilla. Y hacer un gran cambio tampoco. Así que hay que saber.

¿Qué hay que saber?

Muchas cosas, pero voy a destacar las cuatro que considero más importantes.

Ante todo y sobre todo, y aunque puede que haya a quien no le guste oírlo, hay que saber de tecnología. Sí, hay que saber de tecnología. No todos deben saber lo mismo, por supuesto. Los desarrolladores o arquitectos deben conocer las tecnologías en profundidad. Los estrategas y directivos deben saber identificar las oportunidades y amenazas que traen consigo. Los responsables de marketing cómo pueden traducirla en productos y servicios. Los responsables de operación cómo se gestionan y cómo pueden optimizar procesos y operativas. Los responsables de recursos humanos el impacto cultural. Y así sucesivamente. Cada uno en su rol, pero todas las áreas deben conocer la tecnología digital. No hay otra. No hay excusas. Por eso es una Transformación Digital.

Además, hay que saber, y de verdad, de estrategia, porque hay que saber entender los cambios más profundos que la revolución digital trae consigo, las disrupciones que habilita y los posibles cambios en el panorama competitivo. Es necesario entender los sectores y mercados en que nos movemos y avistar los cambios estructurales que se pueden producir. Es preciso, en definitiva, saber incardinar la Transformación Digital en el plan estratégico de compañía, un verdadero plan, no sólo un discurso o powerpoint. Quizá incluso debamos convertir a la Transformación Digital en la piedra angular de ese plan estratégico.

Y, por supuesto, hay que entender muy bien el propio negocio y la propia operación para saber cuáles son nuestras capacidades, necesidades, oportunidades y opciones. Hay que conocer procesos, indicadores, capacidades y realidades. Este conocimiento lo deberíamos dar por supuesto, pero prefiero explicitarlo… por si acaso.

Y finalmente voy a abogar por el conocimiento en el ámbito de la dirección de proyectos y programas. Tal vez pueda sorprender esta apuesta, pero creo que es absolutamente clave, al mismo nivel que las tres anteriores. La Transformación Digital, al menos como yo la entiendo, no es más que un gran proyecto, o mejor, en terminología de PMI, un gran programa, un conjunto de proyectos relacionados y con un mismo objetivo estratégico. La mezcla de técnicas y habilidades propias de la dirección de proyectos son imprescindibles para definir y gestionar correctamente la transformación digital. Una gran estrategia puede arruinarse si no somos capaces de implementarla correctamente. Y para implementarla, la dirección de proyectos es imprescindible.

Conclusión

No. No es creáis que la Transformación Digital es palabrería. Es real.

Y no os creáis que es sencilla, porque es compleja.

Y para llevarla a cabo debéis partir del conocimiento.

Del conocimiento estratégico de vuestro sector y mercado y del conocimiento de vuestra propia compañía, sus procesos, capacidades y funcionamiento. Pero del conocimiento también, de la tecnología digital y de las técnicas de dirección de proyectos para hacer la transformación una realidad.

Voy a conceder que toda empresa sabe, o debe saber, de estrategia y de su propia realidad. Pero ¿todas entienden de verdad de tecnología? ¿Todas saben realmente gestionar un gran proyecto o programa?

Si no es así, más vale que vayan adquiriendo cuanto antes esas capacidades.

Al menos, ése es mi convencimiento.


Imagen de portada: Escultura 'House of Knowledge' de Jaume Piensa. Imagen por Tim Green en Flickr

*****

Artículo publicado en Pulse el 09/10/2018 y en Medium en la misma fecha

Pulse es el servicio de noticias personalizadas de la red social profesional LinkedIn

Recordando las siete formas de desperdicio en procesos

En el artículo anterior hablábamos de unos criterios sencillos para identificar qué tareas de un proceso o qué características de un producto no añaden valor para un cliente. En metodologías de calidad como Six Sigma o Lean, lo que no añade valor se considera desperdicio ('muda' por su denominación japonesa) y es candidato a ser eliminado.

En el ámbito de Six Sigma, y como nos recuerdan Craig Gygi y Bruce Williams en 'Six Sigma for dummies', los posibles desperdicios se agrupan en siete categorías.

Ya hemos hablado de ellas alguna vez pero, dado que últimamente estamos tratando mucho de procesos de negocio en este blog, vale la pena recordarlas. Esas siete categorías son las siguientes:

• Transportation (transporte): El tener que mover piezas, material o información no añade valor para el cliente porque de hecho, por sí mismo, no cambia ni la forma encaje o función del producto o servicio que estamos generando. Por tanto, no satisface uno de los criterios de adición de valor y es desperdicio.


• Waiting (esperas): Cuando una persona, o pieza, material, material, información o equipo permanece inactivo y sin que se haga nada o sin que se haga nada sobre él, no estamos añadiendo valor y es desperdicio. En la fuente citada se cita una excepción en que la espera si añade valor como es el caso de la maduración del vino o el queso, pero es que en este caso particular la espera sí que produce cambios en el producto y unos cambios valorados, y mucho, por el cliente.


• Overproduction (exceso de producción): El exceso de producción consiste en una producción excesiva a sabiendas, en previsión de una demanda futura. Aunque el exceso de producción puede ser un acto de previsión, el problema que genera es que, en general, va acompañado de otras formas de desperdicio como esperas o inventario. Por ello, en general, producir en exceso genera más daño que beneficio y por eso se considera desperdicio.


• Defects (defectos): Este caso es muy fácil de entender. Generar un producto defectuoso puede implicar un trabajo tirado directamente en la basura o, en otros, la necesidad de un retrabajo adicional para corregir el defecto.


• Inventory (Inventario): El inventario entendido en sentido amplio (puede ser realmente materiales o productos en un almacén pero, también, elementos en proceso o productos terminados aún no distribuidos e, incluso, información pendiente de procesar) consume recursos como, por ejemplo, espacio físico y sin embargo no cumple ninguno de los tres criterios de adición de valor.


• Motion (movimiento): Cualquier proceso que exiga movimiento de personas o equipos, más allá del mínimo imprescindible, es una forma de desperdicio porque consume recursos sin aportar valor.


• Extra processing (procesado extra): igualmente, hacer un procesado excesivo, más allá de lo requerido, no añade más valor pero sí que consume recursos.

Los autores citados nos sugieren aplicar el acrónimo TWO DIME que, literalmente significa dos monedas de diez centavos y que recoge las iniciales de las siete categorías en Inglés. Para el público de habla hispana el valor nemotécnico de ese acrónimo es menor, evidentemente, que para los norteamericanos, pero algo puede ayudar.

Finalmente, decir que a la hora de aplicar esta tipología, así como los tres criterios que veíamos en el post anterior, creo que es necesario aplicar el sentido común, como la excepción de la espera en el caso del vino y el queso nos demuestra. Se trata de entender el mensaje de fondo y que lo que estas categorías quieren decir, y aplicarlo con cordura a nuestra empresa y nuestros procesos.

Artículos de este blog relacionados:

• Dónde ahorra Lean Manufacturing... y mucho más
• Aplicando los principios lean al mundo del software: 7 fuentes de desperdicio a eliminar