4 ms·

Indeed. This is compounded by the process being automated being the 'idealised' one - not taking into account the exceptions and variations. This leads to the

Indeed. This is compounded by the process being automated being the 'idealised' one - not taking into account the exceptions and variations. This leads to the 'computer says no' scenario - where people who used to be empowered to fix something can no longer do so because the software doesn't support the operations. There is also another problem - often during the implementation of the software solution - the administrator type people tend to pile on lots of requirements for recording stuff that was never previously recorded because the metrics might be useful and the new systems creates the opportunity to capture the data. This creates extra busy work at best - classic example is timesheets - most data entry into company timesheets ( unless you are the sort of company that charges by the hour ) - is a work of fiction. Even worse the 'data' gives upper management the feeling that they can make decisions on the data without talking to those middle managers who actually know what's going up. As a result it leads to poor decision making and an increasing breakdown of trust. It's amazing how much money senior management will spend on an IT system, a sink costs into data entry, in order to avoid a 5 minute conversation with somebody.

DrScientist 3y ago
Or to shorten the above - realising any IT system is a hybrid of it's users and the system, and it's critical to understand what people do best and make sure that's incorporated into the hybrid. Too often, the focus is on what computers do best only.
Terretta 3y ago
> This is compounded by the process being automated being the 'idealised' one - not taking into account the exceptions and variations. On the contrary, generally tools such as Workday support a generally ideal workflow, but buyers spend years "integrating" aka devolving that workflow to mimic the manual toil of before the tool, including often unnecessary exceptions and variations. The end result is often strictly worse, as the flow did not improve and now there are even more human (error prone) steps and more technical parts to break.
- DrScientist 3y ago
  I'm not suggesting that you should build a tool that deals with all the exceptions and variations in the tool - that would be madness. I'm suggesting the process overall needs to be able to deal with these exceptions and variations - and it's people who are best at dealing with these fairly ( say in a Workday HR context ). What you often see is the implementation of an idealised process in the tool, with no way to deal with exceptions - which leads to 'computer says no' scenarios. Everybody knows what the right thing to do is - conceptually it's simple - but nobody seems to know how to make it happen.
  - Terretta 3y ago
    FWIW, the tool itself could almost always handle a convenient flow, and exceptions. At least, that's true of Workday, and most other SaaS I've helped enterprises install. People don't want that. They need a new tool because the old one generates nothing but complaints, then they want the new tool to do exactly what they used to do. So it too generates nothing but complaints, after the pain of transition. But what's a SaaS to do, refuse the revenue and share multiple? Right.
    - DrScientist 3y ago
      I have personal experience of Workday - the UI is not great from a user perspective - I suspect a consequence of the generic design that allows configurability. The whole challenge with software ( and why it keeps getting written again and again ) is the challenge of balancing flexibility with usability. There is difference between whether the software can technically do something and whether people can achieve that task using the software day to day. The other problem with systems like Workday ( and this isn't Workdays fault per se ) - is that they are used as a mechanism to 'cut' HR operational costs by simply moving the cost from HR to everyone else via 'self-service'. Actually most people want to simply talk to somebody - explain what they want and have somebody make it happen - 'self service' only really works for frequently done things where the time saving offsets the time taken to try and work out how to do the operation in the tool for the first time ( or the first time in ages ). Same thing in finance systems - when large companies move from a purchasing team to a 'self-service' model - most line of business departments simply recreate their own purchasing teams as people who order stuff infrequently have no idea how to fill the forms in. As I said before - it's about thinking about the people in the system, not the tool. Thinking just about the tool leads to tool implementators blaming lazy users and users blaming tools.

DrScientist 3y ago

Or to shorten the above - realising any IT system is a hybrid of it's users and the system, and it's critical to understand what people do best and make sure that's incorporated into the hybrid. Too often, the focus is on what computers do best only.

Terretta 3y ago

> This is compounded by the process being automated being the 'idealised' one - not taking into account the exceptions and variations. On the contrary, generally tools such as Workday support a generally ideal workflow, but buyers spend years "integrating" aka devolving that workflow to mimic the manual toil of before the tool, including often unnecessary exceptions and variations. The end result is often strictly worse, as the flow did not improve and now there are even more human (error prone) steps and more technical parts to break.

DrScientist 3y ago
I'm not suggesting that you should build a tool that deals with all the exceptions and variations in the tool - that would be madness. I'm suggesting the process overall needs to be able to deal with these exceptions and variations - and it's people who are best at dealing with these fairly ( say in a Workday HR context ). What you often see is the implementation of an idealised process in the tool, with no way to deal with exceptions - which leads to 'computer says no' scenarios. Everybody knows what the right thing to do is - conceptually it's simple - but nobody seems to know how to make it happen.
- Terretta 3y ago
  FWIW, the tool itself could almost always handle a convenient flow, and exceptions. At least, that's true of Workday, and most other SaaS I've helped enterprises install. People don't want that. They need a new tool because the old one generates nothing but complaints, then they want the new tool to do exactly what they used to do. So it too generates nothing but complaints, after the pain of transition. But what's a SaaS to do, refuse the revenue and share multiple? Right.
  - DrScientist 3y ago
    I have personal experience of Workday - the UI is not great from a user perspective - I suspect a consequence of the generic design that allows configurability. The whole challenge with software ( and why it keeps getting written again and again ) is the challenge of balancing flexibility with usability. There is difference between whether the software can technically do something and whether people can achieve that task using the software day to day. The other problem with systems like Workday ( and this isn't Workdays fault per se ) - is that they are used as a mechanism to 'cut' HR operational costs by simply moving the cost from HR to everyone else via 'self-service'. Actually most people want to simply talk to somebody - explain what they want and have somebody make it happen - 'self service' only really works for frequently done things where the time saving offsets the time taken to try and work out how to do the operation in the tool for the first time ( or the first time in ages ). Same thing in finance systems - when large companies move from a purchasing team to a 'self-service' model - most line of business departments simply recreate their own purchasing teams as people who order stuff infrequently have no idea how to fill the forms in. As I said before - it's about thinking about the people in the system, not the tool. Thinking just about the tool leads to tool implementators blaming lazy users and users blaming tools.