3 thoughts about quality software integrations


    Seems like it should be simple to have different software systems just pass data back and forth.

    And these days, with the careful, thorough and customer-centric development I see at Qualio, it finally can be.

    But I’ll freely admit that I’ve been skeptical in the past on this subject. I’ve worked with many different systems in my 20+ years in this industry, and historically I’ve not always seen integrations work well.

    The worst example I’ve seen in my career was in the complaint handling space at a company I worked at about 10 years ago.

    Let me tell you the story, and what I learned from it.

    Back then we used Oracle, where all our product and customer information was housed and where our customer support team spent their days.

    And we had tens of thousands of parts, and thousands of customers.

    So it made sense to keep that information there, and we integrated it with our eQMS for complaint handling purposes. (This eQMS was one of the large, well-established QMS tools at the time.)

    We then implemented Salesforce as well, for the field sales and support staff. As is typical in the quality space, it’s hard to get people to work in the QMS if it’s not their primary responsibility. So the idea of information passing between systems with an integration really was a way to solve our compliance issues (namely: folks not reporting product problems in a timely manner). 

    Sounds like a great idea, right?

    In execution, we had some small challenges right off the bat and we were forced to work through those.

    But the real issue didn’t happen until later.

    We've launched this massive integration.

    Everyone is happy.

    Customer support teams are in Oracle.

    Sales folks are in Salesforce.

    And the quality team are happy they don’t have to log into 3 different systems to do their job. There’s little things to work out, as there always can be with a new software tool and organizational change, but it’s going well.

    Fast forward a bit, and we have a Medical Device Reporting (MDR) situation happening in one of the accounts.

    The field rep is gathering all the information, as they’re supposed to. The complaint specialist is also doing their job, and reviewing all the quality issues that are pulled across to the QMS, based on keyword searches running in Salesforce.

    Somehow, one of the VPs knows about this complaint and asks for a status.

    So, to the QMS we go!

    No complaint found.

    We go to Salesforce and find the account notes. Oh dear… there are tons of entries made by the field rep in real time, but nothing in the QMS.

    The complaint team springs into action and files the MDR (already late at this point!), and an investigation with our small army of business analysts begins.

    The problem?

    Oracle didn’t like names with a hyphen in them. 

    So our multi-system integration, based on seamless passing of data into the QMS, was ruined by the different database rules between the applications.

    When any of the 3 systems involved didn’t like the data it saw, it would stop flowing.

    Why didn’t we discover this during integration testing, you ask?

    Or during validation?

    Well, the devil is always in the details.

    While all systems were housed on-premise, and all were the versions that ran on an Oracle database in the background, the data rules in the application were simply not considered - by the eQMS vendor or by us.

    An assumption was made that since it was all Oracle-based on the back-end, the systems would just talk to each other with no challenges. 

    Ultimately, that vendor let us down.


    3 lessons learned


    1. Spec out the applications carefully

    Listen to all your team members, especially the naysayers who are probably speaking from past experience, and consider all those experiences no matter how improbable the situation seems. 


    2. Build realistic timelines and over-communicate

    Don't neglect unscripted testing. The idea that you can imagine and cover every single scenario in a validation exercise is false, but you can give yourself time to get as close to 100% as humanly possible.


    3. Choose a reputable vendor

    The integrations work taking place at Qualio is exciting, innovative, and - most importantly - driven by careful quality planning.

    The lessons I learned 10 years ago have been applied to our development methodology to ensure our integrations are as easy and powerful as possible for our customers, who won't need to face the same issues I did.

    Ask questions as you search for an eQMS vendor, do your due diligence and don't jump in if integrations are important to your operation and you aren't completely comfortable.