As-is; To-Be; Gap

Este artículo corresponde en parte a discusiones técnicas con mis colegas de Embotelladora Andina y refleja mi opinión respecto a los modelos As-Is y To-Be más el análisis de GAP.

Primero es necesario tener en consideración que estas discusiones se originan por causa del transcurso del tiempo, al igual que uno los sistemas envejecen y requieren ser actualizados funcionalmente. Luego la pregunta es ¿Cómo actualizo funcionalmente mis sistemas? Asunto que intentaré responder a continuación[1].

La necesidad de la actualización funcional se presenta cuando se está trabajando varios años con un mismo sistema, que se ha actualizado técnicamente, se han instalado las nuevas versiones del software. Pero, no se usan extensivamente las nuevas funciones que incluye este nuevo software y, por otra parte el portafolio de proyectos se comienza a llenar de muchas iniciativas de “mejoramientos”. La conclusión es: los sistemas requieren un mejoramiento de mayor alcance o profundidad.

El plantearse este mejoramiento o puesta al día tiene varias implicancias:

  1. Los sistemas en uso se implementaron con una tecnología distinta a la hoy en boga, entiéndase BPM. Es decir se diseñaron a partir del concepto funcional: Área Organizativa / Módulo de Software.

  2. No existe mucha seguridad que la  documentación del sistema refleje la realidad actual.

  3. La actualización, con toda seguridad, ocupará la disciplina BPM y el concepto Proceso de Negocios.

  4. Lo más probable es que la organización no esté dispuesta a ejecutar un proyecto con una estrategia Big Band, básicamente por una cuestión de costos. Esto obliga a una estrategia de implementación que denomino “Cambiar la Rueda en Marcha”[2], es decir implementar los nuevos procesos de negocios mientras los sistema originales –antiguos-  siguen funcionando y, todo esto en un mismo landscape.

  5. Dado que los sistemas antiguos tienen un diseño funcional, se mapean directamente uno es a uno con las área organizacionales. Cuestión que no ocurre con los procesos de negocios,  que generan una estructura organizacional matricial, y esto provoca, sin lugar a dudas, un conflicto de poderes –político- no menor.

  6. Si la empresa tiene filiales, plantas u operaciones en distintos lugares o países lo más típico es que teniendo el mismo software, se tienen implementaciones distintas de acuerdo con los criterios de los gerentes.

Estrategia Cambio de Rueda en Marcha

Esta estrategia es válida para una empresa que opera un ERP con sistemas adicionales como CRM, SCM y sistemas legados, todos estos sistemas con algún grado importante de interconexiones. Es decir es para una empresa de tamaño grande con una infraestructura informática compleja que justifica una estrategia como la que describiré a continuación.

Características

Esta estrategia corresponde a las de tipo Evolutivo por Proceso[1], cuyas características  principales son:

Fortalezas

  1. Permite un enfoque en profundidad y sistemático.

  2. Cambio Organizacional suave.

Debilidades

  1. Realización lenta de los beneficios.

  2. Se generan cambios en los procesos debido al paso del tiempo.

Básicamente esta estrategia se aplica a un proceso de negocios End-To-End, por ejemplo: Order-to-Cash, Procure-to-Pay, etc.

Pre-Requisitos

Para que esta estrategia efectivamente pueda aplicarse exitosamente es necesario contar con:

  1. Una directriz del Directorio y la Gerencia General que señale que la empresa re-implementará sus sistemas informáticos utilizando la disciplina BPM.

  2. Un Mapa de los Procesos de Negocios oficial.

  3. Un área Informática con personal capacitado en BPM y que conozca los procesos de negocios de su empresa en profundidad (detalles operativos).

  4. Una estructura metodológica que incluya: la Enterprise Architecture, La estrategia BPM (la que presento en este artículo), Gestión de Portafolio y  Metodología para la Implementación de Procesos de Negocios.

  5. Un plan de Gestión de Cambio.

A mi juicio, lo que importa es contar con estos elementos independientemente del área organizativa que  los provee.

Modelo

Este modelo se aplica a un proceso de negocios End-To-End y su estructura general es:

Estrategia Cambio Rueda en Marcha


Etapa AS-IS

Este es uno de los aspectos que siempre está en discusión[2], ya que existen opiniones a favor y en contra respecto a si es necesario generar los modelos As-is, mi opinión es que es indispensable generar estos modelos debido a que:

  1. Ayuda a generar un alineamiento y entendimiento entre las distintas áreas y locaciones de la empresa en cuanto a cómo efectivamente se ejecuta el proceso de negocios. A menudo en las organizaciones grandes  muchos ejecutivos y usuarios claves no tienen la visión completa de cada uno de los pasos y detalles de la operación del proceso  de negocios. La documentación del As-Is ayuda a generar claridad respecto a cómo se ejecutan las cosas y cuáles son los desalineamientos.

  2. Ayuda a introducir los conceptos de BPM a los ejecutivos y a los usuarios claves, en particular en el uso de los diagramas de procesos de negocios (VAC, EPC, etc.)

  3. Permite establecer los puntos críticos y de mejoramiento del proceso.

  4. Afiata el equipo de trabajo del proyecto: Consultores, Usuarios Claves y Ejecutivos Claves.

Para el levantamiento del proceso As-Is es importante considerar:

  1. Que a fin de generar la documentación del As-Is en un tiempo razonable es necesario tener un método preestablecido de trabajo y un estándar para modelar.

  2. Se necesita de herramienta de software para modelar, ojalá una que maneje objetos como ARIS.

  3. Es indispensable, una vez generado el modelo As-Is, los gerentes involucrados en el proceso validen formalmente el modelo. Esta acción tiene más de una complicación debido a que a menudo el modelo levantado no corresponde a la imagen que tienen del mismo los ejecutivos.

  4. Por último, si su empresa necesita cumplir con alguna regulación (SoX, Basilea II) o alguna certificación el disponer de la documentación de los procesos de negocios actualizados es una obligación.

  5. La responsabilidad de generar y mantener actualizados los modelos As-Is de los procesos de negocios debe estar formalmente asignada a alguna unidad de la organización.

To-Be

La generación de los modelos To-Be es indispensable para establecer que se quiere de la nueva implementación, y ayuda a:

  1. Definir el nuevo modelo del proceso de negocios independientemente del software a utilizar. Esto permite pensar sin restricciones dadas por el software, por la costumbre, por el personal, etc. cuestión que posibilita descubrir oportunidades de mejoramiento.

  2. Al tener los modelos To-Be y los As-Is es factible realizar un análisis de GAP, que es fundamental para esta estrategia.

  3. El desarrollo del modelo To-Be permite establecer Indicadores de Performance –KPI que apoyaran el mejoramiento del negocio y el accountability.

  4. Posibilita realizar un efectivo alineamiento de los procesos de negocios con la estrategia corporativa.

Para la generación del modelo To-Be se pueden trabajar con los siguientes enfoques:

  1. Utilizar Mejores Prácticas, que son modelos provistos, en general, por los fabricantes del software o por alguna otra organización. La ventaja de su uso es tiempo, costo y que son modelos probados en la práctica[3]

  2. Variantes LLL (Legal, Language, Localization), modificaciones a una Mejor Práctica originadas por un imperativo legal, una necesidad impuesta por el idioma o por elementos físicos –no de idiosincrasia- de una locación, por ejemplo la disponibilidad de un determinado  elemento.

  3. Prácticas Propias, son modelos generados por la propia organización y que se justifican, dado su alto costo de generación, cuando el proceso o parte de el –subproceso- no está presente en una Mejor Práctica y/o cuando su implementación genera una ventaja competitiva muy significativa.

Análisis de GAP

En simple es establecer cuáles son los cambios necesarios de realizar al proceso actual  para actualizarlo al Nuevo modelo.

En esta estrategia es necesario volver a tener en cuenta que el “Cambio de Rueda es en Mrcha”, esto significa que los ajustes, modificaciones y adiciones se hacen en el landscape que está operando. Hecho que significa establecer con mucha precisión cuales serán los cambios a realizar, cómo y dónde se harán y, muy principalmente, cuál será el impacto que tendrán

Resumiendo el Análisis de GAP, debe establecer las brechas en:

  1. Procesos y Subprocesos

  2. Parametrizaciones

  3. Desarrollos propios (existente y nuevos)

  4. Datos

  5. Roles

  6. Responsabilidades

  7. Documentación

  8. Performance

  9. Gobernabilidad

Cada uno de los tópicos anteriores debe ser documentado y en conjunto constituirán en Business Blue Print que define el GAP a implementar.

Referencias

[1] SAP Roadmap for BPM

[2] http://it.toolbox.com/blogs/erp-roi/erp-business-process-improvement-asis-or-tobe-13208

[3] http://msaffirio.wordpress.com/2009/06/06/mejores-practicas-best-prectices-practicas-propias-own-practices/

[2] Expresión que la escuché a menudo de mi ex jefe Ricardo Majluf.

#BPM #BusinessProcess #Modelo #Proceso

©2020 by Sociedad Consultores Independientes SpA (SCIneu)

Av. Suecia 0142, Oficina 202, Providencia, Santiago, Chile Fono: (2) 2979 7042   info@scineu.com