Professional Documents
Culture Documents
Overview of XXP and Its SAP Implementation
Overview of XXP and Its SAP Implementation
1
Figure 1. XXP Modernized Services
Av
Su labi
ai
De
pp lity
ma
ly (fu
(n tu
nd
ow re
) )
End User
Distribution
Finance Depot (Battalion,
(from all etc.)
actors)
AMC Finance
Staff Product Support and Sustainment are
performed at the PDC, COOP, and NOC.
In order to perform various services, each facility is broken down into work or cost centers. Personnel
within a work center are divided into resource groups (kind of like departments). Their activities are
described in routings or task lists (essentially procedures), which describe how to assemble a product,
overhaul a product, put together a shipment, etc. Every product is defined by a bill of materials, which
lists the parts which go into assembly of that product. Those products and/or parts are in turn cited by
the routings. These relationships are shown in Figure 2. A plant may be identified by its DODAAC code.
Parts may also be identified by their National Stock Number (NSN).
Work Center
has (Cost Center) perfor
ms
Plant y
man co
(Facility) ns
of ists Routing
(Task List)
Resource
ed
Groups duc
Product o
is
de pr by
is
f
by ined
Bill of Materials has Part Number
(BOM) many (NIIN)
2
XXP Architecture
The XXP solution (a euphemism for the system developed and used to provide the services mentioned
above) is based on conversion of two huge legacy information systems into an integrated SAP R/3-based
system. To allow for scalability and help reliability, the solution is structured in a multi-tier client-server
manner, where most of the server side is shown in Figure 3.
Each type of function is given its own dedicated servers, so that the number of servers for any function
can be easily changed to accommodate more users and more data. The number of servers of each type
ranges from two (for the database servers), to over a hundred. The system is designed to handle a few
terabytes of active data, and tens of thousands of users.
Database servers, which house the online data and the central instance of R/3
Servers to run the main SAP modules APO, BW, and KW
Backup servers and a tape library
Terminal servers, for clients who need terminal access across the government’s private network
Application servers, for all the other SAP components, and other commercial software
Web servers, since many clients will access the system across an internet protocol network
SeeBeyond servers, which manage the interfaces to external systems
Network servers, which run Cisco software to manage the network configuration
Security servers, to validate users and manage security certificates
For this system, SAP runs on top of an Oracle database, and the whole mess uses Sun servers connected
with Gigabit Ethernet on fiber optic cables and Cisco networking equipment. A firewall within the
network prevents outside users from directly accessing the database, backup, and SAP servers.
iPlanet Web
Internet Portal, Citrix
Application Internal
Security, and Terminal
Servers Firewall
SeeBeyond Servers
Servers
Ext. Interfaces
3
External interfaces are handled using middleware called SeeBeyond. SeeBeyond acts as a central point
of contact for all external systems. Messages intended for those systems are packaged in an IDOC
(intermediate document). The IDOC tells SeeBeyond what kind of message it is (content format) and
where it needs to go (routing information). SeeBeyond then unwraps the IDOC, and sends the message
to the correct external system. This relationship is shown in Figure 4. In this case, the document is a
Document Identifier Code (DIC) for some transaction, and the external system is the Defense Automatic
Address System Center (DAASC). The reverse process is then followed when the external system needs
to send information to SAP.
IDOC
DIC DIC
LMP (SAP) SeeBeyond DAASC
- Defines DIC - Extracts DIC (Trading Partner)
- Wraps DIC in IDOC - Sends to DAASC - Processes DIC
Scenarios
Each way in which someone might need to perform a function on XXP is defined using a scenario.
There are three types of scenarios.
Integrated Scenario (IS) – a series of many steps which follows some activity from start to finish;
similar to a use case.
Independent Scenario (IND) – a short set of steps which perform a useful function, but generally
isn’t a complete user activity like an integrated scenario.
Process Scenario (SCN) – a task which is generally one step in a larger integrated or independent
scenario.
Like use cases, IS and IND scenarios form the basis for all levels of integration and system testing, and
they are used to manage the contents of each deployment (release). In other words, the functions to be
implemented with each deployment are defined by the scenarios which will be implemented.
4
Technical Objects
Each piece of code, screen, report, table, or other code-related thing in SAP is called a technical object
(TO). The connections among scenarios and technical objects are shown in Figure 5. Technical objects
can be standard or custom.
Standard (or vanilla or SAP native) objects are defined primarily by SAP. They are customized
for use on a particular system by the activity called SAP Configuration. They include all of the
standard screens and transactions which have a two-letter, two-digit name format, like MM02,
CF28, etc. Changes to standard objects, beyond the predefined configurable options, is extremely
discouraged by SAP.
Custom objects are created by SAP development programmers using the ABAP language.
Pronounced “A-bop”, it is unique to SAP, but looks like a blend between Basic and Pascal. The
names of custom objects generally start with “Y” or “Z”, like the custom transactions ZFUND
and ZIGO.
o Some forms (FRM tech objects) are coded using a horrendous scripting language called
“SAPScript”. No one ever admits to knowing how to program in SAPScript.
Each type of scenario and object is described in Table 2, and their sources are described in Table 3. The
XXP portals merged on 3/10/2003, hence only one portal is shown.
Technical objects (TO) are the source code unit in SAP. There are dozens of types of technical objects,
with an elaborate naming convention to identify the type of each technical object. The types of objects
and scenarios are described in Table 4, along with an idea of how many of each are in the XXP system
so far.
83% of TO are INF, ISP, JOB, REP, TAB, TRX, and USX objects
17% of TO are all the other types (DTX, FRM, IDC, INP, MOD, MTC, OSS, OUT, RTN, SCR,
UTL, and WFL objects)
A technical object (“TO”) is a piece of custom programming that has been created to enhance the SAP
package, such as a custom report, interface, or user exit (special processing embedded into the standard
SAP code); a FIT object is a process scenario or set of business processes that users perform. The FIT
objects may or may not have custom programming (TOs) embedded within them.
Testing
The types of testing include:
5
Mock Go-Live
Process Trials
End-to-End (E2E) Tests
Interfaces
The interface objects (INF) are further defined by the Interface Configuration Database (ICDB), which
captures their physical connection characteristics, security needs, cutover needs, and point of contact.
Connection to each external interface is also defined by the Bridges and Uniques (B/U), which specifies
the communication format and contents of each physical interface.
6
White papers Discussion and analysis of issues Portal
Requirements
The Requirements Traceability Matrix (RTM) maps each requirement from its source to the SAP module
which will implement it (APO, MM, etc.) and to the CCSS application number or unique which used to
perform that function. It also identifies whether each process is manual or automated.
There might be a connection between the RTM and the BPML. For example, the RTM has “PERFORM
PARTS EXPLOSION”, which could correspond to the BPML’s “Change BOM Explosion Numbers”,
which is done in transaction MDSP.
The RTM maps the requirements sources, which include CONOPS, CSLA, RIA, and SBCCOM task
orders, SSF MS3, and the IDEF process model. There is no direct connection between the RTM and
scenarios or objects.
SAP Transactions
The transaction codes generally follow a two-letter, two-digit sequence (e.g. ‘MM02’). Prefixes FO
(Real Estate Management functions), MC (Logistics Information System (LIS) functions), and ME
(pertaining to procurement records) account for about 17% of the 2976 unique SAP transaction names,
while another 21% are from the list {CG, CJ, CO, FB, FM, IM, IW, KB, KK, V-, or VL}, with from 40
to 70 codes having each of those prefixes.
SAP Modules
SAP modules are discussed in the next section.
7
Figure 5. Scenario and Object Relationships
br
ea int
ks o
Deployment 1, 2, or 3
do
(or interim releases)
wn
or one
Tests
de
inclu y
re
ma
mo
use
BPML
eva sist
of ist
ev
ns
al
e
of
ua
co
requirements
te
list)
to s
p
ma
SAP
re
Integrated Independent Transaction la
to? ted
Scenario Scenario Codes ?
ISxxxx INDxxxx (nearly 3000
of them)
ar Requirements
con
ts
consists
of s rela ?
of
to?
of sts
Modules
i
ns
co
traces
from
Process Interface
consists Technical
Scenario Configuration
of Objects (TO)
SCNxxxx
%
Database
97
e
(ICDB)
ar
FIT
Requirements
on
Object
l
con hysica
rati
Sources
obje
INF
3%
figu
are
RPTxxxx,
cts
IFCxxxx,
and Interface support Bridges and
DTFxxxx Objects Uniques
8
Table 4. Scenario and Technical Object Types
9
SAP Modules
The structure of SAP is huge and complex. And to make it worse, they reuse acronyms in different parts
of the system (e.g. PP can be Production Planning or Project Planning).
SAP is composed of the core module, called R/3, and may use other modules called “bolt-ons” if your
system needs those functions. A web-based version of SAP is called “mySAP”, and it either lives as a
stand-alone system, or is supported by the full version of R/3. The structure and contents of mySAP and
SAP R/3 are shown in Figures 6 and 7, and the abbreviations are defined in Table 5. Other SAP and
XXP-related terms are defined in Table 6.
mySAP
E-procurement
CRM BI SCM
EBP
SEM KM BW APO
10
Figure 7. SAP Modules
SAP
Bolt-ons are labeled
in bold italics
Core R/3
Bolt-ons
System
MM APO BW PLM
CS Module PS
SD SNP BW
OM CPM
PP SEM
TEM BPS EHS
CO DS FI
PM
(see below)
CO
FI RE FM
PP
(see below)
PC PA
SL GL
MRP
OM CCA
AA AP
PLM
PCA CEL
AR
QM
Based on LearningGateway course
11
Table 5. SAP and mySAP Modules
12
Acronym Term Definition
OM Organizational Management Part of HR module
OM-CEL Cost element accounting Part of CO module
PA Profitability Analysis A bolt-on module within B&F team;
both cost- or account-based
PC Product cost controlling Part of CO module
PCA Profit Center Accounting Part of CO module – or is it FI?
PLM Product Lifecycle Management A bolt-on module within IBO team
PM Plant Maintenance Module within IBO team
PP Production Planning Part of APO module
PP Project Planning Module within IBO team
PS Project Systems Module within B&F team
QM Quality Management Module within IBO team
R&M Analytical Reporting and Team within R/3 (and XXP)
Performance Management
R/3 Real time three tiered Product name for SAP’s core functionality
RE Real Estate Part of FI and CO modules
SAP System, Application, Products Company who makes R/3 and
related systems.
SCM Supply Chain Management Part of mySAP
SCP Supply Chain Planning Team within R/3 (and XXP)
SD Sales & Distribution Module within A&D team
SEM Strategic Enterprise Management Bolt-on related to B&F team
SL ?????? Part of FI module
SNP Supply Network Planning Part of APO module
TEM Training & Event Management Part of HR module
TV or AA Asset Accounting Part of FI module
WM Warehouse Management Module within A&D team
13
Table 6. Other SAP or XXP Terms
14
Acronym Term Definition
MDR Master Data Record
MILSBILLS Military Standard Billing System Defined by DoD 4000.25-7-M
MILSTRAP Military Standard Transaction Defined by DoD 4000.25-2-M
Reporting and Accounting
Procedures
MILSTRIP Military Standard Requisitioning Defined by DoD 4000.25-1-M
and Issue Procedures
NOC Network Operations Center The main facility for developing fixes and new features for
XXP (MT)
O/P Ownership purpose Intended use of some stocked material
P&L Profit & Loss Type of statement generated by FI
PDC Primary Data Center The main production site for the system
PO Purchase Order
PRON Purchase Request Order Number
PT Process Trials Predefined system testing by end users
RIC
SDD Services Description Document A vision document for XXP, describing the scope and
approach for providing logistics services.
SDS Standard Depot System Legacy system
SIT System Integration Test Scenario test witnessed by customer
SSF MS3 Single Stock Fund Milestone 3 A major feature of XXP, not in the original scope of the
system.
SSO Single Sign-On Universal login
WIP Work in Process
15