Any Road Will Get You There
29th of June 2017Every IT department I have come across with even a modicum of maturity has the recurring activity of planning a two-year roadmap on where it wants to go. Typically this roadmap is revised every year, and starts with gathering a wish list from all involved parties of what they need to do their jobs in the coming years. A common term for the items on the collective wish list are value propositions. And since most companies don’t have an unlimited budget to realize this wish list, selections need to be made based on varying criteria.
However, these wish lists tend to focus on new developments, and never so much on revisiting past built components. And this can be quite the oversight, as leaving an old piece of software in production without proper revision and maintenance can pile up quite the bit of technical debt. So much so that it might hinder necessary adaptations in the future. Even if your value chain is firmly entrenched in its sustain phase, some investments must still be considered.
The main reason why such optimization projects rarely figure on the roadmap is usually attributed to no stakeholder pressing to have them there. This stakeholder could be an executive committee or task force working on the enterprise strategy, or even a special project headed by the CEO, and all the various flavors in between.
This is where Lewis Carroll’s Cheshire Cat comes in. His famous quote about any road getting you to where you want to go, is not a bad starting point. Determining the type of stakeholder you need in your company to actively push for these types of optimization projects, or rather the type of stakeholder that provides synergy with your already existing approach could seem like a daunting task at first. In this case, any approach will be better than none at all. There are several books that try to write out how to form such an entity, like for example the IBM redbook IBM “Creating a BPM Center of Excellence”, but I want to go into the structure suggested by Paul Harmon’s BPTrends approach: The Executive Level BPM Group.
Why a group on an executive level? To reflect the emphasis on management, as this type of initiative becomes a lot easier with senior management support and buy-in. This differs to companies who focus on redesign of specific processes and locate such activities in the separate business units or divisions. It also differs from companies focusing on automation, where typically these activities lie within the IT department. The tasks that make up the activities of a BPM group can be found in the diagram underneath, with the process highlighted in red being the link to the roadmap.
Most tasks on the diagram are self-explanatory. Creating and maintaining the process architecture, preferably stored in a managed repository is a necessary foundation to allow for any set of management support tasks. An up-to-date repository provides the necessary documentation to allow for quickly determining which processes to change according to an emerging need, as well as which IT components to adapt, and which trainings to provide to your knowledge workers. These emergent needs can come from different stakeholders (strategic committee, process analysts, operational people…), and can then be placed into the roadmap with priorities and timings according to the organization’s objectives.
Before tackling the actual optimization of processes, it is also important to have a clear view on which resources (both human and IT) are present, and to determine which approach to take for each individual optimization. The generic options are Redesign, Automation, Improvement (incremental), Management (rework of planning, organizing, measuring, and controlling around existing processes), and Outsourcing. The strategic importance of the process will often also play a significant role in choosing the proper approach. The two diagrams below are example quadrants from Paul Harmon’s book on how to do this. This book is really worth checking out for anyone enthused by process management.
I attempted my own version of this with the underlying BPMN diagram to demonstrate where different types of optimization approaches intersect with a given process. Evidently, there are dozens of other methodologies that act on the efficiency and effectiveness of a process, and any BPM group should definitely determine which of these to consider and adopt in their planning of optimization projects and initiatives.
Paul Harmon’s quadrants are in the same spirit as the Pace Layered Architecture of Gartner where we have Systems of Record (packaged applications or legacy systems with very low rate of change), Systems of Differentiation (applications enabling a unique capability of the organization, typically more adapted but frequently reconfigured) and Systems of Innovation (ad hoc development to tackle new needs/opportunities of the organization and changes in the market).
Even with a specific group in charge of placing the optimization needs on the roadmap, there is still (as with any proposal) the work of drafting up the proposal and writing a business case for its implementation. I have already dedicated some thought to business cases in the past, and will probably write up something more specific to this topic in the future.
| Thought | EA | BPM |