No-Code en progressieve activering bij de planning van overheidsmiddelen
Een van onze klanten zei een paar jaar geleden tegen me: "alle overheden denken dat ze anders zijn, maar wij zijn echt anders!" Als er één ding is dat we na bijna 40 jaar uitsluitend met de publieke sector te maken hebben gehad, dan is het wel dat overheidsprocessen anders zijn. Verschillend tussen overheden. Anders binnen overheden. Heel anders dan bedrijven. En, voortdurend in beweging.
Het aanpassen van Commercial-Off-The-Shelf (COTS) software voor gebruik in overheidsorganisaties kan een zeer onbevredigende ervaring zijn. Enterprise software 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", etc.
Waarom moet het zo zijn? Waarom kan COTS software zich niet gemakkelijk aanpassen aan veranderende eisen?
Dit blogartikel beschrijft onze reis naar een "geleidelijke activering" en "no-code" aanpak.
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.
Veel deskundigen op het gebied van openbaar financieel beheer (PFM) die niet veel verschil zagen tussen configuratie en aanpassing - verwijzen vaak naar elke aanpassing als "aanpassing". Wij praten al enige tijd over het verschil. En de industrie heeft ons ingehaald door configuratie te definiëren als "no-code" aanpassing. Het gebruik van hulpsoftware om de ontwikkeling van code te vergemakkelijken wordt nu "low-code" ontwikkeling genoemd. Ik geef de voorkeur aan de term "configuratie", maar dit spectrum van no-code tot volledige code is een nuttig model.
Enterprise Compounding Software Technische Schuld
Code maatwerk komt met hoge kosten en toekomst uitdagingen op het gebied van aanpassingsvermogen. Aanpassing genereert technische schuld.
Generieke software, zoals Enterprise Resource Planning (ERP) is in hoge mate aanpasbaar met behulp van eigen programmeertalen zoals ABAP en PL/SQL. Het is waar dat ERP software geen configuratie woestenij is met:
- Configuratie van standaardparameters zoals boekjaren, valuta, leveranciers enz.
- Verticale markt snelle start om de uitvoering te vergemakkelijken, hoewel er weinig van toepassing zijn op de overheidssectoren
- Beste praktijkendie voornamelijk uit de particuliere sector komen, ingebouwd in software die voor sommige overheidsfuncties kan worden gebruikt, zolang er geen wettelijke hervorming nodig is.
Regeringen verwerven belangrijke en samenstelling technische schuld door volledige aanpassing van de code. Low-code maatwerk verhoogt ook de technische schuld.
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.
Codeaanpassing kan niet alleen technische schuld creëren. Technologie kan hervormingsmogelijkheden beperken. Wij noemen dit de "technologiekloof“.
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
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.
Government Resource Planning Technische Schuld
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
- Hoge capaciteitsbeperkingen 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
De technische schuld van de overheidsmiddelenplanning wegwerken
Productontwerp zorgt voor technische schuld of technische meerwaarde. Effectief ontwerp resulteert in elegante oplossingen voor problemen van klanten. Onze focus 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 door de hele softwarestack (database, applicatieserver, middleware enz.)
- Begrotingscyclus: Softwarefabrikanten hadden geen volledige ondersteuning voor de volledige overheidscyclus 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
Onze eerste beslissing was om een regeringsspecifiek platform met een verenigd ontwerp. De productsuite is ontwikkeld op basis van onze Componentenkaart voor het beheer van de overheidsfinanciën.
Wij maakten van de gelegenheid gebruik om de beperkingen van de oude technologie aan te pakken door onze software te herschrijven voor het web. We hadden veel geleerd van de migratie van onze vorige software van Canada naar andere landen:
- Overheidsfuncties: Onze focus stelde ons in staat om uitgebreide overheidsfuncties in de gehele PFM-componentenkaart omdat, met passende horizontaal functioneelAndere markten negeren en ontwikkelen op een open systeem dat vele softwarestacks kan ondersteunen.
- Begrotingscyclus: Onze focus stelde ons in staat om de gehele begrotingscycluswaardoor alle toepassingen budgetbewust
- Aanpassingsvermogen: We begrepen de technische schuld van de overheid, en breidden configureerbaarheid significant van onze vorige releases
- 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 eerste implementatie, in Kosovo, duurde 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 maakte quick wins mogelijk. We realiseerden ons dat we elke overheid "progressief konden activeren" tot geavanceerde openbare financiële functies zoals bij de 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 progressieve activering gezien.
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
Ik ontmoette een hoge ambtenaar van de schatkist van een Afrikaans land dat een Tier 1 ERP-systeem gebruikt voor financieel beheer. Het systeem was na 2 jaar nog steeds in de proeffase. Hij beschuldigde mij ervan dat ik van een van die "westerse bedrijven" was die miljoenen dollars per jaar vragen van arme regeringen om alleen maar het onderhoud van de software te betalen. Softwareonderhoud voor software die nog niet geïmplementeerd was. Ik legde uit hoe ons systeem een configuratie-aanpak gebruikte om implementaties te versnellen. Hij lachte alleen maar. Volkomen ongeloof dat het zelfs maar mogelijk was. Hij wist alles over hoe het was voor ERP-implementaties bij de overheid.
FreeBalance heeft geprofiteerd van een eenzijdige focus op de overheid. Onze software kan massaal configureerbaarin vergelijking met generieke software.
Er is nog een andere unieke FreeBalance eigenschap. Veel van onze eerste internationale klanten hadden contracten met grote systeemintegratiebedrijven. Wij waren een softwareleverancier, met enige uitbestedingsverantwoordelijkheden. We ontdekten dat onze projectbetrokkenheid in verhouding stond tot het succes van het project. 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.
Onze aanpak is heel anders.
Ons beleid is om bij alle implementaties betrokken te zijn. Wij begrijpen de overheidsmarkt. Wij werken samen met systeemintegratiebedrijven. Onze product- en serviceteams zijn zo geïntegreerd dat we elk vereist productaanpassing doen. En dit maatwerk wordt bij de volgende release onderdeel van onze commercieel ondersteunde code. Er is geen verweesde code.
Traditionele fabrikanten van bedrijfssoftware stellen langlopende product roadmaps op. Dit is een geaccepteerde aanpak. Het slaat nergens op, maar "zo is het nu eenmaal". Klantbehoeften en technologie veranderen zo sterk, dat het in kaart brengen van productfuncties voor de komende 3 tot 5 jaar, meer lijkt op gokken. Vooral met enig detailniveau.
Ik weet het - klanten zijn geconditioneerd voor roadmaps. Potentiële klanten willen onze 5 jaar roadmap zien. Onze 10 jaar roadmap. Ik denk dat het is om te zien of er ontbrekende benodigde functies in de pijplijn zitten. We laten regeringen de PFM Component Map zien en leggen uit dat we hier alles zullen doen, en software zullen aanpassen aan hun behoeften. (Zolang het geen slechte praktijk is.)
Onze aanpak bestaat erin een gedetailleerde product roadmap voor 3 jaar op te stellen op basis van onze diepgaande klantervaringen. En ons onderzoek naar overheid en technologie. We presenteren dit elk jaar aan onze FreeBalance International Steering Committee (FISC). FISC-deelnemers veranderen de prioriteiten van de roadmap en voegen items toe.
Dit omvat producten en diensten.
Progressieve activering breekt technische schuld af
FreeBalance is een sociale onderneming. Ons mandaat is om te bouwen slim land 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