Design being waarin design onderdeel wordt van de strategie.

Design being waarin design onderdeel wordt van de strategie.

Deel 3 van een serie blogs over de link tussen design en bekende methodes als Agile, Scrum en PRINCE2.

Wat brengt elke methode mee, wat zijn bekende belemmeringen en hoe kunnen we de methodes met succes combineren voor een optimaal ontwerpsucces van álles in je bedrijf: van je processen en touchpoints tot en met je brand expressie.

Hoe je alles in je bedrijf met elkaar verbindt…

…een voorbeeld uit de praktijk van wat ik bedoel.

Design being is het belangrijke deel waarin design onderdeel wordt van de strategie. Design being gaat over de kern van je bedrijf, the why, je brand, je merk, je identiteit als bedrijf. Hoe zorg je ervoor dat alles wat je doet, al je producten en diensten in lijn liggen met de identity van je brand?

Hiervoor heb je een holistische benadering nodig. Een die kennis vereist van design, technologie en processen. Een waarbij je als architect kijkt naar de dienstverlening, product en informatievoorziening.

In feite is je gehele organisatie design driven. Alles van de producten die je maakt, de dienstverlening tot en met de receptiebalie zou een connectie met elkaar moeten hebben binnen het kader van een duidelijke brand en strategie.

Om te komen tot innovatie, een nieuw product of proces kan bijvoorbeeld met de hulp van bekende methodes als design thinking, Lean Six Sigma, watervalmethode, PRINCE2 en Agile geïmplementeerd worden. Deze besprak ik in de artikelen over design thinking en design doing.

Al deze methodes hebben een gemeenschappelijke thema, maar verschillen in de stappen die je moet nemen om je doelen te bereiken. Bijvoorbeeld, design thinking (zie artikel over design thinking) heeft tot doel klantproblemen te begrijpen, en Lean (zie artikel over design doing) benadrukt dat je voortdurend moet werken aan het verfijnen van de oplossing. In het stadium van design being zorg je ervoor dat de hele organisatie doordrongen is dat zij onderdeel uitmaken van de user experience van de klant. Deze coherente en consistente klantervaring zorgt voor de gewenste merkbeleving.

Een methode die past bij design being

De auteurs Jeff Dyer en Nathan Furr introduceerden in hun boek The Innovator’s Method een proces dat een synthese is van de belangrijkste methodes die ik besprak. Dyer en Furr zeggen dat dit de volgende stappen zijn in het creëren van innovatie en het oplossen van interne uitdagingen.

Elke stap is nodig om de cyclus te voltooien en creatieve ideeën om te zetten in oplossingen.

  • Inzicht.

Kijk naar de behoeften die nog niet worden beantwoord. Stel vragen, observeer en experimenteer om inzicht te krijgen in die behoeften.

  • Probleem.

Ontdek de klus die gedaan moet worden. Verken de functionele, sociale en emotionele behoeften van de klant.

  • Oplossing.

Prototype van het minimale awesome product. Maak prototypes en herhaal elke oplossing om dat product te ontwikkelen.

  • Business model.

De go-to-market strategy valideren. Als je de oplossing eenmaal hebt vastgesteld, valideer dan alle onderdelen van het businessmodel.

We zijn het niet gewend design holistisch te benaderen

We kennen vele design deelgebieden. Denk aan …

  • interieurontwerp,
  • industrieel ontwerp,
  • procesontwerp,
  • serviceontwerp

… en nog vele andere deelgebieden. Dit vinden we niet vreemd. Tenslotte is alles om ons heen ontworpen. Zelfs de natuur geeft zichtzelf vorm.

Maar … vervolgens nemen we besluiten over design vaak niet bewust. Zo sprak ik laatst een manager die bedrijfsprocessen liet ontwerpen. Deze processen stonden op zichzelf. Er was geen integraal klantenproces gedefinieerd. Dat is raar, zeker als je klantgerichte, servicegerichte dienstverlening wilt brengen.

Begin dus altijd met een integraal klantenproces en bouw daar je interne processen omheen, niet andersom.

Een voorbeeld van een reis uit mijn praktijk

Iets waar ieder bedrijf minstens één keer mee te maken krijgt, is de aanschaf van nieuwe software. Daarbij ben ik een aantal keer het volgende tegengekomen. Bij softwareontwikkeling ligt de aandacht van de bedrijven die het inkopen vaak helemaal op het invullen van functionaliteit. Voor zaken als hoe onderhoud je de software, architectuur en performance hebben ze geen tijd. Veel bedrijven zoeken snel een ‘bouwer’ en geven dan het startsein voor het implementeren van het proces.

De bedrijven geven hun zegen aan zaken als mobile first en geven hun akkoord om te bouwen in design sprints, want Agile, dat kennen ze zelf ook … Maar er zijn heel wat misverstanden recht te zetten rondom Agile, UML (Unified Modeling Language) en object-georiënteerd programmeren.

Ik heb Agile vaak als excuus of zelfs smoes zien worden gebruikt om de architectuur van software niet serieus te nemen. Er is ooit binnen het bedrijf een prototype gebouwd en ‘het’ werkte. Als het werkt, dan werkt het en dan denken managers/opdrachtgevers dat een traject wel klaar is.

Regelmatig ben ik bij klanten geweest waar vervolgens problemen zijn ontstaan met software, soms zelfs met commerciële pakketten die inmiddels een behoorlijk deel van de omzet binnenhalen. En dan loop je onvrijwillig tegen het einde van de ‘livecycle’ van een product.

Nog anders bekeken. Soms heb ik een project waarbij ik een fysiek product ontwerp en ontwikkel. Een product dat straks in de winkel ligt voor bijvoorbeeld € 150,- heeft ook een eerste prototype gehad. Zo’n prototype kost ter illustratie € 50.000,-. Dit komt door kostbare productietechnieken, handwerk, herwerk, etc. Geen ondernemer haalt het in zijn hoofd om zo’n kostbaar prototype in de markt te zetten, niemand zal dat gaan betalen. Na een prototype krijg je nog een eerste 0-serie om verder te valideren. Pas als het product goed is, de productieprocessen en methodieken beschikbaar, dan wordt er gekeken naar het in serie maken van een product om de prijs te kunnen halen. Bij IT-producten is dat niet anders! Software is wel heel snel te reproduceren, te kopiëren, maar een prototype is nog geen productierijp product.

Het is mijns inziens enorm van belang dat je – in dit geval – een complete IT-architectuur opzet en kijkt naar zaken als:

·      hoe onderhoudbaar is het,

·      wat is de interoperabiliteit,

·      welke standaarden worden gebruikt.

Ook software wordt ontworpen en is dus een vorm van design. Een die niet alleen maar functioneel opereert.

Samengevat

Alles is ontworpen, van interieur tot en met de verpakking en aflevermethode. Hou hier rekening mee als je een product of dienst levert.

Design thinking

De gebruiker echt begrijpen in wat relevant is en welke problemen hij/zij daarmee ondervindt. Zoek hier een oplossing bij en valideer of dat ook de juiste is.

Design doing

Als je een nieuw product, dienst of proces hebt, implementeer! Maar doe dit met de middelen die je hierdoor kan en wilt inzetten. De verschillende projectmethoden kunnen goede of valse verwachtingen scheppen.

Design being

Ook de organisatie is ontworpen. Er zijn processen, een strategie, missie, een productportfolio. Maar vergeet alle op het eerste gezicht niet zo voor de hand liggende zaken, zoals verpakking, de receptie, een ontvangsthal. Alles is onderdeel van het gebouw; jouw bedrijf. Kijk ernaar als een architect. Past die ‘uitbouw’ nog wel bij het geheel. Heeft iedereen goed door hoe het design van het bedrijf eruit ziet? Zorg dat iedereen het design van je bedrijf voelt en begrijpt!

Heb je deze serie blogs gelezen, dan begrijp je waarom ik al ruim 10 jaar niet alleen advies geef aan bedrijven in processen en productinnovaties, maar ook een designstudio heb. Beide gaan namelijk perfect samen, ze kennen dezelfde tools en aanpak.

Wil je eens wat gedachten wisselen over design being voor jouw bedrijf? Stuur mij een mail, ik kom een kop koffie drinken.