Lessons learned from selecting & implementing a
'next-gen' planning platform
- led by Damian Bates, Atlas Copco
The key points below reflect contributions from multiple discussion participants and have been anonymised (except with permission) and edited to adhere to our 'Chatham House Rule' policy.
Atlas Copco's Context
- Different operating divisions, some for service, some supporting equipment sales;
- Different brands with each being its own independent P&L centre;
- Relatively small head office function so, when implementing a new supply chain planning system, it was essential to bring all those divisions on board;
- Previously using SAP APO which was adequate for “steady state” planning but had some limitations:
- it struggled under different operating conditions, particularly the large ramps that we see in the semiconductor industry as well as non-standard demand or supply conditions;
- it lacked sufficient control and visibility to optimally manage customer requirements, especially the complexities around different customer segments and the need to configure for configure- or engineer-to-order scenarios;
- lack of user confidence in the information provided resulted in people communicating directly and using workarounds instead of relying on the data. It felt like a black box where data is fed in and calculations are made but it’s hard to see how they have been arrived at;
- despite running every day, it was slow to adapt to changes in demand whether individual customer order, volume or phasing changes. Our S&OP process is middle-level maturity but the cycle takes too long to respond to these changes;
- When we started pre-pandemic, “VUCA” (volatility, uncertainty, complexity, ambiguity) was seen as a bit of an academic theory but now it has become clearer that traditional planning systems struggle to support that operating context.
Building a business case and gaining buy-in
- At first, the focus was on identifying quantitative (rather than qualitative) benefits as everyone wanted to see savings but we found that lots of the improvements are hard to articulate in pure financial terms, especially when divisions have slightly different operating models, market conditions and maturity levels. There’s a lot of literature about the amount of asset savings potential but it depends a lot on your current baseline and specific conditions so it was hard to adopt that for the business case. Vendors also offer templates to help quantify potential savings but these can be based on questionable assumptions so we decided not to include them in the business case we presented to the board;
- The way forward was, rather than trying to bring everyone along together, to focus on one division that had the most desire to change their planning system and, therefore, already had a level of buy-in from the business unit head. Although it’s difficult to evaluate the benefit of being more agile as there are so many parameters involved, this focus made it easier to articulate qualitative improvements that resonated rather than only using projected inventory savings or efficiency gains. There was an element of faith involved;
- We ultimately decided to use one division as a pilot and, learning lessons from that implementation, roll out to other parts of the business.
Vendor selection
- This was done in parallel with the effort to build the business case and gain buy-in so the two processes influenced each other somewhat;
- One of the biggest challenges was the amount of effort and time required to evaluate vendors. Some vendors were not shortlisted essentially because their sales process wasn’t engaging enough and there wasn’t enough time to coax the necessary information from them;
- The Gartner magic quadrant was a good starting point, although taken with a pinch of salt. What was very effective was to identify and approach other supply chain planning executives who had experience of different vendors as this avoided potential bias, especially when compared to reference customers who vendors can be reluctant to propose and may be somewhat cherry-picked;
- We didn’t have a formal business requirements document from the beginning as these requirements were evolving in this parallel process;
- Although all vendors claim that their solutions are infinitely configurable, we needed to dedicate considerable internal resources to look in detail at how their applications worked. We wanted to confirm how deliverables would actually be supplied so we ran two-day workshops with shortlisted vendors given a high level set of requirements and asking them to demonstrate how they would support our specific requirements, rather than just their generic, high-level presentation. We created an evaluation matrix evaluating individual elements of functionality but it was quite hard to demonstrate this without a fully working model of our business;
- Due to previous experience, we were also quite alert to challenges around data quality and integration, with particular focus on what data was moving, to and from which platforms and at what frequency as even integrations between platforms from the same vendor present challenges. Therefore, it was very helpful that one vendor took some sample data in flat file form and built an operating model so we could really understand it and see it in action
- Our IT team includes “global process owners” who understand very well the business processes that they support technically. Even so, it was critical to getting buy-in from the board that this was business-driven so we spent a lot of time with users building the story around use scenarios and using them to engage the global process owners
- We engaged the customer-facing and operational teams, on how it could help them model and improve their factories, capacity planning etc. and how the data could enable future scenarios rather than just being seen as a day-to-day transactional system
- A key consideration was whether to go into a proof of concept stage and, if so, whether to do that with multiple vendors given the time and costs associated. Ultimately, we decided not to but, having learned lessons from a previous implementation, we decided to go for a more gradual approach rather than a “big bang” where systems are switched overnight
Implementation
- The statement of work was quite a challenge to get right, especially as we hadn’t gone in detail into the level 2, 3 and 4 process flows so it had to be relatively high level. It’s virtually impossible to know all of the challenges in advance because every department has some custom data and processes
- Legal and procurement were rightly very involved in the statement of work but, in retrospect, that probably meant that we were too focused on what might go wrong rather than focusing on the business requirements and getting on with the project. Clearer requirements from the start may have helped but, for that reason, we began with a time and materials agreement but expect to move towards fixed cost as we progress
- We’re going through an “open loop” process where data is read into the planning system to fine-tune our S&OP process but not yet integrating that with production and distribution plans. As we learn how the system and interfaces work, the second phase will be to close that loop and feed those plans back into the ERP. Once we’re happy that we have and end-to-end process for both S&OP and S&OE, we’ll take that to other divisions
- Having started with a high-level, descriptive plan, we’re using an agile approach based on over 100 user stories to detail the level 2, 3 and 4 processes that build up into the level 1 processes. There are seven sprints over over four months to implement S&OP which means we can engage users really early with live data
- The finance team are understandably reticent about bringing their financial data into the planning system so, again, we’re taking an incremental approach by starting with some financial information and hoping to demonstrate the benefits to bring them on board
- With regard to rolling out to other divisions, our pilot division happens to be the most complex so we hope that we’ll have a good operating model that can be applied to the others with a single instance, perhaps with a few tweaks. If we’d tried to align every divisions’ set of requirements, we probably still wouldn’t have started yet!
Lessons learned
- Find stakeholders that are already at least somewhat bought in and who have an end-to-end perspective
- Narrow down potential vendors quite quickly as there’s a lot of work involved with shortlisted vendors to make sure they can really meet your requirements
- Don’t underestimate data quality and integration challenges
- Get the statement of work as clear as possible to avoid finding that one word could make the difference between something being in or out of scope down the line
Next steps: developing control tower capability
- A key challenge is that we have lots of little silos of visualisations of reports which aren’t shared across the business so we’re bringing all our data into a single data lake and consolidating it to create a unified data library
- We want to minimise the amount of processing and create as many common variables as possible in the data library to refer to in reports and common levels of aggregation and hierarchies to help manage access to the data
- It’s still at a relatively early stage but we anticipate building a single supply chain control tower into our planning platform so that it’s built bottom-up with all of the information available in the planning system, in both financial and units terms
- The goal is to be able to drill down into the data from the top and set up critical alerts and reports
*Others on the call also commented on their own plans to develop control towers that include initiatives to better manage master data validated across ERP systems and as a way to migrate away from multiple legacy systems. A specific discussion on this is in the pipeline.
Sign up for monthly updates & session outputs
Tell us which sessions you'd be interested in joining
Top SC Planning Best Practices...Digested
Real lessons learned distilled from a series of practitioner exchanges on...
Digital Transformation of Supply Chain Planning
Digital transformation has been on corporate agendas for some time already but, borne of necessity, tangible progress accelerated significantly since 2020. A silver lining of the pandemic may be that the business case is clearer so the focus has shifted towards implementing and scaling digitalisation initiatives.
Supply Chain Design Modelling and Analytics
Supply chain network (re)design used to come around every few years or so, often based on quite a high level view of customer segments and associated costs. Now, competitiveness and even business continuity relies on the capability to dynamically adapt network flows based on a much more granular understanding of cost drivers.
Volatility, Agility & Resilience: Next-Level Planning
Volatility, Agility & Resilience: Next-Level Planning
Volatility, uncertainty, complexity and ambiguity was already an increasing factor before the pandemic but, now, it is clear that we need the next level of demand forecasting, sensing, planning and execution.
