"Analysis of Penalties Incurced by Sub-par Skills vs. Potential Savings on IT Staff Hourly Rates" (Analyysi huonoista taidoista aiheutuvista seuraamuksista vs. mahdolliset säästöt IT-henkilöstön tuntihinnoissa)
Kirjoittaja: Wojciech Ciesielski, ohjelmistokehityspäällikkö / arkkitehti, Software Mind
Alkuperäinen artikkeli julkaistu osoitteessa LinkedIn Pulse -palvelussa
Outsourcing Ohjelmistokehityspalvelut ovat olleet jo vuosia jatkuva trendi, ja vaikka ne ovat edelleen suosittu toimintamalli monilla toimialoilla, niiden tulokset eivät suinkaan ole aina vastanneet johdon odotuksia. Se, mikä näytti paperilla helpolta ratkaisulta toimintakustannuksia vertailtaessa, osoittautui käytännössä huomattavasti monimutkaisemmaksi. Esimerkiksi General Motorsin tyytymättömyys IT- outsourcing -palveluun sai yrityksen kumoamaan prosessin. Vuonna 2012 GM ilmoitti suunnitelmistaan siirtää 3 000 IT- työpaikkaa, jotka oli aiemmin ulkoistettu Hewlett-Packardille, takaisin yrityksen sisälle. Vuoden 2015 puoliväliin mennessä autovalmistajan suunnitelmiin sisältyi tavoite, että vuonna 2017 IT-henkilöstön määrä olisi 12 000, mikä on lähes kymmenkertainen lisäys verrattuna vuoden 2012 1 400 IT-työntekijään.
Tässä artikkelissa pyritään kuvaamaan usein huomiotta jääviä näkökohtia, jotka liittyvät ohjelmistokehitykseen ” outsourcing ” -periaatteiden mukaisesti ja jotka vaikuttavat merkittävästi siihen, millainen kokonaisvaikutus tällaisilla hankkeilla on liiketoiminnan tuloksiin.
Pätevät ohjelmistokehittäjät ovat kallista työvoimaa. Kun verrataan IT-alan palkkoja esimerkiksi Saksassa, Isossa-Britanniassa tai Yhdysvalloissa lähialueiden tai ulkomaisten palveluntarjoajien tarjoamiin hintoihin, näyttää siltä, että ainoa järkevä vaihtoehto on siirtyä käyttämään heidän palveluitaan. Teoriassa tämä päätös tuo välittömästi 20–70 prosentin kustannussäästöjä. Mutta onko se todella niin?
Jostain syystä monet outsourcing -sopimukset tuottavat syvän pettymyksen, sillä ne eivät täytä liiketoiminnallisia odotuksia. Uuden ohjelmiston toimitusvauhti on odotettua hitaampi. Tuki- ja ylläpitokustannukset nousevat huimasti. Jopa melko yksinkertaisten muutosten käyttöönotto vie viikkoja tai jopa kuukausia. IT-ratkaisujen luotettavuus on kaukana tyydyttävästä, mikä aiheuttaa lukuisia käyttökatkoksia, jotka heikentävät tulosta ja/tai mainetta ulkoisten kumppaneiden ja asiakkaiden keskuudessa.
Monet näistä epäonnistumisista johtuvat liian yksinkertaistetusta lähestymistavasta sijoitetun pääoman tuoton (ROI) laskemiseen, jolloin ohjelmistokustannukset supistetaan lähes yksinomaan työvoimakustannuksiksi. Perustuen kokemuksemme kokemuksemme mukaan osaamisen laadussa olevat erot voivat vaikuttaa tulokseen huomattavasti enemmän kuin tuntipalkkojen erot.
Jos ohjelmistokehityshankkeen ( outsourcing ) suunniteltua sijoitetun pääoman tuottoa (ROI) laskettaessa keskitytään pääasiassa sopimustyöntekijöiden tuntipalkkojen vertailuun yrityksen oman henkilöstön tai muiden toimittajien tarjoamiin palkkoihin, jää huomattavia piilokustannuksia huomioimatta. Tässä artikkelissa keskitymme kahteen usein huomiotta jäävään tekijään, jotka vaikuttavat merkittävästi minkä tahansa ohjelmistokehityshankkeen lopputulokseen: ohjelmistotoimitusprosessin tehokkuuteen sekä taloudellisiin seurauksiin, joita aiheutuu laadun puutteesta, joka johtuu riittämättömästi pätevistä kehitystiimeistä.
Yksi ratkaisevan tärkeistä tekijöistä, jotka määrittävät organisaation kykyä saavuttaa korkea sijoitetun pääoman tuotto (ROI) ohjelmistokehitykseen tehdyistä investoinneista, on itse kehitysprosessin tehokkuus.
Alalla on havaittavissa selvä maailmanlaajuinen suuntaus siirtyä perinteisistä vesiputousmallin mukaisista kehitysprosesseista kevyempiin lähestymistapoihin. Agile-menetelmät, kuten SCRUM, ovat nykyään vakiintunut ratkaisu kaikissa yrityksissä, jotka pyrkivät alan johtavaan asemaan. Oikein toteutettuna ne tuovat organisaatioille merkittäviä etuja:
- Lyhyt markkinoille saattamisen aika, jotta loppukäyttäjille voidaan tuottaa liiketoiminnallista arvoa
- Parempi kyky sopeutua muuttuviin liiketoimintaolosuhteisiin
- Projektin kustannusten ja laajuuden huomattavasti parempi hallinta
Lyhyt markkinoille saattamisen aika, jotta loppukäyttäjille – olivatpa he sitten sisäisiä tai ulkoisia (asiakkaat, yhteistyökumppanit) – voidaan tuottaa liiketoiminnallista arvoa . Perinteisellä vesiputousmallilla toteutetut projektit kestävät yleensä kuukausia, joskus jopa vuosia. Kaikki kehitystyöhön tehdyt investoinnit ovat lukittuina ja jäädytettyinä, kunnes ohjelmisto saavuttaa käyttäjät. Agile-menetelmien pääperiaate on toimittaa toimivia ohjelmistoversioita vaiheittain, jolloin jokainen versio tuo mukanaan lisää liiketoiminnallista arvoa. Tämä tarkoittaa, että jokaisen julkaisun jälkeen (yleensä vähintään kerran kuukaudessa tai kahdessa, parhaiden tiimien lyhentäessä julkaisuvälin kahteen viikkoon tai lyhyemmäksi) ohjelmiston tuomat hyödyt alkavat kattaa sen kehittämiskustannukset.
Parempi kyky sopeutua muuttuviin liiketoimintaolosuhteisiin. Jos projekti toteutetaan perinteisen mallin mukaisesti, muutoksen käyttöönotto on monimutkainen ja työläs prosessi. Se edellyttää suunnitteludokumenttien, projektiaikataulujen, sovitun laajuuden ja projektin aikataulun muuttamista. Tilannetta monimutkaistaa entisestään se, että projektin alkuvaiheessa laaditut vaatimusmäärittelyt, suunnitteludokumentit ja projektiaikataulut kattavat koko projektin.
Lean-prosessissa määrittely-, suunnittelu- ja suunnitteluvaiheet toteutetaan lyhyemmissä sykleissä, joissa keskitytään ominaisuuksiin niiden liiketoiminnallisen arvon tuottamiskyvyn mukaan järjestettynä. Tämä supistaa luonnollisesti niiden muutosten laajuutta, joita liiketoiminnan sidosryhmät saattavat pyytää. Se tarkoittaa, että muutosten käyttöönottoon liittyy huomattavasti vähemmän menettelyllisiä esteitä, jotka muutoin aiheuttaisivat muutoksenhallintakustannuksia.
Merkittävästi parempi hallinta projektikustannusten ja laajuuden suhteen. Yksi kalliiksi käyvistä väärinkäsityksistä, joita esiintyy usein ei-teknisillä johtajilla, on se, että vesiputousmalli tarjoaa paremman hallinnan projektin toimitusaikataulun, budjetin ja yleisen sijoitetun pääoman tuoton (ROI) suhteen. Tämä johtuu virheellisestä olettamuksesta, että monimutkaisen, monialaisen, useiden toimijoiden välisen ja viestintää vaativan prosessin – jolla toimitetaan monimutkaista ohjelmistoa – olisi mahdollista määritellä, suunnitella ja aikatauluttaa tarkasti. Lukuisat epäonnistuneet vesiputousmallilla toteutetut projektit, jotka joko peruutettiin tai ylittivät suunnitellut budjetit huomattavasti, osoittavat, kuinka vaarallinen ja yleinen tämä oletus on.
Keskustelu siitä, kuinka lean- ja agile-prosessit voivat antaa tuotevastaaville huomattavasti paremman hallinnan IT-kustannuksistaan, jää ehdottomasti tämän artikkelin aihepiirin ulkopuolelle. Yksi parhaista johdannoista tähän aiheeseen on erittäin suositeltava kirja ”Software in 30 Days”, jonka ovat kirjoittaneet SCRUM-menetelmän luojat Ken Schwaberin ja Jeff Sutherlandin. Tämä erinomainen, johtamiseen keskittyvä SCRUM-esittely kuvaa menetelmän periaatteita, etuja ja tapoja ottaa se käyttöön organisaatiossa. Luku siitä, kuinka lean-pohjainen empiirinen prosessi lisää suunnittelun tarkkuutta, on avannut silmiä monille, jotka ovat tottuneet perinteiseen ajatteluun IT-projektien suunnittelusta ja budjetoinnista.
.jpg)
.jpg)
.jpg)
