Procesgebaseerde software keuze – of ontwikkeling

process-based-software-banner

Waarom procesgebaseerd?

Niemand zal ontkennen dat software, bij uitstek, procesoptimalisatie mogelijk maakt. Het helpt de procesefficiëntie te verhogen, het maakt procesinnovatie, standaardisatie, kwaliteitsbeheer mogelijk; het laat ook een effectiever beheer toe dankzij nog betere beslissingen, enz.

Echter, ik heb al te vaak moeten vaststellen hoe ‘erbarmelijk’ de keuze van adequate software wordt gemaakt door organisaties: bv. organisaties die een software kiezen omdat één van de managers vernomen had dat een concurrent, een leverancier, of een klant die software gebruikt. Waarbij de echte (functionele) behoeften voor een optimale ondersteuning van de bedrijfsprocessen gewoonweg genegeerd worden. Of erger nog: er wordt eerst hardware gekozen, en dan de software die zou kunnen passen op de verworven hardware.

Daarom vind ik het nog steeds nuttig om ‘best practices‘ bij softwarekeuze – of ontwikkeling – toe te lichten. In de hoop dat managers die deze blog lezen de meest optimale software voor hun eigen organisatie zullen kiezen; of het nu een bestaand softwarepakket is – zogenaamde COTS (Commercial off-the-shelf Software) -, of het om op maat gemaakte software gaat.

Beginnend bij het strategische niveau

Het begint eigenlijk al op het strategische niveau: afhankelijk van jouw strategische focus, volgens Treacy & Wiersema’s waarde disciplines. Dit betekent dat je primair moet focussen op een van de 3 onderstaande waarde disciplines:

Product / Dienst differentiatie

Een bedrijf dat streeft naar het leveren van uitstekende, unieke producten kan best prioriteit geven aan Product Lifecycle Management (PLM) software. Overeenkomstig, kan een organisatie die focust op uitstekende diensten het best de nadruk leggen op Service Lifecycle Management (SLM) software, om zo excellente diensten te ontwerpen, te organiseren en te leveren.

value-disciplinesCustomer intimacy

Wanneer een organisatie focust op erg diepgaande – zeg maar intieme – relaties met haar klanten, dan is eerder een Customer Relationship Management (CRM) software een logische en meest geschikte keuze.

Operationele Excellentie

Het klinkt vanzelfsprekend dat voor een organisatie die beoogt om aan de scherpste prijs te leveren voor een gegeven kwaliteit, de meest voor de handliggende software dan Enterprise Resources Planning (ERP) of Supply Chain Management (SCM) software is.

Echter, zoals Treacy & Wiersema aangeven, mag een organisatie niet enkel een dominante strategische focus hanteren, maar moet het ook de twee andere waarde disciplines op een hoog niveau houden, het zogenaamde olympisch minimum. Zo moet bv. een low-cost vliegtuigmaatschappij een aanvaardbaar service niveau hebben, ook al is dit service niveau lager dan dat van een luchtvaartmaatschappij die business class vluchten aanbiedt. Het is daarom niet omdat je reeds CRM software hebt geïmplementeerd, gegeven jouw focus op “customer intimacy”, dat je helemaal geen ERP, SCM of PLM types software kan overwegen.

En nu, naar tactische & operationele niveaus

De hierboven beschreven prioriteit is wellicht de gemakkelijkste keuze die gemaakt moet worden, althans voor de organisaties die een duidelijke strategische focus hebben. Eens je op lagere niveaus gaat kijken, moet je bepalen welke software functionaliteiten precies nodig zijn om jouw bedrijfsprocessen optimaal te ondersteunen. En dit is waar de rest van deze blog over gaat.

Breng jouw bedrijfsprocessen in kaart

Vooraleer te beoordelen hoe jouw bedrijfsprocessen door software ondersteund kunnen worden, moet je natuurlijk jouw bedrijfsprocessen kennen; op zijn minst degene die je wilt automatiseren. Als je nog nooit de bedrijfsprocessen van jouw organisatie in kaart hebt gebracht, zijn er twee voornaamste aanpakken om dit te doen.

Top-down, beginnend vanaf de Waardeketen

Als je een exhaustief beeld nodig hebt op alle activiteiten van jouw organisatie – wat sterk is aan te raden wanneer je organisatie-breed project overweegt zoals de implementatie van bv. ERP-software – dan is dit meestal de beste aanpak. Beginnen met Porter’s generieke waardeketen kan nuttig en handig zijn bij de meeste commerciële bedrijven die eerder over traditionele primaire en ondersteunende processen beschikken.

Bottom-up, identificeren van de vele bedrijfsprocessen

top-downAndere organisaties – zoals overheidsorganisaties, NGOs, of andere non-profit organisaties – hebben dikwijls zo’n specifieke activiteiten dat enige verwijzing naar Porter’s generieke waardeketen weinig zinvol is. Wanneer ik bijvoorbeeld de bedrijfsprocessen voor de kinderopvang afdeling van de Europese Commissie in kaart bracht, kun je je voorstellen dat ik noch zocht naar inkomende of uitgaande logistiek, noch naar marketing & sales processen.

In dit geval, kan je dan beter beginnen met de identificatie van alle belangrijke bestaande activiteitsdomeinen, bijvoorbeeld door de kennis over bestaande software toepassingen te verzamelen, of zelfs het organogram te beschouwen. Om zo de mogelijke bedrijfsprocessen er uit af te leiden.

Tenzij je slechts één of enkele specifieke processen wilt automatiseren, kan je dan de waardeketen samenstellen, gebaseerd op de vele bedrijfsprocessen en hun onderlinge afhankelijkheden. Op deze manier krijg je een holistische visie op alle activiteiten van de organisatie, en zal het mogelijk zijn aan te duiden welke delen van de waardeketen – dus welke processen – een impact zullen ondervinden van de nieuwe software. Dit is tevens een belangrijk voordeel van de zogenaamde bedrijfs- of enterprisearchitectuur. Het in kaart brengen en kennen van al jouw bedrijfsprocessen biedt trouwens ook de mogelijkheid om systeemdenken in jouw organisatie gemakkelijker toe te passen, nl. dankzij de kennis van onderliggende verbanden tussen de talrijke activiteiten.

Identifieer atomaire activiteiten en functionaliteiten

Functionaliteiten, die automatiseerbare verwerkingen zijn, zouden afgeleid moeten worden van atomaire activiteiten of processtappen – in BPMN “taken” genoemd. En dit verdient wat meer uitleg…

Wat zijn atomaire activiteiten?

Atomaire activiteiten, of taken, komen overeen met werk in een bedrijfsproces dat niet zinvol kan worden opgesplitst in meer gedetailleerde delen. Laten ons dit a.h.v. volgende 2 voorbeelden illustreren.

Voorbeeld 1 – “Invullen van het inschrijvingsformulier” :

functionalityDit is een typisch atomaire activiteit of BPMN-taak. Zelfs wanneer je deze taak verder onderverdeelt, in bv. vul het veld ‘naam’ en dan vul het veld ‘adres’, enz. dan kan je je terecht afvragen of deze verdere decompositie van werk nog zin heeft. Inderdaad, het invullen van een formulier hoort meestal door éénzelfde persoon te worden uitgevoerd, in één tijdseenheid en op éénzelfde plaats. En dat is net wat de atomiciteit van een activiteit betekent: iets dat wordt gedaan

  • door 1 persoon of machine (of 1 productie eenheid)
  • in één tijdseenheid, dus niet gespreid over de tijd heen
  • op éénzelfde locatie
Voorbeeld 2 – “Solliciteer voor de job”

Zo’n activiteit is doorgaans niet atomair, aangezien dit niet in 1 keer gebeurt. Inderdaad, de kandidaat voor de job zal wellicht eerst met de potentiële werkgever contact nemen, bv. via telefoon, e-mail of via LinkedIn, enz. Als hij of zij daarin slaagt, dan volgt er waarschijnlijk een afspraak voor een sollicitatiegesprek. Of zelfs een assessment, of eventuele psycho-technische testen. En de werkgever zal wellicht niet onmiddellijk beslissen na het gesprek. Dit is dus duidelijk geen atomaire activiteit, maar eerder een groep van taken, gespreid doorheen de tijd, eigenlijk een sub-proces dus. En elke activiteit heeft zijn specifieke capabilities (behandelingen) en/of functionaliteiten.

Capabilities (of bewerkingen of behandelingen) en Functionaliteiten

Eens je de bedrijfsprocessen hebt ontleed tot hun atomaire activiteiten, dan is de volgende stap het bepalen van hun respectievelijke bewerkingen of behandelingen (in het Engels “capabilities” genoemd), die nodig zijn om elk van deze taken uit te voeren. Onderstaand voorbeeld illustreert een aantal (4) capabilities die nodig zijn om de atomaire activiteit weeg de lading grondstoffen, uit te voeren. Deze worden voorgesteld door de 4 (blauw-)groene rechthoeken aan de linkerkant.

BL4-NL (2)

Zoals je kan zien, hebben capabilities een ruimere betekenis dan functionaliteiten. Inderdaad, een capability kan ook een menselijke vaardigheid (of competentie) zijn. In bovenstaand voorbeeld, duiden de eerste 2 capabilities op de kennis, zeg maar de vaardigheden, die de gebruiker nodig heeft; dit zijn dus geen functionaliteiten. Terwijl de 2 onderste eerder capabilities zijn die manueel kunnen worden uitgevoerd. Zo kan het gewicht van de lading bv. worden bepaald door het netto gewicht af te trekken van het brutogewicht van de vrachtwagen; terwijl het registreren van de weeggegevens ook manueel uitgevoerd kunnen worden, door deze bv. in een boek te noteren. Maar deze 2 laatste kunnen even goed functionaliteiten zijn, omdat ze ook geautomatiseerd kunnen worden. Als een optische lezer bv. de nummerplaat van de vrachtwagen automatisch kan inlezen, dan kan een software respectievelijk het brutogewicht en het nettogewicht linken aan hetzelfde voertuig; en op die manier het nettogewicht automatisch berekenen. En dit kan dan ook automatisch geregistreerd worden in een database. Dit zijn dus typische functionaliteiten, omdat deze capabilities beschouwd worden als automatiseerbaar. Functionaliteiten zijn dus verwerkingen die mogelijks geautomatiseerd kunnen worden, dankzij software toepassingen, of door robots.

Blog 002-NL

Een functionaliteitenlijst: de basis voor jouw software specificaties

Nadat je alle nodige verwerkingen, en de daaruit afgeleide functionaliteiten, hebt geïdentificeerd voor de betreffende bedrijfsprocessen, heb je dan de basis voor een zeer objectieve software keuze – of voor software ontwikkeling. Onderstaande tabel illustreert hoe functionaliteiten – en dus functionele specificaties – werden afgeleid uit de capabilities in bovenstaand voorbeeld; en op hun beurt, hoe deze capabilities werden afgeleid uit de taak “Weeg de lading grondstoffen“, alsook voor 2 andere taken van hetzelfde bovenstaand proces, zijnde “Neem staal van geleverde grondstof” en “Analyseer staal met grondstof“.

Functionality-table-NL

Capabilities als mogelijke functionaliteiten

Een van de  voornaamste redenen waarom het oplijsten van capabilities – en niet alleen van de bestaande functionaliteiten – belangrijk is, is omdat manuele capabilities mogelijks geautomatiseerd kunnen worden bij het overwegen van de nieuwe software. En op die manier dus een functionaliteit kunnen worden. Zoals hierboven reeds toegelicht voor de 2 functionaliteiten “Bepalen van het gewicht” en “Registratie van de gegevens“, en tevens aangeduid met een groene ‘ja’ in bovenstaande lijst.

Modellen & Vereisten, de basis voor…

Nu vraag je je misschien af wat je nog verder allemaal kan doen met wat je tot nu toe hebt bereikt, zoals het bepalen van de capabilities en functionaliteiten. Meer dan je op het eerste zicht zou denken; de bedrijfsprocesdiagrammen en de respectievelijke capabilities en functionele vereisten zijn inderdaad de basis voor…

…jouw typebestek, RfP of RfQ

rfqDe lijst van functionele vereisten is inderdaad de basis voor het kwalificeren of selecteren van potentiële software leveranciers. En om hen een voorstel, offerte – op zijn minst een inschatting – te vragen van de inspanningen om de software te implementeren. Als je graag zo een RfP (Request for Proposal) of RfQ (Request for Quotation) wil zien, dat gebaseerd is op procesomschrijvingen en de respectievelijke functionaliteiten, dan vraag het me gerust. Het zou je kunnen helpen om de structuur te begrijpen, en zal jou wellicht inspireren om jouw eigen typebestek voor software te schrijven.

…jouw demonstratie scenario’s

Eens je weet hoe jouw processen verlopen – of beter nog: hoe ze zouden moeten verlopen in de toekomst – is het veel gemakkelijker om demo scenario’s te definiëren, zodanig dat je gedurende de belangrijke software evaluatie fase “aan het stuur zit”. Aangezien je nu weet wat de software allemaal zou moeten kunnen doen (d.i. welke activiteiten het moet kunnen ondersteunen en op welke manier), ben je goed voorbereid om de software objectief te evalueren, en een optimale keuze te maken. Je zal niet alleen weten of de vereiste functionaliteiten al dan niet aanwezig zijn, maar dankzij de demo, zal je ook een idee hebben van hoe geschikt en efficiënt de software is voor jouw belangrijkste processen, zoals je ze optimaal wilt implementeren voor jouw organisatie.

…jouw fit-gap analyse

Door de vereiste functionaliteiten te vergelijken met diegene die worden aangeboden door (potentiële) leveranciers, zal je gemakkelijker de “fit” versus de “gaps” van de aangeboden software kunnen inschatten; wat tevens gemakkelijker zal leiden tot…

…jouw “make or buy” beslissing

make-or-buyMet een lijst van functionele vereisten, en na het analyseren van de “fit” en “gaps”, ben je veel beter uitgerust om te bepalen of bestaande software op de markt – COTS software – past bij de werkelijke noden van jouw organisatie. Het zal dus duidelijker zijn om te beslissen of het haalbaar is om COTS-software aan te schaffen en te implementeren of als je de software beter op maat ontwikkelt (of laat ontwikkelen). Een vuistregel was dat wanneer je minstens 70% van de nodige functionaliteiten standaard terugvindt, dan COTS-software overwogen kan worden. In alle andere gevallen, is maatsoftware waarschijnlijk de beste keuze. Hoewel dit vandaag de dag, dankzij Service Oriented Architecture, even goed een combinatie kan zijn van beschikbare en van zelf ontwikkelde componenten. Dan heb je wel IT-deskundigen nodig die dit “assemblage werk” voor elkaar kunnen krijgen, maar jouw bedrijfsprocessen goed moeten begrijpen.

…jouw inspanningen inschat

Ongeacht of je nu software gaat kopen of ontwikkelen, de kennis van de benodigde functionaliteiten en hun doel zullen ongetwijfeld ook helpen om de inspanningen – nodig om de software te ontwikkelen of te configureren – in te schatten. En dit, ongeacht de projectaanpak (Waterval, Agile, enz.) of de inschattingsmethode die je gebruikt. Inderdaad, user stories, story points, use cases, functiepuntanalyses, enz. zijn allemaal hoe dan ook afgeleid van bedrijfsprocessen, hun respectievelijke taken en de overeenstemmende functionaliteiten die deze ondersteunen.

…jouw test scenario’s & test cases

Tenslotte, kan je ook de procesmodellen en functionele vereisten gebruiken om de software te testen zodra die geïmplementeerd is. Inderdaad, je kan de software best (ook) testen vanuit het oogpunt van hele ‘end-to-end’ bedrijfsprocessen; en dus door na te gaan of de software wel degelijk het proces helemaal ondersteunt zoals het (her)ontworpen werd. Dit is ook bekend als Business Process Testing of Business Process validation.

Wat is jouw ervaring met procesgebaseerde software selectie of ontwikkeling? Of jouw mening hieromtrent? Deel het mee via onderstaand vak Reacties en ontvang een gratis trainingspakket (Engelstalige video’s) over procesmodelleren & BPMN.

P.S.: Aarzel niet om deze blog te delen met je Facebookvrienden en –fans, LinkedIn contacten, Twittervolgers en Google+ circles via de share knoppen hieronder. Bedankt!