Recently, I participated in a survey where they asked: what are key best practices that a solution architect should remember. When I reread my answers, I found that my best practices actually also work fine for process architects.
Here they are:
1. Beware YAGNI (You are not going to use it): base your solution architecture on traceable requirements and no more
2. Mind the coupling of components: the less a component knows, the better
3. Beware TAGRI (They aren’t going to read it): travel light, document what’s necessary and translate/summarize to various stakeholder viewpoints to get buy-in (or at least understanding)
(TAGRI was defined by Scott Ambler, in a great essay: http://www.agilemodeling.com/essays/tagri.htm)
4. Business managers don’t care about SOA. They care about that customers are served, employees can do their job, cost, time to market and flexibility/agility
5. Have a clear conceptual model of the concepts that you will use (logical component, technical function, datamodel, etc) and how these concepts relate + trace back (and forward) to other artifacts
6. Talk to the system management people too – certain non-functionals (reliability, security, etc) will drive a lot of your architecture and these people need to become your friend too…
7. The sooner the people in your team start coding, the longer it’s going to take
8. Business analysts focus on the WHY and WHAT and represent demand, architects focus on the HOW (and WHY HOW) and represent supply, don’t get this mixed up
9. Focus on the complex scary stuff first, even though the simple stuff might make you seem to have a lot of progress
Friday, February 27, 2009
Thursday, February 26, 2009
A new form of business rule mining and validation?
I am fully emerged in a business rules automation project, as a process consultant for rules governance.
Last week I received training in the business rules management suite that is used within the project (Be Informed, a promising dutch player, see their website).
And it brought me back years ago, when I was programming (during my time @ university) in Prolog.
Part of my Prolog assignment back then, was to implement an algorithm (from Quinlan) from the Artificial Intelligence - Machine learning domain (see for instance http://en.wikipedia.org/wiki/Supervised_learning).
It worked basically as follows:
You gave it a set of examples, in which each example contained a set of variables and their data, and an associated classification.
For instance:
(Color=Red, Tiers=True, NrOfTiers=4, Engine=True, Sail=False, CanBeInWater=False) -> Car
(Color=Green, Tiers=True, NrofTiers=2, Engine=False, Sail=False, CanBeInWater=False) -> Bike
(Color=White, Tiers=False, NrOfTiers=n/a, Engine=False, Sail=True, CanBeInWater=True) -> Sailingboat
Etc.
When you ran the algorithm, it was able to analyse the examples and classifications, and come up with a minimum set of rules that matched the key determining variables and classification, e.g.:
(Tiers=True, NrOfTiers=4, Engine=True) -> Car
(Tiers=True, NrOfTiers=2, Engine=False) -> Bike
Back to the project....
Considerable time is currently spent in the project for business rule elicitation. Workshops, study of systems, analysing documents, analysing legislation, etc.
In a recent project someone in my company worked with Process Mining, in which logfiles were analysed, and based on the logfile a process diagram was constructed (+ all kinds of performance data).
Adding algorithm, effort and the concept of process mining, made me look up Rule Mining (see http://en.wikipedia.org/wiki/Business_rule_mining). Strangly enough this differs from the concept of Process mining (it does not analyse data, but code).
And this triggered the following "Wouldn't it be cool" idea:
What if we constructed a strong machine learning algorithm component in a business rules management suite, that was able to analyse great sets of (historic) production data and construct the business rule set that was apparently used?
Example: we have a large CRM database and a Billing system. We create a combined table:
(Customer data), (Order data), (Billing Data) and select certain variables that we want to explain, using business rules based on the remaining variables.
For instance: what are the rules for VAT, discount and Gold membership?
The algorithm would do it's work, and create the minimal rule set...
For instance:
(Country=Netherlands) -> (VAT=19%)
(Orderamount > 200, OrderAmount <300, country =" Germany," customerindustry =" Bank)"> (Discount = 5%)
I see a number of benefits:
- Saving time for rules elicitation
- Retroactively understand what rules where used, and compare them to the existing policies (compliance checks)
Do any of the current BRMS have this feature already? (Time to patent ;-))
For a great overview of machine learning basics:
http://www.informatica.si/PDF/31-3/11_Kotsiantis%20-%20Supervised%20Machine%20Learning%20-%20A%20Review%20of...pdf
Last week I received training in the business rules management suite that is used within the project (Be Informed, a promising dutch player, see their website).
And it brought me back years ago, when I was programming (during my time @ university) in Prolog.
Part of my Prolog assignment back then, was to implement an algorithm (from Quinlan) from the Artificial Intelligence - Machine learning domain (see for instance http://en.wikipedia.org/wiki/Supervised_learning).
It worked basically as follows:
You gave it a set of examples, in which each example contained a set of variables and their data, and an associated classification.
For instance:
(Color=Red, Tiers=True, NrOfTiers=4, Engine=True, Sail=False, CanBeInWater=False) -> Car
(Color=Green, Tiers=True, NrofTiers=2, Engine=False, Sail=False, CanBeInWater=False) -> Bike
(Color=White, Tiers=False, NrOfTiers=n/a, Engine=False, Sail=True, CanBeInWater=True) -> Sailingboat
Etc.
When you ran the algorithm, it was able to analyse the examples and classifications, and come up with a minimum set of rules that matched the key determining variables and classification, e.g.:
(Tiers=True, NrOfTiers=4, Engine=True) -> Car
(Tiers=True, NrOfTiers=2, Engine=False) -> Bike
Back to the project....
Considerable time is currently spent in the project for business rule elicitation. Workshops, study of systems, analysing documents, analysing legislation, etc.
In a recent project someone in my company worked with Process Mining, in which logfiles were analysed, and based on the logfile a process diagram was constructed (+ all kinds of performance data).
Adding algorithm, effort and the concept of process mining, made me look up Rule Mining (see http://en.wikipedia.org/wiki/Business_rule_mining). Strangly enough this differs from the concept of Process mining (it does not analyse data, but code).
And this triggered the following "Wouldn't it be cool" idea:
What if we constructed a strong machine learning algorithm component in a business rules management suite, that was able to analyse great sets of (historic) production data and construct the business rule set that was apparently used?
Example: we have a large CRM database and a Billing system. We create a combined table:
(Customer data), (Order data), (Billing Data) and select certain variables that we want to explain, using business rules based on the remaining variables.
For instance: what are the rules for VAT, discount and Gold membership?
The algorithm would do it's work, and create the minimal rule set...
For instance:
(Country=Netherlands) -> (VAT=19%)
(Orderamount > 200, OrderAmount <300, country =" Germany," customerindustry =" Bank)"> (Discount = 5%)
I see a number of benefits:
- Saving time for rules elicitation
- Retroactively understand what rules where used, and compare them to the existing policies (compliance checks)
Do any of the current BRMS have this feature already? (Time to patent ;-))
For a great overview of machine learning basics:
http://www.informatica.si/PDF/31-3/11_Kotsiantis%20-%20Supervised%20Machine%20Learning%20-%20A%20Review%20of...pdf
Thursday, February 19, 2009
BPM vendor brand confusion vs analyst power....
Hmmm,
Received emails from two different vendors, with an invite for Gartner's European BPM conference. Strange, same template, same discount.
Singularity and Metastorm.
If I scan the text, appearantly the BPM vendors are allowed to place 1 - 2 line of own text. Talk about Analyst power....
Singularity will be demonstrating how you can urgently cut operational costs in the shortest possible timescales using our unique high-speed process reengineering approach.
Metastorm is the leading provider of business process solutions. Metastorm BPM® allows you to quickly implement, manage, monitor and analyze improved business processes.
===============
Gartner Business Process Management Summit 2009Using BPM to Thrive, Survive and Capitalize
Register Now
Summit Website
Other Gartner Events
Dear Roeland,Singularity is delighted to support the Gartner Business Process Management Summit 2009 taking place 23-25 February 2009 in London and, as sponsors, we are able to offer you a special 20% discount* on the standard registration fee!Gartner predicts: More than 50% of BPM programs will fail by 2011. How do you make sure your BPM program will be successful by 2011?While you can’t control the economy, you can control the business processes that lie at the very heart of your organization’s ability to survive, thrive and capitalize, even in the most volatile of circumstances.Hear it first at the Gartner Business Process Management Summit, 23 – 25 February, in London. Discover the latest BPM developments, business insights, research and case studies that will help you to:
•
Deepen your understanding of process-driven innovation, continuous process improvement and efficiency
•
Sell a BPM project’s value and obtain executive buy-in
•
Gain the latest change management advice to accelerate business transformation
•
Navigate the BPM vendor landscape to evaluate and select vendors and service providers to invest in the right tools for better planning, budgeting and forecast
•
Learn best practices with BPM project management do's and don'ts to save time, money and effort
•
Recognize the opportunity to avoid costly BPM integration nightmares!
Business Process Management has been at the top of the CIO’s agenda for the past several years and the challenging economic climate makes BPM even more of a strategic imperative.Make better BPM investment decisions, health check your plans and projects and get connected at the Gartner Business Process Management Summit, 23–25 February, in London, the most relevant, timely and important conference.Singularity will be demonstrating how you can urgently cut operational costs in the shortest possible timescales using our unique high-speed process reengineering approach. Review the program and register today.Your processes have never been more important.Online: europe.gartner.com/bpm Phone: +44 (0)20 8879 2430Email: enquiries.events@gartner.com*This discount offer does not apply retrospectively.
europe.gartner.com/bpm
Price Discount
We can offer you a special 20% discount on the standard registration fee - a saving of €539! Register Now and quote XXXXXX to receive your 20% discount.
Team Benefits
No single delegate can possibly cover an entire Summit and extract all of its value. That's why so many enterprises send entire teams.– Get preferential access, as a team, to your preferred analyst of choice – Exclusive meeting rooms for intrateam meetings onsite, subject to availability
Analyst One-on-One
Don't miss out on the opportunity to spend 30 minutes privately, for FREE, discussing a topic of your choice with a Gartner analyst who specializes in this area. (registration is required) Register Now
View the Brochure
© 2009 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates.
PrivacySingularity provides a variety of information through its website pages and offers readers of that information the opportunity to request further information or interaction with Singularity. This Privacy Policy outlines Singularity's approach to use of information you might supply to us during these interactions. Please read full Privacy Policy hereUnsubscribePlease send us an email with the title "Unsubscribe" to: m.white@singularity.co.uk
Gartner Business Process Management Summit 2009Using BPM to Thrive, Survive and Capitalize
Register Now
Summit Website
Other Gartner Events
Metastorm is delighted to support the Gartner Business Process Management Summit 2009 taking place 23-25 February 2009 in London and, as sponsors, we are able to offer you a special 20% discount* on the standard registration fee!Gartner predicts: More than 50% of BPM programs will fail by 2011. How do you make sure your BPM program will be successful by 2011?While you can’t control the economy, you can control the business processes that lie at the very heart of your organization’s ability to survive, thrive and capitalize, even in the most volatile of circumstances.Hear it first at the Gartner Business Process Management Summit, 23 – 25 February, in London. Discover the latest BPM developments, business insights, research and case studies that will help you to:
•
Deepen your understanding of process-driven innovation, continuous process improvement and efficiency
•
Sell a BPM project’s value and obtain executive buy-in
•
Gain the latest change management advice to accelerate business transformation
•
Navigate the BPM vendor landscape to evaluate and select vendors and service providers to invest in the right tools for better planning, budgeting and forecast
•
Learn best practices with BPM project management do's and don'ts to save time, money and effort
•
Recognize the opportunity to avoid costly BPM integration nightmares!
Business Process Management has been at the top of the CIO’s agenda for the past several years and the challenging economic climate makes BPM even more of a strategic imperative.Make better BPM investment decisions, health check your plans and projects and get connected at the Gartner Business Process Management Summit, 23–25 February, in London, the most relevant, timely and important conference.Metastorm is the leading provider of business process solutions. Metastorm BPM® allows you to quickly implement, manage, monitor and analyze improved business processes.Review the program and register today.Your processes have never been more important.Online: europe.gartner.com/bpm Phone: +44 (0)20 8879 2430Email: enquiries.events@gartner.com*This discount offer does not apply retrospectively.
europe.gartner.com/bpm
Price Discount
We can offer you a special 20% discount on the standard registration fee - a saving of €539! Register Now and quote XXXXXXXX to receive your 20% discount.
Team Benefits
No single delegate can possibly cover an entire Summit and extract all of its value. That's why so many enterprises send entire teams.– Get preferential access, as a team, to your preferred analyst of choice – Exclusive meeting rooms for intrateam meetings onsite, subject to availability
Analyst One-on-One
Don't miss out on the opportunity to spend 30 minutes privately, for FREE, discussing a topic of your choice with a Gartner analyst who specializes in this area. (registration is required) Register Now
View the Brochure
© 2009 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates.
Metastorm Ltd. is a company registered in England and Wales with company number 2322265.Keep email from Metastorm coming! To make sure you continue to receive our emails, please add contact_metastorm.com@mail.vresp.com to your address book or approved sender list.If you no longer wish to receive these emails, please reply to this message with "Unsubscribe" in the subject line or simply click on the following link: Unsubscribe
Click here to forward this email to a friend
MetastormCentral House,1 Alwyne Road,London, England SW19 7ABUK
Read the VerticalResponse marketing policy.
Received emails from two different vendors, with an invite for Gartner's European BPM conference. Strange, same template, same discount.
Singularity and Metastorm.
If I scan the text, appearantly the BPM vendors are allowed to place 1 - 2 line of own text. Talk about Analyst power....
Singularity will be demonstrating how you can urgently cut operational costs in the shortest possible timescales using our unique high-speed process reengineering approach.
Metastorm is the leading provider of business process solutions. Metastorm BPM® allows you to quickly implement, manage, monitor and analyze improved business processes.
===============
Gartner Business Process Management Summit 2009Using BPM to Thrive, Survive and Capitalize
Register Now
Summit Website
Other Gartner Events
Dear Roeland,Singularity is delighted to support the Gartner Business Process Management Summit 2009 taking place 23-25 February 2009 in London and, as sponsors, we are able to offer you a special 20% discount* on the standard registration fee!Gartner predicts: More than 50% of BPM programs will fail by 2011. How do you make sure your BPM program will be successful by 2011?While you can’t control the economy, you can control the business processes that lie at the very heart of your organization’s ability to survive, thrive and capitalize, even in the most volatile of circumstances.Hear it first at the Gartner Business Process Management Summit, 23 – 25 February, in London. Discover the latest BPM developments, business insights, research and case studies that will help you to:
•
Deepen your understanding of process-driven innovation, continuous process improvement and efficiency
•
Sell a BPM project’s value and obtain executive buy-in
•
Gain the latest change management advice to accelerate business transformation
•
Navigate the BPM vendor landscape to evaluate and select vendors and service providers to invest in the right tools for better planning, budgeting and forecast
•
Learn best practices with BPM project management do's and don'ts to save time, money and effort
•
Recognize the opportunity to avoid costly BPM integration nightmares!
Business Process Management has been at the top of the CIO’s agenda for the past several years and the challenging economic climate makes BPM even more of a strategic imperative.Make better BPM investment decisions, health check your plans and projects and get connected at the Gartner Business Process Management Summit, 23–25 February, in London, the most relevant, timely and important conference.Singularity will be demonstrating how you can urgently cut operational costs in the shortest possible timescales using our unique high-speed process reengineering approach. Review the program and register today.Your processes have never been more important.Online: europe.gartner.com/bpm Phone: +44 (0)20 8879 2430Email: enquiries.events@gartner.com*This discount offer does not apply retrospectively.
europe.gartner.com/bpm
Price Discount
We can offer you a special 20% discount on the standard registration fee - a saving of €539! Register Now and quote XXXXXX to receive your 20% discount.
Team Benefits
No single delegate can possibly cover an entire Summit and extract all of its value. That's why so many enterprises send entire teams.– Get preferential access, as a team, to your preferred analyst of choice – Exclusive meeting rooms for intrateam meetings onsite, subject to availability
Analyst One-on-One
Don't miss out on the opportunity to spend 30 minutes privately, for FREE, discussing a topic of your choice with a Gartner analyst who specializes in this area. (registration is required) Register Now
View the Brochure
© 2009 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates.
PrivacySingularity provides a variety of information through its website pages and offers readers of that information the opportunity to request further information or interaction with Singularity. This Privacy Policy outlines Singularity's approach to use of information you might supply to us during these interactions. Please read full Privacy Policy hereUnsubscribePlease send us an email with the title "Unsubscribe" to: m.white@singularity.co.uk
Gartner Business Process Management Summit 2009Using BPM to Thrive, Survive and Capitalize
Register Now
Summit Website
Other Gartner Events
Metastorm is delighted to support the Gartner Business Process Management Summit 2009 taking place 23-25 February 2009 in London and, as sponsors, we are able to offer you a special 20% discount* on the standard registration fee!Gartner predicts: More than 50% of BPM programs will fail by 2011. How do you make sure your BPM program will be successful by 2011?While you can’t control the economy, you can control the business processes that lie at the very heart of your organization’s ability to survive, thrive and capitalize, even in the most volatile of circumstances.Hear it first at the Gartner Business Process Management Summit, 23 – 25 February, in London. Discover the latest BPM developments, business insights, research and case studies that will help you to:
•
Deepen your understanding of process-driven innovation, continuous process improvement and efficiency
•
Sell a BPM project’s value and obtain executive buy-in
•
Gain the latest change management advice to accelerate business transformation
•
Navigate the BPM vendor landscape to evaluate and select vendors and service providers to invest in the right tools for better planning, budgeting and forecast
•
Learn best practices with BPM project management do's and don'ts to save time, money and effort
•
Recognize the opportunity to avoid costly BPM integration nightmares!
Business Process Management has been at the top of the CIO’s agenda for the past several years and the challenging economic climate makes BPM even more of a strategic imperative.Make better BPM investment decisions, health check your plans and projects and get connected at the Gartner Business Process Management Summit, 23–25 February, in London, the most relevant, timely and important conference.Metastorm is the leading provider of business process solutions. Metastorm BPM® allows you to quickly implement, manage, monitor and analyze improved business processes.Review the program and register today.Your processes have never been more important.Online: europe.gartner.com/bpm Phone: +44 (0)20 8879 2430Email: enquiries.events@gartner.com*This discount offer does not apply retrospectively.
europe.gartner.com/bpm
Price Discount
We can offer you a special 20% discount on the standard registration fee - a saving of €539! Register Now and quote XXXXXXXX to receive your 20% discount.
Team Benefits
No single delegate can possibly cover an entire Summit and extract all of its value. That's why so many enterprises send entire teams.– Get preferential access, as a team, to your preferred analyst of choice – Exclusive meeting rooms for intrateam meetings onsite, subject to availability
Analyst One-on-One
Don't miss out on the opportunity to spend 30 minutes privately, for FREE, discussing a topic of your choice with a Gartner analyst who specializes in this area. (registration is required) Register Now
View the Brochure
© 2009 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates.
Metastorm Ltd. is a company registered in England and Wales with company number 2322265.Keep email from Metastorm coming! To make sure you continue to receive our emails, please add contact_metastorm.com@mail.vresp.com to your address book or approved sender list.If you no longer wish to receive these emails, please reply to this message with "Unsubscribe" in the subject line or simply click on the following link: Unsubscribe
Click here to forward this email to a friend
MetastormCentral House,1 Alwyne Road,London, England SW19 7ABUK
Read the VerticalResponse marketing policy.
Thursday, January 29, 2009
BRM - not: BR projects!
As I am involved in trying to define, design and implement "business rules governance" (in terms of events, processes, roles, responsibilities, products, etc), I am amazed how tool focused the world currently is (both in rules and BPM).
Checking most vendors site's reveal most of them have "methodologies" to implement their tools, mainly on a project basis. But no word on what type of processes and governance you need when the project has ended.
I find that strange: agility comes after the project, and you will need more than a tool.
Additional confusing factor: that most vendors, when asked about "Business Rules Management" start talking about features in their tools.
I saw the same thing in the BPM market, but slowly, very slowly, BPM technology vendors start understanding the BPM is a management discipline credo, and see that features are there to support process governance processes.....
Checking most vendors site's reveal most of them have "methodologies" to implement their tools, mainly on a project basis. But no word on what type of processes and governance you need when the project has ended.
I find that strange: agility comes after the project, and you will need more than a tool.
Additional confusing factor: that most vendors, when asked about "Business Rules Management" start talking about features in their tools.
I saw the same thing in the BPM market, but slowly, very slowly, BPM technology vendors start understanding the BPM is a management discipline credo, and see that features are there to support process governance processes.....
Execution excellence? Tools will help, but you need governance
I am currently involved in a large transformation program for a Dutch governmental agency. They are busy with pretty innovative stuff: case management, business rules, automated decisions, rules engines, document management - e.g. all the ingredients for the modern data processing company.
A number of key goals:
- Agility - the ability to respond to changes in external (and internal) laws, policies rules in a quick and effective way, with low cost and low risk
- Visbility & Compliance - the assurance that policies and rules are followed
- Efficiency
This organization realized that these goals required more than just an innovative application landcape. They realized for instance that employing rules technology only brings real benefit if they build a capability to quickly and correctly analyse, change and deploy rules. This requires a number of clear processes, value adding workproducts, responsibilities, supporting tooling, trained resources.
I was brought in to support them to define these things and to implement them. I would call it: implementing business rules governance.
For me, partly this is a BPM job: making the organization more process focused, to that they can deliver change in a controlled but agile way. But as a BPM consultant, working also frequently in IT process improvement, I started thinking.
My key question is becoming: we have great control/process frameworks around managing aspects between business and IT:
- ITIL for infrastructure
- ASL (mainly used in Holland) for application maintenance and management
- BISL (mainly used in Holland) for information management and business oriented IT "functioneel beheer"
All of these items create control/governance for some (IT)support or change part of the business operations.
But we see slowly a trend that business/IT control and alignment is reached by creating control over the following items:
- Business Processes
- Business Rules
- Information
- Functionality
At this stage we tend to approach this things separately (expect maybe from a EA/business architecture perspective, but these initiatives never want to be involved in "support" or other nitty gritty detail). The result if we would follow all the Gartner and Forrester reports, is that we end up with at least 4 different center of excellences, governance structures and the lot. This is a bit strange, since these 4 areas are typically very related, and impacted with a change. Which would result in a lot of collaboration and possible confusions (since language/concepts in each area differs....)
My dream would be that some type of business oriented ITIL process framework would be created, that helps companies manage these 4 items in an integrated way. And when a change is needed, the companie capability based on this framework (people, processes, roles, departments, products, etc) would enable organizations to quickly respond..
The "integrated business & IT change governance" services library or something.
One stop shopping for your changes in business process, rules, information and requirements/functionality from systems.
"IBIGSL"?
A number of key goals:
- Agility - the ability to respond to changes in external (and internal) laws, policies rules in a quick and effective way, with low cost and low risk
- Visbility & Compliance - the assurance that policies and rules are followed
- Efficiency
This organization realized that these goals required more than just an innovative application landcape. They realized for instance that employing rules technology only brings real benefit if they build a capability to quickly and correctly analyse, change and deploy rules. This requires a number of clear processes, value adding workproducts, responsibilities, supporting tooling, trained resources.
I was brought in to support them to define these things and to implement them. I would call it: implementing business rules governance.
For me, partly this is a BPM job: making the organization more process focused, to that they can deliver change in a controlled but agile way. But as a BPM consultant, working also frequently in IT process improvement, I started thinking.
My key question is becoming: we have great control/process frameworks around managing aspects between business and IT:
- ITIL for infrastructure
- ASL (mainly used in Holland) for application maintenance and management
- BISL (mainly used in Holland) for information management and business oriented IT "functioneel beheer"
All of these items create control/governance for some (IT)support or change part of the business operations.
But we see slowly a trend that business/IT control and alignment is reached by creating control over the following items:
- Business Processes
- Business Rules
- Information
- Functionality
At this stage we tend to approach this things separately (expect maybe from a EA/business architecture perspective, but these initiatives never want to be involved in "support" or other nitty gritty detail). The result if we would follow all the Gartner and Forrester reports, is that we end up with at least 4 different center of excellences, governance structures and the lot. This is a bit strange, since these 4 areas are typically very related, and impacted with a change. Which would result in a lot of collaboration and possible confusions (since language/concepts in each area differs....)
My dream would be that some type of business oriented ITIL process framework would be created, that helps companies manage these 4 items in an integrated way. And when a change is needed, the companie capability based on this framework (people, processes, roles, departments, products, etc) would enable organizations to quickly respond..
The "integrated business & IT change governance" services library or something.
One stop shopping for your changes in business process, rules, information and requirements/functionality from systems.
"IBIGSL"?
Tuesday, January 06, 2009
Police and protocols
Recently, by accident I was listening to the radio when a quite good show was on. The program gave an insight in the workings of the police. The story was about the arrest of three criminals, and as the reports was "embedded", one could follow all the activities.
It turns out that during arrests, three teams are involved:
- the "AT" - the arrest team
- the "OT" - the observation team
- the "RT" - the research team
The observation team was simply responsible for providing observation on all relevent information on the criminal's behaviour: where were they, what were they doing, how many other people where there, what where the properties of the location (rooms, setup, access points, etc), possibility of weapons. They provided the arrestteam with a constant stream of updates of relevant information.
The researchteam would have its role after the arrest, carefully researching the premises (including cars, computers, etc) on signs (fingerprints, drugs, administration, etc).
The arrestteam had a large responsibility: to arrest the criminals, in such a way that minimal risk was created for the police, citizens and the criminals.
A number of people were interviewed, being asked to comment on the succes of specific arrestteams. Two key succesfactors that came up were "protocols" and "local intelligence".
A protocol is a set of specific steps, triggered when a specific situation needed to be created and solved. It turned out that AT's had about 3 key protocols: make an arrest in a house, stopping a moving car (and arrest the people inside it) and arrest someone on the street. And it turned out that these protocols were practiced many many times, to the point that people would automatically be able to perform them.
Local intelligence is the ability to succesfully improvise when during execution of a protocol, the circuimstances required this.
Hm, protocol and local intelligence?
It triggered the following thoughts:
We are talking about helping a (interchangable) group of people to deliver optimal results when faced with a certain triggering situation. That's what I would call a business process.
They recognized that the better these people were able to perform the protocol the less risks and the more success the groups had. We tend to forget this in BPM, or leave it to "change management".
They practice these protocols many many times. This is something in business processes is not done often. We might get a bit of training, read the process instructions or get training on the job. Not a bad idea: process practice training.
As a side though: I see many (BPM/IT))projects struggle for a related reason: lack of protocol and lack of protocol practice.....
It turns out that during arrests, three teams are involved:
- the "AT" - the arrest team
- the "OT" - the observation team
- the "RT" - the research team
The observation team was simply responsible for providing observation on all relevent information on the criminal's behaviour: where were they, what were they doing, how many other people where there, what where the properties of the location (rooms, setup, access points, etc), possibility of weapons. They provided the arrestteam with a constant stream of updates of relevant information.
The researchteam would have its role after the arrest, carefully researching the premises (including cars, computers, etc) on signs (fingerprints, drugs, administration, etc).
The arrestteam had a large responsibility: to arrest the criminals, in such a way that minimal risk was created for the police, citizens and the criminals.
A number of people were interviewed, being asked to comment on the succes of specific arrestteams. Two key succesfactors that came up were "protocols" and "local intelligence".
A protocol is a set of specific steps, triggered when a specific situation needed to be created and solved. It turned out that AT's had about 3 key protocols: make an arrest in a house, stopping a moving car (and arrest the people inside it) and arrest someone on the street. And it turned out that these protocols were practiced many many times, to the point that people would automatically be able to perform them.
Local intelligence is the ability to succesfully improvise when during execution of a protocol, the circuimstances required this.
Hm, protocol and local intelligence?
It triggered the following thoughts:
We are talking about helping a (interchangable) group of people to deliver optimal results when faced with a certain triggering situation. That's what I would call a business process.
They recognized that the better these people were able to perform the protocol the less risks and the more success the groups had. We tend to forget this in BPM, or leave it to "change management".
They practice these protocols many many times. This is something in business processes is not done often. We might get a bit of training, read the process instructions or get training on the job. Not a bad idea: process practice training.
As a side though: I see many (BPM/IT))projects struggle for a related reason: lack of protocol and lack of protocol practice.....
Sunday, December 07, 2008
3 for 1 - There are more processes in your scope
When analyzing and implementing processes, I found out that we (ok, that includes me...) often focus too much on the core "content" process at hand. We dive into the main "named" processes that are in our scope, focus on the participants, activities, rules, etc. - model them, design improved processes and implement them. But due to this focus on "named content" we tend to forget that every process actually turns out to be three processes (and maybe even 3 more, more on this later).
If we only explore the main one, the other's are either implicitely covered, or completely forgotten, with all negative (change) consequences.
As an example: suppose our scope is "provide quote", in, say, a credit lending bank area. As analysts we dive into the process, find and model all activities - receive quote request, determine credit worthiness, calculate proposed interest rate, create quote, send quote, etc.
And if we are lucky, some analyst might even ask - what are KPI's or what is the management information that is required for the people steering this process? That person felt possibly intuitively that there are other processes floating around.
We might end up with a great "provide quote" process, and yet we might face issues around change management and reinforcement of improvements.
Let's get to the point:
The three processes that "hide in every process" in my opinion are:
- The "content process" - e.g. the main process, aimed at fullfilling the specific customer request, activities leading to the transformation of input to output
- The "operational management process" - the proces (usually plan-do-check-act) of making sure that the "content process" keeps performing.
- The "improve and (re)align process" - the process of "sharpening the saw", making sure that the content process (and operational management process) are improved, and when strategy changes of the company occur, that these processes are adapted to the new strategy .
Some thoughts...
1. As said, most of analyst's attention typically is spend on the "content process". That's ok, since in the end, if that does not run well, we end up with nothing. But let's not forget the other processes....
2. If we look at the operational management process, we might have analysts remembering that we need "management information". That's a step, but not the complete one. Steering requires a number of "process items":
- Who is steering?
- What process is followed for the steering?
- What possibilities are there for interventions ("act"), if process performance is not acceptable? According to what policies and rules?
- What information is required to steer (for planning, for checking), with what frequencies, in what form?
If we only focus on management information, we forget to focus on understanding and implementing the operational management process. Something I earlier wrote about in
"driving 50 MPH without a steer".
3. Interestly, whenever I start talking about operational management, process participants start to look "upward" to a management level. That's a choice, and usually determined by company culture.
My point is: many of the operational management activities you can also place at the process participants level. Many principles ("when is our process functioning fine, and in what situations should we act to correct issues) can better be done by the process participants themselves - they have the knowledge and see things happening. Instead of thinking "I should focus on the process and not the issue, my manager should fix this", we can make them responsible for steering as well. "When I see someone in my team having too much work, I will jump in and help", "When I see an error, I fix it, and make sure we don't make the same error again"...
4. You might object, and say "operational management" and possibly even more "improve and (re)align" should be part of a top-down scope in which we create a BPM framework for management. Sure, that's fine - if it's there. But in many situations that might take a long time. Don't wait for it - start bottom-up/middle out, learn and evaluate.
Conclusion: focus on content is fine, but don't forget to implement operational management and improve/(re)align.
As a PS:
I talked about possibly three more. These are:
- Your supplier and customer processes. What steps do they need to take to deliver and get their need fulfillled? If we forget to look at these processes, then we also miss out on possibly great opportunities for improvement in their and our own processes.
- Supporting processes. I remember working on an improvement project, where we just could not figure out why a certain process step (content level) was taking 2 - 3 days. When diving deeper, we found a supporting process (deliver physical mail) where moving a certain paper-folder took 2 days. Ah.
If we only explore the main one, the other's are either implicitely covered, or completely forgotten, with all negative (change) consequences.
As an example: suppose our scope is "provide quote", in, say, a credit lending bank area. As analysts we dive into the process, find and model all activities - receive quote request, determine credit worthiness, calculate proposed interest rate, create quote, send quote, etc.
And if we are lucky, some analyst might even ask - what are KPI's or what is the management information that is required for the people steering this process? That person felt possibly intuitively that there are other processes floating around.
We might end up with a great "provide quote" process, and yet we might face issues around change management and reinforcement of improvements.
Let's get to the point:
The three processes that "hide in every process" in my opinion are:
- The "content process" - e.g. the main process, aimed at fullfilling the specific customer request, activities leading to the transformation of input to output
- The "operational management process" - the proces (usually plan-do-check-act) of making sure that the "content process" keeps performing.
- The "improve and (re)align process" - the process of "sharpening the saw", making sure that the content process (and operational management process) are improved, and when strategy changes of the company occur, that these processes are adapted to the new strategy .
Some thoughts...
1. As said, most of analyst's attention typically is spend on the "content process". That's ok, since in the end, if that does not run well, we end up with nothing. But let's not forget the other processes....
2. If we look at the operational management process, we might have analysts remembering that we need "management information". That's a step, but not the complete one. Steering requires a number of "process items":
- Who is steering?
- What process is followed for the steering?
- What possibilities are there for interventions ("act"), if process performance is not acceptable? According to what policies and rules?
- What information is required to steer (for planning, for checking), with what frequencies, in what form?
If we only focus on management information, we forget to focus on understanding and implementing the operational management process. Something I earlier wrote about in
"driving 50 MPH without a steer".
3. Interestly, whenever I start talking about operational management, process participants start to look "upward" to a management level. That's a choice, and usually determined by company culture.
My point is: many of the operational management activities you can also place at the process participants level. Many principles ("when is our process functioning fine, and in what situations should we act to correct issues) can better be done by the process participants themselves - they have the knowledge and see things happening. Instead of thinking "I should focus on the process and not the issue, my manager should fix this", we can make them responsible for steering as well. "When I see someone in my team having too much work, I will jump in and help", "When I see an error, I fix it, and make sure we don't make the same error again"...
4. You might object, and say "operational management" and possibly even more "improve and (re)align" should be part of a top-down scope in which we create a BPM framework for management. Sure, that's fine - if it's there. But in many situations that might take a long time. Don't wait for it - start bottom-up/middle out, learn and evaluate.
Conclusion: focus on content is fine, but don't forget to implement operational management and improve/(re)align.
As a PS:
I talked about possibly three more. These are:
- Your supplier and customer processes. What steps do they need to take to deliver and get their need fulfillled? If we forget to look at these processes, then we also miss out on possibly great opportunities for improvement in their and our own processes.
- Supporting processes. I remember working on an improvement project, where we just could not figure out why a certain process step (content level) was taking 2 - 3 days. When diving deeper, we found a supporting process (deliver physical mail) where moving a certain paper-folder took 2 days. Ah.
Monday, November 10, 2008
Gosh - OCEB Fundamentals certified
41 and getting a diploma....
As a betatester, I got certified as OMG's OCEB Fundamentals Certified Expert in BPM. Tada...
As a betatester, I got certified as OMG's OCEB Fundamentals Certified Expert in BPM. Tada...
I think it is a good enough certification program, which is aware of the many schools in BPM thinking. The more European/Dutch focus on Risk management ("AO/IC") is lacking a bit, but in the Business Intermediate this is covered better.
Not sure if I will do betatesting for the rest. For some reason, OMG seems to be really pushing the schedule. For the Fundamentals exam, I received the invitation on June 25th, and had to do the exam before july 25th. The results I received only recently. The Business Intermediate invitation I received on October 10th, with a deadline of November 14. And now the Technical Intermediate has a deadline of Dec 4th - 3 weeks after the deadline of Business Intermediate. While the amount of materials is growing and growing.
Hm.... BPM consultants are busy and have family lives... (or is that a European bias?)
But anyway, I seem to be the first Dutch OCEB certified... Or?
Sunday, September 07, 2008
BPM & Change - Five steps to change
Based on a number of projects where we needed to implement new processes, supported by new technology, I start to see a pattern emerge, that seems to work helping people and organisations reach the goals of a certain change program.
The pattern consists of four phases that people can go through, if supported by the right interventions.
Suppose we have defined a certain change requirement (which could be a full blueprint, that needs to be implemented top-down, or, preferably, there is rooom to work together with the involved people to define and implement the required change)....
Then I see five steps/phases to get to a succesful change:
1. Awareness
Our business life is an attention economy: a lot of stuff is happening, and we only have so much time and processing power. If you want to involve people that will be affected by a change, you will need to get above the radar. So with a good combination of receiving/sending the goal is to make people aware that something is coming, something that will effect them. SThe objective is to touch people in three levels:
1. their thinking (understanding what's coming),
2. their feeling(make sure they associate the coming change with A:positive feelings, based on various values, such as "interesting", "fun", "will create new opportunities", "growth" and B: safety: "my needs & concerns will be addressed", "I will be able to handle this change"
3. Their actions (I want to know more, provide input)
But this is not something you can control - people are (fortunately) autonomous, and will react in different ways. All this is vital information.
2. Understand and commit
Where the first phase is still open and has room for "we will see", this phase is about making people really understand what change is coming and how it will effect their workreality. Here usually a lot of energy is created, which can be positive, but can also lead to sharp resistance if not handled properly. With the right combination of listening, telling, and honest but committed communication from the higher management level, people will need to be made aware that their worksituation will be changed. And that their input is vital - but that choices will need to be made, some of which not that great. Assurance on clear decision procedures/criteria is important.
3. Prepare to perform
The last step for the actual change implementation is the building of competences, skills and self-confidence of the people. Here we train people, do proof of concepts, dry-runs etc. All to assure that we all understand the change in all details and that we are able to work in the new situation and deliver the right performance.
4. The real GO
This is the moment of course, that we have planned so carefully. It's a period full of last minute adaptions, issues and, if all goes well, a growing stream of real work, in line with the required change. It's alive and working!
5. Discipline
We tend to forget this, and often as a consultant we miss this phase, but it is important to address already during earlier phases: making sure the changed situation keeps performing (no fall back to old procedure). This deals with interventions on rewards, jobdescriptions. And with a feedback loop that actively uses the input of people to fine tune the process...
I wonder if other people recognize these phases, or see other important steps and activities! I welcome feedback!
The pattern consists of four phases that people can go through, if supported by the right interventions.
Suppose we have defined a certain change requirement (which could be a full blueprint, that needs to be implemented top-down, or, preferably, there is rooom to work together with the involved people to define and implement the required change)....
Then I see five steps/phases to get to a succesful change:
1. Awareness
Our business life is an attention economy: a lot of stuff is happening, and we only have so much time and processing power. If you want to involve people that will be affected by a change, you will need to get above the radar. So with a good combination of receiving/sending the goal is to make people aware that something is coming, something that will effect them. SThe objective is to touch people in three levels:
1. their thinking (understanding what's coming),
2. their feeling(make sure they associate the coming change with A:positive feelings, based on various values, such as "interesting", "fun", "will create new opportunities", "growth" and B: safety: "my needs & concerns will be addressed", "I will be able to handle this change"
3. Their actions (I want to know more, provide input)
But this is not something you can control - people are (fortunately) autonomous, and will react in different ways. All this is vital information.
2. Understand and commit
Where the first phase is still open and has room for "we will see", this phase is about making people really understand what change is coming and how it will effect their workreality. Here usually a lot of energy is created, which can be positive, but can also lead to sharp resistance if not handled properly. With the right combination of listening, telling, and honest but committed communication from the higher management level, people will need to be made aware that their worksituation will be changed. And that their input is vital - but that choices will need to be made, some of which not that great. Assurance on clear decision procedures/criteria is important.
3. Prepare to perform
The last step for the actual change implementation is the building of competences, skills and self-confidence of the people. Here we train people, do proof of concepts, dry-runs etc. All to assure that we all understand the change in all details and that we are able to work in the new situation and deliver the right performance.
4. The real GO
This is the moment of course, that we have planned so carefully. It's a period full of last minute adaptions, issues and, if all goes well, a growing stream of real work, in line with the required change. It's alive and working!
5. Discipline
We tend to forget this, and often as a consultant we miss this phase, but it is important to address already during earlier phases: making sure the changed situation keeps performing (no fall back to old procedure). This deals with interventions on rewards, jobdescriptions. And with a feedback loop that actively uses the input of people to fine tune the process...
I wonder if other people recognize these phases, or see other important steps and activities! I welcome feedback!
Saturday, September 06, 2008
Borders of BPM - Process management
There is a saying (hope I translate it right): Where people draw borderlines, there will be border-conflicts. In this post, I want to address a definition issue around BPM, based on observations in some recent client work. It deals with (in my view) the difference between business process management and process management. Two areas where the borderline seems blurred. In some discussions I had, due to this blurred borderline, confusion started to grow.
Let's try to find the difference and border conflicts between these area's.
Process management: the area of activity to plan the execution of a process and to steer the execution of a process (through interventions on specific "instances"), to make sure the objectives are met and that process performance is conforming to certain requirements.
(We could also call this: Operations or Operational management).
The managed object here is the performance of the process. The activity is done within the boundaries of the current process, e.g. the process in itself is not changed. Steering will be interventions on people, and work in progress. E.g. analyse a specific client-issue, re-assign work, re-prioritize, fix issues, etc.
Business process management: the area of activity to manage processes as an asset, and manage the life cycle of these processes, aimed at structuredly improving the processes (in a continous cycle).
Here the managed object is the structure/design of the process (perhaps even the existance of the process!)- e.g. in the BPM area of activity, processes are changed, to adapt to sharpened performance goals and/or to structural changing circuimstances (as opposed to reacting to an specific exception - which would be process management).
Activities here range from setting up target improvement goals, analysing/designing processes that can meet these goals, implementating these (changed) processes and checking the structured performance of these processes, to analyse and check if further improvement steps are needed. Here, we act on different levels - we select processes, plan/prioritize processes to analyse/improve, and on a detailed level work with a specifiek process design and adapt it (change activities, business rules for decisions and assignments, etc).
Is process management BPM? Is BPM process management? Difficult, because recursion effects occur: if we implement a process in a company, where this process goal is to increase the performance of other processes, and we are managing this process, uhm, .....
But I do know that if a company has implemented a process, and from that moment on is managing the performance of the process (and not changing anything in the structure), it would be weird to say that they are doing full-swing BPM.... Because a lifecycle perspective and governance is missing.
For me one part of BPM will be to design and implement a process. Part of the process is of course also the processpart that will manage that process (who wants to implement a process without any goverance/control structure?). This means that implementing the process will also create the process management of that process.
Confused? Here is a diagram that tries to show my point: a Plan-Do-Check-Act cycle is implemented and performed (e.g. process management) when (as part of the BPM cycle) the process has been deployed and is being executed for a certain period of time.
Let's try to find the difference and border conflicts between these area's.
Process management: the area of activity to plan the execution of a process and to steer the execution of a process (through interventions on specific "instances"), to make sure the objectives are met and that process performance is conforming to certain requirements.
(We could also call this: Operations or Operational management).
The managed object here is the performance of the process. The activity is done within the boundaries of the current process, e.g. the process in itself is not changed. Steering will be interventions on people, and work in progress. E.g. analyse a specific client-issue, re-assign work, re-prioritize, fix issues, etc.
Business process management: the area of activity to manage processes as an asset, and manage the life cycle of these processes, aimed at structuredly improving the processes (in a continous cycle).
Here the managed object is the structure/design of the process (perhaps even the existance of the process!)- e.g. in the BPM area of activity, processes are changed, to adapt to sharpened performance goals and/or to structural changing circuimstances (as opposed to reacting to an specific exception - which would be process management).
Activities here range from setting up target improvement goals, analysing/designing processes that can meet these goals, implementating these (changed) processes and checking the structured performance of these processes, to analyse and check if further improvement steps are needed. Here, we act on different levels - we select processes, plan/prioritize processes to analyse/improve, and on a detailed level work with a specifiek process design and adapt it (change activities, business rules for decisions and assignments, etc).
Is process management BPM? Is BPM process management? Difficult, because recursion effects occur: if we implement a process in a company, where this process goal is to increase the performance of other processes, and we are managing this process, uhm, .....
But I do know that if a company has implemented a process, and from that moment on is managing the performance of the process (and not changing anything in the structure), it would be weird to say that they are doing full-swing BPM.... Because a lifecycle perspective and governance is missing.
For me one part of BPM will be to design and implement a process. Part of the process is of course also the processpart that will manage that process (who wants to implement a process without any goverance/control structure?). This means that implementing the process will also create the process management of that process.
Confused? Here is a diagram that tries to show my point: a Plan-Do-Check-Act cycle is implemented and performed (e.g. process management) when (as part of the BPM cycle) the process has been deployed and is being executed for a certain period of time.
Wednesday, July 30, 2008
(Dutch) Onderzoek "BPM in Nederland - 2008" : resultaten beschikbaar
(This is a dutch message about the availability of the Dutch results of a BPM survey we ran earlier this year).
Eerder dit jaar berichtte ik over het onderzoek dat Hogeschool Utrecht en Capgemini hebben gedaan rond BPM in Nederland. De resultaten van dit onderzoek zijn inmiddels beschikbaar - het rapport kan aangevraagd worden op www.bpmsurvey.nl.
Interessant leesmateriaal!
Enkele bevindingen:
- BPM krijgt groeiende aandacht
- Hoewel de meeste deelnemers BPM als een management discipline zien, wordt ook gesteld dat BPM nog teveel als IT wordt gezien
- BPM initiatieven redelijk succesvol
- BPM technologie met name nog gebruikt voor procesbeschrijving en publicatie (BPA)
- Tevredenheid over BPM technologie matig
- BPM trajecten hebben last van functionele organisatie/cultuur
- Organisaties die BPM willen toepassen zijn met name op zoek naar ondersteuning bij training
Meer bevindingen in het eindrapport. Veel leesplezier - www.bpmsurvey.nl
Eerder dit jaar berichtte ik over het onderzoek dat Hogeschool Utrecht en Capgemini hebben gedaan rond BPM in Nederland. De resultaten van dit onderzoek zijn inmiddels beschikbaar - het rapport kan aangevraagd worden op www.bpmsurvey.nl.
Interessant leesmateriaal!
Enkele bevindingen:
- BPM krijgt groeiende aandacht
- Hoewel de meeste deelnemers BPM als een management discipline zien, wordt ook gesteld dat BPM nog teveel als IT wordt gezien
- BPM initiatieven redelijk succesvol
- BPM technologie met name nog gebruikt voor procesbeschrijving en publicatie (BPA)
- Tevredenheid over BPM technologie matig
- BPM trajecten hebben last van functionele organisatie/cultuur
- Organisaties die BPM willen toepassen zijn met name op zoek naar ondersteuning bij training
Meer bevindingen in het eindrapport. Veel leesplezier - www.bpmsurvey.nl
Wednesday, July 23, 2008
Studying for OCEB fundamentals
I was lucky to become one of the beta-testers for the OMG's OCEB fundamental exam.
More info on: http://www.omg.org/oceb/
A great refresh (well, to be honest - some new stuff!). And the nice thing - some of the new material I could immediately use in my work. For instance the BMM standard is a great framework for strategy and planning concepts. And Martyn Ould's book about BPM is a nice read, I like his tone of voice - I will probably not just read chapter one, but continue.
A fair amount of BPM area's is covered :
- Process concepts
- Process modelling (BPMN)
- Maturity (BPMM)
- Compliance (but a warning: very USA centric)
- Process performance - KPI's, goal setting, etc
- General MBA stuff on business concepts
- Six Sigma (very very basic)
Stuff that I miss (maybe in a more advanced level?):
- Change management
- BPM technology (including BAM, Rules, Document management interfacing)
- How to do BPM projects (from pure processwork to BPM technology)
- Other process improvement methods such as Lean, TOC
- The relation between BPM and Business/IT architecture
- Other "activity coordination" approaches besides orchestration & choreagraphy: case management, human interaction management, collaborative BPM
A tip: Don't underestimate the work - it's quite a lot of material.
A question: any other Dutch participants? Would be nice to become the first Dutch OCEB certified (ah, my ego again ;-))
Friday exam. Will let you know more... (well, as far as the quite strict NDA will allow me….)
Wednesday, June 18, 2008
Just attended the virtual eBizq seminar
I just attended the eBizq virtual seminar on BPM.
Also see: http://expoq.unisfair.com/index.jsp?id=4616
Fun! And a great way to network, meet people and find information on BPM (although the number of vendor booths is not a bit low).
The presentations and webcasts will be available soon, which is nice, because I missed the first two parts (tip for Ebizq: publish not only the starttime US based, but also the time for people in other time zones ;-)).
He, and my question on collaborative BPM was even answered in the final panel. Nice, although the first speakers sticked too much to the casemanagement, 1 person handling tasks view of BPM technology. I am still looking for collaborative BPM (or HIMS) which can support process-fragments supporting people working concurrenly together on a certain process task (be it deciding, researching, issue-resolution, planning, whatever). See - most processes are partly structured (and can be supported by WFM), partly casemanagement, and some parts are just a total adhoc bunch of people running around, meeting and deciding.... collective intelligence at it's best, but hopefully supported by great BPM features in the future.
The virtual environment was a bit limited (chat rooms that echo-ed of emptyness, and booth chats with vendors, where people did not answer...hmmm).
But it saved me a lot of flying :-)
Also see: http://expoq.unisfair.com/index.jsp?id=4616
Fun! And a great way to network, meet people and find information on BPM (although the number of vendor booths is not a bit low).
The presentations and webcasts will be available soon, which is nice, because I missed the first two parts (tip for Ebizq: publish not only the starttime US based, but also the time for people in other time zones ;-)).
He, and my question on collaborative BPM was even answered in the final panel. Nice, although the first speakers sticked too much to the casemanagement, 1 person handling tasks view of BPM technology. I am still looking for collaborative BPM (or HIMS) which can support process-fragments supporting people working concurrenly together on a certain process task (be it deciding, researching, issue-resolution, planning, whatever). See - most processes are partly structured (and can be supported by WFM), partly casemanagement, and some parts are just a total adhoc bunch of people running around, meeting and deciding.... collective intelligence at it's best, but hopefully supported by great BPM features in the future.
The virtual environment was a bit limited (chat rooms that echo-ed of emptyness, and booth chats with vendors, where people did not answer...hmmm).
But it saved me a lot of flying :-)
Friday, May 02, 2008
JIT training in a BPM technology environment
I cam across an interesting research paper on BPM and knowledge management:
http://www.ejel.org/Volume-5/v5-i3/Leyking_et_al.pdf
Key points:
- Most training efforts are not linked to the situational context - so the learning is too remote from reality, in terms of content and timing
- A process focus can increase the value of training - process context can support modeling of required knowledge areas to complete an activity in the process
In my view there is a strong link between BPM and knowledge management. Many processmodelling efforts, as a start, where created from a knowledge perspective - helping new (and existing) employees in the business to understand the processes and activities to be done, so that they could perform their work accordingly.
And of course, when executing processes, the right employees with the right skills and knowledge are needed for performing certain tasks.
Some BPM technology vendors are already taking some steps to support knowledge management in the context of process. Simple example: a user can click on "show the process map" when working on an activity, and the processmap + highlighted activity is shown, helping the user to understand the context of the activity.
The paper triggered me to think a bit further -
Wouldn't it be great to have a BPM technology solution that enabled us to trigger "just in time" learning?
The scenario:
An employee gets a task assigned. The BPM suite identifies that the person has never performed this task before (of possibly other triggers: the employee scores low on certain other KPI's around this activity such as errors made, throughput time, etc).
The BPM suite suggest to the user, prior to activity start: "Do you want to follow a quick Just In Time training on how to succesfully complete this activity"?
And from that point on, a link is provided to some training environment, which trains the user, through video, text, quizes etc to understand the link to strategy, process context, activity and best practices for the activity.
Benefit: Just in Time, so very closely linked to the context of the actual work to be done.
http://www.ejel.org/Volume-5/v5-i3/Leyking_et_al.pdf
Key points:
- Most training efforts are not linked to the situational context - so the learning is too remote from reality, in terms of content and timing
- A process focus can increase the value of training - process context can support modeling of required knowledge areas to complete an activity in the process
In my view there is a strong link between BPM and knowledge management. Many processmodelling efforts, as a start, where created from a knowledge perspective - helping new (and existing) employees in the business to understand the processes and activities to be done, so that they could perform their work accordingly.
And of course, when executing processes, the right employees with the right skills and knowledge are needed for performing certain tasks.
Some BPM technology vendors are already taking some steps to support knowledge management in the context of process. Simple example: a user can click on "show the process map" when working on an activity, and the processmap + highlighted activity is shown, helping the user to understand the context of the activity.
The paper triggered me to think a bit further -
Wouldn't it be great to have a BPM technology solution that enabled us to trigger "just in time" learning?
The scenario:
An employee gets a task assigned. The BPM suite identifies that the person has never performed this task before (of possibly other triggers: the employee scores low on certain other KPI's around this activity such as errors made, throughput time, etc).
The BPM suite suggest to the user, prior to activity start: "Do you want to follow a quick Just In Time training on how to succesfully complete this activity"?
And from that point on, a link is provided to some training environment, which trains the user, through video, text, quizes etc to understand the link to strategy, process context, activity and best practices for the activity.
Benefit: Just in Time, so very closely linked to the context of the actual work to be done.
Sunday, April 27, 2008
Convergence of process model silos
Go look in a random, reasonably mature organisation, and it is likely that you will encounter a number of places where people think, discuss, record and analyse process.
Let's see where.....
Let's see where.....
First of all we see BPA centers, that model processes so the organisation can... be compliant, reach ISO certification, communicate to people (knowledge management). Often the procesmodels and instructions are published on some intranet.
Then we see enterprise architects, modeling processes (often from a higher view).
We see business analists, working in a change project, trying to find the As-is and To-be situation, and documenting them in requirements tool (parts of business or system use cases) or documents
We see BPM engines running, with procesmodels.
That's a lot of process models, with often a lot of overlap.
Duplication of data and of simular tooling is often the case.
Currently, we see that the tools in the various areas are not integrated. It means remodelling processes in the other tool. And we see that the tools are limited. A BPA tool can have great modelling capabilities, but can't link things to (abstract) services. Or the BPM-suite is great to model processes, but we can't publish them to do knowledge management.
The key question - will we end up with convergence?
There are signs.
- Some companies are using BPA (for instance ARIS) to also model requirements, next to as-is and to-be processes
- Some companies are using their extended BPM suite to also publish the processes to some intranet (for instance Pega systems)
- Some BPM companies are buying BPA tooling
- Some BPA vendors are extending their BPA offering with BPM-suite execution cabilities.
I long for an integrated tool (either one tool, or a clear, say XPDL type, integration - but beware round-trip...)... where I....
- Can model an enterprise (functions, processes, services, organisational units)
- Can model requirements (including business rules), and link them to all of these elements, as-is and to-be
- Can define processes in more detail
- Can execute and measure some of these processes
Human BPM/BPI-game and my key lessons
Recently I attended a good training on process modeling and analysis. One of the final parts was a group exercise where we simulated a process. A lot of fun - first we got the specs of a process, e.g. activities, flows, business rules and resources. And each of us was given a role in the process. Based on a computermodel we received "customer orders", and we performed the tasks, delivering the requested product, while the computer was measuring %on-time delivery and leadtime (+ variances + some other KPI's).
Then we had the opportunity to discuss the process, our observations on performance, and as a group suggest and implement improvements. Of course we used various techniques, we just learned in the training, such as elements from value added analysis, bottleneck removal, leveling, and other lean + common sense techniques. Then we performed the process again, with again KPI measurement. And one last round of improvement and simulation.
We did fine in the end - the process was definitely improved. And - both leadtime went down, resourcing went down, cost went down and predictability went up (less lead time variance).
My key lessons:
1. A lot of improvements is FREE
We often have the idea that improvement comes at a cost. Yes - for most improved processes that will probably be true. But the start process we were given was not so unrealistic. Yet, with surprising little improvement changes, we were able to improve on all major performance elements.
Wandering around various organizations, I have often been puzzled by the lack of view on processes and the great, yet unattemped potential for improvement...
2. Change management is hard....
Running the process went fine, but as a group coming to terms with the analysis, improvement ideas and selection/implementation - ough. A lot of discussion, confusing, different angles, lack of leadership.
It learned me the valuable lessons:
-Business Process Improvement (BPI) needs a mix of people from the floor and people with general process improvement skills
- BPI workshops need a strong facilitator
- BPI needs someone that takes decisions - e.g. management that understand the BPI ideas and is able to prioritize and select
In real live I see these things too. So much room for improvement. Coming up with good improvement ideas is often easy. But getting all the people aligned and agreeing- that's the hard part. In terms of evolution, I guess that's our next challenge. We are great survivors. But in the future collaboration will define our real survival. Not sure if we humans are equiped enough for this task...
Then we had the opportunity to discuss the process, our observations on performance, and as a group suggest and implement improvements. Of course we used various techniques, we just learned in the training, such as elements from value added analysis, bottleneck removal, leveling, and other lean + common sense techniques. Then we performed the process again, with again KPI measurement. And one last round of improvement and simulation.
We did fine in the end - the process was definitely improved. And - both leadtime went down, resourcing went down, cost went down and predictability went up (less lead time variance).
My key lessons:
1. A lot of improvements is FREE
We often have the idea that improvement comes at a cost. Yes - for most improved processes that will probably be true. But the start process we were given was not so unrealistic. Yet, with surprising little improvement changes, we were able to improve on all major performance elements.
Wandering around various organizations, I have often been puzzled by the lack of view on processes and the great, yet unattemped potential for improvement...
2. Change management is hard....
Running the process went fine, but as a group coming to terms with the analysis, improvement ideas and selection/implementation - ough. A lot of discussion, confusing, different angles, lack of leadership.
It learned me the valuable lessons:
-Business Process Improvement (BPI) needs a mix of people from the floor and people with general process improvement skills
- BPI workshops need a strong facilitator
- BPI needs someone that takes decisions - e.g. management that understand the BPI ideas and is able to prioritize and select
In real live I see these things too. So much room for improvement. Coming up with good improvement ideas is often easy. But getting all the people aligned and agreeing- that's the hard part. In terms of evolution, I guess that's our next challenge. We are great survivors. But in the future collaboration will define our real survival. Not sure if we humans are equiped enough for this task...
Thursday, April 17, 2008
(Dutch only) Al goede deelname Nederlands BPM onderzoek (nog lopend)
(Dutch only - concerns progress on a dutch research on application of BPM as discipline and BPM technology in dutch organizations)
Eerder heb ik geschreven over het onderzoek "Business Process Management in Nederland - 2008" dat de Hogeschool Utrecht ism Capgemini uitvoert.
Ik moet zeggen - we hebben nog een week te gaan, maar al 100 mensen hebben de enquete ingevuld op www.bpmsurvey.nl .
Het betekent dat we qua onderbouwing van resultaten redelijk stevig staan, ook gezien de spreiding van de deelnemers over de verschillende branches in Nederland. En ik denk dat de resultaten interessant worden en bruikbaar voor organisaties om te kijken waar BPM zich heen ontwikkelt en te zien wat andere organisaties doen met BPM en BPM technologie.
Reacties van de deelnemers waren voornamelijk positief. Eén quote:
"Het BPM survey werkte voor mij heel verhelderend. Aan de hand van de vragen zie ik de gaten op BPM gebied in onze organisatie. Ik ga mij binnen onze afdeling verder bekwamen in alle facetten van BPM om verbeteringen door te voeren en deze uit te dragen binnen de organisatie."
Kijk, daar worden we natuurlijk blij van. Maar er kwam ook kritiek, goede kritiek, die we meenemen voor toekomstig onderzoek naar BPM.
Vanaf deze plaats kan ik alleen maar zeggen: als je nog niet hebt meegedaan, en geinteresseerd bent in de resultaten van het onderzoek - doe dan mee! Je input is waardevol.
www.bpmsurvey.nl. De vragenlijst is nog tot en met 25 april actief.
Voor meer informatie over het onderzoek, zie ook:
http://www.bpmsurvey.nl/BPMuitnodiging.html
Eerder heb ik geschreven over het onderzoek "Business Process Management in Nederland - 2008" dat de Hogeschool Utrecht ism Capgemini uitvoert.
Ik moet zeggen - we hebben nog een week te gaan, maar al 100 mensen hebben de enquete ingevuld op www.bpmsurvey.nl .
Het betekent dat we qua onderbouwing van resultaten redelijk stevig staan, ook gezien de spreiding van de deelnemers over de verschillende branches in Nederland. En ik denk dat de resultaten interessant worden en bruikbaar voor organisaties om te kijken waar BPM zich heen ontwikkelt en te zien wat andere organisaties doen met BPM en BPM technologie.
Reacties van de deelnemers waren voornamelijk positief. Eén quote:
"Het BPM survey werkte voor mij heel verhelderend. Aan de hand van de vragen zie ik de gaten op BPM gebied in onze organisatie. Ik ga mij binnen onze afdeling verder bekwamen in alle facetten van BPM om verbeteringen door te voeren en deze uit te dragen binnen de organisatie."
Kijk, daar worden we natuurlijk blij van. Maar er kwam ook kritiek, goede kritiek, die we meenemen voor toekomstig onderzoek naar BPM.
Vanaf deze plaats kan ik alleen maar zeggen: als je nog niet hebt meegedaan, en geinteresseerd bent in de resultaten van het onderzoek - doe dan mee! Je input is waardevol.
www.bpmsurvey.nl. De vragenlijst is nog tot en met 25 april actief.
Voor meer informatie over het onderzoek, zie ook:
http://www.bpmsurvey.nl/BPMuitnodiging.html
Saturday, April 12, 2008
Business Process Control in two loops
Earlier I blogged about the role of Business Activity Monitoring. When talking to various vendors I found different views on the use of this. Again - this blogitem's inspiration I got from a presentation from Pallas Athena (www.pallas-athena.com)
Basically there are two efforts going on in a BPM environment that require monitoring, as part of the Plan-Do-Check-Act loop:
1. Operational management (let's call this loop 1)
This is: making sure that current procesflows (real orders, cases, complaints, whatever) deliver within acceptable scoring range.
This is the daily management process to make sure all customer/stakeholder expectations are met. It could include firefighting to make sure that one order gets delivered on time, the certain complaint gets the right attention, that the illness of employee XYZ is not impacting the question a customer had, etc, etc.
2. Process improvement management (let's call this loop 2)
This is the more structural view on the process performance. Now we are not interested in making sure a certain process instance (order, complaint, etc) is executed on time, within budget, but we want to look at the process performance as a whole. And analyse the process - where are bottlenecks, in what type of instances we typically end up with trouble, what are average leadtimes, costs, etc?
I see a number of things in the BPMS market:
1. Some vendors do not see the difference, or limit their view on only one type of management.
2. Most vendors promise that "the BPMS will help you to improve", but most vendors deliver for only one thing: Business Activity Monitoring.
My main point: BAM is not a solution. BAM can be a supporting role (CHECK) to be able to manage both management processes, but we need more in a BPMS. We need to be able to ACT.
A simple analogy:
When I see smoke pooring out of my oven, and the temperature-meter of the oven is well in the red, I have information: my food is burning, my process is out of acceptable KPI ranges.
However, the key question: what can I DO to 1. fix this now, and 2. Fix this from happening again?
My control in this situation is:
Process 1. Switch oven off, take food out, curse, start over (or eat out)
Process 2. Read the recepy, use the oven timer, set the right temperature, and maybe have my girlfriend doublecheck, plus check progress every 5 minutes
BAM is nice, but we need a linked feature called "Business Process Control" in BPMS (and some already have it, but name it differently) - the ability to:
1. Fix current process instance that are off limits (or are in danger to become that)
For instance:
- Reassign staff, temporarely hire new staff
- Prioritize processes / tasks / certain customers
- Say sorry to the customer pro-actively and negotiate new delivery conditions
(Can you think of other control activities?)
2. Fix the process
Usually people think "change process activities" when improving. But my believe is: usually much can be done through:
- Changing assignment business rules (triage, priority based, etc)
- Tune process flow rules
- Increase staff
- Train staff
(Can you think of other control activities?)
BPC - Business Process Control. Now that would be a nice feature in a BPMS.
And maybe even BPCC - Business Process Coaching and Control: a BPMS that alerts you (BAM), suggests (Coaching) possible actions ("why don't you assign this task to Mary?") and allows you to take control measures on loop 1 and loop 2.
But then again, we have enough TLA and FLA's....
Basically there are two efforts going on in a BPM environment that require monitoring, as part of the Plan-Do-Check-Act loop:
1. Operational management (let's call this loop 1)
This is: making sure that current procesflows (real orders, cases, complaints, whatever) deliver within acceptable scoring range.
This is the daily management process to make sure all customer/stakeholder expectations are met. It could include firefighting to make sure that one order gets delivered on time, the certain complaint gets the right attention, that the illness of employee XYZ is not impacting the question a customer had, etc, etc.
2. Process improvement management (let's call this loop 2)
This is the more structural view on the process performance. Now we are not interested in making sure a certain process instance (order, complaint, etc) is executed on time, within budget, but we want to look at the process performance as a whole. And analyse the process - where are bottlenecks, in what type of instances we typically end up with trouble, what are average leadtimes, costs, etc?
I see a number of things in the BPMS market:
1. Some vendors do not see the difference, or limit their view on only one type of management.
2. Most vendors promise that "the BPMS will help you to improve", but most vendors deliver for only one thing: Business Activity Monitoring.
My main point: BAM is not a solution. BAM can be a supporting role (CHECK) to be able to manage both management processes, but we need more in a BPMS. We need to be able to ACT.
A simple analogy:
When I see smoke pooring out of my oven, and the temperature-meter of the oven is well in the red, I have information: my food is burning, my process is out of acceptable KPI ranges.
However, the key question: what can I DO to 1. fix this now, and 2. Fix this from happening again?
My control in this situation is:
Process 1. Switch oven off, take food out, curse, start over (or eat out)
Process 2. Read the recepy, use the oven timer, set the right temperature, and maybe have my girlfriend doublecheck, plus check progress every 5 minutes
BAM is nice, but we need a linked feature called "Business Process Control" in BPMS (and some already have it, but name it differently) - the ability to:
1. Fix current process instance that are off limits (or are in danger to become that)
For instance:
- Reassign staff, temporarely hire new staff
- Prioritize processes / tasks / certain customers
- Say sorry to the customer pro-actively and negotiate new delivery conditions
(Can you think of other control activities?)
2. Fix the process
Usually people think "change process activities" when improving. But my believe is: usually much can be done through:
- Changing assignment business rules (triage, priority based, etc)
- Tune process flow rules
- Increase staff
- Train staff
(Can you think of other control activities?)
BPC - Business Process Control. Now that would be a nice feature in a BPMS.
And maybe even BPCC - Business Process Coaching and Control: a BPMS that alerts you (BAM), suggests (Coaching) possible actions ("why don't you assign this task to Mary?") and allows you to take control measures on loop 1 and loop 2.
But then again, we have enough TLA and FLA's....
New BPMS feature: process mining
Recently I attended a meeting where a BPMS vendor (Pallas Athena, http://www.pallas-athena.com/) presented a new (for me) feature: process mining.
They worked on this concept together with the Eindhoven University (Van der Aalst, a well-known name in BPM research, also see http://www.processmining.org/ and http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/process%20mining.htm)
Basically, the concept is:
- the BPMS reads all kinds of logfiles from various computersystems.
- The BPMS analyses the logfiles and will construct a processmodel automatically
- The data + model can be used for animation and simulation
That's interesting for multiple reasons:
- It usually takes quite some time to construct a procesmodel manually - talks to stakeholders, workshops, etc. Process mining can save time (and cost)
- Even when interviewing stakeholders, they might not have the correct overview and the modelled process might not match reality. Process mining can confront stakeholders and improve model quality.
There is catch of course:
1. The logfiles need to provide data that a BPMS can interpret - aka some type of task identification, a timestamp and a unique ID (of a certain flowing object, such as customer, order, process, etc)
2. Process models that are "mined" will only contain the reality as is presented in the logfiles, and no more. They will miss:
- Business rules for decisions and assignments (why did this instance go left, why was person X the performer of the task)
- Manual activities or activities not traced in logfiles
Still, I saw some cool stuff, that could have added value in BPM efforts:
1. A logfile of a helpdesk application was analysed. Step by step you saw the processmodel appear and get refined, based on the logfile entries
2. A time-based animation could be run, based on the original logfile, showing the flow (little dots) through the process model. This was quite interesting, because it visually showed the execution, quickly pointing to bottlenecks and opportunities for improvement
(Note: if would even be better if the system would be able to present possible improvement actions, based on process improvement frameworks such as Lean and Six Sigma)
3. When the animation was shown to the stakeholders, they did not believe the process - certain flows where against company policy, but did happen. Compliance issues became clear.
4. Based on the logfiles, various KPI's could be calculated. In addition, various statistical facts could be derived, usefull for subsequent simulation
5. If the eventlog also contained userdata, it was possible to analyse and visualize the "social map" - who is involved when, where and is linked to other people.
So, even though the technology is quite new, needs refinement and has limitations, I do see interesting benefits:
- Quickly "mine" a starting point for a processmodel, and then add tasks and business rules
- Visualize currect processes and analyse bottlenecks
For more information - see: http://tabu.tm.tue.nl/wiki/_media/pressrelease/press_release_stw_project_ned2.pdf?id=news&cache=cache
Disclosure: I have no commercial relation with Pallas Athena.
They worked on this concept together with the Eindhoven University (Van der Aalst, a well-known name in BPM research, also see http://www.processmining.org/ and http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/process%20mining.htm)
Basically, the concept is:
- the BPMS reads all kinds of logfiles from various computersystems.
- The BPMS analyses the logfiles and will construct a processmodel automatically
- The data + model can be used for animation and simulation
That's interesting for multiple reasons:
- It usually takes quite some time to construct a procesmodel manually - talks to stakeholders, workshops, etc. Process mining can save time (and cost)
- Even when interviewing stakeholders, they might not have the correct overview and the modelled process might not match reality. Process mining can confront stakeholders and improve model quality.
There is catch of course:
1. The logfiles need to provide data that a BPMS can interpret - aka some type of task identification, a timestamp and a unique ID (of a certain flowing object, such as customer, order, process, etc)
2. Process models that are "mined" will only contain the reality as is presented in the logfiles, and no more. They will miss:
- Business rules for decisions and assignments (why did this instance go left, why was person X the performer of the task)
- Manual activities or activities not traced in logfiles
Still, I saw some cool stuff, that could have added value in BPM efforts:
1. A logfile of a helpdesk application was analysed. Step by step you saw the processmodel appear and get refined, based on the logfile entries
2. A time-based animation could be run, based on the original logfile, showing the flow (little dots) through the process model. This was quite interesting, because it visually showed the execution, quickly pointing to bottlenecks and opportunities for improvement
(Note: if would even be better if the system would be able to present possible improvement actions, based on process improvement frameworks such as Lean and Six Sigma)
3. When the animation was shown to the stakeholders, they did not believe the process - certain flows where against company policy, but did happen. Compliance issues became clear.
4. Based on the logfiles, various KPI's could be calculated. In addition, various statistical facts could be derived, usefull for subsequent simulation
5. If the eventlog also contained userdata, it was possible to analyse and visualize the "social map" - who is involved when, where and is linked to other people.
So, even though the technology is quite new, needs refinement and has limitations, I do see interesting benefits:
- Quickly "mine" a starting point for a processmodel, and then add tasks and business rules
- Visualize currect processes and analyse bottlenecks
For more information - see: http://tabu.tm.tue.nl/wiki/_media/pressrelease/press_release_stw_project_ned2.pdf?id=news&cache=cache
Disclosure: I have no commercial relation with Pallas Athena.
Thursday, April 03, 2008
BPM - Thoughts about change
BPM projects are change projects. And I want to address a number of thoughts about change.
1. Likelihood of change
Thinking about change (and mainly based on my sometimes painfull lessons on projects that actually did not lead to sustained change) I came up with a simple formula to make me once and for all remember factors required for change. They prevent me from being overly optimistic (as I sometimes have the tendency to run too far from the troops...)
The formula: Likelyhood of sustainable change =
Need x Awareness x Sense Of Urgency x Ambition x Priority x Vision x Resources x Courage / Risks
Need: is there current pain? Something that the people want to get away from?
Awareness: is there real awareness of the pain, the causes and the need to get away from it?
(sidenote: in learning theory you have the powerful model of:
UU - Unaware Unable - We are not able to do something, but unaware....
AU - Aware Unable
AA - Aware Able
UA - Unaware Able
In this case: are the key stakeholders at AU level?)
In this case: are the key stakeholders at AU level?)
Sense of Urgency: do key people, with power, affected by the pain (directly or indirectly) really want to get away from it?
Ambition: is there an ambition to spend time, energy and resources to actually do something?
Priority: is this required change and the effort it requires a priority? Or are there other things more important?
Vision: do we have a vision how the TO BE situation looks like and how to get there (more about this later)
Resources: do we have money, people, some time, etc to get there?
Resources: do we have money, people, some time, etc to get there?
Courage: do the leaders, excuses le mot, have the BALLS to actually stick their heads out and get it going?
Risks: how much risk is involved (the bigger, the less likely change will occur, unless.... Courage and Vision is available...)
My lesson: check this formula in the beginning of your efforts on a specific project/change.
And if the outcome is too low, ask yourself: Am I in control to influence the factors? If yes - make an effort, and check again. If no, or if after a number of interventions no significant likelihood is garantueed: go and pick another change worth fighting for.... And if you are working for a manager or client: tell them the outcome and tell them NO.
2. A word on Vision.
As a consultant I learned there are two ways to implement change:
1. Design approach
In this case, we approach the required change from a "blueprint" perspective. E.g. we try to work out a model of the to be situation as much as possible, then perform a gap analysis, leading us to actions required to get from the As-is to the To-be
Base assumption: the future can be designed in a blueprint. The vision can be expressed in a model of the desired state.
2. Development approach
In this case, we work with the people to develop, step by step, required change, and implement it, learning from our efforts, and then get on with the next step.
Base assumption: the future is what happens here and now, and we work together, without a blueprint, but with common goals. The vision needs to be expressed in "common ground", and we need to trust and enable people to create results, develop insights and learn/adapt.
Is there a prefered way? No. Use them both, when appropriate.
I am, for some reasons, too impatient to go with 2, hate unclarity and risk, so I love blueprint visions. That hinders me a lot.
However, a key lesson on 1: think about the number of factors you want to include in the blueprint. I often (and still do :-)) tend to include too many factors. Why? Because I find blueprinting so #^&#$! interesting. But I forget the key thing: the blueprint is there to create a direction, a vision and movement. People are better directed with a strong but simple blueprint, then one with 30 factors, covering 20 slides or so... The elephant is eaten in small pieces...
A word on following the change path....
In my naive starting years, I always thought change went like this:
Right. Of course, this was not reality. It was more like...
An important thing I learned was: if the path of change seems to wander away from the vision, do not immediately start spending lots of energy to push it back. Mischa, a collegue of mine, drew the diagram above and made it suddenly very clear: Groups of people can wander around, and do not follow straight lines. It can cost a LOT of energy (believe me, I learned :-)) to push back. A better way is to see where things are going (and they might suddenly turn...), and only if a certain boundary is crossed, you push back to get them back between the boundary lines.But, how much clarity and detail is needed in the blueprint? As said, I tend to included too many factors, because I like it and gives me a feeling of direction and risk-reduction.
Some lessons here:
- The more factors you stick in, the more energy it will take you to make people see, buy in, and reach the change factor. Links back to likelihood of change....
- The more factors you try to stick in the blueprint, the more factors are likely to change. To my sad realization, I have to admit that even my blueprints are far from the reality that was finally delivered. Lessons on the way and changed circuimstances change the required TO BE, all the time...
So, that's why I am more and more a fan of incremental, iterative change, where we mix design and development approaches and create interim TO BE's that get refined on the way, as shown in the diagram...
Subscribe to:
Posts (Atom)