I always like hearing Michael zur Muehlen presenting: he’s both knowledgeable and amusing, and I’m sure that his students at Stevens Institute of Technology must learn a lot from him. Today, he discussed what every enterprise architect needs to know about BPM, much of which was focused on process discovery because of the link between architecture and developing models.
He looked at two of the common problems problems in process discovery:
- Process confabulation, where a person being interviewed about the existing business process “makes up” how the process works, not through any bad intentions but because they don’t understand parts of it and are a bit intimidated by the presence of a consultant or business analyst asking the questions. (This, by the way, is why I almost always use job shadowing for current process discovery, rather than interviews)
- Paper bias, where the automated process ends up mimicking the paper process since it’s difficult for the participants to envision how a process could change if paper were no longer a constraint.
There are a couple of different philosophies about process modeling, from only modeling processes that include 80% or more of the work in a department, to modeling everything in an enterprise process architecture. There are enterprise process architecture frameworks (what Michael calls an enterprise process map, or EPM) used by some organizations, where they have a template of the major processes within their company that can be easily applied to subsidiaries and departments. Not only does an EPM layout the major categories of processes, it highlights the integration points with external processes. There are also some industry-specific process reference models that can be used in some cases, rather than developing one specifically for an organization.
Within a process architecture, there are multiple levels of granularity or abstraction, just as in any more generalized enterprise architecture. One organization uses 6 levels: business activities, process groupings, core processes, business process flows, operational process flows, and detailed process flows. The top three levels are focused on “what”, whereas the lower three levels are focused on “how”, and there are defined techniques for refining models from one level to another. Hence an enterprise process architecture includes the enterprise process map (defining the major process categories) and the set of process levels (created for each major process).
As with any other type of enterprise architecture, an enterprise process architecture allows for easier collaboration between business and IT because it provides a common framework and syntax for discussions, and becomes a decision-making framework particularly at the lower levels that discuss specific technology implementations.
He went on to talk about SOA and some of the obstacles that we’re seeing. He made a very funny analogy with today’s complex home theater systems: the back of the device (with all the input/output interfaces) is like what the developer sees; the front of the device (with input selection functions) is like what the architect sees; and the remote control with single-button control to set all of the appropriate settings to watch TiVO is what the end user actually needs.
Keep in mind that customers don’t care about your processes, they care about the value that those processes provide to them. Having processes streamlined, automated, agile and encapsulated as services allows you to offer innovative services quickly, since processes can be mashed up with other services in a variety of ways to provide value to customers. The final takeaway points:
- Technology enables process change
- Processes define services
- Core processes become commodities
- Efficient process management crease room for problem solving
- Industrialized processes enable innovation
As always, you’ll be able to find Michael’s slides on SlideShare.