Page 2 9B06E020Refineries manufactured end products, such as gasoline, diesel, chemicals, lubricants and heating oil.These products were delivered to customers through a transportation and delivery network that wascoordinated with the manufacture and marketing of the products to commercial clients, while servicestations sold oil and gas products directly to retail consumers. Because of the integrated nature of the oiland gas companies that dominated the Canadian marketplace, information and decisions were coordinatedacross operations. Actions in the upstream could significantly affect the downstream activities and viceversa, which necessitated, for example, coordinating production levels at the refineries with transportation,storage, marketing and sales groups.SHELL CANADA LIMITEDIn 2003, Shell Canada Limited was one of the largest integrated petroleum companies in Canada, a leadingmanufacturer, distributor and marketer of refined petroleum products and the 14th largest company in thecountry. Shell Canada, headquartered in Calgary, Alberta, employed 3,850 people, and reportedconsolidated earnings of $810 million on $9.5 billion in assets in 2003. Ownership of Shell Canada wassplit between public shareholders (22 per cent) and Shell Investments Limited (78 per cent). ShellInvestments Limited was wholly owned by Shell Petroleum N.V. of the Netherlands, which in turn wasowned by The Royal Dutch/Shell Group based upon a 60/40 split in group interest (see Exhibit 1). ShellCanada operated independently but could draw upon resources and expertise of the Service and OperatingCompanies of the Shell Group as needed. For example, if key people or technology were not availablewithin Shell Canada, they could be sourced from other members of the Shell Group in the United States,Europe or worldwide.Fuels and Lubricant Market PolarizationBy 2002, there was a growing awareness, fueled by reports both internally at Shell Canada and fromoutside consulting organizations, of a shift in the Canadian marketplace for fuel and lubricant products.The net effect of this shift was a growing downward pressure on margins that were predicted to continue toworsen into the future. As David Raynor, senior manager at Shell Canada pointed out: What was happening with our customers was that our traditional value proposition, which was all about quality, loyalty, trust, and competitive price, was becoming less attractive to the kinds of customers we do business with and indeed we were seeing a polarization happen.In the past, Shell’s customers for lubricants and fuels had balanced the need for quality service andreasonable prices in a relationship built upon trust. These customers were not excessively price-sensitiveand valued Shell’s products and services equally. This segment represented the vast majority of Shell’straditional customer base, but in recent years this group was disappearing as two very different customergroups emerged. One customer group was highly price-sensitive and treated fuels and lubricants as acommodity product that did not require valued-added consulting in order to fully take advantage of theproducts in their respective operations (referred to within Shell as “transactors”). The other customer groupwas price-insensitive and valued the Shell brand of products but required additional consulting services tomaximize the use of those products within their operations (referred to within Shell as “progressives”).The vast majority of Shell’s customers (95 per cent) were transactors. The transactors were broadlyrepresented by agricultural, road transport, aviation, rail and marine customers. The transactors simply
Page 3 9B06E020wished to obtain a commodity product as easily as possible for the lowest possible price. The progressiveswere not as price-sensitive and instead looked for added value in the form of additional consulting servicesto improve the efficiency of their operations. This segment was broadly represented by medium-sizeoperations in manufacturing, regional transportation, drilling and some larger operations in mining andpulp and paper. The valued-added services offered included consulting on the most effective lubricant touse and the most efficient lubrication schedule to follow in order to maximize the life of operationalequipment. The transactors were concerned about the cost per litre of Shell’s products and the cost pertransaction. The progressives were more concerned with the cost per unit of output in their respectiveoperations, and thus looked to Shell for services that increased those operational efficiencies.Although the progressives were a small percentage (five per cent) of the total customer base, they weresignificant since they typically made large purchases that were profitable for Shell and there was potentialfor further profit margin expansion with this group. However, because the majority of customers weretransactors (or moving toward being transactors), addressing the needs of this group, with their largerquantity of smaller lower margin sales, was critical.The Agricultural SegmentHistorically, the agricultural segment consisted of small and medium-sized operations, often family-based,that worked independently to bring their products to market directly or through various cooperatives.However, this segment changed dramatically with the formation of coordinated networks of producers, andwitnessed an increased consolidation of farms to produce the business-class farm operation. This shift tolarger, more capital-intensive operations was accompanied by an increased demand by these businesses forbundled products and services and an increased reliance on new technologies (e.g. the Internet and theGlobal Positioning System, or GPS). The business-class farm was rapidly replacing traditional farmingoperations. Accompanying this business shift was a focus on cost savings. The purchase of fuels andlubricants was viewed as a commodity purchase by these business-class farms and thus subject to highprice-sensitivity. The increased pressure that agricultural customers were placing on Shell’s prices wasquickly eroding profit margins at Shell. As Raynor explained: This was happening in different customer segments and at differing paces but over a long period of time the agricultural segment was an underperforming channel, and materially underperforming. So this was all going to the fact that the channel was going to change and I think that channel in distress was why agricultural customers were targeted first.Abandoning these customers was expected to result in a two per cent decrease in market share, whichrepresented a significant revenue stream that Shell was unwilling to lose. The agricultural customer basewas essentially a rural customer, and this remoteness provided unique challenges in managingcommunication, delivery and sales settlement for these customers. Local sales representatives throughoutthese rural areas dealt directly with the agricultural customers for placing orders and account management.The sales representatives operated in an agent capacity whereby they were paid a commission on sales.Under this model, Shell retained ownership of the customer, and the sales representative acted on behalf ofthe company for the sale of Shell-branded products. Customers appreciated this high level of service andliked dealing with a local person who was also a member of their community.
Page 4 9B06E020THE SELF-SERVE STRATEGY AT SHELLRaynor noted that the first step towards more cost-effectively serving the transactors was to shift fromdistributed local sales representatives in these rural areas to a centralized sales force located at Shell’sheadquarters in Calgary, Alberta. Customers would interact with these centrally located sales and supportrepresentatives using technology-enabled communications via phone and fax. The reduced cost pertransaction, resulting from both the streamlined processes and the more flexible sales and supportpersonnel, could then be passed on, at least partially, to the customer in the form of lower prices. Providingsuch a service required the creation of an inside sales force equipped with the tools needed to effectivelymanage the customer relationship. This information needed to be available to all members of the sales andsupport teams since the customer would no longer be dealing with just one individual. A holistic view ofthe customer data was needed so the various interactions required by sales, support, procurement anddelivery were connected to the back-end operations at Shell.Inside sales afforded significant cost savings but there was a concern that these sales might not be enoughto recover shrinking margins since the sales and support teams were still relatively expensive in light of theincreasing pressure on margins. It was also recognized that many of the interactions with customers weresimple requests for information, such as copies of invoices, order status or product and safety information.Although providing this information in a timely fashion was important, the use of inside salesrepresentatives to fulfill these requests was not necessarily the most cost-effective method.Shell had been pursuing a self-serve strategy for a number of years. This strategy began with an increasedreliance on telephone communications, then moved to electronic data interchange (EDI). Now,eCommerce technologies moved away from using people to directly address customer requests. Instead,technology was used to satisfy many of those requests. The current push for a reduction in the average costto serve customers represented a shift away from telephone and EDI technologies to more interactiveeCommerce approaches that paralleled initiatives implemented by the banks. When the banks were facedwith the increased costs of delivering services through their front counter staff they redirected theircustomers over time to automatic teller machines (ATMs) and telephone/online banking technologies forbasic transaction and information requests. Senior management at Shell envisioned that self-servetechnologies based on the phone and Web-based applications could provide similar benefits within theirfuels and lubricants division. Customers could be redirected to phone and Web-based systems for basicordering transactions and for information requests, thus reducing the need for front-line sales and supportstaff. A key technology for implementing this self-service strategy was eStore.eStoreThe initial competitor analysis showed that although there were many players in this market (e.g. ImperialOil, Irving Oil, UFA, PetroCanada and Federated Co-op), none was pursuing initiatives similar to eStore.All of them, however, were likely experiencing the same margin compression being felt by Shell withinthis segment. It was projected that eStore would salvage profit margins and potentially increase Shell’smarket share by two per cent within the agricultural segment by attracting new customers to this innovativeoffering since it would be easier to do business with Shell.Implementation of such an online system required the development of at least some of the applicationssince they were not readily available within the marketplace. Raynor suggested that the uniquerequirements and the novelty of the required technology eliminated the possibility of purchasing a solutionoff the shelf. Shell had extensive application development skills for the development of applications that
Page 5 9B06E020were mandated for use by employees. An information architecture was in place to guide the developmentand deployment of applications at Shell. The IT Security Group developed policies for the secure use ofcomputer hardware and authentication processes that were used by all systems. For Web-based enterpriseapplications, like that envisioned for customers of the fuels and lubricants division, the architecturedictated integration of at least six technologies.Initial estimates of the cost of building the application from the ground up were prohibitively expensive forsuch a novel development project. However, key members of the Calgary IT group were involved with aninitiative within Shell International to develop a generic electronic store called eCATS — ElectronicCustomer Access To Shell. The name eCATS was the internal code name for the Web platform to berolled out to Shell companies around the world. The Shell Canada IT group proposed that this system beused as the basis for the self-serve application needed in the Canadian marketplace. This approach reducedthe estimates of development costs considerably.In September of 2000, Roger Milley, then an eBusiness project manager for Shell Canada, was sent toLondon, England, to evaluate the feasibility of the eCATS project. A Canadian colleague of Milley, aneCommerce strategist, had already been in London for about a month working with the eCATS project toidentify specific functional requirements for the system. Milley, the eCommerce strategist and a seniorproject manager from the IT vendor’s Canadian office conducted a quality assurance review of the project.In concept, the design of the system appeared to be heading in the right direction, but there were challengeswith the project that posed a risk for both Shell International and Shell Canada. There was an urgent needto produce the system for markets in South America and Europe, which led to aggressive project timelines.The business requirements were reasonably well understood at a high-level but detailed analysis had yet tobe conducted. Furthermore, the international IT vendor selected for the project had two developmentplatforms to offer: one that was very mature based on old, withering technology, and one that was about tobe released based on new emerging technology. The decision regarding which technical platform to choosewas a complicated one, and it would have to involve the IT vendor’s software development lab in Toronto,Canada. Due to the proximity to Shell Canada, Shell International felt the project would best be served if itwere based out of Canada, specifically, at Shell Canada’s head office in Calgary. The location wouldprovide better access to the IT vendor and would leverage Shell Canada’s existing relationship with thatvendor. In addition, Shell Canada had already chosen the IT vendor’s new emerging technology for itsgeneral platform for eBusiness development. Shell Canada agreed to host the internationally funded projectand put several of its own people on the initiative, including Milley (assigned full-time), and Wright and aneCommerce strategist, both playing part-time roles.Most of the project team was transferred to Calgary, but sub-teams were positioned in the United Kingdom(for eBusiness program management), Holland (for application hosting and support), Australia (for userinterface design) and Toronto (for software development by the vendor using its platform). Milley wasresponsible for the Canadian project operations, including the relationship with, and the work provided by,the IT vendor. Shortly after the transfer to Canada, the project team conducted a risk analysis of thevendor’s two IT platforms vis-à-vis the urgent needs of Shell International. The team concluded that themature, withering technology was the best tactical solution for the urgent markets. The emerging platformby contrast, was going to be released too late in order for the project to complete on time.With the platform decision made, and a tighter relationship with the IT vendor in place, the eCATS teamproduced a version of eCATS by the end of February 2001. A collaborative relationship with the IT vendoremerged, and the vendor’s project manager played a key role in ensuring the deliverables were of sufficientquality and on time. The eCATS platform was then transferred to Shell’s global hosting operations inHolland and eventually implemented for markets in Holland, England and Brazil. Shell Canada could not,
Page 6 9B06E020however, implement the tactical version of the software. The main issue was that the software could onlyoperate in one language at a time. For Shell Canada, the system had to be bilingual so it could service bothits French and English customers simultaneously. Shell Canada’s needs were not as urgent as ShellInternational’s. Shell Canada preferred the emerging platform that was based on open technologies andopen standards, and it believed the new platform would make a better long-term investment.Shell International shared the same long-term goals, and a second project was commissioned to develop anew, strategic version of eCATS on the emerging platform. The new version would also be more flexiblefor tailoring eCATS to a country’s local needs (such as language and currency). The second project wasalso based out of Calgary and was led overall by Milley. The vendor’s project manager was brought backonce again to provide leadership over the development operations. This time, Milley, the ShellInternational program manager from London and the vendor’s project manager planned the project fromthe beginning. Timelines were more reasonable, resource planning was easier and the strategic platform fordeveloping the software was chosen.Two companies were targeted for the initial implementation: a wholly owned Shell International companyin France and Shell Canada. The eCATS leadership designed the project to have linkages to theimplementations in both France and Canada. This relationship was forged in the first few weeks of theproject. The goal was to be proactive in building systems interfaces and managing organizational change.In doing so, the implementation for each company could be expedited once the eCATS software wasreleased. Shell Canada went a step further and put a number of its people on the eCATS developmentproject. In addition to Milley, Shell Canada assigned software developers, business analysts, a quality/testlead and an architecture lead. As these positions fulfilled specific roles on the development project, ShellInternational covered their associated costs. Shell Canada’s implementation team by contrast, was separateand represented a cost for the Canadian company.The new version of eCATS was released in March 2002, roughly a year after the first version. A copy ofthe software was transferred to Holland as part of the deployment to France, and a copy was transferred toShell Canada’s hosting operations. This version of eCATS was subsequently installed in Shell Canada (bythe separate implementation team) as eStore in May 2002. In addition, most of the Canadian individualsworking on the eCATS project returned to Shell Canada and seeded the organization with in-depthknowledge of the platform. This approach ensured an effective way of transferring knowledge to theoperations.The eStore implementation team was led by two Shell staff members: one representing the business andthe other representing IT. In their respective roles, Kathryn Wise and Marian Mann forged a collaborativeapproach to ensure a successful transition of eCATS to eStore. In that regard, the implementation teamdecided to run the software in pilot mode for about four months as a way of working throughimplementation issues and readying the organization for a more formal launch. The transition was, by mostaccounts, smooth, and by the end of the pilot, the software and operations were deemed to be robust,reliable and ready for a larger audience.In September 2002, eStore was officially launched with marketing and promotion efforts focused ongetting customers signed up to use the system. This process was also pushed out to the localselling/distribution agents who were expected to play a role in making their client base aware of theoffering, in providing demonstrations and in guiding customers through the processes of signing up andusing the system. At the start of the project, the target was to have 2,000 customers signed up over the nextyear.
Page 7 9B06E020By involving staff through a series of projects over a two-year period, Shell Canada had successfullydeveloped a business and IT team with deep knowledge of the eStore application (see Exhibit 2).eStore Operations and ManagementTo make eStore work, an array of business and technical operations had to be put in place. On the technicalside, the services were largely influenced by the systems architecture at Shell. The design for eStore wasbroadly grouped into the front end and the back end. The front end referred to the part of the system thatthe customer would interact with in order to browse a catalogue, get price quotes, place orders, reviewreports and initiate requests for customer service. The back end of the system would provide all thebusiness logic, systems interfacing and data storage services. The architecture required numeroustechnologies to be “stitched” together in a way that would be seamless and hidden from the customer. Theapproach represented commonly accepted design conventions for Web-based development, but it led toseven of Shell Canada’s IT teams being involved. There were teams to address the desktop standard, theuser log-on single sign-on mechanism, the Web application server software, the middle-ware transportlayer, the enterprise resource planning (ERP) system, the data warehouse and reporting system, the productcatalogue system and the general infrastructure for security, servers and networking.The business operations for eStore also involved numerous teams. The call centre received calls fromcustomers using the website; business subject matter experts worked on the ERP, the data warehouse andthe product catalogue; and marketing and sales teams rolled the eStore out to customers.The eStore application was one of a portfolio of at least six other eBusiness applications; some sharedtechnologies and processes with eStore and some did not. Most of these applications came about asseparate initiatives that plugged into the eBusiness infrastructure. There were general user interfacestandards implemented along the way, but the standards evolved and were not always retrofitted on theolder applications.With the software built and rolled out at Shell Canada, Milley settled into an operational role as ITeBusiness leader. Milley and Mann worked to establish the IT operations. Initially, it was the eCommercestrategist, working with the eStore business lead team, Kathryn Wise, and former eCATS business analystswho sorted out the associated business operations. Eventually, a new position on the business side wascreated, the eProduct manager, a role assumed by Wright.Collectively, those involved with eCATS development, its implementation as eStore and the operations tosupport it, learned that interdepartmental coordination was going to be a key success factor. The Web-enabled nature of eStore was forcing integration across organizational groups that had previously existedas silos. According to Milley: If there’s one place where business people and technical people must come together in a collaborative way, it is eBusiness. Web-based applications, such as eStore, have to be very easy to use and be perceived as adding value in the context of the relationship. The simpler we make systems for users though, the more complex the backend—technically and organizationally.In recognition of the organizational challenges, the Shell Canadian contingent set up an IT operationalforum for eBusiness (see Exhibit 3). Bringing together representatives from different IT groups, ShellCanada planned a rolling two-month schedule of work. This approach helped to prevent negative surprises
Page 8 9B06E020from appearing when technical changes were moved to production. Shell Canada also put in place anarchitectural forum for eBusiness that took a longer view on eBusiness technology as a way of forecastingand planning for trends.To manage shared eBusiness assets, Shell Canada set up a common eBusiness application forum, whichbrought together eBusiness representatives from across the company. An example of such an asset wasShell Canada’s main website (www.shell.ca) that contained information on eStore and numerous otherapplications and initiatives. There was another website that allowed for secure log-on to the eBusinessapplications (https://services.shell.ca). In the case of both websites, stakeholders had a vested interest inhow they worked and how they were managed. In short, a committee managed those assets.With respect to eStore specifically, Wright and his colleagues set up ways to gather and processinformation about the rollout, by gathering information from customers, agents, inside sales and customerservice. Other sources of information included direct experience with the website (e.g. as demos weregiven to customers) and the use of statistics that revealed a more granular view of customer setup andbehavior. Those ideas were brought forward to the eStore operational meeting that included the IT supportstaff for eStore.These organizational transformations were challenging. Some forums, such as that for common eBusinessapplications, lacked a single point of accountability. Sometimes weeks or months would go by withoutmeetings. With so many people involved with eStore, anecdotal information was pouring in from all sides,and sometimes the information was contradictory. For example, some people believed the price quotefunction was performing to specification, while others were saying that it was “incredibly slow . . . but notalways.” The statistics from eStore revealed that the number of customers signing up for eStore wastracking upwards towards the target of 2,000; however, the number of customers actually using eStore wasstaying flat.During early 2003, Wright began investigating why customers were not using the system to the extentenvisioned by the organization. He headed to the field to observe the customer experience.Report from the FieldThe eStore usage data showed an interesting pattern whereby customers signed up for an account only tonot use the account again or use the system only perfunctorily. To obtain first-hand experience, Wrightbegan to accompany the local field agents as they visited their customers to see how the system was beingpromoted, to obtain feedback from customers and to observe the experience of the customer using thesystem.The feedback Wright received from customers seemed to touch on a range of issues. Some customers hadnot heard about eStore. Those who had heard about eStore expressed concerns: they preferred to deal withtheir local sales representative who knew their requirements and knew how they operated their business.These customers valued that relationship. Their sales representative had always provided excellent serviceso they didn’t see any reason to use eStore. For those customers that were aware of eStore, there wereconcerns that the online solution was no better than either placing their orders directly through the 1-800call centre or faxing orders in directly. They always had their phone calls answered promptly and theirfaxes acknowledged in a timely manner. Some even knew the people at the call centres by their first namessince they dealt with them on a regular basis. If they were going to use any technology, the phone and faxmachine seemed to be easier and cheaper than using an online system.
Page 9 9B06E020The response from the local sales agents was mixed, with some agents aggressively promoting the use ofeStore and others providing only minimal effort. Some of the agents expressed concerns that their time wasbetter spent dealing with client issues rather then promoting this new system. Others did not feelcomfortable using the system and found it challenging to show their clients how to use eStore. Customersthat were shown how to use the system signed up for an eStore account but they often never used thesystem again and just returned to placing orders in the same way they always had. There was no follow-upafter the point where they signed up for the account so many just forgot about eStore.The customer feedback convinced Wright that eStore was very different from anything the organizationhad deployed before. Jean-Marc Morin, manager of Commercial Marketing at Shell Canada elaborated: There was a realization that we may need some help, we didn’t necessarily know how to effectively market over the Internet and effectively integrate a tool like eStore with our traditional channels to market and our traditional marketing plans.It was also felt that an outside consultant would be able to act more quickly on many of the issues thatwould otherwise need to be vetted through internal processes if handled by Shell employees.Initial work on identifying potential consultants with the needed experience in deploying and marketingcustomer-facing applications resulted in the selection of a Calgary-based firm, RareMethod. Shell hademployed outside consultants in the past for technology-focused initiatives, but these firms tended to belarge consulting organizations. RareMethod, on the other hand, was a small firm focused on contemporary,interactive marketing. Ultimately, Wright felt that this organization had the unique skills and resourcesneeded to assist in this particular project.Report from the ConsultantThe request for proposal that Shell issued for consulting services focused on the need for expertise inmarketing a Web-based application. Wright and Morin felt they needed assistance in branding andpositioning the eStore offering. They recognized that such efforts required specialized tools to implementthat were not available at Shell. As a first step to meeting these marketing objectives, Keith Dundas, thestrategy/client services lead at RareMethod, conducted a user experience review of eStore and interviewedcustomers about their experience using the system. A number of issues were identified as a result of thatprocess.Some customers did not remember the link (uniform resource locator, or URL) for the eStore website orfound it cryptic and often encountered trouble when typing the Web address. If they typed the familiarhttp://<sitename.ca> instead of the secure connection https://<sitename.ca>, it appeared as if the systemwas non-responsive.There were also indications that customers were having problems remembering passwords. The passwordswere automatically generated by the system and conformed to strict security guidelines that required thepassword to be random sequence of letters and numbers and of a certain minimum length. Furthermore, thelog-in screen seemed to confuse some customers since it presented what appeared to be two separate log-inpanes. The left-hand pane was for individuals with usernames and passwords, similar to those used byeStore customers; whereas the right-hand pane was for employees who used a Shell-provided securitydevice (a key fob), essentially a piece of hardware that generated a secure pass code. Customers faced withthe choice between a log-in using “Regular UserIds” or “Security Devices” invariably chose, incorrectly,
Page 10 9B06E020the latter option since it appeared more secure (see Exhibit 4). When customers logged in to the system,they were immediately notified that their password had expired and were prompted to change theirpassword. It appeared to customers that they had done something wrong. The message required thatcustomers enter their old password and go through the process of creating a new password that adhered tostrict security guidelines.The notification messages that customers were receiving from eStore were also confusing. These messagesappeared as system messages from the back-end eBusiness systems and were sent from the eBusinessCentre at Shell and not from the eStore. Customers did not deal with the eBusiness Centre and only knewabout eStore so they often simply ignored the emails. The eStore application was part of a larger suite ofapplications that fell under the purview of the eBusiness Centre. The eBusiness Centre served as aclearinghouse for the various Web-based applications supported by Shell Canada so messages related tothese applications originated from this group. If an end-user needed to be notified concerning one of theWeb-based applications like eStore for issues like passwords or information updates, they received an e-mail from the eBusiness Centre. This practice was originally set up for the internal eBusiness applicationsat Shell, and then was replicated for the customer-facing application eStore.Customers that navigated the log-in process expressed concern that they did not know which application tochoose from the selection menu since there seemed to be a number of applications available for use.However, after trying several of applications in the list and receiving an error message saying that they didnot have access to that application they stopped trying. When employees logged in to the company’sintranet, they were provided with a complete list of the applications available in the organization. Theapplication menu used on the company intranet was replicated for customer-facing applications in theextranet.Some customers saw the value of eStore, while others felt it was cumbersome to use and in particularfound that the process of placing orders seemed to take a long time. After entering their order informationand clicking on the button to place the order, there was a long delay before a response was received fromthe system. Customers were not really sure whether their computers caused this delay, or whether it was anissue with eStore.Not all the findings were user interface-related issues. Dundas suggested that the eStore brand appeared tobe confusing to customers since the site was not really a store, in the sense that customers could connect tothe site and order whatever they wanted. Instead, there was a select product list available and an existingrelationship with Shell was required in order to gain access to the site. In addition, the store analogy did notconvey some of the more strategic functionality that would have allowed customers to streamline their ownaccounting and purchasing processes. These other benefits had not been conveyed to the customers. Inaddition to improving the value proposition for the customer, Dundas suggested that it might be possible toreward customers for their use of eStore, although this posed some legal challenges since “use” in the formof a purchase could not be a condition of participation in any promotion.THE FUTURE OF eSTOREDundas’ interviews with customers concerning their experience with eStore echoed many of the insightsthat Wright and others found during his time in the field. As Wright walked back to his office from thepresentation by RareMethod, he thought he should block off the next week to work out a comprehensiveplan for how to proceed with eStore, in light of his findings and those of the consultant. He knew thatShell’s senior management team were committed to a cost-savings strategy using self-serve technologies,but given the low usage levels they were receiving with their agricultural customers, he knew somethinghad to be done about eStore if they were to achieve this goal.
Page 11 9B06E020 Exhibit 1 ORGANIZATION STRUCTURE FOR SHELL Shareholders Shareholders Royal Dutch Shell Transport and Petroleum Company Trading Co. p.l.c. Netherlands United Kingdom 60% interest in the group 40% interest in the group Royal Dutch / Shell Group Shell Petroleum N.V. Shell Petroleum Netherlands Company Limited United Kingdom Service Companies Operating Companies Worldwide Shell CanadaSource: Company files.
Page 12 9B06E020 Exhibit 2 eBUSINESS KNOWLEDGE ACQUISITION THROUGH PROJECTS 2002 2003 2004 F irst eC A T S x3 P roject w ith S hell International x2 S econ d eC A T S x4 P roject w ith S hell International x7 x6 S h ell C an ad a eS tore Im p lem entation P roject x6 eStore >100 Shell C anada Staff A ssign ed to O perations x6 Initiatives Pilot Full R are M eth od B usiness Staff L aunch Presentation IT StaffSource: Company files.
Page 13 9B06E020 Exhibit 3 CROSS-FUNCTIONAL COORDINATION Communication Flow Among Operational Forums Common eBusiness Application Forum: •Obj: to jointly manage the shared eBusiness assets like https://services.shell.ca , www.shell.ca, user Other eBusiness administration/login, etc. •Met every 1-3 months Application Forums •Worked with a long list of urgent and longer-term ideas •Business and IT Staff from numerous eBusiness Apps eStore Operational Forum: •Obj: prioritize eStore operational issues, opportunities •Met every 1-2 weeks •Work with rolling 1-4 week plan + a long list of ideas •Business and IT Staff supporting eStore Operational Forum for eBusiness: •Obj: Plan and coordinate technological change •Met every 2 weeks •Worked with rolling 2 month plan showing who’s doing what •IT Staff from all IT departments affecting eBusiness Apps Architecture Forum for eBusiness: •Obj: Anticipate technological change •Met about every 2 months •Worked with a high-level plan showing emerging new technology •IT Staff from all IT departments affecting eBusiness AppsSource: Company files.
Page 14 9B06E020 Exhibit 4 DUAL LOGIN PANES Shell Canada Login Ouverture de session - Shell Canada Enter your username and password in the left column, then select Login. If you have a Shell provided security device use the right column instead. Saisissez votre nom d’utilisateur et votre mot de passe dans la colonne de gauche, puis cliquez sur Lancer. Si vous avez un dispositif de sécurité fourni par Shell, utilisez plutöt la colonne de droite. For Regular UserIds For Use With Security Devices Accès normal Accès avec dispositif de sécurité User ID User ID Code d’identification Code d’identification Password Passcode Mot de passe Code d’authentification Login / LancerSource: Company files.