We establish from one place which version of a technical drawing, CAD file, recipe or sample record is the valid one. PDM manages the file and its revisions; PLM extends that across the product's whole life, from idea to serial production, together with change approvals. Whether the drawing that reaches the shop floor is the right drawing stops being a matter for debate.
In a manufacturing business, one of the most expensive mistakes happens quietly: the technical drawing that reaches the machine is not the valid one. The part is made, it is out of tolerance, it becomes scrap — or worse, it goes to the customer. Looking back afterwards, everyone behaved correctly; the foreman used the printout in his hand, the engineering office issued a revision, purchasing ordered material against the old recipe. The problem is not with people, it is that where the valid version lives has never been defined. Files sit in a shared folder; names pile up as final, final_v2, final_revised_new, and after a while nobody can say for certain which one went into production. Nor does the cost stop at scrap; a wrong part delivered to a customer casts doubt over the next order as well.
The same problem appears in a different guise in every sector. In machinery and metalwork the issue is the CAD file and the assembly tree: changing one part also affects the other assemblies that use it, but that relationship usually exists only in the designer's head. On the textile and carpet side the issue is collections and samples; the pattern, the yarn recipe, the colour variant and the sample approval history scatter across email attachments, and the same sample gets woven a second time. In food, when the recipe and the label information are not managed from the same place, the packaging and the contents no longer match. The common thread is this: the technical truth of the product is held not in a system but in people's memories and in file names. The sector may change, but the solution starts from the same place — taking engineering data out of files and putting it on the record.
Two terms are often confused here, and it is worth separating them. PDM (Product Data Management) is narrow and concrete; it works like a vault for technical files. It answers the questions of who checked out a file, which revision is valid, which file belongs to which part, and where the old versions are kept. PLM (Product Lifecycle Management) is broader; it manages the product's entire life, from the idea stage to design, from sample to serial production, and on through revisions to withdrawal from production. PLM cannot be built without PDM; without PLM, PDM remains an orderly file archive. In practice most companies' needs begin with PDM and widen towards PLM as change management is added.
To be honest, this is a matter of discipline more than of software. What the system can do on its own is hold the valid version in one place and stop a change from passing without approval; getting the engineering office into the habit of putting files into the system takes time. We also do not write CAD software: the design program you use stays where it is, and we manage the versioning, the relationships and the approval flow of the files it produces. Editing geometry inside a 3D model, automatic dimensioning or stress simulation are not within our scope. Nor does having the system in place remove, by itself, the old printout in the foreman's hand; how the printouts that reach the shop floor will be controlled is designed separately. Drawing the scope this way from the outset is better than creating an expectation that cannot later be met.
Companies that design machines, lines or moulds to order. On every job, files copied from the previous project and edited by hand pile up; which configuration went to which customer can only be worked out by opening project folders one by one. Engineering data management makes that accumulation searchable and also shortens quotation time when a similar job comes in.
Manufacturers running seasonal patterns, colour variants and sampling processes. When the recipe a sample was woven to, the variant the customer approved and the version that went into serial production are not held in one record, the same sample is produced twice. Which sample was sent to whom and on what date, and which of them converted into sales at the end of the season, are read from the same record.
Manufacturers with a large number of variants adapted to each customer. A change to a single part in the bill of materials affects dozens of products; where that impact is tracked by hand, production with the wrong material becomes inevitable sooner or later. Impact analysis is felt from day one in these companies, and the order from which a revision takes effect is also put on the record.
Companies working with automotive, defence or corporate export customers, which are asked to prove the history of their technical documents. A record of which revision came into force, when and with whose approval, is one of the first things asked for in an audit. The same record also shows which revision a product was built to when a customer complaint arrives later.
CAD files, technical drawings, recipes and specifications are held in a single vault. A version history is kept for every record; old versions are not deleted and remain accessible in the archive. Instead of the habit of writing "final" into a file name, the principle is that the system tells you which version is valid. Alongside the file, the product, customer and project it belongs to are held as attributes, and searching runs over those fields.
Two people working on the same file at once and overwriting each other's work is prevented. Whoever takes the file locks it and, when finished, puts it back as a new revision. Who changed what and when stays on the record; what usually settles a later argument is that record. A short change note is mandatory for every revision, and forgotten locks are released automatically on a timeout.
Every technical document carries a status: draft, under review, approved, revised, withdrawn from use. The approval flow is set up by role, and no document counts as released to production without approval. The revision number and the status appear visibly on the printout that reaches the shop floor. When an approved document is revised, the previous version automatically drops to obsolete, and the right to change a status is limited by role.
Technical files are linked to the parts in the bill of materials. When a part is revised, every product and assembly that uses that part is listed; what the change will touch is seen before approval. In practice this is the step most often skipped, and the most expensive one when it is. The same relationship is also read in reverse: which parts, at which revisions, are used in a given product comes out in a single list.
A change request (ECR) is opened, with its justification and the items affected; if approved, it becomes a change order (ECO). The order states the effective date and what happens to existing stock and to orders in progress. A revision therefore stops being something that happens without anyone knowing. Announcing the change to production, purchasing and quality also happens within the same flow, and every closed order stays in the archive.
The sample request, the recipe the sample was made to, customer feedback and approval status are tracked in a single record. By collection, you can see which variant went to which customer and which was taken into serial production. The recipe of an approved sample is handed straight over to production. Sample cost and the time spent are recorded, and the reason for rejected samples is kept separately; the total sampling load of a collection thus becomes measurable.
Searching runs on part number, material, customer or attribute; if a similar part has been designed before, it is not drawn from scratch. Access to files is limited by role; documents to be shared with a supplier are released under a separate permission and with a record of who downloaded what and when. Withdrawn files do not appear in search by default and are called up from the archive on request; that alone reduces the use of the wrong file.
Together we map out where files sit today in the engineering office, what naming is used and how a revision is announced at present. In most companies there is no written rule here; the first job is to make the rule that actually operates visible and to show where its gaps are. This stage usually takes one to two weeks and is run together with the engineering office.
How part numbers, document codes and revision notation will work is agreed in writing. This step looks technical but is really a management decision; changing it later is costly, so it is settled before a single line of software is written. If your existing numbering works, we do not change it; the price of changing it is usually greater than the benefit.
The system is set up and existing files are migrated. Rather than moving everything, we start with the products still in production; the older archive is left to a second phase. Weeding out duplicate and dead files during the migration is the most laborious but most valuable part of the job. Files are tagged with their attributes, otherwise search is useless; this stage can take four to eight weeks.
Approval roles, document statuses and the change order flow are switched on. They are first tried on a limited number of product groups; if the flow jams on the floor, the number of steps is reduced. Too many approval steps are the most common reason for people working around the system. Which changes do not require approval is also defined; putting every small correction through approval locks the flow.
How an approved revision reaches production, purchasing and quality is wired up, and integration with the ERP or the production tracking system is built. The system is handed over to your team and the rules are left in writing. Over the first months the number of revisions and the approval times are monitored together; if the flow jams, it is simplified. The source code and all engineering data are delivered to you.
PDM is the management of technical files and revisions: which file is valid, who changed it, which part it belongs to. PLM covers the product's whole life, from idea to serial production and from revisions to withdrawal from production; change management, the sampling process and bill of materials relationships belong here. In practice most companies come to us with a PDM need, because the pain is the wrong drawing. The implementation starts with PDM and widens towards PLM as the change and sampling flows are added. Trying to build full PLM from the outset carries the risk of producing a system nobody uses.
No, and we do not go into that area. The design program you use stays where it is, and design continues to be done there. The layer we build manages the versioning, the relationships, the approval and the archiving of those files. Editing geometry inside a model, automatic drawing generation or stress simulation are outside our scope. What we do is pick up where the design program leaves off, turn the file into a corporate record, and get that record to production, purchasing and quality in the right form.
They will not clash; the two look at different bills of materials. The tree in the ERP is for production and costing: material, quantity, unit. The tree on the engineering side carries the design relationship: which part is in which assembly, with which drawing, at which revision. The correct setup is for the revision approved on the engineering side to be transferred to the ERP under defined rules. If you use Logo, Mikro, Netsis or Canias (Turkish ERP products), this system does not replace them; it works alongside them and feeds them approved data.
No, and generally we do not recommend it either. You start with the products still in production; the unused old archive is left where it is or transferred read-only. The real difficulty in a bulk migration is not the copying but weeding out duplicates and files whose validity nobody knows; that work takes the engineering office's time as well. Keeping the scope narrow is better than locking the project into months of file cleaning.
This is a real risk and it is the reason behind most failed implementations. The source of the resistance is usually the extra load: if there are ten fields to fill in for every file, nobody fills them in. That is why we keep the number of mandatory fields to a minimum and place the saving step inside the designer's normal flow. One further condition is that the shared folder be made read-only on a set date; as long as two sources stay open in parallel, the old habit wins.
A versioned technical file archive, with the valid revision clear from a single source; locked editing with a complete change history; approval flows and document statuses by role; bill of materials links and impact analysis; the change request and change order process; sample and collection tracking; searchable, permissioned access. The source code, the database and all engineering data belong to you.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
We take buildings, floors, rooms and desks into a single inventory, and run lease and subscription contract dates, planned building maintenance and the inspection schedule for fire and safety equipment in the same system. The cost of running the facility thus becomes visible by building and by area.
Details →We build a human resources layer that brings employee records, documents, leave and absence, the organisation chart and employee self-service together in a single record. It does not replace payroll; it prepares the data that goes to payroll accurately and traceably, and it connects to the timekeeping and PDKS (time and attendance) side through the same employee record.
Details →We build a system that runs the whole candidate process in a single flow, from drafting the job ad through to the offer and the handover to onboarding. Whichever channel applications arrive through, they collect in a searchable pool, assessments are written on a shared form, and retention periods and data destruction are put on record.
Details →We give every rack and bin in your warehouse an address and record every movement by barcode. From goods receipt to put-away, from pick routing to dispatch checks, the flow runs on handheld terminals; underneath the quantity figure in your ERP we add the physical location of the goods and who moved them, and when.
Details →We capture incoming, in-process and final inspection records on a tablet on the shop floor; when a non-conformance appears we quarantine the goods, start the corrective and preventive action (DÖF / CAPA) flow and follow it through to closure. Measurements, certificates and approvals accumulate by batch, so you go into an ISO 9001 audit with a file that is already prepared rather than one assembled retrospectively from binders.
Details →Working from your bill of materials (BOM), we calculate which material is needed, in what quantity and by when; then we deduct stock on hand, open orders and lead times to produce dated order proposals for purchasing. With the MRP II layer we also test the same plan against machine capacity and labour.
Details →
