development is never as easy as going from “What's the market solution” to “what's the engineering design”  - there are many decisions in the middle that need to be made around the general design, tech requirements, and main components. (For example - - How’s the chassis going to come together, what’s the power supply, how is it going to communicate?)



You probably use Excel for this. At many companies, or on start up teams, you might even find yourselves sitting around in a room and brainstorming mission critical questions with an EE, ME and IE, and creating a baking list of supplies.




At that point, you divvy out the tasks, and ask the questions you need to ask, determine problems you need to solve, and as you come up with the solutions, you come up with the bill of materials (BOM)


But the BOM you keep when you’re prototyping is not the same BOM you keep  when you’re ramping to production—it's a whole different animal. In fact, you probably don't even call your prototyping BOM a "BOM" because it's just a list of parts.


At Arena, we've become very interested in bringing some order to this (usually messy and disorganized) list of parts.



Well, with 80% of the product's costs being determined by the design, the logic follows that if you optimize your designs for cost/availability, you can design a better product more cheaply. But when early designs are scattered across disparate notebooks, emails and scraps of paper, it's pretty hard to know if you chose a component because it was the best one, or if you chose a component because it was the one you had the most information for.


That's why we invented the concept of the innovation BOM.


The innovation BOM provides a framework for organizing the traditionally  disorganized process of getting started with a design. It describes the list of parts that engineers are considering for a  prototype, and is primarily made up of possibilities for critical  components that will define the product, and notes about how these  parts may be sourced.


In a recent Arena blog post, we do a deeper dive into the innovation BOM, and outline 3 ways organizing your early designs into an innovation BOM can help you save money, time, and ultimately create better products. I invite you to take a look.


We've found that by simply by  thinking of this early brainstorming period as a systematic process, you  naturally provide organization to your designs and find more  opportunities to optimize.

At Arena, we work with a lot of high-tech electrical-hardware engineers and OEMs. In our thousands of conversations with prospects and customers, here is one of the most common questions we get - - if you revise a component used in your designs, or swap it out for a  totally different component, how far up does that revision need to go?


This is sort of a tricky question to answer with some major pros and cons on either side.


On one hand, if you always let minor changes to low-level parts trigger new  revisions to your top-level product assemblies (and all the intervening  sub-assemblies), you will quickly find yourself buried in a never-ending  stream of meaningless documentation updates. Which no one loves. Plus, if you're getting notifications all the time, you'll start to tune out and lose track of really important  product-level changes.


On the other hand, it’s easy to think of a component or sub-assembly  change, like a new motherboard or major mechanism redesign, that should  be tracked at the product level. If a major redesign of an existing  component inadvertently introduces a functional, reliability, or, in the  worst case, safety issue, you really want to be able to distinguish  which products contain the revised component and which don’t.


Our CTO has written a piece, "To Roll or Not to Roll"  which is designed to help you decide which type of changes really are worth rolling up the tree, and which ones can be looked at as minor changes.


Check it out!


Essentially, we think that the trade-off between traceability and cost is what counts, and you should be tracking all changes to assemblies when the benefit of  traceability exceeds the inventory and documentation costs.


Thoughts? Or do you have an interesting process that you'd like to share?

I have been hanging out a lot with a friend (let's call her Michelle)  who is in the middle of prototyping - - let's just say I am frequently  reminded how difficult it is to actually turn an idea into a physical  product. . . That particular skill isn't really in my wheelhouse, so I am always  impressed at the gargantuan effort it takes to create a prototype.


Like most products now-a-days, Michelle's product is  electromechanical and super complicated in nature, so sourcing the  parts, getting the right team and equipment in-house, etc etc took a lot  of time and money.


One thing she said helped her get through the pre-prototyping process  was 3D rendering - - especially at the point when she was trying to  establish some partnerships and get her ideas across. By creating visual  images of the idea before it was a reality, she was able to get people  to buy in, and she felt like it was easier to explain her idea to  investors, etc.


Rendering software used to be really technical and complicated, but  there are actually a lot of options out there for people who aren't good  at coding to try. Rendering allows you to tweak a model at virtually no  cost, and share visual concepts with team members or potential  investors much earlier in the process, so it can be a much easier way to  prototype your prototype.


Three Reasons to use 3D Rendering in the Prototyping Process

#1. Rendering lets you evaluate the product before investing in parts or suppliers.

#2. Rendering is an easy way to test out the market.

#3. Rendering gives you more time to design better products.

Has anyone out there used this tactic during prototyping? (And if you want to learn more, we published this article last week that shares more details.)

There's a lot of give and take when it comes to  setting up a change process, and a lot of factors that determine if your  process should be highly formalized, or loosely managed.


A loose change process, where individual engineers have the  discretion to either expedite change requests or make immediate  revisions, exposes your product to unintended consequences - - including  costly scrap and rework at best and field failures at worst. But  excessive review slows down the iterative process and burdens team  members, making it harder to innovate and rapidly improve product  quality.


When thinking about your own change process, here are some things to consider:


If you're early in the product lifecycle and had a small engineering  team, the details of the design will be very familiar to everyone and a  looser change process might work for you.


If your manufacturing process is vertically integrated (meaning you  can generally go downstairs and see the result of a change immediately) a  loose process might work for you.


However, if you are a large company producing higher-volume products,  it’s important to follow a formal change process in order to minimize  the chance of decisions with unforeseen implications.


Or if you have several engineering teams in different disciplines,  and there are a lot of opportunities for one change to impact another  aspect of the product, you might want a more formalized change process.


Arena CTO Eric Larkin shared his experiences running 2 companies - -  one with a formal change process, one with an informal change process. He talks pros/cons here.


One thing that he said stood out in particular to me - -


"I also recommend that companies experiment with a less formal review  of changes in the design phase and switch to a tighter approval process  in production—when mistakes can have major repercussions. And no matter  how changes are handled, product data needs to be centralized."


Does anyone else have experience, thoughts on this subject?

I wanted to share this cool infographic from the Arena Blog - 5 ways you can prepare your business to scale. This seems to be focusing mostly on how you can prepare as a hardware company (product data, operations/engineering focused) but I think it's a nice check list for anyone involved with bringing a product to market.

One of the biggest stressors of putting together a protoype (in my  eyes) is finding all the parts you need, getting the datasheets, etc,  etc, and building that first draft of the BOM. If it's at least easy to  find the parts you're looking for, with information on multiple  distributors, it makes the job a bit easier.


To that end, I want to share a new tool I have caught wind of, as part of my work at Arena Solutions. It's called Octopart,and essentially it's a search engine for electronic parts. It has a Google-like interface, and is really easy to use.


Andres  and Sam, who studied physics together at Brown, then pursued PhDs in  astroparticle physics and plasma physics respectively, are the founders  of Octopart—and  I was lucky enough to talk to them about how they came up with the  idea. I also got some great advice about scaling, the startup mentality,  and - - if you're looking for work - - some ideas for getting a job at  Octopart.


I  think the success of Octopart shows that electronic component  distributors are realizing that distribution is no longer the problem - -  it's finding the parts that you want, and being able to compare parts  across a variety of distributors. In some ways, it seems like the market  is demanding consolidation, and the ability to find/get what they want  in one place, and with less hassle. I think Octopart is actually on the  right track to solving this problem. What do you think? Will we ever  have one-stop-shopping for electrical components?


To learn more about Octopart


apple_ipad_23.jpgWe just launched PartsList--a free application to help engineers document their designs, so everyone around here has design on the brain.


Design is always a fun topic for discussion, because everyone has strong opinions when it comes to design.


Some people are on one end of the spectrum, and think that "design" is what works, what is functional—how it looks is in service to what it does. In other words, if something does what it was designed to do, then it is beautiful, because performance is beautiful.



Others say, design equals aesthetics. Design is more like a skin. It’s superficial, yet it’s extremely important, because people make decisions to use a product on their emotions. In this context, design is about sucking people into a frame of mind that is heavily influenced by the visual.



I feel that when it comes to manufacturing, functionality trumps aesthetics every time. (Unless you're Apple.) And this attitude is really reflected in the tools created for manufacturers.


As someone in the manufacturing software business, I personally feel that manufacturing software often supports functionality in its design, but tends to leave aesthetics and “user-friendliness” far behind. While it does what you need it to do, a lot of the products out there are often limited in scope, difficult to navigate and inflexible—especially when you are used to using some of the fancy products designed for marketing and sales.


Speaking from my experience at Arena, we’ve tried to integrate design into the world of manufacturing software, and we sometimes find ourselves alone in thinking this is important. Perhaps we think a little differently because our founders had a background of product design and engineering, but we believe that design makes a huge difference in the amount of customer value—particularly when you’re dealing with a complex domain.





But is this a pointless endeavor? Especially because, when it comes to design, everybody’s right and everybody’s wrong. Do you think functionality is improved by aesthetics, or do you think the two are unrelated? Is aesthetic design in manufacturing software matter just a “nice-to-have” feature, or is it a critical part of creating a usable product?

I just wrote a post on the Arena Blog about big picture questions to ask when launching a new product.


Answering these questions (what is the overall expected revenue, are  there additional headcount needs, etc) is often the job of C-level and  VP folks - but these aren't the only contributors to a successful new product launch.


Are there special considerations for NPI that Operations should own? Here are my suggestions, what should be added to this list?




Has Operations considered . . .




  • ·         How to kick off/manage the various production phases (proto, pilot, production)


  • ·         The supply Chain strategy—is it consigned, turnkey, hybrid or ”appliance” manufacturing?


  • ·        CM selection—should your CMs operate locally, offshore or should you go with an ODM?


  • ·         Will you build to order or build to forecast?


  • ·         Time that needs to be added for the quality assurance process


  • ·         Your production capacity requirements, plans for expansion


  • ·         The Finished Goods (FGI) Warehouse/Distribution plan


  • ·         Repair center process and costs


  • ·         How engineering and operations can contribute to cost reduction?

This is for everyone out there who is frustrated with their org's poor BOM management systems (or worse - - a lack of systems.)

In my first company, we were stuck using Lawson and Saleslogix as our ERP and CRM tools, while everyone and their mother was using and an ERP that wasn't from the 80's. Plus, we had no system for managing our product record, and things were getting pretty messy. We frequently had issues with our inventory, with making our cost projections . . . of course all that rolls downhill, and for me - -  someone who just needed effective tools to do my job - - it was a nightmare.

The biggest issue was that the boss never seemed to think we were a company that needed BOM management!


If you are in an organization where your product management tools just aren't cutting it, and are trying to convince your boss that you need a good set of tools to manage your BOM, here are 5 indicators that it’s time for your business to look into a BOM management tool that works.


You may need a BOM management tool if . . .


  1. You handle hard to track designs and frequently changing costs.
  2. You deal with manual processes like parts requests, ECO/ECN documents and deviations.
  3. You manage multiple islands of product data coming from teams like mechanical and electrical design, purchasing and quality.
  4. There are several channels of communication between groups like  ODMs, outsourcing partners, international branches or various web  portals.
  5. Any changes to the product record that are not caught early might result in costly product recalls and scrap.


If this is all true for you, then Excel, or email or even some clunky legacy system just won't cut it.


And just for fun, does anyone have any horror stories they'd like to share about using outdated, legacy tools?

Intelligent part numbering schemes are always well-intentioned.


In your dream scenario, you'll always know that RES parts are resistors.You'll be able to group similar parts in your documentaion easily and quickly. You'll have a clear frame of reference for every part, and be able to predefine the change routings, review processes and manufacturing steps  for each part number class or category.


But there are a lot of hidden challenges of intelligent part numbering, and if you're just getting your system in place, it's worth taking the time to decide if it's really right for you.


Pros and Cons of intelligent part numbering vs non-intelligent part numbering


A thorough bashing of Intelligent part numbering


What are some common challenges of intelligent part numbering?


Resource Drain:


Intelligent part numbers are easily susceptible to descriptive  clutter—becoming very confusing, hard to read and impossible to  remember. Imagine, for instance, trying to recall whether a part number was  intended to specify length then gauge, or the opposite. Does ‘R-12-06’  mean the part is a 12-gauge or that it is half an inch?


When the system gets squirelly, you will either need to invest in time-consuming organization strategies, or extra training for the people who manage the system. Plus, once your system gets confusing, you are opening yourself up to mistakes. (Which take time and money to fix.)


It's tough to modify the system

If you are going to change a part, how do you ensure that those changes get carried across the rest of the system? And what happens if that change  invalidates or conflicts with the part numbers that already exist? This is espe




You have a 4 gauge, 8 inch green cable with the number ‘G-8-4.' It's a good cable, but suddenly one comes out with shielding that is a much better fit for your product. If you want to incorporate the new shielded cable into your numbering scheme, you need to add something to indicate if cables are  ‘shielded’ or ‘unshielded.’ Once you do that, you have to go back and make sure all of the old parts get the update. And make sure everyone knows about the change to the naming scheme.


Major. Pain.


And finally, intelligent part numbering may just be outdated.


If you have a computer tracking your part numbers, does it really matter how smart they are? Especially if you're using QR codes and tablets on the manufacturing floor.


What do you think? Intelligent part numbering - - are you for, or against?

If you're working for a large, established company, your engineering  change process may have been set in stone for as long as you can  remember.

But if you're working for a smaller company, maybe the way changes  are managed depends on who's involved, the size of the change at hand,  or the level of crisis-mode you're in. (So in other words, there is no  set process for managing change, or there is a process that's not always  followed.)


Generally, a change is made up of the following steps:


  1. Finding an issue
  2. Reporting an issue
  3. Proposing a solution
  4. Discussing a solution
  5. Agreeing on a solution
  6. Implementing a solution
  7. Reporting that the solution was implemented


If one ore more of these steps are not happening when it's time to  make changes to your product, there is a good chance you are  experiencing a higher volume of scrap, cost overages and internal  conflict than necessary.


If you don't have a process for managing changes (and a process that  everyone follows) here are some reasons why you should push for one in  2012.

You may be able to get away with an informal or non-existent process  for managing change when you’re first starting out, but as you scale,  part quantities become more significant. With more money on the line,  leaving things open to error or chance just isn’t worth the risk.

Additionally, conflicts between team members are more likely to occur  if key people are left out of the loop, or if there is no process to  turn to when things get hectic.


If you're looking to improve the way you manage change in 2012, keep  in mind that an ideal system balances flexibility, speed and control.  You want the right people to always be advised about changes, so there  are no surprises later on when you’re buying parts in volume, but you  also need to be able to make changes before issues get out of hand, so  you want a process that can happen fast.


If you're interested in learning more about this topic, and some considerations that should go into your engineering change management process, here are some additional tips for creating a better change management process.

When you're considering parts for your prototype, take a moment to think about your part numbering system. If your prototype is right, and you move to production, organization will be a big part of what makes/breaks you as you scale.


Essentially, when it comes to naming your parts, your choices are an intelligent part numbering scheme, or a non-intelligent part numbering scheme. If you're trying to decide which one is right for you, here are a few pros and cons of intelligent part numbering.


(And go here for another full article on the advantages/disadvantages of intelligent part numbering.)

A few pros/cons of intelligent part numbering

AdvantagesWhy it works
Efficient searching - If you’ve labeled all resistors with part  numbers starting with ‘RES’ (for example), you can more easily group  similar parts in your design documentation together and swiftly sort  among them.
Clear frame of reference for each part - Descriptive part numbers specify the group  to which every part belongs, so you can immediately see when a part is  in the wrong group.
Process efficiency - Because parts with similar naming  conventions are all handled the same way, you can predefine the change  routings, review processes and manufacturing steps for each part number  class or category.
Disadvantages -
Why it’s a challenge
Training and knowledge required - The individual responsible for assigning  part numbers must understand which group to place the part in and how  subgroups interact. Because so much is based on the naming convention,  mis-naming a part can jeopardize the product design.
Ongoing maintenance - Descriptive part numbers require foresight  and continual adjustment as you incorporate new parts into your design.  Part group sizes must also be considered in advance so you don’t get  stuck with a significant number string 0-9 and an eleventh part.

If you are struggling to keep your product data organized and controlled, today's resource round up is for you. Here are some of my favorite BOM resources from Arena (full disclosure - I work there!) Whether your product data is in Excel, on a napkin, or in a PLM system, there is probably something here that can answer your most pressing BOM question.


Engineering BOM: the ins and outs

The EBOM is the starting point for any product. Learn how the EBOM differs from the MBOM, and download the Arena BOM Master Kit—one of our most popular downloads.

The manufacturing BOM: critical for successfully building a product

Unlike the EBOM, which is organized according to the design of a  product, the MBOM is structured to support how a product is assembled.  Here are tips for better MBOMs and a link to the Arena BOM Master Kit.

Sample BOMs

Need a visual? Here’s how a GPS navigation product BOM would look in  both Excel and a dedicated BOM management system like Arena.

Three tips for building better BOMs

The best BOM management system in the world won’t help you if you  don’t create correct and complete BOMs from the start. Here are three  tips I originally shared on the Arena Blog about building better BOMs.

10 tips for better Excel BOMs

If you are managing your BOMs in Excel, here are 10 tips to help you keep your data organized.

Should you manage your BOMs with ERP?

ERP systems are NOT optimal for managing product data during the design stage—find out why.

Why is it so hard to move a BOM from Engineering to Manufacturing?

An in depth explanation of common disconnects between engineering and  production—particularly when it comes to managing the bill of  materials.

3 tips for taking control of your bill of materials

This cautionary tale tells the story of how the lack of a centralized  BOM delayed one company’s launch for months. It also comes with a  bonus—three key tips for keeping BOMs in sync and under control.

Sharing BOMs with your supply chain?

Use the PDX File standard to share your BOMs in a clear, structured format.

Going global is a great sign that business is booming, but international customers bring the added demands and stress of international delivery. As you gain traction in other countries you will find there is a great deal of cost associated with getting your products to the point of delivery—especially countries that have added tariffs and fees.




There are a few different ways to go about reducing the costs of a global customer base, but the first question you will have to answer is - "Can my current supplier scale to meet my new demands?" If they can, then you will be faced with a decision - - should you cut internationally delivery costs by manufacturing closer to customers, or should you stick with your current supplier and find another way to cut costs?


From the Arena blog, here are some considerations that may help you decide what move is right for your business.


You may want to consider new suppliers closer to your customers if  . . .


  • You have a mature product
  • You have a well-documented and well-managed product
  • You feel comfortable in your ability to deal with and manage risk
  • There are several competing companies that can address your manufacturing needs
  • Manufacturing isn’t your core competency or the core driver of your product’s value


You may want to stick with your current supplier team if . . .


  • Your product is immature
  • You can’t afford a reduction in quality
  • You are dependent on a competency owned by your current suppliers


For more info on this subject, here are a couple of articles I think are particularly useful. Enjoy!


Tips and resources for managing your outsourcing relationships

Manufacturing outsourcing challenges and how to solve them

If you're two guys in a garage, you can ignore this post, I am sure Excel works fine for you.


Everyone else, I'm talking to you.


Why rely on Excel when there are so many cool cloud products that can help you manage your business?


For example - - to communicate better w/designers and external vendors, Proof HQ offers an awesome solution for managing feedback and approval of creative projects. To share, manage and access business files online, I love


I think for general collaboration, and on the sales/marketing side of the building, there is wide-spread acceptance of cloud products, but when it comes to more comprehensive solutions for managing product data, finances, etc, I think people shy away from the cloud, but I think that is a mistake too.


For example, if you’re still using Excel to manage your product data, you’ve probably   noticed that managing change and collaboration with a global supply  chain is an organizational nightmare. Excel is not-collaborative,  creates multiple versions of the same doc, and relies on a Microsoft  product.


From the Arena Blog, here are 5 reasons why Excel is not ideal for managing engineering data.


  1. As your  product goes through multiple revisions, one-dimensional record keeping makes real collaboration nearly  impossible.
  2. BOMs are highly relational, which makes managing your product record  on several static spreadsheets extremely challenging.
  3. Excel can’t easily track product compliance requirements in the same place as the BOM, which leads to  oversight of critical compliance requirements.
  4. Multiple internal and external teams need access to the BOM to edit  the product record throughout the product life-cycle, and in many cases,  multiple versions are created as “save as” docs - another great way to make mistakes.
  5. Spreadsheets cannot communicate with other business systems such as  ERP.


Arena offers a BOM and change management cloud solution, but are there any other lightweight cloud products you use as an engineer or manufacturer (that can replace Excel?)