Organisaation operatiivinen toiminta on jatkuvien muutosten kohteena. Liiketoiminnan muutostarpeiden käsittelyä ja muutosten toteuttamista operatiiviseen toimintaan toteutaan tyypillisesti yskinkertaisen perusmallin mukaisesti, jota havainnollistaa alla oleva kuva.
Kehittämistoiminnan alussa liiketoiminnan muutostarpeet käsitellään: ne käydään yhdessä läpi, ja ne kuvataan määrämuotoiseen konseptidokumenttiin. Dokumentti voidaan laatia sopivimmalla välineellä, jonka käyttö on organisaatiossa vakiintunut (esim. Powerpoint tai Confluence). Konseptin sisältörakenteesta kannattaa laatia kuvauspohja (template), jotta konsepteista tulee yhteismitallisia. Silloin niitä on helpompi esitellä ja käsitellä, ja lopulta hyväksyä kehitysportfolioon. Kehitysportfoliossa kehittämiskohteet arvioidaan, priorisoidaan ja resursoidaan toteuttamista varten. Muutosten toteuttaminen voi olla esim. jokin seuraavista: itse tekeminen (IT-kehitys), hankinta, toimintamallimuutos / prosessimuutos, innovointikokeilu, pienkehitys jne.
Kehittämisen toimintamalli
Kehittämisen toimintamalli voidaan esittää kehittämisen arvovirtana, alla olevan kuvan mukaisesti. Kehittämisen arvovirta jalostaa kehittämistarpeista arvoa tuottavia digitaalisia palveluita tai toimintamalleja organisaation operatiiviseen toimintaan.
Kehittämistarpeiden käsittelyssä saadaan lentävä lähtö, mikäli organisaation kyvykkyydet on kuvattu. Kaikki kehittämiskohteet liittyvät johonkin määrättyyn organisaation kyvykkyyteen, joten kyvykkyyskuvauksien (kyvykkyyskanvaasien) avulla päästään suoraan kiinni muutostarpeiden kohteina oleviin operatiivisen toiminnan elementteihin. Konseptin käsittelyä helpottaa, mikäli organisaation kyvykkyydet tunnetaan ja ne on kuvattu (kyvykkyyskanvaaseihin).
Konseptointi
Konseptointi on kehittämisen toimintamallin vaihe, jossa kaikista liiketoiminnan muutostarpeista, eli kehittämistarpeista laaditaan konsepti. Kehittämistarpeella on joku omistaja, jolla on intressi edistää asiaa. Hän kokoaa kehittämistarpeen ympärille työryhmän, joka valmistelee ja suunnittelee yhdessä kuvauksen, konseptin. Konsepti on “diagnoosi” nykytilanteesta ja siihen aiotusta muutoksesta.
Konsepti käsitellään kehittämismallin mukaisesti yhteisessä arvioinnissa, jossa valitut konseptit esitellään ja hyväksytään, Hyväksymisen jälkeen konseptit siirtyvät kehitysportfolioon, jossa ne priorisoidaan, aikataulutetaan, resursoidaan, jotta ne voidaan edelleen siirtää määrättyyn kehitysjonoon tai määrätylle kehitystiimille toteutettavaksi.
Kehittämismalli voi perustua Lean EA -tyyppiseen lähestymistapaan, jossa kaikki kehittämiskohteet käsitellään yhteisessä tarpeiden käsittely (Demand Management) -toiminnossa. Konseptointivaihe edustaa Biz-Dev-Ops ajattelutavassa Biz osuutta, eli liiketoimintatarpeiden hallintaa.
Jotta kehittämiskohteita voidaan arvioida keskenään, ne on syytä kuvata yhdenmukaisella tavalla. Silloin kehittämiskohteita voidaan a) ymmärtää ja b) vertailla yhteismitallisesti. Kaikista kehittämistarpeista on suositeltavaa laatia konsepti, esimerkiksi alla olevan esimerkkirakenteen mukaisesti. Tässä esitetty sisältörakenne on eräs mahdollinen, ja tätäkin voi soveltaa (lisätä, muuttaa, poistaa) tarkoituksenmukaisella tavalla. Konseptiin pätee sama kuin moneen muuhunkin asiaan: mitä yksinkertaisempi kuvaus on, sitä helpompi sitä on täyttää, ja sitä helpompi sitä on käyttää, ymmärtää ja arvioida.
Konsepti on “diagnoosi” nykytilanteesta ja siihen aiotusta muutoksesta.
Konseptin rakenne
1. Tavoitteet
Aluksi on syytä läpikäydä yhdessä kehittämistarpeen alkusyy ja määritellä sen tavoitteet ja lopputulokset. Tämä on suositeltavaa tehdä yhdessä liiketoiminnan kehittämisestä vastaavan tahon kanssa siten, että kehittämistarpeen ehdottaja esittää asiat ja samalla ne yhdessä kirjataan oheiseen taulukkoon. Näin kehittämistarpeen idea saadaan muotoiltua kompaktisti, jotta oleelliset avainasiat käyvät ilmi mahdollisimman selkeästi, yksinkertaisesti ja helposti. Taulukkomuoto pakottaa tiiviiseen ilmaisuun ja täsmällisiin lauseisiin, ympäripyöreän ja epämääräisen kerronnan sijaan.
2. Liiketoimintamalli (Business Model Canvas, BMC)
Liiketoiminnallinen business case, kehittämiskohteen perustelu, voidaan esittää yleisen BMC-kanvaasin avulla. Se esittää kaiken oleellisen yhdessä kuvassa. Eli perustelut siihen, miksi juuri tämä asia kannattaa toteuttaa, ketä se palvelee, mitä hyötyä siitä on jne. Kuvauksessa voidaan avata myös saavutettavia laadullisia ja taloudellisia hyötyjä, sekä myös kustannuksia.
Liiketoimintamallin kuvaus voidaan laatia monilla eri välineillä. Tämä esimerkki (kuva yllä) on laadittu open source Archi-välineellä.
3. Yleiskuvaus – konseptin arkkitehtuurikuvaukset
Konseptoinnissa on syytä kuvata kehittämiskohteen konteksti, toimintaympäristö. Se voidaan tehdä esimerkiksi kerrosnäkymän avulla, jonka avulla voidaan havainnollistaa kehittämiskohteen kokonaiskuva. Kerrosnäkymän avulla voidaan esittää mm. mikä on se toiminta, johon muutos kohdistuu, ketkä/mitkä toimijat siellä toimivat, ja mitä järjestelmiä toiminnassa käytetään.
Kehittämiskohteeseen liittyviä tietovirtoja voidaan kuvata tietovirtakaaviolla, joka voidaan laatia helposti, kun tarvittavat tiedot on ensin koottu taulukkoon. Lisäksi voidaan kuvata kehittämiskohteen käsitteistöä käsitemallin avulla. Se helpottaa kohdealueen ymmärtämistä (mistä puhutaan kun tästä puhutaan?). Mikäli kyseessä on IT-kehittämistä, kuten jonkin järjestelmäratkaisun toteuttaminen, se voidaan kuvata erityisellä sovellusrakennekuvauksella. Sen tehtävänä on avata ns. ratkaisuarkkitehtuuria. Varsinaiset liiketoiminnan kannalta merkitykselliset asiat voidaan useimmiten kuitenkin esittää jo pelkästään kerrosnäkymän ja tietovirtakaavion avulla.
Tietovirrat eli tiedonvaihto (information switching)
Kehittämiskonseptien osalta on tärkeätä tunnistaa, mitä liiketoiminnan tietoa siirtyy ja mihin suuntaan se siirtyy. Tietovirtoja voidaan kerätä taulukkoon, jonka pohjalta voidaan tarvittaessa laatia visualisointi. Visualisoitu tietovirtakaavio on hyödyllinen, mikäli tietovirtoja enemmän kuin vain muutama. Kaaviossa voidaan osoittaa esimerkiksi värikorostuksilla integraatioiden elinkaaren tilaa (suunnitteilla/tuotannossa/poistuva), sekä tietovirran volyymitietoja, tiedonvaihdon mekamismeja ja protokollia (esim. ftp-siirto).
Huom! Tietolähde ja -kohde voivat olla a) toimjoita ja/tai b) järjestelmiä ja/tai c) prosesseja.
Tietovirtojen kuvaamisen kautta tunnistetaan integraatiopisteet, jotka ovat kokonaisarkkitehtuurin kannalta keskeisiä asioita. Integraatiot ovat tyypillisesti laajojen muutosten onnistumisten tai epäonnistumisen taustalla.
4. Tilanneanalyysi
Tilannetta voidaan laajemmin arvioida esimerkiksi SWOT-analyysin avulla, mikäli kokonaisuus on laaja-alainen ja sitä kannattaa tarkastella syvällisemmin. Pienempien kehittämistarpeiden tapauksessa tilannearviointi ei välttämättä tuota mitään lisäarvoa. Se on yleinen ja helppokäyttöinen menetelmä, jossa kokonaistilannetta voidaan arvioida kattavasti. Huomataan, että mikä tahansa muukin menetelmä voi olla yhtä toimiva tilannearviointiin.
5. Riskianalyysi
Kehittämiskohteeseen liittyvät uhkat ja riskit on syytä arvioida. Tämä voidaan tehdä esimerkiksi alla olevan taulukon esittämällä tavalla.
Riskien vähentämiseen voidaan kiinnittää erityistä huomiota jo konseptointivaiheessa. Tämä voidaan tehdä alla olevan taulukon mukaisesti.
6. Hyväksyntä & eteneminen
Konsepti esittelee kehittämistarpeen ja tavoiteltavan asiantilan, johon muutoksella pyritään. Erilaisia vaihtoehtoisia ratkaisuja on syytä arvioida. Arviointi voidaan tehdä näkyväksi tuomalla esiin eri vaihtoehtoja lyhyesti.
Suositeltava vaihtoehto perustellaan, ja sen toteuttamisen etenemismalli esitellään lyhyesti. Konseptin pohjalta voidaan tehdä päätös hyväksytäänkö vai hylätäänkö konsepti.
Muuta huomioitavaa
Tietoturva-asiat tulee myös huomioida heti alussa, kun kehittämiskohdetta aletaan konseptoimaan. Konseptipohjassa on mahdollisuus huomioida tietoturvaan ja tietosuojaan liittyviä asioita esim. seuraavasti: a) kuvaamalla arkkitehtuurin visualisoinnissa ne elementit, joihin kohdistuu tietoturvauhkia, tai b) kuvaamalla uhat ja riskit riskianalyysin yhteydessä. Tarvittaessa voidaan laatia erillinen tietoturvamallinnus, mikäli konseptoitava kehittämiskohde on erityisen kriittinen.
Konseptointivaihe edustaa Biz-Dev-Ops ajattelutavassa Biz osuutta, eli liiketoimintatarpeiden hallintaa.
“Yksi palvelu, tuhat tunnetta”
Asiantuntija- ja palveluorganisaatiossa palveluiden kehittäminen ja -johtaminen (palvelujohtaminen) ovat käytännön tasolla, operatiivisessa toiminnassa, merkityksellisiä asioita. Ei vähiten siksi, että asiakkaan kokema laatu kulminoituu palvelusta syntyvään vaikutelmaan, yksilölliseen ja subjektiiviseen asiakaskokemukseen. Tämä asiakaskokemus on hyvällä tasolla silloin, kun palvelun laatu on hyvällä tasolla. Laatuun voidaan vaikuttaa organisaation sisäisen toiminnan ja rakenteen tehostamisen keinoin, kun taas asiakkaan kokemukseen ei voida vaikuttaa: se syntyy asiakkaan tunnetasolla, ja on jokaiselle erityinen. Eli asiakaskokemus on tunnekokemus, joka voi samasta palvelusta olla jokaiselle asiakkaalle erilainen. Tähän vaikuttavat monet tekijät joihin organisaation sisältä ei voida vaikuttaa juurikaan, kuten palvelutilanteen vuorovaikutuksen henkilökemiaan, säätilaan, vuorokaudenaikaan, asiakkaan energiatasoihin jne. Näin ollen voidaan todeta, että yksi ja sama palvelu organisaation näkökulmasta voi näyttäytyä, ja näyttäytyykin tuhansina eri tunnekokemuksina eri asiakkaille – asiakasnäkökulmasta. Ei siis voida liikaa keskittyä asiakkaan tunteisiin, vaikka niiden merkitystä haluttaisiinkin korostaa. Kannattaa siis keskittyä organisaation tuottamaan laatuun, josta asiakkaan kokema arvo, asiakasarvo, syntyy. Asiakasarvo sinällään voi olla rahallista tai määrällistä (kampanja-alennus, määräalennus, tarjous), tai se voi liittyä ajan säästymiseen, vaivannäön vähentymiseen, toimenpiteiden helpottumiseen, nopeutumiseen yms., tai lisäarvoon kun palveluun tai tuotteeseen liittyy jokin lisäominaisuus, kylkiäinen, optio (myöhemmin lunastettava/tarjottava lisäetu tms.).
Laatu ja sen puute – häiriökysyntä
Se mihin voidaan vaikuttaa organisaatiossa, on palvelun tuottamisen laatu. Tätä mittaa esimerkiksi ns. häiriökysyntä. Häiriökysyntää syntyy, jos palvelun aikana asiakkaan tarvetta ei saada kerralla kuntoon, vaan asiakas joutuu palaamaan, eli kontaktoimaan, saman asian vuoksi useita kertoja palveluntarjoajan kanssa. Esimerkiksi ravintolassa annos ei vastaa tilattua, jolloin asiakas joutuu kontaktoimaan tarjoilijaa useita kertoja. Lopputuloksena on molemminpuolista turhautumista, ajanhaaskausta ja tarpeetonta vaivannäköä, sekä organisaation kannalta useita seurausvaikutuksia (lisätyötä, lisäkustannuksia, hävikkiä, resurssien kuormitusta, mainehaittaa jne.). Vastaavasti, jos asiantuntijaorganisaation huonosti suunnitellut digitaaliset palvelut (kuten sähköiset itsepalvelut, verkkopalvelut) pakottavat asiakkaan palaamaan samaan palveluun useita kertoja, esimerkiksi täydentämään antamiaan tietoja, syntyy sekä asiakkaalle että palvelun tarjoajalle turhaa lisävaivaa. Tällainen häiriökysyntä on turhaa, se kuormittaa tarpeettomasti molempia osapuolia. Siitä voidaan, ja siitä täytyy päästä eroon parantamalla palvelun laatua.
Kun palveluiden laatua pyritään parantamaan organisaation sisäisin toimenpitein, juurisyihin ja konkreettisiin asioihin päästään kiinni tarkastelemalla, kuinka palvelut tuotetaan: mitä ovat ne prosessit, joilla palvelua toteutetaan, mitkä toimijat osallistuvat palvelun tuottamiseen, mitkä ovat ne tiedot, joita prosesseissa käsitellään ja mitkä ovat ne järjestelmät, joita palvelun tuottamisessa hyödynnetään. Eli lopulta tarkastellaan, kuinka määrättyä kyvykkyyttä suoritetaan organisaatiossa. Toimitaanko laadukkaasti, vai voidaanko asioita tehdä vielä paremmin (“lite bättre“, Curt Lindström).