MECOP Internship Report

OECO, LLC
Charles Thompson, MIS
Senior Internship, June – December 2007
December 2, 2007

12/04/07 12/04/07

i
Contents
Introduction .......................................................................................................1
Projects ..............................................................................................................1
Executive Summary.............................................................................................1
MSDS System ..................................................................................................1
Resin Mix System ............................................................................................2
Receiving/Inspection System...........................................................................2
Detailed Discussion of Work ................................................................................2
MSDS System ..................................................................................................2
Receiving/Inspection System...........................................................................3
Conclusion..........................................................................................................5

ii
Introduction
For my second MECOP internship, I was placed with OECO, LLC, a 300-person company located
in Milwaukie, Oregon that manufactures electromagnetic devices and power conversion
products, mostly for the aviation industry. I worked for Tim Krajcar, head of OECO’s three-
person IT team. My role as an MIS intern mainly encompassed the development of web
applications for the company intranet. My applications will be used on the manufacturing floor
to support operations.

Projects
Material Safety Data Sheet (MSDS) System – Web solution consisting of a
comprehensive database of MSDS files kept by OECO as per OSHA requirements and an
application for management of the database.
This project consisted of several distinct sub-projects:
o Requirements gathering
o Gathering of MSDS files
o Database development
o Application development (general user and administration components)
o User education (including nearly all 300 OECO associates)
o Reconciling the digital system with the pre-existing vertical file containing
physical datasheets (printing new datasheets, scanning old datasheets)
o Documentation
Resin Mix System – Web solution to address costly miscalculations when mixing resins.
Receiving/Inspection System – Web solution to replace existing MS Access system for
processing incoming inventory before use in production.
Electronic Stamps – Digital versions of stamps used on physical documents such as
engineering drawings for a number of uses including conformance with International
Traffic in Arms Regulations (ITAR).
Obsolescence data – Parsing of data stored in an awkward format so that it could be
provided to buyers.

Executive Summary
MSDS System
I designed the MSDS System to enable OECO associates to quickly access information on
potentially hazardous materials. I did this by providing a simple search interface for them to use
to look up the material safety data sheet for any of the 740+ materials used at OECO. The
benefits of the MSDS System are twofold. Firstly, the time taken to locate and update MSDS
files is reduced. And secondly, there is a significant cost savings associated with maintaining
MSDS records in-house. An outsourcing alternative considered before I was assigned the

1
project would have had a recurring cost of $8,952. The cost to have me do it was estimated at
$5,600. That’s a cost savings of $3,352 in the first year alone.

Resin Mix System

The Resin Mix System is designed to address a problem that occurs periodically when
production workers mix resins in incorrect proportions. While uncommon, when this does
happen, it is often the case that large amounts of product are rendered useless and must be
discarded at a high cost. Jeff Williams determined that a key reason for such an occurrence is
that an associate has made an arithmetic error when calculating the various amounts of
ingredients needed to mix the resin. He came to me and Tim with the suggestion that we create
a system that does the arithmetic for them. While I developed a working prototype, it needs
more data. What remains to be done is for a complete set of resin recipes to be added to its
database.
Jeff tells me that last time a resin mistake was made, the cost was $10,044. Since this happens
an average of twice a year, my solution could potentially save the company $20,088 a year.

Receiving/Inspection System
My Project for Receiving/Inspection is essentially a redesign of the system they had in place
when I started. The old system is very inefficient, often forcing associates in the
Receiving/Inspection department to find other things to do while thousands of records are
accessed merely for the sake of displaying a handful of them. The Receiving/Inspection System I
put in place requires that only the records to be displayed are loaded, thus drastically reducing
the time users take to do their job.

Detailed Discussion of Work

MSDS System
I really built the MSDS System from the ground up. The only elements that were in place
when I started were the servers and infrastructure (OECO’s intranet) to host my applications
and the template for the “look and feel” of the user interface. Tim had purchased me a license
for ColdFusion and I downloaded the Eclipse SDK so that I could take advantage of some of its
built-in functionality to make pages using the ColdFusion tags. For the first couple of weeks, I
just brushed up on my SQL and worked my way through a ColdFusion tutorial, making a dummy
example application that dynamically generated queries based on user input.
It didn’t take long to master the simple ColdFusion “syntax” and by about the time I had
it down, I had managed to migrate OECO’s existing MSDS records to some tables in a MySQL
database. Since the application I made with the tutorial had many analogs of features I needed
in the MSDS system, I was able to start developing parts of the MSDS system simply by plugging
a different data source and changing the names of variables used in my queries and my
ColdFusion pages. Within about a week I had developed a search that provided a collection of
search results that each contained a link to a “details” page with information on a material.
A key requirement for the MSDS system was to provide actual copies of the datasheets
to users. Since, I knew I would need them and it was likely that the newest editions of them

2
could be obtained online via the web or via email, I set out early on to get digital MSDSs of all
740+ materials for which OECO needs them. Thus, by the time I had a working prototype of the
system, I also I had about 70% of the datasheets in digital form. Using ColdFusion’s file
manipulation faculties I managed to link each datasheet to its details page.
Another requirement was that certain users be able to update a material’s record.
Satisfying this requirement became my focus once I had reached the working search/details
stage. This portion proved to be much like the “details” portion. However, manipulating records
in a sufficiently limited, consistent fashion proved considerably more challenging. When I had
finished users could search for a material, select it from the search results to view in more
detail, and access the details to change or delete them. In addition, users could create new
records as new materials were put in to use at OECO.
With the application and database finished and about 80% of its files acquired, I now
had to instruct about 300 OECO associates in how to use it. Tim scheduled me a day to bring
people through in groups of 20 so I could take a few minutes to give them a class in how to use
the MSDS System. It was an interesting day. By about the fifth session I had it down, knowing
how people would respond to different pieces of input.
At this point, the most basic requirements had been met. Workers could now look up
most materials and view the datasheets corresponding to them. However, there was a
substantial amount information which had changed upon obtaining new datasheets and which
could only be updated by hand given the format and variety of layouts of datasheets. I had
already begun work on other projects, but for a while I spent many hours visually inspecting
datasheets and updating their records. This, however, was not time wasted as I was then able
to leverage the new data I had gathered when I reconciled the old MSDS system with the new
one; scanning the 20% that could not be obtained digitally and printing ones which I had that
were newer than what we already had. Without the data I had gathered the process would
have entailed physically examining every printed MSDS, a process that could have taken weeks.
Since I had already gathered comprehensive data on the new ones and I had the pre-existing
record for the old ones, I was able to do this job in just five days.
In addition to supporting my MSDS system by getting new datasheets and making the
physical and digital versions match. I also knew that it would be essential to its success that I
describes the database and application in technical terms for to person who would be in charge
of it once I was gone. That is why I wrote a 6-page technical document describing the design
choice I had made and how they contributed to the final product. It is my hope if changes need
made to the MSDS system in future, that it will be made easy by this documentation.

Receiving/Inspection System
At the time of this writing I am still at work on the Receiving/Inspection system.
When OECO receives a part, it must be inspected before it is used in an assembly.
Currently, the inspection is performed and recorded using MS Access. While the interface
elements of the current system are decent, the design of the database tables behind them is
terribly flawed. Furthermore, when a Receiving/Inspection associate follows the steps to bring
up a record, Access loads far more records than are needed leading to absurd lead times when
receiving and inspecting parts. I have been assigned the task of developing a database and front
end to alleviate these conditions.

3
 The parts in the system are of four classes; Boeing Mechanical, Boeing Electrical,
Military Mechanical, and Military Electrical. For each class of part, records are stored and
accessed for two purposes; accessing and updating a part’s receiving and inspection history and
accessing and updating a part’s inspection requirements. Thus, an application supporting both
of these functions for each class of part should consist of 2x4 or eight modules, each one
slightly different from the others.
Developing a new version of the system would pose few challenges if it wasn’t for the
deplorable table design behind the inspection requirements forms. Whoever designed the
portion of the inspection requirements form that stores actual inspection requirements
intended for it to be an open-ended table with cells for different data arranged in such a
fashion that their meaning is made clear by observing their layout. For example, a string
appearing in the column labeled “parameter” and in a row that contains a procedure number is
understood to denote a class of procedure, not a parameter. This would be fine if the table or
tables behind the form reflected this difference, but this is not the case. Instead, this portion of
the form is merely copied verbatim from a single table. Thus, there is no semantic difference
between a row that labels a procedure and a row that stores an actual element of that
procedure.
In addition to not restricting what is represented by a particular column’s values , there
is no pattern as to where within a collection of rows a particular row will appear or even as to
whether or not the row will even be present. As such, the procedure number for a set of
inspection requirements may appear in a special row that serves as a header, it may appear
within the row of the first requirement, or it may not appear at all. This is due to the fact that
users have been taken plenty of creative license when arranging the data on the page, making
to impossible to parse into new, cleaner tables without ruining at least a few records.
With things being the way they are, I have made an effort to break apart the rows as
best I can. I have decided to err on the side of leaving out data stored in the wrong place rather
than trying to handle automatically every special case where somebody has bent the rules. It
has been an understanding among myself my coworkers since I began work on this project that
it may entail that some records will need to be re-inserted into the system because it was lost
when I fail to perfectly translate how each of 96,397 rows fits into its record.
Upon reading what I’ve written here, it should become obvious why such a big part of
what have to do for this project involves imposing a new structure on the existing data. Once I
have determine the best way in which to do this I can implement it and once every record I
mangled in process is updated—a process I can tie in with regular use—there’s a good chance
that the system will never again be so grave of a mess. In fact, OECO may one day even be able
to leverage its receiving/inspection data to improve their lead times and those become more
competitive.
At any rate, what I have contributed toward this end so far is the building blocks for an
approach to breaking apart the inspection requirements table into a schema of tables that are
more useful and usable (including an actual implementations of this for each class of part, and
the module, for each class of part, of the front end web application that deals with the
inspection requirements. I have also created working model for how rows can be added or
removed from an inspection requirements module. What remains to be done is to merge this
dynamic record manipulation model with each of the existing modules and to make them place

4
data into the new tables which I’ve crafted from the old ones. I also need to develop the four
history modules of the front end. It is my sincere hope that I can have all this completed by the
time my internship is done.

Conclusion
Of my two MECOP internships, this one has certainly been the more rewarding and
productive. I truly feel more accomplished for the time I’ve spent here and the work I’ve done.
OECO has helped me claim the benefit of a variety of technical skills including database
normalization, database design, web application development, basic version control system
use, use of the W3C Document Object Model, and use of ColdFusion, MySQL, JavaScript, and
ajaxCFC.
In return, I have given them a complete solution for managing Material Safety Data
Sheets, provided them with a potential solution to costly errors in resin mixes and developed
most of what is needed to reduce lead times in Receiving/Inspection.

Here are some lesson’s I’ll take with me:

Finishing a solution is not the same as implementing it – When I wrote the last line of markup
on the MSDS application, my job wasn’t finished. In fact, it had practically just begun. In order
to ensure the system achieved its goals, I had to tie the processes associated with its precursor
in with the new system and integrate it with parallel workflows such as the labeling of materials
using it. This required that I train many people on how to use it and also that I do plenty of low-
tech, labor-intensive hand work to integrate it with what was already in place.

When intimidated, start small and build up – I spent perhaps more time than was warranted
hesitating out of intimidation by the Receiving/Inspection project. It seemed like such a big
undertaking that I was afraid I would waste time if I took the wrong path when addressing it. I
should have taken a lesson from any of my many math classes throughout the years; To tackle a
big problem, you’ve got to break it into smaller problems and tackle those. Another strategy
that helped was to go and talk with users to gain a better sense of the situation. This helped me
to pick a portion of the whole as starting point that I could duplicate in altered form until I had
about half of the project practically completed.

User buy-in and cooperation is a must – Even with all the potential benefit and the high degree
of completion on the Resin Mix system, it’s fate seems uncertain without the expertise and
labor required of administrative users who will have to supply it with data.