agil bmp af thomas hildebrandt, itu
DESCRIPTION
Oplægget blev holdt ved arrangementet "Get F'IT september 2013: Agil Business Process Management i finans", der blev afholdt den 24. september 2013.TRANSCRIPT
IT UNIVERSITETET I KØBENHAVN
Agil Business Process Management- i FinansThomas HildebrandtLektor, PhD
Leder af gruppen for Proces- & Systemmodellerved IT Universitetet i København og Interessegruppen for processer og IT ved Infinit
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
IT-‐stø3et sagsbehandling
2
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
IT-‐stø3et sagsbehandling1. Processen skal skride frem så
effektivt som muligt
2
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
IT-‐stø3et sagsbehandling1. Processen skal skride frem så
effektivt som muligt
2. Alle regler/love skal overholdes
2
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
IT-‐stø3et sagsbehandling1. Processen skal skride frem så
effektivt som muligt
2. Alle regler/love skal overholdes
3. Skal kunne forstås af sagsbehandleren
2
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
IT-‐stø3et sagsbehandling1. Processen skal skride frem så
effektivt som muligt
2. Alle regler/love skal overholdes
3. Skal kunne forstås af sagsbehandleren
4. Skal støtte samarbejde mellem flere aktører
2
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Agil BPM i Finans
3
Hvordan sikres at processerne passer til virkelighedens skiftende
regler og produkter ? og arbejdsgange ?
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
BPM Metoden
4
• Beskriv “as-is” og “to-be” processer som flow-diagrammer
• Adskil flow-diagram fra beslutningssregler
• Sæt strøm til processen med et standard BPM (Business Process Management) System
• Overvåg og tilpas processer
However, the focus is not on data but on process-related information (e.g., theordering of activities). Process mining is also related to monitoring and businessintelligence [41].
8 ConclusionProcess-aware information systems (PAISs) follow a characteristic life-cycle. Fig-ure 13 shows the four phases of such a life-cycle [7]. In the design phase, theprocesses are (re)designed. In the configuration phase, designs are implementedby configuring a PAIS (e.g., a WFMS). After configuration, the enactment phasestarts where the operational business processes are executed using the system con-figured. In the diagnosis phase, the operational processes are analyzed to identifyproblems and to find things that can be improved. The focus of traditional work-flow management (systems) is on the lower half of the life-cycle. As a result thereis little support for the diagnosis phase. Moreover, support in the design phase islimited to providing an editor while analysis and real design support are missing.
Figure 13: PAIS life-cycle.
In this article, we showed that PAISs support operational business processesby combining advances in information technology with recent insights from man-agement science. We started by reviewing the history of such systems and thenfocused on process design. From the many diagramming techniques available, wechose one particular technique (Petri nets) to show the basics. We also emphasizedthe relevance of process analysis, e.g., by pointing out that 20 percent of the morethan 600 process models in the SAP reference model are flawed [24]. We also
26
analyse &diagnose
procesdesign
systemkonfiguration
procesudførsel
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
BPM Metoden
4
• Beskriv “as-is” og “to-be” processer som flow-diagrammer
• Adskil flow-diagram fra beslutningssregler
• Sæt strøm til processen med et standard BPM (Business Process Management) System
• Overvåg og tilpas processer
However, the focus is not on data but on process-related information (e.g., theordering of activities). Process mining is also related to monitoring and businessintelligence [41].
8 ConclusionProcess-aware information systems (PAISs) follow a characteristic life-cycle. Fig-ure 13 shows the four phases of such a life-cycle [7]. In the design phase, theprocesses are (re)designed. In the configuration phase, designs are implementedby configuring a PAIS (e.g., a WFMS). After configuration, the enactment phasestarts where the operational business processes are executed using the system con-figured. In the diagnosis phase, the operational processes are analyzed to identifyproblems and to find things that can be improved. The focus of traditional work-flow management (systems) is on the lower half of the life-cycle. As a result thereis little support for the diagnosis phase. Moreover, support in the design phase islimited to providing an editor while analysis and real design support are missing.
Figure 13: PAIS life-cycle.
In this article, we showed that PAISs support operational business processesby combining advances in information technology with recent insights from man-agement science. We started by reviewing the history of such systems and thenfocused on process design. From the many diagramming techniques available, wechose one particular technique (Petri nets) to show the basics. We also emphasizedthe relevance of process analysis, e.g., by pointing out that 20 percent of the morethan 600 process models in the SAP reference model are flawed [24]. We also
26
analyse &diagnose
procesdesign
systemkonfiguration
procesudførsel
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
BPM Metoden
4
• Beskriv “as-is” og “to-be” processer som flow-diagrammer
• Adskil flow-diagram fra beslutningssregler
• Sæt strøm til processen med et standard BPM (Business Process Management) System
• Overvåg og tilpas processer
However, the focus is not on data but on process-related information (e.g., theordering of activities). Process mining is also related to monitoring and businessintelligence [41].
8 ConclusionProcess-aware information systems (PAISs) follow a characteristic life-cycle. Fig-ure 13 shows the four phases of such a life-cycle [7]. In the design phase, theprocesses are (re)designed. In the configuration phase, designs are implementedby configuring a PAIS (e.g., a WFMS). After configuration, the enactment phasestarts where the operational business processes are executed using the system con-figured. In the diagnosis phase, the operational processes are analyzed to identifyproblems and to find things that can be improved. The focus of traditional work-flow management (systems) is on the lower half of the life-cycle. As a result thereis little support for the diagnosis phase. Moreover, support in the design phase islimited to providing an editor while analysis and real design support are missing.
Figure 13: PAIS life-cycle.
In this article, we showed that PAISs support operational business processesby combining advances in information technology with recent insights from man-agement science. We started by reviewing the history of such systems and thenfocused on process design. From the many diagramming techniques available, wechose one particular technique (Petri nets) to show the basics. We also emphasizedthe relevance of process analysis, e.g., by pointing out that 20 percent of the morethan 600 process models in the SAP reference model are flawed [24]. We also
26
analyse &diagnose
procesdesign
systemkonfiguration
procesudførsel
?
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
En Business Process-‐GPS?
5
En GPS baseret på flow-diagrammer ville kunne vise ruter
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
En Business Process-‐GPS?
5
En GPS baseret på flow-diagrammer ville kunne vise ruter- for destinationer og veje der fandtes da den blev lavet!
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
En Business Process-‐GPS?
5
En GPS baseret på flow-diagrammer ville kunne vise ruter- for destinationer og veje der fandtes da den blev lavet!og ikke dokumentere reglerne
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
En typisk låneproces ?
6
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
En typisk låneproces ?
6
Flow diagrammet er rigidt
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
En typisk låneproces ?
6
Flow diagrammet er rigidt - og beskriver ikke forretningsreglen der skal overholdes
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
7
- vi forventer, at kunne vælge et vilkårligt mål, afvige fra ruten og få foreslået en ny - og at kortet holdes up-to-date
En Business Process-‐GPS
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
7
- vi forventer, at kunne vælge et vilkårligt mål, afvige fra ruten og få foreslået en ny - og at kortet holdes up-to-date
En Business Process-‐GPS
men også sikre at vi når effektivt i mål
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
8
Skal vi da designe en proces, der beskriver alle mulige veje ??
En Business Process-‐GPS
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Låneproces med flere veje
9
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Låneproces med flere veje
9
nej
ja
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Låneproces med flere veje
9
nej
ja
Sværere at overskue!
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Låneproces med flere veje
9
nej
ja
Sværere at overskue!og reglen er stadig implicit
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Processer vs Regler
10
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Moderne BPMS tillader at adskille beslutningsregler fra flow:
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Processer vs Regler
10
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Moderne BPMS tillader at adskille beslutningsregler fra flow:
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Processer vs Regler
10
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Moderne BPMS tillader at adskille beslutningsregler fra flow:
Men hvad med at erstatte flowet helt med regler?
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Processer vs Regler
10
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Moderne BPMS tillader at adskille beslutningsregler fra flow:
Men hvad med at erstatte flowet helt med regler?Kreditvurdering med rating A skal forelægge før lån kan gives
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Processer vs Regler
10
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Moderne BPMS tillader at adskille beslutningsregler fra flow:
Men hvad med at erstatte flowet helt med regler?Kreditvurdering med rating A skal forelægge før lån kan gives Dokumentation skal modtages før lån kan gives
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Processer vs Regler
10
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Moderne BPMS tillader at adskille beslutningsregler fra flow:
Men hvad med at erstatte flowet helt med regler?Kreditvurdering med rating A skal forelægge før lån kan gives
Rådgivning skal udføres før lån kan gives Dokumentation skal modtages før lån kan gives
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Processer vs Regler
10
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Moderne BPMS tillader at adskille beslutningsregler fra flow:
Men hvad med at erstatte flowet helt med regler?Kreditvurdering med rating A skal forelægge før lån kan gives
Rådgivning skal udføres før lån kan gives Hvis lån gives skal kreditvurdering gentages efter et år
Dokumentation skal modtages før lån kan gives
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Processer vs Regler
10
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
5 | P a g e
Figure 3 Procedural vs. Declarative Solutions
Source: The Decision Model (von Halle & Goldberg) © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.)
The Rule Family, by definition, implies no particular sequence among the conditions to be tested. The Rule Family in Figure 3 also indicates via the “?” that there are other possible combinations of conditions to consider. The Rule Family can contain as many rows as are needed to reach the correct conclusion. For that matter, it can contain additional columns if other conditions are needed to determine a person’s credit rating. The Rule Family table also contains business logic for the logic not modeled in the business process models of option 1 and option 2. These include the adjudication of the credit rating for all values of person’s debt and employment history other than “low” and “good.” Incorporating these into the business process model rather than in the Decision Model would have enlarged and added unnecessary complexity and unnecessary sequence to the business process model. To change or add conditions in such a business process model is far more cumbersome than doing so in the corresponding Rule Family.
Immediate observations are that Option 3 is an improvement over Options 1 and 2 because it:
• Allows a much simpler business process model
Option 1
Option 2
Option 3Rule
Pattern
1 is Low is Good = "A"
1 is Low is Bad = ?
1 is High is Good = ?
1 is High is Bad = ?
Conditions Conclusion
Person Debt
Person Employment
History
Person Credit
Rating
Process Model Rule Family Table Decision Model Diagram
Moderne BPMS tillader at adskille beslutningsregler fra flow:
Men hvad med at erstatte flowet helt med regler?Kreditvurdering med rating A skal forelægge før lån kan gives
Rådgivning skal udføres før lån kan gives Hvis lån gives skal kreditvurdering gentages efter et år
og lade it-systemet beregne vejen baseret på reglerne?
Dokumentation skal modtages før lån kan gives
Tuesday, September 24, 13
Thomas Hildebrandt, [email protected]
IT UNIVERSITETET I KØBENHAVN
Finance IT Tuesday
Regelbaseret hændelsesflow• Beskriv hændelser, afhængigheder og krav
(iflg. lovgivning) i stedet for proceduren
• Start med målet (godkend lån) - identificer forudsætninger og opfølgende handlinger
• IT-værktøj kan på vilkårligt tidspunkt beregne en procedure for den “bedste vej”
• Med det rigtige valg af “modelsprog” kan vi tillade ændringer i model på vilkårligt tidspunkt og tage systemet i brug meget tidligere
11
Tuesday, September 24, 13