시장 조사를 통해 업체의 목록을 확보했다면 본격적으로 상품을 상세히 비교하고 평가해야 한다. 시장 조사 단계가 최소한의 기준에 맞지 않는 후보를 빠르게 걸러내는 작업이었다면, 상품 평가 및 선정 단계에의 미션은 모든 요구사항을 적용하여 각각의 상품을 상세히 파악해보고 그중 우리 회사의 기능 및 기술요건을 가장 잘 충족할 수 있는 업체를 선별해내는 것이다. 상품 평가 및 선정의 세부 절차는 회사의 규모나 리소스 상황에 따라 달라질 수 있다. 이번 챕터에서는 그중에서도 가장 필수적인 세 가지 활동, 즉 RFI(Request for Information), 제품 시연 및 체험, RFP(Request for Proposal)을 중심으로 살펴보고자 한다. 각 활동 별로 상품 비교와 평가를 하되 조금씩 다른 시각을 적용하여 업체를 걸러내고 후보를 좁혀간다는 것이 특징이다.
1. RFI (Request for Information)
RFI란 Request for Information의 줄임말로 상품의 상세 정보를 파악하기 위해 업체에게 보내는 질의서이다. RFI는 서면으로 진행되므로 개별 업체의 영업사원과 직접 교류할 때와 비교해서 짧은 시간 내에 여러 업체의 정보를 객관적으로 파악할 수 있다는 장점이 있다.
RFI를 작성하려면 기존에 작성한 시스템 요구사항이 필요한데, 요구사항의 카테고리와 하위 항목을 그대로 옮겨오되 하위 항목의 내용을 질문의 형태로 변경한다고 생각하면 쉽다. RFI의 내용은 시스템 요구사항과 마찬가지로 제품 기능에 대한 질문이 주를 이루지만 시스템 기술 요건에 대한 질문을 함께 작성하기도 한다. 시스템 기술요건에 대한 질문을 작성할 때에는 일반적인 기술 스펙(Specification) 뿐 아니라 우리 회사만이 가지고 있는 특수한 기술요건까지 담길 수 있도록 상세히 작성하는 것이 필요하다.
RFI를 작성할 때 가장 주의할 사항은 너무 구체적이지 않은, 열린 질문을 해야 한다는 것이다. RFI를 쓸 때 빈번하게 발생하는 실수는 HRD 담당자가 특정 시스템의 기능을 너무 세세하게 기술하면서 '있다/없다'의 답변을 요구하는 닫힌 질문을 던지는 경우이다. 이런 형태의 질문을 작성하는데 들인 노력에 비해 업체로부터 적은 양의 정보밖에 얻을 수가 없기 때문에 해당 시스템의 이모저모에 대해 자세히 소개를 받기 위한 목적에도 맞지 않는다. 반면 열린 질문을 사용하면 업체가 자사 제품의 특성을 풍부하게 설명할 수 있는 기회를 줄 수 있어 유리하다. 예를 들어 'SCORM 표준을 지원합니까?'라는 질문보다는 '귀사의 시스템은 어떤 이러닝 표준(ex. SCORM, AICC, TinCan)을 지원합니까? 이를 완벽히 지원하는지 아니면 일부 제약사항이 존재하는지 기술해주세요'라는 질문이 더 객관적이고 자세한 답변을 받을 수 있다.
RFI 작성 시 주의사항
이렇게 작성된 질의서(RFP)를 후보 업체에게 보내 답변을 요청하게 되고, 업체가 보내온 문서를 바탕으로 기능 비교표를 작성한다 (하기 표 참고). 업체 별 평가를 위해서 각 항목 별로 점수를 O(충족), △(일부 충족), X(미충족)으로 표기하거나 5점 척도를 따로 만들어 사용하기도 한다.
평가 비교표 예시
기능 비교표를 작성할 때에는 HRD 담당자뿐 아니라 다양한 시각을 가진 사람들이 참여하여 제품을 검토하고 평가하는 것이 객관성 확보를 위해서 중요하다. 동일한 요건을 사용하여 이렇게 표를 작성해보면 기능 혹은 기술 측면에서 약한 업체를 가시적으로 확인할 수 있기 때문에 업체 후보를 3-5개 정도로 압축할 수 있을 것이다.
2. 제품 시연 및 체험
제품 시연 및 체험 활동은 말 그대로 직접 시스템을 보고 테스트해보는 단계이다. RFI 활동과는 달리 후보 업체의 영업사원을 직접 컨택하여 상품 하나하나를 더욱 깊이 있게 파악하고 회사의 요구사항에 대해서도 심도 있는 대화를 나누게 되며, 직접 시스템에 접속하여 화면과 기능이 구동되는 모습도 상세히 살펴보게 된다. 이 과정의 목표는 회사의 구체적인 니즈, 회사에 특화된 프로세스 등의 정보를 영업직원에게 최대한 노출하여 해당 업체의 시스템이 원하는 방식으로 작동되는지 여부를 직접적으로 확인하는 것이다. 이때에 활용되는 두 개의 도구는 유즈 케이스(Use Case)와 데모 사이트(Trial)이다.
유즈 케이스(Use Case)는 일반적으로 사용자나 관리자가 수행할 수 있는 시스템 활용 시나리오를 의미한다. 각 업체들이 우리 회사의 요구사항을 충족시킬 수 있는지를 검증하는데 필요한 증거를 확보하는 중요한 단계라고 할 수 있다. 이 단계는 고객인 우리가 시나리오를 작성해서 업체에게 전달해주면 해당 업체가 그에 맞게 시스템이 구동되는 모습을 시연(Demonstration) 하는 방식으로 진행된다. 유즈 케이스는 어느 회사나 반드시 사용하는 단순하고 일반적인 것도 있겠지만, 우리 업계에 국한된, 혹은 우리 회사만의 특수한 프로세스를 반영한 유즈 케이스도 존재할 것이다. 동일한 시나리오를 기준으로 여러 업체들을 비교해보면 확연한 차이를 느낄 수 있다.
유즈 케이스 예시
다양한 이해관계자의 의견을 들어보기 위해 유즈 케이스 시연을 위한 워크샵을 여는 경우도 있다. 교육 시스템을 사용할 다양한 사용자 그룹을 시연에 초대한다면 다양한 시각에 입각한 질문들을 통해 시스템 기능을 다각적으로 검토하는데 도움이 된다. 시스템 기능과 관련된 것이라면 HRD 담당자 외에 부서 리더, 콘텐츠 제작팀, 사내 강사, 법인 교육 담당자 등이 참여할 수 있을 것이고, 기술 요건에 관련된 워크샵 이라면 사내 IT팀이 참여하여 질의응답 시간을 가질 수 있다.
유즈 케이스(Use case)와 함께 검토하게 되는 것은 데모 사이트(Trial)이다. 이 과정에서는 실제 시스템을 써보면서 제품의 기능과 사용성을 실제로 평가할 수 있다. 영업사원에게 데모 사이트를 요청하면 클라우드 상에 존재하는 데모 사이트의 아이디와 비밀번호를 제공해 줄 것이다. 데모 워크샵과 마찬가지로 여러 이해관계자들이 모여서 각자 원하는 방식대로 시스템을 사용해 본 후 경험과 의견을 나누는 자리를 마련한다면 서면으로는 알 수 없었던 기능상의 결점이나 보완이 필요한 부분을 파악할 수 있을 것이다.
유즈 케이스와 데모 사이트 확인을 하는 과정에서 업체와의 질의응답은 계속된다. 시스템과 관련된 직접 경험과 다양한 시각이 더욱 깊이 있는 질문들로 이어지게 되기 때문이다. 이러한 과정을 통해서 업체별 장단점을 속속들이 파악할 수 있게 되고, 그 결과 최종 2-3개 정도의 업체로 후보가 압축될 것이다.