Статья предназначена для заказчиков — руководителей, владельцев бизнеса, которые принимают решение о внедрении 1С и участвуют в предпроектном обследовании.
На обсуждении проекта:
— Вы не так поняли. Должно быть управление из одного места, а не через одно место.(с) Подслушано на Мисте
Когда компания решает автоматизировать учёт на 1С, первое, что предлагают подрядчики, провести предварительное обследование. Многие заказчики относятся к этому этапу как к формальности: лишь бы бумажку получили и начали уже внедрять. Но именно на этом этапе закладываются сроки, бюджет и то, будет ли система реально работать или станет головной болью.
Что даёт предварительное обследование бизнесу
Увидеть реальные процессы, а не только то, что в головах руководителей.
Внедрить лучшие практики, наработанные на похожих проектах.
Понять, насколько выбранная система подходит под задачи компании.
Заранее заметить свои уникальные фишки и заложить их в проект.
Уточнить бюджет и сроки с учётом доработок.
Получить документацию, которая реально помогает работать.
Оценить нужных людей и ресурсы, выделить их вовремя.
Увидеть риски, которые могут испортить результат.
Сэкономить на запуске, сделав часть работ своими силами.
Прикинуть, когда вложения начнут приносить деньги.
Ниже перечислены частые ошибки, которые заказчики совершают, пытаясь помочь или сэкономить.
1. Игнорирование регламента и соглашения
Фраза «Давайте без бюрократии, сразу к делу» звучит разумно, но на практике означает, что стороны не фиксируют в документах предпроектного обследования ничего: ни сроки, ни критерии приёмки, ни время на доработки, ни ответственных.
Последствия. Внедрение либо никогда не завершится, потому что нет точек входа и выхода, либо при исчерпании бюджета просто замёрзнет с недоделанной системой и испорченными отношениями.
Как правильно. Утверждённый регламент и подписанные документы на этапе обследования это ваш единственный инструмент зафиксировать правила игры. Без них вы не контролируете ни сроки, ни деньги, ни результат.
2. Требование избыточной детализации
Заказчики часто просят расписать процесс до мельчайших бытовых подробностей. Или наоборот считают, что раз что-то делается в Excel или по телефону, то это не относится к автоматизации.
Последствия. Если описывать всё подряд, документация раздувается, и вы тонете в согласованиях. А если пропускать важные ручные операции, например, сотрудник меняет статус заказа в Excel после звонка, система потом не будет отражать реальность, и вы ничего не автоматизируете по-настоящему.
Как правильно. Фиксировать все точки, где рождаются или меняются данные, даже если сейчас это происходит за пределами 1С. Статус заказа, договорённости по телефону, пометки в Excel если это влияет на учёт или управление, должно быть учтено. А вот действия, которые никак не отражаются в системе, например, курьер привёз бумажный документ и положил в папку, но данные ещё не введены, можно оставить за скобками.
3. Ставка на анкетирование сотрудников
«Зачем интервью? Разошлите анкеты, они заполнят» так думают многие. И ошибаются.
Последствия. Анкеты заполняются формально. Только очное интервью позволяет аналитику выявить реальную картину учёта и те детали, о которых никогда не напишут в официальном опроснике, но которые потом проявят себя на этапе внедрения.
Как правильно. Проводить интервью с ключевыми сотрудниками лично. Анкеты можно использовать как подготовку к разговору, но не как основной источник.
4. Затягивание сроков обследования
Некоторые заказчики не видят риска в том, чтобы растянуть обследование на несколько месяцев, особенно если параллельно идут другие рабочие процессы.
Последствия. Если процесс затягивается на месяцы, ваши же эксперты устают и начинают саботировать встречи. Люди теряют фокус, а описанные процессы устаревают быстрее, чем вы их успеваете утвердить.
Как правильно. Укладываться в оптимальные сроки. Для 100–120 процессов это 10–11 недель. Дольше теряется и время, и качество.
5. Попытка пропустить описание «Как есть»
Многие хотят сразу описывать «Как должно быть».
Последствия. Без понимания текущей методологии учёта невозможно достоверно оценить три параметра: объём доработок, бюджет и сроки. Если пропускать этот этап, смета становится приблизительной: доработки выявляются позже, когда бюджет уже распределён.
Как правильно. Сначала зафиксировать, как работает сейчас. Потом решать, что менять. Иначе вы будете строить новую систему на том, чего не понимаете.
6. Боязнь кастомизации и боязнь типовых решений
Одни заказчики боятся кастомизации: настаивают только на типовом функционале, а всё остальное, мол, «девочки в Excel доделают». Другие боятся типовых решений и пытаются зашить в программу всё подряд, даже то, что вообще не требует автоматизации.
Последствия. В первом случае ваши уникальные преимущества остаются за бортом системы. Во втором внедрение становится очень дорогим, а обновления экстремально сложными.
Как правильно. И те, и другие неправы. Задача аналитика найти баланс между типовым функционалом и разумной кастомизацией, чтобы система решала задачи бизнеса, но не превращалась в избыточно сложный продукт.
7. Игнорирование читаемости схем
Схема это рабочий инструмент для вас, а не для архива.
Последствия. Если требовать горизонтальные «простыни», их будет невозможно нормально распечатать и изучить.
Как правильно. Вертикальные схемы позволяют быстро проследить логику процесса от начала до конца. Это не просто стандарт, а способ сделать структуру вашего бизнеса прозрачной для всех от директора до рядового исполнителя.
8. Отсутствие измеримых целей проекта
Часто цели внедрения формулируются размыто: «повысить эффективность», «навести порядок», «автоматизировать учёт». Конкретные измеримые показатели при этом не определяются.
Последствия. Если цели внедрения сформулированы размыто, невозможно оценить успех проекта. Приоритизация требований становится субъективной, а бюджет не привязан к конкретным бизнес-результатам.
Как правильно. До начала обследования сформулировать 3–5 количественных показателей, которые должна улучшить новая система. Например, сокращение времени закрытия месяца с 12 до 5 дней, снижение процента ошибок при отгрузке, уменьшение ручного ввода данных в часах в день. Эти показатели станут критериями успеха и помогут отделить обязательные доработки от желательных.
9. Игнорирование аудита качества данных
Если не проверить данные, с которыми предстоит работать в новой системе, многие проблемы останутся скрытыми до момента запуска.
Последствия. Проблемы качества данных переходят из старой системы в новую. Расхождения между регламентированным и управленческим учётом, пересорт по сериям, дублирование контрагентов, незакрытые остатки всё это выявляется уже после запуска, когда исправления стоят дорого и занимают много времени.
Как правильно. На этапе обследования выделить отдельную задачу на аудит данных. Проверить остатки, выявить расхождения. Назначить ответственных за ключевые разделы НСИ (номенклатура, контрагенты, договоры) с чёткими критериями приемлемого качества. Если качество данных ниже допустимого, заложить в бюджет отдельные работы по чистке и нормализации.
10. Формальное назначение руководителя проекта без полномочий
Нередко руководителем проекта назначают сотрудника, который может только организовывать встречи, но не имеет права принимать решения. Или выбирают ИТ-специалиста, чья экспертиза ограничена сетями и оборудованием, без опыта внедрения 1С.
Последствия. Вопросы накапливаются, проектный комитет не решает проблемы, внедрение останавливается. В случае с ИТ-специалистом без опыта неизбежны ошибки в планировании и переделки.
Как правильно. На этапе обследования утвердить руководителя проекта, который имеет реальные полномочия на принятие решений в рамках утверждённого бюджета и сроков. Если назначается внутренний ИТ-специалист, убедиться, что у него есть опыт аналитики и внедрения 1С, либо привлечь внешнего аналитика для методологической поддержки.
11. Отсутствие системного тестирования доработок
Даже если заказчик нанял своего программиста для участия в проекте, а исполнитель предоставил аналитика, проверка доработок часто сводится к формальному «потыкать кнопки». В результате негативные и граничные сценарии остаются незамеченными, а дефекты вылезают уже в промышленной эксплуатации. Переделки на этом этапе обходятся бизнесу очень дорого.
Как правильно. Проверка доработок должна быть системной. Один из эффективных инструментов — матрица трассировки, которая позволяет связать каждое функциональное требование с тест-кейсами и убедиться, что все сценарии отработаны.Подробная инструкция по проверке доработок с примерами описана в статье «Как аналитику 1C проверить любую доработку». Статья написана для аналитиков со стороны исполнителя, но будет полезна также аналитикам, тестировщикам и программистам со стороны заказчика, которые участвуют в приёмке результатов.
Заключение
Предпроектное обследование задаёт фундамент для всего внедрения. Если подходить к нему формально, результаты останутся на бумаге, а риски перейдут в проект. Если относиться к нему как к инструменту планирования, можно получить реалистичный бюджет, понятные сроки и систему, которая действительно соответствует задачам бизнеса.
Пропуск этапов, излишняя детализация, замена интервью анкетами, отказ от фиксации текущих процессов, отсутствие измеримых целей, аудита данных, реальных полномочий у руководителя проекта и системного тестирования доработок приводят к тому, что обследование не приносит практической пользы. Системный подход на этом этапе позволяет избежать доработок в процессе внедрения и обеспечить предсказуемость проекта.
Главная тайна предпроектного обследования в 1С: никогда не знаешь заранее, чем оно закончится. Оно либо переходит в проект, либо в арбитраж.
А какие ошибки при обследовании встречались вам? Делитесь в комментариях, соберём народный антирейтинг.
