가이드라인: 비즈니스 아키텍처 문서
비즈니스 아키텍처는 필요에 따라 핵심 비즈니스 프로세스를 개선 또는 리엔지니어링하기 위해 필요한 내용을 고려하여 구성됩니다. 이 가이드라인은 완전한 비즈니스 아키텍처 문서를 작성하는 데 필요한 요소에 대해 설명합니다.
관계
기본 설명

참조

비즈니스 아키텍처 문서의 참조 섹션에는 비즈니스 아키텍처를 이해하는 데 중요한 배경 정보를 제공하는 외부 문서가 표시됩니다. 참조할 문서가 많은 경우, 다음과 같이 해당 섹션을 서브섹션으로 나누십시오.

  • 외부 문서
  • 내부 문서
  • 관리 문서
  • 비관리 문서

아키텍처 구동 요소페이지 맨 위로

비즈니스 아키텍처는 핵심 비즈니스 프로세스를 개선 또는 리엔지니어링하기 위해 필요한 내용을 고려하여 구성됩니다. 이 프로세스는 비즈니스 유스 케이스 모델의 서브세트를 구성하는 비즈니스 유스 케이스로 표시됩니다. 비즈니스 목적 또한 반드시 입력해야 합니다. 비즈니스 목적은 비즈니스 유스 케이스 모델에서도 캡처합니다. 여기서 모든 비즈니스 목적을 설명할 필요는 없으며 구조적으로 중요한 목적만 설명하면 됩니다. 다음은 비즈니스 목적의 구조적 중요성 여부를 결정하는 특성의 예입니다.

  • 엔터프라이즈의 장기적 성공을 위해 반드시 필요합니다.
  • 비즈니스 전략에 많은 기여를 합니다.
  • 현재 프로세스, 자원 및 하부 구조로 실현할 수 없습니다.
  • 변경 시 비즈니스 전반에 영향을 줍니다.
  • 비즈니스가 직접 제어하지 않는 외부 관계자의 영향을 받습니다.

그러나 위의 특성은 비즈니스 아키텍처에 영향을 주는 요소 중 일부이며 이 밖에도 비즈니스 업무 환경, 기존 자산의 재사용 필요성 및 다양한 표준 준수 의무 등에 따른 제한조건이 적용됩니다. 이러한 매크로 레벨의 영향력(구동 요소)은 비즈니스의 주요 분야 및 운영 방식에 중요한 영향을 주므로 비즈니스 아키텍처의 구성 요소가 됩니다.

아키텍처 구동 요소 는 아키텍처 목적제한조건을 합한 개념입니다. 아키텍처 목적은 비즈니스 아키텍처의 목표 또는 의도에 대해 설명하고 아키텍처 제한조건은 제한을 가합니다. 아키텍처 목적을 명확하게 정의함으로써 비즈니스에 영향을 주는 요인을 활용할 수 있고, 아키텍처 제한조건을 명확하게 정의함으로써 대안을 제안하여 위험성을 줄일 수 있습니다. 예를 들어, 전략적 핵심 사안(뛰어난 운영 성능, 고객 친밀도 또는 제품 혁신), 인적 자원 또는 기타 자원의 가용성, 현재 및 예상 경제 상황, 기술 트렌드, 소비자 행동 변화, 경쟁자 동향, 비즈니스 해당 시장 상태, 세계화, 경제적 이주, 법률 및 규제 등을 고려해야 합니다.

또한 비즈니스 아키텍처를 구성하는 비즈니스의 핵심 품질 차원을 고려해야 합니다. 제시된 정보는 다음을 포함할 수 있습니다.

  • 운영 성능 요구사항 
  • 품질 목표(예: "납기 준수")
  • 확장성 목표(예: 고객 요구 증가에 대처할 수 있는 능력)
  • 이식성 목표(예: 지원되는 국가, 언어 및 제품군)

비즈니스 프로세스 보기

비즈니스 프로세스 보기는 중간 산출물: 비즈니스 유스 케이스 모델의 서브세트로서, 주요 비즈니스 프로세스가 포함됩니다. 이 보기는 다음과 같은 특성의 비즈니스 시나리오 및 비즈니스 유스 케이스 세트에 대해 설명합니다.

  • 비즈니스의 중요한 핵심 기능을 나타냅니다. 
  • 조직의 여러 핵심 요소를 실행하여 많은 부분에 영향을 줍니다. 
  • 비즈니스 아키텍처의 민감하거나 복잡하거나 위험한 특정 측면을 나타내거나 강조합니다.

United States General Accounting Office [GAO97]에는 다음과 같은 비즈니스 프로세스의 우선순위를 결정하는 일정 기준이 나열되어 있습니다.

  • 비즈니스 전략과 가장 많은 관련이 있는 프로세스
  • 고객에 대한 영향력이 가장 큰 프로세스
  • 개선에 따른 잠재적 수익이 가장 큰 프로세스
  • 변화 요구에 대해 합의 의견이 많은 프로세스
  • 현재 사용 가능한 자원 및 하부 구조로 재설계할 수 있는 프로세스
  • 그다지 복잡하지 않아 빠르게 개선할 수 있어 효과도 빠른 프로세스
  • 그다지 복잡하지 않아 리엔지니어링 체험에 활용할 수 있는 프로세스

중요한 각 비즈니스 유스 케이스에 대해 다음 정보를 제공하는 서브섹션을 포함하십시오.

  • 비즈니스 유스 케이스의 이름
  • 해당 목적을 포함하여 비즈니스 유스 케이스에 대한 간략한 설명
  • 비즈니스 유스 케이스가 구조적으로 중요한 이유에 대한 설명

조직 보기

조직 보기는 원래 비즈니스 아키텍처에 중요한 요소를 포함하는 중간 산출물: 비즈니스 분석 모델의 서브세트입니다. 비즈니스 분석 모델이 중간 산출물: 비즈니스 디자인 모델로 정제되면서 조직 보기도 그에 따라 변경되어 비즈니스의 추상 역할과 인력, 소프트웨어 및 하드웨어와의 연결 관계를 보여줍니다. 이를 통해 비즈니스 운영 성능 및 비용를 수량적인 평가할 수 있습니다.

조직 보기는 가장 중요한 비즈니스 작업자, 비즈니스 엔티티 및 비즈니스 이벤트와, 이 세 요소의 비즈니스 시스템 및 계층 구성에 대해 설명합니다. 이 보기에는 또한 가장 중요한 비즈니스 유스 케이스 실현(realization)과 일반 동작 패턴에 대한 설명이 포함됩니다.

이 보기의 범위에는 비즈니스 자체(내부 조직), 또는 해당 비즈니스 및 비즈니스와 해당 파트너와의 관계(확장 조직)가 포함될 수 있습니다. 후자의 관점은 전체 가치 사슬을 통해 고객에게 제품 및 서비스를 전달하려는 경우 특히 유용합니다.

인적 자원 보기  

인적 자원 보기에는 조직 변화를 준비하기 위한 모든 측면이 포함되며 해당 결과는 다음과 같습니다.

  • 권장 하부 구조
  • 변경된 조직에서 직원들의 업무 수행 동기를 부여하기 위한 메커니즘
  • 변경된 조직에서 필요한 스킬을 장려하기 위한 메커니즘

빠른 시간 내에 조직을 정상화하려면 최종 비즈니스 디자인이 공개되기 전에 미리 이 작업을 시작해야 합니다. 즉, 프로젝트 초기에는 노력의 목표가 확정되기 전 초기 반복 단계에서 직원들의 변화 적응에 필요한 일반 작업에 초점을 맞추어야 합니다. 또한 프로젝트 후기에서는 직원들이 새로운 타스크를 수행할 수 있도록 훈련시키고 하부 구조 변경에 따른 요구(예: 직원들의 위치와 필요한 장비)를 연구하는 데 집중해야 합니다. 비즈니스 리엔지니어링과 같이 비즈니스 모델링 노력으로 인해 큰 변화가 수반되는 경우 변화에 대한 준비 자체가 복잡하고 많은 비용이 소요되는 타스크이므로 개별 프로젝트로 진행될 수 있습니다.

Kotter의 변화 모델 [KOT96]은 이미 여러 조직에 성공적으로 적용된 모델로서, 조직 변화를 이끌기 위한 단계를 다음과 같이 정의합니다.

  • 위기에 대한 공감을 이끌어냅니다.
  • 변화를 주도하는 지도부를 구성합니다.
  • 비전과 전략을 개발합니다.
  • 비전을 공유합니다.
  • 포괄적인 영향력을 행사할 수 있는 권한을 부여합니다.
  • 단기 성과를 이끌어냅니다.
  • 성과를 강화하고 보다 많은 변화를 이끌어냅니다.
  • 새로운 접근 방식을 제도화합니다.

또한 다음과 같이 보다 세부적인 변화 측면을 고려해야 합니다. 

조직 문화에 대한 이해

변화에 성공하고 이를 지속적으로 유지하려면 대상 조직의 문화를 이해하고 필요한 경우 변화시킬 수 있어야 합니다. 대상 조직의 문화를 이해하지 못하면 비즈니스 엔지니어링 노력은 모두 실패하게 됩니다. 

비즈니스 모델링 노력이 급진적인 변화를 목표로 하지 않더라도 문화에 대한 이해는 반드시 필요합니다. 즉, 문화를 이해함으로써 예상치 못한 방해 요소를 미리 차단할 수 있습니다.  

문화는 간단한 공식을 적용하여 쉽게 이해하거나 설명할 수 있는 것이 아닙니다.  

Champy [CHM95]는 건전한 비즈니스의 문화를 "자발성"의 문화로 규정합니다. 특히 Champy는 새 비즈니스의 직원이 다음과 같은 측면에서 자발성을 나타내야 한다고 제안합니다.

  • 업무 수행에 있어 항상 가장 우수한 역량을 나타냅니다.
  • 창의적으로 행동하고 위험을 두려워하지 않습니다.
  • 변화에 적응합니다.
  • 의사결정을 수행합니다.
  • 팀 구성원으로서 협력합니다.
  • 특히 정보, 지식 및 미래 또는 현재 "문제점"과 관련된 뉴스를 습득합니다.
  • 타인을 신뢰하고 자신의 신뢰를 쌓습니다.
  • 고객, 공급자, 동료 등 타인은 물론 자기 자신을 존중합니다.
  • 자신의 행동에 책임을 지고 책임을 완수합니다.
  • 타인과 자신 모두 성과에 따라 판단하고 보상합니다.

기업의 문화는 쉽게 바꿀 수 없으며 이는 어떤 형태의 문화도 마찬가지입니다. 따라서 이 한 가지 주제만으로도 책 한 권을 쓸 수 있습니다. Champy [CHM95]는 이 주제와 관련하여 다음과 같은 권장 절차에 대한 간략한 설명을 제공합니다.

  • 기존 비즈니스에서의 구성원의 공유 가치를 판별합니다.
  • 잘못된 점을 식별하고 제거합니다.
  • 필요한 가치와 행동을 명시합니다.
  • 관리 유스 케이스에서 특정 가치 및 행동에 대한 필요성을 지원할 수 있는지 여부를 판별합니다. 지원하지 않는 경우 문화를 바꿀 수 없습니다.
  • 새로운 가치를 널리 알리고 실천하고 생활화함으로써 정립합니다.

비즈니스 문화를 변화시키는 과정에는 많은 어려움이 내재되어 있습니다. 다음은 이와 관련하여 Champy [CHM95]가 경고하는 네 가지 금지사항입니다.

  • 동작 변화를 거부하는 구성원을 묵인해서는 안됩니다. 특히 구성원의 업무가 엔지니어링 목표를 달성하는 데 중요한 경우에는 더욱 그렇습니다. 과거의 행동을 묵인하는 사람은 본인 스스로 변화의 심각성을 느끼지 못하는 사람입니다. 이는 모든 관리자와 팀 구성원에게 모두 해당됩니다.
  • 구성원들에게 변화에 필요한 업무 수행 방법을 알려주지 않고 스스로 변화하도록 기대해서는 안됩니다.
  • 문화가 즉시 변화될 수 있는 것으로 기대해서는 안됩니다. 문화가 변화하려면 몇 달이 아닌 몇 년의 시간이 필요합니다.
  • 새로운 가치 세트를 지원하기 위한 관리 유스 케이스 엔지니어링을 지연해서는 안됩니다.
관심사항 및 태도 관리 

다음과 같은 영역을 고려해야 합니다. 

  • 비즈니스 아이디어 및 전략: 해당 내용을 잘 설명하고 모두 잘 이해하고 있습니까? 
  • 기능 지향 조직 대 프로세스 지향 조직: 프로세스 지향 조직을 목표로 하는 경우 그 이점에 대해 잘 설명하고 모두 잘 이해하고 있습니까?
  • 미래 변화: 변화로 수반되는 내용과 동기 부여 요인을 설명하면 변화에 대한 두려움을 줄일 수 있습니다. 변화는 비즈니스 구성원의 관점뿐만 아니라 고객의 관점에서 동기가 부여되어야 합니다. 
  • 비즈니스 문화: 현재 문화가 필요한 변화를 지원합니까? 
스킬 변경 및 개선

여러 수준의 교육이 필요하며 세 가지 카테고리로 분류할 수 있습니다. 즉, 일반 스킬과 특정 분야 전문 스킬의 경우 외부 프로그램을 사용할 수 있습니다. 해당 조직의 특정 스킬인 경우 프리젠테이션 및 워크샵을 준비하고 계획을 수립해야 하며 필요한 경우 보다 광범위한 훈련 프로그램을 준비해야 합니다. 

일반 스킬: 

  • 프로세스 지향 조직은 고객에 초점을 둡니다. 고객에게 가치를 제공하는 것과 단지 절차를 따르는 것을 정확히 구분해야 합니다. 
  • 프로세스를 수행하는 구성원에게 해당 책임을 분배해야 하며 모든 구성원이 올바른 의사결정을 수행하려면 비즈니스 규칙을 정확히 이해해야 합니다. 

특정 분야 전문 스킬: 

  • 제품 및 서비스 등 비즈니스 전반에 대해 잘 이해하고 있습니까?
  • 관련 비즈니스 액터(고객, 파트너, 벤더)는 무엇입니까?
  • 해당 결과와 제공되는 서비스는 무엇입니까?
  • 프로세스 내 본인의 업무 책임과 어떠한 관계가 있습니까?

비즈니스 프로세스 특정 스킬: 

  • 비즈니스 프로세스를 올바르게 이해해야 합니다.
  • 자신의 비즈니스 액터에 정의된 책임과 비즈니스 작업자의 타스크 수행 능력을 올바르게 이해해야 합니다.
  • 동료의 책임과 타스크를 이해해야 합니다.
  • 비즈니스 도구 사용 방법을 이해해야 합니다.

올바른 조직 스킬을 달성하려면 기존 직원을 잘 훈련시키고 유능한 새 직원을 고용해야 합니다. 

인센티브 정의 

직원들이 비즈니스 아이디어 및 비즈니스 전략에 따라 업무를 수행하도록 장려하는 보상 시스템을 정의함으로써 대상 액터의 요구를 충족시킬 수 있습니다. 비즈니스 아이디어 및 전략을 기반으로 하는 개별 비즈니스 프로세스의 목표에 따라 다음 기준에 따라 보상 시스템을 정의합니다.

  • 전체 비즈니스 성과
  • 전체 비즈니스 프로세스 성과
  • 비즈니스 프로세스의 개별 실행(인스턴스)에 따른 결과
  • 각 개인의 기여도 

대상 조직의 모든 직원 유형에 대한 기존 인센티브를 조사합니다. 기능 지향 조직에서는 일반적으로 조직의 개별 기능 단위에 따라 보상이 제공되므로 해당 성과가 비즈니스와 중요한 비즈니스 프로세스 전체에서 비롯된 것임을 인식하지 못합니다. 따라서 이러한 인센티브 체계를 신속하게 바꿔야 합니다.

그러나 직원들의 변화 수용에 있어 이전 보상 시스템에서 새 보상 시스템으로의 원활한 대체가 매우 중요합니다.

직원들에게 올바른 장비를 제공하고 업무 수행을 위해 최적화된 위치에 설치하는 것 또한 성공을 위한 전제조건입니다. 

지리적 보기페이지 맨 위로

서비스 산업에서는 최적의 위치를 상대적으로 쉽게 정할 수 있는 반면 제조업체의 경우 비즈니스 프로세스의 변화는 많은 비용이 소요되는 대규모 작업입니다. 따라서 예산과 가능한 일정 계획에 따라 단일 프로젝트에서 달성할 수 있는 성과가 제한되는 경우도 많습니다.

위치의 중요성은 프로세스 유형에 따라 다릅니다. 즉, 이러한 측면에서 볼 때 전화 판매 프로세스, 현장 판매 프로세스 및 제조 프로세스는 상당한 차이를 나타냅니다. 조직의 향후 위치와 해당 방법에 영향을 주는 비즈니스 엔지니어링 노력의 가능성 또한 프로젝트마다 현저한 차이를 나타냅니다.

다음은 현실적인 접근 방식을 판별하는 데 유용한 절차입니다.

  • 각 비즈니스 유스 케이스를 조사하여, 관련 비즈니스 작업자의 최적화된 타스크 수행을 위해 필요한 실제 위치를 확인합니다.
  • 유스 케이스 실현(realization)을 하나씩 조사하여 각 비즈니스 작업자에 필요한 장비와 공간을 식별합니다.
  • 전체 비즈니스 또는 관련 비즈니스 유스 케이스 그룹을 조사하여 다음 사항을 고려합니다.
    • 여러 비즈니스 유스 케이스에 참여하는 비즈니스 작업자
    • 다른 프로세스의 결과를 이용하는 프로세스
  • 위의 사항을 고려하여 각 비즈니스 작업자의 최적 위치를 식별합니다.
  • 최적 위치를 현재 상황과 비교하여 다음 사항을 확인합니다.
    • 프로젝트 지시에서의 실제적 변화
    • 비용 효율이 가장 높은 위치
    • 조직에 반드시 필요한 강제 사항
    • 올바른 장비 보유에 따른 보상
    • 올바른 위치 선택에 따른 보상
  • 비즈니스 유스 케이스에 전체 비즈니스 시스템을 배재치하는 데 따른 영향을 고려합니다.
  • 조사 결과에 따라 위치 변경을 위한 비즈니스 유스 케이스당 비용을 예측합니다. 투자의 현실성 여부를 판별합니다.

예를 들어, 고객의 사무실에서 회사 데이터베이스에 직접 접속해야 하는 영업 사원에게는 모바일 데이터 솔루션을 고려해야 합니다. 화상 회의 장비를 설치함으로써 경우에 따라 개발 팀이 본사에 없는 경우의 단점을 극복할 수도 있습니다.

아키텍처 절충페이지 맨 위로

비즈니스 아키텍처 문서의 이 섹션은 비즈니스 아키텍처에서 이 문서 시작 부분에서 설명한 아키텍처 목적과 제한조건(아키텍처 구동 요소)을 실현하는 방법에 대해 설명합니다. 이는 기본 아키텍처 결정에 대한 근거를 보존하기 위한 논의입니다. 따라서 대부분 또는 여러 아키텍처 구동 요소와 비즈니스 아키텍처는 여러 가지 충돌 구동 요소를 최대한 충족시키는 최적의 솔루션을 제공해야 합니다. 이는 여러 절충 및 의사결정이 이루어질 수 있음을 의미합니다. 이러한 의사결정 및 절충의 예는 다음과 같습니다.

예를 들어, 신제품을 빠르기 배치할 수 있는 역량이 특정 아키텍처 목적인 반면 파트너를 통해 보완 제품과 함께 제품을 제공하는 역량이 또 다른 아키텍처 목적이 될 수 있습니다. 외부 파트너를 통해 제품을 제공하는 경우 출시 시간이 지연되므로 이 두 가지 목적은 서로 상충되는 목적입니다. 이러한 경우, 이 섹션에서 이 두 가지 목적을 최대한 달성하기 위한 비즈니스 아키텍처 내 절충에 대해 설명합니다. 즉, 이 예의 경우 파트너 제품 관리 팀을 구성하고, 후보 파트너를 선택할 때 특정 제한사항을 적용할 수 있습니다.

많은 충돌 및 절충은 응용프로그램 아키텍처 또는 기술 아키텍처를 고려한 후에만 나타납니다(개념: 비즈니스 아키텍처 참조). 따라서 이러한 의사결정의 결과를 정확히 이해해야 합니다.

이 섹션은 비즈니스 아키텍처의 전체 구성에 대한 근거(중간 산출물: 비즈니스 분석 모델 및 중간 산출물: 비즈니스 배치 모델에서 캡처)와, 구조적으로 중요한 인력, 소프트웨어 및 하드웨어 관점에서의 향후 실현(realization) 선택사항에 대한 근거(중간 산출물: 비즈니스 디자인 모델)를 모두 제공합니다.