Решения, связанные с электронным документооборотом, — неотъемлемая часть современного корпоративного ландшафта. О развитии систем ЭДО и особенностях их внедрения рассказывает руководитель направления систем управления корпоративным контентом IBS Алексей Коноплев.
Электронный документооборот используется сейчас практически в каждой компании. Обмен информацией с контрагентами, подготовка договоров, кадровые процессы — все это уже автоматизировано. Однако современные требования к управлению корпоративным контентом выходят далеко за рамки традиционного документооборота.
Функции подобных систем уже не ограничиваются обеспечением безопасного хранения информации и маршрутизацией документов между сотрудниками. Такая платформа становится органичной надстройкой над учетной системой. Ее задача — консолидировать внешний и внутренний контент, создаваемый компанией, с последующей интеграцией в бизнес-контекст.
К примеру, любой договор — это не просто отдельный документ. Его утверждению предшествуют подготовительные процедуры: согласования, проведение тендеров и т.п. Далее следуют исполнение обязательств, подписание закрывающих документов, выпуск дополнительных соглашений и другие операции. Система управления корпоративным контентом должна оцифровывать все эти процессы, устанавливать логические связи между документами и предоставлять пользователям доступ к информации в удобном формате с учетом их полномочий.
Программные решения для управления корпоративным контентом активно развиваются. В них появляются новые возможности:
Переход на новую систему управления корпоративным контентом может быть вынужденным или осознанным решением.
К вынужденным причинам относится в первую очередь импортозамещение. Оно может быть связано с уходом вендора либо с требованиями регулятора по использованию отечественного ПО и хранению данных внутри страны. Перейти на новую платформу может вынудить также моральное и техническое устаревание используемого ПО. Многие системы, внедренные 15–20 лет назад, уже не соответствуют современным требованиям, в том числе по производительности.
К причинам осознанного перехода можно отнести технологические и архитектурные особенности текущего решения. К примеру, система функционирует, но ее дальнейшее развитие и масштабирование оказываются нецелесообразными. Финансовые факторы также играют важную роль. Совокупные расходы на поддержку нескольких продуктов могут быть выше, чем внедрение экосистемы унифицированных решений. Кроме того, важным стимулом для перехода становятся запросы бизнеса. Если появляется более удобное решение, пользователи могут инициировать его внедрение. Например, платформы с возможностями low-code-разработки позволяют добавлять новые функции без помощи разработчиков.
В то же время переход на новое решение может вызывать ряд опасений, таких как:
К примеру, достаточно часто у компаний возникают опасения по поводу технологических возможностей нового решения и его соответствия масштабу бизнеса. Развеять сомнения можно с помощью референсных встреч, где потенциальные пользователи смогут пообщаться с теми, кто уже использует это решение.
На проектах по внедрению новых систем важно грамотно управлять изменениями. Пользователи могут сопротивляться переходу из-за того, что привыкли работать определенным образом. Нужно обучить их работе с новой платформой, показав, что она помогает отказаться от трудоемких операций. Также следует организовать обучение для сотрудников внутренней ИТ-службы, которые поддерживали прежнее решение.
Процесс внедрения нового решения — сложный, требующий тщательной подготовки. Необходимо заранее определить ключевые вехи: сроки появления первых документов, сбор окончательных требований, старт проекта и т.д. Кроме того, успех внедрения во многом зависит от грамотно выстроенной коммуникации между участниками процесса.
Формирование проектной команды и распределение ролей
В команде обязательно должен быть спонсор проекта — человек, который обладает полномочиями для принятия окончательных решений. Он отвечает за стратегические вопросы, бюджет и общий контроль внедрения.
Владельцы бизнес-процессов — ключевые заинтересованные лица, которые непосредственно будут работать с системой. Их участие критично, поскольку именно они формируют требования и участвуют в выстраивании процессов. Немотивированное или недостаточное вовлечение этих специалистов может привести к тому, что итоговое решение будет неэффективно работать.
Руководитель проекта от заказчика контролирует архитектуру, управляет работами и взаимодействует с внешним исполнителем или внутренней командой. Он несет ответственность за сроки, концепцию и итоговый результат внедрения.
Дополнительную ценность вносят бизнес-эксперты. Также в состав проектной команды могут входить внутренние ИТ-специалисты.
Состав команды и роли могут уточняться в процессе работы, особенно если в ходе проектирования появляются новые бизнес-процессы, требующие вовлечения дополнительных участников.
Формулирование целей внедрения
Цели проекта — это ориентиры, которые будут сопровождать его на всех этапах. При их формулировке важно достичь взаимопонимания относительно возможностей будущей системы, чтобы избежать затрат на внедрение функциональности, которая не отвечает потребностям бизнеса.
Цели должны быть простыми и понятными. Например, сокращение затрат за счет отказа от бумажного документооборота при взаимодействии с ФОИВ.
Определение организационного и функционального объема
После того как цели определены, необходимо декомпозировать их на функциональный и организационный объем.
Проект внедрения часто влечет за собой организационные изменения, которые могут существенно повлиять на работу подразделений. Такие изменения важно запланировать заранее.
Если в текущих бизнес-процессах не автоматизировано какое-то направление, его можно включить в проект для автоматизации. У внутренней ИТ-службы, как правило, есть бэклог изменений и пожеланий пользователей. Важно оценить, насколько эти изменения применимы и приоритетны для реализации проекта.
Подготовка проектных документов
Когда собрана вся необходимая информация и получена обратная связь, можно переходить к подготовке проектных документов. На этом этапе, как правило, уже есть понимание, как будет выглядеть техническое задание проекта. Вместе с ним обычно формируется реестр функциональных и нефункциональных требований, модели бизнес-процессов, технические регламенты, концепция миграции и т.д.
Определение ключевых показателей успешности внедрения
Нужно также сформировать критерии, по которым будет оцениваться успех проекта. Они должны соответствовать основным целям компании. Например, сокращение затрат на поддержку на 20% через год после внедрения.
Существует несколько вариантов перехода на новое решение, каждый из которых имеет свои плюсы и минусы.
Параллельное использование
Этот подход предполагает одновременную работу с обеими системами до момента стабилизации внедренного решения. Он является комфортным с точки зрения внутренней службы, так как позволяет избежать резких изменений. Однако бизнес чаще всего выступает против такого подхода, поскольку наличие двух систем требует значительных трудозатрат.
Поэтапный переход
На новую платформу постепенно переводится один бизнес-процесс за другим, начиная с тех, которые можно перенести без значительных потерь. В процессе перехода выявляются и устраняются ошибки. Такой вариант является более щадящим и управляемым, хотя и занимает больше времени.
Большой взрыв (Big Bang)
В этом случае определяется конкретная дата старта и переход на новую систему выполняется одномоментно, а не поэтапно. Вариант самый быстрый, но рискованный и иногда безальтернативный. Например, когда уходит вендор и использование прежнего продукта становится невозможным. При таком варианте перехода высока вероятность нестабильной работы системы, особенно в первое время, поэтому он требует согласованности действий всех участников проектной команды. Всегда под рукой должен быть актуальный реестр рисков. Особое внимание следует уделять рискам с высокой степенью влияния. По каждому из них стоит запланировать компенсирующие мероприятия, а все члены команды должны понимать, как действовать в экстренной ситуации.
Оптимальный формат перехода — гибридный: поэтапный перевод бизнес-процессов в новую систему при параллельном использовании обоих решений в критически важных операциях.