Metoden ETHICS Søren Riis Jensen & Morten Skyt Eriksen Samarbejdsorienteret udvikling generelt Problemer ved typiske ikke samarbejdsorienterede udviklingsmetoder, er at de fejler pga. menneskeproblemer, og ikke fordi de rent teknisk ikke kan løse den ønskede opgave. Nye IT-systemer kan få brugere til at føle at deres job bliver mere krævende, at de sidder mindre sikkert i sin position og at fjerne deres selvstændighed. Aggressioner kan føre til at brugerne prøver at "slå" systemet, f.eks. ved at "miste" dokumenter og anden sabotage og så skyder skylden på systemet. Typiske konfliktområder, set fra negativ brugers synsvinkel: IT-afdelingen virker for magtfuld igennem deres dybe kendskab til virksomhedens IT-systemer. IT-afdelingen virker til at have for høj anseelse i virksomheden blandt ledelsen. Lønnen blandt IT-folkene anses for at være for høj, i forhold til hvor mange fejl der sker med de computere som IT-folkene burde have styr på. Essentielt er problemet her en kulturkløft, samt dårlig kommunikation medarbejderne og IT-folkene imellem der er problemet. For at afhjælpe negativitet, kan følgende overvejes ved systemdesign: Synlighed Dels skal brugerne få demonstreret/se at systemet virker og dels skal systemet informere om hvad der sker undervejs i forståelige detaljer. Simplicitet Struktureret information og nemt at vælge, når der skal tages valg. Konsistens Brugerfladen skal have konsistens i design, layout og teksts udformning. Fleksibilitet Systemet kan håndtere enkelte brugeres krav. Samarbejde med brugeren kan ske i tre planer: Konsultativt samarbejde Laveste niveau af samarbejde. Hoveddelen af design klares af systemdesignere, men alle brugere informeres om ændringer undervejs. Evt. inddeles brugere i grupper for at diskutere nye aspekter og for at foreslå systemdesignerne nye ideer og ændringer. Repræsentativt samarbejde Designgruppen består delvist af brugerrepræsentanter. Brugerne har lige meget at sige når systemet designes. Der håbes på at de repræsenterede brugere rent faktisk også repræsenterer den resterende brugerskare.
Konsensussamarbejde Hele brugerskaren er med i designprocessen og dette samarbejde er klart brugerdrevent. En ulempe her er at det kan være svært at lave hurtige beslutninger, men til gengæld er systemet baseret på alle brugeres krav og forslag. Brugergruppen kan evt. opdeles i de opgaver de selv skal bruge i systemet. Der er dog flere ulemper ved et øget samarbejde mellem systemdesignerne og brugerne. Ofte kan der ske: Polarisering af brugergrupperne Ved anden måde er der risiko for at manipulere processen ved at vælge kun de 'rigtige' brugere Deciderede trusler: "Vi gør dette... eller der vil være ulykkelige konsekvenser" Systemdesigneren kan føle at hans job bliver mere eller mindre overtaget af uerfarne og inkompetente folk. Brugere kan føle sig udenfor i en verden de ikke er uddannet i. ETHICS ETHICS i praksis: Førsteårsprojektet Studiekortsystem Da vi i sin tid udviklede studiekortsystemet, benyttede vi ikke metoden ETHICS, men i følgende artikel vil vi beskrive hvordan en udvikling i praksis kunne have fungeret. Domænet vi har perspektiveret over, kunne være set i en bredere kontekst, f.eks. vurdering af om der overhovedet var belæg for studiekort. 1. Hvorfor lave nyt? Det første møde i designgruppen overvejer det fundamentale spørgsmål og problemer med det nuværende system bringes frem i lyset. I studiekortsystemet var der flere problemstillinger: - Computersystemet i brug var dybt forældet og der var derfor ikke vedligeholdelse fra producenten længere. - Systemet var meget ineffektivt. Der var meget manuelt arbejde involveret i produktionen af hvert enkelt studiekort. - Fysisk ufleksibelt: Systemet var låst fast i en kasse der stod i en kælder og hvortil der skulle brændes CD er og flyttes data via disketter. Dvs. der skulle en masse elever ned i en kælder for at få taget billeder og data skulle transporteres via relativt forældede og langsommelige medier. Der kunne desuden stilles spørgsmålet om der overhovedet var behov for studiekort. Hvornår bruges studiekort, til hvad og er der alternative løsninger, som kunne løse samme opgave? Er der eventuelt allerede overlap med andre systemer?
2. Systemets grænser I dette trin bestemmes hvor grænserne mellem det tænkte system og andre allerede implementerede systemer går. I studiekortsystemet skulle der produceres studiekort og tages billeder til disse. Grænsen gik dog ved at stamdata om de enkelte studerende, allerede eksisterede i skolens administrative system. 3. Beskrivelse af det nuværende system I dette trin skal designgruppen uddannes i hvordan det nuværende system fungerer for at have det rette beslutningsgrundlag. Studiekortsystemet var baseret på Windows 98. Licensen til systemet var ikke flytbar og systemet kunne ikke køre på tidssvarende styresystemer. Organisationen Tietgen Skolen, som ellers kørte rent Windows XP, havde derfor valgt at lade denne ene computer køre Windows 98. Ved et evt. nedbrud af denne computer eller dennes printer, ville studiekortproduktion ikke længere være praktisk muligt. 4. 6. Definition af hovedmål og opgaver Tre spørgsmål stilles: - Hvorfor eksisterer bestemte områder i systemet? - Hvad er deres rolle? - Hvad er deres mål? I studiekortsystemet var svarene på ovenstående spørgsmål: - I systemet eksisterer der tre områder: Import af elevdata, billedetagning og sammenknytning af billede og elevdata, samt produktion (printning) af studiekort. Alle disse områder er essentielle i studiekortproduktionen. 7. Diagnosticering af effektivitetsbehov Svagheder i det eksisterende system identificeres og dokumenteres. I studiekortsystemet var klare svagheder: - Systemet var meget langsomt. Det tog lang tid at tage et billede af en elev og få det tilknyttet, sandsynligvis grundet forældet teknologi. - Der var flere manuelle trin der kunne spares ved moderne teknologi. En netværkstilkoblet computer ville ikke skulle have brændt CD er og flyttet data via disketter. - Det er ineffektiv brug af tiden at hele klasser skal flytte sig til et bestemt sted for at få produceret studiekort, i stedet for at bare en enkelt person flytter sig og systemet med. 8. Diagnosticering af jobtilfredsstillelseskrav Hvilke krav er der til jobtilfredsstillelsen? Dette findes der frem til ved et spørgeskema, baseret på ETHICS framework til at måle jobtilfredsheden for den enkelte medarbejder på følgende punkter: - Intellektuel udfordring. - Psykologisk passende.
- Effektivitetsmæssigt passende. - Strukturerede opgaver. - Etisk passende. 9. Fremtidsanalyse Systemet skal være gearet til at kunne ændres til nye krav i fremtiden, så derfor bygges systemet fleksibelt. Denne fleksibilitet opnås ved at holde sig ajour med virksomheder udenfor organisationen omkring forhold, der potentielt kan påvirke systemet i fremtiden. I studiekortsystemet ville det være fornuftigt at systemet kunne håndtere flere data om eleverne. Det er allerede fremtidssikret mod nye studiekortdesign, idet der er integreret et studiekortdesignermodul. I og med at systemet er objektorienteret, er det muligt for udviklerne at lave ændringer. En mulig fremtidig ændring, forårsaget af eksterne faktorer, er et skift fra CPR-nummer til uniid til identificering af elever; et nummer, der følger eleven hele vejen gennem uddannelsessystemet. 10. Specificere og veje effektivitetskrav, jobkrav, effektivitetsmål og jobmål Dette er nøgletrinet i metoden. Mål defineres på basis af de tre foregående trin. Opnåelse af en aftalt og et afmålt sæt af mål kan være en meget svær opgave og skal involvere samtlige, ikke kun designgruppen. Ofte er der konflikt mellem mål og prioriteter i støttekredsen. Det er ikke sikkert at disse forskelle kan løses. I studiekortsystemet var der kun Jan at debattere med. Han kunne undervejs bekræfte og afkræfte diverse forskellige opfattelser af hvordan et effektivt studiekortsystem skulle designes. Det er vigtigt i metoden at forskellige synspunkter og opfattelse af prioriteter bliver luftet. Man kunne forestille sig mere end en pedel som brugere af systemet. Mens en pedel ville foretrække et portabelt system ville en anden måske foretrække en stationær løsning. Én pedel ønsker at eleverne selv medbringer pasfoto til indscanning, mens en anden pedel ønsker at tage et billede af eleven. Det kan altså være svært at stille alle tilfreds og det er derfor vigtigt, at alle får tilkendegivet deres mening under systemudviklingen. En løsning findes ved samtaler med pedellerne, hvor pedellernes personlige forskelle kortlægges. Den ene pedel kan være indadvendt og foretrække en bunke billeder til indscanning på kontoret, mens den anden er mere imødekommende og gerne vil ud blandt eleverne. 11. Det organisatoriske design af det nye system Designgruppen svarer på spørgsmål, baseret på svaret ved trin 5: - Hvilke operationsaktiviteter der er krævet? - Hvilke problemløsningsaktiviteter skal sættes i gang? - Hvilke koordinationsaktiviteter er krævet? o F.eks. hvordan foregår levering af udtræk fra administrationen til pedellen? - Hvilke udviklingsaktiviteter er krævet? - Hvilke kontrolaktiviteter er krævet? o F.eks. hvordan forhindrer vi misbrug? - Hvilke specielle krav, hvis nogen, er krævet af medarbejderne?
o F.eks. at administrationen laver dataudtræk til pedellen - Er der nogen nøgleroller eller forhold, som skal adresseres i det nye design? 12. Tekniske muligheder Hvilke tekniske muligheder er der for systemet, det værende bl.a. hardware, software og brugerens tilgang til systemet. Hver mulighed evalueres på den samme måde som det organisatoriske design (trin 11). I studiekortsystemet overvejede vi forskellige muligheder for digitalkamera kontra webkamera, bærbar computer kontra stationær og dedikeret kortprinter kontra normal printer med specielt papir. 13. Forberedelserne til at detaljeret arbejdsdesign Det valgte system designes nu i detaljer. Data flow, opgaver, grupper, individuelle ansvar og forhold, defineres. Der er også en evaluering der tjekker at designet stadigvæk lever op til de organisatoriske og tekniske krav. 14. Implementering Designgruppen sætter sig nu til at sikre en succesfuld implementering af designet. Dette inkluderer strategien, uddannelse og træning, koordinationen af delelementer og alt der er nødvendigt for en blid overgang. 15. Evaluering Det implementerede system tjekkes for at sikre at det møder målene, effektivitetskrav og jobtilfredsstillelse, ved at bruge diverse analyseteknikker. Hvis noget ikke lever op til kravene, skal der iværksættes rettelser i gang. Med tiden vil ændringer være nødvendige og designprocessen bliver en cirkulær proces. Karakteristik af ETHICS Filosofi: Paradigme Objectives Indledende analyse Domain Hele virksomheden/koncernen, samt eksterne faktorer Target Udvikling af IT-systemer Model : Verbal
Scope:
Outputs: Beskrivelser og beslutningsgrundlag Practice: Baggrund: Udtænkt af Enid Mumford, britisk datalog. Ifølge Mumfords hjemmeside benyttes metoden af mange britiske firmaer og intensivt af én større amerikans producent. Anvendelse Forholdsvist udbredt i UK Deltagere Alle parter som påvirkes af systemet og systemudviklere Product: Bogen Effective Requirements Analysis and Systems Design: The ETHICS Method, Enid Mumford, 1995 Om karakteristikken Paradigmet er meget holistisk, da der er fokus på helheden. Der er ikke et endegyldigt facit og én korrekt løsning, men derimod er de bløde værdier og alle parters krav, ideer, holdninger og følelser vigtige parametre. Man kan argumentere for at paradigmet er mere mod det naturvidenskabelige, hvis vægtning af den trinvise model der bruges i ETHICS, vægtes højere end vi har valgt i vores gennemgang. Metoden bruges som en indledende analyse. Metoden fokuserer på arbejdstilfredshed og de menneskelige påvirkninger implementeringen af et IT-system kan medføre. Domænet er hele virksomheden og til dels også eksterne faktorer. Dvs. alle medarbejdere og eventuelt også samarbejdspartnere involveres jf. trin 10. Modellen er verbal. Der anvendes ingen skemaer og diagrammer, men derimod samtale, interviews og spørgeskemaer. Disse nedfældes skriftligt af hensyn til dokumentationsværdien.