2. Business architecture and modelling fundamentals
3. Business process concepts and fundamentals
4. Business process management concepts and fundamentals
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 [url="https://twitter.com/go_BPM"]go-BPM in Twitter[/url], 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!
Then, if you want to advance to become a true expert, all you need do is read this Forum twice a week. :)
- Lloyd Dugan
- 2 years ago
I propose 2 approaches to someone wanting to study BPM :
1. start reading and learning the curricula for the [url="http://www.omg.org/oceb-2/exam-info.htm"]OMG OCEB[/url] 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 [url="http://www.discoverbpm.com"]BPM Mentor[/url]. 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!
However "If you think education is expensive, you should try ignorance".
A telling indictment of the state of the discipline and industry both.
[*] Relatively easy to do a quick web search and come up with a handset of sites, blogs, articles that would define what BPM is, compare and contrast them. Those definitions and understanding would provide further context to "Now, what do you need to do with this? What's your role in all of this?" I say that because the majority of the time, even in large organizations, project champions, sponsors - usually SVPs or CXOs - do a poor job of explaining to the masses, their troops, WHY the organization is doing what it's doing regarding an initiative or effort and getting the message out there. More often it looks more like a mandate coming down from on high because this SVP came from this org and they used platform 'X' there and now we're going to use it here and the grunts in the cube just shrug - more or less - and say "whatever," and go on about their jobs. Nonetheless, if I'm an end-user I'm going to have to defer to my management and the training I get and hope they ask me what the app actually needs to do. Every time you hear about a vendor getting a big implementation with a large client somewhere, they're usually getting kicked to the curb somewhere else at the same time, but you don't know or hear about that unless you're on the ground.
[*] If I'm a BA I go to the chosen platform's process design class. In fact I recommend to all clients that the BAs, the architect(s), the admins, the developers all go to the process design class. It's that class, irrespective of role, that for every platform ties it all together - how does THIS platform do it, how do all the pieces connect, how does it work under the hood - even if I'm not eventually going to be the person crafting the design. Meantime I start looking at and reading the chosen vendor's web site to understand their idea of BPM and how it's done on their platform. Understanding and knowledge breed consensus. I actually like Pega's philosophy on this in that everyone in the entire organization is a CSA.
[*] If I'm an architect, developer or admin (or all of the preceding) I go to the admin class and the installation class to see how this stuff is built - how it uses the database, how it uses middleware, how it uses LDAP. If I'm a developer I also go to the class to learn the API sets and what language(s) I can use (.NET, WSI, JEE, etc), THEN... I get my hands on an environment and I touch, work on the system because most people learn best hands-on. And I want, need that environment, even if just a sandbox, beyond my class attendance. Most orgs ignore that not only the developer teams need a dev or test environment, but the people running the infra need an environment as well.
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.
No disagreement to points one or two, have seen both myself multiple times. The problem with that is that most of the time, when needing to learn something new, for most of the crew it's after the fact. The exercises below are way upstream from the LOB, the user, the admin, the application or solutions architect, the developer finding out they're going to be implementing BPM on a given platform. The "discipline" as it were, is usually an afterthought, but that's a different discussion.
Per your points below what I actually see happen most often is:
1. A large LOB within the organization wants a solution and chooses the platform that solution. They make this decision without IT's participation, but the infra support gets pushed off to IT anyway (unless the LOB is outsourcing hardware, support and maybe even development to a vendor). Curiosity spread's within the organization, interest spreads and other LOBs jump on the bandwagon.
2. The one I see the absolute most is new senior management who came from another organization that used platform 'X' and they initiate a large effort at the new company to use the same platform.
Your examples below, even with their own flaws exposed, are more diligence than I've observed at most places and I've ran around in some pretty big organizations.
I am a bit skeptical about learning BPM (as a trio of discipline, tool and practices/architecture) through a BPM tool (even the best one).
A couple of examples:
1. During a demonstration of a real and successful BPM-suite based solution to a prospect client, the BPM and project leader (with the expert knowledge of this BPM-suite) didn't manage to explain why the business requested to implement a particular way of working (actually, some sort of a manual RALB).
2. A client wanted to know about advantages of BPM but without committing to a particular software yet. So, the EA group has implemented the same process (which is well-known to everyone) in 4 different BPM-suites and used these implementations to demonstrate various advantages of BPM. At the last meeting, the questions like “why do we need BPM?” were answered by the CIO!
- Dr Alexander Samarin
- 2 years ago
- 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.
Bravo for (1) being the first to mention logic, (i.e. "a logic course") and (2) "researching the industry", which I will take as "domain knowledge".
(A long time ago, logic was a core part of a standard liberal arts curriculum (from which we get the derogatory word "trivial", from the original "trivium", a core of three subjects including grammar, logic and rhetoric.)
It's strange to hear developers that don't have a basic foundation in logic; one can almost predict the mistakes. And then of course, marrying that to ever-deepening knowledge of the industry you serve -- unbeatable.
- 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.
"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: "[url="http://www.process-flexibility.com/index.php?id=237&tx_ttnews%5Btt_news%5D=30&cHash=c731d1bb59c12ab88bd33f4148861958"]Recommended BPM Books by Wil van der Aalst[/url]" (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):
[b]Business Analyst[/b]- 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.
[b]Technical Implementation[/b]- 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.
[b]Integrator[/b]- 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.
Great paper by Prof. van der Aalst! And well worth reviewing by anyone who wants to better grasp the direction of BPM technology for tomorrow . . .
"A decade of business process management conferences: personal reflections on a developing discipline."
The reprint is available at his Homepage: wwwis.win.tue.nl/~wvdaalst/
see publications -> #679 "A Decade of Business Process Management"
- Gary Samuelson
- 2 years ago
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:
[i]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 [quote][b]anemic side of design[/b]in that it's primarily used to
[b]encapsulate messages as apposed to fully describe object behavior[/b].[/i][/quote]
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.
- Page :
However, you are not allowed to reply to this post.