Effective Product Transitions in Complex BOM Environments

This is a guest post by Jack Walsh, manager of the Kinaxis Center of Excellence for Avaya.

Avaya has been a Kinaxis customer since 2007 and has generated tremendous value from the use of RapidResponse. Over the past several years we have focused on either configuring RapidResponse to help us manage supply, demand, S&OP, product cost reduction and most recently inventory. During each phase of deployment and enhancement we have created new data fields and tables in the data model, and new workbooks and other UI artifacts, such as dashboards and scorecards, which utilize them. As our understanding of the tool and the functionality available grew, we integrated our processes and now have a robust S&OP planning process that is closed loop with write and validation steps back into SAP, our ERP backbone. The configurability and extensibility of Kinaxis RapidResponse has been key to our adoption and value capture. Prior to these enhancement phases our supply chain was run mainly through spreadsheets and individualized and siloed processes, resulting in a volatile and unpredictable situation. Our metrics were poor, limited staff were wasting time fighting fires and chasing data, and change was certainly needed. Each phase of enhancements has brought with it more accurate and timely data, allowing for the teams to use their time managing the issues as opposed to managing the data. The end result is a supply chain transformation that includes all core supply chain metrics at or better than best in class! During the past year a significant portion of our core product portfolio went through life cycle transitions, putting our new processes and tools to the test. Product transition is a critical period in any company’s business cycle. Managing this effectively has significant benefit in terms of both reduced risk of excess and obsolete inventory of the old product and their components and effective satisfaction of market demand for the new products. The focus needs to be on agility, while managing cost. We realized that much of what we had configured in RapidResponse was great for managing products during the stable portion of their life cycle, but we were missing the data and analytics necessary to understand the rate of transition between groups of products during the product transition window because we did not have sufficient visibility and analytics we were reacting to demand data too late to avoid significant costs. What we needed were the data and analytics to allow us to proactively change the forecast based on how quickly our customers were changing over to the new products. We needed the ability to aggregate data for all products codes involved in transitions, and the planners needed the flexibility to change which codes were in the old and new groups at any point. These transitions could be one new product code to one old product code, one new code to many old codes, many new codes to many old codes, or many new codes to one old code. At first, this seemed like a very complex request. In the end, we found a simple solution that gave us everything we needed, not only saving Avaya significant excess and obsolete cost, but also managed more rapid introduction of new models with significantly less effort on the part of the planners. First, we needed a way to categorize the product codes according this their transition status. To accomplish this, we added a field to the RapidResponse data model and which enabled the planners to update the new field values to A, B, C, D or E depending on the transition status of a particular product code. The old product codes were represented by an A, the new codes by B, and if necessary C/D/E would be used for additional transitions if they were all relevant to each other in the same time bucket. This solved the problem of making the groups flexible as a planner could have one A transitioning to one B, many A’s to one B, or any other combination necessary, where the only effort required to change the groups was changing the letters in that new field. User filters were created containing the codes relevant to each transition we were managing to avoid getting data for more codes than the user was expecting when reviewing any one transition. Next, we identified the types of reports we needed and built the component worksheets with embedded filters doing a lookup for this new field, returning the results for each transition category. We then brought all the data together in a single report which allowed us to the magnitude of each product transition category as a proportion of the entire product portfolio, focusing us on what was important. Once we had all the data and analytics in place, we created charts in which each transition category was represented by a different color, and displayed the volume line over the bar charts to allow the user to understand the scale of the data being displayed. Finally, we brought all the charts together in a transition dashboard. This became a very powerful tool for us as it gave us the visibility into the rate of transition on a week to week basis, allowing the planners to adapt the forecast to the ever changing ordering patterns of our customers in near real time.

Above: Example of one tab in the transition dashboard – 2 A’s and 2 B’s / Top charts are showing demand in the grey section and forecast in the white with A in blue and B in red / bottom left details which codes are A/B along with life cycle dates / Bottom right shows similar volume data at a regional level Additional tabs are included in the dashboard with charts that show percent of old and new for distributor sales out and on hand, sales funnel, new sales orders created each week, and others. The key to all of the analytics we put in place was the one new field to capture the transition category. Once we could set the embedded filters to key on that designator, we could use it for any data points relevant to product transitions, including the ones referenced above. We now had all of our normal supply chain tools enhanced to show the rate of transition. They were flexible and easy to maintain by the planners, and it was as easy as A, B, C!