At 10:00, a customer clicks Buy. The payment goes through, the coat is reserved, the warehouse receives a pick request, and a carrier prepares to ship it.
The customer never sees the systems behind any of this. When everything works, there is no reason to think about them.
That is quiet tech.
The same coat exists in several systems at once. A designer may still be changing a detail in PLM while a material developer tests the fabric, a sourcing manager discusses lead times with the factory, and the content team prepares the product page. These teams start at different times and often work on the same product in parallel.
PLM
I am a product developer, and I spend most of my day in PLM—Product Lifecycle Management. This is where designers, technical designers, and product developers define what the coat is supposed to be.
We begin with a style: the sketch, category, season, proposed colors, and initial fit requirements. Then we add technical drawings, measurements, construction details, the size range, trims, and factory instructions.
The material developer records the fabric composition, weight, width, color, finish, supplier, and test results in PLM. Buttons, zippers, lining, thread, and labels all go into the BOM—Bill of Materials. The factory needs an exact list of every material and component it is expected to use.
After each fitting, I upload comments and revise the measurements. The factory sends another sample, the technical designer marks the required changes, and I issue the next version of the specification. At the same time, the materials team may replace the fabric because the first option loses its shape, shrinks too much during treatment, or fails a colorfastness test.
We export a Tech Pack from PLM and send it to the factory. Whenever we change the construction or a material, the factory needs the latest approved version.
What is a Tech Pack, and why does it matter?
A Tech Pack is the technical package a factory uses to calculate cost, make samples, and manufacture the final product. It usually includes technical drawings, a measurement chart with tolerances, a BOM covering all fabrics and trims, and requirements for seams, construction, colors, labels, and packaging.
A sketch shows what the coat should look like. The Tech Pack tells the factory how to make and inspect it. Product developers, technical designers, sourcing managers, the factory, and the quality team all need to work from the same approved version. Otherwise, the factory may order the wrong fabric, attach different buttons, or cut an entire production run using outdated measurements.
PLM shows which version went to the factory, which changes have been approved, and which ones are still under discussion. If production begins from an outdated specification, the same mistake can appear across the entire run.
Other teams do not wait for us to finish. While I adjust the sleeve, sourcing is already checking production lead times and the content team may be working with an early sample. Any important change in PLM has to reach the people who have already started their part of the work.
Supplier portal and sourcing
We work with vendors through a supplier portal. Material developers, sourcing managers, mills, and garment factories all use it. This is where we find out whether the ideas in PLM can actually be manufactured.
The material developer requests fabric swatches, prices, production lead times, and the MOQ—Minimum Order Quantity. The mill uploads certifications, composition details, available colors, and supporting documents. The factory receives the Tech Pack, asks questions, confirms when it can produce a sample, and later reports when the production run is ready.
PLM tells us which material the designer selected. The supplier portal tells us whether we can buy enough of it and receive it on time. The mill may not have approved the color for bulk production. The price may work while the MOQ does not. The factory may accept the construction but need more time for a complicated finish.
“We can get this fabric, but the lead time is twelve weeks.”
The sourcing manager takes that back to the product team. They may change the fabric, color, or construction. Then PLM, the Tech Pack, and the supplier documents all need to be updated. A design that looked approved may have to be reconsidered.
Not every factory uses the portal in the same way. Some confirm orders through EDI; others upload documents to a separate sourcing system; and some still send part of the paperwork by email. The sourcing team has to make sure the factory is using the same approved version the product team sees.
QMS
My job is to stop a production run before defective fabric reaches the cutting floor. I keep material, sample, and finished-goods inspection results in the QMS—Quality Management System.
A quality specialist records shrinkage, colorfastness, seam strength, fiber-content checks, and any other tests required for the product. When a sample arrives, they compare its actual measurements with the specification in PLM. Before shipment, an inspector checks part of the finished production run and uploads the result.
If the fabric fails a test, the product developer decides whether a different treatment might solve the problem or whether the material must be replaced. If an inspection finds the same sizing error across the batch, the sourcing manager can block the shipment even after the PO has been issued.
The result in QMS tells other teams whether they can continue with the selected material and whether the finished goods can be accepted.
ERP
Once the product, factory, materials, quantities, and commercial terms are defined well enough, procurement opens ERP. Before ERP, the coat consists of designs and samples. In ERP, it becomes a budget commitment and a set of specific SKUs.
I create the vendor and item records, then issue a PO—Purchase Order. This is the official order against which finance commits the money. The PO includes quantities by color and size, unit cost, currency, dates, shipping terms, and the receiving location.
PLM stores the style and its construction. ERP needs each orderable combination of color and size. The coat therefore receives separate SKUs: black in S, black in M, black in L, and so on. Procurement orders against those records, the warehouse receives against them, and finance uses them to record cost and process invoices.
A change in PLM does not automatically rewrite the PO. If the team replaces the fabric after the order has been created, procurement checks the new price, sourcing confirms it with the factory, and the buyer or planner decides whether the change affects quantities or margin. Finance, meanwhile, is still working with the document already in the system.
ERP shows what the company ordered and how much it costs. Fitting comments stay in PLM; product photography belongs in DAM.
MDM
We do not have a standalone MDM platform. Our master data team handles that work in ERP and in the integrations between systems. Another brand may use a dedicated application.
The team connects the style from PLM to the SKUs in ERP, along with barcodes, seasons, brands, and the product hierarchy. PIM, POS, WMS, OMS, and reporting all depend on those links. Without them, every system may contain a record for the coat without knowing that the records refer to the same product. That is why one shirt can collect ten different IDs before anyone notices.
The work exists even when the company does not own a system called MDM. Someone still has to create identifiers, prevent duplicates, and decide which codes the other teams will use. Independent brands face a smaller version of the same problem: Latin American labels often run on personal, low-overhead systems that still have to keep product, stock, and channels aligned.
PIM
To ERP, the coat is a dry item code such as WWCOATWOOL_01. In PIM—Product Information Management—I turn it into a product page a customer can understand.
I receive the style, SKUs, composition, dimensions, and care instructions. Then I write the product name and description, give the color a customer-facing name, add sizing information and translations, and enter the legally required copy for each market. I may also need to complete more than 30 attributes, including length, closure type, lining material, fit, and care. A marketplace can reject the listing if even one required attribute is missing.
PIM groups separate SKUs into one customer-facing product. On the website, the shopper sees a single coat and selects a color and size. ERP and the warehouse continue to work with a separate SKU for every variation.
The content team starts before production is complete. We can draft the description from the approved specification while the order is still at the factory. But if the product developer changes the composition or care instructions, the content must change too. PIM cannot keep publishing outdated information just because the product page was already finished.
The website, mobile app, and marketplaces require different fields. The content manager does not create three separate products. She maintains the core information and adds whatever each channel and market requires.
DAM
“Are the final images in DAM yet?”
“Yes, but only for the black colorway. The blue one is still being retouched.”
DAM—Digital Asset Management—is where the studio team, photographers, and content managers work with photos, videos, and other media.
The studio team uploads the shoot, records usage rights, and links every file to the correct style and colorway. The black coat needs images of the black coat, not a similar sample from an earlier collection.
Photography and copy move forward in parallel. PIM may be almost complete while retouching is still underway. Or the studio may have uploaded the images before the product team changes the buttons during sample review. The e-commerce team then has to decide whether the existing images are still accurate or whether the coat needs to be photographed again.
DAM stores approved assets and their versions. It does not decide whether the coat is available to sell; the inventory service does.
Pricing system
Merchandising and finance manage prices in the pricing system. They set list and selling prices by market, currency, and channel.
They start with the purchase cost from ERP, the target margin, taxes, and commercial rules. Then they set the price for the Netherlands, the United States, or the United Kingdom and determine when a markdown begins.
“We updated the price for the Netherlands. The markdown starts Friday.”
Nothing changes in PIM or DAM. One market may already be selling the coat at a discount while another keeps it at full price. The e-commerce platform and POS need the correct price for a specific place and moment.
E-commerce platform
I am responsible for the e-commerce platform. This is where my team assembles the page the customer sees.
We take copy and attributes from PIM, images from DAM, prices from the pricing system, and availability from the inventory service. Then we apply market rules: whether the coat can be sold in that country, which delivery methods are available, and whether a promotion code applies.
These pieces do not have to be ready at the same time. We can review the page before the inventory arrives, hide the buy button until launch, or open sales only in markets where price and availability have been confirmed.
If an image is missing, we check the connection to DAM. If a size does not appear, we check the link between the parent product and the SKU, then verify availability. If the price is wrong, we investigate the pricing feed. The e-commerce team has to identify which system supplied the incorrect value.
Marketplace connector
We do not own a marketplace connector. An outside company maintains it, while our marketplace team checks that the brand's information is converted correctly for each platform.
Every marketplace has its own categories, required attributes, size names, image rules, and listing IDs. The vendor maintains the integration. We map our internal values to the marketplace's reference data and verify the listing, price, and inventory we send.
The coat may already be available on the brand's website while a marketplace continues to reject it because an attribute is missing. In that case, we correct the data or the mapping for that channel only. The product team and factory have nothing to fix.
POS
I work in a store and use POS—Point of Sale. I look up the SKU, scan the barcode, check the price, and complete the sale.
At checkout, I don't care about fiber composition or button approval history. I need the correct item, price, tax rules, promotions, and inventory status. If the store offers Click-and-Collect or Ship-from-Store, POS also exchanges information with OMS and the inventory service.
The coat can be selling in a store while a marketplace is still reviewing its listing. Nothing is out of sequence. Sales channels operate independently and receive only the information they need.
WMS
At the warehouse, we work in WMS—Warehouse Management System. This is where employees receive, put away, move, pick, and pack merchandise.
The factory may have marked the production run as shipped, while ERP shows the expected quantity.
“As far as I’m concerned, the inventory doesn't exist yet. First, I have to receive and scan the cartons.”
After scanning, the team reconciles the quantity, checks the condition of the goods, and assigns a storage location.
When an order arrives, WMS tells the picker where the coat is stored. The employee scans the unit during picking and packing. If the location is empty or the item is damaged, they record it here. OMS can then choose another fulfillment location.
WMS knows where the physical product is. The inventory service calculates how much of it can be offered to customers.
Inventory service
The operations team owns availability. In the inventory service, we calculate ATS—Available to Sell—the quantity that can be offered through a particular channel.
We take physical inventory from WMS, sales from POS, reservations from OMS, and allocation rules. Units already promised to customers, safety stock, uninspected returns, and blocked goods are excluded from ATS.
The last coat may be hanging in the Amsterdam store. We decide whether to offer it online through Ship-from-Store or leave it for the store. That decision can change without anyone touching PLM, PIM, or DAM.
Updates do not arrive everywhere at once. If an online shopper and a store associate try to sell the final unit at almost the same time, the inventory service has to distribute the new inventory position quickly. Otherwise, one of the channels may have to cancel the sale.
OMS
The customer clicks Buy, and the order enters OMS—Order Management System, where order operations takes over.
I am an order specialist. In OMS, I see the cart, verify availability, reserve a specific SKU, and select the fulfillment location. The coat may ship from a central warehouse, a regional warehouse, or a store. OMS considers inventory, the customer's address, the promised delivery date, and order-splitting rules.
If the first warehouse cannot find the coat, an order specialist may reroute the order. If the cart contains several products, OMS decides whether to ship them together or in separate packages. WMS receives the pick tasks, while OMS keeps the order status and coordinates the sales channel, warehouse, and delivery.
Payment and fraud systems
We do not own the payment provider or fraud system; both are external services. The payments team monitors them and makes sure we do not create an unpaid order or leave a payment authorization open without an order.
The payment provider authorizes the amount. The fraud system assesses the risk. OMS receives their decisions and continues only after the required checks pass. If the order is canceled, the system must release the authorization or issue the refund.
These services need the amount, currency, customer, and order reference. Until they respond, WMS should not begin fulfillment.
Carrier system
The logistics team uses the carrier system to select the carrier, create a shipping label, and receive a tracking number.
After packing, WMS sends the parcel weight, dimensions, address, and delivery method. The carrier accepts the shipment and returns status updates. OMS and the notification service use those updates to tell the customer where the order is.
If the carrier misses an update, the coat may still be moving as expected, but neither the customer nor customer service can see it.
CRM
“Where is my coat?”
A customer service agent receives the question. They open CRM and the customer service platform, where they can see the customer, order, prior contacts, and messages.
To answer, the agent needs statuses from OMS, the payment service, the warehouse, and the carrier. They should not have to open every system separately. The relevant information needs to be available in one workspace.
If a status never arrives, the agent cannot explain the problem even if another team is already fixing it. To the customer, all of these systems still belong to one company.
Returns platform
A returns specialist starts the return. In the returns platform, they check whether the coat is eligible, connect it to the original order, and choose mail return or return-to-store.
When the item arrives, WMS records the physical unit and an employee inspects its condition. The payment provider processes the refund. The inventory service does not make the coat available immediately; first, the warehouse must confirm that it can be sold again.
The specialist records the return reason here as well. The product team may use that information when developing the next version—but only if store and website reason codes can be understood together and the information actually reaches the team.
Data platform
I am a data engineer. In the data platform, my team brings together history from PLM, ERP, PIM, POS, OMS, WMS, and other systems for reporting and analysis.
We connect the style, SKU, barcode, order, and return. But we do not create the product, manage the warehouse, or promise delivery. If the description is wrong in PIM, the DWH will not correct it. If WMS has not received the cartons, a report cannot make the inventory available.
Our job is to preserve those connections and show teams what happened to the coat across different systems. The actual product work still happens where designers, material developers, sourcing, procurement, content, stores, warehouse, and operations teams do it.
Quiet tech
The customer does not need to know where the designer changed a sleeve, who approved the fabric, how the factory received the specification, where the SKU was created, or which system selected the warehouse.
Technology becomes visible only when something goes wrong: the composition on the website does not match the label, the photo shows the wrong color, the store cannot find an available size, the order is canceled after payment, or the return is accepted but the refund never arrives. Retailers who chased theatrical fitting-room hardware learned the same lesson the hard way: smart mirrors lost the budget fight to quieter inventory and logistics tools.
When everything works, the customer notices none of these systems. Turn the assistants off for a day, and the people inside the company notice immediately.
At 10:07, a customer opened the coat's product page. The photos loaded, the price matched, the right size was available, and delivery was promised for the next day.
They added the coat to the cart, looked at it one more time, and closed the tab.
They did not buy it. They had simply changed their mind.
