[pantulis]

"Native RPA processes are fragile in production"

Because business processes are poorly documented. And if they are more or less documented they are executed by teams that need to override the underlying technology when a "corner case" happens. As someone else has said, shit needs to get done.

You cannot successfully deploy an RPA project without understanding the business process behind it. And that usually means shadowing the people doing the "clerical" work

An interesting perspective comes from the process mining vendors (which is to say Celonis these days), which goes the other way: look at the application logs to extract event data in order to create a model of the business process. And then they move downstream: perform conformance checking (how is the "as-is" model different from the normative BPMN process) and even perform task mining (what are the users doing for each step of the process)

[ethbr0]

Ironically, my experience has been that actually getting an existing business process to some definition of documented is ~25% of the value.

It's terrifying how much critical functionality at an average company exists only in 1-3 brains.

[ChrisMarshallNY]

> It's terrifying how much critical functionality at an average company exists only in 1-3 brains.

It's not actually terrifying. It's the way that businesses have worked for centuries. There's always a "high priest[ess]" in the woodpile, somewhere, that has "The Keys to the Kingdom."

Most businesses have some form of continuity or recovery plan, but many would collapse, without the Key Player, and they do.

The flip side, is that with the Key Player, they can do very well, indeed.

It's just that Silicon Valley has developed a dread of "The Bus Factor," so we do things like deliberately design shoddy project plans, so that inexperienced, disloyal, transient, teams can run them.

I have looked at codebases that were designed to be implemented by a team, when it should have been a simple, 1-person job. It made the code brittle, overcomplicated, underperformant, and buggy as a rotten log.

[ethbr0]

I guess the thing that surprised and terrified me is that in your modern, hyper-efficient business, these people are everywhere. Because there isn't much you can't do with 1-3 people, if you leverage the right (non-RPA) software to enable them.

So consequently, the Key Player turns out to be sprinkled throughout the org.

And, the really scary part, awareness of "who that person is" generally doesn't seem to penetrate >2 management layers up.

[ChrisMarshallNY]

I worked for a 100-year-old Japanese engineering corporation.

They had a seriously robust structure and policy. It worked (check what Japan has been through, in the last 100 years).

But it brings massive overhead and rigidity. Most American companies would not want to work that way.

[rdedev]

Its not just because of poor documentation. I had used one of the RPA tools, Automation Anywhere, to basically open the browser, go to a url and enter a form and scrap some results (this was part of my office training where I was forced to learn this tool). The steps for this process involved invoking the command to open the browser, waiting for some period of time, enter the url in the browser, again wait for some period of time when the results have loaded and then scrap the results into an excel sheet.

The wait time had to be set appropriately. The tool had no way of detecting if the browser is fully opened and responsive. So if the wait time was too small, it would try to enter the url to a non responsive browser and fail. To make matters worse, each computer will take a different amount of time to load the browser fully. So I had to resort to set a large enough wait time and hope it works. In the end it just seemed ironic that an automation tool could end up making the job take longer than manually doing it. I dont know if the current version of Automation Anywhere still has this issue.