Context voor kosten modellen

Auteur Roland Drijver Kosten specialist. Architectuur grenzen door modellen Als iets wel eenvoudig lijkt, maar zelden is, dan is het begrenzing. Of het nu gaat om begrippen in een gesprek of overdraagbare beelden, we denken sneller elkaar te hebben begrepen, dan bij navorsing blijkt. Een definitie van een object, met zijn of haar eigenschappen, lijkt ons meestal afdoende, maar is dat zelden. Een klassieker daarin: wat is een gat? Antwoord: een gat is niets omgeven met iets. Bedoeld of onbedoeld, groot of klein, in allerlei vorm. Door daar een doorsnede aan toe te voegen en wat attributen, in de zin van :het is exact rond, het is axiaal exact in de richting van het vlak geplaatst of het is radiaal in zoveel graden getordeerd ten opzichte van het vlak, de wanden van het gat zijn vlak of glad, met een instulping van x-millimeter in de volgende oriëntatie, kan het lukken het gat te maken of uit te beelden. En soms exact zoals de gene die het definieerde bedoelde. Wat erg behulpzaam kan zijn is het van tevoren bepalen van context modellen. Daarover gaat deze white paper. Als een ICT architect aan tafel gaat met een klant, zal de eerste het gesprek vaak leiden. Klant vertelt eens wat het moet doen aan het einde en voor wie en waarmee en wanneer. Dat vertelt een klant dan. Vervolgens gaat de architect in gesprek met de dragers van de huidige omgevingen waar de klant verandering in wenst. Op zijn reis door de verschillende lagen van het bedrijf komt hij/zij verschillende belangen groepen tegen met verschillende perspectieven op schijnbaar hetzelfde. En erger nog, elk van deze belangen dragers denkt “ de werkelijkheid’ te beschrijven, en wel de pragmatische werkelijkheid. Of het nu gaat om het beschrijven van functionaliteit, de kosten daarvan of het implementeren ervan, er moeten gemeenschappelijke factoren gevonden worden waardoor de verschillenden lagen in het bedrijf, binnen hun eigen context, de attributen kunnen beschrijven van een beschreven staat, de verandering en de eindstaat, in een model dat overdracht naar een andere laag overleeft, zonder het belang van de andere inbrengers te corrumperen, veranderen of teniet te doen. Dat kan maar op een beperkt aantal manieren. In deze white paper zal ik mij beperken tot drie modellen: -context voor kostensoorten -context voor infrastructuren -context voor projecten Deze white paper heeft een tweede doel, ik hoop te bewijzen in de door mij in deze paper uitgewerkte modellen dat het mogelijk is context modellen te gebruiken. Daarnaast hoop ik collega’s uit te lokken op andere etages van ons architectuur huis vergelijkbare modellen te produceren en te publiceren. Context voor kosten modellen: Aanleidingen voor kosten modellen zijn tweeledig, of er wordt een vermindering van uitgaven beoogt, of het inkomen moet stijgen en soms alle twee en ook nog een verhoging van de omzet. Het komt maar zelden voor dat er uit liefhebberij wordt gehandeld, meestal is er wel een knoet in het spel, of een onprettig vooruitzicht voor diverse leden in de kosten biotoop. Waarom is het dan

toch leuk en vaak zelfs uitdagend met kosten en modellen te werken. Antwoord: Het is pas mogelijk elkaar werkelijk te begrijpen als syntax en model waarin de werkelijkheid wordt beschreven gekend is en enigermate omlijnd. Niet zelden in de hedendaagse beroepspraktijk trakteren onderzoekers de opdrachtgever van een kosten onderzoek op veel en onbegrijpelijke soorten van geheimtaal. Het enige dat ter troost kan worden aangevoerd is dat de opstellers het vaak zelf ook niet kunnen uitleggen, hun rapport zegt het nu eenmaal zo. Beroemd zijn de mooie zinnen: “we kunnen uw ROI met twaalf maanden bekorten en dat levert een 20% TCO verbetering op” De klant, volledig gehersenspoeld, niet in staat aan te geven dat hij of zij zich een aap voelt, met in de hand een roestig horloge, doet alsof hij/zij het volledig begrijpt, of schakelt over op de bewuste ontkenning:” Ja, dit is mijn gebied niet, hoewel ik er wel iets van begrijp hoor, maar ik zou het niet kunnen reproduceren’. Nou troost u gerust, dat kan nl. niemand.

We gaan samen die boot bouwen, leuk, ik verheug mij op onze samenwerking

Wow!

Kosten modellen worden en zijn pas begrijpelijk als afgesproken is wat er wordt beschreven, uit wiens invalshoek en voor welke periode. Een beter voorbeeld dat zou kunnen komen uit een goed kosten model: “ we kunnen de operationele kosten van de afdeling Intelbeheer, voor de serverbeheerders van rayon zuid, verlagen met een bedrag van 20 euro per dag, voor een periode van 17 maanden, als we twee servers uitzetten’. Dat klinkt al meer als iets dat je na zou kunnen rekenen, en dat moet kunnen, wil een kostenmodel gelden. Nog beter wordt het als er een koppeling wordt gezocht met de kostenplaats van de klant en zijn eigen balans, en weer een gekende periode wordt beschreven, met duiding van de effecten, waardoor die ontstaan en welke periode. Nog mooier wordt het als er een waarschijnlijkheid in meegenomen wordt en er een herleidbaarheid is naar echte werknemers en echte spullen in een echte omgeving. Voorbeeld: “HP kan de kosten, met inzet van twee mensen gedurende tien dagen,

voor 4000 euro, van kostenplaats 214A van uw budgetjaar 2003, met een bedrag van 20 euro per dag verlagen, zoals uitgewerkt in de rekentabel, door het uitzetten van server IIS2 en IIS 5 , en dit effect zal aanhouden voor de resterende 8 maanden van dit jaar, met een waarschijnlijkheid van 78%, uitgaande van 34 varianten, hetgeen effecten heeft voor werknemer Jan en Krelis en Simon, hun werk zal met 0,4 fte per man afnemen.’ Om zo’n kosten model te starten is het dus verstandig de context te bespreken en in een model vast te leggen.

Direct costs

infrastructure services

Services delivered and cost on logistics doing so

System operation Technology support

Implementation costs

Indirect costs

Cost of end-users

Effects on customers or chain effects we might account for in the model Example: telephone line : provides also usage for data traffic : watchdog services : can even provide inline power

costs of management of data + archiving

Hardware: servers + maintenance - clients + servicesperipheral equipment - network equipment

Software: Application deployment OS distribution Application distribution Drivers and settings Management software Specific tools / toolboxes distributed

cost of obligatory training and cost of time for end-user

Cost of downtime in real financial effects for the end-user

Work: Operations-Planning and process management- database managementservice desk (incident - problem - change costs) + cost of second tier and third tier support

Costs projected into TCO/ ROI/ IRR/ NPV Administration: Financials and administrative costs Training and (local)users training

HP services JK/RD2003

@

Dat wordt door opdrachtgever en opdrachtnemer getekend en in een kluis bewaard. (Althans gezien de conflicten die er vaak op volgen, zou dat wel het verstandigste zijn) Belangrijk ook is het vastleggen van de businesscase van het specifieke ondernemen, die tussen opdrachtnemer en opdrachtgever rollen definieert, verantwoordelijkheden en te leveren producten en in het geval het de kosten effecten betreft, de effecten.

Waar het de geldigheid van zo’n model betreft, het moet herberekenbaar zijn binnen het eigen model, het moet herleidbaar zijn tot aannames en eigenaren van de ingebrachte factoren, die te

toetsen zijn en te valideren tegen een gekend model. Liefst een model dat de accountant met plezier zou ondertekenen. Binnen het model moeten de relaties van effecten en hoe die worden geoogst, helder en ondubbelzinnig beschreven zijn en liefst in grafische vorm worden vastgelegd, inclusief de fasering en de afhankelijkheden en risico’s. Dan ontstaat nu hopelijk een beeld van een geldig kostenmodel. De definitie daarvan luid: een goed kostenmodel (goed is arbitrair maar is in dit voorbeeld gebaseerd op expert opinion): -Geeft kosten weer in soorten -Geeft soorten weer die de klant in zijn/haar eigen context kan traceren -Geeft die soorten weer in parameters die door de klant gekend en her te berekenen zijn of toe te wijzen -Geeft de berekening vorm in een model dat in consensus met de klant gedeeld wordt, wat validiteit aangaat -Laat heldere beschouwing en keuzes toe over de geprojecteerde kosten -Lokt eenduidige besluiten uit -Geeft afdoende context aan afspraken om in afrekening gebruikt te kunnen worden -Spreekt in begrepen termen, in duidelijke definities -Blijft geldig, ook bij projectie in andere delen van dezelfde context -Heeft een zekere universeel toepasbare basis in accountancy regels (termen, begrippen) -Kan over gedragen worden van initiatie van een ondernemen, in uitwerking van te nemen besluiten en acties van het ondernemen, blijft geldig in uitvoering van een ondernemen en laat zich in de afsluiting documenteren en evalueren tegen de in het model beschreven belangen, doelen en kwaliteiten. Op het volgende blad heb ik getracht een grafische weergave van het ideale model te verwerkelijken, het staat echter ieder vrij dat aan te passen aan de syntax en afspraken die gelden in de omgeving waar deze toegepast moet worden. Huiswerk maken, dat is de fundering van een gezond model, en huiswerk blijven maken in de toepassing van dat model.

Een beschrijving van alle te nemen acties en kosten of opbrengsten tijden, na en door het ondernemen; met aanpalende effecten op andere processen, projecten en het verdere ondernemen: zodanig dat er doorzicht wordt geboden in aanleiding, verwachtingen, effecten en keuzes in de voorgaande drie.

Direkte kosten

Software: OS distributie Applicatie distributie Drivers en settingen Management software

Een verbeter actie: een applicatie wordt ingrijpend verbeterd

Door de verbeterde applicatie dalen de kosten voor het zelfbeheer door de eindgebruiker

Indirekte kosten

Kosten van zelfbeheer van data en dossiers

De eingebruiker wil daar meer voor betalen

Vragen die vooraf beantwoord moeten zijn!!!!

Beschreven in een model dat samen met de klant bepaald en uitgewerkt is, waar door beide partijen met ondubblezinnige waarde mee wordt gewerkt.

Gespecifceerd in kosten soorten die de klant kan vertalen: -budget -kostenplaats -Betreffende Fte's op afdeling xxxx -Betreffende de volgende werknemer(s)

Kosten over een gekende periode, in heldere bedragen per eindgebruiker, gebaseerd op locatie of locaties’s, met duidelijke aangave van voor welke functionaliteit die kosten gemaakt worden in het gediende proces Wordt de dienst betaald?En zo ja, door deze eindklant?

Gaat de klant accord met de verbeterde dienst? Is deze bereid er meer voor te betalen

Wordt op bovenstaande vragen met ja geantwoord, dan is er een businesscase, zonder business is er namelijk ten hoogste een kwaliteit case. In dit voor beeld is de relatie ook helder te leggen. En zijn effecten te berekenen.

Om dit model helemaal af te maken voege men er de kosten voor kapitaal en belasting effecten aan toe, en een zeer werkbaar, maar vooral herberekenbaar en herleidbaar model, voor de meetbare kosten effecten in het bedrijf waar dit model voor geldt. Kosten van kapitaal zijn meestal samengesteld uit: -de rente aan de geldschieter -de risico opslag op het project of ondernemen -de verplichte marge voor de ondernemer (eis van aandeelhouders of bezitters) Het eerste deel, de rente zal in de huidige markt rond de 4% moeten uitkomen, de tweede is in een goed uitgewerkt plan 5-8% en de laatste, de marge voor de ondernemer is vaak 20-30%. Dat levert een totaalsom op van 12% directe kapitaal kosten en 20-30% resultaat kosten, vaak uitgedrukt als te realiseren marge. Dat de laatste in de huidige markt onder druk staat zal geen van ons verbazen. Het is echter wel prettig een opdrachtgever te vinden die dit soort kosten (kosten voor kapitaal) helder stelt, het maakt het leven voor de architect en projectmanager duidelijker en geeft een heldere resultaatplicht weer, die de ondergrens ( het minimale resultaat van het ondernemen) van een ROI zou moeten zijn. De belasting effecten zijn goed gedefinieerd door de bevoegde instanties en zijn bij juiste interpretatie zodanig toe te passen, ook hier is een deskundig advies nooit te versmaden, maar dient u als ondernemer of architect wel zelf te kiezen, als er gekozen kan worden. Sluit ik af met wat bemoedigende woorden, er is altijd deskundigheid in de markt te vinden die u graag en veelvoudig zal assisteren met het ontwikkelen en uitwerken van kosten modellen. Daar staat tegenover dat het in uw belang is dat u de keuzes maakt in de kostenmodellen, omdat ze de geldigheid bepalen van uw architectuur in zijn/haar uitwerking naar kosteneffecten. Daarnaast moet u er steeds bewust van zijn dat een model altijd twee hoofd exercities kent, toewijzing en berekening. Dit mechanisme, de twee hoofdexercities ligt ik u toe in een model en een bijbehorend verhaaltje. Met als doel dat u dat ook gaat toepassen in uw kostenmodellen.

Het plezierige plaatje dat u hier ziet is een operatie kamer, waar druk gewerkt wordt aan een succesvolle vervanging van een versleten heup.

De heup kost 20k euro en het personeel en de operatie kamer 30k euro, de instrumenten kosten nog een keer 20k euro. Na de operatie stuurt het ziekenhuis een rekening van 80k euro naar de verzekeraar en deze betaalt per omgaande. Als oefening stappen wij nu dit model in en gaan op zoek naar de kosten factoren. Zoals op de foto al te zien was, er werken vijf mensen in de ruimte en van mij hoort u nu dat er ook een anesthesist aanwezig was, maar die is even koffie drinken en er zijn twee omloopmedewerkers aanwezig, maar die mochten niet op de foto. Van de vijf zijn er twee verpleegkundigen, is er één een co-assistent chirurg in opleiding en is er één vaatchirurg, en er staat een orthopedisch chirurg bij. Tezamen hebben ze lekker omgezet en ook nog 10K euro bruto winst geproduceerd. Onze opdracht is vrij simpel, vaststellen wie of wat die 10K euro heeft geproduceerd in dit proces. Daarbij gaan we uit van het gegeven dat de winst een besluit is van de betrokkenen in de operatie kamer en niet van een administrateur. We stappen de operatie kamer binnen en stellen een heldere vraag: kan het team uitleg geven over de kosten en de berekende winst. De orthopeed stapt naar voren en zegt:” Dat ligt voor de hand, de kosten zijn niet afwijkend van de herleidbare kosten voor lonen en spullen en die 10k euro winst heb ik geproduceerd, lang studeren,u begrijpt het wel, daar hangt een prijskaartje aan’. De verpleegkundigen en de vaatchirurg kleuren spontaan bij en spreken: “ Ja daar heeft de gewaardeerde collega zeker gelijk in, maar een flink deel daarvan komt door ons, wij hebben nl. ook erg lang gestudeerd en zijn als team onnavolgbaar, dus wij zijn zeker goed voor de helft’. Dan komt gelukkig net de instrumentalist langs en spreekt: “ Dat hoorde ik toch maar mooi, u moet weten mijn instrumenten, tja zonder is er niet veel te opereren, en het scalpel, inkoop 0,60 eurocent, maar hij (de chirurg orthopeed) heeft hem wel twee uur beet gehad, daar claim ik 200 euro voor en voor de overige instrumenten toch ook wel, ik zou zeggen totaal 300 euro’. U heeft een mooi klassiek dilemma in handen, en de patiënt die nu ontwaakt, maakt het ook niet makkelijker, zij mompelt nog wat onvast: “Tzit in me heup, alle euro’s, dat kan ik goed voelen, en ik kan het weten, me heup’. Kunt u dit dilemma breken met berekening? Nee, natuurlijk niet, eerst leidt u de deelnemers naar consensus over wie welk deel van de waarde heeft geleverd in dit proces, en dan wijst u als architect alle nog toe te wijzen factoren toe en laat ze uitgebreid zien aan de deelnemers. Als ze allemaal knikken en ja, ja en dergelijke gaan zeggen, bent u klaar, dan heeft u een proces in een kostenmodel gebracht. Voor een kosten model gelden dus als uitgangspunten en uiteindelijk in de modellering: eerst toewijzen, graag samen met de betrokkenen, en dan rekenen. Anders krijgt u nooit die mooie overeenstemming, waar ons aller architecten hart zoveel sneller gaat kloppen.

Context voor infrastructuren: Net als de context voor kostensoorten, heeft het gebied van context voor infrastructuur beschrijving in al zijn/haar vormen, of het nu om schets, architectuur, blauwdruk of bestek gaat een meervoudig doel, het eerste is de behoefte het beschreven veld en de functionele gebieden ondubbelzinnig vast te leggen. Het tweede is de biotoop van de infrastructuur helder te begrenzen. De derde is de wens tot een te delen syntax en beeldtaal te komen voor infrastructuur. Net als met

de context voor kostensoorten is het uitgangspunt dat een goed model de weg van visie – missie tot beleid, opdracht en uitwerking behoort te overleven. Dan speelt er in dit deel van de beschrijvende context nog een extra factor, de beeldtaal en syntax van de standaarden waar de architect zich naar buigt. Voorbeeld is de taal van b.v. MicroSoft in de Windows omgevingen, met specifieke betekenissen aan woorden als domein(domain) of bos (forest), of een operationeel model als Tivoli, waar we plots capitols en andere begrippen ontmoeten, met een geheel eigen syntax. Als er al naar een dergelijke standaard wordt gebogen, is het niet onverstandig de standaard syntax van die keuze onverbloemd over te nemen. Het werkt zeker niet als de architect een eigen beeldtaal of syntax wil behouden. Het is niet per sé onwaar als we een domain controller beschrijven als een hoofd verkeer regelaar in de rol van verkeersleiding en toewijzen van rollen en bevoegdheden en deze bijvoorbeeld de hoofdtoren zouden noemen, het is echter wel zo, dat het de overdrachtelijkheid van de beschrijving lastiger maakt. Net als bij de context voor kosten soorten wil de architect een model dat een uitwerking van een visie kan bevatten, maar net zo makkelijk een derivaat in een missie statement. Het moet zijn geldigheid behouden als het wordt gebruikt in de beleidsuitwerking van de missie. En als er dan functionele beschrijvingen, de technologie beschrijving daarna of de projectplannen en uiteindelijk het bestek wordt beschreven, moet in elk van deze derivaten een zelfde context model gebruikt kunnen worden en moet dat model een consistent en geldig beeld behouden. Alvorens een voorbeeld te laten zien, neem ik u als lezer eerst uitgebreid mee door de diepere eisen aan een geldig model. Het model voor infrastructuur moet een set eigenschappen toelaten: -u moet er eigenschappen in kunnen beschrijven -de eigenschappen moeten in het model tot de juiste uitwerking gedwongen worden door het model, waardoor veel mensen er mee kunnen werken en dezen moeten door het dwingende karakter niet om de werkwijze in het model heen kunnen en daardoor tot dezelfde beschrijvingen komen. -een context model moet overdraagbaar zijn, door zijn/haar logische inhoud,met een minimum aan begeleidende instructie. -een context model moet significant bijdragen aan de architectuur modellen, en dus de kwaliteit van een uitgekiende ruggengraat vertonen. Twijfel bestaat over de toegankelijkheid van academische modellen voor de leek en of het wel redelijk is een toegankelijkheid voor niet ingewijden als eis te stellen. Een bijzonder collega van mij stelde ooit: “ Als een context model niet ondubbelzinnig beschrijft wat het doet, is de vraag niet of het mis kan gaan in de beschrijving, alleen wanneer’. En dat zou wel eens geldig kunnen zijn. Ondubbelzinnig, uitgelegd als ‘ niet in geheimtaal of taal door slechts weinigen te verstaan”, zou wel eens kunnen impliceren dat een context model toch altijd, een zeker, door velen makkelijk te begrijpen model moet opleveren. Dan komt een belangrijke hoofdeigenschap, als een infrastructuur context model een verdeling maakt in onderdelen van de context, kan een onderdeel van de infrastructuur nooit in meerdere delen van de context tegelijk bestaan, anders is het geen infrastructuur, maar meer een dienst of principe van de infrastructuur.

Sourcing

Training

Context model: Eigenschappen van de ICT omgeving in een vaste context 17 - okt - 2003

Contracting

Operation

Procedures

Helpdesk

Support

Location Netwerktopology Domain topology Networkingservices Security Operationalmodel Hardware Software

Geprojecteerd volgens (eind)gebruikers perspectief

Business Logic Sales

Projects

Sales Logistics

Market changes

Fab

Enginering

GAP

Reference Architecture: Where we are in 3 Years Visie: invulling: Onderbouwd met een geldige businesscase: investerings beleid

Office

Straight forward development

Het op de vorige pagina afgebeelde model is een op de Windows 2000 verdeling van infrastructuur gebaseerde context modellering. Daarin kan een factor maar in een veld van de context tegelijk voorkomen. Als een factor in één of meer velden geplaatst wordt, is de afspraak dat effect op alle velden uitgewerkt moet worden. Door zo te werken, dwingt het model de uitwerker consequent steeds dezelfde aspecten van het beschrevene te illustreren. Het model beschrijft, indien ijverig, toegepast de effecten van alle ingebrachte elementen op alle overigen en geeft zo ondubbelzinnig inzicht in alle effecten en gevolgen van het inbrengen van het element. Men stelle zich daarbij zaken voor als: -Kosten effecten in de verschillende deelfacetten van onze omgeving -Aan te passen documentatie -Effecten op procedures -Registratie van keten effecten -Risico bepaling -Effecten op inzet van mensen en invloed op taken - Te nemen hindernissen voor implementatie, c.q. integratie Pas als alle velden zijn geactiveerd en in of uitgesloten is welk effect er mag worden verwacht per aspect, is de validatie tegen de aspecten klaar. Het wordt u nu al ras duidelijk, er is in dit veld dringende behoefte aan automatisering, er wordt nog al wat huiswerk verlangd van de invuller. Troost is er ook, is de omgeving eenmaal in kaart gebracht, dan is het bijwerken van nieuwe gegevens een lichte taak geworden. Misschien hier een korte beschouwing over het fenomeen procedures, hoewel ik geen sluitende definitie heb kunnen vinden stel ik voor deze als volgt te omschrijven: -“Een procedure is een set regels,die een duidelijke belanghebbende een duidelijk omschreven resultaat van een handelen of reeks handelingen levert, in een voorgeschreven volgorde en op een voorgeschreven wijze, met een voorspelbaar resultaat. Door het karakter van de gewenste sturing in de procedure dient zij tevens regulerend te zijn en waar nodig kwalitatief en kwantitatief te sturen en in het gewenste resultaat, afrekenend, of op zijn minst,meetbaar te zijn.’ Het mag gezien het voorgaande duidelijk zijn dat rond het beschrijven van eigenschappen van een element van onze automatisering omgeving, procedures een verplicht onderdeel zijn. Het doel is uiteindelijk beter te kunnen sturen op wat “het” zou moeten doen aan het einde. In dit deel van de werkelijkheid houdt gokken niet stand, en doet men verstandig deze omgeving te managen van uit inzicht en kennis. De complexiteit van een datacenter dwingt een rigide vorm van blauwdruk denken af als de manager een voorspelbaar resultaat wil behalen. Rest mij u uitgeleide te doen uit dit hoofdstuk. Zijn er andere modellen mogelijk? Absoluut, het betoog hierboven is niet bedoeld om een stramien op te leggen, het faciliteert u mogelijk om een structurerend element in uw toelating beleid te brengen voor apparatuur, processen en applicaties. Pas als u enige standaardisatie bereikt in uw beoordeling systeem voor nieuwe zaken, worden keuze en alternatieven voor functionaliteit vergelijkbaar en worden uw business case en architectuur herleidbaar in een context die beschouwing van waardebijdrage redelijk objectief maakt.

Het in dit hoofdstukje opgenomen model sluit wel geheel aan op de wereld van Windows 2000 en de syntax van de inrichting verhalen en de beeldtaal van de beschrijvingen van de MCSE trainingen van MicroSoft. Als u een context model vervaardigd is het adviseerbaar de beeldtaal en factoren in overeenstemming te brengen met de standaard omgeving waar u leefbaarheid van nieuwe zaken ten opzichte van die omgeving wilt toetsen in het context model. Een Sun Solaris model zou dus in andere termen moeten spreken, een Unix omgeving weer in andere termen. Komt u er niet uit, geen nood, er zijn voldoende experts om u te dienen. Wel even checken of het de eerste keer is dat de expert een model ontwerpt, dan moest u er maar voor laten betalen, in plaats van zelf te betalen.

Context modellen voor projecten: We hebben eigenlijk het laatste decennium van de vorige eeuw gevierd met een uitbarsting van mislukkende of misleidende of combinaties van beide in projectvorm ondernemingen. We zijn er als industrie zelfs in geslaagd een adagium te creëren dat ongeveer zo luidt: Projecten : -de vraag is niet of ze mis gaan, alleen wanneer -bij het uiten van het woord risico analyse kijkt de klant als een aap naar een roestig horloge -projecten zijn synoniem aan scope creap -projecten kosten altijd het dubbele -projectmanagers zijn optimisten die geloven in het kunnen voorspellen van een proces, terwijl een proces sturen al haast onmogelijk lijkt -alleen heel flegmatieke mensen moeten projecten afnemen, bij de overigen leidt het minimaal tot hartklachten en vaak tot vormen van zelfdoding of moord U begrijpt, er is nog al wat aan te merken op projecten, zoals meestal uitgevoerd door jonge ambitieuze veeldoeners in de rol van projectmanager. Zonder overdrijven kan worden gesteld, de projectmanager is meestal een speelbal van een veeleisende opdrachtgever en onmogelijke tijden en opdrachten waar hij/zij van gezegd heeft dat het voorspelde uit zou kunnen komen. En daar houdt de opdrachtgever hem/haar graag aan. Daarnaast is gezien de hekel die wij allemaal hebben aan de projectmanager de kans vrij gering dat deze enig mededogen mag verwachten, als datgene hij/zij heeft aangenomen niet haalbaar blijkt te zijn. De meeste paden naar wat langere termijn ondernemingen zijn bezaaid met geëxecuteerde projectmanagers. Had dit voorkomen kunnen worden? Die laatste vraag is natuurlijk retorisch, het had voorkomen kunnen worden, en daar zullen de volgende context modellen u in gaan helpen. Model 1 : belangen Modellen set 2 : methode De modellen die hierna zullen volgen, zullen als u ze volgens het geprojecteerde model toepast, uw succes in het aannemen en uitwerken van projecten, maar u ook in de rol van klant heel veel succesvoller maken dan zonder.

Het spreekt voor zich dat een niet professionele klant al snel onheil mag verwachten in zijn/haar rol als opdrachtgever. Opdrachtgever is nl. een vak. Dat kunt u ook in de praktijk leren, maar zoals de ouderen onder u weten, ervaring is de beste leerschool, maar tevens de duurste. Model 1: belangen:

Het plaatje stelt een project voor dat in de tijd van A naar Z beweegt, met een hoogste en laagste kwaliteit in de te behalen doelen en tussen doelen, wel “mile stones” genoemd. Dat sturen van A naar Z gaat meestal wel, met meer of minder succes. Op de lijn blijven lukt niet altijd, maar met veel ruzie en escalaties komt men uiteindelijk wel aan in Z. Het plaatje draait natuurlijk om de belangen, in dit voorbeeld zijn dat er maar vijf. Dat kunnen politieke bedoelingen zijn van een partij in het bedrijf waar de projectmanager aan het werk is, of een machtige persoon of groep met een eigen doel. De kunst bestaat uit het beschrijven van de te dienen belangen en op welke wijze deze een invloed gaan uitoefenen op het project. Alleen de opdrachtgever denkt belang te hebben bij Z, de overigen, zoals nu in het voorbeeld aangegeven opereren wel ergens langs die lijn, maar alleen belang 5 is een tijdje in hetzelfde spoor als ons project, de overigen hebben andere belangen. Een mooi voorbeeld, uit de grimmige praktijk: Manager X krijgt de opdracht om twee mensen van hoge expertise beschikbaar te stellen voor ons project, dat doet X voorbeeldig in de eerste weken. De projectmanager gaat er bijna in geloven, het gaat lekker. Dan komt het einde van het kwartaal in zicht en manager X moet een bepaalde omzet per kwartaal behalen, dat doet hij niet met ons project, dat doet hij bij eindklanten.

Wij weten dat het project zijn omzet over twee jaar flink gaat verhogen, misschien wel verdubbelen, maar helaas voor ons, manager wordt afgerekend per kwartaal. En hij komt nog flink te kort. Maar als hij die twee experts nog een paar weken, tot het einde van het kwartaal, kan wegzetten tegen een mooi tarief, haalt hij het. U raadt het al, er is zo’n opdracht. Hij kan de mensen kwijt. Wat doet X? En wat wint er in dit krachten veld, het belang van X of ons project? Uw antwoord zou “mandaat” kunnen zijn, maar neemt u maar aan, het begrijpen van de belangen van partijen die we onderweg tegenkomen helpt u veel meer en daarbij dan de juiste bevoegdheden en middelen. Komen we aan modellen set 2: Een beetje uitgebreider en flink wat ingewikkelder, we gaan nu echt de methode in.

Het bovenstaande plaatje geeft in eenvoudige termen de fases van een project weer en het gewicht in het geheel van de exercitie. Natuurlijk wordt hier geen natuurkundige werkelijkheid weergegeven, het is maar een aannemelijke projectie. Het geeft wel structuur aan de hoofdverdeling van de context.

Modellen set 2: details initiatie: 6.1 Project Time Man.

Activity Definition .1 Inputs .1

Work breakdown… structure…

.2

Scope statement…

.3 Historical information .4 Constraints .5 Assumptions .2 Tools and Techniques

5.1 Project Scope Man.

Initiation .1 Inputs .1 .2 .3 .4

Product description Strategic plan Project selection methods Historical information

.2 Tools and Techniques .1 Project selection methods .2 Expert judgment .3 Outputs .1

Project charter


Scope Planning .1 Inputs .1 Product description .2

Project charter

.3 Constraints .4 Assumptions .2 Tools and Techniques .1 Product analysis .2 Benefit/cost analysis .3 Alternatives identification .4 Expert judgment

.1 Decomposition .2 Templates


Scope Definition

.3 Outputs .1 Activity list .2 Supporting detail

.1 Inputs .1

Scope statement .

.3

.2 Constraints .3 Assumptions .4 Other planning outputs .5 Historical information .2 Tools and Techniques

7.1 Project Cost Management

.1 Work breakdown structure templates .2 Decomposition

Resource Planning .1 Inputs

.3 Outputs .2 Project manager .3 Constraints .4 Assumptions

Workbreak down … structure updates…

.3 Outputs .1 .1

Scope statement .

.1 Work breakdown..

Work breakdown. . structure….

structure.. .2 Historical information

.2 Supporting detail .3 Scope management plan

.3 Scope statement.. .4 Resource pool description .5 Organizational policies .2 Tools and Techniques .1 Expert judgment .2 Alternatives identification .3 Outputs .1 Resource requirements

8.1 Project Quality Man.

Quality Planning .1 Inputs .1 Quality policy .2 Scope statement.. .3 Product description .4 Standards and regulations .5 Other process output

10.1 Communication Man.

Communication Planning .1 Inputs .1 Communications requirements .2 Communication technology .3 Constraints .4 Assumptions

Risk Quantification

.1 Inputs

.1 Inputs

.1 Product disciption .2 Other planning outputs .3 Historical information

.1 .2 .3 .4 .5

.1 Checklist .2 Flowcharting .3 Interviewing

.2 Tools and Techniques .1 .2 .3 .4 .5

.3 Outputs .3 Outputs .1 Communications management plan

.3 Outputs

.1 .2 .3 .4

Sources of risk Potential risk events Risk symptoms Inputs to other processes

Organizational Planning .1 Inputs .1 Project interface .2 Staffing requirements .3 Costraints .2 Tools and Techniques .1 .2 .3 .4

Templates Human resource practices Organizational theory Stakeholder analysis

.1 Oppertunities to pursue, threats to respond to .2 Oppertunities to ignore, threats to accept

9.2 Human Resource Man.

12.1 Proj. Procurement Man.

Staff Acquisition

Procurement Planning

.1 Inputs .1 Staffing management plan .2 Staffing pool description .3 Recruitment practices .2 Tools and Techniques .1 Negotiations .2 Pre-assignments .3 Procurements

.1 Inputs .1

Scope statement..

.2 .3 .4 .5 .6 .7

Product description Procurement reaources Market conditions Other planning outputs Constraints Assumptions

.2 Tools and Techniques

.3 Outputs .3 Outputs .1 Role and responsibility assignments .2 Staffing management plan .3 Organization chart .4 Supporting detail

Expected monetary value Statistical sums Simulation Decision trees Expert judgment

.3 Outputs

.1 Quality management plan .2 Operational definitions .3 Checklist .4 Input to other processes


Stakeholders risk tolerances Sources of risk Potential risk events Cost estimates Activity duration estimates

.2 Tools and Techniques .1 Stakeholder analysis

Benefit / Cost analysis Benchmarking Flowcharting Design of experiments

11.2 Project Risk Man.

Risk Identification

.2 Tools and Techniques

.2 Tools and Techniques .1 .2 .3 .4


.1 Project staff assigned .2 Projectteam directory

.1 Make-or-buy analysis .2 Expert judgment .3 Contract type selection .3 Outputs .1 Procurement management plan .2 Statement(s) of work


Solicitation Planning .1 Inputs .1 Procurement management plan .2 Statement(s) of work .3 Other planning outputs .2 Tools and Techniques .1 Standard forms .2 Expert judgment .3 Outputs .1 Procurement documents .2 Evaluation criteria .3 Statement of work updates

Als u de initiatie fase ziet als een degelijk verblijf in de studeerkamer, dan zou de bovengeschetste context kunnen gebruiken om uw activiteiten goed in context te plaatsen. Zet de text op 200% en u kunt het model weer goed lezen. Ook voor dit model geldt dat het maar een voorbeeld is. Voorbeeld modellen 2 : planning 6.2 Project Time Man.

Activity Sequencing .1 Inputs .1 Activity list .2 Product description .3 Mandatory dependencies .4 Discretionary dependencies .5 External dependencies .6 Constraints .7 Assumptions

6.4 Project Time Man.

Schedule Development .1 Inputs .1 .2 .3 .4 .5 .6 .7 .8

Project network diagram Activity duration estimates Resource requirements Resource pool description Calendars Constraints Assumptions Leads and lags

.2 Tools and Techniques .2 Tools and Techniques .1 Precedence diagramming methods (PDM) .2 Arrow diagramming methods (ADM) .3 Conditional diagramming methods .3 Outputs .1 Project network diagram .2 Activity list updates

.1 .2 .3 .4 .5

Mathematical analysis Duration compression Simulation Resource leveling heuristics Project management software


Cost Budgeting .1 Inputs .1 Cost estimates .2 Work breakdown…

structure… .3 Project schedule .2 Tools and Techniques .1 Cost estimating tools and techniques .3 Outputs .1 Cost baseline

.3 Outputs .1 .2 .3 .4

Project schedule Supporting detail Schedule management plan Resource requirement updates

6.3 Project Time Man.

Act. Duration Estimates .1 Inputs .1 .2 .3 .4 .5 .6

Activity list Constraints Assumptions Resource requirements Resource capabilities Historical informations

.2 Tools and Techniques .1 Expert judgment .2 Analogous estimates .3 Simulations .3 Outputs .1

Activity duration.. estimates..

.2 Basis estimates .3 Activity list updates


Cost Estimating .1 Inputs .1 Work breakdown..

structure.. .2 Resource pool description .3 Resource rates .4 Activity duration..

estimates.. .5 Historical information .6 Chart of accounts .2 Tools and Techniques .1 .2 .3 .4

Analogous estimating Parametric modeling Bottum-up estimates Computerized tools

.3 Outputs .1 Cost estimates .2 Supporting detail .3 Cost management plan



Risk Response Development

Information Distribution

.1 Inputs

.1 Inputs

.1 Oppertunities to pursue, threats to respond to .2 Oppertunities to ignore, threats to accept .2 Tools and Techniques

.3 Outputs

.1 Project staff

.3 Project plan..

.3 Staffing management plan .4 Performance reports .5 External feedback

.1 Communications skills .2 Information retrieval system .3 Information distribution systems .3 Outputs

.1 .2 .3 .4 .5

Risk management plan Input to other processes Cintingency plans Reserves Contractual agreements

Team Development .1 Inputs

.1 Work result .2 Communications management plan

.2 Tools and Techniques .1 Procurement .2 Contingency planning .3 Alternative strategies .4 Insurance


.1 Project records

.2 Project plan..

.2 Tools and Techniques .1 Team-building activities .2 General management skills .3 Reward and recognition systems .4 Collocation .5 Training .3 Outputs .1 Performance improvements .2 Input to performance


Solicitation .1 Inputs .1 Procurement documents .2 Qualified seller list


Source Selection .1 Inputs .1 Proposals .2 Evaluation criteria .3 Organizational policies

.2 Tools and Techniques .2 Tools and Techniques .1 Bidder conference .2 Advertising .3 Outputs

.1 .2 .3 .4

Contract negotiation Weighting system Screening system Independent estimates

.1 Proposals .3 Outputs .1 Contract

Voorbeeld modellen 2 : executie 4.1 Proj. Integration Man.

Proj. Plan development .1 Inputs .1 .2 .3 .4 .5

Other planning output Historical information Organizational policies Constrains Assumptions

.2 Tools and Techniques .1 Project planning methodology .2 Stakeholder skills and knowledge .3 Project management information system (PMIS) .3 Outputs .1 Project plan… .2 Supporting detail

4.2 Proj. Integration Man.

Proj. Plan Execution .1 Inputs


Performance Reporting .1 Inputs

.1 Project plan…

.1 Project plan..

.2 Supporting detail .3 Organizational policies

.2 Work results .3 Other project records

.4 Corrective action… .2 Tools and Techniques .1 .2 .3 .4 .5

General management skills Product skills and knowledge Work authorization system Status review meetings Project management information system (PMIS) .6 Organizational procedures

.2 Tools and Techniques .1 .2 .3 .4 .5

Performance reviews Variances analysis Tren analysis Earned value analysis Information distribution tools and techniques

.3 Outputs .1 Performance reports..

.3 Outputs .1 Work results

.2 Change requests..

.2 Change requests…

4.3 Proj. Integration Man.

Overall Change Control .1 Inputs .1 Project plan… .2 Performance reports .3 Change requests… .2 Tools and Techniques .1 Change control system .2 Configuration management .3 Performance…

measurements .4 Additional planning .5 Project management information system (PMIS) .3 Outputs .1 Project plan updates… .2 Lessons learned

Voorbeeld modellen 2 : close out

Controlling Processes


Contract Close-out .1 Inputs .1 Contract documents .2 Tools and Techniques .1 Procurement audits .3 Outputs .1 Contract file .2

Formal acceptance.. and Closure..


Administrative Closure .1 Inputs .1 Performance measurements documentation .2 Documentation of the product of the project .3 Other project records .2 Tools and Techniques .1 Performance reporting tools and techniques

.3 Outputs .1 Project archives .2 Formal acceptance... .3 Lessons learned

Voor de lezer die nu besluit dat dit overbekende zaken zijn, laat zien dat u het heeft toegepast en ik vergeef u onmiddellijk uw onbeleefdheid. Kom ik tot een afronding. Beschreven in deze paper zijn drie modellen: -context voor kosten -context voor functionaliteit -context voor projecten Nu zou ik kunnen afronden met de aansporing: doe er uw voordeel mee, maar dat zou wel erg makkelijk zijn. Mijn pleidooi voor modellen, gaat niet uit van de modellen zelf, maar het streven naar herleidbaarheid van besluiten dat er door afgedwongen wordt. Verbeeld u een paleis als Versailles (bij Parijs) en alle weelderigheid die er uit spreekt, maar belangrijker, de rigide principes die er in verwerkt zijn.

In de huidige werkelijkheid, ons eigentijds beeld is iets als de “gulden snede” een abstractie. De bouwers van dat paleis hadden weinig “sterke “ materialen, er moesten vrij veel principes worden gevolgd, de Romeinse boog, de regels voor maximale maten van geslingerd glas, de wetten van de toenmalige klimaatsbeheersing. Het waren veel huiswerk oefeningen. In deze tijd van snelheid, instant, klaar terwijl u wacht, is het extensieve huiswerk dat architectuur heet in onmin geraakt. “Ik wil het nu, en snel, en goedkoop en ik wil geen maatwerk, ik wil het van de plank” Dat kan alleen als er absoluut standaard wordt ontworpen en zelfs dan is het gebruikelijk dat in de meest nederige woning, de uitvoerder toetst welke tegels de toekomstige bewoner wenst, de kleurstelling van het schilderwerk etc. Een automatisering omgeving, dient vaak veel belangen, veel werkelijkheden, dient veel en verscheidene functionaliteit in te vullen, is onderhavig aan ijzeren wetten: -maximale afstanden, leefbaarheid van protocollen, kosten en baten verwachtingen. Daar is niets eenvoudig aan. Als we de opdrachtgever voor het ontwerpen van functionaliteit niet helpen modellen te leren gebruiken die herleidbaarheid van complexe keuzes naar context toestaan, groeien we door de complexiteit van wat we proberen te combineren over de menselijke maat heen, een mens kan maar een bepaalde horizon zien, en maar een beperkt aantal factoren. Nogmaals, doe uw voordeel met de voorbeelden uit deze white paper. “ De weg is lang en het einde is nog lang niet in zicht” Modellen kunnen u helpen die weg te beschrijven en consistent te houden. RD

Context voor kosten modellen

Recommend Documents