Managing Inter-Organizational Business Policies & Practices
This use case is about two things:
- Interchange of rules between organizations. Interchanges may occur between different organizations, or between different units in the same organization. For example, in the EU-Rent case study, EU-Rent HQ distributes rules to its operating companies in different countries. Operating companies also obtain rules from advisors within their countries, such as trade associations or solution providers.
- Interchange of rules that support business policies and practices.
Some rules that support business policies and practices cannot be immediately executed by a rules execution IT system. They need something from a person, e.g. a decision or confirmation of an action, before the rules execution system can deal with them.
For example, at the end of a EU-Rent rental, the car may be left at, say, an airport car park rather than at the EU-Rent branch designated in the rental contract. EU-Rent calls this an “off-site return”. There are rules to deal with it. Two of them are:
- “For each off-site return a penalty charge must be added to the rental cost”. This is immediately executable.
- “For each off-site return the car must be recovered within 24 hours”. Somebody from EU-Rent has to recover the car, and confirm to the IT system that this has been done. The rule executed by the IT system is: “At 24 hours after the end of any rental, if the rented car has ‘off-site’ status then notify the branch manager”.
When rules arrive via its RIF client, EU-Rent’s rules execution system needs to be able to recognize which ones can be immediately executed, and which have first to be routed for some human action. This will require an item of RIF metadata to indicate whether an incoming rule is immediately executable or not.
To deal with the human side of rules, where required actions might not be carried out, the use case needs two deontic operators - obligation and permission - for rules such as:
- “It is permitted that a rental car is dropped off at a branch other than the rental return branch” (EU-Rent could charge a penalty, but the branch would not refuse to accept the car).
- “It is obligatory that a rented car left off-site at the end of a rental is recovered within 24 hours after drop-off notification”
Note that some deontic rules are directly handled by the IT system. For example:
- “It is obligatory that for each rental, a specific car is assigned to it at the start of EU-Rent working day of the date of the rental’s pick-up date/time”
It could be that on occasional days there aren’t enough cars. There were in the plans when rental bookings were taken, but some customers have not returned their cars on time, some cars have been damaged, some have higher mileage than anticipated and need servicing, etc. etc. The rules execution system cannot resolve the real-world problem, but has to report the failure to comply with the rule.
Rules about rules are also needed. For example:
- “For each EU-Rent building in which smoking is prohibited, ‘no smoking’ notices must be displayed”
The IT system could maintain ‘smoking status’ for buildings, and require reporting of “no smoking” notices after building inspections.
One requirement for rules about rules is for enforcement of deontic rules, in the form: “It is obligatory that if an obligation is not met, a consequence will ensue”. For example, suppose that the rule above was named the "no smoking notices" rule. Then:
- “If any EU-Rent building with 'prohibited' smoking status is out of compliance with the 'no smoking notices' rule for 72 hours, then the building's smoking status must be changed to ‘permitted’ and the Human Resources Department notified”
This gives us a rule about a rule about a rule.
The RIF will have capability to exchange fact bases between organizations, so that what they mean by “customer”, “rental car”, “customer rents car”, “rented car is picked up from branch”, etc. is consistent when they apply exchanged rules to these concepts and fact types. Given a fact base, this use case needs two alethic operators - necessity and possibility - to structure it. For example:
- “It is necessary that each rental has exactly one each of: customer, car group, pick-up branch, pick-up date/time, return branch, return date/time”
“It is possible that any of the following are changed for a rental: car group, pick-up date/time, return branch, return date/time” (there would be additional constraints, e.g. pick-up time couldn’t be changed after the car had been picked up).
It’s likely that each of these would be split into distinct atomic rules for the rule execution system.
Exchange of rules between organizations also requires rule sets. Organizations have many rules and need to manage them at a broader level than individual rules. Typically, rules are grouped into sets around events, e.g. “At rental pick-up time …”, or around concepts, regardless of events, e.g. “A rental car …”
Since the use case is about interchange of rules that support business policy and practice, it would be valuable for the RIF to support the kinds of rules that would be expressed in SBVR. The following six types (using SBVR terms for the rule categories) should do it, although they will probably need to be expressed in FOL to satisfy everyone in the RIF WG:
- Simple Quantification, e.g. “It is necessary that each rental car has exactly one vehicle identification number.”
- Implication, e.g. “If the drop-off location of a rental is not the return branch of the rental then the rental must incur a location penalty charge.”
Aggregation, e.g. “The average of age of rental cars owned by each local area must be less than 5 years”. (The projection "local area owns rental car and rental car has age" is aggregated into "multiset has average")
Proposition Nominalization, e.g. “Each new customer must be informed that the New Customer Discount is available to him.”(The proposition "new customer discount is available to new customer" is nominalized in the fact type "person is informed of proposition")
Answer Nominalization, e.g. “Each new customer must be informed what special offers are available to him.”(The projection "special offers available to customer" is nominalized as a proposition in the fact type "person is informed of proposition")
Objectification, e.g. “Each rental car must be tested before it is purchased.” ("rental car is purchased" and "rental car is tested" are objectified as actualities in the fact type "actuality occurs before actuality")
Summary of Requirements
This use case needs the following
- A RIF metadata item to indicate that a rule can be directly executed (presumably the default), or needs to be routed to a person for some action before it can be executed. It would also be useful to have this metadata available for rule sets.
- Four modal operators:
- Alethic: necessity and possibility
- Deontic: obligation and permission
- “Rules about rules”
- Adoption by the RIF of a standard for interchange of fact bases
- Rule sets
- SBVR rules of the kinds described above - or their (sorted) FOL equivalents.
Scenario
This scenario uses the (fictitious) car rental company, EU-Rent, used as the SBVR case study. The EU legislation discussed is also fictitious.
EU-Rent’s corporate HQ deals with Carwise, a consultancy company with expertise in managing fleets of vehicles. One service Carwise offers is negotiating with EU regulators to clarify regulation and then providing relevant rules to its customers.
An EU regulator issues a directive dealing with insurance for vehicles owned by companies. One of the rules Carwise provides to EU-Rent is:
- “Every car rental must be insured for damages to third parties”
As well as insuring the rentals, EU-Rent has to maintain insurance schedules as proof that it has done so. It decides that it will maintain them electronically. Carwise provides EU-Rent with rules for electronic signatures for insurance schedules, e.g.
- “For electronic filing, a schedule must have electronic signatures from two EU-Rent employees of at least manager grade”
EU-Rent HQ decides to include third-party insurance in the basic price of each rental so that there is no possibility that it can be omitted. HQ provides rules to EU-Rent operating companies within EU countries:
“Each rental rate quoted to customers (e.g. on published tariffs, in web bookings) must include the cost of third party liability insurance”
- “Cost of third party liability insurance must not be disclosed to customers”
It also provides the rules for electronic compliance (obtained from Carwise) to the operating companies.
EU-Rent operating companies also use consulting companies for expertise within their countries. In the UK, Autolaw provides EU-Rent with the rules for placing aggregate insurance for fleets of vehicles:
- “For fleet insurance of more than 200 vehicles, at most 40% of the risk may be placed with any one insurer”
Autolaw also provides the rules for calculating tax liability for aggregated insurance, e.g.:
- “For each rental, the tax on aggregated insurance is 1.5% of simple cost of rental
- Simple cost of rental is the cost for use of the car including compulsory insurance, but excluding extra equipment, additional drivers, optional insurances and VAT”