Ответ в одном абзаце: не соглашаться на проект, у которого единственная контрольная точка — запуск через год. Разбивать его на этапы, каждый из которых заканчивается работающим куском системы, а не отчётом о проделанной работе. Назначать владельца процесса и ключевых пользователей с реальными полномочиями. Мерить прогресс по тому, что уже используется, а не по тому, что оплачено. Дальше — механика и цена такого подхода.
Почему «водопад» показывает эффект после 70–80% затрат
Классическая схема выглядит логично: обследование, проектирование, разработка, тестирование, обучение, запуск. Каждый этап завершается документом, который принимает заказчик. Но ни один из этих документов не является работающей системой. По открытым ориентирам такой проект длится 1,5–2 года, первые результаты появляются через 9–12 месяцев, а новую систему начинают использовать, когда потрачено уже 70–80% бюджета.
Пока система не используется, её никто по-настоящему не проверяет. Ключевой пользователь смотрит на прототип и говорит «вроде так». Архитектурная ошибка, заложенная на втором месяце, обнаруживается на четырнадцатом — когда переделывать её значит переделывать всё, что построено сверху. Отсюда остальные свойства водопада:
требования трудно менять — изменение бьёт по всей цепочке уже принятых документов;
запуск становится стрессом для всей компании сразу, а не для одного отдела;
откат практически невозможен: старая система уже не ведётся, новая ещё не работает.
Руководитель в такой схеме год подписывает акты и не имеет ни одного способа проверить, что проект идёт к результату, а не к акту. Это главный управленческий дефект водопада, а не длительность сама по себе.
Этапы с точками выхода
Альтернатива приземлённее, чем «гибкая методология»: проект режут на части по контурам учёта. Каждая часть — склад, производство, закупки, продажи, иногда отдельный цех — запускается сама по себе, но все строятся по общей архитектуре, заданной в начале. Старая система всё это время ведёт учёт. Порядок этапов внедрения 1С:ERP и вилки сроков интеграторы публикуют открыто, например на smart-process.ru/vnedrenie-erp: первый этап — 2–3 месяца, проект целиком — 12–18 месяцев. Два подхода тот же интегратор сравнивает так.
Длительность: Водопад — 1,5–2 года; Поэтапно — 1–1,5 года.
Первый работающий результат: Водопад — через 9–12 месяцев; Поэтапно — через 2–3 месяца.
Доля затрат к моменту начала использования: Водопад — 70–80%; Поэтапно — бюджет первого блока.
Когда видна ошибка архитектуры: Водопад — ближе к концу, когда на ней всё построено; Поэтапно — на первых запущенных блоках.
Возможность остановиться: Водопад — без результата; Поэтапно — с работающими блоками на руках.
В одном опубликованном переходе с доработанной 1С:УПП на 1С:ERP первым запустили склад и две недели смотрели, как он живёт в новой системе, прежде чем двигаться дальше. Потом пришла очередь производства, продаж, закупок и финансов, а УПП отключили последней. Бухгалтерия всё это время оставалась в старой системе, оперативные документы вводили уже в новой. Точка выхода — не принятая презентация, а отдел, который уже работает в новой системе. В этот момент руководитель решает, идти ли дальше, взять паузу или сменить подрядчика, и ни один из вариантов не обнуляет сделанное.
У поэтапного подхода своя цена, и её стоит заложить в план с самого начала. Месяцами две системы живут рядом: документы передаются из одной в другую, и кто-то регулярно проверяет, что остатки и обороты совпадают. В том же кейсе для этого строили отдельный обмен с журналом и автоматической проверкой расхождений. Это отдельная строка бюджета на интеграцию — плата за то, что бизнес не останавливается.
Роли, без которых этапы не работают
Этапность не спасёт, если на стороне компании некому принимать решения. Три роли, которые руководитель должен назначить сам, а не ждать от подрядчика:
- Владелец процесса — руководитель отдела, который будет жить в новом блоке. Он решает, как будет устроен процесс, и отвечает за то, что отдел перейдёт на новую схему. Если с каждым вопросом он идёт к генеральному, это не владелец процесса, а курьер.
- Ключевые пользователи — сотрудники, которые знают процесс в деталях и проверяют систему на реальных операциях, а не на демонстрационных данных. Их участие нужно закрепить официально: сколько часов в неделю, кто подменяет на время тестирования. Иначе проверка превращается в «посмотрю вечером, если успею».
- Руководитель проекта со стороны заказчика — человек, который держит границы этапов, следит за точками выхода и не даёт подрядчику и отделам расширять объём «раз уж всё равно переделываем».
Руководитель компании нужен в двух моментах: на обследовании, когда решают, чего проект должен добиться в часах, днях и деньгах, и на каждой точке выхода. В текущих решениях его участие скорее мешает: выбор делает тот, кому не работать с результатом.
Как ставить контрольные точки
Контрольная точка — это не дата и не документ. Это проверяемое событие в работе компании. Признаки правильной контрольной точки:
её можно проверить, зайдя в отдел, а не в папку с актами: склад две недели проводит приёмку в новой системе, плановик строит план производства без Excel;
у неё есть измеримый результат «до» и «после» в рабочих единицах — часы на операцию, дни на закрытие периода, количество ручных сверок;
она привязана к блоку, а не к проекту целиком.
Исключение из правила «проверить в отделе» одно — первая точка: она наступает раньше любого запуска, в конце первого этапа через 2–3 месяца. К этому моменту у компании должны быть модель процессов, архитектура и план, по которым можно оценить весь проект и решить, продолжать ли его. Оценка проекта целиком до обследования — не оценка, а угадывание; один запуск через год без промежуточных точек — согласие узнать о проблемах тогда, когда исправлять их дороже всего.
Загрузка...
