Методика построения хранилища документов на SharePoint

СДЦ > Статьи > Методика построения хранилища документов на SharePoint

Авторы: Р.Носков, Р.Бобров

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

В большинстве компаний, файлы, не являющиеся частью формализованного документооборота, хранятся где угодно. Это могут быть рабочие станции сотрудников, сетевые диски, внутренние файловые ресурсы и т.п. Общим свойством этих хранилищ является, с одной стороны — лёгкость размещения туда файлов, как преимущество. С другой стороны – найти там файлы, по прошествии времени, очень сложно, а для рабочих станций так и вовсе невозможно, кроме как их владельцам. В свою очередь, как мы отмечали в анонсе «СДЦ – участник круглого стола cNews «Рынок СЭД 2015: новые тренды», портал на SharePoint вполне способен выступать как хранилище всех (то есть вообще всех) файлов, попадающих или создающихся в компании или организации. Выполнять такую «глобальную» функцию ему помогают, с одной стороны, лёгкость помещения документов в это хранилище, сравнимая с лёгкостью размещения на сетевом файловом ресурсе или рабочей станции. А с другой стороны – из SharePoint также легко и извлечь документ или файл, воспользовавшись быстрым и гибким поиском по содержимому — по обрывку фразы, по части ФИО, по неполной дате и т.п.

Для того, чтобы хранилище корпоративной информации на SharePoint не превратилось в очередную «файловую помойку», в которую помещается всё, что попало (и пропадает там безвозвратно), мы применяем ряд методик, описанных ниже. В их состав входят:

  1. Создание и хранение информации на сайтах подразделений.
  2. Структура папок библиотеки подразделения.
  3. Значащие имена файлов.

Опишем эти методики более подробно

1. Создание и хранение информации на сайтах подразделений

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

Вместе с тем, при создании хранилища на SharePoint, мы можем не слишком заботиться о понятности структуры — мощный поиск SharePoint за доли секунды найдёт нужный файл, и покажет папку, где он находится. Поэтому мы исходим из принципа максимального упрощения иерархии папок и из принципа «ответственности за файл». Последний принцип означает то, что у каждого файла есть ответственный, и этот ответственный является сотрудником вполне определённого структурного подразделения компании. Значит, этот файл должен создаваться в библиотеке на сайте этого подразделения. Договоры — в договорном отделе, или у менеджеров по продажам, проекты — в отделе проектирования, кадровые шаблоны — в отделе кадров и т.п.

Тут же возникает вопрос: а как получить доступ к этой информации сотрудникам других подразделений? Решается он специальным механизмом нашего решения «СДЦ. Типовой портал». Если какие-то, или большая часть этих документов, являются общедоступными, то такие файлы из библиотеки подразделения автоматически реплицируются в общее хранилище — создаётся их копия «только для чтения». Это обеспечивает специальное приложение (веб-часть) на портале. И уже в этом общем хранилище пользователь ищет информацию, создающуюся в других структурных подразделениях, и которая необходима ему в работе. А для ограничения доступа к «чувствительной» информации, используются группы SharePoint.

spss-01-store

Рис. 1 Общее хранилище документов

2. Структура папок библиотеки подразделения

Упомянутый выше принцип максимального упрощения иерархии означает, что не нужно выдумывать сложную таксономию файлового хранилища. Достаточно в качестве первого уровня иерархии использовать библиотеку на сайте подразделения, внутри библиотеки подразделения создавать папки по годам, а внутри каждого года — папки по направлениям работы подразделения. Внутри направлений обычно создаём папки по контрагентам или темам, но это необязательно. Далее можно вкладывать папки друг в друга как угодно, стараясь избегать многократной вложенности. Если избежать не получается — не страшно, три верхних уровня, подразделение, год и направление, а самое главное – применение поиска SharePoint, не дадут запутаться в дереве папок. Опять же, названия направлений могут быть достаточно свободными, чтобы не загонять пользователей портала в жёсткие рамки. Они складываются интуитивно, исходя из специфики работы подразделения, и могут меняться год от года.

spss-02-dpm

Рис. 2 Направления работы Департамента продаж и маркетинга в 2015 г.

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

Отдельно следует упомянуть о возможности облегчённого помещения файла в библиотеку на узле подразделения. Механизмы SharePoint позволяют настроить библиотеку так, что к ней предоставляется доступ из интерфейса «проводник». Это значит, что для своих, часто используемых папок, пользователь может создать ярлыки на рабочем столе, и перетаскивать файлы прямо в них, с той же лёгкостью, с которой он сохраняет документы на сетевом хранилище, или у себя на компьютере. В сочетании с поиском по содержимому, такой механизм даёт огромное преимущество хранилищу на SharePoint перед другими.

spss-04-contracts

Рис. 3 Библиотека договоров 2015 г. в интерфейсе «проводник»

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

3. Структура имени файла

Мы предлагаем использовать файлы с именами определённой структуры. Нотацию этой структуры можно представить в следующем виде:

ТЭГ-[описание содержимого]-ГГММДД-[версия].расширение

Разберём эту нотацию более подробно. Обычно поле ТЭГ – это аббревиатура темы, к которой относится документ, а ГГММДД — дата его последнего редактирования, записанная в обратном порядке. В качестве тэга можно использовать сокращение от наименования контрагента, ведущегося проекта, или вида операционной деятельности. Например: ЕГРЮЛ-СДЦ-151023.pdf, или СДЦ-Яндекс-акт-150930.rtf.

Дату мы помещаем в название документа с двумя основными целями. Во-первых, для сортировки внутри папок файлов близких названий, но разных дат (например, разные документы от одного поставщика: ИП-МТС-150831-счет.tif, ИП-МТС-150930-счет.tif). А во-вторых — для того, чтобы пользователь с одного взгляда на название, мог определить, когда был отредактирован документ.

Вообще, сама цель такого «развесистого» именования файла- дать возможность получить максимальное представление о содержимом с одного взгляда на название, не открывая самого файла в соответствующем ему приложении. Сравните имена СДЦ-РКТ-договор модернизация-150815.docx, и Договор05.docx. Согласитесь, что первое наименование более удобно (при условии, что пользователь знает, что РКТ- это заказчик ООО «Ракета», а это запомнить не трудно), и сильно экономит время при работе с группами файлов.

Теперь мы и добрались до поля «описание содержимого» — оно должно в телеграфном стиле: кратко, но максимально полно, описывать содержание файла. То есть должно быть не слишком длинным, чтобы не занимать пол-экрана, но вместе с тем достаточно понятным, чтобы понять, что содержится в файле. Поле «версия» обозначает номер редакции внутри даты — когда один и тот же файл редактируется несколькими людьми. Тут мы не используем механизм версионности SharePoint, поскольку файл может передаваться между контрагентами по электронной почте.

spss-04-astrahan

Рис. 4 Файлы, относящиеся к договору №1504-131 на реализацию АИСВ Астрахань

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

Заключение

Таким образом, ключевыми свойствами описанных выше методик являются: использование значащих имен файлов, их хранение в библиотеках подразделений компании на SharePoint с простой структурой, и репликация в общедоступный раздел. Применяя эти методики, мы получаем хранилище файлов с лёгким расширением структуры, с быстрым размещением, и мгновенным извлечением файлов. А это как раз те функции, которыми обладает идеальное хранилище.

Дополнительные материалы

  1. O бесплатной версии портала на Microsoft SharePoint Foundation.
  2. Корпоративный портал «СДЦ. Типовой портал».
  3. Доклад «СЭД и хранилище документов на Microsoft SharePoint» (.pptx).
  4. Статья «Microsoft SharePoint и системы электронного документооборота».