The document discusses commuting between research and practice in business process domains. It describes transitioning from an objects-connectors model to a shared spaces architecture for business process support. This involves representing processes as shared spaces with process maps and step forms. The document advocates agile approaches like cross-manning of teams and quickly adjusting processes. It proposes customized agile development of business process support systems that are models of the processes they support.

1. In Search for a Good Theory: Commuting between Research and Practice in Business Process Domain A journey Ilia Bider IbisSoft/DSV, Stockholm University

2. Theory For each item Ordered = Delivered To pay = Total + Freight + Tax Ordered > Delivered shipment To pay > Invoiced invoicing Invoiced = To pay Paid = Invoiced State- oriented view on business processes

3. Starting point – objects-connectors model Model consisting of Atoms Objects Laws Connectors Connector awakes checks restores falls asleep

4. Ending point – BP-support with shared spaces architecture 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

5. Continuation – what it is good for? Business/Enterprise agility - way of survival in the dynamic world Quickly adjust to the changes in the constantly changing business world – affects product/service development Employ new opportunities constantly appearing in the dynamic world for launching completely new products/services

6. Product and service development – traditional cycle Risks Requirements specification do not catch the needs properly Requirements specifications are not converted into a proper design Product/service manufacturing does not follow the design exactly The new product/service is not properly understood by the stakeholders and is rejected or used in the wrong fashion Each product embeds knowledge A good regulator is a model of the system it regulates Conant & Ashby A good solution is a model of the problem it solves A good key is a model of the lock it opens Requirements change during the development -> outdated wrong product/service Learning to use in own practice Requirements engineering Manufacturing/ Implementation Design Tacit knowledge Tacit knowledge Explicit knowledge Explicit knowledge Problems/needs Design specifications Requirements specifications Embedded knowledge Product/Service

7. Minimizing the risks – how? The development team having the tacit knowledge on the actual business needs/problems Agile development Cross-manning of business processes

8. Product and service development – agile style Risk minimization via Not translating to explicit knowledge Short but multiple development cycles What if we can't use agile ? Tacit understanding of problems/needs Problems/needs Manufacturing Learning to use in own practice Requirements engineering Agile approach Going agile Product/service The design phase is merged with manufacturing Learning to use in own practice Requirements engineering Manufacturing Design Problems/needs Design specifications Requirements specifications Product/service Traditional approach

9. Manning of business processes - traditional style Knowledge on current needs/problems can be obtained by participants of the boundary processes who not normally participate in the development process Shall we arrange additional processes for the to transfer knowledge?

10. Manning of business processes - cross-manning Main characteristics Multiple goals Heterogeneous teams

11. Process support for cross-manning Focus on collaboration instead of optimization Support should be adjusted to the needs of particular team – the team itself should be responsible for designing the process it wants to use and be able to change it as needed

12. Focus on collaboration - Shared spaces architecture 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

13. Customized processes - agile development of business processes A good business process support system is a model of the business process it supports Each product embeds knowledge A good regulator is a model of the system it regulates A good solution is a model of the problem it solves A good key is a model of the lock it opens Problems/needs Learning to use in own practice Business process identification and modeling Support system manufacturing Support system design Design specifications Business process models (maps) Business process support system Traditional approach Problems/needs Going agile Tacit understanding of processes Support system manufacturing Learning to use in own practice Business process identification Agile approach Business process support system With agile technique and tools you can start here

14. Agile process development What is needed to achieve it? A tool (process cutting machine) – to make changes quickly The tool should be understandable for the team creating the process – no complicated diagrams and rules

15. Thank you for your attention ! Ilia Bider , IbisSoft/Stockholm University Email: ilia@ibissoft.se Additional resources: http://processplatsen.ibissoft.se/en/ http://processplatsen.ibissoft.se/en/node/27