Information Systems for Managers

 

 

Information Systems for Managers  

 

1.  Define the term SYSTEM. Requirement analysis and definition is the foundation for any systems development. It is independent of the approach you take for design. Explain this statement with example.

System

An information system (IS) - or application landscape - is any combination of  information technology and people's activities using that technology to support operations, management, and decision-making. In a very broad sense, the term information system is frequently used to refer to the interaction between people, algorithmic processes, data and technology. In this sense, the term is used to refer not only to the information and communication technology (ICT) an organization uses, but also to the way in which people interact with this technology in support of business processes. Some make a clear distinction between information systems, and computer systems ICT, and business processes. Information systems are distinct from information technology in that an information system is typically seen as having an ICT component. Information systems are also different from business processes. Information systems help to control the performance of business processes. As such, information systems inter-relate with data systems on the one hand and activity systems on the other. An information system is a form of  communication system in which data represent and are processed as a form of social memory. An information system can also be considered a semi-formal language which supports human decision making and action. Components

It consists of computers, instructions, stored facts, people and procedures. Classification

Information systems perform three vital roles in any type of organisation:

  Support of business operations   Support of managerial decision making   Support of strategic competitive advantage

  

Information Systems is categorized in three parts:

These are basically Management Support Systems. 1.  Management Information System (MIS). 2.  Decision Support System (DSS). 3.  Executive Information System (EIS).

 

Management Information System (MIS): These systems emphasize the management orientation of information systems which support management decision d ecision making at all levels. These systems provide a variety of reports and displays to managers. The contents of these are defined by managers in advance. These systems collate information about internal operations updated by transaction processing systems and business environment data from external sources.

Decision Support System (DIS): These systems are interactive, computer-based systems which use decision/analytical models and specialised databases to assist the decision making process of managerial end users. It provides managers and analysts with analytical modelling and simulation capabilities for sales analysis, production scheduling, costing/pricing/profitability costing/pricing/profita bility analysis. Executive Information System (EIS): These are management information systems tailored to the strategic information needs of top level executives in areas of planning and forecasting.

 

Requirement analysis and definition is the foundation for any systems development. It is independent of the approach you take for design.

Requirement analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the customers or end users.

Requirement analysis is critical to the success of a development project . Requirements must be documented, actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail de tail sufficient for system design. Requirements can be architectural, structural, behavioral, functional, and non-functional

Requirement analysis includes three types of activity:  



 



 



Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance. Requirements engineering can be divided into discrete chronological steps:            

     

Requirements elicitation, Requirements analysis and negotiation, Requirements specification, System modelling, Requirements validation, Requirements management.

Requirement engineering is "a sub discipline of  systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of  hardware and software systems." In some life cycle models, the requirement engineering

 

process begins with a feasibility study activity, which leads to a feasibility report. If the feasibility study suggests that the product should be developed, then requirement analysis can begin. If requirement analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined before requirements are finalized  A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use of use cases that describe all of the interactions that  the users will have with the software. Use cases are also known as functional requirements.  requirements.  In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or  design constraints).

Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified  specified requirements requirements. One could see it as the application of  systems theory to product development. There is some overlap with the disciplines of  systems analysis,  analysis,  systems architecture and systems engineering. If the broader topic of  product development "blends the perspective of marketing, design, and manufacturing into a single approach to product development, then design is the act of taking the marketing information and creating the design of the product to be manufactured. Systems design is the process of defining and developing systems to satisfy specified requirements of the user. Therefore, Requirement analysis and definition is the foundation for any systems development. It is independent of the approach you take for design.

 

2.  Write a short note on the following: a. Knowledge Management System b. Data, Information and Knowledge Flow in Business Process c. Business Continuity Planning

Knowledge Management System

Knowledge Management System (KM System) refers to a system for managing knowledge in organizations for supporting creation, capture, storage and dissemination of information. It can comprise a part of a Knowledge Management initiative. The idea of a KM system is to enable employees to have ready access to the organization's documented base of facts, sources of information, and solutions. For example a typical claim justifying the creation of a KM system might run something like this: an engineer could know the metallurgical composition of an alloy that reduces sound in gear systems. Sharing this information organization wide can lead to more effective engine design and it could also lead to ideas for new or improved equipment. KM systems deal with information so they are a class of information system and may build on, or utilize other information sources. Distinguishing features of a KMS can include: Purpose: a KMS will have an explicit Knowledge Management objective of some type such as collaboration, sharing good practice or the like. Context: One perspective on KMS would see knowledge is information that is meaningfully organized, accumulated and embedded in a context of creation and application. Processes: KMS are developed to support and enhance knowledge-intensive processes,

tasks or projects of e.g., creation, construction, identification, capturing, acquisition, selection, valuation, organization, linking, structuring, formalization, visualization, transfer, distribution, retention, maintenance, refinement, revision, evolution, accessing, retrieval and last but not least the application of knowledge, also called the knowledge life cycle. Participants: Users can play the roles of active, involved participants in knowledge networks and communities fostered by KMS, although this is not necessarily the case. KMS designs are held to reflect that knowledge is developed collectively and that the “distribution” of  knowledge leads to its continuous change, reconstruction and application in different contexts, by different participants with differing backgrounds and experiences. Instruments: KMS support KM instruments, e.g., the capture, creation and sharing of the codifiable aspects of experience, the creation of corporate knowledge directories,

taxonomies or ontologies, expertise locators, skill management systems, collaborative

 

filtering and handling of interests used to connect people, the creation and fostering of  communities or knowledge networks. A KMS offers integrated services to deploy KM instruments for networks of participants, i.e. active knowledge workers, in knowledge-intensive business processes along the entire knowledge life cycle. KMS can be used for a wide range of cooperative, collaborative, adhocracy and hierarchy communities, virtual organizations, societies and other virtual networks, to manage media contents; activities, interactions and work-flows purposes; projects; works, networks, departments, privileges, roles, participants and other active users in order to extract and generate new knowledge and to enhance, leverage and transfer in new outcomes of knowledge providing new services using new formats and interfaces and different communication channels. Benefits of KM Systems

Some of the advantages claimed for KM systems are: 1.  Sharing of valuable organizational information throughout organizational hierarchy. 2.  Can avoid re-inventing the wheel, reducing redundant work. 3.  May reduce training time for new employees 4.  Retention of Intellectual Property after the employee leaves if such knowledge can be codified.

 

Data, Information and Knowledge Flow in Business Process

Business-related knowledge has been identified as the single most important factor ultimately defining organisational competitiveness. The speeding up of new product design and delivery has led to an increase in the demand for knowledge workers and an increase in the knowledge-intensive labour component of products. The same phenomenon combined with the emergence of automation technologies has been argued as having forced organisations into expanding their information processing and service departments while at the same time considerably reducing the material handling workers. The concepts of knowledge, information and data are closely related. Although distinct, these three abstract concepts are always confused. These three concepts are defined as follows: Data

Data is the carrier of knowledge and information, a means through which information and knowledge can be stored and transferred. Both information and knowledge are communicated through data and by means of data storage and transfer devices and systems. In this sense, a piece of data only becomes knowledge or information when it is interpreted by its receiver. In the same sense, information and knowledge held by a person can only be communicated to another person after they are encoded as data. Printed paper and computer disks are examples of data storage devices. A corporate email and the international airmail systems are examples of data storage and transfer systems. Knowledge and Information

While information is descriptive, that is, it relates to the past and the present, knowledge is eminently predictive, that is, it provides the basis for the prediction of the future with a certain degree of certainty based on information about the past and the present. E.g. statements of the type the aluminium smelter’s temperature has bee n set at 1000 degrees Celsius, then all the aluminium in the smelter will be smelted in 30 minutes convey knowledge. Knowledge and information flow between functions, or roles, in organisations. These functions are played by staff (or, in a few cases, by computer systems) engaged in the execution of interrelated activities with the use of tool. Sets of interrelated activities provided the framework. The main component of this frame work is an abstract entity called business process defined below. Business Processes

Business processes have been traditionally defined as sets of interrelated activities, or work flows. We understand, however, that the scope of the business process construct can be broadened by considering elements associated with its activities in a way that turns the business process construct into a rich unit of analysis in organisational studies. In this sense a business process can also be seen as comprising the functions (carried out by organisational staff) and tools involved in the execution of the activities in the process.

 

Moreover, the business process concept can be seen as comprising the product flow between the activities, and the suppliers and customers of the process.

 

Business Continuity Planning

Business continuity planning (BCP) is “planning which identifies the organization's exposure to internal and external threats and synthesizes hard and soft assets to provide effective prevention and recovery for the organization, whilst maintaining competit competitive ive advantage and value system integrity”. It is also called Business continuity & Resiliency planning (BCRP). The logistical plan used in BCP is called a business continuity plan. The intended effect of  BCP is to ensure business continuity, which is an ongoing state or methodology governing how business is conducted. In plain language, BCP is working out how to stay in business in the event of disaster. Typical incidents include local events like building fires, regional incidents like earthquakes or floods, or national incidents like pandemic illnesses. However, it is not limited to just that. Any event that could cause the potential for loss of business should be considered, including any event that the business is dependent on, such as loss of source of supply, loss of critical infrastructure (a major piece of machinery or computing/network resource), or the result of  theft or vandalism. As such, risk management must be incorporated as part of BCP. A completed BCP cycle results in a formal printed manual available for reference before, during, and after disruptions. Its purpose is to reduce adverse stakeholder impacts determined by both the disruptions and duration. Measurable business impact analysis (BIA) "zones" -- areas in which hazards and threats reside —include civil, economic, natural, technical, secondary and subsequent. The development of a BCP manual can have five main phases: 1.  2.  3.  4.  5. 

Analysis Solution design Implementation Testing and organization acceptance Maintenance.   Maintenance.

 

 Analysis

The analysis phase in the development of a BCP manual consists of an impact analysis, threat analysis, and impact scenarios with the resulting BCP plan requirement documentation. Solution design

The goal of the solution design phase is to identify the most cost effective disaster recovery solution that meets two main requirements from the impact analysis stage. For IT applications, this is commonly expressed as: 1.  The minimum application and application data requirements 2.  The time frame in which the minimum application and application data must be available Implementation 

The implementation phase, quite simply, is the execution of the design elements identified in the solution design phase. Work package testing may take place during the implementation of the solution, however; work package testing does not take the place of  organizational testing. Testing and organizational acceptance

The purpose of testing is to achieve organizational acceptance that the business continuity solution satisfies the organization's recovery requirements. Plans may fail to meet expectations due to insufficient or inaccurate recovery requirements, solution design flaws, or solution implementation errors. Maintenance

Maintenance of a BCP manual is broken down into three periodic activities. The first activity is the confirmation of information in the manual; roll out to ALL staff for awareness and specific training for individuals whose roles are identified as critical in response and recovery. The second activity is the testing and verification of technical solutions established for recovery operations. The third activity is the testing and verification of documented organization recovery procedures. A biannual or annual maintenance cycle is typical. As a part of ongoing maintenance, any specialized technical deployments must be checked for functionality. Some checks include:        

Virus definition distribution Application security and service patch distribution Hardware operability check Application operability check

   

Data verification Data application

     