Tuesday, December 28, 2010

Training Archimate Modelleertaal Enterprise Architectuur

Te RealDolmen hebben we het RealDolmen Brains platform waarbij enthousiastelingen avondtrainingen geven aan geïnteresseerde collega's. Onderstaande inleiding tot de ArchiMate modelleertaal voor Enterprise Architectuur werd 20 december 2010 gegeven door Wesley Bille en mezelf.

ArchiMate is de open en vendor-onafhankelijke modelleertaal van The Open Group. ArchiMate vormt een mooie aanvulling op het methodische raamwerk van TOGAF, The Open Group Architecture Framework. TOGAF helpt bij de integratie en het beheer van IT resources vanuit een strategie- en een business-gedreven standpunt. ArchiMate is een architectuurtaal die visualisatietechnieken bevat die toelaten om de samenhang en relaties tussen verschillende domeinen (business, applicaties, technologie, …) in kaart te brengen. Hierdoor voorziet ArchiMate de enterprise architect van eenduidige instrumenten ter ondersteuning en verbetering van het architectuurproces. Zulke instrumenten moeten de architect ook helpen in de communicatie met andere belanghebbenden, zoals managers en softwareontwikkelaars. Hiervoor kan men in ArchiMate views en viewpoints definiëren.



Volgende agenda wordt doorgenomen in bovenstaande presentatie:
  • Inleiding Archimate
    • Inleiding Archimate
    • Toolondersteuning
  • Inleidende concepten en modelleren met ArchiMate
    • Het Metamodel van ArchiMate
    • Bedrijfsarchitectuur
    • Applicatiearchitectuur
    • Technologiearchitectuur
    • Relaties tussen architectuurdomeinen
    • View en viewpoints per specifiek doelpubliek
  • Situering Archimate
    • Relatie tot TOGAF
    • Relatie tot UML en BPMN
  • RealDolmen Case Study Medic Lab (door Wesley Bille, zit niet in de presentatie gezien confidentialiteit)
Tijdens de training werd de gratis Archi modelleertool gebruikt waarmee trainingsmodel en de fictieve realdolmen case geopend kunnen worden.

Meer info over archimate is te vinden op www.archimate.org

Enjoy!

Saturday, October 9, 2010

BOOK - How we do Scrum

Henrik Kniberg describes in Scrum and XP from the Trenches how they do Scrum. This - free to download - book is interesting for everyone who wants to learn about how to do Scrum pragmatic in practise and to avoid pitfalls.

He describes how they do
  • Product backlogs (including user and tech stories)
  • Sprint planning (using planning poker :)
  • Communicate sprints
  • Sprint backlogs (taskboard, burndown chart,...)
  • Daily Scrums
  • Sprint demos
  • Sprint retrospectives
  • ...

and gives tips and tricks about
  • Slack time between sprints
  • Organising - distributed - teams
  • Estimated velocity
  • Fixed prices and release planning
  • eXtreme Programming practises
  • Testing and quality
  • ...
  • and other suggested reading

Tuesday, September 21, 2010

PRINCE2 samenvatting en valkuilen project manager

Telkens als ik het boek “Managing Successful Projects with PRINCE2” opnieuw lees blijf ik er van versteld staan hoeveel nieuwe ideeën ter verbetering ik blijf opdoen.

Hieronder schets ik kort nog eens de principes, methodes en processen van Prince2 om vervolgens enkele valkuilen aan te kaarten waartegen al te vaak gezondigd wordt.

Principes
Indien u een project beheert met Prince2 dienen volgende principes van start tot einde gevolgd te worden:
  • Continued business justification om permanent te valideren of het project nog de moeite loont
  • Learn from experience om van bij de start, tijdens de uitvoering en bij het einde positieve en negatieve ervaringen en remedies mee te nemen en te communiceren
  • Defined roles and responsibilities lijkt een open deur intrappen maar duidelijke afspraken en verantwoordelijkheden zijn fundamenteel voor het welslagen van een project
  • Manage by exception laat de stuurgroep, project manager en team manager(s) toe om op hun niveau zelfstandig te werken en slechts bij “uitzondering” naar het hogere niveau te communiceren of escaleren. Zo wordt tijd efficiënt gebruikt.
  • Focus on products zorgt voor een goed begrip van wat er op het einde van het project aan welke kwaliteit dient gerealiseerd te worden.
  • Tailor to suit the project environment impliceert de stelregel om de methodes en processen van prince2 te gebruiken tenzij afwijkingen beter, weldoordacht en gedocumenteerd worden toegepast op de context van uw project.

Methodes
De methodes zijn de aspecten van Prince2 project management die continue dienen toegepast te worden:
  • Business Case heeft als doelstelling mechanismes te implementeren waarbij beoordeeld wordt of het project wenselijk is en blijft om op basis daarvan beslissingen te kunnen nemen. Naast de redenen voor het project met verhoopte voordelen worden ook neveneffecten, kosten en risico’s behandeld.
  • Quality heeft als doelstelling kwaliteit te definiëren alsook het implementeren van middelen om de kwaliteit te behalen en te kunnen valideren. Een kwaliteitstrategie wordt opgesteld alsook duidelijke afspraken over hoe de producten die het project gaat leveren vorm worden gegeven, de acceptatiecriteria waaraan ze moeten voldoen, hoe deze gevalideerd, geaccepteerd worden enz.
  • Risk heeft als doelstelling om onzekerheid te identificeren, te onderzoeken en te controleren. De risico management strategie wordt vorm gegeven, een budget wordt voorzien om met risico’s om te gaan alsook mogelijk antwoorden op “bedreigingen” maar ook “opportuniteiten” die zich tijdens het project kunnen manifesteren.
  • Plans heeft als doelstelling communicatie en controle te faciliteren waarbij plannen op drie niveaus hiertoe moeten bijdragen, met name het projectplan dat bestaat uit minimum twee stage plannen die op hun beurt bestaan uit optionele team plannen die het effectieve werk inplannen (wie doet wat hoe en wanneer). Tevens beschrijft dit thema gedetailleerd de stappen om tot goede planning te komen en hoe met uitzonderingssituaties die een impact hebben op de plannen dient omgegaan te worden.
  • Organization heeft als doelstelling de projectstructuur van aansprakelijkheid en verantwoordelijkheid efficiënt vorm te geven. Zowel het “bedrijf” (management), de gebruikers van de producten alsook de leverancier die de producten dient te maken zijn vertegenwoordigd. De stuurgroep, project management en team-structuur van het project worden vorm gegeven alsook de verhouding t.o.v. het management van het bedrijf of het programma.
  • Change heeft als doelstelling “issues” te identificeren, te onderzoeken en potentiële en goedgekeurde veranderingen in het project te incorporeren. Een configuration management strategie wordt daartoe vorm gegeven die duidelijk de procedures beschrijft om gecontroleerd met “issues” en “veranderingen” om te gaan. Tevens kan een budget vastgelegd worden voor onverwachte toevoegingen aan het project en kan een platform ingericht worden dat van de stuurgroep het mandaat krijgt om over bepaalde wijzigingen te beslissen.
  • Progress heeft als doelstelling mechanismes te implementeren die voorzien in het opvolgen van de verwezenlijking van de oorspronkelijke planning, te voorzien in voorspellingen voor de toekomst en onaanvaardbare afwijkingen ten aanzien van de planning te controleren. De definitie van “management stages” is hierbij essentieel om het geheel overzichtelijk te houden en inspanningen zo efficiënt mogelijk te laten zijn. Daarnaast worden afspraken gemaakt over een periodieke rapportering en rapportering wanneer een bepaalde “gebeurtenis” zich voordoet (bvb. einde van een stage, ziekte van een medewerker die een impact heeft op de planning enz.)

Processen
Binnen Prince2 is een proces een gestructureerde set aan activiteiten om een bepaald doel te realiseren. De schematische weergave geeft een overzicht van de later toegelichte processen.


  • Starting up a project heeft als doelstelling de vraag “hebben we een levensvatbaar project dat de moeite waard is?” te beantwoorden. De bestuurder (sponsor) en project manager worden aangeduid alsook de projectaanpak. In dit proces wordt tevens een ruwe Business Case gemaakt. Dit alles wordt vastgelegd in het projectvoorstel (Project Brief). Tevens wordt een plan gemaakt voor de initiatie-stage.
  • Directing a project heeft als doelstelling de “stuurgroep” (project board) in staat te stellen voor het succes van het project verantwoordelijk te zijn door belangrijke beslissingen te nemen en het dagelijks beheer door te delegeren. Belangrijke activiteiten zijn de beslissing tot start van de initiatie stage, tot start van het project, tot afsluiting en start van management stages en tot afsluiting van het project in zijn geheel. Naast het beslissen omtrent deze mijlpalen wordt beschreven hoe met periodieke rapportering, uitzonderingsrapportering en “issues” om te gaan.
  • Initiating a project heeft als doelstelling stevige fundamenten te leggen alvorens met de effectieve uitvoering van het project te starten. Belangrijke activiteiten zijn het uitwerken van strategieën die doorheen het project gebruikt zullen worden met betrekking tot risico, kwaliteit, configuratie en communicatie. Vervolgens worden instrumenten ter controle van het project gedefinieerd (bvb. frequentie en vorm van de communicatie tussen de management niveaus, aantal management stages, omgang met issues, definiëren van autoriteit, vormgeven van escalatie-afspraken etc.). Dit alles moet toelaten om het projectplan vorm te geven en alles vervolgens samen te brengen in het “project initiatie document” dat door alle partijen dient goedgekeurd te worden.
  • Controlling a stage heeft al doel het werk dat uitgevoerd dient te worden toe te wijzen, het op te volgen, om te gaan met problemen die zich stellen, progressie te rapporteren aan de stuurgroep en te verzekeren dat de “stage” binnen de afgesproken tolerantiegrenzen blijft. Een belangrijke activiteitenketen bestaat uit ten eerste het toekennen van een werkpakket (bvb. de bouw van een onderdeel) aan een team (incl. goede afspraken hieromtrent), ten tweede het overzien of controleren van de status van een werkpakket en uiteindelijk het ontvangen van het werkpakket. Naast deze activiteiten is het belangrijk de “stage” in zijn totaliteit op te volgen en hierover te rapporteren. Gedurende een stage is het belangrijk “issues” en risico’s te capteren en onderzoeken, eventueel te escaleren en correctieve maatregelen hieromtrent te nemen en uit te voeren.
  • Managing product delivery heeft als doel de link tussen de project manager en de team manager te vormen. Het is de team manager zijn taak om het werk te coördineren opdat producten die werkpakketten vormen te realiseren. De link met de activiteitenketen van het “controlling a stage” proces is zeer duidelijk, de voornaamste activiteiten bestaan immers uit ten eerste accepteren van een werkpakket, ten tweede het uitvoeren van het nodige werk om het werkpakket uit te voeren en uiteindelijk het opleveren van een kwaliteitsvol werkpakket.
  • Managing a stage boundary heeft als doel de grenzen van de management stages te beheren, met name voldoende informatie voorzien aan de stuurgroep om het succesvolle einde van de huidige stage te beoordelen en anderzijds goedkeuring te geven aan de start van de volgende management stage. Het kan zijn dat een uitzonderingsplan de op dat ogenblik in uitvoering zijnde stage vervangt. Voornaamste activiteiten zijn in eerste instantie ofwel het opstellen van een plan voor de volgende stage ofwel het opstellen van een uitzonderingsplan ter vervanging van de huidige stage. Vervolgens worden het projectplan en de business case geüpdate en de huidige stage beëindigt.
  • Closing a project heeft logischerwijze als doel het project op een correct manier te beëindigen. Indien het een geplande beëindiging is wordt deze voorbereid, worden de geaccepteerde producten overhandigd naar de klant, het project geëvalueerd en de afsluiting van het project naar de stuurgroep toe aanbevolen. Indien het een ongeplande premature beëindiging van het project betreft worden eventueel al gerealiseerde producten overhandigd.

Valkuilen
Prince2 is een rijke set aan instrumenten om een project binnen timing en budget kwalitatief te realiseren. Dikwijls merk ik echter dat zeer eenvoudige valkuilen de oorzaken zijn van problemen in een project, hieronder enkele voorbeelden:
  • Projecten die starten zonder formeel goedgekeurd “Project Initiatie Document”. Als reden hiervoor geeft men op dat men snel met het eigenlijke project moest starten en er geen tijd was om dit fundamentele document te maken of dat men dit wel maakte maar niet liet goedkeuren enz. Dit document vormt echter de basis voor heel wat zaken, het beschrijft rollen en verantwoordelijkheden, de op te leveren producten en hun acceptatiecriteria; performantieindicatoren zoals cost, timescale, quality, scope, risk en benefits; tolerantiegrenzen etc.
  • Het ontbreken van afspraken tussen de verschillende management niveaus zoals er zijn stuurgroep (directing), project management en team management. Bijvoorbeeld een project manager die ineens 3% extra budget nodig heeft en niet weet met wie dit kort te sluiten en of hij hier misschien zelf bevoegdheid over heeft. Een ander voorbeeld betreft mensen die producten aan het realiseren zijn en de project manager in het ongewisse laten over hun progressie, kwaliteitsproblemen die men tegen komt of in extreme gevallen zelfs autonoom beslissingen nemen die het ontwerp wijzigen.
  • Verslaggeving van stuurgroepen of werkgroepen die ontbreekt, onvolledig of onduidelijk zijn. Indien ze daarenboven niet opgevolgd worden wat betreft tijdige uitvoering van gedefinieerde taken en consequenties van genomen beslissingen is dit dikwijls een voorbode van problemen die onderweg zijn.
  • Onvolledig of slecht verwachtingen management. Als de verwachtingen van de verschillende partijen (klant, gebruikers, leverancier) duidelijk en op elkaar afgestemd zijn geeft dit een goede kans dat uiteindelijk een succesvol project zal opgeleverd worden. Het is belangrijk dat dit gebeurt voor alle performantie-indicatoren costs, timescale, quality, scope, risk en benefits.
  • Het niet definiëren van “management stages” die het geheel controleerbaar en beheersbaar maken. Gevolgen hiervan kunnen zijn dat pas op het einde van het project blijkt dat de timing niet zal gehaald worden of dat bepaalde activiteiten ter creatie van bepaalde producten al bezig zijn op basis van niet goedgekeurde, onvolledige of zelfs foutieve producten of productspecificaties. Het hoeft geen betoog dat dit nefast kan zijn voor een project.

Meer informatie vindt u op http://nl.wikipedia.org/wiki/PRINCE2 en http://www.ogc.gov.uk/prince2/

Wednesday, March 10, 2010

BPM Roundtable TU/e on February 22, 2010

On February 22th I attended the first BPM Roundtable hosted by the Technical University of Eindhoven. You can find all the presentations on http://www.bpmroundtable.nl . I think the next quotes may be interesting:

1. Will tomorrow's auditor be a process miner?


If you are an auditor, the topic Replaying History by Wil van der Aalst (TU Eindhoven) gives a lot of ideas to embed this into your habitat.

The following quotes come from Marieke Snoep's (T-Mobile) presentation about in From Waste to Wow.

2. Operating Costs a balance between preventive and corrective work.


3. All processes consist of three types of activities:
 


4. Process integration management is intended to realise the ambition to become the ‘zero defect company’ with the 'first time right culture'

5. It's an art to manage processes within a company, to communicate them and make them work

My conclusion about Remco Dijkman's (TU Eindhoven) presentation: Veel Procesmodellen? Weggooien, of ... serieus beheren!

Sunday, February 21, 2010

BPMN 2.0 Applied: Level 1 descriptive modeling or business-oriented process mapping

Introduction

It's very practical how Bruce Silver describes the usage of BPMN 2.0 in three levels (Silver, Bruce (2009). BPMN Method & Style. Aptos, CA 95003 USA: CODY -CASSIDY PRESS).

  1. Level 1 - descriptive modeling or business-oriented process mapping. This level creates a good understanding for all stakeholders about how the business is running.
  2. Level 2 - analytical modeling or the "common process language shared by Business and IT". This level can use the complete notation and describes more complex logic. It's the basis for describing processes in detail, ready to automate.
  3. Level 3 - executable modeling is brand new with BPMN 2.0. It transforms BPMN from a diagramming notation to an XML language for executable process design. At level 3 it should be possible to govern executable systems by graphical models rather than "code". 

 

Level 1 Modeling Palette

The following BPMN constructs comprise the Level 1 Palette.
  • Pool: the pool represents the process as internal participant, this is also called a white-box pool because you know how it works. A black-box pool represents an external participant you don't know from the inside, for example "customer" or "partner".
  • Lane: most often lanes represent performer roles or business units in a white-box lane. You can also use sub-lanes, for example a unit within a department.
  • Task (user, service): a task is an atomic activity. A User Task means a task performed by a Human. A Service Task means an automated activity.
  • Sub-process: a sub-process is a compound activity, meaning an activity with sub-parts that can be represented as a process, a flow of contained activities.
  • Start event (None, Message, Timer): A Start Event indicates the start of a process or sub-process. A None Start Event means the trigger is unspecified, a sub-process must start with a None start. A Message Start signifies the process is triggered by a signal from outside the process. A Timer Start Event signifies the process is run on some predetermined schedule either on-time or recurring.
  • End event (None, Message, Terminate): An End Event indicates the end of a path in a process or sub-process. With a None End Event no result signal is thrown. With a Message End Event a message is sent. With a Terminate End Event immediately ends the process or sub-process.
  • Gateway (Exclusive or Parallel): An Exclusive Gateway (XOR) means only one of the output sequence flows is to be followed, based on some condition. A Parallel Gateway (AND-split) means that all output sequence flows are to be followed.
  • Sequence Flow: A sequence flow links activities, gateways and events within a single pool. They represent orchestration.
  • Message Flow: A message flow represents a signal (message) between two pools. To associate data, you can add a message symbol, an envelope icon. It may not be used to connect two nodes within a single pool.
  • Data Object, Data Store: A Data Object represents a variable while a Data Association represents a mapping between that variable and a data input or output. A Data Store represents externally stored data accessible to the process.
  • Text Annotation: Used to insert information within a diagram.
  • Link event pair (off-page connector): to split a process over more than one page.
 

Level 1 Method and Style

I advice a top-down approach because you'll get to the end just as quickly and be happier with the end result. In black text I describe the methods to create a level 1 BPMN diagram and in red italic I describe the style conventions that will help you to create clear and consistent diagrams.
  1. Define Process Scope
  2. Create the Top Level Diagram for the Happy Path
    1. Add Pools
      • Label white-box pools with the name of a process
    2. Add Lanes (optional)
      • Model internal process participants (activity performers) as lanes within a single process pool. Label lanes with the role or organizational unit that performs (or is responsible for) its contained activities.
    3. Add Happy Path Start and End Event to Process Pool
      • Use only one start event
      • Label Message start events "Receive X" where X is the object triggering the process
      • Label Timer start events to indicate the process schedule ( time or recurring)
    4. Add Major Steps in the Happy Path
      • Label activities VERB-NOUN
      • Try to break it down to no more than 6 steps, use sub-processes to avoid that.
      • Sequence flow must not cross a pool boundary.
      • Sequence flow must not cross sub-process boundary.
    5. Reconnect Concurrent Steps
    6. Add Gateways (XOR and AND) and reconnect steps
      • All activities, gateways and events must be connected via a continuous chain of sequence flows leading from a start event to an end event. They cannot be "floating" in the diagram.
  3. Add Top-Level Exception Paths (most processes have other flows than the happy path
    1. Identify Exception End States and represent them as End Event
      • Label them to indicate the end state. If multiple paths lead to the same effective end state, route them all to a single end event.
    2. Insert Gateways to Define Exception Paths
      • If possible, label exclusive decision gateways with a Yes/No Question, and label the outgoing sequence flows yes and no where the "Yes" answer describes the exception.
  4. Expand Sub-process to Show Detail at Child Level
      • Make models hierarchical, fitting each process level on one page
      • You MUST use a None Start Event
  5. Add Intermediate Message Flows to External Pools (Optional)
    1. Add Black-box pools for External Participants
      • Label black-box pools with a participant role or business entity
      • Begin customer-facing processes with a Message Start Event receiving a message flow from the Customer Pool
    2.  Add Top-Level-Diagram Message Flows
      • Show them between the process and all external pools
      • Label message flows with the name of the message. Use a message linked to the message flow to indicate additional detail, if necessary.
      • Message flow cannot be use to connect points in the same pool.
      • Message flow cannot connect to a gateway.
    3. Add Child-Level-Diagram Message Flows
      • Be consistent with the parent diagram (more detail is possible)
Remarks:
  • I advice not to use "Data Objects". If you want to use them I advice to reserve them for information details of packaging that is not obviously implied by the orchestration itself.
 

Examples

Figure 1: Top Level Diagram for the "Project Sales" process
The "Black-box" Customer has an opportunity.  In the sub-process "Close Opportunity" the deal is closed. If the deal is won, a contract is registered in the ERP-system to fulfill the contract. If a contract according the standards for that company is necessary a contract is created and mutually signed. If a valid contract is available the project status is set to "active".
 

Figure 2: Child Level Diagram for the "Close Opportunity" sub-process
In this process diagram the sub-process is foreseen with much more detail, including lanes.