viernes, 29 de junio de 2018

Gestión de procesos de negocio con Dumas, La Rosa, Mendling y Reijers

'Fundamentals of Business Process Management' es un gran libro que cubre correctamente todos los aspectos relevantes de la disciplina de gestión de procesos, incluyendo la identificación, modelado, mejora y automatización, todo ello en un estilo llano pero al tiempo erudito, actuando como libro de texto universitario pero también perfectamente aplicable al mundo de la empresa.


El libro se estructura en diez capítulos:

  • 'Introduction to Business Process Management': Comienza centrando lo que es un proceso de negocio para, a continuación, repasar el origen e historia de la disciplina de Business Process Management y termina explicando el ciclo de vida de gestión de un proceso de negocio, lo que sirve para estructurar el contenido del resto de libro.


  • 'Process Identificacton': Acomete la primera etapa de ese ciclo de vida, la identificación de los procesos objeto de gestión, para lo cual apuesta por centrarse en los procesos clave y luego explica la composición de un arquitectura de procesos.


  • 'Essential Process Modeling': Primero de los capítulos dedicado al modelado de procesos, que se hace con base en el lenguaje convertido en estándar de facto: BPMN. En este capítulo explica los elementos fundamentales como son las actividades, las decisiones, los recursos y los artefactos que reflejan información
  • .

  • 'Advanced Process Modeling': Segundo capítulo dedicado al modelado que, en este caso, comenta los elementos más avanzadas de BPMN, entrando en el modelado de eventos y excepciones o cómo reflejar la repetición, el retrabajo, las reglas de negocio o las coreografías.


  • 'Process Discovery': se centra en el llamado descubrimiento de procesos que es el levantamiento de la foto actual de proceso (AS-IS), explicando desde el papel del analista de negocio, hasta mecanismos para interaccionar con los expertos de negocio (entrevistas, talleres, etc), un método paso a paso para realizar esta labor y aspectos para asegurar la calidad del resultado.


  • 'Qualitative Process Analysis': Primer capítulo de los dedicados al análisis del proceso ya levantado, en este caso, mediante métodos cualitativos como el análisis de valor añadido, el análisis de causa raíz o la gestión de problemas (issues) y su impacto.


  • 'Qualitative Process Analysis': Segundo capítulo dedicado al análisis pero ahora con métodos cuantitativos como el análisis de flujos, la teoría de colas o la simulación.


  • 'Process Redesign': Una vez levantado el proceso y analizado, en este capítulo se explica el rediseño del proceso de negocio, centrándose sobre todo en proporcionar heurísticas de mejora de procesos y explicando también un método alternativo, el Product-Based Design muy orientado a productos de información (datos)
  • .

  • 'Process Automation': Explica la automatización o informatización del proceso, lo que se traduce en una explicación de los BPMS (Business Process Management Systems), sus ventajas y retos, y la forma de hacer que un modelado de proceso pueda servir como base para su automatización.


  • 'Process Intelligence': Capítulo final que trata fundamentalmente de la explotación de los datos que genera un proceso de negocio. Así se habla de la generación de logs de proceso, incluyendo una breve descripción del formato XES, el descubrimiento automatizado de la estructura de un proceso de negocio, la monitorización y análisis de desempeño del proceso o el análisis de conformidad de la ejecución de un procesos con su definición.

Cada capítulo se acompaña de ejemplos, abundancia de ejercicios (algunos resuesltos directamente y otros propuestos como tarea adicional para el lector/alumno), y un resumen de todo lo visto.

'Fundamentals of Business Process Management' es un libro completo, bien estructurado, con explicaciones al tiempo claras y rigurosas, y que constituye una referencia fundamental del campo de la gestión de procesos de negocio, al menos, la mejor que yo he encontrado hasta ahora.

Muy aconsejable.

Marlon Dumas

(Fuente: Ficha de profesor en Universidad Internacional de La Rioja - UNIR)

Marlon Dumas
Doctor y Máster en Informática de la Universidad de Grenoble Alpes (Francia) y Licenciado en Matemáticas e Informática de la Escuela Normal Superior de París (Francia). Muy conocido internacionalmente por sus contribuciones en el campo de gestión de procesos de negocio, particularmente como co-autor del libro de texto 'Fundamentals of Business Process Management' que es usado en más de 200 universidades mundialmente.

Nacido en Honduras, es científico informático e investigador activo en los campos de BPM y Analítica de Datos de Negocio. Actualmente, profesor de Sistemas de Información en la Universidad de Tartu en Estonia, donde dirige un grupo de investigación en ingeniería de software y sistemas de información, y el Programa Internacional de Maestría en Ingeniería de Software. Profesor adjunto en la Escuela de Sistemas de Información, Facultad de Ciencias e Ingeniería de Queensland University of Technology (Australia), donde contribuye en el MOOC "Fundamentals of Business Process Management" que ha sido completado por más de 10000 participantes. Durante su carrera, el profesor Dumas ha participado en proyectos de investigación con varias empresas líderes, incluyendo SAP AG, Microsoft/Skype, IBM, y Swedbank. El profesor Dumas es co-autor de más 200 publicaciones científicas y de 10 patentes registradas en EUA y UE, incluyendo siete en el campo de BPM.

Marcello La Rosa

(Fuente: Traducción y ligera elaboración propia de la biografía en su página oficial)

Marcello La Rosa
Profesor de Sistemas de Información con la School of Computing and Information Systems en la Melbourne School of Engineering, en The University of Melbourne (UoM), Australia. Antes tuvo un puesto académico en la escuela de Sistemas de Información, en la Science & Engineering Faculty de la Queensland University of Technology en Brisbane, Australia, donde dirigió la asignatura de BPM (2016-17) y fue director académico de agenda corporativa (2012-2017). También recibió una beca de investigación en Sistemas de Información de la University of Liechtenstein (2012-14) y ocupó un puesto a tiempo parcial como investigador principal en NICTA, actualmente Data61 (2012-15).

Adopta un enfoque de ingeniería a la investigación en sistemas de información. Su investigación dirige el diseño, implementación y validación de artefactos de sistemas con modelos, métodos y técnicas con foco en la tecnología. Se esfuerza para implementar los resultados de su investigación a través de herramientas de software libre para maximizar el alcance de la comunidad.

El área de aplicación de su investigación es la gestión de procesos de negocio, Business Process Management (BPM). Postula la idea de analizar el rendimiento organizacional a través de la lente de proceso, empezando por entender que el rendimiento organizacional es funcion del rendimiento de los procesos. Su investigación abarca diferentes materias de BPM, con foco en la búsqueda de procesos, modelado de procesos y consolidación, así como automatización de procesos. Dada la naturaleza multidisciplinar de BPM, en su investigación toma prestadas técnicas de un gran número de disciplinas, más allá de la ingenieria de sistemas, incluyendo gestión de sistemas, arquitectura empresarial, modelado conceptual, ingeniería de software, data mining y machine learning, investigación de operaciones y métodos formales.

Su investigación está expuesta en repositorios públicos como Google Scholar, UoM Minerva Access, arXiv, QUT ePrints y BPMCenter.

Ha estado enseñando diferentes aspectos de BPM; desde los más operacionales como el modelado de procesos, análisis, mejora, automatización y descubrimiento, hasta aspectos de gestión como el alineamiento estratégico y gobierno, para estudiantes tanto de grado como posgrado en Australia y otros países. También ha formado a cientos de mandos, analistas y arquitectos de soluciones en el campo del BPM.

Con base en esta experiencia, ha sido co-autor de 'Fundamentals of Business Process Management', el primer libro abarcador sobre BPM. Este libro ha sido incluido en el currículum de más de 200 universidades e instituciones de enseñanza del mundo.

Después, los autores han usado este libro de texto para diseñar un MOOC en tres partes titulado 'Fundamentals of Business Process Management' acreditado con ABPMP, que imparten a través de la plataforma EdCast, y un segundo MOOC de naturaleza introductoria llamado 'BPM: An Introduction to Process Thinking'disponible en la plataforma FutureLearn. En conjunto, estos dos MOOC han atraído a más de 26.000 participantes hasta la fecha.

Valora el desarrollo de software abierto como medio de llegar a diferentes comunidades: académica, estudiantes y practicantes. Por ese motivo, lidera la iniciativa Apromore, una colaboración estratégica entre varias universidades, que ha recbido financiación pública y privada para el desarrollo de una plataforma de analítica avanzada de procesos de negocio. Esta plataforma combina técnicas para la gestión de grandes colecciones de modelos de proceso mediante técnicas de minado de procesos, con un foco especial en los usuarios finales. También contribuye a la plataforma Nirdizati para la monitorización predictiva de procesos. Otros proyectos abiertos sobre BPM que ha dirigido o a los que ha contribuido en el pasado incluyen Process Configuration, que recoge esfuerzos en la gestión de la variabilidad en sistemas orientados a procesos y YAWL, un sistema BPM basado en comunidad y orientado a la investigación.

Jan Mendling

(Fuente: Ficha de profesor en Universidad de Viena)

Jan Mendling
Jan Mendling es profesor a tiempo completo en el Institute for Information Business de la Wirtschaftsuniversität Wien (Universidad de Viena), Austria. Sus áreas de interes en investigación incluyen varias materias en relación a la gestión de procesos de negocio y sistemas de información. Ha publicado más de 250 artículos de investigación, entre otros en ACM Transactions on Software Engineering and Methodology, IEEE Transaction on Software Engineering, Information Systems, Data & Knowledge Engineering, y Decision Support Systems. Es miembro del comité editorial de siete revistas internacionales, miembro del comité de la Austrian Society for Process Management y uno de los fundadores de la comunidad BPM de Berlín, organizador de varios eventos académicos sobre gestión de procesos y miembro de la IEEE Task Force on Process Mining. Su tesis doctoral ganó el premio Heinz-Zemanek de la Austrian Computer Society y el premio German Targion-Award para disertaciones en el área de gestión estratégica de la información.

Hajo A. Reijers

(Fuente: Ficha de profesor en Universidad de Tecnología de Eindhoven)

Hajo A. Reijers
Profesor a tiempo completo de informática de negocio en el Department of Computer Science de la Universidad de Amsterdam, donde dirige el grupo de Business Informatics. También es profesor a tiempo parcial en el grupo AIS del Department of Mathematics and Computer Science de la Eindhoven University of Technology (TU/e). Su investigación y docencia se centran en la gestión de procesos de negocio, analítica de datos y modelado conceptual. Coopera estrechamente con empresas en el dominio de los servicios de cuidado de la salud así como con varios investigadores internacionales.

Ficha técnica:

miércoles, 27 de junio de 2018

El papel de los chatbots en la automatización de procesos de negocio


No nos resulta difícil imaginar los chatbots como elementos útiles, y casi divertidos, en el entorno del hogar, la informática personal o en diálogos sin mucha trascendencia.

Lo que a lo mejor no percibimos tan claramente es que muchos chatbots, muy especialmente los que se utilizan dentro de empresas, realmente son un elemento de automatización de procesos de negocio. Cierto es que constituyen una automatización muy especializada, orientada a la conversación más o menos natural con humanos y utilizando en ocasiones interfaces avanzadas de voz. Cierto es también, que en esa misma senda de la especialización, la vocación de los chatbots no es la de una automatización extremo a extremo de un proceso sino sólo la automatización de tareas muy específicas del mismo.

Este papel automatizador en un proceso de negocio nos lo confirma Amir Shevat en su libro 'Designing bots' cuando nos dice:

The purpose of bots for business is to facilitate a task of a business process in an easy, pleasant, and productive way. Communications should be to the point, with a focus on getting things done rather than talking abut it.

Automatización especializada, si, pero automatización al fin y al cabo.

Por eso, creo que debemos considerar los chatbots como una herramienta más de la automatización de procesos de negocio junto con BPMS y RPA.

No creo que tardemos, de hecho, en ver suites BPMS o, más probablemente, suites RPA que incluyan entre sus capacidades la de incluir chatbots como una funcionalidad más. Puede incluso que ya existan ofertas en ese sentido, aunque en este momento a mí no me consten.

La automatización de procesos de negocio no tiene por qué ser ni aburrida ni artificiosa, como nos demuestran los chatbots, pero eso no quita para que sea automatización y que incida por tanto, positivamente, en la eficiencia y escalabilidad de los procesos de negocio.


lunes, 25 de junio de 2018

¿Qué son los chatbots?


En el actual panorama de creciente automatización de procesos, de creciente sustitución de personas por robots (físicos o de software) y creciente también, uso de inteligencia como parte del software, una de las áreas de trabajo más activas es lo que se denomina familiarmente chatbots.

Unas piezas de sofware que emulan hasta cierto punto la conversación con un ser humano, en algunos casos sobre las aplicaciones de mensajería (Facebook Messenger, Slack y similares), en otros casos sobre soportes más tradicionales como los SMS o los correos electrónicos y en otras, en fin, haciendo uso avanzado de técnicas de inteligencia artificial como el procesamiento del lenguaje natural y el reconocimiento y síntesis de voz como podemos ver en Siri, Cortana, Alexa y en dispositivos para el hogar como Google Home o Amazon echo.

Para explorar el tema de los chatbots, acudo al libro de  Amir Shevat, titulado 'Designing bots: creating conversational experiences'. Y, empezando por el principio, me encuentro con una definición de qué son esos bots. Dice así:

At a very basic level, bots are a new user interface. This new user interface lets users interact with services and brands using their favorite messaging apps. Bots are a new way to expose software services through a conversational interface. Bots are also referred to as chatbots, conversational agents, conversational interfaces, chat agents and more. 

Algunas cosas a destacar. Por un lado, existen unos bots más complejos que otros pero, en cualquier caso, tienen un ámbito relativamente acotado: el servir de interfaz con humanos. Es decir, no se trata de robots de propósito general sino que su objetivo es 'sólo' dialogar con seres humanos (para ofrecer información, recibir instrucciones, etc). 

En general, estos chatbots deben luego interactuar con otro software que actua como 'backoffice' y que es el encargado de proporcionar los servicios propiamente dichos. Es decir, los chatbots son una forma de interfaz de usuario, de exponer unos servicios subyacentes, pero no son esos servicios.

Lo diferencial frente a otras formas de interfaz es que nos hallamos ante una interfaz de naturaleza conversacional, dialogada, lo que aporta mucha naturalidad a la interacción de cara a las personas, pero a cambio de exigir del bot una cierta sofisticación que le permita mantener esa conversación, entender el lenguaje natural y reaccionar ante imprevistos y comportamientos inesperados por parte del humano.

Esa capacidad de mantener un diálogo más o menos natural les proporciona a los chatbots una apariencia de inteligencia. En algún caso, de hecho, se apoyan en tecnología de inteligencia artificial pero también hay casos muchísimo más sencillos y que utilicen algoritmos mucho más prosaicos.

Nos quedamos, pues, con los chatbots como un sofware de interfaz de usuario de naturaleza conversacional. En próximos posts, hablaremos un poco más de esos chatbots.

viernes, 22 de junio de 2018

El cuadrilátero del diablo


Aunque en la imagen de cabecera de este post hayamos dispuesto un ring, el cuadrilátero del diablo ('devil's quadrangle') no es en realidad una cancha de boxeo sino el terreno en que se lucha por mejorar un proceso de negocio.

En este cuadrilátero se dibujan las cuatro dimensiones en que se mueven las prestaciones de un proceso de negocio, a saber:

  • Tiempo
  • Coste
  • Calidad
  • Flexibilidad

En la tarea de análisis y redefinición de procesos de negocio intentamos, en general, disminuir las dos primeras, es decir, el tiempo y el coste y, en cambio, incrementar la calidad y la flexibilidad. Sin embargo, no siempre será posible mejorar en las cuatro dimensiones y, por ejemplo, una mejora en flexibilidad puede llevar aparejado un mayor coste. La habilidad de los analistas y, sobre todo, las prioridades de negocio, deben proporcionar el equilibrio adecuado.

El papel de este cuadrilátero del diablo es más de tipo conceptual que práctico, pero bueno es disponer de estas sencillas metáforas, como también podría serlo el triángulo de hierro de la dirección de proyectos, para consolidar nuestros conocimientos y guiar nuestra actuación.


miércoles, 20 de junio de 2018

La personalidad del analista de procesos


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

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

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

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

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

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

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

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

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

  • Neurosis: ansiedad, depresión y vulnerabilidad

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

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

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

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

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

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

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


martes, 19 de junio de 2018

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


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

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

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

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


lunes, 18 de junio de 2018

Tres retos para el levantamiento de procesos de negocio


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

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

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

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

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

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

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

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

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


viernes, 15 de junio de 2018

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


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

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

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

¿Qué significa eso?

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

¿Todavía parece un galimatías?

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

miércoles, 13 de junio de 2018

Ciclo de vida de un proceso de negocio


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

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

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


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

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

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

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

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

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

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

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

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


martes, 12 de junio de 2018

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


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

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

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


lunes, 11 de junio de 2018

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


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

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

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

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

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

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

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

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

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

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

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

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

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

viernes, 8 de junio de 2018

Aprendiendo RPA y el uso de UiPath con Alok Mani Tripathi

'Learning robotic process automation' es un libro tremendamente austero, pero creo que efectivo, para dar los primeros pasos en el mundo de RPA (Robotic Process Automation). El libro tiene como dos partes, aunque muy desigualmente repartidas a lo largo del mismo. La primera parte es una explicación general de los conceptos de Robotic Process Automation. Esto se recoge en el primer capítulo. El resto del libro es realmente, una especie de guía de uso de la herramienta de RPA de UiPath.

De esta herramienta, y aportando ejemplos y pantallas reales, nos explica, desde su instalación, hasta el desarrollo de robots software empleando la grabación, diseñando flujos, manipulando datos y ficheros, gestionando los eventos de pantalla o usando plugins y extensiones para interactuar, por ejemplo, con SAP, Excel, Java, el correo electrónico, o la integración con navegadores, pasando por aspectos más cercanos a la prueba, administración y operación como son el trazado, la depuración, el despliegue de robots en producción o el control de código y versiones.

Todo esto se encuentra estructurado en los siguientes diez capítulos:
  • 'What is robotic process automation'
  • 'Record and play'
  • 'Sequence, flowchart and control flow'
  • 'Data manipulation'
  • 'Taking control of the controls'
  • 'Tame that applications with plugins and extensiones'
  • 'Handling events and assistant bots'
  • 'Exception handling, debugging and logging'
  • 'Managing and maintaining the code'
  • 'Deploying and maintaining the bot'
Todos los contenidos se encuentran muy ordenados aunque, eso sí, con una llamativa austeridad de palabras, sin el menor alarde o recreación literaria.

Un libro, no tanto para disfrutar, como para aprender, con un sentido muy, muy práctico y, eso si, absolutamente orientado a la herramienta UiPath.

Alok Mani Tripathi

(Fuente: Traducción y ligera elaboración propia de su ficha de autor en Amazon.)

Alok Mani Tripathi
Alok Mani Tripathi es el fundador de RPATech (www.rpatech.in), que es una compañía líder en servicios y consultoría extremo a extremo con foco en RPA e Inteligencia Artificial. Es un 'early adopter' de RPA y ha estado conectado con varios analistas y proveedores de herramientas RPA. Ha formado a más de 200 personas en diferentes plataformas RPA. Ha creado y dirigido múltiples Centros de Excelencia RPA para organizaciones globales con un claro foco en la automatización de la entrega de servicio. Ha sido desde hace tiempo un contribuidor a la comunidad RPA y mantiene un grupo en LinkedIn con mucho seguimiento.

Ficha técnica:

miércoles, 6 de junio de 2018

15 beneficios de Robotic Process Automation (RPA)


La automatización robótica de procesos (RPA) que definíamos en el post anterior, trae bajo el brazo promesas de eficiencia, rapidez y calidad. ¿Algo más?

Si, RPA puede aportar más, mucho más, según nos aseguran sus evangelistas.

En su libro 'Learning Robotic Process Automation', Alok Mani Tripathi identifica nada más y nada menos que quince beneficios de esta tecnología.

Son estos:

  • Servicios de mayor calidad y precisión, principalmente debido a la eliminación de errores humanos.

  • Analítica mejorada, dado que se registran los datos de todas las actividades.

  • Reducción de costes, fundamentalmente por la reducción de FTEs o su dedicación a tareas de mayor valor pero también por la supresión de errores y problemáticas derivadas.

  • Aumento de la velocidad, ya que los robots trabajan con mayor velocidad que los humanos.

  • Mayor cumplimiento normativo ('compliance'), por el seguimiento estricto de procedimientos, eliminación de errores y registro de todos los datos relevantes.

  • Agilidad, no sólo porque los robots son más rápidos que los humanos sino porque, además, se pueden desplegar en paralelo de forma muy sencilla los robots que se precisen en función de la carga de trabajo.

  • Análisis abarcadores, dado que los robots registran todos los datos necesarios para los posteriores análisis.

  • Versatilidad, ya que la aplicabilidad de los robots es transversal a sectores y mercados.

  • Simplicidad, ya que RPA no precisa habilidades previas de programación sino que el desarrollo es mayormente gráfico o por grabación de las actuaciones de las personas.

  • Escalabilidad, los robots se pueden aumentar o disminuir a voluntad mediante sencillas herramientas de administración.

  • Ahorros de tiempo, no sólo porque se realizan grandes cantidades de trabajo en menos tiempo sino además porque permiten una adaptación muy rápida a nuevos procesos.

  • No invasivo, ya que RPA trabaja fundamentalmente a nivel de interfaz de usuario por lo que no necesita de ningún cambio o interfaz en los sistemas con los que se relaciona.

  • Mejor gestión, ya que la gestión, despliegue y monitorización de los robots se realiza desde plataformas centralizadas.

  • Mejor servicio al cliente, puesto que los robots pueden trabajar 7x24x365, y liberan a los humanos para que éstos se focalicen en una mejor atención. La mayor calidad de los servicios también redunda en mayor satisfacción de los clientes.

  • Mayor satisfacción de empleados, ya que se libera a las personas de grandes cargas de trabajo repetitivo pudiéndose concentrar en tareas más creativas, valiosas y humanas.

¿Alguien da más?


lunes, 4 de junio de 2018

Una definición y un ámbito de aplicación para Robotic Process Automation (RPA)


La automatización robótica, Robotic Process Automation (RPA), es un dominio tecnológico al que estoy dedicando mucha atención en los últimos meses porque, por un lado, es una tendencia tecnológica y, sobre todo, de negocio, a la que conviene prestar atención y, por otra, porque es una tecnología muy importante en automatización de procesos de negocio, unos de los objetos de mi nueva firma, Reingeniería Digital.

Y para empezara hablar por primera vez en este blog sobre RPA, empiezo por una definición sencilla que propone Alok Mani Tripathi en su libro, 'Learning Robotic Process Automation'. Dice así:

Robotics Process Automation is a rapidly growing technology that helps enterprises automate processess by mimicking human action on computers, thereby delivering faster with consistent quality.

De esta definición conviene resaltar, por un lado, l que ya decíamos, que RPA es una tecnología para automatizar procesos de negocio y, por otra, y esto es importante para saber lo que es y no es RPA, que 'mimetiza' lo que hacen los humanos sobre ordenadores, es decir, que RPA asume que existen ya sistemas de información con los que interactuan personas y sustituye a las personas en la realización de esas tareas sobre los programas previamente existentes.

Por avanzar un poco más que la simple definición, veamos qué se responde el autor al hacerse dos preguntas, muy similares y complementarias. La primera es ¿qué debería automatizarse con RPA? Y la contestación es la siguiente:

  • Tareas repetitivas
  • Tareas que consumen mucho tiempo de personas
  • Tareas de alto riesgo
  • Tareas con unos bajos resultados de calidad
  • Tareas que involucran a muchas personas y muchos pasos

A continuación se pregunta ¿y qué puede realmente automatizarse con RPA?

  • Tareas bien definidas y basadas en reglas
  • Lógicas
  • La entrada para una tarea puede obtenerse de un sistema informático
  • Las entradas pueden descifrarse por sistemas software con la tecnología disponible
  • La salida de los sistemas es accesible
  • Los beneficios son mayores que los costes

De la contestación a esta segunda pregunta conviene pararse a destacar, de nuevo, dos cosas. 

Por un lado, que RPA se centra en la automatización de tareas muy bien definidas, lógicas y basadas en reglas. Es decir, a pesar de la aspiración y tendencia a introducir elementos cognitivos y de inteligencia artificial, en el estado actual RPA se centra en tareas muy mecánicas, de baja inteligencia. 

Por otro lado, los últimos puntos hacen referencia continua a la existencia de los sistemas con se interactua y que éstos deben proporcionar de una forma procesable los datos, las entradas y salidas, con que se trabaja. RPA trabaja mucho, por ejemplo, con formularios en pantalla o con ficheros de formatos claros como una hoja de cálculo o en formato PDF.

RPA es un área tecnológica que más que innovación tecnológica pura,lo que ofrece son unas grandes posibilidades de negocio para automatizar, eficientar, eliminar costes y ganar consistencia en los procesos de negocio. Es por ello un área de con una importante realidad y unas grandes posibilidades de futuro a corto.


viernes, 1 de junio de 2018

Los negocios de plataformas con Parker, Van Alstyne y Choudary

'Platform revolution' es, probablemente, el libro clave ahora mismo para entender el emergente modelo de negocio de plataformas que está cambiando completamente tantos y tantos sectores, un modelo en que un elemento intermedio (y en general de naturaleza tecnológica), la plataforma, pone en contacto a oferentes y demandantes que luego interaccionan entre ellos.


El libro se estructura en doce capítulos:

  • 'TODAY: Welcome to the platform revolution': explica qué es una plataforma, las compara con los negocios tradicionales (que denomina 'pipeline') y algunos de los cambios que introduce el modelo de plataformas.

  • 'NETWORK EFFECTS:The power of the platform': Estudia el efecto red, sus tipos, sus aspectos positivos y negativos, las economías de escala de la demanda y cómo escalar el efecto red mediante lo que denomina 'entrada sin rozamiento', es decir, hacer muy fácil a los actores sumarse a la plataforma.

  • 'ARCHITECTURE: Principles for designing a successful platform': identifica los tres elementos que intervienen en los intercambios en plataformas (información, bienes y servicios y alguna forma de moneda), los constituyentes de una interacción nuclear en la plataforma (participantes, unidad de valor y filtro) y con ese armazón conceptual estudia aspectos importantes del diseño de una plataforma como son la manera de facilitar el encaje entre oferta y demanda, cómo ir más allá de las interacciones básicas, la modularidad, etc

  • 'DISRUPTION: How platforms conquer and transform traditional industries': analiza por qué las plataformas disrumpen a los negocios tradicionales ('pipelines') focalizándose en algunos aspectos como la creación de valor, la consumición de valor y el control de calidad y otros aspectos estructurales como el desacoplamiento de los activos de su valor, la re-intermediación o la agregación de mercados. También repasa cómo pueden defenderse los negocios incumbentes.

  • 'LAUNCH: Chicken or egg? Eight ways to launch a successful platform': Analiza una paradoja a la que se enfrentan las plataformas en sus comienzos: dado que son mercados bilaterales y basados en efecto red ¿qué lado deberían impulsar primero, la oferta o la demanda? Tras explicar el problema se proponen ocho vías para gestionarlo.

  • 'MONETIZATION: Capturing value created by network effects': Donde se estudia cómo hacer dinero con las plataformas, justificando por qué no es evidente la respuesta y proponiendo varias formas de monetización posibles.

  • 'OPENNESS: Defining what platform users and partners can and cannot do': Estudia cómo, por qué y hasta qué punto, una plataforma debe ser abierta y lo hace desde el punto de vista de la participación de los gestores y espónsors, de los desarrolladores y de los usuarios.

  • 'GOVERNANCE: Policies to increase value and enhance growth': Aborda aspectos de gobierno y gestión, justificando primero la importancia del gobierno, y pasando revista a algunos aspectos como las leyes, normas, arquitecturas y mercados, proporcionando al final una serie de principios para el autogobierno de las plataformas.

  • 'METRICS: How platform managers can measure what really matters': explica las particularidades de los indicadores para plataformas y hace una serie de propuestas según las fases de desarrollo de la plataforma (startup, crecimiento y madurez) y proporciona algunos criterios para un diseño de métricas correcto.

  • 'STRATEGY: How platforms change competition': Tras pasar revista a algunos conceptos clásicos sobre estrategia, explica cómo la realidad de las plataformas cuestiona en parte algunos de esos modelos como el de las cinco fuerzas de Porter. A continuación, repasa algunas de las formas específicas en que los negocios de plataformas compiten

  • 'POLICIY: How platform should (an should not) be regulated': Repasa algunos aspectos oscuros de la revolución de las plataformas especialmente todo lo que tiene que ver con la regulación como acceso, compatibilidad, políticas de precios justas, privacidad, seguridad, control nacional, impuestos, etc.


  • 'TOMORROW: The future of platform revolution': Tras estudiar qué convierte a un sector en susceptible de ser disrumpido por las plataformas, analiza específicamente los casos de la educación, asistencia sanitaria, energía, finanzas, logística y transporte, servicios profesionales y administración pública para dedicar finalmente algunos párrafos a Internet de las Cosas.

'Platform revolution' es un grandísimo libro. No sólo el tema que analiza es interesante en sí mismo y muy candente, sino que el tratamiento que se le da es riguroso, abarcador y perfectamente comprensible. Un libro que considero ahora mismo imprescindible, no sólo para entender el mundo de las plataformas sino, en cierto sentido, para comprender todo el entorno del negocio digital.

Muy recomendable.

Geoffrey G. Parker

(Fuente: Traducción y ligera elaboración propia de la biografía en su Página oficial)

Geoffrey G. Parker
Profesor de ingeniería en la Thayer School del Dartmouth College donde también es director del Máster en Programa de Gestión de la Ingeniería. Antes de unirse a Darmouth, fue profesor de management en la Freeman School of Business en Tulane University así como director del Tulane Energy Institute. Imparte cursos acerca de estrategia de plataformas de negocio y analítica de datos.

Los veranos los pasa en Boston como profesor visitante y socio en la iniciativa del MIT por la Economía Digital donde también es co-presidente de la MIT Platform Summit anual y del BU Platform Research Symposium. Es miembro del GE Africa Learning Advisory Board cuyo objetivo es mejorar la formación de la fuerza laboral técnica en el continente africano. Imparte conferencias frecuentemente en actos académicos y eventos de la industria y asesora a líderes senior en el gobierno y la industria acerca de sus estrategias de plataformas.

Su investigación explora la economía y estrategia de mercados de plataformas y mercados bilaterales. También está interesado en la innovación distribuida. Algunos de sus proyectos de investigación han sido financiados por becas de la National Science Foundation (IIS-0338662, SES-0323227, SES-0925004), el Department of Energy (DE-FC26-08NT01922) y multitud de empresas incluyendo CISCO, Haier, International Post Corporation, Mass Mutual, Microsoft, PJM, SAP y Thomson Reuters. Es y ha sido panelista para la National Science Foundation, editor senior para la publicación Production and Operations Management, director asociado de la revista Management Science, editor asociado ad-hoc para el MIS Quarterly y editor especial para Information Systems Research.

Tiene un grado en ingenieria electrica y ciencias de la computación por la Princeton University, máster en ingeniería eléctrica dentro del Technology and Policy Program en el Massachusetts Institute of Technology (MIT) y un doctorado en Management Science por la MIT Sloan School of Management.

Puedes conocer más del autor visitando su página oficial o siguiéndole en Twitter donde se identifica como @g2parker.

Marshall W. Van Alstyne

(Fuente: Traducción y ligera elaboración propia de su ficha en Boston University - Quantrum School of Business)

Marshall Van Alstyne
Graduado por Yale en 1984, Máster en la MIT Sloan School en 1991 y doctorado también por la MIT Sloan en 1997.

El profesor Van Alstyne es uno de los expertos líderes en modelos de negocio en red. Investiga sobre economía de la información cubriendo materias como mercados de la comunicación, economía de las redes, propiedad intelectual, efectos sociales de la tecnología y efectos de la información sobre la productividad. Como uno de los desarrolladores del concepto de redes bilaterales, ha sido un contribuidor relevante a la teoría de los efectos de red, una serie de ideas que ya se enseñan en más de 50 escuelas de negocio a lo largo de todo el mundo.

Entre sus méritos se incluyen dos patentes, premios a su carrera y seis premios a mejor artículo. Sus artículos o comentarios han aparecido en Science, Nature, Management Science, Harvard Business Review, The New York Times y The Wall Street Journal.

Puedes conocer más del autor siguiéndole en Twitter donde se identifica como @InfoEcon.

Sangeet Paul Choudary

(Fuente: Traducción y ligera elaboración propia de su ficha en Pipes To Platforms)

Sangeet Paul CHoudary
Sangeet Paul Choudary es un asesor ejecutivo y escritor best-seller internacional. Es co-autor de 'Platform Revolution' y autor de 'Platform Scale'. Ha sido seleccionado como Young Global Leader por el World Economic Forum y está situado entre los 30 máximos pensadores globales en 2016 según Thinkers50 Radar, un ranking global de los principales pensadores de negocios. Su trabajo sobre plataformas ha sido seleccionado por Harvard Business Review como uno de las diez mejores ideas de gestión globales en el año 2016-17.

Sangeet es co-presidente de la MIT Platform Strategy Summit en los MIT Media Labs, emprendedor-residente en INSEAD Business School y educador ejecutivo en Harvard Business School Publishing. También es la persona más joven en haber sido incluido en Thinkers50 India como uno de los 50 mayores pensadores globales de origen indio. Es miembro del grupo de trabajo sobre plataformas y sistemas en el WEF’s Global Future Council y experto en el consejo asesor de la initiative on the Digital Transformation of Industries del World Economic Forum.

El trabajo de Sangeet ha sido clasificado como el artículo destacado de la edición de Abril de 2016 en Harvard Business Review y como el Business Report temático en la edición de Septiembre de 2015 en MIT Technology Review. Es citado y publicado frecuentemente en los principales revistas y medios incluyendo MIT Sloan Management Review.The Economist, The Wall Street Journal, WIRED Magazine, Forbes, Fortune y otros. Es un frecuente speaker y ha sido invitado a hablar en foros globales líderes incluyendo el evento del G20 en 2014, la World50 Summit, el Mobile World Congress, y eventos globales y regionales del World Economic Forum.

Para conocer saber más sobre el autor puedes seguirle en su blog o en Twitter donde está presente bajo el username @sanguit.

Ficha técnica: