Notes on Demantra
Created 04/25/10
Updated 04/28/10, Updated 05/02/10
Introduction
Demantra is a demand planning application that competes with i2, SteelWedge. It was developed by Demantra on
the East Coast, and then bought by Oracle in 2006.
It supports several modes of use:
 Demand Management
 Forecasting
 S&OP collaboration
Some of its unique features are a Bayesian forecasting engine that integrates multiple models, using Bayesian
statistics to determine the appropriate weighting of those models. This is highlighted more in 2003-era documents,
while the later documents focus mostly on data management and integration.
Some of the features include:
 Analytic engine at the core of the system
 Configurable levels and series
 Supporting a product hierarchy
 Custom “worksheets”
 Charting and dashboards
 Collaboration, including approval workflow
 Support for corporate calendars
Most of these features are fairly standard. What also appears to be an advantage is the ability to perform topdown, bottom-up, or middle-out planning.
It appears that Demantra is offered as a desktop-based application, or a web-based application. The technology is
all J2EE, and the database is Oracle.
Resources
http://www.oracle.com/us/products/applications/056849.pdf - this is a 10-page white paper summarizing the
architecture and use of Demantra for Sales and Operations Planning. Written in 2006.
http://www.oracle.com/technology/documentation/demantra.html and select document E05136-09. This is a 300page Implementation guide, for version 7.3, written in 2009.
http://download.oracle.com/docs/cd/B53825_03/current/acrobat/730dmtug.pdf - this is 294 page user’s guide for
Demantra 7.3, written 2009.
Concepts
The local structure is shown below:
Page 1 of 5
Key Elements










Worksheets: A worksheet (sometimes known as a query) is the primary user interface to Demantra data.
The data is organized in a set of multi dimensional hierarchies that enable users to slice and dice data in
any way. These hierarchies are completely configurable and are easily extended.
The Basic Input Data: item, location, sales, promotion (optional)
Time Resolution: provides three sizes of base time unit (day, week, or month) and can support hourly
time units if needed.
Levels: The first interesting feature of any worksheet view is the aggregation level or levels that it uses.
An example would be “Account level”.
Combinations: Each possible pairing of item and location is known as a combination.
Series: A series is a set of data that represents some value that varies over time or that varies between
item-location combinations
Filtering and Exceptions: Both filters and exceptions both limit the members that users can see. Filters
act directly, and exceptions act indirectly
Methods: You can define level methods, which the user sees as ordinary right-click menu options in
Demantra
Security: The Demantra data and menus are secured, so that not all users have access to the same data
and options.
Forecasting: The Analytical Engine reads data from the database, generates a forecast and performs other
analyses, and writes the forecast to the database.
Page 2 of 5
User Interface
Here is the collaboration screen
Here is a typical operations screen:
Page 3 of 5
Demantra Data Model
Looks a lot like the Serus one
What does this suggest to us for the Juliet Development?
Slice and dice – these are summation queries. For instance,
Select sum(normalizedActivity.amount) group by normalizedActivity.year, normalizedActivity.activityType
Is different from
Select sum(normalizedActivity.amount) group by normalizedActivity.activityType, normalizedActivity.year
Hence, the slice and dice logic is in the query generator.
Demantra is very flexible in this regard, and allows for managing queries into worksheets.
What types of reports/queries does JIRA support, for example?
What about rollups?
Here, we would like to get value for sales region 4, which stems from 2 child regions under sales region four, and
two splits into subchildren below that. Assume that there are normalizedActivity records at any node, and that the
tree is not traversable easily through a query.
Page 4 of 5
One approach is to pre-query the region tree, assemible it in memory, find the matching ObjectId values, and
create a summation query where the child nodes are specified in the where clause.
Page 5 of 5