1. DEMAND PLANNING LEADERSHIP EXCHANGEPRESENTS: The web event will begin momentarily with your host: Featuring Guest Commentators:October 16th, 2012 plan4demand

2. Goals for the Session Putting Optimization in context Business and Technology objectives Business Optimization considerations Technical Optimization considerations The Bottom line Q&A/Closing

3. Goal: Examine ways to optimize and get the best out of a JDA Demand toolset installation post go-live Objectives: Putting optimization in context Business process considerations for optimization Technical considerations for optimization The bottom line Key Take-a-ways

4. 4 In a typical optimization problem The goal is to find the values of controllable factors determining the behavior of a system (e.g. a physical production process, an investment scheme) that maximize productivity and/or minimize waste Here we will look at a given Scenario Your business has purchased, installed, and implemented JDAs Demand Planning Module (may have also included either/or/both options in Demand Classification and Demand Decomposition) Time has passed since the original implementation There is a wish list from the business on things not completed when the project went live Senior Execs in the company are not seeing the benefits they thought they would see

5. 5 Set appropriate thresholds on key forecasting metrics to find exceptions Wide enough to capture critical exceptions but narrow enough that you can actually review them all within the planning cycle Re-evaluate those thresholds periodically Focus on this region first Review Exception DFUs each planning cycle Chart Aggregate Accuracy/Error You should use the sum of absolute error (sum(abs(hist-fcst))/sum(hist)) Not just Net Error (sum(hist-fcst)/hist) You dont want to have the over and under forecasting cancel each other out, you want to know how far you were actually off

6. 6 Dont overreact to poor accuracy for one period for a single DFU It may be noise or timing of actual demand Review ALL DFUs at least once annually Bring them up in the demand workbench, and look at them Make sure the model is appropriate Make sure the history is complete and accurate Make sure you like the forecast and that it isnt biased high or low Do a portion of the total DFUs each period

7. 7 Bias is more critical than accuracy on a single DFU Constantly over forecasting by 20% is more damaging than over forecasting 30% one month than under forecasting 30% the next Abs Pct Abs Pct Fcst Absolute Pct Fcst Fcst Fcst Absolute Pct Fcst Fcst Hist Fcst Error Error Error Error Hist Fcst Error Error Error Error Period 1 500 650 (150.00) 150 -30.00% 30.00% Period 1 500 600 (100.00) 100 -20.00% 20.00% Period 2 650 455 195.00 195 30.00% 30.00% Period 2 520 650 (130.00) 130 -25.00% 25.00% Period 3 550 715 (165.00) 165 -30.00% 30.00% Period 3 550 605 (55.00) 55 -10.00% 10.00% Total 1700 1820 (120.00) 510 -7.06% 30.00% Total 1570 1855 (285.00) 285 -18.15% 18.15% In this example, a period of over-forecasting is In this example, the DFU was consistently followed by a period of under forecasting over-forecasted every period In total, the DFU was off by 120 units over In total, the DFU was off by 285 units over three periods for a Forecast Error of 7.06% three periods for a Forecast Error of 18.15% Although Error on a period by period basis was worse on the left, you can see the Net Error was better over time

8. 8 Make sure the Forecasting Algorithm is appropriate for the DFUs historical pattern Demand Classification can help significantly Each Forecasting Algorithm has a number of parameters (or levers) that you can use to affect the forecast Within a DFU model, the only way to get the best statistical model is through trial & error Moving each parameter in micro-increments and setting the values that work best with each of the parameters in conjunction If you take that to the next step and do that with each DFU using each forecasting algorithms - that is millions of potential combinations for each DFU ! Demand Classification can do those computations for you - setting the best mix of parameters for each DFU - for each model - letting you see which works best for you

9. 9 The Best" Statistical Model does not necessarily generate the Best Forecast The numbers dont always tell the whole story There is both Art AND Science involved in Demand Planning The Science is in the pure number being forecasted by the statistical model The Art comes in with analyzing the model and making sure it is the best forecast Is there market intelligence that can be incorporated ? - such as a competitors product launch of a new marketing campaign Are you expecting some cannibalization ? Is your product affected by the current economic climate ?

10. 10 A Process by which Sales History data is split into a Time-Series component and a Marketing/Special Event component Time Series Trend Seasonality Marketing Component Promotions: TV Ads, Catalogs, Displays, Coupons Price Fluctuations Cross-product effects (halo/cannibalization) Market Conditions (micro and macro) Special/Unusual Event

11. 12 There are so many things that go into generating a Good Forecast When choosing between similar forecasts, the simpler algorithm (e.g. Fourier or moving average) is often the best choice Many of the more advanced models such as Lewandowski and Holt-Winters can be very receptive to even the slightest changes in historical patterns and tuning parameters A simpler model automatically factors out a lot of the noise due to the fact that it is less complicated You can create simple spreadsheets to calculate a Fourier model of moving average and explain what is happening to all of your stakeholders ( More on this topic & FVA-Forecast Value Add analysis in a moment) There are definitely times when a more advanced model is more appropriate but it doesnt have to be a one-size-fits-all approach

12. What approach do you use to measurehow well you are Forecasting over time? Answer on the right hand side of your screen A. We use MAPE at an appropriate Lag B. We use a combination of techniques C. We compare to an nave model offline D. We use business intelligence reports E. I dont know!

13. 14 Studied 60,000 forecasts at four supply chain companies 75% of statistical forecasts were manually adjusted Large adjustments tended to be Beneficial Small adjustments did not significantly improve accuracy and sometimes made the forecast Worse Downward adjustments were more likely to improve the forecast than upward adjustmentsSource: Good and Bad Judgment in Forecasting.Fildes and Goodwin, Foresight, Fall 2007

14. 15 FVA is defined as the change in a forecasting performance metric (whatever metric you happen to be using, such as MAPE, forecast accuracy or bias) that can be attributed to each particular step and participant in your forecasting process FVA analysis also compares both the statistical forecast and the analyst forecast to whats called a nave forecast In FVA analysis, you would compare the analysts override to the statistically generated forecast to determine if the override makes the forecast better In this case, the nave model was able to achieve MAPE of 25% The statistical forecast added value by reducing MAPE five percentage points to 20% However, the analyst override actually made the forecast worse, increasing MAPE to 30% The overrides FVA was five percentage points less than the nave models FVA, and was 10 percentage points less than the statistical forecasts FVASource: Michael Gilliland SAS Chicago APICS 2011

15. 16 Comparing your Forecast with a Nave Model The Random Walk, also called the no-change model, uses your last-known actual value as the future forecast For example: if you sold 12 units last week, your forecast is 12. If you sell 10 this week, your new forecast becomes 10 The Seasonal Random Walk, uses something such as the same period from a year ago as your forecast for this year For example: if last year you sold 50 units in June and 70 units in July, your forecast for June and July of this year would also be 50 and 70 A Moving Average is also suitable to use as your nave model, because its also simple to compute and takes minimal effort. The duration of the moving average is up to you - A full year of data (12 months or 52 weeks) has the advantage of smoothing out any seasonality

16. How would you classify your level of interest in the technology behind the JDA applications? Answer on the right hand side of your screen A. Purely business functional thats ITs job High Level stuff only B. Some business some technical Mid-level stuff only C. I have a Technical background Give me those details!!*Answer will effect how technically in-depth we go for the rest of the presentation

17. 18 In the database management systems developed by the Oracle Corporation, the System Global Area (SGA) forms the part of the RAM shared by all the processes belonging to a single Oracle database instance The SGA contains all information necessary for the instance operation In general, the SGA consists of the following: Dictionary Cache: information about data dictionary tables, such as information about account, data file, segment, extent, table and privileges Redo Log Buffer: containing information about committed transactions that the database has not yet written to online redo log files Buffer Cache or "database buffer cache": holds copies of data blocks read from data files Shared Pool: the cache of parsed commonly-used SQL statements which also contains; Data-Dictionary Cache; containing tables, views and triggers Java Pool; for parsing Java statements Large Pool; (including the User Global Area (UGA))

18. 19 The Program Global Area (PGA) memory-area of an Oracle instance contains data and control-information for Oracles server-processes The size and content of the PGA depends on the Oracle-server options installedThe PGA consists of thefollowing components: Stack-Space: the memory that holds the sessionsvariables, arrays, etc.Session-Information: unless using the multithreadedserver, the instance stores its session-informationin the PGA (In a multithreaded server, this goes in the SGA)Private SQL-area: an area whichholds information such as;bind-variables and runtime-buffersSorting Area: an area in the PGAwhich holds informationon sorts, hash-joins, etc. Source: Oracle Corp 2012

19. 20 An SGA sized too small can cause disk thrashing as the SGA is cached to disk instead of remaining in-memory Oracle has gotten better about SGA management with new memory management and the all-encompassing MEMORY_TARGET parameter which can dynamically set the PGA and SGA memory sizes However, incorrect MEMORY_TARGET or override values can cause the PGA and/or the SGA to be too small The DB_CACHE_SIZE should be sized to fit largest amount of data needed to satisfy a given query This can be determined by monitoring the SGA

20. 21 In computer data storage, Data Striping is the technique of segmenting logically sequential data (i.e. a file) in a way that accesses of sequential segments are made to different physical storage devices Striping is useful when a processing device requests access to data more quickly than a storage device can provide access. By performing segment accesses on multiple devices, multiple segments can be accessed concurrently This provides more data access throughput, which avoids causing the processor to idly wait for data accesses Striping is used across disk drives in; RAID storage Network interfaces in Grid-oriented Storage RAM in some systems Source : Microsoft 2011

21. 22 Over the course of several JDA implementations we have observed that I/O bottlenecks can also occur in systems where the data is not properly striped across disks This was more of a problem in the past when array caches were smaller and volume management software was less efficient However, an incorrect implementation can still cause hotspots where disk thrashing can occur because you may end up with multiple parallel processes attempting to pull data from the same disk. Batch process related tuning Statistics can be a problem with JDA The PROCESS% tables are particularly sensitive, depending on volume of data being processed they benefit from either having NULL statistics or stored statistics based on the maximum size of the table

22. 23 Adding hints and adjusting values for the given process in the sre_node_config_props table JDA allows the option of adding Oracle hints to this table that will be added to the dynamic SQL when it is created. For example we have seen Calc Model in particular take advantage of these options. This is very dependent on the type of data you have Adjusting the Number of Nodes This is highly dependent on the hardware (amount of memory available primarily), The JDA process you are having problems with (not all of them even take advantage of the SRE) And the amount of data you are processing (We have seen as few as 3 up through as many as 20 being optimal for a given process) New in 7.6 onwards capability grid status monitor Adjusting the Java Heap size of the Nodes within the Pool With the same caveats as above with sizing being as low as 32m up to 1,536m being appropriate based on what processes are assigned to a given node pool Adjusting the number of Node Pools Most clients will want to have a node pool with a small heap size (i.e. 32mb) setup for JDAs daemon (continuous) processes (i.e. CalcModelUI, etc.) and any Stored Procedure processes

23. What would you say was biggest technical issue youve experienced with the application? Answer on the right hand side of your screen A. Batch related problems B. Systems availability (e.g. Uptime) C. None at all ! It works just fine D. Slow data refreshes on-screen E. Other

24. 25 Flexible Editor (FE) Pages and Searches need to have a periodic review Work with the functional team to identify the Search and FE pages they leverage in their current business process Adjust FE pages and searches to remove tables or search conditions that are no longer needed Capture the SQL and review it to determine if it is need of optimization FE pages could perform poorly after the data volume changes or upgrades. For example; FE page for DFUMap table viewing Page was constructed with MAP as primary table within the FE page and the DFUmap table was secondary Previous version of the app and oracle handled this fine. With the Newer version this caused excessive full table scans and caused undesirable performance and wait time A change to DFUmap as the primary table restored acceptable performance

25. 26 Enhancements in end-user and batch latency can be improved with defined housekeeping Stale or obsolete DFU views should be identified for deletion based on the following criteria; DFUView has no history records, including Zero value records in last 3 years DFU has no Histfcst records for 3 years Records in FCSTDRAFT or FCST do not exist or = 0 UDC - Lifecycle indicator value is not set indicate a New Item UDC - Dependent Demand Flag Yes A SQL script will be written to identify and mark DFUView for deletion To avoid performance issues, it is advised to remove records from certain child tables explicitly before deleting records from master tables Script Name: jda_del_dfu.sql

26. 27 Tables to consider for record deletion prior to removing DFUView records (it is recommended to delete records explicitly from its child tables) Dfumap Fcstdraft Fcstperfstatic Fittedhist Histfcst

27. 28 Introduced in version 7.7 the possibility of moving from vertical storage to a compressed format

28. Unrealistic expectations When a project team estimates the time it will take to complete the implementation, they tend to skip important activities such as organizational change management or process design Not adequately accounting for business-oriented activities While it is relatively straightforward for a software vendor to estimate how long it will take to install and set up software, it is much more difficult to predict activities that are not directly related to software such as defining business process and making decision how the software should be configured Lack of resources There are many companies that agree to a project plan with their vendor, only to find that the two parties have differing expectations of how many and what types of people will support the project Software customization Project teams will inevitably find at least a handful of functionality gaps that they would like to address by changing the software It is important to prioritize and to limit the amount of customization to help contain costs

29. Initiate a Post Go-Live assessment Preferably within 2-4 full planning cycles of Go-Live This can be done externally to prevent we put it in bias IT Systems DO have a product lifecycle too While it may not be as rapid as the cell phone market very few people are still using the very first iPhone model! Optimizing can turn a disappointing initial ROI into a better one!

30. Business Process Optimization Dont create a statistical forecast when you dont need one Get the balance right between science and art Good analytics make prioritizing effort fact based Over analyzing causes paralysis and wasted effort Setting exceptions tolerance and alerts to the level your team can cope with is critical Technical Optimization System up time is key if users cant get on they cant work Understanding JDAs integration with Oracle is important for some one within the business even if technical support is outsourced The more you customize the harder it is to support Slow FE page response can be due to badly structured querys this can be improved by greater education on data selection functionality

31. Page 32 For more information about Plan4Demand or Optimizing JDA Contact: Jaime.Reints@Plan4Demand.com