1. Business process management is a discipline, not a technology. 2. The discipline is grounded in Lean thinking, continuous improvement, total quality management and six sigma. 3. Business processes constantly change, even though many are unaware of it. For example, the products change, the marketing approach changes, suppliers change, the business strategy changes, the organizational structure changes, and if that isn’t enough, the competition and regulatory bodies force change. Or the company gets bought or acquires another company. 4. BPM projects should focus on how to manage and capitalize upon constant, unrelenting change. 5. BPM projects should also help the business person by providing all the information he/she needs within the context of a process, and all the collaboration tools needed within the context of the process. 6. BPM projects should be led by business, not IT, to avoid failure. 7. Business led BPM projects can still fail, so best practices matter. 8. Process governance is an important part of BPM initiatives. 9. Process governance and data governance initiatives should be aligned. 10. The best place to start with a BPM initiative is in cross-functional processes with high volumes of manual work that create a lot of pain in the organization. 11. Change management is critically important; the biggest area of resistance is usually in mid-level managers who are in charge of functional groups. They tend to dislike cross functional processes because they perceive a loss of power. 12. By choosing a process that has lots of pain, it overcomes the internal resistance. 13. A BPM center of excellence (COE) is essential for success. 14. Many companies establish a business process or business performance or business improvement group that sits in the business and supports all the business domains in their BPM efforts. This group usually owns the BPM COE. 15. The companies that are mature in their process initiatives usually have business process organizations (I call them business operations) sitting in the business. 16. Aspiring companies working hard to bring about BPM change often have business process experts/execs sitting in IT with a dotted line to the business. 17. One of the biggest challenges in BPM is finding skilled resources to interview business users, design processes, analyze process and optimize processes. 18. Many companies look to business analysts for their process analyst needs; however, the success rate is only about 50% (based on discussions with BPM COE managers). 19. Building process skills is a big challenge; one way to do it is combine an IT person and a business person into the process analyst job—sort of a 2 in the box approach. It helps with cross-training. 20. Some of the organizations to go to for help with BPM are: ABPMP, BPM Focus, WfMC, AIIM. 21. Some vendors have jumped into the skills building business or efforts because it is a critical path to their success. 22. Vendors that help with skills building include: IBM (see the Blueworks web site), and SAP. Also, Lombardi Software now offers a University for courses in BPM. 23. BPM suites are tools that help with business process management initiatives. 24. BPM suites (BPMS) usually have these components: design, execution, analysis, and optimization, with a feedback loop to the design component for process improvement. 25. Process versions should take less than six months to develop and deploy. 26. Usually a process goes through 3 versions to make it really right; sometimes up to 7. But by then, something has probably changed in the business, making it important to keep updating the process. Get used to change. That is what BPM is all about. 27. Some organizations have broken processes and just want a BPMS to automate a process. The results can be spectacular, but these approaches don’t really capitalize on the full value of BPM. 28. Companies that focus on automation typically do not use simulation and feedback loops into the process design. To move up a level in business benefits, consider using simulation as part of the process optimization effort. 29. Even worse, some companies only want to model processes and not put them into an execution environment. The models get out of date quickly and the value of doing this is very limited. 30. In contrast, some organizations want to move beyond automation and continuous improvement for a single process. They want to have process consistency across all instances of the process. For example, a company may have 50 different call centers around the world. Taking into account local cultural differences and laws, they strive to make the process the same in all locations. 31. Too many organizations just focus on the structured part of the process. You have to look at the entire process or the entire work environment, not just part of it. It’s critical to look at people (design for people, collaboration, social media, etc.), process (the ad hoc and structured process) and information (data and content and all the next social media artifacts). 32. Case management is the term that describes bringing people, process, information together to work on a case folder. 33. A BPMS does not require SOA to run, but SOA and BPM are closely linked, and BPMS deployments should use Business Services whenever possible. 34. SOA needs BPM to make Business Services actionable and relevant within processes. 35. IT used to resist BPMS. Now IT increasingly sees BPMS as a way to support rapid development, lower maintenance costs and cut into the maintenance backlog. If you have resistance from IT, use these arguments to persuade them. 36. BPMS products do not require an enterprise service bus component within the product; it is possible to use existing middleware with pure-play BPMS products. 37. Agile development methodologies are critically important for BPM projects. 38. Process wikis are a new and exciting way to design processes. They are lighter and easier to use, and often SaaS based. 39. Process modeling and data modeling initiatives should be aligned. 40. Master data management or data quality and BPMS deployments should be aligned because cross functional processes access data from different sources, and data quality issues often surface in the execution. 41. Workflow is not the same thing as a BPMS. Workflow is the forerunner to BPMS and mainly focuses on design and execution. 42. Some of the document management products only offer workflow, not BPMS. 43. The BPMS market is fragmented, with probably more than 100 vendors (that’s a guess on my part, not a fact.) 44. The BPMS vendors have different biases about how work is done that gets reflected in their products. It is vitally important to understand their history and philosophy of work, because it might not match yours. 45. The BPMS vendors fall into 3 camps: those that focus on processing documents or other unstructured content; those that concentrate on SOA, middleware and integration; and those that provide a rich work environment for people working primarily on structured processes. 46. The BPMS market is slowly consolidating through acquisitions; eventually the human-centric and integration centric markets will merge. 47. The document-centric market will take longer to converge into the other BPMS segments. 48. Business rules engines (BREs) are an extremely important technology for BPMS. In fact, BREs are more important inside BPMS than standalone. 49. Many vendors offer process templates. Sometimes these are a gimmick and sometimes the process template or framework is valuable. 50. Things to look for in a process template include: process models, best practices, sample code, and a bundle of processes that support an industry sector, not just a single process.
Connie Moore said about the list: "Hope you enjoy it and get value from it". Surely that is a nice compiling about BPM.