1. 11/26: How IS Systems Change the Organization, Systems-Building
Systems as planned organizational change
Systems development
Influences on & challenges to implementation
Systems development approaches
Systems building methodologies

2. Systems: organizational change
Linking to the business plan
The plan
Establishing organizational info requirements
Enterprise analysis vs. Strategic analysis
Systems development & organizational change
Automation, rationalization, reengineering, paradigm shift

3. Systems as planned organizational change
“One cannot install new technology without considering the people who must work with it.”
Systems can be technical successes yet be organizational failures if the political process fails.
The IS plan must be linked to the business plan, supporting overall business goals & integrated into top-level planning.

4. The Information Systems Plan
Serves as a road map to describe:
The purpose of the plan
Strategic business plan: current situation
Current IS systems
Management strategy
Implementation plan
Budget requirements

5. 2 Ways to Find the IS Requirements
Enterprise Analysis: “looking at the whole”
Central approach: ask large number of managers:
How they use information, where they get it
What their environments are like
What their objectives are
How they make decisions
What their data needs are
Create logical application groups:
Groups of data elements that support related sets of organizational processes.
Tends to automate whatever exists, no fundamental change.

6. 2 Ways to Find the IS Requirements
Strategic Analysis, or CSF: Critical Success Factors
CSFs shaped by industry, environment, and manager
Central approach: 3-4 personal interviews with top management, identify goals and the CSFs.
Advantages
smaller data set to analyze.
Takes into account the environment & industry.
Disadvantages:
it’s an art form
opinions may differ on what the CSFs are
Biased toward top management

7. Systems development & org. change
paradigm shift
RISK
reengineering
rationalization
automation
RETURN

8. Systems development & org. change
Automation
Using the computer to speed up the performance of existing tasks

9. Systems development & org. change
Rationalization
Involves streamlining of standard operating procedures, eliminating obvious bottlenecks, so that automation makes operating procedures more efficient.

10. Systems development & org. change
Reengineering
Radical redesign of business processes, combining & eliminating steps to reduce waste and repetition, to improve cost, quality, and service.
Management must understand & measure current design to assess improvements with new design.

11. Systems development & org. change
Paradigm shift
Rethinking the nature of the business and the nature of the organization itself.

12. Systems Development
All activities that produce an IS solution to an organizational problem or opportunity.
A structured kind of problem-solving with six distinct activities:
Systems analysis
Systems design
Programming
Testing
Conversion
Production & Maintenance

13. Systems Analysis Defining the problem Identifying its causes
Specifying the solution
Identifying the information requirements needed.

14. Systems Analysis Includes a feasibility study Technical feasibility
Is the proposed solution technically achievable? Is it possible?
Economic feasibility
Do the benefits outweigh the costs?
Operational feasibility
Will it work in the organizational & managerial framework?
Do an organizational impact analysis:
How a new IS will affect org. structure, attitudes, decision-making, and operations.

15. S.A.: Information Requirements
Basically: who needs what information, when, where, and how?
Incredibly important!

16. Systems Design
Detailed how a systems will met the information requirements as determined by the systems analysis.
Like a blueprint of a house
Logical design
Lays out IS components and their relationships as they would appear TO USERS.
Shows what the proposed IS is supposed to DO.
Physical design
Specs out the hardware, sofware, databases, etc.

17. Programming & Testing
Programming: System specifications created in the design phase are translated into program code.
Testing: vital step, often shortchanged.
Unit testing: seeking errors in particular programs
System testing: does the whole thing work together?
Acceptance testing: evaluation by real users, review by management.

18. Conversion Putting the new IS into production Parallel strategy:
run both old & new simultaneously.
Direct cutover:
Old completely replaced by new on spec. day.
Pilot study:
Limited implementation by small group of users.
Phased approach:
Parts of new IS are introduced separately.

19. Production & Maintenance
New IS is up and running: in production.
At this point, changes in the IS are called “maintenance”.
Changes made are usually to improve efficiency.

20. Influences on & Challenges to Systems Implementation
User involvement & influence
Management support
Level of complexity & risk
Management of implementation

21. Systems Development Approaches
Traditional systems lifecycle
Prototyping
Application software packages
End-user development
Outsourcing

22. Traditional Systems Lifecycle
Variation of systems development cycle
Oldest method for building ISes, necessary for large, complex projects.
Steps:
Project definition
systems study
Design
Programming
Installation
Postimplementation

23. Systems Lifecycle: Steps 1 & 2
Project definition:
Is there a problem?
Can it be solved with a project?
System study
Analyze problems in existing systems
Define objectives
Evaluate alternatives

24. Systems Lifecycle: Steps 3 & 4
Design:
Logical & physical specifications for systems solution
Programming:
Develop software code

25. Systems Lifecycle: Steps 5 & 6
Installation:
Construct, test, train,
Convert to new system
Postinstallation:
On-going evaluation,
Modifications for improvement to meet new requirements

26. Other Approaches: Prototyping
Create an experimental system rapidly and inexpensively for end-users
Steps:
Identify the user’s basic requirements.
Develop an initial prototype.
Use the prototype.
Revise & enhance the prototype.
Iterative approach: repeat the process.
Especially good for end-user interfaces.

27. Other Approaches: Application Software Packages
Buying a premade, prepackaged application software package.
Prewritten code can often fulfill most requirements of an proposed IS.
Customization
Can be modified to meet needs better with optional add-ons.

28. Application Software Packages: Examples
Accounts receivable; Bond & stock management; Computer-aided design (CAD) ; document imaging; E- mail; Enterprise Resource Planning (ERP); Groupware; Health care; Hotel Management; Internet telephone; Inventory control; Job costing; Library systems; Life insurance; Mailing labels; Mathematical / statistical modeling; Order processing; Payroll; Process control;Tax accounting; Web browser; Word processing

29. Other Approaches: End-User Development
End-users develop information system with little help from technical specialists using 4th Generation tools.
Advantages:
Increased user satisfaction
Improved requirements determination
Reduced applications backlog for IS dept.
Disadvantages:
Relatively inefficient, rarely scalable
May hamper updating systems & requirements

30. Other Approaches: Outsourcing
Contracting
Computer center operations
Telecommunications networks
Application development to external vendors

31. Systems-Building Methodologies
Structured methodologies
Structured analysis
Structured design
Structured programming

32. Structured Methodologies
Techniques are step-by-step, each step building on the last one.
Structured analysis
Structured design
Structured programming

33. Structured Analysis
Widely used to define inputs, processes, and outputs.
Logical, graphical model of information flow
Primary tool: Data Flow Diagram (DFD)
Process specifications describe the transformation occurring within the lowest level of the data flow diagram. They express the logic for each process.

34. Symbols for Data Flow Diagrams
PROCESS
SOURCE
OR SINK
FILE

35. Data Flow Diagram (DFD)
GENERATE
BALANCE
GENERATE
BILL
CUSTOMER
FILE
PAYMENT
FILE
GENERATE
REPORT
CUSTOMER 
MANAGER

36. Structured Design
A set of design rules and techniques that promotes program clarify & simplicity.
Reduces effort of coding, debugging, etc.
Documented in a structure chart:
Top-down chart, showing each level of design & its relationship to other levels.
Payroll
Get valid inputs
Calc. pay
Write outputs
Get inputs
Validate inputs
Calc. Gross pay
Calc. Net pay
Update master
Write checks

37. Structured Programming
Extends the principles of structured design to writing of programs to make software programs easy to understand and modify.
3 constructs:
Sequence control (do this, then do that)
Selection control (do this IF that, else do other)
Iteration control (do this WHILE that is true)