ERP Implementations Strategies: Fresh, Rollout, Support, Maintenance with Governance & Compliance with real time experiences.

There is a involvement of mine in different types of SAP projects: Greenfield, Template build and roll out, Business process re-engineering & roll outs, Merger & Acquisitions- a template based on best of both then rollout, few support projects and an upgrade in large scale programs across different industries: automotive, utilities, manufacturing, ?FMCG/CPG, Printing & Imagine industry, Frozen food, Dairy products manufacturing and distribution, FMCG acquired Core FMCG/ FMCD, Retail, Pharma Manufacturing and Commercial organizations, Service Industry. Sharing some strategies and insights on some key aspects like the Approach, Selection, Piloting, Prototyping & Governance that we should all need to think are important to consider when embarking & going on a Global ERP implementation & roll-out program.

Before we go on, there are couple of points that we need to emphasize upon: That the ERP product selection has been done with due consideration to all the features and License (the indirect license issue SAP S/4 HANA has got itself into needs a special mention). The reason is not all offerings by SAP are the best in the market and depending on the business need, requirement & various other factors each organization chooses what's best for it. All the above is much before embarking on a global program.

Most large organizations today have a global presence & depending on the type of industry the businesses can have:

1)?????Multiple manufacturing sites in different locations, across Globe on many nations.

2)?????Multiple Sales or Distribution network centers in different countries as well.

3)?????Regional Sales Centers or Market Performance Centers or Regional Dealers.

4)?????Importers & Suppliers.

5)?????Market Warehouses or Local Operating Agencies or Markets.

“Big-Bang” ERP go-live approach is where all the functional modules namely Sales, Procurement, Finance, Warehouse, HR, Sales etc. depending on what is required and what is available part of the ERP product gets implemented across the business “landscape” i.e., could be all the manufacturing sites or all the regional sales centers across the business.

A “Phased” approach is where the business decides to break up the implementation into phases by building a template and rolling out or implementing part of the functionality and rest later in phases.

What is better, or what is worst? :)

?

?????????

??

There is a lot of text on Big-Bang vs. Phased projects; I’d like to discuss in more details about phased approach projects. I’d like to share my point of view on how it should be done with the “what’s & what nots” with examples where appropriate:

The key considerations (Areas of Risk):

1)?????Pilot sites/centers: This is one the key considerations in the phased project planning and also would pave path for the roll outs forward. We know how each country across continents is placed economically and the volume/value of business they create. For example:

a.??????Europe usually takes the biggest pie in terms of business volume. They usually have lot of requests which are more local in nature than serve to be part of the template. All the special pricing, related government schemes and required interfaces, Obama Care related Interfaces, or special purchasing requirements or External Tax engines: Vertex, OneSource, Sabrix, Brim, Ariba, Fiori etc. for tax functionality which isn’t again required for rest of the world.

b.?????South America do not necessarily take up the large pie but do come up with their complicated tax requirements, India with reverse pricing and complex inter and intrastate tax requirements (yes GST has simplified it all, but it still remains complex), documents required for goods movements. In Brazil, the diff fiscal calendar, “Not a fiscal” and all the other complexities again don’t make up a strong case for a pilot site.

c.??????APAC Region (Asia Pacific): Japan/China/Malaysia/Vietnam/Singapore/India/Hong kong & now a days middle east Countries likewise UAE, Dubai, Oman Saudi Arabia etc. usually have the highest business volume in this region and because of special customers, interfaces like Golden Machine for China and all other local market requirements do not make up a strong case for a pilot site.

d.?????Europe: Within Europe, in general the VAT scheme, Plants Abroad, Intrastate reporting is pretty much all standard across Europe and is pretty much re-usable. So, here I am making a suggestion that it’s best to choose some countries from Europe for piloting and basing your template on. Of course, we have some very few exceptions like some Countries again because of the local and legal requirements more complex than the rest one.

Here We’ve not covered all regions on the Globe but just wanted to give an idea & heads up of the various factors that should be considered when considering your pilot site/regional sales center in the respective region/ Country. A very low volume/risk site/Country as a pilot site might not be a good idea as it might not represent even 25% of the business process/solution design. At the other end, a very high volume/risk site/country isn’t a good idea either, as they have may have too many complex or local requirements/scenarios that might not be re-usable (some of the exclusive regions of EU).

So, choosing not too many sites and medium risk/volume is a safe bet as a pilot site, however, a BIG factor is just to talk to most/all the sites and get an idea on the scope/processes & Key/Critical requirements to build them into the template. However, it’s a tricky situation to talk to all sites and build a template that can cater to all requirements esp. given the timelines and need to hit ground early.

2)?????Stabilization: So, we’re past the pilot phase, there will be the usual issues post first go-lives and post all the fixes, there needs to be few more than the pilot sites/countries/markets that should be part of the next go-live countries.

One must be careful not to plan too many for the next phase of go-live. I’ve witnessed a real example where the first 2 pilot sites went well but the 3rd was a failure—resulted in $ losses, production disruptions: the reasons could be data, market/site readiness or lack of proper training or we probably underestimated that the 1st pilot markets were not new to SAP, however this market was! The next phase was planned for 4 markets- we took a pause and re-planned and cut it back to 1 market and from there on ramped up to multiple markets/sites per phase and gradually moved into an industrial deployment mode.

So, it’s very important that we don’t get overconfident too early and consider all factors, situations and get into a stable mode, before embarking on a Delivery wave phase for multiple markets/sites.

3)?????Governance/Change Control Board/Design Authority: Right from the pilot phase, it is very important to setup a team for the following:

a.??????Governance, Risk and Compliance: Depending on the Industry, it is very important to setup a team which ensures our documents, IT systems, test/validation/results are fully compliant, and meet various industry standards that can be well audited, are comply to various regulatory requirements such as Good Practice (GxP) Regulations for Pharmaceutical Industries. Not to mention the importance of Annual Audit (SoX) Compliance in all the design and documentation.

Simply put, the program/team must ensure that all our documents reflect what’s in the system, documents are stored /archived available for audit purposes anytime, test scripts and evidence are all available and link well to each other.

b.?????Change Control Board or Change Committee Board (CCB)/ Design (or Delegation) Authority: Now, one of the biggest responsibilities lies with CCB/DA-this team should be cross functional & they should be responsible for also Scope control.

Once the template has been built, each new market/site brings in new set of requirements and they can broadly be categorized into the following:

·????????Legal/Regulatory/Fiscal: Country or Industry specific legal/regulatory/fiscal requirements that arise are simply non-negotiable and template should be changed.

·????????Improvement & Timely Review to the Global template(s): Any such requirement that brings in an improvement to the design/process efficiency should be respected. However, each of the requirements should be checked for a valid business case and something that brings in process efficiency or an improvement in the design.

Also, each of these changes should be looked at from a cost-benefit analysis: what’s the cost of implementing this change and what value does it add to the business- does it bring some automation, process efficiency or reduce FTE or simply a better business process that the business is ready to support.

·????????Strategic Changes: Some of them can be strategic changes with their specific & concern contingency planning, for example moving from one 3PL provider to another and which results in newer interfaces. In the long-term strategic vision of the business, the immediate cost of doing some changes might not make sense but there are factors beyond that’ll result in savings in the long term, however, these decisions will need support from Senior/ Leadership Team.

·????????Continuity of Supply as well as Distribution: Changes that need to support supply to key customers/accounts or a change to maintain the continuity of supply as a sub-process to support a main process fall under this category. As with any other category, every change request needs to be validated and analyzed.

It’s always better to come up as many as viable design/solution options with pros/cons and required technical analysis. That gives an idea to the extent of which all the different options were explored and what’s the impact of the changes on the business process or Ways of Working.

c.??????Core Design Team/Local IT experts: There should always be a core design team that understands the template?& any changes to the template are changed in a controlled manner by this team and any x-functional implications well covered & implemented.

The Local IT experts should help plug in the local requirements and liaise with the local business and core design team to manage the change to the template and manage the training & transition to local business aspects.

4)?????Standardization: With global ERP templates, comes the chance of business process re-engineering and standardization. It brings a lot of advantages:

·?????? Different regions might be on different ERP or legacy systems with their own set of data/system and processes. With global ERP programs, it’s a good chance to bring all of them onto a single system, all the data is on a single system.

·?????? Helps businesses optimize and standardize business processes while encouraging the adoption of the best practices throughout the organization. Streamlining the processes brings efficiency and could sometimes be cost-effective one.

·?????? Having all the data in the ERP system helps to consolidate financial information faster and reduces the effort and errors in doing financial consolidation and reporting as well.

·?????? Reduced operating costs: including staff, IT systems, multiple disparate systems, infrastructure, and applications as well as included Operations plus Support (may be under the umbrella of one way which is to be secured from all possible multiple aspects within same network).

?Issues with Standardization: While all the above is mostly true, efficiency, best practices or reduced operating costs need not always be true. In the tendency to standardize or “we’ve to done this for lot of sites/markets before so this should be good for you” theory doesn’t always hold good. So again, proposed for reviews on the same on timely manner considering the same again from multiple aspects.

On certain occasions, there are some sites/markets already on an ERP system and have much more matured systems, better designs, and better practices than the template(s) what we are using in our own mechanism.

Example 1: Use of 3PL is a common scenario and the relation between a business and 3PL can vary from business to business as well industry to industry.

Org 1: 3PL manages the batch determination, picking, packing and related documentation in their WMS systems- Template.

Org 2: Batch management and qty changes managed in-house, 3PL manages only picking/packing & shipment management.

Imagine embedding Org2 into Org1 without changes to the template- resulting in constraints around how the Org2 managed their batches, changes to deliveries and documentation.

Example 2: Minimum Order Value is a common functionality and was part of the template of a large FMCG/ FMCD organization I was working for. They acquired a smaller FMCG/ FMCD and in few of their markets where this practice (of MOV) wasn’t prevalent but the way this market in this region did business was different- they would take all orders (of any value) and consolidate them on a weekly basis and that met the MOV.

However, this required Order into Delivery consolidation, which was not part of the template to the CCB/DA didn’t support resulting in significant changes in the business processes and Ways of Working. The hard MOV check/stop at Order level also resulted in some customer dissatisfaction and some revenue loss in the short term.

Example 3: Organization 1 handles their data and documentation around Hazardous Material info—using text field and treats the SKU as dangerous irrespective of the Mode of Transport.

Org 2 handles it using Standard SAP hazardous profile feature which also handles dangerous profile of the SKU by Mode of Transport.

Org1 acquired some parts of the business from Org2 and was trying to deploy the Org1 template solution into Org2 and as a result the CCB/DA didn’t support the feature that was in Org2.

This means the Org2 pays extra for special handling in special containers of the Dangerous goods, which in the past they never paid for. Org1 CCB/DA saw it as major changes to the template and changing existing data and documentation aspects. The argument that it might result in savings that will come out of savings in the special transportation arrangements might over-run the one-time template and data changes was not pursued because we didn’t have time and it was thought it is not worth it! While this is a tricky situation and there’s no single correct answer- it depends on the number of dangerous goods an organization handles and the extra cost they would incur in special transportation arrangements.

These issues typically happen when 2 different organizations join and have 2 diff ERP systems with different solutions, different processes (likewise the kind of a situation generated in Merger/ Acquisition). If one organization is significantly larger than the other or the larger organization has acquired only a small sector/part of the other organization. In this case, the smaller organization must compromise on some of their existing functionalities/ processes (and sometimes on SOP’s too), maybe less efficient processes or not as smarter solutions.

My purpose was really to talk about different approaches, key factors that need to be carefully considered and planned much ahead of a large-scale program but not to cover all other areas and aspects like Testing, Security etc…but more on the flexibility one must take while imparting standardization. While standardization, best practices all work good for such a large-scale program, however, one has to be careful not to be too rigid about sticking to template processes/solutions. There could have been historical reasons or Brownfield constraints that led to a less efficient or less smart solution when the template was built but if there’s something that improvises it, those should be taken on board.

While the number of such large-scale Greenfield as well as Brownfield programs is less frequent nowadays, it is still expected when the organizations move from the current to the newer versions of ERP for ex. SAP S/4HANA, C/4 HANA for SAP or the various cloud solutions of diff ERP products –the same principles apply in somehow in the different shapes or forms of other ERP's too.

Remember the cycle of feedback, continuous learning, development & improvement is always the best approach! Like a Kai-zen one.

Whatever your experiences from various other programs you’ve been involved within Organization or outside the organization for any internal as well as external Project.