Making the Case for a NASA Advanced Supply Chain Management Initiative

Edgar Zapata

National Aeronautics and Space Administration, Kennedy Space Center

Summary

From 2004 to 2007 a supply chain simulation project was undertaken at
the NASA Kennedy Space Center. The task was to create a discrete event
simulation, from a supply chain perspective, for the job of preparing,
processing and launching a space transportation system. Specifically,
the system and the supply chain to be represented was the crew carrying
system planned to replace the Space Shuttle. That system in development,
the Orion Ares I, has Shuttle derived elements, such as the use of a
reusable solid rocket booster (SRB). A companion cargo vehicle also
planned, completing a capability to be able to explore the Moon (or
beyond), would be the Ares V. Ares V development would start in earnest
in the early 2010's. Though many components of this proposed
dual-vehicle architecture are new, the basic supply chain, because the
system is Shuttle derived, would have many characteristics permitting
immediate study and analysis. Being Shuttle derived, the question was --
what insight could be gained about the future flow of information and
materials? Also, what could be learned about applying a discrete event
simulation to such a system?

While supply chain management is usually strictly associated with the
movement of materials along various steps of a process on the way to a
finished product and it's delivery to a customer, the usage here will
also encompass the necessary flow of information that permits the flow
of material. At the end of the 20^th^ century, as businesses became more
and more focused on narrower and narrower competencies, out-sourcing all
non-core activity, the flow of information between a company and it's
external partners became more sizable and hence more critical. Hence the
birth of supply chain management per se as distinguished from previous
management science or approaches. NASA, being an agency that outsources
about 90% of it's operating funds each year, and human space
transportation in specific, and the process/technology-driven focus that
dominates this NASA business base, can be shown to be ideal candidates
for applying supply chain thinking. In applying supply chain
perspectives to NASA and space flight numerous opportunities and
challenges surface, some lending immediate insight and others pointing
the way to further work. The case will be made here that an advanced
supply chain management initiative that addresses program policies and
practices not only offers opportunities for improvement, but that the
science of supply chain management is ideally suited to NASA and human
space flight. Avoiding the management fad of the month (or day), an
effort is made to present the ideas that flow from a supply chain
management perspective in as generic a way as possible, yet applicable
to the specific details of the NASA tactical situation at hand.

> "Strategy without tactics is the slowest route to victory. Tactics
> without strategy is the noise before defeat" ---Sun Tzu.

  ---------------------------------------------------- ----------------------------------------------------
  ![](media/image1.jpeg){width="2.482638888888889in"   ![](media/image2.png){width="1.1944444444444444in"
  height="1.8569444444444445in"}                       height="1.8555555555555556in"}

  The Orion Ares I crew vehicle.                       The Ares V cargo vehicle.
  ---------------------------------------------------- ----------------------------------------------------

#  Background

In tackling the creation from scratch of a discrete event simulation for
a supply chain that does not yet fully exist for a space transportation
system that is on the drawing boards and prototype stage, it was first
necessary to gather all that information on the existing Space Shuttle
that would be applicable. Because the task was a discrete event
simulation (DES) the majority of the information applied at first would
be about relationships and time. Who needs what and when? Immediately
this information was synchronized with the original project plan for
creating the DES.

Herein lie the few initial questions that would be critical to "thinking
supply chain". Who is the customer? Who are the suppliers? What is the
enterprise being simulated on the computer? These questions lead to one
of the first decisions to be made in creating the DES, the level of
abstraction about the "entity", the representation of the item that
flows through the simulation. Put simply, is the simulation moving a
"customer order" through the simulation, which as processes complete
becomes a "completed order", or does the simulation represent a physical
thing flowing through assorted processes getting closer and closer to
some end-state, a finished part, out the door? This question typically
gets answered in DES by consideration of the subject matter. For
example, a mortgage application process would be represented along the
former lines of an "order", but a manufacturing operation would lean to
the latter "part" type representation of an entity flowing through the
simulation. While this appears clear cut it is not quite that simple.
The complicating factor is the simulation user. What kind of interface
will be presented to the user? What kind of scenarios will be played out
and to what level will the simulation be user friendly? Figure 1 shows
both approaches.

-   With the order as entity the customer is on the radar, as the order
    comes from a customer.

-   Many useful measures can be collected about a part if it's treated
    as a resource, for example, utilization.

-   Many useful measures can be collected about a part if it's treated
    as an entity, for example, work in process.

-   For purposes of changing variables to run alternative scenarios the
    order as entity approach is more user friendly, meaning a subject
    matter expert can change variables in ways that are more in tune
    with the knowledge of the subject matter, the system being
    represented, rather than knowledge of the simulation.

![](media/image3.wmf){width="4.4625in" height="3.341666666666667in"}

Figure 1: Decisions, decisions, what is the entity flowing through the
simulation?

Once implemented the discrete event simulation for the future space
transportation system with the "order as entity" appears as shown in
Figure 2. The order in this case is a request for crew by the
International Space Station (ISS).

![](media/image4.png){width="5.482638888888889in"
height="4.231944444444444in"}

Figure 2: The Supply Chain Network for the Future Orion Ares I

# Physical Functional Units

While the prior entities flow from place to place, the actual places are
also of interest. The concept of a supply chain "node" is the same as
referred to here as a "physical functional unit". A physical functional
unit is defined as that physical location, typically a building or a
location within the plant, through which the entity of interest must
flow in order to reach the next state. A physical functional unit is a
necessary resource as well in order for the work on the part (or order)
to occur. As shown in Figure 1, the order (or the part) needs the
facility in order that for required process to be completed. For a space
transportation system an example would be an engine (the part) that must
go to a certain facility (the node, or physical functional unit) in
order to be installed (the process) onto the launch vehicle. In Figure 2
an example physical functional unit is the "RPSF" or the "CM Landing
Area".

# Other Necessary Elements of the Supply Chain Simulation

# Organizational Functional Units

A simulation flowing resources such as parts from A to B in a given
amount of time in order to fulfill a launch request would
*[not]{.underline}* necessarily be a supply chain simulation. It could
simply be a simulation of a certain series of processes leading to
launch. Elements such as solid rocket booster segments would be
requested by a Kennedy Space Center facility for example, and this chain
of events would kick off because the Space Station wanted crew (again,
the customer request as entity flowing through the simulation). Again,
representing this would simply be akin to any generic process
simulation. A signal would propagate back from the Space Station to the
Launch Pad ("Pad 39 A and or B" of Figure 2) which in turn requests an
integrated vehicle from the Vehicle Assembly High-bay ("VAB HB" in
Figure 2) and so on all the way back to a part being requested of a
supplier.

To be a supply chain simulation much more was needed. To appreciate why
more was needed it's important to digress into costs (an area only for
the brave hearted when considering any federal agency, and even more so
NASA). If a space vehicle element goes from place A to B, or from being
in a semi-prepared state at location A to a state at location B that is
closer to launch, the immediate resources required to get that element
from A to B will be called "touch labor". The term "element" will
generally apply to a large item such as a rocket stage, or an engine. A
crew module or a service module for the proposed future crew carrying
system Orion would be elements. What is found with the past (and still
flying as of this writing) Space Shuttle experience is that the element
of "touch labor" is the smallest portion of all the resources required
to get an element from A to B. That is, the visible "shop floor"
resources to produce, transport, prepare, process, integrate and launch
(and return as required, such as for a Space Shuttle Orbiter, or the
semi-reusable casings of Shuttle's Solid Rocket Boosters) are a small
part of total resources.

The temptation is to neglect other resources by assuming (1) these do
not alter the flow of a part or an element from A to B and (2) any
improvement in the visible process will propagate through the system to
positively influence downwards any other indirect or overhead costs.
Both of these assumptions are myths. (Arguably, there is also the
temptation to ignore indirect resources in an extremely complex system
as (a) too big a problem to be a problem, (b) a topic for bean counters,
not real engineers or busy managers, i.e., not an opportunity to
advance, and (c) "I'm busy improving, doing etc fill in the blank",
i.e., don't annoy me with reality).

Addressing assumption 1, that other resources than those visible to
actually work on the space vehicle can not alter the flow of anything in
going from A to B, neglects the reality of information as intrinsic to
the supply chain. In any industry, would a part move from a supplier to
the customer without proper documentation? Lacking the right data the
part is useless. What part is it? Has it passed inspection? What other
critical information must be with the part for it to enter any supply
chain wanting to control situational awareness and quality. Where is the
part? It is only in the simplest of terms that information can be
divorced from the physical parts that are represented in a simulation
(or even in the real world). Therefore it was a going in assumption in
creating a supply chain simulation for the proposed space transportation
system that information must also be represented somehow.

Also addressing assumption 1, there are well documented information
steps in preparing a space vehicle for launch. Reviews will be reviewed.
These steps, if not performed, mean element X can not go from A to B as
surely as if the facility at B were busy and had a physical barrier
preventing it from budging from point A. Figure 3 shows the Shuttle
Flight Preparation Process. Notice for example that the "SSME
processing" (Space Shuttle Main Engine Processing) block is followed by
an "SSME Rollout Review". [Then]{.underline} the next process of "OPF
Horizontal Processing" (Orbiter Processing Facility Horizontal
Processing) can kick off. One is tempted to believe that this
organizational review whereby engineers, managers and other responsible
parties gather could be ignored in a supply chain simulation, except for
that fact that this is where product information is gathered to a
critical mass to allow the next step. It could be ignored if the
resource cost were relatively and/or absolutely negligible, or if the
level of curiosity about the system were shallow. In this case these
in-direct functions, and many others, require resources that dwarf the
more visible resource needs for an element such as for "SSME
processing". This observation necessitated that these functions be part
and parcel in the representation of the supply chain simulation.

The prior assumption 2 about any improvements in visible processing
steps propagating backwards through the system to benefit indirect or
overhead functions is best understood as a myth when considering that
the indirect functions (a) have nothing to do with the visible activity,
and (b) the indirect functions have fixed costs due to the function
being performed and how it's performed. For example, a scheduled process
is made more efficient and a day is saved or some process is deleted, a
test is no longer required. The scheduling function, that department,
more than likely has it's costs determined by a combination of process
and technology, all defining the transactions with the shop floor. Fixed
costs in the Space Shuttle are notorious for such reasons. Process (the
steps), policy (the organizational rules) and practice or technology
(the software, interfaces and transactions) result in fixed costs. The
reduction of complexity of having one less item to schedule affects only
marginal effort. The same can be said of numerous other indirect
functions such as configuration control (of documents), requirements
management, document generation, configuration tracking (of hardware
state), problem tracking, etc.

![](media/image5.png){width="5.482638888888889in" height="3.8875in"}

Figure 3: Space Shuttle Reviews for Preparing a Flight

Hence, to avoid the temptations outlined previously, certain "review"
type functions were created within the supply chain simulation and
called "Organizational Functional Units". The red items shown in Figure
4 are a representation of the Shuttle-like element receipt or review
processes transplanted by analogy and subject matter expertise, on to
the new Orion Ares I system.

![](media/image6.png){width="5.482638888888889in"
height="3.671527777777778in"}

Figure 4: Space Shuttle-like Reviews Applied by Analogy to Orion Ares I

The Organizational Functional Units required some concepts in the
simulation analogous to the notions related to the physical / location
based Functional Units (for example the RPSF building). While physical
or location related Functional Units of an enterprise have associated
products, Organizational Functional Units would have associated
"Objects" that are produced.

-   Organizational Functional Units actually stem from "Objects" of
    information. An object must be defined in the simulation as (1)
    taking a certain amount of time to create, (2) coming (sourcing)
    from an Organizational Functional unit and (3) having a Physical
    Functional Unit destination, such as the "Operations & Checkout
    Building".

# Enabling Functional Units

Still, a simulation providing only the prior physical or information
resources would still be incomplete and not necessarily provide supply
chain insight. Once again there are still more resources, actually the
bulk of resources to address, that are required to produce the final
product. Considering this became the most difficult aspect of the space
transportation system simulation and in this development also the least
mature area offering tremendous promise and insight for future work. To
appreciate the situation it's important to ask if the rest of the
resources needed to create a final product, those not captured in
directly visible "touch" labor steps or in organizational "review" type
of steps are significant? The answer is yes. Further, it's necessary to
ask if these resources are of interest. Here the matter is less clear
cut as the simulation could run and lend insight without addressing any
further enabling resources. The judgment made here was to lean towards
completeness and to examine what would be discovered in the process.

Where are the rest of the resources required to produce a final product
in human spaceflight, a launch and the safe return of the crew? Figure 5
shows only the picture of all Shuttle resources at the Kennedy Space
Center. At the top is the touch labor we associate with the shop floor,
close in work, around spacecraft and the stuff closely associated in the
public imagination with NASA and spaceflight (i.e., spaceships). The
pyramid effect is quite evident. Moving to other parts of the Shuttle
enterprise, not shown, such as to production sites for expendable
hardware or to Mission Control at the Johnson Space Center would only
accentuate the pyramid effect further or create other similar pyramids.
The touch labor at the top would simply be that most close in to the
intermediate product at that other NASA production or operations site.

![](media/image7.wmf){width="5.475694444444445in"
height="4.334722222222222in"}

Figure 5: The Space Shuttle Pyramid Effect, an Abundance of Support,
Indirect and Production Costs

So it is clear that the area of other resources that are not entrained
in the step by step production process for a launch is an area requiring
continued emphasis, such as in cost models et al. For this simulation
the concept was then created of "Enabling Functional Units".

-   Enabling Functional Units are mostly indistinguishable from
    resources as cost rates that are often employed or applied as
    "burden" in any simulation. They are money, though in real terms
    these resources are people and processes that cost certain amounts
    and have certain defining behaviors. Enabling Functional Units (1)
    begin by defining a functional unit and indicating it as enabling,
    then (2) creating resource names and assigning these to these
    functional units and (3) indicating the fixed and variable costs of
    the resources as inputs to the simulation.

The final perspective then becomes as shown in Figure 6. There are
physical functional units (black), organizational functional units
(red), and enabling functional units (lower portion, un-attached
anywhere).

![](media/image8.png){width="5.482638888888889in"
height="3.359722222222222in"}

Figure 6: Indirect Support for the Orion Ares I

In practice all the prior requires an interface to define and relate all
the necessary parts of a supply chain and create a simulation. The
product developed here evolved to its current form as shown in Figure 7.
The "Network" drop-down provides a single location where a subject
matter expert can begin to define the supply chain of interest. The user
logic flow would be roughly as follows:

-   Define enterprises, such as "ATK" (a private company, and a supplier
    to NASA) or "NASA" (another player in the interwoven supply chain).
    i.e., "Who".

-   Define Functional Units (Physical, Organizational or Enabling) and
    via drag and drop connect these on the graphical user interface.
    i.e., more detailed "who".

-   Define products, either as physical products per se, or as objects,
    which are essentially information products. i.e., "What".

-   Associate products (or objects) with the appropriate functional
    unit. i.e., "who makes what".

-   Lastly resources would be added wherever of interest and associated
    with any functional units in the process. i.e., how much cost.

The interface used was Ariana[^1] by Productivity Apex Inc. (PAI), of
Orlando Florida. PAI created the Ariana interface tool to make
simulation easier to use for the subject matter expert or customer who
would otherwise not be interested or expert in a simulation program or
engine per se. PAI was also the developer under contract to NASA to
create the underlying supply chain simulation model/file presented here.
With this engine a user, such as NASA, can create the file or supply
chain representation that is of interest based on subject matter
expertise as well as knowledge of the correct function and use of the
software interface. Penetrating behind the scenes into the simulation
engine would not be required (though in practice it becomes necessary
during development). The simulation engine itself is the Rockwell
Arena[^2] simulation package.

Because of a desire to create scenarios the resulting product is
actually an interface for creating simulations of any sort. But because
the emphasis of this project was a supply chain simulation, still more
was needed to complete the picture above and beyond a series of concepts
such as enterprises, processes, functional units or resources. For this
next step, a supply chain framework model was required.

![](media/image9.png){width="6.314583333333333in"
height="3.671527777777778in"}

Figure 7: The Earth-to-Orbit Orion Ares I Supply Chain Simulation

# SCOR

Thinking supply chain requires a series of mental shifts the benefits of
which lie in that the framework that evolves is extremely suitable to
identifying opportunities for improvement, where transactions are
intensive, and what actually is required that makes anything move from A
to B or become a final product. Think lean six-sigma, value-added, or
(putting aside buzz-words and fads of the day) the simple forcing
function of thinking in organized ways that leave an enterprise knowing
more about itself today than yesterday. We used to call this "learning".
The Supply Chain Council[^3] "SCOR" model (for Supply Chain Operations
Reference model) was adopted for this project to provide the underlying
framework of processes. In SCOR the basics of process come down to plan,
source, make, deliver and return. While not delving into the intricacies
of SCOR it suffices to say SCOR is a descriptive model, it exists on
paper, as a series of agreed to processes that are common in business,
generic and widely applicable. They were defined to forward the
advancement of supply chain management.

In the implementation of the simulation the process framework was SCOR.
The "Earth-to-Orbit Supply Chain Sim" -- or E2O Sim as it came to be
called -- involved taking subject matter expertise of Shuttle and
transplanting it into a representation of the future system, the Orion
Ares I. As a result, as shown in Figure 8, a Physical Functional Unit,
such as the Vehicle Assembly Building High-bay (VAB HB) definition means
telling the simulation what happens there. What is sourced? This would
be a product of another functional unit, defined in a previous step.
What is produced? This would also be a product, defined in a previous
step. Here the supply chain flows and associations are becoming usefully
defined. Lastly, to whom is this functional unit delivered? Again,
another functional unit defined in a previous step. Here sub-processes
from SCOR can also be assigned.

![](media/image10.png){width="6.314583333333333in"
height="3.1034722222222224in"}

Figure 8: Capabilities of the Simulation and SCOR Processes

# Understanding the Problem

A simulation or a model that runs and produces interesting results must
ultimately test itself against the needs of the enterprise.

As NASA heads into the development of a system to replace the Shuttle,
warning signs surface on the future outlook.

-   Space transportation today, the Shuttle, is 21% of the NASA top-line
    total budget.

-   In 2020 Cx space transportation, the combination of Orion Ares I,
    Ares V and Altair (the lunar lander), will be 34% of the NASA
    top-line. This will be a 62% increase over the Space Shuttle.

-   This assumes current "estimates", a term interchangeable here with
    "plans", are close to the mark. NASA currently is estimating Cx at
    the "65% confidence level". That is the probability that the project
    will come in at the value estimated. Cx is a project totaling \$100B
    through 2020 (in real year dollars), a combination of up-front costs
    and downstream operations and production cost. By way of rough order
    of magnitude, since such a large project is actually a series of
    connected smaller projects, this is about the same as saying that
    about \$65B worth of the project will behave as expected and \$35B
    will not. Typically over-runs at NASA can vary wildly from the tens
    of percents to doublings of cost and beyond.

The prior metric does not change by assuming ever increasing NASA
budgets that keep purchasing power at today's levels, adjusting for any
inflation anywhere, or by assuming wide consensus in the transfer of
funds among the differing NASA enterprises. Such considerations are
"how", tactical assumptions, and have already been taken into account in
the prior metric. For one area of NASA to go up as much as 62% others
must decline (such as science and aeronautics, research and development,
etc). Going farther, to the Moon instead of just to low-earth-orbit and
the International Space Station, does not logically result in additional
funding. While it may be factual that a drive from Florida to Texas, all
other things being equal, costs more than a drive from Florida to
Georgia, this fact does not have any bearing on the amount of cash one
has on hand for either trip. While planning may show there are
sufficient funds in hand for the trip to Texas, one would question the
estimate if it contained an inordinate amount of optimistic planning
assumptions, such as the generosity of strangers, a job promotion in the
months before the trip, and a sudden ability to put off other expenses
such as the mortgage. Figure 9 shows the NASA portfolio to 2020 in real
year dollars[^4].

![](media/image11.wmf){width="5.477083333333334in"
height="4.1097222222222225in"}

Figure 9: The Big NASA Picture, Looking Forward

Various macro-level perspectives can be obtained today given the ability
of tools to both keep up with information as well as to present
information visually, including scenarios. While not delving into the
reasons why the portfolio out to 2020 becomes unsustainable it's more
important to note that the outlook not "adding up" is a focus of many
agency initiatives, especially as regards ways to reduce recurring
operations and production costs (shown in Figure 9 as "ISS Ops" and
"Lunar Ops". (Suffice it to note that the portfolio has no future
development elements in the out years concurrent with the operation of
the new system as does occur today, that the plan has no investment
features for the new transport system once operational, and that the
space station is not budgeted after 2016 though it is required by
Congress and likely to be operational till at least 2020 i.e., two
distinct enterprises are counting on the same \$2B a year of NASA budget
authority in 2017, 18, 19 and 20. All independent of any possible
over-runs in the Cx transport development).

A similar perspective is shown in Figure 10[^5]. Most such forward
analysis has as a key underlying assumption the notion (a Congressional
Budget Office assumption[^6] related to Gross Domestic Product trends,
among others such as Office of Management & Budget assumptions[^7]) that
discretionary spending programs, such as NASA, will rise at the rate of
inflation. Also assumed is the rate will be low, on the order of a few
percent per year. Any such assumption is usually presented in source
material as extremely optimistic by context alone as it is not
foreseeable that GDP growth dramatically deviates from a few percent
yearly but numerous federal programs would increase at rates far faster.
Hence other programs by necessity must decline if making the stronger
assumption that the share of the GDP spent of the federal government
remains close to past experience.

![](media/image12.png){width="5.482638888888889in"
height="4.183333333333334in"}

Figure 10: The Big NASA Picture, Looking Back

# Solutions for the 21st Century and NASA

Having presented a supply chain simulation, there are lessons from the
project that are worth noting.

-   Adopting a supply chain perspective and a supply chain descriptive
    model (SCOR) was shown to be applicable to constructing a
    comprehensive macro-level representation of the complex interplay of
    information and materials for producing a launch.

-   Such a macro-level model was still highly complex, as even the first
    layer of interaction among parties of the supply chain network in
    the NASA space launch enterprise are numerous and complex. The
    simulations complexity increases dramatically in considering the
    information and resources that support the visible processes of
    producing the launch from request for elements through to return.

-   **Any such simulation effort obtains most of its value as a forcing
    function. The forcing function is the simulation can not be created
    without understanding how players in the supply chain network
    function today in order to understand how they might interact
    tomorrow.**

-   The top-two candidates for improvement by which any strategic plan
    can become both more robust to change, and consistent with schedule,
    by being enabling and not outcomes in themselves, and by sheer size,
    are Cx Space Transportation recurring production and operations
    costs and NASA indirect costs, Cross Agency Support. **Both are
    areas ripe for applying supply chain thinking and seeing the fruit
    of such efforts in a reduced recurring cost outcome for the Cx space
    transportation system to be as well as in agency overhead costs.**

-   Assume actual "outcomes" (the robotic / science presence in space or
    a human / exploration presence in space, such as ISS and/or a lunar
    outpost) are not areas for reduction as regards purchasing power /
    budget commitments, but that such areas would be candidates to
    benefit from supply chain thinking as regards increased productivity
    at a given budget.

# Caveats and Future Work

# Caveats

The Ariana/E2O SC Sim file screen shots shown throughout this paper for
Orion Ares I predate certain Constellation Ground Operations Project
Concept-of-Operations decisions. For example the path of the Orion upon
receipt at KSC is, as of this writing, to go to the Operations &
Checkout Building and from there, upon handover to the government, to
the Multi-Purpose Processing Facility (MPPF). The "SSPF" and "PHSF",
such as shown in Figure 7, are no longer part of the plan. The file and
this paper will be updated at a future time to reflect this. Such an
update is not relevant nor alters any of the conclusions or basic
information presented in this paper.

# Future Work

There are a few significant areas that should be emphasized in future
such work in creating a supply chain simulation for the analysis of a
proposed space transportation system. One area of emphasis, analysis
case definition and analysis per se will continue as resources permit.
Successful use of the tool in analysis can build the case for the future
work as follows. In a Darwinian sense any tool must prove itself in the
realm of providing answers to questions of interest in a manner better
than other tools.

[]{.mark}

# Improved Cost Estimating Structure

[]{.mark}

The E2O SC Sim has a relatively modest cost estimating capability.
Individual types of resources and the fixed and variable cost of these
are inputs to the simulation. Then these resources must be attached to
the parts of the supply chain in a way that will serve both to rack and
stack a useful set of outputs as well as in a way that does not keep the
simulation from functioning, such as due to an inadvertent lack of
resources. The later is important as generally a user is not interested
in locating a resource constraint related to costs. Rather, the user is
only interested in what the total cost tally would be, as well as any
individual cost metrics, for a given demand, assuming all such resources
are made available to the operation being simulated.

Ideally the cost estimating capability of a supply chain simulation
would be a capability integrated from an outside tool that is optimized
to the complex task of cost estimating future recurring costs of a crew
carrying space transportation system. Naturally some connection to
Shuttle cost data would be a part of such a capability. The advantage to
be gained should [not]{.underline} lie only in the ability to have a
better cost estimate or a better set of inputs for the supply chain
simulation. Instead, given that a cost estimation tool and a supply
chain simulation are ultimately about the same system, there should be
common descriptive inputs needed by both any cost estimation engine as
well as any simulation engine. This is not trivial. While a supply chain
or a cost estimation tool may require a descriptive emphasis on
different aspects of the same system, ultimately it is the same system.
To expand on this point by way of analogy, if a plant is expanding a
part of it's manufacturing line, the "system" description that a plant
engineer generates can be used to cost out the purchase and the same
description can be used by another (or the same) engineer to plan out
the productivity of the line.

It is unlikely that this ideal could be met by upgrading the existing
supply chain simulation any more than an upgrade of a cost estimation
tool would get it to "talk supply chain". In all likelihood the ideal
integration would be accomplished by a new development from the ground
up, for a combination cost estimation and supply chain model &
simulation. Past efforts such as that described in this paper would
naturally inform such a development. An existing model structure would
likely be optimal to determine cost, enhanced by the actual summation,
averaging etc of replications and runs of a simulation, while the
simulation engine would be optimal for setting the system in motion. A
graphical parts approach whereby a user could build the vehicle by
generic stages, elements, and sub-systems, including ground systems
aspects of facilities, transporters, personnel, and shifts would kickoff
all subsequent cost or simulation functions. A determination of touch
labor per flow is likely the common juncture of both the ideal cost
estimation tool and the ideal simulation. The more challenging and
complicating factor would still be the treatment of support and indirect
functions. This is an area where past work appears to be offering a
critical mass of knowledge to future effort.

One cost estimating capability that also addresses supply chain
improvements is the Launch & Landing Effects Ground Operations model or
"LLEGO". This model can serve as another starting point, as with the E2O
SC Sim, to the implementation one day of a more integrated cost
capability with a supply chain simulation. LLEGO, using MS Excel,
addresses both a baseline capability for future systems, whereby
everything is assumed to be business as usual, as well as an evolving
improvement capability, whereby certain supply chain premises alter cost
estimates. The results of such a model can be used to focus area of
study and investment for improved supply chain management in the real
human space flight enterprise. *Although naturally related, further
information on LLEGO will be a subject of future addition to this
paper.* Shown in Figure 11 is the LLEGO main screen interface.

![](media/image13.png){width="5.482638888888889in"
height="2.807638888888889in"}

Figure 11: The LLEGO Model, Addressing Operations Practices and
Technologies in the Supply Chain

# Supply Chain Signals Structure

In any supply chain the notion arises of signals. From customer to
elements, to assemblies, to parts, the network depends on suppliers
receiving signals for an assortment of reasons. A low inventory may
trigger one signal whereas another signal is initiated by a process
requiring a part or element. In a discrete event simulation this notion
of supply chain signals that trigger transactions introduces a
structural issue. This is a complex issue related to the way a
simulation tries to represent reality on a computer by running a series
of steps that depend on each other, i.e., the "discrete" in any DES.
Left unsaid till now is that the processes are described, to reflect
reality, as taking an amount of time that varies according to a
mathematical distribution. A process does not just take 10 days. Rather,
as an example, the user indicates the process can take from 5 to 12 days
with the process most of the time taking more than 7 days. This can be
done by inputting a process time "Triangular (5,7,12)". On one run at
creating a final product the simulation takes 5.5 days to accomplish the
process, on another 11 days, randomly. Over time the average of the
process duration would reflect the mathematical distribution indicated.
This introduces a "just in time" issue for a supply chain simulation as
follows:

-   Partner A starts to assemble Item A.

-   Item A requires numerous parts.

-   Part A assembly will take X amount of time, Adding Part B to Part A
    will take X amount of time, and so on.

-   Part K comes from Supplier K.

-   Supplier K needs Y amount of time upon being asked for the part to
    make it and deliver the part.

The simulators dilemma becomes, if the "times" are actually
distributions that can randomly take on assorted values, no matter how
restricted the range, there will be a lack of synchronicity.
(Ultimately, reducing the lack of synchronicity to very low levels would
be one sign of an extremely efficient supply chain, i.e., running a
tight ship).

The actual signal pattern that emerges with distributions would be:

-   Partner A starts to assemble Item A.

-   Partner A, knowing that Part C will take 3 days to deliver, requests
    (i.e., sends a signal) that part at the start of some previous
    process, the assembly of Part B for example.

-   As time runs forward the Part B process actually took more or less
    than 3 days.

-   Part C arrives either late, if the Part B process took less than
    expected, or early, if the Part B process took longer than expected.

The prior reality, reflected in the simulation, results in certain
simulation technical issues. In the real world related issues also
arise - some local inventory would be required to address possibly
needing a part faster than expected, or perhaps a supplier would keep
the inventory so as not to be caught by surprise. Both are reflections
of inefficiency, as ideally the signals would be tightly coupled, and
inventories and staging at each node, buyer or supplier, would be small
to nil. That coupling occurs in a modern supply chain by achieving a
partnering and trust for both the buyer and the supplier. An excellent
example is that sales at Walmart would be automatically visible to a
supplier. The supplier could see when there was excess supply and slow
down production, or when there were high sales, and speed up production.
The vendor would not take advantage of a situation of low inventory at
the buyer to increase prices. Neither would a buyer take advantage of
seeing an excess of production at the vendor to negotiate a cheaper
price. Both parties would be using such information exchange for mutual
benefit to productivity, via automation and electronic interchange of
data, not for individual gain at the expense of each other (which serves
no one).

In a simulation the technical issue of signals being sent, which must be
at some defined time, and when the necessary action actually takes place
as complete, both of which are subject to random variation, will more
likely than not mean there is a certain lack of synchronization. This
must be a matter of future consideration. Techniques exist that would
pretend to address this matter, a more "systems dynamics"[^8] approach
for example, vs. a discrete simulation approach, but it is unlikely that
the simulation engine approach has any bearing. More likely the signals
should be seen not as an item to "fix" in a simulation but rather to
guide the understanding of the real system the simulation is meant to
represent. The user would ask:

-   Why are the time distributions as wide as they are?

-   What is staging (a queue) costing me?

-   How do people, processes and systems actually communicate
    information among themselves?

-   How might inefficient realities be best represented in the
    simulation?

-   How can I use the outputs of the simulation to tell me what needs to
    be looked at further to eliminate inefficiencies?

*This signals issue is perhaps the area of most challenge and promise in
future work as it relates to numerous other matters that could be
explored in work to come.*

# Improved User Interface

The SCOR model has 5 top-level process types, plan, source, make,
deliver and return. There are 21 next level sub-processes within these
top level processes, greater detail defining the plan process, the
source process, etc. There are then 135 next level sub-processes below
this prior level. For a user to start assigning processes from SCOR, it
is first necessary to identify the enterprises of interest in the supply
chain network. Company A, Company B, etc must be described. The
Companies have locations. At these locations are sites, physical
functional units, buildings, or simply work stands from which a product
moves from A to B. This requires defining products. For completeness,
objects of information generated by still other functional units
(organizational) can be defined. Lastly even greater completeness would
add resources that contribute costs but are essentially enabling.

The current user interface of E2O SC Sim created a semi-graphical
capability to accomplish much of the prior network definition
automatically. Still, most of the definition is via input screens. None
of this is a major shortcoming. The more significant graphical user
interface shortcoming lies in the lack of step-through intuitiveness
whereby a user readily knows or is prompted to describe what's next,
what else is required to create a valid supply chain simulation file.
This too is an area ripe for future research and development. For
advances in this area future efforts could focus on a simple simulation
paradigm, how difficult is it for a new user with extensive subject
matter expertise, but with minimal simulation experience, to create a
simple path as shown in Figure 12. The difficulty in creating such a
simple "M1 queue", determined by a combination of novice user testing as
well as users with differing degrees of simulation software experience,
could serve to provide insight in the development of any software.
Benchmarks could be quantitative such as time to create, or qualitative,
such as feedback about ease of use or proneness to error. Benchmarks
would guide the capabilities to implement in a future supply chain
simulation graphic user interface.

This does open up a controversy admittedly -- to what degree should
software that will be used to provide decision making support (cost,
lives, time, investment, etc) be so friendly that it could possibly make
users dangerous, appearing to function well but actually being
incorrect? Alternately, if simulation is to gain a home in the analysts
and engineers tool bag it is important to recognize that such an
argument does not mean all efforts at improved, friendly user interfaces
should be low on the priority list. Historically many friendly computing
capabilities began in the realm of the professional who spent time
becoming adept at understanding some obscure software language or
program. Then one day, using MS PowerPoint by way of example, that
professional awakens and discovers he's obsolete, since thanks to a user
friendly intuitive program, everyone can now do professional quality
slideshows and graphics equally badly[^9]. Adobe Photoshop and MS Excel
are also examples of capabilities once only in the realm of the software
cottage industry (as simulation is now). So this trend to user
friendliness is not so much one to encourage or discourage so much as to
simply accept and mine for advantage. Simulation user interfaces will
continue to need refinement towards creating capabilities that are more
and more widely usable to broader and broader audiences.

![](media/image14.png){width="5.482638888888889in"
height="2.607638888888889in"}

Figure 12: A Starting Point to Measure the Degree of Difficulty in the
Use of a Software Interface

# Project Team Members

-   Edgar Zapata, NASA Principal Investigator, NASA KSC

-   Mike Galluzzi, Supply Chain Guru, Space Shuttle Program Office, NASA
    KSC

-   Steve Kyramarios, Project Manager, NASA KSC

-   Dr. Mansooreh Mollaghasemi, PAI Chairman and CEO. Project Role:
    Executive Guidance

-   Mike Callinan, PAI President. Project Role: Chief Logistician

-   Dr. Sam Fayez, PAI Project Lead

-   Dayana Cope, PAI Simulation Lead

-   Assem Kaylani, PAI Graphic User Interface Lead

-   Nathan Rychlik, PAI Simulation Support

-   Manuel Mora, PAI Simulation Support

# Acknowledgements

This work was made possible through the support and funds of the NASA
Exploration Systems Research & Technology program. Leadership in this
program was provided by John Mankins, NASA HQ, at project initiation,
and by the support throughout specific to the modeling and simulation
arena of Don Monell, NASA HQ (later NASA JSC). This project was funded
as Phase I and Phase II in the 2005 to 2007 timeframe.

# More Information

The Earth-to-Orbit Supply Chain Simulation project web page:
<http://science.ksc.nasa.gov/shuttle/nexgen/E2O_supply_chain_main.htm>

# About the Author

Mr. Zapata has worked with NASA at the Kennedy Space Center for over 20
years. In that time he has held responsibility for Shuttle systems
including the Shuttle External Tank, the Shuttle cryogenic propellant
loading systems, and related systems. For over a decade he has worked to
translate the operations experience into improvements in flight and
ground systems design so as to achieve improvements in ground processing
operations from landing through launch, in all aspects from direct to
in-direct operations areas. He participated in the Explorations Systems
Architecture Study or "ESAS" contributing Launch and Landing Ground
Operations cost estimation and integration into life-cycle cost analysis
processes to decide the new NASA architecture to follow the Space
Shuttle. Most recently he has performed strategic Constellation and
NASA/agency future outlook-analysis and supports portions of the
Constellation Standing Review Board via other analysis, including
modeling. Mr. Zapata looks forward to a day when access to space is
safe, routine and affordable as a result of taking advantage of,
quantifying, and understanding the experience and lessons of past and
ongoing space transportation systems operations.

[^1]: More information on Ariana available at:
    <http://www.productivityapex.com/products/Ariana.asp>

[^2]: More information on Arena and Rockwell software available at:
    <http://www.arenasimulation.com/>

[^3]: Supply Chain Council website at:
    <http://www.supply-chain.org/page.ww?name=Home&section=root>

[^4]: From the EZ NASA Model, more information available at:
    <http://science.ksc.nasa.gov/shuttle/nexgen/NASA_Model.htm>

[^5]: A Multimedia presentation by portfolio.com at:

    <http://www.portfolio.com/interactive-features/2008/01/NASA?TID=rm/goo/Interactive_Features_2008_CT/NASA_Budget_&_Timeline>

[^6]: "The Long Term Budget Outlook", CBO 2007 report at:
    <http://www.cbo.gov/ftpdocs/88xx/doc8877/12-13-LTBO.pdf>

[^7]: "The Federal Governments Financial Health", OMB 2007 report at:
    <http://www.whitehouse.gov/omb/financial/reports/citizens_guide.pdf>

[^8]: Basic information on this approach at:
    <http://en.wikipedia.org/wiki/System_dynamics>

[^9]: Columbia Accident Investigation Board, "Engineering by Viewgraphs"
    at:

    <http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0000jL>