Управляемый старт проекта автоматизации на базе 1С: финансы и производство

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

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

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

Мы идем от процесса таким, какой он есть. Роли. Документы. Данные. Контрольные точки. Где возникают ручные операции и расхождения. Иногда просим показать экраны и отчеты: одинаковые слова в разных подразделениях часто обозначают разные действия и разные требования к результату.

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

После каждой встречи готовим протокол. Он фиксирует принятые решения и делает их едиными для всех участников.

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

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

Со стороны бобдей на встречах работают руководитель проекта, функциональный аналитик или консультант и технический архитектор. Руководитель держит рамки и фиксирует договоренности. Функциональный специалист разбирает процесс по шагам и формулирует требования и критерии результата. Технический архитектор собирает ИТ-картину: системы, интеграции и обмены, ограничения по надежности и нагрузке.

Если периметр затрагивает отдельные контуры, мы подключаем профильных специалистов по соответствующим направлениям 1С и интеграциям. Они помогают уточнить требования, ограничения и контрольные точки там, где стандартного разбора недостаточно.

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

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

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

Следующий шаг после обследования — архитектура и смета. Здесь целевая картина превращается в план работ по этапам и приемке.

Архитектуру собираем в двух слоях. Функциональный слой отвечает на вопрос: «Что именно меняем в процессах, правилах и данных?» Технический слой отвечает на вопрос: «Как это будет работать в ИТ-ландшафте: интеграции, обмены, окна, надежность, нагрузка?»

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

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

Если этого разделения нет, разрывы превращаются в список задач. Контроль над объемом работ и сроками ослабевает.

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