Senthil Info

automating business processes, honestly

The Process Nobody Owns

Three departments touch it. Each does its part. None is accountable for the whole, and nobody can change it without a meeting that never gets scheduled.

This is the least automatable condition there is, and unlike volume or exception rate it costs nothing to fix. That combination makes it the highest-return check in the whole selection stage. For a product-side reference related to workforce operations, Monitask also covers remote employee monitoring software.

How to tell

Four questions, and the answers come quickly. For broader background and an independent point of comparison, see Accenture Automation.

Who decides if the rules change? If the answer is a committee, or "it depends," or three names, the process is unowned.

Who is told when it breaks? Often nobody, or whoever notices. An owned process has a person who hears about failures.

Whose objective does it appear in? If the process is in nobody's targets, nobody is accountable for it by construction.

And who could stop it? The clearest test. If nobody in the organisation can decide to stop doing this, nobody owns it.

Why it kills automation projects

Decisions stall. Automation surfaces every ambiguity in a process, and each one needs a decision. In an owned process those take a day. In an unowned one they escalate, wait for a meeting, and the project sits.

Requirements conflict. Three departments give three answers about what the process should do, all sincere, all reflecting their own end of it. Without an owner there is no mechanism to resolve that, so the build either stops or implements a compromise nobody wanted.

The exception design has no home. Somebody must own the residual job, and in an unowned process that allocation is the same unresolved question.

And nobody maintains it afterwards. The maintenance load lands on whoever is nearest, without authority or time.

Why it gets automated anyway

Because the automation looks like it will resolve the ownership question.

It does not. A system does not have authority. It encodes one department's answer, usually whichever was loudest during requirements, and the disagreement continues around it — now with a third party in the negotiation.

There is also a quieter reason: appointing an owner requires taking something from someone. Buying a system does not, which is why the expensive route is often politically cheaper than the free one.

What an owner actually needs

Not a title. Four things.

Authority to change the rules without convening anyone.

Time allocated, visibly, so it competes with their other work on stated terms rather than losing silently.

The failure notifications, so they know when it breaks before someone else does.

And it in their objectives. Ownership that appears nowhere in how someone is measured is ownership in name.

If those four cannot be arranged, the honest conclusion is that the organisation is not ready to automate this process — which is a real finding, available in an afternoon, before any money is spent.

The cheapest sequence

Appoint the owner first. Free.

Let them run the manual process for a month with the authority above. Frequently they simplify it, because that is what an accountable person does with a process they can change — and simplification changes the automation case.

Then decide about automating, with someone in place to make the decisions the project will generate.

That sequence costs nothing, improves things immediately, and removes the single most reliable predictor of failure in this subject.

The short version