We live in a change economy. In a best-case scenario, the change is intended and planned. Business development is a good example: organizations are changed by growth e.g., by expanding existing operations, buying other companies, or increasing international presence. Yet often the changes are sudden, unexpected, or imposed. This forces swift reaction to external dynamics, may require change of priorities and usually results in some business transformation. As this happens, IT plays a vital role in supporting this process.
Regardless of the trigger, expectations from the change are usually the same: more efficiency, unification of processes and data as well as consistency of operations and streamlined integration. On the other hand, it is also a lookout for the lower costs, reuse of resources, streamlined integration and curbed support for business requirements for a limited long-term value.
Unsurprisingly, both changes and resulting expectations pose a real challenge for the company. How to improve efficiency with managing operational changes? How to operate in a more consistent manner on a global scale? How to ensure that the master data in multiple companies is consistent and unified at the required level? How to reconcile the needs of multiple countries or localizations so that they can cooperate better together?
Define a common template
The answer to those requirements for an SAP-driven company is a Common SAP Template. Such a template is a set of information, applications and IT backbone that combined are aimed to support an organization in the common, unified way.
From the feature perspective, the solution template can be imagined as a set of “layers” of functional groups. At the bottom, there is the Common Core Template. It is a set of basic functions which are or should be harmonized across the companies within a group and supporting day-to-day business operations. For companies that are more demanding or simply covering a broader-than-typical functional scope, the Common SAP Template provides the optional second layer of extended applications and functions, again unified and managed on a global level (e.g., extended warehouse management).
Obviously local companies have their own local requirements on top of the common “core” or its “common extensions”. That is either because of the legal (local-core) requirements or simply due to the specific character of the local business (local-extended). The result of the Fit-to-Standard/Gap analysis should provide guidance if and how to address these requirements on top of the common template. While legal requirements are rather hard to avoid, one needs to keep in mind that adding lower-priority features to the common solution will create obstacles to achieving the synchronization and harmonization of the processes and difficulties in system maintenance on a long run.
One can also consider the solution template as a set of accelerators, components required to deliver implementation projects faster, more efficient, and aligned. There can be a set of business processes which are available, ready-to-use and aligned all across the company. They might include business process models, functional and technical specifications or test scenarios providing functional insight into the functional scope and its validation. Typically, a template includes also customizing and development accelerators e.g., a standard chart of accounts, pricing procedures or company standard printout forms. On top of that, the template usually also offers accelerators and tools used to speed up the delivery of rollout projects e.g., project documentation templates, data gathering templates or upload programs used to transfer data into a common SAP solution. If a company is utilizing SAP Best Practices, they allow it to take advantage of some of those accelerators already existing in the ready-to-use package. Regardless of the accelerators, it is crucial, though, to rely on a single, company-wise repository, like SAP CALM, MS SharePoint or SAP Solution Manager acting as a reference.
Larger or more complex organizations may also consider organizational accelerators e.g., policies for customizing, a code of conduct for software development or naming conventions for transports. Another consideration is a solution governance model for long-term template maintenance. There need to be custodians, people who will keep the solution intact and consistent. Eventually, there is a part of the hardware and software that determines where and how the IT systems are managed and maintained.
It doesn’t mean that a solution template needs to embrace all those elements. More is not always merrier. Yet, when the complexity of the organization increases and the scale and/or volume of the rollout projects is high, it is worthwhile to invest in a more comprehensive, reusable template. Alternatively, smaller companies may initially rely on their implementation partner’s experience and tools, focusing on faster project delivery and leaving the decision on the optimal template setup for later.
Template-based delivery
While template documentation provides business explanations and guidelines on standardizing the delivery, larger companies may decide to take their solution template a step further. This can be done by configuring a set of customizing settings so that they can be maintained and re-used in rollout projects. Although it requires some preparation, it may be a good investment when planning e.g., a global rollout program. For smaller companies, such a pre-configured setup is less cost-efficient and hence – less attractive.
When planning for the template delivery, it may be worthwhile to provide a set of ready-to-use templates for the most common and/or time-consuming project activities. These documentation templates may include a gap analysis report for gathering country-specific requirements, standard authorization models, aligning system roles or a set of test scripts and validation scenarios used to test the solution during the implementation project and also during operations of regression or upgrade testing.
Since data migration is usually the most troublesome and time-consuming part of the project, templates guiding project members through data scoping, gathering and delivery according to the common standards reduce errors and inconsistencies during data migration and speed up the migration process. Specifically, pre-defined data dictionaries or ready-to-use migration tools (e.g., LSMW or migration cockpit projects) will definitely improve data migration efficiency. Clearly, if such templates don’t exist, an experienced project partner like All for One can either help to develop it or simply provide it for the rollout project.
Speaking of the project delivery, it is good to think in advance about standards that can help implementing the project in a consistent manner. These standards include the so-called codes of conduct describing guidelines and policies for e.g., customizing, development of customer programs and interfaces, data coding or authorizations. Similarly, clear guidelines for identification of e.g., processes, transports or users simplify and streamline project activities. The same applies to the delivery process itself: a project delivery methodology or organizational change management guidelines steer every project team through the same checklist of project activities and deliverables.
When thinking about the solution template on a long run, obviously not only delivery but also governance should be involved. Depending on the complexity or particular needs of a company, solution governance may only be focused on specific procedures, for instance, for change and release management. In large-scale scenarios, governance embraces also areas of transition (handover of a project into operational support), quality audits and lessons learned, as well as complete organizational support for maintaining the solution, including structures, roles, responsibilities as well as functional and technical ownership of the common template.
And the technical components of the template and its technical architecture determine the flexibility and the level of control over the common solution. Availability of cloud and on-premise scenarios combined with a selection of SAP and SAP partner services offer a wide menu of options available for any needs ranging from full ownership of infrastructure, application and business processes (on-premise), through IaaS, PasS up to the SaaS model.
Set up a rollout project
Regardless whether the template being the starting point is clean and simple or heavy and complex, it serves one purpose. It is to roll out the existing solution to a company that does not have one. Though, there are a few considerations that should be addressed to ensure that project delivery and eventually, business operations supported by the project results end up with success.
Unsurprisingly, every successful initiative should start with the clear purpose. Changes with a big impact, and SAP implementation is one of them, often arouse concerns, fears, questions, maybe even some resistance. Having the project goals set, communicated and understood paves the way for the people wanting to work towards them, not against. Standardization aligns the group’s processes allowing companies to work better together as a whole. This drives efficiency visible both in company financial results as well as streamlined operations.
Efficiency stimulates improvement e.g., retiring an obsolete solution currently in use, addressing requirements and lack of sufficient support for business operations. Understanding the ”why” focuses attention of stakeholders and eases up decision making.
The next step is to assess the playing field and determine the scale of the rollout initiative. Is it a small project e.g., implementation in a single country or a program of parallel rollouts? Global organizations “package” programs in even bigger “containers”: a portfolio of programs targeted at delivery of multiple implementations all over the world. Following plans need to be based on a specific business situation, considering business goals but also delivery constraints.
Then there is a delivery model. At present customers usually choose between something modern (SAP Activate), something “classic” (e.g., SAP ASAP) or something “borrowed” (typically a proprietary delivery model). Currently, for SAP implementation, SAP Activate methodology seems to be the most obvious choice. It focuses on an agile, more interactive approach to implementation, with higher customer involvement offering iterative delivery and hands-on experience.
A waterfall approach, on the other hand, is well established in organizations, although due to limited flexibility it is on a downward slide. Project-oriented organizations as well as implementation partners often utilize their own custom/proprietary methodologies. All for One teams are – aptly named – agile, and therefore ready to work in any of the presented delivery scenarios.
As the saying goes, preparation is 80% of success. When a project methodology is known, there are certain indicators of organizational readiness that should be checked beforehand, prior to actually starting the project. The first indicator is the maturity of an organization planning for implementation, e.g. whether business processes are defined, maybe even aligned with strategic goals or maybe they are completely unstructured, hence capturing this structure will become one of the project goals. The second aspect is the alignment of the organization with the headquarters.
The more standardized business is, the easier the implementation will be. Potential misalignments or custom derogations may require additional optimization. Another readiness indicator is a source of the project drive. Unsurprisingly, projects which are driven by the business (rather than IT) end up with a better solution fit and higher business satisfaction. Rollouts initiated by IT clearly can be successful as well, however they require more effort to onboard the key- and end-users as well as other beneficiaries of the future solution.
Since rollouts typically are international projects, language skills of local and central teams as well as project partners’ teams cannot be underestimated. English might seem to be an obvious lingua franca in a globalizing world. Yet, language skills are very individual and e.g., fluent English or German speakers in finance won’t help push project in sales or manufacturing. This needs to be assessed beforehand to assign people to the project, knowing that they will be able to communicate effectively with corporate and partner consultants. Keep in mind that international rollouts are, well, international, hence the language of template documentation or the system language might also be a matter to consider.
Explore the scope
One of the key dilemmas during the rollout is the level of control a local company is granted in terms of the extent to which the scope of a template solution is a non-negotiable standard and where local differences are allowed. In a strict approach, the template is fixed and the only derogation is a legal localization. When the corporate policy is flexible, template becomes more a recommendation and guide, whereas local customization is limited mainly by economic factors.
Obviously, the first strategy results in a centralized solution and limited local control, but also stronger synergy and harmonization across the group providing better overall efficiency discussed at the beginning of this paper. The latter approach uses a solution template only as an implementation accelerator, thereby significantly undermining the group investment in the common solution.
A well-addressed implementation scope is an important element of the project success. Regardless of the rollout project being international or local, scoping starts with the geographical complexity. “Geography” isn’t just a location on the map but also a set of project variables. Even the delivery of a rollout in one country but at two distant locations raises questions on scoping, testing or support organization. Apart from the already-discussed language issues, geography determines legal requirements e.g., rollouts between two UE countries will be delivered with a more limited set of requirements than a rollout from the EU to Asia or Africa.
Working in another country brings cultural issues to the table. If neglected, they can completely derail any local project. Finally, time difference, which if significant, limits a daily window available for cooperation between internationally working teams and requires careful planning both on the task level (e.g., aligning meetings) as well as on the project master schedule level (e.g., a longer project timeline).
The scope is also determined by the complexity of the company’s organizational structure. Sometimes it is just one legal entity or one new plant. In other cases, it can be a group of companies or production plants in one country. Undeniably, the more complex organization is, the more challenging a rollout project will be.
Apart from location challenges, different entities mean different stakeholders, with an agenda that is not necessarily aligned. Different entities may also mean different purposes (e.g., financial) or business profiles (e.g., commercial, manufacturing, supply chain) which come with a variety of business processes. Aligning those differences locally and matching them with what a template has to offer will be one of the major challenges of a project. Eventually, it will also impact the go-live strategy ensuring business continuity, limited disruption and sufficient support for all involved parties.
Moving from an organization to a solution scope, there is business and IT function complexity. The distinction between the business and IT is valid since both groups will definitely look at the implementation scope from different angles (e.g., a group of processes vs solution components addressing them). While rollouts generally are business driven, only ensuring that the people from business and IT understand “their” layers of the solution can make project a success.
Don’t lose the bigger picture, though. Even the best template won’t address all functions provided by the local third-party systems. Some of these existing legacy solutions will be decommissioned and replaced by newly implemented common SAP system. Other will be replaced with their common counterparts (e.g., local SFA replaced by a common solution used globally). Remaining legacy systems will require adaptation to the new situation e.g., integration with the group’s SAP system, hosting or platform adjustments or a major re-build.
Finally, there is data migration, which is a huge topic deserving a complete separate article. Data, being the “fuel” to the “solution”, is vital to the overall implementation success, and therefore requires careful planning ahead of time. At the local level, it requires considering the scope of the data and people who do and will own it. Rollout scoping should consider, among others, data standards and a management model (e.g. central or local material management), an upload strategy (e.g., which data, where and how will be transferred to specific migration targets) and migration timelines for collecting and cleansing the data synchronized with other project activities of the project plan.
Assign roles
When the scoping playfield is set, it’s time to identify and assign roles and responsibilities. Obviously, the business roles are usually clear. Yet, these need to be combined with the responsibilities introduced by the implementation project. By design, these can be grouped organizationally: group and local teams joined by the external partners. Yet, an international rollout often introduces new people to the game: template solution custodians, business process owners and internal consultants in the central team, group partners (e.g., responsible for central system maintenance) and local partners (typically supporting solution localization).
Combining them effectively with the local business and IT requires clarity and transparency, ideally in a form of a responsibility and accountability matrix. This tool helps project managers to ensure that all project activities and roles are properly assigned, and everybody knows what he or she is responsible for.
Project delivery is not just that, though. For the perfect outcome, the results of a successful project need to be successfully transitioned to operational support. A central team plays an important role, usually defining a managed service model (e.g., central, local, hybrid, internal or partner-managed) and providing a transition framework. It is only after the project partner hands over the solution and deliverables and the operational support is engaged that the project is really completed.
Engage
Is this a “mission impossible”? Well, it definitely is a “mission difficult”, considering the global scale and potential risks and challenges, e.g., prioritizing rollout projects vs S/4 conversion. Yet, it is safe to say that support of an experienced, professional partner can make this uphill battle more like a walk in the park.