![[Forrige artikkel]](../../gifs/prev.gif)
![[CW hjemmeside]](../../gifs/cw.gif)
![[Neste artikkel]](../../gifs/next.gif)
R gjorde ikke leksene sine godt nok
Ukens kronikk er en outsourcing-historie fra virkeligheten, eksemplet er amerikansk, men kunne like gjerne være fra Norge.
For to år siden bestemte R seg for å utvikle et nytt informasjonssystem for bedre styring av den komplekse driftsdistribusjonen. Målet var å redusere arbeidskraften som var nødvendig for lagring, pakking og utsendelse, og å øke volum og betimelig forsendelser til forretningene som solgte Rs produkter. Systemet måtte støtte høyt automatiske astyring av lageret som radiokontrollerte transportsystem, automatisk veiing og strekkodeskilting tilpasset kundeordrer.
Her følger historien om bedrift "R", en større fabrikant av forbrukervarer, sin dyrekjøpte erfaring med outsourcing. Navnene er fiktive for å beskytte de skyldige.
Bedrift R trengte rask levering. På grunn av andre den interne utviklingsstabens andre høyt prioriterte forpliktelser, valgte de å outsource systemets design og utvikling til det internasjonale firmaet Tarvelige Outsource Unlimited. Tarvelige foreslo et en distribuert, åpen klient\tjener plattform ved bruk av en relasjonsdatabase og en kombinasjon av Cobol, C og fjerdegenerasjonsverktøy (4GL). De ble enig om å levere et nøkkelferdig system innen 14 måneder. Bedriftene signerte en utviklingskontrakt med fast pris. Prosjektet ble katastrofalt.
Tarvelige leverte systemet til den fastsatte prisen, men tre måneder forsinket. Det ville ikke i utgangspunktet ikke vært så ille -- hvis systemet hadde vært i stand til å tåle Rs arbeidsmengde. Det var det imidlertid ikke. Varene ble sendt feil, og R var tvunget til å gå tilbake til manuell drift fordi systemet ikke raskt nok klarte å aktivere transportsystemene. Enda verre var det at systemet manglet kontrollfunksjoner som raskt kunne finne og diagnosere problemer. For å holde ting ved like brukte R to millioner dollar til å leie lokaler, utstyr og ekstra bemanning.
Hvordan kunne dette skje? R gjorde ikke leksene sine godt nok fordi det hastet slik med å få distribusjonssystemet på plass. Det finnes måter å prosjektere utviklingskostnader, defektforekomster og operasjonskostnader. Det er viktig å se på disse i forhold til hverandre og ikke bare som individuelle poster. Fra et utviklingskostnadssynspunkt kan outsourcing virke som et smart valg, men ikke hvis defektforekomster eller operasjonskostnader er ute av kontroll.
Men R kunne ha unngått katastrofe.
R måtte kjenne til kostnadene og lengden av tilsvarende prosjekter for å vite om de fikk en god avtale på utviklingskostnadene. Standardmåten å måle disse faktorene på er å bruke funksjonspunkter. Disse undersøker input, output, filforespørsler og grensesnitt for å forutsi tid og krefter som trengs for å utvikle et bestemt system.
Tarvelige benyttet rundt 2.600 funksjonspunkter til Rs prosjekt. Det er 268.000 "Cobol-tilsvarende" kildedelinger -- 50 prosent fjerdegenerasjonsspråk, 40 prosent Cobol og 10 prosent C. Hvor mye burde det koste, og hvor lang tid burde det ta å levere 2.600 funksjonspunkter? Ifølge Capers Jones data, (Applied Software Measurement, McGraw-Hill, 1991), en amerikansk standardmåte å måle gjennomsnitt for IT-prosjekter, ville Tarvelige trenge 325 personmåneder, og ferdiggjøre prosjektet på 48 kalendermåneder. Tarveliges pris lå på 10.000 dollar per personmåned; ved bruk av disse tallene ville prosjektets kostnader ligge på 3,25 millioner dollar.
Hadde R brukt denne metoden for å få et overslag over utviklingskostnadene, burde prosjektet ha kostet 1.250 dollar per funksjonspunkt. Kontraktens kostnader lå på 1.192 dollar per funksjon, basert på faktiske funksjonspunkter levert. Det er rundt 5 prosent mindre en det amerikanske gjennomsnittet.
Fra et tidsperspektiv virket outsourcingavtalen med Snidely som et godt valg. Systemet ble installert på kun 17 måneder. Selv om det var tre måneder forsinket, så er det mye raskere en gjennomsnittet på 48 måneder for denne typen prosjekter. Men når R ble klar over defektforekomstene, og målte den negative virkningen de hadde på støttekostnadene, så begynte den gode avtalen å slå sprekker.
R begynte ikke å kartlegge defekter før tre måneder etter installasjon. De burde ha startet umiddelbart. Gjennom de første åtte månedene med kartlegging av defekter ble det gjennomsnittlig funnet 211 mangler eller feil per måned i Kategori 1. Kategori 1 defekter var de som ble funnet i prosessoren, som for eksempel unormal slutt og ubalanserte tilstander. I den syvende måneden begynte R å spore kategori 2 defekter, som er brukerrapporterte funksjonalitetsproblemer.
Den totale defekttettheten (defekter per 1.000 kodelinjer, eller defekter per funksjonpunkt) i Kategori 1 over en åttemånedersperiode ble rundt én per funksjonspunkt. For sammenligningens skyld kan du forvente å se cirka en mangel per funksjonpunkt for et system på denne størrelsen i systemets 12 første driftsmånedene. (dvs. det totale av kategori 1 og kategori 2 defekter). Denne hyppigheten av driftsforekomster kan virke rimelig i forhold til Jones gjennomsnittet.
Men når du tenker på at Rs Kategori 1 i et nylig 3.000 funksjonspunktprosjekt var mindre enn .007 defekter per funksjonspunkt (dvs. 1\142 av Snidelys førsteårsforekomster), så er ikke det rimelig i det hele tatt. Og Rs lave antall defektforekomster i prosjektet er ikke avvikende; det er typisk for utviklingsprosjekt.
Det er klart at Tarveliges defektforekomster ikke ser bra ut. Verre ble det for R senere i akseptprosessen, Tarvelige mente at R ville trenge to fulltids engasjerte personer per installasjonsområde (fire områder) for å støtte og holde systemet vedlike.
La oss ta Rs gjennomsnittlige 2.000 funksjonspunkter per støtteperson som en sammenligning. Det betyr at R typisk ville trenge 1,3 personer for å støtte 2.600 funksjonspunkter. Men Tarvelige anbefalte åtte personer for samme kodemengde. Det ville koste R 535.000 dollar ekstra i støttekostnader -- basert på 6.7 flere programmerere til en gjennomsnittlig kostnad på 80.000 dollar i året. Avtalen ble seende verre og verre ut.
Det nye systemet viste store prestasjonsproblemer, inkludert treg responstid under moderate mengder og nattlige prosesskrav som systemet ikke kunne tilpasses. Fordi R handlet med et misjonskritisk system, så måtte de rette på prestasjonsproblemene. De trengte rundt seks personår med for å løse prestasjonsproblemet, i tillegg til 480.000 dollar til det første årets driftskostnader.
Mange av disse prestasjonsproblemene grunnet i Tarveliges forsømmelse når det gjaldt å denormalisere databasens design for å forbedre prestasjonen. Det implementerte systemet brukte 4GL for å takle nattlige rapporteringsfunksjoner. Følgelig ble hver rapport prosessert på rad og rekke gjennom hele databasen, som resulterte i driftsineffektivitet. Systemet var et glimrende eksempel på falsk økonomi. Tarvelige sparte utviklingskostnader ved å bruke legion og junior fjerdegenerasjons språkkonsulenter, som resulterte i de angitte driftsineffektivitetene. IT-personellet på R var i stand til å identifisere forbedringer som et resultat av en reduksjon av en satsvis prosess fra to timer til 15 minutter. De var i stand til å øke hastigheten på materiell som styrte utstyrgrensesnittet med en faktor på 500.
R stod også foran store vedlikeholdsproblemer fordi systemets programmer var unødvendig komplekse. En prøve av ti programmer viste for eksempel uakseptabel høy McCabe cyclomatic Complexity resultater. Vanlig aksepterte normer for kvalitetsprogram ligger mellom ti og 15; Snidelys Cobol og C programmer falt mellom 251 og 62. Fordi programmene var så komplekse, ville det være veldig dyrt å endre de for å reflektere nye businessregler.
R må mest sannsynlig skrive om programmene for å unngå kompleksitetsproblemer. Tidlige overslag tyder på at det vil kreve minst ti personår, eller ekstra overskridelser av førsteårets driftskostnader på 800.000 dollar.
Mange av disse prestasjons- og vedlikeholdssakene kom av den ekstremt pressede timeplanen. En realistisk 24-måneders plan ville gjort tingene enklere og billigere.
Ikke bare ble Rs kostnader 40 prosent større enn forventet med tiden det tok å få systemet i drift. Det ville tatt 24 måneder å utvikle systemet selv. Historiens moral? Skal du outsource, så vær sikker på at du:
-- Skriver kontrakt for kvalitet, ikke bare hurtighet og kostnader.
-- Styrer teknologi-risikoen. R burde ha insistert, spesielt for et misjonskritisk system, på en prestasjonskontrakt som inkluderte prototyper og prestasjonsdemoer. Disse koster penger, men ikke i nærheten av de ekstra 2 millioner dollarene som var et resultat av outsourcingkatastrofen.
--Utvikler kostnader og timeplan-scenario før du skriver under på en kontrakt. Hvis R hadde gjort dette ville resultatet vært forutsigbart.
OVERSATT OG BEARBEIDET AV ANN-KRISTIN STRAND
![[Image map not available]](../../gifs/artmap.gif)