Ты предлагаешь "оставить психбольницу в руках пациентов"?

[sukhanchik]

Цитата:

Сообщение от Vals

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

Цитата:

Сообщение от Atar

Как то очень огульно Вы хаете. Следовать Вашим советам - значит бесполезно раздуть кратно бюджеты внедрений, получив в результате "красивую" систему. Только стоит ли оно того?
...
Всегда есть баланс следования методологии/Best Practice и затрат.

Как тут уже говорилось - заказчику иногда нужен бизнес-консалтинг, а не ИТ-консалтинг.
Так вот - вполне себе нередки случаи, когда сначала заказчик отклоняется от бизнес-процессов, заложенных в систему, а потом к ним приходит. Только за это время уже написаны и оплачены тонны кода. И, конечно, всем выгодно ругать все прошлое.
Любое программирование так или иначе будет оставлять в себе куски кода, "которые не работают или генерят ошибки". Как говорится - код с течением времени "протухает". Это кстати хорошо заметно в АХ 2009, если сравнивать ее с АХ 3. Взяли - что-то поменяли глобальное - вылезли проблемы с формами (к примеру). А о них никто не задумался. Аудиторы приходят и видят кучу функций, "которые не работают или генерят ошибки". И каждый прав по своему.

Другие модули. Опять-таки - если изначально не планировать их к использованию - это одно. Если планировать - это другое.
Пример. Была модификация "Разноска по складу", кочующая из проекта в проект у внедренцев. Решили локализаторы ее реализовать. В результате учета всех моментов в системе - реализовался функционал профилей учета. Я не берусь судить за всех внедренцев - но у некоторых - эта модификация была на порядок проще существующего функционала профилей учета. Но, конечно - она не учитывала те или иные моменты. И, возможно, где-то наступала на горло существующему функционалу. Но если сравнивать эти 2 варианта реализации - то вариант, реализованный в рамках локализации может быть неподъемным для бюджета внедрения (будем считать, что реализация от МС является эталонной по качеству, а также что локализация учитывает все стандартные настройки и не ломает нигде буржуйский функционал ).

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

Другое дело - что можно и палку перегнуть (и такие примеры есть - вспомним перекресточное решение - когда многое чего было реализовано параллельно).

А вот найти "золотую середину"... достаточно сложно. Наверное поэтому при аудите приглашают независимо несколько аудиторов для составления картины из нескольких независимых отчетов