Abstract. Deploying ERP tools like SAP in any organization is a complex undertaking with many potential pitfalls--as evidenced by many high-profile implementation failures costing millions of dollars over original estimates. This is in part due to the fact that each ERP deployment is a unique experience with no two enterprises being exactly alike; each with their own unique financial or management processes. Similar complexity in other industries (such as complex electronic systems, aircraft design, transportation systems, environmental/regulatory compliance, pharmaceuticals, wafer fabrication plants, etc.) have spawned processes and tools to deal with this complexity--usually tagged under the heading of Systems Engineering or Systems Architecting. This paper proposes applying systems principles to the ERP implementation project backed up by tools (such as SLATE) that support a systems approach to product development improving the product in the process--after all, the product of an ERP implementation project are functioning, customer-compliant financial and management systems.

As its "architecting" name suggests, you can think of a Systems Architect much the same as a building architect, except the Systems Architect is designing products (any kind of product) rather than a building.

In essence the building architect captures the needs of the building tenants; how they are going to use it, how many people, flexibility, growth, etc. before launching into the design (customer requirements). He then considers the surrounding environment, building codes, getting people in and out, parking, aesthetics, security, plus the myriad other considerations (constraints); doing the trade-offs between various potential approaches before putting it on paper. The design is captured on paper in the form of drawings that document the results of the analysis and communicate those decisions to the builders. Systems architects capture their design trade-offs in the form of detailed design specifications that communicate their decisions to product builders/design engineers--EE’s, Software Engineers, ME’s, and other disciplines.

In the past, buildings were simple enough that a single architect could oversee the entire process. Today they work as large teams involving many different specialized disciplines (energy management, ergonomics, structures, etc.). Systems architecting also involves many different disciplines that must be balanced to build a product that meets the customers needs (manufacturing, distribution, maintenance, regulatory compliance, etc.).

As building commences, the building architect shifts roles from building designer to building project manager. They spend much of their time handling trade-offs as unforeseen problems surface (...materials delivered late that impacts installation of...). System architects also shift roles as the product goes into design. Unforeseen problems or issues surface and need to be addressed and traded at a global level throughout the life of the project.

Given their importance, we would never consider starting building construction without the architectural drawings in hand. We would never consider turning a construction crew loose on a building before the architect knows what they are building; yet that is exactly what happens many times in the product development process--software engineers writing code, electrical engineers designing circuits without the system architect telling them where they are going in the form of design specifications.

Texas Instruments (where SLATE was developed) discovered that if the system architects get behind the construction crew, you’ve lost control of the project and have the beginnings of a "runaway" project. The consequences:

• the chances of restarts and redesign goes up significantly (...you mean we were supposed to put the pipes in before the foundation?).
• costs go up due to work-arounds (if bad design decisions sit without being headed off, they set up like concrete in the product design until it becomes too expensive to pull them out--leading to work around after work around).
• product quality goes down (quality is conformance to customer requirements, since the design is not managed to the customer requirements, the quality of the product is dubious)
• the architect goes into documentation mode (documenting what is already done) rather then leading the design--a runaway!

Since you can’t slow down the "construction crew," you must speed up the systems architects to keep them ahead of the designers. Nowhere is this competitive pressure felt more than in the electronics systems business, where getting to market 6 months late can erode a third of your profits. Feeling this pressure,

Texas Instruments realized the need for a computer-aided architecting tool to accelerate systems architects/engineers by:

• exposing the impacts of design decisions as they were made; versus waiting to see the results when the product hit the field (catching problems early in the design process costs 10x-100x less than catching them on the factory floor).
• automating the low value-added processes of document generation for communicating design decisions
• supporting a groupware approach to product design that allows a team of system architects to work together on a product development (ensuring everyone is working from current information).
• tracking and capturing decisions, rationale, etc. that sets up a project for reuse on a "chunk of product" basis.

The result was SLATE (System Level Automation Tool for Engineers). SLATE represents a "first of its kind" system-level engineering, product-oriented groupware that supports a team approach to system design including:

• a set of system architecting graphical building-blocks that allows a team of system architects to quickly describe and build systems
• commercial, client server, object oriented database for persistent storage of the building blocks and their relationships
• distributed, methodology independent groupware that supports a team approach to designing products (even widely dispersed development teams or contractor/sub-contractor/customer teams)
• automated document generation, where documents are a living by-product of the design capture process
• the ability to interrelate the many different perspectives of the problem with patented technology (i.e. relating cost to components, to the functions that components perform, to the factory where they are built, to the test sets that will test the components, to the maintenance facility, etc.--giving the Systems Engineer access to the right information at the right time so that better decisions can be made).

...the result is a Computer Aided Engineering (CAE) environment that not only captures systems, but also customer requirements, and allows those requirements to be linked to design alternatives; all of which allows a team of designers to focus on the product while avoiding the many pitfalls of getting the right product to market on time and on budget.

The SLATE building blocks (Systems Architecting "Tinker Toys") were developed by talking with systems architects and watching what they were doing. For example we discovered that they used a "language" for describing what they are building. Try this experiment for yourself. Ask any system architect what they are working on and they will grab a marker, head for the nearest white board and begin drawing boxes and arrows (although not as neatly as below)...

As a result, it became obvious to us that whatever a tool did, it needed to speak this natural language of Hierarchical Decomposition. We call these boxes that the architect uses so much, Abstraction Blocks (shortened to AB). These Abstraction Blocks (AB’s) can be hooked up hierarchically (hierarchical decomposition) and functionally (this output goes from here to this input over here). In addition, we can hook other things to them like requirements, technical budgets (power, cost, weight...), notes, simulation models, graphics,...

We built SLATE’s graphical user interface around this idea...with the architecting team using the building blocks to build and interrelate systems. The building blocks are represented graphically in SLATE’s User Interface by icons, for example:

• Abstraction Blocks are used to build things--products, organizations, procedures, distribution systems, test systems, manufacturing facilities, etc.
• Requirements capture the intent of the product design, performance objectives, goals,--how it is that you know you are done with the design.
• Budgets relate quantitative/measurable objectives to product designs (schedule, reliability, cost, throughput, weight, etc.)
• Notes provide a project notebook capability for documenting decisions, rationale, critical items, action items, and others issues
• Documents provide a customer input and output media
• TRAMS enable you to interrelate different hierarchies made with Abstract Blocks. For example, this component performs this function.

These building blocks can be used to build systems by attaching or linking them to each other. For example a car design might consist of many of these abstract building blocks built into the structure of a car (...the car consists of an engine, transmission, passenger compartment, etc.). The parts of the car are hooked to each other such as the engine is attached to the transmission and the transmission is linked to the drive train. Requirements are used to capture customer desires (the foundation upon which the product is built and the common language used to talk to the customer) and are related to the various car components that address those requirements. Budgets are attached to the various car components to track cost, MPG, weight and other critical design parameters. Notes are also attached to car components to document decisions, concerns, and many other issues involved in getting the car to market. With the design complete, documents are generated out of this design capture effort such as maintenance manuals, user manuals, software design specifications, and others.

As illustrated below, SLATE’s building blocks can be used to capture the necessary views of an organization from which SAP can be configured. The process is as follows (see numbered figure below):

1. The first step is to use an appropriate methodology to drive out the objectives or requirements for the SAP implementation. These requirements (like "we need real time access to PO status…") will be used to gauge SAP success and help identify which SAP functions are needed/not needed.
2. The objectives/requirements are mapped into the SAP reference model. This helps identify first, which SAP functions/modules are not required for this implementation and second, which required functions are not supplied by SAP.
3. The resulting mapping can then be used to set SAP’s configuration tables.
4. Because each of the SAP reference model elements can be hooked together in a process flow, SLATE can be used to set the Control Tables. SLATE supplies several important pieces to this problem; first, the logic or flow of information can be captured and simulated in SLATE using SLATE’s token-based simulator and second, SLATE’s Activator feature (ability to associate behavior with each building block) allows you to trigger processes by events (such as a Purchase Order entering the system) effectively allowing you to see how the process will work before going to SAP.
5. With TRAMs (SLATE’s Patented ability to interrelate different hierarchies), an organization can capture other views of a business such as customers, products, organizations, manufacturing, suppliers, etc. Each of the views can be interrelated, for example this customer uses this product, supplied by this organization, manufactured at this facility, which uses these suppliers… These views provide the necessary information to set the SAP data tables.


To this point, we have been focused on the "how we are going to use SAP" or the "to be" condition. However, this is only part of the problem; getting from where we are to the "to be" is a major problem. SLATE can help in this area also.

6. Another decomposition of the current processes and legacy systems used to support that process mapped to the "to be" process will help identify the gap’s (what is often referred to as the gap analysis).
7. These gaps (along with missing or unfulfilled requirements) must be filled either by third party "bolt-on’s" or custom interfaces from legacy systems.
8. Because budgets and notes can be associated with these elements, SLATE provides a natural place to generate specifications, cost estimates, status and management reports, and other documents (including Intranets).

Some of the benefits of this approach include:

• The SLATE "business model" can be used to (re)configure SAP—giving an organization the ability to rapidly change system configurations.
• SLATE’s patented ability to map between different hierarchies allows you relate processes, products, systems, organizations—giving you a big picture view of the business under SAP implementation.
• Because SLATE includes a discrete event simulator (token-based), you can simulate the SAP implementation before going to "code". This not only includes the ability to simulate business objects flowing through the system but also the rules associated with those objects—complete with traceability back to the customer objective behind the rules.
• The ability to make decisions within the context of the customer and the needed features (inhibiting requirements creep).
• SLATE supports a groupware approach to SAP implementation. This means even widely dispersed international organizations can use SLATE’s distributed database to work together on SAP implementations.
• SLATE is a natural communication media for SAP deployment experts—capturing the information and relaying to others involved in the effort (also an excellent way of capturing SAP deployment expertise)—enabling reuse on a major scale.
• Because you are modeling the organization under deployment, future enhancements or changes to the organization can be quickly evaluated (or vice versa)-—which in itself is a very valuable by-product of the SLATE SAP process.

…all of which creates a measurable, improveable process for accelerating SAP implementation, that creates competitive advantage for the SAP customer and consulting organization.

SLATE also has a feature called an "activator". Activators, like their biological virus counterparts, cause other processes to trigger, allowing deployment and management processes to be enforced.

For example:

• A change to a requirement or function could automatically trigger a report of all elements of a project affected by the change (as well as a cost estimate to implement the change).
• Baselining a system could cause a series of final tests to be executed on the system to validate and qualify the finished SAP deployment against original customer requirements (this could also include "SAP-in-the-loop" testing—allowing an organization to try out new features before going live).
• A field service or problem reporting system could automatically trigger a series of tests to duplicate or validate the problem and record the results.
• A SAP feature change or bug report could be automatically forwarded via email to all consultants involved with that part of the SAP deployment.

ERP deployment in a complex organization is a very complex problem that requires a "systems architecting" approach to controlling ERP deployment projects. SLATE supports this systems approach by providing a set of system architecting building blocks that can be used to automate and control an ERP deployment project by:

• capturing the customer’s objectives mapped to an ERP reference process
• identifying differences between the reference model and customer processes to identify and automate ERP parameter configurations
• understanding the gaps between the ERP reference model and the "as is" systems to manage the interfaces between where we are and where we need to go (as well as manage the interfaces with legacy systems)
• providing a means of visualizing customer organizations, people, processes, and products and how they relate to the ERP system (how the product is going to be used...)

...all of which puts you in control of the deployment effort and reduces the risk of a "runaway"; producing satisfied customers and competitive advantage in the process.

Mark E. Sampson works in SLATE marketing at TD Technologies’ in Dallas, Texas. He is a graduate of Brigham Young University (BSCE) and University of Southern California (MS-Systems Analysis/Management) and has over 14 years experience in applying automation tools to various engineering disciplines, including systems architecting. The large number of ERP implementation runaways lead to his investigations into applying systems practices used in other complex projects to ERP implementation. This paper is a result of his investigations. He can be reached at TD Technoloiges Dallas offices at sampson@tdtech.com or (972)669-9937.

Send email to Interex or to theWebmaster
©Copyright 1998 Interex. All rights reserved.