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?
Sunday, April 22, 2007
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 :-)
Subscribe to:
Posts (Atom)