c
 





p
Assignment
Subject Code-ML0004

Q-1. Analyze the need for IT in the Retail Sector?

The retail sector in India is witnessing a huge revamping exercise as traditional

markets make way for new formats such as departmental stores, hypermarkets,
supermarkets and specialty stores. Western-style malls have begun appearing in
metros and second-rung cities alike introducing the Indian consumer to a shopping
experience like never before. India¶s vast middle class and its almost untapped
retail industry are key attractions for global retail giants wanting to enter newer
markets.

The organized retail sector is expected to grow stronger than GDP growth in the
next five years driven by changing lifestyles, strong income growth and favorable
demographic patterns, a KPMG report titled µConsumer Markets in India: the next
big thing?¶ said. The structure of retailing is developing rapidly with shopping malls
becoming increasingly common in large cities, and development plans being
projected at 150 new shopping malls by 2008.

According to the report, the annual growth of department stores has been
estimated at 24 per cent, which is faster than overall retail; and supermarkets have
taken an increased share of general food and grocery trade over the last two
decades. Disposable incomes remain concentrated in urban areas, ³well-off´ and
affluent classes and the growing number of double-income households. However,
the report reveals that the sheer size and potential of the rural segment has been
underestimated. Rated the fifth most attractive emerging retail market, India is
being seen as a potential goldmine. It has been ranked second in a Global Retail
Development Index of 30 developing countries drawn up by AT Kearney. The list
was developed as a response to requests from retail chains facing saturated
demand in most western markets.

AT Kearney has estimated India¶s total retail market at US$ 202.6 billion which is
expected to grow at a compounded 30 per cent over the next five years. With the
organized retail segment growing at the rate of 25-30 per cent per annum,
revenues from the sector are expected to triple from the current US$ 7.7 billion to
US$ 24 billion by 2010. The share of modern retail is likely to grow from its current
2 per cent to 15-20 per cent over the next decade, analysts feel. No wonder a
heavyweight like the Reliance group is planning to do a Wal-Mart in India.

In the next couple of years, India will see at least two Indian retail businesses
attaining the magic figure of US$ 218 million in sales. Several others are expected
to attain a critical mass as growth in the industry picks up momentum. This will be
driven by four key factors.

Availability of quality real estate and mall management practices. Consumer

preference for shopping in new environs.The world¶s largest retailer Wal-Mart has

p
 c
 




p

huge plans for India. It is moving a senior official from its headquarters in
Bentonville, Arkansas, to head its market research and business development
functions pertaining to its retail plans in India. New York-based high-end fashion
retailer Saks Fifth Avenue has tied up with realty major DLF Properties to set up
shop in a mall in New Delhi.

Challenges in the Retail Industry

Ú
 

 



 



 








 
  
 



The retail industry faces challenges similar to those in other industries. What¶s
different is that they combine together to put a great deal of pressure on retailers
in today¶s modern economy. With a fast-paced society and faster-paced
technological changes, customers want new, different, and customized goods now,
and they¶re not willing to wait.

At the same time, pressures on the backend are mounting, too. Larger retailers,
with their efficiencies of scale and international scope, are pushing prices down and
slashing margins. To compete, you have to think like a Wal-Mart, even if you are a
medium-sized retailer. Technology offers your company a way to apply modern IT
techniques on a global scale, whether through bricks-and-mortar stores, or over the
Internet.

Q-b. Write note on e-Fulfillment

Definitions of e-Fulfilment are wide and varied and range from ³core physical
delivery to the customer´ to ³warehouse, pick and pack and call centres´. The term
µfulfilment¶, as such, describes a horizontal tier of services from the beginning of a
job through delivery to distributors or end users. In other words, it refers to the
challenges that take place after the ³Buy´ button is clicked.

In the framework of e-Thematic, the following definition of e-Fulfilment is used:

Ú











  


 
 
 





  

 


 

 




The e-Fulfilment process

E-Fulfilment refers to more than setting up an Internet-enabled front-office. It

entails the integration of the website with all the back-office processes, activities
and functions (marketing and sales, finance and logistics) that support the
fulfilment of customer orders.

p
 c
 




p
The following figure illustrates the back-office processes that take place after the
³Buy´ button has been clicked.

e-Fulfilment process

The sequence of events is: order capture (web order) > stock availability check (e-
warehousing) and interface to finance house (e-billing) > order confirmation >
manufacturing or procurement (not studied by e-Thematic) > order release
(picking/packing/shipping) and final delivery to the customer. Most of these
processes can be executed internally or externally.

Scope of e-Fulfilment

· The scope of e-Fulfilment includes companies with an online retailing presence

that are adapting e-Fulfilment applications (whether their business is old economy,
new economy or a mixture of those two), and software vendors providing e-
Fulfilment applications.

· Both the Business-to-Consumer (B2C) and Business-to-Business (B2B) areas will

be addressed.

· Regarding the integration of back-office activities, the focus of

e-Thematic will be on the operational level. Manufacturing and procurement are
related to the front-end of the supply chain and will thus not be studied by e-
Thematic.

2.Briefly Explain the retail planning Function.

Planning Functionality

p
 c
 




p
Action Messaging

· Order tracking, with its simultaneous creation of action messages (AM), is not a
part of the planning system. This feature interlinks, in real-time, the requirements
and the quantities that could cover them, whenever a new requirement or
replenishment order is created or changed.

· If, for example, the user enters or changes a sales order, order tracking will
instantly search for an appropriate supply to cover the demand. This could be from
inventory or an expected replenishment order (such as a purchase or production
order). When a supply source is found, a link is created between the demand and
the supply. If all of the demand cannot be covered, order tracking will create an
action message suggesting what the user could do to address the situation.

· AM are stored in a separate table. The user can retrieve and view them in the
planning worksheet by running the Get Action Messages batch job.

· AM offers a quick response but less comprehensive plan than the planning system.

Differentiating between Planning and Action Messaging

At a quick glance, it may be difficult to differentiate between planning and action

messaging. Both features display their output in the planning worksheet. The
output suggested actions for the user to take is similar but the way this output is
produced differs.

· The planning system deals with the entire supply-demand pattern of an item
through all levels of the hierarchy, whereas order tracking only addresses the
situation of the order that activated it.

· When balancing demand and supply, the planning system creates links in a user
activated batch mode, whereas order tracking creates the links automatically and
on the fly whenever the user enters a demand or a supply in the program (for
example, a sales or purchase order).

Order tracking establishes links between demand and supply as data is entered, on
a first-come basis. This may lead to some disorder in priorities. For example, a
sales order entered first but with a due date next month may be linked to the
supply in inventory, while the next sales order due tomorrow may cause an action
message to create a new purchase order to cover it.

The planning system, on the other hand, deals with all demand and supply orders
for a particular item, in prioritized order according to due date. It deletes all links
that were created dynamically and reestablishes them according to due date
priority. When the planning system has run, it has solved all imbalances between
demand and supply. No action messages remain in the Action Message Entry table,
as they have been replaced by the suggestions in the planning worksheet.

p
 c
 




p
Concepts in Brief

The planner of a company, the purchaser or production planner is presumed to be

the user of the planning system. The overall problem that the planning system
should resolve is to suggest which actions the user could take to ensure that
customer demand is met. It can be a cumbersome task when working with many
items. This task increases to a staggering level when you include production due to
derived demand that has spread down through the BOM hierarchy.

The planning system assists the user by performing the extensive but rather
straightforward calculations of a plan. The user can then concentrate on solving the
more difficult problems, such as when things differ from normal.

The planning system is driven by anticipated and actual customer demand such as
forecast and sales orders. Running the planning calculation will result in the
program suggesting specific actions for the user to take concerning possible
replenishment from vendors, transfers between warehouses, or production. These
suggested actions could be to create new replenishment orders (purchase, for
example). If replenishment orders already exist, the suggested actions could be to
increase or expedite the orders to meet the changes in demand. Another goal of the
planning system is to ensure that the inventory does not grow unnecessarily. In the
case of decreasing demand, the planning system will suggest that the user
postpone, decrease in quantity or cancel existing replenishment orders. Parameters
that the user sets for an item or a group of items control which actions the planning
system will suggest in the various situations.

Reservations Are Not Considered

The program does not include any reserved quantities in the planning calculation.
Take the example of a sales order that has been totally or partially reserved against
the quantity on inventory. The reserved quantity in inventory cannot be used to
cover other demand. Also, since the sales order was reserved manually, the
planning does not include this requirement, and its corresponding fulfillment, in its
calculation.

The planning system prioritizes according to shipment date since that is the best
way to ensure the lowest possible inventory. Manual reservations tend to prioritize
according to order entry date.

The figure below illustrates how reservations can hinder the most feasible plan.

Forecast and Blanket Orders

Forecast and blanket orders both represent anticipated demand. The blanket order,
which covers a customer¶s intended purchases over a specific period of time, acts to
lessen the uncertainty of the overall forecast. The blanket order is a customer-
specific forecast on top of the unspecified forecast or vice versa.

p
 c
 




p
Order Tracking

Order tracking can be considered as a tool that assists the planner in assessing
whether or not to accept replenishment suggestions. From the supply side, a
planner can see which requirement has given rise to the replenishment and from
the demand side, which replenishment should cover the requirement.

Order tracking links order network entities. Examples of order network entities are
sales orders, item ledger entries, purchase orders and anticipated or realized
inventory transactions. Forecast or safety stock quantities are not considered order
network entities, and are not included in order tracking. The reorder point also
represents some sort of forecast, so it is not included either.

Multi-locations

Companies that operate at more than one location may need to plan for each
location individually. For example, an item¶s safety stock level, as well as its
method of replenishment, may differ from one location to another. In this case, the
planning parameters must be specified per item and also per location.

A stock keeping unit can be regarded as an item at a specific location. If the user
has not defined a stock keeping unit for that location, the program will default to
the parameters that have been set on the item card. The program calculates a plan
for µactive¶ locations only where there is existing demand or supply for the given
item.

Which Items Should Be Planned?

Basically, all items should be planned for in one way or another. In reality,
however, there is no reason to calculate a plan for an item unless there has been a
change in the demand or supply pattern since the last time a plan was calculated.

If the user has entered a new sales order or changed an existing one, there is
reason to recalculate the plan. Other reasons include a change in forecast or the
desired safety stock quantity. Changing a bill-of-material by adding or removing a
component would most likely indicate a change, but for the component item only.

In the case of multi-locations, the assignment takes place at the level of item per
location combination. If, for example, a sales order has been created at one
location only, the program will assign the item at that specific location for planning.

The reason for selecting items for planning is purely a matter of system
performance. If no change in an item¶s demand-supply pattern has occurred, the
planning system will not suggest any actions to be taken. However, the program
would have to perform the calculations anyway in order to find out, and that would
drain system resources.

p
 c
 




p
The planning options are:

· Regenerative plan: calculate all selected items, whether it is necessary or not

· Net change plan: calculate only those selected items that have had some change
in their demand-supply pattern and, therefore, have been assigned for planningIn
addition to these considerations, the planning system only plans for those items
that the user has equipped with appropriate planning parameters. Otherwise, it is
assumed that the user will plan the items manually.

Loading the Demand into the Inventory Profile

The normal types of requirements are loaded into the inventory profile type-by-type
and record-by-record. A requirement could also be negative (the program does not
prevent that). This means that it should actually be considered as a supply but,
unlike the normal types of supply, we regard this type of supply as µfixed¶ the
planning system can take it into account, but it does not suggest any changes to it.
Besides the normal requirements, the planning system deals with two specialties:

· Safety stock

· Production order components

In practice the safety stock can be used to cover requirements if needed, but in
theory, safety stock is not considered a source of supply in the planning calculation.
In fact, the safety stock should remain untouched, and the planning should ensure
that it is also replenished, if necessary. Consequently, the planning system enters
the safety stock quantity into the demand profile as a special requirement (at the
starting date of the period). When handling production orders, the planning system
must monitor the component lines, which represent requirements, before loading
them into the demand profile. Component lines that result from an amended
production order will replace those of the original order. In this way, the planning
system ensures that the component lines are not duplicated.

m
  

 
 


 
 

 
 




 
  
 


  

 
 
 



 
  !"



The following areas as most likely to result in budget overrun.

Training - Training is the near-unanimous choice of experienced ERP implementers

as the most underestimated budget item. Training expenses are high because

p
 c
 




p
workers almost invariably have to learn a new set of processes, not just a new
software interface. Worse, outside training companies may not be able to help you.
They are focused on telling people how to use software, not on educating people
about the particular ways you do business. Prepare to develop a curriculum yourself
that identifies and explains the different business processes that will be affected by
the ERP system. One enterprising CIO hired staff from a local business school to
help him develop and teach the ERP business-training course to employees.
Remember that with ERP, finance people will be using the same software as
warehouse people and they will both be entering information that affects the other.
To do this accurately, they have to have a much broader understanding of how
others in the company do their jobs than they did before ERP came along.
Ultimately, it will be up to your IT and businesspeople to provide that training. So
take whatever you have budgeted for ERP training and double or triple it up front.
It will be the best ERP investment you ever make.

Integration and testing - Testing the links between ERP packages and other
corporate software links that have to be built on a case-by-case basis is another
often underestimated cost. A typical manufacturing company may have add-on
applications from the major e-commerce and supply chain to the minor sales tax
computation and bar coding. All require integration links to ERP. You¶re better off if
you can buy add-ons from the ERP vendors that are pre-integrated. If you need to
build the links yourself, expect things to get ugly. As with training, testing ERP
integration has to be done from a process-oriented perspective. Veterans
recommend that instead of plugging in dummy data and moving it from one
application to the next, you should run a real purchase order through the system,
from order entry through shipping and receipt of payment the whole order-to-cash
banana preferably with the participation of the employees who will eventually do
those jobs.

Customization - Add-ons are only the beginning of the integration costs of ERP.
Much more costly, and something to be avoided if at all possible, is actual
customization of the core ERP software itself. This happens when the ERP software
can¶t handle one of your business processes and you decide to mess with the
software to make it do what you want. You¶re playing with fire. The customizations
can affect every module of the ERP system because they are all so tightly linked
together. Upgrading the ERP package no walk in the park under the best of
circumstances becomes a nightmare because you¶ll have to do the customization all
over again in the new version. Maybe it will work, maybe it won¶t. No matter what,

the vendor will not be there to support you. You will have to hire extra staffers to
do the customization work, and keep them on for good to maintain it.

Data conversion - It costs money to move corporate information, such as

customer and supplier records, product design data and the like, from old systems
to new ERP homes. Although few CIOs will admit it, most data in most legacy
systems is of little use. Companies often deny their data is dirty until they actually
have to move it to the new client/server setups that popular ERP packages require.

p
 c
 




p
Consequently, those companies are more likely to underestimate the cost of the
move. But even clean data may demand some overhaul to match process
modifications necessitated or inspired by the ERP

implementation.

Data analysis - Often, the data from the ERP system must be combined with data
from external systems for analysis purposes. Users with heavy analysis needs
should include the cost of a data warehouse in the ERP budget and they should
expect to do quite a bit of work to make it run smoothly. Users are in a pickle here:
Refreshing all the ERP data every day in a big corporate data warehouse is difficult,
and ERP systems do a poor job of indicating which information has changed from
day to day, making selective warehouse updates tough. One expensive solution is
custom programming. The upshot is that the wise will check all their data analysis
needs before signing off on the budget.

Consultants ad infinitum - When users fail to plan for disengagement, consulting

fees run wild. To avoid this, companies should identify objectives for which its
consulting partners must aim when training internal staff. Include metrics in the
consultants¶ contract; for example, a specific number of the user company¶s staff
should be able to pass a project-management leadership test similar to what the
consultants have to pass to lead an ERP engagement.

Waiting for ROI ± One of the most misleading legacies of traditional software
project management is that the company expects to gain value from the application
as soon as it is installed, while the project team expects a break and maybe a pat
on the back. Neither expectation applies to ERP. Most of the systems don¶t reveal
their value until after companies have had them running for some time and can
concentrate on making improvements in the business processes that are affected
by the system. And the project team is not going to be rewarded until their efforts
pay off.

Post-ERP depression - ERP systems often wreak cause havoc in the companies
that install them. In a recent Deloitte Consulting survey of 64 Fortune 500
companies, one in four admitted that they suffered a drop in performance when
their ERP system went live. The true percentage is undoubtedly much higher. The
most common reason for the performance problems is that everything looks and
works differently from the way it did before. When people can¶t do their jobs in the
familiar way and haven¶t yet mastered the new way, they panic, and the business
goes into spasms.