A Portfolio Approach to Developing Workflows and Processes

One of the common pitfalls I see with process optimization projects is that they tend to focus on a specific process at a time.  This may be ok when you are just starting out, or working with informal processes, but as the number of complex processes improves it is important to try and take a step back and look at things from an overall portfolio perspective.  In many cases processes overlap or are interrelated.  I most often see this in finance processes because they are so common in all organizations.  Something like a Check Request process should be a pretty standard, well defined process but it is often part of a number of other process flows.  It is easy to ignore the fact that the same steps and activities are followed elsewhere, but that leads to a lot of extra work for the process designers and administrators as well as non-standard activities for your process workers to follow.
To overcome this, it is important to consider the following points when analyzing and designing the process:

• Is there a natural collection of steps or activities?
• Are these steps also done to support another process?
• Is a different group or department responsible for those steps?

While performing the process analysis and design, some activities may form a natural grouping.  It could be a set of steps that are referred to under a particular label and they are likely to be assigned to or processed by a specific group of users.  For large complex workflows, it may be a good idea to make that a sub-process that can be referred to as a set unit.  It is important to talk to the stakeholders that perform those tasks and understand if those same tasks or processes are are also performed to support another process.  If they are, then it would be better to design a standard sub-process that is called from the other processes than to build in the specific steps into each process.
The Check Request example I mentioned before is one that I have seen come up in more than one organization.  There is a set of common steps where requests have to be approved, logged, and then processed.  Standard compliance activities are another example of a common central process that may be leveraged by a number of other processes.  Some times these opportunities present themselves early, but other times you have to dig to identify these sub-processes.  In cases where there are multiple groups involved the main process owner or stakeholder may not fully understand the details of how every step is executed so it is important to interview the actual project participants to understand what they are doing and other processes that may use those steps.  Within the Check Request example, it is unlikely that a process owner in Operations understands all of the various corporate activities that may generate a check request, they only understand that it is part of their one process.  By talking to the process workers in Finance, the other perspective can be considered.
By taking a Portfolio Approach in this case, you can potentially make real improvements that extend the process design and automation benefits not just to the one process, but to multiple processes across the entire organization.  Those processes will also get easier to expand and manage as they can leverage common sub-processes and existing functionality.

Source: http://www.mikeoryszak.com/sharepoint/a-portfolio-approach-to-developing-workflows-and-processes