Побочный эффект управления корпоративным контентом

gaymorit-18Недавно пришлось разбираться с одним, довольно старым приложением класса Enterprise Content Management. Возможно, что его следовало бы скорее отнести к классу систем Web Content Management, но учитывая, что использовалось оно внутри компании и пользователи считали, что хранят в нем документы, будем считать, что это ECM. Тем более что в этой системе отсутствовал традиционный функционал WCM такой как шаблоны отображения, расширения и т.п. Про теги и таксономии я и не говорю. В общем, система и система. Можно в неё файл приаттачить, а можно в визивиг редакторе web-страничку нарисовать, а затем, используя функцию поиска, что-нибудь в этой системе найти. Чем на протяжении нескольких лет и занимались редакторы и читатели контента соответственно.

Все было хорошо, пока система не стала искать документы слишком долго. Впрочем, это вполне характерно для такого класса систем. Естественно, были проведены некоторые упражнения по исправлению данной ситуации посредством переезда на новое железо, но через какое-то время и нового железа перестало хватать и проблемой пришлось заняться всерьез. Обычно, в таких случаях находится эксперт, который глубокомысленно заявляет, что проблема в архитектуре. И как только прозвучит эта фраза, сразу же зовут архитектора и говорят, что у него проблема. Конечно, архитектура системы и правда не внушала оптимизма, но настоящий культурный шок мы испытали, посмотрев на данные внутри системы. Дело в том, что большая часть этих данных была структурирована. Не частично структурирована, а структурирована полностью. Одни web-странички представляли из себя HTML-таблицы с описанием объектов и набора параметров в виде строки, другие списки свойств в формате «ключ-значение» в виде тех же HTML-таблиц. Были, правда и экранные формы, включающие несколько закладок, но на вопрос для чего это сделано кто-то мне ответил, что закладки нужны для больших документов, которые не помещаются на один экран, чтоб их было быстрее листать. Разумеется, вопрос известно ли пользователям назначение кнопок PgUp и PgDn я счел задавать неуместным. Одним словом, на протяжении многих лет пользователи вбивали в систему вполне структурированную информацию в виде HTML страниц или в разнообразных офисных форматах. Естественно, в какой-то момент искаться информация во всем этом массиве данных стала медленно. Ситуация существенно ухудшилась после реализации в системе невинной просьбы пользователей о реализации предиктивного поиска.

На самом деле, ситуация довольно типичная. Никто не будет структурировать информацию по собственной воле. Многолетний опыт создания документов в редакторе MS Word формирует соответствующий user experience. А бизнес-приложения, с драконовскими требованиями по обязательному заполнению всех полей в экранной форме отталкивают пользователей (Вспомните сколько раз даже на интернет ресурсах от вас требовали ввести ZIP code ). Тем более, что внесение даже небольших изменений в экранную форму и структуру данных, потребует привлечения программиста и может оказаться не быстрым и не бесплатным. Вот люди и создают «контент» из структурированных данных, а некоторые айтишники их в этом поддерживают. Тезис о том, что 80% корпоративной информации это неструктурированные данные известен практически всем.

О том, что это не так я уже писал в заметке Существуют ли непредсказуемые бизнес-процессы и неструктурированные данные? Мысль о том, что ECM позволяет связать с друг другом различные образы одного и того же объекта, например скан-копию документа с записью о нем в учетной системе, так же достаточно очевидна.

Но, видимо, как-то не так мы рассказываем все это нашим пользователям

Побочный эффект управления корпоративным контентом: 7 комментариев

  1. Что-то я недопонял. Как одно с другим стыкуется?
    “большая часть этих данных была структурирована. Не частично структурирована, а структурирована полностью.”
    “ситуация довольно типичная. Никто не будет структурировать информацию по собственной воле. Многолетний опыт создания документов в редакторе MS Word формирует соответствующий user experience.”

    И вот это.
    “Тезис о том, что 80% корпоративной информации это неструктурированные данные известен практически всем.
    О том, что это не так я уже писал”
    Как оно на самом деле?

    1. Работа сотрудников, по крайней мере некоторая ее часть, в том и заключается, чтоб превращать неструктурированнную информацию в структурированную. Потому и говорить, что какая-то часть информации является не структурированной не вполне корректно. Она не по природе своей такая, просто никто ее пока не проструктурировал

    2. Тут все просто. Большая часть корпоративной информации структурирована, т.е., грубо говоря, может быть представлена таблицами. Поэтому неплохо бы такую информацию хранить также в структурированном виде, например, в базе данных. Но таких таблиц очень много, а с универсальными средствами, позволяющими быстро и легко разные такие таблицы сохранять в структурированном виде и визуально представлять, есть очевидные проблемы – писать под каждую структуру приложение нет смысла. Поэтому самое простое – показывать такие таблицы в HTML-формате на таком вот корпоративном портале. И искать нужную информацию простым контекстным поиском. Проблема ясная, я уж давно сформулировал для себя такую задачу – легкая работа с разнородными структурированными данными – и понемногу этим занимаюсь (понемногу практически, а теория мне уже вполне ясна). Дело интересное. Для систем ACM, кстати, нужное – легкое представление различных структурированных данных в кейсах (задачах, поручениях), например, в виде форм, является обязательной фичей – ну, например, анкета товара в кейсе обработки заявки на закупку, или анкета кандидата в кейсе приема нового сотрудника на работу и т.п.

  2. По описанию похоже на Oracle UCM.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *