At the end of 2009, a number of colleagues and I published a (small) book on current trends in BPM (which is available in English in book and PDF-form, on request).
As an update, we recently published a Dutch article in the dutch BPM magazine, with 3 trend-updates. A version of this article can be accessed here: http://www.slideshare.net/htoebak/trends-in-bpm-2010-4149334
Feedback welcome!
Thursday, May 20, 2010
Tuesday, November 17, 2009
Complexity Approach - A new perspective on organizations?
When in the past, people discovered and created the clock, this new technology had great impact on the way they started seeing things. The clock, as concept, was used to understand other phenomena, such as our body, the movement of the planets, etc. As a model, it helped people conceptualize and understand things, which was great. But also – it limited their view (a model is less than reality). With the discovery of the computer, we did the same thing. Powerful, but we ran into difficulties, trying to explain, for instance, our brain-function, with the simplified concept of computer-concepts. Not everything was as deterministic as we needed, to apply the computer-concept.
More hidden, with the “discovery” of systems thinking, we have done the same. System thinking has lead to great conceptual tools, to….
- Divide the complex reality in parts, that are interconnected, and as group, can be seen as a new part of a large system
- Define “control” as a concept, where a part is steered (plan-do-check-act) by a “managing part”
This thinking and tools have helped us understand, model, realize and operate complex structures, such as IT-systems. Of course, we have used these concepts for other complex areas. So we started to use this in our view of organizations. And that’s where things started to become messy.
Are organizations systems? Are groups of people able to be divided in parts, where some parts are planning and controlling others, measuring output, and intervening when needed, to get the desired results? Or it this view limiting? Possibly even dangerous?
Last Friday, I visited an interesting seminar on a new approach to view (and intervene in) organizations: the Complexity Approach (or also known as Complex Responsive Processes). Some of the key people involved with this new view were present: Ralph Stacey, Douglas Griffin and Thijs Homan. In addition, Nol Groot (former director of the NS, the Dutch Railways) was present, as one of the people that have actively applied this new view in the NS).
Their research in organizations suggested that the system’s approach to organizations is limited. And that it had lead to surreal mythical set of beliefs in leadership and the ability to control and change the performance of an organization. A new view is needed.
So they decided to step back, and try to look at organizations in a fresh way: how are things done here, actually, really? What do we really experience?
This lead to the following observations:
- People interact with other people (usually not the whole organization, but a smaller set) in varying interaction patterns. These “local patterns” (or “self-organizing collectives”) might be totally different than the formal organization structure (they may be based on friendship, identity, role, process, etc).
- This is also true for managers (although in larger meetings they might send a lot, but is essence they don’t know how people interpret their message), breaking one myth “the manager knows all, oversees everything”
- These local interaction patterns emerge – they are not created “by design” but appear and develop over time, through complex influences
- Through interaction patterns, people get informed, negotiate and decide, based on their plans, intentions (I want....). In these patterns people confirm their values.
- These interactions (or “interplays of intention”) produce results. Interaction patterns lead to meaning, changed attitudes, conflict, choices, activity and constraints. However, these results might not be the ones that the people had intended upfront (and might not be in line with manager’s plans and intentions!)
Example: two people want to eat together, and end up at a Italian restaurant, while neither had that in mind at the start - One of the results of local patterns are so-called “social objects”: agreements on how people should behave and perform activities in certain situations.
An example:
- A manager gets his unit in the central hall, and tells them that the organization needed to be more customer-friendly. He explains his plans, and communicates that he expects everyone to commit to the plans.
- People leave the hall, and in various complex interaction patterns, the view of the manager is given meaning, mixed with history (“we have done this before”) and own intentions, in various groups of people. Each group will develop their own meaning, interpretation. And the “company-wide plan” becomes a myth.
- And change might come, yet not predictable, and maybe even in despite of all change management efforts
This new view leads to a number of important (and maybe even scary) questions:
- Can a manager “be in control”, if activity and change is dependent on complex interaction patterns which are mostly unpredictable?
- Is change “manageable”?
- Is “resistance to change” something we see as a sign that our plans have not been executed enough yet, something that we need “to handle” and then reach success in the end?
- Can we speak of organization? Or is it more a network of people (with endless dynamics in interconnections)? Can we speak of organization boundaries? Or again – complex interactions with people “inside” and “outside”?
- Is an organization a set of local patterns of interaction?
(These questions resonate with various uneasy feelings I have about BPM and the "organization-people-process-by-design" myth, it implicitely suggests)
Yet, organizations seem to work, sometimes even great. So, the key question is: if an organization does not function well, what can we do as managers (and for me, as consultant)?
Some of my starting points:
- Many instruments of intervention can still be applied. Be aware that interventions however produce non-predictable results (and non-linear: a small intervention might explode through all interaction patterns, a large intervention might be reduced to nothing....)
- The process of giving meaning (how people perceive the need for change and the desired outcomes) is very difficult to manage. Even through various facilitation workshops, etc, people will have a “on-stage” face and a “off-stage” face. And the “off-stage face” will influence many people in their networks. In a typical organization many “clouds of meaning” might exist around certain themes. However, meaning is often given by fixed groups, based on their intentions and history. Investigation and narrative interventions could help here.
- Be very aware of the existence of the (emerging) patterns, through all networks (visible, invisible). These “cells of people” have large influence. If needed (and possible), intervene in this patterns (for instance: break up the organization in smaller teams, build relations, make sure teams interact with each other, as a manager participate on one or more local groups, getting their respect)
- Develop the ability/competency of people to effectively perform local patterns of interaction, and support them by providing clear intentions (on WHAT is needed, not HOW). Help them to be able to address concerns within the group. And become connected!
- Become aware of the “social objects”, and how these objects are created and changed. Who has influence? Through what patterns?
- Change occurs through interacting cells, that see the need for change, form new ideas and create new social objects.
This complexity approach is interesting stuff, which will probably have a large impact on how I see organizations, change, but also BPM! There is much more I could write, but let’s stop for now!
Ok, one last thought for us, consultants: We often see our project (which is a change intervention!) as a set of people, doing the planned activities. During the project, often “fuss”, “discussion”, “resistance” is born and needs to be handled. Often, I saw this stuff as uneasy, difficult, nagging stuff, that was extra effort and thus delayed the project. But maybe this stuff IS THE REAL the project!?
For more information on the Complexity Approach, see for instance:
http://www.amazon.com/Strategic-Management-Organisational-Dynamics-5th/dp/0273708112
http://www.herts.ac.uk/courses/schools-of-study/business/research/complexity-and-management-centre/complexity-the-experience-of-organizing.cfm
Sunday, November 08, 2009
Sigh! Process as intervention is just not sexy...
I am jealous.
I see many types of interventions that management can choose to influence people behaviour in their company...
I see great workshops focused on culture, people doing fun-games at remote locations, deep and inspired discussions on values
I see managers working on mission, vision and strategy in expensive resorts, golfvenue around the corner
I see IT-systems being designed, and delivered, forcing people to follow the screens and workflows embedded in these systems, with all kinds of cool UI-widgets
I see budgets being given or denied
I see people in fun training
I see promotions, new hero-managers, with powerfull mandate
I see jobpromotions, jobdescriptions and evaluation cycles that will actually hit people in their wallet, with big bonusses for the right behaviour
And then there is us, process consultants, proudly showing the next swimminglane model and desperately trying to find someone to take process-responsibility...
How sexy and influencial is that??????
Can anyone help this disillusioned BPM-practioner with concrete examples of process-interventions that inspired, motivated, improved, e.g. sexy?????
I see many types of interventions that management can choose to influence people behaviour in their company...
I see great workshops focused on culture, people doing fun-games at remote locations, deep and inspired discussions on values
I see managers working on mission, vision and strategy in expensive resorts, golfvenue around the corner
I see IT-systems being designed, and delivered, forcing people to follow the screens and workflows embedded in these systems, with all kinds of cool UI-widgets
I see budgets being given or denied
I see people in fun training
I see promotions, new hero-managers, with powerfull mandate
I see jobpromotions, jobdescriptions and evaluation cycles that will actually hit people in their wallet, with big bonusses for the right behaviour
And then there is us, process consultants, proudly showing the next swimminglane model and desperately trying to find someone to take process-responsibility...
How sexy and influencial is that??????
Can anyone help this disillusioned BPM-practioner with concrete examples of process-interventions that inspired, motivated, improved, e.g. sexy?????
10 easy? questions for managing IT-change
Where various parties from business and IT collaborate in deciding on IT-change (implementing changes, based on various new or changing requirements), a complex playingfield arises.
Often, in my observation, many companies struggle, in terms of "who will need to decide what", during the preparation and delivery-phases of IT-changes. With a more fundamental understanding of the types of questions that needs to be answered and the ownership of these answers/decisions, more clarity can be created (and confusion avoided...).
I think, in essence, we have to deal with 10 easy questions. Well, easy, in terms of the answers provided, they are easy, but to answer them with confidence, based on the right information, might be quite complex....
Here are the 10 questions, that should drive your change-process (for instance your ITIL change process, or any other changeprocess, for instance in deciding and implementing change-requests for your software applications) and create a clear demand/supply relation:
Before realizing the change:
1. Do we understand and really want this change? (business)
2. Are we willing to invest to research solutions? (business)
3. Is the change really feasible, what solution-scenarios exist? (IT)
4. Do we understand the solution-scenario's and are we willing to commit to one (including the consequences)? (business)
5. Can we agree on a realistic start- and enddate? (Business and IT)
6. Do we commit to adequately lead the change from the business perspective? (business)
7. Are we, as IT, willing and able to commit to deliver the chosen solution? (IT)
After realizing the change:
8. Do we accept the delivered solution? (business)
9. Are we willing to implement the solution in our operations (and supporting IT-layer)? (business)
10. Are we done, happy and ready to move on? (business and IT)
I hope that during your changeprocess these questions are clearly answered by the right stakeholder!
In more detail:
1. Do we understand and really want this change?
Key owner: business (and IT to advise)
Remarks: we need to adequately understand a change-request, and assess (preliminary) if it is realistic (we want our app to make coffee, but the end of this week)...
Subquestions:
- Is the submitted change-request clear and understandable? Is the context (Why, Who) clear? Is it (preferably) mainly stated in "what" terms (business requirements), and possibly supported by (preliminary) "how" statements. Is there a "When"?
- Is the requested change (in principle) feasible? (IT advise!)
- Is the (preliminary) "When" (in principle) realistic? (IT advise!)
2. Are we willing to invest to research solutions?
Key owner: business
Remarks: only for very simple requests, we might directly see the solution and required changes in our IT-landscape. More often, IT will need to research the request, and come up with various possible solution-scenario's, that each has it's pro's/cons and consequences
Subquestions:
- Are we willing to free and assign capacity @ IT to research the requirement, and wait for some time to let them deliver? Do we accept the cost? Owner: business
- Are we, if needed, willing to deprioritize other IT-activities, to let this research be executed? Owner: business, with strong IT advise
- Are we able (as business) to further guide IT (and answers business related questions about the requested change)? (business!)
- Are we able to deliver adequate research? Do we have the resources with the right experience and knowledge available? (IT!)
3. Is the change really feasible, and what solution-scenarios exist?
Key owner: IT
Remarks: Based on the changerequest, IT needs to research: can we do this, and how (not in all detail, but in enough detail to have enough trust to answer the question and allow the business to decide the next steps). Research in terms of technical scenario's, their functional and technical impact for the business and IT and the consequences of the solutionscenario, in terms of cost, required resources, time, risks. And an assessment how the scenario fits in the architecture(plans and guidelines).
Subquestions:
- Are there technical solutions that fulfill (fully or partly) the requirements from the change? If yes, what solutions?
- For each solution:
- what are functional consequences
- what are technical consequences?
- what are consequences for future maintenance and supportability?
- does the solution fit in the current/to be architecture?
- And for each solution: how can we realize this solution, in terms of approach, cost, time, required resources? What risks?
4. Do we understand the solution-scenario's and are we willing to commit to one (including the consequences)?
Key owner: business
Remarks: In the end, business needs to decide the scenario and accept consequences (to it's operations and the related change-efforts/investments)
5. Can we agree on a realistic start- and enddate?
Owner: Business AND IT
Subquestions:
- Does this fit in current plans and available resources?
- If not, can we agree on re-priotizing/delay other requests?
- Are there other solutions (in terms of sourcing)?
6. Do we commit to adequately lead the change from the business perspective?
Owner: Business
Remarks: This is a critical question. Many IT-projects suffer from ambitious business, that fails to provide clear and adequate guidance (enough support and time from critical business people) and speed of decisionmaking
Subquestion:
- Can we, as business, free the required people as leaders and subject matter experts?
- Are we willing and able to setup a good issue-resolution process, and commit to it?
- Are we willing to steer the project, take part in steering organization and make tough decisions in a timely fashion?
- Are we willing to invest in the relations and social networks between business, IT and project?
- Do we have but also feel the trust that we can work together with the people on the IT-side?
7. Are we, as IT, willing and able to commit to deliver the chosen solution?
Owner: IT
Subquestions:
- Do we have the drive, trust, knowledge, experience to deliver?
- Do we have the maturity to manage this?
- Do we feel the circiumstances are right? All critical succesfactors covered?
- Do we have but also feel the trust that we can work together with the people in the business?
8. Do we accept the delivered solution?
Owner: business
Remarks: IT has delivered now, and we have taken various actions to gather information on the solution. We checked in various tests and reviews if the solution conforms to the change-requirements(verification) and also checked if the solution will work in our operations(validation).
Subquestions:
- Does the solution comply to the requirements?
- Will the solution fit in our operations?
- Do we have sufficient information to really assess and decide on acceptance?
9. Are we willing to implement the solution in our operations (and supporting IT)?
Owner: business
Remarks: now it's time to get the IT-change in production.
Subquestions:
- Are we ready?
- Has the change been rolled out correctly?
- Acceptable risks for operations?
10. Are we done, happy and ready to move on?
Owner: business and IT
Subquestions:
- Will the business case be reached?
- Is the change correctly functioning in operations?
- Can we close the change, with full satisfaction?
- Did we learn the right lessons? Will we remember them?
- Are we still respected partners?
Often, in my observation, many companies struggle, in terms of "who will need to decide what", during the preparation and delivery-phases of IT-changes. With a more fundamental understanding of the types of questions that needs to be answered and the ownership of these answers/decisions, more clarity can be created (and confusion avoided...).
I think, in essence, we have to deal with 10 easy questions. Well, easy, in terms of the answers provided, they are easy, but to answer them with confidence, based on the right information, might be quite complex....
Here are the 10 questions, that should drive your change-process (for instance your ITIL change process, or any other changeprocess, for instance in deciding and implementing change-requests for your software applications) and create a clear demand/supply relation:
Before realizing the change:
1. Do we understand and really want this change? (business)
2. Are we willing to invest to research solutions? (business)
3. Is the change really feasible, what solution-scenarios exist? (IT)
4. Do we understand the solution-scenario's and are we willing to commit to one (including the consequences)? (business)
5. Can we agree on a realistic start- and enddate? (Business and IT)
6. Do we commit to adequately lead the change from the business perspective? (business)
7. Are we, as IT, willing and able to commit to deliver the chosen solution? (IT)
After realizing the change:
8. Do we accept the delivered solution? (business)
9. Are we willing to implement the solution in our operations (and supporting IT-layer)? (business)
10. Are we done, happy and ready to move on? (business and IT)
I hope that during your changeprocess these questions are clearly answered by the right stakeholder!
In more detail:
1. Do we understand and really want this change?
Key owner: business (and IT to advise)
Remarks: we need to adequately understand a change-request, and assess (preliminary) if it is realistic (we want our app to make coffee, but the end of this week)...
Subquestions:
- Is the submitted change-request clear and understandable? Is the context (Why, Who) clear? Is it (preferably) mainly stated in "what" terms (business requirements), and possibly supported by (preliminary) "how" statements. Is there a "When"?
- Is the requested change (in principle) feasible? (IT advise!)
- Is the (preliminary) "When" (in principle) realistic? (IT advise!)
2. Are we willing to invest to research solutions?
Key owner: business
Remarks: only for very simple requests, we might directly see the solution and required changes in our IT-landscape. More often, IT will need to research the request, and come up with various possible solution-scenario's, that each has it's pro's/cons and consequences
Subquestions:
- Are we willing to free and assign capacity @ IT to research the requirement, and wait for some time to let them deliver? Do we accept the cost? Owner: business
- Are we, if needed, willing to deprioritize other IT-activities, to let this research be executed? Owner: business, with strong IT advise
- Are we able (as business) to further guide IT (and answers business related questions about the requested change)? (business!)
- Are we able to deliver adequate research? Do we have the resources with the right experience and knowledge available? (IT!)
3. Is the change really feasible, and what solution-scenarios exist?
Key owner: IT
Remarks: Based on the changerequest, IT needs to research: can we do this, and how (not in all detail, but in enough detail to have enough trust to answer the question and allow the business to decide the next steps). Research in terms of technical scenario's, their functional and technical impact for the business and IT and the consequences of the solutionscenario, in terms of cost, required resources, time, risks. And an assessment how the scenario fits in the architecture(plans and guidelines).
Subquestions:
- Are there technical solutions that fulfill (fully or partly) the requirements from the change? If yes, what solutions?
- For each solution:
- what are functional consequences
- what are technical consequences?
- what are consequences for future maintenance and supportability?
- does the solution fit in the current/to be architecture?
- And for each solution: how can we realize this solution, in terms of approach, cost, time, required resources? What risks?
4. Do we understand the solution-scenario's and are we willing to commit to one (including the consequences)?
Key owner: business
Remarks: In the end, business needs to decide the scenario and accept consequences (to it's operations and the related change-efforts/investments)
5. Can we agree on a realistic start- and enddate?
Owner: Business AND IT
Subquestions:
- Does this fit in current plans and available resources?
- If not, can we agree on re-priotizing/delay other requests?
- Are there other solutions (in terms of sourcing)?
6. Do we commit to adequately lead the change from the business perspective?
Owner: Business
Remarks: This is a critical question. Many IT-projects suffer from ambitious business, that fails to provide clear and adequate guidance (enough support and time from critical business people) and speed of decisionmaking
Subquestion:
- Can we, as business, free the required people as leaders and subject matter experts?
- Are we willing and able to setup a good issue-resolution process, and commit to it?
- Are we willing to steer the project, take part in steering organization and make tough decisions in a timely fashion?
- Are we willing to invest in the relations and social networks between business, IT and project?
- Do we have but also feel the trust that we can work together with the people on the IT-side?
7. Are we, as IT, willing and able to commit to deliver the chosen solution?
Owner: IT
Subquestions:
- Do we have the drive, trust, knowledge, experience to deliver?
- Do we have the maturity to manage this?
- Do we feel the circiumstances are right? All critical succesfactors covered?
- Do we have but also feel the trust that we can work together with the people in the business?
8. Do we accept the delivered solution?
Owner: business
Remarks: IT has delivered now, and we have taken various actions to gather information on the solution. We checked in various tests and reviews if the solution conforms to the change-requirements(verification) and also checked if the solution will work in our operations(validation).
Subquestions:
- Does the solution comply to the requirements?
- Will the solution fit in our operations?
- Do we have sufficient information to really assess and decide on acceptance?
9. Are we willing to implement the solution in our operations (and supporting IT)?
Owner: business
Remarks: now it's time to get the IT-change in production.
Subquestions:
- Are we ready?
- Has the change been rolled out correctly?
- Acceptable risks for operations?
10. Are we done, happy and ready to move on?
Owner: business and IT
Subquestions:
- Will the business case be reached?
- Is the change correctly functioning in operations?
- Can we close the change, with full satisfaction?
- Did we learn the right lessons? Will we remember them?
- Are we still respected partners?
Sunday, September 06, 2009
Five models to assess your project and stay sane
BPM, IT, and actually any type of project can sometimes be overwhelming in complexity, issues, social patterns and such. In my 17 years of projects, I have developed enough scartissue... And for the more junior-readers: yes, projects fail, including projects I was part of....
In the 17 years I also tried, every time, to learn and understand what happened in the project and why it was a failure, a challenge or a success. It lead to a large set of "sanity checklists" and other best practices. And also to quite some analysis-tools. In this post I want to share 5 easy diagrams as tools for analysis of the project you are working in (or better: about to work in). The tools deal with simple questions you can research within your project. It leads typically to 2 answers: the way it is currently, and the way it should be to be able to deliver succesfully.
Model 1:
Model 1 deals with the process or method you need to choose to deliver the projectproducts.
Two simple questions, try to answer them, map out where it lands in the diagram and then compare to the method that has been chosen for the project (hopefully it was a deliberate choice, and not the often occuring "goodwilling people, yet chaos approach").
In the 17 years I also tried, every time, to learn and understand what happened in the project and why it was a failure, a challenge or a success. It lead to a large set of "sanity checklists" and other best practices. And also to quite some analysis-tools. In this post I want to share 5 easy diagrams as tools for analysis of the project you are working in (or better: about to work in). The tools deal with simple questions you can research within your project. It leads typically to 2 answers: the way it is currently, and the way it should be to be able to deliver succesfully.
Model 1:
Model 1 deals with the process or method you need to choose to deliver the projectproducts.
Two simple questions, try to answer them, map out where it lands in the diagram and then compare to the method that has been chosen for the project (hopefully it was a deliberate choice, and not the often occuring "goodwilling people, yet chaos approach").
Model 2:
Model 2 deals with the amount of ceremony in terms of process and documentation you will need. Again two simple questions.... This tool is great to work with people that either want to overstructure/overdocument when it is not required or people that want to travel very very light, when more is needed...
Model 3:
Model 3 deals with control on the content in your project (so, not on time/cost, which typically already gets enough attention). This deals with: how do we deal with uncertainty in requirements or design. I see many projects that fail to create control over these vital elements. The results are typically confusion, failing assumptions and rework...
Model 4:
Model 4 deals with leadership versus group-behaviour. I have seen projects deliver with low leadership or low groupcohesion, but the combination of these situations is typically deadly. I believe in groups and the great work that can be done by them, but only if they are willing to allign to goals and have enough social cohesion. Usually this occurs if you are working with people that have enough skills and limited ego to cooperate or a strong leader that is able to align people...
Model 5:
The last model is about you (or the people you depend on in the project, enabling you to deliver your scope of the project). I developed it when in a certain project I was very unhappy. I tried to understand why - and found that I was very involved/committed, but had no real influence, in a project which was heading for disaster. Stuck between a rock and a hard place, with only three options - get more influence (tried, no succes) or don't care anymore (not my style), or... get out. I choose the last option, with no regrets. The project failed 3 months later.
More lessons and tools welcome!
Wednesday, July 22, 2009
5 ways to green BPM
In all the turnmoil on the global crisis, but also the media storms on "clouds" within the BPM community, I hope there is still some space left for sustainability, people/profit/planet and environmental issues.
In my opinion, a process-focus can strengthen our ability to improve the sustainability of our business and reduce the negative environmental footprint: P4 (people, profit, planet - and process).
BPM, as a framework for seeing your company through the lense of process, aims at understanding, measuring and improving your processes. While the traditional focus for BPM is things as cycle-time, cost, customer value/service, environmental aspects can be easily incorporated in the BPM approach.
I suggest 5 possible ways to use BPM in greening your processes and business:
1. Analyse - Measure - Select
As part of most BPM efforts current processes are modelled/documented and measured. This provides important insight to know where improvement-areas are. For sustainability we should be able to come up with "GPI's" (thanks to my collegueas for this term) - green performance indicators. Measurements based on these GPI's can give a company insight in their processes: which processes (and even which steps in these processes) have a large environmental footprint.
You can use this information to define an actionplan, and select the processes where the "biggest bang" can be reached. The starting-measurements can later be used to compare to improvement-results. And you might even want to decide to incorporate periodical measurements of your "GPI's" in your Green Balanced Score Card.
As a sidenote: measurement can also support benchmarking, which could help entire industries (why do we need 10 kg of paper in processing 100 insurance-policies, while our competitors can do with 1 kg?)
As part of the process-analysis, the company could attempt to find aspects of the processes, thay may drive environmental footprint - for instance: is there a lot of paper used, a lot of km's traveled, a lot of interaction between various locations/people to execute this process?
After step 1, a number of other steps can be taken:
- Optimize
- Recycle
- Innovate/Re-engineer
- Synergize
2. Optimize
Using techniques from Lean and Six Sigma, various Green optimizations can probably be found. The 7 Waste approach could for instance identify unneeded transport (CO2!). The Six Sigma Root-cause analysis could help identify unwanted environmental effects and their causes.
All these results can be used to gradually improve the process
Case: by stepwise improvements paper-production companies are lowering the amount of water needed, and reduce the water-pollution
Case: a company allowed people to work from home on certain days, using a PC, which reduced CO2 / transport
3. Recycle
It might be possible to recycle materials used as input or output (either process-products, or supporting material). In many industries bottles, glas, paper, etc. is being recycled.
Case: diary factory sells milk in bottles, which are being returned by customers for reuse
4. Innovate/Re-engineer
Taking the BPR approach, one might be able to totally reengineer the process, so that a radical better environmental effect can be used. In some radical cases, the process might not even be needed anymore
Case: various companies re-engineered their invoice-processes, making them all digital instead of paper. Paper and transport went down considerably.
5. Synergize
By closely looking at your process (inputs, outputs) and other processes (within you company or outside), it might be possible to identify ways to create environmental synergy.
Case: an IT-company located their datacenter in a greenhouse-area. The heat of the datacenter is used to warm the greenhouses.
Case: a Shrimp-farm located their farm next to a large energyfactor, the emitted heated water is used to warm the shrimp-bassins.
One might think that these steps can only be applied to production-industry. But....
In many administrative factories, processes consume large amounts of paper, storage and transport of paper, and transport of people for meetings. The 5 items above, combined with BPM technology, supported by ECM and Collaborative tools (videoconferences) can deliver great green effects (and hard Euro/Dollar-savings!).
Cases and Ideas welcome!
In my opinion, a process-focus can strengthen our ability to improve the sustainability of our business and reduce the negative environmental footprint: P4 (people, profit, planet - and process).
BPM, as a framework for seeing your company through the lense of process, aims at understanding, measuring and improving your processes. While the traditional focus for BPM is things as cycle-time, cost, customer value/service, environmental aspects can be easily incorporated in the BPM approach.
I suggest 5 possible ways to use BPM in greening your processes and business:
1. Analyse - Measure - Select
As part of most BPM efforts current processes are modelled/documented and measured. This provides important insight to know where improvement-areas are. For sustainability we should be able to come up with "GPI's" (thanks to my collegueas for this term) - green performance indicators. Measurements based on these GPI's can give a company insight in their processes: which processes (and even which steps in these processes) have a large environmental footprint.
You can use this information to define an actionplan, and select the processes where the "biggest bang" can be reached. The starting-measurements can later be used to compare to improvement-results. And you might even want to decide to incorporate periodical measurements of your "GPI's" in your Green Balanced Score Card.
As a sidenote: measurement can also support benchmarking, which could help entire industries (why do we need 10 kg of paper in processing 100 insurance-policies, while our competitors can do with 1 kg?)
As part of the process-analysis, the company could attempt to find aspects of the processes, thay may drive environmental footprint - for instance: is there a lot of paper used, a lot of km's traveled, a lot of interaction between various locations/people to execute this process?
After step 1, a number of other steps can be taken:
- Optimize
- Recycle
- Innovate/Re-engineer
- Synergize
2. Optimize
Using techniques from Lean and Six Sigma, various Green optimizations can probably be found. The 7 Waste approach could for instance identify unneeded transport (CO2!). The Six Sigma Root-cause analysis could help identify unwanted environmental effects and their causes.
All these results can be used to gradually improve the process
Case: by stepwise improvements paper-production companies are lowering the amount of water needed, and reduce the water-pollution
Case: a company allowed people to work from home on certain days, using a PC, which reduced CO2 / transport
3. Recycle
It might be possible to recycle materials used as input or output (either process-products, or supporting material). In many industries bottles, glas, paper, etc. is being recycled.
Case: diary factory sells milk in bottles, which are being returned by customers for reuse
4. Innovate/Re-engineer
Taking the BPR approach, one might be able to totally reengineer the process, so that a radical better environmental effect can be used. In some radical cases, the process might not even be needed anymore
Case: various companies re-engineered their invoice-processes, making them all digital instead of paper. Paper and transport went down considerably.
5. Synergize
By closely looking at your process (inputs, outputs) and other processes (within you company or outside), it might be possible to identify ways to create environmental synergy.
Case: an IT-company located their datacenter in a greenhouse-area. The heat of the datacenter is used to warm the greenhouses.
Case: a Shrimp-farm located their farm next to a large energyfactor, the emitted heated water is used to warm the shrimp-bassins.
One might think that these steps can only be applied to production-industry. But....
In many administrative factories, processes consume large amounts of paper, storage and transport of paper, and transport of people for meetings. The 5 items above, combined with BPM technology, supported by ECM and Collaborative tools (videoconferences) can deliver great green effects (and hard Euro/Dollar-savings!).
Cases and Ideas welcome!
Wednesday, June 24, 2009
A day in the life of a processconsultant
I am currently in the luxerious but also difficult position of a processconsultant in a quite demanding project, that requires effort from me in a wide range of (process)consultancy areas.
Warning: if you think processconsultants listen, then goto their room to draw and publish processdiagrams, and magically people will follow these... read on....
Here are 5 areas you may encounter as processconsultant depending on your scope and influence. Or in my case, because in these areas things were not evolving well, and were impacting my ability to deliver good results, so I, sigh, jumped in.... (but do check your client, to see if they want you there....)
Area 1. Power discussions
The funny thing about most processes, is that they cut through various functional areas, with their own reporting structure. When designing new processes, early on (or in some cases, too late) the powerquestion will pop up: who will be responsible for what part of the process. And this means the interesting culture of manager's ego's (score!) and risk-aversion (avoid!)
As a processconsultant you might find yourself in workshops, email fights, and waiting for the "oracles" to decide (and hope the verdict will stay the same for some time...)
Area 2. Strategy clarification/operationalization
The typical thing you want as an organization is that your processes actually support (or realize) your strategy. Porter calls it "FIT". And the funny thing about many organizations, especially during change-dynamics, is that some of the strategy might be defined (and sometimes even written down! Sorry, ironic), but often, the management "bla" is so high-level that even selling icecream might be a perfectly fine process with great strategy alignments in terms of "customer focus, quality, etc". So, to bridge the gap between strategy and operations, strategy will need to be detailed in more operational aspects. As a processconsultant you might find yourself coaching mid-level managers to translate the management bla to things that have meaning for the mortal souls, including yourself to be able to define the right process.
Area 3. Groupdynamics and coaching
So you think doing some interviews, showing the diagrams will create alignment? Will create support for new ways of working? Think again. Change is hard, and building support for blueprints describing the future, while it's being build is even harder. As a processconsultant you will find yourself often in groups that are in various forms of disagreement. And often they will look to you, to help/facilitate them to find the answers. Their points of view might confuse you, irritate you, and/or enlighten you (and possibly all at the same time). Help them to find consensus. But you will need their teamlead to decide and steer, where needed.
Area 4. Operational negotiations
Ah, the processdesign looks good, but now the real work starts: implementing it. This will lead to many additional process aspects. How will work be coordinated? Who will sit in what governance structure? Who does what in the processpart of this team? How will we split the work? How do we deal with performance requirements? Vacations and workschedules. A lot of processlogistics need to be settled. As a processconsultant you will find yourself in various HR type discussions, trying to get the team to work....
Area 5. Steering, coaching the manager/teamleads
You may have defined a great process, and even defined key performance indicators (KPI's), but the teamleads need to be empowered: what will they do when one of the KPI's goes off bounds? What steering mechanism do they have, and when will they use it? How to help them get beyond firefighting (which is often a start for processimprovement) culture and get them to start steering in a more tactical way?
Some tips and best practices
- Know your scope as processconsultant, and be conscious about extending your role (you might have too much work and/or too little influence)
- Know your groupdynamics (norming, forming, etc) and change (ADKAR, Carnall's Coping Cycle). Keep an open eye on what's happening in the team(s) around you.
- Be able to operate on strategic, tactical and operational level (including the people on these levels - culture, network, vocabulary)
- Be able to step into the facilitator's role, guiding people to make their own choices (it's their process anyway, "egoless processdesign")
- Ambitions for change might be high, but ability to deliver in the organization will determine the actual results. Be pragmatic, but also don't get crushed between vision and results.
- Maturity for an organization will take time and the right interventions. Be patient when needed, and let things fail even, if needed to get messages/learning across. "If that what must, can't, then make sure what can must" (freely translated from dutch).
- It's people, your work is about people (and a bit of process)
Concluding thoughts
I seem to return to a central purpose for a processconsultant - mainly: to create clarity, consensus and alignment (say 95% of your time), the rest: dropping it in (ever evolving) processmodels.
Last: spend your energy in your own developments accordingly (learning in 2 weeks all the details of BPMN might be interesting, but you might need other priorities ;-))
Warning: if you think processconsultants listen, then goto their room to draw and publish processdiagrams, and magically people will follow these... read on....
Here are 5 areas you may encounter as processconsultant depending on your scope and influence. Or in my case, because in these areas things were not evolving well, and were impacting my ability to deliver good results, so I, sigh, jumped in.... (but do check your client, to see if they want you there....)
Area 1. Power discussions
The funny thing about most processes, is that they cut through various functional areas, with their own reporting structure. When designing new processes, early on (or in some cases, too late) the powerquestion will pop up: who will be responsible for what part of the process. And this means the interesting culture of manager's ego's (score!) and risk-aversion (avoid!)
As a processconsultant you might find yourself in workshops, email fights, and waiting for the "oracles" to decide (and hope the verdict will stay the same for some time...)
Area 2. Strategy clarification/operationalization
The typical thing you want as an organization is that your processes actually support (or realize) your strategy. Porter calls it "FIT". And the funny thing about many organizations, especially during change-dynamics, is that some of the strategy might be defined (and sometimes even written down! Sorry, ironic), but often, the management "bla" is so high-level that even selling icecream might be a perfectly fine process with great strategy alignments in terms of "customer focus, quality, etc". So, to bridge the gap between strategy and operations, strategy will need to be detailed in more operational aspects. As a processconsultant you might find yourself coaching mid-level managers to translate the management bla to things that have meaning for the mortal souls, including yourself to be able to define the right process.
Area 3. Groupdynamics and coaching
So you think doing some interviews, showing the diagrams will create alignment? Will create support for new ways of working? Think again. Change is hard, and building support for blueprints describing the future, while it's being build is even harder. As a processconsultant you will find yourself often in groups that are in various forms of disagreement. And often they will look to you, to help/facilitate them to find the answers. Their points of view might confuse you, irritate you, and/or enlighten you (and possibly all at the same time). Help them to find consensus. But you will need their teamlead to decide and steer, where needed.
Area 4. Operational negotiations
Ah, the processdesign looks good, but now the real work starts: implementing it. This will lead to many additional process aspects. How will work be coordinated? Who will sit in what governance structure? Who does what in the processpart of this team? How will we split the work? How do we deal with performance requirements? Vacations and workschedules. A lot of processlogistics need to be settled. As a processconsultant you will find yourself in various HR type discussions, trying to get the team to work....
Area 5. Steering, coaching the manager/teamleads
You may have defined a great process, and even defined key performance indicators (KPI's), but the teamleads need to be empowered: what will they do when one of the KPI's goes off bounds? What steering mechanism do they have, and when will they use it? How to help them get beyond firefighting (which is often a start for processimprovement) culture and get them to start steering in a more tactical way?
Some tips and best practices
- Know your scope as processconsultant, and be conscious about extending your role (you might have too much work and/or too little influence)
- Know your groupdynamics (norming, forming, etc) and change (ADKAR, Carnall's Coping Cycle). Keep an open eye on what's happening in the team(s) around you.
- Be able to operate on strategic, tactical and operational level (including the people on these levels - culture, network, vocabulary)
- Be able to step into the facilitator's role, guiding people to make their own choices (it's their process anyway, "egoless processdesign")
- Ambitions for change might be high, but ability to deliver in the organization will determine the actual results. Be pragmatic, but also don't get crushed between vision and results.
- Maturity for an organization will take time and the right interventions. Be patient when needed, and let things fail even, if needed to get messages/learning across. "If that what must, can't, then make sure what can must" (freely translated from dutch).
- It's people, your work is about people (and a bit of process)
Concluding thoughts
I seem to return to a central purpose for a processconsultant - mainly: to create clarity, consensus and alignment (say 95% of your time), the rest: dropping it in (ever evolving) processmodels.
Last: spend your energy in your own developments accordingly (learning in 2 weeks all the details of BPMN might be interesting, but you might need other priorities ;-))
Sunday, June 14, 2009
Work in a process. More then we typically see...
Recently delivered training to a group of processconsultants. One item is "workflowmanagement" (no, I do not mean the technology). What we mean in the training when we talk about workflowmanagement is all the work and supporting business rules that coordinate the work being done, e.g. that make the work flow.
Interestingly enough, the students had a hard time seeing the point.
When we talk about a process, people typically limit their view to the direct work being done. If a process consists of activity A, B and C, then, when asked what work is done in the process, they will say "well, A, B and C". Sometimes we play a little game with them, to clarify: we assign tasks A, B and C, and tell them to go ahead and do the process. Work evolves and quickly we can point to new tasks that people suddenly are doing: coordination, making the work flow. Making sure the output of A is delivered to B, so the person doing B can continue. People than understand that transport is an additional activity. But unfortunately, they still don't see that the transport also has a hidden business rule for coordination "if you receive output of A, then start processing B".
The (unfortunately now technical) concepts of "orchestration" and "choreograpy" are two patterns that are used a lot when people are doing work and coordinating the work. Often we see choreography, where people have thought upfront on the process, and agreed on various actions and rules to let the work flow ("so if you are ready with X, you give it to me, and I will...."). Orchestration you see somewhat less: "Micromanaging supervisors", but in, for instance warehouse picking, there is usually a central coordinating unit that hands out work-orders, and triggers other work-orders when the earlier work-orders have been reported ready.
As part of an MBA training we played a process simulation game, to practice applying lean techniques to improve the process. When the group analysed the results of a round of playing, suddenly someone discovered her own "choreograph" activity and the bottleneck it created: the person "batched" outgoing work and delivered when the stack was getting too big (bottleneck 1) and also delivered the items as Last In, First Out order, which later in the process created longer and variating cycle times (bottleneck 2). A nice example of suboptimal workflowmanagement....
My point: in every process, there is a hidden set of activities and business rules, that make the work flow (in terms of activating/triggering people to wait/start/continue). When optimizing processes, this "hidden" process is a vital element in process optimization. We might blindly stare at improving executing A, B or C, but looking at the coordination and supporting rules will also often give a lot of optimization possibilities.
Interestingly enough, the students had a hard time seeing the point.
When we talk about a process, people typically limit their view to the direct work being done. If a process consists of activity A, B and C, then, when asked what work is done in the process, they will say "well, A, B and C". Sometimes we play a little game with them, to clarify: we assign tasks A, B and C, and tell them to go ahead and do the process. Work evolves and quickly we can point to new tasks that people suddenly are doing: coordination, making the work flow. Making sure the output of A is delivered to B, so the person doing B can continue. People than understand that transport is an additional activity. But unfortunately, they still don't see that the transport also has a hidden business rule for coordination "if you receive output of A, then start processing B".
The (unfortunately now technical) concepts of "orchestration" and "choreograpy" are two patterns that are used a lot when people are doing work and coordinating the work. Often we see choreography, where people have thought upfront on the process, and agreed on various actions and rules to let the work flow ("so if you are ready with X, you give it to me, and I will...."). Orchestration you see somewhat less: "Micromanaging supervisors", but in, for instance warehouse picking, there is usually a central coordinating unit that hands out work-orders, and triggers other work-orders when the earlier work-orders have been reported ready.
As part of an MBA training we played a process simulation game, to practice applying lean techniques to improve the process. When the group analysed the results of a round of playing, suddenly someone discovered her own "choreograph" activity and the bottleneck it created: the person "batched" outgoing work and delivered when the stack was getting too big (bottleneck 1) and also delivered the items as Last In, First Out order, which later in the process created longer and variating cycle times (bottleneck 2). A nice example of suboptimal workflowmanagement....
My point: in every process, there is a hidden set of activities and business rules, that make the work flow (in terms of activating/triggering people to wait/start/continue). When optimizing processes, this "hidden" process is a vital element in process optimization. We might blindly stare at improving executing A, B or C, but looking at the coordination and supporting rules will also often give a lot of optimization possibilities.
Assignment: next time you encounter a process (say, eating out) watch the process coordination going. You will see a lot of stuff happening and (sometimes) fail....
Process-design and your view on people
Quite busy, so my flow of blogitems has been diminished considerably. But collecting a lot of thoughts, observations and lessons, so maybe some time soon....
Today's thought: view on people
As processconsultant, I think it's vital that you have a clear understanding of your own view on people in the context of processes.
I encounter two opposing variations in the BPM world (and anything in between):
1. As processconsultant, we gather input, then design the process, then implement it. Implementing means: pushing people in the pigeonholes (processes, activities, roles), and assume they will do their work, driven by KPI's and managers whipping the lot.
The basis assumption: if you design, they will come and do. The rest is "changemanagement", where we explain and assume that either "they" accept, or we encounter "resistance", which we will need to "overcome". We own the process, but accept "input".
I find this approach also a lot in the BPM technology space "Buy this tool, define the process, and your people will obey and empty their taskboxes....".
So, first goals, then process/technology, then people.
2. Processes are done by people, to reach certain goals. So... first we have goals, then people, then, as a supporting mechanism, we have processes. Quite a different viewpoint! Here we first have to understand the goals of the organization and find people willing to support these goals (if nobody found, the rest is pointless). Once we have these people, we work with them (as a supporting/facilitator) to help them structure their work to reach those goals. They own the process, we bring in the process-structuring knowledge.
I firmly believe in approach 2. Yes, it requires more talking, and even more scary: being vulnerable and sometimes unsure what the people/group will want/do/support. It means running workshops, not owning the result, only the way to get there.... It also means accepting that the quality of the outcoming processes is purely based on the maturity of the people you work with. And with careful interventions you might be able to stimulate/let them grow.
In my experience I have to often seen type 1 approaches result in a lot of paper or BPA tools filled with stuff, but no implementation or support from the key people you need for working processes: the process participants or better: the PEOPLE, that understand and are happy to be supported by the process.....
Today's thought: view on people
As processconsultant, I think it's vital that you have a clear understanding of your own view on people in the context of processes.
I encounter two opposing variations in the BPM world (and anything in between):
1. As processconsultant, we gather input, then design the process, then implement it. Implementing means: pushing people in the pigeonholes (processes, activities, roles), and assume they will do their work, driven by KPI's and managers whipping the lot.
The basis assumption: if you design, they will come and do. The rest is "changemanagement", where we explain and assume that either "they" accept, or we encounter "resistance", which we will need to "overcome". We own the process, but accept "input".
I find this approach also a lot in the BPM technology space "Buy this tool, define the process, and your people will obey and empty their taskboxes....".
So, first goals, then process/technology, then people.
2. Processes are done by people, to reach certain goals. So... first we have goals, then people, then, as a supporting mechanism, we have processes. Quite a different viewpoint! Here we first have to understand the goals of the organization and find people willing to support these goals (if nobody found, the rest is pointless). Once we have these people, we work with them (as a supporting/facilitator) to help them structure their work to reach those goals. They own the process, we bring in the process-structuring knowledge.
I firmly believe in approach 2. Yes, it requires more talking, and even more scary: being vulnerable and sometimes unsure what the people/group will want/do/support. It means running workshops, not owning the result, only the way to get there.... It also means accepting that the quality of the outcoming processes is purely based on the maturity of the people you work with. And with careful interventions you might be able to stimulate/let them grow.
In my experience I have to often seen type 1 approaches result in a lot of paper or BPA tools filled with stuff, but no implementation or support from the key people you need for working processes: the process participants or better: the PEOPLE, that understand and are happy to be supported by the process.....
Wednesday, March 11, 2009
Need for other BPM patterns - business focused
A lot of research has been done in the area of process patterns, mainly performed by the TUE (The Netherlands, see here) and QUT (Australia, see here). These patterns are great for validation of the capabilities and semantics of process languages (BPEL, BPMN) and technologies.
However, I think we are missing a set of process patterns, that are business focused. If we would have a good set, I think it will help us delivering projects better and quicker, and also improve our communication between business and BPM technology consultants.
Comment: When I was working on the patterns below, I found that these are mainly task focused. Flow aspects can be served well with the workflow patterns.
Based on my projects experience, I could already see a number of task patterns:
A. Simpel patterns - typical serial workflow based processes
A1. Information capture
A task in which a person is required to capture information from sources outside the system, such as a phonecall or paper-document and enter it as structured and unstructured data.
Typical context:
- Salesrep
- Call center
- Internal HR procedures
A2. Information extraction and structured storage
A task in which a person is required to review unstructured data in the system (such as the scanned image of a document) and extract data and enter it as structured data.
Typical context:
- Backoffice document processing
A3. Prepare advice
A task in which a person reviews the data of a specific request, refines the data using functionality of the system (for instance certain calculations, risk assessments, price, etc) and prepares an advice ("yes, I propose to sell this customer a policy type X, with these conditions")
Typical context:
- Front office processing, sales, underwriting
A4. Decision
A task in which a specific person, based on her/his role needs to decide on something. The task will provide for the required information (case specific, possibly also other data), and the person will need to make a decision.
Typical context:
- Approvals
A5. Review based on 4-eyes principle/judgment
A task for which a person needs to review the correct execution of an earlier task (usual: prepare advice, decision) and make a statement of the correctness of the execution, leading to acceptance of the tasks output or rework.
A6. Inform
A task (or better: a notification) informing a certain stakeholder about critical facts about the execution of a specific process instance ("your request was accepted, your loan will be payed ...."
B. More complex situations
Many more patterns can be defined for process execution. This would support more complex knowledge work situations.
Think of:
B1. Collaborative event for sharing (plan, execute)
When more than 1 person is concurrently needed for a task, in this case: sharing of information
B2. Collaborative event for decision
When more than 1 person is concurrently needed for a task, in this case: deciding
B3. Add a dynamic task
B4. Add process participants
C. Controling & Steering (operational management)
Each process also has a "control" proces (the P, D and C parts of the Plan-Do-Check-Act cycle). For this process it's valuable to also have standard patterns...
C1. Warn
Warn a certain person if specific KPI's of a certain process instance are out of bounds.
C2. Escalate
If a certain task has not been done in a certain predefined time period, escalate it to someone else (automatically, or manually after a signal), higher up the organization
C3. Re-assign
If the workload of a person or team is too high, reassign one or more tasks to another person/team, but on same organizational level
Has these types of patterns already been defined somewhere? Used? Curious.
However, I think we are missing a set of process patterns, that are business focused. If we would have a good set, I think it will help us delivering projects better and quicker, and also improve our communication between business and BPM technology consultants.
Comment: When I was working on the patterns below, I found that these are mainly task focused. Flow aspects can be served well with the workflow patterns.
Based on my projects experience, I could already see a number of task patterns:
A. Simpel patterns - typical serial workflow based processes
A1. Information capture
A task in which a person is required to capture information from sources outside the system, such as a phonecall or paper-document and enter it as structured and unstructured data.
Typical context:
- Salesrep
- Call center
- Internal HR procedures
A2. Information extraction and structured storage
A task in which a person is required to review unstructured data in the system (such as the scanned image of a document) and extract data and enter it as structured data.
Typical context:
- Backoffice document processing
A3. Prepare advice
A task in which a person reviews the data of a specific request, refines the data using functionality of the system (for instance certain calculations, risk assessments, price, etc) and prepares an advice ("yes, I propose to sell this customer a policy type X, with these conditions")
Typical context:
- Front office processing, sales, underwriting
A4. Decision
A task in which a specific person, based on her/his role needs to decide on something. The task will provide for the required information (case specific, possibly also other data), and the person will need to make a decision.
Typical context:
- Approvals
A5. Review based on 4-eyes principle/judgment
A task for which a person needs to review the correct execution of an earlier task (usual: prepare advice, decision) and make a statement of the correctness of the execution, leading to acceptance of the tasks output or rework.
A6. Inform
A task (or better: a notification) informing a certain stakeholder about critical facts about the execution of a specific process instance ("your request was accepted, your loan will be payed ...."
B. More complex situations
Many more patterns can be defined for process execution. This would support more complex knowledge work situations.
Think of:
B1. Collaborative event for sharing (plan, execute)
When more than 1 person is concurrently needed for a task, in this case: sharing of information
B2. Collaborative event for decision
When more than 1 person is concurrently needed for a task, in this case: deciding
B3. Add a dynamic task
B4. Add process participants
C. Controling & Steering (operational management)
Each process also has a "control" proces (the P, D and C parts of the Plan-Do-Check-Act cycle). For this process it's valuable to also have standard patterns...
C1. Warn
Warn a certain person if specific KPI's of a certain process instance are out of bounds.
C2. Escalate
If a certain task has not been done in a certain predefined time period, escalate it to someone else (automatically, or manually after a signal), higher up the organization
C3. Re-assign
If the workload of a person or team is too high, reassign one or more tasks to another person/team, but on same organizational level
Has these types of patterns already been defined somewhere? Used? Curious.
Friday, February 27, 2009
9 best practices for a solution & process architect
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
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
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.
Subscribe to:
Posts (Atom)