1. 1 Management Information Systems Information Systems in Global Business Today Lecture 3

2. 2 “There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of the new order of things.” -- Niccolò Machiavelli  Technical and non-technical expertise  May not involve technology at all! Systems Analysis

3. 3 Systems Analysis and Design (SAD)  Structured process employed to develop IT/IS projects  Identification of business problems  Identification/creation of potential solutions  Selection, design and implementation of final solution  Problem solving … technology?  How do we allow our customers to order products any time of the day or night with minimal cost increases?  How can we enable the location of physical assets as well as communication that will allow re-location?  How do we determine the optimal production mix taking into account the limitations on the production floor?

4. 4 Analysis … Design  SAD contains at least two distinct processes  Analysis : determine the nature and the domain of the business problem  What is the problem?  What is the best solution to solve it?  Design : design, construction and implementation of solution  How do we transform the solution to a usable IS?  A good Analysis is often followed by no Design  A good Design is rarely preceded by no Analysis

5. 5 Process vs. Data Centricity Data-Centric ApproachProcess-Centric Approach What data does the system need? What is the system supposed to do? Tends to have an enduring design stability due to low volatility in organizational data needs. Design stability is necessarily limited due to constant changes in business processes. The file structure is enterprise dependent. The file structure is application dependent. Data redundancy is generally limited and controlled. Data redundancy is generally massive and uncontrolled.

6. 6 Players in the Development Game  Clients and/or End Users : who benefits  IS Management : set criteria and oversee development  Systems Analysts : facilitate and communicate  Application Programmers : CASE tools?  IS Support Personnel  Vendors  Database Administrators  Telecom  Audit & Security: SOX!  IT Steering Committee

7. 7  The system analyst bridges the communications gap between those who need the computer and those who understand the technology.  SA understands business and technology  transform business and information requirements of the organization into computer-based information systems  The Goal :  improved business processes  improved information systems  new or improved computer applications  all three The Role of a Systems Analyst

8. 8 SA Skill Set  Technical Skills  Integration and Communication  Analytical Skills  System Thinking, Value Focused Thinking  Managerial Skills  Business Domain, Project Management, Change Management  Expectations Management!  Interpersonal Skills  Team player, communicator

9. 9  What is an Information System?  An information system is an arrangement of people, data, processes, interfaces, networks, and technology that interact for the purpose of supporting and improving both day-to-day operations in a business - data processing -, as well as supporting the problem solving and decision making needs of management - information services.  What is a Computer Application System?  A computer application is computer-based solution to one or more business problems and needs. IS

10. 10 Types of IS TPS MIS DSS/ES EIS Office Automation (OA) Workgroup Management Systems (WMS) Web-based

11. 11 IS Support Decision Making TPS OAS MIS KWS DSS ESS Organizational Level TYPE OF DECISIONOPERATIONALKNOWLEDGEMANAGEMENTSTRATEGIC STRUCTURED ACCOUNTS RECEIVABLE ELECTRONIC PRODUCTION SCHEDULING COST OVERRUNS SEMI-BUDGET STRUCTUREDPREPARATION PROJECT SCHEDULING FACILITY LOCATION UNSTRUCTUREDPRODUCT DESIGN NEW PRODUCTS NEW MARKETS

12. 12 Systems Development Life Cycle Conceptual Design Analysis Physical Design Implementation & Conversion Operation & Maintenance System requirement Blueprint for detailed design Full design Operational system Preliminary Investigation The problem

13. 13 Systems Development Life Cycle Conceptual Design Analysis Physical Design Implementation & Conversion Operation & Maintenance System requirement Blueprint for detailed design Full design Operational system Change in Scope/Requirement Bad blueprint Implementation incomplete Unfixable errors Preliminary Investigation The problem Wrong problem

14. 14  The SDLC usually incorporates the following general- purpose problem solving steps:  Planning - identify the scope and boundary of the problem, and plan the development strategy and goals.  Analysis - study and analyze the problems, causes, and effects. Then, identify and analyze the requirements that must be fulfilled by any successful solution.  Design - if necessary, design the solution  Implementation - implement the solution.  Support - analyze the implemented solution, refine the design, and implement improvements to the solution. Different support situations can thread back into the previous steps. The Systems Development Life Cycle

15. 15 Planning Analysis Design Support Problem to be solved Problem analysis and Solution requirements Acceptable solution Obsolete solution Implemen- tation Implemented solution Related problem to be solved New solution to same problem Implementation error to be fixed CYCLE!

16. 16 Alternatives to SDLC  OOAD : Objective Oriented Analysis and Design  Combine Data and Processes into an Object  Focus on reuse  RAD : Rapid Application Development  More parallel approach to development

17. 17  A business analyst is a systems analyst that specializes in business problem analysis and technology-independent requirements analysis.  An application analyst is a systems analyst that specializes in application design and technology-dependent aspects of development.  system or application architect.. The Roles of a Systems Analyst

18. 18  TQM  A comprehensive approach to facilitating quality improvements and management within a business.  Identify quality indicators, measure quality, and make appropriate changes to improve quality  Nature of systems analysis encourages analysts to look for business quality problems.  Incomplete and inconsistent specifications from analysts are a significant contributor to poor software quality Trends: Total Quality Management

19. 19  BPR  the study, analysis, and redesign of fundamental business processes to reduce costs and improve value added to the business  BPR project begins with identification of a value chain, a combination of processes that should result in some value to the business. The business processes are documented and analyzed in excruciating detail and streamlined for maximum efficiency.  BPR & SA The skill competencies for BPR and systems analysis and design are somewhat similar. Typical BPR project identifies several opportunities for new and revised computer applications (which systems analysts facilitate). Trends: Business Process Redesign

20. 20  CPI  the continuous monitoring of business processes to affect small but measurable improvements to cost reduction and value added BPR is intended to implement dramatic change. CPI implements a continuous series of smaller changes.  Continuous improvement contributes to both cost reductions, improved efficiencies, and increased value and profit.  Systems analysts may be called upon to participate in continuous process improvement initiatives for any business process, including the design and implementation of improvements to associated computer applications. Trends: Continuous Process Improvement

21. 21  Most businesses have been forced to reorganize to compete globally  IS must support multiple languages, currency exchange rates, international trade regulations, accepted business practices  Coordination of information  International Outsourcing -- detailed requirements needed! Trends: Globalization

22. 22  Problems vs. Symptoms  A problem is a difference between what we have and what we want.  A symptom is an outward manifestation of a problem  Variance, good or bad, from the norm  Many symptoms may be the result of the same problem  Houston, we have a symptom  A symptom is evidence of the problem but not necessarily the problem itself.  Problem definition requires a viewpoint! So What is the Problem?

23. 23 Problem Recognition and Definition  Recognize a variance – symptom(s)  Investigate – interview users, observe use, test the system  Propose a solution – experiment with the system  Ishikawa (fishbone) diagrams can help separate cause and effect  1: come up with symptom categories (people, materials, skills…)  2: relate observed symptoms to categories  3: look for secondary symptoms  Iterative Team Process  Why is this *insert symptom here* happening?

24. 24 Ishikawa Diagram Root Problem MethodsPeople Symptom Category Possible Symptom Categories 4Ps: People, Place, Procedure, Policy 4Ms: Manpower, Machines, Methods, Materials 4Ss: Surroundings, Suppliers, Systems, Skills Possible Symptom Categories 4Ps: People, Place, Procedure, Policy 4Ms: Manpower, Machines, Methods, Materials 4Ss: Surroundings, Suppliers, Systems, Skills Observed Symptom Or Variance Secondary Symptom High distribution costs High customer walkouts Low allocation of staff

25. 25 P - the need to improve performance. I - the need to improve information (and data). E - the need to improve economics control costs, or increase profits. C - the need to improve control or security. E - the need to improve efficiency of people and processes S - the need to improve service to customers, suppliers, partners, employees, etc. PIECES Framework

26. 26 PIECES The following checklist for problem, opportunity, and directive identification uses Wetherbe's PIECES framework. Note that the categories of PIECES are not mutually exclusive; some possible problems show up in multiple lists. Also, the list of possible problems is not exhaustive. The PIECES framework is equally suited to analyzing both manual and computerized systems and applications. PERFORMANCE Problems, Opportunities, and Directives A. Throughput – the amount of work performed over some period of time. B. Response time – the average delay between a transaction or request and a response to that transaction or request INFORMATION (and Data) Problems, Opportunities, and Directives A. Outputs 1. Lack of any information 2.Lack of necessary information 3.Lack of relevant information 4.Too much information – ``information overload'' 5.Information that is not in a useful format 6.Information that is not accurate 7.Information that is difficult to produce 8.Information is not timely to its subsequent use

27. 27 PIECES INFORMATION (and Data) Problems, Opportunities, and Directives B. Inputs 1. Data is not captured 2.Data is not captured in time to be useful 3.Data is not accurately captured -- contains errors 4.Data is difficult to capture 5.Data is captured redundantly -- same data captured more than once 6.Too much data is captured 7.Illegal data is captured C. Stored Data 1. Data is stored redundantly in multiple files and/or databases 2.Stored data is not accurate (may be related to #1) 3.Data is not secure to accident or vandalism 4.Data is not well organized 5.Data is not flexible – not easy to meet new information needs from stored data 6.Data is not accessible

28. 28 PIECES ECONOMICS Problems, Opportunities, and Directives A. Costs 1. Costs are unknown 2.Costs are untraceable to source 3.Costs are too high B. Profits 1. New markets can be explored 2.Current marketing can be improved 3.Orders can be increased CONTROL (and Security) Problems, Opportunities, and Directives A. Too little security or control 1. Input data is not adequately edited 2.Crimes are (or can be) committed against data a.Fraud b.Embezzlement 3.Ethics are breached on data or information – refers to data or information letting to unauthorized people 4.Redundantly stored data is inconsistent in different files or databases

29. 29 PIECES CONTROL (and Security) Problems, Opportunities, and Directives A. Too little security or control (continued) 5.Data privacy regulations or guidelines are being (or can be) violated 6.Processing errors are occurring (either by people, machines, or software) 7.Decision-making errors are occurring B. Too much security or control 1. Bureaucratic red tape slows the system 2.Controls inconvenience customers or employees 3.Excessive controls cause processing delays EFFICIENCY Problems, Opportunities, and Directives A. People, machines, or computers waste time 1. Data is redundantly input or copied 2.Data is redundantly processed 3.Information is redundantly generated B. People, machines, or computers waste materials and supplies C. Effort required for tasks is excessive D. Materials required for tasks is excessive

30. 30 PIECES SERVICE Problems, Opportunities, and Directives A. The system produces inaccurate results B. The system produces inconsistent results C. The system produces unreliable results D. The system is not easy to learn E. The system is not easy to use F. The system is awkward to use G. The system is inflexible to new or exceptional situations H. The system is inflexible to change I. The system is incompatible with other systems J. The system is not coordinated with other systems

31. 31 Typical Pieces Analysis SymptomPIECES Management reports are often not received on time. X Production line throughput is below expected standards.X Product rework is high. X X Inventory control reports are inaccurate. X Exceptions occur frequently and must be processed by hand. X Production time is higher than industry average.X Orders are often cancelled due to excessive delivery wait time. X Required information to process an order not available on demand. X Organizational data redundancy is high. X Production lines are often down for repair or maintenance.X Line personnel are often not aware of their production quota. X Data transferred from production system to sales system by hand. XX Several incidents of system sabotage have been recorded. X Totals451122 Likely Problem Areas Symptom in one (max 2) categories

32. 32 Problem Statement  First, we observe, identify and record symptoms  All we have is an informed guess but we have to start somewhere  Can’t edit or refine something that doesn’t exist  The written problem statement should list the symptoms, suggest their likely cause of causes, and begin an estimate of the resources to develop an effective solution.  a.k.a. Statement of Scope and Objectives  Establish what the system will and will not due  This can (will) change but define boundaries early!

33. 33 Bounded Rationality  Problem solvers are willing to settle for a satisfactory solution to a given problem, and avoid the extreme effort necessary to find the optimal solution  cognitive limitations of human beings  But, maybe we do make rational decisions that are just bounded by uncontrollable constraints?  Satisfying  It’s natural to think about what we want and look for it.  SAD methodologies are designed to avoid this “anchoring” bias

34. 34 Systems  A system is a set of interrelated elements, with an identifiable boundary, that function together to achieve a common goal  Interrelated Elements  subsystems works together to achieve the goals system.  Synergy?  Boundaries  A system is definable within the context of all other systems by virtue of it having a boundary.  Elements that are not contained within the boundary of a system are said to be a part of the environment of the system (uncontrollable) rather than a part of the system itself (controllable).  Common Goal  The goal or purpose of a system is its reason for being.

35. 35 Divide and Conquer  Functional decomposition  the process of breaking a system down into its component elements  allows the study of a single part of a system and consideration of refinement or modification independently from the larger system  Modularity  When do you stop decomposing?  When you’ve learned what you need to know.

36. 36 Decomposition : Systems Development Life Cycle Logical Design Analysis Physical Design Implementation & Conversion Operation & Maintenance Preliminary Investigation  Creeping Commitment 

37. 37 Preliminary Investigation  Key Activities  Problem definition  Estimate problem scope  Estimate project feasibility  Estimate resource commitment  Go/no go decision  Primary Deliverables  Preliminary feasibility report  General problem statement

38. 38 Analysis  Key Activities  Create logical models of current system  Refine problem statement via detailed symptom analysis  Determine requirements for new system  What is?  Implementation Independent!  Primary Deliverables  DFD of current system  ERD of current system  Formal problem statement  Formal requirements definition  Include new features and prioritization of features  Expectations management!

39. 39 Logical Design  Key Activities  Revise current system logical models to reflect proposed system changes  Validate logical model of proposed system against requirements determination  “What should be?” not “How?”  Primary Deliverables  DFD of proposed system  ERD of proposed system  Final performance specifications

40. 40 Physical Design  Key Activities  Determine hardware specifications  Determine software specifications  Conduct feasibility analysis and cost justification for new system  Estimate implementation schedule  Design data structures  Prepare training guidelines  Prepare preliminary testing procedures  Primary Deliverables  Detailed hardware specifications  Detailed software specifications  Final feasibility report  Physical data structures and data dictionary  Implementation schedule

41. 41 Implementation  Key Activities  Acquire hardware and software  Determine location requirements  Install the new system  Parallel? Cutover? Steps?  Create test data and conduct initial system tests  Train all end users  Verify all end user and system documentation  Primary Deliverables  Final performance test metrics  Fully trained end user community  Publish docs  Fully installed system  Fully converted data files

42. 42 Maintenance  Key Activities  Conduct post- implementation review  Perform requested and necessary changes to new system  Monitor performance against established guidelines  Primary Deliverables  Continually functioning system

43. 43 Underlying Principles of Systems Development  Get the owners and users involved  Use a problem-solving approach  Establish phases and activities  Establish standards for consistent development and documentation  Justify systems as capital investments  Don’t be afraid to cancel  Divide and conquer  Design systems for growth and change

44. 44 End of Lecture 3 Questions?