DETERMINING REQUIREMENTS AND SPECIFICATIONS OF
ENTERPRISE INFORMATION SYSTEMS FOR PROFITABILITY
K. Donald Tham
Dept. of Mechanical and Industrial Engineering, Ryerson University, Toronto, Ontario, Canada, M5B2K3
Mark S. Fox
Dept of Mechanical and Industrial Engineering, University of Toronto , Toronto, Ontario, Canada, M5S3G9
Keywords: Traditional costing, traditional Activity-based
Costing (ABC), enterprise model, ontology, strategic
intelligence, Enveloped Activity-Based Enterprise Model (EABEM™)
1
, Temporal-ABC™
2
.
Abstract: A company’s profits may be defined as the posit
ive difference between its income revenues and operational
costs. Today, most companies use traditional costing methods and/or traditional Activity-Based Costing
(ABC) to determine their operational costs with a view to direct operational and business process changes
so that profits are realized. A tripartite approach is presented towards determining requirements and
specifications of enterprise information systems for profitability (EISP). In the first part, an understanding
of the nuances of traditional costing and ABC as is currently practiced in enterprises is presented to point
the shortcomings of these current costing practices. The second part provides a case study that vividly
demonstrates the problems in the current costing methods and clearly points their inadequacies towards
profitability. The third part presents a framework for the specifications of enterprise information systems
for profitability through ontology-based enterprise modeling, EABEM and Temporal-ABC for the
attainment of improved knowledge about costs.
1
EABEM is a trademark of Nulogy Corporation.
2
Temporal-ABC is a trademark Nulogy Corporation.
1 INTRODUCTION
A company’s profits may be defined as the positive
difference between its income revenues and
operational costs. Today, most companies use
traditional costing methods and/or traditional
Activity-Based Costing (ABC) to determine their
operational costs with a view to understand and
direct operational and business process changes so
that profits are realized.
If Enterprise Information Systems for
Profitab
ility (EISP) are to be developed, first, the
determination of requirements and specifications
for such systems must be based upon a clear
understanding of current costing methods and the
shortcomings of such methods towards profitability.
Second, achieving systemic profitability must
begi
n with improved knowledge about costs. From
production floor worker, to office clerk and
administrator, to chief executive officer – there must
be actionable and unambiguous cost knowledge to
guarantee a superior return on capital investments, to
ensure fewer operational mistakes, to make better
use of resources, and to ensure profit generation.
These challenges are interdependent and evolving
operational problems that enterprises need to solve
on an ongoing basis towards achieving systemic
profitability. Thirdly, one way to effectively access
and share information towards costs of products,
services, processes and systems of an enterprise is to
represent and reason about costs using ontology-
based enterprise models [Kosanke, 1997].
A tripartite approach towards determining
requirem
ents and specifications for EISP is
presented. In the first part, an understanding of the
nuances of traditional costing and ABC as is
currently practiced in enterprises is presented to
point the shortcomings of these current costing
practices. The second part provides a case study that
vividly demonstrates the problems in the current
309
Donald Tham K. and S. Fox M. (2004).
DETERMINING REQUIREMENTS AND SPECIFICATIONS OF ENTERPRISE INFORMATION SYSTEMS FOR PROFITABILITY.
In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 309-316
DOI: 10.5220/0002652803090316
Copyright
c
 SciTePress

costing methods and clearly points their
inadequacies towards profitability. The third part
presents a framework for the specifications of
enterprise information systems for profitability
through ontology-based enterprise modeling,
EABEM, and Temporal-ABC for the attainment of
improved knowledge about costs.
2 EXPLAINING THE NUANCES
OF TRADITIONAL COSTING
AND ABC
Traditional costing systems use volume-driven
allocation bases such as direct labour hours, direct
machine hours, direct labour dollars, direct material
dollars, and sales dollars as the primary means of
assigning organizational expenses and overheads to
individual products, services and customers.
However, many of the resource demands by
individual products and customers are not
proportional to the volume of units produced or sold.
Thus, traditional cost systems do not measure
accurately the costs of resources used to design, to
produce, to sell and to deliver products to customers.
In general, according to Cooper [1988a][1988b]
and Kaplan [1988], the apportionment of indirect
and overhead costs to products and service products
based on volume related units such as direct labour
or machine hours according to traditional or
conventional cost systems provide irrelevant costs
for decision making and for the determination of
product or service profitability.
Kaplan and Cooper of Harvard Business School
developed the ABC Principle as an approach to
product or service costing as a means to overcoming
some of the problems with traditional costing
systems. These problems are exacerbated in that
existing enterprise modeling frameworks provide a
modeling infrastructure that tend to support
traditional cost systems [Tham & Fox, 1998].
The traditional ABC Principle includes the
assignment of costs to activities based on their use of
resources, and the assignment of costs to “cost
objects”
3
based on their use of activities [Cokins,
2001]. Since ABC assigns costs to activities based
on their use of resources, the logical formulation of
3
Within the ABC literature, the term “cost objects” refers
to the reasons for which activities are performed in
enterprises. Products, services, and customers are
considered cost objects as they may be the reasons why
activities are performed.
ABC must be premised upon the existence of some
given or identifiable costs of resources.
Nothwithstanding this obvious rationale, the
fundamental question then that begs to be asked at
the macro level is :- “From where and how does one
get the costs of resources for ABC?” At the more
micro level, and definitely from an ABC
implementation perspective, two fundamental
questions arise relevant to ABC:- (i) What unit
resource costs are associated with a resource? (ii)
How does one deduce unit resource cost(s) so that
direct, indirect and overhead costs are accounted for
within the costs of a resource?
According to the ABC concept, costing of cost
objects proceeds with the assignment of cost to
activities based on their use of resources, and the
assignment of costs to cost objects based on their use
of activities. First, the question is: From where and
how does one get the costs of resources for ABC?
Second, ABC emphasizes the need to obtain a better
understanding of cost behaviour and thus ascertain
what causes the overhead costs. However, towards
solving the question and fulfilling this need, there
are some problems that influence the feasibility of
ABC being applied to enterprises.
Let us examine the current costing process in
ABC as is done in existing ABC related softwares.
ABC is typically accomplished in a two stage
process. In the first stage, the cost assignment of
resources to an activity is accomplished through a
resource cost assignment phase through “resource
drivers”. In the second stage, the cost assignment of
activities to cost objects is accomplished through
“activity drivers”. A resource driver is a measure of
an activity’s resource consumption. It is used to
determine the portion of the total cost assigned to
each activity that uses the resources. Resource
drivers take cost from the general ledger and assign
it to activities. An activity driver is a factor used to
assign cost from an activity to a cost object.
Activity drivers are the mechanisms for assigning
the costs of activities to products. An activity driver
is a measure of the frequency of activity
performance and the effort required to achieve the
end result. In short, various factors referred to as
resource drivers, are used to assign cost to activities;
whereas activity drivers are methods for assigning
the cost of activities to cost objects.
Besides contending with the confusing selection
of resource drivers and activity drivers, the current
ABC user must also contend with the concept of
“cost drivers”. Cost drivers are associated with the
input of activities towards cost objects. Cost drivers
are supposed to reflect what causes an activity to be
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
310

performed and what causes the cost of performing
the activity to change. An ABC system achieves
improved accuracy in estimation of costs by using
multiple cost drivers to trace the cost of activities to
the products associated with the resources consumed
by those activities. Hence, this leads to an ABC user
involved in an “art” towards ABC implementation
rather than a “science”. The “art” attempted
involves making two separate but interrelated
decisions about the number of cost drivers needed
and which cost drivers to use. The “art” gets further
confusing because the cost drivers selected changes
the number of resource drivers and activity drivers
needed to achieve a desired level of accuracy.
In summary, the current state of the “art”, or
perhaps, better stated as the problems in ABC
implementations today have led to the following
conclusions:-
1. Based upon the “artful” selection of cost drivers,
resource drivers and activity drivers, “overhead
and indirect costs” get allocated and included into
the cost of a cost object through cost pools.
2. According to the Armstrong Laing Group
[Armstrong, 2002]:- “One of the most difficult
parts of ABC implementation is the identification
and selection of suitable drivers…..you need to be
open to the idea that you may have to change
your assumption about driver assignment, and so
choose a solution that allows this easily.”
3. According to Babad & Balachandran [1993]:-
“An ABC system achieves improved accuracy in
estimation of costs by using multiple cost drivers
to trace the cost of activities to the products
associated with the resources consumed by those
activities. In this respect, a cost driver is an
event, associated with an activity, that results in
the consumption of the firm’s resources.”
4. According to Cooper [1988a][1988b]:- “The art
of designing an ABC system can be viewed as
making two separate but interrelated decisions
about the number of cost drivers needed and
which cost driver to use. These decisions are
interrelated because the type of cost drivers
selected changes the number of drivers required
to achieve a desired level of accuracy.”
5. Due to the increasing costs of overheads, current
ABC softwares and implementations use cost
pools for overheads drawn from the traditional
General Ledger cost accounting systems for the
allocation of overheads to products and services.
However, according to Gary Cokins [1996]: “In
effect, traditional general ledger cost accounting
systems act like thick cloud covers. The clouds
prevent any observation, and eventual
understanding, of the locations and rates at which
the enterprise uses resources to enable the
creation of value or to actually create value for
customers.”
The aforementioned statements express a need to
operationalize the cost assignment with better
consistency, better accuracy, better traceability of
“overheads and indirect costs”, and less ambiguity.
With regard to ambiguity, notice the confusing
usage of terms – resource driver, activity driver,
cost driver, event and drivers.
Given that there can be several different resource
drivers and activity drivers, the cost of the activity is
only as good as a resource driver, and the cost of the
cost object is only as good as an activity driver. This
inconsistent costing situation is further aggravated
depending upon cost driver selections, which in turn,
influences resource driver and activity driver
selections. Indeed, a sorry state of affairs – ABC, as
a means to a more accurate and consistent cost
system for better decision making, has been
basically reduced to the confusing art of driver
selections!
3 CASE STUDY: TRADITIONAL
COST ACCOUNTING (TCA)
VERSUS (TRADITIONAL) ABC
Traditional Cost Accounting (TCA) and traditional
ABC as implemented and practiced today is applied
to the following company data to vividly illustrate
the inadequacies of TCA and traditional ABC in a
company’s quest towards profitability.
Company X Data:-
• Produces 100 units of product A and 500
units of product B for year
• Direct labour for product A is 3 hours and
for product B is 2 hours
• Labour cost is $20 per hour and total labour
hours is 2000 hrs per year
• Total overhead cost per year is $100,000
• Cost of overhead (O/H) = $100,000/2,000
hrs = $50/hour
• Activities required for each of products A
and B are:- Setup, Machining, Receiving,
Packing, Engineering
DETERMINING REQUIREMENTS AND SPECIFICATIONS OF ENTERPRISE INFORMATION SYSTEMS FOR
PROFITABILITY
311

TCA in Company X
ABC in Company X
ABC in Company X with Resource
Driver Changes
*Note:- The resource driver - # of Setups – of
Table 2 is changed to Set-up hours in Table 3; and
the resource driver - # of engineering changes – of
Table 2 is changed to Engineering hours in Table 3.
These resource driver changes in Table 3 provide
better traceability and causal information linking
resource consumption by activities that output
Product A and Product B.
4 CASE STUDY CONCLUSIONS
1. Significant differences in cost per unit for Product
A and Product B are seen by comparisons of
Table 1 versus Table 2, and Table 1 versus Table
3. In short, significant differences in cost per unit
for Product A and Product B have resulted by the
application of Traditional Cost Accounting
(TCA) for Table 1 versus Traditional Activity-
Based Costing (ABC) for Tables 2 and 3. More
importantly, the ABC results from Table 2 and
Table 3 provide superior cost information for
profit improvement relative to the cost
information provided in Table 1.
2. On the other hand, by comparing Table 2 and
Table 3, significant differences in cost per unit for
Product A and Product B have resulted due to the
mere changes in resource drivers of Table 2 to
those of Table 3, notwithstanding the fact that
ABC has been applied to both tables. More
importantly, the ABC results of Table 3 are more
accurate and superior for profit improvement
relative to the ABC results of Table 2. The less
accurate cost assignment by allocation in Table 2
due to minimal causal data, has shifted to the
more accurate traceable cost assignment of Table
3 due to better traceability and causal data
changes of Table 3. In short, the accuracy of cost
assignment in ABC and the value of cost
information for decision making varies according
to the degree to which one can establish causal
and traceable data types and relationships (refer
Figure 1).
Decision Making with Cost Information
from ABC
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
312

5 REQUIREMENTS FOR EISP
As illustrated in Figure 1, as data types and
relationships represented by the volume control
button, “slide” from being mere allocation with
minimal causality towards being highly traceable
with maximum causality, the decision making
information from ABC correspondingly changes
from being, inferior, less prescriptive with minimum
accuracy, to becoming superior, highly prescriptive
with maximum accuracy.
Owing to lack of overhead cost traceability and
hence its accountability, companies attempting to
implement ABC form overhead cost pools for
allocation to activities. Too often, different types of
costs are combined into one diffused overhead pool,
so cost object costs are often grossly distorted due to
allocation. Tracing enables one to assign costs
based on specific data, whereas allocation from
pools often involves indirect assignment of costs to
activities.
In short, EISP must be based upon enterprise
data types and relationships that have properties
and/or attributes that are highly traceable and exhibit
maximum causality for their existence. If such data
types and relationships are deployed in EISP, our
case study vividly illustrates that cost information
generated from the application of ABC tends to be
superior, highly prescriptive and maximally
accurate.
6 SPECIFICATION FRAMEWORK
FOR EISP
It is proposed that an ontology-based enterprise
model should form the specification basis for EISP.
First, by doing so, the design issues of enterprise
modeling can be overcome. Secondly, enterprise-
wide strategic intelligence is promoted. Thirdly, an
ontology-based enterprise models can provide a
superior generic modeling infrastructure towards
enterprise profitability through the support of highly
traceable, maximally causal data types and
relationships in all enterprises.
According to Fox & Gruninger [1998]:-
“An Enterprise Model is a computational
representation of the structure, activities, processes,
information, resources, people, behaviour, goals and
constraints of a business, government, or other
enterprise. It can be both descriptive and
definitional spanning what is and what should be.
The role of an enterprise model is to achieve model-
driven enterprise design, analysis and operation.
From a design perspective, an enterprise model
should provide the language used to explicitly define
an enterprise……
From an operational perspective, the enterprise
model must be able to represent what is planned,
what might happen, and what has happened. It must
supply the information and knowledge necessary to
support the operations of the enterprise, whether
they be performed manually or by machine. It must
be able to provide answers to questions commonly
asked in the performance of tasks.”
To represent and reason about costs using an
enterprise model, the model should be descriptive,
i.e., it should represent key entities, structures and
concepts needed to describe the enterprise’s
activities, resources, products, information flows and
costs.
The model should also be prescriptive. It should
be possible to prescribe the costs of activities,
resources and products of an enterprise using this
model.
A number of issues exist concerning the design of
enterprise models [Fox & Grüninger, 1998]. The
issues are:-
1. Reusability: it is concerned with the large cost of
building enterprise-wide data models. Is there
such a thing as a generic, reusable enterprise
model whose use will significantly reduce the
cost of information system building?
2. The consistent usage of the model: given the set
of possible applications of the model, can the
model’s contents be precisely and rigorously
defined so that its use is consistent across the
enterprise?
3. Accessibility: given the need for people and other
agents to access information relevant to their role,
can the model be defined so that it supports query
processing so that answers to common queries in
an agent’s domain, e.g., costing and profitability,
may be obtained.
4. Selectivity: how does one know which is the right
Enterprise Model for one’s application?
An ontology is a data model that “consists of a
representational vocabulary with precise definitions
of the meanings of the terms of this vocabulary plus
a set of formal axioms that constrain interpretation
and well-formed use of these terms” (Campbell &
Shapiro, 1995).
The goal of ontology-based enterprise modeling
is the implementation of an environment that
supports the modeling and design of enterprises. To
support this, ontological engineering deals with the
DETERMINING REQUIREMENTS AND SPECIFICATIONS OF ENTERPRISE INFORMATION SYSTEMS FOR
PROFITABILITY
313

design and evaluation of a shareable representation
of knowledge that minimizes ambiguity and
maximizes understanding and precision in
communication in an enterprise. The product of
ontological engineering is an ontology and/or micro-
theory. An ontology is a formal description of
enterprise objects, properties of objects, and
relations among such objects. A micro-theory,
however, is a formal knowledge required to solve a
problem in a domain (e.g., costing, quality) or
describes a subset of the domain in detail (e.g., ISO
9000 compliance as a subset of quality). A micro-
theory is separate from, but constructed upon an
ontology.
Vocabulary, definitions, and axioms that
describe
the enterprise are
formally represented using
ontologies, and
prescriptions for achieving goals are
formally defined using ontology representations.
Tham [1999] formalizes enterprise activity-based
costing, and prescribes to strategic cost
management. Parts of these models can be
shared
and re-used by others with minimized interpretation
ambiguity because they are modeled formally.
The business environment of an enterprise is
defined by activities, resources, markets,
customers, products, services, regulations and costs
associated with the enterprise. Strategic intelligence
is what a company needs to know of its business
environment to enable it to gain insight into its
present processes, anticipate and manage change for
the future, design appropriate strategies that will
create business value for customers, and improve
profitability in current and new markets. Therefore,
an ontology based enterprise model can provide an
explicit knowledge representation infrastructure of
shared understanding (Gruber, 1993) to promote
strategic intelligence that guarantees profitability.
There is a distinction between a language and
knowledge representation. A language is commonly
used to refer to means of communication among
people in the enterprise. Representation refers to the
means of storing information (aka knowledge) in a
computer (e.g. database). A representation is
essentially a set of syntactic and semantic
conventions that enables one to form a knowledge
repository or database in a computer for usage by
various agents in a distributed systems environment.
The set of syntactic conventions specify the form of
the notation used to express descriptions of the
knowledge entities. The set of semantic conventions
specify how expressions in the notation correspond
to the entities described. With the proliferation of
computer based distributed systems, enterprises can
make significant gains towards data traceability and
causality through the direct communication of
various enterprise processes (aka agents) with one
another. Consequently, the representation of
knowledge becomes the language of communication
for enterprises.
7 ENVELOPED ACTIVITY-BASED
ENTERPRISE MODEL (EABEM)
AND TEMPORAL-ABC
The motivation towards the research and
development of EABEM and Temporal-ABC is
based, first, upon the practical and implementation
needs towards solving the fundamental macro level
question in ABC as stated in Section 2 – “From
where and how does one get the costs of resources
for ABC?” Secondly, as demonstrated in the
previous section, there is need to give every
consideration to enterprise data, i.e., enterprise-wide
information and knowledge, to be represented with
maximum traceability, maximum causality, high
consistency and minimal ambiguity for the eventual
goal of obtaining highly accurate and prescriptive
cost information to support decision making towards
profitability.
Ontologies by design are constructed from
existing ontologies. For example, Kim’s [1999] and
Tham’s [1999] ontologies for quality and costs
respectively are developed using ontologies of
activity, state, causality, time, resource, and
organizational structure that describe fundamental
concepts about an enterprise. These are collectively
called the TOVE Core Ontologies (Grüninger &
Fox, 1995).
Enterprises are action oriented, and therefore, the
ability to represent action lies at the heart of all
enterprise models. In TOVE, action is represented
by the combination of an activity and its
corresponding enabling and caused states. An
activity is the basic transformational action primitive
with which processes and operations can be
represented.
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
314

Activity-State Resource Cluster
An activity specifies a transformation of the world.
Its status is reflected in an attribute called status.
The domain of an activity’s status is a set of
linguistic constants:-
• Dormant – the activity is idle and has never been
executing before.
• Executing – the activity is executing.
• Suspended – the activity was executing and has
been forced to an idle state.
• ReExecuting – the activity is executing again.
• Completed – the activity has finished.
A state in TOVE represents what has to be true
in the world for an activity to be performed. An
enabling state defines what has to be true of the
world in order for the activity to be performed. A
caused state defines what will be true of the world
once the activity has been completed. An activity
along with its enabling and caused state is called an
activity state cluster or simply activity cluster. The
activity-state resource cluster (Fig. 2) is the nucleus
in building EABEM.
States associate resources with activities through
the four types of states which reflect the four ways
in which a resource is related to an activity – use,
consume, release, produce. The status of a state, and
any activity, is dependent on the status of the
resources that the activity uses or consumes. All
states are assigned a status with respect to a point in
time. There are four different status predicates:-
• Committed – a unit of the resource that the
state consumes or uses has been reserved for
consumption.
• Enabled – a unit of the resource that the state
consumes or uses is being consumed.
• Disenabled – a unit of the resource that the
state consumes or uses has become unavailable.
• Reenabled – a unit of the resource that the
state consumes or uses is re-available.
• Completed – unit of the resource that the
state consumes or uses has been consumed or
used and is no longer needed.
EABEM represents the enterprise-wide
infrastructure for representation of information and
knowledge such that various domains of interests
like cost management, performance measurement,
quality, etc., can be supported in the enterprise. A
formalized schema for EABEM may be represented
as follows:-
• E ≡ [Σ
internal resources
∩ (ξ
sig
)] U [Σ
external resources
∩
(ξ
sig
)] U [Σ
activities
∩ (η
sig
)] U [Σ
frontier activities
]
where
• [Σ
internal resources
∩ (ξ
sig
)]: the set of sentences
defining significant internal enterprise resources,
• [Σ
external resources
∩ (ξ
sig
)]: the set of sentences
defining significant external resources (aka as
frontier resources) to the enterprise,
• [Σ
activities
∩ (η
sig
)]: the set of sentences
defining significant activities of the enterprise,
• [Σ
frontier activities
]: the set of sentences defining
the enterprise frontier activities (aka as boundary
activities that representationally envelope or
surround the enterprise). Hence, the coining of
the term Enveloped Activity Based Enterprise
Model – EABEM.
To overcoming the shortcomings of current
practices based upon traditional ABC, the Principle
of Temporal-ABC states:-
• A cost object, i.e., a product or service, is the
reason why activities are performed.
• The assignment of costs to activities is based
upon their requirements of resources and the
possible changing temporal states of those
resources, thereby resulting in temporal costs for
activities.
• The cost of a cost object is based upon the
temporal costs of activities that produce it.
8 CONCLUDING REMARKS
This paper explains the nuances of traditional
costing and traditional ABC methodologies and
points to the inadequacies of these methodologies
towards profitability. Applications of these methods
to a case study, aptly demonstrates that companies
can unwittingly stray away from the profitability
path due to the inferior and incomplete knowledge
about product and service costs produced by these
methodologies. From a systems and information
engineering perspective, the case study provides
DETERMINING REQUIREMENTS AND SPECIFICATIONS OF ENTERPRISE INFORMATION SYSTEMS FOR
PROFITABILITY
315

evidence for the requirements criteria of high
traceability and maximum causality of data types
and relationships for EISP. Finally, a specification
framework for EISP is presented that is founded
upon ontology based enterprise modeling, EABEM
and the Principle of Temporal-ABC.
If profits are to be realized, companies urgently
need to closely question and examine their current
cost management practices towards profitability.
The situation is further exacerbated as companies
throw millions of dollars and countless human
resource hours in the deployment of enterprise
planning systems that incorporate the inadequate
costing methodologies discussed in this paper.
In the hope that the terms and fundamental
philosophies of the Sarbanes-Oxley Act are
embraceable [Gartner, 2003], the following quote
serves best as a practical and real motivation for
adopting “change thinking” towards profitability:-
“Complying with the legal requirements of
Sarbanes-Oxley is one thing; complying with the
spirit of the Act is another. The fundamental
message of the Act is that CFO’s and boards need to
know their businesses better. To comply with the
Act, organizations will need to ensure that their
senior finance managers really understand what
drives their increasingly complex and diverse
operations, and are constantly attuned to any
changes that impact financial reporting and
business performance.” [Armstrong, 2003]
REFERENCES
Armstrong Laing Group Inc., 2003. “The Sarbanes-Oxley
Act Section 409 – Real Time Issuer Disclosure”, ALG
White Paper.
Armstrong Laing Group Inc., 2002. “Activity Based
Costing Implementation Issues”, ALG White Paper.
Babad, Yair M. and Balachandran, Bala V., 1993. “Cost
Driver Optimization in Activity-Based Costing”, The
Accounting Review, Vol. 68, No. 3, pp. 563–575,
July.
Campbell, A. E. and Shapiro, S. C., 1995. Ontological
Mediation: An Overview”, Proceedings of the IJCAI
Workshop on Basic Ontological Issues in Knowledge
Sharing, Menlo Park CA: AAAI Press.
Cokins, G., 2001. Activity-Based Cost Management: An
Executive’s Guide, John Wiley & Sons, Inc.
Cooper, R., 1988a, “The Rise of Activity Based Costing –
Part One: What is an Activity-Based Cost System?”,
Journal of Cost Management, pp. 45 – 54, Summer.
Cooper, R., 1988b, “The Rise of Activity Based Costing –
Part Two: When Do I Need an Activity-Based Cost
System?”, Journal of Cost Management, pp. 41 – 48,
Fall.
Fox, Mark S. and Grüninger, Michael, 1998. Enterprise
Modeling, AI Magazine, AAAI Press, Fall 1998, pp.
109-121.
Gartner Inc., 2003, “The Sarbanes-Oxley Act Will Impact
Your Enterprise”, Research Note, 20
th
March.
Gruber, Thomas R., 1993. Towards Principles for the
Design of Ontologies Used for Knowledge Sharing, In
International Workshop on Formal Ontology, N.
Guarino & R. Poli, (Eds.), Padova, Italy.
Grüninger, M., and Fox, M.S., 1995. Methodology for the
Design and Evaluation of Ontologies, Workshop on
Basic Ontological Issues in Knowledge Sharing,
IJCAI-95, Montreal.
Kaplan, Robert S., 1988, “One Cost System Isn’t
Enough”, Harvard Business Review, pp. 61 – 66,
January – February
Kim, Henry M., 1999. Representing and Reasoning about
Quality using Enterprise Models, Ph.D. Thesis,
Department of Mechanical and Industrial Engineering,
University of Toronto, Toronto, Ontario, CANADA,
M5S 3G9.
Kosanke, K., 1997, “Enterprise Integration – International
Consensus: A Europe-USA Initiative”, Proceedings of
International Conference on Enterprise Integration and
Modelling Technology, Torino, Italy, October 28-30.
Tham, K. Donald, 1999. Representing and Reasoning
about Costs using Enterprise Models and ABC, Ph.D.
Thesis, Department of Mechanical and Industrial
Engineering, University of Toronto, Toronto, Ontario,
CANADA, M5S 3G9.
Tham, K. Donald and Fox, Mark S., (1998), “Enterprise
Models and Their Cost Perspectives”, Proceedings for
Industrial Engineering and Management, Canadian
Society for Mechanical Engineers (CSME) Forum,
Toronto, May 19-22.
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
316