Mitä tahansa hieman monimutkaisempaa tietojärjestelmää (kuten laajamittaista Odoo-toteutusta) rakennettaessa tulee vastaan helposti monia kysymyksiä, jotka eivät ratkea välittömästi tutkimalla järjestelmän ominaisuuslistaa, lukemalla sen dokumentteja tai kokeilemalla järjestelmän demoversiota. Tällöin tarvitaan usein asiaan tarkempaa paneutumista.
Tietojärjestelmätyössä tällaista asiaan tarkempaa paneutumista kutsutaan konseptisuunnitteluksi, englanniksi Proof of Concept (PoC).
Konseptisuunnittelu on oleellista projektisuunnittelussa ennen kaikkea silloin, kun on tarpeen muuntaa monimutkainen tietojärjestelmätarve konkreettiseksi suunnitelmaksi.
Tässä kirjoituksessa käymme läpi mikä Proof of Concept on, miten se liittyy Odoo-projektien toteutukseen ja miten PoC eroaa prototyypistä.
Yleistä: mikä on Proof of Concept (PoC)
Konseptisuunnitelma, Proof of Concept (PoC) pohjimmiltaan yksityiskohtainen esitys ehdotetusta ratkaisusta ja sen sopivuudesta liiketoiminnan tarpeisiin.
PoC esittää ratkaisun ja sen pohjana olevan sovelluksen ja tämän toiminnot. Se kuvaa miten sovelluksella ratkaistaan ongelmat ja miten helppoa tai vaikeaa tämä on. Konseptisuunnitelma on usein ennakkoedellytys sille, että varsinainen tietojärjestelmä tai tämän prototyyppi voidaan rakentaa.
Konseptisuunnittelun tärkein tavoite asia on tuottaa järkevä vaatimusmäärittely lopputuotteesta. On tärkeää ymmärtää, että PoC:ssa ei vielä toimiteta varsinaista lopullista ratkaisua. PoC:ssa esitetään, miten asia saadaan aikaiseksi ja arvioidaan sen toteuttamiskyvykkyyttä. PoC eroaa merkittävästi myyntipresentaatiosta. Konseptisuunnittelu on ammattilaisvetoista ja siinä kaupalliset ehdot – kuten esimerkiksi sovelluskehityksen maksujen jaksotus – ovat toissijaisia.
Hyvin tehty PoC mahdollistaa sen, että liiketoiminnasta päättävät tahot pystyvät tekemään tietojärjestelmästä informoituja ja analyyttisiä päätöksiä. He ymmärtävät miten vaikeaa tai ylipäätään mahdollista järjestelmän tai sen eri osa-alueiden rakentaminen on.
Konseptisuunnittelu on erinomainen väline ennen kaikkea silloin, kun on tarve integroida useita tietojärjestelmiä keskenään.
Hyvä nyrkkisääntö tietojärjestelmätyössä on se, että minkä tahansa projektin suunnitellusta työmäärä ja aika kertautuvat aina integroitavien järjestelmien määrällä. Jos yhden ydinjärjestelmän rakentamiseen menee viikko, sen integroiminen toiseen järjestelmään lisää aikaa toisella viikolla. Kolmeen järjestelmään integroituminen puolestaan on jo kuukauden työ. Ja vaikeusaste vain kasvaa, jos integraation pitää olla kaksisuuntainen järjestelmien välillä.
Konseptisuunnittelussa onkin hyvä kuvata ja analysoida tarkasti, mikä on tarve eri järjestelmien väliselle integraatiolle ja mihin suuntaa tiedon pitää kulkea. Fiksu konseptisuunnittelija määrittää tässä yhteydessä myös vastuut eri tietojärjestelmien välillä; mikä tietojärjestelmä on master tuotetiedolle, täytyykö hintatietojen kulkea kahteen suuntaan ja mitä tapahtuu, jos tietoa päivitetään toisessa järjestelmässä.
Proof of Conceptin tärkein tuotos on hyvä vaatimusmäärittely. Viisas asiakas varmistaa järjestelmätoimittajalta tarkasti, mikä on PoC-työn lopputulos. Esimerkiksi meillä OBS:llä toimitaan juuri näin: PoC:ssa käydään läpi Odoo-toiminnanohjausjärjestelmän eri osa-alueet ja kuvataan kohta kohdalta, miten asia saadaan toteutettua. Onko se Odoon vakiotoiminto, vai vaatiiko se järjestelmän mukauttamista. Jos mukautusta vaaditaan, onko kyseessä täysin räätälöity ohjelmistokehitys, vai onko tarve toteutettavissa kolmannen osapuolen valmismoduulilla.
Prototyyppi: miten se eroaa Proof of Conceptista?
Usein vastaan tulee myös tilanteita, joissa projektiin osallistuvilla on hieman vääränlainen käsitys konseptisuunnitelmasta (PoC). Kuvitellaan, että konseptisuunnittelussa tuotetaan toimiva prototyyppi. Tämä käsitys on väärä.
Proof of Concept -konseptisuunnittelun tärkein tehtävä on varmistaa, että suunniteltu tietojärjestelmä voidaan toteuttaa. Prototyypin tärkein tehtävä on näyttää, miten haluttu toiminnallisuus pystytään toteuttamaan.
Kun konseptisuunnittelu on valmis, voidaan siirtyä rakentamaan joko prototyyppiä tai valmista tietojärjestelmää. Prototyyppi voi kohdistua myös vain osaan tietojärjestelmän toiminnallisuuksista. Meille OBS:ssä esimerkiksi on tullut vastaan tilanne, jossa eräs Odoo-integraatio oli erittäin monimutkainen. Päätimme siis toteuttaa konseptisuunnitelun jälkeen pienen prototyypin, jossa varmistimme, että integraatio on mahdollinen ja toimii kuten konseptisuunnittelussa oli hahmoteltu.
Projektisuunnittelun ja projektinhallinnan kannalta prototyyppiprojektit ovat erinomainen asia. Ne ovat tyypillisesti pieniä ja lyhyitä miniprojekteja, joissa ei tarvita projektinhallinnallista ”sälää” juuri lainkaan. Scope on hyvin selvä: selvitetään joku tietty asia ja näytetään se käytännössä. Asiasta kuitenkin puuttuvat koulutus, dokumentointi, jalkautukset ynnä muut asiat, jotka vievät perinteisestä projektinhallinnasta helposti leijonaosan.
Prototyypin ei tarvitse myöskään olla täydellinen. Esimerkiksi integraatioiden protyyppäilyssä ei tarvitse huolehtia virheidenhallinnasta. Ja käyttöliittymää prototyypitellessä sitä voidaan iteroida, kun ei tarvitse huolehtia siitä, meneekö jotain alla olevaa rikki.
Seuraavassa taulukossa on kuvattu muutamia prototyyppien ja PoC:n ydineroja.
Konseptisuunnitelma (Proof of Concept, PoC) | Prototyyppi |
Vastaa kysymykseen: voidaanko haluttu järjestelmä rakentaa vai ei? | Vastaa kysymykseen: miten tarkkaan ottaen haluttu tuote saadaan rakennettua |
Testaa idean ja oletuksien kelvollisuuden todellisessa elämässä | Luo interaktiivisen mallin, joka konkretisoi suunnitellun järjestelmän loppukäyttäjille |
Kuvaa idean, toiminnallisuuden ja tuotteen kelpoisuuden näiden toteuttamiseen | Näyttää miten tuote oikeasti saadaan toimimaan |
On teoreettinen demonstraatio siitä, että ratkaisu on saavutettavissa | On käytännöllinen demonstraatio siitä, miten lopputuote tulee toimimaan. |
Prototyypin ja konseptisuunnittelun ero aukeaa ehkä parhaiten miettimällä esimerkkiä lautapelin suunnittelusta. Pelisuunnittelussa PoC kertoo, mikä on pelin atmosfääri (ydinsodan jälkeinen tulevaisuus), mitä eri hahmoja pelaaja pääsee kontrolloimaan (urhea vapaustaistelija) ja miten pelin säännöt toimivat (kolmiulotteinen ammuskelupeli) ja mikä on pelin käyttöliittymä (virtuaalitodellisuus).
Prototyyppi puolestaan on esiversio pelistä, jossa sitä itse pääsee pelaamaan.
Proof of Concept ja prototyyppi Odoo-projektissa
Odoo-projekteissa konseptisuunnittelu tarkoittaa sitä, että käymme läpi OBS:n asiantuntijoiden johdolla kaikki järjestelmän osa-alueet ja integraatiot kolmansiin järjestelmiin. Kirjaamme asiakkaan esittämät tarpeet ylös ja kiinnitämme huomiota ennen kaikkea siihen, mitä toiminnallisuuksia ei saada toteutettua Odoon vakiotoiminnallisuuksilla.
Odoo-projekteissa konseptisuunnittelussa on usein hyvä käydä myös läpi, miten Odoon logiikka toimii ja mitä toimintoja on vaikeaa toteuttaa. Näin pystytään välttämään tilanteet, joissa Odoon haluttaisiin tekevän jotain sellaista mihin se ei luontevasti kykene. Tämä osuus on tehokkainta tehdä avaamalla Odoo ja katsomalla, miten asia tarkkaan ottaen toimii. Hyviä esimerkkejä ovat Odoon tuotevarianttien käsittelyn logiikka ja valmistusmoduulin toiminnallisuudet.
Lopputuloksena on vaatimusmäärittely, jonka avulla asiantunteva Odoo-toimittaja pystyy antamaan sitovan hinta-arvon projektin toteuttamisesta.
Prototyyppi Odoo-projektissa puolestaan rakennetaan osittain toimiva järjestelmä. Järjestelmään voidaan esimerkiksi ladata asiakkaan koko asiakas- tai tuoterekisteri ja esittää miten niiden avulla pystytään muodostamaan automaattisia markkinointikirjeitä tai miten tuotteiden päivitys onnistuu Odoosta WooCommerceen. Myös erilaisten integraatioiden testaaminen käytännössä on monessa tapauksessa fiksua. Tällaisten testaaminen vähentää riskiä siitä, että projektin aikana vastaan tulee yllätyksiä ja näitä ei pystytäkään sitten toteuttamaan.
