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 ;-))

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.

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.....

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.

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

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

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.

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.....

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"?