Чек-лист по интеграции сервисов обмена с ИТ-инфраструктурой
За развитие информационных технологий в компании отвечает ИТ-директор. От него требуется как обеспечить внедрение инновации, так и поддержать работу существующих систем. В том числе если это касается подключения сервиса обмена электронными документами.
За эффективность и развитие информационных технологий в компании отвечает ИТ-директор. От него требуется обеспечить как внедрение инновации, так и поддержать работу уже существующих систем. То же самое касается сервисов обмена электронными документами, которые необходимо интегрировать с текущей ИТ-инфраструктурой предприятия.
Представим ситуацию. Иван Семёнович – ИТ-директор ООО «Ромашка». Однажды к нему обращается главный бухгалтер: «Мои сотрудники устали работать с бумагой, нам нужно что-то менять! Что можете предложить?». Иван Семёнович отвечает: «Есть два варианта. Первый – переход на электронный документооборот (ЭДО) через сервисы обмена. Второй – уволить недовольных бухгалтеров и нанять новых». Заменить бухгалтеров – это, конечно, интересное решение, но кто же даст это сделать. Да и новые сотрудники будут просить о том же… Иван Семёнович и главбух решают остановиться на первом варианте – внедрении сервиса обмена электронными документами, который придётся состыковать с уже используемыми системами. |
На примере, описанном выше, рассмотрим основные правила интеграции внешнего ЭДО с существующим внутренним документооборотом в компании. Поскольку внедрение сервиса обмена – это не операционная деятельность, а проект, то начнём с присущих ему правил.
Определите рамки проекта
Цели и задачи
Для начала определитесь с заказчиком. В данном случае – это бухгалтерия. Теперь определим цели и задачи, которые нужно решить:
- ускорить работу с первичными учетными документами (ПУД);
- освободить бухгалтерию от рутины;
- сделать все процессы прозрачнее;
- организовать электронный архив документов;
- или необходимо сделать всё перечисленное?
От определения целей и задач будут строиться вся ваша дальнейшая работа, планирование и определение бюджета.
Не забывайте постоянно подключать заказчика для формирования окончательных функциональных требований. Главный бухгалтер должен быть в курсе всех изменений, проект реализуется в первую очередь для него.
Бюджет проекта
Не забываем, что бизнес смотрит на ИТ-службу как на центр затрат и в любой момент может перекрыть путь к её инновациям. Поэтому на первом этапе нужно рассчитать, хватит ли выделенных средств на выполнение всех задуманных решений и «хотелок» заказчика. Без определения максимальной суммы непонятны рамки трансформации, сложно сформировать окончательный список требований к проекту.
Ресурсы проекта
Задайте себе вопросы: «Как и какими силами внедряем продукт? Своими или привлекаем специалистов со стороны?»
Что должен сделать ИТ-директор, который приступает к внедрению сервиса обмена и интеграции с иным ПО:
1. Сформировать команду с чёткими ролями на проекте, спланировать её работу.
2. Проработать компетенции специалистов, обучить либо нанять новых сотрудников конкретно для этого проекта, так как сервисы обмена – специфические продукты. И лучше, если за внедрение будет отвечать специалист в области электронного документооборота.
3. Так как мы встраиваем ЭДО уже в существующую систему внутреннего документооборота, требуется синхронизировать сотрудников, отвечающих за поддержку внутренней инфраструктуры, с командой внедрения нового продукта. Это нужно для сохранения работоспособности действующей системы и её поддержания в актуальном состоянии.
Учесть меняющееся законодательство. Необходимо выделить ответственного, который будет следить и информировать о любых изменениях, так как эти они могут повлиять на разработку интеграции с сервисами обмена.
Помните про сроки. Рассчитывая время реализации проекта, отталкивайтесь от объёма работ, выделенной команды, бюджета и требований, предъявленных заказчиком. |
Оцените готовность компании работать с сервисами ЭДО
Может, всё же по старинке? Нет!
После того, как вы определитесь с рамками проекта, нужно учесть особенности перехода на взаимодействие с ЭДО:
1. Предусмотреть использование нескольких сервисов обмена электронными документами, которые обладают своими особенностями. Будут это разные клиенты взаимодействия либо подойдёт работа в роуминге? Или какой-то другой инструмент, собирающий все входящие документы из разных сервисов и отправляющий их в нужные системы?
2. Рынок электронного документооборота в России молодой, развивающийся, и меняющийся. Требуется постоянно мониторить изменения законодательства в данной области.
3. Проработать действующую базу контрагентов. Нужно выяснить, работают ли они с электронным документооборотом? Переход на ЭДО – это, конечно, хорошо. Но он должен быть совместным. Если вам будет не с кем обмениваться документами, то какой в этом смысл?
4. Проверить возможности действующей системы. Возможно, у неё есть коннекторы к сервисам обмена, которыми можно воспользоваться.
5. Оценить готовность инфраструктуры к изменениям. Ограничение ресурсов и бюджета – может оказаться нелегко найти оборудование и ПО, необходимые для подлинной трансформации бизнеса. Данный вопрос прочно связан со следующим правилом.
Учтите проблемы интеграции сервисов с вашей архитектурой
Очень важный момент. Как внедрить новый инструмент в уже отлаженную инфраструктуру и обеспечить работоспособность системы на время ведения проекта? Давайте рассмотрим конкретно на ситуации Ивана Семёновича. Какие вопросы ему придётся решить:
1. Выбор системы, с которой нужно взаимодействовать. Только с ERP системой или ECM. Также можно рассмотреть взаимодействие ЕСМ + ERP.
2. Разделение зоны ответственности систем: какие документы, где они создаются и согласовываются. Нужно выяснить, откуда будут отправляться документы в сервис обмена, а также как настроить разделение обязанностей по работе с документами внутри инфраструктуры предприятия (что именно и где согласовываем).
3. Каждый сотрудник хочет выполнять как можно меньше действий, переключений между окнами. При проектировании новой архитектуры потребуется анализ возможности работы в одном интерфейсе.
4. Проработка чёткого ТЗ, согласованного с заинтересованными лицами.
5. Обеспечение работоспособности системы на протяжении всего проекта. Сотрудники не должны сталкиваться с проблемами в операционной работе. Это может вызвать негатив, а также невыполнение текущих задач руководства.
Уточните условия и сложности сопровождения
Во время внедрения ЭДО в существующую архитектуру нужно инициировать работы по сопровождению системы. Основные вопросы, которым требуется уделить внимание:
1. Обучение пользователей новой функциональности. Нужно показать все плюсы нового инструмента. Подробно объяснив, чего можно добиться и как упростится работа с использованием ЭДО, можно получить сторонников системы, которые будут продвигать решение в компании.
2. Подготовка качественной документации не только о том, как устроена система, но и о принципах работы для пользователей и администраторов, то есть инструкций.
3. Новые обязанности сотрудников закрепляем приказами.
4. Подготовка технических специалистов для поддержки системы. Хорошо, если вы внедряли ЭДО своими силами и у вас уже есть специалисты, которые реализовали проект. Но если же его вели подрядчики, то требуется дополнительно обучить специалистов для поддержки системы.
5. Проработка дальнейших шагов развития инфраструктуры.
Итак, Иван Семёнович, как и вы, дочитал наш чек-лист и теперь понимает, что внедрение ЭДО в существующий внутренний документооборот в компании – это сложный процесс с множеством нюансов. И чтобы успешно внедрить новый продукт, нужно уделить внимание всем моментам, перечисленным выше. Напоследок рекомендуем всем, кто стартует интеграцию сервисов обмена с ИТ-инфраструктурой предприятия, постоянно мониторить ход работ. Всё-таки внедрение нового инструмента – это всегда живой, постоянно меняющийся процесс. |
Комментарии 2
Кстати интеграция может пройти и вполне легко, если, например, СЭД к этому готова. Тут Иван-администартор, а может быть тот же Иван Семенович, делает следующих 4 шага по инструкции -- Добавляем к СЭД внешний документооборот - легко!
Тут хотелось бы уточнить. Все же первым шагом, мне видится как раз сбор этих "хотелок" - требований. Далее расчет трудоемкости на их реализацию, после чего устанавливаем максимальную цену бюджета проекта и следующим шагом приоритезируем требования - устанавливаем рамки проекта.
И на этом этапе важно выделить отдельного участника, ответственного за сбор требований - аналитика. Почему нужен отдельный ответственный? - потому что бизнес-заказчик должен формулировать цели и задачи - конечный бизнес-эффект, и не должен продумывать логику и сущности будущей системы (например, эта функция выполняется по кнопке в правом верхнем углу). А разработчики должны в итоге получить максимально подробное ТЗ, по которому без вопросов можно разработать систему. И если формулирование детальных требований к системе повесить на бизнес-заказчика или на разработчиков, то вероятен риск сделать что-то, что не покрывает конечную цель, либо покрывает не оптимально