1

Masking flexibility behind rigidity: Notes on how

much flexibility people are willing to cope with

Prepared for BPMDS’05 byIlia Bider, IbisSoft,Stockholm, Sweden

2

Do we need flexibility

A bit of provocation

3

Flexibility - Hypothesis• The issue was brought

about as soon as Workflow Management Systems (WFMS) appeared

• First WFMS were considered as rigid as they did not cover all situations the user could get into

Flexibility is required

4

Flexibility – reality by example

Reaction on flexibility of associative search

• Search through association – unusual, difficult to accept

VS

• Directed search – normal – easy to accept

5

Why complaints on rigidity - hypothesis

• Preliminary business process mapping/modeling/analysis cannot be exact.

• This results in “wrong” rigidity rather than in lack of flexibility

6

Solutions

• Start with “wrong” rigidity and quickly transform it to the right one. Risks – before the transformation is completed – users can give up

• Start with real flexibility and quickly transform it into the “right” rigidity. Risks – users may not be able or willing to cope with flexibility

7

Starting with flexibility - a catch

• In the beginning of BPMS introduction flexibility is required due to insufficiency of the underlying BP model

• In the beginning of BMPS introduction flexibility constitute an extra burden on the users while they learn how to use the system

Solution – limit flexibility as soon as possible

8

Starting with flexibility

• Workflow approach does not permit to start with full flexibility (Meccano model)

• Different approach is required (Meccano model)

9

Starting with total flexibilityState flow: Background

• Modeling and control of physical processes - Mathematical system theory

• Continuous-time physical process trajectory:

• x – vector of state variables (reals)• – derivatives of state variables• w – vector of environment variables• Goal – a point or a surface in the state space

0),,( wxxF

x

10

State flow: what is needed

• Find a way for representing states of business processes.

• Understand how to represent speed and direction of movement.

• Find out how to connect speed and direction of movement to the position in the state space.

11

State flow: state and goal

• For each item Ordered = Delivered

• To pay = Total + Freight + Tax

• Invoiced = To pay

• Paid = Invoiced

12

State flow: state and activities

• Ordered > Delivered shipment • To pay > Invoiced invoicing

13

Integrated state = state + operative plan

14

State flow: acquiring rigidity via policies and dynamical planning

• Obligations• Prohibitions• Recommendations

Two step planning

15

Totally flexible BPS system ProBis includes

• Most common business objects– People (contacts and users)

– Organizations (groups of people)

– Documents (piece of information having a physical form)

• 3 generalized business processes– iTeam – suitable for internal information exchange, etc

– xTeam – suitable for sale, purchase, CRM

– Project – suitable for administration of projects

16

Test site Making experiment on living creatures

• SRAT – a medium size Union for academics (12 000 members), about 10 employees

17

Going rigid – first steps

• Terminology and screen layouts – even quite educated people prefer their own terminology (even if it will limit the usability)

• Registering external events, particularly when starting a new process. Require special dialog (even if it will limit the usability)

18

Going rigid – next steps

• Splitting general processes to specialized ones

• Introducing automated planning

19

Questions and discussion

20

Acknowledgement

• Our work is currently supported by Swedish Agency for Innovation System (VINNOVA)

• The author would like to thanks all people participating in the projects that gave raise to the current discussion

21

Thank You!

Ilia Bider,IbisSoft, Sweden

www.ibissoft.com/english/index.htmEmail: ilia@ibissoft.se