Review the decision points with the
stakeholders and set the priority on each decision point.
Depending of the complexity of the business process the team should prioritize which rule harvesting to tackle
first. A good practice is to start with a simple, well understood decision point, to help training the team on the
practice, but keep also in mind that the management wants to see the business value of what the team is working on. So
a decision point that is important by bringing a value, should be in the top of the list.
If needed review the business context to keep the business needs and reassess the priority accordingly. It is important
to start by extracting rules that is bringing immediate value to the business users, to get their buy in, and
motivation to continue to do this painful work. It may be relevant to start with the most complex business
scenario. It helps convincing business users and rapidly enriches the conceptual data model. It is important to set the
expectation among the stakeholders that not all the rules will be discovered during this phase. The goal is to complete
a rule set up to 40-60% to have some tangible decision on standard business event to process. The rule writers or the
development team will enhance the Rule Set later on.
One
good practice is to implement the decision logic using rules for the main stream of business processing, letting the
exceptions to the human. It will be always possible to add rules to manage some newly discovered exception later
on. A typical case is in the underwriting type of rules. An expert will quickly extract some basic rules that
always need to be true to accept the Application. As soon as the discussions start to be around the "but there is a
case where ..." a lot of new rules will arrive.
|
