Внедрение КЭДО можно разделить на два глобальных этапа. Каждый из низ важен и необходим для полноценного и правильного внедрения системы в бизнес-процессы.
Этап исследования.
На этапе исследования происходит сбор требований – важная часть любого проекта. В техническом задании необходимо описать все имеющиеся бизнес-процессы, уделив внимание интеграциям со сторонними системами. В случае возникновения запроса клиент может самостоятельно создать первоначальную версию требований, а затем обратиться к экспертам, занимающимся внедрением КЭДО. Специалисты помогут доработать документ, проведя встречи с ключевыми пользователями и используя сформировавшиеся практики по внедрению.
Стоит понимать, что пренебрежение к описанию требований приведёт к срыву сроков проекта и внедрению системы, не соответствующей изначальным запросам и, следовательно, затратам на исправление.
Этап внедрения.
Это ответственный этап проекта, который рекомендуется разделить на несколько шагов. В зависимости от масштаба проекта, вначале внедряется коробочная версия продукта с минимальными настройками и изменениями, далее выполняется доработка системы. Сроки проектов зависят как от количества необходимых доработок, так и вовлеченности команды заказчика на всех этапах проекта. Внедрение системы КЭДО может занимать от полугода и больше, а крупные проекты длятся не менее года.
Хорошей практикой является проведение пилотных проектов по внедрению систем КЭДО. Такой подход не только даст представление о преимуществах системы электронного документооборота, но и позволит выявить потенциально слабые стороны как самого решения, так и поставщика услуг. Вы получите ясное представление о процессе развертывания и проведения обновлений информационной системы, как взаимодействовать с командой поддержки, скорости реакции поставщика услуг на ваши запросы.
Что стоит учесть при внедрении?
1. Установку порядка взаимодействия.
Важно обозначить порядок взаимодействия сторон, плановые сроки и формат предоставления информации внутри проектной команды. Потребуется определить ответственных со стороны бизнеса и поставщика, ознакомить всех участников с правилами и сроками реализации проекта. Время, которое будет тратиться командой клиента следует тщательно спланировать. Пренебрежение этим аспектом приводит к затягиванию ответов, поиску ответственных во время реализации проекта и многократным корректировкам технического задания.
2. Сопутствующие расходы.
Следует обратить внимание на сопутствующие расходы, которые могут возникнуть у предприятия по мере ввода приложения в эксплуатацию. К этому разделу можно отнести лицензии и оборудование, которое потребуется приобрести, самостоятельная или с привлечением подрядчика поддержка оборудования и ПО, набор и развитие специалистов, которые будут осуществлять поддержку. Для минимизации указанных рисков рекомендуется тщательно изучить требования к приложению и необходимой инфраструктуре перед окончательным выбором поставщика и продукта.
3. Ошибки планирования.
Часто сроки внедрения ПО не соблюдаются из-за нарушения системы планирования. Участники проекта, стараясь максимально удовлетворить заинтересованные стороны, поддаются собственной чрезмерной уверенности. Нередко встречается пример, когда во главу угла ставится обязательное освоение бюджета до конца года. Эксперты, устанавливают чрезмерно короткие сроки, чтобы продемонстрировать высокий уровень профессионализма и соответствовать ожиданиям клиента. Учитывая эти особенности, руководителям проекта необходимо быть объективными и указывать остальным участникам на возможное несоответствие плана и действительности.
4. Проблемы с производительностью.
Нередко после ввода приложений в продуктивную эксплуатацию пользователи сталкиваются с заметным замедлением работы информационной системы. В этом случае проблемы могут быть связаны с несоответствием оборудования заявленным требованиям, сетевыми неполадками или с недостаточной оптимизацией логики приложения. Поэтому один из важных моментов подготовки к внедрению – получение результатов нагрузочного тестирования с указанием примененных параметров. Таким образом, на этапе проектирования важно определить, сколько пользователей сможет одновременно использовать КЭДО не только для просмотра главной страницы, но и при выполнении ресурсоемких операций.
5. Несоответствие результата и ожиданий.
Наиболее неприятный возможный сценарий для проекта – ситуация, в которой приложение в силу обстоятельств оказалось ненужным. Причиной могут быть некачественные требования или утрата актуальности в связи с долгой реализацией проекта. Противодействовать такому риску можно, применяя платформенные решения. В этом случае сокращается период поставки, переиспользуются проверенные с точки зрения бизнеса и законодательства шаблоны процессов. По мере введения приложения в эксплуатацию следует регулярно демонстрировать его стейкхолдерам. Такой подход поможет исключить вероятность несоответствий на ранних этапах.
Заключение.
На всех этапах внедрения коллектив специалистов, занимающийся внедрением КЭДО, должен быть с богатым опытом, который включает аналитиков, разработчиков, тестировщиков, DevOps инженеров и руководителей проектов.
На протяжении всего проекта внедрения системы КЭДО специалисты активно взаимодействуем с клиентом, помогая оперативно решать все возникающие сложности. Помимо услуг внедрения, также может потребоваться последующая техническая поддержка после введения в эксплуатацию систем КЭДО: решение инцидентов, выполнение сервисных запросов по настройке системы, консультации и обучение пользователей, а также взаимодействие с поставщиками программного обеспечения для решения проблем, связанных с ядром системы.