Page 199 - E-Bussiness and E-Commerce Management Strategy, Implementation, and Practice

M03_CHAF9601_04_SE_C03.QXD:D01_CHAF7409_04_SE_C01.QXD 16/4/09 11:09 Page 166

166 Part 1 Introduction

develop at three different levels: (1) there may be different technology architectures used in
different functional areas, giving rise to the problems discussed in the previous section, (2)
there will also be different applications and separate databases in different areas and (3)
processes or activities followed in the different functional areas may also be different.
These applications silos are often a result of decentralization or poorly controlled invest-
ment in information systems, with different departmental managers selecting different
systems from different vendors. This is inefficient in that it will often cost more to purchase
applications from separate vendors, and also it will be more costly to support and upgrade.
Even worse is that such a fragmented approach stifles decision making and leads to isolation
between functional units. An operational example of the problems this may cause is if a cus-
tomer phones a B2B company for the status of a bespoke item they have ordered, where the
person in customer support may have access to their personal details but not the status of
their job, which is stored on a separate information system in the manufacturing unit. Prob-
lems can also occur at tactical and strategic levels. For example, if a company is trying to
analyse the financial contribution of customers, perhaps to calculate lifetime values, some
information about customers’ purchases may be stored in a marketing information system,
while the payments data will be stored in a separate system within the finance department. It
may prove difficult or impossible to reconcile these different data sets.
To avoid the problems of a fragmented applications infrastructure, companies attempted
throughout the 1990s to achieve the more integrated position shown in Figure 3.17(b). Here
the technology architecture, applications, data architecture and process architecture are uni-
form and integrated across the organization. To achieve this many companies turned to
Enterprise resource enterprise resource planning (ERP) vendors such as SAP, Baan, PeopleSoft and Oracle.
planning (ERP) The approach of integrating different applications through ERP is entirely consistent
applications
Software providing with the principle of e-business, since e-business applications must facilitate the integration
integrated functions for of the whole supply chain and value chain. It is noteworthy that many of the ERP vendors
major business functions such as SAP have repositioned themselves as suppliers of e-business solutions! The difficulty
such as production,
distribution, sales, finance for those managing e-business infrastructure is that there is not, and probably never can be,
and human resources a single solution of components from a single supplier. For example, to gain competitive
management.
edge, companies may need to turn to solutions from innovators who, for example, support
new channels such as WAP, or provide knowledge management solutions or sales manage-
Debate 3.2 ment solutions. If these are not available from their favoured current
supplier, do they wait until these components become available or do they
Best of breed vs single-source
attempt to integrate new software into the application? Thus managers
systems
are faced with a precarious balancing act between standardization or core
Selecting ‘best-of-breed’ applications
from multiple system vendors for product and integrating innovative systems where applicable. Figure 3.18

different e-business applications such (illustrates this dilemma. It shows how different types of applications
as enterprise resource planning, tend to have strengths in different areas. ERP systems were originally
customer relationship management, focused on achieving integration at the operational level of an organiza-
transactional e-commerce and supply
chain management is a better tion. Solutions for other applications such as business intelligence in the
approach for an effective e-business form of data warehousing and data mining tended to focus on tactical
infrastructure than using a single- decision making based on accessing the operational data from within ERP
vendor solution. systems. Knowledge management software (Chapter 10) also tends to cut
across different levels of management. Figure 3.18 only shows some types
of applications, but it shows the trial of strength between the monolithic ERP applications
and more specialist applications looking to provide the same functionality.
In this section we have introduced some of the issues of managing e-business infrastruc-
ture. These are examined in more detail later in the book. Figure 3.19 summarizes some of
these management issues and is based on the layered architecture introduced at the start of
this section with applications infrastructure at the top and technology infrastructure
towards the bottom.