Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
BPMS Development Lifecycle Presentada por Mariano Benitez SOA/BPM Practice Manager – Ataway VP Marketing Capítulo Argentino – ABPMP Miembro de BPMN 2.0 RTF -‐ OMG 2 © Todos los derechos reservados. No está permitida la reproducción parcial o total del material de esta sesión, ni su tratamiento informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico, mecánico, por fotocopia, por registro u otros métodos, sin el permiso previo y por escrito de los titulares de los derechos. Si bien este Forum ha sido concebido para difusión y promoción en el ámbito de la profesión a nivel internacional, previamente deberá solicitarse una autorización por escrito y mediar la debida aprobación para su uso. Aclaración 3 Agenda 4 CICLO DE DESARROLLO DE PROCESOS • Descripción • Factores que afectan • Primer ciclo DISCLAIMER • NO NAMES! • Evaluación basada en: – Análisis de varias herramientas, – Experiencias de proyectos, – Foco en el largo plazo. • Formato: – Aspectos a considerar, – Recomendaciones. 5 CICLO DE DESARROLLO DE PROCESOS 6 Desarrollo con BPMS • Alcance de los proyectos: – Comienza con los requerimiento de negocio, – Relevamiento y documentación, – Desarrollo – Continúa con la puesta en producción, – Soporte y evolución. • BPM no es un paradigma estático: – Se agregan procesos nuevos, – Se mejoran los existentes, – La demanda crece en el tiempo. • Ciclo ➡ Flujo 7 Desarrollo con BPMS • Criterios de selección de herramientas BPMS: – Funcionalidad operativa, – Aspect comercial. • Otros factores: – La forma de desarrollar, – Las capacidades de la empresa y el proveedor. 8 FACTORES QUE AFECTAN EL CICLO DE DESARROLLO 9 Alcance de los proyectos BPMS • Paquete de aplicación = Unidad de desarrollo – Procesos, Integración, pantallas, BAM, Reglas • Ejemplos: – Todo incluído (integración, BAM, procesos) – Solo procesos y BAM (integración por WS) – Algunos separan las tareas humanas (pantallas) – Distintas versiones de producto: Express, Full, etc. 10 Alcance de los proyectos BPMS 11 • A qué hay que prestar atención: – Incluir más de una unidad de desarrollo en el alcance • Las consecuencias: – Manejo manual de las dependencias – Mayor complejidad del testeo, despliegue, versionado e integración • La recomendación: – Alinear el alcance de los proyectos a las unidades de desarrollo de las herramientas Capacidades del producto • Cada BPMS tiene limitaciones técnicas • Ejemplos – Modelo organizacional – Elementos de modelado – Infraestructura de runtime – Multi-‐tenancy – Reuso de código 12 Capacidades del producto 13 • A qué hay que prestar atención: – Se altera el proceso debido a estas limitaciones • Las consecuencias: – Se pierde alineamiento con el negocio – Ciertos patrones de solución no son posibles • La recomendación: – Entender bien las capacidades – Definir infraestructura y patrones con esto en mente Ciclo de vida del producto • Aspectos relacionados: – Elementos de desarrollo, – Etapas de proyecto. • Ejemplos: – Manejo de fuentes, – Manejo de ciclo de vida, – Plataforma del producto, – Metodologías, – Documentación. 14 Ciclo de vida del producto 15 • A qué hay que prestar atención: – Cuando el ciclo de vida elegido es distinto al propuesto por el proveedor • Las consecuencias: – Poco soporte del producto y del proveedor, – Complejidad adicional y pérdida de funcionalidad, – Configuración fuera de lo usual. • La recomendación: – Alinear la propuesta del proveedor con las políticas internas, manteniendo la agilidad. Conocimientos del equipo • Los conocimientos necesarios para manipular todos los aspectos del paquete de aplicación • Ejemplos: – Notación de modelado – Diseño de formularios, Implementación de tareas – Integración y manejo de datos – Ejecución, prueba, administración. 16 Conocimientos del equipo 17 • A qué hay que prestar atención: – Cuando existe una gran brecha entre los conocimientos actuales y los necesarios. • Las consecuencias: – Poca aceptación y comprensión, – Larga etapa de aprendizaje, – Dificultad para conseguir personal adecuado. • La recomendación: – Alinear el BPMS con las capacidades de la organización. Separación de funciones • Propuesta por la herramienta dentro de su ciclo de desarrollo – Del analista funcional al implementador • Ejemplos: – Separaciones estrictas, – Niveles incrementales, – Herramientas específicas para cada rol. 18 Separación de funciones 19 • A qué hay que prestar atención: – La fluidez de equipo para pasar de un rol a otro – La cantidad de roles necesarios • Las consecuencias: – Menor flexibilidad del equipo – Menor entendimiento dentro el equipo – Menor agilidad • La recomendación: – Minimizar los roles y/o las divisiones fuertes. Productividad del desarrollador • Ciclo normal de desarrollo: – Hacer, probar y corregir. • Ejemplos: – Boton de play en el IDE, – Mensajes de la aplicación, – Mandar a compilar y salir a tomar un café, – #clicks necesarios. 20 Productividad del desarrollador 21 • A qué hay que prestar atención: – El tiempo que toma desarrollar – La complejidad • Las consecuencias: – Tiempos muertos de espera, – Los errores dentro del ciclo, – Puede alterar el modo de desarrollar. • La recomendación: – Minimizar y simplificar el ciclo del desarrollo. Documentación, soporte y comunidades • ¿Cómo nos afectan estosproblemas? • Ejemplos: – Situaciones sin resolver, – Configuración de seguridad, – Arquitectura y configuración fuera del estándar, – Madurez del producto (¿o falta de?), – ¿Donde están los que saben? 22 Documentación, soporte y comunidades 23 • A qué hay que prestar atención: – Perder el control sobre la resolución de problemas. • Las consecuencias: – Nos transformamos en detectives, – Se pierde la previsibilidad de las tareas, – Se toman decisiones inadecuadas, – Se aplican soluciones no soportadas por el producto. • La recomendación: – Asegurar el proceso de resolución de problemas. Bonus track: El implementador • Problemas – Solo sabe el producto – Falta foco en la mejora – Orientado a proyecto – Estimaciones – Hardcodeo, errores • A que hay que prestar atención: – Capacidades, – Compromiso, – Visión. 24 EL PRIMER CICLO DE DESARROLLO 25 ¿Cómo arranca el primer proyecto? • Resolver un problema de negocio – Se evalúa a partir del ROI del proyecto • Definición estratégica de alto nivel – El CEO impulsa un cambio de rumbo • Una necesidad pura y simple de agilidad – El CIO impulsa bajar el tiempo de respuesta de IT 26 ¿Qué hacer en el primer proyecto? • ¿Definición de la infraestructura corporativa? – Lograr experiencia antes de definirla • ¿Definición de mejores prácticas? – Confirmarlas con el proveedor – Probarlas más de una vez – Investigar alternativas • ¿Transferencia de conocimiento? – En lo posible hacerla luego de la puesta en producción 27 ✘ ✘ ✘ CONCLUSIONES 28 ¿Qué hace único al BPMS? • Visibilidad • Control • Entendimiento común • Modelo = Sistema • AGILIDAD! 29 ✘ ✘ ✔ ✔ ♚ Agilidad con BPMS 30 • Una gestión por procesos unida a un BPMS permite una agilidad sin precedentes • MANTENGA LA AGILIDAD COMO UN VALOR FUNDAMENTAL EN SU ESTRATEGIA DE GESTIÓN POR PROCESOS • ¡Reaccionará a la velocidad de su negocio! Gracias por asistir a esta sesión… Preguntas y Respuestas 31 Para mayor información: 32 Benitez, Mariano M. G. mbenitez@ataway.com http://ar.linkedin.com/in/marianobenitez Para descargar esta presentación visite http//bpmforum.usuaria.org.ar
Compartir