The license and the outcome are separate purchases
The structure is public and easy to verify. The large planning vendors maintain partner ecosystems: published directories of certified implementation firms, tiered partner programs, certification tracks, annual partner awards. None of it is concealed — it sits on the vendors’ own websites, presented as a strength, and from the vendor’s position it is one. The directory exists because the vendor does not, as its standard operating model, implement its own software at scale. Delivery belongs to the ecosystem.
Commercially, that splits what the buyer experiences as one project into two engagements. The license or subscription agreement is with the vendor; it covers the software. The statement of work is with the partner; it covers the project. Two firms, two fee structures, two sets of obligations, two account teams. The signature that buys the software and the signature that buys the outcome sit on different contracts — and in the standard structure, neither contract makes the two firms jointly responsible for what the planning team ends up working in.
That last property matters most when things go wrong, which is precisely when it is least convenient to discover it. A system that underdelivers can be a product deficiency or a configuration deficiency, and the two-contract structure gives the question two candidate answers by design. Each firm can point at the other in good faith and be partly right. This is not an accusation; it is a design fact about the standard commercial structure, and a buyer is better off knowing it before it matters than after.
The structure is rational — for the firms on the other side of it
The first reason is vendor economics. Software revenue scales with licenses; implementation revenue scales with headcount. A vendor that delivered every implementation itself would need a services organization growing in step with its sales — larger, eventually, than its product organization — carrying utilization risk the software business model exists to avoid. A partner ecosystem converts that services burden into someone else’s revenue, and extends the vendor’s reach into regions and verticals its own teams do not cover. From the vendor’s chair this is sound strategy, and it is why the model is so consistent across the enterprise tier.
The second reason is the product itself. An enterprise planning suite earns its breadth by being configurable: the same platform serves a grocery chain, a hardlines retailer and a fashion business, which means it arrives generic and becomes an apparel planning system through configuration. The product you evaluated is a toolkit; the system you go live on is a build. Someone has to decide the hierarchies, the calendar, the planning grain, the size logic, and encode those decisions — and that is a project, which means people, which means a services layer somewhere in the model.
Notice that neither reason has anything to do with the buyer’s outcome. Both are structural conveniences for the supply side, and there is nothing scandalous about that — markets organize around supplier economics all the time. But a buyer should read the structure for what it is rather than for what the partnership language around it suggests. The deeper argument — that a generic platform configured for apparel is not the same thing as an apparel-native system — is made in why apparel needs its own operating system. This essay stays on the narrower question of who does the configuring, because that question has consequences of its own.
The demo is the vendor’s work product. Your system is the partner’s.
The demo you evaluated in the sales cycle was built by the vendor’s presales team — people who work in the product every day, against a model dataset assembled to show it well. There is no deception in that; it is what a demo is, everywhere, for every product. But it is worth being precise about what kind of evidence you were shown: the ceiling of what the product can look like in the hands of the people who know it best, on data shaped to suit it.
The system you go live on is a different artifact. It is configured by the partner’s project team, against your item file, your calendar, your hierarchies, your integrations, under a budget and a deadline. The hands that built the thing you evaluated are not the hands that build the thing you will use. The demo is evidence about the product; it is not evidence about your implementation. Treating one as a proxy for the other is the quiet category error at the center of most enterprise software evaluations.
The practical consequence lands in reference checking. References on the software are typically arranged by the vendor and speak to the product. The more informative reference is on the combination: this partner, implementing this product, for a brand whose planning looks like yours — the same channel mix, a comparable line architecture, a seasonal calendar rather than a replenishment one. That is a narrower question, it is harder to arrange, and it is the one that actually predicts your project.
You are running two procurements, and the second gets a fraction of the scrutiny
The software selection gets the full apparatus: a requirements matrix, demo days, scored evaluations, reference calls, a negotiation. The partner selection tends to arrive afterwards — once the software is chosen, the budget is committed and the organization’s evaluative energy is spent. Sometimes it arrives as a recommendation from the vendor’s sales team; sometimes as a shortlist pulled from the partner directory. Yet the variance between partners is at least as consequential as the variance between products, because the partner makes more of the decisions you will live with.
What varies is not general competence — it is apparel planning depth. Certification measures product knowledge: the modules, the configuration tools, the data model. It does not measure merchandising judgment. A firm can be genuinely expert on the platform and thin on open-to-buy, size curves, drop calendars and wholesale-to-DTC channel mechanics, and its certificates will look identical to those of a firm that is strong on both. Staffing adds a second layer of variance: the proposal is written by the firm’s most experienced people, and the project is staffed from whoever is available on the bench when your start date arrives. That is standard services-industry mechanics rather than sharp practice — but it means you choose the partner, and the partner’s staffing model chooses your consultants.
The discipline that the software selection gets should extend to the partner selection, with the same seriousness and earlier than feels natural. The product half of that discipline is covered in the apparel software buyer’s guide; the partner half is what this essay closes with.
Configuration decisions are planning decisions
Look at what actually gets decided during an implementation. The planning grain — whether the plan lives at style, style-color or SKU. The merchandise hierarchy, and where a blurred category boundary gets drawn. How the calendar handles drops, seasons and transitional periods. Where open-to-buy sits and what it reconciles against. How size curves are stored, applied and overridden. What a reforecast is allowed to change and what it is not. Every one of these reads as a technical configuration item on a workplan, and every one of them is a merchandising design decision the planning organization will live inside for years.
In the partner model, those decisions route through a delivery process: discovery workshops, requirements documents, configuration sign-offs. The people encoding them are consultants — strong on the product, variably grounded in planning. A requirements workshop is a translation exercise: the planner describes what they do, the consultant hears what the product can encode, and the document records the overlap. The system that emerges reflects what survived translation, not everything that was meant — and the sign-off page confirms that the document was reviewed, not that the translation was faithful.
The routing persists after go-live, which is where it bites hardest in a seasonal business. An in-season change — a category that needs a different grain, a new channel, a hierarchy split ahead of the next buy — becomes a change request: scoped, estimated and scheduled through the partner relationship. What the merchandising team experiences as a decision the season needs, the delivery structure experiences as new scope. Neither party is wrong. The mismatch between the two clocks is the point, and in apparel the season’s clock does not negotiate.
The partner is paid for the work, not the outcome
This needs saying carefully, because it is about structures and not about people. The consultants on these projects are, for the most part, capable professionals doing exactly what their contracts define. The issue is what the contracts define. A services firm sells effort — time and materials, or a fixed fee bounded by a change-order mechanism. Under either structure, scope that grows is revenue, requirements churn is billable, and a long tail of post-go-live change requests is an account rather than a failure. Speed, for the services firm, is a cost.
The buyer’s economics point the opposite way: the shortest path to a working system that planners adopt. Both positions are commercially legitimate, and the seam between them runs straight through the middle of the project. Wherever a decision could be resolved simply or thoroughly, thoroughness has a constituency at the table and simplicity does not. The outcome you are buying for — a plan the team trusts, full-price sell-through, margin — is typically a line in neither agreement. The software contract warrants the product. The statement of work warrants the deliverables. The thing you wanted sits between them, contractually unclaimed.
When priorities collide — a go-live date against an unresolved scope item, a season deadline against a configuration queue — the mechanism that resolves the collision is the change order, and the change order’s terms were written before anyone knew what would collide. None of this calls for cynicism, and it does not mean the model cannot be run well. It means the buyer’s protection is not finding a firm with better intentions; it is noticing that the seam exists and writing the questions this essay closes with into the selection itself.
The rationale leaves before the questions arrive
Through the implementation, the deepest understanding of why the system is configured the way it is sits with the partner’s project team. At go-live, that team rolls off. The delivery model depends on it — the consultants’ next engagement is already staffed, and keeping a project team parked on a live account is exactly the utilization problem the model exists to avoid. What remains behind is documentation of whatever depth the budget bought, a trained core team, and a configured system whose design rationale is now partly written down and partly gone.
The questions arrive later, in season, when something needs to change. Why is the hierarchy split this way? Why does the reforecast leave receipts untouched? What breaks if this category moves to a different grain? In each case, the question “why is it set up this way” comes before “what happens if we change it” — and the people who could answer the first from memory are on another client’s project. The standard options are a support retainer, a re-engagement, or an in-house administration function that rebuilds the understanding over time. All three are workable. All three are a recurring cost of the model rather than an exception to it, and they rarely appear in the evaluation-stage arithmetic.
The decay is fastest exactly where apparel is hardest. A seasonal business changes its questions every season — a new drop cadence, an added channel, a licensing arrangement, a category extension. The frequency at which “we need to change the configuration” arises is set by the business’s clock, and the apparel clock runs fast. A delivery model that treats configuration change as an occasional event is priced for a slower business than the one you run.
When the model genuinely serves the buyer
The steelman deserves to be made properly, because the integrator model is not a defect of the enterprise tier — it is load-bearing for the buyers it was built for. A global rollout across banners, regions and fiscal calendars is a program, and program delivery is a real discipline: sequencing, localization, training at scale, cutover management across time zones, governance that survives staff turnover on both sides. Systems integrators carry that discipline as a core competence. A retailer attempting such a rollout without one is standing up a program office from scratch, mid-flight.
Integration-heavy landscapes make the same case. A company with an aging ERP, a warehouse system, several order-management platforms and a data warehouse mid-migration is buying integration engineering whether it wants to or not, and a firm that has built those specific connections before is worth its fee. There is also a subtler benefit: an experienced independent partner is a counterweight to the vendor. It has seen the product fail and can say which modules are mature and which to avoid — something the vendor’s own delivery organization is structurally not positioned to volunteer. The stack complexity that makes this integration work necessary is its own subject, taken up in the disconnected apparel stack.
And some buyers are built for the model. An organization with a standing IT function that manages delivery partners as a routine capability, a program office, and procurement muscle for services contracts can hold an integrator properly accountable — the structural risks described above do not disappear, but they are managed by people whose job is managing them. For that buyer, the model is the operating model working as designed. The integrator model is a tool sized for a certain scale of problem. The failure mode is not the tool; it is inheriting it by default at a scale it was not sized for — which is where much of the mid-market and emerging-brand tier finds itself, running an enterprise delivery model without the enterprise apparatus that makes it safe.
Ask who does the work before you evaluate the work
None of what follows is hostile, and it is worth saying so in the room before a vendor arrives. These are procurement questions about structure, and a vendor or partner with good answers gives them readily. Evasive answers are themselves information. The questions cost nothing, and they move the most consequential facts of the purchase from after the signature to before it.
For the vendor: who implements — your employees or a partner? If a partner, who selects them, who contracts them, and what does the certification they hold actually measure? Whose work was the demo we saw, and who from that team will be anywhere near our project? After go-live, who makes a configuration change in season, under what commercial arrangement, and on whose calendar? For the partner: who exactly will staff this project — named people, not roles — and what apparel planning work have those people shipped? Where will the configuration rationale live when you leave, and in what form? Who owns the requirements document when the plan it encodes turns out to be wrong?
One question belongs to you rather than to either firm: which of your own planners will be released to the project, for real hours, at the workshops where the grain, the hierarchy and the calendar get decided? An implementation staffed with consultants and no planners encodes the consultants’ assumptions, however good the consultants are. What a well-run connected-planning implementation involves — the phases, the data prerequisites, the definition of done — is laid out in the implementation playbook. The questions here come before all of that: they establish who will be doing those phases at all.
The question in the title reads like an operational detail — the kind of thing delegated to IT and answered after the selection is made. It is closer to being the whole purchase. A planning system, as the planners inside it experience it, is not the software; it is the configured, adopted, maintained working thing, and whoever implements it makes more of the decisions that shape the planning organization than the license does. Buyers who ask who that is first are not being difficult. They are noticing what is actually for sale.