Beruflich Dokumente
Kultur Dokumente
Information needs refers to the type of information requirement by an individual in the organisation
Not everyone in the organisation needs same information
Different people in the organisation needs different information
Purpose of analysing information needs
1) Different people need different information
2) Information so acquired is used for decision making
3) Decision taken today based on current information does have an impact in the future
4) Impact can be within the same department or different department in the organisation and its
environment
5) Data is available in abundant to extract information out of it is a complex and a time consuming task
Eg. textbook
Difficulty in assessing information needs
(textbook and ppt)
Method and tool for assessing information needs
The difficulty in assessing information needs in an organisation stems from the degree of uncertainty in
the organisation. the higher the uncertainty the more difficult it is to ascertain inforrmation needs since the
decision makers themselves will not be certain of what information they need and where data for such
information can be gathered
Methods adopted to reduce uncertainty and assess information needs are as given
A. Low uncertainty(near certainty) - Operational level management-Ask what is needed
B. Risk situation(precise probabilistic knowledge)-Middle level management- it can determine the path to
take from existing systems and methods of decision making
C. Very risky(precise probabilistic knowledge is not possible- - Middle and top level management both-In
this situation when various alternatives are available making it difficult to predict the decision makers
apply decision parameters and set decision methodology to make decisions.
D.Total uncertainty - Top management- Experimentation modeling and sensitivity analysis
Methods for determining requirements
Asking/interviewing- open ended and closed ended questions, Delphi method
Using the existing system as a framework
Analysing critical factors
Experimentation and Modeling
Information needs- Relation to Organisation's Goals, Objectives and Targets
What are the above terms
Information needs should be evaluated in the light of organisational goals, objectives and targets
Breakup of information needs according to type of decisions and users
* Operational decisions. These decisions are made by workers and their supervisors and are
concerned with daily production. (Low level managment)
* Managerial decisions. These decisions are made by mid-level managers and are concerned with
topics such as hiring, and motivating employees.(Middle level management)
* Strategic decisions. These are different from operational and managerial decisions. Strategic
decisions are made by organizational leaders and are concerned about the mission and the reorganization of a firm. These decisions tend to be more unstructured, involve more searching of the
environment and tend to occur less frequently than either operational or managerial decisions. (Top level
management)
Information models
It is a representation of the existing information system and the desired information system in the
organisation
It includes the following
Input -sources of data
Process-Processing implies that data from one source is combined with data from another sources and
modified to produce an intelligent result
Output- Which data store or file is the output stored and who will use that result
Report format- A proper information model will contain an accurate representation of the reports produced
by the system. It will show the format of those reports the users to whom the reports are made and the
periodicity of the reports. It will also show whether those reports constitute input for further processing
whether they are stored in local or central repositories etc.
Users - Rights of users are defined. Who will access what information and the level of authority is defined
administrator mode
owner mode
user mode with special permission
user mode
____________________________________________________________________________________
__________________
Assessing Information Needs
This work is based on and, at times uses exact text of, Gustafson DH, Cats-Baril WL, Alemi F. Systems to
Support Health Policy Analysis: Theory, Models, and Uses, Health Administration Press: Ann Arbor,
Michigan, 1992.
Introduction
This section addresses how information systems could be tailored to serve strategic decisions.
Organizations face three types of decisions:
* Operational decisions. These decisions are made by workers and their supervisors and are
concerned with daily production.
* Managerial decisions. These decisions are made by mid-level managers and are concerned with
topics such as hiring, and motivating employees.
* Strategic decisions. These are different from operational and managerial decisions. Strategic
decisions are made by organizational leaders and are concerned about the mission and the reorganization of a firm. These decisions tend to be more unstructured, involve more searching of the
environment and tend to occur less frequently than either operational or managerial decisions.
Strategic Information Systems help policymakers, executives, and planners decide on organization
mission and strategies. Organizations make many different strategic decisions. Sometimes organizations
make these decisions consciously, as when the firm engages in strategic planning. Other times decisions
are made without being aware of the strategic importance of these decisions, as when the environment
forces the organization to act in certain ways. It is difficult to know what issues will be strategically
important for the organization.
One way to understand organization's strategic issues is to look at data needed in previous planning
efforts. Unfortunately, history is often not a good guide of future strategic issues. Because information
systems help in articulating strategic issues, if the information system focuses on the wrong issue it could
radically mislead the organization. How can we anticipate information needs of organizational leaders?
Another reason why organizational leaders may not be able to articulate their information needs is
because they may have forgotten occasions in which they needed more information. When clients are
interviewed about their needs, they have to remember how key information was missing in the past
decisions. This is very unpleasant. No one is in a habit of remembering his or her failures or episodes in
which their needs were not satisfied. Unpleasant events are often forgotten, especially when you,
yourself, are in charge. Interviewing organizational leaders about failures of their organizations to supply
critical information is akin to asking you when did you make bad judgments. It is an unpleasant task that
you rather forget. For some people it is so unpleasant that they may unconsciously distort the facts so not
to remember the events. If managers and leaders forget their failures, if they prefer not remember how
they failed to gather necessary information, interviews will not be very useful. If the manager has a good
memory for these instances, the analyst will have a good basis for specifying the information
requirements.
Various other severe and systematic cognitive biases also impair the ability to define information needs
(IBM Corporation 1981). But it is not just cognitive limitations that create havoc in assessing information
needs. Clients lack of expertise and knowledge is a also a common obstacle to formulating and stating
true needs (Ellis 1982; Hogarth 1981). Many decision makers do not realize how their own needs change
over time and how these needs are affected by external events. Many are not aware of new technological
possibilities and keep projecting future needs based on their existing expectations from current
information systems. In short, many do not know what they want.
Finally there is the problem of distinguishing between what clients' want and what they need. Sometimes
organizational leaders get what they want but not necessarily what is good for the organization.
Information systems cannot be serving the needs of individuals and ignore the needs of organizations.
Sometimes individuals' cognitive styles prevent them from examining information presented in different
formats. Clearly, information systems should help individuals see beyond their own limitations. Sometimes
differences in time horizons, personal career objectives, and internal organization politics prevent some
organizational leaders from seeing the emerging changes around them. Information systems cannot
rubber stamp the status quo. They need to engage leaders in thinking about the emerging future and
assist them in making it a reality. Information systems are intended not only to serve clients but also to
enhance and improve their decision making. By focusing solely on what clients want information systems
may do them a disservice.
This is not to suggest that analysts can identify users needs better than clients themselves. Analysts who
do not involve clients risk the possibility of planning systems that are not used. Information system
analysts are often ignorant of the subject matter. Planning without engaging the client may lead to wasted
effort.
We suggest that information systems should play both roles: give clients the information they are asking
for but add to it information they may need but not have asked for. To do so, analysts and clients must
collaborate to determine information needs. How could this be done?
Previous Approaches
Taggart and Tharp (1977) Yadav (1983) and others have suggested different approaches to improve our
ability to understand information needs:
o Analyze organizational tasks and see how information is used in these tasks (Hira and Mori 1982;
Mintzberg 1975).
o Ask the decision-maker about their needs (Huysmans 1970; Ross and Schoman 1977).
o Deriving requirements from the existing information system (Valusek 1985).
o Looking at strategic goals and concerns (Checkland 1981).
o Do input-process-output analysis (Lundeberg 1979).
Are some of these approaches like the ideas you presented earlier? All of these approaches have
features that are appealing; but each suffers from one or more of these weaknesses:
* A focus on past and current but not future information needs. This may be acceptable in a stable
environment, but not in a dynamic one.
* A focus on a single issue, task, or decision. The resulting information system could be useful in a
highly repetitive operational setting but would be too narrow to deal with the diverse set of issues faced by
most organizational leaders.
* A focus on the information as opposed to decisions. This technique may specify information that are
not used in any specific decisions.
* A focus on the decision-makers personal goals, which may be inconsistent with the organizational
goals.
* A focus on observing users behavior without seeking their insight or helping them examine their
expertise to assess needs more creatively. The more clients participate in the design of information
systems, the more likely that they will see the project to the end and use the resulting information system.
Until now, Information requirement techniques have emphasized structuring needs assessments into
formats compatible with computers, not on finding mechanisms to formulate needs from the users
perspective (Gustafson et al. 1982). While a few user-oriented information requirement tools are
described in the literature (King 1978; Mitroff 1974), the overwhelming majority of tools developed in the
past decade concentrate on structuring and representing the needs expressed by users rather than on
helping users formulate their needs more effectively.
Recommended Methodology
This section presents an alternative method of determining information requirements, Gustafson, Alemi
and Cats-Bariel (1992) developed to overcome the above weaknesses. The methodology has the
following steps:
1. Identify future issues. Invite a panel of internal leaders and external experts that are familiar with
the organization as well as with the environment of the organization. Ask the panel to identify strategic
issues that the organization will face within the next 2-5 years.
2. Identify information needed for selected issues. Ask the panel to specify the information needed
for the most likely and most important issues. Create a non-redundant list of information needed across
all issues examined..
3. Rate the importance of the information for different issues. Ask the panel to set priority for
information needed to address different issues.
4. Allocate resources to govern the collection and analysis of information on the basis of the new
priorities. Identify information that needs to be collected routinely, information that needs to be
computerized, and information that may be collected when the need arises in the future.
Following Table shows who completes the various tasks.
Step
Objective
Performed by
1
Identify issues Panel of experts and organizational leaders
2
List information needs of top issues
3
Create a taxonomy
4
Prioritize information items
5
Develop resource allocation plan for data collection and analysis strategies
Systems
analysis team
There are many advantages to the proposed approach.
* By forcing clients to think about future issues, the planning effort reduces the danger of focusing on
current issues and information needs.
* This type of "issue driven" methodology also minimizes the potential for collecting data that may not
be used in any strategic decision. Directly asking clients what information they need may lead to items
that seem important but are not crucial for any major upcoming decisions.
* By relying on a group rather than an individual, the methodology minimizes the cognitive and
behavioral limitations of having a single person define information needs.
* By adding external experts to the membership of the group, the methodology emphasizes what
people in the organization want and what people outside think they may need.
Each step is discussed below and illustrated by a case study that shows how information needs will be
set for a mental health commission charged with setting manpower policy.
Step 1. Identify future issues
The first step is to identify and prioritize issues likely to confront the decision-makers served by the
information system. A number of mechanisms can be used for anticipating strategic issues. Techniques
like the Delphi, Nominal Group or Integrative Group Process have been used to capture the opinions of
groups of experts on the likelihood that issues will occur. Systems analyses (to identify weaknesses in
system operation), literature reviews, and observing the environment can also be helpful. The
identification process should result in a list of strategic issues along with priorities that reflect both the
intrinsic importance (i.e., magnitude of the consequences) of the issue and the likelihood it will become
salient and thus require a response.
In the case study reported here, 48 experts in mental health policy from several states participated in a
three-month long Delphi study to identify and set priorities on key issues likely to face the mental health
field in the next five years. The experts rated the issues in terms of probability of occurrence and intrinsic
importance. The importance and probability estimates were multiplied to yield an expected value score for
each issue. Later, the 37 members of a commission responsible for setting mental health manpower
policy in one state (the clients of the future information system) selected from that list six issues best
reflecting the goals of their commission. For illustrative purposes, three of the six issues selected were the
following:
1. How to reimburse the growing number of paraprofessionals who treat mental health clients?
2. What educational programs or policies should the state adopt to upgrade knowledge of mental illness
among primary care physicians who deliver many services to rural, mentally ill clients?
3. Many chronically mentally ill patients live in nursing homes that cannot provide adequate care. What
policies should the state adopt to improve care for these patients?
Step 2. Develop a taxonomy
When one examines information needed across different issue, time after time the same pieces of
information may show up. For example, cost of operations maybe important in several different upcoming
issues. In this step, the analysis team works with the panel to identify categories of information. The panel
lists for each issue what information will substantially reduce uncertainty and assist in decision making.
The analysis team then categorizes these information items into distinct and non-redundant list of items.
For example, in the specification of information requirements for the mental health commission, we
conducted a second three-month-long Delphi study. We asked the panel to identify information items that
would substantially reduce uncertainty about how to deal with key issues. After these the panel came to a
consensus about the needed information items, the analysis team eliminated redundancies and combined
the responses into a single list. Many information items appeared in all issues examined. At the same
time, each issue had one or more information items that were unique to the nature of the issue. The
analysis team was able to consolidate the responses into a list of 69 generic information items. Here are
two of the 69 items:
Item number
Item description
1
The size and character of the patient population affected by the issue
5
How expensive is it to provide services that fully meet clients needs?
Step 3. Rate the importance of information requirements
No information system can collect and analyze data to address every possible information requirement.
Even if one could guarantee that the format in which the data were collected was appropriate to a
particular strategic issue, the cost would be prohibitive. It is imperative to establish priorities on what
information is to be collected and analyzed.
In step 4, organization's leaders rate the importance of each information item for specific strategic issues.
The panelist maybe asked a question such as the following:
For the issue "xxx," assign a score between 1 and 3 to each information item reflecting the need for the
information. A score of 1 means the information has low priority, a score of 2 means that the information is
nice to have but not essential and a score of 3 means that the item is essential for addressing the issue.
When finished, the information items rated highest across all issues are considered most responsive to
the organizations needs.
For example, each mental health commissioner was asked to choose the three issues on which they were
most informed. Each commissioner rated the relevance of all 69-information items for their issue. Then a
priority score was calculated by averaging the scores given for each item by all panelists on all issues.
For example, the item "how clients differ from each other?" had an average score of 1.8 (out of a possible
3) across all issues for all raters.
Step 4. Prepare a data collection / analysis plan
Listing what information is needed does not finish the information requirement specification. Further steps
must be taken to specify how and when the information will be collected. A plan should be devised for
data collection. Not all information items should be collected immediately. Nor, should all information
collected be computerized. In specifying data collection plans, we believe it is important to ignore the
following common pitfalls:
* The all or nothing style of including or excluding information items, which omits intermediate options.
It is important to realize that the importance of information may change over time and that data collection
plans must reflect this changing nature of information.
* The separation of data collection from analysis - as if the value of data is independent of your
analysis. It is important to plan for both the data collection and the analysis of the data.
* The assumption that only empirically observable events are data, and that experts opinions are
irrelevant to policy decisions. We should plan the collection of both qualitative and quantitative, numerical
and text and concrete and vague data.
In planning for data collection, it is useful to divide information items into four categories:
1. Essential information. This set includes items important to all issues.
2. Rapid collection items. This set includes items important to most issues. For these items one
45
The monitoring and evaluation methods used with the system
47
Options to the existing system
53
The costs of implementing alternatives to the existing system
61
Legislative and regulatory changes needed to alter the system
This set includes two types of information. Items 2, 13, 42, and 45 require more elaborate description of
the existing system.. Items 47, 53, and 61 deal with alternatives to the existing delivery system. The
organization should plan the data collection and analysis for addressing these information items but
should wait and see if the need for the information arises.
The periodic information set. The information items are unimportant for most policy issues but vital to a
few. The items cannot justify regular data collection or analysis, and might not even justify detailed
planning. The best strategy may be to allocate resources for special studies (perhaps conducted by
vendors). In the case study, the periodic information set consisted of the following items:
Item number
Description of the information item
7
Who gets what priority for different types of care
26
How different providers serve the undeserved areas
28
Constraints specifically limiting substitutability of providers
29
The existing provider certification and education systems
31
Training that might be needed by families and the community
35
Possible funding sources and methods of obtaining funds
56
Legislative/regulatory constraints on the existing/optional systems
57
How legislation defines responsibility for the client population
66
How and whether to mobilize power groups
67
Many of these (28, 31, 35, 56, 66, and perhaps 7 and 29) seem relevant primarily if a change is planned
in the system, so the nature of the information needed would depend on the options under consideration.
The information required is not likely to be present in a typical information system. In addressing this set,
the information system should find resources to conduct quick response studies that draw on the
judgments of experts rather than empirical data.
The low-priority set. Information items in this set have low average importance and moderate to low range
and would only rarely be used in most policy analyses. Even when they are used, they would not typically
be crucial to the analyses. We suggest that no planning or preparation be directed toward these items.
The following items are examples of the low-priority set:
Item number
Description of the information item
4
Episodes of illness: frequency and responsiveness to treatment
9
The role of the family in caring for client
46
What knowledge is needed to correct the problem
58
How existing laws and regulations duplicate each other
64
The position, attitude, and agenda of affected interest groups
Items 4, 9, 46, and 58 require a level of detail that may not be needed in the selection and design of
issues considered by the panel, although they may be important during implementation. It surprised us
that item 64 received such a uniformly low score because interest groups typically have a great effect on
strategic issues. Possibly policymakers felt they already knew the positions of these groups and therefore
needed no further information. Periodic examination of information requirements may suggest a change in
the status of information items. Information considered low priority may change to higher priority as the
issues or the environment changes.
The boundaries between set should be drawn according to the availability of resources to collect and
analyze the data, and by comparing the cost of collecting data in advance with the cost of collecting it on
as needed basis.
Discussion
The methodology we have discussed provides a means with which to identify a core of information items
that will support the analysis of a wide range of issues. It also provides a means of determining which
items to collect and analyze and what priority to assign them. While some data should be routinely
collected and analyzed, in other cases resources should be invested not in doing but in planning the
collection and analysis. Finally, this analysis suggests that much of the information can come from the
minds of experts rather than from observing and documenting events or facts.
The methodology requires that the analysis team identifies and gains access to a group of experts who
will generate and update a list of future issues or potential problems in the field. The selection of experts
is crucial since their collective vision will drive the design of the information system. It is also important
that the panel be available on a regular basis (the frequency depends on the degree of environmental
turbulence) to determine which issues are emerging and whether they require additional items of
information. It is our experience, however, that the generic taxonomy tends to be highly robust and that,
while issues come and go, the taxonomy of types of information needed seldom changes.
The average importance and range of items, on the other hand, may change, so they should be
reassessed periodically. For example, in this era of tight budgets, information items that deal with costs,
resources, and funding are usually important. And because the boundaries of the four information sets
depend on resources, changes in resources for collecting and maintaining the information systems will
alter the boundaries. A loss of resource indicates that we should adopt a stricter definition of importance,
so the low-priority set would grow at the expense of the other three.
Certain refinements could improve the accuracy of the ratings. For instance, it might make sense to use
an importance rating scale with more benchmarks (e.g., 1 to 7 instead of 1 to 3) and to use the variance
rather than the range to classify the items. Also, a different subset of issues and a different set of panel
members could be used to test the stability of the ratings.
The principal idea behind this methodology is to create in advance a flexible information system that
includes a core of critical data, an ability to rapidly access sources of other data as new issues arise, and
the resources to "hire out" special studies in rare cases.
http://gunston.gmu.edu/healthscience/740/AsessingInformationNeeds.asp
Information requirements for MIS
Assessing information needs
A first step in designing and developing an MIS is to assess the information needs for decision making of
management at different hierarchical levels, so that the requisite information can be made available in
both timely and usable form to the people who need it. Such assessment of information needs is usually
based on personality, positions, levels and functions of management. These determine the various levels
of information requirements.
Table 1 Organizational structural implications for information systems
Concept
Implications for Information Systems
Hierarchy of authority
A tall hierarchy with narrow span of control requires more formal control information at upper levels than a
flat hierarchy with wide span of control.
Specialization
Information system applications have to fit the specialization of the organization.
Formalization
Information systems are a major method for increasing formalization.
Centralization
Reporting critical change variables, organizational change, or relationships, and use of multiple channels
in a semi-confusing system may be useful for promoting responses to a changing environment.
Organizations as socio-technical systems
Provides approach to requirements determination and job design when both social and technical
considerations are involved.
Source: Taken from Gordon and Olson, 1984: 358-359.
Levels of information requirements
There are three levels of information requirements for designing an MIS (Davis and Olson 1984). They
are:
At the organizational level, information requirements define an overall structure for the information
system and specific applications and database.
Application level requirements include social or behavioural - covering work organization objectives,
individual roles and responsibility assumptions, and organizational policies - and technical, which are
based on the information needed for the job to be performed. A significant part of the technical
requirement is related to outputs, inputs, stored data, structure and format of data and information
processes.
At the user level, database requirements can be classified as perceived by the user or as required for
physical design of the database.
Strategies for determining information requirements
Gordon and Olson (1984) suggested six steps in selecting a strategy and method for determining
information requirements (Table 2).
Table 2 Strategies for determining information requirements
1. Identify elements in the development process
Utilizing systems
Information system or application
Users
Analysis
2. Identify characteristics of the four elements (in 1, above) in the development process which could affect
uncertainty in the information requirements.
3. Identify the process uncertainties
Existence and availability of a set of usable requirements.
Ability of users to specify requirements.
Ability of the analyst to elicit and evaluate information requirements.
Assess how the characteristics of the four elements in the development process (listed under 1, above)
will affect the these process uncertainties.
4. Determine how the overall requirements uncertainties would be affected by the combined effects of the
process uncertainties.
5. Considering the overall requirements uncertainty, choose a primary strategy for information
requirements.
If uncertainty is low, then the strategy should be to:
Ask the users what their requirements are. This presupposes that the users are able to structure their
requirements and express them objectively. Asking can be done through
- questions, which may be closed or open,
- brainstorming sessions, totally open or guided, and
- group consensus as aimed at in Delphi methods and group norming.
Wherever there are close similarities in the organization and easy replication is possible, information
requirements can be derived from the existing system.
Characteristics of the utilizing system should be analysed and synthesized. This is particularly useful if
the utilizing system is undergoing change.
If uncertainty is high, discover from experimentation by instituting an information system and learning
through that the additional information requirements. This is 'prototyping' or 'heuristic development' of an
information system.
6. Select an appropriate method.
Source: Davis and Olson, 1984: 488-493.
Types of MIS
MIS can be categorized (Mason, 1981) as follows:
Databank information systems refer to creation of a database by classifying and storing data which
might be potentially useful to the decision-maker. The information provided by the databank is merely
suggestive. The decision-maker has to determine contextually the cause and effect relationships. MIS
designs based on the databank information system are better suited for unstructured decisions.
Predictive information systems provide source and data along with predictions and inferences. The
decision-maker can also enquire as to 'what if a certain action is taken?' and whether the underlying
assumptions are true. This type of MIS is useful for semi-structured decisions.
Decision-making information systems provide expert advice to the decision-maker either in the form of
a single recommended course of action or as criteria for choice, given the value system prevailing in the
organization. The decision-maker has just to approve, disapprove or modify the recommendation.
Decision-making information systems are suitable for structured decisions. Operations research and costeffectiveness studies are examples of decision-making information systems.
Decision-taking information systems integrate predictive information and decision-making systems.
Process of MIS
The MIS implementation process (Table 3) involves a number of sequential steps (Murdick and Ross,
1975):
1. First establish management information needs and formulate broad systems objectives so as to
delineate important decision areas (e.g., general management, financial management or human
resources management). Within these decision areas there will be factors relevant to the management
decision areas, e.g., general management will be concerned about its relationship with the managing
board, institute-client relationships and information to be provided to the staff. This will then lead the
design team to ask what information units will be needed to monitor the identified factors of concern.
Positions or managers needing information for decision making will be identified.
2. Develop a general description of a possible MIS as a coarse design. This design will have to be
further refined by more precise specifications. For efficient management of information processing, the
MIS should be based on a few databases related to different sub-systems of the organization.
3. Once the information units needed have been determined and a systems design developed, decide
how information will be collected. Positions will be allocated responsibility for generating and packaging
the information.
4. Develop a network showing information flows.
5. Test the system until it meets the operational requirements, considering the specifications stipulated
for performance and the specified organizational constraints.
6. Re-check that all the critical data pertaining to various sub-systems and for the organization as a
whole are fully captured. Ensure that information is generated in a timely manner.
7. Monitor actual implementation of the MIS and its functioning from time to time.
Table 3 Methodology for implementing MIS
1. Understand the organization
2. Analyse the information requirements of the organization
3. Plan overall strategy
4. Review
5. Preliminary analysis
6. Feasibility assessment
7. Detailed fact finding
8. Analysis
9. Design
10. Development
11. Cutover
12. Obtain conceptual schema
13. Recruit database administrator
14. Obtain logical schema
15. Create data dictionary
16. Obtain physical schema
17. Create database
18. Modify data dictionary
19. Develop sub-schemas
20. Modify database