Professional Documents
Culture Documents
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
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.
Proyectos de 4 meses de duracin. Son nuevas funcionalidades que la organizacin debe adoptar en poco tiempo.
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.
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.
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
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.
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.
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.
Las contrapartes son los usuarios o personas que participarn en las actividades de los procesos automatizados.
Gestin de expectativas. No prometer cosas que aportan mucha riqueza tcnica y muy poca riqueza funcional.
Objetivos
Alcance
Tipos de proyectos
Aspectos de la metodologa
Objetivos Diagramas y herramientas para estimar alcance y esfuerzo Aplicaciones de la metodologa en los proyectos
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
Documentacin y entregables: Es muy deseable que el cliente contribuya fuertemente con toda la documentacin aportando horas de trabajo en confeccionar la siguiente documentacin:
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.
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).
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.
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.
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.
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
www.statum.biz