Size matters
After several years of intralogistics operation and 6 years in intralogistics projects I came to the conclusion that I'd like to do something different.
In 2012 there was an opportunity to join a customer in the role of a solution owner for the application which handles all kind of packaging information.
I thought three things:
- That sounds like an interesting variety
- In intralogistics I struggled a lot with incorrect pallet dimensions, that's something I'd like to fix.
- Well, its a box, it has a length a width and a height... how hard can it be?
With two out of three I was right the third I learned the hard way.
Where it started
When I started this assignment, the planned task did not have any development focus. The project which delivered a new tool including ways of working, RACI model and education material was just completed.
The task was to receive this tool from the project into the line organisation, build up competence and maintain the application.
Within that new application the complete set of packaging requirements was handled. For the customer this meant that it was deeply anchored in the range development process.
A simple example: If you plan to sell 100 pieces of a new article per month it is important to know if 100 pieces represent in the supply chain one small box or a complete container. Whithout that knowledge it is impossible to calculate the preliminary sales price.
At the same time the application handled as well the confirmation of those requirements and registration of further details regarding packaging which were done by the suppliers.
Those two different processes have to a huge extend different lifecylces and different stakeholders which resulted in a highly complex versioning for the different packaging configurations. And that was the point where the problem started which did not get solved by project.
The operation unit which receives a certain pallet expected of course to get the correct weight and dimensions but for the same article these changed over the time, depending on the quality of the raw material for a specific production batch but as well even depending on the weather. Especially products made of materials like textiles or plywood change the weight quite a lot based on the air humidity.
But when you pay the trade tariffs in some countries by weight you want to be precise and don't want to change you import notifications based on the weather forecast.
Most of that and a lot more about things like different waste disposal regulations, cardboard qualities and environmental friendly alternative for EPS I learned during the first few month of the new assignment from 3 wunderful colleagues, which took the task to onboard the newbie who had some experience in IT related project work and things like that but absolutely no subject matter expertise.
During this intense learning phase I started as well a lot of investigation to figure out why this entire things was perceived as quite OK on the design and production units but as a total mess in the supply chain from transport via warehousing until the retail and last mile delivery units.
Identifying the problem
The initial investigations showed quickly that that data in the application was reliable (except a still quite high share of measurement mistakes)
but that this data die not make it to the operational units. The first immediate action taken was to create simple and quick excel templates for the Suppliers to be used when they do the measurements.
Those Templates contained exact descriptions of what and how to measure. They were made available in multilingual, so that the suppliers around the world were able to use the same templates . During the first three month the customers purchase organisation was asked to have a close look at those templates and how they are used on site at the supplier whenever they performed site visits. That helped in a quick and lean way to improve the measurements as such and avoided mixing up things like Length with Hight or inches with cm.
The bigger problem still remained. No matter how good the quality was inside the application, it was useless if we would not manage to get the correct data out in the world as well. A detailed analysis of the integration concept was performed and showed clearly where the problem was located. To avoid too much manual work the application came with a highly complex "mapping logic" which identified which packaging record was supposed to be valid for which receiver at which point in time. This logic was based on leed times and the supply matrix. Unfortunately, both were "only" plans and reality tends to ignore any plan. So in case a certain article was stored for a longer time in a Distribution Center because it did not sell as good as planned this resulted in an older pallet being delivered from that distribution center than expected according to the plan and that resulted in faulty measurement values.
The first idea was to consider the production dates of the actual stock in the supply chain for the forecast calculation but that showed to result in an unacceptable high complexity. At that time the comparably small range of appr. 25.000 articles at the customer resulted already in 180 million packing records being created to reflect the sender - receiver -time horizon relation for every article on every potential supply path for every potential receiver. This was recalculated every day and we hat to invest at that time already quite massively in hardware since the batches which did that calculation struggled to complete before they had to start again. The re-calculation took at that time aound 20 hours and was supposed to be re-done every 24 hours.
The first and obvious suggestion to simplify this by having fewer packaging records simply by giving strict requirements to the suppliers was - as expected - not accepted by the customer since it contradicted the way how they work with supplier development and range development. On a very high level this is driven by high quality on the product and the availability for a low price which is reachable only giving a lot of freedom and tolerances to the supplier in other areas like for example packaging.
The second suggestion was accepted and led to a huge IT development initiative which had impact across many different parts of the organisation and was time estimated to take 2 years untill fully implemented.
Fixing
The approach for the fix was simple "The data follows the goods". But simple does not mean simple to implement.
- The supplier has to confirm which packaging configuration was shipped on pallet level. Meaning we had to implement the unique identifier for a specific configuration in the ERP systems for ALL suppliers.
- This unique identifier had to be connected to the SSCC number on Dispatch, so it was needed to implement it as well in the transport management system(s).
- During inbound the same identifier had to be considered in the ERP systems of the different business unit types where it had to be considered mainly in the warehousing modules for processes like stock in or in the box calculation for customer order parcels.
- Next to the continuous transfer of the identifier all systems which are interested into any packaging information had to integrate to the "main data" interfaces as well from which they could then pick the information they are interested in based on the individual identifier.
On top of the exact and detailed information there was as also a need to serve the information on a higher aggregated level.
While the same article on 4 different pallets could have 4 slightly different weights, the web page where the retail customer shops, needed to present one figure only.
We identified the need for two different levels of aggregation and decided that it should be the application that owns the raw data, which should provide as well the aggregation, not the receiving systems which are the business owners of the aggregation rules. This approach is a bit uncommon and not fully correct from an ownership perspective, but it simplified the technical integration and especially the maintenance of the according business rules a lot.
How
Especially something like the above is difficult to sell in an organisation since it costs a lot of time and quite a bit of money, but from an organisation perspective you "only" correct a faulty parameter. No new applications or screens, no new processes, only a slow improvement of data quality over time. So I was very lucky to be able to form a fabulouse team around me and only the great coorperation allowed us to deliver this change.
The service level and business development teams for the application were sources to an external vendor and the entire team was located in India. The first step was to ensure that we get a very good and close collaboration with those people. We agreed upon having one member from each of the two teams always on side in our office in Germany. Those stayed for 3 to 4 month until they were exchanged with the next team member. Next to that we visited the vendor in Noida every 6 Month. By this we managed to get our external teammates connected. They saw us as colleagues and not as "the customer" anymore such a relationship is absolutely needed to be able to discuss problems and questions.
Together with my IT application architect we managed to convince enterprise architecture that our approach is worth a try even though we basically changed the status of packaging information from being master data to being operational data which was a big thing.
The solution owner of the transport management system and packaging responsible from the global purchase organisation supported a lot in the needed changes at suppliers and distribution.
Even though I learned a lot during that time about "Common Information and Exchange Models", about entity relation models, and event based communication as well as the totally different area of vendor management and budgeting processes, the most important lesson was mainly a confirmation of something I knew before already.
It is all about the team. To take all those individuals one by one and form a team where everyone respects the other and where everyone can rely on every teammate was the key success criteria for this project.
The same was as well the reason for the failure of the first try. The original project delivered a good tool, but they did not consider the receiver of the data good enough.
After 5 years in this area I felt like "want to go home" and looked again for opportunities in the intralogistics.