MidOffice is op sterven na dood

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!