ERP-проект. Как делать

Почему следующий этап не должен начинать проект заново

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

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

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

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

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

Результат этапа должен иметь самостоятельную ценность

Полный маршрут не означает, что каждый ERP-проект обязан дойти до последней точки. Иногда предприятию нужно только надёжно определить рамки и провести обследование. В другом случае требуется операционная модель, которую затем реализует собственный проектный офис. Третий проект заканчивается экономико-учётной постановкой и требованиями к данным. Четвёртый действительно проходит весь путь до фактической проверки в 1С: ERP. Глубина определяется задачей, риском и договорным объёмом, а не желанием обязательно пройти все ступени.

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

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

Эта граница особенно полезна при споре о готовности. Вместо общего слова «готово» появляется точный ответ: какая часть проекта описана, что уже спроектировано, где найдено место реализации, что подготовлено к проверке и что фактически подтверждено. Разговор перестаёт зависеть от впечатления о количестве страниц и переходит к состоянию результата.

Пять уровней готовности результата

В сложном проекте слова «описано», «спроектировано», «реализовано» и «проверено» часто звучат как почти равные. Из-за этого стороны способны честно согласиться, что задача завершена, а через неделю обнаружить, что имели в виду разные вещи. Чтобы этого избежать, полезно различать пять уровней.

Первый уровень — описано. Это означает, что определённый аспект предприятия зафиксирован на основании принятых источников и решений. Второй — спроектировано: определена целевая конструкция, то есть уже не просто восстановлено текущее состояние, а принято, как должно быть. Третий — привязано к системе: для требования найдено конкретное техническое место реализации в целевой ERP или смежной системе.

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

Такое различение хорошо дисциплинирует ожидания. Согласованная схема процесса — ценный результат, но она не становится доказательством настройки. Найденный типовой механизм — важный шаг, но он ещё не доказывает сквозное исполнение. Написанный тест — не успешный прогон. И наоборот, если проект сознательно завершён на уровне спроектированной модели, это не «недоделанный проект», а честно определённый объём с понятной границей.

Что в итоге называется связанной цифровой моделью

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

Ключевое свойство здесь — не полнота списка, а преемственность. Факт обследования должен быть узнаваем в операционной модели, операционное событие — получать экономическую интерпретацию, экономическая потребность — формировать требование к данным, а данные — иметь определённое место возникновения и использования в ERP. Модель становится источником сценария, сценарий — источником проверки, а существенное изменение по цифровой нити возвращается в тот слой, который оно действительно меняет.

Если эти переходы сохранены, предприятие получает не просто комплект проектной документации. Оно получает объяснимую конструкцию, в которой можно двигаться как вперёд — от нормы к реализации, так и назад — от странного поля, цифры или доработки к причине её появления. Именно такая способность понадобится дальше, когда мы начнём последовательно разбирать каждый этап. Первый из них кажется самым простым и поэтому особенно часто выполняется поверхностно: нужно точно определить, что именно входит в ERP-проект.

Глава 2. Сначала определить, что именно мы проектируем

Один завод — несколько разных границ

На старте проекта заказчик часто говорит очень просто: «Нужно внедрить ERP на предприятии». Формулировка кажется достаточной, пока команда не начинает уточнять детали. Выясняется, что юридических лиц несколько, производство расположено на двух площадках, центральный склад обслуживает обе, транспортный участок пока остаётся в старой системе, столовая нужна только для учёта затрат, лаборатория участвует в качестве, но работает во внешнем решении, а часть ремонтных функций вообще выполняет подрядчик.

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

Именно поэтому понятие «входит в проект» слишком грубое. Для большого предприятия нужно несколько независимых рамок. Один объект может входить в организационный охват, но не требовать детального процессного проектирования. Процесс может быть нужен для понимания хозяйственных событий, но остаться ручным. Система может вообще не меняться, но участвовать в интеграции. Реализованное решение может быть шире, чем согласованный объём проверки.

Это не бюрократия и не попытка заранее усложнить проект. Наоборот, независимые рамки позволяют не тащить в глубокую разработку всё предприятие только потому, что оно существует. Они дают возможность говорить о конкретном объёме работ без постоянной подмены: «мы же знали, что у нас ещё есть этот участок, значит он тоже должен быть автоматизирован».

Шесть рамок, которые не обязаны совпадать

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

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

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

Четвёртая рамка — автоматизационная. Она показывает, что именно будет реализовано, изменено или перенесено в ERP. Наличие процесса в модели ещё не означает, что его нужно автоматизировать. Иногда достаточно определить интерфейс с внешней системой. Иногда ручная процедура осознанно остаётся ручной, но её результат должен быть зарегистрирован в ERP в конкретной точке.

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

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