Contenido

Introduccin
Paso 1 Elegir un lugar para comenzar
El cliente monolito
El Platform Play
Ambos necesitan un lugar para comenzar
La metodologa SIR
xito
Impacto
Repetibilidad
Paso 2 Hacer un mapa para el xito
Documento inicial y plan de trabajo (SOW)
Paso 3 Crear los equipos
Paso 4 Disear el primer proceso
Paso 4 Disear el modelo de datos y los formularios
Paso 4 Disear las interconexiones
Paso 4 Elementos adicionales
Construir procesos ajustados al BPMN 2.0 con ProcessMaker

2016 Brian S. Reale

Introduccin

Los proyectos de software empresarial tienen la reputacin de quedarse sin

presupuesto o sin tiempo y terminan fracasando. De hecho, de acuerdo con

una estadstica de Gartner, ms del 50% de todos los proyectos de software

BPM no consiguen ofrecer los resultados esperados. Con estadsticas como

estas, Los implementadores del proyecto realmente necesitan buscar cualquier ventaja posible para realizar un mejor trabajo garantizando xito al mo-

mento de implementar el software. En este eBook en particular exploraremos

una serie de recomendaciones y de hallazgos clave para ayudarle a tener
xito en su prxima implementacin del software BPM.

2016 Brian S. Reale

Paso 1 Elegir un lugar para comenzar

Suena obvio decir que tiene que elegir un lugar para comenzar. Sin embargo,
esto no es tan fcil como suena y hay ms secretos en este paso de lo que
parece a simple vista.

En realidad hay dos tipos de clientes que tienden a implementar un software

BPM.

El cliente monolito

El cliente Platform Play

2016 Brian S. Reale

El cliente monolito

El monolito
Algunos clientes tienen un proceso central, singular y fcil de identificar que

les gusta automatizar. Este proceso es por lo general un pilar estratgico de

su negocio. Usamos el trmino monolito para describir a este tipo de cliente.

Este tipo de compaa no tiene dificultades al momento de elegir el proceso

para automatizar, al conseguir soporte interno para el proyecto, o al configurar los KPIs para definir el xito. En este caso, la decisin ms difcil al

comienzo del proyecto es por lo general si una solucin comercial existente

(COTS) de BPMS es la tecnologa correcta para utilizar, o si la compaa

debera construir un software personalizado para automatizar sus procesos.

2016 Brian S. Reale

Desarrollar flujos de trabajo es el proceso de

recopilar toda la informacin relevante que entra en
el proceso: quin est involucrado, cules son sus
responsabilidades, cmo se transfieren las
tareas, cules tareas son manuales y cules son
automticas.

2016 Brian S. Reale

El Platform Play

El Platform Play
Para el segundo tipo de cliente, la pregunta es un poco ms difcil. A este tipo
de cliente lo llamamos Platform Play. A diferencia de los clientes monolito, el

Platform Play tiende a tener muchos procesos para automatizar. Este tipo de

organizacin tiende a llegar a la conclusin de que requiere del software BPM

de una forma ms gradual y sin la claridad precisa experimentada por los

clientes monolito. En muchos casos estas compaias tienen algunos pro-

cesos en papel, otras los hacen mediante una combinacin complicada de

Excel y email, y otras pueden incluso ya estar automatizadas con un cdigo

personalizado. Por lo general, los procesos se dispersan por toda la organi-

zacin y el dolor se siente en diferentes departamentos y con diferentes niveles de urgencia. Este tipo de cliente a menudo hablar de silos de informacin al momento de describir los problemas de la organizacin.

2016 Brian S. Reale

Ambos necesitan un lugar para comenzar

Aunque hay diferencias significativas entre los clientes monolito y platform

play, tambin hay una similitud. Ambos necesitan identificar el lugar para
comenzar. Los clientes platform play necesitan identificar un proceso de

muchos para automatizarlo primero. Finalmente, una vez que un equipo en el

platform play tenga un mayor dominio en su tecnologa BPMS de eleccin

podr entonces comenzar a automatizar mltiples procesos al mismo tiempo.

Los clientes monolito tienen una ruta mucho ms clara para la automatizacin
del primer proceso. Sin embargo, an deben hacer frente a algunos desafos

al decidir donde comenzar su automatizacin. Un proceso complejo no puede

y no debe abordarse todo al mismo tiempo. Es una mejor idea tener un acer-

camiento ms gil e iterativo para la implementacin y automatizacin incluso

de un solo proceso.

2016 Brian S. Reale

La metodologa SIR
En ProcessMaker para analizar el punto de partida de su proyecto BPMS,

hemos desarrollado una metodologa que llamamos SIR. SIR es un acrnimo

de:

Success (xito)

2016 Brian S. Reale

Impact (Impacto)

Repeat (Repeticion)

xito

La primera pregunta que su organizacin debera hacerse es, Podemos

tener xito automatizando este proceso?

Puede que tenga un problema que ciertamente vale la pena resolver, pero si

el xito no es posible, entonces intentar automatizar este proceso de primero

le garantizar un fracaso en todo su proyecto BPM. Hay un numero de

razones por las que un proceso puede ser difcil de resolver. Sin embargo,

estas razones casi siempre se reducen a una falta de recursos tcnicos, al

tiempo, o al apoyo poltico.

2016 Brian S. Reale

Impacto

Entonces hemos encontrado un proceso que creemos puede ser exitoso al

momento de automatizarlo. Ahora debemos preguntar, Le importar a alguien si tenemos xito? Este proceso afecta lo suficiente a la organizacin

para ser importante? Est alineado con una iniciativa estratgica de importancia en la organizacin?

Hay un balance delicado al encontrar un proceso inicial que sea alcanzable y

que tenga un impacto positivo y significativo en la organizacin. El fracaso

por irrelevancia es casi tan malo como el fracaso por una implementacin no
exitosa. Es casi seguro que ambos tipos de fracaso evaporarn el capital
social y con esto el proyecto llegar a su fin.

Al momento de intentar determinar el impacto, tambin recomendamos

mapear su iniciativa de proceso y cada proceso frente a los objetivos centrales de su negocio (KBOs).

2016 Brian S. Reale

Repetibilidad

Por ltimo, queremos hacer la pregunta, Es este proceso algo que ser

repetible? En otra palabras, si ha identificado numerosos procesos para automatizar, su punto de partida tiene suficiente en comn con los otros pro-

cesos para que pueda ser til en sus prximos proyectos? Estar creando
componentes que podr reutilizar? Repetibilidad significa que podr ganar

apalancamiento para otros procesos en progreso. Esto es muy importante.

Los interesads internos y externos esperarn que sus esfuerzos en el desar-

rollo del proceso comiencen a acelerarse despus de los primeros procesos,

mostrando que la curva de aprendizaje se reducir a medida que avanza.

Algunas de las mejoras tendrn lugar sin ninguna planeacin o esfuerzo adi-

cional. Por ejemplo, cuando implemente su primer proceso necesitar considerar cosas como la instalacin e implementacin de la autenticacin y el

modelo de seguridad (probablemente involucre un Active Directory o algn

tipo de LDAP). Para los siguientes procesos, esta integracin ya estar lista.

2016 Brian S. Reale

Paso 2: Hacer un mapa para el xito

Una vez se haya identificado el problema y la solucin correspondiente a

implementar, es fundamental mapear cmo lucir el xito una vez se automatice el proceso.

Defina cmo se ver todo una vez se automatice el proceso incluyendo lo

siguiente:

Cul es el proceso exacto a implementarse?

Qu informes se necesitarn para controlar el proceso?

Qu hardware, software, y perifricos se incluirn en el proceso?

Qu integraciones se incluirn en el proceso?
Qu mejoras podemos esperar?
Volumen
Tiempo

ndices de defectos

ndices de satisfaccin

Cunto tiempo tomar automatizar el proceso y cuntas iteraciones se

necesitarn para concretarlo?

Todas estas preguntas deben ser muy especficas. Es importante no hablar

sobre cmo lucir el xito en trminos imprecisos. El xito debe basarse en

objetivos muy claros y especficos.

2016 Brian S. Reale

Documento inicial y plan de trabajo (SOW)

En ProcessMaker definimos estos puntos en un documento inicial mientras

que el resto se describe detalladamente en el plan de trabajo (SOW). El documento inicial es donde en realidad se describen las expectativas y limita-

ciones de lo que se har. El documento inicial es el primer documento que se

codesarrolla con el cliente. Este documento es firmado por nuestro equipo y
por el equipo del cliente. Siempre insistimos en que todos los interesados
lean y firmen este documento.

2016 Brian S. Reale

Paso 3: Crear los equipos

Es importante que el cliente entienda desde el comienzo que el proyecto no

podr y no ser exitoso sin la participacin de su equipo. Asimismo, esta participacin casi nunca proviene de una sola persona. En cambio, el cliente

necesitar involucrar muchas personas en su organizacin desde el comienzo. Como mnimo el equipo del cliente debe involucrase en los siguientes
roles:

Patrocinador ejecutivo - Esta persona debe ser un ejecutivo dentro de la

organizacin (idealmente un de nivel C) cuyos objetivos centrales del negocio

estn alineados con el proyecto. Responsable del proceso - Este ser el rol

ms activo en el proyecto y debe tener un excelente conocimiento global del

proceso. Representante de TI - Es necesaria la presencia de un participante
en la tecnologa de la informacin que sea capaz de dirigir las interconex-

iones hacia los sistemas externos adems de entender los modelos de autenticacin y de seguridad que utilizarn.

Usuario final Por supuesto, tambin necesitamos la participacin de los

usuarios finales.

2016 Brian S. Reale

Paso 4: Disear el primer proceso

Bien, ahora estamos listos para comenzar a disear el proceso. Cada

paquete BPM implementar esta parte de una forma ligeramente diferente.

Por ejemplo, en algunos paquetes necesitar crear un modelo de datos antes

de crear formatos de entrada para los usuarios mientras que otros hacen esto
automticamente para el usuario en un segundo plano. No obstante, los
siguientes pasos se siguen generalmente en todos los paquetes:

Diseador BPMN - No he conocido a nadie a quien no le guste la idea de

arrastrar y soltar iconos en una pgina web mientras ve como su proceso

empresarial se materializa justo frente a sus ojos. Los diseadores de pro-

cesos para arrastrar y soltar son notablemente muy fciles de usar. Algunos

diseadores ofrecen un mejor soporte estndar para el BPMN 2.0 que otros.
Debe decidir que tan importante es esto para su proyecto.

2016 Brian S. Reale

Paso 4: Disear el modelo de datos y los formularios

Modelo de datos: Qu datos necesita recoger su proceso? Esta es la siguiente pregunta que debe hacerse cuando empiece a modelar en el software

BPM. En este caso necesitamos pensar en cmo lucirn nuestros formatos,

qu datos adicionales pueden ser necesarios para recoger desde otros sistemas, y qu documentos se agregarn o crearn durante el proceso.

2016 Brian S. Reale

Paso 4: Disear las interconexiones

Interconexiones: Cuando estamos creando modelos de datos para el siste-

ma, es muy probable que encuentre datos que estn alojados en otros sistemas. O puede que se de cuenta que su proceso capturar datos que le gustara alojar en otros sistemas. Esta es a menudo la parte ms tcnica del

diseo del proceso. Estas conexiones a otros sistemas le harn decidir con

su equipo TI cmo acceder a los otros sistemas. Ser mediante un servicio

web REST o SOAP? Se conectar directamente a una base de datos? Importar o exportar una hoja de datos de Excel?

2016 Brian S. Reale

Paso 4: Elementos adicionales

Interfaces La mayora de los paquetes BPM tienen un portal estndar para

que los usuarios puedan acceder a los datos y tareas asignadas. Sin embar-

go, muchos proyectos BPM requieren interfaces muy personalizadas. Cmo

esperan interactuar sus clientes con el sistema? Utilizarn interfaces web y

mviles estndar? O Necesitan que estas interfaces estn incorporadas en

otro software como un software de correo para clientes (Outlook o Gmail) o

con su CMS favorito (Drupal u otro), o necesita ser parte de una infraestructura en quiosco?

2016 Brian S. Reale

Step 4: Designing Interfaces

Interfaces Most BPM Suites have a standard portal for users to use to

access assigned tasks and data. However, many BPM projects require very
custom interfaces. How do your customers expect to interact with the

system? Will they use standard web and mobile interfaces? Or do they need
these interfaces embedded in another software such as email client software
(Outlook or Gmail) or their favorite CMS (Drupal or other), or does it need to
be part of a kiosk infrastructure?

2016 Brian S. Reale

A
forempresarios
Business
UnCommon
lenguajeLanguage
comn para
and
Technical Workers
y trabajadores
tcnicos
Funcionalidad personalizada - Tal como las interfaces personalizadas men-

cionadas arriba, la mayora de los proyectos grandes de BPM tendrn requisitos personalizados. A pesar de lo que le digan los proveedores de BPM,

estos requisitos necesitarn una programacin personalizada. Esa es la realidad del asunto. Preprese para ello. Asegrese de saber lo que general-

mente se ajusta dentro de un paquete BPM as como qu otras partes personalizadas de un sistema necesita para su proyecto

2016 Brian S. Reale

A Common Language for Business

and Technical Workers
Custom Functionality- Just like the custom interfaces mentioned above,

most large BPM projects will have custom requirements. Despite what BPM
vendors will tell you, these requirements will require custom programming.
That is simply the nature of the beast. Be prepared for it. Make sure you

know what generally fits inside a BPM suite and what other custom parts of a
system you require for your project.

2016 Brian S. Reale

Paso 5: Implementacin gil

Bien. Ahora todo ha sido diseado. Ya tiene su punto de partida para el xito.
Djeme hacer nfasis de nuevo NECESITA UN PUNTO DE PARTIDA. No
omita los pasos de arriba para comenzar a implementar. Si tiene ganas de

hacer esto no ser el nico. Los paquetes BPM parecen muy sencillos, y lo
son en la mayora de sus partes. Sin embargo, el diseo del proceso y la

implementacin del proyecto nunca son simples. Sus interesados tendrn

opiniones e ideas inconstantes. Si no concreta todo esto, automatizar un

proceso con el que sus interesados no estarn de acuerdo y al final no lo
utilizarn.

No obstante, una vez tenga un punto de partida a la mano, estar listo para

comenzar a trabajar. En ProcessMaker, generalmente trabajamos en equipos

de 4-6 miembros por proyecto. Creemos que esto nos da la combinacin

correcta de agilidad, redundancia (las personas podran abandonar a mitad

de los proyectos) y continuidad.

2016 Brian S. Reale

Paso 5: Implementacin gil

A pesar de todos nuestros mejores esfuerzos para construir un punto de partida perfecto, es muy difcil asegurar que todo los interesados estn en perfecta sincrona. Esta es otra razn por la que es muy difcil estimar todo un

proyecto con una precisin perfecta. Tambin es otra razn por la que la mayora estar de acuerdo en que es mejor desarrollar el proceso usando metodologas agiles. En ProcessMaker, nuestros ciclos de trabajo se basan en

sprints de 2 semanas. En cada sprint nuestro objetivo es producir versiones

iteradas del producto final siempre que sea posible. Estos sprints de 2 semanas le dan tanto a nuestro equipo como al equipo del cliente la oportunidad

de reaccionar y contribuir en lo que se est realizando. Se vuelve mucho ms

fcil detectar cuales ideas iniciales fueron errneas o necesitan cambiarse. El

cliente se acerca mucho ms al proceso de desarrollo de esta manera, lo cual

dificulta bastante que disientan las interpretaciones entre el interesado y el
diseador/desarrollador.

2016 Brian S. Reale

Paso 5: Implementacin gil

Esto reduce el riesgo porque los problemas pueden corregirse antes de invertir mucho tiempo y se pueden cambiar ms rpido.

La experiencia del usuario puede considerarse para ayudar a encontrar me-

jores soluciones para los usuarios que se introduzcan despus en el proceso.

Podr capacitar usuarios finales de forma modular y luego podr utilizar estos
usuarios tempranos como entrenadores o personas de apoyo.

Podr manejar ms fcilmente la aversin natural al cambio que existe en

todas las organizaciones mediante la implementacin de un cambio en una

forma ms modular.

2016 Brian S. Reale

Conclusin
Hay un viejo dicho que dice que los proyectos nunca fallan debido a un mal
software; sino que fallan debido a una mala comunicacin en el proyecto.

Esto es absolutamente cierto. Irnicamente, la empresas pasan la mayora de

su tiempo evaluando las funciones del producto al momento de decidir que
software BPM comprar. ste es un error comn. Evaluar los equipos del

proyecto y analizar la adecuacin a la cultura entre empresas para un nuevo

proyecto no es tan fcil de hacer como comenzar a hacer una lista de fun-

ciones y una comparacin de precios al momento de seleccionar un producto.

Cierto, este anlisis es necesario. Pero nosotros creemos que si las com-

paas pasan ms tiempo analizando y organizando los equipos de imple-

mentacin, entendiendo su estrategia y filosofa de implementacin, y asegurndose de que la cultura empresarial se ajuste; el riesgo de la imple-

mentacin podr reducirse ampliamente. Incluso si el proveedor de software

BPM y el socio de implementacin son compaas diferentes, aplican las

mismas realidades. Preocpese por cual producto elegir, pero preste igual o
mayor atencin analizando quien har la implementacin y cmo planea
hacerlo.

2016 Brian S. Reale

Si le gustara aprender ms acerca de cmo

implementar proyectos BPM exitosos o sobre
cmo se implementan los proyectos de
ProcessMaker usando esta metodologa, por favor
sintase libre de contactarnos al 617-340-3377, o
envenos un email a info@processmaker.com.

Contact us

2016 Brian S. Reale