Building bridges between systems with automation

Since 1986, Kainos has delivered solutions that enable our customers to do their jobs.

This is true across a wide variety of problem domains in both the public and private sector, and includes tailor made software that has been coded from scratch alongside bespoke configurations of existing software products such as Workday, SharePoint and Dynamics.

It’s worth repeating - our software enables our customers to do their jobs.

Let’s not get too carried away though. Customers do not use our software alone - they use a myriad of other tools and services to do their jobs on a daily basis. They use communication tools such as email, Teams and Slack. They source data from multiple endpoints - local folders, network folders, cloud storage, third party APIs...etc. They use other systems too - perhaps the output from our software is the input to another (or vice versa).

In truth, our solutions are often mere components in larger customer processes. The interaction between these components is typically very manual, and thus slow. There is usually some sort of mapping required to make the output of one component work for another, and so the process can be very error prone. Work is transformed when processes are performant, not just components. Sometimes we lose sight of that.

Consider the following - a customer uses a system we’ve delivered. There’s a screen they can use to create a new user record. The screen itself is well laid out based on our UX expertise and has a responsive design. However, let’s imagine that the customer has to create 50 new records - using this form 50 times is tedious and error prone.

So we counter this by creating multiple record creation functionality - the customer uploads a CSV file of user data and all 50 records are created at once. We’ve tested this to ensure that it’s highly performant - problem solved? Not really - our software is just an efficient part of inefficient process - how much manual effort was involved in compiling the CSV file in the first place? No point in having functionality that works in seconds if the list took days to compile.

These are the sort of gaps between components that we in the Intelligent Automation practice are interested in. It’s about improving overall processes rather than individual components. Perhaps that CSV file from above has been created by someone manually copying data from Workday or an Active Directory group - we can build automations that not only compile this file from the source system, but also upload it to the target system too, alerting the end user of progress and any exceptions that need to be addressed.

There are several ways of accomplishing such interactions. Many modern systems such as Workday are underpinned by APIs that allow us to programmatically extract or upload data. For those without APIs, we can build robotic processes that emulate human interactions with such systems, right down to mouse click level. Processes can be designed to extract data from a source and perform rule-based mapping to generate an output that is fed to a target. The idea is to eliminate those monotonous, error prone processes that require little cognitive effort but take up so much user time. Doing so frees up users to deliver value in other areas of work where their expertise is required.

We’ve come to know many of our customers very well, beyond the software that we support. We know personalities and processes and what holds people back from delivering their best work. If you can think of any bottlenecks your customers experience - even around components that we don’t support - we’d be happy to chat with you about the art of the possible.