MCTL is ten opzichte van de plek waar werkelijk computertechnologie wordt ingezet (bij gebruikers op de werkplek) altijd ondersteunend. Het zorgt ervoor dat binnen een bedrijf operationeel de bestaande computertechnologie juist wordt gebruikt, dat aanpassingen daaraan juist worden uitgevoerd, er een strategie rondom de toekomstige inzet van computertechnologie bestaat en ook tactisch de juiste aansturing is vormgegeven.
Het demand <> supply model is door MCTL verlaten
De verdeling demand <> supply, met de gebruikersorganisatie aan de demand-zijde en IT aan de supply-zijde, is dus verlaten. De scheiding demand <> supply heeft in het afgelopen tijdperk geholpen om vooral aan de gebruikerszijde scherper te krijgen waar en hoe computertechnologie kan worden ingezet. Maar een al te scherpe scheiding werkt een suboptimale inzet in de hand. Een paar voorbeelden ter illustratie:
1. Een bekende uitspraak van Ford, oprichter van de bekende autofabriek, is: “Als ik mijn klanten had gevraagd wat ze nodig hadden, dan hadden ze gezegd: snellere paarden”.
Met andere woorden: aan de gebruikerszijde is het soms heel moeilijk om afstand te nemen van bestaande mogelijkheden.
2. Steve Jobs deed in dezelfde trant een duit in het zakje: “Vaak weten mensen niet wat ze willen tot je het ze laat zien“.
3. Baliemedewerkers bedenken een toepassing waarbij een groot deel van de afspraken via systemen in de toekomst automatisch worden ingepland. Mooi! Helaas zal daardoor een groot deel van hen hun baan verliezen. Het idee verdwijnt in de diepste bureaula, helemaal achteraan. Terwijl het voor de klanten en i.v.m. de noodzaak tot kostenreductie in het bedrijf van het grootste belang was geweest om dit idee verder uit te werken.
Tot slot een laatste uitspraak in lijn met bovenstaande: “Je moet niet doen wat een klant vraagt, maar waar een klant behoefte aan heeft”.
Voorbeeld 1: De nieuwe auto
We zijn thuis met drie personen: vader, moeder en dochter. Ooit gingen we op zoek naar een nieuwe auto, en conform het demand <> supply model gingen wij, voor de zoektocht begon, onze functionele behoefte specificeren. We kwamen eigenlijk, heel bescheiden, maar op één functionele eis: we willen altijd graag allemaal voorin zitten, dus graag een auto met drie plaatsen voorin.
(NB. Eigenlijk hadden we het natuurlijk nog helemaal niet over “een auto” moeten hebben, maar over “onze vervoersbehoefte”. Die abstractie hebben we maar gelaten voor wat het was.)
Kortom, wij gingen op zoek naar een auto met slechts één, in onze ogen bescheiden, functionele eis: drie mensen moeten allemaal voorin kunnen zitten. De zoektocht eindigde al snel met de constatering dat er eigenlijk maar één auto mogelijk was, en die auto vonden we werkelijk te lelijk voor woorden (wat we nu juist weer niet functioneel hadden bedacht vooraf). Met andere woorden: in je eigen toren nadenken over functionele behoeften, zonder daar ook reële mogelijkheden van leveranciers bij te betrekken, kan leiden tot grote teleurstellingen.
Geen demand <> supply maar samenwerking!
Conclusie die getrokken kan worden na bovengenoemde voorbeelden, is dat indien aan de businesskant volledig wordt uitgedacht wat nodig is, en dan pas de leverancier wordt betrokken, er al snel teleurstellingen ontstaan of kansen worden gemist. Aan de andere kant, een leverancier die ‘ins blaue hinein’ producten en diensten gaat ontwikkelen en aanbieden is ook zeer risicovol bezig. Uiteindelijk is samenwerken, waarbij ieder vanuit zijn eigen expertise werkt, veelal de beste optie.
In het voorgaande hoofdstuk is al een beschrijving van de MCTL-activiteiten en de gewenste plaats daarvan in de organisatie opgenomen. Binnen MCTL wordt uitgegaan van een van de volgende twee mogelijkheden:
Functioneel support (FS) is hiermee op de plaats terecht gekomen die het meest “natuurlijk” is.
Bovenstaande organisatieschema’s kunnen nog wat vollediger worden gemaakt door de organisatie als volgt voor te stellen:
Hierbij is ook de besturing van de organisatie toegevoegd. Ook in dit model is Functioneel support (dus de MCTL-taken) terug te vinden in de laag Ondersteuning. Echter, er dient wel letterlijk een link te zijn met de andere organisatieonderdelen, en daarmee komen we op het volgende volledige schema uit:
De kern van alle activiteiten ligt in het blok Functioneel support (FS), maar binnen elk ander onderdeel van de organisatie is de linking pin, doorgaans in de vorm van een key-user, aanwezig. Deze key-user vervult een aantal lokale taken rondom ondersteuning van gebruikers, en daarnaast de inhoudelijke connectie met de centrale FS. Binnen FS zijn rollen als functioneel beheerder / specialist en functioneel strateeg / architect, evenals bijvoorbeeld business analisten te vinden.