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/IbisSoft1

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/IbisSoft2

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/IbisSoft3

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/IbisSoft4

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/IbisSoft5

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/IbisSoft6

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/IbisSoft7

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/IbisSoft8

9.
Example: iPB - an ACM based on shared spaces architecture • No explicit information/ communication flow • All information is obtained from the cases shared space • All reports are left in the cases shared space From “In Search of the Holy Grail: Integrating social software with BPM” http://www.ibissoft.se/publications/HolyGrail.pdf DSV SU/IbisSoft9

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/IbisSoft10

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

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

13.
Answered: Why and How DSV SU/IbisSoft13

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

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

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