Ohjelmiston käyttöönottomatka tuhat mailia alkaa vaiheesta nolla (James Monaghan)

Onnittelut. Olet päättänyt ottaa käyttöön ohjelmiston ja haluat sen onnistuvan. Onko se Agile tai Waterfall, Lean tai Scrum tai jotain aivan muuta. Vaikka onnistuneella projektin toteutuksella on omat vaatimuksensa sen toteuttamiselle
on monia asioita, jotka on otettava huomioon ennen aloitusta.

Onko tavoitetoimintamalli määritelty riittävästi?

Uuden teknologian käyttöönoton kiireessä on lukuisia sudenkuoppia, mutta mikään ei ole yleisempää kuin järjestelmän käyttöönoton/integroinnin aloittaminen pohtimatta, miltä kokonaiskuva näyttää sen valmistuttua. Liian monet projektit ovat haavoittuneet
alkuun, koska jotakin keskeistä teknologiaa ei otettu huomioon kokonaissuunnitelmassa. Kaikkien markkinoilla olevien fintechien ja häiriöiden myötä kaikki pyrkivät integroitumaan saumattomasti keskenään, mutta ilman täydellistä ymmärrystä
of miten haluat heidän yhdistävän ja mistä syystä, voit helposti huomata itsesi tekemässä Target Operating Model -malliasi uudelleen puolivälissä ja joutuvasi heittämään pois kaikki tähän mennessä käyttämäsi vaiva ja resurssit. Se on kuin yrittäisi rakentaa konetta samalla
lennät sillä tai vaihda auton rengas ajon aikana. Tyypillisissä TOM:issa on asiakassuhteiden hallinta (CRM) -tyyppinen järjestelmä, jota asiakasta kohtaava henkilökunta voi käyttää, ja se muodostaa yhteyden asiakkaan elinkaaren hallintajärjestelmään, joka sisältää työnkulun ja sääntömoottorin.
työntämään tarvittavat tehtävät asianomaisille henkilöille tietojen syöttämisen/asiakirjojen latauksen/vahvistuksen ja vahvistuksen suorittamiseksi. Saattaa olla Master Data Management (MDM) -järjestelmä, jota pidetään tietueen lähteenä/kultaisena kopiona, mutta aivan liian usein tämä on siled.
järjestelmä, jossa on useita yhdistettyjä tai integroituja tietovarastoja, joissa on erilaisia ​​järjestelmiä, jotka voivat päivittää tietueita. Voi olla Transaction/Kaupa/Lainausjärjestelmiä, joissa on sisäänrakennettu tai integroitu tapahtumavalvontapalvelu. Tietojen/asiakirjojen toimittajat voivat olla kolmannet osapuolet
tai uutisia/negatiivisia uutisia/seulontatarkoituksiin. Kaikki tai osa näistä voi olla pilvipohjaisia ​​tai myös lähtökohtaisia ​​järjestelmiä. Joten nyt taas kysyn sinulta, oletko miettinyt, mihin tämä 1 uusi teknologia sopii kokonaisuuteen TOM:iin ja onko se lopullinen versio vai oletko sinä
integroimalla sen nykyiseen asetukseen, mutta aiot muuttaa tätä tulevaisuudessa

Kuinka kauan aiot tukea/pitää niitä kaikissa nykyisissä järjestelmissäsi?

On olemassa yleinen virhe, joka tunnetaan nimellä Sunk Cost Fallacy, jonka mukaan vain siksi, että olet käyttänyt X dollaria/euroa/puntaa järjestelmään, on liian kaukana tunnustaa tappiota ja romuttaa se. Tai ettei se ole rikki, joten ei vaadi korjausta. Tai että se on liian juurtunut
nykyisissä järjestelmissä, jotta se voidaan poistaa tai vaihtaa. Jos näin on, olet todennäköisesti päätynyt yhteen epäonnistumiseen tietämättäsi sitä. Nykyaikaiset teknologiaratkaisut ovat joustavia ja niitä tulee rakentaa muutosta varten. Aiemmin fuusiot/kaupat
tai järjestelmien yhdistäminen on pakottanut teknologian integroimaan ja tavallinen prosessi on vain saada se toimimaan. Näitä tulee käsitellä mahdollisuuksina, joiden avulla he voivat harkita uudelleen, miten jotain tehdään, ja pyrkiä tehokkaampaan tapaan. Toinen
Useimmilla uusilla teknologioilla on tai väitetään olevan samanlaisia ​​tarjouksia/moduuleja/ominaisuuksia, kuten raportointi, kojelaudat, työnkulku, tapausten hallintasääntömoottorit, konfigurointistudio. Tämän tavoitteena on houkutella mahdollisimman laajaa yleisöä
Jotkut ihmiset ajattelevat "Miksi minun pitää ostaa X, kun Y:llä on jo se kyky?". Mutta tämä mielessä, haluatko todella muuttaa CRM:stäsi tapahtumien seurantajärjestelmän? Tai tilijärjestelmäsi MDM:n yhdyskäytävään? Tai MDM:si päämiehenä
tietojen syöttöpiste. Tiedät, että saat tuhansia tietueita, joiden puhelinnumerot ovat 12345678.

Henkilöstö/roolit

Jotta toteutus onnistuisi, sinulla on määritellyt roolisi projektin molemmilla puolilla. Sinun ja myyjät. Se riippuu tietysti budjetista, laajuudesta ja aikataulusta. Sinulla voi olla 4 viikon pilvipohjainen toteutus, joka vaatii 2 työntekijää
toimittaja tai se voi olla 10 vaihetta 12 viikon suurista julkaisuista ja 2 viikon ketterä vaatimuslähestymistapa, joka koostuu liiketoiminta-/tuoteanalyytikoista, kehittäjistä, aiheen asiantuntijoista, laadunvarmistustestajista, jotka kaikki tarvitsevat sekä juniori- että seniorirooleja, projekteja
kunkin toimialan/alueen/lainkäyttöalueen johtajat ja ohjelmapäällikkö valvomaan kaikkea. Valitse projektin sponsori, niin näet helposti, miksi yritysohjelmistot tulevat kalliiksi, joskus kohtuuttoman kalliiksi. Tämä on myös ennen kuin harkitset henkilöstön määrää
jotka sinun on kohdistettava vastaamaan. Älä unohda, että tähän projektiin osallistuvat työntekijäsi ovat poissa päivittäisistä tehtävistään huomattavan pitkän ajan. On tärkeää varmistaa, että myyjän henkilökunta on kokenut ja ei ole ollut
äskettäin palkattu vastaamaan projektisi kysyntään.

Toinen näkökohta on kumppanuusmalli. Monilla vakiintuneilla toimittajilla on sertifioituja kumppaneita, joitain putiikkeja ja osa neljästä suuresta, jotka voidaan myös laatia auttamaan toteutuksissa, mutta heillä on myös hinta.

Tiedonsiirto

Yksi uuden ohjelmiston tärkeimmistä teemoista on tietojen käyttö ja/tai tiedonsiirto. Jos uusi järjestelmä kyselee tarpeen mukaan nykyistä tietokantaasi tai tietokantojasi, milloin se saa pääsyn, millä käyttäjillä on mitkä oikeudet
onko pääsy vain luku -käyttöön vai voivatko käyttäjät muokata tai luoda uusia tietueita ja millä järjestelmillä on prioriteettijärjestys näiden muutosten tekemiselle? Entä jos toinen järjestelmä yrittää tehdä muutoksen toisen käyttäjän ollessa kyseessä
uudesta tekniikastasi muokkaako sitä parhaillaan? Tarkoittaako tämä nyt sitä, että kaikki tietojen muokkauspyynnöt tulee reitittää uuden tekniikan kautta? Mitä tapahtuu, kun kaikki uudet teknologiat vaativat samaa tärkeysjärjestystä? Nämä ovat vain aktiivisia asiakasrekisterijärjestelmiä varten.
Entä uuden yhtenäisen järjestelmän luominen? Pitäisikö sinun ottaa big bang -lähestymistapa siirtääksesi kaikki tiedot ensimmäisenä päivänä? Kuvittele riskit. Entä siirtymäkausi, esimerkiksi kun tarkistus on ajoitettu, hankit yhdestä tai useammasta lähteestä tarkastelun suorittamiseksi
ja lähetä sitten puhdas tietue uuteen keskustietokantaan. Se sallisi sen sijaan 12–18 kuukauden siirtymisen. Se ei ole yksi koko sopii kaikille. Siinä kaikki ennen kuin alat harkita kaksoiskappaleiden käsittelyä.

Integraatiot

Kun harkitset uuden teknologian lisäämistä ekosysteemiisi, sinun on varmistettava, että se toimii saumattomasti nykyisen järjestelmän kanssa. Tässä on aluksi kaksi vaihtoehtoa, joko uusi nettolisäys tietyn ongelman ratkaisemiseksi tai olemassa olevan järjestelmän tilalle
tai järjestelmät käytössä. Joka tapauksessa haluat varmistaa, että sillä on pääsy asiaankuuluviin järjestelmiin, joita se tarvitsee sekä alku- että loppupään kulutukseen. Sinun on myös oltava varma siitä, että kaikki poistettavan järjestelmän nykyiset putkistot voidaan huoltaa.
On myös kysymys luvista, joka jää jatkuvasti huomiotta. Käyttäjän käyttöoikeuksien hallinta määrittää, mitä käyttöoikeuksia käyttäjillä on uudelle teknologialle niille tiedoille, joihin sillä on pääsy, ja varmistaa samalla, ettei järjestelmänvalvojan lupavaatimuksia ole.
Mutta kun lisäät uudemman teknologian tulevaisuudessa, tarvitseeko sinun parantaa kaikkien historiallisten järjestelmien kulunvalvontaa siinä vaiheessa? Kuten edellä, älkäämme unohtako tarvetta määrittää, millä tekniikalla on prioriteettijärjestys tietojen muutoksille/päivityksille. Muuten
miten varmistat, että järjestelmä A tekee muutoksen tänään, järjestelmä B peruuttaa sen huomenna ja järjestelmä A yrittää uudelleen seuraavana päivänä.

Järjestelmän käyttöoikeus – Infosec-käytännöt

Oletko palkannut asianomaiset tiimit sisäisesti tarjoamaan resursseja ja pääsyn asiaankuuluviin järjestelmiin oikea-aikaisesti? Jos aiot odottaa viimeiseen hetkeen ennen kuin pyydät lupaa ympäristöön tai tietokantaan jne. Sinä
saattaa vain huomata, että tavoitepäivämääräsi ovat yhtäkkiä saavuttamattomia.

Ostajat vs käyttäjät

Ovatko uuden teknologian loppukäyttäjät mukana päätöksentekoprosessissa? Mitä järkeä on tehdä päätös muiden käyttäjien puolesta, jos he lopulta päättävät, että rakennettava ei sovi heidän tarkoituksiinsa. Taistelu liiketoiminnan ja
IT on jatkuvaa, jota esiintyy kaikkialla ja heilahtelee edestakaisin sen suhteen, kuka saa päättää. Järjestelmän suunnittelun odotetaan aivan liian usein ratkaisevan kaikki ongelmat jokaisen käyttäjän kohdalla täydellisesti. Teknologian ylisuunnittelu, jotta se voidaan ratkaista 100 %
on ihailtavaa, mutta lopulta resursseja vaativa yritys. Alkuperäisenä tavoitteena tulisi olla ratkaisu enemmistön puolesta ja odottaa onnistuneeseen toimitukseen ennen kuin yritetään reunatapauksia. Viimeisten 20 tai 10 prosentin liikkeeseenlaskuista ei pitäisi vastata pääasiallista hankinnan tarkoitusta
tekniikkaa, mutta aivan liian usein se kuluttaa kaikkea. Kysymys, joka sinun on kysyttävä itseltäsi, on, mitä ehdottomasti vaaditaan päivänä 1, ja rajoita vaihtoehtosi osajoukkoon, koska oletusvastaus ilman on aina, aina, kaikki.

Nyt kun tarkastelemme, mitä tulee ottaa huomioon, jotta projektin toteuttaminen onnistuisi, meidän on ymmärrettävä, että ennen aloittamista on enemmän tärkeitä asioita, jotka on otettava mukaan. Nämä vaikuttavat myös päätökseen, mikä ohjelmisto valitaan ensimmäisessä vaiheessa
paikka. Kaikki mikä kiiltää ei ole kultaa. Varmista, että valitsemasi seikka sopii kaikkiin näkökohtiin eikä pelkästään yhteen odotettuun lopputulokseen.