К содержимому
MoranaLabs.
Инженерные гайды11 мин чтения0 просмотров

Сроки внедрения ERP: почему три месяца  это один блок 

Честный календарь проекта по объемам работ: сколько длится обследование, блок и контур предприятия. Что лежит на критическом пути, почему решения заказчика растягивают график сильнее любых доработок и в какие месяцы переход запускать нельзя.

0xReality

Вопрос «сколько длится внедрение» звучит одинаково от всех, но означает разное. Один спрашивает, когда склад перестанет считать остатки в таблице. Другой — когда предприятие целиком уедет со старой системы. Между этими событиями год разницы.

Разберем календарь по объемам работ. Про деньги отдельно есть разбор сметы, про приемку — статья о критериях закрытия этапов. Здесь только время.

Честные вилки

Что запускаемКалендарьЧто определяет срок
Обследование3–4 недели, для производства 4–6Доступность ваших людей для интервью
Один функциональный блок3–5 месяцевОбъем доработок и состояние справочников
Торговый контур: закупки, склад, продажи5–7 месяцев с обследованиемЧисло складов, юрлиц и внешних обменов
Плюс производство и себестоимость9–12 месяцевГотовность спецификаций, маршрутов и норм
Контур предприятия целикомот 14 месяцевЧисло блоков и скорость принятия решений
Переход с зарубежной системыот 9 месяцевОбъем истории и требования к отчетности

Отсюда ответ на вопрос из заголовка. Три месяца — это реальный срок для одного блока среднего объема. Услышав «внедрим ERP за три месяца», уточните, что именно будет работать на исходе третьего месяца и что останется в старой системе. Обычно выясняется, что речь про склад и продажи, а производство, себестоимость и зарплата даже не обсуждались.

На вилки влияет и размер компании, но слабее, чем принято думать. Разница между сорока и двумя сотнями рабочих мест — это в основном объем обучения и число согласований. Настройка блока при этом почти одинаковая: процессов у компании столько же, просто людей на каждом больше. По-настоящему срок двигают две вещи: сколько у вас юрлиц со своими схемами и сколько внешних систем надо связать с учетной.

Календарь определяется не объемом работ

Главное непонимание в оценке сроков: люди складывают трудозатраты и делят на размер команды. Так получается срок работы подрядчика. Календарь проекта считается иначе.

Возьмем этап с сорока рабочими днями работ. Внутри него команда четырнадцать раз упирается в решение, которое принимает заказчик: какой из двух вариантов согласования заявки оставляем, кто отвечает за нормативную цену, что делать с позициями без штрихкода. Если каждое решение ждет пять рабочих дней, набегает семьдесят дней ожидания против сорока дней работы.

Часть ожиданий перекрывается другими задачами, но не все: половина решений блокирует продолжение. В итоге этап на восемь недель работы занимает четырнадцать недель календаря. Ни одного лишнего дня разработки при этом не потрачено.

Вывод практический. Хотите сжать график — сокращайте не объем работ подрядчика, а время принятия решений на своей стороне. Один человек с полномочиями и двумя часами в неделю на проект экономит месяцы.

Как посчитать свой срок за пятнадцать минут

Прикидка, которая работает лучше интуиции. Нужны две величины: оценка работ в рабочих днях, которую дает подрядчик, и ваша честная скорость принятия решений. Вторую посмотрите в почте: сколько в среднем проходит от вопроса подрядчика до письменного ответа.

Дальше арифметика. Решение требуется примерно на каждые три дня работ, блокирует продолжение примерно половина из них. Значит:

Календарь в рабочих днях = Работы + (Работы ÷ 6) × Дни на решение, плюс пятнадцать процентов буфера.

Посчитаем на этапе в двадцать пять рабочих дней при скорости решений три дня. Двадцать пять разделить на шесть — примерно четыре блокирующих решения, каждое по три дня, итого двенадцать дней ожидания. Двадцать пять плюс двенадцать — тридцать семь дней, с буфером сорок три. Это девять недель календаря против пяти недель работы.

Теперь поставьте скорость решений в один день вместо трех: получится тридцать три дня, то есть семь недель. Две недели разницы на одном этапе, и это без единого изменения в объеме работ. На проекте из восьми этапов набегает квартал.

Формула грубая и на нее нельзя ссылаться в договоре. Но если ваш подрядчик обещает срок, который меньше расчетного вдвое, вопрос к нему надо задать до подписания.

Что лежит на критическом пути

Критический путь — цепочка работ, где каждая следующая не может начаться раньше окончания предыдущей. Задержка на нем сдвигает весь проект. Все остальное можно вести параллельно и на срок оно не влияет.

РаботаКритический путьКомментарий
ОбследованиеДаБез него не начинается ничего
Решения по спорным процессамДаГлавный источник простоя
Настройка и доработки блокаДа
Чистка справочниковНетВедется вашими силами параллельно настройке
Написание инструкцийНетПишется по мере готовности функций
Внешние обменыЧастичноРазработка параллельна, тестирование требует готового блока
Обучение пользователейДаРаньше стабилизации блока смысла не имеет
Перенос данных и сверкаДаФинальный прогон только на замороженном контуре
Опытная эксплуатацияДаДлительность диктует бизнес-цикл, обычно месяц

Из таблицы следует неочевидное. Чистка справочников — самая трудоемкая работа заказчика, но она не на критическом пути и может идти с первого дня проекта, хоть до подписания договора на основные работы. Компании, которые начали приводить номенклатуру в порядок заранее, экономят на переносе данных и недели, и деньги.

Пять пожирателей календаря

Нормативно-справочная информация. Единый справочник номенклатуры для компании, где склад, продажи и производство десять лет вели свои названия одной и той же позиции, — это переговоры между отделами. Технической работы там меньше всего. Закладывайте от трех недель до двух месяцев и назначайте арбитра заранее.

Решения, которые некому принять. Разобрано выше. Самая дорогая позиция в календаре.

Смежные системы. Обмен с сайтом, площадками, банком или системой партнера тормозит не своей сложностью, а чужой скоростью: ответ от поддержки внешнего сервиса приходит за неделю, а тестовый контур вам дают за две. Начинайте согласование доступов на старте проекта. Ожидание готовой разработки обмена — потерянные недели.

Готовность производственных данных. Для производственного контура это главный риск графика. Спецификации, маршруты и нормы времени редко лежат в пригодном виде, а без них планирование не запускается. Если норм нет вообще, первым этапом идет их наведение, и это отдельные месяцы.

Люди. Проект живет за счет тех же сотрудников, которые ведут операционную работу. Команда из шести человек, у каждого две недели отпуска летом, теряет двенадцать человеко-недель на июль и август. Это не форс-мажор, а предсказуемая величина, которую надо закладывать в план сразу.

В какие месяцы переход не запускают

Календарные ловушки, которые видно заранее и о которых почему-то вспоминают в последний момент.

  • Декабрь и январь. Соблазн начать год в новой системе понятен, но декабрь — это годовая отчетность, инвентаризация, отгрузки перед праздниками и отпуска. Заказчик физически недоступен. Переход первого января почти всегда означает переход, к которому никто не готовился в декабре.
  • Пик сезона. У ритейла это ноябрь и декабрь, у производства — месяцы максимальной загрузки заказами, у аграриев — посевная и уборочная. Переход в пик означает, что при первой же заминке бизнес встанет.
  • Конец квартала. Последние две недели квартала команда занята закрытием и отгрузками. Планировать на этот период приемку этапа бессмысленно.
  • Июль и август. Отпуска съедают ключевых пользователей. Настройку вести можно, приемку и обучение — нет.

Хорошая дата перехода — первое число месяца после закрытого предыдущего, в спокойный период. Февраль, март, сентябрь и октябрь подходят почти всем.

Что реально запустить за месяц

Отдельный разговор для тех, кому результат нужен вчера. Полноценный блок за месяц не запускается, но месяц — достаточный срок для работ, которые снимают конкретную боль и не требуют перестройки учета.

  • Обмен с банком и разбор выписки. Две-три недели, убирает ручной ввод платежей.
  • Обмен с одной торговой площадкой. Три-четыре недели с тестированием, снимает ручную выгрузку заказов и остатков.
  • Один тяжелый отчет. Тот самый, который финансист собирает руками три дня в конце месяца. Обычно неделя-две работы.
  • Чистка и объединение справочника номенклатуры. Ваша работа, наш регламент и проверочные выгрузки. Месяц силами двух человек на десять тысяч позиций — реалистично.
  • Техаудит производительности. Неделя, если система тормозит и непонятно почему.

Смысл таких работ двойной. Во-первых, они окупаются сами по себе. Во-вторых, это дешевый способ посмотреть на подрядчика в деле до того, как подписывать договор на годовой проект. Мы обычно предлагаем начинать именно так, если у клиента нет уверенности в исполнителе: месяц совместной работы говорит о команде больше, чем любая презентация.

Три сценария срыва графика

Срок назвали до обследования. Классика. Продавец обещает полгода, чтобы выиграть тендер, команда получает проект с невыполнимым планом. Дальше два варианта: либо сроки поедут и все будут виноваты, либо в срок уложатся за счет пропущенного тестирования, и вы получите работающую по документам систему, в которой нельзя провести возврат. Оценка срока без обследования — это маркетинг, и относиться к ней надо соответственно.

Требования поменялись на опытной эксплуатации. Люди впервые видят систему в работе и начинают понимать, чего хотели. Часть замечаний справедлива, часть — попытка воспроизвести привычки старой системы. Лечится регламентом: замечания делятся на блокирующие запуск и остальные, вторые собираются в список для следующего этапа. Без такого разделения проект уходит в бесконечную доработку и не стартует никогда.

Данные никто не готовил. Самый частый и самый тихий сценарий. Все идет по плану до момента переноса, а потом выясняется, что в справочнике двадцать тысяч позиций, из них живых четыре, дубли не размечены и ответственного за них нет. Плюс от месяца к графику, причем в самой неудобной точке — перед стартом, когда дата уже объявлена всей компании.

Сменилась команда подрядчика. Четвертый сценарий, о котором редко говорят вслух. Аналитик, который вел обследование, уходит в другой проект, на его место приходит человек, читающий ваши документы впервые. Месяц уходит на погружение, и это в лучшем случае, когда документы вообще есть. Защита простая: зафиксируйте в договоре поименный состав ключевых ролей и обязанность передавать дела письменно. Требовать несменяемости бессмысленно, а требовать нормальной передачи — вполне реально.

Как выглядит график, который не поедет

Признаки плана, которому можно верить.

  1. Проект разбит на куски по три-шесть недель, каждый заканчивается работающей функцией.
  2. У каждого куска назван результат, по которому его принимают, и человек с вашей стороны, который принимает.
  3. В плане есть строки для решений заказчика с датами, после которых график сдвигается.
  4. Заложен буфер на опытную эксплуатацию, обычно месяц.
  5. Учтены отпуска, закрытие периодов и сезонность бизнеса.
  6. Дата отключения старой системы поставлена условно и уточняется по факту закрытого месяца.

План на год с точностью до недели, где нет ни одной строки про обязанности заказчика, — красивый документ, который перестанет соответствовать реальности на шестой неделе.

Что делать, когда сроки уже горят

Ситуация обычная: дату назвали руководству, а проект отстает. Работающих решений три, и все они про объем.

Сузить контур первого запуска. Вынести из первой очереди все, что может месяц пожить в старой системе. Один работающий блок лучше трех недоделанных.

Отложить нетиповые доработки. Половина из них после трех месяцев работы в системе отмирает сама, потому что люди привыкают к штатной логике. Оставьте то, без чего процесс физически не идет.

Сдвинуть глубину переноса. Стартовать на справочниках и остатках, историю подтянуть после запуска отдельной работой. Прием подробно разобран на странице перехода с SAP, но работает при любой смене системы.

Чего делать нельзя: сокращать тестирование, обучение и опытную эксплуатацию. Это единственные этапы, экономия на которых оплачивается не деньгами, а остановкой отгрузок в первую неделю после старта.

И самое неприятное решение, которое иногда единственно верное: перенести дату. Разговор с руководством о переносе на месяц неприятен ровно один день. Разговор о том, почему компания неделю не может отгружать товар, потому что систему запустили в срок и неготовой, длится кварталами и стоит должностей. Если к моменту принятия решения не сошелся ни один контрольный срез по данным, дату надо двигать, и лучше сделать это за три недели до старта, чем за три дня.

Два месяца после старта, о которых не предупреждают

В графиках проект заканчивается датой промышленного запуска. В жизни после нее начинается стабилизация, и планировать на этот период что-то еще бессмысленно.

Первые две недели идет вал мелких обращений: не нашел кнопку, не хватает прав, печатная форма встала не так. Это нормально и лечится дежурством консультанта на линии. Следующие две-три недели вскрываются сценарии, которые никто не вспомнил на обследовании, потому что они случаются раз в квартал: возврат от розничного покупателя, пересорт по браку, отгрузка на экспорт. Каждый требует небольшой доработки.

Отдельный рубеж — первое закрытие месяца в новой системе. Оно всегда идет дольше обычного, потому что бухгалтерия проверяет каждую цифру дважды. Закладывайте на первое закрытие двойное время и не ставьте на эти дни никаких других задач проекта.

Параллельный учет, если вы его вели, заканчивается именно здесь: старая система отключается после того, как месяц сошелся. Держать два контура дольше разумного — тоже риск, люди начинают вести учет в обоих местах вполсилы, и данные расходятся уже по вине процесса.

Полная нормализация занимает два месяца от старта. К этому моменту поток обращений падает до единичных, и проект переходит в обычную эксплуатацию.

Коротко

Обследование — три-четыре недели. Один блок — три-пять месяцев. Торговый контур — пять-семь месяцев. С производством — девять-двенадцать. Предприятие целиком — от четырнадцати месяцев. Переход с зарубежной системы — от девяти.

Календарь определяют не трудозатраты подрядчика, а скорость решений на вашей стороне, состояние справочников и календарь вашего бизнеса. Любой срок, названный до обследования, — предположение, и единственный способ получить честный план этапов — заказать обследование и получить его в письменном виде. Если проект уже идет и график поехал, имеет смысл посмотреть на него со стороны через аудит внедрения, пока сдвиг измеряется неделями, а не кварталами.

  • #
  • #ERP
  • #внедрение
  • #планирование
  • #сроки
  • #управление проектом
ПоделитьсяTelegramX
рассылка

Новые статьи — на почту

Лонгриды про ML в проде, edge и компьютерное зрение — сразу после выхода.

Канал в Telegram: morana.log

Без спама. Нажимая «Подписаться», соглашаетесь с обработкой персональных данных

бесплатный pdf-гайд

Edge AI или облако: когда тащить нейросеть на железо

Признаки, фреймворк выбора и прикидка экономии — короткий PDF-гайд на почту.

PDF · 5 страниц · без спама. Нажимая «Получить», соглашаетесь с обработкой персональных данных

Читать дальше
— заявка

Опишите задачу  ответим как инженеры. 

Оставьте имя и Telegram — остальное обсудим. Без брифов на 40 слайдов и звонков по три раза.

Отвечаем за пару часовотвечает инженер, а не отдел продажNDA по запросу

Сюда напишем — это быстрее всего

Или сразу написать в Telegram

Без спама и звонков-роботов. Нажимая кнопку, вы соглашаетесь с политикой конфиденциальности и обработкой персональных данных.