Philip Sargent
12 June 1997
Mechanical engineering organisations were the first to discover a need for Product Data Management (PDM) software, but, once developed, this type of software has found many uses outside its original areas of application.
Product Data Management software manages engineering design information through the transformation from prototype design to a product in full production. It is a recognised market with several segments and more than a dozen internationally competing software products. There have been regular exhibitions and conferences devoted solely to this market since about 1993.
Product Data Management (PDM) software integrates with, and partially substitutes for, other software used by engineering organisations such as CAD (Computer Aided Draughting/Design), Engineering Document Management (EDM), Document Management, Free-text Databases, Manufacturing Resource Planning (MRP), and Workflow/Groupware (Wf).
The PDM market became recognisable only when there were sufficient numbers of software packages available which addressed a broadly recognisable set of related engineering design needs. Before this, there was much debate about the differences and relative usefulness of drawing-centred versus project-centred, image-centred, product-centred, or process-centred approaches.
Now the interest has moved on and the more pressing need is to be able to anticipate how software companies plan to meet these PDM requirements. Can established software provider organisations understand the PDM technicalities well enough to sell packages and support users ? Is the software they have technically up to the task ? Is it possible to meet the needs by enhancing the current software product ? Could a software provider organisation cope with purchasing or working with specialist PDM software producers with a radically different point of view from that of the traditional MRP or CAD markets ?
Nearly all the large CAD software companies have drawing and document management add-ons to their products. These support check-in/check-out of drawings which may be "issued" or "on change". However only some people in these companies are conversant with how groups of engineering designers working within a complex organisation need a quite different type of software. Draughting with a CAD system is fundamentally a single-user activity and the engineering CAD file management is centralised, whereas early design of complex products is typically done in decentralised groups.
The core technical expertise in CAD companies is the management of 3D solid geometry and sophisticated user-interface design for 2D draughting.
The first software support for designing complex products in large organisations was Engineering Document Management (EDM). The focus here is to treat the design process as essentially a set of sub-projects which produce a large number of different types of documents: requirements, schematics, drawings, test reports etc. The classic examples are the procurement and design of large military systems, spacecraft and nuclear power plant. These types of project involve formal exchanges of design and contractual information between organizations: customer, suppliers, subcontractors, regulation authorities, test laboratories etc.
Maintaining distribution lists and recording sign-offs, acknowledgements, and clarification requests is a natural task for a tabular database since only a standard set of information is stored about each document. These databases thus stored only the "meta-data", the data about the document and not the document content itself. They are better thought of as project-centred rather than document-centred since it is the document distribution which is recorded. The PDM market started here with mainframe databases accessed using text-only leased-line terminals.
The core expertise of the EDM market leaders is selling multi-million dollar systems to the top management of very large engineering organisations. The technical base is a capability to provide reliable availability to large numbers of users at many sites and an accumulation of large numbers of standard reports.
Companies operating in general commerce and finance were the target for the Document Management package providers. This software market segment started as simply scanning and indexing paper documents for small groups of users and grew out of the microfilm industry. The indexing databases grew more sophisticated and new technologies were developed for the efficient networked delivery of scanned images.
The core technical expertise is in the acquisition, transformation, compression and delivery of bit-mapped images.
Free-text databases grew out of the on-line mainframe database market for legal and commercial information and from computerised newspaper clippings and military intelligence libraries. They allow a query to be phrased in terms of any combination of words which may appear within the body of any document. This requires the maintenance of an index of every significant word in the entire data holding. Usually very little meta-data is held about each article, retrieval is limited to returning a list of article titles or the entire article text.
These systems invariably require specialised, proprietary database and indexing structures and can not be hosted on relational database systems. The popularity of the World-Wide Web has produced a recent proliferation of sites offering free access to full indexes of World-Wide Web documents: currently numbering in the tens of millions. These have not been sold much for specifically engineering purposes but have been used to find information hidden in email archives.
The core technical expertise is algorithms that efficiently parse different corpuses of English language, remove plurals and cases from verb stems, index structures that store synonyms, and evaluation algorithms that rank lists of results by "relevance".
Manufacturing software systems maintain a "Bill of Materials", the breakdown of components from which an engineering product is constructed and when and from whom they must be purchased. They manage stock control of raw materials and semi-finished parts. Modification of product structures is through formal change control using standard data entry "screens".
These were the first large mainframe systems that directly affected engineers work. Their introduction into manufacturing companies is still fraught with problems twenty years after they were first bought it any numbers.
Proprietary database structures were common until this decade but now relational systems are nearly universal for modern systems. The mainframe model is still universal, slightly modified to client-server with PCs and large Unix boxes for the most modern systems.
The core technical expertise is a vast suite of standard data entry and reporting utilities all working to a common core of stock and financial information. The systems offer very high reliability and availability. Several ways of structuring or viewing the component makeup of a product may be available and production scheduling requires subtle algorithms.
This is an immature market with a great deal of confusion surrounding it. There is a spectrum from informal email and bulletin-board systems to rigid pre-programmed case handling systems, e.g. for insurance claims.
Workflow systems fall roughly into two categories, either routing oriented or process oriented. Routing systems are the simpler type where a single key document is passed along a process of categorisation, approval, and signoff; carrying with it its current status and who it has to go to next. These can be implemented purely on top of email but most packages use a central database to monitor progress.
Process oriented workflow systems are possibly the most intrinsically complex and sophisticated software systems in use in organisations. For example, a specific engineering change calculation by a junior engineer may need to be signed-off by the original designer, the senior electrical designers attached to all the projects using the product to which the document applies (but only if it relates to an electrical change), a company safety officer if the document is categorised as a "safety-case", the customer if the document implies an over spend of more than a certain amount, depending on the type of contract under which the work is undertaken. The information needed to make these categorisations and decisions will not all be held in the same place or available at the same time.
The process management has to happen asynchronously on distributed PCs or workstations connected by unreliable and/or low-bandwidth communications. Ideally, the company process embodied in these software systems should be understandable by non-experts, configurable by non-programmers and easily-changed without compromising the integrity of work currently in progress.
The core technical expertise varies from user-interface design and standard client-server technology for the simple, end-user configurable end of the spectrum, to highly abstract computer science research for the complex systems.
Good Product Data Management systems provide flexible product assembly structures supporting complex relationships between parts, drawings, supporting documents, meta-data, people and groups of people. Roles and responsibilities may be represented for project control and will always be present for access control.
The engineering content of CAD files, scanned-images and word-processed documents will be stored in a secure vault and free-text indexes may be available for the text documents.
Check-in and check-out of documents and drawings is part of a simple change control and document distribution process which can elaborated by custom programming: either by using the PDM systems' own scripting language or by making calls to its published API (application programming interface).
Thus PDM covers some of the key core technical capabilities from each of the related software markets. There is a wide spectrum: the most innovative are new and cannot boast a long history of trans-continental reliable operation, the easiest to learn do not have the depth of those offering complex relationships and those constructed as a collection of separately-developed mature packages have extensibility and scalability problems.
The question of which type of software company will dominate the PDM market is an open one: it could be one of the CAD, MRP or PDM companies, but probably not from the document management or workflow producers.
The document management and workflow software producers see engineering design organisations as a niche market with limited funds for software acquisition compared to the generic finance and general management markets. Thus although the largest software producers are to be found in that area, e.g. the Lotus division of IBM, they are unlikely to want to modify their core software to suit the rather specific needs of engineering design.
The large MRP companies see PDM as their natural territory and find it hard to understand why engineering companies need anything other than what is already in the extensive and customisable MRP suites. There is both a technical and a commercial reason why MRP companies do not now and may never understand PDM well enough to support it properly.
CAD companies also have mind-set problem with PDM, though different from that of the MRP companies, but they have an overwhelming commercial need to learn how to do PDM properly because CAD is increasingly becoming a commodity.
Computervision has declared that its is a PDM company and coined its own phrase "electronic product definition" to mean PDM, or as much of PDM as the current collection of their software packages can manage.
SDRC has for some years had a CAD product effectively as a secondary emphasis compared to its analysis suite, and has now fully bought Metaphase which was one the first non-mainframe and object-oriented PDM companies.
There are a handful of independent truly innovative and purely PDM companies selling software today which goes well beyond that available from the CAD and MRP developers. Some will be bought by CAD and MRP companies; those bought by CAD companies may end up in charge as PDM becomes responsible for much of the revenue.
The remaining independent PDM companies can probably only flourish by making close partnerships with the large systems integrators and international management consultancies, e.g. Anderson's or IBM. That can continue so long as the PDM software components do not become commodities since as the partnership continues the intellectual understanding of PDM-type problems would come to reside in the consultancies as well as in the PDM companies.
In the long term, the common computing platforms will acquire some workflow-like functions as standard (Internet mail client software is already free with Microsoft Windows 95) and the existing workflow software companies will also have to manage processes containing increasingly complex databases. Thus it may be a small step for them to absorb the engineering PDM market by providing commodity software to systems integrators. However by that time the workflow market will have segmented and perhaps none of the categories discussed here will have any relevance at all.
(C) 1997 Philip Sargent.