고객 신원
안정적인 ID를 생성할 시스템과 다른 곳에서 업데이트할 수 있는 속성 정의
중복, 합병, 법인, 주소 변경을 어떻게 해결하나요?CRM 대 ERP: 각 비즈니스 레코드를 담당할 시스템 정의
고객 관계 업무를 재무, 재고, 조달, 이행 및 기타 ERP 책임과 비교한 뒤, 한 시스템이 모두 소유하도록 강제하지 말고 인계를 설계
CRM과 ERP는 고객 주문 경계에서 겹칩니다. 가장 안전한 설계는 각 레코드에 하나의 기준 책임자를 두고 인계 과정의 예외를 보이게 하는 것입니다.
- CRM이 관계 맥락을 담당
- ERP가 통제된 거래를 담당
- Jodoo가 시스템 사이의 업무를 조율
CRM과 ERP는 서로 다른 핵심 질문에 답합니다.
한 공급업체가 두 시스템을 모두 판매하더라도 경계를 명확히 해야 합니다.
| 영역 | CRM 책임 범위 | ERP 책임 |
|---|---|---|
| 고객 및 거래처 | 관계 맥락, 이해관계자, 활동, 요구, 영업 기회, 서비스 맥락, 다음 조치 | 청구, 신용, 세금, 이행, 회계에 필요한 고객 마스터 속성 |
| 상업 업무 | 검증, 영업 기회 단계, 관계 약속, 제안 맥락, 예측 입력 | 승인된 품목, 가격, 세금, 신용, 계약, 주문, 배송, 청구서, 결제, 회계 항목 |
| 운영 | 고객 대면 인계, 에스컬레이션, 관계 위험, 커뮤니케이션 이력 | 조달, 재고, 생산, 이행, 자산, 재무, 급여, 법정 통제 |
| 보고 | 파이프라인, 관계 활동, 고객 건전성, 다음 조치, 상업 성과 | 수익 인식, 원가, 마진, 재고 평가, 현금, 부채, 재무 통합 |
모든 공유 레코드에 대한 책임 규칙 작성
각 필드와 실패에 담당자가 없다면 동기화는 거버넌스가 아닙니다.
제품 및 가격
ERP 또는 커머스 시스템이 일반적으로 품목, 가격, 원가, 세금, 가용성을 담당
CRM은 승인된 어떤 상업 맥락을 수정하지 않고 표시할 수 있나요?주문 인계
영업 기회 또는 승인된 요청이 ERP 주문이 되는 시점과 거부를 수정할 담당자 정의
거래를 승인하기 전에 어떤 증빙이 필요한가요?상태 및 예외
기준 이행 및 재무 상태를 반환하면서 고객 후속 조치 책임 유지
실패, 지연, 분쟁 또는 변경된 거래를 누가 확인하고 다음 조치를 하나요?CRM에서 ERP로 이어지는 경로와 실패 대기열 설계
완벽한 도식보다 예외 경로가 중요합니다.
- 01
검증 및 승인
CRM은 요구와 관계 맥락을 기록하고, 필수 상업 검토는 준비 상태를 확인합니다.
- 02
거래 생성
ERP가 통제된 고객, 품목, 가격, 세금, 신용, 주문 데이터를 수용
- 03
기준 상태 반환
고객에게 보여주기 위해 배송, 청구서, 결제, 취소, 신용 상태를 다시 전달
- 04
실패 전달
검증, 중복, 마스터 데이터 누락, 신용, 가용성, 연동 오류가 담당 대기열로 들어감
- 05
고객 조치 완료
관계 담당자는 ERP 기준 정보를 변경하지 않고 결과를 전달하고 다음 조치를 기록합니다.
사람의 워크플로가 CRM 또는 ERP에 완전히 속하지 않을 때 구성 가능 계층 사용
Jodoo를 회계 원장이나 기본 영업 참여 플랫폼처럼 가장해서는 안 됩니다.
거래 생성 전 고객 또는 상업 요청
선택
CRM 및 ERP 주변에 Jodoo 양식, 승인, 증빙, 인계 레코드 사용
피해야 할 사항
검토를 시작하려고 불완전한 ERP 거래를 생성함
팀 간 예외 처리
선택
연동 실패, 데이터 누락, 가격 결정, 이행 문제, 고객 후속 조치 전달
피해야 할 사항
실패한 인계를 이메일로 관리
재무 및 재고 기준 정보
선택
ERP를 원본으로 유지하고 필요한 맥락만 표시
피해야 할 사항
수정 가능한 앱 필드에서 세금, 마진, 평가액 또는 법정 레코드를 다시 계산함
기본 영업 참여 및 예측
선택
패키지 CRM을 원본으로 유지하고 승인된 운영 업무 연결
피해야 할 사항
일반 워크플로 앱에서 전문 영업 기능을 재구축함
CRM이나 ERP를 다시 만들지 않고 예외 경로 조정
두 시스템이 기준 레코드를 유지하면서 팀이 시스템 간 업무를 변경할 수 있을 때 비교가 운영 관점에서 의미를 가집니다.
검증, 승인, 예외, 모니터링에 초점을 둔 변경은 CRM, ERP, 연동, 개발, 릴리스 대기열을 모두 거칠 수 있습니다.
교육받은 관리자는 인계 양식, 승인 경로, 예외 대기열, 담당자 보기, 원본 연계 대시보드를 구성하고 테스트할 수 있습니다.
- ERP 생성 전에 주문 준비 상태 확인 추가
- 거부된 가격 또는 마스터 데이터 누락 사례 전달
- 실패한 인계의 담당자 보기 생성
- 예외 레코드를 여는 대시보드 추가
실용적인 CRM 질문
CRM 소프트웨어와 ERP는 어떻게 다른가요?
CRM은 주로 고객 관계와 상업 업무를 관리합니다. ERP는 주문, 재고, 조달, 생산, 재무, 회계와 같은 통제된 비즈니스 거래와 자원을 관리합니다.
회사에 CRM과 ERP가 모두 필요한가요?
고객 대면 업무와 통제된 거래가 별도 시스템을 정당화할 만큼 깊다면 많은 회사가 두 시스템을 모두 사용합니다. 소규모 팀은 제품군 또는 구성형 플랫폼을 쓸 수 있지만 레코드 책임은 여전히 명확해야 합니다.
Jodoo가 ERP를 대체할 수 있나요?
Jodoo는 구성 가능한 요청, 승인, 레코드, 예외, 대시보드를 운영할 수 있습니다. 단, 제품에서 해당 기능이 정확히 확인되지 않았다면 전문 회계, 재고 평가, 세금, 급여 또는 법정 ERP 통제를 대체하지 않습니다.
Jodoo로 CRM과 ERP 사이의 업무 연결
각 전문 시스템이 기준 데이터를 유지하는 가운데 요청, 승인, 증빙, 인계, 연동 예외, 고객 후속 조치를 조율
- 주문 전 요청 및 승인
- CRM–ERP 예외 대기열
- 시스템 경계를 넘는 운영 워크플로
기준 거래는 ERP에, 관계의 깊이는 CRM에 유지
연동 결정을 피하려고 재무, 재고, 세금, 이행, 예측 또는 고객 참여 논리를 중복 구축하지 마세요.
Jodoo에서 시작
주문 인계 업무 공간 사용