Современные СЭД
прошли эволюционный путь развития от простейших систем регистрации и
учета документов до многофункциональных платформ управления
документами и оперативной деятельностью предприятия на основе
средств автоматизации бизнес-процессов, организации коллективной
работы и других технологий. Чтобы перейти на новый уровень, наши СЭД
должны реализовать гораздо более широкий набор технологий ECM,
которые сегодня необходимы для полноценного управления
неструктурированным контентом. Справятся ли они с этой задачей?
От управления документами
к управлению организацией
Сейчас мы все больше говорим, что
СЭД должны использоваться для комплексной автоматизации процессов
документационного обеспечения управления (ДОУ), причем акцент
смещается от учета движения документов в сторону поддержки принятия
управленческих решений и обеспечения оперативного руководства
компанией.
Такова логика развития систем: на
первом этапе СЭД обычно использовалась для автоматизации канцелярий,
затем подключались делопроизводители в подразделениях, потом
руководители разных уровней. Сегодня мы подходим к тому, что
работать в системе будут все сотрудники предприятия, от директора до
специалиста в подразделении. Это дает новые возможности по
организации коллективной работы и поддержки сквозных управленческих
процессов.
Компании-разработчики следуют этим
рыночным трендам, которые отражают стремление заказчиков получить от
внедрения электронного документооборота более значительный эффект,
чем банальная автоматизация функций делопроизводства. В качестве
объекта автоматизации теперь могут выступать любые бизнес-процессы,
связанные с интенсивной работой с документами и активным
взаимодействием сотрудников. Очень востребованной на рынке является
интеграция с ERP-системами, в первую очередь с SAP. Тот вендор ECM
или СЭД, который сумеет сегодня предложить лучшее решение для
интеграции служб электронного документооборота в среду SAP, имеет
наиболее высокие шансы стать лидером рынка.
По словам Александра Бейдера,
директора по развитию бизнеса компании "ТерраЛинк", вопрос об
интеграции СЭД c ERP имеет приблизительно такую же историю, как и
событие отделения воды от суши. Как только сформировались системы
упомянутых классов, со своими характерными признаками и свойствами,
сразу же встал вопрос об обеспечении финансово-хозяйственного учета
функциональностью работы с первичными документами.
По мнению эксперта, сегодня
наиболее часто задача интеграции решается на самом базовом уровне, а
именно на этапе использования справочников ERP для атрибутирования
документов и прикрепления их образов к записям транзакций. Эта
задача обычно решается на проектном уровне с использованием штатных
сервисов вендора СЭД. Результатом такого рода ограниченного подхода
интеграции является, во-первых, необходимость непрерывного
реплицирования справочников и мастер-данных в базу данных СЭД,
во-вторых, необходимость для пользователя постоянно переключаться из
интерфейса ERP в интерфейс СЭД и наоборот. Кроме того, этот подход
не обеспечивает синхронизацию политик доступа в СЭД и ERP, а также
возможность реализации сквозных бизнес-процессов.
"Вот почему все более явно
осознается сегодня потребность пользователей получать бизнес-контент
непосредственно в контексте работы с ERP-системой, иметь дело
одновременно и реквизитами транзакций, и с образами первичных
документов. Другими словами, символом времени сегодня является не
интеграция СЭД с ERP, а именно, как указанно в тексте, интеграция
СЭД в ERP", - подводит итог г-н Бейдер.
По мысли Натальи Храмцовской,
важно обеспечить интеграцию и взаимодействие СЭД с информационными
системами, поддерживающими основную деловую деятельность
организации, включая системы бухгалтерского, кадрового и налогового
учета, системы управления веб-сайтами организации. И – что особенно
актуально и важно для государственных органов – с системами МЭДО и
СМЭВ.
Контроль исполнения также
становится более оперативным и прозрачным. Возможно, отделы контроля
в их традиционном понимании отойдут в прошлое. Ведь их существование
в качестве обособленного подразделения обусловлено скорее
трудоемкостью сбора и регулярного обновления информации о статусе
задач и поручений. Если эти функции возьмет на себя система (а она
уже сейчас в состоянии это сделать), то контроль могут осуществлять
сами заинтересованные лица — инициаторы поручений и руководители
подразделений.
Александр Бейдер не согласен с
этим мнением: "Мне кажется, что это иллюзия. Необходимо
подразделение, которое профессионально занимается задачами
методологии контроля, формирует показатели эффективности работы
сотрудников, анализирует результаты контроля, подготавливает
рекомендации для руководства, и поддерживает изменения системы
контроля в целом в соответствии с изменениями бизнес-потребностей и
целей развития компании".
Какой должна быть
идеальная СЭД?
Наталья Храмцовская, эксперт
компании ЭОС, полагает, что идеальная современная СЭД – это
ECM-система с хорошим набором функциональных возможностей, способная
интегрироваться с различными деловыми ИС организации. Модуль
управления документами у такого решения соответствует требованиям
признанных стандартов, таких, как MoReq2, и обеспечивает, помимо
удобной оперативной работы, также и долговременную сохранность
целостных и аутентичных электронных документов. Кроме того, СЭД
должна управлять как электронными, так и неэлектронными документами
организации.
Этот тезис поддерживает и Вадим
Ипатов, заместитель генерального директора по развитию бизнеса
компании "ИнтерТраст". По его мнению, идеальная СЭД должна
обеспечивать электронное документирование деятельности организации в
ходе взаимодействия людей и информации в контексте бизнес-процессов.
Оно должно быть основано на правилах (политиках, регламентах,
стандартах), принятых в организации (в том числе, соответствующих
международным, государственным, отраслевым стандартам) в интересах
повышения эффективности деловых процессов, качества и
результативности управленческих решений, обеспечения контроля и
прозрачности их исполнения.
Новые бизнес-задачи для
СЭД
СЭД нового поколения должны
обладать расширенной функциональностью, чтобы использовать их для
решения различных бизнес-задач, существенно расширяя границы ее
применения за пределы классического делопроизводства.
Наталья Храмцовская полагает, что
организации особенно заинтересованы в оптимизации своих основных
деловых процессов, и в тех случаях, когда эти процессы целиком или в
значительной степени представляют собой обработку документов и
информации (например, договорная деятельность), для этой цели может
использоваться СЭД. Однако следует иметь в виду, что, хотя
"оптимизация документопотоков и бизнес-процессов" может
осуществляться с помощью СЭД, принципиальные решения (делегирование
полномочий, административные регламенты и т.п.) принимаются
независимо от нее.
Современная платформа электронного
документооборота и автоматизации бизнес-процессов может быть
эффективно применима во все отраслях деятельности, где требуется
интенсивная работа с документами и человеческий фактор в
значительной мере влияет на результат процесса. Новые СЭД должны
либо уметь быстро сконструировать очередное бизнес-решение из
стандартных блоков, причем без программирования, либо предоставлять
готовые, максимально проработанные, типовые решения в одной или
нескольких областях и специализироваться на этих задачах.
Универсальность всегда вредит специализации, это известный факт.
Решая эти разнообразные
бизнес-задачи, наши СЭД волей-неволей реализуют и новые функции, и
перейдут к новым архитектурам. Зрелость достигается не за счет
только лишь проведения НИР, обязательно нужно накопить практический
опыт. А на это нужно время.
Александр Бейдер сожалеет о том,
что такой переход к новым архитектурам означает тотальную переделку
продукта, потерю стабильности работы и более чем болезненный переход
между выпускаемыми версиями. По его мнению, это главная проблема
большинства российских разработок бизнес-приложений, и не только в
области электронного документооборота.
У западных вендоров сейчас есть
технологическое преимущество. Но далеко не все заказчики сделают
свой выбор в пользу импортных ECM-платформ, места на рынке хватит и
для отечественных разработок. И можно вполне уверенно сказать, что в
обозримом будущем наши СЭД по своей функциональности и архитектуре
вполне можно будет отнести к классу ECM.
Стать платформой можно
только при наличии зрелой архитектуры
Как любой солдат мечтает
дослужиться до генерала, любая система "мечтает" дорасти до
платформы. Чтобы развиваться дальше и самой задавать новые тренды, а
не подстраиваться под переменчивые пожелания клиентов. Если клиент,
даже очень крупный, например даже сам "Газпром", попросит IBM, EMC,
Microsoft или Open Text что-нибудь доработать в своем базовом
продукте, чтобы лично ему было удобно (а скорее, просто так ему
хочется), то ответ будет вежливым, но отрицательным. Крупные вендоры
не идут на поводу у клиентов. Это не значит, что они их не слушают,
как раз наоборот — многие интересные функции привносятся в платформы
из реальных проектов. Но такие вендоры не выпускают специальных
версий своих продуктов даже для самых именитых клиентов.
У нас ситуация иная. Разработчики
СЭД вынуждены "прогибаться", чтобы получить выгодный заказ. Как
правило, требуемые доработки вносятся непосредственно в исходный код
системы и с этого момента вам приходится поддерживать не одну версию
системы, а две. А потом три, четыре, пять... Смотря сколько крупных
заказчиков удастся вендору заполучить. В мире Open Source такую
ситуацию называют "fork" – "разветвление" проекта. Для поддержки это
точно головная боль.
Об опыте компании "ИнтерТраст"
рассказывает Вадим Ипатов: Система CompanyMedia ориентирована на
крупные территориально распределенные организации со сложной
оргструктурой. Такие компании всегда имеют свои уникальные
требования к построению документооборота, поэтому наши внедрения
обычно включают модификацию тиражируемого продукта. Кроме того,
система часто продолжает развиваться в ходе ее эксплуатации в
организации, опять же отслеживая специфические потребности данного
предприятия. То есть далеко не все изменения и новые функции
получают прописку в тиражируемой редакции системы".
"ДоксВижн" тоже идет на встречу
заказчикам, выполняя доработки "под них", признает Сергей Курьянов:
"Да, мы это делаем. Однако в редких случаях, и на такие вещи нами
поставлены ценовые барьеры. Причем платит клиент не только за
доработку, но и за сопровождение этой доработки. Случаи для нас
единичные и только для очень крупных или стратегически важных
заказчиков.
IBM тоже выполняет заказные
доработки своих продуктов для крупнейших клиентов. Связано это не с
тем, что это недоразвитая компания, а с тем, что она не поддерживает
чисто вендорскую модель бизнеса – прибегает к прямым продажам своих
лицензий и является крупнейшим в мире интегратором, внедряя свои
собственные и чужие продукты".
Однако, по мнению Александра
Бейдера, следует различать две вещи: функциональные требования и
архитектура (принципы построения) системы.
Заказчики обычно не выдвигают (и
не могут выдвигать) требований к архитектуре системы. Они требуют
реализации тех или иных необходимых им задач, отвечающих условиям их
работы.
К сожалению, - продолжает эксперт
– наши разработчики, как правило, не имеют возможности системно
заниматься архитектурой и вносят разнородные прикладные функции в
базовый функционал системы. В этой связи я лично скептически
отношусь к возможности появления в России платформ, соизмеримых по
своей масштабируемости и производительности с продуктами EMC, Open
Text и IBM.
Платформы же отличаются тем, что
их архитектуры проработаны гораздо более тщательно, есть
документированные API на все случаи жизни, и это позволяет строить
решения без модификации исходного кода основного продукта.
Достижение подобного уровня архитектурной зрелости для наших СЭД –
это вопрос времени и инвестиций. Оперативно внести изменения по
запросу клиента проще и быстрее, нежели разрабатывать красивое
архитектурное решение. Понимание этого у всех есть, не всегда
позволяет бюджет и сроки, увы.
Сергей Курьянов, директор по
развитию компании "ДоксВижн", придерживается иного мнения: "На рынке
ECM/СЭД есть место как для "коробок", так и для платформ. Так же как
коробка стремится стать платформой, так и платформа стремится
обрасти коробками приложений. Делать из коробки платформу путем
изменений в архитектуре не нужно, гораздо правильнее "переиздать"
коробку на базе одной из ведущих платформ и получить гибкую
архитектуру "бесплатно". Что касается разделения продуктов на классы
ECM и СЭД, то тут, по нашему мнению, имеет место не "догоняние"
российскими СЭД западных ECM, а конвергенция этих классов в нечто
общее при их различиях историй развития управленческой культуры
разных стран".
Однако положительная тенденция
прослеживается. Разработчики уже осознали, что хорошая проработка на
уровне архитектуры избавляет от многих проблем в будущем и наши СЭД
уже движутся в этом направлении.
Станислав Макаров
CNews.ru