ZBC Kennisbank

Knowing the business

 

Een meerderheid van de projecten mislukt. En maar heel zelden wordt dit veroorzaakt door problemen met tijd of geld. Probleem is vrijwel altijd dat het projectresultaat niet voldoet aan de bedoelingen en verwachtingen van de klant. Dat door de reparatie van dit probleem projecten vaak uitlopen of het budget overschrijden, is hiervan het gevolg.

Beter specificeren is meestal weinig zinvol. Voor de opdrachtgever is het projectresultaat tenslotte uniek. Beter specificeren zou alleen het juridische probleem oplossen van wie achteraf de zwarte Piet krijgt toegespeeld. Het probleem zit er vaak in dat er te weinig kennis van en te weinig inzicht in de business van de klant in het project aanwezig zijn. Ook bij de projectmanagers ontbreken deze kennis en dit inzicht. Vaak kijken projectmanagers niet verder dan het projectresultaat en zijn zij niet geïnteresseerd in de bruikbaarheid van het projectresultaat voor de klant. Doorgaans wordt geredeneerd, dat als iets niet gespecificeerd is, het ook voor het project niet van belang is. Juridisch houdbaar, maar tegelijkertijd ook de ontkenning van het belangrijkste projectrisico. Tevens wordt hiermee het tweede deel van de kwaliteitsdefinitie genegeerd: kwaliteit is voldoen aan overeengekomen en vanzelfsprekende behoeften. Dat het projectresultaat bruikbaar moet zijn, is voor de klant natuurlijk zo’n vanzelfsprekende behoefte.

Product owner

Moderne methodieken op basis van Agile lossen dit probleem op door een product owner naar voren te schuiven. De product owner is verantwoordelijk voor de backlog en daarmee impliciet ook voor de bruikbaarheid van het projectresultaat. Helaas staat de product owner in de kou als hij steun zoekt bij genoemde methoden. Er wordt wel beschreven wat hij moet doen, wat zijn output moet zijn en wat zijn rol is in het proces, maar de meest prangende vraag blijft onbeantwoord, de vraag welke competenties en input hij moet hebben en hoe hij het organiseert, dat deze ook daadwerkelijk ingebracht worden in het project. Want dat is het werkelijke probleem. (Zie ook ‘Product owner zijn is een vak’.)
En dus maakt het niet zoveel uit, dat de traditionele projectmanager vervangen wordt door een product owner. Het probleem blijft bestaan. ‘Knowing the business’ moet ingebracht worden in het project. Hoe dat moet blijft onduidelijk. Hooguit zit het verschil hierin, dat projectmanagers zich meestal niet verantwoordelijk voelden voor dit probleem en product owners wel. (Zie ook ‘Product owners maken projectmanagers overbodig’.)

Kwaliteitsmanagers en security officers

Overigens hebben niet alleen projectmanagers en product owners dit probleem. Ook staffunctionarissen zoals kwaliteitsmanagers, security officers, risk managers en QHSE managers worden geacht hun aspectgebied in verband te brengen met de business en de context van de organisatie. Dat is een van de belangrijkste wijzigingen die momenteel via de High Level Structure wordt ingebakken in alle ISO-normen. (Zie ook ‘Herziening ISO 9001: High Level Structuur – HLS’.)
‘Knowing the business’ geldt ook voor hen.
Directies en stakeholders van organisaties pikken het niet langer, dat projecten en stafafdelingen hun eigen feestjes bouwen, los van de organisatie maar wel worden betaald door diezelfde organisatie. Kortom, het is nu menens geworden met ‘Knowing the business’ en dat geldt natuurlijk ook voor dienstverleners, die zich willen kwalificeren bij klanten.

‘Knowing the business’ kan ook pragmatisch

Grote adviesbureaus hebben waarschijnlijk geglimlacht bij het voorgaande. Zij hadden tenslotte de reputatie op het gebied van ‘Knowing the business’. Echter hebben zij in de afgelopen decennia hier omheen zoveel diensten gedefinieerd om maar meer omzet te krijgen, dat de essentie van ‘knowing the business’ ook daar verloren is gegaan. En sedert de crisis hebben klanten geen zin meer om daarin mee te gaan.
De kern is dat je snapt in welke wereld de organisatie opereert (interne en externe stakeholders), wat hun eisen en verwachtingen zijn van de organisatie (missie, kansen en bedreigingen), hoe de organisatie hiermee zijn geld verdient (verdienmodel en de primaire basis voor de continuïteit), wat daarvoor minimaal nodig is (kritische processen, resources en bedrijfsmiddelen) en hoe de samenhang is van deze punten en hoe je dit kosteneffectief kunt verbeteren. Dit laatste is de legitimering voor ieder project en voor ieder managementsysteem binnen organisaties en is bepalend voor de scope. Ontbreken deze legitimering en de scope, dan is de kans groot, dat het project of managementsysteem onvoldoende bijdraagt aan de effectiviteit en/of efficiency van de organisatie en dus als mislukt wordt beschouwd. Ook projecten worden hierop afgerekend en dan is het opleveren van projectresultaat dat niet minimaal klaar is om gebruikt te worden door de organisatie, absoluut te weinig. Zelfs al is dit niet gespecificeerd. Het is namelijk wel vanzelfsprekend. Projectmanagers dienen dus een aantal generieke business principes te kennen. Dit zijn bijvoorbeeld:

  • de verdienstelijking van producten en het veranderende risicoprofiel van dienstverleners;
  • principes van dienstverlening: de verpakking en distributie van de grondstof kennis;
  • het klantorderontkoppelpunt (KOOP) om meer klantgerichtheid te koppelen aan lagere productiekosten;
  • een generiek business model om snel inzicht te krijgen in het functioneren van organisaties.

Deze businessprincipes worden behandeld in hoofdstuk 5 van ‘Projectmanager 2.0 in de praktijk – gratis E-book’. Ook in het artikel ‘Lean werkt pas goed in de tweede helft’ gaan we in op een aantal van deze principes, vooral rond de Lean aanpak. Verplichte kost dus voor project managers, product owners en managers van kwaliteitssystemen. Zij zullen de ‘business logics’ van hun eigen organisatie moeten kunnen doorgronden en ook snel inzicht kunnen krijgen in de eisen en belangen van andere relevante partijen.

CANVAS model

In het kader van ‘Knowing the business’ willen we echter toch nog één aanvullende model bespreken als uitbreiding op het in het vorige hoofdstuk genoemde generieke business model, dat per product of dienst-marktcombinatie ingevuld dient te worden. Het CANVAS-model is wat meer gericht op de stakeholders en kan dienen als de basisplattegrond van ‘knowing the business’. Hierbij moet in feite alleen het volgende plaatje ingevuld worden, waardoor in één oogopslag de context van de organisatie met haar stakeholders duidelijk is, waarbij met behulp van de toepassing van de andere business principes gemakkelijk de kansen en bedreigingen (bedrijfsrisico’s) duidelijk worden:

model_canvas_met_uitleg

Even een kort overzicht van de betekenis van de velden:

  • Klantsegmenten – Een organisatie bedient één of meerdere klantsegmenten. Voor wie creëren we waarde? Wie zijn onze belangrijkste klanten? Er zijn verschillend soorten klantsegmenten. Voorbeelden: massamarkt, nichemarkt, gesegmenteerd, gediversiviseerd, multi-side platforms (of multi-side markten).
  • Waardeproposities – Een organisatie streeft ernaar de problemen van klanten op te lossen en in klantbehoeften te voorzien met waardeproposities. Een waardepropositie beschrijft de bundel van producten en diensten die waarde creëert voor een specifiek klantsegment. Een waardepropositie creëert waarde voor een klantsegment door een onderscheiden mix van elementen die voorzien in de behoeften van dat segment. Waarden kunnen kwantitatief zijn (bijvoorbeeld prijs, snelheid of service) of kwalitatief (bijvoorbeeld ontwerp, klantervaring. Voorbeelden (niet uitputtend): nieuwheid, performance, customization, ontwerp, merk/status, prijs, kostenbeperking, risicobeperking, toegankelijkheid, gemak /bruikbaarheid.
  • Kanalen – Waardeproposities worden aan klant geleverd via communicatie, distributie- en verkoopkanalen. Deze bouwsteen beschrijft hoe een organisatie met zijn klantsegmenten communiceert en ze bereikt om een waardepropositie te leveren. Kanalen kennen vijf verschillende fasen (awareness, evaluatie, aankoop, aflevering, after sales). Het model onderscheidt directe en indirecte kanalen en maakt onderscheid tussen eigen kanalen en partnerkanalen.
  • Klantrelaties – Klantrelaties worden opgebouwd en onderhouden met elk klantsegment. Deze bouwsteen beschrijft de soorten relaties die een bedrijf aangaat met specifieke klantsegmenten. Voorbeelden: persoonlijke hulp, toegewezen persoonlijke hulp, selfservice, geautomatiseerde diensten, communities, co-creatie.
  • Inkomstenstromen – Inkomstenstromen zijn het resultaat van waardeproposities die met succes aan klanten worden aangeboden. Zij representeren de cash die een bedrijf uit elk klantsegment genereert (kosten moeten van de inkomsten worden afgetrokken om winst te genereren). Voorbeelden: goederenverkoop, gebruikersfee, abonnementsgelden, uitlenen/huren/leasen, licentieverlening, brokerage fees, reclame.
  • Key resources – Key resources zijn de middelen (assets) die nodig zijn om de eerder beschreven elementen te bieden en te leveren. Deze kunnen fysiek, financieel, intellectueel of menselijk zijn.
  • Kernactiviteiten -zijn de belangrijkste dingen die een bedrijf moet doen om te zorgen dat zijn business model werkt. Voorbeelden van categorieën: productie, probleemoplossing, platform/netwerk.
  • Key partners – Sommige activiteiten worden geoutsourcet en sommige resources worden buiten de onderneming ingekocht. Het kan nuttig zijn om onderscheid te maken tussen drie motivaties om partnerschappen te creëren: optimalisering van schaalvoordelen, beperking van risico en onzekerheid, acquisitie van bepaalde resources en activiteiten.
  • Kostenstructuur – De onderdelen resulteren in een kostenstructuur die alle kosten beschrijft om het business model te laten werken. Lage kostenstructuren zijn voor sommige business modellen belangrijker dan andere. Het kan daarom nuttig zijn een onderscheid te maken tussen kostengestuurde en waardegestuurde business modellen. Kostenstructuren kunnen de volgende kenmerken hebben: vaste kosten, variabele kosten, schaalvoordelen en scopevoordelen.

In verschillende projectruimten zien we een ingevuld CANVAS-model tegenwoordig aan de muur hangen om ervoor te zorgen dat het project altijd gefocust blijft op zijn doelstellingen en niet verengt in alleen het projectresultaat.

Knowing the business leidt tot goede samenwerking

In het artikel ‘Eigenbelang eerst’ betoogden we al, dat voor samenwerking nodig is dat eigenbelang onderkend en erkend wordt, om te kunnen rekenen op draagvlak en dus samenwerking. Dat gaat sowieso voor abstracte zaken als het projectbelang of het belang van het managementsysteem. Beide zijn slechts middelen om doelen van personen of organisaties te bereiken. Projectmanagers, product owners en managers van kwaliteitssystemen zullen dit moeten beseffen. Zij zullen de business principes moeten kunnen toepassen in de beoordeling van de eigen organisatie, van klanten en van toeleveranciers om te bepalen welke punten voor wie van belang zijn en welke belangen met wie gedeeld worden. Want juist door de belangen van de verschillende spelers te kennen, kunnen win-win situatie gevonden worden, die de basis is voor een goede samenwerking. De traditionele  klant-leverancier relatie vormt in elk geval geen goede basis voor samenwerking en hetzelfde geldt voor resultaten ‘conform to specifications’. 
Ook in de ‘Training projectmanagement in de praktijk’ komen deze business principes en de toepassing om samenwerking te realiseren nadrukkelijk aan de orde.

ZBC ondersteunt zijn klanten met het pragmatisch inrichten van een werkbaar kwaliteitsmanagementsysteem.
DownloadDownload artikel als MS Word document Download artikel als PDF document Print deze pagina Verstuur deze pagina naar een vriend (email)
Auteur(s): Wiebe Zijlstra | 15 januari 2015


Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *