FACET Background

Facets differ from tags in the fact they are both structured and always orthogonal.

A systematic use of facets (better known as FACET-ics) is experiencing steady growth within business processes across the globe. 

FACET-ics reduce the complexity associated with the singular-monolithic hierarchy once used in business. At that time, the technology simply could not support FACET-ics.


What is a product-definition standard?

A product-definition standard is a part of “an agreement of common understanding"2 for a key set of data elements required for product data exchange inside and outside the enterprise.

Why is a product-definition standard needed?


Assumptions -


· A firm will continue to do business with a select but growing number of partners around the world
· Between the partnerships, the firm will look for ways to leverage product data
· Product data will need to be exchanged regardless of IT systems deployed by each partner


Conclusion -


Utilizing an "agreement of common understanding" for the fundamental data elements, in conjunction with a universal data exchange standard, will facilitate data exchange between partners. A product definition serves as the basis for such agreements.

The Current Business Climate
Ø Broader range of "Products" are being offered to customers

§ Solution – A combination of multiple products bundled together to deliver functionality of value to customers e.g., "a device and cell phone service"
§ Equipment – Products, generally sold to an integrator. The integrator combines the equipment to form a specific solution for the customer. e.g., "Motorola Droid" and "Verizon's 4G"
§ Module - e.g., "Engine", "Transmission" or "Pump"
§ Part Usage – a place holder for a class of parts that may include variants.
§ Constituent - e.g., "Bolt" (single-part with a unique identifier ), "Welded Bracket" (dictated-assembly with a unique identifier), "Software Patch" (compiled-object code with a unique identifier) or "Alternator" (purchased-component with a unique identifier)

Ø Streamlined and more consistent "business processes" are being shared across enterprise divisions leading to better performance

Ø Project risk management - "Reusing" vs. ”Inventing"
§ Leveraging prior knowledge and experience to shorten development cycles
v Outside reuse - Supplier collaboration - Modularity with established system interfaces
v Inside reuse - Cross-division sharing - Modularity with options - e.g., Steering column module w/ or w/o turn-signal switch option.
§ Taking advantage of assets through economies of scale

Ø Evolving international standards - e.g., ISO 9000, ISO 10303, BPMN 2.0, BPEL

Ø The extended enterprise will probably never reside on "one" computer system even with "the cloud" on the horizon. Therefore, by necessity, product data must some how be exchanged.

Ø Product portfolio projects are popping up with "The Plan" for profitability

W5H23 -
"The Plan" tells How Much of What is needed When. Where that functionality will be encapsulated. How it will be realized. Who has the skill and drive to accomplish it. And of course, Why it is so important to make the change now.

The Orthogonal Tagging Framework:

When developing a plan, there seems to be a natural and cascading progression for how products are defined and structured. The order of progression is Change Management, Responsibilities, Functions, Systems, Objectives, Structures and Options.

Each of these seven views is described in more detail below:

CHANGE MANAGEMENT: WHY does a change need to be made?

Example: "Recurring field complaint on existing product" OR "New application of technology expected from a competitor 6 months from now".

Engineering Change Notices contain "reasons for change" and inherent embedded effectivity relationships to all product items.

Nothing is static. As designs are refined, it is necessary to transition through structures, sometimes known as version control. It is sometimes necessary to keep records of how the product data was in the past. Product lifecycles are a continuums connected by change events. If having past, current and future structures in the same IT environment is desirable, and it is, then there needs to be a way to return to the appropriate effectivity state. Some call this configuration management as contrasted with variant management (as described in the “Options” view below.) 

Variant management addresses less the versions of the design through time and more about the variant selections made by various groups or responsibilities throughout the enterprise.

RESPONSIBILITIES:
WHO has the skill set to create, deliver and support the changes?

Example, "Advanced Product Designer" OR "Embedded Software Engineer" OR "Field Specialist" from internal expertise or another partner.

Skill set and experience levels determine the level of responsibility that can be taken for a given piece of equipment, module or constituent. Depending on the types of technology within the boundary of the product, responsibility is matched to the skills to assure functionality is delivered in the best way possible.

FUNCTIONS:
WHAT does the customer want to do?

Example, "Find a particular type of business close to the his present location" OR "Place a call to a colleague."

Customers use functional terms to discuss "value" they expect from a solution. Among other things, customers will evaluate the solutions offered by the Enterprise based on cost of functionality delivered.

SYSTEMS: HOW will this functionality be created and delivered?

Example, "Mechanic:Fluidic:Hydraulic oil" OR "Electronic:CAN communication"

Both equipment and modules are connected together to deliver functionality for a customer application. The connections make use of the technologies that are most appropriate. Items, properly connected to each other within a module, form the conduits for delivering expected functionality.

OBJECTIVES: HOW MUCH functionality will satisfy this need?

Example, "Plant Corn at a rate ranging from 30,000 - 150,000 seeds per acre".

Even though one customer uses the same functional terms, it is not always clear that they are speaking of the same quantity or magnitude. Objectives quantify and bound functional expectations.

STRUCTURES: WHERE will this functionality be contained or embedded?

Example, "Hydraulic Motor" OR "Display"

Encapsulated function within chunks of physical space or software code with well-defined interface boundaries providing the assembly factory the latitude to build combination of choices the customer wants in a demand-flow environment. Modularization is the process of breaking up the product into the proper chunks so that designs are reusable within the enterprise. Modularization, by nature of its reusability, also provides the benefit of fast time to market and flexibility to develop products for new markets without long development projects. Managing the connection features, parameters and protocols, as the case may be, also provides the enterprise with the ability to "Design Anywhere, Build Anywhere, Use Anywhere", should that become an enforceable strategy.

OPTIONS: WHEN will we put this quality level of functionality into the solution?

Example, "On-the-go automatic seed rate adjustment" OR "Manually-selected seed rate".

An option is a grouping of the objectives constrained to specific range of functionality. Options are the enterprise's decision what choices the customer can make to tailor value to individual applications. Selecting the appropriate variables and ranges is based on solution packaging decisions on the upper level and technical decisions on a lower level. Both levels of options must be in harmony or else there is pressure for change. In any case, the technical and legislative option rules must never be violated by the customer selections otherwise design intent cannot be assured.

A product definition documents a fundamental level of agreement between all the business partners by supporting "a neutral mechanism capable of describing product data throughout the life cycle of a product; independent from any particular system", i.e., ISO 10303. The elements of the plan provide the key for exchanging data and determining opportunities for design reuse.

The framework outlined above can be linked with the ISO 10303 - "Industrial automation systems and integration - Product data representation and exchange" (i.e., STEP). Gaining agreement between business partners of these key data elements contributes to more seamless data exchange, facilitating collaboration with both internal and external partners. (Every shared data element is not incorporated in A product definition standard .) Industry must actively propose changes to the ISO standard as product data concepts are extended for your company's needs.

A product definition is thus focused on capturing several key data elements and enumerating values for them.

1 "The strict faceted classification model" by Travis Wilson, Facetmap http://facetmap.com/pub/strict_faceted_classification.pdf

2 ISO 10303-41:1994, Industrial automation systems and integration - Product data representation and exchange - Part 41: Fundamentals of product description and support.
3 Bradford, Jim, "Project Management Training Program", Project Management Associates, 1988

 



Copyright © 2013 FACET-ics LLC All rights reserved.

  Site Map