ERP, 패키지를 살까 맞춰서 만들까

가격표보다 먼저 물어야 할 것

ERP를 고를 때 먼저 물어야 할 건 가격이 아니라 바꾸면 안 되는 일이 무엇인가다. ERP를 알아보기 시작하면 제일 먼저 부딪히는 질문이 있다. 패키지를 살 것인가, 맞춰서 만들 것인가.

이 질문은 대개 가격표를 보면서 시작된다. 패키지는 한 달에 얼마, 구축은 견적서 한 장이다. 숫자만 놓고 보면 답이 너무 쉬워 보이지만, 가격표로는 답이 안 나온다.

ERP가 하는 일은 결국 영업, 구매, 재고, 생산, 회계가 따로 쓰던 엑셀과 장부를 하나의 데이터로 묶는 것이다. 주문이 들어오면 재고가 빠지고, 출고가 되면 매출이 잡히고, 월말에는 그 숫자가 그대로 회계로 넘어간다. 같은 숫자를 세 번 입력하지 않게 하는 것이 ERP의 전부라고 해도 크게 틀리지 않다.

여기까지는 패키지든 맞춤이든 똑같이 해 준다. 차이는 회사의 일이 남들과 얼마나 같은가에서 생긴다.

패키지가 맞는 경우

패키지 ERP는 수많은 회사가 함께 쓰도록 만든 제품이다. 가장 많은 회사가 일하는 방식을 기준으로 화면과 순서가 짜여 있고, 그 흐름은 이미 여러 회사에서 검증됐다.

업무가 업계 표준에 가깝다면 패키지부터 보는 게 맞다. 주문, 출고, 매출, 수금이 흔한 순서대로 흘러가고, 거래처마다 따로 챙기는 규칙이 거의 없는 경우다.

법과 세법이 정해 둔 일이 중심일 때도 그렇다. 회계, 급여, 부가세 신고처럼 정답이 정해진 업무는 회사마다 다를 이유가 없다. 법이 바뀔 때 업체가 알아서 고쳐 주는 것도 패키지의 장점이다.

당장 써야 한다면 답은 더 분명하다. 패키지는 가입하면 내일부터 쓸 수 있고, 맞춤 구축은 몇 달을 기다려야 한다.

처리 건수가 많지 않다면 패키지로 충분하다. 하루 수십 건이라면 패키지가 못 하는 부분을 손으로 메워도 부담이 크지 않다.

시스템을 맡아 줄 사람이 없다면 패키지가 편하다. 장애 대응과 업데이트를 업체에 통째로 맡길 수 있다.

패키지의 방식이 더 낫다면 바꿀 생각이 있는 회사도 패키지 쪽이다. 지금 방식이 굳이 지킬 이유 없이 굳어진 것이라면, 검증된 흐름에 맞추는 편이 오히려 이득이다.

다만 패키지를 사서 회사에 맞게 고쳐 쓰는 길은 조심해야 한다. 고치는 비용은 가격표에 나와 있지 않고, 고친 부분은 패키지가 업데이트될 때마다 다시 확인해야 한다.

고친 곳이 많아질수록 패키지를 산 이유였던 '싸고 빠르다'는 장점이 사라진다. 고칠 곳이 여러 군데 보인다면, 그건 패키지가 맞지 않는다는 신호에 가깝다.

맞춤이 맞는 경우

대부분의 회사는 업무 대부분이 표준에 가깝다. 다른 곳은 몇 군데뿐이다.

문제는 그 몇 군데가 하필 회사가 돈을 버는 방식과 붙어 있다는 점이다. 그럴 때가 맞춤 구축을 진지하게 검토할 때다.

회사만의 방식이 매출과 직접 이어져 있다면 맞춤을 볼 때다. 거래처마다 다른 단가 규칙, 그 업계에서만 쓰는 출고 방식, 오래된 거래처와 맞춰 온 정산 관행 같은 것들이다. 남들과 다른 이 부분이 곧 회사가 경쟁하는 방식이다.

업무를 바꾸기 어려운 경우도 그렇다. 패키지에 맞추려면 사람들 손에 익은 순서를 바꿔야 하고, 거래처가 얽혀 있으면 거래처의 방식까지 바꿔 달라고 해야 한다. 화면 하나 바꾸는 일이 아니다.

패키지를 들여도 엑셀이 남을 게 보인다면 맞춤 쪽이다. 지금 엑셀로 버티는 일이 많은데 패키지가 그 일을 하지 못한다면, 도입 뒤에도 그 엑셀은 그대로 남는다.

처리 건수가 많을 때도 마찬가지다. 하루 수백 건이 넘으면 손으로 한 번 더 옮겨 적는 비용이 곧바로 사람 한 명의 일이 된다.

이미 쓰는 시스템과의 연결이 핵심일 때도 있다. 쇼핑몰, 택배사, 기존 회계 프로그램과 데이터를 주고받는 게 일의 대부분이라면, 연결을 회사에 맞게 짜는 쪽이 낫다.

모니터 한쪽에 남은 엑셀

ERP를 도입했는데 모니터 한쪽에 엑셀이 하나 더 열려 있다면, ERP가 다 하지 못한 일이 거기 남아 있다는 뜻이다. 그리고 그 엑셀의 숫자를 누군가는 다시 ERP에 옮겨 적는다.

같은 숫자를 세 번 입력하지 않으려고 들인 시스템인데 입력이 한 번 더 늘어난 셈이다. 맞춤 구축이 필요한 곳은 대개 이 엑셀 안에 있다.

맞춤 구축은 출발점이 다르다. 화면부터 보는 게 아니라 지금 현장에서 쓰는 엑셀과 종이 양식부터 본다.

그 양식에는 어떤 칸을 먼저 채우는지, 누가 어디에 도장을 찍는지, 어떤 숫자를 따로 적어 두는지가 이미 다 들어 있다. 그 흐름을 그대로 화면으로 옮기면 사람들이 새로 배울 것이 줄어든다.

물론 위험도 분명하다. 먼저 시간과 비용이다. ERP 전체를 새로 만들면 보통 3~6개월이 걸린다.

더 큰 위험은 사람이다. 맞춤 시스템은 만든 사람만 구조를 안다. 만든 사람이 떠나면 아무도 손대지 못하는 시스템이 남는다.

그래서 맞춤을 고를 때는 얼마에 만드느냐보다 만든 다음 누가 고치느냐를 먼저 물어야 한다.

한눈에 비교하면

어느 한쪽에 몰려 있다면 답은 쉽다. 섞여 있다면, 다음 방법을 보면 된다.

둘 중 하나만 고를 필요는 없다

실제로는 섞여 있는 경우가 가장 많다. 그럴 때는 일을 나눠서 생각하면 된다. 남들과 같은 일은 사서 쓰고, 다른 일만 맞춰 만든다.

회계와 급여는 쓰던 프로그램을 그대로 두고, 패키지가 못 하는 출고나 정산 쪽만 따로 만들어 연결하는 식이다. API가 열려 있으면 API로, 없으면 DB를 직접 연결하거나 파일을 주고받는 방식으로 필요한 부분만 붙일 수 있다. 쓰던 시스템을 갈아엎는 것부터 생각할 필요는 없다.

맞춰 만드는 부분도 한 번에 다 만들 필요가 없다. 가장 아픈 곳 하나부터 만들면 된다. 기능 하나를 추가하는 일은 보통 2~4주면 된다.

그걸 실제로 써 보고, 다음으로 아픈 곳을 붙인다. 써 보면서 만들면 처음에 요구사항으로 적지 못했던 것들이 드러나고, 다 만든 다음에 드러나는 것보다 훨씬 싸게 고칠 수 있다.

세컨드코리아도 패키지와 맞춤을 둘 다 한다. 창고관리 같은 일은 가입하면 바로 쓰는 서비스로 직접 만들어 운영하고, 동시에 회사에 맞춘 시스템도 만든다.

둘을 다 해 보면 패키지와 맞춤은 경쟁 관계라기보다 순서의 문제에 가깝다. 표준에 가까운 일은 패키지로 시작하고, 쓰다가 표준에 안 맞는 부분이 드러나면 그 부분만 맞춰 붙이는 것도 충분히 좋은 방법이다.

고르기 전에 물어볼 네 가지

첫째, 회사만의 방식이 매출과 직접 이어져 있는가. 그렇다면 그 부분은 패키지에 맞추지 않는 편이 낫다.

둘째, 지금 엑셀로 버티는 일이 얼마나 되는가. 패키지를 들여도 그 엑셀이 그대로 남을 것 같다면, 문제는 그 엑셀 쪽에 있다.

셋째, 하루에 처리하는 건수가 얼마인가. 건수가 많을수록 손으로 옮겨 적는 한 번의 비용이 커진다.

넷째, 만든 다음 누가 고칠 것인가. 패키지라면 업체가, 맞춤이라면 만든 사람이 계속 맡을 수 있어야 한다.

패키지냐 맞춤이냐는 마지막 질문이다

세컨드코리아가 상담할 때 묻는 것은 세 가지다. 지금 쓰고 있는 시스템과 불편한 점, 하루 처리 건수, 희망 일정과 대략의 예산이다.

어떤 ERP를 원하는지는 묻지 않는다. 그건 이 세 가지를 듣고 나면 대부분 저절로 정해진다.

ERP를 고르는 게 목표는 아니었다. 같은 숫자를 세 번 입력하지 않는 게 목표였다. 그래서 패키지냐 맞춤이냐는 맨 마지막에 정해도 늦지 않다.

먼저 정해야 할 건 바꾸면 안 되는 일이 무엇인지다. 그게 정해지면 ERP 옆에 엑셀이 다시 열릴지 아닐지도 대략 보인다.

용어 쉽게 보기

글에 나온 용어를 개발자가 아닌 분도 읽을 수 있게 풀었다.