기본 콘텐츠로 건너뛰기

[국표공] 공용 서버의 활용

특정 프로젝트나 회사에서 공용 서버를 활용해서 공정관리를 진행하면 효과가 높을 것이라는 희망이 있다. 공용 서버를 활용한다는 것은 공정표를 서버에 넣어 놓고 누구든 확인, 수정 등이 가능하게 하는 방법을 의미한다. 이 희망은 상당한 위험을 안고 있다는 것을 먼저 알아야 한다.
가끔 공용 서버를 활용하여 공정관리에 성공했다는 사례가 들리기도 한다. 나도 성공한 사례는 있다. 그러나 나는 실패한 사례가 너무도 많기 때문에 공용 서버를 반대하는 사람이다. 먼저 실패한 사례에 대해서 설명을 해야 할 것 같다. 공정표 작성이 완료가 되어가는 시점이었다. 3~4일 뒤 제출을 앞두고 마지막으로 점검을 하려고 최종 파일을 열었는데 몇가지 달라진 일정이 보이는 것이다. 핵심 마일스톤 몇개의 날짜가 변경되어 있었던 것이다. 누군가 파일을 열고 일부를 수정했을 것이라는 게 내 추측이었다. 누구일까? 어디를 고친 것일까? 고친 내용을 어떻게 찾아야 할까? 다시 고치지 않는다는 보장이 있을까? 결국 고친 사람은 찾지 못했다. 최종 파일에 대한 백업 파일도 없었기 때문에 정확하게 어느 부분을 고쳤는지도 찾지 못했다. 해당 마일스톤의 경로에 대한 일정을 전부 검토해서 재수립하는 수준으로 진행했다.
공정표를 수정하면 리비전 번호를 붙인다. Rev A1에서 시작해서 Rev A2, Rev A3으로 늘어나는 방식이다. 발주처에 제출용일때 Rev A0로 만들어 놓는다. 승인을 받으면 Rev 0가 되는 방식이다. 검토 중이라 Rev A3으로 저장을 해 놓고 며칠 뒤 서버에 들어가 봤더니 Rev A4가 있었다. 누가 만든 것일까? 뭘 고친 것일까? 팀원들에게 물어보니 아무도 만든 사람은 없다고 한다. 이 상황은 Rev A3이 있기 때문에 어느 부분이 고쳐졌는지 파악할 수는 있다. 그러나 수정된 내용을 파악하는데 소요되는 시간은 누가 제공해 주나?
공용 서버를 통해 공정표를 함께 운영하는 방식을 채택하려면 첫번째가 사용하는 동료들의 실력이 비슷한 수준이어야 한다는 것이다. 그리고 사용하는 동료들에게 정확한 규칙이 있어야 한다는 것이다. 동료들 중 누가 고쳤더라도 믿을 수 있는 신뢰가 있어야 한다는 것이다.
공용 서버를 통해 공정관리, 공정표 관리를 진행하려고 한다면 아래 질문에 대해 생각을 해 봐야 한다.
"공정팀 직원들의 공정관리 능력, 공정표를 다루는 실력은 큰 차이가 없나?"
"어떤 직원이 공정표를 수정하더라도 믿을 수 있나?"
"공용 서버에 있는 공정표를 열람하고, 수정하고, 저장하는 것에 대한 명확한 규칙이 있나?"
세계적인 공정관리를 수행하는 조직이나 프로젝트에서는 어떻게 운영할까?
1) 공정표의 담당자는 1명
공정표의 담당자가 1명으로 정해져 있다는 것이다. 여러명의 도움을 받아야 하는 상황이어도 최종적으로 공정표를 담당하는 것은 1명이 한다는 것이다. 이 직원은 본인 PC에서 작업을 하고, 공유를 한다. 공용 서버가 있더라도 모든 작업은 본인의 PC에서 진행한다는 것이다. 중간 성과물이나, 최종 성과물은 항상 공유하지만, 원본은 담당자의 PC에 저장되어 변경되지 않게 한다는 것이다.
예를 들어 2명이 한 팀으로 공정표를 운영할 때도 명확하게 업무를 분리해서 진행을 한다. 1명은 공정표에 반영할 정보를 모으고, 최종 공정표 담당자 1명이 공정표에 직접 실적 현황을 반영한다. 실적 반영(Update)가 완료되면 공정표를 공유하고, 2명 모두가 공정표를 가지고 활용, 분석 등을 진행한다. 원본은 담당자 PC에 저장되어 있으므로, 원본이 변경될 가능성은 매우 낮다. 설령 변경되더라도 담당자가 고친 것이다.
여기서 주의할 것은 담당자 외에는 담당자를 돕는 입장으로 바뀔 수 있다는 것이다. 따라서 담당자 외의 직원이 방관자가 될 수 있다. 이것을 매우 주의해야 한다는 것이다.
'실적을 모으는 A, 그 실적을 가지고 공정표에 반영하는 담당자 B, 실적 반영이 완료되면 공유하는 담당자 B, 공정표를 확인하고 수정할 사항, 문제점, 준공 분석을 진행하는 A'와 같이 함께 업무를 진행하게 해야 한다는 것이다. 이를 위해서는 공정표 관리가 팀으로 진행된다는 것을 팀원들이 인식하는 것과 함께 운영할 수 있는 실력을 갖추고 있어야 한다는 것이다.
2) 파일을 저장하고 관리하는 규칙
공정표는 계속해서 수정되는 과정을 거친다. 담당자가 실적 반영을 완료했다고 하더라도, 동료들은 내용을 파악하고 피드백을 담당자에게 줘야 한다. 여기서 최종 파일 관리가 잘 되지 않으면 수정되지 않은 파일이 최종 파일로 둔갑하는 경우도 종종 있다. 그래서 파일을 저장하고 관리하는 명확한 규칙이 있어야 하고, 함께 일하는 동료들은 그 규칙을 알고 있어야 한다.
- 공정표 Rev A 우한길 수정.XER
- 공정표 Rev A 이용규 수정.XER
위 2개의 파일 중 어느 것이 최종 파일일까? 이렇게 저장하면 알 수 없다는 것이다.
- 공정표 Rev A1 우한길 수정.XER
- 공정표 Rev A2 이용규 수정.XER
이렇게 저장이 되면, A1으로 우한길이 수정했고, 그 파일을 이용규가 수정하여 A2를 만들었다는 것으로 추정할 수 있다.
- 공정표 Rev A1 우한길 수정.XER
- 공정표 Rev A2 이용규 수정.XER
- 공정표 Rev B.XER
Rev B는 어떤 의미일까? 이름을 만드는 원칙이 잘 정해야 있어야 혼란을 최소화 할 수 있다는 것이다.
3) 팀원들의 실력
무엇보다 중요한 것은 팀원들의 실력이다. 혹시 공정표를 임의로 고쳐도 믿을 수 있는 실력이 있어야 한다. 물론 임의로 고쳐서는 안된다. 실력이 있고 위와 같은 원칙을 정확하게 이해하고 있는 직원이라면, 수정 후 이름을 변경하여 저장했을 것이다. 그리고 수정 내용에 대해서 잘 기록해 놓았을 것이다. 한국 건설회사에서 가장 간과하고 있는 것이 이 부분이다. 직원을 팀에 배치하면 해당 직원은 그 업무를 수행할 수 있어야 한다는 막연한 믿음이 공정관리를 어렵게 만드는 길이다. 공정관리 업무라 처음이라면 최소한 3~4년은 공정관리 전문가와 함께 업무를 하면서 교육을 받아야 최소한의 실력을 갖출 수 있다. 신입 직원이라면 훨씬 더 많은 시간과 노력이 필요하다.
무작정 "공용 서버를 사용해서 공정관리를 하는 것이 효과적이다"라고 말해서는 안된다. 우리 조직의 실력, 우리 직원들의 실력을 파악하는 것이 우선이다. 그리고 공용 서버를 활용하기 위해 필요한 원칙을 먼저 정하고, 직원들이 이해하고 있어야 한다는 것이다.

댓글

이 블로그의 인기 게시물

[PK] 공정표의 활용

PMBOK 제6판 '그림 6-21. 프로젝트 일정도표 - 예'를 이용해서 공정표를 한 번 만들어 보자. 1. WBS/WBS Level 1 (프로젝트) : 신제품 Z 개발사업 WBS Level 2 (패키지) :   - 제품 개발 및 인도   - 작업패키지 1   - 작업패키지 2   - 작업패키지 3 2. Activity List PMBOK에서는 아래와 같은 예를 보여주고 있다. PMBOK 제6판 219페이지 * 위 그림에서 마지막 4번째 줄과 5번째 줄은 액티비티 이름이 바뀌었다. '1.1.3.T 구성요소 1과 2 통합완료'와 '1.1.3.M1 통합구성요서를 제품 Z로 테스트'가 서로 이름이 바뀌었다. Primavera로 구현한 내용은 아래와 같다. 여기서 일정도를 표시하기 위해 PMBOK는 실적을 반영한 모습을 보여주고 있다. 공정표는 위와 같이 항상 마일스톤과 요약된 내용을 확인할 수 있어야 한다. 이것을 공정관리(공정표 관리)의 기본이다. 프로젝트의 공정표를 만들 때 액티비티를 늘리는 것은 좋지 않다. 아무리 복잡한 프로젝트라 하더라도 최대 3,000개를 넘지 않는 것이 좋다. 프로그램이 있다 하더라도 실적을 입력해야 하는 건 1명의 사람이다. 사람은 물리적인 시간에 구속을 받게 되어 있다. 또한 단순 반복 작업은 오래할 수 없는 특성도 있다. 3,000개의 액티비티의 움직임을 확인하는 것도 현실적으로 쉽지 않다. 그런데 그 이상이라면? 그것은 공정표를 보지 않겠다는 의미와 같다는 것이다. "난 1만개, 2만개도 관리해 봤어"라고 말하는 건 자랑이 아니라, 본인 스스로 공정표를 효과적으로 관리해 보지 않았다는 증거를 떠들고 있는 것이다. 아무리 액티비티를 줄이려고 해도 한계는 있다. 3,000개의 액티비티를 하나씩 확인하면서 공정관리를 진행한다는 것은 매우 어렵다....

PERT/CPM

  "공정관리를 잘 안다고 말하면서 어떻게 PERT/CPM을 모를수있지?" ​ 가끔 발주자 혹은 감리자가 PERT/CPM 공정표를 제출하라는 요구를 한다. 이때 놀라운 일이 벌어진다. ​ 프로젝트가 진행되면 발주자도 감리자도 현장소장도 공무팀장도 시공팀장, 시공담당자도 모두가 공정관리에 대해 잘 알고 있다고 주장한다. 특히 공정관리자가 투입된 국내 현장에서는 이런 현상이 도두라지게 나타난다. 모두가 공정관리자에게 조언을 한다. "공정관리는 이렇게 하는거야. 공정표는 이렇게 만드는 거야" 이런 현장에서 'PERT/CPM 공정표를 제출하라는 요구'를 받게 되면 나서는 사람은 없다. PERT/CPM 공정표가 무엇이고 어떻게 만들고 운영하는지에 대해 조언하는 경우는 거의 찾기 어렵다. 그동안 공정관리에 대해 잘안다고 잘난척 하는 사람들은 어디에 있는지 찾기 어렵다는 것이다. ​ PERT와 CPM은 공정관리의 가장 기본 이론 중 하나다. 잘난척 하고 싶으면 공정관리에 대한 공부부터 하자. PERT는 무엇의 약자일까? 또 대답을 못한다. PERT가 어떻게 언제 만들어 졌는가는 상식의 영역이다. PERT의 역사를 몰라도 일은 할 수 있다. PERT는 Program Evaluation and Review Technique의 약자다. 따라서 대문자로 쓰는게 맞다. CPM은 Critical Path Method의 약자이다. 이름을 알았으니 내용을 알아보자. <그림1> <그림2> <그림3> <그림1>과 <그림2>, <그림3> 중 어떤것이 PERT이고 어떤것이 CPM일까? ​ <그림1>과 <그림2>, <그림3> 모두가 PERT라고 할 수도 있고, CPM이라고 할 수도 있다. 그러나 아마도 "<그림2>과 <그림3>은 PERT이고 <그림1>이 CPM이다"라도 답변할 가능성이 높아보인다. 이런...

[Planning And Scheduling 지침서] 목차

 1. Planning and Scheduling(공정관리) 1.1. Planning and Scheduling(공정관리) 지침서 (이하 PnS 지침서) 1.1.1. PnS지침서 개요 1.1.2. PnS지침서의 목적 1.1.3. PnS지침서 작성 및 배포 목표 1.1.4. PnS지침서의 적용 가능성 1.1.5. PnS지침서의 개정 1.2. Planning and Scheduling(공정관리) 기본 준비 및 가정 1.3. Planning and Scheduling(공정관리) 범위 및 초점 1.4. Planning and Scheduling(공정관리)에서의 공정표 관리 1.4.1. 공정표의 종류와 이해 i. 입찰공정표 ii. 내부 목표 공정표(Target Schedule) iii. Level 1, 2, 3 공정표 iv. Baseline Schedule(관리기준공정표) v. Update Schedule(관리기준공정표 기준) vi. Revision Schedule(새로운 Baseline) vii. As-Built Schedule(완료공정표) viii. Logic-Linked As-Built Schedule ix. 최종공정표 1.4.2. 프로젝트의 공정표관리 1.4.3. 공정표관리가 필요한 이유 1.4.4. 공정표관리의 개요 1.4.5. 공정표관리의 목적 1.5. Scheduling 방법과 기법   2. CPM 공정관리의 기초, 기본 원칙 및 일반 원칙 2.1. CPM 공정관리의 기본 원리 2.2. Critical Path Method(CPM) – 출처 : PMBOK 2.3. CPM 공정관리의 일반 원칙 a) CPM 계산 사용 b) Datadate 개념 사용 c) Network Float의 소유권 d) Level 4 공정표와 Baseline의 Float 값 e) Critical Activity와 Critical Path Activity f) 준공의 지연은 Critical Path가 지연될 때 g) 준공 지연의 만회는 계획이 아니라 실적으로 판단 h) 준공의 지연...