Agile Business Process Development: Why, When and How
Description
Presentation at BPM 2012: http://bpm2012.ut.ee/program/ Session Innovative BPM Practice. Based on: Process thinking for business agility http://bit.ly/Nouub3
Transcript
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 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 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 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 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 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 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 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 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 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 iPB functionality From “iPB online reference” http://docs.ibissoft.se/node/6 DSV SU/IbisSoft11 IV. Practice Social office in the municipality of Jönköping DSV SU/IbisSoft12 Answered: Why and How DSV SU/IbisSoft13 What about When? Here Interplay between different kind of processes DSV SU/IbisSoft14 Some references Googledoc: Process thinking for business agility: http://bit.ly/Nouub3 iPB online reference http://docs.ibissoft.se/node/6 DSV SU/IbisSoft15 Thank you for your attention! Ilia Bider, DSV SU/IbisSoft Email: ilia@dsv.su.se ilia@ibissoft.se DSV SU/IbisSoft16