Eens in de zoveel tijd vangt iemand de IT tijdgeest van de onderneming. Frank Scavo, voorzitter van Strativa heeft dat gedaan in een blogpost: Tijd voor een onafhankelijkheidsverklaring van softwareleveranciers? (en een Diginomica podcast met een interview door Dennis Howlett). Frank is getuige geweest van een toename van bedrijven die aangepaste software vanaf nul ontwikkelen. Is de "build vs. buy" calculus veranderd? Moeten organisaties zich onafhankelijk verklaren van Independent Software Vendors (ISV's) zoals FreeBalance?
Het is niet zozeer dat organisaties onafhankelijkheid verklaren van ISV's, zoals dat ISV's moeten afhankelijkheid verklaren op klanten.
[hieronder vindt u een tien punten tellende Software Vendor Customer Declaration of Dependence, sla de overheidsinhoud over als u niet geïnteresseerd bent].
Overheidsmarkt bouwen vs. kopen
De IT-markt voor de overheid onderscheidt zich van de zakelijke markt door een groter aandeel maatwerk en legacy-software. Wij zien dit in onze kernmarkt: Government Resource Planning (GRP), met name in ontwikkelingslanden en opkomende economieën. Deskundigen op het gebied van openbaar financieel beheer (PFM) zijn van mening dat het bouwen van op maat gemaakte informatiesystemen voor financieel beheer (FMIS) door de overheid een legitieme optie is:
- Hoe een financieel beheersinformatiesysteem te ontwerpen : Een modulaire aanpak van Gerardo Uña, Richard I Allen en Nicolas M Botton gepubliceerd door de Internationaal Monetair Fonds in mei 2019
- Technologische kansen en aanbevelingen voor de modernisering van geïntegreerde informatiesystemen voor financieel beheer in Latijns-Amerika en het Caribisch gebied van Carlos Pimenta en Antonio Seco gepubliceerd door de Inter-Amerikaanse Ontwikkelingsbank in januari 2019
- Informatiesystemen voor financieel beheer: 25 jaar ervaring van de Wereldbank met wat werkt en wat niet werkt door Cem Dener, Joanna Alexandra Watkins en
In de podcast wijst Scavo erop dat organisaties "geen grootboek moeten bouwen". Toch is het grootboek de kern van het financieel beheer van de overheid. Dit wordt verder bemoeilijkt door het feit dat overheden werken met een verplichtingenboekhouding.
Ik weet hoe ingewikkeld het is om een grootboek op te bouwen met meerdere niveaus van geaggregeerde vastleggingscontroles, en het "vrije saldo" van de begroting in real time te rapporteren. Ik herinner me een gesprek met een consultant van een gerenommeerd adviesbureau voor landenontwikkeling toen ik hem vertelde dat FreeBalance volledige ondersteuning bood voor het boeken van vastleggingen. Hij vroeg me of ik het zeker wist, want het boeken van vastleggingen is erg ingewikkeld.
Waarom zijn zoveel gerespecteerde deskundigen op het gebied van het beheer van de overheidsfinanciën van mening dat de regeringen moeten overwegen boekhoudsystemen op maat te schrijven?
Hoe is het zover gekomen?
- Asymmetrische macht
- Scavo beschrijft hoe ISV's enorme macht hebben zodra software is geïnstalleerd
- Overheden kunnen vastzitten aan Enterprise Resource Planning (ERP) technologiestacks van propriëtaire databases, middleware en programmeertalen (om nog maar te zwijgen van hardware voor in-memory computing).
- Op maat ontwikkelde software beperkt de macht van leveranciers over overhedenhoewel dit een illusie van controle
- Slecht ISV-gedrag
- Scavo beschrijft hoe sommige ISV's asymmetrische macht gebruiken voor slecht gedrag, genaamd "wallet cracking" (bedacht door Brian Sommer), waaronder het aanklagen van klanten, het aanrekenen van indirecte toegang en het verhogen van de onderhoudsprijzen.
- De regeringen hebben de verantwoordelijkheid om overheidsgeld doeltreffend te besteden, om "waar voor hun geld" te krijgen wanneer huurzoekende gedrag van ISV's mag niet worden getolereerd
- Op maat ontwikkelde software vermindert de kans op winstbejag door leveranciershoewel regeringen niet helemaal om technologieleveranciers heen kunnen
- Hoog geprofileerde ERP-fouten bij de overheid
- ERP-fouten bij de overheid variëren van kleine miljoen dollar tot grote miljard dollar boondoggles zoals de Phoenix Betaalsysteem in Canada en velen uit de Ministerie van Defensie van de Verenigde Staten
- Regeringen staan onder politiek toezicht voor grote IT-projecten - het is één ding als een bedrijf geld verspilt, het is iets heel anders als regeringen dat doen (De schuld voor het Phoenix Pay System is een politiek hangijzer tussen de Liberale en Conservatieve partijen...)
- Op maat ontwikkelde software geeft overheden de mogelijkheid om software in kleine modules uit te rollen om grote mislukkingen te voorkomentoch zijn er aanzienlijke aantallen op maat ontwikkelde mislukkingen bij de overheid zoals gezondheidszorg.goven we hebben veel overheden een aanbesteding zien doen om niet-geslaagde aangepaste software te vervangen door nieuwe aangepaste software (zie ook de punten 1 en 5).
- Code aanpassen
- Scavo wijst erop dat veel van de beschikbare Commercial-off-the-Shelf (COTS) "inflexibel" is en aanzienlijke aanpassingen vereist om aan de behoeften te voldoen (en de Gartner Group is zo ver gegaan om deze software als "legacy" aan te merken.)
- De eisen van de overheid verschillen aanzienlijk van de behoeften van het bedrijfsleven, wat leidt tot lange cycli van aanpassing van de code (tot het punt waarop veel PFM-deskundigen het "Customized-off-the-Shelf" noemen), wat leidt tot kwaliteitsproblemen, met de extra kosten voor het onderhouden en upgraden van weescode.
- Op maat ontwikkelde software lijkt voor overheden dezelfde complexiteitsvoetafdruk te hebben als ERP (hoewel, zo betoog ik hieronder, GRP veel minder complex is)
- Software voorspelbaarheid
- Gedetailleerde eisen worden beschreven in aanbestedingsdocumenten van de overheid voor centrale en perifere FMIS-systemen.
- Overheidsprocessen zijn vaak uniek vanwege wettelijke voorschriften en complexe processen die door ambtenaren goed worden begrepen.
- Op maat ontwikkelde software lijkt een hoge voorspelbaarheid te hebben wanneer de expertise bij de overheid ligt, hoewel deze projecten in de praktijk zelden voorspelbaar zijn en de watervalconcept van volledig geplande projecten zijn vaak de bron van mislukking
- Slecht SI-gedrag
- Scavo wijst er ook op dat grote systeemintegratoren vaak schuldig zijn aan mislukte implementaties, vaak door onnodig maatwerk te stimuleren om de inkomsten te verhogen - het is een fenomeen dat Michael Krigsman noemt de "Duivelsdriehoek“
- Overheden geven vaak de voorkeur aan contracten met grote systeemintegratoren als een mechanisme om het risico te beperken
- Op maat ontwikkelde software kan grote systeemintegratoren uit de mix halenhoewel veel op maat ontwikkelde applicatieprojecten worden uitbesteed aan SI's
Staan de regeringen voor twee lelijke alternatieven?
Het is geen ERP COTS of op maat ontwikkelde FMIS voor overheden. Er is het GRP alternatief, zoals onze FreeBalance Accountability Suite. Government Resource Planning is software die exclusief is ontworpen voor de overheid. FreeBalance is de eerste wereldwijde GRP met implementaties in ongeveer 30 landen.
Sommige waarnemers nemen aan dat GRP alle kwaden van COTS heeft geërfd. Andere waarnemers nemen aan dat GRP ISV's niet kunnen concurreren met grote ERP-leveranciers. Ik heb een paar lessen geleerd in deze GRP business:
- Software voor één domein
- Een hoge ambtenaar van het ministerie van Financiën lachte me eens uit op een conferentie toen ik hem vertelde dat FreeBalance-software meestal wordt geconfigureerd om aan de eisen te voldoen - het is deze configuratie die implementaties versnelt, projectkosten verlaagt (vooral in vergelijking met ERP-oplossingen), en maakt toekomstige flexibiliteit voor verandering mogelijk, iets wat wij "geleidelijke activering“
- Sommige waarnemers zien weinig verschil tussen "configuratie" en "aanpassing", maar er is een aanzienlijk verschilwaarbij sommige leveranciers noemen programmeerscripts ten onrechte configuratie en code generatoren en workflow suites worden vaak gepresenteerd als "configuratie".
- De laserfocus op de overheid geeft ons inzicht in het domein dat ontbreekt bij veel grote bedrijven, zoals de grote ERP-leverancier die klanten in de publieke sector vertelt dat line-item budget controls een "best practice" zijn.
- Schaalvoordelen
- De ERP-markt nam in de jaren '90 een hoge vlucht, gesteund door de bezorgdheid over het millenniumprobleem in combinatie met ISV's die functionaliteit van de ene markt naar de andere overhevelen, hogere kwaliteit en betere ondersteuning bieden en zo schaalvoordelen behalen ten opzichte van "best-of-breed" verkopers, maar vandaag de dag software voor meerdere markten is opgeblazen
- Schaalvoordelen nemen af naarmate nieuwe markten worden betreden - veel leveranciers zijn overgenomen om hun productportefeuilles aan te vullen, waardoor er wat Ned Lily van xTuple noemt de "ERP-kerkhof" waar grote leveranciers geconfronteerd worden met een duizelingwekkende complexiteit om zoveel verworven technologieën te onderhouden.
- Grote leveranciers maken gebruik van propriëtaire databases, middleware en programmeertalen om klanten aan een technologiestack te binden - dit vereist aanzienlijke investeringen in een tijd waarin flexibele ISV's open source alternatieven gebruiken.
- Integraal product en proces
- Veel ISV's streven naar schaalvergroting via VAR-partners en systeemintegratoren tot het punt waarop de kennis van de klant verloren gaat en het succes van de implementatie afneemt, waardoor ISV's geen voeling meer hebben met de realiteit van de klant.
- Aan de andere kant streven ISV's vaak naar consultingcontracten met strategische klanten om de productprioriteiten te bepalen, en ik vraag me vaak af hoe de meerderheid van de klanten zich voelt als ze niet strategisch worden geacht.
- Wij zien alle klanten als strategisch, want als onze Voorzitter en CEO, Manuel Pietra zegt vaak: "we hebben maar één klant per land - de regering, en we zitten er levenslang in".
Verklaring van afhankelijkheid van de klant
Veel van de punten zijn geïnspireerd door de Tijd voor een onafhankelijkheidsverklaring van softwareleveranciers? blog post inclusief Web APis, open source, low-code/no-code.
Onafhankelijke softwareleveranciers (ISV's) moeten toegeven en zich ertoe verbinden eerst de klant te dienen om financieel duurzame bedrijven op te bouwen.
- Maatschappelijk verantwoord ondernemen: Gedragscodes van ISV's moeten erkennen dat klanten de primaire gemeenschap zijn voor inspanningen op het gebied van sociale verantwoordelijkheid, en moeten flagrant winstbejag verbieden.
- Toegankelijkheid: ISV-managers moeten toegankelijk zijn voor klanten om productondersteuning, bedrijfsprocedures en klanteninzicht te verbeteren.
- Waarde opbouwen: ISV's moeten zich richten op het opbouwen van waarde als het belangrijkste middel om klanten te behouden, en erkennen dat waarde misschien niet voortkomt uit het toevoegen van functies maar uit iets buiten producten zoals diensten of procesveranderingen.
- Domeinexpertise: ISV's moeten geen nieuwe verticale of horizontale markten betreden tenzij ze domeinexpertise opbouwen in productontwikkeling en productbeheer.
- Uitvoering Bestuur: ISV's moeten deel uitmaken van de programmagovernancestructuur voor belangrijke implementaties, in plaats van zich afzijdig te houden, om partners en klanten te begeleiden.
- Flexibel aanpassingsvermogen: ISV's moeten de last van aanpassing van de code verminderen door middel van no-code configuratie en low-code technieken om implementaties te versnellen, toekomstige wijzigingen te verbeteren en de kosten voor de klant te verlagen.
- Functiebeheer: ISV's moeten zich ertoe verbinden de behoefte aan aangepaste implementatiecode te verminderen met een duidelijk kader van hoe belangrijke functies zullen worden toegevoegd aan productroadmaps.
- Coöperatieve innovatie: ISV's moeten zich verbinden tot klantgestuurde innovatie met een duidelijk kader over hoe coöperatieve innovatie en ontwikkeling mogelijk worden gemaakt.
- Open Systemen: ISV's moeten zich verbinden tot het ondersteunen en gebruiken van bewezen open systemen, inclusief open source, om klanten meer technologische keuzes te geven en tegelijkertijd propriëtaire lock-in te verminderen.
- Zakelijke platforms: ISV's moeten ernaar streven API's en hergebruik van productplatforms aan te bieden om aangepaste ontwikkeling mogelijk te maken wanneer dat gerechtvaardigd is, en tegelijkertijd klanten geen kosten aanrekenen voor functionaliteit waarvoor al is betaald.
Mijn denken over de verklaring kwam voort uit mijn gastblog uit 2014 bij ZDNet: IT-storingen, machtsverschuivingen en sociale media geredigeerd door Michael Krigsman. Klanten kunnen zich verenigen door gebruik te maken van sociale media. Ik wees toen op enkele interessante gedragsveranderingen bij toonaangevende bedrijven in bedrijfssoftware:
- SAP en Infor hebben aangenomen design denken om klantgerichter te worden
- Microsoft heeft een gelijktijdige licentieoptie voor de Dynamics productlijn.
- Negatieve reacties van klanten dwongen SAP om het prijsbeleid voor premium ondersteuning en de Fiori-gebruikersinterface upgrade.
- Salesforce.com was afgepoeierd in haar pogingen om de term "sociale onderneming" te merken.
Sinds die tijd, SAP heeft zijn "indirecte toegang" model veranderd.
Is het alleen een bouw versus koop wereld voor overheden?
Scavo wijst erop dat bedrijfsplatforms van applicatiesuites, zoals de FreeBalance Verantwoordingsplatformkan worden gebruikt om software op maat te ontwikkelen. Het is verre van een binaire keuze tussen bouwen en kopen. Er zijn hybride bouw en koop alternatieven.
Veel overheden willen software bouwen met behulp van een standaard geïntegreerde ontwikkelingsomgeving (IDE) op basis van een technologie. Een "bestuursplatform" is een hybride aanpak door alle bouwaspecten van technologieplatforms op te nemen met hergebruik van koopfuncties die door het GRP COTS worden gebruikt. En, low-code/no-code kan mogelijk maken wat ooit aangepaste ontwikkeling was op GRP Suites als een meer koop dan bouw alternatief.
Hoe kunnen overheden de juiste keuze maken tussen bouwen en kopen?
Scavo noemt een aantal factoren die regeringen kunnen helpen betere bouw-tegen-beslissingen te nemen, die ik heb geprobeerd in een schema weer te geven.
- Industrie-specifieke: Veel ISV-oplossingen zijn geschreven voor andere markten -. dit heeft belangrijke gevolgen voor regeringen die zoveel unieke behoeften hebben
- Overweeg koop wanneer software geschreven voor de overheidsfunctie - productontwerp is belangrijk
- Overweeg bouwen wanneer er geen software beschikbaar is voor de overheidsfunctie, vooral wanneer het gaat om een unieke wettelijke behoefte
- Productrisico: Het bouwen van complexe functionaliteit, zoals een grootboek is riskant, en flexibiliteit voor verandering is belangrijk - Dit heeft belangrijke gevolgen voor regeringen die in de toekomst modernisering en hervorming verwachten.
- Overweeg koop wanneer de behoefte aan product footprint ingewikkeld is en toekomstige veranderingen worden verwacht
- Overweeg bouwen wanneer de behoefte aan product footprint bescheiden is en er weinig toekomstige veranderingen worden verwacht
- Integratierisico: Software moet niet worden beschouwd als zwarte doos silo's - dit heeft belangrijke gevolgen voor regeringen die geen metadata hebben en de integratie van controles in begrotingscycli niet controleren
- Overweeg koop wanneer de behoefte aan functionele integratie groot is, zoals bij het beheer van aanbestedingen, activa en overheidsinvesteringen, waar verkeerde interfaces materiële gevolgen kunnen hebben, zoals achterstallige betalingen van de overheid en het illegaal overschrijden van budgetten, of informatie uit het systeem van cruciaal belang is voor besluitvormers en fiscale transparantie.
- Overweeg bouwen wanneer functies autonoom werken met beperkte noodzaak tot detachering naar financiële kernsystemen