SAP 컨설턴트, 설계자와 시공자는 어떻게 다를까? (PI vs 구축 전격 비교!)

안녕하세요. Rabbit입니다! 🐰

“제 직업은 SAP 컨설턴트입니다.” 주변에서 이런 말을 들으면 어떤 이미지가 떠오르시나요?

아마 많은 분들이 비싼 정장을 입고, 어려운 용어를 써가며 멋진 PPT로 무언가를 발표하는 모습을 상상하실 겁니다. 틀린 말은 아니지만, ‘컨설턴트’의 세계는 생각보다 훨씬 더 다양하고 세분화되어 있답니다.

특히 SAP와 같은 거대한 IT 프로젝트의 세계에서는 더욱 그렇죠. 같은 ‘컨설턴트’라는 이름표를 달고 있지만, 하는 일은 하늘과 땅 차이인 두 그룹이 있습니다. 오늘은 바로 이 PI와 구축 컨설턴트의 차이점에 대해 이야기해보려고 해요. 마치 한 건물을 짓는 ‘설계자’와 ‘시공자’처럼 말이죠.

많은 분들이 헷갈려 하시는 IT 컨설팅의 두 세계, PI(Process Innovation) 컨설턴트과 구축(Implementation) 컨설턴트가 어떻게 다른지, 그리고 이 둘의 관계가 왜 프로젝트의 성패를 좌우하는지 속 시원하게 알려드릴게요!

SAP 컨설턴트_PI, 구축
SAP 프로젝트, 설계자는 PI 컨설턴트, 시공자는 구축 컨설턴트

PI (Process Innovation) 컨설턴트: 미래의 청사진을 그리는 ‘설계자’

SAP 프로젝트의 가장 첫 단추를 끼우는 사람들, 바로 PI 컨설턴트입니다. 이들은 주로 비즈니스 컨설턴트들이며, 기업의 ‘미래’를 그리는 역할을 합니다.

누가, 무엇을 할까?

  • 누가? 주로 경영 전략, 프로세스 혁신에 전문성을 가진 비즈니스 컨설턴트들입니다. 이분들은 회사의 큰 그림을 그리고, 비즈니스 본연의 가치를 극대화하는 방법을 고민해요.
  • 무엇을? 회사의 현재 일하는 방식(As-Is)을 면밀히 분석하고, 선진 사례 벤치마킹이나 핵심 성과 지표(KPI)를 기반으로 가장 이상적인 미래의 업무 프로세스(To-Be)를 설계합니다. 이들의 머릿속에는 오직 하나의 질문이 있습니다. “우리 회사가 글로벌 Top 수준이 되려면 앞으로 어떻게 일해야 하는가?”

PI 컨설턴트는 마치 미래 도시를 설계하는 설계자와 같습니다. 예산이나 기술적인 제약 같은 현실적인 문제보다는, 가장 효율적이고 최적화된 ‘꿈의 청사진’을 그리는 데 집중하죠. 그래서 그들의 결과물은 때로는 혁신적이고, 때로는 파격적으로 보이기도 합니다.


구축 (Implementation) 컨설팅: 청사진을 현실로 만드는 ‘시공자’

PI 컨설턴트가 그린 멋진 청사진을 넘겨받는 사람들이 바로 구축 컨설턴트입니다. 이들은 시스템, 특히 SAP에 정통한 기술 전문가들입니다.

누가, 무엇을 할까?

  • 누가? 특정 SAP 모듈(FI, CO, SD, MM, PP 등)에 대한 깊은 지식을 가진 모듈 컨설턴트와 코드를 짜는 ABAP 개발자 등 테크니컬 컨설턴트들입니다. 이분들은 SAP 시스템의 각 구성 요소와 기능을 손바닥 보듯 꿰고 있죠.
  • 무엇을? PI에서 설계한 To-Be 프로세스를 보며, 이것을 실제 SAP 시스템으로 구현해냅니다. 이들은 설계도만 보고 집을 짓지 않습니다. 현장의 땅(인프라), 예산, 사용 가능한 도구(SAP 표준 기능), 그리고 인력 상황까지 모두 고려해야 하죠.

구축 컨설턴트의 목표는 ‘뜬구름 잡는 시스템’이 아닌, ‘현실적으로 잘 돌아가는 SAP 시스템’을 만드는 것입니다. 이들은 설계도(PI)와 현실(현장 상황) 사이의 간극을 조율하며 ‘살아있는 시스템’을 만들어내는, 그야말로 ‘시공자’ 역할을 합니다. 간혹 이 과정에서 PI의 이상적인 요구사항과 현실적인 기술 구현 사이에서 줄다리기를 하기도 합니다.


이상과 현실의 충돌: “이 설계도대로는 못 지어요!”

여기서 흥미로운 점은, PI와 구축은 같은 컨설팅 회사가 진행하더라도 보통 소속 본부나 팀이 전혀 다르다는 것입니다. 심지어 PI는 A 회사가, 구축은 B 회사가 나눠서 진행하는 경우도 흔하죠. 이 때문에 두 세계의 충돌은 필연적으로 발생합니다.

구축 컨설턴트가 PI의 청사진을 받아들고 현실의 벽에 부딪히며 외치는 대표적인 말들은 이렇습니다.

  • 예산과 일정: “이사님, PI에서 그린 이 기능… 설계도대로 구현하면 비용이 두 배로 뛰고 프로젝트 기간도 6개월은 더 필요합니다!” (으악! 예상치 못한 추가 비용의 압박!)
  • 현장 인프라 부족: “실시간 창고 재고 입력을요? 현장 작업자분들께 PDA 장비도 아직 지급되지 않았는데요?” (이런, 시스템은 만들었는데 사용할 도구가 없으면 무용지물이죠.)
  • SAP 표준 기능의 한계: “이 기능은 SAP 표준에 없어서 처음부터 끝까지 CBO 개발(Z-코드)을 해야 합니다. 나중에 시스템 업그레이드나 유지보수는 어떻게 감당하시려고요?” (표준 기능을 벗어난 개발은 미래에 독이 될 수 있습니다!)

결국 PI 단계에서 장밋빛으로 그려졌던 이상적인 To-Be 모델은, 구축 단계에서 ‘현실화’ 과정을 거치며 축소되거나 변경되는 경우가 비일비재합니다. 마치 아무리 멋진 설계도라도, 현장의 지반이 약하면 기초를 보강하거나 구조를 변경해야 하는 것과 같죠.

SAP 컨설턴트_이상과 현실
이상과 현실 사이의 간극, PI와 구축 컨설팅의 영원한 숙제!

결국 중요한 건, 두 세계를 잇는 ‘균형’

그렇다면 PI는 몽상가이고 구축만 현실적인 걸까요? 절대 그렇지 않습니다. 두 역할은 SAP 프로젝트 성공을 위해 반드시 필요합니다.

  • PI 컨설턴트의 ‘이상’: 회사가 나아갈 방향을 제시하고, 전사적인 관점에서 최적의 목표를 설정합니다. 나침반 없는 배가 망망대해를 헤매는 것과 같죠.
  • 구축 컨설턴트의 ‘현실’: 그 목표를 안정적이고 지속 가능한 시스템으로 구현하여 실제 가치를 만들어냅니다. 아무리 좋은 나침반이 있어도 배가 없으면 항해할 수 없는 것처럼요.

이 두 세계가 서로를 이해하고 존중하며 균형을 이룰 때, SAP는 ‘비싸고 복잡한 엑셀’이라는 오명을 벗고 진정한 디지털 전환의 핵심 동력이 될 수 있습니다. 이는 마치 오케스트라의 지휘자와 연주자들이 각자의 역할을 존중하며 아름다운 하모니를 만들어내는 것과 비슷해요.

성공적인 SAP 프로젝트를 위한 Rabbit의 조언

Rabbit이 본 성공적인 SAP 프로젝트들은 보통 이렇게 문제를 풀어갑니다.

  1. PI 단계부터 현실 반영: PI 단계에 구축 전문가가 참여하여 기술적/비용적 검토를 함께 진행합니다. 초기 단계부터 ‘현실적인 제약’을 인지하고 설계하는 것이 중요합니다!
  2. 단계적 접근(MVP): 처음부터 모든 기능을 다 만들려 하지 않고, 가장 핵심적인 최소 기능(MVP: Minimum Viable Product)부터 오픈한 뒤 점차 고도화합니다. 일단 작은 성공을 맛보는 것이 중요하죠!
  3. 표준 기능 우선 원칙: 가급적 SAP 표준 기능을 최대한 활용하고, CBO 개발(Z-코드, 즉 커스터마이징 개발)은 최소화하여 유지보수 리스크를 줄입니다. 표준을 지키는 것이 장기적으로 비용 절감과 안정성을 가져옵니다.
  4. 변화 관리와 교육: 현장 사용자들이 “왜 이 시스템을 이렇게 써야 하는지” 충분히 공감하고 적응할 수 있도록 지속적인 교육과 변화 관리에 투자합니다. 아무리 좋은 시스템도 사람들이 쓰지 않으면 무용지물이에요! SAP 사용법을 익히고 시스템에 적응하는 과정은 마치 새로운 언어를 배우는 것과 같습니다.

PI 컨설턴트의 큰 그림과 구축 컨설턴트의 현실적인 구현, 이 두 가지가 조화를 이룰 때 비로소 프로젝트는 성공의 길로 나아갈 수 있습니다. ‘설계자’의 꿈과 ‘시공자’의 기술이 만나 멋진 건물을 완성하는 것처럼 말이죠. 이제 SAP 프로젝트의 두 축을 확실히 이해하셨나요? 😎

Similar Posts