Opråb til it-branchen: Kun hvert femte projekt kan betale sig

Kan ikke være mere enig, men mener nu også denne del om baselines bliver tillagt lidt for ringe betydning..

"Den slags mål kræver selvfølgelig også, at man har målt på den nuværende situation, så man har en baseline"

Laver man "kun" baselines på baggrund af et kommende projekt er man allerede et beslutnings niveau for dybt, og vil reelt få et snævert og forsimplet beslutnings grundlag.

Baselines og den indsigt de kan give (hvis man ellers kan magte at overskue de store mængder af data) og om de services man leverer, bør være grundlaget for en samlet vurdering - som herefter gerne skulle pege i retning af de konkrete projekter hvor der kan hentes yderligere gevinster.

Viden er som bekendt magt, men hvem har den?

Måske er det mere relevant med et opråb til politikerne og andre beslutningstagere om ikke at tro på de løfter om besparelser, som projekterne sælges på grundlag af! IT kan ikke lave mirakler og guld.

Jeg synes det er fint at begynde at se på effekt og hvilken forandring man gerne vil opnå med et nyt system, men det er uhyre kompliceret, alene fordi billedet af hvordan man opnår effekten er uklart. Samme gevinst kan opnås med forskellige tilgange. Hvordan gør man et system til sagsbehandling mere effektivt? - en hel systemrevision, bedre brugergrænseflade, uddannelse af sagsbehandlere i det eksisterende system eller skrotte et system der måske understøtter bureaukratiske kontrolstrukturer, frem for sagsbehandling - kage hver fredag?

Hvordan måler man gevinst når det er muligt at udvikle systemer der kan få folk til at gå ned med stress? Hvor er gevinsten i et system - medarbejdertilfredshed, sygefravær, fleksibilitet i arbejdsgange? Jeg har svært ved at se hvordan man skal måle effekt kvantitativt og isoleret i forhold til et enkelt system - det er sikkert bare mig :)

Jeg håber da at det nye K03 giver mulighed for en bedre veksling mellem kravspecifikationer og det endelige system - gerne i forhold til en løbende evaluering af effekt og gevinst.

»Meget af den udvikling vi laver, handler om mennesker, der har holdninger til de arbejdsmæssige forandringer, de indgår i, og som reagerer på dem. De kan blive nervøse for, om de mister deres arbejde, eller klager over, at organisationen ikke tilgodeser dem. Sådanne følelser betyder, at det er svært i praksis at lave de nødvendige forandringer. Så kan det være nemmere bare at tegne en projektplan og følge den.«

Spot on - men så skal vi vel have fat i en coach før en IT professionel :)

...og så én til trolden: Selvfølgelig kan nye IT-systemer betale sig, hvordan skulle de store leverandører ellers kunne overleve :P - det gælder vel også for konsulentbranchen...

Turing felt that the real test of a computer system was whether it could be distinguished from a human being by a human being.

My experience of writing a very succcessful expert system and having it professionally programmed is somewhat different. The first thing to remember is that not all humans are nerds, so the system has to be designed with a human interface which ordinary users are either used to or find themselves quickly comfortable with.
I had very wide experience with the specialism (Radiation Safety/Control of Radioactive Substances) from being a lowly laboratory technician actually doing the work, right through to being a Radiation Protection Adviser trying to ensure that the law was followed both to the letter and in its intentions. So I have an encyclopaedic knowledge of this area. Computers are an interest of mine and have been since the mid 1960s. So I had both the knowledge of what the system needed to achieve for the various agencies policing our work, for the University itself to be able to satisfy itself what was needed was being done and for the input and output available at the various levels of the University to be both easy and natural to the users and to be readily used by the user and to be realistic about what a computer system could achieve.

It took me around two years to satisfy myself and others that the systematics contained everything necessary for an adequate system to be programmed, about 4 months for the programmer to achieve a working system another 3 years to get all the misunderstandings and glitches out of the system and to input and correct all the preexisting data. I then ran it for a year in one department to get a good feel of how well it worked in practice and to fine tune it. So we are talking of a system which from the first attempt to describe the expert system for programming to the pilot run being completed, had taken approaching 6 years. There was then a training phase which must have taken at least a year to get everyone who needed to use the system on-board and using it (I had had a major breakdown by then, due to overwork and did not see this last phase to completion).
Now I had had in mind from the first that the user must be bribed into using the system. It must take the user far less time than the previous paper system, which it copied very closely. But users now had access to powerful tools to allow them to do more experiments with each batch of radioactive material and to do the most difficult calculations for them. Once logged on, their entire holding of radioactive materials was available to them. The system even prints labels for them with all of the information needed to fully identify an aliquot of material. The result is a system which is enthusiastically used by the users and which handles the very complex web of holding and disposing of these materials thoughout their lifetime and prevents the purchase of them by unauthorised persons, keeps all records correct in the background and even prints out annual returns, legally required by the various authorities, all generated in the correct format ready to be posted on.

Clearly, this was a very specialised area but there are some very clear issues which I can identify as to why the system works and is so well regarded even years later:
* It was designed by someone who thoroughly understood the system and the often apparently opposing requirements for each part of the whole.
* It was designed with consideration of (and discussion with) those who had to use it not just those who thought they knew how it would be used. I discussed and fine tuned the system as a system with people at every level to ensure that everything they felt would make things easier for them was incorporated in the system. This was not just a chat with the senior people involved in the work (I do talk to myself but...) but especially people like the staff who received packages and the store staff who then ensured they went to the correct destination. They helped to get the system tightened as much as possible, so that it became very difficult for radioactive material to be brought on-site with out being ordered through the system or declared.
* The system as a system had been working for some time beforehand (rather badly) as a paper system. There were no surprises - we knew what the system had to encompass.
*The programmer was someone who was used to programming in this area of radioactive materials and radiation. He brought enough knowledge of the area not to make simple mistakes through lack of understanding of words and concepts.

And so on.

I think there are several reasons for failures under different conditions. First the system needs to be designed by someone who both understands what IT can do and what it can't AND what the system needs to achieve to work as envisaged. I strongly suspect that this is seldom achieved.
Next it has to be put together in a way that allows for the opposing requirements to be achieveable. This can require jiggery-pokery with databases etc to achieve but it is astonishing what you can achieve if you always have in mind how the system will (as against should) be used. If necessary run tests to find out...

A complex computer system/program seldom has one single requirement one can test it against. It usually has an over-riding idea (all too often very difficult to test) but usually a plethora of other requirements, from security to usability, from clear easily understood instructions to user-friendly ways of reaching them. Testing in this morass is clearly open to all sorts of abuse and problems.

Recently, my (Danish) wife and I had to use the London Oyster card system for the first time. It was not until the next person in the queue explained how to get our ticket and how to reach the help information we needed that we managed to put some more money on our card and buy the tickets we wanted. That system fails at the most fundamental level!

Never mind the Turing test. Any system which has to communicate with human beings who only think in a human way, has to COMMUNICATE WITH THEM where they are not as the nerds of this world think they ought to be able to manange.

Det er en utroligt vigtig diskussion, Jacob rejser. Som kommentarerne viser, er det heller ikke en enkel sag at forbedre sig på gevinstrealiseringen. Hverken før projektet etableres, mens det kører, eller efter det er afsluttet.

Men det er ikke desto mindre indlysende rigtigt, at der gøres noget på området, hvis hele historien om business-cases skal have noget på sig. Hvorfor være omhyggelig med at opstille detaljerede business-cases for at prioritere projekterne ud fra de rigtige kriterier, hvis ikke der følges op på, om de holder?

DANSK IT har faktisk en konference i marts måned, der er dedikeret bl.a. disse problemstillinger.

"Det koster mange penge at gennemføre it-projekter, og det kan kun begrundes med, at man får nogle gevinster i den anden ende. Men det fejler tit. Alt for ofte bliver der investeret, uden at den planlagte gevinst realiseres. I mange tilfælde er gevinsten ikke engang tydeligt defineret."

Det lyder sgu' da mere som om diverse forretningsenheder der står for projekterne, overhovedet ikke er i stand til at vurdere hverken indhold, tidsplaner eller økonomi for projekterne. Sig "Rejseplanen".

Og hvordan måler man lige det? Hvis systemet er et salgs hjælpe system, hvordan måler du så lige om det har kunnet betale sig? Skal sælgerne sælge mere? Er det nok at der bare er kommet et bedre arbejdsmiljø fordi alle "abe opgaverne" nu bliver lavet af en computer? Skal dokumenterne der bliver genereret overholde en given standard? Gjorde den det før systemet?