Всем привет. Меня зовут Вячеслав Зыкин, я бизнес-аналитик в группе компаний «Государственные информационные технологии». В айти уже больше 30 лет и могу сказать, что при внедрении любой информационной системы, будь то бухгалтерская программа или система управления задачами, люди допускают одни и те же ошибки.
В статье попробую перевернуть хотя бы некоторые грабли зубьями вниз на основании опыта, наработанного нашей компанией.
Казалось бы, зачем этот материал на Клерке? Вопрос законный. С точки зрения собственника, финансового директора или главного бухгалтера расход средств на то, что не работает — это убыток. «Похоронить» деньги на сервис, его внедрение, мотивацию персонала и оплату напрасных усилий по внедрению — это не то, чтобы неэффективно. Это неразумно и, наверное, глупо.
Классификация ошибок
Я бы разделил все ошибки на технические, методические и мотивационные. Причём последние в списке, пожалуй, будут первыми по значимости. Потому что остальные сравнительно легко исправить, имея достаточно времени и денег. А вот сменить негативный опыт, который сотрудники могут приобрести в ходе неправильного внедрения, на позитивный — задача нетривиальная и часто нерешаемая без замены руководителя проекта. Или сотрудников.
Итак, мотивационные ошибки.
Внедрение в приказном порядке
Чтобы гарантировано провалить внедрение базы знаний в организации, достаточно издать приказ из буквально трёх пунктов со следующим общим смыслом:
все обязаны немедленно приступить к наполнению и использованию информационной системы;
те, кто проигнорирует приказ, будут строго наказаны;
показатели по наполнению и использованию информационной системы будут влиять на зарплату сотрудников — те, кто не выполнит план по ИС, получат меньше премии, зависящей от KPI.
Даже если база знаний будет на прекрасной, технически безупречной платформе, даже если всё будет продумано методически до последней мелочи — коллектив обязательно будет противодействовать. Пять стадий принятия ещё никто не отменил. Если отрицание проходит быстро по причине его полной неконструктивности, то гнев, торг и последующая депрессия могут практически парализовать не только внедрение базы знаний, но и работу компании вообще.
Пять стадий принятия с точки зрения Миджорни
Чтобы так не было, нужно сначала взрастить идею повышения производительности и, соответственно, материального вознаграждения, почестей и прочих плюшек по пирамиде Маслоу с помощью умелой пропаганды. И только потом плавно вовлекать сотрудников в создание и наполнение базы знаний.
Возьмём службу поддержки. Как аргумент для неё можно привести то, что опытных сотрудников меньше будут отвлекать новички, что саппорт сможет гораздо проще выполнять SLA, что количество эскалаций на более высокий уровень поддержки сильно снизится, что клиенты будут меньше доставать вопросами, если дать им сайт, на котором есть открытая база знаний.
То есть, поставленные KPI можно будет выполнять с гораздо меньшим напряжением. Вот тогда гуру и аксакалы расчехлят клавиатуры, сами разработают структуру базы знаний, сами придумают процедуры верификации и актуализации — главное мягко направлять их умелым руководством. Высший пилотаж — это когда внедряющий менеджер почти не говорит на совещаниях по выработке решений относительно БЗ, а всё идёт так, как он уже придумал. А может быть, даже лучше — если те самые гуру и аксакалы действительно профи.
В качестве примера можно привести известные на весь рунет проекты, созданные энтузиастами. Это l2db (л2дб) — база данных, она же база знаний по игре Lineage 2. Или база знаний рр4 — русская рыбалка 4 в ВК.
Наказания при внедрении базы знаний
Лучший способ похоронить внедрение информационной системы — с самого начала установить наказание для тех, кто не будет ей пользоваться, либо будет вести свою работу параллельно ещё в чём-то. Ответственность за несоблюдение каких-либо стандартов компании может наступать только после того, как эти стандарты обкатаны и утверждены. Иначе может возникнуть казус — сотрудник не может пользоваться информационной системой по независящим от него причинам, а его за это наказывают.
Последствия такого внедрения базы знаний могут быть самыми плачевными — например, ключевые сотрудники могут усомниться в адекватности руководства, встать и уйти. Рынок труда испытывает острейший за последние лет 50 кадровый голод, так что работнику на этом рынке продать себя гораздо проще, чем работодателю – купить.
Что же в противовес наказаниям? Разумеется, поощрения. Корпоративные плюшки в виде баллов, рейтинга, признания для авторов. Или просто деньги — того, кто возьмёт на себя роль паровоза, стоит отмечать и выделять среди прочих сотрудников.
На этом тему мотивационных ошибок можно считать в основном закрытой. Почему в основном? Потому что остальные ошибки вряд ли будут иметь настолько негативные последствия.
Переходим к ошибкам методическим.
Не единая база знаний, а множество локальных
Казалось бы, это вопрос технический — но нет, это грубейший методический просчёт, который может допустить команда. Такое может возникать при стихийном внедрении баз знаний — одно подразделение договорилось между собой и начало вести свою БЗ в Google Docs, второе — в Notion, третье — в WEEEK или TEAMLY.
В результате в компании будет не информационная система, покрывающая все потребности в знаниях. И даже не лоскутное одеяло, а несколько никак не связанных между собой клочков. Такие локальные БЗ смогут решать только локальные задачи. Со временем встанет вопрос объединения знаний на единой платформе, и переделывать процессы, переучивать сотрудников всегда значительно затратнее, чем делать то же самое с нуля — меньше сопротивление, не жаль всего, что было нажито непосильным трудом.
"База знаний" (на самом деле нет) в Google Docs
Неправильная постановка целей и критериев их достижения
Создание базы знаний или другой информационной системы просто для того, чтобы она была — занятие странное. Сама по себе БЗ никакой ценности не несёт, если не определены цели, которых компания стремится достигнуть с ее помощью.
На примере: собрать все инструкции в одно место — цель хорошая, но никакая с точки зрения бизнеса. Собрали — и что дальше?
Пример хорошей, правильной цели: ускорить онбординг и адаптацию сотрудников службы поддержки с 6 месяцев до 2. А для этого:
создать базу знаний с должностными инструкциями, действиями в типовых ситуациях, видеоинструкциями по решению самых распространённых клиентских задач;
на основании всех этих материалов сверстать учебный курс с контролем усвоения знаний;
дополнить БЗ общей информацией о корпоративной культуре, истории компании для быстрого погружения в контекст.
Вот это уже хороший фундамент создания базы знаний для сотрудников.
Чтобы правильно поставить цели, можно воспользоваться любой методикой, принятой в компании. А если такой нет, надо её принять и внедрить. Это может быть SMART, PACT, CLEAR, DUMB — что угодно, что приводит к конкретному результату, конкретной пользе для компании за конкретное время, а не оперирует абстрактными понятиями.
В примере с онбордингом есть и описание главного критерия достижения цели — время ввода сотрудника. Достигли показателя в 2 месяца — считаем задачу выполненной. Если же реализовали всё намеченное в рамках задачи, но не достигли этого результата, значит либо неправильно реализовали, либо допустили ошибку при планировании — так тоже бывает. Важно признаться в этом самим себе, скорректировать процессы, если необходимо, и идти дальше.
Отсутствие обучения
Даже самая продвинутая база знаний бесполезна, если люди не умеют ей пользоваться. Чтобы сотрудники писали и читали статьи, смотрели видеоуроки, они должны это уметь. Поэтому база знаний для сотрудников — это:
вводный тренинг для всех сотрудников;
курс обучения работе с инструментарием базы знаний, реализованный на самой базе знаний или на той же платформе;
инструкции в форме скринкастов, в крайнем случае — текста со скриншотами;
FAQ для сотрудников по работе с платформой БЗ.
Здесь хорошо работает создание курсов с помощью переиспользования статей из БЗ. Такой возможностью обладают, например, TEAMLY, Minerva Knowledge, Platrum, WEEEK и многие другие отечественные системы управления знаниями.
Неправильная структура информации
Одна из главных ошибок — это отсутствие четкой структуры в базе знаний. Когда информация разбросана хаотично, а не сведена в логичную библиотеку, сотрудникам сложно найти нужные данные. Чтобы этого избежать:
Разработайте логичную иерархию разделов и категорий.
Используйте теги для удобной навигации.
Создайте карту базы знаний, чтобы пользователи могли легко ориентироваться.
Структура статей должна идти от задач, решаемых с помощью базы знаний и потребностей её основных пользователей. Чем логичнее и удобнее сделана структура, тем проще пользоваться продуктом, тем скорее будут достигнуты цели.
Разумеется, если платформа для управления знаниями позволяет менять место статей или папок в иерархии — это большой плюс. Но мы забежали вперёд, в технические ошибки. Так вот, выбор системы, которая не позволяет просто менять структуру базы знаний — это большая ошибка.
База знаний нормального человека
Неактуальный, устаревший контент
База знаний — живой инструмент. Он должен меняться вместе с той реальностью, которую он описывает. Чтобы контент оставался полезным:
Разработайте процедуру ревизии знаний.
Проводите её регулярно.
Назначьте ответственного или ответственных за актуализацию статей в разделах.
Удаляйте устаревшую информацию, добавляйте новую.
Отсутствие визуальных элементов
Сухой текст сложно воспринимать. Чтобы сделать базу знаний более наглядной:
Добавляйте схемы, диаграммы, инфографику.
Используйте скриншоты и видеоуроки для пошаговых инструкций.
Вставляйте фото и изображения, где это уместно.
Есть золотое правило хорошей инструкции: если можешь показать — покажи. Текст — не обязательно главный носитель информации в хорошей и полезной базе знаний.
Игнорирование обратной связи
Важно прислушиваться к мнению пользователей базы знаний. Чтобы улучшить ее работу:
Проводите опросы среди сотрудников.
Анализируйте статистику использования разделов.
Дайте возможность оставлять комментарии к статьям.
Пример решения: TEAMLY, Platrum, Minerva и другие сервисы предлагают мощные аналитические инструменты, которые позволяют отслеживать, какие статьи просматриваются чаще всего, какие поисковые запросы не дают результатов, и какие разделы требуют доработки на основе пользовательского поведения.
Это были основные методические ошибки. Перейдём к техническим.
Выбор платформы управления знаниями «от балды»
Если ориентироваться только на красивый интерфейс и тарифы, особенно бесплатные, можно очень крупно попасть на деньги на повторном внедрении базы знаний — но уже на подходящей платформе.
Чтобы не тратить время и деньги на одно и то же, лучше придерживаться классического подхода к любой автоматизации:
собрать требования к системе от всех заинтересованных в ней лиц;
проанализировать эти требования, снять конфликты между взаимоисключающими и выкинуть те, без которых можно жить и заинтересованное лицо с этим согласно;
выписать технические ограничения, связанные с размещением системы в облаке или на серверах компании, прикинуть возможности администрирования для того или другого способа хостинга;
выдвинуть требования по безопасности информации и модели доступа к ней; если у вас есть отделы, то логично искать ролевую модель, которая предполагает наличие подразделений, а не просто «читатель», «редактор», «администратор».
найти максимум вариантов, свести их в таблицу и отметить плюсами соответствие требованиям; где больше плюсов — та платформа и победила.
О выборе платформы по управлению знаниями я писал в статье. Но при выборе стоит учесть и то, что написано ниже — не торопитесь ставить галочку напротив симпатичного вам сервиса.
Ошибки при выдаче доступа
Если база знаний недоступна части сотрудников, это снижает ее эффективность. Убедитесь, что:
У всех есть права доступа к нужным разделам.
Сотрудники могут пользоваться базой с любых устройств.
Интерфейс адаптирован под мобильные платформы.
Безопасность — это хорошо. Но не стоит ей злоупотреблять. Лучше вовсе не хранить в базе знаний секретную информацию, чем изобретать способы её защиты.
Отсутствие интеграции с другими инструментами
База знаний должна быть частью единой экосистемы. Хорошо, когда остальные сервисы компании имеют возможность интеграции по API — тогда и платформу по управлению знаниями стоит выбирать с такой возможностью.
На первый взгляд, напрашиваются следующие интеграции:
с CRM-системой;
с корпоративным порталом;
с системой управления проектами, если управление не реализовано на самой платформе.
Сложный интерфейс
Если пользоваться базой знаний неудобно, сотрудники не будут этого делать. И это тоже вопрос выбора подходящей платформы.
Позаботьтесь о том, чтобы:
Пример решения: Teamly предлагает интуитивно понятный интерфейс с возможностью создания визуальных руководств и деревьев решений, которые превращают внутренние стандартные операционные процедуры в понятные рабочие процессы. То же умеют делать и другие системы — Platrum, Minerva, WEEK и т.д.
Игнорирование мобильных устройств
Ещё один критерий для выбора БЗ. В современном мире важно иметь доступ к информации в любом месте. Убедитесь, что ваша база знаний имеет мобильную версию или приложение.
Отсутствие аналитики
Это тоже показатель, который нужно учесть при выборе системы управления знаниями. Чтобы постоянно улучшать базу знаний, нужно отслеживать ее использование.
Блок аналитики должен позволять:
Сбор статистики по просмотрам и поисковым запросам.
Анализ времени, проведенного на страницах.
Отчеты по активности пользователей.
Создание эффективной базы знаний — это непрерывный процесс. Избегая этих распространенных ошибок, вы сможете построить инструмент, который действительно поможет вашей команде работать продуктивнее и эффективнее обмениваться ценными знаниями.
Must have для платформы управления знаниями
Многих ошибок можно избежать ещё на этапе выбора адекватной платформы для управления знаниями и совместной работы. Вот что я рекомендую учесть при сортировке списка кандидатов на роль корпоративной базы знаний.
Аналитика и отчетность
Продвинутая аналитика для отслеживания поведения пользователей и эффективности контента.
Автоматизированные отчеты для определения эффективности базы знаний.
Интерактивные дашборды, выделяющие ключевые обновления и контент, требующий пересмотра.
Инструменты создания и редактирования контента
Интуитивный визуальный редактор статей, лучше блочный.
Шаблоны для создания структурированной документации.
Интерактивные руководства для создания пошаговых инструкций.
Искусственный интеллект
«Умный поиск» для генерации полноценных ответов, а не набора ссылок, быстрого нахождения релевантного контента в БЗ.
Генеративный ИИ для создания нового контента на основе существующих знаний, но не только.
Инструменты совместной работы
Возможности удаленного и совместного редактирования в реальном времени.
Поддержка комментариев к текстам статьи.
Интегрированные системы рабочих процессов для проверки и утверждения контента.
Отслеживание вклада сотрудников в создание знаний.
Управление версиями и архивирование
В начале славных дел
Ничего не могу с собой поделать, люблю поумничать. Например, заголовок заключительного раздела этой статьи — название фильма Сергея Герасимова о Петре I. Царь-реформатор вспомнился не только в связи с революционными изменениями российской действительности. Его стиль руководства был слишком жесток даже для того времени. А сегодня подобные методы не сработают ни в каком случае, даже в армии.
Внедрение любого нового инструмента должно происходить плавно и поэтапно — и это не говорит о том, что медленно. Руководителю важно проявлять лидерство, но, в то же время, вовлекать в процесс всех, начиная с профильных директоров и заканчивая новичками в компании. Тогда успех гарантирован.
Кстати, мы таки выбрали TEAMLY и начинаем её внедрение. Если интересно, как это происходит, stay tuned )
