Value Stream Map

Value Stream Mapping is een modelleringstechniek afkomstig uit Lean en wordt vooral gebruikt in productieomgevingen. In een VMS map wordt de fysieke stroom van materialen en producten door het productieproces getoond. Een VMS analyse geeft informatie hoe het huidige voortbrengingsproces van diensten en producten functioneert. Het toont niet alleen de processtroom, maar geeft ook de werkelijke procesgegevens. Omdat VSM schema’s gebaseerd zijn op basis van data, kan een VSM goed helpen bij het pinpointen van specifieke problemen in een proces. Zoals bijvoorbeeld lange wachttijden, veel fouten.

Het doel van een VSM is om in een proces zaken te kunnen vinden die leiden tot verspilling (‘waste’) en die daardoor geen waarde voor de klant toevoegen.

Symbool Betekenis
Symbool voor klant of leverancier. Als dit symbool linksboven in de plaat staat, dan betreft het een leverancier; staat het rechtsonderaan dat betreft het een klant.
Symbool voor een proces, activiteit, afdeling of machine waar materiaal doorheen loopt.
Een gegevenssymboll (databox) wordt geplaatst onder andere symbolen om de gegevens die daardoorheen lopen toe te lichten
Een voorraad (inventory) symbool wordt gebruikt om de voorraad tussen twee processen weer te geven.
Een push arrow toont situaties waarin materiaal van het ene naar het andere proces ‘geduwd’ wordt.
De pijl voor zending (shipment) heeft twee mogelijkheden. Of het toont het transport van ruw materiaal van een leverancier naar de ontvangststations in de fabriek. Of het toont het transport van gereed product van zendstations naar de klant.
Dit symbool staat voor een ‘Supermarket’ voorraadpositie en wordt ook in Kanban als zodanig gebruikt.
Door middel van dit ‘Pull’ symbool wordt het fysieke transport van materiaal van een supermarkt voorraadpositie naar een ander (lagergelegen) proces getoond.
Als er sprake is van leveringen aan klanten of van leveranciers waarbij gebruik wordt gemaakt van extern transport, dan wordt dit symbool gebruikt.
Dit symbool betekent dat er informatie op electronische wijze (bv. internet, LAN, e-mail) wordt verzonden tussen twee entiteiten.

 

De VSM wordt vaak gebruikt in de Define-fase van een L6S-project om het te verbeteren proces inhoudelijk te kunnen analyseren en te kunnen begrijpen. In Visio 2013 is een stencil beschikbaar voor het opstellen van VSM-platen (zakelijk – bedrijfsprocessen – shapes voor waardestroomanalyse). De images die op deze plaat getoond worden zijn afkomstig van dit stencil.

Unified Modeling Language (UML)

Unified Modeling Language (UML) is zowel een taal om diagrammen te maken als een notatiewijze om modellen van objectgeoriënteerde software-systemem te specificeren, te visualiseren en te beschrijven.

UML dient twee doelen: (1) visualisatie van het softwaresysteem en (2) communicatiemiddel.

Oorsprong

UML vind zijn wortels in het object-georienteerde programmeren, dat in de 80’er jaren aan populariteit won. UML staat onder toezicht van de Object Management Group (OMG), die UML in 1997 standardiseerde. In 2000 werd UML door de International Organization for Standardization (ISO) geaccepteerd als standaard voor het modelleren van software systems. Sinds 1997 heeft het OMG de taal steeds verbeterd; inmiddels is 2.4.1, daterend van juli 2011, de meest recente versie.

Gebruik van use case diagrams

Use case diagrams worden in de volgende situaties gebruikt:

  • bij het bepalen van business requirements; bij het opstellen en uitwerken van nieuwe use cases stuit men dikwijls op nieuwe eisen communicatie met klanten;
  • omdat use cases relatief eenvoudig zijn, vormen zij voor de use case ontwikkelaars een goed middel om te communiceren met betrokkenen als klanten en gebruikers.
  • ontwikkelen van test cases; een verzameling van use cases vormt een goede basis voor testcase scenario’s.

Terminologie

  • Een model is een abstractie van een onderliggend probleem
  • Het domein is de werkelijke wereld waarin problemen zich voordoen
  • Een model bestaat uit objecten die met elkaar communiceren via boodschappen
  • Een object bestaat uit attributes (zaken die het object weet) en behaviors (zaken die het object kan)
  • Een attribute kan een bepaalde waarde hebben, de state
  • Een class is een blauwdruk voor een object; in een class zijn zowel attributes als behaviors opgenomen. Een object kan gezien worden als een instance van een class.

Hierarchisch opbouw van UML

UML bestaat uit hiërarchische een set van 13 verschillende diagrammen, verdeeld over 6 diagrammen die iets over het systeem zelf vertellen (de structural modeling diagrams) en 7 diagrammen die iets over het systeem en relatie met zijn omgeving vertellen (de behavioral modeling diagrams).

  • structural modeling diagram
    • class diagram
      • toont het model in een statische situatie
      • geeft de relaties tussen de classes in het systeem aan
      • wordt weergegeven door een rechthoek met drie lagen:
        • eerste laag : class name
        • tweede laag : class attribute
        • derde laag: class methode (een + betekent: public; een – betekent: private)
    • object diagram
      • speciale vorm van een class diagram
      • toont de relatie tussen classes op een bepaald moment
      • wordt weergeven als gekoppelde rechthoeken
    • component diagram
      • componenten zijn te vergelijken met classes en zijn te onderscheiden door component diagram teken
      • systemen worden opgebouwd aan de hand van components
      • componenten communiceren onderling door middel van interfaces
    • package diagram
      • wordt gebruikt het systeem op een hoger abstractieniveau te kunnen tonen
      • classes worden hiertoe gegroepeerd in packages
      • in het package diagram worden alleen de relaties tussen de packages getoond
    • composite structure diagram
    • deployment diagram
  • behavioral modeling diagram
    • use case diagram
      • toont hoe een buitenstaander tegen het systeem aankijkt
      • het gaat om wat het systeem doet en niet om hoe het systeem het doet
      • use case diagram bestaat uit meerdere scenario’s
      • een use case scenario is een voorbeeld van wat er gebeurt als iemand of iets (de Actor) met het systeem interacteert
    • activity diagram
    • state machine diagram
    • communication diagram
    • sequence diagram
    • timing diagram
    • interaction overview diagram

Vanuit BPM in het algemeen en requirements management in het bijzonder, vormen de use case diagrams de belangrijkste typen. Deze kijken immers vanuit de optiek van de klant of de gebruiker naar het systeem. Reden om de use case diagram verder uit te werken.

Opbouw

Een use case diagram bestaat uit de volgende elementen (constructs):

  • use case; Een reeks van activiteiten en alternatieven waarmee een systeem interacteert met een actor
  • actor; persoon of systeem die interacteert met een systeem system boundary; toont de grenzen tussen het systeem en de actor
  • association; de wijze waarop een actor participeert in een use case
  • exclude; relatie tussen een andere, externe use case en de use case zelf
  • generalization; hierarchische relatie tussen een algemene en een specifieke use case
  • include; relatie tussen een de use case en een ingesloten use case Exclude en include

Exclude en include zijn in een use case dikwijls lastige begrippen. Included use cases worden gebruikt om te voorkomen dat eenzelfde use case meerdere keren wordt beschrijven. Hiermee wordt redundantie in de use case voorkomen. Als dezelfde stappen in meeerder use cases gebruikt worden, dan worden deze in een een afzonderlijke use case opgenomen en aangeroepen vanuit de oorspronkelijke use cases. Een included use case is onderdeel van zijn aanroepende use cases.

Samenvattend; een included use case wordt gebruikt indien:

  • twee of meer use cases maken gebruik van de included use case;
  • alleen het resultaat van de included use case wordt gebruikt;
  • gebruik van de included use case is niet optioneel;
  • de opsplitsing in meerdere use cases de leesbaarheid van het diagram wordt verbeterd.

Door middel van een extending use case kan er functionaliteit in een use case toegevoegd worden. De oorspronkelijke use case blijft ongewijzigd.

In de volgende situaties kan er gebruik worden gemaakt van een exclude uses case:

  • een deel van de use case is optioneel en
  • een deel van de use use wordt alleen in bepaalde omstandigheden uitgevoerd.

Voorbeelden

  • Bij het plaatsen van een order wordt een kredietwaardigheidstoets uitgevoerd en de klant blijkt niet kredietwaardig. De use case roept een exclude use case aan, waarin niet kredietwaardige klanten worden verwerkt; de actor van deze excluded use case is niet de klant, maar bijvoorbeeld een sales manager.
  • Een sales order systeem kent twee use cases (check order status en place order) waarvoor de actor (in casu: de klant) moeten inloggen. De twee use cases roepen daarom een include use case ‘login’ aan.

Voorbeeld van een use case diagram (pin automaat)

mvp_uml

Swimlanes

Sim lanes vormen een toevoeging aan de op blokjes, pijlen en wiebertjes gebaseerde flow charts.

Het grote voordeel van swim lanes is dat inzichtelijk wordt hoe processen zich door de de organisatie heen bewegen. Vaak maakt dit pijnlijk duidelijk hoeveel handshakes er nodig zijn om een proces er succesvol doorheen te krijgen.

Om dit inzicht te krijgen wordt het proces opgedeeld in banen die ieder een persoon, groep of systeem voorstellen. Activiteiten en beslissingsmomenten worden gegroepeerd in de banen op basis van verantwoordelijkheden.

mvp_swimlanes_3

Swimlanes wordt zowel horizontaal als verticaal afgebeeld. Persoonlijk vind ik de horizontale variant gemakkelijker te lezen. Kwestie van smaak. De verticale variant – mits niet te breed – laat zich gemakkelijker printen op A4 of A3. Voor het bespreken van processen is dat wel gemakkelijker.

Een praktijkvoorbeeld

De onderstaande figuur toont een business use case waarin een swimlane is gebruikt om de impact op de processen door de introductie van een nieuw product in kaart te brengen. De processtappen/activiteiten die geraakt worden zijn geel gekleurd. De figuur is ontwikkeld in yED.

mvp_swimlanes_4

Supplier, Input, Processes, Output, Customer – SIPOC

De SIPOC is een methode voor procesbeschrijving uit de Six Sigma toolkit. Het is in essentie een high level proces map met daarin Supplier, Inputs, Processes, Outputs, Customer. Belangrijkste doel van de SIPOC is om het team duidelijk te maken wat de scope van het project, een probleem of een wijziging is.

Betekenis van de afkorting

De letters staan voor: Supplier, Input, Process, Output en Customer.

  • Supplier; Mensen of groepen van mensen die zorgen voor de levering van datgene waaraan op dat moment gewerkt wordt
  • Input; Formulier, materiaal of informatie die wordt aangeleverd; inclusief de requirements waaraan de input moet voldoen
  • Processen; Activiteiten die uitgevoerd moeten worden
  • Output; Product, dienst of informatie dat naar de klant gaat; inclusief de requirements waaraan de output moet voldoen. De outputs vormen datgene dat gemeten wordt en verbeteringen in de outputs dienen bereikt te worden door veranderingen in de inputs en/of het proces.
  • Customer; Eindgebruiker of een volgende stap in het proces

mvp_sipoc_2

 

 

 

 

 

Een voorbeeld

Supplier Input Process Output External Customer
Leveranciers die grondstoffen toeleveren. Rundvlees, broodjes, sauzen, augurkjes, zakjes, specerijen. Het verwerken van vlees, specerijen, broodjes, saus en zakjes in hamburgers. hamburgers alle externe groepen of personen die hamburgers kopen.

Werkwijze

Het invullen van een SIPOC diagram lijkt makkelijker dan het is. Hier de stappen die gevolgd kunnen worden om te komen tot een SIPOC.

  • Zorg voor een plek waar de teamleden hun toevoegingen op het SIPOC schema kunnen plaatsen. Bijvoorbeeld door de letters S I P O C op een brown paper op een muur te plakken. De teamleden kunnen dan post-it notes gebruiken.
  • Begin met het in kaart brengen van de processtappen. Stel eerst vast wat de start van het proces is en wat het einde van het proces is.
  • Bepaal de output van het proces vast
  • Bepaal wie de klanten zijn die de output zullen ontvangen.
  • Bepaal welke input nodig is om het proces goed te laten verlopen.
  • Bepaal de suppliers van de input
  • Optioneel: stel een voorlopige lijst van klantwensen op. Deze wordt later – in de Measurement fase – verder gebruikt.
  •  Bespreek en verifieer de uitkomsten met belanghebbenden

Structured Analysis and Design Technique – SADT

De Structured Analysis and Design Technique (SADT) is een methode voor systeemontwerp en software-ontwikkeling waarbij systemen als hiërarchie van functies schematisch worden weergegeven.

Geschiedenis
SADT is begin jaren 70 van de vorige eeuw ontwikkeld en werd bekend doordat het MIT en de Amerikaanse luchtmacht ermee gingen werken.

Basismodel
Het basismodel voor SADT wordt gevormd door een rechthoek waarin de naam van de activiteit of het proces wordt genoemd. Aan de linkerzijde van de rechthoek wordt een inkomende pijl geplaatst, die de input voor de activiteit of het proces weergeeft (de input). Aan de rechterzijde wordt een uitgaande pijl getekend, die de outout of het resultaat toont (de output). Aan de bovenzijde van het rechthoek wordt een inkomende pijl getekend, die de gegevens toont welke nodig zijn voor de uitvoering van de activiteit of het proces (de controls). Als laatste wordt aan de onderzijde een inkomende pijl getekend, die de noodzakelijke middelen toont (de mechanisms).

mvp_sadt

 

 

 

 

 

 

 

 

Pijl Activity model Data model
Input Data die gebruikt wordt Activiteit waarmee data geproduceerd wordt
Output Data die geproduceerd wordt Data die gebruikt gaat worden
Controls Zaken die de uitvoering van de activiteit beïnvloeden Zaken die de status van de data beïnvloeden
Mechanisms Middelen en tools

 

INK Managementmodel

Wat is INK?

Het INK-managementmodel heeft als om organisaties tot de beste in hun marktsegment te laten zijn. Het model maakt het mogelijk om snel en eenvoudig relaties te leggen tussen strategie, beleid, middelen en competenties enerzijds en medewerkers, klanten, leveranciers en maatschappij anderzijds. Drie van de negen aandachtsgebieden hebben nadrukkelijk te maken met het onderzoek: management van processen, management van medewerkers en management van middelen. Deze drie aandachtsgebieden zijn het meest relevant voor het be antwoorden van de probleem stelling van dit adviesrapport. Alle drie de aandachtsgebieden kenmerken zich als organisatiegebied. Deze drie organisatiegebieden geven aan hoe de organisatie in gericht kan worden, gelet op de visie, strategie en doelstellingen van de organisatie.

Filosofie

De INK-filosofie kent 9 aandachtsgebieden en 5 fundamentele kenmerken succesfactoren. Het invoeren en toepassen van een integraal model als het INK-managementmodel is vaak een omvangrijk project. Om te voorkomen dat het model een papieren tijger wordt waarbij processen niet flexibel zijn aan veranderende omstandigheden, is er een kwaliteitssysteem als Mavim Rules nodig.

Geschiedenis

Het INK managementmodel is ontwikkeld door het INK. Het model is een afgeleid model van het EFQM ( European Foundation for Quality Management) model. Het INK is in 1991 opgericht door het ministerie van Economische Zaken, om de kwaliteit van de bedrijfsvoering van organisaties te verhogen.

Werkwijze

Na een audit van de organisatie kan bepaald worden in welke ontwikkelingsfase een organisatie zich bevindt. Het INK onderscheidt vijf fasen:

  • fase één is activiteit georiënteerd
  • fase twee is proces georiënteerd
  • fase drie is systeem georiënteerd
  • fase vier is keten georiënteerd
  • fase vijf is transformatie georiënteerd.

Na succesvolle afronding van fase twee is een organisatie proces georiënteerd te noemen.

IDEF-0

IDEF staat voor Integration Definition for Function Modelling.

Geschiedenis

Deze techniek is begin jaren zeventig ontwikkeld bij de Amerikaanse luchtmacht om te helpen bij het ondersteunen van softwareontwikkeling.

Methodiek

In IDEF worden processen met een werkwoord aangeduid en in blokken geplaatst. Pijlen verbinden de blokken met elkaar en tonen de relaties tussen de processen.

IDEF kent een drietal versies:

  • IDEF0: biedt een functiemodel voor de structurele weergave van functies, activiteiten en processen;
  • IDEF1: biedt een informatiemodel dat de structuur en semantiek van informatie beschrijft;
  • IDEF2: biedt een dynamisch model voor tijdsafhankelijke gedragskenmerken.

mvp_idef0

Flowcharts

Een flow chart (stroomdiagram) is één van de meestgebruikte manieren om processen op eenvoudige wijze te visualiseren. Meestal worden basisstroomdiagrammen gebruikt, waarbij blokjes de stappen in het proces voorstellen en waarbij met pijltjes de volgorde van de stappen wordt weergegeven. Naast basisstroomdiagrammen worden ook swim lane diagrams (functiestroomdiagrammen) en workflow diagrams (werkstroomdiagrammen) gebruikt.

Om stroomdiagrammen te kunnen lezen moet je de betekenis van de verschillende symbolen begrijpen. De meeste mensen kennen de basissymbolen zoals ‘processen’ en ‘beslissingen’. Maar er zijn veel meer symbolen. De onderstaande afbeelding toont alle standaard symbolen die in flow chart kunnen voorkomen.

Tips voor goede flowcharts

  • Stel vast waarom het stroomdiagram nodig is
    • Bedenk met welk doel je een stroomdiagram tekent. Misschien om iemand het proces uit te leggen, of om het proces te begrijpen, of om leemtes in het proces te ontdekken enz. Wat ook de reden is, het is belangrijk om de doelstelling vast te stellen.
  • Stel vast wat je doelgroep is
    • Een flow chart wordt niet alleen voor een bepaald doel, maar ook voor een bepaalde doelgroep getekend. Hou daarom rekening met zaken als detaillering, terminologie om de flow chart leesbaar te maken voor de doelgroep.
  • Stel vast of er veel actoren betrokken zijn in het proces
    • Swimlane diagrammen zijn de beste manier om de verantwoordelijkheden van de betrokken actoren (functies, rollen, afdelingen, systemen) voor iedere processtap te kunnen modelleren. Als er echter meer dan 6 á 7 verschillende actoren zijn, dan is het beter om actoren samen te voegen. Dit hangt echter wel samen met de doelgroep waarvoor je het diagram tekent.
  • Bepaal het startpunt en het eindpunt van de diagram
    • Dit lijkt triviaal, maar dit is wel bepalend voor de afbakening van het diagram. Voor de lezer is het dan duidelijk binnen welke grenzen het proces zich afspeelt. Pas daarbij op voor open eindjes; alle takken moeten uiteindelijk eindigen in de laatste stap, tenzij er verwezen wordt middels een on-page of off-page referentie naar een ander proces.
  • Breek het diagram op in meerdere flows
    • Erg lange flowcharts kunnen erg gecompliceerd worden en leiden ertoe dat de lezer details over het hoofd ziet, waarvan het juist je bedoeling was om ze bloot te leggen. Daarom is het beter om het diagram op te breken in deeldiagrammen en gebruik te maken van de referentie-symbolen. Een olifant eet je immers in stukjes.
  • Maak nuttig gebruik van kleuren
    • Door middel van het toekennen van kleuren kun je meer betekenis en informatie geven aan het diagram. Je kunt bijvoorbeeld risicovolle processtappen een rode kleur geven, zodat de lezer direct ziet waar de risico’s in het proces zitten. Voorwaarde is wel dat er een legenda wordt toegevoegd aan het diagram.

Do’s and Dont’s

  • Gebruik de juiste symbolen
    • Ieder symbool heeft een eigen betekening. Hoewel het gemakkelijk lijkt om overal een processymbool voor te gebruiken, lijdt dit eerder tot verwarring dat tot inzicht en overzicht. Maak daarom gebruik van de juiste symbolen.
  • Voorkom een inconsistente richting van de processtroom
    • De twee meest gebruikte en geaccepteerde richtingen om een stroomdiagram te tekenen zijn van boven naar beneden en van links naar rechts. Deze twee moeten echter niet gemengd worden in één diagram.
  • Gebruik geen hysterische kleuren
    • Een stroomdiagram heeft tot doel om een oplossing voor een bepaald probleem te bieden. Met dit in gedachten is het niet verstandig om je boodschap in een landschap van visuele ruis te laten verdwijnen.
  • Het formaat van de gebruikte symbolen moet consistent zijn
    • Om de boodschap van de stroomdiagram goed te laten overkomen is het verstandig om de opmaak rustig te houden door de symbolen goed geproportioneerd te houden. Een vuistregel is dat de hoogte en de breedte van een symbool in lijn zijn met de rest van de symbolen. Uiteraard geldt deze regel niet voor symbolen die doelbewust klein moeten zijn, zoals connectoren.
  • Zorg voor een consistent gebruik van het wiebertje
    • Vaak het wiebertje niet goed gebruikt. Conventie is dat de TRUE voorwaarde aan de onderzijde van het wiebertje komt en de FALSE voorwaarde uit de rechterkant.
  • De ruimtes rond de symbolen moeten gelijkmatig zijn
    • Om stroomdiagrammen er professioneler te laten uitzien is het belangrijk om de ruimtes rond de symbolen overal even groot te laten zijn. Uitzondering wordt gevormd door het beslissingssymbool dat meestal meer ruimte nodig heeft om de labels aan de takken te kunnen tonen.
  • Hou het stroomdiagram leesbaar
    • Vaak wordt een gedetailleerd stroomdiagram verkleint omdat het moet passen op één A4-tje of A3-tje. Dat is echter niet verstandig. Het is beter om het diagram over meerdere pagina’s te verdelen. Daarnaast is het ook een optie om activiteiten te groeperen.
  • Koppel diagrammen in plaats van ze op één pagina te proppen
    • Door middel van twee beschikbare symbolen – de on-page- en off-page referentie – kunnen diagrammen eenvoudig gekoppeld worden. Dat is beter dan ze op één pagina proberen te krijgen.
  • Maak alternative flows duidelijk
    • In bepaalde flowcharts gaan normal flows en alternative flows uit elkaar lopen. Het is dan zaak om de flows door middel van visuele ondersteuning te kunnen onderscheiden. Bijvoorbeeld door de alternative flows van een stippellijn te voorzien.
  • Pas op voor lussen
    • Processen kunnen niet oneindig blijven doorlopen. Waak ervoor dat er geen oneindige lussen in het proces zitten.
  • Zorg voor duidelijke omschrijving
    • Als een processtap meer detail nodig heeft, plaats dat dan in een voetnoot, een call out of eventueel een apart document. Maar doe dit niet in de stap zelf.
  • Voeg een legenda toe
    • Goed gebruik is om een legenda toe te voegen aan het stroomdiagram waarin de gebruikte symbolen toegelicht worden.
  • Voorkom onnauwkeurigheid
    • Controleer het diagram op onnauwkeurigheid of – nog beter – laat een materiedeskundige deze toets uitvoeren voordat het diagram gepubliceerd wordt.
  • Hoe je aan één detailniveau
    • Het is het beste om één detailniveau aan te houden binnen één diagram; bijvoorbeeld een high-level, mid-level of gedetailleerde stroomdiagram.

Symbolen

mvp_flowcharts

EPC

EPC (event-driven process chain; gebeurtenisgestuurde procesketen; Ereignisgesteuerte Processkette) is een modelleringsmethode waarmee de structuur van de besturingsstroom voor een bedrijfsproces wordt aangegeven als een keten van gebeurtenissen en functies.

Geschiedenis

De methode is in 1992 door prof Scheer et al. van de Universiteit van Saarland ontwikkeld binnen het ARIS framework.

Gebruik

EPC diagrammen worden met name gebruikt bij de implementatie van Enterprise Resource Planning. Daarnaast wordt EPC gebruikt om processen te modelleren, analyseren en te verbeteren. Tools EPC diagrammen worden o.a. toegepast in : SAP R/3-modelleerconcepten voor business engineering resource planning identificeren van mogelijke verbeteringen in bedrijfsprocessen ARIS (IDS Scheer)

mvp_epc_1

Elementen

De belangrijkste onderdelen van een EPC-diagram zijn:

Functions. In een EPC diagram komt een functie overeen met een uitgevoerde activiteit. De grafische weergave van een functie is een rechthoek met afgeronde hoeken.

mvp_epc_2

 

 

 

Events. Gebeurtenissen vinden plaats voordat of nadat een functie is uitgevoerd. Functies worden gekoppeld door gebeurtenissen.

mvp_epc_3

 

 

 

Connectors. Verbindingen verbinden activiteiten en gebeurtenissen. Er zijn drie soorten verbindingen: AND (en), OR (of) en XOR (exclusieve OR). Door middel van deze connectoren kunnen processen parallel of via alternatieve paden uitgevoerd worden. Connectors worden weergeven door middel van cirkels.
mvp_epc_4

 

 

Control flows. Ieder EPC diagram bevat meerdere control flow connecties. Deze worden gebruikt om events, functions en connectors te koppelen. Zij worden in EPC diagrammen weergegeven door gestreepte pijlen.

Daarnaast kunnen er in een EPC diagram de volgende elementen voorkomen:

  • Informatie, materiaal, middelen: dit zijn objecten die input leveren aan een processtap of de output vormen van een processtap. Zij worden getekend als rechthoeken die gekoppeld zijn aan functies.
  • Organisatorische eenheden: dit zijn personen of afdelingen die verantwoordelijk zijn voor de uitvoering van een bepaalde functie. Zij worden weergegevn door ellipsen met een verticale lijn.
  • Ondersteunde systemen: technische ondersteuning (systemen en applicaties). Zij worden weergegeven door rechthoeken met verticale lijnen aan de zijkanten.

Conventies

  • Een EPC begint en eindigt altijd met een event
  • Na een event kunnen meerdere functies volgen en na een event kunnen er een of meer functies volgen.
  • Tussen de start en eindevent moeten altijd regels tussen zitten: OR, XOR of AND.
  • Iedere functie of event heeft maximaal 1 input en 1 output boog.
  • EPC elementen kunnen op redelijke vrije wijze gecombineerd worden.
  • Er is tenminste een start event en tenminste een end event
  • Events hebben tenminste 1 inkomende 1 uitgaande pijl
  • Events hebben tenminste 1 incident pijl
  • Functions hebben altijd maar 1 inkomende pijl en 1 uitgaande pijl
  • Er zijn geen losse elementen in de diagram
  • Connectors hebben of 1 inkomende pijl of meerdere uitgaande pijlen en vice versa
  • Tussen twee events kan geen directe lijn aanwezig zijn
  • Tussen twee functies kan er geen directe lijn zijn Start en end event zijn uniek
  • Een event kan nooit gevolgd worden door een connector (XOR, OR of AND)

BPMN (Business Process Modelling and Notation)

Omschrijving

  • Veelgebruikte internationale standaard voor procesmodelering.
  • Biedt de mogelijkheid om business processen grafisch weer te geven door middel van een Business Process Diagram (BDP)
  • Maakt gebruik van flow charting technieken die vergelijkbaar zijn met de Activity Diagrams van Unified Modelling Language
  • Biedt de mogelijkheid om Business Process Execution Language (BPEL) te leveren

mvp_bpmn

Elementen

  • Activity (Activiteit) : Een activiteit is werk dat wordt uitgevoerd in een bedrijfsproces. Een activiteit enkelvoudig of samengesteld zijn. De activiteiten die een onderdeel van een Process Model zijn een deelproces of een taak. Activiteiten worden weergegeven door middel van afgeronde rechthoeken. Zij kunnen eenmaal uitgevoerd worden of interne lussen vertonen.
  • Sub-process (Deelprocessen) : door middel van deelprocessen kunnen bedrijfsprocessen hiërarchisch uitgewerkt worden. Een deelproces bestaat een of meer activiteiten, die al dan niet getoond worden in een diagram. In een ingeklapte versie van een deelproces zijn de details van proces niet zichtbaar in het diagram. Als een activiteit een „plus”-teken heeft, dan geeft aan dat er een deelproces bestaat. Voor een uitgeklapte versie van een activiteit zijn de details van het proces zichtbaar. Er zijn twee typen deelprocessen: Embedded en Independent (herbruikbare)
  • Task (Taak) : Een taak is een enkelvoudige activiteit die onderdeel uitmaakt van een proces. Een taak wordt gebruikt als het werk in de proces niet verder gedecomponeerd kan worden. Er kunnen pictogrammen worden toegevoegd aan Taken om de specifieke aard van de taak te kunnen aangeven. Transaction: dit is een vorm van een sub process waarin alle samengevoegde activiteiten behandeld moeten worden als een ding.
  • Event (Gebeurtenis): Een gebeurtenis vindt plaats tijdens de uitvoering van een bedrijfsproces. Deze gebeurtenissen hebben invloed op het verloop van de procesflow: zij starten, onderbreken of beëindigen een proces. Events hebben doorgaans een trigger en een resultaat. Er zijn twee soorten triggers: catching – dit is een externe trigger; throwing – dit is een trigger veroorzaakt door een output. Een event wordt gepresenteerd door middel van een cirkel, waarbij de vorm van de cirkel het type event voorstelt.
    • Start Events: Een Start Events geeft aan waar een proces begint. Er zijn verschillende triggers die de specifieke startsituatie aangeven. Zogenaamde none start events geven het begin van een deelproces aan. Zij worden ook gebruikt als er sprake is van een ongedefinieerd start van het proces. Als in een diagram een multiple start event wordt getoond, dan betekent dit dat ieder van de triggers het proces kunnen starten. Intermediate Events: intermediate Events vinden plaats nadat een proces is gestart en voordat een proces is beëindigd.Er zijn verschillende ‘triggers’ die de specifieke situatie van de gebeurtenis voorstellen. Intermediate events kunnen in een normaal proces voorkomen of kunnen worden gekoppeld aan de grens van een activiteit.
    • Intermediate Events (Normal Flow): Gebeurtenissen die geplaatst worden binnen een procesflow zijn gebeurtenissen die tijdens de normale uitvoering van de procesflow plaatsvinden. Zij kunnen een reactie op een gebeurtenis weergeven, zoals de ontvangst van een bericht. Maar zij kunnen ook de creatie van een gebeurtenis weergeven, zoals het verzenden van een bericht.
    • Intermediate Events (Attached to Boundary): Een gebeurtenis die aan een activiteit gekoppeld is geeft aan dat de activiteit onderbroken moet worden op het moment dat de gebeurtenis getriggerd wordt. Zij kunnen zowel gekoppeld worden aan taken en aan deelprocessen en worden gebruikt voor fout-afhandeling, de verwerking van uitzonderingssituaties en voor compensatie.
  • End Events (Eindgebeurtenissen): Eindgebeurtenissen geven aan waar een proces zal eindigen. Er zijn verschillende resultaten mogelijk.
  • Gateways (Poort): Door middel van gateways kan men sturen hoe verschillende processtromen samenkomen en divergeren binnen een bedrijfsproces. Zij worden gerepresenteerd door middel van een diamantvorm. Er worden interne markeringen gebruikt om het gedrag van een poort weer te geven. Een poort wordt gebruikt op het moment dat een proces bestuurd moet worden.
    • Exclusive Gateways XOR (Besluiten): Besluiten zijn plaatsen in het bedrijfsproces waar de processtroom twee of meer alternatieve paden uit kan gaan. Slechts één van de mogelijke paden kan ingeslagen worden als het proces wordt uitgevoerd (exclusive=uitsluiten). Er zijn twee typen besluiten: Data (gegevens), bijvoorbeeld voorwaardelijke besluiten gebaseerd op bedrijfsregels. Dit is de meest voorkomende vorm van Besluiten. Zij kunnen getoond worden met en zonder interne X, waarbij die zonder X de meest voorkomende is. Events (gebeurtenissen), zoals de ontvangst van een alternatief bericht. De alternatieve paden kunnen ingeslagen worden op basis van gebeurtenissen in plaats van op basis van voorwaardelijke condities.
    • Inclusive Gateways OR (Besluiten): Inclusive Gateways Decisions spelen een rol als er mee dan één mogelijke uitkomsten mogelijk zijn. De Inclusive Gateway Decision wordt weergegeven met een „O”. Zij worden meestal gevolgd door een corresponderende samenvoegde inclusive gateway. Complexe Gateways (Besluiten) : Complex Gateways zijn besluiten waar een ingewikkelder gedrag aan ten grondslag ligt. Er wordt een „*” gebruikt om dit soort gateways weer te geven. Zij kunnen zowel voor samenvoegde als voor splitsende gedrag gebruikt worden.
  • Connectors: events, activities en gateways worden gekoppeld door middel van connectors. Hiervan zijn drie soorten te onderscheiden: sequence flows die aangeven in welke volgorder activiteiten uitgevoerd moeten worden message flows die aangeven welke berichten er tussen de organisatorische eenheden verzonden worden associations die artefacten (documenten en dergelijke) koppelen aan objecten.
  • Swim Lanes : visuele weergave gebaseerd op groepering van de verantwoordelijkheid voor de uitvoering van activiteiten op basis van personen, afdelingen of systemen.
    • pool: geeft de belangrijkste deelnemers in een proces weer en bestaat uit minimaal 1 baan
    • baan: activiteiten die door een functie of een rol uitgevoerd worden.
  • Artefacten: worden gebruikt om meer gedetailleerde informatie in het model toe te voegen. data object: geeft aan welke informatie of gegevens nodig zijn in een activiteit of die opgeleverd worden door die activiteit groep: wordt gebruikt om verschillende activiteiten samen te voegen annotation: geeft extra informatie om het proces beter te kunnen begrijpen