Chapter 12 Implementing BusinessIT Solutions Introduction to Systems

Chapter 12 Implementing Business/IT Solutions 部份內容補充取自：Introduction to Systems Analysis & Design by Jeffrey L. Whitten and Lonnie D. Bentley. Ch 3, Ch 5 授課老師：台大 管系 楊立偉 Mc. Graw-Hill/Irwin Copyright © 2013 by The Mc. Graw-Hill Companies, Inc. All rights reserved.

Learning Objectives v Use the systems development process outlined in this chapter and the model of IS components from Chapter 1 as problem– solving frameworks to help you propose information systems solutions to simple business problems. v Describe and give examples to illustrate how you might use each of the steps of the information systems development life cycle to develop and implement a buiness information system. 12 -2

Learning Objectives v Explain how prototyping can be used as an effective technique to improve the process of systems development for end users and IS specialists. v Understand the basics of project management and its importance to a successful systems development effort. v Identify the activities involved in the implementation of new information systems. 12 -3

Learning Objectives v Compare and Contrast the four basic information system conversion strategies. v Describe several evaluation factors that should be considered in evaluating the acquisition of hardware, software, and IS services. 12 -4

Section 1 Developing Business Systems 12 -5

I. IS Development • Applying the Systems Approach to IS development • The Systems Approach is a systematic way to develop a solution to a problem 12 -6

II. The Systems Approach v Uses a systems orientation to defining and solving problems and opportunities v Problem Solving – there are specific steps in solving any problem v Recognize/Define a Problem or Opportunity – recognize it exists v Develop and Evaluate Alternative System Solutions – what are the different ways to solve this problem? v Select the Best System Solution – decide which alternative is best v Design the Selected System Solution – design the system for the chosen solution v Implement and Evaluate the Success of the Designed System – put the solution into effect and monitor results for the outcome 12 -7

II. The Systems Approach v. Systems Thinking – the “Fifth Discipline” – seeing the system context v. See the Interrelationships among the systems rather than linear cause-and-effect chains v. See the Process of change among the systems rather than discrete ‘snapshots’ of change 12 -8

II. The Systems Approach Systems Thinking 12 -9

補充 : System Thinking and CLD 12 -10

This Systems Archetype was formally identified in Appendix 2 of The Fifth Discipline by Peter Senge (1990). The Causal Loop Diagram (CLD) is shown. When a problem symptom appears, two options present themselves: 1) apply a short-term fix to the symptom, or 2) identify and apply a longer-term fix to the fundamental issue. The second option is less attractive because it involves a greater time delay and probably additional cost before the problem symptom is relieved. However, applying a short-term fix, as a result of relieving the problem symptoms sooner, reduces the desire to identify and apply a more permanent fix. Often the short-term fix also induces a secondary unintended side-effect that further undermines any efforts to apply a long-term fix. Note that the short-term fix only relieves the symptoms, it does not fix the problem. Thus, the symptoms will eventually re- 12 -11

Exploring Shifting the Burden with Credit Card Debt The CLD for this situation matches the Shifting the Burden archetype, as shown with the symptomatic solution at the top and the fundamental solution at the bottom. 12 -12

Classic examples of shifting the burden include: • Making up lost time for homework by not sleeping (and then controlling lack of sleep with stimulants) 犧牲睡覺時間寫功課 • Borrowing money to cover uncontrolled spending 借錢還債而非控制花費 • Feeling better through the use of drugs (dependency is the unintended side-effect) 依賴藥 物 • Taking pain relievers to address chronic pain rather than visiting your doctor to try to address the underlying problem 對慢性疼痛靠止痛藥而非找出病 灶 12 -13

Classic examples of shifting the burden include (2) : • Improving current sales by focusing on selling more product to existing customers rather than expanding the customer base 注重短期銷售而非擴大 客戶基礎 • Improving current sales by cannibalizing future sales through deep discounts 透過折扣提前銷售 (超 售) • Firefighting to solve business problems, e. g. , slapping a low-quality – and untested – fix onto a product and shipping it out the door to placate a customer 應急處理 • Repeatedly fixing new problems yourself rather than properly training your staff to fix the problems – this is a special form known as “shifting the burden to the intervener” where you are the intervener who is inadvertently eroding the 12 -14

Classic examples of shifting the burden include (3) : • Outsourcing core business competencies rather than building internal capacity (also shifting the burden to the intervener, in this case, to the outsource provider) 外包核心業務 • Implementing government programs that increase the recipient’s dependency on the government, e. g. , welfare programs that do not attempt to simultaneously address low unemployment or low wages (also shifting the burden to the intervener, in this case, to the government) 接受政府貼補 12 -15

III. Systems Analysis and Design v. The process of designing and implementing an IS – Object-oriented or Life Cycle approaches v. The Systems Development Life Cycle – a multistep, iterative process to designing systems, very popular, 5 Phases: Investigation, Analysis, Design, Implementation, Maintenance 12 -16

IV. Starting the Systems Development Process The Systems Development Life Cycle 12 -17

IV. Starting the Systems Development Process v Systems development can be very costly, investigations are made to determine whether to proceed v Feasibility Studies – identify needs, resources, costs, benefits v Operational Feasibility – will the proposed system fit existing business environment and objectives? v Technical Feasibility – degree to which current technical resources can be applied to the new system v Human Factors Feasibility – assess the degree of approval/resistance to the new system 12 -18

IV. Starting the Systems Development Process v Economic Feasibility – the extent to which the proposed system will provide positive economic benefits to the organization v Cost/Benefit Analysis – do the benefits justify the costs? v Tangible Costs/Benefits – can be calculated/quantified (hardware, software, increase in payroll) v Intangible Benefits – hard to calculate (customer approval, political feedback) v Legal/Political Feasibility – what are the legal/political ramifications of the new system? 12 -19

IV. Starting the Systems Development Process Feasibility Factors 12 -20

12 -21

12 -22

V. Systems Analysis • A detailed study of the current system and organizational needs • Organizational Analysis – you must have a thorough understanding of the organization to make the system work well • Analysis of the Present System – “those who fail to study history are doomed to repeat it”, a complete understanding of the current system is critical • Logical Analysis – create logical models the current system, WHAT the system does without regard to HOW • Functional Requirements Analysis and Determination – what Information is required for each business activity and what Processing is required in the system 12 -23

12 -24

Prometric: Understanding Application Performance v What is Prometric’s product? v What product makes all this possible? v How do problems in this product affect their entire operation? v What does APM do? v What were the results of using APM? 12 -25

補充：如何發現需求 Requirements discovery – the process and techniques used by systems analysts to identify or extract system problems and solution requirements from the user community. 由兩部份組成 – Functional requirement 功能性需求 – Non-functional requirement 非功能性需求 5 -26

Functional vs. Nonfunctional Requirements Functional requirement - something the information system must do 註 logical design → what to do 　 physical design → how to do Nonfunctional requirement - a property or quality the system must have – Performance – Security – Costs 5 -27

Process of Requirements Discovery 發現需求的程序 1 Problem discovery and analysis 先發現並分析問題 2 Requirements discovery 發現需求 3 Documenting and analyzing requirements 紀錄並分析需求 4 Requirements management 做好需求管理 (增修刪/版本控管等) 5 -33

1. 問題分析 - Ishikawa Diagram (a. k. a Fishbone Diagram 魚骨圖) • Graphical tool used to identify, explore, and depict problems and the causes and effects of those problems. It is often referred to as a cause-and-effect diagram or a fishbone diagram. 也稱石川圖、原因與效果圖 – Problem at right (fish head) – Possible causes drawn as "bones" off main backbone – Brainstorm for 3 -6 main categories of possible causes 5 -34

2. Requirements Discovery • Given an understand of problems, the systems analyst can start to define requirements. Fact-finding – the formal process of using research, meetings, interviews, questionnaires, sampling, and other techniques to collect information about system problems, requirements, and preferences. It is also called information gathering or data collection. 後面會介紹七種需求收集的技巧 5 -38

3. Documenting and Analyzing Requirements • Documenting the draft requirements – Use cases, Decision tables, Requirements tables 等 • Analyzing requirements to resolve problems – – – Missing requirements Conflicting requirements Infeasible requirements Overlapping requirements Ambiguous requirements 是否有遺漏的 是否有相衝突的 是否有不可行的 是否有重疊的 是否有模稜兩可的 • Formalizing requirements – Requirements definition document – Communicated to stakeholders or steering body 5 -39

Requirements Definition Document – A formal document that communicates the requirements of a proposed system to key stakeholders and serves as a contract for the systems project. 需求定義書 • Synonyms 5 -40 – – Requirements definition report Requirements statement Requirements specification 通常又稱為需求規格書 Functional specifications 或是功能規格書

Sample Requirements Definition Report Outline 5 -41

4. Requirements Management Requirements management - the process of managing change to the requirements. 管理需求的變更 (增修刪/版本控管等) – Over the lifetime of the project it is very common for new requirements to emerge and existing requirements to change. – Studies have shown that over the life of a project as much as 50 percent or more of the requirements will change before the system is put into production. 研究顯示, 專案內有超過一半的需求有可能變動 5 -42

Seven Fact-Finding Techniques 七種需求收集的技巧 1. Sampling of existing documentation, forms, and databases. 2. Research and site visits. 3. Observation of the work environment. 4. Questionnaires. 5. Interviews. 6. Prototyping. 7. Joint requirements planning (JRP). 5 -43

VI. Systems Design • Create a new system to solve the problem/opportunity • Prototyping – create working models of the proposed system • The Prototyping Process – prototypes are developed quickly for trial by users to obtain user feedback • User Interface Design – critical because the interface is the part of the systems closest to the user • System Specifications – listing of elements that formalize the design 12 -44

12 -45

VI. Systems Design The Prototyping Process 12 -46

The Determinants of Project Success v According to the case, what is the most important factor for business project success? v Which projects have fewest problems? v Why would a manager not know if his project is strategic? v What was the biggest challenge given by project managers? 12 -47

Google’s Interface: Balancing Freedom and Consistency v What are Google’s design decisions based on? v What problem is inherent in Google’s culture? v Why is this a problem for users? v What issues does this cause in consistency vs. pragmatism? 12 -48

12 -49

12 -50

補充 : Modeling the Requirement v常用方法 v流程圖 Flow chart (or called Flow diagram) v實體關係圖+資料流程圖 v. Entity-Relationship model (ER model) v. Data flow diagram (DFD) v. Unified model language (UML) v. Use-case diagram使用案例，類似情境之表示 v. Class diagram類別圖，類似個體關係之表達 v. Activity diagram活動圖，類似流程圖之表達 v. Sequence diagram循序圖，活動上加入時序概念 12 -51

Flow chart : Example 參考連結 12 -52

Flow chart : Example 參考連結 12 -53

Flow chart Example 12 -54

Flow chart Example 12 -55

VII. End-User Development v. IS professionals act as consultants while user do their own application development v. Focus on IS Activities – focus should be on fundamental activities: input, processing, output, storage, control v. Doing End-User Development – may discover new or improved ways to do the job 12 -56

VII. End-User Development 12 -57

Blue Prism: “Shadow” IT Is Becoming More Pervasive v What is “shadow” IT? v What situations can lead to this behavior, and why do users do it? v What did the Blue Prism survey reveal? v What is IT’s solution to a problem? Why is this not always the correct solution? What should be their focus? 12 -58

VII. Technical Note: Overview of Object. Oriented Analysis and Design v Objects – anything a programmer wants to manage or manipulate v Object-Oriented Programming (OOP) v Inheritance – ability to inherit properties of a higherorder object v Modularity – a series of interlinked yet stand-alone modules v Polymorphism – different behavior based on conditions v Encapsulation – concealing all the properties inside the object v Object-Oriented Analysis (OOA) – modeling the problem domain as an object-oriented system v Object-Oriented Design (OOD) – create solutions using objects 12 -59

Section 2 Implementing Strategic Business Systems 12 -60

I. The World of Systems Implementation v Implementation is a vital step that must be completed; it is important to PLAN an implementation. 12 -61

II. Implementing New Systems v May be difficult and time-consuming The Implementation Process 12 -62

Project Portfolio Management: Shoot the Bad Projects, Keep the Good Ones v. What is the reward for doing a good job? Why is this true? v. What skills need to be learned by IT to close the credibility gap in PPM? v. What role does internal politics have? v. Why does IT look bad when another department creates a bad project? 12 -63

III. Project Management v What Is a Project? – a set of activities with a beginning and an end, has goals and tasks, may have constraints (limitations) v The Process of Project Management – five phases: v Initiation and Defining – state the problem and identify objectives and resources, explore costs/benefits v Planning – identify and sequence objectives/activities v Executing – put plans into motion v Controlling – ensure project objectives and deadlines are met v Closing – install deliverables, release resources, end the project 12 -64

12 -65

III. Project Management Phases of Project Management 12 -66

Project Management Functions 補充：專案管理的八大功能 3 -67 • Scoping – setting the boundaries of the project • Planning – identifying the tasks required to complete the project • Estimating – identifying resources required to complete the project • Scheduling – developing a plan to complete the project • Organizing – making sure members understand their roles and responsibilities • Directing – coordinating the project • Controlling – monitoring progress • Closing – assessing success and failure

Project Management Activities 對應的八項主要活動 1. 2. 3. 4. 5. 6. 7. 3 -68 Negotiate Scope Identify Tasks Estimate Task Durations Specify Intertask Dependencies Assign Resources Direct the Team Effort Monitor and Control Progress

Project Management Tools & Techniques PERT chart – a graphical network model used to depict a project’s tasks and their interdependencies. Gantt chart – a bar chart used to depict project tasks and their time requirements. 3 -69

PERT Chart 3 -70

Gantt Chart 3 -71

Microsoft Project Gantt Chart 3 -72

Activity 1 – Negotiate Scope – the boundaries of a project – the areas of a business that a project may (or may not) address. Includes answers to five basic questions: 作範圍, 要回答這五個問題 – – – 3 -73 Product Quality Time Cost Resources Statement of work (SOW) – a narrative describing the work to be performed as part of a project. Common synonyms include scope statement, project definition, project overview, and document of understanding.

Statement of Work (SOW 作說明書的大綱範例) I. II. IV. 3 -74 Purpose Background A. Problem, opportunity, or directive statement B. History leading to project request C. Project goal and objectives Notice the use of D. Product description information system Scope building blocks A. Stakeholders B. Data C. Processes D. Locations Project Approach A. Route B. Deliverables Managerial Approach A. Team building considerations B. Manager and experience C. Training requirements (continued)

Statement of Work (SOW 作說明書的大綱範例) 續 V. 3 -75 Managerial Approach (continued) D. Meeting schedules E. Reporting methods and frequency F. Conflict management G. Scope management VI. Constraints A. Start date B. Deadlines C. Budget D. Technology VII. Ballpark Estimates A. Schedule B. Budget VIII. Conditions of Satisfaction A. Success criteria B. Assumptions C. Risks IX. Appendices

Activity 2 – Identify Tasks Work breakdown structure (WBS) 作展開 結構 – a graphical diagram used to depict the hierarchical decomposition of the project into phases, activities, and tasks. Milestone 里程碑 – an event signifying the completion of a major project task or deliverable. (實務上跟收款有關) 3 -76

Activity 3 – Estimate Task Durations • Elapsed time takes into consideration: – Efficiency - no worker performs at 100% efficiency 考量實際產出效率 • Coffee breaks, lunch, e-mail, etc. • Estimates of 75% efficiency are common – Interruptions 可能被中斷的情況 • Phone calls, visitors, etc. • 10 -50% 3 -77

Activity 3 – Estimate Task Durations (continued) 1. Estimate the minimum amount of time it would take to perform the task – the optimistic duration (OD). 2. Estimate the maximum amount of time it would take to perform the task – the pessimistic duration (PD). 3. Estimate the expected duration (ED) that will be needed to perform the task. 4. Calculate a weighted average of the most likely duration (D) as follows: D = (1 x OD) + (4 x ED) + (1 x PD) 6 OD 3 -78 ED 3. 33 days = (1 x 2 days) + (4 x 3 days) + (1 x 6 days) 6 PD

Activity 4 – Specify Intertask Dependencies 兩個 作間的四種關係 • Finish-to-start (FS)—The finish of one task triggers the start of another task. 例: 裝完管線 才能鋪地板 • Start-to-start (SS)—The start of one task triggers the start of another task. 例: 開始拆舊 裝璜就要同時開始清運垃圾 • Finish-to-finish (FF)—Two tasks must finish at the same time. 例: 電話線與網路線都拉好才能 組辦公傢俱 • Start-to-finish (SF)—The start of one task signifies the finish of another task. 例: 開始搬入 家具表示油漆 程完成了 3 -79

Entering Intertask Dependencies 輸入 作相依性 3 -80

Scheduling Strategies 兩種排程的策略 Forward scheduling – a project scheduling approach that establishes a project start date and then schedules tasks forward from the start date. 從開始日開始, 由前往後排 Reverse scheduling – a project scheduling strategy that establishes a project deadline and then schedules tasks backward from the finish date. 從結束日開始, 由後往前排 3 -81

Activity 5 – Assign Resources 分派五大資源 • People – includes all system owners, users, analysts, designers, builders, external agents, and clerical help involved in the project in any way. • Services – includes services such as a quality review that may be charged on a per use basis. • Facilities and equipment – includes all rooms and technology that will be needed to complete the project. • Supplies and materials – everything from pencils, paper, notebooks to toner cartridges, and so on. 3 -82 • Money – includes a translation of all of the above into budgeted dollars!

Defining Project Resources 3 -83

Assigning Project Resources 3 -84

Assigning People to Tasks 將人與 作任務連起來 • Recruit talented, highly motivated people 任用有才能, 有成就動機的人 • Select the appropriate person for each task 針對每個 作, 選擇最合適的人 • Promote team harmony 保持團隊和諧 • Plan for the future 預估到未來的需求 • Keep the team size small 不要一次加太 多人 3 -85

Resource Leveling 資源撫平 Resource leveling – a strategy for correcting resource over-allocations. 例: 當同一個人同時被分派到兩項 作時 Two techniques for resource leveling: • task delaying 作遞延 • task splitting 作分割 3 -86

Task Splitting and Task Delaying 何時該選用 作分割或 作遞延 ? • Critical path 要徑 – the sequence of dependent tasks that determines the earliest possible completion date of the project. – Tasks on the critical path cannot be delayed without delaying the entire project completion time. Critical tasks can only be split. 此時只能用分割的方法 • Slack time 寬鬆時間 – the amount of time that a task can be delayed without causing a delay in the completion date of the entire project. 3 -87 – Tasks that have slack time can be delayed to achieve resource leveling 此時可以用遞延的方法

Activity 6 – Direct the Team Effort • Supervision resources 隨時監督資源的使用狀況 – The Deadline: A Novel about Project Management – The People Side of Systems – The One Minute Manager 形成 衝進 一分鐘經理人: 立標, 讚賞, 申誡 – The One Minute Manager Meets the Monkey • Stages of Team Maturity 規範 (see figure to the right) 團隊成熟度的不同階段 3 -88 執行

10 Hints for Project Leadership 專案領導的十個要訣 1. 2. 3. Be Consistent. 要一致 Provide Support. 要提供支援 Don’t Make Promises You Can’t Keep. 不要承諾做不到 的事 4. Praise in Public; Criticize in Private. 公開表揚, 私下申誡 5. Be Aware of Morale Danger Points. 注意會讓士氣受損 的事 6. Set Realistic Deadlines. 設定符合實際的期限 7. Set Perceivable Targets. 設定可看到的目標 8. Explain and Show, Rather Than Do. 多解釋與示範, 而 不是直接做 9. Don’t Rely on Just Status Reports. 不可只依賴進度報告 10. Encourage a Good Team Spirit. 鼓吹好的團隊精神 3 -89

Activity 7 – Monitor and Control Progress • • 3 -90 Progress reporting 進度報告 Change management 變動管理 Expectations management 預期管理 Schedule adjustments—critical path analysis (CPA) 更改時程與要徑分析

Change Management 變動管理 Change management – a formal strategy in which a process is established to facilitate changes that occur during a project. 3 -91 Changes can be the result of various events and factors including: 為什麼會造成變動的幾大原因： • An omission in defining initial scope 作定義時有疏漏 • A misunderstanding of the initial scope 誤解 作範圍 • An external event such as government regulations that create new requirements 外部事件造成新需求(如政府法令要求) • Organizational changes 組織變動 • Availability of better technology 有更好的技術可用 • Shifts in planned technology that force changes to the business organization, culture, and/or processes 技術造成的改變 • Management’s desire to have the system do more 管理階層 • Reduced funding for project or imposition of an earlier deadline. 經費減少或時程提前

Activity 8 – Assess Project Results and Experiences • Did the final product meet or exceed user expectations? – Why or why not? • Did the project come in on schedule? – Why or why not? • Did the project come in under budget? – Why or why not? 3 -92

SAS: Services Key in Mainframe Migration Project v. What is the problem with the current “homegrown” SAS system? v. What solutions does the new system provide? v. What are the expected dollar savings fro, this implementation? 12 -93

IV. Evaluating Hardware, Software, and Services v Performance must be demonstrated and evaluated v Hardware Evaluation Factors – physical and performance characteristics v Software Evaluation Factors – similar to evaluating hardware v Evaluating IS Services – services may be provided by suppliers of hardware/software or by third parties; do the services address your needs? 12 -94

IV. Evaluating Hardware, Software, and Services 12 -95

IV. Evaluating Hardware, Software, and Services 12 -96

IV. Evaluating Hardware, Software, and Services 12 -97

V. Other Implementation Activities v Testing – testing and debugging are important, does the system work as it should? v Data Conversion – new implementations often require replacing software and databases v Documentation – an important means of communication, often overlooked v Training – training users is vital, usually underbudgeted, and expensive 12 -98

12 -99

Owens and Minor: The Mainframe Goes, but COBOL Stays v. What is the issue with the ERP system? v. Why do they not want to rewrite the system? v. What are the benefits of continuing to use the COBOL system? 12 -100

V. Other Implementation Activities v System Conversion Strategies – cutting over to the new system v Direct – simplest but most dangerous method, turn off the old system and turn on the new one v Parallel – most expensive but safest, run both systems until everyone is satisfied, then turn off old system v Pilot – let only a select few users use the new system until they are happy, then implement the new system for everyone; best user representation can be selected for the trials v Phased (Modular) – gradual conversion one module at a time, combines best of both direct and modular while minimizing risks 12 -101

V. Other Implementation Activities System Conversion Strategies 12 -102

V. Other Implementation Activities v Postimplementation Activities – Use and Maintenance – the longest and most costly phase of a system’s life; correct errors, improve performance, adapt to changes in the business environment v Systems Maintenance – making changes to the system v Corrective – fix errors v Adaptive – adding new functionality v Perfective – improve performance v Preventative – reduce chances of future system failure v Postimplementation Review – ensure the new system meets established business objectives 12 -103

12 -104

Project Success (or Failure): What We Know but Choose to Ignore v. What percentage of major it projects are failures (or cancelled)? v. Describe the various reasons for failure. v. Discuss these reasons – why would we choose to ignore these items? v. How can we work to avoid each of the reasons on the list? 12 -105