An important part of creating a technology solution is to be able to recognise the business problem you are trying to solve. The first thing to ask is why do you want to automate? there are some compelling answers to this question. You can save money, you can consistently repeat the task without needing someone to be present and you can drive efficiencies.
But when it comes to automating systems, “Integration” often muddled up with automation, but you should think of integration as a distinct function that enables automation, they are most definitely not one in the same. Integration is generally very technical and involves code that calls an API, transforms the request and response data from each system so they can understand each other, and because systems are often so diverse, and even with alleged “standards” the only really practical way to do this is with what I call “Glue Code”. Implementing integrations does generally require a high level of technical expertise, and in the world of IT automation that invariably means a business manager will ask IT people to implement the automation of the IT tasks that need to be automated. But that is a fundamental problem because unless you are technically proficient yourself, technical people rarely view a high level requirement in the same way you will, and as a result you will almost certainly fail to achieve your objective. The best way I can explain this is through a story I told recently at a customer event. I have borrowed my actors from the TV Sitcom “The IT Crowd” to help illustrate the problem as I see it.
A Hypothetical Situation
You are Jen, the head of IT, your organisation has a high turnover of contract staff, you are a smart business manager and you realise your team is spending an average of 20 minutes of time each and every time you create a new user on your systems, you are doing this about 25 times a week on average.
You have some complex systems, and without any automation, the only way you can be 100% sure it gets done right each and every time is to ask “Maurice” to do it – “Maurice” is the go-to guy for creating user accounts in your IT team.
And of course, like any manual process there are problems…
- No one values Maurice’s work, creating user accounts seems like a trivial task and does not really add business value.
- Maurice often feels undervalued and wishes he could be doing something more interesting but he is the expert and has to do it because no one else can do it right.
- Things are difficult when Maurice is on leave or unavailable, no one else knows how to do this properly… not even Maurice’s closest college Roy gets it right all the time.
You realise that if you can automate this one task you can not only mitigate the above problems, but a simple calculation would tell you in this situation, if you can automate the process of creating new users on your systems you will free up around 8 Hours a week of Maurice’s time. So, what is the next logical step? It is obvious, right? you sit down with Maurice and the following dialect ensues….
Jen: Is it possible to automate the new user task?
Maurice: “of course” he replies, that would be easy, I can do that, it will take me about a day.
Jen: Perfect, let’s get it done… (a day passes…)
Maurice: I have done that automation you asked for, it was a really good idea you had…
Jen: Excellent, can you show me… (bated with high expectations) I can’t wait to see this in action.
Maurice: Yeah of course, let me show you how simple it is…
The truth is, it was a mistake on Jen's part to give Maurice the freedom to automate this task, because while Jen was trying to automate a business activity, Maurice was actually automating the work he does by writing a script that only he knows how to use! This is “Maurice Automaton”, not “Business Automation”
Maurice has done nothing wrong here, he has done exactly what was asked of him, but Jen has failed because she did not ask for the right thing, and as a result she has not achieved her desired goal of automating a business task – Jen still needs Maurice to run the script each time it needs to be run, and the odds are good that the script is so esoteric that not even his team mate Roy will be able to use the script (eh hem, I mean automation) properly.
Viable automation needs to deliver a number of things
- First and foremost, demonstrable and repeatable ROI to the business
- Esoteric technical tasks MUST be exposed and expressed in a business language that anyone can understand.
- Must free up time so you can deliver “Higher Value” work for your organization
- Must remove dependencies on individual know-how
- Must be usable in practice by non-technical users
What Jen was really looking for was something presented in a format that’s expressed in a language that Jen, or any other business manager with a modicum of common sense would completely understand and could make use of. Something more like this...
In truth, there are a lot of tools out there that don’t recognise this problem but yield a great “get out of jail free card for sales”, which is just answer “yes” to the question can you integrate with XYZ. How? the response will be along the lines of “yes, we provide API’s and some form of web call mechanism, you can script pretty much anything, and we provide you a mechanism to do that”. IT and technical people like the empowerment of these sandbox development environments but it’s a dangerous road to go down because more often than not, customizing via code means poor upgradability and an inherent dependency on the expert who implements the code….
So that’s why I say not all automation is made equal. If you are Jen, Maurice or Roy in your organization you will only be able to deliver ROI if you can automate in a way that makes sense to the business.
Now before Maurice or Roy lynch me for trying to put them out of a job… the truth is, business needs IT (and yes that means you Maurice and Roy), and more now than ever before, so if you are thinking like that then you are probably being looked upon as a dinosaur in your organisation – you need to change that perception. Just think about it, in relation to this simple example above, you are no longer required to expend 20 minutes of your time every time a new user needs to be created, you can, and should now spend that time doing “Higher Value” work for your organisation, not only will that give you a more interesting and varied job, that will elevate your perceived value within your organisation, and on that day when that automation that you helped create goes wrong, it is you that will be called on to make it work again.
I have created a simple check-list to help you validate you have achieved real business value when you automate something in your organisation.
- Is the purpose, function, inputs and outputs of your automation accessible and expressed in terms that is clear, concise and non-technical for you business?
- Can your automation be run at will, without any specialist knowledge by a non-technical person with minimal or no training within your organisation?
- Will the automation always work when you are not present to babysit it?
- Does the automation you have created save more work hours in 6 months than it takes you to implement the entire automation?
If you have answered yes to all of these points AND your non-technical manager agrees with you – congratulations, you have made an automation that has real business value, you deserve a commendation.
This is what I had in mind when setting down our strategy for implementing integrations and automation on the Hornbill platform. We have a “No coding required” policy for customizations so when we came to extend our business process tool to include IT and business system integration and automation I wanted to stick with that policy, so its integration that’s flexible enough to be useful but is always accessible by, and expressed and presented in terms that our mythical Jen can use when building process automations.
In the next article in this series Hornbill iBridge - Integrating in the Cloud I will present our implementation of an integration technology that delivers real business value.