드릴이 아니라 구멍 판매

나는 최근에 흥미로운 표현을 우연히 만났다. 소프트웨어 영업 사원이 클라이언트에 전체 솔루션을 제공하는 것에 대해 이야기하고 있었습니다. "우리는 훈련을 판매하지 않습니다. 우리는 구멍을 팔고 있다"고 말했다. 그것은 좋은 비유입니다. 많은 사람들 (나 포함)이 하드웨어 상점에 가서 전류 도구 부서에서 쇼핑 창이 위대한 전구 구매를 정당화 할 수있는 어떤 프로젝트를 생각할 수 있는지 궁금해했습니다. 그러나 이 논리를 적용하는 것은 엔터프라이즈 소프트웨어 시스템에서와 마찬가지로 직접 수행하는 환경에서도 의미가 있습니다.

문제가 없는 경우 솔루션이 필요하지 않습니다.

그들이 해결하고 싶은 문제가 구멍을 만드는 것이 아니라면 아무도 훈련을 찾아야하는 것처럼, 어떤 문제를 해결하지 않는 한 아무도 엔터프라이즈 소프트웨어를 찾아서는 안됩니다. 이제 엔터프라이즈 소프트웨어를 배포하는 것이 해결될 문제가 있는 경우, 다음으로 보장해야 할 것은 구매하는 것이 필요한 솔루션을 제공한다는 것입니다. 그것은 종종 단지 소프트웨어를 구입하는 것보다 훨씬 더 많은 것입니다.

엔터프라이즈 시스템을 배포하는 것은 복잡한 과제이므로 보수를 받을 만한 가치가 있어야 합니다. 오늘날 글로벌 프로젝트 팀의 세계에서 가장 일반적인 작업 중 하나는 엔터프라이즈 시스템 배포의 엄청난 노력을 나누는 것입니다. 이를 통해 프로젝트의 측면에서 고도로 훈련된 팀을 사용하여 규모의 경제를 제공할 수 있지만, 매우 위험한 방식으로 프로젝트의 측면을 간과할 위험이 있습니다. 이러한 위험은 다른 팀이 물리적으로나 조직적으로 연결이 끊어지게 될수록 더욱 복잡합니다.

엔터프라이즈 시스템 프로젝트의 가장 일반적인 요소를 살펴보겠습니다.

엔터프라이즈란?

우선 엔터프라이즈의 의미는 무엇인가요? 나는 거의 모든 사람을 위해 작동해야 정의를 취할 것이다. 이 컨텍스트에서 "Enterprise"는 전체 조직이 작동하는 방식에 영향을 미치는 모든 프로젝트를 의미합니다. 나는 이것이 모든 조직에 대해 사실이라고 말할 것이다. 엔터프라이즈 구현으로 자격을 갖춘 구현은 사용자 수뿐만 아니라 얼마나 많은 영향을 미치는지에 대한 것입니다. 따라서 공급업체 A에서 공급업체 B로 바이러스 검사 소프트웨어를 업데이트하는 것은 자격이 없을 것입니다. 소수의 사용자를 위해 데스크톱에서 프로젝트 예약 소프트웨어를 구현하는 것은 자격이 없을 가능성이 큽니다. 프로젝트 관리를 중앙 집중화하고 중앙 집중식 엔터프라이즈 프로젝트 관리 시스템을 사용하는 것이 적합할 수 있습니다.

그렇다면 엔터프라이즈 프로젝트인 경우 엔터프라이즈 시스템 배포의 가장 일반적인 요소는 무엇인가요? 사무실에서 가장 일반적인 환경은 자체 TimeControl과 같은 엔터프라이즈 작업표 시스템 또는 Microsoft Project Server와 같은 엔터프라이즈 프로젝트 관리 시스템을 배포하는 것이지만 이러한 요소는 거의 모든 엔터프라이즈 시스템 구현에 공통적으로 적용됩니다.

비트 및 바이트

먼저 소프트웨어의 가장 기본적인 구성 요소인 기술 아키텍처를 살펴보겠습니다. 요즘 우리는 온-프레미스 배포 또는 클라우드 내 구독으로 가기로 한 결정에 따라 생각을 나누어야 합니다. 나는 이 중 어느 것이 다른 날의 어떤 조건에서 가장 좋은지 선택하는 경이로움을 남길 것이지만, 각 범주에서 우리가 생각해야 할 기본 사항 중 일부는 다음과 같습니다.

온-프레미스 설치를 진행하는 경우 어떤 하드웨어를 사용할지 고려해야 합니다. 메모리 및 CPU에 대한 하드웨어 요구 사항은 무엇인가요? 물리적 서버 또는 가상 서버를 사용합니까? 전용 서버 또는 공유를 사용합니까? 어떤 종류의 서버가 필요할 수 있나요? 애플리케이션 서버, 보안 서버, 웹 서버 서버가 필요한가요? 부하 분산, 재해 복구 및 백업은 어떻습니까? 콜드 또는 웜 백업 서버가 필요한가요? 휴! 그러나 우리는 끝나지 않았습니다! 데이터베이스는 어떻습니까? 요구 사항은 무엇인가요? 기존 보안, 애플리케이션 및 데이터베이스 아키텍처에 대한 지원은 어떻습니까? 브라우저, 브라우저 버전 및 모바일 디바이스에 대한 지원은 어떻습니까? 이러한 모든 질문에 대한 답변이 있으면 설치, 테스트 및 프로덕션 환경의 문제를 처리한 다음 시스템이 가동되고 실행되면 시스템 상태 및 모니터링을 처리해야 합니다.

클라우드 내 구독 구현을 진행하는 경우 매우 다른 질문이 있을 수 있지만 여전히 대답할 질문이 있습니다. 어떤 온라인 서비스를 사용합니까? 전용 설치 또는 다중 테넌트 서비스를 사용합니까? 보안은 어떨까요? 자체 인증과 통합할 수 있나요? 구독 서비스를 사용하여 재해 복구를 처리하려면 어떻게 해야 할까요? 데이터는 물리적으로 어디에 있나요? 이것은 우리에게 법적 문제가 있습니까? 내부 브라우저 및 모바일 디바이스에 대한 지원은 어떻습니까? 데이터를 어떻게 가져와서 내부 데이터베이스 또는 기타 외부 SaaS(Software as a Service) 서비스와 연결하여 기능을 통합하려면 어떻게 해야 하나요?

아직 숨이 쉴 수 없나요? 엔터프라이즈 시스템에 대해 이야기할 때 이러한 질문 등이 의제에 있습니다. 프로젝트의 이 부분을 고도로 훈련된 기술 팀으로 옮기면 전체 프로젝트의 범위로 생각하기 시작할 수 있습니다.

나를 구성합니다!

시스템이 작동하는 것 외에도 해당 시스템 내의 기능을 특정 문제에 적용하고 있습니다. 클라이언트가 Project Server를 가동 및 실행하는 Project Server 배포를 본 다음 워크플로 만들기, 프로젝트 포트폴리오의 우선 순위를 지정하는 방법 또는 단일 보고서를 만드는 방법을 학습하기 위한 자금을 할당하지 않았다는 것을 깨달았습니다. 대학으로 돌아온 시스템 분석 101과 마찬가지로, 실제 비즈니스 문제가 있는 비즈니스 사용자에게 필요한 "출력"을 요청할 때 일반적으로 화이트 보드의 맨 오른쪽에서 구현의 이 부분을 시작합니다. 나는 다른 글에서 전에 이것에 대해 이야기했기 때문에 여기에 그것을 belabor하지 않을 것이지만, 출력은 궁극적으로 비즈니스 결정이어야합니다. 이러한 결정을 내리려면 어떤 보고서, 분석 및 궁극적으로 데이터 입력이 필요한가요? 화면의 오른쪽에서 왼쪽으로 작업하며, 시스템에서 구성해야 하는 데이터 요소, 분석 계산, 내보내기 및 보고서의 형태로 필요한 모든 구성 요소 목록이 표시됩니다. 이 구성 연습은 복잡성에 따라 몇 주 또는 몇 달이 걸릴 수 있습니다.

프로젝트의 이러한 측면에 필요한 리소스 유형은 비즈니스 분석가와 시스템 전문가의 조합인 경우가 많으며, 이러한 사용자는 배포되는 시스템의 기능에 고도로 숙련되어 있지만 기술 아키텍처에 능숙하지 않은 것이 일반적입니다. 따라서 시스템의 두 가지 중요한 요소에 대한 연결이 끊긴 팀이 매우 일반적입니다. 이러한 두 그룹이 통신을 덜 할수록 나중에 도전에 직면할 가능성이 높아집니다.

프로세스입니다.

새 엔터프라이즈 시스템을 배포하는 것은 불가능하며 조직의 프로세스에 영향을 미치지 않습니다. 하나의 중앙 집중식 엔터프라이즈 시스템을 포기하고 경쟁사로 이동하더라도 프로세스가 변경됩니다. 사실, 프로세스를 변경하지 않으려는 경우 해결이 필요한 문제가 없을 수 있으며 여기에 또 다른 도전이 있습니다. 사람의 일상생활이 바뀌면 화가 납니다. 나는 시간의 일부를 의미하지 않는다. 내 경험에서, 변화의이 시간에 화가 주어진. 프로세스 변경으로 인해 더 나은 프로세스가 발생하는 경우에도 마찬가지입니다. 따라서 프로세스가 어떻게 변경될지 생각하고 영향을 받는 사람들과 함께 작업하는 것은 프로젝트의 성공에 매우 중요합니다. 그러나 프로세스에서 이러한 변화를 설계하는 데 중요한 바로 그 전문가는 아마도 이러한 변화의 영향을 받는 동일한 사람들이기 때문에 구현의 어려운 측면이 될 수 있습니다. 일반적으로 숙련되고 숙련된 촉진자는 내부 전문가와 협력하여 새로운 시스템의 구현과 함께 가능해진 프로세스의 변화를 안내합니다. 우리의 작업 라인에서, 우리는이 도전을 항상 볼 수 있습니다. "하지만 프로젝트 관리자는 작업표 승인을 먼저 수행해야 합니다." 새로운 TimeControl 클라이언트가 알려줍니다. "그게 우리의 과정입니다." 매트릭스 승인을 통해 프로젝트 관리자가 더 크고 효과적인 프로세스의 일부로 작업표 승인을 수행할 수 있다고 설명하면 화가 납니다. pushback. 이 시점에서, 우리는 우리의 가장 경험이 풍부한 직원 중 하나가 영향을받는 사람들과 협력하여 그들의 우려를 처리하고 프로세스가 어떻게 변화할지에 필수적인 부분임을 확인합니다.

따라서 프로세스 사용자는 구성 사용자 또는 기술 인력이 아니지만 이 팀이 계획되지 않은 경우 설치 및 구성에 대한 모든 노력이 배포되지 않을 것입니다. 이 팀도 다른 두 팀이 내린 커뮤니케이션과 결정에 포함된 계획의 일부가 되어야 합니다.

교육

"그래서, 우리는 훈련이 필요합니까?" 불행하게도 종종 마지막으로 묻는 질문입니다. 일부 교육은 프로젝트의 해당 부분에 많은 실무 논의가 필요하기 때문에 프로세스 변경을 통해 올 수 있지만 새로운 시스템이 단계별 방식으로 작동하는 방법에 대한 실제 사용자 가이드는 어떻습니까? 한 때 교육은 소프트웨어 배포의 중요한 요소로 간주되었으며 클라이언트는 전체 예산의 약 20%를 제쳐놓을 것으로 예상했습니다. 그러나 소프트웨어 비용 및 설치 속도의 변화로 20%가 점점 더 적어졌습니다. 시스템에 대해 사용자당 매월 $20를 지불하는 경우 학습을 위해 사용자당 $4를 따로 두어야 하나요? 나는 그것이 너무 멀리 가지 않을 것이라고 약속 할 수 없다. 학습을 위한 많은 온라인 구독 옵션이 있지만 설계한 정확한 솔루션을 고려하지는 않습니다.

강사는 외부에서 오거나 프로젝트의 구성 또는 프로세스 부분에서 올 수 있지만 실제로 구현 작업을 한 사람이 아닌 전문가인 경우가 많습니다. 따라서 이 팀을 위해 자금을 제쳐놓고 (그리고 당신이 있기를 바랍니다), 당신은 여전히 이 사람들이 사람들을 교육하는 시스템이 실제로 무엇을 하도록 설계되었는지 알고 있는지 확인해야 합니다. 저는 강사가 Microsoft Project Server에 도착하는 것을 보았고, 엔터프라이즈 필드를 구성하고 포트폴리오 분석에서 비즈니스 드라이버를 설정하는 방법을 사용자에게 설명하기 시작했으며, 엔터프라이즈 필드가 이미 모두 설정되어 있고 초기 출시 시 포트폴리오 분석을 사용하지 않을 것이기 때문에 사용자가 빈 응시를 제공하도록 했습니다. 트레이너는 이 특정 배포가 해결해야 하는 문제를 알고 있나요? 그들은해야한다. 프로젝트 시작 시 학습에 대해 생각하면 성공 가능성이 가장 큽니다. 기술, 구성 및 프로세스 팀은 궁극적으로 제공될 교육을 위해 섹션을 통해 중요한 데이터를 제쳐놓을 수 있습니다. 즉, 훈련 팀을 일찍 참여시키는 것을 의미합니다.

롤아웃/수용/문화권 변경

이러한 팀을 시작하기 위해 자원을 제쳐두고 프로젝트를 통해 함께 일하고 의사 소통한 경우 새 시스템의 롤아웃은 그렇지 않은 경우보다 훨씬 원활하게 진행될 수 있지만 문화 변화에 대한 저항을 과소 평가하지는 않습니다. 핵심 전도사를 적시에 사용할 수 있게 하는 것이 중요할 수 있습니다. 또한 이 모든 팀원이 압축을 찼고 다음 프로젝트로 넘어가게 될까요? 프로젝트가 출시 될 때까지이 사람들에 싸여 시스템 지식이 많이있을 것입니다. 나는 특히 작년 초에 우리의 고객 중 하나에 감동했다. IT 부서가 대규모 금융 조직이었습니다. 프로젝트 초기에 소프트웨어를 평가하던 주요 기술 사용자에게 제기되는 문제 중 하나는 "프로젝트를 래핑하면 관리자가 될 사람"이었습니다. "내가 할게." 그가 말했다. 그는 그의 말에 충실했다. 그의 기술과 지식은 큰 성공을 거둔 몇 달 간의 배포를 통해 발전했으며, 그는 여전히 핵심 관리자로 남아 있습니다.

래핑업

팀이 더 큰 목표의 일환으로 소통하고 작업하도록 하는 방법에 대해 고려해야 할 100가지 다른 사항이 있으며, 몇 가지에 대해서만 이야기했습니다. 다음 엔터프라이즈 시스템 배포에 대해 이미 생각해 볼 수 있기를 바랍니다. "설명서는 어떻습니까?" 라고 생각할 수 있습니다. "기술 지원은 어떻습니까?"

기억해야 할 중요한 점은 엔터프라이즈 시스템 배포를 계획할 때 설치 작업뿐만 아니라 완료된 솔루션의 제공을 포함하도록 관점을 확장해야 합니다. 구멍이 올바른 크기, 오른쪽 깊이 및 직각으로 표시되는지 확인합니다.

만든 이 정보

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)를 참조하세요.