ASL en BiSL raamwerk

Geplaatst op 27/11/2013 door Paul Willems

Nou hoopte ik met hart en ziel dat ik met het boekje BiSL (Van Haren publishing) verreweg het saaiste boek aller tijden had gelezen. Persoonlijk moet ik hierbij aangeven dat ik het telefoonboek, wetboek van strafrechten en de Dode Zee rollen in het originele Hebreeuws niet meereken tot dezelfde categorie. Je hebt boeken waarin met een dodelijk ritme van opsommingen een voorleeslijst wordt bijeengeraapt zo saai als slootwater. En je hebt BiSL, water waar de oersoep wordt gecreëerd van waaruit ooit leven zou kunnen ontstaan. Even voor de creationisten onder ons: het is op dit moment een vaststaand feit dat het zo’n 2 miljard jaar heeft geduurd voor het leven ontstond.

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.

Geplaatst in Blog | Getagged , , | Een reactie plaatsen

LEAN pmo

Geplaatst op 23/05/2013 door Paul Willems

LEAN. Ik ben me aan het inlezen in de wondere wereld van Lean. Het is een wereld van herkenning, waarbij veel technieken die ik tijdens mijn studie Technische Bedrijfskunde aan de TuE voorbij komen. Deze studie heb ik niet recent afgerond, dus deze technieken zijn ook zeker niet nieuw. JIT, het kanban systeem, het House of Quality, PDCA en de Poka-Yoke zijn allemaal technieken die de revue gepasseerd zijn. Wel helemaal nieuw was de Value Stream Map. Een mooi systeem om de waarde van de keten in kaart te brengen. Echter krijg ik nu juist daar een ambigue gevoel over.

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.

Geplaatst in Blog | Een reactie plaatsen

Algemene CPM presentatie

Geplaatst op 17/04/2013 door Paul Willems

In deze presentatie wordt de Corporate Portfolio Management methode uitgelegd voor algemeen publiek.

Document: Corporate-Portfolio-Management-v-1.1

Format: pptx

Versie: 1.1

Geplaatst in Presentatie | Een reactie plaatsen

Project

Geplaatst op 10/04/2013 door Paul Willems

Wat is eigenlijk een project? Zonder direct in een valkuil van definities te stappen, gaat het mij om hoe een bedrijf tegen dit concept aankijkt. Er zijn bedrijven die alleen maar projecten uitvoeren en er zijn bedrijven die projecten ontkennen. De eerste categorie zal alles uniek vinden en per project de flexibele organisatie optuigen die daar voor nodig is. Dat kunnen bijvoorbeeld pure verkooporganisaties zijn. De tweede is wars van project management en vindt dat de lijn alle wijzigingen makkelijk zelfstandig kan opvangen.

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?

Geplaatst in Blog | Een reactie plaatsen

Benifit Tracking…waar gaat het mis?

Geplaatst op 20/03/2013 door Paul Willems

In de project management practice van Triage IT wordt telkens een ander onderwerp behandeld en stevig uitgediept. De diverse ervaren project managers komen bij elkaar en bespreken zaken als stakeholder management, governance en risico management. Hierbij wordt dankbaar gebruik gemaakt van hun ervaring in de vele jaren dat ze door de grote bedrijven ingehuurd waren.

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?

Geplaatst in Blog | Getagged , , | Een reactie plaatsen