Кітаптан алынған дәйексөздер ERP-проект. Как делатьавтор Кирилл Ледовский
И наоборот, если проект сознательно завершён на уровне спроектированной модели, это не «недоделанный проект», а честно определённый объём с понятной границей.
Первый уровень — описано. Это означает, что определённый аспект предприятия зафиксирован на основании принятых источников и решений. Второй — спроектировано: определена целевая конструкция, то есть уже не просто восстановлено текущее состояние, а принято, как должно быть. Третий — привязано к системе: для требования найдено конкретное техническое место реализации в целевой ERP или смежной системе.
Четвёртый уровень — проверяемо. Здесь существует воспроизводимый сценарий, который позволяет однозначно отличить ожидаемый результат от ошибки. Пятый — фактически проверено: сценарий действительно выполнен в определённой среде, на определённых данных, и результат зафиксирован. Каждый следующий уровень требует дополнительной работы; он не возникает автоматически из предыдущего
При этом рабочая модель проекта и документ, который видит заказчик, не обязаны быть одним и тем же объектом. Рабочая модель может быть значительно структурнее: в ней хранятся связи, версии, источники, состояния и зависимости. Человекочитаемый документ нужен для обсуждения, проверки и принятия решений.
И последнее правило чтения: не превращайте эту книгу в ещё один архив знаний. Её ценность проявляется только тогда, когда принципы возвращаются в текущий проект. Выберите один спорный участок, пройдите его по маршруту от рамок и источников до прикладной реализации и проверки, отметьте места, где ответ приходится угадывать, и не маскируйте их красивым текстом. Именно эти точки показывают, где проект теряет связность.
Когда книга переходит к прикладной реализации, сравнивайте не «наш документ» и «типовой документ», а две причинные конструкции. Что именно требуется предприятию? Какое поведение поддерживает штатный механизм? Какие параметры и данные делают его применимым? Что остаётся организационным или информационным разрывом, а что действительно требует изменения конфигурации? Такой подход одинаково полезен и при новом внедрении, и при попытке заменить старую доработку современной типовой возможностью.
Раздел о НСИ, параметрах, аналитиках и отчётности лучше читать с обратной стороны — от результата. Если руководителю нужен показатель, попробуйте пройти назад: из каких фактов он складывается, какие аналитики различают эти факты, где значения впервые становятся известны, кто их определяет и каким объектом они фиксируются. Такой обратный маршрут быстро обнаруживает красивую отчётность без исходных данных и обязательные поля, которые пользователи вынуждены заполнять раньше, чем знают правильный ответ.
Сначала определяется, что произошло в деятельности, затем — какой экономический смысл имеет событие, когда он признаётся, в какой оценке и по каким аналитикам.
Сначала должно быть понятно, какое состояние предприятия мы хотим удержать, какой факт для этого нужен, где он возникает и кто отвечает за его определение. Только после этого вопрос «каким объектом 1С это реализовать?» становится корректным.
Полезно держать рядом один живой пример из собственной работы. Это может быть заказ клиента, ремонтная потребность, производственный этап, обязательный реквизит, старая доработка, управленческий отчёт или интеграционный сценарий. По мере чтения попробуйте каждый раз отвечать на один вопрос: какой слой проекта сейчас объясняет этот объект и чего о нём ещё нельзя утверждать? Такой способ быстро показывает разницу между «мы нашли документ», «мы поняли процесс», «мы определили экономический смысл», «мы нашли место реализации» и «мы действительно проверили результат».
Руководитель действующей сложной ERP может начать с первого тома, потому что узнает там собственную боль. Аналитик, который постоянно спорит о границах процессов, может войти через «ERP-Лабиринты». А специалист, которому уже поручили организовать обследование, проектирование или модернизацию, способен сразу открыть третий том.