Enterprise -> Technology
RSS Feed:
|
By: Terry Schurter, Research Affiliate, Hydrasight (Moved) Published: 16th April 2009 Copyright Hydrasight © 2009 |
Hydrasight research confirms that business process management suites (BPMS) continue to be seen as an important component of functional process improvement in many organisations and, to a lesser extent, for cross-functional processes. However, we also observe that many organisations continue to be challenged by their own immaturity with implementing both functional and cross-functional process improvement. This is due to the difficulty associated in codifying processes that often lack sufficient detail or have complex exception handling requirements.
Hydrasight believes that the use of BPMS technology, on both functional and cross-functional processes, can be an appropriate application area for BPMS products. Most BPMS products now offer capabilities to support complex process flows, systems integration, authoring of business rules, automation, operations visibility and modeling standards needed to successfully implement these business processes. However, we caution IT organisations (ITO) and business professionals to recognise that BPMS products provide little support in respect to defining accurate process models where such definitions do not already exist or where processes may be unsuitable for codification (e.g., discretionary decision points).
Hydrasight observes that leading BPMS vendors offer ‘business friendly' tools to aid users in functional and cross-functional process definition (e.g., Lombardi BluePrint, Metastorm Provision). However, we note that process definition for complex processes, and/or processes unique to the organisation, remains a challenge with all BPMS products. Our research confirms that developing a process definition that accurately represents the way work is performed and optimized to achieve desired process outcomes is the single most important factor in determining results gained - whether BPMS automated execution is utilised or not. Hydrasight further notes this is symptomatic of a larger issue where improvement practices such as Six Sigma and Lean also experience significant difficulty in producing desired results on processes not already clearly documented and understood. From our research, we believe this a key factor in limiting the potential of BPMS products to become the foundation of the integrated process enterprise and of process improvement initiatives in general.
Hydrasight research shows that organisations successfully adopting BPMS often focus on processes that are already well-documented or where best practice process models are readily available, diminishing the value of the dynamic optimisation capabilities of the automated suites. This is often due to greater availability of best practice models and the disconnect between ad-hoc business processes and those that are already codified/encapsulated in software applications (e.g., human resources management as one example).
Hydrasight research shows that having access to best practice and/or existing process definition does not guarantee success.
We further observe that even when extensive ‘as is' research is performed before producing a process model, results may still not be consistent with how the process ‘really works' due to the subjective nature of the people involved (e.g., both interviewers and interviewees).
We typically observe that cross-functional processes are rarely well documented or clearly understood in the majority of organisations. This is further complicated by multiple stakeholders with different functional perspectives. The rise of interest in business process management has prompted many organisations to begin looking at these processes with the intent to support them in a more programmatic way. While we recognise the value of this approach, and the efforts to bring cross-functional processes under programmatic control, Hydrasight cautions organisations that the challenges are great-and that outcomes often fall far short of business expectations.
Hydrasight foresees that the subjective elements of BPM, such as the interpretation of process definitions and/or execution decision points, will remain one of the greatest challenges for organisations to face in leveraging the potential of BPMS products. We caution ITOs and business professionals to ensure they pay close attention to the importance of designing process models that accurately reflect how work ‘really gets done'-or how it will be done if the process includes moving to a ‘to be' state of improvement. Moreover, we advise organisations to thoughtfully consider the role of the tool versus the general benefit of process improvement, whether automated or not. In general, we recommend a proof-of-process approach as opposed to a proof-of-concept approach. This assists in avoiding project ‘failure' being directly linked to the tool, rather than the way the tool has been implemented by the business (refer "What's wrong with a proof of concept?"). In either case, Hydrasight observes that codifying an inaccurate process model is likely to lead to failure that extends beyond the intended process goal into issues of diminished confidence with BPMS products, other processes in the organisation and the IT organisation in general-whether they are directly involved or not.
Hydrasight's full set of published trends for 2009, including CIO, virtualisation and SOA, can be found at hydrasight.com (registration required, no charge).
Sorry, we are no longer accepting comments on this item. We suggest trying to contact the author directly.
21st April 2009: 'Chris Adams, VP of Product Management and Product ' said:
Two reasons where I have seen companies slow to adopt process automation efforts are:
- In the process discovery phase, they (the company’s business process champions) cannot agree on what the process is and/or how it should operate
- There are too many exceptions that are part of the process and the BPM/workflow tool they are using is not able to easily and quickly account for the numerous exceptions.
One could even argue that fully discovering a business process before entering the automation phase is not compulsory. Rather, the defined and mapped business process best serves the "majority" of the routing situations, and the BPM tool should then be flexible and open enough to allow for unexpected and/or unhandled routing situations. An ideal BPM solution should allow for:
- Any step in the business process to be activated (“jumped to” from any step in the process)
- Any step in the business process to have defined recipients and “ad hoc” recipients (in the case the defined recipient is not available and the task at hand is urgent and needs immediate attention)
At the very minimum, a business process should not be able to be bottlenecked because of any one person not being available to work on the task itself or a company’s staff mindlessly pushing tasks through people’s inboxes just to get the task at hand to the right person on the right step. In these cases, the automated process is actually a detriment to the company compared to the original manual process. The ability to quickly enter into the process automation phase, but also not risk process chaos because of the possible immaturity of the process, is "phase" of business process evolution where classic business process discovery and initial business process automation actually overlap. Moreover, once the business process has been utilized for some time, through round trip automation, live results of the business process can be compared with the initial modeling efforts of the process to determine how much or how many unexpected routing situations occurred. Meaning, the answer to the question "How different was the modeled process from the executed process?" reveals itself.Reply to Chris Adams, VP of Product Management and Product ?
21st April 2009: 'Terry Schurter (author)' said:
Chris,
Thank you for taking the time to comment. I believe the points you raise reinforce the overall message - that results are keyed to 'discovering' an appropriate process model in many cases. I also note that in some cases, as you mention, it can be viable to put a model in place that enables users to 'tell us' what really works by their choices. I remember when Ultimus first encoded the concept of 'unruly events' - much in the same general vein of purpose.
Terry
The messages above were all contributed by IT-Director.com readers. Whilst we take care to remove any posts deemed inappropriate, we can take no responsibility for these comments. If you would like a comment removed please contact our editorial team.
Published by: IT Analysis Communications Ltd.
T: +44 (0)1908 880760 | F: +44 (0)1908 880761