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