Oleg Skrynnik schrijft in het handboek DevOps Handboek het volgende over waardestromen:

Waardestroom

Een van de belangrijkste concepten van DevOps, geleend van Lean productie, is de waardestroom (value stream).

(...)

Het is nuttig om het werk van een organisatie te beschouwen als het creëren van waarde als reactie op het verzoek van een consument. De acties die worden uitgevoerd om aan de vraag te voldoen staan opgesteld in een reeks met de naam 'waardestroom'. Doorgaans verwerkt een organisatie een verscheidenheid aan verschillende verzoeken. ... Er zijn dus veel waardestroom in het bedrijf.

Werken aan stroomvisualisatie staat bekend als ´value stream mapping´. Het begint bij de selectie van een product: soms het product met de grootste mogelijkheden voor optimalisatie; soms het product dat de snelste significante verbeteringen belooft, en tegelijkertijd materiaal verstrekt om de methode te bestuderen.

Mapping gebeurt in twee stappen: eerst wordt een as-is ('zoals het is') plaatje gemaakt en vervolgens een to-be ('zoals het moet worden'). De studie van de 'to-be map' is om twee redenen belangrijk.

Ten eerste helpt het om lokale optimalisatie te vermijden ... Ten tweede maakt begrip van de gewenste eindtoestand het mogelijk om een realistisch verbeteringsmechanisme op te zetten, met een zo duidelijk mogelijke richting van verbetering.

In feite is de value stream mapping exercitie eenvoudig: men moet eerst de belangrijkste stappen van de aanvraagverwerking identificeren, het werk documenteren dat bij elk van deze wordt uitgevoerd, en ervolgens deze stappen in de juiste volgorde van creatie voor het resultaat rangschikken.

Een van de moeilijkheden is het buitensporige detailniveau, wanneer de resulterende map niet op één blad past. [De tip is] om het aantal mapblokken te beperken tot vijftien om verder te werken met de map gemakkelijker te maken.

De tweede moeilijkheid is om het eens te worden over wat de precieze stappen zijn, en hoe en door wie ze worden uitgevoerd. In sommige organisatie bestaat er geen algemeen begrip van het proces, wat leidt tot vele uren van geschillen.

Bron: DevOps Handboek, Oleg Skrynnik

Jan Vanthienen & Stijn Goedertier maken in hun artikel Bedrijfsregels voor conforme en flexibele bedrijfsprocessen onderscheid in vier soorten bedrijfsregels:

[Men] kan ... vier soorten bedrijfsregels identificeren: integriteitsbeperkingen, afleidingsregels, rechten en plichten en reactieregels. Elk van deze vier soorten speelt een belangrijke rol in het modelleren van bedrijfsprocessen.

(1) Integriteitsbeperkingen

Integriteitsbeperkingen leggen beperkingen op aan de domeinen van bedrijfsconcepten. In feite leiden integriteitsbeperkingen tot precondities voor specifieke activiteiten in bedrijfsprocessen en/of datavalidatieregels
voor de in een proces uitgewisselde data. In tegenstelling tot wat vaak gebeurt, mag de naleving van deze integriteitsregels in bedrijfsprocessen niet gemodelleerd worden als een stap in het bedrijfsproces. Integriteitsregels moeten autonome bedrijfsregels blijven. Bij uitvoering moet het informatiesysteem autonoom beslissen wanneer de naleving van een bepaalde integriteitsbeperking bewaakt moet worden. Figuur 3 illustreert bijvoorbeeld de vereenvoudiging die door te voeren is, wanneer de logica dat alleen klanten ouder dan 18 een order kunnen plaatsen uit het procesmodel gehaald wordt.

(2) Afleidingsregels

Afleidingsregels definiëren bedrijfsconcepten in termen van andere bedrijfsconcepten. De logica van afleidingen moet niet in BPMN gemodelleerd worden, maar is een geheel van autonome regels. Bij uitvoering moet het informatiesysteem beslissen wanneer de toepassing van een afleidingsregel aan de orde is. In vele BPM-producten bestaat nu reeds de mogelijkheid om afleidingsregels afleidingsregels afzonderlijk te modelleren en uit te voeren. Dit leidt tot meer flexibiliteit: de afleidingsregels veranderen vaker dan het onderliggend proces.

(3)  Rechten en plichten van bedrijfsinterne en - externe actoren in een bedrijfsinteractie

De derde soort bedrijfsregels leggen de rechten en plichten vast van bedrijfsinterne en -externe actoren in een bedrijfsinteractie. Men kan aantonen dat deze rechten en plichten beperkingen opleggen aan de volgorde van activiteiten in een bedrijfsproces. Zo legt de volgende bedrijfsregel een partiële volgordebeperking op aan de taken aanvaarden, betalen en verzenden in het order-to-cash proces: “expeditie mag alleen goederen verzenden, wanneer het gerelateerde order officieel aanvaard en betaald is.” Van de zes mogelijke volgorden, zijn er volgens deze regel slechts twee toelaatbaar.

(4) Reactieregels

In procesmodellen bepalen reactieregels de reacties op gebeurtenissen binnen de keuzevrijheid van de eigen rechten en verplichtingen [2]. Daarnaast bepalen ze ook wat er moet gebeuren indien één van de business partners de verplichtingen niet nakomt of wanneer integriteitsregels met de voeten getreden worden. De volgende reactieregel, bijvoorbeeld, geldt vanuit het standpunt van de verkoper: “Wanneer de koper niet betaalt na 30 dagen, moet een bericht “nalatigheid betaling” naar de kredietverzekeraar verstuurd worden.”

Bron: Bedrijfsregels voor conforme en flexibele bedrijfsprocessen, Stijn Goedertier & Jan Vanthienen