IT 컨설팅블로그 글
기존 업무 프로세스 개선 과제 찾기
반복 작업, 병목, 오류 원인을 발견하고 개선 과제를 도출하는 방법을 안내합니다.
업무 프로세스 개선 과제는 불편한 점을 모은 목록에서 한 단계 더 나아가야 합니다. 어떤 업무의 어느 지점에서 문제가 생기고, 무엇을 바꿔 어떤 결과를 확인할지 설명할 수 있어야 실제 실행 과제로 검토할 수 있습니다.
반복 입력이 많다는 의견만으로 새 시스템 도입을 정하면 다른 원인을 놓칠 수 있습니다. 자료의 기준이 다르거나 승인 책임이 불분명한 상황일 수도 있습니다. 이 글은 관찰한 문제를 원인 가설과 개선 후보로 연결하는 실무 절차를 정리합니다.
1. 불편 의견을 실제 업무 장면으로 바꿉니다
먼저 업무의 시작부터 종료까지 흐름을 적고, 어느 단계에서 대기·재입력·오류·재작업이 발생하는지 표시합니다. 누가 어떤 자료를 받아 무엇을 처리하다가 막혔는지 실제 사례와 함께 확인하세요.
‘항상 늦다’는 표현을 그대로 전체 사실로 확정하지 않습니다. 확인한 사례의 범위와 발생 조건을 기록하고 다른 사례에서도 반복되는지 확인할 항목을 남깁니다. 흐름을 처음 정리한다면 업무 현황 분석의 핵심 항목을 함께 참고하세요.
| 발견할 신호 | 먼저 확인할 질문 | 근거 자료 예시 |
|---|---|---|
| 반복 입력 | 어떤 정보를 왜 다른 곳에 다시 입력하는가? | 입력 화면·양식·전달 자료 |
| 전달 대기 | 무엇이 준비돼야 다음 단계가 시작되는가? | 요청·응답·승인 기록 |
| 오류와 반려 | 어떤 조건에서 어떤 보완이 발생하는가? | 오류 유형·반려 사유·수정 사례 |
| 자료 재확인 | 원본과 기준이 서로 다른가? | 항목 정의·갱신 규칙·확인 과정 |
| 담당 불명확 | 처리·결정·예외 대응을 누가 맡는가? | 역할·권한·문의 경로 |
조사 자료는 승인된 범위에서 필요한 내용만 확인합니다. 개선 과제 목록에 비밀번호나 실제 고객의 민감한 자료를 옮겨 적을 필요는 없습니다.
2. 관찰한 현상과 원인 가설을 나눕니다
대기가 길다는 현상만으로 담당자의 문제라고 결론 내리지 마세요. 입력 자료가 완성되지 않았거나 승인 기준이 다르거나 특정 사람에게 판단이 몰렸을 가능성도 있습니다. 가설을 적고 어떤 자료로 확인할지 정합니다.
원인을 확인하기 전에는 해결책도 후보로 남깁니다. 같은 반복 입력이라도 데이터 연결, 입력 양식 통일, 업무 책임 정리 중 무엇이 필요한지는 상황에 따라 다릅니다. 시스템 자동화가 없어도 먼저 개선할 수 있는 업무 규칙이 있는지 함께 봅니다.
예를 들어 요청 정보를 여러 양식에 다시 쓰는 가상 상황을 생각해 볼 수 있습니다. 같은 항목의 뜻이 다르다면 연결 기능을 만들기 전에 항목 정의부터 합의해야 합니다. 이 예시는 설명용이며 실제 조직의 문제나 개선 성과를 뜻하지 않습니다.
3. 문제를 실행 가능한 개선 과제로 적습니다
과제에는 대상 업무, 확인한 문제와 근거, 원인 가설, 바꿀 내용, 책임자와 확인 기준을 넣습니다. ‘업무 효율화’처럼 넓은 이름보다 어떤 처리나 전달 방식을 바꿀지 드러나는 문장이 검토하기 쉽습니다.
| 과제 구성 | 작성할 내용 | 판단할 사항 |
|---|---|---|
| 대상과 문제 | 발생 단계·사용자·영향·근거 | 확인된 사실인가, 추가 조사가 필요한가? |
| 개선 가설 | 바꾸려는 절차·양식·기능과 이유 | 원인과 연결되는가? |
| 범위와 의존성 | 포함·제외 항목·다른 업무와의 연결 | 앞서 합의할 규칙이나 자료가 있는가? |
| 실행 책임 | 검토·결정·실행·운영 담당 | 수행할 사람과 권한이 있는가? |
| 확인 기준 | 비교 대상·측정 방법·검토 시점 | 개선 여부와 부작용을 확인할 수 있는가? |
불확실한 내용은 숨기지 말고 표시하세요. 현재 측정값이 없다면 예상 절감률을 만들어 넣는 대신 무엇을 어떻게 측정해야 하는지 과제에 포함합니다.
4. 영향과 실행 조건을 함께 보고 작은 범위로 검증합니다
자주 발생하는지, 영향을 받는 업무가 중요한지, 오류나 중단 위험이 있는지 살펴봅니다. 동시에 실행 난이도·관련 조직·데이터 준비·운영 부담과 의존성을 검토합니다. 단순히 요청이 큰 목소리로 전달됐다는 이유만으로 순서를 정하지 않습니다.
보안이나 업무 지속에 중요한 문제는 일반 편의 개선과 별도의 판단이 필요할 수 있습니다. 권한이 없는 상태에서 통제 절차를 생략하거나 운영 시스템을 임의로 바꾸는 방식으로 시험하지 마세요.
실행 가능한 후보는 승인된 작은 범위에서 확인하고, 바뀐 조건과 기존 조건을 함께 기록합니다. GOV.UK의 서비스 성과 측정 안내는 성과 지표와 사용자 조사 등 여러 근거를 함께 살펴보는 관점을 설명합니다. 업무에 맞는 확인 방법을 정하는 참고로 사용할 수 있습니다.
처리 시간이 줄었더라도 오류나 다른 담당자의 작업이 늘었다면 전체 개선으로 단정하기 어렵습니다. 대상 범위와 관찰 기간, 예외, 다른 변화의 영향을 함께 확인하고 확대·수정·보류를 결정합니다.
개선 과제 도출 체크리스트
자주 묻는 질문(FAQ)
불편하다는 의견은 모두 개선 과제로 등록하나요?
의견은 출발 자료로 남길 수 있습니다. 실제 발생 상황과 영향, 근거를 확인해 추가 조사와 실행 후보를 구분하세요. 확인하지 않은 원인이나 예상 효과를 확정 사실로 기록하지 않습니다.
자동화할 수 있으면 바로 개발하면 되나요?
먼저 해당 절차가 필요한지, 입력과 처리 기준이 합의돼 있는지 확인하는 편이 좋습니다. 불필요한 반복을 줄이거나 양식을 정리하는 방법과 개발을 비교하고 운영 책임도 검토하세요.
효과를 수치로 측정할 자료가 없으면 어떻게 하나요?
자료가 없는 사실을 명확히 표시하고 측정할 항목·범위·방법을 정합니다. 실제 사례와 사용자 확인으로 가설을 좁힐 수 있지만 측정하지 않은 절감 시간이나 성과를 만들어서는 안 됩니다.
작은 개선부터 하면 중요한 과제가 밀리지 않나요?
작업이 작다는 이유만으로 우선하지는 않습니다. 영향·위험·긴급성·의존성을 함께 판단하세요. 작은 검증으로 중요한 가설을 확인하는 것과 쉬운 작업만 계속하는 것은 구분할 필요가 있습니다.
핵심 정리
개선 과제는 현상·근거·원인 가설·바꿀 내용·확인 기준이 연결돼야 합니다. 업무 흐름에서 문제를 찾고 실행 책임과 의존성까지 정리해야 다음 행동을 결정할 수 있습니다.
대표적인 불편 한 가지를 골라 실제 발생 장면과 확인 자료부터 적어 보세요. 확인한 사실과 아직 확인할 질문을 구분하면 막연한 개선 요구를 구체적인 검토 과제로 바꿀 수 있습니다.
반복되는 업무의 한 장면부터 정리해 보세요
불편한 업무 단계와 사용하는 자료, 확인한 사례와 아직 모르는 내용을 비밀정보 없이 정리해 전산가이 문의하기로 전달해 주세요. 원인 확인과 개선 범위를 논의할 기준을 구체화할 수 있습니다.