Individual pieces of data must be liberated from the static document and free to be used where and how end-users need them.
This is the first in a series about the principles of the Transform Manifesto. If you want to start at the beginning, go here. When you’re ready for the next one, go here.
For a long time, having all the right engineering documentation was all you needed to get the job done. Up until the mid 1990s, that meant piles and piles of paper documents and drawings. In the late 1990s, all the non-GD&T (Geometric Dimension and Tolerance) information such as industry specs and standards, technical data packages, work instructions, test methods, and internal corporate standards, moved from paper to PDF. At the time, it was a revolution that increased speed and enabled easy sharing – but PDF was never meant to be an engineering information tool.
Amazingly, not much has changed since then: most engineering documentation is in PDF format. This means that all the text, graphs, tables, equations, images, and references that comprise manufacturing notes, part/material/process attributes, requirements, test methods, work instructions, supplier instructions, customer requirements, and more are trapped in static PDF (and sometimes PowerPoint, MS Word, or even paper). Nearly every information user in the product development lifecycle struggles to find the precise information they need, extract the relevant data for the task at hand, and feel confident they are using the right versions and references in a sea of disconnected, static documents.
An engineering document is essentially a vast collection of individual pieces of data that engineers need to do their jobs. We believe these individual pieces of data must be liberated from the static document and free to be used where and how end-users need them.
If a worker needs the hole drilling requirements, they should be able to call them up quickly and easily and feed them into the machine. Better still, the machine should be able to extract them on its own and take action based on the data. If you need to share a complex table of values with a supplier, you should be able to extract the values and variables and transfer them easily while maintaining fidelity (and copyright ownership) to the source document. The supplier should be able to receive them in the application in which they are working. And if a change is made to the source document, the supplier should receive a notification of that change.
What is context? Each piece of data is more than just letters or numbers: it has a purpose, it conveys meaning, and it has a relationship with many other pieces of data. Context describes what you can’t see in plain sight and explains why a piece of data may be important to you.
We also believe that each individual piece of data is more than just a jumble of letters or numbers: it has a purpose, it conveys meaning, and each piece of data shares a relationship with many other pieces of data. This is what we mean by context.
Context is the nuance, the unwritten but implied, the actionable intelligence that helps us better understand and use the data contained in the documents. For example, from context we can glean part, material, and process attributes (such as a process that involves hazardous materials). We can determine whether a prescribed process is dependent on another process or requirement, necessitating one process to come before the other in a project timeline. Using context, we can more accurately identify candidates for additive manufacturing. With context, we can quickly and easily qualify vendors as suitable or unsuitable for a particular task.
For many decades, the general wisdom in the information economy was that “content is king”. Today, content is still critical but context is becoming ever more important. By turning documents into data, we can identify, extract, and deliver the contextual and actionable intelligence that users need to make better decisions faster. If content is king, then context is surely queen.
The SWISS platform transforms engineering documents and drawings into interoperable, intelligent, and reusable collections of data that integrate seamlessly into modern engineering workflow. SWISS combines content, context, and software to reduce manual labor and deliver insights that help individuals make better decisions faster.
What do you think? Does this resonate with you? If you think it’s time to shift from documents to data and from content to context, let’s talk.
Ready for the next in the series? Go here.
If you want to read all seven principles of the Transform Manifesto, start here.