How to Develop and Document Business Policies and Decision Logic?

How to Develop and Document Business Policies and Decision Logic?

Changing regulations, business strategies and compliancy standards require new business policies to be developed constantly. Consequently, new decisions will be made which need to be managed properly. However managing these new decisions is (of course) not without challenge. The field of decision management has steadily become more popular – first focusing on it being a better way to manage business rules, but lately shifting its focus to predictive analytics.

However, if we w ant to implement decision management with proper analytical power, consistency and with good result, the underlying input (data, business rules, decision logic but also business policies) needs to be up to date. Developing and documenting business policies in such a fashion that the policy is effective but also can be easily transformed into decision logic (and thus function as input for a decision model) proves difficult in many cases.

So how do you develop a good policy and how do you document it in such a way it provides insight and guidance to the whole organization? In this blog, I will try to explain what a good policy contains, followed by how this policy can be documented in such a way that it is both clear as well as easy to use for all stakeholders.

Developing policies

Policies are a reflection of the organizations’ view on acceptable business practices. It addresses a specific aspect of an organization in which certain decisions are allocated and where it is specified who makes these decisions. However for a policy to be effective it needs to provide information regarding the following:

1. The policy needs to serve a certain strategic course – it all starts with knowing what the goals of the policy are, and what changes it needs to realize.
2. Why is the development of the policy important? This can be because of business requirements, compliancy or service level agreements – what is the driver behind the policy?
3. What are the requirements set for the policy? The policy needs to be actionable, the policy gives a certain direction to your business, with specific standards that define actions and responsibilities.
4. Who needs to know, execute and own the policy? Ownership is key for a successful policy.
5. Where do the standards apply? The policy is put in place to change aspects of the business – what this change affects needs to be clear before being able to act upon the policy in a proper and complete way.
6. The language it is written in needs to be relevant to the people executing the policy. If the people that are relevant for successful implementation of a policy do not understand the way the policy is formulated – it will be an almost guaranteed fail.

After you have managed to define a wholesome policy – which includes all of the aforementioned points, it is key to document it in such a way that the vision of your company (or strategy if you will) trickles down to the operational. There are multiple tools and techniques to assure that the way your policy is documented makes sense to the people working towards its set goal.

From developing to implementing – Decision Logic

Developing a policy is a lot of work. However, documenting it in such a way that it is clear, actionable and fit-for-use regarding decision management can be even trickier. Given the nature of decision modeling and decision logic (which approaches hardcore programming) it is a challenge to boil down policies to this point, as they are generally stipulated by the business – which uses a different language.

Different people have different styles regarding how to take a policy document, which is written in the language of management and ‘the business’, and convert it into input in a decision model. In practice we see that technically and IT inclined people generally prefer exact notations (such as decision tables) whilst business-driven and judicial people tend to prefer natural language as a notation. However, after some training in working with more exact notation, the advantages of this specific style are acknowledged by the business-driven and judicial people. It gives an extra check regarding completeness (did I cover all decisions that have to be made?) but also the quick overview of consequences give the decision table a lot of power.

There are multiple systems however to distill a very verbal document into a more compact decision logic representation. One that is frequently championed is the decision table, which tries to force you to be concise and direct, while others (like Rulespeak) tend to formalize natural language.  Making lists of elements within the document which you can consequently put into a table is generally a suitable approach towards creating proper decision logic. Other options are making decision trees or creating a convention on the use of language. Lastly there is the option to use tools designed specifically to map-out decision making. These techniques and tools can bring structure to the otherwise cumbersome and vague process of developing decision logic from verbal documents.

The technique or tool that suits your organization best depends on the employees and users (decision-makers). Try to find a technique that connects the business with the IT, especially considering the fact that the alignment of business and IT is essential for a clear course of action and operational efficiency.

Well begun is half done

So concluding our story, we can see that the process from developing policies to actual decision logic is a long and rocky road. However there are plenty of guidelines, tools and tricks to make the translation from strategy to operations. As long as your policy has all the required elements formulated,it becomes a question of which tool or technique to use within your organization. From experience I can say that the decision table appeases both business and IT alike, creating a formal decision logic for the whole organization – enforcing your policies.

However, make sure that your policy is clearly formulated from the start because: well begun (developing the policy) is half done (implementing it from policy to decision logic).