Корпоративный поиск

«Мы ничего не теряем. Мы просто долго ищем»

Народная поговорка

Сегодняшний день я посвятил участию в дискуссионном клубе на DOCFLOW 2011. Вел себя активно, одобрительно кивал головой в ходе выступлений, задавал вопросы. Собственно говоря, интересных тем в дискуссионном клубе было две: тенденции развития ECM и корпоративный поиск. Про ECM как-нибудь в следующий раз, а сейчас про корпоративный поиск.

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

Наблюдение первое. Никакой поисковый движок не может по своему быстродействию сравниться с реляционной базой данных. Разумеется, если использовать базу данных правильно. Обычно, продавцы корпоративного поиска, да и ECM в целом, говорят о том, что только 20% корпоративных данных являются структурированными, а остальные 80% — неструктурированным. Поэтому, в реляционную базу данных можно запихнуть всего лишь пятую часть всей информации. Я не знаю, откуда взялась цифра 20%. Почему не 15 или не 30. Мне кажется это утверждение достаточно голословным. Важно другое. Для того чтоб повысить долю структурированной информации её надо структурировать. Если компания не хочет структурировать, например приказы, инструкции и распоряжения, создавать карточки документов, использовать механизмы тегов и категорий, то никакой поисковый engine ей не поможет. Если компания готова вкладываться в структурирование данных, тогда доля данных неструктурированных будет меньше гипотетических 80%.

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

Наблюдение третье. Стоимость лицензий на корпоративный поисковый движок – это верхняя часть айсберга. Информацию всегда сложнее вытащить из системы, чем туда положить. Data warehouse-ы  и витрины данных появились не от хорошей жизни. У любой информационной системы есть пределы capacity. Ни один здравомыслящий DBA не пустит поисковый движок в свою базу данных. В лучшем случае можно получить онлайн-копию. Но это отдельные деньги. Никакими коннекторами и адаптерами задача планирования емкостей не решается. Кроме того, в отличии от stateless протокола HTTP, протоколы доступа к базам данных масштабируются сложно и дорого. Я уж не говорю про вопросы семантики и стандарты на структуры данных.

Резюмирую. Идея корпоративного поиска, безусловно, правильная. Но отдельных денег я платить бы за неё не стал. Корпоративный поиск — это, …как бы это сказать по-русски, commodity, бесплатное приложение к ECM или хранилищу данных.

Реклама

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s