Feniks die valt of Feniks die rijst?
Nieuws over het centrale salarissysteem van de Canadese overheid met PeopleSoft ERP, dat ironisch genoeg steeds vaker de "Phoenix Betaalsysteem", is ontmoedigend. De CBC meldt dat 228.000 gevallen eind juli. Er kwamen duizenden nieuwe gevallen bij in de maand, wat resulteerde in een nettovermindering van 18.000. De De regering had in juni vorig jaar toegezegd dat de problemen eind oktober zouden zijn opgelost.. Uit mijn twitter feed blijkt een grote frustratie onder ambtenaren. Velen vragen zich af waarom het probleem niet kan worden opgelost.
Deze ERP-implementatie is sterk gepolitiseerd. De communicatie vanuit de overheid is vaag. De politieke pers is niet op de hoogte van technologie en kan niet de juiste vragen stellen. Het publiek weet niet wat het probleem is, of wat de problemen zijn.
Ik denk dat het hoog tijd is dat de regering het onderliggende technologische probleem of de onderliggende technologische problemen uitlegt. Anders leidt het tot eindeloze speculaties. Het gebrek aan transparantie leidt tot de veronderstelling dat de Canadese regering geen enkele competentie had in het managen van het Phoenix-project. Ik heb veel Canadese ambtenaren in de informatietechnologie ontmoet met uitstekende vaardigheden in projectmanagement en kennis van technologie. ERP-projecten en ingewikkeld met ontmoedigende succespercentages bij de overheid. Er zijn patronen die uit andere ERP-fiasco's van de overheid naar voren zijn gekomen: late oplevering, budgetoverschrijding, weinig verwachte voordelen - sommige projecten zijn opgegeven. Het is wishful thinking dat ministerieel toezicht zal de feniks op magische wijze uit de as herrijzen.
Dus ik ga speculeren over wat het probleem zou kunnen zijn op basis van patronen in soortgelijke omstandigheden, waarin deze aspecten aan bod komen:
- Stimuleringsmaatregelen
- Kwaliteit
- Projectbeheer
- Beste praktijken
- Training
- ERP-technologie
- Vervanging
- Schaalbaarheid
Ik zal afsluiten met de vraag waarom iemand zich hier zorgen over zou moeten maken.
1. Wanneer prikkels samenspannen voor mislukking van GovTech
Projectteams van de overheid kregen bonussen voor het behalen van mijlpalen. Dit is een giftige outputstimulans. Aan de ene kant moedigt het ambtenaren aan om te gokken met de output en aan de andere kant creëert het een drukmechanisme voor het aftekenen door leveranciers. Het creëert een omgeving waarin de definitie van succes kan worden gecompromitteerd. Dit kan ertoe leiden dat implementatieteams een omvang en kwaliteit leveren die zij als succesvol beschouwen, maar gebruikers niet.
Aanbieders kunnen het mandaat van tijdige levering gebruiken om te leveren met minder kwaliteit of minder omvang. Zeer grote leveranciers weten hoe ze contracten kunnen gebruiken. Ze hebben juridische afdelingen om contractdetails uit te kammen. Het is mijn ervaring dat er altijd gaten zitten tussen de eisen van Request for Proposal en de behoeften van de overheid. Misschien is de reikwijdte van functies die problemen hebben veroorzaakt niet goed geformuleerd. Er kan een aanzienlijk gat zitten tussen de wettelijke contractuele doelstelling voor de leverancier en de werkelijke behoefte.
Ik vermoed dat de stimulansen voor het implementatieteam van de overheid impliceren dat het management begreep dat het project riskant was. Het lijkt mij dat de aanbestedingsaanpak was om faalontkenning te creëren door PeopleSoft, het toonaangevende HR ERP-pakket, als enige te kopen en ervoor te zorgen dat alleen grote systeemintegratiebedrijven aan de kwalificaties van de leverancier konden voldoen. Niemand is ooit ontslagen bij het kopen van...' manier van denken.
2. Wordt Phoenix gekweld door insecten?
Het is onduidelijk hoe 89.000 gevallen in juni zijn afgehandeld. Ik heb het gevoel dat deze werden afgehandeld door workarounds in het systeem en door financiële transacties buiten het systeem om. Zijn er bugs in het systeem die problemen veroorzaken? Zo ja, komt dit dan door onjuiste bedrijfsregels of zit het in bepaalde functies van het systeem? De toevoeging van 71.000 nieuwe gevallen in een maand impliceert dat bugs in regels of validaties die de fout in gaan niet zijn verholpen.
Veel systeemintegratiebedrijven geven klanten de schuld van onvolledige communicatie tijdens het verzamelen van eisen. Dat lijkt in dit geval ondenkbaar. De loonregels van de Canadese overheid zijn geen mysterie. De regels zijn ingewikkeld maar worden goed begrepen. Veel mensen die voor de overheid werken kennen deze regels - net als veel mensen in de privésector. Veel overheidsdepartementen en -instellingen hebben bijvoorbeeld FreeBalance-software gebruikt voor salarisbudgettering en kwaliteitscontrole van het oude salarissysteem.
3. Projecten onder stress worden Griekse tragedies
Er is een typische reactie van het management op projecten die onder druk staan: meer toezicht. Meer toezicht door het management leidt tot meer vergaderingen en meer rapporten. Het verstoort de projectstroom. Het verhoogt de kans op mislukking, zoals in een Griekse tragedie, door te proberen mislukking te voorkomen. Het is onvermijdelijk dat Oedipus zijn vader vermoordt en dat zijn ERP-project niet op tijd wordt opgeleverd.
Projectmanagement onder stress resulteert vaak in het volgen van het oordeel van de minst functioneel en technisch gekwalificeerde persoon in het team: de meest senior persoon. De stem van technisch en functioneel onderlegd personeel wordt vaak overstemd door toezicht, papierwerk en commissies.
De tragedie van commissies is dat ze verslag uitbrengen aan meer commissies. Beslissingen worden steeds vaker genomen door mensen zonder kennis en context.
Er is een typische reactie van commissies: meer mensen toevoegen, meer uren maken. Meer mensen worden te laat in het project toegevoegd. Dit personeel komt nooit op snelheid en onderbreekt voortdurend de productiviteit. Ondertussen vergroot het langer werken de kwaliteitsproblemen, introduceert nieuwe bugs en legt het project lam.
4. Wanneer "Beste Praktijken" de Slechtste zijn
Overheidsopdrachten zijn vaak gebaseerd op voorspelbare tijdlijnen die zijn afgestemd op de budgetcyclus. Typische overheidscontracten voor bedrijfssoftware hebben gedefinieerde mijlpalen op basis van eerdere projecten waarbij verschillende technologieën werden gebruikt. Betalingen vinden plaats bij deze gedefinieerde mijlpalen. Elk project waarbij de mijlpalen niet strikt gedefinieerd zijn, wordt als risicovol beschouwd. Dat betekent dat de meeste overheden agile methodologieën vermijden bij complexe IT-aankopen. Gaten tussen de vereisten en de echte behoeften worden gedicht met change orders. Wijzigingsopdrachten kosten geld. Extra kosten worden vermeden. Dit resulteert in veel hogere kosten op de lange termijn door het niet afstemmen op de behoeften.
Voorspelbaarheid wordt ook geassocieerd met documentatie en toezicht. Systeemintegratiebedrijven besteden een aanzienlijke hoeveelheid tijd aan het schrijven van gap-analyses, specificaties, testcases en acceptatieplannen, waarbij succes vaak wordt afgemeten aan het aantal vernielde bomen en het aantal bijgewoonde vergaderingen. Dit brengt het succes van een project in gevaar. Dit wil niet zeggen dat documentatie moet worden vermeden. Het is dat documentatie als ceremonie vaak succes in de weg staat. Het documentatieproces gebruikt bijvoorbeeld vaak het legacysysteem als anker in plaats van de vervanging. Dus besteden teams meer tijd aan het bepalen en documenteren hoe de nieuwe software zal functioneren als de software die wordt vervangen. De optimale aanpak is om de problemen te identificeren die de legacy software oploste en te bepalen of de vervangende software deze problemen oplost. Vaak blijkt dat de nieuwe software elegantere manieren heeft om problemen op te lossen.
Overheden specificeren vaak de samenstelling van het projectteam voor systeemintegratie. Dit omvat het aantal jaren ervaring met het gekozen product of in het HR-domein. Dit omvat mogelijk niet het inzicht in payroll bij de Canadese overheid, of overheden in het algemeen. En overheden specificeren vaak het aantal mensen dat het integratiebedrijf moet leveren. Deze projectteams kunnen onhandelbaar worden en moeten in silo's werken met frequente vergaderingen tussen de groepen. Meer is zelden beter bij software-implementatie.
5. Het trainingsprobleem
Woordvoerders van de regering hebben aangegeven dat een gebrek aan training een van de hoofdoorzaken van het probleem. De overheid nam de training over van de systeemintegrator, IBM. Dit is geen onredelijke aanpak wanneer overheidspersoneel meer praktijkervaring heeft met payroll. Maar veel projecten lijden eronder als deze tactiek wordt gebruikt om kosten te besparen. Trainingskosten kunnen verschrikkelijk duur lijken in een groot voorstel. Het is een begrotingspost die kan opvallen als een zere duim - makkelijk om in te snijden om kosten te besparen.
Er is voldoende training nodig om het maximale uit bedrijfssoftware te halen. Personeel van de systeemintegrator kent het nieuwe product vaak veel beter en training door overheidspersoneel kan ondermaats zijn. "Train de trainer"-programma's kunnen ertoe leiden dat blinden de blinden leiden. En training in bedrijfssoftware veronderstelt ook een minimum aan domeinkennis die er misschien niet is (ook al staan klanten erop dat die kennis er is). Het is vaak moeilijk voor ambtenaren om generieke training te abstraheren van een bedrijfscontext naar lessen voor de overheid.
Is het gebrek aan opleiding een hoofdoorzaak? Hoe kan het gebrek aan opleiding leiden tot ongeldige berekeningen, waardoor sommige ambtenaren geen loon ontvangen? Er moet een validatie zijn van de gegevensinvoer en uitzonderingsrapporten die aangeven dat mensen niet worden betaald. Uit begrotingsverslagen moet ook blijken dat er een verschil is tussen het verwachte en het werkelijke salaris. Het lijkt erop dat het gebrek aan training bijdraagt aan honderdduizenden gevallen, maar niet de hoofdoorzaak is.
6. Wanneer legacy-technologie wordt vervangen door legacy ERP
Er is een veelvoorkomend misverstand over het Phoenix project. De meeste waarnemers denken dat het systeem is "ontwikkeld" door IBM. De regering van Canada heeft PeopleSoft uitbesteed. Het is een officiële verklaring van het Ministerie van Financiën. IBM werd het systeemintegratiebedrijf na een competitief proces. Het probleem is dat de overheid de technische schuld veroorzaakt door legacy software probeert te elimineren door legacy ERP aan te schaffen. Dit betekent dat het vallen in "technisch faillissement" is uitgesteld. Maar de IT-klok tikt door.
Het heeft weinig zin om oude systemen te vervangen door wat de Gartner Groep oproepen "legacy ERP", dat meer maatwerk vereist dan modernere bedrijfsapplicaties. Overheden hebben vaak meer maatwerk nodig vanwege unieke wettelijke regels. Deze aanpassingen introduceren nieuwe code. Hoe meer veranderingen in code, hoe groter de kans op kwaliteitsproblemen. Meer bugs. Verlies van gegevensintegriteit.
Het kwaliteitsprobleem met sterk aangepaste ERP-systemen wordt na verloop van tijd groter. Veranderingen in de wetgeving zorgen voor meer maatwerk. Maatwerk bemoeilijkt productupgrades omdat de weescode in detail moet worden onderzocht om te zien wat er moet veranderen. Als maatwerk hier een hoofdoorzaak is, dan is de de problemen worden alleen maar erger.
7. Vervanging en portefeuillemythe
Verbeterde integratie en lagere totale kosten zijn typische waardeproposities voor veel grootschalige ERP-projecten. Maar toch, veel overheidsprojecten die bedoeld zijn om meerdere systemen door één systeem te vervangen, resulteren in aanzienlijke kostenoverschrijdingen. In deze omstandigheden kunnen er problemen zijn met verandermanagement. Ik heb het gevoel dat IT-beslissers vaak niet begrijpen waarom verschillende systemen überhaupt zijn toegevoegd. Er kan aanzienlijke functionaliteit nodig zijn in deze systemen die de aanpassingsvoetafdruk vergroot.
Het is logisch dat gecentraliseerde IT-functies meer schaalvoordelen opleveren dan veel afzonderlijke systemen. Het is redelijk om te verwachten dat de training en het onderhoud van één geïntegreerde oplossing minder kosten dan die van meerdere oplossingen die op verschillende manieren met verschillende technologieën werken. In de praktijk is dit niet altijd het geval. Ten eerste zijn ERP-systemen vaak complexer. Het is onze ervaring dat er meer mensen nodig zijn om een groot ERP-systeem te bedienen en te onderhouden dan een verzameling op maat gemaakte en COTS-applicaties. Ten tweede zijn veel ERP-oplossingen niet uniform. Dit komt door de vele overnames die ERP-leveranciers hebben gedaan, zodat er veel technologieën en codegrondslagen in deze oplossingen aanwezig zijn. ERP-leveranciers implementeren monolithische versies van modules die dezelfde technologie en codebasis gebruiken. Dit vereist metadatabeheer en integratiestrategieën wanneer dezelfde software wordt gebruikt omdat de definitie van iets in één module verschilt van andere. De totale kosten op lange termijn kunnen hoger zijn met één legacy ERP dan met een portfolio van applicaties.
Er is ook iets fundamenteel anders aan overheidsbrede ERP-systemen. Er zijn negatieve opbrengsten die in veel overheidsorganisaties optreden wanneer kleinere afdelingen en instanties worstelen met zeer complexe gestandaardiseerde processen die zijn ontworpen voor veel grotere afdelingen. Het kan ook leiden tot meer werklast voor afdelingen en instanties met rechtmatig unieke processen. Bijvoorbeeld, een overheidsinstantie die zich bezighoudt met nationale veiligheidskwesties heeft zeer complexe aanwervingscriteria.
8. Wanneer schalen niet schaalt
Grote payroll-systemen hebben te maken met schaalbaarheid. Dat komt omdat voor elke salarisrun duizenden regels moeten worden doorlopen. In april 2016 waren er meer dan 258.000 federale ambtenaren in dienst bij de Canadese overheid.. Dit is exclusief het aantal gepensioneerde ambtenaren die een pensioen ontvangen. Daarom is het enigszins belangrijk om ervoor te zorgen dat het systeem schaalbaar is voor piekactiviteiten op het gebied van salarisadministratie. PeopleSoft is gebouwd op propriëtaire technologie. Het schalen van PeopleSoft vereist waarschijnlijk een propriëtaire methode van load balancing voor batchprocessen. Deze methode is misschien niet zo elegant als sommige technieken die vandaag beschikbaar zijn. Maar het zou moeten schalen tenzij, zoals bij sommige Shared Services Canada implementaties, er onvoldoende computermiddelen beschikbaar zijn.
Waarom is dit belangrijk?
Phoenix is een van de vele grote IT-projecten van de Canadese overheid die niet aan de verwachtingen hebben voldaan, samen met de één project voor web content managementde Shared Services Canada e-mailproject, en andere Dit is publiek geld die verspild is. Het lijkt erop dat deze implementaties de overheid meer zullen kosten dan wanneer de status quo gehandhaafd zou blijven. Dit voorspelt niet veel goeds voor toekomstige grote IT-projecten bij de Canadese overheid.
Sommige waarnemers vinden dat ambtenaren te veel rechten hebben. Eén persoon twitterde dat er veel minder ambtenaren in dienst zouden moeten zijn in Canada. Zijn punt leek te zijn dat ambtenaren die hun huis kwijtraakten, geen medicijnen of onderwijs konden betalen, het wel verdiend hadden. Er lijkt een gebrek aan empathie te zijn buiten de National Capital Region. Dit idee van onproductieve naamloze bureaucraten is een mythe. Het is waar dat Canadese ambtenaren goede pensioenregelingen hebben, maar velen verdienen minder dan hun collega's in de particuliere sector.
Mijn observatie is dat ambtenaren een zodanige downsizing-, rightsizing-, shared services- en outsourcing-golf hebben doorgemaakt dat het moeilijk is om de kwaliteit en efficiëntie van het werk in de publieke en private sector van elkaar te onderscheiden. Natuurlijk zijn er officieuze bureaucraten bij de overheid, maar er zijn er ook veel in de particuliere sector. Bedrijven als Blackberry en Blockbuster hebben cruciale blunders gemaakt.
Er is een veel hoger percentage missiegedreven personeel bij de overheid dan in de privésector. De meeste ambtenaren die ik heb ontmoet, zijn er om een positief verschil te maken. Dat is iets wat zelden gerapporteerd wordt. Dat zou wel moeten.