dinsdag 31 maart 2009

1. Kennis Management: Deel 1

Zelf gebruik ik liever “Knowlegde Retention” als ik het over het absorberen en vasthouden van kennis heb, maar “Kennismanagement” (KM) is een bekender begrip en in dit artikel zal ik het over KM hebben waar ik hetzelfde mee bedoel als met knowlegde retention.

Het doel van kennis management is het absorberen van kennis door deze op te slaan, te depersonaliseren en te ontsluiten. Het voordelen van actief KM zijn legio:

  • Sneller inwerken van nieuwe medewerkers
  • Betere uitwisselbaarheid van personen en functies binnen een organisatie
  • Efficiënter werken door gevalideerde kennis te gebruiken (binnen processen)
  • Vergroten van waarde van het bedrijf
  • Spreiden van afhankelijkheid
  • Meer halen uit de investeringen in externe medewerkers
  • Betere mogelijkheden werkzaamheden uit te besteden

Bij KM draait het niet om de techniek hoewel er wel techniek nodig is om KM succesvol te integreren in de dagelijkse werkzaamheden.

Kennismanagement is een vorm van investeren. Toegevoegde waarde van kennis ontstaat niet vanzelf. Het is een bewustwordingsproces wat bestaat uit twee onderdelen. Kennis opslaan en kennis ontsluiten. Impliciet hoort daar kennis beheren bij.

Een voorbeeld: Als er op de service afdeling een bepaalde klacht regelmatig terugkomt zou het prettig zijn als de behandelaar of invoerder van de klacht bij het vastleggen van de klacht (en de typering) contextgevoelige suggesties krijgt aangediend zonder dat de gebruiker hiernaar hoeft te zoeken.

Stel dat de klacht binnenkomt dat de afdrukken uit een printer vaag zijn en er verschijnt een tekst onderin “de laatste weken zijn er veel klachten binnengekomen over vage afdrukken, dit bleken vaak afdrukken van het merk printer xx type YY te zijn. Laat de klant de nieuwste firmware installeren om dit probleem te verhelpen”.

Een begin maken met kennis management kan heel gemakkelijk. Binnen onze organisatie hebben we een ontwikkelteam welke software maakt. Bij software stuit je continu op problemen en ontwikkelaars zijn per definitie goed in het oplossen van puzzeltjes. Door elke keer na het oplossen van het probleem zowel het probleem als de oplossing op te slaan in een forum heb je een hele praktische tool. Het opschrijven van het probleem met de juiste sleutelwoorden is van cruciaal belang. Hiermee kunnen anderen ontwikkelaars snel tot het juiste stukje kennis komen. Welke versie van de software is er gebruikt, in welke taal is dit, welk gebied bestrijkt het?

Het opslaan van kennis gebeurt niet vanzelf. Door bovenop de ontwikkelaars te zitten en elke keer te vragen naar welke problemen ze tegen zijn gekomen en of ze deze al hebben vastgelegd, zorgde ik ervoor dat er veel werd vastgelegd. Als iemand met een probleem naar mij toe kwam was de eerste vraag die ik stelde: “Heb je al in de snibbits gekeken?”. Snibbits was de naam die ik aan de Knowledge Base gegeven had. Hoe meer tijd er verstreek hoe belangrijker het forum werd en ook hoe waardevoller.

Dat dit erg voor de hand ligt betekend niet dat ik dit in de praktijk vaak tegenkom.

Om dus actief met kennismanagement te beginnen moet aan de volgende randvoorwaarden voldaan worden:

  • Draagvlak voor het vastleggen van kennis
  • Software om kennis in op te kunnen slaan
  • Beheren van kennis en testen van het draagvlak

Met draagvlak bedoel ik dat een organisatie er bewust van is dat kennis management een vorm van investeren is. Kosten gaan zeer zeker voor de baten uit. Het moet ook echt gecommuniceerd worden en niet het eerste slachtoffer van de commercie zijn (“nu even niet, we hebben het zo druk”).

Hoewel techniek niet het zwaartepunt van Kennis Management is, heb je uiteindelijk wel iets nodig waarin je kennis kunt opslaan. Bestaande software of software die goed integreert heeft dan sterk de voorkeur. Hoe meer stappen er nodig zijn om kennis op te slaan en te vinden, hoe kleiner de kans dat je draagvlak stand houdt.

Kennis vastleggen wordt door alle werknemers gedaan. Om kennis uniform te houden en vervuiling tegen te gaan moet dit wel beheerd worden. Wie beheer uitvoert zou ook moeten signaleren of er nog genoeg kennis opgeslagen wordt en het liefst kunnen meten of kennis geraadpleegd wordt. Een kennisbeheerder kan zo waarnemen als draagvlak van kennis management minder wordt en hierop actie ondernemen. Mijn best practice is dat beheer nooit een dagtaak mag zijn en er tussendoor gedaan wordt. Dus als het veel werk is, laat dan meerdere mensen hiervoor verantwoordelijk zijn. KM is ook een vorm van evolutie. Nieuwe inzichten moeten leiden tot veranderingen. Als er geconstateerd wordt dat iets niet werkt, verander het dan. Het is ook aan te raden dat meerdere personen de taak van kennisbeheer over kunnen nemen, en kennis over kennis management moet praktisch zijn vastgelegd. Zo is de cirkel rond.

Dit is een samenvatting over kennismanagement. In verdere artikelen zal ik meer op details en praktische voorbeelden ingaan.

Wilt u weten of kennismanagement iets voor uw organisatie is? Neem dan contact op met Henri Koppen; 06-26112194 of Henri@henrikoppen.nl

woensdag 25 maart 2009

Wat is BPM? Deel 1

Business Process Management (BPM) is net als Web 2.0. Er is geen vaste definitie en het is geen afkorting uit het woordenboek. In de regel wordt de term gebruikt voor bedrijven die hun bedrijfsprocessen modelleren en middels software automatiseren. De software dient flexibel genoeg te zijn om met constante veranderingen om te kunnen gaan. Door te meten wie wat op welk moment doet ontstaat er inzicht. Op basis van dit inzicht worden er veranderingen in het proces doorgevoerd. Door later opnieuw de metingen te bekijken en analyseren kan er gezien worden of de veranderingen hebben geleid tot een beter resultaat.

Een bedrijf dat BPM doet is dus gericht op het “procesdenken”. Een proces volgens BPM is een logisch (grafisch) model dat beschrijft hoe het proces werkt. Dit model is opgemaakt op een generieke manier. De vorm en kleur van figuren hebben een betekenis en verschillende soort processen kunnen op een zelfde methode worden vormgegeven. Het model beschrijft wat er gedaan moet worden om naar een volgende stap in het proces toe te gaan. Het beschrijft vaak ook wie er actie moet ondernemen en wat de tijd is hoelang er over een actie moet worden gedaan. Het systeem zelf is ook een uitvoerder van processtappen en kan ook gebruikt worden voor signaleringen. Een signalering is een activiteit op basis van een gebeurtenis. Een voorbeeld van een signalering is dat een taak voor iemand hoge prioriteit krijgt als deze langer dan 3 dagen open staat.

Een factuur fiatteren is een processtap met een gemiddelde prioriteit. Als de uitvoerder van de processtap het enorm druk heeft met processtappen van hoge prioriteit, dan zal de fiatteringstap met gemiddelde prioriteit nooit uitgevoerd worden. Door de signalering krijgt fiattering wel een hoge prioriteit en zal dus worden uitgevoerd.

Tijdens een proces evaluatie ronde kan dus gezien worden dat fiatteringen pas na de signalering snel worden uitgevoerd. Als dit structureel is zal het betalingsproces per definitie meer tijd in beslag nemen dan nodig. Als de fiatteringstap namelijk meteen hoge prioriteit krijgt, zal deze sneller worden uitgevoerd. Mogelijk gaat dit wel weer ten koste van andere activiteiten. Door bijvoorbeeld criteria op te stellen waarop een factuur automatisch gefiatteerd mag worden kan het proces verbeterd worden doordat 80% van de facturen eigenlijk geen fiattering nodig heeft door een persoon. Criteria bijvoorbeeld van een maandelijks terugkerende factuur van een crediteur die geen afwijking vertoond van een vorige factuur.

Dit is BPM in een notendop en raakt vooral de essentie.

Als u na het lezen hiervan vragen heeft, dan kunt u kosteloos contact opnemen met Henri Koppen, 06-26112194, Henri@henrikoppen.nl .

woensdag 18 maart 2009

Wat heeft BPM met Kennis Management te maken?

Sinds ik mijn blog heb opgestart over BPM en Kennis Management is het uiteraard belangrijk om de titel en focus van dit blog nader uit te leggen. Sinds augustus 1997 ben ik als ondernemer werkzaam in de IT. In het begin maakte ik Access97 databases voor een administratieve afdeling nu modelleer ik soms hele ERP applicaties. Al vrij snel had ik een eigen methode ontwikkeld welke ik toepaste in alles wat ik maakte. Ik had een vorm gevonden waarin bedrijfsprocessen gegoten konden worden op zodanige manier dat het niet uitmaakte voor welk bedrijf of welke toepassing ik ze maakte. Uiteraard is dit alleen mogelijk als je de basis generiek opzet. Tegenwoordig heet dit beheersen van bedrijfsprocessen “Business Process Management” ofwel BPM. Als je de bedrijfsprocessen modelleerde volgens mijn referentie model (zo noemde ik de ontwikkelde methode), dan had je niet alleen een goede manier om die processen te beheersen (en langzaamaan te verbeteren), maar stopte je ook wat intelligentie van managers in dit proces. Zo was het voor uitvoerders van de processen heel gemakkelijk om hun werk efficiënt te doen en was ook de overdracht naar nieuwe werknemers een heel gemakkelijke oefening. Er vond in feite kennisoverdracht plaats en deze was geborgd in het systeem. Tot nu toe is dit nog erg abstract en in de scope van dit stuk zal ik dat ook blijven.

Dat BPM ondanks een wat trage start toch momentum begint te krijgen, wordt de urgentie om mijn boodschap te verkondigen sterker. De komende maanden zal ik zeer regelmatig puzzelstukjes van mijn kennis vastleggen in dit blogboek. Een kloof die tot nu toe bestaan heeft en voorlopig nog zal bestaan is de kloof tussen de mensen die de onderneming sturen en de mensen die IT gerelateerde zaken doen. De Business manager versus de IT manager. Het is spreekwoordelijk dat de techneut en de manager elkaars taal niet spreken. Er zijn al diverse applicaties en modelleringstools (en talen) die zeggen deze kloof overbrugt te hebben, maar ik geloof dat niet. De tool probeert vaak door middel van visuele aspecten en het zetten van eigenschappen de noodzaak tot coderen te elimineren. Uiteindelijk wordt de kloof wel kleiner en kan een niet programmeur sneller en uniformer applicaties ontwikkelen, maar zal iemand de vertaalslag moeten maken van wens of behoefte naar applicatie. Uiteindelijk hebben applicaties het doel om bedrijfsprocessen uit te voeren en applicaties moeten dus bedrijfsproces gestuurd zijn. BPM richt zich dus niet noodzakelijkerwijs om de kloof tussen IT en de business te dichten, maar meer om door middel van proces gestuurde applicaties de kernbehoefte achter het proces te vervullen. Het gaat dus niet om de technische kennis maar om de vertaling van de business naar een proces en de visie om het functioneren van een bedrijf te modeleren als een proces. Dit kun je pas als je enerzijds begrijpt hoe een procesmodel in elkaar steekt en de vertaling kunt maken van de handelingen van mensen en systemen naar dit model. Door een proces dus in een model te gieten leg je in feite kennis vast. Middels een applicatie ontsluit je die kennis. Het vastleggen van de verloop van een proces in uitvoering (wie, wat waar, wanneer) en de statistiek die het genereert kan gebruikt worden in rapportages die inzicht kunnen geven in het functioneren van de organisatie. Dit is in feite wat Business Intelligence wordt genoemd. Er wordt veel gesproken en geschreven over BI en BI tools, maar ook hier geldt: Techniek is niet het punt. De manier waarop data verzameld en getoond kan worden is niet het punt. Bij BI gaat erom: wat wordt er getoond en hoe moet je dat interpreteren. Pas als de informatie helpt om beslissingen en de gevolgen van die beslissingen inzichtelijk te maken kun je spreken over BI. BI komt dus pas nadat de basis van BPM gelegd is, en is daarmee een extra verdieping op de kennis die je al vastlegt tijdens het “BPM-en”.

Kennis Management (KM), of mijn favoriete benaming “Knowledge Retention” is de kunst van het absorberen van kennis. Hoe leg je kennis vast in een organisatie? Hoe voorkom je dat het weggaan van een werknemer, adviseur of uitzendkracht resulteert in het verlies en verdwijnen van kennis? Hoe leg je kennis vast en gebruik je deze actief? Hoe depersonaliseer je kennis? Knowledge Retention gaat over de antwoorden op deze vragen. Het juist toepassen van BPM is een vorm van kennis vastleggen, de concrete voorbeelden zullen volgen in de blogs die ik zal schrijven. Als je namelijk je bedrijfsprocessen vastlegt inclusief de criteria waarop bepaalde beslissingen genomen worden, dan maak je in feite een blauwdruk van het functioneren van jouw organisatie. Succesvolle ondernemingen presteren beter dan minder succesvolle ondernemingen omdat ze blijkbaar iets in hun processen beter voor elkaar hebben, iets unieks hebben. Uiteraard besef ik me dat het succes van een onderneming meer is dan de sec de processen. Als je visie is dat de klant als koning behandeld moet worden dan vind je de vriendelijkheid van je werknemer niet terug in een proces. Toch zal bijvoorbeeld je serviceproces het verlengde moeten zijn van die klantgerichte werknemer. Want hoe goed hij ook is, als het proces niet klantgericht is dan worden afspraken niet nagekomen en de juiste service niet geleverd. Punt is, dat elk bedrijf een unieke manier heeft om de dingen te doen zoals ze deze doen en eigenlijk geen onderneming “standaard” is. Dus ook processen en de procesinvulling is bij elke organisatie uniek. Bij het vastleggen van processen komt dus een stukje genericiteit kijken. Elke tool of methode die verschillende processen en bedrijven moet kunnen ondersteunen zal een bepaald niveau van genericiteit moeten bezitten. Generiek zijn is echter een gevaarlijk ding. Door de noodzaak van harde code te ontwijken leg je de complexiteit die normaal in de code zit in het model of in de applicatie inrichting. Op zich is dat een goed ding, het maakt je flexibel, alleen in die flexibiliteit ben je erg afhankelijk geworden van de inrichter. Programmeurs hebben vaak opleidingen gevolgd. Voor inrichters van software zijn vaak geen opleidingen en worden die gegeven door de makers van de flexibele software. Hoe kun je als inkopende organisatie snel inschatten hoe hoog de kwaliteit is van de consultant die je voor een project krijgt toegewezen? Nu dwaal ik al snel af van de bron waarvoor deze blog bedoeld is. De bron is wat BPM, Kennis management en genericiteit met elkaar te maken hebben. Ik heb verteld wat BPM is, dat het inzetten van BPM een vorm van kennis management is, en dat er een relatie bestaat tussen BPM en genericiteit.

Ik geloof dat BPM een zeer krachtig middel is om bedrijven succesvoller te laten opereren. Ik geloof dat goed kennismanagement de kracht en de waarde van een bedrijf doen toenemen. Door alle aspecten concreet toe te lichten wil ik draagvlak hiervoor voor deze twee zaken creëren, en hopelijk hiermee mensen en bedrijven helpen hun doelen te halen.

Henri Koppen
18 Maart 2009

dinsdag 17 maart 2009

Het roer om

Jaren lang heb ik een server op mijn zolder staan die draadloos aan het internet verbonden is. Daar heeft altijd www.henrikoppen.nl op gedraaid en dat werkte prima. Ik zal de server nog steeds aanhouden, maar dan alleen nog maar als veilige backup en niet meer om een eigen site te hosten. Tegenwoordig is het niet moeilijk meer om alles (gratis) op het internet te doen, en deze blog/site is daar onderdeel van. Mijn mailverkeer, agenda's en dergelijke doe ik nu via Google Apps, en deze blog is ook Google gerelateerd. 

Ik wil mijn blog nu actief inzetten als vuurtoren die licht schijnt op zaken zoals BPM, Genericiteit en Kennis management. Dit klinkt als technisch, ingewikkeld, abstract en wellicht saai, toch hoop ik goed uit te leggen hoe deze onderwerpen concreet ingezet kunnen worden om de operatie van een bedrijf meer en duurzame structuur te geven. Er is een heel sterk verband tussen BPM kennis en de noodzakelijk genericiteit. En door middel van blogs hoop ik dit steeds duidelijker te maken. 

Al meer dan tien jaar loop ik rond met deze concepten en toets ik ze succesvol aan de praktijk. Nu is de tijd om naar voren te stappen om dit te delen zodat anderen er hier hun voordeel mee kunnen doen. Reacties zijn altijd mogelijk op mijn blogs en hoop dat deze interactiviteit van toegevoegde waarde is.

De tijd zal het uitwijzen....

Henri Koppen
17 Maart 2009