Статистика внедрения корпоративных информационных систем на платформе «1С:Предприятие» фиксирует устойчивую закономерность: порядка 70% проектов не укладываются в изначально запланированные сроки. При этом срыв сроков и превышение бюджета проектов внедрения «1С:Предприятие» обусловлены не функциональными ограничениями платформы и сложностью внедрения, а управленческими решениями, принятыми на подготовительном этапе проекта. В настоящей статье рассмотрены основные критические ошибки, их негативные последствия для хода проекта и практические способы их предотвращения.
Описание ошибки. Наиболее распространённое заблуждение — ожидание, что подрядчик полностью возьмёт проект на себя. Заказчик оплачивает услуги и перекладывает всю ответственность на исполнителя, полагая, что участие бизнеса не требуется. В результате отсутствует назначенный руководитель проекта со стороны компании, ключевые пользователи не вовлечены в процесс, а решения по функционалу принимаются с задержкой или без учёта реальных бизнес-процессов.
Последствия. Проект замедляется на каждом этапе, поскольку отсутствует лицо, способное оперативно принимать и согласовывать стратегические решения и документацию.
Пути решения. Назначить руководителя проекта со стороны заказчика — представителя бизнеса с полномочиями принимать решения и утверждать технические задания. Сформировать проектную команду из ключевых пользователей каждого подразделения (бухгалтер, кладовщик, менеджер по продажам), которые будут участвовать в предпроектном обследовании, тестировании и согласовании решений. Заранее закрепить правила коммуникации: кто отвечает за обратную связь, кто утверждает решения и в какие сроки.
Описание ошибки. Старт проекта без всестороннего анализа текущего состояния бизнес-процессов — один из самых дорогостоящих просчетов. Компании стремятся сразу начать внедрение, минуя этап диагностики, что приводит к переделкам уже реализованных решений и неправильной архитектуре системы.
Последствия. Без понимания реальных процессов компании невозможно корректно настроить систему: автоматизируются не те процессы, сохраняются неэффективные схемы работы, возникают проблемы с учетом. Один и тот же справочник может использоваться по-разному в разных подразделениях, а на уровне реализации это превращается в десятки несогласованных решений.
Пути решения. Выделить отдельный этап для проведения предпроектного обследования. Его задача — зафиксировать, как компания работает в текущий момент, какие управленческие изменения планируются, какие процессы необходимо сохранить, а какие адаптировать. По итогам обследования сформировать отчет об обследовании, реестр требований, реестр функциональных разрывов, дорожную карту проекта внедрения.
Описание ошибки. Распространённая практика — механически переносить в новую систему старую логику работы: таблицы, ручные схемы, неформальные согласования, дублирующиеся справочники, разные трактовки одних и тех же показателей. Данные в старых системах часто не структурированы, содержат ошибки, устаревшие записи и дубли.
Последствия. Компания получает цифровую копию существующего хаоса, только более дорогую в поддержке. Система не даёт ожидаемого эффекта прозрачности и управляемости, поскольку воспроизводит все прежние неэффективные схемы.
Пути решения. Использовать внедрение как повод для пересмотра процессов: устранить избыточные звенья, стандартизировать процедуры и только после этого автоматизировать.
Описание ошибки. Перенос данных из предыдущих систем (или из электронных таблиц) в новую базу «1С» часто рассматривается как второстепенная задача, которой уделяется минимальное внимание на старте. Не проводится инвентаризация и очистка данных, не формализуются правила трансформации, не тестируются сценарии загрузки на малых объемах. Перенос осуществляется вручную или с помощью непроверенных скриптов.
Последствия. На этапе переноса обнаруживаются многочисленные расхождения: дубли контрагентов, неактуальные остатки товаров, несогласованность взаиморасчетов, ошибки в справочниках. Исправление этих проблем требует дополнительного времени и ресурсов, затягивая запуск системы на недели и месяцы. В худшем случае некорректно перенесенные данные становятся причиной ошибок в учете, что ставит под угрозу достоверность отчетности и доверие к системе.
Пути решения. Провести предварительную проверку исходных данных, собрать информацию об особенностях ведения учета в части формирования остатков и в рамках отчета об обследовании описать основные справочники и их источники, а также указать, как именно следует заказчику подготовить данные к переносу. На этапе проектирования необходимо сформировать "Методику переноса данных", в которой детально описать все справочники и их атрибуты с указанием правил трансформации данных. Также описать методику переноса остатков, с указанием ответственных за сверку данных. На этапе подготовки к опытно-промышленной эксплуатации провести тестовую миграцию данных, которая проверит работоспособность инструментов и подходы к сверке, которые были зафиксированы в методике. Только после успешной тестовой миграции проводить полный перенос в продуктивную среду, предусмотрев время на контрольную сверку и корректировку.
Описание ошибки. Проект запускается без формализованных требований и описания будущих бизнес-процессов с привязкой к объектам метаданных системы и распределения функций между подразделениями. В процессе внедрения заказчик неизбежно выдвигает новые пожелания и уточнения. Критической ошибкой является включение этих изменений в текущий объем работ без пересмотра сметы и календарного графика.
Последствия. Требования меняются по ходу проекта, а план остается прежним. Каждое отдельное изменение выглядит небольшим, но новая функция может потребовать изменения данных, ролей пользователей, интеграций и уже разработанного функционала. После каждого изменения необходимо повторное тестирование, обновление инструкций и переобучение сотрудников. В результате проект постепенно становится бесконечным: срок запуска формально сохраняется, но количество работ растёт.
Пути решения. Утвердить модель целевого состояния на старте и закрепить процедуру управления изменениями, включающую оформление дополнительных соглашений: любое новое требование должно проходить формальную оценку влияния на сроки, бюджет и задачи первой очереди. Признавать, что изменение проекта влечет пересмотр его параметров, а не простое добавление задачи к существующему плану.
Описание ошибки. На начальном этапе вопросам разграничения прав доступа и защиты данных уделяется недостаточное внимание. Предполагается, что настройка ролей и профилей будет выполнена «на ходу» в процессе внедрения.
Последствия. Отсутствие продуманной архитектуры безопасности приводит к тому, что к концу проекта настройка прав доступа становится сложной и запутанной. Пользователи либо получают избыточные права (риск несанкционированных действий), либо, наоборот, не могут выполнять свои функции (снижение производительности, обращения в поддержку). Внесение изменений в права доступа уже на стадии опытной эксплуатации требует повторного тестирования всех сценариев, что затягивает финальные этапы.
Пути решения. Спроектировать архитектуру безопасности на этапе формирования модели целевого состояния. Определить перечень ролей пользователей в разрезе должностей и структурных подразделений. Согласовать матрицу доступа к документам, справочникам и отчетам с руководителями соответствующих отделов. Реализовать настройку прав в тестовом контуре и провести пилотное тестирование с участием реальных пользователей. Внести корректировки до перехода в промышленную эксплуатацию. Документировать все настройки для последующего аудита и сопровождения.
Описание ошибки. При стыковке с внешними системами — банк-клиент, системы управления складом, ЕГАИС, маркировка, корпоративные порталы — техническое задание на интеграцию составляется в общем виде, без детализации форматов обмена, протоколов, кодировок, правил преобразования данных и алгоритмов обработки ошибок. Не определяются сценарии сбоев и порядок восстановления обмена.
Последствия. На этапе отладки межсистемного взаимодействия возникают многочисленные конфликты: несовпадение типов полей, различия в справочниках соответствия (например, коды номенклатуры, единицы измерения), ошибки кодировки символов, расхождения в логике расчётов. Каждое устранение требует изменения кода на обеих сторонах и повторного тестирования. Процесс превращается в бесконечную серию тестовых обменов, каждая итерация которой занимает дни и недели, а сроки запуска сдвигаются непредсказуемо.
Пути решения. Выделить интеграционную составляющую в отдельный раздел технического задания с обязательной детализацией:
До начала разработки провести совместное совещание с представителями всех интегрируемых систем для согласования спецификаций. Фиксировать все изменения в отдельном протоколе и утверждать их дополнительно.
Описание ошибки. На начальном этапе проекта часто проводится упрощенная оценка объема работ, основанная на поверхностном понимании бизнес-процессов заказчика. Оценка производится без детального обследования, без учета специфики учетных политик, без анализа интеграций с внешними системами и без учета требований к доработкам типового функционала. Кроме того, не учитываются временные затраты на согласование, тестирование, обучение и исправление ошибок.
Последствия. Заниженная оценка трудоемкости влечет за собой неадекватное планирование ресурсов и сроков. На этапе реализации выясняется, что реальный объем работ в 1,5–2 раза превышает оценочный. Проектная команда вынуждена работать в авральном режиме, качество падает, сроки сдвигаются, бюджет перерасходуется. Заказчик теряет доверие к исполнителю, возникает конфликтная ситуация, что дополнительно замедляет процессы принятия решений.
Пути решения. Внедрить практику многоуровневой оценки трудоемкости. Первая, укрупненная оценка проводится на этапе формирования коммерческого предложения на основе предварительного анализа. Вторая, уточненная, — после завершения предпроектного обследования и составления детального технического задания. Каждая работа должна быть декомпозирована до уровня отдельных задач, по каждой задаче привлекаются эксперты (аналитик, разработчик, консультант). Обязательно закладывать резерв на непредвиденные работы в размере не менее 20–30% от общей оценки. При этом резерв используется только при наступлении согласованных рисков, а не для покрытия новых требований. Учитывать время на согласование документации, обучение пользователей и проведение приемочных испытаний.
Описание ошибки. В начале проекта часто стремятся охватить максимальное количество функциональных блоков, не выделяя критически важные процессы. В результате ресурсы распределяются равномерно между всеми модулями, а ключевые бизнес-процессы, обеспечивающие операционную деятельность компании, не получают приоритетной поддержки. Также распространена ошибка, когда приоритет отдается «интересным» или технически сложным функциям в ущерб базовым, но критичным операциям (например, складской учет или взаиморасчеты с контрагентами).
Последствия. Проект теряет фокус, первые результаты не приносят бизнес-ценности, поскольку автоматизируются второстепенные области. Основные проблемы компании (например, нехватка товарных запасов или задолженности клиентов) остаются нерешенными длительное время. Команда тратит силы на функции, которые не оказывают влияния на финансовые показатели, а сроки запуска системы отодвигаются. В итоге заказчик разочаровывается в проекте, теряется поддержка руководства, финансирование может быть сокращено.
Пути решения. Определить приоритеты на основе анализа бизнес-стратегии компании и текущих «болевых точек». Провести ранжирование функциональных блоков по критериям «важность для бизнеса» и «срочность решения проблемы». Первую очередь внедрения сформировать из процессов, автоматизация которых дает быстрый и измеримый эффект (сокращение задолженности, ускорение отгрузок, снижение ошибок в учете). Остальные функции планировать на последующие этапы. Утвердить матрицу приоритетов на проектном комитете с участием первых лиц заказчика. Таким образом запустить пилотное внедрение — базовый функционал для ключевых процессов, затем постепенно наращивать возможности.
Описание ошибки. Распространенное заблуждение — считать, что обучение сотрудников работе в новой системе не требуется или может быть сведено к краткому инструктажу.
Последствия. Даже идеально настроенная система не работает, если пользователи не понимают, как с ней взаимодействовать. На практике это проявляется в обходе системы, ошибках в данных и снижении скорости работы. Возникает психологическое сопротивление, данные вводятся в обход системы или с ошибками, отчёты формируются вручную, доверие к автоматизации падает.
Пути решения. Заложить обучение в план проекта как обязательный этап. Разработать инструкции для пользователей и администраторов системы. Назначить ключевых пользователей от каждого подразделения, которые пройдут углубленное обучение и станут внутренними наставниками для коллег. Запланировать мероприятия по аттестации пользователей и допускать к эксплуатации только тех, кто прошел эту аттестацию — в этом случае для пользователей становится отдельной мотивацией научиться работать в новой системе. А ситуации, когда пользователь говорит: "Нас этому не учили" будут сведены к минимуму.
Описание ошибки. Во многих проектах процедура приемки результатов работ не регламентирована. Критерии приемки либо отсутствуют, либо сформулированы размыто (например, «система должна работать корректно»). Заказчик может бесконечно требовать доработок, ссылаясь на субъективное восприятие «неудобства» или «неполноты» функционала. При этом сроки приемки не фиксируются, а акты не подписываются.
Последствия. Процедура приемки превращается в бесконечный процесс согласования, который может длиться месяцами. Исполнитель вынужден выполнять дополнительные работы, не предусмотренные целевой моделью, чтобы получить подпись. Проект фактически завершен, но юридически не закрыт, что создает риски для обеих сторон. Команда разработки отвлекается на бесконечные правки, а запуск системы в промышленную эксплуатацию откладывается.
Пути решения. На старте проекта зафиксировать в договоре четкие, измеримые критерии приемки для каждого этапа и для проекта в целом. Утвердить форму акта приемки, в которой перечислены все проверяемые параметры. Разработать сценарии приемочных испытаний, покрывающие все ключевые бизнес-процессы. Провести приемку в два этапа: предварительная (по результатам тестирования в тестовой среде) и финальная (после опытной эксплуатации в течение оговоренного периода). Жестко регламентировать сроки на исправление выявленных недостатков — каждый новый цикл доработок должен быть ограничен по времени и согласовываться отдельным актом. Внедрить практику подписания промежуточных актов по завершении этапов, чтобы не накапливать все замечания к финалу.
Успех проекта автоматизации на платформе «1С:Предприятие» на 70% определяется организационной готовностью компании и лишь на 30% — технологическими аспектами. Ключевые факторы, обеспечивающие реалистичные сроки и достижение заявленных результатов, сводятся к следующим управленческим решениям:
Осознанное отношение к перечисленным аспектам на этапе старта превращает проект автоматизации из источника непредвиденных затрат и задержек в предсказуемый процесс, завершающийся в установленные сроки и приносящий реальную пользу бизнесу.
Как показано в статье, срыв сроков и превышение бюджета — это не неизбежность, а следствие ошибок, которые можно предотвратить. Мы предлагаем комплексный подход к запуску проектов автоматизации: от назначения проектной команды и предпроектного обследования до формализации процедуры приемки и обучения пользователей. Инвестируйте в подготовку — и вы сэкономите миллионы на доработках и переделках. Свяжитесь с нами по телефону +7(495) 989-22-16 или электронной почте sales@rg-spc.ru.
Веб-студия SeoLand: Создание и продвижение сайтов
Наш сайт использует файлы cookie для обеспечения удобства пользователей сайта, его улучшения, сбора статистики и предоставления персонализированных рекомендаций.
Для получения дополнительной информации о целях, сроках и порядке использования файлов cookie вы можете ознакомиться с нашей Политикой обработки файлов cookie
