Veel organisaties kijken welke applicaties naar de cloud kunnen. Is het een optie om dat ook te doen met software voor business process management (bpm)? Bedrijven kunnen met bpm-software hun applicaties en technologie van begin af aan afstemmen op de interne organisatie. Zo kan het er bijvoorbeeld zorg voor dragen dat een nieuwe order eerst wordt goedgekeurd door een leidinggevende, voordat de bestelling wordt doorgegeven aan de leverancier. Dikwijls maakt het deel uit van een service-georiënteerde architectuur (service oriented architecture, soa) en bpm maakt het voor organisaties mogelijk om hun applicaties en processen snel aan te passen aan veranderingen in de bedrijfsvoering.
Grote ondernemingen willen hun software voor business process management (bpm) maar wat graag laten hosten in een publieke cloud. Naast lagere kosten, geen (vaste) infrastructuur, lage onderhoudskosten en snellere implementatie dat een publieke cloud te bieden, heeft vraag ik me af of bpm in de cloud verder nog nadelen heeft die deze ontwikkeling in de weg zullen staan. Ondertussen groeit namelijk, een andere variant, het gebruik van bpm in een privé cloud hard door.
Verschillende clouds
Cloud computing kun je uitsplitsen naar privé cloud, publieke cloud en SaaS. Het verschil tussen cloud computing en software as a service (SaaS) wordt in de kern bepaald door de mate van uitbesteding die wordt toegepast. Een SaaS-leverancier levert een bpm-platform die aan is te roepen via een browser. Een cloudplatform daarentegen laat een bedrijf zelf zijn software installeren op een groep met elkaar verbonden servers die van het bedrijf zelf zijn (privé cloud), of die zijn gehuurd van een provider.
Vaak worden de kosten aangehaald als hét grote voordeel van een cloudgebaseerde bpm-oplossing, maar er zijn ook andere factoren die een rol spelen. Een van de grootste voordelen van levering via de cloud is de snelheid waarmee het systeem kan worden ingezet. Niet alleen hoef je geen hardware speciaal klaar te zetten, ook is de applicatie beschikbaar voor zowel klant als leverancier zonder dat firewallproblemen roet in het eten gooien, vanaf het eerste uitrolmoment en de testfase tot de laatste kleine configuratiemomenten.
Exorbitant
Elk bedrijf dat bpm wil implementeren, of het nou in de cloud is of niet, moet zijn doelen goed in het vizier hebben. Hoewel dat logisch lijkt is dit niet altijd het geval. Vaak schaffen bedrijven een bpm-pakket aan met de door de leverancier geschapen verwachting dat het 'alles doet wat je nodig hebt'. Maar uiteindelijk kwamen ze erachter dat de kosten van het aanpassen van de applicatie om daadwerkelijk aan zakelijke behoeften te voldoen zo exorbitant waren, en dat de implementatie dusdanig lang duurde, dat het project op de klippen liep.
Niet-goed-geld-terug
Ook de kosten moeten goed in de gaten worden gehouden. Je betaalt niet alleen voor de software, maar ook voor de hardware, de ontwikkeling, het onderhoud en eventuele doorontwikkeling. Om de kosten niet uit de pan te laten rijzen is het verstandig om een vast tarief te bedingen die al deze ontwikkelingen omvatten. Niet alleen hou je zo de kosten onder controle, het werkt ook bijzonder verhelderend als de verkoper moeilijk doet over een implementatie in drie maanden voor een vast tarief. Daarnaast ben ik groot voorstander van een soort niet-goed-geld-terug garantie voor het geval dat de implementatie mislukt. Dit maakt de overstap naar bpm in de cloud minder risicovol en zien bedrijven duidelijk het vertrouwen van de bpm-leverancier. Tot slot is het aan te bevelen om goed onderzoek te doen naar de aanpasbaarheid van het systeem als de behoefte verandert; kan de klant dit zelf of zit de klant vast aan vaste (hoge) uurtarieven?
