03 · NOTES

What Should Actually
Be Automated?

Automation is useful. Automating something simply because it can be automated is a different question.

I've spent a lot of time building integrations and automations. One of the easiest traps to fall into is automating something simply because it can be automated.

The better question is: should it be automated?

Automation has a cost. There's the initial development, of course, but also testing, deployment, monitoring, support and maintenance. Sometimes that cost is absolutely justified. Sometimes a five-minute manual task that happens once a month is better left as a five-minute manual task.

On the other hand, a process that happens every day, touches multiple systems, involves repetitive work and creates opportunities for human error is a pretty good candidate.

Can it be
turned into a function?

Before building an automation, I think it's worth looking at the whole lifecycle.

How often does the task happen? How much time does it actually take? How much does an error cost? What other systems depend on it? And what will it take to keep the automation working six months or two years from now?

A process that takes ten minutes once a month may not justify several days of development and testing. A process that takes an hour every day across several systems probably deserves a much closer look.

Just because it can change automatically
doesn't mean it should.

A useful question is whether the process can be described as consistent inputs, rules and outputs.

If the answer is yes, automation is usually easier to reason about. If the process depends heavily on judgment, exceptions or changing business context, trying to automate all of it can make a complicated process even more complicated.

That doesn't mean you can't automate it. It may mean that only part of the process should be automated.

Automation doesn't have to mean
“don't touch it.”

Sometimes the best automation is the one that removes the repetitive work while leaving the judgment to a person.

For example, an integration could identify a change, validate it against known rules and propose the appropriate action — while leaving exceptions for someone to review.

Or automate 90% of the process and leave the remaining 10% to a person because that's where the business context matters.

That's still automation. In fact, it can be a better design than trying to force the entire process into a completely unattended workflow.

Just because it can change automatically
doesn't mean it should.

Business structure is one of the foundational building blocks in a workforce-management system.

Changes to organizational structure can have downstream effects on things like pay-rule triggers, cost centers, employee assignments, reporting, integrations and payroll exports. Because of that, changes to the structure are often something worth treating carefully.

Imagine an upstream HR system changes an employee's organizational hierarchy and an integration automatically makes the same change in UKG Pro WFM.

Technically, the integration may be doing exactly what it was designed to do. But that doesn't necessarily make it the right business outcome.

Perhaps the existing WFM structure should be reused. Perhaps a pay-rule trigger depends on the current structure. Perhaps payroll expects a particular cost-center configuration. Perhaps the organizational change is temporary. Or perhaps the business simply wants the WFM implementation to reflect something slightly different from the HR hierarchy.

A manual touchpoint can provide an opportunity to recognize those situations before a technically correct change becomes a business problem.

In the end I don't think the goal should be to automate everything. Instead, with these questions in mind:

01

How often?

How frequently does the task actually happen?

02

How much effort?

How much time and human effort are really being spent?

03

How predictable?

Can the process be expressed as consistent rules and outcomes?

04

What depends on it?

What downstream systems, processes or people could be affected?

05

What happens when things change?

Will the automation still make the right decision when the business changes?

06

What's the real payoff?

Does removing the manual step justify the development and ongoing complexity?

The goal should be to automate the things that benefit from being automated.

There's a difference.

← Back to notes