Architectuur Competence Community

Inhoudsopgave

1. Inleiding
2. Wat is het probleem eigenlijk
3. Het architectuurmodel
4. Ondersteunende software
5. Wij zijn op zoek naar partners met business- en materiekennis

1. Inleiding

1.1 Probleemstelling

Uw klant, relatie, medewerker heeft een brandende vraag, een klacht, een voorstel, een verzoek tot levering van een dienst voor uw bedrijf, de afdeling P&O, de IT afdeling, uw leverancier, uw bank, de gemeente waar u woont of wie dan ook.
Als het een beetje meezit, kan uw relatie dit kwijt op uw internetsite, bij uw call centre of op welke wijze u dat ook heeft ingericht. Dat is vaak het begin van het lange wachten (zie Het zwarte gat: de backoffice).

Hoe zo, klantvriendelijkheid, efficiëntie, effectiviteit, gestructureerde communicatie, organisatieverbetering, oplossen van stagnaties?

1.2 Doelstelling

In dit artikel wordt een architectuurmodel beschreven van een oplossing, dat door Profuse International is ontwikkeld om bedrijven te ondersteunen, die een veelheid van services moeten verlenen op basis van verzoeken aan klanten, partners, medewerkers, stakeholders, burgers en andere betrokkenen.
Waar het eigenlijk om gaat, is een architectuur model voor een zgn. Competence Community, waardoor een werkelijke vraaggestuurde dienstverlening kan worden geïmplementeerd.

2. Wat is het probleem eigenlijk

2.1 De organisatie anno 2003

Anno 2003 staan dienstverleners onder druk om hun prijs/ prestatieverhouding te verbeteren. Dit geldt natuurlijk voor de profit sector, maar door de liberalisering en prestatiecontracten ook steeds meer voor de non-profit sector. Daarbij moet in gedachten gehouden dat hedendaagse organisaties voortdurend in een staat van turbulentie verkeren.
Klanten worden steeds mondiger, er is sprake van een massa individualisering waarbij klanten steeds meer op hun wenken moeten worden bediend. Er is sprake van een sterke mate van globalisering. De concurrent zit dichtbij en ver weg. De tijd die nodig is om van een idee te komen tot een product staat onder zware druk. Kortom, flexibiliteit en lenigheid van de organisatie is een ‘must’. Zonder een sterke klantoriëntatie red je het niet meer.

De organisaties moeten worden gebaseerd op wat wel wordt aangeduid als de ‘competitive forces’. Dat zijn dan de activa in een organisatie die er werkelijk toe doen: de klanten, de leveranciers, de rollen, de aanwezige talenten, kennis en ervaringen van medewerkers.
Deze organisaties zouden ook moeten worden georganiseerd rondom processen en informatie en niet rondom functies en managementstructuren.

Vanuit deze invalshoek spreken wij in dit artikel over zogenoemde competence communities. In goed Nederlands, dat zijn organisaties (gemeenschappen) die georganiseerd zijn rondom competenties (kennis en vaardigheden) van mensen. Deze mensen zijn ook, weliswaar misschien niet organisatorisch, maar dan toch wel te verdelen in groepen. Wij noemen dit competentie groepen. Later meer hierover.

De regels voor het structureren van deze organisaties zijn gebaseerd op de wijze waarop mensen in de organisatie met elkaar samenwerken. Deze regels kunnen op elk moment realtime worden gewijzigd.

Taylor zei tegen de werkers ‘hoe’ ze hun werk moeten uitvoeren. In de procesgerichte organisatie wordt tegen de werkers gezegd ‘wat’ ze moeten doen. Het ‘waar’ is dan van tweede orde. De medewerker is een kenniswerker geworden en het zou niet meer hoeven uit te maken waar hij zijn werkplek heeft, op kantoor, bij de klant of thuis, of…
Het is duidelijk dat begrippen als ‘communicatie’ en ‘samenwerking’ in deze organisaties een andere dimensie erbij krijgen. Als er in de organisatie blokkades liggen waardoor deze begrippen niet volop tot ontplooiing kunnen komen, gaat dat ten koste van efficiëntie, effectiviteit en continue verbetering. Uiteindelijk leidt dit ook tot een ontevreden klant.

Niet alleen afstemming tussen de wereld buiten de organisatie met de wereld binnen de organisatie is veelal een probleem. In een organisatie gaat het om communicatie en samenwerking tussen de kenniswerkers. En die zitten veelal niet gezamenlijk in hetzelfde gebouw. Ze zitten in een ander pand of zijn bij de klant. Ze zijn onderweg of zitten thuis te werken. Ook binnen de grenzen van één organisatie zijn er vele vormen van communicatie noodzakelijk.

2.2 Het belang van kennismanagement

In de organisatie anno nu is het belang van kennismanagement groot. Globaal gezien zijn er op het vlak van kennismanagement twee stromingen te onderscheiden, nl.:

• De kennisopslag benadering
  Deze stroming heeft als uitgangspunt dat kennis kan worden losgekoppeld van de drager (medewerker) en in een systeem kan worden opgeslagen waar het voor andere medewerkers beschikbaar komt.
  Er valt over dit uitgangspunt veel te zeggen. Feit is dat door allerlei praktijkervaringen nogal wat scepsis hierover is ontstaan
• De kennisstroom benadering
  Deze stroming gaat ervan uit dat kennis iets is dat niet losgezien kan worden van de drager. Kennisoverdracht vindt in deze opvatting voornamelijk plaats door communicatie en samenwerking tussen mensen.

Beide benaderingen hebben recht van spreken. Beide benaderingen hebben ook hun waarde. In de architectuur die in dit artikel wordt beschreven worden beide benaderingen verenigd. In de literatuur wordt dit wel collaboration management genoemd.

2.3 Hoe ver kijkt de aanvrager mee in de organisatie?

Organisaties moet transparant worden voor klanten. Klanten worden mondiger, worden kieskeuriger en willen op maat worden bediend. Om de klant vast te houden zijn organisaties er ook mee bezig om klanten daarin tegemoet te komen. In het model van de Competence Community zal de klant ook steeds aanwezig zijn. Middels een asynchroon communicatiemodel via het internet zullen organisaties in gesprek blijven met de klant. De klant blijft gedurende het hele afhandelingproces de mogelijkheid houden tot bijsturing en tot het verzorgen van aanvullende gegevens.

3. Het architectuurmodel

Het architectuurmodel van de Competence Community bestaat uit zes componenten:

• de aanvrager;
• het contactpunt;
• de infrastructuur voor de supportverlening;
• de infrastructuur voor het wijzigingsbeheer;
• de infrastructuur voor de dienstverlening;
• de infrastructuur voor aanvraagverwerving.

Deze componenten zullen achtereenvolgens in de volgende paragrafen worden besproken.

De aanvrager wil in de vraaggestuurde dienstverlening zo ver mogelijk de organisatie inkijken. Hij wil van de verrichte handelingen, die hem aangaan, op de hoogte blijven en wil zo mogelijk nog kunnen bijsturen.
Voor veel organisaties is de frontoffice beperkt tot het ‘contactpunt’. In dit architectuurmodel gaat het veel verder. Ook de vier pijlers behoren in feite tot de frontoffice. De aanvragers zijn volledig aanwezig gedurende de procesafhandeling in de peilers.
We gaan niet verder in op het blok dat we hier ‘Administratie’ noemen. Dat is in onze optiek de backoffice. De backoffice is voor ons een gegeven, die voor het model alleen van belang is voor wat betreft de uitwisseling van gegevens tussen de frontoffice en de backoffice.

3.1 De aanvrager

De term ‘aanvrager’ zal consequent worden gehanteerd. Er is bewust niet gekozen voor ‘klant’ omdat dat aanleiding kan geven tot misverstanden. Een aanvrager in ons model is iemand die een aanvraag, verzoek, voorstel, klacht, noem maar op inbrengt in het systeem. De aanvrager zit helemaal aan de voorkant. Hij is in feite de ‘trigger’ die het proces op gang brengt.
Een aanvrager kan een ‘klant’ zijn in de betekenis die in het algemeen spraakgebruik daaraan wordt gegeven. Dus een bedrijf of organisatie die een order plaatst, of die een supportaanvraag doet. Maar een aanvrager kan ook een inwoner zijn van een gemeente, of een medewerker in het bedrijf waar het model is geïmplementeerd, of een gebruiker van de nutsvoorziening of van het openbaar vervoer die een klacht heeft, etc. etc.
Mensen die een rol vervullen t.b.v. bepaalde processen in het model, kunnen zelf ook weer aanvrager zijn.

3.2 Het contactpunt

De aanvrager stuurt zijn aanvraag altijd naar het ‘contactpunt’. In feite is dat een competentie groep zoals iedere andere competentie groep in het model (zie verder). Het bijzondere van een contactpunt is dat het namens de organisatie verantwoordelijk is voor de aanvraag in de richting van de aanvrager. Het functioneren van een vraaggestuurde dienstverlening staat of valt hierbij.
Overigens is het niet zo dat alhoewel elke aanvraag gekoppeld is aan een contactpunt, het omgekeerde ook het geval is. Het is niet zo dat alle aanvragen gekoppeld zijn aan hetzelfde contactpunt. Dat zou een bepaalde starheid in het model brengen. Per aanvraag of type aanvraag, net wat u wilt, kan een contactpunt worden vastgesteld.

3.3 De vier verschillende pijlers

De Competence Community berust in ons model op vier pijlers:

1. Een infrastructuur t.b.v. supportverlening. Op gestructureerde wijze wordt de communicatie tussen vragers naar kennis, vragers naar oplossingen van geconstateerde problemen, klagers, ed. in contact gebracht en gehouden met aanbieders van kennis en oplossingen.
   Een kenmerk van deze pijler is dat het verlenen van support betrekking heeft op bepaalde objecten van support. Deze objecten van support kunnen zijn vastgelegd in een configuratie database, maar dat is niet noodzakelijk.
   Een andere eigenschap van supportverlening is dat er een overeenkomst aan ten grondslag ligt (service level agreement).
   Een supportvraag die regelmatig voorkomt, kan in de kennisdatabase worden opgeslagen. In de kennisdatabase bevinden zich problemen met oplossingen. Er is ook een proces om vanuit deze kennisdatabase een aanvraag voor een wijziging voor te stellen (zie pijler 2).


2. Een infrastructuur t.b.v. wijzigingenbeheer. Mensen (van binnen of buiten de organisatie) die wijzigingen voorstellen, het maakt niet uit wat, wordt de gelegenheid geboden de wijzigingen op te geven. Vervolgens zorgt de infrastructuur ervoor dat deze voorstellen gebundeld kunnen worden, dat er een besluitvormingsproces wordt ondersteund zodat voorstellen worden afgewezen of daadwerkelijk in wijzigingen gaan resulteren.
   Geaccepteerde wijzigingen zullen op een zeker moment moeten worden gerealiseerd en geaccepteerd.
3. Een infrastructuur t.b.v. dienstverlening. Standaarddiensten worden middels een catalogus zichtbaar en transparant gemaakt voor de aanvragers, waardoor keuzes kunnen worden gemaakt. Ook specifieke diensten kunnen worden afgesproken. De dienstverlening zal tegen vooraf afgesproken voorwaarden worden uitgevoerd. Achteraf vindt desgewenst verrekening plaats.


4. Een infrastructuur t.b.v. de verwerving van aanvragen. Voordat er aanvragen voor support, wijzigingsverzoeken, aanvragen voor diensten ontvangen worden, is er een proces om nieuwe opportuniteiten te verwerven aan vooraf gegaan. Een verkoopproces. Dit proces doorloopt een aantal fasen waarbij in elke fase specifieke deskundigheden (competenties) moeten worden aangewend.
   De aanvrager van het proces ‘Aanvraagverwerving ’ zal i.h.a. een verkoper of een relatiebeheerder zijn.

De aanvrager voor support, voor een wijzigingsverzoek, een dienst of een verkoper met een opportuniteit treedt in contact, middels het internet, met een contactpunt, een frontoffice, een servicedesk of hoe het ook genoemd wordt en legt daar zijn aanvraag neer. De mogelijkheid is aanwezig dat de aanvrager de hele levensduur van zijn aanvraag via het systeem in contact blijft met de personen die met zijn aanvraag bezig zijn.
De aanvrager kan iemand zijn buiten de organisatie, die op deze wijze met de organisatie communiceert, maar kan ook iemand zijn binnen de organisatie.
Het contactpunt blijft het contactpunt voor de aanvrager gedurende de totale levensduur van de betreffende aanvraag. De aanvrager zal het contactpunt daarop blijvend kunnen aanspreken.

4. Ondersteunende software

Het architectuurmodel, zoals dat in hoofdstuk 3 is beschreven, wordt ondersteund door het softwareproduct CC Assistant. Dit product wordt door Profuse International op de markt gebracht.
De uitwerking van de pijlers of meer informatie over de afzonderlijke modules van dit pakket kunt u vinden in het artikel Vraaggestuurde dienstverlening: het elektronische loket.

5. Wij zijn op zoek naar partners met business- en materiekennis

Vraaggestuurde dienstverlening is in veel verschillende branches aan de orde.
Profuse International pretendeert niet de materiekennis te bezitten om de software specifiek te maken voor bepaalde branches of bedrijfstypen. Wij hebben ons beperkt tot het maken van een pakket voor multi-level service organisaties ofwel in gewoon Nederlands organisaties, die vraaggestuurd moeten opereren onder de druk van concurrenten of de omgeving.
In een aantal case-studies beschrijven we kort een aantal toepassingsmogelijkheden. Deze case-studies zijn nog niet af.
We zoeken daarom partners met business en materiekennis, die in staat zijn om deze case studies te completeren en vooral met wie we in staat zijn onze multi-level service oplossing toe te snijden op een specifiek type bedrijf. Zie daarvoor het artikel Wij willen het ook niet alleen doen.

Voorbeelden van casestudies, die nog afgemaakt moeten worden zijn:

• Overheidsloket
• Patiënten logistiek
• Nutsbedrijf
• Service organisatie
• Vraaggestuurd leren
• Reïntegratie

Uiteraard zijn er ook andere toepassingen denkbaar en ook daarvoor nodigen we graag gespecialiseerde partners uit.

Dit artikel downloaden

In de rubriek
 ' Vraaggestuurd organiseren ' 
vindt u meer artikelen over dit onderwerp.