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.....
Thursday, January 29, 2009
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.....
Subscribe to:
Posts (Atom)