2017.06.14

칼럼 | '지름길은 없다' 클라우드 프로젝트, 요구 분석부터 제대로

David Taber | CIO
클라우드 프로젝트의 리스크 관리는 그 프로젝트 규모와 상관없이 요구를 찾아내는 '발견' 단계가 가장 중요하다. 프로젝트의 발견과 아키텍처 수립 단계가 전체 과정에서 차지하는 비중은 15%에 불과하지만, 이 초기 과정에서 발생하는 오류 혹은 누락은 150% 이상의 예산 초과를 불러올 수도 있다.



그러나 불행히도 이 시기는 팀 내에 낙관적인 분위기가 팽배하는 단계이기도 하다. 그리고 이러한 태도는 프로젝트에 숨어 있는 리스크를 못 보고 지나치는 원인이 된다.

따라서 이 시기에 업체는 강하게 자신의 주장을 피력하며 의사결정 과정에서 고객을 이끌 수 있어야 한다. 하나를 얻기 위해서는 어쩔 수 없이 포기해야 하는 것이 있다는 '뼈아픈' 사실도 가감 없이 이야기해야 한다. 업체가 이것을 제대로 해낼 수 있는가에 따라 이 '발견' 단계의 성공 여부가 결정된다고 해도 과언이 아니다.

사전 작성한 요건 목록의 맹점
일반적으로 고객은 프로젝트 시작에 앞서 그 요건을 조사, 정리해 문서화해 놓는다. 그러나 이 목록에는 몇 가지 심각한 문제점이 있기 마련이다.

1. 요건 목록이 지나치게 업체의 홍보성 메시지이거나 업계 애널리스트의 체크리스트와 닮아 실제 비즈니스 프로세스의 요구를 반영하지 못한다. 이러한 요건 설정은 실제 사용자의 요구를 반영하지 못하고 기술적 기능만 강조하는 맹점을 갖고 있다.

2. 요건의 우선순위가 제대로 정해져 있지 않아 프로젝트를 예산과 스케줄에 맞춰 수행하기 위해 마땅히 포기하거나 양보할 수밖에 없는 부분이 반영되지 않았다.

3. 요건이 엔드-투-엔드 비즈니스 프로세스에 있어서 매우 중요한 부분을 반영하지 못한 채 미완성 상태로 남아 있다. 이러한 미완성 요건은 보통 프로젝트가 훨씬 더 진행되고 나서 뒤늦게 발견된다. 심지어는 테스팅 단계에 가서야 드러나는 경우도 있다.

4. 기업 전체가 프로젝트를 중심으로 돌아간다고 가정한다. 따라서 사소한 정책 변경이나 조정에도 프로젝트 전체가 흔들릴 수 있다. 달갑지는 않지만 실제로 일어나는 일이다.

이처럼 프로젝트 시작 전에 작성된 요건 문서는 그것만 믿고 프로젝트 전 과정을 헤쳐 나가기에 부족한 부분이 많다. 그래서 컨설턴트는 프로젝트를 여러 단계로 나눠 각 단계에서 요구를 분석하고 설정하는 방식을 선호한다. 이러한 방식을 극단적으로 발전시켜 스프린트마다 '작은 발견' 단계를 둔 것이 바로 애자일(agile)이다.

고객의 현장 속으로
그러나 설령 애자일 프로젝트 방식이라고 해도 고객이 실제 사용자와 고객 입장에서 엔드-투-엔드 비즈니스 프로세스를 경험해보지 않는다면 무용지물일 수 있다. 놀랍게도, 기업 임원과 의사결정자는 기업 운영의 세부적인 부분에 대해 잘 모르고, 또 실무자와 일반 직원은 자신이 맡은 일에 대해서만 알고 있는 경우가 많다.

그 결과 오로지 앱을 실제로 이용하는 고객만이 시스템의 문제점을 알 뿐, 회사 내부의 그 누구도 이러한 앱 이용 프로세스를 처음부터 끝까지 파악하지 못하는 상황이 발생하기도 한다. 따라서 더 심층적 '발견'은 시스템을 다음과 같은 일련의 비즈니스 프로세스로 표현하는 것에서부터 시작된다.

- 타깃 마케팅에서 세일즈 요건 충족
- 셀링 및 파이프라인 매니지먼트
- 계약 견적
- 딜리버리, 설치 및 고객 온보딩
- 인보이싱 및 컬렉션
- 보증 및 서비스 권리
- 사례 관리 및 서비스 스케줄링
- 문제 해결 및 서비스 콜
- 추후 관리 및 고객 설문조사


이러한 분석을 해 보면 특히 규모가 큰 기업에서 비즈니스 전체에 대한 단일한 프로세스 흐름이 전혀 마련돼 있지 않다는 사실을 깨닫게 된다. 다국적 기업의 경우 다음과 같은 부분을 프로젝트에 수용하기 위해 다양한 방법을 마련하고 있다. 이들 프로세스 고유의 특성과 요구에 맞춰 요건을 각기 설계해야 함은 물론이다.

- 지역 또는 국가 단위의 비즈니스 관행 (예: 미국, 유럽, 아시아에서의 전략 차별화)
- 수직적 업계 관행 및 규제 (고객 사생활 보호, 계약 규칙 및 회계 관련)
- 유통 채널 및 조인트 벤처
- 프로젝트에 속하지 않는 레거시 시스템 (예: ERP 또는 이커머스)
- 기업 내/외부에 존재하는 정치적 사유지


기업은 클라우드 프로젝트가 지난 수년간 쌓여 온 시스템상의 너저분한 부분을 한 번에 단순하고 간결하게 만들어 줄 것으로 기대한다. 물론 불가능한 것은 아니다. 그러나 이를 위해서는 진지한 태도로 임하는 사람이 필요하다. 간결화, 단순화를 위해서는 시스템 각 부분의 의미와 목적, 각 부분의 상호작용에 대한 이해가 선행돼야 한다. 그리고 이를 바탕으로 스마트한 통합과 대체 전략을 만들어야 한다. 이런 과정 없이는 지름길로 가는 것이 빨리 가는 것으로 보이지만 결국 더 멀리 돌아가게 된다.

---------------------------------------------------------------
프로젝트 관리 인기기사
->칼럼 | 솔직히 말하자, 프로젝트 후원자와 관리자가 문제다
->프로젝트 리더가 기억해야 할 '사람 우선' 전략 4가지
->프로젝트 관리·추적은 이렇게 '7가지 체험 팁'
->"기대치 조율은 이렇게" 프로젝트 관리 11가지 팁
->"온라인 협업과 프로젝트 관리에 그만!" 무료 툴 7선
->예산•일정•진척도 관리 도와줄 PM툴 5선
->폭포수 프로젝트 관리에도 민첩성이 필요하다
-> ‘에이스프로젝트 · 베이스캠프 · 조호 프로젝트’··· PM 툴 3종 비교분석
-> PM이 대비해야 할 흔한 프로젝트 문제 7가지
---------------------------------------------------------------

멀고 험난한 길
지금까지 제시한 전략은 까다롭고, 시간과 비용이 오래 걸린다. 그러나 전체 프로젝트의 15%를 훨씬 넘는 중요한 부분을 차지하는 '발견' 단계에서 심층 발견 프로세스는 컨설턴트와 클라이언트 모두에게 이득이 될 수 있다. 특히 수년에 걸쳐 (좋은 쪽으로든 나쁜 쪽으로든) 진화해 온 하나 이상의 레거시 시스템을 클라우드 시스템으로 대체할 때는 더 그렇다.

아무리 상급 책임자가 프로젝트를 서두르려 해도 준비되지 않은 상태에서 서둘러 진행한 프로젝트는 결국 오래된 악습과 무력해진 비즈니스 관행을 반복, 자동화할 뿐임을 지적하며 이에 맞서야 한다. 진정한 비즈니스 변혁은 비즈니스 프로세스의 개선에서 시작된다.

* David Taber는 'Salesforce.com Secrets of Success'의 저자이자 SalesLogistix의 CEO이다. 세일즈포스닷컴 인증 컨설턴트로, 주로 CRM을 이용한 비즈니스 프로세스 향상 관련 컨설팅을 제공한다. ciokr@idg.co.kr
2017.06.14

칼럼 | '지름길은 없다' 클라우드 프로젝트, 요구 분석부터 제대로

David Taber | CIO
클라우드 프로젝트의 리스크 관리는 그 프로젝트 규모와 상관없이 요구를 찾아내는 '발견' 단계가 가장 중요하다. 프로젝트의 발견과 아키텍처 수립 단계가 전체 과정에서 차지하는 비중은 15%에 불과하지만, 이 초기 과정에서 발생하는 오류 혹은 누락은 150% 이상의 예산 초과를 불러올 수도 있다.



그러나 불행히도 이 시기는 팀 내에 낙관적인 분위기가 팽배하는 단계이기도 하다. 그리고 이러한 태도는 프로젝트에 숨어 있는 리스크를 못 보고 지나치는 원인이 된다.

따라서 이 시기에 업체는 강하게 자신의 주장을 피력하며 의사결정 과정에서 고객을 이끌 수 있어야 한다. 하나를 얻기 위해서는 어쩔 수 없이 포기해야 하는 것이 있다는 '뼈아픈' 사실도 가감 없이 이야기해야 한다. 업체가 이것을 제대로 해낼 수 있는가에 따라 이 '발견' 단계의 성공 여부가 결정된다고 해도 과언이 아니다.

사전 작성한 요건 목록의 맹점
일반적으로 고객은 프로젝트 시작에 앞서 그 요건을 조사, 정리해 문서화해 놓는다. 그러나 이 목록에는 몇 가지 심각한 문제점이 있기 마련이다.

1. 요건 목록이 지나치게 업체의 홍보성 메시지이거나 업계 애널리스트의 체크리스트와 닮아 실제 비즈니스 프로세스의 요구를 반영하지 못한다. 이러한 요건 설정은 실제 사용자의 요구를 반영하지 못하고 기술적 기능만 강조하는 맹점을 갖고 있다.

2. 요건의 우선순위가 제대로 정해져 있지 않아 프로젝트를 예산과 스케줄에 맞춰 수행하기 위해 마땅히 포기하거나 양보할 수밖에 없는 부분이 반영되지 않았다.

3. 요건이 엔드-투-엔드 비즈니스 프로세스에 있어서 매우 중요한 부분을 반영하지 못한 채 미완성 상태로 남아 있다. 이러한 미완성 요건은 보통 프로젝트가 훨씬 더 진행되고 나서 뒤늦게 발견된다. 심지어는 테스팅 단계에 가서야 드러나는 경우도 있다.

4. 기업 전체가 프로젝트를 중심으로 돌아간다고 가정한다. 따라서 사소한 정책 변경이나 조정에도 프로젝트 전체가 흔들릴 수 있다. 달갑지는 않지만 실제로 일어나는 일이다.

이처럼 프로젝트 시작 전에 작성된 요건 문서는 그것만 믿고 프로젝트 전 과정을 헤쳐 나가기에 부족한 부분이 많다. 그래서 컨설턴트는 프로젝트를 여러 단계로 나눠 각 단계에서 요구를 분석하고 설정하는 방식을 선호한다. 이러한 방식을 극단적으로 발전시켜 스프린트마다 '작은 발견' 단계를 둔 것이 바로 애자일(agile)이다.

고객의 현장 속으로
그러나 설령 애자일 프로젝트 방식이라고 해도 고객이 실제 사용자와 고객 입장에서 엔드-투-엔드 비즈니스 프로세스를 경험해보지 않는다면 무용지물일 수 있다. 놀랍게도, 기업 임원과 의사결정자는 기업 운영의 세부적인 부분에 대해 잘 모르고, 또 실무자와 일반 직원은 자신이 맡은 일에 대해서만 알고 있는 경우가 많다.

그 결과 오로지 앱을 실제로 이용하는 고객만이 시스템의 문제점을 알 뿐, 회사 내부의 그 누구도 이러한 앱 이용 프로세스를 처음부터 끝까지 파악하지 못하는 상황이 발생하기도 한다. 따라서 더 심층적 '발견'은 시스템을 다음과 같은 일련의 비즈니스 프로세스로 표현하는 것에서부터 시작된다.

- 타깃 마케팅에서 세일즈 요건 충족
- 셀링 및 파이프라인 매니지먼트
- 계약 견적
- 딜리버리, 설치 및 고객 온보딩
- 인보이싱 및 컬렉션
- 보증 및 서비스 권리
- 사례 관리 및 서비스 스케줄링
- 문제 해결 및 서비스 콜
- 추후 관리 및 고객 설문조사


이러한 분석을 해 보면 특히 규모가 큰 기업에서 비즈니스 전체에 대한 단일한 프로세스 흐름이 전혀 마련돼 있지 않다는 사실을 깨닫게 된다. 다국적 기업의 경우 다음과 같은 부분을 프로젝트에 수용하기 위해 다양한 방법을 마련하고 있다. 이들 프로세스 고유의 특성과 요구에 맞춰 요건을 각기 설계해야 함은 물론이다.

- 지역 또는 국가 단위의 비즈니스 관행 (예: 미국, 유럽, 아시아에서의 전략 차별화)
- 수직적 업계 관행 및 규제 (고객 사생활 보호, 계약 규칙 및 회계 관련)
- 유통 채널 및 조인트 벤처
- 프로젝트에 속하지 않는 레거시 시스템 (예: ERP 또는 이커머스)
- 기업 내/외부에 존재하는 정치적 사유지


기업은 클라우드 프로젝트가 지난 수년간 쌓여 온 시스템상의 너저분한 부분을 한 번에 단순하고 간결하게 만들어 줄 것으로 기대한다. 물론 불가능한 것은 아니다. 그러나 이를 위해서는 진지한 태도로 임하는 사람이 필요하다. 간결화, 단순화를 위해서는 시스템 각 부분의 의미와 목적, 각 부분의 상호작용에 대한 이해가 선행돼야 한다. 그리고 이를 바탕으로 스마트한 통합과 대체 전략을 만들어야 한다. 이런 과정 없이는 지름길로 가는 것이 빨리 가는 것으로 보이지만 결국 더 멀리 돌아가게 된다.

---------------------------------------------------------------
프로젝트 관리 인기기사
->칼럼 | 솔직히 말하자, 프로젝트 후원자와 관리자가 문제다
->프로젝트 리더가 기억해야 할 '사람 우선' 전략 4가지
->프로젝트 관리·추적은 이렇게 '7가지 체험 팁'
->"기대치 조율은 이렇게" 프로젝트 관리 11가지 팁
->"온라인 협업과 프로젝트 관리에 그만!" 무료 툴 7선
->예산•일정•진척도 관리 도와줄 PM툴 5선
->폭포수 프로젝트 관리에도 민첩성이 필요하다
-> ‘에이스프로젝트 · 베이스캠프 · 조호 프로젝트’··· PM 툴 3종 비교분석
-> PM이 대비해야 할 흔한 프로젝트 문제 7가지
---------------------------------------------------------------

멀고 험난한 길
지금까지 제시한 전략은 까다롭고, 시간과 비용이 오래 걸린다. 그러나 전체 프로젝트의 15%를 훨씬 넘는 중요한 부분을 차지하는 '발견' 단계에서 심층 발견 프로세스는 컨설턴트와 클라이언트 모두에게 이득이 될 수 있다. 특히 수년에 걸쳐 (좋은 쪽으로든 나쁜 쪽으로든) 진화해 온 하나 이상의 레거시 시스템을 클라우드 시스템으로 대체할 때는 더 그렇다.

아무리 상급 책임자가 프로젝트를 서두르려 해도 준비되지 않은 상태에서 서둘러 진행한 프로젝트는 결국 오래된 악습과 무력해진 비즈니스 관행을 반복, 자동화할 뿐임을 지적하며 이에 맞서야 한다. 진정한 비즈니스 변혁은 비즈니스 프로세스의 개선에서 시작된다.

* David Taber는 'Salesforce.com Secrets of Success'의 저자이자 SalesLogistix의 CEO이다. 세일즈포스닷컴 인증 컨설턴트로, 주로 CRM을 이용한 비즈니스 프로세스 향상 관련 컨설팅을 제공한다. ciokr@idg.co.kr
X