Bedrijfsmodelleren vanuit producten en diensten

Frits Cost, woensdag 08 juli 2009

Bedrijfsprocessen in kaart brengen blijft een vak apart. Er zijn inmiddels schitterende modelleertools waarmee procesmodellen met één druk op de knop kunnen worden omgezet in werkende applicaties die die processen kunnen ondersteunen of op basis van bedrijfsregels zelfs volledig kunnen uitvoeren, maar in het woud van mogelijke tools en methodieken is het vaak moeilijk kiezen. Bovendien zijn beschikbare proces referentiemodellen die er voor verschillende branches en toepassingsgebieden zijn vaak lastig vertaalbaar naar de eigen praktijk.

Inleiding

Het grootste probleem bij het modelleren van processen ligt in het goed in beeld hebben van de bedrijfsprocessen zelf. Zijn het de juiste processen? Hebben we alle noodzakelijke processen te pakken of zijn er nog witte vlekken? Zijn de processen op de juiste manier afgeleid van de klantbehoeften? Zijn ze afgesteld op de te bereiken bedrijfsdoelen? Zitten ze logisch en begrijpbaar in elkaar? Bovendien wordt het feit dat het bij bedrijfsprocessen in essentie om communicatie gaat tussen mensen nog al eens vergeten. Al met al veel werkende systemen maar vaak minder werkbare processen.

Op zoek naar een manier om grip te krijgen op het vakgebied van bedrijfs(-proces)modellering ben ik de afgelopen jaren binnen allerlei klussen onder andere op de volgende onderwerpen gestuit:

  • Hoe moet de bedrijfsstrategie worden doorvertaald naar processen (top-down)?

  • Hoe kan bovenop het bestaande applicatielandschap een procesarchitectuur worden ontwikkeld (bottom-up)?

  • Hoe ziet de financiële structuur van een waardeketen eruit?

  • Hoe moet regie worden gevoerd bij een ingewikkelde productcombinatie?

  • Hoe kunnen uitbestedingsmogelijkheden worden onderkend?

  • Hoe zien de klantprocessen eruit?

En meer marktsegment gerelateerd:

  • Hoe kan een traditioneel energiebedrijf worden opgesplitst naar verschillende bedrijven?

  • Hoe kunnen de content-, service- en netwerklaag van een telecomoperator het best worden doorvertaald naar bedrijfsprocessen

  • Hoe past het elektronisch medicatie dossier (EMD) binnen de besturing op diagnose behandeling combinatie (DBC)?

Bij dit soort vragen ging ik altijd hardnekkig op zoek naar een bedrijfsgrondvorm waarop alle processen in hun samenhang konden worden afgebeeld. Mijn ervaringen binnen de logistieke wereld aan het begin van loopbaan had mij overtuigd van de noodzaak daarvan. Voor ieder informatievoorzienings project of het nu om een bestaande situatie ging of om nieuw te introduceren producten en diensten werd een logistieke grondvorm opgesteld om de juiste processen te kunnen afbeelden en de daaruit voortvloeiende systeemeisen. De logistieke grondvorm geeft de samenstelling en beweging van goederen weer ‘van zand tot klant’. Maar het opstellen van zo’n grondvorm bleek vervolgens binnen de telecombranche een stuk lastiger voor me te zijn.

Waaraan zou een bedrijfsgrondvorm moeten voldoen. Zo’n grondvorm zou een basiskaart moeten zijn voor de bedrijfsvoering net zoals een basiskaart van een geografisch gebied in een atlas. Daarmee krijgt een bedrijfsgrondvorm een soort kadasterfunctie. Op die basiskaart moeten vervolgens bedrijfsmodellen voor alle relevante bedrijfsaspecten kunnen worden afgebeeld: producten, processen, bedrijfsregels, prestatie-indicatoren, menselijke expertise, IT, organisatorische verantwoordelijkheden et cetera. En waar zou dat dan toe moeten leiden? Consistentie van de bedrijfslogica en transparantie in de besluitvorming. En anders? Stuurloos ronddobberen! Al met al een lastige klus die alleen te klaren bleek te zijn door standaard uitgangpunten te zoeken in de diversiteit van bestaande modellen en methoden met als uitgangspunt: houdt het zo grofmazig en eenvoudig mogelijk en laat ruimte voor eigen invullingen, afwijkingen en uitzonderingen.

Startpunt om tot een duidelijke bedrijfsgrondvorm te komen is het opzetten van een productstructuur die nodig is om de door de klant gevraagde producten en diensten te kunnen realiseren. Want wat je maakt is wie je bent! Een duidelijke product/dienst architectuur maakt de waardestromen (value streams) inzichtelijk. Hoe lopen goederen/diensten, informatie en geldstromen en welke processen moeten daarvoor worden ingericht.

Hamburgermodel

Een manier om producten en diensten in kaart te brengen vond ik in het zogenaamde “hamburgermodel”, ontwikkeld door Wim Gielingh voor de fysieke bouwwereld [Gielingh, 2008]. In dit model worden gevraagde functionaliteit en geboden oplossing tegenover elkaar gezet als top en bodem van het broodje. Het totale broodje geeft daarmee het product of productelement weer (zie afbeelding 1). Deze afbeeldingwijze dwingt je om bij het opstellen van producteisen uit te gaan van de wensen van de klant (een prima manier van werken bij bijvoorbeeld six sigma).

Afbeelding 1: het hamburgermodel

Een heel erg goede toepassing van het hamburgermodel vond onlangs in het boek van Tim Zaal: Integrated Design and Engineering [Zaal, 2009]. Binnen de bouwwereld wordt het model gebruikt om de samenstelling van product/gebouw uit zijn fysieke componenten (bill of material) weer te geven.

Maar buiten fysieke componenten zijn binnen de meeste bedrijfssectoren ook niet fysieke producten of diensten te onderkennen. Hoe kunnen die dan worden afgebeeld en in een product/dienststructuur worden ondergebracht? Bij het zoeken naar een oplossing hiervoor hanteerde ik het uitgangspunt ooit door mijn collega Eric Winter aangedragen dat er in principe maar vier soorten producten en diensten zijn die kunnen worden geleverd: een idee of concept (verbeelding), een handmatige of geautomatiseerde activiteit (verrichting), een tastbaar product (voorwerp) en de beschikbaarheid of capaciteit ergens van (voorziening). Om deze verschillende soorten producten aan elkaar te kunnen knopen heb ik gebruik gemaakt van het bekende IGOE-model (input, guide, output, enabler). In een zin geformuleerd laat dit model zien wat (O) gemaakt wordt, waarvan (I), hoe (G) en waarmee (E). Afbeelding 2 toont het klassieke model waarbij de waardestroom van input naar output van links naar rechts loopt en een rechtop gedraaide versie ervan dat binnen een top-down product/dienst structuur kan worden gehanteerd. Zo ontstaat in feite een bedrijfsfunctie hiërarchie binnen de product/dienst structuur.

Afbeelding 2: het IGOE-model; basismodel (horizontaal) en 90° gedraaid (verticaal)

Door vervolgens het hamburgermodel en het IGOE-model aan elkaar te koppelen ontstaat een vast patroon dat toepasbaar is op elk besturingsniveau, fungerend als een soort business DNA. Binnen verschillende opdrachten probeer ik altijd op ieder niveau met dit patroon de chaos te lijf te gaan (zoals chaostheorie gebruikt maakt van fractals).

Afbeelding 3: het ‘PSOA’ basispatroon

Het patroon, weergegeven in afbeelding 3, levert een bouwblok op voor een architectuurstijl die ‘product/service oriented architecture’ (PSOA) genoemd zou kunnen worden. In ieder geval maakt het de aansluiting met een SOA aanpak vanuit business optiek een stuk eenvoudiger. Omdat het bij bedrijfsvoering in essentie gaat om het creëren van waarde en deze werkwijze de afbeelding van de waardestromen boven tafel tilt spreek ik liever van een ‘value-stream oriented architecture’ (VOA) waarbij in de methodiek de door producten en diensten gecreëerde waardestroom van beneden naar boven loopt.

Voorbeelden

Hoe zien die plaatjes er dan uit? Ik zal een aantal voorbeelden laten zien. In afbeelding 4 wordt de primaire product-/dienst structuur van een telecombedrijf weergegeven dat IP diensten over glas levert. In dit model worden de bedrijfsfuncties nog weggelaten, maar worden de hamburgers met elkaar verbonden door connectoren die corresponderen met de verbindingen uit het IGOE-model. De ‘R’ connector staat voor ‘regie’. Bij de keuze voor kleuren en symbooltjes om te ‘geboden oplossing’ (bodem van de hamburger) weer te geven zijn de eerder genoemde vier verschillende product/dienst soorten als uitgangspunt genomen. Conventies hiervoor staan nog niet vast, maar worden met de opdrachtgever afgesproken.

Afbeelding 4: telco productstructuur voor IP-diensten over glas

Het voorbeeld is een gestripte versie van een product-/dienst structuur die binnen een telecomonderneming is opgesteld en waarbinnen totale portfolio in kaart werd gebracht. Deze werd uitgangspunt gehanteerd voor onder meer de volgende activiteiten:

  • consistent maken van de samenhang van deelproducten;

  • formuleren uitgangspunten voor de kostenstructuur;

  • opstellen protocol voor het uitvragen van de klant bij storingen;

  • toepassen van het eTOM model (enhanced Telecom Operations Map) van het Telemanagement Forum dat binnen de telecomsector als mondiale standaard wordt gehanteerd voor processen;

  • definiëren van de benodigde bedrijfsprocessen (in dit geval verder uitgewerkt in ARIS van IDS-Scheer) en de kpi’s daarbinnen;

  • ontwerpen initiële levering (aansluiting) inclusief regie daarbinnen en continue levering (verbruik) in hun onderlinge relatie;

  • afbeelden van de IT op de processen.

Als belangrijkste resultaten bleek de aanpak consistentie in de keten op te leveren en inzicht te bieden in witte vlekken in procesbeschrijvingen.

Een andere toepassing van de methodiek wordt weergegeven in afbeelding 5. Hier is een bedrijfsdashboard gecreëerd om bedrijfsdoelen via ‘als-dan’ relaties in hun onderlinge samenhang zichtbaar te maken. De IGOE aanduiding is uit de ‘highlevel’ bedrijfsfuncties innoveren en produceren weggelaten. Een hamburgermodel op dit niveau fungeert als totaalframe voor de onderneming. Een dergelijk dashboard kan worden opgesteld voor de verschillende besturingsniveaus: totale onderneming, verschillende product/markt combinaties, verantwoordelijke organisatorische eenheden, afdelingen en personen. Ook tussen deze niveaus worden de doelen via ‘als-dan’-relaties verbonden. Door bedrijfsdoelen en –functies op deze manier met elkaar in balans te brengen wordt een consistente bedrijfsinrichting verkregen (balanced business).

Afbeelding 5: basispatroon als bedrijfsdashboard

Tot slot nog een plaatje uit de zorgsector. Afbeelding 6 laat een ‘product breakdown structure’ (PBS) zien waarop het proces ‘voorbereiding operatie’ kan worden afgebeeld. Het model geeft een overzicht van alle benodigdheden (met de aanwezigheid van de patiënt als uitgangspunt) om een operatie te kunnen uitvoeren en de bedrijfsfuncties die daartoe moeten worden uitgevoerd.

Afbeelding 6: bedrijfsfuncties t.b.v. voorbereiden operatie

Deze structuur vormt de basis voor onder andere de volgende onderwerpen:

  • vaststellen van het niveau in de PBS waarop het proces nog patiëntspecifiek is (naar analogie van het klantorder ontkoppelpunt in de logistiek);

  • bepalen van de kostenopbouw en het niveau tot waar volgens de DBC code (diagnose-behandeling combinatie) wordt gebudgetteerd;

  • verder detailleren van onderkende bedrijfsfuncties met aanwezige protocollen en werkinstructies;

  • maken van procesuitwerkingen tot op het niveau van stappen uit het medicatieproces; verder detailleren van de vastleg- en raadpleegmomenten in het EMD (elektronisch medicatie dossier).

Het hier getoonde voorbeeld is op zich weer een deelpatroon binnen een totaalmodel dat kwaliteit van leven voor de ‘zorgconsument’ als vertrekpunt heeft. Via zorgvragen gedurende diens levensloop wordt verder ingezoomd naar zorgpaden, behandelingen en verrichtingen. Door een robuuste samenhang en transparante weergave ervan wordt zichtbaarheid in de zorg verkregen.

Conclusies

In dit artikel is ingegaan op een beperkt aantal uitgangspunten van de werkwijze met de hamburgers. Naast de uitgangspunten ‘gevraagde functionaliteit versus geboden oplossing’ en het IGOE model wordt ook nog gebruik gemaakt van een standaard indeling voor product- en dienst soorten en een standaard voor het vinden van meetmomenten in bedrijfsprocessen. Bij belangstelling wil ik daar een volgende keer graag dieper op in gaan.

Bij mijn werkzaamheden ben ik tot de conclusie gekomen dat op deze manier voor de meeste bedrijfssectoren communiceerbare en uitwerkbare plaatjes kunnen worden opgesteld. Bovendien bleek het mogelijk om bestaande referentiemodellen en methodieken te integreren in de denkwijze. Ook is de werkwijze bruikbaar in zowel bestaande situaties als voor nieuw te ontwikkelen business. In de praktijk bleek bovendien dat mensen uit verschillende disciplines in de afbeeldingen hun eigen werk herkenden. In een aantal gevallen werden langlopende discussies over inrichtingsvraagstukken (letterlijk) ogenblikkelijk beslecht. In workshop verband leidt een hamburgermodel als grote landkaart aan de wand bovendien tot verrassende resultaten.

Door de werkwijze te hanteren die ik in dit artikel heb beschreven bleek het mogelijk te zijn tot de juiste processen te komen, consistentie met klanteisen en bedrijfsdoelen te bereiken en een logische en begrijpbare en daardoor toepasbare bedrijfsarchitectuur te creëren.

Referenties

[Gielingh, 2008] W. Gielingh: “A theory for the modelling of complex and dynamic systems”, ITcon Vol. 13, p. 421, September 2008.

[Zaal, 2009] T. Zaal: “Integrated Design and Engineering - as a Business Improvement Process”, Maj Engineering Publishing, ISBN:9789079182039, 2009.

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

15/16-11: Landelijk Architectuur Congres meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden