Management Information Systems

Management Information Systems
Information Systems in Global Business Today Lecture 4

Lecture Topics Part 1: Types of MIS Applications Part 2: Selection and Acquisition Part 3: Building Info Systems

Types of MIS Applications
Part 1 Types of MIS Applications

Applications Within an Organization
An example of functional business systems might include, for example, variety of information systems (transaction processing, management information systems, decision support, etc.) that support the business functions of; Accounting and Finance, Marketing, Operations Management and Human Resource Management (HRM)

Accounting Information Systems
An Accounting Application will typically Record and report the flow of funds through an Organization Produce financial statements Allow forecasts of future conditions to be generated

Accounting Information Systems
An example of Accounting application processes

Accounting IS Processes
Order Processing – Captures and processes customer orders and produces data for inventory control and accounts receivable. Inventory Control – Processes data reflecting changes in inventory and provides shipping and reorder information. Accounts Receivable – Records amounts owed by customers and produces customer invoices, monthly customer statements and credit management reports.

Accounting IS Processes
Accounts Payable – Records purchases from, amounts owed to and payments to suppliers – it also produces cash management reports. Payroll – Records employee work and compensation data and produces pay checks and other payroll documents and reports. General Ledger – Consolidates data from other accounting systems and produces the periodic financial statements and reports of the business.

Financial Management Systems
The management systems of a Financial function support business managers and professionals in decisions concerning the financing of a business the allocation and control of financial resources within a business.

Financial Management System Examples

Marketing Information Systems
The function of marketing can have its own set of applications.

Marketing Information Systems
Interactive Marketing Sales Force Automation Customer Relationship Management Sales Management Market Research and Forecasting Advertising and Promotion Product Management

Interactive Marketing
A customer-focused marketing process using the Internet, intranets and extranets to establish two-way transactions between a company and its customers or potential customers. The goal is to profitably attract and keep customers who will become partners with the business.

Targeted Marketing Components
Community – with customized advertising to appeal to people of specific virtual communities. Content – with advertising placed on a variety of selected websites aimed at a specific audience. Context – with advertising placed on web pages that are relevant to the content of a product or service. Demographic/Psychographic – web marketing efforts aimed at specific types or classes or people. Online Behavior – promotion efforts tailored to each visit to a site by an individual, e.g., using ‘cookies’ files. (‘Cookies’? Long story, look it up.)

Targeted Marketing This is an advertising and promotion management concept that includes five targeting components

Internet Marketing There are numerous examples of (software) applications related to Marketing using the Internet. Attached to the applications are; – a communications tool for ‘pushing’ the message to customers. Web publishing – a page development tool for developing pages that ‘pull’ the customers to the message.

Sales Function Automation
The Sales Department might provide the sales force with notebook computers, Web connectivity and sales contract management software. They can connect their work to marketing websites and the company intranet. The goal being to: Increase personal productivity Speed up capture and analysis of sales data from the field to be passed on to Marketing Managers Have the effect of gaining strategic advantage

Operations Management
As an Operations Management example there follows a view of Manufacturing Information Systems that; Supports the production/operations part of the Manufacturing function Includes all activities concerned with planning and control of producing goods or services

Computer-Integrated Manufacturing (CIM)

CIM Objectives The objectives of Computer Integrated Manufacturing are to typically; Simplify production processes, product designs and factory Organization as a vital foundation to automation and integration Automate production processes and the business functions that support them with computers, machines and (possibly) robots Integrate all production and support processes using computer networks, cross-functional business software and other information technologies. These objectives will employ many different applications – some of which may be integrated.

CIM Systems Examples of CIM hardware/software systems are; Computer-Aided Manufacturing (CAM) – that automate the production process Manufacturing Execution Systems (MES) – performance monitoring information systems for factory floor operations Process Control (Systems) – that control ongoing physical processes Machine Control (Systems) – that control the actions of machines. Each of these could be viewed as an application or group of applications.

Human Resource Management (HRM)
HRM often has its own department. As a collection of applications its information systems are designed to support The planning required to meet the personnel needs of the Organization The development of employees to their full potential Control of all personnel policies and programs

Human Resources Systems Will Support…
Staffing Training and Development Compensation Administration Human resource planning Labor force tracking Succession planning Performance appraisal planning Contract costing Salary forecasting Strategic Systems Tactical Operational Labor cost analysis and budgeting Turnover analysis Training effectiveness Career matching Compensation effectiveness and equity analysis Benefit preference analysis Recruiting Workforce planning/ scheduling Skill assessment Performance evaluations Payroll control Benefits administration

HRM and the Internet The Internet is useful to the HRM (Department) for; Recruiting employees using the corporate website and commercial recruiting services Posting messages in selected Internet newsgroups Communicating with job applicants via

HRM and Corporate Intranets
An Intranet is useful to HRM for; Processing common HRM applications Allowing the HRM department to provide around-the-clock services to employees and applicants Disseminating valuable information faster than through previous company channels (such as ‘snail mail’) Collecting information from employees online Allowing managers and other employees to perform HRM tasks with little intervention by the HRM department Acting as a training tool

Employee Self-Service (ESS)
Intranet applications that allow employees to View benefits Enter travel and expense reports Verify employment and salary information Update their personal information Enter data that has a time constraint to it Can be described as ‘self-service’ and can be included as an application.

Information System Applications for E-Commerce
Information Systems applications can be used by an Organization as a basis for trade. It may be the main basis for trade (as it is for E-Bay). Many Organizations use IS applications to ‘add value’ to their product.

Major E-Business Applications
Enterprise Communication Coordination & Collaboration Electronic Business Applications Telecommunications Networks Commerce Internal Systems Intranets Extranets The Internet (Other networks) This figure has been removed from the latest version of O’Brien, but I believe it is serves to illustrate the scope of E-Business. E-Business applications go far beyond E-Commerce – buying, selling and servicing across the Internet. E-Business includes the internal or backend business processes and enterprise communications and collaboration. Front End Back End

Cross-Functional Systems
In Organizations the boundaries of traditional business functions often intersect, overlap or integrate. This is so that Management can reengineer and improve vital business processes all across the enterprise.

Cross-Functional Systems
Below the diagram describes a sequence of events that matches the early part of a product’s life cycle. The functions of Marketing, Engineering and Manufacturing will have tasks (therefore applications) that overlap. New Product Development Process

Enterprise Business Systems
Suppliers Customers Employees Partners Supply Chain Management Sourcing - Procurement Enterprise Resource Planning Internal Business Processes Customer Relationship Management Marketing – Sales - Service Collaboration – Decision Support Knowledge Management Partner Relationship Management Selling – Distribution Enterprise Application Architecture

Customer Relationship Management (CRM)
CRM uses technology to Create a cross-functional enterprise system that integrates and automates many of the processes in sales, marketing and customer service that interact with customers and to Create a framework of web-enabled software and databases that integrate these processes with the rest of the company’s processes.

Customer Relationship Management
CRM Uses IT to Create a Cross-Functional Enterprise System Marketing and Fulfillment Customer Service and Support = Employee or Prospective Customer Fax Sales Cross-Sell Up-Sell PATIENTLY ALLOW TIME FOR ANIMATIONS TO WORK This animated graphic demonstrates how CRM uses IT to create a cross-functional enterprise system. Explain each of the component parts and the roles they play. Telephone Web Retention and Loyalty Programs Contact and Account Management

CRM Applications Contract and Account Management; Sales
Helps sales, marketing and service professionals capture and track data about past/planned contacts with customers/prospects Sales Provides Sales Representatives (reps) with the software tools and data they need to support and manage sales activities ‘Cross-selling’ is trying to sell a customer of one product with a related product ‘Up-selling’ is trying to sell customer a better product than they are currently seeking

CRM Applications Marketing and Fulfillment help marketing professionals accomplish direct marketing campaigns by tasks such as Qualifying leads for targeted marketing and scheduling and tracking direct marketing mailings.

CRM Applications Customer Service and Support
Provides sales reps with software tools and database access to customer database shared by sales and marketing professions Helps create, assign and manage requests for service Call center software that routes sales calls to customer support agents based upon their skills and type of call Help desk software that provides relevant service data and suggestions for resolving problems for customer service reps helping customers with problems

CRM Applications Retention and Loyalty Programs
Try to help a company identify, reward, and market to their most loyal and profitable customers Seen as a function, Retention and Loyalty might use data mining tools and analytical software that extracts information about customers and prospective customers from a ‘Customer Data Warehouse’.

CRM: The Business Focus
Customer Relationship Management supports integrated and collaborative relationship between a business and it’s customers. Acquire Enhance Retain Customer Life Cycle Direct Marketing Cross-sell and Up-sell Proactive Service CRM Functional Solutions Sales Force Automation Customer Support The Internet Shared Customer Data Collaborative Service CRM Integrated Solution Partner Company Customer

Benefits and Challenges of CRM
Customer Relationship Management benefits are; Identify and target the best customers Customization and personalization of products and services Track customer contacts Provide consistent customer experience and superior service/support CRM failures identified in a case study; 50% of applications fail to meet expectations 20% of the time CRM damaged, rather than enhanced, customer relationships A lack of understanding of customer expectation and preparation for customer service is blamed.

Enterprise Resource Planning (ERP)
ERP: a cross-functional enterprise system with an integrated suite of software modules that support the basic internal functions of an Organization. (Functions = ‘business processes’ in some of the books, case studies and web sites.)

Enterprise Resource Planning
Integrated Logistics Production Planning Sales Distribution, Order Management Customer/ Employee Accounting and Finance Human Resources

Enterprise Resource Planning – the Benefits
ERP is often established in Organizations with large numbers of employees, numerous or complex departments and/or large numbers of customers because of a perceived value of; Quality and efficiency in products and operations Decreased costs in production and operations Decision support for Management Enterprise agility – the ability to change strategies and/or methods in response to ‘outside’ changes.

Costs of Implementing a New ERP
Percentages identified in a case study

Enterprise Resource Planning Failures
Case study findings; A company had software installation problems of ERP Integrated Suite into its retail environment. Two retail outlets blamed ERP software for poor financial performance. A grocery had problems with number of transactions. Another large retailer replaced the entire ERP system.

Enterprise Resource Planning Failures
Causes of ERP failure: Underestimating the complexity of the planning, development and training needed Failure to involve affected employees Trying to do too much too fast Insufficient training in new work tasks Failure to do enough data conversion and testing Over reliance by the company on claims of the ERP sellers or consultants

Supply Chain Management (SCM)
Supply Chain Management is a cross-functional inter-enterprise system to help support and manage the links between a company’s key business processes and those of its suppliers, customers and business partners. (Processes? Functions!)

Supply Chain Management
Supply Chain Management (SCM): an application to match strategic objectives for many firms - The right products The right place The right time In the proper quantity At an acceptable cost

Schedule Make Deliver Transportation Planning Demand Order Commitment Advance Scheduling Manufacturing Distribution Internetworked Supply Chain Management Supply Chain Life Cycle SCM Functional Processes Integrated Solution Commit

The Role of SCM

SCM Software helps Organizations reengineer and integrate the functional SCM processes Commit Schedule Make Deliver Supply Chain Life Cycle SCM Functional Processes Strategic Sourcing and Procurement Forecast and Demand Planning Customer Order Fulfillment Service Distribution Network and Warehouse Operations Production Logistics Transportation and Shipment Management The Internet Shared Market Data Collaborative Fulfillment SCM Integrated Solution Supplier Manufacturer Retailer Customer

The goals of SCM is to establish fast, efficient, low-cost network of business relationships or a supply chain to get a company’s products from concept to market. A supply chain is made up of interrelationships with suppliers, customers, distributors, and other businesses that are needed to design, build and sell a product.

Causes of problems with SCM: Lack of proper demand-planning knowledge, tools and guidelines Inaccurate or over-optimistic demand forecasts Inaccurate production, inventory and other data Lack of adequate collaboration within the company and between partners SCM software considered immature, incomplete and hard to implement

Enterprise Application Integration (EAI)
EAI connects cross-functional system and serves as middleware to provide data conversion, communication between systems and access to system interfaces.

Enterprise Collaboration Systems (ECS)
Enterprise Collaboration Systems (ECS): cross-functional Information Systems that enhance communication, coordination and collaboration among the members of business teams and workgroups.

Enterprise Collaboration Systems
Enterprise Collaboration Systems goals are to: Communicate - share information with teams and work groups Coordinate - coordinate individual work efforts and use of resources with teams and work groups Collaborate - work together cooperatively on joint projects and assignments

ECS Tools

Why Collaborate? Workgroups and project teams work together efficiently and effectively regardless of location, they share information, coordinate work efforts and resources. They work together cooperatively.

Selection and acquisition of Information Systems
Part 2 Selection and acquisition of Information Systems

Selection and Acquisition
Selection of Information Systems is a managerial task when (or where) the hardware and software of a new Information System need to be decided upon. The task of ‘acquisition’ follows these decisions – it can be seen as the ‘buying in’ of hardware and software to match the choices made.

Selection and Acquisition – Where They Fit In
Systems Investigation Analysis Design Implementation Review & Maintenance Feasibility Study Project Selection Selection Acquisition } Using the Waterfall Life Cycle Model

Selecting Between Alternatives
When choosing software for applications: Select the criteria for making the choice, Associate ‘weights’ with each criteria, Score acquisition alternatives in terms of how they satisfy the criteria, Calculate the potential choices’ rating by multiplying each score by the weight and then sum the total, Select the one with the highest score.

Criteria for selection of systems or software: List its ‘must-do’ features, ‘should-do’ features ‘nice-to-do’ features Critical success factors for acquisition: Deciding who will manage the purchase, Knowing what to do, Knowing how to do it, Having time to do it.

Difficulties in the early part of software selection: Developing a criteria list, Weighting the criteria list - Especially in service areas. Developing benchmarks - The methods chosen must be tailored to the actual use of a system.

Criteria List The criteria define the set of characteristics that the selection candidate software should have. They enable the elimination of some alternatives at an early stage. Examples of criteria; The cost consideration of Information Systems elements (hardware, software…), Maintenance and support (whether worthwhile, whether provided at all), Quality of the supplier(s) (The vendors), Quality of their product(s).

Weighted Selection Process
Benefits of applying a scoring method of ‘weighting’ software component solutions : It brings objectivity to the selection process. It breaks down the complexity of solutions into their constituent parts so that it becomes possible to compare solutions - This eases the comparison of simpler solutions with those with more complexity.

General Selection Guidelines
The desire to gain ‘hardware economy’ – the idea of having the newest and the most sophisticated hardware - should not motivate selection. Software, not hardware, should drive almost all Information Systems selection decisions. The Organizational (business?) need is generally to have an Information System made up of; System software Hardware Application software

Software generally has a longer life than the hardware on which it runs. Data has even greater longevity. The Information System function should not be migrated to a new architecture without a very good reason - so compatibility with the current architecture should score highly. If using software from more than one vendor, connecting components from one or more vendors is generally difficult /… continued

Because of the view of hardware being the first aspect of the new system to ‘wear out’, followed by software and, eventually, the data, the choice of architecture is important. The architecture should allow for the inclusion of new hardware in 2 – 5 years, software in 2 – 7 years and the reformatting of data in 5, 10, 20… years. /… continued

Connecting applications from different vendors is usually technically feasible - whether it is desirable or not depends on a trade-off between benefits and complexity. Information requirements can never be fully defined in advance, so the selected system or subsystems must be capable of adaptation and growth. Avoid ‘pioneering’ with untested systems unless there is good business justification.

General Selection Guidelines - Summary
Do not change without a reason. When change is needed: Keep it simple. Go for compatibility with current architecture, if at all possible. Go for flexibility. Work from the Organizational problem, through software and hardware options, to a solution. Do not look for ways to choose the most elegant solution, irrespective of the problem.

Two Options There follows two options for selecting software – though there are many; Standard packages Outsourcing Standard packages are software products that are available to buy immediately, since they are ‘off-the-shelf’. Outsourcing, in the current context, is the idea of buying software or software services from a ‘third party’.

Issues with Standard Packages
If considering modification of a bought standard package… Ownership could be retained by the vendor. Your changes may compromise your current licence if your software is licensed. Changes may not be covered by technical support. They may not be supported in upgrades. Upgrade trap Where vendors only support most recent versions of software. (A sales strategy on their part.)

Issues with Standard Packages
Vendor lock-in New systems may be difficult to replace in the future. Training costs There may be a need to train in-house staff to support and maintain the bought-in system.

Outsourcing Outsourcing is the term that describes the purchase of systems development services from outside the Organization. This often entails buying ‘off-the-shelf’ software – or software written specifically for the Organization and may also mean ‘buying in’ system analysis work.

Outsourcing Subcontracting all or parts of the IT function to an external vendor as an alternative to relying solely on in-house resources or capabilities. An Organization can create a strategic partnership between itself and the outsourcing vendor. An outsourcing vendor, with highly specialized and technical employees, assumes a contractual obligation for the organization’s IT systems and their operation.

Outsourcing An Organization may outsource: Data Center Operations
Hardware Support Systems Software Licensing Telecommunications Applications Software Maintenance In certain cases some firms may outsource planning and development of all IT systems. More commonly, selective portions of the IT function are contracted out while keeping control over strategic activities.

Outsourcing An Organization is likely to have;
limited amounts of capital for new technology investment, limited in-house capabilities to make a wise investment, scarce or narrow IT expertise and/or insufficient resources to adequately support or enhance their existing IT activities.

Outsourcing - Reasons The recruitment and retention of experienced IT staff, IT purchasing decisions, A need to make choices that will be appropriate and beneficial both now and in the future. Deciding to focus on core business activities, which often do not include IT systems or telecommunications.

Outsourcing – Reasons When it is more efficient in terms of cost/benefit to outsource IT for use in gaining competitive advantage. Where there is a need to acquire new resources As a reaction to ‘the bandwagon’ (keeping up with competitors) To reduce uncertainty ‘in the field’ To eliminate some troublesome function To enhance credibility of the Organization or its products

Outsourcing - Benefits
Reduces costs as a result of economies of scale. Vendor consolidates activities for a number of clients. The client avoids large capital investment. Enables a strategic business focus. The Organization can concentrate efforts on a manageable number of activities. Improve financial predictability and reduce uncertainty associated with IT. Facilitates technology ‘leapfrogging’ or ‘catch-up’. Economies of scale : The outsourcing vendor can consolidate the IT management activities of various clients, thus performing them more efficiently and effectively. The client can avoid large capital investments for new technology while reducing internal staffing requirements and licensing fees. Strategic Focus : The organization can concentrate efforts on a manageable number of activities. A long term contract with the vendor can improve financial predictability and reduce uncertainty associated with IT.

Outsourcing – Benefits
Enables leveraging of IT expertise. Internal IT staff to focus on higher priority activities. IT staff can give greater attention to key business issues. It offers a way for an Organization to receive the benefits of the latest hardware and software - without making all the purchases themselves by, for example, leasing software. Leveraging IT expertise : Allows internal IT staff to focus on higher priority activities such as creation of new strategic level systems to deliver competitive advantage. Relieves IT staff of routine data processing responsibilities so that they can give greater attention to key business issues.

Outsourcing - Problems
Some loss of strategic flexibility. Potential irreversibility if problems occur. Organizations choosing outsourcing without negotiating a detailed contract may also encounter hidden costs or dramatic increases upon renewal. The outsourced vendor often fails to support the Organization’s business needs. Internal improvements could be neglected. Human Resources effects – the new applications may not suit some employees. It may change the role of internal IT staff to maintenance staff. Irreversibility : Costly and difficult to rebuild its own IT architecture and expertise after these have been handled by an outside party for a considerable period of time. Higher long term costs offset short term savings. Failure to meet needs : Vendor may have poor understanding of business, thus damaging customer relations by inappropriate task priorities and inadequate provisions for data security and recovery from hardware disasters. HR Issues : Potentially most difficult aspect of the outsourcing decision. Staff in a newly outsourced function may be re-deployed internally or transferred to the vendor for a negotiated transition period. Concerns : staff do not return and leave organization without internal expertise. Staff concerned over career prospects. Change in role of IT Staff : Outsourcing changes the role of the internal IT staff. They will focus on monitoring subcontracted work using performance indicators. May be problems of dual loyalties among transferred employees.

Hardware Selection Hardware – evaluated with a view to selection will have the following factors examined: Performance Speed, capacity, throughput Cost Lease or purchase price Cost of operations and maintenance

Hardware Selection Reliability Compatibility …/ continued
Any risk of malfunction and maintenance requirements will be identified Error control and diagnostic features will be specified Compatibility With existing hardware and software? With hardware and software provided by alternative vendors? …/ continued

Hardware Selection ‘Future proof’? Ergonomics …/ continued
What is the speculated product life cycle? Does it use a new, untested technology? Does it run the risk of obsolescence? Ergonomics Is the equipment “human factors engineered”? Is the hardware user-friendly? Is the hardware safe, comfortable and easy to use? …/ continued

Hardware Selection Connectivity
Is the hardware easily connected to Wide Area Networks and Local Area Networks that use different types of network technology and various bandwidth alternatives? Scalability (Does the hardware fit with application tasks?) Can the hardware handle the processing demands of end users, transactions, queries and other processing requirements? …/ continued

Hardware Selection Software Support
(The big question) Is the selected system software and application software best suited this hardware? Support Is support available for this hardware, should equipment go wrong?

Hardware Acquisition When the hardware has been selected there can be a process of hardware acquisition. This is, on the surface, a straightforward task of buying the equipment specified in any Hardware Selection Report.

Hardware Acquisition What makes hardware acquisition difficult is the ‘policy for procurement’ that many Organizations have. This means that Management representatives meet with hardware vendors and ‘haggle’ over what is, ultimately, to be bought in and whether discounts and concessions might be applied.

Hardware Acquisition The hardware vendor will be asked to enter into a contract of sorts – ensuring that the hardware order is complete and on time. There may be more than one hardware vendor (supplier) for complex hardware systems or where there are, for example, ‘dedicated’ network systems that require specialized hardware manufacture.

Software Acquisition Management responsibility for acquisition:
Senior management must recognize the potential for gain in the acquisition of software. Management should review and re-review the relationship between the Organization and Information Systems strategies during the acquisition process. Management should assess the implications of any sensitive applications as part of the procurement process. Senior management : commitment is vital during first phase of acquisition of an element Review: must be in step with both long and short term goals . Need to involve all affected groups Sensitive: frequently business sensitivity

Acquisition of Software – Possible Process
Package Available ? Common System Yes Yes Select a standard package No No Software House Interested ? Yes Any Strategic Impact ? User Development No Yes In-house IS Team Development

(S/W) Acquiring… While working in Information Systems with such job titles as IT Manager, Project Manager, Systems Analyst, Network Administrator… (and may more with some level of management) a person may be asked to ‘get’ things.

(S/W) Acquiring… The ‘things’, in this context, are very often ‘resources’ of one sort or another and may be sorts of hardware, software, personnel or parts of ‘infrastructure’ to contain these things/people.

(S/W) Acquiring… Acquisition may have other names: Procurement
Purchasing Buy-in

The Software Acquisition Task
The duty of software acquisition is, briefly, to get the most appropriate software for a particular task for the best possible price. The price being applied to the Organization for which the (systems analyst) works. “If only it were that easy!” … a systems analyst might say.

Software Acquisition Considerations
Purpose (of the software) Planning (to place and use the software) Cost-benefit analysis Quality Licensing Life span (or Life Cycle) Risks

(S/W) Managing Acquisition
The purchase of software very often involves the management (or control) of: Complex, diverse requirements, A large software development team, Software that is not completely commercial off-the-shelf, but may include some (- to cause complex inter-operability problems), Legal issues involving contracts, copyrights, trade secrets, patents, warranties, and product liability, Disparate interests/focuses of the developers, the acquirers (themselves) and, possibly, the users.

Software Acquisition Process
An example of the process of software acquisition might look like this: Planning, Budgeting, Specifying requirements, Soliciting bids/responses, Evaluating bids/responses, Contracting/negotiating, Monitoring development progress, Evaluating/accepting a new system.

Software Development Environment
Where does ‘Software Acquisition’ fit into the whole Software Development environment? Overall you could have a Software PROJECT Within that you could have: Software Engineering – where software is developed ‘in-house’ Software Acquisition – where software that cannot be developed in house is bought in.

Software Development Environment
Software Project Management – the process of managing the technical process. Software Engineering Management – the process of building the software product. Software Acquisition Management – the process of assembling the requirements, planning the project, acquiring the resources, and monitoring and controlling the implementation.

Back to the Acquisition Process
The buyer (acquirer) plans for the acquisition by: Detailing the requirements Allocating the resources Arranging for the selection of a vendor Contracting with the selected vendor Building an in-house team of users and acquirers Addressing the support requirements

Back to the Acquisition Process
The vendor (seller) prepares for the acquisition by: Deciding whether the resources and capability to bid on the contract are available Deciding whether to bid Developing a team to respond to the proposal Estimating the resources required to accomplish the work

Will There Be Problems? The challenge in most projects is to manage:
Functionally: Organizationally: - Cost - Acquirer - Schedule - Developer - Performance - User Ideally, the user should specify performance, the vendor (seller, supplier) should bid with a cost and schedule, the acquirer should make the big decisions.

A Few Problems Problems occur in the areas of: Communication Planning
Requirements Verification and validation Maintenance

Building Information Systems
Part 3 Building Information Systems

Where/When Does the ‘Build’ Begin?
The building of an Information System could be viewed as occurring throughout the life cycle, but the main ‘build’ – the one that has the appearance of a project – is in the latter part of the Design Phase and throughout the Implementation Phase. Building assumes that most, if not all, of the design issues have been agreed upon between the client and the vendor.

System Build – Where It Fits In
Systems Investigation Analysis Design Implementation Review & Maintenance Feasibility Study Project Selection The ‘build’ } Implementation is building upon the Design to further develop the selected solution

From Design to Implementation
Let us take a look at the typical features of Design and Implementation phases to see how the building of an Information System spreads itself as an ‘extended process’.

Systems Design The Systems Design Phase:
Details how the system will meet information requirements as determined by the procedure of Systems Analysis May involve the user interface and output design for usability Deals with configuration and architecture issues related to the system for scalability, reusability, and performance (measurement)

Systems Design The systems Design Phase usually has many items of documentation. Typical and important documents are the Specifications for the system solution. The Design Phase should reflect clearly the clients’ business priorities and information needs.

Between Design and Implementation
Programming and Testing Programming: The process of translating System Specifications into program code. There are many different languages. More than one may be needed for coding the complete Specification. Breaks down into logic of linear processes, logical decisions, repetition, and ‘calls’ to other programs. Integration is needed and may be required at module, application, system, intra and inter-system levels via ‘middleware’ and calls to programs/modules.

Programming and Testing Testing: Checks whether the system of programs/modules produces the desired results under known conditions. Is a serious part of the development of a system and good ‘test cases’ are required. Testing includes ‘unit’ testing (testing individual modules), system testing (testing all programs together), acceptance testing (demonstrating all programs for client agreement). There is often a document showing a ‘test plan’.

System Conversion: The process of changing from the old system to the new system. Four possible installation choices: Firm-wide rollout versus ‘single location installation’ rollout (Example; all Target stores Vs. one Target at a time) Entire application installation versus ‘phased’ installation (Ex; all software loaded Vs. one application at a time) ‘Direct’ installation vs. ‘parallel’ installation (Running without old system Vs. using new and old together until the ‘new’ is trusted) In-source versus Outsource (Internal IT expertise Vs. ‘hired in’ IT expertise)

Production and Maintenance: Production is the stage after the new system is installed and the conversion is complete. Basically, it is the system in use. Maintenance is a series of tasks following changes in hardware, software, documentation or procedures to correct errors in the system(s). Maintenance can be seen as starting the process over again but on a different scale.

Managing the Build as a Project
As we move through the Design Phase agreements and take the product of those agreements (Specifications) and apply the ‘Specs’ to program-writing, going into the Implementation Phase requires management of a specific kind. Building of the Information System can be viewed as a project and treated as such.

Who’s Who in Project Management
The people associated with this broad level of management include: Users Organizational Management Auditors, Quality Assurance personnel and “standard bearers” – those who represent the products or services.

Who’s Who The people ‘visible’ during the coding of Specifications are typically: Systems Analysts Systems Designers Programmers Web Designers (in the case of Internet applications) Operations Personnel (End users)

Issues in Project Management
Establish the Scope of the Project This usually means making a statement on: Key deliverables Timescales and budgets Performance standards Documentation standards Verification, validation and testing Keeping strictly within the agreed scope to avoid ‘scope creep’

Managing Change ‘Change’, as an issue in Information Systems development has several connotations and each is dealt with differently at different times. The two variations that a Systems Developer may need to deal with are: the change to the workplace – environmental. Changes to the systems development project – administrative. We will look at the idea of changing the project on this occasion. …/ Continued

Change, then in the current context includes modifications to the approved project baseline. In this case, change request procedures are established; Any change request is documented so that its exact nature is understood by all. Investigate the impact of each change request on timescales, budgets, quality, resources and end users. Seek management approval of change requests.

Managing Risk Types of risk; Budget overrun, Time overrun, Performance requirements not being met, Incompatibility with the existing or proposed environment(s), Business needs not being met, Business and technical benefits not achieved (at the implementation stage), Resource or skill deficiency becoming evident. …/ Continued

Strategies for managing risk; Have clear objectives and a well defined scope (This may need client agreement.) Monitor potential problem areas carefully, Ensure training and education is adequate, Partition design and development work into manageable ‘chunks’ (Consider life cycle stages.) Involve the users in the project, Select the appropriate techniques and tools.

Managing Quality Managing quality is concerned with the prevention and detection of defects (mainly in the software, in this context). A ‘quality plan’ for software might ask: What standards are applicable? What inspections will take place and when? Who will be involved in the inspections? What techniques will be used in the inspections? What procedures will be applied at each type of inspection? What standards will be applied to products and deliverables? …/ Continued

Four levels of review Project team reviews Product reviews Management reviews and approvals Quality assurance reviews

Four Levels The ‘Who’s Who’ list from earlier could be viewed as a list of people who might become members of temporary committees and groups that will help coordinate the development of a complex (expensive) system under development. Members of one committee or group can be members of other committees or groups.

Four Levels The Information System Steering Group/Committee
A Steering Group may be a permanent coordinating mechanism at corporate level, responsible for establishing and implementing company policy. Members usually include heads of all key business functions and the head of Information Technology. Normally chaired by a Board member or similar ‘high-ranking’ individual.

Four Levels The Project Steering Committee
Responsible for the management of one or more specific projects, Established, where necessary, by the Steering Group. Should consist of representatives of the business units affected by the projects and of IT specialists.

Four Levels The Project Team itself
A group responsible for the actual work in the project. Headed by a Project Manager who reports to the Steering Committee on/for the project. This leader is normally a senior member of the Information Technology staff.

Four Levels The Quality Assurance Group
A permanent group responsible for assuring the quality of all systems development. One member of this group will normally be seconded to each project.

Four Levels The Information Systems Steering Group
A group concerned with the business and strategic issues arising from Information Systems and setting the technical direction from an Organizational perspective. Ensures that all IS projects are coordinated and properly carried out. Responsible for formalising and publishing the Strategic IS/IT provision (documentation). Initiates reviews of the Strategic IS/IT usage. Sets priorities that provide the business direction of IT …/Continued

Four Levels Responsible for Information Technology (IT) strategy.
Ensures that IT runs as ‘an Organization within an Organization’. Provides a forum for the exchanging of ideas, concerns and experiences. Setting priorities for: Benefits - what is most important to do? Resources - what can be done? Risks - What is likely to succeed?

Four Levels The Project Steering Committee
Initiates formal communication procedures between groups involved in the project. Helps ensure that all planned deliverables are on time and within budget. Reviews and approves all project plans. Authorises commitment of resources. Approves or disproves continuance of the project. Evaluates the post-implementation review.

The Problems of Steering Committees
They may have difficulty in reaching decisions. They may have an inability to communicate decisions in a clear and unambiguous manner. They are increasingly involved in administrative detail. They may show a lack of communication between themselves and systems groups. Poor attendance may occur where committee members fail to be representative at meetings. They may have unrepresentative members (due to laziness or disinterest). Sometimes there is excessive involvement in minutiae.

Manager of a Project The Project Manager:
Defines and reviews deliverables, Estimates resources, Plans, schedules and tracks tasks, Assesses risk, Resolves issues.

The Quality Assurance Group
Process reviews done by this group ask: What went wrong and why? How could it have been avoided? What lessons can be learned for the future? What went right? How were new problems and challenges overcome?

The Quality Assurance Group
Total Quality Management (TQM) Ensures quality is a planned rather than coincidental feature. Needs full management commitment to quality. Needs well-trained and highly motivated staff. Sends a positive signal to the outside world.

From Management to Programming
Let us examine some of the issues related to the ‘sub-phases’ of Programming and Testing. The next part of the lecture tries to keep to the themes of Design and Implementation Phases as well as Project Management.

Coding Practices A good software program:
works according to specification and is verifiable is well commented is written in an appropriate language has a simple design is modular, with independence uses only sequence, selection and iteration is independent of specific hardware constraints is efficient

Coding Practices Good commenting (accompanying instructions) examples:
4 - 5 lines per module (subroutine/section) 1 line per lines of code. Assembler programs should have almost one comment per line 4GLs do not need much commenting. Comments should be brief and to the point. Data and module names should also be brief and to the point.

Coding Practices Pitfalls in code commenting: Redundant commenting,
Obsolete comments, Incorrect comments, Vague comments, Correct, but incomplete comments, Incomprehensible comments.

Design Options When designing software programs there are two main options: Top-Down Design and Bottom-Up. Top-Down is probably the most popular and begins with a general view, moving to more detailed views that become comparable to code modules. Bottom-Up begins with finer-detailed program design options and tries to fit them to broader solutions.

Top-Down Design Top-Down Design practice includes:
Formal and rigorous specification of input, processing and output of each module. When the module is properly specified, disregard the internal workings. Keep away from trivialities. Each level of design should be expressible on a single page of flowchart. Pay as much attention to data design as to process / algorithm design.

Top-Down Structure Diagrams
HIPO Diagrams HIPO stands for Hierarchical Input Process Output

Top-Down Structure Diagrams
For each module do an Input-Process-Output (IPO) chart Output Input Processing

Top-Down Coding As a level is specified, the coding is done for that level, before subordinate levels are specified. Design flaws discovered early on. ‘Dummy’ modules must be inserted, to allow for the running of the program. Some modules will take precedence over others; a processing module cannot run without the input module being written and the results cannot be seen without the output module. Arrange modules in the program in an organized fashion, i.e. either horizontally or vertically.

The Advantages of Modularity
When writing code as modules there are advantages. Code is: Easier to write and debug. Easier to maintain and change. Easier for a manager to control (e.g. as regards delegating programming tasks to programmers of varying abilities).

The Disadvantages of Modularity
Coding modules has disadvantages: A lot of programmers do not understand it. It requires a great deal of extra work. It may require more processing time on the computer. It may require more main memory. It may cause problems in real-time and on-line systems. Modules normally working together should be on the same page.

Testing Levels Module (unit/program) Testing.
Subsystem Testing (Groups of modules but not the whole system). Integration Testing (The whole system).

Testing Methods Black Box Testing - (Functional Testing)
Top-Down testing Knowing the specific functions a system is required to perform, tests are developed to demonstrate that each function is working correctly.

Testing Methods White Box Testing - (Structure Testing)
Bottom-Up testing Knowing the internal workings of the system, tests are developed to ensure that each program is working according to it’s specification.

Black Box Use dummy modules to represent the lower units… Main A B C

Black Box The system is considered as a black box whose behavior is determined by examining inputs and related outputs. Tests are designed to demonstrate that system functions are operational input is correctly accepted output is correctly produced the integrity of the system files/databases are maintained Test cases are derived from the requirements documentation.

Black Box Black box tests attempt to find software errors such as:
incorrect or missing functions interface errors errors in data structures or external file or database access performance errors initialisation and termination errors

Black Box The benefits of Top-Down testing:
System testing ought to be eliminated Major interfaces are tested first Prototyping is enabled A usable subset is available before the deadline Testing is evenly distributed Quicker results It creates a ‘natural test harness’

White Box X Y Z A X Z Y

White Box Testing Using White Box Testing the software engineer can design tests cases that check: Path - Guarantee that all independent paths within a module have been exercised at least once Condition - Exercise all logical decisions on their true and false sides Loop - Execute all loops at their boundaries Data Structures - Exercise internal data structures to ensure their validity

White Box Testing Bottom-Up Testing is needed:
To test a module on insertion to Top-Down structure. To rigorously test a module where calling environment cannot. To accommodate an imperfect Top-Down implementation.

Desk Checking When a programmer checks the program logic by looking at it, general errors found include: Failure to follow specification Commenting errors Quality (Standards) errors ‘Fitting-in’ (Being able to run on the hardware) Logic errors (Sequence, Selection, Iteration logic errors)

Structured Walkthrough
This is a presentation of a program to a group, which may include other programmers on the project, the project leader or manager and maybe a user. All are issued with a listing of the program specification, coding, test data and results a day or two before the meeting.

Structured Walkthrough
The purpose of the walkthrough is to provide a non-aggressive evaluation of the program, in regards to its 'goodness' as described earlier. The programmer receives advice on where a program contains errors. It is the programmer's responsibility to correct any errors uncovered and to hold another walk-through. The idea of the walkthrough is that responsibility for the 'goodness' of the program is shared.

Evaluating Test Results
Test results can be :- output files reports screens updated data on a database To check them they must be printed, browsable or compared with expected results. Differences should be printed or otherwise recorded. If differences exist, a storage dump may be produced. This is difficult to use, stops the test run and generally signifies serious trouble.

Utilities The utility exercises of code testing (which may, themselves, be programs… system software programs) include: Traces Core dumps Snapshots Desk checking Test data loader Test data generator Transaction capture facility

Other Testing Methods Static program analysis (isolating programs and inspecting them line by line) Dynamic program analyser (This may be a testing program ‘run over’ the module under test) Mathematical proofs (Using comparative formulae) Seeded bugs (Placing bugs (which are erroneous instructions or data) into a program to see how many are detected. Example; placing 10, 6 found – indicates a 40% detection failure rate) Clean room approach (Where the code is tested as it is written so that no errors ‘creep in’)

Testing Principles All tests should be traceable to client requirements (A quality quotient should be met). Tests should be planned long before testing begins. 80% of all errors uncovered during testing will likely be traceable to 20% of all program modules.

Testing Principles Testing should begin “in the small” and progress toward testing “in the large”. Exhaustive testing is not possible. To be most effective, testing should be conducted by an independent third party.

Information Systems security
End of Lecture 4 Next Topic Information Systems security

Management Information Systems

Similar presentations

Presentation on theme: "Management Information Systems"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Management Information Systems

Similar presentations

Presentation on theme: "Management Information Systems"— Presentation transcript:

Similar presentations

About project

Feedback