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.

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

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

Not when you need to replace an X with four clicks...

You probably know the story with the high-tech tracking systems for planes on carriers - it was so good and easy to use they had to replace it with toy planes on a table - true story...

I'm not talking about this specific incident, I'm talking about the slogan. Pointing at a couple of bad examples doesn't mean that sometimes businesses do have to change their processes to fit software that is better for them. Or perhaps a better way of putting it is: business and software should change together to answer what's best for the business.

Where I currently work has shitty inventory control - salesforce for sales and device tracking, and an Access database for unit consumption.

This is absolutely woeful and has a number of problems to people who know anything about inventory. Want to know where widget #234 is? Well... I hope someone entered it against the sale in Salesforce. Cool, they did. Now, can we make sure that that serial is unique? No. Which batch of components was it made from? No idea. The sale was accepted on this date, but it wasn't installed until two months later... when was that? Is the item still in warranty? We sent device #234 to a demo site, and then it got moved on, and then it came back and then it was sent to another demo site, we can tell that right, because an issue has cropped up where we need to know where it's been? No, there is no history tracking.

Trying to track inventory in salesforce is a fool's errand because they have no concept that an item is unique and can have history - anything resembling a serial number is just a user-enterable text field, no protection against duplicates, no protection against assigning it against sale 2 because it's already on sale 1.

These are the current business practises where I work, and we've shaped our processes around them. But we're about to start being more hard-lined about warranty terms (until know we've been giving free terms as we've been largely on the VC teat)...

The business needs software that is going to be harder and more complex to use than "yeah, fill in this free text field with whatever you feel like, if you feel like it. So yes, sometimes software needs may look to the casual observer like "this is so arcane and complex", but that doesn't mean that they're automatically bad - the slogan above is trite and the real problem is that it implies business shouldn't ever need to change their processes to suit software. I mean, there is a point to the slogan, but it should be rephrased to something more suitable.

We have similar experiences with software. I think the problem comes from "I'm smart - you're dumb". The software should help me not the other way around.

Consider my brand new Samsung TV set: I could not believe that program numbers are not unique! You can have two stations registered with the same program number!!! Do I have to adapt my business because TVs are suddenly smarter than me?

If I'm too arrogant to realize that a domain problem has a very simple solution then I will reinvent the wheel and make it square.

(Indeed, slogans loose their power through overuse - that does not make them untrue though)

> Consider my brand new Samsung TV set: I could not believe that program numbers are not unique! You can have two stations registered with the same program number!!!

As someone who has spent his career in DVRs and smart TV stuff, I have no idea what you're talking about. What is a "program number" in this context? Are you confusing "program" with "channel"?

I call a "channel" the frequency of a station; "program number" is what the TV gives me on the remote control to go to a station - the number on the screen.

In that framework, the TV has two frequencies (or channels) associated to the same "program number". I can switch between the two by entering from the remote the same "program number" twice or more times...

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.

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.

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.

> 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

There's a special case for England's "connecting for health" $18billion nightmare.

I'd say changing the business process is essential to software meeting the business needs. Why else did you write it?

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.

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.

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.

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).