ERP 프로그램, 기존 제품과 맞춤 개발 중 무엇이 맞을까?
ERP 프로그램을 비교하다 보면 어느 제품에나 구매, 재고, 매출 관리가 있습니다.
기능 목록만 보면 모두 쓸 수 있을 것 같습니다.
기존 ERP 제품과 맞춤 개발을 선택하는 기준은 기능의 개수보다 핵심 업무를 얼마나 무리 없이 처리할 수 있는지입니다. 기존 기능과 설정으로 해결된다면 제품 도입을, 중요한 업무가 계속 시스템 밖으로 빠진다면 확장이나 맞춤 개발을 검토할 수 있습니다.
차이는 메뉴 이름보다 실제 주문 한 건을 처리할 때 드러납니다.
‘재고 관리 가능’이라는 답으로는 부족합니다
식품 유통회사가 ERP를 검토한다고 가정해보겠습니다.
현재 재고 수량만 확인하면 되는지, 유통기한과 입고 단위별로 구분해야 하는지, 반품된 상품을 판매 가능한 재고와 분리해야 하는지에 따라 필요한 기능은 달라집니다.
제품 소개서에는 모두 ‘재고 관리’라고 적힐 수 있습니다.
하지만 실제 처리 과정은 같지 않습니다.
시연을 요청할 때는 메뉴를 둘러보는 대신 실제 업무 사례를 전달해보세요.
"같은 상품이 서로 다른 날짜에 입고됐고, 일부가 출고된 뒤 반품까지 들어왔습니다. 이 과정을 어떻게 처리하나요?"
이렇게 물어야 설정으로 해결하는지, 별도 개발이 필요한지, 엑셀 작업이 남는지 확인할 수 있습니다.
우리 방식이 특별한지, 오래된 습관인지
직원들은 지금 사용하는 엑셀과 똑같은 화면을 원할 수 있습니다.
익숙한 방식이 편하기 때문입니다.
하지만 부서마다 양식이 다르거나 같은 내용을 여러 번 결재받는 절차까지 그대로 개발할 필요가 있는지는 살펴봐야 합니다.
Microsoft의 Dynamics 365 도입 가이드도 기존 업무를 그대로 재현하려 하면 불필요한 맞춤 개발이 늘 수 있어, 표준 기능과 업무 요구를 비교하는 과정을 권장합니다.
중요한 것은 직원의 요구를 무시하는 것이 아닙니다.
왜 그 방식이 필요한지 확인하는 것입니다.
거래처와 약속한 정산 조건 때문에 필요한 절차인지, 이전 프로그램의 한계 때문에 생긴 임시 작업인지에 따라 유지할 이유가 달라집니다.
지켜야 할 업무 조건과 바꿔도 되는 습관을 구분하면 개발 범위도 더 명확해집니다.
기능 하나가 빠졌다고 전부 새로 만들까요?
기존 ERP가 대부분의 업무를 처리하지만 거래처별 수수료 계산만 맞지 않는 상황을 가정해보겠습니다.
이 기능 때문에 전체 ERP를 새로 만드는 선택도 가능하지만, 다른 방법부터 확인할 수 있습니다.
제품의 설정으로 계산 규칙을 바꿀 수 있는지, 추가 모듈이나 공식 확장 기능이 있는지, 별도 프로그램에서 계산한 결과를 연결할 수 있는지 살펴보는 것입니다.
기존 ERP와 별도 업무 시스템을 함께 사용하는 방식도 검토 대상이 될 수 있습니다.
다만 연결한다고 모든 문제가 사라지지는 않습니다.
데이터를 어디에서 입력하고 수정할지, 오류가 생기면 누가 확인할지 정해야 합니다.
선택지를 ‘기존 제품 그대로 사용’과 ‘전부 맞춤 개발’ 두 가지로만 좁힐 필요는 없습니다.
맞춤 개발은 언제 설득력이 생길까요?
매일 처리하는 핵심 업무를 기존 제품으로 수행하기 어렵고, 우회 작업에 드는 부담이 크다면 검토할 이유가 생깁니다.
예를 들어 주문마다 작업 순서와 원가 계산 방식이 달라 여러 엑셀을 합쳐야만 진행 상황을 알 수 있다고 해보겠습니다.
기존 ERP를 도입해도 이 과정이 그대로 남는다면 가장 줄이고 싶었던 일이 해결되지 않을 수 있습니다.
이때는 필요한 정보를 연결하고 실제 작업 순서에 맞게 설계하는 맞춤형 ERP가 대안이 됩니다.
다만 맞춤 개발에도 회사의 참여가 필요합니다.
부서마다 다른 기준을 정리하고, 완성된 기능이 실제 업무에 맞는지 확인할 담당자가 있어야 합니다.
요구사항이 정해지지 않은 상태에서 "우리 회사에 맞게 만들어주세요"라고 맡기면 개발 중에도 판단이 계속 바뀔 수 있습니다.
도입 가격보다 남는 일을 비교하세요
기존 제품은 이용료만, 맞춤 개발은 최초 개발비만 비교하면 조건이 맞지 않습니다.
제품 도입에도 설정, 자료 이관, 교육, 연동 비용이 생길 수 있고, 맞춤 개발 이후에도 운영과 유지보수가 필요합니다.
비용표와 함께 다음 질문을 적어보세요.
도입 후에도 사람이 옮겨 적어야 하나요?
남는 수작업의 종류와 빈도를 확인해야 합니다.
가끔 처리하는 예외와 매일 반복하는 작업은 다르게 봐야 합니다.
업무가 바뀌면 어떻게 수정하나요?
설정으로 바꿀 수 있는지, 개발 요청이 필요한지, 지원 범위와 변경 비용은 어떤지 확인합니다.
담당자가 바뀌어도 운영할 수 있나요?
사용 설명, 관리 권한, 기술 지원과 인계 조건을 살펴야 합니다.
특정 직원이나 개발자만 아는 시스템이 되면 작은 변경도 처리하기 어려워질 수 있습니다.
처음 도입할 때뿐 아니라 운영하면서 필요한 사람과 작업까지 비교해야 합니다.
오코랩스는 개발할 이유부터 확인합니다
ERP 프로그램을 선택하기 전에 현재 가장 번거로운 업무 세 가지를 적어보세요.
그 업무가 언제 시작되고, 누가 어떤 정보를 확인하며, 어디에서 다시 입력하는지 정리하면 제품 시연과 개발 상담에서 확인할 기준이 생깁니다.
오코랩스는 실제 업무 순서를 살펴 기존 솔루션으로 해결할 부분과 맞춤 개발이 필요한 부분을 구분합니다.
기능이 많아 보이는 시스템보다 직원이 반복하던 일을 실제로 줄일 수 있는 범위를 찾습니다.
ERP 도입을 검토하고 있다면 사용 중인 양식과 처리하기 까다로운 업무 사례를 알려주세요.
오코랩스가 기존 제품 활용, 부분 연동, 맞춤 개발 중 어떤 방식이 적합할지 정리하는 것부터 함께하겠습니다.
ERP 프로그램, 기존 제품과 맞춤 개발 중 무엇이 맞을까?
ERP 프로그램을 비교하다 보면 어느 제품에나 구매, 재고, 매출 관리가 있습니다.
기능 목록만 보면 모두 쓸 수 있을 것 같습니다.
기존 ERP 제품과 맞춤 개발을 선택하는 기준은 기능의 개수보다 핵심 업무를 얼마나 무리 없이 처리할 수 있는지입니다. 기존 기능과 설정으로 해결된다면 제품 도입을, 중요한 업무가 계속 시스템 밖으로 빠진다면 확장이나 맞춤 개발을 검토할 수 있습니다.
차이는 메뉴 이름보다 실제 주문 한 건을 처리할 때 드러납니다.
‘재고 관리 가능’이라는 답으로는 부족합니다
식품 유통회사가 ERP를 검토한다고 가정해보겠습니다.
현재 재고 수량만 확인하면 되는지, 유통기한과 입고 단위별로 구분해야 하는지, 반품된 상품을 판매 가능한 재고와 분리해야 하는지에 따라 필요한 기능은 달라집니다.
제품 소개서에는 모두 ‘재고 관리’라고 적힐 수 있습니다.
하지만 실제 처리 과정은 같지 않습니다.
시연을 요청할 때는 메뉴를 둘러보는 대신 실제 업무 사례를 전달해보세요.
"같은 상품이 서로 다른 날짜에 입고됐고, 일부가 출고된 뒤 반품까지 들어왔습니다. 이 과정을 어떻게 처리하나요?"
이렇게 물어야 설정으로 해결하는지, 별도 개발이 필요한지, 엑셀 작업이 남는지 확인할 수 있습니다.
우리 방식이 특별한지, 오래된 습관인지
직원들은 지금 사용하는 엑셀과 똑같은 화면을 원할 수 있습니다.
익숙한 방식이 편하기 때문입니다.
하지만 부서마다 양식이 다르거나 같은 내용을 여러 번 결재받는 절차까지 그대로 개발할 필요가 있는지는 살펴봐야 합니다.
Microsoft의 Dynamics 365 도입 가이드도 기존 업무를 그대로 재현하려 하면 불필요한 맞춤 개발이 늘 수 있어, 표준 기능과 업무 요구를 비교하는 과정을 권장합니다.
중요한 것은 직원의 요구를 무시하는 것이 아닙니다.
왜 그 방식이 필요한지 확인하는 것입니다.
거래처와 약속한 정산 조건 때문에 필요한 절차인지, 이전 프로그램의 한계 때문에 생긴 임시 작업인지에 따라 유지할 이유가 달라집니다.
지켜야 할 업무 조건과 바꿔도 되는 습관을 구분하면 개발 범위도 더 명확해집니다.
기능 하나가 빠졌다고 전부 새로 만들까요?
기존 ERP가 대부분의 업무를 처리하지만 거래처별 수수료 계산만 맞지 않는 상황을 가정해보겠습니다.
이 기능 때문에 전체 ERP를 새로 만드는 선택도 가능하지만, 다른 방법부터 확인할 수 있습니다.
제품의 설정으로 계산 규칙을 바꿀 수 있는지, 추가 모듈이나 공식 확장 기능이 있는지, 별도 프로그램에서 계산한 결과를 연결할 수 있는지 살펴보는 것입니다.
기존 ERP와 별도 업무 시스템을 함께 사용하는 방식도 검토 대상이 될 수 있습니다.
다만 연결한다고 모든 문제가 사라지지는 않습니다.
데이터를 어디에서 입력하고 수정할지, 오류가 생기면 누가 확인할지 정해야 합니다.
선택지를 ‘기존 제품 그대로 사용’과 ‘전부 맞춤 개발’ 두 가지로만 좁힐 필요는 없습니다.
맞춤 개발은 언제 설득력이 생길까요?
매일 처리하는 핵심 업무를 기존 제품으로 수행하기 어렵고, 우회 작업에 드는 부담이 크다면 검토할 이유가 생깁니다.
예를 들어 주문마다 작업 순서와 원가 계산 방식이 달라 여러 엑셀을 합쳐야만 진행 상황을 알 수 있다고 해보겠습니다.
기존 ERP를 도입해도 이 과정이 그대로 남는다면 가장 줄이고 싶었던 일이 해결되지 않을 수 있습니다.
이때는 필요한 정보를 연결하고 실제 작업 순서에 맞게 설계하는 맞춤형 ERP가 대안이 됩니다.
다만 맞춤 개발에도 회사의 참여가 필요합니다.
부서마다 다른 기준을 정리하고, 완성된 기능이 실제 업무에 맞는지 확인할 담당자가 있어야 합니다.
요구사항이 정해지지 않은 상태에서 "우리 회사에 맞게 만들어주세요"라고 맡기면 개발 중에도 판단이 계속 바뀔 수 있습니다.
도입 가격보다 남는 일을 비교하세요
기존 제품은 이용료만, 맞춤 개발은 최초 개발비만 비교하면 조건이 맞지 않습니다.
제품 도입에도 설정, 자료 이관, 교육, 연동 비용이 생길 수 있고, 맞춤 개발 이후에도 운영과 유지보수가 필요합니다.
비용표와 함께 다음 질문을 적어보세요.
도입 후에도 사람이 옮겨 적어야 하나요?
남는 수작업의 종류와 빈도를 확인해야 합니다.
가끔 처리하는 예외와 매일 반복하는 작업은 다르게 봐야 합니다.
업무가 바뀌면 어떻게 수정하나요?
설정으로 바꿀 수 있는지, 개발 요청이 필요한지, 지원 범위와 변경 비용은 어떤지 확인합니다.
담당자가 바뀌어도 운영할 수 있나요?
사용 설명, 관리 권한, 기술 지원과 인계 조건을 살펴야 합니다.
특정 직원이나 개발자만 아는 시스템이 되면 작은 변경도 처리하기 어려워질 수 있습니다.
처음 도입할 때뿐 아니라 운영하면서 필요한 사람과 작업까지 비교해야 합니다.
오코랩스는 개발할 이유부터 확인합니다
ERP 프로그램을 선택하기 전에 현재 가장 번거로운 업무 세 가지를 적어보세요.
그 업무가 언제 시작되고, 누가 어떤 정보를 확인하며, 어디에서 다시 입력하는지 정리하면 제품 시연과 개발 상담에서 확인할 기준이 생깁니다.
오코랩스는 실제 업무 순서를 살펴 기존 솔루션으로 해결할 부분과 맞춤 개발이 필요한 부분을 구분합니다.
기능이 많아 보이는 시스템보다 직원이 반복하던 일을 실제로 줄일 수 있는 범위를 찾습니다.
ERP 도입을 검토하고 있다면 사용 중인 양식과 처리하기 까다로운 업무 사례를 알려주세요.
오코랩스가 기존 제품 활용, 부분 연동, 맞춤 개발 중 어떤 방식이 적합할지 정리하는 것부터 함께하겠습니다.