Ensinnäkin se on termihirviö, mutta toisekseen sillä on ensiarvoinen rooli siinä, että sovelluskehitys käynnistyy sujuvasti, toteutuu sovitussa ajassa ja budjetissa sekä vastaa vieläpä tarkoitustaan. Toisin sanottuna liiketoiminnan vaatimusmäärittelyn merkitys jatkuu projektin alkumetreiltä pitkälle sovelluksen elinkaarta.

Systems Gardenin sovelluskehittäjät Sanna ja Jouni kertovat, että liiketoiminnan vaatimusten määrittely tarkoittaa sitä, minkälaisia asioita asiakkaan liiketoiminnassa tulee ottaa huomioon sovellusta kehitettäessä ja mitä sovelluksen tulee tehdä palvellakseen liiketoimintaa. Määrittely käynnistyy näitä asioita koskevilla peruskysymyksillä. 

– Prosessi alkaa siitä, että laaditaan lyhyet kuvaukset asiakkaan liiketoimintaympäristöstä ja sovelluksen tarkoituksesta ja kirjataan projektin tavoitteet. Alussa selvitetään, mitä asiakas haluaa heille rakennettavan ja miksi, Jouni muotoilee. 

– Jos alussa ei ole selvää, mitä projektin aikana tehdään, on vaikea varmistua siitä, että lopputulos on sitä mitä piti, Sanna lisää.

Sovelluskehityksessä puhuttava samaa kieltä

Systems Gardenin asiantuntijat kertovat, että asiakkaille itselleen sovellukselta toivottavat ominaisuudet voivat olla niin itsestään selviä, että kaikkea ei välttämättä huomata kertoa. Toisaalta asiakkaat eivät aina itsekään tarkkaan tiedä, mitä sovellukselta tarvitsevat. Koska molemmissa tapauksissa vaatimukset tulisi kuitenkin onnistua kommunikoimaan sovelluksen toteuttajille, oikea terminologia nousee suureen rooliin.

– Jos ei ymmärretä sitä, mistä sovellus koostuu, tai luullaan puhuttavan samasta asiasta, vaikka näin ei todellisuudessa olekaan, syntyy projektin aikana helposti väärinkäsityksiä. Siksi yhteisen kielen löytäminen on todella tärkeää, Sanna teroittaa.

Määrittelyn edetessä tarkennetaan sitä, miksi sovellus on tarpeellinen organisaatiolle ja minkälaisiin haasteisiin sen tulisi vastata. Lisäksi käydään läpi sitä, mihin osaan asiakkaan prosessia ja mihin muihin asiakkaan käytössä oleviin ohjelmistoihin sovelluksen tulisi liittyä.

– Esimerkkinä toimii vaikkapa sellainen liiketoiminta, jossa tallentuu paljon puheluita, sähköposteja, lomakkeita tai kohdekäyntejä tietokantaan, jossa niitä täytyisi päästä tilastoimaan, raportoimaan tai ihan vain tarkastelemaan, Jouni listaa.

Liiketoiminnan vaatimusmäärittely varmistaa vastaavuuden käyttäjän tarpeisiin

Jouni kertoo, että sovelluskehityksessä puhutaan toiminnallisista ja ei-toiminnallisista vaatimuksista, joista ensin mainitut ovat kuvauksia siitä, miten sovellus toimii ja mitä se tekee.

– Toiminnalliset vaatimukset määritellään usein erikseen, mutta yksi esimerkki on vaikkapa eri käyttäjäryhmien määrittely, eli minkälaisilla rooleilla sovellusta käytetään. Raportointisovelluksessa kyseessä on asiakkaan asiakas. Oman organisaation sisällä se voi vaihdella esimerkiksi pelkästä lukuoikeudesta jonkin rajatun tiedon muokkaamiseen, toimitusjohtajan pääsyyn tai ylläpito-oikeuksiin.

Ei-toiminnalliset vaatimukset puolestaan tarkoittavat Jounin mukaan sellaisia rajoituksia ja laatuominaisuuksia, joilla varmistetaan, että järjestelmä vastaa käyttäjän tarpeita. Siksi ne liitetään usein vahvemmin juuri liiketoimintavaatimusten määrittelyyn.

Esimerkkejä ei-toiminnallisista vaatimuksista:

• Potentiaalinen käyttäjien määrä. Kuinka sovellus skaalautuu, mikäli määrä kasvaa vaikkapa 10 000 käyttäjästä 100 000 käyttäjään?
• Käsiteltävän datamassan suuruus ja kyky suoriutua siitä.
• Kriittisyys liiketoiminnan kannalta. Tuleeko sovelluksen toimia yhtä nopeasti kaikille? Pysäyttääkö sen kaatuminen liiketoiminnan?
• Lokalisointi. Tukeeko sovellus esimerkiksi eri kieliä eri maissa?
• Infrastruktuuri. Tuleeko sovelluksen toimia yhteen jonkin muun järjestelmän kanssa?
• Tietoturva, datan yksityisyys, varmuuskopiointi

Myös nämä kannattaa hoksata

Sanna ja Jouni huomauttavat, että liiketoiminnan vaatimusmäärittelyssä kannattaa toteuttaa swot- tai riskianalyysi, jotta se mikä projektissa voi mennä pieleen on mahdollisimman hyvin huomioitu etukäteen.  
Samalla on hyvä määritellä se, minkälaisessa aikataulussa projekti tulisi pystyä viemään läpi ja minkä suuruisessa budjetissa. 

– Sovelluskehitys on enemmän taidetta kuin tiedettä. Vaikka kyseessä olisi kuinka pieni sovellus tahansa, jos ei ole määritelty sitä, milloin se on valmis, kehitystä voidaan jatkaa loputtomiin, Jouni toteaa. 

– Määrittelyn ansiosta saattaa myös toisinaan käydä ilmi, ettei sovelluksen kehittäminen ehkä olekaan kannattavaa. Sekä asiakkaalle että meille on hyvä asia, että tämä huomataan ajoissa. 

Sanna mainitsee, että liiketoiminnan vaatimusmäärittelyn yhteydessä voi toisinaan ilmetä muutakin huomionarvoista. 

– Jos määrittelyssä tunnistetaan esimerkiksi jokin tietty kehitystarve, joka ei kuitenkaan tule kuulumaan kyseiseen sovellusprojektiin, se on hyvä kirjata ylös. Näin sen pariin muistaa paremmin palata ja liikkeelle lähtö on sujuvampaa.   

Lue lisää ohjelmistosuunnittelun ja -kehityksen palveluistamme!
Ratkaisut

Kiinnostuitko meistä? Tutustu myös muihin palveluihimme ja ota yhteyttä!
Ratkaisut

Ohjelmistofirmojen markkinointipuheissa korostuu usein se, miten sujuvasti projektit vedetään maaliin milloin mitäkin mallia käyttäen ja toinen toistaan kauniimpien teknologioiden avulla. Softan tekeminen on kuitenkin käyttäjäläheistä ja niin koodarit kuin asiakkaatkin vain ihmisiä. Kaikki alalla toimivat tietävät, että räätälisoftan tekeminen ei koskaan ole ihan helppo nakki. 

Erehtyminen on inhimillistä ja niinpä myös me Systems Gardenilla olemme toisinaan menneet mokien kautta maaliin. Tärkeintä on kuitenkin ottaa opikseen ja kääntää virheet voimavaraksi. Vankan kokemuksemme turvin (ja ehkä myös mokista oppineena) tunnistamme ohjelmistojen arvon liiketoiminnalle ja ymmärrämme niiden käyttäjiä.  

Tähän artikkeliin olemme listanneet ohjelmistotarpeen määrittelyn 10 yleistä sudenkuoppaa sekä kokemuspohjaiset vinkkimme niiden välttämiseksi. Virheitä voi toki tehdä myös teknologiatasolla, mutta kokemuksemme mukaan kaikkein vaikeimmat haasteet syntyvät jo suunnittelussa, määrittelyssä ja liiketoimintatarpeiden ymmärryksessä. 

1. Sisäinen työkalu vai asiakasohjelmisto?

Etenkin Suomen kokoisilla markkinoilla on turhaa yksinkertaistamista, että softa kannattaisi tehdä aina tietyllä tavalla. Karkeasti jaotellen on olemassa sovelluksia, jotka näkyvät asiakkaan suuntaan ja tavoittelevat kilpailuetua tai asiakaspalvelun parantamista, ja toisaalta softia voidaan käyttää sisäisiin prosesseihin ja toiminnan tehostamiseen oman väen kesken. Organisaatioilla voi siis olla paljon tarvetta erilaisen tiedon keräämiselle, järjestämiselle ja jakamiselle. Jos kaikkea lähdetään toteuttamaan samalla sabluunalla, saatetaan toisinaan ampua norsupyssyllä kärpästä.

Eräässä tapauksessa rakennusalan palveluyritykselle oltiin toteuttamassa asiakasportaalia, jolla luotaisiin uusi palvelukanava sähköiseen asioinnin kautta. Kun siirryttiin toteutukseen, kävikin ilmi, etteivät asiakkaan tuotantoprosessit tai toimintamallit tukeneet tällaista ajatusta lainkaan. Laskentamalliin ja asiakaspalveluun ei ollut saatavilla riittävää dataa, koska toiminta ja suunnittelumallit perustuivatkin ihmisten osaamiseen. Koska syötettä ei ollut, ratkaisu oli jäämässä pelkäksi markkinointikanavaksi. Lopputuloksena toteutettiinkin sisäiseen käyttöön toiminnanohjausjärjestelmä, johon kului lopulta koko budjetti, mutta jolla sentään saatiin tuettua sisäisiä prosesseja. Asiakaspalvelukanava jäi odottamaan aikaa parempaa.

Ohjelmistotarpeen määrittelemiseksi tulee ensin ymmärtää liiketoiminnan tarpeet ja se, mitä, kenelle ja miksi ollaan rakentamassa.

2. Ohjelmiston alkuperäinen käyttötarkoitus unohtuu

Asiakas on oman tekemisensä asiantuntija ja tärkeimmässä roolissa siinä määrittelyssä, jonka turvin saadaan aikaiseksi hänen tarvitsemansa ratkaisut. Edellisen kohdan esimerkkiprojektissa oli kuitenkin ongelmana myös päätavoitteen hämärtyminen. Projektiryhmän toiminta ohjautui siihen, mikä milloinkin muodosti ongelman, eikä näin ollen aina välttämättä tehty sitä, mikä olisi ollut oikeasti tärkeää.

Ohjelmistotarpeen määrittelyssä tulisi aina joko kirjata tavoitteet tai vaihtoehtoisesti hyväksyä se, että projektia lähdetään toteuttamaan pala kerrallaan ketterästi ohjautuen. Joskus pitää vain tehdä tietoisesti se päätös, että jostain luovutaan hetkellisesti, jotta jotain tärkeämpää saadaan toteutettua. On helppo sortua määrittelemään liikaa etukäteen sitä, minkälainen sovelluksen käyttöliittymän halutaan olevan, kun järkevämpää olisi keskittyä siihen, millainen sen pitäisi liiketoimintaa palvellakseen olla.

Kannustamme myös ehdottomasti ohjausryhmän käyttöön. Ohjelmistoprojekteissa tulee väistämättä eteen hankalia priorisointipäätöksiä, jolloin projektiryhmän ohella on hyvä olla toinenkin foorumi. Sen vain pitää olla avoin ja valmis puhumaan vaikeista asioista. Ohjausryhmään viedään usein lähinnä budjettiin tai aikatauluun liittyviä asioita, mutta sinne pitäisi viedä myös esimerkiksi sellaisia haasteita, että teknologia ei taivu haluttuun ratkaisuun tai liiketoiminnan muoto ei tue sovellukselta kaivattua toimintaa. On kuitenkin tärkeää muistaa, että ohjelmisto tulisi laatia tukemaan prosessia sen sijaan, että prosessia muutettaisiin ohjelmiston ehdoilla.

3. Ohjelmiston käyttäjiä ei tunneta tai ainakaan ymmärretä

Silloin tällöin olemme saattaneet ryhtyä luomaan hienoa softaa intuitiivisella käyttöliittymällä, kunnes on käynyt ilmi, että sovellusta tulee käyttämään yksi ihminen. Tarve on voinut koskea esimerkiksi sihteerin työhön kuuluvaa datan keräämistä tai sen esittämistä tietyssä muodossa. Olemmekin joskus todenneet jotkin softat, joista tulisi hyötymään 1-2 ihmistä niin kalliiksi, että niitä ei yksinkertaisesti kannata tehdä. Me olemme tyytyväisiä, vaikka määrittely jäisi tähän, sillä ei ole mitään ikävämpää kuin toteuttaa hienoa ja kallista softaa, joka ei hyödytä asiakasta samassa suhteessa. 

Nykyisin on vaikeaa keksiä asiaa, johon ei löytyisi erikoissoftaa. Siksi myös valmisohjelmistot kannattaa lähes aina kartoittaa. Vastaamme on tullut paljon tapauksia, joissa kaivatut työkalut saa jo ostettua muutamalla dollarilla. Yhdelle työntekijälle onkin yleensä halvempaa hankkia olemassa olevan ohjelmiston lisenssi kuin teettää kokonaan uusi ratkaisu. Sopivan sovelluksen löytyminen voi myös herättää siihen, tarvitaanko ratkaisulta ihan oikeasti kaikkia haaveiltuja nyansseja. 

Osana ohjelmistotarpeen määrittelyä me Systems Gardenilla laadimme ns. käyttäjätarinat, jotka auttavat ymmärtämään käyttäjien rooleja. Käyttäjäpersoonien määrittelyn ohella kannattaa kuitenkin huomioida myös sellaiset tahot, jotka eivät välttämättä käytä sovellusta ollenkaan, mutta hyötyvät sen keräämästä datasta.

4. Ohjelmiston toimintaa ei piirretä auki

Kaikki softat ovat viime kädessä tietoa kerääviä lomakkeita ja niitä esittäviä listauksia ja näkymiä. Tiedon keruu ja esitys voidaan kuitenkin toteuttaa hyvin monessa eri muodossa ja monella erilaisella mekanismilla. Asiakkaalla on usein niin selkeä visio siitä, mitä tavoitellaan, että kaikkea ei tule mieleen ilmaista. Jos suunnittelu on toisaalta vain sanallista, jää väärinymmärryksille edelleen paljon tilaa ja seurauksena voi olla vaikeita tilanteita. Olettamus on kaikkien emämunausten äiti.

Eräässä esimerkkitapauksessa asiakasyrityksen tavoitteena oli, että heidän asentajansa löytävät oikeat keikat. Vasta piirtämällä ajatus kuvaksi oivallettiin, että asentajat ilmestyisivät kohteisiinsa milloin sattuu, ja järjestelmä saattaisi laittaa keikat uusiksi kesken päivää, kun asentaja on jo puolimatkassa jonnekin muualle. Usein onkin helpompi todeta, mitä sovellukselta ei haluta. Kun se piirretään kuvaksi, on helpompi havaita se, mikä ei toimi tai mikä vielä puuttuu.

On myös tärkeää huomioida se, toimiiko prosessi kaikissa tapauksissa sovellukselta vaadittavalla tavalla. Vaikka poikkeustapauksia olisi vain 2 %, softan toiminta tulee tökkäämään niihin. Ketterä ohjelmistokehitys mielletään usein siten, että mitään ei tarvitse määritellä kovin tarkasti, vaikka todellisuudessa softan taustalla voi olla kokonainen tiimi tekemässä koodiin muutoksia, jotka voivat olla hyvinkin työläitä. Rautalankamallin muuttaminen on aina halvempaa kuin toimivan softan uudelleenkoodaus.

Kuvallinen havainnollistaminen on kuitenkin tärkeää pitää rautalankamallin tasolla menemättä ulkoasullisiin seikkoihin. Heti, kun mukaan tulee värejä tai grafiikkaa, keskittyminen ohjautuu vääriin asioihin ja niitä paalutetaan turhan varhaisessa vaiheessa. Rautalanka on koodiin verrattuna halpaa, mutta silläkin kyetään demonstroimaan paljon.

5. Käyttäjien tarpeita tai motivaatioita ei huomioida

Muutosvastarintaa softan käyttöönottoa kohtaan esiintyy sitä herkemmin, mitä myöhäisemmässä vaiheessa tulevat käyttäjät huomioidaan – puhumattakaan siitä, että heitä ei huomioida ollenkaan. Klassisessa esimerkissä (ja aivan liian usein) toimistotyöntekijä tai johtaja suunnittelee jotain kentällä toimivalle asentajalle, jota lopputulos ei ensinkään palvele.

Toisinaan ennakkoluulot liittyvät pelkoon siitä, että softa vähentää työvoimatarvetta, vaikka uuden ohjelmiston tarkoitus on yleensä vain turhan työn vähentäminen ja työntekijöiden vapauttaminen siihen, missä he ovat hyviä ja tuottavat eniten arvoa. Ohjelmisto ei tee yksin mitään, vaan esimerkiksi putkimies rakentaa LVIS-järjestelmiä ja saa ohjelmiston avulla tiedon siitä, missä on seuraava keikka. Avoin kommunikointi sovelluksen tarkoituksesta onkin avainroolissa.

Ohjelmisto on usein välttämätöntä pilotoida ensin pienellä ryhmällä, mutta toisaalta sen todellinen hyöty paljastuu tyypillisesti vasta, kun yli 80 % kirjauksista saadaan järjestelmään. Kun töitä sitten tehdään vanhan järjestelmän kanssa päällekkäin, käyttäjässä herää helposti tunne uuden kyseenalaisesta tarpeesta. Niinpä hyväkin sovellus on joskus kaatunut siihen, että sitä ei vain ole saatu käyttöön.

Olennaista on tunnistaa kriittinen massa, jonka avulla sovellus myy itse itsensä. Kun hyödyllinen ratkaisu nähdään toisten käytössä, se usein halutaan helpottamaan myös omaa työtä. Tarkoituksenmukaisin sovellus ja sujuvin käyttöönotto saavutetaan joka tapauksessa silloin, kun käyttäjiä osallistetaan ja sitoutetaan prosessiin mahdollisimman varhaisessa vaiheessa. Ohjelmiston arvo ei muodostu sen valmistuessa, vaan vasta silloin kun se on otettu riittävän laajasti käyttöön.

6. Samoja tietoja kirjataan useita kertoja

Mikäli ohjelmiston liittymätarpeita ei huomioida ajoissa, saattaa niitä ilmetä runsaastikin vasta käyttöönottovaiheessa. Moni ohjelmistoprojekti pysähtyykin aikataulullisesti tällaiseen pullonkaulaan juuri loppuvaiheessaan. On olemassa tapauksia, joissa liittymävaihe on kestänyt peräti kolme kertaa kauemmin, ja vastaavasti maksanut kolme kertaa enemmän kuin itse softan luominen. On hyvä muistaa, että jos dataan sisältyy esimerkiksi asiakkaiden nimien kaltaista tietoa, jonkun tulee myös ylläpitää sitä.

Aina tulisikin mieluummin pyrkiä siihen, että tieto kirjataan vain kerran, minkä jälkeen se soljuu järjestelmien välillä. Sitä varten määrittelyssä tulisi yhtä aikaa kyetä hahmottamaan kokonaisuus, mutta mennä myös siinä määrin yksityiskohtiin, että ohjelmiston paikka prosessissa sekä sen vaatimat liittymät tunnetaan. Toisin sanottuna: mikä on se paikka, jossa tietoa ylläpidetään, ja missä muualla sen pitäisi olla käytettävissä. Tätä voidaan havainnollistaa prosessikaaviolla ja automatisoida integraatioilla.

7. Testailun ja testaamisen eroa ei ymmärretä

Testailu on sitä, että sovellusta vain klikkaillaan sieltä täältä ja sen toimintoja hieman kokeillaan. Kun sovellus otetaan sen jälkeen suoraan käyttöön, voidaankin joutua toteamaan, että se ei toimi ollenkaan todellisen prosessin mukaisesti.   

Sen sijaan testaaminen on suunnitelmallista toimintaa, jolla varmistetaan, että sovellus tekee sen, mitä siltä vaaditaan. Tärkeää on myös sen huomioiminen, mitä sovellus ei saa tehdä, ja testata, mitä mahdollisissa virhetilanteissa tapahtuu. Testausvaiheessa olisi hyvä olla mukana niin toteuttajan kuin asiakkaan taholta sellaisia henkilöitä, jotka eivät ole osallistuneet ohjelmiston kehitykseen. 

Klassinen moka testausvaiheessa on, että järjestelmään ei syötetä todellisia tietoja. On eri asia verifioida, meneekö ”Testikeikka” läpi ”Testiasentajalle”, kuin oikeasti simuloida koko työnkulku toimistosta kentälle ja takaisin oikeiden ihmisten kautta.

8. Ohjelmistosta laaditaan turha käyttöohje ja oletetaan sen riittävän

Ohjelmistojen hankintaan liittyy usein eräänlainen opittu tarve seikkaperäiselle käyttöohjeelle. Käyttöohjettakin täytyy kuitenkin ylläpitää, ja se täytyy päivittää aina kun asioihin tehdään muutoksia. Mitä laajempi käyttöohje on, sitä enemmän ylläpidettävää. Mikään ei myöskään harmita niin paljon kuin se, kun etsii käyttöohjeesta apua, mutta tieto onkin virheellistä tai vanhentunutta. 

Ohjelmistomäärittelyssä on järkevää pohtia käytäntöjen ja vaatimusten perimmäistä tarkoitusta ja suoraan sanoen sitä, lukeeko käyttöohjetta viime kädessä kukaan? Mikäli kyseessä on sisäinen softa, jota käyttää rajallinen määrä ihmisiä, pärjättäisiinkö suppeammalla käyttöohjeella tai saataisiinko se vaikka intranetiin? Voisiko kenttien yhteyteen lisätä lyhyen infotekstin sen sijaan että tuotetaan 20 sivua ruutukaappauksia Word-dokumenttiin? 

Kannattaa kuitenkin huomioida, että B2B-sovellusta ei usein edes voi toteuttaa niin yksinkertaseksi, etteikö sen käyttäminen vaatisi koulutusta. Kuluttajasoftan puolestaan tulisi yleensä olla kenen tahansa käytettävissä enintään lyhyellä opastuksella. Molempia yhdistää se, että mitä paremmin jo alussa määritellään käyttöliittymän kanssa pärjäämiseksi vaadittavat tiedot, sitä vähemmän kaikilla on töitä loppupäässä. Panostukset käytettävyyteen näkyvätkin yleensä suorina säästöinä koulutusbudjetissa. Tärkeämpää on, että käyttäjätuki on kunnossa ja palautetta kerätään ja siitä opitaan.

9. Ohjelmisto suunnitellaan valmistuvaksi kerralla.

Ohjelmistojen elinkaareksi mainitaan usein keskimäärin seitsemän vuotta, mutta sinäkin aikana voi syntyä runsaasti uusiin asetuksiin ja tietoturvaseikkoihin liittyviä muutostarpeita. Jos lähdetään teettämään omaa customsoftaa, on syytä varautua siihen, että muutostarpeita tulee matkan varrella paljon. On ikävää joutua toteamaan, että softa ei ole tietoturvallinen koska joku alustakomponentti on vanhentunut, tai huomata, että värkki ei enää toimikaan kuin yli kolme vuotta vanhoilla kännyköillä.

Järkevintä on pyrkiä hahmottamaan kokonaisuus, luoda siitä road map, toteuttaa sitä pala kerrallaan ja valmistautua tekemään muutoksia myös pilotoinnin jälkeen. Sen sijaan, että ajatellaan mitä kaikkea voitaisiin tehdä, on fiksumpaa keskittyä siihen, mitä täytyy tehdä. Silloin ei myöskään hämmennetä käyttäjiä turhilla toiminnallisuuksilla. Kun aluksi luodaan vain ehdottomat toiminnallisuudet, saatetaankin huomata, että enempää ei edes tarvita.

10. Ohjelmistoa ei suunnitella skaalautuvaksi

Toisinaan käy niin, että ohjelmistoa on käytetty vasta ensimmäiset kolme kuukautta, kun dataa on karttunut jo niin paljon, että sitä ei kyetä hallitsemaan. Vastaavasti softa on voinut toimia hyvin vuodenvaihteen katkoon saakka, mutta ongelmia ilmenee, kun pitäisi tuottaa väliraportti.
Vanhojen sovellusten modernisoinnissa saadaan usein etumatkaa, sillä niiden parissa käytettävissä on heti suuri määrä dataa sen testaamiseen, mitkä elementit eivät mahdollisesti toimikaan. Mikäli kyseessä on uusi sovellus, tulee yrittää mahdollisimman hyvin arvioida, missä määrin ja millä tahdilla datan määrä kasvaa. Toimivuutta voidaan testata myös rakentamalla tekstieditorien käyttämän lorem ipsumin tavoin ns. mokkidataa.

Lue lisää vanhojen ohjelmistojen modernisoinnista

Ongelmia voidaan lisäksi ehkäistä sillä, että valitaan toimintatapoja, joissa ei synny toimittajalukkoja tai tarvita suojattuja komponentteja.

Koska yllätyksiä voi ilmaantua ja asioihin joutua palaamaan, suosittelemme lämpimästi hyödyntämään tarjontaamme kuuluvaa tukisopimuspalvelua.

Lue lisää

Kiinnostuitko meistä? Tutustu palveluihimme ja ota yhteyttä!

Ratkaisut

Ohjelmisto-, järjestelmä-, sovellus- tai digitalisaatioprojekti. Sitä emme tiedä, mikä näistä termeistä määrittelee juuri nyt yrityksellesi tai organisaatiollesi ajankohtaisen ohjelmisto- ja sovelluskehitykseen liittyvän asian osuvimmin. Mutta tästä olemme aivan 100-prosenttisen varmoja: suoraan ei kannata hypätä tekemään. Nimittäin kiitellyn lopputuloksen takana on hyvin määritelty projekti ja ohjelmistosuunnittelu.

Raskassoutuisia, ajastaan jälkeen jääneitä tai epäloogisia sovelluksia sekä ohjelmistoja on jo ihan katugallupinkin perusteella aivan riittävästi. Loppukäyttäjä onkin näissä usein unohdettu tyystin. Kun bittejä aletaan raaputtamaan huolellisemmin, toimimattomuuden perussyy saattaa löytyä mutkien oikaisusta suunnittelussa.

Suunnittelu kannattaa aina näistä syistä:

1. Kiteyttää sovelluksen idean toteutuskelpoiseksi suunnitelmaksi
2. Luo yhteisymmärryksen siitä, mitä olemme rakentamassa – kenelle ja miksi
3. Tuottaa määritelmän: mitä sovellus tekee ja minkä kokoinen se on
4. Mahdollistaa idean testaamisen ennen varsinaiseen kehitysprojektiin ryhtymistä

Ohjelmistosuunnittelu on asia, jolle on aina paikkansa jokaisessa hyvin onnistuneessa lopputuotteessa. Ota tueksi vahvan suunnitteluosaamisen omaava asiantuntijayritys.

Älä tingi suunnittelusta

Teknologioiden, alustaratkaisujen ja pilvipalveluiden kehittymisen myötä tarvitaan kasvavissa määrin lisää ohjelmistoja ja sovelluksia, jotka sujuvoittavat yritysten arkea näyttölaiteriippumattomasti.

Resursoi suunnitteluvaiheeseen heti alussa! Eli pyydä mukaan ammattitaitoinen – lukuisia ohjelmisto- ja sovelluskehitysprojekteja onnistuneesti läpivienyt – asiantuntijayritys. Voit helposti todeta jälkikäteen, että suunnitteluun satsaaminen kannatti. Tälläkin kertaa.

Oikeastaan sellaista onnistunutta ohjelmisto- ja sovelluskehitysprojektia ei olekaan, missä ohjelmistosuunnittelusta olisi tingitty. Mutta niissä ”ei niin maaliin menneissä” -sovellus- ja ohjelmistoprojekteissa yhdistävänä tekijänä on se, että suunnitteluvaiheen ohi on sivakoitu vauhdilla: lähdetty suoraan tekemään. Mutta viimeisen mutkan jälkeen ei olekaan avautunut luistava loppusuora, vaan on tultu yllättävään umpikujaan. Aika ja eurot ovat sulaneet. Mitä kerrottavaa tällaisesta projektista jäi eteenpäin?

Vastaavasti sovelluksen/ohjelmiston hyvin toimiva ja johdonmukainen käyttöliittymä, mukava käyttökokemus ja loppukäyttäjän käyttötarpeiden ymmärrys kertoo sen, että ”suunnittelupöydän äärelle” (lähi- tai etätyössä) on kerääntynyt projektityöryhmä, joka on viettänyt siinä tarpeeksi aikaa: uskaltanut kysyä, keskustella, kyseenalaistaa rakentavasti ja pohtia realistisesti. Ohjelmistosuunnittelu ja helppo vuorovaikutus asiansa tuntevan yhteistyötahon kanssa on avainroolissa.

Kun organisaatiosi teettää ohjelmiston tai sovelluksen, miettikää jo suunnitteluvaiheessa sen loppukäyttäjiä ja heidän tarpeitaan. Miksi ja mitä varten he tulevat sovellusta käyttämään?

Ohjelmistosuunnittelu osa hallittua menetelmää

Tiedä mitä saat! Maailma on täynnä ohjelmistoja ja dataa. Ja digitalisaation edetessä niiden määrä vain lisääntyy. Modernit alustat ja pilvipalvelut tarjoavat sovellusten ja ohjelmistojen kehittämiseen myös yllättäviin muutostilanteisiin (esimerkiksi mobiilisovellus jotakin käyttäjäryhmää varten) ainutlaatuisen mahdollisuuden. Ohjelmisto- ja/tai sovellusprojekti on silti hyvä toteuttaa ohjelmistosuunnittelu edellä.

Valitse yhteistyökumppaniksi sovellus- ja ohjelmistoprojektiin sellainen ohjelmistoyritys, jolla on hallussa ohjelmistosuunnittelu sekä toimivaksi todettu etenemismalli. Tässä alempana avaamme hieman ohjelmiston ja/tai sovelluksen kehittämistä Systems Gardenin tavalla.

”Kannamme sovittaessa kokonaisvastuun ohjelmisto- ja sovelluskehitysprojektistasi sen suunnittelusta aina käyttöönottoon ja ylläpitoon asti. Teemme ohjelmistokehitystä tarkasti alun kartoituksen ja määrittelysi perusteella joko kiinteähintaisena tai tavoitehinnalla pienistä ohjelmistokomponenteista kokonaisjärjestelmiin.”

Systems Gardenin kanssa projekti etenee tällä tavalla

• Suunnitteluprosessimme koostuu työpajoista – niiden määrä valitaan projektin ja työryhmän koon mukaan
• Määrittelee sen, miksi sovellus ylipäätään tehdään
• Listaa konkreettisesti kuka ja ketkä lopputuotetta käyttävät
• Tuottaa määrityksen, mitä sovellus itse asiassa tekee ja kuinka suuri se on
• Antaa esimakua miltä sovellus näyttää ja tuntuu
• Tarjoaa maistiaisen ennen varsinaista projektia

Ohjelmistosuunnittelu: ABC

Vaihe A
Ennen suunnittelua on kysyttävä miksi? Eli vaatimusmäärittely ja kokonaiskuva – miksi ohjelmisto/sovellusprojekti halutaan tehdä ja keitä varten kyseinen sovellus/ohjelmistoprojekti tehdään (= käyttäjäryhmät ja -persoonat).

Vaihe B
Selkeä luettelo ominaisuuksista ja käyttötapauksista – mitä sovellus tekee ja millaisia resursseja sen toteuttaminen vaatii.

Vaihe C
Rautalankamalli ja kuvaus ohjelmiston/sovelluksen rakenteesta. ”Miltä” sovellus tuntuu. Tarvittaessa myös graafinen/visuaalinen suunnitelma siitä, miltä ohjelmisto/sovellus näyttää.

Tämän jälkeen voidaan käydä läpi realistiset toteutusvaihtoehdot: valitaanko valmisratkaisu vai räätälöity ohjelmisto/sovelluskehitys. Kannattaako hankkeeseen yleensä ryhtyä ja kuinka paljon siihen vaaditaan resursseja ja rahaa.

Entä seuraavaksi?
Seuraavaksi käynnistetään varsinainen sovellus/ohjelmistokehitysvaihe. Kannamme sovittaessa kokonaisvastuun ohjelmisto- ja sovelluskehitysprojektistasi sen suunnittelusta aina käyttöönottoon ja ylläpitoon asti. Teemme ohjelmistokehitystä tarkasti alun kartoituksen ja määrittelysi perusteella joko kiinteähintaisena tai tavoitehinnalla pienistä ohjelmistokomponenteista kokonaisjärjestelmiin. 

Yleensä ohjelmisto- tai sovelluskehitysprojekti viedään Systems Gardenin tiimin avulla läpi keskimäärin 3–6 kuukaudessa (riippuen kokoluokasta). Ketterän kehityksen palvelumme ovat yleensä aika- tai työmääräveloitteisia.

Tutustu ratkaisuihimme

Tarjoamme valmiita työkaluja Microsoftin alustalla ja toteutamme ohjelmistoja sekä sovelluksia mittatilauksena. Olemme myös kehittäneet muun muassa oman Gate-tuoteperheen työturvallisuuden ja laadunvalvonnan tarpeisiin.

• Herätämme ideasi henkiin
• Suunnittelu, toteutus ja ylläpito
• Saumaton sovitus järjestelmiisi

• Gate HSEQ-sovellukset
• Työturvallisuus ja laadun hallinta
• Työluvat, pätevyydet, turvallisuushavainnot
• Tarkastukset, TR-mittaus ja auditoinnit

• Microsoft 365
• Intranet, Teams, Power BI…
• Dokumentinhallinta, sopimushallinta
• Koulutus ja konsultointi

Katso tarkemmin, mitä voisimme tarjota sinulle

Tutustu asiakkaidemme kokemuksiin palveluistamme

Onko ohjelmistosuunnittelu ajankohtainen aihe?

Ohjelmistosuunnittelu: ota yhteyttä asiantuntijaan. Saat palvelun ohjelmiston/sovelluksen suunnittelusta lähtien – aina sen toteutukseen saakka. Unohtamatta ylläpitoa ja kehitystä.

Tarvitsetko lisää ymmärrystä digitalisaatioprojektin laajuudesta, osa-alueista tai kustannuksista? Määrittely- ja suunnittelupalvelumme kautta tiedät mitä, kenelle ja miksi. Määrittelyprojektin tuloksena saat kattavan suunnitelman ja realistisen työmääräarvion ennen sitoutumista toteutusprojektiin.

Yhteydenottosi ei sido sinua mihinkään, eikä se myöskään maksa yrityksellesi mitään. Yhteystietojasi emme luonnollisestikaan käytä muihin tarkoituksiin tai jaa niitä eteenpäin. Ota yhteyttä asiantuntijaamme ja sovi helppo etätapaaminen. Tarkastellaan yrityksesi tai organisaatiosi tilannetta sekä tapaa toimia = pohditaan, millainen ohjelmisto tai sovellus voisi sopia teidän yrityksellenne.

Systems Gardenin asiantuntijasi ohjelmisto- ja sovelluskehitysprojekteissa

Suvi Ranttila
suvi.ranttila@systemsgarden.com
p. 040 657 5235

Pirkka Paronen
pirkka.paronen@systemsgarden.com
p. 050 592 1207

Yrityksemme LinkedInissä

”Ratkaisuihimme ja palveluihimme luottaa jo yli 100 yritystä ja yhteisöä – toimialasta riippumatta. Olemme yhdistäneet dataa ja ihmisiä järjestelmistä ja päätelaitteista riippumatta jo lähes 20 vuotta. Meillä on kokemusta vaativista ohjelmisto- ja sovelluskehitysprojekteista sekä kevyemmistä ratkaisuista.”

Myös nämä blogiartikkelit saattavat kiinnostaa

• Kuinka toteutat onnistuneesti SharePoint Online -intranetprojektin
• Sähköinen arkistointi, seminaarikuulumisia Pirkalta
• Valitse sopimushallinta, joka on tätä päivää

Tarvitsetko lisää ymmärrystä digitalisaatioprojektin laajuudesta, osa-alueista tai kustannuksista?

Digitalisaation kehittymisen myötä maailmassa on lukematon määrä erilaisia sovelluksia: muun muassa raskaasti toimivia, bugisia ja jatkuvasti kaatuilevia tai ratkaisevia tietoturva-aukkoja sisällään pitäviä. Onneksi on myös paljon niitä, jotka palvelevat käyttäjiään tarkoituksenmukaisesti. Sovelluskehitys täytyy määrittää raameiltaan järkeväksi.

Olipa alusta mikä vaan, ohjelmistoa ei kannata koskaan tehdä pelkän kehittämisen vuoksi tai siksi, että se on digitrendikästä – tai vaikkapa sillä perusteella, että ”koska kilpailijallakin on.” Sovelluskehityksen tulisi joka kerta palvella mahdollisimman hyvin loppukäyttäjiensä tarpeita. Tällöin ohjelmistokehitykselle on siten aito tarve ja sen myötä saavutetaan esimerkiksi resurssi- ja/tai kustannussäästöjä tai jouhevoitetaan yrityksen toiminta- ja/tai palveluprosesseja.

Ohjelmistokehitys on terminä monelle tuttu, mutta yhtä lailla myös näitä käytetään: softakehitys, ohjelmistoprojekti, mobiilisovellus, applikaatio, tietojärjestelmä ja digitaalinen disruptio. 

Onnistuneen sovelluksen filosofiaa

Usein toimivan sovelluksen tunnistaakin siitä, että ihan aluksi se on määritelty järkeväksi ja hyvin toimivaksi palveluksi: toiminnallisuudet on määritelty asiakaskohtaisesti ja loppukäyttäjien tarpeet kartoitettu huolellisesti. Lisäksi sovelluskehitys on toteutettu siten, että jokaisella sovelluksen ominaisuudella on joku käyttäjiensä toimintaa tukeva aito tarkoitus. 

Hyvin toteutetun ohjelmiston tunnuspiirteitä on myös se, että käyttöliittymä on selkeä, sulavasti toimiva ja sitä on miellyttävä käyttää. Sovelluskehitys/ohjelmistokehitys onkin onnistunut, kun lopputuote päätyy esimerkiksi projektin tilanneen asiakkaan henkilökunnan käyttöön ja siitä on konkreettista hyötyä työarjen sujumisessa eri henkilöstöryhmien, kuten tiimien tai osastojen välillä.

Sovelluksen kehittäminen ei siis pitäisi olla käytännössä koskaan sitä, että tehdään pinnallisia ja hienoja featureja ilman järkevää käyttötarkoitusta. Eli käyttäjiä ei kuunnella ja toivotaan, että hurja määrä ominaisuuksia tarkoittaa toimivaa lopputulosta! Ei, ei ja ei.

Tällaiset caset tunnistaa helposti siitä, että sovellukseen koodataan turhia ominaisuuksia, jotka pahimmassa tapauksessa ainoastaan tekevät käyttämisestä sekavaa ja turhauttavaa. Lopulta voikin käydä helposti niin, että sovellus hylätään käyttäjien toimesta pysyvästi bittimuseoon.

Huolimattomasti määritelty kehitysprojekti syö vain yrityksen resursseja, eikä sovelluksella saavuteta tavoiteltuja hyötyjä.

Sovelluskehitys: Linnanmäki & sähköinen ajopäiväkirja

Helsingin Alppilassa sijaitseva Linnanmäki on Suomen tunnetuin ja vanhin huvipuisto sekä kävijämäärältään myös suosituin huvipuisto, joka kerää runsaasti niin kotimaisia kuin ulkomaisiakin matkailijoita ja vierailijoita etenkin kesäkaudella.

Linnanmäen huvipuisto pitää sisällään yli 40 huvipuistolaitetta, runsaasti erilaisia pelejä sekä ravintoloita ja kahviloita. Huvipuiston suosituin laite on tietysti legendaarinen puinen vuoristorata, joka on ilahduttanut huvipuiston kävijöitä jo vuodesta 1951 alkaen.

Turvallisuus kokonaisuutena on tietysti ensiarvoisen tärkeä asia suositussa huvipuistossa. Linnanmäki toteuttikin Systems Gardenin kanssa ohjelmisto- ja sovelluskehityksenä sähköisen ajopäiväkirjan.

”Yhteistyökumppanin pitää olla aktiivisesti mukana. Ja aktiivisesti mukana pitää olla myös kehitystyössä. Koodaaminen ei ole meidän työtämme, joten emme välttämättä edes tiedä, mitä kaikkea koodaamalla voidaan tehdä. Siksi kaipaamme ideoita ja ohjeita. Siinä Systems Garden on erittäin hyvin onnistunut.”

 

Aki-Petteri Padar
kunnossapitopäällikkö
Linnanmäen huvipuisto

Linnanmäen laitteet tarkistetaan päivittäin ja Systems Gardenin toteuttama sähköinen ajopäiväkirja on kriittinen osa huvipuiston päivittäistä toimintaa. Sovelluksella kirjataan kaikki huomiot ja se mahdollistaa viestinnän laitteiden käyttäjien ja huoltoryhmän välillä. 

Käytön aikana tulevat huomiot, havainnot ja viat kirjataan ajopäiväkirjaan – ja huollon asiantuntijat näkevät sieltä, mikä laite kaipaa huomiota. He pystyvät käyttämään sovelluksessa tehtyjä havaintoja vikojen paikallistamiseen. Aamulla taas saapuva henkilöstö näkee, että laite on tarkastettu, huollettu ja valmiina avattavaksi.

Tutustu mielenkiintoiseen asiakascaseemme tarkemmin!

Näppärät Gate HSEQ -sovellukset

Työturvallisuuden ja laadun parantaminen teollisuuslaitoksissa, työmailla ja kiinteistöissä tarvitsee tietenkin oman sovellusperheen. Me päätimme toteuttaa sellaisen – ja nyt näillä sovelluksilla on jo paljon tyytyväisiä käyttäjiä.

Gate on kehittämämme työturvallisuus- ja laadunhallintasovellusten moderni tuoteperhe, HSEQ-termi taas muodostuu sanayhdistelmästä Health, Safety, Environment ja Quality. Gate HSEQ -sovelluksiin kuuluvat Gate Työluvat, Gate Havainnot ja Gate Auditoinnit, ja ne toimivat niin erillään kuin yhdessäkin. Niillä on yhteiset taustatiedot: esimerkiksi käyttäjähallinta, kohderekisteri karttoineen sekä henkilö- ja pätevyysrekisteri.

Gate HSEQ -sovellukset on kehitetty yhdessä asiakkaiden kanssa työturvallisuuden ja laadunhallinnan parantamiseen – vastaamaan modernilla tavalla työpäivän tarpeisiin laitosympäristöissä, työmailla, telakoilla ja kiinteistöissä. Koska sovellukset ovat oikeiden asiakasprojektien kehitystyön tulosta, saat valmiit ja viilatut sovellukset käyttöön ilman raskaita IT-projekteja.

Sovellusten käyttäjämääriä ei ole rajoitettu, joten asiakas voi ottaa helposti mukaan oman alihankkijaverkostonsa ja urakoitsijansa ilman kustannusten kasvua. Sovelluksilla on luonnollisesti myös 100 prosentin tyytyväisyystakuu.

Gate HSEQ -sovellukset

1. Gate Työluvat = luvanvaraisten töiden ja niiden vaatimien pätevyyksien hallintaan.
2. Gate Havainnot = turvallisuuspoikkeamien, aloitteiden tai muiden havaintojen raportointiin ja käsittelyyn.
3. Gate Auditoinnit = turvallisuus- tai tarkastuskierroksiin, töiden vastaanottoon ja muihin dokumentointitarpeisiin.

Tee turvallisuustyöstä näkyvää ja vaivatonta, tutustu tuoteperheeseen.

Ratkaisuihimme ja palveluihimme luottaa jo yli 100 yritystä ja yhteisöä – toimialasta riippumatta. Olemme tehneet ohjelmisto- ja sovelluskehitysprojekteja jo lähes 20 vuotta.

Sovelluskehitys ja ohjelmistoprojektit

Sovelluskehitys: onko mielessä uusi kehitysprojekti? Onko sinulla ehkä ajatus uudesta sähköisestä palvelukanavasta, mobiilisovelluksesta tai työtä automatisoivasta sovelluksesta. Kaipaako briljantti ideasi vahvistusta? Kannattaisiko mobiilisovellusta kokeilla pilottina vielä kentällä ennen kuin se tehdään loppuun? Muutamme ideasi todeksi.

Järjestelmäkehitys ja modernisointi: onko sinulla jo hyväksi havaittu ja toimiva sovellus, jonka elinkaari alkaa kuitenkin olla loppusuoralla. Kaipaako sovelluksen käyttöliittymä päivittämistä ja siirtoa nykypäivän vaatimuksiin paremmin vastaavaksi. Miten mobiiliyhteensopivuus? Tai loppuiko Microsoftin vakioalusta kesken? Päivitämme sovelluksesi tähän päivään.

Sovelluskehitys on onnistunut, kun käyttäjät ottavat sovelluksen käyttöön arjessa.

Miten juuri me toimimme?

Meidät tunnetaan ohjelmistotalona, jonka erikoisosaamista on bittien ja datan sovittaminen asiakkaan liiketoiminnan tarpeisiin asiakkaan määrittelemällä tavalla. Toimintamallimme joustavat kunkin projektin edellyttämällä tavalla, joten kehitystä teemme aina asiakkaan määrittelemien speksien ehdoilla. Hyödynnämme olemassa olevia ja hyväksi havaittuja valmisratkaisuja ja monistettavia ohjelmistokomponentteja. Olemme tehneet sovelluskehitys- ja ohjelmistokehitysprojekteja liki 20 vuotta.

Ohjelmistoprojekti avaimet käteen
Kannamme tarvittaessa kokonaisvastuun ohjelmistoprojektista suunnittelusta käyttöönottoon ja ylläpitoon. Teemme ohjelmistoprojekteja määrittelyn perusteella joko kiinteähintaisena tai tavoitehinnalla pienistä ohjelmistokomponenteista kokonaisjärjestelmiin.

Ketterä ohjelmistokehitys
Ketterät ohjelmistokehityshankkeemme etenevät vaiheittain, yleensä suunnilleen 2–4 viikon sprinteissä. Lopputulos elää tavoitteiden, demojen ja välikatselmusten kautta tavoitteena saavuttaa paras mahdollinen lopputulos vaiheittain. Ketterän kehityksen palvelumme ovat yleensä aika- tai työmääräveloitteisia.

Konsulttitoimeksiannot
Omaamme vankan asiantuntemuksen eri teknologioista. Meiltä saat asiantuntijan omaan projektiisi – React frontend -kehitykseen, Microsoft-backendiin (Azure, SQL, C#) tai Microsoft 365 -konsultointiin – järkevällä tuntihinnalla.

Lisätietoja sovelluskehityksestä.

• Tutustu tarkemmin yritysten sopimusten hallintaan
• Dokumentinhallinta kuntoon yrityksellesi

”Teidän kanssanne on vaan niin mukava tehdä töitä.”

Lue muita asiakkaidemme kokemuksia

Ketterät sovelluskehityshankkeemme etenevät yleensä vaiheittain, noin 2–4 viikon sprinteissä. Ketterän kehityksen palvelumme ovat yleensä aika- tai työmääräveloitteisia.

Onko sovelluskehitys ajankohtainen aihe?

Kannamme sovittaessa kokonaisvastuun projektistasi sen suunnittelusta aina käyttöönottoon ja ylläpitoon asti. Teemme ohjelmistokehitystä määrittelysi perusteella joko kiinteähintaisena tai tavoitehinnalla pienistä ohjelmistokomponenteista kokonaisjärjestelmiin.

Yhteydenottosi ei sido sinua mihinkään, eikä se myöskään maksa yrityksellesi mitään. Yhteystietojasi emme käytä muihin tarkoituksiin tai jaa niitä eteenpäin.

Voimme auttaa sinua sovelluksen kehittämisessä. Ota yhteyttä Systems Gardenin asiantuntijaan ja sovi helppo etätapaaminen. Tarkastellaan organisaatiosi tilannetta ja tapaa toimia = pohditaan, minkälainen sovelluskehitys voisi sopia teidän yrityksellenne.

Systems Gardenin asiantuntijasi sovelluskehityksessä

Pirkka Paronen
pirkka.paronen@systemsgarden.com
+358 50 592 1207

Lue myös viime kuun blogikirjoituksemme, sen aiheena sopimushallinta
Muut blogikirjoituksemme

Yrityksemme LinkedInissä

Autohuollon videointipalvelu on huoltoasiakkaalle tarjottu digitaalinen palvelu, johon auton huolto videoidaan. Videon avulla asiakas pääsee kurkistamaan auton alle asentajan opastuksella, ja voi valtuuttaa asentajan tekemään ehdotetut työt suoraan palvelusta.

Systems Garden suunnitteli yhteistyössä R-Officen kanssa keskitetyn hallintaportaalin, joka hoitaa määrittelyn mukaisesti videoiden vastaanoton, käsittelyn, yhdistämisen ajoneuvon tietoihin sekä loppuasiakkaan sähköisen viestinnän.

Katso R-Officen case-esittely YouTubesta, ja lue lisää projektista referensseistämme.

Useat tunnetut pääkaupunkiseudun julkisivuhankkeet ovat Alupro Oy:n käsialaa.  Yritys toteuttaa suunnittelijoiden visiot erilaisissa kohteissa, ja tämän lupauksen myötä jo 70% yrityksen liikevaihdosta tulee palvelumyynnistä.

Kuinka tuotannonohjausjärjestelmä ja kasvava palveluliiketoiminta saadaan sovitettua yhteen niin, että päätöksiä voidaan tehdä nopeasti, faktoihin perustuen?

Uudistetaan raportointia ja tehdään siitä reaaliaikaista Microsoftin Power BI -raportoinnilla! Lue asiakastarinamme referensseistä.