Электронный документооборот: как выбрать систему и не упустить важное

    image
    Обычно мы размещаем статьи о нашей платформе для разработки бизнес-приложений CUBA, но сегодня решили открыть еще одну тему на Хабре, связанную с другим нашим продуктом – системой электронного документооборота ТЕЗИС. Мы заметили, что выбирая систему документооборота, заказчики используют различные методики сравнения, но все они касаются только функциональных характеристик систем, а другие не менее важные факторы ускользают от их внимания. Что в общем-то понятно — в интернете не так много объективной и доступной информации о том, на что стоит обращать внимание при принятии решения о выборе СЭД, какие тонкости и нюансы следует учесть, каких подводных камней избежать, а мнение разработчика воспринимается как предвзятое.

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

    Disclaimer: в некоторых моментах наше мнение может отличаться от мнения автора.


    Станислав Макаров, журналист – аналитик, эксперт в сфере ЕСМ

    «Сегодня ЕСМ-система – не просто возможность заявить об инновационном подходе к ведению бизнеса, это насущная необходимость, а отсутствие её на предприятии есть признак недостаточной зрелости бизнес-процессов и слабой культуры работы с электронными документами.
    Между тем, выбор ECM стал довольно трудным делом для заказчиков: рынок весьма насыщен, вендоры наперебой рассказывают о своих продуктах, обещая быстрый экономический эффект и другие чудеса. Но недостаточно просто купить и поставить какую-то ЕСМ-систему, чтобы получить конкурентное преимущество; важно, чтобы она эффективно использовалась и была актуальна сегодняшнему дню еще как минимум 5-7 лет. Так что, цена ошибки при выборе такого важного компонента корпоративной информационной системы очень велика.

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

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


    Как выбирать ECM в условиях зрелого рынка


    Рынок электронного документооборота в России в 2014 году отмечает свое 20-летие. За эти годы был пройден большой путь от простейших систем регистрации и учета документов, которые копировали традиционные методы работы канцелярий, до продвинутых решений, объединяющих функции управления документами, бизнес-процессами и коллективной работы, которые мы сегодня называем ECM-системами.

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

    СЭД и ECM

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

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

    Нефункциональные требования в центре внимания


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

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

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

    Стандартов собственно на ECM/СЭД в России нет. Поэтому разумно относиться критически к заявлениям поставщиков о «соответствии российским стандартам документооборота» – любая гибкая платформа может быть настроена так, чтобы отвечать функциональным требованиям к работе с документами.

    Рекомендации

    • Оставайтесь реалистами, не предъявляйте к системе завышенных требований. Коэффициент запаса по производительности, масштабируемости и доступности должен быть в разумных пределах – с учетом максимального прогноза по росту документопотока и численности организации.
    • Удобство использования (юзабилити) — далеко не такая субъективная вещь, как кажется на первый взгляд. В этой области есть свои стандарты и методики, позволяющие провести вполне объективную оценку. Обращайтесь к специалистам.
    • Следует различать стандарты, предъявляемые к документам и процедурам их обработки, и стандарты к ИТ-системам класса ECM/СЭД. В некоторых сферах действительно есть стандарты, например, в управлении качеством – серия ISO 9000. Поставщик может предложить готовое решение, которое позволит вам быстрее пройти сертификацию или аудит по управлению качеством, но это не гарантия качества самой ECM-системы — учитывайте это.

    Больше — не всегда значит лучше


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

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

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

    У профессиональных инвесторов есть правило, что при принятии решения об инвестиции в ту или иную компанию, ее прошлые успехи и ранее вложенные в нее деньги в расчет не принимаются. Важен только будущий доход — сколько можно заработать завтра, если инвестировать в этот актив сегодня. Это вполне применимо и к ситуации выбора ECM: покупая систему, фактически, вы инвестируете в свое будущее. Когда появился iPhone, на рынке мобильных телефонов господствовала Nokia. И где она теперь?

    Если бы в 2007 году вы принимали решение о развитии у себя направления мобильной разработки, разве все не говорило о том, что пользователей Symbian во много крат больше, чем пользователей iOS? Однако, история рассудила иначе. Кстати, история обожает повторы: точно также Android обошел на повороте iOS, и те из разработчиков, кто еще сохраняет абсолютную лояльность Apple, рискуют выпасть из мейнстрима мобильной революции.

    Вернемся к ECM. Зрелость рынка это отнюдь не признак его заката. Инновации продолжаются. Возможно скоро аналитики объявят нам о новой реинкарнации ECM и начнется очередной цикл развития технологий. Стабильность на ИТ-рынке обманчива, ни один лидер не может себе позволить почивать на лаврах и клиентская база вовсе не гарантирует будущего благоденствия поставщика.

    Рекомендации

    • Исключите статистические данные по объемам продаж и долям рынка из вашего списка критериев.
    • В качестве референсов полагайтесь на относительно новые проекты, сопоставимые по масштабу с вашей организацией, не гонитесь за громкими именами заказчиков — вы же не пресса.
    • Помните, что старые заслуги не есть гарантия успеха вашего будущего проекта. Обратное утверждение также неверно: полное отсутствие внедрений или единственное внедрение не есть признак инновационности, выбирайте разумный баланс.

    Горизонт планирования


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

    Таким образом получается, что горизонт планирования у вас должен быть не менее 7-ми лет. То есть, сегодня вы выбираете систему, расстаться с которой можно будет только по прошествии этого времени. Вы представляете, сколько всего нового может произойти! Разумеется, учесть и предвидеть все невозможно, поэтому придется делать выбор, в какой-то мере, интуитивно.

    Рекомендации

    • Изучите, на какой фазе жизненного цикла находятся ключевые технологии, используемые в продукте. Если они близки к своему закату, то такой продукт брать не стоит.
    • Это же применимо и к самой ECM-системе — нужно оценить, на какой фазе своего жизненного цикла она находится. У вас должна быть уверенность, что выбранное решение просуществует на рынке в рамках вашего горизонта планирования.
      Смотреть надо не на компанию, не на бренд, а на сам продукт – сколько времени он живет на рынке в своей текущей архитектуре. Номер версии бывает обманчив, иногда версии одна от другой сильно отличаются внутренним устройством.
    • Посмотрите, насколько часто выходят версии продукта. Система должна регулярно обновляться, потому что окружающая среда постоянно эволюционирует и пользователи сегодня не готовы ждать от релиза до релиза, чтобы получить новые возможности.
      За образец можно взять модель Google: новые функции вводятся в продукт по мере их готовности. Обновление должно происходить максимально гладко для пользователей и для компаний, чтобы это не превращалось в отдельный ИТ-проект.

    ECM в ИТ-ландшафте организации


    Выбирая предметы гардероба или мебель, вы думаете о том, как это будет сочетаться с остальными вещами и соответствовать вашему стилю. Точно также и с ECM: она должна стать частью вашего ИТ-ландшафта, вписаться в него.

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

    Бывают ситуации и сложнее: допустим, у вас проходит внедрение ECM и параллельно идет глобальный проект по автоматизации бизнес-процессов на базе какой-либо BPMS. Поскольку все современные ECM обладают встроенными возможностями по управлению бизнес-процессами, вам придется выбирать, что использовать для автоматизации процессов документооборота — возможности самой ECM или универсальные инструменты на основе BPM-движка.

    Рекомендации

    • Решить, какие из старых систем будут выведены из эксплуатации после внедрения новой ECM;
    • Решить вопрос с миграцией данных, если это требуется; (Далеко не все старые вещи стоит брать с собой в новую жизнь – вовсе не обязательно переносить все исторические данные в новую систему, а только те, которые нужны для бизнеса.)
    • Откуда наша ECM-система будет получать мастер-данные? Если в организации нет единой системы управления мастер-данными, может быть самое время об этом подумать.
    • Если какие-то функции выводимых из эксплуатации систем не могут быть покрыты новой ECM, то нужно решить два вопроса: а) так ли эти функции необходимы; б) если да, то какими системами можно их покрыть.

    Безопасность


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

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

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

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

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

    Рекомендации

    • Остерегайтесь избыточных требований по безопасности! Это может неоправданно увеличить стоимость проекта и отсечь многие интересные решения.
    • Подходите к безопасности комплексно: самая защищенная ECM будет бесполезна, если конфиденциальные документы лежат на общем диске.
    • Электронная подпись нужна только там, где это требуется по закону. Все остальное – от лукавого, подписывать ЭЦП каждую служебную записку не нужно.
    • Подробно выясните, какая модель управления доступом реализована в системе (дискреционная, мандатная, ролевая), и как она настраивается. Это может влиять на трудоемкость реализации ваших требований по разграничению доступа.
    • Если вы продолжаете использовать бумажные документы, учтите это в своих требованиях по безопасности: не имеет смысла делать строгое разграничение доступа к электронным документам, если бумажные копии свободно переходят из рук в руки.

    Платформа или коробочный продукт?


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

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

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

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

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

    Рекомендации

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

    Интеграция


    Говоря о платформах, мы уже затронули тему интеграции ECM с другими приложениями и системами. Одним из побудительных факторов мы назвали необходимость поддержки разнообразных бизнес-процессов, когда ECM используется совместно с другими бизнес-приложениями – например, помогает работать с финансовой «первичкой» непосредственно в ERP.

    Другой фактор — это необходимость синхронизации мастер-данных (или нормативно-справочной информации, НСИ), включая учетные записи пользователей, организационно-штатную структуру предприятия, каталоги продукции, справочники контрагентов, адресный регистр и многое другое. Чтобы работать согласованно, все корпоративные приложения должны пользоваться одними и теми же справочными данными, а для этого системы должны уметь этими данными обмениваться.

    Нельзя забывать и о взаимодействии с внешним миром. При внедрении ECM в госсекторе нужна интеграция со СМЭВ и МЭДО, в других задачах может понадобиться работа с электронной почтой, при участии в электронных торгах — обмен документами с торговой площадкой и т. д.

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

    Рекомендации

    • Проверьте наличие документированного API к предлагаемому продукту. Закрытые системы сегодня не имеют шансов на выживание в корпоративной среде.
    • Узнайте о других способах интеграции ECM с внешними источниками данных — готовые шлюзы, возможность использования партнерских решений и т. д. Вовсе не обязательно решать каждую интеграционную задачу вручную при помощи API.

    Мобильность


    Продажи смартфонов и планшетов уже в 2013 году превысили продажи ПК, а в скором времени мобильные устройства превзойдут ПК и по количеству — таковы реалии сегодняшнего дня. Корпоративные пользователи также широко применяют мобильные устройства на работе, читая с них почту, утверждая сделки, отдавая поручения и выполняя все другие действия, которые раньше требовали использования настольного компьютера.

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

    Мобильный мир многополярен, монополиста на нем нет (при всем уважении к фирме Apple, которая этот рынок для нас открыла). Предлагаемая вам ECM должна поддерживать все популярные мобильные платформы: iOS, Android, Windows. Причем разработка отдельных нативных приложений под каждую платформу едва ли разумный путь — как с точки зрения экономики, поскольку придется держать несколько команд разработчиков, так и с точки зрения унификации пользовательского опыта (user experience). Для мобильных бизнес-приложений более логичным выглядит использование MEAP-платформ или HTML5-решений, позволяющих централизованно проектировать бизнес-логику и автоматически адаптировать пользовательский интерфейс под конкретный форм-фактор устройства и его операционную систему.

    Концепция BYOD (Bring Your Own Device) уже принята многими организациями, которые поняли, что преимущества для бизнеса от использования сотрудниками собственных смартфонов и планшетов гораздо больше, чем риски (часто — довольно гипотетические), поскольку в области мобильной безопасности появились вполне зрелые решения, сводящие эти риски к минимуму.

    Рекомендации

    • Начните знакомство с ECM-системой с мобильного клиента. Если он вас удовлетворит, то можно двигаться дальше. Главный критерий — с системой должно быть удобно работать, все должно быть понятно без чтения документации, к чему уже привыкли мобильные пользователи. Пусть это отчасти субъективно, однако первое впечатление очень важно.
    • Уточните, как именно реализована мобильная кросс-платформенность, то есть, поддержка разных мобильных платформ. (То, что это обязательно – даже не обсуждается. На одном iPad далеко не уедешь.)
    • Обратите внимание на поддержку различных форм-факторов — для планшета и смартфона нужны разные интерфейсы. Конечно, читать документы со смартфона едва ли удобно, но быстро ответить на вопрос, перенаправить поручение, прочитать уведомление о срочном задании – все эти вещи вполне можно делать и с маленького экрана.
    • Ценовая политика в отношении мобильных версий — отличный индикатор понимания разработчиком ECM парадигмы мобильности. Мобильная ECM отнюдь не товар премиум-класса, а рабочий инструмент, который нужен каждому пользователю.

    Экономика


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

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

    Каждый, кто делал ремонт в квартире с этим согласится — несмотря на самую тщательную подготовку и детальные расчеты, в жизни все получается по-другому.
    Популярный показатель ROI (возврат на инвестиции) слабо применим к системам автоматизации для работников умственного труда, и к ECM в том числе. Ускорение работы с документами само по себе прямого экономического эффекта не дает. Допустим, ваши сотрудники станут находить нужные документы быстрее и сэкономят по 1 часу в день – это же не значит, что вы сократите их зарплату на 1/8? Влияние ECM на бизнес носит более опосредованный характер, и не всегда эти взаимосвязи можно выявить и сопоставить им количественные показатели. Качественные улучшения, как, например, повышение удобства работы с документами, тоже положительно влияют на бизнес, хотя и не измеряются в миллионах долларов.

    Рекомендации

    • Оценивать предложения поставщиков исходя не из цены закупки, а из общей стоимости владения (TCO) системой за срок ее плановой эксплуатации, то есть на интервале 5-7 лет.
    • Выявить все скрытые расходы, не включенные поставщиком в коммерческое предложение. Для нормальной работы ECM может потребоваться дополнительное оборудование (серверы, сканеры, принтеры, техника для работы со штрих-кодами), дополнительный персонал, обучение, модернизация каналов связи, обновление системного ПО, закупка дополнительного ПО, получение лицензий и сертификатов у регулятора, и т. д. Не стесняйтесь спрашивать — лучше все нюансы выяснить на старте проекта.
    • Забудьте о расчетах ROI на основе экономии времени. Либо находите более четкие критерии, например, экономия ФОТ, если вы планируете сокращение персонала, либо полагайтесь на качественные улучшения.
    • Еще один момент: внедрение ECM не обязано дать вам прямую экономию. Расходы на автоматизацию документооборота логично включить в общие издержки на ведение бизнеса. ECM сегодня —такая же необходимость, как электронная почта и доступ в Интернет.

    Не «садитесь на иглу» вендора


    Пожизненно обеспечивать заказами разработчика ECM не входит в ваши планы, не так ли? Ваша цель — обеспечивать конкурентоспособность и развитие своего предприятия. Пока выбранная ECM справляется со всеми возложенными на нее задачами, вы будете ее поддерживать и обновлять, приобретать дополнительные лицензии. Но как только станет ясно, что ваша организация переросла возможности системы, ее придется менять.

    Бывает и другая ситуация: система вполне удовлетворяет пользователей, но фирма-разработчик вдруг уходит с рынка, из-за неблагоприятной конъюнктуры или вследствие недружественного поглощения. От этого никто не застрахован — ни крупные западные вендоры, ни отечественные разработчики.

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

    Рекомендации

    • Избегайте слишком экзотических технологий; избегайте устаревших технологий, находящихся на последних стадиях жизненного цикла – дефицит специалистов может оказаться критическим фактором;
    • Проанализируйте финансовое положение поставщика, особенно это касается отечественных разработчиков.
    • Еще раз об открытом коде: возможно, это ваш спасательный круг, если что-то случится с поставщиком.


    Другие статьи автора на тему документооборота можно почитать в блоге PRO СЭД.
    Haulmont
    132,00
    Корпоративные решения любой сложности на Java
    Поделиться публикацией

    Комментарии 22

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

      А какие технологии использует ТЭЗИС?
      0
      Стандартов собственно на ECM/СЭД в России нет.

      Наталья Храмцовская наверняка оспорила бы это высказывание.
      В целом — спасибо за статью. Продукты, которые я продаю, полностью подходят под все ваши рекомендации.
        +3
        А как же MoReq. Если не ошибаюсь, то данный стандарт подразделяет ECM системы на 2 типа: EDM (electronic document management — управление документами — системы документооборота) и ERM (Enterprise records management — управление записями — системы электронных архивов). Официально стандартом MoReq не признается, но де-факто оон таким является. На его основе созданы как зарубежные системы типа Documentum, так и российские, например STOR-M.

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

        В общем-то автор прав, что в России стандарта нет, но тем не менее они используются. Призываю в этот топик staskin1, он обладает значительно большими знаниями в этой области.
          0
          Приятно видеть, что MoReq не забыт:)
          Но хотел бы поправить: Documentum не был сделан на основе MoReq. Хотя бы потому, что он появился раньше MoReq.
          Но это не главное — Moreq определяет довольно узкую часть функциональности, именно records management, тогда как scope любой ECM-платформы значительно шире.

          Также не стоит проводить жесткую демаркационную линию между document и record. В ECM-системах обычно есть операция «declare document as record» — аналогично нашему понятию «регистрация документа».
          Record — это с одной стороны документы, которые требуются по закону (комплаенс) — накладные, счета-фактуры и проч.
          С другой — все документы, которые как-то могут обосновать вашу позицию перед различными компетентными органами или перед партнерами. Например, обычное письмо по e-mail, где менеджер контрагента обещал вам скидку.
          Для вас это record, ибо если человек уволится и потрет свою почту, как вы эту скидку получите?

            0
            Moreq определяет довольно узкую часть функциональности, именно records management, тогда как scope любой ECM-платформы значительно шире

            Что вы подразумеваете под «scope ECM-платформы»?
          0
          Э, не надо путать стандарты на предметную область (документооборот) и на технические системы. На СЭД таки стандартов нет.
          И да — это не пособие по выбору конкретного продукта))
          0
          Было бы замечательно, если бы заказчики использовали данные рекомендации при выборе софта. Но, если эти рекомендации не донести до широкого круга заказчиков-пользователей, то они так и останутся известными лишь специалистам по ECM и должной пользы не принесут.
            0
            Именно с этой целью мы и опубликовали статью — донести информацию широкому кругу читателей. В дальнейшем планируем еще размещать аналитические заметки по теме СЭД/ЕСМ, возможно с более глубоким рассмотрением отдельных критериев при выборе СЭД.
              0
              К сожалению специалисты заказчиков, посещающие Хабр, не принимают решения о выборе и приобретении корпоративных систем.
                0
                Возможно технические специалисты не всегда могут повлиять на решение о выборе СЭД, но однозначно могут принимать активное участие на подготовительных выбору этапах.
            0
            Спасибо, очень правильная статья.

            детальное сравнение возможностей продуктов может оказаться бесполезным

            Согласен, если выбор идет из TOP-10 СЭД (ниже 10-ки высока вероятность, что в СЭД не окажется какой-нибудь полезной функции, которую забыли учесть при выборе), то в основе должны лежать уже, именно, не функциональные требования.

            Единственное, немного дополню список не функциональных требований на основе своего опыта:

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

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

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

                1. Партнер внедряет СЭД. Плюсы: территориальная близость к заказчику (нет командировочных расходов); конкурентная стоимость ч/ч (ставки в регионах отличают от Москвы); проектный опыт в схожей сфере (как правило интеграторы специализируются на какой-то одной отрасли).

                2. Вендор помогает партнеру и контролирует внедрение СЭД. Плюсы: в сложные моменты вендор может дать партнеру ценный совет; помочь правильно спроектировать решение; для заказчика это гарантия качества + стоимость такого привлечения значительно ниже, чем заказывать у вендора проект внедрения.

                3. Специалисты заказчика сопровождают СЭД. Плюсы: оперативное решение любого вопроса; свои специалисты лучше разбираются в созданном на платформе решении и как правильно лучше понимают специфику своей компании; стоимость как правило ниже. А партнер и вендор привлекаются только в случае развития СЭД или перехода на новую версию.
                  0
                  Единственная идеальная схема? Мне кажется это слишком мало для рынка. В одном случае эта схема работает, в других случаях заказчики ориентированы сразу на другие варианты взаимодействия. Например, по опыту, крупные заказчики сразу настаивают на прямой работе с вендором, т.к. никто не знает систему лучше самого вендора. А кому-то нужна независимость и предпочитают полностью самостоятельное развитие системы, такие примеры тоже есть. В общем, в многообразии предложения кроется рост качества услуг для конечного потребителя.
              +1
              Людмила, здравствуйте.

              Нам как инициаторам создания хаба ECM/СЭД* очень приятно, что ряды расширяются и ваша компания также сочла Хабру достойным местом для размещения публикаций по ECM. Пожалуйста, не перепечатывайте статьи чужих авторов особенно корреспондентов российских онлайн СМИ, тогда не придется оправдываться за чужие глупости. Это я про отсутствие в России стандартов на ECM. Автор или чего-то не знает или не разбирается в стандартизации. Можно не признавать MoReq и утверждать, что он приемлем только для Европы, но те же ISO — международные стандарты и ISO 15489 в двух частях, работает и даже переведен и принят в качестве национального.
                0
                Автор достаточно разбирается в стандартизации, посвятив области СЭД более 20 лет.
                Тем более что автор делал первый перевод MoReq на русский язык по договору с Европейской Комиссией.
                Автор также проводил ряд работ по оценке отечественных систем на соответствие требованиям MoReq, так что имеет далеко те только теоретические познания в этом вопросе.

                Касательно ГОСТ ИСО 15489-2007. Это фреймворк для предметной области — Управление документами. Отнюдь не для технических решений для управления документами. Таковым стандартом мы планировали сделать MoReq, но, к сожалению пока не получилось.
                ГОСТ ИСО 15489 не содержит функциональных и иных требований непосредственно к информационным системам.

                Станислав Макаров, автор.
                  0
                  Станислав, здравствуйте,

                  Автор достаточно разбирается в стандартизации...

                  Спасибо, что присоединились к беседе. Немного странно, что вы пишите о себе в третьем лице :)
                  С вашим вариантом перевода стандарта MoReq и в частности вышепомянутой связки: document/record, где «информационный документ = document, официальный документ = record» я хорошо знаком и даю его в купе с оригинальным текстом на английском и переводом от Натальи Храмцовской слушателям на занятиях по ECM.

                  Переводить стандарты еще не значит разбираться в стандартизации в данном случае не только отраслевой, но и международной. Я говорю о статусе стандартов, их действии на территории той или иной страны, применимости для целей бизнеса, легитимности и отношении официальных органов в том числе и судов в случае различных споров. Как вы, например, ответите на такой вопрос: имею ли я право на территории РФ использовать стандарт ISO 15489-1:2001 Information and documentation — Records management — Part 1: General, если существует национальный ГОСТ Р ИСО 15489-1-2007. «Система стандартов по информации, библиотечному и издательскому делу. Управление документами. Общие требования»?

                  ГОСТ ИСО 15489 не содержит функциональных и иных требований непосредственно к информационным системам.

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

                  Станислав, а почему вы не опубликовали данную стстаью на Хабре от своего имени? Или на Хабре вы представляете интересы компании Haulmont, которая вас пригласила? Тем более надо поститься от своего имени :)
                    0
                    Прежде всего, прошу вас держаться в рамках профессиональной дискуссии. Именовать мнение, отличное от своего «глупостью» явно плохая идея. Непонятно ваше пренебрежительное отношение к журналистам «особенно корреспондентов российских онлайн СМИ». Считать все журналистов недотепами, не разбирающимися в предмете также, простите, банально, как считать всех чиновников жуликами.

                    Также не надо передергивать: в моем тексте нет утверждения что MoReq чем-то не подходит для России. Тем более что я всегда утверждал обратное — посмотрите мои публикации и презентации за последние лет десять.

                    Ответ на свой риторический вопрос про стандарты вы найдете в законе 184-ФЗ «О техническом регулировании». Как известно, стандарты у нас — дело добровольное, ГОСТ носит рекомендательный характер. То есть нечто вроде best practice — хотите следуйте, хотите — нет. С этой точки зрения и MoReq, и стандарт 15489 являются практически полезными, но отнюдь не обязательными.

                    Проверить любую СЭД на соответствие MoReq просто — большинство требований подразумевает простой ответ, выполняется оно в системе или нет. В ИСО15489 определяются политики управления документами, а не функции системы. Странно, что это надо разъяснять. но не суть важно — к теме статьи это мало относится. Ибо какой-либо общепризнанной системы сертификации СЭД у нас не существует (полагаю, с этим вы не будете спорить), а заявления вендоров о соответствии любым стандартам могут оказаться лишь декларацией, поэтому я к ним отношусь скептически и вам советую.

                    Данная статья — это типичный white paper, написанный мной специально для компании Haulmont и они вольны распоряжаться ей по своему усмотрению, в то числе публиковать. Это обычная практика сотрудничества вендоров и консультантов. Моя профессиональная деятельность журналистикой не ограничивается.
                      0
                      Станислав, если мои слова вас оскорбили или задели, я прошу прощения, не хотел. Однако настаиваю на том, что, в вашем случае особенно, зная как обстоят дела со стандартизацией, писать «в России стандартов по ECM/СЭД нет» является глупостью или написано умышленно, правда для каких целей мне не понятно.

                      Про внешних авторов похоже тоже придется прокомментировать и в первую очередь специалистам компания Haulmont. Создавая корпоративный блог на Хабре, вы скорее всего преследуете определенные PR и маркетинговые цели. Учитывая, что Хабра — достаточно продвинутая UGC система, то что проходит на ура на многих известных площадках с заказным контентом и на сайтах собственных компаний тут мало кому интересно. Вы отлично начали, с удовольствием прочитал ваши статьи про платформу и внешние фрейморки. Продолжайте в том же духе.

                      По поводу соответствия каких-либо российских или зарубежных систем стандартам. Как мне видится ситуация на сегодняшний день, не так важна сертификация программного продукта, как научить заказчика писать требования и уже на основании этих требований искать разработчика и поставщика. Ценность стандарта MoReq именно в том, что он помогает сформулировать функциональные и нефункциональные требования и рассказывает как это делать правильно. Например в стандарте написано, что нельзя показывать не только метаданные документа, но даже намекать на наличие документа в поисковой выдаче, если на сам документ у пользователя нет прав. При задании такого вопроса пользователи с ходу говорят обратное: «да, документ не открываем, но карточку и в поиске показать можем, не страшно».
                        0
                        Станислав, здравствуйте!
                        По поводу публикаций в блоге. Вы безусловно правы, мы преследуем определенные PR и маркетинговые цели. Как и 100% зарегистрированных здесь компаний. Спасибо за теплые слова про предыдущие статьи, но на мой взгляд данная публикация также вполне соответствует правилам и принципам Хабра.

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

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

                        В связи с этим мне непонятна ваша сентенция про «то что проходит на ура на многих известных площадках с заказным контентом и на сайтах собственных компаний тут мало кому интересно». Впрочем, для этого есть объективный показатель — отзывы пользователей Хабра.
                          0
                          Вы не только оскорбили, да еще продолжаете это делать. Удивлен.
                          Если вы не видите разницы между стандартами на процессы и на системы, то не могу ничем помочь.

                          И кстати: вы практически дословно цитируете мои статьи десятилетней давности про MoReq. Да, все верно — это хороший фундамент для написания хорошего ТЗ на СЭД, занятую делопроизводством и архивом. Да, не надо в поисковой выдаче показывать даже карточку, если у человек нет прав. Более того: не надо даже учитывать в количестве найденных документов в итогах поиска, чтобы сотрудник, не имеющий доступ к документам не мог даже косвенным образом провести исследование, что хранится в базе. Я именно так и рассказывал в своих презентациях. Честно говоря, не врубаюсь — о чем вы пытаетесь со мной спорить? Кстати, не надо ли вашу систему проверить на соответствие MoReq?

                          И про ГОСТ 15489 я довольно много писал — погуглите, прежде чем кидаться в бой.

                          Но оставьте уже MoReq в покое. ECM, а нынче уже EIM — enterprise information management — понятия более широкие, чем records management. MoReq даже в версии 2010 этот домен не покрывает. Пора двигаться дальше, а не зацикливаться частном вопросе. Стандарты всегда будут отставать от технического прогресса, и это нормально. Сейчас задача автоматизации канцелярии и архива является вполне рутинной и на мой взгляд не требует обсуждения на этой площадке.

                          Гораздо интереснее посмотреть на новые применения ECM, на процессы digital transformation, которые и у нас уже проявляются в полный рост. А вы все про СЭД…

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

                Самое читаемое