업무 자동화, 실패하는 팀들이 처음부터 놓치는 가장 큰 함정
업무 자동화를 도입하면 초반 분위기는 대체로 좋습니다.
반복 업무가 줄어든 것 같고,
실제로 처리 속도도 빨라진 것처럼 느껴집니다.
담당자도 편해졌다고 말하고,
팀장도 이제 좀 정리가 되겠다고 생각합니다.
문제는 그다음부터입니다.
자동화가 켜져 있는데 아무도 완전히 믿지 않는 상태
처음 2주는 잘 돌아가던 자동화가
3주쯤 지나면 예외 케이스 때문에 조금씩 흔들리기 시작합니다.
처음에는 수동으로 한 번만 처리하면 되겠지 하고 넘어갑니다.
그런데 그 한 번이 반복됩니다.
한 달쯤 지나면 자동화는 켜져 있는데 아무도 완전히 믿지 않는 상태가 됩니다.
결국 담당자는 자동화가 처리한 결과를 다시 사람이 한 번 더 확인하는 루틴을 만들게 됩니다.
이때부터는 자동화가 업무를 줄인 게 아니라 업무 하나를 더 만든 셈이 됩니다.
실패하는 자동화는 정상 케이스만 보고 설계됩니다
업무 자동화가 실패하는 팀들은 대개 같은 지점을 놓칩니다.
정상 케이스만 보고 자동화를 설계했다는 점입니다.
겉으로 보기에는 업무 흐름이 단순해 보입니다.
주문이 들어오면 재고를 확인하고,
재고가 있으면 출고하고,
없으면 발주를 넣는 식입니다.
이렇게만 보면 업무 자동화는 금방 될 것처럼 느껴집니다.
그런데 실제 현장에서는 업무가 그렇게 깔끔하게만 흘러가지 않습니다.
재고가 애매하게 남아 있는 경우, 거래처별 우선순위, 부분 출고, 수기 주문처럼 예외 상황은 계속 존재합니다.
이 예외들은 대부분 담당자 머릿속에만 있습니다.
문서로 정리된 적도 없고,
공식 프로세스에도 들어가 있지 않은 경우가 많습니다.
그런데 업무 자동화를 설계할 때 이 예외들이 빠지면 예외가 생기는 순간 자동화는 멈춥니다.
멈출 때마다 사람이 끼어들고,
사람이 끼어드는 일이 반복되면
팀은 자동화를 점점 신뢰하지 않게 됩니다.
실제 업무를 처리하는 사람이 설계에 들어와야 합니다
이 문제가 특히 심해지는 경우가 있습니다.
업무 자동화를 결정한 사람과 실제로 그 업무를 처리하는 사람이 다른 경우입니다.
팀장이나 대표가 자동화를 해야겠다고 결정하고,
실무자는 나중에 그 결과물을 전달받는 구조입니다.
그런데 예외 상황을 가장 잘 아는 사람은 대개 실무자입니다.
실무자는 문서에 없는 예외를 알고 있고,
어느 상황에서 프로세스가 달라지는지 알고 있고,
자동화가 어디서 멈출지를 직감적으로 알고 있습니다.
이 사람이 설계 과정에 빠져 있으면 처음에는 멀쩡해 보여도 오픈하고 나서 문제가 터질 가능성이 높아집니다.
업무 자동화를 제대로 하려면 툴부터 고르는 게 아니라 실무자 인터뷰부터 들어가야 합니다.
프로세스 문서가 있어도 그걸로 끝내면 안 됩니다.
문서에 없는 예외가 실무자에게는 분명히 남아 있기 때문입니다.
자동화 범위는 처음부터 넓게 잡지 않는 편이 좋습니다
또 하나 자주 생기는 실수는 자동화 범위를 너무 넓게 잡는 것입니다.
한 번에 전부 자동화하려고 하면 처음에는 멋있어 보입니다.
주문 접수부터 정산까지 전 과정을 한 번에 묶으면 완성도 높은 구조처럼 보이기 때문입니다.
하지만 이렇게 시작하면 예외가 생겼을 때 어느 구간에서 문제가 났는지 찾기가 어려워집니다.
오류가 생기면 전체 흐름이 같이 흔들리고,
그 시간 동안 업무는 멈춥니다.
실무에서는 오히려 좁게 시작한 팀이 더 빨리 안정화되는 경우가 많습니다.
한 구간을 완전히 안정시킨 뒤 그다음 구간으로 넘어가는 방식입니다.
주문 수집 먼저,
그다음 재고 반영,
그다음 출고 연결처럼 단계를 나눠서 붙이는 식입니다.
이 방식은 처음엔 느려 보여도 중간에 전부 무너졌다가 다시 잡는 시간까지 생각하면 오히려 훨씬 효율적입니다.
툴 선택은 가장 마지막에 와야 합니다
그래서 업무 자동화는 많이 붙이는 것보다 예외 없이 굴러가게 만드는 것이 먼저입니다.
이 지점 때문에 툴 선택도 가장 마지막에 와야 합니다.
많은 분들이 Zapier가 좋냐,
Make가 좋냐,
아니면 직접 개발해야 하냐부터 묻습니다.
그런데 이건 순서가 아닙니다.
어떤 업무를 자동화할 것인지,
그 업무에 어떤 예외가 있는지,
어디까지 자동화해야 하는지가 먼저 정리돼야 툴이 결정됩니다.
툴을 먼저 정하고 프로세스를 거기에 끼워 맞추면 툴이 처리하지 못하는 예외가 나왔을 때 구조 전체가 애매해집니다.
업무 자동화 전에 먼저 확인해야 할 것
- 정상 케이스뿐 아니라 예외 케이스가 정리되어 있는지
- 실제 업무 담당자가 설계 과정에 참여했는지
- 자동화 범위를 한 번에 너무 넓게 잡고 있지는 않은지
- 툴보다 프로세스와 예외 기준을 먼저 정리했는지
정리하면 업무 자동화에서 가장 먼저 빠지는 함정은 정상 케이스만 보고 설계하는 것입니다.
예외를 빠뜨리면 자동화는 멈추고,
자동화가 자주 멈추면 사람은 다시 수동으로 돌아갑니다.
그 순간부터 자동화는 편해지는 도구가 아니라 확인할 게 하나 더 생긴 불편한 시스템이 됩니다.
오코랩스는 업무 자동화 설계를 할 때 어떤 툴을 쓸지보다 지금 자동화하려는 업무에 어떤 예외가 숨어 있는지부터 먼저 봅니다.
실무자가 매번 손으로 처리하는 장면,
문서에 없는 규칙,
담당자만 알고 있는 우선순위를 먼저 꺼내봐야 자동화가 실제 현장에서 오래 살아남을 수 있기 때문입니다.
지금 자동화하고 싶은 업무가 있다면 프로세스부터 정리하기보다 예외 케이스 목록부터 먼저 만들어보셔야 합니다.
업무 자동화는 정상 흐름이 아니라 예외를 얼마나 잘 품느냐에서 성패가 갈립니다.
감사합니다.
업무 자동화, 실패하는 팀들이 처음부터 놓치는 가장 큰 함정
업무 자동화를 도입하면 초반 분위기는 대체로 좋습니다.
반복 업무가 줄어든 것 같고,
실제로 처리 속도도 빨라진 것처럼 느껴집니다.
담당자도 편해졌다고 말하고,
팀장도 이제 좀 정리가 되겠다고 생각합니다.
문제는 그다음부터입니다.
처음 2주는 잘 돌아가던 자동화가
3주쯤 지나면 예외 케이스 때문에 조금씩 흔들리기 시작합니다.
처음에는 수동으로 한 번만 처리하면 되겠지 하고 넘어갑니다.
그런데 그 한 번이 반복됩니다.
한 달쯤 지나면 자동화는 켜져 있는데 아무도 완전히 믿지 않는 상태가 됩니다.
결국 담당자는 자동화가 처리한 결과를 다시 사람이 한 번 더 확인하는 루틴을 만들게 됩니다.
이때부터는 자동화가 업무를 줄인 게 아니라 업무 하나를 더 만든 셈이 됩니다.
실패하는 자동화는 정상 케이스만 보고 설계됩니다
업무 자동화가 실패하는 팀들은 대개 같은 지점을 놓칩니다.
정상 케이스만 보고 자동화를 설계했다는 점입니다.
겉으로 보기에는 업무 흐름이 단순해 보입니다.
주문이 들어오면 재고를 확인하고,
재고가 있으면 출고하고,
없으면 발주를 넣는 식입니다.
이렇게만 보면 업무 자동화는 금방 될 것처럼 느껴집니다.
그런데 실제 현장에서는 업무가 그렇게 깔끔하게만 흘러가지 않습니다.
재고가 애매하게 남아 있는 경우, 거래처별 우선순위, 부분 출고, 수기 주문처럼 예외 상황은 계속 존재합니다.
이 예외들은 대부분 담당자 머릿속에만 있습니다.
문서로 정리된 적도 없고,
공식 프로세스에도 들어가 있지 않은 경우가 많습니다.
그런데 업무 자동화를 설계할 때 이 예외들이 빠지면 예외가 생기는 순간 자동화는 멈춥니다.
멈출 때마다 사람이 끼어들고,
사람이 끼어드는 일이 반복되면
팀은 자동화를 점점 신뢰하지 않게 됩니다.
실제 업무를 처리하는 사람이 설계에 들어와야 합니다
이 문제가 특히 심해지는 경우가 있습니다.
업무 자동화를 결정한 사람과 실제로 그 업무를 처리하는 사람이 다른 경우입니다.
팀장이나 대표가 자동화를 해야겠다고 결정하고,
실무자는 나중에 그 결과물을 전달받는 구조입니다.
그런데 예외 상황을 가장 잘 아는 사람은 대개 실무자입니다.
실무자는 문서에 없는 예외를 알고 있고,
어느 상황에서 프로세스가 달라지는지 알고 있고,
자동화가 어디서 멈출지를 직감적으로 알고 있습니다.
이 사람이 설계 과정에 빠져 있으면 처음에는 멀쩡해 보여도 오픈하고 나서 문제가 터질 가능성이 높아집니다.
업무 자동화를 제대로 하려면 툴부터 고르는 게 아니라 실무자 인터뷰부터 들어가야 합니다.
프로세스 문서가 있어도 그걸로 끝내면 안 됩니다.
문서에 없는 예외가 실무자에게는 분명히 남아 있기 때문입니다.
자동화 범위는 처음부터 넓게 잡지 않는 편이 좋습니다
또 하나 자주 생기는 실수는 자동화 범위를 너무 넓게 잡는 것입니다.
한 번에 전부 자동화하려고 하면 처음에는 멋있어 보입니다.
주문 접수부터 정산까지 전 과정을 한 번에 묶으면 완성도 높은 구조처럼 보이기 때문입니다.
하지만 이렇게 시작하면 예외가 생겼을 때 어느 구간에서 문제가 났는지 찾기가 어려워집니다.
오류가 생기면 전체 흐름이 같이 흔들리고,
그 시간 동안 업무는 멈춥니다.
실무에서는 오히려 좁게 시작한 팀이 더 빨리 안정화되는 경우가 많습니다.
한 구간을 완전히 안정시킨 뒤 그다음 구간으로 넘어가는 방식입니다.
주문 수집 먼저,
그다음 재고 반영,
그다음 출고 연결처럼 단계를 나눠서 붙이는 식입니다.
이 방식은 처음엔 느려 보여도 중간에 전부 무너졌다가 다시 잡는 시간까지 생각하면 오히려 훨씬 효율적입니다.
툴 선택은 가장 마지막에 와야 합니다
그래서 업무 자동화는 많이 붙이는 것보다 예외 없이 굴러가게 만드는 것이 먼저입니다.
이 지점 때문에 툴 선택도 가장 마지막에 와야 합니다.
많은 분들이 Zapier가 좋냐,
Make가 좋냐,
아니면 직접 개발해야 하냐부터 묻습니다.
그런데 이건 순서가 아닙니다.
어떤 업무를 자동화할 것인지,
그 업무에 어떤 예외가 있는지,
어디까지 자동화해야 하는지가 먼저 정리돼야 툴이 결정됩니다.
툴을 먼저 정하고 프로세스를 거기에 끼워 맞추면 툴이 처리하지 못하는 예외가 나왔을 때 구조 전체가 애매해집니다.
정리하면 업무 자동화에서 가장 먼저 빠지는 함정은 정상 케이스만 보고 설계하는 것입니다.
예외를 빠뜨리면 자동화는 멈추고,
자동화가 자주 멈추면 사람은 다시 수동으로 돌아갑니다.
그 순간부터 자동화는 편해지는 도구가 아니라 확인할 게 하나 더 생긴 불편한 시스템이 됩니다.
오코랩스는 업무 자동화 설계를 할 때 어떤 툴을 쓸지보다 지금 자동화하려는 업무에 어떤 예외가 숨어 있는지부터 먼저 봅니다.
실무자가 매번 손으로 처리하는 장면,
문서에 없는 규칙,
담당자만 알고 있는 우선순위를 먼저 꺼내봐야 자동화가 실제 현장에서 오래 살아남을 수 있기 때문입니다.
지금 자동화하고 싶은 업무가 있다면 프로세스부터 정리하기보다 예외 케이스 목록부터 먼저 만들어보셔야 합니다.
업무 자동화는 정상 흐름이 아니라 예외를 얼마나 잘 품느냐에서 성패가 갈립니다.
감사합니다.