Microsoft Dynamics CRM is highly customizable and can be used to reproduce/automate business processes. For someone familiar with the basic use and implementation of workflow processes in Dynamics CRM, creating short workflow processes can be attained by simply inserting a couple of steps and check conditions. But when business processes become complex, it can become daunting and without planning, you can end up wasting a lot of time designing and re-designing the workflow.
My general approach to planning a CRM workflow process is:
Part 1
- Identify the Business Requirements
- Visually model the Business Requirements
Part 2
- Translate the Business Requirements into CRM workflow processes
- Initial CRM Planning
- Create forms and fields
- Identify triggers that start the CRM workflow process
- Convert the Business Requirements into Dynamics CRM workflow processes that account for all possible cases
- Identify duplicate processes
- Identify CRM workflow process loops
- Simplify CRM workflow processes
- Initial CRM Planning
Based upon a real life scenario, in Part 1 of this post, I discussed identifying and modeling the business requirements. Now in Part 2, I will discuss translating the business requirements model into full-fledged CRM workflows.
Scenario
One of the business units in a company is working on a new venture with a series of manufacturers and needs to ensure that the manufacturers are being compliant. They have placed auditors in distribution centers, but need a system to track/report on passed audits and the communications regarding compliance progress (or lack thereof.) They intend to classify the manufacturers by status (red, yellow and green) to help determine which manufacturers are in compliance, and which might be troublesome.
Translate the Business Requirements into CRM workflow processes
Initial CRM Planning
Now that the business processes have been outlined, we need to identify the fields for form design.
Scenario fields:
- Audit Start Date
- 1st Passed Audit Date
- 2nd Passed Audit Date
- 3rd Passed Audit Date
To begin planning the translation from business processes to CRM workflow processes, identify the trigger that starts the CRM workflow – for this scenario, the trigger is when the Audit Start Date is changed.
Convert the Business Requirements into Dynamics CRM workflow processes that account for all possible cases
CRM workflows must be more explicit than typical business process because they must not only account for what should happen, but also for what should not happen. They need to include early exits and account for all possible cases. At first glance it seems that all the workflows, when looked at independently, seem simple to implement. The Passed Audit Process and Status Update Process are simple enough, because there are few decision points (or Check Processes) and there are no looping processes. The Audit Progress Process is more complex because it requires that a task be auto-created every five days until the next audit is passed, and it has multiple decision points. Also, to ensure the most efficient path is used, you must plan for different cases that may occur. For instance, what happens when a manufacturer completes all three audits before the first task is supposed to be auto-created? The workflow must account for all possible cases, at all times. (In reality, this may not be realistic. But designing your workflows with the 80/20 rule in mind and having a firm understanding of their function will help greatly in troubleshooting later.)
All of a sudden, this simple business process…
…quickly morphs into this complex CRM workflow process.
NOTE: The below describes the annotations used in the model:
- P1 = 1st Passed Audit
- P2 = 2nd Passed Audit
- P3 = 3rd Passed Audit
This model depicts every possible case that could happen at any possible point in the business process, but don’t fret! You will not have to re-create the entire model, if you plan appropriately. In fact, if you take a closer look, you can clearly see that there is quite a bit of duplication in the model. We can use this to our advantage.
Identify duplicate processes
Next we need to identify duplicate processes. When taking a closer at the model, you will notice that there are two major chunks of this process that are repeated in other parts of the process. For instance:
- The check to see if the 2nd Audit has passed is duplicated in two places – I named this “P2 Check”
- And the check to see if the 3rd Audit has passed is duplicated in five places – I named this “P3 Check”
Identify CRM workflow process loops
Next, identify any CRM workflow process loops. This scenario requires the CSR to make a call to the manufacturer until they pass another audit. A loop in a Dynamics CRM workflow is easily created by having a Child Process call itself at the end. For convenience’s sake, I will call these the “Reminder” workflows. However, these loops are not exactly the same, because the exit check conditions vary slightly (there is a check condition for each of the passed audits: P1, P2 and P3). Later, these can be simplified so that they only need to be created once and the other CRM workflows processes can simply call them. It should also be noted that the “Reminder” CRM workflow process are located within the “Check” process, so each “Reminder” CRM workflow process will actually be called (or started by) the “Check” CRM workflow process.
Simplify CRM workflow processes
Now that we understand the “Check” CRM workflow processes, the model can be made much simpler. Here is a more simplified CRM workflow process for the Auditing Progress Process
If you skipped the planning phase, and went straight to designing in Dynamics CRM, you likely would have ended up kicking yourself about three hours into the design, realizing you need to account for all the other cases. Not only does failing to plan cause sleepless nights and headaches, it also results in a needless duplication of effort. This model gives us exactly what needs to happen, when it needs to happen.
Some people may feel that they don’t need to plan or they just don’t have the time to do so. Planning a Dynamics CRM workflow process before design versus just jumping into design is much like driving without a map versus having navigation on your GPS. If you don’t have time to get lost and have an adventure, then you don’t have time NOT to plan!
The post Approach for Planning Complex Workflows in Microsoft Dynamics CRM 2011 (Part 2 of 2) appeared first on Understanding ERP & CRM Software.
