Once again paper is to be eliminated
When the drone project came to en end I started to look into next oportunities. And in September 2021 I got the offer to join in a new team which just started to be be build up.
As mentioned before I always like the option to be part of an initiative from the beginning on and since this sounded interesting I joined.
It turned out to become a much longer assignment than expected.
(actually it contiued until Dez 2025)
Background
The specific process which was wished to be digitilized is a bit special, so I need to explain it.
The Customer has a salesfloor with defined sales locations. Each article can be located in one or several of such locations. Each article in a location has an order point and a maximum stock and the same goes for the article in total.
Since customers pick the goods directly from such locations the customer never knows exactly the stock per location, so the ordering is based on the total figures for the article.
On top of that uncertainty there is an additional factor of "overfilling" which complicates the internal refill process. The overfilling is caused by an additional quantity whihc is calculated in the system and added on top of the maximum stock for the article.
The Idea is based on the fact that there are always articles in the surrounding of the to be refilled article which are close to the order point, meaning those do not utilize the complete space given to them. In the end this results in two things to be considered during the refilling:
- How much stock should be send to which location?
- How much stock shall be "overfilled" per location?
These two questions are decided the day before the actual refilling takes place. Sales is supposed to "prepare" the sales locations and to driect the stock accordingly. While the logistics department performs the actual refilling the next morning based on those instructions.
Even though this is a bit complex process for the last few meters of the replenishment it enables the company in total to have a very efficient supply chain, to merchandise a lot of volume on a limited footprint and to present the department to their customers always as "full". Meaning, there is no empty spot because of low stock of yellow napkins because it gets filled instead by blue and the next day it is the other way around.
The problem was the list of articles to be refilled the next morning was available only on Power BI report which got printed and handed over to sales. Sales left notes on the print out and if additional actions were needed in exceptional cases they hat to contact logistics by phone or mail to explain the problem and order more or less stock then suggested on the list.
This very paper based and manual process caused a lot of misunderstandings, mistakes and back and forth communication., so it was supposed to be digitilized to became aligned and traceable.
Preconditions
The currently existing WHM system which handles the calculations for the above explain "Prenotification Process" is supposed to be closed down in the close future. None of the potential successors offers any functionality close to this, but it was listed as mandatory.
So the decision was to build a tool to support this process from scratch as a stand-alone solution which can be integrated to the existing application but based on clearly defined data requierments for the integrations as well to any potential future WHM system.
A new team was established which received the task to build that piece of Sofware as a google based application. It was set up as a standard product team embedded in a bigger product organisation. The expectation was to work according to scrum and the application had to exchange information based on events via solace and run as and App on android devices or as a web page directly in a bowser.
That was it so we started on a pretty blank sheet, but added additional "must haves" very soon. Most of those were pretty obvious:
Use the existing library for FE elements used at the customer
Support the auto-translation provided by the customers translation tool
Support single sign on based on the customers framework
Life up to all requirements needed to be onboarded to the customers' existing co-worker application hub
Composing the team
very soon we started to compose our team. We manged to get 2 experianced backend developers which worked since many years in the domain and had a lot of business knowlege, but very little experiance with cloud based development.
Luckily we managed to adda full stack developer, a pure frondend speciallist and one more backend devepoer with could experiance. While the actual IT specialists in the team started some technical preparations and focused a lot on learning domain and techstck from each other I took the role of a product specialist and worked together with our new UX / UI designer.
And get started
With the support of the designer I started the UX reserch with several user servais and interviews on site to get a better idea of the main functionallities which are in place today and needed, plus the main pain pionts they are struggling with in todays paper solution.
Based on those interviews we built a first clickable Figma Prototype which we used for a second round of verification with the future users.
In paralel I did a data nalysis to figure out which data is currently used in the existing WHM system to perform the calculations. Witht he support of an enterprise architecht responsible for our area we identified the source systems from which our new application should receive the needed information.
Once that was in place the development started with creating the first tables and populating them by getting the first integration in place.
Iterate and grow
Since the majority of the needed data was available now and a good idea of the needs for the UI existed as well our great team managed to get a first prototype versionr eady very soon and we used it for verification in a first test store.
Since this new application was a stand allone module we were in the very luxurious situation that we were were able to turn it on and off in operational units for testing and verification as often as wished. We even found stores where only few interested users wused the new prototype and the rest continued with the old paper solution. This enabled us to work very iterative and to improve both perspectives, the UI as well as the calculations in the backend, rapidly.
A lot of the feedback we received pointed towards missing information. This is a typical habit which I have seen a lot in different projects and which tends to lead to an application which is heavily overloaded with information objects which are needed to handle specific exceptions only. The drawback is that the normal happy flow becomes more and more difficult to handle due to the overload with useless information. A mobile screen is small and to keep it simple for the many it needs to be clean.
Still feedback is appreciated and none of us felt like telling or engaged test community "testers" that their input is not relevant.
So we split it up into:
- Needed
- Needed for specialist during problem solving
- Out of scope (for now)
A plan was created how to introduce a "problem investigation flow" which was supposed to be kept outside of the main screen(s).
The information identified as "Needed" was integrated and included in the screens as fast as possible.
At the same time we started to create events and onboard those to the customers dataplatform to support already very early in the process a first reporting prototype which was supposed to allow us to provide more concrete benefit results.
Additional integrations (incomming and outgoing) additional calculations and frequent improvements on the front end forced us to let the team grow, especially when we reached the point where the application started to have a direct impact on the refilling of the sales locations and the connected ordering process.
Once we reached 15 people we had to realise that this is too big for a scrum team, so we split the team up in two "sub teams" where the daily work was done inside the individual sub teams and only monthly alignment meetings were done in the big team.
We started at the same time the roll out and the workload for our product owner who was at that time responsible for 2 more teams became that high that I took the role of the "acting PO" for our new application.
Organize
The roll out increased - like expected - the workload a lot. Start up sessions with each individual country completed by a follow-up and Q&A session. We established a global chat with representatives form every country and every store which went life. Even though that took a lot of our time in the beginning it payed back after a short time.
On one side we were able to build based on that chat very quickly a detailed Q&A file, on the other isde we saw more and more that stores and countries started to support each other.
At the same time the team insisted more more and more that the two week sprints are to short and that they would like to stop working according to scrum. Since the scrum approach has its benefits especially for the receiver of the deliveries and the stakeholders we first increased the sprint length from 2 to 3 weeks. After 3 month it showed that the team was still not happy and they expressed their wish to change to Kanban.
Especially in teams which are anyway a bit too big and with increasing complexity my experiance with Kanban was not the best.
Based on that we agreed on keeping some of the Scrum elements but organizing the Work in a Kanban board with this approach close to the Scrumban we managed to organise the work in a good way reduce the administrative overhead and still deliver new features or fixes in a good pace.
In general it is never a good idea to stick to one Methodology for the sole reason that this is how one started or how most teams in the company work or anything like that. I am a certified Scrum Master and Product Owner and I try to use scrum when possible, since I think it is a great framework, but in the end it is the main task to enable the team to deliver what the customer needs and that needs in most cases situational adjustments to the ways of working.
Complex core functionalities - like in our case for example the calculations - are always good to be done with a grain of XP to ensure that several people in the team understand them and that mistakes are identified by early testing.
The meeting structure should not be driven by "Scrum requests a daily!", but by factors like co-located teams or remote teams. Co-located people tend to talk anyway to each other where remote teams might need especially in the beginning a more structured approach.
One of the key success criteria I have learned during devlopment projects is the very close colaboration with the customer. Not only to keep them informed about the progress, but as well to have permanent reality checks to verify what is needed and what not. Always avoid "we might need this" features, most of the time you won't need them. And only the close collaboration puts the team in the position to ask "are you sure?" instead of becoming a feature factory with higher output than outcome.
The journey continues
The customer is undergoing a bigger change. next to our small piece there are several other smaller and bigger initiatives running which are all more or less close connected to the internal logistics operation. One of those is the replacing of the internally developed ERP system by a bought WHM system. The mared research has been completed a vedor has been selected and a first pilot is about to start. Since that WHM is lacking any kind of prognosis system for the next day our small application has been listed as a mandatory pre-condition for that new WHM system. Since we have reached by now a state where the outcome from our Prenotification tool is a fundamental base for the ordering we need to undertand how ordering works in this new tool and how to channel our data into that process.
What our tool provides does unfortunately not fit out of the box into that WHM system. Our outcome is a specific quantity of a specific article to be refilled in a specific location. What that tool wants as an input is minimum, maximum and current stock of a specific article in a specific location. based on that they calculate the refill quantities on there own. Those two approaches contradict a bit since the WHM approach does not consider the user input which is the core element of our tool.
The biggest challenge was - like often - to agree on the approach. This time this got even more difficult due to the scattered knowledge base. The WHM Vendor is the only one really understanding the WHM System our team is the only one really knowing our application and the customer of both had problems to draw a picture of the wished position. Several on site sessions where everyone met on the shopfloor and discussed pros and cons we came to a conclusion for a first test.
A bit of adjustments are needed in both applications, but after some iterations with heavy testing a try out version was ready in time for a pilot, even though it contained several "excel-hacks".
This is another thing I learned to appreciate a lot during the years. Try to visualise the data and the integration steps. Extract from one application import to the next, in between look at the data. For an IT-engineer this might sound awkward, but for the customer this is a great step to learn and understand what will happen in the future and to decide if this is really what is intended.
After 4 Weeks of frequent adjustments on both sides the pilot of the new WHM system is now fully operation with our prenotification tool.
Most things remain to be (re-)done...
The prenotification tool is deplaoed in all countries in at least one instance and in total in appr. 250 stores. Even though we had to optimize several Querries and increase the amount of POTs, CPUs and RAM a bit it still runs comparably cheap on only one instance on GCP. Even the stores in China are connected to GCP, like mentioned on other projects the thorough analysis of legal requirements and open collaboration with stakeholders and authorities saved us from deploying a separate instance on Ali Cloud. Only a very limited amount of data without any traceble user connection is sent back and forth through he "Great Firewall". Time needs to show if this connection is reliable and performant enough to be used for a still growing market, but for now it is a great option and the learnings might become usefull for other projects.
The new WHM system is progressing slower than expected. It works in many ways completely different then what the stores are used to and some aspects of a WHM system are hard to map to a none warehouse environment. but the customer is aware of this and to some extend the needed changes in Ways of working are wished. Luckily the integration with our prnotification toll is quite stable by now and the cases where we stumble about problems are getting more and more exceptional.
After four years building up and rolling out the prenotification tool, supporting in piloting and data analysis for the new WHM tool, and building a separate "Goods movement application" which was put on hold due to the new WHM tool, my time in this project comes to an end.
There remains a lot of work to be done to optimize the forecasts on sales location level and to include exceptional flows in the frontend without disturbing the happy flow. We have as well several use cases which were discussed but not realized up till now, but we have put a very solid foundation which is very appreciated by the user community and even more important, we built a very strong and divers team with a huge variety of skills and personalities. If my customer manages in a challenging global environment to keep good leadership and a strong vision, I am sure this fabulous team will continue to deliver countable outcome and real business value.