Measure the Optimal Use of Blue Yonder PMM
As any retailer knows, one of the keys to success is having a competitive advantage. Competitive advantages come in all shapes and forms. The spectrum ranges from having a unique product line or marketing strategy, a cost-effective supply chain, solid vendor compliance, or providing price points aimed at gaining and maintaining customer loyalty, while managing slim margins. Yet, in order to achieve these advantages, the retailer must also possess the IT infrastructure to optimally support their business. If this optimization isn’t achieved, it often creates problems that can adversely affect the business. Any merchandising system, be it Blue Yonder PMM, MMS, SAP, Island Pacific, Oracle (Retek), etc., requires ongoing maintenance to maintain stability. It’s like buying a car. If the buyer doesn’t change the oil or rotate the tires, eventually something is bound to go wrong. RPE has developed a 5-Point PMM Optimization Model to help users better understand where they can improve the management and use of their powerful, open architecture, highly scalable system known as PMM.
There are five critical focal points to measure the optimal use of Blue Yonder PMM. RPE utilizes a 5-Point PMM Optimization Model to assess client systems based on vast experience with a variety of PMM retail clients. Based on an initial review with key IT and business users, RPE determines which of the five areas of focus will best optimize the system.
1. Functionality: Is the Blue Yonder PMM System Meeting the Functional Needs of the Users?
The key advantage to implementing an “Out of the Box” solution such as PMM is that it offers the retailer all the industry adopted functionality required to run retail operations. However, no two retailers operate the same and this makes it very difficult for software vendors to architect a solution to meet the unique needs of every retailer.
In cases like this, the retailer has two options:
(1) Change the business process to fit the solution.
(2) Change the solution to fit the need.
Option 1 is ideal, and this is where business process review and training play a very important role in the initial PMM implementation process. However, sometimes there just is no other choice but to modify the system or to build a “bolt on” solution to fill those gaps. For option 1, RPE PMM professionals work with the strategic business user community to optimally utilize the base features of the PMM system. This will be discussed in further detail as part of the “Process” section. For option 2, RPE functional and technical expertise provide a variety of services including front-end modification of Uniface forms, back-end modification of base stored procedures and packages, or the development of new “bolt on” solutions to support critical gaps.
Functionality Business Case
RPE engaged with a retailer that didn’t have the internal resources to effectively manage their complex price event structure process to support their business within the base PMM Price Management Module. The main driver of this retailer’s success was the effective and timely management of their price events. A third-party solution was implemented to derive their promotional and permanent price events, but the challenge was how to take the result and communicate it back to PMM. RPE developed custom programs to interface the third-party price event data directly into PMM which enabled the retailer to:
(1) Send price events to the store POS System to ensure prices in the system were in alignment with the merchandise tickets and promotional signage.
(2) Accurately reflect the current prices for their products in PMM.
(3) Execute the accurate and timely permanent revaluation of retail dollar value of their inventory balances.
2. Process: Does the Business Process Effectively Utilize the Base JDA PMM Functionality?
Business process design is a critical requirement when implementing a new software solution. Typically, business process design occurs in the BPA sessions conducted as part of the overall initial PMM implementation. However, business strategy changes, people come and go, and this leaves the retailer scratching their heads “How do we design/re-design our business process to fit PMM?” In some cases, it’s determined that business processes do need to change, and in other cases, it turns out to be as simple as training issues.
RPE seasoned professionals design and facilitate the right business processes to fit the base PMM functionality. Also, RPE training professionals specializing in PMM develop training documents tailored to the retailer’s specific uses of PMM, as well as conduct user training sessions.
Process Business Case
With no room for error, an RPE client was planning to change their supply chain model from de-centralized to centralized replenishment in a very short, strict time frame. The DC stocked merchandise was scheduled to come in from overseas vendors on specific dates, and without a means of replenishing the merchandise to the stores, lost sales were inevitable. The three areas of business process design related to PMM included the Transfers and Allocation Module, Purchase Order Module, and the Auto Replenishment Module. RPE managed the entire implementation process including conducting the BPA sessions, documentation of business processes, interface design and development, testing, development of custom-tailored training documents and conducting training sessions. The two key aspects for the success of the implementation were the business process design and training, especially since most of the Planning and Allocation team were new hires, and thus new to PMM. RPE enabled the retailer to meet their goals on time for the first receipt of overseas orders into their new warehouses, and ultimately, the central replenishment of product to the stores.
3. Size & Stability: Is the JDA PMM Database Properly Sized and Managed?
Every IT Department dreads these words from their DBA, “We’re running out of space!” or “The CPUs are pinned!” Even more dreadful for the DBA is the question, “How do I optimize and/or free up space without impacting the performance and/or integrity of PMM?” Unfortunately, PMM does not provide any means to purge unused historical data. To some, the easy way out is to buy more disk. Disk has become cheaper over the years, but any qualified Oracle DBA will argue that this is not the optimal solution. Eventually system performance will take a hit while it attempts to sift through mountains of old, unused data.
The PMM database model is a very well-designed structure and performs extremely well when maintained properly. It was designed to be infinitely configurable which requires a lot of supporting relational tables as well. This is where the fear comes from the DBA asking the very question, “If I purge the data wrong, or configure the wrong database settings, what are the ramifications?” The answer is simple – low performance, data integrity issues or orphaned data, and potentially the inadvertent purging of user required data. RPE Oracle Certified DBA/Developers specifically focus in optimizing the size, configuration, and performance of the PMM Oracle database, including platforms running on 10g, 11g and 12g.
Size & Stability Business Case
A retailer with concerns about the performance and rapid growth of their current PMM database, turned to RPE. The team focused on the following areas that are typical among most PMM clients: INVAUDEE, Merchandise Category Analysis (MCA), Physical Inventory Tables, Price Master Table, Transfer and PO Tables, and the SDI Outbound Tables. It’s not advisable to purge any data from INVAUDEE since it’s the backbone to PMM. RPE recommended once the client upgrades to a newer version of Oracle, to split INVAUDEE into two utilizing newer database management functionality in Oracle 10g – a compressed historic partition, and current partition. RPE conducted a one-time purge process for specific tables of concerned size including MCA and Physical Freeze tables. By conducting user review sessions with key business users, RPE was able to identify which data retention settings to configure in MCA for future on-going MCA retention, and which data to permanently purge. In addition, modifications were made to the Physical Inventory Freeze program to not include SKUs with Zero Inventory Values, which accounted for 80%+ of the freeze records. By doing so, this enabled the client to preserve all past and future freeze data without ever worrying about inflating the table size or hindering performance. Lastly, RPE developed a custom purge and archive program to periodically clean up all critical SDI Outbound tables, and archive data deemed crucial in the event of recovery. The end results of the initiative yielded significant PMM system performance gains through purging and index/partitioning efforts and reclaimed approximately 500GB of disk space by removing over a billion records of data among the various tables.
4. Integrity: Is the Blue Yonder PMM Data Accurate and Up to Date?
data integrity: 1. [The] condition existing when data is unchanged from its source and has not been accidentally or maliciously modified, altered or destroyed.
Every IT Department makes it a point to maintain data integrity. How so? Easy to say in theory, but hardly adhered to. Data maintenance in the back-end happens for a variety of legitimate reasons. Unfortunately, if not done properly, suffer the consequences. PMM’s database is a powerful, well designed structure utilizing thousands of tables, of which all are highly relational. Inadvertently update or delete something and poof, the integrity is compromised; especially when accessing certain areas of the system in the front-end that could cause errors. Even when data is not touched, there are uncontrollable circumstances that compromise data integrity including: program failures that do not complete processing, unknown bugs, etc. In either case, the data needs to be fixed and synched up. In some cases, this can be a simple fix, in others, no small feat. RPE PMM technical consultants fully understand the inner workings of the PMM database structure and have vast experience in data cleanup and synchronization within PMM.
Integrity Business Case
An RPE client had apprehensions about the inconsistencies of their data specifically within Merchandise Category Analysis (MCA), Retail Stock Ledger, and the synchronization of On Order data between the Purchase Order and Transfer Order tables and INVBALEE. RPE quickly identified the levels of MCA that were not rolling up to other levels, purge the corrupt data, and rebuild the MCA tables so that all levels matched when rolled up. The biggest issue faced in conducting a task like this is the processing time and system downtime involved. RPE completed the task without any user impact. Often, clients using PMM encounter occasional instances where Purchase Order and Transfer Order On Order positions get out of synch (not match) what reflected in INVBALEE due to a variety of reasons including:
(1) Extremely old PO On Order changed/received after the base 90-day Inventory Reject setting.
(2) Internal/external system program failures.
RPE developed automated programs that enabled the client to synchronize their Purchase Order and Transfer Order On Order positions with INVBALEE.
5. Performance: Does the JDA PMM System Run Optimally?
The last most critical piece to optimizing PMM is performance. It is important to first stabilize the PMM system before focusing efforts on tuning it up. After all, if it’s not working right, has bad data, or isn’t meeting the needs of the users, what good is making it run faster? Every retailer is different, and thus, has unique characteristics when it comes to the volume and frequency of data processing. Some have a low number of SKUs and Stores, others have a large number, but the critical thing to consider is that PMM was not designed to predict every type of processing load and thus the client is constrained by the performance of the base programs. It’s important to note that the fault cannot be placed on the software vendor. Their systems are designed to run “Out of the Box” and cater to a wide-spectrum of retail users, both big and small.
Sometimes, all that is needed is some purging of data, table partitioning/indexing, or throwing a few hints at some base code. In some instances, this just isn’t enough. The biggest fear for any client is modification of base PMM code. If done right by qualified resources and proper application change control practices, there is nothing to fear.
RPE PMM technical consultants specialize in Unix/Linux, SQL, and PL/SQL for all AIX versions and Oracle platforms including 10g, 11g and 12g. Technical professionals fully understand the inner workings of the PMM base programs, and have worked with a number of PMM clients in optimizing their system through performance tuning.
Performance Business Case
With the rapid growth of their business, a client was consistently missing their Service Level Agreements (SLAs) with the business user community. The PMM Day End jobs were beginning to run well past its allotted time. This caused other programs (i.e., data warehouse, reporting, etc.) dependent on completion of this step to finish well past the agreed upon SLA. A few areas of concern were the Day End/Week End jobs, as well as other periodic base programs including the Auto Markdown program and the Transfer Import program. RPE assisted the client in optimizing the Day End/Week End jobs by identifying jobs that were not required to run as well as tuning up those that were used. The result was a 100% – 150% reduction in processing time, and more importantly, enabling the client to meet the agreed upon SLAs. In the case of the Auto Markdown and Transfer Import program performance, a common theme was found to be the culprit. Due to the heavy volume of Permanent Markdowns at the Store Level, and Transfer Carton Receipt processing via the base import program, the processing of these transactions was not completing in adequate time for the client.
RPE found two key areas for performance improvement:
(1) The price lookup functionality in these programs.
(2) The utilization of the base Batch Upload process vs. traditional INVTRNPRC program.
By building a new price lookup program for each of these programs and implementing the base Batch Processing program, the client realized a performance gain of 700% for the Auto Markdown process and 300% for the Transfer Import process.
How Can RPE Help Reach Blue Yonder PMM Optimization Goals?
It’s important to identify the issue(s) before tackling them. Some issues may be obvious to the client, some may not. Not all the five points mentioned may be applicable to a client’s needs. After all, every retailer is different, and every retailer is at a different stage in their PMM lifecycle.
The first step is to conduct a review session with key IT and business users to help identify any pain points and categorize them under each of the five areas identified in the RPE model. RPE will then conduct a PMM Health Check based on the identified areas within the 5-Point PMM Optimization Model. The length of this phase is dependent on the size and complexity of the PMM system. In the end, RPE will provide a summary of recommendations. Based on findings, a phase 2 is recommended which will be the implementation phase of the recommendations.