Why Demand Works is a Model for Configuration Data Management

ByShaun Snapp

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

  • What application in supply chain planning is a model of simplicity concerning its master data?
  • How does Demand Works Smoothie work concerning master data maintenance?
  • What is the imbalance between the ability to create versus update master data?

Introduction

In this article, we described the serious configuration management issues with SAP SCM. In light of this, I thought it would make sense to point out a software company that is a model of simplicity in terms of how its system is configured. This company is Demand Works. I have written rather extensively about them on the demand planning Brightwork Research & Analysis site (you can find the articles at the link). While their functionality is really outstanding (and easy to use), the way their software can accept data is also exciting to discuss. I was recently in software training and was going through an exercise that mapped import files to the application’s data structures. As I was following along in training, I began zoning out. The reason is I am not interested in performing field mapping. I want to be able to manipulate data in a SQL database for production or in a spreadsheet for demo and simulation purposes and have the applications such as this data up and serve as the basis of the model.

How Demand Works Smoothie Works

Demand Works is a straightforward concept which I think other software vendors should follow. They have a spreadsheet that has some mandatory tabs but many optional tabs. For forecasting, they allow a model to be built with just two tabs. However, more functionality is brought on-line with the addition of more tabs. The tabs have naming conventions, and the import feature in the Demand Works product called Smoothie to bring the appropriate tab to the appropriate table in the database. Why can’t more vendors work like this? The advantage is that an entire configuration model can be maintained in a single spreadsheet, and this greatly reduces the complexity of the modeling. In fact, I question the necessity of configuration interfaces entirely. All that is necessary is an interface document, a user manual, and a spreadsheet with different tabs to manage all configurations in a system. Again, once in a production environment, the configuration can be ported to a SQL database. This database can be edited (and the configuration details) edited either from a command line (for those that are old school) or with a SQL front end such as My SQL Workbench, Toad, or whatever SQL front-end the user is comfortable with. This is where configuration should go.

MySQL Workbench

For more details on MySQL Workbench and using MySQL for supply chain applications, see this blog on the topic.