A Global Template Solution is a packaged solution catering to these harmonized globalized processes with the flexibility to absorb local variations. It is recommended that a Global Template model follow an 80-20 approach where in the global standard processes constitute around 80% of the template while the local/custom processes around 20%. I have worked on couple of such programmes and found that some of the key drivers behind such global initiatives are cost leadership, shared services, global best practices and process consistency.
Such programmes generally start with an exhaustive preparation phase. Key decisions on programme approach, governance, team formation and logistics etc are taken during this phase. Programme approach is based on factors such as time to market, coverage (business areas, geographies), availability of resources, availability of required documentations etc. Considering that these are major business programmes having substantial impact on wider business community, a Global Design Council is established to protect the integrity of the global template during development phase and during multiple roll-outs. This council generally consists of key business leaders and process owners. Team formation, another key activity during this phase, involves identification of process owners and their team, which involves representatives from all key accounts, identification of appropriate service provider, logistics etc. Once the teams are (both client and service provider) identified and logistics are planned the next step is to conduct process design workshops. Process Owners, Business Leaders, Region Representatives, Process Consultants and Functional Consultants are the key participants in these workshops. This team defines the way the organization will operate for next couple of years. Hence such programmes require substantial investment during the initial phases.Process Designs evolve in phases wherein the process foundation is designed followed by profiling the processes and defining the activities. At this point the local/regional requirements take a back seat and the processes are designed keeping in mind the common requirements, common pain areas and global best practices. The functional requirements are extracted from the baseline processes and developed by following a suitable SDLC model. The outcome becomes the 'core component of the Global Template model'.
Once the core component of Global Template is developed, it is taken to the local business to educate them on the standard template, understand and absorb their critical local requirements and constraints. It starts with grouping and prioritization of regions/accounts/sites based on which the Global Template will be deployed. Grouping can be based on parameters like - Region / Country, Business Group, Size, Complexity, Current Package Version, Local Compliances, Cost to Serve, New / Current Region, Readiness etc. Once this view is achieved, the deployment team will better understand the relative size of the deployment candidate and their synergies and common attributes. This will help in estimating the deployment efforts and the overall deployment approach.Deployment Cycle typically begins with Study phase workshops where the Core Team (Process Owners, Local representatives, Functional Consultants, Process Consultants) educates the Local team on the Global Template solution and get their buy-in. In the process there is detailed discussion on local requirements, local constraints and conflation in Global Template. The key objective is to get the optimum benefit from the consistent and common processes of the Global Template. Only critical and unavoidable requirements/constraints should be addressed and absorbed within the Global Template. During this time the Global Design Council plays an important role to govern and if required repress the local sentiments and maintain the integrity of the Global Template. The local requirements are further analyzed to understand any conflicts with the existing global or local design and accordingly either approved or rejected. The approved local requirements are developed and merged within the Global Template solution and they become the 'local component of the Global Template model'.