비즈니스 목표 상태 구축하기

Contents

1 개요

2 평가 지표를 사용

3 프로세스 플로우 사용

4 심층 분석

[edit]

1 개요 #

• 비즈니스가 이디로 가고자 하는지 기술
  
  
• 비즈니스 목표 상태는 원하는 미래 상태의 긍정적인 특징을 설명
  
  
• 목표 상태의 2가지 의미
  
  • 현재 상태이 문제점들이 해결되었을 때 어떻게 운영되는지를 묘사한 것
    
  • 미션과 목표의 달성을 구현한 것
    
• 목표 상태가 분명하게 보이는 것 같아도 성급하게 판단을 해서는 안 된다.
  
• 이 작업은 몇 주가 아니라 일 단위로 수행되며, 산출물은 몇 권의 두툼한 책이 아니라 몇 페이지의 문서이다
  
  

[edit]

2 평가 지표를 사용 #

긍정적 기술서(Positive Statements)를 사용

• 스트레스 포인트가 완화되고 리스크가 경감된다면?
  
• 약점이 처리되고 강점이 강화된다면?
  
• 과제가 해결된다면?
  
• 환경 변화가 정확히 설명된다면?
  
• 성장/비용 억제 기회가 효과적으로 활용된다면?
  
  

[edit]

3 프로세스 플로우 사용 #

미래에 대한 엔터프라이즈의 비전에 근거한 방법으로, 좀 더 깊이 있게 목표 상태를 설명할 수 있다. 목표 상태 비즈니스 흐름을 그리면 된다.

• 고객과 납품업체는 기업과 어떻게 상화작용할 것인가? 현재 상태에서 병목지점이나 갭이 발견된다면, 목표상태에서는 이를 어떻게 해결할 것인지 검토
  
• 상위 수준의 비즈니스 기능 플로우는 미래에 어떻게 될 것인가?
  
• 어떠한 핵심 비즈니스 정보가 프로세스를 타고 흐를 것인가? (목표 정보가 프로세스 플로우에 포함되어야 한다)
  
• 어떠한 주요 인력 계획과 스킬이 있어야 하는가? (직원들이 미래에 어떻게 일할 것인가?)
  
• 어떠한 필수 지원 프로세스와 구조가 있어야 하는가? (수작업에 의한 개입이나 중복 프로세스가 현재상태에 발견되었다면, 목표상태에서는 어떻게 해결할 것인가?)
  
• 어떠한 해심 역량들이 원하는 상태의 달성을 가능하게 할 것인가?
  
  

[edit]

4 심층 분석 #

• 목표나 추진 과제 문서를 가지고 분석하는 것
  

원칙

Contents

1 IT 아키텍처 프레임워크

2 원칙 정의

비즈니스가 원하는 상태를 포착하고 분석하였다면, 비즈니스 기회를 IT플랜으로 어떻게 전환하겠는가?

[edit]

1 IT 아키텍처 프레임워크 #

• 관리 가능한 컨텐츠 목록을 제공함을 목표
  
• 아키텍처의 범위를 의도적으로 제한한 구조
  
• 비즈니스 목표 상태 기회를 근거로하여 관련된 IT 인프라 산출물을 구축하기 위한 로드맵을 제공
  
  

용어

• 아키텍처: 비즈니스의 목표 상태를 가능하게 해 주는 기업의 정보 인프라를 선정하고 구축하고 수정하고 사용하는데 지침이 되는 한 세트의 완전한 프랜을 의미한다.
  
• 인프라: 비즈니스를 지원하기 위해 IT가 구축하거나 구매하거나 사용하는 모든 제품과 서비스를 의미
  
• 데이터: 비즈니스에 관한 주요 사실
  
• 기능: 비즈니스를 경영하기 위해 필요한 중요한 운영 활동을 의미
  
• 플랫폼: 데이터와 기능의 생성과 사용을 가능하게 하는 기술
  
• 인력: 데이터의 소비자와 제공자, 기능의 사용자 및 기술 운영자를 의미
  
  

[edit]

2 원칙 정의 #

• '원칙'은 IT 의사결정의 가이드라인을 작성하기 위해 비즈니스 목표상태를 요약한 것을 의미
  
• 비즈니스 목표 상태를 좀 더 일반적인 IT지침서로 전환하기 위해 원칙을 사용
  
• 원칙은 문구에 대한 논쟁을 최대한 피하고, 신속히 정리하여 공표하는 것이 효과적임
  
• IT 원칙을 작성하기 위한 가이드라인
  
  • 비즈니스 목표 확인서를 IT 목표 확인서로 전환하라 (데이터, 기능, 플랫폼, 인력에 대해서..)
    
  • 간결하고 쉽게 작성하라. (원칙이 기억되고 사용되어지기를 원한다면 최대한 간결하게! 각 원칙은 한 문장으로 정리. 예, 애플리케이션 기능은 재활용이 가능하다)
    
  • 원칙을 사용하여 회사가 보편 타당하게 유지하고 있는 기본 신조를 전달. (예, 고도로 훈련된 인력은 우리의 핵심 성공 요인이다)
    
  • 원칙을 사용하여 여러분이 개발할 모델과 표준에 비즈니스 제약 조건을 부과하라 (예, 자체개발보다는 구매하는 것이 우선이다)
    
  • 원칙은 한 페이지면 족하다.
    

아키텍처와 비즈니스 결합하기

Contents

1 비즈니스 프레임워크

2 비즈니스의 현재 상태 설명 - 주요 정보 수집

[edit]

1 비즈니스 프레임워크 #

아키텍처의 두 가지 큰 문제점

• 지나치게 복잡하며 기술중심적인 세계관
  
  
• 명확한 비즈니스 초점의 결여
  
  

비즈니스 프레임워크가 필요한 이유

• 기업의 니즈에 대한 진정한 이해와 현업의 참여 없이 시작하는 IT프로젝트는 자주 실패함
  
• 기업의 AS-IS와 TO-BE에 대해서 프로젝트의 맨 점음에 상위 수준에서 검토하는 것이 매우 중요
  
  

비즈니스 프레임워크의 기본버전

• 관점: 현재상태와 앞으로 어떻게 운영될 것인지에 대한 설명
  
• 내용: 비즈니스의 내용. 즉, IT아키텍처에서 포착되고 다루어야 할 사항들을 설명
  
• 아키텍처의 동인(Driver)이 되어야 하는 비즈니스에 관한 최소한의 기본적인 정보를 확보하는 수단을 제공하는 것이 목표
  
• 프레임워크를 통해 어떤 것이 필요한 정보인지 파악
  
• 초점을 좁힘으로써 정보 수집의 기간을 효과적으로 단축
  
• 비즈니스 프레임워크를 사용함으로써 IT프레임워크 작업의 투입물이 되도록 특별히 설계된 산출물이 나오게 해야 함. -> 비즈니스 니즈와 IT기회간의 근본적인 통합 달성
  
  

[edit]

2 비즈니스의 현재 상태 설명 - 주요 정보 수집 #

주의사항

• 수집 가능한 정보가 많지만, 몇가지 필수적인 데이터만 제한적으로 수집할 수도 있다
  
• 한 가지 혹은 여러 가지 접근방법을 복합적으로 사용하여 기업의 현재 초점과 주요 현안이 무엇인지 포착해주는 정보를 확인/기록
  
  

전략

• 비즈니스 목표가 무엇인지 나타내는 가장 가시적이면서 인정받는 비즈니스 전략 문서 수집
  
  • 미션/목표 확인서
    
  • 전략/운영 계획
    
  • 핵심 비즈니스 추진 과제와 주요 프로그램
    
• 조직의 리더를 인터뷰
  
  • 조직의 잘된 점과 잘못된 점을 묻고 기록
    
• 기업의 연혁, 문화, 비즈니스 방향의 중요한 변화를 확인/인지/기술
  
• 비즈니스 핵심 동인, 조직의 행태에 영향을 미치는 동기부여 요인
  
• 주요 제약 사항 확인
  
• 조직을 형성하는 기본적인 정보 수집
  
  • What - 조직이 무엇을 하는가? 목표, 존재이유
    
  • When - 조직이 어떻게 운영되는가? 영향을 미치는 주요한 이벤트나 역사적인 변화
    
  • How - 조직은 어떤 방식으로 비즈니스 수행(온라인 판매, 소매점)
    
  • Who - 해당 조직, 고객, 납품업체, 파트너
    
  • Why - 전략/비즈니스 동인의 변경이나 재고를 야기시키는 문제(왜 안팔리나? 왜 우리는 뭔가 다른 것을 해야 하는가?)
    
• 기타사항들
  
  • 기업 규모(연간 매출, 비용, 직원수)
    
  • 고객 수와 유형
    
  • 서비스를 제공하고 제공받는 위치
    
  • 제품/서비스 목록 및 판매 수량
    
  • 상위 수준의 조직 구조 및 프로세스 흐름
    
  • 판매 채널
    
  • 주요 납품업체/벤더
    
  • 주요 보고서 혹은 지표
    
  • 현재 사용 IT기술
    
  • 외부 인터페이스(예, 정부기관 등)
    

Enterprise Architecture

Contents

1 개요

2 글로벌 IT 거버넌스 프레임워크

3 참고자료

[edit]

1 개요 #

이곳의 문서들은 엔터프라이즈 아키텍처 입문(홍릉과학출판사)를 정리한 것이다. 다른 책으로 하려고 했으나, 이것이 4가지 이유 중에 교과서(물론 실무에서도 유용한)로 쓰여진 것이라고 저자 스스로가 밝혔기 때문이다. 교과서라면 원리와 원칙이 분명히 들어 있을 것이다. 지금은 머리말만 읽어도 머리가 지끈거리지만 언젠가는 귀찮을 정도가 되어야 나름대로 전문가소리를 듣지 않을까 한다.

Critical Sucess Factor

• 거버넌스
  
• 프레임워크
  
• 방법론
  
• 리포지토리 및 툴
  
• 산출물
  
• 선진사례
  
  

5가지 EA 개별 구성요소 및 3가지 공통 구성요소

• 개별
  
  • 전략 이니셔티브
    
  • 비즈니스 서비스
    
  • 정보 흐름
    
  • 애플리케이션 및 시스템
    
  • 인프라
    
• 공통
  
  • 보안
    
  • 표준
    
  • 인력
    
    

시스템 분석 및 설계와 EA와의 관계

전략 및 비즈니스 계획과 EA와의 관계

컴포넌트 기반과 SOA와 EA와의 관계

• ITA/EA
  
  

[edit]

2 글로벌 IT 거버넌스 프레임워크 #

[edit]

3 참고자료 #

• 전사적 아키텍처의 핵심, Part 1: 아키텍트 관점에서 고려할 사항
  
• 전사적 아키텍처의 핵심, Part 2: 전사적 아키텍처 저장소 개발과 관리
  
• 전사적 아키텍처의 핵심, Part 3: 전사적 아키텍처 설계와 구현
  
• 전사적 아키텍처의 핵심, Part 4: 전사적 아키텍처 테스트
  
• 전사적 아키텍처의 핵심, Part 5: 조직과 함께 성장하기
  
• 전사적 아키텍처의 핵심, Part 6: 관리성