Sample Proposal Document

PROJECT PROPOSAL Demand Forecasting System for Products

Group Members (with email, most frequently checked) • • •

Shahid Iqbal Baig ([email protected]) Khurram Shehzad Khadim ([email protected]) Adeel Ahmad ([email protected])

Internal Advisor •

Dr. Khawar Zia

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

Mr. Sohaib Umer ([email protected])

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) 2) 3) 4) 5) 6)

Frequent promotional activity High level and variety of competitor activity Promotions are seldom at the same time each year The size of the distribution 'pipeline' tends to vary Growing concentration in sales to biggest customers 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 Ethernet Cards Cable

Units 3 25 ft

Total Cost 900 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

7