We currently get a lot of enquiries asking whether we can “construct” interfaces between an editorial system or CMS and another application (e.g. an ERP system). The general answer is: of course we can (although we do, of course, need to assess each individual case).
However, the intention of the enquiries is clear. The aim is to generate documents as automatically as possible, ideally without human intervention – and their generation should be triggered by, for example, an event in the ERP system (“production order created”) etc.
But why is this such a hot topic right now?
Partly, of course, it is because of the general trend in the market towards demand for personalised and highly-connected products – or because such demand is expected (“Industry 4.0”). Furthermore, many companies have introduced editorial systems in recent years with the aim of optimising the creation of technical documentation in both quality and economic terms. But even if a powerful editorial system is in use, the business of creating documentation, specifications, and offers can still be laborious and error-prone. These difficulties are mostly due to the fact that content from different systems needs to be integrated.
As a result, plenty of unpleasant work needs to be done. Drawings, test logs, existing content, etc. need to be collected, examined, and integrated. All these chunks of information have to be available in the right version, at the right time, etc. If something is missing, a nerve-racking search for that “something” begins, usually whenever we are already running out of time.
Putting publications together by hand is thus complex, expensive and error-prone – and even often unnecessary from an IT perspective.
Which brings us back to interfaces between contiguous systems and the editorial system. They can be used to ensure that, for example, when a technical drawing for a specific product changes, the drawing is made available immediately in the editorial system – along with useful information (e.g. order number and version of the drawing).
In technical terms, the data transfer from system to system is a comparatively trivial and very well-known matter. The more interesting question is: "How can useful data be transferred?" So: How does a technical drawing automatically find its place in the relevant publication? The answer to this question has less to do with interface programming and more with meaningful metadata and classifications – after all, content is supposed to be assigned automatically.
So, how do we proceed? Once we know what information needs to be transmitted, the next important step in an interface project is to look at the metadata. What is there? What is compatible? What can be made to fit (i.e. where can metadata be mapped onto each other in a rule-based way)? What is not possible?
Then we come to aspects relevant to IT: What type of interface should it be?
How long does it take to get from the specification of an interface to its implementation? There is no general answer, but this is a typical case of “it depends”. Is it about one interface or many? Is there a usable metadata concept (e.g. in the form of parts lists in the ERP system)? Is it about a file interface or API programming? Previous projects have taken anything between a few days and several months.
Either way, a return on investment is usually achieved after a short time.
