The Supply Chain Planning System is a source of knowledge about all flows of goods that take place or should take place in your organization.
Aborigines, however, say that knowledge is noise until it enters the muscles. Or else, the overabundance of information is just a distraction. Only the implementation of knowledge determines the success of each tribe.
If you do not know yet if and what IT system is needed in your company, read my previous article – How to chose a supply chain planning system? and go crazy.
However, if you know what you want to achieve, but you are wondering how to run a project, read on. Below I present a number of good practices that will work at the interface between the Supply Chain, Logistics and IT. Even if you are not operating in Australia.
CREATE THE RIGHT TEAM
A good team is the basis for the success of any project. A good team consists of both people selected from the Supply Chain (functional experts) and people responsible for the software.
On the one hand, the operational experience cannot be overestimated in working on new solutions. Only someone who has worked in a given area on a daily basis is capable of having a system in the Supply Chain.
On the other hand, the implementation of a new solution requires a lot of technical knowledge and an analytical “side view” of the processes to be automated.
Therefore, more and more often the so-called DevOps teams, i.e. combining the functions of development, implementation and maintenance of systems.
When working with such a diverse team, it is important to respect the experiences and skills of individual people. Otherwise, a team with theoretically perfect competences will not deliver the result.
Respect you team. Your team can literally make you or break you.
– Jennifer Bridges, Director www.projectmanager.com
It is equally important to appoint, for example, informal leaders for individual areas of the project. Project Manager cannot and should not run the project alone. First, he never has all the knowledge he needs. Second, it would not be effective.
Selecting team members, managing the relationship between them and making them feel personally the owner of the system being implemented is at the heart of the project manager’s job.
Apart from the direct team members, the mentoring role of the project manager is often forgotten and has a significant impact on the success of the entire project.
It’s good for a mentor to be someone who has some experience in running projects. Nevertheless, the most important qualification of a mentor is knowledge of the organization, its processes and, above all, the culture and people working in it.
In addition, a mentor should have a number of soft qualities and skills. I found an interesting infographic summarizing these features on The Engineered Lifestyles portal.
The mentor does not have to be a board member, director or senior manager who is also the sponsor of the project. On the contrary, a mentor should be a person who can support the project manager on an ongoing basis.
During the stage devoted to creating a project team, it is also necessary to ensure that people from different departments in the organization and on the part of the software supplier are in harmony with each other.
Especially in projects that require a lot of commitment, it is necessary to organize an informal dinner or other social activity that will allow you to “break the ice” and get to know each other.
Neglecting this step of team formation affects the later stages of the work. People who have not worked together so far and do not feel part of something new less often take responsibility for the entire implementation.
They also less frequently become ambassadors of the new system in their home teams after the end of the project.
However, without such an approach in the team, the chances of successfully completing the project drop drastically.
EXPLAIN THE SCOPE TO EVERYBODY
If you have completed and put together the project team, the next step should be to present the scope of the project to all interested parties.
The scope of the project means both the functional area covered by the works, and the expected time and cost of implementation.
By contrast, “all concerned” means both stakeholders inside and outside your organization. It covers literally everyone whose work or performance will be affected by planned changes to the Supply Chain.
Typically this includes project sponsors, sales teams, and a logistics or operations team.
However, at this stage, if you are in doubt about whether to inform someone about the project’s foreseen results, it is best to assume that you should.
Nobody. Never. In no project. He has not yet said that he regrets the time it takes to show others what to expect.
Communication at this stage allows both to avoid surprising sponsors at the end of the project and to limit the stretching of the scope of the project when it is the most expensive.
Scope creep: the ever present danger in any project where you keep adding requirements and objectives until the whole thing become unruly mess that you can’t deliver on.
– Brain Westfall, Senior Analyst, Gartner Company
Believe me, you really don’t want to discover at the end of the project that the Commercial Director as “automate orders” understands also the calculation of the amount of rebates and not just the required volumes.
You also don’t want to raise the project budget and extend its duration at the end of the design work, because you have to include features that were not originally included in the specification.
Therefore, in particular, inform everyone that is not included in the scope of the project and collect everything that has been confirmed in one document.
SET (QUANTITATIVELY) TARGETS & MILESTONES
Implementing a system in the Supply Chain is a project. Therefore, you should have specific and time-bound goals.
Typically, the overriding goal is to match the supply chain capabilities with the needs of the rest of the organization, or to ensure continuity of operations with the growing scale of the business.
However, in order to undoubtedly confirm whether the implementation was successful at the end of the project, it is necessary to define what quantitative indicators will answer this question.
Most often, depending on business, 2-3 of the following functional measures are used:
- the level of customer order fulfillment
- in store (or on shelf) product availability
- the accuracy of the demand forecasts
- the overall level of inventory rotation
- obsolete and redundant stock share
- gross inventory losses
When assessing the implementation results, cross-sectional indicators such as logistics costs versus sales or the cash-to-cash cycle should not be used.
These types of cross-functional measures are of great importance for assessing the effectiveness of the entire company. However, by definition, they depend on the operation of many functions. So they do not help in analyzing how the system works in the supply chain.
After confirming the indicators, it is also worth writing down the method of calculating each of them and specifying the reference period against which we will measure the differences.
If you can not describe quantitatively what you are doing as a process, you do not know what you are doing.
– W. Edward Deming, The American Who Taught Japanese About Quality
Many companies calculate supply chain metrics differently. Therefore, any differences in the understanding of the selected measures are best explained with the software vendor at the stage of setting goals.
In addition to setting clearly defined implementation goals, the project manager should also define major milestones at this stage.
It is not about a detailed project plan yet. The time for that will come later when project sponsors and stakeholders confirm the overall direction of the work.
Previously, milestones were a way to break down work into manageable phases from the perspective of a person without expert knowledge.
When implementing supply chain systems, the following list of milestones can be adopted:
- established data sources
- created process maps for:
- demand forecasting
- supply planning
- distribution
- discrepancies list created
- required interfaces mapped
- technical infrastructure available
- all system modules installed
- system tests completed
- acceptance of key users
However, it should be remembered that the milestones will be different in each project. They will depend on the scope of the modules being implemented, the design methodology, and the technical architecture of the selected system.
HOW TO GO THROUGH THE TECHNICAL MEANDERS?
You don’t need to be a systems architect to run an implementation project. You also do not need to have a degree in computer science.
However, it is worth knowing about a few key issues and consciously choosing between alternative approaches.
First of all, before starting the implementation, check with the selected software vendor whether the required basic data is available.
If the quality of the master data does not meet the requirements, or even worse, not all the necessary data is collected, this is the last moment to make changes.
Master data management is neglected in many organizations. Errors at this stage, however, translate as a domino effect on the results of the entire project.
Few people understand how many projects fail due to the lack of relevant data.
– Mikre Ferguson, Managing Director, Intelligent Business Strategies
Second, the choice of a technical system architecture is a business decision that cannot be left to IT alone. The most important decision in terms of architecture will be whether you decide to deploy locally or in the cloud.
Cloud-based systems are maintained on the provider’s servers and available to users via web browsers. Locally implemented systems (the so-called on premise) are installed on computers and servers belonging to the company.
Some vendors also offer hybrid deployment where the cloud is “private”. In other words hosted locally on the organization’s servers. Most of them offer the possibility of implementation in both of these ways.
You can find a detailed overview of the differences between on-premise and cloud based approaches, as well as a description of the advantages and disadvantages of each, on the Software Advice portal.
The most important thing from the business point of view, however, is that cloud solutions translate primarily into operating expenses. On the other hand, the solution installed on own servers is a capital expenditure.
In addition, cloud solutions are used in many organizations at the same time and as such require greater standardization, but are updated much faster.
Locally implemented systems, on the other hand, provide greater possibilities of adapting the process to a given organization, but they change much more slowly.
To decide what architecture a system in the Supply Chain should be based on, you need to ask yourself a few questions:
- do we expect results quickly (cloud)
- do we want to manage the data ourselves (on premise)
- how standard is our planning (cloud)
- how we want to control the process (on premise)
Each subsequent, more detailed technical decision should also be in harmony with the way a given business is run and be subject to similar verification on the basis of non-technical questions.
WHICH APPROACH TO IMPLEMENTATION SHOULD I CHOOSE?
The most common approaches to implementing IT systems today are the iterative approach and the incremental approach. Both belong to the so-called agile design methods.
The iterative approach means gradual development and adaptation to the requirements of subsequent elements of the system. The aim of this approach is to deliver a working, but still incomplete system as soon as possible.
To better illustrate what the iterative approach means, I will use an analogy from the Agile247 website. The iterative approach can be compared to sculpting as follows.
When we implement a system in the Supply Chain, the iterative approach means implementing the standard offered by the supplier first. Then, the gradual adaptation of the system to the specific needs of a given organization.
As a result of using an iterative approach to implementation, several business benefits can be noted:
- receiving a comprehensive (albeit standard) solution earlier
- faster return on investment than with other approaches
- learning by the entire team at the same time.
The incremental approach, on the other hand, means adding separate fragments to a working system that are part of a larger planned whole. Using the sculptural analogy again, the incremental approach can be illustrated as the following process.
With regard to the implementation of the system in the supply chain, the incremental approach may mean first the implementation of the demand planning module, then the distribution module, and then the other related to inventory optimization.
The incremental approach has two positive outcomes from a business point of view:
- receiving partial information about the results of the implementation during the project
- introducing complete parts of the system earlier than in the iterative approach
You can read more about the potential benefits and dangers of using each approach in the article published on Agile247.
However, which approach is the best to choose in implementations for the needs of the Supply Chain?
If your organization already has a set of solutions that the Supply Chain uses, an incremental approach is probably a better solution. In this case, the project consists of adding more elements to an already functioning environment. In a way, it’s about digital evolution.
If, on the other hand, you are at the stage of implementing the first complete set of Supply Chain solutions. It is probably better to opt for an iterative approach. In this case, we can speak of a digital revolution in the supply chain.
HOW TO START… WITHOUT FALSTART?
Assume that the design work went as planned, the system in the Supply Chain has been installed, tested and the results confirmed by key users.
So what to fear? Why not just take off on a large scale?
In practice, everything is still possible at this stage. You can really see that knowledge is noise before it enters the muscles. Our new system is still just theory. When confronted with real data, real-time changes, with many simultaneous users, unforeseen interactions and errors can occur that will critically affect the business.
Unfortunately, the American chocolate manufacturer – Hershey – was painfully convinced of it. Hershey’s board of directors has decided to accelerate the work to complete the rollout before the significant Halloween season for chocolate makers. So the design team limited the testing phase and set new shorter deadlines.
[back then] it was a terrifying new prospect for investors to consider: Could a failed computer project take down a Fortune 500 company?
– Christopher Koch, Editor & Research Analyst, www.cio.com
As a result, the system was launched before Halloween. However, despite adequate inventories, Hershey’s Supply Chain was unable to fulfill orders worth nearly $ 100 million due to system failures.
This translated into a 19% drop in Q4 earnings and an 8% drop in Hershey’s share prices at the end of the year. You can read more about this in the PEMECO Consulting analysis.
Therefore, the best practice is to start slowly. Choose a “piece of business” where you can test the real process before it goes full steam ahead. Depending on the type and structure of the organization, it may make sense to choose:
- product categories from one factory, in manufacturing companies
- a small list of branches or shops in the case of retail chains
- a limited group of customers, in the case of service companies
At the same time, at the end of the project, as at its beginning, all stakeholders should be informed about what will happen. At this stage, the list of interested persons should also include our Customers and Suppliers.
This will allow you to manage change during the design work, not after the implementation is completed, and to prepare or update standard operating procedures.
If supply chain had an arch enemy it would be called “Bad Communication”.
– www.EverythingSupplyChain.com
Tests on a selected range of products, stores or customers must last at least 3 planning periods. In case everything goes as expected. Otherwise, the tests should be extended by the time for changes to the system settings.
Extending the testing period may also be necessary if your organization plans in cycles of less than a month. The 3 planning cycles will then simply not be sufficient to analyze the results obtained.
If our “battle reconnaissance” went well, it is finally time to change other areas of the organization, document the experience gained and celebrate the successful project!
INSTEAD OF ENDING
Supply Chain Management has undergone great changes in recent years. The digital transformation in this area has begun.
Never before have the success or failure of manufacturing and commercial organizations been so dependent on supply chain excellence. Perfection that cannot be achieved using the old systems (the so-called legacy solutions).
That is why so many companies are leading, or will soon be leading, the implementation of new solutions and are looking for leaders with new skills.
Conducting projects in cooperation with IT is one of the sought-after features of a modern leader. However, the ability to manage change and develop team competencies remain the most important skills in the Supply Chain.
The issues of the competences of the Supply Chain Director (or more and more often the Chief Supply Chain Officer). However, I will publish an article on this topic later.
For the time being if you found this article interesting, inspirational, or just helpful, please share it. Also, don’t hesitate to connect with me. The most efficient way is by subscribing to the newsletter. You will be always on top what I publish on the blog and receive additional informations not available here.
I hope we will see each other next time. I publish regularly every second Saturday.
2 Comments