Dynamics 365 Project Service Automation: Kaksi lähestymistapaa PSA:n käyttöönottoon

Dynamics 365 Project Service Automation:n käyttö eroaa organisaatioiden välillä. Syitä tähän ovat käyttöönottotavat ja erilaiset lähestymisnäkökulmat sekä syyt sovelluksen käyttöönotolle. PSA (ja Field Service) ovat molemmat sovelluksia, joita voi käyttää out-of-the-box, asetusten ja parametrien määrittelemisen jälkeen.

Usein PSA-projekti sisältää mukautuksia, kuten muutkin D365 CE -projektit, mutta PSA:n kohdalla yhdellä yksityiskohdalla on eroa: Logiikka, jonka mukaisesti sovellus toimii, on vakio. PSA:n toiminnallisuuksia voi jatkaa, mutta sovelluksen toimintalogiikkaa ei pidä muuttaa. Tällä tavoin sovellus toimii kun Microsoft julkaisee siihen päivityksiä.

Vaikein sovellus oppia

Siinä missä D365 CE:n Sales ja Customer Service -sovellukset ovat suoraviivaisia, PSA ja Field Service ovat hyvin erilaisia. Jätän Field Servicen tämän blogikirjoituksen ulkopuolelle, koska se on täysin oma tarinansa. Keskitytään PSA:iin. MVP Steve Morduen loistavaa blogikirjoitusta lainatakseni, mikä on helppoa minulle saattaa olla vaikeaa sinulle ja toisin päin. Miten sitten määrittelemmekään helpon, argumentoin silti että PSA on D365 CE -alustan vaikein sovellus oppia.

Mitä ”vaikein” sovellus oikeasti tarkoittaa? Lyhyesti kuvattuna se tarkoittaa ”PSA-prosessia” eli liidistä laskutukseen -prosessia ja ymmärrystä siitä mitä yksityiskohtia on otettava huomioon prosessia läpikäytäessä. Liiketoiminta- ja prosessinäkökulmasta katsottuna haasteena on myös se, että tapa käyttää PSA:a on lukitty tiettyyn malliin. Tästä syystä käytän nimitystä ”PSA-prosessi”. Tässä kohtaa saatat ajatella ”Mutta meillähän on liiketoimintaprosessinauhat D365 CE:ssä…”. Tämä on hyvä ja kaunis ajatus, mutta se rajoittuu tiettyyn täsmälliseen prosessiin (esim myyntimahdollisuus tai liidi). Tarkoitan ”PSA-prosessilla” kokonaisprosessia korkealla tasolla: Tapaa edetä liidistä laskutukseen ja niitä toimenpiteitä, joita sovelluksessa täytyy prosessissa edetessä suorittaa. Kyse on valmissovelluksesta, joten tämä on asiaa tarkemmin ajatellessa järkeenkäypää. Vai onko…?

Kaksi lähestymistapaa PSA:n käyttöönottoon

PSA:n käyttöönottoon on kaksi lähestymiskulmaa, käytettäessä sovelluksen vakiotoiminnallisuuksia ja ilman sovelluksen toiminnallisuuksien jatkamista koodilla tai konfigutoinnilla. Rakentamalla PSA:n ympärille voidaan sovellus voidaan viedä vaikka kuun ympäri, kuten t-rex tatuoitu CRM-veteraani Chris Huntingford totesi kertoessaan RAID-lokeista D365 UG Virtual Summer Camp -presentaatiossaan. PSA:n kehittäminen ja toiminnallisuuksien jatkaminen ei kuitenkaan ole tämän blogikirjoituksen fokus, joten keskitytään siihen mitä sovellus on out-of-the-box.

PSA:n kaikkien toiminnallisuuksien käyttöönotto samanaikaisesti on organisaatiolle melko työlästä, erityisesti jos D365 CE on täysin uusi tuttavuus ja aiempaa kokemusta tuotteesta ei ole. Jos ”PSA-prosessi” on yhtenä kokonaisuutena liian paljon, mitä vaihtoehtoja käyttöönoton pilkkomiseksi on? Miten lähdetään liikkeelle siitä mikä on liiketoiminnan kannalta tärkeää niin että kaikki ”nice to have” tulee myöhemmin perässä?

1. Talouden konteksti

Yksi kahdesta lähestymisesta PSA:iin on talouden konteksti. Tarkoitan tällä projektisopimusta (Project Contract) ja kaikkea siihen välittömästi liittyvää. Lähestyminen talouden kontekstista tarkoittaa fokusoitumista laskutettavan datan laatuun ja sen integroimista tai siirtämistä NAV, Business Central, AX tai Finance & Operations tyyliseen ERP:iin laskutusta varten.

Painopisteen ollessa talouden lähestymisessä, PSA-projekti keskittyy myyntimahdollisuudesta laskutukseen -prosessiin ilman suurta panostusta projektinhallintaan ja resursointiin. Projektit ovat silti tässä lähestymissä mukana, koska ne ovat talouden datan muodostumisen vaatimuksena. Tässä vaiheessa saatat kaivata konkreettisia esimerkkejä, joten avaan talouden kontekstia syvällisemmin.

Talouden konteksti pitää sisällään projektisopimuksen (Project Contract) ja sen siihen liittyvät muuttujat. Projektisopimuksen Time & Material ja Fixed Price -rivit määrittävät sekä projektisopimuksen että siihen liittyvien projektien luonteen. Tunteja ja kuluja syötetään valittua projektia vastaan, jolloin taustalla syntyy talouden dataa (Actuals -tietueita), jota koostetaan laskulle. Projektisopimuksen kannattavuus on yhtenä analysoinnin kulmakivenä. Talouden kontekstia voidaan pitää liiketoimintakriittisenä, koska se muodostaa talouden dataa ja päättyy laskutukseen.

Talouden kontekstin käyttöönotossa PSA:n ominaisuuksia hyödynnetään kattavasti ja opittavaa on paljon. Koska tämä kyseinen konteksti on osattava täydellisesti, ei virta välttämättä riitä seuraavan kappaleen osa-alueen käyttöönottoon, ennen kuin juuri käyttöönotettua kokonaisuutta on hetki sulateltu.

2. Projektin konteksti

Projektin konteksti takoittaa käytännössä työn osuutta. Se pitää sisällään projektinhallinnan, projektin WBS:n ja resursoinnin. Painopisteen ollessa projektien ja työn ympärillä, tavoitteena on projektinhallinta ja oikeiden ihmisten resursointi oikeisiin tehtäviin oikeaan aikaan. PSA:ssa projektien suunnittelu ja läpivienti on mahdollista ilman että talouden kontekstia tarvitsee ottaa huomioon.

Pintaa syvemmältä tarkasteltessa projektin konteksti pitää sisällään yksityiskohtaisen projektisuunnittelun ja tehtäväkohtaisen resursoinnin. PSA:n versio 3 on pienentänyt resursointiin tarvittavan työn määrää erottamalla resurssien buukkaukset ja resurssin liittämisen projektin tehtäville toisistaan. Resursointi on tästä huolimatta melko intensiivinen tehtävä ja sen ympärillä olevat toiminnallisuudet vaativat melkoisesti opettelua. Jotta resursointi on tehokasta, tulee siihen liittyvät muuttujat tuntea hyvin. Resursoinnin on myös oltava jatkuvaa ja pitkäjänteistä – hyödynnettäessä PSA:ta ei resursointia voi tehdä ”vain vähän” tai hieman sinne päin.

Projektin kontekstissa on luonnollisesti myös talouden näkökulmaan liittyviä yksityiskohtia kuten resurssien roolit ja projektien WBS:t. Projektin konteksti muuttuu raskaaksi yksityiskohtaisessa resursoinnissa ja suunnittelussa, joten projektinhallinnan ja työn ympärillä olevat toiminnallisuudet on hyvä ottaa käyttöön joko ennen talouden kontekstia tai sen jälkeen.

Yhteenveto

Lähestymistapa PSA:iin ei tarvitse olla kaikki tai ei mitään. Organisaatio voi vaiheistaa PSA:n käyttöönoton kahteen kontekstiin: talouden konteksti projektisopimusten ympärillä ja projektin konteksti työn, projektien ja resursoinnin ympärillä. Liiketoiminnan vaatimukset luonnollisesti vaikuttavat siihen miltä kulmalta käyttöönottoa lähestytään. Lähestymistavasta huolimatta PSA:n käyttöönotossa on hyvä käyttää Microsoft kumppania. Eikä mitä tahansa kumppania vaan sellaista, joka tuntee PSA:n ja sen miten sovellus toimii.

Disclaimer:
Kaikki blogikirjoitukseni ovat henkilökohtaisia mielipiteitäni, ellei toisin mainittu.

  • Share on: