Leading firms realize that to maximimize the value of their customer and product portfolios, it is essential to understand the value created by each portfolio member. Cost-to-serve analytics and reporting is the means to accomplish this, eliminating expensive, departmental ad hoc efforts and creating a single source for all channel, product and customer profitability and analytics. This white paper details how to implement an institutionalized solution using a layered, separation of concerns architectural approach to ensure that your cost-to-serve solution is robust, maintainable, reusable and adaptable.
Cost to Serve Methodology: An Architectural Approach
1. QUAN TALYS T
C O N S U L T I N G, LLC
CostͲtoͲServe Methodology
An Architectural Approach
A single source for granular channel, customer & product
profitability analytics and reporting
Dean D. Baker, Director
Quantalyst Consulting, LLC
1223 Wilshire Blvd., #282
Santa Monica, CA 90403
September 2012 rv1.03
213.401.1286 May 2012 rv1.02
dbaker@quantalyst.com November 2011 rv1.01
www.quantalyst.com April 2011 Published
2. www.quantalyst.com
CostͲtoͲServe Methodology – An Architectural Approach
Table of Contents
Executive Summary ................................................................................................................................. 2
Payback.......................................................................................................................................................... 3
The multiͲdimensional nature of costͲtoͲserve models............................................................................. 4
Additional benefits of dimensionality ........................................................................................................... 4
Resolving Confusion with the term “Dimension” ......................................................................................................................... 4
Defining Dimensions......................................................................................................................................5
Architectural Overview ............................................................................................................................ 6
Figure I – Calculation Engine and the Agnostic Data Structure ................................................................................................ 6
Separation of Concerns Benefit..................................................................................................................... 7
Additional Benefits of Architectural Approach.............................................................................................. 7
AuditͲability to Source Costs ......................................................................................................................... 7
Detail discussion of architecture .............................................................................................................. 8
Data ETL......................................................................................................................................................... 8
The Power of User Maintained Rules ......................................................................................................................... 8
Data Sources ...............................................................................................................................................................9
Figure II – Common Data Sources............................................................................................................................................ 9
The Issue of Stability ...................................................................................................................................................9
Statistics development .............................................................................................................................................10
Source Data Stability .................................................................................................................................................................. 10
Figure III – Cost Drivers Dimensional Populations ................................................................................................................. 11
Figure IV – Activity Assignment Example (Order Entry) ......................................................................................................... 12
Load of Calculation Engine........................................................................................................................................12
Calculate (empty engine)............................................................................................................................. 12
Maintain static rules .................................................................................................................................................13
Validation and Model Integrity .................................................................................................................................13
User controls.............................................................................................................................................................13
What if analysis.........................................................................................................................................................13
Essential Control Files & Stability ............................................................................................................................................... 13
Various other reporting ............................................................................................................................................14
Report..........................................................................................................................................................14
Integral Integration...................................................................................................................................................14
View Integration .......................................................................................................................................................14
StandͲalone...............................................................................................................................................................14
Conclusion............................................................................................................................................. 15
Document revision history ..................................................................................................................... 16
3. www.quantalyst.com
Executive Summary
Leading firms realize that to maximize the performance of their customer and product portfolios, it is
essential to understand the value generated by each portfolio member. CostͲtoͲserve (CTS) is the term that
is used to indicate the resources of the firm that are consumed serving particular products and services to
specific customers. It is safe to say that all firms understand their total costs, while it is the unusual firm
that understands its granular CTS.
What prevents access to this information is that the complexity in providing it is much more than is initially
apparent. There are several sources of this complexity, these include:
1. Solving the multiͲdimensional nature of the CTS solution.
2. Developing the transactional statistics that enable the calculation of costs at the granular level.
3. Providing reporting for users that allow them to act on the results.
4. Institutionalizing the process to create ongoing value.
The resolution of these complexities is found in a comprehensive architectural approach to solving the need
for CTS reporting capability. This architectural approach is essential in that it avoids the tendency of firms
who are uninitiated in CTS implementations to focus on a “software solution”, leading to and expensive
surprise when they begin to understand the reality of the costs of implementation. By understanding this
architectural approach, one will avoid the unnecessary costs brought about by focusing on an incomplete,
or worse, unworkable software solution.
This paper documents such a bestͲpractices approach, and is the methodology that Quantalyst Consulting
has implemented in its CTS engagements. This approach has proven to result in an affordable
implementation that will:
1. Leverage existing investments in systems and people
2. Create an agnostic data structure that is independent of the choice of calculation software
3. Develop an institutionalized, maintainable process to capture ongoing value
4. Provide comprehensive auditͲability to the source costs
5. Implement a layered, separation of concerns approach that ensures the solution is:
a. Robust
b. Maintainable
c. Adaptable
d. Reusable
This technical document is structured as follows:
1. It explains where the payback is found in CTS implementations.
2. It defines the multiͲdimensional nature of CTS models including how to define the dimensions.
3. It provides an overview and benefit summary of the layered architectural approach.
4. It continues with a detailed discussion of each layer within the architectural approach.
Page 2 CostͲToͲServe Methodology – An Architectural Approach
4. www.quantalyst.com
Payback
The increasing implementations of CTS reporting and analytics had been driven by two primary factors:
1. The continued advance in access to and affordability of computing power in terms of both
hardware and software, and;
2. The rapid and identifiable payback of the implementations.
Payback is often times measured in months, and is achieved in the following areas1:
1. Tactical gains, including:
a. Transparency of the supply chain
b. SG&A expense management
c. Peer to peer profitability analysis
d. Single source for all channel, product and customer profitability reporting & analysis
2. Strategic gains, including:
a. Brand value
b. Customer relationship value
c. Channel value
d. New product introductions
e. Warehouse and store placements
3. Operational gains, including:
a. Systems discipline
b. Systems utilization
c. Systems weaknesses identified
d. Foundation for predictive intelligence
4. Predictive
a. Correlation analysis
b. Foundation for the incorporation of big data
1
For additional detail and specific examples as to where gains are seen, how to define and calculate the
gains across a firm’s portfolio contact info@quantalyst.com. Please include a reference to ‘CTS savings’ in
the email header.
CostͲToͲServe Methodology – An Architectural Approach Page 3
5. www.quantalyst.com
The multiͲdimensional nature of costͲtoͲserve models
CostͲtoͲserve requires a multiͲdimensional solution. All CTS models require at least two dimensions
(product and customer), while most are three dimensional. The usual dimensions are:
• The customer
• The product (also used to mean service)
• The channel
The reason for this multiͲdimensionality is that costs attach at different dimensions, and when they attach,
it is not known where those incurred costs will be consumed. A common example is the costs of
transportation of a product to a distribution center
(warehouse). When the transportation cost is incurred, we Resolving Confusion with the term
only know that it is a product cost (depending on the model “Dimension”
design, we may also know that it is a channel cost, for “Dimension” is an overused term that leads to
example, Product_ABC at Channel_Chicago). Until the much confusion. When this paper uses the term
product is served to a customer, we don’t know which “dimension” we are referencing calculation
customer(s) should bear the cost. In this example, the costs dimensions. These are the intersecting
for Product_ABC at Channel_Chicago will be intersected with dimensions that CTS activities (cost pools) are
assigned, and then calculated upon.
those customers served from the Chicago channel who
purchased Product_ABC.
There are three:
x Product
Similarly, there will be customer costs that are incurred x Customer
against a customer, before we know which products to x Channel
assign the cost. An example could be outside sales expenses
(sales calls), which can be identified to the customer – prior A best practice, separation of concerns approach
to knowing which products will be served to the customer. is “empty engine”, time is not a calculating
Eventually, when those products are known, the costs at the dimension. It is, however, a reporting dimension
customer will be intersected with the actual products served (also referred to as a descriptive dimension).
Descriptive dimensions are unlimited, and can
to that particular customer.
attach to the channel, product/service or
customer.
A note on dimensionality – be cautious of extending the
dimensionality beyond three. This will introduce an Additional confusion arises as OLAP reporting
unneeded level of complexity and can be a sign of poor (where the result set ultimately resides)
design architecture. terminology also uses the word “dimension”.
Additional benefits of dimensionality
Because the CTS model is multiͲdimensional, additional benefits are provided to business decision makers.
These include views of profitability that extend beyond the customer to include (usually) channel and sku
(product) profitability. These benefits enhance business strategy such as:
1. Sku rationalization decisions. Sku rationalization programs fail many times because the efforts are
attempted without fully quantified facts. Sku rationalization decisions have to be made with not
just product profitability, but in conjunction with the combined profitability associated with the
channel and customer.
2. Channel efficiency decisions. Having the facts to manage the channels through which you serve
particular customers are an important strategic input. It gives your marketing departments the
ability to guide customer behavior to the most advantageous channels in terms of profitability.
Page 4 CostͲToͲServe Methodology – An Architectural Approach
6. www.quantalyst.com
3. Supply chain efficiency. CTS modeling will create transparency in your supply chain in terms of the
costs of various supply decisions. Examples include the freight costs per unit of various shipping
alternatives and product staging decisions.
Defining Dimensions
The customer and the product dimensions are quite obvious, though some issues do arise in the definitions,
for example, is a customer a shipͲtoͲaddressID or a billingID? Are services products? For the most part, all
will readily agree upon what constitutes a customer and a product. If you have a delivery network, a
customer will probably be defined as a shipͲto addressID (each shipͲto consumes specific resources),
whereas in a mailͲorder house, a customer is usually defined as a billingID. And, yes, services are a distinct
product offering that is served to (consumed by) various customers.
The channel dimension can be more challenging, in part because bestͲpractices are to have consistency
across your model (to avoid unneeded complexity). Therefore, channel definitions should have global
connotations (meaning having the potential to apply to all products or customers). For example, a
marketing executive will think of customer types as channels (distributors vs. companyͲowned). Customer
types do not equate to channels, as the real question is, how are the customers served? If both the
distributors and the companyͲowned customers are served in the same manner, consuming the same
resources (order entry, warehouse, fulfillment, etc.), partitioning your customers into channels based upon
the manner in which they are segmented for marketing purposes does not assist in the costͲ toͲserve
analysis, and may create unneeded complexity. Other issues that arise in design decisions include confusing
channels with reporting requirements (partitioning by profit center) or using channel in an effort to manage
data proliferation by accumulating particular costs (assigning costs to a channel called ‘large customers’).
As you can see, defining proper channels in a CTS model is partially an art, and partially experience.
Channel definitions can make or break a CTS analysis. Following are some general rules to bear in mind:
1. Channels are global, meaning that they potentially apply to all products and all customers. For
example, a parts manufacturer may have OEM (original equipment manufacturer), aftermarket
and consumer channels. The same products may be served from any channel, and the same
customers may be served from multiple channels (a customer served both by OEM and
aftermarket).
2. Channels strongly differentiate. For example, if customers are served the same products from two
different warehouses (depending upon where the customer is located), the warehouses are likely
This ends your document preview
defined as channels. Customers served via the web or mail order are probably strongly
differentiated from those that are shippedͲto from the warehouse docks on your own trucks. Note
For the complete document, please send a request to the below address. Include a
again, that the same products and even the same customer could be served from any of these
reference to ‘CTS design’ in the email header.
channels.
3. Channels have specific and readily identifiable costs. This usually means they will have costs
If you are an individual or consultancy, please state your reason or needs for the
identified in the general ledger or their own headcount assignment or some other means of
request. The document will be sent to all qualified requestors, including, a) those with
specifically assigned costs.
a qualified corporate email; b) individuals with a LinkedIn profile employed with a
4. Channels are conscious business strategies. Where to place a distribution center, whether to serve
qualified entity, or; c) any other request at our discretion.
customers directly or through a distributor, when to use your own delivery capability or a third
party are all examples of conscious business strategy decisions that have been made in how you
dbaker@quantalyst.com
decide to serve your customers.
CostͲToͲServe Methodology – An Architectural Approach Page 5