Retoriek

Pieter Wisse

Retoriek is er niet alleen in soorten en maten, maar als het om pakketten gaat ook in versies.

 

Ooit had retoriek een positieve klank. Wie het woord gebruikte, bedoelde zoiets als constructieve taalbeheersing, overredingskunst. Inmiddels is de boventoon negatief. Want moderne retoriek verhult. Iemand maakt zich dus 'schuldig' aan retoriek, wanneer hij valse informatie verschaft. Hij probeert met een aantrekkelijk beeld te verleiden, terwijl zijn werkelijke aanbieding tekort schiet.

Exemplarisch voor moderne retoriek is helaas de markt van informatietechnologie. Deze droeve conclusie trok ik voor de zoveelste keer, toen ik een boek van de heren Buck-Emden en Galimow las. Zij werken allebei bij de firma Sap. Wist u trouwens dat Sap het acronym is van: Systeme, Anwendungen und Programme in der Datenverarbeitung? Maar goed, uitgeverij Addison-Wesley publiceerde hun boek Sap R/3 System: a client/server technology (1996). Daarin verklaren beide Sap-medewerkers onvervroren dat (p. 167) "R/3 de volledige verwerking van bedrijfstransacties ondersteunt." Het gaat immers om Enterprise Resource Planning of kortweg ERP, nietwaar? Het boek bevat echter slechts luttele pagina's over de feitelijke toepassingen van R/3. Het blijft daar bij een opsomming van zgn functiegebieden. Dat vind ik te grof. Nergens krijg ik houvast aangereikt om het daadwerkelijk functioneren van R/3 te modelleren. Bijvoorbeeld, wat zijn de grenzen? Ik moet blijkbaar maar aannemen dat "alles kan," gewoon omdat het er stáát. Dat is in mijn ogen dus retoriek. Daarom ook vraag ik me inmiddels af wat die grote 'r' in de produktnaam R/3 eigenlijk afkort. Bestaat retoriek tegenwoordig ook in versies?

Bij nader inzien begrijp ik mijn verwarring wel. Die begon met de afwijkende betekenissen die het woord 'systeem' kan oproepen. In combinatie met R/3 dacht ik oorspronkelijk aan een pakket vanuit het perspectief van (eind)gebruikers. Met andere woorden, de programmatuur is kant-en-klaar, na opgave van parameters gereed voor gebruik. Maar zo beknopt als Buck-Emden en Galimow zich over bedrijfsfunctionaliteit uitdrukken, zo uitgebreid behandelen zij de techniek om aanpassingen, uitbreidingen enzovoort te realiseren. In deze optiek is R/3 een gereedschapkist voor programmatuurontwikkeling. De verwarring die de auteurs aan mij doorgaven was, dat gebruikers en automatiseerders met hetzelfde woord verschillende verschijnselen aanduiden. Ik kan nu samenvatten dat Sap geen pakket is voor gebruik, maar voor ontwikkeling. Het ontwikkelpakket R/3 moet eenvoudiger leiden tot ERP-maatwerk, zo herken ik nu het paradigma van Buck-Emden en Galimow. Maar het resultaat is in mijn opvatting geen gebruikerspakket.

Wat mij aan het retorisch gehalte van bijvoorbeeld Sap R/3 System fascineert, is dat zulke vertegenwoordigers erin slagen de principiële tegenstelling tussen enerzijds kant-en-klaar hulpmiddel voor gebruikers, anderzijds gereedschapkist voor programmatuurontwikkelaars buiten het besef van (potentiële) klanten te houden. In commercieel opzicht is dat beslist een bijzondere prestatie, want het vormt mi de sleutel tot groeiende omzet en winst. En dat is inderdaad onmogelijk zonder de verwarring van moderne retoriek. Ik vermoed trouwens dat klanten minstens zoveel bijdragen aan hun eigen illusie. De behoefte aan geruststelling is nu eenmaal enorm.

De poging tot overtuiging slaagt, omdat de 'klant' in zichzelf verdeeld is. Het management wil horen dat nieuwe informatievoorziening snel, goedkoop en integraal geregeld is. Daar speelt de gebruikersbetekenis van pakket. En wat de automatiseerders blijkbaar horen, is dat alles aanpasbaar is. Zij denken weliswaar eveneens aan een pakket, maar absoluut niet voor dezelfde — primaire — processen. Automatiseerders beoordelen, zoals gezegd, of het een pakket is voor hùn ontwikkelproces.

Na aanschaf ontwaken de geledingen ruw. Want tijdens implementatie blijkt dat de aangeprezen 'oplossing' voor alles behalve triviale bedrijfs- respectievelijk ontwikkelprocessen inderdaad geen pakket is. Daar begint het 'probleem' pas. Het management raakt teleurgesteld omdat het project uitloopt, de kosten omhoog schieten en de specifieke managementinformatie toch hiaten vertoont. De paradox luidt dat het project overigens dóórgaat omdat de aanschaf toch al zoveel kostte. Ook de interne automatiseerders verliezen hun enthousiasme. Voor de complexe implementatie (lees: afwijkende programmering) blijken externe specialisten nodig. De theoretische flexibiliteit — zo die al bestaat en dus niet óók een retorisch produkt is — pakt uit als praktische fixatie. Dat hadden zij zich daar allemaal anders voorgesteld. Is het dan geen pakket? Rijkelijk laat gaat de organisatie op zoek naar realistische referenties. Maar alom — dwz management, gebruikers èn automatiseerders — tevreden klanten blijken er ineens niet te zijn.

In elke organisatie met primaire processen van enige dynamiek en complexiteit komt als secundair proces altijd in enige mate maatwerk van programmatuur kijken. Ook Sap erkent de noodzaak van maatwerk, als ik tenminste op het boek Sap R/3 System mag afgaan. Want daarin krijgt R/3 juist als gereedschapkist sterke nadruk. Maar de gelijktijdige bewering dat het 'systeem' compleet functioneert misleidt.

Mijn advies luidt om niet te beginnen aan programmatuur die met een dubbel gezicht voorgesteld wordt. Dat kan nooit kloppen. Zolang een potentiële klant echter verdeeld tot een oordeel komt, blijft de valkuil verborgen. Dus blijven er talloze organisaties intuimelen. Zij moeten daarom beginnen met interne communicatie, zonder retoriek.

 

© 1997, webeditie 2001.
Eerder verschenen in: Informatie Management, 1997, nr 4.