Perspective. It all comes down to what perspective you bring to the discussion.

IT view

An IT department sees process as business behaviors that can be automated by technology. Sure, they understand there are things that won’t be automated and will gladly make allowances for a manual process to be part of a flow.

The automation of tasks by IT is often referred to as workflow, and IT BPM products reflect the complexity of data and transactional flow. IT’s role began with the automating of bookkeeping in the 70′s, which is why the large technology consulting firms we see today, like Deloitte and Accenture (which was Arthur Anderson) were initially accounting and audit firms.

There’s nothing wrong about IT’s view and it matches the role they have in the organization…automate it, keep automation running, find new ways to automate.

Before I leave IT’s view, it needs to be mentioned that there are businesses that are so technology focused that their business view looks a great deal like an IT view. Consider a company like Cisco that produces technology solutions. While it may appear that their work is so slanted to technology that business and IT are the same, this isn’t actually the case.

Cisco still needs to perform a great deal of non-automated work that makes their non-IT functions much more similar to a non-technology provider. They need to envision business, create products and services, and then carry out their plan to market, sell and service those products and services. There are process models specifically for IT, and ITIL is a good example.

What is the battle in the trenches? Complexity that arrives in arguments such as ’swimlanes versus hierarchical process frameworks’. Swimlanes work well to show data flows, but are hard to follow as an end user. Hierarchical process frameworks aren’t useful for automating data and transaction flows. A great deal of the arguments around BPM come from this basic difference.

Business view

Business, on the other hand, is about taking revenue by providing a product or service. Technology provides the enterprise with a way to execute business, but isn’t ’doing business’. Take email for example…IT enables the organization to have an email system, and may even automate email by creating distribution lists, but they don’t write the emails (yes, there are system-generated and automated email responses, but that’s not what I mean in this setting).

That is a manual business activity that needs to be performed by an individual doing work. Business process in this context is about human beings doing the things that serve the business model of providing products and services. A great example of this view would be compliance, where people need to be doing very specific activities for an organization to be certified by an external body (like ISO).

Another would be the ability to know and perform a process as part of clinical trials for a pharmaceutical company…and doing it poorly has severe impact. Business requires humans to behave in a, common, goal-directed fashion that requires individualized knowledge of how to perform their work. The APQC Process Classification Framework was created with a business view in mind.

Where does the conflict occur? End user work, because it isn’t automated, is criticized as not being ‘executable’. It is different in kind from workflow that moves from step to step and can be measured as a ‘stream’ of activity. Humans don’t work that way, and the ‘execution’ of a human process flow doesn’t fit within the automation mindset.

Business architecture view

The most confusing of all views to the outsider, business architecture is the design of business functions in such a way that the ownership and execution of the means of producing goods and services is efficient and effective from a structure point of view. Architecture is about designing an enterprise that can produce outcomes based on needed capabilities. Architecture isn’t about managing processes themselves, though it may help in determining who owns process and where those processes are executed.

A business architecture provides a way to organize an enterprise so that it can succeed at its goals by being effectively managed and accurately measured. By having a business architecture, there are relationships between different workstreams that are coordinated so that individuals, teams and divisions of the enterprise can work together, and so that IT can serve the data and transaction needs of those groups. Business architecture is an overlay of order on what could otherwise be chaotic.

Cisco is a great example here, where they use an architectural methodology from Proact known as BOST (for Business, Operations, System and Technology) that looks at four aspects of business architecture that all need to work in harmony for an organization to be healthy. Take a look at TOGAF as another example to help explain this.

Where does the conflict happen? Architecture frameworks versus end-to-end process flows. A framework provides the ability to manage complexity, but it doesn’t get the actual work done. Whether the architecture actually ‘works’ or not isn’t being directly tested in the day-to-day work being done.

Back to BPM

Business process management, then, is a combination of all three of these views. An efficient organization needs to have, 1) an overarching framework that delivers business capabilities, 2) systems to automate and manage data and transactions, and, 3) a way for users to have a simplified view of the world that is role-based and can follow process end-to-end. Can this all be done well in a single system (this is literally the million-dollar question)? Unlikely.

The software products that perform each of these steps well are diverge in functionality, interfaces and audience. The software can integrated so that information is linked between differing views, but at its execution, it is carried out in different ways by different people. I can’t force my business to take an architecture view of getting work done any more than I can make my IT department work with simple boxes and lines to express an application’s data flows.

Much like building a house means something different to the architect, the contractor and the customer, BPM means something different to everyone. By understanding this, we can move forward as a healthy ecosystem.