fbpx
Otatko M365-lisenssistä täyden hyödyn irti?

Otatko M365-lisenssistä täyden hyödyn irti?

Otatko M365-lisenssistä täyden hyödyn irti?

Systems Gardenin M365-asiantuntijat Miia, Samppa ja Satu kertovat, että Microsoft 365 -lisenssi tarjoaa erinomaiset mahdollisuudet keskittää ohjelmistotarpeita sekä karsia päällekkäisiä järjestelmiä ja turhia kustannuksia. Ennen kaikkea se luo säästöä arjen helpottumisen ja sujuvoitumisen kautta.

SG:n asiantuntijat toteavat Microsoftin saavuttaneen 365-lisenssillään laajan käyttäjäkunnan, minkä ansiosta myös käyttäjien ja organisaatioiden ymmärrys sen tarjoamista mahdollisuuksista paranee kaiken aikaa. Lisensseistä jää kuitenkin edelleen paljon hyödyntämättä.

– Käyttäjät tiedostavat koko ajan paremmin, että M365-ympäristöön kuuluu paljon muutakin kuin Outlook. Samalla lisenssillä pyörivät esimerkiksi intranet, dokumentinhallinta, sopimushallinta, Teams sekä lomakkeet. Kun dataa kertyy paljon, myös raporttien laadinta onnistuu kätevästi. Tietoisuudella olisi kuitenkin vielä runsaasti varaa parantua, Samppa tuumii.

Kaksi henkilöä suunnittelee ohjelmistoa hyödyntäen matkapuhelinta ja paperista leikattuja malleja.

M365-lisenssi karsii päällekkäisyyksiä ja tuo säästöä

Mitä M365-ympäristön keskeiset hyödyt sitten ovat? Satun mukaan ensinnäkin se, että vaikka M365-ympäristö avaa käyttäjälleen erilaisia työkaluja kuin linkkuveitsi, tarjoaa se toisaalta myös hyvät mahdollisuudet karsia päällekkäisyyksiä.

– Kun aletaan pohtia lisenssin laajempaa hyödyntämistä ja sitä, mitä kaikkia ohjelmistotarpeita asiakkaalla oikeastaan on, voidaan M365-ratkaisujen käyttöönotossa usein poistaa niiden vastineita. Kun asiat tapahtuvat samassa ympäristössä, ei useita eri ohjelmistoja tarvita.

Miia nostaa tästä esimerkiksi Microsoftin kanssa kilpailevat intraratkaisut. Hän kertoo, että M365-lisenssiin kuuluvaan SharePointiin voidaan rakentaa sujuva ja helppokäyttöinen intra, mutta todella moni ei sitä tiedä. Tai jos ratkaisu onkin käytössä, niin tiedossa ei välttämättä ole se, kuinka hyvin tiedonhallinta SharePointin avulla mahdollistuu.

– Perinteisesti tiedostoja on jouduttu tallentamaan yksi kerrallaan niille määrättyihin paikkoihin, ja vaikka osa yrityksistä onkin siirtänyt ohjelmistotarpeensa pilveen, saattaa käytössä olla edelleen sama kansiorakenne kuin verkkolevyllä. Silloin vaikkapa jonkin yksittäisen sopimuksen löytäminen voi olla yllättävän hankalaa.

– Pilvessä se onnistuu huomattavasti vaivattomammin metatietojen avulla. Ne vaativat jonkin verran hallinnointia ja yritykseltä muutoksen johtamista, mutta niiden avulla tiedot kuitenkin ohjautuvat aina oikeaan paikkaan ja löytyvät etsimättä. Säästö muodostuu käyttäjän arjessa, kun tietojen käsittely selkeytyy ja helpottuu.

Kaksi henkilöä suunnittelee ohjelmistoa hyödyntäen matkapuhelinta ja paperista leikattuja malleja.

Eroon verkkolevyistä

Työn helpottamisen ja sujuvoittamisen sekä päällekkäisten ohjelmistojen karsinnan ohella M365-ympäristö mahdollistaa kustannussäästön kolmannellakin tavalla. Sampan mukaan se on nostanut ilmiönä päätään jo jonkin aikaa.

– Nykyisin hankkiudutaan yhä enemmän eroon vanhoista verkkolevyistä, jolloin päästään samalla eroon palvelimen ylläpito- ja konesalikuluista. Jokainen lisenssi antaa pilveen paljon tilaa, johon mahtuu suuri määrä dataa. Sopimukset, dokumentit, intra yms. voidaan viedä M365-ympäristöön ja paikallinen palvelin sammuttaa.

– Sen jälkeen käytettävissä on versionhallinta, VPN:ää ei tarvita ja kaikki on saavutettavissa mistä vain – voit selata tietoja vaikka kännykällä, Samppa vinkkaa.

Monipuolinen M365-lisenssi helpottaa ja sujuvoittaa arjen työtä

Päätös M365-ympäristön laaja-alaisemmasta valjastamisesta tehdään Sampan mukaan harvoin organisaation ylätasolla. Tyypillisemmin tarve havaitaan osastokohtaisesti, kun vaikkapa sopimuskatkon tai liittymätarpeen yhteydessä ryhdytään pohtimaan vaihtoehtoja dokumentinhallinnan tai sopimushallinnan ratkaisuille.

– Se kirpoaa yleensä jostain tietystä kokonaisuuden nurkasta, ja siinä vaiheessa meihin on yhteydessä esimerkiksi viestinnästä tai it-asioista vastaava henkilö. Sellainen avaus, että ”Tiedämme, mitä kaikkea lisenssillä voi tehdä, mutta voisitteko auttaa siinä?” on aika harvinainen. Tyypillisempää on, että asiakas ymmärtää tarvitsevansa apua, mutta ei oikein itsekään tiedä, missä ongelmat piilevät. Niissäkin tapauksissa toki tiedostetaan, että sen hetkisiin ratkaisuihin menee paljon rahaa, Samppa toteaa.

– Joskus M365-ympäristön laajempi haltuunotto käynnistyy jonkin muun projektin, kuten Teams-käyttöönoton johdannaisena, tai koulutuksen yhteydessä, kun huomio kiinnittyy siihen, mihin yhdessä tehdyt työt tallennetaan, Satu lisää.

Kaksi henkilöä suunnittelee ohjelmistoa hyödyntäen matkapuhelinta ja paperista leikattuja malleja.

M365-lisenssistä saa parhaan hyödyn kokonaisvaltaisella käytöllä

Systems Gardenin ammattilaiset auttavat mielellään yksittäisten M365-ratkaisujen parissa ja painottavat yhteistyön merkitystä, mutta huomauttavat samalla, että paras hyöty lisenssistä saadaan keskittämällä työskentely yhteen ympäristöön.

– Asiakkaalla on paras tieto siitä, miten he tekevät asioita ja kuinka eri osastot työskentelevät ja pelaavat yhteen. Meidän ammattilaisemme voivat kuitenkin vinkata, missä nykyään kannattaa olla ja minkälaisia automaatioita rakentaa. Autamme konsultoinnista toteutuksen siinä laajuudessa kuin asiakas haluaa, Satu lupaa.

Tarvittaessa Systems Gardenin asiantuntijat laativat yhdessä asiakkaan kanssa kartoituksen ja roadmapin, jonka pohjalta ohjelmistokokonaisuuden sujuvoittamista ja mahdollista karsintaa voidaan toteuttaa.

Optimaalisinta olisi päästä kiinni asiakkaan kokonaiskuvaan, sillä niin monet asiat liittyvät toisiinsa. On aina ihanaa päästä sanomaan asiakkaalle, miten jokin kannattaa tehdä ja että meillä on siihen kaikki ratkaisut, koska silloin päästään tehostamaan asiakkaan työskentelyä niin positiivisessa mielessä – helpottamisen ja mukavoittamisen kautta, Samppa summaa.

Kiinnostuitko? Anna meidän auttaa M365-lisenssin paremmassa hyödyntämisessä!

Lue lisää

Systems Garden Oy:n toimitusjohtaja vaihtuu

Systems Garden Oy:n toimitusjohtaja vaihtuu

Systems Garden Oy:n toimitusjohtaja vaihtuu

Jatkona keväällä toteutettuihin yhtiöjärjestelyihin Systems Garden Oy:n toimitusjohtajaksi on nimitetty Jussi Rautjärvi. Nimitys vahvistaa entisestään Systems Gardenin keskittymistä asiakaskohtaisten Microsoft-teknologiaratkaisujen ja ohjelmistokehitysprojektien toimittamiseen. Tavoitteena on tarjota asiakkaille jatkossa entistäkin parempaa palvelua ja tulevan kasvun myötä yhä enemmän osaamista.

Työurallaan Rautjärvi on toiminut useissa ICT-alan teknologia- ja konsultointiyhtiöissä myynnin ja markkinoinnin sekä liiketoimintajohdon tehtävissä.
– Systems Garden on erittäin mielenkiintoinen yritys ja meillä on erittäin paljon erityisosaamista, jonka avulla voidaan aidosti kehittää asiakkaiden liiketoimintaa ja tehostaa työntekoa. Lisäksi SG:llä on ainutlaatuisen avoin ja keskusteleva kulttuuri, jonka ansiosta asiakkaat voivat olla varmoja, että kanssamme on helppoa ja vaivatonta työskennellä, tuore toimitusjohtaja kertoo.

Väistyvä toimitusjohtaja Pirkka Paronen jatkaa yhtiön hallituksessa sekä System Gardenin ja sen asiakkaiden teknologisena neuvonantajana. Päätyökseen Paronen toimii jatkossa Gate Apps Oy:n toimitusjohtajana.

– Olemme jo muutaman vuoden ajan palvelleet asiakkaitamme kahdella hyvin erilaisella toimialalla. Digitaalisen Gate-työlupatuotteen kasvettua suureksi sen erottaminen kokonaisuudesta mahdollistaa kummankin liiketoiminnan kehittämisen omaan suuntaansa ilman kompromisseja ja hankalia priorisointeja.

– Olen iloinen, että Jussin mukaan liittymisen myötä Systems Gardenin Microsoft-liiketoiminta saa arvoisensa osaavan vetäjän ja pystyy hankalampien vuosien jälkeen palaamaan aidolle kasvu-uralle, Paronen lisää.

Liiketoimintojen eriyttäminen toteutettiin keväällä 2023 yrityskauppajärjestelynä. Toimitusjohtajan vaihdos on jatkoa toteutetulle järjestelylle.

– Liiketoimintojen eriytyessä on luonnollista, että myös System Garden saa uuden toimitusjohtajan, jonka vastuulla on johtaa terävöitettyä strategiaa ja kasvua, yhtiön hallituksen puheenjohtaja Santeri Korpinen kiteyttää.

Lisätietoja asiasta antavat toimitusjohtajat
Pirkka Paronen, puh. +358 50 592 1207, pirkka.paronen@systemsgarden.com
Jussi Rautjärvi, puh +358 50 306 2515, jussi.rautjarvi@systemgarden.com 

 

Millainen on hyvä liiketoiminnan vaatimusmäärittely?

Millainen on hyvä liiketoiminnan vaatimusmäärittely?

Millainen on hyvä liiketoiminnan vaatimusmäärittely?

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.

 

Hyvä liiketoiminnan vaatimusmäärittely sovellusprojektin alussa takaa sujuvuuden.

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.

Sovelluskehityksen hyvä liiketoiminnan vaatimusmäärittely huomioi toimiala- ja asiakaskohtaiset tarpeet.

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

Liiketoimintavaatimusten huolellinen määrittely ehkäisee väärinkäsityksiä.

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

Dokumentinhallinnan puolustuspuhe: Mihin sitä tarvitaan enää 2020-luvulla?

Dokumentinhallinnan puolustuspuhe: Mihin sitä tarvitaan enää 2020-luvulla?

Teksti: Pirkka Paronen, dokumentinhallinnan seniorikonsultti

Kun hiljattain vaahtosin taas puolisolleni viimeisimmästä siististä työprojektista (tietysti insinöörin teknologiaa ihannoivalla, ympäripyöreällä tasolla asiakasspesifejä seikkoja mainitsematta), tokaisi hän hieman yllättäen ”Etkös sinä ole ollut tekemässä niitä digitalisaatiojuttuja? Miten vanha homeinen dokumentinhallinta siihen liittyy?”.

Kommentti sai minussa ensin aikaan tiettyjä vastareaktioita, mutta lopulta jäin itsekin pohtimaan ajatuksen taustaa. Nykyisinhän tietojärjestelmiä ja datavarastoja on jo liikakin. Eihän kukaan enää tarvitse jonkin 90-lukulaisen A4- tai letterformaattiin taitetun kopion digitalisointia. Jos dokumentinhallinnan näkee vain paperikopioina tai arkistona, näin ehkä onkin. Asia ei kuitenkaan ole niin yksinkertainen, ja niinpä huomasin, että dokumentinhallinta tarvitsee nykymaailmassa puolestapuhujan.

Mainittakoon ensinnäkin selvennyksenä, että dokumentit ja tiedostot sekoitetaan helposti keskenään. Yksilöillä ja organisaatioilla on monesti erilaisia tiedostovarastoja, olivat ne sitten verkkolevyjä palvelinten uumenissa tai Teams-rakenteisiin piilotettuja organisaatiosiiloja. Dokumentilla tarkoitetaan kuitenkin yleensä tiedostoa (tai joukkoa tiedostoja), jotka liittyvät johonkin tapahtumaan – yrityksen kontekstissa tietysti liiketoimintatapahtumaan. Julkishallinnossa puolestaan käytetään yleensä termiä asia.

Mutta palataanpa lupaamiini perusteluihin. Täältä pesee dokumentinhallintaa puolustava TOP-6-listani (koska tiivistäminen viiteen kappaleeseen ei onnistunut):

1. Dokumentinhallinnan valtti: dokumentti on pysyvä ja se säilyttää sisältönsä tietyllä ajan hetkellä

Organisaatiot ovat täynnä tietojärjestelmiä. Usein niitä päivitetään ja valitaan sen mukaan, miten tietoa on mahdollisimman helppo luoda, muokata ja prosessoida. Usein tietoa käsitellessä ei tarvitakaan varsinaisesti dokumenttia, vaan ainoastaan helppo tapa hakea tietoa järjestelmästä.

Mitä sitten, kun aikaa kuluu ja järjestelmissä oleva data päivittyy? Mitä jos halutaan tietää, miltä liiketoimintasuhde näytti sen alkamishetkellä? Tai joudutaan erimielisyyksiin projektitoimittajan kanssa toimituksen sisällöstä? Tai halutaan tietää, minkälainen lasku aiheesta 10 vuotta sitten itse asiassa aiheesta lähetettiin?

Yksi dokumentinhallinnan tehtävistä on toimia arkistona. Se paljastaa miltä asiat näyttivät liiketoimintatapahtuman aikaan – ei ainoastaan niiden nykytilaa.

2. Dokumentti on itsenäinen, kokonainen tietojoukko

Toinen olennainen ajatus dokumentista on, että se on itsenäinen, kokonainen tietue. Dokumentti ei välttämättä tarvitse ympärilleen käyttöliittymää, vaan se voidaan tarvittaessa siirtää ja lukea sellaisenaan. Dokumentin mukana kulkee yleensä riittävä konteksti siihen liittyvistä muista tiedoista: yritysten nimet ja y-tunnukset, asiakasnumerot, tuotekoodit ja -kuvaukset jne. Jos katsot dataa tietokannasta käsin, tämä data on yleensä pyritty minimoimaan ja tietokanta sisältääkin vain viittauksia esim. asiakas- tai tuoterekisteriin.

Dokumentti sisältää myös aiheeseen liittyvät tiedot, yleensä selkokielisessä ihmiselle ymmärrettävässä muodossa. Se on kokonainen sisältö, joka ei välttämättä tarvitse viitteitä tai liitetietoja ollakseen ymmärrettävä tai ainakin liitteet ovat silloin olennainen osa itse dokumenttia.

Kaksi henkilöä suunnittelee ohjelmistoa hyödyntäen matkapuhelinta ja paperista leikattuja malleja.

3. Dokumentti ylittää organisaatiorajat, tarvittaessa asiakkaisiin saakka

Dokumentteja voidaan käyttää yli organisaatiorajojen. Usein nykyaikaisissa yhteistyösovelluksissa (esim. Teams) tiedon rakenteet kasautuvat joko organisaatioyksikön/tiimin tai vaikkapa jonkin projektin ympärille. Kaikki toimii hienosti niin kauan kuin asioita käsitellään vain talousosastolla tai projektin sisällä. Kun tietoa pitää jakaa laajemmin, alkaakin melkoinen käyttöoikeuksiin, näkyvyyteen ja säilytyspaikkoihin liittyvä souvi.

Sama dokumentti voi olla organisaatiolle arvokas niin myynti-, tuotanto- kuin jälkimarkkinointivaiheessa. Olennaista voi olla myös sen tunnistaminen, miten tieto on muuttunut vaikkapa rakennuksen tai tietojärjestelmän siirtyessä eri vaiheissa organisaatiosta toiselle. Dokumentin voi jakaa tai lähettää kollegalle toisessa organisaatioyksikössä ilman, että häntä tarvitsee välttämättä opettaa käyttämään mitään. Dokumentin siirtymisriitillä organisaatiolta toiselle on myös sellainen funktio, jota ei välttämättä tulisi ensin ajatelleeksi. Dokumentti ikään kuin siirtää vastuun asian käsittelystä jatkossa toiselle porukalle: ”Tältä asia näytti, kun se valmistui tuotannosta. Ottakaa te siitä asiakaspalvelussa koppi tästä eteenpäin.

Vielä tärkeämpänä pointtina dokumentin voi siirtää myös asiakkaille, toimittajille ja muille sidosryhmille. Koska dokumentti ei tarvitse järjestelmää ympärilleen, voidaan se jakaa vaikkapa sellaisenaan asiakkaille ja kumppaneille – kumppanin koosta, tietojärjestelmätilanteesta tai teknisistä lähtökohdista riippumatta. Eroja voi toki olla siinä, minkä muotoisia tiedostoja kumppani osaa tai pystyy lukemaan, mutta ainakin heillä on mahdollisuus osallistua prosessiin myös tätä kautta. Dokumentti on myös pysyvä todiste siitä, että jotain on suoritettu, toimitettu tai vastaanotettu. Tämä voi asiakaskommunikaatiossa olla jopa kriittistä.

4. Dokumentti on dataa, joka liikkuu järjestelmien välillä helposti

Kaikki tietojärjestelmäammattilaiset rakastavat ja kavahtavat integraatioprojekteja. Miten saada tieto liikkumaan kahden eri tarkoitusta palvelevan järjestelmän – vaikkapa taloushallinnon ja projektinhallinnan – välillä saumattomasti? Helppoa, eikö?

Yksinkertaisin tapa toteuttaa integraatio on siirtää dokumentteja itse – tai parhaassa tapauksessa vain linkittää niitä keskenään. Projektipäällikölle ei välttämättä ole oleellista ymmärtää kaikkia tiliöinnin nyansseja tai tositteiden säilömiskriteerejä (taloushallinnon perusteita) omassa työssään. Sen sijaan hänelle voi olla tärkeää vaikkapa nähdä projektille saapuneet tai siitä lähetetyt laskut mahdollisimman helpossa formaatissa. Koska dokumentti sisältää jo itsessään kaikki tarvittavat tiedot, on tiedon välittäminen dokumentteina helpoin tapa vaihtaa tietoa järjestelmien välillä.

No entäs data sitten? Dokumentinhallintaakin voi käsitellä datana, sillä eräs sen perustoiminteista on säilyttää dokumenteista ns. metadataa, mutta itse dokumenttikin voi olla dataa. Esimerkiksi taloushallinnon datana voidaan myyntilaskuun (usein PDF-dokumentti) liittää vaikkapa koneluettavaa dataa (esim. Finvoice-tyyppinen XML-dokumentti). Näin mukaan saadaan myös taloushallinnon metadata, joka voidaan vaikkapa raportointitarkoituksissa lukea sisään myös projektinhallinnan softaan.

5. Dokumentinhallinnan helppous: kaikki osaavat käyttää dokumentteja

Eräs dokumenttien parhaista puolista on se, että kaikki osaavat käyttää niitä. On totta, että dokumentin alkuperäinen formaatti on ollut paperi, eikä se välttämättä ole nykyisellä erikokoisten ruutujen aikakaudella enää optimaalinen, mutta toisaalta kenellekään ei tarvitse opettaa PDF-dokumentin lukemista tai paperiformaatin käyttöliittymää.

Kaksi henkilöä suunnittelee ohjelmistoa hyödyntäen matkapuhelinta ja paperista leikattuja malleja.

6. Dokumentti selviää järjestelmäpäivityksistä

Oletko koskaan ollut mukana tietojärjestelmän päivitysprojektissa? Halusitpa tai tiedostitpa sitä taikka et, todennäköisesti olet. Tekninen kehitys laukkaa nykymaailmassa niin nopeasti, että dataa joudutaan siirtämään yhä nopeampiin ja älykkäämpiin tietojärjestelmiin kaiken aikaa.

Yleensä järjestelmäpäivitysten syynä ei ole historiallisen tiedon parempi käsittely, vaan olemassa olevien prosessien tehostus, toimintatapojen muutokset, paremmat käyttöliittymät ja esimerkiksi automaatio.

On suurta hulluutta yrittää siirtää kaikki mahdollinen data sellaisenaan vanhoista järjestelmistä uusiin, sillä eihän tiedon syntymiseen ole useinkaan ollut edes samanlaisia prosesseja mitä uusista. Vanha data voikin olla perustellumpaa säilyttää dokumentteina. Silloin tieto on edelleen tallessa, se voidaan lukea järjestelmästä riippumatta ja sitä ei tarvitse sovittaa siirrettäessä sitä seuraavaan ERP-järjestelmään.

Dokumentti selviää järjestelmäpäivityksistä ja ERP:n tai CRM:n uusinnasta tarvittaessa vaikka useamman kerran.

Dokumentinhallinnan tarve ei ole katoamassa

Listaa dokumentin- tai asianhallinnan hyödyistä voisi jatkaa pidemmällekin. Enkä väitä, että dokumentinhallintajärjestelmä olisi tärkein tietojärjestelmä missään talossa – pointtini vain on se, että dokumentinhallinnalle ja tiedonhallinnalle on 2020-luvulla yhä tarvetta. Itseasiassa sille on tarvetta todennäköisesti vielä 2050-luvullakin. Uusia tietojärjestelmiä ja käyttöliittymiä tulee jatkossa kiihtyvää tahtia ja dataa täytyy siirtää ja käsitellä useissa eri paikoissa.

Dokumentinhallinnan järjestelmän tehtävä ei välttämättä ole pysytellä aallon harjalla kaikissa tulevissa teknologiatrendeissä, mutta johtuen dokumenttien erikoisominaisuuksista, dokumentinhallinnalla on varmasti paikkansa jatkossakin – ehkä jopa tärkeämpi kuin äkkiseltään tulisi ajatelleeksi.

Jos haluat jutella tai sparrata dokumentinhallinnan tarpeestasi asiantuntijan kanssa, teemme Systems Gardenilla dokumentinhallinnan projekteja aivan standardilla Microsoft 365 -alustalla. Kuten ehkä artikkelista bongasit, dokumentin- tai asianhallinta ei itse asiassa ole pelkkää teknologiaa, vaan ennen kaikkea tapa ja formaatti järjestää tietoa fiksummin. Itse asiassa se teknologia sinulla on todennäköisesti jo olemassa – ainakin mikäli Microsoftin alusta on jo käytössäsi muihin tarkoituksiin.

Sudenkuopat ohjelmistoprojekteissa – ja kuinka ne vältetään!

Sudenkuopat ohjelmistoprojekteissa – ja kuinka ne vältetään!

Sudenkuopat ohjelmistoprojekteissa – ja kuinka ne vältetään!

 

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ä.

 

10 yleisintä sudenkuoppaa softaprojekteissa

 

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ä.

 

Kaksi henkilöä suunnittelee ohjelmistoa hyödyntäen matkapuhelinta ja paperista leikattuja malleja.

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.

Metsänhoitoyhdistykset saivat tarpeitaan vastaavat intraratkaisut.

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.

Nelihenkinen henkilöstöryhmä työskentelee turhautuneena ohjelmistoprojektin parissa.

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

Henkilö suunnittelee ohjelmistoa työpöydän ääressä käyttäen kuvia ja paperista leikattuja malleja.

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.

Nelihenkinen henkilöstöryhmä työskentelee turhautuneena ohjelmistoprojektin parissa.

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.

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

 

Nelihenkinen henkilöstöryhmä työskentelee turhautuneena ohjelmistoprojektin parissa.

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

Lue lisää

Kiinnostuitko? Ota yhteyttä!

Ota yhteyttä ja sovi etätapaaminen. Katsotaan minkälainen ratkaisu juuri sinun yrityksellesi sopisi.

6 + 10 =

Ota yhteyttä