Blockchainpilot Schiedam. Inkoop- en factureringsproces

Transcriptie

1 Blockchainpilot Schiedam Inkoop- en factureringsproces

2 Probleem Er is een aantal problemen geïdentificeerd m.b.t. het verwerken van inkoopfacturen. Hiervan zijn met name de volgende elementen geschikt om binnen de pilot te adresseren: DUBBELE CONTROLES (o.m. door overlap sub-processen en technologische beperkingen huidig systeem) GEBREK REALTIME INZICHT IN PROCESSEN (zowel intern als extern m.b.t. leveranciers) ADMINISTRATIEVE FRICTIE (e.g. snelheid verwerking en uiteindelijke betaling)

3 Waarom blockchain?

4 Waarom blockchain? Een aanzienlijk onderdeel van deze pilot behelst procesverbetering door het ontwikkelen van een op maat gemaakte applicatie

5 Waarom blockchain? Deze verbeteringen zijn in beginsel te realiseren zonder blockchain technologie

6 Waarom blockchain? Om blockchain-specifieke voordelen te realiseren, is het van belang dat: Er meerdere partijen betrokken worden bij de pilot. Zoals besproken, zou het hierbij in ieder geval gaan om Irado (of een andere grote leverancier qua factuur volume). Tevens is het belangrijk om partijen te betrekken die belang hebben bij toegang en verifieerbaarheid van deze data, bijvoorbeeld: GEMEENTE - door het inspecteerbaar maken van interne processen kan de auditing last verminderd worden AUDITORS - door het inspecteerbaar maken van interne processen kan de auditing last verminderd worden LEVERANCIERS - toegenomen efficiency en doordat facturen en betalingen worden geregistreerd op een 'immutable ledger' zijn banken mogelijk bereid om tegen betere voorwaarden krediet te verstrekken

7 Voorstel

8 Voorstel pilot functionaliteit (I) Twee kerncomponenten: GEBRUIKERSINTERFACE BLOCKCHAIN BACKEND Voor de leverancier, een dashboard om nieuwe facturen aan te melden, status bestaande facturen te verifiëren, en betalingsinformatie Verankeren van gegevens voor individuele facturen en audit-trails van bijbehorende processen in een geschikt blockchain netwerk Voor de gemeente, een overzicht van alle lopende bestelling en betaling processen, automatische notificaties aan toegewezen personen a.d.h.v. begrotingsregels Digitale handtekening via 2-factormechanisme.

9 Voorstel pilot functionaliteit (II) LOG IN Aan de kant van de eindgebruiker (gemeente en leverancier) neemt de pilot primair de vorm aan van een webportal via de browser toegankelijke schermen waarin gebruikers inloggen en relevante aspecten van de processen kunnen bekijken en managen De onderliggende data-laag, inclusief blockchain verankering, is programmatisch bereikbaar en na te lopen door partijen die de benodigde technologische capaciteit in huis hebben, bijvoorbeeld: integratie met accountancy software leverancier om facturen direct in het systeem aan te melden zonder handmatige handelingen auditor/bank kan proces informatie direct integreren in eigen backoffice systemen

10 Voorstel pilot functionaliteit (III) De essentie van de webportal is dat alle betrokken werknemers toegang krijgen tot dezelfde gegevens binnen een gedeelde omgeving om zo met een single source of truth te werken Voor verschillende rollen (verwerker, budgethouder, tekenbevoegde) zijn aparte views waarin de rol-specifieke handelingen kunnen worden verricht, alsmede een overzicht van alle voor een rol relevante data

11 Werkwijze pilot

12 Werkwijze pilot Identificeren externe partijen met oog op commitment, technologische capaciteit en expliciete toegevoegde waarde blockchain technologie

13 Werkwijze pilot UNDER CONSTRUCTION Agile ontwikkel model: focus op regelmatige consultatie en intensief testen met alle stakeholders waarbij eisen en functionaliteit continu worden bijgesteld en afgestemd op huidige inzichten Dit in tegenstelling tot het uitgebreid in kaart brengen van alle gewenste functionaliteit en medium- tot lange ontwikkeltijd

14 Werkwijze pilot </ > Voor dit model is het essentieel dat er voldoende communicatie is tussen ontwikkelaars en een team binnen de gemeente dat als vast contactpunt fungeert

15