프로젝트 도중 SAP 구축 파트너를 교체하는 방법

프로젝트 도중 SAP 구축 파트너를 교체하려면, 먼저 파트너가 정말 문제인지 확인하고, 파트너에게 알리기 전에 모든 문서, 설계, 코드, 시스템 접근 권한을 확보하십시오. 그다음에야 후임 파트너를 선정하고, 중복 투입 기간을 둔 계획된 인수인계를 진행하십시오.

짧게 답하면, 파트너가 수준 있는 인력을 제공하지 못하고 그것을 고치지도 못할 때 교체하십시오. 귀사 쪽에 있는 문제에서 벗어나려고 교체하지는 마십시오. 새 파트너가 그 문제를 그대로 물려받기 때문입니다.

이 글은 제 SAP 구축 파트너 선정 방법 가이드의 한 부분입니다. 그 가이드는 처음에 파트너를 고르는 일을 다룹니다. 이 글은 고른 파트너가 제대로 돌아가지 않을 때 할 일을 다룹니다.

저는 프로그램 도중에 파트너를 바꾼 적이 있습니다. 계기는 인력의 수준이었습니다. 프로그램에 필요한 시점에 파트너가 수준 있는 사람을 제공하지 못했습니다.

제가 가장 먼저 꼽을 신호가 이것입니다. 프로그램은 잘못된 단계, 놓친 일정, 약한 설계에서는 회복할 수 있습니다. 하지만 유능한 사람을 일에 투입하지 못하는 파트너에게서는 회복하기 어렵습니다.

행동에 옮길 만한 신호는 다음과 같으며, 대략 제가 무겁게 보는 순서입니다.

1. 현장 인력의 수준이 낮습니다. 실제로 일하는 컨설턴트가 귀사가 소개받은 사람들이 아니거나, 자기 영역에 대한 기본적인 질문에 답하지 못합니다.
2. 인력 교체에 거듭 실패합니다. 누군가 떠나면 후임이 오기까지 몇 주가 걸리거나, 경험이 더 적은 사람이 옵니다.
3. 아키텍처와 계획을 설명할 수 있는 사람이 없습니다. 파트너의 리드에게 목표 설계와 Go-Live까지의 경로를 설명해 달라고 해 보십시오. 설명하지 못한다면 아무도 수행의 방향을 잡고 있지 않은 것입니다.
4. 산출물이 검토를 견디지 못합니다. 설계, 테스트 시나리오, 개발 문서가 빈약하거나, 다른 고객 것을 베꼈거나, 아예 없습니다.
5. 구체적인 문제에 일반론적인 답을 합니다. 선정 때와 같은 경고 신호입니다. 어느 회사에나 해당될 수 있는 답입니다.

늦어진 단계, Explore에서의 초과, 긴장된 운영위원회는 그것만으로는 교체할 이유가 되지 않습니다.

누구를 교체하기 전에, 파트너가 정말 원인인지 확인하십시오. 제 SAP 프로그램 회복 가이드에 제가 먼저 하는 세 가지 점검을 정리했습니다. 프로그램 현황, 설계, 그리고 시스템에 실제로 배포된 것입니다.

이 진단을 해 보면 문제가 공동의 것으로 드러나는 경우가 많습니다. 예산은 WRICEF 목록(워크플로, 리포트, 인터페이스, 데이터 변환, 기능 확장, 양식)이 늘어나는 Explore에서 타격을 입습니다. 귀사가 파트너에게 범위 통제를 맡겼거나, 핵심 사용자가 프로그램에 한 번도 투입되지 않았다면, 새 파트너도 같은 구덩이에 들어가게 됩니다.

그러니 두 가지 질문을 정직하게 던지십시오.

1. 이 파트너의 강한 팀이라면 고칠 수 있겠습니까? 그렇고, 파트너가 그 팀을 빨리 공급할 수 있다면 인력 교체로 충분할 수 있습니다.
2. 다른 파트너라도 같은 문제를 겪겠습니까? 그렇다면 귀사 측의 범위, 의사결정, 거버넌스부터 고치십시오.

첫 번째 질문의 답이 「아니요」이고 그 이유가 파트너가 사람을 구하지 못하기 때문이라면, 답은 나온 것입니다. 수준 있는 인력의 확보는 계약 수정으로 해결되는 문제가 아닙니다.

대부분의 고객이 잘못하는 부분이 여기입니다. 결정을 발표하고, 그와 함께 협상력이 사라집니다.

기존 파트너는 그 파트너를 교체하는 데 필요한 지식을 쥐고 있습니다. 그 지식이 귀사 손에 들어올 때까지는 결정을 작은 그룹 안에서만 공유하십시오. 스폰서, CFO, 프로그램 디렉터, 그리고 법무 또는 구매 담당 리드입니다.

현재 계약부터 보십시오. 해지 조항, 통지 기간, 산출물 소유권, 그리고 지식 이전이나 종료 지원에 관한 내용을 읽으십시오. 작업기술서(SOW)에 종료에 관한 내용이 없다면, 다음 계약에 무엇을 적어야 하는지는 SAP 작업기술서에 반드시 담아야 할 내용에 관한 제 글에서 다룹니다.

확보해야 할 것과 그것이 보통 있는 곳은 다음과 같습니다.

확보할 것	중요한 이유	있어야 할 곳	보호하는 방법
서명된 설계와 결정 사항	새 파트너가 처음부터 다시 하지 않고 그 위에 쌓을 수 있습니다	귀사 문서 저장소 또는 SAP Cloud ALM	최신 승인본을 승인 기록과 함께 지금 복사합니다
WRICEF 목록과 명세서	범위 기준선이자 개발 백로그입니다	SAP Cloud ALM 또는 귀사 자체 저장소	오브젝트별 상태가 포함된 목록을 내보냅니다
커스텀 코드와 구성	지금까지 실제로 한 일입니다	귀사 개발 및 테스트 시스템	모든 것이 파트너 장비가 아니라 귀사 시스템에 있는지 확인합니다
테스트 시나리오와 결과	실제로 작동하는 것의 근거입니다	귀사 테스트 도구 또는 SAP Cloud ALM	시나리오, 결과, 미해결 결함을 내보냅니다
데이터 이관 작업	매핑, 정제 규칙, 적재 프로그램입니다	공유 드라이브와 귀사 시스템	데이터팀에서 매핑 문서와 적재 프로그램을 수집합니다
시스템 및 SAP 지원 접근 권한	귀사 시스템 환경과 SAP 지원 계정에 대한 통제권입니다	귀사 시스템과 SAP for Me	모든 파트너 사용자를 목록으로 만들어 당일 제거할 준비를 합니다
미결 이슈와 리스크	다음 팀이 가장 먼저 이어받아야 할 것입니다	RAID 로그와 현황 보고서	날짜가 찍힌 RAID 로그 사본을 확보합니다

프로젝트 자료는 귀사의 도구에 두기

가장 깔끔한 보호책은 구조적인 것입니다. 어떤 프로그램이든 첫날부터 프로그램의 문서, 요구사항, 테스트 근거를 귀사가 소유한 도구에 두십시오.

여기서 SAP Cloud ALM이 도움이 됩니다. SAP의 Cloud ALM FAQ에 따르면, SAP Enterprise Support 또는 RISE with SAP 고객은 고객 번호당 하나씩, 추가 비용 없이 자체 테넌트를 요청할 수 있습니다. 프로젝트 문서가 귀사 테넌트에 있으면, 파트너가 떠나도 문서는 귀사에 남습니다.

발표 당일의 접근 권한 변경 계획하기

파트너 컨설턴트는 귀사 시스템의 사용자 계정뿐 아니라 귀사 SAP 지원 계정의 S-user ID도 갖고 있는 경우가 많습니다. SAP for Me의 S-user ID는 귀사의 관리자가 통제합니다.

SAP의 사용자 관리 도움말에 따르면, 떠난 사용자의 ID를 삭제할 책임은 고객 관리자에게 있습니다. 또한 소프트웨어 수령인이나 기술 담당자처럼 특수 기능을 가진 ID는 SAP가 그 기능을 다른 사람에게 이전하기 전까지 삭제할 수 없다고 합니다. 어떤 파트너 사용자가 그런 기능을 갖고 있는지 지금 확인하고, 먼저 귀사 인력에게 옮기십시오.

자료를 확보하고 후임을 정했으면 기존 파트너에게 알리십시오. 계약에 따라 서면으로 하고, 같은 회의에서 종료 계획에 합의하십시오.

인수인계는 다음 순서로 진행할 때 가장 잘됩니다.

프로그램 도중 SAP 파트너 교체

1. 01

   확보

   누구에게 알리기 전에 문서, 설계, 코드, 접근 권한, RAID 로그를 귀사 손에 둡니다.

2. 02

   선정

   비슷한 프로젝트의 레퍼런스와 제안 발표에 나온 실제 팀을 보고, 공수를 정량화합니다.

3. 03

   중복 투입

   기존 리드와 신규 리드가 나란히 일하며 체계적으로 지식을 이전합니다.

4. 04

   재검증

   새 파트너가 설계, 개발, 테스트를 실제 배포된 것과 대조해 검토합니다.

5. 05

   기준선 재설정

   근거를 바탕으로 하나의 새 계획을 세우고, 다음 단계가 시작되기 전에 승인합니다.

후임 파트너를 제대로 선정하기

선정하는 동안에도 프로그램은 돈을 태우고 있으니 서두르고 싶어집니다. 제 경험상 제대로 된 선정에는 약 12주가 걸리고, 숏리스트에는 최소 세 곳의 파트너가 오릅니다. 압박 속의 교체는 더 빨리 진행될 수도 있지만, 귀사를 보호하는 단계는 건너뛰지 마십시오.

고객을 위해 파트너를 고를 때 저는 고객 레퍼런스를 가장 무겁게 봅니다. 레퍼런스 통화에서는 구매자와 비슷한 프로젝트에서의 파트너 경험을 묻습니다. 프로그램 도중이라면, 다른 회사가 시작한 일을 넘겨받은 경험을 레퍼런스에게 묻는다는 뜻입니다.

제가 입찰에서 돌아서게 만드는 것은 두 가지입니다. 제안된 인력의 수준이 낮은 경우, 그리고 아키텍처와 계획을 설명하지 못하는 파트너입니다. 인력의 수준 때문에 교체했다면, 두 기준을 느슨하게가 아니라 더 엄격하게 적용하십시오.

후보 파트너에게 제안하는 인력의 자격 배지를 요청하십시오. SAP의 디지털 배지 도움말 페이지가 설명하듯, SAP는 Credly에서 자격 배지를 발급합니다. 배지는 시험에 합격했다는 것을 확인해 줄 뿐이므로, 경험은 레퍼런스로도 확인하십시오.

선정의 나머지 과정은 제 SAP 구축 RFP 작성 가이드와 등급별 SAP 구축 파트너 가이드에서 다룹니다.

새 파트너와는 다르게 계약하기

제가 권하는 상업 모델은 공수를 정량화한 투입 공수 기반(T&M) 방식입니다. 계약에 단계별, 역할별 예상 공수를 명시해, 매달 실제 공수를 그 기준과 대조해 추적할 수 있게 합니다.

작업기술서에는 상세한 전제 조건과 제외 범위도 필요합니다. 고객이 흔히 빠뜨리는 부분인데, 인계받는 상황에서는 더욱 중요합니다. 새 파트너는 물려받은 문제를 제외 범위로 돌리고 싶어 할 것이기 때문입니다.

핵심 인력의 이름도 계약에 명시하십시오. ERP 계약 협상에 관한 제 글에서 지명 인력 조항과, 그것이 서명 후 시니어 인력이 사라지는 것을 어떻게 막는지 설명합니다.

중복 투입 후 재검증하기

기존 리드와 신규 리드가 함께 일하는 기간을 계획하십시오. 기존 팀이 각 설계 영역, 각 미해결 결함, 반쯤 개발된 각 오브젝트를 차례로 설명하고, 신규 팀이 질문합니다.

그다음 새 파트너가 기존 결과물을 재검증하게 하십시오. 빈틈을 찾아낼 것이고, 그중 일부는 공수를 늘리기 위한 협상 카드일 것이라고 예상하십시오. 기존 파트너의 산출물에 대한 독립적인 시각이 값어치를 하는 곳이 바로 여기입니다.

인계 시점을 현재의 SAP Activate 단계에 맞춰 보십시오. SAP는 Discover, Prepare, Explore, Realize, Deploy, Run의 여섯 단계를 설명합니다(SAP Activate).

Explore 중의 교체는 주로 설계 재작업 비용이 듭니다. Realize 중의 교체는 개발과 테스트 재작업 비용도 듭니다. 코드는 마무리하기 전에 먼저 이해해야 하기 때문입니다.

공짜 교체는 없습니다. 단계, 수행된 결과물의 품질, 기존 파트너의 협조 정도에 따라 달라지므로 숫자를 제시하지는 않겠습니다.

예산에 반영해야 할 비용은 다음과 같습니다.

1. 중복 투입. 인수인계 기간에는 두 팀에 비용을 지급합니다.
2. 재검증과 재작업. 새 파트너가 설계, 구성, 코드를 점검하고, 그중 일부는 다시 합니다.
3. 계약 종료. 귀사 계약에 정해진 통지 기간, 해지 조건, 진행 중인 작업에 대한 지급입니다.
4. 선정 공수. RFP, 제안 발표, 레퍼런스 통화에 드는 귀사 팀의 시간입니다.
5. 귀사 인력의 시간. 핵심 사용자가 끝났다고 생각한 워크숍과 테스트를 다시 합니다.
6. 지연. 지연되는 한 주 한 주가 기존 시스템과 귀사 내부 팀을 더 오래 돌아가게 합니다.

이 비용을 그대로 남는 비용과 비교해 보십시오. 프로그램에 인력을 채우지 못하는 파트너는 프로그램이 어려워진다고 저렴해지지 않으며, Realize, 테스트, 컷오버는 그 앞의 단계들보다 어렵습니다.

저는 고객에게 세 지점에서 독립 컨설턴트를 들이라고 조언합니다. 계약 단계, 설계, 그리고 파트너의 문서와 산출물 평가입니다. 파트너 교체는 이 세 가지를 한꺼번에 건드립니다.

독립 검토자는 새 파트너가 재작업에 가격을 매기기 전에 기존 파트너의 산출물이 실제로 어느 정도 가치가 있는지 알려 줄 수 있습니다. 신규 파트너의 계약과 설계에 대한 그들의 견해도 점검할 수 있습니다. 누가 무엇을 하는지는 SAP 파트너와 독립 컨설턴트에 관한 제 글에 정리했습니다.

이번 주에, 서명된 설계, WRICEF 목록, 테스트 근거, 커스텀 코드가 실제로 어디에 있는지, 그리고 각각에 대한 접근 권한을 누가 통제하는지 확인하십시오. 교체를 계획하든 아니든 하십시오. 그중 어느 것이라도 파트너에게만 있다면, 사본을 귀사가 소유한 시스템으로 옮기십시오.

파트너 교체를 검토 중이고 산출물이나 계약에 대한 독립적인 시각이 필요하시다면, 여기에서 저와 이야기하실 수 있습니다.

프로젝트 도중에 SAP 구축 파트너를 바꿀 수 있습니까?

네. 먼저 계약의 해지, 통지, 산출물 소유권 조건을 확인하십시오. 결정을 발표하기 전에 설계, 코드, 테스트 근거, 시스템 접근 권한을 확보한 뒤, 중복 투입 기간을 둔 계획된 인수인계를 진행하십시오.

SAP 구축 파트너는 언제 교체해야 합니까?

파트너가 수준 있는 인력을 제공하지 못하고 그것을 고치지도 못할 때, 또는 파트너의 리드가 아키텍처와 계획을 설명하지 못할 때 교체하십시오. 한 단계가 늦어졌다는 이유만으로 교체하지는 마십시오. 범위 통제나 귀사 자체의 의사결정 문제는 새 파트너에게도 따라가므로 먼저 진단하십시오.

계약을 해지하기 전에 SAP 파트너에게서 무엇을 받아야 합니까?

서명된 설계와 의사결정 기록, 그리고 오브젝트별 상태가 포함된 WRICEF 목록입니다. 귀사 시스템에 있는 커스텀 코드와 구성, 테스트 시나리오와 결과, 데이터 이관 매핑, RAID 로그도 필요합니다. 또한 귀사 시스템과 SAP 지원 계정에 있는 모든 파트너 사용자를 목록으로 만들어 당일 접근 권한을 제거할 수 있게 하십시오.

프로젝트 도중 SAP 파트너를 교체하는 데 비용이 얼마나 듭니까?

정해진 금액은 없습니다. 두 팀의 중복 투입, 재검증과 재작업, 계약 종료 조건, 귀사 자체의 선정 공수, 지연을 예산에 반영하십시오. 단계가 늦을수록 재작업이 많아집니다. 코드와 테스트는 마무리하기 전에 먼저 이해해야 하기 때문입니다.

SAP 구축 파트너를 교체하는 데 얼마나 걸립니까?

제 경험상 제대로 된 파트너 선정에는 약 12주가 걸리고, 숏리스트에는 최소 세 곳의 파트너가 오릅니다. 압박 속의 교체는 더 빨리 진행될 수도 있지만, 레퍼런스 통화와 실제 팀과의 제안 발표는 유지하십시오.

SAP 구축에서 나온 문서와 코드는 누구의 소유입니까?

그것은 계약이 정하므로 산출물 소유권 조항을 확인하십시오. 실무적으로는 문서를 귀사 자체 저장소나 SAP Cloud ALM 테넌트에, 코드와 구성을 파트너 서버가 아니라 귀사 SAP 시스템에 두어 스스로를 보호하십시오.