Managing and Using Historical Data within RapidResponse

1. Managing and Using Historical Data within RapidResponse Kris Reid director, deployment services

2. Why Keep Historical Data? • Demand • Understand forecast accuracy through visibility to forecast vs. actual demand over time • For use in calculating statistical forecasts and forecast disaggregation as part of the S&OP process • Traceability of root cause for inventory liability issues • Supply • Monitor Schedule volatility and attainment by comparing planned production with actual completions • Compare Supplier Performance (Commit vs. Actual Delivery)

3. Demand - What Data Do I need? HistoricalDemandSeriesDetail HistoricalDemandActual HistoricalDemandSeries HistoricalDemandWaterfall Legend HistoricalDemandHeader Historical Data Needed Can be Autocreated ToleranceProfile HistoricalDemandCategory PartCustomer Input Table Calendar Control Table Part Customer Calculated Table CalendarDate

4. Demand - What data do I need? • HistoricalDemandSeriesDetail • Series • Series.Id • Series.Header.PartCustomer.Name • Series.Header.PartCustomer.Site.Value • Series.Header.PartCustomer.Customer.Id • Series.Header.Category • BeginDate • EndDate • Quantity • UnitPrice

5. Demand - What Data Do I Need? • HistoricalDemandActual • Header • Header.PartCustomer.Name • Header.PartCustomer.Site.Value • Header.Category • Date • Quantity • UnitCost • Unit Price • CommitDate (optional) • RequestDate (optional)

6. Supply - What Data Do I need? HistoricalSupplySeriesDetail HistoricalSupplyActual HistoricalSupplySeries HistoricalSupplyWaterfall Legend HistoricalSupplyHeader Historical Data Needed Can be Autocreated ToleranceProfile HistoricalSupplyCategory PartSupplier Input Table Calendar Control Table Part Supplier Calculated Table CalendarDate

7. Supply - What Data Do I Need? • HistoricalSupplySeriesDetail • Series • Series.Id • Series.Header.PartSupplier.Name • Series.Header.PartSupplier.Site.Value • Series.Header.PartSupplier.Supplier.Id • Series.Header.Category • BeginDate • EndDate • Quantity • UnitPrice

8. Supply- What Data Do I Need? • HistoricalSupplyActual • Header • Header.PartSupplier.Name • Header.PartSupplier.Site.Value • Header.Category • Date • Quantity • UnitCost

9. How to Capture Historical Data • Option 1 : Integrate from existing data stores external to RapidResponse • Demand Waterfalls: • Map HistoricalDemandSeriesDetail (Forecasts) and HistoricalDemandActual (Actuals) • AutoCreate remaining tables • Supply Waterfalls: • Map HistoricalSupplySeriesDetail (Production Plan or Commit) and HistoricalSupplyActual (Completions or Reciepts) • AutoCreate remaining tables • Input files expecting new records only (e.g. ‘net change’ extract)

10. How to Capture Historical Data • Option 2 : Populate from data contained within RapidResponse using a Scheduled Task (formerly known as Data Change Alert) and Workbook • Create a workbook to capture appropriate Series (Plan) and Actual data • There is an out of the box workbook that can be leveraged as a starting point- S&OP Write History Records • Create a Scheduled Task to perform the capture on a scheduled event • Remember that inputs into this table are expected to be new records therefore your source worksheets have to be showing only new data • Source and Destination Worksheets must have the same type and number of columns in the same order/sequence

11. Example of Historical Demand Capture Workbook

12. Demand Waterfall Workbooks

13. Result in Waterfall Workbooks

14. Waterfall Workbook Configuration • RapidResponse includes Demand and Supply Waterfall workbooks as PDRs (Predefined Resources). • The workbooks can be configured using Macros to reference the configured Demand and Supply categories (Historical Demand/Supply Category table). See workbook filtering. Macros include: CustomerFcst_Type (Demand) SupplierFcst_Type (Supply) ShipmentType (Both)

15. Waterfall Macro Configuration

16. Before You Start – Understand Sizing • Database sizing key inputs • Number of unique part/customer or part/supplier combinations • Number categories (e.g. Forecast, Actual, Supplier Commit, Supplier Delivery) • Number of future looking buckets (e.g. 52 weeks) • Number of historical snapshots (e.g. 18 months) • Sizing ‘rule of thumb’ • Up to 100M records = 32GB server • Up to 250M records = 64GB server • Up to 500M records = 128GB server • Example: • 10,000 part/customer X 52 weeks of forecast X 80 weeks history x 2 categories (Forecast and consensus) = 83M records

17. Managing Historical Data • As you continue to populate the historical tables with more and more history, they will grow • You need to “prune” them from time to time to keep the Server “healthy” – i.e. so it doesn’t overrun memory consumption • Can create Scheduled System Tasks to manage deletion of older historical data utilizing Delete Data and DeleteEnterpriseData commands (Data and System Admins only)

18. What Happens If I Have to Do a Full Import? • Generally most customers use Data Update which calculates differences and processes them into the tables without deleting… • However, in cases where a Full Data Import is required generally all data within input tables is deleted • Not to worry…..Historical tables are automatically persisted in the root scenario and permanent scenarios during a full data import

19. Demo • Use ! Kinexions Historical Demand Series Population Workbook to show how data can be captured for Historical Demand Series • Site = HQ • Customer = ebikes • Part = Cruiser • As of Date = 2011-11-07