Generic Approach

8/8/2019 Generic Approach

1/47

KX White Paper Contribution

Integrating a Pricing/Profitability

Solution with an ERP Platform

A Contribution From: James Weaver & Roberto RodriguesDeloitte Consulting LLP/Distinct Package Technologies

Irving Office

November, 2009

Deloitte Consulting LLP


2/47

Table of Contents

Preface......................................................................................................................................................................1

Preface..............................................................................................................................................................1

Introduction ......................................................................................................................................................1Introduction ......................................................................................................................................................1

Motives For This Contribution.........................................................................................................................1

Motives For This Contribution.........................................................................................................................1

Objectives.........................................................................................................................................................2

Objectives.........................................................................................................................................................2

Acronyms and Conventions Used on this Paper...............................................................................................2

Acronyms and Conventions Used on this Paper...............................................................................................2

Section 1Generic Problem Statement and Contribution Description..................................................................3

Section 1Generic Problem Statement and Contribution Description...........................................................3

Section 1.1: Value Adding, Business and Technical Perspectives of Integrating A Pricing Solution.............3

Section 1.1: Value Adding, Business and Technical Perspectives of Integrating A Pricing Solution.............3Being Package Agnostic.....................................................................................................................3

Problem Statement.............................................................................................................................3

Pricing and Profitability Value Adding Drivers.................................................................................4

Technical Contribution Geared Towards Helping You to Deliver Business Value to Your Client(TCV).................................................................................................................................................5

Integration is Key For Value Delivery...............................................................................................6

An Attitude Towards Handling Any Naturally Complex Integration Work......................................6

Section 2Fundamentals Of A Pricing Solutions: Foundations Before Integrating..............................................8

Section 2Fundamentals Of A Pricing Solutions: Foundations Before Integrating.......................................8

Section 2.1: Integrating a Pricing Solution With Any Existing or New ERP System......................................8

Section 2.1: Integrating a Pricing Solution With Any Existing or New ERP System......................................8The Revenue Management Optimization Model...............................................................................8

The Waterfall Concept.......................................................................................................................9

The Price Mart Concept...................................................................................................................10

Allocating Costs: Grasping the Thinking Process............................................................................11

Dissecting the Waterfall Elements: A CIP/Beverage Industry Application....................................13

The Price Setting and Cost Allocation Processes: Feeding the Waterfall With Core Price Elements,Adjustments and Allocated Cost Elements......................................................................................16

Section 3Tackling The Integration Workstream................................................................................................18

Section 3Tackling The Integration Workstream.........................................................................................18

Section 3.1: The Outbound Arm.....................................................................................................................18

Section 3.1: The Outbound Arm.....................................................................................................................18

Using Industry Print : Overall Processes and Tasks To Conceptualize While Minding YourOutbound Arm..................................................................................................................................18

..........................................................................................................................................................19

Pricing Tables And Identifying Where the Outbound Work Will Be Focused On..........................19

On Figure (10), it has being signaled the area where the focus of the Outbound Arm work. (3)Main tasks are part of this piece of the work-stream:......................................................................21

- Field Mapping with Sales and Distribution ERP module Tables and fields.................................21


3/47

- Configuring your Pricing/Profitability Solution to export Price Policy Data in a format that canbe read and loaded via automation on the ERP side........................................................................21

- Choosing and Configuring a Middleware component (Out of the box or customized) to automateloading of Price Policy data onto the ERP Sales and Distribution module and making it availablefor invoicing.....................................................................................................................................21

Identifying Data Sources On An ERP Platform (Mapping Process): Digging into Sales and

Distribution Data..............................................................................................................................21Configuring Your Pricing Solution To Export Price Policy Data....................................................21

Choosing Among Options For Middleware Usage and Configuration To Implement YourOutbound Arm..................................................................................................................................22

Section 3.2: The Inbound Arm.......................................................................................................................23

Section 3.2: The Inbound Arm.......................................................................................................................23

Using Industry Print : Overall Processes and Tasks To Conceptualize While Minding YourInbound Arm....................................................................................................................................23

To recap:...........................................................................................................................................23

..........................................................................................................................................................23

..........................................................................................................................................................24

..........................................................................................................................................................25

..........................................................................................................................................................26

Figures (11-15) intend to represent on a very simplistic but nonetheless comprehensive way justthe sequence of phases/activities that are involved on the Inbound Arm piece of any

Pricing/Profitability ERP Integration workstream. As mentioned previously, on Appendix(2) an .IP file supplying the diagramas shown has being provided as a template. Indeed, IndustryPrint could also used to document the essentials related to the Functional part of both theOutbound and Inbound Arms of the Integration Workstream, in conjunction with other standarddeliverables obtained from our EVD database (In KX) to start up work on Functional andTechnical specifications...................................................................................................................26

Following a sequence documented in Industry Print , the remaining parts of this Section coverthe following details:........................................................................................................................26

- In order to complete tasks and sub-processes: VE-010-030-040 Build Pricing Solutionss Price-

MART Skeleton/Structure and VE-010-030-050 Populate Price-MART Structure in PricingSolution , some classification of WFEs in terms of their originating business processes andcorresponding data sources on the ERP side needs to be completed. Guidelines and Tips are provided in this regard......................................................................................................................26

- Some Tips/Recommendations are provided around the sub-process VE-010-030-020-030Allocate Raw Cost data at an Invoice Line Level when a clear disctinction between Allocationand Aggregation is made. A practical example extracted from a CIP/Beverage Industry clientapplication to allocate Transportation Costs is detailed step by step (IP tasks shown above VE010-030-020-030-010, VE 010-030-020-030-020, VE 010-030-020-030-030 and VE 010-030-020-030-040)....................................................................................................................................26

- Finally, the overall automation process around VE-010-030 (Complete Inbound Arm) iscovered. Recommedations and Tips are provided. Examples illustrating know-how on how totackle Functional and Technical specification work and implementation in terms of tool usage VS

custom development.........................................................................................................................26Classifying Your Waterfall Elements To Facilitate Data Sources Identification On the ERP Side 26

Aggregating VS Allocating Data: A Crucial Distinction.................................................................28

Allocating Costs: A Practical Example in MS Excel.......................................................................29

Modeling the Cost Allocation Automation Process: Weighing Options.........................................32

Modularizing Your Inbound Automated Solution and Minding/Developing Your Functional AndTechnical Specifications..................................................................................................................34

Section 4 Putting Your Work All Together: Testing Strategies, Deployment And Lessons Learned...............37


4/47

Section 4 Putting Your Work All Together: Testing Strategies, Deployment And Lessons Learned.......37

Section 4.1: The Inbound And Outbound Arms Hugging Each Other...........................................................37

Section 4.1: The Inbound And Outbound Arms Hugging Each Other...........................................................37

Your Impressive Yet Understandable Diagram To Show the Results of Your Work.....................37

Holistic Thinking Through The Journey..........................................................................................38

Section 4.2: Testing Strategies.......................................................................................................................38

Section 4.2: Testing Strategies.......................................................................................................................38

The Unit Testing Process (Tips)....................................................................................................................40

The Unit Testing Process (Tips)....................................................................................................................40

The Integration Testing Process (Tips)............................................................................................40

Section 4.3: Deployment................................................................................................................................41

Section 4.3: Deployment................................................................................................................................41

A Sample Cut Over Document.........................................................................................................41

Managing The Roll-Out Process and Post Go-Live Support...........................................................41

Section 4.4: Tips, Recommendations And Lessons Learned (Dos and Donts)...........................................41

Section 4.4: Tips, Recommendations And Lessons Learned (Dos and Donts)...........................................41

Pitfals To Avoid and Best Practices.................................................................................................41

Communication, Communication And Communication..................................................................42

Managing Your Landing On An Integration Project.......................................................................42

Appendix 1Sample Technical Spec For An ABAP Module (SAP)...................................................................43

Appendix 1Sample Technical Spec For An ABAP Module (SAP)...........................................................43

Appendix 2IP Process Diagrams.......................................................................................................................43

Appendix 2IP Process Diagrams................................................................................................................43

Appendix 3Sample Cut-Over Document...........................................................................................................43

Appendix 3Sample Cut-Over Document....................................................................................................43

Appendix 3Cut-Over Document Sample...........................................................................................................42


5/47

A KX Contribution: Integrating a Pricing/Profitability Solution with an ERP Platform

Preface

Introduction

The upcoming pages compose a White Paper contribution to Deloittes Consulting Knowledge Exchange (KX)database. The learning experience we decided to abstract, generalize and formally document on a contribution likethis has being a result of joint work executed at a client from February to June 2009.

We have agreed on not only focus on the technical aspects of the Know-How acquired so it could be leveraged byany other practitioner assigned similar work. We have agreed on providing a holistic approach to our learning basedalso on the value that from a business standpoint an integrated Pricing/ERP solution can bring to an organization.Yet, we have also formally documented lived experiences and tips so others can take advantage of what we learned.Then other practitioners could commit different mistakes and not the same ones we were able to document butothers which could be also documented in successive extensions of this work.

The intent of this paper could be perhaps far from having followed the most rigorous academic standards of Paperwriting. Instead, it has being written in an attempt to be more of a pragmatic tool helping a practitioner who hasbeing assigned to complete related work. In that direction, its story boarding follows this line:

- First, provide context in terms ofbusiness purpose and value for the client organization. This is, ittries first to answer the question: What is on this for the client and why integrating a pricingsolution with an ERP platform is crucial to deliver value?

- Then go onto the Revenue and Pricing/Profitability Fundamentals on a as much simple andpragmatic fashion as possible. These would be the essential concepts to rely on and to have veryclearly understood so a successful and quality integration work can be completed

- Then get deep on the How to go about the Integration work. Both the Outbound(Pricing Solution

ERP) and theInbound(ERP Pricing Solution) arms of the overall process have being covered

- Finally, document Know-How in terms ofTesting, Deployment and Lessons Learned. The LessonsLearned section would be possibly one of the most value-adding ones of the entire Paper for ourPractice and that was the approach that was followed to write it down

We certainly expect to have provided with this Paper a truly useful contribution to our Pricing Practice initially andthen also to the broader Deloitte Technology Service line. We would modestly aim towards that direction becausewe believe the overall approach we have documented as a contribution could be applicable in reality to anyintegration type work.

Motives For This Contribution

Typically any Integration work stream part of an engagement characterizes itself for being very challenging. Perhapsthe main reason for such a fact would be that the success of any work on integration relies on the success of otherwork also, not directly on your hands, residing on the party business processes being integrated. Yet, your successis measured by the sum of the parts working, not on the parts themselves working.

When you integrate you have to dig in the middle of trees of work others are doing sometimes, but step aside

regularly and see the forest. Such a skill is not developed overnight, however, it has seemed to us of much value tobe able to put in written all the know-how we could so others could ride a perhaps faster, less painful at times andmore productive Learning Curve.

Having felt that we have contributed to the firm by successfully executed challenging Integration work made us tocommit on documenting formally what we did for the benefit of our organization as a whole. Not having done itwould have left such an enriching experience unclaimed and an opportunity to try to make a difference not takenadvantage of.

Copyright 2008 Deloitte Development LLC. All rights reserved.Page 1


6/47

A KX Contribution: Integrating a Pricing/Profitability Solution with an ERP Platform December 2009

Objectives

The objectives of this contribution are detailed as follows:

To provide a package agnostic, comprehensive and holisticmethodological frameworkto guide anyfuture Pricing onto ERP Integration work stream part of any Revenue/Pricing Management engagement.Vendavo and SAP -based illustrations of all the concepts, techniques have being provided throughout

this Paper as they relate to the most recent experience we have had. However, the core tools, techniquesand methods part of this approach have being documented thinking on them as of relevance and use nomatter what specific packages are adopted as Pricing and/or ERP solutions

To base such methodological approach on a solid set of Concepts and Fundamentals on Pricing,Profitability, Revenue Management, data flow, data design and deployment. The more solid, clear andarticulated in the mind of the practitioner these concepts are the more productive the correspondingexperience will be

To transmit truly empirical/based on day to day tirelessly work, tips, advice and recommendations to ourcolleagues. There is nothing like having done it and we could not avoid the desire of live how gratifying itis to let others know what we experienced so they can be more productive and even more value-adding totheir clients

Acronyms and Conventions Used on this Paper

WF: Waterfall

WFE: Waterfall Element

VEN: Vendavo

PM: Price Manager

INB: Inbound Interface

OTB: Outbound Interface

OOTBX: Out of the box software application or component

ADJs: Price Adjustments being part of Waterfall Elements (WFEs)

In this guide you will also find the following icon:

Tip:This sign will indicate a section on the Paper where a recommendation/advice based on actual/empirical experienceon an assignment being provided. The advice will be know-how oriented



7/47


Section 1Generic Problem Statement and

Contribution Description

Section 1.1: Value Adding, Business and Technical Perspectives of Integrating A Pricing

Solution

Being Package Agnostic

We believe it could not be a totally off-mark thought to say that, to integrate A and B, you do not necessarily need tobe an expert in doing alone/separately very well and very specifically A and/or B. But to successfully integrate, youhave to:

- Have the willingness to dig onto the intrinsic nuts and bolts of A and/or B to be able to at least understand thebasics of what A and/or B alone experts will be telling you daily

- Understand related business process very wellbefore getting onto the technical aspects of the work

- Understand the fundamental business-process related concepts involved on each arm or side of the integrationwork (data coming in and/or data coming out) to be able to communicate yourself on a clear, non-ambiguous,concise and articulated basis with the many counterparts you will be contacting and talking to all along

- Meet and know people every day and establish rapport and successful communication streams and relationshipswith each one of them

This Paper contribution has thought to be Package Agnostic because when a practitioner is being assignedintegration work she or he will not be responsible for either A or B individually and separately but to ensure thatthe outputs and inputs from/to A/B end up where they need to be. If the related methodological approach is clear andif the practitioner can develop the skill to identify and build productive working relationships with the right peopleon those projects responsible separately for A or B, success being package agnostic will be possible. It isobvious that knowing more on A or B would help but such knowledge would at best be a necessary but not

sufficient condition to successfully integrate.

Problem Statement

We were able to articulate the following bullets in an effort to state the problem we attempted to resolve with thiscontribution:

To establish a conceptual foundation for any (Functional/Technical) design of an interface between aPricing/Profitability solution (Any distinct package) and a given ERP platform (SAP, Oracle, LAWSON,In-House Legacy system, just mention some of them)

To contribute with an approach that will be irrespective of any Pricing/Profitability optimization tool andcould be leveraged on any Pricing-related engagement

To contribute with an approach focused first on understanding business processes, using Industry Print

as a tool to model related business processes

Progress into the technical features of the approach maintaining it tool-independent on thePricing/Profitability side mindset



8/47


Pricing and Profitability Value Adding Drivers

From a practical and value-adding perspective, a clients past execution (past sales and past incurred (direct,indirect) costs to be able to realize those levels of sales) historical data will feed the present process of proactively

set products/services prices trying to increase and if possible maximize profitability. Automating this processtowards efficiency will provide significant value to the business as such dynamics will feed an enriched and morereal, adapted and effective in terms of increased profitability-oriented decision making process.

Described as such, that is a continuous (closed-loop) process for which automation will provide the value of makingpossible a decision making that takes into account with more and more accuracy and speedthe reality of how salesmove and how costs are incurred on a weekly basis for example. After all, the organization prices will be a functionof its market, its competition and its operational direct and indirect costs. If an integral solution such as the one forwhich a know-how is described on this paper is implemented successfully, the client organization can startimplementing pricing and profitability (Possibly cost reducing) measures which will provide them with an edgeagainst their competitors.

On Figure (1) below, the following value-adding drivers to be able to efficiently and effectively take Price andProfitability decisions can be identified. The figures describes an example based on a typical CIP (Consumer and

Industrial Products) Value-Chain (Raw Materials

Manufacturing Process

Retailing Process

EndCustomer)

- Decision Making Based On Transactional Analytics: A decision making process based on the usage of a PriceAnalytics tool which will provide very close to real time information on how sales move and cost related to thosesales move.

- Decision Making Based on Demand Modeling Techniques: The usage of a Price Policy Management tool whichwill be able to receive and incorporate input from current product/services demand trends and to use it efficiently toformulate sound Price Setting Policies.

- Decision Making Related to Develop and Put in Place an Optimized Price Strategy: The use of a Price PolicyManagement Tool which will accurately and efficiently feed Transactional data onto the Price Analytics process thatprecludes the establishments of sound Pricing Policies. Increased profitability will be the ultimate goal beingpursued.

- Effective in Terms of Profitability Deal Making and Execution (Enforcement of Price Policies in Place) :There will be a lot of value to be realized on being able to monitor sales representative behavior not in line withestablished Pricing Policies. The usage of a tool which, based on strong and accurate Price Analytics, allowed PriceManagement decision makers to establish Policies geared towards realizing increased profitability. However,enforcing those Policies will ensure value realization hence, being able to rely on a tool which will make theenforcement process more efficient closes the complete loop of value drivers.



9/47


Figure (1): Pricing and Profitability Value Adding Drivers

The Value added/Business Imperative for which a quali

holistic approach which utilizes multiple data sources cproviding insight and managing margins proactively

Deal Negotiation

Develop deals with retailersconsidering all available pricelevers

Optimized Price Strategy

Manage the price book, policies,procedures, optimal targets,expected outcomes

. . . . . . . . .

.

Technical Contribution Geared Towards Helping You to Deliver Business Value to Your Client

(TCV)

A practitioner was possibly assigned to a Role to design and implement the Integration component of a PricingSolution with a given underlying ERP platform based in her or his technical skills/related past experience. That willhappen with frequency. Nonetheless, increased possibilities of success on the assignment will be directly related tothe capacity of the practitioner to understand the importance of the results of her or his work in the framework ofwhat the client is expecting in terms ofvalue.

TCV or Total Client Value in the case of a Pricing/Profitability engagement would be in direct relationshipwith how clearly Revenue Management Decision Makers will be able to derive new Pricing Policies, decisions interms of Costs reductions and in terms of how to more effectively in cost and increased revenue to promote itsproducts or services. ClearTCV enabled by a solution whose Integration component ensures data flows in and outfrom the solution smoothly providing an accurate transactional and price-setting picture of the organizationsbusiness is the ultimate goal of a sound integration component. Not necessarily a solution embracing the best inbreath technology when decisions of that type did not consider cost, effectiveness and ease of use would be thedesired one.

A practitioner who will go above and beyond its technology-related responsibilities to challenge every move interms of how much impact would that decision have on value delivery will have a greater probability of successfullydeliver a solution of this nature. She or he will also allow the client to think in Deloitte when speaking with otherorganizations trying to benchmark with them on how to use Pricing/Profitability tools to gain an edge on the market.

Tip: Ask yourself always, how much efficient and productive will my client be in terms of realizing trends thatare hurting/would improve its profitability because of the usage of your final deliverables



10/47


Integration is Key For Value Delivery

We will start this section just by quoting the main headline presented on Figure (1) above. This headline says:

The Value Adding Business Imperative for which a quality Interface implementation is key: A holisticapproach which utilizes data from multiple sources can achieve greater profit potential by providing insight and

managing margins proactively

The most important concept expressed on the headline above is in our judgment the one of being proactive. Whencomplex decision making processes need to look at multi-variate related information, data will need to be gatheredfrom diverse sources but would need to be brought together and presented to the decision makers on a condensed yetcomplete and intuitive way. But adequate speed and accuracy are two characteristics that must define the process ofbringing such information to the eyes of the decision makers so decisions are taken at the right time.

Without effectively integrating data (on an automated basis) that will come from diverse sources and presentingsuch data in a way that it generates enlightening/trend-discovery information on the minds of Revenue Managementdecision makers taking proactive decisions will not be possible. Hence, Value Delivery will be compromised.

A sound work integrating such data sources is the cornerstone to provide a data platform that will make possible theapplication of a holistic approach towards value delivery as claimed so far on our contribution. In synthesis, therewill be no value realized without being able to smoothly put everything together.

An Attitude Towards Handling Any Naturally Complex Integration Work

Though technical skills will definitely be important and help in every step of the way, a few others perhaps (soft)skills will be at play when having the responsibility of doing integration work. Here is a tentative list of those traits,conforming perhaps the right attitude to tackle a responsibility of this nature:

- Calm and serenity: At times, you will feel overwhelmed with client and firm representatives expecting from youanswers to many questions on domains you are not directly involved with. That is, you will depend from others tohelp you but you will be asked questions as if you were the primary responsible of those other tasks which are partof the final result of the integration work you are doing. That is simply because integration is done when the partsplus the whole are done. Even when your primary responsibility is the whole its completion will not be possiblewithout the parts being done. This situation will create a lot of anxiety but you need to stay calm, be prepared bydoing your due diligence in contacting the people you depend on and then be able to, with serenity, explain so to

your Management and client representatives.

- Persistency: People both on the A or B sides will say they will help you out but remember that even thoughthey know they work part of a team they will put their own responsibilities and whatever results they would bemeasured by first on their Agenda (As anybody would do). The secret is not to get discouraged when seeing howhard getting the information you need to understand what needs to be done is a situation that repeats time and again.Pressing forward harder but with tact every time will be key.

- Due Diligence: As you will be asking others for help you will be unavoidably compromising part of their time. So,you cannot just simply appear asking for help without having done your homework and being ready to explain theother person what is it that you will be doing to help him help you. Be sure you will show what you have done onyour own to anticipate the answers you are expecting from your other teammate from which you need know-howand expertise she or he only has.

- Communication: Be frank and straight-forward with the various Management level representatives on your

project as quick as possible. Do so whenever you feel things are not getting the needed traction or a major difficulty/road-block brings an unexpected hurdle. Try to listen as much as possible, especially at the beginning of yourengagement during the sponge few days you may have. You will feel that you will possibly not have enoughsponge time but do not get discouraged by that. Communicate often, especially when you are in trouble in terms ofadvancing with the speed you consider you should advance. If you are still in the process of prove yourself on theengagement and you do not have the necessary confidence and rapport with your Project Manager rehearse what youneed to communicate with that person with a buddy of yours in the project or with another peer within the firm youhave confidence with. You can do it on the phone too. For instance, it may have being the case that you went to



11/47


training with a peer of yours before getting staffed on the project and you gained rapport with that person. Rehearsewith her/him what you need to communicate but do so as quick as you possibly can.

- Delegation: Delegate if you can, however, always support and be ready to answer any type of questions fromwhom you delegated in. If you cannot delegate, talk to your Manager and be clear on what you feel you humanly,after a significant/pushed to the limit but humanly possible effort, will be able to deliver. Sometimes you may beforced to delegate and train the person you will be delegating a task into at the same time because deadlines are set

and the person you may have available to help you needs orientation before she or he can produce for you. If youhave to do the job yourself be sure you set expectations clearly with your Manager. Strive to commit with deadlinesbut be also frank when expectations from Management based on what has being committed to the client do notnecessarily match with the reality of what seems possible to be delivered with the required level of quality.

Tip: Spend time knowing who is who at your project. You will probably need to figure out whom the rightparties to talk to among 200/300 team members size projects are depending on the subject at hand. Buildrelationships every day. Your success is based on getting the right information from the right people, not on being anexpert in either A or B if integrating A and B is what you are doing

Tip: Absorb information progressively; do not try to know all at once. The details and know-how you arelooking for to put it to work will build up on themselves incrementally



12/47


Section 2Fundamentals Of A Pricing

Solutions: Foundations Before Integrating

Section 2.1: Integrating a Pricing Solution With Any Existing or New ERP System

The Revenue Management Optimization Model

Figure (2): The Revenue Management Optimization Model

The following is a generic/succinct description of the so called Revenue Management Optimization Model. Wehave described this process in detail because implementation tasks part of the Integration work stream bring to lifethis model and will allow your client to realize value once it is institutionalized within the organization.

We found more practical to explain the model as a series of sequential steps:

Step (1): Assume a set ofPrice and Profitability Policies have being already defined, even before your integratedsolution has being deployed. Daily sales execution will generate accumulated operational data you will want to bring

onto your integrated Pricing/Profitability Optimization Solution periodically to then try to predict and manage thefuture based on better and more effective solutions based in turn in what happened in the recent past. Such historicaldata will need to be transformed and allocated (The allocation concept will be explained shortly veryextensively and will be re-visited later on this contribution) so your solution is able to build up graphs that will helpdecision makers to identify trends and decide upon them. The fundamental cornerstone of this step is to be able toAllocate accumulated sales and cost data at a transactional line basis.

Step (2): Revenue Management Professionals at your client organization will perform Pricing Analysis (PA)activities to identify trends and synthesize recommendations to base decisions in terms of:



13/47


- Pricing Strategy: Increase prices a bit to those clients generating most of the revenue, for instance. Adecision like this will have an immediate impact on the organizations bottom line

- Cost-to-Serve (CTS) changes: Promote less on clients generating less revenue or behaving lessaccording to what was agreed to them. Or, to the contrary, promote more on low revenue generating clientsif identified that they have being supported less historically

- Outliers identification: Be able to support the application of Pareto-rule concepts and decideaccordingly. For example, if the organization incurs in significant costs to drive its trucks to clients indistribution routes which are not generating a sound volume of sales it may decide to reduce significantlymonthly visits and, instead, visit more frequently those customers driving higher volume of sales

Step (3): Based on the results of Transactional Price Analysis activities, major trends are identified and those trendswill feed thePrice Setting/Policy Preparation activities. Price Policies incorporating decisions based on the resultsof the Profit Analysis Step (2) will be published and data on a new set of Price Tables will be interfaced onto thecorresponding organization ERP system.

Step (4): Sales Representatives will be provided with a tool which, now, will enforce compliance with the definedand publishedPricing Policies. Deviations will be detected automatically so proactivity will be at play. Outlier-typeof situations will be detected and the organizations management will be able to act upon those situations before acontract with the end client is signed.

Step (5): New prices will base new sales data getting accumulated daily. We would go to Step (1) above and beginthe entire cycle again.

The Waterfall Concept

The following is a succinct definition of Price Waterfall blended as a result of being part of Pricing/Profitability

training and technically leading one Pricing Solution ERP integration work stream:

A graphical representation of the different components that build up the way a given organizations chargesend clients for its products/services as a function of its different cost and profitability financial elements

A Price Waterfall for one organization is the cornerstone figure helping Revenue Management Decision Makers tocommunicate using the same language on the decision drivers related to set the companys pricing policies. On theY axis of this graph the level of a price component on a desired currency is established. On the X axis the

different components taken into consideration in the process of setting up the final price of a product/service arelisted from left to right. The different components that structure the final customer/retail price are called Waterfallitems or elements (WFEs). Each bar on the graph identifies a WFE. A given bar could be labeled with thered color or not. When a WFE is labeled in red it means it affects the accumulated price with a (-) (negative)sign. The other (2) types of bars representing WFEs are called Price Points. Price Points are represented onthe example graph below in grey color while WFEs are either green or red colored bars. A Price Point is aderived WFE, that is, on its own it does not represent a price component but it is merely the result of an addition ofsubtraction of two other WFEs. Revenue reducer WFEs are normally WFEs that reduce the price ornegatively adjust the accumulated product/service price.

(6) Main types of WFEs will be discussed in a subsequent section of this Paper:

- Price Setting Items: Determined based on Demand Predictions, Elasticity Models, Market/Industry trends,competitor information, external factors, Governmental policies, among others.

- Negotiable Items: Included on end-client invoices to adjust (Up or down) the initial Price Setting total. Theseelements are negotiable with the end-client typically based on behavioral factors. Example: If a client hits a certainsales target on a given period of time, it may be entitled to a discount on the Price being offered for the productsbeing sold when such target is hit

- Invoiced Items: Simply included on end-client invoices

- Revenue Reducing Items: Typically items related to incentives on promotional activities such as rebates forexample and other discounts given to foster increases in sales



14/47


- Chargeable Items (CTS): Constitute a very important part of the Waterfall. Relates to elements that encompasshow much does it cost the organization to put its products or services available for sale in the market (TransportationCosts, Other Promotional Costs, among many others (Details will be provided further on this contribution)

- Cost of Goods Items: Constitute a very important part of the Waterfall. Relates to elements that encompass howmuch it costs the organization to produce its products or services (COGS (Cost of Goods Sold) plus incorporatingprofit margins appropriately

As it becomes apparent by now, delivering value from the use of a tool such as a Price Waterfall stems greatly andprimarily from the ability to properly populate the underlying data that could accurately reflect the reality of thebusiness as frequently as possible. Transactional data builds the Waterfalland it is used and processed, at an invoiceline by line basis, to determine the relative values of each Waterfall element. Price and Profit Analytics allows forthe formulation of sound Price Policies which then are enforced also using the tool.

The Integration work streams responsibility is to bring the Waterfall tool to live so it can be used to provide thevalue it is intended to provide.

Figure (3): An example of a Waterfall representation for a Food/Beverage CIP client type organization

The Price Mart Concept

The following is a succinct definition of the Price-MART concept. A Price-MART is more an InformationTechnology driven concept rather than a business related concept. It is essentially a concept related to how Waterfalldata including multiple data dimensions (For a CIP Food/Beverage organization such dimensions could beCountry, Region, Product, Market, Sales Organization, Customer and many others) is organized



15/47


and stored on an automated database part of the Pricing/Profitability solution being integrated with thecorresponding ERP platform in question.

See Figure (3) for a graphical, very schematic, representation of a Price-MART

Figure (3) A Price-MART Schematic Representation

The following are the main characteristics of the Price-MART which is the core data modeling/storagecomponent supporting any Price/Profitability Optimization tool:

Follows same overall data-mart concept that we know from Data Warehousing basic definitions andknowledge

However, data stored specifically revolves around prices and about the process that conducts toestablish Pricing Policies. The main attributes of a line of sale plus how much did itcost/profitability left a given invoice line are stored on the Price-MART

Each line corresponds with one line of invoice part of final sales transactions involving the organizationsproducts/services

There is a section (at the beginning, labeled on the graph above as the Derived Attributes section)composed of attributes which could be direct or derived (as a result of adding/substracting (2) WFEs)(Product, Customer, Sales-Organization related attributes).

Attributes can be alphanumeric (Ex: Product Code) or Numeric (Ex: Base Price)

The rest of the fields are Waterfall Elements, both actual WFEs and Price Points

Part of the Integration work streams responsibilities is to perform all technical-related (Functional an Technical

design, implementation, testing and deployment) activities necessary to initialize and periodically update the PricingSolutions Price-MART.

Allocating Costs: Grasping the Thinking Process

Let us recall, first of all, the definition previously cited of Cost of Goods type WFEs:

- Cost of Goods Items: Constitute a very important part of the Waterfall. Relates to elements that encompass howmuch it costs the organization to produce its products or services (COGS (Cost of Goods Sold) plus incorporatingprofit margins appropriately).

Indeed, profit-margin related items will be WFEs (Such as Virtual Profit Margin, see Section titled DissectingWaterfall Elements: A CIP/Beverage Industry Application right following this one for more details and for afull understanding with real life examples of all the WFE types on a Price Waterfall) will be appearing on a typical

Waterfall after the actual Cost-related items.Yet, the most important characteristic to be grasped on any Waterfall element part of an applied Price-Mart is thefact that each line of the Price-Mart will correspond with the outmost granular sales transaction of the clientorganization. Let us show a practical example from a Beverage Manufacturing company:

- Beverage on container of size (S) of (6) units each (CalledSKU) is sold on (5) different brands (B1-B5) to clients (Retailers on route [R] monthly). A client on a given routeis visited (N) times a month and once a month a consolidated invoice is submitted to the end client to collectpayment. Let us consider such invoice having a lay-out as follows:



16/47


CustomerID#

Sold-On-Date

ProductID#

FINALPrice/SKU

NET#SKU's

Sold

NETAmountSOLD Liters/SKU

NETAmount inLIT/SOLD

0001-1 3/1/2008 Brand 1 $5.00 2500 $12,500.00 2 5000

0001-1 3/1/2008 Brand 2 $6.00 6000 $36,000.00 2.5 15000

The example invoice above has (2) lines corresponding to (2) sales transactions on a given period of time such as amonth. On the corresponding Price-MART, for any type of price/profitability analysis to be effective, there will beone (1) line (record) per each line of transaction on any invoice. Not one aggregated line per each invoicesummarizing each line on each invoice.

This is a very important distinction to be made and one of the core concepts to be graspedwhen being assigned toa Pricing Solution-ERP integration project. More than 80% of the entire time devoted to this work stream will focuson being able to automate the process of Allocating periodical totals costs incurred to serve clients back to eachand every line of sales transactions occurred during that period. As costs will be accounted while sales transactionsare occurring daily and no total costs will be closed/available until the closure of the current month/periodallocation of costs to come up with the value of each cost-related WFE for the current period will be typicallydone based on total costs of the priorperiod. There is no such thing as Aggregating costs in Price/Profitabilityoptimization. The Aggregation concept will be explained on a further section of this contribution.

Here is a succinct definition of the process of Allocating costs:Allocating costs is to determine, per each salesinvoice detailed transaction line, how much of a total accumulated of costs of a certain type (Such asTransportation costs, COGS, etc) in a certain period corresponds to that particular transaction line . Here wepresent an example:

- (L) number of liters of beverage of brand (B1) have being sold to the group of customers on a given distributionroute and during that period (D) millions of US$ have being spent to enable all trucks to cover all the routes to becovered on that period. If on a summary invoice per month (X) liters of beverage (B1) have being sold to customer(C1), the objective of the cost allocation process is to determine what portion of the (D) sub-total to assign as anactual transportation cost of having sold (X) liters. We will, in this particular example, need to determine per route,customer and liter, what the actual cost allocation factor in US$ will be. A detailed example on Section 3.2 of thiscontribution will be presented with detailed calculations illustrating this process.

Important considerations throughout the Process of Allocating Costs prior to loading/updating a Price-

MART:- You typically use a pot of costs of the prior accounting period (Month, quarter, week, etc, depending) as a baseto do allocations related to the WFEs of the Price-MART you are trying to populate this current period

- Totals of costs for a period could be given to you in different ways, all depending on how, at the moment, theclient may be able to provide you with such data as they have it organized on their current legacy system. Forexample, Transportations Costs data could be provided perDistribution Agency and you may be also provided withthe volume of sales in Liters (LT) of beverage perBrand. You could also be provided with Costs data in US$ (Orany applicable currency) perDistributing Agency as well. You would be normally interested in getting volumes ofsales per period inproduct Units so you can convert such volume in (Liters) orUS$ depending on what would makethe most sense in terms of allocation. These ideas will appear clearer on Section 3.2 when an actual TransportationCosts allocation exercise is reviewed.

- Ensure the pro-rating of costs on consistent measures before you proceed to allocate such costs at a

transactional line level. This is, if you have being provided with (Monthly costs) and are now considering sales dataon a weekly basis (That is, you are on a weekly basis allocating and populating again your Price-MART), you willneed to pro-rate costs at a daily basis (Say, considering a standard month duration of 30 days) and then allocate aweekly fraction of the total of costs you were provided, not the (Grand) monthly total. Do quotients or simplerelationships multiplying and dividing apples with apples and not apples with oranges. That would be the ruleof thumb.



17/47


Dissecting the Waterfall Elements: A CIP/Beverage Industry Application

Using as an example a CIP/Beverage organization application, the following figures illustrate more in detail how thedifferent Sections or Categories of WFEs break-down.

Figure (4): Dissecting Waterfall Elements on a CIP/Beverage Industry Application (Part I)Figure (5): Dissecting Waterfall Elements on a CIP/Beverage Industry Application (Part II)



18/47


W

Figure (6): Dissecting Waterfall Elements on a CIP/Beverage Industry Application (Part III)



19/47


W

R eFigure (7): Dissecting Waterfall Elements on a CIP/Beverage Industry Application (Part IV)Copyright 2009 Deloitte Development LLC. All rights reserved.Page 15


20/47


W

V aThe Price Setting and Cost Allocation Processes: Feeding the Waterfall With Core Price Elements,Adjustments and Allocated Cost Elements

It was mentioned previously that the automation of the feeding routines that periodically run to fill-up/update anorganization Waterfall (Price-MART) constitutes at least 80% of the overall effort involved on an Integration workstream. This rule of thumb becomes valuable when deciding how to allocate also resources onto your work-streamand set up priorities towards meeting deadlines. The work just described is called the Inbound Arm(Transactional Data coming from the ERP platform onto the Pricing Solution) of the Integration work stream and



21/47


we have dedicated an entire section to provide details on all the nuts/bolts involved in designing and implementingthe Inbound Arm.

To put things in perspective, one person for 1-2 months being very conservative FTE could roughly, from themoment the underlying data design is defined and finalized for the Outbound Arm (Price Policy data comingfrom the Pricing Solution onto the ERP platform) take care of the functional and technical design corresponding tothe Outbound Arm. But you would be more than in need to delegate work on the Inbound Arm by groups of

WFEs most probably. The amount of work and the uncertainty involved on the work until all information needed tounderstand how to initialize and allocate is discovered could be much greater

Tip: Delegate the Outboundwork on one person for a limited period of time. Be sure that person will be alsoable to help you with the Inbound work. Be conservative when estimating the number of people you would countwith to complete all theFunctional/Technicalspecification work related to allocation methods. You may need to runa full blown shop developing custom code to accomplish this goal but the Analysis piece related toidentify/understand the data sources and collaborate with responsible teammates on the ERP side may takesignificant time. Be conservative estimating this period of time because, typically, the information that you need willnot be as readily available as you may want it

Feeding the Waterfall with Core Price Elements and Adjustments would be part of the Inbound arm work. Youwill be designing functionally and technically an automated process that will retro-feed invoice line fields such as

Base Price, Rebate amounts, and a number of fields which will be already available on each invoice. No allocationwill be needed for these fields because, as you may remember, each line on the Price-Mart should correspond witheach and every Sales invoice line. Attribute data such as Customer, Sales Organization, Region, Product, etc (Justto mention a few fields) may need to be derived, however, such data will be queried from one or more tables on yourERP system database (This regardless on how simple/complicated those queries may be).

Tip: Work with yourPricing Solution manufacturer specialist and, directly with Product Engineeringtoprocure if needed, the necessary adjustments on the Product itself to fulfill the clients requirements. This is, if thespecialist working with you at the client site warns on potential performance issues on the Pricing Solution to beable to have non-aggregated Price-Mart data you will need to stand firm and procure the resolution of that problemon behalf of Core Product Engineering. Functionality provided and satisfaction of your clients requirements soPrice/Profitability Analysis can be done at a transactional (invoice line) level are elements that cannot be negotiated because value-delivery heavily relies on these premises. Keep requirements and technical limitations separatelyanalyzed and establish the right priorities with whoever helps you on-site from the Pricing Solution Manufacturerside

Tip: One topic that it would be very good it does not catch you off guard is the determination of the actualTransaction-ID field value to be recognized when loading data onto your Price-MART. You will need to be able touniquely identify transaction records. Be sure you diagram the situation and work together with counterpartsinvolved with theSales/Distribution process currently in place supported on the clients ERP solution. Spend timematuring a solution for this issue as it will not be an easy one most probably. If for instance your work stream is partof a large and brand new SAP implementation, it could be the case though that the client may want to maintain twofeeds in parallel: One from the legacy systems into your Pricing Solution and another from the successiveecosystems in SAP that may start to be rolled out on a scattered basis. If this is the case not only theTransaction-ID field determination and correct generation/population would be a challenge but also the unification

ofMaster Data-related ID-s (Customer ID-s, Product-IDs, Organizational-Units-IDs, etc) will be of consideration.



22/47


Section 3Tackling The Integration

Workstream

Section 3.1: The Outbound Arm

Using Industry Print : Overall Processes and Tasks To Conceptualize While Minding Your

Outbound Arm

Even though we will present one more time the diagram below also when talking about the Inbound Arm, we willspend some time on the related terminology and trying to visualize the end to end thought process involved on any

Pricing ERP Integration work stream.

Let us first agree on the meaning of both Arms:

- The Outbound Arm: As a result of the overall Price Management process, Policy Tables are confectioned usingyour Price/Profitability new solution as a tool. Data on these tables needs to be published and enforced to becomplaint with on the current ERP-side Sales/Distribution sub-systems. Such data needs to be periodically exported

from the newly implemented Pricing Solution onto the ERP system corresponding Master Data tables so new sets ofPrices can be enforced while issuing new invoices. All the functional/technical specification preparation activitiesplus the subsequent implementation and deployment tasks revolving around the automation of this export processconform what we have defined as the Outbound Arm (OTB) of the Integration work stream.

- The Inbound Arm: Transactional Data is generated daily on each and every invoice that is issued to end clientswhen selling products/services. We would be referring to invoice data at its inception being recorded as a Payable.Pure invoice transactional data (Item prices, discounts and others directly available on each invoice) will need to beimported onto the newly implemented Pricing/Profitability optimization solution as it becomes available. At thesame time, incurred costs data on the operations period in question will need to be allocated over each and everysales transaction line. All the functional/technical specification preparation activities plus the subsequentimplementation and deployment tasks revolving around the automation of this import process conform what wehave defined as the Inbound Arm (INB) of the Integration work stream.

We have developed a template (IP) file in Industry Print to serve as a guideline to understand processes and tasksinvolved on an Integration work stream of this nature. It will be provided as an Appendix. Two (2) relevant levels ofthis template diagram have being presented in Figures (8) and (9).

Figure (8): High Level Industry Print Integration Work Stream Process Diagram



23/47


Figure (9): Outound Arm Section of an Industry Print Integration Work Stream Process Diagram (Process VE-010-060) expanded)

Pricing Tables And Identifying Where the Outbound Work Will Be Focused On

On Figure (10) below an overall perspective of where work related to the Outbound work stream arm will beresiding logically is presented. The core activity will be to complete a mappingbetween all relevant fields on thecorresponding Price Tables on your Price Optimization solution and the Sales/Distribution/Master DataManagement ERP module tables and fields. This is why we have included the next (3) Sections on this part of this

contribution:

- How to go about identifying data containers (And their data definitions) on the ERP side where PricePolicy Data will be stored

- Factors to be considered when choosing a middleware solution to automate the Integration OutboundArm

- How to go about configuringboth your Pricing/Profitability Optimization solution and your middlewaresolution to the automate the Integration Outbound Arm

Figure (10) offers a very detailed vision on where the Outbound part of the Integration work stream resides. Theway Price Policy Tables are designed, that is, the underlying data modeland the attributes and relationships that endup shaping up which fields each object/table on one side will have and which fields will be part of the other sidetables/objects will greatly vary on which industry/business your customer is in.

We are able to cite as an example names ofPrice Tables for a CIP/Beverage Industry client application. For abeverage producer and distributor the following elements are key in shaping up their Policy Tables:

- Product Brand (Different brands of beverage that are distributed)

- Size and Type of the container (Bottle) in which a given product brand could be delivered

- Agency in charge of distributing the different brands

- The Region and specific city Zone in which both the Agency resides and end clients reside

- Packaging types on which different brands are distributed (Packages of 6, 12, 24 bottles for example)

- Route (Within a Region and a Zone) in which a given end client is located on the distribution process

- Distribution Channel (In this case, a beverage producer differentiates between distributing beverage to small

business VS large retailers such as any of the large US retailrers for example)- Market Segment (In this case, a beverage producer differentiates between different target markets following theclassical definition of Target Market (High-end/Low-end restaurants, bars, etc)

As a result, Price Policy Tables will establish for a given (Fiscal normally, or could be Year or month, there will bealways a Beginning Date and an End Date indicating the period of time over which a given Policy Table iscurrent) period of time and combining one or more of the attributes listed above as applicable Price Data covering:

- Base Price

- Size/Type Adjustments



24/47


- Price Zone Adjustments

- Agency Adjustments

- Packaging Type Adjustments

- Global Adjustments

- Country Adjustments- Regional Adjustments

- Route Adjustments

- Segment Adjustments

Price Policy Data, upon taking input from several sources (Including the same Inbound Arm which will be detailedon the next Section of this paper corresponding to the Price Optimization System box on Figure (10) below) isgenerated over the Solutions Price Setting Environment box shown on Figure (10) below.

Figure (10): Price Management Taking Place on A Price/Profitability Optimization Tool and Outbound Arm



25/47


On Figure (10), it has being signaled the area where the focus of the Outbound Arm work. (3) Main tasks are part ofthis piece of the work-stream:

- Field Mapping with Sales and Distribution ERP module Tables and fields

- Configuring your Pricing/Profitability Solution to export Price Policy Data in a format that can be

read and loaded via automation on the ERP side

- Choosing and Configuring a Middleware component (Out of the box or customized) to automateloading of Price Policy data onto the ERP Sales and Distribution module and making it available forinvoicing

Identifying Data Sources On An ERP Platform (Mapping Process): Digging into Sales and

Distribution Data

These data sources will greatly vary in terms of their specific data design from client to client. But typically, youwill be interested in finding documentary resources and contacting the right teammates (Either from the client, a 3 rd

party vendor or from Deloitte) on the ERP side who can answer questions related to that solution Sales andDistribution Module.

Essentially, you will be interested in understanding in its entirety the underlying data model residing on the ERPside and supporting Sales and Distribution functionality. This, is, basically, all entities and relationships,expressed then as a set of tables and fields, supporting primarily the issuance and management of sales invoices.

In the case of SAP, it will be required to determine the set of tables, fields related to the conditional records thatwill holdPrice Policy Data. Normally such conditional records will be composed of ZV (xx) fields. Following isan example of a mapping applicable to our CIP/Beverage Industry client example:

SAP Field On Conditional

Records Field On Your Pricing/Profitability Optimization Solution

ZV00 Base Price

ZV01 Type of Container Adjustment

ZV02 Price Zone Adjustment

ZV03 Agency-related Adjustment

ZV05 Other Adjustments

Tip: Write down relational (Entity-relationship diagram) schemas as underlying data related to Sales andDistribution functionality will be typically relational (Oracle or SAP ERP platforms, for instance, rest overrelational databases). Even if the ERP platform may rest over a non-relational database, to first understand how anyunderlying data model is being laid out trying to model the reality in terms of entities and relationships will alwayshelp. You can still listen, understand or read documentation around how the data model is being composed on theERP side supporting Sales and Distribution functionality to then elaborate your own Entity-RelationshipDiagram We suggest doing so as a best practice to ensure all the details of the design are understood. This Tipwill also apply for the Inbound Arm work, as it will be detailed on the following Section of this contribution

Configuring Your Pricing Solution To Export Price Policy Data

It will not be uncommon to find out that, regardless of the specific Pricing/Profitability (Package) solution beingprovided to a client, the Outbound Arm related technical design and implementation work will be pretty much outof the box. This is, the data model on the Pricing solution side will need to be customized so data exported couldthen be loaded on the ERP side but such customization work tends not to be very extensive in comparison to theInbound Arm side of things.

In fact, Pricing and Profitability solution vendors such as Vendavo (www.vendavo.com) and Zilliant (www.zilliant.com) have offered very precise documentation on how to configure the Pricing product in such a waythat Price Policy data could be interfaced/integrated successfully with ERP platforms such as Oracle or SAP.

http://www.vendavo.com/http://www.zilliant.com/http://www.vendavo.com/http://www.zilliant.com/


26/47


In the case of Vendavo , pages 50-160 on this attached PDF Guide offer details on how to go about configuringthe solution to be able to interface Price Policy data (In the form of conditional records) into SAP

Note: To gain proper access to this material, when engaged on an assignment, please contact James Weaver([email protected])

The essential steps to be followed to set-up Vendavo and get it ready to interface Price Policy Data follow:

1. Extract pricing meta-data from SAP ERP

2. Load meta-data into Vendavo (This is, schema or data definition data that came from SAP into Vendavo)

3. Define extensions to VPriceRecord (This is, making this step applicable regardless of the package beingused as Pricing/Profitability solution, to customize the data container you may have on the Pricing side to

be able to hold all the data elements required to interface onto the corresponding ERP platform)

4. Map source entities to VPriceRecord (In general and regardless of the Pricing package being used, theproducts data model holds data on entities and those elements will need to be mapped onto the final data

container (For Vendavo it is called VPriceRecord) from which Price Policy data will be exported onto the

corresponding ERP platform)

5.Map entity fields to condition table fields (This will be an ERP package specific step and may vary on itsimplementation, however, irrestrictive of package there may be the need to map the results held on the datacontainer for Price Policy records onto the values that will need to be loaded onto the corresponding ERP

platform (Sales and Distribution/Master) Price Tables)

6. Map pricing fields to condition types and ordered list of possible condition tables (SAP-specific step)

7. Define adapters for generating VPriceRecord and VConditionRecords (Irrestrictive of package one moretime, because you have customized the Pricing side data model to accommodate how data will be needed

on the ERP side, you will need to also customize the corresponding routine/job/event needed to export the

data and make it available to then be interfaced onto the ERP side)

8. Export VConditionRecord (The actual execution of the Export job, irrestrictive of package. It maygenerate either a CSV file, an IDOC (NetWeaver ) file directly or leave data onto a relational table)

Choosing Among Options For Middleware Usage and Configuration To Implement YourOutbound Arm

Essentially, just because a given manufacturer of a Pricing/Profitability solution such as Vendavo or Zilliant provides a full blown set fo software components to automate the Outbound Arm part of the Integration workstream with SAP or Oracle, that does not necessarily mean using those components would be the best/most efficientoption.

It may be very well the case that your client will not count with anybody able to support SAPs XI/PI integrationplatform (Process Interchange ) so the selection of such Middleware component (Unless already acquired formany other purposes) may not be feasible or cost efficient. Or, simply, the frequency of update of Price Policy dataonto the ERP system is not high enough to justify going through the risk of incorporating another component onto aprobable already complex set of interaces implemented overXI/PI .

Perhaps just the implementation of a UNIX shell script which will upload Price Policy data directly over Oracle tables or on temporary tables/objects on a scheduled basis (Every (6) months for example) will suffice. A thoughtprocess like this, just evaluating the best option in terms of cost/benefit and Value will be highly recommended.

In the case of Vendavo , pages 90-150 on the previously attached PDF Guide offer details on how to go aboutconfiguring XI/PI to be able to interface Price Policy data (In the form of conditional records) and on anautomated basis creating IDOC documents to be loaded in SAP.

mailto:[email protected]:[email protected]


27/47


Section 3.2: The Inbound Arm

Using Industry Print : Overall Processes and Tasks To Conceptualize While Minding Your

Inbound Arm

To recap:

- The Inbound Arm: Transactional Data is generated daily on each and every invoice that is issued to end clients.We would be referring to invoice data at its inception being recorded as a Payable. Pure invoice transactional data(Item prices, discounts and others directly available on each invoice) will need to be imported onto the newlyimplemented Pricing/Profitability optimization solution as it becomes available. At the same time, incurred costsdata on the operations period in question will need to be allocated over each and every sales transaction line. All thefunctional/technical specification preparation activities plus the subsequent implementation and deployment tasksrevolving around the automation of this import process conform what we have defined as the Inbound Arm(INB) of the Integration work stream.

We have developed a template (IP) file in Industry Print to serve as a guideline to understand processes and tasksinvolved on an Integration work stream of this nature. It will be provided as an Appendix. Two (2) relevant levels ofthis template diagram have being presented in Figures (11) and (12).

Figure (11): High Level Industry Print Integration Work Stream Process Diagram



28/47


Figure (12): Inbound Arm Section (Master Data Interfacing) of an Industry Print Integration Work StreamProcess Diagram (Process VE-010-010) expanded)

Figure (13): Inbound Arm Section (Transactional Data Interfacing) of an Industry Print Integration Work StreamProcess Diagram (Process VE-010-030) expanded, level (1))



29/47


Figure (14): Inbound Arm Section (Transactional Data Interfacing) of an Industry Print Integration Work StreamProcess Diagram (Process VE-010-030) expanded, level (2))

Figure (15): Inbound Arm Section (Transactional Data Interfacing, allocation procedures) of an Industry Print Integration Work Stream Process Diagram (Process VE-010-030-020-030) expanded, level (3))



30/47


Figures (11-15) intend to represent on a very simplistic but nonetheless comprehensive way just the sequence of

phases/activities that are involved on the Inbound Arm piece of any Pricing/Profitability ERP Integrationworkstream. As mentioned previously, on Appendix (2) an .IP file supplying the diagramas shown has beingprovided as a template. Indeed, Industry Print could also used to document the essentials related to the Functionalpart of both the Outbound and Inbound Arms of the Integration Workstream, in conjunction with other standarddeliverables obtained from our EVD database (In KX) to start up work on Functional and Technicalspecifications.

Following a sequence documented in Industry Print , the remaining parts of this Section cover the followingdetails:

- In order to complete tasks and sub-processes: VE-010-030-040 Build Pricing Solutionss Price-MARTSkeleton/Structure and VE-010-030-050 Populate Price-MART Structure in Pricing Solution , some

classification of WFEs in terms of their originating business processes and corresponding data sources on the ERPside needs to be completed. Guidelines and Tips are provided in this regard

- Some Tips/Recommendations are provided around the sub-process VE-010-030-020-030 Allocate Raw Costdata at an Invoice Line Level when a clear disctinction between Allocation and Aggregation is made. Apractical example extracted from a CIP/Beverage Industry client application to allocate Transportation Costs isdetailed step by step (IP tasks shown above VE 010-030-020-030-010, VE 010-030-020-030-020, VE 010-030-020-030-030 and VE 010-030-020-030-040)

- Finally, the overall automation process around VE-010-030 (Complete Inbound Arm) is covered.Recommedations and Tips are provided. Examples illustrating know-how on how to tackle Functional and Technicalspecification work and implementation in terms oftool usage VS custom development.

Classifying Your Waterfall Elements To Facilitate Data Sources Identification On the ERP Side

When working on the Inbound Arm, the Practitioner leading an Integration workstream of this nature will need to:

- First understand the current Waterfall design, that is, all the WFEs business meanings in terms of revenues andcosts. Trying first to understand, in general, what each WFE is attempting to measure. Maturing related conceptsmay take a few days. To expect grasping every concept too quickly would not be realistic.

- Then, group WFEs by underlying Enterprise Resource Planning macro-process. If in the context of a large SAPimplementation for example, and around specifics on the clients Industry, the practitioner will need to identify allthe End-To-End business process at a higher level first that are being part of the SAP initiative. Indeed, it couldmake sense to see both more than one WFE tied to one macro-process and one WFE indeed tied to many macro-process (That is, involving data to be processed and transformed which is involved or it is part of several businessmacro-processes, processes or sub-processes). Here is an example:

- For a CIP/Beverage industry (Manufacturing) client who manufactures and distributes beverages theseare some of the end of end process to be identified:

- Product to Profitability (P2PR) Process (This is typically the macro-process of which yourPricing/Profitability solution implementation effort will be part of)

- Product to Client Process (P2C) (The Distribution of products/services to clients door ordistributors location depending on the distribution channel being utilized)

-Product to Payment Process (P2P) (The Invoicing process of goods sold)



31/47


- Product to Inventory Process (P2I) (The process of storing production/various goods/assestsprior to Distribution)

-Sale to Collection Process (S2C) (The process of collecting payment upon invoices issued)

- Record to Reporting Process (R2R) (Internal reporting (The process of fulfillingFinancial/Operational reporting needs from various stakeholders on the client organization))

- Then, once the practitioner has a foot on the big picture of processes and macro-process involved, the next step isto go deeper in detail identifying data sources to then map them to each WFE. You will start mapping sets of dataentitities and will end up being able to map fields and write pseudo-queries in a relational (SQL) data querylanguage to complete work on your upcoming Inbound ArmFunctional and Technical specifications.

This process, the mapping process, is the most difficult yet rewarding one. Difficult because you may encounter theneed of doing modifications on the ERP side which may not be in scope or may not be foreseen before you came in(Or may not even be feasible at the time or resources on the ERP side would need to be procured first to make theneeded adjustments within the timeframe you would need them). Your work may bring a new perspective not onlyto your client but to other collegues of yours as well. And difficult also because an ERP platform data model,especially since the Waterfall touches one way or the other many end to end business processes, may be verycomplex. It may be very challenging to obtain only one version of how the ERP data model piece you are looking todissect is being conceived.

Nonetheless, it will be a rewarding task because once you gain clarity on where are the data entities and fields youneed to understand on the ERP side data model a lot of tasks start going downhill after the intial difficulties. Beingable to successfully complete this step will be challenging because it is a communication challenge more than atechnicalone. Digging onto documentation will help but being able to tap into other people on the engagement whomay have an edge over you in knowking other colleagues/client counterparts and have them helping you to properlyconnect will be even more benefitial.

Tip: Be aware that you may be very well contributing also with the workstreams that relate to implement thenew systems you may be trying to integrate with. For example, as a result of the process of digging onto the ERPprocesses and tying them to your WFEs, you may help Analysts implementing a new ERP platform or maintainingan existing one to anticipate/discover design pitfalls, weaknesses or simply opportunities for improvements that maybe valuable. Bringing this type of perspective when you are trying to communicate with others to gather theinformation and most importantly the knowledge you are looking for may be benefitial. Anticipating problems will

always be better than having to react to them when it is already unavoidable not to see their consequences.

Going back once again to our CIP/Beverage Industry reference example, a sample classification of WFEs prior tomap them to end-to-end business macro-process is presented below:

Sales and Distribution Data: All the following data elements will appear on final sales invoices: Price-related fields (Core Price elements plus/minus governed by Policy Tables (See page (21) of

this Paper for a sample list of possible fields) Discounts (Governed on Policy Tables, example on Papers page (21)) Adjustments (Governed on Policy Tables, example on Papers page (21))

Note: Populating WFEs categorized on this classification corresponds to the execution of the IP tasksVE-010-030-040 Build Pricing Solutionss Price-MART Skeleton/Structure and VE-010-030-050

Populate Price-MART Structure in Pricing Solution

Cost-related WFEs: Classified as follows: COGS (Costs of Goods Sold) WFEs:

Variable/Fixed Costs: For example a, beverage manufacturing company may need to break down

Variable/Fixed COGS between the costs incurred at the Brewery (Factory) andthe costs incurred at the Agency prior to distribution of the products. This



32/47


particular classification may vary depending on the specific characteristics andparticularities of your clients Supply and Value chains

Cost To Serve WFEs (CTS WFEs): Transportation Costs: Costs incurred to ensure products/services are brought to the end-

clients doors Marketing Costs: Promotional costs in terms of ad campaigns and other vehicles to

increase awareness on your clients products/services Owned-business Distribution costs: Costs mother organization (Your client) may incurcovering expenses of various (owned) clients. Your client may fund these businessoperations as an incentive to sell mother organizations products/services

Costs of various incentives provided to end customers to place mothersorganization products/services:

Inventory adherence incentives: discounts on price for future orders ifspecified and pre-negotiated inventory levels are met

Various sales targets related incentives: discounts on price for futureorder

Generic Approach

Documents

Transcript of Generic Approach