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