Ik dacht, voor zo’n eerste blog-item houd je je toch een beetje in. Niet te hard van stapel lopen, de kat uit de boom kijken, rustig aan dan breekt het lijntje niet: al die gezegden bestaan niet voor niets. Daarom lijkt het me verstandig om me deze keer te beperken tot een eenvoudig onderwerp: requirements.
Want dat is toch wel een beetje een aflopende zaak, requirements.
Voor mij worden het steeds meer de stille getuigen van een aflopend tijdperk waarin bedrijfsvoering en IT lijnrecht tegenover elkaar staan. Op zijn best is het een verstandshuwelijk, waarin requirements als huwelijkse voorwaarden alle romantiek bij voorbaat eruit halen. Ze staan model voor een strikte scheiding van vraag en aanbod met een vraagkant die volgens de aanbieders nooit exact weet wat hij wil hebben en een aanbodkant die nou nooit eens lijkt te kunnen opleveren wat is afgesproken.
Requirements werken vooral niet in een tijdperk waarin steeds meer software standaard vanuit de cloud wordt aangeboden. De essentie van die oplossingen is dat ze multi-tenant zijn: ze hebben vele verschillende huurders die allemaal gebruik maken van dezelfde software. Daar krijg je grote voordelen mee op het gebied van schaal en onderhoudbaarheid. En dat vertaalt zich weer in een veel scherpere prijs. De voorwaarde daarvoor is wel dat er steeds één versie van de software is: eigen aanpassingen door middel van het oude ambacht van customizen is uit den boze; daarmee zou de economische bodem onder software-as-a-service worden weggeslagen.
In die wereld van SuccesFactors, Salesforce en Workday ga je niet meer eerst in splendid isolation specificaties opstellen van waaraan je ideale HRM-, CRM- of Procurement-oplossing zou moeten voldoen (en dan maar oprecht verbaasd zijn dat geen enkele oplossing blijkt te passen). In plaats daarvan kies je pragmatisch voor een platform dat het meest aanspreekt, bijvoorbeeld omdat de leverancier innovatief en inspirerend is, omdat de oplossing onder de SAP-paraplu valt of omdat er Oracle middleware onder zit. Met behulp van klantgerichte waarde-scenario’s – verhaallijnen waarin de beoogde waarde word gecreëerd, geen requirements dus – kun je vervolgens op basis van werkende versies van de oplossing samen met de bedrijfsvoering binnen enkele weken vaststellen of de gekozen richting voldoet. De feitelijke implementatie is dan al helemaal voorgekookt.
Requirements werkten misschien nog redelijk in een tijdperk waarin we vanuit de centrale IT-afdeling grote, ambachtelijk met de hand gemaakte systemen bouwden: systemen als treinen en bussen die een voorspelbare route gingen volgen en in principe decennia mee moesten kunnen. Maar in het tijdperk van social media, self-service Big Data, business process management en app stores ligt het tempo heel anders: oplossingen worden bij voorkeur vanuit de bedrijfsvoering ontwikkeld en hebben soms een gewenste doorlooptijd van weken of zelfs dagen. Geen treinen of bussen, maar wendbare auto’s en scooters: ga daar maar eens onverstoorbaar requirements voor opstellen.
Werken met platforms lijkt een veel vruchtbaardere strategie: proactief vanuit de IT-kant meedenken met de bedrijfsvoering over een service-catalogus die een veelheid aan verzonnen en nog niet verzonnen oplossingen mogelijk maakt. Dat platform is vervolgens de versneller en springplank voor nieuwe toepassingen, niet in het minst als een inspiratie voor de bedrijfsvoering om tot creatieve combinaties te komen.
Uiteindelijk smelten vraag en aanbod samen: de fusie van IT en bedrijfsvoering zou wel eens volkomen zijn als we niet meer in requirements denken.
Ron Tolido, Senior Vice President and CTO Applications Continental Europe, Capgemini – Director, The Open Group
