Miten valita toimialaan ja toimintamalliin sopiva low-code-alusta?

Mutta tärkein ominaisuus low-code-alustoissa on ja pysyy: ne on optimoitu joko sovellusten kehittämiseen tai työn tuottavuuden lisäämiseen. Yhdessä paketissa ei näitä kahta ominaisuutta näytä löytyvän muualla kuin toimialakohtaisissa ratkaisuissa.

No-code- ja low-code-alustojen tärkein ominaisuus on kehittämisen ja muutosten nopeus ja helppous. Toiminnallisuus kuvataan graafisesti käyttäen joko toimittajan omaa tai standardoitua kehitysmenetelmää. No-code- ja low-code-ratkaisu kääntää toiminnallisuuden koodiksi, joka sitten toteuttaa sovelluksen, palvelun tai prosessin.

No-code- ja low-code-kehittämisen hyödyt verrattuna avoimeen lähdekoodiin

No-code- ja low-code-kehittämisen suurin hyöty verrattuna avoimeen lähdekoodiin ja kirjastoihin on työhön, testaukseen, käyttöönottoon ja ylläpitoon käytetyn ajan ja kustannuksen pienentyminen murto-osaan. Bugikorjauksia ja uusia toimintoja voidaan tehdä tunneissa, ja viedä niitä tuotantoon muutamassa päivässä. Suurin syy tehokkuudelle on se, että kehittäjät ja liiketoiminta ymmärtävät toisiaan paremmin low-code- tai no-code-ympäristössä. Ohjelmointikielen aiheuttamaa muuria ei ole.

Käytän tässä tästä eteenpäin vain sanaa low-code, koska todellisuudessa vain kaikkein yksinkertaisimmat prosessit, jotka eivät vaadi tietoa alustan ulkopuolelta, voidaan toteuttaa no-code-tyyppisesti. Puhtaan no-coden suurin hyöty on se, että niitä voi kehittää lähes kuka tahansa. Forresterin artikkelissa todettiin, että jos osaa kuvata ja käsitellä tietoa Excelissä, osaa myös konfiguroida no-code-ratkaisuja.

Low-code-alustan valinta

Viime vuosina low-code-alustat ovat ottaneet toiminnallisuusharppauksia ja alkaneet erikoistumaan. Samalla on ratkaisujen määrä kasvanut. Low-code-alustoja on useita kymmeniä jollei jopa satoja. Näistä pitäisi liiketoiminta- ja IT-päättäjien yhdessä löytää omaan toimintaympäristöön ja vaatimuksiin sopiva toimittaja.

Tämä siis ei ole päätös, joka tulisi tehdä IT-osastolla. Low-code -kehittäminen tehdään lähellä liiketoimintaa ja jatkossa ainakin osittain liiketoiminta-asiantuntijoiden ns. kansalaiskehittäjien (citizen developer) toimesta. Päätös on ensisijaisesti liiketoimintavetoinen, mutta IT-päättäjien ja tekijöiden mukanaolo ja sitoutuminen päätökseen on tärkeää.

Low-code-alustan ja toimittajan valinta tulisi lähteä liiketoiminnan tarpeista ja kriteereitä kannattaa miettiä etukäteen. Näihin kysymyksiin olisi syytä löytää jonkinlaiset vastaukset ennen ostoprosessin käynnistämistä:

• Mitä ongelmaa ollaan ratkaisemassa ja miksi?
• Kuinka paljon vastaavia ongelmia on olemassa (Low-code alustojen hankinta- ja/tilaushinta on usein sen verran korkea, että kehitettäviä palvelu ja sovelluksia pitää olla paljon)?
• Minkälaiseen toimintamalliin low-code-alustaa tullaan käyttämään?
• Minkälainen on ammattilaisen rooli ja mitä osaamista se vaatii? Mitä uutta osaamista pitää kehittää? Aiotaanko käyttää kansalaiskehittäjiä?
• Kuinka tärkeä rooli on asiakkaan käyttöliittymällä ja sen hienoudella, sekä tarvitaanko useita erityyppisiä käyttöliittymiä palveluiden toteuttamiseen vai onko tarve itse asiassa vain suhteellisen yksinkertainen lomake?
• Kuinka paljon palveluprosesseja on ja kuinka erilaisia ne ovat toisistaan?
• Tarvitaanko paljon integrointeja taustajärjestelmiin vai hoituuko suuri osa palveluprosesseista automaatiolla ja low-code-järjestelmän omalla ammattilaisen käyttöliittymällä?
• Minkälaista tietoturvaa palvelut ja sovellukset vaativat?

Low-code teknologiat voi karkeasti jakaa kahteen pääluokkaan:

1. Applikaatio-keskeinen. Ensin suunnitellaan käyttöliittymä, joka liittyy tai ei liity prosessiin. Yksinkertaisin versio näistä on lomakkeenteko-ohjelmat, joissa ei ole minkäänlaista prosessitukea. Käytännössä applikaation taustajärjestelmä on useimmiten olemassa oleva (useimmiten ei low-code) järjestelmä. Applikaatio-keskeisissä low-code-alustoissa on kattavat rajapintaratkaisut, joilla käyttöliitymä sitten kytketään taustajärjestelmiin.

2. Prosessi-keskeinen. Prosessi-keskeisissä alustoissa projekti alkaa prosessin suunnittelulla. Prosessi voi perustua standardiin, kuten BPMN2.0, tai olla toimittajan itse kehittämä, kuten Pega Systemsin metodologia. Jos prosessi vaatii käyttöliittymän, se tehdään siihen erikseen.

Suurin osa ratkaisuista on jossain näiden kahden ääripään välimaastossa. Tämä tarkoittaa sitä, että sovelluskeskeisellä alustalla voi toteuttaa prosesseja, mutta prosessikehitykseen vaadittava aika ja kustannus on huomattava. Vastaavasti prosessikeskeisiin järjestelmiin voi liittää hyvinkin hienoja käyttöliittymiä, mutta ne pitää kehittää erikseen.

Mistä sitten tietää, kummasta on kysymys? Nimestä voi päätellä jotain mutta verkkosivuista ja ratkaisuista sitäkin enemmän.

Jos yrityksen ensimmäinen viesti liittyy sovelluksiin, niin silloin on kyseessä sovelluskeskeinen alustatoimittaja. Tämä voi olla harhaanjohtavaa, koska useisiin sovelluskeskeisiin ratkaisuihin on myöhemmin lisätty prosessiominaisuuksia ja tämän takia tiedonhallinta voi osittain ontua näissä ratkaisuissa pitkällä aikavälillä. Mutta on hyvä ymmärtää, että näissä ratkaisuissa prosessin kulku, järjestelmän älykkyys ja työn tehostaminen eivät ole keskeisiä tavoitteita. Päätavoite on hieno ja koukuttava loppukäyttäjäkokemus.

Jos low-code alustatoimittaja puhuu työn tehostamisesta ja automaattisesta päätöksenteosta niin silloin ratkaisu on enemmän prosessikeskeinen. Näissä ratkaisuissa tärkeintä on prosessin kulku, tehtävien reititys, palvelutasot, käyttäjien roolit, herätteet ja automaattinen päätöksenteko. Näiden ratkaisujen keskeinen ominaisuus on prosessinohjaajan, jonkinlainen prosessin täytääntöönpanijan, ammattilaisen, käyttöliittymä.

Prosessi käynnistyy näissä ratkaisuissa lomakkeilla (ei palvelukohtaisella sovelluksella). Lomakkeet sinällään voivat olla hyvinkin hienoja, kauniita ja brändinmukaisia mutta niiden erot ovat väreissä, fonteissa ja ulkoasussa, ei käyttökokemuksessa.

Sekä sovellus- että prosessikeskeisissä low-code-alustoissa on myös mahdollista toteuttaa järjestelmän sisäisiä tietokantoja tai tauluja. Tämä tekee järjestelmästä helposti hallittavamman ja turvallisemman. Ja mikä tärkeintä, huomattavasti edullisemman asentaa ja ylläpitää, koska ulkoisten integraatioiden määrä vähenee olennaisesti.

Low-code-alustojen viisi kategoriaa

Toinen lähestymistapa päätöksenteossa on low-code-alustatoimittajien kategorisointi ja sen päättäminen, mikä kategoria sopii parhaiten omiin tarpeisiin. Kuten aina, ja minkä jo edellä mainitsin, yksikään toimittaja ei suoraan kuulu näihin luokkiin. Mutta tässä on yksi päätöksentekomalli lisää, joka voi auttaa päätöksentekijöitä.

1. Lomakkeenteko-ohjelmat
   Low-code ratkaisut lähtivät liikkeelle puhtaista lomakkeenteko-ohjelmista. Nämä ratkaisut ovat vanhoja ja ensimmäiset tulivat markkinoille jo 80-luvulla. Näitä ratkaisuja ovat Adobe Web Forms, Google Forms ja tiettyihin toimialoihin, keskittyvät lomakealustat kuten Abou (kansalaiseen sähköiseen asiointi).
2. Applikaatio-keskeiset alustat
   Nämä alustat ovat lähimpänä perinteistä sovelluskehittämistä, jossa sovellus rakennetaan pidemmälle jalostetuista komponenteista. Verrattavissa legoilla rakentamiseen, jossa mielikuvitus ja taito yhdistellä eri palikoita mahdollistavat hyvin monenlaisten ratkaisujen tekemisen. Tähän kuuluu ratkaisut kuten, OutSystems, Mendix ja Microsoft PowerApps (joka kuuluu myös kategoriaan 4).
3. Prosessi-keskeiset alustat
   Jos tarve on toteuttaa monimutkaisia ja pitkiä prosesseja, joissa on useita vaiheita, ja jotka linkittyvät useisiin taustajärjestelmiin, on tämä ehdottomasti paras vaihtoehto. Näiden järjestelmien suurin haaste on pitkä järjestelmän omaksumisvaihe ja järjestelmän raskaus ja kalleus. Markkinajohtajia tässä kategoriassa ovat Pega Systems ja Appian.
4. Ekosysteemin sisäinen low-code-toiminnallisuus
   Ohjelmistoekosysteemien toimittajat, kuten Salesforce, Microsoft ja Oracle ovat ymmärtäneet low-code toiminnallisuuden tärkeyden ja sisällyttäneet omiin työkalupakkeihinsa tämän ratkaisun. Salesforce ei varsinaisesti ole antanut toiminnallisuudelle nimeä, mutta on mielenkiintoisesti jakanut tämän kahtia: sovelluksen kehittäminen ja low-code (prosessiohjaus). Microsoft PowerApps tuli jo aikaisemmin mainittua ja Oracle Apex on siitä mielenkiintoinen, että se on ilmainen. Mutta kun Oracle low-code ratkaisuun lähtee perehtymään, huomaa, että se käy lähinnä ja lähes ainoastaan Oracle tietokanta- ja ohjelmistoekosysteemiin. Näissä ratkaisuissa on tärkeä tutkia sovellus vs. prosessikeskeisyys, ja varmistaa siten sopivuus omiin tarpeisiin. Mutta näissä ratkaisuissa enemmän tai vähemmän lukittaudutaan ekosysteemitoimittajaan ja sen tietokantoihin ja ohjelmistoihin.
5. Toimialakohtaiset kokonaisvaltaiset low-code-alustat
   Viimeisenä parina vuotena on tullut kokonaisvaltaisia toimialakohtaisia ratkaisuja, joissa on lomakkeentekokone, prosessinkuvaustyökalut ja ammattilaisen käyttöliittymä samassa ratkaisussa. Ne ovat niin uusia, että niistä ei vielä löydy paljon kokemusta mutta alustavat tulokset ovat lupaavia. Koska ne on kehitetty vain tietylle toimialalle, on niistä voitu karsia kaikki epäolennainen pois: niillä kehittäminen on vielä kevyempää ja nopeampaa kuin geneerisillä low-code alustoilla. Esimerkiksi kansalaisen sähköisessä asioinnissa on Ruotsalainen low-code alustatoimittaja Selfpoint saanut nopeasti merkittäviä asiakkuuksia. Suurilla toimijoilla, kuten esimerkiksi Pega Systemsillä on finanssisektorille ja julkishallinnolle räätälöityjä ratkaisuja. Mutta koska ovat ne ovat vain olemassa olevan ratkaisun laajennuksia, niin tätä ei voi kutsua puhtaaksi kokonaisvaltaiseksi toimialaratkaisuksi.

Kaikki lähtee toimialasta, strategiasta ja toimintamallista. Ja tässä en tarkoita sähköisten palveluiden ja prosessien kehittämismallia vaan organisaation tapaa toimia ja toteuttaa palvelu. Yksityisen puolen terveyspalveluissa, esimerkiksi Mehiläisen digiklinikassa, on onnistuttu palvelukehityksessä, koska ensin on päätetty strategiasta johdettu toimintamalli ja työntekijöiden roolit, ja vasta sen jälkeen lähdetty miettimään teknologiaa.

Tee perusteellinen taustatyö, ja päätös tarpeisiin ja toimintamalliin sopivasta low-code-alustatoimittajasta syntyy kuin itsestään.