Buscar:

Go

Mario Saffirio
Tecnologas de Informacin y Gestin de Procesos de Negocios (BPM)

Acerca de
Objetivo
Publicado

As-is; To-Be; Gap

4/07/09 10 comentarios
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 reimplementar 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
[2] http://it.toolbox.com/blogs/erp-roi/erp-business-process-improvement-asis-or-tobe13208
[3] http://msaffirio.wordpress.com/2009/06/06/mejores-practicas-best-precticespracticas-propias-own-practices/

[1] Todo este artculo tiene un trasfondo de tecnologa SAP, pues es la que ocupa mi
empleador: Embotelladora Andina.
[2] Expresin que la escuch a menudo de mi ex jefe Ricardo Majluf.

Tu voto:

2 Votes

Share this:

Correo electrnico
Imprimir

Me gusta:
Me gusta
Be the first to like this.

Tagged: BPM, Business Process, Modelo, Proceso

10 Responses to As-is; To-Be; Gap

Pedro Contreras Jara dice:

1/10/09 a las 4:07 pm
Mario muy interesante tu artculo y concuerdo contigo, en que es estrictamente
necesario, diagramar los procesos de negocios actuales como pre-requisito para
un posterior Anlisis 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 Anlisis de GAP como parte del
anteproyecto, dentro de las consideraciones que tenemos en cuenta, estan:
- Gap de Funcin (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 facl de realizar.
- Gap de Implementacin Sistmica: 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 implementacin sino que puede ser solo,
un cambio de proceder.
_Gap de Roles o segregacin de funciones: Implica un cambio de Rol o
incorporacin de mas personas en la ejecucin de ciertas funciones, que en el
As-Is solo es realizada por una persona. Es aqui donde la participacin 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 consideracin segun mi opinin.
Es conveniente que la implementacin o cambios de prcticas sean hechos a
nivel de cadena de valor, la estandarizacin 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
o

msaffirio dice:
5/10/09 a las 2:05 pm
Pedro:
Muchas gracias por tus comentarios, que ayudan a fundamentar el
artculo.
Saludos,

MSC
Responder

Cecilia Abati dice:

16/10/09 a las 11:02 pm
Excelente artculo!
Solo me queda una duda, la metodologa planteada seguramente brinda muy
buenos resultados, toda vez que implica una revisin crtica 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 revisin de
la propia metodologia de mejora aplicada
Saludos!!!!
Responder
o

msaffirio dice:
21/10/09 a las 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 teora estas mutaciones
son las Ordenes de Mantenimiento o Mejoramiento (as las estn llamdo
ahora), por tanto si tenemo un control sobre los mejoramientos tal que
junto con la implementacin del mejoramiento actualizamos el modelo y
su correspondiente documentacin tendriamos el proceso bajo control.
El otro punto, que lo estoy viendo aqu en EASA, es que si no tenemos
capacitacin permanente y auditorias de procedimientos las
implementaciones se diluyen (literalmente).
Me interes seguir analizando contigo este tema.
Saludos cordiales,
MSC
Responder

Jolave dice:
18/05/10 a las 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
o

msaffiriobb dice:
21/05/10 a las 10:01 am
Gracias no me haba dado cuenta.
Responder

Sergio Hume dice:

28/04/11 a las 3:35 pm
Excelente articulo, pero me asalta una duda, la mejora del proceso, o como se
llega a definir y a redisear el ToBe hasta ahora parece ser algo mgico, no he
encontrado la piedra angular que nos permita estrategicamente enfocarnos en los
puntos en que el proceso falla. Podra 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 travs 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,
adems 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 metodoliga podramos defender mejor las
mejoras planteadas en el diseo del ToBe
Espero sus comentarios
Responder

David dice:
4/03/12 a las 12:42 am
Hola, muy interesante el artculo, es bueno conocer la opinin 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 tendrs algunas plantillas o ejemplos me

seran de mucha utlidad. Gracias de antemano
Responder
o

msaffirio dice:
4/03/12 a las 11:39 am
David:
Para el levantamiento de los as-is y para el diseo de los to-be utilizo
diagramas EPC y la herramienta ARIS, Y por medio de la comparacin
de ambos diagramas, planilla Excel, establezco los Gap.
Atentamente,
M. Saffirio C.
Responder

Paulo Villarroel dice:

9/08/12 a las 12:56 pm
Es muy interesante el artculo 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 informacin como sistemas de
informacin y soporte de stos, asociados al organigrama y roles.
Primero uno debiese analizar el proceso de negocio especfico, 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 metodologas como Six Sigma para caracterizar
correctamente el proceso: SIPOC y matriz RACI, por ejemplo. Se podra usar un
anlisis de madurez del proceso con Hammer.
Ahora bien, cmo saber cul 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 guas de que se debera tener y uno as puede realizar la
comparacin 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 tamao de stas, si est presente o no una
actividad, factibilidad tcnica, costo, entre otros aspectos. Idealmente, priorizar
aquellos mbitos ms relevantes para la empresa o que tengan ms impacto en el
cumplimiento de los Kpi.

En el levantamiento del proceso y en la generacin del As-Is, ya se pueden

identificar instancias de mejora, como por ejemplo, estandarizar las reglas de
decisin (que no sean tan dependientes del individuo Know How como le
denomina ARIS), que no estn 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

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesin:

(requerido)(La direccin no se har
pblica)(requerido)(

Log Out / Cambiar )( Log Out / Cambiar )( Log Out / Cam

biar )
El Anteproyecto de una Implementacin BPM
Mejores Prcticas Best Prectices / Prcticas Propias Own Practices

Qu es esto?
You are currently reading As-is; To-Be; Gap at Mario Saffirio.

meta

Autor: msaffirio
Comentarios: 10 comentarios
Categoras: BPM, Gestin, Informtica, Proceso, SAP

Blog de WordPress.com.
Tema: Oulipo por A. Mignolo.
<div style="display: none;"><img src="//pixel.quantserve.com/pixel/p-18mFEk4J448M.gif?labels=%2Clanguage.es%2Ctype.wpcom%2Cposttag.bpm%2Cpostta
g.business-process%2Cposttag.modelo%2Cposttag.proceso%2Cas" height="1"
width="1" alt="" /></div>
Seguir

Follow Mario Saffirio

Get every new post delivered to your Inbox.

nete a otros 61 seguidores

Sign me up

Ofrecido por WordPress.com

<p class="robots-nocontent"><img
src="http://b.scorecardresearch.com/p?cj=1c1=2&#038;c2=7518284" alt=""
style="display:none" width="1" height="1" /></p> <img
src="http://stats.wordpress.com/b.gif?v=noscript"
style="height:0px;width:0px;overflow:hidden" alt="" />