Ämne 5.4 — Affärssystem (ERP)

I en mening: Enterprise Resource Planning (ERP) är det integrerade back office-systemet — ekonomi, personal, löner, upphandling och försörjningskedja — som fungerar som organisationens huvudsystem (system of record) för pengar, människor och lager, och i tysthet underbygger nästan varje arbetssätt i denna bok.

Varför detta är viktigt inom hälsa och vård#

Digital omvandling inom hälsa och vård får sin uppmärksamhet från kliniska system — den elektroniska patientjournalen, den delade vårdjournalen, patientappen. Men inget av dessa fungerar utan det oglamorösa back office som ligger under dem. Personal måste rekryteras, schemaläggas och betalas; leverantörer måste kontrakteras och regleras; läkemedel, produkter och förbrukningsmaterial måste beställas och spåras; och varje pund måste redovisas mot snävt begränsade offentliga budgetar. ERP är där detta sker, och när det havererar är konsekvenserna omedelbara: obetald personal, stannad upphandling, ostämda räkenskaper och en ekonomifunktion som flyger i blindo.

Skalan är enorm. NHS Shared Business Services (NHS SBS), ett joint venture bildat 2004, driver en nationell Oracle-baserad plattform för ekonomi och upphandling som bearbetar miljontals fakturor och hanterar en mycket stor andel av NHS totala utgifter för över hundra NHS-organisationer (se Viktiga källor). ERP-beslut är därför inte en nischad ekonomifråga — de formar personalförvaltning, kontroll över offentliga medel och den datakvalitet varje analys nedströms är beroende av. För en direktör är ERP både en grundläggande möjliggörare och ett av de högst riskfyllda program en organisation någonsin kommer att företa sig.

Grundläggande begrepp#

Vad ERP är. En enda, integrerad svit av moduler för affärssystem (enterprise resource planning) som delar en databas och en uppsättning masterdata och täcker företagets centrala administrativa processer: huvudbok och finansiell redovisning, leverantörs- och kundreskontra, personal- och arbetskraftsadministration, löner, upphandling (köp-till-betalning, purchase-to-pay), lager och försörjningskedja samt alltmer planering och analys (FP&A — financial planning and analysis). Poängen med ”integration” är att en inköpsorder, en godsmottagning och en faktura stäms av automatiskt eftersom de är samma data, inte tre kopior.

Huvudsystem (system of record). ERP är den auktoritativa källan för finansiella data och resursdata — huvudboken som revisorer litar på och lönerna personalen betalas från. Andra system kan hålla operativa kopior, men ERP är sanningens version för pengar och ofta för den materiella personaljournalen.

Masterdata. De delade referensdata som allt annat beror på: kontoplanen (chart of accounts), kostnadsställen, leverantörsposter, artikelkatalogen och personalposter. Masterdata är den tysta avgörande faktorn för ERP-framgång — smutsiga, duplicerade eller inkonsekventa masterdata korrumperar rapportering, bryter avstämning och undergräver varje process byggd ovanpå.

Vanliga plattformar inom hälsa och offentlig sektor. Inom NHS och bredare brittisk offentlig sektor är de huvudsakliga ERP-plattformarna Oracle (dominerande, till stor del genom NHS SBS och konsortier såsom NEP), SAP, Unit4 (vitt vald av sjukhus, universitet och kommuner) och Microsoft Dynamics 365. Kommuner som levererar socialtjänst för vuxna kör samma klass av system för sin ekonomi och upphandling. Färdriktningen är moln-ERP (programvara som tjänst) snarare än lokala installationer.

Gemensamma tjänster (shared services). I stället för att varje organisation driver sitt eget ERP delar många en gemensam plattform och en gemensam back office-verksamhet — NHS SBS-modellen, och NHS-konsortier som driver mallade Oracle Cloud-instanser. Gemensamma tjänster byter en del lokal flexibilitet mot standardisering, skalfördelar och en mindre gemensam implementerings- och supportbörda.

Bästa praxis#

1. Behandla masterdata som grunden, inte en eftertanke. Rensa och avduplicera kontoplanen, leverantörsposter, artikelkatalogen och personaldata före migrering, och inför löpande ägarskap för datastyrning. De mest skadliga ERP-misslyckandena kan spåras till dåliga masterdata som ingen bra programvara kan åtgärda; ett datakvalitetsarbete är inte valfritt.

2. Anta standarden; minimera anpassning. Konfigurera ERP mot leverantörens eller konsortiets standardmall varhelst processen genuint är standard, och reservera skräddarsydda ändringar för den sällsynta verkliga särarten. Kraftig anpassning blåser upp kostnaden, förstör uppgraderingsbarheten och återimporterar den lokala röra ni försökte fly — moln-ERP i synnerhet straffar instinkten att ”få det att se ut som vårt gamla system”.

3. Designa integrationerna medvetet. ERP står inte ensamt: det måste utbyta data med personal- och e-schemaläggningssystem, kliniska system och apoteksystem (för lager och kostnadsberäkning), bank och analys. Kartlägg varje gränssnitt, äg datakontrakten och testa dem från början till slut — lön matad av ett trasigt schemaläggningsflöde betalar människor fel, och det är ett förtroendeförstörande misslyckande.

4. Driv ERP-ersättning som ett större program, med förändringsledning i kärnan. En ERP-implementering är ett verksamhetsförändringsprogram som råkar involvera programvara, inte ett IT-projekt. Resursera det med programdisciplin (se Ämne 5.2 — Programledt arbete) och en genuin insats för förändringsledning (se Ämne 8.1 — Förändringsledning), eftersom det mesta av ERP-smärtan är människor och process, inte teknik.

5. Var ärliga om risken i ERP-program. Stora ERP-implementeringar har ett välförtjänt rykte om att överskrida tid och kostnad och underleverera på nytta; misslyckandelitteraturen är omfattande och tvärsektoriell. Bygg in beredskap, undvik en big bang-driftsättning där en stegvis är genomförbar och låt aldrig en optimistisk tidsplan åsidosätta beredskap — ett glidit datum går att återhämta sig från, en havererad lön- eller huvudboksövergång gör det inte.

6. Skydda driftsättningen och perioden efter den. Planera dataövergång, parallellkörning, avstämning och hypercare-stöd i detalj, och motstå trycket att förkorta dem. Veckorna runt driftsättningen är när leverantörer förblir obetalda och månadsbokslut havererar; en välbemannad stabiliseringsperiod är skillnaden mellan en stapplande start och en offentlig kris.

7. Använd ERP som huvudsystem för resursförvaltning — och utforma arbetssätten kring det. Låt ERP vara den enda källan för kostnadsställen, budgetar, upphandlingsgodkännanden och personalstat, och anpassa era operativa processer till det snarare än att underhålla skuggkalkylblad. Skuggsystem återinför den fragmentering ERP finns för att ta bort och förruttnar i tysthet datakvaliteten.

8. Väg gemensamma tjänster och moln-ERP efter deras verkliga avvägningar. Gemensamma plattformar (NHS SBS, konsortier i NEP-stil) och moln-ERP erbjuder standardisering, skala, kontinuerliga uppgraderingar och en lättare lokal börda, till priset av viss lokal flexibilitet och ett beroende av leverantören. Välj medvetet: för de flesta organisationer väger standardiseringsvinsten tyngre än den förlorade flexibiliteten, men beslutet bör fattas med öppna ögon, inte som standard.

Frågor att diskutera med ditt team#

1. Hur säkra är vi — med evidens, inte försäkran — på kvaliteten hos de masterdata vi skulle ta med oss in i ett nytt ERP, och vem äger dem efter driftsättning? Masterdata är den tysta avgörande faktorn för ERP-framgång, men behandlas rutinmässigt som en migreringsstädning snarare än grunden det är, så frågan prövar om teamet har tittat noga på kontoplanen, leverantörsposterna, artikelkatalogen och personalmastern eller helt enkelt hoppas att de är rena. I en hälso- och vårdmiljö är insatserna konkreta: duplicerade leverantörsposter bryter avstämning av köp-till-betalning, en personalmaster som inte stämmer med ESR betalar människor fel och en inkonsekvent kontoplan korrumperar varje ekonomisk rapport nedströms som styrelsen och revisorerna förlitar sig på. Spänningen värd att debattera är draget att migrera allt på en gång för att nå ett datum kontra de månader av oglamorös rensning och avduplicering som god praxis kräver, och om någon senior är villig att finansiera ett datakvalitetsarbete som inte visar någon synlig produkt. Ett starkt svar citerar faktiska antal — hur många duplicerade leverantörer, hur många ostämda personalposter — snarare än en allmän känsla av att ”data mestadels är fina”. Det bör också namnge den person och styrmekanism som är ansvarig för masterdatakvalitet efter driftsättning, eftersom data som rensats en gång och sedan lämnats ostyrda helt enkelt glider tillbaka till oordning.

2. Var frestas vi genuint att anpassa ERP för att bevara en välbekant process, och är den skillnaden en verklig särart eller bara den gamla röra vi försöker fly? Kraftig anpassning är den klassiska fällan i företags-ERP: den blåser upp kostnaden, förstör uppgraderingsbarheten och återimporterar just den lokala fragmentering programmet var avsett att ta bort, och moln-ERP i synnerhet straffar instinkten att ”få det att se ut som vårt gamla system”. Frågan ber teamet vara specifika om vilka processer de kommer att insistera på att böja programvaran efter, och att motivera var och en mot ett hårt test av om den är en verklig särart eller bara bekväm vana. Debatten spelar roll eftersom nästan varje back office-process inom hälsa och vård — huvudbok, upphandlingsgodkännanden, löneadministration — genuint är standard, så den ärliga utgångspunkten bör vara att anta leverantörens eller konsortiets standardmall och ändra processen, inte programvaran. Konkreta vinklar inkluderar att lista varje begärd anpassning och fråga vem som gynnas, vilken uppgraderingskostnad den låser in och om ett angränsande sjukhus på samma mall klarar sig utan den. Ett bra svar skiljer det sällsynta legitima undantaget från de många begäranden som drivs av förändringsaversion, och inser att att anta standarden är ett förändringsledar- och ledarskapsproblem, inte ett tekniskt. Det bör också konfrontera den långsiktiga kostnaden: varje skräddarsydd ändring är en skatt som betalas vid varje framtida molnutgåva.

3. Har vi ärligt resursatt den mänskliga och processmässiga sidan av denna ERP-förändring — övergång, parallellkörning, hypercare, utbildning och integrationstestning — eller driver vi den i tysthet som ett IT-projekt? Misslyckandelitteraturen är entydig med att det mesta av ERP-smärtan är människor och process snarare än teknik, så frågan avslöjar om programmet genuint är en verksamhetsförändringsinsats eller ett IT-byte klätt som program. Perioden runt driftsättningen är när leverantörer förblir obetalda, månadsbokslut havererar och personal får sin lön sent, och vart och ett av dessa i ett offentligt hälsoorgan är inte en stapplande start utan ett förtroendeförstörande, potentiellt nyhetsvärt misslyckande. Spänningen att debattera är det ständiga trycket att förkorta parallellkörning, tunna ut hypercare-teamet och komprimera tidsplanen för att nå ett pålagt datum, mot verkligheten att ett glidit datum går att återhämta sig från medan en havererad lön- eller huvudboksövergång inte gör det. Användbara vinklar inkluderar att gå igenom varje integration — e-schemaläggning, ESR, apotekslager, bank, analys — och fråga vilka som testats från början till slut kontra antagits, och om processägare inom ekonomi, upphandling och personal faktiskt har lånats ut för att omforma sina arbetsflöden. Ett ärligt svar visar namngivna resurser för förändringsledning, utbildning och avstämning i planen i stället för en rad som säger ”IT hanterar det”, och är villigt att dela upp driftsättningen där en big bang-övergång lägger till undvikbar risk. Det bör också erkänna att beredskap, inte kalendern, måste styra beslutet att gå vidare.

4. I frågan om gemensamma tjänster och moln-ERP, har vi vägt den standardisering vi skulle vinna mot den lokala flexibilitet vi skulle ge upp — och gjort det valet medvetet snarare än som standard? Gemensamma plattformar såsom NHS SBS och konsortiers Oracle Cloud-instanser, och moln-ERP bredare, erbjuder verkliga vinster — skalfördelar, kontinuerliga uppgraderingar, en lättare lokal implementerings- och supportbörda — men köper dem med en genuin förlust av lokal kontroll och ett hårt beroende av leverantörens färdplan och utgåvetakt. Frågan tvingar teamet att namnge vilken flexibilitet som faktiskt spelar roll för dem och pröva om den är värd kostnaden för att driva, patcha och separat stödja sitt eget back office. Spänningen i en hälso- och vårdmiljö skärps av att det mesta av back office-processerna är standard, så standardiseringsvinsten väger vanligen tyngre än den förlorade flexibiliteten — men ”vanligen” är inte ”alltid”, och att glida in i en gemensam plattform utan att granska avvägningen är hur organisationer hamnar i att ogilla en mall de aldrig medvetet valde. Konkreta vinklar inkluderar att fråga vilka lokala processer teamet skulle kämpa för att behålla och varför, vad som händer när konsortiet ändrar mallen under dem och om villkoren för utträde och dataportabilitet förstås före undertecknande. Ett starkt svar behandlar detta som ett strategiskt val gjort med öppna ögon, där leverantörsberoende och färdplansrisk vägs mot skala och uppgraderingsavlastning, snarare än att antingen som standard välja det delade alternativet för att det är på modet eller klänga sig fast vid en skräddarsydd plattform av vana.

5. Vad är vår ärliga plan för att hindra skuggkalkylblad och lokala kringgåenden från att återuppstå efter driftsättning, så att ERP förblir det enda huvudsystemet i stället för en källa bland många? Hela poängen med ett integrerat ERP är att ta bort den fragmentering skuggsystem skapar, men lokala kalkylblad har ett sätt att överleva en driftsättning och i tysthet återfragmentera de data programmet var avsett att förena. Frågan prövar om teamet har tänkt bortom övergången till den varaktiga operativa disciplin som håller kostnadsställen, budgetar, upphandlingsgodkännanden och personalstat levande i ERP snarare än i någons privata arbetsbok. Det spelar roll inom hälsa och vård eftersom ett skuggkalkylblad över personalstat som inte stämmer med lönen, eller en upphandlingsspårare utanför systemet, i tysthet förruttnar den datakvalitet styrelserapportering och revision är beroende av, och gör det just därför att det är bekvämt för den som underhåller det. Spänningen värd att lyfta är att skuggsystem vanligen finns av ett skäl — ERP-processen kändes långsammare, eller ett genuint glapp aldrig stängdes — så att helt enkelt förbjuda dem misslyckas om det underliggande behovet inte adresseras. Användbara vinklar inkluderar att fråga vilka nuvarande kalkylblad som skulle behöva dö vid driftsättning, varför var och en finns och vilken funktion i systemet eller processförändring som skulle ta bort frestelsen att bygga om det. Ett ärligt svar parar en tydlig förväntan att ERP är auktoritativt med en plan för att åtgärda de glapp som driver människor utanför systemet, och namnger vem som kommer att märka och utmana ett skuggsystem när det dyker upp igen.

6. Är vi genuint ärliga om risken i ERP-program — sektorns historia av överskridanden och underleverans — och har vi byggt vår tidsplan, beredskap och driftsättningsansats kring den verkligheten snarare än en optimistisk plan? Stora ERP-implementeringar har ett välförtjänt, tvärsektoriellt rykte om att överskrida tid och kostnad och underleverera på nytta, och frågan undrar om teamet har internaliserat den misslyckandelitteraturen eller i tysthet antar att det blir undantaget. Insatserna i ett offentligt hälsoorgan är obarmhärtiga: ett glidit datum går att återhämta sig från, men en havererad lön- eller huvudboksövergång är en nyhetsvärd, förtroendeförstörande händelse med parlamentariska och mediala konsekvenser, så optimism som åsidosätter beredskap är inte mod utan vårdslöshet. Spänningen att debattera är det ständiga trycket — från pålagda datum, nedlagd kostnad och viljan att visa framsteg — att komprimera tidsplanen, tunna ut beredskapen och föredra en big bang-driftsättning framför en stegvis som vore säkrare men långsammare. Konkreta vinklar inkluderar att fråga vad planen antar kommer att gå rätt, var beredskapen faktiskt finns, om en stegvis övergång är genomförbar och vilka de uttryckliga kriterierna är för att försena driftsättning om beredskapen inte finns där. Ett bra svar namnger de specifika risker detta program bär snarare än att antyda ERP-risk i allmänhet, bygger in verklig beredskap och ett försvarbart stegvisningsbeslut och behandlar ett datadrivet ”inte än” som ett legitimt och förväntat utfall snarare än ett tecken på bristande nerv.

I praktiken: ett exempel från hälsa och vård#

Ett NHS-akutsjukhus kör ett femton år gammalt lokalt system för ekonomi och upphandling som dess leverantör snart slutar stödja. Rapportering tar dagar, köp-till-betalning är i hög grad manuellt och personalstaten ligger i en härva kalkylblad som aldrig riktigt stämmer med lönen. Sjukhuset beslutar att gå över till ett moln-ERP levererat genom ett regionalt NHS-konsortiums mallade Oracle Cloud-instans, tillsammans med angränsande vårdgivare.

Ekonomidirektören motstår frestelsen att behandla detta som ett IT-byte. Ett program sätts upp med en exekutiv sponsor, en heltidsanställd programchef och — avgörande — ett datakvalitetsarbete som i månader rensar kontoplanen, avduplicerar tolvtusen leverantörsposter och stämmer av personalmastern mot ESR (NHS elektroniska personaljournal) före någon migrering. Processägare inom ekonomi, upphandling och personal lånas ut för att omforma sina arbetsflöden till konsortiets mall i stället för att replikera det gamla systemet.

Sjukhuset väljer en stegvis driftsättning: ekonomi och upphandling först, personal och rapportering i en senare våg, med parallellkörning över två månadsbokslut och ett välbemannat hypercare-team i beredskap. Integrationer till e-schemaläggning, banken och analysdatalagret kartläggs och testas från början till slut. Driftsättningen är inte smärtfri — en eftersläpning av leverantörsbetalningar byggs upp under vecka ett och tar fjorton dagar att avveckla — men eftersom avstämning och hypercare var ordentligt resursatta får ingen personal sin lön sent och månadsbokslutet stängs i tid.

Ett år senare stänger sjukhuset sina böcker på dagar i stället för veckor, upphandlingsgodkännanden verkställs i systemet och personalstaten stämmer äntligen med lönen. Den gemensamma konsortieplattformen innebär också att nästa uppgradering anländer som en rutinmässig molnutgåva snarare än ytterligare ett flerårigt projekt.

Sektorperspektiv#

Startup-företag#

Ett digitalt hälsoföretag i startfasen kör sällan ett fullständigt ERP; det sätter ihop molnbaserade SaaS-verktyg — ett lättviktigt redovisningspaket, en app för personal och löner, ett par kalkylblad — eftersom en tung integrerad svit är oproportionerlig för ett team på trettio. Disciplinen kring huvudsystem spelar ändå roll: även i såddfasen förhindrar en ren kontoplan och en enda auktoritativ lönekälla det avstämningskaos som skrämmer investerare vid due diligence. Det rätta draget är att hålla stacken enkel, integrerbar och väl styrd, och skjuta upp ett ”riktigt” ERP tills skalan genuint kräver det. Startup-företagets risk är spegelbilden av storföretagets — inte överanpassning utan utspridning: ett dussin frånkopplade appar utan ägare av masterdata och ingen som är ansvarig för talen.

Småföretag#

En etablerad liten vårdgivare — en läkarpraktik, ett närapotek, ett vårdhem, en hemtjänstorganisation eller en klinik på en enda ort — bär hela tyngden av finansiella, löne- och upphandlingsplikter med nästan ingen dedikerad ekonomi- eller IT-förmåga, så ett tungt ERP ligger utom räckhåll men disciplinen kring huvudsystem är inte valfri. Det praktiska svaret är en liten, väl integrerad uppsättning molnpaket — redovisning, löner och lager — valda så att en kontoplan och en auktoritativ lönekälla håller, eftersom ett vårdhem som betalar personal sent eller ett apotek vars lager och huvudbok inte stämmer möter samma regulatoriska och kassamässiga konsekvenser som ett stort sjukhus men utan back office-team att absorbera dem. Frestelsen att driva verksamheten på en grundares kalkylblad är starkast här och farligast, eftersom det sällan finns någon som märker när talen glider. Där en yrkesorganisation, franchise eller lokalt nätverk erbjuder en gemensam eller standardiserad ekonomiplattform är det oftast det kloka draget att anta den: den köper den standardisering och det stöd organisationen inte kan resursera själv. Disciplinen är att hålla stacken enkel och styrd av den som äger pengarna, och att motstå skräddarsydda kringgåenden som bara den personen förstår.

Storföretag#

Ett stort sjukhus eller hälsotekniskt företag kör ett fullständigt integrerat ERP som ett verksamhetskritiskt huvudsystem, och att ersätta det är ett av de högst riskfyllda program det någonsin kommer att företa sig. Storföretagets frestelse är kraftig anpassning för att bevara välbekanta äldre processer; disciplinen är att anta standardmallen, resursera ett seriöst datakvalitetsarbete och köra driftsättning med parallellkörning och en välbemannad hypercare-period. Integrationer förökar sig — e-schemaläggning, ESR, apotekslager, bank, analys — och var och en är ett förtroendeförstörande misslyckande om den i tysthet bryter lön eller månadsbokslutsavstämning. Eftersom det mesta av smärtan är människor och process snarare än teknik är förändringsledning (se Ämne 8.1 — Förändringsledning) där storföretagets program vinns eller förloras. Ansvarsskyldigheten inför en styrelse och revisorer gör en havererad huvudbok eller lönesövergång till en styrningsincident, inte bara ett IT-bakslag.

Staten#

I nationell skala och skala för gemensamma tjänster är ERP ett standardiseringsinstrument: NHS Shared Business Services och konsortiers Oracle Cloud-instanser finns för att ge många organisationer en mallad plattform, och byter lokal flexibilitet mot skalfördelar och kontinuerliga uppgraderingar. Statlig ansvarsskyldighet lägger offentlig upphandlingsgranskning (konkurrensutsatta ramavtal, kvalitetssäkring av valuta för pengarna) till varje större ERP-beslut, och ett nationellt övergångsmisslyckande har parlamentariska och mediala konsekvenser. Centrums verkliga hävstång är att sammankalla — att föreskriva eller stimulera gemensamma plattformar så att tiotals sjukhus och kommuner inte var och en driver, patchar och separat havererar sitt eget back office. Den definierande spänningen är mellan nationell standardisering och lokal autonomi: driv mallen för hårt och införandet stannar i missnöje; för mjukt och den fragmentering ERP finns för att ta bort består i tysthet.

Vanliga felmönster#

• Smutsiga masterdata migrerade i klump. Gamla dubbletter och inkonsekvenser förs in i det nya systemet och korrumperar rapportering från dag ett. Åtgärd: rensa och styr masterdata före migrering, och äg dem efteråt.
• Anpassning för att replikera det gamla systemet. Skräddarsydda ändringar gjorda för att undvika processförändring blåser upp kostnaden och förstör uppgraderingsbarheten. Åtgärd: anta standardmallen; ändra processen, inte programvaran.
• ERP drivet som ett IT-projekt. Att behandla det som ett tekniskt byte svälter förändrings-, utbildnings- och processomformningsinsatsen. Åtgärd: driv det som ett verksamhetsförändringsprogram med verklig förändringsledning (Ämne 8.1).
• Optimistisk big bang-driftsättning. Komprimerade tidsplaner och en enda övergång förvandlar vanliga problem till offentliga kriser. Åtgärd: stegvisa där det är genomförbart, och byt aldrig beredskap mot ett datum.
• Trasiga integrationer. Ett otestat flöde från schemaläggning till lön eller från upphandling till huvudbok betalar människor fel eller bryter avstämning. Åtgärd: kartlägg, äg och testa varje gränssnitt från början till slut.
• Skuggkalkylblad överlever. Lokala kringgåenden består bredvid ERP och återfragmenterar data. Åtgärd: gör ERP till det enda huvudsystemet och avveckla skuggorna.

Mognadsmodell#

Checklista#

• Kontoplanen samt leverantörs-, artikel- och personalmasterdata är rensade och avduplicerade före migrering.
• Löpande ägarskap och styrning av masterdata är tilldelade och finansierade.
• Implementeringen är avgränsad och resursatt som ett verksamhetsförändringsprogram, inte ett IT-projekt.
• Anpassning minimeras; leverantörens eller konsortiets standardmall antas för standardprocesser.
• Varje integration (schemaläggning, lön/ESR, kliniskt/apotek, bank, analys) är kartlagd, ägd och testad från början till slut.
• Driftsättningsansatsen (stegvis kontra big bang) väljs utifrån beredskap, inte ett pålagt datum.
• Dataövergång, parallellkörning, avstämning och en hypercare-period är planerade och bemannade.
• Förändringsledning, utbildning och processomformning är uttryckligen resursatta (se Ämne 8.1).
• Alternativen gemensamma tjänster och moln-ERP utvärderas utifrån deras verkliga avvägningar mellan standardisering och flexibilitet.
• ERP är etablerat som det enda huvudsystemet, och skuggkalkylblad är avvecklade.

Viktiga källor#

• NHS Shared Business Services (NHS SBS) — den nationella Oracle-baserade gemensamma tjänsten för ekonomi och upphandling för NHS-organisationer. https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — skalan på den nationella NHS-ekonomiplattformen. https://www.oracle.com/uk/
• NHS North of England Commissioning / NEP-konsortiet — mallat Oracle Cloud-ERP för NHS-medlemmar. https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — ERP för NHS-sjukhus, kommuner och universitet. https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — de ekonomiprocesser ERP underbygger. https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — NHS personal- och lönesystem som ERP måste integreras med. https://www.electronicstaffrecord.nhs.uk/
• Se även Ämne 5.2 — Programledt arbete, Ämne 5.3 — Företagsövergripande projektportföljhantering (EPPM) och Ämne 8.1 — Förändringsledning.

Referenser#

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/