Artikkelin keskeiset kohdat
Prosessit ennen työkalua
Kuka hyväksyy, mitä ovat poikkeukset ja millainen päätösjälki tulee säilyttää.
Nykytilan kartoitus
CRM, toimialajärjestelmät, kirjaamojärjestelmä ja toimisto-ohjelmisto hoitavat usein osan asiankäsittelyistä.
Vaatimukset riippuvuutta vastaan
Tietojen vienti, rajapinta, BPMN, konfigurointioikeudet, poistumissuunnitelma.
Monivuotinen kustannus
Hankinta, käyttöönotto, ylläpito ja irtautumisen kustannus, verrattuna teidän omiin skenaarioihinne.
Zdjęcia ilustracyjne
Kirjaa sitten ylös vaatimukset, jotka suojaavat riippuvuudelta: tietojen ja asiahistorian vienti avoimessa muodossa, dokumentoitu rajapinta (API), BPMN-standardilla kuvatut prosessit, oikeus omaan konfigurointiin ja selkeät säännöt sopimuksesta irtautumiselle. Nimeä riskit, jotka pystyt jo nyt tunnistamaan. Älä ole naiivi — kirjaa kaikki riskit ylös. Vertaile tarjouksia omilla skenaarioillanne ja monivuotisena kokonaiskustannuksena (investointi plus toistuvat operatiiviset kustannukset). Lisenssit, uusimiset, koulutukset, tiimin ylläpito, muutokset, migraatiot. Mieti, kuinka todennäköistä on, että toimittaja menettää avainkonsulttinsa, päättää korvata ylläpitäjät ja kehittäjät tekoälyllä tai lopettaa nykyisen käyttöjärjestelmän tuen.
Tämä artikkeli on tarkoitettu yritysten ja kunnallisten yhtiöiden (spółka komunalna) hallituksille, jotka haluavat järjestää asiakirjojen, kuluvatollisten laskujen, sopimusten tai hakemusten käsittelyn ja ovat valitsemassa workflow-järjestelmää eli työkalua, joka vie asian henkilöltä toiselle ennalta sovittujen sääntöjen mukaisesti. Valittavana on tavallisesti kolme reittiä: valmis BPM-alusta, low-code-työkalu tai tilaustyönä rakennettu räätälöity järjestelmä; alla olevat periaatteet koskevat kaikkia niistä. Artikkeli hyödyttää myös talousjohtajia, sillä he yleensä maksavat huonon valinnan seuraukset.
Miksi riippuvuus toimittajasta syntyy jo alkuvaiheessa
Riippuvuus syntyy harvoin yhdestä huonosta päätöksestä. Yleensä se alkaa aikaisemmin kuin yritys huomaakaan: prosessit kuvataan toimittajan työkalussa eikä yrityksen omissa dokumenteissa; tiedot ja asiahistoria ovat muodossa, jota ei voi helposti viedä pois; konfiguraation tuntee vain käyttöönottokumppani; ja sopimus puhuu paljon käyttöönotosta mutta vähän siitä, mitä tapahtuu, kun yritys haluaa lähteä. Muutaman vuoden kuluttua järjestelmän vaihtaminen maksaa enemmän kuin sen ylläpito, vaikka se ei enää vastaisi tarpeita.
Vaihe 1. Kuvaa prosessit ennen keskusteluja toimittajien kanssa
Ennen tarjouspyynnön laatimista kannattaa kuvata asiankäsittelyt, joita järjestelmän tulee tukea: kuka asian aloittaa, kuka hyväksyy sen ja missä järjestyksessä, mitkä ovat poikkeukset ja kynnysarvot (esimerkiksi erilainen käsittelytie tietyn summan ylittyessä), mitkä ovat määräajat ja millainen päätösjälki tulee säilyttää mahdollista tarkastusta varten. Parasta on kirjata tämä BPMN-standardilla, jota eri työkalut ymmärtävät. Tällöin prosessikuvaus kuuluu yritykselle, ei järjestelmälle.
Ilman tällaista kuvausta vertaillaan toimittajien esityksiä, ei ratkaisuja. Jokainen esittely näyttää hyvältä, koska toimittaja näyttää oman parhaan skenaarionsa, ei teidän vaikeinta poikkeustapaustanne.
Vaihe 2. Selvitä, mitä sinulla jo on
Osa asiankäsittelyistä voidaan usein hoitaa työkaluilla, jotka yrityksellä jo on: CRM:ssä, toimialajärjestelmissä, kirjaamojärjestelmässä tai toimisto-ohjelmistossa. Joskus analyysin johtopäätös on, ettei uutta järjestelmää tarvita lainkaan, vaan riittää menettelyn tai konfiguraation muutos. Tällainen kartoitus paljastaa myös integraatiot, joita uuden järjestelmän on tuettava, esimerkiksi talous- ja kirjanpitojärjestelmän ja KSeF:n (Puolan kansallinen sähköisen laskutuksen järjestelmä) kanssa, sekä paikat, joissa tieto tänään katoaa. Lisää aiheesta: IT-järjestelmien kartoitus.
Vaihe 3. Vaatimukset, jotka suojaavat riippuvuudelta
Nämä vaatimukset kannattaa kirjata tarjouspyyntöön ehtoina, ei toiveina:
- Tietojen ja asiahistorian vienti avoimessa, dokumentoidussa muodossa, milloin tahansa ja ilman lisämaksua.
- Dokumentoitu rajapinta (API) integraatioihin muiden järjestelmien kanssa, oikeudella käyttää sitä myös muilla toimittajilla.
- Standardimuotoiset prosessikuvaukset (BPMN), jotka voidaan viedä pois ja rakentaa uudelleen muualla.
- Oikeus konfigurointiin oman tiimin tai minkä tahansa kumppanin toimesta, muutosdokumentaation kera.
- Sopimuksesta irtautumisen säännöt: siirtymäaika, apu tietojen migraatiossa ja sen kustannus tiedossa etukäteen.
- Ylläpitokumppanin valinta: voiko käyttöönoton jälkeen vaihtaa toiseen toteutusyritykseen menettämättä valmistajan tukea.
Tämä on kuin toimistotilan vuokraus sopimuksella, joka kertoo, mitä sisään tuleminen maksaa, mutta vaikenee poistumisesta. Niin kauan kuin kaikki toimii, kukaan ei huomaa sitä. Ongelma ilmenee sinä päivänä, kun pitää muuttaa pois.
Sama koskee RPA:ta, ERP:tä ja CRM:ää
Nämä periaatteet pätevät jokaiseen järjestelmään, joka järjestää yrityksen työtä. Joka kerta kannattaa kuitenkin aloittaa kysymyksestä, mitä halutaan saavuttaa, sillä vastaus ratkaisee, valitaanko ylipäätään oikea työkaluluokka.
RPA. Ensimmäinen kysymys kuuluu: miksi juuri RPA eikä BPM? Ohjelmistorobotti ottaa haltuunsa ihmisen toistuvia toimintoja olemassa olevissa järjestelmissä, mutta ei muuta itse prosessia; BPM puolestaan järjestää itse prosessin. Jos tavoitteena on vapauttaa ihmiset tietojen kopioimisesta järjestelmästä toiseen, robotti voi riittää. Jos tavoitteena on uusi, lyhyempi asiankäsittelypolku, robotti usein vain vakiinnuttaa vanhan. Robotti on myös riippuvainen muiden järjestelmien näytöistä ja muodoista: mikä tahansa niiden muutos voi pysäyttää sen, joten on hyvä tietää skenaarioiden ylläpidon kustannus ja pitää niiden kuvaus toimittajan työkalun ulkopuolella.
ERP. Tässä keskeinen kysymys kuuluu: pitääkö ERP:n tarjota meille parhaita käytäntöjä ja valmiita prosesseja, vai pitääkö sen tukea omia prosessejamme, jotka rakentavat kilpailuetua? Ensimmäisessä tapauksessa kannattaa pitäytyä järjestelmän standardissa ja rajoittaa muutoksia, sillä jokainen niistä vaikeuttaa päivityksiä ja kumppanin vaihtoa. Toisessa tapauksessa toimii joskus paremmin yksinkertainen ERP, jota tukee ketterä BPM-järjestelmä, jossa muutetaan yrityksen erottuvia prosesseja ilman ydinjärjestelmän muokkaamista. Molemmissa tapauksissa taloudellisten, varasto- ja henkilöstötietojen sekä KSeF- ja pankki-integraatioiden tulee olla vietävissä kokonaan ulos, historiansa mukana.
CRM. Ennen tarjousten vertailua kannattaa selvittää, mitä CRM-käsitteellä tarkoitetaan: asiakaspalveluprosessien järjestämistä, monikanavaista myyntiä vai sopimusten hankinnan alustaa. Nämä ovat kolme eri projektia, joilla on eri käyttäjät, eri integraatiot ja eri onnistumismittari. Riippumatta vaihtoehdosta, asiakastietokannan vienti yhteydenottohistorioineen ja suostumuksineen sekä rajapinta myynti- ja asiakaspalvelujärjestelmiin tulisi olla tarjouspyynnön ehto, ei lisäpalvelu.
Vaihe 4. Vertaa kokonaiskustannusta, ei lisenssin hintaa
Tarjoukset kannattaa koota monivuotiseksi kokonaiskustannukseksi: hankinta ja käyttöönotto, ylläpito ja lisenssit, kehitys sekä sopimuksesta irtautumisen kustannus. Halvin lisenssi voi osoittautua kalleimmaksi kolmantena vuonna, kun jokainen prosessimuutos tarkoittaa maksullista toimeksiantoa yhdelle kumppanille. Vertailu kannattaa tehdä omilla skenaarioillanne: anna jokaisen toimittajan näyttää sama vaikea tapaus yrityksestänne. Lisää tarjousten arvioinnista: tarjousten arviointi ja keskustelut toimittajien kanssa.
Talousjohtajalle tärkeimmät ovat kaksi lukua, joita tarjouksessa ei yleensä ole: prosessin muutoksen kustannus käyttöönoton jälkeen ja toimittajasta irtautumisen kustannus. Niitä kannattaa pyytää suoraan tarjousten arviointivaiheessa.
Vaihe 5. Vastaanotto ja ylläpitosopimus
Järjestelmä kannattaa ottaa vastaan etukäteen sovittujen testiskenaarioiden ja kriteerien perusteella, ei toimittajan vakuutusten perusteella. Ylläpitosopimuksen tulee kertoa, missä ajassa virheet korjataan, kuka ja mihin hintaan tekee muutoksia, sekä vahvistaa tietojen viennistä ja sopimuksesta irtautumisesta sovitut ehdot.
Esimerkki käytännöstä
Kansainvälisen konsernin tytäryhtiöiden ryhmässä yritys käytti keskitettyä ERP-järjestelmää ja tarvitsi samalla automatisoida procure-to-pay-ryhmän taloudellisia prosesseja, ja tämän piti tapahtua konsernin hankintaohjeiden (corporate purchasing guidelines) mukaisesti. Houkutus tarttua konsernin ryhmätyökaluihin oli suuri, mutta ne osoittautuivat melko kalliiksi eivätkä täyttäneet riippumattomuusvaatimuksia tai helpon poistumisen vaatimuksia ongelmien ilmetessä.
Sidosryhmätapaamisissa laadimme yksityiskohtaisen vaatimusmäärittelyn, joka ylitti valmisratkaisujen vakiotoiminnot. Kehitimme useita vaihtoehtoisia tapoja integroida toimialajärjestelmiin sekä mekanismeja, jotka rajoittivat riskiä sitoutua yhteen toimittajaan. Tuloksena syntyi standardeihin perustuva yhtenäinen sovellusstrategia ja ympäristö, jossa uudet asiankäsittelyt rakennetaan ketterästi prototypoimalla lyhyissä tapaamisissa prosessien omistajien, myös ei-teknisten, kanssa. Tämä ympäristö tukee ERP-järjestelmää: se antaa suurta joustavuutta siellä, missä yritys erottuu kilpailijoistaan, ilman suurten käyttöönottoprojektien kustannuksia.