The True Cost of Workload Automation

Thank you for joining me everyone, this is Pat Cameron from Help Systems and today's topic for our webinar is the true cost of workload automation. I'm a director of automation technology here at Help Systems, and I've been here for almost 17 years, I can't believe it. And so I've worked with a lot of customers, a lot of automation tools, a lot of operations people that are thinking about automating, helping them to automate, and so what we're going to talk about today is the cost savings that you can realize with automation.

This is the agenda for today. So we'll talk a little bit about why to automate in the first place, and what are good reasons to automate. How that can help you manage your resources and help with scalability. We'll talk a little about staffing issues and how staff are affected by automation and how they're affected by not automating your systems. To me I think that's even a bigger problem. There are a number of vendor pricing models out there and how people charge for automation tools, so what I want to do is give you some idea when you start looking at an enterprise scheduler or automation tools what are the different types of models that you should be looking for and what you should be aware of so that you're sure you're comparing apples to apples when you're comparing different vendors.

I've got a tool that I'll send you at the end of the—actually I think marketing will send out at the end of today's presentation—a spreadsheet you can use to help you calculate your return on investment for any enterprise scheduling and automation tool that you purchase. And then some of the things to look at when you're evaluating different costs that might be involved with purchasing an automation tool. Actually different costs that can be involved in any software that you purchase, so we'll take a look at some of those. So hopefully, you'll get some good ideas on how to evaluate different software workload automation tools and some of the things that you should look for.

Before we start I've got a quick question that I'd like to pose and if you could answer that, bear with me a second. I'm going to open that poll, so I’m just interested in what you're doing now for workload automation. Enterprise scheduling. Are you using some type of an enterprise scheduler across all of your different applications? A lot of times we meet customers that are using application based schedulers. They buy an application such as SAP and some other ERP package and it comes with a scheduler, so they use that. Do you have an enterprise scheduler that's based across multiple platforms? The other thing we see are customers that have their Windows on one scheduler, if they've got a midrange IBM i or a mainframe or other Unix systems that they're dealing with multiple schedulers across all of those different applications and across all of those different platforms and what they want to look at is how can we consolidate, and I think that's what we're going to see today is that's where you're going to see your cost savings is through that consolidation.

All right, I'm going to go ahead and close that up. And so it looks to me like we have nobody here that's got a single enterprise scheduler. Interesting, but then we do have multiple application-based and multiple platform-based schedulers. So let's take a look at why you would want to consolidate and some things to look at if you do want to consolidate those schedulers. So the first question is why do I want to automate in the first place? And to me, one of the biggest reasons is because it's expensive not to. Often you're running in crisis mode, you've got staff that are managing crises, they're doing a lot of putting out of fires and you know that's kind of fun. I was an operations manager in a previous life and it is kind of fun when you get in that situation where you've got a problem, you need to find the answer and you're doing your kind of detective work to solve that, but it needs to end. People can't work in that mode all of the time. And when you don't have control of your operations area that's kind of what happens. You don't know what's causing the problem, you've got too many places to look. So take a look at how much time you or your staff are spending putting out fires.

Do you have a lot of smart people in your area that are doing mundane tasks? Submitting jobs when they need to submit hopefully on time, and hopefully in the right order? Are they going through checklists and runbooks and checking things off? Instead of being innovative and more productive in how to make things run more smoothly, they get too caught up in the day-to-day and those mundane tasks if things are not automated. Is it easy for you to see the server workload? Can you see across all your servers? You know what's running, what's taking up your resources? What is going to run later today? What's going to run tomorrow or at month end or on the weekend when I need to schedule some downtime? Instead of spending a lot of time gathering that information you should be able to see that pretty easily with an enterprise scheduler. Do you have system administrators who are logging on in the evening to check on jobs to make sure they're running? Logging in on month end to make sure that month end is running correctly? Month end always seems to be the biggest pain point with anybody I've talked within the operations area.

Another big reason to automate is if you've got service level agreements with your customers, your clients. Sometimes they're formal, sometimes not. When I was the operations manager we didn't have any formal SLAs but it was at a hospital and that pharmacy and that ER wanted to make sure that those patient information systems were up and running all the time. They wanted minimal downtime and because they're running 24/7, IT needed to be running 24/7. So we didn't have a formal SLA, but absolutely we had service level agreements in air quotes with our customers, our other business area. Do you have a way to know who is running what and when? That might affect available resources that you have and if you don't have control over who is running a big long query, who's running a report that's going to take up a bunch of my resources then that can be inefficient use of the computer resources that you have. And in that same vein are jobs running at the best time of the day or night? Instead of running those kind of transaction heavy queries during the day maybe they'd be better off running at night, and the results would be available for the users that need those results first thing in the morning. One thing about automation is it can make your customers a lot happier.

Do you have downtime associated with any of your servers? When's the most recent downtime that you had to deal with that maybe was caused by human error: somebody running tasks in the wrong order, running them at the wrong time, running them with the wrong date, so you had to do some type of a restore and rerun some of those. Downtime doesn't necessarily have to be a system down, which I think that's the least likely that it will be in the real world. Most of the time downtime is caused by somebody entering the wrong data, again somebody running something in the wrong order, so if I've got an application that's down to my users that's considered downtime. Sometimes if a workstation is down, that's considered downtime. Accounting didn't get their reports in the morning, to them that's considered downtime. So again downtime doesn't necessarily have to be a system that's down. Can you plan for maintenance? There is necessary downtime in the real world periodically and can you plan for that? Can you forecast what's going to run when so that you can see what's going to be affected by this downtime of a server or VM that I have and how can I manage that with the least effect on my clients or my customers?

And another one for automation has to do with dependencies. Every data center I've been in in the last ten years has got multiple servers, multiple VMs, multiple applications and they're all kind of linked together at various points. A lot of times people will create some kind of trigger files, some dummy jobs that need to run, put some gaps in the schedule hoping that that previous step is completed successfully before that next one runs and that's how they handle those dependencies. But that can absolutely cause you problems. So these are kind of the four big reasons why you would want to automate. And what does that automation do then?

To me the main thing that it does is it gives you control, it will give you control of the processes that are running on your systems, and allow you to be able to document those processes, documentation is always a pain—I have to admit I wasn't very good at it—but if it's included as part of the scheduling package that you purchase then it will get done automatically as well, and you won't have to spend a lot of time documenting. You gain confidence that those jobs and tasks are going to run at the right time in the right order with the right variables. If there's a problem, you'll be notified. People will gain confidence in the fact that everything is going to run correctly, everything at month end is going to run, all those steps are going to run in the right order at the right time. But if there's a problem you'll be notified of it. Here at HelpSystems, for as long as I've been here we've talked about the ability to manage your systems by their exceptions. I shouldn't have to sit and watch jobs run; I shouldn't have to log in at night to see how things are going. Trust that if there's a problem or some type of delay you'll get notified, or whoever is on-call, whoever is responsible for that process will be notified so that the error can be taken care of.

Workload automation also gives you the big picture. It also will let you see your systems across all of your different servers and all of your different applications, so it kind of goes back to control, that you've got control over the whole system instead of different pieces. And then automation also will bring you cost reductions. You'll reduce firefighting and that equals reduced costs, they'll be no more missed SLAs, that will be reduced costs, maybe for you, some people have their bonuses attached to SLAs. They'll be reduced downtime, and that will be reduced cost too. Calculate the value of downtime in the people that are affected, the tasks that are running, and you'll see that it's a lot bigger than that system being down for half an hour or two hours or five hours. Then automatic dependencies will also bring you reduced costs because you won't have delays, you'll see that your tasks will run quicker, they'll be kind of compressed together because they can just trigger one after another instead of having to build in those delays and those types of triggers waiting for other tasks to complete.

Unfortunately, when I worked at the hospital, often our computer room would look like this. And what this causes at the hardware level is kind of the same thing at the software level. With a system that's not automated it's difficult to insert new tasks into a job stream if you can't see what's going to be affected downstream by adding that new job. You'll have lag time between events. It's unpredictable and inconsistent, and then you end up with a lot of manual checklists and runbooks and cheat sheets, and that's going to require more staff. It's all kind of a big circle. It has a negative impact on development because of the way they have to develop as far as not knowing what's happening with any dependencies, what's happening with the upstream and the downstream tasks, and so it's going to take those expensive developers longer to make changes in your applications.

So with automation, your software job streams will look more like this. Automation scales. It's a much better use of your resources, you don't have those lag times, you don't have those gaps, it's easier to provide audit data. Auditors need to know what was changed, what ran, what were the exceptions, etc. If your automation tool is tracking all of that information, you don't have to log into ten different servers and pull that out of different files. It makes your production schedules predictable and consistent. They're always going to run the same way every day. Even on month end. You can create tasks that are more event driven, instead of time driven and you don't have those dead spots anymore, so it's a much better use of your resources with automation because of the scalability and the predictability as well.

Enterprise workloads without automation can sometimes look like this. I did love this picture when I found it. If you're running all different types of applications, I'm going to bring up another poll. So I've got a list of kinds of common applications that are here. And if you could just check the ones that you're using, if you're using any of those. Lots of file movement going on out in the IT world today. I know many of our customers use our schedulers for that file movement: pulling files, pushing them, moving them around, creating that data warehouse so that you give quick access to your users and different business units. SAP, other ERP packages, Informatica, other ETL packages, lots of them out there and typically they'll kind of feed one another. You need a way to be able to pull information from one of those systems, push it into the other so that they all kind of balance and you all have access to that data so that it's quick and easy for your business units, for your accounting people to be able to get to that data.

With all the talk of big data, these days that seems to be one of the big things that is what's caused by all the extra data that's out there is that ability to be able to get to it. Yeah, we've got lots of data there, but we've got to be able to make sense of it, and some of those tasks that are used for that are moving those files, storing documents that you have, all your point of sale information. We work with lots of retailers that are polling their stores constantly for sales updates and inventory updates, now that I've got that information I've got to get that into a data warehouse so that it makes sense for the users that want to be able to track that information and make sure that inventory is up where it needs to be, and sales are where they need to be. So timing is critical for all those types of functions that go on, and they do indeed depend on one another.

So if you've got an enterprise scheduler, your flow chart should look more like this. With a single enterprise scheduler you can build in that automation, service level agreements are built into that flow, notification and escalation are built in so that you don't have to log in and monitor. You'll be notified if there is some type of a problem so that it can be fixed. A lot of times enterprise schedulers will interface with your ticketing software as well, so you want that type of dependency to so that you can quickly get a ticket started and get rolling on that troubleshooting.

So what are some of the staff concerns? Absolutely staff have concerns when we talk about automation, but gosh, in all the IT departments that I've been in nobody seems to be overstaffed these days. Everybody seems to be running on short, so if you can eliminate all of those day-to-day kind of mundane tasks, then you can open up your team so that they can feel they can do things besides checklists and they can be more innovative. And what happens if they're not is that people get frustrated, they get burnt out, if they're working all kinds of shifts, if they're on call all of the time, if they're spending their life doing firefighting, like I said it's kind of fun one day but it's not so good if you're doing that every day and every day. Your turnover rate is going to be higher; you're constantly retraining, so you want to make the environment where your operations area people are working something that makes their life a little bit better. So without automation again you need to hire more staff, and you're retraining them and then how do you handle vacation and holidays and sick time? People do get sick, computers don't get sick, they will do the same things every day but if you're doing a lot of manual tasks you need to be able to take into account those holidays and sick times, etc.

So if you do have automation in place, then that's going to empower your staff to think about the business, think about the bigger picture rather than just focusing on those day-to-day tasks that they're doing. Makes them more productive, makes them more innovative. One of our customers—this was quite a while ago—when they automated all of their data centers, he took the computer operators that previously were going through checklists and made them operations analysts and what they did is they went out to other departments, to accounting and the business office, etc., and kind of worked with them to see what can we automate in this department as well? So in addition to automating just what's in the IT department, you can also automate day-to-day tasks for all of the other business units as well. And those operators became experts in automation.

With that, there was a stable staffing level. There was education and training. You could do kind of a train-the-trainer and get people up to speed; there's a reduced need for off-shift work. We had a customer that hired an engineer to sit and watch their file movement at night because they had kind of an unreliable FTP service. They installed one of our automation tools and they were able to take that engineer and put him onto day shift where he was much more valuable as far as being a part of the other departments and being able to do something besides sit with a checklist actually. You can minimize the on-call with automation, and there's a lot better satisfaction with your job as well as a better quality of life all around because of the hours that you're working.

So let's talk about some of the pricing models for some of the scheduling tools that are out there. Once you've decided to evaluate your workload automation solutions, keep in mind that there's lots of different pricing models out there. I won't get into specifics for specific vendors but here's some of the things to watch out for. And one of those is: is a vendor focused on automation? Or is it just one small piece of a larger business? There have been a number of hardware companies recently that have acquired automation and scheduling tools, so that's not really the focus of the business. So make sure that with those, if it's part of an acquisition that that product is still going to be enhanced, that product is still going to be supported and enhanced for the future.

Another thing to look out for: does the solution require dedicated or specialized hardware? That can be okay if that's what you want to do and some of those appliance type solutions work out just swell but make sure that you get the cost for the hardware included in any quotes that you get. Other things to look for” are there additional server charges for different platforms, for mainframe, a midrange, etc? Are there different modules for different functions? Some of the applications out there will sell you a scheduling tool that will schedule by time. Well if you have dependencies, then you've got to pay extra for that module, and if you want to do monitoring and notification, it's extra for that module, and if you need four different interfaces for applications, that's extra. So make sure that your initial quote has all of the pieces in it, and there aren't extras that are tacked on later that might certainly blow your budget. So what's included in the price? Software, hardware, multiple modules, etc., make sure you get all of that information.

And then pricing is a little...there's a lot of different models out there. Sometimes a scheduler is bundled with other products. I know some of the ERP packages out there will bundle a scheduler. Make sure that you are clear on the cost of that scheduling piece, because you might want to replace that with something that works across applications instead of specifically with the application that you're purchasing. If it's being bundled, you want to make sure that you can use that with other applications, and you're not paying for functions and features that you don't use. Some of the competition out there has huge schedulers with all kinds of little pieces that get tacked on, so don't be paying for functions that you won't be using. On the other hand, take a look at the tools that you are using; maybe some of them can be replaced and consolidated into fewer products. I know like the customer that I talked about that had an FTP package that they were using, it wasn't really reliable, they replaced that and then, in addition, they replaced the FTP movement with an individual scheduler. So sometimes you can combine some of those utilities if the features are available in the job scheduler that you purchase.

Is the pricing tiered based on the application, or based on the hardware? If it's peer-to-peer, how is it priced? If there's no central scheduler, if it's an agentless type, how is that priced? Are there different charges for different environments: a test environment, QA, production, etc.? How is that priced? Some of the competition out there charges by the job. And the other part of that is that you don't know until the end of the year what you're going to be charged for because you're really not aware of the number of jobs that are running, so that kind of scares people, they get their maintenance bill at the end of the year and it's a lot higher than they thought it was, so make sure that you can budget if it is based on the number of jobs. Be sure of your limitations, and also keep in mind if it is, then you're going to have people that don't want to put a job into a job scheduler if it's going to cause extra charges so you might be back in the same place with multiple schedules because you're scheduling some of those in cron or the Task Scheduler or some other free scheduler that's out there. And that kind of defeats the purpose of that central scheduler. And then some also charge by users, so keep that in mind too. How many people are going to be accessing the schedule and what types of charges are there for that?

Services. A lot of companies make their money on services instead of making their money on software. So make sure that you are very clear about what types of services are required. You should be able to get a trial period that you can use the product to help you determine is it easy to install, can you start out without help, is it intuitive? What type of training will I need? Will you need training for the basics or can you do that on your own and then just get some training for more advanced features? Trialing should also allow you to test out support, how easy are they to contact, how easy is that process to get a hold of them? Are they knowledgeable, the people you get on the phone, are they able to answer your questions or does everything have to be escalated? How responsive is the support? That's what you're going to be living with so make sure that it's A1.

A lot of times with the more complicated functions the companies require services, so make sure again that you find that out up front as well. Installation services, training, different types of training certainly is offered by everyone. Sometimes it's required, sometimes you can do without it. Some companies require consultants for software upgrades. Find out about that and also what's included in my maintenance. Are software upgrades included? Enhancements? Where do enhancement ideas come from? Those are good questions to ask. Do you have different tiers for support? Are upgrades included? Are new versions included? All of that is going to help you figure out your cost for the product over the life of that product.

We have a worksheet that we'll send to you that will help you to figure out your return on investment. So it's just an Excel spreadsheet and you can plug in the cost, the initial upfront cost for the software, what your annual maintenance is, any training, etc. Compare that with the salary for the operators or the help desk or whoever is running those tasks now, what proportion of their time is spent on scheduling, how many of them are there? And then calculate what automation is going to be able to do so that you can bring those costs down. So we'll send that out after today. I think tomorrow or whenever marketing does their follow-up.

So some things to look at, the other thing is I think number one when you're starting to look at a new application especially one that is so all encompassing as an enterprise scheduler, make sure you've got your business requirements up front even before you start looking at products and before you start looking at the functionality. You need to find out what applications do I need to interface with? What hardware do I have? What are my audit requirements et cetera and what is my budget and then go out to get a proposal from other companies. You don't want them pushing you; you want to be able to push that sale. So I do have a link here that I will send out in a chat, there's a Wikipedia page that lists all types of job schedulers that are out there in the market, and it will give you a good place to kind of start if you're looking at an enterprise job scheduler. So I put that, there it is, I put that link out there, you're welcome to copy that, and keep it, and that might help you get started with your research for enterprise job scheduling.

Before we leave, I'll just put in a quick plug for our Skybot Scheduler, which is our workload automation tool. And it handles all of those different areas that I've spoken about, and we're happy to have you match us up against any of the competition that's out there.

Well, that's all I have today to talk about workload automation and the cost savings you can see. If you have any questions, you can send them to me over on the right-hand side in the chat window. Happy to answer them. A couple of people have asked about the recording and the presentation. Yup, we'd be happy to send those to you. If anyone has any other questions, I'll hang out here for a minute. If not, I want you to have a great day and thanks for joining me today. I hope we will see you next time.