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:

  • 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.
  • No existe mucha seguridad que la  documentación del sistema refleje la realidad actual.
  • La actualización, con toda seguridad, ocupará la disciplina BPM y el concepto Proceso de Negocios.
  • 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.
  • 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.
  • 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

  • Permite un enfoque en profundidad y sistemático.
  • Cambio Organizacional suave.

Debilidades

  • Realización lenta de los beneficios.
  • 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:

  • Una directriz del Directorio y la Gerencia General que señale que la empresa re-implementará sus sistemas informáticos utilizando la disciplina BPM.
  • Un Mapa de los Procesos de Negocios oficial.
  • Un área Informática con personal capacitado en BPM y que conozca los procesos de negocios de su empresa en profundidad (detalles operativos).
  • 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.
  • 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
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:

  • 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.
  • 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.)
  • Permite establecer los puntos críticos y de mejoramiento del proceso.
  • Afiata el equipo de trabajo del proyecto: Consultores, Usuarios Claves y Ejecutivos Claves.

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

  • 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.
  • Se necesita de herramienta de software para modelar, ojalá una que maneje objetos como ARIS.
  • 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.
  • 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.
  • 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:

  • 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.
  • Al tener los modelos To-Be y los As-Is es factible realizar un análisis de GAP, que es fundamental para esta estrategia.
  • El desarrollo del modelo To-Be permite establecer Indicadores de Performance –KPI que apoyaran el mejoramiento del negocio y el accountability.
  • 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:

  • 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]
  • 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.
  • 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:

  • Procesos y Subprocesos
  • Parametrizaciones
  • Desarrollos propios (existente y nuevos)
  • Datos
  • Roles
  • Responsabilidades
  • Documentación
  • Performance
  • 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] https://msaffirio.wordpress.com/2009/06/06/mejores-practicas-best-prectices-practicas-propias-own-practices/


[1] Todo este artículo tiene un trasfondo de tecnología SAP, pues es la que ocupa mi empleador: Embotelladora Andina.

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

12 thoughts on “As-is; To-Be; Gap

  1. Mario muy interesante tu artículo y concuerdo contigo, en que es estrictamente necesario, diagramar los procesos de negocios actuales como pre-requisito para un posterior Análisis de GAPs. En resumen una vez creados los modelos As-Is, la tarea siguiente tomando en cuenta que a donde queremos llegar, ya lo tenemos definido y diagramado. Comenzamos con el Análisis de GAP como parte del anteproyecto, dentro de las consideraciones que tenemos en cuenta, estan:
    – Gap de Función (Tarea o Actividad): Que se puede producir por la presencia o ausencia de alguna actividad que está propuesta en el To-Be. Este paso a mi entender es el mas facíl de realizar.
    – Gap de Implementación Sistémica: Me permite definir si alguna tarea manual realizada por los usuarios, puede ser automatizada.
    – Gap de Proceso : Me permite identificar una mejora en el proceso de negocio que no necesariamente, implique una implementación sino que puede ser solo, un cambio de proceder.
    _Gap de Roles o segregación de funciones: Implica un cambio de Rol o incorporación de mas personas en la ejecución de ciertas funciones, que en el As-Is solo es realizada por una persona. Es aqui donde la participación de la alta gerencia cobra una relevancia fundamental, los realizadores del levantamiento As-Is, creo, no poseen la capacidad de realizar cambios organizacionales fundamentales para llegar con exito al to-be. ¿Tu que opinas?
    Y una última consideración segun mi opinión.
    Es conveniente que la implementación o cambios de prácticas sean hechos a nivel de cadena de valor, la estandarización debe ser a nivel de EPC (motor de la cadena de valor), los cambios en los procesos de negocios siempre implican cambios en los Procedimientos y controles que estos procesos pueden tener.

    Saludos.

  2. Excelente artículo!
    Solo me queda una duda, la metodología planteada seguramente brinda muy buenos resultados, toda vez que implica una revisión crítica del actual proceso y un cierre de brechas entre el as-is y el to -be, ahora, una vez modificado los procesos y ajustados al to-be, ¿Cual seria la metodologia para asegurar una constante mejora y ajuste de esos proceso que aseguren que en un futuro no estaremos nuevamente determinando gaps? En resumen, ¿Como garantizamos que el tremendo esfuerzo e impulso que requirió el proyecto no se detenga, sino, por el contrario, continue en forma constante? Esto incluye incluso la revisión de la propia metodologia de mejora aplicada…
    Saludos!!!!

    1. Cecilia:

      Muchas gracias por tu comentario y tu pregunta es muy interesante ya que dá para pensar bastante. Honradamente este tema no lo tengo eleborado pero, como primer apronte partamos que los procesos por razones de negocios mutan permanentemente, en teoría estas mutaciones son las Ordenes de Mantenimiento o Mejoramiento (así las están llamdo ahora), por tanto si tenemo un control sobre los mejoramientos tal que junto con la implementación del mejoramiento actualizamos el modelo y su correspondiente documentación tendriamos el proceso bajo control.

      El otro punto, que lo estoy viendo aquí en EASA, es que si no tenemos capacitación permanente y auditorias de procedimientos las implementaciones se diluyen (literalmente).

      Me interes seguir analizando contigo este tema.

      Saludos cordiales,

      MSC

  3. Excelente articulo, pero me asalta una duda, la mejora del proceso, o como se llega a definir y a rediseñar el ToBe hasta ahora parece ser algo mágico, no he encontrado la piedra angular que nos permita estrategicamente enfocarnos en los puntos en que el proceso falla. ¿Podría ser una forma implementando el Process Mining (PM) que lo he estado escuchando bastante en el último tiempo y he intentado algunas iniciativas. En resumen el PM nos permite, a través de los LOG de las aplicaciones actuales, descubrir el proceso actual, incluso sin tener conocimiento del negocio, y hacer una comparativa de este con el modelo AsIs, además de poder analizar el rendimiento del mismo y los distintos usuarios que intervienen en el proceso (Conformance Checker, Performance Checker, Social Analisis). Tal vez utilizando esta metodoligía podríamos defender mejor las mejoras planteadas en el diseño del ToBe

    Espero sus comentarios

  4. Hola, muy interesante el artículo, es bueno conocer la opinión de personas con experiencia en el tema. Lo que me queda duda es como documentas estos procesos As-Is y To-Be, me pregunto si tendrás algunas plantillas o ejemplos me serían de mucha utlidad. Gracias de antemano

    1. David:

      Para el levantamiento de los as-is y para el diseño de los to-be utilizo diagramas EPC y la herramienta ARIS, Y por medio de la comparación de ambos diagramas, planilla Excel, establezco los Gap.

      Atentamente,

      M. Saffirio C.

  5. Es muy interesante el artículo y es claramente aplicable.
    Para generar los modelos As-Is y To-Be yo uso eEPC y a veces BPMN, pero los modelos eEPC pueden aportar mayor información como sistemas de información y soporte de éstos, asociados al organigrama y roles.
    Primero uno debiese analizar el proceso de negocio específico, documentarlo y generar su “Ficha del Proceso”, identificando la cadena de valor, los procesos y subprocesos involucrados, árbol de funciones – MUY importante – . Se pueden usar herramientas o metodologías como Six Sigma para caracterizar correctamente el proceso: SIPOC y matriz RACI, por ejemplo. Se podría usar un análisis de madurez del proceso con Hammer.

    Ahora bien, cómo saber cuál es el To-Be??? Una buena forma es usar un Marco de Referencia, como lo son las ISO o SCOR (para cadenas de suministro). Estos marcos referenciales dan guías de que se debería tener y uno así puede realizar la comparación entre el As-Is y lo “ideal” (ojo que lo ideal o perfecto es enemigo de lo bueno, debe ser “lo mejor” para la empresa, sin necesariamente ser todo o lo ideal). Una vez que se tienen los lineamientos generales se pueden empezar a trabajar las brechas, analizando el tamaño de éstas, si está presente o no una actividad, factibilidad técnica, costo, entre otros aspectos. Idealmente, priorizar aquellos ámbitos más relevantes para la empresa o que tengan más impacto en el cumplimiento de los Kpi.

    En el levantamiento del proceso y en la generación del As-Is, ya se pueden identificar instancias de mejora, como por ejemplo, estandarizar las reglas de decisión (que no sean tan dependientes del individuo – Know How como le denomina ARIS), que no estén claros los clientes, proveedores, productos e inputs del proceso o que se reflejen problemas de Gobernabilidad como ausencia de responsables de ciertas actividades, por ejemplo.

    Saludos.

  6. Reblogueó esto en El Blog de David Rengifoy comentado:
    La estrategia As-Is; To-Be; Gap no es exclusiva para un proyecto de actualización. Inclusive cuando se trata de construir un software completamente nuevo y sin antecedentes en la empresa. El manejo de este modelo resulta sumamente valioso ya que nos permite conocer la manera en la cual, en tiempo presente, se resuelven las necesidades que se presume serán cubiertos con el nuevo software.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s