Presentation at BPM 2012. Read more in http://bit.ly/1otCZD2 - a long journal article that develops the presented ideas farther

1. Agile process development: why, when
and how
Ilia 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/IbisSoft
1

2. 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/IbisSoft
2

3. 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/IbisSoft
3

4. 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/IbisSoft
4

5. Risk inherent to …
1. The model does not properly catch the real process
2. The model is not converted to a proper design
3. Support system does not follow the design exactly
4. The new system is not properly understood by the users and it is
rejected or used in the wrong fashion
5. While time goes the process and its context changes
DSV SU/IbisSoft
5

6. 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/IbisSoft
6

7. What is needed to implement
We can’t do it with Java
Can we?
• A good key is a model of the lock it
opens
• A good process support system is a
model of a process it supports
Modeling design and
manufacturing are
Need a process cutting machine: merged in one
A tool where process modeling is not
strictly differentiated from support
system design and implementation
DSV SU/IbisSoft
7

8. III Some requirements on the tool
• 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/IbisSoft
8

9. Example: iPB - an ACM based on
shared spaces architecture
• 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
From “In Search of the Holy Grail: Integrating social software with BPM”
http://www.ibissoft.se/publications/HolyGrail.pdf
DSV SU/IbisSoft
9

10. Structure of shared spaces in iPB
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/IbisSoft
10

11. iPB functionality
From “iPB online reference” http://docs.ibissoft.se/node/6
DSV SU/IbisSoft
11

12. IV. Practice
Social office in the municipality of Jönköping
DSV SU/IbisSoft
12

13. Answered: Why and How
DSV SU/IbisSoft
13

14. What about When?
Here
Interplay between different kind of processes
DSV SU/IbisSoft
14

15. Some references
Googledoc: Process thinking for business agility:
http://bit.ly/Nouub3
iPB online reference http://docs.ibissoft.se/node/6
DSV SU/IbisSoft
15

16. Thank you for your attention!
Ilia Bider, DSV SU/IbisSoft
Email: ilia@dsv.su.se
ilia@ibissoft.se
DSV SU/IbisSoft
16