Transcript 오브통합.
CHAPTER 14 Learning Objectives 1조 성빈이와 연 장자들 Managing Projects 1. 프로젝트 관리의 목표는 무엇이며, 왜 이것이 정보시스템 개발에 있어서 필수적인가? 프로젝트 관리의 중요성 1. 2. 3. 4. 정보 시스템 프로젝트는 실패율이 매우 높다. 정보 시스템 프로젝트 완성 까지 많은 시간과 비용이 든다. 새로운 시스템의 개발은 조심스럽게 개발되고 조율되어야 한다. 정보시스템 이용 방법과 성공과 실패 여부를 아는 게 중요하다. 잘못된 프로젝트 관리의 결과 잘못된 프로젝트 관리 비용초과 시간 초과 기술적 부족으로 부적절한 수행 예상 이익 획득의 실패 실패한 정보 프로젝트가 생산한 시스템은 종종 프로젝트가 의도대로 사용되지 않거나 전혀 사용되지 않는다. 사용자는 시스템이 잘 작동 되도록 병렬 매뉴얼시스템을 개발해야 한다. 시스템을 실제로 설계하는 데 시스템을 실제로 설계하는데 필수적인 비즈니스 요구 조건을 포착하거나 조직성과를 개선하는데 실패할 수도 있다. 비전문적인 시스템 사용자들에게 시스템과 상호작용 하는 방법은 너무 복잡하고 난해 할 수 있다. 시스템은 이런 사용자들을 위해 설계 되어야 한다. 사용자 인터페이스는 최종 사용자가 상호작용하는 시스템의 한 부분이다. 프로젝트 관리 목표 프로젝트는 특정의 비즈니스 목표를 달성하기 위해 계획된 상관활동의 연속. 정보시스템 프로젝트는 새로운 정보 시스템의 개발, 기존 시스템 향상, 기업의 IT 인프라 교체 및 업그레이드를 위한 프로젝트 등을 포함한다. 프로젝트 관리는 일정한 예산과 시간의 제한 내에서 특정한 목표를 성취 하려고 지식 & 기술 & 도구 & 테크닉 적용을 말한다. 비즈니스의 다른 분야처럼 정보시스템을 위한 프로젝트 관리 하려면 5가지 변수를 잘 다뤄야 한다. 범위: 과업이 무엇이며,무엇이 프로젝트에 포함되지 않는지 규정한다. 프로젝트를 성공적으로 완수하는데 필요한 모든 과업을 규정하 고, 프로젝트의 범위가 처음의 의도를 넘어서 확대되지 않도록 해야 한다. 시간: 프로젝트를 완수하는데 필요한 시간 량 이다. 각 직무를 완료 하는데 필요한 시간을 결정하고, 그 과업을 완료하려는 계획 수립한다. 비용: 정보 시스템 프로젝트 비용은 하드웨어, 소프트웨어, 작업 공간 의 비용도 포함한다. 프로젝트를 위한 예산을 개발하고, 진행 중인 프로젝트의 비용을 감시한다. 품질: 경영자가 규정한 목적을 프로젝트의 최종결과가 얼마나 충족 시켰는지 나타낸다. 정보시스템 프로젝트의 질은 보통 향상된 조직성과 의사결정으로 결정된다. 리스크: 프로젝트의 성공을 위협할 잠재적인 문제를 말한다. 잠재적인 문제는 시간과 비용 증가, 프로젝트의 품질 저하, 프로젝트 완성 방해 함으로서 프로젝트 목표 성취를 방해 한다. Managing Projects 2. 정보시스템 프로젝트를 선택하고 평가하기 위하여 어떠한 방법을 사용했고 이것들이 기업 비즈니스 목표를 어떻게 조정하는가? High 조심스럽게 High 시험-검토 할 프로젝트 Low 피해야 할 프로젝트 Low 확인하고 개발해야 할 프로젝트 일상적인 틀에 박힌 프로젝트 기준 Weight ERP 시스템 ERP 시스템 ERP 시스템 ERP 시스템 A 퍼센트 A 평점 B 퍼센트 B 평점 1.0 주문 프로세싱 1.1 온라인 주문명단 4 67 268 73 292 1.2 온라인 가격 4 81 324 87 348 1.3 물품 목록확인 4 72 288 81 324 1.4 고객 신용체크 3 66 198 59 177 1.5 청구서 4 73 292 82 328 전체 주문 프로세싱 1,370 1,469 Managing Projects 3. 기업은 정보시스템 프로젝트의 비즈니스 가치를 어떻게 평가하는가? 정보시스템의 비용과 이익 실체적인 이익 (Tangible benefits) 측정될 수 있고 금전적 가치로 전환 될 수 있는 이익 (유형의 이익) 실체가 없는 이익 (Intangible benefits) 효율적인 고객서비스나 향상된 종업원의 호의같이 즉각적으로 측정될 수는 없지만 측정 가능한 이득으로 나타나는 이익 (무형의 이익) 노동을 재배치하고 공간을 절약하는 사무시스템들은 경영정보시스템, 의사결정지원시스템 보다 측정가능하고 유형의 이익을 생산해 냄 정보시스템의 비용과 이익 유형이익( 비용절감) 무형이익 생산성 증가 자산 이용 개선 낮은 운영비용 자원 통제력 개선 인건비감소 조직 계획 개선 컴퓨터비용감소 조직의 유연성 증가 외부 수주비 감소 실시간 정보 제공 하드웨어 소비증가율감소 더 많은 정보 통신 행정요원과 전문인력 운영비 감소 조직 학습 증가 설비비용 감소 합법적인 요구사항들의 획득 비용 소프트웨어 서비스 인력 강화된 직원 복지 직무만족도 증가 의사결정능력 향상 운영능력 개선 고객만족도 향상 기업이미지 재고 정보시스템을 위한 자본예산 • 자본예산모델은 장기간의 자본 투자 프로젝트에서 투자 가치를 평가하기 위해 사용되는 방법 중 하나. • 자본예산 방법들은 기업 안팎으로 움직이는 현금 흐름의 측정에 의존하여 자본 프로젝트들은 기업 안팎으로의 현금 흐름을 만들어 냄. • 투자 비용은 자본 설비 구매에서 발생한 직접적 현금 유출로, 이후 몇 년 내에 투자는 투자로 생긴 현금유입과 균형을 맞추고자 추가적인 현금의 유출을 발생 시킬 수 있음. • 현금 유입은 더 많은 제품의 판매, 생산, 운영에서 감소된 비용의 형태로 나타남. • 현금 유출과 현금 유입의 차는 투자의 재무적 가치를 계산하는데 쓰임. • IT프로젝트를 평가하기 위한 자본 예산 모델 - 회수방법, 투자수익률 (ROI), 순현재가치, 내부수익률(IRR) 실물 옵션가격 결정 모델 (ROPM) • 금융 산업에서 차용한 옵션 평가 개념을 사용하여 정보기술의 투자 가치를 평가하는 모델 • 옵션은 어떤 미래 시점에서 사용할 책임이 아니라 권리이다. 예) 콜옵션(call option) 은 어떤 사람이 정해진 날짜나 그 이전에 기초자산을 정해진 가격에 구입할 수 있는 책임이 아닌 권리로서, 금융옵션임 • 기술에 지출한 초기비용이 권리를 만든다는 점에서 스톡옵션(Stock option)과 유사하게 정보시스템을 평가하지만, 경영진이 프로젝트를 취소, 변경, 재개, 연기 할 수 있는 이상 진보할 기술과 그 기술의 전개에 이득을 얻을 의무는 없음 • 장점 : 투자 실행에 앞서 프로젝트의 위험성을 알 수 있는 실험프로젝트나 프로토타입(prototype) 등을 제공함 • 단점 : 기본 자산에서 예상된 현금 흐름과 실행비용의 변화 등 을 포함하는 옵션가치에 영향을 주는 모든 핵심 변수들 을 추정해야 함 재무모델의 한계 • 정보시스템의 재무적, 기술적 측면에서 전통적 시각은 투자의 참 비용과 이익에 영향을 미칠지는 정보시스템의 사회적이고 조직적인 차원을 간과 • 많은 기업에서 행하는 정보시스템의 투자결정은 새 시스템으로 야기된 조직상의 혼란 상황에서 발생하는 비용을 적절하게 고려하지 못함 • 새로운 시스템이나 증진된 직원들의 학습과 지식에서 발생한 시기 적절한 결정과 같은 이익도 고전적 금융 분석에서는 간과 될 수 있음 Managing Projects 4. 정보시스템 프로젝트에서 주요한 위험 요소는 무엇인가? 프로젝트 위험의 특성 프로젝트 크기 소모된 돈의 양, 직원수의 크기, 수행에 할당된 시간 등의 크기가 클수록 그 위험성 큼 프로젝트의 복잡성과 조절의 어려움으로 대규모 프로젝트는 일반 프로젝트에 비해 50~70% 가량 실패 확률 높다 프로젝트 구조 프로젝트는 매우 구조화 되어 있으므로 위험이 낮다 기술적 경험 프로젝트 수행팀과 정보시스템 직원들의 경험이 부족하면 프로젝트 위험도 높다 변화관리와 컨셉(수행)의 개념 변화관리 성공적으로 시스템을 구축하려면, 세심한 변화에 대한 관리 필요 컨셉(수행)의 개념 새로운 정보시스템 도입해 조직적 변화를 효과적으로 관리하려면, 수행과정검토 필수 수행 – 새로운 정보시스템처럼 채택, 경영, 혁신의 일상화를 위해 일하는 모든 조직적 활동 실행과정에서 시스템 분석은 기술적 솔루션 개발, 배열, 상호작용, 다양한 조직에서의 커뮤니케이션을 원활하게 해줌. 최종사용자의 역할 정보시스템의 운영과 디자인에서 사용자 참여는 긍정적인 결과 창출 1. 사용자가 시스템 설계에 깊이 참여하면, 사용자의 우선 사항과 비즈니스 필요 요건, 결과 통제기회를 부여하는 시스템을 생성하기 위해 더 많은 기회 획득 2. 사용자는 변화 과정에서 적극적인 참여자이기 때문에 완벽한 시스템에 더 긍정적 반응 사용자 지식과 전문지식을 통합하는 것은 더 좋은 해결을 이끌어 냄 사용자와 정보시스템 전문가의 관계는 정보시스템 수행 노력에서 전통적 문제영역이 되어옴 사용자와 정보시스템 전문가는 다른 배경, 흥미, 우선 사항을 갖는 경향이 있어 사용자와 설계자간의 의사소통 격차 야기한다. 이러한 차이는 다른 조직적 충성심, 문제 해결을 위한 접근 방법, 어휘를 이끌어냄 사용자 우려 설계자 우려 시스템이 내 일을 위해 내가 필요한 정보를 전달할 수 있을 것인가? 얼마나 많은 디스크 저장 공간이 마스터 파일 을 소모할 것인가? 나는 얼마나 빠르게 데이터에 접근할 수 있을 까? 얼마나 많은 프로그램 코드의 라인이 이 기능 을 수행 할 것인가? 나는 얼마나 쉽게 데이터를 검색할 수 있을까? 우리가 시스템을 가동할 때, 어떻게 우리는 CPU 시간을 줄일 수 있는 가? 내가 시스템 안에 데이터에 접근해야 하는 것 이 얼마나 사무 지원을 할 것인가? 이러한 데이터를 저장하는 가장 효율적인 방 법은 무엇인가? 시스템의 운영이 내 매일의 비즈니스 스케줄 에 얼마나 알맞을 것인가? 데이터베이스 관리 시스템을 우리가 사용할 수 있는가? 사용자와 기술적 전문가 사이의 표명된 격차가 있을 때, 두 그룹이 다른 목표를 추구하는 것을 지속할 때 , 시스템 개발 프로젝트 실패는 매우 높은 위험에 도달함 경영진의 지원과 관여 Managing Projects 5. 프로젝트 위험 요소와 시스템 실행의 관리에 유용한 전략은 무엇인가? 리스크 요인 통제 잠재적인 문제를 예견하고 적절한 조치를 취하면 시스템을 성공적으로 구축할 수 있다. 프로젝트 위험을 관리하는 단계 첫 번째-프로젝트가 직면한 위험 단계와 성질 파악 두 번째 -수행자는 각각 프로그램, 그 위험 수준에 맞는 도구, 방법, 위험관리 접근법 등으로 처리 기술적 복합성 관리 내부통합도구(internal integration tools) 의 사용으로 복합적 기술과 도전적인 프로젝트로부터 이익을 얻을 수 있음 기술 복합성이 얼마나 잘 관리되는지에 따라 프로젝트 성공 여부가 달라짐 상호적 부드러운 관계를 조성해야하며 절대적인 리더 지휘 아래 팀원들 은 풍부한 경험이 있어야 한다. 내부적으로 얻을 수 없는 중요한 지식은 조직 외부에서 수집해야 함 공식적인 계획, 제어 도구 ( Formal Planning and Control Tools ) 프로젝트 계획의 문서화와 모니터를 위한 도구 관리자가 어려움을 발견하고 문제점들이 프로젝트 완료 시간에 어떠한 영향을 주는지 알도록 도움을 줌 프로젝트 계획을 기록하는 두 개의 가장 보편적으로 사용되는 방법은 Gantt 차트와 PERT 차트 시스템 개발자들이 분할 업무를 할 수 있도록 도와줌 Gantt Charts 프로젝트 활동, 시작, 완료 날짜에 대하여 목록화 시기선택, 다른 업무들의 기간, 인적 자원 요구 등을 시각화 업무완료에 걸리는 시간에 비례하는 수평선 바를 통해 나타냄 종속적 임무, 일정상 임무가 다른 임무에 미치는 영향력, 임무가 부여 되는 방식은 보여주지 못함. F14.5(568P) PERT Charts 프로젝트 업무 사이의 연관성을 나타냄 특정 활동을 시작하기 전에 완료되어야 하는 활동, 프로젝트 구성 특정 활동 목록화 마디, 원, 사각형으로 네트워크 도표를 구성함으로써 프로젝트 구현 업무 기간, 시작, 완료 날짜 나타냄 F14-6(569) 사용자의 참여도 증가와 사용자의 저항 극복) - 외부 통합 도구(external intergration tools) : 모든 조직적 단계에서 실행팀의 업무와 사용자를 연결하는 여러 방법들로 구성 사용자들은 프로젝트 팀 내에서 다양한 역할을 수행할 수 있음. 실행팀은 질문에 즉각 응답하고, 사용자의 피드백을 포함하며, 사용자를 도우려는 노력을 보임으로써 반응을 보일 수 있음. - counter implementation 정보시스템의 실행이나 조직 내에서의 혁신을 반대하는 의도된 전략 변화가 자신들의 이익에 해가 된다고 생각하는 사용자들에 의해 발생 극복을 위해서는 사용자 참여(설계 개선 뿐 아니라 동의를 끌어내기 위한), 사용자 교육과 훈련, 경영 명령이나 정책, 협력하는 사용자에게 주어지는 더 나은 인센티브 등의 전략이 필요 조직을 위한 설계 정보 시스템 프로젝트는 새로운 정보시스템이 설치 되었을 때, 절차, 직업 기능, 조직 구조, 권력 관계, 업무 환경 등의 변화를 주의 깊게 계획 인체공학(Ergonomics) 인체공학은 업무 환경에서 사람과 기계사이의 상호작용 직업의 설계와, 건강 문제, 정보시스템의 최종 사용자 인터페이스를 고려 정보시스템을 계획하고 실행할 때, 다뤄야 할 조직적 관점 직원의 참여와 관여 직업설계 표준과 성과 모니터링 인체공학 (설비, 사용자 인터페이스, 업무환경을 포함) 직원 불만 해결 절차 건강과 안전 정부 규제의 준수 조직의 영향 분석 제안된 시스템이 조직의 구조, 자세, 의사결정, 운영에 주는 영향 설명 시스템 분석과 활동 설계가 조직영향 분석을 포함하여야 하지만, 이러한 영역은 전통적 으로 등한시되어옴 정보시스템이 성공적으로 조직에 통합되기 위해서, 철저하고 완벽하게 문서화된 조직 영향(organizational impact) 평가에 대해 더욱 주의를 기울여야 함 사회 기술적 설계 인간과 조직의 문제를 다루는 한 가지 방법으로써, 정보시스템 프로젝트에 사회 기술적 설계 지침을 포함시키는 것 -설계자들은 기술적인 설계와 사회적 설계의 분리된 해결책을 제시 -사회적 설계 계획은 다양한 작업집단(workgroup), 작업 할당, 개인의 직무설계를 분석 -제시된 기술적 해결책은 제시된 사회적 해결책과 비교됨 -사회적 목표와 기술적 목표에 서로 가장 부합되는 해결책이 최종 설계 ,선정됨 사회 기술적 설계의 결과는 조직·인간욕구의 감성(sensitivity)과 기술적 효율성으로 조합된 시스템을 만들어내며, 높은 직업 만족도와 생산성을 이끔 프로젝트 관리 소프트웨어 도구 업무의 정의와 정리 기능, 업무에 필요한 자원을 배당, 업무를 시작하고 끝내는 날짜를 정하고, 업무의 진행 정도 추적, 업무와 자원을 수정 Microsoft Office Project 2007 PERT와 Gantt 차트를 만드는 능력과 중요한 계획의 분석을 돕고, 자원 할당, 프로젝트 추적, 상황 보고를 할 수 있다 EasyProject.NET, Vertabase는 웹 기반 프로젝트 관리 도구 지원 CHAPTER 14 Case Study 1조 성빈이와 연 장자들 DST Systems Scores With Scrum And Application Life Cycle Management 1. DST 시스템의 오래된 소프트웨어의 발전 환경 중에서 무슨 문제가 있는가? 발전 환경 중의 문제 • 이 개발 그룹은 코드 보고나 표준화 개발자 도구 세트 없이 도구, 프로세스 및 소스 코드를 통합한 제어 시스템을 사용한다. 조직 내에서 다른 그룹은 세레나 PVCS, 이클립스, 또는 기타 소스 코드 소프웨어 패키지와 같은 소프트웨어 개발에 대해 매우 다른 도구를 사용한다. • 프로세스에서 수동과 시간이 많이 소요된다. 관리자는 자원을 할당하고, 직원이 어떤 프로젝트을 하고 있고 특정 자산의 상태 를 쉽게 결정하지 못한다. • DST눈 중요한 산품과 AWD를 업데이트하기 위해 노력한다. 이의 전형적인 개발 일정은 격년에 한 번 새 번전을 출시한다. 하지만 다른 경쟁자 들은 새 버전을 더 빨리 출시한다. • DST는 전통 waterfall 모델을 사용한다. 소프트웨어 개발의 waterfall모델처럼 텍스트가 순차적으로 흐르고 있고 이전 단계가 완료된 이후에 다음단계가 진행된다. DST Systems Scores With Scrum And Application Life Cycle Management 2. 이러한 문제점을 해결하는데 Scurm은 어떠한 도움을 주었는가? 기존의 시스템의 문제점으로 인해서 최소의 투자로 극대화된 효과를 얻기 위해 새로운 개발 방식 찾음 Scrum Agile 개발 방법론으로 작은 개발 팀, 짧은 개발 주기, 팀의 집중력과 생산성을 유지시켜 점진적으로 소프트웨어를 개발 Cross-functional Team 각 부문의 전문가들이 모여 운영하는 팀 ScrumMaster 요구사항에 대한 변화 확인 팀 프로젝트 진행사항 확인 프로젝트 오너 제품의 설계에 대해 기 업, 고객, 사용자들을 guiding한다. Scrum은 1990년 경에 Ken Schwaber와 Jeff Sutherland에 의해서 개발되었다. 1993년 Easel Corporation에서 처음으로 사용되었다. 기술적 개발 접근 보다는 소프트웨어 개발에 대한 관 리적 개발 접근 중심이다. Scrum의 기초의 대부분은 하버드 비즈니스 리뷰에서 Hirotaka Teceuchi 와 Nonaka Ikujiro 에 의해 작성된 "New New Product Development Game"이라는 기사에서 출발하였다. Cutter IT Journal 에서 Ken Schwaber가 작성한 연구 논문 "Controlled Chaos: Living on the Edge"에 기반하고 있다. Scrum은 "짧은 회의, 일일 관리, 수평 조직, 협업 산정 및 계획, product backlog, sprint backlog, burn-down chart" 등으로 구성 개발 상태를 보고하고, 공개적으로 문제 또는 장애를 식별하기 위해 매일 실시되는 15분 미 팅을 집행하는 실무에서 Scrum이라는 이름이 나왔다. 이 미팅이 럭비의 "scrum"과 비슷하여, 이렇게 불려지게 되었다. "관리자는 프로젝트가 어떻게 진행되는 지를 알기 위해, 미팅에 참 석할 수 있지만, 참여할 수는 없다."라고 Ken Schwaber를 말하고 있다. Scum에서 timebox 반복을 Sprint라고 부른다. 각 Sprint는 "Sprint Goal"을 가지고 있다. 이는 Iteration을 위한 비즈니스 목적을 수립하고, 각 Sprint의 범위와 내용을 수립한다. XP와는 달 리, Sprint가 일단 시작되면, 내용을 변경할 수가 없다. XP는 소프트웨어 개발 팀의 일부분으로 "고객"을 갖는 반면, Scrum에서는 그 역할 을 "Product Owner"가 수행한다. Product Owner는 커뮤니케이션을 촉진시킨다. 이들은 모델 링에 적극적으로 참여하게 되며, 문서를 필연적으로 작성하게 되지만, 매우 민첩하게 수행 DST Systems Scores With Scrum And Application Life Cycle Management 3. DST는 그들의 소프트웨어 프로젝트에서 Scrum을 효율적으로 사용하기 위해서 어떤 수정을 하였는가? 다루어 져야 될 경영, 조직, 기술적인 요소는 무엇인가? Collabnet Teamforge DST는 소프트웨어 개발 환경을 통합하기 위한 Application life cycle management 필요 통합되어진 코드에 대한 저장소 또는 표준화 된 개발자 도구 세트가 없는 소 스 코드 통제 시스템을 사용 분산된 팀을 위해 완전하게 통합된 개방형 ALM 플랫폼/ 환경에 알맞게 개발할 수 있도록 구별 하게 해주는 프로젝트 평가 팀 구성 스크럼이라는 연구를 시작 생산품의 소유주와 다른 관련된 이해 관계자들에게 새로운 기능을 보여주 는 것을 검토하고 허용 Collabnet subversion DST는 소프트웨어 개발 환경에서 개발 툴의 통합 필요 오픈, 확장된 개발 플랫폼이 필요 웹 기반 협업도구로서 오픈 및 확장 이 가능한 개발 플랫폼 조직 Team Project 관리자의 선정 및 훈련 Project 관리에 대한 전문적인 담당부서 필요 Scrum팀에 대한 이해와 추가적인 개발 필요 경영 Project management 소프트웨어의 선택(예산, 효율성) 기업의 전략과 시스템/소프트웨어의 통합(개방/통합 Tool의 필요성) 기술 새로운 시스템 적용에 따른 인프라 구축 Scrum과 같이 사용할 수 있는 도구 준비 Motorola Turns To Project Portfolio Management 1. 비즈니스에서 모토로라가 직면하는 도전은 무엇인가? 왜 프로젝트 관리가 이 회사에서 결정적인가? • 휴대전화, 무전기 및 무선통신 시스템, 광대역 통신제품 및 각종 전자제품과 네트워킹 제품을 개발하여 공급하는 다국적 기술회사 • 본사는 일리노이주 샤움버그에 위치해 있고, 세계 21개국에 사업장 및 주요 생산시설 가지고 있음 • 2009년에 53000명의 직원들과 220억 원의 수익을 냄 모토로라가 직면하는 도전 • 모토로라는 기업인수 합병을 통해서 성장해왔기 때문에, 그 결과 사업에서 수천 가지 다양한 기능의 시스템이 수행 됨 • 다양한 시스템으로 기업이 운영되면, 효율성이 떨어지고 비용절감이 어려움 • 좋지 않은 경제상황에서 비용을 절감하고 효율을 증가시키기 위해서 세 개의 주요부서 조직 - Mobile Devices segment : 스마트폰, 무선헤드셋의 설계 및 제조, 판매, 서비스 - Home and Networks segment : 케이블티비 운영자, 무선 서비스 제공자, 그 밖의 다른 통신 제공자로부터 사용된 장비와 인프라 개발 - Enterprise Mobility segment : Market voice, 데이터통신제품, 무선 광역망 시스템, 호스트 애플리케이션, 다양한 기업 고객들을 위한 장치 개발 모토로라에서 프로젝트 관리가 중요한 이유 • 모토라라는 통신, 휴대폰 기술 업체이기 때문에, 최신 기술에 민감 • 스마트폰 같이 경쟁자가 많은 사업에서 성공하기 위해서는 프로젝트 관리가 중요함 Motorola Turns To Project Portfolio Management 2. HP PPM의 어떤 특징이 모토로라에게 가장 유용했는가? HP PPM (HP Project and Portfolio Management) • 기업의 비즈니스 성과와 IT 프로젝트를 연계 • IT 투자에 대한 성과와 리스크를 분석하여 IT 프로젝트들의 우선순위를 매기고, 리소스 및 진도관리 등을 진행함으로써, 프로젝트의 성공적인 완료와 전체 프로젝트 포트폴리오를 관리 → 안정적인 비즈니스 서비스 제공을 통한 기업의 비즈니스 성과를 최적화하는 솔루션 HP PPM의 목표 우선순위화 기능 • 실시간으로 다양한 단계의 input, 검토, 승인과 기업 모든 구역의 가시화 등 광범위한 도구를 제공함으로써, 모토로라가 모든 IT 포트폴리오를 사용하게 해줌 • 사용자는 자원, 예산, 예측, 비용, 프로그램, 프로젝트 등 IT에서 전반적으로 요구되는 정보의 최신 데이터 이용 가능 • HP PPM은 SaaS로써 모토로라 직원에 의해 접근 가능 -모토로라는 on-site 버전을 사용했지만 SaaS 전환 함 • Saas의 사용은 모토로라의 지원비를 50% 감소시키는 효과 가져옴 Motorola Turns To Project Portfolio Management 3. 모토로라가 HP PPM을 실행하고 성공적으로 사용하기 전에 고려해야 되는 경영,조직,기술 요소는? 경영 • 모토로라 비즈니스 각 기능에 대한 중요성을 검토 • 모토로라 각 부서의 비즈니스기능과 프로세스가 겹치는 것이 비효율과 비용적 문제를 만드는 것을 해결하기 위한 아웃소싱 업체와 소프트 웨어 업체의 선정 • HP사의 프로젝트와 포트폴리오 관리센터 소프트웨어를 적용과 실행할 때 생길 수 있는 이익을 검토하고 적용 방법, 시기 등을 결정 • HP PPM이 프로젝트를 우선순위로 분류해주고 실시간으로 최신의 데이터를 제공함으로써 프로세스를 자동화하고 운영상의 비용절감의 효과를 가져오는지를 검토 조직 • HP사의 프로젝트와 포트폴리오 관리센터 소프트웨어를 성공적으로 적용하고 실행 하기 위한 조직 내 훈련 • HP PPM이 프로젝트를 우선순위로 분류해주고 실시간으로 최신의 데이터를 제공함으로써 프로세스를 자동화하고 운영상의 비용절감의 효과를 가져오는지를 꾸준히 검토하고 조직에 맞추어 HP와 협조하여 변화하고 수정해나가야함 ->조직내 중복업무가 감소하는지를 프로젝트 관리부서를 설치함으로써 검토 기술 • 프로젝트 우선순위를 분류하고 중복업무를 제거하고 최신의 데이터를 제공하는 프로젝트 관리를 위한 시스템과 기술이 부재하다는 것을 파악 • HP PPM은 SaaS 형태로 서비스를 제공하며 중앙저장소를 바탕으로 목표의 우선순위화와 비즈니스 전 영역에 대한 가시성 • 효과적으로 실시간의 IT 프로그램 및 프로젝트 상태를 잡아내는 높은 수준의 타겟된 데이터와 그래픽 디스플레이를 사용함으로써 모토로라가 가진 문제를 해결해줄 수 있는 기술적 요소가 있음 Motorola Turns To Project Portfolio Management 4. 모토로라에서 HP PPM을 채택한것의 비즈니스 영향을 평가해보라. HP PPM의 비즈니스 영향 • 관리자들이 제안서들과, 프로젝트, 운영상의 활동들의 예산과 자원요소들을 비교하는데 도움을 줌 -> 이러한 분석자료는 HP 중앙저장소에 저장됨 • 이러한 중앙저장소는 프로젝트 목표의 우선순위를 설정해주고 비즈니스 전체 영역에 대한 가시성을 제공하는 등의 광범위한 툴을 제공 •HP PPM 사용자는 자원, 예산, 예측, 비용, 프로그램, 프로젝트 등 IT의 전반적으로 요구되는 정보의 가장 최근 데이터를 갖음 ->모토로라가 모든 IT포트폴리오를 관리할 수 있게 해줌 • 비즈니스 분석과 이를 기반으로 한 권장사항의 생성 • HP PPM은 효과적으로 실시간의 IT 프로그램 및 프로젝트 상태를 잡아내는 높은 수준의 타겟된 데이터와 그래픽 디스플레이를 사용하고 이것은 또한 프로젝트, 제안서, 자산의 최적의 조합을 자동으로 생성하여서 가정 시나리오 (what-if 시나리오)를 계획하여 새로운 비즈니스 프로젝트의 가치와 유용성을 예측할 수 있게 해줌 • SaaS(소프트웨어의 기능 중 유저가 필요로 하는 것만을 서비스로 배포해 이용이 가능하도록 한 소프트웨어의 배포형태)로 서비스를 제공하기에 비용이 절감 • HP PPM을 사용함으로써 프로세스를 자동화하고 운영비용을 낮추려는 모토로라의 목표가 달성됨 ->실제 모토로라는 40% 비용구조를 절감하고 대규모 프로젝트에서 HP PPM을 사용함으로써 150%의 투자수익률을 올림. 모토로라의 IT 지원 비용의 25 % 감소 동일한 작업을 수행하는 중복 업무를 거의 제거하고 회사의 "낭비되는 작업"을 25 % 감소시킴 Jetblue and WestJet : A Tale of Two IS Projects 1. WestJet과 JetBlue 같은 항공사에서 예약시스템은 얼마나 중요한가? 예약시스템은 의사결정과 운영활동에 어떻게 영향을 미치는가? 예약 시스템의 중요성 예약 시스템 제대로 작동 고객 불만 & 수익 하락 항공편을 구매하려는 고객이 많으면 예약시스 템을 더 추가하고 임시 콜 센터 직원을 더 고용, 좌석 양을 조절하면서 고객을 최 우선시 함. 예약 파일을 분석하여 비행 스케줄 조정. 예약 시스템을 통해 항공사 의사결정 관리 Jetblue and WestJet : A Tale of Two IS Projects 2. WestJet과 JetBlue의 예약시스템을 업그레이드 하는 프로젝트의 주요 위험요소를 평가해라. 위험요소를 관리 함으로서 잠재적인 문제를 예상하고 적절한 전략을 적용하는 것은 시스템의 성공 기회를 높여준다 기술 측면: 복잡한 기술이 얼마나 잘 운영되어질 수 있는지에 달려있다 => 기술적 경험 필요 계획 측면: 프로젝트를 실행하기 위해서는 프로젝트 계획 진행과정을 확인 한 다음 진행절차를 확인해야 한다. => 계획의 검토와 확인 • WestJet은 오래된 Sabre 예약 시스템 으로부터 업그레이드 (기존의 오래된 시스템 적용) WestJet의 840000개의 파일이 이미 항공편을 구매한 과거의 고객의 거래데 이터를 포함하여 거래 => WestJet의 예 약 시스템 서버가 오래된 데이터를 전 송 했고 WestJet 대행사가 데이터를 처 리하는데 복잡한 단계를 겪는 어려움을 겪음. WestJet 즉시 파일의 움직임에 요구 되는 이동시간과 항공편 작동에 승객의 짐을 줄이는 것에 실패했다.=> 항공편 에 대한 예약과 파일전송 이후 일정 기 간 동안 접근하기 어려움으로 고객 불 만족 쇄도했고 고객의 불만은 전화와 인터넷을 통해 드러났다. = 이미지 손상 • JetBlue는 SabreSonic CSS를 채택 (기존의 오래된 시스템 적용) 젯 블루 항공은 사소한 결함 전화와 대기시간이 증가하고 모든 공항 키오스 크 및 티켓 프린터가 즉시 온라인으로 되지 않는 몇 가지 문제를 경험 => 2007 년 2 월에, 다른 모든 주요 항공 사들이 강한 눈보라로 그들의 항공편을 이미 취소했을 때 JetBlue에서는 항공 편을 운영 => 나쁜 기상 조건은 이륙상 태에서 비행을 방해 했고 승객을 10시 간 동안 좌초시켰다. = 이미지 손상 젯 블루 항공은 취소 항공편이 1100 로 총 30 만 달러의 손실에 도달, 이후 며칠 동안 항공편 취소가 계속되었다. 이러한 경험은, 새로운 시스템을 실행 할 때 자체 IT 시행에 대해 신중하게 접근하면서 관찰 해야 한다. Jetblue and WestJet : A Tale of Two IS Projects 3. 각각의 항공회사의 예약시스템의 문제를 분류하고 묘사하라. 경영, 조직, 그리고 기술의 요소에서 야기된 문제는 무엇인가? Jetblue and WestJet : A Tale of Two IS Projects 4. 이러한 Project 위험을 통제하는 당신의 단계를 묘사하라. 고위 경영자 중간관리자 운영관리자, 직원 고위 경영진의 시스템 정책 결정에서 시스템 교육이나 방안 등을 마련하도록 시행 경영진들에 의해 결정된 사항을 중간 관리층에서 제도와 시스템을 준비 함 준비된 시스템을 교육하여 고객을 위해 최고의 서비스를 제공