고객 정보 시스템: 중동 방위산업 사례 연구

중동의 한 중견 방위산업 제조사가 고객 정보 시스템을 어떻게 바로잡았는지에 관한 사례 연구입니다. 고객 데이터는 세 곳에 나뉘어 있었고, 견적은 일관성 없는 가격으로 나갔으며, 승인은 이메일 속에서 사라졌습니다. 해법은 Microsoft Dynamics의 단일 고객 레코드, Experlogix CPQ의 규칙 기반 견적, 그리고 승인된 견적을 SAP Cloud Integration을 통해 SAP Sales and Distribution(SD)으로 자동 전달하는 것이었습니다. 견적 소요 시간은 평균 35% 줄었습니다. 영업 기간이 길고, 제품 구성이 복잡하며, 컴플라이언스 요건이 무거운 제조사의 영업 운영, IT, 재무 리더를 위해 쓴 글입니다. 끝부분의 롤아웃 순서와 교훈이 그대로 가져다 쓸 부분입니다.

방위산업 팀이 고객 정보 시스템을 요청할 때는 보통 CRM 이상을 뜻합니다. 구조를 원합니다. 긴 영업 주기, 컴플라이언스 부담이 큰 워크플로, 계속 바뀌는 의사결정자 집단 속에서 복잡한 결정들이 맥락과 함께 모이는 자리입니다.

방위산업 기업에서 디지털 트랜스포메이션 디렉터를 맡고 있던 저는 바로 이 문제를 풀어 달라는 요청을 받았습니다. 문제는 노력 부족이 아니었습니다. 사람들은 일을 하고 있었습니다. 문제는 그 노력이 머물 자리가 없다는 것이었습니다. 공유 플랫폼도, 가시성도 없었고, 판매하는 것과 계획하는 것 사이에 정렬도 없었습니다.

중동의 중견 방위산업 제조사입니다. 무대 뒤에서 움직이는 회사였습니다. 대중 브랜드가 아니었고, 눈에 띄는 것은 목적이 아니었습니다. 이 회사의 부품은 군용 항공과 보안 통신에 쓰였습니다.

모든 판매는 세부적인 경로를 따랐습니다. 엔지니어링 검토, 컴플라이언스 점검, 내부 승인, 버전 관리되는 견적. 혼란스럽지는 않았지만 무거웠습니다.

고객 정보 시스템은 무너지고 있었습니다. 영업은 한 플랫폼을 썼습니다. 지원 부서는 다른 플랫폼을 썼습니다. 운영 부서는 스프레드시트, 오프라인 폴더, 누군가 열기 전에 이미 낡아 버린 문서로 일했습니다.

무엇이 무너져 있었고 그 대가가 무엇이었는지 정리하면 다음과 같습니다.

무엇이 문제였는가	영향
영업 기회 흐름과 의사결정자 파악을 위한 CRM 부재	각 거래가 어디까지 왔는지 공유된 그림이 없음
일관된 기록 없이 수작업으로 처리되는 가격	낡았거나 서로 충돌하는 숫자로 견적이 나감
이메일로 이루어져 자주 사라지거나 지연되는 승인	컴플라이언스 감사 추적이 불완전함
시스템마다 중복되고 세부 내용이 조금씩 다른 고객 레코드	어느 버전이 정확한지 아무도 말할 수 없음

서류상으로는 체계가 잡혀 있었습니다. 하지만 견적 하나를 생성부터 납품까지 따라가 보면 무너졌습니다. 승인은 담당이 불분명해 멈췄습니다. 가격은 누가 견적을 제출하느냐에 따라 달랐습니다. 견적은 이메일 스레드 속에 묻혔습니다. 팀들은 같은 질문을 서로에게 계속 되풀이했습니다. 극적인 실패는 하나도 없었지만, 몇 달에 걸쳐 작은 지연이 쌓였고, 영업 주기가 긴 사업에서는 그렇게 잃은 추진력이 대부분의 사람이 생각하는 것보다 더 큰 타격이었습니다.

목표는 모든 것을 갈아엎는 것이 아니었습니다. 무엇 하나 쓰기 어렵게 만들지 않으면서 마찰을 줄이는 것이었습니다. 사람들을 경직된 프로세스에 억지로 끼워 맞추는 대신, 시스템이 팀이 이미 일하던 방식을 반영하도록 돕는 것입니다.

설정을 건드리기 전에 먼저 팀들과 시간을 보냈습니다. 일이 접수에서 납품까지 어떻게 흘러가는지, 도구가 어디서 방해가 되는지, 사람들이 어디서 데이터를 믿지 않게 되었는지 지켜보았습니다.

그 세션에서 세 가지 우선순위가 나왔습니다.

1. 하나의 공유 고객 레코드를 영업, 지원, 운영이 같은 형식으로 봅니다. 병행 버전은 더 이상 없습니다.
2. 구조화된 견적은 개인의 습관이나 낡은 템플릿 대신 구성과 가격에 대한 일관된 규칙을 따릅니다.
3. 연결된 주문 처리는 승인된 견적이 SAP SD로 깔끔하게 넘어가며 수작업 재입력이 없습니다.

시스템	해결한 것
Microsoft Dynamics CRM	하나의 고객 레코드, 영업 활동 및 영업 기회와 연결
Experlogix Configure Price Quote (CPQ)	제품 구성 규칙, 가격 로직, 견적 버전
SAP Sales and Distribution (SD)	주문 실행과 이행
SAP Cloud Integration (CPI)	CPQ와 CRM을 SAP SD에 연결하는 통합 계층

토대로서의 Microsoft Dynamics. 고객 정보가 정확하고 전체 맥락 속에서 보이는 단일한 자리가 필요했습니다. Dynamics는 엉킨 데이터를 풀기 시작할 자리를 주었습니다. 플랫폼에 대한 익숙함이 도움이 되었고, Outlook 및 Teams와의 궁합도 도움이 되었습니다. 사람들에게 처음부터 다시 시작하라고 요구하지 않았고, 비즈니스가 일하는 방식에 맞추는 조정만 필요했습니다. 팀들이 부서를 가로질러 같은 데이터를 같은 형식으로 보게 되자 신뢰가 쌓이기 시작했습니다.

구성과 가격을 위한 Experlogix CPQ. 이전에는 견적이 너무 다양한 방식으로 작성되었습니다. 사람들은 기억과 수작업 수정에 의존했습니다. 저희는 Experlogix에 제품 조합 규칙, 구성에 연동된 가격, 거래 유형과 금액에 따른 승인 라우팅을 정의해 설정했습니다. 처음에는 제약처럼 느껴졌고 그렇게 말하는 사람도 적지 않았지만, 모호함이 사라졌습니다. 엔지니어링은 더 깔끔한 견적을 받았고, 영업은 지난 거래의 기억에 의존해 가격을 고치는 일을 그만두었습니다.

SAP CPI를 통한 SAP SD. 주문 처리에는 이미 SAP SD를 쓰고 있었습니다. 빈틈은 인계 단계였습니다. 승인된 견적을 여전히 SAP에 다시 입력해야 했습니다. 저희는 둘을 SAP CPI로 연동해서, 승인된 견적이 주문으로 SAP에 곧바로 들어가고 고객 및 주문 데이터가 Dynamics와 SAP 사이에서 동기화되도록 했습니다. 한계에 부딪힌 곳에서는 맞춤 로직을 추가했습니다. 모든 경우에 우아하지는 않았지만, 작동했습니다.

1. 01고객 레코드Microsoft Dynamics, 모든 팀이 보는 하나의 버전
2. 02구성 및 가격 산정조합과 가격을 위한 Experlogix CPQ 규칙
3. 03승인거래 유형과 금액에 따라 라우팅
4. 04주문 생성SAP CPI가 승인된 견적을 SAP SD로 전달
5. 05이행SAP SD, 고객 데이터는 동기화 유지

재입력이 없고, 승인부터 주문까지 감사 추적이 남습니다

롤아웃은 약 6~8개월에 걸쳐 단계적으로 진행했습니다. 극적인 것은 없었습니다. 변경을 겹겹이 쌓고, 단계마다 검증했습니다.

1. 파일럿. 소규모 사용자 그룹과 구체적인 시나리오로 CRM과 CPQ에 집중했습니다. 확장하기 전에 예외 사례를 테스트하고 빈틈을 드러내 수정했습니다.
2. 데이터 정리. 고객 레코드는 Dynamics에 들어가기 전에 통합하고 중복을 제거했으며, 컴플라이언스 문서를 올바른 영업 기회에 연결했습니다. 이 작업은 설정보다 오래 걸렸습니다.
3. 부서 전반으로 확장. 파일럿 워크플로를 다듬은 뒤 영업, 지원, 운영으로 확대했습니다.
4. 중간에 SAP SD 연동. CPQ와 SAP의 연동은 앞단 시스템이 안정된 뒤에 가동했으므로, 초기 문제가 주문으로 번지지 않았습니다.

보안과 컴플라이언스는 첫날부터 설계에 반영했습니다. 방위산업 고객에게 감사 추적의 무결성과 역할 기반 접근 제어는 선택 사항이 아닙니다. 저희는 접근 역할을 명확히 정의하고 승인 이력을 추적했습니다. 데이터 거주 요건은 초기에 정리했습니다. 모든 데이터는 방위 부문 규정에 따라 UAE 안에 머물렀습니다. 그 때문에 초반에는 속도가 약간 느려졌지만, 나중에 더 심각한 문제가 생기는 것을 막았습니다.

교육은 실용적이었습니다. 짧은 세션, 대상에 맞춘 자료, 라이브 시연, 사용법 영상을 한 번에 몰아서가 아니라 몇 주, 몇 달에 걸쳐 이어 갔습니다. 처음에는 도입이 완벽하지 않았습니다. 꾸준한 지원과 눈에 보이는 이점이 초기의 망설임을 이겨 냈습니다. 전환점은 팀들이 실제 상황에서 도구를 써 보고 돌아온 데이터가 정확하다는 것을 확인했을 때 찾아왔습니다.

성과	달라진 점
견적 소요 시간	평균 35% 감소. 많은 거래에서 몇 시간, 복잡한 거래에서는 며칠이 단축됨
구성 정확도	검증 규칙이 오류가 엔지니어링에 닿기 전에 막음
감사 준비 상태	컴플라이언스 점검에 더 이상 막판 부랴부랴가 필요하지 않음
팀 간 정렬	영업, 지원, 운영이 같은 고객 레코드로 일함

35% 단축은 첫 주에 나온 것이 아닙니다. 초기 주기에는 여전히 확인과 정정이 따랐습니다. 제품 규칙과 가격 로직이 일관되자 견적이 빨라졌습니다. 영업 담당자는 더 이상 승인을 쫓아다니거나 재사용하던 템플릿을 고치지 않았습니다. 시스템이 그 단계를 처리했습니다.

기술보다 정렬이 더 중요합니다. 기술적인 구축은 쉬운 쪽이었습니다. 팀들이 하나의 기준 데이터를 신뢰하고 각자 자기 레코드를 관리하는 일을 멈추게 하는 것이 더 어려웠습니다. 사람들에게 의존하라고 요청하기에 앞서 데이터가 믿을 만하다는 것을 먼저 보여 주어야 했습니다.

기능보다 연동의 세부 사항이 더 중요합니다. 전체 시스템을 가치 있게 만든 것은 CPQ와 SAP SD의 연동이었습니다. 독립형 CRM과 독립형 견적에 수작업 주문 입력이 더해진 구조였다면 각각 조금씩만 도움이 되었을 것입니다. 마찰이 사라진 곳은 그 둘 사이의 연결이었습니다.

지원과 교육이 정착시킵니다. 배포해 놓고 방치하는 것은 납품이 아닙니다. 교육은 Go-Live 이후에도 몇 주, 몇 달 동안 이어졌고, 도입이 뿌리를 내리느냐 풀려 버리느냐는 바로 그 기간에 갈립니다.

아키텍처는 여전히 유효합니다. 고객 레코드는 CRM, 구조화된 견적은 CPQ, 주문 처리는 ERP 연동입니다. 같은 프로젝트를 지금 시작한다면 세 가지가 달라질 것입니다.

통합 플랫폼. SAP CPI는 이제 SAP Integration Suite 안의 Cloud Integration 기능으로, API 관리, 이벤트 기반 통합, 사전 구축된 통합 콘텐츠와 함께 제공됩니다. Dynamics에서 CPQ, SAP SD로 이어지는 흐름은 오늘이라면 설계 시간이 더 적게 들 것입니다. 이 플랫폼은 SAP Cloud Integration 가이드에서 다룹니다.

SAP의 자체 CRM도 후보 목록에 올라갈 것입니다. SAP SD가 백엔드라면, 새 프로젝트에서는 이제 Joule을 포함하는 SAP Sales Cloud를 Microsoft Dynamics와 비교해야 합니다. 이 사례에서는 기존의 익숙함 때문에 Dynamics가 옳은 선택이었습니다. 답은 여전히 기능과 연동에 대한 선호에 달려 있지만, SAP 네이티브 옵션은 예전보다 훨씬 설득력 있는 후보가 되었습니다. 선택지는 SAP용 CRM 시스템 비교에서 다룹니다.

미국 연방 범위에는 다른 호스팅 모델이 필요합니다. 이 고객에게는 필요 없었지만, 미국 연방 사업이 있는 방위산업 기업이라면 SAP National Security Services(SAP NS2)를 검토할 것입니다. SAP NS2는 2025년에 미국 내 운영만으로 S/4HANA Cloud Private Edition과 SAP BTP를 FedRAMP+ Impact Level 5 수준에서 운영할 수 있는 잠정 승인을 받았습니다.

방위산업 특유의 요구 사항(감사 추적, 역할 기반 접근 제어, 견적 버전 관리, 데이터 거주 요건)은 플랫폼 세대와 상관없이 적용됩니다. 컴플라이언스의 더 넓은 그림은 공공 부문의 SAP 컴플라이언스 가이드를 참고하십시오.

다른 CRM 플랫폼이 아니라 Microsoft Dynamics를 선택한 이유는 무엇입니까?

리드에서 영업 기회, 판매 후 관리에 이르는 전체 고객 라이프사이클을 관리할 수 있었고, 방위산업 영업의 길고 복잡한 거래 주기도 감당할 수 있었습니다. Outlook 및 Teams와의 궁합이 도입에 도움이 되었고, 팀이 이미 익숙했다는 점이 진입 장벽을 더 낮추었습니다.

컴플라이언스 부담이 큰 고객에게는 접근 제어, 감사 로깅, 유연성, 확장 여지가 또 다른 결정 요인이었습니다.

Experlogix CPQ는 어떤 역할을 했고, 애초에 왜 CPQ가 필요했습니까?

방위산업 제품에는 복잡한 구성 규칙이 있습니다. 가격표만으로는 제품 변형, 컴플라이언스 요건, 고객별 조건 사이의 상호작용을 담을 수 없습니다. CPQ가 없으면 모든 견적이 작성자가 규칙을 알고 있는지에 달려 있었습니다.

Experlogix가 그 규칙을 견적 도구 안에 넣었습니다. 영업 담당자는 며칠 뒤 엔지니어링의 정정을 받는 대신, 견적을 작성하는 동안 검증 피드백을 받았습니다. 오류가 고치는 비용이 싼 앞단으로 옮겨 갔습니다.

SAP SD는 CRM 및 CPQ와 어떻게 연동했습니까?

SAP CPI가 미들웨어 역할을 했습니다. Experlogix에서 견적이 승인되면 플로가 시작되어 올바른 품목, 가격, 고객 데이터와 함께 SAP SD에 주문이 생성되었습니다. CPI는 또한 Dynamics와 SAP 사이에서 고객 및 주문 데이터를 동기화했고, 검증 규칙으로 불일치 데이터를 차단했습니다.

이전에는 누군가가 승인된 견적을 일일이 손으로 SAP에 옮겨 적었습니다. 이를 자동화하자 재입력 오류가 사라졌고 승인부터 주문까지 깔끔한 감사 추적이 만들어졌습니다.

구축 과정에서 가장 큰 어려움은 무엇이었습니까?

첫째는 데이터 품질입니다. 고객 데이터가 부서마다 일관되지 않았고 중복과 누락된 필드가 있어서, Dynamics가 기준 데이터가 되려면 먼저 정리해야 했습니다.

둘째는 연동 매핑이었고, 특히 세 시스템에 걸친 제품 구성과 가격이 어려웠습니다. 셋째는 영업, 엔지니어링, IT, 재무를 정렬하는 일이었으며, 특히 프로세스 일부의 담당이 바뀔 때 그랬습니다.

보안과 컴플라이언스는 어떻게 다루었습니까?

첫날부터 설계에 반영했습니다. 모든 구성 요소가 내부 보안 정책과 국가 규정을 충족해야 했습니다. 역할 기반 접근 제어로 누가 어떤 레코드를 보고 바꿀 수 있는지를 제한했습니다. 견적, 승인, 데이터 변경 전반에 완전한 감사 추적을 남겼습니다. 모든 데이터는 방위 부문 규정에 따라 UAE 안에 머물렀습니다.

설계가 그 요구 사항에서 출발했기 때문에, 컴플라이언스 검토가 돌아왔을 때 데이터는 이미 올바른 형태를 갖추고 있었습니다.

롤아웃에는 얼마나 걸렸습니까?

약 6~8개월이 걸렸고 단계적으로 진행했습니다. CRM과 CPQ에 집중한 파일럿으로 시작해, 피드백을 반영한 뒤 부서 전반으로 확장했고, 앞단 시스템이 안정된 시점에 SAP SD 연동을 중간에 추가했습니다. 교육, 지원, 튜닝은 내내 이어졌습니다.

이 모델을 다른 방위산업 또는 제조 기업에도 적용할 수 있습니까?

그렇습니다. 영업 주기가 길고, 제품 구성이 가능하며, 컴플라이언스 문서가 필요한 곳이면 어디든 가능합니다. 항공우주, 산업 장비, 그리고 견적이 나가기 전에 엔지니어링의 검증이 필요한 모든 사업이 해당합니다.

구체적인 도구보다 연동 로직이 더 중요합니다. 승인된 견적은 재입력 없이 ERP로 흘러 들어가야 하고, 고객 레코드는 단일한 기준 데이터여야 합니다.