STOCK OPTIMISATION TEAM WORK - BACKGROUND AND SUMMARY FOR ZENSAR Summary of projects

Stocking Up A systems development project that supports the capital plans of the business, enabling the efficient delivery of the stocking up element of occupation during a new shop opening or relocation. To include planning, reservations and allocations of stocks through the design of a new system and reporting. The delivery of phase 1 of Stocking Up is essential as the current system would not support the opening of JL Stratford or further new format shops due to changes made to other systems that stocking up relies on. Phase 1 - Delivery for April 2011 (support Sept 2011 opening) NOTE : No deliverables agreed as yet Seasonal Stock Build Current position is that stocks are built in branches ahead of seasonal periods to smooth the flow from the DCs to meet peak sales. Standard size branches have room to hold this stock, but JL at home branches have minimal excess stock holding areas. We can hold this stock for JL at home branches in a second location, but this will come at a significant cost. The proposal will enable the DC's to act as virtual stock rooms and hold excess stock when we are pushing stock out for peak. The system will ring-fence this stock and feed it to the stores on a just in time model. Branch Merchandising Currently, branch replenishment stocks are managed within the system by calculating stock levels at a product level for all branches. The proposal will enable the Merchandising teams to focus stock management by branch rather than product level. Any excesses or shortages of stock would be instantly visible leading to more effective and efficient action plans. The current solutions work well if all branches operate the same replenishment model and had the same amount of stockroom space. However, JL at home branches are designed with minimal stock holding areas to drive the efficiencies of the operation. Currently Merchandising are finding it difficult to manage the current JL at home branches. There is a lot of manual intervention required which will require additional resource once we add more branches. Without the relevant systems to effectively manage stocks into branches, the likelihood is that JL at home branches will either have too little stock and miss sales or be over stocked, putting pressure on the operating model and space in branches. Incurring costs and additional process in the shops and head office.

Seasonal Stock Build Detailed Design

Page

FIRST PIECES OF WORK There will be a number of new modules for Seasonal Stock build and stocking up. MSKBRQB Get Reserved Figure from TMSKBRQ for product, product/branch or product/branch/type. 1. Pass in product, and optionally pass in branch or branch and type bring back RESERVE_QTY total.

MSKBRQM as per MSKBRQ for all or more than one branch. 2. Pass in product, and optionally pass in branches or branches and type bring back RESERVE_QTY for all branches or the passed branches if branches passed in.

MSKBRMB Increase or Decrease buyers Reserve Quantity and/or Outstanding Quantity 3. This is called with a reserve quantity or outstanding quantity change, a product a buyers reserve type and a reason and an indicator to say whether to set quantity to zero if not enough to satisfy negative qty. Delete TMSKBRQ row if resulting quantity and outstanding quantity 0.

MSKBRMM Increase or Decrease buyers Reserve Quantity and/or Outstanding Quantity for multiple branches 4. As MSKBRMB for more than one branch. Delete TMSKBRQ rows if resulting quantity and outstanding quantity 0.

MSKBRAP - reduce buyers reserve quantity according to priority 5. This is called with a quantity and a product. Buyers reserve quantities on TMSKBRQ are adjusted down according to reverse priority order until the quantity has been satisfied. Within the SRFs stock will be decreased so that each SRF is adjusted by a percentage of the amount which needs to be adjusted across SRFs in total. The percentage will correspond to the percentage they started with allowing for Broms. Delete TMSKBRQ rows if resulting quantity and outstanding quantity 0.

There will also be changes to existing DDM modules for Adjustment processing which will now reduce Buyers Reserve on TDDMPRD where there is not enough available DC stock. Four DDM modules: DDMB08, DDMB09, DDMB15, DDMB96 Testing Notes
For each new program or module, Zensar will be required to create a complete unit test pack. Zensar may also be required to update existing programs in which case they will be required to update the existing test pack. The test should confirm that the different paths of the program and all errors are handled as specified. The pack should include:

Seasonal Stock Build Detailed Design

documentation on the mainframe of conditions and how to run the test for each run: load files for the data (if appropriate) JCL to load, run, unload and compare the data for each run. Expected results file from each run to compare against

Page

From level B onwards the test should include a regression test which runs the old version of a program, runs the new version of a program and compares the new against the old to ensure that only expected changes have been introduced. The steps should be performed using JCL utilities recommended by Technical Support teams e.g. DB2UT for loading and unloading tables and SUPERC for comparing files. It will not be necessary to keep several versions of the test pack. Once a program or module is live, only the most recent version of the documentation and JCL should be kept. See MSK.TEST.JCL(UTRFBR*) RPL.TEST.JCL(UTF2*) for example JCL and RPL.TEST.DOC(UTRPLF2A) for an example test pack. When testing programs the developer needs to ensure they are testing that particular program rather than the modules it calls so to this end they need to set up the simplest possible test data for these rather than trying to test all the paths through the modules. Zensar will be required to correct any defects found in the system testing of their code. We will use Mercury Quality Centre to track testing and defects. Defects will be given a priority of: High if they are preventing progress on further testing or if the code was on the critical path for development, Medium if they need to be fixed before going live or Low if the code could go live without the defect being corrected but that should be done before project completion as a tidy up. Defects should be raised in the case of an error OR if the tester has identified during the course of testing that an error was made in the specification. In this case the defect should be accompanied by a specification change. Raising a defect and assigning the defect to a developer will need to be accompanied by an email or verbal notification to inform the developer that they need to look in Quality Centre for new defects or additional comments on a defect. The exception to this is where a developer is routinely checking Quality Centre for defects where we are in the thick of testing. Similarly the developer will need to inform the system tester either verbally or by mail where they have fixed or commented on a defect unless the tester is routinely checking Quality Centre.