Кейс:
почему проект, который руководитель ждал за 2 месяца, растянулся на год — история о нереалистичных ожиданиях и скрытых проблемах в учёте
Как всё начиналось: ожидания vs реальность
Руководитель пришёл с запросом: перейти с УТ 10 на УТ 11.5 за 2 месяца. Компания была среднего размера — торговля через маркетплейсы, ~20000 позиций в номенклатуре, небольшой штат (10–15 человек), месячный оборот около 5 млн рублей. Бюджета на полноценную работу аналитика не было — руководитель ожидал, что это будет «апгрейд версии» с минимальными затратами.
Ко мне обратились с простой задачей: «Нужно перенести учёт из УТ 10 в УТ 11.5. Собери требования, выбери обработку, перенесём базу — и поедем дальше». Стандартный проект по переходу.
Но уже на первом этапе анализа я увидела: проблема не в версии конфигурации, а в самой базе и в том, как ведётся учёт.
С каким бардаком ко мне пришли
Когда я начала разбирать УТ 10, стало ясно: это был системный развал управленческого учёта.
Масштаб проблемы:
· Конфигурация УТ 10 не обновлялась более 10 лет. Часть механизмов была сломана после конфликтного ухода штатного айтишника — это касалось типовых функций и кастомных доработок.
· В каждом блоке учёта — продажи, закупки, склад, деньги, взаиморасчёты — я обнаружила систематические ошибки:
o документы проводились в неправильной последовательности;
o движения по регистрам не соответствовали реальным операциям;
o остатки регулярно «правили руками», чтобы цифры совпадали в отчёте.
· Управленческая отчётость была нерелевантна: по отчётам нельзя было уверенно принимать решения. Руководство считало это «проблемой сотрудников», а не следствием кривой архитектуры.
· Останавливать бизнес было невозможно: ежедневные заказы, отгрузки, работа с маркетплейсами шли без перерывов.
Мой вывод:
Переносить УТ 10 «как есть» нельзя. Это просто перенесёт хаос в новую систему. А «подлечить всё на лету» — нереально.
Вместо 2 месяцев нужен минимум год.
Почему ожидаемые 2 месяца стали реальностью в год?
Причина 1: Недостаточный бюджет усугубил проблему
Когда я озвучила реальные сроки, руководитель попросил подешевле. Вместо 40 часов в неделю была согласована работа на половинном бюджете.
Это означало:
· диагностика растянулась не на 2 недели, а на месяц
· обучение происходило параллельно текущей работе, а не концентрировано
· каждый цикл тестирования шёл медленнее
· я вынуждена была синхронизироваться с его временем
Парадокс: попытка сэкономить привела к растяжению проекта в 5 раз, что в итоге обошлось дороже.
Причина 2: Реальный объём работ был огромным
Я не была уверена в сроках, потому что не встречала такую степень разрушения. Вот что заняло время:
· 1 месяц диагностики каждого блока
· 2–3 недели переговоров с руководством
· 3–4 недели обучения ответственного сотрудника (~40 часов)
· 2 недели проектирования сценария переноса
· 3–4 недели настройки и отладки
· 4–6 недель обучения всех пользователей
· 1 месяц на выстраивание процессов и регламентов
· Текущая работа параллельно с модерацией и консультациями
Причина 3: Ограниченный бюджет означал ограниченное тестирование
При ограниченных средствах пришлось:
· Многократно проверять каждый шаг переноса
· Долго работать с багами, проявившимися после запуска
· Вручную переделывать ошибочные операции
Как я решала: по шагам
1. Честная диагностика и отказ от «магического переноса»
Первым делом я показала руководству реальную картину:
· текущий учёт искажён по всем блокам
· старая база забита ошибками и ручными корректировками
· если перенести всю историю, УТ 11.5 унаследует этот хаос
Результат: руководитель впервые понял, что «смена версии» проблему не решит, и согласился идти по предложенному пути.
2. Обучение ключевого сотрудника
Я выбрала ответственного сотрудника, вовлечённого в операционку. С ним я провела глубокую работу:
· Объяснила базовые принципы корректного ведения учёта в УТ: цепочка продаж, работа с закупками, складской учёт, партии
· На примерах из их базы показала, какие действия ломают картину
· Показала, почему «подправили руками» — источник постоянных проблем
Результат: 40+ часов обучения, растянутые на 3–4 недели. Появился человек, который понимает методологию, а не просто нажимает кнопки.
3. Частичный перенос данных
Я разработала нестандартный сценарий:
· Не тащить всю многолетнюю историю
· Переносить только: остатки на дату начала + операции за квартал
· Исторические периоды закрыть как архив
· В новой базе документы уже отражаются по корректной логике
Это заняло 4 недели, потому что нужно было не просто выбрать обработку, а доработать её, протестировать, провести сверку, переделать ошибочные строки вручную.
4. Обучение всей команды
После переноса я провела обучение по блокам: продажи, закупки, склад, казначейство. Не просто про кнопки, а про связь действий с отчётами.
Результат: сотрудники перестали воспринимать УТ 11.5 как чёрный ящик.
5. Защита номенклатуры и внедрение ИИ‑описаний
Проблема: Менеджеры постоянно меняли артикулы при работе с карточками для маркетплейсов, ломая связку 1С ↔ маркетплейсы ↔ бухгалтерия.
Решение:
1. Запретил изменение артикула после записи карточки
2. Внедрил генерацию описаний товаров через ИИ прямо из карточки номенклатуры
Теперь менеджеры не лазят по полям вручную. Описание формируется автоматически на основе данных карточки и подходит требованиям Wildberries и Ozon.
Результаты: был ли выигрыш за год ожидания?
Да. И существенный.
Для собственника и руководства:
· Верное отражение деятельности: управленческая отчётность теперь опирается на реальные данные, стало очевидно, какие товары и каналы действительно прибыльны
· Поставленный оперативный учёт: сотрудники работают по чётким правилам, есть обученный человек, который поддерживает порядок
· Стабильные интеграции: между УТ 11.5 и бухгалтерией без конфликтов; с маркетплейсами ошибки упали с 15–20 в месяц на 1–2
· Экономия времени: время подготовки описаний товаров сократилось с 30–40 минут на 5–10 минут
Для меня как аналитика:
Этот кейс показал, что ценность аналитика — не в выборе обработки, а в:
· Честной диагностике и умении назвать истинные сроки
· Архитектурных решениях: частичный перенос, защита реквизитов, ИИ как инструмент решения боли
· Выстраивании процессов и обучении людей
· Умении управлять ожиданиями
Главный урок этого кейса
Для руководителей: если аналитик говорит, что вместо 2 месяцев нужен год, это не значит, что он медленный или дорогой. Это значит, что он честно смотрит на проблему и берёт ответственность за результат, а не за галочки в чек-листе.
Для других аналитиков: когда видишь многолетний бардак в учёте, первый шаг — не выбор обработки переноса, а диагностика и переговоры. Потом — выбор правильного сценария. Потом — обучение людей, потому что система настолько хороша, насколько хороши процессы вокруг неё.
Для компаний: год работы над учётом — это инвестиция в то, чтобы система и люди работали по одним правилам. После этого года обслуживание будет дешевле и быстрее, а ошибок будет намного меньше.
С помощью правильной диагностики, архитектурных решений и системного подхода к обучению можно превратить 10-летний бардак в управляемую и надёжную систему, не ставя бизнес на паузу. Но это требует времени, честности о сроках и инвестиции в людей, а не только в технику.
Руководитель пришёл с запросом: перейти с УТ 10 на УТ 11.5 за 2 месяца. Компания была среднего размера — торговля через маркетплейсы, ~20000 позиций в номенклатуре, небольшой штат (10–15 человек), месячный оборот около 5 млн рублей. Бюджета на полноценную работу аналитика не было — руководитель ожидал, что это будет «апгрейд версии» с минимальными затратами.
Ко мне обратились с простой задачей: «Нужно перенести учёт из УТ 10 в УТ 11.5. Собери требования, выбери обработку, перенесём базу — и поедем дальше». Стандартный проект по переходу.
Но уже на первом этапе анализа я увидела: проблема не в версии конфигурации, а в самой базе и в том, как ведётся учёт.
С каким бардаком ко мне пришли
Когда я начала разбирать УТ 10, стало ясно: это был системный развал управленческого учёта.
Масштаб проблемы:
· Конфигурация УТ 10 не обновлялась более 10 лет. Часть механизмов была сломана после конфликтного ухода штатного айтишника — это касалось типовых функций и кастомных доработок.
· В каждом блоке учёта — продажи, закупки, склад, деньги, взаиморасчёты — я обнаружила систематические ошибки:
o документы проводились в неправильной последовательности;
o движения по регистрам не соответствовали реальным операциям;
o остатки регулярно «правили руками», чтобы цифры совпадали в отчёте.
· Управленческая отчётость была нерелевантна: по отчётам нельзя было уверенно принимать решения. Руководство считало это «проблемой сотрудников», а не следствием кривой архитектуры.
· Останавливать бизнес было невозможно: ежедневные заказы, отгрузки, работа с маркетплейсами шли без перерывов.
Мой вывод:
Переносить УТ 10 «как есть» нельзя. Это просто перенесёт хаос в новую систему. А «подлечить всё на лету» — нереально.
Вместо 2 месяцев нужен минимум год.
Почему ожидаемые 2 месяца стали реальностью в год?
Причина 1: Недостаточный бюджет усугубил проблему
Когда я озвучила реальные сроки, руководитель попросил подешевле. Вместо 40 часов в неделю была согласована работа на половинном бюджете.
Это означало:
· диагностика растянулась не на 2 недели, а на месяц
· обучение происходило параллельно текущей работе, а не концентрировано
· каждый цикл тестирования шёл медленнее
· я вынуждена была синхронизироваться с его временем
Парадокс: попытка сэкономить привела к растяжению проекта в 5 раз, что в итоге обошлось дороже.
Причина 2: Реальный объём работ был огромным
Я не была уверена в сроках, потому что не встречала такую степень разрушения. Вот что заняло время:
· 1 месяц диагностики каждого блока
· 2–3 недели переговоров с руководством
· 3–4 недели обучения ответственного сотрудника (~40 часов)
· 2 недели проектирования сценария переноса
· 3–4 недели настройки и отладки
· 4–6 недель обучения всех пользователей
· 1 месяц на выстраивание процессов и регламентов
· Текущая работа параллельно с модерацией и консультациями
Причина 3: Ограниченный бюджет означал ограниченное тестирование
При ограниченных средствах пришлось:
· Многократно проверять каждый шаг переноса
· Долго работать с багами, проявившимися после запуска
· Вручную переделывать ошибочные операции
Как я решала: по шагам
1. Честная диагностика и отказ от «магического переноса»
Первым делом я показала руководству реальную картину:
· текущий учёт искажён по всем блокам
· старая база забита ошибками и ручными корректировками
· если перенести всю историю, УТ 11.5 унаследует этот хаос
Результат: руководитель впервые понял, что «смена версии» проблему не решит, и согласился идти по предложенному пути.
2. Обучение ключевого сотрудника
Я выбрала ответственного сотрудника, вовлечённого в операционку. С ним я провела глубокую работу:
· Объяснила базовые принципы корректного ведения учёта в УТ: цепочка продаж, работа с закупками, складской учёт, партии
· На примерах из их базы показала, какие действия ломают картину
· Показала, почему «подправили руками» — источник постоянных проблем
Результат: 40+ часов обучения, растянутые на 3–4 недели. Появился человек, который понимает методологию, а не просто нажимает кнопки.
3. Частичный перенос данных
Я разработала нестандартный сценарий:
· Не тащить всю многолетнюю историю
· Переносить только: остатки на дату начала + операции за квартал
· Исторические периоды закрыть как архив
· В новой базе документы уже отражаются по корректной логике
Это заняло 4 недели, потому что нужно было не просто выбрать обработку, а доработать её, протестировать, провести сверку, переделать ошибочные строки вручную.
4. Обучение всей команды
После переноса я провела обучение по блокам: продажи, закупки, склад, казначейство. Не просто про кнопки, а про связь действий с отчётами.
Результат: сотрудники перестали воспринимать УТ 11.5 как чёрный ящик.
5. Защита номенклатуры и внедрение ИИ‑описаний
Проблема: Менеджеры постоянно меняли артикулы при работе с карточками для маркетплейсов, ломая связку 1С ↔ маркетплейсы ↔ бухгалтерия.
Решение:
1. Запретил изменение артикула после записи карточки
2. Внедрил генерацию описаний товаров через ИИ прямо из карточки номенклатуры
Теперь менеджеры не лазят по полям вручную. Описание формируется автоматически на основе данных карточки и подходит требованиям Wildberries и Ozon.
Результаты: был ли выигрыш за год ожидания?
Да. И существенный.
Для собственника и руководства:
· Верное отражение деятельности: управленческая отчётность теперь опирается на реальные данные, стало очевидно, какие товары и каналы действительно прибыльны
· Поставленный оперативный учёт: сотрудники работают по чётким правилам, есть обученный человек, который поддерживает порядок
· Стабильные интеграции: между УТ 11.5 и бухгалтерией без конфликтов; с маркетплейсами ошибки упали с 15–20 в месяц на 1–2
· Экономия времени: время подготовки описаний товаров сократилось с 30–40 минут на 5–10 минут
Для меня как аналитика:
Этот кейс показал, что ценность аналитика — не в выборе обработки, а в:
· Честной диагностике и умении назвать истинные сроки
· Архитектурных решениях: частичный перенос, защита реквизитов, ИИ как инструмент решения боли
· Выстраивании процессов и обучении людей
· Умении управлять ожиданиями
Главный урок этого кейса
Для руководителей: если аналитик говорит, что вместо 2 месяцев нужен год, это не значит, что он медленный или дорогой. Это значит, что он честно смотрит на проблему и берёт ответственность за результат, а не за галочки в чек-листе.
Для других аналитиков: когда видишь многолетний бардак в учёте, первый шаг — не выбор обработки переноса, а диагностика и переговоры. Потом — выбор правильного сценария. Потом — обучение людей, потому что система настолько хороша, насколько хороши процессы вокруг неё.
Для компаний: год работы над учётом — это инвестиция в то, чтобы система и люди работали по одним правилам. После этого года обслуживание будет дешевле и быстрее, а ошибок будет намного меньше.
С помощью правильной диагностики, архитектурных решений и системного подхода к обучению можно превратить 10-летний бардак в управляемую и надёжную систему, не ставя бизнес на паузу. Но это требует времени, честности о сроках и инвестиции в людей, а не только в технику.
Полезные статьи для аналитиков
