One of the great benefits of developing automation capability in your company is that you can then take advantage of many of the terrific cloud-based interfaces in your business operations. This allows you to improve your operations much faster and at a much lower cost than you could otherwise.
For example, say your operations staff use a customer support system that does not have a machine learning triage function to allow them to automatically route requests to the right person tagged with the right level of importance. You could replace your entire support system with a new system but that might take months or years and would carry significant costs and risk of failure.
However, once you develop automation capability within your company, an alternative approach to would be to automatically route your cases to a cloud-based machine learning system that would categorise cases in such a way that you could automatically route them to the appropriate support person. This automation + cloud-based interface approach might take days or weeks to complete at a very low cost with low risk of failure.
One recent project with a client involved comparing the two approaches (replace system vs automation + cloud-based interface) in a formal tender. The automation + cloud-based interface came in at 1/20th the cost of the replacing the system.
Cloud-based PDF and scanned document data extraction
Once of the ways we take complexity out of your automation work is by using solutions we have an established relationship with. A good example is our PDF / scanned document data extraction solution. Converting PDFs or scanned documents to data is a common process across our customers. So we have built an online solution that allows our customers to securely send PDFs or scanned documents and receive back data.
Our customers use their automation capability to send the PDF or scanned documents to the service and handle the data once it is returned from the Cloud-based data extraction service (e.g. enter it into their ERP system). We take care of the non-trivial piece (converting the document to data) and our customers take care of automation piece.
SAP journal creation
Another example is creating journals from SAP reports. Our customers automate running reports from SAP using their automation capability. They submit their reports securely to our cloud-based conversion solution that creates journals and consolidated reports. Our customers then use their automation capability to submit these journals into SAP.
Note the similarity in design of this service and the the PDF / scanned document data extraction. Once your team learns how to automate submitting the data to the services and putting the extracted data / journals into your ERP system, they can utilise these services with no involvement from us.
Feed your reporting
In addition to being able to take advantage of cloud-based interfaces, one of the other great things about automation is that every action can be reported on. As the automated process does its thing, it can push events to a data store that can be used to feed your reporting.
Do you want to see the activity across your company and how it is changing over time. Easily done.
Different approaches to the reporting workflow
Reporting projects have one of the highest project failure rates in IT. One of the main contributors to this failure is it is very difficult to determine up-front how to structure all of the data you will be collecting. And, in order to set up the reporting system, you need to do this at the beginning of the project before you have collected any of the data.
We take a different approach. We put all of the data into a datastore as we collect it in the format that it most easily goes into the datastore. Once it is in the datastore, you can query it in different ways to get the reports you want.
In IT lingo, this is called an ELT approach rather than an ETL approach. The 'E', 'T' and 'L' stand for Extract, Transform and Load. A typical data warehouse or data lake project involves Extracting data, Transforming it into the structure required by the database and then Loading it into the database. The ELT approach involves extracting the data, loading it unchanged into a data store and then transforming it when you run reports. Click here to read an article on the ETL v ELT approach.
Our approach to the reporting workflow
Our approach is similar to the ELT approach. We call it CSQ. In this approach you create (extract) the data as part of the automation work, store (load) it into a datastore and, then, when it comes time to generate reports, query (load) it into the reporting solution at the end of the process. So it can be described not as ELT but as CSQ - Create, Store, Query.
In the diagram below, the red shapes in the ETL process are typically done by developers.
The green shapes in CSQ process can be done by your staff using the automation tools they have become familiar with during their work with My business, automated.
What reporting systems can we use?
One of the advantages of this approach is that it doesn't matter what reporting system you use. You can just as easily use commercial systems such as Tableau, Microsoft Power BI or Looker as you can an open-source alternative such as Dash.
Security and data sovereignty
Security considerations are top-of-mind in the design of the shared capability. Data is encrypted on the client, encrypted in transit and encrypted at rest in the cloud. Data is completely isolated across clients.
We use Amazon's AWS infrastructure and can utilise any of the regions that AWS is available in to host the shared infrastructure. This means that your don't have to worry about data sovereignty. Your data remains in whichever jurisdiction you require it to remain in. Here is a list of locations currently supported.