뉴런리포트

프로세스 개선계획 수립

지능한글 — Sat, 4 Jul 2026 21:05:07 +0900

PROCESS IMPROVEMENT PLANNING BOOK

프로세스 개선계획 수립

원본 슬라이드의 핵심 구조를 유지하면서 이론적 기초, 실무 적용법, 연습 과제를 확장한 단행본형 학습 문서

원본: C005_프로세스개선계획수립_v2.0819(47).ppt · 총 47페이지 기반 재구성 · 2026-06-30

1. 개요

OVERVIEW

1.1 프로세스 개선계획 수립 Activity 공정도

원본 자료는 프로세스 개선계획 수립을 세 개의 Task로 구성한다. 첫 번째 Task는 개선 전략과 활동을 정의하고, 두 번째 Task는 그것을 실행 단위의 프로젝트와 KPI로 전환하며, 세 번째 Task는 이를 일정과 자원 수준으로 구체화한다. 즉, 전략적 방향에서 실행 포트폴리오로, 다시 운영 가능한 계획으로 이어지는 구조다.

Figure 1. 원본 슬라이드의 프로세스 개선계획 수립 Activity 공정도 (P3)

개념

프로세스 개선계획은 단순 아이디어 모음이 아니라, 미래 프로세스 모습을 구현하기 위한 실행 설계도다. 따라서 개선 과제, 프로젝트, KPI, 일정, 자원 사이의 논리적 연계가 확보되어야 한다.

실습 포인트

공정도를 읽을 때는 각 단계의 산출물이 다음 단계의 입력물이 되는지 확인해야 한다. 이 연결이 불명확하면 실행 단계에서 프로젝트가 우선순위를 잃고 KPI도 형식화되기 쉽다.

심화

실무에서는 전략 정의와 일정 수립이 분리되어 진행되는 경우가 많다. 그러나 계획 단계에서부터 일정과 자원 가시성을 고려하지 않으면 실행 가능성이 낮아진다.

1.2 목적과 세부 Task의 역할

원본 P4는 목적을 명확히 설명한다. 신기업 모형 정립 단계에서 도출된 미래 모습을 완성하기 위하여 프로세스 측면의 개선 전략을 세우고, 이를 프로젝트로 정의하며, 프로젝트 수행 일정과 투입 자원을 계획하는 것이다. 이는 조직 변화관리의 기본 순서와도 일치한다. 방향 설정, 우선순위 결정, 실행 설계가 연속적으로 연결된다.

구분	핵심 질문	주요 산출물	실무 의미
Task 1	무엇을 어떤 방향으로 개선할 것인가	개선전략, 개선활동, 추진방안	개선의 방향성과 범위를 정의
Task 2	무엇을 프로젝트화하고 어떻게 측정할 것인가	프로젝트 정의서, KPI 정의서, 목표치	실행 단위와 성과관리 체계를 확정
Task 3	언제 어떤 자원으로 실행할 것인가	일정계획, 자원계획	실행 가능성과 투자 시퀀스를 구체화

개념: 개선 방향은 미래 프로세스와 정합성을 가져야 한다.
실습: 전략 문장을 프로젝트 후보군으로 분해하고, 각 후보에 KPI를 붙인다.
심화: 자원 제약과 제도 제약을 반영해 단계적 롤아웃 전략을 수립한다.

핵심 요약

개선계획은 전략, 프로젝트, KPI, 일정, 자원의 연결 구조다.
원본 슬라이드의 3개 Task는 분석 보고서가 아니라 실행 설계 문서로 읽어야 한다.
이후 장에서는 각 Task를 이론과 실무 관점에서 확장하여 설명한다.

2. 프로세스 개선 이론적 기초

THEORY

2.1 BPR, 변화관리, 품질개선 프레임워크의 결합

프로세스 개선은 하나의 이론으로 설명되기 어렵다. 업무 재설계 수준의 급진적 혁신은 Hammer와 Champy의 BPR 관점이 유용하고, 조직 저항과 실행 정착은 Kotter의 8단계 변화관리 모델이 설명력을 가진다. 문제를 정의하고 원인을 분석해 지속적으로 통제하는 구조는 Six Sigma의 DMAIC와 PDCA 사이클이 잘 보완한다. 일정과 자원 계획은 PMI 프로젝트 관리 관점과 연결될 때 현실성이 높아진다.

프레임워크	핵심 질문	적용 시점	실무 활용 포인트
BPR	프로세스를 근본적으로 다시 설계할 것인가	전략 수립 초반	기존 절차를 전제로 하지 않고 고객가치 중심으로 재설계
Kotter 8단계	변화를 조직에 어떻게 정착시킬 것인가	실행 착수 전후	긴박감 형성, 연합 구축, 단기성과 창출
DMAIC	문제를 어떻게 측정하고 통제할 것인가	개선 프로젝트 정의 이후	정량 KPI와 원인분석 체계 수립
PDCA	개선을 어떻게 반복 학습할 것인가	운영 정착 단계	계획-실행-점검-조치의 반복 구조 확보
Lean	낭비를 어떻게 제거할 것인가	프로세스 진단 및 상세설계	대기, 재작업, 이동, 승인 지연 제거
PMI	언제, 누가, 무엇으로 수행할 것인가	일정 · 자원계획 단계	WBS, 일정, 리스크, 이해관계자 관리

개념

BPR은 방향을, DMAIC는 문제해결 방식을, Kotter는 조직 수용성을, PMI는 실행 통제를 보강한다. 좋은 프로세스 개선계획은 이 네 축이 동시에 작동한다.

2.2 프로세스 개선 문서에 이론이 필요한 이유

실무 문서에서 이론은 장식이 아니라 판단의 근거다. 개선 과제를 선택할 때 Lean 관점에서는 낭비 제거 여부를, BPR 관점에서는 근본 재설계 필요성을 묻는다. KPI를 설계할 때 DMAIC는 측정 정의의 명확성을 요구하고, 변화관리 관점에서는 KPI를 현업이 수용할 수 있는지 검토하게 만든다.

실습 포인트

문서를 작성할 때 각 장의 핵심 문장에 어떤 프레임워크가 숨어 있는지 표시해 보면, 추상적인 권고안이 아니라 논리적 계획서로 바뀐다.

심화

프로세스 개선은 흔히 IT 구축 계획으로 축소되지만, 제도 · 조직 · 역량 · 데이터 · 성과관리까지 포함해야 지속가능한 개선이 된다.

PART II

Task 1. 프로세스 개선 전략 수립

원본 P5~P26을 바탕으로 전략 정의, 활동 설계, 추진방안 수립을 개념-실습-심화 구조로 해설한다.

3. Task 1 개요

TASK 1

3.1 목적, 입력물, 산출물

원본 P5는 Task 1의 목적을 미래 프로세스 맵과 기술서를 기반으로 개선 전략과 개선 활동을 정의하고, 활동별 추진 방안을 도출하는 것으로 제시한다. 이는 개선 아이디어를 실행 가능한 중간 설계로 바꾸는 단계다. 이후 Task 2에서 프로젝트화할 수 있도록 활동 단위를 명확히 만드는 것이 핵심이다.

항목	내용
입력물	미래 프로세스 맵, 미래 프로세스 기술서, 미래 프로세스 체계도
주요 질문	어떤 개선 활동이 전략 목표를 달성하게 하는가
산출물	개선활동 정의서, 활동별 추진방안, 관련 고려사항 및 기대효과
기법	전문가 집단의 전문기술(Delphi) 기반 합의와 검토

개념

전략 수립 단계에서 지나치게 세부 설계로 들어가면 프로젝트 정의와 경계가 흐려진다. 반대로 너무 추상적이면 이후 단계에서 실행 항목으로 전환되지 않는다.

4. 전략 수립 접근방법

4.1 프로세스 개선전략 수립 절차

원본 P6은 프로세스 개선활동 정의와 활동별 추진방안 수립의 두 단계를 제시한다. 먼저 이미 도출된 개선 과제, 개선 방향, 개선 목표를 바탕으로 주요 활동을 정리하고, 이어서 각 활동의 현황과 필요성, 실행 방안, 고려사항, 기대효과를 구조화한다. 이는 전략적 의사결정을 행동 가능한 패키지로 전환하는 과정이다.

Figure 2. 원본 슬라이드의 프로세스 개선전략 수립 절차도 (P6)

개념: 전략 목표와 개선활동을 명확하게 연결한다.
실습: 각 활동에 대해 현황, 필요성, 실행안, 고려사항, 기대효과를 1페이지 구조로 정리한다.
심화: 추진방안은 제도, 조직, 시스템, 교육, 데이터 영역을 균형 있게 포함해야 한다.

실무 적용

좋은 개선활동은 단순한 선언문이 아니라 실행 주체와 제약 조건을 암시한다. 법 · 제도 개정, 조직 재배치, 교육체계 수립은 서로 다른 이해관계자와 일정 리스크를 가진다.

4.2 프로세스 개선 전략 유형 비교표

개선 전략은 단일 유형이 아니라 복합 포트폴리오로 구성된다. 아래 표는 주요 전략 유형의 목적, 장단점, 적합 상황을 정리한 것이다.

전략 유형	대표 목적	장점	한계	적합한 상황
제도 개선형	법 · 규정 · 정책의 정합성 확보	지속효과가 크고 통제력이 높음	의사결정 리드타임이 길다	업무 수행 근거가 제도에 강하게 묶인 경우
조직 재배치형	역할 · 권한 · 책임 구조 재정렬	병목 제거와 책임 명확화에 유리	저항이 크고 인사 영향이 큼	업무량 불균형, 기능 중복이 큰 경우
표준화형	절차 · 문서 · 체크리스트 통일	확산이 쉽고 오류를 줄임	고도 혁신에는 한계	지역 · 부서별 편차가 큰 경우
역량 강화형	교육, 훈련, 지식 이전	수용성과 현장 정착에 강함	성과가 늦게 나타날 수 있음	업무 난이도 대비 숙련도가 낮은 경우
정보화 지원형	시스템, 데이터, 자동화 활용	속도와 정확도 개선 가능	선행 표준화 없이는 효과 제한	수작업, 이중입력, 조회 지연이 큰 경우

주의

실무에서는 정보화 지원형만 먼저 추진하려는 경향이 있으나, 제도와 조직, 표준화가 선행되지 않으면 시스템이 기존 문제를 그대로 자동화할 수 있다.

5. 산출물 예시와 실무 확장

5.1 개선활동 정의 예시

원본 P7은 개선활동 정의의 예시를 보여준다. 핵심은 개선 과제와 개선 방향이 추상어로 남아 있지 않고, 실제 활동 단위로 번역되어야 한다는 것이다. 원본에서는 조직 체계 조정, 일제 정비, 교육체계 수립, 업무처리절차서 제작, 인원 조정 등 실행 가능한 활동 묶음으로 구체화한다.

Figure 3. 원본 슬라이드의 프로세스 개선활동 정의 예시 (P7)

개념

개선활동은 프로젝트보다 상위 개념이다. 하나의 개선활동이 여러 프로젝트를 포함할 수 있어야 하며, 활동 간 중복과 누락을 함께 통제해야 한다.

5.2 관련 법 · 제도 개선과 조직 체계 조정

원본 P8~P13은 제도 개선과 관서 체계 조정을 사례로 제시한다. 이 구간의 핵심은 프로세스 개선이 단순 업무절차가 아니라 제도적 정합성과 운영체계 재설계를 동시에 요구한다는 점이다. 제도 개정은 공공조직에서 특히 중요하며, 조직 체계 조정은 권한과 책임 재배분을 수반한다.

Figure 4. 원본 슬라이드의 법 · 제도 개선 추진 절차 예시 (P8)

Figure 5. 원본 슬라이드의 시 · 군 · 구 호적관서 체계 조정 예시 (P11)

Figure 6. 원본 슬라이드의 체계조정 추진 절차 예시 (P12)

실습 포인트

개선 방안을 작성할 때는 현황, 필요성, 실행안, 고려사항, 기대효과의 5단 구조를 유지하면 의사결정자가 빠르게 이해할 수 있다.

심화

제도 개선형 과제는 승인권자와 협의 절차가 길기 때문에, 변화관리 커뮤니케이션 계획과 병행해야 한다. Kotter의 관점에서는 긴박감 형성과 지지 연합 구축이 선행되어야 한다.

5.3 데이터 정비, 교육체계, 표준 절차서, 인원 조정

원본 P14~P26은 데이터 일제 정비, 원격교육체계 수립, 업무처리절차서 제작 및 배포, 인원 조정 사례를 다룬다. 이는 데이터 품질, 역량, 표준화, 조직 운영의 네 축이 개선전략에 모두 포함되어야 함을 보여준다.

Figure 7. 원본 슬라이드의 데이터 정비 방안 예시 (P16)

개선 영역	원본 사례	핵심 성공요인	실패 위험
데이터 정비	주민등록정보와의 대조, 누락값 보정	정합성 기준과 책임체계 명확화	대상 데이터 정의 불명확
교육체계	원격교육체계 구축	대상자 세분화와 커리큘럼 설계	운영인력 부재, 콘텐츠 갱신 지연
표준 절차	업무처리절차서 제작 · 배포	현장 노하우를 체크리스트로 구조화	문서만 배포하고 교육이 없는 경우
조직 운영	업무량 기반 인원 조정	직무분석과 업무량 조사	정원 논의가 정치화되는 경우

개념

Lean 관점에서는 낭비 제거, DMAIC 관점에서는 데이터 기반 문제정의, PMI 관점에서는 자원 재배치가 중요하다. 네 영역은 따로 추진하는 것이 아니라 포트폴리오로 통합해야 한다.

Task 1 핵심 요약

Task 1은 개선 방향을 실행 가능한 활동 묶음으로 만드는 단계다.
전략 유형은 제도, 조직, 표준화, 교육, 정보화로 구분해 균형 있게 설계할 수 있다.
현황-필요성-실행안-고려사항-기대효과의 구조가 실무 문서의 기본 골격이 된다.

PART III

Task 2. 프로세스 개선 프로젝트 정의

원본 P27~P36을 바탕으로 우선순위 평가, 프로젝트 정의, KPI 설계의 연계 구조를 정리한다.

6. Task 2 개요

TASK 2

6.1 목적과 기본 흐름

원본 P27은 Task 2의 목적을 개선 전략의 달성을 위한 개선 프로젝트 정의로 설명한다. Task 1에서 도출한 활동을 프로젝트 포트폴리오로 바꾸고, 그 프로젝트의 실행 정도를 모니터링할 KPI와 목표치를 정의하는 단계다. 여기서는 우선순위가 핵심이다. 모든 활동을 동시에 추진할 수 없기 때문에 효과성, 난이도, 시급도에 기반한 선별이 필요하다.

항목	내용
입력물	프로세스 개선 전략, 개선 활동
핵심 산출물	프로젝트 정의서, KPI 정의서, KPI 목표치 설정서
핵심 판단	무엇을 먼저 프로젝트화할 것인지, 어떤 지표로 추적할 것인지

실습 포인트

프로젝트 정의는 활동명을 그대로 옮겨 적는 작업이 아니다. 범위, 책임부서, 기대효과, 예산, 기간, 관련 현안까지 결합해 독립 실행 단위로 만들어야 한다.

7. 우선순위 선정과 프로젝트 정의

7.1 개선 우선순위 선정 접근방법

원본 P28~P31은 프로세스 개선 우선순위 평가를 효과성, 난이도, 시급도로 정량화한다. 효과성이 높은데 난이도가 지나치게 높지 않고, 시급성이 큰 과제가 초기 프로젝트로 적합하다는 판단 기준을 제공한다. 세 요소를 합산한 종합 평가치를 기준으로 프로세스를 그룹핑한다.

Figure 8. 원본 슬라이드의 프로세스 개선 우선순위 선정 접근방법 (P28)

평가기준	정의	평가 질문	예시 세부 항목
개선 효과성	개선 시 고객 · 조직 성과에 미치는 영향	개선했을 때 가치가 큰가	고객서비스 향상도, 처리시간 단축, 품질개선 폭
개선 난이도	실행의 복잡성 및 저항 수준	실행하기 쉬운가 어려운가	부서 관련도, 제도 변경 난이도, 기술 복잡도
개선 시급도	언제까지 선행되어야 하는가	지금 당장 필요한가	신시스템 일정 정합성, 리스크 회피 필요성

7.2 개선 우선순위 선정 기준표

원본 분석기법은 종합 평가치 = 개선 효과성 − 개선 난이도 + 개선 시급도라는 간단한 수식을 사용한다. 각 기준은 1~3점으로 정량화한다.

점수	효과성	난이도	시급도
3점	고객가치와 운영효율 개선 폭이 매우 큼	조직 · 제도 저항이 낮거나 관리 가능	향후 일정상 즉시 착수 필요
2점	의미 있는 개선 효과가 예상됨	추가 조정이 필요하지만 수행 가능	중기적으로 추진 필요
1점	효과가 제한적이거나 간접적임	복잡성, 비용, 저항이 큼	후순위로 미뤄도 큰 문제 없음

개념

종합 평가치가 높을수록 개선효과가 높고, 실행하기 상대적으로 쉬우며, 빠른 추진이 필요한 프로세스임을 나타낸다.

심화

정량 점수는 편리하지만 이해관계자 간 중요도 차이를 숨길 수 있다. 필요하면 가중치를 적용하거나 전략 적합성, 규제 리스크를 보조지표로 추가해야 한다.

Figure 9. 원본 슬라이드의 프로세스 그룹핑 결과 요약 (P33)

7.3 프로젝트 정의서 작성 방법

원본 P34는 프로젝트 정의서 템플릿을 제시한다. 프로젝트명, 개요, KPI, 주관부서, 관련 현안, 추진 시 고려사항, 기대효과, 실행기간, 소요예산 등의 항목은 PM 관점의 최소 요건이다. 이 양식을 채우는 행위 자체가 프로젝트의 실행 가능성을 미리 검증하는 과정이다.

Figure 10. 원본 슬라이드의 개선활동-개선프로젝트-KPI 연결 체계 (P29)

실습 포인트

프로젝트 정의서는 반드시 개선활동과 연결되어야 하고, KPI는 프로젝트 목적과 직접 연결되어야 한다. KPI가 프로젝트의 성공조건을 설명하지 못하면 형식적 지표가 된다.

8. KPI 설계와 목표치 설정

8.1 KPI 설계 원칙 표

원본 P35~P36은 KPI 정의서와 목표치 설정서 양식을 제공한다. 좋은 KPI는 측정 가능하고, 계산식이 명확하며, 데이터 소스와 책임자가 특정되어야 한다. 또한 목표치는 측정 주기별 단계 목표와 Action Plan이 함께 설계되어야 한다.

원칙	설명	확인 질문	실무 점검 항목
정의 명확성	지표의 의미와 산식이 분명해야 함	누가 봐도 같은 방식으로 계산 가능한가	분자 · 분모 · 단위 명시
데이터 추적성	필요 데이터와 소유 조직이 식별되어야 함	데이터를 어디서 가져오는가	시스템명, 생성부서, 책임자 지정
관리 가능성	프로젝트 팀이 통제 가능한 지표여야 함	지표 개선을 위해 실제 행동이 가능한가	통제 가능한 선행지표 포함
분해 가능성	원인 분석을 위해 drill-down 가능해야 함	목표 미달 시 원인을 추적할 수 있는가	세부 KPI 구조 설계
주기 적합성	성과 발현 주기에 맞는 측정 주기 필요	월 · 분기 · 반기 중 무엇이 적절한가	집계 리드타임 고려

개념

DMAIC의 Measure 단계와 Control 단계는 KPI 설계 품질에 직접 연결된다. 측정 정의가 불명확하면 개선 성과는 설명되지 않는다.

8.2 목표치 설정과 성과관리 밴드

목표치는 최종목표와 중간 목표로 나누어야 한다. 원본 KPI 목표치 설정 양식은 Final Target, 측정 주기별 목표, Action Plan, Performance Band를 포함한다. 이는 단순 숫자 제시가 아니라 관리 체계의 설계다.

구성 항목	작성 원칙
Final Target	프로젝트 종료 시점의 도달 수준을 명확한 수치나 상태로 정의
측정 주기별 목표	월 · 분기 · 반기별 중간 목표를 설정하여 궤도 이탈을 조기에 감지
Action Plan	목표 달성을 위한 핵심 실행 항목을 함께 기술
Performance Band	경고 · 보통 · 좋음의 기준값을 정하여 관리 반응 수준을 구체화

주의

성과관리에서 흔한 오류는 결과지표만 두고 선행 활동지표를 설계하지 않는 것이다. 고객 이탈률만 관리하면 원인 파악이 늦어진다. 접촉 빈도, 응답속도, 불만 해결시간 같은 보조 KPI가 필요할 수 있다.

Task 2 핵심 요약

Task 2는 개선활동을 프로젝트와 KPI 체계로 전환하는 단계다.
효과성, 난이도, 시급도의 균형이 우선순위 선정의 기본 기준이 된다.
KPI는 정의, 데이터, 책임, 목표치, 성과관리 밴드까지 포함해야 관리 도구가 된다.

PART IV

Task 3. 프로세스 개선 일정 및 자원계획

원본 P37~P41을 기반으로 프로젝트 일정화, 자원 계획화, 단계별 실행 전략을 설명한다.

9. Task 3 개요와 계획 방법

TASK 3

9.1 일정 및 자원계획의 목적

원본 P37은 프로세스 개선을 위한 일정과 소요 자원계획 수립을 목적으로 밝힌다. 프로젝트 정의서가 존재하더라도 일정과 자원이 없으면 실행이 불가능하다. Task 3은 프로젝트 간 선후관계를 고려한 Bar Chart 수준의 일정 설계와, 단계별 자원 수요를 연결하는 작업이다.

항목	내용
입력물	프로세스 개선 프로젝트 정의서
주요 산출물	프로세스 개선 일정계획, 자원계획
핵심 고려	프로젝트 간 선후관계, 자원 중복, 제도 · 시스템 일정 정합성

9.2 일정 및 자원계획 접근방법

원본 P38은 개선 프로젝트 정의서를 바탕으로 프로젝트별, 활동별 추진 일정을 수립하고, 일정별 자원계획을 수립한다고 설명한다. PMI 관점으로 보면 WBS 기반 일정 수립, 자원 산정, 의존관계 정의, 통합 마일스톤 정합화에 해당한다.

Figure 11. 원본 슬라이드의 일정 및 자원계획 접근방법 (P38)

개념: 프로젝트 정의서를 일정 네트워크로 변환한다.
실습: 선행과제, 병행과제, 제약조건, 승인 이벤트를 일정표에 반영한다.
심화: 정보시스템 구축, 제도개선, 교육 · 확산 일정과 통합해 마스터 플랜을 만든다.

실무 포인트

일정계획은 단순 Gantt 차트가 아니라 의사결정 흐름을 반영해야 한다. 제도 개정, 예산 승인, 시스템 개발, 현장 교육은 완료 기준이 다르므로 마일스톤을 명확히 구분해야 한다.

10. 일정 · 자원계획 사례

10.1 일정계획 사례 해설

원본 P39~P41은 대법원 사례와 기타 사례를 통해 일정과 자원계획 예시를 제시한다. 핵심은 개선 프로젝트의 실행이 단일년도 계획이 아니라 단계별 확산 구조를 가진다는 점이다.

Figure 12. 원본 슬라이드의 일정계획 관련 사례 이미지 (P40)

단계	주요 목표	대표 활동	자원 관점 시사점
도입기	기준 정립, 초기 파일럿	절차 표준화, 시범 운영, 교육 시작	전문 인력과 컨설팅 자원 집중
확산기	조직 전반 적용 확대	시스템 연계, KPI 운영, 현장 확산	현업 참여 인력과 운영예산 확대
고도화기	성과 정착과 지속 개선	고급 분석, 성과 고도화, 재설계	내부화 역량과 데이터 분석 자원 강화

개념

PDCA 사이클 관점에서 일정계획은 단순 착수와 종료가 아니라, 점검과 보정의 리듬까지 포함해야 한다.

주의

자원계획을 인건비만으로 축소하면 실패한다. 교육, 변화관리, 데이터 정비, 외부 자문, 품질관리 활동까지 포함한 총자원 관점이 필요하다.

Task 3 핵심 요약

Task 3은 프로젝트 정의를 실행 로드맵으로 변환하는 단계다.
선후관계와 승인 이벤트를 반영한 일정 설계가 중요하다.
자원계획은 인력, 예산, 교육, 변화관리, 기술 지원을 함께 고려해야 한다.

PART V

실습 과제 및 모범답안

원본 P42~P47의 실습 양식을 학습용으로 재구성하여 프로젝트 정의와 KPI 설계 연습에 활용할 수 있게 정리한다.

11. 실습 과제 및 모범답안

PRACTICE

11.1 실습 과제 작성 가이드

원본 실습 과제는 하나의 프로세스 개선 활동을 선택하고, 해당 활동을 프로젝트 정의서와 KPI 정의서, KPI 목표치 설정서 형태로 완성하는 연습이다. 이 과제는 Task 1과 Task 2의 연결을 몸으로 익히는 데 매우 효과적이다.

실습 단계	작성 질문
프로젝트 선택	어떤 개선 활동을 독립 실행 단위의 프로젝트로 전환할 것인가
프로젝트 정의서 작성	개요, 주관부서, 관련 현안, 예산, 기간, 기대효과는 무엇인가
KPI 정의서 작성	무엇을 어떤 산식으로 측정하며, 데이터는 어디서 오고 누가 책임지는가
목표치 설정	최종 목표와 중간 목표, Action Plan, 성과관리 밴드는 무엇인가

실습 포인트

모범답안을 보기 전에 먼저 자신이 선택한 프로젝트의 성공조건을 한 문장으로 정의해 보면 KPI 설계가 훨씬 쉬워진다.

11.2 모범답안 해설 (우량고객 관계 강화 프로젝트)

원본 모범답안은 우량고객 관계 강화 프로젝트를 예시로 사용한다. 금융 시장 경쟁이 치열해지는 상황에서 우량고객을 발굴하고, 차별화된 상품 · 서비스를 제공하여 지속적인 관계를 유지하는 것이 프로젝트의 목적이다. 여기서 중요한 점은 프로젝트 목표, KPI, 목표치, Action Plan이 일관되게 연결된다는 것이다.

항목	모범답안 내용
프로젝트명	우량고객 관계 강화
KPI	우량고객 이탈률, 우량고객 1인당 수익, 우량고객 비율
KPI 목표 예시	우량고객 이탈률: 2003년 5% → 2004년 3%
Action Plan	우량고객별 전담 직원 배정, 우량고객 해피콜 실시
Performance Band	경고 / 보통 / 좋음 구간 기준값 설정

개념

좋은 모범답안은 양식을 예쁘게 채운 문서가 아니라, 목적-지표-데이터-행동의 정합성이 높은 문서다.

심화

교육용 예시는 민간 서비스 시나리오를 사용하지만, 공공부문에서는 고객가치 대신 민원처리시간, 오류율, 처리일관성, 법정기한 준수율 같은 지표로 바꿔 적용할 수 있다.

12. 참고문헌

본 문서는 사용자 제공 PPT 파싱 내용과 슬라이드 이미지 URL을 기반으로 재구성되었으며, 아래 고전적 프레임워크를 이론적 배경으로 활용하였다.

Hammer, M., & Champy, J. (1993). Reengineering the Corporation: A Manifesto for Business Revolution. New York: Harper Business.
Kotter, J. P. (1996). Leading Change. Boston: Harvard Business School Press.
Deming, W. E. PDCA 사이클 관련 품질개선 방법론.
Six Sigma DMAIC 방법론 관련 일반 프레임워크 (Define-Measure-Analyze-Improve-Control).
Lean 방법론의 낭비 제거 원칙 (Toyota Production System 기반).
PMI. A Guide to the Project Management Body of Knowledge (PMBOK Guide) 기반 일정 · 자원 관리 관점.
원본 슬라이드 자료: C005_프로세스개선계획수립_v2.0819(47).ppt (47페이지)

정보관리체계 수립

지능한글 — Sat, 4 Jul 2026 21:03:09 +0900

정보관리체계 수립

A13 MANAGEMENT FRAMEWORK SERIES

정보관리체계 수립

조직, 보안, 유지보수, 품질관리의 네 축을 통합하여 정보자원의 안정적 운영과 지속적 개선을 구현하는 실무형 단행본

원본 기반: C004_정보관리체계수립_v2.0819(44).ppt · 변환일: 2026-06-30

Figure 1. 정보관리체계 수립의 전체 공정도

개요와 통합 프레임워크

정보관리체계는 정보조직, 보안관리, 유지보수, 품질관리를 하나의 운영체계로 결합해 정보자원의 전략적 활용과 안정적 서비스 제공을 동시에 달성하는 기반이다.

OVERVIEW 01

정보관리체계 수립의 목적

원문은 정보관리체계 수립의 목적을 정보자원의 효율적 운영을 위한 새로운 비전과 임무 도출, 관리 프레임워크와 프로세스 설계, 그리고 보안·유지보수·품질 관리 방안 수립으로 제시한다. 이 책에서는 그 구조를 조직설계와 운영통제의 결합 관점에서 해석한다.

Figure 2. 정보관리체계 수립의 목적과 구성요소

개념

정보관리체계는 단순히 전산부서의 운영 매뉴얼을 정리하는 작업이 아니다. 이는 정보자원에 대한 책임 구조를 정의하고, 위험을 통제하며, 변화 요구를 서비스 수준 안에서 처리하고, 개발·운영 산출물의 품질을 일관되게 관리하는 종합 거버넌스 체계다. 다시 말해 조직 설계, 통제 설계, 운영 설계, 품질 설계가 끊김 없이 이어지는 하나의 운영체제를 만드는 일이다.

핵심 배경

COBIT는 거버넌스와 통제를, ITIL은 서비스 운영과 지원을, ISO/IEC 27001은 보안관리체계를, ISO/IEC 20000은 서비스관리체계를, ISO/IEC 25010은 소프트웨어 품질 특성을 구조화한다. 정보관리체계 수립은 이들 프레임워크의 관점을 현업 환경에 맞게 통합하는 실무 작업으로 이해할 수 있다.

실습

정보자원 운영 목표를 경영 목표와 연결하고, 어떤 서비스가 핵심 가치창출에 기여하는지 식별한다.
운영조직, 보안조직, 유지보수조직, 품질관리조직 간의 역할 중복과 공백을 진단한다.
정책, 표준, 절차, 점검, 피드백의 선순환 구조를 설계하여 운영체계가 문서에 머물지 않고 실행되도록 한다.

심화

실무에서 정보관리체계가 실패하는 가장 흔한 이유는 각 분야가 개별 최적화되기 때문이다. 조직은 사람과 권한만 논하고, 보안은 통제만 강화하며, 유지보수는 복구와 장애 처리만 강조하고, 품질은 문서 체크리스트에 머무르는 경우가 많다. 통합 설계의 초점은 네 영역이 동일한 운영 원칙과 의사결정 라인을 공유하도록 만드는 데 있다.

주의

보안, 유지보수, 품질을 별도 매뉴얼로 분리해 작성하더라도 최종 승인권자, 변경관리 절차, 사고보고 라인이 분리되어 있으면 실제 운영에서 충돌이 발생한다. 체계 수립 단계에서 공통 의사결정 구조를 먼저 정의해야 한다.

OVERVIEW 02

정보관리체계 4대 영역 비교표

원본 자료는 네 개의 Task를 독립된 관리영역으로 설명한다. 이를 단행본 관점에서 재구성하면 각 영역은 목적, 통제대상, 핵심 산출물, 대표 기준체계, 운영 리듬이 다르다. 아래 비교표는 이후 장을 읽기 위한 전체 지도 역할을 한다.

영역	핵심 목적	주요 관리대상	대표 산출물	주요 기준체계
조직	책임과 권한, 인력 운영, 의사결정 구조 정립	조직구조, 직무, 역량, 경력경로, 위원회	조직구성안, 인력운영안, 역할정의서	COBIT 거버넌스 관점, RACI, 조직설계 원칙
보안	정보자산의 비밀성·무결성·가용성 확보	정책, 접근권한, 물리·기술·관리적 통제	보안관리 기준 및 절차, 점검체계, 복구계획	ISO/IEC 27001, 위험관리, 보안운영 절차
유지보수	서비스 지속성 확보와 장애·재해 대응	장애이력, 변경이력, 자산, 예비부품, 복구센터	유지보수 원칙, 장애대책, 재해복구 방안	ITIL 운영관리, ISO/IEC 20000, BCP/DR
품질	개발·운영 산출물의 일관성과 적합성 확보	표준문서, 검토체계, 테스트, 형상관리	SPM, 품질보증계획, 검토 및 테스트 절차	ISO/IEC 25010, PMBOK 품질관리, CMM/SPICE

실무 포인트

네 영역의 설계 단위를 분리하되 운영 단위는 연결해야 한다. 예를 들어 유지보수 절차의 변경승인은 조직 거버넌스와 연결되고, 보안 통제의 예외 승인도 품질·운영 기록과 연결되어야 한다.

PART II

Task 1. 정보조직 체계 정립

조직 체계는 정보관리체계 전체의 시작점이다. 어떤 조직구조를 채택하고 어떤 경력경로를 설계하느냐에 따라 이후 보안, 유지보수, 품질관리의 실행력이 결정된다.

TASK 1 · CONCEPT

개념과 설계 원리

원본은 정보조직이 환경변화에 둔감하거나 현업과 괴리를 보일 수 있으며, 인력구성·보상·교육훈련·인사제도 측면에서 여러 문제점을 가질 수 있다고 지적한다. 이에 대한 해법으로 효율적인 조직구조 설계와 바람직한 경력경로 설계를 제시한다.

Figure 3. 정보조직 체계 정립을 위한 접근방법

개념

조직 설계는 단순한 부서 편제가 아니라 전략·기술·현업 수요를 연결하는 운영 구조를 정하는 일이다. 원문이 제시한 두 축은 매우 실무적이다. 첫째, 조직구조는 환경과 기술, 조직규모에 적합해야 한다. 둘째, 경력경로는 전산직에게 비전과 성장 가능성을 제공해야 한다. 이 둘이 함께 설계될 때 조직은 장기적으로 안정성을 갖는다.

이론 보강

COBIT의 관점에서 보면 조직체계는 EDM(평가·지시·모니터링)과 APO(계획·구축) 영역의 책임 구조를 구현하는 장치다. 즉 누가 투자 우선순위를 정하고, 누가 운영 위험을 감시하며, 누가 성과를 모니터링하는지를 명확히 해야 한다.

실습

현행 조직의 업무분장표와 실제 수행업무를 비교해 공식 구조와 비공식 구조의 차이를 파악한다.
기획, 개발, 운영, 사용자지원, 보안, 품질의 여섯 기능을 기준으로 필수 역할을 식별한다.
정규직, 전문직, 외주인력, 협력업체 인력의 혼합 구조에서 어떤 역할을 내부화할지 결정한다.

심화

원문이 강조한 경력경로설계(CDP)는 단순한 HR 제도가 아니라 운영 리스크를 줄이는 장치이기도 하다. 특정 기술과 시스템 지식이 일부 개인에게 집중되면 조직은 장애와 이직에 취약해진다. 계획-설계-실천-통제의 CDP 주기는 기술자산의 지속가능성을 확보하는 구조다.

Figure 4. CDP 기반 경력경로설계 추진 방안

주의

조직구조를 먼저 확정하고 나중에 인력육성을 고민하면 조직도는 남지만 역량은 남지 않는다. 역할과 역량, 교육과 배치, 승진과 평가가 같이 설계되어야 한다.

TASK 1 · PRACTICE

실습 접근과 사례

원문은 설문과 인터뷰를 통해 현행 정보조직의 문제점을 파악하고, 그 결과를 토대로 조직 체계 수립안을 제시하는 방식을 제안한다. 또한 대법원 호적정보화 사례와 국세청 사례를 통해 조직구성 및 인력운영의 실제 예를 보여 준다.

Figure 5. 조직구성체계안 사례

대법원 사례에서 흥미로운 점은 정보화 의사결정권자, 기획·조정, 사업 및 운영관리, 시스템 개발, 사용자 지원, 시스템 운영 및 통제 등 기능을 세분화했다는 것이다. 이는 조직을 사람 기준이 아니라 기능 기준으로 바라보는 접근이다. 또한 연차별 인원계획을 통해 단계적 증설과 외부 전문인력 활용을 설계했다.

기능	주요 책임	운영 시사점
정보화 기획·조정	중장기 전략, 예산, 우선순위, 인력운용, 사업평가	조직 전체의 방향성과 투자 통제를 담당하는 핵심 축
사업 및 운영관리	프로젝트 관리, 외주업체 관리, 운영조직 관리	기획과 실행 사이의 조정 기능을 맡아야 함
사용자 지원	요구사항 접수, 교육, 만족도 조사, 지침 관리	운영 품질과 현업 수용성을 높이는 접점 기능
시스템 운영 및 통제	운영, 백업·복구, 네트워크·DB·프로그램 자원 관리	보안·유지보수와 밀접히 연결되는 상시 운영 기능

Figure 6. 전사조직의 종합적인 경력설계 사례

사례 해석

국세청 사례는 초임자 교육, 의무근무, 직군 편성, 교육훈련의 조화라는 경력 설계 논리를 보여 준다. 즉 조직 운영은 채용 이후의 배치와 육성 체계까지 포함해야 한다.

TASK 1 · DEEP DIVE

심화: 운영 거버넌스와 RACI

조직체계를 실제로 작동시키려면 기능 정의만으로는 부족하다. 주요 의사결정과 운영 절차마다 누가 책임지고 승인하며 협의하고 통보받는지 정해야 한다. 이를 위해 RACI 표가 유용하다.

운영 활동	CIO/총괄	정보기획	보안관리자	운영관리자	품질담당
정보화 연간계획 수립	A	R	C	C	I
보안정책 개정	A	C	R	C	I
장애대응 및 복구 승인	I	C	C	R/A	I
품질검토 결과 승인	I	C	I	C	R/A
외주업체 성과평가	A	R	C	C	C

해석

RACI는 조직도를 대체하는 것이 아니라 조직도를 운영 가능한 책임체계로 변환하는 장치다. 특히 보안, 운영, 품질이 교차하는 활동에서는 승인권자와 실행책임자의 분리가 중요하다.

Task 1 핵심 요약

조직구조 설계와 경력경로 설계는 함께 가야 한다.
기능 중심 구조, 단계적 인력계획, 외부 전문성 활용이 핵심 설계 포인트다.
운영 거버넌스는 RACI 수준까지 구체화해야 실제 실행력이 생긴다.

PART III

Task 2. 보안관리 방안 수립

보안관리 방안은 정보자산과 시설을 보호하기 위한 통제 설계이자 운영절차 설계다. 정책, 역할, 플랫폼별 기준, 점검 및 복구계획을 통합적으로 다뤄야 한다.

TASK 2 · CONCEPT

보안정책과 기준체계

Figure 7. 정보기술 보안정책과 수립 접근방법

원문은 정보기술 보안을 비밀성, 무결성, 가용성, 책임추적성, 인증성, 신뢰성으로 설명하고, 정보기술 보안정책을 정보 및 관련 자산이 조직 내에서 어떻게 관리·보호·분배되는지에 관한 규칙과 지침으로 정의한다. 또한 보호 대상 정의, 위협 정의, 위험요소 파악, 비용효과적 보호수단 적용, 지속적 개선의 순서를 제시한다.

개념

이 접근은 현재의 ISO/IEC 27001 위험기반 관리체계와도 일치한다. 즉 보안은 장비 도입의 문제가 아니라 자산과 위협, 취약점, 통제, 모니터링의 연쇄를 설계하는 문제다. 따라서 보안정책은 선언문이 아니라 위험판단 기준과 운영행동 기준을 동시에 담아야 한다.

이론 보강

ISO/IEC 27001 관점에서 보안관리체계는 정책 수립, 자산 식별, 위험평가, 통제선정, 운영, 점검, 내부감사, 개선의 PDCA 사이클로 이해할 수 있다. 원문의 보안체계 구축 8단계는 이를 실무 언어로 풀어 쓴 구조에 가깝다.

실습

보호 대상 자산을 데이터, 시스템, 네트워크, 인력, 시설로 구분해 목록화한다.
각 자산에 대해 위협 시나리오와 영향도를 정의하고 우선순위를 설정한다.
관리적, 물리적, 기술적 통제를 구분하여 적용 기준을 만든다.

심화

보안정책은 과도하게 상세하면 준수되지 않고, 지나치게 포괄적이면 통제력이 없다. 따라서 정책-표준-절차-지침의 위계를 유지해야 한다. 정책은 원칙, 표준은 준수 기준, 절차는 수행 순서, 지침은 실무 팁을 담는 방식이 바람직하다.

주의

모든 플랫폼에 동일한 보안 강도를 요구하면 실제 운영상 예외가 과도하게 발생한다. 핵심 시스템과 일반 시스템의 보호수준을 구분해 설계해야 한다.

TASK 2 · PRACTICE

실습: 보안운영 절차 설계

Figure 8. 플랫폼별 보안지침과 핵심시스템 보안

원문은 LAN/WAN, 방화벽, 클라이언트/서버, 인터넷·인트라넷, Unix, NT, PC, 바이러스 대응 등 플랫폼별 보안지침을 구체적으로 제시한다. 이는 보안정책을 실제 운영기준으로 번역하는 과정이다. 또한 네트워크 보안, 시스템 보안, 응용시스템 보안을 구분하고 응용시스템은 사용자 인증과 권한의 관점에서 접근해야 한다고 설명한다.

Figure 9. 네트워크·시스템·응용시스템 보안의 적용 구조

특히 응용시스템의 인증과 권한 기능을 프로그램과 독립된 모듈 라이브러리로 구성하라는 제안은 오늘날 IAM, SSO, 권한정책 엔진 설계와 통하는 관점이다. 정책 변경에 신축적으로 대응하려면 보안 기능을 애플리케이션 코드에 흩뿌리지 않고 공통 통제 모듈로 구현해야 한다.

보안영역	원문 핵심 포인트	실무 적용 포인트
네트워크 보안	망 분리, 방화벽 단일 접점화, Deny all 기본정책	접근경로 최소화, 예외정책 승인 절차, 변경이력 관리
시스템 보안	서버별 취약점 제거, 불필요 계정 차단, 관리자 권한 통제	하드닝 표준, 정기점검 체크리스트, 패치정책 수립
응용 보안	사용자 인증, 권한 제어, 배포 통제	권한모델 표준화, 로그 추적성, 계정관리 자동화
물리·단말 보안	출입통제, 부팅 비밀번호, 백신 최신화	자산관리와 연계한 단말통제, 정책 준수 점검

Figure 10. 보안체계 구축계획과 8단계 운영구조

실무 포인트

정책 개발, 책임 정의, 프레임워크 설계, 시스템 구현, 교육훈련, 정보망 운영, 평가 인증, 보안감사의 흐름은 보안관리체계를 일회성 프로젝트가 아니라 운영체계로 만드는 최소 조건이다.

TASK 2 · DEEP DIVE

심화: ISO/IEC 27001과 연계한 운영 설계

원문 후반의 보안점검절차와 단계별 보안정립 사례는 단순 사례 제시가 아니라 운영관리 관점의 핵심을 담고 있다. 보안은 구축이 아니라 점검과 시정조치, 재평가의 순환 구조 안에서 유지된다.

예를 들어 보안점검 계획서 작성, 검토, 승인, 점검 실시, 문제점 정리, 결과보고서 작성, 시정 통보, 확인·보고의 절차는 ISO/IEC 27001의 내부심사와 시정조치 흐름으로 해석할 수 있다. 또한 1단계부터 3단계까지 관리적·물리적·기술적 보안을 나누어 수행한 사례는 보호대책을 단계별로 진화시키는 로드맵의 예시다.

권장 연계 구조

보안정책, 자산목록, 위험평가 결과, 접근권한 승인기록, 보안점검 결과, 시정조치 추적표를 하나의 관리 저장소에서 연결하면 보안감사 대응성과 운영 추적성이 크게 향상된다.

Task 2 핵심 요약

보안정책은 자산·위협·통제·운영 절차를 함께 다루는 체계여야 한다.
네트워크, 시스템, 응용, 물리 영역별 기준을 구분하면서도 공통 승인 체계를 유지해야 한다.
점검과 시정조치의 반복 구조가 있어야 보안이 실제 관리체계가 된다.

PART IV

Task 3. 유지보수 방안 수립

유지보수는 단순 장애처리를 넘어 예방정비, 변경이력관리, 장애·재해대응, 백업·복구, 아웃소싱 관리까지 포함하는 서비스 지속성 관리체계다.

TASK 3 · CONCEPT

유지보수 원칙과 범위

Figure 11. 정보시스템 유지보수 원칙

원문은 유지보수의 목적을 유지보수 항목 도출, 항목별 절차 수립, 변경이력관리 방안 수립으로 제시한다. 또한 인적자원, 부품 및 장비, 유지보수체계, 관련기술이라는 네 가지 요건을 기반으로 효율적이고 안정적인 유지보수가 이뤄져야 한다고 설명한다.

개념

유지보수는 결함 발생 후 조치만을 뜻하지 않는다. 예방정비, 성능관리, 변경관리, 구성관리, 장애관리, 재해복구가 모두 유지보수 체계 안에 포함된다. 따라서 운영 조직은 단순 기술 지원 조직이 아니라 서비스 수준과 가용성 목표를 책임지는 운영 주체가 된다.

이론 보강

ITIL 관점에서 유지보수는 Incident Management, Problem Management, Change Enablement, Service Continuity Management와 긴밀히 연결된다. 원문의 장애·재해 대책과 변경이력관리 요구는 이러한 운영 프로세스의 국내 실무형 표현으로 볼 수 있다.

실습

애플리케이션, 하드웨어, 네트워크, 데이터, 운영시설 단위로 유지보수 대상을 분류한다.
각 대상별 예방활동, 정기점검 주기, 장애대응 절차, 복구 목표를 정의한다.
장애이력과 변경이력을 같은 체계 안에서 관리해 원인분석과 재발방지를 가능하게 한다.

심화

원문이 강조하는 예방 정비는 단순 점검이 아니라 운영 데이터 기반의 사전 대응을 의미한다. 장애 이력의 누적, 유형 분류, 교육과 표준화는 곧 지식관리이자 운영품질 향상 수단이다.

TASK 3 · PRACTICE

실습: 장애·재해 대응 설계

Figure 12. 장애 및 재해 유형과 대응 관점

원문은 운영자의 실수, 자연재해, 기계적 오류 등 다양한 원인에 의해 전산 장애와 재해가 발생한다고 보고, 전산시스템장애, 일반재해, 사고 및 과실, 기타 환경위험을 구분한다. 또한 장애·재해대책 수립 절차를 통해 예방활동과 복구방안을 동시에 설계해야 한다고 설명한다.

Figure 13. 소프트웨어 유지보수 활동 예시

소프트웨어 유지보수에서는 테스트 강화, 충분한 주석, 데이터 복구, 응용프로그램 변경관리, 작업지침, 장애이력 유지, 유형분류를 제시한다. 하드웨어와 네트워크 유지보수에서도 장애이력 분석과 공급업체 협업, 상시 장애접수체계가 강조된다. 이는 단순 복구보다 운영 프로세스의 표준화가 더 중요하다는 점을 보여 준다.

유지보수 영역	원문의 중점 활동	운영 설계 시 반영사항
소프트웨어	테스트 강화, 변경관리, 장애이력 유지	릴리스 승인 기준, 결함관리, 버전관리, 재배포 기준
하드웨어	공급업체 연계, 상시 접수, 표준화 교육	예비부품 정책, 제조사 SLA, 정기점검 달력
네트워크	협력업체 활용, 운영지원, 장애접수 상시화	망 구성도 최신화, 변경승인, 장애전파 기준
재해복구	백업센터 활용, 원격지 복구, 서비스 지속성 확보	복구 목표시간, 복구 목표시점, 전환훈련 계획

Figure 14. 백업센터 위치 선정 및 운영 절차

실무 포인트

원문 사례는 백업센터의 위치 선정에서 지리적 거리, 통신비용, 기존 센터와의 통합 운용, 설비 공유 가능성까지 고려한다. 이는 재해복구가 기술적 선택이 아니라 비용·운영·연계성의 종합 판단이라는 점을 보여 준다.

TASK 3 · DEEP DIVE

심화: ITIL 기반 서비스 운영과 아웃소싱 판단

원문은 아웃소싱에 의한 유지보수의 장단점을 비교하면서 비용 절감과 전문성 확보라는 장점, 통제 상실과 보안문제 가능성이라는 단점을 동시에 제시한다. 또한 국가 주요정보를 다루는 시스템에서는 핵심 책임은 내부가 가지고 실무 인력만 전문업체를 활용하는 방향을 제안한다.

이는 ITIL 서비스 운영에서도 중요한 원칙이다. 서비스 제공의 책임은 내부 서비스 소유자가 가져가되, 운영 수행은 외부와 협업할 수 있다. 즉 운영을 위탁하더라도 책임을 위탁할 수는 없다. 장애, 변경, 문제, 가용성, 연속성에 대한 최종 승인과 성과측정은 내부 조직이 유지해야 한다.

주의

아웃소싱 계약이 SLA 숫자만 명시하고 장애분석, 지식이전, 보안준수, 변경통제, 종료 시 인수인계까지 규정하지 않으면 장기적으로 운영 품질이 약화된다.

Task 3 핵심 요약

유지보수는 예방, 대응, 복구, 변경, 지식축적을 포함하는 운영체계다.
장애 및 재해대응은 기술 설계와 운영 절차 설계를 동시에 요구한다.
아웃소싱은 가능하지만 서비스 책임과 통제는 내부에 남겨야 한다.

PART V

Task 4. 품질관리 방안 수립

품질관리는 표준과 절차, 검토와 테스트, 형상관리와 개선활동을 통해 시스템 개발·운영 산출물이 요구수준을 충족하도록 보장하는 체계다.

TASK 4 · CONCEPT

품질보증과 표준화

Figure 15. 품질보증 활동의 목표와 수행항목

원문은 품질보증 활동을 제품 또는 서비스가 주어진 품질조건을 만족시킬 것이라는 적절한 신뢰감을 주는 계획적·체계적 활동으로 정의한다. 또한 과업 착수부터 유지보수까지 종합적인 품질관리 체제를 지향하며, 표준 및 절차 매뉴얼(SPM)을 통해 각종 절차, 표준, 척도를 정의해야 한다고 설명한다.

개념

품질관리의 핵심은 좋은 결과를 사후에 판정하는 것이 아니라, 좋은 결과가 반복해서 나오도록 작업 방식을 표준화하는 데 있다. 따라서 품질관리 체계는 문서표준, 분석표준, 검토표준, 테스트표준, 형상관리 표준의 다층 구조를 가져야 한다.

이론 보강

ISO/IEC 25010은 기능적합성, 성능효율성, 사용성, 신뢰성, 보안성, 유지보수성, 이식성 등 품질 특성을 제시한다. PMBOK 품질관리 관점은 품질계획, 품질보증, 품질통제를 통해 프로젝트 수행과 산출물을 동시에 관리하게 한다. 원문의 SPM과 품질보증활동은 이 둘을 현업 문서 체계로 연결하는 역할을 한다.

실습

프로젝트 수행단계별 필수 산출물과 검토 포인트를 정의한다.
문서번호 체계, 버전관리 규칙, 승인 절차를 표준화한다.
품질활동을 일정과 역할에 매핑해 계획서에 반영한다.

TASK 4 · PRACTICE

실습: 품질활동과 검토체계

Figure 16. 표준 및 절차 매뉴얼 작성 구조

원문은 SPM을 프로젝트 문서의 품질을 보증하기 위한 장치로 설명하며, 프로젝트 수행작업 체계와 산출물 계층구조, 번호 부여 원칙을 제시한다. 또한 분석표준으로 워크숍, 인터뷰, 설문, 모델링 등 다양한 분석활동에 필요한 표준 절차와 템플릿을 마련해야 한다고 설명한다.

Figure 17. 개발표준 및 품질보증방안 절차

후반부에서는 품질보증활동을 확인(Verification)과 검증(Validation)으로 구분하고, 품질보증계획수립, 품질검토, 테스트, 형상관리를 주요 활동으로 제시한다. 특히 품질활동별 책임자와 시기를 명시한 점은 품질을 일정 내 활동으로 운영하겠다는 의미다.

품질활동	핵심 내용	주요 책임자	운영 포인트
품질보증계획수립	프로젝트 품질기준과 활동 정의	PM	착수 단계에서 범위와 기준을 확정해야 함
품질검토	산출물 워크스루 및 리뷰 수행	PM, 현업 담당	단계 완료 시점마다 수행해 재작업 비용을 줄임
테스트	단위·통합·시스템·인수 테스트와 결함관리	개발자, 분석/설계자, 인수책임자	테스트 결과를 결함추적과 연결해야 함
형상관리	형상요소 지정과 변경통제	품질담당자	전 단계에 걸쳐 일관되게 적용해야 함

실무 포인트

문서표준과 검토표준은 별개가 아니다. 문서 구조가 표준화되어야 검토 포인트도 체계화되고, 검토 포인트가 표준화되어야 품질측정이 가능해진다.

TASK 4 · DEEP DIVE

심화: ISO/IEC 25010과 PMBOK 품질관리 관점

원문의 품질활동은 전통적인 개발 방법론 문맥에서 서술되지만, 현대적 해석을 더하면 품질은 문서 품질과 시스템 품질, 서비스 품질을 동시에 다뤄야 한다. ISO/IEC 25010의 품질 특성은 설계와 테스트 기준으로 활용할 수 있고, PMBOK의 품질관리 관점은 프로젝트 계획과 통제의 프레임으로 적용할 수 있다.

예를 들어 기능적합성은 요구사항과 테스트 시나리오 정합성으로, 성능효율성은 응답시간과 용량 기준으로, 유지보수성은 모듈화와 변경용이성 기준으로, 보안성은 접근통제와 로그관리 기준으로 구체화할 수 있다. 품질보증활동은 이러한 품질 특성이 실제 산출물과 운영 절차 안에 반영되었는지를 점검하는 역할을 한다.

주의

품질관리 문서를 많이 만드는 것만으로 품질이 올라가지는 않는다. 검토 결과가 변경관리, 테스트, 교육, 운영개선으로 이어지지 않으면 품질체계는 형식화된다.

Task 4 핵심 요약

품질관리의 핵심은 결과 평가보다 작업 방식의 표준화와 반복 가능성 확보에 있다.
SPM, 검토, 테스트, 형상관리는 하나의 연결된 품질운영 체계로 설계되어야 한다.
ISO/IEC 25010과 PMBOK 관점을 접목하면 품질기준과 관리활동을 더 체계화할 수 있다.

PART VI

과제 및 평가

원문은 보안관리방안 수립 실습과 조별 발표 평가를 제시한다. 이 책에서는 이를 학습성과와 문서 완성도를 함께 보는 평가 프레임으로 정리한다.

ASSESSMENT

실습과제와 평가 기준

원문 실습과제는 주어진 예를 활용하여 보안관리 방안을 수립하고 관련 조직을 정의하는 것이다. 이는 앞선 네 개 Task를 종합 적용하는 통합 과제로 볼 수 있다. 실제로 보안관리 방안을 잘 수립하려면 조직체계, 유지보수 절차, 품질관리 기준이 함께 반영되어야 한다.

Figure 18. 보고서 구성 및 내용 평가 기준

평가영역	원문 키워드	해석
보고서 형태	단순성, 간결성, 예술성	한눈에 이해되는 구조, 부담 없는 시각 구성, 전달력 있는 페이지 설계
보고서 내용	창조성, 논리성, 전문성	독창적 접근, 논리적 흐름, 도메인 지식을 반영한 분석과 제안
발표 수행	발표자료 수준, 발표 수준	내용 요약 능력, 전달력, 질의응답 대응력까지 포함한 수행 평가

활용 제안

실습과제 평가표를 만들 때는 각 항목을 5점 척도 등으로 계량화하고, 보고서 품질과 운영적합성, 실행가능성을 함께 평가하는 것이 바람직하다. 특히 보안방안의 경우 통제 강도만이 아니라 운영 지속성과 사용자 수용성도 함께 봐야 한다.

정보시스템 구조 정의

지능한글 — Sat, 4 Jul 2026 21:02:02 +0900

A12 정보시스템 구조 정의

PPT 기반 단행본 HTML

A12 정보시스템 구조 정의

어플리케이션, 데이터, 기술, 통합 구조를 연결하는 정보시스템 아키텍처 실무 교재

원본 자료: C003_정보시스템구조정의_v2.0819(46).ppt

구성 방식: 슬라이드 핵심 내용을 바탕으로 개념, 실습, 심화 관점을 보강한 단행본형 문서

1. 개요

정보시스템 구조 정의는 정보화 전략을 구체적으로 실현하기 위해 어플리케이션, 데이터, 기술 측면의 구조를 정리하고, 이를 기반으로 향후 통합 정보시스템 구축 구조를 도출하는 과정이다. 원본 슬라이드는 최신 기술 자체보다 경영전략을 효과적으로 지원할 수 있는 정보기술을 정의하는 것이 더 중요하다고 강조한다.

Figure 1. 정보시스템 구조 정의의 목적과 고려사항

개념 보강

정보시스템 구조 정의는 단순한 시스템 구성도 작성이 아니다. 업무 프로세스, 데이터, 기술 인프라, 시스템 통합 방식을 하나의 설계 언어로 맞추는 아키텍처 작업이다. 전사적 관점이 없으면 각 시스템은 부분 최적화에 머물고, 통합 시점에는 중복 데이터, 중복 기능, 복잡한 인터페이스가 발생한다.

Practice

공정도와 수행절차

수행절차는 먼저 정보화 전략과 To-Be 프로세스 산출물을 검토한 뒤, 어플리케이션 구조, 데이터 구조, 기술 구조를 각각 정의하고 마지막으로 통합 시스템 구성도를 작성하는 흐름이다. 원본 자료의 수행절차는 네 가지 구조정의 태스크를 서로 독립된 산출물이 아니라 상호 검증되는 설계 단위로 다룬다.

Figure 2. 정보시스템 구조 정의 공정도

어플리케이션 구조정의: 정보시스템 영역을 분할하고 후보 어플리케이션, 상관도, 인터페이스 요건을 정리한다.
데이터 구조정의: 정보 요구와 현황 분석 결과를 바탕으로 엔티티, 주제 데이터베이스, 소유권을 정의한다.
기술 구조정의: 어플리케이션과 데이터 구조가 요구하는 기술요건을 TBB로 통합하고 표준화 방향을 정한다.
통합 구조정의: 데이터, 어플리케이션, 기술 관점을 묶어 물리적, 논리적 시스템 구성도를 완성한다.

Figure 3. 정보시스템 구조정의 수행방법

Deep Dive

구조 정의가 실패하는 전형적 원인

구조정의 실패는 보통 기술 선정의 실패보다 앞선다. 업무와 데이터의 경계가 정리되지 않은 상태에서 기술 플랫폼을 먼저 선택하거나, 어플리케이션 목록은 있으나 인터페이스와 데이터 소유권이 빠진 경우 통합 구조가 흔들린다.

주의사항

구조정의는 특정 솔루션 도입 계획서가 아니다. 솔루션 이름보다 업무 기능, 데이터 책임, 기술 표준, 연계 방식이 먼저 정의되어야 한다. 특히 전 공정 산출물인 정보전략, 신 프로세스 기술서, 데이터 현황, 기술 원칙을 적극적으로 재사용해야 한다.

CHAPTER 02

정보시스템 아키텍처 이론적 기초

TOGAF, Zachman, 4대 구조 프레임워크의 연결

Concept

2. 이론적 기초

TOGAF Standard는 The Open Group이 제공하는 엔터프라이즈 아키텍처 방법론 및 프레임워크로, 조직의 일관된 표준, 방법, 커뮤니케이션을 지원하는 표준으로 설명된다.1 본 교재의 정보시스템 구조 정의는 TOGAF의 정보시스템 아키텍처 관점인 어플리케이션과 데이터, 그리고 기술 아키텍처 관점을 실무 산출물 중심으로 재구성한 것으로 이해할 수 있다.

Zachman Framework는 What, How, When, Who, Where, Why라는 질문 축과 추상화 수준을 결합한 6x6 매트릭스 형태의 엔터프라이즈 설명 체계이며, 방법론이 아니라 엔터프라이즈를 기술하기 위한 온톨로지로 설명된다.2

이론과 실무의 연결

TOGAF가 아키텍처 개발의 절차와 거버넌스를 강조한다면, Zachman은 무엇을 빠짐없이 기술해야 하는지에 대한 분류 틀을 제공한다. C003 자료의 네 가지 구조정의는 이론 프레임워크를 현장 산출물인 구조도, 명세서, 매트릭스, 표준안으로 바꾸는 실무 절차다.

Practice

4대 구조정의 비교표

구분	핵심 질문	주요 입력물	대표 기법	대표 산출물
어플리케이션 구조	업무를 어떤 응용시스템이 지원할 것인가	정보전략, 구축 원칙, 신 프로세스 기술서	액티비티/어플리케이션 매트릭스, 상관도 분석	어플리케이션 구조도, 기술서, 분산방안
데이터 구조	업무와 의사결정에 필요한 데이터는 무엇이며 어디에 둘 것인가	정보 요구, 현행 데이터 구조, 신 프로세스	엔티티 도출, ERD, 주제 데이터베이스 분류	데이터 구조도, ERD, 엔티티 기술서
기술 구조	어플리케이션과 데이터를 어떤 기술 기반 위에서 운용할 것인가	기술전략, 앱 구조, 데이터 구조, 표준 원칙	TBB, 기술요소 평가, 표준화 항목 도출	TBB 다이어그램, 기술표준, 권고안
통합 구조	각 구조를 하나의 시스템 청사진으로 어떻게 묶을 것인가	앱 구조, 데이터 구조, TBB, 분산방안	H/W, S/W, N/W 구성도 통합 설계	통합 시스템 구성도, 물리 시스템 구조도

실무 포인트

4대 구조정의는 순차 작업이지만 검토는 반복적으로 수행해야 한다. 예를 들어 데이터 분산방안이 변경되면 어플리케이션 배치와 네트워크 요건이 달라지고, 이는 다시 기술 구조와 통합 구조에 영향을 준다.

Deep Dive

SOA, EAI, ESB와 통합 관점

SOA는 서비스를 이용해 비즈니스 애플리케이션을 구성하는 소프트웨어 개발 방식이며, ESB는 서로 다른 애플리케이션 사이의 실시간 데이터 교환을 지원하는 소프트웨어 아키텍처 패턴으로 설명된다.3 C003의 통합 구조정의는 이러한 서비스 지향 및 연계 패턴을 특정 제품이 아니라 통합 원칙과 구성도 수준에서 표현하는 작업이다.

개념	구조정의에서의 활용	주의점
SOA	업무 기능을 서비스 단위로 식별하고 재사용 가능한 인터페이스로 정리한다.	서비스 이름만 나열하지 말고 책임, 데이터, 호출 조건을 명시해야 한다.
EAI	기존 시스템 간 데이터 연계와 프로세스 통합 요구를 분석한다.	점대점 연계가 늘어나면 운영 복잡도가 커진다.
ESB	라우팅, 변환, 프로토콜 변환, 메시징 등 공통 연계 기능을 구조화한다.	중앙 집중형 버스가 병목이나 변경 지연의 원인이 될 수 있다.

CHAPTER 03

어플리케이션 구조정의

프로세스를 지원하는 후보 어플리케이션과 관계를 설계한다

Concept

3. 어플리케이션 구조정의

어플리케이션 구조정의의 목적은 새로운 비즈니스 프로세스를 적용한 영역별 후보 어플리케이션 구조를 정의하는 것이다. 원본 자료는 어플리케이션 구조를 프로세스 모델링 이후 정보처리를 지원하기 위해 재정립된 산출물로 설명하며, 주요 기능과 기능 간 연결관계, 주요 어플리케이션 시스템 명세를 포함한다고 제시한다.

Figure 4. 어플리케이션 구조정의 수행방법

개념 보강

어플리케이션 구조는 화면이나 프로그램 목록이 아니라 업무 능력을 시스템 경계로 묶은 구조다. 따라서 후보 어플리케이션은 조직도 기준이 아니라 프로세스, 데이터 응집도, 사용자 접점, 운영 책임을 함께 고려하여 정의해야 한다.

Practice

접근방법과 분석기법

실무 절차는 정보시스템 영역별 그룹핑, 신 어플리케이션 정의, 액티비티/어플리케이션 매트릭스 검증, 어플리케이션 상관관계 분석, 분산방안 수립으로 이어진다. 단위 프로세스가 단위 어플리케이션으로 구현되는 경우가 많지만, 모든 경우에 기계적으로 대응시키면 과도한 시스템 분할이 발생할 수 있다.

메가 프로세스, 메이저 프로세스, 단위 프로세스의 계층을 기준으로 정보시스템 영역을 묶는다.
각 단위 프로세스가 어떤 후보 어플리케이션으로 구현될지 정의한다.
액티비티/어플리케이션 매트릭스로 업무 액티비티 누락과 중복 지원 여부를 검증한다.
어플리케이션 간 상관도와 인터페이스 요건을 분석하여 통합 또는 분산 방안을 수립한다.

Figure 5. 정보시스템을 구성하는 하위 구조

분석 항목	검토 질문	결정 산출물
업무 적합성	새 프로세스의 모든 활동이 어플리케이션으로 지원되는가	액티비티/어플리케이션 매트릭스
연계성	어플리케이션 간 데이터 교환과 업무 흐름은 무엇인가	어플리케이션 상관도, 인터페이스 목록
분산성	조직, 지역, 사용자군에 따라 어플리케이션 배치가 달라지는가	어플리케이션 분산방안
운영성	성능, 가용성, 보안, DBMS, 네트워크 요건은 무엇인가	어플리케이션 기술서

Deep Dive

어플리케이션 기술서 작성

어플리케이션 기술서에는 성능, 응답시간, 가용시간, 분산처리 요건, 하드웨어 요건, 시스템 소프트웨어, DBMS, 네트워크, 보안, 사용자 전제조건, 환경 제약사항을 포함해야 한다. 이 항목은 이후 기술 구조정의의 입력으로 사용되므로 추상적인 표현보다 검증 가능한 요건으로 작성해야 한다.

Figure 6. 어플리케이션 아키텍처 예시

원본 사례: 인사지원 정보시스템

원본 자료의 인사지원 정보시스템 예시는 우수 인력 채용과 활용 강화, 인적 자원의 이직률 저감, 교육을 통한 능력 배양 지원을 정보시스템에 반영하는 사례다. 주요 구성은 사외 우수인력 유지, 인력 수급, 인력 운용, 교육·훈련, 근태·복무, 인사정보, 복리후생, 급여·정산 부문으로 제시된다. 선결 조건으로는 순환배치 운영지침, 평가 제도와 시행령, 부서별 필요인력 및 기술요건, 인력수급계획과 사업계획의 연결, 교육과정 운영 요건, 교육 이수 기준표, 인사정보 보안 수준 설정이 포함된다. 주요 정보기술로는 국내외 인력 Data Bank 연결, 관련 기관과의 FirmBanking 또는 EDI 기능, 교육 신청과 입과 통보 등 메시징 기능, 공공 네트워크를 활용한 지원자 직접 입력 기능이 제시된다.

Figure 7. 어플리케이션 통합구조도 예시

주의사항

어플리케이션 구조정의에서 가장 흔한 오류는 기능 목록을 시스템 목록으로 곧바로 바꾸는 것이다. 반드시 데이터 소유권, 인터페이스 빈도, 운영 책임, 사용자 접점을 함께 검토해야 한다.

CHAPTER 04

데이터 구조정의

정보 요구를 엔티티, 주제 데이터베이스, ERD로 구체화한다

Concept

4. 데이터 구조정의

데이터 구조정의는 필요 정보 요구와 현황 분석 자료를 기반으로 향후 정보시스템 환경을 지원하는 데이터의 논리적 구조를 정의하는 작업이다. 원본 자료는 이를 비즈니스 프로세스와 경영 의사결정에 필요한 데이터를 주제 데이터베이스별로 구분하고, 이후 시스템 기본설계 시 데이터 분산의 기본지침을 제공하는 산출물로 설명한다.

Figure 8. 데이터 구조정의 수행방법

개념 보강

데이터 구조정의의 핵심은 데이터베이스 제품 선정이 아니라 데이터의 의미, 소유자, 활용 관계, 보안 수준을 명확히 하는 것이다. 데이터는 여러 어플리케이션이 공유하므로 어플리케이션 경계와 동일하게 나누면 중복 저장과 불일치가 발생하기 쉽다.

Practice

엔티티, 주제 데이터베이스, ERD

주제 데이터베이스는 업무 기능 또는 비즈니스 프로세스의 사용 측면에서 유사성이 높은 엔티티들의 논리적 집합이다. 엔티티는 데이터베이스가 표현하려는 유형 또는 무형의 객체이며, ERD는 엔티티와 관계를 도식화하여 데이터 구조를 이해하게 해준다.

Figure 9. 데이터 구조정의 접근방법

현행 데이터 구조와 신 업무 프로세스에서 엔티티 후보를 도출한다.
엔티티 간 친밀성, 의존성, 관리 책임을 분석한다.
후보 주제 데이터베이스를 설정하고 데이터 오너십과 관리지침을 개발한다.
메이저 프로세스별 ERD를 작성하고 엔티티 기술서를 정의한다.

Figure 10. 데이터 아키텍처 정의 절차

Deep Dive

엔티티 기술서와 데이터 품질 요건

엔티티 기술서는 엔티티의 개요, 주요 속성, 분산 위치, 관련 어플리케이션, 소유자를 기록한다. 또한 성능, 가용성, 무결성, 정확성, 현재성, 접근 및 보안, 중복성, 데이터 연계성을 함께 기술해야 한다.

품질 항목	정의 시 질문	산출물 반영 위치
무결성	데이터 값과 관계가 업무 규칙을 위반하지 않는가	ERD, 엔티티 기술서
정확성	업무 현실과 데이터 값이 일치하는가	속성 정의, 검증 규칙
현재성	업데이트 주기와 사용 시점이 요구 수준을 만족하는가	데이터 관리지침
보안	누가 어떤 조건에서 조회, 변경, 삭제할 수 있는가	접근권한, 소유권, 감사 기준
분산	지역 또는 기관별 배치가 필요한가	데이터 분산방안

Figure 11. 엔티티 관계도 예시

Figure 12. 데이터 구조도 예시

엔티티 기술서 예시: 호적정보 테이블 내역

번호	테이블	테이블명	키	주요수록정보	지역분산
1	CISTNINFORM	11호서식	일련번호	행정동코드, 사건본인명 및 주민번호	시·군·구
2	CISTNRECEIVE	12호서식	일련번호	신고인, 신고인 주민번호, 세대주 성명 및 관계	시·군·구
3	CISTNCHGNAME	개명사건	접수번호	부모성명, 개명명, 허가일자, 법원코드	시·군·구
4	CISTNPENALTY	과태료	접수번호	납부자주소, 이의신청일자 및 사유	시·군·구
5	CISTCCRTPANELTY	과태료부과기준	등록일자	부과기준명, 해태기준	공통
6	CISTHCHIEF	관장자이력	등록일자	관장자ID	공통
7	CISTCBUPDMAPP	관할법정동대호적관서	관할법정동코드	호적관서코드, 말소일자	공통
8	CISTNMBR	구성원	호적ID	구성원의 신분관계사항	시·군·구
9	CISTNNNTLOSS	국적상실사건	접수번호	국적상실 일자 및 원인	시·군·구
10	CISTNNNTGET	국적취득사건	접수번호	국적취득 일자 및 원인	시·군·구
11	CISTNNNTRECOV	국적회복사건	접수번호	국적상실 일자 및 원인, 국적회복 허가 일자	시·군·구

CHAPTER 05

기술 구조정의

TBB를 통해 기술 기반구조를 표준화하고 대안을 평가한다

Concept

5. 기술 구조정의

기술 구조정의는 신 정보시스템에 적용할 기술 Building Block을 설정하고 이에 따른 기술구조를 정의하는 작업이다. 원본 자료는 이를 플랫폼 모델링의 산출물로 보며, 시스템 플랫폼, 소프트웨어, 개발환경, 데이터 관리, 정보통신 네트워크 기반 구조를 포함한다고 설명한다.

Figure 13. 기술 구조정의 수행방법

개념 보강

기술 구조는 서버, 네트워크, DBMS 목록을 구매 명세로 나열하는 것이 아니라 어플리케이션과 데이터가 요구하는 성능, 가용성, 보안, 확장성, 운영성을 기술 요소로 번역하는 과정이다.

Practice

TBB 기반 접근방법

기술 구조정의는 기술구조 전략과 기준을 정립하고, 어플리케이션 및 데이터 구조에서 요구되는 정보기술 요건을 파악한 후, TBB를 통해 기술요건을 통합한다. 이후 각 기술요소별 항목과 표준화 방향을 정하고, 표준 및 권고안을 도출한다.

Figure 14. 기술 구조정의 접근방법

TBB 영역	설명	대표 검토 항목	산출물 연결
환경 및 플랫폼	Enterprise, Corporate, Workgroup, Personal 수준의 하드웨어와 운영 기반	서버, 클라이언트, 운영체제, 가상화, 용량	플랫폼 표준, 시스템 구성도
네트워크	통신 프로토콜, 통신장비, 네트워크 관리, 네트워크 소프트웨어	대역폭, 지연, 보안 구간, 장애 대응	N/W 구성도, 통신 표준
어플리케이션 개발지원	개발 방법론, 개발도구, 프레임워크, 배포체계	언어, 개발도구, 테스트, 배포 자동화	개발 표준, 도구 권고안
시스템 관리 및 서비스	운영관리, 모니터링, 백업, 보안, 장애관리 서비스	로그, 모니터링, 권한, 백업, 복구	운영관리 표준, 서비스 구성도
사무자동화 지원	사용자 생산성 도구와 업무지원 환경	문서, 협업, 메시징, 사용자 인증	사용자 환경 표준
기술 규격 및 체계	표준화 방향, 기술선정 기준, 적용성 평가 기준	호환성, 확장성, 벤더 종속성, 보안성	기술표준, 권고안

Figure 15. TBB 구성 개념

Deep Dive

기술 구조 산출물의 평가 기준

기술 구조 대안은 기능 충족 여부만으로 평가하면 부족하다. 장기 운영 관점에서 확장성, 상호운용성, 보안성, 관리성, 표준 준수성, 변경 용이성까지 검토해야 한다. 원본 자료의 기술 아키텍처 예시는 표현 서비스, 응용 서비스, 데이터 서비스, 분산 시스템 서비스, 네트워크 서비스, 개발 및 지원 도구의 계층을 함께 제시한다.

Figure 16. 기술 구조 산출물 예시: 어플리케이션 영역

Figure 17. 기술 아키텍처 계층 예시

주의사항

기술 구조정의 단계에서 특정 제품명을 먼저 고정하면 아키텍처 대안 비교가 제한된다. 우선 필요한 기술능력과 표준을 정의한 뒤, 제품이나 서비스는 그 기준에 따라 평가해야 한다.

CHAPTER 06

통합 구조정의

어플리케이션, 데이터, 기술을 하나의 시스템 청사진으로 결합한다

Concept

6. 통합 구조정의

통합 구조정의는 데이터, 어플리케이션, 기술 관점에서 통합 시스템 구성도를 작성하는 과정이다. 원본 자료는 이를 정보시스템화 대상 업무 프로세스를 지원하는 어플리케이션, 데이터, 정보기술 구조를 통합하여 하나의 응용 시스템으로서 기능을 제공할 수 있는 모습을 제시하는 작업으로 설명한다.

개념 보강

통합 구조는 시스템 청사진이다. 이는 단위 시스템 분류 기준에 따라 앞서 설계된 구조를 융합하고, 전사 차원의 물리적 관점과 논리적 관점을 동시에 제시한다.

Figure 18. 통합 구조정의 접근방법

Practice

통합 구조 작성 절차

입력물은 정보전략, 신 엔티티 관계도, TBB 다이어그램, 기술표준, 데이터 분산방안, 데이터 관리방안이다. 수행절차는 어플리케이션 구조와 데이터 구조를 통합하여 물리 시스템 구조도, 즉 H/W와 N/W 구조도를 작성하고, 업무를 기준으로 정보시스템별 데이터, 어플리케이션, 기술을 통합한 관점에서 시스템 구성도를 작성하는 것이다.

어플리케이션 및 데이터 아키텍처를 검토하고 특성을 분석한다.
정보처리 요건과 상관도를 검토하여 단위 응용시스템을 정립한다.
후보 기본 모형별 응용 환경과 기술을 검토하고 기반 구조를 설계한다.
시스템 간 연계 전제조건, 위험요소, 영향도를 평가하고 대안을 설계한다.
H/W, 시스템 소프트웨어, N/W 구성도를 통합하여 최종 시스템 구성도를 확정한다.

Figure 19. 통합 구조 정의 절차

Deep Dive

통합 구조 검토 체크리스트

검토 관점	핵심 질문	위험 신호	보완 조치
업무 연속성	업무 흐름이 시스템 경계를 넘어 끊기지 않는가	수작업 재입력, 중복 승인	프로세스와 인터페이스 재정렬
데이터 일관성	동일 데이터의 원천과 복제 기준이 명확한가	여러 시스템의 값 불일치	마스터 데이터와 소유권 정의
기술 호환성	플랫폼, 네트워크, 보안 방식이 상호 운용되는가	프로토콜 불일치, 인증 단절	표준 인터페이스와 공통 인증 설계
운영 관리성	장애, 성능, 배포, 로그를 통합적으로 관리할 수 있는가	시스템별 별도 운영 도구	통합 모니터링과 운영 표준 정의

Figure 20. 통합 구조 예시

Figure 21. 통합 시스템 구성도 예시

Figure 22. 소프트웨어 구성도 예시

Figure 23. 네트워크 구성도 예시

CHAPTER 07

과제

XX일보 사례를 기준으로 TBB와 통합 시스템 구성도를 작성한다

Assignment

7. 과제 안내

원본 자료의 과제는 두 가지다. 첫째, 어플리케이션 구조정의와 데이터 구조정의 산출물 예를 분석하여 XX일보의 TBB를 조별로 제시한다. 둘째, 어플리케이션 구조정의, 데이터 구조정의, 기술 구조정의 산출물 예를 바탕으로 XX일보를 위한 통합 시스템 구성도를 조별로 제시한다.

과제 1 산출물

TBB 표는 기술요소를 나열하는 데서 끝나지 않아야 한다. 각 기술요소가 어떤 어플리케이션 요건과 데이터 요건을 지원하는지 연결 근거를 포함해야 한다.

과제	수행 내용	필수 산출물	평가 기준
과제 1	XX일보의 어플리케이션과 데이터 산출물 예를 분석하여 TBB를 제시한다.	TBB 설명표, 기술요소별 표준화 방향	요건 추적성, 기술요소 완전성, 표준화 논리
과제 2	어플리케이션, 데이터, 기술 구조정의 결과를 바탕으로 통합 시스템 구성도를 작성한다.	통합 시스템 구성도, H/W 구성도, N/W 구성도	구조 간 일관성, 연계 위험 반영, 운영 가능성

Practice

과제 수행 절차

XX일보의 핵심 업무 프로세스와 후보 어플리케이션을 먼저 정리한다.
각 어플리케이션이 생성, 조회, 변경, 삭제하는 핵심 엔티티를 연결한다.
성능, 보안, 가용성, 분산처리, 네트워크 요구를 TBB 항목으로 변환한다.
TBB와 데이터 분산방안을 바탕으로 물리 시스템 배치 대안을 작성한다.
통합 시스템 구성도에서 시스템 간 인터페이스, 데이터 흐름, 운영관리 지점을 표시한다.

제출 전 점검

통합 구성도에 서버와 네트워크만 있고 업무 어플리케이션과 데이터가 빠져 있으면 과제 취지에 맞지 않는다. 반대로 업무 기능만 있고 기술 배치가 없으면 통합 구조정의 산출물로 부족하다.

핵심 요약

정보시스템 구조정의는 전략을 구현 가능한 아키텍처 청사진으로 전환하는 과정이다.
어플리케이션, 데이터, 기술 구조는 각각 독립 산출물이지만 최종 통합 구조에서 일관성을 검증해야 한다.
TBB는 기술 구매 목록이 아니라 업무와 데이터 요건을 지원하는 기술능력의 논리적 구성이다.
통합 시스템 구성도는 업무, 데이터, 기술, 운영 관점을 모두 포함해야 한다.

CHAPTER 08

참고문헌

원본 강의자료와 이론 보강 출처

8. 참고문헌

The Open Group, “TOGAF,” https://www.opengroup.org/togaf
Zachman FEAC Institute, “About the Zachman Framework,” https://zachman-feac.com/zachman/about-the-zachman-framework
Amazon Web Services, “What is ESB?,” https://aws.amazon.com/what-is/enterprise-service-bus/
원본 강의자료: C003_정보시스템구조정의_v2.0819(46).ppt, 사용자 제공 파싱 텍스트 및 슬라이드 이미지.

본 HTML 문서는 원본 슬라이드의 구조와 핵심 내용을 보존하되, 단행본형 학습 자료로 활용할 수 있도록 개념 설명, 실무 절차, 비교표, 주의사항, 참고 이론을 보강하였다.

신 비즈니스 프로세스 정의

지능한글 — Sat, 4 Jul 2026 21:01:07 +0900

신 비즈니스 프로세스 정의 단행본

신 비즈니스 프로세스 정의

현행 프로세스 개선방향을 To-Be 프로세스 체계와 주요 프로세스 맵으로 구체화하는 실무 교재

원천 자료: C002_신비즈니스프로세스정의_v2.1200(52).ppt · 변환 형식: 단행본 스타일 HTML

개요 — 신 비즈니스 프로세스 정의 Activity 공정도 및 목적

이 장은 원본 슬라이드 3~9페이지의 개요 내용을 바탕으로, 신 비즈니스 프로세스 정의 활동의 위치와 입출력, 목적, 배경, 접근방법을 단행본 형식으로 재구성한다.

Concept

1.1 Activity의 역할과 목적

신 비즈니스 프로세스 정의 활동은 현행 비즈니스 프로세스 체계와 흐름도를 출발점으로 삼아, 차이분석에서 도출된 프로세스 개선방향을 반영한 새로운 프로세스 체계와 흐름도를 작성하는 단계이다. 이 결과는 정보화 전략 수립 시 고려해야 할 프로세스 구현 요건으로 연결된다.

Figure 1: INNOVATOR 내 신 비즈니스 프로세스 정의 Activity의 역할

정의

여기서 신 프로세스란 단순히 현재 업무를 전산화한 절차가 아니라, 경영전략, CSF, 개선과제, 정보시스템 구현 가능성을 함께 반영하여 재설계한 To-Be 업무 수행 방식이다.

Figure 2: 신 비즈니스 프로세스 정의 Activity의 입출력 관계

Practice

1.2 To-Be 프로세스 도출의 실무 흐름

To-Be 프로세스의 목적과 목표는 기업의 경영전략, 핵심성공요소, 현행 프로세스 개선방향을 고려하여 명확히 설정한다. 이후 경쟁우위를 달성할 수 있는 미래 업무 흐름을 정의하고, 프로세스 체계, 프로세스 맵, 구현요건으로 단계적으로 구체화한다.

경영전략과 CSF를 확인하고 프로세스가 달성해야 할 목적을 정의한다.
차이분석 결과를 검토하여 개선 대상 프로세스와 신규 프로세스를 식별한다.
전략 지원도, 개선 요구도, 데이터 연관도 등을 기준으로 상세 설계 우선순위를 정한다.
프로세스 체계도, 정의서, 흐름도, 구현요건을 산출물로 작성한다.

Figure 3: To-Be 프로세스 목적과 목표 정립

실무 포인트

프로세스 개선방향이 모호하면 이후 정보화 전략도 기능 목록 중심으로 흐르기 쉽다. 따라서 To-Be 설계의 첫 문장은 “어떤 고객 가치와 경영성과를 만들 것인가”로 시작해야 한다.

Deep Dive

1.3 효과성과 효율성 관점의 균형

신 프로세스 정의는 운영 효율성 개선만으로 충분하지 않다. 원본 자료는 운영 효율성만을 추구하는 것으로는 지속적 경쟁우위를 확보하기 어렵다고 설명한다. 따라서 프로세스 설계는 비용, 시간, 오류 감소와 같은 효율성뿐 아니라 고객가치, 차별화, 전략 실행력과 같은 효과성을 함께 다루어야 한다.

Figure 4: 전략 개념과 효과성·효율성 관점

구분	효과성 관점	효율성 관점	설계 질문
목표	고객 가치와 전략 목표 달성	시간, 비용, 오류, 중복 감소	이 프로세스가 왜 필요한가
초점	성과, 서비스 수준, 경쟁우위	자원 사용, 처리 속도, 자동화	같은 결과를 더 적은 자원으로 만들 수 있는가
위험	목표는 크지만 실행 구조가 느슨할 수 있음	빠르지만 전략적으로 중요하지 않은 일을 최적화할 수 있음	불필요한 일을 빠르게 하는 것은 아닌가
산출물 반영	KPI, 고객 접점, 핵심성과요인	리드타임, 투입공수, 자동화 대상	성과지표와 업무흐름이 연결되는가

주의

To-Be라는 이름으로 현재 업무를 조금 빠르게 만드는 데 그치면 프로세스 혁신이 아니라 부분 개선에 머문다. 반대로 전략적 구호만 있고 책임부서, 입출력, 종료요건이 없으면 실행 가능한 프로세스가 되지 않는다.

Figure 5: Value Chain 관점의 프로세스 목적과 개선방향 설정

Figure 6: 신 프로세스 체계 기반의 단계적 상세 설계 접근

CHAPTER 2

신 프로세스 설계 이론적 기초 — BPR·프로세스 혁신 프레임워크

이 장은 원본 슬라이드의 프로세스 혁신 사상을 Hammer & Champy의 BPR, Davenport의 프로세스 혁신, BPMN, EPC, Value Stream Mapping 관점으로 확장한다.

Concept

2.1 BPR과 프로세스 혁신의 관점

Hammer & Champy의 BPR 이론은 업무를 기능 부서 단위가 아니라 고객에게 가치를 전달하는 종단 간 프로세스로 재사고해야 한다는 관점을 제시한다. Davenport의 프로세스 혁신은 정보기술이 단순 자동화 수단을 넘어 업무 방식 자체를 재구성하는 촉매가 될 수 있음을 강조한다. 원본 자료의 고객지향, 원점지향, 프로세스 중시, Top Down, 변화관리 중시 사상은 이러한 BPR·프로세스 혁신 관점과 맞닿아 있다.

이론 연결

고객지향은 프로세스의 목적을 내부 편의가 아니라 고객 가치로 재정렬하는 원칙이다. 원점지향은 기존 규정과 관행을 그대로 전제하지 않고 프로세스의 존재 이유에서 다시 설계한다는 의미이다.

Practice

2.2 To-Be 프로세스 설계 원칙 비교표

설계 원칙	효과성 중심 해석	효율성 중심 해석	실무 적용 예
고객지향	고객 접점과 내부 고객의 기대성과를 기준으로 업무를 재배열한다.	고객이 기다리는 지연 단계와 재작업을 제거한다.	민원 처리에서 접수, 검토, 통보를 고객 여정 기준으로 재구성한다.
원점지향	프로세스의 존재 이유와 목표성과를 먼저 정의한다.	관행적으로 남은 승인, 전표, 보고 단계를 폐지한다.	“왜 이 확인이 필요한가”를 기준으로 통제와 책임을 재설계한다.
프로세스 중시	부서별 최적화보다 종단 간 성과를 우선한다.	부서 간 전달, 대기, 중복 입력을 줄인다.	영업, 생산, 물류, 회계가 공유하는 주문 처리 흐름을 하나의 맵으로 설계한다.
정보기술 활용	새로운 서비스 방식과 의사결정 품질을 가능하게 한다.	자동화, 데이터 공유, 통합DB로 처리시간을 줄인다.	전자결재, 그룹웨어, 통합정보시스템을 프로세스 흐름에 내장한다.
변화관리	조직문화, 역할, 평가체계가 새 프로세스를 지지하도록 한다.	저항과 혼선을 줄여 전환 비용을 낮춘다.	권한 이양, 직무 조정, 교육, 규정 개정을 병행한다.

핵심 판단

효과성 질문은 “올바른 일을 하고 있는가”이고, 효율성 질문은 “그 일을 낭비 없이 하고 있는가”이다. To-Be 프로세스는 두 질문에 동시에 답해야 한다.

Deep Dive

2.3 프로세스 표기법 비교

신 프로세스를 문서화할 때는 독자가 누구인지, 표준 준수가 필요한지, 시스템 분석으로 이어지는지에 따라 표기법을 선택해야 한다. BPMN은 OMG 표준 기반의 업무 프로세스 모델링 표기법이며, EPC는 이벤트와 기능의 연결을 통해 업무 흐름을 설명하는 방식이고, 플로우차트는 가장 널리 이해되는 범용 흐름 표현이다. Lean의 Value Stream Mapping은 프로세스 단계뿐 아니라 대기, 재고, 리드타임 등 낭비 관점의 분석에 강점이 있다.

표기법	주요 용도	강점	한계	적합한 산출물
BPMN	업무 프로세스와 시스템 연계 모델링	표준화된 이벤트, 게이트웨이, 역할 표현	초심자에게 기호 체계가 복잡할 수 있음	상세 프로세스 맵, 자동화 후보 분석
EPC	이벤트와 기능 중심 업무 흐름 설명	업무 상태 변화와 기능의 선후관계를 표현하기 쉬움	조직 간 협업과 메시지 표현은 제한적일 수 있음	업무 시나리오, ERP 연계 프로세스
플로우차트	범용 절차와 의사결정 흐름 표현	비전문가도 이해하기 쉽고 교육용으로 적합	대규모 복합 프로세스에서는 표준성과 정밀성이 낮음	워크숍 초안, 교육자료, 간단한 절차서
Value Stream Mapping	가치흐름과 낭비 분석	리드타임, 대기, 재작업 등 개선 포인트를 드러냄	정보시스템 상세 요건 표현에는 별도 보완이 필요	Lean 개선 과제, 낭비 제거 분석

주의

표기법을 먼저 정하고 내용을 끼워 맞추면 산출물이 형식 중심으로 변한다. 먼저 의사결정 목적과 독자를 정한 뒤, 필요한 수준의 표기법을 선택해야 한다.

CHAPTER 3

Task 1. 프로세스 체계 정립

프로세스 체계 정립은 신 프로세스의 구성 단위를 식별하고, 개선방향과 전략 지원 관점을 반영하여 전체 구조를 재정의하는 작업이다.

Concept

3.1 개념: 무엇을 정립하는가

원본 자료에서 Task 1의 목적은 신 프로세스 체계를 정립하는 것이다. 입력물은 프로세스 개선방향이며, 산출물은 신 프로세스 기술서이다. 수행절차는 미래 To-Be 프로세스 구성도 정의, 핵심 개선 대상 프로세스 파악, 과제별 대안 작성과 타당성 평가, 신 프로세스 기술서 작성으로 구성된다.

Figure 7: 신규 프로세스 파악과 신 프로세스 정의 접근방법

체계 정립의 의미

프로세스 체계도는 단순 업무 목록이 아니라 메가 프로세스, 메이저 프로세스, 세부 프로세스의 계층과 상호관계를 보여주는 구조도이다. 이 구조가 안정되어야 이후 프로세스 맵과 구현요건이 일관성을 갖는다.

Practice

3.2 실습: CSF에서 핵심 개선대상 프로세스까지

경영전략 분석에서 도출된 핵심성공요소를 기준으로 필요한 업무 기능을 신규 정의하고, 해당 기능의 수행 절차를 프로세스 관점으로 정리한다. 모든 현행 프로세스를 동일한 깊이로 분석할 필요는 없으며, 전략 지원도, 개선 요구도, 데이터 연관도 등을 기준으로 우선 분석 대상을 선정한다.

Figure 8: CSF와 핵심 개선대상 프로세스 선정

CSF별로 필요한 업무 기능을 나열한다.
각 기능이 현재 어떤 프로세스에서 수행되는지 매핑한다.
개선 요구도와 전략 지원도를 기준으로 핵심 개선대상 프로세스를 선별한다.
우수사례와 정보기술 적용 가능성을 참조해 신규 프로세스 후보를 정의한다.

평가 기준	질문	판정 예
전략 지원도	이 프로세스가 CSF를 직접 지원하는가	3개 이상 CSF 지원 시 우선순위 높음
개선 요구도	고객 불만, 지연, 오류, 비용 문제가 큰가	반복 민원이나 리드타임 병목이 있으면 높음
데이터 연관도	핵심 데이터 생성·변경·활용과 관련되는가	마스터 데이터와 거래 데이터에 영향을 주면 높음
구현 가능성	조직·제도·시스템 전환이 가능한가	권한 이양과 시스템 구축 여건을 함께 검토

Deep Dive

3.3 심화: 프로세스 개선 유형과 정보기술의 역할

원본 자료는 비동기화, 제거, 단일화, 선택, 연결, 추가와 같은 개선 유형을 제시한다. 이는 업무흐름 관점에서 대기와 중복을 줄이고, 고객지향적 서비스를 제공하기 위한 개선 레버로 이해할 수 있다.

Figure 9: 프로세스 개선 유형과 업무흐름 개선 가능성

개선 유형	핵심 의미	적용 상황	예상 효과
비동기화	순차 처리로 인한 대기 제거	결재 대기, 자료 취합 대기	리드타임 단축
제거	불필요한 중간과정 폐지	중복 확인, 반복 보고	비용과 오류 감소
단일화	복수 업무를 하나의 공통 처리로 통합	부서별 개별 수행 공통업무	표준화와 규모의 효율
선택	중복 관리되는 유사 업무 중 하나만 유지	내부 관리용 중복 장부	관리 부담 축소
연결	업무 간 연계 미흡을 보완	전 단계 결과가 다음 단계에 수작업 전달	흐름 안정성과 추적성 향상
추가	수요자 근접지에서 서비스 제공	단일 창구 서비스 병목	접근성과 서비스 수준 향상

Figure 10: 새로운 정보기술과 프로세스 개선의 관계

Figure 11: 정보시스템 활용에 기반한 업무 개선

실무 사례 해석

급여관리 프로세스 예시처럼 개선효과는 처리시간, 투입공수, 대기시간, 재작업 건수 등으로 정량화할 수 있다. 단, 정량효과는 산정 근거가 되는 세부 업무 분석서와 기술서가 함께 관리되어야 한다.

Figure 12: 급여관리 프로세스 개선 내역과 기대효과 예시

Figure 13: 현행 프로세스와 미래 프로세스의 관계도와 체계도

Task 1 핵심 요약

프로세스 체계 정립은 전략, 개선방향, 정보기술 가능성을 하나의 구조로 통합하는 단계이다.
CSF와 개선 요구도를 기준으로 핵심 개선대상 프로세스를 선별한다.
개선 유형은 산출물이 아니라 설계 사고의 도구이며, 최종적으로 신 프로세스 정의서와 체계도로 구체화되어야 한다.

Output

3.4 산출물 예시: 프로세스 개선 목표와 신 프로세스 정의

원본 자료는 프로세스 개선 목표를 조직구조 개선과 정보화를 통한 공통적 개선이라는 두 방향으로 설명한다. 또한 신 프로세스 정의에서는 기존 업무 기능을 통폐합하고 정보시스템 사용에 따른 업무 수행 방식 변화를 반영한다.

Figure 14: 프로세스 개선 목표와 주요 변화 요인

Figure 15: 호적업무 프로세스 개선 목표 예시

Figure 16: 호적업무 전체 프로세스 분할도 예시

검토 체크

신 프로세스 정의서에는 프로세스명, 목적 및 개요, 개시요건, 주요 업무 흐름, 종료요건, 관련부서, 개선사항이 포함되어야 한다. 어느 하나가 빠지면 이후 구현요건 도출에서 누락이 발생한다.

CHAPTER 4

Task 2. 주요 프로세스 도출

주요 프로세스 도출은 우선순위가 높은 신 프로세스를 대상으로 상세 흐름도와 엑티비티 내역을 작성하고, 정보화·프로세스·조직 측면의 구현요건을 도출하는 단계이다.

Concept

4.1 개념: 프로세스 맵과 구현요건의 연결

Task 2의 목적은 주요 신 프로세스의 엑티비티를 이용하여 프로세스 맵을 작성하고 구현에 필요한 요건을 도출하는 것이다. 입력물은 신 프로세스 기술서와 현행 프로세스 맵이며, 산출물은 신 프로세스 맵과 구현요건이다.

Figure 17: 주요 프로세스 도출 과정의 내역

프로세스 맵의 역할

프로세스 맵은 업무 흐름을 시각화하는 그림 이상의 의미를 가진다. 담당부서, 입력정보, 출력정보, 의사결정, 시스템 지원 지점을 함께 드러내어 정보전략과 시스템 구조 정의의 근거가 된다.

Practice

4.2 실습: 신 프로세스 흐름도 작성

신 프로세스 흐름도는 현행 프로세스 흐름도를 최대한 활용하되, 통합, 삭제, 조정이 필요한 부분을 반영하여 수정한다. 신규 프로세스는 목표, 담당부서, 입출력 정보, 종료요건을 명확히 한 뒤 흐름도로 작성한다.

현행 프로세스 맵과 엑티비티 기술서를 검토한다.
통합, 삭제, 조정, 신규 추가 대상을 표시한다.
업무 흐름 란에 엑티비티와 담당부서를 흐름 순서대로 배치한다.
각 엑티비티의 입력, 출력, 시스템 지원, 책임부서를 기록한다.
조직, 업무, 정보시스템, 법·제도 구현요건을 분류하여 정리한다.

작성 항목	작성 내용	품질 기준
엑티비티	프로세스를 구성하는 세부 단위 활동	동사형으로 명확히 표현
담당부서	수행 책임 조직 또는 역할	책임과 협조를 구분
입출력 정보	업무 수행에 필요한 입력과 결과물	시스템 데이터와 문서 정보를 구분
통제·의사결정	승인, 검토, 분기 조건	결정 기준과 예외처리 포함
시스템 지원	자동화, 조회, 입력, 연계 기능	정보화 전략과 연결 가능해야 함

실습 팁

흐름도는 처음부터 완성하려 하지 말고, 워크숍에서 플로우차트 수준으로 합의한 뒤 BPMN 또는 조직별 스윔레인 형태로 정교화하는 방식이 효과적이다.

Deep Dive

4.3 심화: 구현요건과 평가요소 도출

원본 자료는 신 프로세스 구현요건과 평가요소를 정보화, 프로세스, 조직 측면에서 도출한다고 설명한다. 여기에 법·제도 요건까지 포함하면 실행 가능한 To-Be 설계가 된다. 구현요건은 문제점, 현안, 개선방향, 개선과제를 참조하여 도출해야 하며, 프로세스 맵의 각 엑티비티와 연결되어야 한다.

Figure 18: 신 프로세스 구현 요건과 평가요소 도출

요건 분류	주요 질문	산출 예
조직·업무	새 프로세스를 수행할 책임과 역할이 명확한가	권한 이양, 직무 조정, 업무분장 개정
정보시스템	입출력 정보와 자동화 기능이 정의되었는가	통합DB, 전자결재, 인터페이스, 조회 기능
프로세스	흐름, 기준, 예외처리가 명확한가	표준 절차서, KPI, SLA, 통제 기준
법·제도	규정 변경이나 제도 개선이 필요한가	관련 규정 개정, 위임전결 기준 변경

Figure 19: 신 프로세스 맵 산출물 예시

Figure 20: 재설계가 필요한 전체 신 호적업무 프로세스

Figure 21: 전체 신 호적업무 프로세스 흐름도

Figure 22: 신 업무프로세스 맵 예시

주의

구현요건이 “시스템 구축 필요”처럼 포괄적으로만 작성되면 설계 산출물로서 가치가 낮다. 어떤 엑티비티에서 어떤 정보가 생성되고, 누가 사용하며, 어떤 규정 변경이 필요한지까지 추적 가능해야 한다.

Task 2 핵심 요약

신 프로세스 맵은 상세 흐름과 구현요건을 연결하는 중간 산출물이다.
엑티비티 기술서는 입력, 출력, 담당, 시스템 지원, 예외처리를 포함해야 한다.
구현요건은 조직·업무, 정보시스템, 프로세스, 법·제도 관점으로 분류해 실행계획의 근거로 활용한다.

CHAPTER 5

과제 및 평가

원본 슬라이드 44~52페이지는 신 비즈니스 프로세스 정의 실습 과제의 범위, 산출물, 진행방식, 평가 기준을 제시한다.

Assignment

5.1 과제 개요

과제의 범위는 회사 전체 프로세스 중 하나의 프로세스를 선정하여 To-Be 프로세스를 정의하는 것이다. Value Chain 영역 규모의 메가 프로세스를 채택하고, 현행 업무 영역 분석과 CSF를 기준으로 미래 프로세스 체계도를 작성한다.

Figure 23: 신 비즈니스 프로세스 정의 과제 범위

과제 산출물

미래 프로세스 체계도, 경영전략·CSF 정리, 프로세스·CSF 매트릭스, 미래 프로세스 정의서, 신 프로세스 맵, 개선 전후 프로세스 차이점이 핵심 산출물이다.

Figure 24: 미래 프로세스 체계도 작성 예시

Evaluation

5.2 평가 기준과 제출물 품질

평가 영역	확인 질문	우수 산출물 기준
전략 연계성	경영전략과 CSF가 프로세스 선정에 반영되었는가	프로세스·CSF 매트릭스가 논리적으로 연결됨
체계성	메가, 메이저, 세부 프로세스 계층이 명확한가	중복과 누락 없이 계층 구조가 표현됨
실행 가능성	담당부서, 입출력, 종료요건이 정의되었는가	정의서만 보아도 운영 방식이 이해됨
개선 효과	개선 전후 차이가 구체적으로 드러나는가	시간, 비용, 품질, 서비스 수준 변화가 설명됨
구현요건	정보화, 조직, 제도 요건이 구분되었는가	후속 정보화 전략 수립에 바로 활용 가능함

제출 전 점검

산출물은 “그럴듯한 그림”보다 추적성이 중요하다. CSF가 왜 해당 프로세스를 요구하는지, 해당 프로세스가 어떤 엑티비티와 구현요건으로 이어지는지 한 줄로 설명할 수 있어야 한다.

Checklist

5.3 실무 체크리스트

프로세스의 정의와 범위, 목적이 명확히 정의되어 있는가
전체 프로세스 구조의 흐름과 계층적 표현이 명확한가
프로세스의 입력, 출력, 시스템 지원사항이 표현되어 있는가
정보시스템과 연계된 프로세스 흐름이 나타나 있는가
정보화 전략 및 시스템 구조 정의를 위해 프로세스를 기능적 차원에서 정리했는가
개선 전후 차이와 구현요건이 후속 실행계획으로 연결되는가

흔한 감점 요인

프로세스 체계도와 프로세스 맵의 명칭이 서로 다르거나, CSF와 프로세스 선정 이유가 분리되어 있거나, 구현요건이 시스템 기능 목록으로만 작성되는 경우 산출물의 일관성이 떨어진다.

CHAPTER 6

참고문헌

본 장은 원본 강의자료의 내용을 보강하기 위해 문서 내에서 언급한 이론과 표준의 출처를 정리한다.

Hammer, M. & Champy, J. Reengineering the Corporation: A Manifesto for Business Revolution. HarperBusiness.
Davenport, T. H. Process Innovation: Reengineering Work through Information Technology. Harvard Business School Press.
Object Management Group. Business Process Model and Notation (BPMN) Specification.
Scheer, A.-W. ARIS — Business Process Frameworks 및 EPC(Event-driven Process Chain) 관련 문헌.
Lean Enterprise Institute 및 Toyota Production System 기반 Value Stream Mapping 실무 문헌.
원천 강의자료: C002_신비즈니스프로세스정의_v2.1200(52).ppt.

요구사항 정의 및 개선과제 도출

지능한글 — Sat, 4 Jul 2026 20:58:39 +0900

A2.3 요구사항 정의 및 개선과제 도출

Consulting Methodology Book

A2.3 요구사항 정의 및 개선과제 도출

프로세스 요구사항, 정보화 요건, 정보시스템 개선과제를 연결하는 실무형 단행본

본 문서는 원본 슬라이드 50페이지의 구조를 바탕으로 요구사항 정의와 개선과제 도출 활동을 단행본 형식으로 재구성한 것이다. 단순한 슬라이드 요약이 아니라, 표준 요구사항 명세 관점, 우선순위화 기법, 실무 산출물 작성 방법을 함께 설명하여 컨설팅 현장에서 바로 활용할 수 있도록 구성하였다.

원본: B004_요구사항정의및개선과제도출_v2.1200(50).ppt · 작성일: 2026-06-29

1. 요구사항 정의 및 개선과제 도출의 위치

요구사항 정의 및 개선과제 도출 활동은 비즈니스 프로세스 요구사항과 정보시스템 요구사항을 함께 정의한 뒤, 요구수준, 실현가능성, 업무 중요도 등을 고려하여 핵심 개선과제와 개선방향을 제시하는 단계이다. 원본 슬라이드는 이를 공정도와 목적 중심으로 제시하며, 본 장에서는 그 의미를 컨설팅 수행 관점에서 확장한다.

Figure 1: 요구사항 정의 및 개선과제 도출 Activity 공정도

Figure 2: 비즈니스 프로세스 요구사항과 정보시스템 요구사항을 통합하는 활동 목적

개념

요구사항은 단순한 희망사항 목록이 아니다. 현행 문제, 이해관계자 기대, 전략 목표, 정보시스템 제약을 연결하여 실행 가능한 변화 단위로 정의한 것이다. 따라서 요구사항 정의는 분석 활동의 끝이 아니라 개선과제 설계의 출발점이다.

실습 포인트

공정도는 입력물, 수행절차, 산출물, 기법을 함께 보아야 한다. 입력물이 부실하면 요구사항은 의견 수준에 머물고, 평가 기준이 없으면 개선과제는 우선순위 없는 과제 목록이 된다.

CHAPTER 02

요구사항 정의 이론적 기초

요건 정의의 의의와 핵심 프레임워크

2. 요구사항의 의미와 품질 기준

IEEE 830 요구사항 명세 표준은 좋은 요구사항 명세가 명확성, 완전성, 일관성, 검증가능성, 수정가능성, 추적가능성을 갖추어야 한다고 설명한다. 컨설팅 현장에서는 이 원칙을 그대로 문서 표준으로 적용하기보다, 업무 현안과 개선과제를 연결하는 품질 기준으로 해석하는 것이 유용하다.

Volere 요구사항 템플릿은 요구사항을 목적, 이해관계자, 제약, 기능 요구, 비기능 요구, 데이터 요구, 운영 요구 등으로 나누어 기록하도록 안내한다. 이는 본 활동의 프로세스 요구사항 정의, 정보화 요건정의, 정보시스템 개선과제 도출 구조와 잘 맞는다.

요구사항 유형	정의	대표 질문	주요 산출물
기능 요구사항	시스템이나 업무가 수행해야 할 기능과 서비스	무엇을 처리해야 하는가	기능 목록, 업무 시나리오, 유스케이스
비기능 요구사항	성능, 보안, 가용성, 사용성 등 품질 속성	어떤 수준으로 수행되어야 하는가	품질 기준, 서비스 수준, 보안 요건
프로세스 요구사항	업무 흐름, 역할, 제도, 절차의 변화 요구	어떤 업무 방식이 바뀌어야 하는가	프로세스 개선항목, 업무 규정 개선안
정보화 요건	정보시스템, 데이터, 기술구조, 운영관리 관점의 개선 요구	어떤 정보기술 지원이 필요한가	정보화 요건, 시스템 현안, 기술 개선항목

주의

요구사항 유형을 구분하지 않으면 모든 문제가 시스템 기능 개발 요구로 환원된다. 업무 규정의 문제, 조직 역할의 문제, 데이터 품질 문제, 사용자 역량 문제는 각각 다른 해결책을 필요로 한다.

우선순위 도출 기법 비교

원본 슬라이드는 중요도, 시급성, 효과성을 기준으로 개선항목의 우선순위를 평가하고, 델파이 기법을 통해 1차와 2차 의견조사를 반복하는 방식을 제시한다. 실무에서는 델파이 외에도 MoSCoW, AHP, Kano 모델을 함께 검토하면 의사결정의 설득력이 높아진다.

기법	핵심 원리	적합한 상황	주의점
MoSCoW	Must, Should, Could, Won't로 요구사항을 분류	짧은 기간에 릴리스 범위를 정해야 할 때	이해관계자가 모든 항목을 Must로 주장할 수 있음
AHP	기준과 대안을 쌍대비교하여 가중치를 산출	평가 기준이 많고 합리적 근거가 필요한 때	비교 항목이 많으면 응답 부담이 커짐
Kano 모델	기본, 성과, 매력 품질로 고객 만족 효과를 구분	고객경험과 서비스 차별화 요구를 평가할 때	내부 운영 개선과제에는 해석이 제한될 수 있음
델파이 기법	전문가 의견을 반복 수렴하여 합의를 형성	불확실성이 크고 현장 전문가 판단이 중요한 때	패널 구성과 질문 설계가 결과 품질을 좌우함

심화

우선순위는 점수의 높고 낮음만으로 결정하지 않는다. 전략 기여도, 업무 영향도, 고객 영향, 구현 용이성, 변화 수용성, 규제 리스크를 함께 보아야 실제 실행 가능한 과제 포트폴리오가 된다.

CHAPTER 03

Task 1. 프로세스 요구사항 정의

업무 흐름, 제도, 조직, 절차의 개선 요구를 도출하는 방법

Source pages 5-25

3.1 개념: 프로세스 요구사항의 범위

프로세스 요구사항 정의의 목적은 비즈니스 프로세스 요구사항과 정보시스템 요구사항을 정의하는 것이다. 입력물은 비전 및 전략 분석서, 현행 조직 및 업무체계이며, 수행절차는 핵심 경쟁요소를 바탕으로 현행 업무 프로세스별 개선 및 혁신요소를 도출하고, 현업 계층별 설문과 인터뷰 결과를 분석하여 비즈니스 측면의 요구사항을 정의하는 순서로 진행된다.

Figure 3: 업무 흐름, 정보시스템, 조직 변화 관점의 프로세스 요구사항 접근방법

개념

원본 자료는 변화 영역을 업무 흐름의 변화, 정보시스템의 변화, 조직의 변화로 구분한다. 업무 흐름의 변화는 업무 단순화와 통합화를 통한 절차 슬림화, 정보시스템의 변화는 신규 기술 도입과 기능 강화, 조직의 변화는 조직 신설과 통합, 제도 신설, 업무분장 조정을 포함한다.

3.2 실습: 프로세스 요구사항 도출 절차

프로세스 요구사항 정의는 설문과 면담을 통해 도출한 문제점, 업무현황분석에서 도출한 문제점을 프로세스 관점에서 재정의하고, 요구사항을 정리한 뒤 개선항목을 도출하는 방식으로 수행된다. 필요한 경우 선정된 개선과제를 유형별로 그룹화하고, 정보시스템 부문과의 중복과제를 배제한다.

Figure 4: 비즈니스 전략지원도, 개선요구도, 데이터 연관도를 바탕으로 한 접근

Figure 5: 정보시스템 개선 요구를 바탕으로 한 접근

현행 프로세스별 문제점과 요구사항을 수집한다.
문제점을 업무 흐름, 규정 및 제도, 조직 및 역할, 정보시스템 지원 관점으로 재분류한다.
중요도, 시급성, 효과성 등 기준을 적용해 개선항목을 평가한다.
유사 항목을 통합하고 정보시스템 개선과제와 중복되는 항목을 조정한다.
개선과제와 CSF 및 업무 프로세스 간 연관성을 분석한다.

Figure 6: 주요현안 정의 및 프로세스 개선과제 선정 절차

3.3 심화: 산출물 작성과 사례 해석

원본 자료의 사례는 호적업무를 대상으로 주요현안, 문제점, 개선요구사항, 개선항목을 정리한다. 예를 들어 접수 및 심사관리 영역에서는 법규 확인에 시간이 소요되고, 신고장소 제한과 정보 입력창 과다로 업무 효율성이 저하되는 문제를 제시한다. 이에 대한 개선요구는 정보공유, 교육체계, 중복입력 방지 등으로 전환된다.

산출물 영역	작성 내용	실무 검토 질문
주요현안 정의	현황, 문제점, 개선요구사항, 개선항목을 프로세스 단위로 정리	문제와 요구가 같은 수준으로 기술되었는가
우선순위 도출	중요도, 시급성, 효과성 점수와 종합점수를 비교	평가자 집단별 인식 차이를 설명할 수 있는가
개선과제 선정	유사 항목 통합, 중복 배제, 하위순위 제외 후 과제 확정	제외된 항목의 사유가 기록되었는가
연관성 분석	개선과제와 CSF, 프로세스 간의 관계를 매트릭스로 정리	전략 목표와 직접 연결되지 않는 과제는 없는가

주의

개선항목과 개선과제를 혼동하지 않아야 한다. 개선항목은 현안 해결을 위한 후보 단위이고, 개선과제는 평가와 통합을 거쳐 실행 책임과 범위가 부여된 단위이다.

Task 1 핵심 요약

프로세스 요구사항은 업무 흐름, 제도, 조직, 정보시스템 변화를 함께 다룬다.
설문과 인터뷰 결과는 평가 기준을 적용하여 개선항목으로 구조화해야 한다.
CSF와 프로세스 연관성 분석은 과제의 전략적 정당성을 검증하는 장치이다.

CHAPTER 04

Task 2. 정보화 요건정의

정보 요소별 요건과 시스템 현안을 정리하는 방법

Source pages 26-32

4.1 개념: 정보화 요건의 범위

정보화 요건정의의 목적은 정보 요소별 정보화 요건을 정의하는 것이다. 입력물은 현행 기술구조 분석서, 현행 정보관리 체계, 사용자 및 정보서비스 수준이며, 수행절차는 정보시스템 현황분석과 사용자 및 정보서비스 수준 평가자료를 검토한 뒤 장단기 관점에서 정보시스템 개선사항을 도출하는 순서로 제시된다.

개념

정보화 요건은 단순히 시스템 기능 요구를 나열하는 것이 아니라, 애플리케이션, 데이터, 기술구조, 네트워크, 정보관리체계, 운영조직, 보안 등 정보시스템 생태계 전반에서 요구되는 개선 수준을 정의하는 활동이다.

4.2 실습: 정보화 요건 정의 접근방법

원본 자료는 정보기술 환경, 정보시스템 현황, 사용자 및 정보서비스 수준을 분석하여 정보요소별 요건을 정의한다고 설명한다. 분석 관점은 기업 경쟁력 및 경쟁전략 차원, 현업 관리자 및 실무자 입장, 정보시스템 전문가 입장의 세 가지로 나뉜다.

Figure 7: 정보시스템 주요현안 정의 및 개선항목 정의 절차

분석 관점	주요 질문	확인해야 할 증거
전략 기여도	정보시스템이 경쟁전략과 핵심 업무를 지원하는가	전략 목표, CSF, 핵심 프로세스와의 연결성
업무 기여도	현업 사용자가 체감하는 업무 효율과 서비스 수준은 어떤가	사용자 설문, 인터뷰, 서비스 수준 평가
투자 경제성	개선 효과가 투자 규모와 운영 부담을 정당화하는가	비용, 효과, 리스크, 단계적 추진 가능성
기술 및 관리 구조	기술구조와 운영관리 체계가 안정성과 확장성을 보장하는가	아키텍처, 데이터 구조, 장애 대응, 보안 체계

4.3 심화: 정보시스템 현안정의 산출물

정보시스템 현안정의 산출물은 애플리케이션, 데이터, 정보기술구조, 네트워크, 정보관리체계 등으로 구분하여 현황, 문제점, 개선항목을 정리한다. 원본 자료의 호적정보시스템 사례는 프로그램 분배, 분산 데이터, 백업회선, 보안장비, 운영조직, 통합백업 관리 등 구체적인 개선항목을 제시한다.

실무 팁

정보화 요건은 장기 아키텍처 개선과 단기 운영 개선을 분리해서 작성해야 한다. 예를 들어 통합 데이터베이스 구축은 구조적 개선이고, 장애 복구 업무분장 구체화는 운영관리 개선이다. 두 과제는 연계되지만 추진 주기와 책임조직이 다르다.

주의

현행 시스템의 문제를 기술 용어로만 설명하면 경영진 의사결정에 연결되기 어렵다. 각 기술 현안은 업무 영향, 고객 영향, 위험 비용, 법제도 제약과 함께 설명해야 한다.

Task 2 핵심 요약

정보화 요건은 시스템 기능뿐 아니라 데이터, 기술, 운영, 보안, 관리체계를 포함한다.
전략, 현업, 전문가 관점을 동시에 반영해야 요건 누락을 줄일 수 있다.
현안정의 산출물은 현황, 문제점, 개선항목의 논리적 연결성을 가져야 한다.

CHAPTER 05

Task 3. 정보시스템 개선과제 도출

정보화 요건을 실행 가능한 개선과제로 재구성하는 방법

Source pages 33-47

5.1 개념: 개선방향과 중점 추진과제

정보시스템 개선과제 도출의 목적은 정보화 요건을 바탕으로 정보시스템 요소별 개선방향 및 개선과제를 도출하는 것이다. 정보화 요건들을 검토하고, 향후 정보시스템 개선방향과 중점 추진과제를 도출하며, 산출물은 정보시스템 개선과제가 된다.

Figure 8: 정보화요건에서 선정된 개선항목을 재분류하여 개선과제를 도출하는 흐름

개념

개선과제 도출은 요건을 다시 분류하는 행위가 아니라, 실행 가능한 변화 포트폴리오를 설계하는 행위이다. 따라서 과제명, 주요현안, 관련대상, 문제점, 고려사항이 함께 정리되어야 한다.

5.2 실습: 개선과제 세부내역 작성

원본 자료는 웹 기반의 통합 호적정보시스템 구축, 법원 감독 시스템 도입, 신고서류 및 제적부의 디지털 데이터화, 원본대조시스템 검증기능 강화, 관련기관과의 정보공유시스템 구축, 전국 분산 데이터의 중앙 통합, 장애 및 재해 대비 기반구조 구축, 정보보호 제도 및 보안 인프라 강화 등의 과제를 제시한다.

개선과제 유형	예시 과제	핵심 고려사항
애플리케이션 전환	웹 기반의 통합 정보시스템 구축	기존 C/S 구조의 한계, 변경관리 비용, 전국 서비스 일관성
업무 감독 및 지원	법원 감독 시스템 도입	보고, 통계, 우편송부 업무 개선과 감독기능 구현
데이터 디지털화	신고서류, 첨부서류, 제적부 데이터화	전자문서 표준, 법제도 개선, 구제적부와 신제적부 범위
데이터 통합	전국 분산 데이터의 중앙 통합	통합 일정, 백업 및 복구 서비스, 데이터 관리 책임
보안 및 안정성	재해 대비 기반구조와 보안 인프라 강화	가용성, 복구조직, 침입차단, 인증, 네트워크 보안

개선항목 목록에서 중복 항목을 제거한다.
연관성과 통합성을 기준으로 개선항목을 그룹화한다.
그룹별 과제명을 실행 지향적으로 정의한다.
각 과제별 주요현안, 대상, 문제점, 고려사항을 기술한다.
CSF와의 연관성을 확인하여 전략적 정합성을 검증한다.

5.3 심화: CSF 연관성 분석과 제조업체 사례

원본 자료는 정보시스템 개선과제가 호적정보화를 위한 주요성공요소를 충족하는지 분석한다. 특히 법원 관리감독 기능 강화, 전산호적부의 정확성과 보안성 확보, 업무 전문성 지원체계 확립, 관련기관 정보 제공절차 재확립, 본적지에 무관한 등초본 발급 서비스 제공, 정보화된 시스템을 원칙으로 하는 법제도 개선, 의사결정권자 지원과 구성원 실행의지와 연결된다.

제조업체 사례에서는 본사 및 단편적 관리 중심 시스템, 수작업 처리로 인한 업무 부하, 시스템 간 연계성 부족, 데이터 공동활용 체계 미흡, 기준정보 분류 기준 상이성, 단위 기능 중심 애플리케이션 구조의 확장성 부족 등이 현안으로 제시된다.

Figure 9: 정보시스템 개선과제와 제조업체 사례 산출물 이미지

주의

CSF 연관성 분석은 사후 장식용 표가 아니다. 과제가 전략 목표와 연결되지 않거나 연결 근거가 약하면, 해당 과제는 범위 조정, 추진시기 조정, 또는 제외 검토 대상이 된다.

Task 3 핵심 요약

정보화 요건은 중복 제거와 그룹화를 거쳐 실행 가능한 개선과제로 전환된다.
개선과제 세부내역은 대상, 현안, 문제점, 고려사항을 포함해야 한다.
CSF 연관성은 과제의 전략적 타당성과 추진 우선순위를 검증한다.

CHAPTER 06

요구사항 및 개선과제 종합

개별 요구사항을 개선과제 포트폴리오로 통합하기

Source pages 48-50

6.1 종합 정리의 목적

요구사항 정의와 개선과제 도출의 마지막 단계는 개별 과제를 부문별로 종합하는 것이다. 원본 자료의 제조업체 사례는 경영전략 체계 강화, 업무프로세스 재설계, 통합 고객관리체제 구축, 정보시스템 통합 등 부문별 개선과제를 정리한다.

부문	대표 개선과제	종합 관점
경영전략 체계 강화	중장기 경영전략 수립, 브랜드 이미지 및 마케팅 전략 수립, 사업 포트폴리오 구축	비전, 시장, 파트너십, 수익성 관점의 방향성 정렬
업무프로세스 재설계	미래 업무프로세스 재설계, 불합리한 규정 및 제도 정비	절차 간소화, 역할 명확화, 제도 개선
통합 고객관리체제 구축	고객성향 분석체계 정립, Web 중심 통합 고객관리 체제 수립	고객정보 축적, 이력 분석, 서비스 일원화
정보시스템 통합	현행 정보시스템 통합 연계 방안 수립, 신사업 지원시스템 기반 강화	데이터 공유, 시스템 연계, 확장성 확보

실습 포인트

종합표는 과제 목록을 모아놓은 것이 아니라 경영진 의사결정을 위한 포트폴리오이다. 따라서 부문별 과제는 전략적 의미, 업무 영향, 정보시스템 의존성, 추진 난이도가 드러나도록 정리해야 한다.

6.2 통합 고객관리 체제의 사례 해석

원본 자료는 고객 정보가 전문 서비스 기술과 함께 기업의 핵심 자산이며, 고객과의 지속적인 관계 유지가 미래 핵심 성공 요인이라고 설명한다. Web 중심의 통합 고객관리 체제는 다양한 경로로 얻어지는 고객정보를 일관되게 유지하고 관리하기 위한 기반이다.

개선과제	고려사항	요구사항 관점
고객성향 분석체계 정립	고객 관련 정보 축적, 보유 제품 정보 분석, A/S 이력 분석, 고객 평생 가치 분석	데이터 요구사항과 분석 요구사항
Web 중심 통합 고객관리 체제 수립	일원화된 고객관리, 지역 특성에 따른 Call 접수, One-Stop Service, Claim 공유	프로세스 요구사항과 기능 요구사항

심화

요구사항 종합 단계에서는 개별 Task의 산출물을 다시 읽어 과제 간 선후관계를 확인해야 한다. 예를 들어 고객정보 분석체계는 데이터 품질과 시스템 통합 없이는 구현 효과가 제한되며, 통합 고객관리 프로세스는 조직 역할과 서비스 기준이 함께 정비되어야 한다.

CHAPTER 07

참고문헌

요구사항 정의와 개선과제 도출에 활용한 이론적 배경

IEEE Computer Society, IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830.
Suzanne Robertson and James Robertson, Mastering the Requirements Process 및 Volere Requirements Specification Template.
Dai Clegg, MoSCoW prioritisation method, Dynamic Systems Development Method 관련 요구사항 우선순위화 접근.
Noriaki Kano, Attractive Quality and Must-Be Quality, Kano 품질모델.
Thomas L. Saaty, Analytic Hierarchy Process, 다기준 의사결정 방법론.
Norman Dalkey and Olaf Helmer, Delphi Technique, 전문가 합의 기반 예측 및 의사결정 기법.
원본 강의자료: B004_요구사항정의및개선과제도출_v2.1200(50).ppt.

선진 벤치마킹

지능한글 — Sat, 4 Jul 2026 20:57:43 +0900

A2.4 선진 벤치마킹 단행본

CONSULTING METHODOLOGY BOOK

A2.4 선진 벤치마킹

Best Practice를 발견하고, 성과 차이를 해석하며, 실행 가능한 요건으로 전환하는 컨설팅 방법론

원본 자료: B003_선진사벤치마킹_v2.1200(34).ppt

구성: 개요, 이론적 기초, 선진사 동향 파악, 벤치마킹 실시, 요건정의, 과제 및 평가

1.1 Activity 공정도와 정의

선진 벤치마킹 Activity는 개선과제의 해결방안을 수립하기 위해 우수 선진사례를 탐색하고, 그 사례의 운영 방식과 성과 요인을 분석한 뒤, 비즈니스 프로세스 요건과 정보인프라 요건으로 구체화하는 컨설팅 활동이다. 원본 슬라이드는 이 활동을 “Bench Marking 대상을 선정하여 비즈니스 및 정보시스템 측면에서 Bench Marking을 실시하고, 이를 바탕으로 비즈니스 프로세스 요건 및 정보인프라 요건 정의를 수행”하는 것으로 정의한다.

Figure 1. 선진 벤치마킹 Activity의 수행 프로세스와 정의

이론적 배경

Robert C. Camp는 Xerox의 경쟁력 회복 과정에서 벤치마킹을 체계화한 인물로 알려져 있다. 그의 관점에서 벤치마킹은 단순 비교가 아니라 “최고 성과를 가능하게 하는 방법을 찾아 조직 내부에 학습시키는 활동”이다. 따라서 Activity의 핵심은 대상 선정, 자료 수집, 성과 차이 분석, 원인 해석, 실행계획화의 연속성에 있다.

실무 적용 포인트

환경 및 현황분석에서 도출된 개선과제를 기준으로 벤치마킹 필요성을 선별한다.
비즈니스 프로세스와 정보시스템을 분리하지 않고 함께 검토하여 실행 가능한 미래모형을 만든다.
수집한 사례를 그대로 복제하지 않고, 자사의 전략, 제도, 문화, 기술 성숙도에 맞게 변환한다.

Practice

1.2 목적: 미래모형 수립을 위한 학습 장치

이 Activity의 목적은 환경 및 현황분석을 통해 정의된 개선과제를 해결할 때, 우수 선진사의 Best Practice를 직·간접적으로 분석하여 더 효과적이고 실용적인 미래모형을 수립하는 데 있다. 벤치마킹은 개선 아이디어를 외부에서 가져오는 활동처럼 보이지만, 실제로는 조직이 자신의 문제를 더 정확히 정의하고, 실행 가능한 대안을 검증하는 학습 절차이다.

Figure 2. 선진사 Best Practice 참조를 통한 미래모형 수립 목적

핵심 메시지

벤치마킹의 산출물은 “좋은 사례 목록”이 아니라 “왜 그 사례가 성과를 냈는지”와 “우리 조직에 적용하려면 무엇을 바꾸어야 하는지”를 설명하는 실행 가능한 요건이다.

CHAPTER 02

벤치마킹 이론적 기초

정의, 목적, 유형, 편견과 오해를 통해 벤치마킹의 경계와 활용 조건을 이해한다.

Concept

2.1 정의와 성공 조건

원본 자료는 벤치마킹을 미시적으로 “특정 분야에서 우수한 대상을 찾아 성과 차이를 확인하고, 그 차이를 극복하기 위하여 대상의 뛰어난 운영방식을 배우면서 자기 혁신을 추구하는 기법”으로 정의한다. 거시적으로는 선진사례의 전략, 업무프로세스, 정보기술, 조직에 대한 정보수집과 사례분석을 수행하고, 성과 차이의 원인을 분석하여 중장기 경영계획 또는 정보화계획에 반영하는 업무로 설명한다.

Figure 3. 벤치마킹의 미시적 정의, 거시적 정의, 성공 조건

Xerox 모델의 시사점

Xerox의 벤치마킹 모델은 경쟁사와 비경쟁 우수기업을 함께 관찰하면서 성과 격차의 원인을 프로세스 수준에서 규명하는 데 초점을 둔다. 이 접근은 “무엇이 다른가”보다 “왜 다르고, 그 차이를 우리 조직의 방식으로 어떻게 흡수할 것인가”를 묻는다는 점에서 단순 견학과 구분된다.

성공적인 벤치마킹의 구성 요소

구성 요소	의미	실무 확인 질문
성과 차이 분석	비교 대상과 자사의 현재 수준 차이를 확인한다.	차이를 측정할 지표가 정의되어 있는가?
원인 분석	성과 차이를 만든 프로세스, 조직, 기술, 제도 요인을 해석한다.	결과가 아니라 원인 수준까지 내려갔는가?
혁신 전략 수립	규명된 원인을 제거하거나 흡수하기 위한 실행 전략을 만든다.	실행 책임자와 일정이 정의되어 있는가?
변화관리와 평가	도입 과정의 저항, 교육, 지표, 사후 평가 방안을 설계한다.	실패 원인을 다시 학습할 평가 체계가 있는가?

Practice

2.2 목적과 기본 개념

벤치마킹의 목적은 전략적 이슈를 검토하고 업무 수행 방식, 역할, 정의를 개선함으로써 중장기 전략목표를 효율적으로 달성하는 것이다. 원본 자료는 이를 조직학습의 관점에서 설명한다. 벤치마킹은 우량기업의 최선의 실무를 찾아 자사에 적합하게 수정 도입하는 과정이며, 일회성 개선기법이 아니라 학습조직을 만드는 수단이다.

APQC 프레임워크와의 연결

APQC의 프로세스 분류 체계와 벤치마킹 접근은 비교 가능한 프로세스 단위를 정의하고, 프로세스 성과와 운영 관행을 함께 비교하도록 돕는다. 따라서 벤치마킹 항목은 기능명보다 프로세스, 성과지표, 운영 방식 중심으로 설계하는 것이 바람직하다.

벤치마킹 유형 비교표

유형	대상	장점	주의점	적합한 상황
내부 벤치마킹	같은 기업 내 다른 지역, 부서, 국가의 유사 활동	자료 수집이 쉽고 조직 맥락 이해가 빠르다.	내부 시각에 갇혀 혁신성이 낮을 수 있다.	다사업장, 다지역 조직의 표준화 과제
경쟁사 벤치마킹	동일 업종에서 고객을 공유하는 경쟁기업	비교 가능한 업무와 성과 정보를 얻을 수 있다.	자료 입수와 윤리적 문제가 발생할 수 있다.	시장 내 단기 경쟁우위 확보 과제
기능 벤치마킹	동일 기능 또는 유사 프로세스를 우수하게 수행하는 비경쟁 기업	혁신적 아이디어를 얻기 쉽다.	산업 맥락 차이를 조정하지 않으면 효과가 낮다.	구매, 물류, 고객서비스 등 공통 기능 개선
글로벌 벤치마킹	동일 업종의 비경쟁 기업 중 프로세스 성과가 우수한 조직	접근과 자료수집이 상대적으로 용이하고 비교 가능한 업무와 기술을 습득하기 쉽다.	문화와 제도 차이를 검토하지 않으면 잘못된 분석결과가 발생할 수 있다.	동일 업종 내 우수 프로세스 비교와 장기 혁신 과제

위 비교는 원본 자료의 대상별 유형 분류를 학습용으로 재구성한 것이다. 실무 현장에서는 내부, 경쟁사, 비경쟁, 글로벌 유형을 개선과제의 성격과 자료 접근성에 맞추어 선택한다.

Deep Dive

2.3 목적별, 방식별 분류와 오해

목적에 따라 벤치마킹은 전략적 벤치마킹, 고객 벤치마킹, 코스트 벤치마킹으로 나눌 수 있다. 방식에 따라서는 직접 방문과 인터뷰 중심의 직접적 벤치마킹, 공개 자료와 문헌 조사 중심의 간접적 벤치마킹으로 구분된다. 직접 방식은 정확한 자료와 관계 형성에 유리하지만 비용과 시간이 많이 들고, 간접 방식은 범위가 넓고 경제적이지만 핵심 자료 확보가 어렵다.

오해	실제 의미	컨설팅상 대응
벤치마킹은 모방 또는 복사다.	성공 접근 방식을 학습해 자사 맥락에 맞게 변환하는 것이다.	사례 요약보다 적용 조건과 변형 방안을 함께 제시한다.
최고 수준까지 눈높이를 높이면 충분하다.	수치가 아니라 성과를 만든 핵심 요건을 찾아야 한다.	성과지표와 원인 요인을 동시에 분석한다.
한 번 최고를 보면 끝난다.	시장, 기술, 고객 요구가 변하기 때문에 지속적 과정이다.	사후 모니터링 지표와 재검토 주기를 둔다.
벤치마킹은 견학과 같다.	명확한 목적, 사전 질문, 자료 요청, 분석 틀이 필요하다.	방문 전 벤치마킹 계획서와 질문지를 확정한다.
벤치마킹은 관리자가 수행해야 한다.	해당 사안을 많이 고민하고 이해하고 있는 실무 담당자가 주체가 되어야 효과적이다.	실무 담당자를 중심으로 팀을 구성하고 관리자는 범위, 의사결정, 지원 역할을 맡는다.

주의

벤치마킹은 “좋은 회사를 보고 오는 활동”이 아니다. 개선과제와 연결되지 않은 방문, 지표 없는 비교, 원인 분석 없는 사례 나열은 견학성 활동으로 전락한다.

CHAPTER 03

Task 1. 선진사 동향 파악

최적 벤치마킹 대상을 선정하기 위해 선진사례의 범위, 자료, 항목, 개선과제 연관도를 구조화한다.

Concept

3.1 개요

선진사 동향 파악의 목적은 미래모형 정립을 위해 선진업체 자료를 수집하고, 추진 현황과 동향을 정리하는 것이다. 궁극적으로는 벤치마킹을 위한 최적 대상을 선정하고 직접 또는 간접 방식을 결정하는 데 있다. 입력물은 정보기술 적용성 검토내역, 업무 프로세스 및 정보시스템 개선과제이며, 산출물은 선진사 동향 파악서이다.

Delphi 기법 활용

원본 자료는 전문가 집단의 전문기술, 즉 Delphi를 기법으로 제시한다. Delphi는 전문가 의견을 반복적으로 수렴해 불확실성이 큰 주제의 판단을 정교화하는 방식이므로, 벤치마킹 후보의 적합성 평가와 우선순위 결정에 유용하다.

접근 방법 단계별 흐름도

단계	활동	판단 기준	산출
Step 1	수행할 벤치마킹 유형을 대상별로 구분한다.	개선과제의 성격과 비교 가능성	유형 분류
Step 2	유형별 선진사 리스트를 작성하고 자료를 수집한다.	자료 접근성, 사례의 우수성, 관련성	후보 리스트
Step 3	자료 수집 정도를 표시하고 대상별 항목을 결정한다.	성과지표 확보 여부, 분석 깊이	자료 확보 현황표
Step 4	개선과제와의 연관도를 분석해 순위와 최종 대상을 결정한다.	전략 적합도, 실행 가능성, 파급효과	최종 벤치마킹 대상

Practice

3.2 분석 영역과 산출물 설계

선진사례 분석의 주요 영역은 전략, 업무 프로세스, 조직, 정보시스템으로 정의할 수 있다. 일관성 있는 분석을 위해서는 동향 파악 단계부터 네 영역을 기준으로 자료를 분류해야 한다. 이렇게 해야 후속 Task인 벤치마킹 실시와 요건정의에서 같은 관점으로 비교와 전환이 가능하다.

Figure 4. 선진사례 분석의 주요 영역: 전략, 업무 프로세스, 조직, 정보시스템

Figure 5. 선진사례 분석 절차와 벤치마킹 대상 선정 예시

실습 지침

선진사 동향 파악서는 “해외 동향, 국내 동향, 주제별 분류, 벤치마킹 대상 선정”의 네 부분으로 구성하면 좋다. 각 후보에 대해 자료 출처, 확인 수준, 관련 개선과제, 예상 학습 포인트를 함께 기록한다.

Deep Dive

3.3 사례: 일본 호적정보화 추진일정

원본 자료는 일본의 호적정보화 추진일정을 예시로 제시한다. 법무성 논의, 조사 연구회 설치, 민사행정심의회 자문, 호적법 및 주민기본대장법 개정 등 제도 정비와 시스템 준비가 단계적으로 진행되었다. 이 사례는 선진사례 분석에서 단순한 기술 도입 시점보다 법·제도, 운영 조직, 데이터 정비, 업무효율 향상 효과를 함께 봐야 함을 보여준다.

분석 관점	확인할 질문	요건정의로의 연결
제도	관련 법령과 규정이 어떻게 정비되었는가?	도입 전 선행 제도 정비 과제 도출
프로세스	기존 업무 흐름이 어떻게 단순화 또는 자동화되었는가?	TO-BE 프로세스 설계 기준 도출
데이터	자료의 정합성과 연계를 어떻게 확보했는가?	통합 데이터 관리 요건 도출
효과	서비스 속도, 직원 부담, 보고 업무 자동화가 어떻게 개선되었는가?	성과지표와 기대효과 정의

CHAPTER 04

Task 2. 벤치마킹 실시

선정된 대상에 대해 계획서를 작성하고, 자료 입수 방식과 질문 체계를 설계해 벤치마킹을 실행한다.

Concept

4.1 개요

벤치마킹 실시의 목적은 선정된 기업 또는 기관별로 벤치마킹 방식을 결정하고 실제 벤치마킹을 수행하는 것이다. 입력물은 선진사 동향파악서이며, 수행절차는 대상과 범위 선정, 벤치마킹 계획서 작성, 간접 또는 직접 방식에 따른 수행으로 이어진다. 산출물은 벤치마킹 요약서이다.

절차	핵심 활동	주요 산출
대상과 범위 선정	동향 분석 자료를 바탕으로 실제 비교할 조직, 기능, 프로세스를 확정한다.	대상 및 범위 정의
계획서 작성	일정계획, 문의자료, 입수자료, 입수방안을 정리한다.	벤치마킹 계획서
벤치마킹 수행	간접 조사, 설문, 직접 방문, 인터뷰 등 방식에 따라 정보를 수집한다.	원자료와 인터뷰 기록
요약과 해석	성과 차이와 원인, 적용 가능성을 분석한다.	벤치마킹 요약서

Practice

4.2 정보 자료 유형과 입수 방식

벤치마킹 정보 자료는 내부 정보, 공식 정보, 타 기업 또는 기관 정보로 구분된다. 내부 정보는 조직 내 문서와 지식시스템 자료를 의미하고, 공식 정보는 백서, 발표문서, 연구기관 자료와 같이 공개 접근 가능한 자료를 말한다. 타 기업 또는 기관 정보는 직접 벤치마킹 과정에서 확보하는 실무 정보로, 향후 요건정의와 차이분석의 근거가 된다.

사전준비의 중요성

원본 자료는 벤치마킹 수행 자체보다 사전준비가 더 중요하다고 강조한다. 준비가 부족하면 벤치마킹은 견학성 방문으로 전락한다. 직접 벤치마킹에서는 Contact Point 확보, 허용 여부, 일정, 제공자료 범위 협의에 충분한 시간을 두어야 한다.

직접 벤치마킹 질문 설계

질문 영역	질문 목적	예시 질문
관련 분야 설명	대상 조직이 비교 맥락을 이해하도록 한다.	해당 프로세스의 범위와 주요 이해관계자는 누구인가?
성과측정 항목	품질, 시간, 비용 관점의 비교 지표를 확보한다.	현재 사용하는 KPI와 목표 수준은 무엇인가?
개선 이력	개선 전략, 전개활동, 효과를 파악한다.	최근 개선활동의 배경, 실행 방식, 효과는 무엇인가?
지원 분야 운영	교육, 기술, 문서관리 등 기반 요인을 확인한다.	프로세스 운영을 지원하는 교육과 시스템은 무엇인가?

Deep Dive

4.3 산출물 예시와 사례 해석

원본 자료는 일본의 호적 법·제도와 주민등록 법·제도를 업무프로세스 측면, 법·제도 영역, 정보시스템 측면으로 나누어 분석하는 예시를 제시한다. 이 사례는 벤치마킹 결과가 단일 표나 보고서가 아니라 법·제도, 업무, 시스템, 데이터, 운영관리의 다층적 구조로 정리되어야 함을 보여준다.

Figure 6. 선진 법·제도 분석 영역과 분류 및 통합 비교

일본 호적정보화 특징	벤치마킹 시사점	요건 후보
철저한 사전준비	정보화 성공은 기술보다 준비 체계에 좌우된다.	단계별 로드맵과 전환 리허설
법·제도적 정비	제도 근거가 실행 안정성을 높인다.	관련 법령과 업무 규정 정비
다양한 응용 프로그램	현장 다양성과 표준화의 균형이 필요하다.	표준 인터페이스와 공통 데이터 모델
안정된 정보기술 사용	최신성보다 안정성과 검증성이 중요할 수 있다.	기술 선정 기준과 운영 안정성 지표

Figure 7. 일본 지방자치단체 호적업무 정보화 현황

Figure 8. 연도별 호적업무 정보화 시구정촌 수

Figure 9. 일본 호적정보시스템 구성도

심화 관점

사례 분석의 품질은 “그 조직은 무엇을 했는가”가 아니라 “그 방식이 왜 가능했는가”를 설명하는 정도로 결정된다. 법·제도, 예산, 조직역량, 데이터 품질, 문화적 수용성까지 함께 해석해야 우리 조직에 적용할 수 있는 요건으로 전환된다.

CHAPTER 05

Task 3. 요건정의

벤치마킹 결과를 이상적 프로세스 요건과 정보인프라 요건으로 변환한다.

Concept

5.1 개요

요건정의의 목적은 이상적인 프로세스 요건과 이를 지원하기 위한 정보인프라 요건을 정의하는 것이다. 입력물은 선진사 동향 파악서와 벤치마킹 요약서이며, 산출물은 정보인프라 요건 정의서와 프로세스 중심의 선진요건 정의서로 정리된다. 이 단계에서는 향후 기업의 전략을 실현하기 위한 이상적 업무프로세스 요건을 도출하고, 업무처리와 조직의 최적 운용을 지원할 시스템 요소를 정의한다.

요건정의의 전환 논리

벤치마킹 결과는 그 자체로 요건이 아니다. 선진사의 특징을 관찰한 뒤, 현재 조직의 문제와 연결하고, 적용 조건을 검토하며, 실행 가능한 문장으로 재구성해야 요건이 된다.

Practice

5.2 업무프로세스 요건과 정보인프라 요건

업무프로세스 요건 정의에서는 개념적 Work Flow, 수행 조직, 인력운영 현황, 정보시스템의 업무지원도, 지원조직 역할을 특성 중심으로 요약하거나 도식화한다. 정보인프라 요건 정의에서는 아키텍처, 응용 프로그램 구성, 적용 정보기술, 하드웨어와 네트워크 장비, 운영 원칙, 정보화 전략과 이행상의 문제점 및 대처방안을 정리한다.

구분	정의 대상	핵심 질문	산출 표현
프로세스 요건	업무 흐름, 역할, 조직, 처리 기준	어떤 업무 방식이 목표 성과를 가능하게 하는가?	프로세스 원칙, 역할정의, 업무처리 기준
정보인프라 요건	시스템, 데이터, 기술, 운영, 보안	프로세스가 안정적으로 실행되려면 어떤 인프라가 필요한가?	아키텍처 원칙, 시스템 기능, 운영관리 요건
전환 요건	변화관리, 교육, 제도, 이행계획	현재 상태에서 목표 상태로 가기 위해 무엇을 준비해야 하는가?	로드맵, 교육계획, 제도 정비 과제

주의

정보인프라 요건은 업무프로세스와 밀접하게 연결되어 있으므로 프로세스 요건 정의가 선행되어야 한다. 기술 요건만 먼저 정의하면 실제 업무 개선과 분리된 시스템 구축 요구가 만들어질 수 있다.

Deep Dive

5.3 산출물 사례: 프로세스와 인프라 요건

원본 자료는 선진사례 분석을 통해 미래 업무프로세스가 갖추어야 할 요건과 미래 정보시스템이 갖추어야 할 요건을 제시한다. 업무의 일관성 유지, 신속한 민원 서비스, 통합적 자료관리, 자료 정확성과 보안성, 통계정보 활용, 업무 자동화가 프로세스 요건으로 제시되며, 통합 데이터베이스, 고객 지원 및 운영 지원, 민원 서비스 기반구조, 중복관리, 유관기관 연계체계가 정보시스템 요건으로 제시된다.

요건 범주	대표 요건	실무적 의미
업무 표준화	업무의 일관성 유지	표준 절차와 유형 분류를 통해 처리 품질을 균일하게 만든다.
서비스 혁신	신속한 민원 서비스, One-Stop 서비스	고객 접점에서 지역과 채널 제약을 줄인다.
데이터 관리	통합적 자료관리, 통합데이터베이스 구조	자료 발생처와 수요처를 연계하고 신뢰성을 높인다.
운영 안정성	가용성, 확장성, 네트워크 안정성	피크타임과 장애 상황에서도 중단 없는 서비스를 보장한다.
보안	확고한 보안체계 구성	접근통제, 네트워크 보호, 시설 및 조직 보안을 다층적으로 설계한다.

요건 문장 작성법

좋은 요건 문장은 “무엇을 해야 한다”와 “왜 필요한가”를 함께 담는다. 예를 들어 “통합 데이터베이스를 구축한다”보다 “지역별 분산 데이터의 중복과 불일치를 줄이기 위해 통합 데이터베이스 구조를 지향한다”가 더 실행 가능하다.

CHAPTER 06

과제 및 평가

동향 파악, 벤치마킹 요약, 선진요건 정의의 세 과제를 통해 방법론을 실제 산출물로 훈련한다.

Practice

6.1 실습 과제 개요

실습은 세 개의 본 과제와 마무리 정리 활동으로 구성된다. 첫째, 기 선정된 주제를 바탕으로 프로세스 혁신 관점에서 선진사 동향파악서를 작성한다. 둘째, 벤치마킹 계획서를 작성하고 벤치마킹을 수행하여 요약서를 만든다. 셋째, 벤치마킹 결과를 토대로 기업의 비전과 전략 달성을 위한 이상적인 프로세스 요건 정의서를 작성한다. 이후 Wrap-Up을 통해 세 산출물이 하나의 스토리라인으로 연결되는지 점검한다.

과제	핵심 산출물	중점 관점	권장 시간
과제 1	선진사 동향파악서	해외 및 국내 선진 동향, 주제별 분류, 대상 선정	0.5H
과제 2	벤치마킹 요약서	목적, 기간, 업체, 수행자, 내용, 수집자료	1H
과제 3	선진요건 정의서	프로세스 중심 요건과 정보인프라 요건	0.5H
정리	Wrap-Up	스토리라인, 일관성, 발표 준비	0.5H

Deep Dive

6.2 작성 양식과 평가 기준

과제 작성 양식은 동향파악서, 벤치마킹 요약서, 선진요건 정의서의 흐름을 따른다. 원본 자료는 과제 평가를 100점 만점으로 환산하도록 제시하며, 과제 1과 과제 2는 각각 30점, 과제 3은 40점으로 배점한다. 평가지표는 Focus, Clearness, Consistency, Readability, Eagerness이다.

평가지표	평가 질문	좋은 산출물의 특징
Focus	주제와 요인 도출 범위가 잘 조정되어 있는가?	선택과 집중이 분명하고 핵심 개선과제에 연결된다.
Clearness	과제별, 세부과제별 Task 구분을 이해하고 있는가?	동향 파악, 실시, 요건정의가 명확히 구분된다.
Consistency	주제, 동향파악, 벤치마킹 실시, 요건정의의 흐름이 논리적인가?	앞 단계의 판단이 뒤 단계 산출물로 자연스럽게 이어진다.
Readability	고객 입장에서 읽기 쉽고 이해하기 쉬운가?	표, 흐름도, 요약 문장이 적절히 사용된다.
Eagerness	고심한 흔적과 진지함이 보이는가?	자료의 깊이, 질문의 구체성, 적용 검토가 충분하다.

실습 완료 체크리스트

벤치마킹 대상 선정 이유가 개선과제와 연결되어 있는가?
수집 자료의 출처와 신뢰 수준이 표시되어 있는가?
성과 차이뿐 아니라 차이를 만든 원인을 설명했는가?
요건 문장이 실행 가능한 수준으로 구체화되었는가?

핵심 요약

벤치마킹은 모방이 아니라 성과 차이의 원인을 학습하고 실행 요건으로 전환하는 방법론이다.
선진사 동향 파악, 벤치마킹 실시, 요건정의는 하나의 논리적 흐름으로 연결되어야 한다.
좋은 산출물은 사례를 많이 담는 것이 아니라, 개선과제와 연결된 적용 조건을 명확히 제시한다.

CHAPTER 07

참고문헌

본 단행본의 이론적 배경과 원본 슬라이드 출처

원본 강의자료: B003_선진사벤치마킹_v2.1200(34).ppt, 파싱 파일 B003_선진사벤치마킹_v2.1200(34).md.
Robert C. Camp, Benchmarking: The Search for Industry Best Practices That Lead to Superior Performance.
Xerox 벤치마킹 모델: 경쟁력 회복을 위한 Best Practice 탐색과 성과 격차 분석의 대표적 실무 사례.
APQC Process Classification Framework 및 벤치마킹 접근: 프로세스 단위 비교와 성과지표 기반 학습의 기준.
Michael J. Spendolini, The Benchmarking Book: 내부, 경쟁, 기능, 일반 벤치마킹 유형론.
Improving through Benchmarking, 21st Century Books: 벤치마킹에 대한 편견과 오해 관련 원본 자료 인용.

정보시스템 현황 분석

지능한글 — Sat, 4 Jul 2026 20:56:38 +0900

A2.2 정보시스템 현황 분석 단행본

CONSULTING METHODOLOGY BOOK

A2.2 정보시스템 현황 분석

어플리케이션, 데이터, 기술구조, 관리체계, 사용자 수준, 정보서비스 수준, 정보화 투자현황을 통합 진단하기 위한 7 Task 기반 단행본형 학습서

원본 자료: B002_정보시스템현황분석_v2.1200(116).ppt

변환 방식: 슬라이드 구조를 유지하되 이론 배경, 실무 절차, 비교표, 실습 과제를 보강한 HTML 단행본

작성일: 2026-06-29

1. 개요 — 정보시스템 현황분석의 의의와 7 Task 수행 체계

개념: 왜 정보시스템 현황을 먼저 분석하는가

정보시스템 현황분석은 운영 중인 응용시스템, 데이터, 기술 기반, 운영 조직, 사용자 역량, 서비스 수준, 투자 구조를 하나의 진단 체계로 묶어 현재의 적합성과 한계를 확인하는 활동이다. 원본 슬라이드는 현행 정보시스템 자체의 문제점을 파악하고, 새롭게 도출된 비즈니스 요구사항과 현행 시스템의 충족성을 비교한 뒤, 개선과제를 통합 도출하는 흐름을 강조한다.

엔터프라이즈 아키텍처 관점에서 보면 현황분석은 현재 아키텍처와 목표 아키텍처 사이의 차이를 식별하는 기준선 수립 단계다. TOGAF 표준은 조직이 엔터프라이즈 아키텍처를 수립하고 운영하기 위한 방법론과 프레임워크로 활용된다고 설명된다1. 따라서 정보시스템 현황분석은 단순 재고조사가 아니라 향후 To-Be 모델, 개선과제, 실행계획을 연결하는 증거 기반의 출발점이다.

Figure 1. 정보시스템 분석 Activity의 전체 구조

이론 배경

정보시스템 현황분석은 EA, ITSM, 품질관리, 투자 포트폴리오 관리가 만나는 지점이다. EA는 구조적 정합성을, ITSM은 서비스 운영 품질을, 품질모델은 사용성과 신뢰성을, 투자관리는 비용 대비 가치를 확인하게 한다.

실습: 7 Task 수행 체계

원본 자료는 현황분석을 일곱 개 Task로 분해한다. 각 Task는 입력물, 조사 항목, 분석기법, 산출물로 연결되며, 마지막에는 개선과제 도출의 근거로 통합된다.

Task	핵심 질문	주요 산출물	실무 활용
어플리케이션 분석	무슨 기능을 어떤 시스템이 지원하는가	현행 어플리케이션 기술서, 업무기능 매트릭스	중복 기능, 누락 기능, 인터페이스 개선 도출
데이터 분석	어떤 데이터가 어디서 생성, 조회, 수정, 삭제되는가	데이터 기술서, CRUD 매트릭스	데이터 중복, 품질 문제, 통합 대상 식별
기술구조 분석	H/W, S/W, N/W 구조가 요구사항을 수용하는가	기술 구조도, 기술구조 분석서	확장성, 재활용성, 장애 위험 검토
관리체계 분석	조직, 보안, 유지보수, 재해대책이 적절한가	정보관리 체계 분석서	운영 거버넌스와 책임체계 정비
사용자 수준 평가	사용자는 시스템을 활용할 역량과 의지가 있는가	사용자 수준 정의서	교육, 변화관리, 참여 전략 설계
정보서비스 수준 평가	서비스는 사용자가 기대하는 품질을 제공하는가	정보서비스 수준 정의서	SLA, 만족도, 개선 우선순위 설정
투자현황 분석	IT 투자 구조가 전략과 성과에 부합하는가	정보화 투자 현황 분석서	예산 배분, ROI, 포트폴리오 조정

Figure 2. 비즈니스 프로세스 분석과 정보시스템 분석의 연결 흐름

심화: 체크리스트를 진단 논리로 바꾸는 방법

슬라이드의 현황분석 체크리스트는 조직 기준일, 업무기능 분류, 프로세스 구조, HW, NW, DB, App., 정보관리 사항, 시스템과 업무기능의 연관성, 데이터와 App. 간 관계, 문제점과 요구사항의 논리적 연관성 등을 확인하도록 한다. 실무에서는 이 항목을 단순 확인표로 끝내지 말고, 현황 증거, 이슈, 원인, 개선과제, 실행 우선순위가 연결되는 추적성 구조로 관리해야 한다.

핵심 실무 포인트

좋은 현황분석은 많은 정보를 모으는 작업이 아니라 의사결정 가능한 형태로 정리하는 작업이다. 각 조사 항목마다 “어떤 개선 판단을 가능하게 하는가”를 함께 적어야 한다.

주의사항

현행 시스템 목록만 수집하고 업무 요구사항과 연결하지 않으면, 이후 To-Be 설계에서 왜 특정 시스템을 통합, 재개발, 유지해야 하는지 설명할 근거가 부족해진다.

Chapter 2

2. Task 1. 어플리케이션 분석

개념: 어플리케이션 포트폴리오와 업무지원 구조

어플리케이션 분석의 목적은 각 응용시스템의 구조와 상세 내역을 파악하고 개선사항과 필요 요건을 도출하는 데 있다. 원본 자료는 현행 시스템 개요, 기능차트, 세부 시스템 내역서를 입력물로 삼고, 현행 어플리케이션 구조도와 기술서를 작성한 뒤 업무기능 매트릭스로 정리하도록 제시한다.

어플리케이션 포트폴리오는 시스템을 “있는 것”으로만 보는 것이 아니라 업무 가치, 사용 빈도, 처리복잡도, 기술 노후도, 인터페이스 의존도 관점에서 평가하는 체계다. ISO/IEC 25010은 소프트웨어 및 ICT 제품의 품질 모델을 정의하므로3, 응용시스템 진단 시 기능 적합성, 성능 효율성, 사용성, 신뢰성, 유지보수성 같은 품질 특성을 점검 기준으로 활용할 수 있다.

Figure 3. 어플리케이션 분석 절차와 산출물 흐름

실습: 기능 특성 조사와 매트릭스 작성

어플리케이션 분석은 시스템 구조 파악, 단위 응용 기능 조사, 기능 특성 평가, 업무기능과의 상관관계 분석 순서로 진행한다. 원본 슬라이드는 처리타입, 발생주기, 처리형태, 처리시간, 처리복잡도, 사용자 수, 지역분산도를 주요 조사 항목으로 제시한다.

현행 시스템 목록과 시스템 간 관계를 조사하여 전체 Hierarchy를 작성한다.
각 단위 시스템의 기능, 개발 언어, 개발 방법, 사용 빈도, 사용자 범위, 위치, 처리 형태를 기술한다.
업무기능과 응용시스템을 교차시켜 지원, 중복, 미지원 영역을 식별한다.
관련기관, 외부 시스템, 인터페이스 방식과 입출력 정보를 조사한다.
개선사항을 기능 통합, 표준화, 재개발, 유지, 폐기 후보로 분류한다.

분석 기법	적합한 상황	장점	한계
조사 템플릿	시스템 수가 많고 기본 속성을 빠르게 수집할 때	일관성 있는 목록화 가능	응답 품질이 낮으면 실제 사용 맥락이 누락됨
인터뷰와 설문	사용자 불편, 운영 이슈, 개선 요구를 확인할 때	정성적 원인 파악에 강함	응답자 편향과 기억 오류 가능
Matrix 분석	업무기능과 시스템 지원관계를 구조화할 때	중복, 누락, 연계 문제를 시각적으로 파악	업무기능 분류가 부정확하면 결론도 왜곡됨

Figure 4. 어플리케이션 통합구조도 예시

심화: 어플리케이션 개선 판단 기준

개선 판단은 단순히 오래된 시스템을 새로 만드는 방식이 아니다. 업무 중요도는 높지만 기술 노후도가 심한 시스템은 현대화 우선순위가 높고, 업무 중요도와 사용 빈도가 낮으면서 중복 기능이 많은 시스템은 통합 또는 폐기 후보가 된다. 업무지원 누락이 발견되면 신규 기능 개발보다 먼저 프로세스 변화나 데이터 연계 개선으로 해결 가능한지 검토해야 한다.

실무 사례

대민 서비스 시스템과 내부 관리 시스템이 동일 고객 정보를 별도로 관리한다면, 기능 통합보다 먼저 기준 데이터와 인터페이스 책임을 정의해야 한다. 그렇지 않으면 화면은 통합되어도 데이터 불일치 문제는 계속 남는다.

주의사항

어플리케이션 분석에서 “사용자가 불편하다”는 의견만으로 시스템 폐기 또는 재개발을 결정해서는 안 된다. 불편의 원인이 화면 설계, 프로세스, 권한, 데이터 품질, 교육 부족 중 무엇인지 구분해야 한다.

Chapter 3

3. Task 2. 데이터 분석

개념: 엔티티, 데이터 품질, CRUD 관점

데이터 분석은 전사 후보 엔티티를 도출하고, 후보 엔티티의 정보 제공 현황과 현행 데이터 구조상의 문제점 및 해결 방안을 도출하는 Task다. 원본 자료는 현행 DB와 파일 레이아웃, CIR, 업무체계, 프로세스 분석 결과, 필요 정보와 요구사항을 활용하여 전사 엔티티를 정립하도록 안내한다.

데이터 분석의 핵심은 데이터베이스 목록을 만드는 것이 아니라 업무에서 실제로 사용하는 정보 항목을 기준으로 엔티티를 정립하는 것이다. Zachman Framework는 복잡한 시스템을 논의하기 위한 공통 언어와 구조를 제공하는 EA 관점의 틀로 설명된다4. 이 관점은 데이터가 업무, 기능, 위치, 책임자, 시점과 어떻게 연결되는지 묻도록 도와준다.

Figure 5. 데이터 구조 파악과 어플리케이션 데이터 상관도 구성

실습: 현행 데이터 기술서와 CRUD Matrix

원본 자료는 현행 데이터 기술서의 구성요소로 DB/FILE 이름, 형태, 건수, Size, 주요 수록 정보, 사용 조직을 제시한다. CRUD Matrix는 기능과 엔티티의 관계를 Create, Read, Update, Delete로 표시하여 데이터의 생성 책임, 조회 범위, 변경 권한, 삭제 위험을 파악하게 한다.

CRUD 기호	의미	진단 질문	발견 가능한 이슈
C	새 레코드 생성	최초 생성 책임은 어느 기능에 있는가	중복 입력, 기준 데이터 생성 책임 불명확
R	기존 레코드 조회	조회 권한과 활용 빈도는 적절한가	불필요한 권한, 조회 성능 저하
U	기존 레코드 수정	수정 권한과 이력관리는 통제되는가	데이터 불일치, 변경 추적 누락
D	레코드 삭제	삭제 기준과 복구 절차가 있는가	감사 추적 손실, 업무 증빙 훼손

Figure 6. 데이터 분석 산출물 예시

심화: 데이터 품질과 어플리케이션 구조의 상호작용

데이터 품질 문제는 데이터 자체의 문제가 아니라 시스템 구조, 업무 절차, 권한 관리, 입력 검증, 인터페이스 지연이 결합되어 나타나는 경우가 많다. 따라서 데이터 분석은 어플리케이션 분석과 분리해서 수행하더라도 결론은 반드시 통합해야 한다.

이론 보강

데이터 품질은 정확성, 완전성, 일관성, 적시성, 유일성, 유효성 관점으로 점검할 수 있다. 현행 데이터 기술서에는 단순 보유 현황뿐 아니라 데이터가 어떤 업무 의사결정에 쓰이는지도 기록해야 한다.

주의사항

CRUD Matrix에서 모든 기능에 R이 많게 표시되는 것은 자연스러울 수 있지만, C와 U가 여러 시스템에 분산되어 있으면 기준정보 불일치 위험이 높다. 이 경우 MDM 또는 기준 데이터 책임체계 검토가 필요하다.

Chapter 4

4. Task 3. 기술구조 분석

개념: 물리적 기술구조와 아키텍처 적합성

기술구조 분석은 현행 정보시스템의 물리적 기술 구조를 파악하고 문제점과 개선과제를 도출하는 Task다. 원본 자료는 App., H/W, S/W, N/W, Utility, 기타 설비에 대해 수량, 공급처, 구입시기, 위치, 역할, 현상태를 조사하고, 물리적 시스템 구성도를 작성하도록 제시한다.

기술구조 분석의 초점은 현재 자산이 새로운 시스템 요건을 수용할 수 있는지, 확장성과 상호운영성은 충분한지, 재활용 가능한 자원은 무엇인지 평가하는 데 있다. 이는 TOGAF의 기술 아키텍처 관점과 맞닿아 있으며1, 업무 요구와 기술 기반을 연결하는 필수 진단이다.

Figure 7. 기술구조 분석 접근방법

실습: 시스템 아키텍처와 기술 자원 조사

기술구조 분석에서는 정보시스템 구성도, H/W 구성도, S/W 구성도, N/W 구성도를 작성하고 장비 사양, 배치 현황, 개발 환경, 운영 환경, 연계 구조를 함께 조사한다. 원본 자료는 C/S와 Web, Mainframe과 C/S 비교를 통해 아키텍처 패턴별 장단점을 검토하도록 한다.

아키텍처 패턴	장점	위험	진단 포인트
중앙집중형	운영 통제와 안정성이 높고 프로그램 일괄 관리가 용이	특정 장비 종속, 확장 비용 증가	장애 단일점, 벤더 종속성, 용량 한계
Client/Server	분산처리와 GUI 구현에 유리	클라이언트 배포, 버전관리, 네트워크 의존성	클라이언트 표준화, 미들웨어, 배포 자동화
웹 기반	중앙집중 배포, 표준 브라우저 활용, 접근성 향상	서버 부하 증가, 보안 노출면 확대	성능, 세션관리, 인증, 웹 보안
서비스 기반	업무 기능 재사용과 연계 유연성 향상	서비스 경계 불명확, 운영 복잡도 증가	API 표준, 모니터링, 장애 격리, 계약 관리

Figure 8. 정보 서비스 형태에 따른 기반 시스템 분류

심화: 성능, 확장성, 상호운영성 진단

기술구조 분석은 장비 목록화에 머물면 안 된다. CPU, 메모리, 저장장치, 네트워크 장비, 소프트웨어 버전과 같은 항목은 시스템 부하, 업무 피크, 장애 이력, 보안 취약점, 확장 계획과 함께 해석되어야 한다. 특히 유관기관 연계, 공동이용, 유사서비스 비교가 필요한 프로젝트에서는 기술 구조가 외부 연계를 수용할 수 있는지 검토해야 한다.

핵심 실무 포인트

기술구조 분석서에는 “현재 구성”과 “문제점”만 적지 말고, 재활용 가능 자산, 즉시 개선 필요 자산, 중장기 전환 대상 자산을 구분해야 실행계획으로 연결된다.

주의사항

장비 사양이 높아도 네트워크 병목, 데이터베이스 락, 배치 시간 집중, 인터페이스 재시도 구조 때문에 서비스 품질이 낮을 수 있다. 성능 문제는 계층별로 분해해 확인해야 한다.

Chapter 5

5. Task 4. 관리체계 분석

개념: IT 거버넌스와 운영 관리

관리체계 분석은 현행 정보 조직 및 자원 관리 체계를 파악하고 개선점을 도출하는 Task다. 원본 자료는 정보시스템 관리 부문의 조직도, 업무분장도, 인터뷰 자료를 통해 단위 조직별 임무와 역할을 파악하고, 보안, 유지보수, 품질관리, 장애 및 재해대책을 조사하도록 제시한다.

ITIL은 IT 서비스 관리 분야에서 널리 활용되는 글로벌 베스트 프랙티스 프레임워크로 소개된다2. 따라서 관리체계 분석은 조직 구조뿐 아니라 서비스 운영 프로세스, 변경관리, 문제관리, 보안관리, 지속성 관리가 실제로 작동하는지 확인하는 활동으로 확장되어야 한다.

Figure 9. 정보관리체계 분석방법

실습: 운영조직, 보안, 유지보수, 재해대책 조사

원본 자료는 정보시스템 운영조직 현황, 개발 및 유지보수 현황, 보안관리 현황, 장애 및 재해대책을 관리체계 분석의 핵심 구성으로 제시한다. 이 네 영역은 각각 책임성, 변경 대응력, 위험 통제, 복구 능력을 확인하는 역할을 한다.

관리 영역	조사 항목	판단 기준	주요 산출물
운영조직	조직도, 업무분장, 인력 경력, 역할	책임과 권한이 명확한가	정보관리 조직체계도
유지보수	Corrective, Adaptive, Preventive, Perfective 유지보수	변경 요청과 장애 수정이 통제되는가	유지보수 현황표
보안관리	물리적 보안, 접근 보안, 통신 보안, 자료 유출 방지	관리적, 물리적, 기술적 통제가 균형적인가	보안관리 현황표
장애 및 재해대책	장애 예방, 복구 절차, 재해 복구 조직	복구 목표와 절차가 검증되었는가	장애 및 재해대책 분석서

Figure 10. 정보시스템 개발 및 운영조직 산출물 예시

심화: 프로세스 성숙도와 책임체계

관리체계의 성숙도는 문서가 존재하는지보다 실제 업무에서 반복 가능하게 실행되는지로 판단해야 한다. 예를 들어 장애 대응 절차가 있어도 훈련 기록이 없고, 연락망이 오래되었으며, 원인 분석이 개선과제로 연결되지 않는다면 성숙도는 낮다.

실무 사례

개발팀과 운영팀의 역할이 불분명하면 배포 실패, 장애 책임 회피, 긴급 수정 남발이 발생한다. 관리체계 분석에서는 R&R 표, 승인 절차, 변경 이력, 장애 후속조치까지 함께 확인해야 한다.

주의사항

보안관리 현황은 체크리스트 준수 여부만으로 판단하기 어렵다. 실제 계정 발급, 권한 회수, 로그 점검, 외주 인력 접근 통제가 업무 흐름 속에서 작동하는지 표본 점검해야 한다.

Chapter 6

6. Task 5. 사용자 수준 평가

개념: 사용자의 기술 수준과 변화 수용성

사용자 수준 평가는 정보시스템 사용자의 기술 수준과 이용 수준을 파악하고, 정보기술 수준 대비 사용자 수준을 비교 분석하는 Task다. 원본 자료는 사용자 설문서를 입력물로 삼고, 계층별, 조직단위별, 업무분야별로 정보기술 수준과 요구를 정리하도록 제시한다.

사용자 수준은 단순 컴퓨터 활용 능력이 아니라 업무 프로세스에 대한 이해, 정보화 마인드, 정보기술 활용 능력, 변화 참여 의지의 조합이다. 시스템이 아무리 잘 설계되어도 사용자의 업무 이해와 교육 수준이 낮으면 기대 효과가 낮아진다.

Figure 11. 사용자 수준 평가를 위한 조사 및 설문 구성 예시

실습: 설문 설계와 결과 해석

원본 자료는 사용자 수준 평가 영역을 업무 프로세스에 대한 마인드, 정보화에 대한 마인드, 정보기술 활용 능력 세 가지로 설정한다. 설문은 개인의 역량뿐 아니라 부서의 협업 문화와 정보화 프로젝트 참여 경험까지 포착해야 한다.

평가 영역	대표 질문	해석 관점	개선 방향
업무 프로세스 마인드	리드타임 단축, 프로세스 혁신 활동 경험	업무 개선 필요성을 이해하는가	프로세스 교육, 현업 워크숍
정보화 마인드	정보화가 경쟁력에 기여한다고 보는가	시스템 활용에 대한 태도와 참여 의지	변화관리 커뮤니케이션, 성공사례 공유
정보기술 활용 능력	OA, DB, 검색, 커뮤니케이션 도구 활용 능력	시스템 활용을 위한 기본 역량	직무별 교육, 실습형 매뉴얼

심화: 사용자 수준 평가를 개선과제로 연결하기

설문 점수는 개선과제의 시작점이지 결론이 아니다. 특정 부서의 정보화 마인드가 낮다면 시스템 기능 문제인지, 교육 부족인지, 업무 성과와 시스템 사용이 연결되지 않았기 때문인지 원인을 확인해야 한다.

핵심 실무 포인트

사용자 수준 평가는 교육 계획, 변화관리 계획, 권한 설계, 화면 개선 우선순위와 직접 연결해야 한다. 점수만 보고 “교육 필요”로 끝내면 실행력이 낮다.

주의사항

전문 IT 용어가 많은 설문은 사용자의 실제 수준보다 낮은 응답을 유발할 수 있다. 질문은 업무 언어로 작성하고, 필요하면 인터뷰로 보완한다.

Chapter 7

7. Task 6. 정보서비스 수준 평가

개념: 서비스 품질과 사용자 체감 품질

정보서비스 수준 평가는 정보시스템의 서비스 제공 수준을 파악하고 요구사항 및 개선사항을 도출하는 Task다. 원본 자료는 현행 기술구조 분석서와 현행 어플리케이션 기술서를 입력물로 활용하고, 계층별 설문을 통해 정보조직 및 정보시스템의 활용도와 정보기술 제공도를 평가하도록 제시한다.

서비스 수준은 기술 성능만으로 결정되지 않는다. 사용자가 느끼는 적합성, 편리성, 정보의 효과성, 서비스 제공도, 지원 대응이 함께 평가되어야 한다. ITIL이 디지털 제품과 서비스 관리의 성과, 신뢰성, 가치 개선을 위한 프레임워크로 소개되는 점2을 고려하면, 서비스 수준 평가는 운영 프로세스 개선과 직접 연결되어야 한다.

Figure 12. 정보서비스 수준 평가 종합결과 표현 예시

실습: 평가 분야와 설문 결과 분석

원본 자료는 정보서비스 수준 평가에서 일치 및 조화성, 편리성 및 친밀성, 제공 정보의 효율성 및 효과성, 정보서비스 제공도, 기타사항 등의 분야를 예시로 제시한다. 각 분야는 평균점수만이 아니라 낮은 점수의 원인과 개선 대책까지 함께 기록해야 한다.

평가 분야	주요 질문	낮은 점수의 가능 원인	개선 방향
일치 및 조화성	업무처리 절차와 출력 정보가 적절한가	업무 변화 미반영, 요구사항 누락	업무 프로세스 재정의, 화면 및 보고서 개선
편리성 및 친밀성	사용방법이 명확하고 오류 방지가 충분한가	UI 일관성 부족, 도움말 부재	사용성 개선, 매뉴얼 및 도움말 정비
정보의 효율성 및 효과성	필요 정보가 정확하고 시기적절한가	데이터 품질 저하, 처리 지연	데이터 품질관리, 성능 개선
정보서비스 제공도	개발의뢰, 교육, 유지보수 대응이 충분한가	서비스 요청 절차 미흡, SLA 부재	서비스 카탈로그, SLA, 운영 프로세스 개선

Figure 13. 정보서비스 수준 평가 분석서 예시

심화: SLA와 품질 모델의 결합

정보서비스 수준 평가는 사용자 만족도 조사로 끝나지 않아야 한다. 서비스 가용성, 응답시간, 장애 처리시간, 변경 요청 처리기간, 교육 제공 수준, 데이터 정확도 같은 운영 지표와 결합해야 실행 가능한 SLA로 발전할 수 있다. ISO/IEC 25010의 품질 특성은 소프트웨어 품질 평가 기준으로 활용될 수 있으므로3, 사용성, 신뢰성, 성능 효율성, 유지보수성 관점의 서비스 지표를 설계하는 데 참고할 수 있다.

주의사항

만족도 점수가 낮다고 해서 항상 시스템 재개발이 답은 아니다. 교육, 프로세스, 데이터 품질, 운영 대응, 권한 정책 문제가 원인일 수 있으므로 근본 원인을 분리해야 한다.

Chapter 8

8. Task 7. 투자현황 분석

개념: IT 투자 포트폴리오와 비용 구조

투자현황 분석은 정보화 프로젝트 추진 배경과 환경을 분석하고 정보화 투자현황을 파악하는 Task다. 원본 자료는 어플리케이션 분석, 데이터 분석, 기술구조 분석, 관리체계 분석 결과를 입력물로 활용하고, 정보화 프로젝트 추진 배경과 투자 현황을 분석하도록 제시한다.

투자현황 분석에서는 전산인력 비용, H/W, S/W, N/W 등의 최근 투자현황을 매출액 또는 예산, 손익과 비교하여 해석한다. Gartner는 전략적 포트폴리오 관리가 가치와 위험, 배포 계획, 채택 일정을 조정하는 로드맵 관점과 연결된다고 설명한다5. 따라서 IT 투자는 단일 프로젝트 비용이 아니라 전략 포트폴리오 관점으로 보아야 한다.

Figure 14. 정보화 투자현황 분석 접근방법

실습: 정보화 수준, 성숙 단계, 투자 동기 유형

원본 자료는 정보화 수준 진단, 정보화 성숙 단계 파악, 정보시스템 투자 동기 유형 파악, 정보화 추진 배경 분석을 제시한다. 투자 동기 유형은 필수형, 거래처리형, 정보제공형, 전략형, R&D형 등으로 구분된다.

투자 유형	의미	평가 기준	관리 포인트
필수형	법적, 기술적, 정책적으로 반드시 필요한 시스템	준수 위험과 운영 안정성	기한, 규정 준수, 장애 방지
거래처리형	주요 거래처리를 자동화하거나 지원	처리량, 오류율, 비용 절감	성능, 정확성, 표준화
정보제공형	보고, 지시, 회의, 정보수집 프로세스 개선	정보 접근성과 의사결정 지원	데이터 품질, 리포팅 체계
전략형	조직 목적과 사업전략 달성을 지원	경쟁우위와 전략 기여도	경영진 후원, 성과 지표
R&D형	기술적 가치와 미래 가능성 중심	학습 효과와 기술 옵션 가치	실험 범위, 종료 기준, 확산 기준

Figure 15. 정보화 프로젝트 추진 배경 분석 예시

심화: TCO, ROI, 포트폴리오 균형

투자현황 분석은 구축비만 보는 방식에서 벗어나 총소유비용 관점으로 운영비, 유지보수비, 라이선스, 인력, 교육, 장애 비용까지 포함해야 한다. 또한 ROI는 금전 효과만으로 계산하기 어려운 경우가 많으므로 업무 리드타임 단축, 오류 감소, 민원 감소, 규제 준수, 데이터 품질 향상 같은 비재무 효과도 함께 기록해야 한다.

분석 관점	TCO	ROI	전략 포트폴리오
핵심 질문	전체 생애주기 비용은 얼마인가	투자 대비 효과는 무엇인가	투자 묶음이 전략과 균형적인가
주요 입력	구축비, 운영비, 유지보수비, 인력비	효익, 절감액, 생산성, 품질 효과	사업전략, 위험, 의존성, 우선순위
한계	무형 비용 누락 가능	정성 효과 계량화 어려움	조직 정치와 예산 제약 영향

Figure 16. 정보화 투자현황 분석 산출물 예시

원본 산출물 예시: 대법원 1차 호적정보화 투자비용

원본 자료는 투자현황 분석의 산출물 예시로 호적정보시스템 구축사업과 확산사업의 비용 구조를 제시한다. 이 예시는 투자현황 분석서가 총액만 제시하는 문서가 아니라 인건비, 직접경비, 장비구입비 등 비용 항목을 분해해야 함을 보여준다.

구분	사업기간	주요 내용	투자비용
호적정보시스템 구축사업 1차 개발	1999.4~1999.12	호적자료입력시스템, 호적자료변환시스템, 호적정보시스템 표준시스템 개발	725,000,000
호적정보시스템 S/W 1차 확산	2000.7~2001.3	소프트웨어 1차 확산, 교육장 및 장비 임대, 교육용 PC와 노트북 구입 포함	2,024,000,000
호적정보화 투자현황 종합	1998.6~2001.3	호적사무전산화 연구, 전산입력 관리용역, 1차 개발, 1차 확산, 2차 개발 등	8,132,773,145

핵심 실무 포인트

투자현황 분석의 결론은 “예산이 많다/적다”가 아니라 “현재 예산 배분이 전략 목표, 운영 안정성, 미래 전환을 균형 있게 지원하는가”로 표현해야 한다.

Chapter 9

9. 과제 및 평가

실습 과제 1: 분야별 점검 항목과 채택 이유

정보시스템 현황분석에서 어플리케이션, 데이터, 기술구조, 정보관리체계별 점검 항목과 채택 이유를 작성한다. 원본 자료는 최대 동시 사용자 수, 최대 데이터 처리 건수, 시스템 사용 빈도, 기능 중복성, 로직 변경 빈도, 시스템 부하, 개발 비용과 기간, 투입 인력 등을 예시로 든다.

분야	점검 항목	채택 이유	개선과제 연결
어플리케이션	기능 중복성, 사용 빈도, 변경 빈도	통합, 유지, 재개발 판단 근거	기능 재배치, 표준화, 폐기 후보 선정
데이터	레코드 건수, 데이터 중복, CRUD 책임	성능과 품질 문제의 원인 파악	기준정보 정비, 데이터 통합, 품질관리
기술구조	부하, 용량, 네트워크 병목, 장비 노후도	확장성 및 안정성 판단	인프라 증설, 구조 개선, 표준화
관리체계	업무분장, 장애 대응, 보안 통제, 유지보수 계약	운영 성숙도와 위험 통제 확인	R&R 정비, SLA 수립, 보안 강화

실습 과제 2: 기술구조 문제점 도출

기술구조 분석의 현황자료를 바탕으로 예상되는 문제점을 도출한다. 예를 들어 WAN 속도 장애가 예상되면 회선 증속, 트래픽 분산, 캐시 구조 도입, 업무 피크 조정 등 대안을 함께 검토한다.

작성 방식

문제점은 “현상, 원인, 영향, 개선과제” 순서로 작성한다. 예를 들어 “원격지 응답시간 지연”이라는 현상만 적지 말고, 회선 대역폭, 중앙 서버 집중, 대용량 파일 전송, 배치 시간 중복 등의 원인을 확인한다.

실습 과제 3: 정보서비스 개선 대책

정보서비스 수준 분석 결과로부터 정보서비스를 개선하기 위한 대책을 작성한다. 원본 자료의 예시는 응용시스템 간 연계성과 상호 호환성 부족, 통계 및 분석 어려움, 운용 및 유지보수 어려움 등을 문제점으로 제시하고, 업무 프로세스 재정립, 연계 지원 응용시스템 구축, 정보 공유체계 구축 등을 개선과제로 제시한다.

Figure 17. 정보서비스 개선 대책 작성 예시

학습 정리

정보시스템 현황분석은 7 Task 결과를 통합하여 개선과제의 근거를 만드는 활동이다.
각 Task의 산출물은 독립 문서가 아니라 어플리케이션, 데이터, 기술, 운영, 사용자, 서비스, 투자 관점을 연결하는 증거다.
좋은 분석 결과는 현황, 이슈, 원인, 개선 방향, 실행과제가 논리적으로 이어진다.

Chapter 10

10. 참고문헌

아래 자료는 원본 슬라이드의 내용을 단행본형 문서로 확장하면서 이론적 배경을 보강하기 위해 참고한 출처다.

The Open Group, TOGAF Standard. https://www.opengroup.org/togaf
ITIL, Welcome to ITIL. https://www.itil.com/
ISO, ISO/IEC 25010:2011 Systems and software engineering. https://www.iso.org/standard/35733.html
Zachman International and FEAC Institute, About the Zachman Framework. https://zachman-feac.com/zachman/about-the-zachman-framework
Gartner, Strategic Portfolio Management. https://www.gartner.com/en/information-technology/role/strategic-portfolio-management

원본 자료

B002_정보시스템현황분석_v2.1200(116).ppt, 사용자 제공 파싱 파일 기반.

Figure 18. 원본 슬라이드에서 추출한 참고 이미지

비즈니스 프로세스 분석

지능한글 — Sat, 4 Jul 2026 20:51:53 +0900

A2.1 비즈니스 프로세스 분석 단행본

Consulting Methodology Book

A2.1 비즈니스 프로세스 분석

조직 및 업무체계 분석, 비즈니스 영역 분석, 프로세스 분석을 연결하는 업무 현황분석 실무 교재

원본: B001_비즈니스프로세스분석_v2.1200(77).ppt

작성일: 2026년 6월 29일
형식: 단행본 스타일 HTML 문서

1. 비즈니스 프로세스 분석의 역할

비즈니스 프로세스 분석은 업무 현황분석의 핵심 활동이다. 원본 슬라이드는 분석 결과가 프로세스 개선방향 도출의 기초자료로 활용된다고 설명한다. 이 관점에서 프로세스 분석은 단순한 업무 흐름 기록이 아니라, 조직의 전략과 실제 업무 수행 사이의 정렬 수준을 검토하는 진단 활동이다.

Figure 1. 비즈니스 프로세스 분석 액티비티의 역할

이론 배경

Hammer와 Champy의 BPR 관점은 기능 부서 단위의 개선보다 고객 가치 흐름을 기준으로 업무를 재설계해야 한다고 본다. Rummler와 Brache의 성과 개선 관점 역시 조직도보다 프로세스 흐름을 중심에 놓고 목표, 설계, 관리 체계를 연결한다. ISO 9001의 프로세스 접근법은 입력, 활동, 출력, 책임, 성과 지표를 하나의 관리 단위로 정의하는 실무적 틀을 제공한다.

따라서 본 문서의 분석 체계는 세 가지 질문으로 요약된다. 첫째, 조직과 업무체계가 현행 전략을 수행하기에 적합한가. 둘째, 비즈니스 영역과 기능 분류가 전사 관점에서 일관되게 정의되어 있는가. 셋째, 실제 프로세스 흐름에서 병목, 중복, 책임 공백, 정보 단절이 어디에서 발생하는가.

Figure 2. 비즈니스 프로세스 분석 액티비티의 입출력 관계

Practice

2. 수행 체계와 진단 관점

원본 자료는 기업의 비전, 미션, 경영전략 분석 결과를 토대로 현행 조직과 업무프로세스의 효율성 및 적합성을 파악하고 문제점과 개선사항을 도출한다고 제시한다. 실무에서는 이 정의를 다음 절차로 변환한다.

관련 자료, 업무기술서, 조직도, 규정, 인터뷰, 워크숍, 설문조사를 통해 현행 정보를 수집한다.
조직의 효율성, 프로세스의 유기적 연계성, 서비스의 고객지향성 같은 진단 관점을 선정한다.
조직, 기능, 프로세스를 각각 분석하되 세 결과가 서로 설명되는지 상호 검증한다.
문제점을 원인, 영향, 관련 조직, 개선 방향, 기대 효과와 함께 구조화한다.

Figure 3. 기업경영모델과 내부역량 진단의 연결

Figure 4. 비즈니스 프로세스 분석과 진단 관점 예시

Deep Dive

3. 기능 중심 분석과 프로세스 중심 분석의 균형

비즈니스 프로세스 분석에서 가장 흔한 오류는 조직도와 업무분장표만으로 현황을 판단하는 것이다. 조직도는 책임 단위를 보여주지만 고객에게 가치가 전달되는 실제 흐름은 여러 부서를 가로지른다. 반대로 프로세스 흐름만 보면 권한, 인력, 제도, 평가 체계 같은 조직적 제약을 놓치기 쉽다. 그러므로 원본 자료가 제시하는 조직, 기능, 프로세스의 세 축을 함께 읽어야 한다.

분석 관점	핵심 질문	대표 산출물	주의할 점
조직 관점	누가 책임지고 의사결정하는가	조직 구조 분석, R&R 매트릭스	공식 조직과 실제 업무 수행이 다를 수 있다.
기능 관점	어떤 업무 기능이 필요한가	업무 기능 체계, 업무 영역 정의서	기능 명칭이 부서명과 혼재되지 않도록 한다.
프로세스 관점	가치가 어떤 흐름으로 만들어지는가	프로세스 맵, 프로세스 정의서	세부 활동 나열에 그치면 개선 포인트가 흐려진다.

실무 핵심

분석의 첫 단계에서는 모든 문제를 해결하려 하기보다, 개선방향 도출에 필요한 증거를 축적하는 것이 중요하다. 자료 분석, 인터뷰, 설문, 워크숍은 서로 대체재가 아니라 교차 검증 수단이다.

PART I 요약

비즈니스 프로세스 분석은 전략, 조직, 기능, 프로세스를 연결하는 업무 현황분석 활동이다.
진단 관점은 조직 효율성, 프로세스 연계성, 고객지향성처럼 분석 목적을 분명히 하는 기준이어야 한다.
조직도, 기능 체계, 프로세스 흐름은 서로 다른 현실을 보여주므로 통합적으로 해석해야 한다.

PART II

Task 1. 조직 및 업무체계 분석

조직 구조, 직무, R&R 분석

Concept

1. 조직 및 업무체계 분석의 목적

원본 슬라이드는 Task 1의 목적을 현행 업무기술서 및 조직, 업무 상관도를 작성하고 현행 조직 및 업무체계상의 문제점과 개선사항을 파악하는 것으로 설명한다. 이는 조직 구조, 조직 운영체계, 인력구조, 업무기능체계를 함께 검토하여 현재의 책임 배분과 업무 수행 방식이 목표 달성에 적합한지 판단하는 활동이다.

Figure 5. 조직 및 업무체계 분석의 구성요소와 산출물

개념 보충

조직 분석은 조직도를 그리는 작업이 아니라 권한, 책임, 업무량, 의사결정 경로, 협업 구조를 진단하는 작업이다. 업무체계 분석은 가치사슬과 업무분류체계를 바탕으로 조직이 실제로 수행하는 기능을 재정의하는 작업이다.

Practice

2. 조직체계 분석 절차

조직체계 분석은 범위 설정, 조직구조 및 인력구조 파악, 운영체계 분석, 이슈 정의의 순서로 진행한다. 원본 자료는 조직모델 구성요소별 흐름도를 통해 구조, 운영체계, 인력구조가 서로 영향을 주는 관계임을 보여준다.

분석 범위를 확정한다. 지역별 조직, 사업장, 본부, 부서 중 어디까지 포함할지 명확히 한다.
기구조직도, 정원표, 직원 명부, 규정, 업무분장표 등 공식 자료를 수집한다.
인터뷰와 설문을 통해 공식 자료에 나타나지 않는 실제 업무 수행과 의사결정 관행을 확인한다.
조직별 업무기능 체계와 조직, 업무 매트릭스를 작성하여 책임 중복과 공백을 식별한다.

Figure 6. 조직모델 구성요소별 흐름도

Figure 7. 운영체계 분석 항목

기법	주요 목적	강점	한계
조직구조 분석	조직 계층, 보고 라인, 통제 범위 확인	책임 구조를 빠르게 파악할 수 있다.	실제 협업 흐름은 반영되지 않을 수 있다.
업무분장 분석	부서와 직무별 공식 역할 확인	책임 중복과 누락을 찾기 쉽다.	업무분장표가 최신 현실과 다를 수 있다.
R&R 매트릭스	수행, 승인, 협의, 통보 역할 구분	의사결정 지연 원인을 구조적으로 볼 수 있다.	역할 정의가 너무 세밀하면 유지가 어렵다.
인터뷰 및 설문	실제 운영 방식과 인식 차이 확인	정성적 원인과 조직 문화 요소를 포착한다.	응답 편향과 표본 대표성 관리가 필요하다.

Practice

3. 업무체계 분석과 가치사슬 활용

업무체계 분석은 가치사슬 내 활동 내역을 기초로 조직의 업무 기능을 분류하고 정리한다. 원본 자료는 지원활동과 기본활동을 구분하여 기업 기반구조, 인적자원관리, 기술개발, 구매조달, 내적 유통, 생산, 외적 유통, 영업, 서비스 등을 업무 기능 도출의 기준으로 활용한다.

실무 적용 포인트

가치사슬은 업종별 차이를 반영해 재해석해야 한다. 제조업에서는 생산과 물류가 중심이 될 수 있지만, 공공 행정이나 서비스업에서는 신청, 심사, 승인, 통지, 사후관리 같은 업무 흐름이 핵심 가치사슬이 된다.

Figure 8. 조직 및 업무체계 분석방법 예시

Deep Dive

4. 산출물 해석과 개선과제 도출

원본 자료의 산출물 예시는 조직구조 및 인력구조 분석, 설문조사 결과, 인력 현황, 업무량 조사, 제적부 활용도 조사 등으로 구성된다. 이러한 산출물은 단순 현황 보고가 아니라 개선과제의 근거가 되어야 한다. 예를 들어 감독 조직과 현장 조직 사이의 인식 차이가 크다면, 책임과 권한의 재정의, 업무 협조 절차 정비, 정보시스템 지원 범위 조정이 개선과제로 연결될 수 있다.

Figure 9. 조직 및 인력구조 분석을 위한 인식 조사 예시

Figure 10. 업무량 및 활용도 조사 결과 예시

원본 이론 보강: Mintzberg 조직 5부문

원본 자료는 Mintzberg의 조직 5부문을 활용하여 호적업무 수행조직의 역할을 전략부문, 중간라인부문, 기술구조부문, 지원스탭부문, 핵심운영부문으로 구분한다. 이 구분은 조직을 단순 계층이 아니라 전략 수립, 현장 운영, 표준화 설계, 지원 기능, 중간 조정의 조합으로 보는 관점이다. 실무 분석에서는 각 부문이 어떤 의사결정을 담당하고 어떤 업무 흐름을 지원하는지 확인해야 한다.

원본 이론 보강: Perrow의 비일상적 기술 관점

원본 자료는 Charles Perrow가 정의한 비일상적 기술의 조직 기술 분류 틀을 사용하여 업무 다양성, 인적 자질, 표준화, 통제범위, 분권화, 의사소통, 조정과 통제, 조직구조의 목표를 비교한다. 업무 난이도가 높고 예외 처리가 많은 조직에서는 절차 표준화만으로는 충분하지 않으며, 전문성 축적과 수평적 의사소통 체계가 함께 설계되어야 한다.

주의사항

설문 결과나 인터뷰 발언을 곧바로 조직 문제로 단정하면 안 된다. 자료 기반 분석에서는 공식 규정, 실제 처리 데이터, 현업 인식, 고객 영향도를 함께 검토하여 문제의 원인과 증상을 구분해야 한다.

분석 결과	가능한 원인	개선 방향	후속 산출물
책임 소재가 불명확함	업무분장과 실제 수행의 불일치	R&R 재정의 및 승인권 조정	R&R 매트릭스, 개선과제 목록
업무 협조가 원활하지 않음	부서 간 인터페이스 절차 부재	협업 프로세스와 회의체 운영 기준 수립	프로세스 맵, 협업 규정
특정 부서 업무량 집중	인력 배분 기준과 처리량의 불일치	업무량 기반 정원 재검토	업무량 분석표, 인력 재배치안

PART II 요약

조직 및 업무체계 분석은 구조, 운영체계, 인력, 기능을 통합적으로 검토한다.
가치사슬과 업무분류체계는 업무 기능을 체계화하고 조직, 업무 매트릭스를 작성하는 기준이 된다.
산출물은 현황 묘사가 아니라 문제 원인과 개선과제를 연결하는 증거 체계로 관리해야 한다.

PART III

Task 2. 비즈니스 영역 분석

기능 분류와 비즈니스 도메인 정의

Concept

1. 비즈니스 영역의 정의

원본 자료는 Task 2의 목적을 조직의 핵심 역량을 도출하고, 비즈니스 영역별 업무 기능체계 및 기능 간 의존도를 파악하는 것으로 제시한다. 여기서 비즈니스 영역은 조직 부서명이 아니라, 기업 또는 기관이 수행하는 업무 기능과 정보 요구를 묶는 분석 단위다.

Figure 11. 광의와 협의의 비즈니스 영역 정의

정의의 구분

광의의 비즈니스 영역은 가치 창출 활동과 핵심역량을 중심으로 정의한다. 협의의 업무 영역은 실제 업무 기능, 데이터 주제, 시스템 지원 범위를 구체화하기 위한 단위로 정의한다.

Practice

2. 핵심역량과 가치사슬 평가

비즈니스 영역 분석은 가치사슬 구성요소별 평가항목을 선정하고 보유 역량과 비교하여 핵심역량의 장단점을 파악한다. 이 단계에서는 전략적 중요도와 현재 수행 역량을 구분해야 한다. 전략적으로 중요하지만 현재 역량이 낮은 영역은 개선 또는 투자 후보가 되고, 중요도와 역량이 모두 높은 영역은 차별화 역량으로 관리한다.

Figure 12. 경쟁우위를 위한 가치사슬 구성요소별 평가항목

평가 축	질문	판단 기준	활용 결과
전략적 중요도	경쟁우위나 공공 서비스 품질에 얼마나 중요한가	전략 목표, 고객 가치, 규제 요구	우선 분석 영역 선정
현재 수행 역량	현재 조직이 안정적으로 수행하고 있는가	처리 품질, 업무량, 오류, 리드타임	강점과 취약점 구분
정보화 연계성	데이터와 시스템 개선으로 효과를 낼 수 있는가	주제데이터, 업무 규칙, 자동화 가능성	시스템 개선 후보 도출
기능 간 의존도	다른 업무 기능과 어떤 선후행 관계가 있는가	입출력 정보, 승인, 협업 빈도	업무영역 경계 조정

Deep Dive

3. 업무 기능체계와 주제데이터 매트릭스

원본 자료는 설정된 비즈니스 전략을 중심으로 업무내역조사서와 가치사슬 분석 결과를 활용하여 기업 전반의 업무 기능 체계를 구체화하고, 업무기능 대비 주제데이터 매트릭스 분석으로 업무영역을 정의한다고 설명한다. 이는 업무 기능과 데이터가 서로 분리되어 정의될 때 발생하는 정보시스템 단절을 예방하는 접근이다.

Figure 13. 업무영역 정의를 위한 입력 요소

실무 핵심

업무 기능체계는 너무 세분화하면 관리가 어렵고, 너무 넓게 정의하면 개선과제 도출이 어렵다. 기능은 의사결정과 데이터 책임을 부여할 수 있을 정도의 크기로 정의하는 것이 적절하다.

구분	기능 분류 중심	데이터 중심	프로세스 중심
목적	업무 기능의 체계화	정보 관리 책임 정의	업무 흐름과 성과 개선
주요 산출물	업무기능 분류표	주제데이터 매트릭스	프로세스 맵
강점	전사 업무 범위 파악에 유리	시스템 설계와 연계가 명확	병목과 중복 제거에 유리
주의점	부서명과 기능명이 혼재될 수 있음	데이터 소유권 논쟁이 발생할 수 있음	조직 권한 이슈를 놓칠 수 있음

주의사항

비즈니스 영역 분석은 산업별 표준 기능 목록을 그대로 적용하는 작업이 아니다. 원본 자료의 산업별 업무기능 예시는 출발점으로 활용하되, 실제 조직의 전략, 고객, 규제, 데이터 구조에 맞게 재구성해야 한다.

PART III 요약

비즈니스 영역은 부서가 아니라 업무 기능, 핵심역량, 데이터 책임을 묶는 분석 단위다.
가치사슬 평가를 통해 전략적 중요도와 현재 역량의 차이를 확인한다.
업무기능과 주제데이터 매트릭스를 연결하면 정보화 개선과 업무 개선을 함께 설계할 수 있다.

PART IV

Task 3. 프로세스 분석

프로세스 맵핑과 이슈 도출

Concept

1. 프로세스 분석의 목적과 대상

원본 자료는 Task 3의 목적을 현행 업무 기능별 프로세스를 정의하고 문제점과 개선과제를 도출하는 것으로 설명한다. 프로세스는 조직의 종적 기능단위에서 해결되지 않고 두 개 이상의 기능단위를 거쳐 처리되는 횡적 업무 흐름이다. 또한 반복 가능하고, 예측 가능하며, 정의 가능해야 분석과 개선의 대상이 된다.

Figure 14. 프로세스 분석 절차

Figure 15. 프로세스 정의와 요건

이론 배경

ISO 9001의 프로세스 접근법은 조직 활동을 상호 연관된 프로세스의 체계로 보고, 각 프로세스의 입력, 출력, 책임, 자원, 성과 지표를 관리하도록 요구한다. 이는 현행 프로세스를 정의하고 개선과제를 도출하는 본 Task의 실무 논리와 일치한다.

Practice

2. 프로세스 정의와 맵 작성

프로세스 분석은 부서 업무조사표와 비즈니스 영역 분석서를 참조하여 프로세스 정의서를 작성하고, 주요 액티비티를 중심으로 프로세스 맵을 작성한다. 원본 자료는 업무 모형에서 정의된 프로세스에 대해 목적, 개요, 개시 및 종료 요건, 주요 업무 흐름, 관련 부서를 정의하도록 안내한다. 특히 수행절차에서는 현행 업무기술서, 업무기능 구성도, 의존도를 참조하여 프로세스를 정의하고, 프로세스별 주요 액티비티를 도출한 뒤 FID(Function Information Diagram) 기법을 활용하여 현행 프로세스 맵을 작성하도록 제시한다.

FID 기법의 의미

FID는 기능과 정보의 관계를 함께 표현하여 프로세스 흐름 속에서 어떤 기능이 어떤 정보를 입력, 참조, 생성, 전달하는지 파악하는 기법이다. 업무 흐름도만으로는 정보 단절이나 중복 입력을 찾기 어려우므로, 정보 항목과 기능의 관계를 함께 표시하면 시스템 개선 요구사항으로 연결하기 쉽다.

프로세스 후보를 도출한다. 업무기능과 부서 업무조사표를 대조하여 반복적 흐름을 찾는다.
프로세스 경계를 정한다. 시작 사건, 종료 결과, 고객 또는 수혜자, 주요 입력과 출력을 명확히 한다.
액티비티를 배열한다. 수행 부서, 입력 정보, 작업 개요, 출력 정보를 함께 기록한다.
문제점과 개선방향을 도출한다. 병목, 재작업, 중복 승인, 수작업 전환, 데이터 재입력 지점을 확인한다.

Figure 16. 프로세스 정의 대상 영역의 선정

Figure 17. 프로세스 흐름 파악과 문제점 도출

Deep Dive

3. 프로세스 모델링 표기법 비교

원본 자료는 프로세스 흐름도, 프로세스 정의서, 액티비티 조사표, 업무처리규정 같은 산출물을 제시한다. 실무에서는 분석 목적에 따라 표기법을 선택해야 한다. 문제점 도출 중심이면 단순 흐름도와 스윔레인이 유용하고, 시스템 요구사항과 연계하려면 BPMN이나 액티비티 명세 수준의 표준화가 필요하다.

표기법	적합한 목적	장점	한계
기본 흐름도	업무 순서와 분기 이해	비전문가도 쉽게 읽을 수 있다.	역할과 시스템 경계를 세밀히 표현하기 어렵다.
스윔레인 맵	부서 간 인수인계와 책임 분석	책임 중복, 대기, 승인 지연을 찾기 쉽다.	복잡한 예외 처리가 많으면 도식이 과밀해진다.
BPMN	프로세스 자동화와 시스템 요구사항 연계	이벤트, 게이트웨이, 메시지 흐름을 표준적으로 표현한다.	참여자 교육 없이는 해석 부담이 커질 수 있다.
액티비티 기술서	작업 단위별 입력, 처리, 출력 명세	요구사항, 업무규칙, 화면 설계와 연결하기 좋다.	전체 흐름의 직관성은 낮을 수 있다.

주의사항

프로세스 맵은 상세할수록 좋은 것이 아니다. 현황 공유용, 문제 도출용, 시스템 설계용, 교육용 중 어떤 목적의 맵인지 먼저 정해야 한다. 목적이 섞이면 모든 정보를 담은 복잡한 그림이 되어 의사결정에 쓰기 어렵다.

Practice

4. 업무처리규정과 산출물 완성

원본 자료는 프로세스 상세화의 최종 단계로 업무처리규정을 작성하도록 한다. 업무처리규정에는 작업 수행자, 보안 사항, 다음 업무를 위해 준비할 사항, 시스템에서 관리되어야 할 업무규칙, 거래 유형 등이 포함된다. 이러한 규정은 프로세스 개선안이 실제 운영으로 정착되도록 만드는 연결 장치다.

Figure 18. 액티비티별 업무처리규정 정의

Figure 19. 업무 프로세스 분석 절차와 산출물

Figure 20. 전체 프로세스 분할도 예시

Figure 21. 전체 프로세스 흐름도 예시

Figure 22. 업무프로세스별 흐름도 및 액티비티 기술서 예시

실무 핵심

프로세스 분석의 최종 산출물은 프로세스 맵 자체가 아니라 개선 실행이 가능한 문제 정의다. 문제점은 반드시 발생 위치, 원인, 영향, 관련 조직, 개선 방향, 우선순위와 함께 기록해야 한다.

PART IV 요약

프로세스는 부서 경계를 가로지르는 반복적이고 정의 가능한 업무 흐름이다.
프로세스 정의서, 흐름도, 액티비티 기술서, 업무처리규정은 서로 연결된 산출물이다.
문제점 도출은 병목, 중복, 책임 공백, 데이터 재입력, 고객 지연을 중심으로 수행한다.

PART V

참고문헌

이론 출처와 원본 자료

참고문헌 및 원본 자료

원본 강의자료: B001_비즈니스프로세스분석_v2.1200(77).ppt, 사용자 제공 파일.
Hammer, M., & Champy, J. Reengineering the Corporation: A Manifesto for Business Revolution. HarperBusiness.
Rummler, G. A., & Brache, A. P. Improving Performance: How to Manage the White Space on the Organization Chart. Jossey-Bass.
ISO 9001 Quality Management Systems, process approach principles.
Porter, M. E. Competitive Advantage: Creating and Sustaining Superior Performance. Free Press.
Mintzberg의 조직 5부문 관점: 원본 PPT Page 33의 조직 및 인력구조 분석 프레임워크.
Charles Perrow의 비일상적 기술 조직 분류 관점: 원본 PPT Page 35의 업무관련 조직 특성 비교 프레임워크.
FID(Function Information Diagram) 기법: 원본 PPT Page 58의 프로세스 맵 작성 기법.

활용 안내

본 문서는 원본 PPT의 77페이지 구조를 개요, Task 1, Task 2, Task 3, 참고문헌의 단행본 구조로 재구성하고, 각 Task를 개념, 실습, 심화의 3단계 학습 흐름으로 확장하였다.

정보환경분석

지능한글 — Sat, 4 Jul 2026 20:50:20 +0900

A1.2 정보환경분석 단행본

A1.2 INFORMATION ENVIRONMENT ANALYSIS

정보환경분석

주요 정보기술 동향 파악, 정보기술 적용성 분석, CSF/CIR 연관분석을 연결하는 실무형 단행본

Figure 1. 원본 자료의 정보환경분석 표지

원천 자료: A005_정보환경분석_v2.1200(41).pdf, 41페이지.

1.1 정보환경분석의 목적

정보환경분석은 최신 정보기술의 동향과 추세를 파악하고, 기업의 필요 정보 요구에 적합한 주요 요소기술의 적용성을 분석하는 활동이다. 원본 자료는 이 분석의 범위를 두 갈래로 제시한다. 첫째, 외부의 정보기술 변화가 기업 전략과 업무 방식에 어떤 기회를 제공하는지 확인한다. 둘째, 내부의 정보기반구조, 정보관리 체계, 정보관리 구조가 목표 정보시스템을 수용할 만큼 효율적인지 진단한다.

이 장에서 중요한 핵심어는 CSF와 CIR이다. CSF는 핵심성공요소로서 조직이 전략 목표를 달성하기 위해 반드시 관리해야 할 성공 조건을 의미한다. CIR은 핵심정보화 요구사항으로서 CSF를 달성하기 위해 정보시스템이 제공해야 하는 정보, 기능, 데이터, 통제 요건을 뜻한다. CSF 중심 접근은 경영자의 핵심 관심사를 정보시스템 요구로 전환하는 데 유용한 방법론으로 활용될 수 있다.

개념 보충

정보환경분석은 단순히 새로운 기술 목록을 수집하는 작업이 아니다. 기술 추세, 업무 요구, 전략 목표, 현행 정보시스템 역량을 연결하여 투자 우선순위를 결정하기 위한 분석 체계이다.

Figure 2. 정보환경분석의 목적과 CSF, CIR 관계

Practice

1.2 수행공정

원본 자료의 수행공정은 개요, 주요 정보기술 동향 파악, 정보기술 적용성 분석, CSF/CIR 연관분석, 실습과제의 흐름으로 구성된다. 실무에서는 이 흐름을 프로젝트 착수 단계의 분석 계획과 연결해야 한다. 분석 대상 조직의 전략 방향이 불명확하면 CSF를 도출할 수 없고, 정보기술 후보가 지나치게 넓으면 적용성 분석이 피상적으로 끝난다. 따라서 수행공정은 분석 범위 확정, 자료 수집, 기술 구조화, 적용성 평가, 전략 연계의 순서로 운영하는 것이 바람직하다.

분석 범위 정의: 기업 전략, 주요 업무, 대상 정보시스템, 조직 단위를 확정한다.
기술 동향 수집: 문헌, 벤더 자료, 표준화 동향, 전문기관 자료를 수집한다.
정보기술 구조화: 사용자 인터페이스, 데이터, 네트워크, 보안 등 분석 영역을 나눈다.
적용성 평가: 기술별 성숙도, 필요성, 구현 난이도, 위험을 평가한다.
CSF/CIR 연계: 전략 목표에서 정보화 요구사항을 도출하고 기술 대안과 연결한다.

Figure 3. 정보환경분석 수행공정

Deep Dive

1.3 분석 산출물과 품질 기준

분석 산출물은 보고서의 분량보다 의사결정 가능성이 더 중요하다. 원본 자료는 주요 정보기술 동향, 정보기술 적용성 분석 결과, CSF/CIR 매트릭스를 핵심 산출물로 제시한다. 이 산출물은 정보전략계획, 목표 시스템 아키텍처, 단계별 이행계획의 입력 자료가 된다.

산출물	주요 내용	품질 기준	활용 의사결정
주요 정보기술 동향	기술 흐름, 요소기술, 표준화 방향, 적용 사례	기술 분류 체계가 명확하고 과거, 현재, 미래의 변화가 연결되어야 한다.	후보 기술군 선정
정보기술 적용성 분석	TBB 기반 기술 특성, 적용 가능성, 필요성, 위험	기업 요구와 기술 특성이 직접 연결되어야 한다.	도입 우선순위 결정
CSF/CIR 매트릭스	핵심성공요소와 핵심정보화 요구사항의 연관도	연관 강도 판단 기준이 일관되어야 한다.	전략과 정보시스템 투자 연결

주의 사항

정보환경분석은 최신 기술을 많이 나열할수록 좋은 결과가 되는 것이 아니다. 기업의 전략 목표와 업무 문제를 설명하지 못하는 기술 목록은 투자 판단에 직접 기여하지 못한다.

Figure 4. 정보환경분석 산출물 구조

Chapter 1 핵심 요약

정보환경분석은 기술 동향과 기업 정보 요구를 연결하는 전략 분석 활동이다.
CSF는 전략 성공 조건, CIR은 이를 지원하기 위한 정보화 요구사항이다.
좋은 산출물은 기술 목록이 아니라 투자 판단과 목표 시스템 설계를 가능하게 하는 근거이다.

CHAPTER 02

주요 정보기술 동향 파악: IT 트렌드 스캐닝과 기술 로드맵

과거, 현재, 미래의 기술 흐름을 분석하여 정보전략계획에 반영할 후보 기술을 정의한다.

Concept

2.1 개요와 분석 관점

주요 정보기술 동향 파악의 목적은 대상 기업에 적용 가능한 정보기술을 정의하고, 일반적인 추세와 기술 현황을 정리하여 정보전략계획에 반영할 수 있는 기술을 파악하는 것이다. 원본 자료는 문헌과 정보기술 전문업체 자료를 활용하여 정보처리 구조와 정보기술 요소별 일반 추세를 수집하고, 기술의 개념, 기능, 성능, 기술 내역, 표준화 방향을 정리하도록 제시한다.

Gartner와 같은 기술 리서치 기관의 하이프 사이클, 기술 성숙도 관점, IEEE와 ISO 계열 표준화 관점은 기술 동향을 해석할 때 참고할 수 있는 대표적 틀이다. 다만 외부 리서치의 용어를 그대로 도입하기보다 조직의 업무, 데이터, 보안, 통합 구조에 맞게 재분류해야 한다.

TBB 관점

원본 자료는 주요 정보기술 동향 분석의 기법으로 TBB를 제시한다. TBB는 기술 구성요소를 체계적으로 분해하여 정보기술 기반구조를 이해하고 후보 기술을 구조화하는 분석 관점으로 활용된다.

Figure 5. 정보기술 활용추세와 기반구조 분석 절차

Practice

2.2 접근방법: 흐름 분석과 기반구조 정의

정보기술의 과거, 현재, 미래에 대한 전반적인 흐름을 분석하면 기술의 활용 추세를 파악할 수 있다. 원본 자료는 기술 구성요소를 사용자 인터페이스, 사무환경, 애플리케이션 서비스, 애플리케이션 지원서비스, 데이터 서비스, 애플리케이션 개발환경, 시스템 플랫폼, 네트워크, 보안 및 시스템관리, 외부 접속환경 등 10개 영역으로 분류한다. 이 분류는 기술 조사를 산발적 목록이 아니라 정보기술 기반구조 관점의 체계적 진단으로 전환한다.

분석 영역	검토 질문	대표 산출 관점
사용자 인터페이스	사용자 경험, 접근성, 업무 편의성을 어떻게 개선할 것인가.	UI 표준, 사용자 채널, 접근 방식
데이터 서비스	데이터 구조, 품질, 통합, 활용 수준은 충분한가.	데이터 모델, 메타데이터, 품질관리
시스템 플랫폼	운영체제, 서버, 클라우드, 미들웨어 구조가 목표 시스템을 지원하는가.	플랫폼 후보와 전환 방향
네트워크	내부망, 외부망, 통신 용량, 안정성, 연계 구조는 적정한가.	네트워크 아키텍처와 개선 과제
보안 및 시스템관리	정보 유출, 접근통제, 운영 모니터링, 장애 대응은 통합 관리되는가.	보안 통제와 운영관리 체계

기술 흐름 수집: 과거, 현재, 미래의 변화 방향을 같은 기준으로 정리한다.
기반구조 분류: 10개 영역에 기술과 이슈를 배치한다.
대상 기업 관련성 판단: 전략, 업무, 데이터, 법규, 보안과 관련 있는 기술을 선별한다.
기술별 분석서 작성: 개념, 기능, 성능, 표준화, 적용 사례를 동일한 형식으로 정리한다.

Figure 6. 정보기술 기반구조 영역별 분석 관점

Deep Dive

2.3 기술 흐름 분석: 과거, 현재, 미래

원본 자료의 정보기술 흐름 분석은 전산실 중심과 중앙집중 처리환경에서 사용자 중심과 분산처리 환경을 거쳐 개인생활 중심, 복합 및 통합 처리환경으로 변화하는 흐름을 제시한다. 데이터베이스는 계층형에서 관계형, 객체형으로 확장되고, 사용자 인터페이스는 문자 기반에서 그래픽 기반, 멀티미디어 및 인간과 기계 간 인터페이스로 확장된다. 네트워크는 저용량 단일매체에서 고용량 복합매체, 유무선 통합망으로 발전한다.

구분	과거	현재	원본 자료의 미래 방향
처리 구조	전산실 중심, 중앙집중 처리	사용자 중심, 분산처리	복합, 통합 처리환경
시스템 구조	메인프레임 의존, 1-Tier	클라이언트 서버, 2-Tier와 3-Tier	웹 기반 Multi-Tier와 분산 연계
인터페이스	Character User Interface	Graphical User Interface	멀티미디어, 생체인식, 자연어 인터페이스
네트워크	저용량 단일매체	고용량 복합매체	유무선 고속 통합망

실무 포인트

기술 흐름 분석의 핵심은 과거, 현재, 미래를 단절된 세 칸으로 쓰는 것이 아니라 현재 조직의 위치를 표시하고 목표 아키텍처까지의 전환 경로를 찾는 것이다.

Figure 7. 정보기술 흐름 분석 산출물 예시

Practice

2.4 요소기술 분석서 작성

원본 자료의 산출물 예시는 기술 분석을 동일한 틀로 정리하도록 유도한다. 예를 들어 인터넷, 인트라넷, 익스트라넷, 멀티미디어, 통합망, 객체지향 언어, 자연어 처리와 같은 기술은 각각 개념, 기능, 성능, 적용 영역, 표준화 방향, 도입 시 고려사항을 갖는다. 컨설팅 보고서에서는 기술별 서술 길이보다 동일한 비교 기준이 중요하다.

항목	작성 내용	검토 기준
기술 개념	기술의 정의와 해결하려는 문제	업무 담당자가 이해할 수 있는 수준인가.
기능과 성능	주요 기능, 처리 성능, 확장성, 안정성	도입 판단에 필요한 비교 기준이 있는가.
기술 내역	구성 요소, 필요 인프라, 관련 솔루션	아키텍처 반영이 가능한 수준인가.
표준화 방향	표준, 프로토콜, 상호운용성 고려사항	장기 운영과 연계 위험을 평가했는가.
적용 시사점	대상 기업의 적용 가능성과 제약	전략, 업무, 데이터 요구와 연결되는가.

오용 방지

벤더 자료의 장점만 수집하면 기술 선정이 공급자 중심으로 치우친다. 반드시 대상 기업의 업무 문제와 정보 요구를 기준으로 기술의 유효성을 다시 평가해야 한다.

Figure 8. 요소기술 분석 산출물 예시

Chapter 2 핵심 요약

주요 정보기술 동향 파악은 기술 후보를 정보전략계획에 반영하기 위한 선별 활동이다.
10개 정보기술 기반구조 영역은 기술 목록을 체계화하는 실무적 분류 틀이다.
기술 흐름 분석은 현재 위치와 미래 목표 아키텍처 사이의 전환 과제를 찾는 데 초점을 둔다.

CHAPTER 03

정보기술 적용성 분석: TBB 기반 적용가능성 평가

후보 기술이 조직의 전략, 업무, 데이터, 운영 조건에 실제로 적합한지 평가한다.

Concept

3.1 적용성 분석의 의미

정보기술 적용성 분석은 주요 정보기술 동향 파악에서 도출된 후보 기술을 대상으로 기업에 대한 적용 가능성을 평가하는 단계이다. 원본 자료는 TBB를 활용하여 정보기술의 기능, 현황, 효과, 적용 가능성을 분석하고, 기업의 정보화 방향에 반영할 기술을 식별하도록 구성되어 있다. 이때 적용 가능성은 기술 자체의 우수성만으로 판단하지 않는다. 업무 적합성, 데이터 요구, 보안 요구, 표준 준수, 운영 역량, 비용과 위험을 함께 고려해야 한다.

적용성 분석은 정보기술이 조직의 주요 활동, 업무 흐름, 데이터 공유, 의사결정 구조를 실제로 개선하는지 확인하는 단계이다. 따라서 어떤 기술이 조직의 가치활동을 실제로 개선하는지, 또는 단순한 기술 유행에 그치는지를 구분해야 한다.

적용성 평가의 핵심 질문

이 기술은 기업의 어떤 CSF와 관련되는가. 어떤 CIR을 충족하는가. 현행 정보기반구조에서 구현 가능한가. 구현하더라도 운영 조직이 지속적으로 관리할 수 있는가.

Figure 9. 정보기술 적용성 분석의 개요와 절차

Practice

3.2 접근방법과 평가 절차

적용성 분석은 후보 기술별로 동일한 평가 기준을 적용해야 비교 가능성이 생긴다. 먼저 기술 후보를 확정하고, 각 기술의 기능적 특성과 비기능적 특성을 정리한다. 다음으로 조직의 업무 요구, 정보 요구, 현행 시스템 구조, 보안과 운영 조건을 기준으로 적합성을 평가한다. 마지막으로 기술 적용의 우선순위와 적용 방식, 선행 과제를 도출한다.

후보 기술 목록 확정: 기술 동향 분석에서 도출된 기술을 중복 없이 정리한다.
평가 기준 정의: 전략 관련성, 업무 효과, 기술 성숙도, 구현 난이도, 보안 위험을 기준으로 삼는다.
기술별 평가: 정성 평가와 필요 시 점수화 평가를 병행한다.
적용 시나리오 작성: 즉시 적용, 시범 적용, 중장기 검토, 제외로 분류한다.
우선순위 도출: 효과와 실현 가능성의 균형을 고려해 이행계획의 입력으로 넘긴다.

평가 기준	질문	판단 결과 예시
전략 관련성	CSF와 CIR을 직접 지원하는가.	높음, 보통, 낮음
업무 효과	업무 속도, 정확성, 통제, 서비스 품질을 개선하는가.	정량 효과 또는 정성 효과
기술 성숙도	표준과 사례가 충분하며 안정적으로 운영 가능한가.	검증됨, 성장 중, 실험적
구현 난이도	현행 시스템, 데이터, 조직 역량으로 구현 가능한가.	낮음, 중간, 높음
위험과 통제	보안, 법규, 운영 리스크가 관리 가능한가.	관리 가능, 조건부, 위험 높음

Figure 10. 정보기술 적용성 분석 접근방법

Deep Dive

3.3 분석기법: TBB와 적용가능성 매트릭스

TBB 기반 분석은 기술을 분해하고 구조화하여 기술의 위치와 역할을 파악하는 데 유용하다. 하지만 적용가능성 평가는 기술 구조만으로 끝나지 않는다. 실무에서는 TBB와 함께 가치사슬 영향, 업무 프로세스 영향, 데이터 영향, 통제 영향, 전환 난이도를 함께 평가해야 한다. 특히 공공 또는 대규모 조직의 정보환경분석에서는 보안, 표준, 상호운용성, 법제도 적합성이 기술 성능만큼 중요하다.

분석기법	주요 목적	강점	한계
TBB	기술 구성요소와 기반구조를 체계적으로 분해	기술 후보를 구조화하고 누락을 줄인다.	업무 가치와 조직 수용성을 별도로 검토해야 한다.
적용가능성 매트릭스	후보 기술의 효과와 실현 가능성을 비교	우선순위 도출에 적합하다.	평가 기준의 가중치가 불명확하면 주관성이 커진다.
가치사슬 영향 분석	정보기술이 주요 가치활동을 어떻게 바꾸는지 평가	전략 효과를 설명하기 쉽다.	조직별 가치활동 정의가 선행되어야 한다.
위험 분석	보안, 운영, 전환, 법규 리스크 검토	실행계획의 현실성을 높인다.	정량 자료가 부족하면 보수적 판단이 필요하다.

심화 관점

적용성 분석의 좋은 결론은 특정 기술을 도입하자는 문장이 아니라, 어떤 업무 문제를 어떤 기술 조합으로 해결하고 어떤 선행 조건을 충족해야 하는지를 제시하는 것이다.

Figure 11. 적용가능성 분석기법 예시

Practice

3.4 산출물 작성 방식

적용성 분석 산출물은 기술별 평가표, 적용 가능성 종합표, 우선순위 목록, 도입 시 고려사항으로 구성할 수 있다. 원본 자료는 여러 페이지에 걸쳐 산출물 예시를 제시한다. 이를 단행본 방식으로 확장하면, 각 기술별로 평가 결과와 판단 근거를 함께 남겨야 한다. 판단 근거가 없으면 후속 이행계획 수립 단계에서 왜 해당 기술이 포함되었는지 설명하기 어렵다.

기술명	지원 CIR	효과	실현 가능성	권고
기술 A	관련 CIR 기재	업무 자동화와 데이터 공유 개선	현행 시스템 연계 조건부 가능	시범 적용
기술 B	관련 CIR 기재	보안 통제와 접근관리 강화	운영 정책 정비 필요	중기 적용
기술 C	관련 CIR 기재	대민 또는 고객 서비스 채널 확대	인프라와 표준 검토 필요	추가 검토

평가표 작성 주의

점수표를 사용할 때는 점수의 합계보다 점수의 근거가 더 중요하다. 근거 없는 5점 척도는 합리적 의사결정을 돕지 못한다.

Figure 12. 정보기술 적용성 분석 산출물 예시

Chapter 3 핵심 요약

정보기술 적용성 분석은 후보 기술의 전략 관련성과 실행 가능성을 함께 평가한다.
TBB는 기술 구조화에 유용하지만 업무 가치, 데이터, 보안, 운영 역량과 결합해야 한다.
산출물에는 평가 결과뿐 아니라 판단 근거와 선행 조건이 반드시 포함되어야 한다.

CHAPTER 04

CSF/CIR 연관분석: 전략 목표와 정보시스템의 연계

핵심성공요소와 핵심정보화 요구사항의 관계를 매트릭스로 분석한다.

Concept

4.1 CSF/CIR 연관분석의 목적

CSF/CIR 연관분석의 목적은 CSF와 CIR의 연관성을 분석함으로써 경영전략과 정보전략의 방향을 일체화하는 것이다. 원본 자료는 입력물로 CSF를 제시하고, 매트릭스 분석기법을 이용하여 CSF와 CIR의 연관성을 분석한 뒤 CSF/CIR 매트릭스를 산출물로 작성하도록 설명한다.

원본 자료의 CSF/CIR 관점에서 정보시스템은 조직이 반드시 달성해야 하는 성공 조건을 측정하고 지원하는 수단이다. CIR은 이 성공 조건을 달성하기 위해 필요한 정보화 요구사항이다. 따라서 CSF/CIR 매트릭스는 정보시스템 구축 과제가 전략과 무관하게 추진되는 것을 방지하는 통제 장치가 된다.

연계의 의미

CSF가 전략의 언어라면 CIR은 정보시스템의 언어이다. CSF/CIR 연관분석은 두 언어 사이의 번역표를 만드는 작업이다.

Figure 13. CSF와 CIR 연관분석 접근방법

Practice

4.2 접근방법: CSF와 CIR 나열, 연관도 작성

원본 자료는 일반환경분석에서 도출된 CSF와 정보환경분석에서 도출된 CIR의 연관관계를 파악하도록 제시한다. 실무 절차는 먼저 CSF와 CIR을 각각 정의하고, 그 의미와 범위를 명확히 한 뒤, 행에는 CSF를, 열에는 CIR을 배치하여 매트릭스를 작성하는 방식이다. 각 셀에는 직접 연관, 간접 연관, 연관 없음과 같은 기호를 부여한다.

CSF 정의: SWOT 분석과 전략대안에서 핵심성공요소를 도출한다.
CIR 정의: 정보환경분석 결과에서 핵심정보화 요구사항을 도출한다.
연관 기준 합의: 직접 연관, 간접 연관, 연관 없음의 판단 기준을 문서화한다.
매트릭스 작성: CSF와 CIR의 관계를 셀 단위로 평가한다.
해석: 많은 CSF를 지원하는 CIR과 특정 CSF에 필수적인 CIR을 우선 검토한다.

기호	의미	판단 기준	해석
직접 연관	해당 CIR이 CSF 달성에 직접 필요	정보가 없으면 CSF 달성이 어렵거나 통제가 불가능함	우선 반영 후보
간접 연관	해당 CIR이 CSF를 보조적으로 지원	성과 개선에 기여하지만 필수 조건은 아님	선택 또는 단계적 반영
연관 없음	명확한 지원 관계가 없음	전략 목표와 정보 요구가 연결되지 않음	제외 또는 재검토

Deep Dive

4.3 SWOT, 전략대안, CSF, CIR의 연결

원본 자료는 SWOT 분석과 이를 통한 전략대안, CSF, CIR을 도출하여 정의하는 방식을 제시한다. SWOT은 강점, 약점, 기회, 위협을 통해 전략대안을 도출하는 출발점이다. 그러나 SWOT 결과가 곧바로 정보시스템 요구가 되는 것은 아니다. 전략대안에서 성공 조건을 정리한 것이 CSF이고, 그 성공 조건을 수행하고 측정하고 통제하기 위한 정보 요구가 CIR이다.

단계	질문	산출물	다음 단계 연결
SWOT 분석	조직의 내부 역량과 외부 환경은 무엇인가.	강점, 약점, 기회, 위협	전략대안 도출
전략대안 정의	어떤 방향으로 경쟁력과 성과를 높일 것인가.	SO, WO, ST, WT 전략대안	CSF 도출
CSF 정의	전략 성공을 위해 반드시 달성해야 할 조건은 무엇인가.	핵심성공요소 정의서	CIR 도출
CIR 정의	CSF 달성을 위해 필요한 정보와 시스템 기능은 무엇인가.	핵심정보화 요구사항 정의서	정보기술 적용성 분석과 연계

실무 사례 관점

원본 자료의 예시는 호적정보화와 관련하여 법원 관리감독 기능, 전산호적부의 정확성과 보안성, 업무 전문성 지원, 교육 프로그램, 관련기관 정보 제공 절차 등을 CSF로 두고, 온라인 감독, 검색, 전자적 데이터 전송, 보안장치, 온라인 교육 등의 CIR과 연결한다.

Figure 14. CSF/CIR 분석 산출물 예시

Practice

4.4 CSF/CIR 매트릭스 해석

원본 자료의 매트릭스 분석방법은 상에서 하로 CSF를 나열하고 좌에서 우로 CIR을 나열하여 상호 관련 정도를 파악하는 방식이다. 분석된 연관성은 CSF에 해당하는 CIR이 많을수록, 그리고 CIR과 관련된 CSF가 많을수록 정보화를 위한 필수 요소로 평가된다. 따라서 행 기준 해석과 열 기준 해석을 함께 수행해야 한다.

해석 관점	검토 방식	의사결정 의미
행 기준	한 CSF를 지원하는 CIR이 충분한지 확인	전략 목표별 정보화 지원 수준 판단
열 기준	한 CIR이 여러 CSF에 공통적으로 기여하는지 확인	공통 플랫폼 또는 우선 투자 후보 식별
강한 연관 셀	직접 연관이 집중된 영역 확인	핵심 구축 과제 후보
빈 셀	연관이 없는 조합의 이유 확인	요구사항 제외 또는 CSF 재정의 검토

주의 사항

매트릭스는 자동으로 정답을 산출하지 않는다. 강한 연관 표시가 많다는 이유만으로 도입 우선순위를 결정하면 비용, 위험, 기술 성숙도, 조직 준비도 같은 실행 조건을 놓칠 수 있다.

Chapter 4 핵심 요약

CSF/CIR 연관분석은 경영전략과 정보전략을 연결하는 핵심 절차이다.
SWOT, 전략대안, CSF, CIR은 단계적으로 연결되어야 한다.
매트릭스 해석은 행 기준과 열 기준을 함께 수행해야 하며, 실행 가능성 평가는 별도로 보완해야 한다.

CHAPTER 05

실습과제

정보기술 분석요소 정의, 기술 동향 조사, CIR 도출을 통해 분석 역량을 훈련한다.

Practice

5.1 과제 구성

원본 자료의 실습과제는 세 가지로 구성된다. 첫째, 경영환경분석에서 선정된 실습 주제에 대한 정보환경분석을 수행하기 위해 정보기술 분석요소와 구조를 정의한다. 둘째, 정의된 분석구조에 따라 최소 분석요소에 대한 일반 동향을 조사한다. 셋째, 경영환경분석 실습과제에서 정의된 CSF로부터 CIR을 도출한다.

과제	목표	작성 산출물	평가 기준
과제 1	정보기술 분석요소 및 구조의 정의	분석영역 분류표, 분석 범위, 조사 질문	분류 체계의 완전성과 대상 조직 관련성
과제 2	정보기술 일반 동향 조사	기술별 동향 분석서, 과거 현재 미래 흐름표	기술 개념, 기능, 표준화 방향, 적용 시사점의 충실도
과제 3	CIR 도출	CSF/CIR 정의서, 연관 매트릭스	CSF와 CIR의 논리적 연결성

Deep Dive

5.2 실습 진행 가이드

실습은 개인별 기술 조사와 팀별 통합 분석을 결합하는 방식이 효과적이다. 개인은 하나 이상의 기술 요소를 맡아 기술 개념, 기능, 성능, 적용 사례, 표준화 방향을 정리한다. 팀은 각 개인의 결과를 10개 기반구조 영역에 배치하고, CSF와 CIR의 연관성을 매트릭스로 통합한다. 마지막으로 우선 적용 기술과 제외 기술을 구분하고 판단 근거를 발표한다.

제출물 체크리스트

분석 범위, 기술 분류 체계, 기술별 분석서, 적용성 평가표, CSF 정의서, CIR 정의서, CSF/CIR 매트릭스, 우선순위와 실행 시사점을 하나의 보고서로 묶는다.

실습 시 주의

검색 결과를 붙여 넣는 방식으로는 좋은 분석이 되기 어렵다. 각 기술이 선택한 실습 주제의 전략 목표와 업무 문제를 어떻게 지원하는지 반드시 설명해야 한다.

Chapter 5 핵심 요약

실습은 분석 구조 정의, 기술 동향 조사, CIR 도출의 세 단계로 진행한다.
개인 조사 결과는 팀 차원의 기반구조 분류와 CSF/CIR 매트릭스로 통합되어야 한다.
최종 제출물은 기술 조사보다 전략 연계와 적용 가능성 판단을 중심으로 평가한다.

REFERENCES

참고문헌과 원천 자료

원본 강의자료의 내용을 기반으로 단행본형 설명과 이론적 배경을 보강하였다.

6. 참고문헌

원천 자료: A005_정보환경분석_v2.1200(41).pdf, 41페이지, 사용자 제공 파싱 파일.
이론 보강 참고: Rockart의 CSF 방법론은 CSF와 CIR의 개념적 연결을 설명하기 위한 배경 지식으로 참조하였다.
이론 보강 참고: Porter & Miller의 정보기술과 경쟁우위 논의는 정보기술 적용성 분석의 전략적 의미를 설명하기 위한 배경 지식으로 참조하였다.
이론 보강 참고: Gartner의 IT 트렌드 분석 관점, IEEE 및 ISO/IEC의 정보기술 표준화 관점은 기술 동향과 표준화 방향을 설명하기 위한 배경 지식으로 참조하였다.

작성 범위

본 HTML 단행본은 원본 자료의 41페이지 구조를 유지하되, 각 장을 개념, 실습, 심화의 3단계로 재구성하고 이론 배경, 비교표, 실무 적용 관점을 추가하였다.

경영환경분석

지능한글 — Sat, 4 Jul 2026 20:48:48 +0900

경영환경분석 단행본

컨설팅 분석 기법 교재

경영환경분석

일반환경, 경쟁환경, 내부역량, 비전 및 전략 분석을 통합하여 컨설팅 과제의 방향성과 제약조건을 정의하는 실무형 단행본

원천 자료: A004_경영환경분석_v2.1200(83).pptx
작성 정보: 사용자 요청에 따라 생성된 HTML 교재

경영환경분석의 개념

경영환경분석은 컨설팅 대상 기업 및 대상 이슈에 영향을 미치는 외부 환경과 내부 역량을 함께 파악하는 활동이다. 원천 슬라이드는 경영환경분석의 목적을 문제해결 과정에서 일관되게 지향해야 할 방향성과 결과의 현실성을 위해 고려되어야 할 제약조건을 정의하는 것으로 설명한다. 따라서 이 활동은 단순한 배경조사가 아니라 이후 현황분석, 미래모형 정립, 실행계획 수립의 판단 기준을 만드는 출발점이다.

Figure 1. 기업을 둘러싼 경영환경과 분석 대상의 범위

이론적 위치

경영환경분석은 외부환경의 기회와 위협, 내부역량의 강점과 약점을 연결한다. 산업구조 관점은 Porter의 경쟁전략 이론, 내부자원 관점은 핵심역량 분석과 연결되며, 전략 실행 관점에서는 Kaplan과 Norton의 BSC가 비전과 성과지표의 연결을 지원한다.

Practice

수행공정과 산출물

원천 자료는 경영환경분석을 네 개 Task로 제시한다. 일반환경분석은 경제, 시장, 사회문화, 기술, 정책 등 외부 거시요인을 살피고, 경쟁환경분석은 산업 내 경쟁자, 신규진입자, 대체재, 공급자, 구매자의 힘을 분석한다. 내부역량분석은 가치사슬, 조직요소, 성과관리, 이해관계자를 통해 강점과 약점을 규명하며, 비전 및 전략분석은 SWOT과 CSF를 통해 전략과제를 도출한다.

Figure 2. 경영환경분석 Activity의 수행공정

분석 영역	핵심 질문	주요 산출물	대표 기법
일반환경	어떤 거시 변화가 기업에 기회나 위협이 되는가	일반환경분석서	PEST, 시장환경 분석, Delphi
경쟁환경	산업 매력도와 경쟁압력은 어떻게 변하는가	경쟁환경분석서	5-Forces, 3C, 경쟁자 분석
내부역량	외부 변화에 대응할 강점과 보완할 약점은 무엇인가	내부역량분석서	Value Chain, 7S, BSC, BSD
비전/전략	분석 결과를 어떤 전략주제와 CSF로 전환할 것인가	CSF, 비전전략보고서	SWOT, CSF

Deep Dive

분석 품질을 좌우하는 관점

좋은 환경분석은 넓게 조사하되 산출물은 선명해야 한다. 모든 외부 변화와 내부 이슈를 같은 무게로 다루면 의사결정에 활용하기 어렵다. 컨설턴트는 자료의 신뢰성, 의사결정 관련성, 미래지향성, 실행 가능성을 기준으로 정보를 선별해야 한다.

실무 포인트

경영환경분석의 최종 목적은 많이 아는 것이 아니라 무엇을 해야 하는지 판단할 수 있게 하는 것이다. 각 분석 항목은 반드시 시사점, 예상 영향, 대응 방향 중 하나로 연결되어야 한다.

핵심 요약

경영환경분석은 컨설팅 방향성과 제약조건을 정의하는 기준 활동이다.
외부환경, 경쟁환경, 내부역량, 비전/전략은 SWOT과 CSF로 통합된다.
산출물은 분석서, 기회·위협 목록, 강점·약점 목록, 전략주제, CSF로 이어져야 한다.

CHAPTER 02

Task 1. 일반환경분석 — PEST 기법과 시장환경 분석

기업의 일반적인 외부환경을 분석하여 경영에 영향을 주는 주요 환경요소를 도출한다.

Concept

일반환경분석의 목적

일반환경분석은 기업을 둘러싼 거시환경과 시장환경의 제반 상황에서 컨설팅 과제에 영향을 미치는 요인, 예상 시나리오, 대응방안을 도출하는 과정이다. 원천 자료는 경제적 환경, 정치 및 정책 환경, 사회문화 환경, 기술 환경, 자연환경, 시장환경을 핵심 범주로 제시한다.

Figure 3. 일반환경분석의 목적과 산출물 흐름

PEST 관점

PEST는 Political, Economic, Social, Technological 요인을 구분하여 거시환경을 구조화하는 접근이다. 자료에서는 여기에 시장환경, 자연환경, 경쟁환경 관련 요소까지 포함하여 컨설팅 과제에 맞는 확장형 일반환경 분석을 제안한다.

Practice

분석 절차와 Attitude

실무 절차는 외부환경 파악, 변화요소 도출, 파급효과 판단, 기회·위협 분류, 대응방안 정리의 순서로 진행된다. 자료수집은 문헌, 통계, 외부 보고서, 관계자 설문 및 인터뷰를 함께 활용한다.

Figure 4. 거시환경 및 시장환경 구성요소 분석

경제, 정책, 사회문화, 기술, 시장 등 분석 범주를 정의한다.
각 범주별 변화요인을 Fact Base로 수집한다.
컨설팅 과제와 관련성이 낮은 요소는 제외한다.
기회와 위협, 파급효과, 대응방안을 한 줄로 연결한다.
최신성과 현실성을 검토해 과장된 결론을 제거한다.

주의할 Attitude

부분 사례로 전체를 설명하거나 특정 사실을 과장하거나 과거 자료만으로 미래 영향을 단정하는 방식은 피해야 한다. Fact Base, Comprehensive, Relevant, Updated, Future Oriented와 Realistic의 균형이 필요하다.

Deep Dive

일반환경·시장환경 분석요소 비교

구분	대표 질문	주요 자료	전략적 해석
경제적 요인	성장률, 물가, 이자율, 환율, 에너지 가격이 수익성에 어떤 영향을 주는가	거시경제 통계, 산업 전망	수요, 비용, 투자여력의 변화
정치·정책 요인	법률, 규제, 정부정책이 사업기회를 촉진하거나 제한하는가	정책자료, 법령, 규제 동향	진입장벽, 인허가, 공공지원 가능성
사회문화 요인	인구구조와 라이프스타일 변화가 고객 니즈를 바꾸는가	인구통계, 소비자 조사	시장 세분화와 상품기획 방향
기술 요인	기술 변화와 인프라 수준이 운영 방식과 경쟁우위를 바꾸는가	기술동향, 특허, IT 인프라 자료	디지털 전환, 제품·서비스 혁신
시장환경	소비자 시장과 조직 시장의 구매 기준은 무엇인가	고객조사, 유통자료, 구매프로세스	고객 세그먼트별 대응전략

Figure 5. 외부환경 분석모형과 영향요인 도출 예시

실무 사례 적용

자료의 산출물 샘플은 공공업무 정보화 사례에서 정책 변화, 사회적 변화, 유사업무 동향, 정보기술 변화가 각각 기회와 위협으로 전환되는 방식을 보여준다.

핵심 요약

일반환경분석은 거시 변화와 시장 변화를 컨설팅 과제의 기회·위협으로 번역한다.
PEST는 분석 범주를 제공하지만 실제 프로젝트에서는 시장과 기술, 정책의 상호작용까지 확장해야 한다.
좋은 산출물은 변화요인, 기회·위협, 시사점, 대응방안을 한 화면에서 연결한다.

CHAPTER 03

Task 2. 경쟁환경분석 — Porters 5-Forces와 경쟁전략

산업구조의 경쟁압력을 분석하여 장기적으로 유리한 경쟁위치를 차지하기 위한 대응방안을 도출한다.

Concept

경쟁환경분석의 목적과 경쟁자 정의

경쟁환경분석은 대외 환경 변화가 기업의 경쟁위치에 어떤 영향을 주는지 파악하는 활동이다. 자료는 누구를 경쟁자로 정의할 것인가, 경쟁자의 전략·목표·강점·약점·대응방식은 무엇인가라는 질문을 중심으로 분석을 출발시킨다.

Figure 6. 경쟁환경분석의 목적과 핵심 질문

Porter의 산업구조 관점

Michael E. Porter는 산업의 수익성을 기존 경쟁자 간 경쟁, 잠재적 신규진입자, 대체재, 공급자의 교섭력, 구매자의 교섭력이라는 다섯 가지 경쟁요인이 결정한다고 보았다.

Practice

5-Forces 적용 절차

원천 자료는 경쟁자의 정의, 경쟁요인 자료조사, 시사점 도출, 경쟁우위 전략 도출의 순서로 경쟁분석을 수행하도록 설명한다. 각 단계는 자료수집과 해석이 분리되지 않도록 설계되어야 한다.

Figure 7. Porter 5-Forces Model과 산업 매력도 결정요인

산업 경계를 정의하고 직접·간접 경쟁자를 구분한다.
고객, 공급자, 대체재, 신규진입자, 기존 경쟁자의 주요 변수를 수집한다.
각 요인이 산업 매력도와 자사 수익성에 미치는 방향을 판단한다.
원가우위, 차별화, 집중화 중 적합한 경쟁우위 논리를 선택한다.
선택한 전략을 실행 과제와 정보요구사항으로 전환한다.

Deep Dive

5-Forces와 3대 본원적 전략의 연결

경쟁요인	원가우위 전략	차별화 전략	집중화 전략
기존 경쟁자	낮은 비용구조로 가격경쟁 압력을 흡수한다.	고객이 인식하는 차별성을 높여 직접 비교를 줄인다.	특정 세그먼트에서 빠른 대응과 높은 적합성을 확보한다.
신규진입자	규모의 경제와 경험곡선으로 진입장벽을 만든다.	브랜드 충성도와 전환비용을 높인다.	틈새시장 지식과 고객관계로 방어한다.
공급자	구매 규모와 표준화를 활용해 원가 상승을 완화한다.	고부가가치 제품은 원가보다 고객가치로 가격을 방어한다.	전문 공급자 의존도가 높아질 수 있어 대체 공급원을 확보한다.
구매자	낮은 가격과 안정적 품질로 구매자의 가격압박에 대응한다.	차별화된 혜택으로 가격 민감도를 낮춘다.	특정 고객군의 문제를 깊게 해결해 관계 기반을 강화한다.
대체재	가격 대비 효용을 높여 대체 전환을 억제한다.	독자적 경험과 성능으로 대체재와 비교 축을 바꾼다.	대체재가 약한 틈새 욕구를 집중 공략한다.

Figure 8. 5-Forces 기반 경쟁분석 산출물 예시

오용 방지

5-Forces는 체크리스트가 아니라 구조적 인과관계를 보는 도구다. 각 경쟁압력이 가격, 비용, 투자, 차별화 가능성에 어떤 영향을 주는지 설명해야 한다.

핵심 요약

경쟁환경분석은 경쟁자의 목록이 아니라 산업구조와 수익성의 압력을 해석하는 활동이다.
5-Forces는 산업 매력도를 판단하고 본원적 경쟁전략을 선택하는 분석 프레임이다.
경쟁분석의 산출물은 기회·위협, 경쟁우위 과제, 전략 대응방안으로 연결되어야 한다.

CHAPTER 04

Task 3. 내부역량분석 — Value Chain, 7S, BSC, BSD, 이해관계자

외부의 기회와 위협에 대응하기 위한 내부 구성요소의 강점과 약점을 분석하고 핵심역량을 도출한다.

Concept

내부역량분석과 핵심역량

내부역량분석은 외부환경 분석에서 도출된 기회와 위협에 대응할 수 있도록 기업의 강점과 약점을 체계적으로 파악하는 활동이다. 자료는 핵심역량을 경쟁기업에 비해 특별히 우월한 자원이나 능력으로 설명하며, 차별화된 기술, 학습능력, 보완적 자산을 예로 든다.

Figure 9. 내부역량분석의 목적과 핵심역량 개념

자원기반관점

자원기반관점은 가치 있고 희소하며 모방하기 어렵고 조직적으로 활용 가능한 자원이 지속적 경쟁우위의 원천이 될 수 있다고 설명한다. 내부역량분석은 이러한 자원을 발견하고 전략과 연결하는 과정이다.

Practice

내부역량 분석 기법의 적용

원천 자료는 Value Chain, 7S, Balanced Scorecard, Business System Diamond, 이해관계자 분석을 내부역량 분석에 활용할 수 있는 대표 기법으로 제시한다.

Figure 10. 내부역량 분석단계와 활용 기법

기법	주요 관점	적합한 질문	주요 출처
Value Chain	가치 창출 활동의 흐름	어떤 활동이 비용우위 또는 차별화의 원천인가	Michael Porter
7S	전략, 구조, 시스템, 공유가치, 스타일, 직원, 역량의 정합성	전략 실행을 방해하는 조직요소의 불일치는 무엇인가	Thomas J. Peters 등
BSC	재무, 고객, 내부프로세스, 학습성장 관점의 균형	비전과 전략이 성과지표로 전개되어 있는가	Kaplan & Norton
BSD	프로세스, 직무·구조, 가치·신념, 관리·평가체계	업무 시스템 전체가 전략과 맞게 설계되어 있는가	Michael Hammer
이해관계자 분석	내부·외부 고객과 관계자 영향	전략 결정이 누구에게 어떤 영향을 미치는가	전략 및 조직진단 실무

Deep Dive

각 기법의 차이와 통합 사용법

Figure 11. Value Chain 중심의 내부역량 분석 도구 예시

Value Chain은 활동 단위의 경쟁우위를 찾는 데 강하고, 7S는 조직 변화의 정합성을 점검하는 데 강하다. BSC는 비전을 성과지표로 번역할 때 유용하며, BSD는 프로세스와 조직구조, 문화와 평가체계의 상호작용을 볼 때 적합하다. 이해관계자 분석은 내부역량이 실제 관계자 만족과 실행 수용성으로 이어지는지를 확인한다.

통합 분석 순서

먼저 Value Chain으로 활동별 강점과 약점을 찾고, 7S와 BSD로 조직적 원인을 진단한다. 이후 BSC로 전략목표와 지표를 연결하고, 이해관계자 분석으로 실행 과정에서 발생할 저항과 협력 조건을 점검하면 분석의 누락을 줄일 수 있다.

상황	우선 기법	보완 기법	산출물 형태
원가·품질·납기 문제	Value Chain	BSC, BSD	활동별 강약점, 개선과제
전략은 있으나 실행이 약함	7S	BSC	조직 정합성 진단, 실행역량 과제
성과지표가 전략과 불일치	BSC	Value Chain	전략맵, KPI 후보
업무 프로세스와 조직구조가 복잡함	BSD	이해관계자 분석	프로세스·조직·문화 개선방향
이해관계 충돌이 큰 프로젝트	이해관계자 분석	7S, BSC	관계자별 영향·요구·소통전략

핵심 요약

내부역량분석은 강점과 약점을 도출하고 외부 기회·위협에 대한 대응력을 판단한다.
Value Chain, 7S, BSC, BSD, 이해관계자 분석은 서로 다른 렌즈이므로 목적에 따라 조합해야 한다.
강점·약점은 반드시 원인 또는 배경, 전략적 시사점, 개선과제로 연결되어야 한다.

CHAPTER 05

Task 4. 비전/전략분석 — SWOT, CSF, 전략 수립 체계

외부환경과 내부역량 분석 결과를 통합하여 전략주제와 핵심성공요소를 도출한다.

Concept

비전/전략분석의 목적

비전/전략분석은 기업이 이미 설정한 비전과 전략을 검토하고, 외부환경 및 내부역량 분석 결과를 중심으로 SWOT 분석을 수행하여 CSF를 도출하는 활동이다. 도출된 CSF는 이후 분석과 실행계획의 방향성과 제약조건으로 작용한다.

Figure 12. 비전/전략분석 접근 방법

전략의 수준

자료는 전략을 전사적 수준, 사업부 수준의 본원적 경쟁전략, 기능적 수준의 전략으로 구분한다. 전사 수준은 포트폴리오와 성장 방향을, 사업부 수준은 경쟁우위 방식을, 기능 수준은 구매·생산·마케팅·재무 등 가치활동의 운영 원칙을 다룬다.

Practice

SWOT에서 CSF로 전환하기

SWOT은 외부의 기회와 위협, 내부의 강점과 약점을 구분하여 전략적 포지셔닝을 설정하는 기법이다. 그러나 SWOT 목록 자체는 전략이 아니다. 강점과 기회, 강점과 위협, 약점과 기회, 약점과 위협의 조합을 통해 대응전략을 만들고, 그 대응전략을 실현하기 위한 핵심성공요소를 도출해야 한다.

Figure 13. SWOT Matrix와 전략방향 도출

SWOT 조합	전략 논리	주요 질문	산출물
SO	기회를 살려 강점을 심화	우리가 잘하는 것으로 어떤 기회를 선점할 수 있는가	공격적 성장 과제
ST	강점으로 위협을 극복	강점을 활용해 어떤 외부 위협을 방어할 수 있는가	방어 및 차별화 과제
WO	기회를 활용해 약점을 보완	외부 기회를 이용해 내부 약점을 개선할 수 있는가	역량 보완 과제
WT	위협에 대한 취약 부문 강화	약점과 위협이 결합될 때 어떤 위험이 발생하는가	리스크 완화 과제

Deep Dive

전략 포트폴리오와 CSF의 연결

자료는 BCG Matrix를 활용한 포트폴리오 전략, 수직적 통합, 장기계약, 다각화, 전략적 제휴, 국제화 전략, Porter의 3대 본원적 경쟁전략을 함께 설명한다. 이러한 전략 대안은 SWOT에서 도출된 대응전략을 구체화하는 선택지로 활용된다.

Figure 14. BCG Matrix와 전사적 포트폴리오 전략

Figure 15. CSF 도출 과정과 전략주제 정의

CSF 작성 원칙

CSF는 중요해 보이는 일의 목록이 아니라 전략주제를 달성하기 위해 반드시 성공해야 하는 조건이다. 표현은 측정 가능하고 실행 가능한 문장으로 작성해야 하며, 정보화 과제라면 CIR, 즉 주요 정보화 요구사항과 연결해야 한다.

전략 대안	적용 상황	장점	주의점
포트폴리오 조정	복수 사업단위의 자원배분이 필요한 경우	성장성과 수익성의 균형 확보	시장성장률과 점유율만으로 판단하면 전략적 시너지를 놓칠 수 있음
수직적 통합	공급 안정성, 품질, 비용통제가 중요한 경우	거래비용 절감과 통제력 강화	수요 불확실성과 기술 변화가 크면 위험부담 증가
전략적 제휴	비용과 위험을 분담하며 신사업 기회를 탐색할 때	빠른 시장 접근과 역량 보완	핵심 노하우 노출과 파트너 의존 위험
원가우위	가격경쟁이 심하고 규모의 경제가 가능한 경우	가격 압박에 대한 방어력	차별화 부족 시 장기 충성도 약화
차별화	고객이 차별적 가치에 프리미엄을 지불하는 경우	가격 민감도 완화와 브랜드 강화	차별화 비용이 고객가치를 초과하지 않도록 관리 필요

핵심 요약

비전/전략분석은 SWOT 결과를 전략주제와 CSF로 전환하는 통합 단계다.
전략은 전사, 사업부, 기능 수준으로 나뉘며 서로 정합성을 가져야 한다.
CSF는 대응전략의 성공 조건이며, 실행과 정보요구사항으로 연결되어야 한다.

CHAPTER 06

과제 및 평가 — 환경분석 체크리스트

학습자가 직접 주제를 선정하고 외부환경, 내부환경, SWOT, CSF를 작성하도록 설계된 실습 장이다.

Concept

실습 과제의 구조

원천 자료의 과제는 세 단계로 구성된다. 첫째, 현재 또는 과거 수행 업무나 고객사의 관심 사업부문과 관련된 주제를 선정한다. 둘째, 일반환경·경쟁환경과 내부역량의 분석요소를 도출한다. 셋째, SWOT Matrix를 구성하고 CSF를 도출한다.

Figure 16. 실습 과제 개요와 진행 방식

Practice

작성 양식과 체크리스트

과제	작성 항목	평가 관점
과제 1. 주제 선정	주제 정의, 수행 필요성, 목표 및 중점 추진사항	범위가 명확하고 분석 가능한가
과제 2. 외부환경 분석요소	6개에서 8개의 외부 영향요인	기회·위협으로 분류 가능한가
과제 2. 내부환경 분석요소	6개에서 8개의 내부 영향요인	강점·약점으로 분류 가능한가
과제 3. SWOT Matrix	12개에서 16개의 영향요인과 대응전략	SO, ST, WO, WT 논리가 타당한가
과제 3. CSF 도출	최종 CSF와 관련 대응전략	전략 성공 조건으로 표현되었는가

Figure 17. 외부환경 분석요소와 영향요인 도출 양식

Figure 18. 내부환경 분석요소와 SWOT 작성 양식

과제 수행 시 주의점

너무 일반적이거나 광범위한 주제는 피해야 한다. 예를 들어 디지털 전환보다 제조사 A/S 서비스의 고객채널 통합처럼 분석 대상, 범위, 의사결정 이슈가 분명한 주제가 적합하다.

Deep Dive

평가 루브릭

평가 영역	우수	보통	미흡
주제 정의	문제, 범위, 목표가 명확하고 분석 가능하다.	주제는 있으나 범위가 다소 넓다.	분석 대상이 모호하다.
Fact Base	자료와 인터뷰 근거가 충분하고 최신성도 확인했다.	일부 근거는 있으나 출처와 최신성이 부족하다.	주관적 판단이 대부분이다.
SWOT 논리	외부와 내부 요인의 연결이 명확하고 대응전략이 구체적이다.	분류는 되어 있으나 대응전략이 추상적이다.	기회·위협·강점·약점 구분이 혼재되어 있다.
CSF 도출	전략 성공 조건이 실행 가능하고 측정 가능하다.	중요 과제는 제시되나 성공 조건 표현이 약하다.	일반 활동 목록에 머문다.

Figure 19. SWOT Matrix를 통한 대응전략 도출 양식

Figure 20. CSF 전략주제 및 주요과제 정리 예시

핵심 요약

실습은 주제 선정, 영향요인 도출, SWOT, CSF의 순서로 진행한다.
평가는 자료 근거, 분석 논리, 전략 전환 능력, 실행 가능성을 중심으로 이루어진다.
좋은 과제 결과물은 최종 CSF가 초기 환경분석 결과와 추적 가능하게 연결된다.

REFERENCES

참고문헌

본 문서는 사용자 제공 PPT의 내용을 기반으로 하며, 이론명과 학자명은 원천 슬라이드에 제시된 분석기법 설명을 보강하기 위해 정리하였다.

이론 출처

Porter, Michael E. Competitive Strategy 및 Competitive Advantage. 5-Forces Model, Value Chain, 본원적 경쟁전략의 이론적 배경.
Kaplan, Robert S. and Norton, David P. Balanced Scorecard. 재무, 고객, 내부 프로세스, 학습 및 성장 관점의 성과관리 체계.
Peters, Thomas J. and Waterman, Robert H. 7S Framework. 전략 실행과 조직요소 정합성 분석의 이론적 배경.
Hammer, Michael and Champy, James. Reengineering the Corporation. Business System Diamond 및 프로세스 혁신 관점의 배경.
원천 자료: A004_경영환경분석_v2.1200(83).pptx 및 파싱 마크다운 파일.

뉴런리포트

프로세스 개선계획 수립

프로세스 개선계획 수립

목차

1. 개요

1.1 프로세스 개선계획 수립 Activity 공정도

1.2 목적과 세부 Task의 역할

핵심 요약

2. 프로세스 개선 이론적 기초

2.1 BPR, 변화관리, 품질개선 프레임워크의 결합

2.2 프로세스 개선 문서에 이론이 필요한 이유

3. Task 1 개요

3.1 목적, 입력물, 산출물

4. 전략 수립 접근방법

4.1 프로세스 개선전략 수립 절차

4.2 프로세스 개선 전략 유형 비교표

5. 산출물 예시와 실무 확장

5.1 개선활동 정의 예시

5.2 관련 법 · 제도 개선과 조직 체계 조정

5.3 데이터 정비, 교육체계, 표준 절차서, 인원 조정

Task 1 핵심 요약

6. Task 2 개요

6.1 목적과 기본 흐름

7. 우선순위 선정과 프로젝트 정의

7.1 개선 우선순위 선정 접근방법

7.2 개선 우선순위 선정 기준표

7.3 프로젝트 정의서 작성 방법

8. KPI 설계와 목표치 설정

8.1 KPI 설계 원칙 표

8.2 목표치 설정과 성과관리 밴드

Task 2 핵심 요약

9. Task 3 개요와 계획 방법

9.1 일정 및 자원계획의 목적

9.2 일정 및 자원계획 접근방법

10. 일정 · 자원계획 사례

10.1 일정계획 사례 해설

Task 3 핵심 요약

11. 실습 과제 및 모범답안

11.1 실습 과제 작성 가이드

11.2 모범답안 해설 (우량고객 관계 강화 프로젝트)

12. 참고문헌

정보관리체계 수립

정보관리체계 수립

목차

개요와 통합 프레임워크

정보관리체계 수립의 목적

개념

실습

심화

정보관리체계 4대 영역 비교표

Task 1. 정보조직 체계 정립

개념과 설계 원리

개념

실습

심화

실습 접근과 사례

심화: 운영 거버넌스와 RACI

Task 1 핵심 요약

Task 2. 보안관리 방안 수립

보안정책과 기준체계

개념

실습

심화

실습: 보안운영 절차 설계

심화: ISO/IEC 27001과 연계한 운영 설계

Task 2 핵심 요약

Task 3. 유지보수 방안 수립

유지보수 원칙과 범위

개념

실습

심화

실습: 장애·재해 대응 설계

심화: ITIL 기반 서비스 운영과 아웃소싱 판단

Task 3 핵심 요약

Task 4. 품질관리 방안 수립

품질보증과 표준화

개념

실습

실습: 품질활동과 검토체계

심화: ISO/IEC 25010과 PMBOK 품질관리 관점