Integration in process
Colin Fowle, Managing Director at Blue Car Technologies, outlines how systems integration needs its own system of process management
We recently collaborated with a legal software vendor about how we might make a software offering work with a well known document management system. There was a deep discussion around the merits of each technology – which platforms were supported, and whether there was a document application programming interface (API) and authentication mechanisms.
But then the conversation came round to the integration between the two products improving the overall experience for the end user (ultimately, of course, the lawyer). After a pause, the vendor observed the software would only need to send documents to their system, and then “put them back when done”. In a sense, it’s an admirably concise statement about what’s required in such a process. But the devil – as always – is in the detail. Blue Car Technologies builds integrations between many systems, from document management and collaboration platforms, through digital dictation, to electronic signatures and digital transaction management. Each project has different requirements from the software vendors about how they would like the integrations to work. But several processes are similar – with the improvement of the overall experience for the end user as a common goal.
First, we must understand the process from end to end. We do this by talking to users to appreciate the steps involved, and volumes of data or transactions, from their perspective. We’re looking for the pain points the user could experience. That will typically be laborious, time-consuming or repetitive actions – which make using the systems together difficult or cumbersome.
During this analysis we will look for user interface (UI) elements in the systems and the interactions the user must perform to make a process take place. Could these now be optimised in new ways by building additional UI elements to sit on top of both systems (or indeed by utilising the APIs provided by each vendor’s system)? Security implementation of each system also needs to be considered, and how data will be exchanged between them. Are both systems on-premises or in the cloud, or do we have a mixture of the two? Can the systems authenticate and work together seamlessly, or is some form of transformation required? Many cloud systems implement OAuth (open standard for authorisation) or a flavour of OAuth for user and integrated application authentication. This often requires the caching of access tokens outside of an internet browser environment. But is this acceptable to those managing the end users?
Automation options
Finally, we look to see if any user interactions with the systems can be further automated for greater efficiency. Again, looking at the underlying APIs for each of the systems, if they're well documented we can get a good idea of their functionality. In the initial example, for instance, it was found that new versions of documents could automatically be created back in the document management system, after a digital signing process. The user was spared the task of having to re-profile the document themselves. Hopefully this gives a flavour of the thought and business improvement processes passed through to build a seamless integration between systems. There are, of course, others that may be suitable depending on the availability of well-documented APIs, access to data models, and the strength of the partnership with other legal software vendors.
To learn more about Blue Car, visit www.bluecartechnologies.co.uk