+7 (495) 956-79-28
Демо-версия клиента под BlackBerry
Версия для печати
Главная / Пресс-центр / Статьи и интервью / ECM-системы: прошлое, настоящее и будущее
Статьи и интервью

ECM-системы: прошлое, настоящее и будущее

24.09.2009

Системы управления корпоративным контентом (Enterprise content management, ECM) создавались и создаются прежде всего для управления информацией, которая накапливается в организации в процессе ее жизнедеятельности, причем лидерами по количеству такой информации традиционно выступают банки и страховые компании. Для обеспечения работоспособности в условиях больших потоков документации они вынуждены затрачивать немалые средства на эффективную организацию работы с информацией. ЕСМ-системы предназначены именно для того, чтобы сократить эти затраты. Обеспечивая возможность сбора, хранения и предоставления информации по запросу, они позволяют структурировать получаемую информацию и устанавливать единые стандарты ее обработки, хранения, предоставления по запросу и удаления.

Самыми распространенными информационными системами управления контентом являются системы электронного документооборота (СЭД). Фактически СЭД и ECM в России стали понятиями взаимозаименяемыми, а непрерывно расширяющийся функционал систем электронного документооборота и добавление к ним системы системы автоматизации бизнес-процессов (WorkFlow) уравняли данные понятия полностью. Это обосновано прежде всего тем, что распространенная в РФ модель управления и отчетности предполагает использование для принятия и осуществления управленческих решений именно документов, то есть информационных структур, состоящих из контента и комплекса атрибутов, позволяющих их идентифицировать.

Таким образом, на СЭД, работающих в банках, зачастую возложены нагрузки, многократно превышающие аналогичную нагрузку на систему, эксплуатирующуюся, к примеру, на промышленном предприятии.

В классическом понимании функционал ECM-систем и СЭД сведен к обеспечению автоматизации нескольких стандартизованных потоков документов. К ним, прежде всего, относятся:

К этому всему необходимо добавить такие обязательные функции системы, как:

В классическом виде функционал систем электронного документооборота этим и ограничивается, однако кредитно-финансовые организации накладывают на СЭД свои собственные требования, обусловленные прежде всего большим количеством документоориентированных процессов.

Многие банковские системы, имея в основании ту или иную документоориентированную платформу, могут решать задачи, к примеру, оценки рисков заемщика – физического лица посредством процедуры кредитного скоринга, что позволяет снизить время проведения оценочной процедуры и требований к квалификации участвующих в ней специалистов. Применение таких систем также обеспечивает возможность не только в течение длительного срока хранить сведения о заемщиках (в том числе и несостоявшихся), но и своевременно предоставлять их по требованию в любой точке присутствия розничного банка на всей территории его деятельности, что также снижает возможность умышленного искажения заемщиком сведений, предоставляемых в банк, с целью повышения вероятности получения займа (так называемый soft fraud), а также идентификационного мошенничества.

В настоящее время рынок ЕСМ-систем демонстрирует динамичное развитие. Текущий мировой экономический кризис, несмотря на пессимистические прогнозы, не вызвал значительной стагнации рынка копоративных информационных систем в целом и ЕСМ-систем в частности. Значительно большее влияние, и достаточно негативное, оказал тот факт, что некоторые производители ECM-систем были во многом ориентированы на банковский сектор, и серия банкротств крупных банков в начале 2009 года привела к тому, что рынок именно этих, во многом специализированных, систем пришел в состояние стагнации после активного роста 2008–2009 гг.

Выходом из возникшей ситуации стало массовое внедрение систем автоматизации документоориентированных потоков работ – WorkFlow-систем, обусловленное относительной простотой разработки приложений WF-систем и заметным снижением требований к специалистам, осуществляющим такую разработку. Также немаловажным фактором является значительное сокращение времени разработки такого приложения. Анализ потребности и разработка требований к информационной системе теперь занимают меньше времени, чем разработка системы и ее последующее тестирование.

Архитектура большинства современных ЕСМ-систем построена на основе концепции SOA (сервисно-ориентированной архитектуры). В общем виде ее можно представить в виде следующей четырехуровневой системы (см. рис. 1).

Четырехуровневая архитектура современных ЕСМ-систем

Рис. 1. Четырехуровневая архитектура современных ЕСМ-систем

На первом, самом низком, уровне такой системы находятся СУБД (системы управления базами данных), которые обеспечивают хранение как контента документов системы, так и их метаданных и поисковых индексов. Используемые в системах ECM СУБД можно условно разделить на 2 типа в зависимости от методологии размещения данных. К первому типу реляционных СУБД относят системы SQL производства Microsoft, Informix производства IBM и системы Oracle одноименного производителя. Ко второму типу относят Lotus Domino/Notes производства корпорации IBM. Многие системы электронного документооборота имеют возможность полноценной работы с различными СУБД, а в некоторых случаях, используя принципы корпоративной распределенности, позволяют реализовывать разные части электронных хранилищ на основе различных технологических платформ, что является необходимым условием эффективного управления лицензиями на программное обеспечение в компаниях с высоким уровнем территорильной распределенности, к которым относятся и крупные розничные банки. Также на этом уровне находятся системы, обеспечивающие управление информационной безопасностью как хранимого документационного контента (путем криптографической защиты документальных материалов), так и непосредственно процедур делопроизводства (с помощью электронной цифровой подписи).

Второй уровень системы включает в себя универсальные сервисы, предназначенные для реализации стандартных, унифицированных задач, используемых при выполнении процедур делопроизводства. Так, практически все процедуры организационного документооборота содержат несколько таких сервисов, важнейшим из которых является сервис согласования, позволяющий проводить ознакомление должностных лиц с текстом определенных документов с одновременным получением от них ответной реакции в виде полного или частичного согласия с текстом документа (виза "согласовано") либо несогласия с возвратом на доработку и указанием причин. Также важно отметить наличие возможности различных типов согласования (параллельного, т. е. "веерного", последовательного, т. е. "эстафетного", комбинированного) с возможностью редактирования маршрутов и поддержкой элементарных операций над структурой организаций: определения конкретных подчиненных должностных лиц, их непосредственного руководителя, а также руководителя их структурного подразделения.

Третий уровень (уровень прикладных модулей) представляет собой непосредственную реализацию автоматизированных процедур управления контентом. На этом этапе следует остановиться подробнее, так так подходов к реализации автоматизированных модулей великое множество, но в рамках настоящей статьи мы их разделим на два основных типа.

Первый подход, прекрасно зарекомендовавший себя на протяжении последних лет, - модульная разработка автоматизируемых процессов. Данный подход предполагает использование либо единичных модулей, либо их взаимодействия в рамках SOA для автоматизации каждой конкретной документоориентированной процедуры. Так, уже упомянутый кредитный скоринг в этом случае может быть реализован самим модулем, выполняющим обработку данных, вводимых в систему кредитным экспертом, при этом в рамках процедуры согласования этот модуль предоставляет часть необходимой информации офицеру службы безопасности, который осуществляет согласование на уровне проверки избранных фактов анкеты заемщика.

Второй, более новый и значительно более эффективный, подход представляет собой WorkFlow-реализацию аналогичного системного функционала. При этом сам программный механизм, осуществляющий продвижение документов в рамках документоориентированного потока (так называемый WorkFlow-движок), представляет собой один из сервисов предыдущего, т. е. второго уровня системы и, как все сервисы, имеет стандартизованный интерфейс для любого процесса, который создает соответсвующий запрос.

Как известно, основным и важнейшим принципом, позволяющим провести автоматизацию какого-либо направления деятельности, является его разделение на отдельные бизнес-процедуры (процессы), имеющие четкое начало, окончание, требования к входным данным и результатам, а также к исполнителям отдельных операций – ролевых функций.

Пример WorkFlow-реализации: процесс обработки заявки на закупку письменных принадлежностей

Рис. 2. Пример WorkFlow-реализации: процесс обработки заявки на закупку письменных принадлежностей

В качестве примера рассмотрим такой процесс, как подача работником заявки на закупку письменных принадлежностей.

Работник организации (заявитель) готовит заявку, в которой указывает требуемые канцелярские принадлежности и их количество. Далее заявка поступает на согласование непосредственному руководителю этого работника, идентификатор которого система должна вычислить сама, зная должность заявителя. В случае успешного прохождения первого согласования заявка поступает финансовому контролеру для прохождения бюджетного контроля. Затем она направляется специалисту хозяйственной службы, который определяет наличие запрашиваемых канцелярских товаров в соответствии с учетной системой и, при необходимости, корректирует заявку по договоренности с заявителем. В случае, если необходимых принадлежностей на складе нет, а произвести замену не представляется возможным, он передает заявку специалисту по закупкам, который организовывает поставку заказанных материалов на склад организации. В дальнейшем кладовщик извещает заявителя о необходимости получить запрошенные принадлежности и организует доставку последних заявителю, который по факту получения своего заказа делает соотвествующую отметку в системе, тем самым завершая процесс.

Автоматизация такого процесса начинается с подготовки технических требований с детальным описанием процесса. В платформенной СУБД создается база данных, сохраняющая сведения о процессе (идентификаторы исполнителей, перечень заказанных принадлежностей и многое другое). Далее специально спроектированная модель процесса вводится в WF-движок, который через универсальный либо специализированный интерфейс готов начать выполнение процедур по этому потоку работ, как только у сотрудников организации возникнет потребность в канцелярских принадлежностях.

В дальнейшем для успешного внедрения нового автоматизированного потока работ должно быть проведено его документирование с последующей регламентацией измененного процесса.

Четвертый уровень – уровень систем взаимодействия с пользователем. В настоящий момент существует основная дифференциация интерфейсов пользователя на два больших класса. Это так называемый толстый клиент, обеспечивающий полный функционал взаимодействия с ECM-системой. Приложение "толстого клиента" обычно разрабатывается производителем самой системы, однако периодически встречаются и сторонние разработки. Так, например, системы, использующие решения на основе Microsoft Exchange сервера, могут использовать не только нативное решение (клиентское приложение Outlook, работающее на платформе Wintel), но и сторонние разработки, к примеру, Evolution компании Novell, работающее под ОС Linux. В большинстве же случаев при разработке клиентского интерфейса производителем СЭД функционал такого клиентского приложения четко предопределен разработчиком.

В некоторых случаях, особенно при использовании в качестве СУБД системы IBM Lotus Domino, в роли "толстого клиента" выступает клиентское приложение, производимое самим вендором СУБД – IBM Lotus Notes, и в рамках именно этого приложения уже организуется полномасштабное взаимодействие пользователя с ECM-системой.

Кардинально различается концепция "тонкого клиента" – приложения, реализованного на основе web-интерфейса. Такой подход зачастую не позволяет создавать полнофункционального приложения, но в значительной степени может обеспечить его универсальность и простоту развертывания. Этот вопрос становится максимально интересным, если учитывать следующее взаимоотношение количества рабочих мест при внедрении, к примеру, системы электронного архива: на одного администратора системы может приходиться два архивариуса и более сотни работников, для которых архив организации представляет собой единственную задачу – запрос архивных материалов. Именно для этой категории работников – исполнителей функциональных ролей – и желательно применение интерфейса, реализованного через "тонкий клиент". Такой подход позволяет существенно более эффективно управлять как пакетом лицензий на программное обеспечение в целом, так и в значительной степени удешевить разработку системы электронного архива модуля за счет ограничения функционала "тонкого клиента".

Необходимо также упомянуть отдельный тип клиентских приложений, реализуемых на мобильных платформах, таких как Symbian OS, Apple IPhone OS, Windows Mobile и Google Android. Решения, выполненные на мобильных платформах, могут быть реализованы также в виде "толстого" и "тонкого" клиентов, но обычно обладают значительно меньшим функционалом по отношению к своим "настольным собратьям", главным же их достоинством является мобильный доступ к корпортивному контенту и возможность выполнения работником своих функциональных ролевых обязанностей удаленно от офиса без внесения задержек в бизнес-процессы организации.

К осени 2009 года WF-системы появятся у всех остальных производителей ECM-систем, что приблизительно уравняет функциональность предлагаемых решений, обострив конкуренцию. Таким образом, в ближайшее время следует ожидать качественного функционального рывка, каким в свое время стало появление автоматизации бизнес-процессов. Так, некоторые компании начали предоставлять ECM-решения в виде SaaS-решения (система/программное решение как услуга). В этом случае потребителю предлагается готовое решение с доступом через Интернет и помесячной оплатой определенного количества рабочих мест. Тем не менее такой подход, во многом являющийся революционным, был принят рынком с настороженностью: далеко не каждая компания готова передать свою документацию для хранения на удаленных серверах, принадлежащих провайдеру (поставщику услуги), что несколько останавливает развитие подобной идеологии.

 
Подписка на новости
Ваш E-mail
вернуться наверх