IS 340

Management Information Systems

Chapter 9 – Notes

Developing and Acquiring Information Systems

I. Case Study – Managing in the Digital World: Casual Gaming: You. Me, and Wii

II. Making the Business Case for an Information System – the process of identifying, quantifying, and presenting the value provided by an information system

A. Business Case Objectives – deciding what elements (in this case, information systems) that will or will not add value and competitive advantage to the firm; deciding what is in the firm’s best interests and deciding “go” or “no go” to a particular information system

B. The Productivity Paradox – while quantifying the Costs of a proposed system is easy, quantifying tangible productivity gains from its use is very difficult; while IS may produce gains, other factors may reduce those gains (regulation, taxes, etc.); also, sometimes systems have unintended consequences – employees surfing the net, personal email, online chatting, games, etc., reduce productivity gains; but identifying productivity gains from IS is a well-known problem

1. Measurement Problems – what are we trying to measure, & is that the right thing to measure? System Effectiveness vs. System Efficiency – which is to be measured and which is more important? Many systems today are a Strategic Necessity and required to stay in business (ATMs for the banking business), but are difficult to justify in terms of Costs

2. Time Lags – there may be a significant time lag between the time the investment occurs and the time the bottom line improves; businesses today want to see ROI right now!

3. Redistribution – IS may cause an increase in one place and a decrease in another, so there is a redistribution of benefits rather than an overall increase; Expectations – we fully expect technology to enable/empower us to do our jobs better, but what happens may be that it simply shortens the time for a job to be accomplished and lets us do more in the same time, and we may not recognize that gain in efficiency

4. Mismanagement – in some cases, IS is simply not managed well, or that IS masks bad management or a poor business model, when what is required is an improvement in management or a complete reworking of basic business processes

Note: While this may raise the question as to why spend the resources to build IS at all, the fact is that they are a necessary requirement to compete successfully in today’s business world and must be justified because of their large costs

Note: Some firms may spend up to 40% of their budget on their information systems – try justifying that to your senior management!!

C. Making a Successful Business Case – the case may be made several ways

1. Business Case Arguments based on Faith – despite the lack of hard data, a case can be made on the beliefs/assumptions/presuppositions of the listener; these are usually presented as Strategic arguments (related to the firms competitive strategies) without hard data

2. Business Case Arguments based on Fear – arguments based on “if we do/don’t do this … <xyz> will happen!”; many times related to conditions in the industry and/or suppliers or customers

3. Business Case Arguments based on Fact – quantitative analysis showing both benefits and costs of the system

a. Identifying Costs

1. Total Cost of Ownership – acquisition, use, & maintenance

2. Recurring and Non-Recurring Costs – training costs, hardware costs

3. Tangible and Intangible Costs – cost of hardware, loss of customers who are not ready to purchase online

b. Identifying Benefits – identify both Tangible and Intangible benefits – 10% cost reduction, better customer satisfaction

c. Performing Cost-Benefit Analysis

1. Break-even Analysis – at what point do tangible costs equal tangible benefits

2. Net-Present Value Analysis – cash flow streams at this time vs. in the future

d. Comparing Competing Investments – evaluating costs and benefits for several projects that could be chosen; no firm can afford to do all the proposed projects, so choices must be made

D. Presenting the Business Case – trying to clearly articulate the investment to the organization

1. Know the Audience – who are you presenting to?

2. Convert Benefits to Monetary Terms – most business persons understand monetary terms, so convert the benefits (saving manager’s time) of the IS into monetary terms that the audience will understand ($20K in time saved)

3. Devise Proxy Variables – when quantitative values are difficult to identify, use variables that will make sense to the audience (more time with customers while reducing administrative overhead), or use a scale of 1 to 10

4. Measure What Is Important to Management – what does management consider important? present these elements to them

III. The Systems Development Process

Systems Analysis and Design (SAD) – the process of designing, building, and maintaining information systems; performed by a Systems Analyst – competent in both technology and business/management

A. Customized versus Off-the-Shelf Software

Options for Obtaining Information Systems

1. Build it yourself - Customized

2. Buy a pre-packaged system – Off-the-Shelf

3. Outsource the process

B. Customized Software – Developed to meet the specifications of an organization; may be developed in-house, or outsourced; Expensive! Advantages:

1. Customizability – it can be tailored to meet unique organizational requirements

2. Problem Specificity – the firm pays only for features specifically requested

C. Off-the-Shelf – purchased for common business processes that do not require specific tailoring; cheaper, easier to procure

D. Combining Customized and Off-the-Shelf Software – purchase off-the-shelf, then customize it to your own specifications (copyright issues)

E. Information Systems Development in Action

1. Decompose large, complex problems into many small simple problems

2. Project Manager – the person most responsible for ensuring the success of the project; (s)he must deal with continual change and problem solving

F. The Role of Users in the Systems development Process Systems – (Lecture #1 – End User Involvement) – users have a great knowledge of their own needs and their own jobs, & must be involved in all phases of systems development

G. Steps in the Systems Development Process

****NOTE – the text is INCORRECT!

****The Systems Development Life Cycle (SDLC) has 4 phases: P, A, D, & I

****The Systems Life Cycle (SLC) has 5 phases: P, A, D, I, & M – Maintenance is NOT part of the Development process! Systems Development stops when the systems is Implemented!

H. Phase 1: System Identification, Selection, and Planning – identify and select/choose problems to be solved, begin early development process; (NOTE: the text leaves out the very important Identification process in this edition)

I. Phase 2: System Analysis – a backwards look at the Existing/Current system for full understanding

1. Collecting System Requirements – gather information from users about what is needed

a. Interviews

b. Questionnaires

c. Observations

d. Document Analysis

e. Joint Application Design (JAD) – developed by IBM; formal meeting, time limits, facilitator, agenda; most users and developers all meet together

NOT IN TEXT: Critical Success Factors (CSF) – what is required for success in the project? These are factors that MUST be successful for the project to be completed successfully

2. Modeling Data – Entity Relationship Diagram (ERD) – today’s most popular Structured Tool for modeling Data

3. Modeling Processing and Logic – Data Flow Diagram (DFD) – today’s most popular Structured Tool for modeling Movement and Processing of Data

J. Phase 3: System Design – design the proposed system

1. Designing the Human-Computer Interface (HCI) – there are different ways of interacting with the computer (GUI, text-based, etc.)

2. Designing Databases and Files – the systems analyst must have a thorough understanding of the firm’s data and informational needs to create these correctly; taken from the Data model

4. Designing Processing and Logic – steps and procedures that transform inputs into outputs that are useable by the firm

K. Phase 4: System Implementation – putting the new system into effect “cutting over”

1. Software Programming and Testing – developmental, alpha, and beta testing

2. System Conversion, Documentation, Training, and Support –

a. Direct – stop the old system, start the new; cheapest but most dangerous

b. Pilot – run the new system with a select group of users, when they are happy, give it to everyone; works well/cheap if you choose the right test group, wrong group means “oops!”

c. Phased – replace the old system one module at a time – safe, but time-consuming

d. Parallel – run both systems together until you know the new one is ok; safest but most expensive

****NOTE: SDLC stops here; Phase 5 is not part of SDLC; Phase 5 is part of the SLC

L. Phase 5: System Maintenance – longest and most expensive part of the SLC; goes on for the rest of the life of the system

1. Adaptive maintenance – changes in response to changing business needs or environmental changes

2. Corrective Maintenance – repair flaws

3. Perfective Maintenance – enhancements to improve the system

4. Preventative maintenance – reduce chances of future system failure

M. Other Approaches to Building Information Systems – the traditional SDLC is a slow process, but everyone wants things: 1. Faster, 2. Cheaper, and 3. Higher Quality

1. Prototyping – a working model of the system

a. Type I Prototype – starts small, grows to become the system itself

b. Type II Prototype – a throw-away model used to demonstrate features of the system, then replaced with a fully developed system

2. Rapid Application Development – combines prototyping, close user interaction, and CASE tools to speed up system delivery; 4 phases: (RAD moves between phases 2 and 3 until construction is complete)

a. Requirements Planning – similar to planning

b. User Design – Radical! Intense user design and interaction with prototypes

c. Construction (Design)

d. Move to the new system (Implementation)

3. End-User Development – end users developing their own systems; the text says this is a commonly used practice – THE TEXT IS INCORRECT! Professionals have been moving away from this practice as it is very inefficient and wastes a lot of time and resources that can be better used elsewhere

NOTE: from 4^th edition of this text – notes on End-User Development – this was big in the 1980’s but is not as popular now. However, if you have a lot of sophisticated users, it may work for you

1. Benefits of End-User Development

a. Cost of Labor – systems development is expensive in terms of labor, not hardware, so let the users develop what they want for themselves (with guidance from IS)

b. Long Development Time – EUD allows the users to avoid long waits (5-6 years – above) for project development and implementation of their projects

c. Slow Modification or Updates of Existing Systems – maintenance usually has a lower priority that development, so let users do their own maintenance

d. Work Overload – most IS groups are overloaded, so users can avoid waiting by doing their own development

2. Encouraging End-User development (table 10.14)

a. Personal Computer Tools – software tools enable the user

b. Query Languages/Report Generators – enable users to do their job

c. Graphics Generators – tools to create intuitive graphics

d. Decision Support/Modeling Tools – support complex decisions

e. Application Generators –development of small systems from user specifications

3. End-User Development Pitfalls

a. Users not competent to do the work – many users are simply not able to do much of what needs to be done to complete their project

b. Final systems do not interface with other system – users may not be aware of elements that make their new (personal) system incompatible with other existing systems (ERP)

c. User may not be aware of standards and practices used by the organization

d. User may not create adequate documentation, and this can cause lack of continuity of user leaves

e. Should a user hired to be a marketer or financial agent spend his time developing systems?

IV. Acquiring Information Systems– building your own system is not always feasible

A. Situation 1: Limited IS Staff – IS staff is not big enough to do everything

B. Situation 2: IS Staff Has Limited Skill Set – IS staff may not have skills to do the particular project

C. Situation 3: IS Staff Is Overworked – IS staff already has too large a backlog

NOTE: Backlog on major systems development in the US today: 5 – 6 years!

D. Situation 4: Problems with Performance of IS Staff – for any of a variety of reasons (not all the fault of the IS staff), IS performance has not been as good as the firm would wish

If in-house development is not possible/advantageous, 2 options:

1. External acquisition of a pre-packaged system

2. Outsourcing systems development

A. External Acquisition – Purchase the system from an outside vendor

1. Steps in External Acquisition – bids, proposals, etc.

2. Development of a Request for Proposal (RFP) – Formal process to let others know what you need

3. Proposal Evaluation – Demonstrating and examining criteria; Benchmarking – standardized performance tests to compare various systems on the same standards

4. Vendor Selection – make a decision

5. Managing Software Licensing – software is owned by someone, and if it is someone else you have purchased a license to use it – exactly what does that license say? What does it allow you to do, or restrict you from doing?

6. External Acquisition Through Application Service Providers (ASP) – ASPs provide software applications as needed as a service over the Web using standard Web-enabled interfaces.

B. Outsourcing Systems Development – turning over responsibility for some/all of the firm’s IS development to an outside firm; the most important factor in an outsourcing relationship is Managing the relationship.

1. Why Outsourcing? – Seven (7) reasons listed in text, all good ones:

a. Cost/Quality – the job can be done more cheaply/better by an outside firm

b. IS Performance – (see above)

c. Supplier Pressure – hire (IBM, etc.) to work on their own hardware

d. Simplifying/Downsizing/Reengineering – focus on your core competencies

e. Financial Factors – cannot afford to do it yourself

f. Organizational Culture – IS may not fit into the firm well

g. Internal Irritants – Tension can occur between IS staff & users; go outside to a neutral firm

2. Managing the Outsourcing Relationship – you must manage the outsourcing relationship or it will manage you!

3. Not All Outsourcing relationships are the same:

a. Basic – buy what you need based on price and convenience

b. Preferred – pricing/preferences beneficial to both parties; this can be an ongoing relationship

c. Strategic – both sides share risks and rewards