Skip to main content

Division of General Engineering

ENGM 3000 – Enterprise Systems Design

Enterprise Systems Design (ESD) is a structured course for junior or senior undergraduates that fulfills one of the requirements of the minor or concentration in Engineering Management. Applying principles of Lean, Six Sigma, business analysis, and systems engineering, three-person student teams design or redesign a system or process for a sponsor.

(For an overview of all the types of Engineering Management projects we offer and to learn how they work, see For Prospective Project Sponsors.)

Offered in the Fall and Spring Semesters

What you can expect from an enterprise systems design team project?

Systems combine people, processes, technology (hardware and software), material, information, and physical assets to accomplish an objective. Systems may include products, services, processes, or operations. For the BSD team project, you are invited to identify a system within your organization that you would like to design, map, analyze, and/or improve. Over the semester, a student team will work with you to:

(1)   determine your objectives for the system;
(2)   conduct an end-to-end analysis of how it works and how well it performs currently;
(3)   design an improved version to better meet your objectives; and
(4)   develop an implementation plan to move to the new system

While actually building the new system is not part of the course, you can use the team’s analysis to develop it internally or to contract it to an outside developer. Whatever you choose to do with the results, if we’ve been successful, at the very least, you will gain a deeper insight into the operation of your system and then act accordingly. A business process consultant might charge many thousands of dollars for this service, but with this project the only cost to you is your time (about one hour per week).

(Back to Top)

Contents of the Enterprise Systems Design

As a starting point for considering what you’d like the team to focus on, you may find it helpful to refer to the generic outline of the marketing strategy that every team will follow. You can then “cut to fit” this outline to your particular priorities. The business system consists of three parts:

Part 1: Analysis of the Existing System

Enterprise Analysis. Gaining an understanding the organizational context of the project. Where is the organization headed? How does the process or system support the organization’s directions? What are the business objectives for the system? At a high level, is the system meeting its objectives? What is the driver behind this improvement project? What organizational constraints are imposed on the system? Enterprise analysis provides context to requirements analysis and to solution identification.

Existing System Architecture. Determining how the current system works and how well it is meeting the expectations of its stakeholders. In projects that are intended to develop an entirely new system or capability where none existed before, this section focuses on benchmarking – the analysis of comparable best-practice systems or processes.

Existing System Performance Assessment. Identifying the system’s current performance relative to its business objectives. What are the key shortfalls and risks in the way the system currently operates? What are the root causes of these shortfalls? What are the implications for system improvement?

Part 2. Proposed System Design

The proposed system is a roadmap for meeting the business objective for the system, either by closing the performance gaps identified in Part 1 or by matching or exceeding best practices in place elsewhere.

Benchmarking. Identifying best practices for the system. Using primary and secondary research to analyze those practices and  determine how they could be applied to the organization.

Determination of Solution Approaches. Identification of at least two alternative solution approaches, an incremental solution (improvement of the existing system architecture based on existing organizational constraints), or a clean-slate approach (an entirely new architecture – what could be possible if one or more existing organizational constraints could be lifted). Or the team could fashion the two solution approaches as incremental (near-term) and end-state.

Requirements Analysis. (The heart of business analysis.) Identifying the “use cases” the system must address and the conditions to which the system must respond. Specification of the system’s functional and performance requirements

Proposed System Architecture. Specification of the proposed systems’s functional and physical architecture to meet the requirements (usually a simulation, mock-up, or wireframe of the solution).

Solution Assessment and Validation. Assessment of internal development vs. outsourcing vs. off-the-shelf solutions (if available) options. Determination of how well the proposed solutions meet the system requirements and business objectives. Proposed system risk assessment.

Part 3. Implementation Plan

Project Management Plan. Migration path from existing system to proposed system. Includes benefits/barriers analysis, work breakdown structure, project schedule and budget.

Business Case. Benefits (financial and non-financial) vs. costs. ROI analysis, breakeven analysis.

Outstanding Issues and Future Directions. Includes a proposed project description for a follow-on project.

(Back to Top)

Identifying and Developing an Enterprise Systems Design Project

In this section, we explain what characteristics make for a good project, identify examples of some recently completed projects, lay out a template for the project description, provide an example of a completed project description, and explain how to get started.

(Back to Top)

What makes a good candidate for an Enterprise Systems Design Project?

Good candidates for a BSD project are processes or systems that meet at least one or two of the following criteria…

(a) They are specific and well-defined.
(b) They require either development or improvement (or could benefit from careful analysis).
(c) They are important to the sponsor (worth spending the effort on).
(d) They are repeated, so that lessons learned from analyzing them can be applied to future runs.
(e) They are moderately complex, with multiple steps that can be analyzed, simplified, combined, reconfigured, or rationalized.
(f) They are expected to respond to multiple types of demand (without demanding that you “reinvent the wheel” each time a new demand situation arises).
(g) Even if they are working well now, they may not work in their present form if demand increased or decreased significantly, or if conditions changed significantly.
(h) The sponsor has enough control over them that they can modify or improve them (as opposed to a purchased system that can’t be modified).

(Back to Top)

Examples of previously completed enterprise systems design projects

To stimulate your thinking, here are some of enterprise systems design projects for a range of processes that we’ve completed in the past two years:

  • Patient flow optimization for Vanderbilt Clinic
  • Communications work flow management for office of the CEO of a multibillion dollar organization
  • Facilities management preventive maintenance program
  • Accounts payable optimization for a leading industrial products company
  • Rationalizing of work flow for a multidivisional health care IT company
  • Automation of laboratory requisition system for a full-service forensic sciences company
(Back to Top)

Project Description Template

  • Company Name
  • Company Logo (if available)
  • Brief Background on the company or organization: What it does, who its customers are.
  • Problem Statement: A brief description of the system to be developed or improved.
  • Project Objectives: Desired outcomes from the project.
  • Preferred Qualifications (optional): Any particular major, interest, background, or prior course work by team members.
  • Contact Information: Name of project leader, title, organization, phone, e-mail, website
  • Company Executive Sponsor: Name and title of CEO or equivalent

Don't worry about whether you're expressing your project in enterprise systems design terminology. Your description should be written from your (sponsor) perspective. Part of the team's challenge is the translation into a true BSD project definition. See Project Description Example below.

(Back to Top)

Project Description Example:

Aegis Sciences Corporation: Requisition System Automation

Background
Aegis Sciences Corporation is a forensic chemical and drug-testing laboratory specializing in Zero-Tolerance Drug Testing® for businesses, professional and amateur sports drug testing, pain management physicians, and medical examiners.  We offer services for medical examiners, coroners, pain management physicians, colleges/universities, sports organizations, crime labs, healthcare organizations, and businesses.

The key market segments for Aegis services include:

  • Sports (e.g., Nascar, WWE, MLB Players Association, etc.)
  • Crimes (e.g., medical examiner services, post mortem testing, etc.)
  • Healthcare (e.g., pain medication compliance testing)
  • Workplace (e.g., drug testing, pre-employment screening, etc.)

Problem Statement
Aegis Sciences receives authorizations for testing, referred to as laboratory requisitions, from physicians, clinics, patients, and sports agencies.  Currently, the forms are in a paper format.  Hence, paperwork is sent in bulk to our clients.  Then, the paper requisitions are returned with the patient samples to be tested.  The form includes Patient information as well as the requested tests to be performed.  Upon receipt, the information on the form is manually entered into our laboratory information management system prior to any testing being performed.  The information is then used for scientific testing, billing, and results reporting.

Team Project Objective
Our main goal is to develop a paperless process with our laboratory requisitions that is electronically secure, easy-to-use for our clients, and more efficient and effective for our internal processes.

Some of the specific outcomes desired are:

  • Reduced paper storage
  • Quicker receipt of patient (and insurance) information
  • Ability to forecast testing volume at least 24 hours in advanced
  • Reduced data entry errors and rework
  • Functional areas obtain the specific information that they need in a timely fashion

The ultimate goal is to have a system where the collection sites (i.e., clinics) are able to submit a sample requisition form to Aegis through an electronic medium and that information is correctly dispersed as needed to the appropriate functional areas. 

This project is a critical 2012 project for Aegis due to the rapid growth in sample volumes that Aegis Sciences is experiencing.  It supports both the strategic goals of the company as well as increases the ability to service our clients in a more timely and quality manner.\

Project Contact
Project contact’s name, title, department, organization, email address, phone, web address
Executive Sponsor (name, title)

(Back to Top)

Getting Started on Your Project Proposal

Go to “How Projects Work - Getting Started.” Please be sure to adhere to the proposal deadlines shown so you don’t miss out on a semester.

(Back to Top)