ERP 도입 전 업무정리가 먼저인 이유는 단순합니다. ERP·그룹웨어는 일하는 방식을 대신 정해 주지 않습니다. 업무 지시가 메신저로 오가고 결정이 통화와 회의에 흩어진 상태에서 시스템을 들이면, 시스템은 그 방식을 바꾸는 대신 “결과만 입력하는 업무”를 하나 더 만듭니다. 그래서 제품을 비교하기 전에 손에 들려 있어야 하는 것은 요구사항 목록이 아니라, 지금 회사가 어떻게 돌아가는지를 적은 진단 산출물입니다. 이 글은 실제로 납품한 업무설계 보고서를 바탕으로 그 산출물 7가지를 정리합니다.
이 글에서 다루는 내용
- ERP 도입 전 업무정리가 먼저여야 하는 이유 — 1990년부터 반복된 결론
- 도구를 하나 더 들이면 실제로 생기는 일
- 진단 산출물 7가지 — 무엇을 적고, 제품 선택의 어느 질문에 답하는지
- 7가지 산출물로 ERP·그룹웨어를 고르는 기준 4개
- 진단을 받는 방법과 값
ERP 도입 전 업무정리가 먼저인 이유 — 35년 된 결론
업무를 그대로 둔 채 기술만 올리는 것이 왜 실패하는지는 새로운 발견이 아닙니다. 마이클 해머는 1990년 7–8월호 하버드비즈니스리뷰에 실린 「Reengineering Work: Don’t Automate, Obliterate」에서 제목 그대로 “기존 업무를 자동화하지 말고 없애라”고 썼습니다. 정보기술을 기존 절차를 빠르게 돌리는 데 쓰면 비효율까지 같이 빨라진다는 것이 그 글의 요지입니다.
토머스 대븐포트는 1998년 7–8월호 같은 매체의 「Putting the Enterprise into the Enterprise System」에서 ERP 같은 전사 시스템은 회사의 전략·문화·조직에 자기 논리를 강요한다고 지적하고, 사업에 미치는 영향이 큰 만큼 도입 책임을 기술 담당자에게 넘기지 말라고 썼습니다. 패키지가 정해 둔 흐름대로 회사가 바뀌는 것이고, 그 흐름이 회사에 맞는지는 기술이 아니라 경영이 판단할 문제라는 뜻입니다.
공개한 업무설계 보고서 샘플의 3.6절은 같은 결론을 작업 순서로 적습니다. 모든 업무는 자동화 여부를 따지기 전에 Eliminate(없애기) → Simplify(단순화) → Standardize(표준화) → Integrate(연결) → Automate(자동화) 순서로 검토합니다. 이 순서를 건너뛰고 자동화부터 시작하면 없애도 되는 업무를 빠르게 반복하는 결과가 됩니다. 보고서의 결론(9장)도 같은 말을 합니다. 시스템을 도입한 뒤에도 메신저로 지시하고 따로 보고하며 시스템에는 결과만 입력하면, 시스템은 새로운 입력 업무가 될 뿐입니다.
도구를 하나 더 들이면 실제로 생기는 일
정리되지 않은 업무에 도구를 추가하면 채널이 하나 늘어납니다. Microsoft가 2025년 6월 발표한 Work Trend Index 특별 보고서 「Breaking down the infinite workday」에 따르면 Microsoft 365 사용자는 하루 평균 이메일 117통, Teams 메시지 153건을 받고, 핵심 근무시간 동안 2분에 한 번 — 하루 275회 — 회의·메일·알림으로 끊깁니다. 이 숫자는 도구가 부족해서 나온 것이 아닙니다.
보고서 샘플 3.5절의 진단도 같습니다. 관찰된 법률사무소의 기술환경에서 중요한 문제는 새로운 기술의 부족이 아니라, 업무와 정보가 메신저·이메일·AI 도구·법원 시스템·업무관리 시스템 사이에 분리되어 있고 사람이 그 사이를 연결하고 있다는 점이었습니다. ERP 도입 전 업무정리는 바로 이 “사람이 연결하는 구간”을 찾아 적는 일입니다. 그것이 적혀 있어야 새 시스템이 그 구간을 대신하는지, 아니면 구간을 하나 더 만드는지 비교가 됩니다.
ERP 도입 전 업무정리 산출물 7가지
아래 7가지는 보고서 샘플 2장~4장에 실제로 들어 있는 표입니다. 업종은 법률사무소지만 표의 틀은 업종을 가리지 않습니다. 각 표가 무엇을 적는지와, 그 표가 제품 선택의 어느 질문에 답하는지를 함께 적었습니다.
| # | 산출물 | 무엇을 적나 | 샘플 위치 |
|---|---|---|---|
| 1 | 근거 등급표 | 각 진단 문장이 직접 본 것(Observed)인지, 자료(Documented)·인터뷰(Reported)·해석(Analysis)·미확정(To Verify)인지 | 2.2절 |
| 2 | 가치구조 판단표 | 업무별로 핵심 전문업무(유지)인지, 단순화·표준화·축소 대상인지 | 3.1절 |
| 3 | 업무흐름 진단표 | 관리 단위·업무 요청·검토·공유 방식의 현재 상태와 개선 방향 | 3.2절 |
| 4 | 의사결정 분류표 | 대표에게 오는 요청 6유형 — 정보 의존 3·판단 의존 3 | 3.3절 |
| 5 | 정보구조표 | 고객·사건·업무·상담·이메일·파일·결정·청구 정보가 어디에 연결되어야 하는지 | 3.4절·3.5절 |
| 6 | 낭비·자동화 분류표 | 업무 13개를 Eliminate~Automate로 분류, 연동 불가 판정 포함 | 3.6절 |
| 7 | 핵심 운영문제 우선순위표 | 7개 영역의 현상을 원인 기준으로 묶은 운영문제 5개와 P1/P2 | 4장 |
산출물 1 — 근거 등급표: 어디까지가 직접 본 것인가
진단서의 모든 문장은 같은 무게가 아닙니다. 샘플 2.2절은 각 항목을 Observed(현장에서 직접 확인) · Documented(고객 제공자료) · Reported(대표·직원 설명) · Analysis(관찰과 자료에서 도출한 판단) · To Verify(현재 근거로 확정 불가)로 구분해 표기합니다. 이 표가 있어야 다음 6개 표의 어느 칸이 사실이고 어느 칸이 해석인지 읽는 사람이 가를 수 있습니다. 샘플 2.3절에서는 사건관리·업무 커뮤니케이션·대표 의존·행정업무 등 8개 항목이 Observed, 기록검토·상담 자동화 2개 항목이 Documented로 표기되어 있습니다.
산출물 2 — 가치구조 판단표: 줄이면 안 되는 업무부터 표시
시간이 많이 든다는 이유만으로 그 업무를 비효율로 판단하면 전문업무까지 자동화 대상에 오릅니다. 샘플 3.1절은 7개 업무를 “핵심 전문업무 → 유지”, “필요하지만 접근방식 개선 가능 → 단순화”, “기존 정보의 반복 가공 → 축소”로 나눕니다. 대표의 고객상담과 법률적 판단은 유지, 사건 진행정보 재정리와 대표의 단순 현황 확인은 축소입니다. ERP를 고를 때 이 표가 없으면 “모든 업무를 시스템에 넣는” 요구사항이 되고, 그 요구사항은 그대로 입력 부담이 됩니다.
산출물 3 — 업무흐름 진단표: 일이 어디서 끊기는가
샘플 3.2절은 관찰된 흐름을 “고객·사건 발생 → 개별 업무 → 담당자 수행 → 메신저·미팅으로 확인·공유 → 대표 확인·판단 → 수정 → 다음 업무”로 단순화한 뒤, 6개 진단항목의 현재 상태와 개선 방향을 적습니다. 기본 관리단위는 개별 업무 중심 → 사건 중심, 업무 요청은 외부 메신저 → Task 중심, 진행상황 공유는 별도 커뮤니케이션 → 시스템 조회입니다. 이 표의 “개선 방향” 열이 곧 시스템에 요구할 구조입니다.
산출물 4 — 의사결정 분류표: 대표에게 남길 질문만 남기기
대표에게 몰리는 요청을 Information·Status·Context(정보 의존)와 Approval·Professional Decision·Exception(판단 의존)으로 나눈 표입니다(샘플 3.3절). 앞의 셋은 시스템 조회·업무 화면·업무 기록으로 보내고 뒤의 셋만 사람이 판단합니다. 이 표의 쓰임은 「직원이 대표에게 자꾸 묻는 회사」에 따로 정리했습니다. 그룹웨어의 승인·결재 기능을 켜기 전에 이 표가 없으면 정보 질문까지 결재선에 올라가고, 대표의 승인 대기만 늘어납니다.
산출물 5 — 정보구조표: 정보가 어디에 붙어야 하는가
샘플 3.4절은 고객정보·사건정보·업무·상담·이메일·파일·결정사항·일정·청구·법원 사건정보 10가지가 각각 Customer / Project / Task 중 어디에 연결되어야 하는지 적습니다. 기본 축은 셋입니다. Customer(누구의 일인가) / Project(어떤 사건인가) / Task(지금 무엇을 해야 하는가). 3.5절은 이어서 메신저·이메일·AI 도구·법원 시스템·업무관리 시스템 5개 도구의 현재 용도와 개선 방향을 적습니다. 제품 비교에서 가장 많이 쓰이는 표입니다. 후보 제품이 이 세 축을 그대로 담는지, 아니면 “프로젝트”와 “고객”이 따로 노는지가 여기서 갈립니다.
산출물 6 — 낭비·자동화 분류표: 자동화할 것과 안 되는 것
샘플 3.6절은 고객 전화상담부터 반복 문서작성까지 업무 13개를 Keep / Eliminate / Simplify / Standardize / Integrate / Automate로 분류합니다. 13개 중 Automate가 붙은 것은 “상담 후 후속업무 생성”, “메일·업무내용 재요약”, “반복 문서작성” 셋뿐이고, “대표에게 단순 정보질문”은 Eliminate입니다. 이 표에는 안 되는 것도 적혀 있습니다. 법원 사건정보는 공식 API 연동이 불가능한 것으로 확인되어 맞춤 자동화 대상에서 제외됩니다. 법원 사법정보공유포털은 사건기본정보·사건진행내역을 연계 API로만 제공하고 오픈API는 “추후 제공 예정”으로 안내하고 있습니다. “법원 연동 자동화”를 내세우는 제안서가 있다면 이 표 한 줄로 확인이 끝납니다.
산출물 7 — 핵심 운영문제 우선순위표: 무엇부터인가
7개 진단영역에서 나온 현상을 같은 원인끼리 묶으면 운영문제 몇 개로 줄어듭니다. 샘플 4장에서는 다섯 개입니다. OP-01 사건 중심 운영체계 부족, OP-02 업무·정보·커뮤니케이션 분산, OP-03 대표에 대한 정보의존과 의사결정의존 혼재, OP-04 업무 수행 전 Context의 반복적 재구성, OP-05 상담·외부정보 등 업무 간 Hand-off. 앞의 넷이 P1, 마지막이 P2입니다. 이 표의 P1이 시스템 도입으로 풀리는 문제인지, 업무방식 변경으로 풀리는 문제인지가 다음 장(해결방안 설계 기준, 5.1절)으로 넘어가는 기준이 됩니다.
이 7가지 뒤에 해결방안(5장), 목표 운영체계(6장), 로드맵(7장), 측정(8장)이 이어집니다. 측정 장에는 “30% 절감” 같은 숫자가 없습니다. 정량 데이터가 확보되기 전에는 절감률을 임의로 제시하지 않는다는 것이 보고서의 원칙이고, 그 자리에는 Before 값을 먼저 확보할 KPI 13개가 적혀 있습니다.
7가지 산출물로 ERP·그룹웨어를 고르는 기준 4개
- 정보구조표(산출물 5)의 세 축이 제품에 그대로 있는가. 고객 → 사건(프로젝트) → 업무가 한 줄로 이어지고, 상담·파일·이메일·결정이 사건에 붙는지 봅니다. 기능 수가 아니라 연결 구조가 기준입니다.
- 낭비 분류표(산출물 6)에서 Integrate로 분류된 업무를 그 제품이 담는가. 메신저 업무지시, 메신저 컨펌·수정, 비용청구 업무가 Task와 사건 기록 안에서 처리되는지 확인합니다. Eliminate로 분류된 업무에 기능을 붙이는 제품은 가점이 아닙니다.
- 불가 판정된 외부 연동을 전제로 한 기능은 평가에서 뺀다. 산출물 6에 적힌 “안 되는 것”을 되는 것처럼 설계한 제안은 도입 뒤에 무너집니다.
- 의사결정 분류표(산출물 4)의 확인·승인 기준을 시스템이 담을 수 있는가. 승인 단계마다 기준 문장을 붙이고, 정상 진행은 승인 없이 흘러가는지 봅니다. 모든 단계에 결재를 요구하는 구조는 대표 의존을 시스템으로 옮긴 것입니다.
도입 뒤에는 샘플 8.4절의 30일 점검표를 그대로 씁니다. 진행 사건이 Project로 관리되는가, 업무지시·컨펌이 계속 메신저에서 발생하는가, 시스템에서 확인 가능한 내용을 계속 대표에게 묻는가. 세 항목 중 하나라도 “그렇다”면 제품 문제보다 Phase 1(업무방식 정리, 7.1절)이 건너뛰어졌을 가능성이 먼저입니다.
이 산출물을 받는 방법
위 7가지 표는 업무체계 진단의 산출물인 업무체계 진단서에 들어갑니다. 진단은 값이 정해져 있습니다. 일반은 800,000원(부가세 별도)으로 한 업무 흐름 또는 한 부서를 보며 현장 관찰 3일, 보고서 5일입니다. 고급은 1,200,000원(부가세 별도)으로 두 개 이상의 업무 흐름 또는 회사 전체를 보며 현장 관찰 5일, 보고서 10일이고, 진단서에 Workflow Blueprint 초안과 실행 로드맵이 더해집니다. 관찰 시작 전에는 전액 환불됩니다. 진단서 마지막 장에는 설계·구축의 범위·기간·금액을 적은 서면 견적이 붙지만, 구축을 맡기지 않아도 진단서는 그대로 가져가십니다. 보고서 전문은 샘플 페이지에, 공개한 배경은 이 글에 있습니다.
참고 출처
- Harvard Business Review — Reengineering Work: Don’t Automate, Obliterate (Michael Hammer, 1990)
- Harvard Business Review — Putting the Enterprise into the Enterprise System (Thomas H. Davenport, 1998)
- Microsoft WorkLab — Work Trend Index Special Report: Breaking down the infinite workday (2025)
- 법원 사법정보공유포털 — 연계 API 안내 (오픈API 추후 제공 예정)
포커스 키워드: ERP 도입 전 업무정리
SEO 키워드: ERP 도입, 그룹웨어 도입, 업무정리, 진단 산출물, 업무설계, 업무체계 진단, 업무 프로세스
자주 묻는 질문
ERP나 그룹웨어를 고르기 전에 무엇을 먼저 준비해야 하나요?
요구사항 목록보다 현재 업무가 어떻게 돌아가는지 적은 진단 산출물입니다. 특히 정보구조표(고객·사건·업무가 어디에 연결되는가), 낭비·자동화 분류표, 의사결정 분류표 세 가지가 제품 비교에 바로 쓰입니다.
진단 없이 바로 도입하면 어떤 일이 생기나요?
보고서 결론이 적은 대로, 메신저 지시와 별도 보고가 그대로 남고 시스템에는 결과만 입력하게 되어 시스템이 새로운 입력 업무가 됩니다. 도입 30일 뒤 업무지시·컨펌이 계속 메신저에서 발생하는지로 확인합니다.
진단 비용과 기간은 어떻게 되나요?
일반 800,000원(한 업무 흐름 또는 한 부서, 현장 관찰 3일·보고서 5일), 고급 1,200,000원(두 개 이상의 업무 흐름 또는 회사 전체, 관찰 5일·보고서 10일), 부가세 별도입니다. 관찰 시작 전에는 전액 환불됩니다.