Posted by Tom Dwyer on Thursday, October 29, 2009 - 14:44
Should business decisions be defined only in the context of business processes? Is there an approach to business decision management that results in business processes that run faster and produce higher quality outputs?
Business Decisions are still processes except that they are dynamic processes requiring a different approach if you wish to control them. Some of the more advanced BPM systems (BizFlow) incorporate Dynamic Process handling. The beauty of this Approach is that a need for a decision can be entered into the system as a request with an owner. The owner can then break the solution of the problem to further dynamic and static processes so as to engage the organisation in making the decision. The ability to be able to start to build a history of decision making can in itself become part of the solution to current decisions. HTH
I would like to offer a contrary view. Business decisioning should not be defined in the context of a business process at all. The business decisioning should be defined in the context of business strategy and how the business sees itself creating value – the core value proposition of the business itself, which by definition must exist before the business even contemplates a process. The core value proposition of insurance was defined in the days of quill and ink in much the same way as it is now – my guess would be that processes have changed over the same period. The core value proposition declared as decisioning will in turn tell you what data is required, and it will infer what needs to be done to implement the decision outcome. Then comes identification of the events that drive this value transformation, which in turn introduces process – process is a consequence of the need for a value transformation and an event occurring that causes the value change. This has inverted the relationship that you have proposed - we now have a decision context for the process. Does this result in faster processes and higher quality outputs? A definite maybe! For instance, if you have an existing process that collects loan information from an insurance salesperson for mortgage insurance, and you then decide to automate the underwriting decisions within this process (process led decisioning), you will have a faster process, but you have potentially missed the greater opportunity. If instead you had analyzed the value transformation in the insurance policy (from a state of ‘application’ to a state of ‘approved’) from insurance first principles independently of the existing process, you would have re-identified the required data (and frequently, this set of data it is not the same as is currently captured by the process). And if you then looked to where you could get the data from most efficiently, you might conclude that linking directly with an existing lender’s mortgage process is the better option, in which case the process has become faster by lots of orders of magnitude – from a human interaction to an electronic blip in a mortgage application. This by the way is a real example. We call this the ‘decision centric approach’. A project using this decision led approach is currently being diarized here [http://bit.ly/aRQ4Um] – if this is of interest you can track its progress as we go. Regards,
As we know the business processes we automate can have different characteristics: User centric, system centric, case management, ad-hoc, and also rules based. Just like writing code, process maps should be a well organized and lean. This facilitates easier maintenance and understandability (agility is a BPM value proposition). By removing rules from a process map and placing them in a repository, the rules can be easily changed with less risk to introducing problems and our business processes are cleaner. How to recognize rules? We are not talking about the gateways that decide which path to follow down a procedural flow (i.e. if Order Type is A go this path, otherwise go that path). There is no value in removing those. We are talking about declarative statements, where the sequence the rules are presented makes no difference to the end result. These are decisions or business logic that are intended to influence or guide decisions: • Determine a person’s likelihood of defaulting on a loan; • Determine whether the insurance policy renewal method is to be automatic or manual; • An order over $1000 must not be accepted on credit without a credit check; and, • A high risk customer must not place a rush order. Remove these from the process, place them in a rules repository and your business processes are cleaner and you can put the rules management closer in the hands of the business. Reference B. Halle’s and L. Goldberg’s The Decision Model for good discussion of the topic. Cheers Gil
|
||
|
