지난 포스팅에 잠시 턴키 방식이 언급되었었다. 그런 김에 SI의 계약 방식에 대해서 오늘은 포스팅을 해보려고 한다. 이 두 가지만 알면 SI 계약 방식은 다 커버한다고 보면 될 것 같다.
우선 맨먼스가 무엇인지는 지난 포스팅 때 열심히 설명을 했으므로 여기서는 생략하도록 하겠다. 지난 포스팅이 궁금하다면, 아래 링크로 가서 보도록 하자 :)
2020/06/09 - [슈르의 오피스라이프/SI 이야기] - [SI이야기] SI에서 인건비를 산정하는 방식(MM, 등급, 단가) 및 예시
1. 턴키(Turn Key)란 무엇인가?
턴키의 정의는 위와 같다. 쉽게 설명하면 처음부터 끝까지의 모든 일을 수행사가 일정 금액을 받고 일하는 것이다. 중요한 포인트는 고객은 완성된 상태만을 받는다는 것이다. 수행사는 다 개발하고 고객은 '열쇠를 돌리면 작동한다'라는 엄청난 계약형태인 것이다.
이마저도 설명이 어렵다면, 자동차를 사는 것과 같다. 고객인 나는 돈을 주고 차를 사는 것이고, 자동차 회사에서 차를 다 만들고 나에게 자동차 열쇠를 주는 것이다. 자동차 시동은 당연히 완벽하게 걸려야 하고, 나는 그 자리에서 바로 그 차를 몰고 갈 수 있는 상황이라고나 할까.
거의 모든 SI 프로젝트에서 이 턴키 방식으로 계약을 진행한다. 규모가 크면 클수록 턴키 방식으로 될 확률이 높다. 이건 계약 방식이기 때문에 협상의 여지도 사실 없다.
자 그럼 턴키 방식과 맨먼스 방식이 있는데 왜 턴키를 선택하는 것일까?
2. 턴키 방식은 '갑'의 리스크가 적다는 장점이 있다.
턴키 방식은 갑이 좋아하는 계약 방식이다. 당연한 이야기다. SI 프로젝트가 보통 턴키 방식으로 이루어져 있다는 건 고객에게 그 방식이 유리하기 때문이다. 중요한 건 '왜 고객에게 유리하냐!'인데 그걸 차근차근 설명해보겠다.
턴키는 계약서를 쓸 때 결과론적인 기준에서 작성이 되기 때문에 디테일이 상당히 약한 편이다. 아무리 요구사항을 촘촘하게 쓰고, 아무리 열심히 준비를 해도, 한 사람이 하루를 사는 데에도 변수가 많은데 하물며 여러 명이서 장기간 동안 일하는 프로젝트는 그 변수가 말도 안 될 정도로 많이 발생하기 마련이다. 이때 고객의 탓을 할 수 있는 여지가 없는 게 턴키 방식의 특징이다.
예시를 들면 이렇다.
CASE 1 : "프로젝트는 1년짜리고, 계약 금액은 10억. 여기에 들어가는 인력은 20명이고, 이 계약은 턴키방식이다."
이런 프로젝트를 6개월 정도 이상 없이 수행하다가 코로나 19가 터졌다고 치자. 갑자기 누군가가 의심자가 되어서 출근을 할 수 없는 상황이 됐다. 불행히도 그 사람과 교류했던 사람이 2명은 더 되기 때문에 자가격리를 해야 하는 상황이다. 프로젝트는 진행되는데 인력이 불가피한 사유로 부족해진 것이다.
다행스러운 것을 먼저 이야기하면, 이로 인해 프로젝트가 다소 지연이 될 경우 고객은 보통 그 지연에 대해서 이해를 하고 넘어가기 마련이다. 누군가의 건강의 문제고, 저항할 수 없는 가이드의 문제이니 '불가피한 상황'이라는 사실을 이해하고 화를 내지 않는 것이다. (만약 수행사의 잘못 - '개발 진도가 잘 안 나가서...'으로 이루어진 지연이라면 엄청나게 혼났을 것이다.ㅜ_ㅜ)
불행한 사실을 이야기하면, 이로 인해 프로젝트가 1년 만에 끝나지 않고 2개월이 더 소요될 수 있다고 한다면 그 비용은 수행사의 부담이 된다. (고객이 그걸 이해하고 "아 그랬군요, 우리가 2개월치 비용 더 드릴게요."라고 말해주는 것을 기대한다면 당신은 회사생활을 하면 안 된다.)
그 이유는 아주 단순하다. 턴키방식으로 계약했기 때문이다. 고객은 프로젝트 중간에 수행사가 북을 치든 장구를 치든 잠을 자든 무엇을 하든 그게 중요하지가 않다. 중요한 것은 '계약한 물건을 받느냐' 이거 하나다. 누군가가 계약서에다가 '코로나와 같은 불가피한 사유(?)로 인한 인력 유실 발생 시 추가 비용은 고객사에서 부담한다"라고 썼다면 고객이 부담했겠지만, 한국에서 그렇게 꼼꼼하게 계약서를 '을'에게 유리하게 쓰는 곳은 본 적이 없다.
턴키가 그러면 고객사에게만 유리한 것이냐? 아니다. 2번의 문장을 잘 보면 답이 있다. '갑'에게 유리한 계약 방식이다. 고객사가 수행사에게 턴키를 주면 수행사가 책임지는 구조다. 그걸 수행사가 혼자 감당 할리가 없는 게 SI의 현실... 수행사도 그 아래에 하도급 업체(협력업체)에게 턴키 방식으로 계약을 넘긴다. 턴키가 꼬리에 꼬리를 물고 이어질 수도 있다는 것이다.(이 놀랍지 아니한가! 갑을병정무 에서 결국 마지막이 폭탄을 끌어안는 구조다.)
3. 그런 턴키도 단점은 비용, 맨먼스의 장점이 그 비용.
턴키와 맨먼스의 차이는 턴키 방식으로 계약할 경우 위와 같은 이유로 발생할 수 있는 추가 비용 또는 손실에 대해서 나름 비상금을 마련해둔다는 것이다. 리스크라는 명목이 될 수도 있는데, 보통은 투입되는 인력의 인건비에 어쩌고 저쩌고 다 더해서 리스크율을 곱하기 해버리는 것이다. 맨먼스로 계약하면 100만 원이었을 프로젝트가 턴키가 되면 150만 원이 되거나 하는 식이다.(리스크율을 얼마나 잡느냐는 case by case다)
그래서 SI 프로젝트 제안을 해야 하거나 가격 경쟁력을 가져가야 하는 경우가 발생하면 수행사는 협력업체와의 계약방식을 턴키를 안 하고 맨먼스 방식으로 하기도 한다.(100만 원으로 진행해서 50만 원을 낮추는 것이다.) 고객사와 수행사는 턴키지만, 협력업체는 맨먼스 방식인 것이다. 가격 경쟁력을 갖추기 위해 수행사가 폭탄을 안고 있는 구조인 셈이다. 이렇게 계약을 했을 때, 만약 인력이 2개월 더 필요하게 된다면, 수행사가 비상금을 깨서 추가 맨먼스 계약을 통해 그 인력을 확보해야만 한다. (맨먼스 방식은 그 맨먼스만 채우면 프로젝트에서 더 일할 의무가 없다는 뜻이기도 하다.)
자 그럼 최종 정리를 해보겠다.
<턴키 방식 - 고객사 기준>
장점 : 갑의 프로젝트 리스크(추가 비용 지출의 가능성)가 줄어든다.
단점 : 리스크의 버퍼를 잡기 때문에 맨먼스보다는 다소 비싸다.
<턴키 방식 - 수행사 기준>
장점 : 결과만 잘 나오기 때문에 가격 적정성에 대한 고객사의 챌린지가 다소 약한 편이다.
: 협력업체와 턴키 방식으로 계약을 하면) 리스크가 적은데 고객사에게 돈은 많이 받고 좋다.
단점 : 맨먼스보다 비용이 높기 때문에 제안 시 가격 경쟁력을 갖기 어려울 수 있다.
: 협력업체와 맨먼스 방식으로 계약을 하면) 초과 비용에 대해서는 수행사가 고스란히 감당해야 한다.
<맨먼스 방식 - 수행사 기준>
장점 : 협력업체에게 투입 인력에 대한 인건비 정도(MM)만 지불하면 되기 때문에 턴키보다 저렴하다.
단점 : 계약한 만큼 일을 다 한 경우 해당 인력은 철수하게 되는데, 프로젝트 지연이 있는 경우 추가 비용을 부담해서 연장 계약을 해야 하는 리스크가 존재한다.
슈 과장은 턴키 방식 계약으로 일을 해보기도 했고 맨먼스 방식으로 일을 해보기도 했다. 프로젝트의 리스크가 크면 클수록 맨먼스 방식의 계약은 지양하게 된다. 실제로 맨먼스 방식으로 계약했는데 프로젝트 일정이 늦어져서 해당 인력에 대해 연장 계약을 해야 했던 경우도 있다. 나도 수행사도 잘못이 없는데 어쩔 수 없는 불가피한 이유(고객님이 원해서^^)로 그 인력을 잡아둬야 했던 상황이 있었다.
맨먼스는 계약만 하면 관심 꺼도 되는 턴키 방식과 달리 관리 요소가 하나 더 늘어난다는 불편함도 있다. 그래서 추가 비용을 부담하지 않기 위해 1MM 추가로 계약하고 그 사람을 일주일에 2일씩 나오게 하는 방식으로 하는 사람들도 있다. 그러면 사실상 1MM(20일)을 채우기 위해서 10주를 나와야 하는 것이다. 그런 치사함마저 발생하는 게 맨먼스 방식이다.
만약 오늘 이 용어를 처음 들었다면, 당신은 계약을 진행하는 사람이 아닐 확률이 매우 높다. 이 문제는 계약하는 회사/사람들이 민감한 이슈니 만약 한 회사 소속의 직원이라면 관심을 꺼도 된다. 회사에서 알아서 '계속 있어라', '일 다 했으니 그냥 나와라'라고 알려줄 것이다 ^^
'슈르의 오피스라이프 > SI 이야기' 카테고리의 다른 글
[SI이야기] SI프로젝트에서 사업관리가 하는 일 (0) | 2020.06.18 |
---|---|
[SI이야기][산출물] WBS를 만들어보자(정의, 작성 예시) (8) | 2020.06.17 |
[SI이야기] SI에서 인건비를 산정하는 방식(MM, 등급, 단가) 및 예시 (7) | 2020.06.09 |
[SI이야기] 제안요청서(RFP) 읽는 방법 - 군산시 공공배달앱 CASE (2) (5) | 2020.06.04 |
[SI이야기] 제안요청서(RFP) 읽는 방법 - 군산시 공공배달앱 CASE (1) (0) | 2020.06.02 |