As-is; To-Be; Gap

Este artculo corresponde en parte a discusiones tcnicas con mis colegas de Embotelladora
Andina y refleja mi opinin respecto a los modelos As-Is y To-Be ms el anlisis de GAP.
Primero es necesario tener en consideracin 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 Cmo actualizo funcionalmente mis sistemas?
Asunto que intentar responder a continuacin[1].
La necesidad de la actualizacin funcional se presenta cuando se est trabajando varios
aos con un mismo sistema, que se ha actualizado tcnicamente, 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 conclusin es: los sistemas requieren un
mejoramiento de mayor alcance o profundidad.
El plantearse este mejoramiento o puesta al da tiene varias implicancias:
Los sistemas en uso se implementaron con una tecnologa distinta a la hoy en boga,
entindase BPM. Es decir se disearon a partir del concepto funcional: rea
Organizativa / Mdulo de Software.
No existe mucha seguridad que la documentacin del sistema refleje la realidad
actual.
La actualizacin, con toda seguridad, ocupar la disciplina BPM y el concepto
Proceso de Negocios.
Lo ms probable es que la organizacin no est dispuesta a ejecutar un proyecto con
una estrategia Big Band, bsicamente por una cuestin de costos. Esto obliga a una
estrategia de implementacin 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 diseo funcional, se mapean directamente
uno es a uno con las rea organizacionales. Cuestin 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 poltico- no menor.
Si la empresa tiene filiales, plantas u operaciones en distintos lugares o pases lo
ms tpico 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 vlida para una empresa que opera un ERP con sistemas adicionales
como CRM, SCM y sistemas legados, todos estos sistemas con algn grado importante de
interconexiones. Es decir es para una empresa de tamao grande con una infraestructura
informtica compleja que justifica una estrategia como la que describir a continuacin.
Caractersticas
Esta estrategia corresponde a las de tipo Evolutivo por Proceso[1], cuyas
caractersticas principales son:
Fortalezas
Permite un enfoque en profundidad y sistemtico.
Cambio Organizacional suave.
Debilidades
Realizacin lenta de los beneficios.
Se generan cambios en los procesos debido al paso del tiempo.
Bsicamente 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 seale que la empresa re-
implementar sus sistemas informticos utilizando la disciplina BPM.
Un Mapa de los Procesos de Negocios oficial.
Un rea Informtica con personal capacitado en BPM y que conozca los procesos de
negocios de su empresa en profundidad (detalles operativos).
Una estructura metodolgica que incluya: la Enterprise Architecture, La estrategia
BPM (la que presento en este artculo), Gestin de Portafolio y Metodologa para la
Implementacin de Procesos de Negocios.
Un plan de Gestin 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 discusin[2], ya que existen opiniones a
favor y en contra respecto a si es necesario generar los modelos As-is, mi opinin 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 cmo efectivamente se ejecuta el proceso de
negocios. A menudo en las organizaciones grandes muchos ejecutivos y usuarios
claves no tienen la visin completa de cada uno de los pasos y detalles de la
operacin del proceso de negocios. La documentacin del As-Is ayuda a generar
claridad respecto a cmo se ejecutan las cosas y cules 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 crticos 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 documentacin del As-Is en un tiempo razonable es
necesario tener un mtodo preestablecido de trabajo y un estndar 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 accin tiene ms de una complicacin
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 regulacin (SoX, Basilea II)
o alguna certificacin el disponer de la documentacin de los procesos de negocios
actualizados es una obligacin.
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
organizacin.
To-Be
La generacin de los modelos To-Be es indispensable para establecer que se quiere de la
nueva implementacin, 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. cuestin que posibilita descubrir oportunidades de
mejoramiento.
Al tener los modelos To-Be y los As-Is es factible realizar un anlisis 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 generacin del modelo To-Be se pueden trabajar con los siguientes enfoques:
Utilizar Mejores Prcticas, que son modelos provistos, en general, por los
fabricantes del software o por alguna otra organizacin. La ventaja de su uso es
tiempo, costo y que son modelos probados en la prctica[3]
Variantes LLL (Legal, Language, Localization), modificaciones a una Mejor
Prctica originadas por un imperativo legal, una necesidad impuesta por el idioma o
por elementos fsicos no de idiosincrasia- de una locacin, por ejemplo la
disponibilidad de un determinado elemento.
Prcticas Propias, son modelos generados por la propia organizacin y que se
justifican, dado su alto costo de generacin, cuando el proceso o parte de el
subproceso- no est presente en una Mejor Prctica y/o cuando su implementacin
genera una ventaja competitiva muy significativa.

Anlisis de GAP
En simple es establecer cules 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 precisin cuales sern los
cambios a realizar, cmo y dnde se harn y, muy principalmente, cul ser el impacto que
tendrn
Resumiendo el Anlisis de GAP, debe establecer las brechas en:
Procesos y Subprocesos
Parametrizaciones
Desarrollos propios (existente y nuevos)
Datos
Roles
Responsabilidades
Documentacin
Performance
Gobernabilidad
Cada uno de los tpicos anteriores debe ser documentado y en conjunto constituirn en
Business Blue Print que define el GAP a implementar.
Referencias
[1] SAP Roadmap for BPM