Showing posts with label Business Process Management. Show all posts
Showing posts with label Business Process Management. Show all posts

Monday, January 19, 2009

Process Catalogue Template

Few posts back I have published a process template. In continuation here is now Template for process catalogue. Use it as you wish. Also let me know any changes you require.

Get this doc from:

Documents

Sunday, January 18, 2009

Process Design

In most of the cases BPM deals with existing process where process designer picks up the existing process, optimize it as per the given mandate and finish off his/her work. Does this expose him/her to best practices of process design?

So the steps of process design are:

1. Concept: The Idea  what do you want to do?
2. Form: The Process  The process and the result of process(product)
3. Content: The Meaning  Does form satisfies the concept?

In a well designed process cater to following class of changes:

1. Change in State: Transition to one state to another during the course of execution of process. For example in Quote to Cash process change in state of Quote to Order.
2. Internal Changes: Changes in other processes which are within the realm of enterprise/s to whom process is catering. For example change in price of an item while a Quote to Cash process is in middle of execution. Price change is another process.
3. Environmental Changes: These changes are most of time beyond control of participating enterprises. For example change in tax structure while a Quote to Cash process is in middle of execution.

In any process Class 1 changes are accounted for because they form the normal exertion path of a process. Class 2 changes are also accounted in most of well designed process either as Class 1 changes or exceptions or via versioning path. Class 3 changes are not taken care in most of the process design due to resultant complexity and thin chances of occurrence of these changes. Class 3 changes can be accounted either as Exception, using versioning or catastrophe. If Class 3 changes are not accounted in process design this may result in chaos.

To design a process following models can be used by various players of game.

1. Value Stream Mapping: This mapping technique is widely used by Six Sigma and Lean professionals.
2. Event Modeling: This technique is widely used by Process Reengineering professionals.
3. Object Modeling: This technique is widely used by software professionals to model software as real life objects. For details you can refer to OOPS and OOAD literature.
4. Data Modeling: This is one more technique which is widely used by software professionals to design data intensive software.
5. Process Interaction Model: This is the models which caters to intra and inter process interaction. This model is borrowing concepts from Control engineering and ARIS methodology. This model is under development and soon I will release more details about it.

Business and System Analysts use Value Stream Mapping, Event and Process Interaction Models to define, refine and model a process. Technical Architects and Designers use Object Model, Data and Process Interaction Models to come out with technical specifications and actual design.

Process Design Good Practices

1. Design for present but do not loose sight from future.
2. Take account of Class 1 events and Class 2 events.
3. Manage Class 3 events keeping complexity in full view.
4. Balance between automation and manual tasks to keep process simple.
5. Strive for perfection but watch out for complexity, so balance.

Reference
1. http://en.wikipedia.org/wiki/Value_Stream_Mapping
2. http://www.isixsigma.com/dictionary/Value_Stream_Mapping-413.htm
3. http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design
4. http://www.ooad.org/
5. http://en.wikipedia.org/wiki/Data_flow_diagram
6. http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
7. http://en.wikipedia.org/wiki/Dataflow
8. http://en.wikipedia.org/wiki/Event_model
9. http://msdn.microsoft.com/en-us/library/ms533023(VS.85).aspx
10. http://www.actiontech.com/BPM/BIM.cfm
11. http://process-interaction-models.info/

Friday, January 9, 2009

Orchestration & Choreography

I generally encounter discussions and questions from various Architects, Designers and Business Persons discussing Orchestration and Choreography. It seems to me that these two topics hotly debated and misunderstood in the context of SOA. I also want to add my voice to the noise.

I understand Orchestration and Choreography from their dictionary meanings.

Orchestration:

1. Noun: To arrange something carefully, and sometimes unfairly, so as to achieve a desired result (Cambridge Advanced Learner's Dictionary)

2. Noun: The arrangement of a musical composition for performance by an orchestra; also: orchestral treatment of a musical composition (Merriam-webster’s online dictionary)

Orchestration Examples:

  1. In a concert conductor is giving instructions to players of violin, piano and other instruments to modulate pitch and volume to create music. Conductor is essentially passing instructions at the time of actual performance.
  2. A road crossing at which vehicles are following traffic rules in the presence of traffic police personnel. In real time depending upon traffic flow in different directions, traffic policeman takes action and ensures smooth flow of traffic.

In both the cases there is a central body which controls the performance of participants (performers and vehicles) for successful execution of a task

Choreography:

  1. Noun: the skill of combining movements into dances to be performed (Cambridge Advanced Learner's Dictionary)
  2. Noun: the composition and arrangement of dances especially for ballet (Merriam-webster’s online dictionary)

Choreography Examples:

  1. Sandeep Soparkar choreographed a dance sequence Britney Spears stage performance. In this scenario Sandeep has defined every step of dance well ahead of the performance so Britney and her stage co-performers are just enacting the same.
  2. A road crossing at which vehicles are following traffic rules without presence of traffic light or traffic police. These rules are defined in advance. Each vehicle is just following them for smoother and safer movement.

In both cases the participants (performers and vehicles) are following some predefined rules for successful staging of drama.

In SOA context, I will carry forward the argument and define the Orchestration and Choreography on same lines.

Orchestration:

  1. It is done at run time.
  2. There must be some central body, which controls the flow of the message and behavior of each participating service. This central body may be logical entity or set of rules/protocol.
Participating services are not aware of each other and even they are not aware of their involvement in orchestration.






Choreography:

1. It is done at design time
2. There is no logical entity to control the behavior of participating services but a set of rules/protocol exists which controls interaction of services.
3. Participating services are aware of each other and know when to execute their operations



So, how in real life Orchestration and Choreography played out in SOA universe.

In real life SOA implementation of services are done in the form of small business processes, which are state aware. In these processes services remain stateless but not the whole process. Individual services are not aware of their involvement in any process. This is the case for Orchestration. The central hub/rules/protocol decides how different services will interact. Most of the routing is content aware and depends upon result of execution of participating services.

Choreography can be thought of integration of small business processes, which are directly made up of services. The resultant grand business process might involve workflow. So in this grand process smaller constituent business process need not to expose all of its functionality beyond boundaries of itself. Small business processes have some private functionality and some of publicly exposed. Publicly exposed functionalities are exploited to integrate them and reach at grand business process where no central hub is defined so no run time decision. All decisions have been made at design time.

Monday, December 29, 2008

Process Template

Recently I have developed a document which will be helpful in documenting enterprise process. This document is in MS WORD format. The document is structured in technology independent way. I will certainly welcome any suggestion and changes with respect to technology and platform.

I hope this document will be helpful tool to lot of us to sail through EPM/BPM universe.

The document can be downloaded from Scribd.com.

Documents

Wednesday, December 10, 2008

Enterprise Process Management

Enterprise Process Management should be considered as superset of Business Process Management. In current scenario whenever we talk about BPM we always think of business organization. But in real world every organization is not business organization. There are various organizations which have interests beyond business e.g. government organizations, non-government organizations (NGO), philanthropic organizations, etc. So the term BPM is not sufficient to cater their needs. I propose Enterprise Process Management (EPM) because Enterprise covers not only business organization but also lot of other non-business organizations.

Keeping EPM into sight, what is process?

A process is a coordinated thread of sequential and parallel activities needed to deliver value to stakeholders.

So what is EPM?

Enterprise Process Management is assuming controlling position on processes from inception/idea to its delivery, from very first activity to last, and analysis of each and every activity for continuous and step improvement.

From definition it is very clear that EPM can be visualized from three view points:

  1. Inventive viewpoint
  2. Execution viewpoint
  3. Improvement viewpoint





1. Inventive viewpoint: This viewpoint is affected by strategic and tactical decisions of any enterprise. Strategic and tactical success of any enterprise demands effective and efficient processes with continuous improvement build in. As environment is dynamic and most of the time beyond the control of enterprise, processes must be adaptive in nature and if possible self-aware.



2. Execution viewpoint: This viewpoint focuses on execution part of processes’ lifecycle. Once process is released in any enterprise for execution purposes this viewpoint takes over. In any successful process this viewpoint has longest duration with numerous small changes but insignificant number of step changes.



3. Improvement viewpoint: In this viewpoint focus is on improvement related aspects of process. This viewpoint gets feed from execution and gives to inventive viewpoint. The improvements may be minor chunks (part of continuous improvement) or quantum leap.



Classification of Enterprises Processes

On the basis of complexity, enterprise processes can be divided into three categories:

1. Material Processes
2. Information Processes
3. Human Interaction Processes


  1. Material Processes: MPs are primarily concerned to “THINGS”. The purpose of these processes is transforming the material and consume resources. These processes rely heavily on Industrial engineering concepts. These processes are found in primarily in manufacturing, assembly, process industrial environment. Generally speaking these processes are so matured over time period across the industries that they more or less resemble procedure or long running procedures. This means the input and output of these processes can be defined objectively.

  1. Information Processes: IPs are primarily concerned to “DATA”. These processes transform data into information or information into more abstract information. These processes rely on Computer science, Software engineering and Information science concepts. These processes are prevalent in service and non-service industrial environment. Again due to tremendous progress in computer science, information science and software engineering these processes resemble to procedures.

  1. Human Interaction Processes: HIPs are primarily focus on human cognitive aspects. HIPs are articulation of subjective issues and getting agreement among various stakeholders. HIPs are based on structure of human communication and coordination, which are prevalent in natural languages and cultures. HIPs are highly affected by cognitive abilities of participating actors and surrounding environment. Most of the time HIPs are highly subjective so their automation is a big challenge.

In real life settings, most of the enterprise processes are combination of MP, IP and HIP.

For simplicity let us consider a simple process: Opening a checking bank account by a new customer.

So to open checking bank account, customer has to submit a form to branch where he wishes to have account. The account opening form also need some supporting document like identity card of the prospect along with letter from an existing account holder. Upon submission of completed form and supporting document, a clerk at branch verifies the documents at preliminary level and sends to regional office for detailed verification. If verification result is OK, account is opened, base branch & customer are informed and checkbook, ATM card are dispatched to customer. If verification result is NOT OK, base branch & customer are informed.

In the first glance the process seems to be well structured and simple enough for automation. This process seems to fall in Material and Information Process category. So automation looks easy and within reach. Now let Human aspect enter into the process.

Mr. Clerk who accepts documents from prospective account holders has friendship with Mr. Tony. One fine day Mr. Tony reaches to branch where Mr. Clerk is stationed and submit Account opening form. Mr. Tony does not was not carrying supporting documents, so he talks to Mr. Clerk and makes promise to submit supporting documents on next Monday and asks Mr. Clerk to hold his docs till then. So human relations start tearing a well-structured process.

Since human interactions and communication is unstructured and asymmetric, so automation of such aspects is very difficult.