We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

Policies, procedures, policies and rules - a point of view

user-pic
Vote 0 Votes

Sandy had a great post this week - Policies, procedures, processes and rules - where she discusses some of the very real challenges in managing new ways of documenting our businesses. If we use business rules and process maps to say what we are going to do, how do we map these to each other or to higher level artifacts? How do we track change and manage it effectively. Like Sandy I fear I have more questions than answers but I wanted to add a couple of thoughts:

  • Capturing high-level procedures and policies, along with the goals of our systems, is not the same as using a business rules management system or a business process management system to capture operational details.
  • There is a huge value in having the actual process steps and business rules/decisions that execute in a process be visible, manageable and editable by both the business and technical people in an organization. These executable "views" of the business are more real than anything written down ever will be - they execute more repeatably and are more auditable than any manual process could be.
  • Automatic conversion of one to the other is much less important than traceability. Focusing on recording which process steps in your BPMS implement which procedure, which rules in your BRMS implement a specific decision that is supposed to be based on a particular policy or law is critical. Only then can you do the kind of impact analysis that is crucial to both compliance and agility. For instance, you can then ask for all the audit logs for process executions based on such-and-such an exception handling policy or all the rule artifacts that implement such-and-such a law. This allows you to find the right pieces, see what they do and change them appropriately.
  • Don't forget requirements for your system in all this - they too come in high level and low level forms and must be managed and traced.

One final comment. All of this sounds hard but it is only worth discussing because BPMS and BRMS and related constructs make it so much more practical to lay out how your business operates. You could not do any of this if you (or when you) just wrote code. The fact that the problem has become visible is a GOOD thing!

Technorati Tags: , , , , , , , , ,

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links

Fico

Subscribe

 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives

    Blogs

    ADVERTISEMENT