Regis University

ePublications at Regis University

All Regis University Theses

Spring 2009

Implementing an Sap Transportation Management

System Solution: a Case Study
Debra F. Wycoff
Regis University

Follow this and additional works at: https://epublications.regis.edu/theses

Part of the Computer Sciences Commons

Recommended Citation
Wycoff, Debra F., "Implementing an Sap Transportation Management System Solution: a Case Study" (2009). All Regis University
Theses. 10.
https://epublications.regis.edu/theses/10

This Thesis - Open Access is brought to you for free and open access by ePublications at Regis University. It has been accepted for inclusion in All Regis
University Theses by an authorized administrator of ePublications at Regis University. For more information, please contact [email protected].
 Regis University
College for Professional Studies Graduate Programs
Final Project/Thesis

Disclaimer
Use of the materials available in the Regis University Thesis Collection
(“Collection”) is limited and restricted to those users who agree to comply with
the following terms of use. Regis University reserves the right to deny access to
the Collection to any person who violates these terms of use or who seeks to or
does alter, avoid or supersede the functional conditions, restrictions and
limitations of the Collection.

The site may be used only for lawful purposes. The user is solely responsible for
knowing and adhering to any and all applicable laws, rules, and regulations
relating or pertaining to use of the Collection.

All content in this Collection is owned by and subject to the exclusive control of
Regis University and the authors of the materials. It is available only for research
purposes and may not be used in violation of copyright laws or for unlawful
purposes. The materials may not be downloaded in whole or in part without
permission of the copyright holder or as otherwise authorized in the “fair use”
standards of the U.S. copyright laws and regulations.
 SAP TMS Implementation

Running head: IMPLEMENTING AN SAP TMS SOLUTION

Implementing an SAP Transportation Management System Solution: A

Case Study

Debra Wycoff

Regis University

 SAP TMS Implementation ii

Project Paper Revision History

First Draft Submitted to Advisor, John Holmes April 24, 2009

Revision Submitted to Advisor, John Holmes April 26, 2009

Final Draft Submitted to Advisor, John Holmes May 4, 2009

 SAP TMS Implementation iii

Acknowledgments

Regis University has taught me to think critically and

independently and has reinforced the concept of life-long, self

directed learning. During my studies at Regis, I have had the

privilege of studying with highly qualified members of the

faculty, and I sincerely appreciate the knowledge, dedication

and professionalism of each and every person with whom I have

worked.

John Holmes, Don Ina and Shari Plantz-Masters deserve

special appreciation and acknowledgment. John supported me

through the journey to complete my thesis. He was always

available with a caring attitude and a commitment to see me

through the process, even when he was travelling extensively

with his consulting business. Don encouraged me and guided me

through the daunting task of finishing my thesis and

presentation, always with humor and a positive outlook.

Shari Plantz-Masters has been an inspiration to me during

my enrollment at Regis. She has been a role model and a mentor,

always encouraging me to believe in myself.

The successful completion of my degree would not have been

possible without the incredible support of my family, especially

my husband Tom. He has provided an incredible support system for

me by shouldering more than his share of responsibility within

 SAP TMS Implementation iv

our household to allow me the time to study and continuously

encouraging me to complete my degree

 SAP TMS Implementation v

Executive Summary

System implementations sometimes result in unexpected system

behavior. This paper is a case study focusing on an SAP

transportation management system implementation that resulted in

unexpected system behavior and a different user interface than

the one that had been tested. Through a grounded theory approach

the case study researched specific data gathered from the

project documentation and from interviews with key system

developers and a primary business user. The findings from the

study can be applied to other similar system implementation

projects and also provide some insights related to additional

research that could be expanded.

Please note that the name of the company, the name of the

project and other information related to this system

implementation have been changed to mask the identity of the

consumer goods company being studied.

 SAP TMS Implementation vi

Table of Contents

Project Paper Revision History ii

Acknowledgements iii

Executive Summary v

Table of Contents vi

List of Figures x

CHAPTER ONE: INTRODUCTION 1

Problem to Be Investigated and Goal to Be Achieved 3

Relevance of the Project 3

Barriers and/or Issues 4

Questions to Be Discussed or Answered 5

Scope of Case Study 6

Definition of Terms 12

Chapter Review 14

CHAPTER TWO: REVIEW OF LITERATURE AND RESEARCH 15

Overview of All Literature and Research on the Project 15

Literature and Research Relevant to the Project 16

Ground Theory and Case Study 16

BBC Company Research 22

Overview 23

Organizational Structure 23

Project Methodology 27

 SAP TMS Implementation vii

Change Control Governance Process 27

Distribution Network 28

USEvolve Project 30

SAP AG Company Overview 58

Summary of What is Known and Unknown About the Project

59

Topic

Contribution This Project Will Make to the Field 61

CHAPTER THREE: METHODOLOGY 63

Research Methods to Be Used 63

Life-cycle Models to Be Followed 63

Specific Procedures 64

Preparation Phase 64

Research Phase 66

Research Design 66

Data Collection and Analysis 68

Formats for Presenting Results/Deliverables 72

Review of the Deliverables 74

Resource Requirements 74

Outcomes 74

Chapter Review 76

CHAPTER FOUR: PROJECT HISTORY 77

How the Project Began 77

How the Project Was Managed 77

 SAP TMS Implementation viii

Significant Events/Milestones in the Project 78

Changes to the Project Plan 78

Evaluation of Whether or Not the Project Met Project Goals 79

Discussion of What Went Right and What Went Wrong in the

80

Project

Discussion of Project Variables and Their Impact on the

81

Project

Findings/Analysis Results 81

TMS Help Desk Ticket Log 81

Interviews 89

Summary of Results 97

CHAPTER FIVE: LESSONS LEARNED AND NEXT EVOLUTION OF PROJECT 100

What Was Learned From the Project Experience 100

What You Would Have Done Differently in the Project 101

Discussion of Whether or Not the Project Met Initial

102

Project Expectations

What the Next Stage of Evolution for the Project Would Be

102

If It continued

Conclusions/Recommendations 105

Summary 105

References 107

Appendix A: Terms and Acronyms 110

Appendix B: USEvolve Project Team Management Structure 113

 SAP TMS Implementation ix

Appendix C: Case Study Analysis 118

Appendix D: Interview Notes and Prepared Questions 119

Interview with System Developer 1 (EM DEV1) 119

Interview with System Developer 2 (EM DEV2) 127

Interview with Business User 1 (BusUser1) 131

Prepared Interview Questions (if required) 134

 SAP TMS Implementation x

List of Figures

Figure 1. BBC Company: TMS Functional Architecture Prior

to USEvolve Project . . . . . . . . . . . . . . 7

Figure 2. BBC Company: TMS Functional Architecture After

USEvolve Project . . . . . . . . . . . . . . . 8

Figure 3. Scope: Case Study, BBC Company USEvolve Project 10

Figure 4. Case Study Scope Timeline . . . . . . . . . . . 12

Figure 5. APO Upgrade Timeline . . . . . . . . . . . . . 43

Figure 6. R/3 and APO Upgrades High-Level Timeline . . . 45

Figure 7. BBC Company TMS High-Level Data Flow . . . . . 46

Figure 8. BBC Company Logical Architecture After

Implementation of the APO Upgrade and TMS

Replacement . . . . . . . . . . . . . . . . . . 54

Figure 9. TMS Help Desk Tickets by System . . . . . . . . 82

Figure 10. TMS Help Desk Tickets by Category . . . . . . . 83

Figure 11. Known vs.Unknown Issues Prior to Go-Live . . . 85

 SAP TMS Implementation 1

CHAPTER ONE: INTRODUCTION

BBC Company is a large consumer goods manufacturing company

with headquarters in the United States. During 2007 and 2008 the

company performed a technical upgrade of its SAP enterprise

resource planning (ERP) system globally across its three

business divisions. The enterprise-wide project, named Project

Evolution, was the over-arching project, with three separate

work streams, one for each of its business divisions located in

Canada, the United States and Europe. The U.S. upgrade is the

focus of this study. That work stream was referred to as the

U.S. Evolution Project (USEvolve). In addition to a technical

upgrade of the SAP R/3 and APO modules, the USEvolve project

included an Oracle system upgrade and the replacement of the

legacy transportation management system (TMS) with the SAP

platform which included two new SAP system modules-­

Transportation Planning and Vehicle Scheduling (TPVS) and Event

Manager (EM).

Overall, USEvolve project was successful in that the BBC

Company was able to perform its planning, production and

distribution processes without shutting down its manufacturing

operations when the project was implemented into the production

 SAP TMS Implementation 2

environment although some manual interventions were required.

The functionality and design of the replacement transportation

management system that was deployed into production differed

considerably from the system that had been planned and tested in

the development and testing environments. In particular, the

Event Manager system’s graphic user interface (GUI), known as

the Web Communication Layer (WCL), had a number functional

components and attributes that were significantly different than

the test version and different than the training provided to the

users--both internal users and external users. The production

versions of the electronic data interchange (EDI) transactions

were different than the ones that were tested with

transportation carriers, creating issues and challenges for

them. System performance was extremely slow. There were also a

number of issues related to the functionality in TPVS.

The issues experienced following the deployment of the new

TMS system to the production environment created confusion among

all the users and disruption to their normal, expected business

processes. As a result, a significant amount of additional work

and manual intervention was required by the users and the

technical resources to ensure shipments were not delayed.

During the six-week production support period following the

system deployment, a number of problems were identified and

 SAP TMS Implementation 3

cataloged through the “Help Desk” process. At the end of the

production support phase of the USEvolve project, a significant

number of issues remained. Following the production support

phase, the system maintenance and support was transitioned to

the technical resources and a separate enhancement phase was

launched to solve some of the outstanding issues.

Problem to Be Investigated and Goal to Be Achieved

The TMS system transition from the test environment to the

production environment should have been fairly seamless and

transparent to the users. The purpose of this paper is to

analyze the BBC Company’s TMS replacement project to develop a

better understanding of the problems that occurred during the

deployment of the new transportation management system and

explore what can be learned and applied to future system

implementations.

Relevance of the Project

SAP AG is currently the leading supplier of enterprise

resource planning system and supply chain management system

software globally (Datamonitor, 2008a). At the time, its

transportation management system, especially the Event Manager

module, was a fairly new system that was not yet in wide usage.
 SAP TMS Implementation 4

As such, there was an opportunity to learn much more about this

transportation management system and to apply that knowledge to

other system implementations, upgrades, and enhancements.

Since the system upgrade and TMS replacement project, BBC

Company has merged with another company and has begun plans to

develop an SAP system design to support the new expanded company

structure. The new organization could potentially benefit from

the findings provided by this case study.

BBC Company has conducted benchmarking with other consumer

goods companies in the past. Other organizations considering an

upgrade or replacement of a transportation management system

with the SAP platform could potentially utilize any knowledge

gained from this case study to prevent some of the same issues

that BBC Company experienced.

Barriers and/or Issues

The primary barrier encountered with this case study was

the availability of the technical resources for further, in-

depth exploration or explanations of the causes related to the

problems that occurred during the transition of the TMS

applications from the test environment to the production

environment. The primary technical resource leading the

development of the Event Manager module, a consultant, left BBC

 SAP TMS Implementation 5

Company at the end of the production support phase to work with

a different company on a new project. While he did participate

in an interview, the depth of the information obtained was

limited by the short duration of the interview. Other technical

resources, who were project participants, were largely

unavailable for extensive interviews and explanations. Many of

the resources exited the company after the project. Some were

reassigned to new projects related to the company’s merger. Most

of those who were reassigned were immersed in their new work

responsibilities with limited time to participate in a case

study.

The personal nature of each person’s role and experience

related to the USEvolve and the fact that there were some

challenges associated with the TMS replacement implementation

presented another potential barrier to finding the true root

cause of many of the issues. It was known that this case study

would be influenced to some degree by subjectivity.

Questions to be Discussed or Answered

There were a number of questions to be answered through

this case study in relation to the TMS replacement project. What

caused the dysfunction in the TMS deployment? Why did the TMS

production version differ from the test version and the training
 SAP TMS Implementation 6

provided to the users? Why did it take so long to resolve many

of the issues? Were the issues a result of business requirements

that were either not defined or poorly defined? If there were

business requirements that were defined but were not delivered,

what were the reasons? What can be learned from the issues

encountered with this system implementation that can be applied

to future system implementations to prevent similar problems?

Scope of Case Study

The BBC Company’s USEvolve project included an upgrade of

its SAP legacy modules R/3 ad APO. The project also included

replacing the Manugistics legacy TMS with SAP’s TPVS and EM

modules. While there were some issues associated with the

upgrade as a whole, the focus of this case study was on the

transportation management portion of the system. The author’s

involvement with the project was related to the transportation

management system.

Figure 1 is a high-level representation of the BBC

Company’s functional architecture related to the transportation

management system and SAP prior to the system change.

 SAP TMS Implementation 7

Figure 1. BBC Company: TMS Functional Architecture Prior to USEvolve Project

Source: BBC Company Documents

Figure 2 below incorporates the changes from the USEvolve

project to show the functional architecture of the SAP

applications that replaced the Manugistics TMS and the rate-and­

lane-loader application.
 SAP TMS Implementation 8

Figure 2. BBC Company: TMS Functional Architecture After USEvolve Project

Source: BBC Company Documents

 SAP TMS Implementation 9

While USEvolve included an Oracle system upgrade and the

upgrade of the SAP Business Warehouse (BW) along with additional

reporting capabilities, the case study scope concentrated

specifically upon the transportation management functionality.

Figure 3 depicts the high-level scope related to this case

study.
 SAP TMS Implementation 10

Figure 3. Scope: Case Study, BBC Company USEvolve Project

 SAP TMS Implementation 11

In an effort to narrow the focus of the case study for

manageability, some of the TMS functionality was determined to

be out of scope. The freight rate maintenance functionality was

excluded from the scope of this study even though the rate

master data was a critical TMS system component and the

automated rate loading was problematic during the deployment of

the system. The Business Warehouse and reporting functionality

was also considered out of scope.

Reverse logistics, shipments of returnable dunnage and

reusable packaging materials, were another component that was

considered beyond the scope of this study because the system

design was significantly different than the design for outbound

finished goods shipments. The design decision for reverse

logistics shipments was required to support the legacy front-end

Web tool that was utilized by BBC Company’s customers.

Other system modules and applications that were excluded

from the scope of this case study included the interfaces,

middleware, the yard management system (YMS), and the third-

party payment process. Some of the issues related to EDI

transactions were reviewed in this study, although not at a

technical, in-depth level. The EDI component of this project

could have been the subject of a separate case study.

 SAP TMS Implementation 12

Time was also a defining factor related to the case study

scope. This case study was limited to the issues reported from

the go-live date, March 3, 2008, through the six-week production

support phase and through the definition of the TMS enhancement

phase.

Figure 4. Case Study Scope Timeline

Definition of Terms

Several key terms have been used throughout this paper are

defined below. Appendix A contains a list of additional terms

used in this paper.

Term Definition
SAP AG software company that produces
enterprise resource planning
and supply chain planning
software, e.g., ECC(R/3);
SCM(APO); SCEM(EM); WCL
TMS (in context of this paper) transportation management
system; system used to plan and
manage the distribution of
finished goods to wholesale
customers and the return of
reusable packaging materials
 SAP TMS Implementation 13
and dunnage, the items used to
protect the finished goods
during shipment.
R/3 & ECC Both terms refer to the SAP
enterprise resource planning
(ERP) module that is used for
financial management and
business execution. ECC is the
upgraded name for R/3.
SCM & APO Both terms refer to the SAP
planning module that is used
for planning production and
transportation carrier
optimization. SCM is the
upgraded name for APO.
TPVS SAP Transportation Planning and
Vehicle Scheduling application;
part of the SCM/APO planning
module
SCEM SAP Supply Chain Event
Management; used
interchangeable with the term
EM and Event Manager
EM Event Manager; refers to SAP’s
SCEM
Event Manager refers to SAP’s SCEM
WCL SAP Web Communications Layer;
refers to the Web interface
that sits on the SAP Event
Manager
SAP Enterprise Portal front end of the SAP NetWeaver
platform
SAP NetWeaver serves as an integration layer
that can host business
applications

Throughout this paper, several terms have been used

interchangeably:

• R/3 and ECC refer to the execution module of the SAP

architecture

• APO and SCM refer to the planning module of the SAP

architecture
 SAP TMS Implementation 14

• SCEM and EM both refer to the Event Manager system

Chapter Review

The purpose of this paper was to analyze the issues

that were encountered with the new transportation

management system that was implemented by the BBC Company

in March 2008, to develop a better understanding of the

causes associated with those issues, and to determine if

there were findings that could be applied to future BBC

Company projects or to system implementations in general.

Although USEvolve included upgrades associated with

multiple SAP modules, the scope of this paper was limited

to the replacement transportation management system that

included TPVS, EM and its Web Communications Layer (WCL).

Issues related to the EDI transactions were included in the

analysis as they related to the transportation carriers but

were not analyzed at a technical level. Because the system

design for reverse logistics shipments was significantly

different than the system design for finished goods

shipments, reverse logistics were not included in this

study.
 SAP TMS Implementation 15

CHAPTER TWO: REVIEW OF LITERATURE AND RESEARCH

Overview of All Literature and Research on the Project

The research in conjunction with this case study encompassed

many different forms. Formal literature review was conducted

related to the subject of qualitative analysis, specifically

focused on the grounded theory approach to case studies. Other

literature reviews included life-cycle methodologies such as the

waterfall and iterative methodologies, project management, SAP

AG and its systems, and the BBC Company.

The BBC Company’s intranet provided much of the information

related to the company’s objectives, organizational structure,

program and project management processes, and details related to

the USEvolve project. Research related to the SAP AG and its

system components included the company’s Website, books written

about the company’s system, presentations made by SAP to the BBC

Company, a Webinar, system documentation, and a training class

related to the TPVS functionality. Interviews with system

developers and a key business user associated with USEvolve were

also utilized. Knowledge developed as a result of the Regis

MSCIT program and personal experience from USEvolve and other

previous transportation management system implementations was

 SAP TMS Implementation 16
also applied to this case study. The Project Management

Institute’s third edition of the PMBOK Guide was consulted for

the project planning and the project management of this case

study. Research related to the American Psychological

Association’s (APA) writing style guidelines was also conducted.

It included a workshop conducted by Regis University and

consultation of the Publication Manual of the American

Psychological Association.

Literature and Research Relevant to the Project

Grounded Theory and Case Study

Grounded theory is a qualitative case study research method

originally developed by two sociologists, Barney Glaser and

Anselm Strauss, and published in 1967 in their book, The

Discovery of Grounded Theory (Traverse, 2001). According to

Myers (1997, Grounded theory section, para. 1), “Grounded theory

is a research method that seeks to develop theory that is

grounded in data systematically gathered and analyzed.” It is

characterized by an inductive, iterative approach that Glaser

and Strauss termed the “constant comparative method” (Gorman &

Clayton, 2005).

Qualitative research evolved from the social sciences and

is research related to social and cultural phenomena in

comparison to quantitative research which evolved from the

 SAP TMS Implementation 17

natural sciences (Myers, 1997). Quantitative researchers use

numeric methods and generally use deductive reasoning, meaning

the research begins based on a general hypothesis that must be

proven through the research details. Qualitative research

generally reviews specific data to gain understanding of the

relationships and generalizes from the details (Scholz & Tietje,

2002). Qualitative research can use a number of different

methods for conducting research related to a phenomenon. Myers

(1997) categorizes the qualitative methods as 1) action

research, 2) case study, 3) ethnography and 4) grounded theory.

The method helps to determine the research design and the way

the data is gathered (Myers). He suggests that grounded theory

is a useful method of research, especially in information

systems, because it is “extremely useful in developing context-

based, process-oriented descriptions and explanations of

phenomenon” (Grounded theory section, para. 2).

White (2000, p. 110) explained grounded theory in the

following manner, “Qualitative research . . . should not simply

describe a situation, but look for explanations and analyses,

and at all levels a search should be made for generalizations or

theories to explain and understand the topic being investigated.

These generalizations or theories should, therefore, emerge or

be ‘grounded’ in the empirical research. . . . Implicit in the

 SAP TMS Implementation 18

process is that the researcher constantly looks back and

reflects, and as a result refines the theory against new

research findings.”

According to Yin (2003b, p. 1), “case studies are the

preferred strategy when ‘how’ or ‘why’ questions are being

posed, when the investigator has little control over events, and

when the focus is on a contemporary phenomenon within some real-

life context.” He stressed the importance of developing

“preliminary concepts” or theories at the beginning of the

research to help define the “unit of analysis,” and the relevant

variables to determine the data to be collected (p. 3).

Yin (2003a, p. 5) points out that “the term theory covers

more than causal theories. Rather, theory means the design of

research steps according to some relationship to the literature,

policy issues, or other substantive source.”

Grounded theory is characterized by specific processes that

differentiate it from other research methods. Bryman and Bell

(2003) outline the processes utilized in grounded theory

research beginning with developing the research question as the

first step, followed by theoretical sampling, data collection,

and data coding. This in itself is not particularly different

from other research methods; however, the iterative nature of

this method does differentiate it. Different processes can be

 SAP TMS Implementation 19

conducted in parallel with other processes, processes can move

constantly forward and backward in the four steps outlined above

conducting a constant comparison of indicators and concepts.

The comparison results in the generation of categories (Bryman &

Bell).

Bryman and Bell described the outcomes in grounded theory

as concepts, categories, and hypotheses. Concepts are “labels

given to discrete phenomena” and are the result of an open

coding process (p. 429). A category is a higher level of

abstraction than a concept, “a concept that has been elaborated

so that it is regarded as representing real-world phenomena”

(p. 430). They define hypotheses as “initial hunches about

relationships between concepts” (p. 431). Other coding methods

called axial coding and selective coding are also utilized in

grounded theory (p. 429).

Pandit (1996, Data analysis phase section, para. 5)

describes the coding processes as follows, “Whereas open coding

fractures the data into concepts and categories, axial coding

puts those data back together in new ways by making connections

between a category and its sub-categories.” He said, “Selective

coding involves the integration of the categories that have been

developed to form the initial theoretical framework” (para. 6).

 SAP TMS Implementation 20

Qualitative research has been criticized as being too

subjective and lacking rigor. Because it often involves a single

phenomenon or a small number of cases, some believe it does not

provide reliability nor allow for generalization based on the

findings ((University Of Texas, 2008). Stake (1995), in his

book, The Art of Case Study Research, acknowledges that

subjectivity does influence qualitative research:

There is no particular moment when data

gathering begins. It begins before there is

commitment to do the study: backgrounding,

acquaintance with other cases, first

impressions. A considerable proportion of

all data is impressionistic, picked up

informally as the researcher first becomes

acquainted with the case. Many of these

early impressions will later be refined or

replaced, but the pool of data includes the

earliest of observations. (p. 49)

Research design is a critical component in overcoming the

criticism. The research design should incorporate the research

objectives, the methodology to be used in the research, the data

 SAP TMS Implementation 21

collection and data analysis to be used and how the data will be

managed (White, 2000).

White (2000) indicates that planning in the design phase is

critical to establish validity and reliability. Validity is

related to whether the research design fully supports the

research questions or objectives and reliability is related to

consistency in the research and whether another investigator

would be able to develop similar findings based upon the

research design.

Triangulation was reported by Yin (2003b) to be an

important concept related to validity and reliability. He

suggested that using multiple sources of data or using more than

one observer or interviewer in a research project were methods

that could be incorporated to triangulate or validate the data

while providing greater objectivity.

Yin (2003b) outlined the following as the six most commonly

used sources of evidence in qualitative research: 1)

documentation, 2) archival records, 3) interviews, 4) direct

observations, 5) participant-observation, and 6) physical

artifacts. He pointed out that using more than one source of

evidence provides a form of triangulation.

 SAP TMS Implementation 22

BBC Company Research

An overview of the company, its business and IT

organizational structures and project methodology will be

reviewed to provide some context for this case study. Much of

the information related to the BBC Company was obtained from the

company’s internal documentation, most of it found on the

internal portal. Additional research included Datamonitor

company and industry profiles and a case study published in a

credible information systems journal related to the BBC

Company’s portfolio project management structure and process.

The case study referenced above was co-authored by two BBC

Company employees, an IT strategy consultant, and the head of an

information technology department at a reputable university. It

outlines BBC Company’s project portfolio management structure

and methodology. It also includes a high-level analysis related

to the BBC Company’s maturity model.

Information from these sources was utilized but the

specific details related to the source are not shown in the

reference section of this paper in order to maintain the

anonymity of the BBC Company.

 SAP TMS Implementation 23

Overview

Datamonitor (2008b) reported that BBC Company ranked in the

top ten among consumer goods manufacturers in its industry

segment with annual revenue in 2007 of $6.2 billion. BBC Company

employed nearly 10,000 people in its three divisions located in

the United Kingdom, Canada and the United States. Its

headquarters are located in the United States.

BBC Company was considered strong financially and

competitively from both a market position and a brand portfolio

position (Datamonitor, 2008b). Mergers and acquisitions have

been prevalent in the industry and the trend toward

consolidation is expected to continue (Datamonitor).

Organizational Structure

The BBC Company was structured as a global enterprise led by

the global chief executive officer (CEO). Reporting to the

global CEO were the CEOs from each division and the global chief

information officer (CIO). A global program management office

(GPMO) reviewed all of the organization’s IT and business

projects to ensure there was alignment with the company’s

strategic goals, to provide standardized processes across the

 SAP TMS Implementation 24

organization, and to coordinate projects to capture synergies.

The GPMO reported to the global CIO.

Each division was organized with a CIO, chief strategy

officer (CSO) and a chief financial officer (CFO) reporting to

its CEO. Each of the three areas had its own program management

office (PMO) respectively — information technology (IT) PMO,

product PMO, and finance PMO. The three different functional

groups formed a divisional PMO. Across the three divisions, each

functional area acted as a center of excellence (COE) providing

a global methodology for its area. For example, the global IT

methodology provided a framework for all IT projects. It defined

the organizational roles and provided standardized templates

that could be adapted to each project. Each division had an

executive steering committee comprised of the “chief” level

leaders across its division. The role of the steering committee

was to review and prioritize IT projects. It was also

responsible for approving funding for IT expenditures and

resolving conflicts that were escalated to that level.

All projects throughout the enterprise followed a five-step

stage-gate waterfall methodology. Each stage was required to be

completed, and then reviewed and approved by the appropriate

management before the project could move to the next phase. The

involvement of the financial PMO varied depending upon the

 SAP TMS Implementation 25

amount of the expenditure associated with the project. All

projects that exceeded $1 million are considered capital

projects and required a more rigorous financial methodology.

Metrics related to the project’s schedule, cost, scope and risk

were utilized throughout the project and were published using a

dashboard to visually depict the status of a project at any

time. At the end of each project an evaluation was conducted

based on the metrics established early in the project. It was

rated as having been delivered on target, above target or below

target. Project methodology will be discussed in further detail

later in this chapter.

A project steering committee, made up of the appropriate

business and IT leadership, provided guidance to the project

team and resolved issues associated with that project. Issues

that had broader company implications were escalated to the

executive steering committee.

Projects were generally initiated by a business unit through

its IT business partner. The business partner’s role was a

position that was established as a liaison between the IT

organization and the business. Each business partner was

knowledgeable about an area of the business and its associated

technology. The business partner reviewed business requests,

established the business requirements and developed a business

 SAP TMS Implementation 26

case. The business case estimated the timeline and cost

associated with the planning and analysis phase of the project

as well as the resources required. The business case was

submitted to the technical review board for an architectural

review and for resource planning. Once the business case was

reviewed and accepted by the technical review board, it was

submitted to the operations committee, composed of the CIO’s

direct reports, for approval. Once it was approved by the

operations committee, the business case was then reviewed and

prioritized by the executive steering committee. A global

architectural review board reviewed all business cases approved

by the executive steering committees to ensure they met the

enterprise architectural standards and fit any longer-range

planned changes.

The IT organization was characterized primarily as a matrix

organization. Some activities such as SAP configuration and

architecture were centralized; however, most of the IT

organization had dual accountability to both IT and a business

unit. BBC Company employed a limited number of people in the

leadership area of the IT organization. Through a strategic

partnership agreement with EDS, most of the IT services for

projects and day-to-day IT support requirements for BBC Company

were provided through the EDS organization. Other IT

 SAP TMS Implementation 27

consultants were also hired as necessary to fulfill a specific

technical need.

Project Methodology

As discussed earlier in this paper, all BBC Company projects

followed a 5-step stage-gate waterfall method in which one stage

was required to be completed and approved prior to moving to the

next stage. The project life cycle included all project

management activities and deliverables. Projects involving

system implementations also included and followed a similar

traditional waterfall systems development life cycle (SDLC) with

the following sequence of activities: (a) planning, (b)

analysis, (c) design, (d) implementation, and (e) support

(Whitten 1998). The support or maintenance phase included

continuous improvements which eventually lead to the process

starting again. In general, BBC Company maintained an n-1

strategy related to the versioning of its systems.

Change Control Governance Process

Changes to the BBC Company’s systems, whether in the

production environment or in association with a project, were

required to be processed using the change control governance

process. Change requests in general were tracked using Peregrine

 SAP TMS Implementation 28

software. The Change Control Board met regularly twice a week to

review change requests or as needed if emergency situations

arose. Any change request that involved a project scope change

had to be approved by the steering committee.

Most changes were required to be made sequentially, first in

the DEV environment and then the QA environment. If testing was

successful, the change was moved into the production system.

Some changes were made directly in the production system. For

SAP changes, called transports, the changes were managed through

a toolkit called the Transport Management System (SAP TMS) — not

to be confused with the transportation management system

implementation that is the subject this case study. “A

transport request is a container of objects that contain objects

(ABAP programs, screens, menus, texts, messages, table

definitions, or structures) or configuration data (Sens, 2008,

4.5.1 Transport activities section, para. 2).” The system tracks

changes to objects and configuration so the change can be

managed and moved to the next system in the SAP landscape

(Sens).

Distribution Network

The replacement TMS, which is the focus of this case study,

was to support the U.S. Division’s distribution requirements, so

 SAP TMS Implementation 29

it is important to understand the BBC Company’s distribution

network.

Two manufacturing facilities, one located in the eastern

portion of the U.S. and one located in the western area of the

U.S., produced and packaged finished goods for distribution

within the Unites States and to a few export locations including

the Puerto Rico and Caribbean area.

There were approximately 600 wholesale customers that

received products either directly from a manufacturing plant or

indirectly through a distribution center depending upon the

volume and the mix of products that were ordered. BBC Company

used a segmentation model to determine, by customer, where each

product would be sourced and the mode that would be used to ship

that product. Customers submitted a weekly order for products to

be shipped the following week from a plant or a distribution

center.

Shipments to customers within the U.S. were managed by the

BBC Company, and could be shipped to a customer via rail, truck

or intermodal modes depending upon the location. Export

customers had different shipping terms and the product was

shipped via ocean. Export customers were out of scope for this

study.
 SAP TMS Implementation 30

A few customers received shipments via a cross-dock. In this

case the products were shipped via rail to a facility that

unloaded the railcar and transferred the product immediately to

trucks for delivery. This shipping method provided cost savings

associated with the rail mode to customers that did not have

rail receiving capabilities. Multiple stop shipments were

sometimes sent to customers that had less-than-truckload (LTL)

order quantities.

All of the transportation lanes from an origin shipping

location to a customer destination were contracted with

transportation carriers. Specialized transportation equipment

was required for certain products to protect the product in

transit. Lane assignments to carriers included the types of

equipment that was required. There was more than one carrier and

more than one equipment type assigned to a transportation lane.

USEvolve Project

Documentation related to the USEvolve project was stored on

the project’s official SharePoint site and was utilized as the

primary source of information regarding the overall project and

the replacement of the TMS specifically. Additional information

related to the project was derived from emails, meetings,

 SAP TMS Implementation 31

conversations with various resources, and interviews with system

developers and one of the primary business users.

The following section provides high-level background

information related to the USEvolve project to provide context

for the case study. The project was much more complex than can

be covered in this paper.

Project purpose and background.

Project Evolution was initiated to upgrade the BBC Company’s

SAP systems in each of the organization’s three business

divisions to improve overall functionality and to ensure the

version being utilized was supported by SAP. The U.S. Division’s

project, USEvolve, also included the replacement of the legacy

transportation management system with the SAP platform. The

legacy TMS consisted of an older, unsupported version of

Manugistics NetWorks Transport and NetWorks Carrier.

At the time USEvolve was initiated, APO had been in place

for over five years, was four releases behind the current

version, and the functionality was no longer adequately

supporting the business in the areas of demand planning and

supply planning. The business had begun to use solutions outside

the SAP system. Manugistics was the legacy TMS system in place,
 SAP TMS Implementation 32

and the version had not been supported for three years. The

total cost of ownership of this application was high.

The upgrade of R/3 4.6c to ECC 6.0 was organized as a

separate work stream from the APO upgrade and TMS replacement

components of the project. The data warehousing and reporting

aspects of the project were also organized as separate work

streams. For the purposes of this case study, USEvolve focused

primarily on the TMS replacement but also included some

references to the APO upgrade portion of the project to provide

some background and additional context related to the overall

scope.

The overall project, Project Evolution, aligned with and

supported the corporate goals of improving profitability

throughout the supply chain and by helping to better position

BBC Company for a potential merger by providing a viable,

scalable system infrastructure. The BBC Company leveraged its

project synergies by combining the regression testing for APO

and R/3 and coordinating a single go-live among the divisions.

The combined effort resulted in overall dollar savings, reduced

the total amount of time required for the project, and set the

infrastructure for seamless integration between systems.

Savings resulted from having one project manager, one steering

committee and one go-live effort. While there were efficiencies

 SAP TMS Implementation 33

gained overall, the APO upgrade and, consequently, the TMS

replacement project had to be extended and incurred some

additional costs because some of the same resources were

required for the R/3 project work stream. The coordination

effort began after the U.S. division’s project had begun.

Costs and benefits.

The total cost of the APO upgrade and TMS replacement

portion of the USEvolve capital expense project was $4.2

million, approximately $1 million more than the original

estimate. Most of the additional cost was labor cost incurred

for project resources. Throughout the project, the scope was not

expanded; however, the schedule was extended first to coordinate

the go-live date for all of the work streams and later to allow

for additional testing and defect resolution. The initially

planned February, 2008 go-live date was later extended by two

weeks.

Benefits identified with this project included net

operational savings from the retirement of the Manugistics TMS

system, a reduction in the number of servers required, and a

reduction in the number of Oracle instances required. The

estimated payback period was 10-11 years.

 SAP TMS Implementation 34

Other opportunities from the project included reducing the

architectural complexity, eliminating interfaces between

Manugistics to and from each of the SAP modules, reducing the

number of vendors, and consolidating the licensing fees and

system maintenance with one preferred vendor—SAP.

TMS alternatives.

According to the USEvolve business case, four alternatives

were considered related to the TMS system:

1. upgrade Manugistics TMS to the current software version

2. conduct an request for information (RFI) or a request for

a proposal (RFP) for a different replacement TMS software

package

3. continue with the current Manugistics TMS software package

and move to a "life-support" system, such as the

PeopleSoft application

4. replace the Manugistics TMS system with APO functionality

The IT organization’s goals included reducing the number of

different applications supported and moving to a simpler

architecture. Its recommendation was to replace the Manugistics

TMS with the SAP APO functionality. That solution was adopted

and implemented. Timing was a critical success factor and was

 SAP TMS Implementation 35

identified as a risk associated with the selected TMS solution.

The solution needed to be implemented in the first quarter of

2008 to avoid having to adopt the “life-support” solution. That

option would have resulted in significant custom coding for new

interfaces from Manugistics to SCM and ECC, and the project’s

net operational benefits would not have been fully realized. To

meet the timeline, the TMS solution scope was limited to a like­

for-like functionality. No additional functionality was allowed

to be implemented even if it were available.

A request for proposal (RFP) process was ruled out due to

the time constraints associated with the project and the timing

of the upcoming busy season in relationship to implementing a

new TMS solution.

New technologies associated with TMS solution.

The new TMS solution utilized three new SAP system

applications--Event Manager, WCL and the enterprise portal (EP).

All were new technologies to the organization that required

technical resources with specialized skills and knowledge. The

technical skills required included SAP Basis, SAP ABAP and Java

programming.

SCEM 5.0 (EM) was the event management functionality

contained within the SCM 5.0 software. Event manager could have
 SAP TMS Implementation 36

been configured in many different ways and could have been used

for many different purposes. It is designed to provide

visibility to a supply chain process, usually with an

organization’s trading partners, that requires monitoring by

measuring a sequence of expected events against the actual event

status and providing defined alert notifications if the actual

event is not reported or an unexpected event occurs, thus

allowing for management by exception. The information related

to the planned and actual status, called an event handler, is

interfaced to the BW repository for reporting and performance

measurement (SAG AG, 2005).

BBC Company implemented EM as a communication tool to

monitor the transportation process, tracking the status of a

shipment from the time it was created until it was delivered to

the customer. Transportation carriers, through the WCL or EDI

transactions, received a shipment tender that provided the

expected events such as when the shipment was expected to be

loaded and when the shipment was expected to arrive at the

destination. Other business rules or contractual service

standards defined some of the other expected events. For

instance, an acknowledgment from the carrier either accepting or

declining the tender was expected within a defined time period.

 SAP TMS Implementation 37

When an event did not occur, an alert was sent to the

appropriate people.

SAP EM had standard content that was configurable for

customized events, statuses, and business rules. It interfaced

to ECC and to SAP NetWeaver BI, the business intelligence

reporting application. WCL was the user interface that provided

visibility to a shipment’s status for both carriers and internal

transportation planners (SAG AG, 2005). The version implemented

by BBC Company was not a NetWeaver application, but a one-off

SAP application utilizing Java 2 Enterprise Edition (J2EE) that

only worked with SAP Event Manager. According to the SAP

documentation for the configuring the WCL application, “It is

based on two development components: program code (Java

classes) and user interface (JSP pages)” SAP AG (2008, p. 6).

The enterprise portal was used as an authorization pass

through for both the Event Manager and the business warehouse

(BW) for user access. The portal also utilized Active Directory

(AD) to authenticate users for single sign-on (SSO). An overview

of the transportation processes will be covered later in this

chapter.

Impact to the organization.

 SAP TMS Implementation 38

The departments that were primarily impacted by the USEvolve

project included Supply Chain Planning, Customer Service and

Logistics/Transportation. Enhanced demand planning capabilities

to support the high-volume season planning requirements were to

be delivered to the Supply Chain Planning department via the APO

upgrade. Their key work processes had been addressed, but the

impact to this group was limited. The TMS solution required a

conversion of all transportation processes from the Manugistics

solution to the SAP TVPS and SAP EM TMS solution. Transportation

processes identified included the automated assignment of

carriers to shipments, tendering and communication of shipment

information to carriers, receiving shipment acknowledgements and

status updates from carriers, planning multi-stop shipments,

handling cross-dock shipments and communicating with the third-

party payment (3PP) vendor. The 3PP process is handled in the

ECC system, so it is out of scope for this case study.

According to the project documents, USEvolve required work

process analysis, process re-designs, integration activities,

system configuration and technical changes to support the work

processes in the new version.

Transportation planners, the primary TMS internal business

users, required training in the new work processes associated

with using TPVS to assign carriers and equipment to planned

shipments, to make carrier and equipment changes to shipments in

 SAP TMS Implementation 39
both TPVS and ECC prior to the actual loading and departure of

the shipment, and to monitor shipment status in TPVS and EM.

Other BBC internal users from the customer service department

and the manufacturing scheduling department also required

training on new work processes related to creating, changing and

deleting shipments.

Transportation carriers, the primary external TMS users,

required training too. Carriers either exchanged information

electronically via EDI or through the Web interface. Those

carriers that utilized the Web interface required training to

access the SAP portal and to use the WCL to accept or reject

their shipment tenders and to submit shipment status updates

such as “arrived at destination” notifications. Minimal changes

were made to the EDI specifications related to the new system.

Carriers that utilized EDI were required to make the changes in

their systems and test the transactions prior to the planned go-

live date.

USEvolve project organization structure.

Members of the USEvolve management team responsible for the

APO upgrade and TMS replacement included the following roles:

• Business Partner Owner

• IT Solution Delivery Lead

• Project Sponsor
 SAP TMS Implementation 40

• Business Partner

• IT Lead

• Project Manager

• Lead Architect

Detailed descriptions of the responsibilities associated with

these roles can be found in Appendix B. Because the project

crossed the company divisions, in some instances, such as the

project manager role, the same person fulfilled the role for the

larger project scope.

The USEvolve steering team was comprised of the vice

president of operations, general managers from each

manufacturing facility, the business partner owner, the IT

solution delivery lead, the project sponsor, the director of

logistics (TMS system owner), the APO IT lead, and the R/3 IT

lead.

The APO IT Lead was responsible for the entire APO solution,

which also included the replacement TMS. Technical IT resources

made up that team. Initially, there were two developers assigned

to configuring the Event Manager and WCL. One, known as EM

Dev1, was a BBC Company technical resource. The other, EM Dev2,

was a consultant hired for this role. EM Dev1 had additional

responsibilities related to the upgrade. Coding changes were

being made to the Load Builder application to remove custom

 SAP TMS Implementation 41

coding for functionality that had become available in APO. The

Load Builder IT Lead (LB 1) was a BBC Company employee. There

were two technical resources assigned to the Load Builder work.

One (LB Dev1) was an EDS production support resource and the

other was a consultant (LB Sup1) from iLog, the LB supplier.

At different times during the project, especially pre-go­

live and post-go-live, additional resources were hired or

assigned to the project. Other technical support teams including

Basis, ABAP, Security, Testing, Change Management, and Training

provided resources as required.

On the business side, subject matter experts (SME)

representing different process areas including demand planning,

supply planning, production planning and detailed scheduling and

transportation participated in the project. For most of them,

the role primarily involved user acceptance testing. The

transportation representative had a larger role to assist

defining the business requirements and ensuring the technical

solution met the business needs. In September 2007, the

transportation business representative left BBC Company and

another resource was assigned. As the project progressed, more

of the business users were involved in reviewing the design,

assisting with transportation master data setup, and testing.

Training classes for the external transportation carriers were

 SAP TMS Implementation 42

conducted by a few of the business users. Classes to train

internal business users were also taught by business

representatives from the Logistics department. There were

approximately 100 external transportation carrier users that

were trained initially. The business users were primarily from

the Logistics department; however, users from the other APO

business processes were also trained in the new TMS

functionality.

Project schedule.

The initial timeline for the USEvolve project was planned

as a seven-month project beginning in February 2007, placing the

go-live date in late September. See Figure 5 below.

 SAP TMS Implementation 43

APO upgrade timeline

Jan Feb Mar Apr May Jun July Aug Sept Oct Nov Dec

Phase I

Feasibility

Today Scope, TMS timing

Requirements Development
Functional & Technical design complete
To be design
Finalized scope for phase I

Implementation

IT build

Testing

Training
Go Live

Change Management

Phase II

4
Figure 5. APO Upgrade Timeline

Source: BBC Company Documents

This plan coincided with the BBC Company’s high-volume

season which precluded the required level of business user

involvement in the project. As a result, the project go-live

date was extended until mid-February, 2008. It was determined

that the project either had to be implemented by the third week

in March 2008 or that it would have to be postponed until the

end of the peak season, sometime after September.

The company’s Program Management Office recommended

combining R/3 and APO upgrade project management activities

within the umbrella project, Project Evolution, in order to

create synergies and congruity across the organization while

 SAP TMS Implementation 44

reducing the overall project costs. Subsequently, in May 2007, a

single project manager was assigned to ensure consistency

throughout the enterprise and to leverage synergies such as

combining the regression testing, the go-live activities, and

the production support following the cutover. As a result, the

project was managed as a program and the U.S. Division funded

its portion of the overall project. Each division still had its

own team resources and managed its overall local system

landscape. USEvolve also had a separate project plan and project

team with technical resources to support the U.S. Division’s

specific APO and TMS requirements.

 SAP TMS Implementation 45

Following is the planned schedule for the overall project

that was published in October 2007 (Figure 6).

R/3 and APO Upgrades High-Level Timeline

2007 TODAY 2008
May June July Aug Sept Oct Nov Dec Jan Feb Mar
Feasibility

Development

Implementation

R/ 3 Cycle R/ 3 Cycle 2 R/ 3 &

1 Testing Testing R/ 3 &APO APO
Cycle 3 Cycle 4
APO Cycle 1 APO Cycle 2 Testing Testing
Testing Testing

SAP
Max R/ 3 End User Training
R/3 APO Checkpoint Attn. Oracle
System Upgrade
Review Go / No-Go
R/3 Implementation
Stage Gate Checkpoints

APO Development APO Implementation Go-Live

Stage Gate Stage Gate
R/ 3 & R/ 3 & R/ 3 &
APO APO APO
Mock Mock Mock Production
Cutover Cutover Cutover
1 Support
2 3

Figure 6. R/3 and APO Upgrades High-Level Timeline

Source: BBC Company Documents

The development stage in this timeline overlapped with

the feasibility and implementation stages, which was not

consistent with the project methodology. The overlap was

probably created as a result of combining the upgrade efforts

for the two modules across the organization.

In January 2008, business users from all of the

functional areas raised concerns regarding the limited amount

of testing that had been had been successfully completed.

Issues with the Load Builder functionality had delayed end-to­

 SAP TMS Implementation 46

end testing, and TMS processes were dependent upon the Load

Builder in order test. TMS users were extremely uncomfortable

with the new system. The project was extended approximately

two weeks with the new go-live date of March 3, 2008.

TMS solution overview.

This section will cover some high-level information

related to the TMS solution including a description of the

weekly transportation process from the planning stage through

the execution phase and finally the reporting phase. Figure 7

depicts the flow of the data.

BBC Company: TMS High-level Data Flow

Planning Execution Reporting

Rate
Maintenance
Actual Actual
Shipments Shipments
ECC 6.0 Existing
OMS Sales Order Rates
(R/3) Reporting
Rate Data
Validation

Sales Create Manual Shipment/ IW

Order Delete Shipment/ External
Modify Weight/DateCarrier 3PP Actual
Existing
Tendered System Shipments BO Reporting
Load Builder / iLog Shipments Data
Shipment
New Status
Reporting Updates
Lane Planned Shipments Data
Sales Order
Maintenance
Internal Users
TPVS

SCM 5.0 Shipment Changes

Add/Chg/Del: YMS
Planned Shipment, (APO)
Lane, TSP, MoT, Shipment Status Updates
New Reporting Data
BW
(Historical Reporting)
Accept/ Tenders
Reject & Shipment External
Statuses Changes
EDI Tenders VAN/EDI Transportation
Carrier System
Internal Users
Web Accept/ Yard Reports
Tenders Reject &
Accept/ Event Manager Statuses
Reject
Email
& Statuses
Email
WCL
Tenders

Accept/Reject
& Statuses

Transportation
Carrier Users

Figure 7. BBC Company TMS High-Level Data Flow

 SAP TMS Implementation 47

Weekly Planning Process: Each week wholesale customers

submit their orders on Monday for products to be shipped the

following week. Tuesday, the weekly planning process is

initiated. Upstream processes from the transportation planning

activities follow a planned sequence beginning with the demand

planning (DP) process followed by the supply network planning

(SNP) process and the production planning and detailed

scheduling (PPDS) process. The result is passed to TPVS and

the Load Builder in a shippable subset of the customer’s

order. Load builder performs a shipment optimization process

for each shipping origin. A shipping origin can include a

manufacturing plant, a distribution center or a contract

manufacturing location. It uses the transportation lane master

data in TPVS to determine the appropriate transportation mode

and equipment to be assigned based on the product inventory

availability and the production schedule, then builds planned

shipments that have been optimized for the best solution.

Different parameters can be applied to the optimization to

test different scenarios.Once the solution is released,

planned shipments are available in TPVS.

Transportation planners then perform a carrier

optimization process. If the transportation lane data is set up

 SAP TMS Implementation 48

correctly with the desired transportation service provider (TSP)

and means of transport (MoT), the results of the carrier

optimization require very little, if any, manual adjustment.

Once the transportation planner is satisfied with the results of

the carrier assignments, the planned shipments are released in

TPVS. The release triggers the tendering process to the

transportation service providers and the tendered shipments are

interfaced to the Event Manager and the WCL in a “new tender”

status. The shipment information along with the scheduled ship

date is interfaced back to the order management system as

information for the customer.

Transportation service providers who are configured to

receive EDI transactions receive an EDI 204 transaction for each

shipment. All carriers receive an email notification for each

tender. Transportation service providers that are not EDI

enabled can access their shipment tenders through the WCL. They

can accept or decline a shipment tender using the WCL

functionality. EDI carriers then return an EDI 990 transaction

either accepting or rejecting the shipment tender. The shipment

status is updated in the Event Manager and interfaced to WCL,

TPVS and ECC with the “accepted” or “rejected” status.

The WCL user interface provides two different screen

options called visibilities for transportation service

 SAP TMS Implementation 49

providers. One is titled the Planned Shipment Visibility and the

other is the Transportation Visibility. Shipments that are

planned in TPVS but have not yet been published to ECC, reside

in the Planned Shipment Visibility. Once shipments are published

from TPVS to ECC, they move to the Transportation Visibility.

TPVS owns the document until it is published. Once the

publishing process occurs, the shipment document is transferred

to ECC and ECC becomes the document owner. When the shipment is

published, a delivery document is created for the shipment. In

some instances, there is more than one delivery associated with

a shipment. Shipments with multiple stops have multiple

deliveries associated with a single shipment. The shipment and

information related to the products on a shipment and the status

of that shipment should be the same. Any changes made to the

shipment in ECC should interface back to TPVS, Event Manager and

the WCL on a real-time basis.

Changes to a shipment may be made prior the loading and

departure of a shipment. The change may be made in TPVS until

the shipment is published. If it has been published, the change

must be made in ECC. TPVS provides a simpler method for changes.

Changes to the product on a shipment or the date of a shipment

may be made by customer service or the facility where the

shipment is sourced. Transportation planners may adjust the

 SAP TMS Implementation 50

carrier or the vehicle resource, which is an equipment type, as

necessary. In some cases, a shipment may be deleted.

Each change should trigger an email notification to the

transportation service provider. EDI carriers will receive an

EDI 204 transaction with the appropriate change information.

Event Manager and WCL are also updated with the changes.

Weekly Execution Process: Customer orders placed the prior

week are scheduled to ship the current week. Transportation

service providers are responsible to provide the appropriate

equipment for the shipment at the loading facility location on

the scheduled shipment date. Some locations have a yard

management system. Carriers check in their equipment for the

scheduled shipment. A report related to the status of a

carrier’s equipment inventory on the property is emailed to the

carrier every two hours.

When the equipment is at the loading dock, the status on

the shipment is changed by a warehouse user to indicate it is

loading. When the loading process is completed, the warehouse

user performs a post goods issue (PGI) transaction in ECC. At

some locations, the carrier delivers the equipment to be loaded.

The carrier receives a notification when the trailer is ready to

be picked up. When the shipment is picked up, the driver signs

the bill of lading and a user performs the ship start

 SAP TMS Implementation 51

transaction in ECC which changes the shipment status to

“enroute” status. The shipment data in the order management

system is updated for the customer. A daily report is emailed to

a carrier indicating the shipments that loaded and departed that

day along with the bill of lading number that is required for

proper invoicing of the freight movement.

Once the shipment is delivered to the customer, the

transportation service provider either submits an EDI 214

transaction or updates the shipment status using the WCL. The

status is then changed to “arrived at destination.” The customer

will also update the order management system to indicate that

the shipment has been delivered. The date and time that the load

is delivered is the key information associated with this status.

The “shipment end” is triggered in the system.

History related to the shipment is stored in one of the two

repositories--the Information Warehouse (IW), a custom data

warehouse or the SAP Business Warehouse (BW)—for reporting

purposes.

Once the driver has picked up a shipment, the

transportation service provider receives the bill of lading

number and can submit a freight invoice to the third-party

payment (3PP) vendor.

 SAP TMS Implementation 52

The above process outlines at a high level the

transportation processes and what happens to a shipment from

beginning to end. Truck and intermodal shipments follow this

process. Rail shipments are slightly different in that the

tender in not offered to the rail transportation providers for

planning purposes. Orders for boxcars are placed with the

servicing railroad. When the loading of a boxcar has been

completed, the shipment instructions are transmitted to the

railroad via EDI 404 transactions. The primary difference is

that rail tenders are placed in “accepted” status by a

transportation planner rather than the transportation service

provider. Once the PGI occurs, the “ship start” is

systematically triggered, and the ship start in turn triggers

the EDI 404 transaction. Another difference is that the EDI

transaction is generated from the ECC system rather than TPVS.

The status updates are interfaced to the other systems, so that

all systems have synchronized information related to the

shipment.

Manually created shipment activity is conducted in the ECC

module.

Original Design Note: The project team originally intended

for the transportation planning work to be performed in TPVS

rather than ECC. Instead of publishing all of the shipments for

 SAP TMS Implementation 53

a week, the plan was to publish a couple of days’ shipments at a

time, re-run Load Builder as necessary and allow the system to

solve for inventory or production issues. The timing associated

with this planning solution drove some of the design in the WCL

providing a separate visibility to shipments in the planned

status vs. those in that had been published to the ECC. It was

thought that carriers would need to perform most tender

acceptance processes using the planned shipment visibility and

that the arrival updates would be completed using the

transportation visibility. The planned publishing process was

changed back to the weekly method before the new system was

implemented. Publishing the following week’s shipments occurs

shortly after the tendering is completed for a location, so new

tenders often move from the planned shipment visibility to the

transportation visibility within minutes.

Logical architecture.

Figure 8 shows how the system will be designed.

 SAP TMS Implementation 54

Figure 8. BBC Company Logical Architecture After Implementation of the APO

Upgrade and TMS Replacement

Source: BBC Company Documents

The project documentation indicates that there were no changes

required to the existing infrastructure to support EM or SCM.

SAP uses a three-tier client/server architecture. Tier 1 is the

client user interface, tier 2 is the application and tier 3 is

the database (Bancroft, Seip, & Sprengel, 1998).

Security.

External WCL system users were required to register for a

user id to enable them to access the system. Each carrier was

encouraged to have all potential users register for his or her

 SAP TMS Implementation 55

personal user id, and each carrier was encouraged to have at

least two users—a primary and a backup. The carrier interface

architecture was structured to use an SAP reverse proxy to gain

access to the SAP applications with the SAP portal providing the

initial authentication. The carrier user IDs were maintained in

a separate domain in the active directory (AD) from the

corporate users.

The initial password was designed to be emailed to the user

when he or she successfully entered the correct user ID and the

same information--first name, last name and email address--that

was provided during the registration process. If the information

matched, the password was emailed to the user’s email address.

If the information did not match, access was denied.

Pre-implementation and post-implementation processes for

setting up the users were developed. The first was a spreadsheet

with the user registration information. The latter required a

formal IT request with specific information related to the user

and the carrier. Each user was given a unique User ID that was

recorded in the domain for non-employee users. Once the user ID

was issued, the user permissions had to be set up in the SAP

portal. Lastly, the user profile in Event Manager had to be

configured for the specific carrier so that only that carrier’s

shipments were visible to the user.

 SAP TMS Implementation 56

Internal user IDs were created in a different domain. These

users were given visibility to all shipments in the WCL and

access to the enterprise portal. They were supposed to have

single sign-on (SSO) capability in WCL, meaning they did not

have to enter a user ID and password to access the WCL if they

were already logged into the network.

SAP landscape.

The SAP landscape included a development (DEV) environment

that was used for all configuration and program coding; a test

(QA) environment that was fully integrated and used for

regression testing and integration testing; and the production

(PROD) environment.

Testing.

Four testing cycles were planned for USEvolve, each with

its own objectives. The purpose of Cycle 1 testing was to

execute regression test plans in the DEV environment to validate

the existing APO functionality. Cycle 2 had two different

phases. The first phase was planned to perform configuration,

unit and string testing in DEV related to the TMS replacement

components which included TPVS, EM, WCL, master data, and R/3
 SAP TMS Implementation 57

rate management. Part two of Cycle 2 included several activities

in the QA environment. At that time, QA was not fully integrated

so some of the testing was limited. The tasks included in this

testing involved user acceptance testing (UAT) of APO

functionality not related to TMS, monitoring system performance,

and performing the first mock cutover test.

Cycles 3 and 4 involved further testing in the QA

environment including end-to-end testing. Cycle 3 required users

to execute test cases again and validate that all work processes

worked as designed and sign off. The plan for testing in this

cycle expanded to include the TMS functionality along with

carrier testing if the functionality was available at that time.

It also included system integrations and interfaces that were

not available in the previous cycle, additional performance

testing, and a second mock cutover.

The final cycle of testing, Cycle 4, was to finalize all

test cases, resolve any outstanding defects, test the portal and

event manager via the firewall, perform carrier testing for both

the portal functionality with external access and EDI

functionality. This phase also included performance testing of

the portal.

The team leads were responsible for the test cases and

assigning the testing to the appropriate users. Test cases were

 SAP TMS Implementation 58

managed through SAP Solution Manager, a toolset used to define

process hierarchies and to manage the testing process and

documentation.

SAP AG Company Overview

SAP AG is a software company specializing in enterprise

resource planning (ERP) software packages. Globally, it is

ranked first in the following enterprise software markets:

enterprise resource planning (ERP), customer relationship

management (CRM) and supply chain management (SCM)(Datamonitor

2008a).

The company is headquartered in Walldorf, Germany and has a

strong global presence operating in 50 countries through its

partners and subsidiaries. The company has three business

divisions—product (software), consulting and training

(Datamonitor 2008a). Revenue in 2007 for the company was E10.2

billion with the U.S. business, its largest market, accounting

for over 26% of its business. SAP AG employs nearly 44,000

throughout the world (Datamonitor). Competing with MicroSoft,

Oracle and other large business software companies, SAP held

28.4% of the market share in 2007. Its software is utilized by

over 38,000 companies globally (Datamonitor).

 SAP TMS Implementation 59

The name SAP is an acronym for its German name, “Systeme,

Anwendungen, Produkte in der Datenverarbeitung,” which means

“Systems, Applications, and Products in Data Processing” in

English (Williams, 2000). Datamonitor (2008a) reported the

company was established in 1972 by five former IBM engineers and

released R/1 the following year. It also indicated that SAP AG

initially evolved through its own development work and most

recently it has expanded its success by acquiring other software

companies that excel in a specific market segment. In 2004, the

company developed its roadmap to achieving a service-oriented

architecture (SOA)(Datamonitor). SAP NetWeaver has been a very

successful innovation for the company and has made the system

easier to implement and enhance (Datamonitor).

The SAP system has several different applications that

represent a business process. Most utilize a fourth-generation

programming language called Advanced Business Application

Programming (ABAP) ((Williams, 2000).

Summary of What is Known and Unknown About the Project Topic

There are a number of things known about this case study.

When the new replacement transportation management system was

cut over to the production environment, there were many

unexpected problems encountered. Most of the issues were

 SAP TMS Implementation 60

documented through the BBC Company’s help desk and a ticket was

logged for each issue that was reported for all aspects of the

project. Some of the problems experienced, especially during the

first day or two, were managed outside of the formal process via

direct telephone or email contact with the technical resource. A

log of the help desk tickets is available from the daily

production support meetings in which the tickets were

prioritized and resources were assigned. The author, who was an

observer-participant during part of USEvolve, has maintained an

archived email database from the project which contains

reference to most other TMS-related problems that occurred after

the cutover.

Project Evolution followed the BBC Company’s prescribed

project management process and its global IT methodology. Most

of the project’s documentation was performed using the approved

templates. The project utilized a Microsoft SharePoint site for

team communication and collaboration. That site is the official

Project Evolution documentation repository. The TMS business

requirements and the defect log for the total project are both

available on the site.

Details related to the TMS enhancement phase are available

in the Logistics department’s database. To sum up what is known

is that there is a significant amount of information related to

 SAP TMS Implementation 61

Project Evolution that may or may not answer the questions

related to this study.

What is not known about Project Evolution is greater than

the amount that is known. The author became an observer-

participant in the project during the training phase. Prior to

becoming a trainer, knowledge of the project was at a very high

level of detail. The training role required the author to learn

how to use the new TMS system, including TPVS and Event Manager,

well enough to teach others how to use it for their particular

roles and to assist the TMS users with support during the

production support phase.

It is not known how the design phase of the process was

conducted for TPVS and Event Manager. It is not known how the

testing phase of the project was conducted.

In general, it is not known what caused the go-live issues.

In a few instances, an explanation related to specific problem

has been offered by the technical IT resources.

Contribution This Project Will Make to the Field

The cost associated with upgrading or implementing an IT

system tends to be expensive, so anything that can be learned

from this study may reduce overall expenditures for future BBC

Company projects or for other companies undertaking similar

 SAP TMS Implementation 62

work. It is hoped there will be implications for both the

business and the technical aspects of the project that can be

applied.
 SAP TMS Implementation 63

CHAPTER THREE: METHODOLOGY

Research Methods to Be Used

A grounded theory approach was selected as the most

appropriate method to research the TMS system implementation

phenomenon that occurred when the BBC Company deployed the new

system to production. This approach best supported the nature of

the research objectives to develop a better understanding of

Project Evolution overall and, more specifically, to develop a

better understanding of what occurred during the go-live process

and the following six-week production support period and what

may have caused the problems that were encountered. Grounded

theory was well suited for research within the actual business

context, allowing the data to drive the research and allowing

for iterations as required. This particular study was not

conducive to a quantitative research methodology.

Life-cycle Models to Be Followed

Two basic life-cycle models, a waterfall model and an

iterative mode, were followed in this research. The waterfall

methodology was used in the project management life cycle and

the research life cycle. The research model outlined by Dul and

Hak (2008, pp. 12-13) included nine steps in three different

phases. Phase one of the research model, the preparation phase,

 SAP TMS Implementation 64

included 1) defining the research topic, 2) defining the general

research objective and the general type of research and 3)

defining the specific objective and specific type of research.

The second phase was the actually research phase which included

developing the research design 4) selecting the research

strategy and 5) selecting the instance(s); 6) data collection

and 7) data analysis. The final phase included 8) discussing

the results and 9) reporting the research (Dul & Hak).

An iterative life-cycle model was utilized in conjunction

with the grounded theory method. This model supports flexibility

in the data collection and data analysis phases of the research.

It has been referred to as a recursive model by some as the data

collection and analysis often occur in an almost parallel nature

rather than sequential and the process can move forward or

backward within the processes (Bryman & Bell, 2003).

Specific Procedures

Preparation Phase

A project plan for organizing the professional project and

presentation was established and the literature review related

to research methodologies and research design was begun. The

project proposal and the initial research design was developed

and submitted to the project advisor and subsequently approved.

 SAP TMS Implementation 65

The questions to be answered included:

• What system issues were encountered when the system was

implemented in production?

• What was the nature of each of the issues?

• Were the problems experienced during cutover different than

the problems that were uncovered during the testing phase?

• Were any of the problems related to business requirements

that were not defined?

• Were any of the problems possibly related to poorly defined

business requirements?

• Were any of the reported issues business requirements that

were defined and not implemented? If so, why was it not

delivered?

• Why did it take so long to resolve the issues identified?

• Why did the production version of TMS differ from the test

version and the training materials?

• What can be learned from this TMS implementation that can be

applied to future implementations?

 SAP TMS Implementation 66

Research Phase

Research Design

Initially, high-level questions related to the BBC Company’s

TMS system implementation were outlined, and the appropriate

data collection techniques were identified. Based on the

literature reviewed earlier in chapter 2, it was determined that

documentation from USEvolve was a good source of evidence and

could provide many insights into the project issues. Three

specific documents were initially identified for analysis as the

first phase of the data collection process.

The first document to be reviewed was the log of issues from

the help desk process. This would provide an objective source of

information related to the nature of the system issues.

The defect log was the second document selected for

analysis. The purpose of this log was to document and track any

known problems encountered during the testing phase of the

systems development life cycle and the status of the particular

defect. Comparing the problems documented in the defect log

against the issues reported in the help desk log would provide

objective insights related to a specific problem--whether an

issue was defined prior to the system cutover, whether the

problem had been resolved prior to cutover, what the resolution

was and whether there were any implications as to why the

 SAP TMS Implementation 67

problem still existed at go live. Theoretically, all defects

should have been resolved prior to cutover or documented as to

why a defect was not resolved.

Business requirements defined for a project are generally

used in the system design. The business requirements document

was selected as the third source of evidence providing an

objective approach for comparison to the help desk ticket log.

Analysis in this area was planned to review three different

possibilities: 1) to determine whether there were business

requirements that had not been defined, 2) to determine whether

there were poorly defined business requirements and 3) to

determine if there were business requirements defined that were

not delivered.

Interviews were also determined to be an appropriate source

of evidence for providing insights and potentially answering the

research questions. Interviewing was planned as the second data

collection phase to allow for further exploration depending upon

the findings from the first data analysis phase. Planned

interviews were targeted to both technical project resources and

business project resources. The specific individuals would be

selected based on the first phase analysis and availability of

the resources.
 SAP TMS Implementation 68

A third planned source of evidence was the author’s

observation as a participant. To limit the subjectivity

introduced to this study, the project documentation was planned

to be utilized as the first source of information wherever

possible followed by the interview information. The entire

USEvolve project repository was a planned source of evidence for

any other research that would potentially need to be done.

Other possible resources could be defined as the project

progresses.

Triangulation of the data sources was planned to improve the

objectivity and reliability of the study. To further increase

the reliability of the information, a case study database along

with the data analysis and interview notes will be maintained.

Data Collection and Analysis

First, the help desk ticket log was retrieved. The log

included issues that were reported from the cutover of the

system through the six-week production support phase. Items in

the log that were not specifically TMS-related were deleted.

Each remaining item in the log was given a new identifying

number and categorized based on the system(s) that were impacted

(e.g., TPVS, EM, WCL, ECC, Other). Next, each item was

categorized as an email, EDI, rate or functionality issue. Items

 SAP TMS Implementation 69

that were out of scope were eliminated. Similar items were then

grouped together. For example, there were several individual

items related to logging into the WCL or to EM. Minimal changes

to the information on the spreadsheet were made to ensure the

privacy of the company.

Finally, a review of the help desk log from a participant-

observer role revealed there were some missing issues. A

systematic email review was undertaken to add items that were

reported to the technical resources rather than using the

official help desk process. For the most part, the missing items

occurred during the first two days; however, there were some

other items that were not officially reported throughout the

six-week timeframe. As an example of an item that was added

from the email database is an issue that occurred the first two

days. Almost all users were unable to log into the system.

Carriers called the Logistics department for assistance and the

business users passed the information directly to the WCL and EM

technical resources rather than logging a ticket. Although the

issue had many instances, it was logged one time for each

instance that contained a different description or details

related to the issue or that identified a specific resolution.

The intent in logging it more than once was to preserve any

information that may provide insights for future reference.

 SAP TMS Implementation 70

Next, each item in the revised TMS help desk ticket log was

analyzed against the Project Evolution defect log to identify

any known issues for further analysis. The defect number, if

found in the defect log, was recorded in a separate column next

to the ticket information on the ticket log. A description of

the defect, status and the resolution information was also

recorded in a separate column next to the defect number.

A copy of the detailed business requirements was retrieved

from the repository. Each item from the revised TMS help desk

ticket log was reviewed against the detailed business

requirements to determine first whether a business requirement

was defined in relation to this issue. If there was a business

requirement, the detailed business requirement was noted in a

separate column. If there was no business requirement defined,

that was recorded on the spreadsheet. An assumption was made

that a business requirement was probably fulfilled if there was

not an issue defined in the help desk ticket log. That may or

may not have been a valid assumption, but the focus of the

analysis was on the reported problems. The analysis of business

requirements in relation to how well they were defined was to be

a separate process to be done after the initial analysis.

In the process of reviewing the detailed business

requirements, it appeared there were some problems encountered

 SAP TMS Implementation 71

in the “original document” which resulted in detailed

requirements aligned with the high-level requirements that did

not make sense. It appeared to be a “copy and paste” error. The

high-level requirements have some additional documentation. (It

was confirmed that the same data is in the original document

that was signed by all parties.)

An additional component of analysis, namely, the work

defined for the enhancement phase, was also analyzed in relation

to the TMS help desk ticket log.

Once this initial analysis was completed, all documentation

in the USEvolve project repository was reviewed for further

information related to the questions posed in this case study.

The initial analysis did not really answer the questions other

than what issues had been reported and the nature of the issues;

it created more questions. Reviewing the additional

documentation provided more contexts for the project and some

observations related to the project and the project management

process but did not provide any major insights into the go-live

issues.

Interviews were arranged after the initial data analysis and

the documentation review was complete. The results of the

analysis, which will be discussed later, pointed to the WCL as

the area that created the most questions. The developers of the
 SAP TMS Implementation 72

WCL and EM system were both interviewed to gain their

perspective on the issues. A primary business user who had been

most involved in the resolution of issues on an on-going basis

since the implementation was selected for an interview to

represent the business perspective.

Questions to be used for the interviews were prepared in

advance to use as necessary during the interviews; however, the

actual interviews were conducted as conversations rather than a

structured interview. The goal was to gain understanding from

each participant related to his role and insights related to the

TMS replacement project and system.

Formats for Presenting Results/Deliverables

The data collected for the analysis was copied into a

Microsoft Excel spreadsheet with several different worksheets.

Most of the analysis was performed in the worksheet labeled

“HELP Desk Ticket Log – TMS.” Supporting information was

provided in the other worksheets: 1) “Bus Req – High Level” 2)

“Bus Req – Detail Level” 3) “Enhancement Project” and

miscellaneous pivot tables. Concepts related to the analysis

process are presented in the last worksheet as a list. Please

note that the official defect log document was not added
 SAP TMS Implementation 73

included as part of this analysis document due to the many names

and references to products that might identify the BBC Company.

Interview notes were documented immediately following the

interviews using the notes taken during the interview and the

protocols utilized. The following protocol was utilized. In each

interview, the purpose of the case study was defined. An

overview of the method of analysis that had been utilized so far

in the study was reviewed. The disclosure was made to each

person that his interview would become a part of a formal

research paper and that neither his name nor the name of the

company related to the project would be disclosed. Concepts from

the interviews will be captured in the same worksheet listed

above for the data analysis in order to keep everything in one

place. Observations will also be added to that worksheet.

Key concepts, categories and hypotheses will be reviewed as

part of this paper. In addition to the data analysis and the

study results, a significant amount of descriptive information

related to USEvolve and the TMS system was presented in chapters

1 and 2 to provide the necessary background and context for the

results that will be presented later in this paper.

 SAP TMS Implementation 74

Review of the Deliverables

Deliverables represent the final phase of this case study.

The deliverables associated with this study include the

description and context related to the phenomenon being

researched, the analysis documentation, interview questions and

notes, and the review of the study results presented in this

paper. Both the analysis document and the interview information

will be included in Appendixes C and D respectively for

reference.

Resource Requirements

Resources required for this project included the interview

candidates’ and the author’s time to complete the activities

associated with the study. Supporting resources, namely project

advisors and other faculty were the other key resource

requirements to successfully complete the professional project.

Outcomes

The research design was helpful in guiding the work for the

study and for defining the data collection and analysis process.

The analysis process of the documents seemed logical but did not

provide as many insights into what caused the issues as

originally thought. The defect log could have provided more

 SAP TMS Implementation 75

insights had it been utilized to record issues that were

encountered during the testing phase along with a detailed

explanation of the resolution that would allow another technical

resource to easily resolve known issues.

Analyzing the business requirements was very difficult.

There were so many help desk tickets that were not directly

related to the definition of business requirements. They were

related to the system configuration, functionality or design.

Logically, business requirements may not have been the

appropriate vehicle for a correlation to the reported issues.

Reviewing the enhancements defined in relation to the business

requirements was perhaps a better analysis process.

Reviewing the project documentation did not provide answers

to the study’s questions but was viewed as an objective source

of project information. In this instance, the information was

not found; however, in another project, answers or clues might

actually exist. Whether information of this type is available is

dependent upon the documentation and the discipline applied

during a project.

The interviews were definitely the most interesting aspect

of the study. The people interviewed provided some valuable

insights and identified some common themes for additional areas

of research. An interesting theory surfaced related to the

 SAP TMS Implementation 76

cause of the much of the system’s dysfunction; however, no

definitive technical answers were revealed. The depth of the

interviews was limited by the amount of time. Follow-up

interviews could have potentially provided additional details.

Interviews with a wider base of resources could have also

offered more information related to the study questions.

Chapter Review

This chapter outlined the methodology used to conduct this

case study. The grounded theory approach was selected as an

appropriate method for studying this phenomenon. The life-cycle

models that will be utilized were defined. Specific procedures

to be followed were explained. A review of the deliverables, the

resource requirements for the study and the outcomes were also

discussed in this chapter. The next chapter will provide the

project’s history.
 SAP TMS Implementation 77

CHAPTER FOUR: PROJECT HISTORY

How the Project Began

This case study was born from the desire to better

understand the impacts experienced by the Logistics department

business users and external transportation carriers during the

implementation of a new transportation management system at the

BBC Company. From that understanding, the objective is to

determine better methods or practices associated with system

implementations especially in relation to the SAP TMS system

applications. The intent of the study was to also fulfill the

professional project requirements of the Master’s degree program

at Regis University.

How the Project Was Managed

A project management plan initially laid the groundwork for

the professional project. After a significant literature review,

the project proposal with a high-level approach and research

design was submitted for approval. Once approved, the research

design was refined and the official data collection and analysis

began. The specific procedures were outlined in chapter 3.

The data collection and analysis phase followed an iterative

process. The discovery of clues throughout the analysis process

led to additional research related to a number of subjects that

were probably outside the boundaries of this study. Eventually,

 SAP TMS Implementation 78

the process of trying to synthesize the information into

findings led back to the original research design and back to

the final coding stage to complete the study.

Significant Events/Milestones in the Project

The act of beginning to write this paper was a significant

event for the author. Finishing it was an event of greater

significance.

Changes to the Project Plan

The project schedule for this study was pushed out a number

of times usually as a result of other work-related

responsibilities. Shortly after USEvolve was completed, the

anticipated company merger occurred bringing a flurry of new

activities, changes and different responsibilities for the

author.

Scope creep occurred to a certain extent as well. Scope and

boundaries, in an iterative process, are easily expanded by

interest and curiosity as to whether a new path will lead closer

to an answer. After the interviewing component of the data

collection and analysis phase, additional research was conducted

to learn more related to the SAP transport management system,

the SAP NetWeaver platform, the SAP SCEM system, and the WCL

application. In retrospect, these may not have been necessary

 SAP TMS Implementation 79

steps in the study, and they were very time consuming

activities. A more experienced researcher using the grounded

theory method might have been more disciplined around adherence

to the boundaries.

Evaluation of Whether or Not the Project Met Project Goals

From the aspect of providing insights to better managing

future system implementations, the project definitely met its

goals. The author would have liked to have had more definitive,

concrete technical answers; however, the author eventually

accepted the fact that additional investigation will be

required. Even with a further investigation, there is no

guarantee that a definitive answer will be found.

Findings from this study provide a direction for some of the

additional research that could be pursued and some

recommendations for developing better methods and practices for

use in future systems development life cycles and project

management life cycles. While the study did not provide any

technical outcomes that SAP AG and other companies implementing

the SAP SCEM application will likely be able to apply, overall

the study successfully accomplished the objective of developing

a better understanding of the phenomenon.

 SAP TMS Implementation 80

Discussion of What Went Right and What Went Wrong In the Project

Interviews provided the most valuable insights in this

study. The people involved were extremely open and honest. The

discussion related to each person’s personal context within

USEvolve helped to add perspective to some of the other data

analysis and helped in developing some of the inferences.

Additional interviews with others on the team might have added

some dimensions to the findings. The time constraints of the

study and the availability of the other resources prevented

additional interviews.

The initial data analysis of gathering, coding and analyzing

the TMS help desk ticket issues provided evidence indicating

what the most prevalent issues from a quantitative perspective

were. They did not provide any insights related to which issues

caused the greatest impact. The analysis comparing the tickets

with the defect log and the defined business requirements did

not reveal the expected relationship. Reviewing the documents in

the USEvolve project database provided additional understanding

of the overall project and provided some context. The outcome

from reviewing the documents in the repository was not very

enlightening in answering the study questions.

All of these different research aspects were in some way

helpful to the end results. The findings would not have been the
 SAP TMS Implementation 81

same without the multiple data sources. The interviews would not

have provided as much insight without the knowledge gained

through the analysis of the help desk tickets and the other

information that was gathered.

Discussion of Project Variables and Their Impact on the Project

This case study could have been approached in many other

different ways. It is unclear whether the sequence utilized for

the data collection would have influenced the overall results.

For instance, had the data collection and analysis begun with

interviews, the topic of documentation might not have been

included in the interviews. Since multiple sources of evidence

were used, theoretically the documentation issue would have

surfaced from the sources of data and the other data analysis

processes. Confirmation from the developers regarding the

purpose of the defect log and how it was used would have

required additional investigation steps with the developers.

Findings/Analysis Results

TMS Help Desk Ticket Log

Some initial high-level quantitative analysis related to the

nature of the TMS help desk tickets from the log helped to

provide insights as to the direction and focus the study should

 SAP TMS Implementation 82

take. Of the 86 tickets, approximately 86% were related to the

Event Manager and WCL systems and 14% were related to the APO

and TPVS systems.

TMS Help Desk Tickets by System

APO/TPVS EM/WCL

14%

86%

Figure 9. TMS Help Desk Tickets by System

There were some overlaps in that some tickets affected both APO

and EM applications and some instances that also affected ECC.

(Please note, the percentages shown are intended to provide the

general direction; they are not statistically exact.)

Next, the tickets were categorized by the type of issue.

The three general categories emerged from the initial coding: 1)

EDI, 2) email or 3) functionality issue.

 SAP TMS Implementation 83

TMS Help Desk Tickets by Category

Functionality EDI Email

8%

24%

68%

Figure 10. TMS Help Desk Tickets by Category

All of the tickets could probably be categorized as

functionality, but there were a number of issues specifically

related to both EDI functionality and email functionality. Many

of the EDI and email issues were similar in nature, so if the

problem was resolved two tickets were resolved.

It was expected that the relationship of the tickets

reported at and following go-live to the defect log would be

low. It was hypothesized that any known issue prior to go-live

that was logged, resolved and closed as a log item would not be

correlated to a ticket. If the known issue in the defect was not

resolved prior to go-live, there was a likelihood a ticket would

be in the help desk log and the reason for the ticket could be

easily explained. It was also expected that if an issue was

known prior to go-live it would be cataloged in the defect log.

 SAP TMS Implementation 84

It was expected that if some of the issues seen at go-live had

already been resolved in testing, there would be information as

to how they were resolved that the ticket could be quickly

closed.

There were seven instances in which a defect was logged in

relation to the tickets. Of those, all but one were closed as

defect items. One of the closed items had a workaround but was

not resolved. The other five were issues that had been resolved

prior to go-live and reoccurred. The information related to the

resolution was very limited or non-existent.

 SAP TMS Implementation 85

Based on the author’s email documentation, another round of

analysis was conducted in relation to the tickets and whether

the issues were known prior to go-live.

Known vs. Unknown Issues Prior to Go-Live

Known Issues Prior to Go-Live: Defect Logged
Known Issues Prior to Go-Live: Defect Not Logged
Issues Not Known Prior to Go-Live

8%

37%
55%

Figure 11. Known vs.Unknown Issues Prior to Go-Live

Analysis of the known versus the unknown issues prior to go-

live indicated that approximately 45% of the issues were known

prior to go-live. Only 8% of the issues had been logged in the

defect log. The other 37% of the issues had not been logged

indicating that the documentation was either not done or was

stored in a different document than the defect log.

Next the tickets were reviewed in relation to the defined

business requirements. If the ticket logged was associated with

a defined business requirement, the requirement number was

noted. There was no clear relationship between the tickets and

 SAP TMS Implementation 86

the defined business requirements. Only seven of the 59 defined

business requirements were identified in the ticket log. In

analyzing the tickets that were not associated with a defined

business requirement, it became apparent that many of the help

desk tickets were related to system configuration, a programming

issue, application of a business rule, or some other

functionality and that a business requirement would not have

been expected to be defined. In three instances, no business

requirement was specifically defined. Business users expected

the same functionality to exist in the new system; they were

promised like-for-like functionality by the IT project

leadership. Other types of issues that had no business

requirement defined involved system performance, process or

design.

The analysis of the ticket log in relation to the defined

business requirements created more questions than answers.

Intuitively, there is a relationship, but the information that

is being analyzed in this scenario is not robust enough to draw

meaningful conclusions.

EM Dev1 said in the interview that many of the help desk

ticket log items were enhancement requests that were beyond the

original scope of the TMS replacement project. So the

enhancements were analyzed in relation to the tickets and the

 SAP TMS Implementation 87

business requirement definitions. In reviewing the thirteen

enhancement project catgories, there were some new requirements,

but a number of the enhancements represented functionality that

was available and working properly in the previous system. From

a business perspective, that work was in the project scope in

the like-for-like deliverable. One of the enhancement categories

was for WCL work. Some of the issues in that category had been

resolved in the test system and a large number of the design

issues were identified prior to go-live even though there was

not enough time to complete the changes before the system

implementation. From a technical perspective, some of these

issues might be considered new requirements.

In the interview with EM Dev1, he indicated that one of the

goals related to the the TMS replacement project was to reduce

the amount of customization and push the Logistics team to use

more standardized practices. The IT team’s direction was to

provide the “vanilla” version of EM and TPVS and “shoe horn” the

business processes into the system processes. Then, whatever

didn’t work would be customized as required. This approach to

system design might provide some of the explanation for the

large number of tickets and might indicate that an enhancement

phase was planned rather than just an outcome of the TMS

project.
 SAP TMS Implementation 88

The initial analysis of the TMS help desk ticket log

provided some definition around what the go-live issues were and

what difficulties were encountered during the analysis with

regard to the defect log and the business requirements. What the

analysis did not provide was a true guage as to the severity of

the issues. There were approximately four tickets related to

system performance. Both of the EM developers reported system

performance as the most critical issue at go-live. The poor

system performance, incorrect information, and the improper

functioning of our transportation carrier communications—EDI,

the WCL, and emails—caused many issues for our carriers. They

were not receiving the correct information, they were unable to

view the information on the WCL and in some cases the incorrect

EDI transactions were causing severe system errors.

The internal transportation planners were waiting hours for

the tendering process, fielding calls and troubleshooting the

carrier difficulties related to logging into the WCL, emailing

screen prints of tenders to carriers, and finding ways to deal

with the information gaps. There was a great deal of chaos

beginning Day One.

Nearly every transportation carrier user had difficulty

logging onto the system intially due to a number of different

causes. In many instances, the authentication information

 SAP TMS Implementation 89

required for the initial password to be emailed to the user

failed because there was a space preceding the contents of one

or more of the required fields. In other instances, a component

of the security set-up process was not complete or was

incorrectly configured. Testing this functionality was not

feasible prior to implementation.

To close out the analysis of the help desk ticket log, the

defect log, the business requirements, and the enhancements, key

thoughts and questions were recorded in a separate tab in the

analysis spreadsheet labeled “Concepts, etc.” That worksheet was

used to record key ideas from the interviews along with other

observations as a participant. This information was used in the

development of categories and the sythesis of the study’s

findings.

Interviews

The following is a discussion of some key concepts from the

interviews that were conducted with the two EM/WCL system

developers and one of the primary business users. The notes from

the interviews are located in Appendix D of this paper for

reference.

When asked for insights as to what caused the differences

between the test and production versions of EM, WCL and TPVS,
 SAP TMS Implementation 90

both system developers indicated that system performance was the

primary cause. Both confirmed that a stress test was not

performed because the QA system was not designed for that type

of testing. The impact of so many users at one time was not

anticipated.

EM Dev2 said that WCL version (4.1) was an older version

using Java and was not designed for the volume of transactions

and the number of system users at one time. He indicated there

is a newer version (5.1) that is based on an ABAP platform that

would have better supported the performance requirements.

EM Dev1 offered another explanation of the differences in

the test and the production versions of the systems. Normally, a

change to the system follows a sequence of progression from the

DEV environment to the QA environment and finally to the PROD

environment. At go-live, some SAP transports (system changes)

were created directly in PROD without going through the normal

sequence. Whenever a transport is created, it locks objects in

the system. The objects must be “released” before other

transports can be applied. Some of the objects were not released

properly. As a result, other transports could not be properly

applied as they were moved from QA to PROD. The system was left

in a different “state.” That is why the system looked and

functioned differently than expected in the production version.

 SAP TMS Implementation 91

This explanation seemed to make the most sense related to

differences that were unexpected. This could explain a very

large number of the help desk tickets. However, EM Dev2 did not

concur. When asked about the tranport process, he indicated

there was not a problem with that system. The interviewer did

not ask clarifying questions at that point and should have. It

is possible that EM Dev2 interpreted the question in relation to

the transport management system in SAP rather than the way the

transports may have been applied and the resulting problems.

Further investigation of this explanation would be

warranted. If it truly was the cause of so many of the issues,

it needs to be well understood by technical resources to prevent

further occurences.

Both system developers suggested the TMS replacement project

should have been a separate project with focused resources. Many

of the technical resources were responsible for supporting more

than one system so they were pulled in many directions. The

number of resources that had the capability to assist with

development of EM and WCL were very limited. There were a total

of four resources and three of them had other responsiblities to

balance. The technical resource responsible for TPVS was also

responsible for the Load Builder application. There were

problems associated with the Load Builder that delayed testing

 SAP TMS Implementation 92

for TPVS, EM and WCL. Responsibilites for other upstream

processes also impacted the work EM Dev1 could perform related

to EM and WCL. Because of the dependencies, the upstream

processes had to be resolved before the next step in the process

sequence could be completed.

Constrained business resources were also an issue according

to the developers interviewed. The project had a business

project lead assigned. He left the company mid-way through the

project. A different person was assigned to that role. Both felt

there was a gap in the knowledge transfer during the transition.

Neither of the people assigned to the business lead role was a

primary system user. It was suggested that the role should have

been filled by a primary user who could provide more of the day-

to-day business requirements.

Testing was a key area that all three of the people

interviewed brought up as having been problematic. From the

business user’s perspective it was the biggest issue related to

the project. He felt it lacked structure and was not thorough

enough. He said that data and system problems impacted the

testing the TMS users were able to do almost every time they

tried to test. BusUser1 conducted many of the training classes

for the transportation carriers. He said it was difficult to get

data for testing and he never knew for certain that the data
 SAP TMS Implementation 93

would be available for each class because there was a limited

amount and multiple groups were using the same data. He felt

that there was a lot of productive time lost when trying to

test.

Both technical resources interviewed agreed that there was

not enough testing. EM Dev2 felt there was not enough

integration and system stress testing. He also suggested that

more carriers should have been included in the testing phase.

Each EDI carrier did participate in testing transactions;

however, only one major carrier was involved in most of the

testing.

The design phase of the development life cycle was

challenging for both the developers and the business team. EM

Dev1 indicated EM was a very new system and that it was new to

the company’s IT team. They were learning the new software on

the “fast track.” Because the system was so new, it was

extremely difficult to find an experienced resource with

knowledge of the EM and WCL.

According to the developers, the defined business

requirements did not provide enough detail to effectively

configure the new systems. The original business lead was

involved early in the project and provided some initial

direction for the design. BusUser1 said he was involved in an

 SAP TMS Implementation 94

early design phase meeting, but did not see the prototype until

several months later. The business user said he had never seen

the original business requirements nor any documentation

following the design meeting.

Once the developers were ready for the business involvement

it was the company’s busy season and it was difficult for

business users to attend meetings. Different users often

alternated attending meetings. This created some other problems

as the user attending would provide input on how the system

should be set up. At the next meeting, a different user would

request it be changed. There was no group consensus. Some users

did not have an opportunity to provide input. The developers

indicated that sometimes the primary business users were not at

the meetings and their expertise in the day-to-day requirements

was critical. By the time the primary users had an opportunity

to test the new system, it was too late to incorporate many of

their requests for system design changes due to the project

schedule.

Both developers recommended early user involvement with the

primary business users as a critical success factor for future

projects. BusUser1 recommended that the developer spend time

actually sitting with the business users prior to beginning the

 SAP TMS Implementation 95

design to understand the users’ work and the business

requirements.

Other implications or learnings from these interviews

related to the business requirements and design suggest that

communication within the business team and between the technical

team and the business team could have been much better.

Incomplete or missing documentation was a consistent theme

throughout the case study research. During interviews with the

two EM system developers they confirmed that the defect log was

not utilized properly throughout the project for EM and WCL

issues. Time constraints caused them both to prioritize the

delivery of the system over documenting the issues they

encountered during testing and the resolution. It was pointed

out that the nature of process related to the defect log tends

to discourage its use to some extent. A logged defect usually is

assigned back to the same technical resource along with a

deadline for resolving the issue. Once the issue is resolved,

there is more work for the resource to update the documentation.

EM Dev1 reported that most of the changes to WCL were made

in the DEV or QA system while a user was present and could

validate the changes. No formal documentation of the changes was

maintained. These system developers were not the only ones who

did not maintain documentation. The examination of documents in

 SAP TMS Implementation 96

the project’s repository also revealed many missing project

documents or incomplete documents. For instance, documentation

of lessons learned has always been a standard process for all

projects. None was found on the site other than one specifically

prepared by the training team. The business requirements

document is an example of incomplete documentation. It had been

approved by the appropriate parties but still has sections that

indicate they will be defined by a specific person. There is no

additional or updated documentation associated with those

requirements.

Another distraction that EM Dev1 reported in the interview

that probably impacted the development, testing and focus on

USEvolve was the announcement made a few weeks prior to go-live

that Hewlett Packard (HP) had been selected to replace EDS as

the company’s strategic partner. At the time, HP and EDS had not

yet merged, and many of the BBC Company’s IT employees were

affected by a reduction in force. A number of the employees,

including EM Dev1, transitioned from BBC Company to HP and

continued to perform the same work as an HP consultant to the

BBC Company. The elimination of positions impacted other

employees working on the project. The timing of this stressful

event was poor.

 SAP TMS Implementation 97

Summary of Results

Analysis of the TMS help desk ticket log indicated that the

majority of issues reported were associated with the Event

Manager and the WCL. EDI and email issues accounted for a

significant percentage of the tickets. Analysis of the help desk

ticket log and the defect log revealed that there was very

little documentation related to problems that had occurred prior

to go-live, and it led to additional incremental analysis

related to categorizing tickets that represented issues that

were known prior to go-live versus the tickets related to issues

that were not known prior to go-live. It supported the idea that

more information should have been documented in the defect log.

Business requirements that had been defined during the

feasibility stage of the USEvolve project were compared with the

help desk tickets and no clear relationship was established. It

was determined that many of the tickets were related to a type

of system functionality that generally would not necessitate

that a business requirement to be defined. The last step in this

initial analysis phase involved reviewing the tickets with the

enhancements that were defined for a subsequent project to

determine if a business requirement had been defined for that

enhancement. There were some new business requirements, but a

 SAP TMS Implementation 98

number of the enhancements were defined originally as a

requirement. A few were found to be functionality that was

available in the previous system and expected by users in the

like-for-like solution that was delivered.

The quantitative analysis did not reveal the severity of the

impacts related to the system performance and the significance

of the impact of incorrect information being emailed and

transmitted systematically to the transportation carriers.

Information from the interviews was extremely helpful in

adding context to the phenomenon. System performance was the

main problem experienced during go-live from a technical

perspective. The volume of transactions and the high number of

users at one time was not anticipated and overwhelmed the

system.

A technical explanation of how system objects that were not

properly released after they were changed in the production

system caused an altered state of the production system as

additional transports were moved into production offered one of

the most logical explanations related to one of the key study

questions. The fact that the second developer did not agree was

extremely disappointing. However, because of the significant

impact the incorrect system version had on the business and its
 SAP TMS Implementation 99

partners and the cost implications, it is an important concept

to continue to pursue.

Other themes that evolved from this case study included

challenges that were faced and suggestions for future projects.

Some of the major challenges were the constrained technical and

business resources for the project, losing a key person during

the project, system design and testing problems related to the

dependency upon upstream processes and applications, conflicting

user requirements, and the lack of documentation discipline.

Ideas for improving future implementations included some of the

following suggestions: 1) organize each system implementation or

upgrade as a totally separate project to allow resources to

focus their efforts, 2) ensure primary business users are

actively involved in defining business requirements and

participating in the additional requirements gathering and

system design processes, 3) develop a process to ensure there is

consensus among the users related to business requirements and

system design that includes a process for escalation to resolve

conflicting requirements, 4) conduct comprehensive testing to

include integration and stress testing, 5) include external

users in the process as much as possible, and 6) proactively

communicate key information within the business team and with

the technical team.

 SAP TMS Implementation 100

CHAPTER FIVE: LESSONS LEARNED AND NEXT EVOLUTION OF PROJECT

What Was Learned From the Project Experience

The descriptive nature of the grounded theory approach

requires a significant amount of narrative to adequately set the

stage for the audience and provide the context related to the

study. Researching the company and the project at the level of

detail required to become knowledgeable about how the project

was structured, what the system changes entailed and to

genuinely understand the project required reading and absorbing

all of the project documentation and further researching areas

that were not fully understood.

Writing the story created a continuous search for more

knowledge and additional information. Even as the deadline

loomed to complete the writing, there was still tendency to want

to go research a subject more completely. Setting the boundaries

for what was an acceptable level of knowledge was challenging.

As a novice utilizing the grounded theory method, the

process was uncomfortable at times. Initially, it seemed as

though there was little or no information to support the answers

to the study questions. There were times when the real question

in the author’s mind was whether the work was being carried out

correctly. Additional iterations of reviewing the data that had

been collected eventually led to some inferences that were

 SAP TMS Implementation 101

meaningful although not the technical level of explanation that

was being sought. The process also made it clear that the

technical answer might not be found without initiating a

different study method. The time and cost associated with a more

technical, root-cause type of analysis might end up being higher

than the value returned.

Gorman and Clayton (2005) were referring to an automated

process when describing qualitative research, but the

description seems to sum up the work conducted regardless of

whether the data is collected and analyzed manually or using an

automated system. “By its very nature qualitative research

encourages the collection of too much data, and the abilities of

information technology only compound this tendency” (p. 219). It

is “. . . more conducive to breadth analysis rather than depth

analysis” (p. 220).

What You Would Have Done Differently in the Project

Accepting the research design boundaries would be the major

change the author would have made in conducting this study.

While the author learned a great deal about SAP systems, the

unplanned research conducted throughout the study took a great

deal of time. Certainly some of the information was applied to

the study, but it probably would have been better to have

 SAP TMS Implementation 102

acknowledged the lack of detailed knowledge on the subject and

identified the subject as a possible future direction to

continue researching in a later, separate study.

Discussion of Whether or Not the Project Met Initial Project

Expectations

As previously discussed, the project did not meet the

author’s initial expectations. The answers were not neatly

documented in the project’s repository. There were few clues in

the data other than what issues were defined through the help

desk tickets. The information obtained from the interviews was

much closer to meeting the initial project expectations. After a

certain number of iterations of reviewing and analyzing the same

information in different ways, the results seemed more

meaningful and satisfying.

What the Next Stage of Evolution for the Project Would Be If It

Continued

There are several different avenues that could be pursued as

the next stage of evolution for this study. Because of the

tremendous operational and cost implications associated with

implementing an incorrect version of a system into the

production environment, the first opportunity would be to

 SAP TMS Implementation 103

research the change process further to determine if the

explanation provided by EM Dev1 is a valid explanation related

to the system object locking and release sequencing. If it is

proven to be true, then additional training and controls need to

be implemented to ensure this issue is not repeated during

future system changes of any kind. It is possible that the

company’s IT Centers of Excellence would assist with the

investigation and the training.

In light of the company’s recent merger, there are a number

of activities that could be included in the next stage of

evolution for this project as preparation for the next system

change. From a business perspective, a project to research best

practices for writing effective business requirement definitions

could be initiated. Improving the current definitions would

provide the foundation for defining the business requirements

for the next generation system that consolidates both companies’

business operations. The process should be done systematically

so that the requirements include all business activities that

are conducted.

Another important step in preparation for expected system

changes that could be undertaken relates to documentation. The

current state system, including all processes, applications,

interfaces, data and architecture, should be completely

 SAP TMS Implementation 104

documented before a consolidation effort is begun. As another

step in documentation, it might be helpful to conduct some short

follow-up interviews with the appropriate technical resources to

document, even at a high level, what is known about the actions

that were taken in the past to resolve the initial help desk

tickets.

Since it is known that the current WCL system is not

scalable, researching alternative solutions for the short term

and the longer term could be started. This work stream could

include an investigation into methods for conducting the

appropriate stress tests in the future to ensure system

performance is acceptable.

Another continuous improvement work stream that could be

pursued, perhaps by the IT Centers of Excellence, relates to

finding better methods to incorporate documentation efforts into

projects. The company has implemented a disciplined

organizational structure and a formal methodology to support

successful projects. It is providing a framework that is not

being utilized effectively. The full value of the investment is

not being realized. The nature of the work involved with

documentation sometimes drives the wrong behavior. There may be

opportunities for increasing the value of the documentation to

the company and, at the same time, making the documentation

 SAP TMS Implementation 105

process less time consuming and easier to use for technical

resources.

Conclusions/Recommendations

Several opportunities have been identified as a result of

this study. It is recommended that two work streams be pursued

in the near future. The first work stream would be conducted by

the technical organization. The team would review the validity

of the theory proposed by EM Dev1 regarding the SAP system

object locking and release behavior. The findings would

determine any subsequent action to be taken, if any.

The second work stream would be assigned to the business

team to research best practices in writing effective business

requirements. Both of these actions would support more

successful future system implementations and support future

system changes required as a result of the company’s merger.

Other opportunities have been identified and could be future

projects and may depend upon the timing and nature of the

company’s business plans.

Summary

The purpose of this case study was to examine the TMS

replacement project and develop a better understanding of the

 SAP TMS Implementation 106

problems that occurred when the system was deployed. It was

hoped that analyzing this project would provide insights as to

what could be learned from the problems and effectively utilized

for improving future system implementations.

The study followed a defined research design using the

grounded theory method. Through its iterative process, a number

of themes developed that helped to explain some of the

challenges and influences that contributed to the go-live system

issues. The themes developed into suggestions for improving

future projects and potential work streams to continue to the

next evolution of this study.

 SAP TMS Implementation 107

References

Bancroft, N. H., Seip, H., & Sprengel, A. (1998). Implementing

SAP R/3: How to introduce a large system into a large

organization (2nd ed.). Greenwich, CT: Manning Publications

Co.

Bryman, A., & Bell, E. (2003). Business research methods.

Oxford, NY: Oxford University Press.

Datamonitor (2008, June 27). SAP AG: Company profile (). New

York:

Datamonitor (2008, October 20). BBC Company [name changed for

anonymity in paper]: Company profile (). New York:

Dul, J., & Hak, T. (2008). Case study methodology in business

research. Burlington, MA: Butterworth-Heinemann.

Gorman, G. E., & Clayton, P. (2005). Qualitative research for

the information professional: A practical handbook (2nd

ed.). London, UK: Facet Publishing.

Myers, M. D. (1997). Qualitative research in information

systems. MIS Quarterly, 21(2), 241-242. Retrieved from

Association for Information Systems Web site:

http://www.qual.auckland.ac.nz/

Pandit, N. R. (1996). The creation of theory: A recent

application of the grounded theory method. The Qualitative

Report, 2(4), . Retrieved from http://www.nova.edu/

 SAP TMS Implementation 108

SAG AG. (2005). Configuration and modification guide for the SAP

EM Web interface (SAP SCM WCL 5.0) [Brochure]. : Author.

Sap Ag. (2008, August 28). SAP event management: What it is, and

how you can reap the benefits (Webinar). Message posted to

https//www2.gotomeeting.com/join/756422191/106028016

Scholz, R. W., & Tietje, O. (2002). Embedded case study methods:

Integrating quantitative and qualitative knowledge.

Thousand Oaks, CA: Sage Publications, Inc.

Sens, M. (2008). Upgrading SAP. Infinity Science Press.

Retrieved March 1, 2009, from

http://common.books24x7.com.dml.regis.edu/book/id_24722/boo

k.asp

Stake, R. E. (1995). The art of case study research. Thousand

Oaks, CA: Sage Publications, Inc.

Traverse, M. (2001). Qualitative research through case studies.

Thousand Oaks, CA: Sage Publications.

University Of Texas (2008). The case study as a research method:

Uses and users of information --LIS 391D.1. , , . Retrieved

from http://www.gslis.utexas.edu/

White, B. (2000). Dissertaton skills for business and management

students. New York, NY: Cassell.

Whitten, J. L., & Bentley, L. D. (1998). Systems analysis and

design methods (4th ed.). Boston, MA: Irwin McGraw-Hill.

 SAP TMS Implementation 109

Williams, G. C. (2000). Chapter 1: Introduction to SAP sales and

distribution. In Implementing SAP sales and distribution

(p. ). Retrieved March 1, 2009, from

http://common.books24x7.com.dml.regis.edu/book/id_7214/book

.asp

Yin, R. K. (2003). Applications of case study research (2nd

ed.). Thousand Oaks, CA: Sage Publications, Inc.

Yin, R. K. (2003). Case study research: Design and methods (3rd

ed.). Thousand Oaks, CA: Sage Publications, Inc.

 SAP TMS Implementation 110

Appendix A: Terms and Acronyms

Term/Acronym Definition
3PP third-party payment
ABAP Advanced Business Application
Programming; 4th-generation
programming language used in
most SAP applications
AD Active Directory; system for
authenticating users for single
sign-on
APO See SCM
Basis SAP system administration—
requires skills related to
database management, GUI and
the operating system
BO BusinessObjects; reporting
system used for extracting
information from the
Information Warehouse
CEO Chief Executive Officer
CFO Chief Financial Officer
CIO Chief Information Officer
COE center of excellence
CRM Customer relationship
management
CSO Chief Strategy Officer
DEV development system environment
DP demand planning
ECC See R/3
EDI Electronic data interchange
EDI204 transaction Tender offer to transportation
carrier via electronic data
interchange
EDI990 transaction Accept/decline acknowledgement
to a shipment tender (EDI204)
sent by a transportation
carrier via electronic data
interchange
EDI214 transaction Shipment status notification
sent by a transportation
carrier via electronic data
interchange
 SAP TMS Implementation 111

EM Event Manager; refers to SAP’s

SCEM
ERP Enterprise resource planning
Event Manager refers to SAP’s SCEM
GUI graphic user interface
IW Information Warehouse;
customized data repository
J2EE Java 2 Enterprise Edition
Load Builder System that optimizes the
planned production schedule and
the inventory availability to
build discrete shippable
vehicles
Manugistics Software company that produces
the transportation management
system which includes NetWorks
Transport and NetWorks Carrier
modules
OMS order management system
NetWorks Carrier Manugistics Web-based tool for
communication with
transportation carriers
NetWorks Transport Manugistics carrier selection
module
Oracle relational database management
system produced by Oracle
PPDS production planning and
detailed scheduling
PMO program management office
PROD production system environment
QA quality assurance, or testing,
system environment
R/3 & ECC Both terms refer to the SAP
enterprise resource planning
(ERP) module that is used for
financial management and
business execution. ECC is the
upgraded name for R/3.
rate/lane loader home-grown application for
loading rates and lanes into
the Manugistics TMS
SAP AG software company that produces
enterprise resource planning
and supply chain planning
software, e.g., ECC(R/3);
 SAP TMS Implementation 112
SCM(APO); SCEM(EM); WCL
SAP Enterprise Portal front end of the SAP NetWeaver
platform
SAP NetWeaver serves as an integration layer
that can host business
applications
SCEM SAP Supply Chain Event
Management; used
interchangeable with the term
EM and Event Manager
SCM & APO Both terms refer to the SAP
planning module that is used
for planning production and
transportation carrier
optimization. SCM is the
upgraded name for APO.
SME subject matter expert
SNP supply network planning
TMS (in context of this paper) transportation management
system; system used to plan and
manage the distribution of
finished goods to wholesale
customers and the return of
reusable packaging materials
and dunnage, the items used to
protect the finished goods
during shipment.
TPVS SAP Transportation Planning and
Vehicle Scheduling application;
part of the SCM/APO planning
module
TSP transportation service provider
UAT user acceptance testing
WCL SAP Web Communications Layer;
refers to the Web interface
that sits on the SAP Event
Manager
WM webMethods middleware
 SAP TMS Implementation 113

Appendix B: USEvolve Project Team Management Structure

Role Responsibilities
Business Partner Owner • Owns Business Case benefits realization.
• Ensures business resources are available for project and
accountable to project.

Sets direction for the project

• Drives buy-in of project scope and future state solution
with process advisory team and executive steering team.
• Set priorities between projects.
• Determine priorities between scope, quality, time, cost &
customer satisfaction.

Escalation path for issue resolution

• Resolve conflicts that extend beyond the teams control.
• Removes barriers for project team to ensure success of
the project.

Delivery of APO Upgrade/Leverage business case

• Business Case Development (Business needs and benefits),
communication and approval.

Program execution
• Owns execution and reporting of ongoing business
benefits.
• Gathers project support from all stakeholder areas.
• Solicit business resources for the project.
• Champion the cause and remove barriers.
 SAP TMS Implementation 114

IT Solution Delivery • Ultimately responsible for entire business solution (business and IT
portions).
Lead
Sets direction for the project
• Keep the project focused.

Approves final project plan

• Provide the project team with time to plan.

Delivery of APO Upgrade/Leverage business case

• Approves Planning and Analysis, Design, Build, and
Implement phases of APO Upgrade/Leverage program.

Program execution
• Sets overall program direction for project resources.
• Ensure overall project plan meets business objectives.
• Provides clarity of roles and responsibilities for the
leadership team of APO Leverage/Upgrade program.
• Owns project scorecard and project metrics.
• Reports APO Upgrade/Leverage program status to project
chair, process advisory team.
• Sets expectations with process owner team members.
• Provides on-boarding for new process owner members.
• Consolidate issues and action items for the process
owners meeting.
• On time/On budget for the project budget.

Issue resolution
• Resolve project issues.
• Identify critical path issues that emerge as unresolved.
• Escalates unresolved issues, scope changes and budget concerns for
the APO Upgrade and Leverage project.
 SAP TMS Implementation 115

Project Sponsor
Drive the scope and design of future state solution
• Drive definition of business requirements.
• Sets direction and expectations for Business Process
design with APO Upgrade/Leverage project team.
• Ensures business process design meets business
requirements.

Drive final approvals.

• Drive testing and acceptance of future state solution.
• Final approval of business requirements.
• Give final signoff and approval of all processes,
including tool customizations and process workarounds.
• Approve design and scope of Planning and Analysis phase
of project.

Drive change management related to internal and external stakeholders

• Lead communications, change management and issues

resolution in his/her processes to internal and external
stakeholders.
• Obtains, schedules business resources required by the
project.
• Provides resource support for implementation and
production support.
• Provide calendar time to the project.
• Act as second tier for issue resolution, suggesting
elevation to process owner advisory group if necessary.
• Communicate decisions to key stakeholders, program
sponsors, and other involved parties.
• Reaffirm that all decisions are considered binding and
final.

Drive benefits
Owns execution and reporting of ongoing business
benefits from the project.
 SAP TMS Implementation 116
• Understand the overall enterprise view of various
Business Partner projects and their inter-dependencies from the business
perspective.
• Ensure all business requirements are captured and
represented in the business case.
• Participate in project approach and review sessions as
determined by the PM.
• Stage gate reviewer for Analysis deliverables, and other
deliverables going forward.
• Provide overview and sign-off on the developed business
case and communicate and sell its content to stakeholders
and IT operating committee members.
• General consulting/thought leadership for the various
projects needs.
• Drives I/T Business Case review and approval.
• Ensures that the projects being delivered by the PMO are
guided by BBC approved business strategies and priorities
• Monitoring of annual IT financial plan - Oversight,
guidance, and barrier removal.
• Executive decisions on program scope and scope changes
(PCRs) based upon the parameters that require escalation
to the I/T Operating Committee.
• Executive decisions on program and project risks & issues
based upon the parameters that require escalation to the
I/T Operating Committee.
• Owns the Quarterly Prioritization Process (ensuring
proper quarter sequencing, and I/T processes adhered).

IT Lead • Lead design activities. Responsible for the ultimate design of the project
work product (application, system, processes)
• Monitors, reviews and assists with system configuration.
Configuration of SAP Enterprise Portal, documentation of
configuration and unit testing configuration.
• Identifies and ensures completion of functional specifications for all
authorizations, reports, interfaces, conversions, and enhancements.
• Ensures that result/output of all enhancements,
interfaces, conversions, and reports meet business needs
and use best practices in respective areas. Responsible
for functional design documentation working with onsite
developers.
• Ensures development of adequate configuration support plan.
• Ensures adherence to PMO methodology including stage gates.
• Reviews and approves test plans (functional and
technical) to ensure integrity and quality of production
system.
• Manages business demands in the sandbox environment.
• Acts as primary contact for escalating functional and
technical issues related to the sandbox environment.
• Participate in business process mapping.
• Monitor development efforts for all enhancements,
interfaces, conversions, reports and forms.
• Assist I.T. Teams as needed to gain understanding of
business and performance needs and design points.
• Assist with Organization readiness for go-live.
 SAP TMS Implementation 117

Project Manager
Ensure use of CDM Stage Gate methodology
• Defines and gains approval for project management
standards and procedures.
• Defines and gains approval for Project Management Process
Design.
• Aligns project plan to ensure that the Feasibility,
Development and Implementation phases are planned
appropriately.
• Conduct formal reviews at the completion of each phase.
• Provide guidance to project team on Stage Gate
methodology.

On time / On budget delivery of project

• Acts as the advisor to all team members regarding Corp
Development Methodology Stage Gate deliverables and
Project Management discipline (schedule, risk, resource,
etc.)
• Is responsible for facilitating development of an
integrated project plan that is complete, actionable and
valid with respect to tasks, work effort, timeline and
resources.
• Responsible for APO Upgrade/Leverage PMO deliverables.
• Ensures consistency for all APO Upgrade/Leverage project
deliverables in accordance with APO Upgrade/Leverage
program project schedule and CDM methodology.
• Is responsible for utilizing the Project Evolution Issues Management process
that enables visibility, communication, progress tracking, escalation and
closure.
• Is responsible for management of project scope via the established PCR
process.
• Is responsible for Project Status Reports that are credible and provide
sufficient information to know where the project stands.
• Is responsible for escalating issues to team leads and beyond (as
appropriate) for resolution. Escalates issues, scope change requests, budget
concerns, etc. to project owners for resolution.
• Schedules APO Upgrade/Leverage resources.
� Ensure that the technical requirements for the system are
Lead Architect met.
� Ensure technical design is in accordance with the
strategic BBC Company architecture plan.
� Ensure that the technical design is appropriate and that
the design will support future system upgrades
� Be responsible for taking immediate corrective action in
case of deviation.
� Ensure adherence to CDM standards.
� Escalated unresolved issues, scope change requests.
� Identifies integration points between projects.

Source: BBC Company Documents

 SAP TMS Implementation 118

Appendix C: Analysis

Analysis documentation is attached as a separate electronic

file: TMS Replacement Analysis v 04

 SAP TMS Implementation 119

Appendix D: Interview Notes

Interview with System Developer1:

TMS Replacement (EM, WCL and TPVS)

March 13, 2009

Overview:
A one-on-one interview was conducted with the EM System
Developer1 (EM Dev1). During the SAP Upgrade/TMS replacement
project, he was the BBC Company’s IT resource responsible for
the development and configuration of Event Manager to include
the WCL; the other EM system developer (EM Dev2) was a
consultant.

The interview lasted approximately one hour. Background

regarding the purpose of the case study was reviewed with EM
Dev1 at the beginning of the session. He understood and agreed
to the fact that the information he shared would be utilized and
quoted in the formal paper related to the case study and that
his name and the company’s name would not be disclosed. The
purpose of the interview and the case study was explained to EM
Dev1-- to better understand how the project was organized, if
the root cause of some of the go-live issues had been found, and
to identify specific learning could be applied to other
implementations of this particular system or other system
implementations in general.

An overview of the method of analysis utilized thus far was

also disclosed:
• reviewed the documentation of the project’s SharePoint site
• reviewed and categorized the HELP Desk Tickets created

during the 6-week production support phase (go-live to

hand-off as normal system maintenance)

• analyzed the HELP Desk Tickets in relation to the defined

business requirement, the defect log and the enhancements
that were identified for the enhancement phase following
the production support time period
• this interview was another iteration in the project
analysis as there were many unanswered questions from the
documentation

He was asked to share his knowledge and insights related to

the project. Interview questions were prepared in advance to
use as necessary to lead the conversation, but the goal was to
understand the issues from his perspective and his role in the
 SAP TMS Implementation 120
project. The interviewer allowed the conversation to occur,
asking pertinent questions that had not yet been answered.

Project organizational structure:

The upgrade/TMS replacement project was part of the BBC
Company’s PMO portfolio. The project included an executive
team, the steering committee and the project team.

There was a PMO project manager who was responsible for

managing the overall project. The TMS replacement project was
set up as a sub-project under the larger one. There were
additional project managers assigned to specific components of
the project. For example, there was a project manager assigned
to the TMS replacement component of the project from the BBC
Company. His normal role was as a liaison between the business
and the IT organizations.

Most other IT resources who participated on the project

were BBC Company employees, SAP consultants or EDS consultants.
There were a few consultants from other third-party companies.
During the project, HP was selected to replace EDS as the IT
strategic partner. EDS and HP eventually became one
organization. Many of the IT employees of the BBC Company were
affected by job eliminations. Many of them, including EM Dev1,
transferred to HP and are continuing to do the same work/role as
an HP consultant for BBC Company.

TMS replacement portion of the project, there were several

IT resources assigned and one TMS business lead:

� project managers (2)

o BBC Business Liaison
o EDS Technical
� solution designers (2)

• one for the R/3 (ECC) module (BBC)

• one for the APO (SCM) module (BBC)

� EM system development/configuration (2)

o EMDev1 (BBC)
o EMDev2 (SAP)
� TPVS system development/configuration
o TPVSDev1 (BBC)
o TPVSDev2 (ILOG-focused on the load creation module)
o SAP resources as required
� ABAP Team (3 plus off-shore as required)
� webMethods
 SAP TMS Implementation 121
� Logistics Business Lead (BBC) – first representative left
mid-way through the project

There was some overlap of resources. EM Dev1 was also

responsible for the upgrade of other portions of the APO module
that included process orders and the plant scheduling
functionality. As a result, he was pulled in more than one
direction at times. The sequence of the processes sometimes
affected the prioritization of work. Because the TMS and other
functions were dependent upon the success of the process orders
and the plant scheduling, it was necessary to focus on those
areas first.

Project Methodology
A waterfall methodology “with a BBC Company twist” was
followed. BBC Company utilizes a “stage-gate” process. The
project is approved from one stage gate to another; however,
there is not a “hard stop” for each stage. In many instances,
we keep moving to the next stage before completing everything in
the previous stage.

EM Dev1 believes the company’s project execution is good.

There is a tendency to go live on the fly.

Training in the methodology was ½-1 day of training. The

company culture, as a whole, is not disciplined with regard to
structure and documentation.

HELP Desk Tickets/Go-Live

From his perspective, many of the HELP Desk Tickets
submitted during the production support phase represented new
business requirements. He felt the business requirements
defined in the project were not at a low enough level of detail.
They did not necessarily represent the “day-to-day” business
requirements.

EM/WCL Design Methodology

Based on the comment that the business requirements did not
define the day-to-day needs, he was asked what methodology the
team used to configure the system. He indicated that several of
the IT resources were knowledgeable regarding the business based
on previous experience with the Logistics Department--(TPVS
Dev1, EM Dev1, and Solution Designer1). They had some input
from the Logistics Department Business Lead. The Business Lead
then left t he BBC Company to pursue a different job. A new
Business Lead stepped into the role but had very little
 SAP TMS Implementation 122
training/knowledge transfer related to the project before the
original lead left the company..

One of the goals related to the TMS replacement project was

to reduce the amount of customization and push the Logistics
team to use more standardized processes. While the software was
new, the direction was to reduce customization to save money.
The IT Team’s goal was to provide a “vanilla” version of EM/TPVS
and “shoe horn” the business processes into the system—make the
business fit the system process. The leadership felt that
whatever didn’t work once the business users started reviewing
different scenarios would be customized as required. The
business processes maps that had been developed during the
initial system implementation about five years ago were reviewed
and modified by the project team. There were very few
modifications to the business process maps.

Meetings were scheduled by the project team to present the

system to the internal business users and get feedback from
them. The meetings were not as successful as planned. The
business users had difficulty attending the meetings due to
timing of the project. BBC was experiencing the busy season
during the project development and testing phases. The
attendance at meetings was low. Different users attended the
meetings—alternating so others could keep the business running.
The user(s) attending would provide their thoughts on how the
system should be configured. Someone else would later ask that
it be changed. No consensus because it was not a “group”
decision. Some of the user’s needs were not identified during
the meetings.

Overall, there was not enough user involvement in the

design or the testing of the new TMS. Not always the correct
users for the design/testing needs, not enough user input,
different requirements by different users. A definite gap in
the knowledge transfer when the first business lead left and
passed the responsibility to the next one.

Another issue related to the system design and development

was that the EM tool was very new. The system was new to the
BBC IT resources. They were learning the new software on a fast
track. It was extremely difficult to find a resource outside of
the company with any kind of knowledge and experience with the
EM/WCL.

TPVS/WCL/EM Test vs Production Versions?

When asked for insights from a technical perspective
regarding differences in the system that was delivered in
 SAP TMS Implementation 123
production vs the system that was tested, EM Dev1 provided a
couple of findings:

System Performance – TPVS, WCL, EM

System performance was extremely slow at go-live.
There was not an effective way to stress test the new
system components.

There are three different environments (SAP instances)

:
o Development (DEV) - used for initial testing.
It is not fully integrated, so limited in
testing capabilities
o Test (TEST) – integrated copy of the SAP
Production, but is a snapshot of the production
system at a given time. With some exceptions,
can do end-to-end testing
o Production (PROD) – fully integrated system

System instances are not in synch. A refresh takes

four complete days to bring the system down and back up.
The cost is extremely high. Given the time to copy the
production system (refresh TEST), the systems will never be
completely in synch.

TEST system
o Different data set than PROD (older version of
production data, less data)
o Different user base (fewer, different access
for some)
o Performance tends to be faster in TEST as a
result.
o Stress tests were performed prior to go live.
Thorough stress tests were performed on the ECC
portion since it is the company’s priority
system. Minimal stress testing completed for
the TPVS/EM. Day 1 – slow performance for all
users. Process of tendering loads took hours
rather than minutes. User queries in WCL were
extremely slow, often timing out before the
result was returned. Had not tested the impact
of all of the users – 100+ external carrier
users and internal users.

Configuration changes – moving from DEV to TEST to

PROD
 SAP TMS Implementation 124
BBC Company uses Peregrine to track “transports.” A
request for change (RFC) is created that tracks the changes
to be made. Theoretically, the sequence of movement is
from DEV to TEST and finally to PROD. The changes are
tested each time.

At go-live, some transports were created directly in

PROD without going through the normal sequence. Whenever a
transport is created, it locks objects in the system. The
objects have to be “released” before other transports can
be moved/applied. Some of the objects were not released,
thus other transports did not get applied properly as they
were moved from TEST to PROD.

This left the systems in a different “state”—thus the

difference between what the system looked like and how it
functioned prior to go-live and just after.

EM/WCL Technology
The user interface of EM is set up in the SAP Portal, which
uses the NetWeaver. The WCL uses a different platform—the same
one that was used for the SRM application.

Documentation
In response to the observation that many documents were
missing or incomplete on the project’s SharePoint site, EM DEV1
indicated that, in general, BBC Company is not disciplined in
updating documents. While there is a methodology that BBC
Company subscribes to, every project seems to have different
standards. He felt that some of the documentation was “limited”
because the IT resources are generally not technical writers and
have to prioritize the delivery of the system over
documentation.

The defect log was not updated for most of the TMS issues
that were encountered during testing. When asked what the
criteria were for creating a defect, EM Dev1 indicated that it
was not utilized as designed. The design of the defect log
process, by its nature, discourages logging issues to some
extent. When a defect is logged, it generally gets assigned
back to the same technical resource to solve within a time
period. The resource was then expected to update the
documentation. Most of the changes to configuration were done
in the testing phase, but were not well documented. Many
changes were made in DEV or TEST while a user was present and
could validate the changes.
 SAP TMS Implementation 125
Following the merger of BBC Company and XXX Company, a new
methodology and documentation process has been defined and
adopted. It focuses heavily on documentation. From the
perspective of EM Dev1, there needs to be some balance that
allows a technical resource with specific skill sets to utilize
their skills rather than spending so much time documenting.
Having additional resources specifically for the documentation
efforts would be helpful.

Lessons Learned – Recommendations for implementing this

System for a Different company?
1) Set up the TMS replacement project as a separate, focused
project rather than having it as sub-project of the larger
upgrade. This would allow technical resources to focus
their efforts rather than being pulled in different
directions.
2) Technical resources: Ensure there is a resource with
experience in EM/WCL so that there is less time required in
the learning mode.
3) Define a methodology for the project, follow it and enforce
its use:
a. Ensure you have resources with the following skills
i. Process expert
ii. Technical expert
iii. Documentation expert
b. Requirements gathering needs to be focused and
detailed with the right business users, consistent
user input, proper identification of hard and soft
constraints, and prioritization of requirements when
there are conflicting requirements or to determine
which requirements/issues receive the resource time.
c. Utilize UML modeling.
d. Organizational understanding that there is no such
thing as a purely “technical upgrade.” End users are
impacted by changes to the system. The importance of
user involvement and the potential impact to users
should not be underestimated.
e. Organization understanding that change management
involves more than training.
4) Develop a permission/approval process for system

configuration changes. Resist the temptation to make a

change without a consensus of the appropriate parties.

At the end of the interview, EM Dev1 was thanked for his

time and his willingness to share his insights related to the
TMS Replacement Project. It was reinforced that his identity
 SAP TMS Implementation 126
would be kept confidential and that the BBC Company’s name would
also not be disclosed in the case study.
 SAP TMS Implementation 127

Interview with System Developer2:

TMS Replacement (EM, WCL and TPVS)

March 27, 2009

Overview:
A telephone interview was conducted with the EM System
Developer2 (EM Dev2). During the SAP Upgrade/TMS replacement
project, he was the consultant responsible for the development
and configuration of Event Manager to include the WCL; the other
EM system developer (EM Dev1) was a BBC Company employee from
the IT Department.

The interview lasted approximately half an hour.

Background regarding the purpose of the case study was emailed
to the EM Dev2 when the interview was requested. EM Dev2
initially declined the interview as he was concerned about
confidentiality and a conflict of interest. Subsequent to the
BBC Company project, EM Dev2 worked on a similar project for a
competitor of BBC Company. He was assured that the interview
would not involve any information related to the competitor
company. He agreed to share his ideas related to the BBC
Company’s project and what lessons were learned from the
project—what he would do differently if he were to implement a
similar project. He understood and agreed to the fact that the
information he shared would be utilized and quoted in the formal
paper related to the case study and that his name and the
company’s name would not be disclosed. The purpose of the
interview and the case study was explained to EM Dev2-- to
better understand how the project was organized, to determine if
the root cause of some of the go-live issues had been found, and
to identify specific learning could be applied to other
implementations of this particular system or other system
implementations in general.

An overview of the method of analysis utilized thus far was

also disclosed:
• reviewed the documentation of the project’s SharePoint site
• reviewed and categorized the HELP Desk Tickets created
during the 6-week production support phase (go-live to
hand-off as normal system maintenance)
• analyzed the HELP Desk Tickets in relation to the defined
business requirement, the defect log and the enhancements
that were identified for the enhancement phase following
the production support time period
• interviewed EM Dev1
 SAP TMS Implementation 128
• this interview was another iteration in the project
analysis as there were many unanswered questions from the
documentation

He was asked to share his knowledge and insights related to

the project. Interview questions were prepared in advance to
use as necessary to lead the conversation, but the goal was to
understand the issues from his perspective and his role in the
project. The interviewer allowed the conversation to occur,
asking pertinent questions as the conversation progressed.

Project organizational structure:

EM Dev2 was a consultant hired through a third-party IT
consulting firm. He reported to the APO Solution Design Manager
and was primarily responsible for the configuration/design of
Event Manager and the WCL. The system had to support EDI
transactions to/from the transportation carriers. The EDI
transactions – EDI204, EDI990 and EDI214s—were the shipment
tendering information to the transportation carriers and
subsequent responses accepting/rejecting the tender and status
updates regarding a shipment. Carriers could submit the
transactions electronically through a value-added network (VAN)
service or utilize Web-based portal to receive and transmit the
transactions. Because the EM/WCL systems interfaced with other
systems, EM Dev2 had to have knowledge of and work with the
other technical resources wherever the systems interfaced.

HELP Desk Tickets/Go-Live Issues

EM Dev2 felt that the primary issue at go-live was related
to the system performance. The version of WCL used was an older
version (4.1) and used Java. It was not designed for the volume
of transactions and the number of system users BBC Company
interfaced with at one time. There was never a stress test that
measured the system impact of so many users at one time. The QA
system was not designed for that type of testing.

There is a newer version (5.1) that is based on a different

platform – ABAP-- that would have better supported the
performance requirements.

The testing that was done was primarily unit testing and
functionality testing. EM Dev2 felt there was not enough of
integration and system stress testing.

EM Dev2 indicated that the upgrade project was very

difficult. BBC Company was not only performing a technical
 SAP TMS Implementation 129
upgrade of ECC (R/3) and SCM (APO), it was also upgrading Oracle
and replacing the transportation management system within the
same U.S. project. “There were too many moving parts,” he
said. He felt the project would have been more successful if
it had been organized as 3 or 4 separate projects to provide the
appropriate level of attention/focus to each one. The TMS
Replacement project was a big project by itself and should have
been treated as such. While he was dedicated to the EM/WCL
systems, other resources had responsibilities that touched more
than one of the project workstreams.

He indicated that there were a limited number of technical

resources who could assist with the EM/WCL development besides
EM Dev1 and him (Solution Designer and one other consultant ).
The other technical resources who worked on the EM/WCL systems
had responsibilities that extended beyond EM/WCL to other system
functionality.

EM/WCL Design Methodology

The design process began with the business requirements;
however, the requirements did not provide enough detail. The
business lead was involved in the design of EM/WCL early;
however, that business representative left the company. The new
business lead replacement was involved early in the project, but
was not one of the primary system users. A meeting was held
with the business users to gather more information. Based on
the business user involvement later in the project, EM Dev2 felt
it would have been beneficial to the project, from a design
perspective, to have at least one of the primary business users
actively involved earlier in the project. By the time the
primary business users had an opportunity to test the new system
it was too late to incorporate many of their requests for system
design changes due to time limitations.

EM Dev2 indicated that most of the testing with carriers

was done with one large carrier. He suggested that involving
more carriers in the testing of the new system would have been
helpful.

TPVS/WCL/EM Test vs Production Versions?

When asked for insights from a technical perspective
regarding differences in the system that was delivered in
production vs the system that was tested, EM Dev2 said he
believed it was a performance issue. When asked about the “
transport” process, he did not think this was a factor.
 SAP TMS Implementation 130

Documentation
In response to the observation that many documents were
missing or incomplete on the project’s SharePoint site followed
by a question of whether the technical documentation was
actually stored in a different location, EM DEV2 said the
SharePoint site was the location for all documentation; however,
the deadlines they faced caused them to prioritize the more
urgent system development over documentation. He said the
project could have utilized 1-2 more technical resources,
especially for the TPVS component. Issues with Load Builder and
TPVS caused delays in the work related to EM/WCL. The resource
responsible for TPVS was unable to focus on TPVS due to issues
with the Load Builder. The “project casualty” was integrated
testing. It could not be done because the other system
components were not yet working.

Lessons Learned – Recommendations for implementing this

system for a different company
5) Conduct carrier testing earlier in the project with more
carriers
6) Get the right user(s) involved early in the project to
gather user knowledge and determine design requirements.
7) Set up the project as a stand-alone project with one
project plan and dedicated resources.
8) Conduct comprehensive, integrated testing.
9) Having a good business user team that did not panic during
the go-live phase was helpful. The business users did a
great job of prioritizing the issues and assisting with the
carrier users by fielding phone calls, troubleshooting the
issues encountered by the carriers, and helping to
categorize the problems.

At the end of the interview, EM Dev2 was thanked for his

time and his willingness to share his insights related to the
TMS Replacement Project. It was reinforced that his identity
would be kept confidential and that the BBC Company’s name would
also not be disclosed in the case study.
 SAP TMS Implementation 131
Interview with BusUser1:

TMS Replacement (EM, WCL and TPVS)

March 27, 2009

Overview:
A telephone interview was conducted with Business User 1
(BusUser1), who is one of the transportation planners in the
Logistics department. During the SAP Upgrade/TMS replacement
project, BusUser1 performed system testing and carrier training
related to the WCL during the development stage of the project.
In addition, he handled a large percentage of the calls from
carriers during the “go-live” phase of the project. He was
later instrumental in defining the business requirements and
testing the solutions during the enhancement phase of the
project.

The interview lasted approximately fifteen minutes.

Background regarding the purpose of the case study was disclosed
to BusUser1. He understood and agreed to the fact that the
information he shared would be utilized and quoted in the formal
paper related to the case study and that his name and the
company’s name would not be disclosed. The purpose of the
interview was to gather his ideas, based on his experience as a
business user during the upgrade/TMS replacement project,
regarding the major issues and lessons learned.

An overview of the method of analysis utilized thus far was

also disclosed:
• reviewed the documentation of the project’s SharePoint site
• reviewed and categorized the HELP Desk Tickets created
during the 6-week production support phase (go-live to
hand-off as normal system maintenance)
• analyzed the HELP Desk Tickets in relation to the defined
business requirement, the defect log and the enhancements
that were identified for the enhancement phase following
the production support time period
• interviewed EM Dev1 and EM Dev2
• this interview was another iteration in the project
analysis as there were many unanswered questions from the
documentation

He was asked to share his knowledge and insights related to

the project. Interview questions were prepared in advance to
use as necessary to lead the conversation, but the goal was to
understand the issues from his perspective and his role in the
project. The interviewer allowed the conversation to occur,
asking pertinent questions as the conversation progressed.
 SAP TMS Implementation 132

Biggest Issues

The biggest issue was the lack of structured testing. It

was not thorough. Every time we tried to do testing, it seemed
as if there was an issue with the data or the system. There was
a point where we had to go live and EM/WCL were missing pieces.
Even if we’d had successful testing, we probably would have run
out of time before the go-live, but could have had a better
chance to identify and resolve more of the issues prior to go-
live.

BusUser1 was pretty comfortable with the overall system

functionality at go-live because he conducted training classes
for carriers.

The TMS replacement involved APO and TPVS. Those

applications seemed more “ready” than EM/WCL. Overall, he felt
that the transportation issues were not as much of a problem as
the issues encountered with the Load Builder application. It
had major issues that had to be resolved in order to keep the
business running. We had some manual workarounds we could
perform.

From an overall SAP-specific viewpoint, it was difficult to

get data for testing. It was never clear who was responsible
for setting it up. There was a limited amount of test data.
There were multiple groups using the same data. Bottom line—
there was a lot of productive time lost when trying to test.

Conducting the training was very difficult because you were

never certain the data would be available for each class. If
another group ran a process, it might impact your data.

What would you have done differently or would you do

differently if you to do over?
The system developer(s) should spend time sitting next to
the business users to understand their work and the business
requirements. He said he never saw the business requirements
for the project. He participated in a meeting with the system
developer (EM Dev2) and the project lead for the business early
in the project to help identify the business requirements
related to the portal tool (WCL). It was a long time (several
months) before he saw the system prototype. He did not see any
documentation related to the user input. There were a number
of meetings where the users were supposed to see the new WCL,
 SAP TMS Implementation 133
but the meetings were not very successful. There was always a
problem with the data/system.

At the end of the interview, BusUser1 was thanked for his

time and his willingness to share his insights related to the
TMS Replacement Project. It was reinforced that his identity
would be kept confidential and that the BBC Company’s name would
also not be disclosed in the case study.
 SAP TMS Implementation 134

Prepared Interview Questions (if required)

Project background and purpose:

• Looking for information on what can be learned from
the implementation of TPVS and especially EM. What
could be applied by others implementing these
systems that would help with an efficient design,
development, testing, and deployment process?
• Reviewed documentation on the SP site
• Reviewed and categorized HELP Desk Tickets (6-weeks
prod support)
• Analyzed TMS HELP Desk Tickets in relation to
defined business requirements, the defect log and
the enhancements that were planned
• Found that there are many questions that were not
answered from the documentation

Project Structure

An RFP was issued for a third-party company to manage the

Project Evolution upgrade/TMS replacement project. What company

was hired? (SAP, HP, other?)

What project methodology was followed?

How was the overall project structured from an

organizational perspective?

PMO (Global vs US)

 SAP TMS Implementation 135

Steering Committee

Project Team

What was the organizational structure of the TMS project

team?

How were the project team and technical resources assigned?

By skill set or by functional area within SAP (DP, SNP, PPDS,

TPVS, EM)?

Were technical resources assigned to more than area of the

project?

What were your roles and responsibilities for this project?

Did the organizational structure change during different

phases of the project?

What was the system design process for TPVS and EM?

There were business requirements defined for the TMS

system. How were they utilized in the system design process?

 SAP TMS Implementation 136

How were users involved in the design of TPVS and EM?

How were users involved in the testing of TPVS and EM?

At “go-live”, the production EM system looked and behaved

very differently from the test version of EM. There were a high

number of issues related to EM reported to the HELP Desk. What

kind of insights can you provide from a technical perspective as

to what may have caused the differences and the issues? (HELP

Desk Ticket List for Reference)

Was the SAP Solution Manager System utilized for this

project?

Can you provide some background as to how the system

changes were managed – movement from DEV to TEST to PROD? Some

of the explanation I have heard is that the transport system

caused part of the problem. Can you help me understand that

process and how it may have failed?

Validate system context diagram .

 SAP TMS Implementation 137

Technology for EM

We are using the SAP Portal for WCL component of EM. Does

that use NetWeaver?

What were the biggest challenges in designing/developing

EM?

Documentation

As I reviewed the documentation on the project SP site, I

found:
• Many documents missing
• Many documents incomplete

Did you and other technical resources document the project

elsewhere? If so, what was the process for documentation?

Defect log: What were the criteria for entering a defect?

(Many of the issues encountered during testing were not in the

defect log and re-appeared in production.) How were the changes

in testing documented and moved to PROD?

 SAP TMS Implementation 138

Lessons Learned

Based on your experience with this upgrade/TMS replacement

project, what would you do differently if you were implementing

a new SAP TMS system for a different company?

Design/testing

Project Management

Resources

Business Involvement

Technical

Other

Any other thoughts you think might be helpful to others

considering implementing TPVS or EM?