It’s astonishing just how many large companies have been held back, derailed or even destroyed by large scale software projects that have gone badly, badly wrong. Companies can end up paying far more than originally agreed. Some projects are simply never completed. Whatever the specifics, the enormous stresses software implementation meltdowns create for both vendor and client are simply too horrible to contemplate.
Let’s not finger point. Any quick search of the internet will provide examples of the software equivalent of a multi-vehicle pile-up.
And it’s not enough simply to be aware of the pitfalls. We need new approaches and new ways of implementing and managing systems that radically reduce the risks.
This paper draws on our experiences at RELEX over the last 8 years. We don’t pretend to have all the answers; any software company that pretends to have all the answers hasn’t been asking the right (or enough) questions.
However our approach seems to have helped us and our customers sidestep or solve many of the problems common to large system implementations.
What’s the secret? Well it’s not that much of a secret, but it is an important principle: agility. We think companies should be thinking in terms of agile process development – and here’s why.
When Software Implementation Projects Are Painful, Does That Mean They’re Working?
In a word, no.
Many massive software projects (ERP implementations being a good example) have problems, or even failure, written into them from the very beginning. The waterfall approach is a term used to describe a traditional strategy in software development; one widely thought to be broken. Under this approach the customer is expected to define all their goals and requirements at the outset. It’s a strategy inherited from hardware orientated industries like construction that, when applied to software, brings huge problems. Agile software development is a contrasting approach often put forward as a better alternative.
At RELEX we apply the same thinking to processes because where one is implementing supply chain management systems, the key concern is to optimize your processes and then wrap the system around the model – not the other way round.
While the waterfall approach is pretty much discredited for software development it’s still far too common in process development. Hence you have the same, questionable situation of a client being asked to scope out a project from the outset where no one has used the system, and where they have probably seen no more than a system demonstration, and that only a couple of times. This is an almost impossible task, and an unreasonable one, and the problems tend to multiply with the size of the project.
The waterfall model can also push people to make decisions in areas in which they are not yet expert. For example, client-side representatives involved in the specification phase of operative supply chain software may not be IT experts. Their skills may instead lie in supply chain management, procurement or product management. There’s often a limited upside in asking them to scope out the technical IT requirements and there’s downside a-plenty. In addition, it is usually very hard to define the best possible alternative without actually using the process and system in a daily work.
So what’s the answer?
Above all, specification should evolve in tandem with actual usage.
Under this approach the objective of the specification phase is not to define every single detail of the software, but to reach a common understanding of the application in terms of the most important uses and processes. Also, the specification should be considered more as a hypothesis, which will change after users have experienced the software in routine use.
We find it helps to concentrate on 3-5 core processes, such as assortment management, master data management, ordering/reordering and handling tricky demand situations (product launches, campaigns etc.). In most cases, one three-hour workshop on each topic is enough to produce an overview of the current situation and identify the ultimate goals and targets of each process. The most important objective in this phase is to identify roles and responsibilities relating to the process, ahead of the system going live (even in pilot).
When the specification is complete it’s time to roll up one’s sleeves and get the system up and running. We find this usually takes between 4 and 8 weeks, after which the customer can start piloting the system, typically for one product group or a small number of stores. At this point, the users can see how the system actually works within their operations, and that makes it far easier to suggest changes. Then, based on client feedback, vendor and client can fine tune the system together to meet the client’s needs in accordance with this evolving understanding. This can be done incrementally throughout the course of the pilot (typically three months).
The approach won’t seem revolutionary to anyone familiar with the agile approach to software projects. Agile methods have become more and more popular over the last decade, and many software companies use them very successfully. RELEX uses the agile approach extensively in its own software development.
The key to understanding the importance of agility with software implementations is appreciating that it’s distinct from agile software development; it’s pretty much a prerequisite that the software being implemented should be inherently agile – easy to configure and adjust. Agility in implementations is primarily about agile business process development. In practice, this means that when a new business process requirement is identified during the pilot, changes are made e.g. adjusting software calculation logic. Typically, however, these changes are not carried out by software developers, but by the vendor’s supply chain consultants and, as the implementation proceeds, increasingly by the customer’s own super user(s). The real process experts are the people who will be using the system, and RELEX’s approach is based on the belief that they should be empowered to make the changes they want, as and when they’re needed to get the process functioning towards goals.
The Requirements of an Agile Process Development
Agile business process development is a simple idea: you have the best possible roadmap at the outset but as you proceed, whenever you find the landscape has changed, you can take a different route. The roadmap is there to provide a starting point and guidance, but the ultimate goal is to arrive at your destination, happily, quickly and safely. Given solid IT support what’s not to like?
The question becomes; ‘why are not more software companies operating this way then?’ The answer is; ‘because it is not easy’. The operating model is very demanding of the software itself, of the vendor’s implementation team and also of the vendor’s business model.
The most fundamental requirement is that the software or platform that you are using for your project is flexible. Agile process development requires you to be able to make constant adjustments to the system and get more or less instantaneous feedback so the impact of each adjustment can be analysed. If your software or platform isn’t designed for quick and simple adjustment then you’ll either find it’s not possible or it has the potential to cost you a great deal of money.
In practice a key system feature is likely to be In-Memory Analysis whereby data is held in the active memory and bypasses storage entirely, allowing vast data flows to be processed in seconds rather than hours or days. This feature ensures that you get instant feedback with each adjustment. Processing delays common with systems that process data held on hard drives mean that you can only sensibly adjust as fast as the system reports. At RELEX flexibility is the quality that we’ve strived hardest to achieve and is, consequently, the goal our R&D teams have put most time into. The result is extremely efficient on-the-fly calculation and reporting, which enables all product master data and inventory metrics (among other data) to be used in search and reporting criteria. This makes it very easy to implement changes e.g. for handling order proposals, as time, experience and new circumstances suggest that changes are necessary.
Secondly, you need to know which questions to ask during the specification phase and those vary from case to case. Who defines the products and which need be replenished? How should the changes in future campaigns be communicated to the purchasing and what should the purchasing do with this information? What are the most important Key Performance Indicators in this project? It is inevitable that some questions are left unanswered at this stage. Above all though you really need to understand the target process. This is not always the case at the outset, and you often reach the necessary understanding through experience. Consultants’ expertise helps shape a tailor-made solution to each customer’s needs.
Finally, the vendor and the client need to have shared goals. If the vendor is charging from the very beginning, and/or if consultancy fees are open-ended and grow larger the longer the project continues, it creates an incentive to spin the project out for as long as possible. This runs directly counter to the client’s best interests. The best deal is one where incentives are structured to deliver an effective system to the client quickly and efficiently and that reward the vendor for the smooth, long term operating of the system. If the vendor can supply a system that doesn’t need constant support from the vendor or third party consultants then it again benefits the customer and makes for a profitable business for the vendor.
Case Example: Vianor – The Leading Tyre Retailer in Northern Europe
A good example of the RELEX approach was the implementation project RELEX carried out with Vianor. From early on it became apparent that key challenges would be, firstly, the definition of processes for the assortment management and replenishment systems and, secondly, change management, especially within Vianor’s retail outlets.
Let’s take assortment management as an example. When the project started there was no clear assortment management process as responsibility for ordering was with the outlets. Working with RELEX, Vianor’s development team came up with a model whereby seasonal assortment for each pilot outlet was defined using XYZ classification and based on sales frequency. Instead of spending too much time in advance defining the model, the team decided on an early test of the first model in tandem with Vianor’s front line staff, and then to modify it according to the feedback.
When the pilot started, the outlets were generally happy, but quickly noticed that there were some customer requests that needed to be ordered even though they were not in the assortment. Together with RELEX, it was agreed that introducing a new order model would be the best way to handle this. The solution was implemented within a couple of days, and quickly tested with the pilot outlets. After positive feedback the solution became an integral part of the new model.
In the late pilot, more and more outlets were already using the new system for replenishment. Then it was noticed that the model actually worked better for larger outlets, which received a comprehensive assortment. On the other hand, smaller outlets found they needed a slightly wider assortment. Again the teams made some quick changes to the system calculations, tested them the next day, and then introduced them into to pilot. The changes were well received and were retained in the model.
The two challenges that Vianor faced are both very common in business process development. You can only really see the impact of a routine after you have implemented it. Therefore it’s vital that there’s sufficient inbuilt flexibility to allow you to adjust the operating model after piloting each new approach.
With RELEX, Vianor has been able to reduce its peak inventories by 30 percent without any adverse impact on availability. Logistics Manager Markus Huttunen from Vianor has been won over by RELEX’s agile process development model:
“The implementation project was incredibly fluent and all the challenges we faced were solved basically within 24 hours – even completely new functions were introduced in just a few days. The most challenging part of the project was to define what we really needed, and thanks to their supply chain expertise, the RELEX team was able to help us a lot in achieving our goals efficiently.”
How to Proceed
If you are thinking of buying a new software system there are some key points which you might like to bear in mind. It is quite likely that your processes will change over time. And it is almost certain that your thoughts about your actual needs will evolve as you use the system over a period of time. Knowing that you might want to ask yourself whether you wouldn’t be better off with a system that you can configure to match your needs yourself without having to start a new software project.
t RELEX, we don’t charge a license fee before a client has had a chance, during the pilot phase, to make sure that the software actually supports the target processes and that there is a business case to continue using it. Since our pay day only comes when these goals are achieved, we have a vested interest in doing everything we can to deliver the best possible solution. That’s why we make client’s problems our problems.
If you are interested knowing how to get this kind of system to support your replenishment and forecasting process, contact us via the form below.
About Vianor
Vianor Tire & Auto Service is part of the Nokian Tyres owned network of Vianor service centers spanning 1,400 outlets in 27 countries. Vianor is a combination of the Latin words Via Nor that mean Northern Road. The Vianor network is far reaching and comprises the largest chain of tire stores in the Nordic countries.
Read more: vianor.com
