Systeemontwerp

Stap 1

Beschrijf het probleem

Begin niet met ontwerpen

In de loop der jaren heb ik presentaties van prachtige oplossingen gezien, maar er is altijd een aantal oplossingen dat geen probleem heeft.

Een marketingleraar liet me ooit een elektrische vork zien en het verhaal erachter dat ze ook naar een restaurant gingen en vroegen om een tafel dicht bij een stopcontact. Een deel van het verhaal was dat ze een  prototype aan het testen waren. Niemand twijfelde aan de noodzaak en de ober ging voor een lang verlengsnoer.

De meeste oplossingen beginnen met een probleem, maar een goede ontwerper probeert de vraag achter de vraag te vatten. Je zult zeurende vragen moeten stellen als “waarom is het een probleem”?

Wees je bewust van tijdelijke oplossingen, wees je bewust van de zakelijke waarde van het proces dat problemen vertoont. Probeer naar de ware oorzaken te reiken. Als je het eens bent over de uitdaging en de impact, dan beschrijf je een voorlopige  businesscase.

Een businesscase legt de reden vast voor het starten van een project of taak. Het wordt vaak gepresenteerd in een schriftelijk document, maar kan ook in de vorm van een korte mondelinge overeenkomst of presentatie komen. De logica van de businesscase is dat wanneer middelen zoals geld of moeite worden verbruikt, deze een gerechtvaardigde bedrijfsbehoefte moeten ondersteunen.

Kijken

Evalueer het proces en identificeer het probleem of de uitdaging.
Het gebeurt zo vaak dan mensen een prachtige oplossing presenteren maar dat het ontbreekt aan een probleem.

Kaders

Bepaal welke grenzen/ kaders wordt bepaald door interne bedrijfsregels, beleid, strategie, en richtlijnen. Daarnaast wat wordt bepaald door wetgeving en externe opgelegde standaarden.

Groei

Stap voor stap naar een werkend, geaccepteerd en gebruikte oplossing.

Reflecteer

Evalueer de werking van de gerealiseerde oplossing. Is het probleem nu opgelost of kan het beter?

Previous
Next

Focus op input en output en accepteer dat wat er in de black box gebeurt het domein is van de volwassen professional. Processtappen maken deel uit van een reeks en afhankelijk van de vraag kan de adviseur dieper graven door het deksel van de zwarte doos te openen en fijnere granulariteit van processtappen te identificeren.

Wim

Ken het proces

Een waardevol instrument om de ware informatie over een proces te verkrijgen, is het model van een use case. Deze use-case heeft:

  1. Een betekenisvolle titel.
  2. Een korte beschrijving om context te bieden.
  3. Beschrijving van de invoer met alle mogelijkheden (dit is geen beschrijving van randvoorwaarden).
  4. De hoofdstroom (ook wel de happy flow genoemd) wordt beschreven als een opeenvolging van stappen.
  5. Ook Alternatieve en/of Sub-stromen worden stap voor stap beschreven.
  6. Beschrijving van de output met alle mogelijkheden.
  7. Primaire gebruiker (1 actor of persoon die het proces in gang zet).
  8. Secundaire gebruikers; andere betrokken actoren als ontvanger, medewerker, adviseur, validator, beslisser.

Bepaal de ontwerpruimte.

Ontwerp is overgeven aan creativiteit. Maar hoeveel ruimte krijgt die creativiteit?

In deze fase inventariseer je: 

  1. Strategie.
  2. Budget.
  3. Prioriteit.
  4. Juridische kaders en bedrijfsstandaarden (compliance).
  5. Interne bedrijfsregels (business rules).

Deze aspecten geven je grenzen aan en soms lijkt het op een complexe jungle, maar als je de open plek vindt, dan heb je je ontwerpruimte. Mogelijk kan er wat worden onderhandeld over wat extra ruimte; denk aan een budget, interne bedrijfsregels en strategie maar andere regels geven harde grenzen.

Het besef dat je aan het ontwerpen bent.

Er zijn intensieve gesprekken geweest met alle belanghebbenden. Je hebt als het goed is een sponsor gevonden buiten IT. Content en proceslogica zijn immers eigendom van “de business” en er zijn afspraken gemaakt, er zijn kaders gesteld maar waarschijnlijk heb je tijdens die gesprekken al de bijna onbedwingbare neiging gevoeld om een oplossing te presenteren. 

Nu is het moment aangebroken om dat de doen. Neem daar de tijd voor. Vat samen wat er is gebeurd en wat je observaties zijn. Maak duidelijk welke kaders je hebt bepaald en hoe je de ruimte daarbinnen gaat inzetten.

Accepteer dat er niet meteen een golf van enthousiasme over je heen komt want je presenteert een verandering en die worden vaak beschouwd als bedreigend.

Je presenteert je oplossing vanuit een houding van: dit gaat er gebeuren. Vraag niet om toestemming want het is je rol om die sores uit handen te nemen. Natuurlijk heb je die oplossing eerst samen met je sponsor/ product-eigenaar besproken. 

Realiseer

Dit is het moment dat je gaat ervaren dat alles wat eerder gedaan wordt de moeite waard is. De basis voor een functioneel ontwerp ligt op tafel en kan verder worden uitgewerkt. Denk niet dat alles al tot achter de komma is bepaald maar behoudt flexibiliteit

Ik heb veel ervaring in een aanpak die begint met bewustwordingsoefeningen en behoefte-bepalingsessies. Wanneer uw gebruikersvertegenwoordiging de bewustwordingssessie heeft gedaan, zijn zij goed toegerust om de dialoog mee te voeren.

Een van de fundamenten van goed IT-beheer is een echte vraag- en aanbodaanpak. Dit dwingt het bedrijf om eigendom van inhoud en bedrijfslogica te accepteren.

Het resultaat is een goed beheerd realisatieproces.

Reflecteer, evalueer.

Het is een cyclisch proces; ondersteunende processen met diensten zoals IT-middelen.

Geef de gebruikers enkele weken de tijd om te werken met een goed gepresenteerde oplossing in een uitgebalanceerde adoptiesetting.

Vraag niet meteen om reflectie maar laat de gebruikers met de tooling werken en eraan wennen.

Maar je komt op een punt dat je minimaal twee vragen moet stellen

  1. Hebben we een tool gecreëerd die van toegevoegde waarde is voor het proces waar je aan werkt?
  2. Kunnen we het verbeteren, wat zijn de gebreken in de huidige tools, en wanneer er voldoende budget is, kun je de releasekalender bekijken en beslissen wat de volgende functies zullen zijn?

Het is nooit klaar!.

Process; Functional

Frietje Zwarte Doos

Use cases beschrijving is lastig maar essentieel. Het beschrijft het proces en functionele toepassing van hulpmiddelen. Deze toepassing zijn in onze wereld vaak IT functies. Het is geenszins de bedoeling om die functionele benadering te vermengen met de technische realisatie. Dat is het gesprek tussen de systeemontwerpen en de architect/ ontwikkelaar.

Read More »
Greenfield

Greenfield ontwikkelen

Soms is er geen goed Nederlands woord voor een term die in het Engels wel treffend is. Impact is zo’n woord Placeholder, nog zo een

Read More »