Dairy Fram Group

HKU049

Probir Banerjee prepared this case under the supervision of Eugenia Ng and Dr. Ali Farhoomand for class discussion.This case is not intended to show effective or ineffective handling of decision or business processes.

This case is part of a project funded by a teaching development grant from the University Grants Committee (UGC) ofHong Kong.

Copyright 1999 The University of Hong Kong. No part of this publication may be reproduced or transmitted in anyform or by any means - electronic, mechanical, photocopying, recording, or otherwise (including the Internet) - withoutthe permission of The University of Hong Kong.

Ref. 99/45C

1

Dairy Farm Group –Redesign of Business Systems and Processes

The year 1997 marked the beginning of a slump in retail sales for the Dairy Farm Group ofCompanies, (DFG), a major Hong Kong-based food retailer with operations in a large number ofmajor cities in the Asia-Pacific region. The economic crisis that gripped Asian countries duringthe latter part of 1997 was one reason for the downturn. A second and more important reason,one that worried DFG significantly more than the Asian crisis, was the increasing competitivepressures that DFG faced from European and US retail chains preparing to gain a foothold in thegrowing Asian market. Another concern was its low profit margins compared to its competitorsin Hong Kong and China and other retailers in Europe and the US. While DFG operated on asales-to-profit margin of 2.23 per cent in 1997 and 1.98 per cent in 1996, competitor A.S. WatsonGroup, comprised of the Park’N Shop, Watsons and Fortress chain of stores in Hong Kong andChina, had a 9.22 per cent sales-to-profit margin in 1997, up from 5 per cent in 1996. Anothercompetitor, US-based Wal-Mart, reported a 2.92 per cent margin in 1997. DFG’s businessmission was: “To be the leading food and drug store operator in sales and shareholder valuecreation in Asia-Pacific”. DFG realised that crucial to the successful pursuit of its businessmission was the need to redefine its business strategy, geared towards “sensing and responding tocustomer needs” as opposed to traditional “buying and selling”.

The shareholders were critical of the extant management’s ability to provide DFG with thedirection needed to fulfil its mission. Consequently, a new CEO was hired in June 1997. Thenew management team hired the services of two consulting firms through an “open bidding”system to independently carry out a preliminary investigation of existing systems at DFG, and torecommend solutions. The final contract was to be awarded to the firm whose recommendationswere seen as being actionable and directly contributing to the bottom line (i.e., competitiveadvantage through quantum-level leaps in customer satisfaction and shareholders’ wealth, atsignificantly reduced costs).

The two consulting firms locked horns to win the contract.

This document is authorized for use only in PGP/ Information Systems for Managers - II (ISM-II) by Prof. Shubhamoy, Prof. Prabin Kumar Panigrahi from January 2012 to July 2012.

99/45C Dairy Farm Group – Redesign of Business Systems and Processes

2

Company Background

In 1886, Sir Patrick Manson, a Scottish surgeon, and five prominent Hong Kong businessmenformed Dairy Farm with the objective of supplying cow’s milk to Hong Kong people. In 1904,the Company began importing frozen meat and opened its first retail store at the Central Districtdepot, and by 1957, it had three retail stores and had started expanding its product range, markingthe start of its transformation into a major food retailer and distributor. By 1986, its centenaryyear, it had more than 300 retail outlets, including the Wellcome grocery chain. It had become aleading force in the manufacturing, wholesaling and distribution of dairy and other food productsin the Pacific region and in China. In the same year, the Company acquired a 50 per cent interestin the Maxim’s chain of restaurants in Hong Kong. In 1987, it acquired 25 per cent of Kwik SaveGroup plc - the sixth largest grocery retailer in the UK - and commenced supermarket operationsin Taiwan.The Company subsequently acquired 228 branches of the 7-Eleven convenience stores fromJardine Matheson in 1989, followed by acquisition of the 108-store Simago chain in Spain andthe 61-store Woolworths chain in New Zealand in 1990. Other major expansion activitiesincluded the establishment of a 49 per cent-owned joint venture with Nestlé to develop dairyfactories throughout China in 1992, acquisition of the 142-store Cold Storage chain in Singaporein 1993, establishment of a 50/50 joint-venture with Cold Storage and joint ventures to developsupermarkets and discount stores in Malaysia and Japan in 1994 and 1995 respectively. In 1995,it also signed agreements with the Hero group in Indonesia and the RPG group in India to manageand develop supermarket chains in the two countries. In 1996, Guardian pharmacy joint ventureswere established in Malaysia and India and a 51/49 supermarket joint venture was formed inSichuan.

By 1997, it had operations in all major cities in the Asia-Pacific region, Australia, New Zealandand Europe. In order to concentrate on its core retailing business in the Asia-Pacific region, DFGdisposed of its 49 per cent interest in Nestlé Dairy Farm to Nestlé and decided to close down theloss-making Mannings drugstores in Taiwan and the Wellsave discount stores in Japan. At 31December, 1997, DFG operated 1,352 outlets, principally supermarkets, convenience stores anddrugstores, and employed some 45,600 people. It had also entered into the restaurant businessthrough a 50 per cent interest in Maxim’s Caterers Limited, Hong Kong’s largest restaurant andcatering company with more than 300 outlets in Hong Kong and Mainland China. The reportedsales and profit figures for the year 1997 were US$6.9 billion and US$154 million respectively.1

Fifty-five per cent of DFG’s shares was owned by Jardine Matheson Ltd. and the balance washeld by the public. DFG’s shares were listed on the Hong Kong, Singapore, Bermuda, Londonand New York Stock Exchanges. The primary share listing of the parent company, Dairy FarmInternational Holdings Limited, was in London and the bulk of its shares were traded inSingapore. The Company was incorporated in Bermuda and its businesses were managed fromHong Kong by Dairy Farm Management Services Limited through regional offices in Asia andAustralasia.

DFG’s New Business Strategy

In order to retain its dominant position in the Asia-Pacific region, DFG had decided on a newbusiness strategy. Firstly, the strategy entailed defending its existing markets through a processof rationalisation focused on the disposal of, or closure of, its non-core operations. Such aprocess was expected to put DFG in a position to expand its core operations and become adominant player in each of its chosen markets. A combination of acquisition and rapid

1 US$1=HK$7.74.



3

establishment of new formats funded from its cash-rich position was decided upon. The secondcomponent of the strategy was to respond to the increased competitive threat through changes toits organisational structure, and in this respect it had decided to de-federate its businesses andoperate as a single entity wherever possible. Such a move, it was felt, would enable DFG tocapitalise on both its size and resources and work cohesively as a single company with a singlevision, identity and brand where appropriate. The third dimension of the strategy was to improveon its market share and customer base through exploiting new markets and opportunitiesconsistent with its core market capitalisation strategy.

Existing Systems

The existing systems within DFG were the Store Systems and the Operational Systems.

Store Systems

These systems were those deployed at the retail stores of various business units of DFG. Theretail store applications were point-of-sale systems, procured from several vendors andcustomised for each store’s requirements. Each store had its own local area networks (LAN) onwhich the store system was implemented. The store systems did not interface with any of DFGsoperational systems. Some stores had optical scanners while some had cash registers at thecustomer checkout points. Sales data was transmitted to the related business unit data centresthrough fax and modem for the purpose of consolidation and operational decisions. Historicaldata storage at the store level was minimal, owing to the high volume of daily transactions.

Operational Systems

The operational systems that supported DFG’s retail operations were the following:

• Central Merchandise Management, which included Item and Vendor Management, Pricingand Promotions, Stock Management, Trading terms/costs and Store Replenishment

• Financial and Accounting Management• Inventory Management• Warehouse and Distribution Management• Human Resource Management

Operational systems in DFG’s business units were large in scale, complex in operation andbusiness-critical in nature. Each business unit had its own merchandising, inventory andwarehousing system, implemented on diverse hardware and software platforms. Managers didnot have direct access to the database in the mainframe. Some standard reports were generatedfor management analysis. Any new reports required coding of programmes.

Problems with Existing Systems

Historically, information systems developers had developed systems to meet the requirements ofspecific business functions within an organisation. DFG was no exception. It had a wide rangeof disparate, independent application systems, each built around specific business functions suchas finance, merchandising, warehousing etc. These systems were closed walls, with no provisionfor information exchange across business functions. Furthermore, as DFG expanded itsoperations into various countries in Asia-Pacific, the applications had to be customised to adapt tothe multilingual and multicultural environments of the various countries. As a result, severaldifferent versions of the software existed, significantly increasing the maintenance overheads.Additionally, many business processes within DFG were manual and inefficient, thereby slowing



4

information processing and decision-making. Store replenishment was an example of one suchsystem that required considerable manual action and intervention.

Another handicap with DFG’s systems was that the store systems were not designed to capturethe full details of customer transactions. As such, the customer database allowed only vaguenotions about the customer to be developed. The anonymity of cash transactions, personalprivacy laws and the sheer volume of transactions prevented DFG and other similar retailers fromdeveloping the intimate customer knowledge that was taken for granted in many other industries.This lack of customer knowledge was seen as a formidable barrier to realising the quantum-levelleap that DFG intended to achieve in “sensing and responding” to customer needs.

There was also a dearth of information for management decisions. The relatively scantinformation that was available was fragmented, voluminous, spread across diverse formats andnot current. As such, it was difficult to integrate or analyse. Sometimes, important informationwas not available at all. As an example, calculating lost sales opportunity at the stores arising outof stock outages was not possible because such data was not captured. Information wasexclusively made available in paper form and to analyse it in any other way required that theinformation be entered into a spreadsheet and modified into a new structure.

Like other retail businesses, DFG’s business was also highly distributed. Mobile employees suchas the travelling salesmen and those in the warehouse and distribution functions had problemsaccessing corporate information from remote locations. All DFG employees were tied to specificlocations in order to access corporate information resources. In the first instance, this occurreddue to the specific nature of the access devices (i.e., an IBM 3270/5250 terminal) and theircorresponding dedicated networks. Subsequently, access locations had been fixed because thewide variety of system security services had not extended to allow access from more than onelocation. User identity was often combined with the notion of a fixed location dependent networkidentity.

Problems with Existing Processes

DFG operated as a federated organisation, more by compulsion than by choice. The compulsionstemmed from the fact that a large number of small companies at geographically dispersedlocations had been acquired over a period of time. Since there was no communications network,each of these companies operated independently. There was duplication of some assets andwastage of human resources. For example, although Wellcome operated in the daytime and 7-Eleven at night, each had its own fleet of trucks for stock movement, thereby increasingtransportation costs.

In terms of business processes, store replenishment was one process that required significantmanual intervention. Each company had its own set of suppliers from whom goods werepurchased. This resulted in different prices being paid for the same items because they camefrom different suppliers. Economies of scale were not possible. There was little power overvendors in terms of negotiating terms of trade, particularly in regard to discounts on bulkpurchases. Monitoring of stock “shrinkage” was also a major problem. Sometimes excess goodswere supplied and charged to the stores. Average stockholding for some items (except freshfood) was about thirty-five days against the industry norm of seven days. A consequence of highinventory cost was that DFG’s business units operated at margins that were much lower thanthose of other operators such as Tesco in the UK and Wal-Mart and K-Mart in the US.



5

Another business process that wasted human resources was the accounting function. Thefunction being centralised, copies of purchase orders raised by the stores were sent to the CentralOffice. Copies of goods receipt note and supplier invoices were also received at the CentralOffice. Manually matching such large number of orders with supplier invoices and goods receiptnotes was a daunting task, with phenomenal wastage of man-hours. In 7-Eleven alone, 375,000invoices were matched annually by 120 people.

Findings of the Consulting FirmsAfter a detailed investigation and analysis of the existing business operations, systems andprocedures and the supporting infrastructure, the two consulting firms submitted the followingrecommendations:

Firm A

The firm felt that DFG had an excellent network of retail stores and product lines, which gave it ahead-and-shoulders advantage over its competitors. The snag was management control,attributable to geographically dispersed, disparate and close-walled systems. It found thatsignificant improvements in DFG’s operations and profitability could be achieved by building acorporate management information system, supported by the right technology andcommunications infrastructure. It would enable managers to access corporate information invarious ways and across all functions, thereby facilitating the decision-making process. It alsofound that sufficient advantage could be derived from exploiting the potential of electroniccommerce (EC) and other emerging technology trends.

The major recommendations were as follows:

Store Operations

It was felt that DFG could significantly improve sales and customer satisfaction by adoptingelectronic retailing as a subset of its retailing function. In this respect it suggested that the storeoperate in two environments - the physical and the virtual (electronic). [A schematic view of theproposed application is shown in Exhibit 1].

Features suggested for inclusion in the electronic store application were as follows:

• It would be a World Wide Web (the Web)-based retail system using client-serverarchitecture, aimed at providing an Internet based home shopping system consisting of anElectronic Store and an Electronic Distribution Centre (E-DC). The E-DC was to provide theservices of a fulfilment centre, including product availability, delivery status, physicaldelivery and product warehousing.

• The application would interface with other functional units linked to the retail operations,such as the head office, distribution centres, vendors, consumers, and the financial institutionsfor settlement of electronic transactions

• It would provide full retail capability, similar to that provided by a physical store, to thevirtual customer. The functions recommended for inclusion in the application were productbrowsing, product purchasing, product information, purchase methods, purchase status,purchase history and personalised customer service.



6

Network Computing and Application Re-Design

The development of the Web and its corresponding Web-server and browser technologies hadcreated an opportunity for organisations such as DFG to re-think the architecture of theirapplications. It was recommended that applications, centrally deployed in the mainframeenvironment, be re-written and ported on the latest n-tier client server architecture, with theInternet browser (or other thin-client access device) providing the user interface and anapplication server or information broker as the middle tier. This design model would help inrealising the benefits of information access and data sharing. Other benefits of adopting such atopology would be scalability, application maintenance and software component reuse. Tosupport the re-written applications, it was recommended that an organisational intranet bedeveloped wherein the LANs at the stores would be interconnected with each other throughCommon Gateway Interfaces (CGI), forming a Wide Area Network (WAN). [See Exhibit 2 for asuggested plan for the communications network].

Application Integration and Information Sharing

The firm’s investigation revealed that DFG’s applications had developed over time, independentof one another. Stove-piped applications all communicated with their own databases. Littleattention had been paid to the requirement to exchange information between applications, or toreliably create new information from data sets derived from two or more applications. The firmrecommended that it was important for DFG to have an integrated set of applications within eachbusiness unit so as to facilitate information interchange across business functions. In this regard,it was recommended that store applications interface with all the operational systems, such asfinance, merchandising, warehousing and human resources. [See Exhibit 3 for the message-broker architecture for application integration].

Remote Access

DFG had three distinct classes of mobile users with three different requirements for mobileservices. They were the telecommuters, travelling employees and the task-oriented mobile usersworking for the warehouse, distribution, inspection departments and the stores. It wasrecommended that these users be provided with secured, location-independent access to corporateinformation resources. Such facilities had to be usable, secure, manageable and provisioned atacceptable cost.

Data Warehouse and Data Mart

Like most organisations, DFG only stored transaction records arising from inputs to theoperational systems in the course of daily business. It was the only repository of raw data.Analysis of raw data was a time-consuming and tedious process. Data aggregation, collation etc.was a repetitive process in such analysis. The consulting team recommended that DFG shoulddevelop Data Warehouse and Data Marts to facilititate data analysis and decision-making.

Inventory Management

Firm A found that inventory was the largest single cost-factor in DFG’s retail operations. DFGhad an average inventory holding of thirty-five days as against a norm of seven days for theindustry. The high stockpiling was attributed to delayed processing of purchase orders. It wasrecommended that access points on the proposed corporate intranet be provided to the vendors sothat in cases where direct buying by the stores was involved, store orders could be sent to thevendors in EDI formats. Similarly, vendor invoices could also be sent to the Central Office inEDI formats. The method would facilitate faster processing of orders, leading to reduced



7

inventory at warehouses. Additionally, it would enable computerised matching of orders withinvoices and thereby significantly reduce manpower overheads.

Development of Core Competencies

Firm A believed that in seeking to maximise IT effectiveness, an organisation should not seek tominimise the cost of its technology but maximise the effectiveness of its staff. To this end, itrecommended that a systematic assessment of the required technical skills be made and necessarytraining plans and recruitment schemes be charted out so as to have core competence within theorganisation. [See Exhibit 4 for the Price Performance Trade-off of IT Staff].

Firm B

Firm B believed that technology alone could not bring competitive advantage unless it wasplanned in the context of an organisation’s present and future business needs. In addition totechnology, it placed emphasis on business processes, viewing them as major determinants of anorganisation’s ability to develop and retain competitive advantage. Accordingly, theidentification and re-engineering of business processes to support DFG’s business strategy, andthe acquisition of technology to support such re-engineering, was the stated direction. In thisregard, it recommended a technology planning process, the output from which was to be knownas “DFG’s Technical Architecture”, essentially a framework enabling rapid changes in DFG’sbusiness processes and its supporting applications by providing a clear definition of endorsedstandards, technologies and policies governing their use. [A schematic representation of theTechnology Planning Process is shown in Exhibit 5].

Technology Planning Process

The recommended technology planning process comprised of a business component and a relatedtechnical component. The business component consisted of the identification of businessprocesses and the re-engineering of business processes considered critical to the successfulpursuit of DFG’s business strategy. The technical component pertained to the identification oftechnologies to support the business processes and an implementation plan.

Business ComponentThe business component included the identification and re-engineering of crucial businessprocesses. In trying to address this issue, Firm B viewed the entire set of operations withinDFG’s business units as a set of Business Process Domains (BPDs). These were essentially thelogical grouping of business processes and their associated systems dedicated to a commonpurpose, with the possibility of such grouping being geographically dispersed. Five such BPDswere identified: In-Store Systems, Business Unit Operational Systems, Business Unit AnalyticalSystems, Group Systems and Core Infrastructure Services [see Exhibit 6 for a schematic view ofthe BPDs and associated processes]. The primary purpose of grouping the processes under BPDswas the ability to specify the desired system characteristics for a BPD as a whole, as opposed toindividual processes. Specifically, the following characteristics were considered crucial forsuccess of systems within each BPD.

• Availability, specifying recovery plans, tolerance for system outages etc.• Assurance, specifying security, integrity and credibility requirements• Usability, specifying user interface requirements• Adaptability, specifying interoperability and porting requirements



8

The following systems and business processes were identified for re-engineering:

Store SystemsIn respect of store applications, the recommendation was that common store applications be builtaround standardised technology. The store applications would be resident on a back-end server,which would also store transaction data so as to facilitate stock monitoring at the store level.Store LANs would be networked with the data centres and the central office at Hong Kong fordata transmission. In order to have scalability, the client-server architecture was proposed for itsdeployment. [See Exhibits 7 and 8 for the suggested application partitioning logic and thephysical topology respectively]. It was also recommended that the store applications be re-designed to ensure that all data conducive to decision making was captured at the transactionpoints. The application would be extended to support new channels of marketing, such asfacsimile and telephone, IVR and ITV.

It was suggested that Store Systems have the following attributes:

• Share a common information base• Be integrated• Support co-ordinated actions. In-store systems needed to support distributed transactions• Interface with systems external to the Store Systems• Be flexible to accommodate changing business requirements and operation in multiple

geographic territories• Be scalable from a minimum of two to a maximum of fifty shopping lanes• Be adaptable to operate across DFG’s multiple retail formats• Be extensible to accommodate new technologies and releases• Be remotely maintainable• Integrate with standard DFG management mechanisms

Inventory ManagementIt was felt that the suggested business strategy of operating as a single entity in a de-federatedorganisational structure would enable DFG to achieve economies of scale in terms of inventorymanagement. It was recommended that store systems would integrate with operational systemsand also be extended to include the buyers and suppliers. A central merchandising system withineach business unit would monitor the inventory levels at each store and generate individual storeorders. The store orders would then be routed to the respective stores for their approval.Approved orders would be consolidated and purchase orders generated to suppliers. Ingenerating purchase orders, leverage would be obtained in respect of the terms of trade withdifferent suppliers. [A descriptive model of the suggested method is shown in Exhibit 9].

Significant benefits were expected to accrue from such a process. While stock outages at storeswould be minimised, it would also ensure that the stores maintained optimal stock levels. Itwould also provide DFG with additional power to negotiate terms of trade with its suppliers andsubstantially reduce the number of purchase orders and invoices. The process entailed theintegration of the POS, merchanidising and the warehousing functions across the in-store and theoperational BPDs. A future direction recommended in this regard was the integration of thesupply chain across business units, and continual stock level monitoring at individual storesdirectly by the suppliers, who would then supply stocks as necessary.



9

Category ManagementTraditionally, DFG, like all retailers, maintained separate buying and selling functions. Buyingwas not fully geared towards customer requirements. The selling function entailed sellingwhatever was available in the stores. The result was warehouses carrying large inventories ofslow-moving stocks and stock outages at stores for fast-moving items. The establishment of acommon process, one that would enable customer requirements to be sensed and catered to,depended to a large extent on detailed, accurate and timely information on customer transactions.While the suggested changes in the store operations would enable detailed data capturing oncustomer transactions, it was recommended that data warehousing technology be adopted tofacilitate organisation and analysis of data for marketing to customer segments.

Electronic CommerceThe firm felt that DFG could benefit from advertising its products on the Web. They howeverexpressed reservation in regard to buying and selling through the Internet, particularly because ofthe security problems inherent in electronic transactions. It would be a long time beforeconsumers would feel comfortable with giving their credit card information on the Internet for thepurpose of settling Internet-based transactions.

Technical ComponentFor DFG to evolve from a federation to a group business structure as per its business strategy,significant additional investment in a common supporting infrastructure linking the variousbusiness units was required. The level of linkage required between the business units and thesupport required to integrate the supply chain across business units depended upon successfuldeployment of the services under the Core Infrastructure Services. [See Exhibit 10 for theapplications planned for deployment within this BPD.] A corporate-wide area network to providegroup-wide information systems through interconnections across the various BPDs identifiedwithin DFG was recommended. Over time, the Core Infrastructure Services BPD was seen todevelop as the foundation for distributed computing within DFG and hence provide group-wideinformation management capability. It was initially planned to extend only up to the boundary ofeach business unit so as to provide inter-business services. As the functions available within theBPD became more relevant to the information systems within business units, the domain wasplanned to be extended to provide intra-business unit services. To facilitate this progression, allinternal services pertaining to a business unit were required to be provided in accordance withstandards and technologies selected for the Core Infrastructure Services BPD.

A key function of the Core Infrastructure Services was to provide enterprise-wide systemsecurity, integrity and credibility, particularly within the In-Store BPD. Some of these serviceswere to be invoked explicitly by application programmes, while others were to be used implicitlythrough the use of operating systems, databases, communications, security or message-basedcomponents. In respect of each BPD, continuous or near continuous availability of systems,interoperability with other systems, usability in terms of user interfaces etc., were other functionsprovided by the Core Infrastructure Services.

Technology Planning Team

To carry out the recommended technology planning, it was proposed that a TechnicalArchitecture Programme Group (TAPG) be established under the auspices of a TechnologyStrategy and Architecture Group (TA Team) which would be the body formally established toconceive, develop and maintain DFG’s Technical Architecture. TAPG membership would be



10

drawn from three groups: the DFG TA Team, DFG’s Technology Partners and the consultantorganisations with specific technology expertise.

The Technical Architecture development, review and adoption process would consist of thefollowing seven steps:

1. The DFG TA Team would receive business direction from the DFG Operating Committee viathe Group CIO.

2. The DFG TA Team would interpret business direction and instruct TAPG.3. TAPG would develop the DFG Technical Architecture, with formal revision of the document

every three months. Urgent technology decisions would be communicated by issuing an ITPolicy and Standards Directive.

4. The DFG TA Team would forward the document to DFG’s Business Units, DFG’s TechnicalPartners and DFG’s IT Council for review. Formal comments would be communicated backto TAPG via the Group Technical Architect. The DFG IT Council would meet bi-monthly.

5. The DFG Technology Architecture would be reviewed and accepted by the Group CIO.6. The Group CIO would issue the DFG Technology Architecture to the DFG IT Steering

Committee for formal policy adoption.7. The DFG Operating Committee would be informed of the formal adoption by the Group CIO.

Evaluation of the RecommendationsBoth consulting firms had a successful track record. While firm A stressed primarily thedevelopment of a management information system and use of emerging trends in technology,firm B focused on the re-engineering of crucial business processes with supporting technology.DFG’s management team faced some difficult decisions, all the more so because it was difficultto put quantitative values on some of the qualititative benefits accruing from such projects. Costbenefit analyses such as payback periods, net present value of expected future cash flows etc.were therefore only gross approximations.



11

EXHIBIT 1ELECTRONIC STORE APPLICATION - SCHEMATIC VIEW

CIS

ESTOREData Store

ESTORECommunication

CustomerInterface

Customer

Courier

Fulfillment Center Head Office

Electronic Store

CSR/ StoreManagement

Customer

MIS

Suppliers

Banks

Key:CIS - Customer Interface Server MIS - Management Interface Server CSR - Customer Service Representative

Source: Technical Architecture document (v 1.0) of Dairy Farm Group



12

EXHIBIT 2SYSTEM SCHEMATIC OF PROPOSED COMMUNICATIONS NETWORK

Country HubSingapore

MDNS

Country HubHK

Australia Office

Singapore Office

Country HubAustralia

PRC Office*

Malaysia Office

Indonesia Office

New Zealand Office

Taiwan Office

Japan Office

Dairy Farm Group

Hong Kong ConvenienceStores Ltd.

Sims Trading Company Ltd.

Manning Retail Ltd.

Wellcome Company Ltd.

Oliver's

OpenNet

Internet

2

3

Traveling Users

*refer to section 2.5 for details in China connection

Leased Circuit

Frame Relay PermanentCircuit (PVC)




13

EXHIBIT 3SUGGESTED APPLICATION INTEGRATION USING MESSAGE BROKER

LEGACY MAINFRAME APPLICATION SYSTEM

Program

Program

PURCHASED UNIX APPLICATION SYSTEM

Program

Program

NEW ‘SERVICE-ORIENTED’ APPLICATION SYSTEM

Client

Service Service

Client

Customer nameand address data

Editing andbusiness rules toupdate customername and address

MessageBroker




14

EXHIBIT 4PRICE PERFORMANCE TRADE OFF FOR IT STAFF

Cost

Tim e

High

Low

Trade off

IT Staff

MIPSNetworkMemoryStorage




15

EXHIBIT 5RECOMMENDED TECHNICAL PLANNING PROCESS

F u t u r e T e c h n i c a lArch i tec ture

Appl ica t ionsHa rdwa reSof tware

C o m m u n icat ions

D F G D i r e c t i o na n d B u s i n e s sRequ i rements

Pr inc ip les

C u r r e n t(de facto)

Arch i tec tures

IndustryT e c h n o l o g y

T r e n d s

P r o d u c tSe lec t ion

S t a n d a r d s

Investm e n tDec is ions




16

EXHIBIT 6BUSINESS PROCESS DOMAINS

GROUP

CORE INFRASTRUCTURE SERVICES

Analytical

nn Executive Information Systems

nn Data Warehouse

nn Data Marts

nn Analytical Applications

nn Financial

nn Human Resource

nn Merchandising

nn Warehouse

nn POS

nn In-Store Merchandising

nn Labour Scheduling

nn Time & Attendance

nn File & Print

nn Office Automation

nn Directories• DNS• DHCP• Email• LDAP

nn Enterprise Application Integration (EAI)

nn Transaction Management

nn Management• Network• System• Application

nn Security

nn Time

Operational

HighAvailability

Very HighAvailability

DisasterRecovery

In-StoreBUSINESS UNIT

nn Loyalty




17

EXHIBIT 7ELECTRONIC STORE APPLICATION - SUGGESTED PARTITIONING LOGIC

User InterfaceLayer Application

Layer Data & TransactionLayer

Browser ApplicationServices

RemoteApplicationServices

Data

Web ServerSSL / HTTP Active X


PresentationServices

Access orControlMechanisms

Applications

SystemInterconnection

Data Access



18

EXHIBIT 8ELECTRONIC STORE APPLICATION - SUGGESTED PHYSICAL TOPOLOGY

Standard Client

User Interface

Netscape or Microsoft IE3Browser

Application BusinessLogicMinor validation usingJAVAscript

InfrastructureSSL/HTTPSMTP, MIMEIP

Core Systems & DBMS

ApplicationBusiness Logic

NIL

Data Management

Microsoft SQLServer

Application Services

Application Business Logic

E-RETAIL US Interactive/ DE Inc.

Microsoft Site Server—Commerce Edition

InfrastructureMicrosoft MQ (Internal)

IBM MQ Series (External—Target)

Microsoft DCOM

IP

Microsoft NT Domain Security

Tivoli Network, Systems & ApplicationsManagement (Target)

Any JavaScript Browser Microsoft NT on IBM Netfinity Microsoft NT on IBM Netfinity

LAN LAN

InfrastructureMicrosoft MQ (Internal)

IBM MQ Series (External—Target)

Microsoft DCOM

IP

Microsoft NT Domain Security

Tivoli Network, Systems &App. Management (Target)

Firewall

IBM / AIX

INTERNET




19

EXHIBIT 9STORE REPLENISHMENT - SUGGESTED LOGISTICS

LEGEND:

1, 2, n Suggested orders for stores 1, 2 … N (raised by merchandising system)1a, 2a, na Confirmed orders (Confirmed by stores 1, 2 … N)3 Supplier wise orders (raised by merchandising systems with leverage of trading terms)4 Supplier delivery5 Warehouse delivery receipt6, 7, n Store delivery of allocated orders6a, 7a, na Store delivery receipt


SUPPLIER

WAREHOUSE

MERCHANDISINGSYSTEM

TRADING TERMS

STORE 1

STORE 2

STORE N

3

1

1a

2

2a

6

7

n

6a

7a

n a

4

5

N

Na



20

EXHIBIT 10CORE INFRASTRUCTURE SERVICES - SUGGESTED APPLICATION TOPOLOGY

Standard Client

User Interface


Software Engineering

InfrastructureData I/C - IBM MQSeriesDist. Computing & Objects - Microsoft DCOMNetwork - TCP/IPTransaction Process - NilSecurity - IBM TivoliNetwork, System &Application Management - IBM Tivoli

Core Systems & DBMS



Data Management

Application Services

Application Business Logic


InfrastructureData Interchange - IBM MQSeriesDistributed Computing & Object Services - Microsoft DCOMNetwork - TCP/IPTransaction Processing - NilSecurity - IBM TivoliNetwork, System & ApplicationManagement - IBM Tivoli

PLATFORM PLATFORM PLATFORM

WAN LAN or WAN

InfrastructureData I/C - IBM MQSeriesDist. Computing & Object - Microsoft DCOMNetwork - TCP/IPTransaction Process - NilSecurity - IBM TivoliNetwork, System &Application Management - IBM Tivoli



Documents

Dairy Fram Group