TAKEAWAY: BPM has demonstrated mixed success and continues to get attention. Many see BPM playing a central role in handling the ongoing data explosion, facilitating business transformations, and enabling performance in the context of increasing complexity.
Business process management (BPM) has been around long enough that there are lessons-learned, best practices, and improvements to the tool sets themselves. BPM tools are sometimes packaged as a suite (BPMS) and are often referenced as a providing a BPM platform. Progressive BPM casts a wide shadow.
BPM in its current form is directly embedded with the management of the business, and the underlying processes and data. Not everyone will be able to accept such an influential view. It’s implications are far reaching. In fact there is an emerging BPM maturity model which can, for those who respect process and are ready to improve, provide insights into each of these managed elements and the associated at-large capabilities that can be achieved. It seems that, in the end, BPM will be tightly related to the fundamental industry-shaping mega-shift away from transaction based client-server systems toward big data and the cloud. In the brave new world, it might very well be that you cannot optimize without BPM, that big data might not be actionable without it (with more likelihood that those actions will be strong analytics and event handling). BPM is here to stay; it is increasing adopted and refined by leaders.
TAKEAWAY: Rules are getting more attention because, more than ever, they demonstrate ability to impact productivity. This article provides insight into why this is the case, and how rules can help companies succeed in today’s competitive environment.
Rules have always been around, even taken for granted. Of late rules have been subjected to increased diligence, and increasingly subjected to automation. New approaches are enabling rules to be proactively used in business analysis, change facilitation and solution development. Progressively approached, rules are an integral part of the business blueprint and vital to performance.
Rules that can be applied to make repeatable decisions on a predictable basis are the starting point. Such rules reside in different places, like policy, regulations, legacy computer systems, and “tribal knowledge”. These rules work in direct conjunction with decisions and processes to impact performance.
Why Companies are Investing in Business Rules
- Rules bring efficiency to structured repeatable decisions, so productivity is improved and more predictable. Additionally, this operational efficiency keeps experts free to spend their energy on the more unique unstructured situations.
- Rules can be made clear and transparent, enabling team understanding of how and why decisions are made. In operation you can see precisely what might need to change, and there is a workable path to do so.
- Rules, as defined and owned by the business and as supported and facilitated by IT, provide a vital opportunity to get the team communicating and working together. The nature of rules injects discipline and attention to detail, while directly serving strategy.
How to Approach Business Rules (and Get the Desired Outcomes)
Rule-oriented techniques and tools have evolved and are a proven path for business analysis, using a genuinely business-driven approach. This is resulting in high quality business requirements, and leading to the best available solutions – solutions that are flexible, get used, and deliver results.
Rules are vital and need to be treated in context of the productivity improvements that are available, and their ability to bring a company to relatively high performance teaming (or even influence the culture). To establish rules as an important element of a company’s performance architecture, deliberate steps must be taken to recognize the commitment, keep the right people involved, manage the initiative, and assure a solid support structure. In hope of distinguishing this from the usual motherhood and apple-pie, the following points are offered to help make a rules-based program successful:
- A rules-based program can start to resemble “moths drawn to a flame”, so be prepared and take advantage. Business people will have their interest piqued and stay engaged if the effort shows promise. IT will be anxious for true requirements that brings them closer to the business and the allure of high system ROI. Recognize and stand up to the pervasive challenges of credibility and communications. Start with (and maintain) a communication strategy that includes development of a business vocabulary (not geek speak).
- Recognize that business people do understand and care but will be hard pressed to stay engaged because there is real cost when they are pulled away from operations. Organize the program to involve the right business people at the right times and in the right ways. Prepare and work to cultivate the active, high-impact participation of business stakeholders with an absolute minimum time investment. Administer the program with the same clarity and transparency that is to be embodied into the rules themselves. Continuously clarify and validate roles and responsibilities.
- Recognize that IT people are required and can assume the role of program leader/facilitator. There is a significant list of items that must be diligently addressed, all from an unwavering business perspective. These include scope, charter, goals/objectives, issue management, business and system analysis and modeling, reporting/metrics, and ultimately the rules themselves. Certainly the right IT people can do this, and it is true that a rules-based program typically leads to system requirements, design etc. However, more fundamentally, note that rules present a unique opportunity to link to strategy, something that must be done in close cooperation (even deference) to the business. The point is that this is one of those key opportunities for IT to be one with the business, and it is no place for trial-and-error, poor communication skills, or questionable credibility. Send the A team.
- Use methods and spend energy to extract rules from their natural state, where ever they are (policies, systems, peoples’ heads, etc.). and establish them as a baseline within a business rule management system (BRMS). Along the way, seek to gain real-business-life insights into successes and failures. Recognize that the goal is not simply to have a centralized repository of rules, but to proactively apply them for performance improvement. Map and refine rules in relation to the established vocabulary and key performance indicators (KPIs). Decompose and understand the affected decisions, and place those decisions in their process contexts. Analyze the rules in context of affected processes and supportive automation. Automation makes a huge capability improvement, but there will always be need for a practical understanding of how it works (if the system rejects someone, it’s not acceptable to simply say it’s because the system said so). Test specific rule adjustments to anticipate their impact before deploying. Maintain a clear path for business stakeholders to realize timely adjustments as required. Treat the program as a well-qualified source of company knowledge and best-practices.
We’ve all heard that you can’t improve what you don’t measure. Even more basically, you can’t measure what doesn’t exist. Not everyone is in a bloody process mess, but in cases where you hear “we don’t really have a process” the key word is really. If they are delivering a product or service, they have at least the essence of a process. Processes might not be formal or agreed or understood, which in turn makes them susceptible to waste and variation and manipulation, but they get manage to get things delivered. All things considered, such a situation usually provides no real basis for improvement, it is more a definitional exercise, and might best benefit from something like DFSS. Companies might need a blood test if up to now they were freely growing up and not worrying about processes, if they are made up of companies that have been merged together or otherwise “re-engineered”, if they come to find their efforts more subjected to compliance and complexity, or if they have reached a performance ceiling.
It’s never been productive, and today it’s evermore untenable, to be stuck speculating about what could be done and should be done versus what’s said to be done and what is actually done. But it happens – quite a bit. Companies get stuck in such a rut and are hard pressed to get out. Like plaque in the blood stream, it’s hard to clean up even if you know it is there. And why is that? The short answer has to do with the need for the blood system (process) to work in conjunction with the nervous system (rules) as attached to the brain (strategy-goals-objectives), all of which is affected by DNA (culture), and ultimately the soul (individual behaviors), which in total reflects and sustains meaningful life (operational capabilities).
So let me slow down here before I get my blood pressure up. Please don’t get me wrong on ideas like collaboration and refinement. It’s more than okay, it’s necessary to speculate and think deeply about process. But such thinking must be characterized by movement toward closure and readiness to assume associated responsibility. Apply the tourniquet. Beware of sending process off to committee. Processes and process ownership cannot be sacred cows – they are too important to health.
Theoretically, the company (the body) owns the processes (the blood). But process is an easy target. Everybody knows the blood is in there and for whatever reasons, could try to draw it. This does not usually work and is not advised. Processes are an element of the business architecture that also need some applied ownership. The rightly skilled people need to be entrusted with the right degree of formalized ownership. To keep efforts vital and unconstrained (“disease free”), process ownership should include: 1) the associated process performance ownership – not just a determination of what needs to be done; 2) real experts – either directly or through defined direct communication mechanisms; and 3) a clear defined path to influence (and in some cases control) the interdependent architectural elements (such as policy/rules) and fundamental enablers (such as leadership and IT).
Of course, processes represent precious intellectual property that must be protected – it is lifeblood.
Image: renjith krishnan / FreeDigitalPhotos.net
It might be insightful to look back at how product development competitiveness has evolved in the past, and to consider what might be emerging now in this regard. For complex highly-engineered products, the progression could look like this. At the start of the new century, many companies started considering product lifecycle management (PLM). Now as we head into 2012, there is expectation that the product development function will step up (transform) for the vitality and good of the enterprise. This is how I see it at this point.
…click here to read more