50 Things I Know About Business Process Management

Connie Moore By Connie Moore

I just got on Twitter yesterday. My Twitter handle is “cmooreforrester”.  Wow, what an experience.  I had 54 followers in 24 hours, and now have 83 followers in 2 days.  In honor of the occasion, I thought I would write the 50 things I know about BPM, in 140 characters or less for each entry.  (OK, don’t hold me to the 140 character count; I didn’t count the actual sentence length.)  Hope you enjoy it and get value from it. The 50 things I know about BPM:

  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 processes, 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.  

Categories:

Comments

re: 50 Things I Know About Business Process Management

Nice post and good summary of points about what BPM is about !There is one point that I would like to comment and a new one that I would like to add :-)- Comment: I'm not completely agree with point 6 "BPM projects should be led by business, not IT, to avoid failure".Most of the BPM projects are in fact small applications that are developed by IT teams, same way than any other application in a particular organization.I agree that big BPM deployments must be driven by business people but in my experience most of the BPM projects I see are handled by IT teams. IT teams has already accepted BPM solutions as part of their day to day technologies (i.e database, web frameworks...)- Point 51: As is already the case in other markets (database, BI, portal, CMS...) the BPM market will know key open source actors that will change the way to bring BPM solutions to organizationsbest regards,Miguel Valdes

re: 50 Things I Know About Business Process Management

Thanks Miguel for your comments. I thought long and hard about the point that business should lead BPM projects. I think the main point is that I was referring to BPM the discipline rather than BPMS implementations, which I think must be done jointly between IT and the business.I definitely agree with you about open source eventually making its way up the stack to higher and higher levels of functionality, but I haven't seen much open source BPMS adoption yet with our clients. Don't really know why that is.

re: 50 Things I Know About Business Process Management

Hi Connie,I'm meeting with a lot of customers that are looking for open source alternatives to commercial BPM vendors (specially now with the economic difficult times) but most of the open source solutions are not yet offering all the required fonctionalities expected by customers.Most of the open source BPM solutions are in fact providing a really good engine but not yet the kind of advanced graphical environments expected by customers so this is still the gap.BTW, after years leading an open source BPM engine solution I'm just founded a new company with the goal to bring to the market such an complete BPM solution in open source.best regards,Miguel

re: 50 Things I Know About Business Process Management

that's exciting. I agree with you; the open source products need strong support for business people (e.g. user interfaces, reporting & analysis) to have true business appeal. Keep us posted as your company makes progress.

re: 50 Things I Know About Business Process Management

Great post! I agree with everything that you say except for item 25 "Process versions should take less than six months to develop and deploy".Six months is setting the bar too low. I recently gave a presentation on SaaS BPM technologies to a group of MBA's and mentioned that I suspected one of the reasons they were choosing SaaS vendors is that the people who caused them the greatest frustration were not their external competitors, or internal rivals, but rather.......I did not even have a chance to finish the sentence. The entire class yelled "THE IT DEPARTMENT". Well, the entire class apart from two IT guys who were visibly startled.This set off a lively discussion that was summed up by an exchange started by one of the poor IT people who remarked that his users must be happy because IT rolled out a new iteration of system X every two months (I am not going to mention the name, but for a product like X, two months is a truly heroic achievement!)Well, he got crucified. "Two months! Don't you understand anything? When I need a change, I need it the next week. Maybe I can live with two weeks, but two months? And you're proud of that?"The entire economy can go from boom to bust in 6 months and this will flip priorities 180 degrees. Unless a company can adapt to changing circumstances in a matter of weeks, it will certainly be caught wrong-footed and may not even survive. Certainly CIO's who cannot provide the kind of response times that the business needs will not survive.However, dynamic technologies such as Java, open source technology stacks and powerful commodity hardware are making it possible, build, implement and modify business processes in a matter of days, rather than weeks or months. My own company provides a browser based tool in which you can implement or modify a business process in a matter of minutes as illustrated by http://www.enterprisewizard.com/flash/WorkflowDemo.html and I am sure that our competitors are working to catch up.Business Process Management is finally coming of age with tools that allow IT to meet the expectations of the business community and reduce the cost of developing or modifying processes by an order of magnitude. Process automation is no longer an impediment to adaptability, but an enabler.

re: 50 Things I Know About Business Process Management

BPM from a software perspective will always be attempted (and achieve the most success) by leveraging the technology you have "in house" to accomplish your BPM goal. Companies who feel they have to adopt new technology to successfully execute BPM will see any potential benefit drowned in a sea of up front costs. Build your BPM strategy with what you have already bought and only contemplate change if you see issues in regard to flexibility, re-use and/or speed of response to business change. That being said, then the real "value" in BPM comes not from the software or applications but from the processes which you execute on top of your software applications and the way you manage continous process improvement.

re: 50 Things I Know About Business Process Management

One of the key issues we encountered is finding process flows and models we could use to start our business process projects. We found a great repository for process flows (which seems to be new but getting more flows added every day) at www.processgenie.com in their "Process Marketplace."

re: 50 Things I Know About Business Process Management

great comment, Colin, about 6 months being way too long. I agree, and the point I made needs clarifying (I was working hard to make Twitter length comments and didn't go into detail, but should have.) Here goes:BPM is about continuous process improvement. That means when you first deploy your process version, it is good--much better than the "as is"--but not perfect. The idea is to come up with subsequent process versions that improve upon the last. These new process versions are typically rolled out every 2-6 months. In the meantime, there are lots of process changes that need to happen every week. The kind of little changes I'm talking about are bug fixes, variable changes, business rules changes, etc. These should be done in 1-2 days (remember, there is testing.) Most companies I've talked with have a process governance meeting every week or every two weeks to identify the big process changes and the little process changes that need to be made. The little process changes can be made the same day, potentially, depending on the practices the organization has in place.I hope this clarification helps.

re: 50 Things I Know About Business Process Management

Thomas, I agree with you that the real value from BPM comes from the process improvements, not the technology. However, I think that sometimes you need to bring in BPM suites to get the job done because your internal vendors may not have a strong enough BPM product. For example, SAP may be your strategic vendor, but its BPM strategy has been poorly executed and it might not be a good platform to build upon. Or, for example, IBM may be your strategic partner with 2 different BPM offerings, so it may be a good in-house vendor to build upon, although one of its BPM products is very integration focused and the other is very document focused. You may have to work harder with the IBM solution to make it support human-centric processes than you would with a BPM suite from one of the pure-play vendors. I think the decision to partner with existing vendors or to bring in a BPM suite provider depends on which vendors are your strategic partners--it's important to recognize that some are strong in BPM while others barely have a BPM offering.