7 ms·

So you're blaming the staff for an impractical UI? You do realize that software should meet the business needs - not the business meeting the software needs?

Peroni 15y ago
No, as I clearly said, I'm blaming the management for not clearly communicating to the staff why the new system will prove to be more efficient in the long run.
- binarymax 15y ago
  But it isn't efficient. Its so inefficient that the staff have been reduced to using a marker on the screen. Its not a failure of management communication or proper training. It's a failure of the product.
  - jonknee 15y ago
    That could be the case or it could also be the case that the head waiter never took the time to learn and has refused to change his ways. Hard to say from just one data point. The same system could be successfully used in thousands of other restaurants.
- rudasn 15y ago
  You have no facts to prove your claim. You don't know whether or not a) the management clearly communicated to the staff; b) the new system is actually more efficient; c) the headwaiter isn't actually the manager that put the system there in the first place; d) this event happened "in the long run", after working with the system as it should after which stakeholders decided that it's actually not efficient, etc etc. You can blame management and bad communication all you want but the fact is that what seems rational and efficient for some people (management) is irrational and inefficient for others (the person actually doing the work).
ht_th 15y ago
But in the end it probably does both. I often find that when developing some system we end up with a less than optimal result due to all kinds of constraints. Sometimes there just isn't enough money to finish the project the way I wanted, or the existing ICT infrastructure isn't under my control and I and my clients have to make ends meet. Then the organisation starts growing around the solution like a leukocyte encapsulating a non-own-body cell and it becomes part of the organisation.
- nazar 15y ago
  Tho offtopic, non-own-body encapsulated by leukocytes never becomes a part of organization(organism)
vacri 15y ago
That's a throwaway slogan that implies that businesses shouldn't ever have to change their processes.
- alextgordon 15y ago
  It's just reality. Software is easier to change than people. People forget things, get into bad habits, have non-perfect understandings, ulterior motives, and all sorts of other flaws. If your software relies on fixing flaws in humans, it's probably going to fail.
  - sneak 15y ago
    Actually, it directly depends on how many people. Good software is expensive, and if your staff is below a certain number, it may be cheaper to just use the stick. I think this is why hospital software systems are so abysmally bad. They have people who are accustomed to complex training, and software that costs a small fortune to deploy.
    - vacri 15y ago
      Part of the reason why hospital software is bad is because of the intense politics involved, complete with fiefdoms and sales reps with shiny toys. A friend of mine used to be in Quality management at the Royal Children's Hospital in Melbourne, here are two (of many) stories The hospital patient management process is somewhat paralysed because every department has its own custom system for managing patients. He was involved in trying to get a hospital-wide system in, but the CEO was more interested in "making her mark" than managing the hospital, which would require forcing the point with the department heads. So quite frequently patients moving between departments would not have their receiving department ready or even aware of their arrival. Generally the issue was that either department heads liked the shiny toys brought by sales rep -foo- (doctors get a lot through sales rep gifts) and didn't want to change because they'd stop getting them; or that the doctor was stonewalling because they didn't want to learn a new system. Classic case of everyone saying "something must be done... by someone else!". The kicker is that no matter how persuasive your argument might be, the doc would have the last word with "children will die if I can't use this software" and the argument would end. The other story is much shorter: at one bigwig's meeting, one of the senior specialists - a 27-year veteran - shot down a new doctor's comments saying that he wasn't familiar with how things work here. The new doctor's reply? "I've been here 17 years..." I've had a microcosm of this experience as well. While installing monitoring gear for one of the departments, the department chief went ballistic because the new computers had power cables that were touching the desk: "It's written into the quote that the power cables will not touch the desk!". Nonsense, of course, but it's how she gets things to her liking - she was the poster girl for post-contract feature changes. I would have called her on it to try and forestall the next few things that were 'in the contract', but my company was spineless and would never have backed me up. I guess the short form is: a large part of the reason why software is terrible in hospitals is because not many people that have a say are actually evaluating the software properly.

Peroni 15y ago

No, as I clearly said, I'm blaming the management for not clearly communicating to the staff why the new system will prove to be more efficient in the long run.

binarymax 15y ago
But it isn't efficient. Its so inefficient that the staff have been reduced to using a marker on the screen. Its not a failure of management communication or proper training. It's a failure of the product.
- jonknee 15y ago
  That could be the case or it could also be the case that the head waiter never took the time to learn and has refused to change his ways. Hard to say from just one data point. The same system could be successfully used in thousands of other restaurants.
rudasn 15y ago
You have no facts to prove your claim. You don't know whether or not a) the management clearly communicated to the staff; b) the new system is actually more efficient; c) the headwaiter isn't actually the manager that put the system there in the first place; d) this event happened "in the long run", after working with the system as it should after which stakeholders decided that it's actually not efficient, etc etc. You can blame management and bad communication all you want but the fact is that what seems rational and efficient for some people (management) is irrational and inefficient for others (the person actually doing the work).

ht_th 15y ago

But in the end it probably does both. I often find that when developing some system we end up with a less than optimal result due to all kinds of constraints. Sometimes there just isn't enough money to finish the project the way I wanted, or the existing ICT infrastructure isn't under my control and I and my clients have to make ends meet. Then the organisation starts growing around the solution like a leukocyte encapsulating a non-own-body cell and it becomes part of the organisation.

nazar 15y ago
Tho offtopic, non-own-body encapsulated by leukocytes never becomes a part of organization(organism)

vacri 15y ago

That's a throwaway slogan that implies that businesses shouldn't ever have to change their processes.

alextgordon 15y ago
It's just reality. Software is easier to change than people. People forget things, get into bad habits, have non-perfect understandings, ulterior motives, and all sorts of other flaws. If your software relies on fixing flaws in humans, it's probably going to fail.
- sneak 15y ago
  Actually, it directly depends on how many people. Good software is expensive, and if your staff is below a certain number, it may be cheaper to just use the stick. I think this is why hospital software systems are so abysmally bad. They have people who are accustomed to complex training, and software that costs a small fortune to deploy.
  - vacri 15y ago
    Part of the reason why hospital software is bad is because of the intense politics involved, complete with fiefdoms and sales reps with shiny toys. A friend of mine used to be in Quality management at the Royal Children's Hospital in Melbourne, here are two (of many) stories The hospital patient management process is somewhat paralysed because every department has its own custom system for managing patients. He was involved in trying to get a hospital-wide system in, but the CEO was more interested in "making her mark" than managing the hospital, which would require forcing the point with the department heads. So quite frequently patients moving between departments would not have their receiving department ready or even aware of their arrival. Generally the issue was that either department heads liked the shiny toys brought by sales rep -foo- (doctors get a lot through sales rep gifts) and didn't want to change because they'd stop getting them; or that the doctor was stonewalling because they didn't want to learn a new system. Classic case of everyone saying "something must be done... by someone else!". The kicker is that no matter how persuasive your argument might be, the doc would have the last word with "children will die if I can't use this software" and the argument would end. The other story is much shorter: at one bigwig's meeting, one of the senior specialists - a 27-year veteran - shot down a new doctor's comments saying that he wasn't familiar with how things work here. The new doctor's reply? "I've been here 17 years..." I've had a microcosm of this experience as well. While installing monitoring gear for one of the departments, the department chief went ballistic because the new computers had power cables that were touching the desk: "It's written into the quote that the power cables will not touch the desk!". Nonsense, of course, but it's how she gets things to her liking - she was the poster girl for post-contract feature changes. I would have called her on it to try and forestall the next few things that were 'in the contract', but my company was spineless and would never have backed me up. I guess the short form is: a large part of the reason why software is terrible in hospitals is because not many people that have a say are actually evaluating the software properly.