If you’re part of an organization that’s scaling to production, we’ve got you covered with our scalable cloud PLM solution.

But what if you’re just starting out? You need to capture and document parts, but without changes and a supply chain to manage, you may not be ready to implement a full-service solution. You may just need something that helps you design and document a prototype, or turn your parts into BOMs.

For people like you, we created PartsList.

Why PartsList?

In the last year, we noticed a lack of engineer-focused systems that individuals and small teams could use to document and share their designs. We hope to change all that with PartsList—a new cloud application that makes it easy to document, organize and share BOMs.

PartsList is a low cost tool for engineers who just need to find parts, document a BOM and get it to doc control (or a partner, vendor or friend). Since we launched in January, we’ve been getting an enthusiastic response, and a lot of early traction, which has been really exciting to see.

As the product manager of PartsList, I’d like to give you a tour of PartsList, so you can see how it can help you get your prototype built. At this point in time, we’re letting new users try PartsList for free, so if you think you might be interested, set up your account today.

What are some cool things you can do with PartsList?

When we created PartsList we had design engineers in mind.

The use case for PartsList begins with an engineer who needs to get his/her full circuit design from EDA or ECAD documented. (Or an engineer who needs to document a napkin drawing, reference BOM or a parts list in a spreadsheet.) From there, PartsList can be used to:

Complete the documentation process for an existing bill of materials

Export a BOM from ECAD, import it into PartsList and use Autofill to collect datasheets and vendor site information for your entire BOM in one click. For any given part, all you need is the manufacturer and manufacturer number to capture the rest of the information—including datasheets and links to purchase—with the click of a button.

When you’re done, export the BOM to CSV or PDX to share it with whoever needs it. (And if you’re unfamiliar with PDX, here is more information on how you can use PDX to share build packages.)

Consider multiple critical component contenders

PartsList comes with PartSaver—a bookmarklet that you can use to capture and save critical part information with one click. If you’re browsing parts online, you can use the PartSaver browser button to capture critical component information—including datasheets and vendor information, and make comparative evaluation easy.

Create a new Bill of Materials

If you want to start a BOM from scratch, you can find the parts individually online, and use PartSaver to capture all the data into a unique list.

It’s also easy to build out a napkin-drawing or sketched BOM with PartsList. Just load the basic information—part number and manufacturer—into PartsList, select Autofill and PartsList will pull the rest of the information you need to complete your BOM.

If you have a BOM in EDA or ECAD, or a reference design from a partner or manufacturer, you can import the old design to PartsList, remove the components that you want to replace, and use PartSaver to clip replacement parts.

Create a new part request form

PartsList gives you a full list with supplier item information, which can be passed to document control for creation of internal part numbers and inclusion of parts into another system—if you have access to PLM, or an ECAD library.

It’s never too early to be organized

If you’re an engineer at an early-stage startup, two guys in a garage building a prototype or even a serial inventor with a ton of ideas to document, a comprehensive cloud PLM solution might feel like a bit much. But if you want to be prepared when it’s time to scale, it’s never too early to adopt a simple, effective way to collect part data, as well as build and share simple BOMs. So I hope you give PartsList a try.

For more information:

Try Arena PartsList for free today

Your right-sized BOM management toolkit in the cloud

Arena PDXViewer-display PDX build packages in an easy-to-read, navigable format

When you’re dealing with engineers you’re talking CAD and design; when you’re working with purchasing and production you’re talking ERP and SCM. And if you have to share product data between these groups, the only way to make sure each system accepts the information is to send everything via email and spreadsheets.

While email and spreadsheets are fine for some things, they are not the best way to share a build package or a change order.  This is why we developed Arena PDXViewer—a free cloud application that displays PDX build packages in an easy-to-read, navigable format. (To learn more about the PDX file standard, check out my previous post.)

We built PDXViewer for ultimate usability, enabling it to work on any computer with any operating system and without any required set up. Our viewer has been the cleanest, simplest viewer on the market for some time, but we’ve recently introduced a new feature that brings PDXViewer to the next level—the ability to filter a build package.

Introducing Filter—the easiest way to break your BOM up into supplier-specific build packages

With Filter, you have the flexibility to decide what to include and exclude in your PDX build package. This new feature means that PDXViewer now gives you complete control over the exact set of parts and drawings you share with a subcontractor, vendor or manufacturing partner.

How to use Filter to control your product data

Filter addresses an issue that affects everyone in the manufacturing process—control over what data is shared.

• Engineers can use Filter to remove unwanted or private files, items, manufacturers and contacts from a build package before sharing with downstream partners, or requesting a quote.
• Procurement can use Filter to break build packages up into vendor-specific data sets for clear, unambiguous communication with vendors.
• Operations can use Filter to attach a customized build package to a work order so manufacturing partners have all the information they need to do their jobs.
• Contract manufacturers can use Filter to create a unique build package for each vendor when outsourcing aspects of production, such as cables, PCB, enclosures, or the shipping and packaging.

Give PDXViewer a try—it’s free!

When sharing a build package, there is always the concern that including too much information will lead to unwanted exposure of private or erroneous data, or confusion on the part of the recipient. With the addition of Filter to PDXViewer, you can rest easy, knowing you are in complete control of what data travels down the supply chain.

Try PDXViewer today for free—create and share build packages with more control and fewer errors.

Let me explain.

We’ve come a long way since our early days as BOM.com, and today Arena is used by thousands of manufacturers around the world. And while we’ve solved the problem of capturing, communicating and controlling product data for small to midsize organizations with our cloud PLM software, we know that data management is still a challenge for the lone hobbyist, the garage startup or the small business that is still deciding on vendors and processes, or building out their supply chain.

Managing product data should be a no brainer—even if you’re just two guys in a garage

To solve this problem, we’ve launched two new products that can help manufacturers and engineers get their designs documented and shared earlier in the process—Arena PartsList, and Arena PDXViewer.

Together, PartsList and PDXViewer create a lightweight solution that requires no organizational initiative and no set up. Using PartsList and PDXViewer together, engineers can import designs from ECAD, automatically pull in critical component information and create a fully documented BOM (which can be shared as read-only build package for fast quoting or building.)

How PartsList and PDXViewer help you document and share your designs from Day One

Arena PartsList—create and share clean, fully documented BOMs

Arena PartsList is the ultimate lightweight tool for design engineers. With one click, PartsList turns any list of parts into a purchasable BOM you can share with doc control, purchasing or potential vendors.

If you import designs from your ECAD tool and select Autofill, PartsList will automatically pull the datasheets and key component attributes for all the parts in your list. If you’re browsing parts online, you can use the PartSaver bookmarklet to capture critical component information in one click.

You can use PartsList to create any number of parts lists, organize them however you like them share your lists with anyone who needs them by exporting to CSV or PDX.

PDXViewer—display PDX build packages in an easy-to-read, navigable format

PDXViewer is a free tool for sharing easy-to-read, organized BOM data with anyone who needs it. PDXViewer opens any PDX file (including ones you create with PartsList) and can be used on any operating system or machine. PDXViewer takes the hassle out of handing off the BOM, and is a great tool to use with vendors and suppliers.

Although easy to use, PDXViewer is extremely robust. In addition to viewing PDX files, you can use PDXViewer to break a build package up into smaller subsets of data to share with subcontractors, vendors or manufacturing partners. With the ability to preview your files, or share exported change orders as redlined PDX packages, you can be sure you are always sending the right data downstream.

Right-sized PLM solutions for every manufacturer, at every stage of development

Although we are extending the benefits of cloud PLM to a larger audience, don’t think we’ve forgotten about our current customers. At its core Arena is about cloud collaboration—whether through our new lightweight apps, or our scalable BOM and change management tool.

We decided to extend the benefits of cloud PLM to a wider audience because we believe that all manufacturers—at all stages of development—deserve an easy-to-start, easy-to-learn, easy-to-use solution for centralizing product data and sharing BOMs with suppliers.

With PartsList and PDXViewer, we now fully support product design at every stage of the market. We have tools for the individual, for the partnership, for the startup, for the small and midsize companies, and for the large organization. At any size, and any price point, you can rely on Arena to help you capture and easily share your designs.

PDXViewer is a free tool from Arena. You can try PartsList for free for 90 days. Sign up now—and help influence development going forward by sending me your feedback or posting to the comments. Thanks!

For more information

Arena PartsList—create and share clean, fully documented BOMs

PDXViewer—display PDX build packages in an easy-to-read, navigable format

In some cases, by the time you craft the ECR, add in the appropriate documentation, talk it over with the product engineer and send the ECR around for approval, the engineering change order (ECO) is completely redundant.

So if your ECRs are just being used as mini ECOs, do you really need them? If the same people go through the same process twice for every change, and there are no real differences between ECRs and ECOs, what’s the point of having both?

Give your engineering change requests a purpose

While there are some exceptions, ECRs are actually an important part of the change process for most companies. However, it’s important that you know why you are writing ECRs in the first place, and that you enable the right people to participate in the ECR process.

In many companies, an engineer will write an ECR, send it to key players for approval and then write an ECO to put through the same process with some additional people included, like the VP of engineering.  In this example, the ECR is a fairly unimportant part of the overall change process—especially if most people ignore the ECR on the first round, knowing there is an ECO coming.

In many ways, having engineers come up with ECRs is somewhat contrived. When an engineer submits an ECR, it’s not usually to request a change; it’s to propose a solution. To make the most of the ECR process, and separate it from the ECO process, consider incorporating customer, supplier and manufacturing feedback into your ECR process.

How can you make the most of ECRs?

Some companies use ECRs as a way to document proposed, accepted and rejected engineering changes, particularly in highly regulated environments. If you’re using Arena, ECRs are a great way to informally discuss an issue—and capture the discussion—before you create a formal change.

In smart organizations, engineering change requests are a formalized way people outside engineering can make recommendations for change. Within our customer base, we see this in a variety of ways.

Some organizations use ECRs as a way to capture customer complaints. One really innovative way to do this is to link your customer case system to the request system in your PLM tool.

Other companies use ECRs to increase/improve communication with suppliers. You may not want to loop your supplier into your ECO process, but when you think about it, your supplier is in a perfect position to catch problems with the parts you’re purchasing, or notice places you can optimize across product lines. Encouraging suppliers to submit ECRs gets them involved, but is less of a commitment than an ECO.

In general, ECRs are a great way to capture suggestions without incorporating everyone into your ECO process. ECRs can capture defects at all levels—supplier defects, shop floor defects, customer concerns, feedback from sales. A natural flow might look like this: a product issue comes in from customer support, an incident report is created in your customer care system and the ECR to ECO process begins.

If you are leveraging change requests properly, you will stop thinking of them as busy work, and start thinking of them as a way to incorporate more relevant feedback into your process.

For more information:

What’s an engineering change request form?

Is your change process in check for 2012?

Three common change management problems and how to solve them

Three essential tips for effective change management

Engineering change management in Arena

This is our last blog post of 2011! Happy (almost) New Year!

All I have to say is, where did the time go?

From the earthquake in Japan, to the floods in Thailand; from the robot takeover at Foxcon, to the growing onshoring trend, 2011 was certainly a crazy year. I really appreciate everyone who read this blog over the last 12 months—hope to see you again in 2012!

(By the way, if you haven’t yet subscribed to our blog, please do so! It’s the best way to stay in touch.)

I am excited to continue discussing manufacturing, engineering and product management issues, and hope 2012 will be a year of growth—for the manufacturing industry as well as the economy as a whole.

In the spirit of the holiday, I’d like to take a walk down Memory Lane, and share our top 5 posts from 2011.

Best of the Arena Blog—2011

Why is it so hard to move a BOM from engineering to manufacturing?

BOM management strategies: Four recommendations for better Excel BOMs

Three ideas for encouraging workplace innovation

Do QR codes belong on the shop floor?

Why you should be using the PDX File Standard

Thanks again for a great year! Goodbye for now, and I’ll see you next year!

At Arena, we have built a robust way to invite trusted suppliers into your decision making process, but there are still occasions in which you need a quick, easy way to send product data to one-time, transactional partners. That’s why I am so excited about Arena PDXViewer—it makes assembling and sending build packages, quote requests and BOMs easy.

If you’re already using a PDX viewer, I encourage you to try Arena PDXViewer—it’s web-based, easy to use and works on any computer. If you’re unfamiliar with PDX—read on to learn how this XML-based standard can revolutionize the way you connect with your suppliers.

Life before PDX

If you’re not using PDX files to share comprehensive product data (including AMLs, BOMs, change orders, etc.) you can probably relate to how difficult it is to make your BOM accessible to external teams.

Without PDX files, preparing a build package for delivery is a mixture of black magic, blood, sweat and data from a business system. In some companies, one person is hired or trained to access the system for the sole purpose of sending data to suppliers once or twice a year. At other companies, data is pulled manually out of the PLM system by the design engineers, who put the data into an Excel spreadsheet and send it to suppliers in binders or zip files.

There are several problems with the manual methods of data sharing. For one thing, it’s nearly impossible to maintain the original BOM indentation when you export to Excel or try to print, and you may end up making PDFs of screen shots to try and maintain the original format. If you need to get rid of confidential data before sending your data, the process takes even longer. You quickly end up using tools like Paint or Acrobat, or find yourself at the printer with scissors, Wite-Out and a glue stick.

It’s amazing how many time-consuming, error-prone methods there are for getting product data out of a PLM system, when all you really need is a simple, standardized format for sharing PLM data.

A case for PDX

If you’re sick of all the workarounds, you may be ready for PDX—an open IPC XML-based standard with a solid and devoted following.

PDX is a great way to maximize your PLM usage because it incorporates suppliers—and anyone else who can’t access your PLM system—into your process in a clean, secure way.

PDX acknowledges that not everyone will be a PLM power user, and takes the burden off of engineers and doc control to get data from business systems for colleagues and vendors.  For power PLM users who have to work with a wide variety of people, PDX means easy data consolidation and sharing. Suppliers can even use PDX to run exports with BOM attachments as needed, or take the information and upload it into a variety of systems.

The PDX standard is fast, but more importantly, it minimizes errors. Because PDX is a read-only snapshot, you don’t have to worry that your data will get tampered with or that errors will be introduced to your BOM. PDX really is a fool-proof way to get structured product data out of your business system, and get it to the people who need it.

PDXViewer—a PDX viewer from Arena

As we announced earlier this year, Arena offers a free PDX viewer that is more convenient, and easier to use than any other PDX viewer on the market. (Check it out at arenasolutions.com/pdxviewer.)

Based on customer feedback, we recently updated the Arena PDXViewer interface and added the ability to highlight BOM substitutes. We believe these updates really increase the value of PDXViewer, and extend its functionality even further.

We have already seen how useful PDX can be, and we are committed to improving the process for Arena customers and other users. If you have never used PDX, I would urge you to give Arena PDXViewer a try. It works with SAP, Agile, Arena, Teamcenter and WebSphere systems, go to arenasolutions.com/pdxviewer, and check it out.

For more information

Announcing Arena PDXViewer: A free web app for sharing product data

Today I wanted to do a bit of a round-up, and share some of our most popular “BOM” blog posts and downloads from the Arena website.

Enjoy! And if you have any additional questions about BOM management you’d like us to answer on this blog, post to the comments and I will be sure to get back to you.

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.

Beyond BOM 101

This free download discusses:

• Current BOM management processes and their associated challenges
• Current BOM management tools
• New automated tools to manage BOMs
• Benefits of selecting the right PLM tool

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.

When is the right time to embrace a BOM management tool?

A successful startup shares how early adoption of product management tools fostered innovation.

What should you look for in a BOM management tool?

Not all BOM management tools are created equal. We highlight three key features that are must-haves in any BOM tool.

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.

Getting people to adopt new systems is notoriously difficult, but it doesn’t have to be. We have worked with hundreds of organizations as they embark on their PLM journey, and have three steps you can take to make your implementation stick.

Communicate the vision, early and often!

In some companies, crisis is the motivator of PLM adoption. This can actually make things easier in some ways, because the vision is clear and motivation is high as people are still reeling from lost clients, lost money and lost sleep.

But if you’re adopting PLM because of an edict from on-high, it’s much harder for busy engineers to understand why established processes and systems are changing.

Communication leads to buy-in

If you can clearly communicate why PLM will help the team, you will never have problems securing buy-in. But clear communication isn’t just something to check off your list—it must continue throughout the entire process. In a recent LinkedIn conversation about PLM implementation, Ryan McVay from Delivering Learning Solutions put it best:

“Imagine you bought the biggest and best entertainment center with a 60″ LED screen, a $1,500 receiver and a 7-speaker Bose system. Once you have defined your wiring scheme, gotten the components wired up, tested the sound settings and programmed the universal remote, all that’s left is to turn it on. Right?

Wrong!               

Your family and friends need to be informed of what you are doing, why you are doing it, accept the changes, and get trained on the benefits and functions of the new system. If this doesn’t happen then you can count on everyone walking up to the TV, hitting the power button and completely bypassing everything you did! If this happens, your benefits, all your hard work, initial investment and future ROI are gone, gone, gone.”

As goes television set-up, so goes PLM implementation.

Cross-functional communication is key

Remember, it’s not enough that your management team understands the ‘why,’ as you move through the implementation process, make sure everyone else understands it too. When the organization as a whole knows the vision behind PLM implementation (whether it’s cost-savings or improved efficiency) people will be much more willing to make the change.

And if you’re struggling to convince the people in your organization that PLM is the right move for you, check out our Arena ROI kit, which explains how BOMs and changes can be better managed with a software system.

When moving your business online, start with the easy win

One of the benefits of adopting PLM is that the software automates your decision process and minimizes errors. So as you’re moving forward with your implementation, you should take a few minutes to consider what that process is before you decide how you want to capture it. (And a good vendor can assist you in this process.)

Defining your process is usually simpler than you think—start small, and continually refine as you go along.

Start with the item master and expand from there

An obvious place to start is with your item master. Once your product record is documented in a consistent and universally accessible place, it’s easier to look at measuring change, then adding request processes, then moving forward from there. Getting a single version of the truth and the correct version of all your BOMs in the system is also a great way to get the few remaining doubters to buy in.

If you can take a measured approach in phases, where you bring aspects of your business online as you are ready, the implementation will feel much more comfortable to everyone involved. Set your sights on achievable milestones, and look for an easy first win—again, in our experience, that is almost universally getting the item master in your system.

Remember—implementing a new system is a work in progress. Start small with something, and you can always change your mind later as your business grows and requirements change.

Define your process, but don’t reinvent the wheel.

While PLM implementation forces some organizations to formalize their processes, if you have a process and it’s been working for you, don’t throw it out just because you’re switching from paper to software.

Moving your current processes into your PLM system is as simple as taking your paper system and replicating it—there is no need to start over from scratch.

Don’t create bottlenecks by re-engineering your process

When moving to PLM, many organizations decide to re-engineer their change board routings because they think the software will make it easier for twice as many people to be involved. This is a reasonable idea (PLM does make it easier to quickly make changes) but adding people who don’t really need to be involved leads to hold-ups and bottlenecks.

If it’s common knowledge that the VP of engineering signs off on projects through his or her admin, set your PLM system up so that process can continue.  Always ask—when we had the paper system, who did it then?

Want more information?

I hope these recommendations from our in-house team are useful to you, and help you feel a little bit more comfortable as you move toward adopting a system to manage your product data.

If you are still evaluating systems, and are interested in getting more information about Arena BOM and change management software in the cloud, request a free trial.

An MVP strategy allows product developers to work more closely with customers and align product features to actual use.

Recently, we’ve been taking a new approach to product development at Arena.

Traditionally, our main goal in developing new product features was to go-live with well-architected, fully-designed and ready-for-use products. While this approach has worked well for us over the years, changes in software development and delivery have got us thinking a little bit differently.

Moving to a minimum viable product strategy

When it comes to product development, our established process was to brainstorm all the ways in which the product or feature could be used, construct a list of requirements that addressed every possible scenario with a range of solutions and implement a design that met as many of the requirements as possible.

This approach came with a few downsides. Occasionally, we missed a key usage or requirement, and even more frequently, we would over-engineer for a minor use case. Although we could achieve a high level of completion and scalability, it was hard to revise or revisit more fundamental aspects post-release.

When Steve Chalgren joined the Arena team as vice president of product management and strategy, he pushed us to rethink our approach. He pointed out that as a SAAS company, we could do things differently because customers are always able to use the latest version of our product and we can iterate rapidly. Steve advocated, and we adopted, the idea of releasing minimum viable products (MVP).

Avoid over-engineering with an MVP strategy

If you’re not familiar with the concept of MVP, it’s essentially the strategy of developing a concept just to the point of usability, and then letting users tell you where to add the bells-and-whistles. It’s a response to the challenge of over-engineered products that don’t do exactly what the customer wants, but it’s also a way to save time and become more efficient, as it is harder to go back and iterate once you’ve put so much time into a fully-designed product.

The minimum viable product model has allowed us to be more customer-focused, and to be a more agile player in the new software development landscape. We’ve used the MVP strategy to release three new targeted applications at this point—PDX Viewer, PartSaver and Drop Box. Each of these products was built to satisfy a specific customer need, and while the first release supported some usages, it wasn’t a catch-all.

But that’s sort of the point.

An MVP strategy means that instead of developing a product to its full potential before the release, we’re putting it out in front of customers as a concept, and then letting them tell us where they find the greatest value so we can maximize the effectiveness of additional development efforts.

How MVP strategies allow users to influence product development

So far, this approach seems to be working. When we released PartSaver, one of our early adopters told us his organization used a very similar form for new part requests. We hadn’t come up with the idea of using PartSaver as a part request form ourselves, but once we got this feedback we realized this was an important use case and it has informed the way we’ve developed the product going forward.

Another example of the MVP strategy can be seen in our recent addition of QR codes for SmartLinks. In this case, all we’ve done is allow you to create a QR code. We’re not telling you where to find your scanners, or how to use QR codes in your business, we’re just waiting to see where you might take it.

Developing with an MVP mindset has been extremely rewarding, and I think other companies could potentially benefit from this approach.

Some considerations if you’re looking to implement a Minimum Viable Product strategy

1. Effective MVP products demonstrate purpose and provide value—even in their most limited form. A group of users should be able to come back to use an MVP again and again even though they think it could be better. This early adoption and feedback is what allows you to iterate based on what customers are doing.
2. Speaking of early adopters, don’t burn them with a bad product. MVP products may be incomplete, but they’re not low-quality. Remember—that first set of customers forms the market’s impression, so make sure they have a positive experience, even if you leave them wanting more. MVP isn’t a good fit for companies whose products can’t support in-place upgrades. If early adopters are forever stuck with the MVP while future customers benefit from updates, loyalty and adoption for future products will quickly decrease.
3. A MVP strategy is only possible when you are able to iterate quickly based on user feedback, and when you are confident in your ability to work quickly yet maintain a consistent level of quality. If you release the first version, and find out that customers hate a feature, or that another feature doesn’t work, you need to be able and willing to listen to those concerns, and make changes in a timely manner.
4. In a successful MVP strategy, the cost customers incur for updates and improvements must be low. In Arena’s case, we are able to push updates to customers quickly and transparently with minimal customer interference since we aren’t an on-premise solution.

A final word on MVP

If you can make it work, surfacing products and releases very early and letting them mature in the public eye allows you to target improvements around actual usage. You dramatically increase the efficiency and effectiveness of your development efforts, and provide your customers with a product that is just right for their needs.

We’re looking for feedback on our MVPs

If you have a second, please let us know what you think of our new applications—PDX Viewer and PartSaver.

Our usual approach to product development is to address known application issues, then use customer requests for additional functionality to inform the design and details of future features. But in our last release, we included something you didn’t ask for—the ability to generate QR codes from Arena SmartLinks—a new feature in Arena that creates a static, unchanging link pointing to the latest effective revision of a document.

Addressing the need for a paperless manufacturing floor

The idea to provide QR codes did not come out of our normal process, but I believe there is an unrealized opportunity for QR codes on the shop floor, so I pushed to include the functionality. Manufacturers are becoming less paper-driven to improve efficiency, cut costs and reduce environmental impact. Scanners are already used for inventory control, and electronic documentation is increasing in usage on the shop floor. With the popularization of tablet computers, I believe this trend will accelerate, and QR codes will provide a great way to connect electronic documents to the real world.

Keeping documents current in a paper-dependent world can be challenging, especially as revisions frequently change. While all companies strive to maintain current documentation, for some segments—like medical device—documentation must be current. (FDA regulations for Good Manufacturing Processes (GMP) require all medical device manufacturers to remove down-rev documentation from their manufacturing floor.) Using a tablet computer for shop floor documentation combined with SmartLinks functionality could be one way for manufacturers to ensure that documentation is always current.

How QR codes could be used on the shop floor

With the ability to create scannable URLs, manufacturers can implement a point-and-browse experience on the shop floor.  For example, if work orders listing collections of parts included a QR code, a technician with a tablet could scan the work order, and immediately pull up the latest approved assembly procedure.

Manufacturers could also use this functionality to improve inventory management—with QR code-enhanced bins that provide a real-world bookmark for the latest specifications for each part.

Predicting and addressing customer needs to inform product development

As I said, the decision to adopt QR codes wasn’t obvious to any of us, but I used my “founder’s authority” to make the final call and add this functionality into Arena, even though there were no customer requests for it. As I said, there is a delicate balance between exercising your own judgment and listening to popular sentiment when designing enhancements, and in this case I went with my gut.

So what do you think? We’ve added a technology to the Arena application just because I thought it might be useful. Do you think this is a smart move? And do you agree that camera-enabled tablets will increase adoption of QR codes in manufacturing?