Kaiken liiketoiminnan, prosessien ja palveluiden perustana ovat informaatioteknologiaan perustuvat liiketoimintaratkaisut ja -alustat, joita ylläpidetään ja kehitetään jatkuvasti. Vaikka suurin osa organisaation kehitysaloitteista liittyy olemassa oleviin ratkaisuihin ja palveluihin, tarvitaan myös innovatiivisia ratkaisuja ja palveluja mahdollistamaan liiketoiminnan kasvu ja muutos.
Kehitysaloitteet jaotellaan arvonluonnin kanaviin, arvovirtoihin, joissa on ymmärrys siitä, miten ja millä ratkaisuilla liiketoiminnalle tuotetaan parhaiten arvoa. Arvovirrat voidaan organisoida teknologian käyttötarkoituksen tai bisnesalueiden mukaan tai niiden yhdistelmänä (lue lisää arvovirroista kappaleesta 2.1 Strateginen suunnittelu).
Kehitysaloitteet muodostavat arvovirtojen kysynnän, ja ne voidaan jakaa neljään eri kysynnän lähteeseen, kuten alla oleva kaavio osoittaa:
- kyvykkyyksien suunnittelu – suunnitellaan merkittävimmät liiketoimintakyvykkyyksien kehitystarpeet
- ideat ja konseptit – tuotetaan ideoista konsepteja ja haastetaan nykytila
- lisäykset ja parannukset – kehitetään olemassa olevia liiketoimintaratkaisuja ja kyvykkyyksiä
- palvelumuutokset – palveluiden jatkuva pienimuotoinen kehittäminen.
Kysynnän lähteissä kehitysaloitteet jalostuvat kehityspyynnöiksi, jotka johtavat tuotteiden, ratkaisujen ja palveluiden kehittämiseen erilaisia menetelmiä käyttäen.
Kuva 5.0.1 Liiketoimintatarpeesta palvelutuotantoon
Kehittämisen johtamisalue keskittyy liiketoimintahyötyjen tuottamiseen. Tasapainoilu lyhyen ja pitkän aikavälin hyötyjen tavoittelemisen välillä voi kuitenkin olla vaikeaa: on päätettävä, reagoidaanko liiketoiminnan välittömiin tarpeisiin kehittämällä olemassa olevia ratkaisuja ja palveluja vai investoidaanko pikemminkin arkkitehtuurimuutokseen ja uusien, innovatiivisten ratkaisujen kehittämiseen. Kehittämisen johtaminen tarjoaa tehokkaat ja parhaisiin käytäntöihin perustuvat keinot hallita eri lähteistä tulevia tarpeita ja varmistaa liiketoimintahyötyjen saavuttaminen.
Seuraavat perusperiaatteet varmistavat sekä lyhyen että pitkän tähtäimen liiketoimintahyödyt:
- Varaa resurssit käytettäväksi yksinomaan tiettyjen kehityspyyntöjen käsittelyyn tehokkuuden ja nopeamman läpimenoajan varmistamiseksi.
- Pidä kehitystoiminta kurinalaisena suunnittelemalla ja organisoimalla sopiva toiminta- ja hallintomalli. Tämä auttaa tunnistamaan riippuvuudet muiden projektien kanssa ja tekemään korjaustoimenpiteitä ajoissa.
- Pysy lähellä liiketoimintaa paremman liiketoimintahyödyn varmistamiseksi. Ylimmän johdon päätöksenteko ei ole yksinään riittävä toimenpide varmistamaan, että liiketoiminnan näkemys säilyy koko kehitysputken läpi. Sen sijaan nopeasykliset palautekierrokset liiketoiminnan, kehitystiimien ja loppukäyttäjien välillä takaavat ajantasaisemman näkemyksen ja valistuneen päätöksenteon.
Oikean kehittämismenetelmän valinta
BT-standardi ehdottaa kahta vaihtoehtoista kehittämismenetelmää:
- Projektoitu, vaiheittainen kehityskulku (eng. sequential development), joka koostuu tietystä määrästä kehitysvaiheita, ja jossa edeltävä vaihe täytyy aina olla tarkastettu ennen seuraavaan vaiheeseen siirtymistä. Laadun varmistaminen tehdään laatimalla hyväksymiskriteerit ja testitapaukset, joiden avulla tarkistetaan, täyttääkö ratkaisu kokonaan tai osittain vaatimukset. Tämän jälkeen testaustiimi suorittaa testit ja hyväksyy kehitetyn tuotteen.
- Jatkuva, täydentävä kehityskulku (eng. incremental development), joka koostuu toistuvista, ratkaisua täydentävistä (tai iteratiivisista) kehityssykleistä (tai sprinteistä), ja jossa loppuasiakkaan palautetta kerätään jokaisen täydennyksen osalta. Tässä kehittämismenetelmässä isommat kokonaisuudet on jaettu pienempiin osakokonaisuuksiin, joita kutsutaan sprinteiksi. Ratkaisua kehitetään vähitellen ja testataan sprinteissä. Käyttöönoton ja testauksen yhdistäminen samaan sprinttiin luo luontaisen sillan seuraavaan sprinttiin, ja testaus puolestaan tarjoaa palautetta seuraavaan käyttöönottoon tai sprinttiin. Täysin sovellettuna tämä kehittämismenetelmä aikaistaa liiketoimintahyötyjen kertymistä, sillä ratkaisuja voidaan julkaista tuotantoympäristössä jo varhain, sprintti kerrallaan, minimiratkaisua (minimum viable product) täydentämällä.
Resurssien jakaminen toimitusvaiheessa
Resurssien jakaminen kehityspyyntöjen toteuttamiseen voidaan tehdä kahdella eri tavalla: käyttämällä tehtävään varattuja (eng. dedicated) tai jaettuja resurssitiimejä. Molempien tiimien toimintaa ohjaa liiketoimintahyötyjen maksimointi.
- Tehtävään varattujen resurssitiimien käyttö mahdollistaa nopeamman tuotekehitysajan (eng. time-to-market), koska päätöksenteko on yksinkertaisempaa ja tiimien koko työaika on varattu (omistettu) yhden kehitysvirran tarpeille. Ketterien kehitysmenetelmien jatkuva käyttö luo rutiinit, jotka helpottavat tiimin sisäistä viestintää ja yhdessä tekemistä. Tiimin koko pysyy samana, ja siksi kustannukset ovat kiinteät. Tiimin täytyy kuitenkin pystyä jatkuvasti osoittamaan kehittämiensä tuotosten arvo. Tätä resursointitapaa käytetään tyypillisesti jatkuvan kehityskulun kehittämismallissa.
Kuva 5.0.2 Tehtävään varatut resurssitiimit
- Jaetut resurssitiimit jakavat joustavasti kapasiteettiaan eri kehitysvirtojen välillä, ja resurssien käyttöä voidaan tarvittaessa kohdentaa laajempien kehityshankkeiden tarpeisiin. Koska kehityspyyntöjä on yleensä enemmän kuin mitä jaetut resurssitiimit voivat hoitaa, resurssien priorisointi tehdään keskitetysti. Tämä voi hidastaa tuotekehitysaikaa, mutta samalla tämä lähestymistapa varmistaa, että korkealle priorisoidut kehittämishankkeet saavat tarvittavat resurssit käyttöönsä. Tätä resursointitapaa käytetään yleensä projektoidun kehityskulun mallissa.
Kuva 5.0.3 Jaetut resurssitiimit
Isompien ja epätavallisten kehityspyyntöjen osalta hyvä käytäntö on tehdä asiasta projektialoite, sillä se auttaa hyvän hallintotavan ja ohjausryhmän käytäntöjen muotoutumista.
Suuret yritykset käyttävät usein sekä tehtävälle varattujen että jaettujen resurssitiimien kapasiteettia kehitystavoitteen saavuttamiseksi. Usein keskeisten liiketoiminta-alustojen kehittäminen vaatii jatkuvaa kehittämistä, ja siksi kehittämisestä vastaavat näihin tehtäviin omistetut tiimit. Tehtävään varattuja resursseja käytetään usein myös uusien digitaalisten ratkaisujen kehittämisessä, koska siten tuloksia saavutetaan nopeammin.
Kehittämisen johtamisalueen ydinkomponentit
Kuva 5.0.4 Kehittämisen johtamisalueen kuusi hallintoelementtiä
Kehittämisen johtamisalueen toiminta- ja hallintomalli voidaan sovittaa organisaatiokulttuurin mukaiseksi. Seuraavat periaatteet olisi hyvä huomioida kaikissa tapauksissa:
- Tarkoituksenmukaisuus ja priorisointi varmistavat, että tärkeät kehityspyynnöt saatetaan loppuun ensimmäiseksi ja että kehitettävä ratkaisu tuottaa mahdollisimman suuren liiketoimintahyödyn. Lisäksi ne edellyttävät kyvykkäiden henkilöiden nimeämistä projekteihin.
- Sitoutuminen kehityspyynnön toteuttamiseen antaa valtuutuksen ihmisten ja muiden resurssien kiinnittämisestä kehittämiseen. Sitoumus perustuu kehityspyynnön hyväksyntään priorisointivaiheessa huomioiden muun muassa resurssien saatavuuden, riippuvuudet, sidosryhmien valmiudet ja riskit.
- Ohjaus ja riskienhallinta tukee päätöksentekoa kehitysprosessin aikana ja auttaa käsittelemään tunnistetut riskit. Nopeat ja toistuvat kehitysvaiheet auttavat riskien tunnistamista ja käsittelyä sekä poistavat turhia viiveitä myöhemmissä vaiheissa. Porttikohtaiset tarkistuspisteet ja ohjausryhmät auttavat riskien käsittelyä laajempien ja liiketoimintavaikutuksiltaan suurempien kehitysohjelmien osalta.
- Kehittämismenetelmä koostuu hyvin määritellyistä ja kaikkien ymmärtämistä käytännöistä, joilla ratkaisu suunnitellaan, hyväksytään ja otetaan käyttöön liiketoimintaympäristössä. Teknisen kehittämisen lisäksi pitäisi kiinnittää huomiota muutoksen hallintaan, joka auttaa saavuttamaan todelliset liiketoimintahyödyt. Muutoksen hallintaa ovat esimerkiksi viestintä sidosryhmien kanssa, koulutustilaisuuksien pito ja palautteen kerääminen.
- Siirto palvelutuotantoon varmistaa, että liiketoimintaprosessien jatkuvuus ei vaarannu, kun uusia tai muuttuneita ratkaisuja siirretään tuotantoon. Selkeät prosessit ja vastuut sekä tälle toiminnolle omistetut resurssit luovat kyvyn ja kapasiteetin vastata nopeasti ja onnistuneesti tuotantoonsiirtopyyntöihin.
- Hyötyjen toteutuminen alkaa, kun ratkaisu on tuotannossa ja kun hyötylaskelmassa alun perin suunnitellut hyödyt on saavutettu. Projektin aikana syntyneitä näkemyksiä ja kokemuksia voidaan hyödyntää priorisointiprosessissa oppina ja tulevaisuuden päätöksenteon tukena. Liiketoimintahyödyt konkretisoituvat yleensä palvelun käyttöönoton jälkeen mutta niiden toteutumista on hyvä monitoroida myös pidemmällä tähtäimellä.
Alla oleva taulukko osoittaa, miten eri kehittämismenetelmiä sovelletaan pääperiaatteiden kanssa.
| |
Projektoitu kehityskulku |
Jatkuva kehityskulku |
| Tarkoituksenmukaisuus ja priorisointi |
Projektiryhmä on laatinut hyötylaskelman, sille on projektin ohjausryhmän hyväksyntä ja salkun ohjausryhmä on tarkistanut ja priorisoinut sen. |
Tuoteomistaja priorisoi kehitysjonossa olevat pyynnöt perustuen arvovirtojen sidosryhmien tarpeisiin. |
| Sitoutuminen kehityspyynnön toteuttamiseen |
Projektin ja kehityssalkun ohjausryhmät hyväksyvät projektisuunnitelman, varaavat tarvittavat resurssit ja huolehtivat toimintaedellytyksistä. |
Kehitystiimi päättää, mitä kehitysjonon pyyntöjä he voivat viedä loppuun seuraavassa sprintissä. |
| Ohjaus ja riskien hallinta |
Riskisuunnitelma tehdään etukäteen, ja ennakoidut riskit otetaan seurantaan. Projektin välitavoitteet ja tarkistuspisteet tarjoavat ohjauksen ja riskien seurannan koko projektin ajan. |
Kehittäminen on jaettu pienempiin osatuotoksiin, joita käsitellään useammin (päivittäiset seisomakokoukset, sprinttisuunnittelu jne.) |
| Kehittämismenetelmä |
Jokainen etappi edustaa erillistä kehitysvaihetta, jotka täytyy viedä loppuun vaihe kerrallaan. |
Kehittämistä tehdään jatkuvissa sprinteissä. Halutut ominaisuudet ja vaatimukset tallennetaan kehitysjonoon. |
| Palvelun siirto tuotantoon |
Viimeistelty tuotos testataan ja viedään kehittämisen lopuksi tuotantoon. |
Jokaisen kehityssyklin päätteeksi tehdään testaus ja siirto tuotantoon sekä kootaan palaute. |
| Hyötyjen toteutuminen |
Lähes kertavaikutuksena, kun valmis lopputulos otetaan käyttöön. |
Osittaisina jokaisen kehityssyklin lisätessä hyötyelementtejä. |
Kevyen hallintomallin soveltaminen (eng. Minimum Viable Governance, MVG)
Kevyt hallintomalli on tehokas menetelmä kehittämisen tuotosten yhdenmukaisuuden ja tehokkuuden varmistamiseksi ketteryydestä ja nopeudesta tinkimättä.
Hallintomalli varmistaa yrityksen yleisten tavoitteiden ja strategian mukaiset vastuut, auktoriteetin ja viestinnän. Se myös määrittelee mittarit, käytännöt, standardit sekä valvontamekanismit, joiden avulla työntekijät voivat hoitaa tehtävänsä ja vastuunsa tehokkaasti. Oleellista on kuitenkin löytää oikea tasapaino hallinnon ja ketteryyden välillä.
Organisaatiot voivat myös määritellä tehokkaita prosesseja ja käytäntöjä, kuten esim. itsearviointimekanismit, sekä seurata tuotosten valmistumisen hyväksynnän kriteereitä. Kehitystiimit voivat arvioida, täyttyväkö vaatimukset kysymällä esimerkiksi seuraavia kysymyksiä:
Täyttääkö hanke nopean etenemisen kriteerit? Kuuluvatko valitut toimittajat hyväksyttyjen kumppaneiden listalle? Ovatko oikeat sidosryhmät mukana? Vastaako ratkaisu olemassa olevia arkkitehtuuristandardeja? Onko ratkaisu tietosuojakäytäntöjen mukainen?
Hankkeiden hallinnointi kehittämisen elinkaaren ajan vaihtelee käytetyn menetelmän mukaan.
Olemassa olevien ja valmiiden kehittämiskäytäntöjen soveltaminen
BT-standardi tarjoaa pragmaattisen ja liiketoimintalähtöisen viitekehyksen kehittämiskäytäntöjen soveltamiseen. BT-standardi soveltuu kypsyysasteeltaan eri tyyppisiin organisaatioihin, ja sitä voi käyttää yhdessä muiden käytäntöjen, kuten Scaled Agile Framework ja DevOps, kanssa. Alla on esiteltynä muutamia kehittämisen käytäntöjä:
- Scaled Agile Framework (SAFe) perustuu tietyllä liiketoimintafokuksella järjestettyihin kehittämisen työjonoihin ja niiden riippuvuuksien hallintaan. Se tarjoaa jatkuvan kehittämisen putken ideasta palveluun, ja käyttää sisäänrakennettuja priorisointi- ja ohjausmenettelyjä.
- DevOps (Develop and Operate) voidaan ottaa käyttöön pienimuotoisemmin, koska siinä on vähemmän kokonaiskoordinaation ohjaus- ja hallintomenettelyjä. DevOps sopii hyvin yhden tuote- tai palvelualueen jatkuvaan kehittämiseen.
- Projekti- ja salkkujohtaminen (eng. Project and Portfolio Management, PPM) hallinnoi projektien suhdetta liiketoimintastrategian tavoitteisiin. Se on rakenteellisesti hyvin järjestetty lähestymistapa, jolla kontrolloidaan monimutkaisia projekteja ja ohjelmia, joilla on suuri liiketoimintavaikutus ja merkittäviä riippuvuuksia. Projekti- ja salkkujohtaminen valikoi ja priorisoi projektit, varaa niihin resurssit, monitoroi edistymistä ja tarjoaa keskitettyä informaatiota projekteista sidosryhmille.
