Proximity in Operations

The time to work together is sooner rather than later
(Courtesy of www.engineeringdaily.net)

The strongest operations will purposely locate the engineering as close as possible to the manufacturing operations.  It has been proven over and again that this encourages dialogue between he two groups which benefits the operation.  But what about  within an engineering organization?  Are there good ways to set up an organization to maximize the engineering talent?

One of my earlier posts relayed my positive experience with Integrated Product Teams (IPTs).  This involved having members from different functional groups together in one group to successfully design and support a product.  However it is not enough to have these members in one group.  They must sit together or near each other to make it work.

At Boeing I was a structural design engineer.  My closest associate I worked with was the stress analyst.  It was our job to work together to develop a statically and dynamically robust design that would be eventually manufactured.  So he and I sat next to each other , even sharing a common table between us.  This allowed us to lay out drawings and sketches to discuss design details immediately rather than travelling across an office to work together.  Other functional members sat close by so even though I interacted with them less frequently, they were close by to discuss details.

Better designs evolve when everyone resides near each other
(Courtesy www.astrocenter.tamu.edu)

Many companies still embrace they idea of  the same functions (i.e. stress, design, manufacturing, etc) sitting together in an engineering operation.  But this idea allows groups to become an "us" versus "them" philosophy that stagnates production.  It is better to sit together and then "we" can use engineering skills to a better advantage.

Work Breakdown Structure (WBS)

The key component to managing any project in an operation is the work breakdown structure (WBS).  It is the very essence of what tasks and steps are needed, who will perform them, and when they are due to keep the project on task.  It takes effort to build the WBS to be effective, but there are several tips to remember to help.

An example of a WBS for a dinner party
(Courtesy www.chrisitaindenard.wordpress.com)

First, keep the tasks small enough so that one person can work on them independently on a full time basis.  By assigning the task to one person, you have established responsibility belongs to one person and he or she knows it is all on them to keep on track. If the task is too big, one person will be overwhelmed and the quality of the completed end item will suffer.  If you have two or more people assigned to a task, each may think the other(s) will complete it and as a result no one will see it finished.

Second, keep on top of the program schedule.  This sounds like a "no-brainer" but from my experience some project managers believe tasks can be performed on auto-pilot.  Depending on the project you should have at least one or two schedule reviews every week in order to address schedule challenges or delays.  It will happen so it's a good idea to be able to be ready to establish work around actions that will bring tasks back on target.  Management will ask what you are doing to fix the problem so have a plan developed quickly.

Third, get management's understanding that sometimes you need help.  There will be times when you need additional help due to unforeseen circumstances.  You or your designates may not be able to fix it by themselves.  That's why it's a good idea to sit down with your boss and get their buy in that they can get you help immediately if you need it.  A good manager will have a sense of urgency and support that will drive them to borrow or pull resources to you to help complete the process.  You won't really know until it happens but it's essential to prepare them for the possibility of a request in advance.

Establishing work tasks is essential to successful operation
(Courtesy www.sciencephoto.com)

Experienced Workers in New Positions

(Courtesy www.islinguists.com)

One of the benefits of hiring an experienced worker is you can expect him or her to be able to ask the right questions, look for answers on their won, and generally find out how to do their job without a lot of oversight.  However if a person is hired to your organization based not as much on direct experience but on common, transferable skills, it  is essential that there be some allowance for learning for the new position.

From personal experience, I have had this happen to me.  I was hired as an experienced engineer at Boeing to help out a group.  However the new group's task (passenger seat integration) was new to me and required some initial learning and mentoring that I never received.  Needless to say my experience was not a pleasant one and I eventually left the group.

Here are some ideas to integrate an experienced worker into a new role:

• Find out how much experience he or she has in the new area. Then fill in the gaps with classes, training, and mentoring to get that person up to speed.  It shouldn't take long for an experienced worker to grasp the new details so this is time well spent.
• Get feedback from the new worker.  Sometimes managers (especially younger managers) are reluctant to talk to a seasoned worker.  Get over it.  Your organization's success depends upon the solid performance of it's workers.  Let them know you care.
• Find out what areas the worker excels at and give them projects that showcase those skills.    They can help your organization by tapping on previous experience while learning the new job at hand.  

(courtesy: www.cochrenfoundation.com)

From an engineer's perspective it is important to know that while many skills are transferable there may be gaps that need to be filled in.  Don't just throw someone into the deep end of the pool and hope they know how to swim.

Database Management

For an operation to be successful many items need to be tracked in some type of database or software system. These systems are often used by manufacturing, engineering, and even management to track an event or project that all three groups (and more) have a stake in.  If one person is in charge of input and output of the database (including management report outs) then if is a straightforward process as long as you can depend on that person.

Database management requires keeping status current
(Courtesy: 8u.fotomiser.com)

The problem comes when you have many people tasked to keep status on a project.  I have been personally involved in several of these scenarios and it is always a struggle to keep the database updated on a regular level.  One such program required the engineers to track data set releases and provide revised  estimated completion dates (ECDs)  if scheduled events were going to be late.  As the focal for the database, I would often have to track down particular engineers and extract a new ECD and input it into the database for them.  It was a lot of extra work which was unnecessary if the engineers were more diligent.

There are several things that could have been done better to help the process go better:

• Have management emphasis (and enforce) the importance of keeping databases current with the latest information.  Employees will focus on providing updated information if management is keeping emphasis on timely updates.  Management must not just send e-mails out requesting updates; they need to personally talk to those who are tardy on their inputs.
• If several groups use the database, assign one person in that group to be responsible for ensuring updates are happening.  It is pointless for one single person to be responsible for inputs of hundreds of users.  Break the task up and get help.
• Schedule daily stand up meetings to allow those who are tardy to explain to upper management why they haven't kept up.  I guarantee that this will ensure the database is current.

(Courtesy: www.gettyimages.co.uk)

Rejections on the Floor

An inevitable fact of life in operations is the occurrence of errors or rejections on the shop floor,  Upper management is always striving to "eliminate rejections", "work smarter", or some other catchy slogan to eliminate errors.  But the best you can do is to implement checks and balances in the process to help reduce the error count.  What you do when you have an error on the floor is just as important as trying to avoid it initially.

(Courtesy www.unlimitedchoice.org)

Many medium to large companies have an error reporting system established whereby standard rules are followed when a rejection occurs.  Once an error is reported or written up (usually by Quality Assurance) it is essential that the information is accurate.  Some key things to check:

• Are the correct part numbers listed in the rejection write-up? I have seen many error reports (often called rejection tags) that have the incorrect part numbers and or descriptions in error.  This is a problem if there was ever a need to go back and look at a repair later and the records were in error.
• Is the error write-up clearly written? If there is confusion on what is really in error, then the incorrect analysis and repair methodology will not effectively address the issue.
• Will a repair impact downstream users?  If your repair will effect any downstream users you must coordinated before you provide your repair fix (disposition).  Otherwise bigger problems may occur that will adversely affect schedule.

For those weighing on the repair, be certain they have the necessary skill and experience to effectively analyze the problem.  An inexperienced mechanic or engineer may have good intentions, but a lack of experience in a key juncture of the operation could be a problem further down the process.

Finally it is essential to keep a record of the different rejection scenarios that one encounters on the shop floor.  Some times repairing the error requires a unique fix that should be shared with others to help educate them.  This is most important if it is second shift or a weekend and subject matter experts are unavailable.  A good database will help locate a similar issue to consult for you rejection at hand.

Rejecting discrepant parts is a fact of operations management
(Courtesy www.blg.gov)

Testing

(courtesy www.beaed.com)

A critical but often overlooked element in operations is testing.  It is an activity that doesn't relate directly to full production but the results gained from testing will prove or disprove a design or process.  That will determine whether your chosen design will be allowed to full production.

For larger companies,  testing is scheduled and run by a separate test group. The design groups have some say into how the testing will be done.  The testing group will be able to determine the location and specification of measuring devices, the accuracy of the measurements, and ultimately the validity of the results.  It is important for the design or manufacturing group convey the purpose of the test to the testing group, otherwise the testing group may assume the wrong objective and this will potentially invalidate the results.

For testing purposes the testing group will require that one or more people from design and manufacturing groups be available on site during testing.  Testing lasts anywhere from one day to a week so you need to make sure staff is available to support the testing.  Those supporting the testing should be knowledgeable of the purpose of the test; preferably more experienced personnel rather than a junior engineer or mechanic.

(courtesy www.knifilters.com)

Once testing is complete, immediately evaluate the results to determine validity.  A thorough operation will have predicted (hopefully accurately) the results prior to the test.  Then there are no surprises once testing is done.  With the right planning, a testing operation will proceed smoothly and results will validate the design successfully.

Compatibility of 3D CAD Graphics Systems

The design and operations world has many options available to use in designing, manufacturing, and assembling a product or system.  These include CATIA, Unigraphics, ProE, Solidworks, AutoCad, and others. While all of these software packages have strengths and weaknesses, it is important to have a way of translating a 3D design from one system to another.

(Courtesy of images.frompo.com)

Hopefully, within an organization, a company is using one type of software (and the same version) when sharing a design back and forth between engineering and operations. It seems impossible that a company would use different types of software, but I have seen it done.  Obviously this creates problems right away and I would suggest that these types of companies don't have an idea what is going on.

The biggest challenge occurs when a company contracts out a design to another company and different software packages are used.  This happens quite often where different contractors win bids with different companies.  Rather than try to institute a new software (expensive and time consuming) the two partners use their in-house software packages.

To get different types of software packages to share designs, translation software is used.  Files are created and used to translate a CAD model from one software to the next.  In an ideal world this process should take no more than a couple of hours.

However, several things can go wrong.  First, the type of translation software may not have been tested accurately.  A computer or IT person may thing everything is good, but an engineer or operations person may find there are errors including the misfortune of an "unreadable model".

The conversion process may take several days which is clearly unacceptable in a fast paced industry with little buffer built into its schedule.  For delays in processing the translation many people usually have to help fix the problem, which pulls them away from other work.

Even in a normal design or manufacturing iteration, the amount of back and forth review and changing of models is time consuming and that may not be desirable in order to meet schedule.  For this reason alone, careful consideration must be given to what types of CAD packages are being used by your group and those you do business with.  It pays to work this our early on or you may pay dearly later delivering late products to market.

(Courtesy of www.plm.automation.siemens.com)