In this day and age, you would think that every system would have been interfaced with every other type of system. That’s probably true. But it’s NOT true that every individual system has been interfaced with every other individual system and that’s where most of the challenges are.
Vastly Different Systems
When we interface vastly different systems, such as a LIMS and an accounting system, we know it’s going to be difficult. Despite any chargeback module a LIMS might have built into it, most people know it won’t be similar to the work the accounting system does. This type of interface is difficult but we know that the databases and features will be entirely different. As such, we can be prepared for the level of difficult in this type of interface.
Somewhat Similar Systems
This is where we run into problems. When we expect similarites in systems, it’s not uncommon that we don’t realize the challenges we’ll face.
For example, let’s look at an ERP/MES/QMS (Enterprise Resource Planning/Manufacturing Execution System/Quality Management System – and, by the way, here’s some proof that the manufacturing side of things gets crazy with making up new acronyms for the same things just as we do in laboratory software). One example of this would be SAP.
The problem is that these types of systems sometimes have modules that do sampling. And, if we’re sampling from something called a QMS to a LIMS, which both has samples AND is also sometimes referred-to as a QMS, shouldn’t they be about the same?
Obviously, the databases will be different. The tables and fields will have different names and different structures. But even beyond that, the processes are different because the purposes are different.
On the manufacturing side, you sample to check the quality. The sample is what you take from the product. It doesn’t matter if it’s 100 grams of dry material, 100 tablets of a pill, 20 bottles of liquid to be sent to different areas for testing – all of this is one sample that will be tested in order to give a pass or fail on the product.
In the past, I have talked about how a LIMS (or ELN or LES) sample is not necessarily a physical sample, to begin with. It is merely a sample record in the database. And this is where some confusion comes in.
In addition, as we continue to get new software and continue to do new interfaces, we continue to have entirely new groups of people doing these interfaces that don’t know that.
So, if we were going to interface SAP to LabWare LIMS or SampleManager LIMS to JD Edwards, these are all fairly old systems. Now, I should add that there are always unique aspects to interfaces based on the fact that every implementation is unique to a customer, but let’s just look at the fact that some portion is more predictable, for many cases.
Then, because all these companies have been around for so long and there are so many services groups dealing with these interfaces, we would expect that experience is passed along and that every interface team has a basic understanding of the issues. While that’s not always true, it’s at least possible.
But when we interface any system that is a newer system, the team tends to be new to the interface and concepts, as well. And this is an area where we also run into issues. New software vendors don’t necessarily hire experience people from SampleManager or SAP because many want a fresh view of things. But a fresh view not only means big, new ideas, but it can mean a lack of knowledge of the issues that don’t change, such as the issue of “sampling.”
In the End
Interfacing projects need someone on the team who understands how all this mapping works from a high level, even if they don’t know the specific systems involved, although knowing the specific systems is an additional advantage. If the services vendor or vendors involved don’t have such a person, then if a customer can find someone on their own who has this knowledge, this is a way to pass this knowledge onto the rest of the team to make the entire interface go more smoothly.