Het concept van de MidOffice is zo’n tien jaar geleden bedacht. Het is een echt academisch tekentafel concept en dat niveau is het ook nooit overstegen. Het idee is mooi, de praktijk heeft echter uitgewezen toch weerbarstiger te zijn.
Het is begonnen met een MidOffice. Daarna werd het de ‘Dunne MidOffice’, gevolgd door de ‘Dikke MidOffice’, toen de ‘gekantelde MidOffice’ en nu hoor je er weinig meer over. Niet vreemd dat het stil wordt, want als het concept zo sterk wijzigt klopt er iets niet.
Laten we even in vogelvlucht door de concepten gaan: de ´Dunne MidOffice´ koppelt met de front- office (de intake applicaties) en back-office systemen en laat ze intact. De front- en back-office applicaties behoren in dit concept niet tot de MidOffice.
In het concept van de ´Dikke MidOffice´ moesten de back-office applicaties worden opgenomen in het MidOffice. De back-office applicaties zijn afdelings- en kennisspecifiek terwijl de MidOffice organisatie breed zou moeten worden ingezet. In de tussentijd zijn de functies in de MidOffice opgesplitst over vele componenten die elk hun eigen specifieke en onafhankelijke functie hebben. Uiteindelijk kregen we een MidOffice die gekoppeld moest worden met zoveel applicaties dat de tel werd verloren in het aantal stekkers, waardoor het onderhoud aan al die stekkers zeer arbeidsintensief werd.
De ’gekantelde MidOffice’ is een MidOffice waarbij functies of applicaties niet meer centraal staan maar de organisatie. De organisatie moet kantelen: de medewerkers van de oude back-office worden verspreid over de front-office, de ‘eerste lijn MidOffice’, de ‘tweede lijn MidOffice’ en de back-office.
We leven in een tijd dat onder andere gemeenten, provincies en het rijk fors moeten bezuinigen. Leuke academische architectonische exercities zijn niet meer wenselijk. We moeten terug naar de business. De centrale vraag was, is en blijft: wat heeft de business nodig om werkzaamheden op een zo efficiënte en gebruikersvriendelijke mogelijke wijze uit te voeren? Om dit te bereiken is het nodig om voor elk voorstel voor een functie in een nieuw aan te schaffen of bestaande applicatie tegelijk een onderbouwing mee te laten komen in termen van noodzakelijkheid en kosten. De eisen en wensen in RFI’s en RFP’s kunnen dan drastisch worden ingekort. Tevens zal dan blijken dat het eindeloos opsplitsen van functies uit standaard (geïntegreerde) applicaties omwille van architectuur alleen maar de kosten verhoogt.
Hoe zijn we dan aan die concepten en ideeën gekomen? Het antwoord daarop is redelijk simpel: door advisering van interne consultancy afdelingen en/of van externe consultancy organisaties. Daarbij is het motto vaak dat hoe complexer je het maakt, hoe moeilijker het te doorgronden en te doorzien is voor degenen die beslissingen moet nemen. Je wilt laten zien dat jouw inbreng van waarde is, omdat alleen jij het nog snapt. Hierdoor kost advisering en de daarop volgende implementatie veel meer tijd dan noodzakelijk, maar jij hebt een baan of maakt uren die je kan factureren. Immers, in de praktijk maken softwareleveranciers alleen nieuwe functies als het voor hen kostendekkend is. Wat kunnen gebruikers van software daarvan leren?
Wie oren heeft om te horen, die hore!
Interessante ‘knuppel in het hoenderhok’!
Vraag die bij mij als zoekend gemeentelijke medewerker opborrelt is: ‘Geen midoffice dus? Maar, wat dan?’
Midoffices, al of niet gekanteld, worden aangeboden om medewerkers van een KCC met één applicatie zicht te geven op de voortgang van processen in het gebouw. Van de processen die binnen het midoffice zelf afgehandeld kunnen worden kan gedetailleerde informatie worden verstrekt en van de andere processen is vanuit het midoffice bekend hoe ver het staat met de afwikkeling ervan en bij wie men te rade kan gaan als meer gedetailleerde informatie nodig is. Althans… zo wordt het door de leveranciers verkondigd…
Maar ok, géén midoffice dus…
Vraag die resteert: hoe doet het KCC dan zijn werk? Zoeken in alle beschikbare vakapplicaties?
Met vriendelijke groet,
Johan Michielsen
teamleider Organisatie
(in oriëntatiefase voor een midoffice achtige oplossing)
Het is mij niet duidelijk waar dhr. Sikkema de afgelopen jaren heeft vertoeft, want ik herken de geschetste historie nauwelijks. Het is waar dat we vandaag de dag minder nadruk leggen op het alleen doorgeven van berichten aan backoffices (vanwege incidentele problemen/kosten met koppelingen).
Echter, het concept van een midoffice met een geïntegreerd zaaksysteem, KCS, DMS/RMA, CMS/PDC/PIP/Eformulieren en evt. een ESB is springlevend! Het dreigt zelfs overal bestaande DMS/RMA’s (van o.a. Unisys ECM) te vervangen. Misschien dat daar de zorg van de heer Sikkema vandaan komt?
De specificaties (PvE) voor een dergelijke ‘midoffice suite’ zijn inmiddels voor 95% uitgetrild en dus standaard. Met de komst van WABO en/of mGBA in het midoffice wordt het zaaksysteem bovendien steeds belangrijker. Er valt zodoende ook veel te bezuinigen zoals wij – maar ook gemeenten als De Waard (zie de ‘best gejat’-prijs van KING) – inmiddels hebben aangetoond.
Wat we wel constateren is dat gemeenten veel moeite hebben met de benodigde organisatie- / cultuurverandering. Maar ook niet (of slecht) aanbesteden leidt soms tot kleine drama’s. Maar verder gaat het prima, hoor…