bedrijfsvoering
Beheer bedrijfsregels vergroot flexibiliteit Richtlijnen vaak verscholen in broncode
Bedrijfslogica bevindt zich veelal verspreid in de hoofden van de medewerkers, delen ervan zijn
informatie / juni 2004
vastgelegd in programmacode. Om de bedrijfsvoering
12
Ieder bedrijf kent vele bedrijfsregels; deze regels oefenen een essentiële invloed op het bedrijfsresultaat. Desondanks zijn er maar weinig bedrijven die hun bedrijfsregels expliciet beheren, aandacht besteden aan efficiënte en consistente uitvoering van bedrijfsregels of procedures hebben voor wijzigingen op bedrijfsregels. Bedrijven zijn niet op tijd met de toepassing van nieuwe wetgeving waardoor een achterstand ontstaat in de verwerking van aanvragen; bedrijven hebben moeite met het inspelen op nieuwe marktomstandigheden en de vergrijzing van de medewerkers zorgt ervoor dat expertise zo de bedrijfspoort uit wandelt. De business rules approach is een stroming die aandacht vraagt voor deze situatie. Op basis van praktisch toepasbare principes draagt de deze benadering oplossingen aan. Deze oplossingen helpen bedrijven de efficiëntie, consistentie en flexibiliteit te verhogen bij de uitvoering en het beheer van bedrijfsregels. De basisprincipes voor een beter beheer van bedrijfsregels zijn verwoord in het Step-principe van Barbara von Halle (Hay & Von Halle, 2002): 1. Scheid bedrijfsregels en kennis van
te stroomlijnen moet het algemeen management volgens de auteur bedrijfsregels expliciet beheren. Silvie Spreeuwenberg componenten die niet relevant zijn voor de business (it-componenten). 2. Behoud traceerbaarheid van bedrijfsregels naar de bronnen op basis waarvan deze regels tot stand gekomen zijn en de diverse afdelingen, mensen of systemen die de regels gebruiken. 3. Beheer bedrijfsregels expliciet, los van projecten en mensen. 4. Positioneer de bedrijfsregels in het bedrijfsproces en zorg voor wijzigingsprocedures. De verantwoordelijkheid voor regels hoort in een organisatie belegd te zijn bij de business. De terminologie, nodig voor het opstellen van regels tussen afdelingen, inclusief de it-afdeling, is op elkaar afgestemd. Als regels in itsystemen gebruikt worden zijn deze regels slechts één keer gedefinieerd in een centrale repository. Slechts dan kunnen inconsistenties en incompleetheid van regels in een vroeg stadium worden onderzocht en kunnen wijzi-
gingen in regels snel, met minimale risico’s geëffectueerd worden.
Richtlijnen Bedrijfsregels zijn een vertaling van een bedrijfsstrategie, wetgeving of expertise naar operationele richtlijnen. Elk bedrijf kent dergelijke richtlijnen, ze zijn te vinden in handboeken, procedures en it-systemen. Een veel gebruikte definitie voor bedrijfsregels is ‘iedere richtlijn over gedrag, acties, uitvoering en procedures in een activiteit’ (Business Rules Group, 1995). Het niet voldoen aan een regel heeft consequenties. Hoewel deze consequenties in de praktijk triviaal kunnen zijn of inconsequent uitgevoerd kunnen worden, is dit wel een belangrijke karakteristiek. De woorden die in een bedrijfsregel gebruikt worden moeten eenduidig gedefinieerd zijn, vooral als ze afwijken van normaal gebruik of woordenboekdefinities. Deze woorden worden gedefinieerd in een vocabulaire.
Samenvatting De auteur betoogt dat bij beheer van bedrijfslogica regels en kennis gescheiden moeten worden van voor bedrijfsvoering irrelevante (it-)componten. Duidelijk moet zijn waar regels vandaan komen en wie of welke systemen ze gebruiken. Bedrijfsregels moeten los van projecten en mensen worden beheerd. Ze moeten hun plaats krijgen in de bedrijfsvoering en onderdeel zijn van een wijzigings- en borgingsprocedure.
Een veelgehoorde misvatting is dat bedrijfsregels in het bedrijfsproces zitten. De laatste tijd heeft het bedrijfsleven terecht veel aandacht besteedt aan business process management. Business process management integreert onderdelen van de bedrijfsuitvoering in een integraal bedrijfsproces. De voordelen van deze integratie mogen niet ten koste gaan van de flexibiliteit van de onderneming. Om dit te voorkomen, aldus Jim Sinur van Gartner, moeten de regels die ten grondslag liggen aan de businessprocessen expliciet gedefinieerd en beheerd worden. Ook belangrijke vertegenwoordigers uit de Business Process Management
Voorbeelden van bedrijfsregels, een term en feiten
Group (BPMG) zien een rol voor bedrijfsregels voor de uitvoering en het beheer van processtappen in een bedrijfsproces. ‘Seperate the know from the flow’, aldus Roger Burtlon (2001), voorzitter van de BPMG. Een proces voert geen regels uit maar zoekt de juiste regels op. Een fundamenteel verschil tussen een procesbeschrijving en bedrijfsregels is dat een procesbeschrijving een volgorde aangeeft waarin de stappen doorlopen moeten worden, terwijl bedrijfsregels onafhankelijk zijn van de volgorde waarin zij uitgevoerd worden (en dus declaratief zijn). Volgens Roger Burlton moet de ‘ruit’, de notatiewijze voor een beslissing in een procesdiagram, zoveel mogelijk vermeden worden bij het
1
opstellen van een procesdiagram. Aan deze beslissingen liggen bedrijfsregels ten grondslag. Het gebruik van de ruit kan resulteren in een ongewenste mix tussen bedrijfsregels en processen in een processpecificatie.
Drijfveren De aandacht voor het beheer van bedrijfsregels is geen gevolg van een nieuwe technologische ontwikkeling maar eerder een reactie op operationele problemen waar organisaties tegenwoordig mee te maken hebben. Belangstellenden voor dit onderwerp zijn voor de helft mensen met een itachtergrond en voor de andere helft mensen met een bedrijfsstrategische achtergrond, zo leert analyse van
informatie / juni 2004
De termen in een vocabulaire zijn zelfstandig naamwoorden of een combinatie van een zelfstandig naamwoord en een bijvoeglijk naamwoord. De termen hebben een bepaalde betekenis binnen het bedrijf of binnen een bepaalde context van het bedrijf en deze betekenis is niet ambigu. Termen in het vocabulaire zijn atomair en kenbaar en vormen de basis voor de definitie van feiten. Feiten zijn simpele zinnen die termen met een werkwoord aan elkaar relateren. Door feiten te definiëren breiden we een vocabulaire uit met relaties tussen termen. Regels representeren controle en gedrag en gebruiken de gedefinieerde termen en feiten. Regels kunnen restricties opleggen, een berekening uitvoeren, een conclusie of actie afleiden of een heuristiek beschrijven. De belangrijkste richtlijnen voor het opstellen van regels is dat deze geen impliciete aanname bevatten van de manier waarop, wanneer, waar en door wie de regel wordt toegepast, en dat zij helder geformuleerd zijn (zie ook Ross, 2003).
13
bedrijfsvoering informatie / juni 2004
bezoekers van twee eerdere conferenties over bedrijfsregels. Het probleem en de gevolgen van miscommunicatie in bedrijven kunnen een drijfveer zijn voor het verbeteren van het beheer van bedrijfsregels. Het gebruik van dezelfde woorden met verschillende definities door verschillende afdelingen of personen binnen een bedrijf kan resulteren in langs elkaar heen werken, toepassen van verkeerde regels, onnodig lange discussies in vergaderingen en verkeerde systeemresultaten. Een ander probleem is dat veel bedrijven geen logische benadering hebben
14
voor het definiëren van regels. Het gevolg is dat medewerkers tijdens het uitvoeringsproces nieuwe regels creëren. Deze regels leiden tot verwarring en inconsistentie. Het achteraf oplossen en in kaart brengen van deze problemen is inefficiënt en leidt tot frustraties tussen medewerkers en staf. Een gestructureerde manier om regels te definiëren moet deze situatie voorkomen (Van Engers, 2003). In de huidige economie verwacht men dat bedrijven in staat zijn snel te reageren op nieuwe klantwensen of veranderingen in de markt waarin het bedrijf opereert. Hoe kan de uitvoerende organisatie aan deze wens voldoen? Hoe kunnen de regels snel bekend worden bij medewerkers in callcenters, bij internetportals of bij bedrijfsapplicaties? Zowel de organisatie als itapplicaties zijn vaak niet ingericht op dit soort processen. Kleine wijzigingen in regels resulteren vaak in noodprocedures om gevallen die ten onrechte met oude regels zijn behandeld weer te corrigeren. Een it-afdeling heeft voor
een wijziging van de regels al snel een vooronderzoek nodig om de onderdelen van applicaties op te sporen die aangepast moeten worden, vervolgens moeten de wijzigingen doorgevoerd worden en moet er een volledige regressietest uitgevoerd worden. Niemand kan immers met zekerheid zeggen of er, door onterechte aannames in de codering, onbedoelde neveneffecten door de wijziging zijn ontstaan. Dat dit proces meer dan een paar weken in beslag neemt zal niemand verbazen.
Centrale repository De vraag is of de business deze aanpak nog lang kan verantwoorden? Door bedrijfsregels expliciet in een centrale repository te beheren kunnen regels direct aan de uitvoering bekend worden gemaakt en kan de toepassing van de regels continu worden teruggekoppeld om op deze wijze een gesloten lerend systeem te creëren. Veel bedrijven die het beheer van bedrijfsregels willen verbeteren zoeken
2
Regels omvatten projecten, in ruimte en tijd
niet projectmatig uitgevoerd worden maar als doorlopende activiteit. Kennis kan uit organisaties verdwijnen als mensen hun pensioengerechtigde leeftijd bereiken of een andere baan aanvaarden. Kennis die alleen bestaat in de hoofden van werknemers vormt een risico voor het bedrijf. Gestructureerde
vraag of kennis überhaupt wel kan worden geformaliseerd . De discussie hierover wordt wel aangeduid met ‘flow-en-stock’-discussie. De ‘flow’stroming (zie Weggeman, 1997) denkt dat kennis niet geobjectiveerd kan worden omdat de dragers van kennis hier altijd een subjectieve interpretatie aan geven. De ‘stock’-benadering denkt
»Een it-afdeling heeft al gauw weken nodig om een regelwijziging door te voeren« documentatie van de kennis voorkomt dat deze verdwijnt als medewerkers de organisatie verlaten. Hoewel in kennismanagementprogramma’s aandacht is besteed aan het beheer van kennis in organisaties heeft deze aandacht zich vaak gericht op de impliciete (ook wel ‘tacit’ genoemde) kennis die werknemers van een bedrijf hebben en vaak ook weer meenemen bij ontslag. Bedrijfsregels kunnen de kennis van een organisatie beschrijven die formaliseerbaar is. Door het formaliseren van kennis in bedrijfsregels is deze niet meer ‘tacit’. In de kennismanagementgemeenschap zijn de meningen verdeeld over de
dat kennis geobjectiveerd en bewaard kan worden voor later gebruik (Van Engers, 2003). De ideeën achter bedrijfsregels sluiten aan op de idee dat kennis als formele regels bewaard, hergebruikt en geëvalueerd kan worden.
Modelleerparadigma’s De wijze waarop het vocabulaire voor bedrijfsregels beschreven wordt sluit goed aan bij het modelleerparadigma Object Role Modeling (ORM; www.orm.net). ORM is de Britse variant van de in de jaren zeventig in Nederland ontwikkelde Natuurlijke Taal Informatie Analyse Methode (Niam). Niam voor-
informatie / juni 2004
naar een betere relatie met hun klanten door gepersonaliseerde producten en diensten aan te bieden. Dit resulteert in meer regels terwijl men tegelijkertijd de uitvoering wil versnellen en tegen lagere kosten wil werken. Om dit in goede banen te leiden is een gestructureerde aanpak vereist. Vaak besluiten bedrijven pas iets aan de gangbare werkwijze te veranderen als regels en hun herkomst niet meer te achterhalen zijn. Het vinden van de regels die een organisatie uitvoert is vaak een lange speurtocht langs verschillende bronnen. De regels bestaan uit wetgeving, expertise, interne procedures, richtlijnen, standaarden en contracten tussen bedrijven (bijvoorbeeld een service level agreement). Het is niet ongewoon dat men op basis van deze bronnen geen helder beeld heeft van de regels die een organisatie uitvoert en men deze regels moet opzoeken in de broncode van applicaties. Een nadeel daarbij is dat een it-afdeling doorgaans op basis van projecten aandacht besteedt aan het beheer van de regels. Per project worden regels opgesteld en gecodeerd. Hierdoor is het onmogelijk dat projecten regels hergebruiken of dat wijzigingen op regels op eenvoudige wijze in verschillende systemen worden doorgevoerd. Het beheer van regels moet daarom
15
bedrijfsvoering zag in die periode in de behoefte aan een methode voor het opstellen van relationele-databasemodellen. Het resultaat van toepassing van Niam is een informatiemodel op basis waarvan een relationeel model ontworpen kan worden. Het gebruik van Niam/ORMmethoden in het bedrijfsleven is beperkt doordat databasemodellen vaak opgesteld worden door (technische) itmedewerkers die liever in één keer een relationeel-databaseontwerp maken. De nadruk op natuurlijke taal en leesbaarheid van de grafische modellen met ‘verwoordingen’ (leesbare regels) sluit goed aan bij de nadruk op begrip en beheer door de business.
informatie / juni 2004
UML
16
De Unified Modeling Language (UML), de facto notatiestandaard voor softwaremodellen, sluit niet goed aan bij het expliciet beheren van bedrijfsregels op de voorgestelde manier. Ten eerste is de taal niet geschikt voor gebruik door de business doordat de beschikbare concepten in UML gebaseerd zijn op concepten die in programmeertalen te vinden zijn en niet op concepten die men in de business tegenkomt. Ten tweede heeft de taal geen notie van regels. Hoewel een UML-associatie of een constraint gespecificeerd in de Object Constraint Language (OCL) een bedrijfsregel zouden kunnen representeren, zijn er ook regels die niet met UML-concepten beschreven kunnen worden. De organisatie die UML beheert, de Object Management Group (OMG), is zich bewust van deze situatie. Vanaf 1990 houdt de OMG zich bezig met het beheren van standaarden die integratie van software bevorderen. Standaarden voor integratie op laag niveau (zoals Corba en Com) geven echter geen oplossingen voor migratie-
»UML-concepten zijn gebaseerd op programmeertalen, niet op de business« paden van software naar de ‘nieuwste webinterfacetechniek’. Bedrijven blijven dus problemen houden met de interoperabiliteit van hun systemen. Het antwoord van de OMG is model driven application development (mda). Bedrijfsregels spelen een belangrijke rol binnen OMG’s missie om UML en mda te laten evolueren naar een framework voor het specificeren van algemene en domeinspecifieke software-eisen. De OMG ziet drie modelleerniveaus in mda. Een platform specific model (psm) beschrijft van een bepaald protocol de corresponderende implementatie voor een modelelement. Een modelelement kan bijvoorbeeld een integerattribuut zijn van een UML-klasse in een platform independent model (pim). Het protocol kan Java zijn of een ander technologisch construct. Het psm beschrijft nu hoe je dit integerattribuut kan vertalen naar Java zodat dit model gebruikt kan worden voor het genereren van code. Een pim geeft een modelbeschrijving onafhankelijk van een specifieke implementatie. In dit model worden de objecten, mechanismen en interface van een systeem beschreven en ligt de nadruk op de functionaliteit in plaats van op de techniek. Vervolgens definieert de OMG een computation independent model. Dit model is onafhankelijk van een specifiek mechanisme waarmee het uitgevoerd wordt. Over de definitie van dit model lopen nog veel discussies. Het idee van dit model is dat we van de uitvoering van een bedrijfsactiviteit, bijvoorbeeld opvoeren nieuwe klant, een model kunnen maken en dat dit model onafhankelijk is van het feit of de activiteit uitgevoerd wordt door een mens of door een machine. We beschrijven de activiteit dus vanuit een businessperspectief en niet vanuit een technologisch perspectief. Dit uitgangspunt is redelijk nieuw binnen een organisatie als de OMG waar voornamelijk technische mensen de dienst uitmaken. Voor modellen op dit niveau
werkt de OMG aan een op bedrijfsregels georiënteerde modelleertaal. Het onderzoek rondom het semantic web en ontologieën heeft veel overeenkomsten en overlap met de ontwikkelingen voor een modelleertaal voor bedrijfsregels. Binnen de OMG werken de twee groepen (ontologie en bedrijfsregels) nauw samen.
Technologie Op het moment dat bedrijfsregels uitgevoerd worden met traditionele ‘procedurele’ programmacode, is de programmeur genoodzaakt de regels in een bepaalde volgorde te evalueren. Omdat de regels onafhankelijk van een volgorde zijn opgesteld, kan de programmeur tijdens dit proces een onbedoelde interpretatie toevoegen of ziet hij zich genoodzaakt de bedrijfsregels in de programmacode te dupliceren. Hiermee komt de onderhoudbaarheid van de regels in gevaar. Om dit te voorkomen is het aan te raden met producten te werken die bedrijfsregels expliciet ondersteunen. Producten die het beheer en de uitvoering van bedrijfsregels ondersteunen, kunnen in drie categorieën worden verdeeld: rule engines richten zich op het ondersteunen van regels in een itsysteem, rule-ontwikkelomgevingen richten zich op het definiëren van regels, en rule-managementproducten richten zich op het bedrijfsbreed beheren van regels. De leveranciers combineren een rule engine meestal met een rule-ontwikkelomgeving. Op het gebied van rulemanagement zijn er nog weinig producten. In deze situatie kan verandering komen op het moment dat er een standaard is die uitwisseling van regels tussen producten vereenvoudigt. Opname van één bedrijfsregel in een stukje programmacode is triviaal. Het gaat om de manier waarop een verzameling regels gecombineerd wordt. Sommige rule engines bevatten een
bedrijfsvoering informatie / juni 2004
18
mechanisme, vaak de redeneer- of inferentiestrategie genoemd, om regels efficiënt in een situatie uit te voeren. Er zijn twee redeneerstrategieën voor een rule engine. Een datagedreven redeneerstrategie start met een beschrijving van een situatie: ‘ik weet dat mijn klant dit jaar een bestelling van 50.000 euro heeft geplaatst’ en gaat kijken welke regel gebruikmaakt van deze informatie om eventueel relevante nieuwe informatie af te leiden. Deze nieuwe informatie wordt vervolgens weer op dezelfde manier behandeld als de initiële informatie. De doelgedreven aanpak begint precies andersom. Deze start met een beschrijving van het doel dat bereikt moet worden: ‘ik wil weten of deze klant de status vaste klant kan krijgen’ en bekijkt vervolgens welke regels kunnen helpen bij het beantwoorden van de vraag. De condities van relevante regels worden vervolgens op dezelfde manier behandeld als het initiële doel. De datagedreven redeneerstrategie wordt vaak in batchapplicaties gebruikt en de doelgedreven aanpak wordt eerder in front-officeapplicaties gebruikt. De evaluatievolgorde van regels kan het proces van het uitvragen van informatie leiden, waardoor gebruikers alleen de gegevens hoeven op te voeren relevant zijn voor de specifieke taak. Een andere klasse rule engines, zonder redeneermechanisme, richt zich meer op databases. De bedrijfsregels worden in deze systemen vertaald naar databaseconstraints of -triggers. Net als andere typen rule engines kunnen zij gebruikt worden in een back- en frontofficesysteem en onderscheiden zij zich met de wijze waarop het beheer van de regels is ingericht. Deze producten zijn
vaak gekoppeld aan een bepaald type databaseomgeving. Gartner doet onderzoek naar de verschillende producten voor bedrijfsregels (Sinur, 2003). Hoewel sommige partijen in deze markt al meer dan 25 jaar oud zijn komen er nog steeds nieuwe partijen bij. Producten onderscheiden zich met het platform en de wijze van integratie, variaties of optimalisaties van een redeneermechanisme. De meeste producten ondersteunen één redeneermechanisme. Verder kunnen deze producten zich onderscheiden door hun run-time performance en de wijze waarop het beheer van de regels is ingericht.
Literatuur Business Rules Group (1995). Defining Business Rules – What Are They Really? www.businessrulesgroup .org. Burlton, R.T. (2001). What Not How: Business Process Management: Profiting from Success. Indianapolis: Sams Publishing. Engers, T. van (2003). Inaugurale rede acceptatie hoogleraar juridische kennismanagement. Amsterdam: Vossiuspers UvA. Hay, C., B. von Halle (2002). Requirements Analysis: From Business Views to Architecture. New Jersey: Prentice Hall. Ross, R. (2003). Principles of the Business Rule Approach. Boston: Addison-Wesley. Sinur, J. (2003). Architecting Agility With Business Rules. Gartner Research Note, COM19-9972. Sinur, J. (2003). The Business Rule Engine 2003 Magic Quadrant. Gartner Research Note, M19-4791. Weggeman, M. (1997) Kennismanagement, inrichting en besturing van kennisintensieve organisaties. Schiedam: Scriptum Management.
Toekomst
Silvie Spreeuwenberg is directeur en mede-oprichter van LibRT. E-mail: silvie @librt.com.
De verwachting is dat de Business Rules Work Group (BSWG) van de OMG dit jaar haar eerste standaard met de werknaam ‘Business Semantics for Business Rules’ zal effectueren. Deze standaard is gebaseerd op predikatenlogica en biedt ondersteuning voor het werken met verschillende community’s met ieder hun eigen vocabulaire. De verwachting is dat de standaard productleveranciers zal aanmoedigen producten te leveren voor het beheer van regels op businessniveau. Een trend in de markt is de samenwerking tussen leveranciers van business process management-tools en rule engines. De bedrijfsregels ondersteunen dan de uitvoering van een processtap. De toenemende vraag naar agility (wendbaarheid) en de toenemende mate waarin de bedrijfsregels onderhavig zijn aan veranderingen zullen het gebruik van regels doen toenemen om flexibiliteit te garanderen. Gartner ziet deze ontwikkeling als volgt: ‘het aantal businessapplicaties dat variabele bedrijfsregels gebruikt zal groeien van circa 10 tot 15 procent in 2002 tot tussen de 30 en 35 procent tegen het jaar 2007 (0,7 waarschijnlijkheid).
European Business Rules Conference Op 16, 17 en 18 juni vindt in Amsterdam de derde jaarlijkse Europese conferentie over bedrijfsregels plaats. Tijdens de conferentie worden nieuwe ontwikkelingen in de organisatorische en technologische aanpak van bedrijfsregels besproken en wordt nieuwe technologie voor het beheer ervan gedemonstreerd. Enkele sprekers zijn: Jim Sinur (Gartner Research), Ronald G. Ross, John Zachman en Terry Halpin. Meer informatie op www.eurobuzrules.org.
