Opas sarjassa: Dynamics 365 -kumppanin valinta

Miten valita oikea kumppani Dynamics 365 Finance & Supply Chain Management -ratkaisulle?

Lyhyt vastaus: älä aloita kumppanin ansioluettelosta, vaan siitä, mistä olette luopumassa. Konserni, joka vaihtaa AX 2012:sta, asettaa toimittajalle täysin erilaisia vaatimuksia kuin se, joka luopuu SAP:sta tai yhdistää viisi eri järjestelmää. Kumppanien joukko, joilla on todellista kapasiteettia, on pieni, joten arvioinnin painopiste on tiimin henkilöissä, toimituksen maakohtaisessa järjestämisessä ja siinä, kuka ylläpitää ratkaisua projektin päätyttyä.

Tämän oppaan on kirjoittanut d365 Guide. Emme toteuta Dynamics 365 -ratkaisuja emmekä myy lisenssejä. Olemme olemassa, jotta ostaja voi vertailla kumppaneita samoin perustein.

Tämä opas koskee erityisesti Finance & Supply Chain Managementia. Yleisestä valintaprosessista, sovelluksesta riippumatta, katso oppaamme oikean Dynamics 365 -kumppanin löytämisestä Suomessa.

Miksi tämä hankinta poikkeaa muista?

Finance & Supply Chain Management on Microsoftin yrityssegmentin ratkaisu, jonka juuret ovat Axaptassa ja myöhemmin AX:ssä. Järjestelmä on rakennettu konserneille, joilla on useita juridisia yksiköitä, monimutkaisia tavaravirtoja ja toimintaa useissa maissa. Tämä näkyy kaikessa: projektien koossa, aikataulussa, mukana olevien määrässä ja siinä, kuinka harva toimittaja todella pystyy toimittamaan.

Muutama suuruusluokka viitekehyksenä, ja jotka ovat d365 Guiden arvioita Suomen markkinoista. Projektit alkavat tyypillisesti noin 450 000 eurosta ja kestävät useita vuosia esiselvityksestä vakaaseen käyttöön. Arvioimme, että Suomessa on noin sata asiakaskonsernia, jotka käyttävät järjestelmää tai sen edeltäjiä, ja että uusia projekteja alkaa noin viisikymmentä vuodessa. d365 Guide on tunnistanut useampia toimijoita F&SCM-osaamisella, mutta suurempien suomalaisten moniyritysohjelmien tai kansainvälisten kokonaisvaltaisten ohjelmien osalta arvioimme, että riittävän kapasiteetin omaava ryhmä on noin kymmenen. Nämä luvut ovat markkina-arvioitamme, päivitetty syyskuussa 2026, eivät virallisia Microsoft-tilastoja.

Tällä on seuraus, jota harvoin lausutaan: puhtaat uusmyyntisopimukset ovat harvinaisia. Monet kumppanit hakeutuvat sen sijaan nykyisten asiakkaiden pariin konsultointipalveluilla, paremmilla ylläpitosopimuksilla tai ottamalla haltuunsa jatkokehityksen, ja laajentavat sitten toimeksiantoa maa kerrallaan.

Teille ostajana tämä tarkoittaa kahta asiaa. Kilpailu projektistanne on pienempää kuin luulette, mikä heikentää neuvotteluasemaanne. Ja valitsemanne kumppani tulee todennäköisesti olemaan kanssanne useita vuosia, sillä toimittajan vaihtaminen tämän kokoisen asennuksen keskellä on kallista ja riskialtista. Arvioinnin on siksi oltava terävämpi, ei laimeampi, kuin pienemmässä hankinnassa.

Terminologinen asia, joka vaikuttaa laajuuteen

Finance ja Supply Chain Management ovat kaksi erillistä sovellusta, jotka lisensoidaan erikseen, vaikka markkinat ja useimmat kumppanit puhuvat niistä yhtenä järjestelmänä. Selvennä ajoissa, mitkä moduulit te itse asiassa tarvitsette, sillä se vaikuttaa sekä lisenssikustannuksiin että tiimin tarvitsemaan osaamiseen. Sama koskee lähisovelluksia, kuten Project Operations ja Human Resources, jotka usein hiipivät laajuuteen esiselvityksen aikana.

Vaihe 1: Lähtekää siitä, mitä olette korvaamassa

Tämä on tärkein rajaus, ja se, joka useimmiten ohitetaan. Vaatimuslista on suunnilleen sama lähtötilanteesta riippumatta, mutta tehtävä työ eroaa perustavanlaatuisesti, ja siten myös sopiva kumppani.

LähtötilanneMitä kumppanin on ennen kaikkea kyettävä todistamaan
AX 2012 R2/R3 tai AX 2009AX 2012 R2/R3:lle: kokemusta Microsoftin tukemasta päivityspolusta, koodianalyysistä, laajennuksista ja tiedonsiirrosta. AX 2009:lle: kokemusta migraatioprojekteista Finance and Operationsiin. Molemmissa tapauksissa kumppanin tulee pystyä osoittamaan, miten vanhat mukautukset ja ISV-riippuvuudet arvioidaan ennen niiden käyttöönottoa.
SAP, IFS tai muu suurempi ERPProsessisuunnittelu perustuksista alkaen ja migraatio ilman yhteistä datamallia. Ei perintökoodia huomioitavaksi, mutta huomattavasti raskaampaa työtä liiketoiminnan prosessien ja käsitteistön kanssa.
Useita järjestelmiä konsernissaKyky rakentaa ydinmalli ja levittää se. Lokalisaatiot, juridiset yksiköt, konsernin yhteiset prosessit ja ohjausmalli, joka toimii yritysten välillä.
Business Central on kasvanut yli roolinsaEttä he uskaltavat kyseenalaistaa vaihdon. Syynä on usein muutama prosessi, ei koko järjestelmä, eikä kumppani, joka mielellään myy kalliimpaa ratkaisua, ole se, joka selvittää asian teille.

Jos luovutte AX 2012:sta tai AX 2009:stä

Tämä on yleisin lähtötilanne Suomessa. AX 2012 on ollut useita vuosia Microsoftin normaalin tuen ulkopuolella, ja useimmat sitä edelleen käyttävät ovat lykänneet päätöstä hyvästä syystä: järjestelmä toimii, se on voimakkaasti mukautettu ja syvästi integroitu liiketoimintaan.

AX 2012 R2:lle ja R3:lle on olemassa Microsoftin tukema päivityspolku Finance and Operationsiin, joka voi sisältää sekä datan että koodin. Tämä ei kuitenkaan tarkoita, että kaikkea tulisi siirtää muuttumattomana. Keskeinen osa esiselvitystä on päättää, mitä päivitetään, mitä rakennetaan uudelleen ja mitkä vanhat mukautukset ja prosessit tulisi jättää jälkeensä. AX 2009 ei noudata samaa tuettua päivityspolkuja, ja se on siksi arvioitava migraatioskenaariona, jolla on erilaiset edellytykset.

Etsitte kumppania, joka on tehnyt juuri tämän matkan useita kertoja ja joka pystyy osoittamaan, miten he selvittävät, mitkä vanhat mukautukset tulisi sisällyttää. Yleinen ja kallis virhe on rakentaa kaikki takaisin, mitä oli olemassa, peläten, että joku saattaisi kaivata jotain.

Huomaa myös, että pitkä kokemus AX:stä ei automaattisesti tarkoita syvällistä kokemusta nykyisestä Finance and Supply Chain Managementista. Alusta, laajennusmalli, käyttö ja päivitys-malli ovat muuttuneet. Arvioi siis, kuinka monta modernia toteutusta, päivitystä ja käyttöönottoa henkilö on todella tehnyt, ei vain AX-vuosien määrää.

Jos luovutte SAP:sta, IFS:stä tai muusta suuremmasta ERP-järjestelmästä

Tässä ei ole perintökoodia huomioitavana, mikä kuulostaa helpommalta kuin mitä se on. Työ siirtyy sen sijaan prosessisuunnitteluun ja liiketoiminnan käsitteiden kääntämiseen uuteen rakenteeseen. Tilikartta, tuotetiedot, asiakasrakenne ja varastologikka näyttävät harvoin siltä, mihin olette tottuneet, ja organisaatio kokee sen.

Kumppanilla on oltava kokemusta tämän tyyppisen käännöstyön johtamisesta, ei vain järjestelmän konfiguroinnista. Kysy erityisesti, miten he työskentelevät liiketoiminnan avainkäyttäjien kanssa suunnitteluvaiheessa ja kuinka paljon siitä ajasta on teidän vastuullanne.

Jos yhdistätte useita järjestelmiä konsernissa

Silloin kyseessä ei ole projekti, vaan ohjelma. Kysymykseksi tulee, mikä on yhteinen ydinmalli ja mitä jokainen yritys saa päättää itse, ja tämä on hallintakysymys yhtä paljon kuin tekninen kysymys.

Tämän toimittavan kumppanin on osattava kuvata malli- ja käyttöönottonsa konkreettisesti: miten mallia ylläpidetään, miten poikkeamia käsitellään, miten paikalliset vaatimukset eri maissa rakennetaan sisään, ja mitä toinen ja kolmas maa todella maksaa verrattuna ensimmäiseen. Pyydä lukuja aiemmalta asiakkaalta, ei periaatekuvausta.

Jos koette Business Centralin käyneen liian pieneksi

Tämä on lähtökohta, jossa näemme useimmiten vääriä johtopäätöksiä. Puute ei harvoin piile muutamaassa prosessissa, integraatioissa, jotka eivät koskaan valmistuneet, tai siinä, että järjestelmä konfiguroitiin toimintaan, josta te kasvoitte ulos.

Vaihto suurempaan ratkaisee ongelman, mutta täysin eri kustannuksin ja monimutkaisuudella kuin todellisen ongelman korjaaminen. Kumppanilla, jolta kysytte, on yleensä oma etu vastauksessa. Varmistakaa siksi, että analyysin tekee joku, joka hyötyy yhtä paljon molemmista lopputuloksista, tai tehkää se sisäisesti.

Jos johtopäätöksenä on, että pysytte nykyisessä ratkaisussa, on sen tason kumppanivalinta tarkistettava. Käsittelemme sitä oppaassa, joka kertoo, miten löydätte oikean Dynamics 365 -kumppanin Suomessa.

Vaihe 2: Päätä, onko kyseessä projekti vai ohjelma

F&SCM-käyttöönotto yhdessä yrityksessä ja käyttöönotto kahdeksassa yrityksessä viidessä maassa eivät ole sama asia. Silti ne usein hankitaan samalla tavalla, ja poikkeamat ilmenevät vasta, kun toinen maa on aloittamassa.

Selvennä ennen kuin aloitatte:

  • Kuinka monta juridista yksikköä ja maata on mukana, ja missä järjestyksessä?
  • Mitä tulee olla yhteistä ja mitä saa poiketa yritysten välillä?
  • Kuka omistaa mallin ensimmäisen käyttöönoton jälkeen?
  • Tuleeko kumppanin toimittaa kaikki maat, vai voitteko käyttää paikallisia resursseja joissakin?

Vastaukset ohjaavat siihen, minkä tyyppinen toimittaja on järkevä. Kumppani, jolla ei ole omaa läsnäoloa Pohjoismaiden ulkopuolella, voi silti toteuttaa käyttöönoton, mutta silloin on ilmettävä, miten ja kenen kanssa he tekevät yhteistyötä.

Vaihe 3: Kokoa pitkä lista kaventamatta kenttää tarpeettomasti

Usein sanotaan, että F&SCM vaatii yhden globaaleista järjestelmäintegraattoreista. Tämä ei pidä paikkaansa Suomen olosuhteissa. Suurimmilla toimijoilla on syvät resurssit ja globaali kattavuus, mutta on olemassa myös keskisuuria pohjoismaisia kumppaneita, joilla on pitkä F&SCM-historia ja huomattavasti suurempi osuus seniorikonsultteja tiimeissään.

Mikä todella karsii, ei ole yrityksen koko, vaan kolme asiaa:

  • Go-live-projektien määrä Finance and Operationsissa viimeisten kahdenkymmenen neljän kuukauden aikana. Ei asiakkaiden kokonaismäärä, eikä AX-historia.
  • Ovatko he toimittaneet jotain, mikä muistuttaa teidän lähtötilannettanne, eli samanlaisen vaihdon samanlaisesta järjestelmästä.
  • Pystyvätkö he miehittämään teidät seniorihenkilöillä ilman, että toinen käynnissä oleva projekti tyhjennetään.

Neljästä kuuteen ehdokasta on kohtuullinen lähtökohta. Useampaa on vaikea arvioida vaaditulla syvyydellä, ja vähemmän ei anna teille minkäänlaista vertailua.

Vaihe 4: Arvioi tiimiä, ei yritystä

Tämän kokoisessa projektissa ette osta toimittajaa, vaan arkkitehtitiimin. Ero kahden saman hintaluokan kumppanin välillä on lähes aina henkilöissä.

Ratkaisuarkkitehti

Projektin tärkein rooli. Arkkitehti yhdistää konsernin taloudellisen rakenteen, eli konsernitilinpäätöksen, sisäisen hinnoittelun ja yhteiset toiminnot, operatiivisiin virtoihin. Pyydä CV, kysy, mitkä henkilön viimeisistä projekteista menivät tuotantoon, ja keskustele arkkitehdin itsensä kanssa ennen sopimuksen allekirjoittamista.

Talous- ja toimitusketjun jaottelu

On epätavallista, että sama konsultti on vahva sekä edistyneessä talousmallissa että raskaassa logistiikassa tai tuotannossa. Arvioikaa siksi tiimiä kokonaisuutena ja pyytäkää CV:t niiltä, jotka asentavat moduulit, joista olette todella riippuvaisia. Jos teillä on edistynyt varastonhallinta, tuotanto tai globaali hankintalogistiikka, näihin alueisiin on oltava nimettyjä henkilöitä.

Projektipäällikkö ja muutosjohtaja

Projektipäällikön tulisi olla johtanut vähintään yhden vastaavan kokoisen käyttöönoton vakaaseen käyttöön asti, ei vain go-live-vaiheeseen. Muutosjohtaminen ei ole pehmeä kysymys tässä järjestelmässä: F&SCM koetaan monimutkaiseksi niille, jotka työskentelevät siinä päivittäin, ja käyttöönotto ratkaisee, tuottaako investointi tulosta.

Vaihe 5: Tarkista toimitusmalli

Lähes kaikki suuremmat kumppanit yhdistävät konsultteja Suomessa resursseihin muissa maissa. Tämä ei ole ongelma sinänsä, ja toimitus, joka on kokonaan miehitetty suomalaisilla seniorikonsulteilla, tulee erittäin kalliiksi ilman, että siitä välttämättä tulee parempi.

Ratkaisevaa on, missä projektin rajat menevät. Analyysin, suunnittelun ja ratkaisun muotoilevien päätösten tulisi olla lähellä liiketoimintaa ja kielellä, jossa vivahteet eivät katoa. Konfiguraatio, kehitys, tiedon puhdistus ja testaus toimivat hyvin sijoitettuna vakiintuneeseen keskukseen toisessa maassa.

Kysy suoraan, miten tiimi on koottu, millä aikavyöhykkeillä se työskentelee ja kuka kirjoittaa vaatimusmäärittelyn, jonka perusteella kehittäjät rakentavat. Nimenomaan tässä siirrossa syntyvät kalliit väärinymmärrykset.

Vaihe 6: Kysymyksiä kysyttäväksi ja miten vastauksia tulisi tulkita

Seuraavat kysymykset on muotoiltu niin, ettei niihin ole itsestään selvää hyvää vastausta. Vastauksen arviointi on vähintään yhtä tärkeää kuin kysymys.

1. Kuinka monta go-live-projektia teillä on ollut Finance and Operationsissa viimeisen kahden vuoden aikana?

Tämä on yksittäinen informatiivisin kysymys koko arvioinnissa, ja se, johon useimmiten vastataan epämääräisesti.

Hyvä vastaus sisältää:

  • Luku, jonka asiakkaat voidaan nimetä ja mielellään ottaa yhteyttä.
  • Eron uusien käyttöönottojen, laajennusten lisämaihin ja siirrettyjen ylläpitopalveluiden välillä.

Varoitusmerkit:

  • Vastaus liukuu asiakkaiden kokonaismäärään tai yrityksen historiaan AX:ssä.
  • Referenssit ovat useita vuosia vanhoja.

2. Kuka tulee olemaan ratkaisuarkkitehtimme, ja saammeko tavata hänet nyt?

Arkkitehti on henkilö, jonka päätösten kanssa elätte kymmenen vuotta. Henkilön tapaaminen vasta käynnistyksen yhteydessä on liian myöhäistä.

Hyvä vastaus sisältää:

  • Nimen, CV:n ja tapaamisen ilman myyjää huoneessa.
  • Tiedon siitä, kuinka suuren osan ajastaan henkilö käyttää teidän projektiinne ja mitä hän tekee muuten.

Varoitusmerkit:

  • Arkkitehti nimetään sopimuksen allekirjoittamisen jälkeen.
  • Henkilö esitellään arkkitehtina, mutta on pääasiassa työskennellyt AX:ssä.

3. Miten suunnittelette tiedonsiirron, ja kuka siitä vastaa?

Tiedonsiirto on oma projekti projektin sisällä, ja yleisin syy go-live-ajankohdan siirtymiseen.

Hyvä vastaus sisältää:

  • Kuvauksen siitä, kuinka monta testisiirtoa suunnitellaan ja milloin ensimmäinen tapahtuu.
  • Selkeän vastuunjaon tiedon laadusta, jossa suuri osa kuuluu kohtuudella teille.

Varoitusmerkit:

  • Siirto kuvataan teknisenä toimintana myöhään projektissa.
  • Saldojen, historian ja perustietojen välillä ei tehdä eroa.

4. Mitä tulee olemaan ydinmalli ja mitä paikallista?

Kysymys koskee kaikkia konserneja, myös niitä, jotka aloittavat yhdessä maassa, sillä malli määritetään ensimmäisessä käyttöönotossa riippumatta siitä, kutsutteko sitä sellaiseksi.

Hyvä vastaus sisältää:

  • Konkreettisen mallin siitä, mitä hallitaan keskitetysti ja mikä saa poiketa.
  • Kokemuslukuja siitä, mitä toinen maa on maksanut verrattuna ensimmäiseen aiemmalla asiakkaalla.

Varoitusmerkit:

  • Kysymykseen vastataan periaatteellisesti ilman esimerkkejä.
  • Kaiken pitäisi olla yhteistä, ilman keskustelua siitä, mitä tapahtuu, kun yritys ei voi noudattaa mallia.

5. Miten tiimin kokoonpano jakautuu maiden kesken?

Katso edellinen osio toimitusmallista. Kysymys on esitettävä suoraan ja siihen on vastattava luvuilla.

Hyvä vastaus sisältää:

  • Jakautumisen roolin ja vaiheen mukaan, ei vain kokonaisprosenttiosuutta.
  • Tiedon siitä, kuka kirjoittaa vaatimukset, joiden mukaan kehittäjät rakentavat.

Varoitusmerkit:

  • Paikallisten konsulttien osuus esitetään korkeana myyntivaiheessa ja laskee tarjouksessa.
  • Analyysivaiheeseen miehitetään pääasiassa resursseja, jotka eivät tapaa liiketoimintaa.

6. Mitä lisäsovelluksia ehdotatte, ja kuka omistaa suhteen?

Useimmat F&SCM-ratkaisut sisältävät kolmannen osapuolen sovelluksia esimerkiksi varastonhallintaan, EDIin, veroraportointiin tai dokumenttien hallintaan.

Hyvä vastaus sisältää:

  • Luettelon siitä, kuka on toimittaja, mitä se maksaa jatkuvasti ja kenen kanssa teillä on sopimus.
  • Pohdinnan siitä, mitä sovellukselle tapahtuu, jos vaihdatte implementointikumppania.

Varoitusmerkit:

  • Kumppanin omat sovellukset esitetään ilman hinta-arviota.
  • Riippuvuudet ilmenevät vasta sopimuksen liitteissä.

7. Miten ylläpito on järjestetty, ja kuka tekee jatkokehityksen?

Järjestelmää päivittää Microsoft jatkuvasti, ja ratkaisunne on pysyttävä mukana. Ylläpito on se vaihe, jossa elätte pisimpään ja jossa kokonaiskustannukset määräytyvät.

Hyvä vastaus sisältää:

  • Kirjallisen ylläpitomallin, jossa on nimetty asiakasvastaava, vasteajat ja hinnoittelumalli.
  • Suunnitelman siitä, miten regressiotestaus hoidetaan Microsoftin päivitysten yhteydessä.
  • Tiedon siitä, ovatko ylläpitotiimin henkilöt samoja kuin projektitiimin, ja miten siirto tehdään.

Varoitusmerkit:

  • Ylläpitosopimuksesta keskustellaan vasta sen jälkeen, kun projektisopimus on allekirjoitettu.
  • Jatkokäsittely hinnoitellaan ainoastaan juoksevana, ilman minkäänlaista priorisointiprosessia.

Ansiot ja käsitteet, jotka mittaavat jotain muuta kuin luulet

  • FastTrack for Dynamics 365 on Microsoftin asiakkuuden menestys- ja neuvontaohjelma päteville projekteille, joka toimitetaan yhdessä toteutuskumppanin kanssa ja perustuu Success by Designiin. Se ei ole kumppanisertifikaatti tai kumppanin ansio sinänsä. Kokemus FastTrackista, Implementation Portalista ja go-live readiness -tarkastuksista voi kuitenkin olla relevanttia, kun arvioitte kumppanin tottumusta Microsoftin toteutusvaatimuksiin.
  • Microsoftin kumppanimääritykset perustuvat vuodesta 2022 alkaen Solutions Partner -nimityksiin. Kultakompetenssi-käsitettä ei enää ole, eikä sitä tulisi esiintyä ajankohtaisessa aineistossa.
  • Sure Step on lakkautettu. Microsoftin nykyinen implementointiopastus on rakennettu Success by Designin ympärille. Kumppani, joka edelleen kuvaa Sure Stepiä nykyisenä metodologianaan, kertoo vahingossa jotain siitä, kuinka usein materiaali tarkistetaan.
  • Sertifikaatit liittyvät henkilöihin, eivät yrityksiin. Kysymys on, ovatko sertifioidut henkilöt niitä, jotka teille tulevat.
  • Yrityksen konsulttien määrä ei kerro mitään siitä, kuinka moni heistä on käytettävissä, kun projektinne alkaa.

Mikä yleensä menee pieleen itse valinnassa

  • Vaatimusmäärittelystä tulee liian yksityiskohtainen liian aikaisin, mikä sitoo ratkaisun vanhan maailman prosesseihin ja ajaa eteenpäin mukautuksia, joita teidän on sitten ylläpidettävä.
  • Arviointi painotetaan demoon ja esitykseen. Kaikki ehdokkaat tässä segmentissä esittelevät hyvin.
  • Ylläpitovaihe jätetään hankinnan ulkopuolelle, vaikka se muodostaa suurimman osan kokonaiskustannuksista kymmenen vuoden aikana.
  • Sisäistä omistajaa ei nimetä mallille, mikä tarkoittaa, että kumppani käytännössä päättää, miten konserni työskentelee.
  • Aikataulu asetetaan liiketoiminnan päivämäärän mukaan sen sijaan, että otettaisiin huomioon kuinka monta testisiirtoa todella tarvitaan.
  • Päätöksentekoryhmä ei ole yksimielinen siitä, miksi vaihto tehdään, mikä ilmenee vasta suunnitteluvaiheessa, kun prioriteetit törmäävät.

Huomautus lähteistä

Suurin osa Suomessa julkaistusta aineistosta Dynamics 365 -kumppanin valinnasta on kumppanien kirjoittamaa. Materiaali on usein asiantuntevaa, mutta sen on kirjoittanut osapuoli, jolla on intressi lopputulokseen, ja siksi kriteerit päätyvät usein lähelle heidän omaa profiiliaan.

Tässä segmentissä se painaa enemmän kuin missään muussa, koska toimittajia on vähän ja jokainen yksittäinen hankinta on suuri. Lukekaa useita lähteitä ja miettikää, kuka hyötyy siitä, että juuri nämä kriteerit painavat eniten.

Seuraavat vaiheet

Aloita kirjoittamalla ylös kolme asiaa ennen kuin otat yhteyttä mihinkään toimittajaan: mistä olette luopumassa, mitkä maat ja yritykset sisältyvät ja missä järjestyksessä, ja mitä pitäisi olla ratkaistu kahden vuoden kuluessa. Näiden kolmen vastauksen avulla toimittajakeskustelut ovat lyhyempiä ja huomattavasti valaisevampia.

d365 Guidessa voitte vertailla suomalaisia Dynamics 365 -kumppaneita sovellusalueen, toimialan ja koon mukaan ja rajata kenttää ennen kokousten varaamista.

Jos aiotte samalla tarkistaa CRM-puolen, on olemassa erilliset oppaat Dynamics 365 Salesille sekä Customer Servicelle ja Field Servicelle.

Seuraava suositeltu opas

Aiheeseen liittyvät oppaat