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

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: BPM, BRMS, business agility, business process management, business rules, policy, procedure, requirements, Sandy Kemsley, process map