Emne 5.4 — Virksomhedsressourceplanlægning (ERP)

I én sætning: Virksomhedsressourceplanlægning (ERP) er det integrerede back office-system — økonomi, HR, løn, indkøb og forsyningskæde — der fungerer som organisationens system of record for penge, folk og lager og i det stille understøtter næsten alle arbejdsformer i denne bog.

Hvorfor det er vigtigt i sundhed og pleje#

Digital transformation i sundhed og pleje får sin opmærksomhed fra kliniske systemer — den elektroniske patientjournal, den fælles omsorgsjournal, patientappen. Men intet af det kører uden det uglamourøse back office nedenunder. Personale skal rekrutteres, planlægges og aflønnes; leverandører skal kontraheres og afregnes; lægemidler, udstyr og forbrugsvarer skal bestilles og spores; og hver krone skal gøres rede for mod stramt begrænsede offentlige budgetter. ERP er der, hvor det sker, og når det svigter, er konsekvenserne øjeblikkelige: uudbetalt løn, gået i stå indkøb, uafstemte regnskaber og en økonomifunktion, der flyver i blinde.

Skalaen er enorm. NHS Shared Business Services (NHS SBS), et joint venture oprettet i 2004, driver en national Oracle-baseret økonomi- og indkøbsplatform, der behandler millioner af fakturaer og håndterer en meget stor andel af de samlede NHS-udgifter for over hundrede NHS-organisationer (se Centrale kilder). ERP-beslutninger er derfor ikke en nichebekymring for økonomi — de former arbejdsstyrkestyring, kontrol med offentlige midler og den datakvalitet, enhver efterfølgende analyse afhænger af. For en direktør er ERP både en grundlæggende muliggører og et af de mest risikable programmer, en organisation nogensinde vil forsøge.

Kernebegreber#

Hvad ERP er. En enkelt, integreret ERP-pakke af moduler, der deler én database og ét sæt stamdata og dækker virksomhedens kerneadministrative processer: hovedbog og finansregnskab, kreditor- og debitorstyring, HR og arbejdsstyrkeadministration, løn, indkøb (purchase-to-pay), lager og forsyningskæde og i stigende grad planlægning og analyse (FP&A — financial planning and analysis). Pointen med "integration" er, at en indkøbsordre, en varemodtagelse og en faktura afstemmes automatisk, fordi de er de samme data, ikke tre kopier.

System of record. ERP er den autoritative kilde til finans- og ressourcedata — hovedbogen, revisorer stoler på, og lønnen, personalet aflønnes fra. Andre systemer kan holde operationelle kopier, men ERP’en er sandhedsversionen for penge og ofte for den materielle HR-registrering.

Stamdata. De fælles referencedata, alt andet afhænger af: kontoplanen, omkostningssteder, leverandørregistre, varekataloget og medarbejderregistre. Stamdata er den stille determinant for ERP-succes — beskidte, duplikerede eller inkonsistente stamdata ødelægger rapportering, bryder afstemning og undergraver enhver proces bygget ovenpå.

Almindelige platforme i sundhed og den offentlige sektor. I NHS og den bredere britiske offentlige sektor er de vigtigste ERP-platforme Oracle (dominerende, i høj grad gennem NHS SBS og konsortier som NEP), SAP, Unit4 (bredt valgt af hospitaler, universiteter og lokale myndigheder) og Microsoft Dynamics 365. Lokale myndigheder, der leverer voksensocialpleje, kører den samme klasse af systemer til deres økonomi og indkøb. Den moderne retning er cloud-ERP (software-as-a-service) frem for installationer på stedet.

Fælles tjenester. I stedet for at hver organisation driver sin egen ERP deler mange en fælles platform og en fælles back office-drift — NHS SBS-modellen og NHS-konsortier, der kører skabelonbaserede Oracle Cloud-instanser. Fælles tjenester bytter noget lokal fleksibilitet for standardisering, stordriftsfordele og en mindre kollektiv implementerings- og supportbyrde.

Bedste praksis#

1. Behandl stamdata som fundamentet, ikke en eftertanke. Rens og afdubler kontoplanen, leverandørregistre, varekatalog og medarbejderdata før migrering, og sørg for løbende dataforvaltningsejerskab. De mest skadelige ERP-svigt kan spores til dårlige stamdata, ingen mængde god software kan rette; en datakvalitetsarbejdsstrøm er ikke valgfri.

2. Tag standarden i brug; minimér tilpasning. Konfigurér ERP’en til leverandørens eller konsortiets standardskabelon, hvor processen reelt er commodity, og forbehold skræddersyede ændringer til den sjældne ægte differentiator. Kraftig tilpasning puster omkostningen op, ødelægger opgraderbarheden og genimporterer den lokale uorden, I forsøgte at slippe for — især cloud-ERP straffer "få det til at ligne vores gamle system"-instinktet.

3. Design integrationerne bevidst. ERP står ikke alene: den skal udveksle data med arbejdsstyrke- og e-vagtplansystemer, kliniske og apotekssystemer (til lager og kostpriser), bank og analyse. Kortlæg hver grænseflade, eje datakontrakterne, og test dem fra ende til anden — løn fodret af en ødelagt vagtplansfeed udbetaler folk forkert, og det er et tillidsødelæggende svigt.

4. Kør ERP-udskiftning som et større program med forandringsledelse i kernen. En ERP-implementering er et forretningsforandringsprogram, der tilfældigvis involverer software, ikke et it-projekt. Ressourcesæt det med programdisciplin (se emne 5.2 — Programledet arbejde) og en ægte forandringsledelsesindsats (se emne 8.1 — Forandringsledelse), fordi det meste ERP-besvær er mennesker og proces, ikke teknologi.

5. Vær ærlige om ERP-programmets risiko. Store ERP-implementeringer har et velfortjent ry for at overskride tid og pris og levere under på gevinst; fejllitteraturen er omfattende og går på tværs af sektorer. Byg kontingens ind, undgå en big-bang-go-live, hvor en faseopdelt tilgang er mulig, og lad aldrig en optimistisk tidsplan overtrumfe parathed — en skredet dato kan rettes, en fejlslagen løn- eller hovedbogsovergang kan ikke.

6. Beskyt go-live og perioden efter. Planlæg dataovergang, parallelkørsel, afstemning og hypercare-support i detaljer, og modstå presset for at forkorte dem. Ugerne omkring go-live er, når leverandører forbliver ubetalte, og månedsafslutningen bryder sammen; en veltilbemandet stabiliseringsperiode er forskellen mellem en ujævn start og en offentlig krise.

7. Brug ERP som ressourcestyringens system of record — og design arbejdsformer omkring den. Lad ERP’en være den enkelte kilde til omkostningssteder, budgetter, indkøbsgodkendelser og normering, og afstem jeres driftsprocesser til den frem for at vedligeholde skygge-regneark. Skyggesystemer genindfører den fragmentering, ERP findes for at fjerne, og lader i det stille datakvaliteten rådne.

8. Afvej fælles tjenester og cloud-ERP på deres reelle afvejninger. Fælles platforme (NHS SBS, NEP-lignende konsortier) og cloud-ERP tilbyder standardisering, skala, løbende opgraderinger og en lettere lokal byrde, til prisen af noget lokal fleksibilitet og en afhængighed af udbyderen. Vælg bevidst: for de fleste organisationer opvejer standardiseringsgevinsten den tabte fleksibilitet, men beslutningen bør træffes med åbne øjne, ikke som standard.

Spørgsmål at drøfte med dit team#

1. Hvor sikre er vi — med evidens, ikke forsikring — på kvaliteten af de stamdata, vi ville tage med ind i en ny ERP, og hvem ejer dem efter go-live? Stamdata er den stille determinant for ERP-succes, men behandles rutinemæssigt som en migreringsopgave frem for det fundament, det er, så dette spørgsmål tester, om teamet har set grundigt på kontoplanen, leverandørregistre, varekatalog og medarbejderstamdata eller blot håber, de er rene. I en sundheds- og plejesammenhæng er indsatsen konkret: duplikerede leverandørregistre bryder purchase-to-pay-afstemning, et medarbejderregister, der er uenigt med ESR, udbetaler folk forkert, og en inkonsistent kontoplan ødelægger enhver efterfølgende finansrapport, bestyrelsen og revisorer støtter sig til. Spændingen, der er værd at debattere, er trækket mod at migrere i bulk for at nå en dato versus de måneder af uglamourøs rensning og afduplikering, god praksis kræver, og om nogen senior er villig til at finansiere en datakvalitetsarbejdsstrøm, der ikke viser noget synligt produkt. Et stærkt svar citerer faktiske tal — hvor mange duplikerede leverandører, hvor mange uafstemte medarbejderregistre — frem for en generel fornemmelse af, at "dataene for det meste er fine". Det bør også nævne den person og det styringsmekanisme, der er ansvarlig for stamdatakvaliteten efter go-live, fordi data, der renses én gang og derefter efterlades ustyrede, blot driver tilbage til uorden.

2. Hvor er vi reelt fristede til at tilpasse ERP’en for at bevare en velkendt proces, og er den forskel en reel differentiator eller blot den gamle uorden, vi forsøger at slippe for? Kraftig tilpasning er den klassiske ERP-fælde i virksomheder: den puster omkostningen op, ødelægger opgraderbarheden og genimporterer netop den lokale fragmentering, programmet skulle fjerne, og især cloud-ERP straffer instinktet til at "få det til at ligne vores gamle system". Dette spørgsmål beder teamet om at være specifikt om, hvilke processer de vil insistere på at bøje softwaren til, og at begrunde hver mod en hård test af, om den er en ægte differentiator eller blot komfortabel vane. Debatten betyder noget, fordi næsten hver back office-proces i sundhed og pleje — hovedbog, indkøbsgodkendelser, lønadministration — reelt er commodity, så den ærlige standard bør være at tage leverandørens eller konsortiets standardskabelon i brug og ændre processen, ikke softwaren. Konkrete vinkler inkluderer at liste hver ønsket tilpasning og spørge, hvem der drager fordel, hvilken opgraderingsomkostning den låser fast, og om et nabohospital på samme skabelon klarer sig uden den. Et godt svar skelner den sjældne legitime undtagelse fra de mange ønsker drevet af forandringsaversion og erkender, at det at tage standarden i brug er et forandringsledelses- og ledelsesproblem, ikke et teknisk. Det bør også konfrontere langtidsomkostningen: hver skræddersyet ændring er en skat betalt ved hver fremtidig cloud-udgivelse.

3. Har vi ærligt ressourcesat den menneskelige og proces-side af denne ERP-forandring — overgang, parallelkørsel, hypercare, uddannelse og integrationstest — eller kører vi den i det stille som et it-projekt? Fejllitteraturen er entydig om, at det meste ERP-besvær er mennesker og proces frem for teknologi, så dette spørgsmål afslører, om programmet reelt er en forretningsforandringsindsats eller et it-skift i programtøj. Perioden omkring go-live er, når leverandører forbliver ubetalte, månedsafslutningen bryder sammen, og personale får løn for sent, og hver af dem er i et offentligt sundhedsorgan ikke en ujævn start, men et tillidsødelæggende, potentielt nyhedsværdigt svigt. Spændingen at debattere er det konstante pres for at forkorte parallelkørsel, udtynde hypercare-teamet og komprimere tidsplanen for at nå en pålagt dato, mod virkeligheden, at en skredet dato kan rettes, mens en fejlslagen løn- eller hovedbogsovergang ikke kan. Nyttige vinkler inkluderer at gennemgå hver integration — e-vagtplan, ESR, apotekslager, bank, analyse — og spørge, hvilke der er testet fra ende til anden versus antaget, og om procesejere i økonomi, indkøb og HR faktisk er udlånt til at redesigne deres arbejdsgange. Et ærligt svar viser navngiven forandringsledelses-, uddannelses- og afstemningsressource i planen frem for en linje, der siger "it klarer det", og er villig til at faseopdele go-live, hvor en big-bang-overgang tilføjer undgåelig risiko. Det bør også erkende, at parathed, ikke kalenderen, må styre beslutningen om at fortsætte.

4. Har vi i spørgsmålet om fælles tjenester og cloud-ERP afvejet den standardisering, vi ville vinde, mod den lokale fleksibilitet, vi ville opgive — og truffet det valg bevidst frem for som standard? Fælles platforme som NHS SBS og konsortiers Oracle Cloud-instanser, og cloud-ERP mere bredt, tilbyder reelle præmier — stordriftsfordele, løbende opgraderinger, en lettere lokal implementerings- og supportbyrde — men køber dem med et reelt tab af lokal kontrol og en hård afhængighed af udbyderens køreplan og udgivelsesrytme. Dette spørgsmål tvinger teamet til at nævne, hvilken fleksibilitet der faktisk betyder noget for dem, og teste, om den er pengene værd at drive, patche og separat understøtte deres eget back office for. Spændingen i en sundheds- og plejesammenhæng skærpes af, at det meste back office-arbejde er commodity, så standardiseringsgevinsten som regel opvejer den tabte fleksibilitet — men "som regel" er ikke "altid", og at glide ind i en fælles platform uden at undersøge afvejningen er, hvordan organisationer ender med at fortryde en skabelon, de aldrig bevidst valgte. Konkrete vinkler inkluderer at spørge, hvilke lokale processer teamet ville kæmpe for at beholde og hvorfor, hvad der sker, når konsortiet ændrer skabelonen under dem, og om udtræden og dataportabilitet er forstået før underskrift. Et stærkt svar behandler dette som et strategisk valg truffet med åbne øjne, der afvejer udbyderafhængighed og køreplansrisiko mod skala og opgraderingslettelse, frem for enten at vælge den fælles løsning som standard, fordi den er moderne, eller at klamre sig til en skræddersyet platform af vane.

5. Hvad er vores ærlige plan for at forhindre, at skygge-regneark og lokale omveje dukker op igen efter go-live, så ERP’en forbliver det enkelte system of record frem for én kilde blandt mange? Hele pointen med en integreret ERP er at fjerne den fragmentering, skyggesystemer skaber, men lokale regneark har en måde at overleve en go-live på og i det stille gen-fragmentere de data, programmet skulle forene. Dette spørgsmål tester, om teamet har tænkt ud over overgangen til den varige driftsdisciplin, der holder omkostningssteder, budgetter, indkøbsgodkendelser og normering levende i ERP’en frem for i nogens private projektmappe. Det betyder noget i sundhed og pleje, fordi et skygge-normerings-regneark, der er uenigt med lønnen, eller en off-system indkøbssporing i det stille lader den datakvalitet rådne, som bestyrelsesrapportering og revision afhænger af, og gør det netop fordi det er bekvemt for den, der vedligeholder det. Spændingen, der er værd at bringe frem, er at skyggesystemer som regel findes af en grund — ERP-processen føltes langsommere, eller et reelt hul blev aldrig lukket — så et simpelt forbud fejler, medmindre det underliggende behov adresseres. Nyttige vinkler inkluderer at spørge, hvilke nuværende regneark der ville skulle dø ved go-live, hvorfor hvert findes, og hvilken kapabilitet i systemet eller procesændring der ville fjerne fristelsen til at genopbygge det. Et ærligt svar parrer en klar forventning om, at ERP’en er autoritativ, med en plan for at rette de huller, der driver folk ud af systemet, og nævner, hvem der vil bemærke og udfordre et skyggesystem, når det dukker op igen.

6. Er vi reelt ærlige om ERP-programmets risiko — sektorens track record af overskridelse og underlevering — og har vi bygget vores tidsplan, kontingens og go-live-tilgang omkring den virkelighed frem for en optimistisk plan? Store ERP-implementeringer har et velfortjent ry på tværs af sektorer for at overskride tid og pris og levere under på gevinst, og dette spørgsmål spørger, om teamet har internaliseret den fejllitteratur eller i det stille antager, at det vil være undtagelsen. Indsatsen i et offentligt sundhedsorgan er nådesløs: en skredet dato kan rettes, men en fejlslagen løn- eller hovedbogsovergang er en nyhedsværdig, tillidsødelæggende begivenhed med parlamentariske og presemæssige konsekvenser, så optimisme, der tilsidesætter parathed, er ikke mod, men skødesløshed. Spændingen at debattere er det konstante pres — fra pålagte datoer, sunk cost og ønsket om at vise fremskridt — for at komprimere tidsplanen, udtynde kontingens og foretrække en big-bang-go-live frem for en faseopdelt, der ville være sikrere, men langsommere. Konkrete vinkler inkluderer at spørge, hvad planen antager vil gå godt, hvor kontingensen reelt sidder, om en faseopdelt overgang er mulig, og hvad de eksplicitte kriterier er for at udskyde go-live, hvis parathed ikke er til stede. Et godt svar nævner de specifikke risici, dette program bærer, frem for at antyde ERP-risiko generelt, bygger reel kontingens og en forsvarlig faseopdelingsbeslutning ind og behandler et datadrevet "ikke endnu" som et legitimt og forventet udfald frem for en svigtende nerve.

I praksis: et eksempel fra sundhed og pleje#

Et NHS-akuthospital kører et femten år gammelt økonomi- og indkøbssystem på stedet, som leverandøren snart holder op med at understøtte. Rapportering tager dage, purchase-to-pay er stærkt manuel, og normeringen lever i et vildnis af regneark, der aldrig helt stemmer med lønnen. Hospitalet beslutter at flytte til en cloud-ERP leveret gennem et regionalt NHS-konsortiums skabelonbaserede Oracle Cloud-instans, sammen med nabohospitaler.

Økonomidirektøren modstår fristelsen til at behandle det som et it-skift. Et program oprettes med en direktionssponsor, en fuldtids programleder og — afgørende — en datakvalitetsarbejdsstrøm, der bruger måneder på at rense kontoplanen, afdublere tolv tusind leverandørregistre og afstemme medarbejderregisteret mod ESR (NHS’ elektroniske personaleregister) før nogen migrering. Procesejere i økonomi, indkøb og HR udlånes til at redesigne deres arbejdsgange til konsortiets skabelon frem for at replikere det gamle system.

Hospitalet vælger en faseopdelt go-live: økonomi og indkøb først, arbejdsstyrke og rapportering i en senere bølge, med parallelkørsel over to månedsafslutninger og et veltilbemandet hypercare-team i beredskab. Integrationer til e-vagtplan, banken og analysedatavarehuset er kortlagt og testet fra ende til anden. Go-live er ikke smertefri — en bunke af leverandørbetalinger opbygges i uge ét og tager to uger at rydde — men fordi afstemning og hypercare var ordentligt ressourcesat, får intet personale løn for sent, og månedsafslutningen lukker til tiden.

Et år senere lukker hospitalet sine bøger på dage frem for uger, indkøbsgodkendelser håndhæves i systemet, og normeringen stemmer endelig med lønnen. Den fælles konsortieplatform betyder også, at næste opgradering ankommer som en rutinemæssig cloud-udgivelse frem for endnu et flerårigt projekt.

Sektorperspektiver#

Startup#

En digital sundhedsstartup kører sjældent en fuld ERP; den syr cloud-SaaS-værktøjer sammen — en let regnskabspakke, en HR-og-lønapp, et par regneark — fordi en tung integreret pakke er uforholdsmæssig for et team på tredive. Disciplinen med system of record betyder dog stadig noget: selv på seed-stadiet forhindrer én ren kontoplan og én autoritativ lønkilde det afstemningskaos, der skræmmer investorer væk under due diligence. Det rette træk er at holde stakken enkel, integrerbar og velstyret og udskyde en "rigtig" ERP, til skalaen reelt kræver det. Startuppens risiko er spejlbilledet af virksomhedens — ikke overtilpasning, men uhæmmet vækst: et dusin usammenhængende apps uden stamdataejer og ingen ansvarlig for tallene.

Lille virksomhed#

En etableret lille udbyder — en lægepraksis, et lokalt apotek, et plejehjem, et hjemmeplejefirma eller en enkelt klinik — bærer hele vægten af finans-, løn- og indkøbspligter med næsten ingen dedikeret økonomi- eller it-kapacitet, så en tung ERP er uden for rækkevidde, men disciplinen med system of record er ikke valgfri. Det praktiske svar er et lille, veintegreret sæt cloud-pakker — regnskab, løn og lager — valgt så én kontoplan og én autoritativ lønkilde holder, for et plejehjem, der betaler personale for sent, eller et apotek, hvis lager og hovedbog er uenige, står over for de samme regulatoriske og likviditetsmæssige konsekvenser som et stort hospital, men uden et back office-team til at absorbere dem. Fristelsen til at drive virksomheden på en grundlæggers regneark er stærkest her og farligst, da der sjældent er nogen til at bemærke, når tallene driver. Hvor en fagorganisation, franchise eller lokalt netværk tilbyder en fælles eller standardiseret økonomiplatform, er det som regel det kloge træk at tage den i brug: den køber den standardisering og support, organisationen ikke selv kan ressourcesætte. Disciplinen er at holde stakken enkel og styret af den, der ejer pengene, og at modstå skræddersyede omveje, kun den ene person forstår.

Stor virksomhed#

Et stort hospital eller sundhedsteknologifirma kører en fuld integreret ERP som et missionskritisk system of record, og at udskifte den er et af de mest risikable programmer, det nogensinde vil forsøge. Virksomhedens fristelse er kraftig tilpasning for at bevare velkendte legacy-processer; disciplinen er at tage standardskabelonen i brug, ressourcesætte en seriøs datakvalitetsarbejdsstrøm og køre go-live med parallelkørsel og en veltilbemandet hypercare-periode. Integrationer mangedobles — e-vagtplan, ESR, apotekslager, bank, analyse — og hver er et tillidsødelæggende svigt, hvis den i det stille bryder løn eller månedsafstemning. Fordi det meste af besværet er mennesker og proces frem for teknologi, er forandringsledelse (se emne 8.1 — Forandringsledelse) der, hvor virksomhedsprogrammet vindes eller tabes. Ansvar over for en bestyrelse og revisorer gør en fejlslagen hovedbogs- eller lønovergang til en styringshændelse, ikke blot et it-tilbageslag.

Myndighed#

I national skala og skala for fælles tjenester er ERP et standardiseringsinstrument: NHS Shared Business Services og konsortiers Oracle Cloud-instanser findes for at give mange organisationer én skabelonbaseret platform og bytter lokal fleksibilitet for stordriftsfordele og løbende opgraderinger. Offentligt ansvar tilføjer offentlig indkøbsgranskning (konkurrenceudsatte rammer, value-for-money-assurance) til enhver større ERP-beslutning, og et nationalt overgangssvigt har parlamentariske og presemæssige konsekvenser. Centrets reelle løftestang er at indkalde — at påbyde eller incitamentere fælles platforme, så snesevis af hospitaler og lokale myndigheder ikke hver driver, patcher og separat fejler deres eget back office. Den definerende spænding er mellem national standardisering og lokal autonomi: pres skabelonen for hårdt, og adoptionen går i stå i vrede; for blødt, og den fragmentering, ERP findes for at fjerne, består i det stille.

Typiske fejlmønstre#

• Beskidte stamdata migreret i bulk. Gamle dubletter og inkonsistenser tages med ind i det nye system og ødelægger rapportering fra dag ét. Løsning: rens og styr stamdata før migrering, og eje dem bagefter.
• Tilpasning for at replikere det gamle system. Skræddersyede ændringer lavet for at undgå procesændring puster omkostningen op og ødelægger opgraderbarheden. Løsning: tag standardskabelonen i brug; ændr proces, ikke software.
• ERP kørt som et it-projekt. At behandle det som et teknologiskift sulter forandrings-, uddannelses- og procesredesigninsatsen. Løsning: kør det som et forretningsforandringsprogram med ægte forandringsledelse (emne 8.1).
• Optimistisk big-bang-go-live. Komprimerede tidsplaner og en enkelt overgang forvandler almindelige problemer til offentlige kriser. Løsning: faseopdel, hvor det er muligt, og byt aldrig parathed for en dato.
• Ødelagte integrationer. En utestet vagtplans-til-løn- eller indkøbs-til-hovedbogsfeed udbetaler folk forkert eller bryder afstemning. Løsning: kortlæg, eje og test hver grænseflade fra ende til anden.
• Skygge-regneark overlever. Lokale omveje består ved siden af ERP’en og gen-fragmenterer dataene. Løsning: gør ERP’en til det enkelte system of record, og pensionér skyggerne.

Modenhedsmodel#

Tjekliste#

• Kontoplan, leverandør-, vare- og medarbejderstamdata er renset og afdubleret før migrering.
• Løbende stamdataejerskab og -styring er tildelt og finansieret.
• Implementeringen er afgrænset og ressourcesat som et forretningsforandringsprogram, ikke et it-projekt.
• Tilpasning er minimeret; leverandørens eller konsortiets standardskabelon er taget i brug til commodity-processer.
• Hver integration (vagtplan, løn/ESR, klinisk/apotek, bank, analyse) er kortlagt, ejet og testet fra ende til anden.
• Go-live-tilgangen (faseopdelt versus big bang) er valgt ud fra parathed, ikke en pålagt dato.
• Dataovergang, parallelkørsel, afstemning og en hypercare-periode er planlagt og bemandet.
• Forandringsledelse, uddannelse og procesredesign er eksplicit ressourcesat (se emne 8.1).
• Muligheder for fælles tjenester og cloud-ERP er vurderet på deres reelle afvejninger mellem standardisering og fleksibilitet.
• ERP’en er etableret som det enkelte system of record, og skygge-regneark er pensioneret.

Centrale kilder#

• NHS Shared Business Services (NHS SBS) — den nationale Oracle-baserede fælles tjeneste for økonomi og indkøb til NHS-organisationer. https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — skalaen af den nationale NHS-økonomiplatform. https://www.oracle.com/uk/
• NHS North of England Commissioning / NEP-konsortiet — skabelonbaseret Oracle Cloud-ERP til NHS-medlemmer. https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — ERP til NHS-hospitaler, lokale myndigheder og universiteter. https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — økonomiprocesser, som ERP understøtter. https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — NHS’ arbejdsstyrke- og lønsystem, ERP skal integreres med. https://www.electronicstaffrecord.nhs.uk/
• Se også emne 5.2 — Programledet arbejde, emne 5.3 — Virksomhedsdækkende projektporteføljestyring (EPPM) og emne 8.1 — Forandringsledelse.

Referencer#

1. Enterprise resource planning — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. System of record — Wikipedia — https://en.wikipedia.org/wiki/System_of_record
3. Master data management — Wikipedia — https://en.wikipedia.org/wiki/Master_data_management
4. Chart of accounts — Wikipedia — https://en.wikipedia.org/wiki/Chart_of_accounts
5. Payroll — Wikipedia — https://en.wikipedia.org/wiki/Payroll
6. Procure-to-pay — Wikipedia — https://en.wikipedia.org/wiki/Procure-to-pay
7. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
8. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Change management — Wikipedia — https://en.wikipedia.org/wiki/Change_management
11. Business process re-engineering — Wikipedia — https://en.wikipedia.org/wiki/Business_process_re-engineering
12. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
13. NHS Shared Business Services — Wikipedia — https://en.wikipedia.org/wiki/NHS_Shared_Business_Services
14. NHS Shared Business Services — the national Oracle-based finance and procurement shared service for NHS organisations — https://www.sbs.nhs.uk/
15. NHS Shared Business Services with Oracle Fusion Cloud Applications — Oracle — https://www.oracle.com/uk/
16. Public sector and healthcare ERP — Unit4 — https://www.unit4.com/industries/public-sector-software
17. Introductory Guide to NHS Finance — HFMA — https://www.hfma.org.uk/
18. NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with — https://www.electronicstaffrecord.nhs.uk/