Предпроектное обследование — это анализ текущих бизнес-процессов, информационных систем, данных и требований предприятия до начала внедрения или крупной доработки 1С. Его результатом должен стать не общий отчёт о проблемах, а практическая дорожная карта: что автоматизировать, в какой последовательности, какими силами и с каким ориентировочным бюджетом.
Без обследования проект часто начинается со списка пожеланий отдельных подразделений. Бухгалтерия хочет сократить закрытие месяца, производство — видеть загрузку оборудования, склад — устранить расхождения, руководство — получать управленческую отчётность без Excel. Если эти требования не объединить в одну целевую модель, предприятие рискует получить набор локальных доработок вместо единой системы управления.
Что такое предпроектное обследование 1С
Предпроектное обследование — самостоятельный этап подготовки автоматизации. Команда проекта изучает, как предприятие работает сейчас, фиксирует проблемы и ограничения, определяет целевую модель процессов и оценивает разрыв между текущим состоянием и возможностями будущей системы.
Обследование необходимо проводить не только перед внедрением 1С:ERP. Оно полезно перед:
- заменой устаревшей конфигурации;
- объединением нескольких баз;
- автоматизацией управленческого учёта;
- внедрением складской или производственной подсистемы;
- интеграцией 1С с WMS, MES, CRM и другими системами;
- масштабной переработкой существующего решения;
- переходом на централизованный учёт группы компаний.
Официальная функциональная модель 1С:ERP охватывает производство, финансы, закупки, продажи, склад, бюджетирование и другие направления. Поэтому перед внедрением важно определить не только перечень функций, но и взаимосвязи между подразделениями и владельцами данных.
Когда предприятию необходимо обследование
Обследование особенно важно, если присутствуют несколько признаков:
- данные распределены между 1С, Excel и внешними сервисами;
- одни показатели рассчитываются разными подразделениями по разным правилам;
- закрытие месяца зависит от ручных корректировок;
- неизвестно, какие доработки действительно используются;
- отсутствует полная документация по обменам и интеграциям;
- отчётность формируется после дополнительных выгрузок и обработки данных;
- невозможно заранее оценить стоимость будущего проекта;
- предприятие выросло, но архитектура учётной системы осталась прежней;
- внутренний IT-отдел занят текущей поддержкой и не может подготовить проект изменений.
Само по себе наличие старой программы ещё не означает, что нужно немедленно внедрять ERP. Сначала необходимо понять, является ли причиной проблем программный продукт, методология учёта, качество данных, процессы или распределение ответственности.
Почему нельзя начинать со списка доработок
Формулировка «нам нужен новый отчёт» не описывает бизнес-задачу. До разработки необходимо установить:
- кто принимает решение на основании отчёта;
- какие показатели ему нужны;
- откуда поступают исходные данные;
- кто отвечает за их качество;
- когда отчёт должен быть готов;
- какие действия выполняются после его получения.
Иногда проблема решается настройкой типового функционала или изменением процесса. В других случаях требуется переработка модели учёта, интеграция нескольких систем или новая архитектура данных.
Если подрядчик сразу оценивает список доработок, не изучая процессы, заказчик получает цену программирования, но не стоимость решения бизнес-задачи.
Что входит в предпроектное обследование 1С
Анализ целей бизнеса
Проект начинается с управленческих целей, а не с выбора экранов и документов.
Цели должны быть измеримыми. Например:
- сократить срок подготовки управленческой отчётности;
- получать себестоимость по продуктам, заказам или направлениям;
- исключить повторный ввод данных;
- повысить достоверность складских остатков;
- связать планы продаж, закупок и производства;
- централизовать учёт нескольких юридических лиц;
- сократить количество ручных сверок.
Формулировка «внедрить 1С:ERP» не является полноценной целью. ERP — инструмент, а не самостоятельный результат.
Описание процессов AS IS
AS IS — описание того, как процессы работают сейчас.
Команда обследования фиксирует:
- участников;
- документы;
- последовательность операций;
- используемые системы;
- точки ручного ввода;
- согласования;
- контрольные процедуры;
- исключения;
- проблемные участки.
Особое внимание необходимо уделять не только стандартному маршруту, но и отклонениям: возвратам, пересортице, перепланированию производства, изменению заказа, отмене поставки и ручным корректировкам.
Именно исключения часто становятся источником основной сложности будущего проекта.
Инвентаризация информационных систем
Необходимо составить карту текущего IT-ландшафта:
- конфигурации и версии 1С;
- количество баз;
- доработки;
- расширения;
- внешние обработки;
- обмены;
- серверная инфраструктура;
- базы данных;
- личные кабинеты и внешние сервисы;
- WMS, MES, CRM, BI и другие решения;
- мобильные приложения и оборудование.
По каждой системе определяют её назначение, владельца, критичность и источники данных.
Анализ качества данных
Даже правильно настроенная система не даст достоверной отчётности, если в ней:
- дублируются номенклатура и контрагенты;
- отсутствуют обязательные аналитики;
- используются разные единицы измерения;
- не заполнены характеристики;
- неправильно ведутся серии и партии;
- статьи расходов создаются без единых правил;
- данные корректируются задним числом;
- не определена мастер-система для справочников.
Очистку и нормализацию данных необходимо включать в проект заранее. Иначе ошибки проявятся уже на этапе переноса или опытной эксплуатации.
Анализ методологии учёта
Автоматизировать можно только согласованную методику.
На обследовании проверяют:
- правила распределения затрат;
- состав себестоимости;
- структуру центров финансовой ответственности;
- статьи доходов и расходов;
- аналитики управленческого учёта;
- правила формирования резервов;
- подходы к бюджетированию;
- методы отражения внутригрупповых операций;
- соответствие оперативного, управленческого и регламентированного контуров.
Если подразделения используют разные определения одного показателя, сначала нужно согласовать методологию и только затем настраивать систему.
Проектирование модели TO BE
TO BE — модель процессов после автоматизации.
Она должна отвечать на вопросы:
- какие действия останутся за пользователем;
- какие операции будут выполняться автоматически;
- какая система отвечает за конкретные данные;
- где проходит согласование;
- как обрабатываются исключения;
- какие контрольные точки предусмотрены;
- какие отчёты и показатели получает руководство;
- как система взаимодействует с внешними решениями.
TO BE не должна быть копией текущего процесса в новом интерфейсе. Задача автоматизации — устранить лишние операции, а не перенести их в другую программу.
Fit-gap-анализ
Fit-gap-анализ показывает, насколько требования предприятия покрываются типовыми возможностями выбранного решения.
Все требования можно распределить на группы:
- поддерживаются типовым функционалом;
- требуют настройки;
- требуют изменения процесса;
- требуют интеграции;
- требуют разработки;
- могут быть исключены как не создающие бизнес-ценности.
Такой подход помогает сохранить типовую конфигурацию там, где это возможно, и обоснованно планировать доработки.
Этапы предпроектного обследования
| Этап | Основные действия | Результат |
|---|---|---|
| Подготовка | Определение целей, состава участников и границ | План обследования |
| Интервью | Встречи с владельцами и исполнителями процессов | Перечень требований и проблем |
| Анализ систем | Проверка конфигураций, доработок и интеграций | Карта IT-ландшафта |
| Моделирование AS IS | Описание текущих процессов | Карты процессов |
| Проектирование TO BE | Формирование целевой модели | Целевая архитектура |
| Fit-gap-анализ | Сопоставление требований с возможностями решения | Реестр разрывов |
| Оценка | Планирование работ, ресурсов и этапов | Дорожная карта и бюджетный ориентир |
| Презентация | Обсуждение выводов с руководством | Согласованное решение о проекте |
Кто должен участвовать в обследовании
Одной встречи с бухгалтерией недостаточно. Состав участников зависит от границ проекта, но обычно в него входят:
- спонсор проекта;
- генеральный или операционный директор;
- финансовый директор;
- IT-директор;
- главный бухгалтер;
- руководитель производства;
- руководитель логистики или склада;
- руководитель закупок;
- руководитель продаж;
- владельцы автоматизируемых процессов;
- ключевые пользователи.
Владельцы процессов объясняют, какой результат должен получать бизнес. Ключевые пользователи показывают, как операции фактически выполняются. Эти точки зрения могут не совпадать, поэтому обе необходимы.
Какие документы получает заказчик
Набор результатов зависит от масштаба обследования. Для корпоративного проекта целесообразно подготовить:
- цели автоматизации;
- границы проекта;
- описание AS IS;
- модель TO BE;
- карту информационных систем;
- перечень интеграций;
- реестр требований;
- fit-gap-анализ;
- реестр доработок;
- требования к переносу данных;
- архитектурную схему;
- ролевую модель;
- реестр рисков;
- этапы внедрения;
- состав проектной команды;
- порядок приёмки;
- предварительную оценку сроков и бюджета.
Как отличить качественный результат от формального
| Формальный результат | Качественный результат |
|---|---|
| «Автоматизировать склад» | Описаны приёмка, размещение, отбор, отгрузка и исключения |
| Общая сумма проекта | Оценка по этапам, блокам и видам работ |
| Перечень пожеланий | Приоритизированный реестр требований |
| Список программ | Архитектура с владельцами данных и обменами |
| «Перенести данные» | Указаны состав, глубина истории и правила проверки |
| Общие риски | Указаны вероятность, влияние и меры управления |
| Перечень отчётов | Определены пользователи, показатели и источники данных |
Сколько длится предпроектное обследование
Срок зависит не столько от размера компании, сколько от числа процессов, систем, юридических лиц и интеграций.
Экспресс-обследование может быть ограничено одним функциональным блоком. Полное обследование производственного предприятия обычно затрагивает финансы, производство, закупки, склад, продажи и интеграции, поэтому требует более глубокой работы.
До начала обследования необходимо зафиксировать:
- подразделения в контуре;
- список процессов;
- количество систем;
- ожидаемые документы;
- формат интервью;
- доступ к базе и документации;
- ответственных со стороны заказчика.
Типичные ошибки заказчика
Передать обследование только IT-отделу
IT-команда знает систему, но не должна единолично определять финансовую, производственную или логистическую модель.
Описывать только идеальный процесс
Необходимо учитывать реальные исключения и ручные обходные операции.
Требовать точную стоимость до анализа
Без зафиксированных границ точная оценка создаёт ложное ощущение определённости. На раннем этапе корректнее указывать диапазон и допущения.
Автоматизировать все процессы одновременно
Не каждую проблему нужно решать в первом этапе. Требования следует разделять на обязательные, важные и перспективные.
Не назначить владельцев решений
Если по спорным вопросам никто не принимает окончательное решение, обследование превращается в бесконечное согласование.
Как оценить качество предпроектного обследования
После завершения руководство должно получить ответы на семь вопросов:
- Какую бизнес-проблему решает проект?
- Какие процессы входят в границы?
- Что изменится для подразделений?
- Какие данные и системы затрагиваются?
- Какие риски существуют?
- Какие ресурсы потребуются от заказчика?
- Какими критериями будет измеряться результат?
Если ответы остаются неопределёнными, начинать активную разработку рано.
Подход ТРИО
ТРИО до начала ERP-проекта моделирует реальные процессы предприятия, загружает примеры данных заказчика и показывает будущую работу системы. Такой формат позволяет выявить ограничения до подписания договора на полномасштабное внедрение.
Компания занимается разработкой, внедрением и поддержкой решений на базе 1С и работает как с отдельными задачами, так и с комплексными корпоративными системами.
Если предприятие планирует внедрение ERP, переход с устаревшей системы или автоматизацию отдельного контура, первым шагом может стать обследование. По его результатам можно сформировать реалистичную архитектуру, определить приоритеты и получить обоснованную оценку проекта.
Часто задаваемые вопросы
Можно ли внедрить 1С без предпроектного обследования?
Чем обследование отличается от технического задания?
Нужно ли обследование, если компания уже использует 1С?
Можно ли использовать результат обследования для выбора подрядчика?
Обязательно ли внедрять систему после обследования?
Кто принимает результат обследования?
