빅뱅 규모의 적정성

 빅뱅 방식의 프로젝트 진행이 불가피하다 해도 숙련된 현업 사용자들이 감당 가능할 정도의 규모라야만 프로젝트가 성공하게 됩니다.

 시스템을 점진적으로 도입하거나 개발하기가 좌절되거나 왜곡되기 십상이기는 어느 기업이나 매한가지입니다. 덕분에 일단 일부터 저질러 놓고 보는 빅뱅 방식의 프로젝트가 많아졌습니다. 모르긴 해도 금융권과 같이 1분이라도 멈춰서는 곤란한 곳 말고는 대규모 구매에 따른 비용 할인 효과 또한 무시하지 못해 빅뱅 방식을 채택하곤 합니다.

 얼마 전에 어떤 곳은 전사적자원관리(ERP), 재무위험관리(FRM), 자금흐름관리(CFM), 비즈니스계획시스템(BPS), 경영정보시스템(EIS) 등을 일 년 남짓한 기간에 몽땅 구축하겠다고 밝혔습니다. 두말할 것도 없이 정말 어려운 프로젝트입니다. 실제로는 독립적으로 실행해도 부족하지 않을 프로젝트의 집합이기 때문입니다. 더군다나 시스템 관점으로 보면 저 중 몇몇은 정보를 받기만 하는 EIS(임원정보시스템) 류와는 달리 서로 정보를 주고 받아야 합니다. 각자의 프로세스가 명확하지 못한 상황에서 서로 영향을 줄 수 밖에 없는 시스템을 동시에 구축하기란 보통 일이 아닙니다. 누군가에게 저 1년은 지옥과도 같을 거라 봅니다.

 물론 요구사항을 엄격히 제한하고 우선순위를 분명히 하며 검증 기간을 넉넉히 한다면 모범적으로 끝날 가능성이 없지는 않습니다만 단기적인 비용 지출을 낮추기 위해 너무 힘든 길을 택했다는 생각은 지우지 못하겠습니다. 각각의 프로젝트 성공 수준보다는 하위 프로젝트 간 조율 능력이 궁극적인 성패를 가름할 텐데 이런 게 더 어렵잖습니까? 

 이렇게 어렵다 어렵다 얘기했는데 진짜 어려운 이유는 따로 있습니다. 바로 이미 정해진 수의 숙련된 현업 사용자가 모든 하위 프로젝트들을 감당하기 힘들기 때문에 규모가 큰 프로젝트가 겹칠수록 어려워질 수 밖에 없습니다. 전산실 인력도 이에 포함됩니다. 본래 하던 일이 있는데 프로젝트가 생기면 아무래도 힘듭니다. 그런데 동시에 뛰어야 할 프로젝트가 전임이든 겸임이든 여러 개라면 감당이 될까요? 물론 결과물은 나옵니다. 어떻게든 나오죠. 이때까지 나오지 않은 적은 거의 없습니다. 때문에 아예 프로젝트 참여 자체를 회피하거나 최대한 발을 담그지 않지요. 깔끔하게 성공의 단물을 포기해 버리기도 합니다.

 그렇다고 현업 참여를 강제하려 해서도 안됩니다. 콩 심은 데에 콩 나며 공짜 점심은 없습니다. 보다 적은 비용으로 보다 적은 사람들이 일을 했다면 결과물도 보다 작기 마련입니다. 시급함의 당위성을 이야기하는 사람들도 있을 텐데 감히 자기 최면에 의한 당위성이라 하겠습니다. 왜 그리 맹목적으로 배수의 진을 칩니까? 모험을 해야 하는 상황에 대한 판단은 각자의 몫입니다만 ERP에 FRM, CFM까지 생각할 회사라면 다소 느리더라도 쉽게 갈 수 있는 길을 택하는 게 좋지 않을까요? 단순히 프로젝트 비용만으로 어려운 결정을 내리지는 않았으면 합니다. IT 인력은 둘째 치고 최소한 현업은 감안하길 바랍니다.

 이러니 저러니 해도 주체는 현업 사용자입니다. 현업이 허덕이면 IT나 여타의 외부인력이 할 수 있는 게 별로 없습니다. 그냥 끝내고 나가기 위해 짜맞출 뿐이죠. 현업이 IT 프로젝트를 참가할 때 괴로운 마음을 적게 가질 상황이라야 진정으로 시행착오를 줄이며 프로젝트를 진행하게 될 겁니다.

 사족이지만, 제 취향 대로 저 프로젝트들을 실행한다면 ERP/BPS → DW/OLAP → EIS/CFM → EIS/FRM 순으로 진행할 겁니다. 굳이 경부 고속도로 짓듯 프로젝트를 할 필요는 결코 없잖습니까? 단계만 잘 나눠도 인명을 지키고 장기적으로는 효율과 효과라는 두 마리 토끼를 모두 잡을 수 있습니다.