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

TU VOTO:

5 Votes
SHARE THIS:

 Correo electrónico
 Imprimir


4/07/09BPM, Business Process, Modelo, Proceso

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

1. Pedro Contreras Jara dice:

1/10/09 en 4:07 pm

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.

Responder
 1. msaffirio dice:

5/10/09 en 2:05 pm

Pedro:

Muchas gracias por tus comentarios, que ayudan a fundamentar el artículo.

Saludos,

MSC

Responder

2. Cecilia Abati dice:

16/10/09 en 11:02 pm

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

Responder
 1. msaffirio dice:

21/10/09 en 8:15 pm

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

Responder

3. Jolave dice:

18/05/10 en 10:29 pm
 Estimado: por el lado tecnologico la respuesta de como implementar BPM(s) a la
problematica de los sitemas legacy y los nuevos en base a procesos de negocios,
se llama SOA (http://es.wikipedia.org/wiki/Arquitectura_orientada_a_servicios)

Responder

1. msaffiriobb dice:

21/05/10 en 10:01 am

Gracias no me había dado cuenta.

Responder

4. Sergio Hume dice:

28/04/11 en 3:35 pm

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

 Responder

5. David dice:

4/03/12 en 12:42 am

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

Responder

1. msaffirio dice:

4/03/12 en 11:39 am

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.

Responder
6. Paulo Villarroel dice:

9/08/12 en 12:56 pm

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.

Responder
7. Pingback: BPM | Business World TI

8. davidrengifo dice:

4/04/14 en 5:48 pm
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