Вы находитесь на странице: 1из 5

EGR402 Using OSCAR

Role of an Engineering Department


Tech companies usually have a matrix organization:
P1 P2 P3 P4
Corporate
R&D
Finance
Sales
Engineering
Production
Support
Services
P1, etc represent product families. The functions on the left may serve all products but for
larger companies, everything below R & D may be dedicated to one product. There is an
inherent conflict of interest between the product managers who want to optimize their own
product (and bonus) and the functional leaders who desire to get economies of scale and
uniform (high) standards across the whole organization. As usual, some competition is good;
too much makes everyone forget that the real competition is outside the company.

The Engineering department is responsible for the technical performance of the products.
That usually means design, test and data organization. That does not mean that the views of
the other functions can be ignored for these functions. It is simply that engineering takes the
lead role, consults the others and is accountable for the outcomes. Since engineers frequently
move from one product division to another (through opportunity or a re-org), the engineering
leaders try to establish a common methodology. This takes two forms:
a. A standardized product life cycle where Engineering is responsible for system design,
detailed design, prototype validation and production standards. Data and explanations
are required for all activities to meet standards and possible legal challenges. The
process is managed through a demanding series of stage-gate design reviews.
b. A common process to identify what has to be controlled as well as the impact of all
parameters and variables on performance. This is the OSCAR process. It applies
equally well to systems and to small components.
The names and details in these processes vary by company but they all serve the same purpose.
The common language and methodology mean that engineers can be moved or contribute to
other design reviews with minimal additional learning. Since trouble-shooting is really just
design in reverse, they can also be drafted to emergency teams for root-cause analysis.
The OSCAR process
The EGR policy to pursue realistic capstone projects means that students should appreciate the
role of engineering in an organization. As stated above, the engineering department in a
company is responsible for the technical performance of processes and products. However,
being numerate and analytical, engineers also find very diverse employment opportunities in
marketing, R & D, manufacturing and field support. Thats great for individuals but the
capstone goal is to cover the primary function of engineers to manage technical performance.
That means design and qualification supported by data generation/organization/analysis. As
you should appreciate by now, there is (always) a process to achieve the goal.

The system map shows how the engineering process (inside the box) contributes:

Start Constraints: End


Resources, knowledge, assumptions, time

Sponsor OK ? Sell Sponsor


DoE
Plan: Tests, Delete
Problem (Re)statement analysis, or Problem
Budget
Schedule conclusions redefine
$$$ Performance
Payment $$$
Quantitative
Time solution Transfer Time
strategy function(s)
aka: equations Archive
History
linking I/O and
parameters

Constraints: Materials, tools, technology

Note the multiple dialogs that have to go on with functions outside the box. In the initial
stages of a products life, marketing leads; in production, its the manufacturing engineers.
However, in the critical design and formation stage, the engineering process (in the box above)
dominates. Specifications are always subject to ambiguity and uncertainty. The first step in
the sequence is therefore to state the problem or desired outcome in the terms that engineers
use to realize it. That then becomes the definitive statement against which the work is done.
You did this in EGR401. Then theres a carefully documented series of steps to select the
implementation that will best match the requirements. Its a transparent process; customers,
sponsors, users and other company functions see the statements of work and if they dont
disagree, they have no grounds for complaint later. This pre-emptive process is important
since if something does go wrong, theres no shortage of experts with perfect hindsight.

Meet your friend, OSCAR


The usual technique to help people remember a process is to base it on an acronym. In this
case, it is OSCAR.

O S C A R

Objectives Strategy Conditions Actions Records


Goals Plans Imposed/free Design for X Lab books
Requirements Last time .. Technology Simulate Syntheses
Problem fix Methodology Sequence Orders Progress
Mistake-proof Quantify Suppliers Build Minutes
Disaster recovery Sub-divide Stress Test Summaries
RFP/Q Resources Materials Get data Distributions
Suppress failure Tools Environment Analysis Metadata
Exploit success Deadlines Components Validate Archive
Safety Keep info. Publish
Approvals Reviews
Transfer functions

Outputs = f [inputs, boundary conditions, constants, parameters]

The diagram spells out the scope of the steps in the engineering box. It would be nice to start
at the top left and proceed rapidly through each column. Unfortunately, we all know that its
not like that. There are:
Interactions between topics that lead to compromises.
Changes in priorities during the project.
Gaps in knowledge or data that need side-activities.
Mistakes, misunderstandings, screw-ups, breakdowns, delays .
Surprises from your other team member, Mr Murphy, etc.

The useful feature of this process is that it forces you to consider a wide range of topics. Even
if you decide that you can/will do nothing about them, thats much better than ignoring them
and being surprised later. It is very sad to see that response to a question in a design review.
The silence says it all.
Application of OSCAR in the project
Get used to applying the process. It applies equally to large and small tasks, from a whole
project to a single experiment. If an abyss of ignorance is discovered, there has to be a pause
while its scale and importance are assessed. That leads to more learning or a detour using the
same sequence for analysis. OSCAR is also a template for the way in which any claim for
success would be laid out. Throughout the course, every student is expected to follow and
demonstrate the OSCAR process. It has to be practiced to the point where it is instinctive.
Hiring managers like that.

Note that there are three thinking stages before the action starts. Why? A safe answer is
always: cost. Thinking is a lot quicker and cheaper than action. The problem is that thoughts
are personal and transient so we have a process for that too. Its called a notebook. When
you think you are ordered enough to put a little progress peg in the ground, you create a
working report.

In past capstone projects, many teams found that the time to build and test one prototype
absorbed all their efforts and the result was a shortfall in the engineering component of the
project. They achieved the first requirement of a prototype to demonstrate existence and
maybe functionality. However, theres a second-level engineering expectation thats at the
core of the capstone experience - to quantify performance constraints and generate data to
support opportunities for improvement. Most projects didnt get to that stage. Accordingly,
EGR401 (starting in January 2017) placed more emphasis on demonstration of the prototype to
leave more time in 402 for engineering development.

The single most important line in the diagram above is the bottom one.

Outputs = f [inputs, boundary conditions, constants, parameters]

This encapsulates the engineering dimension. You have been looking at these equations for
years but may not have appreciated their design significance. You are unlikely to ever to have
to formulate the equation. Thats done in lectures to show the logic and principles behind the
behavior. From now on, just look it up and amend it to suit your application. There are three
important points to observe:

The equation tells you what you have to know, understand and control. These terms
will then be the basis of your tests and analysis.
It tells you which factors are most important. For example: ex is much more important
than x but only for certain values of x.
One equation may be enough for a simple experiment. However, for a system, multiple
equations apply so its a more challenging problem. The converse is also valid break
the system down into cause-effect interactions that have simple relationships that can
be analyzed after simple experiments. Simple = easier = move on, thank you.

Conclusions
Practice the OSCAR process. In doing so, youll find that many of the terms are not important
for your project. Thats OK; they can be shunted to the sidelines - but not forgotten. Get the
simple parts right. Everyone expects you to manage them. It will let you go further and faster
with the more difficult problems where there is more tolerance but also plaudits for progress.

Document everything. It takes time but doing a job once no matter how slowly is always
better than having to take multiple attempts (and be seen to be wasting resources).

J Robertson 7-3-17

Вам также может понравиться