Эффективное внедрение Базы знаний — это поиск баланса между желаемыми функциями и бюджетом. Чтобы найти его и не потратить лишнего, нужен системный подход.
В этой статье мы разберем ключевые факторы, влияющие на стоимость:
Такой анализ поможет принимать взвешенные решения на каждом этапе, снижать риски и внедрить систему, которая будет точнее соответствовать вашим потребностям.
В этой статье мы разберем ключевые факторы, влияющие на стоимость:
- как задача определяет выбор между «коробочным» и кастомизированным решением;
- почему разные пользователи требуют разного интерфейса;
- как интеграции могут сэкономить или потопить бюджет;
- и когда без внешней методологии не обойтись.
Такой анализ поможет принимать взвешенные решения на каждом этапе, снижать риски и внедрить систему, которая будет точнее соответствовать вашим потребностям.
Особенности задачи
Перед вами может стоять задача по внедрению небольшого проекта, для которого подойдет коробочное, относительно недорогое решение. Например, цель — организовать хранение проектной документации, при этом сама по себе система и регламенты по работе с ней (порядок создания, актуализации, обмена) уже есть. Все, что нужно — это обеспечить удобное пространство для обмена данными и совместной работы. Или вам требуется систематизировать информацию по продуктам, для чего достаточно использовать списки с простой группировкой, без сложной иерархии и связей между продуктами.
Для подобных задач подходят решения, не требующие сложной кастомизации: можно взять готовой продукт на рынке, быстро развернуть его и начать работу, не тратя много сил, времени и денег на внедрение.
Другой пример — та же проектная документация, но в крупной корпорации, которая занимается капитальным строительством. Там сложная структура: проекты в проектах, субподрядчики, дочерние компании. Документации много и нужно вникать, как выстроена логика работы с информацией в каждой компании/подразделении в рамках корпорации, чтобы учесть все особенности; разработать и внедрить правила и регламенты. В таких случаях возможностей коробочного решения, скорее всего, не хватит и важно выбрать более функциональное, которое даст вам простор для изменений и при этом не потребует постоянных платных доработок.
Могут возникнуть и другие особенности. Например, вам нужна система для контактного центра, где важно максимально быстро находить релевантную информацию. Тогда одним из ключевых требований будет возможность легко настраивать такие «поисковые» сценарии работы и делать это с учетом индивидуальных потребностей скилл-групп (команд операторов со специализацией на различных вопросах).
Учет особенностей, уровня сложности задачи критичен и перспектив развития, так как помогает выбрать решение, которое будет достаточно полно покрывать все требуемые сценарии, обеспечивать необходимую гибкость и масштабируемость в будущем, или, напротив, не будет для вас чрезмерным и неоправданно дорогим.
Для подобных задач подходят решения, не требующие сложной кастомизации: можно взять готовой продукт на рынке, быстро развернуть его и начать работу, не тратя много сил, времени и денег на внедрение.
Другой пример — та же проектная документация, но в крупной корпорации, которая занимается капитальным строительством. Там сложная структура: проекты в проектах, субподрядчики, дочерние компании. Документации много и нужно вникать, как выстроена логика работы с информацией в каждой компании/подразделении в рамках корпорации, чтобы учесть все особенности; разработать и внедрить правила и регламенты. В таких случаях возможностей коробочного решения, скорее всего, не хватит и важно выбрать более функциональное, которое даст вам простор для изменений и при этом не потребует постоянных платных доработок.
Могут возникнуть и другие особенности. Например, вам нужна система для контактного центра, где важно максимально быстро находить релевантную информацию. Тогда одним из ключевых требований будет возможность легко настраивать такие «поисковые» сценарии работы и делать это с учетом индивидуальных потребностей скилл-групп (команд операторов со специализацией на различных вопросах).
Учет особенностей, уровня сложности задачи критичен и перспектив развития, так как помогает выбрать решение, которое будет достаточно полно покрывать все требуемые сценарии, обеспечивать необходимую гибкость и масштабируемость в будущем, или, напротив, не будет для вас чрезмерным и неоправданно дорогим.
Чем лучше вы понимаете особенности и возможности рассматриваемой системы, тем более обоснованно сможете подойти к выбору, избегая излишних затрат.
Категория пользователей
Следующий важный аспект — это категория пользователей, которые будут работать с Базой знаний. Есть люди, которые не очень хорошо знакомы с технологиями, им нужен максимально простой интерфейс, чтобы они могли легко находить информацию и взаимодействовать с системой. Продвинутым пользователям, напротив, потребуется богатый функционал: расширенный поиск, применение AI, полнофункциональный редактор контента, более гибкое структурирование информации и варианты взаимодействия.
Если у вас в компании есть оба типа пользователей, то в рамках системы вам необходимо предусмотреть варианты взаимодействия и для тех, и для других. Такой подход будет более затратным, но при этом даст лучший результат для бизнеса, т.к. гарантированно повысит вовлеченность всех категорий пользователей в работу с системой.
Внедрение усредненного варианта, компромисса между потребностями экспертов, и для пользователей с минимальными навыками (так называемых "синих воротничков"), — идея плохая. Таким решением просто не захотят пользоваться.
То есть, потратив чуть больше на этапе внедрения, вы затем сэкономите время и силы всех сотрудников, снизите риск саботажа Базы знаний сотрудниками и избежите внедрения «костылей» и обходных вариантах в уже готовом решении (что по итогу окажется дороже).
Если у вас в компании есть оба типа пользователей, то в рамках системы вам необходимо предусмотреть варианты взаимодействия и для тех, и для других. Такой подход будет более затратным, но при этом даст лучший результат для бизнеса, т.к. гарантированно повысит вовлеченность всех категорий пользователей в работу с системой.
Внедрение усредненного варианта, компромисса между потребностями экспертов, и для пользователей с минимальными навыками (так называемых "синих воротничков"), — идея плохая. Таким решением просто не захотят пользоваться.
То есть, потратив чуть больше на этапе внедрения, вы затем сэкономите время и силы всех сотрудников, снизите риск саботажа Базы знаний сотрудниками и избежите внедрения «костылей» и обходных вариантах в уже готовом решении (что по итогу окажется дороже).
Учитывайте категорию и потребности всех пользователей Базы знаний и создавайте удобную систему, которой все будут пользоваться с удовольствием.
В момент внедрения это потребует больше вложений, по на длинной дистанции точно приведет к экономии.
Интеграции с другими системами и каналами взаимодействия с Базой знаний
В зависимости от того, как вы подойдете к интеграциям, они могут либо привести к значительной экономии, либо стать самой затратной и нерентабельной статьей бюджета внедрения.
Например, вы инвестируете в интеграцию базы знаний с платформой для колл-центра или CRM-системой. Благодаря такой интеграции вы экономите человеко-часы сотрудников, снижаете количество их ошибок и повышаете лояльность клиентов. В конечном итоге эти сэкономленные ресурсы по стоимости существенно превышают интеграционные затраты и полностью их оправдывают.
Для производства, где сотрудники работают на оборудовании или физической инфраструктуре, тоже необходим доступ к базе знаний, однако компьютеров у них зачастую нет. В таких случаях важна интеграция с другими удобными каналами: например, мессенджерами. Дополнительно можно разработать бота, с которым можно переписываться или даже общаться голосом. В таких случаях доработки и интеграции критически важны, поскольку они напрямую влияют на эффективность работы работников — платить за них стоит.
Но иногда возникает обратная ситуация, когда компании, гонясь за модными трендами, пытаются внедрить в базу знаний чат-ботов и интеграцию с мессенджерами, несмотря на то, что реальная необходимость в этом отсутствует. Например, если сотрудники используют компьютеры, и доступ к базе знаний с телефона редко требуется, а информация не слишком сложная, то дополнительные помощники окажутся излишними. Такие доработки часто требуют значительных затрат и времени, поэтому их следует тщательно и критически оценивать, чтобы понять, действительно ли они оправданы и принесут пользу.
Например, вы инвестируете в интеграцию базы знаний с платформой для колл-центра или CRM-системой. Благодаря такой интеграции вы экономите человеко-часы сотрудников, снижаете количество их ошибок и повышаете лояльность клиентов. В конечном итоге эти сэкономленные ресурсы по стоимости существенно превышают интеграционные затраты и полностью их оправдывают.
Для производства, где сотрудники работают на оборудовании или физической инфраструктуре, тоже необходим доступ к базе знаний, однако компьютеров у них зачастую нет. В таких случаях важна интеграция с другими удобными каналами: например, мессенджерами. Дополнительно можно разработать бота, с которым можно переписываться или даже общаться голосом. В таких случаях доработки и интеграции критически важны, поскольку они напрямую влияют на эффективность работы работников — платить за них стоит.
Но иногда возникает обратная ситуация, когда компании, гонясь за модными трендами, пытаются внедрить в базу знаний чат-ботов и интеграцию с мессенджерами, несмотря на то, что реальная необходимость в этом отсутствует. Например, если сотрудники используют компьютеры, и доступ к базе знаний с телефона редко требуется, а информация не слишком сложная, то дополнительные помощники окажутся излишними. Такие доработки часто требуют значительных затрат и времени, поэтому их следует тщательно и критически оценивать, чтобы понять, действительно ли они оправданы и принесут пользу.
Чтобы не тратить лишние ресурсы и деньги на интеграционные задачи, всегда важно учитывать то, как та или иная связка систем в конечном счете повлияет на бизнес и работу сотрудников и стараться рассчитать эффективность вложений.
Функциональные требования
При внедрении Базы знаний в крупном бизнесе клиенты часто формируют очень широкое ТЗ, которое учитывает не только приоритетные потребности, но и перспективу ближайшего роста. В таких ТЗ часто появляются сложные сценарии работы с платформой, запросы на платные доработки.
При этом заказчик в этот момент еще не накопил экспертизу и не имеет ясного представления о том, как именно будет «жить» База знаний в их компании. А подрядчик — даже если это опытная команда — еще не достаточно хорошо знаком с бизнесом клиента, чтобы критически осмыслить эти требования и скорректировать лишнее. В результате, если такому ТЗ дают ход, по прошествии времени и потраченных n-ых миллионов рублей часто оказывается, что большая часть требований могла быть реализована с помощью уже существующих возможностей системы.
При этом заказчик в этот момент еще не накопил экспертизу и не имеет ясного представления о том, как именно будет «жить» База знаний в их компании. А подрядчик — даже если это опытная команда — еще не достаточно хорошо знаком с бизнесом клиента, чтобы критически осмыслить эти требования и скорректировать лишнее. В результате, если такому ТЗ дают ход, по прошествии времени и потраченных n-ых миллионов рублей часто оказывается, что большая часть требований могла быть реализована с помощью уже существующих возможностей системы.
Поэтому важно начать с простых сценариев, выбирая более легкие и понятные задачи, постепенно расширяя экспертизу как внутри компании, так и со стороны вендора.
Такой подход помогает обеим сторонам лучше погрузиться в процесс, понять его тонкости и особенности. В результате, появляется возможность более точно определить, какие функции системы подходят для решения текущих задач, где требуется более тонкая настройка или дополнительные доработки. Это позволяет сформировать более адекватное техническое задание для экспертных команд и вендора и не тратить лишние деньги.
Также полезно использовать возможности платформы (если таковые есть) для проведения А/Б-тестирования функционала: разделять подходы, выделять группы пользователей и через некоторое время собирать обратную связь. Такой подход помогает понять, какой инструмент или стратегия работает лучше, и оценить эффективность внедрения в рамках уже доступных возможностей системы. В итоге вы получите более точное представление о том, какие решения наиболее подходят для ваших бизнес-задач, не прибегая к сложным и дорогостоящим кастомизациям.
Также полезно использовать возможности платформы (если таковые есть) для проведения А/Б-тестирования функционала: разделять подходы, выделять группы пользователей и через некоторое время собирать обратную связь. Такой подход помогает понять, какой инструмент или стратегия работает лучше, и оценить эффективность внедрения в рамках уже доступных возможностей системы. В итоге вы получите более точное представление о том, какие решения наиболее подходят для ваших бизнес-задач, не прибегая к сложным и дорогостоящим кастомизациям.
Методология
Когда крупная корпорация с нуля выстраивает глобальную стратегию по управлению информацией и с ней внедряет Базу знаний, внешние методологи действительно необходимы, ведь внутренней экспертизы по управлению знаниями, как правило, нет.
Однако по нашему опыту большинство задач не такие глобальные, ориентированы на нужды бизнес-подразделений или департаментов. В таких случаях важны конкретные сценарии работы со знаниями: что именно и как делают сотрудники и переложение этих сценариев на Базу знаний. Для первого нужны внутренние эксперты, которые поделятся собственным опытом работы со знаниями, для второго — эксперты поставщика платформы. То есть, можно справиться собственными силами без дополнительных затрат на внешнюю экспертизу.
Есть и другая важная методологическая сторона — обучение сотрудников работе с информацией. Чтобы успешно работать с Базой знаний и со знаниями вообще им нужно понимать, как лучше структурировать данные, по каким принципам создавать информацию, как форматировать. Например, статья должна одновременно освещать несколько вопросов или же состоять из связных небольших материалов?
Такие знания востребованы особенно в тех случаях, когда организация впервые сталкивается с систематизацией данных. На начальном этапе вам может потребоваться методологическая поддержка, возможно даже некий внешний эксперт, который проведет обучение. Однако для поддержания работы сторонние специалисты, как правило, не нужны: задачами по организации знаний в платформе справляется один-два контент-менеджера, которых лучше всего вырастить из собственных сотрудников.
Однако по нашему опыту большинство задач не такие глобальные, ориентированы на нужды бизнес-подразделений или департаментов. В таких случаях важны конкретные сценарии работы со знаниями: что именно и как делают сотрудники и переложение этих сценариев на Базу знаний. Для первого нужны внутренние эксперты, которые поделятся собственным опытом работы со знаниями, для второго — эксперты поставщика платформы. То есть, можно справиться собственными силами без дополнительных затрат на внешнюю экспертизу.
Есть и другая важная методологическая сторона — обучение сотрудников работе с информацией. Чтобы успешно работать с Базой знаний и со знаниями вообще им нужно понимать, как лучше структурировать данные, по каким принципам создавать информацию, как форматировать. Например, статья должна одновременно освещать несколько вопросов или же состоять из связных небольших материалов?
Такие знания востребованы особенно в тех случаях, когда организация впервые сталкивается с систематизацией данных. На начальном этапе вам может потребоваться методологическая поддержка, возможно даже некий внешний эксперт, который проведет обучение. Однако для поддержания работы сторонние специалисты, как правило, не нужны: задачами по организации знаний в платформе справляется один-два контент-менеджера, которых лучше всего вырастить из собственных сотрудников.
Методология важна, однако привлечение сторонних экспертов должно быть оправдано сложностью и объемом задачи.
Модель использования: контур или облако
Развернуть систему в контуре дороже, чем использовать для этого же облачные сервисы. Большинству компаний, которые внедряют Базу знаний, облачных решений достаточно. Тем не менее они могут выбирать более дорогой вариант. Происходит это из-за повышенных требований к безопасности.
Например, безопасники блокируют облачную модель, чтобы снизить риски утечки определенных данных. При этом те же самые данные доступны внешней аудитории бизнеса через сайт или другие ресурсы. Получается, что это ограничение становится нелогичным.
При этом мы не утверждаем, что все без исключения должны выбирать облачные сервисы. Есть отрасли, где требования к ИБ регламентированы государством. Есть ситуации, в которых локальное развертывание в конечном счете действительно будет оптимальным вариантом: когда компания мыслит на перспективу использования решения 5+ лет.
Например, безопасники блокируют облачную модель, чтобы снизить риски утечки определенных данных. При этом те же самые данные доступны внешней аудитории бизнеса через сайт или другие ресурсы. Получается, что это ограничение становится нелогичным.
При этом мы не утверждаем, что все без исключения должны выбирать облачные сервисы. Есть отрасли, где требования к ИБ регламентированы государством. Есть ситуации, в которых локальное развертывание в конечном счете действительно будет оптимальным вариантом: когда компания мыслит на перспективу использования решения 5+ лет.
Включенность внутренней команды
Подрядчик не сможет полностью понять специфику вашего бизнеса и учесть все нюансы. Поэтому сразу примите как данность, что необходимо выделить время внутренних экспертов, которые будут работать с плотной связке с вендором, отвечать на его вопросы, разъяснять разные аспекты бизнес-процессов, верифицировать гипотезы.
С одной стороны, это загрузка сотрудников и те же человеко-часы, с другой...
С одной стороны, это загрузка сотрудников и те же человеко-часы, с другой...
— только благодаря включению внутренней команды вам удастся разработать оптимальные технические требования для платформы, быстрее реализовать развертывание решения, избежать дополнительных трат на ненужные доработки.
Применение генеративного ИИ
Бизнес сейчас активно проявляет интерес к генеративному ИИ. Компании начинают запускать собственные проекты: нанимают специалистов по машинному обучению, промт-инженеров, приобретают дорогостоящие ресурсы, учатся обрабатывать данные.
Однако зачастую ключ к успеху прост и лежит в создании действительно хорошо структурированного контента. А это именно то, что предполагает База знаний.
Однако зачастую ключ к успеху прост и лежит в создании действительно хорошо структурированного контента. А это именно то, что предполагает База знаний.
Поэтому важно стратегически подходить к выбору Базы знаний и заранее проектировать её с учетом развития искусственного интеллекта, интеграцию которого в бизнес вы, скорее всего, будете проводить в ближайшие годы.
Такие базы должны быть не просто хранилищами информации, а хорошо структурированными, легко расширяемыми и совместимыми с технологиями генеративного ИИ, а ещё лучше - использующими их уже сейчас, что обеспечивает их долгосрочную актуальность и эффективность.
Заключение
Эффективная (в том числе с точки зрения стоимости) База знаний — это не та, у которой больше всего функций, а та, которой пользуются каждый день. Чтобы оптимизировать затраты на внедрение такой платформы нужно разумно рассчитывать и распределять бюджет, а не пытаться его сократить или втиснуть в узкие рамки. Лишние траты возникают, когда решение внедряется в отрыве от контекста: реальных задач, живых пользователей и существующих бизнес-процессов.
При этом самая важная инвестиция на старте — это время, потраченное на глубокий детальный анализ. Понимание уровня сложности и всех аспектов стоящей перед вами задачи убережет вас от покупки «космического корабля» для поездки в магазин или, наоборот, попыток доработать детский велосипед до уровня новейшей модели Tesla.
При этом самая важная инвестиция на старте — это время, потраченное на глубокий детальный анализ. Понимание уровня сложности и всех аспектов стоящей перед вами задачи убережет вас от покупки «космического корабля» для поездки в магазин или, наоборот, попыток доработать детский велосипед до уровня новейшей модели Tesla.