ERP 고도화 업체 선정: 기존 개발사 없이 시스템을 인수하는 기준

기존 개발사 없이 ERP를 고도화하려면 새 기능 견적보다 현행 시스템을 복원하고 원장 숫자를 설명할 수 있는 업체인지 먼저 확인해야 합니다. 소스·계정·배포·백업·연동 자산을 인수하고 재고와 미처리 거래, 마감 경계를 대조한 뒤 안정화와 고도화를 나눠 발주하세요. 자료가 부족한 상태에서 전체 기능과 고정 금액을 확약하는 제안은 전제와 제외 범위를 다시 확인할 필요가 있습니다.

ERP는 켜지는데 작은 수정도 할 수 없는 상황이 있습니다. 전 담당자의 개인 계정에 서버가 묶여 있거나 현재 운영 버전과 저장소 코드가 다른 경우입니다. 이전 개발사가 없다는 사실만으로 전면 재구축을 결정하지는 마세요. 회사가 실제로 확보한 자산과 재현 가능한 기능을 조사하면 유지할 부분과 새로 만들어야 할 부분을 구분할 수 있습니다. 다만 조사 중 운영 데이터를 수정하지 않도록 읽기 권한과 시험 환경을 먼저 마련합니다.

일반적인 유지보수 이전은 문서와 담당자가 있는 상태에서 책임을 넘기는 일일 수 있습니다. 기존 개발사가 없는 ERP 인수는 설명되지 않은 계산, 예약 작업, 수동 정정까지 찾아야 합니다. 화면의 재고가 맞아 보여도 기초 수량과 입출고를 합하면 다른 결과가 나올 수 있고, 월말 담당자가 별도 파일로 숫자를 맞추는 절차가 숨어 있을 수 있습니다. 이런 공백을 새 업체의 개발 능력만으로 메울 수는 없습니다. 고객사의 구매·창고·재무 담당자가 현재 업무 근거를 제공해야 합니다.

이 글의 인수·검수 순서는 발주자가 요구할 수 있는 일반 제안입니다. 특정 고객의 실제 장애나 복구 성과를 옮긴 사례가 아닙니다. 기존 계약의 권리와 데이터 접근 허가는 회사가 확인해야 하며, 소스를 확보하지 못했거나 외부 제품의 수정 권한이 없는 경우에는 그 제약을 전제로 대안을 정해야 합니다. 계약 해석과 회계 판단은 해당 담당 전문가의 확인 영역으로 남깁니다.

보안 인수와 비용 산정의 근거는 구분해서 읽는다#

NIST SSDF는 공급자와 보안 개발 관행을 논의하는 참고 틀이고, GAO 비용 가이드는 범위·가정·위험과 실제 비용 갱신을 다룹니다. 이 자료들만으로 기존 ERP의 원장 정확성이나 소스 권리, 복구 가능성을 판단할 수는 없습니다. 아래 인수 순서는 일반 실무 제안이며 자사 환경의 복원·대사 결과와 계약 확인이 별도로 필요합니다.

• NIST SSDF 1.1: 공급자 보안 개발 질문을 위한 참고 틀
• GAO 비용 추정·평가 가이드: 미확정 범위·가정·위험을 나눈 비용 관리

진단·복원·안정화·고도화를 나눠 계약한다#

업체 선정 인터뷰에는 분석가와 운영 담당자가 함께 참여하도록 요청할 수 있습니다. 복원되지 않는 자료를 어떤 순서로 조사할지, 원장 차이를 누가 승인할지, 회사 계정으로 접근하지 못하면 어떤 안전한 대안이 있는지 묻습니다. 모르는 영역을 인정하고 조사·보류 조건으로 설명하는 후보가 있는지 보세요. 자료가 없는데 오류 없는 인수나 무중단 전환을 보장하는 문구는 실제 근거와 제외 조건을 확인하기 전까지 평가 증거로 쓰지 않습니다.

진단 발주에는 조사 대상과 접근 범위, 산출물, 종료 조건을 적습니다. 회사가 가진 저장소, 운영 서버 목록, 계약 자료, 최근 백업, 오류 내역과 담당자 명단을 제공합니다. 새 업체는 확보된 자산, 권한 부족, 운영본과 소스의 차이, 복원 시험 결과, 중요 위험과 추가 조사 항목을 반환하게 하세요. 코드를 잠깐 보고 모든 수정 비용을 확정하는 방식보다 조사 결과로 다음 범위와 예산을 정하는 편이 전제를 확인하기 쉽습니다.

진단 중에는 변경을 통제합니다. 오류를 찾았다는 이유로 운영 DB를 바로 수정하거나 배포 설정을 덮어쓰지 않게 하세요. 긴급 복구만 별도 승인 경로로 허용하고 무엇을 바꿨는지 전후 값과 책임자를 남깁니다. 수정이 필요한 거래는 먼저 사본에서 재현합니다. 읽기 전용 조사와 운영 변경 권한을 구분하면 인수 과정에서 생긴 문제와 이전부터 있던 문제도 더 정확하게 나눌 수 있습니다.

배포 복원은 저장소의 최신 코드가 실행된다는 사실만 확인해서는 부족합니다. 운영 중인 버전과 빌드 방법, 필요한 라이브러리, 환경 설정, 파일 저장 위치와 정기 작업을 묶어 별도 환경에서 실행해 봅니다. 개인정보나 거래 자료를 사용할 때는 조사 목적에 필요한 범위만 허용하고 노출을 줄입니다. 비밀정보는 보고서나 메신저에 그대로 붙이지 말고 승인된 보관 경로와 교체 책임을 기록하세요.

원장 인수에서는 현재고 한 숫자보다 기준일과 증감 근거를 봅니다. 품목·창고·단위별 기초와 입출고, 예약·보류의 정의, 진행 발주와 미출하 주문을 대조합니다. 음수나 차이가 있으면 개발사가 임의로 맞추는 대신 현업 담당자가 사유를 설명하고 정정안을 승인하도록 합니다. 회계 마감 뒤 변경한 자료가 있다면 어느 보고서와 후속 거래에 영향을 주는지 재무 담당자가 확인합니다. 프로그램 오류와 업무 정정은 기록에서 분리하세요.

정기 작업은 화면에 보이지 않아 놓치기 쉽습니다. 매일 거래 파일을 받는 작업, 외부 시스템에 전송하는 작업, 야간 집계와 백업, 만료되는 인증서나 연동 계정을 목록으로 만듭니다. 실행 주기와 마지막 성공 시각, 실패 연락 대상, 다시 실행해도 중복되지 않는 조건을 확인하세요. 이전 담당자가 직접 처리하던 일을 자동 기능으로 오해하지 않도록 실무자의 하루·주간·월말 작업을 함께 묻는 과정이 필요합니다.

안정화 견적과 기능 추가 견적은 분리합니다. 현행 오류 재현, 문서 보완, 접근 복구, 배포 정리, 원장 대사는 시스템을 유지할 수 있게 만드는 일입니다. 신규 승인 단계와 새 재고 화면은 별도의 변경입니다. 진단에서 발견한 위험을 모두 원래 유지보수 금액에 포함한다고 가정하지 말고, 조사 범위와 수정 우선순위, 변경 승인·재견적 기준을 적으세요. 외부 제품의 지원 종료나 라이선스 교체 비용도 확인되지 않은 항목으로 표시합니다.

새 업체가 모든 업무를 다시 만들어 주겠다는 제안에는 의존 관계를 물어보세요. 발주만 고치려 해도 품목 코드, 입고, 반품, 정산이 이어질 수 있습니다. 현재 원장이 안정적이면 화면이나 주변 모듈부터 교체하는 안을 검토하고, 핵심 데이터 구조가 맞지 않으면 단계 재구축과 전체 교체의 이관 위험을 비교합니다. 기존 개발사 부재는 대안 선택의 조건 중 하나일 뿐 특정 방식의 성공을 보장하는 근거가 아닙니다.

문서와 담당자가 있는 일반 이전은 유지보수 외주 업체 선정에서 비교할 수 있습니다. 인수가 끝난 ERP의 추가 개발은 기존 ERP 확장 개발 기준과 연결하세요. 실제 투입팀과 계약 증거는 ERP 개발 업체 선정 기준을 함께 확인하세요.

다른 운영자가 복원하고 숫자를 따라갈 수 있어야 인수한다#

인수 검수는 회사 계정 접근, 시험 환경 배포, 백업 복원, 대표 거래 조회·처리, 원장 합계 대조로 나눕니다. 각 항목에 수행자와 확인자, 실행 자료와 남은 예외를 기록하세요. 확인할 수 없는 항목은 완료 대신 미확인으로 두고, 업무 중단 가능성과 대응 방법을 써야 합니다. 암호를 전달받았다는 메일이나 소스 파일 목록만으로 인수 완료를 판정하지 않습니다.

복원된 환경에서 승인되지 않은 사용자가 재고 조정을 할 수 없는지, 이미 마감한 거래를 일반 권한으로 고칠 수 없는지 시험합니다. 통신이 끊긴 연동을 재실행했을 때 같은 입고·출고가 두 번 반영되지 않는지도 봅니다. 실패하면 누가 대기 거래를 확인하고 어디서 재처리하는지 운영 문서에 표시하세요. 실제 거래 반영은 고객 승인과 추적 가능한 근거 아래 진행합니다.

고도화 오픈 전에는 변경 동결 시점과 기존·신규 경로를 명확히 합니다. 시험한 배포본과 운영에 올릴 배포본이 같은지 확인하고, 미처리 주문과 발주를 어느 시점의 값으로 옮기는지 결정합니다. 전환 후 원장 차이가 발생하면 신규 입력을 어디서 멈추고 어떤 거래를 보존한 채 되돌릴지 훈련합니다. 서버 프로그램만 과거 버전으로 바꾸면 거래도 저절로 돌아간다고 가정해서는 안 됩니다.

최종 납품물은 자산 목록, 데이터 사전, 배포·복구 절차, 연동 목록, 권한표, 알려진 오류와 미해결 위험, 변경 이력입니다. 새 업체가 없는 자리에서 회사 담당자나 다른 운영자가 문서를 따라 핵심 절차를 재현해 보세요. 결과가 다르면 자료나 권한을 보완한 뒤 다시 확인합니다. 다음 담당자에게도 같은 수준의 인수가 가능하도록 문서 갱신 책임을 유지보수 범위에 넣습니다.