 |
Дорастут ли российские СЭД до ECM?
29.08.11
Современные СЭД прошли эволюционный путь развития от простейших систем регистрации и учета документов до многофункциональных платформ управления документами и оперативной деятельностью предприятия на основе средств автоматизации бизнес-процессов, организации коллективной работы и других технологий. Чтобы перейти на новый уровень, наши СЭД должны реализовать гораздо более широкий набор технологий 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, а конвергенция этих классов в нечто общее при их различиях историй развития управленческой культуры разных стран".
Однако положительная тенденция прослеживается. Разработчики уже осознали, что хорошая проработка на уровне архитектуры избавляет от многих проблем в будущем и наши СЭД уже движутся в этом направлении.
Технология ECM успешно зарекомендовала себя во многих прикладных решениях
- Управление договорами на всех стадиях (согласование, подписание и исполнение);
- Управление качеством;
- Взаимодействие с клиентами (техподдержка, жалобы и рекламации, запросы услуг, оформление сделок, ведение клиентских досье, и т. д.);
- Проектная деятельность любого направления;
- Управление продажами (подготовка коммерческих предложений, участие в конкурсах);
- Управление закупками (сбор, согласование и консолидация заявок, подготовка конкурсной документации, проведение конкурсов);
- Управление финансовой документацией (учет и согласование входящих и исходящих счетов, интеграция с финансовой и ERP-системой);
- Управление заявками (получение материальных ценностей, услуг, пропусков, и пр.);
- Создание электронных архивов различной специфики (обычные либо исторические документы, проектно-сметная или конструкторская документация, фото, аудио и видео архивы и т.д.)
Станислав Макаров
От управления документами к управлению организацией
Сейчас мы все больше говорим, что СЭД должны использоваться для комплексной автоматизации процессов документационного обеспечения управления (ДОУ), причем акцент смещается от учета движения документов в сторону поддержки принятия управленческих решений и обеспечения оперативного руководства компанией.
Такова логика развития систем: на первом этапе СЭД обычно использовалась для автоматизации канцелярий, затем подключались делопроизводители в подразделениях, потом руководители разных уровней. Сегодня мы подходим к тому, что работать в системе будут все сотрудники предприятия, от директора до специалиста в подразделении. Это дает новые возможности по организации коллективной работы и поддержки сквозных управленческих процессов.
Компании-разработчики следуют этим рыночным трендам, которые отражают стремление заказчиков получить от внедрения электронного документооборота более значительный эффект, чем банальная автоматизация функций делопроизводства. В качестве объекта автоматизации теперь могут выступать любые бизнес-процессы, связанные с интенсивной работой с документами и активным взаимодействием сотрудников. Очень востребованной на рынке является интеграция с 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, а конвергенция этих классов в нечто общее при их различиях историй развития управленческой культуры разных стран".
Однако положительная тенденция прослеживается. Разработчики уже осознали, что хорошая проработка на уровне архитектуры избавляет от многих проблем в будущем и наши СЭД уже движутся в этом направлении.
Технология ECM успешно зарекомендовала себя во многих прикладных решениях
- Управление договорами на всех стадиях (согласование, подписание и исполнение);
- Управление качеством;
- Взаимодействие с клиентами (техподдержка, жалобы и рекламации, запросы услуг, оформление сделок, ведение клиентских досье, и т. д.);
- Проектная деятельность любого направления;
- Управление продажами (подготовка коммерческих предложений, участие в конкурсах);
- Управление закупками (сбор, согласование и консолидация заявок, подготовка конкурсной документации, проведение конкурсов);
- Управление финансовой документацией (учет и согласование входящих и исходящих счетов, интеграция с финансовой и ERP-системой);
- Управление заявками (получение материальных ценностей, услуг, пропусков, и пр.);
- Создание электронных архивов различной специфики (обычные либо исторические документы, проектно-сметная или конструкторская документация, фото, аудио и видео архивы и т.д.)
Станислав Макаров
