Top Banner
1 The Design-Chain Operations Reference-Model By John Nyere At Supply Chain World 2006 in Dallas the Supply-Chain Council (SCC) introduced the first release of the Design-Chain Operations Reference-model (DCOR™). The new model fills voids associated with the Supply-Chain Operations Reference-model (SCOR®) and creates a value chain that unites the design chain and the supply chain. These process reference models integrate the well-known concepts of business process reengineering, benchmarking and process measurement into a cross-functional framework. Before describing the details of the Design-Chain Operations Reference- model, let us review the original SCOR-model and explain the need for DCOR. SCOR The Supply-Chain Operations Reference-model was developed and endorsed by the SCC as the cross-industry diagnostic tool for supply chain management. SCOR enables users to address, improve and communicate supply chain management practices between interested parties. The model has been used and continuously improved over the past ten years. SCOR is a process reference model for supply chain management, spanning from the supplier’s supplier to the customer’s customer. Virtually every supply chain practitioner knows SCOR’s five major processes: Plan, Source, Make, Deliver and Return (Figure 1). Figure 1. SCOR’s five major management processes. Supplier Plan Customer Customer’s Customer Suppliers’ Supplier Make Deliver Source Make Deliver Make Source Deliver Source Deliver Internal or External Internal or External Your Company Source Return Return Return Return Return Return Return Return DCOR Version 1.0™, Copyright the Supply-Chain Council. This paper was published with the concurrence of the Supply-Chain Council and extensively references DCOR Version 1.0.
15
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: DCOR by John Nyere

1

The Design-Chain Operations Reference-Model

By John Nyere

At Supply Chain World 2006 in Dallas the Supply-Chain Council (SCC) introduced the

first release of the Design-Chain Operations Reference-model (DCOR™). The new

model fills voids associated with the Supply-Chain Operations Reference-model

(SCOR®) and creates a value chain that unites the design chain and the supply chain.

These process reference models integrate the well-known concepts of business process

reengineering, benchmarking and process measurement into a cross-functional

framework. Before describing the details of the Design-Chain Operations Reference-

model, let us review the original SCOR-model and explain the need for DCOR.

SCOR

The Supply-Chain Operations Reference-model was developed and endorsed by

the SCC as the cross-industry diagnostic tool for supply chain management. SCOR

enables users to address, improve and communicate supply chain management practices

between interested parties. The model has been used and continuously improved over the

past ten years.

SCOR is a process reference model for supply chain management, spanning from

the supplier’s supplier to the customer’s customer. Virtually every supply chain

practitioner knows SCOR’s five major processes: Plan, Source, Make, Deliver and

Return (Figure 1).

Figure 1. SCOR’s five major management processes.

Supplier

Plan

CustomerCustomer’s

Customer Suppliers’ Supplier

Make DeliverSource Make DeliverMake SourceDeliver SourceDeliver

Internal or External Internal or External

Your Company

Source

Return Return ReturnReturn Return Return

Return Return

DCOR Version 1.0™, Copyright the Supply-Chain Council. This paper was published with the concurrence of the Supply-Chain Council and extensively references DCOR Version 1.0.

Page 2: DCOR by John Nyere

2

The SCOR-model describes the business activities associated with all phases of satisfying

customer demand. By using process building blocks, the model can describe supply

chains that are very simple or very complex using a common set of definitions. SCOR

has been extremely successful in describing and providing a basis for supply chain

improvement for global and site-specific projects. In the U.S. Department of Defense, the

reference model brings together multiple armed services, commands and agencies to

define what they do. SCOR also brings a complete set of inputs, outputs, metrics and best

practices that can be configured to achieve desired outcomes. Make no mistake, in

addition to being a process reference model, SCOR is a continuous-improvement process

methodology.

Yet SCOR is silent on a number of key business functions. Specifically, the

model does not address: sales and marketing (demand generation), product development,

research and development, and some elements of post-delivery customer support. In

response to an overwhelming consensus of members, the Supply Chain Council

developed DCOR to address the product development and research and development

business processes.

Early Design-Chain Operations Reference-model development

The SCC did not develop the DCOR model from scratch; it inherited an initial

draft from the Business Process Management organization within Hewlett-Packard (HP).

Under the lead of Joe Francis and Caspar Hunsche, HP developed the first Design-Chain

Operations Reference-model. Not only did HP managers see a need for a Design-Chain

model to be appended to the Supply-Chain model, they saw the need to develop a

Customer-Chain Operations Reference-model (CCOR). DCOR’s structure, and that of

the forthcoming CCOR, were inspired by SCOR. Both HP models were conveyed to the

Supply-Chain Council in June 2004.

In March 2005 the Technical Development Steering Committee chartered a group

of practitioners to develop the first DCOR model to be released by the Supply-Chain

Council. In March 2006 they released Version 1.0 at Supply Chain World, the

organization’s annual global conference.

What is DCOR?

The Design-Chain Operations Reference-model (DCOR) is a cross-industry

diagnostic tool for design-chain management. DCOR enables users to address, improve

and communicate design-chain management practices within and between interested

parties. It spans product development and research and development, but does not

describe sales and marketing (demand generation) and post-delivery customer support.

Like SCOR, the DCOR model is organized around five primary management

processes: Plan (Design Chain), Research, Design, Integrate and Amend (Figure 2).

Page 3: DCOR by John Nyere

3

The intersections between SCOR and DCOR will be further clarified by the Supply-

Chain Council in 2008; most of the actual exchanges will take place in the enable

processes and in the planning processes of the model.

DC Integrate

I

DC Design

D

DC Research

R

DCPlan

(DesignChain)

P (DC)

Top Level -

Design Chain Operations Reference Model - Version 1.0

DCDesignChain

DCOR

DC Amend

A

Figure 2. DCOR is organized around five major management processes.

Plan (Design Chain), Research, Design, Integrate and Amend

DCOR’s five basic management processes are defined as follows:

Plan (Design Chain). The development and establishment of courses of action

over specified time periods that represent a projected appropriation of design chain

resources to meet design chain requirements.

Research. The Research management process encompasses the identification and

decomposition of research topics, obtaining and synthesizing of information and

evaluation and publishing or archiving of research findings. This includes the

identification of sources of supply, sourcing and validation of materials/products against

requirements.

Design. The Design management process encompasses the refresh of definition,

creation, analysis, testing and release of form, fit and function of an existing product.

This includes reviewing and adjusting sourcing, manufacturing, testing, servicing and

disposal processes.

Integrate. The Integrate management process encompasses releasing refreshed

product and new product definitions to Supply Chain for execution and releasing

refreshed and new product design documentation to Marketing and Support

organizations.

Page 4: DCOR by John Nyere

4

Amend. The Amend management process encompasses the gathering and

analysis of product design issues and manufacturability feedback for current products.

To differentiate the “Plan” or “P” process in the Design-Chain model from the

“Plan” process in the Supply-Chain model, and the Design (“D”) process in the Design-

Chain from Deliver (“D”) in the Supply-Chain model, the DCOR project development

team clearly identified all processes, process categories and process elements as being

components of the Design-Chain. In Figures 2, 3, 4 and 5, every object that belongs to the

Design-Chain model and not to the Supply-Chain model is clearly identified with a “DC”

to differentiate it from a supply chain process, process category, process element, input

and output, metric or best practice. This was essential because the two models will be

joined and rationalized over the coming months.

DCOR-model Structure

Beside the five basic management processes that provide the organizational

structure of the DCOR-model, it is useful to distinguish between the three process types

in the model: planning, execution and enable.

DC Integrate

I

DC Design

D

DC Research

R

DC

Plan(DesignChain)

P (DC)

DCDesignChain

DCOR

DC

R3 ResearchNew

Technology

R3

DC

R2 ResearchNew

Product

R2

DCPD PlanDesign

PD

DCPI Plan

Integrate

PI

DCPR PlanResearch

PR

DC

PP PlanDesignChain

PP

DCED Enable

Design

ED

DCOR Overview: Level 1 & Level 2

DC

D3 DesignNew

Technology

D3

DC

D2 DesignNew

Product

D2

DC

D1 DesignProductRefresh

D1

DCEI EnableIntegrate

EI

DC

I3 IntegrateNew

Technology

I3

DC

I2 IntegrateNew

Product

I2

DC

I1 IntegrateProductRefresh

I1

DCER EnableResearch

ER

DCEP Enable

Plan

EP

DC Amend

A

DC

R1 ResearchProductRefresh

R1

DCEA Enable

Amend

EA

DCPA PlanAmend

PA

DC

A3 AmendProductSpecs

A3

DC

A1 AmendProductFallout

A1

DC

A2 AmendDeficientProduct

A2

Execution Processes

Enable Processes

Planning

Processes

Figure 3. Level 1 and Level 2 DCOR Planning, Enable, and Execution process types

Page 5: DCOR by John Nyere

5

Planning processes align expected resources to meet expected design requirements.

Planning processes balance aggregated demand across a consistent planning horizon.

They generally occur at regular intervals and can contribute to design chain response

time.

Execution processes are triggered by planned or actual demand that changes the state of

products. They include scheduling and sequencing, researching and design, materials and

integrating product, and amend.

Enable processes prepare, maintain and manage information or relationships upon which

planning and execution processes rely.

The SCOR process categories are constructed around 1) Stocked Product, 2)

Make to Order Product and 3) Engineer to Order Product. In DCOR, within the Research,

Design and Integrate processes, the common internal structure (Figure 3), focuses on

three environments: Product Refresh, New Product and New Technology. R1 is

Research Product Refresh, R2 is Research New Product and R3 is Research New

Technology. This same convention is used for Design (e.g., D1 – Design Product

Refresh) and Integrate (I1 – Integrate Product Refresh).

DCR3 Research

NewTechnology

R3

DCR2 Research

NewProduct

R2

DCD3 Design

NewTechnology

D3

DCD2 Design

NewProduct

D2

DCD1 Design

ProductRefresh

D1

DCI3 Integrate

NewTechnology

I3

DCI2 Integrate

NewProduct

I2

DCI1 Integrate

ProductRefresh

I1

DCR1 Research

ProductRefresh

R1

Figure 4. DCOR Focus: Product Refresh, New Product and New Technology

Product Refresh, New Product and New Technology

The three constructs—Product Refresh, New Product and New Technology—vary

from industry to industry. Product Refresh relates to an existing product. In the

automotive industry, this would equate to introducing “next year’s” model when a

company spends 15 months to incrementally improve upon an existing model. In the

technology area, product refresh may span three to four months.

Product Refresh

New Product

New Technology

Page 6: DCOR by John Nyere

6

A new product equates to an automotive manufacturer introducing a totally new

product, e.g., a truck, when the company had only produced passenger vehicles to date.

This may take as long as seven years. In the U.S. Department of Defense it takes even

longer to introduce a new weapon system.

With new technology, a company may be operating in a space where they have

never operated before, such as fuel cell technology to continue the automotive example.

Obviously, the cycle time (time to market) will be progressively longer as companies

refresh, introduce new products and employ new technologies. Correspondingly, it costs

less to refresh than to introduce new products (higher) and new technologies (highest).

Amend Process, Process Categories and Elements

While SCOR’s Return Process decomposes into sourcing and delivering

defective, repairable and excess product, DCOR’s Amend Process deals with product

fallout, deficient product and product specifications. Each of DCOR’s three Amend

Process categories warrant further examination.

First is the process category A1, Amend Product Fallout, which is the process of

gathering, analyzing and addressing issues related to a product’s manufacturability.1 The

process is triggered by feedback (an issue) that manufacturing quality or other process

standards/metrics cannot be met. The Amend Product Fallout process category ends with

the publication of an Advisory (the Engineering Change Notice). Amend Product Fallout

decomposes into four process elements, as shown below in Figure 5:

DCA1 Amend

ProductFallout

DCA1.1 Receiveand Validate

Issue

A1.1

DCA1.3

DistributeIssue

A1.3

DCA1.2

DecomposeIssue

A1.2

DCA1.4 Publish

Advisory(ECN)

A1.4

Figure 5. The Amend Product Fallout process elements

The second Amend Process category is Amend Deficient Product (A2), which is

the process of gathering, analyzing and addressing a product's technical design

deficiency. The process is triggered by feedback that product performance, behavior

and/or appearance do not meet product specifications. This includes tolerances for safety.

The process ends with the publication of an advisory.

1 The complete definition of A1 is “The process of gathering, analyzing and addressing products

manufacturability. The process is triggered by feedback that manufacturing quality and process

standards/metrics cannot be met. This includes regulatory compliance issues.”

Page 7: DCOR by John Nyere

7

DCA2.1 ObtainDef iciencyInf ormation

A2.1

DCA2.2

ValidateIssue

A2.2

DCA2.3

DecomposeIssue

A2.3

DCA2.4

DistributeIssue

A2.4

DCA2.5

PublishAdvisory

A2.5

DCA2 AmendDef icientProduct

A2

Figure 6. The Amend Deficient Product process elements

The third Amend Process category is Amend Product Specifications (A3), which

is the process of gathering, analyzing and addressing a product's specifications. The

process is triggered by feedback that the product’s specifications as published must be

revised. The A2 process culminates with the publication of a Specification Change Order.

DCA3 Amend

ProductSpecs

A3

DCA3.1 ObtainSpecif icationInf ormation

A3.1

DCA3.2

ValidateIssue

A3.2

DCA3.3

DecomposeIssue

A3.3

DCA3.4

DistributeIssue

A3.4

DCA3.5

PublishSCO

A3.5

Figure 7. The Amend Deficient Product process elements

DCOR, like SCOR, Contains Three Levels of Process Detail

For those familiar with SCOR, it should be apparent that DCOR has maintained

the same three process levels that SCOR has employed for a decade (Figure 8). Level 1 is

made up of the process types, including Plan, Research, Design, Integrate and Amend.

From the practitioner’s perspective it is here that performance targets are established. At

Level 2, the Configuration level, the process categories are configured to meet a

company’s strategy.

Page 8: DCOR by John Nyere

8

Figure 8. DCOR is hierarchical with three levels

Amend

Level

Description Schematic Comments

Top Level (Process Types)

Level 1 defines the scope and content for

the Design-Chain Operations Reference-

model. Here basis of competition

performance targets are set. Research Design Integrate

Plan1

#

ConfigurationLevel(Process Categories)

A company’s design chain can be

“configured-to-order” at Level 2 from

core “process categories.” A company

implements its strategy through the

configuration managers choose for their

design chain.

2

Process Element Level

(DecomposeProcesses)

Level 3 defines a company’s ability to

compete successfully and consists of:

Process element definitions

Process element information

inputs and outputs

Process performance metrics

Best practices, where applicable

System capabilities required to

support best practices

Systems/tools.

Companies “fine tune” their strategy at

Level 3.

3

PD.1

PD.2xxxxxxxx

PD.3 PD.4Establish Design Plan

Companies implement specific design

chain management practices at this level.

Level 4 defines practices to achieve

competitive advantage and to adapt to

changing business conditions.

ImplementationLevel

(DecomposeProcess

Elements)

4

Not

In

Scope

Desig

n-C

hain

Op

era

tio

ns R

efe

ren

ce-m

od

el

Page 9: DCOR by John Nyere

9

At Level 3 we have the process elements, what some call “functional activity

descriptions.” Fine tuning the company’s strategy takes place at this level. It is at Level 3

where a process element has inputs, outputs, metrics and best practices. Here companies

can begin to configure their business to drive the intended results. Let’s look at one

process element: EP.2, Manage Design Chain Performance:

DCReliable Continuous

Improvement Processand Methodology.

DC

Efficient andeffective

benchmarkingprocess

DCSound Project

Management Processand Methodology

DCBusiness

Rules

EP.1

DCManage

PlanInformation

EP.3

DC

ManageDesignChain

Performance

EP.7

DCEP.2 ManageDesign ChainPerformance

EP.2

COST

DCManage Design

Chain PerformanceCost

RESPONSIVENESS

DC

Manage DesignChain

PerformanceCycle time

DCLean andSix Sigma

Figure 9. EP.2, Manage Design Chain Performance

In a process element the input’s source and output’s destination are conspicuously

identified. For example, the Input, Business Rules, comes from Enable Plan (EP.1),

Manage Business Rules. The Output, Manage Design Chain Performance goes to EP.7,

Manage Design Chain Configuration. If the company is focused on responsiveness and

not cost, managers would put the responsiveness metric “in scope” and the cost metric

“out of scope.” DCOR provides over two hundred best practices that a company can use

(or not). In Figure 9, for example, Lean Six Sigma is one of four best practices that may

be applied to this process element.

As a side note, the model conveyed to the Supply-Chain Council, came without a

single best practice. The DCOR team applied applicable best practices from the SCOR

model to DCOR, leveraged the U.S. Department of Defense’s repository for best

practices, and the Corporate Synergy Development Center in Hong Kong for design-

related best practices.

BEST

PRACTICES

DESTINATION OF

OUTPUT

OUTPUT

SOURCE OF SPECIFIC INPUT

INPUTPROCESS ELEMENT

METRICS

(Clearly

identified by

category)

Page 10: DCOR by John Nyere

10

As with best practices, the model conveyed by HP did not contain a complete

metrics suite. It still does not but the DCOR development team went to great lengths to

ensure that every process, every process category and especially every process element

had a responsiveness metric and a cost metric associated with it. Both best practices and

metrics will be improved in future releases of DCOR. Regardless, this brief discussion of

metrics at the lowest level is a good segue into the overall Performance Attributes and

Level 1 Metrics of the DCOR model.

Performance Attributes and Level 1 Metrics

Referring back to the Level 3 model (Figure 6), Level 1 Metrics are primary, high level

measures that cross multiple DCOR processes. Level 1 Metrics do not necessarily relate

to a DCOR Level 1 process (Plan, Research, Design, Integrate and Amend). Again, the

model remains true to the SCOR framework by maintaining the same five performance

attributes employed in SCOR: Reliability, Responsiveness, Flexibility, Costs and Assets

(Figure 8). As stated above, Responsiveness and Costs were the focus for this first release

of DCOR.

Performance Attributes

Level 1 Metrics Reliability Responsiveness Flexibility Costs Assets

Perfect Product Design x

Design Chain Cycle Time x

Product Design Change Cycle Time x

Total Design Chain Cost x

Design Chain FTE per Product Design x

Design Chain Fixed Assets Value x

Figure 10. DCOR Level 1 metrics and performance attributes

The Design Chain Reliability Performance Attribute (Level 1) is Perfect Product Design.

It measures the performance of the design chain in delivering: the correct design to the

correct place at the correct time in the correct format with the correct documentation to

the correct customer.

The Design Chain Responsiveness Performance Attribute (Level 1) is Design Chain

Cycle Time. It measures the speed at which a design chain provides products to the

customer.

The Design Chain Flexibility Performance Attribute (Level 1) is Product Design Change

Cycle Time. It measures the time to change a product design after it has been released to

operations.

The Design Chain Costs Performance Attribute (Level 1) is Total Design Chain Cost. It

provides the costs associated with operating the design chain.

Page 11: DCOR by John Nyere

11

The Design Chain Assets Performance Attribute (Level 1) is the effectiveness of an

organization in managing assets to support design chain operations. This includes the

management of all assets: fixed and working capital.

Using DCOR by Itself or in Concert with SCOR

SCOR has been employed for nearly a decade without the benefit of DCOR. Like

SCOR, DCOR can be used by itself to support analysis, measurement and improvements

of design chains. In “fabless” industries where companies design but do not manufacture

or distribute product, the DCOR model has tremendous potential. Keeping DCOR loosely

integrated with the other reference models that make up the Council’s Integrated

Business Reference Framework (see next paragraph) allows the other models to be

improved on or used independent of the others. The maturity levels of the reference

models are also very different, with SCOR being a very mature model and DCOR

waiting for refinement by practitioners.

Loose model coupling also unburdens the two different disciplinary areas. But

some benefits can only be realized by coupling the two models in an expanded value

chain. Tradeoffs and optimization between supply and design can now be made. Time to

market and time to volume can only be measured when the two models are used together.

The Integrated Business Reference Framework

DCOR Version 1.0 March 2006DCOR Version 1.0 March 2006DCOR Version 1.0 March 2006SCOR Version 8.0 March 2006

SCOR Version 8.0 March 2006CCOR Version 1.0 2007CCOR Version 1.0 2007CCOR Version 1.0 2007

Business

Plan

Business

Plan

Design

ChainPlan

Design

ChainPlan

Supply

ChainPlan

Supply

ChainPlan

Customer

ChainPlan

Customer

ChainPlan

DesignDesign

MakeMake

SellSell

IntegrateIntegrate

DeliverDeliver

PricePrice

ResearchResearch

SourceSource

RelateRelate

AmendAmend

ReturnReturn

AssistAssist

Figure 11. Supply-Chain Council’s Integrated Business Reference Framework2

Figure 11 presents the Integrated Business Reference Framework first described

at Supply Chain World in 2006. With the release of DCOR, two thirds of the overall

framework are now in place. CCOR is the final third of the overall framework, which is

scheduled to be released in 2008. The Integrated Business Reference Framework is the

2 The Integrated Business Reference Model was developed by Scott Stephens, former Chief Technology

Officer of the Supply-Chain Council, who presented it at Supply Chain World 2006.

Page 12: DCOR by John Nyere

12

business plan that drives all of the company’s value chains. As illustrated below,

customer requirements, product data management (PDM) and product lifecycle

management (PLM), cycle times and costs, can now be gauged in a more complete

manner:

---------------Supply Chain-------------

.

Figure 12. Customer Requirements, Cycle Times, Bills of Materials and Product

across the Integrated Business Reference Framework

Let me conclude with a couple of comments about the integrated framework.

First, there will need to be a leveling between the SCOR model and the DCOR model.

Over time, the SCOR model added more detail to the processes associated with engineer

to order (ETO) product and—to a lesser degree—the make to order and the stocked

product “chains.” SCOR S3, M3 and D3 respectively address Source, Make and Deliver

ETO product as shown in Figure 13.

SC

S3 Source

ETO

Product

S3

SC

M3 Make

ETO

Product

M3

SC

D3 Deliver

ETO

Product

D3

Figure 13. The SCOR Engineer to Order value chain

Design Integrate DeliverResearch Source

Design Chain Cycle Time Order Fulfillment Cycle Time

Make

--------------------Design Chain------------

Customer Requirements

Product

Bill of Materials, Recipe, Specification

Page 13: DCOR by John Nyere

13

But with the addition of DCOR’s New Product R2, D2 and I2, we have a value

chain that looks like Figure 14.

DCR2 Research

New

Product

R2

DCD2 Design

New

Product

D2

DCI2 Integrate

New

Product

I2

SCS3 Source

ETO

Product

S3

SCM3 Make

ETO

Product

M3

SCD3 Deliver

ETO

Product

D3

Figure 14. The DCOR and SCOR Engineer to Order value chain for New Product

The M3 process level looks like this:

M3.6 Stage FinishedProduct(e-t-o)

M3.6

M3.5 Package(e-t-o)

M3.5

M3.4 Produceand Test

(e-t-o)

M3.4

M3.3 IssueProduct(e-t-o)

M3.3

M3.2 ScheduleProduction

Activ ities (e-t-o)

M3.2

M3.1 FinalizeProductionEngineering

M3.1

M3 Engineer-to-Order

M3

M3.7 ReleaseProduct to

Deliver (e-t-o)

M3.7

Figure 15. Engineer to Order value chain for New Product

M3.1 is the process element “Finalize Production Engineering,” which is defined

as “Engineering activities required after acceptance of order, but before product can be

produced. [They] may include generation and delivery of final drawings, specifications,

formulas, part programs, etc. In general, the last step in the completion of any preliminary

engineering work done as part of the quotation process.”

Page 14: DCOR by John Nyere

14

M3.1 Finalize

Production

Engineering

M3.1

Number

of ECOs

ECO cost

Delivery

Performance

to CustomerCommit Date

Capacity

Utilization

Production

Engineering Cycle

Time

Automated conversionof engineering drawings into

product specifications

AutomatedConfigurationManagement

Assets

Cost

Reliability

Responsiveness

Methods,

Procedures,

Processes

M3.2

Engineering

Design

Order

Information

D3.3

Figure 16. Finalize Production Engineering process element M3.1

Note that there are two inputs and a single output for M3.1. In addition to order

information, Engineering Design is the second of the two inputs for this function.

Engineering Design will clearly come from the Design Chain, from either the Product

Refresh or New Product value chains. Methods, Procedures and Processes comes out of

M3.1, which is defined as: “Methods, procedures and processes required to produce

distinct items, such as parts that retain their identity through the transformation process

and are intended to be completed after receipt of a customer order, including custom

products that are designed, developed and produced in response to a specific customer

request.”

What this says is that in the case of Product Refresh, design specifications come

out of D1.5 (Release Design to Integrate) and go to I1.3 (Obtain and Validate Design)

where they continue through the remainder of the I1 process elements and finally result

as I1.6 (Release Product) as product specifications.

Concluding Remarks

For the first time organizations have communications tools that bring together the

design and supply chain to address problems that span more than just the supply chain.

SCOR and DCOR enable them to address problems specific to the supply chain or the

design chain, or both. Using the integrated framework companies can address process

threads that span a product’s lifecycle—not just the supply chain portion. The overall

Page 15: DCOR by John Nyere

15

framework can be used to develop a more balanced scorecard with a more complete set

of measurements that can be benchmarked.

As a member of the Supply-Chain Council’s Technical Development Steering Committee,

John Nyere led the development of the first release of the Design-Chain Operations

Reference-model (DCOR). He is the Special Assistant for Supply Chain Integration

serving in the Office of the Deputy Under Secretary of Defense for Business

Transformation in the U.S. Department of Defense. Nyere is a graduate of Washington

State University and the U.S. Naval Postgraduate School.

Other principals associated with the Supply-Chain Council’s release of DCOR Version

1.0 were Nicolas Giraldo (Azurian), William Whiddon (Building Technology Inc.), Ari

Luis C. Halos (College of Engineering and Agro-Industrial Technology, University of the

Philippines Los Baños), Christie Lin (Corporate Synergy Development Center, Hong

Kong), Michael Salhlin and Lars Magnusson (Ericsson), Joseph Francis and Caspar

Hunsche (Process Core Group, LP), Eberhard Frey (Hewlett Packard), and Ricardo

Velez (Tampere University of Technology, Finland); with assistance from Scott Stephens

(Technical Director, the Supply-Chain Council) and Melinda Spring (Technical Program

Development Director, the Supply-Chain Council).