В вечном поиске...
В вечном поиске...
Самой обсуждаемой темой на ECM-journal в прошлом месяце был поиск. Что не удивительно – человеку свойственно всё время что-то искать и, как правило, находить не совсем то, что он искал.
Ясно, что поиск по неструктурированным данным трудоёмок и не очень эффективен, а структурировать всё подряд дорого и зачастую просто неудобно.
Будем считать, что создающий документ сотрудник надеется, что его работа принесёт кому-то пользу, то есть он хочет, чтобы его документ впоследствии смогли найти. Если усилия по приближению документа к потенциальному адресату будут не очень обременительными, то сотрудник их с удовольствием приложит.
Имя документа может быть очень красноречивым, но и корпоративные правила могут предписывать наименования типа «Протокол заседания такого-то органа номер такой-то от такого-то числа». Даже если этот протокол содержит подробности обсуждения интересующих вас вопросов, то из названия это никак не видно, а список этих вопросов отлично бы смотрелся где-то рядом, например, в тегах.
Обсудили на заседании сотрудничество с каким-нибудь клиентом – в тегах указали название клиента, обсудили состояние проекта – в тегах имя проекта и стадия, родили при обсуждении свежую идею, которую внесли в протокол – обозначили её парой слов и тоже записали в теги.
И находить эти протоколы стало бы гораздо удобней.
В вебе теги используются много лет сплошь и рядом. Пример твиттера очень показателен – если хочешь быть в курсе, просто отслеживай соответствующий тег, естественно, принимая во внимание, что в горячей теме необходима суровая фильтрация. Но внутри корпорации злоумышленника найти и наказать много проще, поэтому и работать с тегами можно значительно эффективней.
Но в СЭД теги почему-то не очень жалуют. Мне кажется, совершенно напрасно. Технически всё реализуется достаточно просто, и неразрешимых организационных проблем не видно – если человек может написать грамотный протокол, то и правильные теги к нему проставить тоже сможет.
Можно пойти ещё дальше, и помечать тегами отдельные куски документа. Это было бы ещё удобней для ищущего – нет необходимости копаться в большом документе, достаточно посмотреть только его нужную часть. Но реализация такого сценария будет явно более трудоёмкой, так как документы обычно хранятся в относительно закрытых форматах, а создаются при помощи сторонних приложений.
Комментарии 5
Как человек, ставящий теги и использующий их, говорю, с ними не все так просто... Хотя и их люблю :) И статистика использования тегов, как средства поиска, тоже не всегда радует. Но, возможно, это зависит от реализации и привычек, я бы сказала "стереотипов действий". У твиттерян уже особые "стереотипы".
А еще любопытно было подмечать, что близкие темы: информационный хаос и управление информацией (Information Governance) - именно в апреле поднимали западные коллеги, причастные к труду AIIM. Так появилась инфографика «Information Chaos vs. Information Opportunity», являющаяся выжимкой фактов из одноименной электронной книги, ссылка на которую висела на главной странице aiim.com, а Sherpa Software опубликовали White Paper «What is information governance?».
Какое-то слишко обобщенное утверждение.
Во-первых, искать "по всему подряд" обычно и не нужно. Реально значимымой для большинства документов являются очень небольшая порция информации. Более того, некоторой важной информации может просто не быть в документе - т.е. её все равно нужно вводить дополнительно.
Во-вторых, в чем именно заключается трудоемкость поиска по неструктурированным данным? Мне вот это не вполне ясно.
Вот сейчас вы на ровном месте создали проблему и попытались героически ее решить...
Давайте задаимся более общим вопросом - а зачем такой априори структурированный объект как протокол заседания создавать в неструктурированном виде? Почему бы не создать его сразу как структурированную единицу, выделив все значимые составляющие:
Нестуктурированный документ (кстати, почему неструктурированный? Уже давно есть форматы поддерживающие как отображение, так и структуризацию информации одновременно) - это следствие, его вполне можно генерировать автоматически на основе приведенных выше данных.
Единственный приходящий мне на ум сценарий, когда у вас изначально будет документ без метаданных (структуры) - документ пришел к вам извне.
Не понял за счет чего повысилось удобство? Чем поиск имени клиента или названия проекта в тексте, хуже, чем поиск его в некоем поле называемом тэгом? Может быть у нас просто разное представление о том, что такое тэг? То, что вы описали, больше напоминает строку с произвольными ключевыми словами. Но это не метки (тэги)!
Метки хорошо работают пока их ограниченное количество, или у вас есть жесткие правила по работе с ними. Иначе вы рискуете погрязнуть в этих самых метках.
Чтобы не ходить далеко за примерами http://ecm-journal.ru/showcloud.aspx - это метки к статьям на EJ. Только часть из этих меток реальные тэги, большинство же - это добавление в поле тэгов рубрик к которым относится статья (например, "внедрение", "государство", ...). Но даже на таком небольшом колчестве тэгов уже видны несколько десятков тэгов-дублей (например, "делопроизводителю, делопроизводства, делопроизводство").
Возможно потому, что понимают - поддержка полноценной и удобной системы тэгов, это удовольствие сравнимое по стоимости с поддержкой любой другой системы метаданных.
На самом деле, во многих СЭД есть механизмы по поддержке тэгов, но они изначально ориентируются на работу в очень крупных компаниях, где без должного управления тэгов может быть сотни тысяч. Вот, кпримеру, довольно интересная статья Introducing Enterprise Metadata Management о том, как строится система таксономии в SharePoint, начиная с версии 2010, почему она такая сложная и громоздкая - из каких предпосылок исходили авторы при её проектировании
Мы вообще не всегда можем внутрь документа залезть - бывает хотя бы видео и аудио, трудно поддающиеся распознаванию, да и в доступном тексте автоматически определить, что важно, а что нет - задача как минимум нетривиальная, так что обычная практика заключается в том, что если есть по чему искать, то ищем по всему подряд, а если нет, то кроме заголовка и аннотации ничего и не остаётся.
Протокол взят чисто для примера.
Кстати, не факт, что он очень уж изначально структурированный - заседания бывают разные, повестки в чистом виде может вообще не быть, как и конкретных решений.
С другой стороны - почему только протокол структурированный? Любой текстовый документ есть набор тезисов, так что структурировать изначально можно всё, кроме разве что художественных произведений.
Собственно, я и пытался сделать упор именно на то, что сотрудник хочет, чтобы его документ было легко найти. И он приложит к этому усилия. Если опыт будет успешным, то и другие будут ему следовать.
Естественно. :)
Начнётся обязаловка - не факт, что это всё хорошо закончится.
Ну и таки да - это может оказаться слишком дорого.
Вот я и говорю, что это, на мой взгляд, не слишком удачный пример.
Выглядит, как пример того, как не нужно проводить совещания (впрочем, возможно термин "заседания" употреблен не просто так - мол, посидели, поговорили и разошлись). Если нет понимания, что обсуждалось (да повестка не обязательно известна ДО совещения - в процессе она может и меняться), и какие приняты решения, то, имхо, на 99% - время потрачено впустую.
Давайте ещё раз, тезисно:
Итак, когда мы ищем документы, нам нужны точность метаданных и гарантированное их заполнение. Необязательные тэги тут явно не помощники.
Если же мы начинаем искать информацию, которая как мы определили выше, с трудом поддается структуризации, то вот и начинают изобретаться всякие разные схемы. Вполне возможно, что тэги здесь могут оказаться вполне полезны, вот только:
Я еще раз настоятельно рекомендую вам посмотреть на другие, конкурирентные по отношению к Directum решения. Например, начать можно с того, как устроена таксономия в SharePoint (ссылку на хорошую вводную статью я давал чуть выше). Особое внимание я бы обратил на то, что:
Причем все эти "навороты", не плод больного ума, пары начинающих "архитекторов", а результаты работы над другой системой (Content Management Server), на базе которой работала (а может и сейчас работает...) совокупность сайтов microsoft.com. Правда, как я понимаю, мы эту систему таксономии увидеть не сможем - на пользователей она не выходит.