Author Lochan Narvekar, © 2017 Ref# PIM0001-R01
What is
PIM? Helping complement existing PLM Implementations with MDM
The focus of product management has
evolved from Product Data Management, Product Life Cycle management to finally
Product Information Management.
In its early
days, Product Data Management meant mostly engineering data. With only few reach
outs to other business functions, such as, “instruction sheets” for
manufacturing. There were CAD, CAM files etc., and emphasis was more on the
translating the data from engineer’s desk out to the manufacturer in best
possible way.
Product Life
Management took this further to enable companies manage the lifecycle of a
product initially from Engineering to manufacturing, but soon beyond
manufacturing into functions such purchasing, Order Management, Service and
sometimes Support. This was clear extension of original PDM ideas to some,
hence most PDM vendors got onto the bandwagon developing their PLM softwares.
As much as we agree on the need for strong software in helping engineers create
3-D models in aiding them to innovate, we will agree that there was not an
equal need felt on the PLM side.
All the
companies know what they are doing when they build a product and sell it.
That’s their bread and butter. So, PLM software helped more on aiding
cataloging, change order, BOM management and transfer, and other niche areas to
fill the gaps in already existing processes. Key question companies wanted
answered was what needs to happen at various stages of a product life cycle. Emphasis
was on management of product from concept to obsolescence.
Product Information
Mgmt takes this one notch ahead. There is equal emphasis on PLM, but there is
need to supplement it with accurate data and means of getting that data. So, in
many ways, PIM complements and completes PLM.
Also, as
written above, PIM is unique in that it is more a business need. Companies know
what they are building, but need accurate data to build it! PIM addresses this
area.
PIM
recognizes the strong product data needs of business functions like Marketing,
Sales, Finance, Logistics and ties them to the needs of Engineering,
Manufacturing and Purchasing. By doing this through same prism, PIM creates a FULL
view of product data, and in the process aids organizations in gluing these desperate
functions into PLM.
Then, PIM
will also take this data and feed the analytical tools in a standard way.
Previously, this was done in resource intensive ways. With PIM, there comes standardization
in the data which also standardizes the processes that transform this data for
analytics.
PIM will lay
foundation for quality data communication with external parties. PIM should
also consider regulatory compliance needs.
By full
product view, I do not mean to say that PIM is a hub or even a software
product. We see enough people getting trapped in this thought. PIM really
starts with recognition of a product data problem anywhere in the company PLM
processes and flows through from there into a solution to this problem. Perhaps
the solution is software, but never software alone! Note that even the software
need not always be a Product Hub. There are different models of solving PIM
problem that depend on complexity, scope, funding etc. They begin with
integration at one end, going through hybrid approaches to finally a complete
Product Hub solution.
PIM is
NOT catch all
It’s very
important not to burden PIM platform with all the Product attributes that organization
needs. Although it’s true that an attribute exists because its needed
somewhere, only some of these attributes are really key to the business
function and have been identified as needing the PIM care and attention.
Something
like ABC inventory classes for raw material. You would take more care of the A
parts.
Example: at
one of my clients, we had a logistical attribute called layers per pallet.
Although this was very much proven to be required in logistics, was not
required outside of that function and hence was not brought into the PIM effort
or under PIM control.
Some of the
key attributes include engineering attributes related to form, fit, function
such as Length, Width, Height; General attributes like product number,
description, revision; Logistical attributes like pallet, container quantities.
Attributes from Marketing such alternate product categories; Finance needs
product hierarchies; Sales related attributes; Key attributes from core
functions such as purchasing and Order Mgmt. We do need PLM attributes like
statuses, flags needed to move the product along. One interesting area of
contention is custom or company specific attributes. These attributes are
always needed based on the unique needs of each business;
PIM could
also include key documents that are needed across the organization like sales
collaterals. But these could be referenced rather than brought into immediate
PIM concern and handled through content management initiatives.
Product data
is by nature hierarchical. Packaging, Engineering Item categories, product
catalogs are all hierarchical in nature. Add to this, the key financial product
hierarchy, Marketing’s product categorization based on specific portfolio
needs. This is also included under PIM umbrella.
Emphasis
on Business Involvement
PIM also
concerns the business processes that deal with the data. I like to quote,
“Quality processes need quality data, but also, vice-versa”.
We should not
forget that majority PIM projects (if not called so) start with the business
process that needs quality data. Often this part is missed somewhere along in
PIM initiative. Although this is not a direct function of IT, it’s a
responsibility that in my view, MDM charter holds. I will leave it to the
informed reader to engage their business counterparts. If MDM principles are
followed properly, this requirement should be met automatically.
PIM is
MDM, after all…
If not for
MDM principles, PIM would be just another IT data integration project. Hence
faithful adherence to MDM principle is very critical; even in the face of tight
deadlines, attempt must be made on each of the facets of MDM. This is not just
a theoretical exercise; it has definite ROI implications as well as promise of long
term success. Please talk to your system integrator or IT to make sure that
they follow up on this promise and present their strategy to you.
PIM,
what it’s not?
This is a
tough question to answer and has strong political tone to it. So, I want to
caution the reader that take this as only starting suggestion and act based on
your individual scenario. Examples will clarify what I mean.
PIM is not
data integration platform. In other words, do not expect Enterprise Information
Integration platforms to be PIM hubs. By now it’s clear to the reader that PIM
is a child of MDM, or MDM applied to product area. In this capacity alone, PIM
offers lot of business objective support that cannot be met with Enterprise Bus
alone. Enterprise Bus is a layer which makes the PIM projects a reality by
integrating systems intelligently.
Integration
platforms have come long way from basic offerings and have become intelligent
brokers between the desperate applications. Yes, they are taking over some key
components of MDM such as limited data governance, audits, better business
event support and some business rules support.
As explained
above, PIM is not a catch all tool. Meaning, unless there is enterprise wide
consolidation or some other need such as retiring home grown or old system,
attempt should not be made to bring in all attributes into PIM system for
management; and definitely not as is. But in certain cases deadlines and some
of the reasons mentioned above may make it easy to do so. Even then every
attempt must be made to apply MDM prism onto the attributes to get optimal
results. We do not want to transfer same old problems to PIM system.
PIM is also
not a data cleansing tool. Although a close cousins and important members of
PIM family, data cleansing tools complement the core PIM applications. Lot of
clients point at such tools and low cost of ownership and feel tempted to use
them as the core PIM platform. I think these tools have definite need, but in
addition to strong PIM applications.
What’s
next?
I hope that
this article clarifies the subject of Product Information Management and how to
delineate it from other IT initiatives. Next steps would be to identify what product
data related problems you are facing throughout your product’s life cycle.
Interview your business as well as IT analysts; they will point to the obvious
problems that they want fixed. Then, engage your systems integrators or IT
analysts to solve those problems by applying familiar Master Data Management
principles.
About the
Author: About the Author: Lochan started his career in R&D architecting
PLM/MDM software. Moved to Consulting in 2005, and has been successfully
consulting for many years in the PLM, PIM and MDM area. He can be contacted Lochan@gmail.com.
This is copyrighted material; © 2017 Lochan Narvekar.
