Reális ServiceNow-bevezetési időkeret közepes vállalatoknak

Kérdezzen meg három ServiceNow-partnert, mennyi időt vesz igénybe egy bevezetés, és három különböző választ fog kapni, mind magabiztosan. Az őszinte ServiceNow-bevezetési időkeret egy közepes vállalatnál szűkebb, mint amit a szállítók beismernek, és szélesebb, mint amit a vevők remélnek. Ez az, ami valójában történik, hétről hétre, és mi különbözteti meg a tiszta éles indulást egy elsodródó projekttől.

Hova megy valójában az idő

Az ösztönös feltételezés szerint a build a leghosszabb rész. Nem az. Egy tipikus, közepes méretű HRSD vagy ITSM-bevezetésnél maga a build körülbelül öt-hat hetet vesz igénybe. A naptár többi részét döntések, integrációk, tesztelés és az emberi valóság – a megfelelő emberek egy térbe ültetése – emészti fel.

Egy 300 és 5 000 fő közötti vállalat fókuszált projektje általában ebbe a tartományba esik:

• 1-2. hét: hatókör-meghatározás, kickoff, discovery jóváhagyása, környezet-hozzáférés
• 3-8. hét: iteratív build kétheti sprintekben
• 9-10. hét: integráció-keményítés és felhasználói átvételi tesztelés
• 11-12. hét: képzés, élesítési próba, éles bevezetés
• 13. héttől: hypercare és a finomítások első hulláma

Tizenkét hét egy komoly hatókör alsó határa. Bármi rövidebb vagy újradesign, vagy olyan projekt, amely csendben elcsúszik az átvételi kritériumain.

Milyen hatókör fér bele valójában 12 hétbe

A vevők hajlamosak azt feltételezni, hogy a hatókör egy szabadon tekerhető gomb. Nem az. Valódi határ van aközött, amit egy senior csapat 12 hét alatt szállíthat, és amihez több időre van szükség.

Egy 12 hetes HRSD-bevezetés általában tartalmazza a HR-ügykezelést, egy márkás munkavállalói portált, négy-hat életciklus-eseményt, mint a beléptetés és kiléptetés, a HR-biztonsági modellt, és egy mester-adat integrációt a SuccessFactors vagy Workday rendszerrel. Ez sok érték, de egyben a plafon is.

Ha emellett Employee Document Managementet, e-aláírás-integrációt, komplex több országos adóáramlásokat vagy egy második HR-rendszert is szeretne a platformra táplálni, a naptár megnyúlik. Nem lineárisan nyúlik meg. Minden extra integráció olyan tesztelési komplexitást ad hozzá, amely végighullámzik a teljes terven.

Ugyanez a minta érvényes az ITSM-re. Az Incident, Request, Problem, Change, a CMDB-alapok és egy discovery-integráció belefér 12 hétbe. Adjon hozzá SecOps-t, Field Service-t vagy egy nagy CMDB-tisztítást, és 20 hetes projektet kap, nem 14 hetest.

Ha még mérlegeli a hatókör-beszélgetést, a vevői útmutatónk a ServiceNow-partner kiválasztásához kifejti, miben kell megegyezni az aláírás előtt.

A döntések, amelyek valójában meghatározzák a naptárt

Öt döntés, amelyet az első két hétben kell meghozni, dönti el a ServiceNow-bevezetési időkeret nagy részét. Ha ezeket jól meghozza, a terv többi része általában megmarad.

Az adatmodell. Hogyan lesznek a munkavállalók, helyszínek és szervezetek ábrázolva? A Department és Cost Center natív mezőket fogja használni, vagy kibővíti a user táblát? Ez részletnek tűnik. Nem az. Minden riport, minden irányítási szabály és minden integráció ettől függ.

A biztonsági modell. A ServiceNow ACL-eket, HR-biztonsági policy-kat, kontextuális biztonságot és szerepköröket ad. A rossz rétegzés vagy szivárgásokat vagy lezárásokat hoz létre, és a megváltoztatása éles indulás után fájdalmas. Egy senior architektnek az 1. héten kell rajzolnia a modellt, nem a 6. héten.

Az integrációs megközelítés. Valós idejű, kötegelt, vagy hibrid. Push vagy pull. Mid-table vagy közvetlen table. A válasznak az üzlet valódi SLA-igényéhez kell illeszkednie, nem a partner legegyszerűbb mintájához. Ha ezt rosszul választja, a projekt során a saját integrációs rétegével harcol.

A portálélmény. Gyári, könnyen témázott, vagy egyedi. Mindegyik választás védhető. Az egyedi portálok rendszeresen háromszor hosszabb ideig tartanak, mint amit a vevők várnak, az akadálymentesség, lokalizáció és tartalomkezelési munka miatt, amit senki nem szab meg előre.

Az irányítási kadencia. Ki hagyja jóvá a változásokat, milyen gyakran és milyen csatornán keresztül. Egy közepes méretű vállalat, amely úgy tesz, mintha Fortune 500-as irányítást igényelne, megfojtja a projektet. Egy vállalat, amely teljesen kihagyja az irányítást, audit nyom nélkül érkezik az éles indulásra.

Hol lassulnak a projektek anélkül, hogy bárki észrevenné

A 3. heti sprint-szemle általában jól érződik. A 7. heti sprint-szemle az, ahol a valóság betolakodik. Néhány minta megbízhatóan okoz projekt-elsodródást, és könnyen felismerhetők, ha tudja az alakjukat.

Az érintettek elérhetősége a leggyakoribb. Az országos HR-vezetők, bérszámfejtési menedzserek és IT-üzemeltetési emberek nem a projekten dolgoznak teljes munkaidőben. Ha egy partner nem foglalja le a naptárukat az 1. héten, ezek a jóváhagyások két-három héttel később jelennek meg. A build-csapat vár. A költség nő.

A második az integráció-felfedezés. A partnerek gyakran dokumentáció alapján adnak árajánlatot SuccessFactors- vagy Workday-integrációra, nem az ügyfél valódi konfigurációja alapján. Az első valódi adatexport az a pillanat, amikor a projekt vagy kitart, vagy csúszik. Egy jó partner az 1. héten kér sandbox-exportot, nem a 6. héten.

A harmadik a tesztadat. Az átvételi tesztelés akkor bukik meg, amikor a tesztkörnyezet nem tartalmaz reális munkavállalói rekordokat, valódi szervezeti hierarchiákat és reprezentatív keresztmetszetet a peremesetekről. Azok a partnerek, akik a tesztadatot utólagosan kezelik, minden alkalommal két hetet veszítenek rajta.

A negyedik a „csak még egy dolog”. A közepes méretű projektek ritkán buknak meg egy nagy változás miatt. Húsz apró kiegészítés miatt buknak meg, amelyek mindegyike ésszerűnek tűnt. Egy írásos változás-vezérlési napló fegyelme, akár egy egyszerű is, több időt spórol meg, mint bármilyen módszertan.

Hogyan néz ki a „gyors”, amikor valódi

A gyors bevezetés nem elsietett bevezetést jelent. Olyan projektet jelent, ahol a megfelelő döntéseket korán hozzák meg, és el is maradnak megdöntve.

A keresendő jelek konkrétak. Működő szoftver a 3. héten, nem diavetítések. Egy valódi integráció, amely adatokat továbbít körbe az 5. héten. Az átvételi tesztszkripteket az üzlet írja, nem a partner, a 8. hét előtt. Élesítési próba a 11. héten. Egy éles bevezetés, ahol senki nem lepődik meg, mert mindenki látta már a platformot két hónapig működni.

Abból is meg tudja állapítani, hogy a partner hogyan reagál a súrlódásra. A gyors projektekben is vannak problémák. A különbség abban van, hogyan oldódnak meg. Egy gyors partner megnevezi a problémát a következő standupon, két opciót javasol, és a csapat dönt. Egy lassú partner workshopot ütemez, hogy a következő héten megbeszéljük.

A sebesség költsége ritkán pénz. A döntésképesség. Azok a közepes méretű vállalatok, amelyek védik döntéshozóik idejét és felhatalmazzák a partnert a mozgásra, érnek időben az éles indulásra.

Mikor a hosszabb időkeret a helyes döntés

Néha az őszinte válasz az, hogy a 12 hét rossz. Néhány helyzet több futópályát igényel.

Ha egy meglévő HR- vagy ITSM-platformot vált le aktív munkafolyamatokkal, az adatmigráció és párhuzamos futtatás négy-nyolc hetet ad hozzá. Ha több országban működik különböző jogszabályi követelményekkel, a konfiguráció megszorzódik. Ha a CMDB a szélesebb IT-átalakítás alapja, nem siettetheti az adatminőségi munkát. Ha az érintettek valóban megoszlanak a szakszervezeti, üzemi tanácsi és vállalati irányítás között, nem szűkítheti a jóváhagyási ciklust.

Ezekben az esetekben a helyes megközelítés a fázisbontás. Vigye élesbe az alapplatformot 12 hét alatt, igazolja az értéket, majd bővítse a következő negyedévben. Azok a vállalatok, amelyek mindent egy projektben próbálnak szállítani, ritkán szállítanak bármit is jól.

A hosszabb időkeret költségvetésre gyakorolt hatásáról a ServiceNow-bevezetési költségek közepes vállalatokról szóló írásunk levezeti a matekot.

A lényeg

Egy reális ServiceNow-bevezetési időkeret egy fókuszált, közepes méretű bevezetésnél 12-14 hétbe fér bele, amikor a partner senior, a döntéseket korán hozzák meg, és a hatókör tiszteletben tartja, amit a naptár valójában megtartani képes. Azok a projektek, amelyek elcsúsznak, szinte sosem műszaki okok miatt csúsznak el. Azért csúsznak el, mert valaki a 2. héten elhalasztott egy döntést, és a költsége a 10. héten jelent meg.

Ha egy ajánlat előtt ül, amely vagy hat hetet, vagy harmincat ígér, mindkettő jelzés. A hat hét demó-színházat jelent. A harminc hét egy túl-mérnöki megközelítést jelent egy olyan problémához, amelynek nincs rá szüksége. A legtöbb közepes méretű vállalat számára a helyes válasz középen van, és közelebb, mint amit a legtöbb szállító be akar ismerni.

A Milic Media Kft.-ről. Közvetlenül végfelhasználói ügyfeleknek szállítunk ServiceNow-bevezetéseket, senior gyakorlókkal a billentyűzeten és alvállalkozói build-csapatok nélkül. Ha másodvéleményt szeretne egy időkeretről, amelyre ajánlatot kapott, küldje el az SOW-t, és elolvassuk.