7. LA01_DCP_2021-03-10-133708

An Odette Publication
Demand Capacity Planning
Ref LA01 Version 1.1 Published April 2004

Demand Capacity Planning – V 1
Overview
Executive Summary
The promising potential of modern Supply Chain Management (SCM) concepts is
attracting the attention of the whole automotive industry. These concepts address root-
causes of current limitations in many logistics networks. Efficient build-to-order strategies
and short time to delivery goals require fast, flexible and reliable supply networks. In this
context inter-company visibility and transparency of relevant data play a central role.
Modern SCM aims to complement current plant or company centric processes based on
ERP systems by linking together the different actors in supply networks and establishing
well defined collaboration processes. Thus SCM is a core element in overcoming the
local, company-centric view and enabling a global view on supply networks.
The Odette SCM is developing recommendations for selected SCM building blocks by
bringing together the know-how and experience of OEMs and major suppliers.
This recommendation describes the SCM building block “Demand Capacity Planning”
(DCP). It incorporates business process model, functionalities and the respective data
elements/messages. The goal of the recommendation is to set a de facto standard for
DCP in the automotive industry and to establish a basis for interoperability of DCP
applications from different software providers and marketplaces.
The goal of Demand Capacity Planning (DCP) is to avoid significant capacity
shortfalls and situations of serious under-utilisation. The emphasis is on potentially
serious misalignments beyond the time horizon covered in existing production planning
systems. Therefore DCP is positioned as a complement to existing ERP-systems.
A key element in DCP is the detection of potential misalignments (capacity shortfalls or
under-utilisation) early enough to take preventive actions. After receiving updated
demand forecast information, DCP highlights the time periods with serious under or over
capacity. In the first stage of problem solving, the supplier tries to adjusts his capacity to
the new demand situation with internal measures (e.g. banking, overtime, non-working
shifts). If these measures are not sufficient to solve the issue, the supplier will work with its
customer(s) to evaluate and decide on additional collaborative measures. These
measures (e.g. installation of additional shift, new tool, new line) are typically associated
with long lead-times for implementation, significant investment and risk and therefore
require approval of the commercial areas (purchasing / sales).
The proposed concept with its systematic, integrated and fast process and collaborative
elements leads to earlier and more reliable detection of capacity issues and will allow the
supplier to better adapt his capacity to the fluctuations of demand.
When Odette started the DCP project, several companies (e.g. Audi/VW, DC (MCG),
Ford, GM, PSA, Renault) had either already introduced or at least planned to introduce
DCP applications. GM Europe for example started in 1999 with a system called CAMAS.
In 2002 1.800 suppliers with 50.000 part numbers were using the solution. And this is just
one example.
The drivers to standardise the basic functionality and processes of DCP are:
! Suppliers want to avoid having to implement individual solutions with every customer
and want to see consolidated demands for capacity planning
! Customers want to minimise the effort for roll-out of the DCP process to their suppliers
! From the standpoint of a single company, the implementation of individual DCP
systems with all relevant business partners is very time consuming and inefficient.
Page: 2 / 37
Overview
Project participation
The following companies were part of the Demand Capacity Planning Project working
group:
OEMs Suppliers Organisations

DaimlerChrysler Bosch Galia
GM/Opel Faurecia SMMT
PSA Peugeot Citroën Siemens VDO
Renault Treves
Volvo Cars
Overview - How to use the Recommendation

The recommendation consists of 3 parts:
! The current Central Document divided in 8 chapters
! Presentations , e.g. for training purposes (to be found in appendix)
! XLS proof of concept (to be found in appendix)
In addition it provides presentations, e.g. for training purposes (to be found in appendix).
Chapter 1, Philosophy of Supply Chain Management, describes the foundation of modern

SCM concepts while chapter 2 gives an introduction to DCP.
Chapter 3, Business Process Description, describes the basic concepts. More details are
given in the corresponding WP3 presentation file.
Chapter 4, Functionality, details the recommended functionalities. More details are given
in the corresponding WP4 presentation file, including commented screen copies of the
XLS proof of concept.
Chapter 5, to 8 describe Responsibilities, Data Description, Technical Aspects and
Appendix.
For readers with an IT background, we advise to read chapters 2, 3, 6 and 7 first. To go

more into the details, we advise you to study the Chapter 4.
For readers with a logistics background, we suggest that you first read the chapters 2, 3,
4, 5 . In order to go more into the details, we advise you to look at the WP3 and WP4
presentation files.
Page: 3 / 37
Table of Contents
Table of Contents
1. Philosophy of Supply Chain Management ................................................... 5

2. Introduction to DCP........................................................................................ 6
3. Business Process Description .................................................................... 11
3.1 Initialisation ............................................................................................................11
3.1.1 Demand Information ....................................................................................................................... 11
3.1.2 Capacity Information ...................................................................................................................... 13
3.1.3 Mapping of Demand and Capacity Information.............................................................................. 16
3.2 Problem solving process (mono customer scenario) ........................................18
3.3 Problem solving process (multi-customer scenario) .........................................19
4. Functionality ................................................................................................. 20
4.1 Introduction to the Alerts & Measures board (collaborative view)....................20
4.2 Functionalities of the Alerts & Measures board (collaborative view): ..............22
4.3 Internal Supplier view............................................................................................26
4.4 Multi-customer approach ......................................................................................27
4.5 Additional functionalities ......................................................................................28
5. Responsibilities ............................................................................................ 29
5.1 Functions Involved ................................................................................................29
5.1.1 Medium Term DCP......................................................................................................................... 29
5.1.2 Long Term DCP.............................................................................................................................. 29
5.2 Elements for which responsibility must be taken ..............................................29
5.2.1 Data ................................................................................................................................................. 29
5.2.2 Parameters ....................................................................................................................................... 30
5.2.3 Customer/supplier interface ............................................................................................................ 30
6. Data Description ........................................................................................... 31
7. Technical Aspects ........................................................................................ 32
7.1 Architecture of DCP Solutions .............................................................................32
7.2 Interoperability .......................................................................................................32
7.3 Scalability and Technical Robustness.................................................................36
8. Appendix ....................................................................................................... 37
8.1 Presentations (e.g. for training purposes) ..........................................................37
8.2 Change Request procedure ..................................................................................37
Page: 4 / 37
Demand Capacity Planning – V 1.1
Chap 1 Philosophy of Supply Chain Management
1. Philosophy of Supply Chain Management

The starting point of any Supply Chain Management project should be an in depth
understanding of the current situation in the supply network (e.g. material and information
flows). On this basis, the establishment of consistent and agreed inter-company business
processes can take place. In general this requires an adaptation / re-engineering of
internal business processes of the participants. IT and the Internet play a major role to
enable and support SCM concepts.
The core elements of the SCM philosophy are:
! Customer demand driving the whole inter-company supply network (synchronisation,
built-to-order).
! Increased reaction speed and flexibility of the supply network.
! Multi-tier concepts where applicable.
! Exception based management (alerting)
! Workflow based problem resolution.
! Integrated inter-company processes to collect and share relevant data
" visibility and transparency
! Information relevant for decision making updated in an appropriate period of time
" quick responses
! Simulation of ‘what if’ scenarios.
! Elimination of root causes rather than curing of symptoms.
Page: 5 / 37
Chap 2 Introduction to DCP
2. Introduction to DCP
Capacity alignment has always been an important issue in business. Industrial
companies have therefore established procedures to align their capacities (production
equipment, personnel, etc.) to the volatility of market/customer demand.
The traditional process is usually carried out internally without the direct involvement of
external business partners. Recent developments in the automotive industry (e.g.
globalisation, platform strategies, process standardisation, higher number of model
variants, longer machine running times, shorter product life-cycles) have increased the
difficulties associated with this approach.
The scope of DCP, as described in this recommendation, focuses on the medium/long

term planning aspects. Short term capacity adjustments like the daily allocation of
operators to production lines or work plan optimisation in ERP systems are outside the
DCP scope. (see picture below)
SCMo
Supply Chain
Monitoring
Call-offs, VMI, Kanban DCP DCP

+ short term capacity Ful- medium term long term
alignments fillment
e.g. 1 to 12 months e.g. 1 – 3 years
days months years [time]
operations production sales / purchasing,

users (logistics/ planning project mgmt.
production)
overtime, additional shifts, major investments
examples premium small invest- (tooling, machines,
of freight, ments, large etc.)
measures banking banking
Picture 2-1: Positioning of DCP
The Odette Recommendation proposes an integrated approach with collaborative

elements that helps to overcome the weak points of the traditional approach. It also
provides the means of collecting data to carry out marketing and sales simulations.
The ultimate goal of DCP is to reduce the number of capacity shortfalls and their
consequences significantly and to avoid situations of serious under-utilisation of
capacities. The approach is a significant evolutionary improvement of the traditional,
rather unstructured, cumbersome capacity planning activities.
Suppliers that produce products for various customers using the same resources (e.g.
production facilities) need to check whether their total capacity is sufficient to satisfy the
consolidated potential demand of all customers. This recommendation takes this “multi-
customer scenario” into account.
Page: 6 / 37
Integrated DCP has clear benefits for customers and suppliers:

! Reduction of extra costs (waste) associated with capacity shortfalls:
! premiums for extra hours etc.;
! other unplanned ad hoc activities (e.g. production plan rescheduling);
! opportunity costs (e.g. management could spend more time in value creating
activities instead of devoting time for capacity issues).
! extra transportation cost (premium freight);
! Minimized rejection/loss of customer orders " contribution margin.
! Reduction of all costs associated with idle capacities.
! Enables supplier and customer to optimise their investment planning.
The general principles of integrated DCP are:

! Uniform/agreed demand and capacity constraint definitions.
! Consistent and realistic medium/long term demand forecasts:
! Medium term demand information (typically up to 12 months) represented by the
existing call offs and forecasts on part number level.
! Long term information (e.g. 2 or 3 years) is usually only available on
feature/option/car model/powertrain level. This information needs to be translated to
product types to have a clear meaning for suppliers.
! Capacity constraint definitions that have the same meaning for suppliers and
customers and that can be compared automatically by IT applications with the
respective demand information.
! Low complexity
The basic DCP process, as detailed in the next paragraphs is :

! Early warning system : Detect potential capacity shortfalls and under-utilisation
situations ;
! Alert resolution: When a severe future misalignment is identified, the involved
partners follow an agreed structured resolution procedure.
! Focus on early detection and resolution of the crucial issues that require long lead
times.
Page: 7 / 37
! Early warning system :

Potential capacity shortfalls and under-utilisation situations are detected early enough
to take preventative actions .
DCP focus on severe misalignment only. (see picture below)
“Normal” Demand Volatility Serious Demand / Capacity

Misalignment
Q Q
demand
available capacity
no alert in DCP alert in DCP
[t] [t]
! Alert resolution : using a Two-Stage approach to problem solving

Stage 1 : supplier first tries to adjusts its capacity to the new demand situation with
internal measures
Stage 2 : a collaborative business processes is used to solve the remaining issues
" open communication between suppliers and customers (e.g. transparency of
shared relevant data)
" basis to take the best decisions regarding measures/action plans
Customer Supplier Supplier

demand check total total
!! forecasts !!
(quantities & dates)
+ demand vs.
total capacity "
capacity
Alert ? No
action
-15% ! Yes
Multicustomer scenario : Supplier
internal measures /
The process is more complex.
action plan
"
Alert ? No !
action
-10% !! Yes
Customer Supplier
collaborative measures /
" action plan "
Alert ? No !!
action Legend:
Yes
!! = back-end
-5% !!! system,
" = DCP-Screen
with custo-
mised view
Picture 2-2: Two-Stage Approach to Problem Solving
Page: 8 / 37
! Focus:
Focus on early detection and resolution of the crucial issues that require long lead
times.
The process to define measures to resolve alerts is:
• create incremental capacity ,
• synchronise the implementation of the measure with the demand, taking into
account the implementation reaction time
• give priority to resolving issues with the least amount of slack between now
and the latest date for taking the decision to implement the measure .
capacity Additional assembly line

constraint
[units/w.] Additional mould for plastic housing
Additional equipment for final testing
WE shifts
Increase material supply for parts
Priority should be given to
Current capacity resolving issues with the least
amount of slack
demand Slack available BEFORE
initiating the measure
[units/w.]
0 2 4 6 8 10 20 30 week [time]
reaction time (time for decision taking, planning, implementation of measure)

determines, when a capacity adjustment step (increment) materializes
duration time (minimum duration for the measure)
Picture 2-3: Process to define measures to resolve alerts
Page: 9 / 37
! Architecture : Layer concept

! DCP is a complement (add on) to existing backend systems and does not replace
ERP systems (see picture below)
DCP
collaboration
layer
DCP
private data
C1 area S1 area C2 area S2 area
holding layer
" " " "

back-end
systems
!! !! !! !!
layer
Customer Supplier Customer Supplier
1 1 2 2
Legend: !! = back-end system, " = DCP-Screen with customised view
Picture 2-4 : Architecture with Layer concept
! Collaboration & Confidentiality : Each company has full control over which information
will be made available to which collaboration partner (see picture below)
collaboration area Supplier 1

for Supplier 1 with
private data holding
Customer 1
area of Supplier 1
DCP S1
Customer 1
Customer 2
DCP DCP
C1 C2
DCP S2
private data holding

area of Customer 1
Supplier 2
Picture 2-5 : Collaboration and private Data Holding
Page: 10 / 37
Chap 3 Business Process Description
3. Business Process Description

The Business Processes are divided in two parts:
! Initialisation :
" Demand Information
" Capacity Information (Capacity models, Capacity definitions)
" Mapping of demand and capacity information, in terms of Structure and Time Buckets
! Problem solving :
" MONO-customer scenario
" MULTI-customer scenario
3.1 Initialisation
Initialisation Processes describe the activities that have to be completed before the day
to day operative processes can start.
The customer and supplier each have their own initialisation tasks to perform. Some
collaboration is required between the customer and supplier to ensure that both party’s
have their systems set up in a complementing and compatible way (for instance time
buckets).
3.1.1 Demand Information

In DCP (Demand Capacity Planning), demand means the quantities for a specific
“item” a customer needs for a specific time period. An item can be a part number, a set
of part numbers (= product type), a feature/option, car model/platform, a powertrain,
etc.
Demand could also be expressed as an average usage per standard subdivision of the
defined time periods e.g. average daily usage over six monthly periods.
! Demand at part number level

For medium term DCP, the demand information is generally available at part
number level and typically comes from the material planning systems of different
customer sites (e.g. existing call offs/releases/forecasts).
! Demand at product type level

A product type is a set of part numbers defined through a hierarchical structure.
(see Picture 3-1 : Demand at Product Type Level)
! Demand at feature/option/car model/powertrain level

Long term DCP demand information is often only available at feature/option/car
model/powertrain level (e.g. sun roof, ABS, leather seats, rain sensor, park pilot,
engine, gear box, car model X, engine family Y).
This demand information typically comes from centralised program planning, usually
covers a long horizon (years) and is aggregated on a higher level.
Today this information is often not communicated to suppliers.
Page: 11 / 37
A feature/option generally requires a set of product types (example: the option “park
pilot” requires the product types “park sensor” and “wiring harness”, “Electronic
Control Unit for park pilot” and “display”).
In order to establish meaningful information for suppliers the demand at
feature/option/car model/powertrain level needs to be broken down to product type
level (see Picture 3-2: Demand at feature/option/car model/powertrain level).
The product types need to be defined in such a way that the supplier can map them
unambiguously to capacity constraints.
Multi sourcing quotas need to be applied by the customer prior to sending the
demand information.
sensors
rain distance
sensors sensors
rain rain distance distance

sensor sensor sensor sensor
type F type G type D type E
A 187 320
part number / description

A 187 321 rain sensor type G
with connector X
A 187 322
Picture 3-1 : Demand at Product Type Level
Multi sourcing quotas

platforms 3.000 250 need to be applied by
the customer prior to
2.000 250
demand sending the demand
1000 information
car models
(or powertrains) 4% 5%
2% 2,5% 8% 20%
option level in %
features/
options 100 “rain- 150 “park-
tronic” pilot”
100 100 150 150

rain “rain- wire
sensor tronic” distance harness
product type B-Gen ECU sensor for pp
B-Gen
45% 55%
100 100 68 82 150
rain “rain- wire
allocation to sensor tronic” distance distance harness
suppliers B-Gen ECU sensor sensor for pp
B-Gen
Supplier i Supplier j Customers
Suppliers
Picture 3-2: Demand at feature/option/car model/powertrain level
Page: 12 / 37
Supplier(s) must have the ability to enter (manually or automatically) additional

demand, e.g. for spare parts and for other customers.
Suppliers shall not modify/overwrite the original demand information (the figures
that were generated in the customers planning systems). That means, “unrealistic”
demand information from customers shall be shown in DCP Dash Board and revised
by entering a “fictitious compensatory demand” as an adjustment measure.
DCP uses gross demands with inventory information not taken into account.
It is essential for the supplier to get full transparency on the different origins of
demands (i.e. demand by plant, demand by after-sales organisation etc.) to check the
consistency and completeness of the information.
3.1.2 Capacity Information

In general capacities can be expressed in many cases in a very simple and direct form
as maximum output per item for a specified time interval. Examples:
! Capacity for park sensors type “abc”: 2000 units per day,
! Capacity for aluminum wheels type “Monaco”: 20000 units per month.
Three definitions of capacity are used as DCP Capacity Information:

! The “Contracted Capacity” is specific for every customer and does not change until
purchasing changes the contract. Optionally the “flexibility” might be specified in
purchasing contracts.
! The “Available Capacity” (synonyms: declared capacity, installed c., planned c.,
actual c., production c., best can do c., resource based c.) can be expressed as
a) total capacity, i.e. across all customers and also as
b) customer specific capacity.
It can be entered by the supplier (e.g. logistics planner) at any time for any period of
time without contractual effects. The available capacity may also include free
capacity not currently allocated. The available capacity should be set equal to the
contracted capacity (default value) if the available capacity is not entered
specifically.
! The “Incremental Capacity” shows the contribution (quantity) and lead time of extra
measures to increase/decrease the actual available capacity. Typical operational
measures may be overtime, additional shifts, etc. Typical commercial measures: are
investments in additional tooling, production lines, etc. The incremental capacity
may also include free capacity not currently allocated.
A key-point in DCP is the definition of the available capacity that will be used as the
main reference in the system.
Page: 13 / 37
demand
available capacity
Q supplier offers potential increase incremental capac
capacity
∆Q incr. cap. 2
already agreed/planned
∆Q incremental capacity 1
capacity adjustment
lead time for capacity increment 1

lead time for capacity increment 2
0 10 20 30 40 [t]
Picture 3-3: Available Capacity and Incremental Capacity
Depending on the level of collaboration required between the customer and the
supplier, available capacity can be determined as:
! Contracted capacity and flexibility, based on contract
! Feasibility or best-can-do capacity, based on detailed production planning (usually
ERP-based)
! Resource-based capacity, usually derived from current and/or future bottleneck
resources (manually or extracted from ERP system)
To handle resource based capacity information in DCP, the structure of a capacity

model needs to be set-up. For every relevant (bottleneck) resource (e.g. assembly line,
final testing) the maximal available units per time interval (e.g. parts per week, hours
per month) needs to be evaluated. This defines the “capacity constraints”.
The capacity model is defining the mapping structure linking the “items” with the
“resources”. (see Picture 3-4: Example for Capacity Model for Resource based
Capacity Information)
Only a very limited number of bottleneck resources (usually 1 or 2 per product type)
determine the capacity in terms of products. As a consequence, rather simple capacity
models allow a sufficient level of accuracy in DCP. This keeps the complexity low and
the focus on the relevant issues.
Page: 14 / 37
Electronic
Control
Unit (ECU) Rain Sensor
Type A B C 1 2
Items
x1 x1 x1
coefficient for
resource usage x2 = x3 =
Allocation of items 30 sec. 45 sec.
to resources C3 C5
Resources ⌧ ⌧
testing moulding
capacity constraint 620 hours / month
Example for a resource based capacity model:

! The capacity constraint (availability) of resource “moulding” per month is 620
hours.
! To produce 1 unit of “rain sensor Type 1”, x2 = 30 seconds of resource “moulding”
are consumed
! to produce 1 unit of “rain sensor Type 2”, x3 = 45 seconds of resource “moulding”
are consumed
Picture 3-4: Example for Capacity Model for Resource based Capacity
Information
Page: 15 / 37
3.1.3 Mapping of Demand and Capacity Information

The core issue is to understand and describe the relationship between demand and
capacity. (see example in picture below):

!! forecasts demand vs. capacity
!!
(quantities & dates) total capacity " (quantities & dates)
We have
Can you supply us ? "100 people,
"2 production lines,
•in April : 1000 navigation systems
"8000 material sets
•in May : 1200 navigation systems
"we can work 5 days in 2 shifts
This comparison requires a clear

MAPPING of demand & capacity
information
The picture below illustrates how the “demand view” and the “capacity/resource view” are
mapped in DCP:
! Every item is associated to one or several resources / capacity constraints
! For every item-resource link, the coefficient of resource usage has to be defined.
Customer 1 Customer 2
D
Car platform Y2 Car platform Y1
E
Customer defined Electronic Sensors M
grouping* Control
A
Unit Rain Distance
ECU N
(ECU) Sensor Sensor D
Demand Structure
x1 x1 x1 x1 x1 x1 x1 x1 x2 x3 x1 x1 x1 x2
MAPPING Demand/Resources x1 x1 x1
Coefficient for resource usage
Allocation of items to resources
Resources Structure ⌧C1 ⌧C2 C3 ⌧ C4 ⌧ C5 ⌧ C6 ⌧ C7 ⌧ C

ECU 1.1 ECU 1.2 testing lacquering moulding assembly machining A
ECU ECU P
Supplier defined Sensors A
Type 1 Type 2
grouping*, eg by plant C
or product type Europe I
T
Electronics Y
Supplier
Legend: * = optional Demand on item level ⌧ Resource Grouping
Picture 3-5: Building up the DCP Model - Linking Demand Structure with Capacity
Structure
Page: 16 / 37
The standard time period in DCP has to be defined by the supplier and agreed by
the customers.
Incoming demand and capacity information must be transformed into the agreed time
period.
Customer 1 Customer 2
D
E
Customer defined M
grouping* week month quarter A
12 1 2 3 123 72 3 4 8 3 N
D
Demand Time buckets
transformation
MAPPING time buckets

standard time interval
Coefficient for resource usage
transformation
Resources Time buckets ⌧C1 ⌧C2 C3 ⌧ C4 ⌧ C5 ⌧ C6 ⌧ C7 ⌧ C
A
123 P
A
C
week e.g. based on production calendar I
T
Supplier Y
Legend: * = optional Demand on item level Resource Grouping
Picture 3-6: Time Intervals in DCP ($ update)
Page: 17 / 37
3.2 Problem solving process (mono customer scenario)
DCP analyses regularly and automatically whether demand forecasts and capacity
plans are aligned. It checks whether
! the demand forecast coming from the customer side and
! the available capacity (actual and/or planned) coming from the supplier side
are balanced. The DCP application highlights the time periods with under and over
capacity.
In a mono-customer scenario, the solving process uses a two-stage approach:

• First stage : Supplier first looks for internal solutions to alert
o DCP will enable :
% Automatic suggestion of measures
% Validation process : suggested measures will propagate up to
the required approval level
o Alerts are only propagated to customer AFTER agreed reaction time for
supplier internal measures
• Second stage : If the internal adjustment measures are not sufficient to align
capacity and demand, customer and supplier should collaborate and agree on
further alignment measures, cost and time scales. In this case the customer
may adjust its demand forecast and/or the supplier may adjust its capacity..

!! forecasts demand vs. capacity
!!
(quantities & dates) total capacity " (quantities & dates)
Alert ? No
action
-15% ! Yes
internal counter Supplier
measures /
action plan "
Alert ? No !
action
-10% !! Yes
Customer Supplier
collaborative counter
measures /
" action plan "
Alert ? No !!
action Legend:
Yes
!! = back-end
-5% !!! system,
" = DCP-Screen
with custo-
mised view
Picture 3-7: DCP process with two stage approach
Page: 18 / 37
3.3 Problem solving process (multi-customer scenario)

In the multi customer scenario, a three stage process is used:
• First stage : the supplier has to define internal measures to align capacity and
consolidated demand.
• Second stage : the supplier splits + allocates the total capacity across the
customers
• Third stage : the supplier collaborates separately with each customer where
alerts exist
Customer 1 Supplier Supplier

!! forecasts !!
+ demand vs.
total capacity "
capacity
Customer 2 No
Alert ?
demand
!! forecasts action
Yes
(quantities & dates) Supplier
internal counter
measures /
action plan "
Alert ? No
action
Yes
Supplier collaborates split + allocate Supplier
separately with customer 2 proposed capaci-
ties to customers " Supplier takes a business
decision (confidential)
Customer 2 Supplier
measures / Supplier collaborates
" action plan " Legend:1
separately with customer
Supplier !! = back-end
Customer 1 system,
measures / " = DCP-Screen
" action plan " with custo-
mised view
Picture 3-8: DCP Basic process in the multi customer scenario
The Multi-Customer process is simply reiterations of the mono-customer process,

except that the supplier has to make a commercial decision to allocate capacity
between customers.
This commercial decision is made in an additional stage of the DCP approach and is
supplier internal and confidential.
This additional stage is applied only in case of multi-customer scenario.
This process reflects exactly what suppliers are doing without DCP.
Page: 19 / 37
Chap 4 Functionality
4. Functionality
This chapter describes the basic elements of DCP in detail.
The Power Point presentation related to Chapter 4 shows in details the content and
process related to the Alerts & Measures Board. The following part of the
recommendation is only a brief abstract of the main functionalities described in the
document.
4.1 Introduction to the Alerts & Measures board (collaborative view)
General overview of the Alerts & Measures Board (Collaborative view)
The DCP process is managed in separate views of the Alerts & Measures Board:
• The supplier internal consolidated view (will be described later in this chapter)
• The collaborative view shared by the customer and the supplier
The Alerts & Measures Board consists of three main areas:

! Demand from the customer(s), and capacity (available capacity + contracted
capacity) from the supplier
! A collaborative area in which issues regarding demand and capacity alignment
are to be solved and decisions made
! A list of proposals of capacity adjustment measures to be used in the collaborative
area
Parameters
The parameters to consider are:

! under the responsibility of the supplier, but to be approved by the customer
" Time period (e.g. month)
" Number of periods to display
" Units (e.g. press unit working hours, kg of raw materials, volume unit, …)
! set collaboratively by the customer and the supplier
" Alert threshold: allows filtering to focus only on the main problems.
Presentation of the Alerts & Measures Board
The Power Point presentation related to Chapter 4 describes in details the various
parts of the Alerts & Measures Board.
Page: 20 / 37
Parameters
Press Working Hour Alert thresholds -10% 0% +5%
Unit
(% of demand)
Time period Month

Month Horizon (period) 9
Demand and capacity overview Time period

P1 P2 P3 P4 P5 P6 P7 P8 P9
Updated: 02/07/2003 Demand (input) 400 480 550 450 400 500 650 700 900
Updated: 05/07/2003 Available Capacity (input) 500 450 480 500 500 500 500 500 500
Available Capacity - Demand 100 -30 -70 50 100 0 -150 -200 -400
Updated: 05/01/2003 Contracted Capacity 600 600 600 600 600 600 600 600 600
Collaborative problem solving area

Proposed Solutions
Date Impl. Supplier Customer Supplier Customer
Cost Priority Rule Solution P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P++ Valid
(decision) Time approval approval removal removal
P-1 1 yes yes yes yes 0 3 2 10% (on avail. capa) Overtime, NOT charged 30 1
P-1 1 approve 3 = approve approve 3 = approve € 5 2 10% (on avail. capa) Overtime, charged 22 0
P-3 6 approve 4 = approve approve 4 = approve €€ 6 3 Add one shift 250 250 250 250 0
P-3 6 approve 4 = approve approve 4 = approve €€ 6 3 Add one shift 250 250 0
P-5 ∞ approve 5 = approve approve 5 = approve €€€ 7 4 Invest in new machine 200 200 200 0
P-x x yes yes approve approve 0 - - Disregard alert on month "x" ALERT 1
Incremental capacity (total: approved and not approved actions) 100 0 0 50 100 0 200 ALERT 390
Incremental capacity (approved actions only) 100 0 -22 50 100 0 -100 ALERT -400
Alert situation (confirmed actions only) 25% 0% -4% 11% 25% 0% -15% -44%
List of general Capacity Adjustment Measures BY SUPPLIER

Potential incremental capacity
Cost Priority Rule Solution P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P++ Insert
P-1 1 yes yes yes yes 0 3 2 10% (on avail. capa) Overtime, NOT charged 50 &
P-1 1 approve 3 = approve approve 3 = approve € 5 2 10% (on avail. capa) Overtime, charged 50 &
P-3 6 approve 4 = approve approve 4 = approve €€ 6 3 Add one shift 250 250 250 &
P-5 ∞ approve 5 = approve approve 5 = approve €€€ 7 4 Invest in new machine 200 200 200 &
P-6 ∞ approve 6 = approve approve 6 = approve €€€€ 8 4 Invest in new line 500 500 500 &
P-3 4 approve 7 = approve approve 7 = approve €€ - 3 Remove one shift -250 -250 -250 &
Adjustment Measures BY CUSTOMER

P-x x yes yes approve approve 0 - - Disregard alert on month "x" TBD TBD TBD TBD TBD TBD TBD TBD ALERT &
P-x x yes yes approve approve 0 - - Demand adjustment for month "x" TBD TBD TBD TBD TBD TBD TBD TBD VALUE &
Picture 4-1: Alerts & Measures Board (Collaborative view)
Basic requirements for the Alerts & Measures Board
! For a capacity constraint, both demand and capacity need to be expressed in the
same unit for the same time period and horizon. (see Chap 3.1-Initialisation)
! A regular update of demand and capacity information
! A list of capacity adjustment measures, agreed in advance if possible, so that
actions can then be suggested by the DCP ‘suggestion algorithm’
Page: 21 / 37
The general process is as follows:
Initialisation phase
Demand and capacity

List of general Demand and Capacity
overview
Capacity Adjustment
Measures
Pre-defined Automatic 'suggestion Problem solving area
measures/actions algorithm' $ Suggestions
Approval of actions
Problem solving area
(automatic approval,
manual approval, removal)
Picture 4-2: General process for Collaborative view
4.2 Functionalities of the Alerts & Measures board (collaborative view):

Automatic ‘suggestion algorithm’ to solve problems in the demand and capacity
alignment
In order to facilitate the decision-making process, some options shall be calculated in a

simple automatic way when data are updated.
Key point : the suggestion algorithm has to be very simple in order to be easily
understood by both partners.
The calculation process could be based on:
! Minimum lead-time before implementation of the pre-defined measures

! Priority rules of the pre-defined measures
! Etc…
The Power Point presentation related to Chapter 4 describes a proposal for the
calculation process.
Validation process
After the calculation process is performed, both partners have to validate the measures
they wish to take to solve the issues. To do so, they can either agree or reject each
suggested measure.
Note : some measures selected by the automatic calculation could be pre-approved.
Page: 22 / 37
Supplier and customer can also add or remove manually, if necessary, some measures
in the Collaborative problem solving area. This is especially important when, for
instance, a measure previously approved is no longer needed because of a decrease
in the demand
Approval is based on a simple workflow system based on authority levels. Each

partner allocates a single decider to each level.
Impacts of a demand update in the Collaborative view
Only the approved actions should remain on the Alerts & Measures board from one
period to the next .
Demand t
Capacity and demand Data
relationships
Data adjustment
based on
Pre-defined Automatic 'suggestion experience
Approval of actions
Only
Demand t+1 approved
actions
Same actions as Capacity and demand
previously + new actions
based on experience
Pre-defined Automatic 'suggestion

Approval of actions
Picture 4-3: General process with a demand update
DCP Dashboard
The DCP Dashboard is a common user interface that includes all the Alerts &
Measures Boards (Collaborative view) for the capacity constraints managed in the DCP
tool.
It reflects the same information from a customer or a supplier point of view.
(See Picture 4-4: DCP Dashboard overview)
Page: 23 / 37
Distance ⌧ Machining x2
Parameters
Unit Press Working Hour Alert thresholds -10% 0% +5%
Sensor (% of demand)
Time period Month

⌧ Machining x2 Demand and capacity overview Time period
Sensors ⌧ Assembly x1 Updated: 02/07/2003 Demand (input)

P1
400 480
P2 P3
550
P4
450
P5
400
P6
500
P7
650
P8
700
P9
900
⌧
Assembly x1 Updated: 05/01/2003 Contracted Capacity 600 600 600 600 600 600 600 600 600
Car ⌧ Moulding x1 Collaborative problem solving area

Proposed Solutions
platform
Rain
⌧
Y1 Assembly x1 (decision) Time approval approval removal removal
Sensor 2 10% (on avail. capa) Overtime, NOT charged

⌧
P-1 1 yes yes yes yes 0 3 30 1
Moulding x1 P-1 1 yes yes yes yes 0 3 2 10% (on avail. capa) Overtime, NOT charged 48 1
Car Selection of a capacity 2 10% (on avail. capa) Overtime, charged
⌧
P-1 1 approve 3 = approve approve 3 = approve € 5 22 0
Lacquering x3 P-1 1 yes yes yes yes 0 3 2 10% (on avail. capa) Overtime, NOT charged 50 1
platform constraint/resource
Y2
? ⌧ Lacquering x2 P-1
P-1
1
1
yes
approve
yes
3 = approve
yes
approve
yes 0
3 = approve €
3
5
2 10% (on avail. capa) Overtime, NOT charged
2 10% (on avail. capa) Overtime, charged
50
50
1
0
Electronic ⌧ !! Testing x1
Incremental capacity (total: approved and not approved actions) 100 0 0 50 100 0 200 50 200
Control Incremental capacity (approved actions only) 100 0 -22 50 100 0 -100 -200 -350
⌧ !!
Alert situation (confirmed actions only) 25% 0% -4% 11% 25% 0% -15% -29% -39%
Unit (ECU) Testing x1
List of general Capacity Adjustment Measures BY SUPPLIER
!! ⌧ !! Testing x1 Date Impl. Supplier Customer Supplier Customer

⌧ ECU 1.2 x1 P-1
P-3
1
6
approve 3 = approve approve 3 = approve €
approve 4 = approve approve 4 = approve €€
5
6
2 10% (on avail. capa) Overtime, charged
3 Add one shift
50
250 250 250
&
&
P-5 ∞ approve 5 = approve approve 5 = approve €€€ 7 4 Invest in new machine 200 200 200 &
Adjustment Measures BY CUSTOMER

P-x x yes yes approve approve 0 - - Disregard alert on month "x" TBD TBD TBD TBD TBD TBD TBD TBD TBD ALERT &
P-x x yes yes approve approve 0 - - Demand adjustment for month "x" TBD TBD TBD TBD TBD TBD TBD TBD TBD VALUE &
(customer view)
Machining Parameters
-10% 0% +5%
Press Working Hour Alert thresholds
⌧
Unit
(% of demand)
C7
Sensors Time period Month
⌧
Demand and capacity overview Time period

Assembly C6 Updated: 02/07/2003 Demand (input)
P1
400 480
P2 P3
550
P4
450
P5
400
P6
500
P7
650
P8
700
P9
900
⌧
? Updated: 05/01/2003 Contracted Capacity 600 600 600 600 600 600 600 600 600
Moulding
Europe C5 Collaborative problem solving area
Proposed Solutions
Lacquering C4
⌧
!! Selection of a capacity
Electronics constraint/resource
ECU
Incremental capacity (total: approved and not approved actions) 100 0 0 50 100 0 200 50 200
Type 2 Incremental capacity (approved actions only) 100 0 -22 50 100 0 -100 -200 -350
!!
⌧
Alert situation (confirmed actions only) 25% 0% -4% 11% 25% 0% -15% -29% -39%
Testing
C3 List of general Capacity Adjustment Measures BY SUPPLIER
P-1 1 approve 3 = approve approve 3 = approve € 5 2 10% (on avail. capa) Overtime, charged 50 &
P-3 6 approve 4 = approve approve 4 = approve €€ 6 3 Add one shift 250 250 250 &
ECU 1.2 C2 P-5 ∞ approve 5 = approve approve 5 = approve €€€ 7 4 Invest in new machine 200 200 200 &
⌧
Asia Adjustment Measures BY CUSTOMER

ECU Date Impl. Supplier Customer Supplier Customer
Type 1 C1 (decision) Time approval approval removal removal
P-x x yes yes approve approve 0 - - Disregard alert on month "x" TBD TBD TBD TBD TBD TBD TBD TBD TBD ALERT &
⌧
P-x x yes yes approve approve 0 - - Demand adjustment for month "x" TBD TBD TBD TBD TBD TBD TBD TBD TBD VALUE &
ECU 1.1
(supplier view)
Picture 4-4: DCP Dashboard overview
Page: 24 / 37
DCP Dashboard also allows the definition of roles and responsibilities for the
workflow process. This process should be kept as simple as possible as quick
reaction is necessary.
Each capacity constraint is allocated to an ‘approver’ who is responsible for decisions
at that level.
‘Approvers’ linked to upper nodes should be included in the work flow process. In
order to reduce the workflow loop and have a reactive process, these people should
take responsibility for decisions even if approval is required from other departments,
Distance ⌧ Machining x2 ‘Approvers’ linked to upper nodes should be included in the

Sensor work flow process.
⌧ Machining x2 In order to avoid a workflow loop and have a reactive

process, these people should take responsibility for
Sensors ⌧ Assembly x1
decisions even if approval is required from other
⌧ Assembly x1 departments,
Car ⌧ Moulding x1
platform
Rain
Y1
Sensor ⌧ Assembly x1
Car
⌧ Moulding x1
platform ⌧ Lacquering x3
Y2
? ⌧ Lacquering x2
Electronic ⌧ !! Testing x1
Control
Unit (ECU) ⌧ !! Testing x1
!! ⌧ !! Testing x1
⌧ ECU 1.2 x1
Picture 4-5 Roles and responsibilities for the Approval process through the DCP
Dashboard
The Power Point presentation related to Chapter 4 provides a description of the DCP
Dashboard.
Page: 25 / 37
4.3 Internal Supplier view

The Internal Supplier view is exclusive to the supplier and allows him/her to compare
the demand from the customer(s) to the available capacity from its back-end system
and to take internal actions before data is published in the Collaborative view.
The design of the view and the rules for the internal 'suggestion algorithm' should be
similar to the Collaborative view, but with no approval process from customer side.
List of Internal Demand and Capacity (from Demand and

Capacity Adjustment back end systems) capacity overview
Measures
SUPPLIER
Pre-defined Automatic 'suggestion algorithm' Internal problem
INTERNAL
VIEW
measures $ Suggestions solving area
Approval of measures (automatic

approval, manual approval, Internal problem
removal) solving area
List of Collaborative Demand and Capacity (from Demand and

Capacity Adjustment Supplier Internal view) capacity overview
Measures
Pre-defined Automatic 'suggestion algorithm' Collaborative
measures $ Suggestions problem solving area

approval, manual approval, Collaborative
removal) problem solving area
Picture 4-6: General process including the Supplier Internal view
Page: 26 / 37
4.4 Multi-customer approach

In the multi-customer scenario, the Supplier Internal view allows the supplier to:
! consolidate the demand from all the customers
! compare consolidated demand to the available capacity (from the back-end
system)
! decide on internal actions
! and split the resulting capacity (available and incremental from the internal
actions) to each customer
From the collaborative point of view, the multi-customer scenario will (changer partout
(see JPC)) be translated into several mono-customer situations. The Power Point
presentation related to Chapter 4 describes the various steps in this process.
List of Internal Demand and Capacity (from Demand and

Capacity Adjustment back end systems) capacity overview
Measures
SUPPLIER
Pre-defined Automatic 'suggestion algorithm' Internal problem
INTERNAL
VIEW
measures $ Suggestions solving area

approval, manual approval, Internal problem
removal) solving area
Demand and Capacity Demand and Capacity

List of Collaborative Demand and List of Collaborative
Capacity (from Supplier Internal (from Supplier Internal Demand and
capacity Capacity
Adjustment view) Adjustment view) capacity
Measures overview Measures overview
Pre-defined Automatic 'suggestion Collaborative Pre-defined Automatic 'suggestion Collaborative
measures algorithm' $ Suggestions problem solving measures algorithm' $ Suggestions problem solving
area area
Approval of measures Approval of measures
(automatic approval, manual Collaborative Collaborative
problem solving (automatic approval, manual
approval, removal) approval, removal) problem solving
area area
COLLABORATIVE VIEW – CUSTOMER 1 COLLABORATIVE VIEW – CUSTOMER 2
Picture 4-7: General process including the Supplier Internal view in the multi-
customer scenario
Page: 27 / 37
4.5 Additional functionalities
This section describes some optional functionality:

! DCP Dashboard and Alerts & Measures Board
" Creation of a simulation environment for internal analysis (in which it would be
possible to modify demand, …)
" Possibility to define an alert threshold or an internal filter for period ranges
instead of the entire horizon (e.g. -5% on the first 3 months, then -10% on the
rest of the horizon)
" Definition of an alert threshold for a group of capacity constraints that would
apply for all the related Alerts & Measures Boards
" …
! Data query
' e.g. a list of capacity constraints with red alerts
' e.g. a list of all capacity constraints with red alerts ON periods between 1 and 3
' e.g. a list of all capacity constraints with “decision date” (yellow boxes) in month 1
AND “action validated by both partners”
' …
Page: 28 / 37
Chap 5 Responsibilities
5. Responsibilities
5.1 Functions Involved

The main business functions involved in the DCP process include commercial functions such
as Purchasing (customer side) and Sales (supplier side) and operational functions such as
Procurement (customer side) and Production Planning (supplier side).The level of
involvement in the process, however, of these different functions can vary according to the
planning horizon involved.
NB: In larger organisations there may be a dedicated Capacity Management function.
5.1.1 Medium Term DCP

In the case of medium term DCP (e.g. horizon up to 12 months) the customer
procurement function is likely to be more deeply involved in managing the day to
day process than the customer purchasing function.
On the supplier side, the production planning function is likely to be more deeply
involved in managing the day to day process than the sales function.
Even in medium term DCP, however, the commercial functions on both sides will
quickly become involved if actions to align capacity and demand have significant
financial consequences for either of the partners.
5.1.2 Long Term DCP

In the case of long term DCP (e.g. horizon 1 – 5 years) the commercial functions are
more likely to be involved than the operational functions.
Long term DCP depends much more on business forecasts and strategic plans than
on actual production plans.
5.2 Elements for which responsibility must be taken
5.2.1 Data
5.2.1.1 Demand Data
This is the responsibility of the customer and should be:
! in line with the definition in this DCP recommendation
! adjusted to supplier business allocation
! detailed at the lowest practical level (part number, if possible)
! able to be consolidated in different ways (users/usages)
! given with an adequate horizon
! regularly updated
5.2.1.2 Capacity Data

This is the responsibility of the supplier and should be:
! In line with the definitions in this DCP recommendation
! Adjusted to customer allocation
Page: 29 / 37
Chap 5 Responsibilities
! Able to be matched to demand detail and/or demand consolidation

! Regularly updated
5.2.2 Parameters
The operation of an effective DCP tool depends upon the setting of several parameters.
Some of these parameters can be set by the supplier and the customer independently whilst
others must be agreed collaboratively.
5.2.2.1 Set by supplier independently

! Internal alert thresholds
! Pre-defined measures
! Rules associated with pre-defined measures
5.2.2.2 Set by customer independently

! Pre-defined measures
! Rules associated with pre-defined measures
5.2.2.3 Set collaboratively

! Time buckets for demand/capacity comparison
! Capacity units
! Collaborative alert thresholds
! Reaction time
5.2.3 Customer/supplier interface

Specific contacts with appropriate decision making authority at different hierarchical levels
must be nominated on both sides.
The workflow and escalation rules must be agreed between the partners as well as the
expected reaction times for different levels of alert.
Functional and technical pilots for the DCP application should also be nominated as well as a
Level 1 helpdesk.
Page: 30 / 37
Chap 6 Data Description
6. Data Description
This recommendation is too high level to define all data elements necessary to support all
DCP functionnalities.
It is assumed that the developers of DCP solutions will build a comprehensive data model.
DCP deals with 3 categories of data:

! DCP-internal data
! Information flow between DCP and backend systems
! Information flow between interoperating DCP instances .:
Picture 6-1 bellow illustrates the information flow in a decentralised architecture. Further
information regarding interoperability can be found in chapter 7.
Legend:
!! = back-end system,
" = DCP-Screen
DCP
information flow
level DCP
back-end
systems " " " "
level
!!! !!! !!! !!!
material flow
Supplier A Supplier B Customer 1 Customer 2
Picture 6-1: Basic Information Flow in DCP
Page: 31 / 37
Chap 7 Technical Aspects
7. Technical Aspects
7.1 Architecture of DCP Solutions

In order to achieve integration between customers and suppliers and to enable seamless
collaboration, a DCP layer is introduced in addition to today’s systems and processes
(see picture below). This DCP layer can be seen as an add-on to existing ERP-systems.
Different IT concepts are possible to support DCP.
As demonstrated by existing DCP solutions, the DCP functionality and processes can be
supported by a specialised central application.
Another option is to utilise specialised interoperable, decentralised and disparate,
applications.
A third alternative is to have the functionality supported by a decentralised interoperable
application as part of a company’s internal back-end system. Even a mix of concepts will
be compliant with this recommendation.
DCP
collaboration
DCP
private data
C1 area S1 area C2 area S2 area
" " " "

back-end
systems
!! !! !! !!
layer
Customer Supplier Customer Supplier
1 1 2 2
Legend: !! = back-end system, " = DCP-Screen with customised view
7.2 Interoperability
A good example for existing interoperability is mobile telecommunications:
! We, as the users, select one telephone model (e.g. from Nokia, Sony, Alcatel) and
one service provider (e.g. Vodafone, Deutsche Telecom, Orange), that fits best to
our individual profile/requirements.
! Our service provider interoperates with the other service providers and builds up a
direct connection to every external conversational partner we want to talk to. The
basis for the interoperability between the service providers are international
standards (e.g. GSM for mobile phones).
! As a user we do not have to care what telephone model and what software release
our conversational partner has. Nor do we need to know his service provider to talk
to him, to send him a text message or to leave a voice message.
Page: 32 / 37
! With one telephone and one service provider we are connected to everybody. We
only need to know the correct telephone numbers.
Another example is the World Wide Web:
! Servers from any brand, using any operating system (NT, XP, UNIX…) are
interconnected, and can be added/removed without notice.
! Messages are travelling in this network without any central co-ordination platform.
! Nobody has any control of this network, but everybody can enjoy the advantages of
easy, robust and cheap communications.
The Odette SCM Group is convinced that Interoperability is the only feasible way to
implement SCM concepts on a broad basis in the automotive industry. The
reasons for this opinion and our proposed solution to the problem are described below.
Many B2B concept types like Demand Capacity Planning , Supply Chain Monitoring,
Vendor Managed Inventory, eRFQ, etc. have been created and introduced in the past
couple of years, and every day new solutions are added. As a consequence,
customers, marketplaces, suppliers, logistics providers, etc. which have developed and
implemented those B2B solutions require their relevant business partners to connect to
their solutions.
As illustrated in Picture 7-1 below, a single company (“Company X”) has two way to
comply with the request to use a business partner’s DCP solution:
! Option 1: Company X integrates its own backend systems with the DCP solution
of the respective business partner
" own backend integration (1:1 connection) for every individual solution
" poor cost/benefit ratio due to limited number of transactions and high one-off
investment
! Option 2: Company X may use a browser access
" user needs to log-in, check the situation and effect transactions / key in data in
the application (1:1 connection)
" inefficient due to high manual effort in day-to-day business..
companies that
Business Business Business Business initiate a B2B
Partner A Partner B Partner C Partner D solution integrate
!! !! !! !! their backend
systems once
" " " "

Option 1:
ss ss s s
Company X will inte- ce ce ce
ro ro ro
grate own back end lp lp lp
ua ua ua
system with B2B-SCM an an an
m m m
solution of Business
Partner A
Option 2:
poor cost/benefit user needs to log-in, check situation and effect
ratio due to limited !! transactions /key in data in the solutions of
number of transactions Business Partners B, C and D (browser
access)
Company X
inefficient due to high manual
effort in day to day business
!! = Backend System (e.g. ERP), " = B2B solution
Picture 7-1: Scenario without Interoperability
Page: 33 / 37
The number of relevant business partners (customers, marketplaces, suppliers, logistic

providers, etc.) can be very large. In such cases it is likely that the cost to build up
and/or to maintain the many 1:1 connections will exceed the benefits of the new
concepts. As a consequence, Company X may refuse to participate and the initiator of
the B2B solution will not achieve the goal to integrate Company X in this inter company
business process and functionality.
In order to overcome the problem of an immense number of expensive 1:1

connections, we propose an interoperability concept based on a decentralised
architecture as shown in Picture 6-1.
Every organisational unit (e.g. Company X) selects and installs one interoperable
DCP application. Company X may choose a lean low-cost solution or a solution with
advanced backend integration features and user management functionality according
to their own needs and preferences. The application can be hosted internally or
externally (e.g. company portal, marketplace or ASP).
Company X’s DCP application (“instance”) is linked to the company’s back-end
systems (legacy, ERP, etc.). As stated above, the back-end systems remain the
leading systems for capacity information and parameters.
After a status change in the-back end system (e.g. a change in cycle time that affects
capacity) the company’s own DCP instance is updated via the EAI information flow.
To inform the relevant business partners about the new status, the interoperability
information flow is used to update (synchronise) the adjacent DCP instances. The
DCP instances of the different organisational units communicate via the Internet, ENX,
ANX or other appropriate networks.
Picture 7-2 shows the benefits of the proposed concept:

! Company X selects (and pays for) one interoperable application that best fulfils their
needs best
! Company X invests only once in backend integration and will be linked to all
business partners
! highly automated business process and fast and reliable data flow with all
business partners
! full B2B functionality
Page: 34 / 37
companies that
Business Business Business Business initiate a B2B
Partner A Partner B Partner C Partner D solution integrate
!! !! !! !! their backend
systems once (no
change)
" " " " B2B-SCM instances
interoperate
(based on respective
Odette Interoperability
" Recommendation)
company X
!! Interoperability is an efficient way to achieve
integrates its " full end-to-end integration (fast and
own backend
Company X reliable data flow) and
systems once
" full B2B functionality and business
process
!! = Backend System (e.g. ERP), " = B2B instance e.g. for SCMo or VMI
Picture 7-2: Scenario with Interoperability
A separate project group will develop the necessary elements to realise interoperability
for B2B applications. The basis is likely be a general recursive interoperability
approach with three major objects as deliverables:
! a general Supply Chain Recursive Model (SCRM)
as a basis for mapping complex supply networks in decentralised IT applications
! a general Supply Chain Interoperability Protocol (SCIP)
where an interoperability message set is embedded in an XML protocol
! a general Supply Chain Interoperability Reference Architecture (SCIRA)
Based on this general approach, a specific DCP Interoperability Recommendation

will be developed at the appropriate time in the future. This will include the necessary
XML message body enveloped by the SCIP and taking advantage of the SC Reference
Architecture. The results will be validated in a proof of concept.
In the same way, specific Interoperability Recommendations for other concept types
(e.g. VMI, SCMo) will be developed.
Page: 35 / 37
7.3 Scalability and Technical Robustness

In addition to interoperability, other attributes of a successful DCP application are
scalability and technical robustness. The following is a summary of the points that
companies should consider in the selection of their DCP application. A Technical
Assessment document will be made available through Odette to provide more detailed
help for companies selecting a solution. The following are the key areas that will be
explained in greater detail in the Technical Assessment document.
! Volumes
The capability of DCP solutions to scale easily is critical as supply networks come in
a variety of forms with wide ranges of user numbers, transaction volumes and other
dynamics that vary from situation to situation. Points that need to be considered are:
" Data storage
" Data access
" Data volatility
" Batch transactions
" On-line transactions
" Data transfer volumes
" Keying redundancy
" User volumes
" Ease of use
! Deployment
To be responsive to DCP issues, potential solutions must be capable of rapid
deployment, with minimal technical support and with minimal technical resistance
from the parties involved. Points that need to be considered are:
" Interoperability with other DCP and associated solutions
" Ease of integration with back office systems
" Central server versus distributed server models
" Thin-client versus thick-client models
! Other considerations
There are other technical issues that should also be considered to ensure that the
DCP solution is capable of supporting the process in a robust way. Points that need
to be considered are:
" Data integrity
" Commitment control and data roll-back
" Mirroring and replication
" Infrastructure resilience and redundancy
" Technical support
" Solution development plan
Page: 36 / 37
Supply Chain Monitoring V1.0
Chap 8 Appendix
8. Appendix
8.1 Presentations (e.g. for training purposes)

! Work Package 2
! Work Package 3
! Work Package 4
! Xls Proof Of Concept
8.2 Change Request procedure

For any Change Request, please use the Odette Change Request form available on the
Odette web site: www.odette.org, in the “Members only” section or on the Odette CD-ROM,
and e-mail it to the Odette Central Office at odette@odette.org.
Page: 37 / 37

7. LA01_DCP_2021-03-10-133708

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7. LA01_DCP_2021-03-10-133708

Uploaded by

Copyright:

Available Formats

An Odette Publication

Demand Capacity Planning

Ref LA01 Version 1.1 Published April 2004

OEMs Suppliers Organisations

Overview - How to use the Recommendation

Chapter 1, Philosophy of Supply Chain Management, describes the foundation of modern

For readers with an IT background, we advise to read chapters 2, 3, 6 and 7 first. To go

1. Philosophy of Supply Chain Management ................................................... 5

1. Philosophy of Supply Chain Management

The scope of DCP, as described in this recommendation, focuses on the medium/long

Call-offs, VMI, Kanban DCP DCP

days months years [time]

operations production sales / purchasing,

Picture 2-1: Positioning of DCP

The Odette Recommendation proposes an integrated approach with collaborative

Integrated DCP has clear benefits for customers and suppliers:

The general principles of integrated DCP are:

The basic DCP process, as detailed in the next paragraphs is :

! Early warning system :

“Normal” Demand Volatility Serious Demand / Capacity

no alert in DCP alert in DCP

! Alert resolution : using a Two-Stage approach to problem solving

Customer Supplier Supplier

capacity Additional assembly line

reaction time (time for decision taking, planning, implementation of measure)

Picture 2-3: Process to define measures to resolve alerts

! Architecture : Layer concept

" " " "

Legend: !! = back-end system, " = DCP-Screen with customised view

Picture 2-4 : Architecture with Layer concept

collaboration area Supplier 1

private data holding

Picture 2-5 : Collaboration and private Data Holding

3. Business Process Description

3.1.1 Demand Information

! Demand at part number level

! Demand at product type level

! Demand at feature/option/car model/powertrain level

rain rain distance distance

part number / description

Picture 3-1 : Demand at Product Type Level

Multi sourcing quotas

100 100 150 150

Supplier(s) must have the ability to enter (manually or automatically) additional

3.1.2 Capacity Information

Three definitions of capacity are used as DCP Capacity Information:

lead time for capacity increment 1

Picture 3-3: Available Capacity and Incremental Capacity

To handle resource based capacity information in DCP, the structure of a capacity

Example for a resource based capacity model:

3.1.3 Mapping of Demand and Capacity Information

Customer Supplier Supplier

This comparison requires a clear

Resources Structure ⌧C1 ⌧C2 C3 ⌧ C4 ⌧ C5 ⌧ C6 ⌧ C7 ⌧ C

Legend: * = optional Demand on item level ⌧ Resource Grouping

MAPPING time buckets

Legend: * = optional Demand on item level Resource Grouping

Picture 3-6: Time Intervals in DCP ($ update)

3.2 Problem solving process (mono customer scenario)

In a mono-customer scenario, the solving process uses a two-stage approach:

Customer Supplier Supplier

3.3 Problem solving process (multi-customer scenario)

Customer 1 Supplier Supplier

Picture 3-8: DCP Basic process in the multi customer scenario