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!
Monday, May 28, 2007
Tuesday, May 08, 2007
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.
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.
Sunday, May 06, 2007
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!)
- 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!)
Thursday, May 03, 2007
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....)
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....)
Wednesday, May 02, 2007
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....
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....
Sunday, April 22, 2007
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?
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?
Saturday, April 21, 2007
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!
Saturday, April 14, 2007
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?
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?
Wednesday, April 11, 2007
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.
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!
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...
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...
Saturday, April 07, 2007
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 :-)
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 :-)
Tuesday, March 27, 2007
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 :-)
"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...
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).
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!
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!
Sunday, March 25, 2007
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!
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!
Friday, March 02, 2007
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!
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!
Saturday, February 24, 2007
Some of my favourite BPM Blogs
Here are my favourites. If I miss a good one, let me know!
http://improving-nao.blogspot.com/
http://www.column2.com/
http://www.brsilver.com/wordpress
http://www.ebizq.net/blogs/bpmblog/
http://kswenson.wordpress.com/
http://www.bpminaction.com/blog/
http://blog.lombardicto.com/
http://www.itredux.com/blog/
http://www.edmblog.com/
http://www.ebizq.net/blogs/it_directions/
http://blogs.ittoolbox.com/erp/bpms
http://improving-nao.blogspot.com/
http://www.brsilver.com/wordpress
http://www.ebizq.net/blogs/bpmblog/
http://kswenson.wordpress.com/
http://www.bpminaction.com/blog/
http://blog.lombardicto.com/
http://www.itredux.com/blog/
http://www.edmblog.com/
http://www.ebizq.net/blogs/it_directions/
http://blogs.ittoolbox.com/erp/bpms
Late at night - a small Godel, Escher, Bach thought on BPM
Ok, it's late, going to bed soon.
But I got triggered by a small sentence on
http://www.bpm.com/BriefingRO.asp?BriefingId=29
stating "the need for a tool to “manage the process of process management.”
Hm. Question to all BPM-people: how is the business process management of our business process management efforts....
If I read the sentence, it's almost like getting yourself out of a swamp, by pulling your own hair (that's an old fairytale reference :-)).
But seriously, is it possible to...
- Model your process management efforts
- Execute them
- Measure them
- Improve them
?
What KPI's can we define for process management efforts?
- Nr of models completed...
- Cycle time per model...
- Complexity of delivered models...
- Cost per model
- Nr of process issues identified. Nr of solved.
- Nr of process improvement ideas identified. Nr of implemented.
- Delivered business case
- Average business case per improvement idea
A big question is: can we define a model for, say proces modelling?
And interesting - if people feel awkward here, and doubt about the possibility to model the process modelling effort, well, how do you think your stakeholders feel if you come to model their process???? Right.
Good night.
But I got triggered by a small sentence on
http://www.bpm.com/BriefingRO.asp?BriefingId=29
stating "the need for a tool to “manage the process of process management.”
Hm. Question to all BPM-people: how is the business process management of our business process management efforts....
If I read the sentence, it's almost like getting yourself out of a swamp, by pulling your own hair (that's an old fairytale reference :-)).
But seriously, is it possible to...
- Model your process management efforts
- Execute them
- Measure them
- Improve them
?
What KPI's can we define for process management efforts?
- Nr of models completed...
- Cycle time per model...
- Complexity of delivered models...
- Cost per model
- Nr of process issues identified. Nr of solved.
- Nr of process improvement ideas identified. Nr of implemented.
- Delivered business case
- Average business case per improvement idea
A big question is: can we define a model for, say proces modelling?
And interesting - if people feel awkward here, and doubt about the possibility to model the process modelling effort, well, how do you think your stakeholders feel if you come to model their process???? Right.
Good night.
Subscribe to:
Posts (Atom)