갑자기 PI 프로젝트를 해야 한다면

 
 
 
 
 

ERP 구축만 하다가 갑자기 PI 프로젝트를 해야 한다면 어떻게 할까?

 
 
 
 
 
 
 
마침 요즘 새롭게 PI 프로젝트를 하고 있고, 지금까지 4주 정도 됐다.
 
바로 직전 프로젝트는 ERP 구축 프로젝트였고 거의 2년 가까이 진행했었다. 그러다보니 PI는 오랜만이라 뇌를 스위칭하는데 조금 어려움이 있지만, 그래도 재미있다. 확실히 구축 프로젝트와는 뇌의 다른 부분을 사용해야 하는 게 느껴진다.
 
구축과는 정말 느낌이 다르다. 일하는 동료들도 다르고, 고객이 우리에게 기대하는 것도 다르다. 업무적으는 오히려 내가 학생 때 생각하던 "컨설턴트"에 더 가깝게 느껴진다.
 
지난 글 『SAP 운영에서 구축으로 넘어가기 위해 필요한 능력』에서 썼듯이 나는 ERP 운영 출신이다. 출신이 이런지라 아무래도 PI 컨설팅에서 필요한 역량을 이 회사에 오기 전에는 배우지 못했었다.
 
그래도 운이 좋게 이직 후 PI 프로젝트를 할 기회가 두어 번은 있었고, 훌륭하신 분들과 사내 교육 자료를 통해서 많이 배웠다. 앞으로 더 배워야 할 게 많긴 하지만... 그래도 이번 플젝이 PI여서 좋다. 부족한 부분을 채울 수 있는 기회니까.
 
이번 글에서는 1. 구축 프로젝트와 PI 프로젝트는 뭐가 다른지, 2. 나같이 SAP 구축/운영만 하던 사람이 PI를 왜 어려워 하는지, 3. PI 프로젝트의 매력 포인트는 무엇일지를 생각해보고자 한다.
 
 
 
 
 

---

 
 
 
 

1. PI 프로젝트는 구축 프로젝트와 뭐가 다른가?

 
 

1-1. PI란 무엇인가?

우선 PI란 무엇인가? PI는 Process Innovation의 약자이다. 여기서 말하는 프로세스 혁신이란 '기업의 구성요소 전반을 변화시키는 것'이라고 할 수 있다.
 
교과서적인 얘기는 잠시 치워두고 보자. 뭘 바꾼다는 건가? 여기서 바꾸는 것은 기업의 "전략"이 아니다. 즉, 신사업에 진출하거나, 기존 사업을 접거나, 새로운 기술에 투자하는 등 전략적 의사결정을 바꾸자는 게 아니다. 그건 전략 컨설팅에서 하는 일이다.
 
PI에서는 이런 전략이 고정된 상황에서 개선 요소를 찾는 게 목표이다.
전략이 고정된 상황이란 다시 말해 영업환경, 생산설비, 생산기술, 인적자원이 바뀌지 않는 상황이란 가정이 깔린다.
 
그리고 이 안에서의 개선요소란 회사의 핵심성과지표를 향상시키기 위한 것이다. 이는 고객만족, 효율화, 속도개선, 품질향상 등을 말한다. 궁극적으로는 이를 통해 매출과 이익을 포함한 기업가치가 증가된다고 본다.
 
 

1-2. PI는 어떤 식으로 진행되는가?

 
PI 프로젝트는 보통 ① Access, ② Visioning, ③ Design의 3단계로 이뤄진다. 요약하자면 문제를 알고(Access), 지향점을 설정하고(Visioning), 어떻게 달성할지를 제시하는 것이다(Design).
 
각 단계별로 구체적으로 뭘 하는지는 컨설팅 회사의 내부적인 방법론이기도 하므로, 여기서는 생략하겠다.
 
 

1-3. PI의 두 가지 유형

 
요즘 PI는 보통 두 가지 유형으로 나뉜다. "순수 PI"와 "(ERP 구축을 위한) 사전 PI"다.
 
순수 PI는 대규모 ERP 구축을 고려하지 않은 PI다. PI의 결과가 단위 시스템 구축으로 이어질 수는 있지만, 처음부터 ERP 구축이라는 큰 변화를 염두에 두진 않는다. 따라서 시스템적 제약은 크게 생각하지 않고 순수하게 제도나 조직의 변화, 일의 내용이나 절차를 변경하는 과제를 수행한다.
 
다만 일의 내용이나 절차를 변경함에 있어 시스템과 분리할 수 없기 때문에, 어느 정도의 시스템과 관련한 설계 역량을 필요로 한다. 그렇지만 ERP 구축을 위한 사전 PI에 비해서 강하게 요구되지는 않는 편이다. ③ Design 단계에서 상세 프로세스 설계는 하지만, 시스템과 연계된 부분은 간단한 기능요건 정의 정도로 끝나곤 한다.
 
사전 PI는 애초부터 대규모 ERP 구축을 염두에 두고 시작하는 PI이다. 따라서 To-Be의 결과는 ERP로 구현될 수 있게끔 나와야 한다. 이 때에도 순수 PI처럼 ① Access, ② Visioning, ③ Design의 3단계는 다 수행한다. 다만, 순수 PI에 비해서 ③ Design 단계에서의 역량이 강조 된다. "설계한 내용이 ERP 구축되기에 바람직한 설계인지"가 중요하다.
 
 
 

2. 왜 PI 프로젝트를 어려워 할까?

 
그럼 왜 나같은 SI/SM 출신들은 PI 프로젝트를 어려워 할까?
 
바로 ① Access, ② Visioning 단계를 직접적으로 해본 적이 없기 때문이다. 그나마 Design 단계는 PI 문서를 본다든지, 프로젝트 후반에 참여를 한다든지 해서 간접적으로는 참여 경험이 있을 수는 있다. 
 
그렇지만 이슈가 되는 문제를 찾고, 과제를 뽑는 일은 SM/SI 출신 중에서는 안 해본 사람이 많다.
 
왜?? ERP를 통한 구현은 보통 현업이 필요로 하는 걸 구현해주는 것이지, 나 스스로 그 필요를 찾아본 적이 없기 때문이다.
 
그래서 구체적으로 뭘 못한다는 말일까? 아래 3가지라고 본다.
 

1. 비즈니스 효과에 대한 설명을 못한다.
2. 비즈니스 관점에서 데이터를 리서치하고 분석하는 데 의외로 약하다.
3. 구조화된 문서를 만드는 연습이 안 되어 있다.

하나씩 더 자세히 살펴보자.
 
 

2-1. 비즈니스 효과에 대한 설명을 못한다.

 
그렇다. 비즈니스 효과에 대해서 설명하지 못한다. 설명하더라도 추상적이거나, 중언부언하는 경우가 많다. 예를 들어 이런 식이다.
 

이슈 1: 경영계획 시스템이 필요함
왜냐하면 현재 경영계획이 미흡하기 때문

 
 
이렇게 "A 없는 게 이슈인데 그건 A가 없기 때문이다" 같은 실수를 한다.
 
어떤 현상에 대해서 그것이 왜 이슈인지 근거를 들어야 하는데 제대로 찾지 못한다. 단순히 SAP ERP 기능상으로는 더 발전된 기능이 있기 때문에, 그게 필요하다는 말을 반복한다.
 
이게 연습이 되지 않으면 To-Be는 그냥 SAP에 있는 기능으로 제시하게 될 뿐이며, 그게 진정 왜 필요한지에 대한 근거는 말하지 못한다.
 
 

2-2. 비즈니스 관점에서 데이터를 분석하고 리서치하는 데 의외로 약하다.

 
SAP 운영을 하면서 시스템을 담당했기 때문에 데이터 분석을 잘하거라고 생각하면 곤란하다. 의외로 약하다. 쿼리를 날리는 건 잘하지만, 해당 데이터를 통해 어떤 인사이트를 분석해내는 걸 잘 못한다.
 
데이터에 숨어 있는 크기, 추세, 비율, 편차 등의 요소를 분석해서 어떤 결론과 이어야 하는데, 그런 연결 고리는커녕 분석 데이터를 만들어내는 것조차 잘 못한다.
 
만약 컨설팅 회사에 신입으로 입사했다면 어떨까? 이 때는 RA라는 직급으로 시작하는데, RA의 'R'이 바로 Research다. 컨설팅 회사에서 일을 시작하면 이렇게 자료 조사부터 배운다.
 
그런데 그렇지 않고 SAP SI나 SM에서 들어온 케이스라면? 의외로 약할 수밖에 없다. 운영이나 구축 업무를 하면서는 SAP의 주요 기능과 ABAP 프로그래밍, 설계 역량에 더 집중할 수밖에 없는 환경이기 때문이다.
 
 

2-3. 구조화된 문서를 만드는 연습이 안 되어 있다.

 
물론 대기업 SI/SM 회사에서도 이걸 가르치긴 한다. MECE나 Why so, So what 등의 방법을 가르치고 발표도 꽤 시킨다. 하지만 당장의 구축 프로젝트에서는 별 필요가 없으므로 아무래도 중요성을 낮게 인식할 수밖에 없다. 특히나 저연차일수록 그렇다.
 
하지만 PI 컨설팅 프로젝트에서는 이런 일을 숨쉬듯이 한다. 정말 일상화된 일이며 이걸 못하면 안 된다.
 
구축 프로젝트에서는 상대적으로 문서를 만들 일이 적다. 대부분 정형화되어 있으며, 작성하는 문서도 Configuration 정의서, Key Data 정의서, 단위 프로그램 설계서 정도다. 대부분의 일은 시스템 구현과 테스트, 데이터 마이그레이션에 치중되어 있다.
 
그러다보니 자연스레 문서 작성과 발표의 중요성이 떨어지고, 해볼 기회도 적어진다.
 
만약 프리랜서로 SAP 구축만 계속 하고 싶은 생각이라면 굳이 갖추지 않아도 될 수도 있겠다.
 
 
 

3. 그럼 PI 프로젝트의 매력 포인트는 뭘까?

 
 
그럼 왜 SAP 구축만 하면 되지, PI까지 관심을 가져야 하는 걸까?
누구나 그럴 필요는 없지만 나는 둘 다 잘하고 싶다. 내가 그러고 싶은 이유는
 

3-1. 둘을 연결시킬 때 중독적인 재미가 있기 때문이다.

 
우선 재미있다. ERP 구축만 하는 것보다 훨씬 재미있다.
 
PI를 하면서 ERP의 기능과 설계과 왜 이런 식으로 되어야 하는지, 그 근거를 더 깊게 고민해볼 수 있다. "SAP 스탠다드"이기 때문에 무조건 좋다,는 데에서 그치는 게 아니라, 보다 더 비판적으로 생각해볼 수 있게 된다. SAP라는 솔루션의 틀을 벗어나서 생각해볼 수 있게 된다. '보다 폭 넓게 생각해본다는 것', 그리고 이를 통한 사고의 확장은 그 자체만으로도 삶을 재밌게 만들어준다고 나는 생각한다.
 
 
 

PI와 ERP는 상호보완적이다.

 
 
그리고 둘은 상호보완적이다. PI를 하면서 ERP의 이유와 근거를 찾을 수 있다면, ERP 구축을 하면서는 신기술을 탐색하고 효율적인 설계를 통해 PI에 필요한 실질적 도구를 갖출 수 있다.
 
또한, ERP 구축을 통해서 PI의 결과가 어떻게 구현되는지 그 실체를 알 수 있다. 이 부분은 PI만 하는 컨설턴트는 절대 알 수 없는 즐거움이며 능력이다. PI를 할 때에도 ERP의 구현가능성을 염두에 두고 할 수 있고, 더 구체적이고 더 멋지게 만들어낼 수 있다.
 
이를 위해서는 현재 ERP에서 어디까지 할 수 있는지, 어떻게 설계하는 게 더 효율적일지를 정확하게 알아야 한다.
 
예를 들어 '연결수불'과 같은 주제로 PI를 하는 건 PI 그 자체도 어렵지만, ERP로 구현도 굉장히 어렵다. 연결수불의 복잡한 로직을 단순히 CBO로 발라버리는 건 그나마 쉽다. 그렇지만 ERP 전 모듈의 상관관계를 다 이해하고, CO 모듈의 스탠다드 로직과 테이블을 다 이해한 채로 가장 알맞은 설계를 하는 건 상당히 어려운 일이다.
 
 

3-2. 구조화 능력을 키울 수 있다.

 
PI 프로젝트를 하면 정말 매일매일이 자료를 찾고 분석하고 발표하는 나날이다. 이 과정에서 일잘러라면 모두에게 필요한 구조화 능력은 정말 안 키울래야 안 키울 수가 없는 환경이 갖춰진다.
 
구조화 능력이 왜 필요할까? 구조화 능력이란 정보를 체계적으로 분류하고, 정리하여 효과적으로 이해하거나 전달할 수 있는 능력을 말한다. 컨설팅 분야에서 이런 능력은 분석적 사고와 문제 해결 능력에 직결된다고 본다.
 
구축 프로젝트만 하면 배울 수 없는 걸 배울 수 있는 귀중한 시간이라고 생각한다.
 
 
 
 

---

 
 
 
 
PI 프로젝트와 ERP 프로젝트를 번갈아 할 수 있다는 점이 내게는 현재 회사가 아주 매력적인 이유 중 하나다.
 
SAP 프리랜서를 한다면 이렇게 배울 기회가 없지 않겠는가? 요즘 구축 프로젝트는 모듈 컨설턴트에게 설계 문서 작성 시 상당한 개발 능력까지 요구하는 추세이던데, 점점 구축 프로젝트만으로는 컨설팅스러운 능력을 배우기 어렵게 되어 가는 것 같다.
 
앞으로 내 인생이 어떻게 펼쳐질지는 모르겠지만, 현재는 재미가 있으니 계속 꾸준히 해보고 싶다.