8. 프로젝트관리 - 'toc제약경영

TOC 제약경영 (정남기 저, 대청, 1999)

Copyrightⓒ 1999 정남기 All rights reserved 1 페이지 http://pm.chonnam.ac.kr

8 프로젝트관리(4)

PERT/CPM 은 한계가 있다

대규모 사업이나 신제품 개발을 위한 프로젝트는 주문생산이나 흐름

생산과는 다른 특성을 지닌다. 정해진 기간에, 주어진 예산을 사용하여 프로젝트를 완수하고, 고객을 기쁘게 해야 한다. 비용, 스케쥴, 그리고 성과가 주요 관심사이다. 프로젝트의 성과를 높이려면 불확실성을 잘 관리하여, 가능한 빨리, 그리고 약속한 납기를 지키는 것이 필요하다.

지금까지 프로젝트 관리는 PERT/CPM 기법이 주로 사용되었다. 그렇지만 그 결과는 만족스럽지 못하다. 납기를 못 지키는 것이 당연한 것으로 여겨지고, 막판 일에 쫒기는 것은 다반사이다. 그 이유는 PERT/CPM이 자원의 능력을 감안하지 못하고, 작업의 순서(애로 공정)에만 의존하여 스케쥴링하기 때문이다. 이것은 비현실적인 계획이 되고, 실행할 때 많은 문제를 야기한다.

여기서 제시하는 TOC기반의 애로사슬(Critical Chain) 프로젝트 스케쥴링은 PERT/CPM과 다르다. 애로공정(Critical Path) 대신 애로사슬이 정의되는데, 작업순서를 만족하며 자원을 중복사용하지 않는 공정들로 구성된다. 그리고 여러가지 버퍼 시간을 작업시간과 함께 고려하여 스케쥴링하기 때문에, 실행도중 발생하는 예기치 않은 일이 납기에 미치는 영향을 줄인다. (애로사슬과 버퍼시간의 정의에 관한 내용은 (부록 C)에 있는 예제를 참조하기 바란다.)

“실제작업시간은 배정된 시간보다 짧아지지 않는다 Work expands to fill (and often exceed) the time allowed.” — Parkinson의 법칙 “잘못될 소지가 있는 것은 그렇게 되고야 만다 Whatever can go wrong, will.” — Murphy의 법칙

프로젝트 관리가 필요한 것은 불확실성 때문이다. 프로젝트 관리자가 관심가질 일은, 요소작업 하나 하나의 작업시간이나 계획 일정 준수 여부가 아니라, 마지막 납기 준수 여부이다. 매 요소작업마다 머피의 법칙(불확실한 상황)을 감안하여 여유기간을 추가하는 것은 공기를 필요 이상으로 늘려 잡 (4) 이 내용은 Patric, F.S.(1998) Critical Chain Scheduling and Buffer Management: Getting Out Between Parkinson’s Rock and Murphy’s Hard Place의 내용에 근거한 것임.

http://pm.chonnam.ac.kr



는다. 더군다나 대부분의 프로젝트에는 파킨슨의 법칙(주어진 작업시간을 다 사용하려는 경향)이 적용되므로, 이건 너무 비효율적이다.

프로젝트관리는 서로 갈등관계에 있는 다음 2가지를 해결한다.

납기가 빠르다. 한번 약속한 납기는 지킨다.

이 해결방법은 불확실한 상황을 미리 대비하고, 작업시간 늘어나는

것을 막는 데서 출발한다. 즉, 머피를 대비하고, 파킨슨은 막는다. PERT/CPM의 머피 대비책은, 각 요소작업이 정해진 일정에 맞추어

제 시간을 지켜주면, 전체 프로젝트도 예상대로 끝날 것이라는 생각이다. 그러나 TOC는 이와 다르다. TOC에 근거한 애로사슬 스케쥴링과 버

퍼관리는 요소작업의 일정이나 그 일정 준수 여부에 관심을 두지 않는다. 요소작업별 작업완료시간은 계산하지도 않는다. 오직 약속된 프로젝트 납기에만 관심을 둔다. 구체적인 방법을 찾기 위해, 현재의 관리방식을 살펴보고 파킨슨 현상이 생기게 되는 이유를 알아보자.

사람들은 보통 프로젝트를 각 요소작업별로 나누어 작업시간을 추정하고 일정을 잡는다. 이 계획에는 자원의 활용도가 감안되고, 납기에 대한 약속 준수가 들어 있다. 따라서, 작업시간이 매우 신중하게 제시되는데, 실제 소요시간에 ‘안전’을 생각한 덤이 추가된다. 이 덤에는 머피의 법칙, 조직 생활 때문에 어쩔수 없이 지연되는 시간, 그리고 프로젝트를 여럿 수행할 때 추가로 필요한 시간 등을 포함시킨다.

이 요소작업시간 추정치는 단일값이 아니라 확률치이다. 작업완료시간은 단정적으로 말 할 수 없고, 그 시간 안에 끝낼 확률로서 표현될 수 있기 때문이다. 만약 매우 공격적인 추정치라면, 50%의 신뢰수준을 갖고 있으며, 보다 현실적이고 안전한 추정치는 85-95%의 범위에 있는 것이다.




(그림 3-10) 요소작업시간 추정치의 분포 그러므로, 요소작업시간 추정치에는 덤이 많이 들어가 있다. 어떤 경

우는 덤이 실제 작업시간보다 2-3배 더 클 수도 있다. 요소작업이 계획대로 진행되지 않으며 프로젝트의 납기도 지키기 어려운 이유가 여기에 있다.

보통은 이 추정치로 프로젝트 스케쥴을 작성하여, 작업의 선후관계와 시작/완료시간이 정해진다. 사람들은 이 지정된 일정을 중심으로 작업을 수행하나, 주로 완료시간을 기준으로 일정 계획을 세운다. 즉, 시작시간에는 맘 편하게 다른 일을 계획하다가 완료시간이 다가오면 그에 맞추어 서두른다.

문제가 여기서 발생한다. 먼 훗날 얘기처럼 여유있어 보이던 예정 완료시간은 슬금슬금 다가오는데, 그 동안 좀 다른 일에 신경을 쓰든가, 페이스를 조절하여 일한다. 그런데, 막상 완료시간이 더 다가오면, 꼭 급한 일이 한 두 가지씩 생기기 마련이고, 이제 이 ‘급한’ 일을 처리하다 보면, ‘현실적이고 안전하게’ 추정했던 작업소요시간이 ‘공격적’인 추정치로 바뀐 상황이 된다. 더 심한 경우는 납기를 연기해야 한다. 또 다른 경우, 만약 작업을 예정보다 일찍 끝냈다 하자. 그러면 그 다음 작업을 곧 이어서 시작할까? 그렇지 않을 것이다. 다음 작업의 시작일은 앞 작업의 완료예정일로 이미 정해져 있기 때문에, 준비가 안 되어 있다. 그렇다고 준비를 서두르지도 않을 것이다. 더군다나 자기 작업시간에 충분한 덤을 얹어 놓았고, 앞 작업마저 빨리 끝나 있는 상황에서 결코 서두를 이유

안전한 추정치로 신뢰수준

이 85~90%임

공격적인 추정치로

50%의 신뢰수준을

작업소요시간의

최소치

이 추정치는 단일값이 아니라 확률치이다.




는 없다. 이렇게 되면, 프로젝트 납기는 잘해야 가까스로 지켜질 것이다. 그것도 막판에 잘 몰아치든가, 아니면 어딘가를 대충 처리하는 선에서…파킨슨 법칙은 틀림없다! 일이 이렇게 되는 것은 요소작업의 완료시간을 정해둔 것과 현실적이고, 신중하게, 안전하게 추정된 작업소요시간 때문이다. 프로젝트 관점에서 보면, ‘안전’ 덤을 편안하게 허비하면서 납기 약속을 곤경에 빠뜨린 결과가 되었다.

애로공정이 아니라 애로사슬

전 장에서 우리는 현재 프로젝트 관리 방식이 안고 있는 문제점을 살펴 보았다. 이 문제점들은 PERT/CPM의 한계이기도 하다. 이제, 이 문제 해결의 대책을 생각해보자.

불확실성(머피)이 있는 상황에서 납기를 보장하기 위하여, (대책 1-1) 요소작업마다 시작/완료시간을 정하지 않는다. (대책 1-2) 덤을 한 곳으로 모은다.

빨리 끝난 작업을 활용하기 위하여 (대책 2) 사용할 자원을 미리 준비하여 대기시킨다. 프로젝트 진행상황을 관리하는 방법으로 (대책 3) 버퍼(여유시간)로 진도를 모니터링한다.

이 대책들은, 프로젝트를 전체 시각에서 보는 시스템 사고에 의한 프

로젝트 관리 방식이다. 이들은 불확실성이 만드는 어려운 상황을 미리 알아내서 이에 대한 대비책을 제시한다. 즉, 파킨슨은 무력화시키고, 머피는 전체를 한데 모아 프로젝트 단위로 처리한다.

이제 각각의 대책을 자세히 설명하면서, 애로사슬 프로젝트관리 방식을 소개한다. 이 내용에 부합되는 예제가 (부록 3)에 있으므로, 이 대책과 예제를 함께 참조하면 이해에 많은 도움이 될 것이다.

(대책 1-1) 요소작업마다 시작/완료시간을 정하지 않는다.

애로사슬 프로젝트 관리에서는 덤이 없는 작업시간, 즉 순수작업시간




을 사용한다. 이 시간은 한 작업에 몰두했을 때, 그리고 별다른 문제가 안 생겼을 때 걸리는 시간을 말한다. 이것은 보통 신뢰수준 50%의 작업시간에 해당한다.

이렇게 함으로써, 요소작업의 완료시간을 없앨 수 있으며, 이는 파킨슨을 몰아내는 결정적 역할을 한다. 현장에서는 ‘누가 뭐라하든 작업에 필요한 만큼의 시간은 꼭 필요하다’ 라고 생각한다. 신뢰수준 50% 수준으로 작업시간을 정하면, 이 시간에 끝내지 못할 경우가 절반이다. 따라서 완료시간을 정하는 것이 무의미하며, 아예 생각하지도 않는다.

(대책 1-2) 덤을 한 곳으로 모은다.

요소작업 작업시간의 추정치를 다시 생각해보자. ‘90% 수준’과 ‘50% 수준’의 차이는 안전을 위한 덤에 해당한다. 이 덤을 각 요소작업에 나누면 허비되고 말지만, 한데 모으면 유익하게 사용될 수 있다.

애로 작업의 덤을 한데 모아, 다이어그램의 맨 끝에 덩어리로 두면 프로젝트 납기를 지키는 데 유용하게 쓰일 수 있다. 애로사슬 작업중 어느 것이 늦어지더라도, 이 덩어리만큼의 여유가 이를 보호해 주기 때문이다. 우리는 이 덩어리를 ‘프로젝트 버퍼(project buffer)’라 부른다.

버퍼를 한데 모으는 것은 하나의 ‘시스템 사고’이다. 이것은 나누는 것에 비해 이점이 있다. 각 요소작업이 ‘50% 추정치’이기 때문에, 절반은 예상보다 빨리 끝나고 절반은 늦어진다고 볼 수 있는데, 늦게 끝난 작업의 늦어진 시간을 빨리 끝난 작업이 상쇄시켜 줄 수 있다. 각 요소작업에 나누어진 버퍼에서는 이런 상쇄 효과가 없다.

통계적 결과는 아니지만, 모아진 버퍼의 크기는 각 요소작업 버퍼 합에 비해 거의 절반 수준이면 충분하다고 본다. 그럼에도 납기준수에는 더 효과가 있고, 납기 단축효과까지 있다. 부분보다 전체를 보는 시스템 효과이다.

이제 비애로(non-critical) 작업을 보자. 이 작업들도 현재 진행중인 작업에 전력을 다하며, 끝나는 대로 다음 작업에 넘긴다. 프로젝트를 빨리 끝내려면 너무나 당연한 일이다. 애로 작업처럼 자원을 준비시키는 등 세심한 관리는 하지 않지만, 애로 작업을 기다리게 하지 않을 정도는 관리한다.

보통은 이들 비애로 작업은 가능한 빨리 시작하여, 혹시 무슨 일이 있더라도 여유있게 하는 것이겠지만, 이제 무조건 일찍 시작하지 말고 버퍼를 사용하자. 여기서도 각 비애로 작업들의 덤을 한데 모아, 작업 완료시간이 이 다음 공정의 애로작업 시작시간에 맞출 수 있게 한다. 이런 버퍼를 ‘먹임(feeding) 버퍼’라 한다.

비애로작업의 자원은 미리 준비해둘 필요까지는 없다. 최악의




경우, 프로젝트 버퍼를 사용할 수도 있으므로, 그저 진행중인 작업을 빨리 끝내는데 집중하면 그만이다.

(그림 3-11) 애로사슬 프로젝트 스케쥴링의 개요 (대책 2) 사용할 자원을 미리 준비하여 대기시킨다. 위 (대책 1)에 따르면 다음 의문이 생긴다. 즉, 요소작업별 시작/완료시간이 없으면, 자원 사용 일정을 어떻게 알아서 자원을 미리 준비해 둘 수 있겠는가? 이 질문에 대한 답은, 여기서 다룰, 빨리 끝난 작업의 체계적 활용 대책과 밀접한 관련이 있다.

우선 자원을 2 종류로 구분하여, 애로사슬 작업을 수행하는 ‘애로자원’과 비 애로사슬 작업을 수행하는 ‘비애로자원’으로 나누어 생각하자. 여기서 관심은 애로자원들이다. 이들이 프로젝트 일정을 거의 결정하기 때문이다. 한가지 유의할 점은, 애로자원의 가용시간이 미리 정해진 것이 아니고, 선행공정이 끝난 후에 정해진다는 점이다.

이제 (대책2)를 다음 2단계로 설명한다. 단계1: 자원마다 작업을 바꾸는데 걸리는 시간을 미리 알아둔다. 이

시간은 하던 일을 마치고 다른 일을 준비하는 데 걸리는 시간으로, ‘자원 버퍼’라 부른다. 애로 선행공정이 끝나면 곧바로 다음 애로 공정에 이 자원이 투입되게 하려는 것이다.

먹임버퍼

프로젝트버퍼

애로사슬 프로젝트 스케줄링

낙관적인

애로사슬자원을 대기시킴

애로사슬이 변동되어도 납기일비애로작업이 변동되어도 애로

사슬은 변경되지 않게 보호한

납기




단계2: 각 자원마다 현 작업의 예상 소요시간을 정기적으로 보고한다. 이 시간은 단계1에서 정해둔 자원준비시간과 연결하여 사용된다. 예를 들어, 작업A가 자원1에서 작업 중인데, 이어서 작업B가 자원2에서 작업된다 하자. 자원2를 준비하는 데 20분이 걸린다. 이제 작업A의 남은 시간을 모니터링하다가, 20분 후에 끝난다고 알려오면, 우리는 이때부터 자원2를 준비시킨다.

이 방법은 기존의 방법에 비해 생각의 포인트가 바뀌었다. 종래에는

‘몇 %나 달성했는가’라는 과거 실적을 중요시 했지만, 이 방법은 ‘앞으로 얼마나 남았는가’라는 평가와 앞으로 대책을 더 중요시 한다. 따라서 우리는 더 이상 요소작업별로 배정된 시간에 집착하지 아니하고, 앞 공정이 빨리 끝나면 그만큼 빨리 다음 공정을 착수할 수 있게 되었다. (대책 3) 버퍼로 진도를 모니터링한다. 프로젝트 실행을 어떻게 관리할까? 즉, 일단 프로젝트가 시작되고 나면, 기준이 되는 요소작업 납기가 없는 상황에서, 프로젝트의 진행상황이 어떻게 파악되는가? 여기에 핵심 역할을 하는 것이 먹임 버퍼, 프로젝트 버퍼, 그리고 ‘버퍼관리’라 불리는 프로세스이다. 어떤 요소작업이 완료되면, 그 완료시간에 따라 관련 버퍼들이 얼마나 줄었는지 혹은 늘었는지 알 수 있다. 현재 진행중인 작업을 기준으로 앞으로 작업소요시간에 대한 추정치가 계속 수정되어 가므로, 우리는 버퍼의 변화를 모니터링할 수 있다.

버퍼가 어느 기준보다 많이 남아 있으면, 모든 것이 제대로 가고 있다는 증거이다. 만약 버퍼가 어느 정도 줄면, 어떤 조치를 내려야 할지 예의 주시하다가, 정작 어떤 수준 아래가 되면 이 조치를 실행시킨다. 즉, 일이 제대로 되어 가고 있을 때는 관여하지 않고, 중대 사안이 아닐 때는 간단히 대응하고, 꼭 필요할 때에는 관여하는 방식을 취한다. 우리는 지금까지 애로사슬 프로젝트관리를 설명하였다. 이 방법이 이전의 PERT/CPM 방법과 다른 점은, 애로사슬이 유지되도록 적극적으로 먹임 버퍼를 사용하는 점이다. 이전 방법은 애로공정이 바뀌면 이에 수동적으로 대응했을 뿐이다. 결론적으로, 애로사슬 프로젝트관리를 PERT/CPM 방법과 비교하여 다음과 같이 요약된다.

각 작업의 소요시간으로 ‘안전’ 치가 아니라 ‘평균’ 치가 사용된다.




여유시간이 각 작업에 분배되지 않고, 중요한 위치에 모아져 사용된다.

작업시작을 가능한 늦추어 재공재고를 줄이면서도, 프로젝트 완성을 늦추지 않는다.

작업 선후관계뿐 아니라 자원제약도 고려된다. 이러한 이유로 다음과 같은 이점이 있다.

프로젝트기간이 단축된다. 재공재고가 줄어든다. 납기 약속 준수가 더 확실해진다. 현실 요건이 반영되므로 재 스케쥴링이 줄어든다.

작업 우선순위가 확실히 구분된다


8. 프로젝트관리 - 'toc제약경영

Leadership & Management