agil bpm - ibm af bo ebro christensen, ibm

13
© 2013 IBM Corporation 1 Bo Ebro Christensen 9/24/2013 CFIR 24/9 2013 Agility and BPM - IBM Bo Ebro Christensen Niels Agersnap Josefine Moussa

Upload: infinit-innovationsnetvaerket-for-it

Post on 25-Dec-2014

521 views

Category:

Sports


0 download

DESCRIPTION

Oplægget blev holdt ved arrangementet "Get F'IT september 2013: Agil Business Process Management i Finans", der blev afholdt den 24. september 2013.

TRANSCRIPT

Page 1: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

1 Bo Ebro Christensen 9/24/2013

CFIR 24/9 2013 Agility and BPM - IBM

Bo Ebro Christensen Niels Agersnap

Josefine Moussa

Page 2: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Introduction – agile BPM

2 Bo Ebro Christensen 9/24/2013

Agile Process Development

Business Agility enabled by BPM & Business Rules

Topic of today - Typically IBM is involved implementing the first process with the customer

- Lessons learned may be different for later processes - Based on 3 recent BPM projects in Public and Finance in DK - Also based on 10 years experience of BPM waterfall - Also based of several years of IT development Productivity measurements - Products used: BlueWorks Live and IBM BPM

Page 3: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Agile = rask, adræt, behændig, hurtig

9/24/2013 4 Bo Ebro Christensen

•Faster development (40%)

•Faster change of processes (80%)

•Significant reduction in labor time (50%)

BPM is inherently more agile than traditional development.

Page 4: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Quick Win Project - Project Phases / Sprints

9/24/2013 5 Bo Ebro Christensen

Assumption validation – a few hours

Process ”Discovery/kick off” – a few days (time-boxed! )

Infrastructure analysis - a few weeks

Process Work stream

•Project team – a few good people - Approximately 10 roles ~ 8 people •The process in scope is used as a ”Just-in-Time” driver

Milestone / end criteria

All major building blocks identified, resources/skills confirmed

All stakeholders and actors identified (people, system integration points)

All system/infastructure requirements identified. Eg Roles, security, installation, capacity er

Solution/process operational (details later)

Duration – a few months Typically 3-5 sprints Each sprint ends in a playback workhop

SOA Workshop

GUI Workshop

Core

S

yste

m

Wo

rks

ho

p

Invo

lve

d P

art

y

Wo

rks

ho

p

Pa

ym

en

ts

Wo

rks

ho

p

....

W

ork

sh

op

Docu

me

nt

Ma

na

ge

me

nt

Wo

rks

ho

p

KPI

Op

era

tio

na

l G

ove

rna

nce

&

Im

ple

me

nta

tion

Security & Roles Infrastructure

Implementation As required...

Infrastructure Work stream

Page 5: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Sprints are followed by playbacks

9/24/2013 Bo Ebro Christensen 6

2 – 4 Months

1-2 Weeks

2-3 weeks

2-3 weeks

2-3 weeks

3-5 Weeks

Process & requirements are defined in BlueWorksLive Primary screen established

Process is running All screens defined as first draft

All artefacts exist as first draft All screens complete

Process works

Production

Playbacks – a key improvement of agile over waterfall – helps establish buy-in and commitment

Page 6: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Sprint 0 theme: Analysis and requirements (4-5 weeks)

7

Domain Result of playback

GUI Primary screen established in a first version for test purposes and to

support discussion and analysis.

Process BWL process reflects ALL activities and all major use cases. Business

side approves the major cases.

Delivery: BlueWorks Live documentation.

Backend

integration

Testing prototypes of various types of integration at a ”sunshine

scenario” level.

A process can be started from the triggering component and the result

of the process can be delivered to the receiving component.

”Experiments” of protocols and integrations are a part of this sprint.

Business

rules

Analysis of rules involved eg application form validation, credit

validation etc.

Business variable are identified at an entity level with major business

attributes documented in text form.

Installation Developement environment installed.

Testing environment approved and agreed.

Test User test cases identified (not detailed).

Migration considerations completed. 9/24/2013 Bo Ebro Christensen

Page 7: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

”User stories” and ”personaes” helps create

individul stories and helps break down complex

processes into understandable scenarios

Especially helpful if users find the process too

complex and abstract

9 Bo Ebro Christensen 9/24/2013

Manifesto for Agile Software Development Individuals and interactions over (development) processes and tools

Page 8: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Manifesto for Agile Software Development Working software over comprehensive documentation

Focus on demonstrating ”running parts” in

playbacks and workshops

The BlueWorks Live process model is the

”contract” between IT and business AND the

documentaiton of the requirements.

DONT spend time documenting (obsolete)

process models

Sprints and process documentation are non-

compatible – but we need to document

lessons learned and adapt for the next

process

11 Bo Ebro Christensen 9/24/2013

Page 9: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

The business is involved in sprint 0 (Blue Works

Live) and they CAN define the process models.

DONT establish long requirement documents

from business to IT

The Blue Works Live model is

– the process documentation,

– the business requirements, and

– the contract between IT and business

13 Bo Ebro Christensen 9/24/2013

Manifesto for Agile Software Development Customer collaboration over contract negotiation

Page 10: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Manifesto for Agile Software Development Responding to change over following a plan

Use the default sprint content plan BUT be

willing and able to adapt to changes

At first, a challenge to the Project Manager

15 Bo Ebro Christensen 9/24/2013

Page 11: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Lessons learned

9/24/2013 Bo Ebro Christensen 16

Focus on early demonstration showing running artefacts improves end-user communication and accellerates learning curve. Dont document – be lazy - do it automatically ! BPM impacts the way the process participants work – manage the change !! – agileBPM reveals it faster. Sprints of 2-3 weeks is too short – but perhaps OK for smaller processes. Business MUST be involved AND customer must accept time-boxing and iterations – in some cases business side there will never be a ”version 2”. Lots of estimation exercises required – we need to develop key distribution sizing numbers and collect experience. Initially a Project Managers nightmare.

Page 12: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Conclusions from projects where we gradually moved to Agile

Agile process development dramatically enhance quality and commitment of

BPM moving abstract concepts into ”seeing is beleiving”

Business agility and process development agility are complementary.

Reduces risk of re-do / late changes Reduces risk of late delivery

Agile process development is good for vendor-customer projects and even better

for ”in-house” development.

You CAN develop large processes in a few months and simple processes in a

few weeks using Agile BPM

17 Bo Ebro Christensen 9/24/2013

Traditional BPM

Agile

Waterfall

Page 13: Agil BPM - IBM af Bo Ebro Christensen, IBM

© 2013 IBM Corporation

Questions ?

18 Bo Ebro Christensen 9/24/2013

Do one brave thing today … then run like hell !