ICS321 Management Information Systems

1. Dr. Ken Cosh ICS321 Management Information Systems

2. Business Applications • Ebusiness Systems • Cross Functional Ebusiness Systems • CRM • SCM • KMS • DSS • Business Intelligence Review

3. “Building Information Systems” • Redesigning an organisation with IS • Systems as planned organisational change • The Systems Development Lifecycle • Business’ impact on Systems Development • Requirements Engineering • Implementing valuable systems • Managing Change • Outsourcing Solutions Next Module

4. Major Risks and uncertainties in systems development. • Already mentioned some of the enterprise wide project failures • Systems requirements are complex and volatile • Time and costs are difficult to predict • Managing Organisational change • Deciding where the best impact could be had • Which system project to choose • How far to go with the system changes Building Information SystemsThe Challenges

5. 4 structured organisational change levels available; • Automation • Replacing repetitive tasks by faster, more reliable systems • Rationalisation of procedures • Streamlining of standard operating procedures, removing bottlenecks for example. • Business Process Re-engineering (BPR) • Radical redesign of business processes, redesigning the way the business performs procedures, combining steps for example. • Paradigm Shift • Radical reconceptualisation of the nature of the business and the nature of the organisation. Organisational Change through Systems Development

6. The Spectrum of Organisational Change High Paradigm Shifts Reengineering RISK Rationalisation Automation Low Low High REWARD

7. An engineering discipline that investigates the cost effective development of systems. Concerned with all practical aspects of system production from system specification to system maintenance, including design, development and implementation. Systems Engineering

8. S.E. Lifecycle

9. S.E. Lifecycle II

10. Requirements Engineering “Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when your client starts using your product, is so expensive and so inefficient... …A requirement is something that the product must do or a quality that the product must have.” [Robertson & Robertson 1999]

11. The Importance of R.E. • The later in the development cycle an error is detected the more expensive it is to repair. Davies 1993

12. Requirements Elicitation • Sources: • Goals • Domain Knowledge • System Stakeholders • Operational Environment • Organisational Environment • Techniques: • Interviews • Scenarios • Prototypes • Facilitated Meetings • Observation

13. Communication Issues • Management lack appreciation of IS concepts (people oriented) • IS lack appreciation of Business functions (technology oriented) • User disagreements / conflicts • Result - elicit requirements from many stakeholders (viewpoints) using many different techniques. Elicitation Difficulties

14. Interviewing difficulties • Firstly, one individual person is unlikely to know everything about what a system should do. • Secondly, the individual may not be able to articulate all the requirements coherently. • Finally, the individual may not actually know what they do Eliciting Requirements

15. Brainstorming Project Scoping Conflict discussion However, arguments and people not really understanding what they do. Facilitated Meetings

16. Ethnography • Watching users in action to understand what they do. • But problem of creating meaningful reports. Business processes often too subtle & complex to describe easily. Observation

17. Discussion of what should occur in different situations and under different conditions. Conceptual modeling But, can you cover all eventualities? Scenarios

18. Present basic overview of potential solution • Paper Mockup • Beta test version • Potential to get carried away with how it looks. • Design Orientated. Prototypes

19. Combination of Techniques Interviewing Facilitated Meetings Analysis of available systems A Good Requirements Specification Prototypes Scenarios Observation Analysis of existing systems

20. Detecting & Resolving Conflicts between Requirements Discovering the bounds of a system and how it interacts in it’s environment Elaborate System Requirements to Software Requirements Requirements Analysis

21. Classification • Functional vs Non-functional • Priority • Scope • Stability / Volatility • Conceptual Modeling • Negotiation Requirements Analysis

22. Technical Analysis • Is it possible? • Economic Analysis • Costs vs Benefits • Is it worth doing? Feasibility Analysis

23. Economic Evaluation • What’s it going to cost me? • Acquisition / Development Costs • Hardware, Software, Project Team salaries, Consultant fees. • Implementation Costs • Conversion, Training, Staff salaries, Design & Printing costs • Operating Costs • Ongoing Staff salaries, Training, Outside services, Forms, Maintenance, Upgrades/

24. Apparent / Hidden Costs Computer Costs Overheads Software Personnel Improper use of management time Conversion Costs Security / Privacy Documentation Costs Training & Recruitment Operations Overload Communication Problems Labour Division

25. Benefits • Direct Savings • Staff reductions, Space, • Cost Avoidance • Current system inflation (maintenance etc.), Additional Staff, • Intangible Benefits • Productivity Improvement, Better Information & Decisions, Accuracy, More Timeliness, Reliability, Flexibility