RESEARCH & DEVELOPMENT BIJ SOFTWARE- BEDRIJVEN

Transcriptie

1 Management accounting en control Management control in de praktijk RESEARCH DEVELOPMENT BIJ SOFTWARE- BEDRIJVEN De softwaresector is belangrijk voor de Nederlandse economie. Daarbij is de sector een van de koplopers als het gaat om innovatie. Dat betekent dat research development van groot belang is binnen softwarebedrijven. De auteurs bespreken in dit artikel de specifieke kenmerken van dit soort bedrijven en gaan in het bijzonder in op de vorm van management control die in de sector gebruikelijk is. Daarbij beschrijven ze de casestudies van twee bedrijven. DOOR WOUTER SCHREUDER EN KO ACHTERBERG De Nederlandse softwaresector draagt jaarlijks voor 17,3 miljard (2,8 procent van het bruto nationaal product (BNP)) bij aan de Nederlandse economie (Te Velde et al., 2010). De sector is daarnaast research development (RD)-intensief. Van de arbeidscapaciteit besteedt de sector 9 procent aan onderzoek en ontwikkeling. De sector behoort daarmee tot de koplopers van innovatieve bedrijvigheid in de Nederlandse kenniseconomie. In werkelijkheid is deze bijdrage nog groter. Ook bedrijven die formeel buiten de sector vallen, produceren software. Het productsoftwarebedrijf vormt een subsector. Een productsoftwarebedrijf investeert in het ontwikkelen van een softwareproduct en verkrijgt inkomsten door het verkopen van licenties, door het verrichten van softwareonderhoud en vaak door aanvullende dienstverlening. De bijdrage van productsoftwarebedrijven bedraagt jaarlijks 3,9 miljard. Deze subsector neemt daarmee een substantiële plaats in binnen de Nederlandse economie. Specifieke kenmerken van een productsoftwarebedrijf zijn dat het maken van één of een miljoen kopieën van een product ongeveer hetzelfde kost en dat de brutowinstmarge van productverkoop kan oplopen tot 99 procent. Daarnaast is er vaak sprake van een customer lock-in en is de variëteit van mogelijke producten en diensten bijna oneindig. Het klinkt als een zegetocht. Er schuilt echter een addertje onder het gras, namelijk dat toekomstige opbrengsten moeten opwegen tegen initiële kosten van ontwikkeling. En die kosten beet kan dodelijk zijn. Daarom vraagt investeren in productsoftware om een bijzondere vorm van management control op de bedrijfsresultaten (Cusumano, 2004). In dit artikel gaan we in op die vorm van management control bij productsoftwarebedrijven. We behandelen achtereenvolgens RD-processen en management control, productsoftwarebedrijven en management control en beschrijven casestudies van twee productsoftwarebedrijven. RD-processen en management control RD is te classificeren in drie fasen (Kerssens et al., 1997): ~ basic research: experimenteel of theoretisch onderzoek, gericht op het verkrijgen van nieuwe kennis van onderliggende principes van waarnemingen waarbij het onderzoek niet gericht is op mogelijke toepassingen. Een voorbeeld hiervan is onderzoek naar de (sub)atomaire werkelijkheid door kwantumtheoretici of onderzoek naar de geestelijke oorsprong van fysieke kwalen; ~ applied research: onderzoek gericht op het verkrijgen van nieuwe kennis op een specifiek gebied of specifieke doelstelling. Een voorbeeld hiervan is onderzoek naar de onder- 18 DECEMBER 2011

2 Fasen RD Levers of control BSC-dimensie Basic en applied research Diagnostic: ~ Monitoren voortgang van activiteiten Customer New product development (experimental development) ~ Evalueren winstgevendheid RD-activiteiten ~ Selecteren van RD-projecten Belief Boundary: ~ Bevorderen van coördinatie en communicatie ~ Stimuleren van leren (organisatiebreed) ~ Reduceren van onzekerheid Financial Business process Innovation and learning Figuur 1 Koppeling RD-fasen aan levers of control en BSC (Chiesa et al., 2009) linge samenhang tussen (sub)atomaire deeltjes om daaruit nieuwe scheikundige stoffen te creëren; ~ experimental development (of product of process development): systematisch werk dat voortbouwt op bestaande kennis en gericht is op de toepassing van deze kennis in producten of processen. Een voorbeeld hiervan is onderzoek gericht op het productierijp maken van lasertechnologie of naar het toepasbaar maken van kwantumversleuteling. RD-processen kenmerken zich (afhankelijk van de fase) vooral door technologische onzekerheid, marktonzekerheid of onzekerheid over de projectscope (Davila, 2000). Management control kan een middel zijn om die onzekerheid te reduceren. Aan dit vraagstuk is aandacht besteed door o.a. Chiesa et al. (2009). Chiesa koppelt de RD-fasen aan de levers of control van Simons en aan de dimensies van de balanced scorecard (BSC) van Kaplan en Norton (1992). Dit is weergegeven in figuur 1. Dit sluit aan bij de opvattingen van Simons (1995a) over de paradox tussen creativiteit en control. Elke organisatie heeft potentieel en kent blokkades daarop. De levers of control kunnen een bijdrage leveren aan het vrijmaken van aanwezige creativiteit. Simons opvattingen daarover zijn weergegeven in figuur 2. Kerssens (1997) geeft aan dat gebleken is dat er verschillende problemen zijn met het toepassen van standaard financiële Potential To contribute To do right To achieve To create Figuur 2 Levers of control ~ Motiveren van wetenschappers/engineers Interactive: Organizational blocks Uncertainty about purpose Pressure or temptation Lack of focus or of resources Lack of opportunity or fear of risk Managerial solution Communicate core values and mission Specify and enforce rules of the game Build and support clear targets Open organizational dialogue to encourage learning Control lever Beliefs systems Boundary systems Diagnostic control systems Interactive control systems prestatiemeeteenheden (als profit, return on investment, return on net assets) op RD-processen: ~ het isoleren van RD-activiteiten van andere bedrijfsactiviteiten in hun bijdrage aan het bedrijfsresultaat; ~ de (vaak aanzienlijke) time lag tussen RD-inspanningen en mogelijke financiële opbrengsten; ~ de mate van acceptatie van prestatiemeting binnen RD-afdelingen. Productsoftwarebedrijven vallen in de RD-categorie experimental development (product- en procesontwikkeling). Hiervoor gelden weer specifieke management-controlkarakteristieken. Hier gaan we in de volgende paragraaf verder op in. Productsoftwarebedrijven en management control Bij softwarebedrijven is er vooral sprake van experimental development (product development). Basic of applied research komt weinig voor. Product development kan betrekking hebben op het aanbrengen van aanpassingen in bestaande softwareproducten of op het radicaal ontwikkelen van een nieuw product. In beide gevallen vindt de ontwikkeling van productsoftware plaats tijdens een transformatieproces. Twee methoden van ontwikkeling komen het vaakst voor: ~ lineaire ontwikkeling, waarbij elke fase eenmalig wordt uitgevoerd en wordt afgesloten met een mijlpaalproduct dat als bindend wordt ervaren, de zogenoemde watervalmethode; ~ iteratieve of agile (wendbare) ontwikkeling (komt in de productsoftwarebranche het vaakst voor), waarin het bedrijf kortcyclisch delen van de applicatie oplevert en na elk deel opnieuw prioriteiten stelt. Voorbeelden van agile developmentmethoden zijn Scrum en Extreme Programming. DECEMBER

3 Control mode Key characteristics Antecedent conditions Examples of mechanisms Behavior Rules and procedures articulated Rewards based on following rules procedures Knowledge of appropriate behaviors Behavior observability Development methodology Job description Supervisor-subordinate hierarchy Work assignment Rules procedures Outcome Outcomes and goals articulated Rewards based on producing outcomes goals Outcome measurability Defined target implementation date and/or budget Expected level of performance Defined project milestones Clan Common values, beliefs problem-solving philosophy Identification reinforcement of acceptable behaviors Specific task goals evolve over life of the task Appropriate behaviors unknown Outcomes not measurable Coalitions of individuals with shared ideologies Socialization Hiring training practices Implemented rituals and ceremonies Self Individual defines task goals or procedures Individual monitors, rewards, sanctions self Rewards based, in part, on individual s self-control skills Complex or non-routine task Performance evaluation ambiguity Lack of required rules or procedures Desire to exercise self-control Individual s ability Individual empowerment Self-management Autonomy in what individual does on job Autonomy in how individual does the work Self-set goals, self-monitoring, and self-rewarding Figuur 3 Control-modes met karakteristieken Kirsch (1996) heeft onderzoek gedaan naar de keuze van control modes binnen het ontwikkelingsproces van software. Zij borduurt daarbij voort op het model van Ouchi (1979). Hierin is de keuze van de controlstrategie afhankelijk van de kennis van de controller van het transformatieproces en de mate waarin de output meetbaar is. De dimensie die Kirsch toevoegt, is de observeerbaarheid van gedrag. Haar conclusie is dat hoe beter controllers het ontwikkelingsproces begrijpen en hoe beter taken te observeren zijn, hoe waarschijnlijker het is dat ze behavior controls zullen inzetten. In een later artikel heeft Kirsch (1997) control modes weergegeven, met hun karakteristieken en antecedent conditions. Dit is weergegeven in figuur 3. Elke organisatie heeft potentieel en kent blokkades daarop Een aantal karakteristieken van productsoftwarebedrijven en het productontwikkelingsproces zijn van belang. Cusumano (2004) onderscheidt enkele karakteristieken van de softwaresector: ~ kosten van het product zitten volledig in het ontwikkelingsproces en niet in het productieproces; ~ brutowinstmarge is daardoor erg groot (deze kan oplopen tot 99 procent); ~ kosten gaan daarbij voor de baten uit; ~ mogelijke variëteit van mogelijke producten en diensten is bijna oneindig. Softwarebedrijven kunnen zich in hun product marktmix positioneren langs de volgende assen: ~ productbedrijf of dienstverlenend bedrijf zijn (of een hybride vorm); ~ software aan consumenten of aan bedrijven verkopen, binnen een massa- of nichemarkt; ~ product horizontaal (breed) of verticaal (gespecialiseerd) oriënteren. Veel productsoftwarebedrijven gebruiken agile softwareontwikkelmethoden. Deze zijn gebaseerd op de volgende principes (Hoogendoorn, 2004): ~ Ontwikkel software incrementeel/iteratief. Incrementeel ontwikkelen stelt een bedrijf in staat om het project op te delen in een aantal deelproducten en deze afzonderlijk van elkaar op te leveren. Dit verkleint het risico dat het eindproduct niet is wat de klant wil en de klant kan nu per deelproduct zijn feedback geven, wat het bedrijf weer kan meenemen tijdens de ontwikkeling van het volgende deelproduct. ~ Manage software requirements. Requirements management heeft te maken met het achterhalen, vastleggen en beheren van de behoeften van de klant. ~ Maak gebruik van op componenten gebaseerde architectuur. 20 DECEMBER 2011

4 Systemen met een op componenten gebaseerde architectuur zijn eenvoudig uit te breiden, inzichtelijk en begrijpelijk en bevorderen het hergebruik van bepaalde delen van de programmacode. Aangezien de systemen steeds groter worden, neemt het belang van een goede architectuur toe. ~ Maak prototypes. Door de gebruiker een grafische voorstelling te geven van het product (prototyping), verkleint een bedrijf de faalkans van het project. Een globale, grafische oplossing voor het probleem is door de gebruiker beter te begrijpen dan pagina s vol broncode. Casestudies We hebben twee vergelijkbare productsoftwarebedrijven onderzocht op hun management-controlsystematiek. Beide bedrijven: ~ zijn producenten van productsoftware; ~ zijn werkzaam op de Nederlandse markt; ~ zijn actief in een nichemarkt; ~ zijn van gelijke grootte wat betreft medewerkers en omzet; ~ gebruiken eenzelfde ontwikkelplatform. Context Bedrijf 1 heeft een hybride vorm, waarbij zowel productontwikkeling plaatsvindt als dienstverlening die rechtstreeks gekoppeld is aan het eigen product. Het bedrijf produceert software voor bedrijven binnen een nichemarkt en is verticaal georiënteerd. Het bedrijf levert aanvullende diensten in de vorm van consultancy en verschillende vormen van support op het eigen product. Het bedrijf gebruikt een agile softwareontwikkelingsmethode voor de bouw van het eigen product. Bedrijf 2 heeft ook een hybride vorm, waarbij zowel productontwikkeling als dienstverlening op het eigen product wordt Doelstelling/ niveau ~ Bedrijf Gericht op resultaten Bedrijf 1 Bedrijf 2 ~ Afdeling/team Gericht op bijsturing en leereffect Indicatoren/fase ~ Roadmap Opbrengsten/kosten ~ Ontwerp Figuur 4 Doelstellingen en indicatoren casusbedrijven Financieel georiënteerd Input voor verbeterprocessen en bewustwording gedrag ~ Realisatie Uren/storypoints Uren/evaluatie ramingen/functiepunten ~ Onderhoud Meldingen Meldingen Wens Meetbaar krijgen gedrag Meetbaar krijgen proces geleverd. Het bedrijf levert software aan bedrijven binnen een nichemarkt en is verticaal georiënteerd. Het productbedrijf hanteert de watervalmethode als ontwikkelingsmethode. Hoe beter controllers het ontwikkelingsproces begrijpen en hoe beter taken te observeren zijn, hoe waarschijnlijker het is dat ze behavior controls inzetten Management control Bedrijf 1 heeft verschillende doelstellingen voor het meten van prestaties. Op bedrijfs- en afdelingsniveau is de doelstelling vooral om te rapporteren op resultaten. Voor de afdelingsmanagers geldt dat het doel vooral is om tijdig te kunnen bijsturen. Er is de afgelopen jaren een cultuurverandering doorgevoerd met betrekking tot het meten van prestaties, waarbij de onbewuste angst voor het meten omgevormd is in een cultuur waarin medewerkers juist mogen leren van fouten. Bedrijf 2 meet op bedrijfsniveau voornamelijk op de financiële dimensie. Het verkeert in de fase dat het binnen het ontwikkelbedrijf probeert inzicht te krijgen met behulp van indicatoren, zodat het kan sturen op basis van deze indicatoren. Indicatoren zijn daarbij input voor verbeterprocessen en bewustwording van gedrag. Bij bedrijf 1 ligt er veel nadruk op indicatoren die direct met de productrealisatie en -onderhoudsfase te maken hebben. Het bedrijf kijkt binnen de realisatiefase naar uren en storypoints. Een storypoint is een uitdrukking van de mate van complexiteit van de functionaliteit in een aantal punten. Binnen de onderhoudsfase ligt de nadruk op het aantal meldingen dat binnenkomt. Het bedrijf heeft een poging gedaan om aan de voorkant van het proces inzicht te krijgen in het meten van de opbrengsten versus de begrote kosten, maar besteedt hier door gebrek aan managementsturing weinig aandacht meer aan. Bedrijf 2 legt de nadruk op het meten van uren, waarbij het zowel naar de voor- als nacalculatie kijkt. Wekelijks bepaalt het het aantal nog te besteden uren. Er is een begin gemaakt om met functiepunten te gaan werken. Het werken met functiepunten is een alternatief voor storypoints en maakt de omvang van het systeem inzichtelijk door middel van een functiepuntenanalyse. Het management evalueert jaarlijks de ramingen door de realisatie af te zetten tegen de raming. Hoe DECEMBER

5 kleiner de afwijking, hoe betrouwbaarder de ramingen zijn. Binnen de onderhoudsfase maakt het bedrijf binnen de urenbesteding onderscheid naar het type activiteit. Ook bedrijf 2 meet binnen de onderhoudsfase het aantal meldingen. Beide bedrijven hebben weinig indicatoren beschikbaar in de processtappen voorafgaand aan de realisatie- en onderhoudsfase. Beide bedrijven gebruiken aantal uren en aantal meldingen als belangrijke indicatoren binnen het productontwikkelingsproces. Het probleem met deze indicatoren is dat ze weinig zeggen over de productiviteit, effectiviteit en kwaliteit van het ontwikkelingsproces. De directies van beide bedrijven geven aan dat zij meer inzicht willen hebben in de productiviteit en kwaliteit van het ontwikkelingsproces. De directie van bedrijf 1 legt vooral de nadruk op het meetbaar krijgen van gedrag. Bij bedrijf 2 focust de directie op het meetbaar krijgen van processen. In figuur 4 is dit samengevat. De indicatoren die cursief staan, zijn net in gebruik genomen of zijn nauwelijks meer in gebruik. Conclusie De doelstellingen die beide productsoftwarebedrijven gebruiken binnen het productontwikkelingsproces zijn voornamelijk diagnostisch en interactief van aard. De diagnostische doelstelling is gericht op het rapporteren over de prestaties en het kunnen bijsturen bij afwijkingen. De interactieve doelstelling is gericht op het in gesprek komen met de teams. Deze doelstellingen sluiten aan bij het raamwerk van Chiesa (2009). Hij stelt in dat raamwerk dat bedrijven die zich bezighouden met product development vooral gebruikmaken van diagnostische doelstellingen en daarbij ook interactieve doelstellingen kunnen gebruiken. Beide bedrijven richten zich op outcome als control mode, waarbij ze resultaten zo veel mogelijk meetbaar maken. Bedrijf 1 is daarbij verder, en laat meer grip zien op vooral de realisatie- en onderhoudsfase. Directies van beide bedrijven hebben de wens om meer indicatoren inzichtelijk te maken, dus om nog meer outcome control in te bouwen. De focus zou daarbij moeten liggen op de fasen waarin nog weinig indicatoren aanwezig zijn, namelijk het roadmap- en ontwerpproces. Voor productsoftwarebedrijven geldt dat zij beter investeringsbeslissingen kunnen nemen als ze sneller grip krijgen op de kosten en mogelijke opbrengsten. De beperkende capaciteit is de inzet van menskracht en manuren kunnen slechts eenmaal gebruikt worden. Bedrijf 1 heeft als grote wens om behavior als control mode in te zetten. De vraag bij behavior control binnen productsoftwarebedrijven is in hoeverre gewenst gedrag binnen het ontwikkelingsproces goed te definiëren valt en in hoeverre het gedrag te observeren is. Ten slotte doen we de suggestie dat de agile ontwikkelmethode, waarbij multidisciplinaire teams intensief samenwerken, een voorbeeld is van Ouchi s clan als control mode. Deze stelling moet nader onderzocht worden en kan een nieuw licht werpen op de inzet van control modes binnen productsoftwarebedrijven. Literatuur ~ V. Chiesa et al. (2009). Performance Measurement in RD: Exploring the Interplay between Measurement Objectives, Dimensions of Performance and Contextual Factors, RD Management, 39:5. ~ M.A. Cusumano (2004), The Business of Software, New York: The Free Press. ~ T. Davila (2000), An Empirical Study on the Drivers of Management Control Systems Design in New Product Development, Accounting, Organization and Society, 25. ~ S. Hoogendoorn (2004), Pragmatisch modelleren met UML 2.0, Addison Wesley. ~ R.S. Kaplan en D.P.Norton (1992), The Balanced Scorecard: Measures that Drive Performance, Harvard Business Review. ~ I.C. Kerssens-Van Drongelen en A. Cook (1997), Design Principles for the Development of Measurement Systems for Research and Development Processes, RD Management, 27:4. ~ L.J. Kirsch (1996), The Management of Complex Tasks in Organizations: Controlling the Systems Development Process, Organization Science, 7:1. ~ L.J. Kirsch (1997), Portfolios of Control Modes and IS Project Management, Information Systems Research, 8:3. ~ W.G. Ouchi (1979), A Conceptual Framework for the Design of Organizational Control Mechanisms, Management Science, 25:9. ~ R. Simons (1995a), Control in an Age of Empowerment, Harvard Business Review. ~ R. Simons (1995b), Levers of Control. How Managers Use Innovative Control Systems to Drive Strategic Renewal, Boston, MA: Harvard Business School Press. ~ R. te Velde, J. Veldkamp en M. Plomp (2010), De softwaresector in Nederland Survey 2010: in opdracht van ICT~Office, Dialogic. Wouter Schreuder heeft in april 2011 de opleiding tot Registercontroller aan de Erasmus Universiteit afgerond. Momenteel is hij werkzaam als Senior Controller voor het IT-bedrijf van SNS Reaal. Hij heeft ruim tien jaar werkervaring binnen de IT-sector, waarvan de laatste 4,5 jaar in de functie van controller. Dit artikel is gebaseerd op zijn referaat aan de Registercontrolleropleiding van de Erasmus Universiteit Rotterdam. Ko Achterberg is docent Accounting Information Systems aan de Controllersopleiding van de Erasmus Universiteit. 22 DECEMBER 2011