타스크: 대상 조직 평가
이 타스크는 조직의 현재 상태를 평가하고 현재 프로세스, 도구, 직원 스킬 및 시장 환경 관점에서 설명하는 방법에 대해 설명합니다.
목적
  • 현재 프로세스, 도구, 구성원의 역량, 구성원의 태도, 고객, 경쟁자, 기술 동향, 문제점 및 개선 영역의 관점에서 응용프로그램을 배치할 조직의 현재 상태 설명
  • 대상 조직을 엔지니어링해야 하는 이유에 대한 동기 부여
  • 비즈니스 모델링 노력의 이해 당사자(stakeholder) 식별  
관계
역할기본: 추가: 지원:
출력
기본 설명

비즈니스 모델링에 있어 가장 효율적인 경로를 선택하려면 해당 인원, 프로세스 및 도구 관점에서 대상 조직의 현재 상태를 이해해야 합니다. 이 타스크의 목적은 문제점 영역 및 개선 가능성과, 외부 문제에 대한 정보(예: 경쟁자 또는 시장 동향)를 이해하는 것입니다. 이 타스크를 완료하면 다음 정보를 얻을 수 있게 됩니다.

  • 대상 조직의 현재 상태
  • 인원 유형, 역량 레벨, 스킬 및 동기
  • 현재 대상 조직에서 사용되는 비즈니스 도구
  • 현재 비즈니스 프로세스에 대한 설명과 이해 레벨 
  • 개선의 가능성이 가장 높은 영역 

현재 상태를 평가하는 이유는 다음과 같습니다.

  • 수행할 비즈니스 모델링 시나리오(개념: 비즈니스 모델링 범위 참조)를 선택할 수 있습니다.
  • 가장 먼저 고려해야 하는 영역을 식별할 수 있습니다. 
  • 필요한 경우 대상 조직에서 프로세스, 도구 및 인원을 변경해야 하는 동기를 부여할 수 있습니다.
  • 변경에 따른 직접 또는 간접적 영향을 받게 될 대상 조직의 인원에게 동기를 부여하고 이해를 공유할 수 있습니다.

이 타스크는 비즈니스 엔지니어링을 위해 비즈니스 모델링을 수행하는 경우에만 가치를 추가할 수 있습니다. 시스템 요구사항을 도출하기 위해 기존 조직의 차트를 빌드하는 경우라면 전체 평가가 필요하지 않습니다. 또한 개념: 비즈니스 모델링 범위를 참조하십시오. 

단계
평가 시작

평가는 현재까지 알려져 있는 핵심 이해 당사자(stakeholder)를 대상으로 한 워크샵을 개최함으로써 시작하는 것이 바람직합니다. 이러한 초기 워크샵의 기본 목적은 비즈니스 분석가로 하여금 비즈니스 모델링 노력의 이해 당사자를 만나게 하는 것과 프로젝트 이해 당사자로부터 포괄적인 문제점 목록을 수집하는 것입니다. 초기 워크샵 수행 방법에 대한 세부사항은 기법: 평가 워크샵을 참조하십시오.

이해 당사자(stakeholder) 식별

비즈니스 모델링 노력의 이해 당사자를 식별하십시오. 또한 다음과 같은 대상 조직 외부의 이해 당사자를 식별하십시오.

  • 고객: 고객은 누구입니까? 출시 시간, 기능, 보안, 견고성 및 안전성과 복잡도 측면에서 고객의 제품에 대한 요구사항은 무엇입니까?
  • 경쟁자: 경쟁자는 누구입니까? 경쟁자가 우위를 점하고 있는 영역은 어디입니까? 경쟁자로부터 배울 수 있는 것은 무엇입니까?
  • 기타 이해 당사자. 다른 관련 이해 당사자가 있습니까? 공급자 및 파트너와 관련이 있습니까? 이들과의 관계에 문제점이 있습니까? 예기치 않은 상황을 피하기 위해 지속적으로 관리해야 하는 영향력과 의견을 보유하고 있는 인원이 있습니까?

다음과 같은 대상 조직 내 이해 당사자를 식별하십시오.

  • 프로젝트 관리자
  • 영업 사원
  • 고객 대표
  • 마케팅 담당자

대상 조직에 대한 각 이해 당사자(대표)의 기대를 확인하십시오. 이 작업은 평가 워크샵의 일부로 또는 질문지 양식으로 수행할 수 있습니다. 

인터뷰를 통해 변경에 대한 인원의 태도를 파악하십시오. 변경에 대해 부정적이거나 회의적인 경우 부정적 태도를 긍정적 태도로 변화시키지 않으면 변경을 성공적으로 수행할 수 없습니다.

고객의 현재 및 미래 기대를 분석하고 이를 정량화해야 합니다. 고객의 기대를 가정해서는 안되며 고객으로부터 직접 정보를 얻어야 합니다. 고객을 공식, 비공식적으로 인터뷰하거나 텔레마케팅과 같은 시장 조사 기법을 사용할 수 있습니다.

대상 조직의 구조 설명

조직의 구조, 역할, 현재 구성 팀에 대해 간략히 설명하십시오. 또한 대상 조직의 다른 파트 간 관계를 파악하십시오. 예를 들어, 영업과 유지보수, 또는 제품 개발과 영업의 관계를 조사하십시오.

이러한 정보를 나타내기 위해 비즈니스 모델링 표기법을 사용할 수도 있지만 그보다는 이해 당사자에게 익숙한 설명 스타일(텍스트, "조직도" 또는 UML(Unified Modeling Language))을 사용하는 것이 보다 효과적입니다. 

핵심 인원 식별

대상 조직의 핵심 인원을 식별하십시오. 핵심 인원은 다음과 같은 특성을 갖고 있습니다.

  • 조직 상황에 정통합니다.
  • 조언자 역할을 수행할 수 있습니다.
  • 특정 영역의 전문가입니다.
  • 비즈니스 모델링 노력에 반대합니다.
  • 예산을 책임지고 있습니다.

비즈니스 엔지니어링 노력을 성공으로 이끌기 위해서는 이러한 핵심 인원의 참여가 필요하며 다음과 같이 활용할 수 있습니다.

  • 나머지 평가 단계에 정보 수집을 위해 참여
  • 대상 조직의 변경사항을 식별하는 데 도움을 주는 전문가
  • 파일럿 프로젝트에 대한 컨트리뷰션 및 조언자로서의 역할

참고: 효과적인 새 조직의 구현이 아닌 비즈니스 모델링의 원칙에 대해 논의하려는 인원에 주의를 기울어야 합니다.

비즈니스 아이디어 및 비즈니스 전략 평가

대부분의 조직은 비즈니스 아이디어와 전략을 잘 문서화하고 있습니다. 따라서 "가상" 대상 조직을 문서화하는 경우(즉, 보다 나은 제품을 빌드하기 위해 비즈니스 모델링을 수행함으로써 대상 고객의 비즈니스 프로세스를 이해하려는 경우)에는 이 단계를 제외할 수 있습니다. 

전략을 검토하여 다음 사항을 평가하십시오.

  • 현재 프로세스가 전략과 일치하는지 여부 
  • 조직 인원이 전략을 이해할 수 있을 정도로 구체적인지 여부 
  • 전략의 측정 가능 여부 
  • 전략이 현실적으로 인지되는지 여부 

자세한 정보는 또한 중간 산출물 가이드라인: 대상 조직 평가를 참조하십시오. 

벤치마킹

다음 사항을 결정하십시오.

  • 벤치마킹 대상: 세부적인 벤치마킹 노력을 수행하려는 경우 경쟁자가 아니더라도 유사한 점이 많은 대상을 찾아야 합니다. 
  • 벤치마킹에 사용할 메트릭: 관련 메트릭은 일반적으로 시간, 비용 및 품질의 조합입니다. 
  • 벤치마킹 수행 방법: 다른 조직과 파트너쉽을 갖는지 또는 공용 정보만을 참조하는지 여부

자세한 정보는 또한 중간 산출물 가이드라인: 대상 조직 평가를 참조하십시오. 

대상 조직 측정

조직을 측정하는 것은 해당 비즈니스 프로세스를 이해하고 측정하는 것이며 다음 사항을 고려해야 합니다.

  • 고객이 인지하는 메트릭(예: 전달 시간의 정확성)과 내부적으로 인지되는 메트릭(예: 프로덕션 비용)이 잘 조합된 메트릭 세트를 정의하여 사용하십시오. 

  • 메트릭을 수집할 대상을 결정하십시오. 

  • 효과적인 메트릭 수집 방법을 정의하십시오. 이 방법은 쉽고 가능한 "방해"가 되지 않는 방법이어야 합니다. 그렇지 않은 경우 인원의 참여를 얻을 수 없습니다.  

자세한 정보는 중간 산출물 가이드라인: 대상 조직 평가를 참조하십시오. 

기본 변경 이유 식별

이해 당사자(stakeholder)에게 비즈니스 프로세스 및 비즈니스 도구를 변경하려는 이유에 대해 물어보십시오. 다음은 이들의 일반적인 응답으로서 비즈니스 프로세스를 찾아 새로 도입하는 방법에 영향을 줍니다.

  • "이 신 기술을 사용하고 싶지만 업무 수행에 어떠한 영향을 주는지 알아야 합니다."
    한 예로 전자상거래 웹 사이트를 구축하기로 결정한 회사를 들 수 있습니다. 대부분의 경우 이에 대한 가장 효과적인 접근 방식은 이러한 변화를 기존 비즈니스 프로세스 세트의 변경이 아닌 새로운 비즈니스 분야로 간주하는 것입니다. 
  • "경쟁력 확보를 위해 기존의 비즈니스 프로세스를 보다 효과적으로 만들어야 합니다."
    이러한 경우 다음과 같은 몇 가지 질문을 통해 원하는 효율성 수준을 이해해야 합니다, 즉, 약간의 개선을 원하는지 또는 주요 재작업과 많은 새로운 유형의 기술 지원이 필요한지 여부를 확인해야 합니다. 또한 경쟁자가 누구인지 비교를 위해 사용되는 메트릭은 무엇인지 파악해야 합니다. 
  • "레거시 시스템에 오류가 많아 더 큰 문제가 발생하기 전에 바꿔야 합니다." 이러한 경우에도 역시 몇 가지 질문을 통해 비즈니스 프로세스의 변경 여부에 대한 기대를 파악해야 합니다. 프로세스 변경을 원하지 않는 경우에는 몇 가지 상위 레벨 비즈니스 모델링을 수행하여 현재 조직의 맵을 파악하는 접근 방식을 사용할 수 있습니다(도메인 모델만으로 충분할 수 있음). 
변화 역량 예상

대상 조직의 변화 역량을 분석하십시오. 개인과 마찬가지로, 조직은 제한된 범위의 변경사항만을 수용할 수 있습니다. 특정 조직은 다른 조직에 비해 변화에 보다 잘 대비할 수 있습니다. 변화에 대한 조직의 역량을 이해하려면 조직 인원을 대상으로 한 인터뷰를 통해 변화에 대한 태도와 의지를 파악해야 합니다.

다음 사항을 고려하십시오.

  • 현재 조건에 대한 우려의 분위기가 있는지 여부 - 이러한 경우 제안된 변경사항이 개선을 위한 노력으로 인식되지만 필요한 조사가 올바르게 수행되지 않는 위험성이 있습니다. 
  • 변화에 대한 우려의 분위기가 있는지 여부 - 조직에서 다양한 이유로 몇 가지 개편 작업을 수행했지만 이해 당사자(stakeholder)는 이를 성공으로 인식하지 않습니다. 이러한 경우 변경 제안사항을 구체적으로 작성하고 해당 동기를 명확히 밝혀 조직 인원이 변경의 가치 여부를 고려할 수 있도록 해야 합니다. 또한 이전 변경 노력이 실패한 이유도 파악해야 합니다.
  • 대상 조직 인원의 일반적인 태도. 예를 들어, "젊고 도전적인지" 또는 "숙련되고 안정적인지" 여부를 파악해야 합니다. 
  • 대상 조직이 기존 조직인지 또는 완전히 새로운 조직을 구축하는지 여부. 후자의 경우 새 조직의 인원에게 필요한 역량과 준비 기간 중 이러한 역량에 할애할 수 있는 시간을 이해해야 합니다. 

위에서 언급한 소프트웨어적인 요소 이외에도 신기술(예: e-business 솔루션 빌드에 필요한 기술)의 준비 상태를 평가해야 합니다. 이러한 기술의 예는 다음과 같습니다. [CONA99]

  • 클라이언트/서버

  • 데이터베이스 관리

  • 프로그래밍 언어(예: HTML, XML, Java)

  • 스크립트 서버 페이지 및 Servlet(예: Microsoft Active Server Pages, Java Server Pages)

  • 오브젝트 통신 프로토콜(예: OMG CORBA(Common Object Request Broker Architecture), Java 표준 RMI(Remote Method Invocation) 또는 Microsoft DCOM(Distributed Component Object Model))

  • 컴포넌트(예: Microsoft ActiveX/COM)

  • 웹 응용프로그램 프레임워크(예: IBM WebSphere 또는 Microsoft Windows DNA)

이 평가는 솔루션 아키텍처를 구성할 때 감수해야 할 위험성 레벨에 큰 영향을 줍니다. 활동: 프로젝트 범위 및 위험성 평가도 참조하십시오. 

문제점 식별

문제점을 식별하기 위한 가장 효과적인 방법은 문제점 식별 세션을 위해 여러 핵심 인원을 모으는 것입니다. 세션 구성 방법에 대한 일반 정보는 가이드라인: 브레인스토밍 및 아이디어 정리를 참조하십시오.

다음과 같은 질문을 제시하십시오.

  • 대상 조직의 문제점은 무엇입니까?
  • 무언가 잘못되었다고 느끼십니까?
  • 일정이 늦어지거나 예산을 초과한 프로젝트가 있습니까?
  • 해당 프로젝트의 문제점은 무엇입니까?
  • 분석할 수 있는 메트릭이 수집되었습니까?

각 문제점이 프로젝트에 대해 현재 갖고 있거나 앞으로 갖게 될(적절한 조치를 취하지 않는 경우) 부정적 영향은 무엇입니까? 문제점의 영향을 파악함으로써 문제점 해결 및 조치 수행의 중요성을 이해할 수 있습니다.

각 문제점의 근본 원인을 식별하십시오. 문제점의 근본 원인을 파악함으로써 문제점 해결 및 조치 수행 방법과 관련 비용을 이해할 수 있습니다. 이 작업에는 피시본 다이어그램을 활용할 수 있습니다. 문제점의 근본 원인이 여러 개인 상태에서 가중치를 설정해야 하는 경우에는 파레토 다이어그램을 활용할 수 있습니다. 

경고: 일반적으로 먼저 문제점을 이해하는 시간을 갖기 보다 솔루션 정의에 집착하는 경향이 있습니다. 문제점을 기록하고 모든 사람에게서 정의에 대한 합의를 얻을 수 있는지 확인하십시오.

해당 영향에 따라 문제점의 등급을 설정하십시오. 예를 들어, 1 - 5 등급을 사용할 수 있습니다. 여기서, 5는 가장 위험한 영향 요소를 나타내며 1은 가장 무해한 영향 요소를 나타냅니다. 이러한 방법을 사용하는 기본 목적은 문제점의 상대적 중요성을 파악하기 위한 것입니다.

문제점의 정의에 대한 합의를 얻는 가장 단순한 방법 중 하나는 해당 정의를 쓰고 모든 사람이 동의하는지 확인하는 것입니다. 아래 표에 문제점을 나열하십시오.

문제점 

영향 

근본 원인 

등급 

전달된 소프트웨어의 품질이 낮습니다. 

- 고객이 불만족을 나타냅니다.
- 기본 릴리스 후 버그 수정을 릴리스해야 합니다. 
- 테스트 케이스가 완전한 적용 범위를 제공하지 않습니다.
- 테스트가 자동화되지 않았습니다.
- 테스트 수행자가 적절한 훈련을 받지 않았습니다. 

#5 

... 

... 

... 

... 


결론 도출

수집한 정보 결과를 분석하고 집중할 영역 및 문제에 대한 목록을 컴파일하십시오. 조기에 처리해야 하는 문제는 보통 다음과 같은 카테고리로 분류할 수 있습니다.

  • 주요 문제점 영역. 비즈니스 프로세스 성능을 현저히 개선할 수 있는 영역
  • 단기 이익을 얻을 수 있는 영역. 빠른 결과를 나타낼 수 있는 영역
  • 개선의 효과가 뚜렷한 영역

수집한 정보와 결론은 중간 산출물: 대상 조직 평가에 문서화하십시오.

권장사항 작성

미래를 대비하여 몇 가지 권장사항을 평가의 일부로 포함시켜야 합니다. 권장사항은 비즈니스 모델링을 위해 수행하는 접근 방식에 대해 설명해야 합니다. 표준 시나리오 세트는 개념: 비즈니스 모델링 범위를 참조하십시오.



특성
다중 발생
이벤트로 구동됨
진행 중임
선택사항
계획됨
반복 가능함
자세한 정보