Бизнес‑анализ · AS‑IS · TO‑BE · первая волна

Функциональное обследование 1С до первой строки кода

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

Разобрать один процесс Посмотреть метод обследования

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

Процесс · контрольный пример цепочка подтверждена

ВопросПочему растёт срок?решение руководителя

Наблюдение5 ролей · 4 системыреальный маршрут

РезультатПервая волнаграница и приёмка

Заказ клиентаобещаемый результат и срок

Вход

Решение ролиExcel + согласование в чате

Разрыв

Факт в 1Сввод после выполнения

Запаздывает

Целевой процессфакт запускает следующее действие

Готов

1 процессот входа до результатадо 5 ролейв проверке7 материаловдля принятия решения0 строк кодапока не найдена причина

Ролевая линза

Один проект. Четыре критерия правильного решения.

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

Эффект и граница инвестиций

Покажем, какой разрыв действительно стоит менять и где можно остановиться.

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

Фокус решения: Цена разрыва, риск бездействия и граница первой инвестиции
Главная метрика: Время цикла, ошибка, ручной труд или стоимость задержки
Результат первого шага: Карта приоритетов и решение по первой волне

Перейти к протоколу доказательства

Карта решения01 / 04

01Какой процесс теряет результат
02Сколько стоит подтверждённый разрыв
03Когда масштабировать или остановиться

Управленческий выходИнвестировать только в доказанное изменение

Дорогие симптомы

Процесс уже изменился, а 1С и ответственность остались в прошлом

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

01Excel стал частью процесса

Решение принимают вне 1С, а результат заносят постфактум

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

Бизнес зависит от личных файлов, а автоматизация не видит реальный маршрут работы

02Один факт вводят несколько раз

Подразделения поддерживают разные версии одного события

Заказ, потребность, срок или статус повторно переносят между документами, базами и таблицами. Ошибка обнаруживается уже в отчёте или у клиента.

Повторный труд растёт, но причина ошибочно выглядит как нехватка ещё одной формы

03Отчёт начинается со сверки

Цифра есть, но руководитель не может проверить её происхождение

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

Управленческое решение запаздывает и опирается на договорённость, а не на единый факт

04Очередь задач растёт быстрее эффекта

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

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

Бюджет разработки превращается в постоянную поддержку исторической неэффективности

Короткий ответ

Что такое функциональное обследование 1С?

01Факт02Разрыв03Цена04Целевая модель

Функциональное обследование 1С — это исследование реального бизнес‑процесса до разработки: его границы, ролей, решений, данных, действий в системе и вне её, дорогих разрывов и минимально достаточного целевого сценария.

Один процесс проходит от события до результата
Выводы подтверждаются рабочими примерами
Причина отделяется от пожелания и решения
Первая волна имеет критерий приёмки

Границы обследования

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

Шесть осей не дают исследованию превратиться в набор интервью. Для каждой остаётся конкретный факт, владелец и способ проверки.

Цель и метрика

Какое решение должен улучшить процесс и по какому факту это будет видно.

Граница

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

Роли и решения

Кто создаёт факт, кто меняет его смысл и кто отвечает за итог.

Данные и документы

Откуда приходит информация, где дублируется и чему можно доверять.

Система и обходы

Что выполняет 1С, что живёт в Excel, почте, бумаге и личной памяти.

Цена и приоритет

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

Интерактивное прослеживание

Каждый вывод можно провести обратно к факту рабочего процесса

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

Слой 01 · управленческий вопрос

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

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

Есть одно событие запуска и один результат
Назначен владелец сквозного эффекта
Метрика связана с управленческим решением

Трасса процесса01 / 04

01ОснованиеВопрос руководителя02ПроверкаНачало и конец03КонтрольВладелец результата

Доказанный разрывУчастники считают границей разные процессыБез единой границы требования продолжают расти уже во время разработки.

Результат этапаПаспорт процесса и критерий результата

Продуктовый первый шаг

01 / Функциональное обследование

Обследование за 10 рабочих дней

Ограничиваем работу одним сквозным процессом и пятью ключевыми ролями. Этого достаточно, чтобы доказать причины, спроектировать TO‑BE и подготовить первую волну к оценке и приёмке.

Срок10 рабочих днейОбъём проверки1 процесс · до 5 ролейНа выходе7 рабочих материалов

Решение после обследованияизменить процесс / настроить 1С / доработать / не инвестировать

Зафиксировать границу процесса

Паспорт процесса

Вопрос, граница, владелец, участники, метрика и критерий завершения.

Карта AS‑IS

Реальный путь одного примера по ролям, системам, данным и исключениям.

Матрица доказательств

Ссылка каждого вывода на интервью, экран, документ, замер или наблюдение.

Реестр разрывов

Причина, частота, влияние, владелец и приоритет без смешения с решением.

Модель TO‑BE

Целевой сценарий, новые правила, роли и минимально необходимые изменения 1С.

Матрица решений

Организационное правило, типовой механизм, настройка или доработка — с аргументами.

Маршрут первой волны

Граница реализации, критерии приёмки, риски, зависимости и порядок запуска.

Причина до разработки

Не каждый разрыв нужно закрывать программным кодом

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

PСлой 01

Процесс

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

DСлой 02

Данные

Факт появляется поздно, дублируется, не имеет источника либо одинаковое поле означает разные вещи.

TСлой 03

Типовой механизм

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

CСлой 04

Код и интеграция

Уникальная ценная логика действительно не покрывается типовым решением или системам нужен новый контракт.

Целевой процесс

1С фиксирует тот факт, который действительно меняет решение

В целевой модели данные не собираются «на всякий случай». Каждый факт появляется у ответственной роли в нужный момент, запускает следующее действие и остаётся проверяемым до результата.

Одно событие запускает сквозной сценарий
Роль видит основание и допустимое действие
Исключение получает владельца и срок решения
Метрика раскрывается до первичного факта

Управленческий результатРуководитель видит не новый интерфейс, а сокращённый цикл, устранённый повторный труд и объяснимое состояние процесса.

Целевой сценарийсобытие → решение → результат

01СобытиеПроверенный вход02РешениеРоль и правило03Действие1С или интеграция04РезультатМетрика и владелец

Маршрут обследования

Десять дней от вопроса руководителя до реального первого этапа

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

01
День 1
Зафиксировать вопрос и границу
Выбираем один сквозной процесс, его владельца, событие запуска, результат и доступный реальный пример.
Паспорт и план наблюдений
02
Дни 2–4
Пройти процесс как он работает
Ключевые роли показывают действия, документы, обходы, ожидания и исключения на одном фактическом сценарии.
Карта AS‑IS и доказательства
03
Дни 5–6
Отделить причины и экономику
Группируем разрывы по слою, оцениваем частоту, повторный труд, задержку, ошибку и бизнес‑влияние.
Приоритетный реестр разрывов
04
Дни 7–8
Собрать целевой сценарий
Сравниваем организационное изменение, типовой механизм, настройку, интеграцию и минимальную доработку.
TO‑BE и матрица решений
05
Дни 9–10
Спроектировать первую волну
Фиксируем самостоятельный результат, критерии приёмки, зависимости, риски и данные для оценки реализации.
Исполнимый маршрут изменений

Как доказываем готовность

Обследование закончено, когда четыре ответа выдерживают проверку

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

01
Где факт?Вывод связан с реальным примером, документом, экраном или замером.
02
Почему это разрыв?Показано влияние на срок, деньги, ошибку, обязательство или повторный труд.
03
Почему это решение?Сравнены правило процесса, типовой механизм, настройка и разработка.
04
Как принять результат?Первая волна имеет сценарий, метрику, допуски и ответственного владельца.

«Команда настоящих профессионалов: разбирается в бизнес‑процессах и учитывает специфику бизнеса».
Власов Иванруководитель IT‑департамента, ГК «ЖЕЛЕЗНО»

«Доверяем команде за внимание к деталям и индивидуальный подход к нашему делу».
Сметанина Светланаглавный бухгалтер, НЛК

«Команда проработала план перехода, предусмотрела наши пожелания и успешно его реализовала».
Солмашенко Светланакоммерческий директор, Miko

Короткие ответы

Что спрашивают перед функциональным обследованием

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

Задать свой вопрос

01Что такое функциональное обследование 1С?

Это исследование реального бизнес‑процесса до разработки: его границы, ролей, решений, данных, действий в 1С и вне системы, дорогих разрывов и целевого сценария. Результатом становится не отчёт ради отчёта, а подтверждённый маршрут минимально достаточных изменений.

02Чем функциональное обследование отличается от технического аудита 1С?

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

03Почему нельзя сразу написать техническое задание?

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

04Кто должен участвовать в обследовании?

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

05Какие материалы и доступы потребуются?

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

06Сколько длится обследование?

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

07Можно ли заказать обследование отдельно от разработки?

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

08От чего зависит стоимость обследования?

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

Материал проверенБизнес‑процесс · функциональная модель · граница автоматизации

Методика сверена с опубликованным материалом IT‑Сервис о функциональном моделировании в ERP‑проектахи официальным маршрутом фирмы «1С» по реальной автоматизации. Неподтверждённые показатели эффекта не используются; каждый вывод привязан к процессу, факту и критерию следующего решения.

Актуализировано03.08.2026

Первый проверяемый шаг

Разберём один процесс до оценки разработки

За 45 минут зафиксируем событие, результат, ключевые роли и место, где процесс теряет управляемость. После встречи останется граница обследования и список фактов для точного старта.

Один сквозной процесс вместо списка всех пожеланий
До пяти ролей и один реальный контрольный пример
Без обязательства передавать нам последующую разработку

Обследование одного сквозного процесса01 / 01

Какой симптом сейчас ближе к вашей задаче?

Процесс держится на Excel и ручных передачахУправленческий отчёт требует постоянной сверкиПланируем внедрение ERP или КАДоработок много, а эффект не виден

Ваше имяКомпания

Телефон или рабочая почтаЧто сейчас происходит?

Ответим в рабочее время. До встречи пришлём короткий список данных, чтобы разговор был предметным.