Business Process Implementation for IT Professionals phần 3 doc

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 followi

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

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

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 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

design review of draft materials

to determine

if and to what extent applicable business rules are reflected

in the document text

design review of requirements to determine

if and to what extent applicable business rules are

contained

in the requirements specificati

on Perform complianc

e audit of finished software

to determine

if the software accurately reflects the requirements, including those requirements associate

d with business rules Test finished system to determine

if applicable business rules are being accurately reflected

product with suitable environme

nt conditions designed

to determine

if product reacts properly

to incorporat

ed business rules Test product integrated with the entire

n to determine

if business rules are being interprete

d properly

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

metamodel structure attributes

Table 5.1: Emergency Response Rule Metamodel

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

Detail level: Dispatch function/trouble resolution process

Persistence: Immediately, until rescinded

Implementation

method:

Included in all software requirements dealing with dispatch functionality

Compliance monitor: Design review

Table 5.2: Sales Tax Calculation Rule Metamodel

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

Owner: Chief Accounting Officer

Persistence: Immediately, until rescinded

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 understand representations In addition, past and current software practice does not use

difficult-to-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

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