PROJECT PROPOSAL

Demand Forecasting System for Products

Group Members (with email, most frequently checked)

• Shahid Iqbal Baig (shaid23pk@yahoo.com)

• Khurram Shehzad Khadim (gujratone@hotmail.com)
• Adeel Ahmad (adeelahmad9@hotmail.com)

Internal Advisor

• Dr. Khawar Zia

External Advisor (including company employed in, designation and email)

• Mr. Sohaib Umer (sebi@nexlinx.net.pk)

1
Problem Statement
To develop a system that will forecast product demand for
• multiple products
• multiple customers
of “Lever Brothers of Pakistan”, based on historical sales data.

Objective
To help the above mentioned company in planning future productions of different products while
minimizing inventory holding cost.

Description
Beneficial Definition:
Virtually every manufacturing or service company needs to generate forecasts of their short to
medium term sales. Being able to forecast demand more accurately has major commercial
advantages, whether the forecast is used:

1) to plan purchasing, production and inventory,

2) as the basis of marketing or sales planning,
3) Or for financial planning and reporting or budgeting.

• WHAT MAKES MARKETS DIFFICULT TO FORECAST?

SUMMARY: The dominant characteristic of real world markets is probably "NEVER

THE SAME THING TWICE" that makes it difficult for the forecasters to forecast.

In real world markets, many factors conspire to make accurate forecasting difficult to
achieve.

In the first place, sales forecasts are frequently used for all the purposes suggested in the
above mentioned definition. Examples are the different role of the profit forecast
(probably conservative) and the sales plan (probably optimistic), or where marketing
expenditure is closely associated with the turnover of brands (and therefore leads to
defensive forecasting to protect planned marketing spends). There are also conflicts in
terms of which units should be forecasted - orders-based for production forecasting and
invoice-based for financial forecasting.

Similarly, forecasts by week by “stock keeping unit” for the next 12 weeks may be
required by production planning. But, this time horizon is far too short and this level of
detail is potentially much too great for marketing and sales planning purposes.

The important point is to have a clear vision of who the primary Customer or Customers
of the forecasts are. Select the appropriate level of detail and time horizon accordingly
and accept that secondary customers will probably have to accept sub-optimal forecasts.
In many situations it is helpful for both Marketing and Sales to generate sales forecasts.
Sales are often more likely to possess the detailed short term knowledge whilst Marketing
need to 'own' the forecasts as a result of their role as brand profit 'custodians', and

2
 possibly have a clearer knowledge of longer term influences. It is vital here that each area
is clear about the role and purpose of the forecasts they produce, and that issuance
schedules optimize the currency of the data used as inputs, and given as outputs, by each
forecaster.

The second major difficulty of forecasting in real world markets is the very nature of
these markets. They frequently exhibit some or all of the following characteristics:

1) Frequent promotional activity

2) High level and variety of competitor activity
3) Promotions are seldom at the same time each year
4) The size of the distribution 'pipeline' tends to vary
5) Growing concentration in sales to biggest customers
6) Fluctuating positioning at point of sale - between 'value' (i.e. low prices) and
'added value' (i.e. quality)

This makes it hard for traditional forecasting approaches such as statistical methods to
provide acceptable results over a short to medium time horizon.

• CHOOSING THE RIGHT FORECASTING METHODOLOGY

SUMMARY: Real world markets are difficult to forecast using statistics because the
events which drive variations in sales are always different.. Also, customers respond to
events differently through time. Their buying behavior is behavioral, rather than
mechanistic in nature.

All statistical methods either even out the peaks and troughs in sales history to produce
trend-based forecasts, or else they look for repeated patterns in the historical peaks and
troughs to make future forecasts.

However, if the peaks and troughs in the sales of real-world products are caused by what
are often 'random' events, such as promotions or competitor activity, how can statistical
methods help you forecast? On the one hand, a smoothed forecast has little value if the
primary purpose for forecasting is to predict the short term sales peaks and troughs. On
the other hand, how valid is the second approach given the random nature of historical
peaks and troughs?

If you cannot use statistics, what can you use? In the majority of situations, informed
judgment (or 'finger to the wind' as cynics might describe it) is actually more likely to
produce better results within fmcg markets.

The essence of judgmental forecasting is the application of the business manager's

knowledge and interpretation of past events and activities, and their effects on sales, to
planned future events and activities. The result is a 'judgmental' forecast for the future
sales periods.

3
 The key factors to consider are fairly well known:

• Trade promotions

• Launch / re-launch activity

• Promotions / special packs

• Historical out of stocks

• Distribution changes

• Seasonality (if relevant)

• Competitor activity

• Advertising effect

• Market trends

Although there is never the same thing twice, developing and using an understanding of
how sales respond to different types and combinations of events is the most effective way
of generating a forecast. It has spin-off benefits too, because it forces marketing and sales
people to think long and hard, and hopefully objectively, about which factors really drive
their sales.

The method most likely to succeed is forecasting from the 'bottom up', and reviewing
from the 'top down'. This means generating the forecasts at the lowest (relevant) level of
detail using the process described above: the 'bottom up' method. One then compares how
the resulting forecasted year on year growth rates and Moving Annual Totals compare to
expectation, historical or current growth rates and Moving Annual Totals. If the 'bottom
up' results are out of line with the 'top down', then the 'bottom up' forecasts need to be
revisited to identify the sources of the difference.

This process must continue until the 'top down' and 'bottom up' forecasts are consistent.

CURRENT SYSTEM

SUMMARY: Use of spreadsheets is clumsy and labor intensive while terminal based
midrange or mainframe systems and ERP options tend to be inflexible, and do not
provide the variety of instant graphical views that a PC based system makes possible.

The forecasting methodology recommended in this article places a lot of emphasis on the
knowledge and judgment of the forecaster. This is unavoidable given the nature of the
market, but it follows that developing a good forecast is a labor-intensive process.

Computer systems can help here, by providing the forecasters with a productive and
flexible environment in which to analyze and manipulate numbers. A lot of companies
use spreadsheet based systems. Some use systems that have been developed to run via
terminal emulation on their corporate midrange or mainframe machines. Finally, some
use the option from their ERP (Enterprise Resource Planning) system.

4
 None of these approaches are ideal.

Spreadsheet based systems are generally difficult to maintain, in terms of adding new
products or customers, updating actual or rolling forward years. They also tend to show
the data in fixed views due to the fixed rows and columns structure of spreadsheet
programs. Some analytical capability can be introduced by building clever spreadsheet
macros, or by users reformatting data in different ways within their spreadsheets, but this
approach tends to be clumsy and labor intensive. In addition, aggregation of data across
products and customers tends to require considerable manual processing.

Terminal based midrange or mainframe systems and ERP options overcome the
maintenance problems but tend to be inflexible, and do not provide the variety of instant
graphical views that a PC based system makes possible. In addition, such systems can
sometimes have performance problems - where transaction processing systems and
decision support systems operate on the same host, transaction processing systems
necessarily get preference in receiving processor time. In addition, it is hard to give
terminal based systems the degree of user-friendliness which sales and marketing users
generally prefer.

PROPOSED SYSTEM

These traditional approaches offer elements of the ideal approach; one really needs a
system which combines the ease of maintenance and robustness of the mainframe / ERP
approach with the speed, flexibility, graphics and user friendliness of the PC.

Methodology

• OOAD
 Documents
1) Use Cases:
The scenarios that provide a description of the system will be used.

2) Sequence Diagrams

3) Class Diagrams
4) Object Diagrams

Technologies

• Waterfall Model with Prototype Demo

Software and Tools

• JBuilder for JAVA

• Oracle 8.0i

5
Hardware Requirements

• Server
Minimum 233 MHz processor
Minimum 64 Mb of RAM
Windows NT 4.0 / Windows 2000 Server

• Workstations
Minimum 233 MHz processor
Minimum 64 Mb of RAM
Windows NT 4.0 Workstation / Windows 2000 Professional

• Intranet Infrastructure
Ethernet Cards 10/100 Mbps
Shielded Twisted Pair Cable
Hub

Cost Benefit Analysis

The costs involved in project are:
• Hardware
Type Units Total Cost
Ethernet Cards 3 900
Cable 25 ft 175
Hub 1 500

• Time
Members => 3
Hours Worked Per Week Per Member => 5 hrs.
Total Hours Spent Per Week By The Team => 3 * 5 = 15 hrs.

1) Project – I

Analysis
Time Span => 4 weeks
Total Time Cost => 4 * 15 = 60 hrs.

Design
Time Span => 4 weeks
Total Time Cost => 4 * 15 = 60 hrs.

Prototyping
Time Span => 4 weeks
Total Time Cost => 4 * 15 = 60 hrs.

Tool Learning
This task uses the same time frame as “Analysis” but has a different time cost.
Hours Worked Per Week Per Member => 2 hrs.

6
 Time Span => 4 weeks
Total Time Cost => 4 * 3 * 2 = 24 hrs.

2) Project - II

Development
Time Span => 4 weeks
Total Time Cost => 4 * 15 = 60 hrs.

Documentation
Time Span => 4 weeks
Total Time Cost => 4 * 15 = 60 hrs.

Testing
Time Span => 4 weeks
Total Time Cost => 4 * 15 = 60 hrs.

Work Schedule