KSC Next Gen Site ___Questions? Comments?

Making the Case for a NASA Advanced Supply Chain Management Initiative

This work will continue as a work in progress.

Last Revision: January 8, 2009

[Download in .pdf format]

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.

The Orion Ares I crew vehicle and the Ares V cargo vehicle.

1. 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.

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).

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

1.1. 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”.

2. Other Necessary Elements of the Supply Chain Simulation

2.1. 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 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 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.

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.

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”.

2.2. 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.

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).

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.

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

3. 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.

Figure 8: Capabilities of the Simulation and SCOR Processes

4. 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].

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.

Figure 10: The Big NASA Picture, Looking Back

5. 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.

6. Caveats and Future Work

6.1. 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.

6.2. 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.

6.2.1. Improved Cost Estimating Structure

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 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.

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

6.2.2. 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.

6.2.3. 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.

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

7. 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

8. 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.

9. More Information

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

10. 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 ezNASA-Model, more information available here.

[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 report at: http://www.gao.gov/financial/fy2007financialreport.html

[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

_____________________

Also see:

_____________________

Website Contact: Edgar Zapata, NASA Kennedy Space Center