Zafin Naehas 인수, 은행 가격 책정과 고객 오퍼 간의 간극을 겨냥하다

Zafin은 Naehas 인수에 합의하며, 가격 책정 결정과 고객 오퍼 사이에 놓인 승인 및 공시 영역으로 뱅킹 소프트웨어 사업의 범위를 확장하고 있다. Zafin Naehas 인수는 이 여정의 더 많은 부분을 동일한 소유 체계 아래 연결하게 된다. 다만 양사는 2026년 10월 26일 거래 완료가 아닌 최종 계약 체결을 발표했다.

전략적 쟁점은 실행에 있다. 은행은 매력적인 상품을 설계하고도 마케팅, 고객 서비스, 계좌 운영 전반에 걸쳐 조건을 일관되게 제공하는 데 어려움을 겪을 수 있다. 이러한 연결을 관리하는 소프트웨어를 인수하면 Zafin은 프로세스에서 더 폭넓은 역할을 맡게 된다. 동시에 이는 AI 기능 추가를 넘어서는 통합 과제를 만든다.

은행 구매자에게 중요한 비교 기준은 연결된 실행 체계와 개별 시스템 간 조정이다. Temenos는 폭넓은 뱅킹 포트폴리오로 경쟁하며, Adobe는 이미 문서화된 Naehas 구축 사례에 참여하고 있다. 이러한 접근 방식은 구매 맥락을 보여준다. 은행은 상품 규칙이 어디에 존재할지, 오퍼가 고객에게 어떻게 전달될지, 어떤 시스템이 책임성을 유지할지를 결정해야 한다.

Zafin Naehas 인수가 실제로 바꾸는 것

이번 계약은 은행 의사결정에서 이를 전달하고 이행하는 데 필요한 업무로 Zafin의 목표 범위를 확장한다.

양사의 인수 계약 발표에 따르면, Naehas는 오퍼 관리, 공시 자동화, 마케팅 컴플라이언스 기술을 제공한다. 오퍼 관리는 고객 제안의 배경이 되는 규칙과 활동을 조율한다. 공시 자동화는 해당 제안에 수반되는 필수 설명과 조건을 관리한다.

Zafin은 통상적인 조건과 필요한 규제 승인을 전제로 거래가 2026년 4분기에 마무리될 것으로 예상한다. 거래 종결 전까지 두 사업은 독립적으로 운영을 계속한다. 기존 구축 환경의 조달 결정을 검토하거나 변경을 계획하는 고객에게 이 구분은 중요하다.

발표문은 Naehas를 Zafin의 뱅킹, 통합, AI 오케스트레이션 플랫폼과 함께 제시한다. 오케스트레이션은 소프트웨어, 도구, 사람 간의 업무를 조율하는 것을 의미한다. Zafin은 이 결합을 규제 대상 기관 전반에서 더 많은 활동을 지원하는 방법으로 설명한다.

따라서 즉각적인 변화는 전략적 범위다. 구매자는 이를 제공 완료된 제품 통합, 완료된 마이그레이션 또는 입증된 캠페인 성과 개선과 구분해야 한다. 계약은 의도된 소유 구조를 정하지만, 구현이 고객이 실제로 사용할 수 있는 것을 결정한다.

예를 들어 은행 예금 프로모션을 생각해 보자. 상품 관리자는 조건을 정의하고, 마케팅 부서는 메시지를 개발하며, 검토자는 공시를 승인하고, 운영 시스템은 고객 자격을 판단한다. 각 활동은 개별적으로 정확히 작동할 수 있지만 전체 프로세스는 여전히 느릴 수 있다.

더 넓은 공급업체 포트폴리오는 이러한 인계 절차를 줄일 기회를 만든다. 상품 정보는 반복적인 수동 해석 없이 오퍼 준비 단계로 이동할 수 있다. 승인 결정은 배포되는 정확한 조건과 계속 연결될 수 있다. 이는 거래 발표만으로 확정된 결과가 아니라 잠재적인 통합 이점이다.

은행이 이미 중복되는 제품을 사용하고 있을 때 이러한 구분은 특히 중요해진다. 고객사는 기존 마케팅 소프트웨어와 내부 승인에 의존하는 정상 작동 중인 오퍼 프로세스를 갖추고 있을 수 있다. 소유권 통합이 그 프로세스를 교체할 가치가 있음을 자동으로 의미하지는 않는다.

유용한 평가는 은행이 개선하려는 업무에서 시작한다. 팀이 여러 시스템에서 상품 조건을 반복적으로 대조한다면 더 긴밀한 연결에 주목할 만하다. 병목이 내부 권한이나 해결되지 않은 정책에 있다면 소프트웨어 통합만으로는 지연의 상당 부분이 남는다.

이 때문에 이번 인수는 운영 워크플로에 관한 논의에 속한다. AI는 포지셔닝의 일부를 제공하지만, 실제 범위에는 콘텐츠, 권한, 승인, 전달, 증거가 포함된다. 사업성은 각 기관 내부에서 이러한 요소들이 어떻게 연결되는지에 달려 있다.

기존 고객에게는 연속성에 관한 질문이 우선 중요하다. 어떤 계약이 유지되는가? 기존 통합은 누가 지원하는가? 양사는 언제 통합 제품 로드맵을 설명할 것인가? 명확한 답변은 구매자가 단기 의무와 장기 기회를 구분하는 데 도움이 된다.

은행 팀은 인계 지점에서 압박을 받는다

가장 직접적인 영향을 받는 팀은 상품 결정을 정확한 고객 경험으로 전환할 책임이 있는 팀이다.

상품 리더에게 압박은 일관성과 관련된다. 상품 정의는 홍보 문구, 자격 확인, 서비스 지침으로 이동하는 과정에서도 유지되어야 한다. 불일치가 발생하면 오퍼가 진행되기 전에 또 한 차례의 해석 과정이 필요해진다.

마케팅 팀에게 쟁점은 활용 가능한 권한이다. 이들은 기본 약속을 실수로 변경하지 않으면서 캠페인을 조정할 여지가 필요하다. 승인된 변경은 더 쉽게 만들고 승인되지 않은 변경은 드러나게 하는 워크플로일수록 가치가 높다.

컴플라이언스 팀은 다른 제약에 직면한다. 더 빠른 제작은 검토가 필요한 자료의 양을 늘릴 수 있다. 자동화는 검토자가 변경되지 않은 콘텐츠를 반복 확인하는 대신, 의미 있는 변경을 식별하고 승인 이력을 추적할 수 있을 때 제 역할을 한다.

운영 팀은 출시 이후의 결과를 떠안는다. 캠페인에서 정확해 보이는 오퍼도 자격을 갖춘 고객에게 기대한 결과를 제공해야 한다. 따라서 이행, 즉 약속된 혜택의 제공은 동일한 운영 문제의 일부다.

이 논의에는 구체적인 구현 사례가 있다. Capgemini는 Naehas와 Adobe를 개인화 오퍼 플랫폼에 활용한 북미 은행을 설명한다. Naehas는 오퍼 생성 허브 역할을 했고, Adobe는 오퍼 데이터와 고객 경험 이벤트를 처리했다.

Capgemini는 오퍼 생성 시간 60~70% 단축과 승인 시간 75% 단축을 보고했다. 이 수치는 해당 특정 구현 사례를 설명한다. 이는 제안된 Zafin 결합에 대한 독립적인 측정치가 아니라 파트너가 보고한 결과다.

이 사례가 중요한 이유는 개선이 아키텍처와 구현 작업을 수반했기 때문이다. 오퍼 준비를 고객 경험을 제시하는 데 사용되는 시스템과 연결했다. 따라서 보고된 성과는 적절한 한계 아래 조율된 실행이 달성할 수 있는 수준의 참고점을 제공한다.

또한 이는 구매자가 결정을 기능 비교로 축소해서는 안 되는 이유를 보여준다. 워크플로는 이를 둘러싼 시스템, 사람에게 부여된 책임, 단계 간 이동하는 정보의 품질에 따라 달라진다.

유사한 변화를 검토하는 은행은 지연이 실제로 어디에 축적되는지 파악해야 한다. 검토자를 기다리는 일은 누락된 상품 정보를 기다리는 일과 다르다. 잘못된 공시를 수정하는 일은 통합 장애를 해결하는 일과 다르다. 각 문제는 서로 다른 해결책을 시사한다.

조직적 압박은 이러한 진단에서 비롯된다. 비즈니스 리더는 설계부터 전달까지 오퍼의 책임자가 누구인지 정의해야 한다. 기술 팀은 각 결정을 어떤 시스템이 통제하는지 정해야 한다. 검토자는 예외를 처리할 합의된 방법이 필요하다.

이러한 결정이 없다면 더 폭넓은 플랫폼은 기존의 분절된 프로세스를 다른 인터페이스 안에서 재현할 수 있다. 반대로 결정이 갖춰진다면 통합은 직원들이 이전에 메시지, 스프레드시트, 반복 회의를 통해 처리하던 조정 업무를 줄일 수 있다.

이로써 이번 인수는 마케팅 부서를 넘어 엔터프라이즈 구매자에게도 중요해진다. 구매 결정은 상품 운영, 아키텍처, 고객 서비스, 리스크 관리에까지 영향을 미친다. 이들 그룹은 제안된 결합을 평가하기 전에 성공에 대한 공동의 정의를 마련해야 한다.

가격 책정과 오퍼를 연결하려면 공유 규칙이 필요하다

핵심 메커니즘은 상품 결정이 팀과 시스템을 거쳐 이동하는 과정에서 그 의미를 보존하는 것이다.

고객과 기관의 더 폭넓은 관계를 기준으로 결정되는 인센티브인 관계 기반 뱅킹 오퍼를 상상해 보자. 자격은 계좌 보유 현황, 적격 활동 또는 기타 승인된 조건에 따라 달라질 수 있다. 정확한 조건은 오퍼의 전 생애주기에 걸쳐 일관되게 유지되어야 한다.

마케팅 문구는 이러한 조건을 표현하는 하나의 방식일 뿐이다. 은행에는 대면 직원용 지침, 디지털 채널용 규칙, 혜택 제공을 위한 로직도 필요하다. 이러한 표현이 서로 엇갈리면 추가 자동화는 불일치를 더 빠르게 배포할 수 있다.

연결된 워크플로는 현재 조건과 그 이력 모두를 보존해야 한다. 직원은 어떤 버전이 승인을 받았고 어떤 버전이 고객에게 전달되었는지 판단할 수 있어야 한다. 운영 중인 오퍼를 업데이트한다고 해서 이전 결정의 근거가 사라져서는 안 된다.

이는 Zafin과 Naehas에 실질적인 통합 질문을 제기한다. 권위 있는 상품 및 오퍼 정의는 어디에 존재하게 될 것인가? 공동 소유는 이 질문을 해결할 기회를 제공하지만, 기술적 답을 확정하지는 않는다.

구매자는 변경 사항이 시스템 간에 어떻게 이동하는지도 물어야 한다. 가격 책정 업데이트에는 수정된 공시, 재승인 또는 배포 중단이 필요할 수 있다. 워크플로는 모든 업데이트를 동일하게 처리하지 않고 이러한 상황을 구분해야 한다.

AI는 또 다른 책임 계층을 도입한다. AI 에이전트는 모델과 도구를 활용해 작업을 수행하는 소프트웨어다. 뱅킹 워크플로에서 초안을 생성하는 일과 그 공개를 승인하는 일에는 서로 다른 권한이 필요하다.

Zafin의 2026년 6월 23일 에이전트 오케스트레이션 플랫폼 발표는 에이전트 접근, 도구 사용, 인간의 권한, 증거에 대한 통제를 설명한다. 회사는 AIOS가 업무 진행 방식과 적용되는 통제를 기록한다고 말한다.

이러한 포지셔닝은 인수의 전략적 적합성을 설명하는 데 도움이 된다. 오퍼 준비에는 자동화가 지원할 수 있는 업무와 명확한 권한이 필요한 결정이 함께 존재한다. 두 요소를 연결하려면 소프트웨어가 제안, 수정, 승인, 게시할 수 있는 범위에 대한 명시적 경계가 필요하다.

예를 들어 보조 도구는 승인된 조건과 캠페인 초안 간의 불일치를 식별할 수 있다. 불일치를 표시하면 검토 작업이 생성된다. 캠페인을 자동으로 수정하고 공개하는 일은 별도의 권한 수준을 의미한다.

정보가 불완전할 때도 같은 구분이 적용된다. 시스템은 그럴듯한 문구로 빈틈을 채우기보다 중단하고 결정을 요청할 수 있어야 한다. 규제 대상 커뮤니케이션에서 불확실성에는 책임자가 필요하다.

이는 구매자가 현실적인 시나리오로 검증할 수 있는 설계 요건이다. 공급업체의 광범위한 AI 서사를 받아들일 필요는 없다. 데모는 승인되지 않은 변경이 중단되는지, 예외가 올바른 사람에게 도달하는지, 증거에 계속 접근할 수 있는지를 보여줄 수 있다.

이번 Zafin의 Naehas 인수에 대한 해석 중 가장 중요한 것은 이것이다. 그 가치는 오퍼 프로세스 전반에서 의사결정과 책임 소재를 연결하는 데 달려 있다. 콘텐츠를 더 많이 생성하는 것만으로는 이 과업의 일부만 해결할 수 있다.

기존 플랫폼이 경쟁 기준을 설정한다

Zafin은 기존 뱅킹 스위트 및 특화 소프트웨어의 검증된 조합과 경쟁하게 된다.

Temenos는 폭넓은 스위트 접근 방식을 이해하는 데 유용한 참고 사례다. Temenos의 뱅킹 제품 포트폴리오는 코어 뱅킹과 기타 금융 서비스 역량을 포괄한다. 코어 뱅킹 소프트웨어는 핵심 계좌 및 거래 기록을 관리한다.

이 비교는 동일한 제품을 비교한다기보다 구매 범위에 관한 것이다. Zafin과의 관계를 더 폭넓게 검토하는 은행은 계좌 운영, 디지털 경험, 재무 통제를 이미 담당하는 시스템과 Zafin이 어떻게 조화를 이루는지 평가하게 될 것이다.

폭넓은 포트폴리오는 상업적 책임의 창구를 더 명확하게 제공할 수 있다. 구매자는 협상 횟수를 줄이고 더 긴밀하게 조율된 지원을 선호할 수 있다. 다만 기반 제품들이 정보와 워크플로를 효과적으로 공유하는지는 여전히 확인해야 한다.

특화 접근 방식은 다른 장점을 제공한다. 은행은 특정 요구사항을 이미 충족하는 소프트웨어를 유지하면서 다른 시스템과 연결할 수 있다. 이는 선택권을 보존하지만, 누군가는 통합 책임을 맡아야 한다.

Capgemini 사례에서 Adobe의 역할은 이 두 번째 경로를 보여준다. Naehas는 이미 다른 엔터프라이즈 플랫폼을 포함하는 아키텍처에 참여하고 있다. 따라서 이번 인수는 기존 의존성과 파트너십의 네트워크 안으로 들어가게 된다.

Zafin에게는 자체 포트폴리오 내 연결을 더욱 긴밀하게 만드는 것만큼 이러한 관계를 유지하는 일도 중요할 수 있다. 고객은 마케팅 환경을 교체하거나 모든 고객 채널을 재구축하지 않으면서도 더 나은 조율을 원할 수 있다.

여기서 구체적인 경쟁 기준이 나온다. 제안된 조합은 은행이 이미 운영 중인 환경을 수용하면서 얼마나 많은 업무를 덜어낼 수 있는가? 모든 연결에 여전히 상당한 맞춤형 조율이 필요하다면, 더 폭넓은 제품 카탈로그는 제한적인 안심만 제공한다.

구매자는 완전한 운영 시나리오를 비교해야 한다. 오퍼를 출시하는 것은 하나의 시나리오다. 승인 후 이를 수정하는 것은 또 다른 시나리오다. 분쟁이 있는 혜택을 고객에게 설명하는 일은 서로 다른 정보 요구사항을 가진 또 하나의 과제를 만든다.

첫 번째 시나리오만 다루는 벤더 데모는 중요한 질문을 남긴다. 기존 시스템도 같은 수준의 검토를 받아야 한다. 익숙하다는 사실만으로 현재 워크플로가 변경, 예외 또는 과거 증거를 잘 처리한다는 점이 입증되지는 않는다.

이번 인수는 책임에 관한 상업적 논의도 바꾼다. 별도 벤더가 참여할 경우 고객은 지원 의무가 어디서 시작하고 끝나는지에 대한 명확한 합의가 필요하다. 공동 소유는 그러한 경계 전반에서 책임 소재를 더 명확히 할 기회를 만든다.

그러나 구매자는 세부 사항을 서면으로 요청해야 한다. 실패한 인계를 조사하는 팀은 어디인가? 제품 전반의 수정 작업은 누가 조율하는가? 외부 마케팅 플랫폼이 통합 요구사항을 바꾸면 어떻게 되는가?

이 질문들은 경쟁 분석을 현실에 기반하게 한다. 여기서 뱅킹 스위트가 우위를 잃었다거나 특화 플랫폼이 불필요해지고 있다고 단언할 근거는 없다. 기관마다 출발점과 제약 조건이 다르다.

방어 가능한 판단은 더 좁다. Zafin은 뱅킹 오퍼를 둘러싼 더 많은 업무를 다루고자 한다. 경쟁력은 그 넓어진 범위를 실제 고객 환경에서 유용하게 만드는 데 달려 있다.

통합 증거는 여전히 뒤따라야 한다

현재 이용 가능한 증거는 결합 플랫폼의 결과를 입증하기보다 인수의 논리를 더 분명하게 뒷받침한다.

독립적인 업계 맥락은 이 문제가 왜 주목받아야 하는지 설명하는 데 도움이 된다. Celent 애널리스트 Daniel Mayo의 오퍼 수명주기 분석은 고객 시정 조치를 수수료, 이자, 커뮤니케이션과 관련된 실패와 연결한다. 시정 조치란 문제가 발생한 뒤 고객 피해를 바로잡는 것을 의미한다.

이 관찰은 고객 약속 전체에 대한 검토를 뒷받침한다. 하지만 이번 거래가 그러한 실패를 막을 것이라는 점을 입증하지는 않는다. 통합 워크플로가 실제 운영 환경에 도달하기 전에도 인수 논리는 설득력 있게 들릴 수 있으므로, 이러한 분석적 구분은 중요하다.

이번 발표는 공동 고객 성과 결과를 입증하지 않는다. 구매자는 여전히 구현 노력, 통합 범위, 운영 신뢰성, 지속적인 지원에 관한 증거가 필요하다. 각 회사가 개별적으로 성공적인 구축 사례를 보유하고 있더라도 이 질문들은 남는다.

통합 데모가 도움이 되겠지만, 그 설계가 중요하다. 세심하게 준비된 출시 시나리오는 변경과 예외 처리에 수반되는 까다로운 업무를 감출 수 있다. 구매자는 입력값이 충돌하거나 필수 승인이 누락될 때 어떤 일이 일어나는지 확인해야 한다.

과거 기록의 재구성에는 특히 주의를 기울일 필요가 있다. 고객 서비스 직원은 이후 업데이트 이전에 적용되었던 조건을 설명해야 할 수 있다. 시스템은 그 설명을 관련 오퍼 버전 및 고객 상호작용과 연결해야 한다.

이는 단순히 문서를 찾는 것과 다르다. 검색 가능한 지식 베이스는 직원의 정보 검색을 도울 수 있지만, 운영 워크플로는 권한도 정립해야 한다. 검색 결과만으로 특정 결정에 어떤 조건이 적용되었는지는 판단할 수 없다.

마이그레이션은 또 다른 불확실성을 만든다. 기존 기록은 일관되지 않은 명칭이나 구조를 사용할 수 있다. 이를 공유 환경으로 옮기려면 의미를 보존하고, 충돌을 식별하며, 자동으로 조정할 수 없는 정보를 처리하는 방식에 대한 결정이 필요하다.

고객은 기능 중복에 대해서도 명확한 설명이 필요하다. 두 벤더가 오퍼 프로세스의 일부를 각각 다룬다면 로드맵은 해당 기능들이 어떻게 공존할지 설명해야 한다. 구매자는 공동 소유가 단일한 제품 경험을 보장한다고 가정해서는 안 된다.

성과 주장에도 같은 신중함이 적용된다. 이전 Naehas 구축 사례의 결과는 관련 기준점을 제공한다. 그러나 서로 다른 시스템, 통제 체계, 인력을 보유한 다른 기관에서 기대되는 결과를 입증하지는 않는다.

신뢰할 수 있는 평가는 전체 프로세스를 측정해야 한다. 승인 대기열이 변하지 않는다면 더 빠른 초안 작성의 비즈니스 가치는 제한적이다. 다운스트림 시스템이 약속된 혜택을 안정적으로 제공하지 못한다면 더 빠른 승인은 또 다른 문제를 만든다.

통제와 유지관리 노력 사이에는 균형도 있다. 고도로 구성 가능한 워크플로는 복잡한 요구사항을 수용할 수 있지만, 누군가는 그 구성을 최신 상태로 유지해야 한다. 구매자는 구현 후 필요한 인력과 전문성을 이해해야 한다.

이러한 우려가 전략적 논리를 약화시키는 것은 아니다. 이는 이를 평가하는 데 필요한 증거를 규정한다. 기업들이 의도한 범위를 관찰 가능한 고객 결과 및 명확한 운영 책임과 연결할 수 있을 때, Zafin Naehas 인수는 더욱 설득력을 갖게 된다.

거래 종결, 제품 연결, 고객 결과를 지켜봐야 한다

다음으로 유용한 신호는 거래 완료, 눈에 보이는 제품 연결, 그리고 전체 오퍼 프로세스를 포괄하는 고객 증거다.

우선 공식적인 거래 종결 발표를 지켜봐야 한다. 두 회사는 2026년 4분기를 예상 시점으로 제시했다. 완료 공지는 소유권 조건을 해소하고 실행 계획을 평가할 더 확실한 기반을 제공할 것이다.

종결만으로 제품 준비 상태가 입증되지는 않는다. 다만 고객이 더 명확한 기업 구조를 기준으로 다음 단계를 평가할 수 있게 한다. 리더십, 지원 연속성 또는 통합 우선순위에 관한 동반 발표는 그 단계를 정의하는 데 도움이 될 것이다.

지연은 제시된 원인을 바탕으로 해석해야 한다. 일정 변경은 여러 이유에서 발생할 수 있으므로 구매자는 모든 변경을 운영상 문제의 증거로 간주하지 말아야 한다. 유용한 정보는 수정된 일정과 고객에 미치는 영향에 관한 내용이다.

둘째, 구체적인 제품 연결을 지켜봐야 한다. 어떤 정보가 시스템 간에 이동하는지, 어떤 조치를 이용할 수 있게 되는지, 승인 결정이 어떻게 업무와 연결된 상태로 유지되는지를 명시할 때 로드맵은 더 의미를 갖는다.

가장 유용한 데모는 초기 생성 이후의 오퍼를 따라가는 방식일 것이다. 조건 변경, 검토 결정, 고객 채널로의 배포, 과거 기록의 검색을 보여줘야 한다. 이를 통해 연결의 품질을 드러낼 수 있다.

구매자는 외부 시스템이 그 데모에 어떻게 통합되는지도 지켜봐야 한다. 정상 작동하는 인프라의 교체를 요구하는 통합 경험은 기존 환경 안에서 작동하는 경험과는 다른 제안이다.

책임에 대한 명확한 설명은 인수의 운영 사례를 강화할 것이다. 통합 플랫폼이라는 모호한 언급은 핵심 질문을 해결하지 못한 채 남길 것이다. 제품 명칭과 공동 브랜딩은 관찰 가능한 행동보다 증거력이 낮다.

셋째, 해석할 수 있을 만큼 충분한 맥락을 담은 고객 결과를 지켜봐야 한다. 유용한 사례는 원래 워크플로, 구현 범위, 측정 기간, 남아 있는 수작업을 설명할 것이다. 이러한 세부 사항이 없으면 핵심 수치상의 개선을 비교하기 어렵다.

가장 강력한 증거는 속도를 정확성 및 서비스 결과와 연결하는 것이다. 승인 시간이 짧아지는 것은 중요하지만, 구매자는 예외, 수정, 이행도 이해해야 한다. 더 빠른 프로세스는 어떤 일이 있었는지 설명할 수 있는 역량을 보존해야 한다.

실명이 확인된 고객 참여는 이러한 결과를 더 쉽게 평가하게 한다. 기밀 유지로 공개가 불가능한 경우에도 상세한 방법론은 도움이 될 것이다. 목표는 다른 기관이 자사의 운영 조건에 대한 관련성을 판단할 수 있도록 하는 증거다.

이러한 신호는 순서대로 평가해야 한다. 거래 완료는 거래를 확정한다. 제품 연결은 이용 가능한 역량을 확정한다. 고객 결과는 그 역량이 실제 프로세스를 개선하는지 확정한다. 이 단계를 건너뛰며 판단하면 아직 증거가 뒷받침하지 못하는 결론을 유도하게 된다.

뱅킹 기술팀은 현재 프로세스에서 오퍼가 시간, 의미 또는 책임 소재를 잃는 지점을 문서화하는 것부터 시작해야 한다. 조건을 정의하고, 커뮤니케이션을 승인하며, 오퍼를 배포하고, 혜택을 제공하는 시스템을 식별하라. 그런 다음 벤더에게 동일한 오퍼가 변경과 예외를 거치는 과정을 보여 달라고 요청하라. 제품 세부 사항이 드러남에 따라 이 연습을 활용해 Zafin Naehas 인수를 평가하라. 유용한 질문은 더 폭넓은 플랫폼이 기관이 설명할 수 있는 의사결정을 보존하면서 조율 업무를 줄이는지 여부다. 자체 워크플로를 기준으로 한 데모를 요청하고, 미해결 질문의 담당자를 지정하며, 더 광범위한 구축을 결정하기 전에 결과를 기존 아키텍처와 비교하라.