Что стоит хранить в СЭД
Даже имея доступ к корпоративному архиву документов, организованному с помощью системы электронного документооборота, все мы вольны решать, какие документы стоит помещать в систему, а какие – нет.
Не секрет, что у каждого из нас скапливается довольно много файлов, которые размещаются на локальных дисках, а не в СЭД – набросков, мыслей, записок, картинок, прототипов, архивов, писем, фотографий, электронных книг. Даже имея доступ к корпоративному архиву документов, организованному с помощью системы электронного документооборота, все мы вольны решать, какие документы стоит помещать в систему, а какие – нет.
И чаще решение принимается не в пользу СЭД. Причем критерий один – нежелание тратить время: чтобы документ поместить в СЭД, нужно заполнить его карточку и назначить права, а это всегда дополнительная работа. Тем не менее, хотелось бы порассуждать, в каких случаях документ все-таки следует сохранять в системе, даже если «не хочется».
Во-первых, важные для бизнеса компании документы должны размещаться в СЭД всегда. Переписка с клиентами, партнерами или поставщиками может оказаться весьма полезной при последующем разборе конфликтных ситуаций. Сохраненные черновики проектов или договоров позволят вашим коллегам подхватить вашу работу, если вы заболели.
Во-вторых, документы, содержащие полезные для сотрудников компании знания и опыт. Электронные книги, полезные статьи и просто список ссылок на Интернет-ресурсы нужно размещать в СЭД: время, сэкономленное на их поиске вашими коллегами, полностью окупит две минуты создания карточки вами.
В-третьих, в СЭД должны попадать и закрытые сведения о различных активах, например, пароли к Интернет-ресурсам или лицензионные ключи используемого в компании ПО, если за него отвечаете вы. Хранение этих сведений в СЭД с ограничением доступа гораздо безопасней, чем на локальных дисках, а при необходимости – если меняется ответственный, например, - эта информация может быть передана новому сотруднику безо всяких проблем.
В СЭД вряд ли должны размещаться фото с пикника, архивы программ или ICQ-переписка с другом, но туда вполне могут попасть фотографии с корпоративных семинаров, протоколы тестирования нового оборудования или видео-ролики вашей новой рекламы, только что переданные вашим рекламным агентством.
И не надо экономить байты и бояться, что система не справится с огромным потоком документов! Поддержка распределенных хранилищ в СЭД – уже обязательный элемент, а возможности категоризации и поиска, в т.ч. полнотекстового, изначально присутствуют в корпоративных системах электронного документооборота.
Комментарии 2
C первым пунктом хранения документов согласен. Насчет третьего - для паролей и лицензионных ключей есть специальные средства (запрос в поисковике расскажет об этом лучше всего), хотя для малого среднего бизнеса вложения в эти средства руководство скорее всего не одобрит.
Второй пункт. Электронные книги действительно удобнее хранить в СЭД, будь то .chm-файл или отсканированный вариант, а насчет полезных статей и ссылок на интернет-ресурсы можно поспорить.
Для этого на мой взгляд лучше всего подойдут другие средства: вики и блоги. Чем мы сейчас с Вами и пользуемся. :) Аналитики ввели концепцию ECM, согласно которой подобные системы должны управлять всем контентом организации, в том числе веб-контентом, но реально немногие системы могут предложить даже управление веб-сайтом, не говоря уже о поддержке web 2.0, как его сейчас модно называют технологию реализации блогов и виков. Хотя это было бы полезным на мой взгляд.
Для создания документов в системе ЭДО нужно завести на него карточку или, говоря другими словами, описать его в системе с помощью набора реквизитов. Это время, на что Максим уже обратил внимание, к тому же что писать в карточке на заносимую вырезку из статьи, которая может быть интересна сотрудникам компании и занесена в общее хранилище? Здесь сотруднику придется изгаляться и придумывать четкое название, чтобы эту информацию потом можно было быстро найти. Гораздо проще занести ее в корпоративные блоги, если это, например, некое общее рассуждение или в вики, если это четкий ответ на поставленный вопрос с указанием ключевых слов, с помощью которых потом можно будет искать эту информацию. А последующий полнотекстовый поиск поддерживается сейчас у всех серьезных вендоров.
Насколько я знаю технология виков и блогов сейчас поддерживается в SharePoint 2007 (и в Portal Server и в Office Services), поэтому начало положено, кто здесь будет следующим? Сам пока не тестировал это решение, но интересно посмотреть на реализацию.
Кто из российских разработчиков сможет предложить это, потому что теория и технология это хорошо, а как внедрять это в реальных компаниях и провести четкую линию между информацией, которую стоит заносить в виде реальных документов, и информацией, которую надо заносить в виде блогов и виков пока сложно представить.
Вики и блоги требуют, действительно, определенной культуры в организации. Не всегда именно такой формат удобен и применим - в силу привычки, из-за особенностей среды использования и т.д. Чем, например, вики отличается от базы знаний (вопросов/ответов)? Тем, что его может обсуждать, изменять, дополнять любой человек. Это удобно в публичных, "интернетовских" базах знаний, когда автором может быть каждый и все строится на энтузиазме. В корпоративной среде энтузиазма ждать сложно. Появляются ответственные, различные схемы мотивации, и формат "вики" уже не является определяющим.
Прозвучали интересные моменты, которые обязательно обсудим:
- как формально закрепить, что должно помещаться в СЭД, а что нет, нужны ли регламенты и инструкции, как мотивировать людей, что менять в интерфейсе и т.д.;
- полнотекстовый поиск: он должен быть независимым от СЭД и других источников или достаточно встроенного в СЭД; что мы ждем от полнотекстового поиска;
- особенности корпоративных блогов и вики: когда они нужны, что в них писать, как их хранить и искать по ним;
- управление веб-контентом в ECM: публикация страниц на внутренние и внешние сайты и порталы, управление вспомогательными функциями (новости, рекламные блоки, статистика). Что требуется, какие проблемы, каковы технологии.