311
The design of integrated information systems
using business analysis. Case study 4
David Jakob
Central Marketing, British
Telecom/National Networks, London
EC2V 7AG, United Kingdom
A brief description of the use of business analysis in the
design and specification of an Integrated Information System
within British Telecom is given. The role of the end users in
this process is emphasised. The paper concludes that this
methodology ensures that end users are provided with a system
which they want.
1. Introduction
British Telecom (BT) is currently investigating
a number of ways and means to provide managers
with the means of accessing relevant information
online. Within the National Networks (NN) Divi-
sion this is being achieved by the use of a business
analysis methodology to aid in the design and
specification of appropriate systems. This paper
discusses the merits of such a methodology and is
illustrated by a description of a system currently
under development, known as the Management
Information and Finance (MI&F) system.
As this paper is intended to show how an
information scientist can exploit his or her talents
in new directions, it is necessary to give a brief
picture of my own background and my role within
the project that I shall describe.
I finished my first degree in Philosophy and
Psychology at Leeds University in 1976. Prior to
that I worked for a number of years as a subcon-
tractor in the Engineering and Electronics In-
dustry. I continued doing this on completion of
my studies, until in 1983 I gained a place at City
University to do an MSc in Information Science.
In 1984, I joined British Telecom, who allowed me
to complete my thesis whilst working for them [1].
I was employed by a marketing department. Be-
cause of my interest in computing, I was given a
role in which I acted as the interface between the
marketing department and the main computing
North-Holland
Journal of Information Science 12 (1986) 311-315
Downloaded from jis.sagepub.com at PENNSYLVANIA STATE UNIV on March 6, 2016
division. function was to specify the market-
My
for in-house systems as well as divi-
ing content
sional projects. As such, BT trained me in market-
ing and in business analysis, both of which built
on knowledge I had gained from the information
science course. I fulfilled this role for almost two
years, during which time I helped to specify and
implement two large mainframe projects (includ-
ing the MI & F system), and numerous micro based
ones. I am currently employed by the same de-
partment, but have moved to doing work in the
strategic market planning section. It must be
stressed that this paper presents a personal view
and is not necessarily the view held by British
Telecom.
2. Background and objectives to the MI & F system
As the overall design of the system reflects
partially theorganization within NN, it is neces-
sary to provide a brief description of this struc-
ture.
National Networks has two major subdivisions,
and several central functions. Thus we have Trunk
Services which controls the national trunk com-
munications network, and Specialised Services with
a number of product lines controlling a variety of
products and services using the trunk network.
Examples of these products include telex, private
circuits and the public data network using packet
switching. In addition there is a central sales force
which deals with BT’s major National Accounts,
and other central functions including a Commer-
cial Management Unit and the Marketing Divi-
sion of which I am a member.
Product lines contain functional groups con-
cerned with e.g. engineering, network planning,
product marketing and finance.
The objective of the MI & F system is to pro-
vide senior managers within NN with both a
marketing and financial view of their business in
order to aid decision making. The part of the
system dealing with finance is used primarily for
cost accountancy and has been developed as a
312
separate database. I do not intend to devote any
time to describing this part of the project. It is the
development of the marketing information system
which will be used to illustrate the value of busi-
ness analysis. Suffice it to say, at present, that in
the long term the intention is to integrate the two
parts.
The target audience for this system includes
managers and directors at board level as well as
the more senior managers within the product lines.
As such they are a diverse set of users, with a wide
range of differing information requirements. Ex-
amples of the type of information include en-
gineering information about products/services,
revenue details,customer information and compe-
titorprofiles. This means that the system will have
to cope with both numeric and textual data. It will
also have to have links to other systems which
currently hold this information.
The design must be capable not only of satisfy-
ing these needs, but must do so consistently and
economically. This is to be achieved by ensuring
that there is a single front end which is simple and
friendly to use; the data must be consistent and
minimize duplication; it must be flexible and able
to change as the business grows; and finally, it
must be able to support the functions performed
by the specific users. Clearly this is a tall order for
any system designer, so how are they to proceed?
3. Business analysis
It is in this context that business analysis can
play a crucial role. This methodology can be de-
scribed as: providing a clearly structured and
rigorous approach applied to the understanding of
the business; involvement of the users during the
lifetime of the project, both in the provision of the
information and in the validation of the analyst’s
understanding; and finally the use of a set of tools
which &dquo;provide a common language for the users,
analysts and designers to communicate their un-
derstanding&dquo; [2].
The most important role in the design of the
MI & F or
any other system is that of the user. The
methodology recognizes that they are the only
people who know what functions they perform
and what that entails in terms of information.
They are the people who actually perform the
work which the system is intended to support.
Downloaded from jis.sagepub.com at PENNSYLVANIA STATE UNIV on March 6, 2016
This means that they are ideally suited to specify
the exact requirements.
The users involvement must continue through-
out the project, especially in setting objectives,
standards, acceptance testing and trialling. After
implementation and hand-over of the system, this
involvement continues in the form of suggested
enhancements and changes. Thus, the responsibil-
ity for the final product is firmly placed in the
hands of the users, with the quality of the system
determined by the degree of their involvement in
the project.
The problem is that users are not generally
trained in systems analysis or the design of com-
puter systems. It is here that the business analyst
can help, by working alongside the users. It is
their role to draw out the information from the
users and convey this to the designer in terms
which both sides can understand and agree. This
is done by providing a set of tools which can be
understood by both the professional system desig-
ner and the specific user(s). The tools used are the
’Function’ and ’Entity’ models, which are briefly
described below.
4. The function model
This model describes what business functions
are performed within the organization, and the
relationships between them. This is done by
arranging them in a hierarchical order. Table 1 is
a simple example of this.
It can be seen from this example, that functions
F4100-F4800 are all subsumed and implied by
the top level function F4000. Each of the sub-
sidiary functions can, in turn, be subdivided.
Functions at the lowest levels will then form part
of the systems application program. This task is
repeated for the whole of the business under anal-
ysis and forms the function model.
The model describes the business functions
which need to be performed, regardless of how or
who is performing them. In many instances, it will
in fact describe an ideal system, which allows for
future growth within the business. It may also
help by suggesting ways to restructure the organi-
zation more efficiently.
The model is constructed by the use of a ’top
down’ interviewing method. This means that the
analyst will start by asking the most senior
 313

Tahle 1 management. Having prepared a formal version of

Example of a function hierarchy the model, the analyst then requests the inter-
viewees to validate it. The final model is that
which accurately reflects the users views and un-
derstanding, and is completely understood by them
and the analysts.

5. The entity model

This model describes the information items

managers about their view of the business, and
their role within it. They will also be asked what
they consider they should be doing and where they
consider the business is going. This process is
repeated at lower levels of management, until a
complete function model can be provided. Usually
this involves no more than three or four levels of
which are required to support the business func-
tions, and the relationships between them. It will
subsequently form the main input into the design
of the system’s database and dictionary. Figure 1
is a simple example of such a model.
Each entity (those items in the boxes) has,
additionally, a number of attributes associated
with it. So, for example, the customer entity will
have attributes such as Name, Reference number,
Headquarters address, Contact name, etc. within
it. The lines between the boxes describe the rela-
tionships which exist. An example of this is that
’each and every’ (the crows foot) SITE must (solid
line) be owned by ’a’ CUSTOMER. Conversely,
’a’ CUSTOMER may (dotted line) be the owner
of ’each and every’ SITE.
Cross validation between the function and en-
tity models is done by the use of a Function/En-
tity Matrix. This will indicate whether an entity is
created, deleted, updated and/or displayed by
each function. This not only ensures that all the
necessary information items have been included,
but is also a good indicator when doing a sizing
exercise for the database.

Fig. 1. Example of an entity model.

Downloaded from jis.sagepub.com at PENNSYLVANIA STATE UNIV on March 6, 2016

314

6. Design of MI & F -
Sales breakdown by product.
Phase C: Competitor Information such as
After the initial analysis, it was recommended - Name,
that an ’architecture’ approach be used in the -

Product Type,
design of the required system. Thus, each product -

Application.
line, including National Account Sales, is to de- -

velop its own comprehensive systems. This is nec-
essary, as each require information at a very low
level to control their business. Additionally, there
are fundamental differences at those levels be-
tween the product lines, which prevent them from
Market Shares,
-
References and locations.
This will involve the integration of information
from a variety of sources including sales, engineer-
ing, finance and marketing. The reference material
on competitors will come from a variety of textual

using the same database. databases within the company.

The marketing system, on the other hand, is
intended for use by the more senior managers.
Their needs are satisfied primarily by more ag- 7. Current status .

gregated information. At that level each database

will have a common structure and the product line
systems will therefore be able to feed the market-
ing system directly. This is represented diagram-
matically in Fig. 2.
The marketing system will hold information in
three groups each of which is being built as a
separate phase of the project. These are detailed
below.
Phase A: Product Information such as
-
The system has been built on a central Amdahl
machine using Cullinet’s IDMS/R database prod-
uct. Terminals have been located within some of
the relevant managers’ offices, linked to the
mainframe by KiloStream circuits.
The system was designed, after analysis, by
using ADS ONLINE as a prototyping tool. This
meant that users were able to see what the finished
product would look like prior to the development

Product type, .

of the application programs. Because of this ap-

Number of orders/sales,
-

proach, the users were able to comment and amend

Number of installations
-
.

the system without any significant impact on

-

Performance/Quality measures, timescales.

-

Distributions e.g. by industry, Geography, Phases A and B were released for user trialling
Company size, during December 1985. The whole development
-

Distributions by Application e.g. Data, from initial analysis to implementation has taken
Video, Text. 12 months to complete. Phase C is currently under
Phase B: Major Account Information such as development having already been prototyped and
-

Name, accepted. Testing is due to begin during March

-

Company structure, 1986.

-

Revenue breakdown e.g. by Product, Appli- The full implementation (i.e. connecting all the
cation, selected users on the system) is dependent on

Fig. 2. Schematic of NN information system architecture.

Downloaded from jis.sagepub.com at PENNSYLVANIA STATE UNIV on March 6, 2016


loading all the data into the system. This is cur-
rently under way, and should be completed shortly.
Three of the product line systems have been
designed and are now under development.
8. Conclusion
The methodology of business analysis has al-
lowed us to design a number of inter-related sys-
tems which, we are sure, reflect the needs of the
business. The use of common design tools and
software will ensure consistency.
An undoubted conclusion has been that the
role of the users in this process is the key to
success. Within the MI & F project this has been
clearly demonstrated. Senior members of staff have
been sitting on the project board, which has a
strong influence on the commitment from staff at
Downloaded from jis.sagepub.com at PENNSYLVANIA STATE UNIV on March 6, 2016
315
other levels. Without this, it is doubtful if the
system would enjoy its current success in terms of
its acceptance by management within National
Networks. This contrasts sharply with the numer-
ous instances quoted in the computing press, where
users complain of systems which do not fulfil their
expectations (e.g. [3]).
References
[1] D. Jakob, A statement of requirements for the British
Telecom Specialised Services Integrated Database project,
unpublished thesis, City University, Information Science
Department, London, September 1984.
[2] A. Hakim, Data analysis as a toolbox not a bible, Paper
presented at the BCS Database Conference 85, 16/17 April
1985, Huddersfield Polytechnic.
[3] D. Jakob, The analysis of end user functions and their
information requirements, unpublished paper, December
1985.