A top-down mandate to bring increased automation will require the implementers and the business unit to meet, agree on requirements, and exchange detailed information about the existing process which may or may not be formally codified. This process is frequently done without the involvement of frontline service workers, so the information being exchanged is done by people at least one step removed from the details of the work, and it just gets worse from there, like a meeting-filled, high-stakes variant of the telephone whispers game.
The opposite case is where a business unit develops their own highly computerized solution, but the process, when discovered, is unacceptable to the BigCo. The subject matter expert can seldom contribute technical artifacts into the sanctioned rewrite, so the rewrite becomes an imperfect facsimile, and the subsequent migration will cause issues.
In both cases, much of the conflict comes from the users of the software not being contributors to the software, in a broad sense of that word. And, service unit employees are often already tiered between process administrators and task executors with no obvious path of advancement between them, such that the frontline workers can be automated out of a job entirely. On top of the organizational barriers, this creates a structural disincentive against contributing to a solution.
Is there an assumption (explicit or otherwise) that the human process your are automating includes a capability that the general public would consider "ethical"?
In the worst case scenario, where: 1. that capability is removed by the automation 2. there are negative consequences 3. the whole world discovers the consequences,
will your business survive? Can you "blame the vendor?"
e.g. https://www.reuters.com/article/us-amazon-com-jobs-automatio...
Amazon made a smart move in pulling this project -- the public perception risk of selling, or even deploying a product that could be seen as "bias, automated" was too great.
Woof, trigger warning. Been there.
