엔터프라이즈 소프트웨어 선택 시 어려움
이 문서는 "트렌치에서" 컬렉션의 일부입니다. 엔터프라이즈 시스템 구현이 성공하기 위해 적응하고 발전할 수 있어야 하는 방법을 설명합니다.
이 문서의 Word 버전을 다운로드하려면 엔터프라이즈 소프트웨어 선택 과제를 참조하세요.
더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.
엔터프라이즈 소프트웨어 선택 과제
그것은 항상 여기 주위에 발생합니다. 클라이언트는 며칠 또는 일주일 안에 응답을 완료하고 기업 시스템이 구매를 고려하도록 다시 보내는 지침과 함께 "제안 요청"(RFP)을 사무실로 보냅니다. RFP는 거의 모두 동일하게 보입니다. 일반적으로 간단한 개요, 응답을 고려하기 위해 수행해야 하는 사항에 대한 지침, 형식을 지정해야 하는 방법 및 다시 보낼 시기 등이 있습니다. 그런 다음 필요한 기능의 긴 그리드와 답변을 작성하는 추가 에세이 질문의 숫자가있다.
RFP의 과제는 엔터프라이즈 소프트웨어를 선택하는 데 이상적으로 적합하지 않으며 RFP 프로세스가 수행될 때 발생하는 것이 organization 대한 최상의 결정을 보장하지 않는다는 것입니다. RFP는 최고의 가격으로 최고의 상품을 얻을 수있는 방법으로 구매 커뮤니티에 의해 설계되었으며, 그들은 여전히 그 훌륭한 일을. 제품과 비교할 수 있는 경우 의사 결정 프로세스는 하나 또는 두 개의 추가 변수(예: 배송 날짜)만 사용하여 최상의 가격에 집중할 수 있습니다. 가능한 솔루션이 동일한 일반 범주에 있지만 전혀 비교할 수 없는 경우(엔터프라이즈 소프트웨어의 경우와 같이) 구매자가 고려해야 하는 변수의 수는 엄청나며 RFP 프로세스는 선택에 가치를 추가하지 않습니다. 대부분의 회사에서 엔터프라이즈 소프트웨어를 선택하는 방법 엔터프라이즈 소프트웨어의 공급업체 또는 솔루션 공급자에서 항상 발생하는 프로세스를 살펴보겠습니다. 회사에서 제공하는 것처럼 엔터프라이즈 프로젝트 관리 소프트웨어 또는 엔터프라이즈 작업표 소프트웨어에 대해 이야기하겠습니다. 그러나 패러다임은 거의 모든 엔터프라이즈 시스템 선택에 대해 동일합니다.
대부분의 회사에서 엔터프라이즈 소프트웨어를 선택하는 방법
먼저 엔터프라이즈 소프트웨어의 공급업체 또는 솔루션 공급자에서 항상 발생하는 프로세스를 살펴보겠습니다. 회사에서 제공하는 것처럼 엔터프라이즈 프로젝트 관리 소프트웨어 또는 엔터프라이즈 작업표 소프트웨어에 대해 이야기하겠습니다. 그러나 패러다임은 거의 모든 엔터프라이즈 시스템 선택에 대해 동일합니다.
대부분의 조직에서 엔터프라이즈 소프트웨어를 찾는 원동력은 몇 가지 문제에서 비롯됩니다. 아마도 문제는 현장 직원에 의해 표면화됩니다. 아마도 문제는 고위 경영진의 누군가에 의해 식별됩니다. 그러나 이 이니셔티브는 고위 경영진의 지원을 받아야 합니다. 전체 기업에 영향을 미칠 시스템의 풀뿌리 선택은 심지어 가장 진보적 인 조직에서 환상이다. 그래서 고위 관리자는 "우리는 이런 종류의 엔터프라이즈 시스템이 필요하다"고 결정합니다.
일반적인 엔터프라이즈 소프트웨어 선택 프로세스는 다음과 같습니다.
경영진은 새로운 엔터프라이즈 시스템이 필요하다고 말합니다.
프로젝트 관리자가 선택됨
관련된 모든 부서에서 요청 요청
모든 요청을 하나의 큰 스프레드시트로 병합
많은 공급업체에 요구 사항 표 보내기
많은 응답 받기
짧은 목록
데모 보기
협상
관리 동의 가져오기
경영진이 다른 것을 결정하게 하세요.
선택 활동을 위한 프로젝트 관리자가 자원합니다. 인터넷으로 이동하여 검색 엔진을 로드하고 "EPM 소프트웨어"(또는 원하는 엔터프라이즈 시스템)를 입력합니다. 즉시 반 만 안타가 반환됩니다. 아마도 부지런한 프로젝트 관리자는 계속 진행하기 전에 사용할 수 있는 시스템의 종류를 알아보기 위해 처음 12개 정도의 서핑을 할 수 있습니다. 분명히 아무도 아마도 마지막 하나가 organization 대한 이상적인 시스템인지 확인하기 위해 반 만 개 이상의 안타를 통해 서핑 할 시간이 없다.
프로젝트 관리자는 이제 이 새로운 엔터프라이즈 시스템 구현의 영향을 받는 사람들 사이에서 선발 위원회를 구성합니다. 위원회에 있는 사람들 중 일부는 처음에 organization 필요를 확인한 현장 직원 중에서 온 것일 수 있습니다. 다른 사람은 그렇지 않을 수 있습니다. 이 선발위원회에는 어떤 종류의 시스템을 선택할지에 대한 다양한 관심사가 있는 사람들이 섞일 수 있습니다.
불운한 프로젝트 관리자는 이제 위원회의 각 구성원에게 새로운 엔터프라이즈 시스템에 필요한 것에 대해 대표 그룹을 폴링하도록 요청합니다. 각 위원회 담당자는 어떻게 이 작업을 수행하나요? 우선, 모두가 같은 노력을 기울이는 것은 아니지만 숙제를하는 사람들을 위해 직원에게 중요한 기능 목록을 제출하도록 요청합니다. 그런 다음 그들은, 너무, 인터넷을 명중하고 일부 공급 업체 웹 사이트를 서핑. 각 사이트가 새 시스템을 만들 수 있는 요청의 종류에 대한 새로운 아이디어를 제공하므로 이러한 사이트의 브로셔에 표시되는 기능을 복사하여 붙여넣을 수 있습니다.
이제 위원회가 다시 조립되고 각 위원회 위원의 긴 스프레드시트가 다른 사람들과 하나의 거대한 스프레드시트로 병합됩니다. 요구 사항의 메가 스프레드시트는 분류되지만 문제가 있습니다. 위원회의 모든 다양한 요구 사항 중 첫 번째는 이제 광범위한 관점에서 기능이 요청됨에 따라 더욱 명백해집니다. 다른 부서뿐만 아니라 다른 국가 / 지역 또는 다른 부서에 위원회 위원이있을 수 있습니다. 거의 항상 동일한 목록의 다른 요청과 충돌하는 요청이 있습니다(예: 시스템은 매우 쉽고 많은 프롬프트가 없어야 하며 시스템은 각 사용자에 대한 많은 옵션으로 매우 유연해야 합니다).
마지막으로 공급업체에서 볼 수 있는 결합된 스프레드시트가 완료되었습니다. 수백 개의 기능 요청이 있으며 각 요청마다 공급업체가 "예", "아니요" 또는 "예"라고 말해야 합니다. 또한 이 기능이 "필수"인지, "중요-가지고 있는지" 또는 "좋은 기능"인지 여부를 말하기 위해 가중치 시스템을 연결할 수도 있습니다.
RFP는 거의 갈 준비가되어 있습니다. 일반적으로 선택의 기술 아키텍처에 대한 몇 가지 에세이 질문이 있을 것이며, 이러한 요구 사항에 대해 폴링된 사용자 수에 따라 아키텍처 요청이 동등하게 충돌할 수 있습니다(예: 시스템에는 모든 데이터가 SQL Server 데이터베이스에 중앙에 저장되어야 합니다.) 시스템은 모든 데이터를 사용자의 컴퓨터에 로컬로 저장하도록 허용해야 합니다.
사실, 그것은 지금까지 꽤 좋은 소리, 당신은 생각하지 않아? 결국 필요한 모든 기능을 제공할 수 있는 사용자를 보여 주는 여러 공급업체 응답을 다시 가져올 것입니다. 사실, 그것은 지금까지 꽤 좋은 소리, 당신은 생각하지 않아? 결국 필요한 모든 기능을 제공할 수 있는 사용자를 보여 주는 여러 공급업체 응답을 다시 가져올 것입니다.
하지만 지금까지 설명한 내용에는 실제로 근본적인 문제가 있습니다: 엔터프라이즈 시스템이 아닌 상품에 RFP 프로세스를 사용할 때 발생하지 않는 문제입니다. 엔터프라이즈 시스템은 무언가에 대한 솔루션입니다. 그러나 우리는 문제에 대해 지금까지 아무 말도하지 않았다. 이것은 기술 산업이 정상적이고 허용 가능한 것으로 받아 들여온 일반적인 발생입니다.
이러한 방식으로 엔터프라이즈 소프트웨어를 선택하는 것이 작동하지 않는 이유
구매자는 수십 년 동안이 방법을 사용하고 아무도 그것을 질문하지 않았지만 엔터프라이즈 소프트웨어 비즈니스의 사람들은 엔터프라이즈 소프트웨어를 선택하는 클래식 RFP 방법에 근본적인 문제가 있다는 것을 알고 있습니다.
우선, 기능 목록이 엄청나게 길다고 해서 비즈니스 문제를 해결하는 데 더 가깝다는 의미는 아닙니다. 사실, 당신이 해결하려고하는 특정 비즈니스 문제를 명확히하지 않은 경우, 당신은 일을 더 복잡하고 궁극적으로 악화, 더 나은 만들 가능성이 높습니다. RFP 프로세스는 상품을 구매하도록 설계되었습니다. 신발이나 감자, 설탕과 같은 동종 제품이 있는 경우 이러한 품목을 이런 식으로 구매하면 가장 낮은 비용의 입찰자와 가능한 공급업체 중에서 최고의 선택이 발생할 수 있습니다. 유사한 상품에 대한 RFP에 대한 응답은 가능한 공급 업체를 매우 쉽게 비교할 수 있도록합니다. 혼합의 각 제품에 대한 변수가 무한(엔터프라이즈 소프트웨어와 마찬가지로)인 경우 RFP에 대한 응답에는 무한 수의 변수도 있으며 프로세스는 값이 거의 없는 결과를 생성합니다.
엔터프라이즈 시스템을 선택하는 RFP 방법을 사용하는 경우 RFP는 대부분 동일하게 표시됩니다. 이는 모두 동일한 자극에 대한 응답으로 생성되기 때문입니다. 프로젝트 관리자는 '이 엔터프라이즈 시스템에 필요한 것' 목록을 요청하고 대부분의 중간 관리자가 해당 요청에 응답해야 하는 유일한 어휘는 기능 목록입니다. 따라서 RFP에 대한 응답은 모두 동일하게 표시됩니다. 시스템의 일부 또는 일부 노력으로 시스템의 일부로 사용할 수 있는 모든 기능의 검사 목록입니다.
선발 팀에서 가장 일반적인 것은 RFP에 대한 많은 응답을 받고, 수백 페이지를 통과하며, 완료되면 시작할 때보다 솔루션에 더 가깝게 느껴지지 않는다는 것입니다. 이것은 제안에 대한 공정한 요청을 만들고 연습이 장난꾸러기였다는 것을 발견하기 위해 답변을 평가하는 데 엄청난 노력을 기울인 구매자에게 매우 실망스럽습니다.
이 모든 것보다 더 나쁜 것은 경험이 풍부한 엔터프라이즈 영업 사원이 프로세스가 실망스러운 결과를 얻을 것이라는 것을 알고 있으며 RFP가 생성될 것이라는 소식을 듣는 순간부터 일하고 있다는 것입니다. RFP 응답에서 작동하지 않습니다. 이는 관련이 없습니다. 대신, 그들은 RFP가 시작된 원래의 자극을 찾고, 관리 구조에서 두 개 또는 세 개 이상의 수준을 작업하고 있습니다. 그들은 몇 가지 비즈니스 과제를 분명히 하고 구매자와 다른 중간 관리 직원이 궁극적으로 RFP를 만들고 공급 업체에 보낼 수 있도록 움직이는 바퀴를 설정한 고위 경영진을 찾습니다.
RFP 응답이 구매 프로세스 내에서 거의 명시되지 않은 비즈니스 문제에 대한 명확한 답변없이 끝나면 기업 영업 사원은 고위 경영진이 프로세스를 완전히 우회하고 고위 기업 영업 사원과의 개인적인 관계에 따라 시스템을 선택하게되어 행동으로 도약 할 준비가되어 있습니다.
이 소리가 지저분하다고 생각한다면, 당신은 틀렸습니다. 실제로 RFP 프로세스를 통해 구매하는 것보다 경영진 수준에서 개인 관계를 통해 소프트웨어를 선택하는 것이 더 나은 사례를 만들 수 있습니다.
그러나 개념 증명 또는 파일럿은 어떨까요?
따라서 엔터프라이즈 소프트웨어 구매에 적용할 때 클래식 구매 프로세스에 결함이 있다는 것을 알고 있습니다. 이 경우 엔터프라이즈 프로젝트 관리 시스템과 같은 엔터프라이즈 소프트웨어를 어떻게 선택해야 하나요? 널리 사용되는 방법은 개념 증명 또는 파일럿 단계 메서드를 사용하는 것입니다.
이 두 용어는 종종 동의어로 사용되므로 개념 증명 또는 파일럿 배포에 대해 이야기해 보겠습니다.
개념 증명. 개념 증명에서 장래 organization 엔터프라이즈 소프트웨어를 제한된 방식으로 배포하여 이러한 문제를 극복하는 솔루션의 능력에 대한 몇 가지 질문이 있는 기술적 과제를 달성할 수 있음을 증명합니다. 데이터 볼륨의 예가 될 수 있습니다. "우리는 제품이 프로젝트당 많은 작업을 처리하지 못할 수 있다고 우려하고 있습니다. 소프트웨어와 함께 제공되며, 각각 500개의 태스크가 있는 두세 개의 예제 프로젝트를 사용하고, 이러한 프로젝트를 소프트웨어에 로드할 수 있는 방법과 소프트웨어가 이 볼륨으로 기본 기능을 계속 수행할 수 있는 방법을 보여 드리고 싶습니다."
파일럿 단계. 파일럿 단계는 엔터프라이즈 소프트웨어를 설치하는 것이지만 scope 제한됩니다. 파일럿 배포는 사용자의 하위 집합에 대한 것일 수 있습니다. 예를 들어 1,000명 중 10명만이 4주 동안 소프트웨어를 완전히 사용합니다. 또는 기능의 하위 섹션 또는 데이터 볼륨의 하위 집합에 대한 것일 수 있습니다. 예를 들어 500개 프로젝트 중 10개만 로드됩니다.
개념 증명 또는 파일럿 단계는 어떻게 사용합니까? 종종 발생하는 문제는 파일럿 단계 또는 개념 증명이 적용되는 방식입니다. 잠재 organization 전화를 걸어 개념 증명 제안을 요청하고 입증해야 하는 기술 개념을 식별할 수도 있는 경우는 매우 드뭅니다. "무엇을 증명하기를 바라고 있으며, 우리가 그것을 입증했다는 것을 어떻게 측정할 수 있을까요?" 우리는 묻습니다.
가장 일반적인 것은 중간 관리의 누군가가 organization 자신의 삶을 더 쉽게 만들 수 있기를 바라는 엔터프라이즈 소프트웨어의 일부를 확인했다는 것입니다. 고위 경영진은 전혀 관여하지 않으며 중간 관리 직원은 극복하려는 비즈니스 과제를 명확히 밝히지 않았습니다. 솔루션이 단지 건물에 있다면 다음에 경영진이 복도를 돌아다닐 때 운영 중인 솔루션을 '실수로' 보고 즉시 엔터프라이즈 배포에 축복을 줄 수 있기를 바랍니다. 영화 '꿈의 필드'에서 문구를 빌리려면 "우리가 그것을 만들면, 그들은 올 것이다."
거의 성공하지 않습니다. 엔터프라이즈 소프트웨어의 문제는 배포를 성공으로 만들기 위해 고위 경영진의 참여가 필요하다는 것입니다. 이 엔터프라이즈 시스템에서 보고서 및 분석의 '클라이언트'가 될 고위 경영진입니다. 다양한 직원이 엔터프라이즈 소프트웨어를 설계, 구성 및 학습하는 데 필요한 시간을 허용하기 위해 개인적으로 투자해야 하는 고위 경영진입니다. 엔터프라이즈 시스템 배포의 일부인 비즈니스 프로세스를 수락하거나 다시 디자인하는 데 도움을 주어야 하는 고위 경영진입니다. 고위 경영진이 축복뿐만 아니라 암시적 지원과 직접적인 지원을 제공하지 않으면 개념 증명이 도움이되지 않습니다.
이는 파일럿 단계에서도 마찬가지입니다. 회사가 엔터프라이즈 소프트웨어 사용을 통해 일부 비즈니스 문제를 해결하기 위해 최고 수준에서 커밋하지 않은 경우 파일럿 단계의 도입은 생산적이지 않습니다.
이는 배포의 파일럿 단계에 자리가 없다는 것을 말하는 것이 아닙니다. 성공적인 배포에서 중요한 지점을 수행합니다. 해당 위치는 구매 결정이 완료되고 엔터프라이즈 시스템의 설계가 완료된 직후입니다. 이제 파일럿 단계를 통해 엔터프라이즈 시스템 디자인을 테스트하고 일반 배포를 위해 미세 조정할 수 있습니다.
실행 중인 소프트웨어를 확인하면 관리에서 소프트웨어를 선택할 수 있기를 바라며 파일럿 단계가 완료되면 비효율적인 파일럿이 있으며 선택 프로세스에서 더 이상 앞서 나가지 않습니다.
조직에서는 엔터프라이즈 소프트웨어를 어떻게 선택해야 하나요?
엔터프라이즈 시스템은 매일 중대형 조직에서 구매하며 RFP 방법이 가장 효과적이지 않을 수 있지만 매우 효과적인 엔터프라이즈 소프트웨어를 선택하는 몇 가지 방법이 있습니다. 다음은 고유한 효과적인 엔터프라이즈 선택 프로세스를 만들기 위한 몇 가지 팁입니다.
문제를 명확하게 설명합니다. 무엇보다도 문제를 명확하게 설명합니다. 즉, 고위 경영진이 참여해야 하며 명료하게 설명하는 문제는 비즈니스 문제이므로 비즈니스 측면에서 명확히 설명해야 합니다. 한 가지 좋은 질문은 "우리가 지금 할 수 없는 비즈니스 결정이나 큰 어려움으로만 할 수 있는 것, 이 엔터프라이즈 시스템 솔루션의 배포로 완화될 수 있는 것"입니다.
이 엔터프라이즈 시스템을 사용하여 해결하려는 일련의 비즈니스 문제가 있을 수 있습니다.
공급업체에 솔루션을 만들 수 있는 약간의 위도를 제공합니다. 비즈니스 문제 또는 문제가 명확히 설명되면 가능한 공급업체에 문의하고 프로세스를 지원한 고위 경영진에 대한 액세스가 투명해야 합니다. 관리가 처음부터 프로세스의 일부인 경우 고위 경영진과의 "비밀" 공급업체 회의는 불가능해집니다. 공급업체가 문제를 이해하고 답변할 때 약간의 위도를 부여하도록 합니다. 이러한 비즈니스 과제가 생각보다 미치는 영향을 설명하는 organization 대해 자세히 알아볼 수 있으며 잠재적 공급업체에 솔루션을 설명하려고 하지 않을 때 문제에 대한 훨씬 더 광범위한 해결 방법을 확인할 수 있습니다.
가능한 솔루션 공급자와 이야기할 때 기술 및 비즈니스 프로세스 과제 모두에 대해 이야기해야 한다는 것을 이해해야 합니다. organization 프로세스에 영향을 미치지 않은 엔터프라이즈 시스템 솔루션은 없었습니다. 솔루션 공급자가 프로세스의 영향을 받는 방법을 도울 수 없는 경우 솔루션의 일부만 보고 있습니다.
어떤 사람들을 만나러 가라. 몇 가지 가능한 솔루션 공급자로 내려가면 기존 클라이언트 중 일부와 통신하도록 요청합니다. 더 나은, 공급 업체가 기존 클라이언트 중 일부를 방문 할 수 있는지 확인합니다. 좋은 솔루션 공급자는 종종 자체 배포에서 성공을 거두었으며 잠재 고객을 만날 시간을 가질 만큼 관대한 클라이언트가 있는 경우가 많습니다.
RFP 응답을 읽거나 공급업체 판매 데모를 보면서 배운 것보다 가능한 솔루션의 숙련된 클라이언트를 통해 몇 시간 후에 자세히 알아볼 수 있습니다. 공급 업체에 가능한 클라이언트 참조 및 사이트 방문을 요청할 때 만날 수있는 이상적인 회사가 당신과 똑같이 될 것이라고 생각할 수 있습니다. 항상 그런 것은 아닙니다.
사용자와 관련이 있거나 다소 유사한 다른 산업의 회사를 만나는 것은 매우 가치 있는 경우가 많습니다. 사용자보다 크거나 작은 조직에서 많은 것을 배울 수도 있습니다. organization 사용 중인 버전이나 정확한 크기인지 또는 정확한 업계에 있는지보다는 솔루션에 대해 얼마나 많은 경험을 했는지에 더 중점을 둡니다.
기존 클라이언트를 방문할 만큼 운이 좋다면 공급업체가 아님을 기억하세요. 존중하고 정중하고 감사해야 합니다. 작은 선물, 아마도 회사 로고 홍보 자료의 가져 오는 것은 종종 잘 평가된다. organization 함께 있거나 전화에서 참조와 대화하는 동안 다음과 같은 몇 가지 가능한 질문이 있을 수 있습니다.
다른 사용자보다 이 솔루션을 선택하는 데 어떤 프로세스를 사용했나요?
이 솔루션이 비즈니스 프로세스에 어떤 영향을 미쳤나요?
배포에서 가장 어려운 측면은 무엇인가요?
지금까지 가장 가치 있는 투자 수익률은 무엇이었습니까?
여기에서 솔루션이 어떻게 진화하는지 확인하나요?
행복한 답변만 기대하지 마세요.
참조를 완전히 제공할 수 없는 공급업체는 만족하는 클라이언트가 많은 공급업체보다 다소 의심적이어야 합니다.
마지막으로, 선택한 경우 단계적으로 배포합니다. 이 열에서 단계적 및 빅뱅 모드에서 배포하는 방법에 대한 다른 문서를 찾을 수 있습니다. 이렇게 하면 엔터프라이즈 시스템 배포와 관련된 위험을 완화하고 시스템이 발전함에 따라 배포 프로세스를 미세 조정하는 데 도움이 됩니다.
엔터프라이즈 시스템 배포는 동적 프로세스입니다. 한 달 후에 영원히 도착하는 행복한 결과를 가진 일회성 결정은 아닙니다. 가장 성공적인 엔터프라이즈 배포는 관리의 최고 경영진에서 현장에서 가장 전술적으로 배포 프로세스의 일부가 될 핵심 인력을 포함하고 단계 후 단계적으로 시스템의 진화를 계속하는 선택으로 시작됩니다.
효과적인 엔터프라이즈 시스템 선택은 프로세스의 첫 번째 단계에 불과합니다.
작성자 정보
Chris Vandersluis는 캐나다에 본사를 둔 HMS Software인 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)를 참조하세요.