가이드라인: 비즈니스 유스 케이스
비즈니스 유스 케이스는 비즈니스 프로세스를 정의합니다. 이 가이드라인은 비즈니스 유스 케이스를 개발하는 방법에 대해 설명합니다.
관계
기본 설명

설명

비즈니스 프로세스는 여러 가지 다양한 비즈니스 유스 케이스로서 정의되며 각 비즈니스 유스 케이스는 특정 비즈니스 워크플로우를 나타냅니다. 비즈니스 유스 케이스는 비즈니스 수행 과정을 정의하며 특정 비즈니스 액터에게 가치있는 결과를 생성하는 일련의 조치에 따른 성과에 대해 설명합니다. 비즈니스 프로세스는 비즈니스에 대한 가치를 생성하거나 비즈니스 비용을 감소시킵니다.  

함께 표시된 텍스트에서 설명되는 다이어그램.

승객은 개인 또는 그룹으로 여행을 할 수 있습니다. 그룹 여행을 하는 경우에는 여행 안내원이 동행하게 됩니다.

비즈니스 유스 케이스는 "개별 비즈니스 액터에게 관찰 가능한 가치가 있는 결과를 생성하는 일련의 비즈니스 조치"에 대해 설명합니다. 따라서 개별 액터 관점에서 볼 때 비즈니스 유스 케이스는 원하는 결과를 생성하는 완전한 워크플로우를 정의합니다. 이는 일반적으로 말하는 "비즈니스 프로세스"와 유사하지만 "비즈니스 유스 케이스"의 정의가 훨씬 정확합니다.

비즈니스 유스 케이스 개념의 정의에는 다음과 같이 비즈니스 유스 케이스를 이해하는 데 필요한 여러 가지 키워드가 포함됩니다.

  • 비즈니스 유스 케이스 인스턴스 - 위의 정의가 특정 비즈니스 워크플로우에 대한 정확한 정의입니다. 즉, 비즈니스 유스 케이스는 인스턴스로 이해해야 합니다. 실제로 여러 가지 워크플로우가 있지만 대부분이 매우 유사합니다.

유스 케이스 모델을 쉽게 이해할 수 있도록 작성하려면 유사한 워크플로우를 하나의 비즈니스 유스 케이스로 그룹화해야 합니다. 오브젝트 모델 관점에서는 이 비즈니스 유스 케이스가 "클래스"가 됩니다. 비즈니스 유스 케이스를 식별하고 설명하는 것은 개별 유스 케이스 인스턴스가 아닌, 클래스와 유사한 비즈니스 유스 케이스를 식별하고 설명하는 것입니다. 따라서 비즈니스 유스 케이스는 결정 지점 및 대체 플로우를 정의합니다. 이 때 해당 경로는 비즈니스 상태, 비즈니스 이벤트 및 비즈니스 액터의 입력에 따라 결정됩니다. 

  • 개별 액터 - 액터는 일반적으로 올바른 비즈니스 유스 케이스를 찾는 데 있어 가장 중요한 요소입니다. 개별 액터 또는 실제 액터 인스턴스에서 시작함으로써 규모가 너무 크거나 복잡한 비즈니스 유스 케이스를 피할 수 있습니다.

적합한 액터를 결정할 때는 먼저 해당 액터 역할을 수행할 수 있는 두세 명의 다른 사용자를 지명한 다음 각 개인에게 필요한 지원을 정확하게 평가합니다. 예를 들어, 먼저 "고객" 액터를 식별하는 것으로 가정합니다. 나중에 각 고객에게 필요한 지원을 평가할 때 세 명의 다른 고객, 즉 제품의 일반 "사용자", "구매자" 및 "평가자"를 찾을 수 있습니다. 이들은 제품과 경쟁자를 비교할 때 필요한 요소입니다. 이들 각각은 비즈니스에서 수행되는 다른 역할을 나타내므로 개별 비즈니스 유스 케이스가 필요합니다.

  • 관찰 가능한 가치가 있는 결과 - 이 표현은 비즈니스 유스 케이스의 올바른 범위를 결정하는 데 매우 중요합니다. 즉, 비즈니스 유스 케이스의 규모가 너무 적거나 너무 커서는 안됩니다. 비즈니스 유스 케이스가 관찰 가능한 가치가 있는 결과를 제공해야 한다는 의미를 고려함으로써 완전한 플로우를 찾고 규모가 너무 작은 비즈니스 유스 케이스는 피하게 됩니다. 해당 결과는 인지 가능하고 측정 가능한 것이어야 합니다.

올바른 비즈니스 유스 케이스는 액터가 식별 가능한 값을 갖고 있는 타스크를 수행하는 데 유용합니다. 성공적으로 수행한 비즈니스 유스 케이스에는 가치를 산정할 수 있습니다. 규모가 너무 작은 비즈니스 유스 케이스의 경우 범위가 제한적이므로 리엔지니어링 가능성도 거의 없습니다.

  • 비즈니스에서 - "비즈니스에서 수행되는 조치"라는 표현은 비즈니스가 비즈니스 유스 케이스를 액터에 제공한다는 의미와 비즈니스 유스 케이스가 실제로 비즈니스에서 수행되는 내용만 처리한다는 의미를 모두 갖고 있습니다. 다른 곳에서 수행된 작업에 대한 지원은 포함되지 않습니다.
  • 조치 - 조치는 비즈니스에 대한 액터 요청 또는 특정 시점에서 호출됩니다. 조치에는 내부 타스크 및 결정과, 호출된 액터 또는 기타 액터에 대한 요청이 포함됩니다.

비즈니스 유스 케이스는 대상 비즈니스 및 해당 외부 비즈니스 액터 간의 상호작용과 상호작용에 따른 비즈니스 영향을 지정합니다. 비즈니스 유스 케이스의 성능에 따라 비즈니스 상태가 변경될 수 있으며 이로 인해 비즈니스가 향후 이벤트 또는 상호작용에 대응하는 방식이 변경될 수 있습니다. 따라서 비즈니스 유스 케이스는 이러한 상태 변경사항을 지정해야 합니다.

비즈니스가 해당 환경에 직접적이고 명시적으로 제공하는 대상을 서비스라고 합니다. 이러한 관점에서 보면 비즈니스는 단지 최상위 레벨 비즈니스 시스템이므로 해당 자원을 캡슐화하고 해당 환경에 잘 정의된 서비스를 제공해야 합니다. 가이드라인: 비즈니스 시스템을 참조하십시오. 비즈니스 유스 케이스에서 설명한 것처럼 비즈니스 액터와 비즈니스 간의 상호작용은 하나 이상의 해당 서비스 호출을 통해 발생합니다. 새 비즈니스를 개발하는 경우(예: 비즈니스 작성) 또는 비즈니스를 변경하는 경우에는 비즈니스 유스 케이스로 비즈니스가 지원해야 하는 서비스를 식별할 수 있습니다.

수집한 비즈니스 유스 케이스 세트는 가능한 모든 비즈니스 사용 방법을 구성합니다. 또한 가이드라인: 비즈니스 유스 케이스 모델을 참조하십시오.

비즈니스 유스 케이스 대 비즈니스 유스 케이스 실현(realization)

유스 케이스 구동 비즈니스 모델링 프로젝트에서는 두 가지 비즈니스 보기를 개발합니다.

비즈니스 유스 케이스는 외부 비즈니스 보기를 나타내며 이 보기는 비즈니스가 액터에게 원하는 결과를 제공하기 위해 수행하는 데 중요한 내용을 정의합니다. 비즈니스 유스 케이스는 또한 비즈니스 유스 케이스 실행 시 필요한 비즈니스와 액터의 상호작용(비즈니스 액터-비즈니스 입력-응답 시퀀스)을 정의합니다. 이 보기는 각 비즈니스 유스 케이스에서 수행되는 내용을 결정하고 동의할 때 개발되어야 합니다. 비즈니스 유스 케이스 콜렉션은 비즈니스 파트별로 수행하는 내용과 그에 따른 예상 결과를 직원에게 알려주는 데 매우 유용한 비즈니스 개요를 제공합니다. 비즈니스 유스 케이스 설명은 비즈니스의 실제 내부 구조를 참조하지 않고 이 기능을 수행합니다. 비즈니스 유스 케이스는 또한 비즈니스 실행 시 발생하는 상태 변화와, 발생 또는 수신하는 중요한 비즈니스 이벤트에 대해 설명해야 합니다. 비즈니스 유스 케이스는 비즈니스 상태가 내부적으로 성립되고 유지보수되는 방식이나 비즈니스 이벤트를 내부적으로 전달하는 방식에 대해서는 설명하지 않습니다. 대신 필수 비즈니스 동작의 전체 보기를 나타낼 수 있는 상태 변경의 정의와 중요한 비즈니스 이벤트에 대한 정의를 지정합니다.

반면에 비즈니스 유스 케이스 실현(realization)은 원하는 동일한 결과를 달성할 수 있도록 작업을 구성하고 수행하는 방식을 정의하는 비즈니스 유스 케이스의 내부 보기를 제공합니다. 실현(realization)에는 비즈니스 유스 케이스 실행에 참여하는 비즈니스 작업자와 비즈니스 엔티티 및, 작업 수행에 필요한 작업자와 엔티티 간 관계가 포함됩니다. 원하는 결과를 달성하기 위해 각 비즈니스 유스 케이스의 작업을 구성하는 방식을 결정하고 동의하려면 이 보기를 개발해야 합니다. 비즈니스 디자이너는 비즈니스 상태 변경사항 및 비즈니스 이벤트에 대해 비즈니스 유스 케이스의 명세(내용)와 비즈니스 유스 케이스 실현(realization)의 실현(방식) 간의 일치하는 맵핑을 유지함으로써 모든 비즈니스 유스 케이스에서 원하는 동작을 달성합니다.

비즈니스 유스 케이스 보기는 둘 다 주로 비즈니스 내의 작업자를 대상으로 합니다. 즉, 외부 보기는 비즈니스 유스 케이스 외부의 작업자를 위한 것이며 내부 보기는 비즈니스 유스 케이스 내부 작업자를 위한 것입니다.

비즈니스 유스 케이스의 클래스 및 인스턴스

비즈니스 운영에 따라 거의 무제한의 별도의 워크플로우를 식별할 수 있게 됩니다. 유스 케이스 인스턴스는 특정 워크플로우 또는 시나리오로서, 여러 협업 비즈니스 구성원이 오브젝트 모델에 정의된 해당 역할에서 수행하는 작업에 해당하며 특정 비즈니스 구성원 또는 해당 구성원이 수행하는 역할과는 관련이 없습니다.

비즈니스 유스 케이스는 세부 설명 대신 유스 케이스 모델을 쉽게 이해할 수 있도록 만들기 위해 사용합니다. 따라서 동일하지는 않더라도 유사한 여러 비즈니스 유스 케이스 인스턴스의 유니온을 워크플로우로 나타냅니다.

일반적으로, 특정 역할을 훌륭하게 수행하는 직원은 여러 가지 다른 비즈니스 유스 케이스의 인스턴스에서도 같은 역량을 나타냅니다.

예제:

공항 탑승 수속 카운터의 경우, 개별 탑승 수속 비즈니스 유스 케이스와 그룹 탑승 수속 비즈니스 유스 케이스 모두 탑승 수속 카운터 직원의 동일한 업무 능력이 필요하며 특정 출발과 관련된 동일한 정보에 액세스해야 합니다. 따라서 두 가지 유스 케이스 모두 동일한 탑승 수속 직원 비즈니스 작업자 및 출발 엔티티를 사용하여 디자인해야 합니다.

비즈니스 유스 케이스의 범위

때때로 특정 서비스가 하나 또는 여러 비즈니스 유스 케이스로 구성되는지 여부를 결정하기 어려운 경우가 있습니다. 예를 들어, 공항 탑승 수속 프로세스에 비즈니스 유스 케이스 정의를 적용할 수 있습니다. 승객이 항공권과 수화물을 탑승 수속 직원에게 제시하면 직원은 승객의 좌석을 확인한 후 탑승권을 인쇄하고 수화물 처리를 시작합니다. 승객이 일반 수화물을 소지한 경우 탑승 수속 직원은 수화물표와 고객 수화물 교환증을 인쇄한 후 해당 수화물에 꼬리표를 붙이고 탑승권과 함께 고객 수화물 교환증을 승객에게 전달하여 비즈니스 유스 케이스를 종료합니다. 수화물 모양이 특이하거나 특수한 내용물이 들어 있어 일반적인 방법으로 운송할 수 없는 경우 승객이 직접 특수 수화물 카운터로 가져가야 합니다. 수화물이 적정 중량을 초과하는 경우에는 항공사 발권 사무실로 가 해당 금액을 지불해야 합니다. 탑승 수속 직원은 비용 처리를 할 수 없기 때문입니다.

탑승 수속 카운터, 특수 수화물 카운터 및 발권 사무실에 각각 다른 비즈니스 유스 케이스가 필요합니까? 또는 단일 비즈니스 유스 케이스만 필요합니까? 물론 이 트랜잭션에는 세 가지 다른 유형의 조치가 포함됩니다. 그러나 문제는 특정 비즈니스 유스 케이스가 특수 수화물을 갖고 있는 승객에게만 중요한가 하는 것입니다. 실제로는 승객이 처음 탑승 수속 카운터로 가서 추가 비용을 지불할 때까지가 해당 승객에게 의미있는 전체 프로시저입니다. 따라서 서로 다른 세 가지 카운터가 포함되는 전체 프로시저가 하나의 비즈니스 유스 케이스가 됩니다.

이 기준 이외에도 서로 밀접한 관련이 있는 서비스에 대한 설명을 함께 보관함으로써 각 서비스를 동시에 검토하고 함께 수정, 테스트할 수 있으며 해당 매뉴얼을 작성하고 단일 유닛으로 관리할 수 있습니다.

또한 두 개의 독립 비즈니스 유스 케이스의 시작이 유사한 경우도 있음에 유의해야 합니다.

예제:

보험 회사의 경우 청구 처리 비즈니스 유스 케이스와 요청 처리 비즈니스 유스 케이스는 특정 액터가 청구 담당자와 접촉하는 시점부터 시작됩니다. 청구 담당자와 액터는 액터가 보험금을 청구하는 것인지 또는 특정 정보를 요청하는지 여부를 명확히 하기 위해 일부 정보를 교환합니다. 해당 여부를 명확히 해야 수행할 비즈니스 유스 케이스를 결정할 수 있습니다. 여기서 두 비즈니스 유스 케이스의 시작은 유사하지만 서로 관련은 없습니다.

이름

비즈니스 유스 케이스의 이름은 비즈니스 유스 케이스 인스턴스가 수행될 때 발생하는 내용을 나타내야 합니다. 따라서 이름 양식은 능동형으로서, 일반적으로 동명사(Checking-in) 또는 동사와 명사를 함께 사용하여 설명합니다.

이름은 외부 또는 내부 시점에서 비즈니스 유스 케이스의 타스크를 설명할 수 있습니다(예: 주문 제출, 주문 수신). 비즈니스 유스 케이스는 비즈니스에서 일어나는 일에 대해 설명하지만 해당 이름은 주요 액터 관점에서 지정하는 것이 바람직합니다. 상황에 따라 원하는 스타일을 결정하면 비즈니스 모델의 모든 비즈니스 유스 케이스에 대해 동일한 규칙을 적용해야 합니다.

목적

비즈니스 유스 케이스의 목적은 적어도 다음 두 가지 관점에서 지정해야 합니다.

  • 비즈니스 프로세스와 상호작용하는 비즈니스 액터의 경우 해당 비즈니스 액터가 비즈니스에서 예상하는 가치를 지정합니다(외부 목적). 
  • 비즈니스 프로세스를 수행하는 조직의 관점에서는 해당 비즈니스 프로세스의 목표와 프로세스 수행을 통해 달성하고자 하는 내용을 정의합니다(내부 목적). 

성능 목적

다음은 몇 가지 공통 메트릭 카테고리에 대한 설명입니다. 

  • 시간 - 전체 워크플로우 또는 워크플로우 일부를 실행하는 데 소요되는 예상 시간 
  • 비용 - 전체 워크플로우 또는 워크플로우 일부를 실행하는 데 필요한 예상 비용
  • 품질 - 예: "제품 프로덕션 라인에서 결함율은 2% 미만이어야 합니다."

가장 중요한 과제는 측정과 관련된 시나리오(비즈니스 유스 케이스 인스턴스)를 이해하는 것입니다. 사용할 기준은 시나리오 빈도 또는 시나리오와 비즈니스의 관련성입니다. 워크플로우의 특정 파트가 중요한 경우 해당 서브플로우의 비용 또는 시간만 측정하여 불필요한 노력을 줄일 수 있습니다. 

워크플로우 - 구조

대부분의 워크플로우는 여러 서브플로우로 간주되며 이러한 서브플로우가 함께 모여 전체 플로우를 형성합니다. 때때로 특정 비즈니스의 여러 비즈니스 유스 케이스가 공통 서브플로우를 갖거나 특정 비즈니스 유스 케이스의 서로 다른 파트에 동일한 서브플로우가 나타나기도 합니다. 이 공통 동작의 볼륨이 큰 경우 동일한 비즈니스 작업자가 수행해야 합니다.

서브플로우의 볼륨이 크고 여러 비즈니스 유스 케이스에 공통적이며 본질적으로 독립적인 분리된 파트를 구성하는 경우, 해당 동작이 별도 비즈니스 유스 케이스로 파티션되면 모델이 보다 명확해질 수 있습니다. 이 새 비즈니스 유스 케이스는 원래 유스 케이스(가이드라인: 비즈니스 유스 케이스 모델의 포함 관계 참조), 확장 유스 케이스(가이드라인: 비즈니스 유스 케이스 모델의 확장 관계 참조) 또는 해당 상위 유스 케이스(가이드라인: 비즈니스 유스 케이스 모델의 유스 케이스 일반화 참조)에 포함됩니다.

예제:

공항 탑승 수속 카운터의 경우, 개별 탑승 수속 비즈니스 유스 케이스와 그룹 탑승 수속 비즈니스 유스 케이스 모두 동일한 프로시저를 사용하여 개인 승객의 수화물을 처리합니다. 이 서브플로우는 항공권 처리와 무관하지만 논리적으로는 관련이 있으므로 수화물 처리 비즈니스 유스 케이스에 별도 모델링됩니다.

비즈니스 유스 케이스의 워크플로우는 활동 다이어그램을 사용하여 시각화할 수 있습니다. 가이드라인: 비즈니스 유스 케이스 모델의 활동 다이어그램을 참조하십시오.

비즈니스 유스 케이스 워크플로우에 대한 설명 및 구조화에 대한 자세한 정보는 가이드라인: 유스 케이스에서 이벤트 플로우에 대한 설명을 참조하십시오.

워크플로우 - 예

다음은 각 개별 고객에게 맞게 구성된 솔루션을 판매하는 조직의 제안 프로세스 비즈니스 유스 케이스 워크플로우에 대한 설명입니다. 기법: 비즈니스 유스 케이스 모델의 활동 다이어그램의 사용 예제 섹션에서 이 워크플로우 구조를 보여주는 활동 다이어그램 예제를 제공합니다.

1. 기본 워크플로우

1.1. 최초 접촉

이 프로세스는 고객과 회사가 처음 접촉할 때 시작되며 다음 중 한 가지 방식으로 진행됩니다.

  • 고객이 질의 또는 일련의 요구사항을 전달하기 위해 회사와 접촉합니다.
  • 회사는 고객에게 가치를 추가하고 회사에는 수익을 창출할 수 있는 제품이 있음을 확인합니다.

회사가 다음 정보를 얻기 위해 고객과 상호작용합니다.

  • 고객측 담당자
  • 회사측 담당자
  • 새 고객 여부
  • 이 계약과 관련한 제안 또는 입찰 상황에 대한 모든 중요 정보

1.2. 초기 기회 작업

이 섹션의 주요 목적은 다음 두 가지입니다.

  • 고객 요구사항 수집
  • 이 기회에 대한 추가 조치 결정

예비 고객 요구사항 수집, 판매 계획 작성(선택사항) 및 기회 분석 수행 단계는 반복 수행할 수 있으며 동시에 수행될 수도 있습니다.

1.2.1 예비 고객 요구사항 수집

다음을 수행하여 제품 요구사항 및 고객 비즈니스 요구사항을 모두 수집하십시오.

  • 고객에게 질문
  • 고객 입력 여부 확인
  • 예비 사이트 조사 수행(선택사항)
  • 사용 가능한 모든 고객 정보 확인

전체 요구사항 세트는 다음으로 구성됩니다.

  • 기술 선택사항(고객이 대안 조사를 원하는 경우 복수 선택 가능)
  • 제품 선호사항
  • 기능적 요구사항(시장 분석)
  • 빌드 구조 및 환경 특성
  • 인구 통계학적 특성
  • 이동성/용량
  • 네트워크 성장 예상
  • 설치된 기본 정보
  • 시간대
  • 서비스 요구사항
  • 가격 요구사항

1.2.2 판매 계획 작성(선택사항)

회사는 고객과의 협의를 통해 고객 요구사항을 충족시키는 솔루션 제안 방법을 결정합니다. 이렇게 작성된 내용을 판매 계획이라고 하며 여기에는 잠재적 솔루션의 네트워크 및 전환 특성이 포함됩니다. 또한 회사의 전략적 위치 지정과 네트워크에 대한 논의로 미래 요구를 준비할 수 있습니다.
이 판매 계획은 정확성과 완전성을 기하기 위해 고객이 검토합니다. 검토를 마친 계획은 전체 제안 프로세스에서 제안할 제품, 시장 패키지 및 품목과, 제안 통합 시 필요한 가정을 결정할 때 안내서로서 사용합니다.

1.2.3 기회 분석 수행

회사는 잠재 솔루션에 대한 상위 레벨 가격 및 비용 정보를 수집합니다. 이는 고객에게 정확한 비용 정보를 제공하는 것이 아닌 해당 기회의 잠재적 가치를 이해하기 위한 작업입니다.
다음으로 회사는 고객 요구사항을 검토하여 다음 사항을 판별합니다.

  • 기회의 위험성(제품 가용성, 경쟁 및 고객 위험성)
  • 수익 대비 비용
  • 기회 유형(단순, 복잡 등)
  • 판매 가능성
  • 예상 판매 규모
  • 예상 스케줄

회사는 이 평가에 따라 기회를 계속 진행할지 여부를 결정합니다.

1.3. 제안 프로젝트 계획 작성

회사는 제안 작성 및 제출 계획을 작성합니다. 이 계획에는 제안의 각 파트를 완료하는 개인에 대한 지정이 포함됩니다.

1.4. 전달 프로젝트 계획 작성

회사는 다음 기준에 따라 솔루션 전달을 위한 임시 프로젝트 계획을 개발합니다.

  • 고객 요구사항 시간대
  • 자원 가용성
  • 팩토리 용량
  • 신제품 가용성
  • 써드파티 제품 가용성

이 프로젝트 계획은 향후 팩토리 계획에 사용됩니다.
또한 이 프로젝트 계획은 견적 프로세스에서 갱신되고 수정됩니다.

1.5. 견적 준비

이 플로우는 포함된 견적 프로세스 비즈니스 유스 케이스에서 자세히 정의됩니다.
견적 프로세스를 실행하면 다양한 레벨의 확실성을 가진 엔지니어링 솔루션이 가격과 함께 개발됩니다.

1.6. 추가 정보 컴파일

회사는 조회에 응답하기 위해 정보를 컴파일합니다. 조회는 일반적으로 향후 제품 개발에 대한 내용이며 고객 비즈니스 요구사항에 포함될 수 있습니다. 여기에는 또한 고객이 반드시 알아야 할 정보가 포함됩니다. 일반적인 조회 유형은 다음과 같습니다.

  • 기술
  • 현재 기능
  • 향후 기능
  • 표준 준수
  • 향후 표준 준수
  • 현재 제공되는 서비스
  • 향후 제공될 서비스

1.7. 제안 분석 및 종결

회사는 다음 항목을 포함하는 제안을 컴파일합니다.

  • 견적
  • 마케팅 자료(기존 자료)
  • 제품 정보(기존 정보)
  • 재무 조건
  • 스케줄 정보
  • 재무 분석을 제안 레벨로 롤업
  • 고객 및 회사의 불이익 및 책임
  • '환경'의 법적인 의미
  • 제안 솔루션 작성 시 모든 가정사항

1.8. 제안 제출

회사는 위의 정보를 고객에게 제시/제안합니다.

1.9. 고객 결정 얻기

고객이 제안에 대한 피드백을 제공합니다. 회사는 제안의 견적 내용에 대해 고객의 동의를 얻습니다. 동의 형식은 솔루션 특성 및 고객에 따라 다르며
일반적으로 다음과 같이 구성됩니다.

  • 서명한 구매 주문
  • 고객이 구매 주문을 제출할 것이라는 구두 합의
  • 서명한 계약서
  • 구두 합의
  • 결정사항이 없거나 유효 기간이 만기되면 부정적인 결정이 발생합니다.

2. 대체 워크플로우

2.1. 비즈니스 기회 거부

1.2. 단계에서 비즈니스 기회가 거부된 것으로 판명되면 다음 조치를 수행할 수 있습니다.

  • 완전 거부
  • 다른 공급자와의 합작 투자 시도
  • 다른 영역으로의 방향 선회
  • 다른 분배업자/공급자에게 요청 전달
  • 고객 요구사항 변경 시도

2.2. 고객 요구사항 충족 불가능

기회 분석 수행 또는 견적 준비에서 회사가 고객 요구사항에 맞는 솔루션을 제안할 수 없는 경우, 다음 조치를 수행할 수 있습니다.

  • 다른 제조업체 장비 제안
  • 고객 요구사항 재평가
  • 회사에 문의하여 향후 제품에 대한 정보 수집
  • 고객 요구사항 변경 시도
  • 신제품 개발 결정
  • 합작 투자 또는 공급자 찾기
  • 대체 재무 양식 찾기
  • 다른 할인 정책 적용

2.3. 알려지지 않은 중요 정보

제안 프로세스에서 알려져 있지 않거나 사용할 수 없는 중요한 정보를 식별하면 회사가 다음 중 한 가지 조치를 수행합니다.

  • 정보 얻기
  • 가정 후 프로세스 계속 진행

가정사항을 작성하면 기록한 후 제안의 첨부 문서로 고객에게 전달합니다.

2.4. 새로 작성하여 불완전하거나 정확하지 않은 일반 고객 프로파일

회사에서 몇 가지 이유로 일반 고객 프로파일이 부정확한 것으로 판별되면 다음 조치를 수행할 수 있습니다.

  • 새 고객의 경우 계약에 대해 협상합니다.
  • 고객 선호사항을 포함/판별합니다.
  • 설치 기반을 판별합니다.
  • 레코드 갱신을 요청합니다.

가능성

비즈니스 유스 케이스의 가능성은 프로세스상의 해당 비즈니스 유스 케이스 및 규모에 대한 실제 개선 가능성을 반영해야 합니다. 비즈니스 유스 케이스에 대해 지정한 메트릭을 참조하십시오. 

확장점

확장점은 비즈니스 유스 케이스의 확장성을 나타냅니다. 확장점에는 이름이 지정되고 비즈니스 유스 케이스의 워크플로우 내 하나 이상의 위치를 참조합니다.

또한 가이드라인: 비즈니스 유스 케이스 모델의 확장 관계를 참조하십시오.

올바른 비즈니스 유스 케이스의 특성

  • 해당 이름 및 간략한 설명은 비즈니스 모델링 팀의 외부 구성원도 쉽게 이해할 수 있도록 명확해야 합니다.
  • 각 비즈니스 유스 케이스는 외부 액터의 관점에서 완성됩니다. 예를 들어, 보험 회사의 청구 처리 비즈니스 유스 케이스는 고객이 보험금을 청구할 때 시작됩니다. 청구 처리 비즈니스 유스 케이스는 고객에 대한 보험 회사의 결정에 대한 알림과 보상 지불이 포함되어야 완성됩니다.
  • 각 비즈니스 유스 케이스는 일반적으로 하나 이상의 액터와 연관됩니다. 비즈니스 유스 케이스는 액터에 의해 시작되며 액터와의 상호작용을 통해 타스크를 수행하고 결과를 전달합니다.
  • 지원 유스 케이스가 액터와 상호작용하지 않을 수도 있지만 일반적인 경우는 아닙니다*. 이는 비즈니스 유스 케이스가 내부 이벤트에 의해 시작되어 해당 타스크를 수행하기 위해 액터와 상호작용하지 않아도 되는 경우에 해당됩니다.

*이는 유스 케이스의 UML 정의에 반하는 것으로 보일 수도 있지만 가이드라인: 비즈니스 유스 케이스 모델에서 '내부 비즈니스 유스 케이스'에 대해 설명하는 섹션을 참조하면 이해할 수 있습니다.

올바른 워크플로우 설명의 특성

  • 비즈니스 모델링 팀의 외부 구성원도 쉽게 이해할 수 있도록 명확해야 합니다.
  • 비즈니스 유스 케이스의 목적 이외에 워크플로우에 대해 설명합니다.
  • 비즈니스와 관련이 있는 타스크에 대해서만 설명합니다.
  • 비즈니스 유스 케이스의 가능한 모든 타스크에 대해 설명합니다. 예를 들어, 조건이 충족되는 경우와 충족되지 않는 경우에 일어나는 일에 대해 모두 설명합니다.
  • 커뮤니케이션하지 않는 액터는 언급하지 않습니다. 다른 액터를 언급하는 경우 설명을 이해하고 유지보수하기 어렵습니다.
  • 병렬로 수행되는 다른 비즈니스 유스 케이스에서 수행되는 타스크가 아닌 해당 비즈니스 유스 케이스에 속하는 타스크에 대해서만 설명합니다.
  • 관련이 없는 다른 비즈니스 유스 케이스는 언급하지 않습니다. 비즈니스 유스 케이스를 시작하기 위해 특정 결과가 비즈니스에 필요한 경우 해당 내용을 전제 조건으로 명시해야 합니다. 이 전제 조건에는 해당 결과가 작성된 비즈니스 유스 케이스에 대한 참조가 포함되어서는 안됩니다.
  • 비즈니스 유스 케이스에 대해 설명된 타스크 순서가 고정되어 있지 않은지 여부를 표시합니다.
  • 쉽게 읽고 이해할 수 있도록 구성되어야 합니다.
  • 설명은 워크플로우의 시작과 끝에 대해 명확히 설명합니다.
  • 각 확장 관계를 명확히 설명하여 비즈니스 유스 케이스의 삽입 방법 및 시기를 명시합니다.

올바른 추상 비즈니스 유스 케이스의 특성

  • 일정 규모를 유지해야 합니다. 즉, 구체적 비즈니스 유스 케이스는 해당 추상 비즈니스 유스 케이스와 함께 쉽게 읽을 수 있어야 합니다. 따라서 추상 비즈니스 유스 케이스의 규모가 너무 작아서는 안됩니다. 추상 비즈니스 유스 케이스의 규모가 너무 작은 경우 제거해야 하며 해당 타스크는 영향받는 구체적 비즈니스 유스 케이스에서 설명해야 합니다.
  • 논리적으로 관련이 있는 타스크를 포함합니다.
  • 특정 이유가 존재해야 합니다. 추상 비즈니스 유스 케이스에는 세 가지 유형의 타스크, 즉 여러 비즈니스 유스 케이스에서 공통적인 타스크, 선택적인 타스크 또는 모델에서 강조해야 하는 중요한 타스크 중 하나 이상이 포함되어야 합니다.