DSV SU/IbisSoft1

Agile process development: why, when and howIlia Bider - IbisSoft/DSV SU

Presentation at BPM 2012: http://bpm2012.ut.ee/program/Session Innovative BPM Practice

Based on: Process thinking for business agility: http://bit.ly/Nouub3

DSV SU/IbisSoft2

Plan of presentation

I. Traditional BP development and problems inherent to it

II. Agile BP development

III. Requirements on the tools for agile BP development

IV. Practice

DSV SU/IbisSoft3

Background

• Own practical experience• Nonaka theory of knowledge transformation

• Good regulator theorem of Conant and Ashby“Every Good Regulator of a system must be a model of that system”

DSV SU/IbisSoft4

I. Traditional approach to BP design

• A good regulator is a model of the system it regulates

Conant and Ashby• A good solution is a model of the

problem it solves

• A good key is a model of the lock it opens

Scholten• A good process support system

is a model of a process it supports

DSV SU/IbisSoft5

Risk inherent to …

1. The model does not properly catch the real process2. The model is not converted to a proper design3. Support system does not follow the design exactly4. The new system is not properly understood by the users and

it is rejected or used in the wrong fashion5. While time goes the process and its context changes

DSV SU/IbisSoft6

II. What to do – agile approach

A good process support system is a model of a process it supports

Modeling design and manufacturing are merged in one

DSV SU/IbisSoft7

What is needed to implement

Modeling design and manufacturing are merged in one

We can’t do it with Java

Can we?

Need a process cutting machine:

A tool where process modeling is not strictly differentiated from support system design and implementation

• A good key is a model of the lock it opens

• A good process support system is a model of a process it supports

DSV SU/IbisSoft

III Some requirements on the tool

8

• Be understandable for the team creating the process – no complicated diagrams and rules

• Even the first draft of a process model should be functional

• No requirements on the order of operations until (and if) they are known

• Take care on: Data Documents Communication between people

DSV SU/IbisSoft9

• No explicit information/ communication flow• All information is obtained from the case's

shared space• All reports are left in the case's shared space

Example: iPB - an ACM based onshared spaces architecture

From “In Search of the Holy Grail: Integrating social software with BPM”http://www.ibissoft.se/publications/HolyGrail.pdf

DSV SU/IbisSoft

Structure of shared spaces in iPB

10

Process shared space – a place in the “cloud” where each process participant goes to fetch information and place the results

Process map – the upper level of the shared space structure

Step form – the low level of details of one part of the shared space

DSV SU/IbisSoft11

iPB functionality

From “iPB online reference” http://docs.ibissoft.se/node/6

DSV SU/IbisSoft12

IV. Practice

Social office in the municipality of Jönköping

DSV SU/IbisSoft13

Answered: Why and How

DSV SU/IbisSoft14

What about When?

Here

Interplay between different kind of processes

DSV SU/IbisSoft15

Some references

Googledoc: Process thinking for business agility: http://bit.ly/Nouub3

iPB online reference http://docs.ibissoft.se/node/6

DSV SU/IbisSoft16

Thank you for your attention!

Ilia Bider, DSV SU/IbisSoftEmail: ilia@dsv.su.se

ilia@ibissoft.se