이 문서는 실제로 납품한 업무설계 보고서를 샘플로 다시 구성한 것입니다. 장 구성, 진단 기준, 표, 로드맵, 측정지표는 납품본과 같습니다. 특정 고객을 알아볼 수 있는 내용(사무소명, 담당자, 작성일, 그 사무소만의 사정)은 덜어냈습니다. 업종을 법률사무소로 둔 것은, 업무설계가 그 업종의 일하는 방식 위에서만 성립하기 때문입니다.
업무 프로세스 · 정보구조 · 협업체계 · 시스템 적용 · 자동화 개선안
1. Executive Summary
이번 진단에서 확인된 핵심 문제는 업무량 자체보다 사건을 중심으로 업무와 정보가 충분히 연결되지 않는 운영구조에 있다. 사건 관련 업무는 수행되고 있으나 개별 업무, 상담, 파일, 이메일, 업무지시, 수정요청, 결정사항이 하나의 사건 History로 연결되지 않아 필요한 정보를 다시 찾고, 묻고, 정리하고, 전달하는 업무가 발생한다. 또한 시스템에서 확인할 수 있는 정보와 대표 변호사의 전문적 판단이 필요한 사항이 함께 대표에게 집중되는 현상이 확인되었다.
따라서 이번 업무설계의 우선순위는 개별 업무의 자동화가 아니라 사건 중심 운영체계를 구축하고 업무와 정보를 연결하는 것이다.
1.1 핵심 진단
| 영역 | 핵심 진단 |
|---|---|
| 사건관리 | 사건보다 개별 업무 중심으로 관리되는 부분이 있어 전체 진행과 History 연결이 부족함 |
| 업무공유 | 메신저·미팅과 실제 업무기록이 분리되어 있음 |
| 대표 의존 | 시스템에서 확인할 정보와 전문적 판단이 필요한 사항이 함께 대표에게 집중됨 |
| 정보관리 | 상담·업무·파일·이메일·결정사항이 사건 Context로 충분히 연결되지 않음 |
| 행정업무 | 이미 존재하는 정보를 다시 확인·정리·전달하는 업무가 발생함 |
| 상담 | 상담정보를 사건 및 후속업무와 일관되게 연결할 필요가 있음 |
| 확장성 | 사건과 인력이 증가할수록 정보확인과 커뮤니케이션 부담도 증가할 가능성이 있음 |
1.2 우선 실행과제
| 순서 | 실행과제 | 실행방향 |
|---|---|---|
| 1 | 사건 중심 관리체계 구축 | Customer → Project/Matter → Task |
| 2 | 업무와 정보 연결 | 상담·파일·이메일·결정·청구를 사건에 연결 |
| 3 | 업무 커뮤니케이션 통합 | 업무지시·검토·수정·완료를 Task 안에서 관리 |
| 4 | 대표 정보의존 축소 | 현황·Context는 시스템에서 확인하고 전문적 판단만 대표에게 요청 |
| 5 | 상담과 후속업무 연결 | 상담 → 결정사항·Action Item → Task |
| 6 | 진행보고 최소화 | 정상 진행은 시스템에서 확인하고 미팅은 문제·지연·판단 중심으로 운영 |
| 7 | 반복 업무 표준화 | 반복되는 사건유형과 업무를 Workflow·Template으로 구성 |
| 8 | 필요한 업무만 자동화 | 운영 후 반복빈도·소요시간을 측정하여 ROI가 높은 업무만 개발 |
1.3 해결방식
- 업무방식 개선 — 없애도 되는 업무를 제거하고 불필요한 보고, 확인, 재정리, 승인 과정을 줄인다.
- 시스템 적용 — 고객, 사건, 업무, 상담, 파일, 이메일, 결정사항, 청구를 연결하여 사람이 기억하고 전달해야 하는 업무를 줄인다. 새로 개발할 것이 아니라 이미 개발이 완료된 기능을 실제 운영에 적용한다.
- 맞춤 자동화 개발 — 앞의 두 단계 이후에도 반복적으로 남는 업무를 측정하여 개발 필요성과 ROI가 확인되는 경우에만 별도 개발한다.
1.4 목표 운영구조
Customer → Project / Matter → Task
사건 Project를 중심으로 상담 · 업무 · 파일 · 이메일 · 일정 · 결정사항 · 검토/수정 · 고객 커뮤니케이션 · 청구 · 사건 History를 연결한다. 사람이 사건을 기억하고 서로 설명해야 업무가 이어지는 구조에서, 사건에 업무와 정보가 축적되고 필요한 사람에게 필요한 Context가 제공되는 구조로 전환하는 것을 목표로 한다. 변호사는 법률적 판단, 사건전략, 고객상담 등 전문업무에 집중하고 구성원은 자신이 수행해야 할 업무와 필요한 정보를 명확하게 확인할 수 있도록 운영체계를 재설계한다.
2. Observation Overview
2.1 진단 범위
대표 변호사와 구성원의 실제 업무 수행 과정, 업무 커뮤니케이션 방식, 사건 관련 정보처리, 고객상담, 업무확인 및 행정업무를 관찰하였다. 사전 제공 자료는 현장관찰을 보완하는 자료로 사용하였으며, 자료에 기재된 내용은 현장에서 직접 관찰한 사실과 구분하여 판단하였다.
2.2 진단 근거의 구분
이 보고서는 모든 문장을 같은 무게로 쓰지 않는다. 어디까지가 직접 본 것이고 어디부터가 우리 해석인지를 항목마다 구분해 표기한다.
| 구분 | 의미 | 보고서 반영 기준 |
|---|---|---|
| Observed | 현장에서 직접 확인한 내용 | 관찰 사실 |
| Documented | 고객 제공자료에서 확인한 내용 | 자료에 근거한 사실 |
| Reported | 대표 또는 직원이 설명한 내용 | 인터뷰 내용 |
| Analysis | 관찰 및 자료를 바탕으로 도출한 판단 | 진단 의견 |
| To Verify | 현재 근거만으로 확정할 수 없는 내용 | 추가 확인 대상 |
2.3 확인된 업무환경
| 영역 | 확인 내용 | 근거 |
|---|---|---|
| 사건관리 | 사건 진행 과정의 업무가 개별 업무 단위로 처리되는 부분이 있음 | Observed |
| 업무 커뮤니케이션 | 메신저와 미팅을 통한 업무공유·컨펌·수정요청이 존재 | Observed |
| 업무공유 | 구성원이 서로의 업무 진행상황을 별도로 확인해야 하는 경우가 있음 | Observed |
| 대표 의존 | 직원이 대표에게 직접 물어봐야 알 수 있는 업무정보가 존재 | Observed |
| 고객상담 | 대표 변호사의 전화상담과 통화 전후 사건내용 확인 업무가 존재 | Observed |
| 업무리뷰 | 메일과 업무 관련 내용을 AI 도구로 정리하여 확인하는 방식이 관찰됨 | Observed |
| 상담기록 | 상담에서 발생한 정보가 고객·사건·후속업무와 일관되게 연결될 필요가 있음 | Observed |
| 행정업무 | 법원정보 등을 확인하고 다시 정리하여 공유하는 업무가 존재 | Observed |
| 기록검토·서면작성 | 고객도 주요 시간소비 영역으로 인식 | Documented |
| 상담 자동화 | 고객도 상담 후 정보정리와 후속업무 자동화를 개선과제로 인식 | Documented |
사전 제공 자료에서는 병목을 서면작성, 기록검토, 의뢰인 응대 및 수임영업, 사무관리로 구분하고 있었다. 본 보고서에서는 이를 그대로 자동화 대상으로 채택하지 않고, 현장관찰과 결합하여 업무방식의 문제인지, 운영구조의 문제인지, 시스템 또는 자동화가 필요한 문제인지 다시 판단하였다.
3. Current Operating System Diagnosis
3.1 Business Value — 가치 구조
법률사무소의 핵심 고객가치는 전문적인 법률판단, 사건 대응, 법률문서 작성 및 고객상담에서 발생한다. 따라서 시간이 많이 소요된다는 이유만으로 이러한 업무를 비효율로 판단해서는 안 된다. 반면 전문업무를 수행하기 위해 주변에서 발생하는 검색·확인·재정리·재전달 업무는 고객가치와 직접 연결되지 않으면서 전문가의 시간을 소비할 가능성이 있다.
| 업무 | 판단 | 개선방향 |
|---|---|---|
| 대표 변호사의 고객상담 | 핵심 전문업무 | 유지 |
| 법률적 판단·사건전략 | 핵심 전문업무 | 유지 |
| 상담 전 사건내용 파악 | 필요하지만 접근방식 개선 가능 | 단순화 |
| 상담 후 내용 정리 | 기록·공유·후속업무를 위해 필요 | 표준화·시스템화 |
| 사건 진행정보 재정리 | 기존 정보의 반복 가공 | 축소 |
| 직원 간 진행상황 확인 | 정보 부족을 보완하기 위해 발생 | 축소 |
| 대표의 단순 현황 확인 | 전문판단이 아닌 Context 확보 목적 | 축소 |
핵심 개선방향은 변호사의 전문업무를 줄이는 것이 아니라 전문업무 전후에 발생하는 비부가가치 업무를 줄이는 것이다.
추가 확인 — 사건유형별 매출과 수익성, 평균 투입시간, 업무유형별 담당자와 소요시간은 현재 자료만으로 확정할 수 없다. 향후 실제 운영데이터를 확보하여 추가 분석한다.
3.2 Workflow — 업무 흐름
현재 관찰된 업무 흐름을 단순화하면 다음과 같다. 고객 또는 사건 발생 → 개별 업무 발생 → 담당자 업무 수행 → 메신저·미팅 등을 통한 확인 또는 공유 → 대표 변호사 확인·판단 → 수정 또는 추가업무 → 다음 개별 업무.
| 진단항목 | 현재 상태 | 개선방향 |
|---|---|---|
| 기본 관리단위 | 개별 업무 중심인 부분 존재 | 사건 중심 |
| 사건 전체 Workflow | 업무 간 연결 부족 | Project 구조 |
| 업무 요청 | 외부 메신저 사용 | Task 중심 |
| 검토·수정 | 대화·미팅과 업무기록 분리 | Task History |
| 진행상황 공유 | 별도 커뮤니케이션 필요 | 시스템 조회 |
| 상담 후 후속업무 | 상담정보를 다시 업무로 전환 | 상담 → Task |
핵심은 사건이 업무 전체를 담는 상위 관리단위로 기능하도록 만드는 것이다. 개선 후에는 모든 업무가 어떤 사건에서 발생했으며 이전 업무와 어떤 관계가 있고 이후 무엇으로 이어지는지를 연결한다.
3.3 People & Decision — 조직과 의사결정
대표에게 업무가 집중되는 현상은 두 가지로 구분해야 한다. Information Dependency는 필요한 정보를 얻기 위해 대표에게 질문해야 하는 경우이고, Decision Dependency는 대표의 전문적 판단이나 승인권한이 실제로 필요한 경우다. 현재는 이 두 종류의 요청이 충분히 분리되지 않고 함께 전달되는 부분이 확인된다.
| 유형 | 내용 | 목표 처리방식 |
|---|---|---|
| Information | 사건정보 확인 | 시스템 조회 |
| Status | 진행상태 확인 | Project/Task |
| Context | 이전 상담·결정내용 확인 | Project History |
| Approval | 결과물 또는 다음 단계 승인 | 확인·승인 기준 |
| Professional Decision | 법률적 판단·사건전략 | 변호사 판단 |
| Exception | 일반 기준으로 처리할 수 없는 상황 | 책임자 판단 |
목표는 대표에게 들어오는 모든 질문을 줄이는 것이 아니라 대표의 전문적 판단이 필요하지 않은 질문이 대표에게 도달하지 않도록 하는 것이다.
3.4 Information — 정보 구조
사건 관련 정보는 고객상담, 메신저, 이메일, 개별 업무, 파일, 법원정보, 미팅 등 다양한 접점에서 발생한다. 여러 채널을 사용하는 것 자체가 문제는 아니다. 핵심은 각 채널에서 생성된 중요한 정보가 최종적으로 사건 Context로 연결되는가이다.
| 정보 | 목표 연결구조 |
|---|---|
| 고객정보 | Customer |
| 사건정보 | Project |
| 업무정보 | Project → Task |
| 상담정보 | Customer + Project |
| 이메일 | Project / Task |
| 파일 | Project / Task |
| 결정사항 | Project / Task History |
| 일정 | Project / Task |
| 청구정보 | Customer + Project |
| 법원 사건정보 | Project History / 일정 / Task |
정보구조의 기본축은 세 단계로 단순화한다. Customer — 누구의 일인가 / Project — 어떤 사건인가 / Task — 지금 무엇을 해야 하는가. 같은 정보는 가능한 한 한 번만 기록하고, 중요한 결정은 대화가 끝난 뒤 사라지지 않도록 사건 또는 업무 History에 남긴다. 사람의 기억이 업무정보를 보관하는 시스템의 역할을 하지 않도록 하는 것이 핵심이다.
3.5 Technology — 시스템 및 기술
현재 기술환경에서 중요한 문제는 새로운 기술의 부족이 아니라 업무와 정보가 여러 도구 사이에서 분리되고 사람이 그 사이를 연결하고 있다는 점이다.
| 도구·시스템 | 현재 사용 | 개선방향 |
|---|---|---|
| 메신저 | 업무지시·공유·컨펌 | 실제 업무와 커뮤니케이션 연결 |
| 이메일 | 외부 및 업무 커뮤니케이션 | 사건·업무와 연결 |
| AI 도구 | 메일 및 업무내용 Review | 구조화된 업무정보를 기반으로 필요한 정보만 제공 |
| 법원 시스템 | 사건 관련 원천정보 | 필요한 내용을 내부 사건기록과 연결 |
| 업무관리 시스템 | 통합 업무관리 기반 | 사건 중심 운영체계 적용 |
3.6 Waste & Automation — 낭비 및 자동화
자동화 여부를 판단하기 전에 모든 업무를 다음 순서로 검토한다. Eliminate → Simplify → Standardize → Integrate → Automate. 이 순서를 건너뛰고 자동화부터 시작하면, 없애도 되는 업무를 빠르게 반복하는 결과가 된다.
| 업무 | 분류 | 개선방향 |
|---|---|---|
| 고객 전화상담 | Keep | 유지 |
| 통화 전 사건내용 확인 | Simplify / Integrate | 필요한 Context 제공 |
| 통화 후 상담내용 정리 | Standardize / Integrate | 상담 기능 활용 |
| 상담 후 후속업무 생성 | Integrate / Automate | Action Item → Task |
| 사건 진행상황 확인 | Simplify / Integrate | Project 중심 확인 |
| 대표에게 단순 정보질문 | Eliminate / Integrate | 시스템 조회 |
| 메신저 업무지시 | Integrate | Task 중심 |
| 메신저 컨펌·수정 | Standardize / Integrate | Task History |
| 진행상황 공유 미팅 | Simplify | 문제·예외·판단 중심 |
| 메일·업무내용 재요약 | Simplify / Automate | Daily Review |
| 법원정보 재정리 | Simplify / Standardize | 필요한 정보만 Project에 연결 |
| 비용청구 관련 업무 | Standardize / Integrate | Customer·Project·청구 연결 |
| 반복 문서작성 | Standardize / Automate | Context 기반 초안·Template |
법원 사건정보 — 공식 API를 통한 외부 연동이 불가능한 것으로 확인되었다. 따라서 현재 단계에서는 맞춤 자동화 개발대상에서 제외하고, 업무에 필요한 사건정보를 Project에 입력 또는 업로드하여 History·일정·Task와 연결하는 방식으로 운영한다. 되는 것처럼 설계했다가 나중에 무너지는 것보다, 안 되는 것을 안 된다고 적고 그 전제 위에서 설계하는 편이 낫다.
3.7 Scalability — 확장성
현재 구조에서 사건과 직원이 증가하면 전문적인 법률업무만 증가하는 것이 아니라 정보확인, 상황설명, 진행상황 공유, 컨펌 요청 등 운영 커뮤니케이션도 함께 증가할 가능성이 있다.
| 대표가 담당해야 하는 영역 | 운영체계가 담당해야 하는 영역 |
|---|---|
| 법률적 판단 | 현재 업무상태 |
| 사건전략 | 담당자 |
| 중요 고객 커뮤니케이션 | 일정 |
| 중요 승인 | 기존 상담내용 |
| 예외상황 판단 | 업무 History |
| 전문적인 검토 | 파일 및 이전 결정사항 |
| 완료 여부 및 후속업무 |
대표의 업무를 다른 사람에게 단순 위임하는 것이 아니라, 대표가 직접 기억하거나 설명할 필요가 없는 운영정보를 시스템이 담당하도록 하는 것이 핵심이다.
4. Key Operating Problems
7개 진단영역에서 발견된 현상을 동일한 원인을 기준으로 통합하면 다섯 가지 핵심 운영문제로 정리된다.
| ID | 핵심 운영문제 | 관련 영역 | 우선순위 |
|---|---|---|---|
| OP-01 | 사건 중심 운영체계 부족 | Workflow / Information / Technology | P1 |
| OP-02 | 업무·정보·커뮤니케이션 분산 | Workflow / Information / Technology | P1 |
| OP-03 | 대표에 대한 정보의존과 의사결정의존 혼재 | People & Decision / Scalability | P1 |
| OP-04 | 업무 수행 전 Context의 반복적 재구성 | Business Value / Information / Waste | P1 |
| OP-05 | 상담·외부정보 등 업무 간 Hand-off | Workflow / Information / Waste | P2 |
이 문제들의 상위 원인은 사건 중심 운영구조 부족과 업무·정보의 연결 부족 두 가지다. 그 결과 사건 Context 분산 → 필요한 정보를 사람이 다시 탐색 → 다른 구성원 또는 대표에게 확인 → 추가 커뮤니케이션 → 결정과 수정내용이 실제 업무와 분리 → 다음 업무에서 다시 Context 확인의 흐름이 반복된다. 따라서 개별 증상을 각각 자동화하는 것보다 상위 운영구조를 먼저 변경하는 것이 우선이다.
5. Solution Design
5.1 해결방안 설계 기준
| 단계 | 해결방식 | 판단 기준 |
|---|---|---|
| 1 | 업무방식 개선 | 제거하거나 단순화하여 해결할 수 있는가 |
| 2 | 시스템 적용 | 필요한 업무와 정보를 하나의 운영체계로 연결할 수 있는가 |
| 3 | 맞춤 자동화 개발 | 앞의 두 단계 이후에도 사람이 반복해야 하는가 |
5.2 사건 중심 운영체계 구축
사건성 업무는 독립된 업무로 관리하기 전에 어떤 고객의 어떤 사건에서 발생한 업무인지를 먼저 정의한다. 기본 구조는 Customer → Project(Matter) → Task이며, Project에는 상담·업무·파일·이메일·일정·결정사항·검토 History·청구를 연결해 Project가 사건의 현재 상태와 전체 History를 확인하는 기준점이 되도록 한다.
5.3 업무와 커뮤니케이션 연결
업무지시, 검토, 수정, 완료와 관련된 중요한 커뮤니케이션은 해당 Task를 기준으로 처리한다. 메신저를 일상적인 소통수단으로 쓰는 것 자체를 제한할 필요는 없지만, 업무의 결과나 중요한 결정이 메신저에만 남아서는 안 된다. 요청 → 수행 → 검토 → 수정 → 완료를 하나의 Task History로 연결한다.
5.4 대표 정보·의사결정 의존 개선
대표에게 들어오는 요청을 Information / Status / Context / Approval / Professional Decision / Exception으로 구분한다. 앞의 셋은 Project와 Task에서 확인하고, 대표가 직접 행동하거나 판단해야 하는 항목만 확인필요로 구분한다. 대표의 의사결정 권한을 무리하게 분산시키지 않으면서 단순 정보확인을 위해 대표를 찾는 업무를 줄이는 것이 목적이다.
5.5 업무 Context 재구성 최소화
구성원이 모든 사건의 전체 상황을 계속 기억하도록 요구하지 않는다. 업무를 시작할 때 필요한 것은 지금 수행할 업무에 필요한 정보, 최근 발생한 중요한 변화, 직접 판단하거나 행동해야 하는 사항 세 가지다. Project Context·확인필요·Daily Review를 활용하여 필요한 시점에 필요한 정보를 확인하도록 한다.
5.6 상담정보와 후속업무 연결
상담은 별도의 기록업무로 끝나는 것이 아니라 사건 Workflow의 일부가 되어야 한다. 상담 → 상담내용 정리 → Customer 연결 → Project 연결 → 주요 사실 및 결정사항 기록 → Action Item 정리 → Task 생성·연결 흐름으로 적용한다. 상담내용을 기록하는 것 자체보다 상담 결과가 다음 업무로 끊김 없이 이어지는 것을 운영 목표로 한다.
5.7 외부 사건정보 처리
법원 사건정보 자동연동을 전제로 업무를 설계하지 않는다. 법원 시스템에서 확인한 정보 중 내부 업무에 필요한 내용만 선별하여 해당 Project에 기록하고, 필요한 경우 일정 또는 Task와 연결한다. 외부정보 전체를 다시 작성하는 것이 아니라 내부 업무 수행에 필요한 정보와 후속조치만 구조화한다.
5.8 진행상황 공유 방식 개선
정상적으로 진행되는 업무는 시스템에서 확인하고, 사람 간 커뮤니케이션은 문제 / 지연 / 위험 / 예외 / 판단 / 의사결정에 집중한다.
6. To-Be Operating System
6.1 목표 운영체계
| 정보영역 | 연결 대상 |
|---|---|
| 고객정보 | Customer + 상담 |
| 사건정보 | Project |
| 상담기록 | Customer + Project |
| 개별 업무 | Project + Task |
| 업무 커뮤니케이션 | Task |
| 이메일 · 파일 · 일정 | Project / Task |
| 결정사항 | Project / Task |
| 검토·수정 History | Task |
| 청구 | Customer + Project |
| 법원 관련 정보 · 진행 History | Project |
6.2 직원의 업무방식
직원은 회사 전체의 모든 사건상황을 지속적으로 파악할 필요가 없다. 내가 지금 해야 할 업무, 업무 수행에 필요한 사건 Context, 마감 및 우선순위, 이전 결정사항, 검토·확인이 필요한 사항에 집중한다. 업무가 완료되면 결과와 기록이 Task와 Project에 남고 다음 업무가 같은 Context 위에서 이어진다.
6.3 대표 변호사의 업무방식
대표에게 제공하는 정보를 세 가지로 구분한다. Action Required(직접 행동해야 하는 업무), Decision Required(전문적 판단이나 승인이 필요한 업무), Attention Required(지연·위험·중요 고객이슈 등 알아야 하는 변화). 정상적으로 진행되고 대표의 판단이 필요하지 않은 업무까지 같은 중요도로 제공하지 않는다.
6.4 상담 운영방식
고객 상담 → 상담내용 정리 → 주요 사실·결정사항 기록 → 고객 요청사항 확인 → Action Item 정리 → 담당자·기한 지정 → Task 생성 → Customer·Project 연결 흐름으로 처리하여 상담정보와 후속업무가 분리되지 않도록 한다.
6.5 검토와 의사결정
| 유형 | 처리방법 |
|---|---|
| 단순 업무완료 | 담당자 완료처리 |
| 정해진 기준 충족 여부 | 체크리스트·기준에 따라 처리 |
| 결과물 검토 | 지정 검토자 확인 |
| 중요 고객 발송 | 필요 시 승인 |
| 법률적 판단 | 변호사 확인 |
| 사건전략 변경 | 책임 변호사 결정 |
| 예외상황 | 책임자 판단 |
전문적인 판단과 단순 업무확인을 분리함으로써 필요한 통제는 유지하면서 불필요한 승인 대기를 줄인다.
6.6 미팅 운영방식
시스템에 기록된 진행상황을 다시 읽어주는 미팅은 최소화한다. 미팅에서는 문제가 발생한 사건, 지연되고 있는 업무, 예외적인 상황, 중요 고객 이슈, 법률적·운영상 판단, 업무방식 개선이 필요한 문제를 우선한다. 회의에서 결정된 내용은 관련 Project 또는 Task에 기록한다.
7. Implementation Roadmap
7.1 Phase 1 — 업무방식 정리
시스템 설정 이전에 새로운 업무처리 원칙을 확정한다.
| 작업 | 내용 |
|---|---|
| 사건 관리기준 | 사건을 Project 단위로 관리 |
| 업무 생성기준 | 사건 관련 업무는 해당 Project에 연결 |
| 커뮤니케이션 기준 | 업무지시·수정·검토는 Task 중심 |
| 상담기록 기준 | 상담정보와 후속업무를 구조화 |
| 컨펌 기준 | 정보확인·승인·전문판단 구분 |
| 미팅 기준 | 진행보고보다 문제·판단 중심 |
| 정보관리 기준 | 사건정보의 기준 위치와 기록원칙 확정 |
7.2 Phase 2 — 운영체계 구축
| 작업 | 적용내용 |
|---|---|
| Customer | 기존 고객정보 정리 |
| Project | 진행 중 사건 생성 및 연결 |
| Task | 현재 업무를 해당 Project에 연결 |
| 파일 · 이메일 | 사건·업무 기준 연결 |
| 상담 | 상담정보·결정사항·후속업무 연결 |
| 청구 | Customer·Project 연결 |
| 확인필요 | 대표의 실제 확인사항 중심으로 운영 |
| Daily Review | 주요 변화·업무·확인사항 Review |
| 권한 | 역할별 접근 및 처리권한 설정 |
| Template | 반복 사건유형 확인 후 단계적으로 구축 |
Phase 2의 목표는 주요 사건의 현재 상태와 관련 업무·정보를 시스템에서 확인하고, 업무지시와 진행관리를 위해 메신저나 사람의 기억에 의존하지 않아도 되는 상태를 만드는 것이다.
7.3 Phase 3 — 실제 운영 및 안정화
구축된 구조가 실제 업무에서 작동하는지 확인한다. 주요 확인항목은 다음과 같다.
- 시스템 밖에서 계속 처리되는 업무
- 메신저로 다시 돌아가는 업무
- 직원이 대표에게 계속 질문하는 정보
- Project에서 찾기 어려운 정보
- 불필요한 입력과 과도한 업무단계
- 실제로 사용되지 않는 기능
- 누락되는 상담정보
- 불필요한 승인
- 새롭게 발견되는 반복업무
발견된 문제를 단순히 사용자의 적응 문제로 판단하지 않고 업무설계와 시스템설계 양쪽에서 원인을 확인하여 수정한다.
7.4 Phase 4 — 추가 자동화 검토
운영체계가 안정화된 이후에도 사람이 반복적으로 처리하는 업무가 남는 경우 다음 기준으로 자동화 필요성을 평가한다.
| 평가항목 | 확인내용 |
|---|---|
| 발생빈도 | 월 몇 회 발생하는가 |
| 총 소요시간 | 월간 총 몇 시간이 사용되는가 |
| 인건비 영향 | 실제 얼마의 인적비용이 사용되는가 |
| 규칙성 | 자동처리 규칙을 정의할 수 있는가 |
| 오류위험 | 자동화 오류 발생 시 영향은 무엇인가 |
| 기술 가능성 | 필요한 데이터 및 시스템 접근이 가능한가 |
| 개발비용 | 구축·유지비용은 얼마인가 |
| 회수기간 | 개발비를 절감효과로 회수할 수 있는가 |
8. Measurement & Follow-up
8.1 측정 원칙
업무설계의 효과를 “편해졌다”는 평가만으로 판단하지 않는다. 도입 전후의 업무시간, 정보확인, 커뮤니케이션, 업무누락 및 처리속도를 가능한 범위에서 측정한다. 현재 정확한 Before 데이터가 없는 항목은 초기 운영기간 동안 기준값을 먼저 확보한다.
8.2 핵심 KPI
| KPI | 측정방법 | 목표 |
|---|---|---|
| 사건 Context 파악시간 | 상담·업무 시작 전 정보확인 시간 | 감소 |
| 대표에게 묻는 단순 정보질문 | Information/Status 질문 횟수 | 감소 |
| 메신저 업무지시 | 업무 관련 지시 횟수 | 감소 |
| 진행상황 확인 커뮤니케이션 | 별도 질문·보고 횟수 | 감소 |
| 상담 후 정리시간 | 상담 종료 → 기록완료 | 감소 |
| 상담 후 Task 연결시간 | 상담 종료 → 후속업무 생성 | 감소 |
| 정보 재입력 | 동일정보 반복입력 횟수 | 감소 |
| 승인 대기시간 | 검토요청 → 결정 | 감소 |
| 업무 누락 | 마감·후속업무 누락 건수 | 감소 |
| 업무 지연 | 마감 초과 업무 비율 | 감소 |
| 업무 History 기록률 | 사건 관련 주요 활동 기록 | 증가 |
| 시스템 외 업무처리 | 외부 채널에서만 처리되는 업무 비율 | 감소 |
| 대표 전문업무 비중 | 대표 총 업무시간 중 전문업무 비율 | 증가 |
8.3 추가 확보 데이터
| 데이터 | 활용 |
|---|---|
| 직원별 주요 업무시간 | 업무별 인건비 계산 |
| 사건유형별 평균 처리시간 | Workflow 개선효과 |
| 사건유형별 매출 | 수익성 분석 |
| 반복 행정업무 빈도 | 자동화 ROI |
| 대표의 정보확인 시간 | 대표 시간가치 개선 |
| 상담 횟수와 정리시간 | 상담 기능 적용효과 |
| 월간 업무량 | 개선 전후 처리량 비교 |
정량 데이터가 확보되기 전에는 구체적인 시간·비용 절감률을 임의로 제시하지 않는다. 이 보고서에 “30% 절감” 같은 숫자가 없는 이유다. 재지 않은 것을 적으면 그 숫자로 평가받게 되고, 그때부터는 개선이 아니라 숫자 맞추기가 된다.
8.4 30-Day Review
초기에는 기능 사용률보다 새로운 업무방식이 실제로 적용되고 있는지를 확인한다.
| 점검항목 | 확인내용 |
|---|---|
| 사건 Project화 | 진행 사건이 Project로 관리되는가 |
| Task 연결 | 개별 업무가 사건에 연결되는가 |
| 메신저 의존 | 업무지시·컨펌이 계속 외부에서 발생하는가 |
| 정보검색 | 필요한 정보를 Project에서 찾을 수 있는가 |
| 대표 질문 | 시스템에서 확인 가능한 내용을 계속 대표에게 묻는가 |
| 상담운영 | 상담정보와 후속 Task가 연결되는가 |
| Daily Review | 실제 필요한 정보가 제공되고 있는가 |
| 업무누락 | 후속업무가 빠지는 경우가 있는가 |
| 사용자 불편 | 불필요한 입력이나 단계가 있는가 |
8.5 90-Day Review
90일 시점에는 실제 운영데이터로 운영효과(Context 파악시간, 대표 정보질문, 메신저 업무처리, 상담 후 정리시간, 업무누락·지연, 진행보고 업무의 변화), 운영구조(사건유형별 Workflow 표준화 가능 영역, 불필요한 승인, 역할 재조정, 추가 SOP, 사용하지 않는 업무단계), 추가 개선(반복 수작업의 빈도·소요시간·비용 기준 자동화 ROI)을 평가한다.
8.6 지속 개선 기준
업무설계는 한 번 구축하고 끝나는 작업이 아니다. 실제 업무를 운영하면서 새로운 병목을 확인하고 Observe → Measure → Eliminate → Simplify → Standardize → Integrate → Automate → Measure Again 순서로 반복한다. 최종 목표는 자동화의 수를 늘리는 것이 아니라 필요한 업무만 남기고, 필요한 정보가 연결되어 있으며, 사람은 자신이 판단하고 실행해야 하는 일에 집중할 수 있는 운영체계를 만드는 것이다.
9. Conclusion — 최종 진단 및 권고
이번 진단에서 확인된 핵심은 업무량 자체보다 업무가 연결되는 방식에 개선 여지가 크다는 점이다. 법률사무소의 업무는 고객상담, 사건검토, 서면작성, 법률적 판단, 제출, 일정관리, 고객안내, 비용청구 등 여러 활동이 하나의 사건을 중심으로 이어진다. 그러나 관찰된 업무환경에서는 그 과정에서 생성된 정보와 결정이 하나의 사건 History로 충분히 축적되지 못하고, 이후 필요한 사람이 다시 정보를 찾고, 묻고, 정리하고, 전달해야 하는 업무가 발생한다.
따라서 발견된 여러 문제는 상당 부분 하나의 구조적 문제로 정리된다. 사건을 중심으로 업무와 정보가 충분히 연결되어 있지 않기 때문에 사람이 그 연결을 반복적으로 대신하고 있다.
이번 업무설계의 목적은 더 많은 기능을 추가하거나 모든 반복업무를 자동화하는 것이 아니다. 먼저 사건을 Project/Matter로 정의하고 그 안에 고객, 업무, 상담, 파일, 이메일, 일정, 결정사항, 검토·수정, 고객 커뮤니케이션, 청구 및 History를 연결해야 한다. 구성원은 모든 사건을 기억하는 대신 자신이 지금 해야 할 업무와 그 업무에 필요한 Context를 확인할 수 있어야 한다.
시스템을 도입한 뒤에도 기존 방식대로 메신저로 업무를 지시하고 별도로 진행상황을 보고하며 시스템에는 결과만 입력한다면, 시스템은 새로운 입력업무가 될 뿐이다. 중요한 것은 도구를 하나 더 쓰는 것이 아니라 기존 업무처리 방식 자체를 사건 중심 운영체계로 전환하는 것이다. 맞춤 자동화는 이 구조가 실제로 운영된 이후에도 남아 있는 반복업무를 측정하여 필요성과 ROI가 확인되는 경우에만 진행한다.
이번 업무설계의 방향을 한 문장으로 정리하면 다음과 같다. 변호사의 일을 줄이는 것이 아니라, 변호사가 변호사의 일에 집중할 수 있도록 주변의 운영업무를 재설계한다.
최종적으로 지향하는 것은 모든 업무가 자동화된 조직이 아니다. 업무는 사건을 중심으로 연결되고, 정보는 필요한 순간에 확인할 수 있으며, 반복적인 운영업무는 시스템이 지원하고, 구성원은 자신이 수행해야 하는 업무에 집중하며, 변호사는 전문적인 판단과 고객가치 창출에 더 많은 시간을 사용할 수 있는 운영체계 — 이것을 본 업무설계 프로젝트의 최종 목표로 권고한다.