QA ≠ Test

QA(품질 보증)는 개념적인 용어이고, TEST는 QA(품질 보증)를 하기 위한 수단이자 방법이다.

EDUCATION

[사업관리] 핵심 용어 - 비즈니스 케이스에 대해서 알아보자

품생품사(品生品死) 2021. 2. 15. 00:15
반응형

비즈니스 케이스 (Business Case)

✔ 비즈니스 케이스는 예상되는 기대 이익, 예상 비용, 기술적 그리고 관리적인 계획과 계획에 대한 현실성을 뒷받침할 데이터들에 대한 상세한 내용을 제공한다.


비즈니스 케이스는 다양한 형태의 양식(Forms)으로 구성된다. 최소한에 있어, 이는 문제를 기술하고, 해결책을 제안하며, 이것이 구현하고자 하는 비용과 리스크, 그리고 소모 비용을 정당화할 수 있는 예상되는 이점에 관한 내용을 포함해야 한다.


비즈니스 케이스는 최소한 다음과 같은 구성은 지니고 있어야 한다.

 

 

문제 기술 (Problem Statement)

✔ 문제 기술은 어떠한 부적절함과 비효율성과 약점들을 일으키는 현재의 환경과 현상을 부각해 기술한다. 예를 들어 연방 항공 통제국(FAA)은 기존 시스템이 4년 후에는 적어도 일주일에 한 번씩은 항공기의 운항 괘도 추적에 실패할 것이라고 주장함으로써 새로운 시스템으로 교체해야 한다는 주장을 효과적으로 펼칠 수 있었다.

해결책 (Solution)

✔ 비즈니스 케이스에는 상위 새 레벨에서의 해결책을 반드시 기술해야 한다. 예를 들어, 해결책이 레거시 메인 프레임에서 일련의 점진적인 개발과 배포 과정을 통해서 현대화된 하드웨어/소프트웨어로 이전한다던가? 라 하는 것들이다. 해결책은 일정과 비용에 대한 예측치를 제안해야 한다.

리스크(Risks)

✔ 리스크는 비즈니스 케이스에서 간과되는, 그러나 매우 중요한 요소이다. 지금까지 발생한 문제에서 파생되는 범위에 대해서 과장되는 부분이 많을 것인데, 리스크 섹션은 당신에게 최종 시스템에 영향을 주고, 투입 노력에 영향을 주는 것들을 나열함으로써 신뢰성을 회복하게 한다. 이 섹션은 또한 현대화(Modernization) 시도에서 가장 중요한 부분인, 기대 바를 초기에 확정시킨다.

이점 (Benefits)

✔ 이 항목은 제한된 시스템이 리스크를 감안 했을 때, 얻게 되는 이상적인(Ideally) 이점이 비용에 대해 얼마나 되는지를 식별한다. 비관적인 시나리오, 예상되는 시나리오, 낙관적인 시나 리오를 만들 수 있다. 낙관적인 시나리오를 사람들이 믿지는 않겠지만, 이는 예상되는 시나리오가 낙관적인 시나리오와 다른 것!이라는 신빙성을 더할 것이다.


✔ 이와 더불어 비즈니스 케이스에는 프로젝트의 여러 가정들을 식별해야 한다. 비즈니스 케이스를 이해하고, 기록하고, 발표하는 것은 현대화 계획에 있어 매우 중요하다. 이는 소모되는 비용에 대한 투자를 받고 프로젝트 수행 중에 투자받기로 한 금액을 보호하기 위해서도 필요하다.

 

 

비즈니스 타당성(Business Justification)

프로젝트를 위해 준비된 비즈니스 정당성(Business Justification) 또는 비즈니스 사례라고 한다. 제안서와 그리 다르지 않지만 다분히 타당성을 증명하기 위한 회사 내부용 문서이다. 이는 향후 활동의 타당성, 합리성 및 목적성을 평가하고 장단기 관점에서 구현 성공 가능성을 평가할 수 있게 된다.

 

 프로젝트의 비즈니스 사례는 또한 프로젝트를 감독하는 주체 및 기관(이해 당사자)이 프로젝트 과정에 영향을 미치는 결정을 내리고 정당화할 수 있는 문서로 작성되어야 한다. 이것은 프로젝트를 시작하는 기본 문서의 필수 부분 중 하나이고, 프로젝트 헌장 및 최소한 비즈니스 정당성은 프로젝트의 예상 결과를 정의하고 프로젝트 팀에 방향을 제공해야 한다.


✔ 핵심은 다름 아닌 당위화 (합리화) justification이다. 즉, 이 일을 통해 어떤 득 또는 실이 있는지, 그 득과 실의 정도는 얼마인지를 설명하고 이해하는 것이며, 궁극에는 그렇게 움직이게 하는 것이다.


✔ 잘 작성된 비즈니스 케이스에는 아래 내용을 기본적으로 포함하고 있다.

  • 추진하려고 하는 일은 한 줄 요약되어 있어야 한다.
  • 어떤 득과 어떤 실이 예상되어야 한다.
  • 고객 몇 명, 언제까지 아니면 몇 % 등등의 예상 숫자 등 정량적 수치로 표시되어 있어야 한다.
  • 만약 일이 계획대로 되지 않으면 어떤 영향이 있을지 리스크를 예측해야 한다.
  • 일의 진행이 수월하지 않더라도 수행하고 있는지를 모니터링할 수 있어야 한다.

 

Related References

✔ Clark, K. B. (2003). Project Scope and Project Performance. Operations Management: Critical Perspectives on Business and Management, 3(10), 446.
✔ Khan, A. (2006). Project scope management. Cost engineering, 48(6), 12-16.
✔ Kraus, W. E., & Cressman, K. R. (1992). Project Scope Definition-A Practical Approach, COST ENGINEERING-ANN ARBOR THEN MORGANTOWN-, 34, 15-15.
✔ Meredith, J. R., & Mantel Jr, S. J. (2011). Project management: a managerial approach. John Wiley & Sons.
✔ PMI (2014). Project Management Body of Knowledge (PMBOK® GUIDE). In Project Management Institute.

 

This is audit_0001

요약 : 소프트웨어어 qa, 웹 qa, 앱 qa, 소프트웨어 테스트 자동화, 자동화 소프트웨어, pm 교육, 비즈니스 소프트웨어, 소프트웨어 공학 프로젝트, audit, auditer

반응형