What’s wrong with the fire-and-forget method for build package exchange?
As I briefly touched upon in my previous post, manufacturers have surprisingly few tools designed for efficient product data sharing. Most communicate product data to their suppliers with email, spreadsheets, and even faxes—techniques that I collectively think of as ‘fire-and-forget’ communication.
Fire-and-forget traditionally refers to a weapon that does not need guidance after launch. In the business world, fire-and-forget communication happens when you send a bunch of information and then surrender control and hope for the best. Just think about how engineers and purchasing agents spend hours assembling and preparing build packages to send to suppliers—only to lose visibility and control after the data is sent.
The consequences of fire-and-forget in manufacturing
While email provides a quick and convenient way to move relatively small build packages, and has thereby become the most common medium for build package exchange, it simply doesn’t work as a data management tool.
You can’t use email to see whether your supplier has received and viewed the build package you just sent, and your supplier can’t easily pull the latest build packages for your product. It’s easy to misplace or mix up critical documents when searching email folders and downloaded files. And when your suppliers can’t locate the correct drawing or package, they all too often build from the most recent documentation that they can find and hope for the best.
When a build package is too big to send as an email attachment, many companies resort to general-purpose file transfer tools like FTP, SharePoint, Dropbox, or Box. These tools work better than email for fire-and-forget file transfer, but they take time to set up and suppliers need to be trained on how to use them.
Without a single standard, your supplier ends up with an ad hoc archive of spreadsheets and product data assembled from a variety of locations—all organized in customer-specific ways. None of these tools are built with manufacturing data in mind, so neither you nor your supplier can easily find the latest information or highlight new information in updated files.
We are twelve years into the 21st century, and it’s still amazingly common to end up with the wrong part or subassembly because someone involved in the exchange of manufacturing data missed a key change or confused one file for another.
Better build package exchange is one of the first areas where manufacturers should expect to see immediate, tangible benefits from the migration of manufacturing and manufacturing software into the cloud.
Imagine a purpose-built cloud tool that tracks all “active” build packages in one place and presents the information to suppliers in a standardized, easy to understand format. By evolving product data exchange practices and tools to take full advantage of the cloud, we can all make fire-and-forget product data communication a thing of the past.
I founded Arena because I believe manufacturers should be able to use cloud applications built for manufacturing. Arena Exchange has features and functionalities only possible with the cloud, and we’re building new partnerships with other cloud companies to extend our tools even further. Stay tuned.
Arena Exchange for PDX Build Package Collaboration