Weet de business niet wat ze wil of levert IT niet wat de business vraagt?

Beide vragen zijn irrelevant. De business kan namelijk niet weten wat ze wil en IT kan niet opleveren wat de business vraagt. Toch is dit vaak de realiteit van hoe de business naar IT kijkt en vice versa, zeker waar het gaat om maatwerk IT-projecten. Een mooi voorbeeld van de zogenaamde kloof tussen business en IT. Een kloof die helemaal niet hoeft te bestaan. Het is namelijk helemaal niet nodig dat de business weet wat ze wil om toch een 100% passende oplossing te leveren.

Waarom kan de business niet weten wat ze wil?

De "business" heeft soms wel een beeld van wat ze wil, maar heeft vaak geen idee wat de mogelijkheden zijn om dat beeld te verwezenlijken. Daarnaast moet een oplossing morgen klaar en alomvattend zijn. Zodoende wordt snel de conclusie getrokken dat IT te langzaam werkt en met halffabrikaten komt. Een uitstap naar een "snelle oplossing" met Excel / SaaS ligt op de loer. Daarnaast is het simpelweg onmogelijk om te voorspellen wat je in de toekomst écht nodig hebt. Daar kom je pas in het realisatieproces achter.

Waarom kan IT niet opleveren wat de business vraagt?

Doordat "IT" een vertaling moet maken van de eisen van de business naar een IT-oplossing en dat (te) veel tijd kost, is IT simpelweg niet in staat een passende oplossing te bieden. Zodra er een eerste testversie wordt opgeleverd is vaak de situatie al veranderd. Bovendien wordt IT beperkt door de beschikbare middelen en is het moeilijk uit te leggen aan de business waarom zaken soms simpelweg niet kunnen. Laat staan de hierboven beschreven onmogelijkheid om sowieso een goed idee te hebben van wat de business wil.

Het gaat niet om wat de business wil, het gaat om wat de business nodig heeft

Er is dus een ander proces nodig van applicatierealisatie met bijbehorende ondersteunende tooling. Hierin zijn een tweetal zaken van essentieel belang:

- Hoe sneller een eerste versie wordt opgeleverd, hoe eerder de business ideeën kan gaan vormen over hoe de oplossing er echt uit moet komen te zien. Zoals al vaker gezegd: als IT de snelheid van verandering van de business wil kunnen bijbenen, zal men moeten stoppen met programmeren en tools moeten gebruiken waarmee veel sneller en eenvoudiger een applicatie kan worden gebouwd en aangepast.

- Een klein projectteam die de taal van de business spreekt en bij elke wens kan vragen: heb je dit nodig? Waarom heb je dit nodig? Zou dit niet slimmer zijn? etc. Dus niet: u vraagt, wij draaien, maar: u vraagt, wij denken mee, stellen de juiste vragen terug en laten zien hoe dat in het systeem zou werken. Het zou nog mooier zijn als de business ook zelf direct mee kan bouwen /kleine aanpassingen kan doen.

Agile - SCRUM in combinatie met een MDD/RAD/aPaaS-tool

De manier om dit te bereiken is om een Agile-methodiek (bijvoorbeeld SCRUM) te combineren met tooling waarmee veel sneller applicaties/prototypes kunnen worden opgeleverd. Zodoende ontstaat een werkwijze waarbij de business veel directer in het ontwikkelproces betrokken wordt. Daarnaast wordt ondersteunende tooling gebruikt waarmee de business sneller een eerste werkende versie heeft en niet per se programmeurs nodig zijn om oplossingen te realiseren. Zo wordt zelfs een situatie gecreëerd waarin de business zelf kan mee-ontwikkelen. Een soort van "ideale" wereld dus.

Dit blog is tevens verschenen op CIO.nl.

Meer weten? Neem contact op of vraag een demo aan.

Subscribe to our newsletter

Subscribe

and share this blog item

  • image description
  • image description

Experience Betty Blocks