2026년 ERP 구축 팀: 필요한 인력과 각자의 역할

ERP 구축 팀에는 권한을 가진 스폰서, ERP를 아는 프로젝트 매니저, 영향을 받는 모든 기능 부서의 비즈니스 프로세스 오너, 기능 컨설턴트와 기술 컨설턴트, 그리고 통합, 데이터 마이그레이션, 테스트, 변화관리, 컷오버를 맡는 전담 리드가 필요합니다. 클라우드 SAP 프로젝트에는 클린 코어 아키텍트와 지정된 SAP 담당자가 더해집니다. 팀 규모는 회사 인원이 아니라 복잡도로 정하고, 모든 컨설턴트에게 Go-Live 이후 해당 영역을 책임질 내부 담당자를 한 명씩 짝지어 주십시오.

이 글은 ERP 프로젝트에 인력을 배치하는 스폰서, CIO, 프로그램 디렉터를 위한 것입니다. 역할, 각 역할이 성공하거나 실패하는 요인, 팀 규모, 클라우드 ERP와 AI가 바꾸는 것, 그리고 구축 파트너와 업무를 나누는 방법을 다룹니다.

제가 함께 일한 한 회사는 ERP 구축 두 건을 동시에 진행하고 있었습니다. 하나는 SAP, 다른 하나는 Oracle이었습니다. Oracle 프로젝트에는 4,500명이 투입되었고 SAP 프로젝트에는 38명이 투입되었습니다. 한쪽은 순조롭게 가동되었고, 다른 쪽은 끝나지 않는 재앙이었습니다. 차이는 팀이었습니다.

25년간 SAP 구축을 해 왔지만 이 패턴은 달라지지 않았습니다. 팀을 잘못 꾸리거나, 맞는 사람들을 잘못된 구조에 앉히면 프로젝트는 늘어지고 비용은 오르며, Go-Live 시점에는 사용자들이 이미 그 시스템을 싫어하기로 마음먹은 뒤입니다.

1. 프로젝트 스폰서장애물을 치우고, 예산을 확보하고, 부서 간 결정을 내립니다
   SAP 서비스 담당자RISE 프로젝트에서 플랫폼 에스컬레이션과 서비스 리뷰
2. 프로젝트 매니저일정, 범위, 리스크, 파트너 조율

• 비즈니스 프로세스 오너설계를 검증하고 실제 업무 흐름을 테스트
• 기능 및 기술 컨설턴트구성, 확장, 그리고 반박
• 데이터 마이그레이션 리드정제, 적재, 컷오버 데이터
• 통합 리드미들웨어 설계와 데이터 흐름
• 변화관리 및 교육 리드소통, 챔피언, 정착
• 클린 코어 아키텍트클라우드 에디션에서 모든 확장이 놓일 위치

역할	실제로 하는 일	참여 시기
프로젝트 스폰서	장애물을 치우고, 예산을 확보하고, 부서 간 결정을 내립니다	전 단계
프로젝트 매니저	일정, 범위, 리스크, 파트너 조율을 운영합니다	전 단계
비즈니스 프로세스 오너	설계를 검증하고, 시나리오를 테스트하고, 실제 업무 흐름을 대변합니다	Explore에서 Deploy까지
기능 컨설턴트	요구사항을 수집하고, 모듈을 구성하고, 테스트를 지원합니다	Explore에서 Deploy까지
기술 컨설턴트	확장, 인터페이스, 시스템 설정	Realize에서 Deploy까지
통합 리드	시스템 간 미들웨어 설계와 데이터 흐름	Explore에서 Deploy까지
데이터 마이그레이션 리드	데이터 전략, 정제, 적재, 컷오버 데이터	Prepare에서 Deploy까지
변화관리 및 교육 리드	교육, 소통, 정착 활동	Explore에서 Run까지
테스트 리드	테스트 스크립트, SIT, UAT, 결함 추적	Realize에서 Deploy까지
컷오버 매니저	운영 전환, 다운타임, 롤백 계획	Deploy
클린 코어 아키텍트(클라우드 에디션)	모든 확장을 어디에, 어떤 클린 코어 레벨로 둘지 결정합니다	Explore에서 Run까지
SAP 서비스 담당자(RISE)	플랫폼 에스컬레이션, 서비스 리뷰, SAP 로드맵 정렬	Prepare에서 Run까지

제 SAP 구축 팀 역할 글에서 역할별로 더 자세히 다룹니다.

프로젝트 스폰서

스폰서의 일은 프로젝트 헌장에 서명하고 사라지는 것이 아닙니다. 부서 간 의견이 갈릴 때 결정할 권한을 가진 사람이 프로젝트 매니저 위에 없으면 프로젝트는 몇 달씩 멈춥니다. 스폰서는 연락이 닿아야 하고, 어려운 결정을 내릴 의지가 있어야 하며, 킥오프 때만이 아니라 안정화까지 자리를 지켜야 합니다.

잘못되는 경우는 모든 것을 IT에 넘기는 스폰서입니다. ERP는 비즈니스가 돌아가는 방식을 바꿉니다. 경영진이 이끌지 않으면 실패합니다. 운영위원회 가이드에서 스폰서의 회의체를 어떻게 구성하는지 다룹니다.

프로젝트 매니저

ERP 프로젝트 매니저는 일반적인 IT 프로젝트 관리만이 아니라 SAP나 Oracle 프로젝트가 실제로 어떻게 돌아가는지 알아야 합니다. 리스크, 의존 관계, 컷오버 시점의 압박이 다르기 때문입니다.

잘못되는 경우는 범위 문제에서 컨설턴트에게 끌려가거나, 테스트 기한을 비즈니스에 지키게 하지 못하는 프로젝트 매니저입니다.

비즈니스 프로세스 오너

IT가 귀사의 비즈니스를 운영하는 것은 아닙니다. 운영, 재무, 구매, 인사 부서가 합니다. 프로세스 오너는 시스템이 서류상이 아니라 실제 프로세스에서 작동하게 만듭니다. 이들을 빼면 워크숍에서는 말이 되었던 구성이 첫 주에 무너집니다.

처음부터 참여시키십시오. 자신이 참여하지 않은 결정을 승인하라고 UAT 때 불러서는 안 됩니다.

ERP 컨설턴트

좋은 컨설턴트는 반박합니다. 모든 것에 동의하고 요구사항 하나 따져 묻지 않는 컨설턴트라면 전문성을 더하는 것이 아니라 시간을 청구하고 있는 것입니다. 최고의 컨설턴트는 몇 달을 날릴 실수를 미리 막습니다.

약한 컨설턴트의 신호 하나는 과도한 커스터마이징입니다. 비즈니스가 왜 프로세스를 바꿔야 하는지 설명하는 것보다 쉽기 때문입니다. 커스텀 프로그램은 모두 유지보수하고, 업그레이드 때 테스트하고, 다음 팀에 설명해야 합니다. SAP의 클린 코어 레벨 덕분에 이 부채는 이제 눈에 보입니다. 예전 방식으로 만든 확장은 레벨 C나 D에 놓이고, 첫 대규모 업그레이드에서 드러납니다.

데이터 마이그레이션 리드

기존 시스템의 나쁜 데이터는 새 시스템의 나쁜 데이터가 됩니다. 마이그레이션 전에 데이터 품질을 논의할 책임자가 없으면 첫날부터 재무 보고서가 현실과 맞지 않습니다.

데이터 마이그레이션은 비즈니스가 책임져야 하는 비즈니스 프로세스입니다. 데이터를 옮기는 일은 IT가 할 수 있습니다. 그 데이터가 맞는지 확인하는 일은 비즈니스의 몫입니다.

변화관리 및 교육 리드

변화관리는 교육이 아닙니다. 소통, 이른 참여, 그리고 Go-Live 전에 비즈니스 안에서 챔피언을 찾는 일입니다. 교육이면 충분하다고 가정하면, 새 시스템을 신뢰하지 않는 사용자들은 스프레드시트로 돌아가고, Go-Live 이후에 이를 바로잡는 데는 큰 비용이 듭니다.

이 리드는 콘텐츠를 만들고, 파일럿을 운영하고, 준비도를 측정해야 합니다. Go-Live 2주 전에 PDF 한 장을 나눠 주는 사람이 아닙니다. SAP 프로젝트에서는 이제 디지털 어댑션 도구도 이들의 몫입니다. SAP는 2024년에 인수한 WalkMe로 SAP Enable Now를 통합하고 있으므로, 새 콘텐츠는 WalkMe에서 계획해야 합니다.

클린 코어 아키텍트(클라우드 에디션)

SAP는 이제 모든 확장을 A부터 D까지 네 가지 클린 코어 레벨로 분류합니다. 각 갭을 표준 구성으로 해결할지, SAP BTP 위의 레벨 A 확장이나 ABAP Cloud 기반 온스택으로 해결할지, 아니면 아예 하지 않을지를 누군가는 정해야 합니다. 대규모 프로젝트에서는 전담 역할입니다. 중견기업 프로젝트에서는 보통 솔루션 아키텍트가 겸합니다.

SAP BTP와 ABAP Cloud 경험이 없는 파트너는 이 역할을 맡을 수 없습니다. 이 규칙에 따라 확장을 몇 건 인도했는지 묻고, 실제 사례를 보여 달라고 요청하십시오.

SAP 서비스 담당자(RISE 프로젝트)

RISE with SAP 환경에서는 SAP가 시스템의 인프라와 운영을 맡으므로 SAP도 딜리버리의 일부입니다. CIO에게는 플랫폼 에스컬레이션, 서비스 리뷰, 로드맵 정렬을 위한 지정된 SAP 담당자가 필요합니다. 그 사람을 운영위원회 초대 명단에만 올리지 말고 Prepare 단계부터 팀 명단에 올리십시오.

팀 규모는 인원 수가 아니라 복잡도에 맞춰야 합니다.

회사 유형	일반적인 팀 규모	복잡도를 좌우하는 요인
소규모(단일 법인, 직원 500명 미만)	10-25명	대부분 표준 기능, 적은 통합
중견기업(다수 사업장, 직원 500-5,000명)	30-75명	더 많은 통합, 지역별 프로세스 변형, 대규모 변화관리
대기업(글로벌, 직원 5,000명 이상)	100-500명 이상	다수의 법인과 통합, 여러 관할권에 걸친 컴플라이언스

복잡한 수주 생산 방식의 제조를 운영하는 직원 50명 규모의 공장은, 표준 유통 프로세스를 운영하는 직원 500명 규모의 회사보다 더 크고 더 전문화된 팀이 필요할 수 있습니다. 해야 할 일을 기준으로 규모를 정하십시오. SAP 프로젝트 자원 배분 계획 가이드에서 계획을 세우는 방법을 보여 드립니다.

Joule은 이제 SAP의 구축 도구(SAP Cloud ALM과 SAP Activate Roadmap Viewer)에 들어와 있습니다. SAP Build Code는 Joule을 활용해 개발자가 SAP BTP에서 확장을 만들도록 돕습니다. Microsoft Copilot은 상태 보고서, 운영위원회 브리프, 변화관리 커뮤니케이션의 초안을 작성합니다.

일관되게 쓰면 이 도구들은 워크플로 중심 역할의 속도를 높입니다. 같은 범위가 몇 년 전에 필요로 했을 규모보다 프로젝트가 다소 가벼워지지만, 극적으로 작아지지는 않습니다.

이 도구들을 역할 정의에 명시하십시오. 기능 컨설턴트는 요구사항과 fit-gap 문서의 초안을 쓰는 데 AI를 씁니다. 프로젝트 매니저는 상태 보고에 씁니다. 개발자는 도움이 되는 곳에 씁니다. AI가 바꾸지 못하는 것은 책임입니다. 초안은 더 빨리 나오지만, 그 초안이 담은 내용은 여전히 사람이 책임집니다.

대부분의 기업은 비즈니스를 아는 내부 핵심 팀과, 기술과 방법론의 깊이를 가져오는 파트너를 결합합니다.

내부 팀은 상태 회의에 출석하는 수준이 아니라 실제로 참여해야 합니다. 그렇지 않으면 프로젝트는 파트너만 이해하고 회사 안에서는 아무도 운영할 수 없는 시스템을 인도하게 됩니다.

파트너에게 기대할 것은 구조, 더 빠른 의사결정, 그리고 귀사와 같은 종류의 실수를 겪어 본 경험입니다. 맡기지 말아야 할 것은 범위 결정, 프로세스 설계 승인, 사용자 준비도입니다. 이 일들에는 내부 책임자가 필요합니다.

꾸준히 통하는 모델은 섀도 페어링입니다. 컨설턴트마다 Go-Live 후 그 영역을 책임질 내부 카운터파트가 있습니다. 컨설턴트가 인도하고, 내부 담당자가 배우며, 컨설턴트가 떠난 뒤에도 지식이 남습니다.

파트너를 검증할 때는 벤더의 쇼케이스 고객이 아니라 귀사와 규모와 업종이 같은 회사의 레퍼런스를 요청하십시오. 클린 코어 경험을 사례와 함께 묻고, RISE 프로젝트에서 SAP와 어떻게 협업하는지 물으십시오. 모호한 답은 누가 현재의 SAP를 알고 있고 누가 3년 전에 알던 SAP를 팔고 있는지 알려 줍니다.

ERP 구축 팀은 몇 명으로 구성됩니까?

회사 규모보다 복잡도에 따라 달라집니다. 프로세스가 단순한 소규모 기업은 보통 10-25명, 여러 사업장을 가진 중견기업은 30-75명, 글로벌 대기업은 100-500명 이상이 필요합니다. 주문 설계 생산 프로세스가 복잡한 제조업체는 표준 유통 기능을 운영하는 더 큰 회사보다 많은 인력이 필요합니다.

클라우드 SAP 프로젝트에는 어떤 새로운 팀 역할이 필요합니까?

두 가지입니다. 하나는 모든 확장이 어디에, 어떤 클린 코어 레벨로 놓일지 정하는 클린 코어 아키텍트 또는 확장 리드입니다. 규모가 작은 프로젝트에서는 솔루션 아키텍트가 이를 맡습니다. 다른 하나는 RISE with SAP에서 에스컬레이션과 서비스 리뷰를 위해 지정하는 SAP 서비스 담당자입니다. SAP가 시스템의 인프라와 운영을 맡기 때문입니다.

ERP 구축에서 프로젝트 스폰서의 역할은 무엇입니까?

스폰서는 예산을 확보하고, 장애물을 치우고, 부서 간 의견이 갈릴 때 결정합니다. 프로젝트를 직접 관리하는 사람이 아니라 프로젝트가 관리 가능한 상태가 되도록 만드는 사람입니다. 스폰서가 하는 가장 중요한 일은 안정화까지 관여를 유지하는 것입니다. 컷오버 이후 경영진의 관심을 잃은 프로젝트에서는 수년간 이어지는 임시방편이 생겨납니다.

ERP 구축에 왜 비즈니스 프로세스 오너가 필요합니까?

재무, 운영, 인사, 구매 부서 사람들이 일이 실제로 어떻게 돌아가는지 알기 때문입니다. 이들이 없으면 팀은 서류상으로만 말이 되고 실무에서는 실패하는 시스템을 설계합니다. 처음부터 워크숍과 설계 결정에 참여시키십시오. UAT 단계에서는 잘못된 부분을 고치기에 이미 비용이 너무 큽니다.

ERP 컨설턴트를 고를 때 무엇을 봐야 합니까?

반박할 줄 아는지 보십시오. 모든 것에 동의하는 컨설턴트는 귀사가 아니라 자기 일을 편하게 만들고 있는 것입니다. 좋은 컨설턴트는 잘못된 요구사항에 이의를 제기하고, 범위 확대를 짚어 내고, 왜 대개 커스텀보다 표준이 더 낫다고 설명합니다. 그다음에는 클린 코어 경험을 사례로 확인하고, 직접 연락해 볼 수 있는 비슷한 규모의 레퍼런스를 확인하고, 귀사의 문제를 풀고 있는지 아니면 이미 인도할 줄 아는 프로젝트를 팔고 있는지 살피십시오.

ERP 구축에서 데이터 마이그레이션은 어떻게 다룹니까?

전략, 정제 규칙, 적재, Go-Live 검증을 책임지는 전담 리드를 두십시오. 데이터 품질의 주인은 비즈니스입니다. IT는 공급업체 레코드 하나를 옮길 수 있지만, 그것이 맞는지는 비즈니스만 압니다.

ERP 프로젝트에서 변화관리란 무엇이며 왜 중요합니까?

Go-Live 전, 중, 후에 업무 방식의 큰 변화에 대비하도록 사람들을 준비시키는 일입니다. 소통(무엇이 왜 바뀌는지를 일찍 알리기), 참여(핵심 사용자가 설계와 테스트에 참여하기), 지원(동료의 적응을 돕는 챔피언)을 포함합니다. 이를 교육 일정표로만 취급한 프로젝트는 매번 같은 결과를 얻습니다. 임시방편, 스프레드시트, 아무도 신뢰하지 않는 시스템입니다.