Loading…

Automate the boring parts of your job

Turns out the robots are here to make your job more interesting.

Article hero image

Nobody wants to do grunt work. Every job and every business has some amount of boring, mundane stuff to do. It’s the part of the day that we all dread: picking text out of PDFs, moving files from emails to a folder, or painful data normalization and manual report generation. Developers would rather write business logic: the new code that solves problems and advances the product.

That’s where developers can take a tip from DevOps. Automation is a big part of the DevOps ideology. If you do something two or three times, you automate it. Developers should take note of where they can improve not only their own personal efficiencies, but also overall business efficiency.

Robotic process automation (RPA) takes DevOps scripts to the next level. These automation solutions emulate human actions in repeatable ways, except faster and more reliably. As tech experts discover the power of RPA, they are finding great ways to make their jobs less stressful, spend more time doing what they love, and solve harder problems.

We here at UiPath are big fans of RPA (obviously), but you don’t need to take our word for it. We spoke to two of our community MVPs: Priya Darshini, senior technical consultant at Machina Automation, and Eduard Shlepetskyy, the founder of Ective.eu. They’ve been using RPA to make companies more efficient for years.

Read on as we dive into some real-world examples.

Automate your own processes first

Priya and Eduard wouldn’t be where they are now without first applying automation to their own work. While they now work with companies around the globe on improving their efficiency through intelligent automation, digital transformation, and (most importantly) building software robots to do the most boring parts of people’s jobs, they started by automating their own work first. As the saying goes, “Physician, heal thyself.”

Eduard got started with process automation when he was working in an international order processing department. Most of his day was spent copying and pasting data out of Excel and PDF files and into web-based SAP forms. He found this boring and realized most of his job could be done automatically.

He automated about 75% of his work early in his career by copying and pasting code straight from Stack Overflow. Then he asked management if he could automate work for the 20 other people on his team. He achieved a 60% success rate and freed the dev team up to improve their product.

Priya got her start by automating a 155-step software installation where even a simple upgrade would take seven hours and require a huge maintenance window. After clicking the same boxes and typing in the same information on multiple computers, she wrote code that made those massive maintenance windows a thing of the past.

After all this time, they are still find new ways to simplify and improve the work we do, both in our jobs and outside them. For example, Eduard recently supported an organization that finds accommodations for Ukrainian refugees. Their call center was spending a lot of time manually validating that certain accommodations were still available. He quickly set up a voice robot and could call 20,000 people to ask if their accommodation was still available and for how many people.

Automation tools have become quite sophisticated in the past few years, including functionality that most people don’t know about. They both write automations that go well beyond basic point-and-click interactions: they involve orchestration, credential management, and contextual document object recognition and retrieval. RPA has more potential than ever and it’s constantly growing in capability.

Task automation is not process automation

Even though both Eduard and Priya got into automation by scripting some of their everyday work, we want to point to a common misperception: don’t go into automation thinking it’s like a typical development or DevOps task. There’s a big difference between what UiPath does and the common approaches to automation. If I’m good at VBA, I write a lot of macros because that’s what VBA is good for. If I’m good at RPA development, I write end-to-end scripts because that’s what RPA is good for.

When people are experts in one area, they automate something narrow. With RPA, whether you have one tool or 20 different tools written in Java, C#, and Python, you can automate the entire process. Think about automating entire business processes. It's not about only small tasks, but rather a symphony of smaller tasks (and sometimes bigger ones) that amount to something with major business value.

Choosing what, how, and when to employ automation

Determining what can be done by a software robot is not as simple as finding grunt work and writing a script to do it. When teams first start automating, everyone is excited about the possibilities and eager to jump into the deep end. They come up with a process they think is perfect for a pilot project, but sometimes it’s not and it can fail. To be successful in employing automation, you need to identify business processes with high ROI, rather than simply targeting the most annoying processes..

Dev teams have done a great job deciding where to employ automation in their continuous integration/continuous delivery (CI/CD) pipelines. CI/CD automation is high-value, helps multiple people, and supports an entire business process that impacts many teams. It saves time, is less tedious for dev and QA, reduces room for error, and is universally accepted as a best practice for modern software development.

That is not to say, however, that every automation is related to time savings or personal frustration. One of Priya’s cybersecurity clients chose to automate a process purely for compliance purposes. They had technical work with security implications for the entire company (e.g. network changes, account privileges). It’s the kind of work that was done by one or two technical administrators. She used automation to delegate the work entirely to a robot instead of holding humans accountable.

When Eduard works with his clients, he begins with a list of more than 100 common business processes that nearly every company can automate across many departments. One of his most important criteria is staying as lean as possible with little human involvement. Once a process is captured, any step that’s executed can be repeated and executed more efficiently. But you should keep human interactions to a necessary minimum.

Any process selected for automation should have tangible long-term value. A secondary benefit of discovering what processes could benefit from automation is that you can assess whether business processes from years ago are still relevant and continue to provide business value. It’s all too easy to keep doing work because that’s the way it’s always been done, but we recommend asking why you bother doing a process early on. It’s not uncommon for Priya’s clients to admit they don’t know why they’re performing the process or whether the process is even valuable to begin with. Regarding long term business value and developer happiness, deprecation can be just as powerful as automation.

You should treat RPA like a personal assistant. Don’t look at it as identifying the things you should automate. Instead, remember that everyone has a part of their job that they enjoy the least. Automation allows you to spend more time gathering inputs from other people through interpersonal interaction, then feeding that data into a robot so it can do something useful.

Everyone’s automation needs are different

Automation opportunities for developers are usually specific to the work of technical staff: run a build, deploy, test, etc. For non-technical staff, automatable work looks different because each person’s role is different. Someone in accounts receivable may have calculations to do on an everyday basis, while their work goes to someone in fulfillment, who translates that data into a product delivery, whether a physical shipment or a set of privileges in a SaaS product.

When a company looks to automate one or more processes, RPA can help them look at their overall approach with fresh eyes and find new areas automation could solve for. Solution design inevitably becomes a cross-organizational effort with contributions from many departments, including sales, marketing, accounting, finance, and human resources.

Large automation projects with diverse stakeholders require significant effort and communication, so we recommend starting small. It’s good for organizations to begin by automating mundane, repetitive, high-value tasks before getting into end-to-end, comprehensive process automation. It takes considerable skill and awareness to determine which of these tasks and processes will offer the most value—and, as with software development, there’s no shortage of potential pitfalls.

The scope of software robot capabilities can range from serving individuals to fulfilling organizational needs. It’s all about understanding ROI, choosing meaningful processes to automate, and allowing the robots to handle lower-value tasks. This enables humans to have more time, lean on a dependable system, and focus on high-value, cross-cutting initiatives like digital transformation.

Automating organizations into the digital age

RPA brings artificial intelligence and machine learning to large initiatives like digital transformation. In the past, AI and ML were exciting buzzwords that didn’t offer everyday value. However, modern automation platforms now include useful AI/ML capabilities that can identify processes ripe for automation.

Digital transformation originally meant moving paper-based processes to digital systems. Now it is evolving beyond technology to mean transforming manual processes into automatic ones: people, management, and accounting all gain efficiency by automating processes. RPA goes a step further by tracking work and identifying automation opportunities using task mining.

In my experience, people starting their automation journey often don’t know their own processes, which means it’s easy to overlook what could be automated. Task mining observes everyday activities and suggests what processes can be done by a software robot. It’s especially difficult for individuals to see what a robot could do when tasks are completed by multiple people in different departments. Task mining looks beyond these boundaries and gives humans a better view of the business processes that occur every day.

When there’s organizational buy-in for these types of capabilities, multiple stakeholders and departments can chip in and build tools that help many people irrespective of roles. As teams and their automations mature, they start building and maintaining automation-specific backlogs. People can submit ideas or say, “I’m having trouble in this area. Can it be automated?” From there, organizations can start doing feasibility reviews and establishing a culture of cross-functional efficiency.

Developers then have a big opportunity to review the backlog, help the business with feasibility, assess automation architectural needs, use their bug-finding skills in planning and implementation, and continue to push automation further.

Make your job better by only doing the interesting work

Developers and DevOps teams have been automating repetitive work for years, but that push for automation hasn’t spread across most non-technical departments. We think RPA speeds up high-ROI work, creates organizational self-awareness (“why are we doing this and is there value to this work?”), and builds a culture of efficiency.

Automating business processes end to end can bring cross-functional teams together in new, valuable ways. Start with small tasks and work your way outward, learn the needs of other teams, and get people excited enough to put together an automation backlog. Tools like UiPath can empower developers to expand their reach across their companies, bringing value beyond feature implementation or task completion.

The Stack Overflow blog is committed to publishing interesting articles by developers, for developers. From time to time that means working with companies that are also clients of Stack Overflow’s through our advertising, talent, or teams business. When we publish work from clients, we’ll identify it as Partner Content with tags and by including this disclaimer at the bottom.

Add to the discussion

Login with your stackoverflow.com account to take part in the discussion.