Business is changing, it is changing

We live in a growth economy. Shareholders and investors expect companies to advance their business. Regardless of these expectations, most companies simply want to grow. This means more: more presence and more products and/or services that companies offer. As a result, companies, on the one hand, go beyond their core, primary activities and, on the other hand, enter international, global markets. And there are acquisitions – another alternative for growth. In every scenario, over time, an organization becomes a number of local branches around its original headquarters. They relate to the headquarters organizationally, but the scope and shape of local business processes may differ. There may be more discrepancies on IT level, e.g. the scope of IT solutions, including ERP systems (different suppliers, different versions), not to mention the integration with satellite systems, supporting a specific part of local business. For such organizations, the best solution may be to develop and then implement the template: reference solutions for local organizations.

Another case of transformation may be, when a company realizes that the current tools are insufficient, ineffective, too complex, out of scale or obsolete, so it needs a new, simpler solution, better suited to the scope of the business.

Two worlds – one goal

Yet, every business transformation can be considered from two perspectives. On the one hand, there is a business organization that triggers the need for change, and on the other hand, there is IT team that facilitates their implementation. Both aim at simplification of managing business, typically by introducing or aligning standards, unifying business processes in a way that supports local subsidiaries, but also allows HQ to see the group of companies as one organization and not a set of individual businesses.

None of these two drivers will cause any successful changes on its own. It is the synergy of both worlds what is needed. Business is a flywheel for change, while IT provides measures to meet business needs. It is an important issue, because one often thinks about changes or innovations in the IT category, while the impact, benefits and subject that actually needs changes is business.

Designing the solution

The answer to the ubiquitous change is continuous development of the company and introduction of ERP solutions. This is particularly valuable for organizations that operate globally, but also expand in a more local sense – e.g. they open new branches, set up new companies or open new production lines. To get that growth under control, one needs a solid foundation, which will also provide basis for further development. Such a foundation in the case of ERP systems is called a common template. Yet, to design a valid template, one first needs to determine what its high and low level architecture should be.

All for One Poland recommends a four-layer solution.

First, common tier split into:

  • Common Core Template, which contains a set of standardized processes supporting the key, most standard, basic part of the business. It is easily replicated to new subsidiaries, because each company needs standardized financial, controlling or logistic functions.
  • Common Extended Template, which includes standard processes for larger, more complex or specific organizations. They may still be replicable between companies or plants within a group, but will not be applicable for every organization within the group.

The second, local tier can be classified into

  • Local legal requirements – specific local legal requirements. It is typically a must-have element of template solution implementation in a new country or specific, regulated line of business. Each country has its own specific business requirements and these have to be addressed in the central system.
  • Local business requirements – these are strictly business requirements (not imposed by the legislator), however, due to the specific nature of business they may be of key importance for the success or failure of a given organization.

The Common Core Template is usually considered as unalterable. Other elements should be implemented on the basis of a decision and a strong business case. The organization should define which functions it needs for business development and how much it wants to adapt to local needs.

What is “a template”?

The first level of template definition is its structure considered from the perspective of the level of standardization/flexibility and the level of business requirements supported by common IT solution. The second, often taken for granted and hence underestimated, level is actual “contents” of the template. The most basic element of a corporate template is a set of standard, integrated working business processes accompanied by the system customizing/development and functional and technical documentation.

The next element is a set of test scenarios, which will be used to validate that the process works properly, i.e. they present the steps to be taken so that the process can be completed end-to-end. These two are closely related to user manuals guiding process users through the steps of their daily work and highlighting more unusual or problematic situations Industrialized templates often also include readyto-use tools, accelerators, simplifying project delivery, i.e. project documentation templates, data migration templates, data loading programs, tools for reporting project progress, user knowledge base explaining how the system works, what the typical problems are and how to solve them. All these elements can be used both in the implementation of the template during the rollout project and for operational use by the organization after the rollout.

The template may also include policies, procedures and standards that describe how to create and change customizing settings, how to develop custom code or interfaces, how data should maintained or what the naming conventions for specific objects should be. The company-specific implementation methodology itself may also be a part of template.

Solution governance

Yet the template does not exist in the business vacuum. Business changes, new requirements appear, existing requirements change. These changes need to be managed in a controlled manner by specific governance policies. The governance is a set of rules and principles of guiding maintenance and changes to the template solution. In particular template governance and controls apply to:

  • Template governance: focused on maintaining consistency and quality of the template. It embraces documents, procedures, rules, standards and tools driving solution compliance and alignment with company-wide regulations. Template governance typically decides upon change and release management procedures, defined organizational framework (organizational roles and RASCI matrix) and ensures management support.
  • Project governance: focused on controlling and maintaining quality of the template rollout project delivery. Managed by project management team, by means of e.g. change management, communications management or risk management. Includes project-related roles and RASCI matrix, independent from the organizational RASCI for template governance. Project governance always depends on and is impacted by template governance.
  • IT governance: focused on IT and infrastructure maintenance and control. Managed by IT organization. Includes infrastructure and security management as well as performance management. IT governance drives standardization of IT services, e.g. hardware standardization (e.g. user workstations, printers, warehouse terminals), service delivery model (on-premise, hosting, SaaS) or location (e.g. HQ, local).

Rollout goal

When a template is already developed for a given organization, a moment comes when it is necessary to implement this template. That means delivering a rollout project. The first thing one should focus on are the goals of this project. Understanding of these goals is key success factor and facilitator of rollout delivery. When the organization implementing this solution understands why the project is done, it will be easier to take and accept the decisions made. For example, if the main goal is standardization, it will be easier to understand why local division needs to give up certain solutions that had been used in the company before. It will be easier to understand that new solution may be different (perhaps “worse”), but on a group level it will be standardized. That way all employees execute certain activities in the same way. Sacrifice of the locality and specificity of the company is made for the sake of work unification within the whole group.

Alternatively, if the main goal is efficiency and cost reduction, then e.g. resigning from a local server room and moving systems to a common IT service centre or resigning from certain local solutions and switching to alternative solutions sounds like much more justified business decision.

Project scale

When the rollout goals are already defined, it is necessary to decide what will be done within the framework of a given project. Rollout projects can be very diverse. From simple projects, such as a new plant in the same country, through opening branches in other countries, to more complex solutions when a company wants to implement common solution in several countries in one go.

The latter case often grows into a program of several rollouts spread over a longer period of time. Also it is not unusual for companies to decide to update their IT systems during the rollout program. With very large organizations there may even be a portfolio of rollout programmes covering different countries or regions within one organization.

Solution implementation method

In the case of standard, clearly defined rollouts, the most frequently used methodology is the traditional SAP ASAP-based roadmap. It is so-called waterfall delivery model – with gathering and specifying the requirements, their implementation, validation and operational execution. The second approach, not so common among rollout projects, is the agile SAP Activate methodology. The flexibility it provides brings also the risk of uncertainty, very much unwanted in rollouts. There is also a third option, when the customer develops his own implementation methodology and wants to use it in this project. Reliable SAP implementation partner should be able to fi t into any of these scenarios.

Assessment of organizational readiness

Now, prior to the delivery start one needs to asses readiness of the organization to carry out the project.

In order to ensure project success the following aspects need to be taken into account:

  • organizational maturity, including who initiates the project in the company – IT due to the drive for new systems, as the old systems do not meet IT the requirements, or is it the business who wants to change the solutions to operate smoothly within the group.
  • processes in the company – to what extent the local unit implementing SAP systems is aligned with group processes. It is very often the case that vast part of processes is in line with company standards, but local deviations e.g. in logistics may present some risk for the implementation.

The final element is the language – when planning the communication, one should consider not only the language that will be used in the project (what language is used by local subsidiary, corporate team, implementation partners), the language in which the project documentation is written but also the language of the solution itself, due to exposure of not only key but also end users.

Scope definition

Eventually, when defining a rollout strategy, it is necessary to precisely specify the way in which the scope of the implementation is managed. In practice, one can think about two extremes – a rigorous and rigid approach with sticking to the template, in which local solutions do not interfere with the template. From the point of view of the headquarters it can be well perceived, but from the perspective of the local unit it can mean less support for their business. In the second – fully flexible approach – template serves only as the basis, the point of reference, but company allows to implement everything that is needed locally, to ensure that all requirements are met for the business to be well run and profitable. From the point of view of central maintenance, the later approach is more complex, because a solution is potentially too far off the common model.

Most rational approach is to stick to the template as much as possible, yet with critical-minded openness to local requirements that are necessary for business operations.

Another issue to be taken into account when defining the scope is organisational or legal complexity. Organisational complexity means e.g. the number legal entities that will probably end up as SAP company codes. Project plan will look differently for one company implementation and differently for e.g. six entities. It is necessary to understand what the company’s organisational structure is based on. Speaking about the organizational structure, one cannot ignore the production plants – at the planning stage one should already decide if or how to integrate them into the central solution and how to manage the risk of that integration.

Data – business fuels

No system will work properly if it does not have valid and correct data. When considering rollout implementation one needs to pay attention especially to:

  • data scope – determining which data are necessary in SAP and how it will be gathered and migrated. It is important to describe it at the most detailed level, including estimated volumes and sources of data,
  • data ownership – a clear identification of persons responsible for the preparation and maintenance of the data,
  • data model – global and/or local standard model describing business (i.e. impact) and technical (i.e. tables, fields) details of the data, as well as conventions used,
  • data migration strategy – means of transferring data to the new system (automatic, semiautomatic, manual), establishing rules related to migration (gathering, cleaning, mapping, uploading, validating, customizing) for each data object in terms of migration,
  • data migration schedule – the timing of data migration activities, aligned with other activities of the project, including migration sequences and potential rework,
  • data migration targets – SAP systems and clients that will be used during data migration activities.

Roles in the rollout project

The most important activity when designing a rollout strategy is to identify and then assign roles and responsibilities. Typically there are three groups of people: the company (HQ) initiating and managing the rollout, the local company to which the rollout is made and the implementation partner in the project. Of course, more complex situation (e.g. with multiple implementation partners, local vendors) are not unusual. It is important, though, that all parties know what are they responsible for during the project. Well defined roles in the project and assigned responsibilities (RACI) will establish the leading role in the project.

Plan the transition

Although at the beginning of the project that may seem much too early, good transition planning provides solid basis for smooth handover of live solution from the project organization to the support organization. Central delivery organization needs to ensure that the information about application service organization, RACI, processes and tools is properly shared with local organization. Then, during the project, based on transition framework necessary resources are defined and planned. Knowledge about the local implementation needs to be properly documented and shared with the support organization. It is the project team that on the one hand provides and eventually retires post go-live support, while one the other hand support organization enters the operational mode of application support. And the solution lives on.