사업분석

Business analysis
비즈니스 분석과 혼동하지 마십시오.
경영학
기업경영
회계
사업주체
기업지배구조
회사법
법인명칭
경제학
자금
관리유형
조직
거래

비즈니스 분석은 비즈니스 요구를 파악하고 비즈니스 문제에 대한 솔루션을 결정하는 데 중점을 둔 전문[1] 분야입니다.[2] 솔루션에는 소프트웨어 시스템 개발 구성 요소, 프로세스 개선 또는 조직 변경이 포함될 수 있으며 광범위한 분석, 전략 계획 및 정책 개발이 포함될 수 있습니다. 조직 내에서 이러한 업무를 수행하는 데 전념하는 사람을 비즈니스 분석가 또는 BA라고 합니다.[3]

비즈니스 분석가는 소프트웨어 시스템을 개발하기 위한 프로젝트에서만 발견되는 것은 아닙니다. 또한 비즈니스 이해 관계자와 협의하여 비즈니스 문제를 해결하면서 조직 전반에 걸쳐 작업을 수행할 수도 있습니다. 오늘날 비즈니스 분석가들이 수행하는 대부분의 작업이 소프트웨어 개발/솔루션과 관련되어 있지만, 이는 전 세계적으로 비즈니스가 디지털화 시도에서 겪고 있는 지속적인 대규모 변화 때문입니다.[4]

역할 정의는 조직에 따라 다르지만 대부분의 비즈니스 분석가들이 일하는 공통의 영역이 있는 것 같습니다. 책임은 다음과 같습니다.

  • 비즈니스 시스템을 조사하고 상황을 전체적으로 파악합니다. 여기에는 조직 구조 및 직원 개발 문제뿐만 아니라 현재 프로세스 및 IT 시스템의 요소를 조사하는 것이 포함될 수 있습니다.
  • 비즈니스 시스템의 운영을 개선하기 위한 조치를 평가합니다. 여기서도 제안된 프로세스 재설계 및 IT 시스템 개발과 일치하는지 확인하기 위해 조직 구조 및 직원 개발 요구 사항을 검토해야 할 수 있습니다.
  • 적절한 문서화 표준을 사용하여 IT 시스템 지원을 위한 비즈니스 요구사항을 문서화합니다.

이에 따라 핵심 비즈니스 분석가 역할은 비즈니스 상황을 조사하고 비즈니스 시스템 개선을 위한 옵션을 식별 및 평가하며 요구 사항을 정의하고 비즈니스 요구 사항을 충족하는 데 있어 정보 시스템을 효과적으로 사용할 수 있도록 보장하는 역할을 하는 내부 컨설팅 역할로 정의할 수 있습니다.

하위분야

비즈니스 분석에는 요구 사항 분석이 포함되며, 때로는 요구 사항 엔지니어링이라고도 합니다. 조직의 변경 사항이 전략적 목표와 일치하는지 확인하는 데 중점을 둡니다. 이러한 변경에는 전략, 구조, 정책, 비즈니스 규칙, 프로세스 및 정보 시스템에 대한 변경이 포함됩니다.

비즈니스 분석의 예는 다음과 같습니다.

기업분석 또는 기업분석

비즈니스 전반의 요구사항과 전략 방향을 이해하고 비즈니스가 이러한 전략적 목표를 달성할 수 있는 이니셔티브를 파악하는 데 중점을 둡니다. 또한 다음을 포함합니다.

요구사항 계획 및 관리

비즈니스 분석가가 요구 사항을 수집하는 방법, 순서, 기술, 이해 관계자 및 그가 따를 일정을 계획하는 것을 포함합니다. 반면에 요구사항 관리에는 요구사항 변경 요청을 포함하여 최종 요구사항을 최신으로 유지하기 위해 비즈니스 분석가가 따라야 할 프로세스가 포함됩니다.

요구사항 도출

본문 : 요구사항 도출

프로젝트의 이해관계자로부터 요구사항을 수집하기 위한 기술을 설명합니다. 요구사항 도출을 위한 기술은 다음과 같습니다.

요구사항 분석 및 문서화

프로젝트 팀에서 요구사항을 성공적으로 구현할 수 있도록 요구사항을 개발하고 지정하는 방법을 설명합니다.

분석.

주 기사 : 요구사항 분석

분석의 주요 형태는 다음과 같습니다.

문서화

요구사항 문서는 다음과 같은 여러 형태로 작성될 수 있습니다.

  • 텍스트 – 예를 들어 특정 정보를 요약한 이야기
  • 행렬 – 예를 들어 우선 순위가 있는 요구 사항 표
  • 다이어그램 – 예를 들어 한 구조에서 다른 구조로 데이터가 흐르는 방법
  • 와이어프레임 – 예를 들어 웹사이트에서 요소가 필요한 방법,
  • 모델 – 예를 들어 컴퓨터 게임의 캐릭터를 묘사하는 3-D 모델

요구사항통신

이해관계자들이 요구사항과 요구사항의 이행 방법을 공유할 수 있도록 하는 기술을 설명합니다.

솔루션 평가 및 검증

비즈니스 분석가가 제안된 솔루션의 정확성을 수행하는 방법, 솔루션 구현을 지원하는 방법 및 구현 시 발생할 수 있는 단점을 평가하는 방법을 설명합니다.

기술

비즈니스 분석가가 비즈니스 변경을 촉진할 때 사용할 일반적인 비즈니스 기술이 많이 있습니다.

이러한 기술 중 일부는 다음과 같습니다.

페스틀

메인 기사: PESTLE

이는 조직에 영향을 미치는 다양한 외부 요인을 조사하여 외부 환경 분석을 수행하는 데 사용됩니다.

PESTLE의 6가지 속성:

  • 정치적(정치적 압력에 의한 현재 및 잠재적 영향력)
  • 경제(지역, 국가 및 세계 경제에 미치는 영향)
  • 사회학(한 사회가 조직에 영향을 미칠 수 있는 방법)
  • 기술(신기술 및 신흥기술의 효과)
  • 법적(국내법과 세계법의 효력)
  • 환경(지역, 국가 및 세계 환경 문제)

헵탈리시스

이를 통해 7개의 중요한 범주에 대한 초기 단계 비즈니스/벤처에 대한 심층 분석을 수행할 수 있습니다.[5]

조향

그것은 본질적으로 PESTLE에 대한 또 다른 해석입니다. PESTLE의 동일한 요소를 고려하며, 작성자/사용자가 PESTLE과 반대로 이 약어를 사용하기를 선호하는 경우를 제외하고는 자체적으로 도구로 간주되어서는 안 됩니다. 스티어는 다음 사항을 고려합니다.

  • 사회문화적
  • 테크니컬
  • 경제의
  • 생태학
  • 규제요인

대부분의.

이를 통해 MOST의 속성을 정의하여 작업 중인 프로젝트가 네 가지 속성에 각각 맞게 정렬되도록 내부 환경 분석을 수행할 수 있습니다.

MOST의 네 가지 속성은 다음과 같습니다.[6]

  • 미션(기업이 가고자 하는 곳)
  • 목표(미션을 달성하는 데 도움이 되는 주요 목표)
  • 전략(앞으로 나아가기 위한 옵션)
  • 전술(전략을 실행하는 방법)

SWOT

SWOT는 힘이 있고 가장 큰 기회가 있는 분야에 활동을 집중하는 데 도움이 됩니다. 이를 통해 약점과 내부 및 외부 위협의 형태로 나타나는 위험을 식별합니다.

SWOT 분석의 네 가지 속성은 다음과 같습니다.

  • 장점 – 장점은 무엇입니까? 현재 잘 되어 있는 것은 무엇입니까? (예: 회사의 가장 우수한 활동의 핵심 분야)
  • 약점 – 개선해야 할 점은 무엇입니까? 극복해야 할 것은 무엇입니까? (예: 불만족스럽게 수행하고 있는 주요 영역)
  • 기회 – 조직이 직면한 좋은 기회는 무엇입니까? (예: 경쟁사의 실적이 저조한 주요 분야)
  • 위협 – 조직이 직면한 장애물은 무엇입니까? (예: 선수들이 좋은 성적을 낼 수 있는 주요 분야)

CATWOE

이는 비즈니스가 달성하려고 하는 것에 대한 생각을 촉구하는 데 사용됩니다. 비즈니스 관점은 비즈니스 분석가가 제안된 솔루션이 관련된 사람들에게 미치는 영향을 고려하는 데 도움이 됩니다.

CATWOE에는 6가지 요소가 있습니다.[7]

  • 고객 – 최고 수준의 비즈니스 프로세스의 수혜자는 누구이며 문제가 고객에게 미치는 영향은 무엇입니까?
  • 행위자 – 상황과 관련된 주체, 솔루션 구현에 참여하는 주체, 성공에 영향을 미치는 주체는 무엇입니까?
  • 전환 프로세스 – 문제의 영향을 받는 프로세스나 시스템은 무엇입니까?
  • 세계관 – 큰 그림은 무엇이며 이 문제가 미치는 더 큰 영향은 무엇입니까?
  • 소유자 – 조사 중인 프로세스나 상황을 누가 소유하고 있으며, 솔루션에서 어떤 역할을 담당하고 있습니까?
  • 환경적 제약 – 솔루션과 솔루션의 성공에 영향을 미치는 제약 및 제한 사항은 무엇입니까?

드보노의 6가지 생각하는 모자

이는 아이디어와 옵션을 생성하고 분석하기 위해 브레인스토밍 세션에서 자주 사용됩니다. 특정 유형의 사고를 장려하는 데 유용하며 누군가에게 "기어 전환"을 요청하는 편리하고 상징적인 방법이 될 수 있습니다. 그룹을 특정한 방법으로만 사고하도록 제한하는 것을 포함합니다. 즉, 당시의 "분위기"에 맞는 아이디어와 분석을 제공합니다. 6가지 생각하는 모자로도 알려져 있습니다.

  • 화이트: 순수한 사실, 논리적.
  • 녹색: 창의적입니다.
  • 노란색: 밝고, 낙관적이고, 긍정적입니다.
  • 흑인: 부정적인, 악마의 옹호자.
  • 빨간색: 감성적.
  • 파란색: 차갑다, 컨트롤.

모든 색상/무드를 사용해야 하는 것은 아닙니다.

오왜

다섯 가지 이유를 사용하여 단일 사례에서 실제로 발생하는 일의 근원을 파악할 수 있습니다. 주어진 각 답변에 대해 추가적인 '이유'를 묻습니다.

모스크바

이는 요구사항 자체의 유효성과 다른 요구사항에 대한 우선순위를 비교하여 적절한 우선순위를 할당하여 요구사항의 우선순위를 결정하는 데 사용됩니다.

MoSCoW는 다음과 같이 구성됩니다.

  • 반드시 있어야 합니다 – 그렇지 않으면 배송에 실패합니다.
  • 그래야만 합니다. 그렇지 않으면 해결책을 채택해야 합니다.
  • 그럴 수도 있음 – 배송 만족도를 높이기 위해
  • 이러한 시간을 가질 수 없습니다. 이 배송 기간에서 요구 사항을 제외하는 데 유용합니다.

VPEC-T

주 기사: VPEC-T

이 기법은 공통의 이해관계가 있지만 우선순위와 책임이 다른 시스템에 대한 여러 당사자의 기대를 분석할 때 사용됩니다.

  • 가치 – 참여하는 모든 당사자의 목표, 신념 및 관심사를 구성합니다. 그들은 재정적, 사회적, 유형적 및 무형적일 수 있습니다.
  • 정책 – 수행 가능한 작업 및 수행 가능한 방법을 규정하는 제약 사항
  • 이벤트 – 활동을 자극하는 실제 진행
  • 내용 – 비즈니스 활동의 모든 측면에서 작성되고 사용되는 문서, 대화, 메시지 등의 의미 있는 부분
  • 신뢰 – 시스템 사용자와 시스템 내 정보에 액세스하고 변경할 수 있는 권리 간

SCRS

비즈니스 분석에서 SCRS 접근 방식은 분석이 높은 수준의 비즈니스 전략에서 현재 상태와 요구 사항을 거쳐 솔루션으로 흘러야 한다고 주장합니다[8]. SCRS는 다음을 가리킨다.

  • 전략.
  • 현재상태
  • 요구 사항들
  • 해

비즈니스 분석 캔버스

비즈니스 분석 캔버스는 비즈니스 분석가가 비즈니스 분석 작업 할당의 일부로 완료될 활동에 대한 높은 수준의 보기를 신속하게 제시할 수 있는 도구입니다. 비즈니스 분석 캔버스는 여러 섹션으로 나뉩니다.

  • 프로젝트목표
  • 이해관계자
  • 납품가능
  • 목표 운영 모델에 미치는 영향
  • 커뮤니케이션 접근법
  • 책임
  • 스케줄링
  • 주요일자

캔버스에는 비즈니스 분석가가 컨텐츠 구축에 도움이 되도록 조직에 요청할 수 있는 활동과 질문이 있습니다.[9]

비즈니스 프로세스 분석

프로세스는 현재 상태를 파악하기 위해 시각적으로 모델링되고 모델은 특정 비즈니스 프로세스에 영향을 미치는 활성화 요인을 파악하기 위해 수준별로 표시됩니다. 가장 높은 수준의 모델에는 많은 기업에서 공통적으로 사용할 수 있는 엔드 투 엔드 비즈니스 프로세스가 있습니다. 비즈니스 프로세스 수준 아래에는 활동, 하위 활동 및 마지막 작업의 수준이 있습니다. 작업 수준은 가장 세분화되며 모델링 시 특정 워크플로우를 보여줍니다. 비즈니스 프로세스가 워크플로우 수준에서 문서화됨에 따라 특정 비즈니스에 영향을 미치는 특성에 의해 더 큰 영향을 받거나 "활성화"됩니다. 이러한 "워크플로우 지원자"는 워크플로우 설계, 정보 시스템/IT, 동기 부여 및 측정, 인력 및 조직, 정책 및 규칙, 시설/물리적 환경으로 간주됩니다. 이 프로세스 레벨링 및 분석 기법은 비즈니스 분석가들이 특정 비즈니스에 실제로 필요한 것이 무엇인지, 그리고 미래의 상태에서 더 높은 효율성을 위해 프로세스를 다시 설계할 수 있는 가능성이 있는 곳을 이해하는 데 도움이 됩니다.[10]

비즈니스 프로세스 분석은 효율성을 개선하고 비용을 절감하며 생산성을 극대화하려는 모든 비즈니스에 매우 유용한 도구입니다. 비즈니스 운영 방식을 이해하고 개선 기회를 파악하기 위한 포괄적이고 체계적인 접근 방식입니다. 기업은 전체 프로세스를 끝에서 끝까지 분석하기 위해 한 걸음 뒤로 물러섬으로써 운영 효율화를 위해 해결할 수 있는 비효율성 영역을 식별할 수 있습니다. 프로세스 분석은 또한 제거하거나 채울 수 있는 프로세스의 중복이나 공백을 식별하는 좋은 방법입니다. 올바른 전략과 구현을 통해 기업은 조직의 성과를 개선하고 시간과 비용을 절약할 수 있습니다. 올바른 툴을 사용하면 프로세스 및 절차에서 발생하는 모든 문제를 쉽게 파악하고 해결할 수 있으므로 변화에 대응하고 경쟁력을 유지할 수 있습니다.

비즈니스 분석가의 역할

비즈니스 분석의 범위가 매우 광범위하기 때문에 비즈니스 분석가는 비즈니스 분석의 범위를 구성하는 세 가지 활동 중 하나를 전문으로 하는 경향이 있어 왔습니다. 비즈니스 분석가의 주요 역할은 비즈니스 요구를 파악하고 요구 사항을 정의하는 것입니다. 그리고 비즈니스 문제에 대한 해결책을 제공하는 것은 다음 일련의 활동의 일부로 수행됩니다.

스트래티지스트
조직은 현대 비즈니스 세계에서 어느 정도 지속적인 전략적 문제에 초점을 맞출 필요가 있습니다. 비즈니스 분석가들은 이러한 요구에 부응하여 조직과 환경의 전략적 프로파일을 분석하고, 고위 경영진에게 적합한 정책과 정책 결정의 효과에 대해 조언하는 데 정통합니다.
건축가.
조직은 위에서 언급한 전략적 분석을 통해 파악된 비즈니스 문제를 해결하기 위해 변화를 도입해야 할 수도 있습니다. 비즈니스 분석가는 목표, 프로세스 및 리소스를 분석하고 재설계(BPR) 또는 개선(BPI)을 수행할 수 있는 방법을 제안함으로써 기여합니다. 이러한 유형의 분석가의 특정 기술은 비즈니스에 대한 지식, 요구 사항 엔지니어링, 이해 관계자 분석과 같은 "소프트 스킬" 및 비즈니스 프로세스 모델링과 같은 일부 "하드 스킬"입니다. 이 역할은 기술과 그 사용에 대한 인식이 필요하지만 IT 중심의 역할은 아닙니다.
비즈니스 분석 작업의 이러한 측면에는 핵심 비즈니스 프로세스의 재설계, 새로운 핵심 프로세스를 지원하는 기술의 적용, 조직 변화의 관리 등 세 가지 요소가 필수적입니다. 이러한 비즈니스 분석 측면을 BPI(Business Process Improvement) 또는 리엔지니어링(Reengineering)이라고도 합니다.
IT 시스템 분석가
IT 개발과 비즈니스 시스템 전반을 일치시킬 필요가 있습니다. 비즈니스의 오랜 문제는 일반적으로 매우 비용이 많이 들고 전략적으로 중요한 IT 투자에서 최상의 수익을 얻는 방법입니다. IT 부서는 문제를 인식하고 IT 시스템의 요구 사항을 보다 잘 이해하고 정의하기 위해 비즈니스 분석가 역할을 만드는 경우가 많습니다. 개발자와 테스트 역할이 겹치는 부분이 있을 수 있지만, 항상 변경 프로세스의 IT 부분에 초점을 맞추고 있으며, 일반적으로 이러한 유형의 비즈니스 분석가는 변경 사례가 이미 만들어지고 결정된 경우에만 참여합니다.

어쨌든, 분석가(즉, 문제 조사자)가 설계 작업(해결책 정의자)을 수행하는 한, 분석가라는[as of?] 용어는 최근 다소 오해의 소지가 있는 것으로 여겨집니다.[by whom?]

비즈니스 분석가의 주요 책임 분야는 고객의 소프트웨어 요구 사항을 대조하고 이해하며 비즈니스 관점에서 더 자세히 분석하는 것입니다. 비즈니스 분석가는 비즈니스와 협력하고 지원하며 비즈니스를 지원해야 합니다.[11]

조직구조 내의 기능

비즈니스 분석의 역할은 조직 프레임워크 내에서 다양한 구조로 존재할 수 있습니다. 비즈니스 분석가는 일반적으로 기업의 비즈니스 기능과 기술 기능을 연결하는 역할을 하기 때문에 종종 비즈니스 라인, IT 내에서 또는 때로는 둘 다에 맞춰 역할을 수행할 수 있습니다.[12]

사업정렬
비즈니스 분석가는 비즈니스 측면에서 일할 때 특정 비즈니스 라인의 대상 전문가인 경우가 많습니다. 이러한 비즈니스 분석가들은 일반적으로 특정 비즈니스의 프로젝트 작업에만 집중하여 교차 기능 프로젝트를 위해 다른 영역의 비즈니스 분석가들을 끌어들입니다. 이 경우에는 일반적으로 IT 측에 비즈니스 시스템 분석가들이 더 많은 기술적 요구사항에 초점을 맞추게 됩니다.
IT 정렬
대부분의 경우 비즈니스 분석가는 IT 내에서만 활동하며 프로젝트에 필요한 비즈니스 및 시스템 요구 사항에 초점을 맞추고 다양한 주제 전문가(SME)와 상담하여 철저한 이해를 보장합니다. 조직 구조에 따라 비즈니스 분석가는 특정 개발 연구소에 배치되거나 리소스 풀에서 그룹화되어 가용성과 전문 지식을 기반으로 다양한 프로젝트에 할당될 수 있습니다. 전자는 특정 주제 전문 지식을 구축하고 후자는 교차 기능 지식을 습득할 수 있는 능력을 제공합니다.
실천관리
대규모 조직에서는 변화의 질을 유지하고 조직의 변화에 따른 위험을 줄이기 위해 프레임워크를 정의하고 변화를 구현하는 과정 전반에 걸쳐 표준을 모니터링하는 우수성 중심 또는 실천 관리 그룹이 있습니다. 일부 조직에는 프로젝트 관리, 비즈니스 분석 또는 품질 보증과 같은 개별 스트림에 대한 독립적인 우수성 센터가 있을 수 있습니다.

업무 관리 팀은 일반적으로 프로세스, 절차, 템플릿 및 모범 사례로 구성된 조직의 모든 비즈니스 분석가가 작업을 수행하는 프레임워크를 제공합니다. 가이드라인 및 성과물 제공은 물론, 비즈니스 분석 기능의 지속적인 개선에 집중할 수 있는 포럼도 제공합니다.

목표들

궁극적으로 비즈니스 분석은 다음과 같은 결과를 얻고자 합니다.

  • 솔루션 생성
  • 강력한 프로젝트 관리를 위한 도구 제공
  • 효율성 향상 및 폐기물 감소
  • 프로젝트 개시 문서와 같은 필수 문서 제공

이러한 목표를 평가하는 한 가지 방법은 모든 프로젝트의 투자 수익률(ROI)을 측정하는 것입니다. Forrester Research에 따르면, 미국에서는 맞춤형 및 내부 개발 소프트웨어 프로젝트에 매년 1,000억 달러 이상이 지출되고 있습니다. 이러한 모든 소프트웨어 개발 프로젝트에는 정확한 데이터를 유지하는 것이 중요하며 비즈니스 리더들은 제안된 프로젝트나 활성화된 프로젝트가 끝날 때마다 반환 또는 ROI를 지속적으로 요청합니다. 그러나 값이 생성되거나 소멸되는 위치에 대한 충분한 데이터 없이 ROI를 요청하면 부정확한 투영이 발생할 수 있습니다.

낭비를 줄이고 프로젝트를 제때 완료

참고 항목: 프로젝트취소

프로젝트 지연은 다음과 같은 몇 가지 측면에서 비용이 많이 듭니다.

  • 프로젝트 비용 – 매달 지연될 때마다 프로젝트 팀의 비용과 비용이 계속 누적됩니다. 개발팀의 상당 부분이 아웃소싱이 되었을 때, 그 비용은 빠르게 쌓이기 시작할 것이고, 시간과 재료를 기준으로 계약이 이루어지면 매우 눈에 띕니다. 외부 당사자와의 고정 가격 계약은 이러한 위험을 제한합니다.[13] 내부 리소스의 경우, 인건비가 기본적으로 고정 비용이기 때문에 리소스가 소요하는 시간을 프로젝트에 대해 추적하지 않는 한 지연 비용이 쉽게 나타나지 않습니다.
  • 기회 비용 – 기회 비용은 수익 손실과 실현되지 않은 비용 절감이라는 두 가지 유형으로 나타납니다. 일부 프로젝트는 신규 또는 추가 수익을 수익으로 창출하기 위한 목적으로 특별히 수행됩니다. 매달 지연될 때마다 회사는 이 새로운 수익 흐름의 한 달을 포기합니다. 다른 프로젝트의 목적은 효율성을 개선하고 비용을 줄이는 것입니다. 다시 말하지만, 장애가 발생할 때마다 이러한 비용 절감의 실현이 한 달 더 연기됩니다. 대부분의 경우 이러한 기회는 포착되거나 분석되지 않기 때문에 ROI를 잘못 계산할 수 있습니다. 두 가지 기회 비용 중 손실된 수익이 가장 심각하며, 그 효과는 더 크고 오래 지속됩니다.

많은 프로젝트(특히 규모가 큰 프로젝트)에서 프로젝트 관리자는 프로젝트를 제 시간에 완료할 수 있도록 보장하는 책임이 있습니다. BA의 역할은 프로젝트가 제 시간에 완료되지 않으면 최소한 가장 우선순위가 높은 요구사항을 충족하도록 하는 것입니다.

올바른 요구 사항을 문서화합니다.

비즈니스 분석가들은 비즈니스 요구사항을 충족하는 방식으로 요구사항을 정의하려고 합니다. 예를 들어 IT 애플리케이션의 경우 최종 사용자의 요구사항을 충족하는 데 필요한 요구사항을 정의해야 합니다. 본질적으로, 그들은 올바른 애플리케이션을 정의하기를 원합니다. 즉, 고객의 피드백을 주의 깊게 듣고 프로그램을 작성할 기술 설계자와 코더에게 명확한 요구 사항의 전체 세트를 전달하여 올바른 요구 사항을 문서화해야 합니다. 비즈니스 분석가가 적절한 요구사항을 도출하는 데 도움이 되는 도구나 기술이 제한적일 경우, 사용되지 않거나 다시 작성해야 하는 요구사항을 문서화할 가능성이 상당히 높아집니다. 이로 인해 아래에서 설명하는 대로 재작업이 이루어집니다. 불필요한 요구 사항을 문서화하는 데 낭비되는 시간은 비즈니스 분석가에게 영향을 미칠 뿐만 아니라 개발 주기의 나머지 부분에도 영향을 미칩니다. 코더는 이러한 불필요한 요구사항을 수행하기 위해 응용프로그램 코드를 생성해야 하며 테스터는 원하는 기능이 실제로 문서화되고 코드화된 것처럼 작동하는지 확인해야 합니다. 전문가들은 새로운 소프트웨어 애플리케이션의 기능 중 10%에서 40%가 불필요하거나 사용되지 않는 것으로 추정하고 있습니다. 이러한 추가 기능의 양을 3분의 1까지 줄일 수 있으면 상당한 비용을 절감할 수 있습니다. 최소화 또는 단순하고 최소화된 기술의 접근 방식은 구현된 솔루션의 결과 및 유지 보수를 위한 비용 절감을 지원합니다.

프로젝트 효율성 향상

효율성은 재작업을 줄이고 프로젝트 기간을 단축하는 두 가지 방법으로 달성할 수 있습니다.

재작업은 일반적인 업계의 골칫거리이며, 많은 조직에서 재작업이 매우 보편화되어 종종 프로젝트 예산과 타임라인에 포함됩니다. 일반적으로 요구 사항이 불완전하거나 누락되어 오류를 수정하는 프로젝트에서 필요한 추가 작업을 말하며 정의에서 코딩 및 테스트에 이르기까지 소프트웨어 개발 전 과정에 영향을 미칠 수 있습니다. 요구사항 수집 및 정의 프로세스가 철저한지 확인하고 프로젝트의 비즈니스 및 기술 구성원이 이러한 프로세스에 초기 단계부터 참여하도록 함으로써 재작업의 필요성을 줄일 수 있습니다.

프로젝트 길이 단축은 두 가지 잠재적 이점을 제공합니다. 프로젝트를 단축할 수 있는 매월 프로젝트 리소스 비용을 다른 프로젝트로 전용할 수 있습니다. 이를 통해 현재 프로젝트의 비용을 절감하고 향후 프로젝트의 시작 시간을 단축할 수 있습니다(따라서 수익 잠재력을 높일 수 있습니다).

참고 항목

인용

  1. ^ Kathleen B Hass, Richard Vander Horst, Kimi Ziemski (2008). 분석가에서 리더로: 비즈니스 분석가 관리 개념의 역할 제고, 2008. ISBN1-56726-213-9. p94: "기업분석학의 학문이 전문화되면서"
  2. ^ 프로젝트 관리 연구소 2015, pp. 3-4, § 1.5.
  3. ^ "Business Analysis Body of Knowledge v3.0". IIBA. Retrieved 7 July 2023.
  4. ^ "What do Business Analysts do in Software Projects". CIO.com. Retrieved 2 November 2019.
  5. ^ "Heptalysis – The Venture Assessment Framework". Pejman Makhfi, VentureChoice, Inc. Retrieved 22 October 2005.
  6. ^ "Exploring Corporate Strategy Using M.O.S.T. Analysis". Strategy Consulting Ltd. Archived from the original on 12 April 2009. Retrieved 9 April 2009.
  7. ^ "Business Open Learning Archive". Chris Jarvis for the BOLA Project. Retrieved 9 April 2009.
  8. ^ "Business Analysis SCRS approach". Business-analysis NZ. Archived from the original on 5 May 2013. Retrieved 28 August 2012.
  9. ^ "Business Analysis Canvas, Roadmap To Effective BA Excellence". 10 August 2017.
  10. ^ "Essentials for Strategic Management in Business and How to Achieve Them - Doing With Ease". 2022-08-13. Retrieved 2022-12-24.
  11. ^ http://businessanalystmentor.com/2009/06/29/why-should-you-become-a-business-analyst/ 2015년 3월 12일 Wayback Machine http://news.dice.com/2013/06/13/5-steps-to-becoming-a-business-analyst/ 에서 아카이브됨
  12. ^ "THE BA'S TRAINING ROADMAP". IRM.
  13. ^ "Once you know, you know – UIR3". Retrieved 8 November 2020.

참고문헌

  • Project Management Institute (2015-01-01). Business Analysis for Practitioners. Project Management Inst. ISBN 978-1-62825-069-5.