
목차
SAP 작업기술서(SOW)는 파트너가 무엇을, 어느 정도의 공수로, 누구를 통해 수행하며, 그것이 어떻게 바뀔 수 있는지를 정하는 계약 문서입니다. 범위, 상세한 전제 조건과 제외 범위, 단계별, 역할별 공수, 인수 기준이 있는 산출물, 지명 인력, 변경 관리를 담아야 합니다.
대부분의 SOW는 범위는 그럭저럭 다룹니다. 고객이 흔히 빠뜨리는 것은 상세한 전제 조건과 제외 범위이며, 귀사가 최종적으로 얼마를 내게 될지를 결정하는 것이 바로 이 부분입니다.
이 글은 제 SAP 구축 파트너 선정 방법 가이드의 한 부분입니다. SOW는 SAP 파트너 RFP와 제안 발표 다음에 오는, 그 과정의 마지막 단계입니다. 서명 전 SOW 검토의 실제 사례는 ERP 계약 협상에 관한 제 사례 연구를 읽어 보십시오.
좋은 SAP SOW는 프로그램의 운영 매뉴얼처럼 읽힙니다. 귀사 측 누구라도 이 문서를 펼쳐 세 가지 질문에 답할 수 있어야 합니다. 무엇을 받는가, 그것은 무엇에 달려 있는가, 무언가 바뀌면 어떻게 되는가입니다.
SOW에 필요한 섹션과, 하나가 빠졌을 때 무엇이 잘못되는지는 다음과 같습니다.
| 섹션 | 담아야 할 내용 | 부실할 때 벌어지는 일 |
|---|---|---|
| 범위 | 범위에 포함되는 프로세스, 모듈, 회사 코드, 플랜트, 국가, 사용자 | 워크숍마다 무엇이 포함되었는지가 다시 논쟁거리가 됩니다 |
| 전제 조건 | 가격이 의존하는 조건과, 각 조건이 틀렸을 때의 결과 | 파트너가 올리는 변경 요청에 귀사가 반박할 수 없습니다 |
| 제외 범위 | 파트너가 하지 않을 일과 그 일을 대신 누가 하는지 | 일이 귀사와 파트너 사이로 빠지고 아무도 책임지지 않습니다 |
| 접근 방식과 단계 | 방법론, 단계별 계획, 품질 게이트 | 한 단계가 끝났다고 합의할 시점이 없습니다 |
| 공수 | 단계별, 역할별 예상 공수 | 공수 소진 속도가 계획대로인지 알 수 없습니다 |
| 산출물과 인수 | 이름이 정해진 문서와 결과물, 인수 기준, 승인 기간 | 미완성 작업에 대금이 지급됩니다 |
| 인력 | 지명된 핵심 인력, 역할, 투입률, 교체 규칙 | 제안 발표에서 만난 팀이 현장의 팀이 아닙니다 |
| 고객 책임 | 귀사 인력이 무엇을, 언제 제공해야 하는지 | 귀사 측에서 생긴 지연이 파트너의 변경 요청이 됩니다 |
| 변경 관리 | 변경을 제기하고, 평가하고, 가격을 매기고, 승인하는 방법 | 변경 요청이 두 번째 매출원이 됩니다 |
| 거버넌스 | 운영위원회, 보고, 에스컬레이션 | 문제가 비용이 커진 뒤에야 늦게 드러납니다 |
가격을 요청하기 전에 범위는 귀사가 직접 쓰십시오. 그래야 파트너가 자기 범위가 아니라 귀사의 범위에 가격을 매깁니다.
이것이 고객이 흔히 빠뜨리는 섹션입니다. 이것이 없으면 가격은 귀사 측 누구도 읽거나 동의하지 않은 조건 위에 놓이게 됩니다.
전제 조건은 파트너가 가격을 매길 때 기준으로 삼은 조건입니다. 제외 범위는 파트너가 아예 가격을 매기지 않은 일입니다. 둘 다 제3자가 그것이 지켜졌는지 확인할 수 있을 만큼 구체적이어야 합니다.
적어 두어야 할 전제 조건 유형
모든 전제 조건에는 결과가 필요합니다. 「이것이 틀린 것으로 드러나면, 그 변경은 영향 평가와 함께 변경 관리 절차를 거친다」라는 문장이 전제 조건을 장식에서 통제 수단으로 바꿉니다.
SAP SOW가 다뤄야 할 범주는 다음과 같습니다.
- 조직 범위. 가격이 포함하는 회사 코드, 플랜트, 판매 조직, 국가, 법인의 수입니다.
- 프로세스 범위. 범위에 포함되는 비즈니스 프로세스의 명칭, 그리고 파트너가 귀사에 채택을 기대하는 SAP 표준 프로세스입니다.
- WRICEF 물량. 워크플로, 리포트, 인터페이스, 데이터 변환, 기능 확장, 양식의 수를 복잡도별로 적습니다. 이 목록이 늘어나면서 Explore 단계에서 예산이 타격을 입으므로, 기준 수량은 계약에 들어가야 합니다.
- 데이터. 이관할 데이터 오브젝트, 이력 데이터의 양, 모의 이관 횟수, 데이터 정제 담당자입니다.
- 인터페이스. 인터페이스마다 이름, 상대편 시스템, 그 시스템을 누가 변경하는지를 적습니다.
- 테스트. 테스트 사이클 수, 시나리오 작성자, 수행자, 결함 수정 담당자입니다.
- 고객 측 투입. 귀사의 어떤 인력이 얼마만큼의 시간으로 필요한지, 의사결정을 얼마나 빨리 내려야 하는지입니다.
- 환경과 라이선스. 시스템, 도구, 접근 권한을 누가 언제까지 제공하는지입니다.
- 장소와 언어. 팀이 일하는 장소, 온쇼어와 오프쇼어 비율, 출장, 문서와 교육에 쓰는 언어입니다.
- 교육과 하이퍼케어. 교육 모델, 교육받는 사내 강사 수, 하이퍼케어의 기간과 종료 기준입니다.
예산에 가장 중요한 것은 WRICEF 기준 수량입니다. SAP의 자체 교육 자료는 Explore 단계를 Fit-to-Standard 분석으로 설명하며, 이 단계에서 승인된 차이 요구사항이 Realize 단계를 위한 제품 백로그에 추가됩니다(SAP Learning). 승인된 차이 하나하나가 새로운 WRICEF 공수가 될 수 있으므로, 증가를 잴 시작 수량이 필요합니다.
적어 두어야 할 제외 범위 유형
제외 범위에는 그 일을 대신 누가 하는지를 적어야 합니다. 담당자 없이 「제외」라고만 적힌 항목은 컷오버 중에 발견되기를 기다리는 빈틈입니다.
일반적인 범주는 다음과 같습니다.
- 레거시 시스템의 데이터 정제와 보강. 대개 고객의 일입니다.
- 인터페이스 반대편에 있는 서드파티 시스템과 레거시 시스템의 변경.
- 소프트웨어 라이선스와 구독. SOW가 아니라 귀사와 SAP 간의 계약에 들어갑니다.
- 인프라와 호스팅. 파트너가 명시적으로 운영하는 경우가 아니라면 제외입니다.
- 최종 사용자 교육 진행. 파트너가 귀사의 사내 강사만 교육하는 경우입니다.
- 명시된 범위를 넘는 조직 변화관리.
- 보안, 역할, 권한 설계. 다른 주체가 담당하는 경우입니다.
- 지정된 사이클 밖의 성능, 침투, 회귀 테스트.
- 조직 범위에 없는 국가, 법인, 현지화.
- 하이퍼케어 이후의 애플리케이션 지원. 별도 계약입니다.
두 목록을 프로그램 디렉터와 나란히 놓고 읽으십시오. 어느 목록에도 없는 것이 바로 변경 요청이 나올 곳입니다.
제가 SAP 구축에 권하는 상업 모델은 공수를 정량화한 투입 공수 기반(T&M) 방식입니다. 단계별, 역할별 예상 공수를 계약에 적어, 매달 실제 공수를 그 기준과 대조해 추적할 수 있게 하는 것입니다.
이사회에는 고정가가 더 안전해 보입니다. 실제로는 모든 전제 조건이 유지되는 동안에만 가격이 고정되고, SAP 프로그램은 Explore가 끝날 무렵이면 그 대부분을 시험대에 올립니다. 고정가 단계가 그래도 타당한 경우는 SAP 구축 비용에 관한 제 글에서 다룹니다.
SOW에서 두 모델을 비교하면 다음과 같습니다.
| 비교 항목 | 고정가 | 공수를 정량화한 T&M |
|---|---|---|
| 계약이 고정하는 것 | 전제 조건이 유지되는 동안의 가격 | 단가, 그리고 단계별, 역할별 예상 공수 |
| 리스크의 위치 | 파트너가 예비비로 가격에 반영 | 귀사에 있지만 매달 보임 |
| 범위가 움직일 때 | 모든 변경이 협상이 됨 | 공수가 움직이고, 귀사는 그것을 추정치와 대조해 봄 |
| 추적할 수 있는 것 | 마일스톤과 변경 요청 | 단계별, 역할별 계획 대비 실제 공수 |
| 귀사를 보호하는 것 | 빈틈없는 전제 조건과 제외 범위 | 빈틈없는 전제 조건, 제외 범위, 공수 보고 |
공수를 정량화하면 T&M이 백지수표에서 통제된 예산으로 바뀝니다. 추정치를 단계 대 역할의 표로, 인일(person-day) 단위로 요청하고, 그 표에 대한 월간 보고를 계약상 의무로 만드십시오.
단가가 공수 속에 숨지 않게 하십시오. 역할 구성은 제 SAP 프로젝트 자원 배분 계획 가이드를 이용해 시장 단가와 비교해 보십시오.
초반에는 시니어 투입일이 많고 후반에는 주니어 투입일이 많은 계획은 흔합니다. 그 반대라면 설명이 필요합니다.
고객이 빠뜨리는 부분이 바로 청구액을 결정하는 부분입니다. 상세한 전제 조건과 제외 범위입니다.
산출물은 완료 정의가 있는, 이름이 정해진 결과물입니다. 「설계 지원」은 산출물이 아닙니다. 합의된 기준에 따라 검토되고 서명된 Record to Report 솔루션 설계 문서는 산출물입니다.
인수를 품질 게이트에 연결하기
SAP Activate는 Discover, Prepare, Explore, Realize, Deploy, Run의 여섯 단계로 진행됩니다. SAP는 각 단계 후에 공식 품질 게이트를 두어, 프로젝트가 다음으로 넘어가기 전에 해당 단계의 산출물이 완료되었는지 확인한다고 설명합니다(SAP Learning).
이 게이트를 SOW에 활용하십시오. 각 게이트에서 제출할 산출물, 인수 기준, 귀사의 검토 기간(일수)을 나열하십시오. 대금 지급은 달력이 아니라 인수된 산출물에 연결하십시오.
귀사 측의 누군가는 그 문서들을 판단할 수 있어야 합니다. 이것이 제가 독립 컨설턴트를 들이기를 권하는 세 지점 중 하나입니다. 계약 단계, 설계, 그리고 파트너 산출물 평가입니다. 두 역할이 어떻게 함께 일하는지는 SAP 파트너와 독립 컨설턴트에 관한 제 글에서 설명합니다.
사람의 이름을 명시하고 확인하기
제안된 인력의 수준이 낮은 것은 제가 입찰에서 돌아서게 만드는 두 가지 중 하나입니다. 다른 하나는 아키텍처와 계획을 설명하지 못하는 파트너입니다.
SOW에는 솔루션 아키텍트, 프로그램 매니저, 그리고 각 기능 및 기술 리드의 이름이 들어가야 합니다. 그들의 투입률, 교체 인력에 대한 귀사의 면접권, 모든 교체에 대한 귀사의 승인을 적어 넣으십시오. 지명 인력 조항이 실제로 어떻게 쓰이는지는 ERP 계약 협상 사례 연구에서 보여 드립니다.
이력서를 그대로 믿지 말고 자격증을 확인하십시오. SAP는 실시간 확인을 지원하는 Credly를 통해 자격 배지를 발급합니다(SAP Learning). SAP의 자격 유지(stay certified) 절차에 따라, 보유자가 필수 평가를 놓치면 자격이 만료됩니다(SAP Learning).
이 조항은 보기보다 중요합니다. 저는 프로그램 도중에 파트너를 바꾼 적이 있고, 계기는 파트너가 수준 있는 인력을 제공하지 못한 것이었습니다. 그 상황에 이르기 전에 무엇을 확보해야 하는지는 제 프로젝트 도중 SAP 파트너 교체 가이드에서 다룹니다.
변경 관리는 부실한 SOW가 비싸지는 지점입니다. 전제 조건이 모호하면 거의 무엇이든 변경이라고 주장할 수 있습니다.
실효성 있는 변경 관리 섹션에는 다음 요소가 필요합니다.
- 발생 조건. 변경은 전제 조건이 깨지거나, 제외 범위가 범위 안으로 들어오거나, 귀사가 새로운 것을 요청할 때에만 존재합니다.
- 영향 평가. 작업 시작 전에 범위, 역할별 공수, 일정, 비용을 서면으로 평가합니다.
- 단가표. 변경은 계약 단가로 가격을 매기며, 합의하지 않는 한 긴급 할증은 없습니다.
- 승인 권한. 귀사 측에서 누가 어느 금액까지 변경을 승인할 수 있는지 정하고, 정해진 기준액을 넘으면 CFO가 승인합니다.
- 변경 기록부. 승인되었든 반려되었든 모든 변경을 누계와 함께 운영위원회에 보고합니다.
- 기준선과의 연결. 새로운 WRICEF 오브젝트는 전제 조건에 적힌 수량과 대조해 측정합니다.
파트너는 정당한 변경도 제기할 것입니다. SAP 프로그램에서는 계약 서명 시점에 아무도 몰랐던 것들이 드러납니다. 목표는 누구든 돈을 쓰기 전에 각 변경이 보이고, 가격이 매겨지고, 승인되게 하는 것입니다.
제가 이끌었거나 구해 낸 21개의 SAP 프로그램에서 가장 크게 본 실수는 시작 단계에서 계획을 제대로 세우지 않는 것입니다. SOW는 그 계획이 구속력을 갖게 되는 곳이며, 여기에 들이는 시간은 분쟁이 된 변경 요청에 비하면 저렴합니다.
구체적인 다음 단계는 이렇습니다. 지금 앞에 있는 SOW를 꺼내 모든 전제 조건과 제외 범위를 한 페이지에 나열하십시오. 각 항목 옆에 그것이 틀렸을 때 어떻게 되는지, 누가 비용을 내는지를 적으십시오. 그 열을 채울 수 없다면 그 SOW는 아직 서명할 준비가 되지 않은 것입니다.
서명 전에 SAP 작업기술서를 독립적으로 검토받고 싶으시다면, 저는 계약 단계에서 고객을 돕고 있습니다. 여기에서 저에게 연락하실 수 있습니다.
SAP 작업기술서에는 무엇이 들어가야 합니까?
범위, 상세한 전제 조건, 제외 범위, 접근 방식과 단계, 단계별, 역할별 예상 공수, 인수 기준이 있는 산출물, 지명 인력, 고객 책임, 변경 관리, 거버넌스입니다. 가장 자주 부실하게 남는 부분이 전제 조건과 제외 범위이며, 최종 비용을 결정하는 것이 바로 이 부분입니다.
SAP SOW에서 전제 조건과 제외 범위는 무엇이 다릅니까?
전제 조건은 회사 코드나 WRICEF 오브젝트의 수처럼 파트너가 가격을 매길 때 기준으로 삼은 조건입니다. 제외 범위는 레거시 데이터 정제처럼 파트너가 아예 가격을 매기지 않은 일입니다. 각 전제 조건에는 그것이 틀렸을 때 어떻게 되는지를, 각 제외 범위에는 그 일을 대신 누가 하는지를 적어야 합니다.
SAP 구축에는 고정가와 T&M 중 무엇이 더 낫습니까?
저는 공수를 정량화한 T&M 방식을 권합니다. 단계별, 역할별 예상 공수를 계약에 적고 매달 추적하는 것입니다. 고정가는 모든 전제 조건이 유지되는 동안에만 유지되며, SAP 프로그램은 Explore 단계에서 대부분의 전제 조건을 시험대에 올립니다.
SAP 산출물의 인수 기준은 어떻게 정합니까?
각 산출물의 이름을 정하고, 완성된 모습이 어떤지 기술하고, 귀사 팀의 검토 기간을 정하십시오. 이를 각 단계 끝의 SAP Activate 품질 게이트에 연결하고, 산출물이 인수되었을 때에만 대금을 지급하십시오.
SAP SOW에 컨설턴트 이름을 명시해야 합니까?
네, 핵심 역할에 대해서는 그렇습니다. 솔루션 아키텍트, 프로그램 매니저, 기능 및 기술 리드입니다. 그들의 투입률, 교체 인력에 대한 귀사의 면접권, 모든 교체에 대한 귀사의 승인을 추가하십시오. 자격증은 이력서에 의존하지 말고 Credly의 SAP 배지로 확인하십시오.
SAP 작업기술서는 누가 작성해야 합니까?
초안은 파트너가 쓰지만, 범위와 전제 조건은 귀사에서 나와야 합니다. 시장에 나가기 전에 범위를 쓰고, 서명 전에 파트너와 독립적인 사람이 전제 조건, 제외 범위, 산출물을 검토하게 하십시오.
다음 단계
지금 ERP 프로젝트를 진행 중이십니까?
이 글이 지금 진행 중인 프로젝트와 맞닿아 있다면, 30분 대화가 일주일간의 내부 분석보다 대개 더 많은 진전을 가져옵니다.




