Журнал о системах электронного документооборота (СЭД)
Технологии проектирования и построения СЭД

В вечном поиске...

  5 комментариев Добавить в закладки

Самой обсуждаемой темой на ECM-journal в прошлом месяце был поиск. Что не удивительно – человеку свойственно всё время что-то искать и, как правило, находить не совсем то, что он искал.
Ясно, что поиск по неструктурированным данным трудоёмок и не очень эффективен, а структурировать всё подряд дорого и зачастую просто неудобно.
Будем считать, что создающий документ сотрудник надеется, что его работа принесёт кому-то пользу, то есть он хочет, чтобы его документ впоследствии смогли найти. Если усилия по приближению документа к потенциальному адресату будут не очень обременительными, то сотрудник их с удовольствием приложит.

Имя документа может быть очень красноречивым, но и корпоративные правила могут предписывать наименования типа «Протокол заседания такого-то органа номер такой-то от такого-то числа». Даже если этот протокол содержит подробности обсуждения интересующих вас вопросов, то из названия это никак не видно, а список этих вопросов отлично бы смотрелся где-то рядом, например, в тегах.

Обсудили на заседании сотрудничество с каким-нибудь клиентом – в тегах указали название клиента, обсудили состояние проекта – в тегах имя проекта и стадия, родили при обсуждении свежую идею, которую внесли в протокол – обозначили её парой слов и тоже записали в теги.

И находить эти протоколы стало бы гораздо удобней.

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

Но в СЭД теги почему-то не очень жалуют. Мне кажется, совершенно напрасно. Технически всё реализуется достаточно просто, и неразрешимых организационных проблем не видно – если человек может написать грамотный протокол, то и правильные теги к нему проставить тоже сможет.

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

Ещё материалы автора
Похожие записи
Комментарии (5)
Елена Питомцева 06 мая 2014 г. 15:46  

Как человек, ставящий теги и использующий их, говорю, с ними не все так просто... Хотя и их люблю :) И статистика использования тегов, как средства поиска, тоже не всегда радует. Но, возможно, это зависит от реализации и привычек, я бы сказала "стереотипов действий".  У твиттерян уже особые "стереотипы".

Максим Кайнер 06 мая 2014 г. 15:52  
Самой обсуждаемой темой на ECM-journal в прошлом месяце был поиск.

А еще любопытно было подмечать, что близкие темы: информационный хаос и управление информацией (Information Governance) - именно в апреле поднимали западные коллеги, причастные к труду AIIM. Так появилась инфографика «Information Chaos vs. Information Opportunity», являющаяся выжимкой фактов из одноименной электронной книги, ссылка на которую висела на главной странице aiim.com, а Sherpa Software опубликовали White Paper «What is information governance?».

 
А вообще, было бы интересно развить мысль насчет тегов в ECM-системах, так бы получился более емкий и основательный материал. К примеру, можно подумать, какие из документов в первую очередь следует одарить тегами как обязательными реквизитами...

 

Михаил Романов 06 мая 2014 г. 20:01  
Ясно, что поиск по неструктурированным данным трудоёмок и не очень эффективен, а структурировать всё подряд дорого и зачастую просто неудобно

Какое-то слишко обобщенное утверждение.

Во-первых, искать "по всему подряд" обычно и не нужно. Реально значимымой для большинства документов являются очень небольшая порция информации. Более того, некоторой важной информации может просто не быть в документе - т.е. её все равно нужно вводить дополнительно.

Во-вторых, в чем именно заключается трудоемкость поиска по неструктурированным данным? Мне вот это не вполне ясно.

Даже если этот протокол содержит подробности обсуждения интересующих вас вопросов, то из названия это никак не видно, а список этих вопросов отлично бы смотрелся где-то рядом, например, в тегах.

Вот сейчас вы на ровном месте создали проблему и попытались героически ее решить...

Давайте задаимся более общим вопросом - а зачем такой априори структурированный объект как протокол заседания создавать в неструктурированном виде? Почему бы не создать его сразу как структурированную единицу, выделив все значимые составляющие:

  • обсуждаемые вопросы
  • принятые решения
  • сроки исполнения
  • ответственных
  • ...

Нестуктурированный документ (кстати, почему неструктурированный? Уже давно есть форматы поддерживающие как отображение, так и структуризацию информации одновременно) - это следствие, его вполне можно генерировать автоматически на основе приведенных выше данных.

Единственный приходящий мне на ум сценарий, когда у вас изначально будет документ без метаданных (структуры) - документ пришел к вам извне.

Обсудили на заседании сотрудничество с каким-нибудь клиентом – в тегах указали название клиента, обсудили состояние проекта – в тегах имя проекта и стадия, родили при обсуждении свежую идею, которую внесли в протокол – обозначили её парой слов и тоже записали в теги. И находить эти протоколы стало бы гораздо удобней.

Не понял за счет чего повысилось удобство? Чем поиск имени клиента или названия проекта в тексте, хуже, чем поиск его в некоем поле называемом тэгом? Может быть у нас просто разное представление о том, что такое тэг? То, что вы описали, больше напоминает строку с произвольными ключевыми словами. Но это не метки (тэги)!

Метки хорошо работают пока их ограниченное количество, или у вас есть жесткие правила по работе с ними. Иначе вы рискуете погрязнуть в этих самых метках.

Чтобы не ходить далеко за примерами http://ecm-journal.ru/showcloud.aspx - это метки к статьям на EJ. Только часть из этих меток реальные тэги, большинство же - это добавление в поле тэгов рубрик к которым относится статья (например, "внедрение", "государство", ...). Но даже на таком небольшом колчестве тэгов уже видны несколько десятков тэгов-дублей (например, "делопроизводителю, делопроизводства, делопроизводство").

Но в СЭД теги почему-то не очень жалуют.

Возможно потому, что понимают - поддержка полноценной и удобной системы тэгов, это удовольствие сравнимое по стоимости с поддержкой любой другой системы метаданных.

На самом деле, во многих СЭД есть механизмы по поддержке тэгов, но они изначально ориентируются на работу в очень крупных компаниях, где без должного управления тэгов может быть сотни тысяч. Вот, кпримеру, довольно интересная статья Introducing Enterprise Metadata Management о том, как строится система таксономии в SharePoint, начиная с версии 2010, почему она такая сложная и громоздкая - из каких предпосылок исходили авторы при её проектировании

Игорь Салтыков 08 мая 2014 г. 09:37  
Во-первых, искать "по всему подряд" обычно и не нужно. Реально значимымой для большинства документов являются очень небольшая порция информации. Более того, некоторой важной информации может просто не быть в документе - т.е. её все равно нужно вводить дополнительно. Во-вторых, в чем именно заключается трудоемкость поиска по неструктурированным данным? Мне вот это не вполне ясно.

Мы вообще не всегда можем внутрь документа залезть - бывает хотя бы видео и аудио, трудно поддающиеся распознаванию, да и в доступном тексте автоматически определить, что важно, а что нет - задача как минимум нетривиальная, так что обычная практика заключается в том, что если есть по чему искать, то ищем по всему подряд, а если нет, то кроме заголовка и аннотации ничего и не остаётся.

зачем такой априори структурированный объект как протокол заседания создавать в неструктурированном виде?

Протокол взят чисто для примера.
Кстати, не факт, что он очень уж изначально структурированный - заседания бывают разные, повестки в чистом виде может вообще не быть, как и конкретных решений.
С другой стороны - почему только протокол структурированный? Любой текстовый документ есть набор тезисов, так что структурировать изначально можно всё, кроме разве что художественных произведений.

поддержка полноценной и удобной системы тэгов, это удовольствие сравнимое по стоимости с поддержкой любой другой системы метаданных.

Собственно, я и пытался сделать упор именно на то, что сотрудник хочет, чтобы его документ было легко найти. И он приложит к этому усилия. Если опыт будет успешным, то и другие будут ему следовать.

с ними не все так просто

Естественно. :)

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

Начнётся обязаловка - не факт, что это всё хорошо закончится.
Ну и таки да - это может оказаться слишком дорого.

 

Михаил Романов 10 мая 2014 г. 18:40  
Протокол взят чисто для примера

Вот я и говорю, что это, на мой взгляд, не слишком удачный пример.

заседания бывают разные, повестки в чистом виде может вообще не быть, как и конкретных решений.

Выглядит, как пример того, как не нужно проводить совещания (впрочем, возможно термин "заседания" употреблен не просто так - мол, посидели, поговорили и разошлись). Если нет понимания, что обсуждалось (да повестка не обязательно известна ДО совещения - в процессе она может и меняться), и какие приняты решения, то, имхо, на 99% - время потрачено впустую.

Давайте ещё раз, тезисно:

  • СЭД/ECM, как правило, хранит как минимум 2 типа контента (в реальности их можно и нужно разделить на больше количество, но нам важны только 2):
    • документы (у западных коллег есть даже специальный термин Record), т.е. сущности, которые подтверждают некоторый факт: факт заключения сделки (подписанный договор), её исполнения (акт), факт приема на работу (приказ) и увольнения (заявление), ...
    • информационный контент, т.е. тот, который содержит некую полезную информацию (например, документация на продукт, инструкция по настройки сети в офисе N, и т.д.)
  • Когда мы ищем документ, перед нами в 90% случаев стоит задача найти конкртеный экземпляр по точным критериям: дата, котрагент, номер, ... Скажу даже больше, для солидной части документов мы можем их различить только по этим самым критериям - в остальном они идентичны (для наглядного примера можно взять заявление или типовой договор).
  • Еще одна весьма частая задача поиска документов: найти ВСЕ документы, по определенному вопросу - например, все договоры, заключенные с определенной компанией. Чтобы обеспечить такой тип поиска мы должны вводить метаданные единообразно и принудительно.
  • Если же мы ищем некую информацию, например, ответ на вопрос "как настроить Wi-Fi в офисе на Ленина, 15", то наша методология поиска меняется разительно: 
    • Нам нужна информация и абсолютно не важно как она хранится: в какаом документе (или не документе), какого формата, ... Более, того, достаточно многие компании (по моим личным наблюдениям) отходят от хранения динамически меняющейся информации в виде автономных документов. Т.е. та же инструкция по настройке с гораздо большей вероятностью будет храниться в виде статьи в Knowledge Base, которая, в свою очередь будет построена на каком-нибудь Wiki-подобном движке.
    • С большой вероятностью информация не хранится в одном месте.
    • Т.к. информаци очень разнородна для нее очень сложно или невозможно выделить регулярные атрибуты метаданных.

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

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

  • нужно определить что же такое "тэг": как они создаются, как используются при поиске
  • необходимо понять, что такого дает использование тэгов по сранению с другими типами поисков/навигации. Например, имеет ли смысл выносить в тэги "имя клиента", "название проекта", "новую идею", при условии что они и так находятся по тексту документа?
  • понять какие проблемы имеет система тэгов и как с ними можно бороться

Я еще раз настоятельно рекомендую вам посмотреть на другие, конкурирентные по отношению к Directum решения. Например, начать можно с того, как устроена таксономия в SharePoint (ссылку на хорошую вводную статью я давал чуть выше). Особое внимание я бы обратил на то, что:

  • базу терминов (из которых строятся тэги) наполняют централизованно, специальные люди (добавить новый термин могут и другие пользователи, но это отдельный процесс, который завершается на тех же "специальных людях", которые приводят новый термин в соответствие с общей схемой)
  • термины имеют весьма сложную внутреннюю организацию. В частности:
    • термины объеденены в наборы терминов (например, группа "Географические точки" или "Продукты питания")
    • термины иерархически упорядочены
    • поддерживаются такие свойства как работа с синонимами и омонимами (точнее омографами) или термины на разных языках
  • термины делятся на глобальные (enterprise уровня) и локальные (например, для отдельных подразделений). 
  • для терминов есть понятие прав доступа / групп безопасности
  • ...

Причем все эти "навороты", не плод больного ума, пары начинающих "архитекторов", а результаты работы над другой системой (Content Management Server), на базе которой работала (а может и сейчас работает...) совокупность сайтов microsoft.com. Правда, как я понимаю, мы эту систему таксономии увидеть не сможем - на пользователей она не выходит.

Сейчас обсуждают
Больше комментариев