Question

Job Title and Qualifications for Part Engineering

  • 7 July 2021
  • 5 replies
  • 105 views
A
  • Anonymous
  • 0 replies

We need to hire someone to help us engineer parts but I don’t know what job title to use that would help attract potential candidates. We’d like someone with a technical background that has (or could achieve) a fundamental understanding of BOOs and BOMs and the manufacturing process. They’d also need to work with our sales team to provide custom quote requests in more of a sales engineering role. Is there a set of commonly used job titles for the product/part engineering role? Have other companies found that people with engineering backgrounds and degrees are better suited for these roles or is an engineering degree overkill in most cases?

 

Currently my VP of Products and my project engineer work with me to engineer parts. We have a product specialist that doesn’t quite have the horsepower to do more than duplicate and make small modifications to existing engineered parts.

5 replies

S

We’re a machine shop, Make to Order and Make to Stock. We have ‘Estimators’. These people do not have engineering degrees. Their strength is knowing the capabilities of the equipment (saws, lathes, machining centers, assembly, etc.), and understanding the materials we typically use. We’re primarily a plastics shop, and machining some of these materials is significantly different from machining others, both in regards to times and tolerances.

Our Estimators typically are ‘home grown’, reqruited/promoted from the shop floor.

tshoemaker
Userlevel 3

I have often asked companies “What kind of engineers do you have: 1. Sales engineers, 2. Design engineers, or 3. Manufacturing Engineers”… Each has a place, and where I worked we had several of each kind. The sales engineer can figure out enough about the product to spec out and price a product for sale. the design engineer creates the detail drawing and specifications to meet the need, but it may not have any instructions on how to make it. Finally the Manufacturing engineer takes the drawing, specifications, etc, and knowing their capabilities, decides what is needed to make the product. They build out the BOM, the Routing, and define what is purchased vs made. 

Some companies, all three of these positions are the same people. Others might combine 1 & 2… others might combine 2 & 3. but what it sounds like you need is the last one… the design engineer that says “how do we make the engineered product.

Note that in Epicor, the BOM is NOT the exact ingredient list if items in the finished product. It is the ingredient list that is required to MAKE the product. In some cases, you need to make extra, or mix extra epoxy, or extra paint, or extra wood to actually make the product, but before you are done, you grind or cutoff the extra that was required as part of the manufacturing process… a pure design engineer doesn’t always plan for the extra, and they only look at the BOM that is in the finished product. (OK that is maybe an over generalization… Sorry to all the great design engineers out there).

Tim Shoemaker, Sr Principal Product Manager, Epicor Software, Rapid City, SD 949-294-0203
M
Userlevel 1

Speaking as an Engineer that works on Product MoM’s, I think the answer to your question somewhat depends on what kind of salary level you’re thinking of offering for the position.  For example, if you’re planning on treating it more like an administrative job, “this is the person that creates the parts on the computer for us”, then advertising the job as an Engineering position would be the wrong call because professional Engineers would be put off by the basic admin pay.  Alternatively, if you plan on treating it as a technically skilled job, where the person requires good engineering knowledge and Epicor ability, then advertising it as an administrative role won’t attract people skilled enough.  Consider who you’re targeting.

As Tim described above, our company has Sales Engineers who deal with the customers, Design Engineers who design the products and “own” them, and Manufacturing Engineers who design and “own” the processes to build those products.  I was a Manufacturing Engineer who was assigned to the team pulled together to implement Epicor in our company (circa 9 years ago).  Initially I was just setting up the Engineering side of the system, which meant creating all the parts & MoM’s to get the system running.  Once we went live, the creation of new parts became the responsibility of (mainly) the Design Engineers and (occasionally) the ME’s.   They create the part, then send out alerts to representatives of various departments to have them enter their specific bits of information (e.g. Procurement enter supplier info for purchased parts, Finance enter the financial information and carry out the final cost rollup and check the costs, etc).  Once all the info is in, the Engineer is responsible for releasing the part.

New MoM’s are made as a collaboration; the Design Engineer creates the Engineering BoM (what Tim describes above as the exact ingredient list), then hands it over to the ME, who adds the Operations and any additional materials/scrap rates to turn it into the Production BoM.

As the years rolled by my job title was changed from ME to ERP Support Analyst - Engineering, but that’s more because I’m treated as a system super-user; I took on supporting Engineering, Procurement, Planning, Stores, and Production.  These days I spend more time introducing system/process improvements and offering day-to-day user support than I do tweaking MoM’s, but I’m still the one they come to when they have an overly complicated MoM to design.

The one thing I would stress above all others is don’t underestimate how complicated MoM creation can be.  Depending on how complicated your products are, and how much of your business you run through Epicor, the ability to create detailed MoM’s that accurately reflect your production reality well enough to allow accurate pricing, planning, scheduling, etc, can be an incredibly complicated process.  Somebody with a good technical mind, both for understanding the production process they’re modelling and understanding the many elements of Epicor that can affect it, is a wise approach in my opinion.  They also need to be a logical thinker - the ability to create a MoM that works requires a good understanding of how MRP logic works.

tshoemaker
Userlevel 3

Story Time: I once had an argument with a DESIGN ENGINEER over the “accuracy” of the BOM in the ERP System. He said “We cannot have BOMs that inaccurately describe what is in the finished product”. He wanted the BOM to be “Exactly” what was in the final shippable item. He thought that the ERP system was his design document.

I referred to the ERP system as the “Electronic BOM”… and it needs to describe everything we need to buy & make, not just what is in the final product. An extreme (ok… maybe odd) example: If you are going to make Hard Boiled Eggs, you need water. The water needs “issued” from stock, and it will be consumed, but, it is not in the final product, nor can it be returned to stock. The Mechanical Engineer needs to account for all the tools and supplies that are needed for the manufacturing process.

Tim Shoemaker, Sr Principal Product Manager, Epicor Software, Rapid City, SD 949-294-0203
M
Userlevel 1

Interestingly we went through something similar at the start of implementation.  Some Design Engineers wanted Epicor to control the build standard of their products, and therefore felt it should only reflect a BoM that matches the drawings exactly.

They were re-educated to the fact that an ERP system is a business-wide system, not just for one department.  It needs to know everything needed to make a product so it can a) control the stock of those parts and order when necessary, making sure you have enough stock to cater for wastage as well, and b) accurately cost your product, so you know how much it really costs you to make it, so you know what to charge your customers.

Across the board, persuading multiple departments that were used to only thinking of “their little bit” of the business to work with an ERP system that connected everyone to everyone else was an interesting challenge.   In my experience the people who use the system best are the people to take the time to learn how their actions/information in the system affect other departments, the “if I tweak how I enter this, it makes your life a bit easier every day” kind of scenario.  It’s one of the reasons we try to set up collaborative working (e.g. part masters) where we can.

Reply


Terms & Conditions