I would like to get your view on policies, processes and procedures, and how best to document them using the various tools in use today. Please comment on the following views:
1. Policy describes the why; also accountabilities, business rules for any decisions to be taken and corrective action/ disciplinary actions should the policy not being adhered to. Similar to 'laws', it states what is allowed and what not and how to redress it. A policy should not contain processes or procedures, but refers to them.
2. Process derives from the value chain (what, who, where, when) and can be modelled in various tools, from manual 'brown paper' maps to MS Excel, MS Visio to various database tools (ARIS etc). It comprises activities/ functions, decisions, may span several systems, executed by several teams/ people (RACI) and may cross functional/ organisation boundaries
3. Procedures comprise the work instructions to execute a task/ activity (how). It normally is executed by one person/ team, does not cross organisational boundaries and is normally documented in a document. It does not normally split in the process logic (decisions) that goes outside the boundary of the activity, but may contain complex decisions/ decision trees to indicate the direction of the process logic after the activity.
Hi John,
I subscribe these views. The big challenge I guess is to manage and to disseminate all this information in an integrated way. These documents describe a part of the organization at different levels, have different goals, are maintainded by different positions (roles) who often use different tools. But in the end it's important to be able to drill dawn from policies to the way these are executed manually or by systems. The other way round, it's important for people on the workfloor to understand how their tasks contribute to a larger end to end story that is relevant for customers.
Regards,
Samuël
First, I like your definitions.
I believe the best way to doucment business process is in a repository based tool like ARIS. This allows you the tracability and impcat analysis that is crucial in today's fast moving environment. It also enables the process model for other uses like performance monitoring and simulation. In order to get the full benefit of having the process in a tool like ARIS I think the procedures and policies should be in ARIS and linked to the appropriate process. If there is already other tools in place that are working well for policies and procedures it would "good enough" to create object place holders in ARIS and link those place holders to the content in the other tools. For instance, if policies are maintained in Word, create an object to represent the policy in ARIS and link it to the Word document. The object can be linked to the appropriate processes in ARIS and provide tracability and availability.
You are broadly right on a 'process' definition but I would question capturing the process information across various platforms. Though it is doable and technically not a challenge, but defeats somehow the purpose of performance improvement as the high overheads and chances of human error nullify the benefits, if any.
Though theoritically BPM initiative can be viewed in isolation and without BPMS, but BPMS increase the chances of a successful BPM initiative.
I do agree with Rick in that policies better be captured in ARIS. However, some technical details in case of an SAP implementation project, can be captured in SolMan which is not ARIS but can be referenced from ARIS.
Regards,
Sumit
Hi,
This is really a interesting topic. I agree with you on Policy and Process however I have question on Procedures especially on the last part of procedures.
Although we all know Procedures contain task level information or what we called key stroke level information, but the complex business decisions / business logic would be easier to be captured on process level as Business Rule. if we capture the Business Rule/logic information in a document outside process repository it nullifies the whole purpose. We might loose the tracebility and impact analysis information related to this if we just use it as link to document rather than using Business Rule object.
Would really like to know the view of others in this topic.
Regards
Abhijit Das
Hi,
very interesting issues addressed in this post, both from John and from all other contributors. On point (1) I agree completely and I would only specify that normally in policies the main point is giving the organization the basic rules to be shared (if it were a State, I think about policies something like "The Constitutional Law"). On points (2) and (3) I prefer to consider process and procedure as two faces of the same coin. The process is simply the sequence of activity form an input to get output (no matter of the level we are talking about, if at first level of a VACD or the n-EPC-level); procedure is a compete description of the process including not only the sequence of the tasks but also responsabilities, system used, documents in input or in output, details description of a specific task and any other information useful to enable the process itself to be correttcly carried out. Hence, from this point of view istructions are specific documents, linked in the procedure, which offer specific details in a task (example, a sequence of screenshot of a particular IT system that specify how to input data correctly or which data fields are mandatory etc.).
I appreciate this kind of issues and I´d like to read other comments on it.
Best Regards
Rino
