Databricks SAP 통합, 데이터 공유를 넘어 엔터프라이즈 AI로 확장
Databricks와 SAP는 10월 30일 파트너십 확대를 발표하며 SAP 고객에게 더 많은 엔터프라이즈 AI 기능을 제공하겠다고 밝혔다. 다만 출시 일정은 구체적으로 제시되지 않았다. Databricks SAP 통합은 이제 비즈니스 기록을 데이터 준비, AI 지원, 거버넌스, 애플리케이션 개발과 연결하는 더 넓은 워크플로를 목표로 한다.
핵심 쟁점은 기업이 AI 프로젝트를 시작할 때마다 비즈니스 의미를 다시 구축하지 않고 재사용할 수 있는지다. 주문 기록은 어시스턴트가 이를 책임감 있게 해석하려면 관계, 정의, 권한이 필요하다. 이번 파트너십은 각 팀이 이런 세부 정보를 다시 구성하게 만드는 맞춤형 추출 방식을 겨냥한다.
SAP는 Snowflake와도 협력하고 있어 구매자는 고려할 또 다른 플랫폼 관계를 갖게 된다. 그러나 당장의 부담은 엔터프라이즈 아키텍처 팀에 쏠린다. 이들은 어떤 통합 업무를 관리형 플랫폼에 맡기고 어떤 비즈니스 책임을 직접 유지할지 결정해야 한다.
Databricks SAP 통합이 실제로 바꾸는 점
이번 발표는 파트너십의 의도된 범위를 데이터 공유에서 이를 사용하는 애플리케이션과 AI 시스템으로 확장한다.
SAP Databricks는 비즈니스 데이터와 분석을 연결하는 SAP의 관리형 환경인 SAP Business Data Cloud 내에 Databricks를 탑재한다. 10월 발표에서는 클라우드 및 온프레미스 시스템 전반의 애플리케이션 데이터로 연결되는 경로로 SAP Application Data Foundation을 소개했다.
Databricks는 확대된 제공 범위에 포함될 기능으로 Genie, Lakeflow, Unity Gateway, Lakebase를 꼽았다. 이 기능들은 AI 지원, 데이터 엔지니어링, AI 통제, 운영 애플리케이션을 포괄하는 역할을 맡을 예정이다.
회사는 또한 Databricks의 AI 지원 도구인 Genie와 SAP의 AI 어시스턴트 Joule 간 연결을 계획하고 있다고 설명했다. 중요한 점은 SAP Databricks 확장 발표가 기존 제공 기능과 예정된 추가 기능을 구분하면서도, 기능별 출시 일정은 제시하지 않는다는 것이다.
이 구분은 즉시 조달에 영향을 미친다. 구매자는 기존 연결 기능은 평가할 수 있지만, 발표된 전체 워크플로가 자신의 환경에서 이용 가능하다고 가정해서는 안 된다.
SAP의 별도 엔터프라이즈 AI 발표도 파트너십 확대를 뒷받침한다. 이 발표는 AI 개발, 비즈니스 컨텍스트, 엔터프라이즈 통제를 연결하려는 더 광범위한 노력 속에 해당 작업을 위치시킨다.
SAP는 유연한 데이터 저장소와 관리형 분석 기능을 결합한 아키텍처인 레이크하우스를 이러한 노력의 기반으로 설명한다. SAP의 발표는 다른 Databricks 기능과 함께 Agent Bricks도 언급한다.
이러한 설명은 전략적 방향을 보여 준다. 하지만 명시된 모든 구성 요소가 SAP Databricks 내에서 동일한 이용 가능성, 구성 요구 사항, 지원 체계를 갖춘다는 점을 입증하지는 않는다.
실질적인 변화는 제안된 역할 분담이다. 더 많은 통합 책임은 플랫폼 제공업체가 맡고, 고객은 그 결과로 마련된 기반 위에서 비즈니스 애플리케이션을 구축하게 된다.
이는 각 팀이 SAP를 또 다른 데이터세트를 추출하는 소스 시스템으로 취급하는 방식과 다르다. SAP의 비즈니스 정의가 후속 AI 작업에서도 지속적인 역할을 하도록 만든다.
그러나 제품 발표만으로는 맞춤형 작업이 얼마나 사라질지 확정할 수 없다. 고객별 확장 기능, 조직의 정의, 외부 시스템과의 연결은 여전히 검토가 필요하다.
이 이벤트를 통해 SAP Databricks를 이해하려는 독자에게 유용한 구분은 범위다. 기존 관계는 플랫폼을 연결하며, 확대된 관계는 그 위에서 수행되는 더 많은 작업을 연결하는 것을 목표로 한다.
따라서 이번 발표는 아키텍처적 약속으로서 주목할 가치가 있다. 운영상 의미는 고객이 어떤 조건에서 무엇을 배포할 수 있는지, 그리고 어떤 측정 가능한 결과를 얻는지에 달려 있다.
엔터프라이즈 데이터 팀이 새로운 구축-구매 판단에 직면하다
이번 확장은 플랫폼 제공업체가 점점 관리형으로 제공하는 통합 작업을 기업이 왜 다시 구축해야 하는지 설명하도록 압박한다.
맞춤형 추출에는 이해할 만한 매력이 있다. 팀은 목적지를 선택하고, 변환을 제어하며, 특정 보고 요건에 맞춰 데이터세트를 구성할 수 있다.
문제는 해당 데이터세트가 공유 인프라가 될 때 나타난다. 한때 대시보드에만 쓰이던 정의가 예측, 자동화된 추천, 비즈니스 의사결정에 영향을 미치기 시작한다.
예를 들어 공급업체 신뢰도를 평가하는 조달 어시스턴트를 생각해 볼 수 있다. 이 어시스턴트에는 구매 주문 목록만으로는 부족하다. 요청 날짜, 확정 날짜, 실제 입고, 이후 수정 사항을 구분해야 한다.
모델은 이러한 구분을 이해하지 못해도 설명을 생성할 수 있다. 그 결과 답변은 설득력 있게 들리지만, 전혀 다른 비즈니스 질문을 측정하고 있을 수 있다.
관리형 데이터 기반은 기업이 이러한 구분의 출처를 어디에 둘지 바꾼다. 팀은 모든 관계를 하류에서 다시 구축하는 대신, 지원되는 비즈니스 데이터가 이미 필요한 컨텍스트를 담고 있는지 평가할 수 있다.
이것이 데이터 엔지니어의 필요성을 없애는 것은 아니다. 다만 이들이 정당화하고 우선순위를 정해야 하는 업무를 바꾼다.
추출 스크립트를 유지하는 일과 배송 정의가 조달 정책에 부합하는지 검증하는 일은 다르다. 후자는 어시스턴트가 비즈니스 사용자에게 직접 도달할수록 더 중요해진다.
이 압박은 SAP 관리자와 비즈니스 소유자에게도 미친다. 이전에는 보고 목적으로 제한됐던 데이터세트가 익숙하지 않은 대상에게 서비스를 제공하는 시스템의 입력값이 될 수 있다.
그때 접근 결정에는 기술적 연결성 이상이 필요하다. 소유자는 누가 어떤 목적으로, 어떤 비즈니스 해석 아래 기록을 사용할 수 있는지 결정해야 한다.
SAP 엔터프라이즈 AI 프로젝트에서 이는 조직 소유권을 배포 아키텍처의 일부로 만든다. 모델 팀이 더 나은 프롬프팅만으로 모든 불확실성을 해결할 수는 없다.
이에 따라 구매자는 더 구체적인 구축-구매 판단에 직면한다. 재사용 가능한 플랫폼 기반 요소와 기업 고유의 비즈니스 로직을 구분해야 한다.
관리형 연결은 책임을 흐리지 않으면서 반복되는 엔지니어링 작업을 줄일 때 매력적이다. 반대로 고객이 정의가 어떻게 전달되는지, 누가 이를 유지하는지 설명할 수 없다면 매력은 줄어든다.
인력 측면의 의미도 있다. 일상적인 통합 작업을 플랫폼으로 옮긴다고 해서 기존 프로세스를 실제로 폐기할 수 없다면 자동으로 여력이 생기지는 않는다.
기존 추출 스택과 새 관리형 경로를 함께 운영하는 기업은 처음에는 복잡성을 더할 수 있다. 비즈니스 사례는 어떤 유지보수 의무가 사라지는지에 부분적으로 좌우된다.
이 분석은 관리형 통합이 보편적으로 더 낫다고 단정하지 않는다. 대신 발표가 강제하는 비교, 즉 운영 수명 전반에 걸친 통합 소유권 문제를 짚는다.
더 나은 구매 질문은 전체 워크플로를 다룬다. 실제로 사용할 수 있는 애플리케이션에는 어느 정도의 엔지니어링, 비즈니스 검토, 지속적인 지원이 필요한가?
이 질문은 엔터프라이즈 아키텍처 팀이 새로 발표된 기능 목록보다 더 명확한 평가 기준을 갖게 한다.
비즈니스 의미가 AI 제안의 작동 원리다
통합의 기술적 가치는 기록을 단순히 접근 가능하게 만드는 데 있지 않고, 기록과 함께 사용할 수 있는 컨텍스트를 보존하는 데 있다.
Databricks는 데이터의 의미와 관계를 설명하는 정보인 시맨틱 메타데이터가 SAP Business Data Cloud에서 Unity Catalog로 이동한다고 문서화한다. Unity Catalog는 Databricks의 카탈로그 및 거버넌스 시스템이다.
지원되는 정보에는 테이블 설명, 열 설명, 키, SAP 거버넌스 태그가 포함된다. 키는 기록과 관계를 식별하며, 거버넌스 태그는 정책 목적에 따라 정보를 분류한다.
시맨틱 메타데이터 문서는 경계도 명시한다. 서로 다른 공유 영역의 테이블 간 관계는 지원되지 않으며, 동기화된 SAP 메타데이터는 Databricks에서 읽기 전용으로 유지된다.
이 세부 사항들은 엔터프라이즈 AI가 데이터를 유용하게 추론하기 전에 올바른 기록을 식별해야 하기 때문에 중요하다.
예시적인 재무 워크플로에서 수익 질문에 답하는 어시스턴트는 적절한 측정 기준을 선택해야 한다. 수주된 주문, 발행된 송장, 인식된 수익은 서로 다른 목적을 지닌다.
설명과 관계는 질문이 어떤 데이터를 다루는지 정립하는 데 도움이 된다. 모델이 설명을 생성하기 전에 모호성을 줄일 수 있다.
그러나 메타데이터가 완전한 비즈니스 명세는 아니다. 수익 열에 대한 설명이 기업 회계 정책의 모든 예외를 반드시 인코딩하는 것은 아니다.
이로써 명확한 평가 경계가 생긴다. 구매자는 어떤 의미가 자동으로 전달되고, 어떤 의미가 여전히 정제된 정의나 사람의 검토에 의존하는지 살펴봐야 한다.
기록 간 관계에도 같은 원칙이 적용된다. 공유된 데이터세트 내에서 지원되는 관계가 복잡한 교차 도메인 질문에 필요한 모든 컨텍스트가 갖춰졌음을 의미하지는 않는다.
고객 약정과 공급업체 성과를 비교하는 어시스턴트는 여러 비즈니스 도메인에 분산된 정보에 의존할 수 있다. 애플리케이션은 이러한 경계를 고려해야 한다.
바로 이 지점에서 SAP 엔터프라이즈 AI 프로젝트는 데모를 넘어선다. 비즈니스 조건이 예외를 만들 때도 설득력 있는 답변은 정확성을 유지해야 한다.
취소된 주문, 부분 납품, 변경된 식별자, 늦은 조정은 평가에 유용한 예시다. 이는 보고된 통합 결과가 아니라 예시적인 테스트 조건이다.
기본 원칙은 AI 지식 베이스에서도 나타난다. 정보에 접근하는 문제와 사용할 수 있는 컨텍스트에 접근하는 문제는 별개다. 엔터프라이즈 트랜잭션 시스템은 권한과 일관성에 대해 더 엄격한 요건을 추가한다.
개발자에게 주는 시사점은 모델 선택이 데이터 해석 뒤에 따른다는 것이다. 더 강력한 모델도 정의되지 않은 비즈니스 지표를 안정적으로 보완할 수는 없다.
비즈니스 사용자에게도 시사점은 실용적이다. 답변은 무엇을 측정했고 왜 그러한 해석이 적합한지 판단할 수 있을 만큼 충분한 컨텍스트를 드러내야 한다.
따라서 Databricks SAP 통합은 의미를 드러내는 질문을 통해 가장 잘 평가할 수 있다. 기록 접근은 필요하지만, 애플리케이션이 운영상 신뢰를 얻을 자격이 있는지는 해석이 결정한다.
이것이 파트너십의 AI 제안 뒤에 있는 작동 원리이며, 기술 문서가 광범위한 혁신 주장보다 더 유용해지는 영역이다.
제로 카피 공유는 업무를 바꾸지만 없애지는 않는다
복제를 줄이면 데이터 경로는 단순해질 수 있지만, 접근, 정책, 애플리케이션 동작에 관한 상당한 책임은 그대로 남는다.
OpenSharing은 Databricks의 데이터 공유 플랫폼이다. SAP 커넥터 문서는 제로 카피 접근을 설명하는데, 이는 공유된 데이터가 공유 연결을 통해 복제되지 않고 원래 위치에 유지된다는 의미다.
이 주장은 아키텍처의 특정 계층에 관한 것이다. 모든 하류 애플리케이션이 새 자산 생성을 피한다는 약속으로 해석해서는 안 된다.
예측, 변환된 데이터 세트 또는 애플리케이션 데이터베이스는 자체적인 저장 및 관리 요구 사항을 만들 수 있습니다. 구매자는 연결 자체에서 추정하기보다 전체 애플리케이션을 평가해야 합니다.
SAP BDC connector는 SAP 및 Databricks 관리자 간의 조율도 필요로 합니다. 액세스는 구성된 공유 방식과 적절한 권한에 따라 달라집니다.
문서에는 또 다른 운영상의 세부 사항도 포함되어 있습니다. Databricks는 청구 및 관리 목적으로 특정 워크로드 사용량과 운영 정보를 SAP와 공유할 수 있습니다.
이 정보는 조직을 식별하고 공유된 SAP 데이터와 관련된 워크로드를 설명할 수 있습니다. 고객은 이 문서화된 방식을 아키텍처 및 공급업체 검토에 반영해야 합니다.
이러한 세부 사항은 관리형 커넥터의 가치를 부정하지 않습니다. 실제 배포에서 “관리형”이라는 말이 무엇까지 포괄해야 하는지를 보여 줍니다.
기업에는 여전히 액세스 요청, 변경되는 비즈니스 정의, 애플리케이션 장애 및 서비스 연속성에 책임질 사람이 필요합니다. 데이터 경로가 짧아진다고 해서 이러한 책임이 자동으로 배정되지는 않습니다.
또한 정보를 읽을 권한이 있다고 해서 그 정보에 따라 행동할 권한까지 있는 것은 아닙니다. 공급업체 지연을 설명하는 어시스턴트와 구매 주문을 변경하는 애플리케이션은 서로 다른 권한 수준을 가집니다.
파트너십이 애플리케이션과 에이전트, 즉 도구를 사용해 작업을 완료하는 소프트웨어 시스템으로 확장될수록 이 구분은 더욱 중요해집니다.
기업은 권고안을 작성하는 어시스턴트는 수용하되, 운영 변경 전에는 승인을 요구할 수 있습니다. 이 경계는 애플리케이션의 설계와 평가에 포함되어야 합니다.
따라서 발표된 플랫폼 확장은 데이터 액세스, 답변 품질, 행동 권한 부여에 대해 별도의 검증을 받아야 합니다. 한 영역에서의 성공이 다른 영역에서의 성공을 입증하지는 않습니다.
성능 주장에도 비슷한 엄격함이 필요합니다. Databricks는 발표에서 고객 개선 사례를 인용하지만, 이러한 사례가 계획된 모든 통합의 암묵적 벤치마크가 되어서는 안 됩니다.
기존 고객의 도입 사례는 기반 플랫폼이 비즈니스 워크로드를 지원한다는 점을 보여 줄 수 있습니다. 그러나 공개된 출시 일정이 없는 기능의 성능까지 입증할 수는 없습니다.
그러므로 비판적 관점은 구체적입니다. 이 아키텍처는 반복적인 통합 작업을 줄일 그럴듯한 방법을 제시하지만, 발표는 남아 있는 모든 구현 의무를 수치로 제시하지는 않습니다.
구매 관점에서 SAP Databricks를 설명할 때 핵심적인 주의 사항은 다음과 같습니다. 지원되는 워크플로우, 그 한계, 그리고 소유권 모델을 함께 평가해야 합니다.
성공적인 배포는 애플리케이션을 둘러싼 운영 체계 전반의 작업을 줄여야 합니다. 그 작업을 눈에 덜 띄는 관리 프로세스로 옮기는 것은 실질적 이점을 약화시킬 것입니다.
Snowflake는 SAP 액세스만으로는 차별화되지 않는 이유를 보여 줍니다
SAP가 다른 플랫폼 파트너십도 발표했기 때문에, Databricks는 고객이 SAP 데이터로 구축하고 운영할 수 있는 역량을 놓고 경쟁해야 합니다.
SAP는 2025년 11월 Snowflake와의 협력을 발표했습니다. 이 발표에서는 SAP Snowflake 솔루션 확장과 기존 Snowflake 환경용 커넥터를 모두 설명했습니다.
제안된 아키텍처에는 복제 없는 양방향 공유와 비즈니스 컨텍스트를 포함한 SAP 데이터 액세스가 포함되었습니다. 이러한 주제는 현재 Databricks가 강조하는 핵심 가치 제안과 겹칩니다.
따라서 SAP의 Snowflake 데이터 협업은 관련성 있는 경쟁 기준점이 됩니다. 이후 문서를 확인하지 않은 채, 원래의 제공 목표를 현재 제공의 증거로 간주해서는 안 됩니다.
이 비교가 중요한 이유는 Databricks 발표를 광범위하게 해석하는 데 한계를 두기 때문입니다. SAP 데이터 액세스가 단일 외부 분석 플랫폼을 통해서만 제공되는 것은 아닙니다.
이 때문에 구매자는 통합 액세스가 플랫폼 선택을 결정한다고 가정하기보다 실제 워크로드를 비교할 필요가 있습니다.
확립된 데이터 엔지니어링 관행을 가진 기업은 기존 환경과의 일관성을 중시할 수 있습니다. 다른 기업은 특정 애플리케이션 패턴이나 비즈니스 사용자 경험을 우선시할 수 있습니다.
이는 분석상의 고려 사항일 뿐, 어느 공급업체가 보편적으로 우위에 있다는 증거는 아닙니다. 여기서 검토한 출처는 경쟁 구현 간의 통제된 비교를 제공하지 않습니다.
유용한 경쟁 질문은 공유 데이터와 유지 관리되는 비즈니스 애플리케이션 간의 거리와 관련됩니다.
액세스가 부여된 뒤 팀은 얼마나 많은 작업을 수행해야 할까요? 비즈니스 사용자는 답변을 얼마나 쉽게 검토할 수 있을까요? 무언가 변경될 때 관리자는 책임 소재를 얼마나 명확하게 추적할 수 있을까요?
이 질문들은 비교를 이 글의 핵심 쟁점, 즉 관리되는 비즈니스 컨텍스트와 반복적으로 재구성되는 컨텍스트에 연결해 둡니다.
플랫폼은 폭넓은 기능을 제공하면서도 고객에게 까다로운 인계 과정을 관리하게 할 수 있습니다. 반대로 범위가 더 좁은 배포도 경계가 잘 이해된다면 상당한 가치를 제공할 수 있습니다.
SAP의 다중 파트너 접근 방식은 장기적인 상호운용성 문제도 제기합니다. 고객은 워크로드가 플랫폼 경계를 넘을 때 어떤 정의가 재사용 가능한 상태로 유지되는지 알아야 합니다.
개방형 공유 메커니즘은 연결성을 구축하는 데 도움이 됩니다. 애플리케이션 로직, 비즈니스 정의 및 운영 절차의 이식성은 별도의 검토가 필요합니다.
기업 구매자에게 이는 도입 조건과 함께 종료 조건도 평가해야 함을 의미합니다. 데이터 연결은 프로덕션 애플리케이션이 만드는 종속성의 일부일 뿐입니다.
Databricks에 이 확장은 기대치를 높입니다. 회사는 더 폭넓은 개발 및 운영 경험을 중심으로 관계를 포지셔닝하고 있으며, 이는 더 폭넓은 평가를 불러옵니다.
SAP의 과제는 확대되는 플랫폼 관계 전반에서 이해하기 쉬운 선택지를 유지하는 것입니다. 구매자는 지원되는 기능과 책임성에 관한 명확한 경계를 필요로 합니다.
따라서 경쟁적 의미는 극적인 것이 아니라 실무적입니다. 더 많은 공급업체가 비즈니스 데이터로 가는 경로를 제공하며, 차별화는 고객이 그 경로를 통해 완료할 수 있는 신뢰할 만한 작업의 양으로 이동합니다.
다음 신호는 가용성, 의미 충실도 및 운영 결과입니다
다음 증거는 발표된 아키텍처를 배포 가능한 기능 및 측정된 비즈니스 워크플로우와 연결해야 합니다.
첫 번째 신호는 기능 수준의 가용성입니다. 앞으로 몇 달 동안 출시 문서는 고객이 확장된 기능 중 무엇을 사용할 수 있는지와 어디에서 지원되는지를 명확히 해야 합니다.
유용한 업데이트는 일반 제공과 프리뷰 액세스를 구분하고, 관련 종속성을 설명할 것입니다. 또한 계획된 어시스턴트 연결의 제공 상태도 확립할 것입니다.
이 정보는 아키텍처 방향을 평가 가능한 배포 옵션으로 전환함으로써 발표를 강화할 것입니다. 계속된 모호성은 단기 계획을 제한할 것입니다.
두 번째 신호는 의미 충실도이며, 이는 비즈니스 정의와 관계가 시스템 전반에서 사용되는 과정에서 얼마나 정확하게 유지되는지를 뜻합니다.
고객에게는 지원되는 경계를 감추지 않고 드러내는 사례가 필요합니다. 여러 도메인에 걸친 질문과 변화하는 비즈니스 정의는 특히 검토하기 유용한 영역입니다.
이러한 조건을 투명하게 처리하는 애플리케이션은 관리되는 비즈니스 기반에 대한 주장을 뒷받침할 것입니다. 빈번한 수동 재구성은 이점을 축소할 것입니다.
이는 공급업체가 완벽한 이해를 주장해야 한다는 뜻은 아닙니다. 명확한 한계와 반복 가능한 평가는 맥락 지능에 대한 광범위한 보장보다 더 강력한 증거를 제공할 수 있습니다.
세 번째 신호는 완전한 고객 워크플로우에서 나온 운영 결과입니다. 관련 보고는 더 빠른 분석과 더 빠른 구현, 유지 관리 감소 또는 더 나은 의사 결정 품질을 구분해야 합니다.
이러한 결과는 서로 다른 질문에 답합니다. 더 빠른 쿼리는 기업이 맞춤형 통합 스택을 폐기했다는 사실을 입증하지 못하더라도 유용할 수 있습니다.
마찬가지로 어시스턴트는 사용자 시간을 절약하면서 새로운 검토 의무를 만들 수 있습니다. 운영 평가는 답변의 신뢰성을 유지하는 데 필요한 노력도 포함해야 합니다.
구매자는 명확히 정의된 기준선, 명시된 비즈니스 프로세스, 그리고 사람의 개입에 대한 분명한 설명을 찾아야 합니다. 이러한 세부 사항이 불명확하면 비교는 어려워집니다.
가장 강력한 고객 증거는 배포 후 무엇이 바뀌었는지를 설명할 것입니다. 어떤 작업이 사라졌는지, 어떤 통제가 남았는지, 조직이 결과를 어떻게 측정했는지를 식별할 것입니다.
이는 또한 누가 먼저 혜택을 받는지도 명확히 할 것입니다. 데이터 엔지니어, 관리자, 비즈니스 분석가 및 운영 사용자는 동일한 아키텍처의 서로 다른 부분을 경험합니다.
파트너십의 중요성은 이러한 경험을 연결하는 데 달려 있습니다. 더 나은 개발 환경은 그 이점이 일상적인 비즈니스 사용까지 이어질 때 더욱 중요해집니다.
Databricks SAP 통합은 그 연결을 향한 신뢰할 만한 방향을 제시합니다. 문서화된 기반은 남아 있는 질문을 구매자가 조사할 수 있을 만큼 구체적으로 만듭니다.
도입을 결정하기 전에, 팀이 이미 일관되게 답하는 데 어려움을 겪는 비즈니스 질문을 선택하세요. 공급업체에 제안된 아키텍처 전반에서 해당 질문의 기록, 정의, 권한 및 승인 경계를 추적해 달라고 요청하세요. 주요 발표 외의 종속성을 포함해 필요한 모든 기능의 출시 상태를 요청하세요. 그런 다음 유지 관리와 비즈니스 검토를 포함하여 그에 따른 작업량을 기존 프로세스와 비교하세요. 유용한 결과는 각 결정을 누가 소유하는지와 실제로 어떤 작업이 사라지는지에 관한 더 명확한 설명입니다. Databricks SAP 통합의 경우, 이 증거는 다음 AI 투자를 평가하는 기업에 발표된 확장의 의미를 부여할 것입니다. 귀 조직은 이러한 주장을 검증하기 위해 어떤 비즈니스 워크플로우를 사용할 수 있을까요?
