Webinar: BPMN with camunda

1,451 views
1,167 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,451
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
52
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Webinar: BPMN with camunda

  1. 1. BPMN with camunda Webinar July 17, 2014
  2. 2. Welcome! Jakob Freund is CEO of camunda, author of the bestselling book 'Real-Life BPMN' and a regular speaker at BPM conferences. His passion is the big picture of scaling up business models by well- defined and automated business processes, using BPMN as the common language for Business and IT.
  3. 3. About Camunda 201320122011201020092008 Incorporation Consulting and Training around BPM camunda BPM BPM Software Vendor Locations: Berlin (HQ), San Francisco Memberships
  4. 4. camunda BPM References Banking Insurance Other
  5. 5. Some references outside D.A.CH. Financial Industry Regulatory Authority USA Sony DADC New Media Solutions USA National Centre for Vocational Education Research Australia Allianz Indonesia Insurances Indonesia
  6. 6. BPMN with camunda BPM Analyst / Developer User Operator Modeler Tasklist / Your UI Cockpit Engine camunda BPM platform
  7. 7. Camunda BPM Community Day Robert Parker, Australia Post: Order management using camunda BPM This presentation will describe our order management architecture and in particular order fulfilment processes using Camunda BPM technology. A number of business requirements leading to design challenges will be presented, along with the benefit of using BPM to realise solutions and the corresponding business benefits. In addition, some key technical challenges, solution options, and resulting solution design decisions and implications will be presented. Also: • Camunda @ 1&1 Internet • Grails • OSGi • Elastic Search • Advanced Mocking • Upcoming Features Thursday, September 18 | Berlin http://network.camunda.org/meetings/32
  8. 8. BPMN Process Design BPMN in Operations How to argue for BPMN and camunda Agenda
  9. 9. „Executable BPMN process models…  Are always complex and detailed.“  Are a refinement of business driven process models.“  Should be created and maintained by IT alone.“ Three common mistakes
  10. 10. Is this a „complex process model“ ?
  11. 11. You can create (and skip) complexity wherever you want Start complete task execute service End Human Software Engine
  12. 12. Camunda: Flexible combination of BPMN and Code Start complete task execute service End
  13. 13. „Send me an email when there‘s work to do“
  14. 14. Bad Approach
  15. 15.  Retrieve the user that should be assigned to a user task based on complex business logic  Notify that user by email about the pending task  Track KPI in external System after the usertask has been completed.  Track KPI after the issue has been reviewed I want to: see: BPMN 2.0 by Example, OMG
  16. 16. 100% Model-driven approach (Anti-Pattern)
  17. 17. 100% Model-driven approach (Anti-Pattern) Retrieve the user that should be assigned to a user task based on complex business logic Notify that user by email about the pending task Track KPI in external System after the usertask has been completed Track KPI after the issue has been reviewed
  18. 18. Bad Approach
  19. 19. Better: Keep the Diagram „lean“
  20. 20. Silver Bullet „Listener“
  21. 21. The Listener in Detail 1. Retrieve Assignee‘s Email 2. Create Email with Deep Link 3. Send Email
  22. 22. Keeping the diagram easy-to-read • Retrieve the user that should be assigned to a user task based on complex business logic • Notify that user by email about the pending task Track KPI in external System after the usertask has been completed Track KPI after the issue has been reviewed
  23. 23.  Activities that are (really) relevant for the business side  Activities I want to monitor explicitly  Activities where I can benefit from the process engine‘s capabilities  Requirements that just need to be implemented In BPMN: As much as necessary, as little as possible
  24. 24. „Executable BPMN process models…  Are always complex and detailed.“  Are a refinement of business driven process models.“  Should be created and maintained by IT alone.“ Three common mistakes
  25. 25. The big Mistake Level 3 („executable process model“) is a refinement of Level 2 („Operational Process Model“)!
  26. 26. The new „camunda-house“ Strategic Process Model Operational Process Model human process flow technical process flow
  27. 27. The new „camunda-house“ Strategic Process Model Operational Process Model human process flow technical process flow • Manual Control Flow • Work Description • User Experience • Interaction Flow • Collaboration between User and System • quick overview • logically-abstract • Precise description • Physically- concrete • Automated control flow • Code
  28. 28. Don‘t mix human and technical flows!
  29. 29. Don‘t mix human and technical flows!
  30. 30. Clearly separate human and technical flows HUMAN TECHNICAL HUMAN
  31. 31. „Executable BPMN process models…  Are always complex and detailed.“  Are a refinement of business driven process models.“  Should be created and maintained by IT alone.“ Three common mistakes
  32. 32. Executable Process Model = Technical (Process) Flow Strategic Process Model Operational Process Model human process flow technical process flow
  33. 33. Pure Code? Strategic Process Model Operational Process Model human process flow technical process flow
  34. 34. The executable process model is (also) a business driven artefact.
  35. 35. The technical flow must be developed in a collaboration User Analyst Developer Problems, Needs, Priorities... Feasibiltiy, Efforts, ... Ideas, Roadmaps, Costs... To-Be Processes, Requirements, ... Strategic Process Model Operational Process Model human process flow technical process flow
  36. 36. How to discover a „good“ process analyst? Hard Skills • BPMN • Technical Understanding (How dows a process engine work?) • Business Domain Understanding Soft Skills • Readiness of mind • ability to communicate • Analytical Mind • Empathy
  37. 37. Typical PoC-Workshop (5 days) Process Design Process Execution Live Demo Design: 2 Days • To-Be-Process Design • Business Departments, IT-Architects, Software Developers Conclusion: 0.5 Days • Prototype Live Demo • Lessons Learned • All Stakeholders • Developing a Process Application Prototype • IT Architects, Software Developers Implementation: 2.5 Days
  38. 38. „Executable BPMN process models…  Are always complex and detailed.“  Are a refinement of business driven process models.“  Should be created and maintained by IT alone.“ Three common mistakes
  39. 39. BPMN Process Design BPMN in Operations How to argue for BPMN and camunda Agenda
  40. 40. Real World Demo: camunda Free Trial Process Website Tasklist Cockpit Special UI
  41. 41. Coming soon: bpmn.io
  42. 42. BPMN Process Design BPMN in Operations How to argue for BPMN and camunda Agenda
  43. 43.  Transpareny: We get an understanding of how we work – sth. That used to be buried in legacy applications.  Up-To-Date-Documentation: When we just document our processes, it‘s hard to keep them up to date. Now the docs are necessarily up to date, because they represent what‘s actually running.  Shorter Development Cycles: The camunda-approach is very good fit for modern paradigms such as agile collaboration. There is a way better communication between business and IT that dramatically increases development cycles.  Reduced Programming Efforts: BPMN is a very powerful language for process execution, and a BPMN process engine therefore brings a good number of features that we would otherwise need to code ourselves (Examples: Wait States)  What you see is what you run: For the first time we now really say what‘s currently happening, because we get a real-time view on our source code the moment it‘s being executed! What customers say about BPMN / camunda BPM
  44. 44. Typical PoC-Workshop (5 days) Process Design Process Execution Live Demo Design: 2 Days • To-Be-Process Design • Business Departments, IT-Architects, Software Developers Conclusion: 0.5 Days • Prototype Live Demo • Lessons Learned • All Stakeholders • Developing a Process Application Prototype • IT Architects, Software Developers Implementation: 2.5 Days
  45. 45. Q&A

×