This page is for anyone confused by why a company keeps its product information and its business information in different places. Every order has two different kinds of information about it. One kind is about the product itself: what it is, what it is made of, what size it should be. The other kind is about the business transaction: what was ordered, at what price, and where it stands today. At work, a merchandiser reads both kinds of information every day, often from two different systems, and has to know which system to trust for which question.
Without this distinction, a person assumes one system should show everything, and gets confused when it does not. A new hire opens the ERP-side purchase order looking for the latest fabric weight and cannot find it, because that fact never lived there. A merchandiser changes a measurement in the design system and expects the factory's cost sheet to update itself, and it does not. This lesson names the two kinds of information, the two kinds of system that usually hold them, and the one point where they meet on a real order.
You need: lesson 9.1's idea that information about an order must move as reliably as the goods themselves. No other lesson is required first.
By the end of this lesson you can:
Not covered here: the exact fields that connect a purchase order, a tech pack and a costing sheet (lesson 9.3); what it costs when information fails in other ways, such as wrong data or a late update (lesson 9.4); keeping information reliable with no dedicated system (lesson 9.5).
| Term | Meaning |
|---|---|
| PLM (product lifecycle management) | The system or method that manages a product's own information, from design through development: its tech pack and its sample-round history. |
| ERP (enterprise resource planning) | The system or method that manages a business's transactional information: its orders, inventory, costing and production scheduling. |
| Tech pack | A document that specifies exactly what a garment is: measurements, fabric, trims, construction and artwork, that a factory produces against. |
| Purchase order | A document from a buyer confirming quantity, price and delivery date, which commits the buyer to pay for the goods it orders. |
| Specification reference | A named or numbered tech pack or approved specification a purchase order points to, so both sides agree exactly what is being made. |
| Costing sheet | The document that lists a garment's cost components and adds them to the price the factory quotes. |
| Production tracking | Comparing a stage's actual finish date against its planned date throughout production, to catch a delay while it can still be fixed. |
| Version confusion | When two people work from different, outdated copies of the same document without realising it. |
Every order produces two different kinds of information. The first kind describes the product itself: its design, its specification, its sample-round history. This is product lifecycle information, and the system built to manage it is called PLM, product lifecycle management. The second kind describes the business transaction and its status: the order placed, the cost agreed, the schedule tracked. This is transactional information, and the system built to manage it is called ERP, enterprise resource planning. The same order's information lives partly in each system. Confusing what belongs where is a common source of the version confusion this course covers.
| Stage | What it does | What it hands over |
|---|---|---|
| PLM | Manages the product's design, specification and sample-round history until it is approved. | A confirmed specification reference |
| ERP | Manages the order, its cost and its production status from placement to shipment. | An order tracked against that fixed reference |
| What can differ | The shapes you meet | Why it matters |
|---|---|---|
| Dedicated PLM and ERP as separate systems | A larger exporter runs a PLM-style system for design and sample approval, and a separate ERP-style system for orders, costing and production. | The two systems do not update each other automatically; a fact must be carried across the boundary deliberately. |
| One combined system | Some companies run a single system that covers both kinds of information, with PLM-style and ERP-style modules inside it. | The two kinds of information still exist and still need the same care, even though they sit in one piece of software. |
| A domestic brand without dedicated software | Cedar & Co., a smaller domestic brand, tracks both kinds of information in spreadsheets and shared folders rather than dedicated PLM or ERP software. | The same two kinds of information still exist; a manual system is still a real system that needs the same discipline. |
| Product families where the boundary shifts | For made-to-stock knit-to-garment and socks and hosiery ranges, PLM-style information can be simpler (fewer sample rounds, a standing specification), while the ERP-side order and stock information is often heavier because of repeat, forecast-driven orders. | The general split still holds: product information stays on one side, business information on the other, whatever the product family. |
| Export versus domestic orders | An export order like Order A carries extra ERP-side fields (letter of credit terms, shipping documents) that a domestic order on open account does not need. | The PLM side of the order barely changes between export and domestic; the ERP side grows with the transaction's complexity. |
Northline Apparel's design team manages Order A's tech pack, and every sample-round revision from lesson 5.2's proto, fit and PP rounds, in a PLM-style system. This is the product's own history: what the T-shirt is meant to be, and how that idea was proved through samples. Once the tech pack is approved, its confirmed specification reference is entered as a fixed field on the ERP-side purchase order that Delta Garments works from, alongside the purchase order's own quantity, price, delivery terms and payment terms fields covered in lesson 5.3. From that point, Delta Garments' merchandising and production teams track the order in the ERP-side system: the costing sheet, and production tracking against the 16-week timeline.
Two different systems, two different kinds of information, one order. Delta Garments never needs to open Northline Apparel's PLM-style system; it needs only the confirmed specification reference the purchase order already carries.
The worked numberThis is not a calculation-heavy lesson: it is a classification exercise, on five fields drawn from Order A's own documents.
Write your answer on the working template in block 10 for every document field you are unsure about.
The trapA common mistake is to assume that if a company does not run named PLM or ERP software, it has no real system for this information. Cedar & Co., a smaller domestic brand, tracks the same two kinds of information in spreadsheets and shared folders rather than dedicated software. It still has a functioning system, a smaller and more manual one, and the same discipline this course teaches still applies to keeping it reliable. The software a company uses does not decide whether the two kinds of information exist; it only decides how they are held.
Every order produces two kinds of information. One kind is about the product itself: its design, its specification, and how samples proved the design worked. The other kind is about the business deal around it: the order placed, its cost, and where production stands today. Companies often use one system to manage the product information and a different system to manage the business information. The two systems do not update each other by themselves. Once the product's specification is confirmed, that one fact is copied into the business system as a fixed field, and from then on the business system tracks the order against it. A company without dedicated software for either job still has both kinds of information, just held in simpler tools such as spreadsheets.
A new hire joins Northline Apparel's buying office and starts checking Order A's documents. She notices that the tech pack's design team recently revised a body length measurement after a fit sample, but the purchase order Delta Garments is working from still shows the earlier specification reference.
The purchase order's specification field reads:
Is the mismatch between the tech pack and the purchase order a system failure? Decide before you open the answer.
Not necessarily. Two facts decide this.
First, PLM and ERP are usually separate systems handling different kinds of information. The tech pack's revision history lives in the PLM-side system; the purchase order's specification field lives in the ERP-side system. They were never designed to update each other automatically.
Second, a specification only transfers to the purchase order at a specific handoff point, once the specification is confirmed, not continuously. The purchase order's own field states it is fixed once entered. If the latest measurement revision has not yet reached that confirmed handoff point, the gap is expected, not broken.
The correct response is to check whether the revision has been confirmed and formally carried across, not to assume either system has failed.
Framed qualitatively rather than with a single figure: if someone assumes PLM and ERP sync automatically when they do not, they may work from an outdated field on one side while believing it already reflects the other side's latest update. This is a form of version confusion, this course's own term for two people working from different, outdated copies of the same information without realising it.
Understanding the PLM/ERP boundary, and that the handoff happens at one point rather than continuously, is what prevents this risk turning into a real cost on an order like Order A.
The Information map sheet already lists the documents Order A produces: the tech pack, the purchase order, the costing sheet and the bill of lading, with who creates each one, who relies on it, and what happens if it is wrong. For each row, use the notes column to mark whether that document is PLM-side (product information) or ERP-side (transactional information), using the three-step method above.
| Document | Created by | Relied on by | Mark it PLM-side or ERP-side |
|---|---|---|---|
| Tech pack / specification | Northline Apparel (design) | Delta Garments (production, quality) | |
| Purchase order (NA-2291) | Northline Apparel (buying office) | Delta Garments (merchandising, production) | |
| Costing sheet | Delta Garments (merchandising) | Both companies' merchandising | |
| Bill of lading | The shipping line | Both companies, and the bank under the letter of credit |
1. What kind of information does PLM primarily manage?
2. What kind of information does ERP primarily manage?
3. A factory receives a 5,000-piece domestic order tracked only in spreadsheets, with no named PLM or ERP software. Does it lack a real system for this information?
| EN | AR | FR | TR | Meaning |
|---|---|---|---|---|
| PLM (product lifecycle management) | إدارة دورة حياة المنتج (PLM) | Gestion du cycle de vie du produit (PLM) | Ürün yaşam döngüsü yönetimi (PLM) | The system or method that manages a product's own information, from design through development: its tech pack and its sample-round history. |
| ERP (enterprise resource planning) | تخطيط موارد المؤسسة (ERP) | Progiciel de gestion intégré (ERP) | Kurumsal kaynak planlaması (ERP) | The system or method that manages a business's transactional information: its orders, inventory, costing and production scheduling. |
| Tech pack | حزمة المواصفات الفنية | Fiche technique | Teknik paket | A document that specifies exactly what a garment is: measurements, fabric, trims, construction and artwork, that a factory produces against. |
| Purchase order | أمر الشراء (طلبية الشراء) | Bon de commande | Satın alma siparişi | A document from a buyer confirming quantity, price and delivery date, which commits the buyer to pay for the goods it orders. |
| Specification reference | مرجع المواصفة | Référence à la fiche technique | Spesifikasyon referansı | A named or numbered tech pack or approved specification a purchase order points to, so both sides agree exactly what is being made. |
| Costing sheet | كشف التكلفة | Fiche de coûts | Maliyet tablosu | The document that lists a garment's cost components and adds them to the price the factory quotes. |
| Production tracking | تتبع الإنتاج | Suivi de production | Üretim takibi | Comparing a stage's actual finish date against its planned date throughout production, to catch a delay while it can still be fixed. |
| Version confusion | اختلاط الإصدارات | Confusion de version | Sürüm karışıklığı | When two people work from different, outdated copies of the same document without realising it. |
You now know which kind of information belongs to PLM and which belongs to ERP. The next lesson follows Order A's own documents and shows the exact fields that connect a purchase order, a tech pack and a costing sheet, and what happens when one of those links breaks. Back to the course map