Управление архивами документов традиционно является одной из ключевых составных частей всего комплекса задач управления корпоративным контентом (ЕСМ). До недавнего времени оно по своей актуальности явно уступало тематике автоматизации документно-ориентированных бизнес-процессов. Однако в последние годы эксперты отмечают быстрый рост интереса заказчиков именно к задачам электронных архивов. Предвосхищая и откликаясь на эти изменения в потребностях рынка компания «Логика Бизнеса» пополнила линейку своих ECM-продуктов специализированным решением «Логика: АРХИВ» на платформе Alfresco/МСВСфераИнфооборот. О том, зачем понадобилось создание такого ПО и какие задачи могут решать с его помощью корпоративные клиенты, рассказывает руководитель продукта «Логика: АРХИВ» Сергей Нигматуллин.
Давайте для начала выясним, для каких задач предназначен ваш новый продукт «Логика: АРХИВ»? Из докладов на ECM-конференциях представителей компании «Логики Бизнеса» складывается впечатление, что реализуемые вами проекты в этом направлении — это не совсем то, что подразумевают классические документоведы.
В понятийной терминологии действительно есть некоторая путаница и недопонимание, под термином «архив» в разных контекстах подразумевается порой весьма различное содержание. Сразу уточню, что, говоря о сфере применения нашего продукта, мы обычно употребляем термин «оперативный архив» или даже «хранилище документов».
Давайте посмотрим на этот вопрос с точки зрения жизненного цикла документа, в котором обычно выделяется два основных этапа: оперативный, когда документ активно используется в текущих деловых процессах, и архивный, когда документ уже не нужен для регулярного применения, но может потребоваться в случае необходимости. Обратите внимание, что чести перейти во второй жизненный этап удостаиваются далеко не все документы, а только важные, время жизни которых обычно регламентируется внешними для данной организации нормативными актами. Большинство же документов после окончания оперативного этапа просто уничтожаются, во всяком случае, так было для бумажных документов, хранить которые — дорогое удовольствие.
Понятно, что к системам оперативной работы с документами (это и есть хорошо знакомые СЭД) и к архивным системам предъявляются различные, подчас диаметрально противоположные требования, поэтому в них обычно используют принципиально разные архитектуры, технологии и пр. В очень упрощенном виде можно сказать, что с СЭД работает большое число пользователей самых разных профессий, и тут важна скорость работы с документом, а к классическим архивам имеют доступ единицы профессионалов-архивистов, и тут главной функцией является недорогое, но надежное хранение. Более того, такими архивами занимаются на крупных предприятиях специальные подразделения, и даже существует отдельная архивная отрасль со своими организациями.
Но понятно, что задача хранения документов и создания соответствующих хранилищ (которые часто называют «оперативными архивами») актуальна и для активного этапа жизненного цикла документов. Вот как раз для организации таких оперативных архивов и предназначен наш новый продукт.
Но если речь идет об оперативной работе с документами, то почему для этого нельзя использовать уже давно существующие решения, которые имеют соответствующие хранилища документов?
Прежде всего, давайте вспомним, что в значительной степени тематика СЭД в России исторически появилась в связи с, в том числе, необходимостью автоматизации организационно-распорядительного документооборота. ОРД — это, конечно, важная часть управления организацией, но на нее все же приходится весьма незначительная доля корпоративного контента, причем довольно простого по структуре, в основном это текстовые, относительно небольшие документы — приказы, распоряжения, письма... И еще ОРД имеет дело с документами с относительно коротким сроком активного использования, который почти никогда не превышает пяти лет.
В тоже время существуют документы, которые находятся в активном обращении по
Важный момент заключается в том, что такие документы рождаются не только в СЭД, точнее сказать, что они рождаются в разных системах, используемых в организации, — EPR, CRM, САПР, финансовых и пр. Каждая из этих систем имеет какое-то собственное хранилище документов, которое используется именно данной системой для решения определенных задач. Но когда компания, автоматизировав отдельные участки своей деятельности (канцелярию, финансовый блок, отдел продаж, конструкторское бюро), выходит на более высокий уровень управления, то появляются задачи, для решения которых нужны документы из разных информационных систем. То есть появляется необходимость создания единого интегрированного электронного архива, которым нужно управлять совсем уже другими специализированными инструментами.
За последние годы круг задач по управлению документами вышел далеко за пределы традиционного ОРД. И дело тут не только в резком росте объемов хранилищ документов. Изменился также состав задач, изменились требования к функциональным возможностям таких хранилищ. Если в случае СЭД мы имеем дело с процессно-ориентированным системами, которые создаются, отталкиваясь от бизнес-процессов, и в которых роль хранилищ является второстепенной, то задачи кейс-менеджмента требуют использования документно-ориентированной архитектуры, и такие системы «пляшут» как раз от архива, причем формируемого из разных источников, документов.
Но тогда нужно вспомнить о классических ECM-платформах, базовая идея которых во многом основывается на том, что нужно сначала просто обеспечить сбор и хранение контента, а уже потом использовать его для тех или иных производственных нужд.
Чем отличаются СЭД от ECM? Совсем не только функционалом, а в первую очередь тем, что СЭД — это прикладное решение, используемое для выполнения задач определенного класса, а ECM — платформа, на базе которой создается такое решение. Первое в идеальном случае может быть установлено и настроено самим заказчиком, второе — это все же инструмент разработчика, как правило, специализированной ИТ-компании, имеющей соответствующие квалификацию и компетенцию. Разумеется, преобразование СЭД-решения в конкретную информационную систему у конкретного заказчика — это не просто процедура ее инсталляции с дистрибутива (хотя, вариант «СЭД из коробки» для типовых задач в небольшой организации вполне возможен), но при этом необходимо произвести настройку нужного функционала. Адаптация параметров выполняется с минимальным объемом программирования. В случае использования платформ процедура создания конкретной системы намного сложнее и обычно требует серьезного программирования. Чтобы избавить заказчика от этого бремени, но сохранить преимущества платформенного подхода (масштабируемая архитектура, возможность построения широкой функциональности на единой технологической базе) «Логика Бизнеса» разработала полноценные продукты на собственной ECM-платформе, в том числе «Логику: АРХИВ».
Как появился это продукт?
Тут стоит сказать, что «Логика Бизнеса» — компания, которая занимается и разработкой прикладных решений, и внедрением ECM-решений у заказчиков. При этом логика появления прикладных решений очень простая. Если у нас нет готового продукта для конкретного заказчика, то мы дорабатываем платформу под него. По мере того, как реализуемые проекты начинают складываться в определенный класс задач, и по мере получения нами соответствующей отраслевой экспертизы, формируется понимание, каким должно быть тиражируемое прикладное решение. Именно таким образом у нас формируется линейка продуктов, которая выглядит так: «Логика: СЭД», «Логика: ФИНДОК», «Логика: ТЕХДОК», «Логика: ЮЗЭДО», «Логика: ДОСЬЕ» и «Логика: АРХИВ». Появлению последнего предшествовала реализация большого числа проектов по созданию архивно-ориентированных систем для предприятий различных отраслей — банковско-финансовой, телекома, нефтегаза, госсектора и др.
Но все же, зачем нужно создавать отдельный прикладной продукт для создания архивов, если поддержка хранилищ документов является штатной функцией ECM-платформы?
Во-первых, у организаций все чаще возникает потребность в создании единой системы хранения документов, а не использовании набора отдельных хранилищ. Создание такой единой системы — весьма сложная задача. Она должна объединить самые разные документы, в том числе бумажные и электронные, поступающие из различных информационных систем, т. е. нужны средства интеграции с этими системами, причем двухсторонней, чтобы и эти системы могли иметь доступ к документам хранилища.
Дополнительной задачей является сканирование и оцифровка бумажных документов. Учитывая то, что мы имеем дело с большими входными потоками документов, нужно максимально использовать автоматические методы их атрибутирования и классификации. При вводе нужно исключить избыточную и противоречивую информацию, ведь одни и те же документы могли ранее вводиться в разные системы. Поскольку хранилище занимает большие объемы, то нужно реализовать многоуровневую иерархическую архитектуру. А для большого числа пользователей особенно актуален вопрос обеспечения конфиденциальности и управления правами доступа.
Во-вторых, такие единые системы хранения документов нужны не сами по себе, чтобы просто все держать в одном месте, а для решения конкретных деловых задач и поддержки конкретных бизнес-процессов. Соответственно нужны средства создания специализированных рабочих мест, развитые возможности поиска, причем не только полнотекстового, но и интеллектуального, с учетом контекста конкретной производственной задачи.
И наконец, еще один важный момент: для эффективного решения практических задач нужно не просто хранить документы как независимые объекты (как в обычной файловой системе), а проводить их группировку и структурирование под те или иные бизнес-задачи, обеспечивать формирование связей документов между собой и в контексте их последующего использования. Например, инженеру нужна вся документация по конкретному оборудованию, а руководителю проекта — комплекс договорной, финансовой и прочей документации, относящейся к его проекту. Причем это нужно делать как в процессе ввода документов (это полезно, если у вас уже сформулирована производственная задача), так и после того, как документы уже помещены в хранилище (когда у вас появилась новая задача).
Если попробовать кратко сформулировать, чтобы вы сказали заказчикам — почему им нужно использовать именно ваше решение для создания оперативных архивов?
В первую очередь я назову возможность быстрой реализации такого проекта, по нашему опыту, это занимает от трех до шести месяцев, причем основное время уходит не на развертывание системы, а на подготовительную консалтинговую работу для постановки целевых задач. Внедрить продукт своими силами сможет не каждая организация, но поддерживать и развивать при желании можно самостоятельно. Для этого «Логика: АРХИВ» имеет развитые средства простой настройки под задачи заказчика без использования программирования, возможность создания собственных специализированных рабочих мест.
Во вторую очередь, как я уже сказал выше, наша версия архива имеет уникальную для своего сегмента возможность связывать документацию на уровне объектов — сделок, зданий, оборудования, сотрудников. Эта и другая функциональность, например возможность разгрузить базы данных сторонних решений, делают «Логику: АРХИВ» интересным продуктом для заказчика. При том, что он обладает всеми преимуществами enterprise-решений: легко масштабируется, имеет открытую архитектуру, гибок в настройках.
С чего нужно начинать подобные архивные проекты?
Для начала заказчику нужно четко понять, зачем ему нужен такой архив, какие производственные задачи он собирается решать с его помощью. Исходя из этого определяется, какие категории документов нужно туда помещать, как их группировать, организовывать взаимосвязи. Второй важный момент — создание единого набора нормативно-справочной информации, поскольку обычно в разных системах используют собственные НСИ, их нужно унифицировать.
И чисто технологический вопрос: с какими операционными системами и СУБД может работать ваш продукт?
Практически со всеми популярными, тут заказчик может выбирать то, что ему лучше подходит, что он лучше знает и что уже использует.
ПОДГОТОВЛЕНО ITWEEK EXPERT
