Three Eras of Sourcing

DSI's navigation is licence-composed. Every module is gated per organization, so one customer sees BOM Insight, Sourcing and Quoting, and another sees Sourcing and almost nothing else. Whatever we shipped had to make sense as the second item in a full suite and as the front door for a customer who bought only this. No bespoke chrome, no parallel information architecture, no assumption about what sits beside it.

The hardest one to hold. The original concept folded RFQ into a general-purpose project shell, which flattened exactly the things that make RFQ good: supplier-side workflow, response handling, awarding, negotiation. RFQ keeps all of it. Sourcing does not replace it and does not wrap it.

OEM procurement teams cost parts to make internal buying decisions. EMS customers cost the same parts in order to quote those costs back to their own customers and win the build. Same surface, opposite direction of travel: one is deciding what to pay, the other is deciding what to charge. The design had to serve both without forking.

Scope moved repeatedly: an early narrowing from “new shell for DSI” to “the costing module”, a mid-flight expansion to serve EMS customers, and then a long third phase about making the module's answers stay put. Each shift moved what we built. None of them were allowed to move the four-tab structure, the ranked price sources, or the RFQ boundary.

A Sourcing project pulls pricing from seven source types: Contract Pricing (now generalized into typed Cost Sets), Purchase History, Quote Responses, Quote History, Specific Price, Web Price and Manual Price. The buyer ranks them. The project then applies the highest-ranked source that actually has data for that part at that volume, and falls down the stack only when it has to.

Three things make it a design decision rather than a settings screen. Ranking is layered, so a shipped default can be overridden per organization and again per project, and a buyer working on one project never has to touch a global. Each source carries its own tie-break chain, so “which contract price” is answerable as well as “which source”, and Lowest Price is permanently welded into every chain: you can reorder around it, you cannot remove it. And the per-line override is as important as the default, because clicking a price opens the full comparison and lets judgment beat the ranking on any single line.

This is the decision I would defend hardest, and it is the one that took longest to say out loud. The obvious model is a pipeline: BOM, then Sourcing, then RFQ. It is wrong. A Sourcing project is the object. An RFQ is what that project does when it has a gap, which is to say a part with no usable price or a price that has gone stale.

So the answer has to come home. Quote Responses is this project's own live RFQ. Quote History is every other project's past RFQs. Same underlying data, different scope, both sitting in the same ranked stack as contract price and web price. Going to market is an operation the project performs on itself, and it competes for the line on the same terms as everything else.

The consequences fall out cleanly. Only lines that genuinely need a quote get sent, so the send is partial and repeatable rather than a handoff. Anything already sent is excluded automatically. And when responses come back changed, they arrive as a diff the buyer reviews and applies, not as a silent write.

Once a module picks prices for you, it will eventually pick a different one. That is correct behavior and it is also how you lose a buyer's trust, because the real negotiation happens on a call the software never sees. A buyer settles a price offline, comes back, and the line has moved.

So there are three separate loops, and keeping them separate was most of the work. Refresh is upstream staleness: go and re-read the sources. Sync with RFQ is downstream drift: quantities and parts changed here, show me the diff before suppliers see it. Lock is the human one: this line is settled, stop touching it.

Lock is the interesting one because it is mostly implicit. Overriding a price locks the line, because overriding a price is the buyer saying they know something the data does not. Rather than hide that, the interface names it: the refresh control on a locked line relabels itself to “Unlock to Refresh Line”, and the line carries a Refresh Locked state where the buyer is already looking. Moving which alternate part costs the BOM opens a two-branch dialog that spells out both consequences in plain language, with a remember-my-choice escape. Small surfaces. They are where the module stopped feeling like a spreadsheet that changes its mind.

These users live in Excel and will ask you for more columns forever. The Part List gives them four: internal part number, manufacturer part number, one per quantity tier, and status. Each one is a dossier rather than a field, stacking whatever the project needs to see inside a single cell, with the two identity columns pinned. Twenty-eight optional sub-fields live inside those four cells, from lifecycle and years-to-end-of-life to excess cost and package type. Density without horizontal panning.

The second half of that decision matters more. Which sub-fields appear is not a personal preference, it is a named view authored at the organization level and attached to the project, and the same view governs what renders, what can be sorted, and what comes out in the export. One artifact, three surfaces, so a team's definition of a part travels with the work instead of being rebuilt per user.

Costed BOMs consolidates a multi-level BOM with subassemblies, Make and Buy distinctions and reporting-only lines into one rollup, with volume tiers selectable per assembly. A Sourcing project carries up to six simultaneous quantity tiers, so a buyer can see 100, 1,000 and 10,000 units of the same assembly side by side. The RFQ side carries twelve, which is a real seam between the two modules rather than a bug.

The rollup problem is that parents and children get their numbers from different places: children are priced from sources, parents are summed from children. Rather than build a second rendering path for assemblies, an assembly is given a synthesized price entry of its own, so it sorts, renders and exports exactly like a purchased part and its unit cost is simply its rolled total divided by its volume.

And the setting people conflate: Consolidate By decides which rows merge and sum their quantities, so the same resistor in five subassemblies can become one larger buy. Group By decides which lines share a single cost decision. They are not the same question, and the winning line is recomputed per quantity tier, so a project can be costed from one supplier at 1,000 units and a different one at 10,000.

Sourcing did not ship once. It shipped continuously across three phases with distinctly different jobs, and my role changed in each one: building the object, then widening it to a second kind of customer, then directing designers on parallel tracks while the module learned to stop moving.

The first version was bigger than what shipped. I wanted Sourcing to reframe DSI itself, to make a project the central object that any capability could compose inside. We started building toward that. As the work progressed a clearer truth surfaced, and it was smaller and truer: this is a costing problem. Sourcing became the place where BOM data meets every price signal the company already owns, and it reaches out for a new quote only when nothing it holds is good enough.

From a shell to a costing module. Sourcing became its own module with its own data, its own ranked price configuration and a link to RFQ. This is where the pivot happened: the general-purpose project shell was killed and the costing module shipped in its place. The four-tab structure and the price stack were set here and never moved again.

Shipped: module gated per organization · own price-source ranking · own schema, own line items · the RFQ link, both directions · tags, statuses, assignment.

Multi-level, versions, and a sell side. Real BOMs are not flat and real projects are not one-shot. Multi-level assemblies, project versioning as a tree with selective copy scope, and then the EMS-facing capability: markup and sell price, sitting per line and per quantity tier directly on top of whichever source won. The features did not multiply. Their meanings did.

Shipped: multi-level BOM costing · version trees, selective copy · markup and sell price per tier · contract price becomes typed cost sets · end-customer attribution.

Freeze, lock, and provenance. The phase nobody plans for. Buyers negotiate offline and need the result to survive the next refresh. Finished lines should not be re-priced just because everything else was. Line locking, manual prices, and frozen snapshots of internal price data mean a costed BOM stays the costed BOM you agreed to.

Shipped: line locking, with recorded reason · manual price override, per tier · snapshots of contract, quote, PO data · manual-edit tracking · sync-with-RFQ as a reviewed diff.

Across every shift: the four-tab structure even under pressure to flatten it, ranked price sources as a first-class concept and never buried in settings, and RFQ staying its own application. Those three survived a pivot, a customer-type expansion, an organizational change, and two years of feature pressure.

Era one I designed most of it. By era three I was directing designers on parallel tracks, which meant the load-bearing decisions had to be written down and defensible rather than held in my head. The four tabs and the price stack became the thing everyone designed against, which is the actual test of whether a structural decision was any good: other people can extend it without asking you.

DSI users are conditioned to spreadsheet exports and enormous tables, so pushback is constant and structural. Going deep on the why with decision-makers, rather than bending on structure and adding another column, is what kept the module coherent.