Categories: software
With CRM being this month’s focus area, making all your systems interact with each other is a key part of being able to get the data you need to feed your CRM system. Your project, therefore, if it has anything to do with IT, systems or data, probably needs some kind of interoperability approach in order to make it possible to pull relevant bits of information out when they are needed.
Think about it for a moment. If you design and build something that is completely standalone that’s good for a short while. But when you need to create a single view of the truth – a single customer record or report showing various data points – you will have to merge data from that system with data held in other systems. Which one is the master data? Even something simple like a customer informing you of a change of address becomes a problem if the systems aren’t linked.
What is interoperability?
Interoperability is that link between systems. This includes things like programming languages. When you are designing a product, think about the environment in which it will operate, who needs to use it and how it will link to, provide data for or send data to other systems. It’s often easier to think about information or data flow rather than the systems themselves, as these can be mapped on afterwards.
Using common standards and programming languages for system builds can save money and make it easier to find technical team members to work on your projects. Using open source tools, for example, is one way to build interoperability into your systems, but of course this will only work if your other systems use the same protocols.
Why is it important to your project?
No project is really standalone. Including interoperability in your design specifications as a non-functional requirement builds in future proofing. It also simplifies making links with other projects and systems which is especially important if your project is being carried out as part of a programme.
How do you get it?
You can’t design in interoperability yourself, although it doesn’t hurt to know that you need it! Involve your firm’s technical architect or, if you are using commercial off the shelf packages, talk to the supplier. A business analyst can help map processes and explain how the business users will actually use the system, so they can be really helpful when it comes to showing where the data comes from and how individual records are used and updated.
The best advice is to look at the big picture from the start of the project. Consider how things connect and consider what might be asked of the system or the project in the future. Of course, you can’t always predict how your new IT package will be used, but you can have a good guess. And you may find that users are already suggesting technical and functional changes that you are having to put into a bucket called ‘Phase 2’ for assessment and analysis later. These features may give you a good idea about the sort of things users will be asking for in the future so you can build in (or at least not shut any doors) for them.
Interoperability is probably already in your company’s technical strategy, so that’s a good place to start if you are building up your project requirements or including constraints in your project initiation document.
It isn’t the most glamorous of project requirements, but if you want your product – be that CRM or something else – to be useful and to be used, then it is worth considering from the outset.



