Main

September 25, 2008

Ten Rules for Wall Street

Ten Rules for Wall Street

What are the rules? Did people break the rules, bend the rules, or ignore the rules?

Confidence in Wall Street went down the drain last week. The credit crisis gave business a bad name, and it gave government a bad name for not doing anything about it. Trust disappeared. 

It's time to rebuild trust in business and government.

Here are ten rules for restoring trust in business and government. These rules apply to everything from the global financial system, to Wall Street; from federal governments to local jurisdictions; from global corporations, to organizations and small businesses.

Companies that learn to define transparent rules that are sensible, consistent, easy to understand, and easy to follow will be easy trust. On the other hand, companies that rely on opaque rules that are complicated, confusing, illogical, inconsistent, or deceptive will be hard to trust. They will go out of business.

Rule 10 - Have guiding principles. Act on principles, independent of influence by greed or friends.

Rule 9 - Follow policies and guidelines about what is permissible and what will not be tolerated.

Rule 8 - Establish rules of behavior concerning what is right and wrong. Success in business depends on understanding the rules. The rules of the business are the way the business really operates. Design transparent rules that are logical, sensible, easy to understand, and easy to follow.

Rule 7 - Leverage knowledge and judgment. Know what you know, and know what you don't know. Document and retain what your experts know and how they think so their knowledge can be shared with those who need to know. Use wise judgment. Know when to follow the rules, when to bend them, and when to forget them.

Rule 6 - Make smart decisions informed by facts, rules, knowledge, principles, and judgment. Decide using clear, logical, and unbiased rules that explain each decision clearly. Use sound reasoning to make rules-based, principles-based, and knowledge-based decisions.

Rule 5 - Create enterprise architecture to deal with change and complexity. Use architecture to simplify complexity, and to understand how the whole business and the whole system works; Understand who, what, when, where, why, and how. Design the architecture to ensure that all the parts fit (interoperability), connect (integration), work (quality), work as intended (alignment), last (reliability), and can be shared (reusability). Design the architecture so the business can handle increases in complexity and increases in the rate of change (flexibility). Design the architecture to reduce time-to-market and reduce operating costs. Design the architecture to support rules-based and principles-based compliance.

Rule 4 - Do the engineering, to design systems that work, change, and last. Apply architecture and engineering design principles to ensure alignment, flexibility, quality, interoperability, integration, reusability, reliability, compliance, reduced time-to-market, and reduced costs. Build in risk management safety factors so the business and the systems can handle extreme stresses and excessive loads.

Rule 3 - Have a clear vision. Stand for brand.

Rule 2 - Instill confidence. Improve the quality, consistency, and accuracy of decisions and actions.

Rule 1 - Build trust. Align actions, decisions, and transactions with management's intentions. Align execution to goals, strategy, and mission. Align systems to business. Align implementation to intention.

Sept. 25, 2008   Rolando Hernandez   BIZRULES

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 13, 2008

Introducing the BIZRULES® RuleMap™

Documenting business rules is a good first step on the path towards the business rules approach.

But sometimes that's not enough.  Taking the next step and getting to the next level requires simulating business rules so they are easy to review and verify.

Over the past few months BIZRULES has been working on a new product that lets us do both. It's a visual tool that lets us not only draw diagrams of business rule models, it also lets us simulate the rule logic. This tool helps us speed up the rules harvesting process and improves the quality of our rulebooks.

BIZRULES® RuleMap™ is an interactive rulebook that models business rules and simulates business logic.  This logical model lets you see how your business rules really work. It lets you visualize the Reasoning Chain™ that leads to smart conclusions and right decisions.


We use this tool to document your business rules independent of any BRE - yet it can be implemented using any BRE. Again, this is a logical model of your business rules.  It can be used as the rulebook or specs for authoring the rules in any BRE.

Take a look at a sample RuleMap. And let us know what you think. Contact us for pricing or a web demo.

 

 

March 16, 2007

Best Buy, Bogus Prices: Confusion about pricing rules reveals need for business rules management

If employees don’t know, don’t understand, or don’t care what the rules are, you have a business rules problem.

If customers get different answers depending on who they talk to, you have a business rules problem.

If salespeople can decide whether to charge the right price or a bogus price, you have a business rules problem.

Best Buy, the nation's largest electronics retailer, has a business rules problem.

It's also dealing with a public relations nightmare, and an investigation by the Connecticut Attorney General's Office.

Pricing rules used by salespeople in Best Buy stores are inconsistent and contrary to Best Buy pricing policies established in the boardroom. “What we've learned very quickly is we have not been clear enough in communicating to our employees the policy, and how to execute it in our stores,” said Dawn Bryant, spokeswoman for Best Buy.

Success in the world of business depends on understanding the rules,” I said recently during a panel discussion on Sarbanes-Oxley compliance.

“You need to know the internal rules and policies of your business. You have to comply with the external rules and regulations that govern your business, industry, and function. Your company must ensure that rules are followed. Your company must enforce the rules. Your company must give staff tools to help them follow the rules, make legal decisions, and prevent them from making illegal decisions. Business rule management systems (BRMS) and business rule engines (BRE) help companies comply with rules and regulations like SOX.

If you don’t have a rule engine that automatically prevents employees from breaking the rules and instantly detects and prevents fraud, you’re out of the game. You’ll end up watching your stock go from $30 to $3 during lunch. You lose. You’re out of business.

Smart companies are using business rules to ensure compliance with rules, to enforce rules, to increase agility so they can change faster, to prevent business mistakes, and to reduce IT system development costs by changing rules in days not months.

Business rules technology helps business comply with rules and regulations, helps employees follow the rules, and prevents employees from breaking the rules (either accidentally or on purpose).”

Business rules management is the prescription for business rules problems. Business rules management entails everything from the business rules approach to business rules technology. 

The business rules approach helps companies transform complex policies into easy to understand business rules. What better way is there to clearly describe and communicate policies and business rules to employees?

Business rules technology helps companies execute the right business rules at the right time every time. What better technology is there to automate business rules?

What happened at Best Buy is a great example of what can go wrong when business rules are not designed and engineered properly.

Business rules are like the glue that holds together all the parts of the corporation. Business rules integrate and align all the moving parts of the corporation. With business rules management, Best Buy can ensure that rules and processes used in the stores are aligned with Best Buy pricing policies defined in the boardroom.

Without business rules management to connect the elements of the corporation, the only way to ensure the corporation works as intended is to "hope and pray," as John Zachman likes to say. With weak or wrong business rules, the corporation falls down like a house of cards.

This is why business rules management is vital to the corporation.

Business rules management is not just about documenting business rules, defining who the owners are, and deciding who is authorized to change them. It’s not just about using rule-based languages to speed up system development instead of hard-wiring rules in legacy code. It’s not just about selecting a business rules engine. It’s not just about understanding the company’s strategies, policies and business practices, and then transforming those objectives into rulebooks, descriptive business rule models, IT specifications, and finally into automated systems.

Business rules management is also concerned with architecting and engineering the business rules so they are integrated with the rest of the business. This helps ensure that the implemented business rules that are in actual use, whether automated or manual, align with the governing rules and strategies of the business.

What happened at Best Buy?

At first, I thought the Best Buy pricing problem was complicated and hard to explain. Then I wondered how can business rules help solve this problem? What would BIZRULES do if Best Buy came to us for help?

That’s easy. I like to draw pictures to simplify complex ideas. By removing the complexity, pictures help me make even the most complex concepts easy to understand:

BIZRULES Analysis of Best Buy Pricing Rules 

(Click to see medium or large slide)

This is an example of three business rules that were apparently in operation at Best Buy when this story broke. Of course, we really don't know the rules were, so this is just a good guess based on published news accounts of what really happened.

Along with a picture of the rules, this slide shows how the rules affect the rest of the company. It also shows how the rules satisfy business rules management objectives, and business rule engineering design objectives:

Rule #1 is a conceptual explanation of the pricing policy to honor the lowest price.

  • This rule tells us what management means and what their intentions are.

Rule #2 is a logical description of the corporate policy to honor the lowest price:

  • This business rule clearly shows alignment to corporate strategy.

  • This is the high quality rule prescribed by the pricing strategy.

  • This rule shows integration between online and retail stores.

  • This rule offers reusability – the same rule can be implemented online and in the store.

  • This rule shows transparency.

  • This rule reduces operations costs because it’s easy to follow.

  • This rule demonstrates regulatory compliance.

  • This picture is worth a thousand words.

  • This rule builds Customer Trust Management.

  • This is a “Best Buy” type of rule.

  • This rule is easy to approve, assess, test, and certify.

  • This rule improves governance and controllership.

Rule #3 is used (i.e. prescribed) by some salesman to mislead customers into paying higher prices:

  • This business rule is clearly not aligned to corporate strategy.

  • This poor quality rule is operational and being used in stores.

  • This rule shows discontinuity and inconsistency between online and retail stores.

  • This store rule cannot be reused online because it lacks transparency.

  • This rule increases operations costs because it’s hard to explain and justify.

  • This rule raises questions about regulatory compliance.

  • You need a thousand words to explain this picture.

  • This rule destroys customer confidence and trust.

  • This rule is public relations nightmare.

  • This rule may be illegal.

  • This is a “bait & switch” type of rule.

  • This rule should never have been approved.

  • This rule raises questions about whether proper rules, processes, and controls are in place.


Now that I understand what the current pricing situation at Best Buy is, it seems pretty straightforward:

  • Management intention is Rule #1. This is Best Buy’s pricing policy.
  • Marketing description is Rule #2. This is what marketing thinks is happening.
  • Sales prescription is Rule #3. This is what salespeople are actually doing.
  • IT specification is not applicable in this example because these rules have not been automated. If these rules were automated, an executable specification of the rule (i.e. pseudo code) may need to be developed for the programmer.


These four views of the business rules fit nicely into an Enterprise Rules Architecture.

The next step is to fit these rules into an enterprise architecture framework. I used John Zachman’s influential and compelling Framework for Enterprise Architecture as an example:

The Zachman Framework for Enterprise Architecture

(Click to see medium or large slide)

Next, I overlaid Best Buy Rules #1-3 on top of Zachman’s Enterprise Architecture Framework to add more clarity to the Best Buy pricing situation:

BIZRULES Analysis of Best Buy Pricing Rules (part 2)

 (Click to see medium or large slide)

The pricing problem at Best Buy is that the business rule used by salespeople in the stores contradicts the company’s pricing policy. Clearly Rule #3 is not aligned with Rule #1 or Rule #2.
Business rules confusion is what caused the problem.

Business rules management is the solution.

To get out of this sticky mess, Best Buy needs to:
  • establish or improve their business rules management.
  • prevent salespeople from using Rule #3 immediately
  • mandate use of Rule #2 immediately.
  • automate Rule #2 as soon as possible. Why let salespeople decide pricing at all? Let the computer figure out what the lowest price is.
  • use a business rule engine to automate this rule as quickly as possible. This rule change needs to happen overnight. But changing hard-wired rules in code takes take days or weeks. Often, companies that don’t use rule engines take months to change business rules as simple as these. This is one reason why companies buy rule engines: Changing rules in a rule engine takes minutes.
  • educate salespeople on the pricing rules. Of course, if Best Buy automated the rules using a rule engine, they wouldn’t need to train as much.
  • ensure compliance with these rules from now on.
What about the secret website?

Business rules can also help Best Buy get rid of the secret and duplicate website. It's hard enough to maintain and manage prices for thousands of products on one website, let alone two. There are costs associated with maintaining a duplicate site containing 250,000 pages; surely management and shareholders want to reduce redundant costs like these. One way is to use a business rule engine to eliminate the duplicate site and duplicate effort. Why not write a few rules to show different prices (if that really is management’s objective) depending on whether the salesman pulls up the web pages on the Internet or the "secret website" on the Intranet?

How else can business rules management and business rules technology help Best Buy? Please comment and let me know.

Rolando Hernandez

CEO & Chief Rules Architect, BIZRULES

 

1 1 1

1
1
1
1

Continue reading "Best Buy, Bogus Prices: Confusion about pricing rules reveals need for business rules management" »

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

May 31, 2006

What rules belong in the BRE and what rules should be hard-coded? (FAQ #2)

Here's a great way to decide which rules belong in the rule engine and which rules could be hard-coded. The idea is that rules that you have no control over, such as compliance rules, must be rule-based so you can react quickly and implement them as soon these rules are changed. When a regulating authority tells you when the new rules become effective, you have no control whatsoever, and a rule engine enables you to change fast.

Rules that you control, where you can take your time and decide when the rules shall become effective, can be hard-coded if so desired. There still may be benefits to rule-basing these rules, but at least you can hard-code them if necessary.

Rules that should be in the BRE:

  • Business Rules
  • External rules
  • Governing rules (Regulatory rules / Legislative rules / Compliance rules / etc.)
  • Rules that you do not control
  • Rules that change often (Promotion rules / etc.)
  • Industry rules
  • Market rules (Competitor rules / Pricing rules / etc.)
  • Environmental rules (Seasonality rules / Weather rules / etc. )

Rules that could be hard-coded

  • System Rules
  • Internal rules
  • Rules that you control
  • Rules that never or rarely change

Idea credit to Paul Ulshafer. See PowerPoint slide of this idea.

FAQ

December 29, 2005

Use Business Rule Analysts for Rule Engines; Use Business Analysts for Code

I'd like to wrap up my blogging for the year with a couple of thoughts that I'd like to explore further next year.

My first thought is about the risks of offshoring rule harvesting. I'll talk about that next year. My second thought is on the state of the rules market. I'll write about that in my next blog. My third thought is about the differences between a business rules analyst and a business analyst. Here it is...

The business rules analyst is focused on separating rules from code. The rule analyst walks and talks business. He or she talks about business terms like customers and products and prices and services and business strategies and rules and policies and procedures and functions and rules and responsibilities and authorities and operations and conditions and action. The rule analyst talks about business rules and business logic. The rule analyst means business.

The business analyst sees rules as code. The business analyst talks about the system. A business analyst is often a systems analyst by nature, and by training. The systems analyst talks about program fields and screen fields, tables, user interfaces, primary keys, referential integrity, and code. When they talk about conditions and actions, they're often talking about what action to you take when the user pushes this button or that button on the screen. The systems analyst talks about program rules and program logic. They talk about the data access layer, and the bits and the bytes. The systems analyst means code.

Most Subject Matter Experts I know will tell you that they are sick and tired of having IT systems analysts come in and ask them the same questions over and over again. A good business rules analyst will ask that question once, and write it down once and for all.

I know it's confusing, and I can understand why some companies that are new to business rules think all they need is a business analyst to do rule harvesting. Maybe it's the title of business rules analyst or business rule harvester.

I don't like any of those titles, because they leave out one of the keys to success with the business rules approach and business rule technology: knowledge.

Back when business rule engines were called inference engines or expert systems, we used to have knowledge engineers. The knowledge engineer would handle knowledge acquisition, knowledge representation, and knowledge engineering.

Three things you miss when you use a business analyst instead of a knowledge engineer is knowledge acquisition, knowledge representation, and of course knowledge engineering. You also miss discovering and retaining the knowledge about the rules and the knowledge behind the rules. You miss the knowledge about what rule to use when and why. You miss the knowledge the experts have and need to use in order to figure out what the rules are. The good business rules analyst, or knowledge engineer as I like to call them, elicits this invaluable knowledge from the experts, digitizes it, and memorializes so it cannot be forgotten.

If you don't use a business rules analyst (i.e. a knowledge engineer) on your business rules project, you won't capture the true business knowledge, and you won't get all the business rules. You will get lots of computer program rules, and you will increase your risk of failure.

Companies often run into trouble when they try to use business analysts instead of business rule analysts to define their business rules.

That's when they call BIZRULES. We help them get back on track with the business rules approach, methodology, and technology.

In many cases, the client's business analysts have invested a lot of time writing use cases, and everyone thinks that the business rules would be in the use cases. Eventually the client discovers that use cases are useful for designing object-oriented systems, but they're really not that useful for defining business rules. That's one problem.

Another problem is that the business analysts are often really systems analysts with a new title. They are coming at this from the systems point of view, from the code perspective, from the technology side, not from the business side.

But the biggest problem is that most companies do not know what the business rules are. There is no rulebook that tells management what the rules in the existing system are, or that tells IT what the business rules in the new system should be.

Companies decide to use rules technology because the rules change often and because they see a lot of value in enabling the business people who make the rules to actually write the rules in the system.

Once they leap into the business rules side (is that the dark side?) companies realize they need a rulebook with the rules of the business. They have specs, and lots of good documentation, but they usully don't have a rulebook that you could use to author the rules into the rule engine. So they need to go thru the rule harvesting phase of the business rules approach.

Some companies new to the business rules approach consider using business analysts (i.e. systems analysts) instead of business rule analysts (i.e. knowledge engineers) for rule harvesting.

That approach works for traditional IT-driven procedural hard-coded applications. But for leading-edge business-driven declarative rules-based applications, traditional business analysis and systems analysis techniques are probably not going to work. Knowledge engineering techniques and business rules analysis techniques, however, will work.

I believe there is a very significant difference between a business rules analyst and a systems analyst.

The rules analyst wants to define the business rules separately from the code. He or she wants to store the rules in the rules engine. Their objective is to write rules for rule engines.

The systems analyst sees rules as code. They want to embed the rules in the program code. Their job is to document the rules so they can be hard coded in whatever language the programmers are using.

There's a lot more to it than that, so I'd like to continue the discussion next year. Meanwhile, I'd like to hear your thoughts on this topic. What do you think is the difference between a rules analyst and a business analyst?

Have a happy and safe New Year's Eve. And best wishes for a great new year!

October 27, 2005

Business Rules Forum presentation on Nov. 10, 2005

Rolando Hernandez, BIZRULES CEO & Chief Rules Architect, will be speaking at the 8th International Business Rules Forum in Orlando, FL. on Thursday Nov. 10, 2005 from 10:15 a.m to 11:15 a.m.

The Knowledge-Based 21st Century Enterprise

Learn how five forward-thinking innovative companies leveraged rules-based and knowledge-based technologies to maintain their competitive edge. Five case studies will explore the strategy, vision, methodology, and actual results / return on investment using BRE/ES tools. Hear, for the first time, how a Fortune 10 company is using rules/process management for digitization and compliance. Take away lessons learned, best practices, and design principles you can apply in your business.
Locations of visitors to this page