In this series of interviews, we talk to employees of E. Breuninger GmbH & Co. about the joint project of the multi-channel warehouse in Sachsenheim. In the second part of the interview series, we talk to Goran Zukolo, Lead Product Owner and Domain Architect for the logistics area, who provides an insight into the collaboration from his professional perspective.
What is your position at Breuninger and what tasks does it involve?
My name is Goran Zukolo. I am a domain architect at Breuninger and responsible for the logistics domain. I advance various topics at a strategic level and create concepts that take into account the many dependencies so that everything interlocks smoothly.
What background do you need as a domain architect?
I think a technical background definitely helps. Personally, I started out in software development, which is where I spent my first years in the job. Later, I broadened my horizons in other directions. As a domain architect, I need a very in-depth knowledge of logistics and of Breuninger as a company. These are two interdependent things. In our particular case, there are many special features that you need to be aware of to make everything work.
So does your role have a kind of interface function?
Definitely, between the business owner and the technology.
When and how did you get involved in the project?
I got involved in the project quite early on, in 2016. But that’s also because it wasn’t just an infrastructure project, of course. At that time, I was responsible for the software that controlled the e-commerce logistics. Another colleague was responsible for B2B logistics, and we were both given the task of participating in the project at a very early stage to ensure that everything we had in mind for the distribution center in Sachsenheim was also implemented within the software.
Can you briefly describe the B2C and B2B logistics? What was the initial situation?
We had clearly separated the areas. The only point of overlap was the incoming goods department, that is, where the new goods were delivered. Parcels were unpacked in order to be forwarded and processed later in e-commerce logistics or for the stores, each according to their own specifications.
The subsequent processes, such as outbound, were completely separate. These were managed by separate warehouses. My main task was to increase the efficiency of outbound and all associated processes at the old locations, where the goods for consumers were stored and processed, so that they could support our growth accordingly.
As a result, I gained a great deal of knowledge about our e-commerce process.
Which is a good segue to your expectations regarding the collaboration with TUP.
My expectation regarding the collaboration was that we would be able to approach topics in an agile way, because that was what we, as a company, knew and wanted.
Agility was also important to us in order to gain experience early on and then be able to initiate the improvement process. During the selection process, I got the impression that TUP was willing to adopt our agile approach.
Can you give us an example to illustrate this agile implementation? As I understand it, you wanted to move away from “task one, then task two” and towards a parallel process.
Exactly. A lot of things were developed in parallel, but at some point you have to use your resources in such a way that you can test them step by step. For example, we received individual modules from TUP very early on and were able to start testing them immediately. In principle, we were already refining it from that point on. Often, if we are honest, a concept can be outdated a year later. New situations can also arise from company development or external factors, which can shift the focus. The way we worked with TUP also proved effective in these cases.
How was the collaboration with us on a professional and personal level?
I have to say, it was consistently positive. This became apparent to us early on in the partner selection process. TUP was a partner who not only appeared competent, but proved to be so.
I always enjoyed working with them and was also on site in Stutensee once a week during the project phase to work with TUP colleagues on the design. Those days were a lot of fun.
In my opinion, the partnership can be highlighted as a really positive aspect. This is also reflected in the stability of the team, which has been maintained and still consists largely of the same people.
The team on site will be very happy to hear that! This brings me to the topics of availability, response time and quality of cooperation.
In terms of availability: From the very beginning, we had a stable team that worked almost exclusively for us, which is of course an advantage.
In terms of response speed, we were in constant dialog, talking to each other and moving things forward practically every day. I think that speaks for itself. The quality was always good, too. Mistakes happen, especially in projects of this magnitude, that’s normal. What’s important then is a good ‘error culture’ and that you treat each other with respect. That was always the case.
We have been working together for about seven years and we are still working with the same teams, even though some of them have been increased in size. I think it also speaks for us that a team of developers who have been working for the same customer for seven years still enjoy their work.
Next, we would take a look at the project: what was the target state you were aiming for and how did the actual state develop towards it?
Basically, we had a greenfield project. Many layouts were created on the drawing board and we thought a lot about how we wanted to implement all of this.
Even in this phase, we received expert advice from our TUP colleagues, who of course contributed their experience from other projects. This was very helpful to us, because Sachsenheim was a new and, above all, a unique project for us. Accordingly, we were very grateful for the extensive know-how available in Stutensee.
In this context, let’s talk about particular milestones and approaches. Is there anything that stands out in your opinion?
We had various ideas in the rough concept that we had planned but then discarded because we realized that our business had grown. This led us to reallocate space. But with the software we got, it was relatively easy to stop this customizing and use the reallocated space for other activities.
During the project, we often found ourselves in situations — due to the coronavirus and the strong focus on e-commerce — where we had to react quickly and were able to do so thanks to the software fitting like a “tailor-made suit” — to quote TUP.
Are there any things you would like to mention from your architectural perspective?
In the end, flexibility was and is the key. This is because the software is not standardized, as some offer on the market are, especially by larger software providers, who then say “This is how it is now!” We always had the opportunity to consider how a process should work in our ideal scenario and then adapt it later on the software side after a learning curve in operation. With a standard product, we would not have been able to make these changes and integrations with other systems so easily.
That brings us to the end of the project. How did you perceive the support in the after-care phase?
A lot has actually changed in the after-care phase. I think there is always a difference because “after care” means that we have transitioned to a certain daily routine. The hyper-care phase was exhausting, but important in order to work through priorities. But at some point, a daily routine set in, in which we grew much closer together as a team. We now had the time to focus more on working together and to think about how we want to work together as a team in such a “non-project mode”.
We also had the time to optimize in all directions. I think TUP also benefited from our experience regarding processes. As I said, we grew together.
Thank you for the interview.
Back to the interview overview
To the Breuninger success story