1

Part I: Problem Statement

2
 3

1. Problem Definition

1.1 Introduction

Today’s organizations operate in a market that is becoming increasingly complex and

dynamic. This can be illustrated with a number of examples. The introduction rate of new
products and services is gathering pace and as life cycles become shorter, products and
services are increasingly tailored to the needs of small market segments or even to the
requirements of individual customers. New distribution channels have been created,
facilitating quick product introduction. To accommodate and implement this increasing
complexity of products, services and distribution methods, organizations are frequently
redesigning their organization structures and business processes, also in order to increase
effectiveness and efficiency. Acquisitions, mergers and strategic alliances, as well as sales of
divisions, are thus all the more often to be considered as parts of ongoing organizational
change. Boundaries between organizations are blurring. New financial products are being
developed and offered at lower costs while being characterized by higher financial risks. The
varying possible coincidence of these phenomena has characterized the business situation
with complex dynamism. The degree to which organizations can be successful in competition
depends on the speed at which they can adapt to changed circumstances. This largely depends
on the ability of their business information systems to support changing user information
needs.

In order to modernize their information systems, many organizations have replaced their
legacy information systems by implementing modern ERP systems1. In most cases, these
investments were made to meet a number of objectives simultaneously. For example, within
an organization, many different types of legacy information systems were in use that did not
comply with millennium and Euro requirements. The focus of these old information systems
was on offering basic transaction-based data with little attention paid to the need to provide
decision-support information. Sometimes, organizations went through a business process re-
engineering exercise resulting in organizational change, characterized by new information
needs. In a number of situations, existing legacy systems were insufficiently flexible to meet
these new information needs. However, when the millennium turned and most organizations
had implemented their new ERP systems, a growing number of complaints were expressed.
For example, implementation cycles were much longer and costly than initially budgeted
(Saunders, 1999; Scheer and Haberman, 2000; Waggle, 1998; Chiara, 2001). The ability of
ERP systems ever to meet the ROI benchmarks as promised was brought into question
(Stedman, 1999), as was their flexibility and future-proofing, supposedly sufficient to enable
them to continue to be an organization’s central business information system for several years
in dynamic circumstances of on-going change. New users starting to use existing and
available information and existing users with new or changed information needs characterize
the dynamic environment in which these information systems have to accommodate
information. Whether ERP systems can adequately respond to these varying information
needs is a central question.

In science, business information systems like ERP systems have been investigated from the
viewpoint of accounting information systems. The focus in these research initiatives is
predominantly on proposing improved accounting data models. The two most prominent
examples of these initiatives are McCarthy’s (1978) REA model and Riebel’s (1984) data

1
ERP systems are offered by vendors such as SSA GT, Oracle, SAP, PeopleSoft, et cetera.
4 Chapter 1: Problem Definition

recording rules (‘Grundrechnung’). Everest (1974) describes the objectives of improved

accounting data models as increased sharability of data, increased availability of data,
improved evolvability of data and increased data integrity.

This dissertation focuses on the question of how ERP systems can better store data to service
internal and external information needs that may change over time. A new method of
organizing accounting data, suitable to deploy as an ERP systems data model, is proposed.
This data model should be sufficiently complete and robust so as to be implemented as a data
model for ERP systems and deployable as a data source in real-life customer situations. It
should be able to hold data for existing and new information needs. The completeness of the
data stored in this newly proposed data model is validated through answering the question of
whether enough data could be held to service the information requirements of a new
application. We chose to validate the completeness of the data available through a new
application as the value added is better demonstrated when data can be provided for an
application not currently supported by data extracted from existing ERP data models. As
representative of a new application choice, whether sufficient data can be provided to service
hierarchical treasury management decision-making with ex ante and ex post accounting data
to be applied in manufacturing organizations will be evaluated. To attain this objective, the
new application has first to be defined by introducing principles of business logistics into the
domain of treasury management to obtain a hierarchical treasury management decision
framework where decisions are defined at various levels. Following that, management
accounting theory will be applied to evaluate which ex post and ex ante information is
required to support these decisions. Once all information requirements for this new
application are known, the newly proposed accounting data model’s ability to hold sufficient
data will be evaluated as validation of the multi-purpose nature of this data organization
approach.

The scope of the research project described in this dissertation can also be outlined through a
description of the three most important keywords in this dissertation. The keywords are:
accounting, treasury management and information systems.

Accounting is the first keyword. This domain is usually divided into financial accounting and
management accounting. The goal of management accounting is to provide the knowledge
required for planning, decision-making and control (Zimmerman, 1997; Anthony, 1988).
Financial accounting focuses on providing information to external stakeholders. The overall
goal of this dissertation relates to defining an improved accounting data model that can hold
more complete data for new and existing information needs. These decisions can relate to
internal subjects (in the field of management accounting) or external questions (as discussed
in financial accounting). More specifically, the knowledge on decision-making is applied to
the domain of treasury management decisions at an operational level, i.e. the management of
financial resource flows. These decisions are supported with relevant cost information (see
Chapter 6). The goal of financial accounting is to record the relevant financial data on
business transactions and provide them to the (mainly external) stakeholders in the
organization. The double-entry bookkeeping system is the most widely used format for the
storage of financial accounting data. However, later in this dissertation (see Chapter 2), it will
be demonstrated that this data recording method has drawbacks when accounting data are
provided for decision-making. Therefore, an alternative recording approach for capturing
accounting data is proposed (see Chapters 2 and 3).

Treasury management is the second keyword and relates to solving two categories of
problems. The first category concerns planning and executing the physical flow of financial
resources, e.g. optimizing supplier payments, optimizing customer collections, etc. The
second category of treasury management decisions concerns the identification and hedging of
financial risks related to financial resources used in business transactions, e.g. optimizing
currency and interest rate risks. In this research, only treasury management decision support
 Chapter 1: Problem Definition 5

was considered, which belongs to the first category (i.e. optimizing the physical flow of
financial resources), since these decisions can be fully supported on the basis of business
transaction data stored in the ERP data model. The other category of decisions (focusing on
currency and interest rate optimization) make use of very different types of data
(macroeconomic, operations research modelling, etc.) and are consequently outside the scope
of this discussion. Treasury management decisions focusing on financial resource flow
optimization are usually divided into short and medium-term decisions, and long-term
decisions.2 Decisions typically made for the long term relate to, for example, a decision to
expand the volume of financial resources through the raising of capital or the issue of bonds, a
decision to invest a strategic surplus of financial resources by taking a stake in another
organization, and so on. One unifying characteristic of all these decisions is that, once made,
they are difficult to reverse. Long-term decisions essentially determine from a high-level
perspective which types of financial resources are used in a business. Short and medium-term
treasury management decisions essentially originate from the results of long-term decisions.
Decisions typically made in this timeframe are those, for example, optimizing payments and
collections of financial resources, optimizing cash surpluses and deficits, minimizing bank
costs, etc. Short and medium-term financial policies are instituted to efficiently manage the
financial resources of a firm. They are close to the operations of the firm and once
implemented, are easier to change. ERP systems hold information to support short and
medium-term decision-making in several functional domains, one of which is treasury
management. In this research, supporting treasury management decisions in the short and
midterm was opted for as being the typical timeframes within which ERP systems facilitate
decision support (see Chapter 5).

Information system is this dissertation’s final keyword. The trend today in business
information systems is for so-called Enterprise Resource Planning systems, which are
standard integrated business information systems. As previously explained, many
organizations invested heavily in these information systems to resolve a number of problems
simultaneously. The objective of this research is to propose an improved data model that
could be the sole data source for an ERP system.

This research was conducted following a multidisciplinary approach, as a mono-disciplinary

approach would have yielded only partial solutions to the research questions. Following the
research methodology applied in Industrial Engineering and Management science, this
approach takes all relevant viewpoints on the problem into account. In this research, the
information technology perspective is studied in relation to a treasury management decision-
making viewpoint to coherently investigate the overarching question of ‘Is there a better way
to define and organize accounting data suitable for implementation and deployment in ERP
systems which provides more complete ex ante and ex post data to support existing and new
internal and external information needs?’ The newly proposed accounting data model is
validated in an application where data has to be provided to support hierarchical treasury
management decisions with relevant cost data. ‘Hierarchical’ is meant to be understood as the
relational state where decisions are defined at multiple levels and the outcome of decisions
made at a higher level sets the scope in which decisions defined at a lower level can be made.

In the remaining part of this chapter, the following topics are discussed. Section 1.2 covers
different approaches to support changing information needs in ERP systems. Section 1.3
discusses how accounting data model research results have not been incorporated into the data
models of current business information systems on the basis of literature analysis. The
problem of restricted data availability is therefore still an existing and relevant problem today.
This finding is illustrated by an analysis of the data recording approach in a sample ERP
system. Section 1.4 provides an outline of the research objectives and questions covered in

2
Hill et al. (1992) argue that it is advisable to define this difference on the basis of the nature of the
decision and not on the basis of the timeframe within which the decision is made.
6 Chapter 1: Problem Definition

this dissertation. Section 1.5 deals with the research methodology applied in this research.
Section 1.6 discusses the research design. Section 1.7 discusses the scientific and practical
relevance of this research. An outline of the remaining chapters of this dissertation is
presented in Section 1.8.

1.2 Different approaches to support changing information needs in

ERP Systems

Several different approaches can be discerned servicing changing information needs in ERP
systems. Two of these are used very widely and are therefore discussed here, namely focusing
on the support of new algorithms and focusing on the design of improved data organization
frameworks. These two approaches are discussed below.

1.2.1 Focusing on the design of new algorithms

Following the first approach, the focus is on the definition of new business algorithms to
solve a changed management information problem. Once new algorithms are defined, they are
designed and developed in new software applications. The shared data model, which holds the
data used to service all ERP applications, is modified, where data proves insufficient, on the
basis of the new data requirements. This approach always implies the development of new
algorithms and data model extensions. An example within the treasury management domain
could be the definition of an algorithm to serve a treasury management decision framework in
which decisions are supported hierarchically where there can be several alternative solutions
for a single decision. In operations management, a number of hierarchical decision-making
applications are already known that focus on optimizing operational resources (see e.g. Bitran
and Hax, 1977; Bitran and Tirumpati, 1993; Fransoo et al., 1995; and Hax and Meal, 1975).
Hierarchical decision-making relates to decisions that are defined at different levels where the
outcomes of decisions defined at a higher level set the scope for optimizing decisions defined
at a lower level. Comparable hierarchical decision-making applications could be developed to
service treasury management decisions that optimize financial resource usage. Were these
functional applications developed as ERP software applications, following this approach
would necessitate the ERP data model being modified or extended for missing data.

1.2.2 Focusing on the design of improved data organization frameworks

The second approach focuses on the design of multipurpose data models. Researchers and
information system architects advocating this approach point to the advantages that result
when business transaction data are organized independently of any application scope, in that
there are no restrictions on data availability when stored data are reused to service a newly
defined algorithm. A significant number of research initiatives have been defined in this area,
see e.g. Verdaasdonk (1998, pp. 88-96), Dunn and McCarthy (1997), Weber and
Weissenberger (1997), Sakagami (1995), Murthy and Wiggins (1993). The most important
research initiatives in this area are by McCarthy (1982) and Riebel (1994), based on
Schmalenbach (1948). This literature will be discussed in detail in Chapter 2. These authors
focus in their research projects on improved ways of organizing accounting data stored in
information system data models.

The first important research initiative was McCarthy’s Resource-Event-Agent (REA) model,
which redefines relevant accounting data on economic events in such a way that data can be
provided to service requirements for financial accounting information needs. Following this
 Chapter 1: Problem Definition 7

approach, every financial business transaction is described by its key components: resources,
events and agents, and the possible relationships between them. The REA model was first
designed using the E-R (entity-relationship) methodology. An object-oriented version of the
REA model was later presented (see Dunn and McCarthy, 1997; Geerts and McCarthy, 1997;
McCarthy, 1995). The REA model was further developed into the extended REA model
(Geerts and McCarthy, 2000, 2002).

The second important research initiative was Schmalenbach’s (1948) and Riebel’s (1994)
‘Grundrechnung’ description. Schmalenbach differentiated between ‘Grundrechnung’ (the
data storage area) and ‘Sonderrechnungen’ (applications making use of ‘Grundrechnung’). He
described accounting data recording principles for ‘Grundrechnung’ to guarantee the purpose
neutrality of recorded data. Purpose neutrality of accounting data means that data are not
defined specifically for one application but can be reused for a whole range of applications.
Riebel (1994) extended Schmalenbach’s recording rules in order to bring ‘Grundrechnung’
into practice. This resulted in the definition of data recording principles with which data
models have to comply in order to guarantee the purpose neutrality of stored data.

1.2.3 Which approach to prefer?

Focusing design efforts on proposing new algorithms could seriously negatively impact the
application and data model architecture. Following this approach, the data model is designed
after the requirements of new algorithms are frozen, without anticipating the possible need to
support additional algorithms at a later date. As a result, the reapplicability of already
available data to service new algorithms cannot be guaranteed. When existing data recording
is not entirely satisfactory, separate data models are created with the sole objective of
supporting the newly designed algorithm. This soon leads to several data sources being used
concurrently to service the business information system. These data sources often contain
similar data (e.g. one data model holding aggregated data, a second data model holding
detailed data; both data models referring to the same business transaction), with the potential
risk that data recorded in different data sources are not synchronized. Applications built
following this approach look like a patchwork with no transparent, reusable architecture.
Scapens et al. (1996) describes this problem as follows: ‘… it has also been questioned
whether sufficient attention was given to the ability of managers to see through the limitations
of data and draw on a variety of information sources in a flexible way for decision-making
rather than giving their choices controlled by external reporting in a deterministic way’.
Owing to these drawbacks, defining new algorithms and modifying the data model
accordingly cannot be considered as a good approach offering a sound foundation for the
guarantee of ongoing support of new and/or changing information needs over the longer term.

Consequently, defining improved accounting data models is the right approach at a

fundamental level as objectives like increased sharability and availability of data directly
contribute to the ability to service existing and new applications over time without
restrictions. However, whether data models of large, modern business information systems are
in fact built on the basis of the research result recommendations of the two most important
data model proposals, the REA model and ‘Grundrechnung’, remains in question. Are the
data models proposed as a result of scientific research initiatives actually suitable for
deployment in practice, or –though fundamentally correct options– do they suffer from
another type of drawback that renders them incapable of use in practice? This will be further
explored in the following section.
8 Chapter 1: Problem Definition

1.3 Does the problem of limited data reusability still exist in

practice?

1.3.1 No adoption of REA and ‘Grundrechnung’ concepts in data models of

current business information systems according to the literature
In the last few decades, several scientific research projects have focused on improved
accounting data models. Over the same period of time, business information systems have
evolved from very specific propriety systems offered by hardware vendors to generic business
information systems, like ERP systems, that operate platform independently. These generic
systems service the information needs of multiple users in many different types of
organization. This section explores whether the recommendations on accounting data model
design as formulated –among others– by McCarthy (the REA model) and Riebel
(‘Grundrechnung’) have been adopted in current business information systems.

The objective of the REA model was to capture the essential data characteristics of a financial
business transaction in a generic way in terms of Resources-Entities-Agents and the
relationships between these components. A number of authors have questioned the feasibility
of the REA approach as a data model. Sakagami (1995) argues that the REA model is not
really suitable for real-life implementation due to features of the modelling technique (entity-
relationship) chosen. Applying this modelling technique causes the REA meta model to grow
with the number of specific REA components needed in a real-life situation. Sakagami notes
that this will inevitably lead to performance problems. Geerts (1997) explains that the REA
model lacks ‘reusability’ and ‘extendibility’ when designed using the E-R modelling
technique. These drawbacks were subsequently recognized and an object-oriented version of
the REA model created (see Dunn and McCarthy, 1997; Geerts and McCarthy, 1997;
McCarthy, 1995). The REA model was further developed into the extended REA model
(Geerts and McCarthy, 2000, 2002). Except for some examples on the use of the REA model,
which might have led to data model prototypes, there is no mention of the deployment of the
REA model in actual customer applications in scientific literature.

There is even less literature about and references to applications of the ‘Grundrechnung’ data
recording principles. Riebel et al. (1992) and Sinzig (1994) published that the
‘Grundrechnung’ achieved an degree of ‘purpose neutrality’ suitable for application in the
ERP system R2 of ERP vendor SAP AG. However, Weber and Weissenberger’s research
(1997) indicated that Riebel’s approach has not yet resulted in concrete software applications.

On the basis of literature investigation, it was found that the two most prominent scientific
research programs (McCarthy’s REA model and Riebel’s ‘Grundrechnung’) have not yet led
to adoption in practice in large-scale implementations of business information systems. Based
on this analysis, it can be ascertained that the problem of providing reusable data that allow
for data provision to service existing, new or changing information needs, is still not properly
resolved to date. More research is needed to make data organization frameworks available
that comply with the following two criteria. First, new data models should be able to
accommodate data on business transactions to service existing, new or changed algorithms.
These data should not only be ex post data but also ex ante data. Second, these data models
should be suitable for acting as sole data sources for large-scale implementation of business
information systems like ERP systems.

Questions remain concerning whether and how the problems of providing reusable data to
service changing information needs have been solved in practice in real-life situations by
software application vendors. Has practice gone its own way and have ERP vendors
developed their own sole-source data models, able to service changing information needs, and
are these data models simply not consolidated in scientific literature or are ERP data models
 Chapter 1: Problem Definition 9

still designed on the basis of requirements frozen at a particular moment in keeping with the
first approach described (see Section 1.2.1), confirming expectations that capabilities to
service information needs changing over time are limited? To gain an impression of how
matters stand with this issue in practice, the next section investigates empirically how
business data are stored in a sample ERP system.

1.3.2 Illustration of business process instance data storage in a sample ERP

system

1.3.2.1 Terminology Definition and Situation

The process of data recording in current ERP systems is analysed through the empirical
investigation of a sample ERP system that can be considered as representative in the industry.
The following definitions are applied:
• Business process. Any set of activities performed by a business that is initiated by an
event, that transforms information, materials or business commitments and produces an
output. Value chains and large-scale business processes produce outputs that are valued
by customers. Other processes generate outputs that are valued by other processes
(Harmon, 2002). For example, procure-to-payment, a network of activities to complete
the procure-to-payment process
• Business process instance. A business process describes a generic sequence of activities.
A business process instance3 describes an actual process in a specific situation, which
includes data, real actions and specific decisions. Workflow systems and simulation
systems, for example, both keep track of the data from execution of specific BPIs in order
to determine things like how long the process actually takes, who handles a specific
instance or how much it costs. In simulation systems, someone has to supply information
about a set of actual instances (Harmon, 2002). For example, ‘Process Instance of
business process “procure-to-payment” number 85 between business partner “Peters” and
“Johnson”’
• Business transaction. The execution of one particular activity instance of a process
instance. For example, ‘Business partner Johnson orders 100 wheelchairs from business
partner Peters’ (the activity, ‘ordering’, is an example of a business transaction)
• Process instance state. Is used to track the progress of a process instance execution. A
state is changed to indicate that one business transaction (i.e. an activity instance of the
process instance) has finished and the execution of the network can continue to the next
business transaction. At that point, data on the executed activity are recorded in one or
more documents.
The relationships between the terms, ‘process instance’, ‘process instance data’, ‘activity
instance’, ‘activity instance data’ and ‘process instance state’ are illustrated in Figure 1-1:

3
In the remainder of this chapter, ‘business process instance’ is abbreviated to ‘BPI’.
10 Chapter 1: Problem Definition

P r o c e s s in s ta n c e

P ro ce ss In sta n ce S ta te

ma l i t y
A c tiv ity A c tiv ity A c tiv ity
ee
In s ta n c e In s ta n c e In s ta n c e
I n f o r m a t i o n S y s tR

A c tiv ity A c tiv ity

In s ta n c e In s ta n c e
D a ta D a ta

P ro c e s s In s ta n c e D a ta

Figure 1-1. Relevant terminology in the context of a process instance

Data storage for BPIs in the chosen sample ERP system is analysed below by investigating
the data recording process pertaining to data required to service a realistic sample information
request. The following information request was chosen: The Production Manager raises the
request for 300 extra units of product ‘chair frames’ to the Purchase Manager. To service
this information request, data on two different process instances are required:
• BPI #1, specific situation of business process: ‘Periodic Material Requirements Planning’
• BPI #2, specific situation of business process: ‘Procure-to-Payment’

The activities of these two BPIs are detailed below. The details on recorded data per activity
instance can be found in Appendix 1.

BPI #1, specific situation of business process ‘Periodic Material Requirements

Planning’4
Activity BPI State Information stored
Plan Material Requirement Required Material Advice Order

BPI #2, specific situation of business process ‘Procure-to-Payment’

Activity BPI state Information stored
Ask Quotation for Chair Frames Proposed Purchase Quotation
Order Chair Frames Committed Purchase Order
Receive Chair Frames Received Delivery Note
Receive Invoice Invoiced Purchase Invoice
Posting Purchase Invoice
Update Supplier Administration
Payment Invoice Paid Check
Post Purchase Invoice
Update Supplier Administration

4
Only the last activity of this BPI is detailed.
 Chapter 1: Problem Definition 11

The BPIs are illustrated in Figure 1-2:

B u s in e s s P ro c e s s In s ta n c e # 1 b e lo n g in g to
P lan M a te ria l
b u s in e s s p ro c e s s ‘M a te ria l R e q u ire m e n ts
R eq uirem e nt
P la n n in g ’

B u s in e s s P ro c e s s In s ta n c e # 2 b e lo n g in g to
b u s in e s s p ro c e s s ‘P ro c u re m e n t-to -P a y m e n t’
R e qu ire d

P ro p os e d C o m m itte d R e ce ive d

A sk O rde r C ha ir- R ece ive

Q uo ta tion F ram e s C ha ir-F ram e s

P o st P o st C h eck
Inv o ic e P a ym en t

In v oice d P a id

R ece ive S e nd
Inv o ic e P a ym en t

U pd ate S up plie r U pd ate S up plie r

A d m in istratio n A d m in istratio n

A ctivity B u sin es s P roc e ss Instan ce S ta te

Ins tan ce

Figure 1-2. Relationship between Activity Instance and Process Instance State

1.3.2.2 How data on BPIs are recorded in the sample ERP system
The data recording approach to the data used in BPIs of a sample ERP system is analysed on
the basis of the data used to service the sample information request as proposed in the
previous section.5 The details on recorded data are presented in Appendix 1. The following
aspects are investigated:
• data storage in a single BPI: to understand whether the data of a single BPI is provided
using a common, transparent approach to service different information needs
• data storage approach between different BPIs: to understand whether the data of different
BPIs can be integrated using a common, transparent method to service different
information needs.
These two aspects are considered the most important and crucial in understanding how data
on BPIs are organized in current ERP systems. There are several other aspects that are worth
investigating (e.g. technical aspects like product architecture, database technologies used in
ERP systems, etc.) but are considered less important in the context of the research objectives
of this dissertation. In addition to these three aspects, whether elements of the proposed data
models, namely McCarthy’s REA model or Riebel’s ‘Grundrechnung’, are adopted in the data
storage approach of the BPIs of the sample ERP system is investigated. These two categories
of question result in four findings on the data recording process of the data used in BPIs in
current ERP systems, and are described below.

5
The ERP system used for this investigation is SSA Baan ERP from ERP vendor SSA GT.
12 Chapter 1: Problem Definition

- Findings on the data storage of data used in a single BPI -

Finding 1:
There is no equivalent of the BPI at a data level. Data on a single activity instance are
persistently stored but the network activity instance (i.e. the BPI) itself is lost at the data
level.
When the BPI state changes, the data for the new BPI state are entirely re-established.

This finding concerns the question of how data on a single BPI are recorded. Figure 1-1
visualizes that a state change in a BPI occurs when an activity is finished and the execution of
the BPI is continued with the next activity instance. At that point, data on the conditions of
the finished activity are recorded. This raises the question of how data on such a finished
activity are stored in the data model and whether data on different activities of the same BPI
can be made to cohere, answered by examining how data on BPI #2, ‘Material Procurement’,
are stored. In Section 1.3.2.1, information on the following aspects of this network is
presented: the activity instance network, the BPI states and the data stored per BPI state (for
more details, see Appendix 1). Examination of Appendix 1 reveals that no BPI state is
maintained. Data necessary to support the information needs of one BPI state (i.e. one
finished activity instance in the BPI) are always redefined from scratch. This is either done by
copying and modifying the data from the previous BPI state or by creating an entirely new
definition. An example of the former option is the data creation for the ‘order chair frames’
BPI state (following ‘quotation for chair frames’). Some data are copied (e.g. the business
partner data) whereas others are redefined (e.g. proposed quantity, proposed delivery date,
etc. become committed quantity, committed delivery date, etc.). An example of the latter
option is the data creation for the ‘post invoice’ BPI state (following BPI state ‘receive
invoice’). Posting an invoice is only a summary recording of the total amount categorized in
specific general ledger accounts. In comparison with the previous activity (i.e. ‘receive
invoice’), all other invoice data are lost. In view of the data over the entire lifecycle of a BPI,
it can be said that a BPI always carries all its data (of different BPI states) with it but that
there is no central mechanism bringing data of a given BPI into coherence. There is no option
to retrace the BPI data to any of the various activity instances of a BPI, as a consequence of
the data organization methodology applied (i.e. copying and modifying). Consequently, there
is only limited possibility of enhancing application functionality supported for a BPI state
because it is restricted by the available data for that particular BPI state with no option to
reuse data defined for other business process instance states.

Finding 2:
Every completed activity instance of a BPI results in BPI state, domain-specific data
recording. This data record of the state of a BPI is stored in isolation and not as a sub-
category of a BPI.
No data organization mechanism is used to track BPI data across different states in its
lifecycle.

Each activity instance in the BPI belongs to a specific functional domain. This is illustrated on
the basis of the activity instances of BPI #2 (as described in Section 1.3.2.1 and see Appendix
1 for details). For example, the ‘Ask Quotation’, ‘Order Chair Frames’, ‘Receive Chair
Frames’ activities belong to the ‘Distribution Logistics’ functional domain and the ‘Receive
Invoice’ and ‘Payment Invoice’ activities belong to the ‘Finance’ functional domain. The
nature of the information requests belonging to a functional domain, even those belonging to
a subdivision of a functional domain, prescribes that data should be presented in a particular
format. For example, within the ‘Distribution Logistics’ functional domain, the presentation
of the ‘quotation’ is similar to the presentation of the ‘order’ but different from the
presentation of the ‘delivery note’. The question, therefore, is whether data should be
 Chapter 1: Problem Definition 13

recorded in the format used by the target user group of the information related to an activity
or whether the data should be recorded independently of the format in which it is used.
McCarthy (1979) claims that when data are stored according to the requirements of a certain
artefact (e.g. general ledger accounts), they are only reusable to a limited extent (i.e. within
the scope of new requirements based on the chosen accounting artefact). An investigation of
the sample ERP system highlights that data are indeed stored specifically in the format
prescribed by the information requests of a specific BPI state. For example, for the ‘post
invoice’ activity, data are stored in general ledger format, for the ‘order chair frames’ activity,
sufficient data on the order are stored to handle information requests of the ‘Distribution
Logistics’ domain but there is limited availability to support financial information requests.
Besides, in an ERP system, data belonging to a BPI state are stored in isolation and are
unrelated with respect to the data stored on BPI state, which immediately precedes or
succeeds the focused data item. In current ERP systems, the relationship between data of
different activities needs to be defined by means of a workflow management tool. These tools
are not truly integrated with the information system itself; rather than being an embedded and
integral part of the information system, these tools are mostly offered as bolt-on add-ons for
the ERP system. The data model itself lacks the definition capability to compose all data over
different activities of a single BPI.

- Findings on data organization between BPIs -

Finding 3:
As data on a single BPI are not stored in a structured manner, there is no structured
data organization approach between different BPIs.
There is no generic integration between data between different BPIs. When data on different
BPIs are integrated, they are integrated to support specific, predefined functional
requirements.

This finding concerns the question of how data on different BPIs are integrated with each
other. Prior to investigating how data on BPI #1 are integrated with data on BPI #2, how the
activity instances of these two BPIs are integrated should be considered (the activities are
described in Section 1.3.2.1, with details on recorded data described in Appendix 1). As
explained earlier in this section under Finding 2, data on activity instances of a BPI are stored
in isolation; however, they can be made to cohere using a workflow management system, an
add-on tool on top of the ERP system. These tools support the definition of activities at
different levels of detail. Accordingly, first the highest level is defined (integration between
BPI #1 and BPI #2), then the integration between individual activity instances of a BPI are
defined at a lower level. It is prone to the same drawbacks as defined for Finding 2. The
workflow management tool, which facilitates integration between activities over different
BPIs, is only defined on top of the information system and is not really integrated. Its only
function is to invoke activities in a certain sequence. As the execution of activities implies
reading data on the chosen activities, this approach facilitates bringing data on different
activities into context. The possibility of defining an activity chain over different BPIs is thus
achieved through selecting a sequence of activities out of a predefined set of possible activity
combinations. The number of possible integration options between activities of different BPIs
is predetermined. The source of this limitation can be found in the data structure. As stated in
Findings 1 and 2, in current information systems, data are provided in a contextually specific
BPI state. Of relevance to this finding is the fact that a number of possible integrations
between different BPIs are provided from a data viewpoint as domain-specific BPI state data.
If a generic, transparent data definition concept was used to organize the BPI data, then
transparency for data between different BPIs could be achieved, allowing for more flexible
integration. As this is not yet the case at the level of a single BPI, it can be concluded prior to
any discussion of the data organization between different BPIs that the data on a single BPI
should first be organized consistently and coherently.
14 Chapter 1: Problem Definition

- Finding on the use of a generic data organization concept -

Finding 4:
Data on BPIs are not organized according to REA or ‘Grundrechnung’ principles. No
other equivalent data organization concept6 is used to define data on BPIs consistently
and transparently.
Double-entry bookkeeping is implemented as a data recording method to support financial
information needs.

Earlier in Section 1.3.1, it was found on the basis of literature analysis that principles of REA
and ‘Grundrechnung’ have not been adopted in ERP systems to date. However, it is possible
that current ERP systems have been adopting some of the recommendations of REA and
‘Grundrechnung’ without these having resulted in scientific publications. In order to
understand the actual status of REA and ‘Grundrechnung’ adoption in existing ERP systems,
three different aspects are investigated in more detail for the ERP system under investigation.
First, the extent to which the research results on the most prominent research initiative,
McCarthy’s REA Model, have been adopted in the data models of the sample ERP system are
investigated. Second, whether or not the ERP data models take into consideration the data
recording principles prescribed by ‘Grundrechnung’ is evaluated. As a third and final topic,
whether data models of current ERP systems suffer restrictions because of the adoption of
application artefacts such as general ledger accounts, debit/credit, etc., is explored. The
outcome of the investigation of these three topics is described below.

First, the adoption of research results on REA in current ERP systems is investigated.
McCarthy (1979) noted that business transaction data could be reused to service multiple
information needs from various different users when essential data characteristics are
recorded. In his REA model, he defined ‘Resources’, ‘Events’ and ‘Agents’ as the essential
components to be consistently recorded in the data model. The question remains whether ERP
system designers ever followed this advice. As already highlighted in Section 1.2.2, among
the other drawbacks reported by several researchers, Sakagami (1995) remarked that the REA
model is not really suitable for large-scale implementations and Geerts (1997) indicated that
the REA model lacks ‘reusability’ and ‘extendibility’. Owing to these drawbacks, it is not
expected that ERP system data models have adopted features of the REA framework in their
basic format. However, ERP designers could have modified the REA model into one suitable
for implementation in ERP systems. It was stated in Finding 2 that in the sample ERP system,
data are recorded specifically in the format used by users of a functional domain. For
example, the ‘post invoice’ activity implies that the financial result of the ‘receive purchase
invoice’ activity is recorded in the general ledger accounts. Data on essential REA
components such as the ‘Resource’ or the ‘Agent’ are lost. This simple example illustrates the
contention that no extended version of the REA model was applied as a data storage approach
in the sample ERP system.

Second, the extent to which the data models of existing ERP systems comply with
‘Grundrechnung’ data storage principles was investigated. With respect to the possible
application of the data recording principles of ‘Grundrechnung’ (Riebel, 1994; see also
Verdaasdonk, 1998, pp. 91-92) in the data model design of current ERP systems, an
investigation of the sample ERP system illustrates that none of the prescribed data recording
rules have been followed for BPI data recording. These data recording rules are:
1. ‘No heterogeneous classification or summarizing of data elements’. This data recording
principle prescribes that data should be classified homogeneously and that detailed data
should be recorded in all situations. In Finding 2, it was indicated that data on a

6
In this context, a ‘data organization concept’ is defined as one transparent data organization ‘vehicle’,
reusable and capable of holding the data of one entire network of financial obligations in a commonly
agreed format.
 Chapter 1: Problem Definition 15

completed activity are always stored in a domain specific format. For example, data on
‘Posting the Invoice’ are stored in general ledger accounts whereas data on ‘Quotation for
Wheelchairs’ are stored in a Distribution Logistics-specific format (see Appendix 1 for
details). It is therefore ascertained that data on different completed activities are recorded
heterogeneously. Depending on the characteristics of the activity, detailed or summarized
data are recorded.
2. ‘No arbitrary division and allocation of accounting data’. This data recording principle
suggests that accounting data should be recorded as they occur in the BPIs prior to
defining calculations or allocations. Again, Finding 2 showed that data on some of the
completed financial activities are stored in general ledger accounts (see Appendix 1 for
details). Data stored in general ledger accounts are by definition arbitrarily categorized
and specific to the details of the BPIs (i.e. the choice of general ledger accounts depends
on the nature of the BPIs and the calculation or allocation of data could have taken place
before the actual data recording on general ledger accounts).
3. ‘Recording an entry at the lowest level possible’. This data recording principle prescribes
that data should be recorded with as much detail as possible. In some situations this
recording principle is achieved, e.g. data on the ‘Purchase Order Wheelchairs’ are stored
with full detail (i.e. ‘at the lowest level’). However, in other situations, this recording
principle is jeopardized, e.g. when data on the BPI are stored in general ledger accounts,
only a ‘financial summary’ of the data on the finished activity is stored – detailed data are
lost.
4. ‘Characterization with all attributes of interest and importance’. This data recording
principle suggests that full data should be available to service all attributes of interest and
importance concerning a broad user community. See also recording principles 2 and 3.
General ledger accounts do not hold data on the circumstances in which an activity took
place. Data stored on the ‘Order chair frames’ activity (see Appendix 1) only hold scant
financial information. In other words, no data are accommodated in the representative
sample ERP to service the general notion of ‘attributes of interest’ of different
information users.
This elaboration is to clarify that ‘Grundrechnung’ data storage principles have not been
applied in the data model design of the sample ERP system.

The third and final aspect of this investigation was to examine whether data models of current
ERP systems still contain application artefacts. For decades, research aimed at improved
accounting data models has been initiated as the various drawbacks of double-entry
bookkeeping became apparent (e.g. as described by McCarthy 1980, p. 628; see also
Belkaoui, 1992, p.110; Hollander et al., 1996, pp.49-54 and Verdaasdonk, 1998, pp.87-88).
These researchers have consistently advised avoiding adopting application artefacts in the
data model design in order to avoid possible restrictions in data storage because of limitations
to a chosen application scope. This raises the question of whether ERP system designers have
followed this advice and abandoned double-entry bookkeeping features in data model design.
Investigation of the sample ERP system has revealed that data on some financial activities are
still stored in general ledger accounts (see Appendix 1). Despite frequent advice from
scientists, the adoption of double-entry bookkeeping artefacts continues in today’s
information systems. However, some additional explanation is required here. Not all of
McCarthy’s drawbacks on double-entry bookkeeping are applicable to characteristics of ERP
system data models since in addition to this data recording technique, other data recording
also takes place. If several data recording methods are concurrently applied in ERP systems,
the next question is whether double-entry bookkeeping is only implemented as an
optimization of the shared data model to service external control-related information needs.
Thus the question is whether data recorded in general ledger accounts are only derived from a
transparent, reusable data model or whether several data sources are concurrently maintained.
Investigation of the representative sample ERP system has revealed that BPI data are not
organized as transparent, reusable data objects as explained earlier in this finding. Therefore,
it can be ascertained for the sample ERP system that data recorded in general ledger accounts
16 Chapter 1: Problem Definition

is not derived from a transparent data organization concept. The application of double-entry
bookkeeping in the ERP system could therefore lead to limitations in the availability of data.

The outcome of the investigation of these three aspects (nonadoption of REA aspects,
noncompliance with ‘Grundrechnung’ data recording principles, and the adoption of
application artefacts in the data model) indicate that practice did not follow the
recommendations made in scientific literature.

1.3.2.3 Summary of business transaction data recording in current ERP systems

In Section 1.3.2, two different aspects of data recording in a representative sample ERP
system were empirically analysed, namely the data organization of a single BPI and the data
organization between different BPIs. The next matter under scrutiny focuses on whether
research results on prominent data models like REA and Grundrechnung are used in practice
in a sample ERP system deployed in several large-scale customer implementations. This
investigation resulted in the definition of four findings that all apply to the sample ERP
system. Though other ERP systems have not been the subject of this investigation, it is
expected, based on experience in practice with other ERP systems, that a comparable
empirical investigation of other systems would yield results in line with the findings as
defined for this sample ERP system.

1.3.3 Approach chosen in this research

The problem of providing reusable data suitable to service existing, new or changing
information needs remains unsolved today. This was found as a result of literature analysis in
Section 1.3.1 and was illustrated for a sample ERP system in Section 1.3.2. The following
approach has been chosen in this research to solve this problem. In order to achieve the
research objectives as defined later in this chapter (see Section 1.4), the following questions
need to be answered. First, a new way to define and organize accounting data has to be
proposed, resulting in an accounting data model suitable for ERP implementation and
deployment in real-life customer situations. Within this data organization approach, data will
have to be defined in a neutral and objective fashion (according to Schmalenbach’s
Grundrechnung approach) so that they can also be reused to accommodate data to service
other applications at a later date. This part of the research clearly focuses on the second
approach as explained in Section 1.2.2 (i.e. focusing on the design of improved data
organization frameworks). Even when the objective is to support existing, new and changing
information needs on the basis of neutral and objective data, a scope consideration still has to
be made. Here, the existing, new or changing information needs are envisaged as those that
are typically solved by ERP systems today and for which no entirely new type of data (such
as risk data, macroeconomic data, environmental data, etc.) are required. The aim is to avoid,
within this context only, a situation where new or changing information needs enforce data
model changes by proposing an improved data organization framework. Second, the
reusability of data accommodated through the newly proposed accounting data model should
be illustrated by evaluating whether sufficient data can be provided to support hierarchical
treasury management decision-making at multiple levels with ex post and ex ante accounting
data. This part of the research could be considered as an example of the first approach as
outlined in Section 1.2.1 (i.e. new algorithms are developed in addition to the body of
knowledge concerning treasury management). However, the data provision to support this
algorithm in information systems will not be facilitated by specifically enhancing the existing
ERP data models to comply with the new requirements on data availability. On the contrary,
since a new data organization method aiming at providing data for multiple purposes is
described in the next three chapters of this dissertation, the newly required data will be
accommodated by this new accounting data model. The ability to provide data to service the
 Chapter 1: Problem Definition 17

newly outlined application in the treasury management domain will be used to validate the
capability to provide data to many other new applications in the future.

1.4 Research Objectives and Questions

This section concerns the problem statements of this research. Verschuren and Doorewaard
(1995) indicated that a research problem statement consists of the research objective and
research questions. This research project can be broken down into two research objectives,
each with a list of research questions.

The central objective of this research, as outlined in Section 1.1, is to answer the following:
‘Is there a better way to define and organize accounting data suitable for implementation and
deployment in ERP systems which provides more complete ex ante and ex post data to
support existing and new internal and external information needs?’ This question was the
result of the observation in the literature that research results on accounting data model
research have not lead to data models which were useful for implementation in large ERP
systems on the one hand, and the finding that existing ERP systems still struggle under the
same limitation of insufficient data being capable of being provided to handle existing, new
and changing internal and external information needs. Therefore, there remains justification
for additional research towards improved accounting data models. This is outlined in the
following research objective.

Research Objective 1
¾ To propose a data organization framework allowing the storage of ex post and ex ante
accounting data on BPIs suitable for supporting changing accounting information
requests defined by different users.

A solution to this research objective consists of three steps. In Section 1.2.2, it was explained
that data need to be organized independently of any application scope in order to be reusable
for existing, new and changing information needs. McCarthy (1979) argues that this is only
possible when aspects of reality are incorporated into the data model. As a first step to the
solution of this research objective, investigating which aspect of reality occurs as a recurring
pattern in the BPI data is necessary. This will be the central entity of the data model. Once
this recurring pattern is identified, the data components of this recurring pattern, essential to
supporting information needs, have to be defined as the second step. Since the objective is to
design an accounting data model which can be implemented in information systems, it is
crucial to define these data components as design features that have to be taken into
consideration when designing the data model. The third and final step is that the new
accounting data model has to be designed in a commonly used data modelling language on
the basis of the design features of essential data components as defined in the second step.

Research objective 1 can be redefined by means of the following research questions:

1. How should an alternative data organization method be defined from the recurring pattern
recognisable in BPI data?
2. What are the essential data components of the BPI data pattern required to service new
and changing information needs?
3. How can design features of essential BPI data components be modelled into an
accounting data model which can be implemented in large business information systems?
These three research questions refer to the two problem areas as described in Section 1.3.2.2.
The first research question relates to the lack in current ERP systems of a central generic data
organization concept that allows the retrieval of data on a BPI at different stages of its life
18 Chapter 1: Problem Definition

cycle at once. The second research question investigates which essential data components
need to be modelled in the data model so that sufficient data are available to service new and
changing information needs. The third and final research question deals with the problem of
how the essential data components of the proposed data organization methodology identified
can be modelled so that an accounting data model becomes available that can be implemented
in business information systems and provide data in real-life customer implementations.

The newly defined accounting data model is designed to be implemented in large ERP
systems and to hold data to service existing, new and changing information needs from
various internal and external information users. While this data model is expected to hold data
to service a broad spectrum of applications, one application has been selected to validate
whether the data model can indeed hold the data required to support all the information needs
that occur in this application scope. The choice was to prefer a new application over an
existing application in order to understand whether the proposed accounting data model could
overcome restrictions encountered with existing data models. The application chosen is
hierarchical treasury management decision support based on relevant cost data (ex ante) and
ex post data. In this instance ‘hierarchical’ is to be taken to meant that decisions are defined at
different levels whereby the outcome of decisions defined at a higher level define the scope in
which decisions at a lower level can be made. The application chosen for validating the newly
defined accounting data model is defined as the second research objective.

Research Objective 2
¾ To propose a framework of hierarchical treasury management decisions where ex post
and ex ante accounting information is used for decision support in information systems.

Owing to the fact that the application chosen (hierarchical treasury management decision
support with relevant cost data) is new, several steps have to be taken prior to actual
validation on data completeness. Firstly, the new application has to be defined. Since
hierarchical decision support also occurs in the domain of business logistics, it is logical to
define the different treasury management decisions in a decision framework along the same
lines as applied in business logistics decision frameworks. Supporting the treasury
management decisions with relevant cost data was opted for. Therefore, as a second step, the
relevant cost data, which actually play a role for decision support has to be defined for each of
the decisions. Since the objective is to support these decisions with data held by the newly
defined data model, what the requirements on data availability are have to be outlined
alongside the definition of the relevant costs for each of the treasury management decisions.
The third step is that an algorithm has to be defined for each of the decision alternatives that
allows the calculation of what the decision outcome in terms of relevant costs will be for each
treasury management decision generically. Since the treasury management decision
framework is defined along the lines of business logistics decision frameworks, it is a natural
choice also to redefine algorithms borrowed from this discipline and modify them to render
them useful in the domain of treasury management. Again, since the objective is to support
the decisions with data held by the new accounting data model, additional requirements on
data availability encountered by the newly defined algorithm have to be outlined. Finally, the
actual validation of the data model, which is the research result of research objective 1, can
take place. The validation relates to the question of whether the data model can hold sufficient
data to fulfil the data requirements defined for supporting decisions with relevant costs (see
Step 2), and the data requirements defined to support the calculation algorithm (see Step 3).
 Chapter 1: Problem Definition 19

The following research questions are defined to solve research objective 2:

1. How should a framework of hierarchical treasury management decisions based on
concepts of business logistics be defined?
2. Which are the relevant ex ante and ex post accounting data suitable to service treasury
management decisions with financial information?
3. How a consistent process be outlined to define relevant costs in such a way that an
information system can determine incremental and opportunity costs for any treasury
management decision scenario?
4. How do additional functional requirements of the new treasury management application
impact on its ability to provide data through the accounting data model proposed as the
research result of research objective 1?
The four research questions detail the application chosen to validate the accounting data
model that is the result of research objective 1. The first research question refers to the
problem of defining treasury management decisions hierarchically. The second research
question refers to the definition of the accounting information relevant to supporting the
treasury management decisions with financial information. The third research question refers
to the difficulties of converting an advanced accounting theory into a process suitable for
implementation in an information system design. The fourth research question relates to
whether the data needed to support treasury management decisions using the chosen
accounting technique can be provided through the proposed accounting data model that is the
result of research objective 1.

1.5 Research Methodology

The research project discussed in this dissertation was conducted according to the
methodology applicable for design-oriented research. In design-oriented research, the ultimate
goal is the description and design of a model, which might take many different forms, such as
a framework, a design, a software model, etc. (see De Leeuw, 1993). The following
methodological steps have been taken to achieve this goal. The project was initiated by
outlining a problem statement. The problem statement is the generalization of the issue as
perceived by all representative stakeholders. The first step in the solution was the definition of
requirements for the data model. These requirements can be based on multiple sources:
literature analysis, case studies, workshops, etc. Then the data model was designed on the
basis of these requirements. The design of model was the result of an iterated process: when
necessary, requirements were further refined and the data model got improved as a logical
result. When the model was considered to have some state of maturity, it was validated. The
actual validation relates to investigating whether the newly designed model sufficiently solves
the research objectives derived from the problem statement (Bilderbeek et al., 1998).

This methodology has been applied to this research subject as follows. The problem statement
(‘how to provide data for existing, new and changing information needs’) was defined on the
basis of literature analysis and discussions with ERP system architects. Requirements for an
improved accounting data model were defined on the basis of recommendations in literature
and the author’s own experience with the design of ERP systems. After a couple of iterations,
these requirements resulted in the definition of the design features for the accounting data
model and ultimately in the design of the contract data model, expressed in UML (Unified
Modelling Language), see Chapter 4. This contract data model is the end result of this
research. Several different aspects could be chosen to validate the proposed data model, as
explained further in Section 5.2 of Chapter 5. Whether the data model could be built can be
validated (i.e. the development aspect), as can whether a customer could deploy the data
model as data source in a real-life customer implementation (i.e. the implementation and
20 Chapter 1: Problem Definition

deployment aspect) or whether the data model could hold sufficient information (i.e. the
completeness aspect). The completeness aspect was chosen to validate the suitability of this
model for holding data for new and changing information needs, i.e. can the data model hold
sufficient information to support existing and new applications? An application has been
outlined to answer this question (i.e. operational treasury management decision-making).
Again, according to the methodology of design-oriented research, requirements for data
availability for this new application were defined first. Subsequently, an algorithm suitable for
executing the treasury management calculations was defined. Additional data requirements
for this algorithm were defined as well. Ultimately, the validation consisted of evaluating
whether the data model could support the two sets of additional data requirements to service
the application (operational treasury management) chosen for validation. It should be
emphasised that the target audience for the treasury management application is primarily the
system architects of large ERP systems who want to design a treasury management
application as a logical extension of an ERP system. The target audience is not the
professional treasurer whose daily activities consist of making these treasury management
decisions in practice.

1.6 Research Design

This section concerns the research design applied to this research subject. This research
focuses on designing a new accounting data model supporting new and changing information
needs from various types of users and which can be implemented in real-life customer
situations. The outline of this research project has been defined in five parts:
• Part 1: Problem statement
• Part 2: Functional architecture
• Part 3: Object architecture
• Part 4: Validation
• Part 5: Conclusions
The research approach chosen in each of these 5 parts will be elaborated in the remainder of
this section.

Part 1: Problem statement

The problem statement proposed in this research relates to the fact that data models of current
large ERP systems are only capable of holding data to support existing, new and/or changing
information needs from various types of information users to a limited extent. This problem
has been derived from literature analysis. Research results on accounting data model research
as consolidated in scientific literature are characterized by only describing the mechanics of
the new model and the examples provided, offer only a limited illustration of its performance.
These newly proposed data models have not led to publications on actual implementation and
deployment of the proposed designs in ERP systems used in real-life situations. The problem
of restricted data provision by existing data models is also illustrated through investigating
how data on BPIs are recorded in a sample ERP system.

Part 2: Functional architecture

In the second part, the functional architecture of the newly proposed accounting data model is
presented. This is carried out in three consecutive steps.

The first step deals with an outline of the requirements the proposed data model needs to fulfil
in order to meet the objectives on data provision to service existing, new and changing
information needs. These requirements are defined on the basis of literature analysis,
investigation of current ERP systems and discussions with information system architects.
 Chapter 1: Problem Definition 21

Literature describes that new data models should ideally be designed in close relation with
aspects of reality in order to avoid restrictions emergent from incorporating application
artefacts such as debit/credit, a general ledger, etc. (see e.g. McCarthy, 1979). Therefore, as a
second step, the aspects of reality that correspond to the phenomena of BPI data were
investigated and subsequently analysed in two ways: firstly, through the analysis of the
recurring pattern found in different business transaction data types (such as sales transactions,
purchase transactions, etc.), as recorded in double-entry bookkeeping since its inception;
secondly, through the analysis of the recurring pattern in BPI data as recorded in a sample
ERP system. The recurring pattern is proposed as the ‘contract’, a formal record of
agreements made between parties.

In the third step, the essential data components needed to provide data for existing, new and
changing information requests are defined. The essential data characteristics are found on the
basis of literature investigation. Defining the essential data components as design features to
facilitate the design of the technical architecture in the next phase concludes the definition of
the functional architecture.

Part 3: Technical Architecture

The purpose of this research project is to obtain a data model that can serve as the sole data
source of ERP systems deployed in large-scale customer implementations. Therefore, it is
critical to express a technical design following a commonly accepted design method with no
known restrictions. On the basis of the design features, the results of Step 3 of Part 2, the
contract data model is designed in UML (Unifying Modeling Language). The usability and
completeness of this data model was discussed with various ERP system architects.

Part 4: Validation
Many different aspects could be relevant subjects for validation in this research project. Two
of the most trivial choices are, first, is the data provided through the new contract data model
sufficiently complete so as to be able to accommodate data to service existing, new and
changing information needs? Second, can the data model be implemented in large business
information systems and can it satisfactorily hold data in a real-life customer situation. Since
validation of the second aspect (suitability for technical implementation) implies building an
entire business information base with the contract data model as the sole data source and
subsequently organizing full customer implementation with this information system, this
aspect is beyond the scope of this research. Validation on completeness of the data source has
been conducted in four consecutive steps as discussed below.

Step 1: Definition of the representative application

The goal of completeness of data provision by the newly proposed data model relates to its
ability to service existing, new and/or changing information needs. From a validation
perspective, a representative information request needs to be outlined first, against which it is
later evaluated to determine whether sufficient data could be provided by the data model.
Hierarchical treasury management decision-making was selected for support as a new and
representative treasury management application focusing on optimization of financial
resource use in manufacturing organizations. This approach to treasury management decision-
making is based on concepts from the business logistics domain. Because current treasury
management information systems are not defined following this approach, this is considered
a sufficiently representative application to validate the completeness of the data stored in the
newly proposed data model. The definition of a new application consists of defining three
different frameworks for hierarchical treasury management decision-making, namely a
centralized, decentralized and hybrid model for decision-making. The definition of these
frameworks for treasury management decision-making are defined on the basis of analogy
with decision-making frameworks in business logistics as described in the literature of this
domain.
22 Chapter 1: Problem Definition

Step 2: Data requirement definition of the new information needs

Having outlined the scope of the application chosen for validation in the previous step, the
next question relates to the required data availability. Prior to defining the requirements on
data availability, a method for decision-making has first to be determined. The method of
decision-making is the relevant cost method. This choice is based on literature research in the
domain of management accounting. For each of the treasury management decisions in the
hybrid treasury management decision framework, it was first determined which relevant costs
play a role in supporting the decision. Subsequently, the requirements on data availability
were determined for each of the decisions individually. The complete list of different data
requirements is ultimately derived from the list of data requirements per individual decision.

Step 3: Data requirements on the calculation algorithm applied in the new application
Once the data requirements per individual decision are known, whether there are additional
requirements on data availability related to the calculation algorithm of the new application
needs to be examined. A suitable calculation algorithm has first to be determined before these
additional data requirements are defined. Since the hierarchical approach to treasury
management decision-making is based on knowledge of the business logistics domain, logic
suggests that the literature of business logistics be investigated with a view to finding a
suitable algorithm that can be used in the new application. In fact, the literature investigation
indicated that the MRP7 netting algorithm is effective in supporting treasury management
decisions defined in a hierarchical framework. Additional data requirements to support
treasury management decisions with relevant costs on the basis of MRP netting calculation
are derived.

Step 4: Validation of the completeness of data provided by the contract data model
Validation on completeness of the data provided by the contract data model has been
evaluated by investigating whether the data requirements on decisions and the algorithm as
outlined in Steps 2 and 3 can be fulfilled by data provided by the contract data model. Two
treasury management decisions have been investigated in particular to understand whether the
contract data model can indeed hold all required data to support this new and relevant
application.

Part 5: Conclusion
The research objective of this research project is to propose a new accounting data model,
capable of holding sufficient data for new and changing information needs. After some minor
modifications, the proposed contract data model proved to be sufficiently complete to hold
data to support a new representative application in the context of treasury management
decision-making.

1.7 Research Relevance

This section discusses the scientific and practical relevance of the outcome of this research
project. Scientific relevance of research projects concerns itself with determining to what
extent fundamental insights are elaborated and new knowledge is acquired. Professional or
practical relevance relates to the question of how relevant problems in practice can be solved
or simplified on the basis of the conclusions of the research. The scientific and practical
relevance is noted separately for the two research objectives.

7
‘MRP’ stands for ‘Material Requirements Planning’.
 Chapter 1: Problem Definition 23

1.7.1 Scientific Relevance of the Research Questions

The scientific relevance of a research project relates to the new fundamental knowledge
acquired that can be used and further elaborated in later research projects. The first research
objective is ‘To propose a data organization framework allowing the storage of ex post and ex
ante accounting data on BPIs, suitable for supporting changing financial information requests
defined by different users’. Previous research towards improved accounting data models is
represented by the American School, predominantly the REA model, presented by McCarthy
(1979, 1982) and the German School, namely ‘Grundrechnung’, data recording rules
presented by Schmalenbach (1948) and later operationalized by Riebel (1994). These research
projects resulted in the presentation of accounting data models that focused on the structure of
ex post data only (under the REA model) or the definition of data recording rules only
(following ‘Grundrechnung’). Neither approach has led to data models suitable for
accommodating data in real-life scenarios. The scientific relevance of this research objective
is the definition of an accounting data model that can be used to provide data in real-life
situations and that not only covers ex post data but also includes ex ante data.

The second research objective is ‘To propose a framework of hierarchical treasury

management decisions where ex post and ex ante accounting information is used for decision
support in information systems’. Numerous research projects have long dealt with subjects in
the fields of ‘operations management of physical goods’ and ‘operations management
decision-making’. Contributions can be found in domains like ‘business logistics’, ‘physical
distribution’, ‘management accounting’, etc. However, this optimization question has not
been investigated with respect to financial resources. Almost no research has been done on
the topics of ‘operations management of financial resource flows’ and ‘operational treasury
management decision-making’. The scientific relevance of this research objective is that the
operational treasury management decisions are redefined from a financial logistics
perspective and supported with accounting data. Therefore, some new treasury management
algorithms have been defined which are based on principles of business logistics.

1.7.2 Practical Relevance of the Research Questions

The practical relevance of a research subject relates to the extent to which the outcome of this
research can be used in a professional context. Van Aken describes a ‘professional’ as ‘a
person from a well-described professional group who, with creativity and application skills,
makes use of scientific knowledge when solving “value” problems’ (Van Aken 1994,
borrowing from Freidson, 1973, Schön 1983). These ‘value problems’ are problems in the
real world where the ‘value’ of those who have the problem has to be improved, this in
contrast to ‘knowledge’ problems that can also be described as ‘truth’ problems.

The practical relevance of the outcome of the first research objective (‘To propose a data
organization framework allowing the storage of ex post and ex ante accounting data of BPIs,
suitable for supporting changing financial information requests defined by different users’) is
the fact that system architects are now able to build more efficient and more complete
information systems because an appropriate data organization methodology suitable as a data
model for ERP systems, and allowing its deployment in large real-life customer
implementations, is now available. In current information systems, the financial information
is accommodated fragmentally and incompletely and is only reusable to a limited extent. The
output of data models described so far in scientific literature did not allow for deployment in
real-life customer situations.

The practical relevance of the outcome of the second research objective (‘To propose a
framework of hierarchical treasury management decisions where ex post and ex ante
accounting information is used for decision support in information systems’) can be defined at
two levels. It has now been demonstrated to system architects how to implement treasury
24 Chapter 1: Problem Definition

management decisions supported by incremental and opportunity cost accounting data in

information systems. At a later date, once these information systems have become available, it
will be possible to explain to end-users (the treasurers) how they can optimize the treasury
management decision-making process on the basis of relevant financial information. The
latter question is not solved in this dissertation.

1.8 Outline of this dissertation

This dissertation comprises nine chapters:

Chapter 1: Problem statement. Argues that accounting data models as proposed in scientific
literature (e.g. REA and ‘Grundrechnung’) are not used in ERP systems on the basis of
literature analysis. This statement is illustrated by the analysis of the data model of a sample
ERP system. This chapter also outlines the research objectives and questions, the research
design used, and illustrates the scientific and practical relevance of this research.

Chapter 2: Contracts as aspects of reality in designing the data model. In keeping with
recommendations made in earlier research, new accounting data models may not contain
application artefacts and should be based on aspects of reality. An analysis of the recurring
pattern in BPI data is therefore conducted in this chapter. Contracts are found to be the
relevant aspect of reality and the contract data model is proposed as multipurpose, single data
source. This chapter also outlines the functional requirements with which an accounting data
model that can accommodate data to meet changing information needs of various types of end
users should comply.

Chapter 3: Design features of the contract data model. This chapter contains a discussion of
the fundamental information components of the contract data model. It illustrates how the
various fundamental information components composing the definition of the contract data
model all meet the relevant functional requirements of the multipurpose data model as defined
in the previous chapter. Chapters 2 and 3 can be taken together as the scientific answer to the
first research objective.

Chapter 4: Object model of the contract data model. The design of an object model for the
implementation of the contract data model in information systems is described in this chapter.
This chapter provides an answer for the ‘professional’ or practitioner to the first research
objective.

Chapter 5: Outline of hierarchical treasury management decision framework. The validation

of the contract data model as an improved accounting data model is accomplished by
analysing whether sufficient data can be accommodated to service a new application.
Supporting hierarchical treasury management decisions is chosen as the relevant application
scope. The treasury management decisions, which compose the hierarchical treasury
management decision framework, are outlined here.

Chapter 6: Data availability requirements to service treasury management decisions with

relevant costs. In order to validate the suitability of the contract data model as a sole data
source, the data availability requirements of the chosen application must be made explicit. For
each of the treasury management decisions outlined in the previous chapter, this chapter
investigates which data are required to service the decision with relevant cost information.

Chapter 7: Algorithm to support treasury management decisions with relevant costs. In this
chapter, a suitable algorithm is provided to calculate and compare the financial impact for
 Chapter 1: Problem Definition 25

each possible alternative to solve a treasury management decision in a particular situation in a

generic way. The definition of this algorithm results in the definition of additional
requirements on data availability. Chapters 5, 6 and 7 can be taken together as the scientific
answer to the second research objective.

Chapter 8: An information framework, defined as an extension of the contract data model, to

service treasury management decisions. This chapter concludes the validation of the contract
data model as a data source to service changing information needs. The requirements defined
in Chapters 6 and 7 are brought together here and whether the new requirements have already
been incorporated in the object model of the contract data model as discussed in Chapter 4 is
evaluated. An extension of the contract data model is described to incorporate the remaining
requirements. This chapter offers an answer for the ‘professional’ or practitioner to the second
research objective.

Chapter 9: Conclusions in this research. This chapter formulates conclusions and reflections
on the two research objectives. Recommendations are made for future research.
26 Chapter 1: Problem Definition

Part I. Problem Statement

Chapter 1
Problem
Definition

Part II. Functional Architecture

Chapter 2
Contract, basis
for Data Model

Chapter 3
Design Features
Contract Model

Part III. Object Architecture

Chapter 4
Object Model
Contract Model

Part IV. Validation

a. Application Scope
Chapter 5
Hierarchical
b. Requirements Def. Treasury Man. Dec

Chapter 6
Requirements
c. Algorithm Def. TM decisions

Chapter 7
d. Object Model
HCFEM
Validation Algorithm

Chapter 8
TM Decision
Pattern

Part V. Conclusion

Chapter 9
Conclusions
27
28