En intressant fråga att fundera på när man ska konstruera ett system är vem som vill vad med systemet. Vem är det som har beställt systemet? Vad vill man att systemet ska göra? Hur kommer man att använda systemet? Vilka kommer att använda systemet? etc.

Säg att ledningen för ett företag bestämmer sig för att köpa ett system för produktion och försäljning av "Wrapplar". Anledningen är att man vill förbättra produktionen + att "alla andra använder ju IT så vi måste göra det också". För att få själva systemet gjort så vänder de sig till dig.

Vilka frågor är då lämplig att ställa sig? Jo, t.ex. vad ska systemet göra och hur ska det användas. Du skriver snabbt ner frågorna och ringer Kalle Karlsson som snabbt beskriver av detta. Du sätter dig ner, konstruerar systemet, kallar på Kalle Karlsson för att visa det, några timmar senare lämnar Kalle dig mycket nöjd med en CD-skiva med programmet och lämnar efter sig en trevlig check som gör att du kan få ost på frukostmackan i fortsättningen.

Allt är alltså frid och fröjd ... i alla fall tills några månader senare då Kalle ringer igen och är fruktanvärt upprörd. Han berättar att produktionen har minskat och alla anställda som kommer i närheten av ditt system är fruktansvärt upprörda och vägrar använda det. Du påpekar att Kalle själv har godkänt systemet och det gör precis vad som står i specifikationen. Efter en så kallad "uppriktig" diskussion så slänger Kalle på luren och lovar att han ska tala om för alla sina kollegor att du inte klarar av att göra nåt vettigt.

Vad var det som gick fel? Flera saker skulle kunna göras mycket bättre, men låt oss börja med att fundera över detta med själva beställningen av systemet. Företagsledningen beställde systemet för att förbättra produktionen i företaget, + "imponatorfaktorn" (vilket är en mycket dålig anledning), och beslutar sig för att ett IT-system skulle göra saken bättre. Man får då anta att de har gjort en riktig bedömning men du får bara veta att det här ska systemet göra men du får inga detaljer, när du ringer upp Kalle ger han dig en snabb muntlig redovisning ... allt detta tyder på att det är ingen som har tänkt på vad systemet ska göra igentligen. När du frågar efter hur dest ska fungera så är det Kalle som ger en beskrivning av hur det fungerar, men hur vet du att detta är en korrekt beskrivning? Vad vet igentligen Kalle om hur produktionen/försäljningen fungerar?.

Ett problem är alltså att den som beställer ett system kanske inte vet vad systemet ska göra eller hur olika arbetsuppgifter utförs. Du kanske för höra argumentet av en mellancheferna att "jag jobbade med det där i 15 år så jag vet precis hur det går till" ... det intressanta är då när dessa 15 år inträffade, var det i början av 60-talet ... i så fall är hans/hennes kunskaper antagligen ointressanta för dig och hur vet du att han/hon var en typsisk arbetare. Vad du vill veta är hur arbetet fungerar nu och hur de som arbetar med produktionen nu upplever situationen.

Du måste alltså ta reda på hur detta fungerar ... frågan är bara hur. Några olika sätt är:

• Intervjuer
• Observationer
• Expertkunskap
• Formulär

Med hjälp av dessa metoder så kan du få reda på vad systemet verkligen ska göra (mer detaljer om dessa metoder ges här).

Ett annat misstag var att inte göra några prototyper av systemet och låta verkliga användare testa detta samt att göra någon form av utvärdering av det färdiga systemet för att se att det verkligen uppfyller de krav som ställts.