Let Me Set The Scene
Finished watching the video? Good. Now then, let’s put you in the same shoes as John. Picture yourself with the following scenario.
‘You have teams of people working in your IT department. If you are lucky, some aren’t overworked and stressed. You, their manager, are stuck between a rock and a hard place. You have requirements to improve efficiency and have a number of IT projects to deliver. Your staff just don’t have the bandwidth. They have too much work and are stuck in the rut of daily operations and break fix. Every day is the same. Every day is groundhog day. You need a solution, something new to motivate your staff, increase their efficiency, cut down on the daily repetitive tasks and get those projects delivered your managers keep talking about.
Whether it is reading blogs over lunch, a chat with a colleague by the water cooler or a presentation at a local user group, you keep hearing the same buzz words. Automation, orchestration and workflows. People are saying that their IT efficiency has increased, repetitive tasks are now done without the need for someone to get involved and user portals allow staff to request new services from the IT department and have the automatically provisioned. All thanks to adopting automation. This is fantastic! You have found your silver bullet!’
Follow the Yellow Brick Road
Over the next few months you speak to multiple vendors, trial some different tools and finally make a decision. You select a product set that will automate the majority of things you can think of. Breathing a sigh of relief you start dreaming of the future. Easy life, happier staff, automated everything. But, first things first. You need to prove this is going to work, so you decide to do a pilot. Picking on something easy, you decide to automate the new starter process. You map it out on paper and it looks straight forward.
You sit and stare at it for a while and then realise there is a fly in the ointment. One of your staff would usually carry out these tasks, the fourth being to go and get a laptop from Susan in procurement. Obviously, you cannot automate this, so you will need to work around this. Undeterred, you decide to go and see Susan, get a laptop and ask a member of staff to look at automating the first three steps.
A Moment of Confusion
What started off as very straightforward now has to take into account processes and requirements from another department in the business
Speaking to Susan you soon find that there are more hoops to jump through than you first thought. Susan is surprised you aren’t aware, but then again, one of your staff normally carries out this task. Susan explains what really has to happen.
‘You cannot get a laptop released for a new starter until they are in the HR System. Once in there, their soon to be line manager needs to raise an order for the laptop. This in turn has to be approved by his boss. Once all that is done, you can have a laptop.’
Feeling confused you go back to your desk and sketch out what the process looks like now. It isn’t too bad you think. There are some approval processes in there. They can be placed into the automation flow with the product set that you decided on, but it will take more work. OK. No problem.
The Final Straw
A few weeks later you have your pilot up and running. You have tested it plenty of times and it all works fine. It is going to save a lot of time and simplify the new starter process. Success! You can’t help feel a bit smug about it. Automation is simple and effective. You can see a lot more of it in your near future. Think of all the processes that can be automated! Think of all the frustration you are going to eradicate! As with all things, you have to present your results and demo your pilot workflow to your manager and the other heads of departments. When the time comes you feel confident that everything will work out just fine.
“The line manager doesn’t need to get approval from his manager for the laptop” says Mike. Susan disagrees and reiterates her point. “Also, contractors don’t get VPN access, only full time staff” says Mike. At this point Steve chips in. “Well, some contractors do!” Confusion sets in. “That isn’t the case though. They aren’t allowed VPN access” retorts Mike. “Well, when needs must” replies Steve shrugging.
Your well thought out process for the pilot now looks like something out of a horror show. No one can agree what the process is. After all your effort, the automation is irrelevant! You haven’t even got so far to demo it to people! What has happened?
The Bitter Truth
What you just witnessed there was the bitter truth of automation! ‘What!?!’ you shout. ‘But it’s automation! Automation solves everything (makes me laugh as much as when people say ‘we do DevOPs’).’ Despite the buzz by all the vendors (and yes, I’m neutral when it comes to vendor solutions; pro’s & con’s to all) automation doesn’t solve a lack of understanding around the business. Do you recall that ancient IT proverb?
That’s right. It is still true! All the advances in technology don’t make up for bad or misunderstood business processes. If you automate rubbish you will get.. well, automated rubbish. It doesn’t matter what the vendor says about their product set. It doesn’t matter what the price tag of the product set is. It certainly doesn’t matter who the vendor is (some of the best automation tools are open source!). If you want to reap the benefits of automation in your business, you need to step back from the technology. You need to make sure your business can walk before you try and make it run.
I have experience of providing automation solutions to various organisations ranging from small to large enterprises. One of the initial and common questions I hear is ‘how much will it cost to automate ‘x’?’ I will admit that I have had some funny reactions when I reply ‘are you sure you know what ‘x’ is and what the business process for x is?’ From experience, initial conversations around automation start with a room full of technical people; IT operations, administrators, architects. Don’t get me wrong, I like talking shop as much as the next IT nerd, but this is the wrong place to start. Where do I start I hear you cry? Well let me tell you.
Learning to Crawl
Get the process owner(s) into a room. Make sure they bring a few people along who work in the same team. More often than not, it is easy for the process owner to lose sight of or knowledge on how the process currently works. Afterall, ‘owners’ don’t usually do. Make sure you have plenty of whiteboards, paper, post it notes, pens, pencils and coffee. Get the current process written out. People will disagree with how the process works. Paper will get screwed up, whiteboards will get cleaned, but eventually you will have the process written up and it will be the truth. It won’t take long I hear you say. I can assure you, I have sat in rooms for hours and days with people, before they agree on the how the existing process works. Finally, take a photo of it. You’ll be thankful that you did later on.
Your First Steps
You have the process written out now. Everyone has agreed how it works. Lets get automating then! Halt! Stop! Don’t you dare! Just because you have an agreed process doesn’t mean it is fit for purpose. Businesses inherently concern themselves with important matters like revenue, cash flow and what you are told is important from the people upstairs. There is nothing wrong with this. But, if you are going to be automating this process then isn’t this the perfect time to poke it with a stick and ask the question ‘is this still fit for purpose?’ Remember GIGO. Put a consultative hat on and challenge the the process. Don’t be afraid to ask questions. It is common to not see the big picture when you’re living inside of it. Sometimes it takes an outsiders view to open eyes and make people realise there could be a better way.
Some of the questions that I like to ask are
- Is the process as efficient as it can be?
- Does the current process meet business needs?
- Are there any in-play strategic changes that could affect the viability of this process?
- How often is this process used?
- Is it worth automating this process?
- Do you still need this process?
Once everyone is happy that the process is good, it is time to move on.
It is time to map the process to the technology! Now is the time to get the room packed with your fellow IT comrades. Now is the time to overlay the business process with the technology. HR System? Runs on SAP. Brilliant. Can we automate what we need to in SAP? What do we need to do that? What data do we need to push into SAP and what will we need to get back? What is next? User account in Active Directory. Already have scripts to create a user? Brilliant, we can use those. Treat this as a technical discovery phase. You need to know what system does what, what talks to what, how they talk to each other and more importantly what APIs do they have. Once the business process has been successfully overlaid against the technology stack you can start to produce a high level diagram of how the workflow will execute. List the inputs that are required, any manual intervention steps to the flow (such as manager approval for a request). Whether the workflow fails or succeeds, who needs to know? Is there a CMDB that needs updating? This is the time to collate all the information required to build the workflow. What do you do with all that information I hear you ask? With all that knowledge you now how, it is time to put pen to paper (or fingers to keyboard) and start writing a design document. At this stage, I would recommend documenting the following items
- Workflow Description – what is this workflow used for?
- Prerequisites and Assumptions – what has to be in place for this workflow to successfully start? Are there any assumptions?
- Success Criteria – what has to happen for execution of this workflow to be marked as completed successfully?
- Inputs – what information needs to be pushed into this workflow
- Outputs – what information will this workflow provide when it succeeds or fails
- Execution Diagram – high level visio diagram of the workflow steps
- Execution Step Details – map inputs and outputs for each workflow step. Document what systems the step will interact with
- Error Handling – document what has to happen if the workflow fails
Go For A Run
It’s time to get your hands dirty! After all this talk you can finally get down to creating the workflow. You sit down in front of the computer screen, load the vendors product up and start implementing those inputs, outputs and decisions that are going to automate that business process. Be prepared for some long hours, hard work, disappointment and plenty of head scratching. It really isn’t as easy as people think. Just as you think you have cracked it, the workflow devil stabs you in the back and you realise that
- That vendor API really doesn’t work as they said it would
- Something doesn’t make sense in process logic. Despite all those conversations something got missed (yes, this really does happen)
- ‘While you are doing that, could we try this?‘ last minute requests from the process owner
- A hundred other face palm inducing moments
At some point you are going to have a workflow that executes end to end. Success! Now is the time to sit down with people who normally have to carry out the business process and let them test the workflow. Yes, that’s right, UAT (user acceptance testing). Don’t skip it. This is your chance to make sure the workflow does exactly what the users need it to do. Expect some remediation activity at this point. Chances are something has been missed or a chance to increase efficiency is realised. Just be sure to retest any changes and perform UAT again. There is nothing worse than getting a workflow in to production only to find that it doesn’t work! Once UAT is passed and everyone is happy, get that workflow into production.
Kick Back and Put Your Feet Up
The workflow is done, the process owner is happy, his staff are happy and you aren’t getting daily requests for ‘that process.‘ In turn your staff are happy and even have some spare time. You can all take your foot off the gas, ease up a little and kick back. At least for an hour or two. Once the rest of the business see the benefit of automating processes, expect demands from all angles. Automating the leavers process? Check. Automating server deployments? Check. Patch Wednesday? Automate it! There are so many business processes that can be automated. With the rapid improvement cycle in technology, businesses have come to rely ever more on technology. This increases the chance that at least part of many business processes can be automated, reducing risk, raising efficiency and reducing costs. In addition, automation is a key component in building your very own self service portal. Let your users request what they need through a private web portal. Behind the portal, automated processes can deliver against the request (or at least help deliver against the request). Is it dawning on you yet? Ah, there it is. That’s right, you are going to be building lots of workflows. The question is, can you write a workflow to automate what you need to do?
- Always approach workflow development from a ‘business process‘ first point of view
- If the business process is misunderstood or not fit for purpose, neither will be the workflow
- Don’t rush. Plan, discuss, review, repeat
- Break the business process down into small, bite sized pieces. It will help identify common pain points
- Create a high level design document outlining the requirements of the workflow
- A diagram speaks a thousand words so draw more than you type
- Always ask the questions ‘is this process fit for purpose?‘ and ‘do we really need to automate this?‘