메뉴 건너뛰기

SAP 한국 커뮤니티



PS 모듈의 이해

불루마린 2009.12.15 13:03 조회 수 : 15045 추천:1

PS 모듈을 시작했거나, 진행하고 있는 관계사직원들과 자료 공유 및 의견수렴을 위한 글.. [작성자 : 박홍귀]


 


실제로 PS 모듈과 같은 경우 SAP Certification이 없고, 건설/조선/제조/IT 업종에 따라 관리포인트가 상이하기 때문에 컨설팅 하거나, 받기가 쉽지 않은 모듈중 하나입니다.


 


기준정보인 BOM과 MRP 일정관리 중심으로 진행하는  제조업과  Project Manager 와 각 WBS 담당자의 의사소통을 통해 예산관리 중심으로 진행 하는 건설업(설계와 시공은 다르며 회사마다 구축모델이 많이 상이함), M/H산정, 개발본수와 공수산정 등 투입인력계획 중심으로 진행되는 IT 프로젝트의  관리 포인트가 상이하므로 타사 구축 사례들을 곧바로 적용하기 쉽지 않습니다.


 


실제로 해당 프로젝트 수행경험자들이 그 프로젝트의 특성을 이해하고 WBS 구조를 정의할수 있습니다. PS의 주요 마스터는  WBS인데 WBS element와는 다른 level, 즉 Acitivity로 구성된 Network Level 에서 Activity에 Material을 연결후 생산/구매/자재일정과 관련된 Scheduling이 일어납니다. 그러나 Unique하고 처음과 끝이 있는 프로젝트(MTS가 아닌 MTO만 대상)에서는 Model별 수량관리가 주 관리 요소가 아닐수도 있습니다. PP(BOM, MRP) 개념중심 또는, WBS 를 일정관리 단위로 보는 MS Project 이론에 치우치다 보면 WBS 하단에 1대 N으로 매핑되는 일정관리 용도의 Network 과 Activity에 많은 시간을 소비하게 되어 기본적인 WBS구조에 대한 설계가 소홀해질 우려가 있습니다.


(WBS : Work Breakdown structure, 업무분할구조 , SCOPE과 예산 분할 구조)


 


처음과 끝이 있는 한시적인 일(프로젝트) Budget을 Breakdown 하고 책임중심별 Scope을 나눌때 사용하는 PS 모듈의 가장 기본적인 마스터인 WBS 생성시 재무관점만을 도입하여 비목 구분만으로 된 WBS 모습이되어도 바람직하지 않을수도 있다고 보여집니다.  


 


하지만 PS는 CO(관리회계) 모듈에서 파생되었기 때문에 관리회계 개념 [경영계획, 예산, 손익, 원가, 배부, 결산]등을 이해하지 못하면 제대로 이해하거나 접근하기 어려운것도 사실이고, 조직구조도 여러개의 법인 업무를 하나의 프로젝트로 구성될수 있는 Controlling Area 레벨에서 진행됩니다. 또한  계획/실적 값등 CO-PA(경영계획/예산/수익성분석)와 원할히 연계되었을때 진정한 PS의 가치를 알수 있다 해도 과언이 아닙니다.  


또한 손익이 발생하는 수주프로젝트와 매출이 발생하지 않은 Overhead 성, 건설가계정의 유형을 가진 사업조직별로 다른 프로젝트 유형별로 표준WBS (업무분할구조)를 사전에 정의하는 일도 중요해 집니다.


프로젝트 실적금액은 회계처리를 동반하니 수주(고객존재)프로젝트인 경우는 특별한 경우를 제외하고는 계약이 완료되었을때 그 계약단위로 프로젝트 코드부여 작업과 동시에 프로젝트가 시작되는것이 일반적입니다. 프로젝트가 계약없이 선진행 되었을때 예산수립이 어렵고 계약이후 프로젝트 비용의 회계처리가 달라지니 수익성분석으로의 정산규칙을 다시 정의하고 다시 코드를 부여해야 되므로 번거로운 작업들이 수반될수 있습니다.


 


또한 프로젝트별 경영계획 /실적, 손익이 PS에서 CO로 반영되어 수익성 분석을 통한 사업군별 포트폴리오 관리로 Go할것인지 Drop할것인지  전략적 의사결정 지원도 가능해 집니다. 사전 정의된 프로젝트 유형별로 만들어진표준 WBS에  축적된 Data 혹은 기존에 축적된 WBS별 Data들이 동일한 유형의 프로젝트 Planning 시 에 유용한 정보로 가치를 발휘하게 될것 입니다.


 


건설업, 조선업종 과 같은 경우 [혹자는 도면, 문서관리 시스템 을 PLM으로 약칭]중요시 하는 문서관리 시스템과 같은 경우 도면관리에  특화된 Legacy 시스템이나 별도 Package를 사용하는 경우가 많고 현재 사용하고 있는 일정관리 시스템과의 연계나 추가 개발해야 되는 Web 솔루션등이 추가적으로 보완 되는 것이 일반적인 프로젝트 관리 시스템의 미래모습(To-Be) 모습이라 할수 있습니다.


 


이는 SAP PS 만으로 모든 프로젝트 관리가 이루어 지지는 않는다는 것인데.. 사실은 가장 현실적인 모습입니다. PS 모듈을 도입했다고 원할한 프로젝트 관리를 보장받는것이 아니고 .. 조직과 임무, 프로세스 재설계 검토,누가 할것인가? 를 정의하고 지속적으로 담당자를 교육해야하는 어렵고도 중요한 과제가 수반됩니다.


 


프로젝트관리자 PM은 그 프로젝트 위험이나 규모에 따라서 임원에서 부터 대리급 까지 다양한 계층의 인력중에 누가 PM을 수행 하느냐에 따라서  프로젝트 품질, 일정 등의 내용등이 현격한 차이를 보인다고 합니다.


이는 프로젝트가 PM과 각 분야별 WBS 담당자별 Communication 중심으로 일이 진행이 되며 한정된 자원을계획하고 집행하고 통제하여야 하는 경험과 노하우가 필요한 영역이기 때문일 것입니다...


또한 경영계획, 예산수립, 계약검토, 자원투입, 품질, 위험, 수익성확보의 책임자로 전분야 걸친 관리자로서의 역량이 필요하게 되어 일하는 절차나 방법이 담겨있는 조직내 작은 경영자로서의 PM Manual이 필요하게 됩니다.


따라서 PM은 많은 프로젝트에 대한 막중한 책임을 맡게 되고 한정된 자원을 효과적으로 활용 통제할수 있는 권한위임 문화도 이 필요한데 이는 프로젝트 관리가 성공적으로 정착하기 위한 전제조건이 될수 있습니다..


 


연구개발, 설계, 고객의 수주를 받아 매출을 발생시키는 다양한 유형의 프로젝트는 각각의 유형이 달라일반적으로 그 프로젝트를 수행해 봤던 경험이 많은 인력들이 PM을 수행합니다. 프로젝트 성격에 따라서 CPM이 형태가 아닌 Bar chart 형태의 일정관리로도 충분한 경우 WBS element 만을 사용하고 Network과 Activity를 사용하지 않아도 되며 구매/자재, 생산이 없다면 Network 사용할지 여부를 결정해야 합니다.


일반적으로 M/H 시스템이나 견적 시스템은 별도로 두어 필요한 경우에 I/F  처리하는 경우가 많습니다. M/H 시스템을 별도로 두어 WBS에 연계시킬수도 있고 아니면 Network과 Activity 부분을 사용할수도 있습니다. 사용자의 수나 빈도에 따라 총 금액이나 총수량만 ERP에 연계처리하고 별도 시스템으로 두어 연계하는것이 더 좋을 수도 있습니다.


매출손익은 프로젝트 별로 집계하는 것이 일반적이며 원가및 비용은 각 WBS element 단위로 관리됩니다.


 


WBS element 는 월말 배부작업과 정산작업을 수반하므로 PM이 관리, 통제가능한 Level까지만 구성되는것이 바람직 하고 프로젝트 유형별로 거의 동일한 구조로 생성되어야 비교 분석 및 계획시 참조가 용이합니다.


 


다양한 형태의 프로젝트가 각 사업부별  년간 경영계획과 연계된 예산관리 연계되어 범위안에서 진행 됩니다. 경영계획은 1년에 한번 많아야 두번 정도로 고정되는 금액이고, 예산은 계속 변경되어 최초/최종 예산 조회및 관리가 가능한 형태로 관리되어집니다. 프로젝트 유형에 따라서는 장기간의 수주 PJT와 같은 경우는 예산변경관리가 매우 중요해 지기도 합니다.


프로젝트는 Unique한 형태로 촉박한 일정으로 진행 되니 한회사 내에서도 해당 프로젝트 성격에 맞게 PS 모든 관리요소 중 부분적으로  선택 적용할수 있어야 합니다. 한정된 자원을 적절히 사용하여 목표 성과물을 만들기 위해서는 품질, 원가, 일정의 Trade off의 적절한 중간점 찾기가 필요해 집니다.


 


GE의 사장이며 경영자였던 잭웰치도 화공학박사이며 연구소 출신의 기술인력으로 부사장이 되어서야 재무회계를 배웠다고 합니다. 회계 비 전문가인 기술인력 또는 사업관리자가 Project Manager를 맡을수 있다는 상황을 예상하여 관리 가능한 레벨과 수준반영. PM 중심의 프로젝트 관리 이론 이해 그리고 SAP PS[프로젝트 관리]모듈을 통해 무엇을 계획하고 관리할것인가?  구성원의 Role Define .사용자인 PM의 요구사항과 의견등이 사전에 충분히 고려되어야 할것입니다.  [09.02.13] 

 

출처 : http://www.facebook.com/note.php?note_id=185031241516673