Tuesday, December 20, 2011

Teknologens ansvar

Teknologi er agnostisk i forhold til hva den brukes til. Det er vi som bruker og lager den som må ta stilling til hvorvidt bruk/utviklingrn er etisk (og evt juridisk) akseptabel. Hvilket ansvar har vi teknologer for eventuell misbruk av vår teknologi? Hvilke skanser skal vi bygge inn i systemene, og skal vi kunne trekke tilbake rett til å bruk om vi mener den er uetisk?

Informasjonsteknologi gjennomsyrer alle samfunnsprosesser og hverdagen vår. Siden dataene som skapes er lite synlige er det liten fokus på hvilke risiki og utfordringer dette skaper. I og med at samfunnet bygges på digital informasjonsteknologi som har store svakheter burde den stilles krav til den. I forhold til omfanget av problemet med data som kommer på avveie og misbrukes foregår det en underraportering i media. Noe skyldes nok manglende innsikt fra journalistenes side, delvis skyldes et problemets abstrakte natur. Hjernene våre er fortsatt mer oppmerksomme på fysiske farer enn abstrakte. Sannheten er at vi (i vesten) lever i et tryggere samfunn enn noen av forfedrene våre. Allikevel er det mer fokus på "marginale" problemer, men som som gjerne skaper frykt. Her i Norge har vi i desember 2011 vært mer opptatt av at butikkene er tomme for smør enn at EU holder på å gå over ende, det demonstreres verden over mot myndighetene til våre viktigiste handelspartnere. De samme mundighetene er også iferd med å vedta en rekke lover som fratar oss elementære rettigheter som tilkjempet.

Informasjonsteknologi, som annen teknologi, bør inneha visse egenskaper. Sammenlignet med f.eks. en bro så skal den ikke ramle eller på annen måte utgjøre en fare for den som bruker den. Med informasjonsteknologi er problemene helt anderledes, men likheten er at man utsetter brukeren for en risiko.

Jeg mener teknologer i større grad må bidra til styrke personvern, og gi brukeren kontroll over egne data (disposisjonsrett). Jeg synes også utviklere bør diskutere hvilket moralsk og eventuellt juridisk ansvar det innebærer å lage programvare.

Jeg synes også at man må ha et mer bevisst forhold til om man overhodet trenger å lagre data sentralt. Distribuert brukerstyrt lagring  av personlig informasjon foretrekkes.

Et innspill av Poul-Henning Kemp i forhold til risiko forbundet med bruk av software
http://queue.acm.org/detail.cfm?id=2030258

Dette er et klart tilfelle hvor IT-ingeniører kommer i ansvar
http://it.slashdot.org/story/11/12/20/0127215/software-bug-caused-qantas-airbus-a330-to-nose-dive

Ingeniører, og spesiellt våpenprodusenter, blir det stilt særlig ansvar til. IT-bransjen og programmere stilles det generellt lite ansvar til.

Det er spesiellt mange utfordringer rundt bruk av tjenester på internett, hvor både kriminelle og myndigheter "tar seg til rette" i personlige opplysninger. Dersom individet ikke kan disponere egne data og selv vurdere risiko kan det internettet vi har kjent til nå vil eroderes av overvåkingstiltak og murer.

Dette ble mange forskjellige vinkler, men poenget er: når bør og kan programmere ta etisk og/eller juridisk ansvar? Hvilket opplysningsansvar vedr risiko for brukeren har man som programmerer og tjenestetilbyder?

Programkode skiller seg fra annen ingeniørkunst ved at kan endres fortløpende, kopieres og gjenbrukes uavhengig av opphavsmann/kvinne. Svært mange internettjenester er mashups av andre tjenester. Det blir derfor vanskelig å plassere formelt ansvar i mange tilfeller. Mye av koden er skrevet av frivillige (åpen kildekode).

Formelt ansvar i forhold til sluttbruker kan man trolig begrense til den som leverer sluttproduktet og tjenester. Min bekymring dreier seg mer om det store fraværet av debatt rundt og løsninger som ivaretar individets disposisjonsrett, samt åpenhet rundt risiki ved bruk.

Sunday, December 11, 2011

Lærende distribuerte organisasjoner

Når organisasjoner skal yte tjenester krever det ofte bidrag fra flere enheter i et organisasjonsnettverk. Dersom en eller flere enheter svikter kan verdien på tjenestens sluttresultatet bli redusert.

Et organisasjonsnettverk vil aldri være helt stabilt, siden de ulike delene kontinuerlig utsettes for nye krav og muligheter. Nettverket sett i systemperspektiv er stadig i endring og gjør fortløpende prioriteringer av egne ressurser. Hverken arbeidet eller etterspørselen etter nettverkets tjenester kan standardiseres og må kunne håndtere variasjon. Det eneste som er konstant er endring. Det er derimot mulig å benytte erfaringer i endringsprosessene. Da har man muligheter til identifisere hva som bør endres, og hvordan.

For at nettverket skal kunne skape verdi må de ha gode evner og forutsetninger til å samarbeide og til lære av sine feil. Det gir ikke mening å forsøke å styre/kontrollere et slikt system, med krav, pålegg og reglement, til å skape verdi, minimalisere feilrater og yte tjenester av høy kvalitet.

Et typisk trekk ved organisasjonsendringer innen tjenesteytende organisasjoner (spesiellt offentlig) er tettere sammenkobling og funksjonsdeling for å produsere tjenestene. Konsekvensen er at antall forbindelser øker. Se for deg en eller annen etat eller bedrift som består av et nettverk av organisasjoner som må samarbeide for å yte en tjeneste fra start til slutt.
Verdiskapingen skjer i større grad i ytterkanten av nettverket enn mot midten, mens midten har en koordinerende rolle. Det er i flyten det kan skje verdireduserende feil, og særlig overgangene mellom organisasjonsenheter som er fokus for denne posten.

Et eksempel på en slik flyt kan være innen helsevesenet: diagnostisering, behandling, oppfølging, eventuell etterbehandling. Selv denne forenklede utgaven av denne flyten er ganske kompleks. Jo senere ut i flyten en feil oppstår, jeg større kan "verditapet" være både samfunnsøkonomisk og for pasienten. En feil tidlig i flyten kan komplisere og fordyre, og dermed konsumere større ressurser.

For at de ulike enhetene skal kunne samarbeide kreves god informasjonsflyt, så det er essentielt at dette fungerer. Informasjonsflyt skjer gjerne ved integrasjon av IT-systemer, og her er det ofte svake punkter. Forbedring av systemene, og integrasjon mellom disse, blir desverre ofte salderingsposten når ulike budsjettposter skal prioriteres i den enkelte organisasjonsenhet. En vanlig årsak er systemenes usynlige natur gjør det vanskelig se betydningen for verdiskapingen i nettverket. Ignorering av IT som informasjonsbærer og støtte i prosessene skaper ofte store problemer om systemene ikke fungerer og/eller er dårlig tilpassede. Ved funksjonsdeling kan det være at fagmiljøer brytes opp, og nye kommunikasjonsbehov (og overlevinger) oppstår, som også har en tendens til å bli undervurdert som kostnadsdriver og kompliserende. Det er nærmest en naturlov at organisasjon, informasjonsflyt og IT etterhvert kommer i utakt på grunn av manglende innsikt og prioritering.

Organisasjonsenhetene som samarbeider må kunne kommunisere godt seg imellom for å koordinere arbeidet, estimere kapasitetsbehov og lære av feil.

Skal systemet kunne tilpasse seg er det nødvendig å bygge læring inn i systemet. Læring er avhengig av tilbakemelding på hva som fungerer, hvor det skjer feil og ineffektivitet. Skal de som utfører arbeidet kunne lære må de få tilbakemelding på det arbeidet de gjør. For mer informasjon om teorier rundt dette, les "The Learning Organization", men et viktig prinsipp kan godt siteres:

Learning organizations are characterized by total employee involvement in a process of collaboratively conducted, collectively accountable change directed towards shared values or principles.

De som har studert tegningen over litt nøyere vil se at sirkelen i midten (som symboliserer administrasjonen) er tegnet litt større enn de andre. Dette reflekterer ikke faktisk størrelse, men heller typiske trekk ved byråkratiske organisasjoner. Jeg har også tegnet piler som viser informasjonsflyt inn mot administrasjonen (Rapportering), og en pil ut kalt Kommando og kontroll.

Det mangler ikke informasjonsinnsamling og rapportering i slike organisasjonssystemer, men problemet er at det ikke har noen verdi for forbedring av kvalitet, effektivisering og dimensjonering. Administrasjonen vil ikke ha mulighet til å trekke konklusjoner om hvor det oppstår problemer og hvilke endringer som må gjøres. De som trenger informasjon rapporterer oppover (innover). Slik skapes en masse informasjon med svært liten verdi, og som kun gir en illusjon om kontroll på administrativt nivå. Det blir brukt massevis av ressurser til informasjonsinnhenting som tilfører svært liten verdi.

Ofte er måleparameterene det rapporteres på knyttet opp mot politiske mål, tidsfrister og budsjetter. Selv om dette gir mening i noen sammenhenger bidrar slike målinger sjelden til forbedre kvalitet (det er ikke mulig å måle kvaliteten gjennom flyten), dimensjonere riktig og få kontroll på budsjettet. Det hele resulterer i en byråkratisert og tungrodd prosess med liten verdi, og hvor de som trenger tilbakemeldinger blir sulteforet med informasjon. Organisasjonen fordummes og begår de samme feilene unødig, overskrider budsjettene og har dårlig kontroll på kvaliteten. Denne form for kostnadskontroll skaper kostnader og bidrar i liten grad til å oppnå det man ønsker.

Såkalt streng styring og kontroll, som er en yndet frase fra toppbyråkrater og politikere, gir ikke tilbakemeldinger til de som trenger dem. Å stille krav (tidsfrister og budsjettinstramminger) er ikke det samme som tilbakemeldinger, men disse tingene ser ut til blandes. Når tall er aggregert og rapportert til administrasjonen, har de liten informasjonsverdi i forbedrings- og endringsarbeide. I tillegg er det ofte så stor forsinkelse i informasjonsflyten at tallene ikke lengre representerer virkeligheten.

Når arbeidere og ledere er mer involvert innsamling av erfaringsdata og bruken av disse får man en tettere og mer konkret læringssløyfe som vil være verdifull i kvalitets- og endringshåndtering hvor de selv er involvert.

Denne posten lufter noen tanker og teorier om hva som bør gjøres anderledes. Det vil ikke være noen enkel sak få til noe sånt i virkeligheten, men det er heldigvis ansvaret til de som setter igang omorganiseringer og funksjonsdelinger.

Anbefalt lesning:
Can’t get no satisfaction: Why service companies can’t keep their promises