What really holds up automation in the enterprise

The technical hurdle is almost never the problem. What kills projects is ownership, the works council agreement, and the question of who maintains the thing in two years.

In almost every company I have worked in, there was an automation that worked and still never went into production.

The reason was almost never technical.

Three things to settle first

Who owns the result. An automation that moves data from system A to system B has two owners and no one responsible. When it breaks, nobody calls, because nobody is in charge. It breaks anyway, it just goes unnoticed. Settle this before the first script.

What the works council says. Anything that records employee activity potentially falls under co-determination. Even if it only counts how many tickets a team closes. That is not a reason to skip it. It is a reason to ask early. An automation that fails against a works council agreement after six weeks of building could have been scoped differently in week one.

Who maintains it in two years. The most common cause of death in the enterprise is not the bug. It is the departure of the one person who knew how it works. If an automation exists only in one head, it is a liability, not a gain.

What follows from this

I do not build anything that is not documented and handed over. Not even when it would be faster. A script without a handover is a prototype pretending to be a product.

In practice that means: there is one page of text that explains what the thing does, where it runs, what happens when it fails, and who to call then. If that page does not exist, the project is not finished.

And the small version of this

The same applies to individuals on a smaller scale. A rule in your mailbox that you can no longer explain in six months is one you will eventually switch off, because you no longer trust it.

Write down what you built. Two sentences are enough.