Main

August 22, 2008

Army mandates 12 knowledge management principles

"Connecting those who know with those who need to know." That is a great definition of knowledge management. And it's right out of the Army manual. The US Army recently released a knowledge management memo outlining 12 principles to encourage and reward sharing knowledge throughout the organization.

"Knowledge management is about connecting those who know (know-why, know-what, know-who, and know-how) with those who need to know and leveraging that knowledge across the institutional Army and to contractors, nongovernmental organizations, the other military services and coalition partners,” states the memo.

A few months ago I wrote about classifying knowledge as either critical knowledge or common knowledge.  Common knowledge is about your experience and what you know.  Critical knowledge is about your expertise and how you think.

Continue reading "Army mandates 12 knowledge management principles" »

March 14, 2007

Enterprise Rules Architecture

In case you are new to business rules, I’d like to go over a few basic terms and facts about business rules and enterprise architecture. Understanding terms and facts is one of the first steps in the business rules approach.

The purpose of the corporation is to perform a business function. The function of most corporations is to make a profit for shareholders by selling products and or services. Corporations comply with external rules, laws, and regulations that specify what the corporation can, should, must, and must not do. They calculate and pay tax, and they report information and file submissions with government agencies.

Corporations establish missions, goals, and strategies such as “sell more and increase profit.” They define internal business rules, policies, procedures, processes, and flows to support the strategies while assuring regulatory and statutory compliance. They put in place business rules to guide macro and micro decision-making and help management plan, manage and improve the operation.

Corporations open stores and branch offices in places and jurisdictions that they would like to do business in, and where customers can go to shop, buy, and transact. They hire employees and educate them on the goals and processes, and train them on the rules.

Corporations design, build, use, and manage information systems, business systems, and database systems for managing, transacting, reporting, decisioning, advising, and automating business functions. These systems have a business purpose, function, structure, behavior, and logic.

All these elements that make up the corporation can be represented by an enterprise architecture framework.

One influential and compelling concept of enterprise architecture was defined in the 1970s by John Zachman when he described his Framework for Enterprise Architecture. The Zachman Framework (click to see it small, medium, or large) consists of descriptive models that describe all the elements of the corporation and the business models of the corporation.

The elements of the corporation include shareholders, employees, and customers (who); data, information, and systems (what); events, plans, schedules, and flows (when); locations, stores, offices, domain names, and networks (where); processes, programs, and code (how); and goals, strategies, policies, and business rules (why).

The business models (i.e. views or perspectives) of the corporation are contextual scope (planner view); conceptual business model (owner); logical system model (designer); technology model (builder); and detailed specifications (sub-contractor).

Business rules integrate and align all the elements and business models of the corporation. Enterprise rules architecture ensures that the functional and structural components of the business rules required for the corporation to fulfill its business function will work, change, and last.

Business rules management entails the business rules approach, business rule methodologies, best practices, rule harvesting, rule modeling, business rule engineering design objectives, enterprise architecture, enterprise rules architecture, rulebase architecture, terms glossaries, semantic modeling, business rule engines (BRE) and business rules management systems (BRMS).

1

February 08, 2007

Macro decisions (million dollar decisions)

Macro decisions are strategic or tactical decisions. I like to call them million dollar decisions. Examples of macro decisions that can be automated using business rules:
  • What is the best product that we should recommend for this customer?
  • What is the best solution for this situation?
  • What is our underwiting strategy and policy?
  • What is our refund policy?
  • What is our pricing strategy for next year?
  • What is our discount policy this year?
  • What promotions should we run?
  • What should we do to improve improve yields and revenue?
  • Where should we locate the new store?
  • Where should we build the plant?
  • Where should we build the product?
  • Where should we hire the employees?

  • What Legal Entity structure should we use for this company?
  • What Legal Entity should we use for this contract?
  • Should we create a new legal entity for this deal?
  • What is the best way to structure this deal?

  • How do we design this plant so as to prevent and contain fires? How do we clean up this oil spill?
  • How do we minimize tax and maximize revenue for this contract?
  • How should we record these types of accounting transactions?
  • How do we calculate this quarter's tax provision?
  • How do we solve this customer's mission critical problem right now?
  • How do we troubleshoot this problem?
Thanks to James Taylor at the EDM blog for the idea for this list. If you have any others you'd like to add to the list, please add your comment below.

See also:

Micro decisions (a million little decisions)

Micro decisions are operational decisions. I like to call them a million little decisions. Examples of micro decisions that can be automated using business rules:
  • Is the customer eligible for the product?
  • Is the customer eligible for the promotion?
  • What discounts is the customer entitled to?
  • What should I up-sell right now?
  • What should I cross-sell right now?
  • What is the highest available commission (HAC)?
  • What is the lowest available fare (LAF)?
  • What credit card does the customer prefer to use?
  • Do I have all the information I need to save this record in the system?
  • How do I work-around the bug or limitation in the system?
  • Who should we assign as the company contact person for this sale?
Thanks to James Taylor at the EDM blog for the idea for this list. If you have any others you'd like to add to the list, please add your comment below. See also:

July 02, 2005

What is the difference between a Business Rule and an IF-THEN Statement?

Business Rules derive inferences and arrive at conclusions by reasoning about facts or premises using either deduction or induction.

An if-then statement in a declarative rule-based programming language is a business rule. Business rules are designed to solve complex problems that require thinking and knowledge in order to make intelligent decisions. Business rules can explain their reasoning process in order to justify their conclusions, decisions, and recommendations. Business rules are commonly used to create Intelligent Systems that reason and apply knowledge.

An if-then statement in a procedural programming language is not a business rule. It is simply a type of conditional statement designed to either control program branching or to conditionally execute sections of program code. If-then statements are commonly used in conventional programs that process data and manage information.

This was originally published here.
Locations of visitors to this page