Systematic Process of Conceptualization

For Enterprise Information System Renewal and Integration

Kenji Nishioka and Koichiro Ochimizu

Japan Advanced Institute of Science and Technology, Noumi-shi, Ishikawa-prefecture, Japan

Keywords: Development Concept, Process, Requirement Analysis, Software Engineering.

Abstract: We have had not yet practical method to define development concepts in spite of its importance for cost

effectiveness of system development. In this paper, we propose a systematic process to define development

concepts focused on renewal and integration of enterprise information systems. This process practices

development concept definition as problem solving based on trouble shooting manner. So software

engineers utilize their experiences and technologies of system development for the process effectively.

1 INTRODUCTION

Enterprise information systems (EIS) like Enterprise

Resource Planning (ERP), Customer Relationship

Management (CRM), Product Data Management

(PDM), and project management are indispensable

for business works today. Each enterprise uses EIS

for business profit like productivity, cost reduction,

quality assurance, and contribution of the amount

sold every day. So owners can’t help evolving their

EIS continuously for change of their business

environment and renovation of ICT in order to keep

or enhance their business position profitably.

But it is not always easy to develop the EIS

which satisfies owner’s business expectation.

Because EIS developers like SI (System Integration)

vendors are not usually business experts. So it is not

easy for them to understand correct business

situation of EIS owners like their customers. And the

customers are not always ICT experts. So it is not

easy for them to understand real capacity of EIS

based on the ICT which is changing and evolving

continuously. Then mismatch between developers’

business knowledge and customers’ expectation

might occur easily.

One of the roles of development concepts is to

prevent from such mismatches. A development

concept is a direction of expected system effects on

starting development stage. It is based on

developers’ correct understanding of customers’

business expectation and available ICT, and its

suitable consensus between customers and

developers will bring a cost effective EIS as

customers have expected, and reasonable amount

sold for the EIS development effort of developers.

But in spite of such importance of development

concepts, currently few experts define them in

heuristic manners. And it is difficult to get not only

manuals or tools but also reliable techniques or

advices for development concept definition. This

situation means there has been no development

concept definition methods which can be used

practically in real development field, yet.

In this paper we propose a systematic method to

define development concepts for EIS renewal and

integration. We call this method Systematic Process

of Conceptualization (SPC) in this paper. Where,

“systematic process” means project independent and

well structured activity series to define development

concept with understandable output forms, support

tools, and some standards for efficient practice.

Trough remained section 2 to 6 we describe

background and basic idea of SPC, detailed process

of SPC, practical results of SPC project and evaluate

SPC, a related research, and conclusion.

2 DEVELOPMENT CONCEPT

DEFINITION METHOD

2.1 Background of SPC

There are two types of technical problem for

development concept definition.

One is process problem to define development

concept systematically, and another is transition

Nishioka K. and Ochimizu K..

Systematic Process of Conceptualization - For Enterprise Information System Renewal and Integration.

DOI: 10.5220/0003968500630069

In Proceedings of the 14th International Conference on Enterprise Information Systems (ICEIS-2012), pages 63-69

ISBN: 978-989-8565-11-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

problem to transfer the defined concept to analysis

and design phase of system development.

The Conceptualization method (Lockheed Martin

ACC, 1996) described in section 5 has solved the

transition problem, using context diagram as a part

of a development concept. But this method depends

on idea generation like brainstorming and

breakthrough, so there are following subjects as

process problem which SPC should resolve.

Subject 1: The definition process of development

concept is not so concrete, so we should consider

how to practice brainstorming and breakthrough

depending on each project situation.

Subject 2: There are few support tools and

manners to define development concept, so it is

difficult for developers to get outputs which are

logical and understandable for customers.

Subject 3: So it takes long time to define a

development concept consented with customers.

2.2 Basic idea of SPC

Customers usually start EIS renewal and integration

to resolve not technological problems like system

usability but business problems like cost efficiency.

So definition of development concept can be

regarded as problem solving to get customers’

business problems solutions based on EIS renewal

and integration. On this standpoint we adopted

troubleshooting (TS) approach which is familiar

with experienced software engineers, as a problem

solving manner of SPC.

Generally TS consists of 4 subtasks (Alma,

2000). The first formulate problem description

subtask is to grasp trouble contents objectively based

on related phenomena, the second generate causes is

to generate causal hypotheses based on the trouble

contents, and the third test is check the hypotheses

based on experimentation. The last subtask, repair

and evaluate is system repair based on resolution of

the causes and check of the system to work

correctly.

SPC consists of 3 phases to define development

concepts as Fig.1 (IDEF0 form), and first 3 subtasks

of TS are applied to these 3 phases.

The first grasping business domain phase

corresponds to formulate problem description

subtask of TS. In this phase developers grasp

customers’ business domain and understand

customers’ business problems and expectations. The

second planning solution for current problems phase

corresponds to generate causes subtask of TS. In this

phase we extract a bottleneck which is the most

important cause among current problems, and plan

to solve it. The third verification and materialization

phase corresponds to test subtask of TS. In this

phase developers check whether the solution is a

correct answer to resolve the bottleneck and its

related main problems which prevent customers

expect directly. And based on this check result,

developers define a development concept for EIS

renewal and integration.

These 3 phases are divided 7 processes (Fig.1),

and they will be repeated at least twice to accelerate

definition of suitable development concept.

System

Scope

Basic

Development

Plan

Finding

Bottleneck

based on

Causal

Relation

Breakdown

of System

Business

Domain

Information

Customers

Current

Problem

List

Solution

Work

Flow

Consideration

Extra

Problems

Business Goal

Specification

of EIS

Available ICT

Development

Concept

Current Reality Tree

(TOC)

Conflict Resolution Diagram

(TOC)

Prototype of

Development

Concept

Ｃｏｎｃｅｐｔｕａｌｉｚａｔｉｏｎ

Expected Effects/Solution

Correspondence Table

Inquiry Sheet

for BS

Review Joined

by Customers

Customer Consensus

121

132

Grasping

Business Flow

Grasping

Business Activity

Finding

Current Problems

Analyzing Causal

Relationships

Planning Solution

of Bottleneck

Confirmation of

Business Goal

Definition of

EIS Scope

Phase of

Understanding Business Domain

Phase of

Planning Solution for Current Problems

Phase of

Verification and Materialization

Confidential

Agreement

Box：Process Activity

Left side Arrow ：Input

Right side Arrow：Output

Underside arrow：Tool

Upside Arrow：Close

Condition/Feedback

Notes

PROCESS

Current

Reality

Tree +

Bottleneck

Grasping

Business

Status for

Managing

and Actual

Work

111

Finding

Current

Problems

for

Managing

and Actual

Work

112

Solving

Main

Problems

and

Planning

Bottleneck

Solution

122

Verification

for

Solution of

Bottleneck

131

Work flow form

Figure 1: Construction of SPC process.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

3 Definition of SPC process

The SPC is a kind of step wise refinement process as

Fig.1, which outputs additional value (right side

arrow) based on input information (left side arrow).

Previous processes get feedback (upside arrow) from

following processes, and the close condition of each

process is consensus of customers or review joining

customers (upside arrow). There are some tools

(underside arrow) to support activities efficiently.

In this section we will describe detailed SPC

processes, using partially a concrete case study,

renewal of inventory system for sales and

development of security devices.

3.1 Definition of Development Concept

Prototype

In the initial start of SPC, developers define a

prototype of development concept rapidly after first

inquiry from customers. The prototype is based on

early restricted information through SPC processes

roughly. Purpose of this activity is to get a chance to

hold a meeting with customers as soon as possible,

discussing concrete items based on the prototype.

This meeting is start line of next SPC repetition,

which represents as a feedback arrow on Fig. 1.

3.2 Grasping Business Domain Phase

Customer’s business expectation and current

problems should be understood correctly for

additional value of EIS renewal and integration. To

understand them developers should grasp current

status of customers’ business domain in both

managing and actual work aspects.

This phase consists of 3 processes. The first

process is for grasping customers’ business activities

generally, and the second process is for grasping

customers’ business work flow related current EIS.

These 2 processes work concurrently. And the third

process is for collecting customers’ current

problems.

1) Grasping Business Activity Process. In this

process developers grasp information like

customers’ business domain, business role of EIS

and customers business expectations for EIS renewal

and integration. But customers’ business information

and related information is huge to grasp generally.

So SPC provides Business Status (BS) which is a

description form and an experimental guideline to

collect minimum background information to

understand customers’ business situation. BS items

include customers’ business category, its trend,

customers’ business status or position, their business

characteristics, EIS information, and customers’

expectation. BS also prevents too much overhead to

collect information. Moreover BS items are useful as

a template of concrete questions to customers.

2) Grasping Business Flow Process. To

grasp background of EIS renewal and integration

necessity, developers need to understand current EIS

as a system with business roles. So SPC provides

tools for a business work flow to make clear

business roles of EIS.

The tool is similar to sequence chart of UML, but

it represents EIS and its actors as participants instead

of objects, so users can grasp typical business

Extra４

Paper base information

management ( = Barrier

for increasing sales

amount)

３

Overhead of estimation

by business person

１

Overhead for business

person to check inventory

via an engineer

２

Too much overtime work

of business person

(Increasing inquiry)

４

Occurrwnce of miss

transformation from

order sheet to

delivery resavation

６

Mism atch between

order and delivery

５

Overhead to make inventory

list by an engineer

７

Too late supply

for invent ory

９

Difficulty of planning

manifacturing at factory

Ex tra ２

Diffic ulty for related

people to know

inventory status

Extra３

Increase of

management cost

８

Overhead to input to product

resevation sheet by engineer

１０

Too much overtime

work of engineer

(Increasing engineering

issue)

Extra１

Late or incomplete

order to the factory

Extra５

Mnagement by

individual person

Extra６

Over capacity for

inquiry ocurances

Extra７

Incomplete cross checking

of each entry sheet

Extra８

Separated location among

sales office, e ngin eer

office, and factory

Extr a９

Difficulty to use

information for

customer service

１１

Uncomplete past

sales record

BOTTLENECK candidate

BOTTLENECK

candidate

BOTTLENECK candidate

Main PROBLEM

Main

PROBLEM

Main PROBLEM

Cause

Result

n1,n2:Current problem No

Note

Figure 2: Current reality tree of security device inventory management.

SystematicProcessofConceptualization-ForEnterpriseInformationSystemRenewalandIntegration

information exchange among EIS and actors

sequentially. Where, actors are both system users

and outer systems.

3) Finding Current Problems Process. Collecting

current problems are start points of consideration of

development concept on SPC. Their main

information sources are previous process activities,

so the purpose of this process is to keep quality of

collected problems, through considering them based

on collected information, and providing feedback to

previous processes if needed. Such consideration

provides chances to find extra problems and brush

up developers’ understanding.

To make smooth progress of this consideration, a

form named current problem list with consideration

column is provided by SPC.

3.3 Planning Solution for Current

Problems Phase

The first target of this section is to extract a

bottleneck among current problems prepared on the

previous phase. The bottleneck is a basic problem

which causes various problems. The next target is to

get a solution of the bottleneck. It is a concrete target

to realize customer’s business expectation.

SPC uses causal analysis for these targets, so

SPC adopts TOC as support tools, because TOC

includes various techniques based on causal

relationships.

1) Analyzing Causal Relationships Process. SPC

uses current reality tree of TOC as a support tool to

extract bottlenecks candidates systematically based

on causal relationships among current problems.

Especially it analyses whole current problems

impartially without prejudice, so it is useful to get

totally optimised development concept.

SPC selects a bottleneck among the candidates as

the most important target to resolve. The manner of

its selection is to find a bottleneck which causes the

most main problems on the current reality tree.

On our case study, renewal of inventory system,

“Paper base information management” (Extra 4) is

the bottleneck. This problem had been paid attention

since the inquiry stage, so this analysis provides a

backing to it. But it should be attended that related

main problems have been made clear, and they will

be resolved by solution of the bottleneck.

2) Planning Solution of Bottleneck Process. There

may be many potential solutions for the bottleneck

itself, effective solutions not only for the bottleneck

but also for related main problems are not so many.

And limited budget and development deadline are

severe constraints for the solution.

But conflicting solutions often appear, so SPC

prepares conflict resolution diagram of TOC as a

support tool to resolve such confliction. Through

this tool, such confliction can be utilized to

sophisticate the bottleneck solution.

Basic development plan

・Development period 1 for goal 1 – 3, period 2 for goal 4, period 3 for goal 5

・Characteristics of new system are web base hybrid system with high security.

Business Goal of EIS Renewal and Integration

1. Block of information mismatch between order and delivery based on web system

2. Information sharing among sales division, engineering division, and factory based on

secure hybrid system

3. Fine manufacture schedule without product shortage based on real time information

sharing with factory

4. Automated generation of estimation, order, and manufacturing order sheet based on

inventory master information

5. Extension of business chances based on enhanced customer service using

accumulated information

System scope: context diagram

Period 1

INVENTORY SYSTEM

（Web version）

ENGINEERING

FACTORY

SALES

・Refer inventory

・Refer manufacturing reservation

・Check inventory information

・Manufacturing reservation

・Inventory information

・periodic

system check

・Refer inventory

・Refer schedule of

delivery/field engineering

・ Schedule of delivery/

field engineering

Customer Information for delivery

(based on secured means)

・Delivery schedule

・Refer schedule of

delivery/field engineering

・Check inventory information

INVENTORY

MANAGER

・Check inventory

information

：system

：actor

：I/O data

Note

MAINTENANCE

Figure 3: Image of development concept.

3.4 Verification and Materialization

Phase

The first target of this section is to verify the

bottleneck solution using a SPC tool. The next target

is definition of development concept.

1) Confirmation of Business Goal Process. The

first purpose of this process is confirmation not to

occur communication gap between customers and

developers during previous activities. The second

purpose is definition of a business goal. SPC

provides expected effects/solution correspondence

table as a support tool for these purposes.

This table consists of 3 columns. The left column

is for customers’ business expectation described on

BS, and center column is for resolved main

problems by the bottleneck solution. IF these 2

columns contents are not consistent, feedback to

previous processes is needed. If consistent, business

effects brought by resolution of the bottleneck and

related main problems will be input on the right

column. These effects are the business goal of EIS

renewal and integration.

2) Definition of EIS Scope Process. Purpose of

this process is to complete a development concept,

making the scope of new system and basic

development plan. Fig.3 is a development concept

image of our case study.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

SPC uses context diagram for the scope of EIS as

the Conceptualization method uses. Representation

of context diagram is based on information

exchanging between actors and system, so it is easy

for customers and developers to grasp outline of new

EIS generally. Moreover it is easy for analyst and

designer to understand system scope concretely as

upstream information.

Based on this system scope and the bottleneck

solution the basic development plan will be made for

limited budget and development deadline, too.

Then the development concept has been

completed. It consists of the business goal, system

scope of new EIS, and basic development plan to

realize the goal and the scope.

4 SPC RESULTS AND

EVALUATION

We will introduce following 2 practical results of

development concept definition based on SPC

(Table 1 S1, S2), and evaluate SPC based on them.

4.1 SPC Results

1) CRM, Project Management integration. This

case is CRM integration with project management

functions (S1) in SI division (Nishioka, 2003). One

of business expectations of this project is cost

reduction of SI business by communication gap

resolution between sales persons and engineers.

We collected about 60 problems on phase of

grasping business domain. For example, sales

persons had used CRM, and engineers had used

project management tools, but there had been no

ways to access the systems each other.

Through current reality tree analysis we

extracted the bottleneck, lack of collaboration

between sales persons and engineers. It caused main

problems like difference of documentation systems

between sales and engineering, and un-sharing

information like customer status on CRM and

development project status on project management

tools.

So we proposed development of new EIS

integrated CRM and project management as a

bottleneck solution. This solution also included new

product concept, so it would satisfy another business

expectation about a new sales product of SI division.

This proposal was reviewed by division

managers and directors individually, and agreed.

2) Inventory Management System Renewal. This

case is system replacement of inventory

management (S2) as SI business.

Customers usually hesitate to explain business

detail to outsiders, so it was useful to provide image

of needed information for development concept

definition through the concrete prototype, and

discussion about the prototype with customers was

useful to understand business situation of them.

Detailed information can’t be open here because

of confidential agreement with the customer, but in

this discussion we had gotten concrete information

like work flow, new original functions expected by

customers, and recent business troubles.

Especially business troubles caused by current

system are important, because trouble information,

its frequency, and damage cost are important points

to be cared for new system development. And one of

the most effective factors to get the order was a part

of the development concept not to repeat the

troubles. This part can be evaluated quantitatively as

cost effectiveness, and its effect was more practical

than abstract effect like information sharing.

Table 1: Development concept definition cases.

EIS field

C1 CRM

Maker A

ICT vendor

C/S

Conceptualization

method

Internal SI

mana

ement

Maker A

C/S

Internal dev.

SPC

0.6 -

Inventory

management

SI venture

Maker B

Web

SPC

0.6

0.24

（

0.4

）

Note) Rectangle means regularized cost rate

Meeting

frequency

rate

Project

C1:Before SPC

S1,S2

：

By SPC

Developer

Customer

Product type

Development

type

Development

concept definition

method

4.2 Evaluation of SPC

Before SPC we had used the Conceptualization

method. So C1 on Table 1 is a project applied the

Conceptualization method, and S1, S2 are projects

applied SPC. Cost rate means ratio of total

development man month based on C1, for example,

S1 rate is S1/C1, and C1 rate is C1/C1=1. Meeting

frequency rate is ratio of meeting times to define

development concept with customers comparing

based on C1. Where, number in bracket is

regularized by total development man month, so

regularized rate of S2 is 40% (0.24/0.6).

The followings are evaluation of SPC based on

Table 1 mainly.

i. Project independency: In C1 project we should

consider how to practice brainstorming and

breakthrough, but in S1 or S2 project we could use

SPC systematic process without worry how to

practice the development concept definition.

ii. Wide applicability: We could applied SPC to

SystematicProcessofConceptualization-ForEnterpriseInformationSystemRenewalandIntegration

various type of development concept definition like

internal development of company (S1), SI for

customers (S2), EIS integration (S1), EIS renewal

(S2), client/server system development (S1), and

web system development (S2) as Table 3 shows.

These facts depend on benefit of systematic and

usable definition process of SPC, which manner is

based on problem solving like TS including cause

analysis, and which activities are supported by

various tools like TOC. So outputs of this process

are logical and understandable for customers.

Moreover experienced development engineers are

familiar with TS manner, so they can apply the

process without so much stress.

iii. High productivity: Regularized frequency of

meeting for development concept definition of S2 is

40% of C1, so productivity or load of developers

and customers is improved clearly. This fact

depends on SPC benefit of quick start of information

gathering based on prototype discussion with

customers, guideline of minimum information to be

gathered based on BS, causal relationships analysis

and its support tools, and problem solving manner

with concrete target like a bottleneck of current

problems and customers expectations.

And SPC clears the transfer problem to use context

diagram as the Conceptualization method.

But SPC is not a general method like it. SPC

focuses on EIS renewal and integration, so SPC

can’t be applied to new EIS development based on

new business concept. However, almost all SI

projects are system renewal and integration or new

system development for usual business, which SPC

can be applied.

5 RELATED RESEARCH

We will describe the Conceptualization method as a

research relating development concept definition.

The Conceptualization method is general method

to discuss “Is this the right system to make?” based

on business needs and available technology.

The Conceptualization method is means of idea

generation to get development concepts through

collecting target domain information, brainstorming

based on it, and breakthrough based on them. Its

characteristic is to define development concept as

business goal and system scope written in a context

diagram. Especially the context diagram is

understandable intuitively, so it is useful for team

communication and presentation to stakeholders.

ACC regards the Conceptualization method as

the top level technology of object oriented system

development. Especially they regard this method to

realize seamless transfer from development concept

definition to analysis and design phase based on

business goal and context diagram.

SPC succeeds context diagram representation

from the Conceptualization method, but SPC focuses

on EIS renewal and integration, and SPC regards

development concept definition as problem solving

based on systematic process and support tools

instead of brainstorming and breakthrough.

6 CONCLUSIONS

In this paper, we proposed SPC as a systematic

method to define development concept focused on

EIS renewal and integration.

SPC practices development concept definition as

problem solving for customers based on TS manner.

Through SPC developers grasp customers’ business

domain, activities and situation, so they can

understand customers’ business problems and

expectations correctly. And they extract a bottleneck

among the problems based on causal relationship,

get and sophisticate a bottleneck solution, and verify

the solution. Then each output is summarized as a

development concept consented by customers,

which realize seamless transfer to analysis and

design phase. SPC supports such whole activities by

the 3 phases and 7 processes systematically with

support tools like TOC.

Characteristic of SPC is to adopt TS as concrete

problem solving manner to define development

concept consistently. So each process output is

logical and understandable. Especially experienced

developers are familiar to TS, so it is easy for them

to use their practical experiences for development

concept definition based on TS manner.

Through practical results of projects applied SPC

we confirmed merit of SPC, project independency of

each process activity, wide applicability, and high

productivity of development concept definition.

On the other hand current SPC tools are useful,

but automatic supports like transformation process

output to following processes are not enough, so

current subject of SPC is to enhance tools for higher

productivity.

We intend this subject to link the theme of

software development integration which includes

integrated design and programming environment

(Nishioka, 1993).

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

REFERENCES

Lockheed Martin ACC, Rational Software, 1996.

Succeeding with the Booch and OMT Methods, A

practical Approach. Addison Wesley.

Goldratt, Eliyahu M., 1994. It’s Not Luck. The North

River Press Publishing Corporation.

Nishioka, Kenji et al, 2003. Integration of CRM and SDM

for SI: Y – CMS. Information Processing Society of

Japan, SIG Technical Reports, 22(2002-SE-140) .

Alma, Schaafstal et al, 2000. Cognitive Task Analysis and

Innovation of Training: The Case of Structured

Troubleshooting, Human Factors. The Journal of the

Human Factors and Ergonomics Society, Volume 42,

Number 1, pp. 75-86.

Nishioka, Kenji et al, 1993. Fine-grained Information

Model on TENSE OMS. Journal of Information

Processing Society of Japan, Vol.34 No.03.

SystematicProcessofConceptualization-ForEnterpriseInformationSystemRenewalandIntegration