MIC 4

Random Interface Thoughts

• Do we need an interface for SSG team?
  • No. Too many hands in the cookie jar, and especially with real time investment collections type data that could be used wrong in the wrong hands (especially if we have owner access). I would also be worried about an SSG looking at a stores competitive product.  This is similar to not giving ELK access out to Product. G 
• Do we need an interface for store owners?
  • I think so. While it would be a monumental task, I think there are a lot of advantages.  Making MIC 4.0 intuitive enough that we can roll it out to the entire owner group would be a good thing.  Administering regular round pulls and the like would be a challenge.  Maybe a version of MIC 4 that allows setting changes, but only a TSM/SM/MIC Specialist can finalize a session? Owners = Users, TSM's = Super Users, Central MIC = Admin. G
• Should 4.0 be made compliant with:  multiple browsers, tablets, Blackberrys?
  • Yes. Java should allow greater compatibility across browsers, and having a mobile version makes sense for the future. G
• ZIP Code Tool (Graphical) G

Random Team Thoughts

• Who (reps from which NAPA positions) should be involved in the specifications for the new product?  Who should make the final decision on a feature or rule?
• Consider development, qa, and production to be a role of Classification and not the BI team.  If this happens, what positions will need to be contracted for development up and to the time of release and what positions should be retained for ongoing support and development?
• I think we would need separate advisory groups, for both business and technical (user) related input. G
• Will need a person/team to communicate between the MIC side and the RPM side to ensure compatibility of new features. G
• UAP/Auto Todo/Australasia whatever it is called? G

Random Business Rule Thoughts

• Is it okay to send data generated in 4.0 to RPM on a regular basis?
• Is it acceptable/possible to combine class, percent coverage, and sales potential all into a hidden formula behind a slider?  Moving away from the simple SP calculation could present problems explaining SKU recommendations. G
• Why is owner non acceptance and the distrust of MIC so prevalent, and how can we combat that? G
• Should we adjuist the overstock logic to something closer to Excess or SCORE calculations? G
• Can we do overstock returns from POG items? G
• Once a POG item is removed from the POG, can/should we try and return it before the 24 month window? G
• Can we use MIC for non-NAPA inventory management, specifically in IBS locations? G
• Having a different template that worked with main stores in MIC 4 would be helpful (higher sales potential ranges but only on specific categories). G

Random Random Thoughts

• Where are the current training programs we have falling down, and how can we ensure better management of MIC across all stores knowing that different users are working with different goals in mind. G
• Is MIC 4.0 different enough that is should be called something other then MIC?  What advantages and disadvantages are there to retaining a known name, and the good/bad associations with it currently. G
  • Call it MAGIC - JD
  • MIC Fire: Forcasted Inventory Recommendation Engine. G
  • Phoenixutf

Jeremiah's Thoughts

• There are times (when parts are put in too early, or when sales are low) that parts might need to be held on the self longer than two years without sales.
• Some of the parts held by ignore stock period do not have that good of a chance to sell, so the rule has potential to be adjusted to be more accurate.utf