What’s so difficult about Global Product Development Strategy? Let’s start with Part Numbers...

kenichiohmae_bookI recently read an excellent book by Kenichi Ohmae, a Japanese business strategist, called “The Invisible Continent”. Mr. Ohmae sites Cisco a few times in the book as an example of a product development company that is structured for the Invisible Continent. Two elements of the invisible continent definition are a borderless dimension and a cyber dimension. Cisco has embraced those and has been quite successful over the years with new products, so their product development organizational structure must be working.

This article is not about Cisco, but about why it seems so difficult for established companies to adapt themselves to a global, networked business model, including leveraging their acquisitions, purely from a product development angle, as that is our area of knowledge.

There is no way to cover the many topics surrounding this question without turning this into a novel, so I will use a series of smaller articles in bite sized chunks.

Bite Size Chunk #1. Part Numbers and the Design Anywhere, Build Anywhere initiative - Now let’s say for example we have 4 divisions in our group, 2 in the USA and 2 in Europe and we want to adopt a Design Anywhere, Build Anywhere infrastructure. Let’s start with Design anywhere first, and create a common infrastructure so our engineering teams can collaborate and share data and expertise.

Being a heavily mechanical engineering organization, let’s choose

  • A common, associative 3D CAD system as our mechanical design authoring tool
  • A PDM or PLM system to keep all the revisions straight as we move data or grant data access to our global engineering teams.

One of the first things we should figure out is how we are going to organize part numbers. This basic component of our infrastructure will be with us for a long time so we should make a good decision.

Here is where we run into our first “established practices or visible continent” methodology versus “what’s a smart practice with modern technology invisible continent” methodology.

The old way is to try to create or use an existing divisions “intelligent” part numbering scheme that was set up before we had modern PDM, PLM and ERP systems. Part numbers can be coded with prefixes and suffixes to represent different part types, product lines, and commodity codes and a whole bunch of other translations for the numbers so they can be organized mostly on a spreadsheet. The more information you are trying to code into the part numbers, the more you trap yourself into this old methodology.

Our own Dave Stewart wrote an excellent blog detailing the pros and cons of intelligent part numbers.

The new way is to enforce the use of attributes or Meta data associated to part numbers in the PDM/PLM system. You can then search on attributes versus part numbers or retrieve attributes to get your information based on a sequential part number.

Similar to a police officer that calls in your sequentially numbered license plate, he gets information about you (Meta data) that is stored in a database based on the license number. I doubt very much officer Jones reads your license number with his eyes and automatically decodes that YUQ 098 means:

“Rodney McCabe, Zero Wait State IT manager, 3 speeding tickets in the past 5 years but no felony convictions.”

But there is no doubt Officer Jones has (some) of that info sent to him on his computer screen because Rodney had to register his car and the information was put in a database. Likewise, product attributes can be enforced upon part file check in to PDM/PLM.

Now I could see a prefix number, tied to the division or group name that is responsible for the part, similar to a state designation on a license plate, so if a person read the number off a part warehouse tag in Malaysia, they would know which PDM, PLM or ERP system to look in, based on what software tools that group is using.

Conclusion – If you have a strategic business goal like Design Anywhere, Build Anywhere, which is something like a Cisco infrastructure using modern databases and networked systems, and in your first planning session, the team falls back on the “intelligent part numbering system of XYZ division” because it’s well defined on 2 pages with single spaced written designations; You are trapped in the old ways, and stuck on the visible continent. Your Design Anywhere initiative has been compromised from the start. You can still get it done, it’s just harder – more visible continent roadblocks exposed in the next article.


Subscribe to the ZWS Blog

Recent Posts