De laatste jaren hoor ik steeds vaker dat mijn klanten Siebel als duur ervaren. De business-owners vinden dat het doorvoeren van changes te lang duurt en te veel kost. In een APM (Application Portfolio Management) traject staan de jaarlijkse Siebel support fees steevast in de top 5 waardoor Siebel de volle aandacht van de CIO heeft bij rationalisering van het landschap. Ook de release- of changemanagers ervaren Siebel vaak als een lastig platform om door de acceptatie- en productieomgeving te loodsen. De roll-out duurt lang en ondanks jarenlange ervaring gaat het nog regelmatig verkeerd.

Ik vraag mij echter af of dit beeld wel terecht is. Is Siebel echt duur? Is het een inefficiënt platform om veranderingen door te voeren? Is de roll-out inderdaad foutgevoelig en omslachtig?

Vroeger was alles beter

Vijftien jaar geleden, toen ik mijn eerste Siebel implementaties uitvoerde was dit beeld heel anders. Als Siebel consultants hadden wij direct contact met de business. We bespraken de wensen, bouwden een prototype, verifiëerde het prototype met de key-users en bouwden de gewenste functionaliteit binnen enkele weken. We testen vaak binnen het team; de ontwikkelaar deed de unit test en zijn collega de systeemtest, de key-user deed de acceptatietest. Als er geen bevindingen waren dan voerden we gezamenlijk met de technische beheerder de release naar productie. De roll-out ging niet altijd soepel. We vergaten wel eens een LOV-waarde of een view maar dit losten we gewoon op de eerste productiedag op. Siebel was super agile. Wat een verademing ten opzichte van de legacy systemen.  De Siebel consultant was een vlotte jonge alleskunner. We deden de business analyse, de gebruikersworkshops, we configureerde, scripten, EIM’den, verifiëerden en deden de roll-out. Alles binnen één multidisciplinair team waarin wij samen met de DBA en technische beheerder alle macht hadden. Wanneer de server herstart moest, en dat moest in Siebel 2000 en de eerste Siebel 7 versies regelmatig, dan gaf ik de services een schop en kon er weer worden doorgewerkt. De business was tevreden en onder de indruk van de snelheid, ze kregen eindelijk wat ze zelf wilden.

Eigenlijk wel gek

Gek, wat is er dan in vijftien jaar veranderd? Waarom is het beeld zo sterk veranderd? Het liefst zou ik hierop willen antwoorden: “Vroeger waren de Siebel consultants veel beter en slimmer dan nu!”, maar dit geloof ik niet. De jonge professionals die wij bij Ebicus opleiden zijn van hetzelfde kaliber of zelfs beter dan ik was. En door de jaren heen heb ik vaak samengewerkt met jonge slimme professionals van andere bedrijven. Bovendien zie ik op veel Siebel implementaties nog steeds enkele ouwe rotten uit het eerste uur.

Is Siebel 8 wellicht complexer en lastiger geworden? Ook dit lijkt mij onwaarschijnlijk. Siebel documentatie is door de jaren heen duidelijk verbeterd. De “hidden” features in classes, user properties en standaard Business Services zijn beter gedocumenteerd en toegankelijker dan ooit. ADM heeft het releaseproces vereenvoudigd, bedrijven hebben hun eigen goed werkende Release Admin Sheet of maken gebruik van third party software zoals Xebia of Atomic.

Waar zit dan het grote verschil? Ik heb hier eens diep over nagedacht. Wat is er nu de afgelopen tien jaar zo veranderd in het Siebel landschap dat we van snel en goedkoop naar langzaam en duur zijn gegaan?

Ik kan het natuurlijk niet empirisch toetsen, maar ik denk dat ik enkele oorzaken kan noemen. Over het algemeen kost het daadwerkelijk configureren in Siebel niet meer tijd dan vroeger. Een applet is een applet en een BC is een BC. Misschien kost het implementeren van complexe functionaliteit iets meer tijd omdat het binnen een web van bestaand maatwerk moet worden ingepast. Daarentegen zijn de bouwteams vaak zeer ervaren en kennen zij de bestaande Siebel applicatie door en door. Een uitzondering hierop is wellicht het uitbesteden naar India of een andere goedkoop land waar de workforce regelmatig veranderd.

Siebel is onderdeel van een complexe IT-infrastructuur 

Siebel is onderdeel van het gevestigde IT landschap geworden. Legacy. Door de jaren heen is er steeds meer functionaliteit toegevoegd en Siebel is steeds meer geïntegreerd binnen een complexe keten. Siebel wordt al lang niet meer in een klein agile multifunctioneel team ontwikkeld en beheerd. Change en Run zijn uit elkaar gegroeid. Dezelfde release- en changemanagers die Siebel nu als rigide beschouwen, stellen zelf de releaserequirements en -procedures op die elke vorm van risico moeten uitsluiten.  Logisch, Siebel is het domein van de servicemanager geworden.  Er moet aan steeds hogere servicelevels worden voldaan (bijv. van 8 X 5 naar 24 X 7, toegenomen BIV classificatie). Dit alles vertaald zich weer in nog stringentere procedures. Niemand kan de impact van een change door de gehele keten overzien, in plaats van risico’s te managen vluchten release- , changemanagers en testmanagers in risicomijdend gedrag en moet alles volledig dicht worden getimmerd.

Naast het testen en uitrollen van de nieuw gebouwde functionaliteit zie ik dat analysetrajecten ook vaak tijd- en geldverslindend zijn. Het is niet gek dat de meeste IT-organisaties overstappen op SCRUM en hierbij business, analisten, developers en testers weer dichter bij elkaar brengen.

Kan het zijn dat het een golfbeweging is? Elke ontwikkeling in een nieuwe techniek begint agile. Zodra de nieuwe techniek integraal onderdeel van het gevestigde IT landschap wordt, verstikken we in een complexe organisatie die gedreven wordt door bureaucratie, procedures en functiescheiding. In de jaren 80 en 90 zagen we dit bij de back office, in de jaren 90 en 00 bij de front office en CRM, nu gaan we binnenkort hetzelfde zien bij het web en de front end.

Siebel is niet duur

Is Siebel dus nu zo duur? Nee, ik denk dat dit meevalt. Het is niet de techniek die het duur maakt maar de veeleisende organisatie en landschap waarin de Siebel changes moeten worden doorgevoerd. Na meer dan vijftien jaar Siebel blijft natuurlijk de vraag of anno 2015 de fit for purpose van Siebel opweegt tegen de TCO.  En dat is een totaal ander vraagstuk.

Patrick Gaspersz
Senior Consultant
Ebicus