Retail systems are not hard because retail is complicated. They are hard because the unit everything hangs off is a style in a colour in a size, in a season, in a market, and every system in the estate holds a slightly different opinion about what that unit is. Fashion and apparel is the extreme case: the assortment turns over several times a year, the buy is committed months before the customer sees it, and the margin is decided by how the season is exited rather than how it was entered.
Everything downstream inherits this decision. A product master built around style with colour and size as dimensions behaves very differently from one where each variant is its own item, and the choice decides how the buy is planned, how stock is counted, how the size curve is analysed and how a size run is broken. Getting it wrong is not a configuration problem, it is a data model problem, and it surfaces later as reporting that cannot be reconciled. We design the dimension model against how your merchandising and buying teams actually think, then hold every downstream system to it.
The buy is committed long before the customer is asked. That means the system has to carry a plan by department, category and option count, an open to buy against it, and a way to see the difference between what was planned, what was committed and what has landed. Where this lives outside the platform, and it usually does, the work is either bringing it in or integrating it properly so that the merchandising plan, the purchase commitment and the finance forecast are the same numbers rather than three views that get reconciled in a meeting.
A size curve that works in one store is wrong in the next one, and a national replenishment rule flattens exactly the differences that make money. The work is configuring allocation by store cluster and size profile, setting replenishment on the lines that repeat and leaving the fashion lines to allocation, and making the rules visible to the people who own them so they can be argued with. Plus the unglamorous half: stock in transit, cross-docking and how a late delivery is re-allocated rather than pushed at whoever was next in the list.
Season end is where the margin is actually decided. The system has to hold markdown as a planned, staged activity with a price per channel and per market, with the accounting treatment of the markdown and any provision falling out of it rather than being journalled afterwards. It also has to answer what a line cost by the time it left: initial margin, achieved margin after markdown, and the terminal stock position. That is a data model question as much as a pricing one, and it is easier to design in than to retrofit.
A group that trades its own stores, sells wholesale to department stores, runs concessions inside someone else's floor and franchises in some markets is running four different commercial relationships, and they differ in who owns the stock, who takes the markdown, when revenue is recognised and what data comes back. Concession sales arrive as reported sell-through rather than as your own transactions. Franchise partners buy from you and price themselves. Each of these is an entity, pricing and revenue design question, and treating them as retail with an exception flag is how the ledger stops reconciling.
Store systems have to keep trading when the network does not, so the offline capability of the point of sale, and what it is allowed to do while offline, is a design decision rather than a footnote. Around it sits the rest of the store estate: hardware stations and peripherals, cash management and safe drops, store-level stock counting, click and collect, ship from store and endless aisle, employee permissions, and the local fiscal and receipt requirements that differ market by market. We configure Commerce and the store estate around it, and we integrate to the point of sale you keep where replacing it is not the right call.
Ship from store and click and collect promise stock that a store believes it has. Item-level RFID is what makes that promise safe: cycle counts that take an hour rather than a night, and a measured accuracy figure instead of an assumed one. The work is integrating the reads into the inventory position rather than into a separate app, deciding what happens when the read and the system disagree, and setting the accuracy threshold at which a store is allowed to accept online orders. The threshold is a commercial decision with a cost either side of it, so it belongs to the business rather than to the integration.
The customer's model is simple: bought there, returning here. The system's model rarely is. Returning a web order to a store crosses entity, channel, tax treatment and stock ownership in one movement, and an exchange for a different size is a return and a sale that has to net correctly for revenue, VAT and commission. Add returns that go to a third party for grading, refunds against a payment method that has expired, and fraud rules that have to run without punishing good customers. This is where an omnichannel programme usually turns out to be a finance project.
For a retailer this is not only statutory reporting. It is price and tax by market, local receipt and fiscalisation rules at the till, customs and duty on cross-border ecommerce, the choice of which entity a web order is sold from, intercompany flows when one market's warehouse ships another market's order, and returns that cross a border on the way back. It runs on the same template and country wave method as any multi-country programme, with the retail obligations added to the country obligation register.
In design, before configuration, and it is usually the longest thread in the programme. The work is agreeing the product model once: what a style is, which attributes are dimensions and which are descriptive, how colour and size are coded, how a season and a collection are represented, and which system is master for each attribute. Then it is a migration and cleansing exercise with a reconciliation you can show an auditor. Anyone who tells you this is a data load has not done it.
Often no. The single stock position is an inventory and integration problem, not a till problem. If the point of sale can publish its transactions and stock movements reliably and take back a stock position, it can stay. We would tell you to replace it when it cannot support the store fulfilment you want to offer, when it holds pricing logic that needs to move, or when it is out of support. That is a shorter list than most proposals imply.
Four places, and none of them is the storefront. The product model is agreed too late. Store stock accuracy is assumed rather than measured, so ship from store starts failing customers. Returns are scoped as a logistics flow and turn out to be a revenue and tax flow. And the wholesale, concession or franchise part of the business is left until phase two, at which point the phase one design has to be reopened. We put all four on the register in the first fortnight, with a cost against each.
Yes, and on an estate this size it is the normal shape. We take the enterprise side, the merchandising, inventory, order management and finance layer, and integrate to the storefront and product information systems you keep. What has to be settled in writing before anything is built is which system is master for each piece of data and which one wins in a conflict. Ambiguity there is the most expensive thing in an omnichannel estate.
Not one we can show you as a published case study, and we are not going to imply otherwise. Our delivered work is in enterprise data, integration, supply chain and audit, and it is on this site with the numbers as measured. What this page describes is capability: the design decisions, the failure modes and the sequence. If that is not enough evidence for a programme of your size, ask us for the delivery team we would name, the references we can give and the parts we would want a specialist alongside us for, and judge it on that.
Sector capability, not a client reference. This page describes work we do in this sector. It names no client and claims no result, because those belong with an engagement. Delivered work carries the 6 engagements we can show you, with the numbers as measured.
Other sectors
