No-Code en progressieve activering bij de planning van overheidsmiddelen
Als er één ding is dat FreeBalance heeft geleerd na bijna 40 jaar uitsluitend met de publieke sector te hebben te maken, is dat overheidsprocessen verschillend zijn. Verschillend tussen overheden. Anders binnen overheden. Heel anders dan bedrijven. En, voortdurend in beweging.
Het aanpassen van Commercial-Off-the-Shelf (COTS) software, zoals de grote Enterprise Resource Planning (ERP)-systemen, voor gebruik in overheidsorganisaties kan rampzalig. Bedrijfssoftware projecten bij de overheid zijn beladen met mislukkingen en complexe uitvoeringsmethoden. Velen in de technologie-industrie zien deze beproevingen als de "kosten van het zakendoen". "Het is wat het is", enz. Maar waarom moet het zo zijn? Waarom kan COTS software zich niet gemakkelijk aanpassen aan veranderende eisen?
Deze blog behandelt de verschillen tussen configuratie (gebruikt door de FreeBalance Accountability Suite™) en maatwerk (vereist voor ERP-implementaties), en legt onze geleidelijke activering en geen-code aanpak.
Verschil tussen configuratie en aanpassing
De meeste COTS-software gebruikt voor Planning van overheidsmiddelen (GRP) vereist een aanzienlijke aanpassing van de code. Softwareontwikkeling, meestal met behulp van propriëtaire programmeertalen, stelt overheden in staat om aangepaste vereisten te ondersteunen. Maar, tegen een prijs.
Wat is Configuratie?
In digitaal beheer van overheidsfinanciën (PFM) verwijst configuratie naar de mogelijkheid om het GRP-systeem, of geïntegreerd financieel management informatiesysteem (IFMIS) zoals het vaak wordt genoemd, in te stellen en aan te passen aan de behoeften van een overheidsorganisatie. Dit kan het configureren van workflows, het instellen van gebruikersrechten en het definiëren van begrotingscategorieën omvatten. Configuratie-opties worden gewoonlijk vooraf gedefinieerd door de GRP-provider en zijn beschikbaar voor alle gebruikers binnen de organisatie.
Wat is maatwerk?
Aanpassing, aan de andere kant, verwijst naar de mogelijkheid om het GRP-platform of de software aan te passen om beter te voldoen aan de specifieke behoeften van de organisatie. Dit kan het creëren van nieuwe modules, integratie met andere systemen of zelfs het ontwikkelen van aangepaste rapporten of dashboards omvatten. Aanpassingsopties vereisen vaak aanzienlijke technische expertise.
Wat is het probleem?
Veel PFM-experts zien niet veel verschil tussen configuratie en aanpassing - vaak verwijzen ze naar elke aanpassing als "aanpassing". Wij praten al enige tijd over het verschil. En de industrie heeft ons eindelijk ingehaald door configuratie te definiëren als aanpassing zonder code. Het gebruik van hulpsoftware om de ontwikkeling van code te vergemakkelijken wordt nu "low-code" ontwikkeling genoemd. Wij geven de voorkeur aan de term "configuratie", maar dit spectrum van no-code tot volledige code is een nuttig model.
ERP en maatwerk
Generieke ERP-software is in hoge mate aanpasbaar met behulp van eigen programmeertalen zoals ABAP en PL/SQL. Het biedt enkele configuratiemogelijkheden, zij het niet echt van toepassing op de overheidssector:
- Configuratie van standaardparameters zoals boekjaren, valuta, leveranciers, enz.
- Verticale markt snelle start om de uitvoering te vergemakkelijken, hoewel weinig van toepassing op de overheidssector
- Beste praktijkenvoornamelijk uit de particuliere sector, ingebouwd in software die misschien van toepassing zijn op sommige overheidsfuncties, zolang er geen wettelijke hervorming nodig is
Het probleem met code-aanpassing is dat het komt met hoge kosten en toekomst uitdagingen op het gebied van aanpassingsvermogen waardoor technische schuld.
Technische schuld
Regeringen verwerven belangrijke en samenstelling technische schuld via full-code en low-code aanpassingen.
Technische schuld omvat:
- Complexiteit van de uitvoering van het volledig formuleren van eisen en het inzetten van een volledig aangepaste ontwikkeling, waarvoor coördinatie van programmateams nodig is, en het instellen van een uitgebreide kwaliteitsborging.
- Complexiteit van het onderhoud na de implementatie neemt toe omdat er weescode is die moet worden ondersteund met interne middelen, niet de verantwoordelijkheid van de fabrikant
- Upgrade complexiteit bij het benutten van functionaliteit uit nieuwe releases, omdat de aangepaste code moet worden onderzocht en gerationaliseerd met de nieuwe versie
- Complexiteit van de verandering door de weescode te moeten begrijpen alvorens aan verandering te beginnen.
Technologiekloof
De aanpassing van de code beperkt ook de mogelijkheden tot hervorming van het beheer van de overheidsfinanciën. Wij noemen dit de "technologiekloof". A Gartner Groep analyse ontdekte dat software die niet is ontworpen voor toekomstige aanpassing organisaties in 15 jaar ongeveer 50 keer de oorspronkelijke investeringen kost.
Tekenen van de technologische kloof in het spel zijn:
- Arme time-to-results voor implementaties
- Arme time-to-change voor systemen
- Veel contracten met hoge kosten personeel om systemen te beheren
- Frequente systeemfouten en kwaliteit problemen
- Beperkt vermogen om gegevens voor andere doeleinden te gebruiken wegens gebrek aan openheid vanwege propriëtaire technologie lock-in
- Beperkt integratie van subsystemenzelfs tussen producten van dezelfde fabrikant
Waarom is Government Resource Planning anders?
Overheden worden geconfronteerd met complexere implementaties dan bedrijven.
Implementaties van software voor overheidsbedrijven zijn complexer van aard:
- Veel meer bedrijfstakken in een nationale of subnationale regering, dan bedrijfsconglomeraten
- Hoog beperkingen van de menselijke capaciteit in technologie, project en functionele kennis
- Complexer prestatiebeheer structuren en planning, omdat de overheid geen bottom-line heeft zoals "winst of verlies“
- Hogere praktijkdiversiteit vanwege wettelijke vereisten
- Complexere planning via meerjarig begrotingen die controles creëren in systemen voor verbintenisboekhouding
- Belangrijke politieke zorgen voor implementaties in de publieke sector
Overheden ervaren ook een bredere veranderingsvoetafdruk dan organisaties in de particuliere sector:
- Meer reorganisaties na verkiezingen, en van kabinetswijzigingen
- Meer juridische hervorming omdat veel systeemprocedures zijn vastgelegd in wetgeving, en wetten veranderen - bijvoorbeeld: overschakeling op boekhouding op transactiebasis, steun voor de eenheidsrekening van de schatkist, hervorming van de aanbestedingen, hervorming van de overheidsdiensten
- Meer procesverandering naast de juridische hervorming
- Meer internationale normen zoals MTEF, IPSAS, COFOG, GFS en SDG's, naast ondersteuning van een aantal normen voor de particuliere sector.
- Bredere organisatorische beperkingen waaronder gevestigde belangen die tegen verandering zijn
- Meer gebruik van oude technologie in de regering die verandering duur maakt, hoewel opgezadeld met hoge exploitatie- en onderhoudskosten
Geen technische schuld
Productontwerp zorgt voor technische schuld of technische meerwaarde. Effectief ontwerp resulteert in elegante oplossingen voor problemen van klanten. De focus van FreeBalance op de overheid heeft ons bevrijd van veel beperkingen van bedrijfssoftware.
Het ontwerp voor de web-native FreeBalance Accountability Suite™ begon medio 2006. Wij onderzochten veel van de beperkingen waarmee fabrikanten van bedrijfssoftware worden geconfronteerd en trokken een aantal conclusies:
- Overheidsfuncties: Software fabrikanten misten uitgebreide overheidsfuncties vanwege de noodzaak om software te verkopen aan vele industrieën, of verticale marktenin vele softwareklassen (ERP, CRM, SCM, HCM enz.), of horizontale marktenen in de hele softwarestack (database, applicatieserver, middleware enz.)
- Begrotingscyclus: Softwarefabrikanten hadden geen volledige steun voor de volledige overheid begrotingscyclus van beleid, begrotingsplanning, verplichtingen en verplichtingenvoor alle uitgaven en ontvangsten
- Aanpassingsvermogen: Softwarefabrikanten vertrouwden op code aanpassing omdat software vaak oorspronkelijk is ontworpen voor bedrijven
- Metadata: Softwarefabrikanten hadden belangrijke gegevensdefinitie problemen binnen productsuites die de integratie en controles, vaak van het bedrijf overnamesterwijl ze rigide lokalisatie, speciaal voor talen
Het FreeBalance-verschil
Onze eerste beslissing was om een regeringsspecifiek platform met een verenigd ontwerp. De productsuite is daarom ontwikkeld op basis van onze Componentenkaart voor het beheer van de overheidsfinanciën.
- Overheidsfuncties: Onze focus stelde ons in staat om uitgebreide overheidsfuncties over de gehele PFM-componentenkaart met passende horizontale functionaliteitandere markten negeren, en een open systeem dat vele softwarestacks kan ondersteunen.
- Begrotingscyclus: Onze focus stelde ons in staat om de gehele begrotingscycluswaardoor alle toepassingen budgetbewust
- Aanpassingsvermogen: We hebben de technische schuld van de overheid begrepen, en de configureerbaarheid uitgebreid aanzienlijk van onze vorige uitgaven
- Metadata: We realiseerden ons dat metadata verenigden geïntegreerd met configuratie - we realiseerden ons ook dat er een betere manier moest zijn om te lokaliseren
Configuratie en progressieve activering
FreeBalance was succesvol geworden in het snel implementeren van software. Onze implementatie in Kosovo duurde slechts 26 dagen. Het toenmalige operationele systeem omvatte begrotingscontroles, het afdrukken van cheques en een rekeningstelsel. Boekhoudkundige functies kwamen later. Net als treasury en gedecentraliseerde controles. De configuratieaanpak in eerdere versies van de FreeBalance-software vergemakkelijkte quick wins. We realiseerden ons dat we elke overheid "geleidelijk konden activeren" tot geavanceerde openbare financiële functies zoals onze eerste en langst bestaande klant, het Regering van Canada.
Sinds de voltooiing van de eerste versie van onze web-based FreeBalance Accountability Suite™ modules in 2009 hebben wij een toenemende behoefte aan geleidelijke activering.
Regeringen streven naar vooruitgang en modernisering, ondersteund door GRP-systemen voor:
- Hervorming van het bestuur: PFM, audit, openbare dienst, overheidsopdrachten en belastinghervorming.
- Open Overheid: transparantie van begroting, begroting, overheidsopdrachten, inkomsten en resultaten met participatieve mechanismen
- Decentralisatieagentschap en subnationale fiscale decentralisatie, deconcentratie
- Technologie Automatisering: automatiseringsefficiëntie, uitzonderingswaarschuwingen, kunstmatige intelligentie
- Digitale transformatie: migratie van systemen van registratie naar systemen van betrokkenheid, naar systemen van intelligentie en naar systemen van innovatie
- Modernisering van de prestaties: programmabudgettering, prestatiestructuren, resultaten en uitkomsten
Voordeel van integratie van producten en diensten
FreeBalance heeft geprofiteerd van een één enkele focus op de overheid. Onze software is massaal configureerbaarin vergelijking met generieke software. En wij treden op als zowel systeemontwikkelaars en systeemuitvoerders - een ander uniek FreeBalance kenmerk.
Veel van onze vroege internationale klanten hadden contracten met grote systeemintegratiebedrijven. Wij waren een softwareleverancier, met enige uitbestedingsverantwoordelijkheden. Wij ontdekten dat onze projectbetrokkenheid evenredig was aan het projectsucces. We ontdekten ook dat veel overheidsverzoeken voor functiewijzigingen niet waren doorgestuurd door onze partners. Onze product roadmap was niet op elkaar afgestemd.
De traditionele aanpak van product roadmaps voor bedrijfssoftware is via integratiepartners met een tweede kanaal via productondersteuning. Softwarefabrikanten staan vaak los van de eisen van de klant. Fabrikanten die veel verticale markten ondersteunen hebben vaak een gebrek aan expertise, dus de "feature loterij" zal vaak sommige markten bevoordelen boven andere.
FreeBalance Product Roadmap Aanpak
Onze aanpak is anders.
Ons beleid is erop gericht betrokken te zijn bij alle implementaties. Wij begrijpen de overheidsmarkt. We werken samen met systeemintegratiebedrijven. Onze product- en serviceteams zijn zo geïntegreerd dat we elk gewenst productaanpassing doen. En dit maatwerk wordt onderdeel van onze commercieel ondersteunde code in de volgende release. Er is geen weescode.
Traditionele fabrikanten van bedrijfssoftware stellen langlopende product roadmaps op. Dit is een geaccepteerde aanpak. Het slaat nergens op, maar "zo is het nu eenmaal". Klantenbehoeften en technologie veranderen zo sterk, dat het in kaart brengen van productfuncties voor de komende drie tot vijf jaar, meer lijkt op gokken. Vooral met enig detailniveau.
Klanten zijn echter gewend aan roadmaps. Potentiële klanten vragen vaak naar onze roadmaps voor vijf en tien jaar. Wij tonen hen de PFM Component Map en leggen uit dat wij hier alles zullen doen en software zullen aanpassen om aan hun behoeften te voldoen. (Zolang het maar geen slechte praktijk is.)
Onze aanpak bestaat erin een gedetailleerde product roadmap voor drie jaar op te stellen op basis van onze diepgaande klantervaringen. En ons onderzoek naar overheid en technologie. We presenteren dit aan onze Internationale stuurgroep FreeBalance (FISC) elk jaar. FISC-deelnemers wijzigen de prioriteiten van de roadmap en voegen punten toe. Dit omvat producten en diensten.
Progressieve activering breekt technische schuld af
FreeBalance is een doelgericht bedrijf. Ons mandaat is om te bouwen slimme welvaart door middel van op technologie gebaseerd bestuur. Regeringen kunnen geen welvaart opbouwen wanneer zij een technische schuld hebben aan informatiesystemen. Technologie moet hervorming van het bestuur mogelijk maken.
Deze configuratieaanpak, die een progressieve activering mogelijk maakt, omvat:
- Bedrijfsregelparametrisatie
- Geen-code-workflow
- Meerjarig geconfigureerd rekeningstelsel
- Uniforme metadata
- Extra gegevensvelden
- Eén taalbestand (in plaats van starre taalsets)
- Terminologie configuratie
- Aanpasbare hulp door integraal content management systeem
Voor meer informatie over de configuratieaanpak van FreeBalance, zie neem contact op.