Как успешно внедрить 1С:Документооборот: 7 принципов на примере СГМК

Почему похожие проекты заканчиваются по-разному?

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

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

Хорошо увидеть эти принципы можно на примере СГМК. Компания перевела на 1С:Документооборот 3.0 единый контур, которым пользуются 1500 сотрудников в 70 организациях. Через систему ежемесячно проходит около 10 тысяч документов. При таком масштабе даже небольшая ошибка в организации проекта могла заметно повлиять на результат.

Разберем, какие решения помогли команде довести проект до успешного запуска.

1. У проекта должен быть человек, который может принять решение
2. Не переносить старую систему один в один
3. Сначала искать решение в типовых возможностях системы
4. Нужно заранее договориться, как будет работать команда
5. Заказчик должен участвовать в проекте, а не только принимать результат
6. Приемка должна быть понятной и проверяемой
7. Проект должен закончиться не запуском, а передачей системы
Что в итоге делает проект успешным

Во время внедрения постоянно возникают вопросы, на которые нельзя ответить только с технической точки зрения.

Нужно ли сохранять старый процесс? Можно ли изменить привычный маршрут согласования? Кто отвечает за новый справочник? Какой вариант выбрать, если подразделения хотят разного?

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

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

На проекте СГМК решения не оставались только на стороне подрядчика. Команда заказчика активно участвовала в проектировании системы, а разработчики СГМК — в проверке кода. Это помогало быстрее обсуждать спорные вопросы и сразу учитывать, как новая система будет работать внутри компании.

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

Переход на новую версию часто воспринимают как переезд: нужно взять все, что есть в старой системе, и аккуратно перенести в новую.

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

Именно поэтому переход стоит начинать не с вопроса «как это перенести?», а с другого:
Нам вообще нужно сохранять этот процесс в прежнем виде?

До проекта СГМК система была сильно изменена. Многие доработки находились прямо в основной конфигурации. Из-за этого обновления стали сложными и выходили примерно раз в полтора года. ИТ-команда тратила много времени на поддержку уже написанного кода вместо развития системы.

При переходе на редакцию 3.0 команда не стала копировать старую систему. Требования и новую модель работы проектировали заново. Существующие доработки пересмотрели, а часть из них убрали, потому что нужные возможности уже появились в типовом решении.

В результате старый технический долг не переехал в новую систему под другим названием.

Практический вывод: миграция — хороший момент, чтобы навести порядок, а не только сменить версию программы.

Почти на каждом проекте появляются запросы, которые начинаются словами:

«У нас это всегда работало немного по-другому».

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

Каждая доработка требует разработки, проверки и дальнейшей поддержки. А при обновлении нужно снова убеждаться, что она не перестала работать.

В СГМК команда заранее договорилась о простом правиле: любую задачу сначала пытались решить стандартными средствами 1С:Документооборота 3.0. К доработке переходили только тогда, когда типовых возможностей действительно не хватало. При этом основную конфигурацию не меняли — необходимые дополнения выносили в расширения.

Такой подход заметно изменил систему.

Например:

• вместо доработанного рабочего стола появились десять типовых реестров;

• для документов настроили полный цикл обработки;

• ручную маршрутизацию заменили автоподстановками;

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

• совместителей оформили как отдельных сотрудников с собственными правами.

Это не значит, что команда полностью отказалась от доработок. Она отказалась от доработок без достаточной причины.

Практический вывод: хороший вопрос для каждой новой задачи — «что произойдет, если мы оставим типовой вариант?». Очень часто окажется, что он уже решает проблему.

Функциональные требования отвечают на вопрос, что должна уметь система.

Но для управления проектом этого мало.

Нужно также договориться:

• кто готовит материалы;

• кто их проверяет;

• сколько времени занимает согласование;

• как фиксируются решения;

• кто отвечает за данные;

• что происходит, если сроки нарушены;

• по каким каналам общается команда.

Без этих правил даже понятный проект постепенно теряет управляемость. Одни участники ждут документ, который другие не знали, что должны подготовить. Заказчик считает вопрос согласованным, а подрядчик ждет подтверждения. Замечания остаются в переписке и возвращаются через несколько недель.

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

Проект СГМК строился как совместная работа, а не как передача задания подрядчику. Аналитики заказчика участвовали в проектировании, разработчики — в код-ревью, специалисты Академии передавали знания внутренней команде.

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

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

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

Поэтому проект нельзя строить по схеме:

1. заказчик рассказал, чего хочет;

2. подрядчик ушел работать;

3. через несколько месяцев показал готовую систему.

За это время могут измениться требования, сотрудники — иначе понять договоренности, а отдельные решения — оказаться неудобными в реальной работе.

В проекте СГМК внутренняя команда участвовала в работе на всех этапах. Новую систему проектировали вместе. Разработчики заказчика проверяли доработки. Администраторы и пользователи прошли 25 учебных сессий.

Благодаря этому после запуска компания получила не только настроенную базу, но и людей, которые понимали, как она устроена и как ее развивать дальше.

Такое участие помогает и во время проекта. Чем раньше заказчик видит решение, тем раньше можно обнаружить расхождения и изменить подход без дорогой переделки.

Практический вывод: участие заказчика — это не только согласование документов. Это совместное проектирование, проверка решений и подготовка своей команды.

Фраза «система должна работать корректно» звучит разумно, но проверить ее невозможно.

Что именно значит «корректно»? Какой результат считается принятым? Какие сценарии должна пройти команда? Кто подтверждает выполнение требований?

Если ответы не зафиксированы заранее, ближе к завершению проекта у сторон могут появиться разные представления о готовности системы.

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

В проекте СГМК результат подтверждали не общими формулировками, а приемо-сдаточными испытаниями. Для функциональных блоков подготовили сценарии тестирования. Из 313 требований выполнили 289 — это 92%. Проект завершили в рамках утвержденного бюджета.

Так приемка стала не спором о впечатлениях, а проверкой конкретного результата.

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

Запустить систему — еще не значит завершить внедрение.

После запуска кто-то должен:

• поддерживать пользователей;

• разбирать ошибки;

• обновлять систему;

• менять маршруты;

• подключать новые процессы;

• понимать, какие решения были приняты и почему.

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

Поэтому передавать нужно не только базу, но и знания.

По итогам проекта СГМК получила:

• настроенную и протестированную систему;

• проектные решения и требования;

• сценарии испытаний;

• инструкции для пользователей и администраторов;

• обученную команду поддержки.

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

Практический вывод: один из главных результатов внедрения — способность заказчика самостоятельно работать с новой системой после ухода проектной команды.

Успешное внедрение редко держится на одном ярком решении.

Обычно результат складывается из более простых вещей:

• решения принимаются быстро;

• роли понятны;

• заказчик работает вместе с подрядчиком;

• старые процессы не переносят автоматически;

• доработки делают только там, где они нужны;

• результат можно объективно проверить;

• внутренняя команда готова поддерживать систему после запуска.

Проект СГМК показывает, какой эффект дает сочетание этих принципов.

Переход прошел одномоментно для всех организаций и без остановки документооборота. В новой системе работают 1500 пользователей. Она обрабатывает около 10 тысяч документов и более 8 тысяч процессов в месяц. Внутри этих процессов система выполняет около 70 тысяч автоматических действий, а примерно 4 тысячи задач по регистрации документов проходят без участия пользователей.

Но главный результат проекта не только в цифрах.

СГМК не просто перешла на новую редакцию. Компания пересобрала процессы, сократила количество лишних доработок, подготовила внутреннюю команду и создала систему, которую можно обновлять и развивать дальше.

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

Сейчас он участвует в конкурсе «Проект года». Поддержать проект можно по ссылке: https://eawards.1c.ru/projects/kogda-sistema-ne-tormozit-biznes--masshtabnyy-perehod-ao-sgmk-na-1s-dokumentooborot-red-30-388140/.