What's BPM and what's in your process portfolio?

I had a funny discussion with a collegue on BPM and the contents of your process portfolio.
He, being a bit new to the area of BPM, first asked me to define it. Well, I used an old definition and talked him through the following story line...

"Hm, BPM. Business process management. Can you define it?"
"Well, sure. You know financial management?".
"?? Uh, yeah, of course, that's been around for ages"
"Ok, well, what is it, financial management?"
"Duh. It's taking care of your money".
"Hm. How?"
"Well, all sorts of concepts, techniques, organization, people, sometimes IT, so in total a lot".
"Explain?"
"Well, cash flow, boring accountants, activity based costing, accounting, budget, budget review, balance sheet, general ledger, accounts, and of course people, some activities, and they usually have some of this stuff automated in a financial system. Oh, and they have al kinds of techniques for investments, business cases, ROI, EVA, etc".
"Wow, you really grasp that. So, it's a lot of things, aimed at taking care of your money, right?"
"yes!".
"Why?"
"Well, otherwise the company would go broke. That's why!"
"Ah! Excellent. So... money seems an important resource. What other stuff do you see as important to manage?"
"Uhm, let me think. Well, people (ah! human resource management"), risk (ah! Enterprise risk management), uhm, products! (ah, product life cycle management), oh and of course customers (crm).
"What about process?"
"Hm. yes, those too - if your processes are bad, no money will flow, people will leave, products will not develop, risk will run around, and customers.... well, you won't have them"
"So, there's your BPM, BPM is a whole lot of stuff to take care of your processes".

So, the discussion continued...

"So, can you tell me about this BPM. I understand Financial management, but I guess BPM has other concepts"
"Indeed. In BPM we have....
- A process portfolio
- Proces models (of all important processes in your portfolio)
- Proces owners
- KPI's for some or all processes
- A process life cycle approach (from define/discover, analyse, model, implement, measure to improve, innovate,and phase out)
- All types of practices around these life cycle steps
- People with specific skills that takes care of process modeling, consulting, and helps to improve them
- Automation for process modelling, measuring and sometimes executions"

"What's in this process portfolio?"
"All the processes you have identified, and you feel strong about"
"Can you name some?"
"Sure,
- Operational processes (procure, pay, build, market, sell, deliver, invoice)
- Product lifecycle processes (invent, develop, test, maintain, phase out)
- Management processes (operational, tactical, strategic)
- Supporting processes (IT service management, HR, Finance, Risk & Compliance, etc).
"
"That's it?"
"No, there is one more. It's called your Change process"
"Change process? That's not a process. That's a project!"
"Oh, is it? I bed that everytime you adapt your company to new markets, new regulations, new risks and new chances, you take simular steps".
"Well, yes, but..."
"And that around these so-called projects, you have processes to select yearly what changes to do, what projects to run, to measure, re-evaluate, etc?"
"Hm, yes, but..."
"And that, if you would really succeed at being great in change, all your people should be able to understand and take change steps really good, by repeating this proces?"
"Yes..."
"So, it's a process. A process that delivers change to your company. And you should know it, measure it, improve it, manage it. Like crazy. Because if you don't, all the other stuff doesn't matter".
"He. It's the same as an important concept in Financial management! The only way to really take care of money!"
"Which one?"
"To Invest!"

"you got it :-)!"






-

Requirements - need for new approach

Been doing some consultancy for a client, around the processes dealing with requirements. Yep, that's process management as well - making sure your innovation processes are able to capture requirements and initiate and guide change effectively and efficiently.

My client is struggling with two things:
- A large application, which misses a lot of baseline documentation (what else is new...), and no clear approach how to capture requirements for changes
- An unclear link between strategy/business drivers, business processes and the IT functionality to support the processes

Let's start with the first one - requirements methods for maintenance situations
It's amazing to see how little one can find on requirements management and engineering for existing applications. Sure, tons of stuff for "green-field, let's create a new application, with a great set of requirements". But honestly, how many times does that happen?
Right.
(One article I found was a good start, and I recommend it - www.processimpact.com/articles/reqs_not_green.pdf )

What is needed is a better, common way, of dealing with the requirements around an existing system. And how to define changes - so that business knows that it asked the correct things, designers/developers know what to build, testers know what to test (next to regression testing), and change management knows what to prepare the business with.
Something a bit light and agile (you know how many requirements an average system contains....many!) And.. With a clear process and clear artifacts.

For now, we came up with:
- Identify required change source, stakeholders and business drivers/strategy
- Understand requirements of change, in terms of changed/added/deleted
=> business requirements (e.g. what does the business want to reach)
=> process requirements
=> functional requirements (global and in the form of use cases or a functional decomposition)
=> non-functional requirements
=> information model
=> business rules
- Determine impact and possible solutions. Perform trade-off analysis
- Decide on scope and plan the change.
- Perform usual IT activities (refine, design, implement, test, etc)

Insights welcome!

And now the second one - the missing link between business intent, process, requirements and IT.
Most requirements methods are still focused on what I call "features". A business analyst will talk to users, understand processes and data, and will come up with a solution, expressed in a list of "the system should .... feature X". So, in the end we understand what functions it needs to do, maybe even understand the tasks they relate to, but we lost the link with process and with business drivers/intent.

What I hope, is that requirements methods will evolve, and will start linking to new developments in thinking around business architecture and process architecture.
In the end, we mainly build IT systems to support actors within businesses to perform tasks, that are executed in the context of processes!

So, what I would like is to see the convergence of:
- Business architecture concepts:
- What business intent/strategy do we want to implement?
=> Principles
=> Execution Objects (could be people, IT)
=> Data Objects
- Process architecture
=> What processes are needed to execute and deliver the strategic results?
- Requirements
=> Linked to process steps: this step, we want to automate, and it will require XYZ....
Hm, you might even call it: BPM driven requirements methods!

Again, comments welcome. I am puzzled by the naivitity of current requirements methods.

With BPM technology towards supportive, context-sensitive end-user applications

Picture a complex application, full of user-oriented functionality. Thousands of forms.
An ERP system. Or some custom application for pensions, complex trade, transport, etc.

Now image the time, the training, the effort people need to get used to the user interface. To find their way to the correct windows, menu's, dialogs. Quite a challenge. And imagine users in a situation where every X months new features are rolled out. For a new product, a new service. A new menu item, hidden under three layers of other menu items.

And so, think of the amount of process tasks people are performing daily. And then the amount of time they need to...
- Understand the context of a task
- Remember what functionality to use to perform the task
- Navigate to the correct functionality
- Remember how this all works and how to perform the task...
All this, eevery day, every time a new task needs to be done...

Now let's look at what BPM technology can deliver, together with more smarter/opener, let's say service based applications (and possibly some rulebased layer, or context engine)

A process is started in a BPM engine. A task is delivered to someone's inbox.
The person opens the task, and wants to perform it.
And the task has knowledge. It knows its context! So, why not let the task tell the application?
E.g.
- User opens inbox
- User selects task to execute
- Task informs application (through a context engine) what is needed from the application
- Application shows just the functionality/windows needed for the task
- And if needed, shows detailed instructions, based on the task context

Basically: the context-sensitive application.
No more navigation. The task will lead the way. And the user gets the right information and functionality at her/his fingertips.

Result:
- Less unneeded navigation, getting lost, mouse clicks, etc.
- Faster processing
- Reduced training cost

But, how do you train someone new? Or when a trained person gets a new task, or needs to use new functionality?
Well, the BPMS can tell (BAM) that a certain task has never been performed by a certain user. So the BPM-S or an trainingmodule can warn the user, provide computer based instructions, and guide the user through her/his first time. And if needed, again, and again (e.g. task inbox item should have a button saying "I need some help with this"). That's what I call supportive.

New RSS feed available (full articles)

As a result of Sandy's tip (http://www.column2.com/2007/07/links-for-2007-07-02/), I have now added an RSS feed with full articles. (And gosh, a quick search on Google showed me that there is a large discussion going on, on full or partial publishing. Hm, I vote full... ;-))

And: Other tips and comments always welcome!

Regards,
Roeland

(Just back from a lovely vacation in Italy - when in Umbrie, don't miss http://www.sanpietroinvalle.com/eng/, but don't tell others!)

From interface spaghetti to process coordination layer

Remember the old days of system integration?

Requirement: When we have done task X in application A, we need to send data to application B, so we can continue doing stuff.

Solution: we create a system to system interface.

Purely datadriven. As an example:

- We enter an order in our ordersystem

- During the night, a batchjob will wake up, and send the order data to the invoicing system

- The invoicing system will send an invoice and update general ledger

In diagram:

The results are known:

- Many interfaces, spaghetti

- Applications become coupled, having knowledge about eachother

- Many types of technologies for integration (file/FTP, messaging, API calls)

- A system is responsible for only part of a process (do + send).

- When exceptions arise - who will fix? Extra knowledge of system B in system A.

- Process understanding disappears from business to IT (and from IT to technical batch schedules, that no-one really oversees)

- Difficult to maintain, a change leads to changes in many systems

- Many different ways of reporting status and issues (leading to tons of paper output that no-one dares to read or check...)

And of course, we have tried. We invented EAI. Companies bought ESB's. The result: the same spaghetti, but now standards based.

The lesson: put the process back in the solution. E.g. don't let systems do hand-offs, but let a process coordination engine do this for us....

The solution now looks like this:

Advantages:

- Clear process

- Part of exceptions can be handled by process engine itself

- Other exceptions can be forwarded as manual tasks to business and IT without additional changes in systems

- Systems are decoupled and have no knowledge of each other

- Integrated, process based (in stead of integration based) reporting

- Information flow can be real time (or can still be done in batch)

Realize - this should change your thinking. Don't think interface, think process:

Requirement: we want to correctly sell and invoice our products (process). As a first step, we want to capture order data (step in process). After that, we want to generate and send an invoice (step) and update this correctly in our general ledger.

Solution: define the process, link the process and the solutions for the steps, and use a process coordination layer.

Take-aways from a Microsoft BPM Seminar

Recently I visited a seminar on BPM, organized by Microsoft and some of it's partners from the Microsoft BPM Alliance (in this case Ascentn, Ruleburst, IDS-Scheer and Amberpoint).

Ironic: the seminar was organized at the premises of the owner of Cordys, a direct competitor in the field of BPM-suites.
Another irony: while most Microsoft talks were about 30 - 50 minutes, each vendor was only allowed to speak for 10 minutes. How's that for powerplay. And that was unfortunate, because these partners seemed to understand BPM much better....
A bit scary is the strength of these parties in The Netherlands. When asked, most of these partners had only 1 or 2 implementations in the Netherlands.
Last.. I was surprised by the amount of people (about 100). Not bad for BPM.

On average, the BPM seminar was oriented at a fairly technical audience. Most talks were about SOA, services, engines, etc. E.g. not much attention to BPM as a business discipline. And as result, most talks were based on "if you built it, they will come...". Hm.

The typical SOA/BPM slides came along:
- Services from legacy and other apps
- A process layer to coordinate services and deliver outcome
- Business rules to drive decisions
- BI/BAM for process measurement/reporting
- Multichannel presentation layer for human interaction

And the typical promises on business case:
- Agility, nicely coordinated, loosely coupled...

It was nice that some anti-patterns were discussed:
- BDUF - Big design upfront , were architects design the grand future from an ivory tower
- "Buy an ESB and everything will go smoothly"
- Hacking it from the bottom-up

The suggestion was: Middle-Out, think big, act small, take incremental steps.

Two great presentations were given by David Chappel (http://www.davidchappell.com/blog/)
Some of his key statements:
- SOA has been around for years (DCE, Corba, COM). But now, with standards in place, we can really get it going (SOAP, WSDL).
- RPC standards are in place. However, a good standard for messaging is still missing.
- Reuse is unfortunately NOT the key business case driver for SOA. Did we ever leverage reuse that much? Remember OO? SOA's key driver is Agility. Reuse is limited to technical services, not business services.
- UDDI is a dead-end street. Nobody uses it.
- Business people developing and maintaining their own processes in a tool for execution - it is a myth.
- Business does not care about SOA.
- The future of Java is at risk. There is no clear process execution framework and infrastructure for Java, while Microsoft's Net.3.0 has this built in. In addition, there is no clear solution for business rules (repository and execution), where Microsoft has many.

He also went through the Microsoft technologies relating to BPM.
- Biztalk for system-2-system orchestration, with Workflow Foundation
- Sharepoint for Human processes
- Integration with browser and Outlook
- Ability to create process aware applications based on Office (OBA - Office Business Applications based on MOSS - Microsoft Office Services System)

An interesting thing was the Sharepoint Designer tool. Although only shown shortly, it was interesting to see that they had choosen not to use a traditional procesmodelling tool (activity, arrow, etc), but a rule-based (if XYZ happens, then create action ABC for person D), comparable with your "email rules".

I liked some of the collaborative options, with the integration of Outlook. For instance: define a proces, where a task will automatically schedule a meeting with certain stakeholders, to decide on a certain issue for this process.

But.... a key issue. If you want to define a business process (and rules) using Microsoft technology, and this process covers both System-2-System and Human workflow, you will need to work with 2 tools, and you will not have an integrated procesmodel.....
Microsoft and David did not see this as an issue "as there are not many other vendors that are supplying integrated process tools".

My soapbox...
I think they are wrong... In my opinion, this seriously limits the position of Microsoft in the BPM market. It leads to multiple technologies, competences, maintainance (2 repositories), and issues around BAM (where to measure what?).
They also said this themselves - MS will probably integrate the models.
Strangly, no word about Visio, which is I think a large player in the process modelling area.

Funny is that this lacking also explains partly the partner-strategy. But I wonder what will happen with the Alliance as soon as Microsoft has extended their capabilities.
In my view Microsoft is simply late, tries to compensates with partners, and will get back on track in some time. And some of the partners are so small in terms of ability to execute, lacking succesful implementations, I wonder who will go for these partners.
And as usual, no clear position on BPMN and BPEL (although BPEL seems to be supported end of this year...)

Take-aways from BPM-Forum session

Recently I visited a session of the Dutch BPM-Forum (http://www.bpm-forum.org/), where a dutch Insurance company talked about the implementation of a BPM tool (in this case http://www.cordys.com/) for a claims handling process.

Some key take-aways:

1. In the experience of the insurance company, in the end, the tools were NOT the issue. Most time was spent on understanding processes.
In my view, this is essential. Many vendors claim that their tools can do magic. Well, sure, but you still need a lot of work trying to understand and correctly model the processes. Business analysis is a key skill that you need in a BPM project, so be carefull with BPM projects run as an IT powerplay.

2. They understood that the processes they were trying to model, where too difficult to define in a sequential flow model. There were too many exceptions and possible events with unpredictable timing. They decide to take a Case management approach.


A great pictore from vd Aalst (professor on BPM at Technical University of Eindhoven, The Netherlands) that was used:


Also see: http://is.tm.tue.nl/staff/wvdaalst/workflowcourse/slides

My lesson: start with processes, and be very aware of the complexity. Don't use a modelling tool to understand the processes (because it will make you see reality through the limitations of the tool), but first seek to understand more freely. Then make the call if this is sequential/decision stuff or more complex event-based/collaboration based stuff, and pick the right tool for modelling and execution for that.

3. Essential for the business case, was the ability to use existing functionality. They found ways to abstract and use services provided by the legacy system. This allows them to use current investments, while opening the possibility (through the abstraction) to stepwise replace legacy with new technology, as long as it delivers the same service.

4. A good strategy was the focus on external partners. Part of the strategy, from the start, was the ability to integrate (from a process and BPM-suite) perspective with events and processes from and to other players in the service chain.

5. They kept Content solution and Process solution separate (but did integrate it).

In my opinion important. Currently some businesses invest heavily in ECM solutions and take a document-centric approach to process, implementing process in the ECM tool. In my view, documents are a temporary solution for information exchange. So, base your proces engine on proces, and let it integrate with information providers, including unstructured/ECM suppliers.

Functional or process oriented? Or is there a 3rd way?

Now, with the increased attention to BPM and processes, many companies are asking themselves: should we organize through function or process?
Some choose to stay in functional units, but increase the collaboration and create end-to-end governance and measurements (with often much politics).
Some turn the company sidewise, and create a more process driven organisation.

Of course, most of us understand the thoughts behind this.

Functional:
Pro's
- Focus on competency
- Easy to bind people - sharing the same work/chain unit
- Focus on scale efficiencies
- Relatively easy to measure
- Relatively easy to understand

Cons:
- Loose of focus on the complete chain
- Chance that units strive for suboptimal choices, that effect overall process effectivenes, efficiency and responsiveness (agility)
- Difficult to implement new or changed processes
- Pointing to each other when issues, no clear process coordinator

Process:

Pro's
- Focus on end-to-end responsibility
- Grows understanding of the full chain
- Outside in thinking , customer focus easier to keep
- Easier changes to processes
- Reduced or no interdepartmental hand-overs

Con's
- Chance of fragmented knowledge and skills
- Could become complex, depending on complexity
- Loss of checks and balances
- Simular functions are done in other proces organizations, leading to loss of benefits of scale

In my opinion, there is a third way, that combines best of both worlds.

Service Oriented - with process management.
STOP! If you now are thinking about webservices, ESB's, WDSL, BPEL and other stuff - reset please. I am talking about business services.
Think of SOA as another way of structuring. Instead of focus on FUNCTION (we do X), Process (we undertake X, then Y, ... then Z), think of a structure of loosely coupled units that provide a certain function, in the context of one or more processes.

Think business lego. Easy units that we can quickly reorganize into new value chains.

A critical succesfactor for this is the ability for each unit to partner. To quickly understand it's role in the whole, and adapt internally, if needed, to supply the correct service. Call it "Chain Service Intelligence". This is not a skill that is easy to develop! It should be deeply embedded in the people, the attitudes and culture of the organization.

Another succesfactor is the question: where do we put operational process management?
In a functional organization, this was always the issue: it was implicitely put in the functional units themselves (I am responsible for part Y in the chain....), but no-one felt responsible for the whole chain (Well, I handed over on time, so it's not my issues...).
So, how do we build and maintain chains of services?

I believe we can create flexible businesses with small "service units". But that we also need a central service, responsible for end-to-end processes. A unit, that has 2 responsibilities:
- Operational: managing/coordinating concrete execution of processes. E.g. a "case manager" that monitors the execution of proces XYZ for customer ABC. Customer focus and delivery focus.
- Tactical: staying focused on delivering process outcomes within set goals and boundaries, and where needed, improve processes (possible, supported by a Process Center of Excellence) - both from a internal stakeholder perspective (investors, employees) and customer (service, satisfaction). Basically, this department owns the "Change process" (which is a normal process, part of the process portfolio).