Tarkvara juurutamise tuhande miili pikkune teekond algab nullfaasiga (James Monaghan)

Palju õnne. Olete otsustanud mõne tarkvara juurutada ja soovite, et see oleks edukas. Kas see on Agile või Waterfall või Lean või Scrum või midagi muud. Kuigi edukal projekti rakendamisel on selle käitamiseks omad nõuded, siis seal
on palju asju, mida tuleks enne alustamist kaaluda.

Kas sihttöömudel on piisavalt määratletud?

Uute tehnoloogiate juurutamisel kiirustades on palju lõkse, kuid need pole tavalisemad kui süsteemi juurutamise/integreerimise alustamine, arvestamata, milline näeb välja üldine suurem pilt, kui see on valmis. Liiga palju projekte on haavatud
alguses tagasi, sest mõnda olulist tehnoloogiat ei võetud üldisesse skeemi arvesse. Tänapäeva turul olevate fintechide ja häirijate puhul püüavad kõik sujuvalt üksteisega integreeruda, kuid ilma täieliku arusaamata
of kuidas Kui soovite, et nad ühendaksid ja mis põhjusel, võite hõlpsasti leida end poole peal oma sihttöömudelit ümber tegemas ja peate minema viskama kõik seni kulutatud jõupingutused ja ressursid. See on nagu katse lennukit ehitada
sellega lennata või autoga sõites rehvi vahetada. Tavalistel TOM-idel on kliendisuhete halduse (CRM) tüüpi süsteem, mida saavad kasutada kliendiga silmitsi olevad töötajad ning mis on ühenduses kliendi elutsükli haldussüsteemiga, mis sisaldab töövoo ja reeglite mootorit.
suruda vajalikud ülesanded asjaomastele inimestele andmete sisestamise/dokumentide üleslaadimise/valideerimise ja kontrollimise lõpuleviimiseks. Võib olla põhiandmete haldamise (MDM) süsteem, mida käsitletakse kirje allikana/kuldse koopiana, kuid liiga sageli on see siled
mitme koondatud või integreeritud andmesalve süsteem koos erinevate süsteemidega, mis võivad kirjeid värskendada. Sisseehitatud või integreeritud tehingute jälgimisteenustega võivad olla tehingu-/kauplemis-/laenusüsteemid. Andmete/dokumentide jaoks võivad olla kolmandad osapooled
või uudiste/negatiivsete uudiste/sõelu eesmärgil. Kõik või mõned neist võivad olla pilvepõhised või ka eeldussüsteemidel. Nii et nüüd küsin uuesti, kas olete mõelnud, kuhu see 1 uus tehnoloogia teie üldisesse TOM-i sobib ja kas see on lõplik versioon või olete
integreerida see praegusesse seadistusse, kuid plaanite seda tulevikus muuta

Kui kaua kavatsete kõigi oma praeguste süsteemide puhul neid toetada/hoida?

On levinud viga, mida tuntakse uppunud kulude eksimusena, mille kohaselt lihtsalt sellepärast, et olete süsteemile kulutanud X dollarit/eurot/naela, on liiga kaugel lüüasaamist tunnistama ja sellest loobuma. Või et see pole katki, seega ei vaja parandamist. Või et see on liiga juurdunud
praegustes süsteemides, et oleks võimalik seda eemaldada või asendada. Kui see nii on, siis olete tõenäoliselt jõudnud ühe tõrkepunktiga, ilma et oleksite sellest isegi aru saanud. Kaasaegsed tehnoloogilised lahendused on paindlikud ja neid tuleks ehitada muutusteks. Varem ühinemised/ülevõtmised
või süsteemide liitmine on sundinud tehnoloogiat integreerima ja tavaline protsess on see lihtsalt tööle panna. Neid tuleks käsitleda kui võimalusi, mis neil on, et mõelda ümber, kuidas midagi tehakse, ja püüelda tõhusama viisi poole. Teiseks
enamikul uutel tehnoloogiatel on või väidetavalt on sarnased pakkumised/moodulid/funktsioonid, nagu aruandlus, armatuurlauad, töövoog, juhtumihaldusreeglite mootorid, konfiguratsioonistuudio. Selle eesmärk on pöörduda võimalikult laia publiku poole
mõned inimesed mõtlevad: "Miks ma pean X ostma, kui Y-l see võime juba on?". Kuid seda silmas pidades, kas soovite tõesti muuta oma CRM-i tehingute jälgimise süsteemiks? Või kas teie kontosüsteem on teie MDM-i lüüsis? Või teie MDM direktorina
andmesisestuspunkt. Teate, et saate lõpuks tuhandeid kirjeid telefoninumbritega 12345678.

Personal/rollid

Mis tahes rakendamise õnnestumiseks on teil projekti mõlemal poolel määratletud rollid. Teie ja müüjad. Ilmselt sõltub see eelarvest, ulatusest ja ajakavast. Teil võib olla 4-nädalane pilvepõhine juurutus, mis nõuab 2 töötajat alates
müüja või see võib olla 10 etappi 12-nädalastest suurväljaannetest koos 2-nädalase paindliku nõuete lähenemisviisiga, mis koosnevad äri-/tooteanalüütikutest, arendajatest, teemaekspertidest, kvaliteeditagamise testijatest, kes kõik vajavad nii noorem- kui ka kõrgemaid rolle, projekti
iga ärivaldkonna/piirkonna/jurisdiktsiooni juhid ja programmijuht, kes seda kõike jälgib. Lisage projekti sponsor ja saate hõlpsalt aru, miks ettevõttetarkvara läheb mõnikord liiga kalliks. See on ka enne, kui arvestate töötajate arvu
mille peate sobitamiseks eraldama. Ärge unustage, et teie selles projektis osalevad töötajad on pikka aega oma igapäevastest ülesannetest eemal. Oluline on veenduda, et müüja töötajad on kogenud ja ei ole olnud
hiljuti tööle võetud, et rahuldada teie projekti nõudlust.

Teine kaalutlus on partnerlusmudel. Paljudel väljakujunenud müüjatel on sertifitseeritud partnerid, mõned butiigifirmad ja mõned suurest neljast, keda saab samuti koostada juurutamist abistamiseks, kuid neil on ka hind.

Andmeedastus

Üks uue tarkvara osa peamistest teemadest on andmetele juurdepääsu ja/või andmete migratsiooni kaalumine. Kui uus süsteem hakkab vastavalt vajadusele päringuid tegema teie praegusest andmebaasist või andmebaasidest, millal see juurdepääsu saab, millistel kasutajatel on millised õigused
Kas sellele juurdepääsuks on juurdepääs kirjutuskaitstud või saavad kasutajad redigeerida või uusi kirjeid luua ning millistel süsteemidel on nende muudatuste tegemisel prioriteetne järjekord? Mis siis, kui teine ​​süsteem proovib muudatusi teha, kui teine ​​kasutaja
teie uuest tehnoloogiast redigeerib praegu seda? Kas see tähendab nüüd, et kõik andmete muutmise taotlused tuleks suunata läbi selle uue tehnoloogia? Mis juhtub, kui kõik uued tehnoloogiad taotlevad sama prioriteetsusjärjekorda? Need on mõeldud ainult aktiivsete kliendiregistrisüsteemide jaoks.
Kuidas on lood uue ühtse konsolideeritud süsteemi loomisega? Kas peaksite kasutama suure paugu lähenemisviisi, et viia kõik andmed üle esimesel päeval? Kujutage ette riske. Mis saab üleminekuperioodist, näiteks kui ülevaatus on kavandatud, saate ülevaatuse läbiviimiseks ühest või mitmest allikast
ja seejärel postitage puhas kirje uude keskandmebaasi. See võimaldaks selle asemel migratsiooni 12–18 kuu jooksul. See ei ole kõigile sobiv lähenemisviis. See on kõik enne, kui hakkate kaaluma duplikaatide käsitlemist.

Integrations

Kui kaalute oma ökosüsteemi uue tehnoloogia lisamist, peate veenduma, et see töötab sujuvalt teie praeguse seadistusega. Sellel on algselt kaks võimalust: kas uus lisand konkreetse probleemi lahendamiseks või olemasoleva süsteemi asendamine
või süsteemid paigas. Mõlemal juhul soovite tagada, et sellel on juurdepääs asjakohastele süsteemidele, mida ta vajab nii üles- kui ka allavoolu tarbimiseks. Samuti peate olema kindel, et kogu kasutuselt kõrvaldatava süsteemi torustikku saab hooldada.
Samuti on küsimus lubade andmise kohta, mis jäetakse pidevalt tähelepanuta. Kasutaja juurdepääsu juhtimine, et määrata, millised õigused on kasutajatel uue tehnoloogia jaoks andmete jaoks, millele sellel on juurdepääs, tagades samal ajal ka administraatoriõiguste nõuete puudumise.
Kuid kui lisate tulevikus uuema tehnoloogia, kas peate sel hetkel kõigi ajalooliste süsteemide juurdepääsukontrolli täpsustama? Nagu ka ülal, ärgem unustagem vajadust kindlaks teha, millisel tehnoloogial on andmete muudatuste/värskenduste prioriteetsus. Muidu
kuidas veenduda, et süsteem A teeb muudatuse täna, süsteem B muudab selle homme tagasi ja süsteem A proovib järgmisel päeval uuesti.

Juurdepääs süsteemile – Infoseci eeskirjad

Kas olete kaasanud vastavad meeskonnad, et pakkuda õigeaegselt ressursse ja juurdepääsu asjakohastele süsteemidele? Kui plaanite oodata viimase hetkeni, enne kui taotlete luba keskkonnale või juurdepääsule andmebaasile vms. Teie
võib lihtsalt avastada, et teie sihtkuupäevad on ootamatult saavutamatud.

Ostjad vs kasutajad

Kas uue tehnoloogia lõppkasutajad on otsustusprotsessi kaasatud? Mis mõtet on teha otsust teiste kasutajate nimel, kui nad lõpuks otsustavad, et ehitatav ei sobi nende eesmärkidele. Võitlus äri ja
IT on pidev, mis esineb kõikjal ja kõigub edasi-tagasi selles osas, kes saab otsustada. Süsteemi ülesehituselt oodatakse liigagi sageli, et see lahendaks iga kasutaja jaoks suurepäraselt kõik probleemid. Tehnoloogia üleprojekteerimine, et lahendada 100%
on imetlusväärne, kuid lõppkokkuvõttes ressursimahukas ettevõtmine. Esialgne eesmärk peaks olema lahendada enamiku jaoks ja oodata eduka tarnimiseni, enne kui proovite äärejuhtumeid. See viimane 20% või 10% emissioonidest ei tohiks olla omandamise põhieesmärk
tehnoloogia, kuid liiga sageli muutub see kõike tarbivaks. Küsimus, mida endalt küsida, on, mis on 1. päeval lõplikult nõutav, ja piirake oma valikud alamhulgaga, kuna vaikevastus ilma on alati, alati, kõik.

Seega, kui vaatame nüüd, mida projekti edukaks rakendamiseks arvesse võtta, peame mõistma, et enne alustamist on rohkem olulisi asju, mis tuleb kaasata. Need mõjutavad ka otsust, millist tarkvara esimesena valida
koht. Kõik, mis hiilgab, pole kuld. Veenduge, et see, mida valite, sobiks kõigi kaalutluste jaoks, mitte ainult ühe oodatud lõpptulemuse jaoks.