Logo Studenta

Ciclo de Vida BPM

¡Este material tiene más páginas!

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

Otros materiales