Business Process Implementation for IT Professionals phần 3 doc

5.5 Metamodel structure
The business rule metamodel attributes that are utilized as the basis for further
discussion are:
§ Creation date;
§ Name;
§ Description;
§ Purpose;
§ Source;
§ Owner;
§ Category;
§ Scope;
§ Detail level;
§ Strength;
§ Priority;
§ Persistence;
§ Format;
§ Implementation method;
§ Compliance monitor;
§ Domain specific.
Other metamodels certainly are possible, but the one utilized here will effectively serve
as a vehicle for discovering the opportunities and problems associated with the use of
business rules as an integral part of business operation. That structure, along with some
refinements discussed later, can be considered as the core of a comprehensive business
rule metamodel.
5.5.1 Rule identification
The first four attributes of the metamodel structure, creation date, name, description, and
purpose, provide a unique identifier for the rule. The meaning and values for each
attribute are generally self-explanatory. A separate ID attribute is not specified in this
structure but, depending on need, could certainly be added. Using only the values of the
four identifier attributes, it should be possible to define a rule with sufficient detail to
distinguish it from all other rules.

Although additional information is provided by the values of the other attributes, they
should not be needed for the identification of a unique rule. The remaining attributes and
values can, of course, be used to search for rules with specific characteristics.
5.5.2 Rule advocacy
The attributes of source and owner provide an indication as to the original and continuing
advocates for keeping the rule. All rules must have a business reason for their creation
and continued existence. As part of the life cycle process, that reason must be examined
periodically and verified as to its continued validity. As a result of their direct involvement
with the rule, the creator and the owner are the primary advocates and must be
consulted if any alteration in the rule status is contemplated. The source of the rule and
the ownership of the rule must be from a business perspective. The source and the
current owner can be the same or they can differ, and the owner can change periodically
for many business reasons. The rule administrator is not necessarily the owner, and the
administration function is usually considered from a technical perspective.
If the source or the owner for a rule is not specified and cannot be easily identified, that
rule should be considered a candidate for elimination. All these conditions should be
specified as part of the rule life cycle activities.
5.5.3 Rule classification taxonomy
In a very real sense, any classification scheme is somewhat arbitrary, even though some
means of classification is usually considered necessary to reflect the utilization and
implementation of the rule within the enterprise. There is also another major reason for
the classification of rules. In any reasonably sized enterprise, there likely are thousands
of business rules. The intricacies of effectively creating, maintaining, using, reusing, and
discarding the rules require some classification scheme regardless of the configuration
management approach used. The purpose of the classification scheme is to reduce the
number of rules that would need to be considered at any one time.
Many investigators have advanced and defended specific rule taxonomies, resulting in
considerable debate and conflict. Most of the taxonomies are specific to the area and
emphasis being advanced by the investigator and are usually defined to efficiently
accommodate the needs of the proposed approach. Because the set of rules for an

enterprise exists independently of any taxonomy, it is possible to define and utilize
multiple taxonomies. Each taxonomy could be optimized to serve a specific purpose,
such as configuration management or conflict analysis. One taxonomy could be business
oriented, while another could be implementation oriented.
Specification of a rule taxonomy as a separate degree of freedom governed by needs of
the business and independent of the other defining rule characteristics would accomplish
the following:
§ Eliminate the unnecessary conflict over the definition of the ultimate rule
taxonomy;
§ Allow different user groups to optimize their access to and use of the
rules.
The price that must be paid for that flexibility is, of course, the additional time and effort
to place each rule (either automatically or manually) into its proper place in every
taxonomy utilized. In addition, as has been previously stated, a robust repository is also
necessary for the simultaneous definition of multiple taxonomies.
For illustration purposes in this section, some specific taxonomy is necessary. A
relatively robust taxonomy that interacts efficiently with the process implementation
methodology discussed later is defined and utilized. It is defined in business-oriented
terms and is matrix oriented. Although it effectively provides a comprehensive example
of the information needed in a taxonomy, it is not intended that this classification scheme
be considered as the only appropriate one. Many schemes are possible and may
simultaneously coexist with each other and the one presented here.
Three structure attributes, category, scope, and detail level, are used in this taxonomy.
They provide the basis on which to classify the rule into a suitable category. Figure 5.1
indicates one method of specifying values for the category and scope attributes using a
matrix structure. The rows of the matrix represent the specific aspect of the enterprise
that the rule addresses. Although the rows may not provide a complete taxonomy, the
author has yet to find a case where a proposed rule could not be reasonably placed into
one of the rows.

Figure 5.1: Example of business rule taxonomy.
The columns of the matrix represent the scope or sphere of influence within the
enterprise. Each of the columns and rows can be further decomposed into smaller units
as necessary for the understanding of a particular rule. For example, the organization
unit row can be divided into the individual organizations of the enterprise. The degree of
decomposition determines the detail level of the rule. Although not indicated in the figure,
each matrix cell should be decomposed in both category and scope for as many levels
as rules are reasonably expected to be defined. Because the amount of detail that can
be produced in that manner is quite large, this process will not be explicitly performed in
this presentation.
5.5.4 Rule operation
The last seven attributes of the rule structure provide the operational conditions for the
realization of the rule. Those conditions are specified by the strength, priority,
persistence, format, implementation method, compliance monitor, and domain-specific
attributes. A brief discussion of each of those attributes follows. The strength attribute
was discussed in some detail in Section 5.3, so it is not considered further at this time.
The interactions of that attribute with other operational attributes are examined later as
necessary.
The priority attribute is utilized when there is a rule conflict. Although in theory there
should never be a rule conflict with rules covering the same area, in practice that is
difficult to control because there usually are a large number of rules with many different
originators and owners. The priority attribute indicates the desired outcome in a conflict
situation. The simplest priority scheme is probably the values “required,” “where
possible,” and “guideline.” Although better than nothing, that priority scheme generally is
ineffective in resolving conflicts since the chance of conflicting rules having the same
priority is relatively large. That is where reasoning and analysis over a given rule set
become necessary.
As with any type of attributes, care must be taken to ensure that all rules are not simply
given the highest value possible by their originators. That requires good administration
and configuration management functions.

The persistence attribute indicates the period during which the rule will be effective.
There are many possible values for the persistence attribute:
§ From creation until explicitly deleted. Example: “From now on, all
employees will enter the building through the south entrance only.”
§ From creation until a specific occurrence, date, or time. Example: “Until
the renovations are complete, all employees will enter the building
through the south entrance only.”
§ For a certain period. Example: “For a 2-week period starting this Friday,
all employees will enter the building through the south entrance only.”
§ During periods indicated by the state of a defined entity. Example: “When
the red light is on, all employees will enter the building through the south
entrance only.”
In the examples, for better understanding, the period during which the rule is effective is
included in the rule statement. That, of course, does not have to be the case. A rule can
be stated without any indication as to its period of applicability. In that case, a specific
indication as to the effectiveness period must be included as the value of the attribute. If
it is unknown, that condition also should be stated.
The format attribute provides the style of the business rule. Styles could include:
§ A rule language;
§ Structured English (or other natural language) text;
§ A mathematical expression;
§ Freeform text;
§ A table or matrix (including the case of one cell);
§ Procedural code;
§ A combination of any of the above.
All those styles are useful in expressing business rules. Which form is the most
appropriate in a given situation depends on the level and the purpose of the rule and the
manner in which it will be used. A single style is not sufficient to represent all the different
types of rules that are needed in the enterprise. Because of the desirability to compare
and reason about rules of differing styles, some means of translating to a common

formalism is desirable. That need is discussed further in Section 5.8, which considers the
use of a repository.
Each of the styles can provide for parameters whose values can be changed without
changing the rule statement itself. In many cases, that parameterization can facilitate
rule creation and management.
Currently, no standards are available for business rules, and that lack, unfortunately,
extends to the definitions of style. Almost anything can be used, as determined by the
creator of the rule. The enterprise needs—and should set—some internal standards in
this area to be in a better position to effectively manage business rule usage.
In many cases, the creator of the rule uses a style that must be converted into one or
more other styles before it can be used. Products that can accommodate business rule
inputs generally require their own specific style (remember the lack of standards). The
use of many different products, each with individual style requirements, can create a
difficult problem. Errors can easily be made in translating rules from one style into
another. The need for many target styles complicates the testing and identification of
error conditions in the application as a whole. With that said, it still is probably better to
set a single standard for the creation of business rules and then translate them into the
various formats needed rather than create them with different formats. In that way, all the
rules have at least the same standard style(s), which facilitates their comparison and
reuse.
Rule styles other than those listed could also be defined, depending on the particular
needs of an enterprise. The more structured the format and the more it is parameterized,
the easier it is to automatically utilize the rule in the operation of the enterprise.
The implementation method attribute indicates the method(s) by which the rule will be
accommodated. This attribute is key to the successful utilization of business rules
because it provides for an explicit relationship between the rule statement and the
means for realizing it. By examining the proposed linkage, it can be determined if the
proposal will provide the most effective method of rule realization and, if not, what the
method should become. In many contemporary instances, rules are stated without any
indication as to how the rule will be incorporated into the business. Without that explicit

linkage, the use of business rules as an integral part of enterprise operation will fail.
The major utilization methods include the following:
1. Specifically including or considering a rule in the development of
manual procedures and practices;
2. Considering a rule as the requirements for a software development are
being developed;
3. Specifically including a rule in the requirements for a software
development;
4. Manually considering or incorporating a rule as part of an application
design activity;
5. Entering a rule into a product and interpreting it at compile time;
6. Accessing a rule from a library and interpreting it at compile time;
7. Entering a rule into a product and interpreting it at run time;
8. Accessing a rule from a library and interpreting it at run time.
Each implementation method is illustrated as part of an overall rules system, as defined
in Section 5.8.
In general, the methods become more automatic and less error prone as listed from top
to bottom. Depending on the strength of a rule, one implementation method may be
more appropriate than the others. For a required rule, the desired method would be the
eighth one in the list, directly accessing the rule and utilizing it at run time. If changes are
needed, they could be made and the altered rule bound at the desired time. For a
guideline rule, methods 1, 2, and 4 are probably most appropriate; the rule does not
have to be followed exactly, although some type of fuzzy logic could be used to
determine which rule would be utilized.
The value of the compliance monitor attribute, which is closely associated with the rule
implementation method, explicitly defines how the rule realization is examined to
determine if it produces its defined constraints. A good way to start is to associate one or
more compliance monitor techniques with each implementation method. Others can be
defined if needed. The numbers in the following list correspond with the numbers in the
implementation methods list.

1. Use a
design
review of
draft
materials
to
determine
if and to
what
extent
applicable
business
rules are
reflected
in the
document
text.
2,3,4. Use a
design
review of
requireme
nts to
determine
if and to
what
extent
applicable
business
rules are
contained

in the
requireme
nts
specificati
on.
Perform
complianc
e audit of
finished
software
to
determine
if the
software
accurately
reflects
the
requireme
nts,
including
those
requireme
nts
associate
d with
business
rules. Test
finished
system to
determine

if
applicable
business
rules are
being
accurately
reflected.
5,6. Test
product
with
suitable
environme
nt
conditions
designed
to
determine
if product
reacts
properly
to
incorporat
ed
business
rules. Test
product
integrated
with the
entire
applicatio

n to
determine
if
business
rules are
being
interprete
d
properly.
7,8. Test
product
with
suitable
environme
nt
conditions
designed
to
determine
if product
reacts
properly
to
incorporat
ed
business
rules. Test
product
integrated
with the

entire
applicatio
n to
determine
if
business
rules are
being
interprete
d
properly.
Change
business
rule
parameter
value or
structure
and retest
to
determine
if change
is being
implement
ed
correctly.
The domain-specific attribute, the final one in the metamodel, consists of any domain
requirements that may arise from regulatory bodies, required standards, or similar
sources. Requirements must be considered when the applicable domain is involved. For
example, assume this rule: “Insert the maximum number of ads into the bill envelope
without increasing the amount of postage due.” The domain-specific value for that rule

could be a reference to the regulation that the post office uses to calculate the amount of
postage to be paid.
5.5.5 Examples
Two examples of business rules with differing characteristics are shown in Tables 5.1
and 5.2. The rules are designed to illustrate the wide variety of rules that can be
accommodated using the metamodel defined at the beginning of this section. Readers
are invited to take any business rules with which they are familiar and (1) ensure that it is
a well-formed business rule by determining if it has the required characteristics and (2)
determine the specific characteristics of the rule by determining values for all the
metamodel structure attributes.
Table 5.1: Emergency Response Rule Metamodel
Creation date: 1/1/95
Name: Emergency Response Rule
Description: In the event of an emergency that requires a
field response by employees, at least two
employees will be dispatched to the trouble
location.
Purpose: The purpose of this rule is to help provide safe
working conditions under emergency conditions.
Source: Safety Department
Owner: Vice President of Administration
Category: Operations: function
Scope: Process
Detail level: Dispatch function/trouble resolution process
Strength: Requirement
Priority: High
Persistence: Immediately, until rescinded
Format: Text only
Implementation
method:

Included in all software requirements dealing
with dispatch functionality
Compliance monitor: Design review
Domain specific: None
Table 5.2: Sales Tax Calculation Rule Metamodel
Creation date: 6/1/95
Name: Sales Tax Calculation Rule
Description: This rule requires that the sales tax be
calculated using this formula: ST = (Price * Tax
rate) rounded up to next cent if not already at a
whole cent.
Purpose: The purpose of this rule is to provide the rule for
calculating the sales tax on products.
Source: Tax Department
Owner: Chief Accounting Officer
Category: Operations: function
Scope: Transaction
Detail level: Tax calculation function, tax calculation
transaction
Strength: Requirement
Priority: High
Persistence: Immediately, until rescinded
Format: Mathematical equation
Implementation
method:
Business rule library that is accessed by
software at run time
Compliance monitor: Module test and application integration test
Domain specific: Tax code reference: Sect. 10.556.9 State Code

5.6 Rules versus requirements
Although the modeling, implementation, and use of process business rules are not
covered until later in this book, one area of potential confusion needs to be addressed
early: the relationship between process business rules and the requirements for software
products that support a process. In general, the software requirements must be
consistent with applicable process business rules (and other types of business rules, for
that matter) but they do not necessarily have to contain the rule itself, nor do they have
to be rules themselves. In fact, they should, in general, not be business rules. Business
rules are oriented toward understanding and defining the operation of the business, while
requirements are oriented toward defining the operation of a software product. If a
process business rule states that “all preventative maintenance will be performed
between midnight and 7:00 A.M. except for weekends, when it can be done anytime,”
then a software scheduler that supports the maintenance process could have a
requirement that “a means must exist through a GUI interface to specify the time period,
based on days of the week during which work can be scheduled.”
That example of a requirement is a product requirement or rule that supports the
business rule. It clearly is not a business rule in the sense we have been assuming and
using business rules. The author refuses to be drawn into a philosophical discussion
concerning the definition of a product requirement as a special type of business rule. It is
not necessary, or probably even feasible, to provide a definitive answer to that question.
In the development of software product requirements, additional business rules may be
identified. If a prospective requirement further defines the process that the software will
support, it can also be considered a business rule and may or may not be kept as a
requirement. As an example, assume a casual customer billing business rule has been
specified. A software product that will be used to monitor customer account status could
be given a requirement that “if a customer is delinquent in any payment for the last year,
that customer will be billed every month instead of every other month.” In that case, the
requirement is clearly process related even though it initially was defined as a software
product requirement. With that understanding, the requirement should also be

considered as a business rule and the needed product requirement reconsidered. In the
example, the product requirement could (and probably should) be restated to the
following: “The product will be capable of generating a bill at intervals determined by
customer status.”
Whether a candidate software requirement is process related must be determined from
the individual circumstances. If it is determined to be such, a recast of the requirement
and an addition to the business rule set probably is appropriate.


5.7 Rule engine
As an aid in the configuration management of business rules and to make the
incorporation of business rules into the enterprise more effective, the concept of a rule
engine has been advanced. Although not well defined, the implicit purpose of the rule
engine is to provide an efficient mechanism for rule administration and use. The
functionality of a rule engine can range anywhere between the following two extremes
depicted:
§ The functionality is that of a passive library that is used only to contain rule
definitions. The library usually has functions that allow rules to be created,
deleted, copied, and manually browsed, but there is little additional
functionality. Although better than nothing, this type of rule engine is
minimally useful. It is not possible to use this type of engine with
implementation methods 5, 6, 7, and 8, as defined in the list in Section
5.5.4. That severely limits the effective use of rules in the operation of the
business.
§ The functionality is that of a full-function repository utilizing an explicit robust
rule metamodel. This engine would allow the full range of implementation
methods as well as provide for the efficient reuse of rules. Configuration
management functions would be enhanced through automatic discovery of
rule conflicts, overlaps, and possibly gaps.
To achieve the second type of rule engine, a large number of problems must be

addressed and solved. Further discussion of what is needed to accomplish the
realization of this engine is beyond the scope of this chapter. The main purpose of
including the concept of a rule engine is to alert readers that they should be cautious in
assuming a specific meaning when they encounter the term.
Some types of rule engines being offered are modified inference engines, database
constraint checkers, and workflow engines. Those are all legitimate implementations, but
each has a relatively narrow focus. Examples of uses of these types of engines are given
in Section 5.8.


5.8 Rule system
An illustration of the architecture for a complete business rule system as utilized in the
implementation of a process is presented in Figure 5.2; the discussion given in this
section is based on the diagram in the figure. In addition to the end user, five different
human-oriented roles are shown: administrator, owner or agent, analyst, software
developer, and data modeler. Those roles could be performed by five different staff
members, or they could be combined as warranted. In addition, some parts of the roles
may be automated through the use of expert systems or similar approaches. For the
purpose of this discussion, however, it is assumed that the roles are performed by
individual staff members.
Because Figure 5.2 is designed to show a systems approach to the operational
environment for business rules, it must incorporate many interrelated functions and
entities necessary to the implementation of a process. If the reader is unfamiliar with
some of them, the terms and functions presented in the figure are discussed in other
areas of the book.

Figure 5.2: Rule system architecture.
The administrator assigns the proper characteristics, such as a specific implementation
type, and places it in the repository. If new functionality is needed to accommodate the
implementation type, it must be acquired and provisioned by the enterprise organizations

responsible for that type of activity before creation is considered complete.
Before being made generally available, the new business rule (or set of business rules)
should be simulated to determine possible effects on the enterprise. Some activities to
determine potential significant overlaps, gaps, inconsistencies, and conflicts with existing
rules should be performed through a reasoning and analysis process. That may require
simulation and other forms of testing using the experience and knowledge of staff
members along with an automated tool assist.
As an example of the reasoning and analysis required, consider the following two rules
concerning business travel:
1. “All travelers on company business will fly at the lowest available airfare.”
2. “No employee traveling on company business will be compelled to stay
over a weekend unless the business purpose spans the weekend.”
In many cases, the two rules will conflict because the lowest airline fare will require a
weekend stay. It would be useful to analyze rule sets to determine where conflicts of this
type exist. The rules could then be adjusted to remove the problems. As an example, the
following rule contains the essence of the two travel rules while removing the conflict: “All
travelers on company business will fly at the lowest available airfare that does not
require a weekend stay unless the business purpose also requires a weekend stay.”
This rule system is based on a single repository for all rules but allows the utilization of
multiple rule engines for different rule implementation types. The repository itself can, of
course, also be considered to be a type of rule engine and used directly as indicated.
That direct use may or may not be practical, but it needs to be considered for
completeness. The use of the single repository permits an effective simulation function
and the ability to reason about the effect and purpose of each individual rule or multiple
rules in combination. This type of analysis is critical in ensuring that each rule or set of
rules correctly fulfills its intended purpose, regardless of how they are implemented. In
addition, the single repository facilitates the life cycle management of the rule base.
Because of its central position in the analysis and management of the rule base, the
format of the rules in the repository is generally suited to these purposes. Many rule
formats will be required for the effective use of the rules under different circumstances

and environments. It will be necessary to convert the repository rule form to multiple
representations, depending on the desired characteristics of the rule under operational
conditions.
The design of the repository business rule metamodel, including the necessary
classification taxonomies, is also of critical importance. This class model serves as the
main mechanism for ensuring the integrity of the rule base and preventing undue
proliferation of rules. Although it generally will not be used as part of the real-time
operational environment, it is central to its proper functioning.
Figure 5.2 depicts many of the implementation types discussed in previous sections.
Although not theoretically necessary, each type usually involves a format change. The
diagram illustrates how the same task can make use of rules with different
implementation types. That is the usual situation in software development and shows the
importance of determining the effect and compatibility of the different rules as a separate
step in the development process.
For example, Task 1 uses two business rules in two different ways. First, it uses rules
that have been compiled from the repository into a run-time library. The rules are not
incorporated into the task but, in effect, constitute a type of database and are accessed
in much the same way. The characteristics of the rules are that they are changed
frequently and also need to be accessed on a frequent basis. The compile function
places the rules in a format that facilitates their access by the task. The complexity of the
rule format is borne by the compiler, not by the task.
An autocompile function is shown as the compile mechanism in the diagram. That
means that whenever an appropriate rule is changed in the repository, it is automatically
compiled and placed in the run-time library. A manual compile also could have been
used, but if there is a significant amount of change, the autocompile probably is better. A
manual compile function is shown later to depict the concept separately. The
characteristics of rules with this implementation type are that they change frequently and
need to be accessed at a moderate rate.
In addition to the use of a run-time library, Task 1 uses some business rules directly from
the repository. The characteristics of the rules are that they are changed frequently but

are accessed only rarely. The format complexity must be borne by the task, because
there is no conversion from the representation used in the repository to one better suited
to the operational task. It is possible, however, to provide a real-time translation function
or interpreter to change the format. That would be a reasonable approach if there were
several tasks that could use the same interpreter. If the interpreter would be used by only
a single task, there would be no reason not to make it a component of the task and not
keep it as a separate entity.
In general, unless the change rate of the rules is much greater than their access rate,
this type of implementation should not be used. If at all possible, the repository should
not be an integral part of the real-time software operations environment. It is much better
suited to a non-real-time role. In addition, the characteristics that would make this type of
implementation desirable do not seem to represent a practical situation.
In the diagram, a workflow manager is used as the control mechanism for the tasks. The
manager depends on business rules to determine the execution conditions for the tasks
and to monitor their operational performance. The rules are present in the repository but
must be translated to the form needed by the workflow manager. After translation, the
rules become resident in the workflow manager, becoming a replicated copy of the
original rules. The characteristics of these rules are that they are changed relatively
infrequently and the input format required by the manager is fixed and not under control
of the enterprise.
Although not made a part of the diagram to manage its complexity, many other software
components can require business rules in a manner similar to that of the workflow
manager. They need business rules to be entered in a fixed prespecified format
(probably different for each package). These components could exist in either the
infrastructure (e.g., security packages) or application (e.g., accounting packages)
domain.
Task 2 uses rules that must be interpreted by the software designer and then
implemented as an integral part of the final software product. This is the situation found
in most previous and current software implementations. The business rules are utilized
by incorporation as part of the source code and in many instances have difficult-to-

understand representations. In addition, past and current software practice does not use
an explicit form of the incorporated rule, as is indicated by the repository. The rules exist
only in the software code form.
There are legitimate reasons for using this type of rule implementation as long as the
rule is also replicated in the repository. Efficiency considerations in the form of response
time or throughput requirements may mandate this implementation approach. However,
because this approach is prone to significant error in the translation, comprehensive
testing and simulation probably would be necessary to ensure that the rule
implementation conforms to the original. Characteristics of business rules with this
implementation type are very infrequent changes and high access rates.
Task 3 uses two different rule implementation types. The first is a variation of the type
used by Task 2. It also involves a manual translation of the business rule, as depicted in
the repository, into actual software code. The difference is that the code that represents
the business rules is isolated into a separate part of the task. The method is about as
efficient as the Task 2 method and is less prone to errors because of the separation from
the other components of the task. However, because changes will force a recompilation,
the time to make a change will be significant. Rule characteristics for this implementation
are the same as those for Task 2: very infrequent changes and high access rates.
The second type of rule implementation used by Task 3 is an autocompile from the
repository, which is similar to the first implementation type used in Task 1. The difference
is that the compiled rule is part of the task and not part of a separate run-time library.
That may also indicate a format difference between the two because the results of the
compilations do not have to be the same. The characteristics of rules with this
implementation type are that they change frequently and need to be accessed at a
moderate rate.
In addition to using business rules to direct software functionality, they also can be used
to format or change the data used by the software programs. That is illustrated in Figure
5.2 using a direct translation from the repository to the database. It also could be done
on a manual or automated basis, depending on the anticipated frequency of change.
Finally, the business rules can be used to produce printed materials that direct the

manual tasks performed by the end users. In general, any process implementation
requires both manual and automated tasks. Those tasks must be coordinated and
interoperate with each other. Using the same set of business rules as the source for both
types of tasks helps ensure the needed interaction.


5.9 Summary
Business rules are used throughout the enterprise, usually on an informal and
unstructured basis. That prevents achievement of most of the advantages that the rules
can provide. By considering business rules as a fundamental asset of the enterprise and
performing the needed modeling, rules can be utilized to considerable advantage.
Selected bibliography
Herbst, H., “A Meta-Model for Business Rules in Systems Analysis,” Proc. 7th Conf.
Advanced Information Systems Engineering, Berlin, Springer-Verlag, 1995, pp. 186–199.
Herbst, H., Business Rule-Oriented Conceptual Modeling (Contributions to Management
Science), New York: Springer-Verlag, 1997.
Katsouli, E., and P. Loucopoulos, “Business Rules in Information System Development,”
Proc. 2nd Workshop Next Generation of CASE Tools, University of Jyvaskyla, Finland, 1991,
pp. 481–503.
Lang, P., W. Obermair, and M. Schrefl, “Modeling Business Rules With Situation/Activation
Diagrams,” Proc. 13th Internatl. Conf. Data Engineering, Birmingham, UK, Apr. 7–11, 1997,
pp. 455–464.
Rosca, D., et al., “A Decision Making Methodology in Support of the Business Rule Lifecycle,”
Proc. 3rd IEEE Internatl. Symp. Requirements Engineering, Annapolis, MD, Jan. 6–10, 1997,
pp. 236–246.
Ross, R. G., The Business Rule Book: Classifying, Defining and Modeling Rules, Version 4.0,
Boston: Database Research Group, 1997.
Soper, P., Managing Business Rules, Englewood Cliffs, NJ: Prentice Hall, 1997.
Chapter 6: Financial management
Economics—more specifically, financial considerations—are at the core of any

enterprise. Bluntly stated, any profit-making enterprise exists so that the amount of
money it takes in from customers is greater than the amount that goes out in expenses;
the more the better. While that is a relatively easy statement to make, in actual practice,
there are enough nuances to keep armies of people busy trying to define exactly what
the statement means and how best to achieve that desirable condition. A strong
indication of that problem becomes evident as this chapter unfolds.
6.1 The basics
Almost every decision and every action taken or not taken in an enterprise generally are
motivated or justified on the basis of one or more financial metrics whose values are
measured, calculated, or estimated. Unfortunately, depending on which organization or
individuals are involved and the specific procedures and metrics utilized, many of those
references are based on incomplete information and do not always adequately reflect the
true values.
The goal of this chapter is to motivate and define an enterprise financial model that can
be used to provide a financial analysis of any proposed enterprise activity. The
availability of this model is especially important in analyzing decisions concerning the
automation assets. Many of the advantages of those assets as well as the overall asset-
based approach are susceptible to challenge on traditional accounting grounds. To
determine their actual contribution to the enterprise, the financial model and associated
analysis mechanisms must be able to effectively consider all the factors that affect the
automation assets.
The financial model derived here is not perfect. There is still plenty of room for
controversy and differences of opinion. The value of the model is that it forces explicit
consideration of all issues that have a possible impact on the decision as to whether or
not a proposed action (or group of related actions) concerning the automation assets
should be undertaken.
The emphasis of the discussion is on financial philosophy rather than detailed
accounting procedures. However, to provide an embodiment of the philosophy and give
enough detail for suitable examples, some reliance on accounting terms and principles is
necessary. Those terms and principles are explained as necessary, so a detailed

knowledge of accounting is not required.
The points raised here are not meant to always apply to each and every aspect of the
enterprise. It is necessary, as in the case of any proposed analysis or activity, to
evaluate the advantages and disadvantages before deciding that a proposed procedure
or technique is appropriate and necessary. A decision also must be made as to whether
to utilize informal or formal approaches to meet the needs of a particular situation.
Formal approaches using explicit models and procedures usually provide better results
but at a cost that may or may not be worth the improvement.
In addition to presenting the financial needs of the automation assets and the reasons
that a conventional financial and accounting approach generally will not provide the
desired results, the discussions in this chapter are designed to provide a better
understanding of some of the more pervasive financial and accounting criteria and the
inherent limitations of their use.
6.1.1 Basic equations
The financial or accounting aspects of the enterprise are summarized by two equations:

assets −
liabilities =
equity
(evaluated
at a
specific
point in
time)



equity +
(revenue
−

expenses)
= revised
equity
(evaluated
over a
specified
time
period)

where assets are items that can be used for the production of revenue; liabilities are
items that reduce the future capability to create revenue; equity is a measure of the
worth of the enterprise; revenues are items that increase equity; and expenses are items
that decrease equity.
The equations also incorporate some inherent assumptions that are addressed in the
discussions that follow. For ease in use, the five variables in the equations hereafter are
known as the financial categories of the enterprise.
While the equations must always hold for a given enterprise, they cannot indicate the
many underlying aspects that are necessary for the successful operation and continued
existence of an enterprise. The equations can only represent static conditions, while an
enterprise is fundamentally a dynamic asset. Thus, the dynamic (process) aspects also
must be considered to provide a complete characterization of the financial aspects of the
enterprise. Those aspects are addressed shortly.
The terms expense and cost are used here somewhat interchangeably, as common
usage dictates. Although they are intended to signify different meanings, it is not useful
for current purposes to be rigorous in that respect.
6.1.2 Asset transformations
This section is concerned with the dynamic aspects of the enterprise. Enterprise
dynamics can—and usually do—consist of a large number of complex interactions.
However, there are some simple ways in which the basic enterprise dynamics can be
defined and described in the same terms used for the basic financial equations. The

resultant structures and processes can then be utilized in the construction of the desired
financial model.
The fundamental dynamic of the enterprise is to transform assets into revenue, as
illustrated in Figure 6.1. Figure 6.1(a) depicts the basic asset cycle. Depending on the
business of the enterprise and the assets involved, that can be accomplished in a variety
of ways. Physical assets can be sold, leased, or used to provide a service (e.g., house
washing with a pressure washer). Intangible assets (e.g., skills) can be used to provide a
service (e.g., building design). Sometimes assets need to be converted before they can
realize revenue (e.g., beads and string converted into necklaces, which are then sold).
Assets that support the enterprise but that are not in the direct conversion chain also are
considered to contribute to the generation of revenue (e.g., equipment, lights, personnel
skills, automation assets).

Figure 6.1: Basic asset transformation process.
The dynamic model also contains a feedback path, such that the revenue generated can
be used to obtain more assets, which then can be used to generate additional revenue.
That classic case of positive feedback loop would allow uncontrolled growth and
prosperity for the enterprise as long as other activities that tend to inhibit the main
process do not exist.
The major inhibiting activity is that associated with incurred expense. Expense is the
utilization of assets for non-revenue-producing functions. Expense is incurred to pay
employees, provide office space and utilities, and so on. Adding this process to the main
process results in the diagram Figure 6.1(b). As long as the values of expenses and
revenue are such that revenue does not suffer a continuous decrease, the enterprise will
remain viable.
In Figure 6.1 and the others in this chapter, expense is shown as the diversion of
revenue. Such diversion reduces the amount of revenue available to obtain assets. By
considering revenue as a monetary equivalent asset, it is reasonable for the schematic
format shown to show expense as a reduction in that asset. In reality, however, expense
can reduce any monetary equivalent asset.

So far, liabilities and equity have not been accounted for in the dynamics. Liabilities are
merely a mechanism for delaying the actual payment of an expense to keep current
revenue-producing assets at a maximum. For example, if a building is purchased and a
mortgage is obtained for the purchase, the mortgage represents the liability. However,
the whole building asset can be immediately used by the enterprise.
Liabilities can be considered by incorporating the concept in the dynamic process model
shown in Figure 6.1(c). Assuming that equity remains constant, incurring a liability
increases assets by the same amount, while reducing a liability requires an equivalent
amount of asset value.
The first basic financial equation presented in Section 6.1.1 contains only two
independent variables; the third variable is dependent on the values of the other two.
Assets and liabilities usually are assumed to be the independent variables, so equity is
merely the difference between them. If there are no liabilities, then equity is equivalent to
the assets. For that reason, there is no real reason to include equity in the dynamic
model. It can be calculated at any time a value is desired.
The next addition to the dynamic model is the inclusion of internal transformations.
Internal transformations are transformations that are utilized in the enterprise to produce
the financial items needed in the operation of the enterprise. The most frequent
occurrence of such transformations is the conversion of one or more assets into another
asset that is needed by the enterprise. Exchanging cash for buildings, equipment, or raw
materials is a frequent type of asset transformation. Consequently, converting raw
materials and equipment use into a product suitable for sale is another type of
transformation. The transformation chain can contain as many steps as needed. An
example of an asset conversion chain is shown in Figure 6.2.

Figure 6.2: Asset conversion chain.
Although not as frequent, liabilities also can be converted from one form to another (e.g.,
unsecured loan to secured mortgage). Although revenues and expenses also can
assume different forms, their value is the overriding aspect of interest so that the
different forms usually are not considered explicitly except when the associated risk is

materially different. For simplicity, the remainder of this discussion considers only asset
transformations.
The dynamic model developed so far does not include the concept of intangibles.
Intangibles can easily be added to the model, as shown in Figure 6.3. The major
difference between the effect of the intangible assets and liabilities and the tangible
categories is that the intangibles have a direct effect on the ability of the enterprise to
convert assets into revenue. As a part of the asset conversion chain, an intangible asset
enhances the conversion, while an intangible liability inhibits it because the assets are
used to service the liability instead of being used to produce revenue.

Figure 6.3: Transformation process and intangibles.


6.2 Initial financial model
The financial operations of the enterprise have now been defined through a static model
(the basic equations) and a dynamic model, as defined in Figure 6.1(c). The combination
of the two models forms the initial financial model of the enterprise as illustrated by
Figure 6.4. This initial model lacks some constructs that are needed to fully understand
the financial implications. The major missing aspects of the initial model are the drivers
that cause each of the models to change state and explicit consideration of the
automation assets. Those concepts are introduced as the discussion continues and are
used to complete the model.

Figure 6.4: Initial enterprise financial model.


6.3 Financial events
Any driver that causes the values of the categories of the financial model to be changed
is called a financial event. A financial event is any action or activity on behalf of the
enterprise that causes one or more financial categories (assets, liabilities, equity,

revenue, expense) to change value and thereby change the financial state of the
enterprise.
Financial events can result from internal or external occurrences. From a financial
perspective, the enterprise consists of the totality of the effect of all financial events. This
discussion provides more detail concerning the definition and characteristics of financial
events and continues the process of developing an appropriate financial model.
Initially, we examine financial events that result from internal enterprise activity. Financial
events that originate outside the enterprise are then considered and the combination of
the two used to create the completed model.
Financial events can be of any size and may be an aggregate of other financial events. A
simple financial event cannot be subdivided into simpler acts, while a compound financial
event consists of an aggregate of simpler events.
Because the effect of a financial event will, in general, be nonlinear, the financial
consequences of a compound financial event usually will not be a simple linear addition
of the results of all the component financial events. It may be a relatively involved (and
possibly unknown) function of the component financial events. That effect is one of the
major difficulties that limits the application of synthesis techniques to the characterization
of the enterprise financial environment and necessitates the use of measurement and
analysis techniques instead.
A financial event can have long-term or short-term effects. Buying paper for the copy
machine usually results in a one-time expense per purchase (financial event). However,
purchasing some form of investment security is a financial event that may realize
expense or revenue over an extended period of time. Each event has unique
characteristics and needs to be considered separately to accommodate those
differences.


6.4 Financial event model
An enterprise financial event (simple or compound) will be modeled by defining all the
effects that can occur as a result of the event. From the definition of a financial event,

those effects consist of changes in one or more financial categories. Each category can
increase or decrease depending on the specifics of the financial event. It is useful to
further decompose some of the categories to provide enough detail to develop the
different perspectives utilized later in the discussion. In addition, the possibilities of
intangible categories are allowed. That is necessary to partially accommodate financial
implications not captured by the conventional approach to financial analysis.
The resultant model is illustrated by Figure 6.5. For that model, 11 categories have been
defined that need to be examined individually for each financial event. Although most of
the categories are well known, some are not usually stated or examined explicitly. That
lack of consid- eration is one of the main reasons that a financial analysis using a partial
model may give misleading or even wrong results. The major character- istics of all the
categories are discussed briefly, and, as a part of this discussion, their applications to
the automation assets are considered.

Figure 6.5: Financial event model.
Although each model category is discussed separately, they are closely interrelated. For
example, performing a purchase financial event can result in a direct cost, an allocated
cost, an opportunity cost, and an asset transfer. All of them happen simultaneously, and
both their individual values and the aggregate result are important for a variety of
analysis purposes.
In addition to each of the categories being a part of the financial event model, they also
must be used to augment the static and dynamic categories of the initial model. To avoid
undue complexity, that is not explicitly performed during the course of this discussion.
The items are made a part of the completed model produced after the discussion of all
the financial event model categories.
6.4.1 Cost categories
As will be evident from the following sections dealing with costs associated with the
automation assets, costs result from two sources: that associated with the creation and
continuing existence of the assets and that associated with the use of the assets in the
operation of the business. With some few exceptions, the costs associated with the use

of the assets is far greater than the costs needed to define and implement them. That is
a unique aspect of the automation assets. In most normal costing environments, the cost
to provide an asset is the dominant one.
Because of the shift in emphasis for the automation assets, intangible costs become
much more important to consider, and sufficient means to estimate them must be
defined and utilized. Continuing measurements to determine the accuracy of the
measurements also must be utilized. Following the normal procedure results in the costs
assigned to the automation assets to be understated by a considerable amount.
6.4.1.1 Allocated cost
An allocated (indirect) cost is a cost that is incurred in support of a large number of
enterprise financial events; as a consequence, the contribution associated with any given
financial event cannot be known exactly. The amount to be allocated is fixed, and an
algorithm determines the amount assigned. Although the allocated cost often is not
directly controllable, it usually is included in the measurements of accountability. An
allocated cost can be tangible or intangible but should be reasonably matched in time
with the service it represents.
Consider a business rule automation asset. Are there costs that should be allocated to a
business rule? If so, what does this allocation represent? Certainly the costs of operating
the repository as well as those incurred by performing the activities of the other
automation asset management components should be allocated. Those costs, however,
represent a minor effect. The major effect comes from the intangible costs resulting from
the enterprise using the rule to constrain the operation of the business.
Assume the following business rules: (1) “No sales will be made to any customer 60
days or more behind in payments for previous orders” and (2) “No sales will be made to
any customer owing more than $10,000.” Customers denied goods or services because
they fall under the effect of both rules may get mad and give all future orders to a
competitor. Part of the cost of the bad-will and lost orders should be allocated to each of
these rules. The allocation may be uniform or based on the percentage of other
companies that come under only one of the rules. Portions of the estimated intangible
cost also may be allocated to other rules or assets that are found to contribute to the

cost.
The total intangible cost could be estimated by considering the number of customers that
fall under those rules every year, their average yearly orders for past years, and the
percentage that do not place another order within a 1-year period. The fact that there is
an operational cost allocated to the rules does not mean they are bad rules. The amount
saved in bad debts because of either rule may be much larger than the cost they cause.
(The cost avoidance effect is discussed in Section 6.4.2.3.)
6.4.1.2 Direct cost
Direct costs are costs that can be reasonably associated with a specific enterprise
financial event. As with allocated or indirect costs, direct costs can be tangible or
intangible. Using the previous example of business rule assets, direct costs that could be
associated with the rules are those costs that are unique to the rule. If customers are
denied goods or services because they fall under the effect of one of the rules, then that
cost is a direct cost of the rule because it can be reasonably associated with the use of
the rule.
Direct costs are sometimes referred to as variable costs; they exist only because of the
financial event to which they are attached. If the financial event had not occurred, the
cost would not exist. If one of the rules cited in Section 6.4.1.1 did not exist, then the cost
currently attributed to it also would no longer exist.
6.4.1.3 Opportunity cost
An opportunity cost is a cost that is incurred because the occurrence of a specific
financial event prevented another financial event from being performed, and the absence
of that financial event resulted in some cost (or lost revenue) to the enterprise. The most
common example usually is stated in terms of lost interest on money that is spent to
purchase equipment for a specific purpose. The revenue that is lost because the money
was not available for investment is an opportunity cost. The rule of thumb is that the
revenue realized from a financial event should at least be greater than the associated
opportunity cost. Of course, the money also could have been used to purchase other
equipment to produce a different product. The potential revenue from that alternative use
also would be considered an opportunity cost.

The opportunity cost associated with the creation phase of an automation asset is the
revenue generated from the direct cost of developing and placing the asset in the
repository. While that could be substantial for assets such as processes, the opportunity
cost associated with the use of the asset is usually far greater. The cost of utilizing a
given process in labor costs and computer costs is large; therefore, so are the
opportunity costs.
6.4.2 Revenue categories
Unlike costs, revenue usually is associated only with the use of an asset and not with its
mere existence. The use of the asset may be to convert other assets, to transfer
ownership to someone else (e.g., a sale), or to retain ownership and charge for its
continuing usage (e.g., a lease, a license, or a service). That is in keeping with the more
traditional approach to revenue accounting. However, other unique aspects to the
revenue aspects of the asset management system must be considered. One of those
aspects is the concept of allocated revenue. Why that concept is useful in the asset
management system and the major considerations involved are discussed next.
6.4.2.1 Allocated revenue
In most revenue generation situations, the cause of the revenue can be readily
determined. In the case of the automation assets, that is not the usual condition because
of the number of assets that may be involved and the implicit, rather than explicit,
contribution to the revenue.
Consider, for example, a scenario that is used to develop and test a process
representation. The process is used as the basis for a workflow, and the workflow is
used to provide a service that generates revenue. The scenario certainly contributed to
the realization of revenue. Why and how much of this revenue should be allocated to the
scenario? This discussion provides a partial answer.
The automation assets need to have revenue allocated to them to indicate their value to
the enterprise. In far too many cases, the concept of cost centers is utilized as one type
of component of the enterprise. Cost centers, as their name implies, are considered to
be pure cost and, by implication, a bad thing to have. Management is always trying to
reduce the cost associated with a cost center. Cost centers are always contrasted with

profit centers, which, again by implication, are considered good things to have. After all,
who does not want profit?
In reality, there is no such thing as a cost center. It is a fiction of accounting, defined for
convenience. From the perspective of the dynamic model, all costs contribute to the
generation of revenue, and all revenue is the ultimate result of incurring cost. If there are
costs that do not contribute to some aspect of the generation of revenue, they easily can
be eliminated, and the profit of the enterprise will increase by the same amount. By
allocating revenue to the financial events that resulted in costs of some type (whether
they occurred in a cost center or a profit center), the true contribution of the financial
events to the effective functioning of the enterprise can be determined. It easily could be
true that increasing the cost incurred by a cost center would provide an even greater
increase in revenue to the enterprise.
Activity-based costing, which is designed to determine the relative contribution to cost of
the activities in a process, provides only half the needed information. The other half is
activity-based revenue, which provides an allocation of revenue to each of the same
process activities. If the allocated cost is greater than the allocated revenue, that
indicates that the process activity is badly designed and needs to be changed or that the
allocation algorithm requires adjusting.
Now that the “why” part of the revenue allocation has been considered, the remaining
need is to discuss how the allocation should be made, specifically in the case of the
automation assets. Because of the number of assets involved, the allocation probably
should be made on the basis of an entire asset class or a major subclass. If desired,
another allocation based on some type of averaging could be made to the individual
assets.
The allocation algorithm probably will be structured around the use of an “elimination”
technique. That is accomplished by asking the following questions: What would be the
effect on revenue if the asset class did not exist? Would it be reduced by 0.1%, 5%, or
75%? Would the revenue be increased by some amount? While the last question may
seem strange, consider the business rule example used previously. If it was decided to
eliminate the restriction placed on customer orders imposed by the rules, the total

revenue of the enterprise conceivably could increase. However, so would the risk factor
associated with that revenue, resulting in a cost associated with unrealized revenue or
simply bad debts. In fact, it would be hoped that the cost avoidance allocation (see the
discussion in Section 6.4.2.3) would be greater than the negative revenue (cost)
allocation.
The effect on revenue can be difficult to determine, but if the enterprise is to understand
the causes and effects of its individual and compound financial events, an approach to
providing that type of information needs to be developed and actively utilized in the
decision-making process.
Returning to the example of the scenario asset, the prior discussion indicates that the
allocation of revenue could be accomplished as follows. Assume that the scenarios did
not exist, resulting in processes that had to be tested and verified another way, possibly
on “live” customers. If that approach resulted in a longer time to reach operational status
and, based on historical data, resulted in 5% fewer customers, then the lost revenue due
to late process availability and the reduction in customers would be partially allocated to
the scenario assets involved in the process.
Remember that the revenue reduction assumption is only an estimation procedure used
by the analysis process to determine the contribution of the scenarios to the overall
revenue and thus indicate their contribution to the enterprise revenue.
6.4.2.2 Direct revenue
As opposed to allocated revenue, revenue that can be identified as a direct result of a
given asset should be entirely associated with that asset. Unlike costs, there are few
instances in which revenue can be considered as only being associated with a single
asset or other enterprise financial event. The generation of revenue is almost always the
result of the interaction and contribution of many enterprise activities. One exception
might be a sole practitioner providing medical or legal advice for a fee. Even then, there
probably are other associated financial events that would have part of the resultant
revenue allocated to it.
In spite of the view expressed in the preceding paragraph, most revenue realized by an
enterprise is assumed to be the result of a single financial event. That is because the

allocation activity is not performed and there is a need to associate revenue with some
enterprise financial event. The revenue resulting from a sale is attached to the asset or
service sold. The contribution of other enterprise financial events to the realization of the
revenue is not considered. To restate the point, this method of associating revenue is
what makes it so hard to justify individual components of the enterprise that are
important, but for which only a cost category is identified.
6.4.2.3 Cost avoidance
Cost avoidance is the result of an enterprise financial event that negates the need to
incur a cost. Cost avoidance is a type of revenue because it increases the ultimate
amount of funds available to an enterprise over that which would be available had not
the financial event been performed. However, that aspect must be viewed with extreme
caution, as the following discussion indicates. Two types of cost avoidance, each with
somewhat different characteristics, are defined. For convenience, they are labeled weak
avoidance and strong avoidance.
The first type, weak avoidance, is similar to that realized by buying an item on sale. If the
usual price is $10.00, but the item is purchased on sale for $8.00, then a cost of $2.00
has been avoided by meeting the terms of the sale. The reason that financial event is
termed a weak avoidance is that, had the item not been purchased, there would have
been no obligation to pay the $2.00. The existence of the cost that is avoided is created
by the very financial event that avoids it. It easily can be argued that this is not a cost
avoidance financial event at all but merely presents a different decision cost for an item
that may or may not be purchased.
The strong type of avoidance is much more powerful in its effects. In this case, the cost
still exists even if the financial event that could avoid it does not occur. An example is the
receipt of an invoice that is due in 30 days. The terms of the invoice state that if it is paid
in 10 days, only 98% of the total amount needs to be paid. That is the usual commercial
practice of “two 10, net 30” payment terms. By paying the invoice within the 10-day
period, a cost of 2% of the invoice is avoided. If the payment is not made in the 10-day
period, the entire amount must be paid. A real savings can result from strong avoidance.
Another example of strong cost avoidance results from the potential reuse of an

automation asset (e.g., software component). If the asset is reused, the need to incur
cost to provide a new asset is avoided. If it is not reused, the cost for the asset still
exists. Cost avoidance is one of the major contributions of the automation assets.
6.4.3 Asset and liability categories
Not all financial implications occur from revenue and expense con- siderations. Changes
in asset values and liability values also are important aspects of enterprise financial
events. The major difference from the model categories defined in this section and those
used in the usual accounting sense are again associated with intangibles, specifically the
concept of intangible liabilities. As will be pointed out, neglecting the explicit effect of
intangibles can cause the enterprise to fail.
It is interesting to note that the intangible aspects, while not considered part of the
conventional accounting treatment of an enterprise, probably are one of the most
important considerations of the stock price of a public company. Companies do react to
that by engaging in public relation campaigns and so-called institutional advertising,
which are designed to make people feel good about the company and its brands. In a
real sense these costs are not expenses but an asset conversion from a monetary asset
to the intangible asset of positive consumer perception. However, by not reflecting the
financial effects of these intangibles down deep into the enterprise, the best opportunities
to reinforce the good actions and correct the bad actions are lost.
6.4.3.1 Tangible assets
Many financial events result in an exchange of one asset type for another. The sale of an
inventory item realizes revenue and results in a reduction in the value of the inventory
asset and an increase in the cash asset. The purchase of office supplies results in an
expense, an increase in the office supplies asset, and a decrease in the cash asset.
In addition, a financial event can cause the value of an asset to change without resulting
in a transformation, the realization of revenue, or the incurring of a liability. Those
changes may or may not be associated with a revenue or expense component. An
example is the reduction in price of certain inventory items to sell them more quickly.
Outside financial events also can result in asset value changes. For example, a
competitor bringing out a new line of merchandise can cause the inventory value to

decrease considerably.
The valuation of enterprise assets is open to some interpretation. If a tangible asset is
purchased for some amount of money, it usually (but not always) can be assumed that
the value of the asset, at the time of purchase, is the amount paid. After that period,
asset value can increase, decrease, or remain the same. Although usually expressed in
dollars, it is difficult to determine against what measure value should be determined.
As a simple example, assume that the intrinsic, or absolute, worth of some asset
remains constant throughout its life. If it was purchased for $10.00, then, depending on
inflation, it will be worth more after some amount of time. The dollar value increases, but
the absolute value does not. Because of that difficulty in measuring the intrinsic worth of
an asset, standard accounting practices do not consider those types of changes unless
they are realized by an explicit financial event, such as the sale of the asset. If the asset
in this example were sold for $13.00, the gain in the dollar value of the asset would be
recognized. At any given time, using only standard accounting information, it is difficult to
determine the financial eventual value of the tangible assets. The intangible assets are
even harder to value, as discussed in Section 6.4.3.2.
From an asset management system perspective, the expenditure of resources is the
financial consequence of creating an automation asset. The difficulty lies in the
determination of the value of the automation asset. Is it the cost of creating the asset, the
projected cost avoidance obtained from the reuse of the asset, the amount of future
revenue that can be realized from the asset, or some combination thereof? Although a
great deal of attention is not given to the valuation of the automation assets, it is
important to obtain some degree of comprehension as to the value of the assets. That is
measured in dollars because it is the only real comparison available to the enterprise.
6.4.3.2 Intangible assets
Consider the development of a software component asset. How should the value of the
component be determined so that any project using the component could be charged
appropriately? In this case, the value probably should be determined by utilizing the
development costs as a base. That is in contrast to most attempts at evaluating this type
of asset, which use as an estimate the number of times the asset is expected to be used.

That type of estimate is relatively unreliable because usage is difficult to predict. Even if
the asset is used in a project, its worth would stay the same if the asset is still considered
to be viable. The value obtained through use could be thought of as a cost avoidance
revenue. Methods of valuing software components as one specific case of great interest
are discussed in Chapter 14.
As difficult as it is to estimate the worth of a software component, it is more difficult to
estimate the worth of other automation assets, such as a business rule. The cost to
develop a specific business rule is usually quite low, while the effects of the rule can be
quite large, as indicated in previous examples. Because of the difficulty, the temptation
would be to forego a valuation. However, some value must be placed on the asset if it is
to be treated with the respect accorded the other enterprise assets and show that it is
part of the asset conversion chain that ultimately results in revenue. Simply expensing
the cost of creating the business rules is an informal indication that they have no
continuing value and are, in a sense, throwaway items.
The easiest approach to the valuation problem in this instance is probably the same as
utilized for tangible assets. Assign the class of business rules a value consistent with the
cost of creating them. While that probably understates their real value to a considerable
extent, the major goal is to treat them as assets, not necessarily to provide as accurate a
valuation as possible. An absolute valuation of asset worth probably is not a reasonable
goal to pursue anyway.
The importance of assigning a value to the automation assets is to treat them in the
same way as the other assets of the enterprise. At a minimum, the costs associated with
their creation should be capitalized and not treated as an immediate expense. When that
is not done, there is an increased tendency to view the assets as having little intrinsic
value because no other effective way exists to estimate their continuing contribution to
the operation of the enterprise. Even if financial accounting rules do not allow
capitalization of those assets, this should be done from a management accounting
perspective.
6.4.3.3 Tangible liabilities
As with assets, an enterprise can change its liabilities by performing an appropriate

enterprise financial event. The major difference is that the valuation of tangible liabilities
usually is not difficult. The liability almost always is the amount owed in dollars. The
connection with the automation assets usually is indirect because there is no concept of
liability, per se, in the asset management system. Assume that a decision is made to
procure a certain software component and make it an automation asset. If the purchase
price is borrowed, then a liability is created that is associated with the asset. The
association is relatively unimportant, however, since the key is the availability of the
asset itself, not the means by which it was financed.
6.4.3.4 Intangible liabilities
In many cases, intangibles are more important than the tangible financial categories. The
same is true for the liability aspects of the asset management system. One of the most
important intangible liabilities is negative customer perception of the enterprise or its
products. If the perception is large enough, it can easily overwhelm the assets of the
enterprise and cause an effect that is the same as if the tangible liabilities were much
greater than the assets. It can throw the enterprise into bankruptcy. The relatively recent
near-bankruptcy experiences of Ford Motor Company and Chrysler Corporation can
easily attest to that fact.
What does the asset management system have to do with the intangible liabilities? The
answer is that, properly considered and utilized, it can go a long way toward preventing
the occurrence of this type of liability. One of the main purposes of the asset
management system and associated assets is to allow the enterprise to standardize and
measure the effectiveness of its operations and thereby improve the service to its
customers. The asset management system, or lack thereof, directly affects the existence
of any intangible liability.
6.4.4 Equity categories
Because equity is merely assets less liabilities, there is no need to treat equity as a
separate topic, especially as it relates to the asset management system. Although an
enterprise spends a significant amount of time raising equity through stock sales or other
activities, the goal is not really to increase equity, it is to increase the assets available to
the enterprise without increasing liability. By focusing on the increase in assets, the

equity is carried along.
Because intangible assets and liabilities have been defined as possible categories of
both the static and dynamic enterprise models, the concept of intangible equity also must
be defined. In the same manner as that defined for the tangible categories, this type of
equity is merely the difference between the intangible assets and the intangible liabilities.


6.5 External financial events
External financial events are occurrences that:
§ Originate from outside the enterprise;
§ Are not controllable by the enterprise;
§ Change the value of at least one of the 11 financial categories of the financial
event model.
External financial events represent the randomness of the enterprise environment and
the need for the enterprise to operate in such a manner as to reduce the effect of those
events to a minimum. From a financial perspective, that means the definition and
utilization of internal financial events in such a way that the enterprise is least vulnerable
to outside forces. This is a type of risk management that should be explicitly utilized in
any type of financial and operational planning for the enterprise.
By adding a representation for external financial events to the enterprise dynamic model,
the dynamic model is completed. That model, along with the augmented static model
developed previously, now can be used to structure the evaluation of any proposed
financial event.