Когда компания внедряет 1С, хочется одного:
чтобы система помогала зарабатывать больше и работать спокойнее, а не превращалась в бесконечную стройку.
Проблема в том, что:
· бизнес постоянно меняется — акции, скидки, новые каналы продаж;
· старый подход «сначала всё опишем, потом сделаем» часто не успевает за реальностью.
Гибкие методологии (Agile, Scrum, Kanban) — это способ внедрять 1С по шагам, получать результат быстрее и успевать подстраиваться под изменения.
Разберём на примере.
Кейс: сеть магазинов одежды внедряет 1С:ERP
Компания:
25 магазинов одежды, около 350 пользователей.
Особенности:
· сильная сезонность: коллекции, распродажи, чёрная пятница;
· регулярно появляются новые акции и идеи от маркетинга;
· руководство хочет видеть результат не «через год», а как можно раньше.
Сначала попробовали классический подход:
· долго описывали требования;
· утвердили большое техническое задание;
· начали делать — а бизнес уже придумал новые акции и поменял правила игры.
В итоге стало понятно:
каскадная схема не успевает за реальностью, проект «расходится» с бизнесом.
Тогда решили перейти на гибкий формат:
· работать спринтами по 2 недели (Scrum);
· вести поток задач и поддержки через доску (Kanban).
Что хорошего дала гибкая методология
1. Можно подстраиваться под изменения, а не сопротивляться им
В рознице акции меняются постоянно:
· вначале хотели просто скидки;
· потом добавили «купи 2 — третий в подарок»;
· потом бонусы за отзывы и карту лояльности.
В гибком подходе:
· новые идеи попадают в общий список задач (бэклог);
· бизнес вместе с аналитиками решает, что важнее сделать в ближайшие недели;
· нужную акцию можно добавить в ближайший спринт и не ждать конца проекта.
Итог:
система успевает поддерживать почти все ключевые промо, а не только те, что были придуманы год назад.
2. Быстрые результаты вместо «год терпеть, потом посмотрим»
Вместо того чтобы полгода «копать» и ничего не показывать, команда делала так:
· в первый месяц запустили кассы и онлайн‑заказы;
· затем настроили нормальный учёт остатков по складам;
· чуть позже — мобильные решения для кладовщиков.
Компания начала получать пользу уже через пару месяцев:
· быстрее обслуживание клиентов;
· лучше видны остатки и неликвиды;
· быстрее сбор заказов.
Это важно:
руководство видит, что проект живой, деньги работают, а не лежат в «ИТ‑яме».
3. Постоянная обратная связь, а не «сюрприз на запуске»
В гибком формате:
· пользователи регулярно видят прототипы и новые функции;
· руководство тестирует ключевые операции каждые 2 недели;
· аналитики и разработчики быстро получают комментарии: удобно / неудобно, нужно / не нужно.
Плюс для бизнеса:
· меньше «нелепых» решений, которые никто не использует;
· меньше переделок, потому что ошибки ловятся на ранних этапах.
4. Люди вовлечены, команда не разваливается
В проект включили суперпользователей:
· по одному от торговли и склада;
· они участвовали во встречах, тестировали, помогали формулировать требования.
Что это дало:
· сотрудники чувствовали, что это «их система», а не «чужой ИТ‑монстр сверху»;
· меньше сопротивления изменениям;
· команда проекта не выгорела, потому что видела реальные результаты и поддержку.
5. Понятно, что происходит с проектом
Вместо отчётов в духе «идут работы» использовали простые визуальные вещи:
· доска задач: видно, что планируется, делается, готово;
· график прогресса: сколько задач осталось, какая скорость команды.
Для директора это плюс:
· можно быстро понять, всё ли идёт по плану;
· проще принимать решения: добавить людей, сместить сроки, урезать функции.
Но у гибкого подхода есть и минусы
1. Риск раздувания объёма работ
Когда можно добавлять задачи в процессе, бизнес этим пользуется:
· появляются дополнительные отчёты, интеграции, «а давайте ещё вот это».
Если не управлять этим:
· список задач растёт быстрее, чем бюджет и сроки;
· проект может сильно подорожать и затянуться.
Что нужно:
· человек, который отвечает за приоритеты (Product Owner);
· правило: если добавляем важное — что‑то менее важное переносим или убираем.
2. Документация может «провалиться»
В гонке за скоростью легко сказать:
«потом опишем, сейчас главное — сделать».
Риски:
· новые люди долго входят в курс дела;
· сопровождать систему после запуска дорого и сложно.
Решение:
· заложить время на краткую документацию по итогам каждого спринта;
· фиксировать основные решения и бизнес‑логику, хотя бы в сжатом виде.
3. Сильная зависимость от ключевых людей
Если проект держится на одном суперпользователе или аналитике:
· отпуск или уход такого человека сильно бьёт по скорости и качеству;
· отдельные части системы «завязаны» на его знания.
Как снизить риск:
· дублировать роли (несколько вовлечённых представителей бизнеса);
· делиться знаниями и фиксировать договорённости.
4. Возможны проблемы на стыках модулей
Когда разные блоки (продажи, склад, лояльность) делаются параллельно:
· может оказаться, что каждый модуль «правильный сам по себе», но вместе они работают некорректно;
· пример: остатки считаются по‑одному, а скидки и бонусы предполагают другую логику.
Нужно:
· регулярно прогонять сквозные сценарии «от продажи до отчёта»;
· следить за общей архитектурой данных и процессов.
5. Высокая нагрузка на тестирование
Каждый спринт:
· появляются новые функции;
· нужно проверять, что старые не сломались.
Если всё тестируется только вручную:
· тестировщики перегружены;
· часть ошибок неизбежно уходит в рабочую систему.
Выход:
· автоматизировать хотя бы часть повторяющихся тестов;
· договориться о списке критичных сценариев, которые обязательно проверяются.
Когда гибкий подход в 1С стоит использовать, а когда — нет
Гибкие методологии подходят, если:
· бизнес быстро меняется (розница, e‑commerce, маркетинг);
· нужны быстрые результаты, а не «идеальный проект через год»;
· руководство готово регулярно участвовать: смотреть демо, ставить приоритеты, давать обратную связь.
Опасно использовать «чистый Agile», если:
· компания консервативна и любит чёткие регламенты;
· требования жёстко заданы законом (регуляторика, гос.проекты);
· никто не хочет брать на себя ответственность за приоритеты.
Оптимальный вариант для большинства:
· не крайность, а гибрид:
o немного классики для общей архитектуры и ключевых решений;
o гибкие спринты там, где мир меняется быстро (акции, отчёты, витрины, интеграции);
o отдельное внимание к тестам и документации.
Такая подача поможет читателю без технического образования:
· понять, зачем вообще нужны гибкие методологии;
· увидеть реальные плюсы и минусы на примере;
· и сделать вывод: стоит ли ему просить внедрять 1С «по‑гибкому» и на каких условиях.
чтобы система помогала зарабатывать больше и работать спокойнее, а не превращалась в бесконечную стройку.
Проблема в том, что:
· бизнес постоянно меняется — акции, скидки, новые каналы продаж;
· старый подход «сначала всё опишем, потом сделаем» часто не успевает за реальностью.
Гибкие методологии (Agile, Scrum, Kanban) — это способ внедрять 1С по шагам, получать результат быстрее и успевать подстраиваться под изменения.
Разберём на примере.
Кейс: сеть магазинов одежды внедряет 1С:ERP
Компания:
25 магазинов одежды, около 350 пользователей.
Особенности:
· сильная сезонность: коллекции, распродажи, чёрная пятница;
· регулярно появляются новые акции и идеи от маркетинга;
· руководство хочет видеть результат не «через год», а как можно раньше.
Сначала попробовали классический подход:
· долго описывали требования;
· утвердили большое техническое задание;
· начали делать — а бизнес уже придумал новые акции и поменял правила игры.
В итоге стало понятно:
каскадная схема не успевает за реальностью, проект «расходится» с бизнесом.
Тогда решили перейти на гибкий формат:
· работать спринтами по 2 недели (Scrum);
· вести поток задач и поддержки через доску (Kanban).
Что хорошего дала гибкая методология
1. Можно подстраиваться под изменения, а не сопротивляться им
В рознице акции меняются постоянно:
· вначале хотели просто скидки;
· потом добавили «купи 2 — третий в подарок»;
· потом бонусы за отзывы и карту лояльности.
В гибком подходе:
· новые идеи попадают в общий список задач (бэклог);
· бизнес вместе с аналитиками решает, что важнее сделать в ближайшие недели;
· нужную акцию можно добавить в ближайший спринт и не ждать конца проекта.
Итог:
система успевает поддерживать почти все ключевые промо, а не только те, что были придуманы год назад.
2. Быстрые результаты вместо «год терпеть, потом посмотрим»
Вместо того чтобы полгода «копать» и ничего не показывать, команда делала так:
· в первый месяц запустили кассы и онлайн‑заказы;
· затем настроили нормальный учёт остатков по складам;
· чуть позже — мобильные решения для кладовщиков.
Компания начала получать пользу уже через пару месяцев:
· быстрее обслуживание клиентов;
· лучше видны остатки и неликвиды;
· быстрее сбор заказов.
Это важно:
руководство видит, что проект живой, деньги работают, а не лежат в «ИТ‑яме».
3. Постоянная обратная связь, а не «сюрприз на запуске»
В гибком формате:
· пользователи регулярно видят прототипы и новые функции;
· руководство тестирует ключевые операции каждые 2 недели;
· аналитики и разработчики быстро получают комментарии: удобно / неудобно, нужно / не нужно.
Плюс для бизнеса:
· меньше «нелепых» решений, которые никто не использует;
· меньше переделок, потому что ошибки ловятся на ранних этапах.
4. Люди вовлечены, команда не разваливается
В проект включили суперпользователей:
· по одному от торговли и склада;
· они участвовали во встречах, тестировали, помогали формулировать требования.
Что это дало:
· сотрудники чувствовали, что это «их система», а не «чужой ИТ‑монстр сверху»;
· меньше сопротивления изменениям;
· команда проекта не выгорела, потому что видела реальные результаты и поддержку.
5. Понятно, что происходит с проектом
Вместо отчётов в духе «идут работы» использовали простые визуальные вещи:
· доска задач: видно, что планируется, делается, готово;
· график прогресса: сколько задач осталось, какая скорость команды.
Для директора это плюс:
· можно быстро понять, всё ли идёт по плану;
· проще принимать решения: добавить людей, сместить сроки, урезать функции.
Но у гибкого подхода есть и минусы
1. Риск раздувания объёма работ
Когда можно добавлять задачи в процессе, бизнес этим пользуется:
· появляются дополнительные отчёты, интеграции, «а давайте ещё вот это».
Если не управлять этим:
· список задач растёт быстрее, чем бюджет и сроки;
· проект может сильно подорожать и затянуться.
Что нужно:
· человек, который отвечает за приоритеты (Product Owner);
· правило: если добавляем важное — что‑то менее важное переносим или убираем.
2. Документация может «провалиться»
В гонке за скоростью легко сказать:
«потом опишем, сейчас главное — сделать».
Риски:
· новые люди долго входят в курс дела;
· сопровождать систему после запуска дорого и сложно.
Решение:
· заложить время на краткую документацию по итогам каждого спринта;
· фиксировать основные решения и бизнес‑логику, хотя бы в сжатом виде.
3. Сильная зависимость от ключевых людей
Если проект держится на одном суперпользователе или аналитике:
· отпуск или уход такого человека сильно бьёт по скорости и качеству;
· отдельные части системы «завязаны» на его знания.
Как снизить риск:
· дублировать роли (несколько вовлечённых представителей бизнеса);
· делиться знаниями и фиксировать договорённости.
4. Возможны проблемы на стыках модулей
Когда разные блоки (продажи, склад, лояльность) делаются параллельно:
· может оказаться, что каждый модуль «правильный сам по себе», но вместе они работают некорректно;
· пример: остатки считаются по‑одному, а скидки и бонусы предполагают другую логику.
Нужно:
· регулярно прогонять сквозные сценарии «от продажи до отчёта»;
· следить за общей архитектурой данных и процессов.
5. Высокая нагрузка на тестирование
Каждый спринт:
· появляются новые функции;
· нужно проверять, что старые не сломались.
Если всё тестируется только вручную:
· тестировщики перегружены;
· часть ошибок неизбежно уходит в рабочую систему.
Выход:
· автоматизировать хотя бы часть повторяющихся тестов;
· договориться о списке критичных сценариев, которые обязательно проверяются.
Когда гибкий подход в 1С стоит использовать, а когда — нет
Гибкие методологии подходят, если:
· бизнес быстро меняется (розница, e‑commerce, маркетинг);
· нужны быстрые результаты, а не «идеальный проект через год»;
· руководство готово регулярно участвовать: смотреть демо, ставить приоритеты, давать обратную связь.
Опасно использовать «чистый Agile», если:
· компания консервативна и любит чёткие регламенты;
· требования жёстко заданы законом (регуляторика, гос.проекты);
· никто не хочет брать на себя ответственность за приоритеты.
Оптимальный вариант для большинства:
· не крайность, а гибрид:
o немного классики для общей архитектуры и ключевых решений;
o гибкие спринты там, где мир меняется быстро (акции, отчёты, витрины, интеграции);
o отдельное внимание к тестам и документации.
Такая подача поможет читателю без технического образования:
· понять, зачем вообще нужны гибкие методологии;
· увидеть реальные плюсы и минусы на примере;
· и сделать вывод: стоит ли ему просить внедрять 1С «по‑гибкому» и на каких условиях.
Полезные статьи для аналитиков
