Contenidomarketing.processmaker.com/acton/attachment/3812/f-01db/1/-/-/-/-/5... · Paso 4 –...

Contenido

IntroducciónPaso 1 – Elegir un lugar para comenzarEl cliente monolitoEl Platform PlayAmbos necesitan un lugar para comenzarLa metodología SIR ÉxitoImpactoRepetibilidadPaso 2 – Hacer un mapa para el éxitoDocumento inicial y plan de trabajo (SOW)Paso 3 – Crear los equiposPaso 4 – Diseñar el primer procesoPaso 4 – Diseñar el modelo de datos y los formulariosPaso 4 – Diseñar las interconexionesPaso 4 – Elementos adicionalesConstruir 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.


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 monolitoEl cliente Platform Play


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.



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 lastareas, cuáles tareas son manuales y cuáles son automáticas.

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.


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.

Ambos necesitan un lugar para comenzar


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)

La metodología SIR


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.

Éxito


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

Impacto


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.

Repetibilidad


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?VolumenTiempoÍ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.

Paso 2: Hacer un mapa para el éxito


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.

Documento inicial y plan de trabajo (SOW)


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.

Paso 3: Crear los equipos


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.

Paso 4: Diseñar el primer proceso



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.

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


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?

Paso 4: Diseñar las interconexiones


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?

Paso 4: Elementos adicionales


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?

Step 4: Designing Interfaces

A Common Language for Business and Technical Workers

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

Un lenguaje común para empresarios y trabajadores técnicos


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.

A Common Language for Business and Technical Workers


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.

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.



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.



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.

Conclusión



Contact us

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 [email protected].

http://www.processmaker.com/

Contenidomarketing.processmaker.com/acton/attachment/3812/f-01db/1/-/-/-/-/5... · Paso 4 –...

Documents

Transcript of Contenidomarketing.processmaker.com/acton/attachment/3812/f-01db/1/-/-/-/-/5... · Paso 4 –...