1,7 miljardin euron projekti myöhässä vuosia – tilaaja ei huolissaan
Vaikka Antti väitti taannoin, että heinäkuussa ollaan kesätauolla, niin tästä on pakko kirjoittaa.
Tämmönen uutinen osui eilen silmään Tietoviikosta. Uutinen kertoo, että USAn armeijan SAP-projekti on vuosia myöhässä. Projekti on alkanut vuonna 2005, sen piti olla valmis vuonna 2007, jolloin uusi valmistumistavoite asetettiin vuoteen 2010. Tämän hetken arvaus on, että uusi ERP olisi käytössä tämän vuoden joulukuussa.
Muutama mehukas poiminta jutusta:
Uusi SAP-järjestelmä korvaa valmistuessaan yli 140 erillistä vanhaa järjestelmää. Uudella erpillä hallinnoidaan 140 miljardin dollarin vuosibudjettia, ja se palvelee 80 000 käyttäjää. Noin 15 500 ihmistä käyttää jo nyt järjestelmää.
Vau, projekti on neljä vuotta myöhässä alkuperäisestä suunnitelmasta, ja vajaa viidesosa käyttäjistä käyttää järjestelmää!
Vuodesta 2005 käynnissä olleessa projektissa ei ole vieläkään tunnistettu kaikkia vaatimuksia ja kuluja. Myös tarkastajien vuonna 2008 antamasta 16 suosituksesta seitsemän on edelleen toteuttamatta.
Yhtäkkiä tuo arvio käyttöönotosta tämän vuoden joulukuussa alkaa kuulostaa kovasti optimistiselta.
Tilintarkastajien mukaan projekti on tullut jo yli 53 miljoonaa dollaria budjetoitua kalliimmaksi. Vaarana on myös se, ettei järjestelmä valmistuessaan palvele alkuperäisiä tavoitteitaan.
Yhdysvaltain armeija ei tarkastajien raportin mukaan ole itse yhtä huolissaan projektin tulevaisuudesta vaan toteaa, että esitetyt riskit ovat hallittavissa eivätkä ne vaikuta hankkeen kustannuksiin tai aikatauluun.
Anteeksi mitä täh häh? “Ei vaikuta kustannuksiin tai aikatauluun”? Kuinkahan paljon projektin pitäisi olla myöhässä, että se vaikuttaisi aikatauluun. Melko varma olen siitä, että armeijan päälliköt eivät tee tuota projektia omilla rahoillaan.
Älyttömän tarinan lopussa on kuitenkin jotakin järkevääkin.
Amerikkalaisen konsulttifirma Asuretin toimitusjohtaja Michael Krigsman muistuttaa, että kaikissa suurissa erp-projekteissa vaikuttaa aina kolme tekijää: ohjelmistotoimittaja, järjestelmäintegraattori ja asiakas. Jotta hanke onnistuu, kaikkien täytyy hoitaa oma roolinsa hyvin.
Eittämättä tässä tilanteessa asiakas, USAn armeija, ei ole vahtinut toimittajien perään riittävästi. Miksi pitäisikään, koska riskit ovat hallittavissa eikä aikatauluongelmia ole.
Yritykselläsi ei ole rahaa yhtä paljon kuin USAn armeijalla. Ennen toimitussopimuksen allekirjoittamista valitse itsellesi puolueeton kumppani, joka auttaa yritystäsi pitämään toimittaja aikataulussa.
Niin. Tulipa vaan mieleen, että entä jos USA:n sotilasvoimat ei suostukaan maksamaan Accenturelle? Ois ihan kiva nähä mitä tapahtuu, ku yrittävät pakottaa. Sotahan siitä syttyy 😉
Voittajia lienee turha arvailla.
No sepä vain 🙂
USA:n armeijalla on rahaa. Hiljattain Pentagon myönsi, että heiltä on hukassa tolkuton määrä rahaa jotka lähetettiin käteisellä laatikoissa Irakiin. Rahat ovat edelleen ”hukassa” eikä asia tunnu paljoa painavan. Ja vastaavia rahojen järjettömiä hukkaamisia sekä megalomaanisia budjettivajeita löytyy vielä lisääkin ihan riittävästi. Pointtini on, että tämä uutinen on äärimmäinen esimerkki eikä ole linjassa niiden pelisääntöjen kanssa joiden mukaan me muut pelaamme. Aikatauluilla tai varsinkaan rahasummilla ei näyttäisi olevan lainkaan merkitystä kun pelaajana on sotilasmahti.
Uutisen lopussa oli hyvin mielenkiintoinen virke josta lainaus kuuluu näin: ”erp-projekteissa vaikuttaa aina kolme tekijää: ohjelmistotoimittaja, järjestelmäintegraattori ja asiakas.”. Missä kohtaa tuolla on laadun varmistus? Kannattaisikohan noihin hommiin jo hiljalleen ottaa mukaan testauksen ammattilaiset jotka raportoivat systeemin kunnosta reaaliaikaisesti. Jos tosiaan kustannukset huitelevat jo miljardiluokassa, niin voisi olla järkevää sijoittaa vaikkapas 10 miljoonaa testaukseen. Ja puhun nyt ammattitestauksesta 🙂
Moro Ammttitestaaja, joko sitä on palattu sorvin ääreen vai onko lomat vielä tulossa?
Olisi hyvin mielenkiintoista tietää, että kuinka paljon tuollaisessa projektissa on etukäteen varattu paukkuja testaukselle ja että miten testaus laadunvarmistuksen osana on järjestetty.
Joka tapauksessa voitaneen olla sitä mieltä, että tässä projektissa kaikki ei ole mennyt ihan nappiin. Testaukseen joko ei ole panostettu riittävästi tai sitten panokset on sijoitettu kertakaikkiaan väärin.
Lomat on nyt lusittu ja on jälleen aika porautua testauksen maagiseen maailmaan 🙂
Sanoisin, että asevoimilla yleisesti ottaen on pitkät perinteet kalustonsa testauksessa. Jotkut ovat joskus syyttäneet joidenkin maiden asevoimia, että he tahallaan rientävät heti kaiken maailman konflikteihin jotta pääsevät testaamaan kalustoaan. Menemettä tähän seikkaan tätä pidemmälle, heitän väitteen jonka mukaan on täysin eri asia testata pommeja kuin massiivista organisaation hallintaohjelmistoa. Ohjelmistojen ja tietotekniikan testaus tekee poikkeaman klassiseen testaukseen. Toki big picture on samankaltainen, mutta yksityiskohdat erit.
Otetaan esimerkki asevoimia käyttäen: sanotaan nyt tuollainen armeijan perusrunkoon kuuluva tykki. Tykin käyttöliittymä on niin yksinkertainen, että tykkimieskin osaa sitä käyttää. Tykin testaus on suoraviivaista ja kaikki tietävät mitkä ovat tykin requirementit ja että milloin testitulos on passed. No entäs sitten ohjelmisto jonka on tarkoitus korvata useita muita ohjelmistoja ja jota käyttää tuhansia ihmisiä? Mitkä ovat requt ja mites se testataan? Tuohon tarvitaan aivan oma ammattikuntansa joka tuollaisen voi testata. Kyseeseen voi tulla ainoastaan ohjelmistojen testaukseen kutsumuksen saanut lievästi hullu ammattitestaaja. Näin se vain on.
Erinomainen esimerkki! Vaikka olisi kuinka monimutkainen sotavempele, se testataan todella huolellisesti ammattilaisten toimesta ennen tositilanteeseen joutumista. Epäonnistuneen laadunvarmistuksen seuraukset ovat paljon dramaattisemmat taistelutilanteessa kuin toimistotyössä.
Toki voidaan irvileukaisesti todeta, että ei se oo kiva sotilaillakaan, jos huolto tai ammukset jäävät saapumatta paikalle ERPin softavirheen takia.
Mukavaa alkavaa syksyä Ammattitestaajalle!