Procesmodel

Definitie van een proces

De term proces wordt vaak misbruikt in servicemanagement contexten. Gedefinieerd als "een reeks activiteiten die zinvol zijn voor de klant, met een specifieke doelstelling", moet een proces beperkt blijven tot activiteiten.

De basislay-out van een proces

Eisen aan processen

Om een procesarchitectuur te definiëren hebben we meer nodig dan alleen deze eenvoudige definitie. USM specificeert 10 eisen waaraan een proces moet voldoen, voordat we het inderdaad een proces kunnen noemen en als zodanig kunnen behandelen:

1. Een proces beschrijft wat achtereenvolgens moet gebeuren, niet het wie of hoe.
2. Een proces is dus te duiden met een werkwoord.
3. Een proces is telbaar.
4. Processen zijn niet afhankelijk van praktische condities(◊).
5. Processen hebben een voor de klant relevant en uniek doel.
6. Een proces is op te splitsen in deelprocessen, maar daardoor verandert het proces niet.
7. Een procesmodel ordent de processen.
8. Een integraal procesmodel omvat alle activiteiten voor het managen van services.
9. In een geïntegreerd procesmodel komt elke activiteit slechts één keer voor.
10. Op de activiteiten wordt toezicht uitgeoefend met procescontrol.

Processen versus practices

Als we de 'processen' uit alle huidige frameworks, standaarden en referentiearchitecturen testen aan de hand van deze 10 eisen, kunnen we aantonen dat ze allemaal combinaties van mensen, processen en technologie beschrijven: het wat, het wie en het hoe. Daarom voldoen ze allemaal niet aan de allereerste van de 10 eisen. Ze beschrijven eigenlijk practices, en practices zijn geen processen: practices zijn afgeleid van processen door de wie en de hoe toe te voegen aan de wat. De grote meerderheid voldoet ook niet aan eis 5: ze zijn niet klantgericht. De meeste van deze "processen" zijn interne aangelegenheden voor de dienstverlener en zijn als dusdanig slechts een deel van de klantgerichte processen. Ook wanneer mensen BPMN gebruiken of een van de andere zogenaamde 'bedrijfsprocesmodelleringstechnieken' of producten die 'swimlanes' gebruiken, specificeren ze rollen en documenten en voldoen ze niet aan eis 1.

In het e-book "Demystifying the term PROCESS" wordt dit in detail uitgelegd.

Het procesmodel met slechts vijf processen

Het verwijderen van alle wie en hoe uit deze practices leidt dan tot de kern van een proces architectuur: alleen het wat.

Het herformatteren van de resterende verzameling activiteiten op zo'n manier dat het resultaat voldoet aan de rest van de 10 vereisten, leidt vervolgens tot een klantgericht, integraal, geïntegreerd en non-redundant procesmodel voor servicemanagement.

In dat procesmodel vinden we slechts vijf processen die onafhankelijk zijn van de business van de organisatie. Vier van deze processen zijn reactief: ze worden extern getriggerd, door de externe klant. Deze reactieve processen worden gebruikt om te reageren op de vraag van de klant.

• Afspreken (Contract Management - CTM): het opstellen en onderhouden van serviceovereenkomsten en het aansturen van de implementatie ervan. Dit proces betreft zowel de serviceovereenkomsten met externe klanten als de overeenkomsten met externe toeleveranciers en met interne oplosteams die bijdragen aan de service. De bijbehorende melding heet wens, waarin het concept klacht is opgenomen. De wens fungeert als trigger voor het proces.
• Wijzigen (Change Management - CHM): de gecontroleerde ontwikkeling en release van wijzigingen in de infrastructuur van de afgesproken service. Dit proces koppelt de voorziening en/of ondersteuning voor zover deze deel uitmaakt van de beheerde infrastructuur. De bijbehorende melding wordt wijzigingsverzoek (of request for change (RFC)) genoemd. Het wijzigingsverzoek fungeert als trigger voor het proces.
• Herstellen (Incident Management - INC): de reparatie en het herstel van de service zoals afgesproken (in eerste instantie niet zo snel als mogelijk maar zo snel als afgesproken). Dit proces betreft zowel storingen als dreigende storingen van elke omvang, inclusief rampen. De bijbehorende melding heet incident (of storingsmelding). Het incident fungeert als trigger voor het proces.
• Uitvoeren (Operations Management - OPS): de geplande uitvoering van alle operationele handelingen voor de overeengekomen service en de monitoring van de prestaties van de infrastructuur en alle componenten daarvan. De bijbehorende melding heet service request (of operationeel verzoek). De service request fungeert als trigger van het proces.

Een van de vijf processen is proactief: het proces wordt intern getriggerd door de organisatie van de dienstverlener. Dit proactieve proces is gericht op structurele verbeteringen in de geleverde services, het managen van alle bedreigingen en innovaties voor dienstverlening.

• Verbeteren (Risk Management - RIM): het voorkomen van effecten die schadelijk zijn voor de afgesproken services (mitigeren van bedreigingen), evenals het bevorderen van structurele verbeteringen in de afgesproken services (bevorderen van innovaties). De bijbehorende melding wordt risico genoemd. Het risico fungeert als trigger voor het proces. Het proces 'verbeteren' wordt niet getriggerd door andere processen, maar alleen door mensen: in termen van het procesmodel is het 'zelf-triggerend'. Mensen dienen risico's in, maar er wordt ook actief naar risico's gezocht. De directe stakeholder is hier de eigen organisatie van de leverancier. De klant is slechts een indirecte stakeholder: alle verbeteringen zullen uiteindelijk de dienstverlening verbeteren.

Het USM-procesmodel met hele processen

In een procesmodel dat aan alle 10 eisen voldoet, worden prestaties bereikt met workflows: samengestelde stromen van activiteiten, die bestaan uit niet-overlappende fragmenten van afzonderlijke processen uit het geïntegreerde procesmodel. Een handeling voor herstel kan bijvoorbeeld worden uitgevoerd door een wijziging te laten uitvoeren of door een reset van infrastructuur, maar in beide gevallen wordt de uitvoering gerealiseerd in één en slechts één proces: Operations Management (Uitvoeren). Dit creëert een eenduidige control over de daadwerkelijke dienstverlening en voorkomt conflicten.

Deze unieke geïntegreerde procesmodellering voor dienstverleners kan eenvoudig worden geleerd, toegepast en ondersteund met tools, met behulp van niet meer dan 8 gestandaardiseerde USM-workflowtemplates voor al je servicemanagementactiviteiten. Stel je eens voor hoeveel minder complexiteit en kosten je zult maken met een dergelijk managementsysteem.

De lay-out van een proces standaardiseren

Elk proces heeft dezelfde basislay-out en bijgevolg heeft elk proces ook soortgelijke activiteiten. Aan het begin en het einde van elk proces vinden we altijd dezelfde vergelijkbare activiteiten: het opstarten en beëindigen van het proces. Processen verschillen vooral in één aspect: het klantgerelateerde doel van het proces, en daarmee verschillen ze in de aard van het proces. Dat verschil manifesteert zich in de activiteiten in de body van het proces.

In de onderstaande afbeelding worden de activiteiten in de body van elk proces aangegeven met hun kleur. In die afbeelding zijn de vergelijkbare (maar niet identieke) activiteiten grijs. De details van deze activiteiten worden per proces behandeld in het USM-boek.

De basis-layout van de 5 USM processen

De samenwerking tussen componenten van het procesmodel

Vanwege de non-redundantie van de processen heeft elk proces (met uitzondering van OPS) een of meer van de andere processen nodig om een vereiste prestatie te leveren. Daarom is elk proces (behalve OPS) opgesplitst in twee secties: de initiële sectie die het volgende procesblok triggert en de sectie die het proces administratief afsluit. De pijlen in de onderstaande afbeelding laten zien hoe de processen elkaar triggeren.

Het USM-procesmodel met gesplitste processen

Het gevolg van deze non-redundantie en interne afhankelijkheid tussen procesblokken leidt tot het concept van USM-workflows, met verbazingwekkende resultaten....