Hieronder worden conceptuele vragen over RPM verzameld en (gaandeweg) voorzien van antwoorden. Vragen over ontwikkeling van RPM staan bij ontwikkeling/faq; vragen over implementatie van RPM staan bij uitrol/faq

Ik heb ook even geneusd op rpmplatform.nl en lijk dan tot de conclusie te moeten komen dat het gaat om de kunst van het vragen stellen. Dat lijkt me enorm belangrijk en ik zou als gebruiker dan ook zeer benieuwd zijn naar wat me dat oplevert in de zin van 'gaat iedereen die antwoord geeft op die goede vragen dan ook echt daarmee aan de slag?' Of komen we dan in een soort gevaarlijke Abelene-paradox (a zeggen, a doen (of b doen, nog erger), maar eigenlijk a niet willen, dus als het even kan eronderuit willen komen of slechts korte termijnwinst na willen streven). Kortom: hoe creeer je (met RPM) intrinsieke motivatie om duurzaam na te komen wat je met elkaar afspreekt. Hoe voorkom je een papieren tijger, die bv ISO (maar ook prince2) vaak oplevert? Daarin zou de superplus van RPM zitten, lijkt me.

Intrinsieke motivatie is inderdaad wat je wilt. Je kunt motivatie echter niet rechtstreeks bij mensen aanbrengen, gemotiveerd raken is veel meer een interne aangelegenheid van mensen, ze raken gemotiveerd voor iets omdat ze er op een bepaalde manier over gaan denken of er iets bij gaan voelen. Bijvoorbeeld omdat ze een verband gaan zien met hun eigenbelang, of met een ideaal dat ze hebben, of omdat ze iets mooi gaan vinden, of iemand aardig gaan vinden. Perceptie is dus een sleutel tot motivatie. Zo gebruik je ook het principe van vragen stellen in RPM: je formuleert ze zo dat je mensen er op een bepaalde manier mee leert kijken of waarnemen. Bijvoorbeeld: je vraagt niet met welke procedure de kwaliteit geborgd is, maar je laat in je vraagstelling zien dat kwaliteit op meerdere manieren geborgd kan worden, dat de praktijk vaak een mix is, en dat je door een goede keuze van die mix meer flexibiliteit kunt krijgen. Van procedures worden mensen meestal niet warm, van flexibiliteit wel. Of: je vraagt niet wie de klant is, maar je vraagt naar de belanghebbenden. Klanten willen immers altijd meer dan waar ze recht op hebben en daar word ik als medewerker niet warm van, alle mooie kwaliteitsdoelen ten spijt. Belanghebbenden, daar hoor ik echter zelf ook bij. Ik mag nu dus zegen wat voor mij persoonlijk van belang is, en hoe ik in verhouding sta tot al die andere belanghebbenden. De vragen die je stelt met RPM beginnen dus niet bij werkafspraken, maar bij perceptie. Ze laten mensen op een bepaalde manier kijken naar klanten, hun werk, hun omgeving, etc. en ze prikkelen tot formuleren van wat ze zien. Als dat niet bijdraagt aan motivatie ga je de vraagstelling herzien. Als blijkt dat een vraag motivatieverhogend werkt kun een volgende vraag stellen, en al doende kom je bij concrete werkafspraken.
Papieren tijgers zijn richtlijnen waar mensen zich niet aan houden. De neerslag van RPM-vragen en de bijbehorende antwoorden is echter geen richtlijn maar een venster, juist omdat het gebaseerd is op vragen over waarneming. Het maakt zichtbaar wat mensen zien, en waarom ze dingen doen. Het is een blog, geen handboek. En omdat aan alle bijdragen dezelfde vragen ten grondslag liggen, leest het snel.

Resultaatverantwoordelijkheid ligt toch daar waar procesmanagement en lijnmanagement bij elkaar komen?

Deze interpretatie van resultaatverantwoordelijkheid mag intuitief juist zijn, maar op deze wijze kan iemand alleen maar resultaatverantwoordelijk zijn als hij ook volledig bevoegd is, en dat is alleen de manager die hierarchisch boven het hele proces staat. En die wil nu juist de resultaatverantwoordelijkheid delegeren. In RPM wordt het daarom zo gedaan: alleen eindverantwoordelijkheid is hierarchisch compleet. Resultaatverantwoordelijkheid definieer je dan als de verantwoordelijkheid om een resultaat te (laten) plannen en te (laten) realiseren binnen de grenzen van een gegeven procesontwerp en de gegeven personele capaciteit. Twee voorafgaande gegevens dus. Het verhaal begint dan bij de procesverantwoordelijke die vanuit regelgeving en klanteneisen tot een procesontwerp komt, inclusief zaken als kostprijzen, standaard doorlooptijden en competentie-eisen. De personeelsverantwoordelijke maakt vervolgens personele capaciteit beschikbaar, en voegt bijvoorbeeld nog wat opleidingskosten toe aan het proces. Dan is het de beurt aan de resultaatverantwoordelijke om te gaan plannen: welke output per wanneer, tegen welke kosten? Vervolgens loopt het proces en wordt er voortdurend bijgestuurd. Daar in hebben alle drie verantwooordelijkheden hun eigen rol.

Ik heb mijn processen al beschreven, moet ik nu alles overnieuw doen als ik met RPM ga werken?

Voor wie is het NIET?

RPM heeft een beperkte meerwaarde voor organisaties die hun bedrijfsprocessen met weinig inspanning in een hiërarchische structuur kunnen passen, waar wijzigingen in processen voldoende soepel worden opgevangen, en waar de planingcyclus al voldoende bijdraagt aan een lerende organisatie. Dat komt voor bij kleinere organisaties (korte lijnen) in stabiele markten.