You are on page 1of 51

Objetivos

Objetivo de aplicar la metodologa BPM y su definicin

Alcance

Tipos de proyectos

Aspectos de la metodologa

Objetivos Diagramas y herramientas para estimar alcance y esfuerzo Aplicaciones de la metodologa en los proyectos

Conclusiones

Aplicar la metodologa BPM en la realizacin de proyectos.

Establecer un standard de los mecanismos y pasos que se deben aplicar para la ejecucin de proyecto de manera exitosa.

Se orienta a las personas a que perciban si el proyecto en el que estn trabajando es orientado a procesos o no y por lo tanto si es viable.

Se ensea a travs de las herramientas de anlisis a detectar e identificar los grandes componentes del sistema mediante un mtodo universal y aplicable a proyectos que usen casi cualquier BPMS.

Tcnica muy eficiente del pasaje de diseo a implementacin.

Lista de entregables de cada una de las fases del proyecto.

El tipo de proyecto que se vaya a implementar.


Proyectos de rpida implementacin y resultados de alto impacto. Proyectos de integracin de procesos. Proyectos no orientados a BPM

Proyectos de 4 meses de duracin. Son nuevas funcionalidades que la organizacin debe adoptar en poco tiempo.

Pocos procesos, entidades y pocos indicadores.


No existen requerimientos de alta integracin con otros sistemas. Para solucionar los requerimientos se usan las funcionalidades del producto y no se desarrolla clases de negocio.

Una buena caracterstica de estas situaciones es que como el cliente necesita el proyecto en corto plazo est de acuerdo a flexibilizarse a la herramienta y metodologa.

Proyectos de mayor complejidad. Modelo de procesos necesita un nivel de madurez mayor y seguramente requieren de una o varias personas expertas.

La organizacin apunta a consolidar su sistema y es necesario que los actores principales lleguen a comprender, modelar y simular la interaccin de todos los procesos antes de implementar.
Existe mayor cantidad de procesos, entidades e indicadores que harn que el anlisis de la solucin global pase a ser una de las actividades ms crticas.

Para solucionar los requerimientos se usan las funcionalidades del producto y no se desarrolla clases de negocio.
Indicadores deben definirse antes o en paralelo a los procesos.

Son proyectos donde se decide usar Apia pero no estn claros los procesos y no son tangibles los beneficios.
Generalmente hay motivos estratgicos para usar Apia y tcnicamente pueden hallarse soluciones ms eficientes para implementar.

La metodologa aqu descrita no es compatible con este tipo de proyectos y seguramente debe descartarse el uso de Apia para este tipo de situaciones.

Se identifican 3 reas claramente definidas en tecnologa BPM:


BPA Arquitectura empresarial, modelizacin, simulacin y publicacin. Anlisis de procesos, diseo y re-diseo de procesos y comunicacin. BPM Automatizacin, Workflow, reglas de negocio y gestin documental. BAM Monitores, BI y cuadro de mando.

El objetivo ms importante para llegar a buen destino con el proyecto es realizar los pasos correctos en la ejecucin de las tareas comprendidas en el rea de BPA.

Debe existir un punto de inflexin o hito en el cronograma que establezca claramente cuando se finaliza y se aprueba lo establecido en el BPA. y en base a dicha informacin se comienza a realizar el BPM de los procesos resultantes.

El rea de servicios debe tener una estructura que permita alinear al cliente para ejecutar esa metodologa de trabajo.

Compromiso fuerte del cliente con el proyecto y a su vez hacerlo sentir parte del mismo.

Todos los proyectos implementan en el inicio el proceso de definicin de alcance y relevamiento junto con la contraparte.

La metodologa apunta a buscar la manera ms lgica de representar el proceso, mejorarlo si es necesario, y por ltimo representarlo en un sistema BPM.

Gran importancia a los procesos de una organizacin por s mismos, sin tener en cuenta la herramienta de diseo y tampoco la herramienta en donde se ejecutarn.
Se deben conocer los diferentes diagramas que se pueden utilizar para relevar, analizar y modelar procesos dentro del aspecto lgico y no tcnico.

A partir del cuadro de eventos/procesos y respuestas se determina la cantidad de procesos resultante a partir de los eventos requeridos por el cliente.

Matriz que contiene los procesos y entidades que forman parte del sistema y cmo interactan entre s.
Establece que accin toma el proceso sobre cada entidad.

De estos diagramas se puede deducir diferente informacin que debe ser tenida en cuenta cuando se realice el anlisis estructurado.

Este modelo sirve para los proyectos de integracin o de largo alcance, en donde se modelan las diferentes relaciones conceptuales de las entidades del proyecto.

3 grandes grupos de diagramas de anlisis

1 Modelizacin Conceptual

2 Diseo Preliminar

3 Diseo BPM

1 Modelizacin Conceptual
Eventos-Respuestas

Descomposicin funcional Diagramas lgicos de procesos Especificaciones de procesos Reglas de negocio Modelo conceptual de datos Integracin de procesos y datos

2 Diseo Preliminar
Diagramas fsicos de procesos

Componentes funcionales Modelo conceptual de datos Integracin de procesos y datos

3 Diseo BPM
Diagramas BPM de procesos

Especificaciones de pantallas Especificaciones de salidas Especificaciones de interfaces Modelos lgicos de datos Integracin de procesos y datos

Entradas:
Modelizacin Simulacin Anlisis de impacto Salidas: Mtricas de procesos Indicadores de gestin e indicadores de calidad.

A nivel de tecnologa los pasos del proceso son: Modelizacin Workflow / Integracin / Reglas de negocio / Tecnologas varias Cuadro de mando / BAM / BI.

Diseos Es llevar los modelos realizados en el punto 1 a un mapa ms especfico y ms tcnico que est contenido en una herramienta BPM (APIA). Desarrollos Es la programacin requerida (motor de reglas de negocio y clases de negocio) para cumplir con todo lo requerido en la definicin de los procesos en el diseo. Monitores (Mejora continua) Su importancia es para lograr una gestin de procesos y no una automatizacin.

Identificar claramente el tipo de proyecto y siempre que sea posible llevarlo a que sea un proyecto de rpida implementacin y resultados de alto impacto.

Definir claramente las etapas de trabajo:


Lgica de los procesos.

Diseo de los procesos.


Programacin requerida.

El objetivo en el prototipo es cerrar la lgica y el diseo de los procesos.

Resumen pasos a seguir:

Sesiones de relevamiento rpidas y con las personas dueas de los procesos.


Anlisis y diseo de la solucin mediante BPM-RAD de forma intensa. En el conjunto de procesos que integren el proyecto deben existir algunos de ellos que sean de criticidad para la organizacin. Mediciones e indicadores de los procesos en el estado actual y luego de la implementacin del proyecto.

Proyecto no mayor a 6 meses. Trabajar con un rea de la empresa que tenga entusiasmo en el proyecto y que a su vez tenga poder de promover el cambio en la cultura organizacional de la empresa.
No escatimar esfuerzo en documentacin, capacitacin y entrega de informacin a los usuarios finales del proyecto.

Identificar y especificar los problemas y oportunidades de mejoras del proceso, metas y objetivos. Podramos implementar a nivel documental un FODA por cada proceso o proyecto.

Los siguientes tems son errores que no deberan suceder:

No visualizar procesos y trasladarlos a una gran cantidad de clases de negocio.

Tratar de que la cultura de APIA y BPM se implante de abajo hacia arriba en la estructura de una organizacin. Concentrarse exclusivamente en los aspectos tecnolgicos. Prolongar demasiado el esfuerzo. Dejar que las culturas y actitudes corporativas frenen el desarrollo del proyecto.

Los proyectos exitosos deberan seguir la siguiente lnea:

Las contrapartes son los usuarios o personas que participarn en las actividades de los procesos automatizados.

Apoyo y liderazgo directivo.

Compromiso de la contraparte y documentacin que respalde cada hito del proyecto.

Gestin de expectativas. No prometer cosas que aportan mucha riqueza tcnica y muy poca riqueza funcional.

Anlisis y Diseo participativo y dinmico.

Mediciones y Control de resultados de cada etapa del proyecto.

Objetivos

Objetivo de aplicar la metodologa BPM y su definicin

Alcance

Tipos de proyectos

Aspectos de la metodologa

Objetivos Diagramas y herramientas para estimar alcance y esfuerzo Aplicaciones de la metodologa en los proyectos

Conclusiones Aplicacin de la metodologa en el rea de servicios

Factores que dan complejidad de un proyecto:


La cantidad de usuarios que usan el sistema. La cantidad de reas funcionales, oficinas, grupos, etc, que usan el sistema. Los indicadores aumentan la dificultad del modelo. Un proyecto muy complejo en indicadores puede elevar la complejidad substancialmente. La integracin entre procesos y el fuerte acoplamiento entre ellos generalmente incorpora complejidad adicional.

Factores que dan complejidad de un proyecto:


Relacin Tcnico/Funcional: Mantener el ratio cerca del 30%. Nunca puede ser superior a 50% en BPMS y difcilmente se encuentre por debajo de 30%. Contraparte colaborativa: La contraparte puede llegar a hacer gran parte del trabajo o apoyar poco.

Madurez organizacional: Nivel de conflictividad de la organizacin frente al proyecto y su facilidad para flexibilizarse y adaptarse a los cambios.

Recomendaciones al Consultor Funcional:

1. Gestin de expectativas. No regalar promesas porque si, inicialmente tener una postura inflexible para aceptar nuevos requerimientos ms all de los iniciales.

Luego ir estudiando a la contraparte e ir buscando limites de negociacin y analizar los puntos de debilidad de la misma para luego ser usado como punto de apoyo para no aceptar nuevos requerimientos alineando metodolgicamente al cliente y a la contraparte.

Recomendaciones al Consultor Funcional:

2. Estimaciones de esfuerzo de acuerdo a la metodologa Aplicar una metodologa para estimar proyectos, con el mismo criterio que aplicamos para ejecutar un proyecto BPM. Identificar los procesos y entidades que van a existir y su complejidad; en base a ese conocimiento y determinadas paramtricas existentes podemos llegar a saber cunto esfuerzo va a insumir cada proceso.

Identificar cuantas interfaces y consultas generales y analticas van a existir; en base a esto se puede ajustar la estimacin.

Recomendaciones al Consultor Funcional:

3. Evitar siempre llegar a la programacin de bajo nivel. Disear una clase de negocio especfica tiene que ser algo poco usual en estos proyectos. Exprimir las capacidades nativas del producto intentando resolver la problemtica con las herramientas que aporta APIA.

Entregar proyectos sin clases de negocio y obteniendo el mximo las capacidades de Apia se hacen procesos ms simples.

Recomendaciones al Consultor Funcional:

Intentar pensar en las consultas e indicadores antes de hacer los procesos.


Debuguear los procesos antes de testearlos.

Intentar simular los procesos antes de implementarlos.

Recomendaciones al Consultor Funcional:

4. Convencer al cliente de la importancia del prototipo. El prototipo tiene que dejar ser una formalidad con el cliente y pasa a ser la piedra fundamental del proyecto. El prototipo tiene que contemplar todas las alternativas planteadas por el cliente de forma tal que el diseo del proceso y entidades quede cerrado en esta instancia. Lo nico que se deja de lado es la entrada en detalle en formularios, generacin de interfaces e implementaciones especficas que se deban realizar.

Recomendaciones al Consultor Funcional:

4. Convencer al cliente de la importancia del prototipo. Comprometer a la contraparte de la importancia del prototipo, para esto nosotros mismos le damos una alta importancia. Es muy importante mostrar el prototipo con los procesos del cliente para facilitar la comprensin de todo el sistema y sus componentes

Recomendaciones al Consultor Funcional:

5. No buscar culpas. Evitar caer en la discusin de quienes son los culpables de que aparezcan en el proyecto cambios no previstos. Muchas veces podemos tener flexibilidad para terminar cediendo en hacer un cambio sencillo y que nos sirva para ser menos flexibles antes cambios ms difciles de contemplar.

Recomendaciones al Consultor Funcional:

6. Modificar la clsica espiral propuesta en ingeniera del software.

La ingeniera del software propone una espiral que es relevar, analizar, disear, desarrollar, testear y recin en ese momento entregar al cliente los resultados. Y de acuerdo a las opiniones del cliente y sus modificaciones es que se circula por esa espiral n veces.

Recomendaciones al Consultor Funcional:

6. Modificar la clsica espiral propuesta en ingeniera del software.

Proponemos modificar la espiral, aprovechando la facilidad que tiene APIA para representar cualquier proceso a nivel de prototipo en un plazo muy corto (no ms de 20 o 30 das).

Por tanto nuestra espiral sera relevar, analizar, disear y entregar al cliente. Este ciclo lo realizamos n veces hasta que el cliente muestra su conformidad y ese hito es la confirmacin del prototipo; paso siguiente se realiza el desarrollo y el test y la puesta en produccin.

Recomendaciones al Consultor Funcional:

7. Trabajo colaborativo. Mximo esfuerzo para que el cliente coopere entregando el Facilis, el MER y todo lo que se va a transformar en entregable del proyecto o input de implementacin.

De esta forma acortamos los plazos de validaciones y minimizamos prdida de informacin y aseguramos cierta madurez para la presentacin del prototipo.

Recomendaciones al Consultor Funcional:

8. Nuevas prestaciones de Apia indispensables para el Consultor Funcional.

Importar XPDLs Facilis con su respectivo DD y formularios e importar un MER generndose automticamente en Apia los objetos entidades, diccionario de datos, formularios, consultas, procesos, monitores, etc. Usando el Configuration Manager se podrn llevar los objetos a otros ambientes e inclusive guardar y recuperar contenidos de instancias de entidades cuando las definiciones cambien.

Recomendaciones al Consultor Funcional:

Documentacin y entregables: Es muy deseable que el cliente contribuya fuertemente con toda la documentacin aportando horas de trabajo en confeccionar la siguiente documentacin:

Diagramas de relevamiento y diseo.

Documentacin generada por APIA.

Documentacin que genera FACILIS.

Documentacin y entregables:

El MER debe incluirse en la documentacin de diseo. Manual de usuario genrico para usuarios de proyectos ms el facilis del procesos y descripcin de la tarea. El Help on-line incluye al manual genrico ms los documentos generados por Facilis ms los videos .flv generados en el e-learning de acuerdo a procesos, tareas y formularios.

El e-learning tiene un template que incluye la capacitacin, FAQ, glosario, foro, preguntas al docente y enlaces.

Existen otros entregables que deben ser completados:


Caso de negocio durante el anlisis. Caso de xito cuando se vean resultados tangibles o al final del proyecto. Carta de satisfaccin del cliente antes de finalizar el proyecto. Documento de referencia del proyecto. Oportunidades de mejora en la metodologa. Evaluacin de las personas que intervinieron (empresa, cliente y partner).

Entidades y Procesos - MER y Facilis:

Los elementos fundamentales que tienen que ser ingresados en Apia son los procesos y las entidades.

Tareas, grupos, formularios, clases de negocio, monitores, consultas y diccionario de datos son necesarios para la definicin del modelo pero es generalmente una consecuencia directa de los procesos y entidades. Apia cuenta con la facilidad de importar modelos de MER y diagramas de procesos BPMN que proponemos se construyan antes de comenzar la etapa de implementacin con Apia.

Entidades y Procesos - MER y Facilis:

El MER aporta mucha riqueza por si mismo pues seguramente cada una de esas entidades tenga relacionado un proceso que la crea o modifica. Generalmente las entidades son objetos relevantes del sistema que deben aportar informacin a los usuarios a travs de consultas y muchas veces es necesario monitorear los procesos que la crearon y modificaron. El Proceso Facilis aporta riqueza sobre como los procesos dan origen y afectan a las entidades del sistema.

Entidades y Procesos - MER y Facilis:

Es necesario trabajar con estos modelos y que exista una correlacin entre las entidades y datos del MER y de Facilis.

Para el primer prototipo de los procesos principales del sistema no es fundamental contar con el MER y para ello se pueden importar los XPDLs en Apia que darn origen a todos los objetos. Antes de que se genere el modelo de objetos es necesaria la intervencin humana para tomar decisiones sobre el alcance.

Entidades y Procesos - MER y Facilis:

De la importacin del MER:


Apia genera tantas planillas como entidades de cdigos existan. Apia genera las entidades, diccionario de datos, formularios, procesos, monitores, consultas on-line y pretende seguir evolucionando.

Se presenta al cliente los prototipos obtenidos de la generacin por la importacin del MER y de los procesos Facilis sin clases de negocio especficas. El testing ser mnimo para la presentacin de los prototipos. El testing funcional debe hacerse con el debugger.

PROTECA como medio de comunicacin: PROTECA se usa para almacenar Clases de negocio, modelos de datos, procesos, consultas, cubos, etc.

Est organizada para albergar MERs, Clases de negocio, excels con valores de codigueras, formularios, consultas y cubos

Los objetos se suben mediante los procesos ITIL a Proteca

www.statum.biz

You might also like