ERP 외주 개발, 맡기기 전 필독 사항 총정리

ERP 외주 개발을 맡겼다가 낭패를 봤다는 얘기, 주변에서 한 번쯤 들어봤을 겁니다.
납품은 됐는데 실제로 안 쓰게 됐다는 경우.
중간에 업체가 연락이 안 된다는 경우.
추가 기능 붙이려니 처음 견적의 몇 배가 나온다는 경우.
이런 일이 생기는 건 개발 실력 문제가 아닌 경우가 많습니다.
맡기기 전에 확인했어야 할 것들을 확인하지 않아서 생기는 경우가 대부분입니다.
계약 전에 반드시 확인할 것들
개발 범위가 문서로 정리돼 있나요
"ERP 만들어주세요"로 계약하면 안 됩니다.
어떤 기능을 만들고,
어떤 기능은 포함되지 않는지가
문서로 명확하게 정리돼 있어야 합니다.
구두로 협의한 내용은 나중에 서로 기억이 달라집니다.
범위가 문서로 없으면 추가 비용 분쟁의 시작입니다.
납품 기준이 명확한가요
"완성되면 납품"은 기준이 아닙니다.
어떤 기능이 어떻게 작동해야 납품 완료인지가
구체적으로 정해져 있어야 합니다.
기준이 없으면 업체 입장에서는 납품이고,
우리 입장에서는 미완성인 상황이 생깁니다.
납품 후 유지보수는 어떻게 되나요
ERP는 만들고 끝이 아닙니다.
쓰다 보면 오류가 생기고,
업무가 바뀌면 기능도 바뀌어야 합니다.
납품 후 몇 개월까지 무상 수정이 되는지,
그 이후 유지보수 비용은 어떻게 되는지를 계약 전에 확인해야 합니다.
납품 후 연락이 안 되는 업체가 실제로 있습니다.
소스코드 소유권은 누구한테 있나요
개발이 끝난 뒤 소스코드가 우리 것인지 확인해야 합니다.
소스코드가 없으면 나중에 다른 업체한테 유지보수를 맡기거나
기능을 추가하기가 어렵습니다.
계약서에 소스코드 인계 조항이 있는지 반드시 확인하세요.
비슷한 프로젝트 경험이 있나요
ERP는 업종마다 구조가 다릅니다.
쇼핑몰 개발 경험이 많은 업체가
세무법인 ERP를 잘 만든다는 보장이 없습니다.
비슷한 업종,
비슷한 규모의 프로젝트를 해본 경험이 있는지를 확인하세요.
경험이 있다면 어떤 이슈가 있었고
어떻게 해결했는지까지 물어보세요.
"해본 적 있습니다"와 실제 경험은 디테일에서 차이가 납니다.
개발 중간에 확인할 것들
중간 보고가 있나요
개발이 시작되고 나서 연락이 뜸해지는 업체가 있습니다.
"완성되면 연락드릴게요"는 곤란합니다.
어느 단계에서 중간 확인을 하는지,
우리가 피드백을 줄 수 있는 시점이 언제인지를
미리 정해두는 게 맞습니다.
우리가 테스트할 수 있는 환경이 있나요
납품 전에 실제로 써볼 수 있는 테스트 환경이 있어야 합니다.
화면만 보여주는 것과
직접 데이터를 넣어보는 건 다릅니다.
실제로 써봐야 우리 업무랑 맞는지 안 맞는지가 보입니다.
계약서에서 꼭 챙겨야 할 항목
- 범위 정의
- 납품 기준
- 하자보수 기간
- 소스코드 인계
- 지연 시 패널티
이 다섯 가지가 계약서에 없으면
나중에 분쟁이 생겼을 때 우리한테 불리합니다.
금액이 저렴한 업체일수록
이 항목들이 빠져있는 경우가 많습니다.
오코랩스가 처음 미팅에서 하는 것
기능 얘기보다 업무 파악이 먼저입니다.
지금 어떻게 일하고 있는지,
어디서 불편함이 생기는지를 먼저 듣습니다.
그 다음에 범위를 정하고,
범위가 정해지면 문서로 정리해서 공유합니다.
개발 중간에는 단계별로 확인하고,
납품 전에는 충분히 테스트할 수 있는 환경을 드립니다.
핵심 정리 ERP 외주 개발은
계약 전에 범위, 납품 기준, 유지보수, 소스코드 소유권을
반드시 확인해야 합니다.
처음부터 문서로 기준을 잡아야
추가 비용과 분쟁을 줄일 수 있습니다. 납품 후에도 담당자가 바뀌지 않습니다.
처음부터 같이 한 사람이 끝까지 책임집니다.
ERP 외주 개발 맡기기 전에 확인하고 싶은 게 있다면,
오코랩스와 먼저 이야기해보세요.
ERP 외주 개발, 맡기기 전 필독 사항 총정리
ERP 외주 개발을 맡겼다가 낭패를 봤다는 얘기, 주변에서 한 번쯤 들어봤을 겁니다.
납품은 됐는데 실제로 안 쓰게 됐다는 경우.
중간에 업체가 연락이 안 된다는 경우.
추가 기능 붙이려니 처음 견적의 몇 배가 나온다는 경우.
맡기기 전에 확인했어야 할 것들을 확인하지 않아서 생기는 경우가 대부분입니다.
계약 전에 반드시 확인할 것들
개발 범위가 문서로 정리돼 있나요
"ERP 만들어주세요"로 계약하면 안 됩니다.
어떤 기능을 만들고,
어떤 기능은 포함되지 않는지가
문서로 명확하게 정리돼 있어야 합니다.
구두로 협의한 내용은 나중에 서로 기억이 달라집니다.
납품 기준이 명확한가요
"완성되면 납품"은 기준이 아닙니다.
어떤 기능이 어떻게 작동해야 납품 완료인지가
구체적으로 정해져 있어야 합니다.
기준이 없으면 업체 입장에서는 납품이고,
우리 입장에서는 미완성인 상황이 생깁니다.
납품 후 유지보수는 어떻게 되나요
ERP는 만들고 끝이 아닙니다.
쓰다 보면 오류가 생기고,
업무가 바뀌면 기능도 바뀌어야 합니다.
납품 후 몇 개월까지 무상 수정이 되는지,
그 이후 유지보수 비용은 어떻게 되는지를 계약 전에 확인해야 합니다.
소스코드 소유권은 누구한테 있나요
개발이 끝난 뒤 소스코드가 우리 것인지 확인해야 합니다.
소스코드가 없으면 나중에 다른 업체한테 유지보수를 맡기거나
기능을 추가하기가 어렵습니다.
계약서에 소스코드 인계 조항이 있는지 반드시 확인하세요.
비슷한 프로젝트 경험이 있나요
ERP는 업종마다 구조가 다릅니다.
쇼핑몰 개발 경험이 많은 업체가
세무법인 ERP를 잘 만든다는 보장이 없습니다.
비슷한 업종,
비슷한 규모의 프로젝트를 해본 경험이 있는지를 확인하세요.
경험이 있다면 어떤 이슈가 있었고
어떻게 해결했는지까지 물어보세요.
개발 중간에 확인할 것들
중간 보고가 있나요
개발이 시작되고 나서 연락이 뜸해지는 업체가 있습니다.
"완성되면 연락드릴게요"는 곤란합니다.
어느 단계에서 중간 확인을 하는지,
우리가 피드백을 줄 수 있는 시점이 언제인지를
미리 정해두는 게 맞습니다.
우리가 테스트할 수 있는 환경이 있나요
납품 전에 실제로 써볼 수 있는 테스트 환경이 있어야 합니다.
화면만 보여주는 것과
직접 데이터를 넣어보는 건 다릅니다.
계약서에서 꼭 챙겨야 할 항목
이 다섯 가지가 계약서에 없으면
나중에 분쟁이 생겼을 때 우리한테 불리합니다.
금액이 저렴한 업체일수록
이 항목들이 빠져있는 경우가 많습니다.
오코랩스가 처음 미팅에서 하는 것
기능 얘기보다 업무 파악이 먼저입니다.
지금 어떻게 일하고 있는지,
어디서 불편함이 생기는지를 먼저 듣습니다.
그 다음에 범위를 정하고,
범위가 정해지면 문서로 정리해서 공유합니다.
개발 중간에는 단계별로 확인하고,
납품 전에는 충분히 테스트할 수 있는 환경을 드립니다.
ERP 외주 개발은
처음부터 문서로 기준을 잡아야계약 전에 범위, 납품 기준, 유지보수, 소스코드 소유권을
반드시 확인해야 합니다.
추가 비용과 분쟁을 줄일 수 있습니다.
납품 후에도 담당자가 바뀌지 않습니다.
처음부터 같이 한 사람이 끝까지 책임집니다.
ERP 외주 개발 맡기기 전에 확인하고 싶은 게 있다면,
오코랩스와 먼저 이야기해보세요.