Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Purchasing Road Map System (PuRSe)

A database and workflow supporting purchasing financial impacts

Lon Kimberlin

on 5 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Purchasing Road Map System (PuRSe)

Top 20% Business Use Cases
Creation of a Road Map Idea (RMI)
Monetizing of a RMI
Implement an RMI (PACT ~ Piece Price)
Monthly Financial Impact Update
(Quarterly update forecast)
(Monthly (more frequent?) "Actuals")
SDP Proposal (Sept 2013)
Purchasing Road map Item
SAP Receipt History
Forecast Buy (based on FMBR)
SDP Presentation (July 2013)
Lisa Groh-McGraw knows the document.
Donna Bayuga keeps the original copy.
Business Use Case ~ Convert RMI into part detail ... only to be summarized again.
The Basic Element of RMI Financial Conversion
A purchasing PACT road map idea, once it is implemented (meaning it is affecting pricing) transitions from a projection "I think" to a combination of " We know" (actual) and "We believe" (forecast).
When a PACT RMI is moved onto an implementation path, it must make a projection of savings. Savings are "credited" to the implementing buyer and buyers team for 12 months (more detail on this in "Carry Over"). The PRS solution is expected to intelligently break down this 12 month project based on "number of working days in a month and year for a region."

This 12 month projection of savings (or "I believe") continues to be updated based on the Commodity Manager / Directors understanding the idea and the business environment.
When a PACT Roadmap Idea is ready to be implemented (after going through stages covered under "RMI Status Changes") the projection of savings begins to be replaced weekly updates of financial impact based on receipt activity ("I know").
Having a mix of monthly projections but measuring actual performance in weekly buttons must be considered / anticipated.
The balance of PACT Roadmap Idea's 12 months (starting from point of financial impact) is made up of a forecasted savings from the Forecast Material Buy Report. Where the actual performance ("I know") replaces projection ("I think") in the first week (month) after conversion, going forward actual performance begins to replace forecast performance ("I believe").
The Process Overview of PRS
Road Map Item Data Relationships (Historical)
Purchasing Road Map System Fields.
PTP275 Inforecord Price Walk
User Interface Here
SARA Audit Report
The Data Relationship Model Based on Reports / Speculation
Calculation (all iterations here)
Currency Preconverted
Example of Road Map Item and SARA Connection
This in the process of being reviewed.
Additional Master Data Elements should be added ... it exists in Excel today...
A question has been posed to the team regarding the what is the base of a forecast or actual calculations ... receipt, invoice, or payment?
The current receipt record kept in Enterprise Data Warehouse are a front runner as they appear to define receipt and the price paid.
The accuracy associated with what actually was paid the supplier could (should) be considered a gold standard ... its a matter if we have enough gold.
I am not certain that we have in one place, how much the supplier invoiced and what as paid (deriving piece price).
It is possible that we will need to calculate the schedule agreement price at time of receipt if it is not present in the EDW.
This will (could) involve the bringing info records to determine the price at the time of receipt.
The question : How "accurate" must the saving calculation be?
Boldly put, can we multiply the quantity of receipt or payment times the price change? (Simple savings) OR must we take into consideration changes relative to each other ... using an actual example from the price walk report.
Need to find a price change with a retro component for a complete discussion. ( a no retro is already part of the summary).
Solution Approaches to "Excel" like feel in managing "Landscaped" Ideas.
It appears that attempting to calculate retro based on "actuals", we will be attempting to copy a process handled by SARA today.
It may be more expedient when measuring actual savings, to use the SARA reported "savings".
Build on Notes from Kristin McIntire
Savings with no retro element.
Savings with retro element.
Same Year (12 Months)
Cross Year (12 months)
Same Year (12 Months)
Cross Year (12 Months)
Piece Price Change
Business Rules ... defining how a savings idea behaves.
Piece price ... how long does it "record" ... 12 months? What defines the starting point ... effective date or implementation date? Do special rules apply when crossing a FY break point.
One Time Payments (OTP) ...
Fiscal Savings
Total Savings
Carryover Savings

Is it (it is!) possible to define savings (as described in the glossary) based on implementation date, installation date, total savings, forecast savings, actual savings and clear business rules.
One Time Payments (OTP)
As general rule, the savings are simpler in savings reporting ... it happens when it is implemented. This does not diminish the calculation that goes into the OTP ... but at the end of the day, it is the value on the check ... or is it?
Are OTP based on a purchasing leaders "calculation" outside of the solution and getting a check? (Do we expect the solution to project OTP similar to the way that retro's will be "forecasted"? (Posted to eRoom 2 Jan 2014).
Goals (Development and Storage)
The January 2014 version or proposal of the solution from the development team (SPIDER like)
User Interface Development
Master Data Development
A key usability feature of the U/I is creation of a user profile. This profile will assist with initial presentation of the landscape document AND the entry or creation of RMIs. The fields expected to make up the manager profile.
Purchasing Organization
Purchasing Region
Division (AE / PS / BE)
Business Unit ( Seating / Interiors / Electronics) .. or whatever the team calls the subset of "Division".
Supplier ... or maybe not.
It will be beneficial to link each of the columns to master sheet which includes the column (obviously), the "table", dimension or "object", relationships / hierarchies, sources, examples or complete data ...
New Notes are coming 8 Jan 2014.
PPR and Purchasing
Purchasing is not familiar with the MBBP and plant profile (PPR) database. This is not necessarily bad. The two can coexist for a short time but we need to make provisions that they stay connected.
Plant Master Data
This is an example how plants are classified today.
We have attempted to remain agnostic regarding the naming of groupings and focus on data or data examples and using group 1, group 2, etc.
We are also attempting to stay connected to the PPR by a manually maintained link to the PPR table. A plant will have purchasing / finance designations and PPR designations (and likely some unique regional designations).
Vendor Master
Database Structure
E:\Purchasing BPO\Purchasing Savings\Savings Reporting\Official Documents\Execution\Supporting Documents
Full transcript