I learned about systems and processes studying for a biology degree.
I'm not suggesting that biology is the only, or best, place to begin learning about systems and processes, but that there are a variety of potential starting points for learning about BPM, none of which involve software or technology.
Any area of study that fosters a mindset for analytical and systemic thinking is probably a good foundation for BPM.
If you are at the University, you should take a course on BPM; it will help you to cover the main topics, in a structured way and in relationship with other knowledge fields as SOA (Application Integration), Enterprise Applications Architecture...
If you are already working in the IT industry, you could assist a BPM Event or Seminar, but we recommend to do it that after you already get some basic knowledge of the field. Reading a BPM Book covering in amplitude (not depth) main topics is a good idea, and then assisting to a seminar to share real world experiences.
Finally, reading this Blog periodically and following go-BPM in Twitter, is the best way to keep updated on the BPM field.
Remembering “BPM” is a discipline, a principle coined by “IT” in context of People need to be “recognised” as the creators of all information in a business. So to “learn” is relatively simple with the understanding how people work. I never really had any formal training when in the ’70s as an auditor we mapped out how information was created. We were given a plastic template with symbols representing different steps and thereafter it was talking to people to extract exactly how the “system” worked and physically mapping out on paper! It is that simple!
It was a highly effective way to spot weaknesses where the audit could focus and adding value by making recommendations to management where “weaknesses” could be improved. So in late 90s as “BPM” followed up on “workflow” it just seemed so natural and simple. BUT by then IT had imposed “processing” power which had such inflexibility and very poor business user support that had created a gap between business and IT. It was seen as a challenge trying to mould these silo driven systems to reflect how business really worked. Spreadsheets and off line small databases thrived filling that gap. And so “BPM” had a role to try and fix the legacy”mess”.
Mapping out processes began much as undertaken in the 70s but frustration with the then dominant IT systems held back progress. Never the less this “BPM” approach persevered and software to support mapping matured and some early tools to help convert into some basic applications. Now that move has reached a tipping point allowing the “BPM” skill set to directly create next generation applications which now wholly support the real world of work supporting people.
Taking that big step to ”digitise” is no longer that IT smoke and mirrors and complexity with fear of delivering change. Just remember legacy becomes the slave to this new digital capability that breaks down the historical silos of structures created by the early IT systems.
If you understand all this that’s it you are ready to deliver BPM to the organisation! It is much more about your people skills a good listener, a logical thinker and a thought provoker as real users tell you how they work; the good rewarding aspects as well as some of the nonsense they are forced to live with!
I suggest first to understand the meaning of process, which word comes from latim ("processum") and means "advance", "move forward", or set of measures to achieve a certain goal. Based on this definition, we can apply the process concept in many matters, e.g., biology, mathematic, research, culinary, etc., and business management of course. At BPM, understand why the management by processes can be much more efficient and effective in using the available resources to achieve the business goals, instead the traditional management by functional areas of departments. Based on it, we can better understand that the way to do the things can make all the difference, e.g., what is the better sequence of activities, main decisions, the better resources to use in each activity along the business process, etc.. Afterwards, we have a lot of seminars, books, articles, etc., in which we can learn more with the presented business cases (specially be attent to the achieved business results), etc..
The truth is, most people don't learn BPM until their job requires it. In that case, the best bet is nearly always training directly from the vendor. But the background you bring to that training matters a lot. Solid business analysis skills and strong technical (not necessarily including coding) and problem solving abilities will be crucial. In short, you want to walk into the room with an understanding of how to identify and address business issues, along with the technical capacity to learn how to use the technology.
Then, if you want to advance to become a true expert, all you need do is read this Forum twice a week. :)
I propose 2 approaches to someone wanting to study BPM :
1. start reading and learning the curricula for the OMG OCEB exam, first Fundamental and then, depending on the path, Business, Technical or both. Advantages: no pre-requisites, really everything you need to know, cheap - but do not be fooled - not easy to pass the exams !
2. taking one-on-one lessons with BPM Mentor. Advantages: you discuss with someone experienced that can tailor the sessions for you to gain the maximum out of your time, you are assessed by the Mentor against your objectives set at the beginning and guided on the next steps, price is negotiable depending on the mentee's needs
But ... the best advice I can give to someone wanting to study BPM is: after learning some, start asking yourself what can you bring to the table :-) Good luck!
Interestingly a high proportion of attendees at the Gartner and Forrester BPM conferences are newbies. Certainly you get a broad view of the different perspectives of BPM at these event in a very short space of time plus as an attendee you can have 1 on 1 with analysts. But attendance is not cheap.
However "If you think education is expensive, you should try ignorance".
Learning implies desire, need or both. Avocation or vocation, but most of the time usually need. In that context, the following regarding goal(s), roles and responsibilities:
Rinse, repeat, drill down from there. Definitely start hanging out in vendor communities at the very least so I can read what others are doing, what heartburn, challenges they're experiencing, extrapolate to what I'm trying to do and, hopefully, avoid the same problems and learn from others.
If equally tempered with avocation as much as vocation read, read and read some more, anything and everything I can get my hands on, and let my learning send me in additional directions beyond just the immediate task at hand, because there'll be another job, task after this first one. The more you know, the more you can do.
Certs are for fun and demonstrating competency later, but some people's are harder than others. ;)
Just my tuppence.
hmm, I would start with researching the industry, become familiar, learn the evolution of the practice, etc. along with...
- take a logic course with emphasis on information technology
- take a 101 business management course.
- hang out here, join other BPM discussion groups
- give a try at documenting my workflow as it passes through the company value stream. This would be a great opportunity to create my own project, while learning corporate politics - slightly off track.
- learn one or two of the mapping applications
- read BPMN 2.0, keep current with BPMN.org
- Find a mentor and read what he reads.
What I would recommend:
- read BPM CBOK (Chapter 2 as a minimum)
- take an introductory course, e.g. BPMInstitute's BPM101
- take Bruce Silver's course on BPMN
- find a job that both requires BPM knowledge and provides BPM education
What I'd recommend to keep away from:
- learn BPMN by reading the OMG spec
- get BPM education from a vendor
There is no such thing as BPM vendor because BPM is not a software.
[above] Anatoly - Fully agree.
"There is no such thing as BPM vendor because BPM is not a software"
-- Slight difference is that I would first start with the BPMN-2.x specification (seriously...), then Bruce Silver's book , and for a very good vendor-oriented perspective (hands-on and open-source), Real-Life BPMN by J Freund and B Rucker.
More detailed guidance...
For all who-want-to-learn... please see: "Recommended BPM Books by Wil van der Aalst" (google it) or follow the link.
A few more words on this topic... you must segment your interest into at least one of the three groups (perspectives):
1) Business Analyst - focus on the BPMN specification and download/read/become-familiar with the notation. You MUST also have a background (subject matter expert or SME) in your chosen business: commercial banking, finance, health (etc.). See above link for BPM books. But, focus is on business-change and process management (BPM-free... so-to-speak) prior to adding on advanced layers of perspective and approach. Important to realize that BPM is a culmination of needs/practice. Without perspective you won't see necessary and foundational values behind the BPM practice.
2) Technical Implementation - Do step #1 above (if you want to earn your "chops")... Otherwise, just read the manual and practice - realizing you'll more-often take the team off-course than actually do anybody any favors. Reason for this, somewhat harsh, view is that BPM is not SOA nor BPEL. Most beginners simply do BPM as an act of software development - and this is very bad for project outcomes.
The books for a Technical Implementation team: See above link... and focus on Bruce Silver's BPM Method & Style book, BPM Handbook, and others vendor specific: IBM, Camunda, Activiti, etc.
3) Integrator - Big shift in perspective on the integration team because at this stage you'll be looking for mature SOA architects and developers - folks with proven track records in managing complex, long-running, multi-channel transactions and transformations. They don't necessarily need to necessarily know BPMN/BPM... but it helps immensely. Your SOA experts are generally smart and will most likely spend an evening reading the BPMN standard and various vendor documents during project ramp-up/discovery phase. Key is that you MUST have senior, experience SOA professionals on your team... critical success factor.
Or...you can take BPM training (inclusive of BPMN and Bus Arch) and forthcoming ACM training (inclusive of CMMN) from me, which is offered under the BPM.COM brand for stature. Really, there are training alternatives out there, but book learning is rarely enough. Practice. Engage. Train.
Almost all the great topics required for "learning BPM" have been covered. Especially I vote for anyone who mentioned "systems thinking", and for Stephanie's comment on "logic".
But if we consider the original question as asking more generally "what are the domains of knowledge that one has to know to be good at BPM", then I will add another topic. And it's one that I'm sure everyone will agree is essential.
It's essential for the success of any BPM program that the practitioners be good at data modeling.
And we can take data modeling at its most general to range even starting from ontologies, through conceptual modeling, to standard data modeling and ending up at database management.
Today one can no longer assume (if it was ever true) that an IT department has a reliable capability for data modeling and data management. This problem is multi-faceted, including education, the capacity for any one person to know all the technologies required to thrive in IT, prejudices and fads against relational database, IT and business governance and budgeting questions that resist investment in data management etc. etc.
Even if one is only building business processes on top of third party data models acquired as part of an ERP application, a deep understanding of the semantics of data management is critical to BPM success. Business process complexity can escalate when data is "not clean", i.e. multiple versions of the same data have to be kept in sync via kludges. And the eventual result is increasing cost to deploy any new process. Data modeling is where business semantics, i.e. "the meaning of business information resources" are first defined. Data models are therefore the foundation on which the entire edifice of business systems, including business processes, are constructed.
It's possible that everyone will say to me "well, certainly data modeling and data management are foundational and essential -- it's obvious and doesn't need to be said". My point is that we should in fact call it out. And probably spend more time on it.
Thanks for pointing out the dependency of semantics and data modeling.
I just recently ran across this topic during some independent research/writing. However, I've found a different relationship between data and process modeling. This received my focus because my work tends to be more on the implementation side of things - hence, business domain ontology plays a critical role on BPMN (model) run-time development. Task relationships thus requiring semantics to help both preserve and define the "business conversation" represented between each while execution (token) flows through and between process instance(s). Highlighting the integration side of my work, expressing process and task interaction between effort (BPMN model) and underlying system domains (back-office app', services, database, rules, etc).
However... from a formal process-management perspective, "BPM does not describe the task logic, only the process logic" (B Silver 2011). This exclusion of task-logic from the process model implies an intentional omission of our business domain ontology - meaning that proper BPM (defined by BPMN 2) is not concerned with detailed process and business data. Focused instead on process information, we intentionally leave off internal activity/task logic and its semantic details.
So, I found myself in a corner... leaving BPM related data modeling and semantics with the following thought:
This topic (BPM and data-model/domain) is a little confusing due to overlapping definitions (and potential misuse). For the context of my remarks, the business domain is synonymous with "enterprise ontology". "Business model" is a close second in describing our ontology (i.e. schema). Problem with all of these terms is the overlapping "domain-driven" methodology which holds great importance to an object's behavior. For BPM, our domain model leans more towards the anemic side of design in that it's primarily used to encapsulate messages as apposed to fully describe object behavior.
Ergo... turn BPMN modeling tools off and swivel over to UML/CASE (process modeling vs system architecture).
Given the ubiquity of "domain driven" and "object oriented" discussions there's a lot of material on topic (e.g. object-oriented, UML Unified, Jacobson, etc.).
See also for "business domain ontology" (my interest on integration):
Albani, Antonia, Jan LG Dietz, and Johannes Maria Zaha. "Identifying Business Components on the basis of an Enterprise Ontology." Interoperability of enterprise software and applications. Springer London, 2006. 335-347.