 |
 |
THE
USE OF MICSS/MERP, AN ERP MODEL, IN EDUCATION AND RESEARCH
J.
Chen*, M. Yerushalmy**, J.E. Ward***, S. Y. Nof*+
* School of Industrial Engineering
Purdue University
**
MBE Simulations Ltd.
***
School of Management
Purdue University
+
Corresponding author: snof@purdue.edu
|
Abstract:
In order for students to have better understanding on
ERP system, an educational model based on MICSS/MERP is
introduced. With this model, students do not need to learn
a complex ERP system, but can still understand the fundamental
principles of an ERP system. MICSS/MERP is also applied
for the research of information assurance on ERP systems.
Experimental data show that MICSS/MERP is an effective
and efficient tool for education and research tasks of
ERP. Copyright ©2001 IFAC
Keywords:
information system; information integration; system management;
enterprise modeling; production systems.
|
1.
INTRODUCTION AND BACKGROUND
MICSS
(Management of Interactive Case Study Simulator) is a helpful
tool achieving ease of use and assisting better understanding
of ERP (Enterprise Resource Planning) from both education and
research points of view. It is well known that ERP is a complex
system. Implementation of ERP involves large investment and
is time consuming. One of the major causes of difficulty in
implementation is lack of education. Recognizing this problem,
in our practice of computing education and research, we introduced
MICSS. MICSS is a case study simulator for management of production
and service. Four functional views are modeled, including Marketing,
Production, Purchasing, and Finance. For each view, a set of
policies and actions can be changed. The changing policy itself
in any functional view might require certain knowledge of the
state of other functions. By changing the right policy and actions
at the right time, we expect better performance of the simulated
company, such as higher profit and better reputation.
The
advantage of MICSS is that the information exchange among the
different functional views is clear. This exchange can help
understand the information exchange among the different modules
of ERP. Moreover, it can then help understand the data structure
of ERP. Two versions are applied, MICSS and MERP (web-based
ERP simulator). Both have been used in the School of Industrial
Engineering at Purdue University. To measure the effectiveness,
an undergraduate class has participated in several experiments.
The activities of the students are classified into three levels:
(i) individual level; (ii) grouped, but without communication
among group members; (iii) grouped, with communication among
group members. Three operational scenarios are simulated: Wrong
Information; Delayed Information; and Normal Case. The measured
results include the history of changed policy, the reputation,
and the profit. From the feedback of students and analysis of
experimental data, the conclusion that MICSS/MERP is useful
to understand ERP can be drawn.
1.1. Educational Model
The
advances of enterprise-wide client/server computing now makes
it possible to control all major business processes with a single
software architecture, virtually in real time. This integrated
solution, known as Enterprise Resource Planning (ERP), promises
benefits from increased efficiency to improved quality, productivity,
and profitability.
ERP
software is relatively new and complex. For example, one of
the leading ERP software systems SAP R/3, is composed of four
major parts: accounting, manufacturing, sales, and human resources
- containing more than 70 smaller modules. R/3 is a totally
integrated system, allowing companies to automate or eliminate
many costly and error-prone manual communication procedures.
R/3 can help multinational corporations, since it can handle
different currencies, different languages, different tax laws
and regulations, and different requirements of several countries.
SAP enforces business process reengineering, and it also permits
organizations to operate globally, and more effectively and
efficiently. The abilities indicate that the implementation
of EPR software is complex, and thus time consuming and expensive.
For example, there are more than 8,000 tables in the SAP databases,
containing both user data and system data. These complicated
tables direct the users through many menus and screens. Implementing
these tables in a multilanguage, multicurrency, multifunction,
multiproduct environment can take two to four years. Interfacing
SAP's client/server architecture with legacy systems adds to
the complexity. As a result, introducing SAP means significant
changes in organizational structure, job descriptions, business
processes, and organizational strategy. The SAP company is trying
to deliver a simpler solution built on mySAP.comŽ e-business
platform which enables to deploy several independent modules
on a single database. The idea is to implement a simple system
on a laptop computer, to achieve flexibility at lower cost,
see (Laudon, et al., 1998) and (Turban, et al., 2001). The typical
complexity of the ERP software is not the only reason attributed
to the difficulties of implementation of this software. The
lack of education is also a serious problem.
The
lack of ERP education does not necessarily indicate that students
need to learn more about how to use the software. There are
two levels of education: one level is operational, which is
related to how to use ERP; The other level is fundamental, which
is related to how an organization can work well with ERP. For
industrial engineers, it might be more important to understand
issues such as why ERP is necessary, how ERP helps organization,
how the different functional departments can interact with each
other. These issues are more fundamental than how to use a particular
ERP system. The operational education can be done through using
ERP software itself. But for understanding the principles, we
might not need to use the software directly. An education model
is a useful solution.
When
selecting the educational model, several issues have to be considered:
-
The model itself should be easy to use. The major reason that
we want to use a model instead of an actual ERP software is
to simplify and improve the learning process. Thus, the model
cannot be too complex.
-
The
model should reflect the complex nature of ERP. For example,
in SAP, there are four major views, accounting, manufacturing,
sales, and human resources. This separation of main functions
has to be evident in the model.
-
There
should be a performance feedback index, so that the learners
can know at anytime whether their decisions are right or wrong.
After
detailed comparison of software tools, MICSS (The Management
Interactive Case Study Simulator) has been selected. In the
next section, MICSS and its web-version, MERP, are introduced.
In section 3, how MICSS is applied in teaching is explained.
Research with MICSS on information assurance is presented in
section 4. Conclusions are presented in section 5.
2. MICSS AND MERP
The
Management Interactive Case Study Simulator (MICSS) is a computerized
case study that simulates the realities of managing a manufacturing
company (MICSS manual, 1998). Different company models can be
implemented. Students manage the company model and attempt to
succeed in producing (virtual) profit. The company is driven
by four main functions: Marketing, Production, Purchasing, and
Finance. Each function provides its own "view," including
information, managerial actions and policies. Examples of policies:
marketing-production links, machine policies. Example of policies:
manual scheduling. MERP is an advanced version of MICSS that
was recently introduced as a web-based version.
Similar
to an ERP system, to obtain the best results one must coordinate
and synchronize all four views (Figure 1). This synchronization
is called the global view of the system. Attaining a global
view is part of the challenge of MICSS/MERP, and in order to
achieve this global view, the right information exchange at
the right time among different functional department is critical.
Another critical element is how effectively the information
and coordination help making decisions that follow principles
of production planning and control, such as pull production,
lean manufacturing, and constraints-based flows. For example,
if a manager from the Marketing function wants to increase sales,
he/she has to consult first with a manager from the Production
function, to check whether there is enough resource capacity
to handle the increased production orders. Then he/she may also
need to consult with a manager of raw materials, to find whether
there is sufficient raw material inventory to handle this potential
increased production on time. Finally, a manager from the Financial
function will have to evaluate whether sales are indeed increased
in the longer term, and if they are, whether it generates more
profit and better market reputation, or increased costs and
diminished customer satisfaction.
Figure
1. A marketing view of the MICSS Model
(MICSS Software, 1998)
The
structure of MICSS/MERP imitates the multiple functional views
of ERP systems. For example, SAP R/3 is composed of four general
parts: accounting, manufacturing, sales, and human resources.
Unlike actual ERP software, MICSS/MERP does not go into the
detailed technical description and interface, such as how many
modules, or which tables there are in the ERP system. Instead,
all of the complexity of this technical detail is hidden behind
the scene, so that students know how ERP might work and help
their decisions in a high-level, non-confusing way.
The
software is relatively simple. The simulated company model runs
by itself, following the actions specified by the students.
Customer orders arrive and are automatically registered, then
transferred to the production view and turned into Work-Orders.
Materials are automatically released to the floor and the work
centers start to process the Work-Orders. Once these Work-Orders
are completed, they are stored until the delivery date. On the
delivery date, the order is automatically shipped to the customer.
In this model, the customers pay upon receipt of the products.
The
evaluation function of MICSS includes two main performance indexes.
One of them is the profit. This is a one-year, monthly, or quarterly
performance indicator. The other index is the reputation of
the company in the market, which is a long-term performance
indicator reflecting the percentage of deliveries made on time.
In reality, a company may prefer to increase its short-term
sales by sacrificing its reputation. In this case, the company
may generate large profit in the short time, but at the same
time, lose customers. Hence, the reputation index is related
to long-term performance. The MERP model enables distributed
students to interact and follow the indication of company progress
over the Internet.
3. MICSS/MERP IN EDUCATION
At
Purdue University, the MICSS/MERP models have been applied successfully
in several courses in the School of Industrial Engineering,
and in the School of Management. For instance, in the course
"Computing in Industrial Engineering", the topic of
ERP is discussed, mostly in the context of computing. Emphasis
on production management and control with MICSS/MERP is in other
courses. The time available to cover this topic is two to three
weeks, which include several lab lectures. Since time is limited,
it is unrealistic to expect students to learn how to use a full
ERP system, not to mention that specializing in a current version
of a particular commercial package is not an essential educational
objective. The labs are designed to help students to understand
the principles and complexity of ERP systems, and how they work
from an Industrial Engineering aspect. After a general introduction
to ERP methodology and software, the students participate in
several lab sessions working with the model on a PC network.
Lab
Procedure
-
The first lab lecture introduces the background of running
the simulation-based model program. Students quickly learn
how to operate the software, but whether they can generate
profit and high reputation levels is still a challenge.
-
In the first assignment after the first lab lecture, the students
are asked to run the model with six combinations of different
control policies. The students can choose which policies,
and when to switch to other policies. For each combination,
six runs are required to collect statistical results.
-
The second lab lecture focuses on how the right control policy,
selected at the right time, can affect the system performance.
A set of questions lead to answers on how to select and switch
the policy. The challenge is to identify and understand the
control problem, and which information would be useful.
-
For the second assignment, the students are divided into four-member
teams, with each member responsible for one of the four functions.
The one responsible for financial function does not change
any policy, but records the profits and can advise on policy
changes that may be useful according to the financial growth
or decline in certain experimental sets (see below). Each
group carries out four sets of experiments, which are called,
respectively, the non-cooperation set, cooperation set, wrong
information set, and delayed information.
For
the non-cooperation set, there is no information exchange among
members representing different functional views. Each person sets
up the objective based on his/her own functional view. Also, the
change of a policy and its timing are decided based on the information
available in his/her own view.
For
the coordination set, students are reminded that the objective
of their individual functions should be subject to that of the
whole company. The change of policy and its timing are decided
not only based on the information available for his/her own view,
but also information obtained and shared from other views.
(For
the case of wrong and delayed information, since they are part
of an information assurance research project, they are explained
in the following section.)
For
this assignment, students need to prepare a group report, in which
they analyze the individual objectives of different functions
and the possibilities of conflict with the general objective of
the company. Typically most of the students (about 90%) answer
the analysis problem correctly.
Figure
2.
Profit comparison between cooperation case and non-corporation
case 1
Figure 3. DDP (Reputation)
comparison between cooperation case and non-corporation case 2
| 1
and
2
Data
shown are from running MERP, a web-based, networked model
of ERP. Only a portion of the experimental lab results are
included in the tables. |
Results
from Experiments
The
results collected from students have indicated the importance
of cooperation among different functional views to the students
themselves, and to their ability to execute better control actions.
In Figure 2, the performance values in the coordination case
and non-coordination case are almost the same in the beginning.
But the performance with coordination keeps improving, while
the performance results without coordination keep decreasing.
Similar performance trends can be found in figure 3 for Due
Date Performance (DDP), a major factor of the company's reputation.
4. MICSS/MERP IN RESEARCH
Research
activities on information assurance in networked enterprises
are carried out at the Purdue PRISM lab and the School of Industrial
Engineering. The objective of the project is to design agents
and protocols to automatically satisfy the information assurance
needs of networked organizations. The first step is an extensive
study of the information assurance needs of organizations, including
identification of possible assurance requirements, their relative
potential to damage performance, and how the relevant information
can be assured. The research has focused on ERP and related
systems, as one of the most extensive, integrated information
systems in modern enterprises. It has been observed that three
typical scenarios encountered during information exchange in
an ERP system, are (1) data can indeed be correct, (2) can be
wrong, or (3) can be correct but delayed. It is difficult, however,
to investigate what is the impact of wrong and delayed information
through the use of ERP. One reason is that in a full ERP system,
many parameters cannot practically be controlled, so the experiments
might end up without meaningful results. Another reason is that
there are no evaluation criteria for researchers with which
results can be compared. MICSS/MERP were selected as good experimental
models of ERP. With these models, every parameter can be controlled,
and the evaluation can be achieved, e.g., through the financial
functional view. Besides, MICSS/MERP can be used to track and
simulate the decision procedure and information exchange in
an ERP system model in a more general way.
The
procedure of using MICSS/MERP in the experiment is as follows:
-
Conduct pilot experiments with MICSS/MERP to establish a baseline.
This baseline includes the set of policies and changes of
policies, and the time to execute a policy switch. The baseline
was tested and proven with a set of "good policies",
namely, the policies that consistently lead to better performance.
This model approach is consistent with the common application
of "Best Practice" policies available in full ERP
system.
-
Simulate
the occurrence of delayed information. The "right"
policy (baseline) is loaded in the beginning of this experiment,
but some parameters are modified. Only after a certain time
period, the correct policy and parameters information are
changed back to the baseline, the recommended policy and timely
information. Examples of delay are explained below.
-
Simulate
the wrong information. The "right" policy (baseline)
is loaded in the beginning, but some parameters are changed
and never changed back to the correct parameter information
and policy.
ANOVA
of results obtained from different scenarios was conducted. Results
for profit performance are listed in Table 1. In the table, "S"
means the two scenarios are significantly similar; "D"
means the two scenarios are significantly different; "NA"
means no sufficient data are available for ANOVA. The detailed
information can be found in (Bellocci, et al., 2001).
Table
1.
Profit performance comparison to baseline performance
a.
Delayed information (by 3 months) vs. baseline
| |
|
Baseline
Policy
|
| |
|
Period
1
|
Period
2
|
Period
3
|
Period
4
|
|
Delayed
3 months
|
Prices
delayed
|
S
|
S
|
S
|
S
|
|
QLT
delayed
|
S
|
S
|
S
|
S
|
|
Size
of Batch delayed
|
S
|
S
|
S
|
S
|
|
Order
Levels delayed
|
S
|
S
|
S
|
S
|
b.
Delayed information (by 6 months) vs. baseline
| |
|
Baseline
Policy
|
| |
|
Period
1
|
Period
2
|
Period
3
|
Period
4
|
|
Delayed
3 months
|
Prices
delayed
|
S
|
NA
|
NA
|
D
|
|
QLT
delayed
|
D
|
D
|
D
|
D
|
|
Size
of Batch delayed
|
S
|
S
|
S
|
S
|
|
Order
Levels delayed
|
S
|
S
|
D
|
D
|
c.
Wrong information (half) vs. baseline
| |
|
Baseline
Policy
|
| |
|
Period
1
|
Period
2
|
Period
3
|
Period
4
|
|
Wrong
half
|
Prices
delayed
|
D
|
D
|
D
|
D
|
|
QLT
delayed
|
S
|
S
|
D
|
D
|
|
Size
of Batch delayed
|
S
|
D
|
D
|
D
|
|
Order
Levels delayed
|
S
|
S
|
S
|
D
|
d.
Wrong information (double) vs. baseline
| |
|
Baseline
Policy
|
| |
|
Period
1
|
Period
2
|
Period
3
|
Period
4
|
|
Wrong
double
|
Prices
delayed
|
D
|
D
|
D
|
D
|
|
QLT
delayed
|
D
|
D
|
D
|
D
|
|
Size
of Batch delayed
|
S
|
S
|
D
|
D
|
|
Order
Levels delayed
|
D
|
D
|
D
|
D
|
Based
on the experimental results, some preliminary conclusions can
be stated as follows:
-
Performance measures: Profit is highly sensitive to information
failures. DDP, on the other hand, reacts more slowly, and
needs long lasting and relatively large errors to be affected
significantly.
-
For delayed information (data - smaller by 25% during 4 to
8 months, then back to the baseline policy): Consequences
do not last for a long time. When we return to the baseline
policy, the company follows the normal evolution of the correct
scenario.
-
For wrong information (data doubled or halved during 2 months,
then back to baseline policy): Even after returning to the
baseline policy, we can see the impact of the wrong information
in the first period of the performance of the company.
These
results have confirmed the impact of information failures, but
further research is required to distinguish which information
failures are less or more influential.
5.
CONCLUSION
MICSS/MERP
are effective models in both education and research. Being a relatively
simple tool, MICSS/MERP can help students understand better the
complex nature of ERP and how it works. Being a simulation based
training model, MICSS/MERP can help represent the true ERP systems
and evaluate the consequences of inappropriate information exchange.
The model software can also help students learn management skills
of networked enterprises.
There
are also some drawbacks in using MICSS/MERP. First, in trying
to simplify the model and minimize the required training in operating
the model, the software itself may be too rigid. For example,
students cannot add resources dynamically, or change machines
during the experiments. In the current versions, such changes
require external modification of the model by experts. Second,
it does not yet reflect the fact that enterprises may be involved
increasingly in e-business and Internet based activities. The
new and improved web-based version of MICSS, MERP, is being developed
and expected to incorporate such capabilities in the near future.
ACKNOWLEDGEMENT
This
research has been developed under the PRISM program (Production,
Robotics, and Integration Software for Mfg/Mgmt) at Purdue University.
Students in the class, Computing in I.E., Purdue University, have
participated in the experiments.
REFERENCE
|
Bellocci,
et al., (2001). Bellocci, Thomas, C. B. Ang, P. Ray,
and S. Y. Nof
|
| |
Assuring
Information in Networked Enterprises Through
Active Protocols and Autonomous Agents, Research
Memorandum, School of Industrial Engineering,
Purdue University, Jan. 2001.
|
|
|
| Laudon,
et al., (1998). Laudon, K., and J. Laudon |
| |
Essentials
of Management Information Systems. Third Edition,
Prentice Hall. |
|
|
| MICSS
manual, (1998). Help file in MICSS. MBE Simulation,
Ltd., 1998. |
|
| MICSS
Software, (1998). MICSS Software. MBE Simulation, Ltd.,
1998. |
|
| Turban,
et al., (2001). Turban, E., R. K. Rainer, and R. Potter |
| |
Introduction
to Information Technology. John Willey &
Sons, INC. |
|
|
|
|
|
