Информационная археология. Как перестать терять до 25% рабочего времени на поиск данных

Очень интересный и показательный кейс на одном из производств. Крупный клиент, прислал срочные вопросы по отгруженной партии. Нужно было поднять согласованное ТЗ, протокол контроля качества и переписку с их маркетологом полуторагодичной давности. Три человека искали это почти два рабочих дня. ТЗ нашлось в архиве на сетевом диске, протокол — во вложении письма у уже уволившегося менеджера, а переписка частично велась в мессенджере на личном телефоне. Клиент ждал, менеджер нервничал, производство простаивало с перезапуском партии. Когда все собрали, выяснилось, что правда на стороне производства, отклонение в пределах допуска, который сами же и согласовали. Два дня работы трех человек — чтобы доказать то, что было зафиксировано письменно более года назад.

Масштаб проблемы. Когда каждый пятый час уходит на «археологию»

Для относительно небольших компаний количество систем может быть достаточно большим: 1С, CRM, система управления производством, почта, два мессенджера, файловое хранилище, портал для клиентов, таск-трекер. Насчитали семнадцать точек, где рождается и живет рабочая информация. Некоторые исследования говорят про 20% рабочего времени на поиск нужных данных, и поначалу эта цифра казалась преувеличением. Замерили у себя по трем отделам за две недели: у менеджеров вышло около 15%, у технологов ближе к 25%, а у нового сотрудника в первый месяц — вообще за 30%. То есть каждый четвертый-пятый час специалист занимается не работой, а археологией. Умножьте на фонд оплаты труда и получите сумму, от которой становится нехорошо.

Отдельная беда — это накопленный хлам, который никто не удаляет. По нашим прикидкам, около двух третей документов на общих дисках устарели, но продолжают исправно находиться поиском. Прайс 2021 года, регламент приемки, который переписывали трижды, инструкция к уже проданному оборудованию И самое интересное, что старый документ часто выглядит убедительнее нового: он аккуратно оформлен, у него солидное название вроде «Технология_финальная_утверждено.docx», а актуальная версия лежит под именем «техн правки от Василия v3». Сотрудник открывает первый, работает по нему и может сделать брак.

Еще занятнее, когда знания живут только в голове. Если технолог работает с 2011 года и половина решений по некоторым заказам принимается исходя из его личного опыта. И когда он, например, уходит на три недели в отпуск туда, где плохая связь, эти заказы могут встать. Ситуация, конечно, смешная, но по факту значимый риск. Личные архивы сотрудников — вообще отдельный жанр: папка «Работа» на рабочем столе, где лежит вся экспертиза человека за семь лет. Увольняется — и половина уезжает вместе с ноутбуком в смысле знаний, а не файлов.

Почему классические базы знаний не работают и что делать вместо миграции

Про корпоративные базы знаний. Мы их делали дважды. Первый раз в 2018 году — завели внутреннюю вики, торжественно объявили, назначили ответственных по отделам. Через восемь месяцев туда заходили три человека, один из них был системный администратор, который проверял, работает ли сервис. Причина простая: люди один раз не смогли легко найти нужную информацию. Доверие к базе знаний теряется мгновенно, а восстанавливается годами. Поэтому второй заход строили уже из другой точки: не заставлять людей писать статьи, а сделать так, чтобы знание собиралось само из того, что они и так делают.

Главное решение, которое сэкономило нам кучу денег и нервов, — отказ от идеи «давайте перенесем все в одну систему». Эту мысль приходится продавливать почти в каждом разговоре с коллегами-предпринимателями, потому что она интуитивно приятная и абсолютно провальная. Миграция данных из семнадцати источников заняла бы год, стоила бы как самолет и все равно провалилась, потому что люди продолжили бы писать в мессенджер. Работает другое: поиск ходит по источникам через программные интерфейсы и собирает результаты, а данные остаются там, где живут. Это называется «распределенный поиск», и с современными коннекторами подключение к корпоративным системам, почте и файловому хранилищу занимает недели, а не месяцы. Никакой ломки привычек, никакого переучивания. Люди работают как раньше, просто теперь у них есть одно окно, где можно спросить.

Но есть нюанс, создающий помехи: без нормальных описаний документов поиск выдает кашу и никакой искусственный интеллект от этого не спасет. Пришлось договориться на берегу о минимальном наборе: тип документа, клиент, заказ, дата, автор, срок актуальности. Шесть полей, не двадцать, иначе никто не будет заполнять. Первые три месяца заполняли руками через шаблоны в CRM, сейчас большую часть подставляет автоматика.

От поиска слов к поиску смыслов

Классический поиск по словам ищет совпадения букв, поэтому запрос «как не допустить бракованной продукции» может не найти документ, где написано «возможные дефекты адгезии». Векторный поиск работает по смыслу: текст превращается в набор чисел, отражающих значение, и близкие по смыслу вещи оказываются рядом. Сочетание двух подходов дает гораздо лучший результат, чем каждый по отдельности, особенно когда в компании своя терминология и свой жаргон. Отдельная тема — права доступа, и это та часть, где экономить категорически нельзя. Поиск обязан показывать человеку только то, к чему у него есть доступ, причем проверять это в момент запроса. Самое интересное началось, когда над поиском появился слой с языковой моделью. Разница принципиальная: раньше система отдавала двадцать ссылок — и удачи вам, теперь она дает сформулированный ответ со ссылками на конкретные абзацы конкретных документов. Работает это по схеме, которую называют «поиск с дополнением генерации»: модель сначала находит релевантные фрагменты во внутренних данных, а потом отвечает строго по ним, не придумывая от себя. Цитирование источника обязательно, без него доверять нельзя вообще ничему. У нас типовой вопрос вроде «какие режимы печати на заказ для сети аптек в прошлом году» теперь закрывается за двадцать секунд вместо получаса беготни.

Гигиена данных и борьба за культуру обмена знаниями

Заодно модель взяла на себя и грязную работу. Новые документы автоматически получают категории и теги, дубликаты вылавливаются пачками — нашли одиннадцать версий одного регламента, отличающихся парой абзацев. Противоречия тоже всплывают: система может подсветить, что, например, в двух действующих документах указаны разные сроки решения вопросов с браком — семь дней и четырнадцать. Выдача подстраивается под роль: технолог и менеджер по одному и тому же запросу видят разное, потому что им нужно разное. У каждого документа теперь есть срок пересмотра, и владельцу прилетает уведомление, что пора проверить актуальность. Не проверил за месяц — документ помечается как сомнительный и падает в выдаче.

Отвечать за актуальность должен автор, а не абстрактный отдел управления знаниями. Это выяснили опытным путем: пока ответственность была размазана, не делал никто. Помогли кнопки «информация устарела» и «ответ не помог» прямо в интерфейсе — за первые месяцы набралось около двухсот отметок, и это оказался лучший список задач по наведению порядка, чем любой аудит. Плюс видна история правок, кто и когда что менял, и появился простой рейтинг доверия: часто используемый документ, подтвержденный экспертом и без жалоб, поднимается выше.

Неявное знание вытаскивается из переписки и обсуждений в задачах, и это оказалось золотой жилой. Мы подключили транскрибацию совещаний и производственных разборов, и теперь решения из голосовых обсуждений превращаются в текст, а из текста — в структурированные записи. Из обращений в поддержку автоматически формируются ответы на частые вопросы, сейчас там больше сотни статей, которые никто не писал руками. Новички — лучший тест системы, их вопросы в первый месяц точно показывают дыры в базе. Время выхода сотрудника на самостоятельную работу сокращается примерно с девяти недель до пяти с половиной.

Что меняется в цифрах. В несколько раз сократилось время до ответа по типовому вопросу, доля успешных поисков выросла примерно до 78% против чуть больше половины на старте, а количество повторяющихся вопросов к ведущему технологу снизилось. Окупаемость измерить сложно, но сложить сокращение онбординга, уменьшение брака от работы по старым документам и высвобожденное время специалистов вполне реально — у нас вышло, что вложения вернулись за девять месяцев. Проекты начали идти быстрее просто потому, что перестали изобретать заново то, что уже решали в 2019-м.

Только вот главная сложность не в технологиях. Люди не любят отдавать то, на чем держится их незаменимость, и это самое трудное в проекте.

Иногда помогает премия за наполнение базы и публичная благодарность тем, кто делится.

Наш технолог теперь сам гоняет новичков: «в системе посмотри, там все есть».