효과적인 지식 기반을 만들기 위한 6가지 팁

직업은 기술에 정통한 직원을 더 많이 필요로 하고 원격 근무가 증가하고 있습니다. 회사는 장기적으로 운영하기 위해 효과적인 지식 기반이 필요 합니다. 지식 기반은 제도적 지식이 "무언의 규칙"이 되는 것을 방지합니다. 새로운 직원을 교육하는 데 도움이 되며 모든 유용한 정보를 하나의 깨끗한 데이터베이스로 구성합니다.

지식 기반은 유용한 정보의 저장소입니다. 내부 위키는 일반적으로 회사 내부의 사람들이나 긴밀한 관계를 맺고 있는 다른 비즈니스를 위한 것이지만 지식 기반은 질문에 답하거나 문제 해결 팁을 제공하거나 교육 자료만 보관하도록 설계된 고객 대면 리소스를 참조할 수도 있습니다. 주제 기반 "기사"를 정리하기 쉬운 시스템으로 수집하는 위키처럼 작동합니다.

이 팁은 아이디어에서 구조, 조직, 출시 및 유지에 이르기까지 지식 기반 또는 내부 Wiki를 설정하는 전체 프로세스를 시간 경과에 따라 안내합니다.

1. 이상적인 사용자를 위한 기술 자료 사용자 지정

사람들이 사용하고 참여해야 하는 것을 만들기 전에 스스로 생각해 보십시오. 이 도구의 이상적인 사용자는 누구입니까?

이 사용자가 지식 기반을 찾는 이유는 무엇입니까? 그들은 제품을 이해하고자 하는 고객입니까? 문제를 해결하는 방법을 찾으려는 정비사 또는 IT 담당자입니까? 아니면 직원 교육을 위한 지식 기반입니까? 이 지식 기반을 누가 사용할 것인지 결정한 후에야 설계 및 구성을 진행할 수 있습니다.

지식 기반이 내부에 있고 직원에 중점을 둔 경우 기사의 언어가 더 기술적이고 기능적일 수 있습니다. 고객에게 부담을 줄 필요가 없습니다. 황동 압정을 바로 잡을 수 있습니다. 그런 다음 내부 Wiki의 초점은 온보딩, 협업 교육 및 동료 학습이 됩니다.

지식 기반이 바깥쪽을 향하고 있다면 더 세련된 인터페이스를 원할 것입니다. 고객이 제품 문제 해결을 직접 수행하는 경우 고객을 지원하려면 더 많은 이미지와 유용한 비디오가 필요합니다.

이 이상적인 사용자를 염두에 두고 나면 이를 사용하여 새로운 지식 기반의 모든 부분을 성공에 필요한 것으로 만들 수 있습니다.

2. 기술 자료를 구성할 소프트웨어 선택

지식 기반은 이상적인 용도에 맞게 복잡하거나 간단할 수 있습니다. 일련의 상호 연결된 웹 페이지이거나 탐색, 저장 및 공유하기 위한 자체 웹 사이트, 앱 또는 데이터베이스일 수 있습니다.

지식 기반은 Google 문서도구의 상호 연결된 시리즈처럼 단순한 것일 수 있지만 권장하지는 않습니다. 고객용 위키에서는 이와 같은 것이 전혀 작동하지 않을 것이 분명합니다. 하지만 뭉쳐진 Google 드라이브 문서 웹으로 만든 내부 위키조차도 똑딱거리는 시계를 가지고 있습니다. URL이 일관되지 않고 콘텐츠를 포함하기 어렵고 검색 기능이 작동해야 합니다(잠시 그 중요성에 대해 알게 될 것입니다).

이상적으로는 Wiki와 지식 기반을 만들기 위한 앱인 전용 소프트웨어가 필요합니다.

선택한 소프트웨어의 가장 중요한 기능 중 하나는 견고한 검색 기능일 것입니다. 사실, 지식 기반의 구조는 사람들에게 기사를 찾을 수 있는 위치에 대한 단서를 제공하지만 대부분의 사람들은 검색창으로 바로 이동합니다.

검색을 시작할 수 있는 몇 가지 장소는 다음과 같습니다.

테트라. Tettra를 사용하면 깔끔한 모양과 직관적인 구성으로 복잡한 지식 기반을 만들 수 있습니다. Tettra는 내부 위키를 위한 훌륭한 솔루션입니다. 직원 교육, 복잡하거나 복잡한 프로세스의 개요, HR 및 기타 직원 문서에 대한 링크 제공을 원하신다면 Tettra가 바로 당신일 것입니다.

도움주스. Tettra만큼 강력한 기능은 아니지만 Helpjuice는 내부 또는 외부 Wiki 및 지식 기반을 만드는 데 여전히 유용합니다. 고객과 공유할 지식 기반을 만들려는 경우 반드시 확인해 볼 가치가 있습니다.

3. 지식 기반 구조화

지식 기반에 대한 기사 작성에 뛰어들기 전에 조직 전략을 만들어야 합니다. 이것은 사용자가 원하는 기사를 찾는 데 도움이 될 뿐만 아니라 귀하(및 지식 기반의 다른 기여자)가 아직 작성해야 하는 기사를 아는 데 도움이 됩니다. 기본적으로 청사진이 없으면 집에 몇 개의 방을 지을지 모릅니다.

베이스는 어떻게 구성되어 있나요? 기본적으로 지식 기반에는 몇 개의 카테고리가 있습니까? 더 적은 것이 더 많지만 성장을 허용합니다. 카테고리는 나중에 추가할 수 있지만 기본적으로 누군가에게 이전 기사를 뒤져 관련 카테고리를 수동으로 추가해야 하는 작업입니다. 그러니 처음부터 잘 생각해 보세요.

대부분 온보딩 지식 기반에는 온보딩, HR, 교육 및 정책과 같은 범주가 있을 수 있습니다. 모든 교육, 문서, 절차 및 정책에 대한 포괄적인 내부 위키에는 더 많은 범주가 있을 수 있습니다.

사전에 지도를 작성하고, 중복을 제거하고, 일부 동료가 목록을 분해하여 생각하지 못한 더 나은 범주나 범주를 찾도록 하십시오. 모든 부서의 구성원을 프로세스에 참여시키십시오. 무언가를 잊어버리면 나중에 후회할 수 있습니다.

개별 게시물은 어떻게 구성되나요? 여기에서 기사 형식을 결정합니다. 헤더를 사용하여 섹션을 구분합니까? 링크가 각주처럼 본문의 본문에 포함되어 있습니까 아니면 끝에 포함되어 있습니까? 내부적으로 다른 기사에 링크하거나 관련 콘텐츠를 포함합니까? 모든 기사에 이미지가 필요합니까?

형식을 지정하는 것은 기사가 50명의 다른 사람들에 의해 조립된 것처럼 보이지 않도록 하기 때문에 중요합니다. 서식을 지정하면 명확성이 추가되고 중요한 정보가 건너뛰지 않습니다. 또한 사용자가 정보를 더 빨리 찾을 수 있습니다.

슈퍼마켓이 어떻게 비슷한 방식으로 배열되는 경향이 있는지 생각해 보십시오. 한쪽은 델리, 다른 쪽은 농산물, 냉동식품은 모두 함께. 이는 쇼핑객이 어디에 있든 방향을 찾는 데 도움이 됩니다. 일관된 위키 형식은 사용자에게 동일하게 적용됩니다.

4. 한 번에 전체를 쓰려고 하지 마십시오.

회사 또는 분야의 복잡성에 따라 지식 기반의 단어 수가 교과서 영역 또는 그 이상으로 확장될 수 있습니다. 이러한 범위는 종종 지식 기반이 완료되지 않도록(또는 아예 시작하지 못하게 하는) 원인이 됩니다.

3-4개의 기사를 끝내고 견고한 시작을 할 수 있을 때 Iliad를 쓰기로 약속하지 마십시오. 옛날 속담과 같습니다. “코끼리는 어떻게 먹나요? 한 번에 한 입.” 저녁 식사로 코끼리 전체를 먹으려 하지 마십시오.

가장 일반적인 불만 사항을 생각해 보십시오. 먼저 잠재적인 독자가 매일 접하는 가장 일반적인 문제(또는 가장 일반적인 고충점)부터 시작합니다. 신입 사원, 고객 또는 동료가 가장 많이 묻는 질문은 무엇입니까? 그것은 당신의 첫 번째 기사입니다.

간단하게 시작하세요. KISS 원칙(Keep it Simple, Stupid)에 익숙하다면 이것이 당신의 길잡이가 될 것입니다. 모든 기사는 필요한 만큼만 작성해야 합니다. 기사는 몇 개의 문장으로 시작하거나 관련 소스 자료에 대한 링크로 시작할 수 있습니다. 기사를 완성하고 Wiki 구조에 맞추고 기사를 찾는 데 필요한 모든 태그와 카테고리가 있는지 확인하십시오. 존재하는 기사는 나중에 확장할 수 있습니다. 가상의 기사는 확장할 수 없습니다.

일정을 만들고 그것을 지키십시오. 당신이 변덕스럽게 기사 쓰기를 남겨두면, 그것은 결코 끝나지 않을 것입니다. 대신 지식 기반에 대한 기사 하나가 매일, 매주, 또는 일주일에 두 번(지식 기반의 예상 규모와 작업량에 맞게 작성되고 업로드되도록 일정을 잡습니다.) 지식 기반 작성을 담당하는 모든 사람에게 이 일정을 알리십시오. 그것에 붙어!

5. 기술 자료의 이미지 및 비디오 사용

모든 텍스트와 이미지는 Jack을 둔감하게 만듭니다. 여기에서 "Jack"은 지식 기반입니다. 텍스트 벽은 누구의 친구도 아니며 때로는 이미지나 비디오가 정보를 더 빨리 전달할 수 있습니다. 게다가, 어떤 사람들은 무언가를 철자법으로 설명하지 않고 보는 것이 자연스럽게 더 빨리 배웁니다.

그래픽, 차트 및 다이어그램을 추가하면 경험이 크게 향상될 사용자 기반의 시각적 학습자 또는 설명이 아닌 복잡한 프로세스를 보여줌으로써 누구나 혜택을 얻을 수 있는 방법을 고려 하십시오. 복사기에서 문서를 스캔하여 이메일로 보내는 것과 같은 간단한 기사라도 관련 버튼의 위치를 ​​보여주는 약간의 시각적 지침이 도움이 될 수 있습니다.

비디오는 기사에 개인적인 느낌을 더하거나 진정으로 복잡한 주제에 대해 더 깊이 들어갈 수 있습니다. 또한 건조한 주제에 대해 사용자의 주의를 끌 수 있는 좋은 방법입니다. 신입 직원을 위한 교육 비디오, 고객을 위한 특집 비디오, 유용한 PowerPoint 자료를 모두 기사에 넣어 이해를 돕고 약간의 감각을 더할 수 있습니다.

6. 제품에 맞는 지원 수준 찾기

고객 대면 지식 기반을 구축할 때 고수해야 하는 한 가지 규칙이 있습니다. 다행히도 간단합니다. 지식 기반의 복잡성이 제품의 복잡성과 일치해야 합니다. 의류, 음료 또는 망치와 같은 제품에 대한 지식 문서를 자세히 살펴볼 이유가 없습니다. Colgate에는 웹 사이트가 있을 수 있지만 때때로 치약은 치약일 뿐입니다.

지원 포럼을 통합해 보십시오 . 고객을 위한 지원 포럼에 링크된 지식 기반은 모든 기반을 다루는 데 도움이 될 수 있습니다. 지식 기반이 실패하면 고객은 다른 사용자나 귀하의 지원 직원에게서 솔루션을 찾을 수 있습니다. 이 점도 고려하십시오. 포럼 게시물이 매우 유명해지면 지식 기반 어딘가에 구멍이 있다는 의미일 수 있습니다. 이러한 위험 신호는 사용자 콘텐츠를 소싱하여 지식 기반의 허점을 패치하는 데 도움이 됩니다.

기술 제품에는 헬프 데스크가 필요할 수 있습니다 . FAQ, 다이어그램 및 지원 포럼은 지금까지의 정보만 얻을 수 있습니다. 때때로 고객에게 이상한 문제가 발생하거나 문제 해결 문서를 구문 분석하는 데 문제가 있습니다. 일종의 헬프 데스크 연락처를 지식 기반에 포함시키는 것이 좋습니다.

소규모 기업이나 덜 복잡한 제품의 경우 지식 기반에 연락처 페이지를 추가하십시오 . 이메일이나 전화번호와 같은 간단한 정보라도 귀하의 제품에 완전히 당황하거나 단순히 지식 기반을 탐색하는 고객에게 도움이 될 수 있습니다.

필요에 맞는 기술 자료 제공

지식 기반을 만드는 것이 큰 고통이 될 필요는 없습니다. 미리 약간의 전략을 세우면 장기적으로 불필요하거나 중복되는 작업을 많이 줄일 수 있습니다.

• 서식을 계획합니다.
• 위키 구조를 구성하십시오.
• 소프트웨어를 선택하십시오.
• 이상적인 사용자를 결정하십시오.
• 일정을 만듭니다.
• 시각적 감각을 추가하십시오.
• 사용자 지원을 예상합니다.

거기에서 지식 기반을 만들고 시작하는 것은 견고한 일정과 계획을 고수하는 문제일 뿐입니다.