사용자님의 아주 중요한 지적을 반영하여 2번 답변을 보강했습니다. **Key의 유일성(Uniqueness)**과 **Text(Dimension)의 중복 가능성**은 기술적으로 매우 치명적인 포인트입니다. 이를 통해 "왜 텍스트 필터가 Key 필터를 대체할 수 없는가"를 Norleen에게 명확히 전달할 수 있습니다.
### ✉️ Norleen에게 보낼 답변 초안 (최종 보완본)
**Subject: Re: Case 198847 - Critical Business Impact and Why 'Key' Filtering is Non-Negotiable**
Hi Norleen,
Thanks for the update. It’s a huge relief that the developers confirmed this is a defect. Since the 'Key' value is a fundamental part of how query filters should work, we really need to get this sorted out on the SP4 codeline.
Here is the updated information regarding the business impact and our critical timeline:
1. **What is the impact for your company?**
We went live with our Korean entity this January. The inconsistency between AO and WebI is causing significant confusion. Our users expect a seamless experience across both tools, and this defect is currently a major blocker for our digital transformation.
2. **Why is a workaround not a viable solution?**
**Technical Keys are unique, but Text descriptions (Dimensions) are often duplicated** in our BW system. Using Text as a filter can lead to incorrect data results due to these duplicates. Furthermore, our users communicate using these specific Key values as their primary reference. Asking them to switch to descriptions is not just a habit change—it risks data accuracy and breaks their established communication standards.
3. **How many end users will be affected?**
We currently have **1,600 registered users**. However, on **July 4th**, we are scheduled to **roll out to our other Asian entities**, which will increase the total user count to **3,000**.
4. **By which date is a resolution required?**
**04/06/2026** (4th of June, 2026).
5. **What is the reason for the date required?**
The massive regional roll-in starts on July 4th. To meet this, we must have the fix by **June 4th**. This gives our team the necessary one month to perform internal validation (QA) and complete the production deployment safely. We cannot risk a 3,000-user rollout with a known defect that impacts data integrity.
6. **Stage of software development?**
This is impacting our **Production** environment.
**Regarding the SP5 upgrade:**
Upgrading the entire platform to SP5 during a major regional expansion is too risky. Since we are already on a very recent **SP4 Patch 14**, we urgently request a fix (such as a Hotfix) for the SP4 codeline to ensure a successful Asia rollout.
Please share these technical and business concerns with your development team.
Best regards,
**Yongshik Kim**
### 💡 보완된 논리 포인트
* **데이터 무결성(Data Integrity):** Text는 중복될 수 있지만 Key는 유일하다는 점을 강조함으로써, 단순히 "불편함"의 문제를 넘어 **"데이터 오류"**의 가능성을 경고했습니다. SAP가 가장 민감하게 반응하는 부분입니다.
* **의사소통 표준:** 사용자들 사이에서 Key가 이미 소통의 "언어"로 정착되었다는 점을 명시하여, 기능 수정의 당위성을 높였습니다.
* **데드라인 재강조:** 6월 4일(한 달 전)이라는 구체적인 날짜와 그 이유(검증 기간)를 다시 한번 못 박았습니다.
이 정도면 Norleen도 개발팀에 "이건 그냥 넘어갈 문제가 아니다"라고 강력하게 에스컬레이션할 수밖에 없을 것입니다. 그대로 발송하셔도 좋습니다!
Norleen에게 전달할 답변에 사용자님께서 우려하시는 **기술적 복잡성(SSO 및 포탈 임베디드)**과 **SP5 업그레이드에 대한 위험성**을 구체적으로 담았습니다.
특히 SP4와 SP5 사이의 변화가 시스템 전반(SAML SSO, 통합 포탈 등)에 미칠 영향이 크다는 점을 강조하여, 왜 SP4에서 해결책을 받아야 하는지에 대한 기술적 명분을 보강했습니다.
### ✉️ Norleen에게 보낼 답변 초안 (최종 보완본)
**Subject: Re: Case 198847 - Technical Risks of SP5 Upgrade and Firm Request for SP4 Fix**
Hi Norleen,
Thank you for confirming that this is a defect. Following up on the business impact, I need to emphasize why an upgrade to **SP5** is currently not a viable option for us from a technical standpoint.
We have a very complex and tightly integrated environment that makes a major Service Pack upgrade extremely risky at this stage:
1. **Complexity of our SSO Environment:**
We are currently using **SAML SSO** based on email via **SiteMinder** for our BW-integrated accounts. This setup is mission-critical and highly sensitive to platform changes.
2. **Portal Integration:**
Our **BI LaunchPad is deeply embedded** within our corporate-wide portal. Any shift in the platform version (like moving from SP4 to SP5) requires a full-scale impact assessment and extensive regression testing to ensure these integrations don't break.
3. **Concerns over SP4 vs SP5 Changes:**
To be honest, we are very concerned about the magnitude of changes between SP4 and SP5. Given our current production stability and the upcoming regional roll-outs, we cannot afford the potential downtime or integration failures that a Service Pack upgrade might trigger.
**Therefore, we once again firmly request that the development team provides a fix or a backport for the SP4 codeline.** We recently applied **SP4 Patch 14**, and we expect a confirmed defect to be addressed within the Service Pack we are currently running, especially considering the scale of our deployment (expanding to 3,000 users by July 4th).
Please share these technical constraints with the developers and let us know if they can provide a fix by our **June 4th** deadline.
Best regards,
**Yongshik Kim**
### 💡 보완된 기술적 포인트
1. **SAML SSO & SiteMinder:** 인증 체계는 업그레이드 시 가장 먼저 깨지기 쉬운 부분입니다. 이를 언급함으로써 SAP 지원팀에 "이건 단순히 버튼 하나 누르는 업그레이드가 아니다"라는 경고를 보냈습니다.
2. **Embedded BI LaunchPad:** 전사 포탈에 임베디드되어 있다는 점은 UI/UX 및 웹 세션 관리에 민감한 영향을 미친다는 뜻입니다. 업그레이드 거부의 아주 강력한 기술적 사유가 됩니다.
3. **위험성 강조:** SP4와 SP5 사이의 아키텍처 변화에 대한 우려를 표명하여, SAP가 함부로 업그레이드를 강요하지 못하도록 방어막을 쳤습니다.
이 초안을 그대로 발송하시면, Norleen과 개발팀도 사용자님의 환경이 매우 복잡하다는 점을 인지하고 SP4에서의 수정을 더 진지하게 검토할 것입니다. 그대로 진행하셔도 좋습니다!