Wat  een ander probleem vormde is het feit dat het team uit enorm verschillende functies en achtergronden komt. Namelijk zowel beheer, ontwikkeling en test, maar dus ook uit verschillende technologieën. Java, .Net en het financiële pakket. Dat betekent dat niet iedereen zomaar alles van elkaar over kan nemen. Sterker nog: het is een bak kikkers die alle kanten eruit springen als je niet uitkijkt.

Dan hebben we de start. We gaan gewoon beginnen!

Geen PID, Project Brief, geen governance die al dan niet bepaalt of we verder mogen. Allemaal weten we dat we in onze ontwikkelstraten veel beter, sneller en beheerster kunnen gaan bouwen. Maar dan moeten de straten wel beter opereren. We moeten alles wel veel beter beheersen dan we ooit gedaan hebben. Wat er fout is geweest?

Veel te veel handmatig; Aan de start van een nieuwe omgeving gaat alles nog wel redelijk synchroon over de verschillende omgevingen. Maar na een paar maanden zijn er (door omstandigheden zullen we maar zeggen) veel verschillen tussen bijvoorbeeld een T-omgeving en een A-omgeving. Wijzigingen die niet consequent doorgevoerd worden, configuraties die “even” aangepast worden omdat een test team even vast zit of teveel autorisaties voor teveel mensen. Letterlijk meegemaakt dat er een script geschreven werd om op een bepaalde omgeving het loglevel weer terug te zetten naar 1, aangezien er altijd wel iemand het loglevel op 5 zette.

Te foutgevoelig; Aan het einde van het programma, doorlooptijd van 2,5 jaar, hadden we het deployen van nieuwe versies over de OTAP-straat niet op orde. Bij de eerste tests bleken twee gebruikers verschillende tabbladen te zien toen ze hun testen startten op de acceptatie omgeving. Dat betekent dat je na 2,5 jaar nog steeds niet geleerd hebt van je werkzaamheden.

Te weinig een generieke aanpak; De technieken kunnen danig van elkaar verschillen. Een pakket is duidelijk iets anders dan zelfbouw. Maar ook de .Net en de Java straat waren danig verschillend. Niet alleen in tools, dat kan omdat een technologie nu eenmaal specifieks ondersteund wordt door een leverancier, maar ook in testsoorten of aanpak of methode. Dat is wel vreemd. Waarom gaat alles niet door dezelfde status kwaliteitscontrole? Waarin is Java daar anders dan .NET?

Gebrek aan metrics; In feite is dit geen ongewenste situatie. Een gebrek aan kennis is nooit een reden om te denken dat iets niet goed gaat. Ik weet zoveel dingen niet, maar dat is geen reden om me ongerust te maken. Echter in dit geval is er geen kennis van bijvoorbeeld de doorlooptijd van een change. Of het feit dat een change sneller opgepakt wordt met .Net dan met Java. Of hoeveel bevindingen er in een Systeem Test omgeving gevonden worden. Etc. Etc.

Het moest beter en het kan beter. Met dat gevoel creëer je een team. Alles wat we doen is een verbetering en is per definitie goed. Het schept een band.

De definities die ik wil hanteren zijn te doorgronden door verschillende brillen of doorsnedes te hanteren. De eerste heeft te maken met de technologische stack en ziet er zo uit:

Een verticale doorsnede (stack) van de geleverde services geeft de diverse soorten functionaliteit weer die onderdeel zijn van een ontwikkelstraat. Van beneden naar boven betreft dit:

1. Hardware, Server OS (en DBMS); Dit betreft de fysieke servers en/of PC’s die direct aangestuurd worden door een Operating System. Bij mijn klant betreft dit Windows en Linux servers. Indien een database hierop geïnstalleerd is volgt er geen bovenliggende stack, maar betreft het een database server.
2. VM; dit betreft een virtuele instantie van een server. Het is mogelijk om een cluster aan virtuele servers te draaien op 1 fysieke server.
3. Server OS (en DBMS); Dit betreft het operating system bij de VM-instantie, al dan niet geïnstalleerd met een database.
4. Middleware; Dit betreft alle software die noodzakelijk is als tussenlaag tussen de applicatie en een database en/of Operating System. Voorbeelden zijn applicatie servers als Websphere, Weblogic of IIS, maar ook MQseries, een service bus of een webservice.
5. Software; In het geval van een pakket installatie is dit de standaard (plain vanilla) installatie van de desbetreffende applicatie. Het betreft ook de configuratie van dit pakket (en de latere beheer activiteiten als patching & upgrading van dit pakket).
6. Het maatwerk; de daadwerkelijk gebouwde toegevoegde functionaliteit (van een pakket). De reden waarom deze nog een gedeelte paars heeft komt omdat beheer verantwoordelijk is voor het plaatsen van deze functionaliteit. Ontwikkeling is uiteraard voor de bouw van deze fucntionaliteit.

En dan nu het simplificeren van de zaken: de eerste 5 zijn allemaal een onderdeel van provisioning en de laatste worden gezien als deployments. Hierbij is de laatste een verantwoordelijkheid van de desbetreffende ontwikkelteam. Dat kan een scrum team zijn, een change in een lijnteam of een waterval project. Hierbij assisteert beheer in het plaatsen van de software, het eventueel controleren van de software sources en het daadwerkelijk operationeel beheren van de software (bijvoorbeeld door het draaien van batches).

De eerste vijf zijn sinds kort de verantwoordelijkheid van mijn System Team.

1. Er wordt maatwerk gemaakt.
2. Er wordt gebruik gemaakt van een eigen ontwikkeltaal.
3. Er is een logistiek proces waarin nieuwe functionaliteiten gemaakt worden en uiteindelijk in gebruik genomen worden.

Vervolgens krijg je een veelvoud aan smaken, talen, processen, raamwerken en methodes. Bijvoorbeeld dat men gebruik maakt van verschillende versies in zo’n proces of dat er verschillende stadia zijn waarin de functionaliteit zich bevindt of dat er een veelvoud van platformen bestaan waarop mijn van deze functionaliteit gebruik maakt. Termen als ITIL, Prince2 of MSP zijn allemaal methodes (of best practices) die inspelen op zo goed en zo gecontroleerd mogelijk wijzigingen door te voeren in een productionele omgeving. Enfin: ontwikkelstraten.

Mijn klant heeft de beschikking tot meerdere van dit soort straten. Voornamelijk zijn dat .Net en Java. Deze zijn aangevuld met een BI ontwikkelstraat (voor de Management Informatie Systemen) en er is ook een financieel pakket. Deze laatste is ook een ontwikkelstraat, aangezien het standaard pakket niet toereikend is voor de functionaliteit die gewenst is.

Allemaal maken ze gebruik van een OTAP straat en allemaal hebben ze een aparte manier van werken. En dus hebben ze allemaal een eigen proces. Allemaal!

Ze maken gebruik van hun eigen tools, hebben hun eigen processen, hun eigen snelheid en ook de governance is anders. Pas als men richting productie gaat worden er generieke eisen gesteld, aangezien hier ITIL heerst. De ITIL ayatola’s eisen een change in het helpdesk pakket, anders gaat er niets in productie. Sterker nog: er is bepaald dat de A-omgeving ook onder beheer valt en dus moet men zelfs een change indienen om naar een acceptatie test omgeving te gaan.

Zie hier de grote clash vanuit Dev naar Ops: van flexibiliteit (lees: chaos) naar structuur (lees: starheid).

Mijn opdracht is hier een verbetering in aan te brengen onder het motto: wij willen naar DevOps migreren.

Gestart zonder PID geen architectuur en ook geen formele goedkeuring. Hoe dat komt zal ik melden in de volgende blog. Het bewijst wel dat alle voorgaande formele processen die ik beschrijf voor het portfolio management niet noodzakelijk de enige weg naar succes is.

Ik zal in de blog bij gaan houden wat onze vorderingen zijn.

Vaak vertaalt dit zich naar: welke applicaties kan ik migreren tot één.

Vorige week met een partner een gesprek gehad over deze rationalisatie en portfolio management. Het probleem zat in het feit dat ondanks de duidelijk aantoonbare (financiële) voordelen van het migreren van applicaties, klanten dit toch vaak niet doen. Uiteindelijk lukte het hem niet om de klant te overtuigen van de noodzaak.

Waar ligt dat aan?

Volgens mij ligt dit aan de voorkant van het proces: het Strategische Portfolio.

Pas als je weet hoe een klant beslissingen maakt aan de voorkant welke ideeën en initiatieven uiteindelijk worden geautoriseerd, kun je daarin meepraten. Pas dan kun je rationalisatie als onderdeel opvoeren in de besluitvorming.

Dat betekent dus ook dat het geen ICT feestje moet zijn. De business moet daar een heilzaam traject in zien. Dus ICT: kom uit je schulp!

Dat is het BiSL boek: 2 miljard jaar wachten op een sprankje leven.

Wat blijkt? In mijn huidige opdracht van het inrichten van Applicatie Beheer bij mijn huidige klant ben ik tegen het broertje van BiSL gelopen: ASL. Van hetzelfde laken een pak is hier een stukje Aristotelische opsomming van beheertaken bijeengeraapt die zelfs de gemiddelde gabber tijdens de loveparade in slaap sust. Het ergste is nog dat ik in een organisatie verkeer waarbij de ITIL en BiSL ook uit de kast is getrokken. Dat betekent dus dat niet alles klakkeloos overgenomen moet worden, omdat behoorlijk wat zaken opgepakt worden door infrastructuur mannen en Functioneel Beheer.

Als ik dan google op deze rafelrandjes tussen alle drie de methodes, kom je vaak niet verder dan een mooi plaatje hoe deze methodes zich verhouden ten opzichte van elkaar. De drie bollen worden keurig van elkaar gescheiden alsof er een mooi doorgeefluikje mogelijk is van ITIL naar BiSL of ASL en andersom. Dan merk ik dat ik in een politieke organisatie zit, omdat het praten over RACI’s schering en inslag is. Het praten, niet er naar leven.

Binnenkort verwacht ik de vraag hoe het zich verhoudt t.o.v. CobiT.

Ik heb nu reeds de helm besteld om dit gesprek goed voorbereid in te gaan.

Voordeel van een VSM lijkt mij de inzage waar het geld nou ook al weer mee verdiend wordt. Niet met derivaten uitzetten door de controller van uw bedrijf, maar met het maken van goede producten of diensten waar mensen bereid zijn geld voor neer te leggen. Daarnaast zie ik in de ondersteunende IT systemen nog een enorme verzuiling die zelden ooit geplot worden op de keten die het ondersteunt. Hierin is een wereld te winnen. Praat met een beheerder (technisch of functioneel) en je zult praten in systemen, applicaties of een onderdeel van het ondersteunen van een service. De mensen die in een bedrijf als  Achmea weten wat de impact is van het aanpassen van het incassoproces zijn echt geld waard. Of zoek eens een mooie definitie binnen uw bedrijf wat men verstaat onder een ketentest. En ik bedoel één definitie, niet vier of vijf.

Nadeel vind ik een kriebelend gevoel dat ik het beste kan omschrijven met een anekdote. Enkele jaren geleden was ik op Cordial, een evenement georganiseerd door Cordys. Cordys maakt een Enterprise Service Bus die, ondersteund door een Business Proces Modelling tool, een einde maakt aan de spagetti van integratie tools. Tot zover de brochure. Op het evenement sprak iemand van de winkelketen Miss Etam die een succesvolle implementatie achter de rug had van de tool.

Ze beschreef een business case waarbij de kosten van de implementatie van Cordys gedekt werd door het automatiseren van een proces voor het uitwisselen van kleding tussen filialen. Als een klant een bepaalde maat/kleur niet kon vinden, kon nu met dit proces een oplossing gevonden worden bij een ander filiaal. Het proces werd geanalyseerd, een nieuw ontwerp werd gemaakt en Cordys ingezet om deze nieuwe werkwijze te ondersteunen. De extra omzet was de baat bij de business case.

Mij bekroop het gevoel dat Cordys niet de oorzaak was van de extra omzet. Het was de focus rondom het proces die er voor gezorgd had dat dit proces niet meer “erbij” hing, maar een te verbeteren en te handhaven primair proces was. Ongetwijfeld was het een proces dat in de loop der jaren, door evolutie, is ingericht. Iemand begint eens een ander filiaal te bellen voor een klant aan de balie en na verloop van tijd komt er een informatie en goederenstroom op gang. Als je na een lange tijd eens gaat afvragen of dit wel het meest logische proces is, lijkt verbetering niet erg ver weg. Los van een ESB.

Hetzelfde geldt voor de VSM. Zou men niet altijd gewoon in processen moeten denken? En zou men niet altijd gewoon moeten nadenken of het niet slimmer kan? Of sneller? Is dat niet de boodschap van Lean?

Gelukkig is de CPM methode een proces raamwerk.

Helaas kom ik in de knoei als ik me afvraag of een klant hier daadwerkelijk voor wil betalen.

Document: Corporate-Portfolio-Management-v-1.1

Format: pptx

Versie: 1.1

Een mooi voorbeeld van de eerste is een productie organisatie die afhankelijk is van bouwprojecten voor haar afzet. Ze produceren parkeervoorzieningen in de vorm van bijvoorbeeld slagbomen en betaalautomaten. Een project voor dit bedrijf kan dus bestaan uit 1 slagboom. Dit wordt vervolgens geheel gepland op zo’n ouderwets planbord, waar projecten en onderhoud door elkaar heen lopen.

Een groot schoonmaak bedrijf waar ik onlang was, ontkent projecten. Het organogram van dit bedrijf lijkt op een enkelvoudige hartslag. Heel lang een platte lijn, met ineens een enorme piek. Enkele duizenden mensen op de werkvloer en maar een kleine, hoge piramide van management. Het project voor de invoer van een generiek Europees proces dat al enkele jaren duurt is eigenlijk een stille dood gestorven. Elke poging om hier conform een bepaalde methode een mooi einde aan te maken stierf een stille dood. Dit weerspiegelde de planning.

Het mooiste hybride model vind ik de productie van Boeing vliegtuigen. In principe is dit lopende bandwerk. Echter wordt elk vliegtuig gepland alsof het een project is. Dit alles ondersteund door een Project Portfolio Management pakket waarbij de projectstatus dus een weerspiegeling van de productielijn is. Zo is de lijn project geworden. Ik weet alleen niet of dit volgens de Prince2 methode gebeurt.

Hoe kijkt uw organisatie tegen projecten aan?

De eerst volgende keer gaat het fenomeen “de business case” uitgediept worden. De business case is een van de belangrijke thema’s binnen Prince2. Aangezien wij in Nederland het begrip PINO hanteren (Prince In Name Only), zal ik hier eens een schot voor de boeg doen voor de volgende practice.

De project manager schrijft de business case; De opdrachtgever heeft het veel te druk, de projectleider is meestal toch extern ingehuurd om dit soort klusjes uit te voeren en de business case wordt dus geschreven door iemand die er primair geen belang bij heeft.

De business case wordt zodanig gemanipuleerd dat ie de norm haalt; Omdat de projectleider de business case schrijft, zijn de genoemde cijfers flexibel. De projectleider schrijft de business case namelijk om een akkoord te krijgen, niet noodzakelijk om waarheidsgetrouw te zijn.

Gedurende het traject ligt ie op de plank; Versie 1.0 wordt geschreven, centraal opgeslagen en als zodanig aan het einde van het project opgeleverd als deliverable. Intussen vangt hij virtueel stof.

Aan het einde worden slechts de kosten nog vergeleken; Omdat de projectleider eindverantwoordelijk is voor het proces zal hij zich moeten verantwoorden naar de uren gespendeerd versus de uren gepland. Deze actie is nodig voor het verkrijgen van decharge op zijn of haar project. Op basis hiervan krijgt hij/zij een schouder klopje of duw.

De business case wordt niet overgedragen aan een business eigenaar (waar het al had moeten liggen); Door operationele druk en het volgende stapeltje van projecten dat de opdrachtgever weer moet opstarten, gaat de business case op hoop van zegen de la in totdat, bij succes, deze wellicht het jaarverslag ingaat.

Er wordt niet aan benefit tracking gedaan

Onder deze omstandigheden zou ik persoonlijk niet op het break even moment een evaluatie van de benefit case uitvoeren. Wat ga je daar leren? Hoe vaak gebeurt dat eigenlijk in uw bedrijf?