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....
Subscribe to:
Posts (Atom)