Lipton Canada

INTRODUCTION

August 1997: Five months into a ten-month timeline, and Tim Pallant knew
the January 1, 1998, project deadline was in jeopardy. The team had been
unable to find a practical way to configure SAP R/3' to handle trade spending in the
flexible manner the company required. As project leader of Lipton Canada's SAP R/3
implementation team, he had to make a decision very soon on what to do next. The
basic functionality required to support this process had been identified during the
system evaluation, but prototyping had exposed that, in general usage, it would
become maintenance frightening. Now, despite the many possibilities he and his team
had explored, he could see no easy way to make it work. At this point he had identified
three alternatives, and he didn't particularly like any of them. One option would be to
rewrite a section of the SAP Rl3 software- without the appropriate functionality, the
company wasn't going to get the benefits it had anticipated. Alternatively, the company
could give up on the way trade spending was handled. The final alternative would be to
keep searching for a configured solution within SAP R/3 for a little while longer. Given
SAPS complexity, Tim wasn't fully convinced that all possibilities had been exhausted.
He didn't even want to think about the ultimate alternative-abandon SAP R/3 altogether
and quickly tackle year 2000 compliance some other way.

BACKGROUND

Lipton Canada was a division within Unilever Canada that manufactured and sold
packaged food products, predominantly to the retail trade. Becel, Red Rose, Lipton
Sidedishes, Soupworks, and Ragu were a few of its main brands. Its head office was
located in Toronto, and it operated four manufacturing plants and three
sales offices located across the country. The business case to implement SAP R/3 for
handling order management had been developed in the fall of 1996. Up to then, Lipton
had been using a highly tailored order management system (OMAR) that had been
developed in-house fifteen years earlier. By 1996 the company knew it had to either
update the existing system to make it year 2000 compliant, or replace it. While the
straight cost of updating OMAR was expected to be less than purchasing and
implementing SAP R/3, other considerations made the SAP proposal attractive. OMAR
had been continuously enhanced over the years and was finely tuned to provide
excellent support for the business needs of the day, but it was based on older
technology and would need considerable modification to support future needs. As the
system aged, integration with other, more recently acquired systems became
increasingly difficult. In addition, support and maintenance depended on the knowledge
of a small number of Lipton employees, making the company helpless to normal
turnover of personnel. Unilever as a whole had also adopted a policy of moving to
common open Systems across the company. Not only was this expected to alleviate IT
management problems such as those mentioned, but it would also support the parent
company's desire to integrate its global operations. SAP R/3 software had been
recommended by Unilever and it was already in use in over thirty Unilever operating
companies worldwide, including Lipton United States.

Even so, Lipton Canada wanted to ensure that SAP R/3 would meet the company's
specific needs in the extended order management process. During the fall of 1996 an
assessment was conducted. (Only order management was under consideration,
although other SAP R/3 modules, particularly finance, were candidates for future
implementation.) The first step was to ensure that SAP R/3 would support current
practices in order management. A high level analysis of existing processes was
conducted, and compared with SAP R/3 functionality. Several gaps were identified,
specifically for certain payment processes related to distribution, and for many EDI
transactions, but by and large SAP R/3 appeared to be a good substitute for OMAR, and
offered significant additional functionality in some key areas.

It was judged that the gaps could be handled by add-on modules, implemented at
designated "user exits" in the software. The second step was to identify strategic
initiatives in order management that were planned for the near future, and that would
require either new systems or enhancements to OMAR. If these initiatives were already
supported by SAP R/3, the cost to develop the capabilities could be avoided. The
assessment determined that in addition to providing year 2000 compliance, SAP R/3
offered flexibility in pricing, apparent improvements to the planning and execution of
trade spending, and the ability to track contribution by customer. Further, it would
enable migration from the current AS1400 platform to a UNIX environment.

THE IMPLEMENTATION

By the end of 1996 the assessment was completed. SAP R/3 appeared to match about
80 to 90 percent of Lipton's requirements, and a plan was in place to address the gaps.
A budget and timeline were established, based both on some consulting advice and on
the experience of other organizations. Ten months, while an
aggressive target, was considered feasible. In February 1997, the business case was
presented to the executive committee, and the proposal was approved. Eleven people,
six from the business and five from IT, were selected to be on the project team, with Tim
Pallant as the leader. The users chosen for the team were selected on the basis of their
competence and knowledge of their particular functional area. In Tim's words: The
argument I used with the various departments to get the right people is that these are
the people who are going to design how your department works for the next five years.
You need to release your best people to work full-time on the project, and back-fill their
positions. By and large I got the people I wanted-it was a very strong team. But that's
what you need, the senior people-a team of leaders. Tim himself, coming from the sales
and trade marketing area, was well versed in the business processes being affected,
and he also had considerable experience working with IT on various aspects of the
company's systems. To support the team members from Lipton and add specific SAP
R/3 knowledge, a well-established systems implementation consulting practice was
hired. The consulting firm assigned six consultants to the Lipton project, although this
number would vary over the life of the project. The consultants were expected to lead
the implementation, but also to provide sufficient knowledge transfer for Lipton to be
self-sufficient by the end of the project. Tim expected three things from the consultants:

1. Leadership/mentoring. Lipton had no experience with SAP Rl3, and needed the
expertise of the consultants.

2. Depth of knowledge. Whether specific individuals on the team personally knew all
the details or not, a big consulting practice had the capacity to leverage both its special
knowledge of the product and corporate experience from previous implementations.

3. Workmanship. In addition to providing knowledge and leadership, the individual

consultants were expected to be able to execute the mechanics of implementation-i.e.,
configure the software. The project team reported to the executive committee, which
had overall project oversight, and met biweekly with the Business Review Group (BRG),
senior managers who had line responsibility for the business processes being affected.
In accordance with the SAP R/3 implementation methodology, the first six weeks were
spent developing a blueprint of existing organizational processes. Unlike the high-level
analysis of processes conducted during the assessment phase, this analysis was
detailed, and provided not only a documented starting point, but was also intended to
help educate the consulting team on Lipton's way of doing business. As the Lipton users
worked on developing the blueprint, the consultants explained how SAP R/3 handled
the same processes, and indicated
where Lipton might have to alter the way it handled certain operations. In fact, to the
frustration of the team members, the consultants seemed to respond to most issues
with the phrase "SAP doesn't work that way." Before long, Lipton team members found
they weren't willing to accept this response without pushing back, demanding a fuller
explanation and more research. Once the blueprint was complete, configuration began.
For most areas, SAP R/3 processes, even where different from existing practices, were
acceptable. Because the users on the team were fairly senior, they had the mandate to
make process changes in their areas. If changes had a significant business impact (such
as altering the level of service to customers, or requiring additional resources), they
were taken to the BRG for discussion. In accordance with recommended practice, this
group was expected to provide rapid (forty-eight hour) turnaround on issues brought to
them by the project team.
In general, issues were presented to the BRG with the team's proposed solution, and for
the most part they were resolved in a timely fashion. On those occasions where the BRG
delayed making a decision or changed its mind, the team would have to reconfigure the
software, which put pressure on the completion date.

TRADE SPENDING

By August decisions had been made on how to handle most business processes. The
major exception turned out to be trade spending, where the team had run into a brick
wall. From the beginning they had known that existing processes would have to change,
but they had expected that SAP'S built-in functionality would be an improvement. For
trade spending, the SAP R/3 solution appeared to be an unacceptable step backward in
terms of both the information provided and the ease of use. Trade spending was the
process through which Lipton supported cooperative promotional work with its
customers. Lipton agreed to set aside a certain amount of money; when the customer
promoted a product through flyers or special displays, Lipton covered some of the cost.
Apart from managing the mechanics of the approval process and payment to
customers, the software was expected to support analysis of return on trade spending,
both by promotional program and by customer. Ironically, the initial assessment of the
software had suggested that SAP R/3 would address inefficiencies in the existing
process. Lipton wanted to plan and execute trade spending by individual customer. The
original system had been designed on the basis of regional planning. Numerous work-
arounds plus great flexibility
in allowance type and payment had resulted in a system that provided the desired
customer-specific functionality, but not efficiently. SAP R/3 offered customer-specific
planning and execution as part of the base system, and provided the opportunity to
simplify the overall trade spending processes.

With improved process efficiency and more effective tracking of trade spending, the
expectation was that SAP R/3 would be an improvement. That said, there was general
recognition that the approach in SAP R/3 was quite different from what the company had
been used to, and would have a significant effect on the way that customer agreements
were set up and the flow of funds tracked. For example, decisions would have to be
made on whether account managers would now be responsible for setting up and
maintaining their own agreements, and how this would affect overall control. However,
because of the overall potential that SAP R/3 offered for the customer management
process, these changes were considered worth implementing. Unfortunately, when the
team encountered the details of configuration, they realized that instead of an
improvement over the existing system, they might end up with something worse. The
original expectation was that the customer rebate agreement process in SAP R13 could
easily handle the functionality required for trade spending. Unfortunately, to do what
Lipton required increased the clerical workload dramatically. Rather than improving
efficiency, following this route would slow the process down and require increased staff
to handle the process.
Part of the increase in workload came from the required complicated, multiscreen data
entry, which not only meant the process took longer, but invited errors and update
difficulties. This was particularly problematic because the new system would operate in
real-time, so errors could have widespread ripple effects before-
and after-being corrected. After trying many different ways to configure the software
without success,
a proposal was made to create custom screens to make data entry easier. However, the
implications for long-term maintenance were not acceptable. Members of the BRG were
also unwilling to forgo some of the functionality that they felt added value both for
Lipton and for customers, but which also added to the complexity of the process.

By August, Tim felt he was facing a brick wall. The team had been working flat out,
desperately trying to come up with a solution, and stress was mounting. Deep down, he
couldn't believe that SAP R/3 was unable to handle the process in the way the company
wanted to operate. Trade marketing was not, after all, unique to Lipton, and with all SAP
W3's built-in functionality, he felt sure there was a way to make it work. Hadn't other
companies faced the same problem? He was irritated that the consultants had provided
little help on this. While they were competent enough at straight configuration, they
hadn't been able to provide much leadership on helping him assess his options, nor had
they been able to find any answers within their own organization or through SAP. Their
pat response was to change the process to fit with the software, but that meant SAP R/3
would reduce rather than add value-not what Lipton expected from its investment.
Unfortunately, time was growing short. The team was already behind schedule for going
live on January 1, and he didn't know how much longer he should ask them to keep
trying to solve the problem. Since the fiscal year ended in December, missing the
January deadline would require a much more complicated cut-over. Tim had to sort out
his options, and take a proposal to the Business Review Group and the executive
committee within the next few days.

Q Analyze the stakeholder consideration after mapping the stake holding in Lipton
Canada.
Q - Critically analyze the stakeholders communication strategy for SAP