О видах и подвидах СЭДов на SharePoint

Осипов Александр, product manager системы EOS for SharePoint

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

Наиболее популярным трендом последних 2–3 лет является использования платформы Microsoft SharePoint для решения подобных задач.

Если посмотреть на рынок систем автоматизации документооборота на SharePoint в России, то можно насчитать порядка 10–15 решений от разных поставщиков: как от мелких, которые ранее занимались аутсорсингом разработки программного обеспечения и созданием корпоративных порталов, так и от крупных, специализацией которых на 100% как раз и является разработка СЭД.

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

Виды и подвиды

Если нарисовать схему видов и подвидов решения для автоматизации документооборота на SharePoint, получится следующая картина:

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

Вид первый – с внешним сервером приложений

Разберем первый вид – СЭД на SharePoint с внешними серверами приложений, т. е. с внешней СЭД.

С технической точки зрения выглядит это так: есть некая внешняя СЭД, есть корпоративный портал на SharePoint, на котором подключены специальные веб-части, они подключаются к внешней системе и берут оттуда данные, т. е. работают как некий шлюз. Фактически на самом портале ничего не происходит, вся работа ведется во внешней СЭД.

Основной и большой минус подобного подхода – система сложна и во внедрении, и в поддержке, и в последующей доработке ее функционала, так как кроме настроек SharePoint придется проводить основные настройки именно на внешней СЭД.

Соответственно придется задействовать разных специалистов: не только SharePoint-специалистов, но еще и специалистов, которые разбираются во внешней СЭД, что, согласитесь, увеличивает и стоимость внедрения, и стоимость последующей поддержки. Более того, любой технический специалист понимает, что чем больше систем или разных шлюзов задействовано, тем выше риски, больше вероятность сбоя. При таком подходе требования к серверной архитектуре также увеличиваются как минимум в 2 раза. Кроме того, подобные системы не являются кроссбраузерными и поддерживают работу клиентов лишь на Internet Explorer.

На текущий момент систем такого вида не так много, их выпустили два крупных вендора СЭД как дополнение к своим основным системам. По понятным причинам популярность подобные решения на рынке так и не нашли.

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

Но прежде чем перейти к ним, хотелось бы затронуть не очень приятный для многих момент – производительность самой платформы Microsoft SharePoint 2010.

О производительности SharePoint

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

Но нагрузки на корпоративный портал и на СЭД все-таки сильно отличаются. В СЭД сотрудники создают новые документы, система проверяет права доступа, запускает одновременно несколько процессов по одному документу, пользователи выполняют назначенные им задачи, используют поиск по документам и пр. А увеличение объемов хранимых в системе данных с течением времени только увеличивает общую нагрузку и усугубляет проблемы с производительностью.

Единственный способ решения этой проблемы – серьезная переработка и оптимизация внутренних технологических процедур и компонентов платформы SharePoint, используемых в рамках СЭД.

Вид второй и его подвиды

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

Условно их также можно поделить на два подвида: корпоративные порталы с функцией автоматизации ряда задач по документообороту и коробочные полнофункциональные СЭД.

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

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

В таких решениях в качестве workflow чаще всего используется система Nintex, которая кроме своего основного преимущества – проектирования рабочих-процессов в графическом редакторе – имеет целый ряд недостатков:

a. Во-первых, стоимость, порядка $10 000 версии 2010 Standard Server или $20 000 за Nintex Workflow Enterprise Server. То есть к конечной стоимости решения необходимо прибавить еще немалую стоимость Nintex.

b. При проектировании сложных процессов все-таки потребуется программирование, пусть и не много, но некоторые функции, например, в части отображения тех же кнопок запуска процессов, можно реализовать только путем программирования.

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

d. Nintex в отличие от самой платформы SharePoint 2010 работает только под Internet Explorer.

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

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

Основное отличие – в подходе к реализации системы и решении вопроса производительности.

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

Ядро данного решения фактически на 90% состоит из собственной разработки и лишь на 10% использует базовые возможности SharePoint (авторизация, хранилище, API). Такой подход, безусловно, положительно сказался на быстродействии системы, но плохо сказался на

o возможностях доработки системы собственными силами заказчика. Фактически любая серьезная доработка потребует привлечение разработчика, так как от стандартного SharePoint там осталось лишь 10%.

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

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

Вторая система из данного подвида использует совершенно другой подход к решению поставленной задачи. Эту систему по праву можно назвать полнофункциональной СЭД, так как она была разработана одним из крупнейших российских игроков рынка СЭД при участии Microsoft. Система изначально создавалась на основе требований российского законодательства и требований ГСДОУ.

Что касается вопроса производительности платформы SharePoint для задач СЭД, то разработчик данной системы пошел по собственному пути соблюдения баланса между двумя описанными выше «крайностями». Это означает, что функции, эффективно реализованные в самой платформе, были оставлены без изменений на стороне SharePoint. К ним, прежде всего, относятся: поля карточек, бизнес-процессы (workflow), разрешения на доступ, гибкие настройки списков и библиотек и др. Помимо прочего это также позволяет сохранить легкость перехода на новые версии платформы Microsoft.

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

Именно поэтому данная система на протяжении нескольких лет заслуженно является самой популярной СЭД на SharePoint в России и пользуется активным интересом как среди коммерческих организаций, так и государственных, для которых особенно важно соблюдение требований ГСДОУ и автоматизация полного жизненного цикла документа.

Это система EOS for SharePoint, разработчиком которой является лидер отрасли электронного документооборота компания ЭОС («Электронные Офисные Системы»), знакомая многим по другим своим решениям в области СЭД.