Monday, August 29, 2011

Paradigm Shift To Goal-Orientation

If we look back twenty or thirty years, we can see that processes were not as common as they are today. People did similar things as they do today, but interactions within organizations were pretty chaotic. One day things could go well, and another day they may not. To keep running, organizations relied a lot on specific individuals, who knew what they were doing and who could lead others. Automation just reflected the realities in the organizational management style. It didn’t try to formalize interactions. It just helped people to perform pieces of their individual work.

In those days the sustainability of management was questionable. Then automatic processes arrived and offered a few things that decision makers could not refuse:

  • They put fuzzy interactions under control
  • They reinforced important behaviors
  • They made management less dependent on individual art and made workers easily replaceable
  • They made functions reusable and less dependent on a specific context, and
  • They made management more predictable and sustainable over time

With these obvious benefits, organizations started introducing and reinforcing processes. Management automation then responded with the shift to process-orientation automation, which used SOA architectures and technologies along with Business-Process Management.

Of course, all of that was a positive change from what it was before. Today, however, we can often hear the complaint that we have too many processes, and we immediately visualize suppressed people acting like screws in a bigger machine. They do their steps, but have fuzzy ideas as to why they are needed. Known actions often become over complicated and move far out of reach due to all the dances and maneuvers that have to happen. Then, if somebody attempts to cut corners to do things differently, he or she is immediately bitten by the manager’s stick. Also, in this picture, managers are not happy themselves. They are constrained almost as much as their subordinates, and they can’t use their knowledge, experience, and power to make things better. Processes starts popping up to organize other processes and eventually consume all in their way. Does this look familiar to you?

It is clear today that processes have problems.They are inflexible and cannot quickly respond to changing situations; though designed to be universal, they are inefficient due to their many steps and cannot be applied to unique situations; they have problems dealing with other conflicting processes; and, most importantly, many processes are not scalable.

This last issue is a huge problem with processes. A small number of processes is relatively easy to be understood by the average human mind. But, when the number and complexity of processes grow things quickly get out of control. All the processes starts to twist and wrap each other, and more processes are created to govern other processes. Even worse, having all of these processes sometimes create a false feeling that everything is under control--that having these processes keep everything running smoothly when, in fact, they are losing people within their twists and gaps. Thus, any attempt to create comprehensive automation using just processes across an entire organization is set for failure. In the best case possible, it will become a Frankenstein monster that consumes large amounts of money and gives few results.

Some people have already begun to see these problems. They say things like, “this must be made simpler,” “employees have to be empowered to make better decisions,” that “success has to be measured by results, not by having a large amount of actions,” and so on. Agile and lean management practices have started to undermine rigid processes. Management is becoming more concerned about what and why and less with how. We can conclude then that a paradigm shift has begun. Right now, however, it’s happening mostly at an organizational management level and is only starting to affect how automation is being done.

Together with Maxim Privalov, I analyzed trends and made a prediction that the next logical step in management automation will be toward goals. The research we performed indicated that goal-oriented management automation will be better able to address the current problems and future needs of management automation because of the following facts:

  • Goals are easier to define than processes
  • Goals are more flexible and can be achieved through multiple methods
  • Unlike processes, goals are more resistant to situational changes and are able to adapt
  • Goal interdependencies are easier to discover and manage
  • Goals are more efficient since they represent and work towards an end result, and
  • Goals naturally scale by breaking it into sub-goals

It is important to note, though, that the transition from the process-oriented paradigm to a goal-oriented paradigm will be a slow evolution. Companies have already spent billions of dollars in automation. They will not want to lose their investments. Thus, every change will most likely happen gradually over a period of time in order to not cause major disruptions. If we look at the past paradigms, we can see how the transitions happened before:

  • Centralized Paradigm
    • Primary focus: critical organization-wide management functions
    • Transition: none - it arrived with the arrival of computers
  • Function-oriented Paradigm
    • Primary focus: individual management functions
    • Transition: revolutionary - new systems were built from scratch while old systems were kept in service
  • Process-oriented Paradigm
    • Primary focus: business processes to formalize inter-individual and group-to-group interactions
    • Transition: evolutionary - previously developed individual functions were exposed via business services and orchestrated into business processes

The new paradigm will continue that pattern:

  • Goal-oriented Paradigm
    • Primary focus on: business goals that drive interactions or functions
    • Transition: evolutionary - previously developed business processes will remain as prescribed patterns to achieve business goals

With this next paradigm shift towards goal-orientation, comprehensive management automation will eliminate the fuzzy and confusing ways of the process-oriented paradigm.

C2/GOMA is the way to do this. Keep reading!


  1. Given that the majority of things now are process oriented, how does this framework fit into C2/GOMA or will everything have to be re done? It appears to me that C2/GOMA has no restrictions on how you achieve a goal, whether that be by a process or function. Since processes have many problems, as you stated in the blog, how do these things affect C2/GOMA if the method to achieve goals is by using processes?

    1. In my later posts I touched that topic. Process is defined as a sequence of activities. In GOMA activity is an elementary goal which is required to achieve some other higher-level goal(s). If we look at processes from that perspective we may define a process as a prescribed breakdown of goal (or set of goals) into sub-goals (activities) and setting timing dependencies (sequences) between them. Other terms that I use to call a process is "execution pattern" or "goal reaching pattern".