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

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

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?

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

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!

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!

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

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

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.