1. If the Process is medium sized or large, you should try to create a multi-layered structure for your BPDs with linked Processes
2. The Highest level BPD should be as much abstracted as possible, and simple and clear to understand, stay away from spagetthi Processes
3. For large Processes functionality based groupings into sub-processes should be done
4. Business User Swim lanes should be one per Team/Participant Group
5. You can use multiple system swimlanes to place the system activities near the business activities, for better readability.
6. Separate your Business Data from process data.
7. You can use two primary Context Wrappers (Business and Process) at the top level BPDs to minimize the changes to BPD as the model evolves
8. The Name of the activity should be appropriate to its function.
9. You can use sticky notes next to activities to further define the functionality and purpose of the activity.
10. A well designed BPD approach is to clearly identify the Happy path first and then plot the Exception Paths in context of the Happy Path.
11. If you are the architect use the documentation for each acitivity to provide implementation directions.
If you are the developer update the documentation to facilitate easy maintenance and enhancements.
12. Recommended number of maximum activities in a Process diagram is 10, same goes for service diagrams also.
13. All lines in a BPD should be straight, You can use Ctrl + Arrow Keys to make perfect straight lines.
14. You can optionally create a color scheme for your activities e.g. All Human Services/Tasks in yellow, System activities in Gray etc. with a color legend placed as a sticky note.
15. Example of Process Context Variables are
1. Instance ID
2. Activity Subject
3. Due Dates
16. You need not move all decision gateways to system lane, I have seen someone do that the resulting diagram was a mess. Argument being gateways are system activities.
Please feel free to add to this list or let us know if you have a different concept.