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) of
Hong Kong.
Copyright 1999 The University of Hong Kong. No part of this publication may be reproduced or transmitted in any
form or by any means - electronic, mechanical, photocopying, recording, or otherwise (including the Internet) - without
the 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 of
Companies, (DFG), a major Hong Kong-based food retailer with operations in a large number of
major cities in the Asia-Pacific region. The economic crisis that gripped Asian countries during
the 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 competitive
pressures that DFG faced from European and US retail chains preparing to gain a foothold in the
growing Asian market. Another concern was its low profit margins compared to its competitors
in Hong Kong and China and other retailers in Europe and the US. While DFG operated on a
sales-to-profit margin of 2.23 per cent in 1997 and 1.98 per cent in 1996, competitor A.S. Watson
Group, comprised of the ParkN Shop, Watsons and Fortress chain of stores in Hong Kong and
China, had a 9.22 per cent sales-to-profit margin in 1997, up from 5 per cent in 1996. Another
competitor, US-based Wal-Mart, reported a 2.92 per cent margin in 1997. DFGs business
mission was: To be the leading food and drug store operator in sales and shareholder value
creation in Asia-Pacific. DFG realised that crucial to the successful pursuit of its business
mission was the need to redefine its business strategy, geared towards sensing and responding to
customer needs as opposed to traditional buying and selling.
The shareholders were critical of the extant managements ability to provide DFG with the
direction needed to fulfil its mission. Consequently, a new CEO was hired in June 1997. The
new 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 to
recommend solutions. The final contract was to be awarded to the firm whose recommendations
were seen as being actionable and directly contributing to the bottom line (i.e., competitive
advantage through quantum-level leaps in customer satisfaction and shareholders wealth, at
significantly 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 businessmen
formed Dairy Farm with the objective of supplying cows milk to Hong Kong people. In 1904,
the Company began importing frozen meat and opened its first retail store at the Central District
depot, and by 1957, it had three retail stores and had started expanding its product range, marking
the start of its transformation into a major food retailer and distributor. By 1986, its centenary
year, it had more than 300 retail outlets, including the Wellcome grocery chain. It had become a
leading force in the manufacturing, wholesaling and distribution of dairy and other food products
in the Pacific region and in China. In the same year, the Company acquired a 50 per cent interest
in the Maxims chain of restaurants in Hong Kong. In 1987, it acquired 25 per cent of Kwik Save
Group plc - the sixth largest grocery retailer in the UK - and commenced supermarket operations
in Taiwan.
The Company subsequently acquired 228 branches of the 7-Eleven convenience stores from
Jardine Matheson in 1989, followed by acquisition of the 108-store Simago chain in Spain and
the 61-store Woolworths chain in New Zealand in 1990. Other major expansion activities
included the establishment of a 49 per cent-owned joint venture with Nestl to develop dairy
factories throughout China in 1992, acquisition of the 142-store Cold Storage chain in Singapore
in 1993, establishment of a 50/50 joint-venture with Cold Storage and joint ventures to develop
supermarkets 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 manage
and develop supermarket chains in the two countries. In 1996, Guardian pharmacy joint ventures
were established in Malaysia and India and a 51/49 supermarket joint venture was formed in
Sichuan.
By 1997, it had operations in all major cities in the Asia-Pacific region, Australia, New Zealand
and Europe. In order to concentrate on its core retailing business in the Asia-Pacific region, DFG
disposed of its 49 per cent interest in Nestl Dairy Farm to Nestl and decided to close down the
loss-making Mannings drugstores in Taiwan and the Wellsave discount stores in Japan. At 31
December, 1997, DFG operated 1,352 outlets, principally supermarkets, convenience stores and
drugstores, and employed some 45,600 people. It had also entered into the restaurant business
through a 50 per cent interest in Maxims Caterers Limited, Hong Kongs largest restaurant and
catering company with more than 300 outlets in Hong Kong and Mainland China. The reported
sales and profit figures for the year 1997 were US$6.9 billion and US$154 million respectively.
1
Fifty-five per cent of DFGs shares was owned by Jardine Matheson Ltd. and the balance was
held by the public. DFGs shares were listed on the Hong Kong, Singapore, Bermuda, London
and New York Stock Exchanges. The primary share listing of the parent company, Dairy Farm
International Holdings Limited, was in London and the bulk of its shares were traded in
Singapore. The Company was incorporated in Bermuda and its businesses were managed from
Hong Kong by Dairy Farm Management Services Limited through regional offices in Asia and
Australasia.
DFGs New Business Strategy
In order to retain its dominant position in the Asia-Pacific region, DFG had decided on a new
business strategy. Firstly, the strategy entailed defending its existing markets through a process
of rationalisation focused on the disposal of, or closure of, its non-core operations. Such a
process was expected to put DFG in a position to expand its core operations and become a
dominant 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 second
component of the strategy was to respond to the increased competitive threat through changes to
its organisational structure, and in this respect it had decided to de-federate its businesses and
operate as a single entity wherever possible. Such a move, it was felt, would enable DFG to
capitalise on both its size and resources and work cohesively as a single company with a single
vision, identity and brand where appropriate. The third dimension of the strategy was to improve
on its market share and customer base through exploiting new markets and opportunities
consistent 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. The
retail store applications were point-of-sale systems, procured from several vendors and
customised for each stores requirements. Each store had its own local area networks (LAN) on
which the store system was implemented. The store systems did not interface with any of DFGs
operational systems. Some stores had optical scanners while some had cash registers at the
customer checkout points. Sales data was transmitted to the related business unit data centres
through fax and modem for the purpose of consolidation and operational decisions. Historical
data storage at the store level was minimal, owing to the high volume of daily transactions.
Operational Systems
The operational systems that supported DFGs retail operations were the following:
Central Merchandise Management, which included Item and Vendor Management, Pricing
and 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 DFGs business units were large in scale, complex in operation and
business-critical in nature. Each business unit had its own merchandising, inventory and
warehousing system, implemented on diverse hardware and software platforms. Managers did
not have direct access to the database in the mainframe. Some standard reports were generated
for management analysis. Any new reports required coding of programmes.
Problems with Existing Systems
Historically, information systems developers had developed systems to meet the requirements of
specific business functions within an organisation. DFG was no exception. It had a wide range
of disparate, independent application systems, each built around specific business functions such
as finance, merchandising, warehousing etc. These systems were closed walls, with no provision
for information exchange across business functions. Furthermore, as DFG expanded its
operations into various countries in Asia-Pacific, the applications had to be customised to adapt to
the multilingual and multicultural environments of the various countries. As a result, several
different 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 such
system that required considerable manual action and intervention.
Another handicap with DFGs systems was that the store systems were not designed to capture
the full details of customer transactions. As such, the customer database allowed only vague
notions about the customer to be developed. The anonymity of cash transactions, personal
privacy laws and the sheer volume of transactions prevented DFG and other similar retailers from
developing 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-level
leap that DFG intended to achieve in sensing and responding to customer needs.
There was also a dearth of information for management decisions. The relatively scant
information that was available was fragmented, voluminous, spread across diverse formats and
not current. As such, it was difficult to integrate or analyse. Sometimes, important information
was not available at all. As an example, calculating lost sales opportunity at the stores arising out
of stock outages was not possible because such data was not captured. Information was
exclusively made available in paper form and to analyse it in any other way required that the
information be entered into a spreadsheet and modified into a new structure.
Like other retail businesses, DFGs business was also highly distributed. Mobile employees such
as the travelling salesmen and those in the warehouse and distribution functions had problems
accessing corporate information from remote locations. All DFG employees were tied to specific
locations in order to access corporate information resources. In the first instance, this occurred
due to the specific nature of the access devices (i.e., an IBM 3270/5250 terminal) and their
corresponding dedicated networks. Subsequently, access locations had been fixed because the
wide variety of system security services had not extended to allow access from more than one
location. User identity was often combined with the notion of a fixed location dependent network
identity.
Problems with Existing Processes
DFG operated as a federated organisation, more by compulsion than by choice. The compulsion
stemmed from the fact that a large number of small companies at geographically dispersed
locations 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 and
wastage 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 increasing
transportation costs.
In terms of business processes, store replenishment was one process that required significant
manual intervention. Each company had its own set of suppliers from whom goods were
purchased. This resulted in different prices being paid for the same items because they came
from different suppliers. Economies of scale were not possible. There was little power over
vendors in terms of negotiating terms of trade, particularly in regard to discounts on bulk
purchases. Monitoring of stock shrinkage was also a major problem. Sometimes excess goods
were supplied and charged to the stores. Average stockholding for some items (except fresh
food) was about thirty-five days against the industry norm of seven days. A consequence of high
inventory cost was that DFGs business units operated at margins that were much lower than
those 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. The
function being centralised, copies of purchase orders raised by the stores were sent to the Central
Office. Copies of goods receipt note and supplier invoices were also received at the Central
Office. Manually matching such large number of orders with supplier invoices and goods receipt
notes was a daunting task, with phenomenal wastage of man-hours. In 7-Eleven alone, 375,000
invoices were matched annually by 120 people.
Findings of the Consulting Firms
After a detailed investigation and analysis of the existing business operations, systems and
procedures and the supporting infrastructure, the two consulting firms submitted the following
recommendations:
Firm A
The firm felt that DFG had an excellent network of retail stores and product lines, which gave it a
head-and-shoulders advantage over its competitors. The snag was management control,
attributable to geographically dispersed, disparate and close-walled systems. It found that
significant improvements in DFGs operations and profitability could be achieved by building a
corporate management information system, supported by the right technology and
communications infrastructure. It would enable managers to access corporate information in
various ways and across all functions, thereby facilitating the decision-making process. It also
found that sufficient advantage could be derived from exploiting the potential of electronic
commerce (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 adopting
electronic retailing as a subset of its retailing function. In this respect it suggested that the store
operate in two environments - the physical and the virtual (electronic). [A schematic view of the
proposed 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-server
architecture, aimed at providing an Internet based home shopping system consisting of an
Electronic Store and an Electronic Distribution Centre (E-DC). The E-DC was to provide the
services of a fulfilment centre, including product availability, delivery status, physical
delivery 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 institutions
for settlement of electronic transactions
It would provide full retail capability, similar to that provided by a physical store, to the
virtual customer. The functions recommended for inclusion in the application were product
browsing, 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 had
created an opportunity for organisations such as DFG to re-think the architecture of their
applications. It was recommended that applications, centrally deployed in the mainframe
environment, be re-written and ported on the latest n-tier client server architecture, with the
Internet browser (or other thin-client access device) providing the user interface and an
application server or information broker as the middle tier. This design model would help in
realising the benefits of information access and data sharing. Other benefits of adopting such a
topology would be scalability, application maintenance and software component reuse. To
support the re-written applications, it was recommended that an organisational intranet be
developed wherein the LANs at the stores would be interconnected with each other through
Common Gateway Interfaces (CGI), forming a Wide Area Network (WAN). [See Exhibit 2 for a
suggested plan for the communications network].
Application Integration and Information Sharing
The firms investigation revealed that DFGs applications had developed over time, independent
of one another. Stove-piped applications all communicated with their own databases. Little
attention had been paid to the requirement to exchange information between applications, or to
reliably create new information from data sets derived from two or more applications. The firm
recommended that it was important for DFG to have an integrated set of applications within each
business 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 as
finance, 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 mobile
services. They were the telecommuters, travelling employees and the task-oriented mobile users
working for the warehouse, distribution, inspection departments and the stores. It was
recommended that these users be provided with secured, location-independent access to corporate
information resources. Such facilities had to be usable, secure, manageable and provisioned at
acceptable cost.
Data Warehouse and Data Mart
Like most organisations, DFG only stored transaction records arising from inputs to the
operational 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 should
develop Data Warehouse and Data Marts to facilititate data analysis and decision-making.
Firm A found that inventory was the largest single cost-factor in DFGs retail operations. DFG
had an average inventory holding of thirty-five days as against a norm of seven days for the
industry. The high stockpiling was attributed to delayed processing of purchase orders. It was
recommended that access points on the proposed corporate intranet be provided to the vendors so
that in cases where direct buying by the stores was involved, store orders could be sent to the
vendors in EDI formats. Similarly, vendor invoices could also be sent to the Central Office in
EDI formats. The method would facilitate faster processing of orders, leading to reduced
7
inventory at warehouses. Additionally, it would enable computerised matching of orders with
invoices 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 to
minimise the cost of its technology but maximise the effectiveness of its staff. To this end, it
recommended that a systematic assessment of the required technical skills be made and necessary
training plans and recruitment schemes be charted out so as to have core competence within the
organisation. [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 was
planned in the context of an organisations present and future business needs. In addition to
technology, it placed emphasis on business processes, viewing them as major determinants of an
organisations ability to develop and retain competitive advantage. Accordingly, the
identification and re-engineering of business processes to support DFGs business strategy, and
the acquisition of technology to support such re-engineering, was the stated direction. In this
regard, it recommended a technology planning process, the output from which was to be known
as DFGs Technical Architecture, essentially a framework enabling rapid changes in DFGs
business processes and its supporting applications by providing a clear definition of endorsed
standards, technologies and policies governing their use. [A schematic representation of the
Technology Planning Process is shown in Exhibit 5].
Technology Planning Process
The recommended technology planning process comprised of a business component and a related
technical component. The business component consisted of the identification of business
processes and the re-engineering of business processes considered critical to the successful
pursuit of DFGs business strategy. The technical component pertained to the identification of
technologies to support the business processes and an implementation plan.
Business Component
The business component included the identification and re-engineering of crucial business
processes. In trying to address this issue, Firm B viewed the entire set of operations within
DFGs business units as a set of Business Process Domains (BPDs). These were essentially the
logical grouping of business processes and their associated systems dedicated to a common
purpose, with the possibility of such grouping being geographically dispersed. Five such BPDs
were identified: In-Store Systems, Business Unit Operational Systems, Business Unit Analytical
Systems, Group Systems and Core Infrastructure Services [see Exhibit 6 for a schematic view of
the BPDs and associated processes]. The primary purpose of grouping the processes under BPDs
was the ability to specify the desired system characteristics for a BPD as a whole, as opposed to
individual processes. Specifically, the following characteristics were considered crucial for
success 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 Systems
In respect of store applications, the recommendation was that common store applications be built
around 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 for
data transmission. In order to have scalability, the client-server architecture was proposed for its
deployment. [See Exhibits 7 and 8 for the suggested application partitioning logic and the
physical 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 transaction
points. The application would be extended to support new channels of marketing, such as
facsimile 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 DFGs multiple retail formats
Be extensible to accommodate new technologies and releases
Be remotely maintainable
Integrate with standard DFG management mechanisms
It was felt that the suggested business strategy of operating as a single entity in a de-federated
organisational structure would enable DFG to achieve economies of scale in terms of inventory
management. It was recommended that store systems would integrate with operational systems
and also be extended to include the buyers and suppliers. A central merchandising system within
each business unit would monitor the inventory levels at each store and generate individual store
orders. 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. In
generating purchase orders, leverage would be obtained in respect of the terms of trade with
different 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 stores
would be minimised, it would also ensure that the stores maintained optimal stock levels. It
would also provide DFG with additional power to negotiate terms of trade with its suppliers and
substantially reduce the number of purchase orders and invoices. The process entailed the
integration of the POS, merchanidising and the warehousing functions across the in-store and the
operational BPDs. A future direction recommended in this regard was the integration of the
supply chain across business units, and continual stock level monitoring at individual stores
directly by the suppliers, who would then supply stocks as necessary.
9
Category Management
Traditionally, DFG, like all retailers, maintained separate buying and selling functions. Buying
was not fully geared towards customer requirements. The selling function entailed selling
whatever was available in the stores. The result was warehouses carrying large inventories of
slow-moving stocks and stock outages at stores for fast-moving items. The establishment of a
common 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 on
customer transactions, it was recommended that data warehousing technology be adopted to
facilitate organisation and analysis of data for marketing to customer segments.
Electronic Commerce
The firm felt that DFG could benefit from advertising its products on the Web. They however
expressed reservation in regard to buying and selling through the Internet, particularly because of
the security problems inherent in electronic transactions. It would be a long time before
consumers would feel comfortable with giving their credit card information on the Internet for the
purpose of settling Internet-based transactions.
Technical Component
For 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 various
business units was required. The level of linkage required between the business units and the
support required to integrate the supply chain across business units depended upon successful
deployment of the services under the Core Infrastructure Services. [See Exhibit 10 for the
applications planned for deployment within this BPD.] A corporate-wide area network to provide
group-wide information systems through interconnections across the various BPDs identified
within DFG was recommended. Over time, the Core Infrastructure Services BPD was seen to
develop as the foundation for distributed computing within DFG and hence provide group-wide
information management capability. It was initially planned to extend only up to the boundary of
each business unit so as to provide inter-business services. As the functions available within the
BPD became more relevant to the information systems within business units, the domain was
planned to be extended to provide intra-business unit services. To facilitate this progression, all
internal services pertaining to a business unit were required to be provided in accordance with
standards and technologies selected for the Core Infrastructure Services BPD.
A key function of the Core Infrastructure Services was to provide enterprise-wide system
security, integrity and credibility, particularly within the In-Store BPD. Some of these services
were to be invoked explicitly by application programmes, while others were to be used implicitly
through the use of operating systems, databases, communications, security or message-based
components. 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 functions
provided by the Core Infrastructure Services.
Technology Planning Team
To carry out the recommended technology planning, it was proposed that a Technical
Architecture Programme Group (TAPG) be established under the auspices of a Technology
Strategy and Architecture Group (TA Team) which would be the body formally established to
conceive, develop and maintain DFGs Technical Architecture. TAPG membership would be
10
drawn from three groups: the DFG TA Team, DFGs Technology Partners and the consultant
organisations with specific technology expertise.
The Technical Architecture development, review and adoption process would consist of the
following seven steps:
1. The DFG TA Team would receive business direction from the DFG Operating Committee via
the 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 IT
Policy and Standards Directive.
4. The DFG TA Team would forward the document to DFGs Business Units, DFGs Technical
Partners and DFGs IT Council for review. Formal comments would be communicated back
to 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 Recommendations
Both consulting firms had a successful track record. While firm A stressed primarily the
development 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.
DFGs management team faced some difficult decisions, all the more so because it was difficult
to put quantitative values on some of the qualititative benefits accruing from such projects. Cost
benefit analyses such as payback periods, net present value of expected future cash flows etc.
were therefore only gross approximations.
11
EXHIBIT 1
ELECTRONIC STORE APPLICATION - SCHEMATIC VIEW
CIS
ESTORE
Data Store
ESTORE
Communication
Customer
Interface
Customer
Courier
Fulfillment Center Head Office
Electronic Store
CSR/ Store
Management
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 2
SYSTEM SCHEMATIC OF PROPOSED COMMUNICATIONS NETWORK
Country Hub
Singapore
MDNS
Country Hub
HK
Australia Office
Singapore Office
Country Hub
Australia
PRC Office*
Malaysia Office
Indonesia Office
NewZealand Office
Taiwan Office
Japan Office
Dairy FarmGroup
Hong Kong Convenience
Stores 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 Permanent
Circuit (PVC)
13
EXHIBIT 3
SUGGESTED 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 name
and address data
Editing and
business rules to
update customer
name and address
Message
Broker
14
EXHIBIT 4
PRICE PERFORMANCE TRADE OFF FOR IT STAFF
Cost
Ti me
Hi gh
Low
Trade off
IT Staff
MI PS
Net work
Memory
Storage
15
EXHIBIT 5
RECOMMENDED TECHNICAL PLANNING PROCESS
Fut ur e Techni cal
Ar chi t ect ur e
Appl i cat i ons
Har dwar e
Sof t war e
Co mmu n i cat i ons
DFG Di r ect i on
and Busi ness
Requi r ement s
Pr i nci pl es
Cur r ent
( de f act o)
Ar chi t ect ur es
I ndust r y
Technol ogy
Tr ends
Pr oduct
Sel ect i on
St andar ds
I nvest me nt
Deci si ons
16
EXHIBIT 6
BUSINESS PROCESS DOMAINS
GROUP
CORE INFRASTRUCTURE SERVICES
Analytical
n n Executive
Information
Systems
n n Data
Warehouse
n n Data Marts
n n Analytical
Applications
n n Financial
n n Human
Resource
n n Merchandising
n n Warehouse
n n POS
n n In-Store
Merchandising
n n Labour
Scheduling
n n Time &
Attendance
n n File & Print
n n
Office
Automation
n n Directories
DNS
DHCP
Email
LDAP
n n Enterprise
Application
Integration
(EAI)
n n Transaction
Management
n n Management
Network
System
Application
n n Security
n n
Ti me
Operational
High
Availability
Very High
Availability
Disaster
Recovery
In-Store
BUSINESS UNIT
n n Loyalty
17
EXHIBIT 7
ELECTRONIC STORE APPLICATION - SUGGESTED PARTITIONING LOGIC
User Interface
Layer
Application
Layer
Data & Transaction
Layer
Browser
Application
Services
Remote
Application
Services
Data
Web Server
SSL / HTTP Active X
Presentation
Services
Access or
Control
Mechanisms
Applications
System
Interconnection
Data Access
18
EXHIBIT 8
ELECTRONIC STORE APPLICATION - SUGGESTED PHYSICAL TOPOLOGY
Standard Client
User Interface
Netscape or Microsoft IE3
Browser
Application Business
Logic
Minor validation using
JAVAscript
Infrastructure
SSL/HTTP
SMTP, MIME
IP
Core Systems & DBMS
Application
Business Logic
NIL
Data Management
Microsoft SQLServer
Application Services
Application Business Logic
E-RETAIL US Interactive/ DE Inc.
Microsoft Site ServerCommerce Edition
Infrastructure
Microsoft MQ (Internal)
IBM MQ Series (ExternalTarget)
Microsoft DCOM
IP
Microsoft NT Domain Security
Tivoli Network, Systems & Applications
Management (Target)
Any JavaScript Browser Microsoft NT on IBM Netfinity Microsoft NT on IBM Netfinity
LAN LAN
Infrastructure
Microsoft 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 9
STORE 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 delivery
5 Warehouse delivery receipt
6, 7, n Store delivery of allocated orders
6a, 7a, na Store delivery receipt
SUPPLIER
WAREHOUSE
MERCHANDISING
SYSTEM
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 10
CORE INFRASTRUCTURE SERVICES - SUGGESTED APPLICATION TOPOLOGY
Standard Client
User Interface
Application
Business Logic
Software Engineering
Infrastructure
Data I/C - IBM MQSeries
Dist. Computing & Objects
- Microsoft DCOM
Network - TCP/IP
Transaction Process - Nil
Security - IBMTivoli
Network, System &
Application Management
- IBM Tivoli
Core Systems & DBMS
Application
Business Logic
Data Management
Application Services
Application Business Logic
Infrastructure
Data Interchange - IBM MQSeries
Distributed Computing & Object Services
- Microsoft DCOM
Network - TCP/IP
Transaction Processing - Nil
Security - IBM Tivoli
Network, System & Application
Management - IBM Tivoli
PLATFORM PLATFORM PLATFORM
WAN LAN or WAN
Infrastructure
Data I/C - IBM MQSeries
Dist. Computing & Object
- Microsoft DCOM
Network - TCP/IP
Transaction Process - Nil
Security - IBM Tivoli
Network, System &
Application Management
- IBM Tivoli

Dairy Fram Group

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Dairy Fram Group

Hochgeladen von

Copyright:

Verfügbare Formate

HKU049

Das könnte Ihnen auch gefallen