Global process unifying and standardization methodology
With the advent of globalization and interdependencies brought about by globalization, many organizations are moving towards one global organization—transforming from regional processes to global processes. It is critical for organizations to have a process framework as an enabler in this journey. While unifying the processes and making them consistent across regions, there are various opportunities to leverage best practices. This paper focuses on defining the methodology for such a process transformation.
This methodology covers the business process transformation and standardization in a multi-regional scenario with or without any target IT system or ERP package. This methodology does not intend to cover IT system implementation methodology, program management methodology, change management methodology, or any guidance on process modeling tools.
Defining Process Framework
Process framework definition is required to help change mindset from a departmental or silo view to an end-to-end process view. It is also needed to define clear ownership for processes and transaction flows, both at the regional and global levels.
Defining Process and Process Levels
It is important to clearly call out what a “process” is. A clear definition of process helps in building common understanding across all the stakeholders and also helps teams work cohesively.
Exhibit 1: Business Process Illustration
Defining Process Levels
As we build process framework, a clear definition of process levels is required. Process framework is typically built in top-down mode—defining top-level process and owners and moving to the next levels. Process levels can be defined as L0 (Level Zero) to L4 (Level Four).
Exhibit 2: Defining Process Levels
- L0—Enterprise Process Groupings at the highest levels are called L0. They can be Core or Supporting Processes that are built at top level. Examples: Customer Development, Supplier Development, Plan Supply and Demand, Fulfill, Procure, Pay and Collect. Most importantly, a global level executive ownership of process needs to be defined at the L0 level. The owners can be called L0 Process Owners and they are global owners who help in giving strategic direction, executive decision making, and breaking ties, providing guidance to the team, and monitoring and controlling the progress. Depending upon business realities and needs, global level L0 process owners may have regional counterparts and typically are required to have representatives acting on their behalf on a day-to-day basis. Global Level Process Ownership is a critical step used to create mindset shift and build ability to own and view a process as “global.”
- L1 process is an end to end transaction flow. It includes the definitions of start point, end point, and scope/boundary of transactional flow. L1 flows are represented in visual flow diagrams. Global level to-be processes are defined, and business experts/subject matter experts (SMEs) are identified at this level. To provide the interdependencies view, it may be opted to provide an end to end transaction flow view across the L0 processes as illustrated below.
Exhibit 3: L0 Process Framework and Mapping of L1 Transaction Flows
- L2 is a collation of detailed role-wise activities required to complete a specific L1 Transaction Flow. Process at L2 can be represented by a box in a visual diagram. L2 boxes needs to be placed with clear sequencing, handshakes, decision points etc, to form a transaction flow. An L2 box may include multiple activities or steps that can be logically grouped and represented as a L2 box in a flow diagram.
- L3 are detailed business requirements, business logic, and business rules around each of the activities in L2. For each L2 process box, L3 requirements can be represented by structured “ability to…” statements. For example, with in receiving customer orders (L2): “Ability to receive customer orders by EDI/Fax/E-Mail.” These L3 requirements are detailed out to the lowest level for clarity while collecting requirements.
- L4 are the exceptions to the general business rules and may apply for 0–1% transactions.
Note: Defining Process Framework at the L0 and L1 levels requires significant amount of current business understanding, brainstorming, and stakeholder management. It is recommended to employ professional services of domain experts to drive towards industry standard process framework. Also, building process framework is normally an iterative exercise and needs strong executive commitment and involvement. This requires pre-work, organization wide communication, and stakeholder management before starting the “as-is” stage. It is recommended that the identified business leaders for building the framework continue through the lifecycle of the program.
Defining Roles and Responsibilities
Defining clear ownership and expectations from different roles, both at the regional and global levels, is the key to the success of achieving to-be design objective.
Different level of ownerships:
- L0 Process Owner—A stakeholder representing executive management ownership at the top-level process as explained previously.
- L0 Backup—Senior business leaders with L0 process ownership, who would be working on day to day basis for future process definition, providing guidance to the team and acting on behalf of L0 Process owners.
- Global Transaction Flow Owners (GTFO)—A business expert taking ownership of a given transaction flow at a global level. This person works as a facilitator across regions, is authorized to make decisions at the global level, is in synch with L0 backup on the key decisions, and receives help from L0 backup to arrive at key decisions and during tie breaker situations.
- Regional Transaction Flow Owner—Business experts representing their respective regions in the process of building a global model. Responsible for highlighting regional best practices or differentiators, ensuring alignment of regional processes to global model, and ensuring feasibility of global model for the region in question, regional stakeholder management, and process level communication in respective regions.
- Subject Matter Experts—Business experts for the subject who may be engaged full time or part time.
All the roles are part of as-is and to-be design teams. Regional Transaction Flow owners and SMEs are responsible for respective as-is process signoff and the global to-be design signoff.
Capturing As-Is Process Model
An important start to achieving an optimal to-be model, is to capture required as-is process details with similar level of details across regions, and the use of consistent terminology. To enable consistent details in as-is stage, the following steps can be taken:
Building Reference Models
The purpose of building reference models for each transaction flow is to:
- Provide a head start for the as-is workshop with a ready reference model,
- Give pointers and guidance to ensure greater coverage of business requirements and fewer misses,
- Ensure consistent level of details in defining transaction flow—which is extremely useful when moving to the to-be stage, and
- Ensure consistent terminology usage.
Note: It is important to have a consistent numbering for identification of each L2 box and eventually the L3/L4 requirements. For example, numbering for a flow diagram could indicate <TF><L2 Box Number>. In all cases, each L2 box and requirements should be uniquely identified, as it helps in consolidation activities.
As-Is Process Questionnaire and Checklists
The as-is questionnaire is specific to a flow and is targeted to prompt the SMEs/workshop participants to think through the process and provide complete business requirements so as to help ensure coverage of all steps in a process with the required details.
In order to have maximum learning from the as-is workshops, the following points may be considered for workshop planning:
- Providing for pre-work, workshop, post-work and signoff/closure;
- Planning workshops of similar flows sequentially across regions helps in taking the output of one region to the next, taking learning and helping in better consistency of output; and
- Logically grouping the transaction flows to create business functions/cluster—which can be represented by the same group of individuals. This provides a good flexibility in planning and better continuity across similar flows.
Pre-workshop activities include preparation and planning with an intention, and activities to accelerate as-is process workshops.
Pre-workshop activities include the following:
- Understanding of the process framework and inventory of flows (transaction flows with description, start and end points),
- Building of reference models,
- Building checklist questionnaire for the transaction flow,
- Finalizing output templates,
- Validating reference models with key business owner(s),
- Validating checklist questionnaire for the transaction flow with key business owner(s),
- Circulating and gathering feedback on the reference model and questionnaire,
- Adjusting the reference models,
- Validating the reference models with GTFOs,
- Identifying potential pain areas for focus in workshop, and
- Building the workshop plan and guidelines.
As-is workshops are usually face-to-face activities with the objective to come to a conclusion on as-is business process flows for the region with the required level of detail and consistency.
The workshop can be structured to include following key steps:
- Step 1: Introduce Reference Model—The reference models provide a quick start and help build consistency in the flows across regions. In step 1, an introduction and walk through of the reference model helps to provide the explanation of the entire process flow, how the business process is represented, and an explanation of each box in the reference model. This helps to set the common understanding of the reference model beforehand.
- Step 2: Develop As Is Process Flow—After introduction of the reference model, the team can suggest or make needed changes to the reference model to correctly represent the business flows in the flow diagram by adding, modifying, and/or deleting actions on the reference model. The facilitator must ensure that in the process, the level of details for L2 is consistent with the guidance for the process level, otherwise, there would be more difficulties in building to-be models.
- Step 3: Document As Is Requirement for Each Process—The team documents the detailed L3 business requirements and L4 exceptions against each L2 process in a transaction flow. It is recommended that the requirement capture statements should be consistent, for example, in calling each requirement in the form of “Ability to.” (i.e., Ability to receive orders from e-mail, Ability to perform xyz check, etc.). With the use of a process modeling tool, the requirements can be captured online for the given to-be flow.
While it is recommended that the L2 level flow diagram is kept more consistent across the regions and at a granular level, the L3 and L4 requirements should be captured to the last level of details.
- Step 4: Complete a Value-Add Analysis—The value-add analysis should identify the value of any step that exists in the process. To do this exercise, the team needs to have the right mindset to critically look at each step in the process and indicate the value addition from the following:
(a) CVA—Customer Value Add: Value addition of a step from the customer point of view, which includes the external stakeholders for the process—both customers and suppliers (e.g., ability to inform customer on the status of the quote, ability to provide the estimated turnaround time for the quote, etc.).
(b) PVA—Process Value Add: Typically a step or process needed for the internal controls, measure, and monitoring. This may not be of great importance to the customer, but it may be mandatory from internal controls/monitoring point of view (e.g., ability to perform credit check, ability to perform margin checks, etc.).
(c) NVA—Non-Value Add: These are the steps that exist in the process, which do not add any significant value to the customer or to the internal controls (e.g., ability to print the output document that may be filed). During the to-be stage, NVA should be looked at for elimination. PVA and CVA should be looked at for making them easy, less cumbersome or more effective, and automated. CVA especially should be evaluated to make them more effective.
- Step 5: Document Time Measures at Each Process Level—Time measure is an indicative time for each process stage at the L2 level. The time measure helps to identify the most time-consuming steps, when looked at in relation to the value addition. The areas with high time measure should be critically looked at for making them more effective/efficient/automated.
- Step 6: Document Pain Points—Pain points are the existing challenges in the process, as seen by the business team. The pain points, when eliminated, should result in some improvement. Pain points capture may be free flow in the workshop, and teams can share the feedback on the key issues, difficulties, and limitations that may be captured during the as-is stage with good understanding, but limited validation.
- Step 7: Identify Quick Wins/Potential Improvement Opportunities—Quick wins and potential improvement opportunities are the areas which, when addressed, help bring additional benefits quickly. In many cases, the pain points are addressed, however at times, the quick wins help to identify the key items that may be expedited to reap additional benefits, without any dependencies with the program activities.
Exhibit 4: Typical As-Is Workshop Activity Details
Post Workshop Activities
Though most of the requirements get clarified during the workshop, there could be action items, open items for validation, or additional details that may need to be captured. These action items and validation of the as-is details with the larger business community constitute post-workshop activities.
Signoff is required as a mark of completion of the as-is requirements capture milestone. It is recommended that appropriate regional stakeholder management should be done in post workshop activities before signoff. Also, signoff should typically not include any open items, barring valid exceptions.
Building To-Be Process Model
Building the to-be model from the disparate regional as-is flows could be a daunting task. However, the steps taken as indicated in the as-is stage, for example, common level of process definition and similar level of L2 capture with the help of reference model, consistency of phrase in L3/L4 requirements capture, a glossary of terms, and consistent nomenclature of L2, L3, L4, etc., help facilitate build up of the to be model.
The to-be stage may be divided into the following:
Pre-Workshop and Straw Man Creation Activities
Straw man is a draft process flow used to facilitate requirements creation that is taken forward for the validation in the to-be workshop. The straw man is normally validated in a smaller group before to-be workshops. Other pre-workshop activities include preparation/finalization of plans, templates, facilitators' guide for the workshop, and implementation of any quick wins in parallel, etc.
As-is Process Collation, Consolidation and Classification and Straw Man Preparation—Straw man preparation starts with the L2, L3, and L4 process, requirements consolidation, and classification. Collation is to capture the L2 and L3/L4 in a common tool (this document refers to MS Excel as a tool) with appropriate numbering and needed details as appearing in to-be spreadsheet template. Each business process and requirement is listed in the spreadsheet side by side for the regions. Once the collation is complete, the classification and consolidation can be done. The L2/L3/L4 processes are then looked for applicability across regions marking (classifying) them as “Common (C)”, “Partly Common (PC)” or “Different (D).” It is important to note that scoring may be used to bring out better value from the process. Here, L2/L3/L4 processes may be marked for relevance against key parameters to come up with the overall score and putting in the cut-off score for dropping some of the requirements. Scoring would typically be based on parameters like value add, business criticality, industry practice compliance, target system fitment etc. The L2/L3/L4 requirements that are below a minimum, defined cutoff may be targeted to be dropped.
Exhibit 5: Classification
The analysis described previously helps first level consolidation of L2/L3/L4 business requirements and identifies L2/L3/L4 that are recommended for change/drop from the as-is world.
Using this information and the base as-is reference model diagrams, a to-be reference straw man is created. The straw man is needed as a good starting point for to-be workshop. Once the straw man is created, it is very important to get the same validated in a restricted group for first level feedback and adjustments before the workshops.
Exhibit 6: To-Be Straw man Creation
To-be Workshops may have following steps:
• Introduction of overall workshop plan,
• Setting goals, roles, and workshop execution process,
• Introduction of to-be straw man,
• Discussion and finalization of to-be flow and requirements at a global level,
• Identification of regional differentiators that may not be taken in global model and are marked to be taken only for regional process,
• Identification of the processes/requirements that would change due to re-design, and
• Identification of the open items, issues for resolution, and post-workshop items.
To-Be Workshop Goals and Process
- To design to-be State Global process diagram (L2 level) for Transaction flows, Global L3 requirements (including Operational Reports), Regional L2 and L3s, High Level Gaps with reference system, Solution Options, Business Metrics Catalog;
- To finalize on key changes to the process; and
- To finalize on open issues and next steps.
- Process—Conduct workshop to achieve workshop objectives using the following documents:
- Introduction presentation (PowerPoint),
- To-be straw man TF at L2 process level, and
- Consolidation and normalization worksheets, including open issues (Excel).
- Global transaction flow owner, SMEs, Consultants, and IT Team (need-based)
Measuring the Success
It is important to measure “globalization” to keep a tab of the percentage of common process achieved and to have the management control on this overall parameter result. The globalization can be measured by rolling up L3 level common requirements that are included in the to-be model vis-à-vis total requirements. In addition, as a measure of process improvement, key financial and process parameters should be measured before and after implementation.
Post-Workshops Activities and Signoff
To-be model finalization could mean significant stakeholder management, apart from action items closure, open items closure, additional details that may need to be captured. All of these activities would be carried out as a part of post-workshop activities.
Key considerations include the following:
• Leveraging best practices across various regions and from industry is the key to achieving an optimal, unified process.
• The process steps should be discussed in depth to avoid any major changes to the flow design down the line. The cost of implementing changes increases as we move forward to different phases within a program and as the implementation into systems begins.
• Choose the right set of people to debate on the processes in different regions and come up with a unified process with minimal differences across regions (some differences are unavoidable due to legal requirements or due to local competitive advantage).
• It is easy to get bogged down and have discussion for hours without coming to a conclusion, given the process and cultural differences between various regions and team members. It is important to have a focus, set ground rules for the meeting, and determine a process owner who to drive the workshop.
• If this process unification is coupled with an ERP transformation, it is important to fine tune the process and process steps based on the product fitment, and take advantage of standard processes available out of the box for an ERP system.
Many thanks to Saurabh Agarwal (Infosys Consulting), Santosh Iyer (Infosys Consulting), Sharad Elhence (Infosys Consulting), and Ramakrishnan Krishnamurthi (Infosys Technologies Ltd) for their contributions.
Paul Harmon (January 2003). An introduction to SCOR methodology. A white paper from Supply Chain Council Influx® tool of Infosys Technologies Limited.
© 2010, Deepak Mandot and Hemal Shah
Originally published as a part of 2010 PMI Global Congress Proceedings – Melbourne, Australia