LILIANA MARISOL SEPULVEDA GARCIAdagda.shef.ac.uk/dispub/dissertations/2011-12/... · LILIANA...
103
Design, Development and Evaluation of a Management Information System (MIS) Prototype A study submitted in partial fulfilment of the requirements for the degree of Master of Science in Information Management at THE UNIVERSITY OF SHEFFIELD by LILIANA MARISOL SEPULVEDA GARCIA September 2012
Transcript of LILIANA MARISOL SEPULVEDA GARCIAdagda.shef.ac.uk/dispub/dissertations/2011-12/... · LILIANA...
Design, Development and Evaluation of a Management
Information System (MIS) Prototype
A study submitted in partial fulfilment
of the requirements for the degree of
Master of Science in Information Management
at
THE UNIVERSITY OF SHEFFIELD
by
LILIANA MARISOL SEPULVEDA GARCIA
September 2012
2
Abstract
Background: Sheffield Forgemasters International Technical Department’s high
productivity demands a system that will help them in the management of their
information. As part of a solution to this problem they have decided that the adoption of
a system that will allow them to store, retrieve and create reports will help them in their
decision making process that will solve their identified problem.
Aims: This investigation aims to design, develop and evaluate a Management
Information System (MIS) prototype for Sheffield Forgemasters Technical Department
for the improvement of materials that will support the decision making process and
propose which functions such system should contain.
Methods: The research adapted a methodology based in Design Research where it
incorporates Rapid Application Developments in the development stage. This
methodology has five stages that include: 1) Problem identification and motivation, 2)
Define Objectives for solution, 3) RAD, 4) Evaluation and 5) Communication. The data
was collected in the evaluation phase and was qualitative mainly in the form of
notebook annotations and memorandums that contained the end users feedback.
Results: The desirable structure a MIS should contain based in the investigation
includes a creating, modifying, reporting and calculating facility. Calculating is the only
feature that literature does not suggest, making this a highlighted finding of the
investigation. The basic functions that are proposed are: a user friendly interface, a
relational database to correctly manage data, realtime processing, and on demand
reports.
Conclusions: The final application was successfully introduced to the company where
it has received a warm acceptance by all end users. The research led to several
findings proving that the adapted methodology will work under circumstances similar to
the ones in this investigation and might help other researchers in the same situation.
Although this was just a prototype, there is still further work needed to extend this
system and lead to other interesting findings.
3
Acknowledgement
To my soulmate and best friend Daniel, who has been there for me every single day
since the beginning of this journey. Thank you for making me a better woman, for
teaching me that things are not so bad as I imagine and for constantly encouraging me
to continue in the pursuit of my dreams. You are my rock.
To my mother that was always there supporting and sending her love whenever
needed. Thank you for always believing in my potential. Your love was felt even though
we are thousands of kilometres apart. Hope that I can continue to keep you proud over
the years.
To CONACYT the institution from my federal government that rewarded me with the
scholarship that made this degree possible.
To my supervisor Miguel Nunes, that made me see skills in me that I never
acknowledge before and for providing me with his expertise to finish my investigation.
To Sheffield Forgemasters for receiving me warmly into their facilities. I will like to
specially thank Dr. Martin Kearney for giving me the opportunity to make my
investigation in his department and Magali Toulze for her patience, time and guidance
throughout the project. Thank you all for believing in me and my work, I will always
remember your kindness and it was an honour to contribute in this important company.
4
Contents
ABSTRACT .............................................................................................................................................. 2
ACKNOWLEDGEMENT ............................................................................................................................ 3
CONTENTS .............................................................................................................................................. 4
LIST OF FIGURES ..................................................................................................................................... 7
CHAPTER 1 INTRODUCTION.................................................................................................................... 8
1.1 CONTEXT OF THE PROJECT .................................................................................................................... 8
1.2 AIM ............................................................................................................................................... 9
1.3 RESEARCH QUESTIONS ...................................................................................................................... 10
1.4 OBJECTIVES .................................................................................................................................... 10
1.5 DISSERTATION OUTLINE .................................................................................................................... 10
CHAPTER 2 MANAGEMENT INFORMATION SYSTEM (MIS) IN THE MANUFACTURING INDUSTRY ......... 12
2.1 INTRODUCTION ............................................................................................................................... 12
2.2 INFORMATION SYSTEMS (IS)............................................................................................................... 12
2.2.1 Introduction ........................................................................................................................ 12
2.2.2 Managerial levels................................................................................................................ 13
2.2.3 Types of Systems ................................................................................................................. 15
2.2.3.1 Operational Level: Transactional Process System (TPS) ................................................................ 16
2.2.2.2 Tactical Level: Management Information System (MIS) and Decision Support System (DSS) ........ 16
2.2.2.3 Strategic Level: Executive Information Systems (EIS) ................................................................... 19
2.2.4 Conclusion ........................................................................................................................... 19
2.3 UNDERSTANDING MANAGEMENT INFORMATION SYSTEMS (MIS) ................................................................ 20
2.3.1 Introduction ........................................................................................................................ 20
2.3.2 Different connotations given to MIS.................................................................................... 20
2.3.3 Benefits of MIS .................................................................................................................... 21
2.3.4 MIS Components of Application .......................................................................................... 22
2.3.5 Functional Components of Application ................................................................................ 23
2.3.4.1 Graphical User Interface (GUI) ..................................................................................................... 24
2.3.4.2 Data Management ....................................................................................................................... 24
2.3.4.3 Processing.................................................................................................................................... 26
2.3.4.4 Reporting ..................................................................................................................................... 26
2.3.6 Conclusions ......................................................................................................................... 27
5
2.4 ROLE OF MIS IN THE MANUFACTURING INDUSTRY ................................................................................... 28
2.4.1 Introduction ........................................................................................................................ 28
2.4.2 MIS supporting organisational subsystems ......................................................................... 28
2.4.3 Examples of MIS supporting the Manufacturing Industry ................................................... 29
2.4.4 Challenges in MIS as subsystems in the manufacture industry ............................................ 29
2.4.5 Conclusion ........................................................................................................................... 30
CHAPTER 3 METHODOLOGY ................................................................................................................. 31
3.1 INTRODUCTION ............................................................................................................................... 31
3.2 DESIGN RESEARCH (DR) .................................................................................................................... 31
3.2.1 Design Research in Information Systems ............................................................................. 32
3.2.2 Design Research Methodology ............................................................................................ 33
3.2.2.1 Phase 1: Problem identification and motivation ........................................................................... 34
3.2.2.2 Phase 2: Define the objectives for a solution ................................................................................ 34
3.2.2.3 Phase 3: Design and Development ............................................................................................... 34
3.2.2.4 Phase 4: Demonstration ............................................................................................................... 34
3.2.2.5 Phase 5: Evaluation ...................................................................................................................... 34
3.2.2.6 Phase 6: Communication.............................................................................................................. 35
3.2.2.7 Entry Points ................................................................................................................................. 35
3.3 HOW DESIGN RESEARCH WAS USED...................................................................................................... 35
3.3.1 Application of Phase 1: Problem identification and motivation ........................................... 36
3.3.2 Application of Phase 2: Define the objectives for a solution ................................................ 37
3.3.3 Application of Phase 3: Rapid Application Development (RAD) ........................................... 38
3.3.3.1 Requirements Planning ................................................................................................................ 39
3.3.3.2 User Design .................................................................................................................................. 40
3.3.3.3 Construction ................................................................................................................................ 41
3.3.3.4 Cutover ........................................................................................................................................ 41
3.3.4 Application of Phase 4: Evaluation ...................................................................................... 42
3.3.4.1 Observation ................................................................................................................................. 42
3.3.4.2 Discussion after observation ........................................................................................................ 42
3.3.4.3 Negotiation of new requirements and modifications for prototype improvements ...................... 43
3.3.5 Application of Phase 5: Communication .............................................................................. 43
3.4 CONCLUSION .................................................................................................................................. 44
CHAPTER 4 RESULTS ............................................................................................................................. 45
4.1 INTRODUCTION ............................................................................................................................... 45
4.2 PROTOTYPE 1 ................................................................................................................................. 45
6
4.2.1 How Phase 3: RAD was applied in prototype 1 .................................................................... 45
4.2.1.1 Requirements .............................................................................................................................. 45
4.2.1.2 Design .......................................................................................................................................... 46
4.2.1.3 Construction ................................................................................................................................ 48
4.2.2 How Phase 4: Evaluation was applied in prototype 1 .......................................................... 49
4.2.2.1 Results from observation ............................................................................................................. 49
4.2.2.2 Discussion after observation ........................................................................................................ 50
4.3 PROTOTYPE 2 ................................................................................................................................. 51
4.3.1 How Phase 3: RAD was applied in prototype 2 .................................................................... 51
4.3.1.1 Requirements .............................................................................................................................. 51
4.3.1.2 Design .......................................................................................................................................... 52
4.3.1.3 Construction ................................................................................................................................ 53
4.3.2 How Phase 4: Evaluation was applied in prototype 2 .......................................................... 53
4.3.2.1 Results from observation ............................................................................................................. 53
4.3.2.2 Discussion after observation ........................................................................................................ 53
4.4 FINAL APPLICATION .......................................................................................................................... 54
4.6 LESSONS LEARNED ........................................................................................................................... 54
4.6.1 Theory ................................................................................................................................. 55
4.6.2 Practical .............................................................................................................................. 57
4.6.3 Methodological ................................................................................................................... 58
CHAPTER 5 CONCLUSIONS .................................................................................................................... 60
5.1 RELATING FINDINGS WITH RESEARCH QUESTIONS ..................................................................................... 60
5.2 CONTRIBUTION TO KNOWLEDGE .......................................................................................................... 61
5.2.1 Contribution to the Information Systems field ..................................................................... 61
5.2.2 Contributions to Research Methods. ................................................................................... 62
5.3 LIMITATIONS OF THE RESEARCH ........................................................................................................... 62
5.4 FURTHER WORK............................................................................................................................... 63
REFERENCES ......................................................................................................................................... 64
APPENDIX 1: DATABASE DESIGN AND DEVELOPMENT DETAILS............................................................ 69
APPENDIX 2: PROTOTYPE 1 .................................................................................................................. 72
APPENDIX 3: PROTOTYPE 2 .................................................................................................................. 78
APPENDIX 4: FINAL APPLICATION ......................................................................................................... 83
APPENDIX 5: PLANNING (NOTEBOOK ANNOTATIONS) ......................................................................... 87
7
List of Figures
FIGURE 2-1 MANAGERIAL LEVELS OF AN ORGANISATION . .......................................................... 14
FIGURE 2-2 SYSTEMS THAT WILL BE HIGHLIGHTED IN THIS DISSERTATION ........................................ 15
FIGURE 2-3 SUGGESTION OF HOW A DETAILED REPORT MIGHT LOOK LIKE. ...................................... 17
FIGURE 2-4 SUGGESTION OF HOW A SUMMARY REPORT MIGHT LOOK LIKE. ..................................... 17
FIGURE 2-5 SUGGESTION OF HOW AN EXCEPTION REPORT MIGHT LOOK LIKE. .................................. 18
FIGURE 2-6 COMPONENTS OF AN MIS .................................................................................. 23
FIGURE 3-1 REASONING IN THE DESIGN CYCLE .......................................................................... 32
FIGURE 3-2 DESIGN SCIENCE RESEARCH METHODOLOGY (DSRM) PROCESS MODEL SUGGESTED BY
PEFFERS ET AL. (2008) WITH ALL OF THE POSSIBLE RESEARCH ENTRY POINTS. ........................... 33
FIGURE 3-3 MODIFIED METHODOLOGY THAT WILL BE USED DURING THE COURSE OF THIS DISSERTATION. 36
FIGURE 3-4 TRADITIONAL SOFTWARE DEVELOPMENT VS. RAD . ................................................... 38
FIGURE 3-5 RAD CYCLE AS SUGGESTED. ................................................................................. 39
FIGURE 3-6 DESIGN APPROVED BY END USER IN JAD MEETING. .................................................... 41
FIGURE 3-7 FORMAT UTILISED FOR OFFICIAL CHANGES, MODIFICATIONS AND REQUIREMENTS. ............. 43
FIGURE 4-1 MENU STRUCTURE OF THE MIS PROTOTYPE SYSTEM. ................................................. 47
FIGURE 4-2 GENERAL SYSTEMS’ LOGICAL FLOW ....................................................................... 48
FIGURE 4-3 MAIN MENU DISPLAYED TO END USERS IN FIRST OBSERVATION EXERCISE......................... 49
FIGURE 4-4 SPLIT FORM BOTTOM PART DOES NOT MATCH THE TEXTBOXES IN THE FORM..................... 50
FIGURE 4-5 ADDITION LEVEL ‘EXTRAPOLATION OF DATA’. .......................................................... 52
8
Chapter 1 Introduction
1.1 Context of the project
Every year in the UK industry sector, companies spend thousands of pounds utilising
duplicate information. A report made by Experian reveals that 85% of enterprises works
with duplicate information every month making the transfer of information, the use of
time and production unbalanced (Taylor, 2008). Likewise, Dekker (2001) explains that
there is a growing concern in many organisations with the input of data that contains
typographical mistakes which many people refer to as typos. He suggests that when
this occurs, data retrieving is not accurate, it creates confusion and decision making is
difficult. Conversely, another major problem is when employees do not find the
information they are looking for in their own files. This may be because they do not
have a centralised database (i.e.: they just use Excel or Word files) that will help them
retrieve data or because files are not stored properly (i.e.: they are given complex
names or incompatibility of formats). The IDC in their report “Hidden Costs of
Information Work in the Enterprise” reveal that an average worker spends 6.2 hours
every week looking for the right information (Feldman et al., 2005). In an urge to change
this, many companies turn to technology to resolve these issues. Levesque (2011)
explains that many companies lack an IT department that deals with these
complications. In other words, IT departments are seen as a group of technicians that
only fix computers and printers, instead of being seen as professionals that can be
capable of developing systems that satisfy the company’s information needs. He
continues explaining that 52% rely on outsourcing the construction of an Information
System (IS). There are different types of IS that support specific industry functions. In
the case of manufacturing, an important activity is “improving a product and product
differentiation” (Long, 1989, p.102). Therefore, a useful IS could be one that could
facilitate the storing and extrapolation of strategic data in the form of reports to analyse
current and historical data that will enhance those activities and prevent the duplication
of data.
9
1.2 Aim
This project aims to design, develop and evaluate a Management Information System
(MIS) prototype for Sheffield Forgemasters Technical Department, in order to
investigate how this type of system can support an engineering improvement of
materials and which functions should it contain. This prototype will help the company to
organise and store the information produced for specific Tensile and Metallography
Tests, which are mechanical properties, which will allow them the retrieval of
information in the form of custom made reports. This will help them in their decision
making process to decide which materials can be improved and further their research in
the variety of their products. Improvement of materials occurs when they compare the
heat treatment conditions of products against specific mechanical properties (Tensile
and Metallography) to decide which heat treatment condition and parameters are
suitable for specific products. Also, this system will allow them to update their
information from any computer connected through the department’s network. The
creation of this prototype will help in the course of this investigation as the practical
experience of this project will reinforce the literature shown in the dissertation and will
give lead to the answering of the proposed research questions.
This project was born from the necessity of the department to organise their information
in a centralised database that will help them retrieve reports, avoid duplicates and
typographical mistakes in their files to effectuate a better management of their
information. Currently, they only use Microsoft Word, Excel and physical documents to
perform their duties, making them spend a considerable amount of time searching for
the desired information.
This matter will be taking place at the facilities of Sheffield Forgemasters International.
The goal of this project is to create a useful MIS that will satisfy the client’s needs and
evaluate thorough design research the upcoming prototype’s development and any
issues encountered.
10
1.3 Research Questions
The following portrays the fundamental research questions that are intended to unfold
in the course of this investigation.
-What is an ideal MIS System to support decision making in the engineering
improvement of materials?
-What are the functions for such a system?
1.4 Objectives
The objectives for the dissertation are as follows:
-To identify the department’s fundamental information needs.
-To understand the flow of information in the department.
-To understand what kind of reports will improve the decision making process in this
department.
-To create an interface that is suitable to the company’s goals and main values.
-To contribute any knowledge perceived or deducted to Information System Design
Research.
-To discover suitable functions for an MIS in engineering department of a manufactory
industry.
1.5 Dissertation Outline
Chapter 1 presents an introduction to the dissertation framework. Some of the
highlighted points are the investigation research questions, objectives and the overall
aim. The chapter finalises with the dissertation outline.
Chapter 2 focuses in explaining in depth the concept of Management Information
Systems (MIS) as this is the intended final product of the prototype that is going to be
11
created in this project. In order to introduce the reader into the context, it is firstly
explained what constitutes an Information System and the different roles it can play in a
managerial environment. The literature review continues highlighting trade
characteristics, differentiations between MIS and other systems and their main
components. The chapter finalises with the role that MIS have been playing in the
Manufacturing Industry in the past years.
Chapter 3 explains the methodology that was used during this dissertation. It starts by
defining the selected methodology Design Research and how it is currently being used
in the Information System field. The literature follows with a description of how it was
used in the project with the incorporation of Rapid Application Development for the
development stages and presents the concept of prototyping in this context.
Chapter 4 states the findings of the investigation; these include the description of each
of the prototypes results and the final application. The chapter ends by stating the
lessons learned with the findings from a theoretical, practical and methodological point.
Chapter 5 presents the conclusions from this dissertation this will cover the answering
of the research questions, contribution to knowledge, the limitations the investigation
had and finally future work that could be done.
12
Chapter 2 Management Information System (MIS) in the Manufacturing Industry
2.1 Introduction
The following is an overview that looks in depth at MIS. It starts by identifying in which
level of an organisation they are intended to perform and how they are differentiated
from other systems. Aspects like the main characteristics, benefits and components
complement the literature for this particular dissertation. To finalise this chapter the role
of MIS in the manufacturing industry is explained to give a background understanding of
this project.
2.2 Information Systems (IS)
2.2.1 Introduction
In order to have a clear understanding of what IS are, it is important to split the
definition into two parts. To start with, the meaning of information is so broad that
defining it is difficult. Therefore, for the purpose of this investigation information will be
referred to as:
“Data that has been processed or manipulated intentionally for a particular context”
(Curtis & Cobham, 2005; Long, 1989; Davis, 2005)
Furthermore, system is another complex term. For this dissertation the focus will only
be in physical systems defined as: “a collection of interrelated parts that taken together
form a whole with purpose and it changes if any of the parts leads to or results from a
change” (Curtis & Cobham, 2005).
13
Analysing both meanings it is clear that the concept of IS is a jointure of the best of both
worlds. As Stair & Reynolds (2008) suggests it deals with the input, processing and
storing of the information a company has for further retrieval into a particular context.
Although this is not an accurate description, it is based upon the previous def initions
given for information and system.
Many authors discuss the different angles and meanings an IS may have (Beynon-
Davies, 2002; Kendall & Kendall, 2004; Ward & Peppard, 2002; Curtis & Cobham,
2005; O’Brien, 1990), notwithstanding it is important to keep in mind that as this project
deals with the creation of a computerised information system for a particular
organisation any reference to this concept will be exclusively dealing with their usage as
support in organisations. In other words, the focus of this concept will be narrowed to
only systems that work with managerial activities in a company that provide an output
that helps in specific tasks to managers.
2.2.2 Managerial levels
There is a consensus between authors in what Anthony (1965) suggested regarding a
standardised structure for managerial levels in organisations. For instance, Long (1989)
suggests that these levels were created to filter the information that can be accessed in
the different positions in an organisation. He continues to emphasise the importance of
filtering as an action because when the right information is provided in a suitable form,
the decision process becomes easier. The three stated managerial levels are:
Operational, Tactical and Strategic (Anthony, 1965; Kendall & Kendall, 2004; Curtis &
Cobham, 2005; Long 1989; Bagad, 2009).
As Figure 2-1 illustrates, these three levels are represented through a pyramid that
suggests the ranks within an organisation. The bottom part of the pyramid symbolises
the Operational Level that as Long (1989) described, deals with temporary tasks and
does not require the personnel involved in it to deeply analyse situations or scenarios
regarding their departmental function. Curtis & Cobham (2005, pg.10) complements
this idea by stating that this level performs day to day activities of the organisation that
are “immediate, highly detailed and frequent”.
14
Moreover, the middle part of the figure represents the Tactical Level. Long (1989)
explains that their major role is to manage and plan medium term work activities that in
some cases requires analysing multiple scenarios (‘what if’ reports) that may be seldom
conclusive. He furthers his explanation by adding that many of the decisions taken in
this level are relying on manager’s personal judgment and experience rather than any
kind of collected information.
The top part of the figure corresponds to the Strategic Level. Kendall and Kendall
(2005) describes this level as the highest rank in an organisation, meaning that the
decisions they take are crucial for the survival of a company. These decisions are long
term and they normally have to be aligned to the business objectives. Long (1989)
states that managers in this level are very objective and regularly use the ‘what if’
reports to predict trends or analysis of specific situations. It is important to highlight the
regularity of the reports at each managerial level as this point will be explained upon
when the details of the project are described.
Figure 2-1 Managerial Levels of an Organisation adapted from Long (1989).
15
2.2.3 Types of Systems
For the purpose of this dissertation as there is a great variety of IS for managerial
support, only a few will be focussed on. The ones that will be highlighted are systems
that are most commonly confused in relation to the MIS which is the IS that will be
developed in this project. This will clarify the differences that exist between the systems.
Similar to managerial levels, literature shows that several authors (Kendall & Kendall,
2005; Boddy et al., 2005; Sadagopan, 2004; Bagad, 2009) represent the different types
of IS in the form of a pyramid like that shown in Figure 2-2. Kendall and Kendall (2005)
explain that the analogy with this shape is recurrent because when the different types of
systems were defined most companies used the organisational pyramid structure to
represent their hierarchies. Therefore, managerial levels and the different types of IS
interrelate as the pyramid levels dictate the desirable functions that they should
perform. The selected IS for these classifications are: Transactional Process System
located in the Operational Level, Management Information System and Decision
Support System in Tactical Level and finally Executive Information System for the
Strategic Level. Two main IS are located in the Tactical Level purposely as literature
highlights a confusion between these systems. Every given description will be
exemplifying only general features to point out the role they play in each managerial
level.
Figure 2-2 Systems that will be highlighted in this dissertation, adapted from Kendall and
Kendall (2005)
16
2.2.3.1 Operational Level: Transactional Process System (TPS)
Bagad (2009, pg.16) stated that TPS as the name suggests, are systems that “record
and process data resulting from business transactions”. Rainer & Cegielski (2010)
emphasize the importance of these systems by describing them as pillars of any
business information. They continue by explaining that these IS collect all kinds of data
such as numbers from prices and dates from contracts, amongst other things that will
later be used by other IS located in a higher level. However, Morley & Parker (2009)
indicate that TPS deal with extensive volumes of data every day and that in order to be
efficient, the functions they accomplish must be standard at all times. They also
explained that the existence of other systems that depend on them to perform their core
functions (as they need to extract data from TPS or copy TPS behaviour) enabled them
survive through all these evolving technologies.
2.2.2.2 Tactical Level: Management Information System (MIS) and Decision Support System (DSS)
The main objective of MIS is to collect data that will be converted into information, in
order to be communicated to different departments that can make tactical or strategic
decisions (Mohapatra & Prasad, 2012; Lucey, 2005). Kendall & Kendall (2004)
explained that MIS are frequently used by middle to top management levels and they
clarify their argument by referencing the pyramid pointed out in Figure 2-2. MIS help in
different hierarchies in an organisation, but as Shajahan (2004) suggests it always have
to have a managerial approach as their focus is to support these activities. He
continues by explaining that this systems support “planning, organising, staffing,
coordination, control and decision making activities” (pg. 24). Long (1989) indicates
that custom made or informative reports are compiled when they want to focus this
system into managerial decision making and always deals with already structured
problems. He continues explaining that contrary to TPS’s they are highly adjustable to
modifications and are malleable to the changing business information needs. Likewise,
Morley & Parker (2009, pg.509) complement Long’s contribution by referring to MIS as
“information reporting systems”, highlighting the fact that three of the reporting styles
are: detailed, summary and exception reports.
17
These reports are well defined by Reynolds (1995) who suggests that detailed reports
deal directly with transactional actions. He furthers by saying that this reports are most
likely what a TPS would have as an output and represents in detail a line stored in a
database. Figure 2-3 illustrates a sample of this kind of report. Likewise, Reynolds also
explains what a summary reports contains. He refers to them as reports that reflect the
accumulation of many transactions that can be added to show a total result. It is highly
important that this added figure is a number and it is related to a unique identifier.
Figure 2-4 represents what a summary report might look like. Last type of report, is
called exception report that only presents data with abnormal situations in a specific
context. Reynolds explains that these reports are of high value to managers as they
show only cases or scenarios that need special attention. This can be seen as time
saving and relevant to highly effective managers. Figure 2-5 demonstrates how an
exception report might be presented.
Figure 2-3 Reynolds (1995) suggestion of how a Detailed Report might look like.
Figure 2-4 Reynolds (1995) suggestion of how a Summary Report might look like.
18
Figure 2-5 Reynolds (1995) suggestion of how an Exception Report might look like.
On the other hand we have DSS that are characterized for allowing the user to retrieve
specific data for their specialised reports with the help of a user friendly or interactive
interface (O’Brien, 1990). Davis (2005, pg.81) states that the main objective of a DSS is
to provide managers with substantial information that will give them “an understanding
of the environment and an examination of relevant alternatives”. Contrary to MIS, Long
(1989, pg.46) discussed that these systems work with “semistructured and unstructured
problems”, making them more complex. He also highlighted that DSS provide
information that will guide a manager in selecting a viable solution to problems,
although it is a must that a manager’s experience and expertise become involved in any
final decision. The common uses of a DSS are for financial or statistical purposes;
however there is evidence that modern versions of this system can be used for data
mining that will help identify any problems in specific cases (Davis, 2005). Reynolds
(1995) explains that the data DSS uses to generate their reports can be from external
sources to complement what they already have in the organisation’s database. This
gives the manager the advantage to examine deeply the problem or scenario that
he/she wants to solve. He also highlights that although they can perform all of the
functions of a MIS, they are mostly used to forecast and analyse problems that require
short term or medium term planning and thinking.
19
2.2.2.3 Strategic Level: Executive Information Systems (EIS)
O’ Brien (1990) claims that an EIS is a system that aims to directly help top managers
in strategic decision making activities to analyse any factors or situations that are
preventing an organisation to fulfil their main objectives. Similar to that, Davis (2005,
pg.127) suggests that this system “extracts, filters, compresses, and tracks critical data”
to help top managers interpret scenarios with a visual interface that may present
graphics in any form and as well textual information. Reynolds (1995) contributes to this
description by adding that in order for this system to fully help managers it is crucial to
customise it, as every company has different information needs. He also states that
although EIS are targeting directly the strategic level of a company, there are cases in
which tactical personnel might use this system to fulfil their short term tasks. Withal,
Reynolds summarises the main purpose of this system by highlighting that the
information retrieved from EIS are intended to measure the organisation’s, employees
and competitors performance based in current market trends and the public’s
expectations. According to Curtis & Cobham (2005), the simulations that an EIS
perform are made for very complex scenarios and are usually related to long term
decision for a business growth.
2.2.4 Conclusion
Finding a suitable system for a company is not an easy task. As there is a great variety
of possibilities, just as Long (1989) suggests it is crucial to understand first what are the
information needs of a company before selecting an IS solution. Likewise, Kendall and
Kendall (2005) explained that as each system satisfies a different necessity, it's
important to know the user requirements, feasibility and scope. In spite of that, the
purpose of the presentation of the previous IS overview was to highlight the way it
would be referred to throughout this dissertation and emphasise the difference between
the systems that are categorised in each of the managerial levels. As this project
intends to develop an MIS it was fundamental to point out the main characteristics it
possess and to highlight the support it brings into the tactical level as this concepts will
be featured in the upcoming chapters. Although two systems were presented in the
tactical level, this was purposely to contrast the difference and confusion it exists
between both concepts.
20
2.3 Understanding Management Information Systems (MIS)
2.3.1 Introduction
MIS appeared in 1960 and were categorised in the family of data processing systems
(Long, 1989). They became very popular for the next ten years until a new generation
of Information Systems (IS) arise; these were their predecessors the Strategic
Information Systems (SIS) (Ward & Peppard, 2002; O’ Brien, 1990). Although MIS are
not the “today’s” system, Ward & Peppard (2002, p.18) explain that 50% of all IS
investments in organisations is designated to “data processing” technologies, hence the
importance of a MIS.
2.3.2 Different connotations given to MIS
Long (1989, pg.42) broach the subject that “there is probably less consensus on the
meaning of MIS than on any other term in the computerese vocabulary”. He continues
explaining that many people refer to it as “a method, a function, an approach, a
process, an organization, a system and a subsystem” (pg. 42), making it clear that it is
crucial to specify the focus that is going to follow throughout this investigation.
From the many connotations it has been given, Sadagopan (2004) suggests that one of
the ways authors misuse the term MIS is when people are not familiar to the informatics
terminology and tend to generalise the concept of MIS to any IS that generate Decision
Support (DS) for managers, like Decision Support Systems (DSS) and Executive
Information Systems (EIS), that were mentioned previously. In spite of that, there is a
gap between all of them and what distinguishes MIS from the rest is that they address
only formal decisions and their main function is to generate basic fixed reports for
middle to short term tasks. For that reason, Sadagopan’s meaning of MIS refers to it as
an IS.
Curtis & Cobham (2005) claim that another use for the term “management information
systems” is to encompass all of the systems that serve for management purposes at
any managerial level. This means that contrary to Sadagopan’s contribution that sees
21
an MIS as one type of the many possible managerial systems, Curtis & Cobham claim
that MIS are any kind of system with a focus in management activities. Similar to that,
O’Brien (1990, pg. 6) explains that many people also use it as a “synonym for
information system” or information management. He based his statement in the
literature he discovered between 1960-1990 that existed of MIS and believes that as
people continue to read the origins of this concept, they commonly confuse the term as
it has evolved and acquire different connotations through the years .This creates a clear
confusion in the literature because every author has to define the context in which they
will use this term.
Davis (2005) provides another possible significance to this meaning by referring to it
also as an organisational function. He describes this as a group of people in an
organisation that “plans, develops, implements, operates, and maintains the
organization’s information technology infrastructure and the organization’s portfolio of
applications” (pg. 209). Also, he furthers by advising that when they use this
connotation, the literature will focus in MIS as a company’s technical support
department, rather than a system itself.
Nonetheless, in this dissertation MIS will be referred to as Reynolds (1995, pg. 202)
defined it: “a computer system capable of integrating data from many sources to
provide data and information useful to support operations, management, and decision
making in an organization”. The useful information he refers to are reports that present
all of the necessary information a manager needs for their tactical decision making.
2.3.3 Benefits of MIS
Mohapatra & Prasad (2012) suggest that one of the benefits of MIS is that they offer
strategic support. They continue explaining that as they are able to deliver reports,
managers can analyse trends or patterns giving them valuable information. Another
advantage they present is that these tools are time saving. As many of the processes
that were manual now are being automated, users can spend their time in other
activities that will generate value to the organisation.
22
In the other hand, Sadagopan (2004) describes as an advantage the control over
redundancy. This is achieved by storing all the information in only one database, this
way avoiding the duplication in data. Conversely he adds that the sharing of resources
contributes to the benefits of an MIS. As all of the reports and data are easily reach
through an interface, users can rely that all information is viewed by other persons.
O’Brien (1990) states that MIS improve the organisation's’ communication, as this type
of system provides information in real time to other users and in the same format. He
continues explaining that even though emphasising the characteristic that everyone will
have the same format sounds irrelevant, the truth is that when employees manage
different formats and versions of a document confusion increases and duplication may
occur.
Curtis & Cobham (2005) claim that another benefit to an MIS is the ease of analysis as
this kind of system processes complex data and retrieves it in the form of standardized
reports that are easy to understand. This advantage reduces considerably time from
managers from their decision making process. They also suggest that MIS benefit users
with their interactive interface as they make the process of extraction and retrieval easy.
2.3.4 MIS Components of Application
It is important to know what comprises a MIS to fully understand what makes it work
altogether as a whole. Enduring to this, Bagad (2009) suggests that one of the
fundamental components of this type of system is the hardware dimension. He
continues explaining that this is everything related to physical equipment like CPUs,
keyboards, etc. Reynolds (1995) contributes with the software component as he
describes this as all the programs or applications that need to be running for the system
to work properly. Likewise, the database component is highlighted by O’Brien (1990) as
he describes it as the heart of the system, where all the raw data is stored and
organised. Next component is the network environment as it involves how the
computers that are linked to the system are connected to share information among
each other with the help of intranets, wireless, LAN’s, etc (Curtis & Cobham, 2005).
Last component is the people that interact with the system, Long (1989) refers to them
23
as the end users, people who give maintenance to the system and who input the data
into the system. Figure 2-6 illustrates how all of these presented components work
together in an MIS. This figure is an adaptation of all of the authors’ contributions.
Figure 2-6 Components of an MIS (Bagad, 2009; Reynolds, 1995; O’Brien, 1990; Curtis &
Cobham, 2005; Long, 1989).
2.3.5 Functional Components of Application
To extend the understanding of a MIS, it is important to clarify how each of the parts
interacts between each other. There is no consensus in what the basic functional
components are, but literature shows that similarities between authors (Murthy, 2008;
Shajahan, 2004; Bagad, 2009; Curtis & Cobham, 2005; Davis, 2005, O’Brien, 1990)
can condense into the following parts:
24
2.3.4.1 Graphical User Interface (GUI)
Reynolds (1995, pg.67) describes the GUI as the visual interface where a user with the
help of a pointing device like a mouse can “load programs, read files, and create
directories to store data”. In other words, it is the way a user inputs data into the
system. Even though Reynolds explanation is clear, the relevance of this description is
that without this interface the user will never be able to interact with the MIS, hence the
importance of this component. This step is crucial to the system as it is the one that
provides the channel to the user to insert any command or instruction (Curtis &
Cobham, 2005). Another relevant contribution is from Bagad (2009) who claims that a
well-designed GUI is fundamental for an enterprise system, as having a user friendly
interface will facilitate the input of data and also the retrieval process for inexperienced
users. Curtis & Cobham (2005) suggest that another important aspect of the GUI is that
apart from being a way to input data, it is the platform that will display to you any
possible output of the system. They further explain that every possible screen design
that will be utilised and/or displayed in the system will influence the way the user
interacts. This statement highlights the importance of the component and advises
developers to pay attention to what the user really wants visually as making a user
happy will increment the possibility of a successful implementation.
2.3.4.2 Data Management
This particular component is of great importance because it deals with what and where
the information that enters into the system is stored and how they manage it. To start
with, a MIS with no hesitation needs a database to store all of the data. Davis (2005)
suggests that a MIS can exist with one or multiple connected databases to store data.
According to Connolly & Begg (2005, pg.15) a database is “a shared collection of
logically related data, and a description of this data, designed to meet the information
needs of an organization”. They also explain that a database also provides data from
the data working as a “system catalog” that helps understand what each piece of input
data means.
Murthy (2008, pg.9) suggests that there are two types of generic databases: centralised
and distributed. He describes centralised as the ones “located at a single site” that is
25
easier to control and that many people may connect to it having the appropriate
permissions and direct connection to it i.e.: intranet or LAN. On the other hand he
explains distributed as a single database that is physically spread among different
networks in different computers. In fact, Murthy continues by breaking down that even
though this type of database is more secure, it is very expensive to maintain. In this
project a centralised relational database will be designed and developed for the MIS. A
relational database is a repository of data that is connected through relationships, which
helps recognise stored items that are interrelated (Kedar, 2009). This type of database
was first documented by Codd (1970) and continues to be use in the present. Table
relationships are logically connected through columns that are stored in tables and have
unique identifiers called primary keys or candidate keys (Gillette, 2001).
One of the most attractive features of a relational database is that when it is created,
relationships do not need to be defined, making it easier for the programmer to develop
and maintain it (O’Brien, 1990). Reynolds (1995) claims that relational databases have
tables with two dimensions: tuples that represent a row and attributes that are a
column in a table. Connolly & Begg (2005, pg.79) also explain that the way each table
connect is through foreign keys that they define as “an attribute, or set of attributes,
within one relation that matches the key candidate key of some (possibly the same)
relation”.
When talking about what information an MIS need to store, O’Brien (1990) states that
every system suits specific organisational needs, consequently this element depends
entirely with what the organisation is pursuing with the system. Nonetheless, he
emphasises that stored information must be meaningful and also a main concern is to
reduce redundancy. Regarding how data is being managed, Sadagopan (2004)
explains that the best way to manage it is by using a Data Base Management System
(DBMS) that is a program that allows a user to create, manipulate and manage
databases in a visual way (Reynolds, 1995)
26
2.3.4.3 Processing
Beynon-Davies (2002) compares this component to the tasks a human brain performs.
He furthers by explaining that all of the operations, calculations and registers are taken
place in the Central Processing Unit (CPU) that a computer has. This part of the system
can also be seen as the place that “processes data according to instructions” given by
the user (Davis, 2005, pg. 314). This component is of great importance as it is the part
where data transitions to information that is relevant for the organisation (Reynolds,
1995). O’Brien (1990) suggests that there are two types of processing: batch and
realtime. He describes batch processing as the information that is accumulated and
then processed periodically. Similarly, Curtis & Cobham (2005) explain this concept as
temporarily held-on transactions that are just waiting for an entire batch to complete in
order to submit entirely in the system. Conversely, O’Brien (1990) continues explaining
the second concept of realtime processing as all of the data that reflects immediately in
the system after submitting it. Realtime processing in some cases is also called online
processing (Curtis & Cobham, 2005).
2.3.4.4 Reporting
As one of the main features a MIS performs is that they generate reports, the way they
trigger these reports is important (Curtis & Cobham, 2005). Reynolds (1995) suggests
that this fundamental component is the MIS ‘extra value’ in which they outstand as this
characteristic clearly differentiate them from any other system. He claims that similar to
the types of reports that might exist that were presented in the “Types of IS” section;
there are three common ways of “triggering mechanisms that causes reports to be
printed or displayed” (pg. 206). These may be periodic, exception or on demand
triggers.
Periodic reports are triggered on a regular basis to managers (i.e.: weekly, monthly), as
they are programmed to be printed or send to email accounts whenever they are
required (O’Brien, 1990). The second type are the exception reports that are only
triggered when something extraordinary happens in a standardised process in a
company (i.e.: inexplicable low levels of inventories) and they are not expected in any
regular basis, hence the name exception (Reynolds, 1995). Last triggering type is the
27
on demand basis, which refers to the reports that will be generated only when the user
demands it (O’Brien, 1990).
This component is of great use to the users of the MIS as it is the part of the system
that helps providing valuable information that will be used for analysis and their decision
making process (Curtis & Cobham, 2005). In other words, this component directly deals
with the output of the system (Shajahan, 2004).
2.3.6 Conclusions
The previous section presented in detail the concept of MIS. Although it was clear that it
is not a modern system, the purpose behind this literature was to show what makes it
still ‘in demand’ at the present. A valuable lesson learned from this system background
is that the confusion that exists with the different connotations it has, makes it difficult
for any person to understand what someone really wants to refer to. Nonetheless, it is
clear that the key word to all of this confusion is the word management. That might be
because when someone reads it the first thing that might come into mind is the action of
‘administrating something’, making it easy to relate this concept into actually managing
all of the information systems a company has, instead of thinking of a system that it
was built to help report information to managers. Conversely, it was learned that the
main characteristic that made them different from other systems was the ability to
create reports for unstructured problems. In this dissertation, the MIS artefact
developed for this project was positioned in the tactical level of a manufacturing
engineering department and the main focus is on the components of database,
processing and reporting.
28
2.4 Role of MIS in the Manufacturing Industry
2.4.1 Introduction
Now that the concept of MIS has been presented, it is important to highlight the different
uses it might have in diverse industries. For instance, O’Brien (1990) suggests that
some of the most common industries where MIS are implemented might be: marketing,
manufacturing, human resources, accounting and finance. However, as Sheffield
Forgemasters is a manufacturing company, this section will focus in presenting the
different roles MIS have in this industry. Davis (2005) explains that when an MIS is
implemented in the manufacturing industry it usually supports the production and
operation activities from the company. Nonetheless, Sarngadharan & Minimol (2010,
pg.133) suggests that even though they are characterised for supporting production and
operation, they also have a role in the “purchase, marketing, personnel, finance and
accounting” of a manufacturing company.
2.4.2 MIS supporting organisational subsystems
In order to truly understand how a MIS works with an organisational subsystem, it is
fundamental to define first what a subsystem is: “a self-contained system within a larger
system” (Oxford Dictionary, 2012). According to Oke (2009) every company has
different subsystems. He exemplifies this by pointing out that the different departments
within an organisation like accounting, finance or marketing perform specialized tasks
even though the company’s main line is any of the aforementioned areas. As a result,
the point Oke it making with his explanation is that a MIS can be implemented in an
accounting department and support with reports to managers even though the company
manufactures i.e.: steel. With this example it is clear the way a MIS can work inside of
an organisation’s subsystem.
Another important point is to understand that within those organisational subsystems,
they exist levels of managerial activities (Sarngadharan & Minimol, 2010), similar to the
managerial levels presented in section 2.2.2 from Chapter 2 of this dissertation. Several
authors suggest that these levels are: transactional, operational, controlling and
29
strategic (Oke, 2009; Sarngadharan & Minimol, 2010; O’Brien, 1990; Davis, 2005). The
only new element is controlling which relates closely to the tactical level as in this case
controlling will be in charge of the level that creates reports and tactical as the level that
only focuses in planning (Oke, 2009).
2.4.3 Examples of MIS supporting the Manufacturing Industry
All of the following examples will provide general descriptions and desirable features of
the possible systems that support these levels. Focusing in the different MIS
subsystems a good example for the Marketing would be the one suggested by O’Brien
(1990, pg.432) that states that in the transactional level the system will focus in the
“customer orders, billings and returns”. In the controlling level the reports would be
reflecting “market share, distribution and performance”. For tactical it would plan the
“product, pricing and sales forecasting” and for strategic level it will project the
“customer strategy models and long range marketing plans”. All of these examples are
few of the many variants that this subsystem may output.
Last example is from Sarngadharan & Minimol (2010, pg. 134) who details a Production
subsystem. He describes some of the expected activities in the transactional level are
“materials consumption and material control”. In the controlling level it is expected
“detailed reports comparing actual performance with production schedule”, for tactical
level “planning performance” and in the strategic level “alternative manufacturing
approach or approach to automation”.
2.4.4 Challenges in MIS as subsystems in the manufacture industry
Ronen & Pass (1992) are authors who studied for years the challenges MIS face in the
manufacturing industry. In their paper “Manufacturing Management Information
Systems Require Simplification” they explain three key challenges in this area. Firstly,
they claim that one main problem is that these subsystems are developed with
traditional methodologies that do not fit to the manufacturing profile. In other words,
they are suggesting that traditional approaches like the Structured Systems Analysis
and Design Method (SSADM) are not suitable for this industry as they are mainly used
30
for financial systems and require extensive documentation that makes the developer
lose time that could be invested in perfecting the system. They continue with the
second challenge as they explain that the building and maintenance of manufacturing
systems is more complex because if compared to a financial subsystem, manufacturing
requires the detailed description of thousands of products and analysis of many
variables. In finance, it is mostly numbers and that is easy to calculate, as with
manufacturing every action can be modified as the production process is made daily
and updates of variations in product may be needed. Last challenge is the fact that as
the manufacturing industry requires specialised machinery, synchronizing this type of
equipment to the systems reading is a complex task. Consequently, collecting data is
not as easy as one may expect.
2.4.5 Conclusion
There are many ways a MIS can participate in the manufacturing industry. The previous
examples were presented so that it can be seen that in this project the MIS prototype
will be allocated as a subsystem in Sheffield Forgemasters Technical Department for
the activity of controlling production and quality of materials. For that reason, it can be
concluded that the role MIS play in this industry is to perform as an organisational
subsystem that provides managerial support by creating reports that responds to the
needs of the committed function or department of the company (Shajahan, 2004).
31
Chapter 3 Methodology
3.1 Introduction
This chapter will present a description of the methodological approach used in this
dissertation. In order to complete this investigation, the selected methodology to answer
the research questions was Design Research. On the other hand, the software
development methodology chosen for the prototype was Rapid Application
Development (RAD) due to the limitation of time in this project. The following sections
aim to describe how these methodologies were used together in order to answer the
research questions. A qualitative approach will be used to collect the users’ feedback in
their experience with the prototypes. There will only be an evaluation process were end
users will be observed interacting with the prototypes and the interpretations and
feedback from those meetings will be documented.
3.2 Design Research (DR)
Design Research is a science that has awakened interest since the early 90’s and
although there is still a debate in whether design should considered as a research in
some fields like IS (Peffers et al., 2008), March and Smith (1995) consider that to fully
understand the concept one has to know the difference between Natural Science and
Design Science. Simon (1996) makes a clear distinction between the two concepts as
he described that Natural Science focuses in explaining the behaviour of phenomenon
or specific objects have between each other, while Design Science targets the
understanding of artefacts made by humans for specific situations or scenarios. As DR
is a Design Science, now it is important to state its main objectives and how it
contributes to the field of IS.
32
3.2.1 Design Research in Information Systems
Even though there is no consensus in the definition of DR, the contribution of several
authors could be condensed into: “A research approach that is concerned in the
building of artefacts that help to solve specific organisational problems and as well
answers research questions and in this way make a knowledge contribution to a
specific field, in this case Information Systems” (Järvinen, 2007; Hevner et al., 2004;
March & Smith, 1995; Nunamaker et al, 1991). As this definition is a generalised idea,
it is important to highlight that this methodology always deals with the building of IT
artefacts (Orlikowski & Iacono, 2001) and with addressing that artefact into solving a
specific problem (Hevner et al., 2004). If there is no artefact involved then this would not
be called a Design Research. Likewise, as any other methodology it has a series of
defined phases that suggest the way it should be applied in a research project.
Nevertheless, as there has been a slow advance in this area in the past fifteen years
with little contribution (Peffers et al., 2008), variations to the reasoning of the design
cycle illustrated in Figure 3-1 (Vaishnavi & Kuechler, 2005; Cohen, 2007; Takeda et al.,
1990) are few . For this thesis, a variation proposed by Peffers et al. (2008) was used
as it allows the introduction of Rapid Application Development to fit perfectly into their
proposed cycle.
Figure 3-1 Reasoning in the design cycle mentioned by (Vaishnavi & Kuechler, 2004; Cohen,
2007; Takeda et al., 1990).
33
3.2.2 Design Research Methodology
In this particular project the selected cycle is the one suggested by Peffers et al. (2008)
which synthesizes the best contributions from all of the cycles stated by recognised
authors in DR. In their paper “A Design Science Research Methodology for Information
Systems Research” they describe a cycle that does not follow a particular order and it
can be approached from different angles. Figure 3-2 portraits this methodology, and for
means of Sheffield Forgemasters’ particular case the Problem Solved Initiation will be
the selected entry. This methodology will directly help in the answering of the research
questions. The way they explain the steps in this case is from left to right even though
they emphasise that the way the flow goes depends entirely in the entry point the user
selects. The entry points will be defined after the explanation of each phase of the cycle
is stated.
Figure 3-2 Design Science Research Methodology (DSRM) Process Model suggested by
Peffers et al. (2008) with all of the possible research entry points.
34
3.2.2.1 Phase 1: Problem identification and motivation
In the initiation of the cycle Peffers et al. (2008, pg.52) explains that it is fundamental to
state the problem of the investigation and also to “justify the value of the solution”. They
further state that when a researcher and reader are motivated by the possible outcome
or contribution that it will be achieved, it is more likely that for the end result they will
understand the complexity of the investigation.
3.2.2.2 Phase 2: Define the objectives for a solution
This step requires the definition of the objectives that the researcher will try to pursuit
throughout the investigation. All the presented objectives should be “possible and
feasible” (Peffers et al., 2008, pg. 55).
3.2.2.3 Phase 3: Design and Development
The main objective of this step is to define the characteristics that the IT artefact will
have visually and design as well and develop its architecture.
3.2.2.4 Phase 4: Demonstration
This phase requires the researcher to demonstrate the artefact or prototype to potential
users to collect feedback of their first impressions that will help in the course of the
investigation.
3.2.2.5 Phase 5: Evaluation
This is a key point as it is the one where the stated objectives are compared with the
previous demonstration and has be done with “relevant metrics and analysis
techniques” that in this case might be either qualitative or quantitative (Peffers et al.,
2008, pg.56). Depending of the results in this step the researcher should evaluate if
he/she has to return to phase 2 ‘Define Objectives’ or 3 ‘Design and Development’ to
make and desirable modifications to the artefact improvement.
35
3.2.2.6 Phase 6: Communication
Final step, regards the way the findings of the research are going to be presented. The
researcher at this point should reflect on the contribution the IT artefact has to IS and
find a suitable way to present the outcomes to other researchers.
3.2.2.7 Entry Points
Peffers et al. (2008, pg. 71) suggest that entry points should be selected when the
developer has a complete understanding of the project. After that, he/she should decide
either to start the methodology with a “Project Centered Initiation, Objective Centered
Solution, Design and Development Initiation or Client/Context Initiated” depending on
their particular situation.
3.3 How Design Research was used
The following section will explain how DR was used in this investigation with the help of
Rapid Application Design (RAD). The principle motivation for this approach was due to
the fact that this project needed clear results in a limited amount of time. Therefore,
after a deep investigation the most reasonable methodology was the merging of these
two. With this, we will have the opportunity to contribute to DR and with the limited
amount of time, deliver a functional prototype. Although, the most common DR
approach is the one shown in Figure 3-1, the proposed cycle by Peffers et al. (2008)
seem like an opportunity to document the use of a new variation in such a narrow
project. Figure 3-3 shows how the proposed methodology by Peffers et al. (2008) was
adapted to exemplify how RAD was compressed into their suggested steps 3 and 4.
36
Design Research is suitable in this investigation as it gives the chance to explore with
the methodology the desirable functions to support a MIS in a manufacturing industry
focusing in the improving of their materials at a tactical level. As one of DR main goals
is to solve specific problems with the help of an IT artefact (Orlikowski & Iacono, 2001),
when combined with RAD, which emphasises in the building of prototypes, the
outcomes might be ideal for scenarios as the one presented in this specific project with
limited amount of time and the advantageous approach of the involvement of the end
user. The following is an in depth explanation as to how Figure 3-3 took place in this
investigation.
3.3.1 Application of Phase 1: Problem identification and motivation
To start with, as phase 1 suggests, the problem and a motive need to be defined. As a
result, for purpose of this thesis the problem was synthesized as:
Problem: Sheffield Forgemasters Technical Department has been struggling in the flow
and seeking of information as they do not have a database to store and retrieve the
reports their departments produce for the quality and production control of materials.
Also, there is a problem with the duplication of data and typographical errors in the
reports they generate as all of the files they use are by copying and pasting information,
passing through emails or modified by error. That is why the department was looking
Figure 3-3 Modified methodology that will be used during the course of this dissertation,
reflects how DR and RAD work together in the building and evaluation of the artefact (Peffers
et al., 2008).
37
forward for a system that can help them process all of the present and historic data they
have so that they can easily access it and use that information for their decision making
process.
Main motive: As there is no database in this department, there is a need to organise
and store their information so that they can spend all of their time really generating
productive outcomes than designating hours to find the correct information and also
automate their processes so they can standardise and extrapolate the information they
really desire.
3.3.2 Application of Phase 2: Define the objectives for a solution
Furthermore, the objectives were to be aligned with the initial problem. The following
was the proposed objective:
The main objective of this project was to generate a prototype that will have a
centralised database that will allow all of the users to retrieve reports, add and modify
data in a user friendly way in order to improve their decision making in materials. One of
the main challenges was to understand their processes and what the data they were
using meant.
To continue with the next compressed stages, it is important to introduce the concept of
prototyping in the IS context as it will be continuously repeated in the dissertation and it
is what the intended product will be.
Beynon-Davies (2002) defines it as a process that involves the construction of an early
version of a system or a part of a system in order to receive feedback for improvements
from the top management. Avison & Wood-Harper (1991) explains that the biggest
advantage of prototyping is that it is the only way that a final user can see, operate and
feel what the expected system will really look like. They further explain that many end
users are frustrated when they have to wait until the developers finish the entire system
in order to have a glance of what they negotiated on the first stages of the project and
possibly be disappointed by the system’s final outcome (Avison & Fitzgerald, 2003).
38
The selected software development methodology Rapid Application Development
(RAD) creates prototypes and does not document in detail at any stage. Thus, it
compacts most of the traditional development phases for an IS including: analysis,
design, build and test; into one step as seen in Figure 3-4. The main reason for this it’s
because in the traditional cycle the developers need to finish each stage in order to
advance to the next one and every time users found an error, this can only be
addressed at the final stage making this inconvenient and slow (Rainer & Turban,
2009).
Figure 3-4 Traditional software development vs. RAD (Rainer & Turban, 2009).
3.3.3 Application of Phase 3: Rapid Application Development (RAD)
Now that the prototyping approach has been defined, the software development
methodology that uses prototyping will be described in this section that comes to
substitute Phase 3: Design and Development and as well Phase 4: Demonstration from
the original methodology proposed by Peffers et al. (2008).
To start with, the Rapid Application Development (RAD) was first introduced into the
world by James Martin in 1991 in which he created it in order to fulfil the need of
finishing an IS project in little as three months (Avison & Fitzgerald, 2003). Reynolds
39
(1995) portraits the four phases that Martin suggested in Figure 3-5, and each phase
will be described as it was used in the methodology chosen.
Figure 3-5 RAD cycle as suggested by Reynolds (1995).
3.3.3.1 Requirements Planning
The first stage of the cycle is Requirements Planning that deals with extracting from the
end users the systems requirements (Avison & Fitzgerald, 2003). An important fact of
this methodology is that it combines a specific technique called JAD that stands for
Joint Application Design and focuses in having group sessions with end users were
they jointly exchange ideas and come into a consensus of the final requirements,
design or any other concern of the system (Rainer & Turban, 2009).
The way this step was applied into the project was that a JAD meeting took place in the
Technical Department of Sheffield Forgemasters were with the contribution of end
users the requirements were established in a dialog where they expressed what they
expected of the final system. During this and all of the following meetings two main end
40
users Magali Toulze (Product Manager) and Dr. Martin Kearney (Technical Director)
were the ones that formally requested or transmitted any concern, modification or
requirement throughout the project. They acted as mediators between the rest of the
staff in the department and myself. The first general requirements that gave an idea of
what they wanted from the system were established in the meeting and are as follows:
-A system that allows the input and modification of information.
-Custom made reports.
-Multiple users using the system at the same time.
-The constant use of combo boxes to reduce typographical mistakes.
-Usage of current tools offered by the company (in this case Access and SQL server).
-In specific reports the allowance of multiple requirements and results.
-A system that could access the database from any computer inside the company
In next chapter a more specific description of requirements dividing them into functional
and non-functional will be given and also it will be changing along with the prototype
evolution.
3.3.3.2 User Design
This phase will be the direct equivalent of the original diagram Phase 3: Design and
Development shown in Figure 3-2 from Peffers et al. (2008) where in this case will be
broken down into two in order to explain how it will be substituted by the addition of
RAD in the dissertation as shown in Figure 3-3. Specifically in RAD, this phase only
deals with the design of the user interface where again, it can be discussed through a
JAD meeting with end users (Avison & Fitzgerald, 2003).
In this dissertation after the assimilation of the previous requirements and the planning
and development of the database architecture shown in detail in Appendix 1, a draft
design was created after perceiving what the user expected through a JAD meeting that
took place in June 6, 2010 shown in Figure 3-6. The results from that meeting were
satisfactory as the two main end users, previously mentioned, accepted the proposed
design and asked at that specific time for no modifications.
41
Figure 3-6 Design approved by end user in JAD meeting.
3.3.3.3 Construction
This stage covers Phase 3: Design and Development as construction in an IT context
refers to development and also Phase 4: Demonstration as at this stage we present the
constructed prototype to the end user for feedback. Curtis & Cobham (2005) explain
that this phase refers to the coding of the already stated design and ends with the
building of one or more prototypes for the end users to judge. For this particular project,
the construction was made with the following tools that were provided by Sheffield
Forgemasters.
Data base Management System: Microsoft SQL Server 2008
Developing tool: Microsoft Access 2010
The development consisted of creating the relational database and connecting it to the
front end application (Access 2010) so that data could be displayed for demonstration
purposes. Three prototypes were constructed in total and end users through series of
meetings provided feedback for any desired alterations, in next chapter details of the
prototypes will be described.
3.3.3.4 Cutover
This step as suggested by Avison & Fitzgerald (2003) deals with converting the
prototype into an actual system. They specify that if the user just wants a prototype, like
in this dissertation case, this phase can be used just to test and polish the prototype
and also train end users how to use it correctly. For purpose of this thesis, the cutover
phase was made in August 2012 when the second prototype was approved. This stage
42
took approximately one full week of training and testing as the final application just had
two small modules.
3.3.4 Application of Phase 4: Evaluation
As mentioned before, this stage evaluates the prototypes in interaction with the end
user and for the purpose of this project three evaluation mechanisms will be utilized:
observation, discussion after observation and negotiation of new requirements. These
mechanisms are qualitative as they will gather non-numeric data as evidence to
improve the prototype on course. Evidence of this data is provided in the Appendix 2
and 3 and it was mainly notebook annotations and memorandums as no recordings are
allowed in the facilities of the company.
3.3.4.1 Observation
Observation is the process of evaluating how a person in a specific setting develops in
order to evaluate the interaction it has with the object placed (Jorgensen, 1989).
Kaplan and Maxwell (1994, pg. 33) suggests that in the IS context observation can be
used for “providing formative evaluation that is aimed at improving a program under
development, rather than assessing an existing one”. This means that in a
demonstrative stage a developer may evaluate how a user interacts with the system
and make annotations that will become qualitative data that will support in the research.
In this dissertation informal observations were made when the user interacted with the
three prototypes, written annotations are provided as evidence in Appendix 2 and 3.
3.3.4.2 Discussion after observation
The post-observation discussion is the process where the observer reflects in all of the
details that were perceived and annotated in the previous examination (Danielson &
McGreal, 2005). In this particular case the discussion in a meeting was effectuate
approximately three days after the user interacted with each stage of the prototypes.
This was made in this way in order for the user to have a gap of time to reflect in what
43
were the aspects he/she did not like about the system. The feedback gathered from the
discussion is documented Appendix 2 and 3 that deals with the full documentation of
the prototypes that were made. The results from the discussion are described in detail
in the official memorandums provided in the meetings.
3.3.4.3 Negotiation of new requirements and modifications for prototype
improvements
After the discussions have taken place, in order to have a structured way of keeping
any changes and negotiations for the system, a specific format proposed by the client
was created so that all of this documentation could be stored as evidence. Figure 3-7
illustrates the format that was used and further details of any modification or change in
requirements of the prototypes can be seen in Appendix 2 and 3.
Figure 3-7 Format utilised for official changes, modifications and requirements.
.
3.3.5 Application of Phase 5: Communication
Peffers et al. (2008) describe this stage as the part where the developer has to present
the findings and make a contribution to the area it was applied. In this dissertation in the
next Chapter called Results specifically in section 4.6 Lessons Learned the
contributions made in theory, practice and methodology will be detailed. The two
research questions are answered in the theoretical contribution which makes it the most
44
important section from the results chapter. In order to deduce each of the contributions
a deep analysis and reflection into all of the collected qualitative data was made.
3.4 Conclusion
In this chapter the adopted methodology was described in detail and all of the parts that
compose it. Although the methodology is a new approach as the ideas of two authors
with different ideologies (Peffers et al. for Design Research and James Martin for
Software Development) are being merged to fulfil an investigation, the presumed
outcome has to unfold successfully. The fundamental reasons for combining the
methodologies were in the case of RAD , the project has the limitation of time and for
Design Research there has been little contribution in the past fifteen years with no
accepted framework for the methodology, that utilising the one proposed by Peffers et
al. (2008, pg. 1) that they define as: “ consistent with prior literature, it provides a
nominal process model for doing DS research, and it provides a mental model for
presenting and evaluating DS research in IS”, makes it appealing to test .
45
Chapter 4 Results
4.1 Introduction
This chapter aims to describe how Phase 3: RAD, Phase 4: Evaluation and Phase 5:
Communication from the selected methodology were used in the building of the three
prototypes along with the overall findings that all the research unfolded. The previous
steps from the methodology Phase: 1 and Phase: 2 were clearly stated in the last
chapter, as they have to be defined just once in the entire methodology as they will
remain the same in all the process. Each built prototype had a different aim as these
were defined through the constant feedback from end users that was collected in the
Phase 4:Evaluation. It is important to remember that as this methodology involves the
creation of a prototype that will require modifications for its perfection, there will be a
loop between Phase 4 to Phase 3 constantly. The loop was visually stated in Figure
3-3 from last chapter.
4.2 Prototype 1
This first prototype was created with the information collected in the first JAD meeting
and documents that were provided by the company for a better understanding of every
process involved with the reports they wanted to generate.
4.2.1 How Phase 3: RAD was applied in prototype 1
4.2.1.1 Requirements
Following the previous stated requirements mentioned in section 3.3.3 a more detailed
list is as follows:
Functional
-Forms that deal with the specific test should be displayed in “Split Form” from Access.
46
- When moving from form to form the page must display the work order number the
user is working at in the top.
-The search must be done by SFEL work order and Customer.
-Reports should contain the following: Heat Treatment Conditions, Customer Details,
Product Details in the header and information from the mechanical properties.
-Information should be added in a standardised form similar to a wizard sequence.
-All data must be modifiable in a visual form.
Non-Functional
-System must be usable in Windows XP and Windows 7 Operating Systems.
-System must be run in Microsoft SQL Server 2008
-All dates should be expressed in the format: dd/mm/yyyy.
4.2.1.2 Design
As the presented design draft in the first JAD meeting was approved (see Appendix 1),
the system building started based in that illustration for forms and reports. It consisted
of a green upper horizontal line that divided the header from the design area. The
company’s logo is located in the upper right corner, just as featured in Figure 3-6.
Regarding reports, they will all look the same even though the information displayed is
different. In other words, they will all be standardised. The Technical Department
provided drafts of what they were expecting in reports as this information can only be
adequate to their main processes that they previously discussed in private meetings.
With the help of these drafts that were paper based and are confidential, the reports of
this system were easy to create.
The design of this system continued with defining the menu structure. This deduction is
the product of what the client expressed in meetings and the interpretation of how the
system will flow efficiently. The menu is divided into three main activities that are
highlighted with different colours that represent the entry of data, maintenance of data
and reporting of the system shown in Figure 4-1.This structure will be used throughout
the chapter to locate any specific modifications made in a prototype menu level.
47
Figure 4-1 Menu structure of the MIS prototype system.
The main menu represents the entry page that in other words is the first page that the
end user will interact with. This page is fundamental as it contains the three main
navigation options of the system. The level ‘Create Test’ in orange represents the entry
of data in the system. It deals with all of the inputs and once it is clicked the form
appears with no further menu. The next level is ‘Modify Test’ in red that is the
maintenance of data and that name was assigned by the client even though it deals
also with modifying basic information as the client’s details and product. Contrary to the
previous level, when you click that navigation, there is another sub-level that will divide
into ‘Specific Test’ that gives the user the option to browse the mechanical property test
they want to modify skipping the step of client details and products. Similarly, they can
also click in ‘Customer or SFEL W/O’ that this deals with searching a specific client or
Sheffield Forgemasters (SFEL) work order to modify. Last level is ‘Generate Report’ in
green that its main function is to browse through the same sub-level as the previous
navigation either a specific mechanical property test or a client’s name or work order.
48
As previously mentioned in Chapter 1 section 1.2 Aim, the department deals with
comparing heat treatment conditions (HTC) against the mechanical properties of
Tensile and Metallography in order to decide the right HTC for future and current
products. Understanding this flow helped in the design of the system’s entering of data
level. For this reason, Figure 4-2 illustrates that one customer has one product that
contains one unique heat treatment condition that goes into one specific test that can
be either Metallography or Tensile and regardless of the case he/she chooses that test
will always have a requirement, result and a sentence. Further information of this logic
is documented in Appendix 1.
4.2.1.3 Construction
The construction of this system was made with the help of Access 2010, with the
programming language “Visual Basic”. One big challenge was learning this
programming language as the author had no previous experience with it. Also, Access
2010 version is not stable as it constantly crashed and needed to be restarted in order
to complete any command given. The database manager system used was Microsoft
SQL Server and creating the database was easy, but connecting it to Access was the
challenge. Currently, Access 2010 limits the functionalities it has when connecting to
SQL Server and documentation about how to work with both tools together is very
limited. Understanding the behaviour of both tools took time and finding a balance
Figure 4-2 General Systems’ Logical Flow
49
between the nomenclatures each application was complicated. The construction of this
first version prototype lasted four weeks.
4.2.2 How Phase 4: Evaluation was applied in prototype 1
4.2.2.1 Results from observation
For this step it was fundamental to observe how the users interact with the prototype for
the first time. Preparation for this interaction was made by setting up inside Access
2010, as this was not the final application, a formal view that started with the “main
menu” page was displaying as portrayed in Figure 4-3. During and after the
observation, annotations in a notebook were taken as recordings are not allowed inside
the company. The exercise lasted for almost two hours were a total of three persons
used the prototype. As this was the first time they ever used the MIS, it was needed a
time to explain how everything worked before the interaction. The three users exposed
that they had never interacted with systems of such characteristics. A detailed
description of the results and annotations are documented in Appendix 2.
Notwithstanding, as a highlight of the annotations, predominantly the user found itself
confused by how the information in “Split Forms” from Access were displaying the
captured information. Figure 4-4 exemplifies the confusion as the bottom part is not
ordered according to the textboxes sequence.
Figure 4-3 Main Menu displayed to end users in first observation exercise.
50
Figure 4-4 Split form bottom part does not match the textboxes in the form.
4.2.2.2 Discussion after observation
In the meeting following the observation session, the issues encountered by users were
discussed with accuracy. In this meeting post-observation Magali Touzle was present
and provided the official memorandum for the requested changes (see Appendix 2). In
general, the users found problems with some values that were not displaying on-screen
properly, tab order of textboxes, visual displaying of the reports, order of buttons, font
sizes, colours and many other details related to the interface. Regarding the database
they complained about some textboxes that should allow letters and also that some
numbers should be unique. It was of great value the feedback from the users as some
of the mistakes they encountered were not perceived at all by myself, making it very
useful for the next prototype.
51
4.3 Prototype 2
Prior to the construction of the second prototype, an analysis of the feedback from
users and annotations was made. The analysis consisted in detecting which
modifications needed to be made for the database and which to the database itself. The
importance of this relies in that when a database change is needed, no data should be
inside tables in order to avoid any interference with the relationships between tables.
Reflecting into what was best for the user also was a key variable into this new
prototype. Once the changes were classified the RAD process could be conceived.
4.3.1 How Phase 3: RAD was applied in prototype 2
4.3.1.1 Requirements
The new requirements of this second prototype were directly extracted from the
memorandum provided by Magali Touzle in the previous post-observation meeting. In
this specific case, requirements are going to be seen as the changes for the second
prototype as they are a reflection of the evolving prototype. Details of this memorandum
are in Appendix 2. The following were the changes needed for the prototype:
Functional
-A mechanical property should be allowed to add multiple requirements and results.
-When a report is longer than one page, the new pages should contain the information
from the header: Heat Treatment Condition, Customer Details and Product Details.
-Forms from Metallography should always display temperature as RT (Room
Temperature).
-All forms from the mechanical properties should have an ‘add new’ button and ‘save’
button for their requirements and results.
-Add ‘Main Menu’ buttons when appropriate.
-Main menu should contain a new level called ‘Extrapolation of data’.
-Search form should now include browse by ‘description’ and ‘material’.
52
Non-Functional
-The SFEL work order and Cast Number from Customer Details should be unique.
-Fix missing connections.
-Add back buttons in all forms.
-Add in the form Heat treatment Condition a combobox for Medium, Quality Heat
Treatment and Specimen.
4.3.1.2 Design
The design for this second prototype continued in line with the previous prototype
visually, nevertheless the only changes made were the ones requested by the users.
The most significant change was the menu level as a new section has been added to
the prototype. The following Figure 4-5 illustrates the new addition. With level
“Extrapolation of Data” the database only needed the addition of columns to the already
existent tables. Regarding the interface, there was just a small change to the already
existent search form.
Figure 4-5 Addition level ‘Extrapolation of Data’.
53
4.3.1.3 Construction
As this second version is a continuation of the first prototype everything remained the
same concerning the programming language and tools used. The only new thing was
the addition of the module ‘Extrapolation of data’ that required new thinking and more
programming. An example of these changes was the form of search that now it required
the browse by ‘description’ and ‘material’ that only produced more lines of code. The
client emphasise that adding the extrapolation of data level was fundamental as this is
going to help them compare present and past data for the improving of material.
4.3.2 How Phase 4: Evaluation was applied in prototype 2
4.3.2.1 Results from observation
A second appointment was made with the users with the same dynamics as first
prototype meeting. Details of the notebook annotations are in Appendix 3. As a
summary, the main information gathered in this occasion was that users were happier
with this prototype as they saw reflected the corrections they requested. Only one user
noticed a malfunction one the connection, which was annotated, but the interaction they
had with the system was fluent and comfortable compared to the first meeting. This
malfunction specifically dealt with the ‘adding’ of multiple requirements in the Tensile
Result form.
4.3.2.2 Discussion after observation
Three days after the users interacted with prototype two, Magali Touzle prepared the
official memorandum with the last changes for the final application. During the meeting
the points from the memorandum were reviewed one by one for a better understanding.
She continued emphasising the importance of the new level in the menu structure
‘extrapolation of data’ by exemplifying that with this they can browse past reports and
results from specific mechanical properties that failed to discover patterns easily and
research in those mistakes, making the improvement of materials easier. It was a big
surprise that even though the detail from the malfunction that was annotated in the
54
previous observation was there, many other details were in the memorandum. The
importance of other persons perspective was appreciated at this point because things
that were not perceived by the developer was noticed by the users, making it easier to
perfect this second prototype.
4.4 Final Application
The final application literally consisted of completing the requirements from prototype 2
and adding the last aesthetics changes to the MIS. This process was very fast where it
only took five days to complete, as the user satisfaction in last prototype was very high
and almost all of their expectations were fulfilled at this point. However, there was a
specific form that gave trouble by not passing the correct values as the programming
commanded. Fixing this last bug was a challenge because after analysing the code and
even comparing it to the other functional forms the conclusion was that everything was
in order. At this point, there was nothing that could be done to make the form work so a
drastic decision of remaking the form from scratch was done as time was consuming for
this project. After that extreme decision, the form worked and the application was
completed. Users were pleased with the final result that was exposed in a last
interaction meeting that was made in the Technical Department (see Appendix 4).
After the warm reception the application was then placed in the network so that
everyone could have access from any computer from the company.
4.6 Lessons Learned
This last section from Chapter 4 will reveal the findings of this dissertation. The findings
will be divided into three to highlight the impact it had in this investigation and clarify the
answers to the research questions. Also, as aforementioned the findings are the final
step of the methodology Step 5: Communication that will complete the explanation of it.
The sections will be: theory to emphasize how the literature review relates to the final
application, practical will narrate the advantages of using prototyping and the framework
used and finally methodological will describe how RAD was introduced to DR.
55
4.6.1 Theory
The literature review presented in Chapter 2 was trying to highlight the desired
components, characteristics and managerial level a MIS is expected to support in this
dissertation. In this section a contribution in terms of the application regarding how it
should look and what it should be will be defined. To start with, it is important to define
all of the elements in the narrowed field or subject that will help to make a contribution
in IS:
An MIS in a tactical level to support manufacturing processes in an Engineering
department.
To continue, it is fundamental to review that an IT artefact was done with a specific
menu structure and set of functionalities. Thereupon, after the final application was
finished the results in the MIS pointed out that these desired characteristics from
structure and functionalities can be highlighted as:
Menu structure: It is needed with no question an entry page that will display four main
suggested levels. These are creating, modifying, reporting and calculating (it is called
extrapolation in this dissertation case) facilities. Figure 4-5 illustrates the proposed
menu structure as this has helped to achieve the success of the MIS in this project
particular situation. The extent in which each of the levels have to unfold should be
depending with the client’s requirements and experience with computers, as it is always
better to keep a system as simple as possible. In this dissertation the client in repeated
occasions expressed that they felt comfortable with consistent buttons and few menu
options, making it clear that creating something simple is best. As aforementioned in
the literature review, MIS are characterised mainly because of their reporting abilities,
ergo it is of high importance to overlook the reporting facility as this will have a high
impact of the MIS success.
Set functionalities: After reviewing the literature, just as section 2.3.5 Functional
Components of Application suggests, the desirable functionalities will be all the
aforementioned but giving a specific advice in each of the components, basing this in
the experiences gathered with this dissertation:
56
-A Graphical User Interface (GUI) so that the end user through a visual interface can
order the system what to do. The colours and designs should be ad-hoc to the
company’s logo so that it can truly be adopted as a custom made system that
represents the company’s main values. It is extremely important to always maintain
things simply, as the simplicity will transmit a user tranquillity and acceptance to the
new system.
-A data management component that will have a centralised relational database so that
no matter the volume of information the company needs to store, the interrelationships
of the data will facilitate the retrieval of data and the generating of reports. Also, defining
constraints in the application will reduce hours of programming and can create a
standardized atmosphere to users letting them know of the general rules for entering
data in the system.
-A processing component that will act as the systems brain. In the literature review it
was defined that it existed batch and realtime processing. In this particular environment
realtime processing is highly recommended and needed as the information needs to be
processed instantly.
-A reporting component that will provide on demand basis reports. These were
explained as the reports that were triggered only when the end user asked them for.
This manufacturing company cannot have periodic reports because every product with
every client is different; there is no standard operation of what they will ask. Having
triggered reports that will not be requested will be a waste of resources, ergo only on
demand are recommended when reports are specialized. It is also important to
remember that aligned and well-margined reports are visually appealing. Finally, as
obvious as it may sound as these report are fixed they should all look the same.
As a summary to the theoretical contribution of this investigation in the IS field, it is
important to define a menu structure with four simple levels: create, modify, report and
calculate. These levels will try to support the user when navigating through the GUI. It is
also necessary a centralised relational database that will support the data management
of the application so that later on data can be retrieved easily into information whenever
57
the end user needs it. As reports are expected with an MIS, triggering these on demand
basis would be essential as engineering departments are not prone to transactional
processes. They mostly require specialized attention to their clients and reports are
variable (referring to the information, not to how they look). Last, but not least it is
fundamental to process all of the data in realtime so that all of the multiple end users
can have access to the information immediately after entering it.
4.6.2 Practical
The second contribution in this investigation will be of practical matters. There are two
specific points that will be described for this section: advantages of using prototyping
and the framework that was used, in this case RAD, embedded in the entire process.
These two points are the results of the experience of developing this MIS system by the
author of this dissertation, making this contribution a recollection of personal thoughts
unfolded by this investigation.
The first advantage of using a prototype were perceived in the evaluation phase of this
investigation as having the benefit of constantly being given end users feedback was
convenient. With every feedback new opportunities of improvement were reflected in
design and also in the programming.
Another advantage into prototyping is that to a certain extent, it gives your client and
end users a voice into what they expect and also their involvement is dramatically
higher than with any other method as they feel this project is theirs and they try to
nurture it as much as possible. With the help of the JAD meetings and the observation
phase, users were relaxed and participatory as they wanted to be involved in the end
results of the prototype too. This experience was a complete eye opener as seeing in
action what the literature suggests is a valuable lesson.
The last advantage of prototyping that also relates to the framework used, in this case
RAD, the developer does not need to make extensive documentation of the entire
process. As mentioned before, one great limitation in this investigation is the time and
documenting all of what the traditional methodology implies was not viable. That is why
adopting RAD reduces significantly time and also it makes you have a better
58
relationship with the client as you have to be communicating advances and making
them test the prototype. Many authors (Kendall & Kendall, 2005; Reynolds, 1995;
Sadagopan, 2004; Bagad, 2009; Rainer & Turban, 2009) support the argument that
having your client as your advocate and a good relationship are key points in all the
stages of developing a system.
Similarly to last point, the technique of JAD that is part of RAD methodology was a
great ally in this investigation. Through these meetings that were of great value, many
little details that were not perceived by the author were highlighted by the end users. If
these errors were not outspoken, then the prototype and contributions might not be
completed on time, due to the timing factor. In conclusion, RAD was a time effective,
convenient and very helpful development methodology as it improved the relationship
with the end users and with the constant feedback from them it made easier the
developers task of fulfilling their information needs.
4.6.3 Methodological
This last section will describe how RAD was introduced into Design Research in this
project and to what extent does this combination helped in the investigation process.
The main reason for this explanation is for future IS researchers that would like to know
the outcome of the two merged methodologies when creating a system or just
prototypes. When a researcher is motivated with a problem sometimes it is hard to find
a perfect methodology to start the investigation. Likewise, some other researchers
might think that using two or merging a couple of approaches may be suitable. This
investigation presented this case and it expects to help in any further projects that need
more than one approach for developing IS, encouraging confidence into proposing new
methodologies in the field of IS. The proposed approach contributes into the IS context
as it intends to help future researchers that need information when dealing with MIS in
manufacturing industries or engineering departments.
As mentioned before in Chapter 3 Methodology, this investigation is using a proposed
framework from Peffers et al. (2008) in Design Research that involved originally six
steps that for the purpose of this research were reduced to five. This reduction involved
59
the introduction of RAD replacing step three and four from the original methodology as
shown in Figure 3-3. The use of the proposed methodology in this project was ideal as
it allowed the creation of an IT artefact in a short period of time thanks to RAD
incorporation and also the guidance in research with the DR framework that made
reflection into the development and design a conscious process and evaluation, this led
to the offered contributions of section 4.6.1. Also, what this methodology brought was a
complete focus in the encountered problem, always leading into completing main
objectives and finding contributions for the IS field by following simple steps.
In general, the use of the framework was good and convenient because it led easily into
the answering of the research questions for this specific problem. RAD made that the
prototype development more efficient, faster and with a final application that kept the
client satisfied. Also, thanks to the JAD meetings that are part of the RAD cycle an
extraordinary feedback was collected from end users and a relationship of trust was
created as they believed in the project.
It was crucial throughout all of the phases in the methodology to keep in mind that even
though this looked as a typical project that involved the development of a system it was
a research. There is a big gap between these two actions and being aware of that in the
entire investigation is hard. Using Design Research when you are an IS developer is an
excellent approach to research as it slowly helps you gather all of the information
necessary to contribute into this field without losing your developer roots. In other
words, this methodology helps in having the perfect balance into developing rapidly and
researching with a final purpose making it easier to fulfil the information needs of the
client.
60
Chapter 5 Conclusions
This final chapter will discuss the findings with the research questions, the contribution
to knowledge, limitations that were encountered and finally will talk about any future
work that can be done this investigation.
5.1 Relating findings with research questions
In this section the answers to the two research questions that were established for this
investigation will be presented. As both questions are interrelated they will be answered
at once. A brief discussion will be done for the questions to address the corresponding
answers.
-What is an ideal MIS System to support decision making in the engineering
improvement of materials? And what are the functions for such a system?
In the last chapter it was concluded that as part of the theoretical findings the ideal MIS
would be one that could have a specific structure and set of functionalities. The
theoretical findings of this research could be considered the most significant one as it
provides a contribution to the IS field in a concrete way. Regarding which structure it is
recommended and useful for in this specific situation there previously presented a
system that contained a creating, modifying, reporting and calculating features or
sections that will be guiding the MIS main functions. The proposed structure should
then control the following functions of the system that includes a simple and user
friendly Graphic User Interface, a relational database that will allow the data to be
managed correctly, a realtime batch process for information to reach users immediately
and a reporting facilities that will provide on demand basis reports. The reports
generated by this MIS could directly help in the decision making process of the
company as the data they have will now be converted into information useful for their
needs. The specific section from the menu structure called calculating will help in the
extrapolation of data to compare present and past reports and serve as reference for
future research within the company. When a company of such nature can compare the
61
aforementioned data (reports and calculations), the improvement of materials can be
made easily creating an environment of security among managers as they are now in
control of their department’s information. Also, when a material is actually improved this
will be documented in the MIS system database and the stored information can help
any member from the department’s team creating in this way multiple benefits in the
adoption of an MIS of such characteristics.
The methodology that helped in the answering of the research questions was a merging
between of Design Research and RAD that it was an experimentation made by the
author in order to obtain the easiest way to obtain a balance between researching a
specific topic while developing an IT artefact. It is of great importance to remember that
‘ideal’ in this context means satisfying the information needs of a client, although the
ideal MIS system of any company should be one that is custom made to the necessities
they have. These contributions have the goal to serve as a basis to any researcher that
needs to develop a system in such narrow conditions.
5.2 Contribution to knowledge
The final application was successfully finished and the client was happy with the results.
The previous mentioned findings and the company’s acceptance of the MIS are
evidence that the stated objectives in Chapter 1 were achieved as they all involved
these two points. This dissertation makes two main contributions to knowledge. One is
related to the field of IS and the other is to researching methods. Both will be described
as follows.
5.2.1 Contribution to the Information Systems field
The contribution related to the IS field is that contrary to what the literature emphasises
about the reporting function from an MIS, it was discovered that extrapolating
data/calculating is fundamental for the improving of materials in manufacturing
industries. The creation of the prototypes showed at first that the focus was only at the
beginning in generating a custom made report that will provide the client with specific
information. However, as the project evolved the department’s team realise that they
62
also needed to extrapolate information in order to compare it, contrast it, graph it and
trace patterns that will result into findings in their area. This feature is still makes this
system an MIS as it is not artificially generating solutions, it is still just extracting and
placing in the form of graphs the data that the client will analyse manually. This
conclusion would not be possible if a good relationship with the client was not formed
and constant feedback with the observation process had not taken place. The client
transmitted the contribution indirectly and with the evaluation process it was possible to
deduct this finding. The project evolved from creating only reports to also comparing
data that will impact more significantly the decision making process. Also it was
discovered that using RAD as a developing methodology the direct client and team
members felt more involved in the project generating a generous amount of feedback
that was key to the success of this investigation.
5.2.2 Contributions to Research Methods.
In this particular case a merging between two methodologies were used. It was
discovered that using them together made this project end successfully in a three
month period of time. The proposed methodology is a contribution to Design Research
as the final application proved that merging it with RAD is possible for projects of such
nature. Design Research needs contributions of such kind for researchers to have
abundant information in such narrow topics. As this investigation had against it the
factor of time, RAD phase helped combat this negative aspect. If another development
methodology was used like i.e. SSADM the result would not be positive as exhaustive
documentation would have consumed valuable time and research would be made with
little reflection opening the chance to insignificant findings.
5.3 Limitations of the Research
The most obvious limitation in this research was the time as a three month period is
extremely short for developing a system, even though it was just a prototype. Another
very relevant limitation was that the author had no experience whatsoever with Access
2010 and Visual Basic deriving a lot of stress. Last limitation was that this project could
63
not achieve the construction of graphs in the ‘extrapolation of data’ level as there was
no time left to develop it.
5.4 Further work
This MIS expected from Sheffield Forgemasters still needs technical and mechanical
properties to be created and of course, make this an actual system and not just a
prototype. As mentioned before, graphs are needed so that the comparison between
different mechanical properties can be effectuated for improved decision making. This
system can also later be connected to other subsystems inside the company so they
can share information in realtime and work together. Once all of these elements are in
place, research can further be into discovering detailed aspects of MIS as what are the
requirements for these kinds of systems to be stored in a cloud environment or which is
the most suitable programming language for such systems.
Word Count: 14,990
64
References
"Subsystem". Oxford Dictionaries. April 2010. Oxford Dictionaries. April 2010. Oxford
University Press. 02 August 2012
<http://oxforddictionaries.com/definition/english/subsystem>.
Anthony, R.N (1965). Planning and Control Systems: A Framework for Analysis.
Cambridge, Mass :Harvard University Press.
Avison, D. & Fitzgerald, G. (2003). Information Systems Development: Methodologies,
Techniques and Tools. Madrid: McGraw-Hill.
Avison, D.E., Wood-Harper, A.T. (1991). An Exploration in Information Systems
Development. Oxford: Blackwell Scientific Publications Ltd.
Bagad, V. (2009). Management Information Systems. Pune: Technical Publications.
Beynon-Davies, P. (2002). Information Systems: An Introduction to Informatics in
Organisations. Palgrave Macmillan. Retrieved 12 June 2012, from
<http://lib.myilibrary.com?ID=86081>
Boddy, D. , Boonstra, A. & Kennedy, G. (2005). Managing Information Systems: An
Organisational Perspective. Essex: Pearson Education.
Codd, E.F. (1970). A Relational Model of Data for Large Shared Data Banks.
Communications of the ACM , 13 (6), 377–387. doi:10.1145/362384.362685
Cohen, L. et al. (2007). Research Methods in Education. New York: Routledge.
Connolly, T., Begg, C. (2005). Database Systems: A Practical Approach to Design,
Implementation, and Management. International Computer Science Series. Pearson
Education UK. Retrieved 12 June 2012, from <http://lib.myilibrary.com?ID=106462>
65
Curtis, G. & Cobham, D. (2005). Business Information Systems: Analysis, Design and
Practice. Essex: Pearson Education Limited.
Danielson, C. & McGreal, T. (2000). Teacher Evaluation to Enhance Professional
Practice. Alexandria, VA: Association for Supervision and Curriculum Development.
Davis, G.B. (2005). The Blackwell Encyclopedia of Management: Management
Information Systems. Oxford: Blackwell Publishing Ltd.
Dekker, S. (2001). The Field Guide to Human Error. Retrieved June 20, 2012 from
http://leonardo-in-flight.nl/PDF/FieldGuide%20to%20Human%20Error.PDF
Feldman,S. , Rahal, J., Duhl, J. & Crawford, A. (2005). Hidden Costs of Information
Work in the Enterprise. Retrieved May 8, 2012 from
http://es.scribd.com/doc/6138369/Whitepaper-IDC-Hidden-Costs-0405
Gillette, C. (2001). MCSE SQL server 2000 database design. Scottsdale: The Coriolis
Group.
Hevner, A.R., March, S.T., & Park, J. (2004). Design research in information systems
research. MIS Quarterly, 28 (1), 75–105. Retrieved from
http://www2.uiah.fi/~ikoskine/ip07/r0201a_Hevner.pdf
Järvinen, P. (2007). Action research is similar to design science. Quality & Quantity,
41(1), 37–54. DOI: 10.1007/s11135-005-5427-1
Jorgensen, D. (1989). Participant Observation: A Methodology for Human Studies.
London: SAGE.
Kaplan, B. & Maxwell, J. A. (1994). Qualitative Research Methods for Evaluating
Computer Information Systems. Evaluating Health Care Information Systems: Methods
and Applications, Thousand Oaks, CA, 45–68.
66
Kedar, S. (2009). Database Management System. Pune: Technical Publications.
Kendall, K. & Kendall, J. (2004). Systems Analyisis and Design. (6th Edition). New
Jersey: Prentice Hall.
Levesque, M. (2011). Many Business Lag Behind in Tech Adoption. Retrieved May 8,
2012 from http://www.idatix.com/many-businesses-lag-behind-in-tech-adoption/
Long, L. (1989). Management Information Systems. London: Prentice-Hall.
Lucey, T. (2005). Management Information Systems. (9th Edition). London: Thomson
Learning.
March, S., & Smith, G. (1995).Design and natural science research on information
technology. Decision Support Systems, 15(4) ,251–266. Retrieved from
http://iris.nyit.edu/~kkhoo/Spring2008/Topics/DS/march_smith_DSS1995.pdf
Mohapatra, S. & Prasad, R. (2012). Information Strategy Design and Practices 2012.
New York: Springer Verlag.
Morley, D. & Parker, C.S. (2009). Understanding Computers: Today and Tomorrow,
Comprehensive. Boston: Cengage Learning.
Murthy, C. (2008). Enterprise Resource Planning and Management Information
Systems: Text and Case Studies. Mumbai: Global Media.
Nunamaker, J.F., Chen, M., & Purdin, T.D.M.(1991). Systems development in
information systems research. Journal of Management Information Systems, 7(3), 89–
106.Doi: 10.1109/HICSS.1990.205401
O’Brien, J.A. (1990). Management Information Systems: A managerial end user
perspective. Boston: Irwin.
67
Oke, J. (2009). Management Information Systems. Pune: Nirali Prakashan.
Orlikowski, W. & Iacono, C. (2001). Desperately Seeking the “IT” in IT Research- A Call
to Theorizing the IT Artifact, Information Systems Research, 12(2), 121-134.
Peffers, K. , Tuunanen, T. , Rothenberger, M. & Chatterjee, S. (2008). A Design
Science Research Methodology for Information Systems Research. Journal of
Management Information Systems, 24(3), 45-77. Doi: 10.2753/MIS0742-1222240302
Rainer, K. & Turban, E. (2009). Introduction to Information systems Enabling and
Transforming Business. Hoboken, NJ. : John Wiley & Sons.
Rainer, R.K. & Cegielski, C.G. (2010). Introduction to Information Systems: Enabling
and Transforming Business. Hoboken, NJ. :John Wiley & Sons.
Reynolds, G.W. (1995). Information Systems for Managers. St. Paul, MN. : West
Publishing Company.
Ronen, B. & Pass, S. (1992). Manufacturing Management Information Systems Require
Simplification. Retrieved July 3, 2012 from
http://www.boazronen.org/PDF/Manufacturing%20Management%20Information%20Sys
tems%20Require%20Simplification.pdf
Sadagopan, S. (2004). Management Information Systems. India: Prentice-Hall of India
Pvt. Ltd.
Sarngadharan, M. & Minimol, M.C. (2010). Management Information System. Mumbai:
Himalaya Pub House.
Shajahan, S. (2004). Management Information Systems. Delhi: New Age International.
Simon, H. (1996). The Sciences of the Artificial. Cambridge, MA.: MIT Press.
68
Stair, R. & Reynolds, G.W. (2008). Fundamentals of Informations Systems. Boston:
Cengage Learning.
Takeda, H. et al. (1990). Modeling Design Processes. AI Magazine, 11 (4), 37-48.
Taylor, R. (2008). Duplicate data costing UK businesses thousands, according to new
Experian report. Retrieved May 10, 2012 from
http://www.qas.co.uk/company/press/duplicate-data-costing-uk-businesses-thousands-
according-to-new-experian-report-504.htm
Vaishnavi, V. & Kuechler, B. (2005). Design Research in Information Systems.
Retrieved July 28, 2012 fromhttp://ais.site-
ym.com/?page=DesignScienceResearc&hhSearchTerms=vaishnavi
Ward, J. & Peppard, J. (2002). Strategic Planning for Information Systems. (3rd
Edition). Sussex :John Wiley & Sons Ltd.
69
Appendix 1: Database Design and Development Details
Note: The following database documentation is not extensive as RAD methodology
does not require this and the anything referring the logical model and actual database
cannot be added as it is confidential.
Step 1 Case:
-One customer may order many products.
- A product contains only one heat treatment condition that is unique.
-A product contains only one chemical analysis.
-A chemical analysis requires of only one heat treatment to exist.
-A heat treatment impacts a mechanical property (Drop Weight, Impact, Mechanical,
Rolls, Transition Fracture, Metallography or Tensile).
Step 2 Requirements:
A database that allows user to perform the following activities:
1) Create a report that contains the customer details, product details, heat treatment
condition, requirements and results from the required mechanical property with one final
sentence to that test.
2) Easily retrieve in a screen the summary of a customer name, sfel work order,
identifier of heat treatment condition, order no., cast no., drawing no., material,
description, date of test and specifications.
70
Figure illustrates the final result of second requirement.
Step 3 Conceptual Model: Entity Relationship Diagram (ER)
First attempt of ER diagram:
In this version there was still confusion in the flow of information and the role of the
chemical analysis entity.
71
Final Version of ER diagram
This ER is the representation of the flow and interaction between the entities in this
system. Although only two modules were created for this project, this view was created
this way to have an accurate comprehension of the flow of information. This is evidence
that the objective ‘To understand the flow of information in the department’ was fulfilled.
72
Appendix 2: Prototype 1
Requirements
The next images show the first requirements asked for in the first JAD meeting,
following by the draft of the reports they wanted for the specific mechanical properties.
73
74
Design: First Draft
-Notebook Version of Design
This is the design that was presented to the end users and approved.
75
-Clean Version of Design
First Menu Structure in Prototype
76
First Observation
77
First Discussion Post-Observation
78
79
Appendix 3: Prototype 2
New Requirements
The new requirements are exactly as presented in Annex 2 in the Discussion Post-
Observation. As said in the dissertation, the requirements are going to be the changes
the user requires.
Addition in the Menu Structure Design
80
Second Observation
81
Second Discussion Post-Observation
82
83
Appendix 4: Final Application
The following are some screen caps of the final application.
Main Menu
Customer and Product Details
84
Heat Treatment Condition
Select Test
85
Tensile Requirement
Tensile Results
86
Sentence
87
Appendix 5: Planning (Notebook Annotations)
Designs
In this section the images represent some of the notebook drafting that led to the
actual design from the prototype.
88
89
90
91
Programming
In this section drafting the logic of the programming is shown.
92
93
Menu Structure
This image shows the planning of the menu structure in the first stages.
(a) I, the supervisor, agree to this dissertation being made immediately available through the
Department and/or University Library for loan or consultation, subject to any special restrictions
(*) agreed with external organisations as part of a collaborative project.
*Special
restrictions
(b) I, the supervisor, request that this dissertation be withheld from loan, consultation or
reproduction for a period of [ ] years from the date of its submission. Subsequent to this period,
I, agree to this dissertation being made available through the Department and/or University
Library for loan or consultation, subject to any special restrictions (*) agreed with external
organisations as part of a collaborative project
Name
Department
Signed Date
THIS SHEET MUST BE SUBMITTED WITH DISSERTATIONS IN ACCORDANCE WITH DEPARTMENTAL
REQUIREMENTS.
