Home Ondernemen & Business De Dood van Requirements

De Dood van Requirements

163

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 kunnen zijn als we niet meer in requirements denken.

Ron Tolido, Senior Vice President and CTO Applications Continental Europe, Capgemini – Director, The Open Group

14 REACTIES

  1. Ron, interessante stelling. Requirements de dood in de pot. Ik kan het hier niet mee eens zijn … althans, niet op de manier zoals je het hier verwoord. Requirement is een mooi Engels woord voor behoefte, en hoe je het pok draait of keert, die behoeften zijn er wel.

    Waar we het denk ik wel over eens kunne. worden is dat requirements-a-la-lange-lijsten-met-requirements hun beste tijd wel gehad hebben. Co-creatie en it-driven ontwikeling van platforms obv waarvan “de business” haar behoeften kan ontdekken / kan exploreren lijkt wel een model van de toemomst.

  2. Bas, dan zijn we het volgens mij helemaal eens. De bedrijfsvoering heeft meer dan ooit ‘behoeften’. En de sleutel om daaraan te voldoen ligt beslist niet in het nog meer specificeren van requirements.

  3. Behalve dienst doen als een lijst met wensen en eisen voor een nieuwe toepassing, helpen requirements ook bij het vaststellen wanneer iets “af” is en helpen daarmee ook de budgetten onder controle te houden. Op dit laatste punt ben ik benieuwd naar een alternatief. Hoe zorgen we ervoor dat de wensen van gebruikers niet oneindig blijken en daarmee het project financieel niet beheersbaar wordt?

  4. Best Value Procurement is hiervoor een fantastisch alternatief. Dit is het gedachtegoed van de Amerikaanse hoogleraar Dean Kashiwagi.
    Best Value Procurement gaat over een andere wijze van het vinden en behouden van een samenwerking tussen klant en leverancier. Het is meer dan een inkoopmethode die een paradigma verandering vraagt van de inkoper (rol van expert verandert naar het herkennen van de expert).
    De inkoopfilosofie van prestatie-inkoop staat haaks op de gangbare filosofie van controleren door middel van zeer gedetailleerde specificaties, dichtgetimmerde contracten, inspecties en controles. Bij prestatie-inloop wordt de toeleverancier juist erkend als expert, waarbij dus in plaats van nadruk op controle achteraf de nadruk zwaar op het voortraject ligt.

    De principes van Best Value Procurement zijn zowel in de private als in de publieke sector toepasbaar.

  5. Ha Ron,

    Interessante write-up. Ik ben het deels met je eens maar wil ook wel wat nuanceren:

    Requirements zijn met name interessant in die gebieden binnen / capabilities van het bedrijf, waarmee het zichzelf onderscheidt in de markt. Voor alle ander gebieden zie je commodity- en BPO-achtige overwegingen ontstaan. IT/SaaS lijkt hier erg op; schaal, commodity, voorspelbaarheid en prijs zijn hier belangrijker dan de perfecte oplossing.

    Het is daarom natuurlijk niet altijd zo dat alle SaaS IT geboren wordt uit business frustratie. De eigen afdeling kan dergelijke schaal en prijs vaak zowiezo niet leveren. Pikant is wel dat IT zou moeten herkennen wanneer “niet zo perfect” goed genoeg is.. en meestal is dat niet zo! IT begrijpt de business niet en de business snapt niet waar IT wel en niet toe in staat is.

    Het lijnrecht tegenover elkaar staan van business en IT heeft hiermee een fundamentelere oorzaak: Men begrijpt elkaar niet meer. Op het moment dat business en IT hun eigen processen en organisatie individueel optimaliseren groeit er een enorme afstand. Doorgeschoten efficiency leidt tot het bekende “Wij” en “Zij” probleem. Verkeerd outsourcen van IT maakt het allemaal nog erger..

  6. Hi Ron, leuke en prikkelende opinie. Maar zijn er voor het inrichten van zo’n SaaS omgeving en het aan elkaar knopen van allerlei best of breed Cloud oplossingen en stukjes maatwerk (want je wilt toch onderscheidend zijn, anders heb je geen toegevoegde waarde als bedrijf) geen requirements nodig? Ook inderdaad om meetbaar te maken of iets af is?

  7. Gijs,

    Aan elkaar plakken wordt inderdaad een interessante bezigheid. Maar of dat hetzelfde is als bouwen op specificaties en requirements..? Zelf denk ik dat heldere value-scenario’s(zie het commentaar van John) en business cases (budget-boxing kan heel goed werken) moeten zorgen voor de meest optimale resultaten.

  8. John,

    Inderdaad heel interessant, al helemaal als je het in mijn stuk beschreven ‘platform’ ook beschouwt als een ’toeleverancier’: het platform krijgt de rol van een vertrouwde partner, pro-actief en stimulerend in de richting van waardevolle oplossingen.

  9. Beste Ron,

    Door je tekst heen valt te lezen dat requirements veel meer een impliciet karakter hebben/krijgen. Want ook al gaat het dan om scooters of auto’s. Je wilt wel een rode scooter of blauwe auto, want zwart dat vind je maar niks. En een paar mooie accessoires erbij die iemand anders niet heeft, daar wil je best wel iets extra’s voor betalen ….

    Vriendelijke groet,
    Leon Dohmen

  10. Leon, het kiezen van de kleur en accessoires blijft desalniettemin niet hetzelfde als een auto op je eigen specificaties laten bouwen of (erger nog) ombouwen …

  11. Ha Ron,

    Welkom op BlogIT!

    Ik geef je helemaal gelijk. Ik bedoel half gelijk. Of toch driekwart? Wat ik bedoel is, voor functionele requirements ga ik helemaal mee. Stop maatwerk, het is te resourceverslindend. Schaalvergroting in software en hosting helpt ons allemaal. Kortom, voor de meeste software is het veel beter mee te doen met wat er is dan daar iets aan toe te willen voegen. Dat lukt best omdat veel oplossingen functioneel hetzelfde kunnen. Je zou dan gewoon op basis van prijs kunnen kiezen.

    Maar er zijn nog andere requirements die je kunnen helpen bij het maken van een keuze. Laat ik ze non-functional requirements noemen. Geld alleen is zo banaal. We kiezen voor een bedrijf met een bepaald imago, we stellen eisen aan performance, beschikbaarheid, beveiliging, schaalbaarheid, de beste SLA’s, Nederlands sprekende helpdesk en je kent alle redenen wel die we gebruiken om toch op onze favoriet uit te komen.

    Half mee eens dus!

  12. Helemaal gelijk. Hier loop ik dagelijks tegen aan. Oracle heeft ook al een keer iets soortgelijks gesteld, omdat er vaak ellenlange discussies in organisaties worden gevoerd, op het verkeerde niveau, d.w.z. buiten de directiekamer. Er zijn maar weinigen die echt begrijpen van wat een OOTB is inclusief de practices die je erbij krijgt. Zodra je op zoek gaat naar requirements ben je eigenlijk al verkeerd bezig. Zou je niet gewoon een goede uitleg moeten bieden over wat je uitstort in een organisatie en een heldere schets moeten geven over waarom het noodzakelijk is om te doen? Leuke klus voor goede business consultants (en dan niet van die bla bla, maar mensen met ervaring en die de business door en door kennen, ook geen verkopers).

  13. Requirements dood? Service leveren uit voorraad?

    Beste Ron, Mooie punten die je daar aansnijdt. En, misschien heb je hier wel de valkuil te pakken die de IT zichzelf heeft opgelegd door alsmaar tot in detail systemen te bouwen die aan specifieke requirements voldoen. Bedrijven kampen altijd al met het probleem dat klanten blijkbaar altijd dat vragen wat niet standaard in het aanbod zit. Dit is gelukkig niet een nieuw probleem, maar bestaat al sinds de industriele revolutie.

    Grofweg kun je dan ook bedrijven onderscheiden die standaard uit voorraad, gepland en geassembleerd en maatwerk leveren. In de IT is dit niet veel anders. Eigenlijk is het platform dat jij als oplossing biedt te vergelijken met de voorraad. Afhankelijk van de specifieke wensen kan daar direct of na enig voorwerk uit geput worden. Echter, voorraad maken en aanhouden kost geld, en de vraag kan fluctueren. Soms met hoge pieken en dalen, soms op een redelijk constant niveau. Daarom is het zoeken naar product markt combinaties ook in IT een nuttige bezigheid, die noodzakelijk is voor je bedoelde platform strategie. Goed begrijpen van je klant behoeften blijft dus nog steeds net zo belangrijk als vroeger. Hoe je dat vertaalt naar de aanbod organisatie (in dit geval de platformen) is daar toch altijd een afgeleide van.

    Het enige waar we ons voor moeten hoeden, is te denken dat we alles uit een platform kunnen leveren. Dit houdt verband met het service type dat men vanuit dat platform kan leveren. Visualisatie, batch of of realtime services functionaliteit bijvoorbeeld. Een stelling van mijn kant: ieder service type heeft zijn eigen architectuur. Enerzijds zijn architecturen moeilijk te veranderen. En, als ze zo flexibel zijn dat er alles mee kan is het operationeel zo complex dat het gebruik te complex is, en vaak overkill. Dus nog veel te duur.

    Veel van de oplossingen ligt in het goed begrijpen wat voor service type er aan de vraagkant nodig is. Door wat specifieker in te zoomen kan ontdekt worden wat dit betekent voor de supply chain van IT services. Hier komen we aan op het punt waar IT’ers veel aan kunnen hebben: de IT services behandelen als een supply chain. Het voordeel is dat al veel voorwerk gedaan is in de supply chain ontwikkeling van bedrijven in de afgelopen 100 jaar. Er hoeft dus niet zoveel opnieuw verzonnen te worden. De concepten om dit toe te passen zijn al voorhanden.

    Kortom ik onderschrijf je stelling, en kan inmiddels uit eigen ervaring bevestigen dat dit een zeer haalbare strategie is. Business architecten kunnen hierin een bepalende rol spelen.

    Groet
    Harry

  14. […] to my previous blog someone drew my attention to an article published a year ago by Ron Tolido: “De Dood van Requirements” (the death of requirements). The author foresees a brighter future if we stop thinking in terms […]

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in