Designing the problem before the solution
In this PIM project, the API work became simple only after the team had agreed on the business problems and tested a future data model with users.
- Discipline
- Business Analysis
- Type
- Anonymised professional work
Overview
The project was presented as a PIM implementation with integrations between SAP, Akeneo and downstream systems. I expected the difficult part to be mappings and APIs.
It was not. The most time-consuming questions came earlier: what exactly did a SKU represent, which variants were genuinely different, and which parts of the current workflow should be carried into the new system? Once those questions were settled, the technical implementation was relatively direct.
Context
Several departments worked with the same catalogue but used it for different purposes. Marketing, Product, IT and the data specialists did not always group or name products in the same way. In SAP, one SKU definition could cover several business variants, including a few exceptional cases that were difficult to model consistently.
Copying the existing structure into the PIM would have preserved the ambiguity. The project therefore needed to define a future model, not only migrate the current one.
Our consulting team was small: one project manager, one senior PIM consultant and two business analysts. On the client side, the workshops included the people who actually made or used the relevant decisions.
Defining the problem
The client did not arrive with a neat list of validated pain points. People described inconveniences: repeated manual updates, confusing attributes, awkward product creation and information that was difficult to trust.
After each workshop, we reviewed those observations internally. We tried to separate three things:
- a genuine business pain point;
- a limitation inherited from the current tools;
- a habit that was inconvenient but not worth redesigning the model around.
We returned to the next workshop with that interpretation and asked the client to challenge it. This loop mattered. It prevented us from converting every complaint directly into a requirement.
Making decisions
The useful participants changed with the question. Data definitions needed the people who knew the catalogue history; future workflows needed Product and Marketing; feasibility needed IT and the PIM consultant.
No single group could define the model alone. The customer held the business and historical knowledge; the consulting team brought analysis and platform expertise. Decisions became reliable when those perspectives met around a specific question.
Validating decisions
We did not validate the model only through diagrams or specifications. Once a direction was clear enough, the senior consultant configured it in the Akeneo development environment.
The client then used it. Future users created products, changed attributes and followed the proposed workflow themselves. This produced much better feedback than a demonstration. A workflow can look convincing while someone else presents it and still feel awkward when you have to perform it.
Some configurations confirmed the model. Others exposed assumptions we had not noticed in the workshop. We adjusted the model and repeated the exercise.
Outcome
By the time the API work started, the difficult business decisions had already been made. The mappings referred to concepts that the teams understood in the same way, and validation rules followed from definitions that had been tested with users.
The APIs were not trivial, but they were no longer being asked to compensate for an unclear model.
Perspective
I used to think of an integration mainly as a contract between systems. This project made the organisational part much more visible to me.
Systems can exchange technically valid data while the teams behind them disagree about its meaning. In that situation, a successful API call proves very little.
The most useful work in this project happened before implementation: turning inconveniences into validated problems, agreeing on a shared model and letting users test that model while it was still inexpensive to change.
Key takeaway
The API became straightforward because the organisation had already done the harder work of agreeing on what the data meant.