Современное управление контентом: слон или дерево?

Сергей Бушмелев, ИТ-аналитик компании DIRECTUM

Наверно, все помнят притчу о слоне и слепых, в которой слепые люди пытаются составить описание слона. Каждый из них исследовал свою часть слона: бок, ногу, хобот, хвост, ухо, бивень и каждый, после проведения исследования, выдвинул свою гипотезу.  Но, несмотря на имевшуюся возможность прийти к общему мнению в ходе научного диспута, каждый из исследователей остался при своем мнении, и все их предположения оказались в корне неверны. Причина сложившейся ситуации заключалась в том, ни один из «исследователей» не обладал зрением и, поэтому, не смог составить целостное представление об изучаемом феномене.

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

 Тем не менее, при общении с заказчиком говорить приходится как раз о веревках, стенах и деревьях. В переводе с языка аллегорий на общечеловеческий это означает, что разговор идет не об абстрактных ECM-платформах, а о решении видимых им задачах: автоматизации деятельности канцелярии, управления организационно-распорядительными документами (ОРД), обработки входящих счетов (invoicing) и т.п. Платформы же интересуют скорее ИТ-директоров заказчика, нежели прагматичных «бизнесов» - руководителей и сотрудников основных подразделений. Последние четко видят задачи, которые требуется решить и на «слонов» ведутся слабо. И основной критерий, применяемый ими при оценке предложений – насколько успешно могут быть решены стоящие (или поставленные) перед ними задачи при помощи той или иной системы.

Эта «приземленность» бизнес-пользователей может быть причиной некоторых заблуждений. Одно из распространенных заблуждений заключается в том, что предлагаемая поставщиком ECM-платформа часто воспринимается заказчиком как «средство» для решения задач, а не как «средство, при помощи которого можно создать средство», решающее конечные бизнес-задачи. Не в последнюю очередь эти заблуждения есть отражение позиции производителей ECM-платформ, зачастую позиционирующих свои продукты как интеграционные решения, включающие полноценные механизмы управления бизнес-процессами (Business Process Management), управления электронными документами (Electronic Document Management), управления документацией (Records Management.

Примерно в этом же ключе высказался¹ Джеймс Мюррей, вице-президент европейского отделения Interwoven. По его словам, пользователи неправильно понимают смысл термина ECM и считают, что ECM системы разрешат все их проблемы, связанные с обработкой корпоративного контента, тогда как на самом деле ECM-системы  могут разрешить только малую толику проблем пользователей. Поэтому сам термин подлежит декомпозиции (в оригинале «должен быть взорван», blown apart) на составляющие части. «Отрасль должна вернуться назад к разговору об отдельных компонентах, например, управлению документами, поиску, делопроизводству (records management)» - добавляет Джеймс.

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

Эта смена обстановки вынуждает ИТ-компании готовить свой «симметричный ответ кризису»: адаптировать стратегии продвижения продуктов под текущую экономическую ситуацию. Одним из замеченных трендов российского рынка систем электронного документооборота является увеличение активности по продвижению готовых бизнес-решений, автоматизирующих определенную, если не сказать узкую, сферу деятельности (делопроизводство, система менеджмента качества (СМК), управление договорами). Единого определения бизнес-решений не существует: за звучным словосочетанием может скрываться как консалтинговые услуги, так и программные решения. Специалисты компании DIRECTUM считают, что бизнес-решение в области управления корпоративным контентом – это, прежде всего, программно-консалтинговый продукт, объединяющий технические решение и методику внедрения для эффективного решения определенной бизнес-задачи. Техническое решение представляет собой поставляемую как единое целое совокупность необходимых компонент: программных модулей, настроек, сервисов, аппаратных решений. Методику внедрения в данном случае можно характеризовать как выжимку «лучших практик» (best practices), квинтэссенцию опыта и квалификации поставщика. Она включает в себя план внедрения, необходимые методические материалы, шаблоны организационно-распорядительных документов, ответы на часто встречающиеся вопросы, способы решения известных проблем.

Обновленный подход сулит ряд преимуществ:

●  лучшее понимание нужд заказчика и, как следствие, предложение более востребованных решений;

●  становится проще посчитать эффективность сделанных инвестиций (ROI), а там, где это невозможно, на помощь придет общая оценка зрелости²;

●  более адекватная оценка заказчиком потенциала решения, и, как правило, отсутствие неоправданных ожиданий от внедрения данного решения;

●  сокращение стоимости, длительности и сроков окупаемости проекта.

Сказанное выше не означает отрицание концепции ECM или умаление ее достоинств. ECM хороша именно как концепция, позволяющая взглянуть на управление корпоративным контентом «сверху», видеть весь круг возникающих задач, пусть не в деталях, но хотя бы в общих чертах. Но в разговоре с заказчиком, при формировании предложений целесообразнее, особенно в такой непростой экономической ситуации, имеет смысл оперировать прикладными понятиями и предлагать оптимальные решения отдельных задач.

Но если заказчику позволительно быть «близоруким», и мыслить только категориями отдельных решений, то поставщику это может стоить бизнеса. Разговаривая с заказчиком о веревках, стенах и деревьях, поставщик всегда должен держать в мыслях слона. Чтобы потом не придумывать, как прикрутить к ушам хвост. Иными словами, нужно видеть дальше, чем заказчик, за его текущими желаниями нужно уметь увидеть пути развития решения, будущую интеграцию отдельных бизнес-приложений. Это не реверанс в сторону платформенных решений: использование общей платформы для двух решений не означает автоматически возможность их интеграции. Речь идет об их взаимодействии на более высоком уровне, причем, чем выше уровень, тем больше свободы при проектировании и реализации внутренней структуры приложений.

Вариантов интеграции существует несколько. Это и входящие в состав приложения или разрабатываемые отдельно коннекторы к другим информационным системам, специализированные интеграционные приложения: брокеры сообщений (MQM), сервисные шины Enterprise Service Bus (ESB), движки Business Process Management (BPM). Также, говоря об интеграции приложений, нельзя не вспомнить идею сервис-ориентированной архитектуры (SOA). За определением обратимся к Википедии³: «Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение».

Не будем вдаваться в технические подробности, благо о SOA написано столько, что даже простое перечисление материалов объемом потянет на хорошую статью. Хочется обратить ваше внимание на следующий момент: если для производителя достаточно, чтобы приложение просто «умело» интегрироваться, прежде всего, с другими приложениями того же производителя, то для того чтобы начал выигрывать заказчик, необходимо, чтобы интерфейс приложений был стандартным, и тогда появится возможность соединять в единое приложение модули различных производителей. Но возможно ли это, ибо, перефразируя известную пословицу, что заказчику прибыль, то поставщику убыток. Согласятся ли производители допустить совместимость своих продуктов с продуктами конкурентов, упрочнив положение последних? Так как тогда появится возможность заменить решение от одного производителя аналогичным решением от другого, без лишних затрат и с сохранением существующей инфраструктуры.

Думается, на этапе развития и «захвата» рынка такое бы было невозможно. Компании-производители старались получить максимально возможную долю рынка, и несовместимость с продуктами конкурентов на данном этапе было «оружием» в конкурентной борьбе. Но рынок постепенно насыщался, компании закреплялись в определенных нишах, находили свое место в магических квадрантах аналитиков. И стало понятным, что для того, чтобы обеспечить дальнейшее развитие, придется смириться с наличием «на поле» конкурентов и уметь взаимодействовать с их приложениями.

Думаю, именно этими соображениями руководствовались «старожилы» рынка программного обеспечения, как EMC, IBM, Microsoft, Alfresco, Open Text, SAP, Day Software и Oracle, объединившие свои усилия для продвижения стандарта взаимодействия при управлении контентом CMIS⁴ (Content Management Interoperability Services). Данный стандарт есть техническая спецификация модели предметной области (данные и сервисы) для взаимодействия с хранилищами контента (репозиториями) ECM-систем посредством веб-сервисов. CMIS содержит предметно-ориентированную модель данных управления контентом, набор базовых сервисов, работающих с моделью данных, а также несколько протоколов связи для этих сервисов, включая SOAP и REST/Atom.

Основными достоинствами нового стандарта является то, что он:

●  разработан для работы с существующими хранилищами, позволяя пользователям создавать и совершенствовать приложения, поддерживающие одновременную работу с множеством хранилищ — делая общедоступным уже имеющийся у заказчика контент;

●  отделяет веб-сервисы и контент от хранилища контента, позволяя пользователям управлять контентом раздельно;

●  обеспечивает базовые веб-сервисы и интерфейс Web 2.0, что ощутимо упрощает разработку приложений;

●  является платформой разработки, которая не зависит от языка программирования;

●  поддерживает разработку композитных приложений и мэшапы (mash-up) бизнес- или ИТ-аналитиками;

●  обеспечивает рост сообщества независимых разработчиков программного обеспечения.

Как уже говорилось выше, соответствие хранилищ контента стандарту CMIS позволит обращаться к любому из них произвольному приложению. Данный сценарий взаимодействия не является единственным – другим сценарием, взятым из реальной жизни, является взаимодействие систем одного класса, но разных производителей. Это могут быть АБС (Автоматизированные банковские системы), ERP-системы, наконец, ECM-системы. Как правило, чаще такие потребности возникают в крупных холдингах, возникших в результате сделок M&A (Mergers & Acquisitions, слияние и поглощение). Каждая поглощаемая или присоединяемая компания тащит с собой «наследство» из информационных систем, автоматизирующих деятельность данной компании. Вместе получается такой веселый «зоопарк» - кошмар и головная боль ИТ-руководства холдинга. Другой вариант развития событий, когда появляется необходимость взаимодействия систем одного класса – попытка наладить информационный обмен между различными органами государственной и муниципальной власти. И если в холдингах еще возможен сценарий, когда руководство холдинга организовывает и финансирует переход всех предприятий холдинга на программное обеспечение одного производителя, то для государственных и муниципальных учреждений, вовлеченных в информационный обмен, такой способ решения может не подойти. Прежде всего, в силу ограниченности бюджетов и принадлежности учреждений к различным ветвям и структурам власти.

Если говорить о ECM-системах, то разговоры на бескрайних российских просторах об этом идут уже давно. Практически, в последние два-три года не было ни одного крупного мероприятия, собравшего представителей отечественных производителей СЭД, на котором бы не поднимался вопрос «стандартизации систем электронного документооборота». С одной стороны, это хороший знак: период «захвата территорий» близок к концу, рынок зреет, и производители смиряются с мыслью, что надо будет обеспечить совместимость с системами конкурентов. Думается, во времена рецессии количество случаев, когда необходимо организовать взаимодействие, только увеличится, прежде всего, в силу роста числа сделок M&A и ограниченности бюджетов, не позволяющей осуществить перевод на информационные системы одного поставщика.

С другой стороны, каждый раз вопрос повисал в воздухе, и долгожданный «стандарт» за все эти годы так и не был принят. В чем же дело? Неужели, на самом деле стандартизация не нужна? Выскажу свое предположение, почему сложилась такая ситуация. Как мне думается, коллеги, ратующие за создание стандарта, попали в ту же ловушку, что и покупатели ECM-систем. Если оперировать понятием ECM-система и рассматривать вопрос взаимодействия двух систем этого класса, то практически невозможно определить, какой именно информацией должны обмениваться системы. Все дело в том, что, как уже говорилось выше, понятие ECM включает массу различных технологий: управление бизнес-процессами, управление электронными документами, управление электронной почтой. Получается, что нужно стандартизовать все эти перечисленные и другие технологии. То есть нужно выработать стандарт на обмен документами (включая метаданные), в него же включить протокол обмена сообщениями, задачами и заданиями, возникающими в ходе управления бизнес-процессами. Также необходимо включить в стандарт механизм обмена информацией между частями ECM-систем, реализующих функционал управления документацией. Задача, на мой взгляд, практически неразрешимая.

На помощь может прийти уже знакомый и хорошо зарекомендовавший себя декомпозиционный подход. Думается, стоит перестать пытаться обеспечить взаимодействие абстрактных ECM-систем и рассматривать взаимодействие отдельных функциональных частей, например взаимодействие подсистем управления документацией. Наверно, самым ярким примером, иллюстрирующим работоспособность данного подхода, будет принятие модельных требований к системам управления электронной документацией (Electronic Records Management Systems) MoReq и MoReq2. Вопрос о необходимости разработки требований к системам электронного документооборота (СЭД) был поднят на DLM-форуме⁵ в 1996 году. Еврокомиссия в 1999 году объявила тендер на разработку спецификаций, который выиграла компания Cornwell Affiliates plc. Работа велась два года (2000-2001), и в 2001 году спецификация MoReq («Типовые требования к системам управления электронными документами») была опубликована. Спецификации MoReq достаточно широко использовались как в странах Евросоюза, так и за его пределами. Однако за семь лет многое изменилось, и стала ощущаться необходимость обновления спецификаций. Кроме того, встал вопрос о разработке методики тестирования программного обеспечения на соответствие данным требованиям, что также требовало их переработки – спецификации нужно было сформулировать таким образом, чтобы их положения трактовались однозначно и не создавали трудностей при тестировании⁶. В 2006 году Генеральный секретариат Еврокомиссии объявил о проведении открытого конкурса на право подготовки новой редакции требований – MoReq2, который выиграла та же консультационная компания Cornwell Consulting (позднее – Serco Consulting). В августе 2008 года спецификация MoReq2 увидела свет. В разработке и обсуждении спецификации приняли участие эксперты не только из стран Евросоюза, но и из США, Канады, Австралии и России.

MoReq и MoReq2 содержат перечень функциональных требований к управлению электронными документами при помощи систем управления электронными официальными документами (СУЭОД). Спецификации предназначены для применения:

●  потенциальными пользователями ‎СУЭОД: как основание для подготовки конкурсных требований

●  пользователями ‎СУЭОД: как основание для проведения аудита и проверки существующих СУЭОД;

●  центрами обучения: как справочный документ для подготовки учебных курсов по управлению электронными документами и как учебный материал;

●  академическими институтами: как учебный ресурс;

●  поставщиками и разработчиками СУЭОД: как руководство по разработке продукта и улучшению его функциональных характеристик;

●  организациями, предоставляющими услуги по управлению электронными официальными документами: как руководство по разработке услуг, которые они предоставляют;

●  потенциальными пользователями услуг по управлению электронными официальными документами (на условиях аутсорсинга): как пособие по контролю качества приобретаемых услуг.

●  Помимо этого, при использовании документации по тестированию систем, разработанной параллельно с MoReq2, предполагается ее использование:

●  поставщиками и разработчиками СУЭОД‎: для тестирования возможностей СУЭОД  на соответствие MoReq2;

●  пользователями ‎СУЭОД: для тестирования СУЭОД при внедрении на соответствие MoReq2⁷.

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

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

1. Phil Muncaster, ECM needs "exploding" says Interwoven, IT Week, https://www.computing.co.uk/itweek/news/2223054/ecm-needs-exploding-interwovenhttps://www.computing.co.uk/itweek/news/2223054/ecm-needs-exploding-interwoven.

2. М.Р. Галимов «Модель зрелости организации в области ECM», https://www.ECM-Journal.ru/docs/Model-zrelosti-organizacii-v-oblasti-ECM.aspx.

3. Свободная энциклопедия Википедия, https://ru.wikipedia.org/wiki/Сервисно-ориентированная_архитектура.

4. Свободная энциклопедия Википедия, https://ru.wikipedia.org/wiki/Content_Management_Interoperability_Services.

5. Сайт форума https://dlmforum.typepad.com/.

6. Н.А. Храмцовская «Опыт публичного обсуждения важнейших нормативных документов на примере спецификаций MoReq2», «Делопроизводство и документооборот на предприятии» № 10/2008.

7. MoReq2 спецификация: типовые требования к управлению электронными документами, М.: РОО «Гильдия Управляющих Документацией», 2008.

Источник: Финансовая газета. Экспо №2