В предыдущих статьях нашего цикла речь шла об анализе того, что из себя представляет современная корпоративная СЭД: какие задачи она решает и какие существуют подходы к ее реализации в организации. В данной статье мы подведем итоги предыдущих публикаций и сформулируем контекст дальнейшего обсуждения, который будет посвящен детальному анализу функциональности СЭД. Прежде всего, мы выделим некоторые определения термина СЭД, которые естественным образом вытекают из предыдущего обсуждения. Нужно отметить, что данные определения пока не являются общепризнанными, но нам они представляются разумными и достаточно естественными, и, самое главное, они позволяют нам двигаться дальше в наших рассуждениях и не противоречат сложившейся практике использования понятия СЭД. Итак, на наш взгляд можно выделить следующие определения:
- СЭД (корпоративная СЭД) — набор интегрированных приложений, автоматизирующих процессы обработки документов в компании. Приложения, реализованные в рамках СЭД, могут модифицироваться, их набор может расширяться.
- Приложение СЭД — программный комплекс, автоматизирующий отдельный процесс обработки документов в рамках СЭД, логически выделяемый относительно других задач обработки документов в компании.
- Платформа СЭД — инфраструктура и техническая архитектура для реализации приложений СЭД, обеспечивающая их независимое использование, интеграцию, упрощение создания и сопровождение.
Нужно отметить, что последнее из данных нами определений очень близко определению ECM компании Gartner. В контексте данных выше определений терминов СЭД, по крайней мере в нашем понимании, базирующемся на опыте реальных внедрений, практически идентичен пришедшему с Запада термину ECM (Enterprise Content Management). В этом контексте можно воспринимать русскоязычный термин СЭД как полный эквивалент англоязычному термину ECM. Определения, данные выше, создают достаточно хорошую предпосылку для создания модели СЭД в компании, а также возможность анализа использования различных видов программного обеспечения для реализации отдельных компонентов инфраструктуры СЭД и конкретных приложений на ее базе.
Однако существует еще один контекст использования терминов СЭД и ECM, который вносит основную путаницу в интерпретацию двух этих понятий, а именно — наименование конкретного класса программного обеспечения, которое используется в качестве базового компонента для реализации инфраструктуры СЭД и, соответственно, приложений на ее базе. В этом контексте термины СЭД и ECM отнюдь не идентичны. Под ПО класса СЭД подразумеваются продукты отечественного производства — “Дело”, “Директум”, DocsVision и целый ряд других систем, исторически выросших из приложений, решающих задачи автоматизированной поддержки директивного управления. К ПО класса ECM относятся такие продукты, как Documentum, OpenText, FileNet и другие продукты, выросшие из систем класса DMS-средств создания корпоративных архивов документов. Данные классы ПО имеют существенное различие как в части архитектурных реализаций, так и в части конечной прикладной функциональности, однако имеют и много общего, что позволяет оба этих класса ПО рассматривать как потенциальную основу для создания инфраструктуры СЭД. Нужно сказать, что существуют примеры их совместного использования в рамках единой СЭД, где каждая из подсистем решает те задачи, для которых она лучше адаптирована. Правда, ситуации эти характерны в основном для достаточно крупных организаций. Краткий анализ различий этих классов ПО мы сделали в статье № 2 данной серии публикаций. Нужно также отметить, что в качестве основы для создания инфраструктуры СЭД могут быть выбраны и другие типы ПО, например IBM Lotus Notes, который не относится ни к одному из выше описанных классов ПО, но вполне успешно используется для создания на его базе приложений СЭД.
Итак, после проделанного нами достаточно краткого вступления в тему (которое заняло у нас без малого шесть статей) можно переходить к конструктивной части, то есть сформировать методологию создания корпоративной СЭД. Для этого прежде всего необходимо определиться с требованиями к инфраструктуре СЭД, на базе которой мы и будем строить нашу систему. Так как наш цикл публикаций посвящен выработке общей методологии внедрения, а не ориентирован на пользователей какой-либо конкретной системы (класса ПО), то мы будем рассматривать некую общую идеальную инфраструктуру современной СЭД, на примере которой рассмотрим ее функциональные подсистемы. Этому мы посвятим нескольких ближайших публикаций. Идеальная инфраструктура будет реализовать весь набор функциональности, которая потребуется нам для создания на ее базе самых разнообразных приложений СЭД, кратко рассмотренных нами ранее, причем она же будет обеспечивать и все необходимые уровни интеграции этих приложений в единый комплекс, а также обеспечит нам оптимизацию стоимости владения в условиях развития системы. Конечно, ни одна система, которую мы можем приобрести на рынке, после инсталляции не обеспечит нам соответствия всем описанным далее требованиям, однако мы по мере возможности и достаточно кратко будем иллюстрировать то, как та или иная подсистема реализует соответствующую группу требований.
Итак несколько замечаний по поводу “идеальности” рассматриваемой платформы СЭД:
- идеальная платформа реализуется как набор относительно независимых, но хорошо интегрируемых сервисов и подсистем в полном соответствии с идеологией сервисно-ориентированной архитектуры. На практике при реализации СЭД на базе реального набора конкретного ПО такое разделение не всегда будет соответствовать архитектуре конкретной системы;
- наша идеальная платформа СЭД реализует полный набор функций соответствующих подсистем. На практике ни одна из представленных на рынке систем не обеспечивает поддержку всех перечисленных в обзоре функций. Так что при внедрении реальной системы нам надо быть готовыми к ограничениям функции нашей реальной инфраструктуры, относительно идеальной, либо вкладывать средства, порой достаточно значительные, в ее доработку для компенсации этих ограничений;
- при рассмотрении функциональности платформы СЭД в ближайших статьях мы не будем рассматривать факторы, формирующие стоимость владения реальным комплексом приложений, создаваемых на его базе.
При формировании модели инфраструктуры СЭД мы выделили следующие функциональные подсистемы:
- подсистема электронного архива документов;
- подсистема картотеки или учета документов, в которой реализуется основная бизнес-логика правил учета документов;
- средства маршрутизации документов и автоматизации контроля их исполнения;
- средства автоматизации бизнес-процессов обработки документов;
- подсистема навигации, классификации, поиска и управления знаниями;
- средства поддержки управление записями;
- подсистема безопасности.
В отдельный блок мы также выделили системные требования к инфраструктуре СЭД, к которым отнесли:
- средства обеспечения масштабируемости системы;
- средства интеграции СЭД c другими компонентами информационной системы организации;
- средства для расширения функциональности и кастомизации приложений, созданных на ее базе.
Получившаяся модель оценки функциональности СЭД уже довольно давно эксплуатируется при рассмотрении сравнения функций различных видов ПО в нашей предметной области. В нашей интерпретации “роза ветров” идеальной инфраструктуры СЭД будет выглядеть следующим образом (см. рис. 1). Естественно, на практике любая реальная система будет обеспечивать неравномерное соответствие идеальному объему по разным группам функций.
То есть схема ее соответствия идеальной модели будет выглядеть примерно так, как это выглядит на рис. 2. Конечно, профили реальных систем для построения СЭД, которые нам предлагает рынок, будут существенно различаться. Зависеть это будет, безусловно, и от стоимости, и, соответственно, от функциональной мощности системы, от ее класса, истории создания системы и степени ее “современности”. В наши задачи не входит построение профиля для конкретных систем. Это было бы слишком громоздко для выбранного нами формата обсуждения, и вряд ли мы в состоянии сделать это достаточно объективно, так как порой отсутствует возможность ознакомиться даже с подробной документацией на систему и ее рабочей демоверсией, без ее приобретения. Да, наверное, данная задача и не должна решаться одним из производителей, представляющих на рынке собственную систему данного класса, но предложенная нами модель и дальнейшее описание функций, как нам представляется, позволят получить некоторый общий базис для сравнения довольно сложно сравниваемых между собой классов ПО, а также определенную методологическую базу для выбора той или иной системы либо их комплекса для решения задачи развертывания в организации инфраструктуры СЭД. Некоторые соображения о том, какие имеются критерии принятия решения по выбору конкретной системы, мы изложим в последних статьях нашего цикла, когда будем говорить собственно о методологии внедрения.
Прежде чем перейти к рассмотрению функциональных подсистем, мы, забегая вперед, опишем варианты ПО, на базе которого создаются современные инфраструктуры СЭД в отечественных организациях. Данные сведения мы приводим, исходя из нашего практического опыта, анализа различных источников информации и обсуждений предмета с коллегами по отрасли. В качестве основы развертывания инфраструктуры СЭД в современных условиях используются:
- отечественные СЭД — ПО данного класса представлено достаточно разнообразными системами как по сложности и стоимости, так и по архитектуре реализации. Объединяют их, как мы и отмечали ранее, более глубокая ориентация на конкретные прикладные задачи, возникающие в отечественных компаниях в области автоматизации процессов обработки документов, и наличие готовых прикладных решений на их базе;
- западные ECM — системы данного класса концентрируются на задачах развертывания базовой инфраструктуры СЭД и единого электронного архива компании, а также на решении прикладных задач , традиционных для западного рынка автоматизации документооборота;
- Microsoft SharePoint — данная система интегрирует в своем составе как значительную функциональность ECM-систем, так и функциональность, предназначенную для организации корпоративного портала и средств создания внутрикорпоративной среды универсальных взаимодействий (то, что принято называть Enterprise 2.0). Также Microsoft SharePoint рассматривается как среда разработки широкой номенклатуры разнообразных решений;
- IBM Lotus Notes — универсальная среда внутри- и кросс-организационного взаимодействия и разработки различных приложений. На базе этой системы отечественные разработчики создали несколько готовых прикладных решений (приложений СЭД), предназначенных, в частности, для решения задач с отечественной спецификой;
- другие платформы (например, ERP) — нам также известны примеры использования в качестве базы для создания платформы СЭД платформ, изначально не ориентированных на решение задач документооборота. Такое решение, как правило, принимают организации, где задачи обработки документов занимают несущественное место по сравнению с задачами, погруженными в данную платформу, и где основные средства интеграции приложений в корпоративной ИС реализуются средствами этой платформы;
- In-House-разработка — до сих пор существуют компании, в которых разработка базовой платформы автоматизации, включая, в частности, и задачи обработки документов, ведется собственными средствами. При этом данный путь для этих компаний позволяет сохранить приемлемую стоимость владения за счет накопленной в системе уже разработанной за долгие годы функциональности и использовать опыт персонала в ее использовании и развитии.
Последние два типа внедрений обладают огромным разнообразием, так что в качестве примеров, иллюстрирующих реализацию конкретных функций, в дальнейших статьях мы ограничимся их реализацией в первых четырех типах внедрений.
Безусловно, формат статьи не дает нам возможности проанализировать все аспекты обсуждаемой темы. Более подробно это изложено в лекциях курса “Создание Корпоративной СЭД”.
Автор статьи — президент компании “ДоксВижн”.
