CRM·회계·주문 시스템 연동 견적은 무엇에 따라 달라질까?

같은 CRM, 주문 시스템, 회계 소프트웨어를 연결한다는 견적이라도 두 업체가 말하는 작업은 크게 다를 수 있습니다. 한 업체는 새 주문만 보내고, 다른 업체는 고객 정보 대조, 회계 상태 회신, 이후 변경 처리와 과거 기록 반영까지 포함할 수 있습니다.

견적을 비교하려면 주문 한 건이 어떻게 처리되어야 하고 누가 결과를 확인할지 적어 보세요. 시스템의 개수는 작업이 어디에서 일어나는지 보여 줍니다. 실제로 무엇을 만들어야 하는지는 시스템 사이의 규칙이 결정합니다.

주문 한 건의 흐름을 따라가 보기

가상의 도매업체를 생각해 보겠습니다. 영업팀은 CRM에 고객 연락처를 보관하고, 직원은 주문 시스템에서 주문을 접수하며, 재무팀은 별도의 회계 소프트웨어를 사용합니다. 이 업체는 접수된 주문을 바탕으로 재무팀이 검토할 문서 초안을 만들고 싶습니다.

주문 ORD-204를 예로 들어 보겠습니다. 고객의 CRM 식별자는 C-81, 회계 시스템의 고객 계정 번호는 A-347입니다. 누군가는 두 식별자가 같은 고객을 가리키는지 확인해야 합니다. 회사 이름만으로 대조하면 이름이 바뀌거나 비슷한 기록이 둘일 때 판단할 기준이 남습니다.

다음으로 각 정보의 기준이 되는 시스템을 정합니다. 연락처 이름은 CRM에서, 승인된 청구 정보는 회계에서 가져올 수 있습니다. 접수된 수량과 합의한 가격은 주문 시스템을 기준으로 삼을 수도 있습니다. 이는 예시를 위한 가정이며 실제 규칙은 해당 업체가 합의해야 합니다.

‘접수됨’의 의미도 정해야 합니다. 영업팀이 주문을 접수했다고 해서 재무팀이 만들어진 문서를 승인한 것은 아닙니다. Microsoft의 Dynamics 365 Sales 문서는 견적, 주문, 청구서를 별도 단계로 다뤄 이 차이를 보여 줍니다. 이는 한 제품의 절차입니다. 실제 연동 규칙은 사용 중인 소프트웨어와 업무에 맞아야 합니다.

같은 세 시스템, 다른 작업 범위

가상의 도매업체에 적용할 수 있는 범위 세 가지입니다. 실제 제품이 필요한 작업을 지원한다는 전제에서, 범위가 넓어질수록 정의하고 구현하고 확인할 일이 늘어납니다.

작은 범위로도 충분할 수 있습니다. 그 경우 수작업을 제안서에 명시해 구매자가 그 방식이 적절한지 판단할 수 있게 해야 합니다. 더 넓은 범위라면 추가되는 데이터 흐름과 결정 사항을 분명히 적어야 합니다.

견적에 사용할 연동 경로 정리하기

주문에서 회계로 가는 흐름부터 시작해 발생 조건을 적습니다. 예를 들면 ‘주문 시스템에서 주문이 접수된 상태가 된다’입니다. 주문 식별자와 고객 식별자의 대응 관계를 기록합니다. 옮길 필드를 나열하고, 해당한다면 수량, 할인, 통화, 상태를 각각 어떻게 해석할지도 적습니다. 회계 처리 방식은 담당자와 합의해야 합니다.

도착 시스템에서 무엇을 할지도 지정합니다. 초안을 만들지, 변경 가능한 초안을 수정할지, 재무팀에 확인 건을 보낼지 정합니다. 누가 승인할 수 있는지도 명시합니다. 예상 처리 시간과 미완료 전송을 조사하기 시작할 시점을 정하세요. ‘정기적으로’보다는 합의된 업무 기한이 견적을 내는 데 도움이 됩니다.

돌아오는 흐름도 각각 설명합니다. 회계 시스템에서 문서 식별자를 돌려주는 것과 결제 상태를 돌려주는 것은 별개의 작업입니다. 어느 쪽도 두 시스템의 모든 고객 필드나 문서를 양쪽에서 수정할 수 있다는 뜻은 아닙니다.

시스템 간 의미 변환에 관한 Microsoft 가이드는 데이터 의미가 다를 때 의도적인 처리가 필요한 이유와 유지보수 및 모니터링을 고려해야 하는 이유를 설명합니다. 이 문서는 하나의 설계 패턴을 소개할 뿐, 모든 연동에 그 패턴을 적용하라고 요구하지는 않습니다. 견적에서는 비슷한 필드 이름을 같은 의미로 간주하지 말고 필요한 변환 작업을 명시해야 합니다.

결과를 누가 어떻게 확인할지 합의하기

각 흐름마다 완료 기준을 기록합니다. 메시지를 보냈다는 사실만으로 올바른 고객과 금액으로 초안이 만들어졌는지 알 수는 없습니다. 출발지와 도착지의 관련 기록을 어떻게 대조하고, 누락이나 불일치를 어떻게 찾고, 조사에 필요한 식별자를 어디서 확인할지 합의합니다.

예외를 처음 받는 담당자나 팀, 확인할 수 있는 정보, 원본 기록을 수정하거나 재시도를 승인할 사람을 정합니다. 알 수 없는 고객, 거부된 필드, 검토 후 도착한 수정 사항 같은 사례를 포함하세요. 직원이 수동으로 처리할 경우도 결정합니다.

이렇게 정리해야 연동 경로를 실제 견적에 사용할 수 있습니다. 발생 조건, 기준 정보, 식별자, 방향, 필드의 의미, 도착지 작업, 처리 시간, 완료 확인, 예외 담당자가 들어갑니다. 테스트 계정을 제공할 사람과 결과를 승인할 사람도 적으세요.

과거 데이터의 범위 정하기

‘오래된 주문도 포함’이라는 말만으로는 부족합니다. 기록의 종류와 기간, 필요한 관련 고객 기록을 정하고, 대조와 정리를 맡을 사람을 지정합니다. 가져온 뒤 무엇을 확인할지도 적습니다.

이 일회성 작업은 지속적인 전송과 구분합니다. 과거 데이터가 어디까지이고 운영 중 처리가 어디서 시작되는지, 인계 기간의 변경은 어떻게 반영할지 합의합니다. 그렇지 않으면 두 업체 모두 ‘데이터 가져오기’라고 적어도 준비와 확인 작업의 양이 다를 수 있습니다.

전제 조건과 지속적인 작업 비교하기

각 업체에 같은 연동 경로를 기준으로 견적을 요청하세요. 제품 버전, 허용되는 작업, 권한, 인터페이스 제한, 커넥터 조건에 대해 확인한 내용과 아직 확인할 내용을 구분해 달라고 하세요. API 목록이나 커넥터 로고만으로는 우리 계정에서 필요한 작업을 할 수 있는지 알 수 없습니다.

접근 권한이 없거나 규칙이 미정이라면, 그 불확실성을 어떻게 해소하고 제안에 어떤 영향을 주는지 물어보세요. 영국 정부의 애자일 계약 지침은 공공 조달에서 정보 부족이 계약 선택에 미치는 영향을 다룹니다. 여기서 얻을 수 있는 실용적인 교훈은 두 제안을 같은 약속으로 보기 전에 전제를 드러내야 한다는 점입니다.

초기 설정과 테스트는 정기적인 소프트웨어 또는 커넥터 구독료와 구분합니다. 그런 다음 자격 증명 관리, 미완료 전송 확인, 필드 대응 관계 수정, 제품 변경에 따른 호환성 대응 등 합의할 운영 및 유지보수 작업을 적습니다. 무엇이 포함되고 누가 맡으며 이후 변경을 어떻게 합의할지 확인하세요. 구독료 항목만으로는 이런 책임을 알 수 없습니다.

마지막으로 ORD-204가 각 제안에서 어떻게 처리되는지 따라가 보세요. 무엇이 언제 도착하고, 완료되지 않으면 어떻게 되며, 누가 이어서 처리하는지 보이나요? 차이가 있다면 총액을 비교하기 전에 작업 범위로 논의해야 합니다.

범위가 정해진 연동을 LINK-V와 논의하고 싶다면 API 연동 서비스에서 시작할 수 있습니다. 데이터 흐름과 미해결 질문을 가져오세요. 구체적인 범위와 지속적인 관리는 프로젝트별로 합의합니다.

연동 견적에 관한 질문