AD-A2 5 9 685AFT/GI,/L.R/92o-4 SIUN NI"

DTIC

S ELECTE

w C

AUTOMATED LOGISTICSINFORMATION SYSTEMS:

A CASE STUDY

THESIS

James E. Hogue

AFIT/GIR/LSR/92D-4

Approved for public release: distribution unlimited

S93-01556IIIII~hIf8" 1 2 7 02 6

The views expressed in this thesis are those of the authorsand do not reflect the official policy or position of the

Department of Defense or the U.S. Government.

DTLC QUALI" INOPECTED 5

!I Uuo-•,l [

Distribution/i Availabity Cos

- fAveil and/or.Dist ! Special

AFIT/GIR/LSR/92 D-4

AUTOMATED LOGISTICS INFORMATION SYSTEMS:A CASE STUDY

THESIS

Presented to the Faculty of the School of Systems and Logistics

of the Air Force Institute of Technology

Air University

In Partial Fulfillment of the

Requirements for the Degree of

Master of Science in Information Resource Management

James E. Hogue, B.Mus.

December 1992

Approved for public release: distribution unlimited

Preface

This was the final effort I made for the Air Force. In the past 12 years, my goal

has been to make other's jobs the easiest and least stressful as possible through con-

trolling, modifying, or eliminating the bureaucracy inherent in my work and increasing

the communication and cooperation between all those I have come in contact with. My

hope is that this work will continue that tradition with recommendations that, if

implemented, would lead to greater communication between people and support systems.

Just as in all my endeavors, this is not the effort of one man, but a compilation of

the work of many people. My thanks goes to the Greene County, Montgomery County,

Wright State University, Air Force Institute of Technology, and the 2750th Air Base

Wing Master Publications librarians who, on multiple occasions, spent time and effort

trying to locate references that did not exist. I thank the people at the Standard Systems

Center, Gunter Air Force Base, Alabama, who took the time to explain to an ignorant

researcher how their systems worked and identified contact points and information

gurus for the same. Without the reams of documentation, briefings, and historical

documents they sent, the background for each of the systems under study would have been

impossible to construct. I also thank the 2750th Logistics Squadron and the 2046th

Communications Group for allowing me to witness the workings and leam some of the

intricacies of the systems.

I appreciated Majors Wayne Stone and Steve Teal's balanced perspective and how

they ensured the quality and timeliness of the thesis.

Ii

Finally, to Debbie, my wife of 14 years, I would not have completed this program

or thesis without her encouragement and support. Thanks are too small a compensation.

James E. Hogue

|ii

Table of Contents

Page

Preface ii

List of Figures vi

List of Tables vii

Abstract viii

1. The Problem I

Introduction 1Background of the Problem 1Statement of the Problem Situation 3Purpose of the Study 4Description of the Study 4Importance of the Study 5Scope of the Study 5Definition of Terms 5Outline of the Remainder of the Thesis 8

I1. Review of Related Literature 9

Organization of the Present Chapter-Overview 9History of Data Sharing Technology 9Theories of Data Sharing 11Conclusions 13Introduction to Logistics Information Systems 13

Standard Base Supply System (SBSS) 13Consolidated Aircraft Management System 14(CAMS)On-Line Vehicle Interactive Management System 1 4(OLVIMS)

Summary of the Literature Review 16

III. Methodology 17

Organization of the Present Chapter-Overview 17The Case Study 17Why the Case Study 17

Type of Research Question 18Extent of Control 19Focus 19

iv

Page

Limitations of the Case Study Method 19Data Collection 20Data Evaluation 20

Input and Output 22Applications 23Database Management System 24Operating System 24Language 25Hardware 25Data 26Conclusion 26

Summary 27

IV. Findings 28

Organization of the Present Chapter-Overview 28Findings 28

Input and Output 29Applications 30Database Management System 30Data 32

Data Dictionary 34Data Element 36

Summary 36

V. Summary, Conclusions, and Recommendations 37

Organization of the Present Chapter-Overview 37Summary 37Conclusions 38

Input and Output 38Applications 38Database Management System 39Data 39

Recommendations 39Further Study 40

Appendix: Acronyms 41

Bibliography 42

Vita 46

V

List of Figures

Figure Page

1. Typical Wing, Prior to 1992 2

2. Objective Wing 2

3. General Information System Model 20

4. Expanded Information System Model 21

5. Complete Information System Model 22

6. System Internal Relationships 23

vi

List of Tables

Table Page

1. Relevant Situations for Different Research Strategies 1 8

2. Information System Components and Data Sharing 27

3. Comparison of Logistics Information Systems and System Components 28

4. Data Elements Within Logistics Information Systems 32

vii

AFIT/GIR/LSR/92D-4

Abstract

A change within the Air Force has shifted management responsibilities within the

logistics community. Formerly diverse functions have come under the purview of a

single manager-the Logistics Group Commander-who has inherited information systems

that may not be able to provide consolidated information for informed and accurate

decision making. The purpose of this thesis was to describe the current and potential

ability for three logistics information management systems to share data: Standard Base

Supply System, Consolidated Aircraft Management System, and On-Line Vehicle

Information Management System.

A systems model was synthesized from the literature review to determine what

components of a system may impact data sharing. Identified were input and output,

applications without a database management system, absence of a database management

system, and the data itself.

Data was gathered through the study of each system's documentation along with

interviews from systems managers and experts. It was found that documentation for

system data was inadequate and was the largest obstacle to data sharing.

Recommendations included revising documentation, providing more input and

output capability for the On-Line Vehicle Information Management System, and

redesigning the On-Line Vehicle Information Management System to operate around a

database management system.

vOii

AUTOMATED LOGISTICS INFORMATION SYSTEMS:

A CASE STUDY

I. The Problem

Introduction

Rapid and pervasive changes have occurred within the United States economy and

the international politico-military situation leading to a massive streamlining of the Air

Force. Operational controls have been reoriented. Functional areas have been redefined,

regrouped, and reorganized. Some structures have been eliminated and others have been

changed so that they bear little resemblance to their previous forms. Throughout this

streamlining, the basic building block of the Air Force has remained virtually intact-

the operational wing. The wing has not remained unscathed, however.

Background of the Problem

Prior to 1992, the predominant structure of the Air Force Wing was the tri-

deputy system. This structure consisted of a deputy commander of operations, deputy

commander of maintenance, and deputy commander of resource management. Figure 1 is

an organization structure chart for a standard tri-deputy wing.

In early 1992, General Merrill A. McPeak, Chief of Staff of the Air Force, iden-

tified an "objective wing" in which logistics functions were aligned under a Logistics

Group Commander and most aircratt mnaintenance functions were aligned under flying

squadron commanders (McPeak, 1992). Figure 2 is an organization structure chart of

the objective wing.

OFF BASE WING CommSUPERVISION

OPS A/C GENJ SUPPLY MSN SUPT

OPS COMP TRANS SEC POL]

C O M PS C I V I C E S

LOTS OFLARGE

TENANTS

Figure 1. Typical Wing, Prior to 1992 (McPeak, 1992)

OFF BASE WINGSUPERVISION T _

OPERATIONS LOGISTIGROUP GROUP SUPPORT GROUPJ

OPS SUPT LOG SUPT MSN SUPT

OPS SUPPLY SEC POLICE I

"OPS MAINTENANCE CIV ENG

OPS TRANS MWR/SVS I

CONTRACTING I 1 COMM IA FEW SMALLI

TENANTS

Figure 2. Objective Wing (McPeak, 1992)

2

Statement of the Problem Situation

Logistics information systems were designed for the tri-deputy wing (Figure 1)

with management and operations responsibility for each system residing with the

appropriate functional manager. The objective wing structure brought most logistics

information systems under the management control of a single manager, the Logistics

Group Commander. This was a major shift from the former organization (McPeak,

1992).

The Logistics Group Commander, under the objective wing, is responsible for

five diverse functions--logistics support, supply, aircraft maintenance (limited to some

-entralized functions), transportation, and contracting-with each function supported by

its own automated information system. For the Commander to acquire the data necessary

for informed decision-making, each functional area has to be tasked for the relevant

information. This information then has to be consolidated for consumption.

An automated information system able to query all of the individual systems and

then consolidate the data appropriately could result in more efficient and accurate

decision making by the Logistics Group Commander (Davis, 1988).

The single largest obstacle to implementing such an automated information

system is the limited ability to share data between current systems. Data sharing means

that the individual pieces of data can be understood and used by the different systems

(Date, 1990:7). For data to be shared, it must be defined identically by all systems. In

essence, implementing such a design results in a single database that all systems can

access (Date, 1990:44, Nguyen, 1991).

Developing such a database design is the responsibility of the Secretary of the Air

Force, Under Secretary for Acquisition. This office strives to provide the Air Force with

3

one definition for every piece of data used in every Air Force information system. In a

28 April 1992 telephone interview, Bao T. Nguyen, Air Force Data Manager, related that

developing a single definition for a data name has been difficult because the information

culture of the Air Force has been built around independent information systems.

Information systems have grown up along functional lines with little interaction outside

their respective functions. This trend has caused identical data names to appear in

different systems but with diverse definitions.

In order to standardize data definitions, eliminate duplication of effort, and irte-

grate information systems within the Air Force, information systems must be designed

from their very inception with data sharing as a primary requirement. Current

operational systems may, therefore, require a complete redesign to implement data

sharing.

Purpose of the Study

The purpose of this thesis was to describe the current and potential ability for

three logistics information management systems to share data. Each system was studied

to find commonalties that would indicate that data sharing had or could occur.

Description of the Study

Systems for this study were chosen from three functional areas under the control

of the Logistics Group Commander. In order to analyze each system, specific portions

were studied in detail. The purpose, requirements definition, structure, operating

environment, data, input, output, and interface abilities were studied to determine

similarities and differences between the systems. The study was descriptive in nature

using a case study approach.

4

Importance of the Study

This study performed two functions. First, the study served as a historical

perspective on logistics information systems within a changing Air Force.

Second, this study may serve as a basis for further research in designing a fully

integrated information system within the logistics community. Additional investigations

broadening the scope of the current study would serve to expand knowledge of current

system interactions and potentially result in a stronger basis for replacement systems.

Scope of the Study

Due to the diversity of logistics information systems, it was not possible to

compare all available systems. The systems chosen for this study were implemented Air

Force-wide and represented functional areas under the Logistics Group Commander.

Systems represent supply, transportation, and aircraft maintenance functional areas.

Definition of Terms

Application. 1. The task to be accomplished by a computer system; for instance:

word processing, accounts payable, and statistical analysis (Hipgrave, 1985;

Pfaffenberger, 1991 ). 2. The integration of logically related programs to accomplish a

specific purpose (Ahituv and Neumann, 1990; Senn, 1989). Applications have been

used as a user interface or "front end" to database management systems (Date, 1990).

Artificial Intelligence. A computer science field that attempts to improve

computers by endowing them with some of the characteristics associated with human

intelligence, such as the capability to understand natural language and to reason under

conditions of uncertainty (Pfaffenberger, 1991).

5

Data. A general term used to denote the raw facts and figures that are used for

discussion, decision-making, calculating, or measuring (Hipgrave, 1985; McLeod,

1986). Data is in the form of letters, numbers, and symbols and can be contained inside

or outside of an automated system. For the purpose of this paper, data will be considered

to be stored within an automated system or on magnetic medium.

Data Dictionary. This term is alternately referred to as a data directory or

meta-data (Hipgrave, 1985; Date, 1990; Pfaffenberger, 1991). Within a database

management system, the data dictionary contains the explanation of the format of the data

within the database. It also includes definitions of other objects in the database, the

structure of the database, and how different users view the data. A comprehensive data

dictionary may include cross references on what data is used in which applications,

which users require which reports, and what terminals are connected to the system.

Data Element. A single unit of data within a database (Hipgrave, 1985; Date,

1990). For instance, DATE would be a data element within most databases.

Data Sharing. Multiple applications, users, and processes have access to indi-

vidual pieces of data and can use that identical piece of data for different purposes.

Simultaneous (concurrent) access is also implied (Date, 1990).

Database. A computerized collection of related information about a subject

organized in a useful manner that provides a base or foundation for procedures such as

retrieving information, drawing conclusions, and making decisions (Date, 1990;

Pfaffenberger, 1991). This data repository is accessed by using the computer's

software (Hipgrave, 1985; Date, 1990).

6

Database Management System (DBMS). A software package that facilitates the

creation and manipulation of a database (Date, 1990; Hipgrave, 1985; McLeod, 1986).

Some of the functions the DBMS performs include defining, processing, retrieving,

adding, changing, or deleting data within a database (Date, 1990; Kroenke, 1992;

Pfaffenberger, 1991).

Flat File Database. A database that stores, organizes, and retrieves information

from only one file at a time (Pfaffenberger, 1991).

Hardware. The physical components of the computer. It includes input devices,

output devices, one or more processing units, memory, and storage devices. The

hardware is incapable of manipulating data by itself. With instructions from a program,

the hardware is able to move and process data (Hipgrave, 1985; Savitch, 1988;

Sullivan, Lewis, and Cook, 1985).

Logistics Information System. Management information systems that are

specifically designed for the logistics environment.

Management Information System (MIS). An information system that provides

managers at all levels of an organization with the information needed for making deci-

sions by exploiting the data held within the database (Hipgrave, 1985; Ahituv and

Neumann, 1992).

On-Line Processing. Processing mode where transactions are entered

immediately into the database system (McLeod, 1986).

Operating system. The software that is used as an interface between the user, the

applications, the database management system, and the physical hardware of a computer.

The operating system supervises the workload of the computer, controls input and

7

output, manages the computer's memory, places data on storage media, protects the user

from errors within the computer or application, provides a way to share data between

programs, and controls the sequence of execution for programs (Hipgrave, 1985;

Lister, 1984).

Schema. A complete logical view of the database (Kroenke, 1992).

Software. 1. A general term for a computer program, collection of programs,

operations, or routines used to carry out tasks on a computer. 2. Anything that is not

hardware, including documentation (Hipgrave, 1985).

Transaction. 1. An event that requires or generates data. 2. A change of data

within a database. 3. A complete processing operation (Hipgrave, 1985).

Transmission Control Procedure/Internet Protocol (TCP/IP). A file transfer

protocol for use in electronically connected computers. TCP/IP was developed by the

U.S. Department of Defense (Stamper, 1991).

Outline of the Remainder of the Thesis

Chapter I introduced the thesis problem and detailed why it is important to study

the potential for interaction between current logistics information systems. It concluded

with definitions of terms used throughout the thesis. Chapter II reviews the literature

on data sharing and introduces the three logistics information systems. Chapter III

describes the case study method and the particular methodology of this thesis. Chapter IV

provides a comparative analysis of each system. Finally, Chapter V summarizes the

previous four chapters, draws conclusions about the interaction of the three logistics

information systems under study, provides recommendations for enhancing data sharing,

and identifies further opportunities for research.

8

II. Review of Related Literature

Organization of the Present Chapter-Overview

This chapter begins with a history of shared data technology, theories of data

sharing, and concludes with an introduction to the three logistics information systems

being studied.

History of Data Sharing Technoloav

Computers were first used for business applications in the 19SOs. Slow,

cumbersome, and highly inefficient programs were written in machine language, a code

composed entirely of Os and Is. Input and output was in the form of punched cards. Data

groups in these computers were in the form of fields, typically expressed in bits, bytes,

and words. With the low level of these constructs and the relative scarcity of computers,

there was no need for data sharing. Programmers produced unique programs for unique

machines that performed unique operations on unique data. (Jones, 1992; Sullivan,

Lewis and Cook, 1985)

Not until the 1960s with the advent of the transistor and high-level

programming languages, were computers considered economically viable for general

business purposes. With the introduction of the COmmon Business Oriented Language

(COBOL), programmers were able to describe data in more general terms. COBOL

provided the concept of fields linked together to form records, and records linked

together to form files. Two major limitations plagued the early systems, however.

First, records could only be accessed within files in two ways: sequentially or directly.

Sequential access means that to locate an individual record, every record in a file had to

be read, starting at the beginning of the file, until the record needed was found. Direct

access means that the exact location of the record within the file had to be known to

9

access it. Accessing data was a problem because the location of the specific record was

contained only within the application. Data used within one application was worthless to

another because of inconsistencies in the way each application stored data. Access limi-

tations were overcome in the late 1960s with the introduction of access methods within

software utilities called file management systems. "These systems developed and stan-

dardized models for organizing files and methods for accessing records within files"

(Jones, 1992: 58). Data storage methods were no longer application specific.

The second limitation with early systems was that files were formatted and owned

in a proprietary fashion by the using application. Data, records, or files from one

application could not be shared with other applications. This limitation was not

overcome until 1971 when the Committee On DAta SYstems Languages (CODASYL)

standardized the network data model as the database organization structure. The network

model allowed a host language (such as COBOL) to manipulate data through a "call"

sequence that insulated the programmer from the data, allowing multiple applications to

access the same data (Date, 1990). The network data model provided a good foundation

for data sharing, but was not understood by users. "The users could not effectively

communicate their requirements, understand the constraints imposed on them by these

systems, or control their own data management destiny" (Jones, 1992: 58).

In 1970 and 1971, E. F. Codd defined a mathematically based data organization

approach that was specifically designed to provide for the integration of databases and the

development of integrated database systems. The data was stored in tables with no

physical linkage between the tables. Data manipulation was provided through a language

that, like the network model, could be called from a host language. The language could

also be used independently to provide ad hoc inquiries in near English. This "relational"

database enabled users and developers to overcome the shortcomings of the network

10

model. It was not until the 1980s that developers of the relational database management

systems (RDBMS) began to standardize their data manipulation language. Systems Query

Language was standardized by the American National Standards Institute and the Inter-

national Organization for Standardization allowing for an almost universal acceptance of

the language (Jones, 1992; Date, 1990).

Theories of Data Sharinq

Data, in complex organizations, usually reside in many different forms and in

many locations. Problems become apparent when trying to access, validate, and share

the data. Older systems may be in application-unique formats while newer systems may

store data within a standardized format. Even though standards exist in modem systems,

there is enough leniency within the standards so that products from different suppliers

do not always work with the data stored by a competitor's product. Some database

management systems are not flexible enough to cross the boundaries between

microcomputers, minicomputers, and mainframe computers. In order to overcome data

obstacles, the user needs to access all of the data regardless of where or in what form it

resides (Brown, 1991; Jones, 1992; Rasmus, 1991). Differences arise, though, in

exactly how data sharing should be accomplished.

This survey of recent literature revealed that there are at least two poles of

thought on sharing data. All of the literature acknowledged that fully shared data, in any

form, was not available at the time of this writing.

The majority of the literature reflected the opinion that the best way to assure

data sharing was to design systems with sharing in mind (Goodhue and others, 1992;

Jones, 1992; Staples and Sharon, 1992; Von Halle, 1992, Wolf and others, 1989). One

advocated the use of a centralized data repository that would provide users with identical

11

access to all data regardless of where the data may be physically stored or the type of

data management system used (Jones, 1992). Another advocated designing all systems

around a common information systems data model to facilitate the sharing of data (Von

Halle, 1992). Not all reports were optimistic concerning the implementation of shared

data, however. Although planning and implementing data-integrated systems appeared to

be the answer for sharing problems, in reality, few organizations have succeeded. The

primary reason for failure was that firms were not prepared to undertake the cost of

rewriting all systems necessary to support the complete sharing of data (Goodhue and

others, 1992).

A contrasting opinion was that re-engineering all systems was not necessary to

provide access to all data. An open system interface that allowed all users to access data

residing in any machine or management system would provide the same function as

making the environment homogeneous. The basic premise was that an artificial intel-

ligence module would be used to identify the requestor and where the information

resided. The module would interpret the request and compile information from a variety

of databases on several hardware platforms. It would then return the results in a format

useable by the requestor (Rasmus, 1991).

There was a wide range of opinion as to who or what was to blame for the

inability of data to be shared. Parallel development of software systems without coor-

dination or sharing of technologies was one reason identified for the difficulty in estab-

lishing interfaces between systems or in developing an integrated approach to the entire

system design problem (Davis, D., 1987). The data owners' refusal to share was

mentioned as an additional contributing factor (Van Halle, 1992). The inability for

current standards to deal with in-place systems might have also been an element of the

problem (Jones, 1992). Another reason offered was that the standards were available,

12

but were not enforced (Brown, 1991). All agreed that a concerted, coordinated effort

was necessary to produce an integrated data environment.

Conclusions

In spite of the wide variety of perceived causes for the lack of data sharing, only

two solutions were suggested in literature. The majority of the contributors advocated

redesigning all applications around a common framework to solve the sharing problem.

An alternative suggested by one source was to develop an open-system interface with the

capability to act as a translator between dissimilar systems.

Introduction to Looistics Information Systems

Standard Base Supply System (SBSS). In 1963, the Air Force formed the

Supply Systems Design Office to "develop and control a standard USAF base supply

electronic data processing system" (Special Order G-58, 21 June 1963). One of the

first automation efforts in the Air Force, the SBSS functioned as a stand-alone system.

Interaction with other systems was through punched-card transactions. Transactions

from the SBSS for supply issues (office supplies, equipment issues, fuel, and so on)

were output on card decks which were then carried to the punched-card reader of other

systems for processing. Verification was through manual comparison of printed output

from both systems (Tyson, 1992).

By 1983, modifications to the SBSS allowed data to be transferred electronically

to the accounting and finance system. Updates from the SBSS were consolidated and

processed once a week with automated verification. Later SBSS revisions allowed for

more frequent updates, but still only in consolidated groups and not immediately. With

Increment II of the consolidated aircraft management system (CAMS), a maintenance-

supply interface was formed which allowed parts ordering and status updates to be

13

performed through the CAMS in individual transactions without lengthy delays (Tyson,

1992; FD-G83-004 Basic, 1983).

Consolidated Aircraft Management System (CAMS). The newest of the

systems studied, CAMS was initiated 5 May 1983 when HQ USAF Data Project Directive

DPD-HAF-G83-004 was issued. CAMS was to replace the Maintenance Management

Information and Control System used to gather maintenance data, man-hour usage, and to

track personnel training and certification (Hill, 1992). Implemented in seven

increments, CAMS was to have all the capabilities of its immediate predecessor as well

as (1) on-line maintenance data collection and work order generation, (2) a

maintenance-supply interface, (3) automated debriefing and Air Force Technical Order

Form 781-series forms generation, (4) administrative/logistics and personnel

availability tracking, (5) automated scheduling and multiple status inventory reporting

system, (6) follow-on comprehensive engine management system, and (7) quality con-

trol/assurance and production scheduling (FD-G83-004 Basic, 1983).

On-Line Vehicle Interactive Manaqement System (OLVIMS). From 1971,

vehicle maintenance control relied upon the Vehicle Integrated Management System

(VIMS), a mainframe, punched-card system, for data management. In the late 1970s,

the Air Force started a project to upgrade VIMS to run on the replacement to the

Burroughs base computer, the Sperry 1100. This system would allow operators to

update records and produce reports immediately from terminals rather than having to

produce punched cards and wait days for printed reports. However, the project was

canceled in 1985 due to a funds shortage (Fry, 1992).

In late 1985, the Standard Systems Center began work to move VIMS from the

mainframe system to the USAF standard microcomputer-the Zenith Z-248. Working in

14

stages, the plan was to initially provide Zenith Z-248s to act as terminals for input to

the VIMS running on the mainframe and then move the processing from the mainframe

entirely to the Z-248s. This first Air Force effort to transfer a major system from a

mainframe to microcomputers gave birth to the On-Line Vehicle Interactive Management

System (OLVIMS).

In 1986, OLVIMS Increment I fielded two million dollars worth of

microcomputers as data entry terminals and gave units a key-punch replacement

program with data review and edit capabilities. This effort released the maintenance

control specialists from working only from printed listings and punched cards.

In 1988, Increment II of the OLVIMS changed the hardware platform from the

standard base computer to the Air Force standard microcomputer. This change

eliminated the vehicle maintenance facilities' dependence on the central data processing

center while still maintaining all the functionality and processes of the VIMS. The VIMS

was decommissioned in December 1988, after OLVIMS was fully fielded.

OLVIMS III, fielded in May 1990, provided additional improvements. It

automated work order generation, work load control, warranty management, and

scheduled maintenance processing. This increment was reported as saving over two

million dollars by eliminating excess forms and reports, increasing productivity, and

enforcing warranties. Updates to OLVIMS III have added graphic analysis reporting,

parts failure analysis, and reporting aids for contracted operations.

15

Summary of the Literature Review

This chapter provided a history of the development of shared data technology and

progressed with theories of systems sharing and concluded with introductions to the

three logistics information systems under study. Chapter III describes the case study

method and the particular methodology of this thesis. Chapter IV provides a comparative

analysis of each system. Finally, Chapter V summarizes the previous four chapters,

draws conclusions about the interaction of the three logistics information systems under

study, and identifies further opportunities for research.

16

Ill. Methodologv

Orqanization of the Present Chapter-Overview

Chapter III describes the case study method and explains why this method was

chosen for use in this study. This chapter also describes some of the limitations of the

case study method. This chapter concludes with a description of the data collection

methods and how the data was chosen.

The Case Study

A case study "examines a phenomenon in its natural setting, employing multiple

methods of data collection to gather infomration from one or a few entities (people,

groups, or organizations). The boundaries of the phenomenon are not clearly evident at

the outset of the research and no experimenta, control or manipulation is used"

(Benbasat and others, 1987: 370). The purpose for the case study method is to "see new

theoretical relationships and question old ones" (Dyer and Wilkins, 1991:614). The

case study has established its usefulness in instruction and learning environments. It is

effectively used in industry to analyze in-house situations and to direct problem solving

because of its emphasis on detail (Bocker, 1987:64; Emory and Cooper, 1991:143;

Kellogg, 1985:60).

Why the Case Study

Selecting the case study method over other research methods was based on three

conditions: "(1 ) the type of research question posed, (2) the extent of control an

investigator has over actual behavioral events, and (3) the degree of focus on

contemporary as opposed to historical events" (Yin, 1989:16). Using this framework,

each condition is discussed below in relation to its applicability to this thesis.

17

Type of Research Question. As described in Chapter I, the purpose of this thesis

was to describe the current and potential ability for three logistics information

management systems to share data. Each system was studied to find communalities that

would indicate that data sharing had or could occur. A restatement of the purpose in the

form of a research question would be: How could the three information systems share

data? The strategies applicable in answering a "how" question, as identified in Table 1,

are experiment, history, and case study as opposed to survey and archival analysis

methods which delve into "how many" and "how much". The second criteria for

determining a research method is the amount of control the researcher has over the

subjects.

TABLE 1Relevant Situations

for Different Research Strategies

Form of Research Requires Control over Focuses onStrategy Question Behavioral events? Contemporary

Events?

Experiment how, why yes yes

Survey who, what,* no yeswhere, howmany, how much

Archival analysis who, what,* no yes/no(e.g., economic where, howstudy) many, how much

History how, why no no

Case Study how, why no yes* "What" questions, when asked as part of an exploratory study, pertain to all five

strategies.(Yin, 1989:17)

18

Extent of Control. The subjects of this study are information systems that are

managed centrally through the Air Force Standard Systems Center. The "subjects" are

located at most Air Force installations and are dynamically changing through system

maintenance and modification procedures. In essence, no control over behavioral events

was available for the purposes of this research. Looking again at Table 1, Experiment is

eliminated from the strategies available because this method requires control over

behavioral events.

Focus. Although a limited historical perspective was given for each logistics

information system, the major emphasis of the study was on the current systems. This

final criteria eliminates all strategies except Case Study.

Limitations of the Case Study Method

The case study method has several inherent limitations. First, the case study

method is descriptive rather than causal. The case study can only describe what events

have occurred without making any inferences as to why the events occurred. Without the

benefit of control over the subjects or variables, there is no predictive ability within

the case study method. No assumptions can be made that identical circumstances would

produce similar situations. The corollary to this observation is that the study can not be

replicated to verify the results as can be done with experimental methods.

Second, the case study is designed for depth rather than breadth. Generalizations

are not possible since no attempt is made to adequately describe characteristics of a

population by taking observations from a sample of items. Case studies emphasize

analysis of a limited number of events and their interrelations within a specific context.

19

Third, although the case study often uses hypotheses, the reliance on qualitative

rather than quantitative data makes their support or rejection more difficult. The case

study method's emphasis on detail can provide insight for problem solving, evaluation,

and strategy, however.

Finally, as with all research methods, the case study relies on the investigative

prowess of the researcher, even more so than with statistical and experimental methods

since the case study can not be replicated. (Benbasat, 1987; Emory and Cooper, 1991).

Data Collection

The primary data collection method was through documentation research.

Various forms of documentation including Air Force regulations, functional descriptions,

and training materials were reviewed along with briefings and other presentations on

the individual systems. Semi-structured interviews were also used to supplement the

documentation. Open-ended questions solicited information on background, application

output, and perceptions of usability.

Data Evaluation

A model was needed to identify components of information systems in order to

determine what portions might influence data sharing between systems. The first model

discovered was a general systems model (Ahituv and Neumann, 1990; McLeod, 1986).

Figure 3 shows a representation of the model used.

[ Input I I Processes output

Figure 3. General Information System Model (Ahituv and Neumann, 1990;

McLeod, 1986)

20

This model did not provide sufficient detail, however. Senn suggests that

processes could be expanded to include applications, database management systems, and

operating systems (Senn, 1989).

Applications

Input Database Management OutputSystems

OperatingSystems

Figure 4. Expanded Information System Model (Ahituv and Neumann, 1990;McLeod, 1986; Senn, 1989)

Applications, database management systems, and operating systems are written

in programming languages. Each may be in one or more languages; therefore, the

various languages could be considered a component of the information system (Sullivan,

Lewis and Cook, 1985).

The final component of the information system is the physical portion. The

computer machinery itself, the internal and external accessories, and anything attached

to the machinery, such as communication lines, constitute the physical component. The

physical component is usually called hardware (Ahituv and Neumann, 1990; Stamper,

1991; Sullivan, Lewis and Cook, 1985). Figure 5 illustrates the complete information

system model. Notice that all other components except language are included within

Hardware since each depends, to a greater or lesser extent, on the physical components

for their usefulness. Language includes the software portion of the system.

21

Language

ApplicationsInput Output

DatabaseManagement

System

Data Operating HardwareSystem

Figure 5. Complete Information System Model (Ahituv and Neumann, 1990;McLeod, 1986; Senn, 1989;Sullivan, Lewis and Cook,1985)

Each of the eight system components, (1) input, (2) output, (3) applications,

(4) database management system, (5) operating system, (6) language, (7) hardware,

and (8) data, were scrutinized to see if any could impact data sharing. Below is a

narrative description of each of the components along with a discussion of whether the

component should or should not be included in the evaluation of the three logistics

support systems. Determination of inclusion or exclusion was made with the assistance

of thesis advisors.

input and Output. Input and output were treated as one component because inputs

to one system may be outputs from another system and similar or identical methods are

used for both operations. An input uses a mechanical, electrical or magnetic medium to

place data within the system in a form that the system can understand. Common input

methods include reading magnetic tapes, magnetic disks, and punched cards; typing on

terminal keyboards; and using optical scanners and communications ports. Output

22

divulges the contents of the system in either a human or machine readable format.

Examples of output methods included writing magnetic tapes, disks, and punched cards;

and sending data to terminal screens, printers, and communications ports.

Without the ability to physically transfer the data from one system to another on

a common medium, data sharing will be extremely difficult. The exact medium of

transfer-electronic or mechanical-may also have some significance depending on the

time and effort required to enact a data transfer. For example, keying data into a

terminal from a printed output may cost more in time than the value of the data. Sharing

data, although possible, may be so time consuming and labor intensive that it would not

be feasible except on an infrequent basis.

Conclusion: input and output devices could impact data sharing.

Apolications. An application is what the vast majority of information systems

users see and interact with. The application is an integration of logically related

programs to accomplish a specific purpose (Ahituv and Neumann, 1990; Senn, 1989).

Applications are used as a user interface or front end to database management systems

(Date, 1990). Figure 6 shows the relationships between applications, database

management systems, operating systems, and hardware.

End User

F- Applications

rDatabase Management system

I perating System

F- Computer Hardware

Figure 6. System Internal Relationships (Date, 1990; Kroenke, 1992)

23

Conclusion: based on this design, applications used in conjunction with a database

management system would not significantly impact data sharing. Applications that

directly stored, retrieved, and processed data without an intervening database could have

a significant impact on data sharing.

Database Manaqement System. A database management system (DBMS) is a

software package that facilitates the creation and manipulation of a database (Date,

1990; Hipgrave, 1985; McLeod, 1986). Some of the functions the DBMS performs

include defining, processing, retrieving, adding, changing, or deleting data within a

database (Date, 1990; Kroenke, 1992; Pfaffenberger, 1991).

The DBMS controls the structure of the data, that is, how long it is, whether

numbers, characters or both were allowed and in what order. It also determines how the

data is stored and retrieved. The physical storage of the data is accomplished through the

operating system. The database management system also passes data to applications for

processing.

Conclusion: the database management system could impact data sharing.

Operatina System. An operating system is software that is used as an interface

between the user, the applications, the database management system, and the physical

hardware of a computer. The operating system supervises the workload of the computer,

controls input and output, manages the computer's memory, places data on storage

media, protects the user from errors within the computer or application, provides a

way to share data between programs, and controls the sequence of execution for

programs (Hipgrave, 1985; Lister, 1984).

24

Commercial products exist that can move data between operating systems

irrespective of the transfer medium. Degradation of the data is not a problem since the

operating system does not process or modify the data.

Conclusion: operating systems would not significantly impact data sharing.

Langluae A computer programming language is a code that gives the computer

instructions on how to manipulate data. The more sophisticated (or higher) the

language, the more closely the code resembles a spoken language. The lowest language,

machine code, is a series of Os and 1s (Savitch, 1988).

Computer languages have the ability to initiate other programs that are not

necessarily in the same language. Also, application programs for a single database

management system are written in various languages without affecting the ability of the

DBMS to perform its functions.

Conclusion: computer programming languages would not significantly impact data

sharing.

Hardware. Computer hardware is the physical component of the computer. It

includes input devices, output devices, one or more processing units, memory, and

storage devices. The hardware is incapable of manipulating data by itself. With

instructions from a program, the hardware is able to move and process data (Savitch,

1988; Sullivan, Lewis, and Cook, 1985).

The Air Force, through its contracting practices, has forced standardization of

computer hardware. Allowing buys only from the standard small computer and standard

multi-user small computer contracts has resulted in almost homogeneous computer

25

hardware. As older, non-standard machines wear out and are replaced, only standard

machines will remain. Large computers fall under similar criteria.

Conclusion: computer hardware would not significantly impact data sharing.

Data. Data are the raw facts and figures that are used for discussion, decision

making, calculating, or measuring (McLeod, 1986). Data are contained inside, or

outside of an automated system. For the purpose of this paper, data are considered to be

residing within an automated system.

The data elements and their corresponding definitions are a prime indicator of the ability

to consistently share data. Individual data elements with the same name and different

purposes or the same purpose but different formats complicate the ability to share data.

On the former, confusion exists as to whether a specific data element is correct to use

for accurate transactions. The latter requires some translation or may preclude sharing

if the format is too limiting.

Conclusion: data could significantly impact data sharing.

Conclusion. After discussing the eight components of an information system, it is

found that, because of their similarities, two can be readily combined to form one. Of the

other six, only half could impact data sharing. The final four components that could

impact data sharing and will be used to evaluate each logistics information system are:

(1) input and output, (2) applications, (3) database management system, and (4) data.

Table 2 graphically depicts this summation.

26

TABLE 2

Information System Components and Data Sharing

Component Affect on Data Sharing

1 Input Impact Combined with 2

2 Output Impact Combined with 1

3 Applications Significant Impact if no DBMS

4 Database Management System Impact

5 Operating System No Impact

6 Language No Impact

7 Physical No Impact

8 Data Significant Impact

Summary

Chapter III described the case study method, explained why it was chosen for use

in this study, and described some limitations of the case study method.. This chapter also

discussed what data collection methods were used and how the data were evaluated,

Chapter IV describes the the four factors considered significant to data sharing within

Chapter III: input and output devices, applications, database management system, and

data, in relation to the three logistics information systems. Finally, Chapter V

summarizes the previous four chapters, draws conclusions about the interaction of the

three logistics information systems under study, and identifies further opportunities for

research.

27

IV. Findings

Ormanization of the Present Chapter-Overview

Chapter IV describes the the four factors considered significant to data sharing

within Chapter III: input and output devices, applications, database management system,

and data, in relation to the three logistics information systems.

Findinqs

Findings for input and output, applications, and database management system are

summarized in Table 4, below. Explanations follow the table.

TABLE 3

Comparison of Logistics Information Systems and System Components

Component CAMS SBSS OLVIMS

Input and Output Sperry 1100/ Sperry 1100/ Microprocessor2200 Based 2200 Based Based

ICI ICI

1/2 inch Mag 1/2 inch Mag 1/4 inch MagTape Tape Tape

5 1/4 inch 5 1/4 inchFloppy Disk Floppy Disk

Terminals Terminals Terminal

DDN DDN

Printers Printers Printers

28

TABLE 3, Continued

Component CAMS SBSS OLVIMS

Applications Front end to Front end to Direct DataDBMS DBMS Manipulation

DatabaseManagement Network Hierarchical NoneSystem I I

(AFM 66-279, Vol XXVII, 1992; AFM 67-1, Vol II, Part 4, Chapter 5, SectionA, 1991; AFM 77-320 Vol I, 1992; Tyson, 1992; Steinhardt, 1992)

Input and Output. The SBSS and CAMS reside on the same Sperry 1100 or 2200

series mainframe computer, depending on what is installed at the particular location.

Sharing hardware greatly facilitates their sharing data. The Interactive Communication

Interface (ICI), an operating system utility program, aids in transferring data between

the SBSS, CAMS and other systems. It allows formatted data to be transferred from one

system to another or between different locations. Between two locations, the ICI will

format the data for transfer over the Defense Data Network (DDN) using a transmission

control procedure/internet protocol. (AFM 66-279, Vol XXVII, 1992; AFM 67-1, Vol

II, Part 4, Chapter 5, Section A, 1991; Tyson, 1992; Steinhardt, 1992).

The OLVIMS resides on the standard Air Force Microcomputer. Input and output

are somewhat limited because there is no provision for data transfer by way of

communications lines, either DDN or telephone. Limited data transfer between OLVIMS

and SBSS is carried out by placing data on a 5 1/4 inch magnetic floppy disk and

physically carrying it to the other system. Updates and reports that are required by

higher headquarters are transferred by means of a magnetic disk through the mail.

Other than printing data from one system and then keying the data through a terminal on

the other system, there are no common transfer mediums between OLVIMS and CAMS

(AFM 77-320 Vol I, 1992; Guchian, 1992; Steinhardt, 1992; Teti, 1992).

29

Applications. The SBSS and CAMS applications function as a front end to the

database management systems for their respective systems. The applications do not deal

with the data directly; therefore, the applications neither help nor hinder data sharing.

The OLVIMS is a data storage and retrieval application without a database system.

Applications manipulate the data directly instead of going through a file management or

data management system. Two-way links between files are identified within the files

themselves, but the location of the links within the file is only known by the application.

Application dependence makes data sharing difficult, but not impossible. In order to

share data with other than OLVIMS applications, an application must be used that knows

exactly where the data and its corresponding links are. In addition, access to data within

the files is through keys and subkeys. In order to recall specific data, an operator has to

know the specific key, usually a vehicle number or a work-order number (Farrell,

1992).

Database Management System. Both the SBSS and the CAMS use a database

management system. Application independence allows data to be shared more easily since

data can be manipulated without having intimate knowledge of the way the data is

physically stored within the system.

The SBSS database uses the Sperry Data Management System- 1100 for data base

definition. The SBSS database is designed using the CODASYL Worldwide Standards

Committee specifications. Access to the database is through a hierarchical relationship.

In order to navigate through the database, several levels have to be traversed. '-irst, the

area is located, then the record within the area, and, finally, the data element within the

record. The database is divided into 38 areas, and 244 records. Records are further

grouped into nine types or categories to aid in reports and reports processing. Record

30

types are scattered throughout the areas and were not limited to one type in any one area

(AFM 67-1, Vol II, Part 4, Chapter 5, Section A, 1991).

The description of the database (including how the data is stored) is contained

within the database itself. This coexistence allows greater versatility in data sharing.

The description resides in a file called "SBSS*SCHEMAS" that also contains the data

dictionary. The database description identifies the location of each data element by coding

what record it is stored within. Each record is identified by a unique three-character

code which also is the first three characters of the data element label. For instance, the

element "National Stock Number" is code "AQNOO1 ," meaning it is the first element in

the "AQN" record (AFM 67-1, Vol II, Part 4, Chapter 5, Section A, 1991; "Element and

Property Definition Information List," 1992).

The CAMS database is managed through a network database structure. Similar to

a hierarchical structure, the network structure also requires passing through several

layers to arrive at the data element. Access to the data element is through a database key.

The key is composed of the area name, page number, and record number that the data

element resides in (AFM 66-279, Vol I, 1990).

The description of the CAMS database is included in files integral to the database,

again, making data sharing easier. The overall description is contained in a file called

"SCH/DOC-5R 1" with paths between levels described within files called "QLP/DOC-

5R1" for single-level navigation and "CV/DOC-SR1" for selected multi-level navigation

(AFM 66-279, Vol XIX, 1992).

The OLVIMS was built without using a database management system. Absence of a

database management system makes data sharing very difficult for reasons explained in

the applications section. In order to allow ad hoc inquiries of the system, a conversion

31

application was designed to translate the OLVIMS files into CONDOR III formatted database

management files. Using Condor Ili allows inquiries other than standard reports to be

made utilizing the CONDOR III database management system (Farrell, 1992; AFM 77-

320, Vol 1, 1992)

Data. Fifty data elements from the three logistics information systems were

compared. Elements were chosen as those most likely to either be shared among the

three systems or required for management reports and review. These elements were

confirmed by the thesis advisors. The list of data elements, along with the systems in

which they reside and their structure, is contained in Table 4.

TABLE 4

Data Elements Within Logistics Information Systems

Data Element SBSS CAMS OLVIMS

1 ACTION DATE 5 N 5 N (YYDDD) 5 N (YYDDD)

2 ACTION TIME 4 X 4 N (HHMM) 4 N (HHMM)

3 APPOINTMENT DATE 6 X (YY/MM/DD)4 COST lox _7 N (99)

DATE 6 N (YYMMDD)

6 DATE 5 N S N (YYDDD)

7 DATE 4 X_

8 DATE OPENED 5 N (YYDDD)

9 DOCUMENT NUMBER 8 X

10 DOCUMENT NUMBER 14 X 14 X 14 X

11 DOCUMENT NUMBER 16 X

12 DOLLAR VAWE 8 N (99)

13 ELEMENT OF EXPENSE 3 X 3 XINVESTMENT CODE

14 ELEMENT OF EXPENSE 5 XINVESTMENT CODE

32

TABLE 4, Continued

15 EMPLOYEE NUMBER 5 N 5 N

16 EQUIP ID/SERIAL NUMBER 7X

17 EXTENDED COST 1ON

18 EXTENDED COST 8 X19 EXTENDED COST, SIGNED 10 SN

20 EXTENDED PRICE 8 SN (99)Data Element SBSS CAMS OLVIMS

21 NATIONAL STOCK NUMBER 18 X 12 X

22 NSN/PN/QRLNR 15X 15 X 12 X

23 NOMENCLATURE 19 X 15 X 15 X

24 ORGANIZATION CODE 3 N

25 ORGANIZATION CODE 3 X 2 X

26 ORGANIZATION 12 XIDENTIFICATION CODE

27 ORGANIZATION/SHOP CODE 5 X

28 QUANTITY 6 X29 QUANTITY 1ON

30 QUANTITY 7 SN

31 QUANTITY 6 N

32 QUANTITY 4 N 3 N

33 QUANTITY S N 5 N

34 QUANTITY 2N

35 QUANTITY 7 SN

36 QUANTITY 1 N37 QUANTITY 8 N38 QUANTITY 5 SN

39 QUANTITY ORDERED/ 5 N 5 NDUE IN

40 RESPONSIBILITY/COST 6 X 6 X

CENTER CODE

41 STOCK NUMBER 15 X

42 TIME OPENED 4 N (HHMM)

33

TABLE 4, Continued

Data Element SBSS CAMS OLVIMS

43 TOTALCOST _6 N (99)

44 TOTAL COST _7 N

45 UNIT OF ISSUE 2 X 2 X

46 UNIT-ID 1 A 2X

47 URGENCY JUSTIFICATION 2 X 2 XCODE

48 USER IDENTIFICATION 6 X

49 VEHICLE REGISTRATION 8 X 6 X

NUMBER I I I _I

KEY: The initial numeral indicates the number of characters available to the dataelement. The second group of characters indicates the type of characters allowed in thedata element. The group in parenthesis indicates a specific format that is required forthat data element.

Data Type Format

X Any Character Y YearA Alphabetic Character M MonthN Numeric Character D DaySN Signed Numeric (+ or -) H Hour

M Minute9 Decimal Place, 1 for each

(AFM 66-279, Vol XXVII, 1992; AFM 77-320, Vol 1, 1992; "Element and PropertyDefinition Information List," 1992)

Data Dictionary. The SBSS was the only system studied that has a computerized

data dictionary. It lists the data code which identifies the record the data resides in, the

name of the data element, and the input, interrogation, and output formats of the data. It

does have shortcomings, however. The data dictionary does not have a narrative

description of the data elements even though several have identical or similar names but

different structures. For instance, Table 5, data elements 5 through 7 are all DATE, one

with six numerals, one with five numerals, and the last with four characters of any

kind. There are ten QUANTITYs with as many different structures. The lack of

34

exhaustive definitions will cause problems in identifying appropriate data elements and

could lead to incorrect or nonsensical results.

The CAMS contains 20 subsystems within its overall umbrella. Each of the 20

subsystems is accompanied by its own manual which contains the data dictionary for that

subsystem. Data elements compared in this study are from the Maintenance-Supply

Interface Subsystem which is described in AFM 66-279, Vol XXVII, 1 March 1992.

The CAMS data dictionary provides sufficient detail to identify the function as

well as the structure of each data element. The data dictionary is arranged by input and

output format screens with data descriptions arranged in the order in which they appear

on the screen. There is no comprehensive dictionary that lists data elements in

alphabetical order nor is there any indication of how or where the data is stored. This

arrangement of data elements makes identifying eligible elements for data sharing very

difficult. It also could lead to errors caused by falsely identifying data. Data stored in

one element could easily be mistaken for multiple elements or different data elements

for references of a single element. This is the result of the confusion caused by element

names which are listed in multiple screens but no storage location is given.

OLVIMS data definitions listed in AFM 77-320 Vol 1, 1 May 1992, are the most

comprehensive of the three systems studied. However, like the CAMS, the data elements

are grouped by screens and listed in the order of their appearance. Also, the lengths of

the data elements are not explicitly stated. Lengths were determined in this study by

either reviewing the format within the definition of the element or by counting the

spaces shown on the screen rendition in the manual, a very risky arrangement. Errors

in data element length could make data sharing difficult. For instance, in Table 5, data

element 22, OLVIMS allows 12 characters, while SBSS allows 18. SBSS sharing

35

OLVIMS' NATIONAL STOCK NUMBER would not be a problem because SBSS NATIONAL

STOCK NUMBER is larger than OLVIMS NATIONAL STOCK NUMBER. OLVIMS sharing SBSS

NATIONAL STOCK NUMBER would require some method of shortening the data element in

order that it would fit into OLVIMS' allocated space.

Data Element. Data is most easily shared when the format for the data element is

identical. For instance, Table 5, data element 15, EMPLOYEE NUMBER, is identically

formatted for CAMS and OLVIMS. An identical format allows an employee number to be

used by either system without adverse effects. Identical data elements occur in Table 5,

Elements 1, 10, 33, 39, 40, and 46.

For data elements that are not identically formatted, the data must be converted to

a common format before sharing. This action can become quite involved and may require

user intervention. For instance, Data Element 4, COST, when sharing from SBSS to

OLVIMS, requires that multiple manual transactions be made to account for items that

cost $10,000.00 or more. Other, less critical data are truncated automatically, such as

data element 23, NOMENCLATURE, or zeros in specific places are removed, such as data

element 50, VEHICLE REGISTRATION NUMBER, so that the data will fit into the data

element (AFM 77-320, Vol I).

Summary

Chapter IV described the the four factors considered significant to data sharing

within Chapter III: input and output devices, applications, database management system,

and data, in relation to the three logistics information systems. Chapter V will provide a

summation of Chapters I through III, provide conclusions drawn from the results

reported in Chapter IV, and list recommendations to enhance data sharing between the

logistics information systems. Finally, topics for further study will be considered.

36

V. Summary. Conclusions. and Recommendations

Orqanization of the Present Chapter-Overview

This chapter provides a summation of Chapters I through III, draws conclusions

from the results reported in Chapter IV, and list recommendations to enhance data

sharing between the logistics information systems. Finally, topics for further study

will be considered.

Summary

The Air Force has changed. With this change has come a shift in management

responsibilities within the logistics community. Formerly diverse functions have come

under the purview of a single manager-the Logistics Group Commander. This single

manager has inherited information systems that may or may not be able to provide

consolidated information in order to make informed and accurate decisions. The purpose

of this thesis was to describe the current and potential ability for three logistics

information management systems to share data.

A literature review conducted within the scope of this thesis has discovered two

theories on how data sharing might be possible. The first was to design or redesign all

information systems to share data. The second was to design an open system interface

that would use artificial intelligence to translate data and inquiries between database

management systemsn All of the authors admitted that no fully shared data systems have

been implemented as of this writing.

This thesis used the case study methodology to produce its results. Data collection

was through documentation research with secondary emphasis placed on personal

interviews using open ended questions. The components of the logistics information

37

systems that were evaluated for inclusion in the study were input, output, applications,

database management system, operating system, programming language, computer

hardware, and data. The four areas that could have impacted data sharing and were

included in a more thorough investigation were the input and output (treated as a single

component), applications, database management system, and data.

Conclusions

Input and Output. All systems had adequate input and output methods to share data

with other systems. The input and output for the OLVIMS, however, was inadequate for

increasing the frequency of sharing data above that which was used at the time of this

study. Limiting input to the terminal's keyboard or to a magnetic disk may require an

inordinate amount of time and effort to be expended by an operator in relationship to the

amount and significance of the data that is entered into the system. SBSS and CAMS have

the greatest potential for sharing data because both systems share hardware. CAMS and

OLVIMS have the least potential for sharing data because there are no high-speed

common input and output methods between the two.

Applications. The SBSS and CAMS applications were neither a hindrance nor a

help to sharing data between systems. Because the applications acted as front ends to

database management systems, the applications did not directly affect the data. Within

OLVIMS the applications did directly affect the data. The structure of the data was

contained within the application itself; therefore, any attempt to share the data would

require intimate knowledge of the application in order to share the data with another

system. SBSS and CAMS have the greatest potential for sharing data because of the

absence of application specific data. OLVIMS has the least potential for sharing data

because of its application specific data requirement.

38

Database Manaqement System. The use of a database management system within

the SBSS and the CAMS significantly enhanced the ability to share data contained within

the systems. The data structure and relationships were readily available without having

intimate knowledge of the application. Inquiries, modifications, additions, and deletions

could be made utilizing the utilities within the database management system. SBSS and

CAMS have the greatest potential for sharing data because of their use of standardized

database management systems. OLVIMS has the least potential for sharing data because of

its lack of a standardized database management system.

Data. The largest obstacle for sharing data in all three systems was the data

itself. All three systems had shortfalls in the documentation describing the data

elements. The SBSS data dictionary was the easiest to use, but did not contain data

descriptions to differentiate elements with identical or similar names. The OLVIMS data

dictionary had the best descriptions of the data, but was ungainly to use and did not

definitively identify the lengths of the elements.

The shortfalls within each data dictionary made identification of all identical data

elements impossible. Even though the SBSS and CAMS and the SBSS and OLVIMS regu-

larly interact, the documentation was not comprehensive enough to identify which data

elements were being used between the systems. The inadequacies of the data dictionaries

would preclude any universal data sharing between the three systems studied and any

other systems.

Recommendations

Any information management system can be improved, but the purpose of this

section is not to find fault but to recommend areas that need attention in order to facili-

tate data sharing. Some data sharing has occurred, but the potential exists that much

39

more could occur with some modifications to the existing logistics management systems.

The recommendations are listed in decreasing order of significance.

Emphasis should be placed on completing the data dictionaries within each logis-

tics information system. Only then can any real progress be made on sharing data

between systems. Without a comprehensive, logically ordered data dictionary available

for systems developers, any attempt at sharing data among new or existing systems

would be very difficult or futile.

The input and output capability of OLVIMS should be enhanced. The limitation of

methods to communicate with other systems precludes data sharing.

OLVIMS should be redesigned around a database management system. With an

application independent database, data sharing as well as ad hoc inquiries would be

significantly simplified.

Further Study

This thesis is only a scratch on the surface of a very large mountain. The 19

other modules of CAMS as well as all the other logistics management systems within the

Air Force deserve similar analysis. Also, when adequate data dictionaries become

available for the three logistics support systems studied within this thesis, data

elements could be scrutinized to determine if the systems could be streamlined while

data elements can be eliminated, consolidated, or otherwise modified, further

simplifying already complex logistics information systems.

40

Aooendix: Acronyms

CAMS: Consolidated Aircraft Management System

COBOL: COmmon Business Oriented Language

CODASYL Committee On DAta SYstems Languages

DBMS: Database Management System

DDN: Defense Data Network

ICI: Interactive Communication Interface

OLVIMS: On-Line Vehicle Interactive Management System

SBSS: Standard Base Supply System

TCP/IP: Transmission Control Procedure/Internet Protocol

VIMS: Vehicle Integrated Management System

41

Bibliography

Ahituv, Niv and Seev Neumann. Principles of Information Systems for Manamement.Dubuque IA: Wm. C. Brown Publishers, 1990.

Air Force Data Systems Design Center. Core Automated Maintenance System CombatMaintenance System Functional Description (Basic). FD-G83-004 Basic.Gunter AFS AL: Air Force Data Systems Design Center, Maintenance Division,1983.

Benbasat, Izak and others. 'The Case Research Strategy in Studies of InformationSystems," MIS Quarterly, vol 11. no 3: 369-388 (September 1987).

Bbcker, Franz. "Is Case Teaching More Effective Than Lecture Teaching in BusinessAdministration? An Exploratory Analysis," Interfaces, vol 17, no 5: 64-71(September-October 1987).

Brown, P. "Integrated Hypertext and Program Understanding Tools," IBM SystemsJournal, vol 30, no. 3: 363+ (September 1991).

Date, C. J. An Introduction to Database Systems. Volume I. New York: Addison-WesleyPublishing Company, 1990.

Davis, Daniel. "Interfacing and Integrating Hardware and Software Design Systems," TheDesian. Development and Testing of Complex Avionics Systems: ConferenceProceedings Held at the Avionics Panel Symoosium in Las Vegas. Nevada on 27April - 1 May 1987. 30-1 thru 30-8. Neuilly-sur-Seine, France: AdvisoryGroup for Aerospace Research and Development, 1987 (AD-Al 98 666).

Davis, Michael W. Applied Decision Suoport. Englewood Cliffs NJ: Prentice-Hall,1988.

Department of the Air Force. Eguioment Maintenance: Core Automated MaintenanceSystem (CAMS). DSD: G054/FS (PA). Database Management. Users Manual.AFM 66-279, Vol XIX. Washington: HQ USAF, 1 March 1992.

Department of the Air Force. Eguioment Maintenance: Core Automated MaintenanceSystem (CAMS). DSD: G054/FS. Introduction to the Core Automated MaintenanceSystem. Users Manual. AFM 66-279, Vol I. Washington: HQ USAF, 1 November1990.

Department of the Air Force. Eguioment Maintenance: Core Automated MaintenanceSystem (CAMS). DSD: G054/FS. Maintenance-Supoly Interface. Users Manual.AFM 66-279, Vol XXVII. Washington: HQ USAF, 1 March 1992.

42

Department of the Air Force. Motor Vehicles: On-Line Vehicle Interactive ManaqgmentSystem (OLVIMS): B004/VO, End User Manual. AFM 77-320, Vol I.Washington: HQ USAF, 1 May 1992.

Department of the Air Force. USAF Standard Base SUDDIV System. AFM 67-1, Vol II,Part Four. Washington: HQ USAF, 1 November 1987.

Dyer, W. Gibb, Jr. and Alan Wilkins. "Better Stories, Not Better Constructs, ToGenerate Better Theory: A Rejoinder to Eisenhardt," The Academy of ManagementReview, vol 16, no 3: 613-619 (July 1991).

"Element and Property Definition Information List," Standard Base Supply System FileMaintenance Listing, 22 June 1992.

Emory, C. William and Donald R. Cooper. Business Research Methods. Homewood IL:Richard D. Irwin, Inc., 1991.

Farrell, Philip J., OLVIMS Programmer/Systems Analyst. Personal interview.SSC/LGTRV, Gunter AFB AL, 14 September 1992.

Fry, Jerry, Program Manager, OLVIMS. Personal interview. SSC/LGTRV, Gunter AFBAL, 30 July 1992.

Goodhue, Dale L. and others. "Strategic Data Planning: Lessons From the Field," MISQuarterly. vol 16, no 1: 11-34 (March 1992).

Guchian, Kim, VIMS Manager. Personal interview. TECOM Inc., 2750 LogisticsSquadron/TR, Wright-Patterson AFB OH, 23 June 1992.

Hill, SSgt Charles L., Core Automated Maintenance System Manager. Personal interview.2046 Communications Group, Wright-Patterson AFB OH, 8 May 1992.

Hipgrave, Richard. Computing Terms and Acronyms: A Dictionary. London: The LibraryAssociation Publishing Limited, 1985.

Jones, Mark R. "On the Shoulders of Giants: Unveiling Repository Technology, part 2,"Database Proqramming and Design. vol 5. no 5: 58+ (May 1992).

Kellogg, Douglas E. "The 'closed-loop' case," Harvard Business Review. vol 85. no 4:60-65 (July-August 1985).

Kroenke, David M. Database Processing: Fundamentalse Design. Implementation. NewYork: Macmillan Publishing Company, 1992.

Lister, A. M. Fundamentals of ODeratina Systems. London: Macmillan Publishers Ltd.,1984.

McLeod, Raymond Jr. Manaaement Information Systems. Chicago: Science ResearchAssociates, Inc., 1986.

43

McPeak, Merrill A. Tomorrow's Air Force: Reshaping the Future. Videotape. USAF PIN611362DF.

Nguyen, Bao T., Air Force Data Manager. Telephone interview. SAF/AAID, WashingtonDC, 28 April 1992.

Pfaffenberger, Bryan. Que's Comruter User's Dictionary. Second Edition. Carmel IN:Que Corporation, 1991.

Rasmus, Daniel W. "Integrating Distributed Information: Merging Information FromDiverse Sources Sometimes Takes Just a Little Common Sense," Byte, vol 16, no.12: 247+ (November 1991).

Savitch, Walter J. Turbo Pascal: An Introduction to the Art and Science ofProgramming. Menlo Park CA: The Benjamin/Cummings Publishing Company,Inc., 1988.

Senn, James A. Analysis and Design of Information Systems. New York: McGraw-HillPublishing Company, 1989.

Stamper, David A. Business Data Communications, Third Edition. Redwood City CA: TheBenjamin/Cummings Publishing Company, Inc., 1991.

Staples, Geoffrey and Dave Sharon. "Earthquake Insurance One Integration Approach,"Software Magazine, vol 12, no 2: 41+ (February 1992).

Steinhardt, SSgt Lyle A., Interactive Communication Manager. Personal interview.SSC/SSBOT, Gunter AFB AL, 28 Sep 1992.

Sullivan, David R. and others. Computing Today: Microcomputer Concepts andApplications. Boston: Houghton Mifflin Company, 1985.

Teti, William T. Supervisor, Maintenance Control. Personal interview. TECOM Inc.,2750 Logistics Squadron/TR, 23 June 1992.

3400th Technical Training Wing. Base Level System Interfacing with Supply. StudyGuide (SG) G3AAR64572 001 -IV. Lowery AFB CO: 3440th Technical TrainingGroup, 1987.

Tyson, MSgt Stephen M., SBSS Manager. Personal interview. 2750 Logistics Squadron,Wright-Patterson AFB OH, 15 May 1992.

Von Halle, Barbara. "Share and Share Alike: The Data-sharing Lesson is Tough to Leam,but it's a Worthwhile Exercise," Database Programming and Desiqn. vol 5. no 3:15+ ( March 1992).

Wolf, Joel L. and others. "Multisystem Coupling by a Combination of Data Sharing andData Partitioning," IEEE Transactions on Software Engineering., vol 15, no 7:854- 860 (July 1989).

44

Yin, Robert K. Case Study Research: Design and Methods. Newbury Park CA: SagePublications, Inc., 1989.

45

Vita

James E. Hogue was born on 25 December, 1956 in Albany California. He

attended Wayland Baptist University, Plainview, Texas, receiving the degree of Bachelor

of Music with a major in Education in May 1979. He was commissioned in the Air Force

through Officer's Training School in February, 1980. He has held several positions in

the Air Force, including: Executive Officer at the squadron and wing level, Squadron

Section Commander, Assistant Operations Support Branch Chief, and Assistant Chief,

Central Base Administration. He has served at Scott Air Force Base, Illinois; Lackland

Air Force Base, Texas; Royal Air Force Woodbridge, United Kingdom; and Pope Air Force

Base, North Carolina. Mister Hogue was selected to attend the Air Force Institute of

Technology, Wright-Patterson Air Force Base, Ohio, in the School of Logistics and

Acquisition and attended as a student from May 1991 until his separation. He was

separated from the Air Force as a captain under the voluntary separation program in

August 1992.

Permanent address: 118 N. BermudaWaco, Texas 79072

46

Form ApprovedREPORT DOCUMENTATION PAGE OMB No 0704-0188

- *'.:- ~'- - -'~ ~ "e~ec ' ,-e ýf"- c -n t 3vnt Snd co mnent-s regaad ts gdnet 1-ale an, cie aspect of 1Tiic 7:,gl v- ýs lo, ;et'' c rec..c-r :ý. .'orer ! .'39' ge,ýg' -. aac~a,!e's S_, e s,- .e. r Clorat fc- "nforat'-c Ooe'a:.--, inc Reeoc's 'i'S eilerson

•a• -- .. -. " . ;', :' . U222-43N2 an tzi t- ¶ Of",e :4 %Narement arc auage. Paoe',cr, Reduclon P1o0eC (07C4."088)r .' z" 2-C 2C,3

1. AGENCY USE ONLY (Leave blanA) 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED

December 1992 Master's Thesis4. TITLE AND SUBTITLE 5. FUNDING NUMBERS

iAUTOMATED LOGISTICS INFORMATION SYSTEMS:'A CASE STUDY

6. AUTHOR(S)

James E. Hogue

7. PERFORMiNG ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATIONREPORT NUMBER

Air Force Institute of Technology AFIT/GIR/LSR/92D-4Wright-Patterson AFB OH 45433-6583

9. SPj.C)pSOI.(= MON!T ORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING MONITORINGAGENCY REPORT NUMBER

11. SUj'EVNTrARY NOTES

12a. CSR:'.!'ON AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE

Approved for Public Release: DistributionUnlimited

13 A •,....•CI' m,. 200 words)

A change within the Air Force has shifted management responsibilities within the logistics commu-nity. Formerly diverse functions have come under the purview of a single manager-the LogisticsGroup Commander-who has inherited information systems that may not be able to provide consol-idated information for informed and accurate decision making. The purpose of this thesis was todescribe the current and potential ability for three logistics information management systems toshare data: Standard Base Supply System, Consolidated Aircraft Management System, and On-LineVehicle Information Management System. A systems model was synthesized from the literature

4 review to determine what components of a system may impact data sharing. Identified were inputand output, applications without a database management system, absence of a database managementsystem, and the data itself. Data was gathered through the study of each system's documentation alongwith interviews from systems managers and experts. It was found that documentation for systemdata was inadequate and was the largest obstacle to data sharing. Recommendations included revisingdocumentation, providing more input and output capability for the On-Une Vehicle InformationManagement System, and redesigning the On-Line Vehicle Information Management System to operatearound a database management system

14. SUBJECT TERMS 15. NUMBER OF PAGES

,Data Sharing Data Management 58Information Exchange Information Transfer 16. PRICE CODE

Logistics Management Logistics Support17. SECURITY CLASSIFICATION 18. SECURITYECURITY CLAS.NIFICATION 20. LIMITATION OF ABSTRACT

OF REPORT OF THIS PAGE OF ABSTRACT

Unclassified Unclassified Unclassified ULNSN 7540-0" 280-5500 Stara-od -o0- 298 -Rev 2-89)

P2,9 c' 3-- ID -INS. Sic Z40 8298 '32

AFRT Control Number AFIT/GIR/LSR/92D-4

AFIT RESEARCH ASSESSMENT

The purpose of this questionnaire is to determine the potential for current and furure applicationsof AFIT thesis research. Please return completed questionnaires to: AFIT/LSC. Wright-Patterson AFB OH 45433-9905.

1. Did this research conuibute to a current research project?

L Yes bNo

2. Do you believe this research topic is significant enough that it would have been researched (orcontracted) by your organization or another agency if AFIT had not researched it?

a. Yes b. No

3. The benefits of.AFIT research can often be expressed by the equivalent value that your agencyreceived by virtue of AFIT performing the research. Please estimate what this research wouldhave cost in terms of.manpower and/or dollars if it had been accomplished. under contract or if ithad been done in-house.

Man Years S

4. Often it is not possible to attach equivalent dollar values to research, although the results ofthe research may, in fact, be important. Whether or not you were able to establish an equivalentvalue for this research (3. above) what is your estimate of its significance?

a. Highly b. Significant c. Slightly d. Of NoSignificant Significant Significance

5. Comments

Name and Grade Organization

Position or Title Address