Gemeente ICT van de toekomst: SOA, Midoffice, brokers, etc

[Helsie]

In gemeenteland is het hebben van een midoffice en een service oriented architecture helemaal hot (en ook onderdeel van landelijke richtlijnen). Zijn er meer tweakers die werkzaam zijn in deze richting (als inhuur bij een gemeente of bij gemeente in dienst)?

Ik ben wel benieuwd wat voor aanpak andere gemeentes (zelf zit ik bij gemeente Breda) hierbij hanteren (en dan ervaringen horen van mensen die er zelf mee werken, niet de promo praatjes van leveranciers hoe het bij andere gemeentes werkt).

Wij maken gebruik van BizTalk 2006, SharePoint 2007, MS CRM 3, etc. Ontwikkeling wordt (nog) vooral door inhuur gedaan en het beheer doen we zelf. Leuke technologie en veel mogelijkheden, naar mijn mening!

[ Voor 18% gewijzigd door Helsie op 27-07-2007 11:52 ]

[ajhaverkamp]

Wat bedoel je met de termen "midoffice" en een "service oriented architecture". Mij zegt het helemaal niks. Ik werk nu ruim 10 jaar bij een onderdeel van de gemeente Amsterdam. Stadsdelen en gemeentelijke diensten zijn in principe volledig autonoom op het gebied van ICT. De afgelopen jaren zijn er 2 clubs opgericht voor het centraal regelen van personeelszaken (HRM volgens de modetermen) en voor ICT. Echt van de grond komen wil het niet, enkel gemeenteonderdelen die gedwongen worden om mee te doen, doen mee. Bedoel je zoiets?

[Sjakskus]

Ik was op de nationale office dag 2005 waar een demo werd gegeven hoe een gemeente (ik geloof woerden) hun zaakjes hadden geregeld mbv biztalk en share point

Gemeente haarlem had destijds alles opensource (project ossos)

Ik heb een jaar bij een kleinere gemeente in middenbrabant gewerkt.

Je zou eens kunnen informeren bij het ROM (regio overleg midden brabant) of gemeente Oosterhout.
Oosterhout is bezig een met een shared service center, ook voor omliggende gemeenten.
Zij hebben daar vast al eens over nagedacht.

[Helsie]

ajhaverkamp schreef op vrijdag 27 juli 2007 @ 11:55:
Wat bedoel je met de termen "midoffice" en een "service oriented architecture". Mij zegt het helemaal niks. Ik werk nu ruim 10 jaar bij een onderdeel van de gemeente Amsterdam. Stadsdelen en gemeentelijke diensten zijn in principe volledig autonoom op het gebied van ICT. De afgelopen jaren zijn er 2 clubs opgericht voor het centraal regelen van personeelszaken (HRM volgens de modetermen) en voor ICT. Echt van de grond komen wil het niet, enkel gemeenteonderdelen die gedwongen worden om mee te doen, doen mee. Bedoel je zoiets?

Wat jij noemt, is meer inderdaad, zoals Sjakskus al zegt, het Shared Service Center idee. Dat is bij ons ook al ingericht, maar vanuit een technisch oogpunt niet meer dan logisch dat je alles vanuit 1 punt wil beheren en niet 5 met elkaar botsende en geïsoleerde ICT afdeling wilt hebben binnen 1 gemeentelijke organisatie, dus daar wil ik het in dit topic niet teveel over hebben.

Midoffice is het best te schetsen via een plaatje (binnen onze afdeling Informatievoorziening heeft iedereen dit al 300x gezien):



Het is in het plaatje van frontoffice (klantcontacten) en backoffice (technische infrastructuur) een nieuwe laag die zich bezig houdt met het inrichten van centrale (gedeelde) gegevensverzamelingen en applicaties, het koppelen van verschillende backoffice systemen (van niet-ICT afdelingen) en het aanbieden van generieke (zoveel mogelijk herbruikbare) onderdelen om processen mee te automatiseren. Bij ons betekent dat bijv het digitale loket en de binnenkomende aanvragen via dat loket. De midoffice zorgt er middels de Service Oriented Architecture voor dat de aanvraag bij alle betrokken afdelingen terecht komt en centraal geregistreerd wordt.

Service Oriented Architecture betekent dus niets anders dan dat je een architectuur inricht om complete diensten (processen) aan te bieden, in plaats van allemaal losse programma's die niet met elkaar kunnen praten. Hierbij wordt vooral gebruik gemaakt van XML berichten en webservices. Systemen die daar niet mee kunnen werken, worden via alternatieve wegen gekoppeld (desnoods via (proprietary) file communicatie).

Sjakskus schreef op vrijdag 27 juli 2007 @ 12:00:
Je zou eens kunnen informeren bij het ROM (regio overleg midden brabant) of gemeente Oosterhout.
Oosterhout is bezig een met een shared service center, ook voor omliggende gemeenten.
Zij hebben daar vast al eens over nagedacht.

Wij hebben er ook al wel over nagedacht hoor... Maar ik wilde een beetje ervaringen uitwisselen met tweakers die daar ook echt zelf mee bezig zijn (en geïnteresseerden wil ik er natuurlijk ook best over vertellen, dus vragen zoals 'wat is het in godsnaam' vind ik leuk om te beantwoorden. )

[ Voor 6% gewijzigd door Helsie op 27-07-2007 13:44 ]

[Sjakskus]

Ik bedoelde ook dat zij misschien een leuke sparringspartner zijn,
Zij zitten met dezelfde situatie en zij hebben ongetwijfeld ook een soortgelijke omgeving.

Je zou dan ook eens een dagje bij hun gaan kijken en visa versa.

[ Voor 17% gewijzigd door Sjakskus op 27-07-2007 13:52 ]

[Jabba]

Dit begint erg hot te worden idd, hier (wageningen) staat het nog aan het begin van het gebeuren, afwachtende houding

[ajhaverkamp]

Hmmm, ik heb nu een tijdje naar het plaatje zitten staren en de tekst een paar keer gelezen, maar ik snap het nog niet.
Enerzijds bedoel je de "één-loket functie". Een éénduidige voorkant voor oa de burger.
Aan de andere kant zitten de systemen zoals de bestaande databases.

Daartussen bouw je dan een systeem zodat de klant (oa burgers en intern personeel) dat kan benaderen? Bv via webservers?

Edit: ik ben techneut, geen beleidsmaker dus wil ik het snappen waar het daarwerkelijk over gaat en niet wat kreten en kleurige grafiekjes zien en dan meteen denken: hmm, die is extern, die weet waar het over gaat, dat moeten wij ook hebben. (Geen verwijt richting jou hoor)

[ Voor 25% gewijzigd door ajhaverkamp op 27-07-2007 14:05 ]

[Helsie]

ajhaverkamp schreef op vrijdag 27 juli 2007 @ 14:03:
Hmmm, ik heb nu een tijdje naar het plaatje zitten staren en de tekst een paar keer gelezen, maar ik snap het nog niet.
Enerzijds bedoel je de "één-loket functie". Een éénduidige voorkant voor oa de burger.
Aan de andere kant zitten de systemen zoals de bestaande databases.

Daartussen bouw je dan een systeem zodat de klant (oa burgers en intern personeel) dat kan benaderen? Bv via webservers?

_{(Ik wil zelf ook alles snappen, ben ook hier vanuit de technische beheer kant gekomen, dus ik vind het niet meer dan normaal dat mensen willen snappen hoe dingen écht werken als ze ergens iets van willen weten )}

Maar je vat het goed samen. We willen 1 voorkant voor burgers, welke bestaat uit email, telefoon, balie, internet loket. Maar het is wel de bedoeling dat al die contact-varianten van de voorkant toegang hebben tot dezelfde gegevens. Dus als een burger belt, dat degene die de burger helpt ook kan zien wat deze burger via het internet loket heeft aangevraagd, etc. Verder heb je aan de achterkant te maken met allemaal verschillende systemen: compleet eigen technologie/gesloten dabases/protocollen/etc. Het mooiste voorbeeld is misschien wel wat je moet aanvragen aan vergunningen als je een café wil beginnen. Dan komt er echt alles bij kijken: Huisvesting, milieu, horeca, etc. Vroeger moest men dan 31 vergunningen (serieus...) aanvragen en dan moest je ook nog zelf weten welke vergunningen. Nu (of in de nabije toekomst dan... ) kies je voor het 'product' 'café beginnen' in het digitale loket.
Het loket (Webserver) genereert een XML-bericht wat verstuurd wordt naar BizTalk.
BizTalk pakt het bericht op en herkent het als bericht van een bepaald proces (kan danwel aan de hand van de inhoud van het bericht zijn danwel aan de wijze waarop het binnenkomt).
In BizTalk zijn de processen beschreven die dat bericht moet doorlopen, maw welke andere partijen (verschillende gemeentelijke backoffice afdelingen het bericht moeten ontvangen en op welke wijze. BizTalk vertaalt het bericht naar de verschillende indelingen (voor zover het zelf gekozen formaat niet voldoet) en stuurt het door. Maar daarbij kan BizTalk ook het bericht/de aanvraag in CRM opslaan, een aanvraag in SharePoint opslaan, etc. Dat is allemaal vrij te configureren en dus ontzettend krachtig.
Communicatie verloopt meest via SOAP (Webservices) in XML-formaat en evt ook via FILE communicatie (bij gebrek aan webservices). Als een status verandert en dat wordt weer centraal opgeslagen, kan de burger in zijn 'Mijn Loket' online zien wat de status is en een medewerker van de 'klantenservice' kan het in de systemen ook zien.

Door gebruik te maken van centrale gegevensverzamelingen kun je er bijv voor zorgen dat Sociale Zaken niet een adres heeft van burger X dat afwijkt van het adres dat burgerzaken van burger X heeft. Dus dat is zeker een vereiste om je eigen gegevens eenduidig en correct te houden. Op deze manier kan er dus een integrale dienstverlening aangeboden worden: Processen en gegevens zijn over verschillende afdelingen heen op elkaar afgestemd.

Ik weet niet of dit de boel een beetje verduidelijkt?

---
Toevoeging:
Dat 'een systeem' in de quote

Daartussen bouw je dan een systeem zodat de klant (oa burgers en intern personeel) dat kan benaderen? Bv via webservers?

moet je dus breder zien als een geheel van systemen, met inderdaad webservers, maar ook webservices (zijn andere dingen! draaien wel op een webserver, maar dienen puur voor het op- en-neer sturen van berichten via HTTP protocol, zie het als een 'POST'-actie op een website waarbij je variabelen doorgeeft), maar ook verschillende databases. En dat geheel is dus die Service Oriented Architecture.

BizTalk is in het midden van dit geheel de broker (makelaar) die alles afhandelt, vertaalt, etc. Op dat niveau kun je dus ook je monitorring doen of alles goed loopt. BizTalk moet berichten ontvangen, verwerken en verzenden. (En dat deel beheer ik dus, functioneel en deels technisch).

[ Voor 20% gewijzigd door Helsie op 27-07-2007 14:35 ]

[ajhaverkamp]

Helsie schreef op vrijdag 27 juli 2007 @ 14:27:
[...]
Ik weet niet of dit de boel een beetje verduidelijkt?

Ja, dat maakt voor mij de boel een stuk duidelijker.

Momenteel kan de burger van Amsterdam een zeer beperkt aantal zaken regelen via een centraal e-loket. Als ik nu kijk wat er precies aangeboden wordt, krijg in een "java.lang.NullPointerException" error. Dus wat de produkten zijn, kan ik nu niet zien.
Voor zover ik weet gebeurt dat vooral via e-mail. De gemeente Amsterdam is nogal groot, dit soort zaken dien je centraal te regelen. Ons stadsdeel (Centrum) kan op eigen houtje niks doen. Bv een paspoort kan de bewoner van stadsdeel Centrum in alle andere stadsdelen ook aanvragen. Dus moet het centraal gebeuren. Dit soort gegevens staan bij het Register van Amsterdam.
En dan kom je bij het probleem dat iedereen zijn eigen systemen heeft draaien voor heel veel andere dingen, zoals: horecavergunningen, bouwvergunningen, koninginnedagvergunningen, openbrekingen, etc etc. Ongeveer elk systeem gebruikt zijn eigen NAW gegevens, dus trek die eerst maar eens 1op1 gelijk.
Alle hardware staat op de lokatie van de dienst of het stadsdeel. Meestal is tussen de diensten/stadsdelen wel een koppeling via het gemeentelijk e-net (heette vroeger GDA, gemeentelijk datanet Amsterdam). Dus is het wel te ontsluiten via één centraal punt. Echter moet je dan voor heel veel dingen een koppeling gaan regelen, daar is niet aan te beginnen.
Dan zul je waarschijnlijk toch eerst de hele ICT van de gemeente Amsterdam moeten centraliseren. In totaal telt de gemeente Amsterdam zo'n 20.000 man, verspreid over vele lokaties. Doordat het nu redelijk kleine clubjes zijn (hier 800 werkplekken en 13 man ICT) ben je wel flexibel met alles.

Samenvattend lijkt het me dat het hier niet snel van de grond zal komen. Natuurlijk zie ik wel in dat het natuurlijk een fantastisch iets is als je als burger even aanlogt met de DigiD code en dan van alles en nog wat kunt regelen.
Als techneut kijk ik meteen naar de oplossing (wordt me ook regelmatig verweten door collega's) en zie dan op dit moment te veel onoverkomelijke knelpunten.

(Momenteel loopt hier een digitaliseer project mbt archieven en poststromen, dan zie je meteen weer dat het ambtelijk personeel wat ouder is en nogal wat moeite heeft met (technische) aanpassingen. Netjes gezegd)

[Helsie]

ajhaverkamp schreef op vrijdag 27 juli 2007 @ 15:19:Samenvattend lijkt het me dat het hier niet snel van de grond zal komen. Natuurlijk zie ik wel in dat het natuurlijk een fantastisch iets is als je als burger even aanlogt met de DigiD code en dan van alles en nog wat kunt regelen.
Als techneut kijk ik meteen naar de oplossing (wordt me ook regelmatig verweten door collega's) en zie dan op dit moment te veel onoverkomelijke knelpunten.

Het nadeel is dat er landelijke richtlijnen zijn, die voorschrijven dat gemeentes hieraan moeten (gaan) voldoen... Dus zelfs Amsterdam moet er ook aan geloven, neem ik aan? Het is mij overigens nog niet volledig duidelijk wat de 'boete' is als er door een gemeente niet voldaan wordt aan de eisen...

Centralisatie van de IT hebben we hier al achter de rug (kleine 2500 werknemers bij de gemeente Breda, het Shared Service Center - Informatievoorziening bevat volgens mij rond de 80 werknemers (15 midoffice, 35 backoffice, 30 frontoffice)). Het mooie van de architectuur is dat je verschillende systemen die niet rechtstreeks met elkaar kunnen praten via de broker wel met elkaar laat communiceren. Daardoor hoef je niet direct centraal alle systemen te vervangen. Maar 1 geïntegreerde infrastructuur is natuurlijk wel een handige basis om dergelijke zaken samen te laten werken... Dan is er in elk geval een technische verbinding tussen eea...

[Rudedadude]

Helsie schreef op vrijdag 27 juli 2007 @ 14:27:
[...]
Het mooiste voorbeeld is misschien wel wat je moet aanvragen aan vergunningen als je een café wil beginnen. Dan komt er echt alles bij kijken: Huisvesting, milieu, horeca, etc. Vroeger moest men dan 31 vergunningen (serieus...) aanvragen en dan moest je ook nog zelf weten welke vergunningen. Nu (of in de nabije toekomst dan... ) kies je voor het 'product' 'café beginnen' in het digitale loket.

Ik betwijfel of het ooit zo simpel wordt dat er een product 'cafe beginnen' komt Ook in dat geval zal je nog moeten weten of je daarvoor in jouw situatie zaken als een drank en horecavergunning, terrasvergunning, bouwvergunning, 8.40 melding, bestemmingsplanvrijstelling en gebruiksvergunning nodig hebt, maar wordt je daar als het goed is wel in begeleid door de gemeente. Ook moeten dan door een verbeterde interne informatievoorziening voorkomen worden dat je niet eerst 4 van de 5 vergunningen aanvraagt en krijgt, en dat je tenslotte de laatste vergunning geweigerd wordt, waardoor de andere 4 ook waardeloos zijn. Hier is de overheid op het gebied van de omgevingsvergunning (Wabo) al mee bezig, waarbij er voor gezorgd wordt dat er 1 beslissing genomen wordt over zaken die nu nog verschillende vergunningen zijn. Ergens in 2008-2009 zullen we gaan zien hoe dat gaat lopen.
Verder volg ik de hele mid-office ontwikkelingen, Andez aanbestedingen e.d. redelijk, omdat ik op de hoogte wil zijn van de ontwikkelingen. Het klinkt allemaal alsof de techniek niet zo het probleem hoeft te zijn, maar zoals Arjan al aangeeft zijn het uiteindelijk mensen die er mee moeten gaan werken.

[R3M1]

... laat maar

[ Voor 96% gewijzigd door R3M1 op 27-07-2007 17:59 ]

[kraats]

Ik werk bij een kleine gemeente (Nunspeet) en wij zoeken het vooralsnog niet in een broker, maar meer in een mid-officepakket wat zelf alle koppelingen onderhoudt. We zijn in vergevorderde gesprekken met bijvoorbeeld BCT, met hun pakket Corsa. Op die manier begin je met een paar producten op deze manier ontsluiten en dat breid je steeds verder uit. In één keer helemaal klaar zijn zal technisch niet lukken, maar organisatorisch zeker niet. Vooral omdat het een veel projectmatigere manier van werken betekent. Maar het doel is er en dus weet ik dat ik de komende jaren nog wel wat werk te doen heb

[Verwijderd]

Ik ben een student aan de Universiteit Twente en bezig met een behoefteonderzoek bij gemeenten op het gebied van elektronische dienstverlening en de invulling van de midoffice. Op dit moment ben ik al bij een aantal gemeenten geweest en er is een duidelijk verschil te zien tussen gemeenten met een "dikke" midoffice en met een "dunne" midoffice.

Ik denk dat het voor gemeenten belangrijk is om te bepalen waar hun voorkeur naar toe gaat. Gemeente die kiezen voor een dunne midoffice vinden functionaliteit als workflow management en CRM minder belangrijk als gemeenten die kiezen voor een "dikke" midoffice. Dit heeft vooral te maken met het feit dat Backoffice applicaties deze functionaliteiten ook bieden binnen hun specifieke domein. Als je geen taken verschuift van de backoffice naar de midoffice is deze functionaliteit dus ook niet noodzakelijk.

Voor het uitbreiden van mijn onderzoek ben ik nog op zoek naar gemeenten die kiezen voor een "dikke" midoffice. Werk jij ben een gemeente die kiest voor een “dik” midoffice en ben je betrokken bij de inrichting hiervan en wil je meewerken aan mijn onderzoek (interview van +/- 1 1/2 uur), stuur me dan even een e-mailtje dan neem ik contact met je op.

Zie voor de verschillen tussen "dik" en "dun": http://www.vhic.nl/defaul...99420036&FOLDER=4214BDSYS

[Helsie]

Op dit moment lijkt ons midoffice meer op een dun midoffice (met enkele 'dikke' aspecten). Dus ik weet niet of dit interessant is voor je onderzoek?

Op termijn zal dit wel steeds meer een dik midoffice worden, maar zoals de pagina die je gaf treffend beschrijft, is de macht van de verschillende backoffices te groot (en de processen te complex) om dat nu al zo op te pakken. De organisatie is wat dat betreft nog volop bezig met 'kantelen' (van taakgericht naar procesgericht werken)...

[ Voor 53% gewijzigd door Helsie op 30-07-2007 11:12 ]

[Verwijderd]

Helsie schreef op maandag 30 juli 2007 @ 11:09:
Op dit moment lijkt ons midoffice meer op een dun midoffice (met enkele 'dikke' aspecten). Dus ik weet niet of dit interessant is voor je onderzoek?

Welke 'dikke' aspecten?

[Helsie]

Bij een aanvraag schrijven we de aanvraag niet alleen weg naar de backoffice systemen, maar doen we een 'kopie' naar CRM en zakenmagazijn, wat dus echt beheerd wordt door de midoffice. Hierin wordt statusinformatie bijgehouden. Dus we doen iets meer dan een dun midoffice, maar op termijn moet dat (veel) meer worden. De eerste 'echte' dunne toepassing wordt binnenkort het electronisch maken van afspraken, wat volledig zonder backoffice medewerkers/applicatie plaats zal vinden.

[Verwijderd]

Ik ben vooral op zoek naar gemeenten die ook iets doen met workflowmagement in hun midoffice. Merk namelijk dat dit onderdeel in mijn onderzoek nog maar zeer beperkt naar voren komt. Denk dat dit vooral komt omdat gemeenten nog niet zover zijn.

[Rudedadude]

Tja, ga op bezoek in Dordrecht met hun Mozaiek Daar zijn inmiddels een heel aantal vergunningenprocessen gedigitaliseerd. En definieer je term workflow goed, want de manier waarop de term gehanteerd wordt verschilt nogal eens. Ik neem aan dat je bij workflow icm met een midoffice graag ziet dat vanuit de workflow bijvoorbeeld statusinformatie voor de burger wordt teruggekoppeld, voortgangsbewaking, etc.

[ Voor 54% gewijzigd door Rudedadude op 30-07-2007 13:00 ]

[Verwijderd]

Ja idd maar ook de interne processturing. Vooral met de ontwikkeling zoals de WABO wordt processturing voor het afhandelen van vergunningsaanvragen belangrijker omdat het dan meerdere afdelingen/applicaties betreft en ben zeer benieuwd hoe gemeenten daar mee omgaan.

[ Voor 11% gewijzigd door Verwijderd op 30-07-2007 14:33 ]

[Verwijderd]

Rudedadude schreef op maandag 30 juli 2007 @ 12:57:
Tja, ga op bezoek in Dordrecht met hun Mozaiek Daar zijn inmiddels een heel aantal vergunningenprocessen gedigitaliseerd.

Bedankt voor de tip!!

[Helsie]

Verwijderd schreef op maandag 30 juli 2007 @ 12:16:
Ik ben vooral op zoek naar gemeenten die ook iets doen met workflowmagement in hun midoffice. Merk namelijk dat dit onderdeel in mijn onderzoek nog maar zeer beperkt naar voren komt. Denk dat dit vooral komt omdat gemeenten nog niet zover zijn.

Wij zijn inderdaad nog niet zo ver. De intenties zijn er wel, maar het is hier nog niet geïmplementeerd (of zelfs nog maar in het implementatie traject). We overwegen K2 .Net voor het bouwen van workflow processen, maar dat pakket moeten we nog evalueren.

[Verwijderd]

Hebben jullie toevallig de producten van Pallas Athena overwogen?
Een hoop gemeenten hebben hun procesbeschrijvingen al in Protos gemaakt, maar schijnen toch te kiezen voor andere producten als het aankomt op workflowmanagement en dat terwijl ze Protos kunnen uitbreiden tot Protos activate of zelfs FLOWer.
Tja Pallas Athena is mede opdrachtgever dus vandaar...

[Rudedadude]

Dan kan jij beantwoorden of:

Procesbeschrijvingen gemaakt in Protos inderdaad niet gebruikt kunnen worden in Flower, iets wat ik gehoord heb. Dan heb je namelijk meteen een goede reden te pakken

Tweede reden lijkt mij het maken van koppelingen. Veel gemeenten kiezen ervoor om de workflowtool van het reeds aangeschafte DMS te gebruiken, dan kunnen ze gebruik maken van dezelfde applicatie en hoeven er geen 'nieuwe schermen' geleerd te worden.

Derde reden is dat het hebben van een procesbeschrijving niet betekent dat je daar vervolgens makkelijk een workflow mee kunt inrichten. Processen kunnen tenslotte vanuit heel andere oogpunten of aandachtsgebieden beschreven zijn (waarvan rechtmatigheid een mooi voorbeeld is), en de consistentie en manier van beschrijven van de processen moet behoorlijk goed zijn om deze eenvoudig te kunnen gebruiken voor workflow. Vaak zal je er een heel aantal stappen tussenuit willen slopen die voor het proces wel van belang zijn, maar die het uitvoeren van de workflow niet genoemd moeten worden.

[Helsie]

We hebben wel producten van Pallas Athena in gebruik binnen de gemeente, maar dat zijn afdelingsspecieke gebruikers(groepen) (geloof ik). De reden dat we in eerste instantie K2 .Net overwegen is de verregaande integratie met het Microsoft .Net platform, wat we hier gebruiken icm BizTalk. Maar ik zit zelf niet in dat keuzetraject. Maar gemeentebreed is Protos bij ons dus niet in gebruik (dat weet ik nog net wel ), dus dat zal voor ons niet direct de overweging zijn.

[sariel]

Pff......leuke kreten allemaal....

wat ik mij (als burger) nou zit af te vragen is of er, in plaats van duur klinkende bullshit, nou eindelijk eens wat gedaan wordt aan de hoeveelheid bureaucratie (2 uur in rij wachten om een ticket in te mogen leveren om een paspoort aan te mogen vragen bijvoorbeeld), de beveiliging (al bij genoeg van die toko's langs geweest voor m'n werk waar uberhaubt geen beveiliging was omdat geen enkele beheerder een idee had in welk werelddeel de klok misschien zou kunnen hangen), onlogische procedures (van het ook van de inwoners gezien), etc.

dan klinkt dat "service oriented architecture" wel aardig, maar komt er voor de uiteindelijke gebruikers (de inwoners van de gemeenten) dan ook enige voortgang in?

[kraats]

dat is nu juist de bedoeling. zoveel mogelijk producten digitaal beschikbaar maken (24 x 7) en zorgen dat burgers maar één keer hoeven te authenticeren en dan al hun aanvragen op één plek inzichtelijk zijn. Nu zijn er voor de meeste processen aparte backoffice-applicaties gebouwd die onderling geen koppeling hebben. De bedoeling is dat alle info over elke burger in één centrale database raadpleegbaar is, waardoor je een eigen klantendossier krijgt met alle voor jou nuttige informatie.

[Helsie]

sariel schreef op maandag 30 juli 2007 @ 15:34:
Pff......leuke kreten allemaal....

Ondanks je ontzettend positieve manier van benaderen en volledig logische manier van alles schetsen zal ik toch proberen stap voor stap antwoord te geven. (ik weet niet in welke gemeente je woont en ik spreek ook geenszins namens de gemeente Breda, maar gewoon vanuit persoonlijke titel hoe ik het zie! )

wat ik mij (als burger) nou zit af te vragen is of er, in plaats van duur klinkende bullshit, nou eindelijk eens wat gedaan wordt aan de hoeveelheid bureaucratie (2 uur in rij wachten om een ticket in te mogen leveren om een paspoort aan te mogen vragen bijvoorbeeld),

In 1 rij staan en daarna klaar zijn heeft niets met de hoeveelheid bureaucratie te maken. Dat zou het zijn als je zelf langs 5 balies moet om het te regelen. Dus dat is puur een capaciteitsprobleem. Ook soms een kwestie van timen hoe laat je langsgaat.

de beveiliging (al bij genoeg van die toko's langs geweest voor m'n werk waar uberhaubt geen beveiliging was omdat geen enkele beheerder een idee had in welk werelddeel de klok misschien zou kunnen hangen),

Ik heb werkelijk geen idee wat je hiermee bedoelt. Het verband tussen beveiliging en klokken zie ik niet zo...

onlogische procedures (van het ook van de inwoners gezien), etc.

Wat bedoel je hiermee?

dan klinkt dat "service oriented architecture" wel aardig, maar komt er voor de uiteindelijke gebruikers (de inwoners van de gemeenten) dan ook enige voortgang in?

Op dat laatste punt durf ik volmondig ja te antwoorden. Het hele concept van digitale dienstverlening is natuurlijk iets dat de burger meteen merkt:
- 24 uur per dag beschikbaar, dus op elk willekeurig moment dat het de burger uitkomt,
- beschikbaar vanaf de plaats waar het de burger uitkomt.
- Concreet heb je natuurlijk geen balie-wachttijden meer voor alle producten die digitaal afgehandeld kunnen worden en dus ontlast dit drukte bij de balies. Daardoor hebben ze daar weer meer tijd om de zaken die wel langs de balie moeten af te handelen.
- Daarbij is het ook nog eens goedkoper, want hiermee pak je de belasting bij de bron aan, in plaats van simpelweg meer balies open te gooien (wat veel meer geld zou kosten!).
- Snelheid van afhandeling kan omhoog (een aanvraag bestaat digitaal en hoeft dus niet overgeklopt te worden, als alles goed is ingericht. Tevens geen post-vertraging (intern + extern).
- Je hoeft minder info op te geven. Door de nieuwe aanpak is alle relevante info van afdeling X ook bekend bij afdeling Y, zodat je niet meer je adres op 4 plaatsen door hoeft te geven, zoals in het verleden wel kon gebeuren.
- Bepaalde producten die in het verleden verschillende losse aanvragen waren, kunnen straks in 1x aangevraagd worden, door één en hetzelfde formulier in te vullen. De gemeente (maw de midoffice infastructuur) zorgt ervoor dat alles bij de juiste afdelingen terecht komt.
- Je kunt online de status van je aanvraag (of aanvragen) terugzien, waardoor de voortgang helderder is.
etc etc

Genoeg redenen wat je ervan merkt/gaat merken?

[sariel]

Helsie schreef op maandag 30 juli 2007 @ 15:55:
In 1 rij staan en daarna klaar zijn heeft niets met de hoeveelheid bureaucratie te maken. Dat zou het zijn als je zelf langs 5 balies moet om het te regelen. Dus dat is puur een capaciteitsprobleem. Ook soms een kwestie van timen hoe laat je langsgaat.

Het valt zelden te timen op welke tijd langsgegaan kan worden. Er is 1 dag waarbij zowel de gemeente open is en ik vrij heb. Donderdag avond. En laat dan de rest van de stad ook langs moeten komen, want ook zij kunnen niet tijdens werktijden zomaar vrij nemen. En capaciteit...ja...de ene helft van de medewerkers zit druk te werken (1 papiertje invullen, zoeken naar papier 2, 3, 4, en 5, die invullen, dan bijbehorende papieren opzoeken en invullen, etc...dat bedoelde ik met bureaucratie)

[...]
Ik heb werkelijk geen idee wat je hiermee bedoelt. Het verband tussen beveiliging en klokken zie ik niet zo...

blijkbaar....wat ik er mee bedoel is dat alles geautomatiseerd wordt maar de medewerkers die alles moeten beheren krijgen vaak of geen tijd om te leren hoe de nieuwe applicaties werken of krijgen niet genoeg tijd om hun dagelijkse werkzaamheden te doen of zijn uberhaubt niet geschikt voor systeembeheer omdat ze er de kennis en ervaring niet hebben (vaak wordt "windows installeren" door p&o vaak al gezien als hoofdvereiste en als je het kan ben je al een computer guru).

[...]
Wat bedoel je hiermee?

Dat er vaak procedures zijn waarbij het voor de inwoners gewoon niet duidelijk is waarom die procedures er zijn of wat het nut er voor is. bijvoorbeeld een document moeten aanvragen bij de gemeente om bij een ander loket een ander document aan te moeten vragen, ook als de afdelingen de informatie uit dezelfde bron kunnen halen (vaak kan er meegekeken worden op de schermen en dan zie je dat ze gewoon dezelfde programma's open hebben staan.....), maar dan moet het op die manier, "omdat dat de procedure is". Medewerkers (niet alleen bij overheden) hebben nogal eens de neiging om aan de oude procedures vast te houden omdat ze die kennen en geen zin hebben om al die nieuwe "onzin" te moeten leren, want "vroeger ging het zo en dat werkte toch ook?".

[...]

Op dat laatste punt durf ik volmondig ja te antwoorden. Het hele concept van digitale dienstverlening is natuurlijk iets dat de burger meteen merkt:
- 24 uur per dag beschikbaar, dus op elk willekeurig moment dat het de burger uitkomt,
- beschikbaar vanaf de plaats waar het de burger uitkomt.
- Concreet heb je natuurlijk geen balie-wachttijden meer voor alle producten die digitaal afgehandeld kunnen worden en dus ontlast dit drukte bij de balies. Daardoor hebben ze daar weer meer tijd om de zaken die wel langs de balie moeten af te handelen.
- Daarbij is het ook nog eens goedkoper, want hiermee pak je de belasting bij de bron aan, in plaats van simpelweg meer balies open te gooien (wat veel meer geld zou kosten!).
- Snelheid van afhandeling kan omhoog (een aanvraag bestaat digitaal en hoeft dus niet overgeklopt te worden, als alles goed is ingericht. Tevens geen post-vertraging (intern + extern).
- Je hoeft minder info op te geven. Door de nieuwe aanpak is alle relevante info van afdeling X ook bekend bij afdeling Y, zodat je niet meer je adres op 4 plaatsen door hoeft te geven, zoals in het verleden wel kon gebeuren.
- Bepaalde producten die in het verleden verschillende losse aanvragen waren, kunnen straks in 1x aangevraagd worden, door één en hetzelfde formulier in te vullen. De gemeente (maw de midoffice infastructuur) zorgt ervoor dat alles bij de juiste afdelingen terecht komt.
- Je kunt online de status van je aanvraag (of aanvragen) terugzien, waardoor de voortgang helderder is.
etc etc

Genoeg redenen wat je ervan merkt/gaat merken?

Ik hoop echt dat de gevolgen die je noemt ook daadwerkelijk gaan gebeuren, het zou een hoop kopzorgen schelen en mijn gezeur een stuk minder maken

[Verwijderd]

Rudedadude schreef op maandag 30 juli 2007 @ 15:18:
Procesbeschrijvingen gemaakt in Protos inderdaad niet gebruikt kunnen worden in Flower, iets wat ik gehoord heb. Dan heb je namelijk meteen een goede reden te pakken

Tweede reden lijkt mij het maken van koppelingen. Veel gemeenten kiezen ervoor om de workflowtool van het reeds aangeschafte DMS te gebruiken, dan kunnen ze gebruik maken van dezelfde applicatie en hoeven er geen 'nieuwe schermen' geleerd te worden.

Derde reden is dat het hebben van een procesbeschrijving niet betekent dat je daar vervolgens makkelijk een workflow mee kunt inrichten. Processen kunnen tenslotte vanuit heel andere oogpunten of aandachtsgebieden beschreven zijn (waarvan rechtmatigheid een mooi voorbeeld is), en de consistentie en manier van beschrijven van de processen moet behoorlijk goed zijn om deze eenvoudig te kunnen gebruiken voor workflow. Vaak zal je er een heel aantal stappen tussenuit willen slopen die voor het proces wel van belang zijn, maar die het uitvoeren van de workflow niet genoemd moeten worden.

Ik ben nog niet helemaal thuis in wat allemaal wel en niet kan... maar een ding weet ik wel Protos modellen kunnen wel in FLOWer hergebruikt worden (en dus eventueel ook aangepast worden)

Ik ben inderdaad ook veel gemeenten tegen gekomen die de workflowintegratie kiezen bij hun DMS, waarbij hun DMS vaak ook nog onderdeel is van het zakenmagazijn. Het nadeel hiervan is denk ik dat deze systemen in eerste instantie toch een DMS zijn en dus workflowfunctionaliteit missen (workflowaanpassingen etc). Maar ik heb natuurlijk niet alle mooie systemen gezien

Tja dat derde punt is een hele goeie, ik denk idd dat een beschrijving van een workflow meestal gedetaileerder is (met vele kleine tussenstapjes) als een procesbeschrijving. Nu heb ik mij laten vertellen dat je met behulp van Activate een vertaling zou kunnen generen, maar hoe dat precies zit.... ga ik van de week uitzoeken!

[Rudedadude]

Volgens mij precies andersom dan je het zegt. Om een workflow goed in te richten heb je per stap redelijk wat specifieke gegevens nodig, het totaal aantal genomen stappen in een workflow zal volgens mij meestal wat kleiner zijn dan dat je in een procesbeschrijving vast legt. De reden daarvoor is dat je anders een medewerker irriteert door hem mbv de workflow te wijzen op stappen die hij/zij toch wel kent en waarbij er in het systeem weer een handeling verricht moet worden om verder te komen in de workflow. Dan wordt het een soort keurslijf en niet meer een ondersteuning in de werkzaamheden.

Maar goed, om het ook weer een beetje terug te trekken naar de midofice discussie: een vierde reden voor het niet gemeenschappelijk aanschaffen van een workflowtool is de zogeheten eiland-automatisering die je vaak ziet binnen gemeenten. Elke afdeling is hierin zijn eigen weg gegaan en heeft bijvoorbeeld een backofficeapplicatie met workflowfunctionaliteiten (een ...4all van Centric bijvoorbeeld, of Civision van PinkRoccade). Zie zo'n afdeling maar eens zover te krijgen dat dit systeem opgegeven wordt en men zich overgeeft aan de applicatie van een ander organisatieonderdeel waarvan de personen nauwelijks kennis hebben van de processen die op de eigen afdeling worden uitgevoerd. Er zijn gemeenten die inderdaad bewust het beleid voeren dat er 1 workflowpakket gebruikt gaat worden waarmee vroeg of laat alle afdelingen moeten gaan werken, maar dat zijn er niet zoveel volgens mij. In de mooie schema's van de verschillende midoffice architecturen is dat ook niet iets dat 'moet' gaan gebeuren, als uiteindelijk de boel maar met elkaar weet te praten

[PHiXioN]

Overheden proberen juist de macht en afhankelijkheid van Microsoft te verminderen, maar toch rent men meteen daarheen voor een Biztalk oplossing. Dat terwijl er een prima Nederlands bedrijf is dat het zelfde type software levert, Cordys namelijk, dat tevens een heel stuk opener is.


@ AJ

Service orientatie kan voor de overheid betekenen dat verschillende applicaties uit verschillende omgevingen en organisaties kunnen worden gecombineerd om 1 ervaring naar de burger te creëeren. Deze zal dan het idee hebben met de overheid te praten, terwijl het echte dataverkeer voor hem is afgeschermd en wordt geregeld door een broker. Het is zeg maar een soort on-the-fly integratie, althans dat is het doel.

[Helsie]

PHiXioN schreef op dinsdag 31 juli 2007 @ 02:41:
Overheden proberen juist de macht en afhankelijkheid van Microsoft te verminderen, maar toch rent men meteen daarheen voor een Biztalk oplossing. Dat terwijl er een prima Nederlands bedrijf is dat het zelfde type software levert, Cordys namelijk, dat tevens een heel stuk opener is.

Of iets Microsoft of een Nederlands product is, maakt mij niet bijzonder veel uit. Op welke manier is Cordys' software opener? Ik kende het niet (zit nu op de site te kijken en ziet er goed uit, maar het is geen technisch verhaal, dus ik kan het niet echt technisch tov BizTalk (bijv) plaatsen ofzo).

[ajhaverkamp]

Een paar weken geleden had ik er nog nooit van gehoord. Ondertussen ligt er nu een concept van 56 pagina's op mijn bureau over de invoering van midoffice etc bij ons stadsdeel
Leuk om te lezen dat daar veel zaken in genoemd worden die hierboven ook al genoemd zijn, zoals het opgeven van *4all applicaties door andere applicaties, DMS systeem als workflow.......

[Bigbadkip]

-

[ Voor 99% gewijzigd door Bigbadkip op 21-09-2022 12:38 ]

[F_J_K]

Ik heb dit topic toentertijd gemist wegens vakantie. De derde ANDEZ GovUnited aanbesteding is uit en dit kwam ik toen tegen, dus toch even reageren

ajhaverkamp schreef op vrijdag 27 juli 2007 @ 14:03:
Hmmm, ik heb nu een tijdje naar het plaatje zitten staren en de tekst een paar keer gelezen, maar ik snap het nog niet.
Enerzijds bedoel je de "één-loket functie". Een éénduidige voorkant voor oa de burger.
Aan de andere kant zitten de systemen zoals de bestaande databases.

Daartussen bouw je dan een systeem zodat de klant (oa burgers en intern personeel) dat kan benaderen? Bv via webservers?

Edit: ik ben techneut, geen beleidsmaker dus wil ik het snappen waar het daarwerkelijk over gaat en niet wat kreten en kleurige grafiekjes zien en dan meteen denken: hmm, die is extern, die weet waar het over gaat, dat moeten wij ook hebben. (Geen verwijt richting jou hoor)

Die plaatjes zijn niet van hem maar van EGEM

Even heel kort door de bocht: je hebt vele vele backoffice systemen (die ik niet zou willen karakteriseren als technische infra maar kort door de bocht als losse sets van processen en gegevens) die allemaal wat gegevens hebben over burgers en bedrijven, allemaal wat applicaties hebben, etc. Een beperkte sync kan je al doen met datadistributie (DDS4all etc) maar dat gaat alleen op voor een beperkte set van gegevens zoals NAW.

Als je nu gebruik wilt maken van webintake (webformulieren om je hondenvergunning aan te vragen om 3 uur 's nachts ipv. in de rij staan of duur en lang bellen tussen 9 en 16) en als je 1 centrale dienst wilt hebben om je klanten van dienst te zijn, zal je gegevens moeten afstemmen en centraal (of via een SOA, maar er zijn nog amper backoffice systemen die 24/7 in de lucht zijn - als het al een van de zeldzame systemen is die een koppelvlak heeft) gegevens beschikbaar moeten stellen zodanig dat je er centraal bij kan zonder de hele dag 30 applicaties open te hebben staan of elke burger steeds alles opnieuw te laten invoeren.
En dus heb je een superset van gegevens (gegevensmagazijn) en een centrale plaats voor de statusinfo en de ingevulde formulieren etc (zakenmagazijn) nodig. Plus een broker om de boel te vertalen, te cachen als een BO systeem plat ligt en rond te sturen van en naar backoffice, website (formulieren, "mijn gemeente" statusupdates, algemene info zoals gegeven vergunningen, etc) en klantcontactcentrum. Nog leuker wordt het als je backoffice een volledig gesloten systeem is, of als het nu met bijv Excel gaat. Dan kan je in een "dik" midoffice systeem met generieke tools processen inrichten zoals de hondenvergunning aanvraag en afhandeling. En heb je na een tijdje dus geen tig losse applicaties met allemaal eigen workflowsysteempjes, datadefinities, etc, maar 1 centraal systeem waar je generiek eenvoudige processen kan afhandelen en/of monitoren.

Het is deels technisch (broker, adapters, etc) maar vooral organisatorisch (wat willen we weten, welke info is leidend, etc).

Rudedadude: inderdaad zijn super/subzaken ook een leuk 'speeltje' Maar die hoeven IMHO inderdaad qua techniek niet ingewikkelder te zijn; dat moet met een beetje vraaggeleiding / webintake systeem best zijn in te richten.

offtopic:
Leuk om te zien dat in de laatste twee jaar de meeste leveranciers en gemeentes dezelfde terminologie zijn gaan gebruiken. Scheelt imho een hoop langs elkaar heen praten.

Verwijderd schreef op maandag 30 juli 2007 @ 10:43:
Dit heeft vooral te maken met het feit dat Backoffice applicaties deze functionaliteiten ook bieden binnen hun specifieke domein. Als je geen taken verschuift van de backoffice naar de midoffice is deze functionaliteit dus ook niet noodzakelijk.

Het "ideale" geval van alles SOA zie ik nog even niet gebeuren, daar zijn er nog te weinig backoffice systemen te ontsluiten voor alle relevante processen. Neem dat vooral mee in je onderzoek

Overigens, neem vooral contact op met de originele 'andez' gemeenten en inderdaad is Dordrecht wat dat betreft ook een leuke. En check de rest van de gemeenten die worden genoemd in 'Benchmark digitale dienstverlening 2007' van CGEY.

[Rudedadude]

F_J_K schreef op maandag 03 september 2007 @ 17:08:
Ik heb dit topic toentertijd gemist wegens vakantie. De derde ANDEZ GovUnited aanbesteding is uit en dit kwam ik toen tegen, dus toch even reageren

Rudedadude: inderdaad zijn super/subzaken ook een leuk 'speeltje' Maar die hoeven IMHO inderdaad qua techniek niet ingewikkelder te zijn; dat moet met een beetje vraaggeleiding / webintake systeem best zijn in te richten.

Het is niet zozeer de zaakintake met vraaggeleiding die volgens mij daarbij van belang is, maar eerder de zaaktypen die gedefinieerd moeten worden. Betekent het namelijk dat je voor elke mogelijk zaakverloop een apart zaaktype definieert (en daarbinnen statussen, terugkoppelmomenten, etc.) of kies je ervoor een beperkter aantal 'componenten' in te richten die samen de zaak kunnen gaan vormen. Bij dat laatste is het natuurlijk belangrijk om al die dwarsverbanden goed in kaart te hebben en ervoor te zorgen dat de boel goed op elkaar aansluit. Volgens mij is dat nog best lastig, en in de proof of concept van de Andez aanbestedingen is ook tot nu toe gekozen voor een relatief eenvoudig, enkelvoudig proces (evenementenvergunning). Ik heb de verschillende uitwerkingen hiervan niet gezien, maar ik ben onder andere benieuwd hoe daarin zaken als de besluitvorming en facturering zijn opgenomen / uitgewerkt.

[F_J_K]

Inderdaad, je hebt gelijk: ik ging alleen nog maar in op de voorkant. Inderdaad is de inrichting interessanter. En dan moet je inderdaad goed nadenken over de samenhang en juist de onafhankelijkheden tussen de verschillende deelprocessen. Wat dat betreft ben ik benieuwd wat er aan impelementaties is van de omgevingsvergunning / de achterkant van de BRIKS formulieren in het land - en tzt van de 'BKS' formulieren en processen bij andez2. Wabo gaat geloof ik nog wel even duren trouwens, ik zou verbaasd zijn als dat er nog in 2008 komt

De Dordrecht evenementenvergunning beschrijving die wordt gebruikt bij die aanbestedingen is idd enkelvoudig, de (potentiele) leveranciers moeten nu nu al diep hebben zitten zuchtten van het vele werk voor zo'n proof of concept, al is het natuurlijk hartstikke interessant voor de gemeenten om meer te zien dan papieren offertes en PowerPoint presentaties. In de uiteindelijke

[Rudedadude]

Wabo is volgens het ministerie al uitgesteld tot 1 januari 2009, een beetje hetzelfde verhaal als de WKPB, de wetgeving is nog niet op tijd klaar.

Maar het is wel treffend hoe ajhaverkamp het beschrijft, ik kom ook geen gemeente meer tegen of men is bezig, of heeft het over de aanschaf en alle ontwikkelingen rondom het midoffice. En anders begin ik er zelf wel over

[F_J_K]

Yup en yup. Het is de afgelopen twee jaar erg hard gegaan. De 65%-elektronische-dienstverlening-'eis' zal daar best bij geholpen hebben (al is dat "op te lossen" met een website plus een hele grote printer), plus dat de techniek / de leveranciers duidelijk te bieden hebben dan een paar jaar geleden. Dan een vleugje tegen elkaar opbieden via de monitor van overheid.nl en je bent er
Dat en het was hoog tijd dat er wat gebeurde met alle losse systemen. Eens zien waar we over een paar jaar staan met o.a. de basisregistraties.

[ Voor 16% gewijzigd door F_J_K op 05-09-2007 10:13 ]

[Verwijderd]

Ik kom toevallig deze discussie tegen, leuk om te lezen!

@Helsie, ik zou graag wat info uitwisselen via mail ofzo want ben benieuwd wat jullie met Bizztalk hebben draaien nu, ik weet van Cees (nu EGEM-i) dat jullie er toen mee aan de slag zouden gaan. Ik werk zelf in Adam. Het beeld dat van Adam werd geschetst wil ik wel wat recht zetten want we zijn druk bezig met basisregistraties, datadistributie, stuf, service bus, e-dienstverlening, samengestelde e-formulieren etc. Zowel centraal als bij de stadsdelen gebeurt veel.

@AJ: bedoel je jullie DMS selectie? Centrum gaat toch niet zelf een mid office aanschaffen mag ik hopen ;-).

@Frank: je hebt weer tijd over na het bestek zie ik, gelukkig maar ;-)

Groet
Raymond

[Rudedadude]

"Toevallig" een topic tegenkomen waarop 1,5 week niet is gereageerd en daarbinnen je eerste post plaatsen. Dat klinkt niet als toevallig, meer als goed zoekwerk

Ik heb eind vorige week het GU-1 bestek onder ogen gekregen maar die 200 pagina's waren nog even wat teveel om volledig door te nemen en om te doorgronden hoe de complete software-as-a-service opzet met allerlei optionele modules nu precies aan moet gaan sluiten op hetgeen gemeenten zelf al hebben aan software e.d.

[Rudedadude]

Eens een behoorlijk kick tegen dit topic Ik ben benieuwd of er op GoT nog veel personen rondlopen die direct of indirect te maken hebben met de gemeentelijke/overheids informatievoorziening en informatie architectuur, zoals in dit topic behandeld, of zoals neergelegd in de Nora (Nederlandse Overheids Referentie Architectuur)

[F_J_K]

Die zijn er wel ja. Ga gerust door met vragen of stellingen

Ondertussen het GU bestek gelezen en gesnapt? Het kort geding is gewonnen en het loopt (gelukkig?) dus nog steeds.

Wat vinden jullie van NORA, vergeleken met bijv. een insteek zoals ANDEZ/GU1?

offtopic:
En ik weet toevallig dat rerkel GoT al zeker 5 jaar, readonly dan, kent

[VincentH]

NORA en de ANDEZ/ GovUnited aanbestedingen zijn twee losse ontwikkelingen, die overigens wel (kunnen) leiden tot hetzelfde resultaat: standaardisering van architecturen bij de Nederlandse overheid. NORA, doordat het een referentie biedt, ANDEZ/GU doordat gezamenlijke inkoop van bijvoorbeeld mid-office toepassingen (conform de NORA) helpen die architectuurgedachtes ook in de praktijk te brengen. Ze versterken elkaar.
Jammer dat NORA tot nu toe nog vrij abstract is en daarmee vooral voor kleinere organisaties lastig toe te passen. Maar wellicht wordt dat wel meer ingevuld bij NORA 3.0.


Maar al die ICT-oplossingen maken de gemeente van de toekomst niet. Daarvoor moeten de gemeentes eerst een organisatie-ontwikkeling doormaken, die ze in staat stelt om al die ICT-toepassingen ook goed toe te passen. Alle gemeentes zitten achterin INK-fase 1, tot hooguit begin fase 2, terwijl al die integrale toepassingen, zoals een Midoffice en integrale vergunningen als de WABO horen bij systeem-georiënteerde fase 3 organisaties.

[Helsie]

VincentH schreef op woensdag 23 januari 2008 @ 17:19:
NORA en de ANDEZ/ GovUnited aanbestedingen zijn twee losse ontwikkelingen, die overigens wel (kunnen) leiden tot hetzelfde resultaat: standaardisering van architecturen bij de Nederlandse overheid. NORA, doordat het een referentie biedt, ANDEZ/GU doordat gezamenlijke inkoop van bijvoorbeeld mid-office toepassingen (conform de NORA) helpen die architectuurgedachtes ook in de praktijk te brengen. Ze versterken elkaar.
Jammer dat NORA tot nu toe nog vrij abstract is en daarmee vooral voor kleinere organisaties lastig toe te passen. Maar wellicht wordt dat wel meer ingevuld bij NORA 3.0.

NORA beschrijft een ander abstractieniveau dan een concrete aanbesteding. Op het moment dat NORA concreet wordt, is het geen referentie architectuur meer, maar een concrete (verplichte?) richtlijn... Dus ik mag toch hopen dat NORA3 niet té concreet wordt, want dan kunnen ze net zo goed de Overheids ICT centraal gaan reguleren (en dat is anders dan standaardiseren).

[VincentH]

Daar heb je gelijk in. Centraal geregelde overheids-ICT lijkt me zeker geen goed plan! Iets specifieker zijn de ANDEZ/GU aanbestedingen een concrete invulling binnen de NORA-kaders, die de NORA principes verspreidt binnen de overheid.
Het is voor het Rijk in ieder geval overigens al verplicht om NORA te gebruiken als referentie architectuur. Met name uitvoeringsorganisaties zijn nu allemaal druk bezig met het vertalen van de NORA naar hun eigen organisatie.

[Helsie]

VincentH schreef op donderdag 24 januari 2008 @ 07:46:
Daar heb je gelijk in. Centraal geregelde overheids-ICT lijkt me zeker geen goed plan!

Mij wel. Hoe leuk ik het ook vind dat we nu hier in Breda 'onze eigen gang kunnen gaan', zolang we ons aan de NORA richtlijnen houden, landelijk gezien wordt het wiel wél vele malen opnieuw uitgevonden en ik vind dat we aan de burgers verplicht zijn om dat niet te doen. Alle gemeentes voeren dezelfde processen uit (zelfde soorten vergunningen, zelfde burgerzakenproducten, etc etc) en dus vind ik het vrij onzinnig dat alle gemeentes (al dan niet in samenwerkingsverbanden) zelf alles gaan ontdekken en implementeren.

[Rudedadude]

Tja, het lastige is alleen dat je op het moment met een situatie zit waarin verspreid over alle gemeenten duizenden verschillende applicaties worden gebruikt, waardoor de feitelijk situatie bij elke gemeente weer anders is. Je kan niet zomaar even zeggen dat alle gemeenten dat de deur uit moeten doen en collectief moeten kiezen voor product x. Daarnaast is het natuurlijk met name een organisatievraagstuk: niet elke organisatie (of afdeling/cluster/sector/team/whatever) is even ver in het overschakelen naar digitaal werken. Tussen gemeenten onderling, maar ik binnen gemeenten zitten daar enorme verschillen tussen. De gemiddelde leeftijd van een gemeenteambtenaar is ongeveer 44 jaar, niet idereen is even handig met ict

[Helsie]

Rudedadude schreef op donderdag 24 januari 2008 @ 10:02:
Tja, het lastige is alleen dat je op het moment met een situatie zit waarin verspreid over alle gemeenten duizenden verschillende applicaties worden gebruikt, waardoor de feitelijk situatie bij elke gemeente weer anders is. Je kan niet zomaar even zeggen dat alle gemeenten dat de deur uit moeten doen en collectief moeten kiezen voor product x. Daarnaast is het natuurlijk met name een organisatievraagstuk: niet elke organisatie (of afdeling/cluster/sector/team/whatever) is even ver in het overschakelen naar digitaal werken. Tussen gemeenten onderling, maar ik binnen gemeenten zitten daar enorme verschillen tussen. De gemiddelde leeftijd van een gemeenteambtenaar is ongeveer 44 jaar, niet idereen is even handig met ict

Klopt, ik zeg ook niet dat het nu van de ene op de andere dag ingevoerd moet worden. Maar lange termijn mag het best een streven zijn.

[Taigu]

Zeer interessant topic, al zit ik zelf helemaal niet in de overheid. Wat mij direct opvalt is dat er veel vanuit het technische perspectief wordt gekeken naar dergelijke oplossing (niet zo vreemd op t.net). Dit terwijl dergelijke trajecten naar mijn mening veel meer met de "business kant" te maken hebben.

Wat is jullie functie binnen deze instanties ? Hoe verloopt bij jullie de top-down benadering, wie pakt het stuk business architectuur en informatiearchitectuur op ? Of is dit vooraf al bepaald en wordt dit opgelegd ?

[Verwijderd]

Ben er nu ook een 4 weken geleden ingerold.. naar mijn mening zijn er een paar grote obstakels, die gemeenten beletten om intensief met de ontwikkeling van een midoffice aan de slag te gaan.

- de verschillende systemen, die werken, alleen vervangen moeten worden om te voldoen aan de "midoffice"eisen. Er zijn stribbelingen van werknemers. die willen het houden zoals het nu is.
- de verscheidenheid aan aanbieders in software, wie heeft nu daadwerkelijk een juist product
- nauwelijks referentiekaders, gemeenten moeten zeg maar zelf het wiel uitvinden
(nu met andez3 ft. gov united probeert deze een standaard applicatie aan te bieden, zeer goed iniatief!)
- precies uit te leggen wat de gevolgen zijn van de verandering in werkprocessen voor de werknemers (draagvlak creeeren)

zo maar even wat dingetjes waar ik ook mee zit momenteel. Ben net begonnen..

[F_J_K]

Verwijderd schreef op woensdag 27 februari 2008 @ 11:58:
Ben er nu ook een 4 weken geleden ingerold.. naar mijn mening zijn er een paar grote obstakels, die gemeenten beletten om intensief met de ontwikkeling van een midoffice aan de slag te gaan.

Ontwikkeling: bedoel je dan maatwerk, of inrichting op basis van een bestaand pakket? Maatwerk lijkt me, juist gezien de vele pakketten die er ondertussen zijn, zonde van geld en tijd en maakt samenwerken er niet makkelijker op

- de verschillende systemen, die werken, alleen vervangen moeten worden om te voldoen aan de "midoffice"eisen. Er zijn stribbelingen van werknemers. die willen het houden zoals het nu is.

Elke verandering is er een te veel, als het bij iemand 'in my back yard' gebeurt. Maar moet er zoveel vervangen worden dan? Behalve natuurlijk als het ook een (beter dan huidig) DMS/CMS/etc betreft, dat zal er inderdaad al wel zijn.
De natte droom van sommigen is juist dat een middoffice koppelt met alles dat er al draait, zodat er niets moet worden vervangen maar "gewoon" de huidige **4all wordt gebruikt. Zie ik trouwens nog even niet gebeuren (maar wie ben ik ). Leuk wordt het dan om ook, in een "dikke" variant, verouderde of in een brakke Access DB gebouwde applicaties om te zetten naar het midofficeen zo functionaliteit uit te breiden zonder de veelgebruikte backofficesystemen er uit te gooien.

Overigens is, en ik kan niet zeggen dat me dat tegen staat, de wens van anderen juist dat het midoffice middels grotendeels generieke eenvoudige proces(jes)/stappenplannen veel backofficesystemen ook zonder veel te koppelen kan aanvullen (of vervangen) om zo heel snel o.a. voldoende goede e-dienstverlening te kunnen bieden i.c.m. enige webintakefunctionaliteit.

Vraag is dus wat (voor jou) een midoffice omvat; broker+adapters+wat magazijntjes (plus webintake?) of juist een hele "dikke" inrichting incl. (hopelijk lichte) menselijke workflow, DM/CM/etc.

- de verscheidenheid aan aanbieders in software, wie heeft nu daadwerkelijk een juist product

Daar zijn, als het zoveel mag moet kosten, nu juist aanbestedingen voor om het uit te vinden. De luxe van het mogen kiezen wat je zelf zou willen is er vaak niet echt
En ik vind dat de mensen die het komen helpen implementeren (van leverancier, maar ook intern en met wat samenwerking met collega-overheden) zeker zo belangrijk zijn dan 'het doosje'.

- nauwelijks referentiekaders, gemeenten moeten zeg maar zelf het wiel uitvinden
(nu met andez3 ft. gov united probeert deze een standaard applicatie aan te bieden, zeer goed iniatief!)

Gezamelijk oppakken en zo veel mogelijk standaardiseren: graag \o/ Dan trouwens zeker ook v.w.b. de inrichting. Dat iedereen zijn proces-wiebertjes perse anders moet zetten en voor X*Y ipv. X en Y op een formulier wil zien, enkel omdat het "al eeuwen" zo gaat is (IMHO) op enige termijn hartstikke zonde: van het geld, de tijd en ook zeker de kwaliteit. Als er de komende maanden / jaren meer standaardisatie (met voldoende vrijheid) komt op meer dan technisch vlak: graag.

Draagvlak is inderdaad uiteindelijk een heel belangrijk punt.

[ Voor 6% gewijzigd door F_J_K op 27-02-2008 19:49 . Reden: knip, weinig toevoegende opsomming :P ]

[Verwijderd]

*knip pluggen van eigen adviestoko*

[ Voor 87% gewijzigd door Rukapul op 23-06-2009 21:22 ]