Knowledge Automation

Two common mistakes are (1) attempting to automate decision-making tasks without redesigning the surrounding business process, and (2) redesigning a business process without considering how the decision-making will be automated. Decision management should always be considered both during process redesign and as a form of process redesign.

Ref. 8EC9-A

The most common approach when automating operational decisions is to encapsulate the knowledge required for the decisions in decision services, which are called by the BPMS at the decision points in the process.

Ref. BE94-B

A more typical process would have several decision points. Each decision point in the process flow calls only one decision service, but a decision service may be called from multiple decision points. That is, the same service may be reused to make decisions at several points in a business process or from multiple processes. This is not just a form of economy but a reliable way to enforce consistency of decision-making across different stages in the process, different product lines, different channels, and different functions in the business.

Ref. 576F-C

The decision services I will be considering in this book are stateless; that is, they have no memory. Goldfish-like, after the service returns the decision results for a case, it forgets all about it. If it is called again with the same data it will make exactly the same decisions.

Ref. FE7E-D

Service-oriented architectures and business rules management systems are an essential component of modern agile businesses. They vastly reduce the problems associated with the evolution of complex and volatile business strategies and policies. SOA and BRMS [business rule management systems] are parallel and complementary technologies.

Ref. 3CDF-E

Paul Konnersman has proposed an approach to analysis and modeling of human decision-making processes that can greatly simplify this apparently impossible task.3 His Decision Process Specification method is based on the insight that since many decisions involve several people, the atomic activity to be modeled is the decision itself, not the work contribution of any particular person involved with it.

Ref. 2107-F

Konnersman uses five roles: every activity has a decision manager, but it may also have consultees, approvers, inspectors, and informees (see Table 2.1).

Ref. 0440-G

Precision, cost, speed, agility, and consistency can all be improved by replacing human decision-making with automated decision-making. One of the goals of process redesign should therefore be to use decision services wherever possible, using human tasks only to interact with the customer and to handle marginal and exceptional cases.

Ref. C454-H

The thinking in Enterprise Decision Management is that you shouldn’t say “rule” when you mean “decision.” In other words, it’s some decision that rules can be used to make that provides the actual value-add for the business—not the rules per se. To say this differently, rules are simply the means to some important business end, some operational decision(s) to be made. So the EDM message is that you shouldn’t talk to business executives about the means (rules) when it’s the ends (decisions) that really matter. It’s simply the wrong artifact.

Ref. 621B-I

It’s an excellent point. It’s not rules per se that makes [sic] a company act smarter; it’s enabling better decisions that makes the company act smarter. Rules and rule management are simply a means to that end. I’m very comfortable with that view and I think the message is a good one.

Ref. 2F8A-J

Similarly, as we move on to the next three levels I will propose a top-down process of analyzing the structure of decision-making at each decision point, discovering the knowledge required for each decision and then implementing

Ref. 3D1B-K

Automating decisions in business processes involves identifying or generating the business knowledge required to make those decisions and codifying it in a machine-executable form. The knowledge can then be automated by encapsulating it in services that execute the decisions. This

Ref. 1A60-L

As these examples show, rules are discrete and independent statements that each express a single atom of executable business knowledge. By independent, I mean that the meaning of a rule is entirely contained within itself and does not depend on its relation with other rules.

Ref. 1FD1-M

One of the principal attractions of business rules is that they are declarative, which means, among other things, that they can be defined without any consideration of order: the decision made by a rule set need not depend on the order of the rules within it.

Ref. CCAE-N

The business processes require decision services. The decision services require business knowledge. The business knowledge requires analytics.

Ref. 5FC8-O

Decision services make decisions. This may seem too obvious to state, but it is surprising how often this basic truth is ignored. A decision service is fundamentally a decision-making component. So, although it could be specified in various ways (for example, as a function, an object, or an input-output mapping), the best way to define its functionality is purely in terms of the decisions it makes. Each decision can be defined as a means of providing an answer to a question. So if you can clearly define the questions, the answers, and the means, you have completely defined the functionality of the rule service.

Ref. 57D9-P

Decisions require information. You can discover the requirements of a decision by asking what information is required to make the decision. Information is of three kinds: 1. Business knowledge (in all its forms: business rules and their metaphors, algorithms, and analytic models) 2. Data describing the case to be decided on 3. The results of other decisions

Ref. 6E44-Q

As simple as they are, these diagrams are staggeringly useful, because they allow the broad scope and structure of the decision-making to be appreciated at a glance and discussed by all the people involved in the project: the project sponsors, project managers, business domain experts, analysts, designers, developers, and testers. They allow people to point to things and say “this component of the decision-making,” without having to refer to anything technical or architectural. The DRD is produced using a simple, structured workshop technique called DRAW.

Ref. 4B65-R

In principle, DRAW consists of a standard sequence of five stages: 1. Identify the decision points. 2. Define the top-level decisions. 3. Decompose the decision-making. 4. Describe all the nodes in detail. 5. Define the decision service boundaries.

Ref. 5C23-S

Gradually your DRD will expand to cover the board, and things might get a bit messy (multiple colors help). But when the process is complete you will have a complete DRD, identifying all the decisions required, the areas of knowledge involved in the decisions, and the areas of data required by the decisions. The four separate principal decisions you started with will probably have been joined together, either directly (like Eligibility and Bureau requirements) or indirectly through shared subdecisions.

Ref. F404-T

The source of the knowledge (for example, documents, spreadsheets, personnel, legacy systems, or analytics) An estimate of its size and complexity (such as approximate number of rules or pages of calculations) Who will be responsible for providing the knowledge (preferably a specific name) The maintenance requirements, including who will be updating the knowledge (business or IT staff), and how often Any other important background (for example, constraints on availability of the individual designated as the source of the knowledge and any plans to introduce new

Ref. 176D-U

LET ME SUMMARIZE OUR PROGRESS SO FAR. We have remodeled our business processes, identifying a set of decision points that will be automated by encapsulating our organization’s business knowledge in decision services.

Ref. 1570-V