Clearvale.com
 
Korea SAP Users' Group
블로그
  • 2탄, 방법론: PI/ERP프로젝트 성공을 위한 새로운 모색
    작성자: 회원 8759, 2011년 12월 28일

    시작이 반이라는 말이 있습니다. ERP 프로젝트도 시작하는 모양새만 봐도 결과를 어느 정도 예측할 수 있습니다. 여기서 모양새란 프로젝트 방법론을 포함한 전체 진행 방향을 말합니다. 프로젝트 방법론만으로도 결과를 예측할 수 있는 이유는 SAP 프로세스가 연역적 체계로 구성되어 있어 이에 반하는 접근방식으로는 애초부터 궁합을 맞출 수 없기 때문입니다.

         

    ERP인가? 우리회사는 어떤 목적으로 ERP를 도입하려 하는가? 등등의 질문에 대한 답 중 가장 많은 답변은 아마도 프로세스 혁신(PI)을 위해서일 것이고 많은 분들이 이에 공감하리라 생각합니다. 그런데, 대부분 프로세스 혁신을 위한 수단으로 좋은 컨설턴트, 회사의 의지 및 PI팀의 열정에서 답을 찾으려고 하는 것이 일반적인 상황입니다. 그러나 훌륭한 컨설턴트” “의지” “열정만으로 목표로 하는 PI가 가능할까? 쉽지 않습니다. 그리고, 그것만으로는 결코 가능하지 않다고 감히 단언할 수 있습니다. 그럼 무엇이 필요한가? 바로 방법론입니다. ‘제대로 된 방법론입니다. 그리고, 프로젝트의 방향성입니다.

     

    그런데, 일반적으로 고객들은 방법론의 중요성을 간과하고 있습니다. 설혹 중요성을 알고 있다 하더라도 방법론을 분석하고 평가할 수 있는 상황은 지극히 제한적입니다. 왜냐하면, 방법론은 컨설팅사의 대표적인 지식자산 중 하나이며 프로젝트를 계획, 운영, 관리하는 전문적인 이론체계이기 때문입니다. 이러한 이유로 프로젝트팀의 의지에 관계 없이 잘못 적용된 방법론은 목표수준에 미달하는 결과를 초래합니다.

     

    업무 성격상 무수히 많은 제안요청(RFP) 프로세스를 경험한 필자도 모듈 기능 하나하나를 분석하듯 방법론의 실제를 요청하거나 학습하는 고객을 본 적이 없습니다. 따라서, 본 칼럼 2편에서는 이러한 방법론이 프로젝트에 어떠한 영향을 미치는지 설명하고 SAP를 성공적으로 구현하기 위한 제대로 된 방법론을 제시하여 향후의 프로젝트에 참조가 되었으면 합니다.

     

    2000년 중반 모 대기업에서 QA(Quality Assurance)로 프로젝트에 참여하였을 때의 상황입니다. 기업의 프로젝트명은 [*** PI & ERP프로젝트]였습니다. 프로젝트 출범식에서 CEOSAP 시스템에 내장된 선진프로세스를 그 어떤 수정없이 그대로 도입하라는 엄명까지 내린 터라 프로젝트팀의 분위기는 혁신의 열정에 넘쳐 있었습니다. 프로젝트를 담당하였던 글로벌컨설팅사의 방법론도 PI가 가능한 방법론이었습니다. 그런데, 결과는 기대에 미치지 못했습니다.

     

    프로젝트를 보다 더 잘 진행하기 위하여 CIO의 자문역으로 제3의 인물이 위촉되었고 이 분에 대한 CIO의 신뢰가 커 이 분이 주장하는 방향으로 진행되게 되었는데 결론적으로 귀납적 접근방법이었습니다. 필자도 TO-BE 단계에서야 이를 인식하게 되었고 문제를 제기하였지만 개선되지 않았습니다. 일반적으로 귀납적 방법론은 개발프로젝트에 적용되는 방법론으로, SAP 프로젝트와 PI에는 적합하지 않습니다. 그리하여, 프로젝트는 CEO의 엄명과 프로젝트 제목에도 불구하고 프로세스혁신은 차치하고 엄청난 양의 개발에 포커스된 프로젝트로 진행되었습니다. 그 뒤의 상황은 구태여 설명하지 않아도 짐작할 수 있을 것입니다.

     

    우리는 위의 사례에서 어떤 시사점을 가질 수 있습니까?

     

    첫째, 프로젝트의 리더십입니다. 일반적으로 프로젝트는 PM에 의하여 지휘되고 PM을 보좌하는 스텝과 PM을 자문하는 QA로 프로젝트의 지휘부가 구성됩니다. 그런데, CIO의 자문역이 프로젝트 전체를 총괄하는 PMQA의 역할을 자처하고 월권함으로서 발생된 조직체계상의 이슈입니다. 이것이 왜 문제가 될까요? 프로젝트의 최종 책임은 컨설팅사와 PM에게 있고 방법론을 통하여 이를 실행하며 최종적인 책임을 담당하기 때문입니다. 그러나, 자문역은 프로젝트에 대한 그 어떤 책임도 없이 전혀 다른 방향으로 혼란을 조성한 것입니다.

     

    물론, 객관적인 경력으로 볼때도 당시의 자문역은 SAP 프로젝트에 대하여 주관적인 의견을 제시할 수 있는 경험이나 일정 수준의 지식을 갖추고 있지는 않았습니다. 이것이 첫번째 이슈였습니다., 혁신프로젝트인 ERP프로젝트가 성공하기 위하여는 조직체계와 사람이 중요합니다. ERP 프로젝트, 특히 PI를 지향하는 SAP 프로젝트의 경우 하나의 업무를 위하여도 최소한 3가지 이상의 TO-BE 대안을 제안하고 검토하여야 합니다. 무제한적인 논쟁을 통하여 최적 대안을 찾아야 하는데 지식산업에서 어울리지 않는 행정적 권한이 지적탐구와 분석을 제약하게 된 것입니다. 이러한 상황에서 제대로 된 프로젝트를 기대하는 것은 허황된 욕심에 다름없습니다.

     

    둘째, ERP를 통한 PI를 진행하기 위하여는 PI가 가능한 방법론을 적용하여야 합니다. 특히, SAP의 경우는 절대적으로 단계적 접근에 의한 연역적 접근의 방법론이 필요합니다., 최종적인 to-be를 디자인하기 위하여는 2레벨>3레벨의 단계적 접근이 필요하며 프로세스 확정 후 기능레벨인 4레벨>5레벨의 순으로 적용됩니다. (부분적인 상황이지만 프로세스가 4레벨까지 내려가는 경우도 있습니다.) 매출프로세스를 예로 들면 매출이 2레벨 프로세스이고 문의>견적>오더>계약 등이 3레벨이며 3레벨에는 목적에 따라 다양한 프로세스의 대안이 존재합니다., 견적의 방법, 오더의 절차와 순서 및 종류, 계약의 방식과 절차 및 종류 등. 이러한 다양한 프로세스의 대안 중 회사에 유효한 프로세스를 선택하고 필요없는 프로세스는 생략하여 성력화하는 과정이 바로 PI의 과정입니다.

     

    그런데 개발방법론에 의한 접근이 이루어지게 되면 프로세스보다는 오더에 속해있는 4레벨의 기능적인 부분의 영역에 치중하여 오더를 진행하는 화면의 기능을 현재의 기능과 비교하는 것부터 시작하는 귀납적 접근으로 진행되어 프로세스 개선보다는 사용의 편의와 보고자 하는 정보의 구성이라는 기능 구현에 중점을 두게 됩니다. 따라서, 이러한 방법론에 의하여 현재 시스템과 희망하는 추가적 기능을 보완하는 상황으로 진행되어 프로젝트팀의 의도와 달리 원천적으로 프로세스혁신이 불가능한 상황이 됩니다., 프로세스혁신을 위해서는 어떤 기능화면의 어떤 정보가 아니라 프로세스 관점에서의 어떻게’ “ 등에 방향성을 집중해야 하기 때문입니다.

     

    이러한 이유로 프로세스의 혁신과 통합에 목표를 둔 ERP 프로젝트라면 이를 실현할 방법론의 선택이 성공 프로젝트를 위한 핵심 전제조건이라 단언할 수 있습니다. SAP 프로젝트를 제대로 진행하기 위한 신뢰할 수 있는 방법론으로 컨설팅사들은 독자적이며 검증된 방법론을 가지고 있습니다. 방법론은 컨설팅사의 가장 중요한 자산이기도 합니다.

     

    본 칼럼에서는 SAP프로젝트를 제대로 구축하기 위한 방법론의 하나로 필자가 경험한SAPASAP (Accelerated SAP) 방법론을 예로 들어 설명하고자 합니다. ASAP방법론의 독자적인 특징은 방법론이 SAP 시스템과 통합되어 있다는 사실입니다., TO-BE 프로세스를 설계하는 문서와 시스템이 연동되는 방법론의 체계와 더불어 오랜 경험을 통하여 제공되고 변화되어진 다양한 템플릿 등은 ASAP방법론의 대표적인 장점으로 프로젝트의 품질확보를 보다 안정적으로 가능하게 할 것이라 판단합니다. 물론, 연역적인 접근을 기반으로 하고 있습니다.

     

    그리고, 연역적 접근의 실현을 위하여는 ‘TO-BE 프로세스정의서’(3레벨)‘TO-BE 기능정의서’(4,5레벨)를 구분하여야 합니다. 그런데, 대부분의 경우 이들이 혼용되고 있습니다.

     

    3레벨 TO-BE 프로세스정의서는 전체 프로세스의 방향과 목적을 한 눈에 볼 수 있고 프로세스별 다양한 대안도 동시에 비교할 수 있습니다., 자재이동을 예를 든다면 입고, 출고 등등의 자재이동의 종류와 절차 및 방법을 한꺼번에 볼 수 있는 것입니다. 그러나, TO-BE 기능정의서는 정의된 프로세스를 기능단위로 즉, 프로세스에 의하여 정해진 결과를 시스템에서 구현되는 방법을 기능적이 측면에서 정의합니다. 오더의 경우 생성>변경>조회의 순으로 단위기능을 시스템에서 테스트하고 확정합니다.

     

    이러한 프로세스정의서와 기능정의서가 혼용되면 숲을 볼 수 없고 기능만 확인되고, 결국 문서 작성의 실효성을 의심할 수 밖에 없는 상황이 발생하게 됩니다. 2006년 진행한 프로젝트에 QA로 참여시 프로세스정의서는 없고 기능정의서만 있어 프로세스 리뷰시 전체 흐름에 대한 이해와 분석에 근원적인 제약이 있었고 SAP 기능의 순서를 매뉴얼화 한 것에 불과하여 프로젝트 감리에 고충이 적지 않았던 상황도 있었습니다.

     

    당시 생각했습니다. 이러한 문제를 원천적으로 제거하기 위해서는 SAP의 교육센터에서 시스템만 교육할 것이 아니라 방법론도 교육해야 한다는 생각을 하게 되었고, 현재 그렇게 실시하고 있는 것으로 알고 있습니다.

     

    될성 싶은 나무는 떡잎부터 알아 본다고 했습니다. 프로젝트 방법론의 선택은 분명 고객사의 책임은 아니지만 컨설팅사만의 책임도 아닙니다. 이젠 고객들도 프로세스와 기능을 이해하기 위하여 학습하는 노력 만큼 방법론에 대해서도 제안요청(RFP) 항목에 포함시켜 질문하고 검토, 분석, 학습할 필요가 있습니다. 왜냐하면, 방법론이야말로 떡잎의 자양분이기 때문입니다.

     

    Happy New Year!



    회원 134

    프로젝트마다 방법론 얘기는 많은데 이호신전무님처럼 그 중요성을 명쾌하게 설명해주신 분은 거의 없었던 것 같습니다. 귀납적 접근을 중시하는 개발방법론으로는 프로세스 혁신이나 투비(to-be) 이미지 구현이 왜 어려운지 일깨워주는 멋진 글 고맙습니다. 넙죽. ^^

    2011년 12월 28일


비공개
비공개
비공개
비공개