So you’ve had a dig around in the world of automation and like what you see? You’re not alone – automation is consistently one of the hottest trends in Service Management. But it can be daunting to know where to begin. How do you go about mapping all those things people do into consistent, repeatable processes? What tools do you need? What skillsets?
Maybe those kinds of questions are too much for a lot of people to overcome. At McKinney IT, we see a lot of organisations who could be really benefiting from automation, but just aren’t doing it. Sometimes it just isn’t on their radar. Sometimes they don’t think they have the capabilities. And sometimes they just need someone to champion the cause, to get something (anything) up and going and show it off to the decision-makers. Maybe that could be you! So here are a few of our top tips to getting started with automation.
If you’re just dipping your toes in the waters of automation, you don’t want to try to take on a behemoth process, like new starter onboarding, which can cut across all areas of the business – IT, HR, Finance, Facilities etc. If you pull it off you’ll be a legend, or course. But there’s a reason legends are few and far between. If you try to bite off more than you can chew then you can quickly become overwhelmed, and your very worthwhile and beneficial project never ends up seeing the light of day. We recommend that you start with something small and relatively straightforward that you know you’ll be able to achieve and show off to the people that matter. Start with one simple process and get it going well before you tackle the next few.
Start With What You Know
It’s much easier on you if you can start by automating a process that you know well in a part of the organisation that you know well. If you’re in HR, don’t start by trying to automate the process to make changes to IT firewalls, you’re going to struggle to get acceptance from the IT folks and, to be honest, you’re probably going to botch it up. If you’re in IT, keep away from the payroll process. For now. Over time, as you automate more and more and start to get yourself a proven track record, you may well be able to get buy-in and broaden your automation to include other departments, maybe even the entire enterprise, but if you try to start there on day 1 you’re probably going to find yourself fighting (and losing) a lot of battles. Getting to that level of maturity is a long game. We don’t often see organisations that can make it happen within 3 or 4 years of starting out on their automation journey.
Our advice: choose something that your team does regularly, that involves two or three stakeholders and that (ideally) isn’t being done very efficiently. Maybe there’s that thing where the customer emails you and asks for something, and you have to call their manager to make sure it’s ok (if they’d ever answer the phone), then send it off to IT to do it. And IT never tell you when they’ve done it so you’re left explaining to the customer why they can’t have their thing yet even though IT did it last week. Choose that. Perfect.
If you want some ideas about processes that people often automate, we’ve got a list coming soon for you.
Automate the Process First
At McKinney IT, we tend to think of automation in two respects.
On the one hand you have automation of the business process. These are the steps that need to happen in order to deliver the service. So if the service involves ordering a new piece of software for your laptop, the business process might be:
- The user logs a request
- The user’s manager approves the request
- Procurement purchase the software
- IT install the software
At the moment, those steps might be being co-ordinated via phone, emails, paper (shudder) or sending a ticket from team to team. Automating the business process means getting those steps into a workflow engine of some kind (more on that later) so that they can be automatically assigned to the right people, in the right order, at the right time. The actual activities might still be carried out manually, but now you have an enforced, repeatable, visible process that makes sure things aren’t being forgotten or done too soon or too late.
The second aspect is technical automation. Technical automation is where we replace some of those manually performed tasks from the business process with automatically performed tasks – done via scripts or other tools. So in the process above, you may be able to say that certain common software can be packaged and automatically installed on the user’s laptop without IT needing to get involved, enabling you to replace the manual step 4 with a (technically) automated activity, reducing IT’s effort and enabling you to deliver your service more quickly.
McKinney IT always recommends that you start with getting your business process automation right first, before you start playing with scripts and such. If you start with technical automation without a reliable business process in place you’re heading into wild west territory, with things being done out of order and often without approval. As you get better at automation, it’s possible to do both the business process and technical automation at the same time, but when you’re starting out, get the basic business process sorted first.
Map Your Business Process
This one’s probably a bit obvious by now, but you need to formally map out your business process. That might mean talking to a bunch of different people to find out what they currently do in order to deliver the service you’re planning to automate. There are a few different things that you need to think about:
- What communications are sent, and how, and when. For example, you might need to send an sms to the requestor when they first log their request to let them know their ticket number. You might need to pop up a notification on an approval app to let a manager know they have something to approve. You might need to email Procurement to tell them a request for a new software purchase is in their queue. These are all part of the business process and need to be mapped out.
- Who needs to approve or authorise the request? Are there multiple approvers? Do all approvals go out at the same time, or one after the other? Do all approvers need to approve, or just any one? And so on.
- Who needs to be involved in delivering the service? In what order do activities need to be assigned? What can be done in parallel to speed up the process, and what is dependent on other activities?
- Are there different scenarios you need to cater for (“branches”)? For example, perhaps if the requestor is a senior manager, you bypass the approval step. Or if the equipment ordered is non-standard, it needs go to procurement to purchase it, otherwise it comes out of inventory.
- Are there technical automation steps available? Scripts that can be run or tools that can be used? Where do these fit into the process?
At McKinney IT, our first step when automating a new business process is to map the activities and their rules and dependencies out using a flowchart tool like Visio. We accompany that with a document that explains in more detail what is involved in delivering each of the activities. We then circulate our documents to the various stakeholders and step through the process with them. If possible, we also shadow requests through the process to make sure we haven’t overlooked anything. By the end of that process we should have a pretty high level of confidence that we’ve got the process nailed down.
Build Your Workflow
At last! Time to build! But why is there so little of this article left? Don’t abandon me!
Never fear, we’ve got a whole separate post coming about how to build your first workflow, so keep an eye out for that, and good luck!