Designing Clarity
← Case studies
Decisions#PIM#API#Data Modelling#Workshop Facilitation

Before the interfaces, “product” meant three different things

SAP, Akeneo and the business teams used the same product vocabulary for different objects. The case explains the tools, then shows how definitions were designed and tested before interface work.

Concepts
Shared LanguageRepresentationFuture StateOperational Validation
Discipline
Business Analysis
Type
Anonymised professional work

Four terms before the case

This project involves enterprise software, but the underlying problem does not require specialist knowledge. Four terms are enough to follow it.

  • SAP was the client’s established enterprise system and a major source of product and material data. It also contained years of historical codes and exceptions.
  • PIM means Product Information Management: a system used to maintain product descriptions, attributes and classifications, then distribute them to websites, catalogues and other channels.
  • Akeneo is the PIM product selected for this project.
  • SKU means Stock Keeping Unit: the smallest unit managed in stock, often representing a specific colour, size or package. A SKU is not automatically the same thing as a business product.

The project was expected to connect SAP, Akeneo and several downstream systems. Before interface development began, those four terms exposed the real work.

The same word referred to different objects

Marketing, Product, data specialists and IT all used the word product. They did not always mean the same level of the catalogue. One team grouped several SKUs into one customer-facing product. Another treated each historical SAP record as a separate object. Both definitions made sense within their own work.

An interface cannot resolve that disagreement. It can only encode one version of it.

The first task was therefore to decide what product, SKU and variant meant in the future catalogue—and which historical distinctions still deserved to exist.

Evidence before requirements

Workshops produced a long list of frustrations: manual updates, attributes that nobody trusted, awkward creation steps and workarounds that had become routine.

We did not convert the list directly into requirements. After each workshop, we classified the observations as business needs, limitations of the current tools or local inconvenience. The interpretation returned to the next workshop for challenge.

This reduced the risk of rebuilding the current process inside a newer application.

Different expertise at different stages

Senior consultants concentrated on data-model design and the workshops where the difficult business boundaries had to be decided. Their role was to make conflicting definitions visible, bring edge cases to the right people and shape a model that could be tested.

Once the model was agreed, a Business Analyst configured it in the Akeneo development environment. Configuration itself did not require senior consultancy. Future users then created products, changed attributes and completed real tasks. The Business Analyst revised the configuration when those tests exposed a missing case.

Because this happened before interface development, changing a definition meant updating the model and configuration rather than reworking completed integrations.

Decision record

  1. 01

    Separate future needs from current-tool friction

    Evidence
    Manual work, low-trust attributes and routine workarounds
    Decision makers
    Catalogue users, Product, Marketing, Business Analysts and senior consultants
    How it was checked
    Return the interpreted problems to the next workshop
  2. 02

    Define product, SKU and variant

    Evidence
    Conflicting business definitions and historical SAP exceptions
    Decision makers
    Data specialists, Product, Business Analysts and data-model leads
    How it was checked
    Test definitions against real products and edge cases
  3. 03

    Test the model before developing interfaces

    Evidence
    The agreed model configured in Akeneo by a Business Analyst
    Decision makers
    Future users, Product, Marketing and the configuring Business Analyst
    How it was checked
    Complete real tasks, revise the configuration and repeat
  4. 04

    Define what the systems exchange

    Evidence
    A tested product structure and known technical constraints
    Decision makers
    IT, Business Analysts, technical consultants and delivery team
    How it was checked
    Review field mappings, validation rules and interface behaviour

What interface development inherited

By the time interface work began, the systems had a shared object to exchange. The teams no longer had to decide whether a SKU was a product while choosing the field that would carry it.

The integration still contained history and technical constraints. What it no longer contained was an unresolved organisational definition disguised as a mapping problem.