솔루션 구매자되기

이 문서는 "트렌치에서" 컬렉션의 일부입니다. 이 문서에서는 잠재 소프트웨어 구매자가 쉽게 이해할 수 있는 비즈니스 분석 방법을 적용하여 소프트웨어 공급업체와의 상호 작용을 보다 효과적으로 만드는 방법을 설명합니다. 여기에서는 소프트웨어 솔루션을 통해 해결해야 할 문제가 무엇인지 효율적으로 확인함으로써 소프트웨어 평가 기준을 작성하는 데 도움이 되는 연습 과정을 안내합니다.

더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.

솔루션 구매자 되기

소프트웨어 구매는 기능 목록, 광고 캠페인 또는 친구의 추천을 기반으로 하는 경우가 많습니다. 이 문서에서는 잠재 소프트웨어 구매자가 쉽게 이해할 수 있는 비즈니스 분석 방법을 적용하여 소프트웨어 공급업체와의 상호 작용을 보다 효과적으로 만드는 방법을 설명합니다.

예전과 같지는 않습니다. 엔터프라이즈 설정에서 소프트웨어를 작동하도록 하는 것은 더 이상 설치라고도 하지 않습니다. 요즘 구현 또는 배포라는 용어는 새 패키지를 시작하고 실행하는 데 필요한 사항을 더 잘 설명합니다.

점점 더 많은 소프트웨어 공급업체가 솔루션으로 판매하는 것에 대해 이야기하고 있으며, 이는 당연한 일입니다. Microsoft Project Server 또는 Microsoft CRM 같은 엔터프라이즈 시스템을 배포할 때는 먼저 관련될 다양한 기술 계층에 대해 생각해야 하며, 이를 시작하기 전에 전체 비즈니스에 미치는 영향에 대해 생각해야 합니다.

판매할 솔루션은 물론 솔루션 판매도 함께 제공됩니다. 이를 전혀 따른다면, 중대형 조직을 대상으로 하는 지구상의 거의 모든 하이테크 조직이 솔루션 판매 제공자로 다시 만들기 위해 노력하고 있다는 것을 알고 있습니다. Microsoft는 확실히 이러한 조직 중 하나입니다. Microsoft는 지난 몇 년 동안 현장 판매 및 구현력에서 지침 원칙으로 판매되는 솔루션을 확립하기 위해 광범위하게 노력해 왔습니다.

그렇다면 솔루션 영업 사원이란? 그들은 여전히 영업 사원입니다 사실이다. 그러나 솔루션 영업 사원은 소프트웨어 상자를 이동하는 것뿐만 아니라 클라이언트가 상황을 개선하는 데 도움이 되는 무언가를 구축하는 것을 목표로 합니다.

지금까지 좋은 소리; 모든 인생에서 당신의 많은 개선하고자하는 영업 사원의 너바나. 그러나 이것은 과제와 함께 제공되며, 그 문제를 해결하는 것은 잠재 클라이언트가 참여할 수 있는 것입니다.

문제에 집중

대부분의 솔루션 영업 사원이 시장에 도착했을 때 직면하는 과제는 솔루션이 어떻게 생겼는지에 대한 우리의 선입견입니다. 우리는 소프트웨어의 기능과 기능에 집중하는 데 너무 익숙합니다, 우리는 소프트웨어 판매원에게 이야기 할 때 대화는 거의 필연적으로 직접 리드, "소프트웨어가이 작업을 수행 할 수 있습니까? 소프트웨어가 그렇게 할 수 있나요?" 숙련된 소프트웨어 영업 사원과 포지션을 판매하는 솔루션으로 옮겨가는 유형은 함수 및 기능을 판매하는 데 너무 많이 사용되므로 가장 기본적인 질문인 "무엇이 문제인가요?"를 묻는 것을 잊어버리는 경우가 많습니다.

이제 이것은 어리석은 것처럼 들릴 지 모르지만 소프트웨어 영업 사원과의 마지막 몇 가지 대화에 대해 생각하면이 질문이 거의 나오지 않는 것에 놀랄 수 있습니다. Microsoft 및 해당 파트너와 같은 공급업체는 매년 많은 제안 요청을 받습니다. 나는 수년에 걸쳐 그들 중 수백을 보았고, 거의 항상 존재하는 한 가지는 공급 업체가 채울 것으로 예상되는 함수의 긴 그리드입니다. 이 큰 스프레드시트는 종종 클라이언트에 대한 회신의 핵심입니다.

거의 존재하지 않는 것은 이러한 각 기능에서 해결할 비즈니스 요구 사항에 대한 설명입니다. 이전 제품에서 잘 알고 있거나 어딘가에서 승격된 것을 보았기 때문에 이 신제품에 관심을 가지게 된 것에 집중하기 위해서는 진정한 규율이 필요합니다. 특히 어떤 유형의 솔루션을 찾고 있는지에 대한 입력이 많은 엔터프라이즈 설정에서 특히 그렇습니다. 사람들이 특정 비즈니스 요구 사항에 대해 이야기하는 것보다 새 소프트웨어 시스템에서 하고 싶은 모든 기능을 나열하도록 요청하는 요청을 보내는 것이 훨씬 쉽습니다.

명백한 것을 놓치고 있다고 생각하기 시작했다면, 당신은 혼자가 아닙니다. 이 조건은 현재 소프트웨어 업계에서 널리 퍼져 있어 비즈니스 분석가라는 새로운 컨설턴트 범주가 생겨났습니다. 이러한 사용자는 비즈니스 요구 사항에서 소프트웨어 기능으로 연결하도록 학습됩니다. 기업 수준 소프트웨어 평가에서 비즈니스 분석가가 기본 개념을 적용하는 방식으로 기본 개념을 적용하는 방법을 몇 분 정도 살펴보겠습니다.

비즈니스 요구 사항 식별

가장 먼저 고려해야 할 것은 비즈니스 요구 사항으로 인해 처음에 새로운 소프트웨어 시스템을 찾게 된 것입니다. 우리 조직은 종종 엔터프라이즈 프로젝트 관리 소프트웨어 구현에 대해 회사에 문의합니다. 컨설턴트로 조직에 도착했을 때 소프트웨어를 구입할지 여부에 대해 이야기하기 훨씬 전에 조직이 지금 프로젝트 관리를 어떻게 하고 있는지 묻습니다.

그들이 대답을 마칠 때, 나는 항상이 후속 질문을 물어: "그 방법은 당신을 위해 작동?" 놀랍게도 클라이언트는 종종 대답합니다. 나를 위해 구현 대화는 거기에 중지해야. "문제가 없다면 해결책을 만들 방법이 없습니다!" 종종 이 대답은 사람들을 일시 중지하게 합니다. "왜 전화했나요?" 나는 물어 볼게요. 답변은 매우 다양할 수 있으며, 사람들이 조정해야 하는 몇 가지 의제가 있으며 대화가 5분 미만이라는 것을 깨닫고 방을 둘러보는 것은 드문 일이 아닙니다.

따라서 "비즈니스에 무엇이 필요한가요?"라고 묻는 것은 시작하기에 좋은 장소입니다. 이 질문에 답변하는 전체 목표는 거의 항상 있습니다. 처음에 이니셔티브를 시작한 목표입니다.

비전 연습 수행

다음으로 소프트웨어 기능 측면에서 이것이 무엇을 의미하는지 좀 더 자세히 살펴봐야 합니다. Microsoft Project Server와 같은 엔터프라이즈 프로젝트 관리 소프트웨어를 조직에 구현할 때는 항상 핵심 담당자(소프트웨어를 평가하는 사람) 및 연습을 후원하는 고위 경영진이 참여하는 비전 연습으로 시작합니다. 이 연습의 목적은 비즈니스 목표를 기술 기능에 연결하는 것이므로 기술 담당자만으로는 이 연습을 수행하는 것만으로는 충분하지 않습니다.

이 작업을 수행하는 효과적인 방법은 큰 화이트보드가 있는 방에 핵심 인력을 배치하는 것입니다. 화이트보드를 4열로 나눕니다. 맨 오른쪽 열에서만 제목으로 시작합니다. 이를 "비즈니스 결정"이라고 부릅니다.

오른쪽 열에서 고려 중인 새 시스템을 사용하여 원하는 비즈니스 결정을 나열합니다. 클라이언트에서 이 작업을 수행할 때 가장 먼저 해야 할 일은 많은 기능을 나열하는 것이므로 중요한 대답은 비즈니스 의사 결정이라고 주장해야 합니다. 예를 들어 참가자는 즉시 "모든 리소스 및 해당 워크로드 목록이 필요합니다"라고 말할 수 있습니다. 물론 그럴 수도 있지만, 알아내야 할 것은 해당 목록으로 어떤 비즈니스 결정을 내릴 것인가하는 것입니다.

비즈니스 결정의 몇 가지 예는 다음과 같습니다.

• 특정 부서에서 채용 또는 해고

• 프로젝트에 대한 이동 또는 이동 안 않음 결정

비즈니스 의사 결정의 괜찮은 목록이 있으면 일시 중지합니다. 이제 비즈니스 의사 결정 목록을 검토하고 우선 순위가 가장 높은 결정을 파악할 수 있는 좋은 시기입니다. 이러한 비즈니스 의사 결정 중 하나에 대한 답변만 얻을 수 있다면 조직에 가장 큰 가치를 제공할 수 있는 질문을 스스로에게 물어볼 수 있습니다. 이 시점에서 상위 3가지 결정을 선택하는 것이 항상 가장 쉽습니다.

지금까지 얻은 경우 이미 엔터프라이즈 프로젝트 관리 소프트웨어를 찾는 대부분의 조직보다 더 많은 성과를 거두었습니다. 시스템 공급업체에 가장 중요한 비즈니스 의사 결정의 우선 순위 목록을 제공할 수 있다는 것은 전체 프로세스에서 큰 진전입니다. 시스템 공급업체에 어떤 비즈니스 의사 결정을 내려야 하는지 알려줄 수 있는 경우 간단한 기능에 대해 이야기하는 것 이상으로 조직을 보다 효과적으로 만드는 방법에 대해 이야기할 수 있습니다.

다음으로 각 결정을 살펴보고 "비즈니스 결정을 내리기 위해 어떤 보고서가 필요한가요?" 하고 묻습니다. 거의 모든 결정은 하나 이상의 보고서를 보고 결정됩니다. 세 번째 열에 "보고서"라는 레이블을 지정합니다. 상위 세 가지 결정 각각에 대해 해당 결정에 필요한 보고서를 해당 열에 나열합니다.

예를 들어 특정 부서의 직원을 고용할지 또는 소방 인력을 고용할지 결정하려면 리소스 용량 계획 데이터를 보여 주는 부서별 보고서가 필요하다고 말할 수 있습니다. 여기에는 예상 워크로드, 예상 리소스 가용성 및 일정에 대한 예측이 포함됩니다. 중견 기업인 경우 현금 흐름도 문제가 될 수 있습니다. 예를 들어 추가 인력이 필요하지만 고용할 현금을 찾지 못할 수 있습니다. 현금 흐름 보고서에는 예상 수입과 잔액이 있는 자금 유출이 포함됩니다.

우선 순위로 식별한 각 결정에 대한 보고서 열을 입력하면 필요한 사항의 모양이 이미 명확해지기 시작했습니다. 완료되면 잠재 시스템에서 필요한 물리적 출력 목록이 표시됩니다.

조직에서 이미 사용 중인 것으로 확인된 유형의 보고서가 이미 있는지 확인하려면 여기서 다시 일시 중지합니다. 이러한 보고서가 존재하지만 다양한 형식으로 불완전한 데이터 또는 생성을 위해 과도한 노력이 필요할 수 있습니다. 조직에서 작업한 보고서 형식을 찾으면 시스템 요구 사항 목록에 추가할 수 있습니다. 이제 시스템 공급업체에 더 많은 정보를 제공할 수 있습니다.

이제 주요 보고서가 식별되면 해당 보고서를 생성하는 데 필요한 시스템의 요소로 이동할 수 있습니다. 차트의 두 번째 열에 제목 "Analysis"를 추가합니다. 각 보고서에 대해 보고서를 생성하는 데 필요한 분석 또는 알고리즘을 식별합니다. 예를 들어 리소스 용량 계획 보고서의 경우 프로젝트 관리 시스템의 중요한 경로 일정과 리소스 평준화 분석이 필요할 수 있습니다.

이러한 분석은 종종 각 기능이 포함된 수많은 기능을 기반으로 공급업체에서 판매합니다. (예, 기능별 판매는 여전히 살아 있고 잘!) 확인할 수 있어야 하는 것은 필요한 보고서를 제공하는 최소한의 기능이며, 이를 통해 식별한 비즈니스 의사 결정을 내리거나 개선할 수 있습니다. 실제 비즈니스 요구 사항을 충족하기 위해 필요한 기능이 얼마나 기본적인지 놀랄 수 있습니다. 일부 보고서의 경우 분석이나 계산이 전혀 필요하지 않습니다. 보고서는 새 시스템의 데이터에서 바로 생성할 수 있는 간단한 집계일 뿐입니다.

마지막으로 차트의 첫 번째 열로 옵니다. 필요한 분석을 확인한 후에는 분석을 제공하는 데 필요한 데이터 요소를 결정하도록 이동할 수 있습니다.

차트의 첫 번째 열에 제목 "입력"을 추가합니다.

사용했던 예제에서는 부서의 작업에 관련된 각 프로젝트에 대한 전체 작업 목록이 필요할 수 있습니다. 조직의 모든 프로젝트일 수 있습니다. 또한 일정 분석에서 작업이 이동하면 워크로드가 리소스 평준화 분석에서 이동되도록 각 작업에 정의된 워크로드와 함께 각 리소스의 가용성에 대한 전체 프로필이 필요합니다. 또한 특정 부서에서 채용 또는 해고 결정을 시작한 방법을 기억하십니까? 또한 부서별로 리소스를 식별할 수 있어야 합니다.

새 엔터프라이즈 시스템에서 필요한 모든 것을 식별할 때까지 오른쪽의 출력에서 왼쪽의 입력으로 다음과 같이 이동할 수 있습니다.

위험 평가

이 연습이 완료되면 각 입력으로 돌아가서 이러한 데이터 요소를 사용할 수 있는 방법을 결정하는 것이 좋습니다. 종종 그렇듯이 이러한 항목 중 일부는 존재하지 않는다는 것을 알게 될 수 있습니다. 예를 들어 일부 조직에서는 리소스 가용성의 전체 목록을 유지 관리하지 않습니다. 또한 모든 프로젝트에 해당 프로젝트에서 생성된 리소스 부하를 보여 주는 리소스 로드 일정이 있는 것은 아닙니다. 많은 조직에서 특정 유형의 프로젝트는 어떤 종류의 시스템에도 포함되지 않습니다. 응급 작업, 기술 지원 작업 또는 정기적인 유지 관리 작업이 몇 가지 일반적인 예입니다.

비즈니스 가치를 제공하는 데 필요한 기본 데이터에 액세스할 수 없는 경우 시스템의 해당 요소를 고위험으로 확인해야 합니다. 예를 들어 조직 프로젝트의 80%에 대한 리소스 로드 일정을 식별할 수 있는 경우 직원을 늘리거나 줄이는 비즈니스 결정을 개선할 것으로 합리적으로 기대할 수 있나요? 대답은 "아니오"일 가능성이 높습니다. 왜? 시스템에 없는 프로젝트의 20%가 특정 부서의 작업 부하의 80%를 나타낼 수 있기 때문일 수 있습니다. 모든 데이터가 없는 경우 최종 보고서가 정확한지 알 수 없습니다.

물론 이러한 종류의 문제에 대한 방법이 있습니다. 한 가지 방법은 데이터 요소에 액세스할 수 없는 조직의 이러한 측면의 모든 비즈니스 프로세스를 격리하는 것입니다. 프로젝트가 시스템에 없을 수 있는 부서에는 리소스도 나열되지 않습니다. 이 작업은 모든 경우에 간단하게 수행할 수 없습니다. 이러한 비즈니스 프로세스 및 비즈니스 의사 결정이 구현에 얼마나 많은 위험을 초래하는지 파악하려면 항목별로 확인해야 합니다. 이 시점에서 개선하고자 하는 최종 비즈니스 결정의 우선 순위를 다시 지정하는 것은 드문 일이 아닙니다. 매우 바람직하지만 매우 높은 위험으로 판명되어 배포의 초기 단계에서 추구할 가치가 없는 결정을 내릴 수 있습니다.

수행한 작업 문서화

이러한 종류의 모임을 수행할 때 프로세스 전체에서 메모와 메모를 기록하는 작업을 수행하는 사람인 서기관을 할당합니다. 특정 비즈니스 결정이 높은 우선 순위 또는 낮은 우선 순위로 평가된 이유 또는 참조할 좋은 메모가 없는 경우 고위험으로 간주되는 이유가 빠르게 잊혀질 것입니다.

다음을 기록하는 것이 매우 중요합니다.

• 화이트보드에 작성한 내용

• 프로세스에 참여한 사람

• 각 최종 비즈니스 결정을 소유하는 사람

이 시점에서 압도감을 느낀다면 두려워하지 마십시오. 이 전체 연습은 가장 큰 조직에서도 매우 빠르게 수행할 수 있습니다. 하루 이틀 만에 전체 프로세스를 완료할 수 있는 것은 드문 일이 아닙니다. 성공의 열쇠는 적절한 수준의 관리를 회의실로 가져오는 것입니다. 또한 이러한 유형의 모임은 조직 외부의 누군가가 항상 수행했던 방식으로 작업을 수행하는 데 방해가 되지 않는 것이 가장 좋습니다.

지식은 힘입니다.

엔터프라이즈 프로젝트 관리 시스템(실제로 모든 종류의 엔터프라이즈 시스템에서)을 살펴보는 경우 이 연습을 완료하면 소프트웨어 시스템 공급업체와 상호 작용할 때 엄청난 양의 전력이 제공됩니다. 사용자에게 중요한 시스템의 요소와 그렇지 않은 요소를 즉시 구분할 수 있습니다. 소프트웨어 공급업체는 원하는 보고서 및 의사 결정 목록을 제공할 수 있습니다.

공급업체에서 제공하는 일부 응답에 놀랄 수 있습니다. 기능별 이외의 방식으로 응답할 수 있습니다. 즉, 정사각형 함수를 라운드 요구 사항에 맞추려고 하면 더 나은 공급업체는 시스템을 사용하여 비즈니스 문제에 가장 적합한 방법을 보여줄 수 있습니다.

다음은 이 연습을 수행할 때 가장 큰 이점입니다. 즉, 기성용 평가 기준을 만들었습니다. 이제 개념 증명 단계에서 시스템이 수행해야 하는 비즈니스 의사 결정을 개선하는 데 필요한 정보를 제공하는지 여부에 즉시 집중할 수 있습니다.

작성자 정보

Chris Vandersluis는 캐나다에 본사를 둔 HMS 소프트웨어인 Microsoft Certified Partner인 몬트리올의 사장 겸 설립자입니다. 그는 맥길 대학교에서 경제학 학위를 취득했으며 프로젝트 제어 시스템의 자동화 분야에서 30년 이상의 경험을 보유하고 있습니다. 그는 PMI(프로젝트 관리 연구소)의 오랜 회원이며 MPUG(Microsoft Project Users Group)의 몬트리올, 토론토 및 퀘벡 지부를 설립하는 데 도움을 주었습니다. Chris가 저술한 출판물에는 포춘, 헤비건설 뉴스, 컴퓨팅 캐나다 잡지, PMI의 PMNetwork 등이 있으며, 프로젝트 타임즈의 정기 칼럼니스트입니다. 그는 McGill 대학에서 고급 프로젝트 관리를 가르치고 종종 북아메리카 및 전 세계의 프로젝트 관리 협회 기능에서 연설합니다. HMS Software는 TimeControl 프로젝트 지향 시간 유지 시스템의 게시자이며 1995년부터 Microsoft 프로젝트 솔루션 파트너로 활동해 왔습니다.

Chris Vandersluis는 다음에서 전자 메일로 연락할 수 있습니다. chris.vandersluis@hms.ca

Chris Vandersluis에서 더 많은 EPM 관련 문서를 읽으려면 HMS의 EPM 지침 사이트(https://www.epmguidance.com/?page_id=39)를 참조하세요.