A process model is not enough...

A number of years ago, I worked for a system integrator, with a a manager that was, well, a bit limited in his overview of the IT best practices.
One day he came up with a great idea. Recently visiting a seminar, he had learned that UML was the answer for everything. And he had a solution to the workfloor's problem: unclear requirements and an expensive process to define them. His solution: use case diagrams. His expectations: we could draw these in 1 hour, and voila - we had our requirements - quickly, clear, and cheap!
It took a while to make him understand that a picture, with some actors, circles and words, where a great idea to structure requirements, but by now means, a use case diagram would cover the requirements in enough detail. So reluctantly he allowed us to continue to analyse and write good software requirement specs.... :-)

It seems that we seem to make the same mistake now with process models. In a number of situations now, a business person delivered a set of process models, and said "well, here are our processes, have fun analyzing them and supporting them with good IT solutions".

Right....

So for once and for all:
When people need to communicate about process - a lot more information is needed.
My checklist:
- The goal of the process, how does the goal relate to the strategic intent of the company
- The criticality of this process
- Compliance, legal and other regulation requirements for this process
- The involved stakeholders (internal, external)
- The power structure/organization structure of these stakeholders
- The trigger that starts the process + through what channels
- The process owner
- The place of this process in the process architecture
- Input to the process
- Output of the process (including exceptions)
- The central object of the process (document, case, transaction, claim, client request, etc) that flows through the steps
- Events during the process, and typical + exceptional sequences and timings
- Data involved through the process
> Logistics (who does what when)
> Execution (data needed to perform task, data produced by task)
> Management (measures)
- Business rules for process:
> Decisions on flow (what task now.... if XXX then do YYY)
> Decisions on assignment (task XXX will be done by YYYYexcept if AAAA then performed by BBBB)
- The critical decisions, rules or patterns associated with it, and required authority to take them
- Succes - when is execution of this process considered a success? What performance criteria?
- CSF's - what is needed to reach this performance? and KPI's
- History of the process - when was it created, how has it performed, when and why has it broken down, what are typical issues, when and why performed it exceptionally well

Well, that's a lot more than a process model. It's the process context that BPM specialists need.

Starting with BPM-Suites - but what to do with presentation layer

It was nice to see some of my remarks on my previous post (BPM and packages) confirmed in a good state of the BPMS market item on bpm.com:
http://www.bpm.com/BriefingRO.asp?BriefingId=31
"The true upside opportunity for BPM is to evolve into a platform that supports rapid application development, change, and integration with a visual model-centric paradigm that represents a clear advantage over previous application development approaches."

E.g. A BPM-Suite currently is nothing more that a new custom development tool....

I want to address another limitation, that causes confusion.
Many BPM-Suite vendors proudly say: well, use our BPM-Suite, model your processes, link to your services, and voila, you have your SOA enable, process aware, WFM portal..... And, even better: you re-use your legacy.

I doubt it.
On a recent project, a client wanted to use a BPM Solution, integrated with their current core application. BPM vendor comes in, and says: shield your application, by wrapping services around it.

What this means:
About 65 screens, that users are used to, and that work fine, should be replaced by 1. Services, en 2. Well, screens again, but now in a Portal component of the BPM-Suite.

Added value? Good question...
- Rebuilding screens
- Rebuilding screen based business rules/validations

I am a bit puzzled. How can we deliver the power of BPM technology for human centric workflow, in the reality of existing applications....

On my wish list: a BPM vendor that comes in, and says...
Oh sure, we have a tool that analyzes all screens in your application, analyzes all user interactions over the last X years, and then generate a portal with optimized screens. With some minimal work, if needed, you can optimize these screens where needed. Oh, and the generated screens use common techology X, conforming to standards Y.

Then... I see BPM as a new tool, that can take over and integrate various packages and custom built apps, and integrate them from a process perspective.

Key challenge for BPM-technology: integration with packages

I have now seen two major projects that decided not to go for a separate BPM technology layer.
Both had done a large package selection (both in the insurance market). And it turned out (surprise) that these packages had their own, simple but workable, workflow/orchestration technology component.

I participated in both projects during feasibility studies, aiming to analyse the possibility to integrate the package with the company's target BPM platform.

And in both situations, we had to conclude: yes it is possible, but it's complex, risky and leads to a lot of extra effort.

Hm. This is not the way that BPM Technology is going to be the next killer app....

Some facts
1. These package vendors build their own "BPM technology" type components, but with deep integration with their package. Make's sense from a vendor perspective (for the short run), but is a nightmare for integration and enterprise architecture goals for typical companies (that would like to limit different types of technology used for process coordination)
However, their defense is also: there is no consensus on what BPM technology should provide, and what standards it should follow. Result of course is a proprietary process language, and service integration platform.
As a result, it is very difficult to buy the package, but replace the BPM component with your own central platform.
So we end up with another process component, and extensive integration (back to EAI) with other software, that needs to play a role during the end-to-end processes (so we lose overall process views and coordination).

2. User interface issues around packages and human workflow components of your BPM platform is another pain. Typical requirements are:
- Inbox for tasks
- Ability to open, claim, pauze, intermediate save, finish task
- Context aware task windows (e.g. after claiming a task, open the right dialog and windows in the package
- Integrate with document management, showing for a task the related documents.

As there are no clear standards and answers in these area's, clients have the possibility to let the package do this (usually speedy, but limited and proprietary) or try to find a solution with BPM technology and some presentation layer, integrating BPM, package and ECM solution.
Unfortunately, this is for the most part hard coding, deep coupling web client, server and various other technology layers.
So we end with, again, package solution, proprietary presentation layer, including WFM user interface.

Question - Can we solve this?

Well - there will always be package vendors that provide their package with a proprietary BPM component. Just to be able to support client requirements, one stop shopping and to avoid being dependent on third party technology.

But I think from a customer perspective (mainly technology), customers and their IT architecture can require packages to be more open to integration with third-party BPM tools. Definitely a good advice.

And most vendors might not have an issue either - it's sometimes better to focus on the package functionality, and leave general functionality to others (see what happened to identity management/LDAP, database, app server, messaging). BPM technology is the next candidate for commodity infrastructural software.

However, the BPM vendors need to do something too - being able to standardize even more. Sure, the WFMC model is a start, and some standards are there. But solve the above two issues 9with minimal development required and customers can force package vendors to open up to process (as a next step, after opening up for data and services).

And then BPM technology has a chance to go more mainstream. Otherwise we will always view BPM technology as yet another 4GL, in which we can develop visually (but we still call it development...)

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).

Lean and BPM - growing attention. But where are the Academics?

I just saw two articles on the use of Lean in the context of Business Process Management (published through BPM institute, ah, at least one BPM group that is surviving ;-)).
See:
http://www.bpmenterprise.com/content/c070618a.asp
http://www.bpmenterprise.com/content/c070625a.asp

And I am glad that we see this trend developing. In my opinion, Lean is a great process improvement framework, that we can apply in the area of BPM.
The big change from the BPR times is this: When BPR was big, basically the only process improvement groundrules we had, were, well, take a blank paper, and start all over.
But... where we used to have the "magical" step, going from current state process to future state, we now have a growing set of best practices and frameworks that make the process improvement step more based on sound research and practical experiences at other companies (such as Toyota).
Type BPM and Lean in Google and there are more and more hits.
The same on BPM and Six Sigma.
Great!

The only thing I am waiting for/hoping for is more activity in the field of academics - research on process concepts in the services industry... We need sound research and a better conceptual framework for service processes. While great work has been done on operations research and management, in the area of logistics and manufacturing, the "logistics" in services are not well understood. We know there is things as "cycletime" "Work in progress inventory" "flow"
"resource scheduling". But we need a better framework of theorie and optimization methods.

Anyone that has a perspective on this - reactions welcome!

(Dutch market): Lean survey

A request to my readers in The Netherlands.

In the Netherlands, there is a growing interest in Lean (a process improvement framework, based on the Toyota Production System).
A collegue of mine is researching the use of Lean in the dutch market. He is working for a unit that helps clients improve on Operational Excellence.
He is looking for people that are working for businesses (so, preferably not implementing consultants) that have been involved in Lean, that are located in The Netherlands and that are willing to spend 2 (well, 5 is more likely) minutes to fill in an online survey.
What's in it for you:
- Receive the results (and gain more information on the use of Lean)
- A chance to win a good book on Lean (for your next Lean project ;-))

And an extra request, if you fill it in, please remark on the last survey page, that you found the page through this blog...

Thanks!

The original request (Dutch):
"Lean is ‘hot’. Steeds meer bedrijven en sectoren adopteren het Lean gedachtegoed in hun streven naar efficiëntie en productiviteitsverbetering. Niet alleen binnen productie en logistiek, maar bijvoorbeeld ook in de energiesector, zorg en financiële wereld worden de principes van Lean veelvuldig toegepast.

Capgemini is een onderzoek gestart om de toepassing van het Lean gedachtegoed en de doelstellingen die organisaties hiermee nastreven in kaart te brengen binnen de diverse branches en bedrijfsfuncties in Nederland.
De resultaten zullen u de mogelijkheid bieden uw positie in te schatten. Met andere woorden, het zal antwoord geven op vragen als: wordt Lean veelvuldig toegepast binnen mijn branche? Welke tools worden daarbij gebruikt en met welke doelstelling? En zou het gedachtegoed van Lean wellicht ook voor mijn bedrijf effectief kunnen zijn?

Wij vragen twee minuten van uw tijd om antwoord te geven op zes korte vragen. Ook als u nog niet eerder bekend bent met ‘Lean’ kunt u de vragen beantwoorden. Uiteraard ontvangt u na afloop van het onderzoek de resultaten. Tevens maakt u door het invullen van de vragenlijst kans op het boek ‘Lean Transformation’ van B. Henderson en J. Larco.

Open de onderstaande link om direct de vragenlijst te openen:
www.operationalexcellence.nu "

BPM is about change - and change is about people

As a consumer, I am often amazed about the inside-out thinking of companies (not the customer is focus, but the company - and the customer has to live with it, or leave.... and most time they will...). And in addition, to the many many basically terrible processes that companies have, leading to awfull customer service, mainly caused by unawareness and lack of ownership.

The basis truth is: customers come and stay if service is good. And let's define the basis to service: it's that simple (well...) chain of all the little steps-actions-thoughts-decisions and ownership that people in your business take when trying to make a customer happy. It's the people!

As a short example: I am spending 4 months now to get rid of my Internet connection (that I cannot use even at this stage). Am struggling to order new furniture, where the company forgot to send me the requested proposol ("because person X was transfered and forgot to hand over"). So today, when I went to a shop for new contactlenzes, and everything just went fine (they even had the right data on me), I was even a bit amazed (and satisfied!). These people simply cared and had their processes in order.

As BPM specialists, I think we sometimes forget this, and focus on process too much. If we magically analyse the proces, identify gaps, issues, find the causes and remove them, processes will flow again. Sure, this is part of the needed intervention, but it's not enough: in the end, it's the people, and the chain of their actions, thoughts and ownership....

Coincidences do not exist I think. Currently I am doing two projects that are forcing me to see this fact and deal with it. And to be honest - I like it. My BPM attitude and efforts are suddenly growing to something I could call, well, group therapy.

For instance - I am currently working with an insurance company, that is struggling with a key area in their change operations: how to deal with changes, linking to their processes and IT solution. The key area I focus on currently is requirements.
I have the luxury that I can interview many people, based on a structured interview template, that covers process, concepts, stakeholders, issues and possible solutions. It's a great way to see through a group, see many viewpoints and perspectives, and identify patterns, shared images of issues, but also explicit or hidden differences in point of views (and even disputes).

First of all, I started realizing that this set of interviews is already a process intervention - by asking certain questions, people started thinking about things and became aware of their own actions and the consequences it had. They started seeing the chain (or at least part of it)!
But a key realization: for many people, playing a part in a customer chain, is like the group of blind men touching the elefant... they all assume they understand, but never see the full picture.

The next step (which I find somewhat scary) is that I will feed back the findings of all interviews to the group as a total (in a workshop), checking with them the correctness of my findings (and note - correctness is not reality - it's perception of the group). Maybe the elefant becomes more visible. I will also let them prioritize as group the biggest issues, and let them brainstorm on possible solutions + prioritize. Again an intervention (and almost group therapy) to make them realize the current state of how things are going and make them understand that THEY are in the lead to create a good, outside in, process, but more important that this process can only work if they care about it....

Maybe we should not talk about BPM, but about MPATEY - "My Process Actions That Elevate YOU (the customer). Eg.... empathy for the customer :-)
Are you focused on the people? If not, then realize: blueprint thinking on process is a nice and safe way to understand and to design, but it's only part of the solution...

Collaborative and Mobile solutions from MagicMonday Amsterdam

A bit off topic, but in a way linked to new ways of interaction during business processes and knowledge work...

I attended a great event yesterday in Amsterdam: Mobile Monday (http://www.mobilemonday.nl/, Dutch).

Two things came up, that showed interesting innovations for businesses, in the area of B2C (or better C2B!) and G2P (Group to Person, sorry my invention :-)).

1. Backchannel (G2P)
A new concept for me, very new generation internet type. The concept is simple: a presenter is giving a speech, supported by visual material (such as a Powerpoint presentation). At the same time, a large screen shows comments by the group listening to the presenter. This could vary from questions, doubts, observations, new insights to (realtime) results of research (is this person telling the truth).
What's nice about it:
- It made the whole group feel much more involved.
- Easier and faster to interact with rest of audience (react to eachothers comments)
- It made boring parts of the presentation much more fun :-)
- The comments are kept (on a website) and can be reviewed later by presenter and participants (would be nice if there was a playback with timed backchannel, a type of voice over :-))

Where I have my doubts:
- Well, I am not a part of the new internet generation, that can MSN, listen to music, watch tv and do homework at the same time. The constant stream of comments distracted me from the speaker
- It would be nice to filter out questions to the speaker and keep them on the screen, till addressed. Now it was still a blur of all kinds of comments, which kept going...

For some pictures of the concept....
http://www.flickr.com/photos/marjolyn/530670411/ (backchannel on the right)
http://www.flickr.com/photos/64015000@N00/530485307/ (backchannel image)

For a list of comments during the presentation (partly dutch, partly english):
http://www.flickr.com/photos/64015000@N00/530485307/

2. Mobile concept: barcode scan by mobile phone camera
There was a presenter from http://www.op3.com/, who are working on a new way of C2B (Customer to Business) interaction: through barcodes.
Some example scenarios:
- You walk around in museum. Every object has a barcode close to it. Scan the barcode with the camera on your phone, and additional information will be displayed....
- You walk on the street. You see that a lamppost is broken. The lamppost contains a barcode. You scan the barcode, which automatically informs the local government to fix it
- You want to get a coffee in your company or make a copy of some paper. Coffeemachine/Copieer broke. You scan the barcode, and your mobile phone informs the vendor that repair is needed.
- You see a poster of a cool new band. Scan the barcode and your phone shows you more info and enables you to order the cd, download MP3's or order tickets for the next concert close to you...
- You are buying a trainticket. The trainticket contains a barcode. You scan it, and your phone immediatly informs you about the fastest trainroute and interesting (well for you personally) things to do in the place of destination.

This is just a short brainstorm, but I do see large potential. From a lean perspective (outside in) it's amazing how difficult it often is to fulfill your need as a "consumer" (yikes). It involves searching, going places, asking, uninterested personnel, waittime (so it takes 2 months to get this couch?) etc. Technology that we as buyers could use to quickly find our way to the right product would greatly improve our lives. Not to forget the advantage for the companies...

A key lesson on process analysis & (re)design

Together with a team, we recently completed the process analysis and redesign for a specific process area for large bank.

I wanted to share some of the experiences and a key lesson.

We took the following approach:
1. Understand current process (including visual model) , through workshops and document review
2. Deepen understanding, by finding process statistics
3. Design future state process, by using elements of Lean and common sense
Step 1 - requirements. Step 2. Activities. Step 3. Responsibilities. Step 4. KPI's
4. Analyse automation possibilities, and define use cases, non functionals and preliminary IT architecture (iterative)
5. Develop business case and different scenario's

We delivered the following, in a way a fairly complete business architecture
- A proces diagram (with annotations) current state
- A proces requirements document future state
- A proces design (logical level) future state, annotated, different levels of abstraction and use of swimlanes
- An organizational design (with FTE calculations)
- A use cases document and non-functionals document (together: software requirements)
- A preliminary IT architecture
- A cost/benefit analysis spreadsheet with different scenario's for implementation (including options such as BPO and offshoring the development of the proposed IT solutions).

All deliverables have cross-traceability (for instance a proces step links to a certain requirement, links to a certain use case and feature of the proposed IT solution). Handy for consistency checking..

Nice was the active application of Lean thoughts. For instance:
- An active focus on the customer requirements: what would a customer require in terms of proces, product and service? And what steps does a client need to take to go from need to solution- and are we able to help with these steps or simplify/reduce?
- A split of the basis flow (main proces, which can include detection of exceptions) and exception handling processen, to make sure that the main factory process continues.
- A clear split in plan-do-check-act cycle activities.
- Just In Time approach, with zero - to close to zero work-in-progress inventories
- The use of takt-time as a basis for "flow design" and calculation of effort.

Key Lesson - split requirements and design

When I was still on the techie-side of things, we had a rule "the sooner you start coding, the longer it's going to take", promoting the importance of clear requirements and a thought-through architecture. Well, I think the same is true with Future State business process modelling. In the beginning we brainstormed and modelled a bit on future state, only to realize that, together with our client, we needed to take a step back.

What we did, was the division of process abstractions in:
- A set of requirements
- A logical model (with no implementation decisions yet)
- A physical model (with implementation decisions, scenario's, such as BPO and IT)

This greatly improved and focused our effort. We were able to facilitate our client through process requirement sessions, where questions were asked such as:
- What are the goals?
- What should have been done, to consider a process instance to be done totally?
- What should be the result of the process execution? In what dimensions measured?
- What should be CSF's and KPI's?
- What stakeholders are involved? Why? In what responsibility/accountability and added value?
- What requirements will the main stakeholder, the CUSTOMER, have? (VOC).

The key strength was, that the customer started to see that certain requirements where not compatible and needed prioritization (sure, you want low cost, high quality, agility, speed, compliance all at the same time, but that's nirvana. What's most important?)
And that the procesmodelling effort for the future state was a simple exercise, using the requirements as a basis. The modelling refined some of the requirements (feedback learning), for which we used traceability and version control.

Note: in the logical procesmodel we identified different processes - from workfloor to management.

After the logical procesmodelling was done, the next step was to explore implementation choices in the steps of the process. Can we automate X, can we outsource Y? It lead to a number of scenario's and a proposed physical process design.

Although it sounds a bit top-down, through iterations we made sure that requirements, logical design and physical design were synced and improved where needed. The result - a happy client, with a sound plan for his business. Next step: getting it decided and live!

4 reasons to capture your events

A common reason that I hear from companies, for embarking on the BPM journey is process visibility. The so needed knowledge about what's happening in the company, to be able to assess status, progress and strategic alignment.
In my opinion, visibility starts with events, and to begin with: the external events: situations where you as a company are contacted by an external stakeholder (customer, supplier), which triggers a series of activities.
A good start (which any secretary can tell you) is to have some type of incoming event recording system. Why?

4 reasons:
1. To help customers trust you - it is so strong if you can tell the customer - "sure, we have received your order, change, complaint, at date XYZ". Events are integral information in your customer relations history.
2. As part of your record management system (compliance, auditing)
3. As major input for your KPI's & management information (how many order-requests have we received?)
4. As input for your inline simulation engine

The last option is a fairy new feature in BPM engines. It saves you enormous time if you don't have to dig up all kinds of events information, to be able to run simulations.
Inline simulation helps you to see what results would have been, based on your past actual history, if you change certain business rules or processes....

The good news is that you already probably have many event capturing systems. Unfortunately, the events are not seens as separate entities, but are translated and deeply burried in your ERP's, CRM's, Web logs, batch-audit & signal files, Document management systems, not to forget masses of emails and paper documents.

It would be good to see a new module in your enterprise architecture: your event capturing and recording system. Let's call it the Event-Friend :-)
A system that recognizes events, stores them and dispatches them based on business rules to people, BPM suites, ERP systems, SOA orchestration stacks, etc.
And in the future maybe even more intelligent - able to relate events (which one belong to another) and see patterns, trouble (new account opening, and directly a cancel?) or fraude...

An essential element in your future Event Driven Architecture.

Do you have process maturity at the right place first?

Today I was "babysitting", taking care of a 2.5 year girl. Wonderful. Outside, sunny, and running around together with this gorgeous bundle of joy, energy and learning. It's a wonder to see small children learn. I must say, evolution has given children the right tools to grow up:
- Great Curiousness
- Joy and Courage
- The will to repeat again and again and again, (and getting better all the time as a result)

It made me realize an important thing about abilities in a company. There is quite some talk about "Business process management maturity" models. As a sidenote: did you ever meet a CEO that stayed awake at night, worrying how to get higher in the maturity model? Right...

Anyway, children grow up and learn. And they have the right skills for this learning.
But if we want to help grow a company, and get better processes, where would you start?
I have seen many checklists to hunt down the right process. The biggest bang for you buck, the most visibility, the best etc. Frontoffice! No, backoffice! Uhm, supporting processes first. No, the most fat slow cost-intensive. Probably, they are all right a bit.

But maybe more important than which process to pick, is the question how to proceed. Think of any activity in your company that delivers change. So, not the base processes (sell, procure, invoice, etc), but processes that change these base processes. Not much companies realize they have many of these types of processes as well. Some of them:
- New product development
- New IT systems
- Responding to changes in legislation
- Updating your brand and communications
- Management wanting a new way of reporting
Etc...

Now think about your strength in these types of processes.
As a small example, I worked for a company selling insurance products. They were ok doing that. But developing new ones or changes? A nightmare. No visible process, more a large group of people spending most time influencing and disagreeing. Efficient? Right.
I don't think that in general, companies are strong in their change oriented processes.
Now, compare that to the little girl, and her great learning ability....

Maybe when we are starting change or improvement projects, we should spent more time growing our change/learn ability. See this as one of the strategic goals in your project. Maybe even assess it first, and become aware of common pittfalls in your company.

Your change ability is:
1. a CSF for any running project or change process
2. A competitive advantage in general (confirmed in research on High Performance Organisations)

So, if you want to grow process maturity, grow your maturity in your change abilities first (or too!)

A tale of "moments of truth". 7 rules for Customer Management.

Ok, deep sigh, I had a "MOT" with a big company in the Netherlands. My telco provider, to be precise. (For MOT: see http://apply-mag.com/mag/farming_moments_truth/)

And it made me, sadly, realize, that BPM is SO necessary.

Short recap:
- I moved to live together with my girlfriend
- Both of us have broadband ADSL connections, at the same provider
- For some strange reason, KPN/Hetnet have a "year subscription"rule, e.g. if not cancelled at last month, you are forced to stay another year (something that in my recollection only weird bookshops still try to do).... even if you have been subscribing for many years, as a happy paying customer....

Since I moved to a house which already had a ADSL connection, I called my provider to see if I could cancel my own. Two subscriptions on the same address would not work anyway.
What follows (and I will not go in all details) were the usual 15 calls, press 1 for, no we can't do this, sure we can, endless music and a growing frustration.

Some of the experiences made me realize that outside-in thinking, MOT's and event driven companies are a FAR future in many cases.

My lessons:
1. Sure, a call center is nice, but make sure that you have identified your common EVENTS
2. Make sure that for each event a protocol or process exists. It should not be too hard to think outside in, and collect most possible events that can occur with your customers. And decide how to deal with them....consistently.
3. Decide who you will assign the process coordinator role. And make sure it is NOT your customer. In this last MOT, I had call center agents, requesting me to call back in 2 days, because then a certain change would have been processed. Me.... with the typical re-explain story all over again, including the earlier discussions no,,,yes,,,but,,,,
4. Consider to assign "a problem owner". Someone that simply says "Sure, I understand your event, I understand our steps to fulfill your needs and comply with our standards, and I WILL TAKE CARE OF IT". My name is XXX, and you can always call me at ..... I will call you as soon as.... Make sure that your customer does not need to understand the internal working of your company, to get his or her problem solved.
5. Train your staff to record decisions and status. Ah, I see you have called us before. Sure, the status is now xxxxx, and no, you don't have to explain again or go into discussion again. Nice for your customer, even nicer for your internal coordination mechanismes.
6. Don't make your customer feel that when signing up to a service, all lights are on green, and when in a later stage all lights are on red. A sure thing to get them really distrustfull.
7. Treat a loyal customer good.

Amazing that when you talk to these companies, which I often do, they have fancy process management tools, BAM, SOA, etc. But the key thing they forget.... the people that buy their services...
Process maturity is not about technology, it is about understanding that every MOT (moment of truth) is created by many small actions by various people in your company. BPM can be used as an intervention to get these actions aligned. It asks for a culture of customer orientation, getting the job done,.... simply maturity.
Maturity. So... Grow up! (or be gone when your competitors understand this better....)

Sentence of today "culture eats process for lunch every day."

A short post...:
Great article...
http://www.bpminaction.com/blog/2007/04/success_with_bpm_a_cpr_approac.php

"culture eats process for lunch every day."

What a great way to understand in a split-second that all your BPM efforts, often IT driven, will face an important hurdle, that will make you realize that process-analysis and design should be driven by people and culture first, and then IT....

Spring is here - time to approve standards...

In a relatively short period of time, I have seen important approvals of standards, related to BPM... BPM is on the move.

1. BPDM seems to be approved
See: http://www.modeldriven.org/web/bpdm
Still unsure how BPDM and XPDL are related. Will need to research this. Comments welcome.

2. BPMM
The business process maturity model (with a foundation of CMMi)
Also see: http://www.omg.org/docs/bmi/07-03-04.pdf

Very handy as reasonably objective framework for measurement and improvement planning.

3. BPEL 2.0
The business process execution language, version 2.0
Also see: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
and... http://www.oasis-open.org/committees/download.php/23665/wsbpel-v2.0-OS.htm

I have not checked BPEL 2.0 yet, but do hope it has now capabilities for human workflow as well....Anyone knows?

Star Rating added

I've added a 5 star rating widget (http://spotback.com), which allows visitors to score individual articles. You're most welcome leaving a score, after reading an article! Your scores are an important KPI in my BPM-BAM dashboard ;-). Thanks!

Future Feature of BPM-Suites : Predictive BPM

I remember, when working for a large insurance company, that they were struggling with workforce planning. Basically, once a year, they looked at the average workload per employee, and based on that estimate and some predictions on future developments, they agreed on the workforce numbers for different teams in front- and backoffices.
What they forgot were seasonal influences. In insurances, a lot of work happens during the beginning of the year (renewal, new pension plans).
A typical result was the following: agreed workforce started in januari, and (since workload was much higher), a backlog of work started to grow. Managers unsatisfied, pressure on teamleaders and, in the end, the workforce. Around june, backlog was unacceptable, expensive external temps were hired, which caused an initial extra drop in productivity (more experienced workforce needed to guide temps) and in, say oktober, things started to be in control, leading to november estimations for the next-year workforce, where, well, you guessed it, memory was short, so about the same numbers were planned....
And customer service? Well, in this company, it was seen normal that pension overviews of the previous year were send in Q3/Q4 of the next year on average.....

Of course, workforce planning is sometimes difficult. It requires process maturity to measure, be realistic, and take out politics. It takes process maturity to evaluate plans and have the courage to adapt when needed.

A great thing would be, if BPM-Suites came with a feature, which I would "predictive BPM".
Take a typical moment in time, with a running BPM Engine. A great number of process instances exist, each with a certain state in their flow.
It would be great if you could ask your engine the following basic questions:
1) How much workforce effort is needed the coming say 10 weeks, to finish the current process instances, if these processes are to be finished in a certain (SLA) timeframe?
2) What is the estimated influx of new process instances for the coming period, based on a seasonal analysis of previous years?
3) What is the total required workforce (current process instances + new instances) to finish all work required to meet SLA's?

Sure, this is complex stuff.
A BPM-S would need (or a tool above the BAM/BPM Suite):
- Knowledge of workforce - all people, their productivity, their work-assignments
- Knowledge of procesflows - typical flows per process (% for each branch and sub-branch)
- Task duration and effort
- Process history - a log of all process start events in previous years, #per day, % per type per day

But what a great planning tool would be possible. I could even see business analysts help managers with what-if scenario's...
- What-if our competitor is delivering 10% faster throughput, how much more workforce or productivity increase would we need?
- What-if we are able to change seasonal influences with some incentive?

In manufacturing, this type of planning is already there. The services industry is behind.

But it's promising to see that "Predictive" and "BPM" already are delivering hits on google.
Because what's process management, if the only thing we can do with BAM is look in our back-mirrors?

EDA, Rules and BPM

Came across a great diagram (sorry, (c)), which explained a possible architecture that connects Event Driven Architecture, Rules and BPM.

The elements (in sequence):

1. A business event occurs, and is signaled from somewhere (say a CRM application)
2. It's given to a Event Processing Agent. This decouples the business event from a process event. Based on rules, it translates the business event to one or more process events.
3. Process events are given to the BPM layer which starts a process (or continues a waiting one)

I like this decoupling. It creates a clear component that has the responsibility to know what is needed in terms of processes. And manage it by a rule engine.

Suppose your customer reports being pregnant... (ok, it's my girlfriend :-))

Process events for the typical insurance company:
- Time to start up a advice on life insurance
- Time to trigger some gift to be sent
- Time to inform the health insurance dept. on coming claims and required reservations....

I do still wonder where to place the logic for knowing, based on a process event, if a new process needs to be started or a waiting one needs to continue. In my view, we need some type of component there as well... with knowledge about process events, rules and current process instances that are waiting or running. The CEP-unit.

Case management - real life example

Went to a Special Interest Group meeting in my company, around the Cordys BPM product.
A group of consultants had succesfully delivered a BPM solution for a large insurance company, around Claims handling.
While they were modelling and gathering requirements they found:
- It was impossible to model a coherent process front-to-back
- Many events could happen, at unpredictable times and sequences
- If trying to model this in production workflow style, the amount of exceptions was simply too much
- Not all tasks could be predicted based on context...

No need to go on - they found the case management situation.
They created quite a flexible solution, were:
- Certain parts of the process were modelled - "process fragments"
- When a "case" was started, users could decide which tasks (and process fragments) needed to be performed
- During execution of the case, new tasks/fragments (from a standard list + manually defined - single tasks) could be added or removed
- After execution of a task, users could decide (based on business rules) if the case was finished or not.

The interesting part: they build this with a tool that was more aimed at traditional BPM. By a clever combination of some custom code + BPM parts, they were able to create a good solution.

The session did make me think about what a process really is, and what approach to choose to model and automate. A warning there: if you start projects with the production workflow BPM mindset, you will try to fit in reality (if you have a hammer, all problems look like nails...).

What is a process?
I am still struggling with this. Maybe what I will present here is rubbish, but it's a first attempt.

A process is defined as:
- A set of possible events
- A data context (or state)
- A set of possible activities
- A set of rules that govern relations between these elements

The metamodel relations are:
- There are External Events (outside of "world") and Internal Events: change of state
- (Event + Certain context/state) link to a certain Rule, that triggers Activity.
- Activity results in Change in State. Change in State triggers Event.

Now, you could define certain heuristics to come up with your "BPM approach"...

1. If all Events are known, and Each (Event-State) triggers unique Activity, we have production workflow.
-> Deterministic

2. If Certain (Event, State) combinations have NO Rule or Multiple known at design time, but do require an action (from a person!).... Case management
-> Non deterministic

3. If not all States can be defined at design time... Case management

4. If not all events can be definid at design time... hm, exceptions in workflow, or case management.

Hm, maybe it's getting late. But I am trying to find some type of BPM metamodel, that allows us to analyse a business situation more fundamentally, instead of trying to start with a workflow.
Ideas welcome!

Gartner BPM Summit London - Day 2, Part 1

Ah, a great start of the day with a good presenter: Regina Casonato.
Her research shows (and I agree, from real-life experiences) that there are processes we are currently not able to automate (well) with the current generation of BPM tools: fluid, contextbased collaborative processes.

Small example on my side: ever tried to model collaborative BPM with BPMN and Swimlanes? Right....

So where all vendors talk about S2S and H2S integration (S=System, H=Human), she helped us understand the tricky domain of H2H BPM.

Some important terms that play a role:
-> Presence.
In my definition: your own availability, in terms of for WHO, and via WHICH Channel at WHAT TIME. Something that you manage (already). However, something that in the future, you will be able to manage much more detailed.
Now: I can decide where I will be, if I pick up the phone (general or caller ID), if I will respond to IM (availability, even for certain people), etc. In the future I might detail this more: between 9 - 11 Am, I am available for BPM activities X, Y, and Z, through channels IM and email. Oh, and BPM process A, B and C I will be available during working days. E.g. detailing my presence "rules" to context....

-> Context
More tricky. Whenever we are presented by say an email or a workflow item or a phone call, or whatever thing/person that delivers us information, we need to understand why, what, how, who, when, etc. Context is what we need to be able to do something usefull with provided information and with a activity/request.

(She made an interesting link to BPM and information overflow: a process can be seen as a piece of context - we are doing X for customer Y). When delivering an activity, the process (what needs to be done) + process data (which customer, what step of the process) serve as context to the person doing the activity. So more explicit processes can help us structure reality and fight overload (well a bit - she warned for context overload).

-> Collective Intelligence
Beautifull clear concept - all the mindpower you can have, that you need to really perform some activity in a process well (think decision, strategy, etc).

Now, let's get back to the Collaborative part. Suppose a process requires a collaboration as part of a certain activity. H2H. This could be: synchronous (all people required need to be available, aka a "meeting"), asynchronous (a conversation over time - discussion/forum/email correspondence) or hybrid. The concept of presence becomes important here: a group of people receives a task. Will I get it, will I be involved, am I needed - a mix of context, rules and my presence decisions. And depending on my channel choices, I might be included through face to face, phone, chat/instant messaging, email, etc.
The key question: how to involve the right people at the right time, and support them well?
Her point is that these types of H2H interactions are currently not well integrated in BPM tools, and that if we want to take on the Information Worker processes, we'll need to rethink. From the production workflow transaction based processes (do this, do that) to a mix of do this, do that, hmmm, think about this, collaborate on that...
A mix of technologies, think networking sites (who has knowledge about XYZ and is currently present), IM, email, VOIP, etc.

It's funny, in my current project we spend quite some time how to get certain stakeholders doing certain tasks at the right time (sometimes together), and what if they are not available...
It links to another concept she used:
-> Just-In-Time Intelligence.
Ah. The right task and the right time to the right persons with the right knowledge.

Collaborative Events happening in a process flow can of course:
- Be logged -> to capture the knowledge, so that simular tasks later can re-use this knowledge
- Be traced -> to support compliance

In her view the whole Web 2.0 collaborative technology and BPM could be linked and merged.
And of course, she reminded us: don't do collaborative BPM within your company walls, think larger - customers, suppliers, partners.... How to leverage your collective intelligence!

Interesting times ahead!

A sidenote:
The concept of an Context Engine versus a Process Engine made me realize we currently mix these things. We define BPM models in BPM Suites, where at design time we decide for each activity what the means are to finish this activity (that person, that SOA call). What if we split these concepts:
- A process engine knows only about an activity that needs to be done
- A context engine knows for each activity, based on presence, contextual knowledge, etc, how to get this activity executed...

SAAS powered BPM-modeling for the traveling consultants...

Yes, I know, I am behind! I should have been blogging day 2 and 3 of the BPM summit. And I will, hopefully over Easter. Ouch, times flies, and I am in the final stage of a interesting BPM design phase, which was taking a lot of my time.

Anyway, a short post on new thoughts about the new SAAS development (or BPM ASP).
The SAAS for BPM concept is quite simple: provide a good BPM modelling tool, over the web. The process repository is hosted somewhere safe, no tools or databases needed on your PC's.
Two vendors that I know of now are working on delivering it: Appian (Appian Anywhere) and Lombardi's Blueprint. Others will follow, I expect.

Now for consultants working a lot on the road, at different projects, with different PC setups, this could actually be a great tool. How many times we have had situations where we needed to model complex processmodels really quickly, while either working on our own laptop (not connectable to client network, no printing, no sharing) or working on PC's provided by client with of course no BPM modelling tools (well, apart from Powerpoint...). Ouch. And most of these companies take 2 weeks and endless signatures to fix either the laptops or have BPM software installed (if they even have it).

So I see a new trend: "White Label" BPM SAAS, where consultancies companies can create their own labeled BPM modelling tools (oh, and while we are at it, throw in some organisation and Business/Information architecture modelling as well!). A nice collaborative environment, where projects can be set-up within 5 minutes and go.... The result: less Powerpoint frustration, productivity and collaboration + great tools to facilitate the complex tasks of process analysis, decisions and design..... And not to forget: a view for the our clients (RSS?!) on deliverables and progress.

My wishlist:
- Browser based, no added stuff needed.
- BPMN
- Create models and model-hierarchies
- Multi-user
- Version control and tracking
- Assign ownership to different model-area's (who can do what)
- RSS feeds and other update alerts on process changes
- Ability to log and discuss process questions and issues + resolutions
- Tool to extract everything in XPDL/BPDM
- Ok, tool to extract complete proces repository as some type of Office document (for easy off-line review and delivery)
- Ability to "tap into" a certain model/design session and see the live changes occur (when working in groups) and do some time of direct messaging/discussion online.

I think I will start talking to my employer :-)

BPM Summit Day 1 - Observations

Pffff. How would you feel after a day at a congres about "Wordprocessing". Envision a congres hall, filled with 20 vendors. Each trying to talk to you, and show you their great product...
"In our app, you can type text and print it"
"Well, in ours you can type it and see it WSYIWYG!"
"Well, we work on all platforms"

Ok, now I know: BPM-Suites can model processes, execute them, measure them, and sometimes simulate them. Sure....
The key question: what's the differentiatior????

I remember Lean, where a lot of attention of going to the customer and the customer journey: what to do to fullfill your need.
My prediction: in the BPM market, it's going to be about understanding of the customer's business context, your professional services and training capabilities and your turn-around time to deliver real solutions, based on your track record.....
And for customer's it won't be easy to surf this vendor space.

Of course I can help :-)

BPM Summit Day 1 - Part 3

I went to a presentation by Janelle Hill (quite strong presenter, I must say), about new roles in the BPM area. She talked about the new "Process Excellence Center" or PEC, and the typical roles involved with BPM: process owner, process analyst, process consultant, process architect, PEC manager.
I must confess I am a bit hesitant. Everytime a new technology or thoughleadership reaches us, we are talking about new competence units. I remember the BI cc, the Java cc, the Client/Server cc, the Process Modelling cc. Sure, as a first step, some network of expertise is needed, but let's face it: do we have a "Money management center of excellence"? No, we have integral management, where finance is a part of the responsibility of a manager. Process management should be the same, with, sure, a backoffice or consultancy organization to support this manager.
What did trigger me was the notion of the expectations of IT and the attitude towards risk of management. When you have a situation where management is low risk, and sees IT as utility, coming from the IT side, pushing BPM will be very difficult. And trust me, I have been there... Working for an insurance company, with basically no appetite for innovation (unless it was pushed down from management), being an BPM evangalist was not easy....

I was quite happy being at the next presentation, by Singularity. Well, ok, this guy was just reading out-loud (yep) the full presentation (including the jokes, ouch!). But it did make a good point accross: case management is a fundamentally different add-on to BPM.
This is something I have been noticing as well: when modelling processes, you will come into business situations that will seriously challenge your modelling skills and also will exceed currect "production workflow" capabilities of BPM-suites.
The singularity guy showed a pyramid - with in the base typical "hygiene" processes: able to model at design time, limited complexity, limited collaboration. In the higher area's you get to processes that can be classified as...
- Many possibly events that need to be handled, with unpredictable occurence and sequence
- Intelligence at RUN time, a case handler that will decide that certain steps are needed in addition, or certain tasks will not be...
In one word "Judgemental processes". Examples include a doctor's visit, certain insurance claimes, pre-sales, exceptions, etc. Highly unpredictable and context-sensitive.
In my experience when you hit these types of processes and trying to BPMN them, you end up with a milion exceptions....
The key concepts in those types of processes:
- Process fragments, little pieces of process that can be added to a process instance
- Business rules, that will govern which fragments can be added in what conditions
- Events that will trigger changing the case processes and approach
- Case state that will determine where we are, and if we are finished
Definitly a new BPM area!

A quite good presentation was done by Nuon, one of the leading utilities companies in The Netherlands. Finally a solid BPM and SOA real-life projects, with some honest lessons and CSF's.
Their need was to reach as state where they were able to change processes in a matter of days/week instead of the typical 18! months. The market (customers, compliance, take-overs and mergers) was requiring this. They created a flexible SOA infrastructure with a BPM engine on top, and stepwise refined it. A bottom-up approach, quickly spreading the word and adding processes step by step.
A quite good prep-action was to define a reference architecture with layers and principles, around among others the service governance, the change control, etc. Some policies included:
- Stateless services
- A provider of contentservices (data, functionality connected to a business process) will not deliver the SOA/BPM infrastructure and vice versa (to prevent vendor lockin)
Well, they have processes running! Even changing them (cycle time: less than a month!). And with bottom-line success, including a nice decreasing days sales outstanding (DSO).

A last presentation by Global 360. Some concepts:
- Transformational applications versus tactical applications
- If your process needs more than 2 systems to work, forget the agility....
- Process intelligence (including BAM) will likely to be a separate domain, with it's own technology (BAM, simulation, workforce planning)

A last gem by Janelle Hill:
- In our age of information overload, process provides a context for information! More about this later, based on a great presentation on day 2 about collaborative BPM trends...

BPM Summit Day 1 - Part 2

BPM Summit – Day 1 Part 2

I went to the SAP presentation. I must say that I was disappointed – it was more a high level product overview and sales talk. Hm.
It was interesting to see that SAP has transformed itself from a pure ERP player, to a middleware supplier (they stated that they were #3 in the market) and active SOA/BPM standards pursuing company. Question stays if customers actually want that. Nuon for instance stated explicitly: our BPM and SOA layer provider will not be our “content” provider, and vice versa, to limit vendor lock-in. But with an installed based of 38.000 clients and about 12 million users (wow!), some will accept both ERP and BPM/SOA infrastructure from one vendor, I guess…
SAP is of course also busy with their industry templates. Nice to hear that they had a set (in R/3) and decided to simplify them! A lesson that a lot of template providers (to be) will probably still have to learn (and their customers…)

Loose gems from different sessions:
-Oracle: SOA will fail if you do not approach it with a BPM perspective.
- Global360: BPM is a success if you talk to an end-user and they only talk about their application (preferably: their “transformational application”) using only business terms and not mention any tools such as BPM. Aka “Our loan application”, “Our customer portal”.
- Let go of the word “Maintenance”. When approaching applications with BPM, let’s talk about iterations.
- BPM as technology will only deliver process effectiveness, not delivery efficiency. You will need to analyse processes and improve them yourself (using methods such as Lean-Six Sigma, Simulation and Process Automation).
- When starting with a process, a number of starting points exist: bottom-up (what is done/needs to be done), top-down(what goals, what measures).
- You might want to implement processes as-is with a BPM Suite, to be able to start gathering information, and then improve.
- Key question on BPM maturity: are you using BPM technology in AN application (Point Solution), or did you create a BPM Platform to be used by all process aware projects?
- A lot of companies (Oracle) are starting to offer “industry process templates”. Gartner predicts that these templates will become valuable assets. But not all agree.. The key question is: will this add value? Some say: we are not interested in the BPM-S Supplier X Order-To-Invoice process, we want to know how say Procter & Gamble is doing it. The closest companies to get to that kind of information will be process modeling companies and the larger system integrators… And not so much the smaller BPM-S suppliers…

Following later - an interesting presentation about Casemanagement, which in my view is a NEW addition to the BPM field (although some companies have been understanding this already for a while, among others pallas athena, singularity and metastorm).

Gartner BPB Summit London, Day 1 - Part 1

BPM Summit Day 1 – Part 1
Also see: http://www.gartner.com/2_events/conferences/bpm2.jsp
I had a somewhat slow start at Gartner’s BPM Summit. Although presentations were okay, I actually did not hear that much new. My lesson: although Gartner is an important player in the research area, the summit does not hit that much in depth real life lessons.

A summary of presentations.

Bill Rosser kicked off an introduction around BPM as a discipline. Nice to see someone actually trying to define what is meant by discipline (in his terms: an area of study/ expertise/ knowledge, a set of principles/methods, and a set of rules of conduct to comply with).
A returning item in this and later presentations was the trigger to get started with BPM and related technology: 1. Improvements (e.g. cost, customer value, time to market), 2. Agility and 3. innovations. In the eyes of Gartner, although process improvement is a good goal, it’s a bit limited compared to the potential of BPM. But a necessary step in the adoption of BPM.
Starting with BPM could be done top-down and bottom-up, the latter being the most frequent encountered, according to Gartner. Bottom-up has it’s risks, mainly in loosing focus and early termination. It’s main CSF’s are good champions and good results, that are marketable towards sr. management.
Another repeating subject was the need for business to realize that functional orientation and corresponding business area maximization will most likely lead to overall sub-optimalization. Key is maximalization over the whole valuechain (starting with your own company off course…), and a combination of functional and process orientation. So process orientation as a complement to traditional functional management.

Nice to see that Bill talked a bit about the change management and the area’s of interventions (as I wrote about earlier: BPM is a set of interventions, in my eyes). Areas included organization, technology, culture, to build trust, rewards, ownership and the right attitude, through for instance education and methodology standards. He warned that these interventions could take 2 – 3 years to yield result and that you need to time these interventions right: if going too fast, you might not get the results (ouch, a valuable lesson for me, who typically is too much ahead…).
He also warned about the discipline: while it is important to approach process management as a discipline, one should be careful not to create a “harnas” with too much discipline demands. Don’t focus too much on standards, tools etc. Overdoing it could harm progress. In my perspective most companies I meet still are quite under-disciplined (read: adhoc), but the US-situation might be different.
And a last lesson: while running your BPM efforts, communicate communicate communicate. Have process visibility as key focus.

During the opening keynote we heard there were about 450 delegates. Not bad for a European BPM Summit! A summary was given on Gartner’s6 best practices/key elements for BPM: Alignment, Culture & Leadership, Methodology, People Skills & Roles, Governance and BPM Technology.
A quite good presentation was given by Mark Raskino. While stressing the fact that we are in a 3rd wave, and that BPM is a must-do, he also warned that BPM is a hype currently, and that expectations are inflated. The real valuable lessons will need to be learned the hard way: by doing, partly failing and recovering. A path I am very willing to take, and am taking every day. The key lesson: again, this is not the silver bullet, the “plug & play” solutions that will magically solve issues, like CRM, ERP etc promised before.
He talked about the mindset of managers, and what would convince these people to go BPM. Quite simply: cash flow, market position (not to be bought, but to take over yourself), your stockprice, your competitive edge (something that might be good now, but is deteriorating quickly, and management’s knowledge of the pain (and fat) in processes. His key remark: Process maturity (read: your ability to continuously improve) is a sustainable competitive advantage.
An analysis of the market developments showed that this advantage is quite needed: globalization (in terms of offshore resources, capital, markets and conditions for execution of processes) and regulations/compliance (which will grow due to the ease of internet).
His premises: the question is not if you will do BPM, but how well you will do it….
And he predicted that business process may well start to be recognized as intangible assets that will start to appear on companies balancesheets (now, how’s that for “management!”).
He stated a solid wishlist for managers in 2015, and striking was that BPM was a requirement in most of them. Research showed that CEO’s were seeing this too, and that even CIO’s (although a bit hidden in research) were responding with changing investment patterns.

Some concluding remarks:
- Essential in BPM is to create a number of process abstraction layers (which I recognize in my projects).
- A nice metafore on the changing IT landscape: from Stonehenge (legacy) to Lego city.
- Business intelligence will become a critical element in BPM: Without clear measurements, discussions on which process to improve and why will stay highly political and not objective.
- BPM Suites are currently highly oversold, and under-delivering (a finding which agrees with results from the CIO research)
- IT should NOT be the BPM leader, but the enabler.

And a last theme, that came back later: IT’s is slowly becoming a more planned (IT portfolio) area, but for BPM that’s killing: you don’t want to put in a process-change request at IT, and wait for X months. You want it within days! It made me aware that something like IT portfolio control, which seems like a nice idea, is actually not something business is glad about…. Chances are that when introducing BPM, we need two processes for change: the quick one, for BPM (maybe even with business doing it themselves) and the slower one (custom code maintenance, etc). Mark warned that to keep good time to market for process changes, the number of people/layers involved in a change should be minimized (otherwise too much noise, time, cost). And I agree – agility on the deliveryside could do wonders here!

Will be @ Gartner's BPM Summit in London

Oops, have not been blogging for a while. Busy with a large BPM design for a migration factory. And for my own migration :-) : moving to a new town. Dust is settling now, so time to blog more about BPM (lot's of new insights...).
Well, I am in London, and while be joining the BPM summit of Gartner. Will try to blog each day on the highlights. Looking forward hearing the newest insights on BPM. The program is loaded with potential interesting presentations!

BAM and visibility - driving 50 Mph without a steeringwheel?

Recently I say two interesting articles, dealing with "management" as a separate proces-area.
See:
http://bpmbusiness.typepad.com/business_of_bpm/2007/01/bpm_and_six_sig_1.html, who writes about control and BAM (and confuses the two)
And...
http://www.bptrends.com/publicationfiles/advisor20070227.pdf, a good article about management as a process, in relation to BPM.

I am working currently on an interesting project, which needs to quickly build a administration factory, that is able to handle a large volume of transactions (which are partly client facing, partly technical, involving a large number of stakeholders, including the unavoidable indian offshore backoffice). My client has already done good work on the key processes, however I quickly discovered that we needed to distinguish between a number of proces area's, with different levels of control.
The first level was the operational level: the exact process to handle a transaction. Most focus seem to go here, typically (and also for this client).
However, two more levels were needed:
A level, which is above the transaction layer, which I call the "logistical process layer". It's the whole operational planning and coordination of the large volume of transactions. Here, business rules and approaches such as Lean, TOC and operations research come in. At this level we design the factory, making sure it will be able to support the transaction amounts.
A third layer is what I call "governance". Here we talk about planning and steering on a higher level. Maybe you could call it planning & control, or simply management: making sure the goals of the factory are reached.

Back to management. I find it interesting, that a lot of attention in the BPM area is currently going to BAM - Business Activity Monitoring. And most people are enchanted - wow, we can provide management with almost real-time information at their fingertips.

My observation:
If your car is running at 50 Mph, the oil level is fine, the lights are on, the motor temperature is on, the airconditioning-temperature in the car is 20 degrees celcius, the time is 10.25, engine RPM is 100, and you see a tree approaching fast, a steer and a break would be nice....

In short: BAM without a Control mechanism does not add value
(well, ok, at least you'll know you will crash)

Or: don't measure if you can't steer
(So, I agree with Gartner that visibility is a great thing as a result from BPM, but it's not the full answer to business BPM needs...)

It links back to a lot of lessons people learned from Business Intelligence projects. Sure, in the beginning management will be thrilled, and will ask for various KPI's. Even so for BAM.
But quickly, you will find they are no longer looking at all the numbers. Why? Because KPI's that are not in their control are simply not relevant. KPI's that are in their control, and (ok, this might be simplifying things) are linked to some personal commitment (such as bonus, prestige, pain-such as be fired) will get the most attention.
Actually, KPI's that are not in their control will make them feel awkward (compare it to the feeling you get when confronted with global warming, hunger in africa, forrest destruction in brazil - it's all in the news (KPI's), but what (little) can I do about it??)

So, when designing a BPM environment, advices:
- Do design a management proces as well (plan do check act)
- Determine what controls the manager has (and which are linked to his/her(!) areas of interest)
- Define the KPI's (and frequency/events - alerts)
- Make sure that the controls are in some way known/modelled as well "if KPI X is below Y, then ....."

Hm. Controls. E.g. the "Act" when the "Check" did not satisfy the manager. What type of controls can you think of?

Here we get back to classic management theory:
- Operational management decisions:
- Set a different priority for a certain task/set of tasks "staff, please fix Client A NOW!"
- Re-assign work "Jim, please take over this task, and Mary, take Jack's job"
- Shout "Why didn't you do this already??" or ask "Could you please handle this now?"
- Quickly add resources "Get some temp workers right away"
- Create adhoc fixed to the process, probably specific to a certain transaction "forget check A for now!"
- Adhoc reward people (with money, fun, interesting challenges, etc)
- Coach, coach, coach
- Tactical management decisions:
- Send people to training
- Replace people, increase staff or decrease
- Analyse waste (Lean), including Defects (why, how often, how to prevent?)
- More structural changes/optimizations to the process - tune logistics and business rules
- Automate certain steps/innovate certain parts of the process
- Reward people more structurally (and grow them)
- Fire the manager :-)

A BPM system (or a manual BPM framework) will help here. A BPM system can support quick tuning of process (steps, assignment rules, flow business rules)

Realize...
- Sure, a maximum optimized operational process is needed...
- However, if the management proces is ad-hoc, chaotic and immature, I bet fire fighting will drive out any good operational process
- And let's not forget, these managers are expensive, so let's make their process as efficient as possible as well :-)

So, are you designing operational processes with control in mind?
Motto: if the manager wants BPM, then his process will be BPM-ed too!