REA analysis of SAP HCM; some initial findingsRichard Fallonrichard.l.fallon@student.shu.ac.uk01Simon PolovinaS.Polovina@shu.ac.uk01Communication and Computing Research Centre
,
CCRCSheffield Hallam University
,
UKS1 2NU
This paper explores further the claim that the Transaction-Oriented Architecture (TOA) based on the principles of Resources, Events, Agents (REA) can enhance Enterprise Resource Planning (ERP) systems by providing a principled theoretical basis that can underpin ERP business process implementations. We provide details of some of our initial findings of the REA/TOA analysis which we carried out on the SAP Human Capital Management (HCM) module. Given that SAP is recognized as the dominant ERP system with over 50% of the market share, this technology is viewed as the representative case study technology for exploring the theory of REA in actual ERP systems. In particular O'Leary's and Dunn et al.'s works are expanded upon, substantiating O'Leary's findings that SAP was found to be consistent with REA in its database, semantic and structure orientations. Using SAP's HCM module as the exemplar, two notable discoveries are made. These are namely (i) identifying that several anomalies exist in the underlying data model, and (ii) that there are many more REA entities than previously discovered by Dunn et al. Through the SAP HCM exemplar it is shown that REA adds value to modelling business processes in ERP systems.
SAP AGERPDesign PatternsREAHCMTOA (TransactionOriented Architecture)SemanticsOntologyCombining and Unifying Business Intelligence with Semantic Technologies (CUBIST)-
In this paper we explore the claim that TOA can be used following the principles of
REA to enhance business process modelling in ERP systems, by providing a tool that
can be used to increase the system design and understanding of the business process
implementation and the underlying data model.
Fundamental to REA/TOA is the concept of a design pattern, since REA is defined
in terms of an object design pattern. A design pattern is a recognized, named solution
to a common design problem [
1
]. Catalogs of design patterns have been produced by
the Gang of 4 as the solution to commonly found object oriented software design
problems [
2
]. The concept of the Transaction Model (TM) was introduced to provide
a method of encapsulating the REA model using CG concepts and thus allowing for
the capture of organizational transactions by providing abstract constructs [
3
]. TOA
offers the possibility of providing the tools (TM, TrAM, MAS) and concepts required
to model the structure and transactions of an organization and provide purpose and
direction to Service-Oriented Architecture (SOA) [
4
].
There are many vendors of ERP software, the top five vendors are SAP,
Peoplesoft, Oracle, J.D. Edwards, and Baan. SAP is recognized as the dominant ERP
system with over 50% of the market share [
5
]. Due to the clear commercial
importance of the SAP solution, it was considered a logical step to use this
implementation as an exemplar for ERP systems.
We provide evidence that shows how REA can be successfully used for modelling
SAP business processes (in SAP HCM) and how SAP can be considered in part as
complying with REA theories. However, the results of the research also indicate that
through non-compliance with the REA ontology, how data is lost or stored again
(repeated) within the SAP database. Confirming one of McCarthy’s [
6
] original
theories that led to the REA ontology, since he identified that using conventional data
storage techniques (such as double entry), would lead to inconsistency of data,
information gaps and overlaps in data or data spread.
This paper proceeds as follows. Section 2 contains the core of this paper, by
making an REA analysis on one (SAP) business domain, SAP HCM and one business
process within this domain, labor (labour) requisition. Section 3 provides a final
summary and outlook.
2
2.1
REA analysis of SAP HCM
HR business process
The HR business process is defined by Dunn et al. [
7
] as encompassing all that is
required to acquire and then pay for employee labor. The HR business process is
commonly separated into two separate sub-processes, where one sub-process; (i)
personnel is responsible for hiring, training, evaluating and terminating employees
and the other sub-process; (ii) payroll is responsible for the time management and
subsequent payment of the employee’s services [
7
].
2.2
REA Enterprise Value System
In the REA Enterprise Value System the HR business process is defined as the point
of contact between the enterprise and its employees [
7
]. In this sense the employees
are seen as external suppliers (external agents) or business partners providing labor to
Investors and creditorsSuppliers (vendors)EmployeesCashCashGoods,
services
CashLabourCashEnterpriseGoods,
services
CashCustomers
the organization in return for cash. The HR business process in the Enterprise Value
System is identified in Fig. 1 below.
Within the HR business process Dunn et al. [
7
] identify two key forms of resources
that of human capital, the labor provided by the employees and the cash paid by the
organization to the employee in return for the labor which was provided.
In REA terms the HR business process is identified (Fig. 2) as a special case of the
acquisition/payment cycle, consisting of four key business events; labor requisition,
labor schedule, labor acquisition and cash disbursement [
7
].
The ideas from Dunn et al. [
7
] and their initial REA diagram (Fig. 2) were used as
a basis, from which this paper provides a more detailed investigation into the labor
requisition business event which is shaded in grey in Fig. 2. These investigations have
shown how it is however possible to provide further detail (than that provided by
Dunn et al. [
7
]) of the labor requisition event and subsequently identify new REA
entities.
2.3
SAP Human Capital Management (HCM)
The HR module is identified within SAP as Human Capital Management (HCM).
SAP HCM consists of three separate sub modules which are identified as Talent
Management, Workforce Deployment and Workforce Process Management. These
three HCM sub-modules are then surrounded by; Workforce Planning and Analytics
as detailed below in Fig. 3.
End-User ServiceDelivery
Talent
Management
Deployment
Process Management
Planning
Analytics
The labor requisition event is defined by Dunn et al. [
7
] as the identification of a need
for labor. Supervisors are usually responsible for determining this need through
monitoring either one or all of enterprise growth (or the lack of), production plans,
sales forecasts, employee turnover and other indications of labor requirements.
The labor requisition event can be aligned with the recruiting process within Talent
Management in SAP HCM. Through our REA analysis of SAP HCM we have gone a
step further than Dunn et al. [
7
] and identified four further (sub) events within the
main labor requisition event, these four (sub) events are; requisition, advertisement,
application and hire (detailed in Fig. 4 below). For each independent box (Resource,
Event and Agent) the corresponding SAP table has been identified and is shown in
brackets. The Resources, Events and relationships which are shaded in grey have
been found to be non-REA compliant and will be discussed below, together with the
other REA entities which were identified.
reserves
ResourcesREA entities.
Dunn et al. [
7
] state that in a valid REA design, each Resource, Event or Agent entity
can be found stored within a separate database table. Using this criteria we have
produced the results detailed in the Tab. 1-5 which show that we have; (i) identified
many more REA entities than those defined by Dunn et al. [
7
], together with
numerous relationships, (ii) that the tables for all the entities (except for cash resource
and hire event) could be adequately accounted for within the (SAP) REA data model.
The new entities discovered are detailed below;
(sub) Events.
Events are defined as ‘a class of phenomena which reflect changes in scarce means
[economic resources] resulting from production, exchange, consumption, and
distribution’, Yu and Yu quoted by McCarthy [
6
], the following REA (sub) events
were identified as detailed in Tab. 1 below.
t
n
e
v
E
Recruitment Request
Advertisement
Application
Hire
n
o
i
t
p
i
r
c
s
e
D
a request from within the
organization for new
personnel
placing of an
advertisement for a new
position
the receipt of an
application from an
applicant
the point at which an
applicant becomes a new
employee
yes
no
yes
no
Resources.
McCarthy [
6
] originally defined a resource as equivalent to an asset in accounting
terms and subsequently a resource was further defined by Dunn et al. [
7
] as something
with or without substance that are provided or used (consumed) during an
organizations business activities thus the following resources were identified in the
labor requisition event as detailed below in Tab. 2.
Resource
Cash
Recruitment Instrument
Vacancy
Position/labor type
Applications
no
yes
yes
yes
yes
Agents.
McCarthy [
6
] defined agents as persons or agencies that participate in economic
events or are responsible for subordinates that participate in these events. The
following agents were identified in the labor requisition event as detailed below in
Tab. 3.
Relationships.
The following relationships were identified in the labor requisition event as detailed
below in Tab. 4. The table details each relationship together with the corresponding
Resource/Event/Agent which the relationships connect.
Participation3
Participation4
Participation5
Participation6
Participation7
Participation8
Participation9
Participation10
Stock-flow1
Stock-flow2
Stock-flow3
Stock-flow4
Responsibility
Reserves
Hire Event .
yes
yes
no
yes
yes
yes
yes
no
no
no
yes
yes
no
yes
yes
Application
Application
Hire
Hire
Vacancy
Vacancy
out
Cash
in
in
in
Recruitment
Instrument
Applications
Position/labor
type
Cost centre
Vacancy
A known problem was encountered when modelling the hire event with respect to the
duality relationship, since the REA ontology fails to explicitly specify whether the
duality relationship should be seen as a property of the type level (relevant for the
modelling phase) or of the instance level (of a running system) [
9
]. Since if the
‘conceptual modelling support’ function was to be used which states that, when
duality is used as the criterion of a valid model then; ‘all types of a valid model must
be coupled in duality relationships with other events’ [
9
]. In the case of the Hire
Event we have interpreted this duality relationship as belonging to the instance level
of a running system, which means that there is no way to identify which named event
type this particular hire event should be paired with. There was no evidence found
within the SAP system of any event type which could correspond with the duality
properties of the hire event. As observed by Borch and Stefansen [
9
] both
possibilities are acceptable and they suggest that ‘it is possible for the user of the
ontology to make his or her own interpretation’. Our interpretation of this event, that
it is belonging to the instance level, corresponds with the fact that the REA model was
defined given the SAP implementation and not that the implementation followed an
REA design.
Data storage.
As previously stated Dunn et al. [
7
] assert that in a valid REA design, each Resource,
Event or Agent entity can be found stored within a separate database table. However
within SAP HCM the hire event is not stored within a unique table, instead when this
event (an applicant is hired) occurs the information about the applicant is moved from
the applicant table directly to the employee table. Thus data is lost at this point since it
is not possible to trace back directly to historical details of the event. There are of
course practical implications which must be to be taken into account when a system is
implemented, such as the necessary storage requirements when each and every event
is stored. O'Leary [
10
] identifies this same issue and states that ‘an events accounting
system is a theoretical ideal which realistically would never be implemented’. He
then draws the same conclusion that unless storage became costless and abstracting
detail was ‘painless’, there would never be full event histories. The assumption can
therefore be made that the designers at SAP made the decision to reduce data storage
requirements by storing this event and the relevant data in this way.
Cash Resource.
For the business process labor requisition, the storage of cash resource does not
follow REA principles, since the value of placing an advert (a cash resource) is stored
within the Advertisement Event in the SAP table T750B in the column PCOST.
However, this value does not find duality within the system, since it does not at any
point within the business processing get transferred to a Cash Resource table or
subsequently to a general ledger (resource) table. The value PCOST is used later by
a SAP reporting process to determine how many applicants are received through a
specific advert and thus determine a cost per advert per application. But at no point is
the value PCOST booked against any cash accounts. There is no stock-flow in, in
terms of an advert that has been placed, but no stock-flow out in terms of a cash
resource, the payment for the advert which has been placed. Therefore in the
processing of labor requisition, the SAP system does not conform with REA theory,
which leads to information been lost or repeated (at a later date) in the database. It is
our assumption that this value (PCOST – cost of advertising) must at a later date be
deducted from the general accounts ledger, however no evidence could be found to
confirm this assumption.
Vacancy Resource.
The vacancy resource is stored within the SAP table T750X. The table contains
foreign keys to the HR personnel organizer (participation9) responsible for this
vacancy and the line manager (participation10) to which this vacancy has been
assigned. The table also contains a foreign key (reserves relationship) to the
position/labor type table that provides details of the position which is vacant. The
structure of this table does not conform directly with REA theory, since the agents
(involved in the event) should not be assigned directly to a resource (table) but should
in fact be assigned to the event taking place [
7
].
Relationship participation4.
The advertisement (event) table does not contain the details of the personnel organizer
responsible for this advert, shown in Fig. 4. Labor Requisition as relationship
participation4. This does not conform to REA theory, which states that each agent
which participates or is responsible for an economic event should be identified.
2.5
REA compliance
From the REA entities identified in SAP HCM and detailed in Tab. 1, we have
produced the following table Tab. 5, which shows what percentage of the REA
entities identified can be defined as been REA compliant.
When examining the results as detailed in Tab. 1-4 and more specifically at the REA
compliance of each of the entities discovered Tab. 5, we can concur with the results of
O'Leary [
10
], in that we have underpinned how SAP’s business processes (in SAP
HCM) can be effectively modeled using REA techniques. However we go further in
two significant areas;
The results have shown (in detail) how REA can be used for modelling a business
process; Human Resources. The detailed evidence shows one database table (-and
several smaller anomalies) where SAP is not REA compliant, and resulting from this
non-compliance, also shown how data is lost or repeated in the SAP database.
We have also confirmed a further statement from O'Leary [
10
] that ‘SAP was
found to be consistent with REA in its database, semantic, and structure orientations.
However, there were some implementation compromises in the structuring and
semantic orientation of the SAP data model’.
With regards to modelling business processes such as HR, O'Leary [
10
] makes the
statement;
‘For many real-world settings, REA is underspecified. For example, if we want to
know how a human-resources process works, REA provides no direct insights.
However, given a human resources model or system, we can map it to REA to try to
understand it better or we can build a system using REA as a guide to the underlying
data model, etc.’
This statement is reiterated by Geerts and McCarthy [
11
], however in section 2 we
have shown how a business process in SAP HCM can in fact be adequately modeled
using REA techniques and thus be subsequently represented in REA templates.
It is unlikely that SAP was implemented following a generic template model, since
SAP has been implemented over a successive period of development over many years
and thus is likely to contain many artifacts from the past such as the classical general
ledger system of accounting. Moreover SAP was clearly not originally implemented
following an REA paradigm [
10
], so it also clear that the differences between REA
and SAP can be interpreted as modelling compromises from an REA perspective. The
same conclusion is made by Hessellund [
12
], who then suggests that this difference in
interpretation will provide (a positive) feedback to the ontology development process
and (can) be used as inspiration for further extensions of the core ontology.
The REA designs detailed by Dunn et al. [
7
] were a useful starting point, from
which we have shown how REA can be used as a useful tool that can be used to
increase the system design and understanding of the business process implementation.
Through using REA analysis we have shown how our theoretical REA designs can be
mapped directly to a real world (SAP) implementation.
A recognized limitation to REA modelling was encountered when analyzing SAP
HCM, in that the REA model identifies only a structural view of the system, with the
result that all behavioral aspects of the model must then be identified and documented
using techniques such as data-flow diagrams [
13
]. The recognized solution to this
problem is the use of unified modelling language (UML) for object-oriented
modelling, previously identified by Booch et al. [
14
]. This again emphasizes the need
noted by others [
10, 13
] for further research that will lead to a set of tools and
procedures which will allow REA designs to be used for the entire development life
cycle.
The data identifying the REA compliance of the REA entities discovered Tab. 5,
would appear to indicate that in the critical area of defining event entities, SAP has
the most problems with REA compliance. Through this non-compliance with the
REA ontology, we have shown how data is lost or stored again (repeated) within the
SAP database. This confirms McCarthy’s [
6
] original theory which led to REA, since
he identified that using conventional data storage techniques (such as double entry), it
would lead to inconsistency of data, information gaps and overlaps in data or data
spread.
We have corroborated the findings exactly as foreseen by [
10
], namely that in two
significant areas i.e. (i) SAP could benefit from an REA approach to business process
engineering, since this would avoid data loss, and (ii) REA could benefit from an
analysis of a real ERP system. Notably in this respect we have identified many more
entities than those defined by Dunn et al. [
7
].
4
modeling
[1]
J. M.Bieman
, G. Straw,
H.Wang
,
P. W.Munger
and
R. T.Alexander
,
"Design patterns and change proneness: An examination of five evolving systems,"in Software Metrics Symposium
,
2003
. Proceedings. Ninth International,
2003
, pp.
n/a.
[2]
E.Gamma
, Design Patterns:
Elements of Reusable Object-Oriented Software
. Boston: Addison-Wesley,
1995
.
[3]
S.Polovina
and
R.Hill
,
"A transactions pattern for structuring unstructured corporate information in enterprise applications,"International Journal of Intelligent Information Technologies (IJIIT)
,
vol. 5
, pp.
33
-
47
,
2009
.
[4]
S.Polovina
,
"The transaction concept in enterprise systems,"in The 2nd CUBIST Workshop
,
2011
, pp.
43
.
[5]
V. B.Gargeya
and
C.Brady
,
"Success and failure factors of adopting SAP in ERP system implementation,"Business Process Management Journal
, vol.
11
, pp.
501
-
516
,
2005
.
[6]
W. E.McCarthy
,
"The REA accounting model: A generalized framework for accounting systems in a shared data environment," The Accounting Review
, vol.
57
, pp.
554
-
578
,
1982
.
[7]
C. L.Dunn
,
J. O.Cherrington
and
A. S.Hollander
,
Enterprise Information Systems: A Pattern-Based Approach
. Boston:
McGraw-Hill
,
2005
.
[8]
R.Haßmann
,
C.Krämer
and
J.Richter
,
Personnel Planning and Development using SAP ERP HCM
. Boston: SAP PRESS,
2010
.
[9]
S. E.Borch
and
C.Stefansen
,
"Evaluating the REA enterprise ontology from an operational perspective,"in Proceedings of the CAiSE
,
2004
, pp.
n/a.
[10]
D. E. O'Leary
,
"On the relationship between REA and SAP,"International Journal of Accounting Information Systems
, vol.
5
, pp.
65
-
81
,
2004
.
[11]
G. L.Geerts
and
W. E.McCarthy
, Eds.,
Modeling Business Enterprises as Value-Added Process Hierarchies with Resource-Event-Agent Object Templates
. Berlin: Springer,
1997
.
[12]
A.Hessellund
,
"Modeling issues in REA," in 2006b, pp
.
n/a.
[13]
U.Murthy
and
C.Wiggins
Jr,
"OOREA: An object-oriented resources, events, agents model for enterprise systems design,"in 2004
, pp.
n/a.
[14]
G.Booch
,
J.Rumbaugh
and
I. Jacobson
,
"The unified language,"Unix-Review
, vol.
14
, pp.
41
-
44
,
46
,
48
,
1996
.