1. Not having a clearly defined outcome; one that can be measured so that improvement can be detected
  2. Not having buy-in at the grass-roots level (planners, users); if your team is not on board then stormy seas lie ahead
  3. Not having an available and capable DBA available when required throughout the project (not full time... but available quickly when needed)
  4. Not having a company "owner and champion" who has appropriate authority and who stays with the project from beginning to end.
  5. Not subscribing to the KISS principle.  Keeping things as simple, basic, and attainable as reasonably possible will contribute to an easier, better implementation.
  • If your proposed implementation is using data that already exists and has been proven to be clean and complete then you can likely take on a larger Demantra project.
  • If Demantra is new to your organization and the data (both "standard" from EBS and "custom" from other sources) has not yet been vetted, then you would do well to implement your project in a two phases.
  • In the case of two phases, the the first phase is typically the "DM" phase and basic S&OP where the concentration is on:
    • quality ITEM, LOCATION, and SALES data
    • proper hierarchy levels within the model
    • forecast generation
    • simplified S&OP contributions
    • user training and familiarity
  • The second phase would then typically be advanced S&OP or PTP/DSM
    • customized S&OP if required
    • modeling the desired promotions and causal factors 
    • populating the model with known (historical) promotions
    • populating the model with an initial pass at planned (future) promotions
    • enabling promotional "forecast lift" and adjusting the engine and the model until things work 
  • The critical factor tends to be quality and completeness of data, which generally takes many cycles of import-review-diagnose-correct before it is ready for production use.
  • A typical question might be:
    • "If we are planning to implement Demantra and ASCP, which should we implement first?"
  • While there is no hard and fast answer, a guiding question might be:
    • "Are you currently feeling more pain on the supply side or the the demand/forecasting side?"
  • If your existing supply side systems (inventory, production) are operating reasonably well then you would do well to implement Demand Managment (Demantra) first.  The forecast and potentially the safety stock generated by Demantra can and should be used later to feed the supply side application (ASCP).
  • If your existing demand/forecast systems are operating well and the supply side is problematic then implementing the supply side apps first (ASCP) would be a good choice.
  • Note that if your operation is already Oracle-centric and you have EBS then ASCP will already be available as part of the suite; it would need to be configured.
  • If your operation is NOT Oracle-centric then it can be easier to start with Demantra insofar as it is more "standalone" than ASCP and can be more easily fed with data. 
  • If your organization employs promotions to distributors, retailers, or the end-consumer then you should already have a well-defined set of promotions, schedules, and rules.
  • Promotion effectiveness can be deduced to some degree from the later evaluation of demand and subsequent fulfillment.  However, more accuracy can be gained with a tracking/confirmation method (DSM = Deduction and Settlement Management).
  • In the case of DSM there needs to be a defined mechanism for customers (corporate or consumer) to provide proof/feedback on the number of promotions that have been taken advantage of.  The element of proof through purchase verification both reduces fraud and provides timely and accurate information on the effect of promotions.
  • There is a time offset between when a promotion becomes live for the customer and when production and/or shipping needs to be ramped up to meet the expected demand.
  • The combination of tracking promotions, deductions & settlement, and the forecast "lift" affects on the forecast are sufficiently complex that a well defined model can not only improve the process, it can be the mechanism that makes it entirely viable in the first place.
  • Demantra must associate a PRODUCT and a CUSTOMER in order to generate a forecast.
  • If you rarely change product names or the associations between PRODUCTs and CUSTOMERs then you are unlikely to engage in copying history (chaining) or altering associations (member management).
  • On the other hand, if you regularly change PRODUCT names (SKU names) and have to copy dozens or hundreds of combinations worth of sales history to a new set of combinations, then RapidTool will be of enormous benefit.
  • Equally, if you regularly assign PRODUCTs to new LOCATIONs due to changes in internal distribution centers (DCs), company acquisition, or sales expansions, then RapidTool will be of large benefit for member management.
  • The native Demantra ability to perform demand-history-chaining or member-management is cumbersome and not repeatable.
  • Rapidtool is browser-based and relatively easy to train.  More importantly, all actions can be saved as a script and then be tested in DEV and repeated quickly in TEST or PROD.
  • Our long experience working in the trenches left us with a wishlist of quick-n-easy tools that would simplify and shorten some implementation tasks
  • Rather than built several separate tools we built a framework of related tools; we can then augment the toolset more easily in the future
  • At the outset of a large implementation it is often true that hardware, operating systems, databases, applications, and people are all in motion.
  • For Demantra or other VCP implementers it is helpful to have an immediately available ETL tool to move and clean initial data.
  • Further, it is helpful both during and after implementation for application users and management to see the state of the data or application output without having to engage in complex Demantra, ASCP, or other training.
  • We developed the entire Zipics framework to simply pop into a basic real or virtual Windows server.  Once installed the following are enabled:
    • zipETL provides easy but capable data integration.
    • zipVIZ provides easy but capable data visualization
    • zipDB allows on-the-fly database/table creation (great for injecting data or extracting data)
    • zip3D is pending but will allow much more dynamic representation of data in 2D and 3D
    • zipDATAGEN is pending but will allow random but representative data generation for Demantra and potentially other VCP apps
    • zipPAX is pending but will allow parallel execution of large queries in a manageable way
  • The suite is low cost, quick to install, and has value for initial implementations and for later day-to-day operations