SPOTLIGHT ON TWININGS

We caught up with James Maunder, Head of Business Systems at R. Twining and Company Limited, who shared his insight on their recent major SAP implementation.

Here’s what he Told us...

We implemented a broad SAP deployment into our Andover site in June last year. Our Andover site is our global head office, the home of two commercial business units and is the location of one of our major tea blending and packing plants.

Our SAP implementation was a catalyst to renew and reconfigure our core business processes delivering gains in efficiency and effectiveness and, as such, fully aligned with our business strategy. A central philosophy of our implementation was the validated assumption that the processes baked into SAP represent industry ‘good practice’. Thus, we aimed to use SAP as ‘out of the box as possible’.

We’re live with core ECC covering our financial, sales, procurement, production and logistics processes. In addition we have SCM for availability to promise, supply network planning, and demand planning; SRM for requisitioning and supplier self service; SAP BW and Bex for report delivery; and PI for integration. Additionally, we use SAP Solution Manager for overall system management, system documentation and change management.

Overall this has been a successful and well managed delivery and one that we are keen to learn important lessons from. To this end, I asked my team the following questions in relation to people, process and technology:

Reflecting on these discussions, and also on my own insights, here are some of the key points that we learned…

1. What did we do well that should be replicated in future projects?

2. What were the things that we should have done differently?

3. What were the things that surprised us; the things that we really hadn’t anticipated?

PEOPLE

What did we do well?Overall the delivery engine for any project is its people. I realise that this is a blindingly obvious thing to say, but when I reflect on the core driver of our success, it comes down to our team who were incredibly hardworking, dedicated and intellectually robust.

One of the things we did particularly well in this context was to actively build the team, blending a mix of people who really knew the business (Twinings) with people who really knew SAP, and taking steps to craft the right culture within that team.

We were very careful to ensure that hard work was balanced with opportunities for the team to ‘play’ together with the benefit that relationships deepened and strengthened. We were careful to craft a ‘no blame culture’ : from the start of the project there was a regular ‘sunrise meeting’, every morning at 8:30am. Everyone had to be there, and a key purpose of the meeting was to call out if anyone needed help. From the very start we set the expectation that calling out for help was not only acceptable, it was the right thing to do. Not calling out and then failing later on was not what we were aiming for.

Build the right team, take steps to deliver the right culture and from that you’ll get the dedication, hard work, intellectual curiosity, robustness and rigour required for a successful SAP project.

What were the things that we should have done differently?

I would focus here on how we drew the scope of the team. While we created a very successful team, there were some people who had one foot in the team and one foot out of the team. For those individuals it was challenging to navigate the different cultural norms, behaviours and expectations. The lesson here is to draw your boundaries more widely, ensuring that people are clear on whether they are in the team, or whether they are somebody to be consulted, or just somebody to be kept updated on the progress of the implementation.

An important factor in this is that we created an SAP team culture which was quite distinct from that normal to Twinings. We could have done more to make that culture and its values visible to the rest of the business. In a way there was quite a segregation between the project team and the wider business; this at times made it challenging for those not on the project to properly understand what the project team was trying to achieve.

I would praise the work ethic of the team, as well as the intellectual rigour in which challenges were addressed. Despite this, in the latter half of the project the SAP team did have to work some pretty long hours and weekends to meet the timeline. While this is fairly normal for projects of this magnitude, we could have been more proactive in addressing resource over-allocation which would have made for an even smoother delivery.

What were the things that surprised us?Moving from a set of legacy systems that are of a smaller scale than SAP, delivered a significant increase in system and integration complexity. It surprised us how many people needed to get involved in problem solving. In ‘the olden days’ when we ran legacy ERP and linked systems, one or two heads would suffice to resolve an issue in any one of those solutions as they were relatively small, self-contained and simple. Because SAP is so sophisticated, broad and integrated, problem solving needs a different kind of focus.

PROCESS

What did we do well?We were very keen to learn lessons from other organisations that had struggled to deliver a successful SAP implementation.

One of the key messages that came out time and time again is the need to take SAP as ‘out of the box’ as possible.

Of critical importance was the need for strong rigour around project management methodology and, especially, change control. We reflected on our Twinings culture and its strengths and weaknesses, and concluded that we were “lean, agile, not too hot on process, light on governance, with a patchy track record of change control”; none of this added up to likely SAP success! One of the guiding principles therefore in selecting our implementation partner was to select an organisation who would bring that rigour, who could demonstrate a rigorous approach and could prove through reference calls that they, as a matter of course, would implement that approach. That is the way it went.

So, the top line point on process is that we adopted a robust project scope and change control process. We also had very clear and strict project planning and control mechanisms. Every phase had entry and exit criteria: you couldn’t go from one phase to the next phase without it being properly signed off. Re-enforcing this, we had a single project environment for holding documentation and actions.To keep us honest we also utilised an independent project assurance service. We had rigorous testing cycles with typical unit tests, integration tests, full dress rehearsals and regression testing for our implementation in Poland and China. Lastly, we had an active steering group with great support and commitment.

Things we could have done differentlyThese would mostly be around timing and these issues really came towards the end of the project. For example, we left designing our support processes until we had a support partner in place and frankly that was too late. We should have defined those processes earlier on right up front in the blue-printing stage when we were less busy.

Because our process stated that one of the go live criteria was that ‘the support processes are defined, agreed and ready to go’, not having the support processes defined became a major issue.

Finally, the negotiation of the contract with our support partner was left too late and didn’t give us the opportunity to focus on building this critical relationship.

Things which surprised usManagement of SAP Licensing takes a lot of focus and we simply hadn’t had that kind of requirement before. Additionally, SAP securities and authorisations is a large role and we had to modify our team structure to enable the right amount of focus on these areas.

Having SAP has helped us up our game as an IT department as it has challenged received wisdom on how to do things.

TECHNOLOGY

What did we do well?We’ve been very pleasantly surprised on the role that ‘Solution Manager’ plays. It requires configuration and focus to get it running but, if you do that, you can really deliver significant benefits. In our case, for example, we put all of our change control and our run documentation through Solution Manger.

What were the things that we should have done differently?Although we had a lot of focus on legacy applications and their retirement post-SAP, this would have benefited from earlier planning. Getting our SAP integration strategy right would also have benefited from more focus and involvement with our other specialists.

Things which surprised usOne area of SAP which we have found to be highly beneficial but complex and needing really focused skills is APO. We have had to do some additional work here to really understand what we’ve got, what it can and can’t do, and how it works.For this we have needed to invest in additional training and consultancy to help us resolve these teething troubles and, for something as

significant and as complex as SAP, you do need to plan for a period of trouble shooting with budget and resource. Once these initial problems are resolved, you can really move on to get the benefits out of your SAP investment.

The most challenging part of the project was data! It was difficult to source the skills-set to extract data from legacy, put it through the right transformation and upload it into SAP.

We are aware that there is a lot else you can do in it and we will evaluate other functionality in time, but we find Solution Manager generally to play a positive presence in our application architecture.

As part of an ongoing research project, IQ ERP surveyed our SAP Leadership network as part of a research project on ‘Lessons Learned from SAP Greenfield Projects’.The outcomes of our research to date has indicated a great deal about the different lessons learned in regard to People, Process and Technology surrounding SAP implementations, with different factors around these impacting on every stage of ERP implementations, across a diverse range of industries and project sizes.

WWW.ITQERP.COM |