Contenido

Introducción
Paso 1 – Elegir un lugar para comenzar
El cliente monolito
El Platform Play
Ambos necesitan un lugar para comenzar
La metodología 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 – Diseñar el primer proceso
Paso 4 – Diseñar el modelo de datos y los formularios
Paso 4 – Diseñar las interconexiones
Paso 4 – Elementos adicionales
Construir procesos ajustados al BPMN 2.0 con ProcessMaker

© 2016 Brian S. Reale

Introducción

Los proyectos de software empresarial tienen la reputación de quedarse sin

presupuesto o sin tiempo y terminan fracasando. De hecho, de acuerdo con
una estadística de Gartner, más del 50% de todos los proyectos de software
BPM no consiguen ofrecer los resultados esperados. Con estadísticas como
estas, Los implementadores del proyecto realmente necesitan buscar cualqui-
er 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 próxima implementación 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 fácil como suena y hay más 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 fácil de identificar que

les gusta automatizar. Este proceso es por lo general un pilar estratégico de
su negocio. Usamos el término monolito para describir a este tipo de cliente.
Este tipo de compañía no tiene dificultades al momento de elegir el proceso
para automatizar, al conseguir soporte interno para el proyecto, o al configu-
rar los KPIs para definir el éxito. En este caso, la decisión más difícil al
comienzo del proyecto es por lo general si una solución comercial existente
(COTS) de BPMS es la tecnología correcta para utilizar, o si la compañía
debería construir un software personalizado para automatizar sus procesos.
 

© 2016 Brian S. Reale

Desarrollar flujos de trabajo es el proceso de
recopilar toda la información relevante que entra en
el proceso: quién está involucrado, cuáles son sus
responsabilidades, cómo se transfieren las
tareas, cuáles tareas son manuales y cuáles son
automáticas.

© 2016 Brian S. Reale

El Platform Play

El Platform Play

Para el segundo tipo de cliente, la pregunta es un poco más difícil. 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
organización tiende a llegar a la conclusión de que requiere del software BPM
de una forma más gradual y sin la claridad precisa experimentada por los
clientes monolito. En muchos casos estas compañias tienen algunos pro-
cesos en papel, otras los hacen mediante una combinación complicada de
Excel y email, y otras pueden incluso ya estar automatizadas con un código
personalizado. Por lo general, los procesos se dispersan por toda la organi-
zación y el dolor se siente en diferentes departamentos y con diferentes nive-
les de urgencia. Este tipo de cliente a menudo hablará de silos de infor-
mación al momento de describir los problemas de la organización.

© 2016 Brian S. Reale

Ambos necesitan un lugar para comenzar

Aunque hay diferencias significativas entre los clientes monolito y platform

play, también 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 tecnología BPMS de elección
podrá entonces comenzar a automatizar múltiples procesos al mismo tiempo.
Los clientes monolito tienen una ruta mucho más clara para la automatización
del primer proceso. Sin embargo, aún deben hacer frente a algunos desafíos
al decidir donde comenzar su automatización. Un proceso complejo no puede
y no debe abordarse todo al mismo tiempo. Es una mejor idea tener un acer-
camiento más ágil e iterativo para la implementación y automatización incluso
de un solo proceso.

© 2016 Brian S. Reale

La metodología SIR

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

hemos desarrollado una metodología que llamamos SIR. SIR es un acrónimo
de:

Success (Éxito) Impact (Impacto) Repeat (Repeticion)

© 2016 Brian S. Reale

Éxito

La primera pregunta que su organización debería 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 difícil de resolver. Sin embargo,
estas razones casi siempre se reducen a una falta de recursos técnicos, al
tiempo, o al apoyo político.
 

© 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 algui-
en si tenemos éxito?” ¿Este proceso afecta lo suficiente a la organización
para ser importante? ¿Está alineado con una iniciativa estratégica de impor-
tancia en la organización?

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

que tenga un impacto positivo y significativo en la organización. El fracaso
por irrelevancia es casi tan malo como el fracaso por una implementación no
exitosa. Es casi seguro que ambos tipos de fracaso evaporarán el capital
social y con esto el proyecto llegará a su fin.
Al momento de intentar determinar el impacto, también recomendamos
mapear su iniciativa de proceso y cada proceso frente a los objetivos central-
es 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 au-
tomatizar, ¿su punto de partida tiene suficiente en común con los otros pro-
cesos para que pueda ser útil en sus próximos 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 esperarán que sus esfuerzos en el desar-
rollo del proceso comiencen a acelerarse después de los primeros procesos,
mostrando que la curva de aprendizaje se reducirá a medida que avanza.
Algunas de las mejoras tendrán lugar sin ninguna planeación o esfuerzo adi-
cional. Por ejemplo, cuando implemente su primer proceso necesitará consid-
erar cosas como la instalación e implementación de la autenticación y el
modelo de seguridad (probablemente involucre un Active Directory o algún
tipo de LDAP). Para los siguientes procesos, esta integración ya estará lista.
 

© 2016 Brian S. Reale

Paso 2: Hacer un mapa para el éxito

Una vez se haya identificado el problema y la solución correspondiente a

implementar, es fundamental mapear cómo lucirá el éxito una vez se auto-
matice el proceso.
Defina cómo se verá todo una vez se automatice el proceso incluyendo lo
siguiente:

¿Cuál es el proceso exacto a implementarse?

¿Qué informes se necesitarán para controlar el proceso?
¿Qué hardware, software, y periféricos se incluirán en el proceso?
¿Qué integraciones se incluirán en el proceso?
¿Qué mejoras podemos esperar?
Volumen
Tiempo
Índices de defectos
Índices de satisfacción
¿Cuánto tiempo tomará automatizar el proceso y cuántas iteraciones se
necesitarán para concretarlo?
Todas estas preguntas deben ser muy específicas. Es importante no hablar
sobre cómo lucirá el éxito en términos imprecisos. El éxito debe basarse en
objetivos muy claros y específicos. 
 

© 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 doc-
umento 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 participación de su equipo. Asimismo, esta par-
ticipación casi nunca proviene de una sola persona. En cambio, el cliente
necesitará involucrar muchas personas en su organización desde el comien-
zo. Como mínimo el equipo del cliente debe involucrase en los siguientes
roles:
Patrocinador ejecutivo - Esta persona debe ser un ejecutivo dentro de la
organización (idealmente un de nivel C) cuyos objetivos centrales del negocio
estén alineados con el proyecto. Responsable del proceso - Este será el rol
más 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 tecnología de la información que sea capaz de dirigir las interconex-
iones hacia los sistemas externos además de entender los modelos de auten-
ticación y de seguridad que utilizarán.
Usuario final – Por supuesto, también necesitamos la participación de los
usuarios finales.

© 2016 Brian S. Reale

Paso 4: Diseñar el primer proceso

Bien, ahora estamos listos para comenzar a diseñar 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
automáticamente para el usuario en un segundo plano. No obstante, los
siguientes pasos se siguen generalmente en todos los paquetes:

Diseñador BPMN - No he conocido a nadie a quien no le guste la idea de

arrastrar y soltar iconos en una página web mientras ve como su proceso
empresarial se materializa justo frente a sus ojos. Los diseñadores de pro-
cesos para arrastrar y soltar son notablemente muy fáciles de usar. Algunos
diseñadores ofrecen un mejor soporte estándar para el BPMN 2.0 que otros.
Debe decidir que tan importante es esto para su proyecto.
 

© 2016 Brian S. Reale

Paso 4: Diseñar el modelo de datos y los formularios

Modelo de datos: ¿Qué datos necesita recoger su proceso? Esta es la sigui-

ente pregunta que debe hacerse cuando empiece a modelar en el software
BPM. En este caso necesitamos pensar en cómo lucirán nuestros formatos,
qué datos adicionales pueden ser necesarios para recoger desde otros siste-
mas, y qué documentos se agregarán o crearán durante el proceso.
 

© 2016 Brian S. Reale

Paso 4: Diseñar las interconexiones

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

ma, es muy probable que encuentre datos que están alojados en otros siste-
mas. O puede que se de cuenta que su proceso capturará datos que le gus-
taría alojar en otros sistemas. Esta es a menudo la parte más técnica del
diseño del proceso. Estas conexiones a otros sistemas le harán decidir con
su equipo TI cómo acceder a los otros sistemas. ¿Será mediante un servicio
web REST o SOAP? ¿Se conectará directamente a una base de datos? ¿Im-
portará o exportará una hoja de datos de Excel?
 

© 2016 Brian S. Reale

Paso 4: Elementos adicionales

Interfaces – La mayoría de los paquetes BPM tienen un portal estándar para

que los usuarios puedan acceder a los datos y tareas asignadas. Sin embar-
go, muchos proyectos BPM requieren interfaces muy personalizadas. ¿Cómo
esperan interactuar sus clientes con el sistema? ¿Utilizarán interfaces web y
móviles estándar? O ¿Necesitan que estas interfaces estén 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 infraestructu-
ra 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
UnCommon
lenguajeLanguage forempresarios
común para Business
and Technical Workers
y trabajadores técnicos

Funcionalidad personalizada - Tal como las interfaces personalizadas men-

cionadas arriba, la mayoría de los proyectos grandes de BPM tendrán requis-
itos personalizados. A pesar de lo que le digan los proveedores de BPM,
estos requisitos necesitarán una programación personalizada. Esa es la reali-
dad del asunto. Prepárese para ello. Asegúrese de saber lo que general-
mente se ajusta dentro de un paquete BPM así como qué otras partes per-
sonalizadas 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: Implementación ágil

Bien. Ahora todo ha sido diseñado. Ya tiene su punto de partida para el éxito.
Déjeme 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 mayoría de sus partes. Sin embargo, el diseño del proceso y la
implementación del proyecto nunca son simples. Sus interesados tendrán
opiniones e ideas inconstantes. Si no concreta todo esto, automatizará un
proceso con el que sus interesados no estarán de acuerdo y al final no lo
utilizarán.
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 combinación
correcta de agilidad, redundancia (las personas podrían abandonar a mitad
de los proyectos) y continuidad.
 

© 2016 Brian S. Reale

Paso 5: Implementación ágil

A pesar de todos nuestros mejores esfuerzos para construir un punto de parti-

da perfecto, es muy difícil asegurar que todo los interesados estén en perfec-
ta sincronía. Esta es otra razón por la que es muy difícil estimar todo un
proyecto con una precisión perfecta. También es otra razón por la que la may-
oría estará de acuerdo en que es mejor desarrollar el proceso usando metod-
ologías 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 sema-
nas 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 más
fácil detectar cuales ideas iniciales fueron erróneas o necesitan cambiarse. El
cliente se acerca mucho más al proceso de desarrollo de esta manera, lo cual
dificulta bastante que disientan las interpretaciones entre el interesado y el
diseñador/desarrollador.
 

© 2016 Brian S. Reale

Paso 5: Implementación ágil

Esto reduce el riesgo porque los problemas pueden corregirse antes de inver-
tir mucho tiempo y se pueden cambiar más rápido.
La experiencia del usuario puede considerarse para ayudar a encontrar me-
jores soluciones para los usuarios que se introduzcan después 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 más fácilmente la aversión natural al cambio que existe en
todas las organizaciones mediante la implementación de un cambio en una
forma más modular.

© 2016 Brian S. Reale

Conclusión

Hay un viejo dicho que dice que los proyectos nunca fallan debido a un mal
software; sino que fallan debido a una mala comunicación en el proyecto.
Esto es absolutamente cierto. Irónicamente, la empresas pasan la mayoría de
su tiempo evaluando las funciones del producto al momento de decidir que
software BPM comprar. Éste es un error común. Evaluar los equipos del
proyecto y analizar la adecuación a la cultura entre empresas para un nuevo
proyecto no es tan fácil de hacer como comenzar a hacer una lista de fun-
ciones y una comparación de precios al momento de seleccionar un producto.
Cierto, este análisis es necesario. Pero nosotros creemos que si las com-
pañías pasan más tiempo analizando y organizando los equipos de imple-
mentación, entendiendo su estrategia y filosofía de implementación, y ase-
gurándose de que la cultura empresarial se ajuste; el riesgo de la imple-
mentación podrá reducirse ampliamente. Incluso si el proveedor de software
BPM y el socio de implementación son compañías diferentes, aplican las
mismas realidades. Preocúpese por cual producto elegir, pero preste igual o
mayor atención analizando quien hará la implementación y cómo planea
hacerlo.

© 2016 Brian S. Reale

 Si le gustaría aprender más acerca de cómo
implementar proyectos BPM exitosos o sobre
cómo se implementan los proyectos de
ProcessMaker usando esta metodología, por favor
siéntase libre de contactarnos al 617-340-3377, o
envíenos un email a info@processmaker.com.

Contact us

© 2016 Brian S. Reale