14 december 2011

Uitstekende kennisuitwisseling over het begroten van IT

Vorige week had ik de eer om de opening keynote te mogen houden op de Galorath Conferentie. Hoewel de conferentie georganiseerd werd door een leverancier van Cost Estimating Software was het een uitstekende en open kennisuitwisseling over het begroten van IT. De conferentie kende een goed mix van sprekers die verschillende puzzelstukjes presenteerden rondom verschillende aspecten van het begroten van IT. Binnenkort kunnen de presentaties worden gedownload van de Galorath website, maar hierbij alvast mijn persoonlijke impressie:


Estimating and Pricing of Application Management in Oracle EBS
Frank Vogelezang, Ordina
In mijn opening keynote heb ik twee onderwerpen belicht die zowel in de wereld van IT begroten als in de de Pricing community regelmatig ter sprake komen.
Het eerste onderwerp is de vaststelling dat begroten en pricing twee verschillende disciplines zijn, die elk hun eigen vaardigheden en mindset vereisen. Begroten is een engineering discipline die leidt tot de beste inschatting van het aantal eenheden (uren, apparaten, licenties, CPU-cycly enz.) om een IT-oplossing te realiseren of een afgesproken niveau van dienstverlening te garanderen. Begroten gaat over het beheersen van je eigen vak. Pricing is de discipline om die oplossing of dienst zodanig aan te bieden dat een klant voor mijn aanbieding kiest. Dit heeft dus veel meer te maken met weten wat de klant nodig heeft en belangrijk vindt en welke criteria hij hanteert om zijn keuze te bepalen. Pricing gaat over het kennen van de klant. Bij Ordina hebben we een eenvoudig model ontwikkeld om iedereen die betrokken is bij de totstandkoming van een aanbieding te bepalen bij zijn rol in het proces.
Het tweede onderwerp is het begroten van Applicatie Management. Het belangrijkste issue daar is de scope van de dienstverlening. Applicatie Management is in de ene organisatie iets heel anders dan in een andere organisatie. Om dat goed te kunnen begroten heb je dus een flexibel begrotingsmodel nodig. Als je dan ook nog eens Applicatie Management doet voor Oracle E-Business Suite implementaties wordt de uitdaging nog iets groter, omdat de informatie die voor de ingang van een contract beschikbaar is, doorgaans niet geschikt is om met reguliere metrieken voor functionele omvang, zoals COSMIC of FPA uit de voeten te kunnen.
Voor een wat meer onafhankelijke review van mijn keynote verwijs ik je graag naar Dan Galorath's Blog.

The Technical Debt Challenge
Geert-Jan Waanders, CAST Software
CAST Software is gespecialiseerd in de analyse van de kwaliteit van software. Dit levert niet alleen een analyse op van welk deel van de software bedreig(en)d wordt, maar dit kunnen zij ook vertalen naar de technical debt. Technical debt is een inschatting van de kosten die nodig zijn om de bedreigingen voor de korte termijn (niet afgehandelde uitzonderingen die tot crashes kunnen leiden) of voor de langere termijn (gecompliceerde code die niet onderhouden kan worden) te repareren. Hun analysesoftware is niet alleen geschikt voor maatwerksoftware, maar kan ook overweg met pakketten als SAP, Siebel en PeopleSoft.
In de discussie na afloop kwam nog een ander aspect van technical debt naar boven: achterstallige innovatie of de backlog aan nog niet geïmplementeerde verbeteringen. Voor dat aspect zou begrotingstooling een mooie aanvulling kunnen vormen bij de bepaling van de technical debt.

Estimating SAP HR implementations in Lukoil
Ton Dekkers, Galorath Consulting
Het implementeren van SAP HR binnen een van de grootste bedrijven ter wereld is een megaproject, net als de vervolgreleases. Omdat de IT-afdeling van Lukoil nu een zelfstandig bedrijf is hadden zowel de opdrachtgever als de opdrachtnemer behoefte aan een goed begrotingsmodel voor de SAP implementaties.
Voor het bepalen van de omvang is de indicatieve methode van de NESMA gebruikt. Het resultaat is getoetst door een sizing proxy te maken op basis van tellingen van sleutelwoorden in de documentatie. Het resultaat was een goede basis voor het kostenbegrotingsmodel.

Applied Cost Practices for Software Intensive Projects
Rene Berghuijs, NAVO
Het Air Command And Control System (ACCS) van de NAVO moet de tactische planning, begeleiding en uitvoering van luchtoperaties combineren en automatiseren. Dit programma is in 1999 gestart en zal de lidstaten bij volledige implementatie ongeveer 1,5 miljard Euro hebben gekost. Om de verschillende onderdelen van het programma te begroten wordt de Cost Estimating and Assessment Guide van het Government Accountability Office uit de VS gebuikt als best practice. Omdat het programma door één leverancier wordt uitgevoerd is een goed kostenbeheersings en beoordelingsproces cruciaal om de kosten in de hand te houden. NAVO's ACCS Management Agency (NACMA) schat dat hun kostenprogramma de NAVO lidstaten enkele honderden miljoenen Euro heeft bespaard.

Effort Estimation and Risk Management using the CoBRA Approach
Jens Heidrich, Fraunhofer Institute on Experimental Software Engineering
De CoBRA methode is een hybride van de traditionele expertschattingen die gebaseerd zijn op menselijke kennis en data gedreven parametrische modellen zoals SEER, die gebaseerd zijn op ervaringscijfers. Met de CoBRA methode kan een begrotingsmodel op maat worden gemaakt voor een homogene groep projecten, In zekere zin is het vergelijkbaar met de aanpak die Ordina heeft gekozen voor het begroten van Applicatie Management op basis van de knowledge bases van SEER IT. De CoBRA methode kent daarin meer flexibiliteit, omdat ook afhankelijkheden tussen verschillende cost drivers gemodelleerd kunnen worden.

More Successful IT Projects through Estimation, Planning and Control
Dan Galorath, Galorath Incorporated
Dan begon zijn verhaal met de vaststelling dat mensen onverbeterlijke optimisten zijn. Tijdens de NESMA najaarsconferentie heeft Carolyn Mair een presentatie gehouden over de psychologie achter dit optimisme. De presentatie van Dan ging vooral over de oplossing: temper het optimisme door een blik van buiten door gebruik te maken van een parametrisch model op basis van ervaringscijfers. Het klinkt heel simpel en uit eigen ervaring kan ik bevestigen dat het in essentie ook echt zo simpel is. Het implementeren daarvan en dan met name het goed opbouwen van ervaringscijfers is bij veel IT-bedrijven vaak een lastige exercitie. De beloning kan heel groot zijn als je een goed begrotingsproces hebt. Professor Chris Verhoef heeft weleens becijferd dat dat in de tientallen procenten kan lopen.

Using Parametrics in Requests for Proposal
Harold van Heeringen, Sogeti
Bij aanbestedingen kunnen klanten zodanige vragen stellen over prestaties van de leverancier dat ze ruimte overlaten voor interpretatie. Goed gebruik is dat zowel de klant als de leverancier deze ruimte in hun eigen voordeel zullen uitleggen. Het resultaat is veelal een ontevreden klant en een moeizame relatie. Dat zijn allebei ongewenste effecten en kunnen worden voorkomen als de aanbestedingen vragen bevatten die gebaseerd zijn op SMART gedefineerde parametrische formules.
Dat dit soort vragen onderdeel zijn van een breder probleem heb ik recent beschreven in een achtergrondartikel in de Automatisering Gids dat in veel aanbestedingen de echte toegevoegde waarde niet gewaardeerd wordt. Zie ook mijn blogpost van 2 december.

How to Predict the Maintenance Effort for Software
Eric van der Vliet, Logica
Een van de grote verschillen tussen een project en een Applicatie Management contract is dat je in het laatste geval meestal genoeg tijd hebt om binnen het contract een leercurve te kunnen zien. In een goed begrotingsproces moet zo'n leercurve worden meegenomen. Logica heeft ontdekt dat de standaardwaarden van de knowledge bases van SEER SEM meestal goed overeenkwamen met de eindsituatie van een Applicatie Management contract. Zij hebben de belangrijkste parameters bepaald die in de loop van de tijd veranderden en gebruikt konden worden om de leercurve te modelleren.
De manier waarop zij de leercurve, binnen Ordina vaak liefkozend de hockeystick genoemd, hebben gemodelleerd vertoont veel overeenkomsten met de manier waarop wij het onderdeel correctief beheer hebben gemodelleerd in ons Applicatie Management model.

Geen opmerkingen: