05.09.2011, 22:21 | #21 |
Участник
|
Цитата:
Я пытался сделать предположение, с чем это может быть связано. Первое что приходит в голову - что язык х++ очень прост и программировать на нем гораздо интересней чем читать горы документации. Но я не могу исключить и версию о которой здесь говорили - таким образом некоторые пытаются посадить клиента на крючок. Правильно! НО НЕ научно все это как то.... Всяк другого мнит уродом...... |
|
05.09.2011, 23:53 | #22 |
Administrator
|
Цитата:
Т.е. уровень доверия к х++ гораздо выше, чем к документации. Отсюда - большое кол-во специалистов по х++, которым гораздо проще влезть в код, нежели в документацию.
__________________
Возможно сделать все. Вопрос времени |
|
06.09.2011, 09:41 | #23 |
MS Dynamics AX 2012 R3
|
Цитата:
Сообщение от sukhanchik
А еще аргумент в пользу x++ состоит в том, что вся та документация, которая была и есть на систему бывает не отражает реалии.
Т.е. уровень доверия к х++ гораздо выше, чем к документации. Отсюда - большое кол-во специалистов по х++, которым гораздо проще влезть в код, нежели в документацию.
__________________
"Человек человеку волк, а зомби зомби зомби." (с) С Уважением, Алексей Кабанов Последний раз редактировалось ZornFire; 06.09.2011 в 10:05. |
|
06.09.2011, 09:51 | #24 |
Administrator
|
это не только по отчетности (и скорее даже больше не по отчетности), и не обязательно бухгалтерских принципов (смотря какой код ковыряешь) - но понятно - что без знания предметной области особо много не сделаешь.
__________________
Возможно сделать все. Вопрос времени |
|
06.09.2011, 09:55 | #25 |
Участник
|
Цитата:
Не у всех есть возможность поработать в партнере МС, соответственно далеко не все знают как с этим работать! Да и в партнерах тоже, видимо, учат не очень - нам, например, "прилепили" (по другому не скажешь) свою трансляцию заказов/закупок и др. при наличии стандартной!!! Вот отсюда и бардель в модификациях!
__________________
Axapta 3.0 sp - хз какой, kr2 |
|
|
За это сообщение автора поблагодарили: Atar (0). |
06.09.2011, 12:42 | #26 |
Аманд
|
Цитата:
- Повторное программирование аналога стандартной функциональности - Программирование функций которые не работают или генерят ошибки - Невозможность использования других модулей системы, кроме тех, которые доработаны. (так как разорваны все связи) - Невозможность использования стандартных настроек, так как доработки о них не знают и т.д. Причём такие перлы чуть ли не на каждом проекте по экспертизе. |
|
06.09.2011, 16:34 | #27 |
Консультант
|
Цитата:
Сообщение от Vals
Всё, о чём уже говорилось:
... - Невозможность использования других модулей системы, кроме тех, которые доработаны. (так как разорваны все связи) - Невозможность использования стандартных настроек, так как доработки о них не знают и т.д. Причём такие перлы чуть ли не на каждом проекте по экспертизе. - Разве в требованиях клиента "чуть ли не на каждом проекте " указано что то отличное от того, что реализовано? - Разве в дизайне решения (ТД, ТЗ и пр.) не указаны ограничения и написано (опять) не то, что реализовано? Вот пример: Разве не во благо экономии времени/денег не выполнялась, ну, к примеру, доработка налоговых проводок при выполнении связанной модификации в проекте внедрения, изначально ориентированном исключительно на логистический контур? Если документация отличается от реализованного или документации нет, то это совсем другой разговор и дело не в уродовании системы, а профессионализме внедренца. Да и причём тут документация! А как же здравый смысл? А как же "не умножать сущности"? Как то очень огульно Вы хаете. Следовать Вашим советам - значит бесполезно раздуть кратно бюджеты внедрений, получив в результате "красивую" систему. Только стоит ли оно того? Возможно, Вы и не имели ввиду, что каждый проект должен проводиться ровно до тех пор, пока не - Станет возможным использование других модулей системы, кроме тех, которые реально нужны клиенту. - Станет возможным использование всех (!) стандартных настроек, которые клиент никогда не планирует использовать. Но оговорка о "чуть ли не каждом" говорит именно об этом. Всегда есть баланс следования методологии/Best Practice и затрат. Последний раз редактировалось Atar; 06.09.2011 в 16:36. |
|
|
За это сообщение автора поблагодарили: dn (1). |
06.09.2011, 17:05 | #28 |
Administrator
|
Цитата:
Сообщение от Vals
Всё, о чём уже говорилось:
- Повторное программирование аналога стандартной функциональности - Программирование функций которые не работают или генерят ошибки - Невозможность использования других модулей системы, кроме тех, которые доработаны. (так как разорваны все связи) - Невозможность использования стандартных настроек, так как доработки о них не знают и т.д. Цитата:
Так вот - вполне себе нередки случаи, когда сначала заказчик отклоняется от бизнес-процессов, заложенных в систему, а потом к ним приходит. Только за это время уже написаны и оплачены тонны кода. И, конечно, всем выгодно ругать все прошлое. Любое программирование так или иначе будет оставлять в себе куски кода, "которые не работают или генерят ошибки". Как говорится - код с течением времени "протухает". Это кстати хорошо заметно в АХ 2009, если сравнивать ее с АХ 3. Взяли - что-то поменяли глобальное - вылезли проблемы с формами (к примеру). А о них никто не задумался. Аудиторы приходят и видят кучу функций, "которые не работают или генерят ошибки". И каждый прав по своему. Другие модули. Опять-таки - если изначально не планировать их к использованию - это одно. Если планировать - это другое. Пример. Была модификация "Разноска по складу", кочующая из проекта в проект у внедренцев. Решили локализаторы ее реализовать. В результате учета всех моментов в системе - реализовался функционал профилей учета. Я не берусь судить за всех внедренцев - но у некоторых - эта модификация была на порядок проще существующего функционала профилей учета. Но, конечно - она не учитывала те или иные моменты. И, возможно, где-то наступала на горло существующему функционалу. Но если сравнивать эти 2 варианта реализации - то вариант, реализованный в рамках локализации может быть неподъемным для бюджета внедрения (будем считать, что реализация от МС является эталонной по качеству, а также что локализация учитывает все стандартные настройки и не ломает нигде буржуйский функционал ). Т.е. тут как бы получается так - задача аудитора - найти все эти огрехи. Но эти огрехи были и будут всегда - и это нормально, если внедрение не является разработкой софта . Другое дело - что можно и палку перегнуть (и такие примеры есть - вспомним перекресточное решение - когда многое чего было реализовано параллельно). А вот найти "золотую середину"... достаточно сложно. Наверное поэтому при аудите приглашают независимо несколько аудиторов для составления картины из нескольких независимых отчетов
__________________
Возможно сделать все. Вопрос времени |
|
06.09.2011, 19:42 | #29 |
Аманд
|
Цитата:
2. Бюджеты раздувает не аудит |
|
|
За это сообщение автора поблагодарили: Мартынов Дмитрий (1). |
06.09.2011, 21:28 | #30 |
Участник
|
Цитата:
Сообщение от sukhanchik
А еще аргумент в пользу x++ состоит в том, что вся та документация, которая была и есть на систему бывает не отражает реалии.
Т.е. уровень доверия к х++ гораздо выше, чем к документации. Отсюда - большое кол-во специалистов по х++, которым гораздо проще влезть в код, нежели в документацию. |
|
07.09.2011, 16:27 | #31 |
Участник
|
Добрый день, коллеги.
Нашу версию мы изложили в колонке: Вредные мысли от Алана Купера С уважением, Александр Дублин. |
|
09.09.2011, 14:07 | #32 |
Участник
|
Цитата:
Щас работаю с 1С. Всё делаем внутренними силами. И вот такая арифмеетика выходит. цена системы = цена продукта + цена владения(зарплата ит персонала) Что такое цена продукта для клиента? Это аванс, который он даёт, ожидая в дальнейшем получить то, что ему нужно от системы. С Аксой так выходит, что платиш в 10 раз больше за продукт, а получаеш за это в 10 раз меньше. Деньги просто уходят в никуда. Здесь я имею ввиду именно покупку продукта, а не внедрение и обслуживание. В этом все и проблемы. Всю работу делают никак не MS. (отдачи от них никакой) А в 1С платиш за продукт мало, и получаеш за это вменяемую и своевременную поддержку. Если раньше в Аксе работал по расчётам с клиентами, поставщиками, управление запасами и несколько незначительных ответвлений в Аксе. И 80% времени это была борьба с системой. Кто кого обхитрит. Щас тоже самое в 1С, но к этим же областям прибавил документооборот, планирование производства и pdm. И на борьбу с системой у меня уходит очень мало времени. Нет класов, нет витеиватых и слабоописанных или неописанных алгоритмов. Мозг не так загружен, поэтому есть ресурсы для работы с пользователями. И это с учётом того что в 1С мне ещё года два идти, до того уровня который у меня был в Аксапте. Это насчёт востребованности систем.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему. |
|
09.09.2011, 14:25 | #33 |
Участник
|
Цитата:
...Я бы даже сказал, демпинговой стоимости 1С. 1C демпингует? А теперь бесплатно! у SAP, OEBS и MBS цены на лицензии существенно завышены. Dynamics - разводилово на бабло? Цитата:
Цитата:
Ой, давайте не будем. Люди ж не только здесь сидят, но и на 1Совских ресурсах. Дальнейшее сравнение с 1С в этой ветке является оффтопиком. Если хотите продолжать, то создавайте новую ветку в разделе http://axforum.info/forums/forumdisplay.php?f=29 |
|
09.09.2011, 15:06 | #34 |
Участник
|
Потому что эти выводы становятся всё более явными?
Ну ты просто слово никуда заменил синонимом. Цитата:
Зафлудят, затролят .. любую тему. Цитата:
Сообщение от mazzy
Дальнейшее сравнение с 1С в этой ветке является оффтопиком.
Если хотите продолжать, то создавайте новую ветку в разделе http://axforum.info/forums/forumdisplay.php?f=29 Просто причитав что Георгий пишет, увидел нотки безнадёги. И как будто виноваты в этой шляпе транзакционные системы. Считаю что это не так. Щас не буду искать, но и раньше много писал что МS - жлобы и т.д, т.п. Что абсолютно им пофиг и на конечных пользователей и на внедренцев, как минимум из раши. Занимаются .. знает чем. Может подковёрными играми очень увлеклись. Но ни как не делом. Дела не видно. И это будет всё более явным с годами.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему. |
|
09.09.2011, 17:29 | #35 |
Moderator
|
Справедливости ради, хочу заметить что обсуждаемая проблема не связана только с Микрософт. Это проблема внедрения и продажи любых сложеых систем. И вполне справедливый гнев по поводу Микрософт правильнее изливать в других темах. Вот на выходных доберусь надолго до компа, и напишу что я по сути проблемы думаю
|
|
09.09.2011, 18:37 | #36 |
Участник
|
эти "выводы"?!!! да вы внутри не читали.
по-моему, ничего не меняется на рынке вот уже несколько лет. Цитата:
Сообщение от miklenew
Щас не буду искать, но и раньше много писал что МS - жлобы и т.д, т.п.
Что абсолютно им пофиг и на конечных пользователей и на внедренцев, как минимум из раши. Занимаются .. знает чем. Может подковёрными играми очень увлеклись. Но ни как не делом. Дела не видно. И это будет всё более явным с годами. вай, не хочу эту бодягу по новой. ведь все аргументы уже проговаривались. просто перечитайте |
|
09.09.2011, 22:17 | #37 |
Участник
|
Коллеги!
Вы все-таки прочитайте книгу "Психбольница в руках пациентов". Уверен, что поймете истинную причину ваших претензий к вендору, коллегам и себе. С уважением, Александр Дублин. P.S. Для тех, кто любит халяву сообщаю, что в инете можно скачать бесплатно. |
|
10.09.2011, 03:04 | #38 |
Участник
|
Да, читали-читали.
Что сказать то хотите? |
|
10.09.2011, 09:24 | #39 |
Участник
|
По моему мнению в посте ведется обсуждение нежелательных явлений (проблем следствий), а не причин проблем.
Считаю, что причинам проблем являются: 1) Отсутствие проектирования процессов взаимодействия пользователя с ERP системой. 2) Отсутствие измеримых целей внедрения (туманный scope проекта). С уважением, Александр Дублин. |
|
10.09.2011, 11:45 | #40 |
Участник
|
Проектирование процесса взаимодействия ERP и пользователя
Цитата:
А вот про проектирование процесса взаимодействия пользователей с ERP может быть ветку отдельную сделать. Я что то не знаю каких то специальных методологий. Стандартные нотации бизнес-процессов сюда не подходят. Ну и важно не только как нарисовать но и как проектировать. Я лично применяю, то что называется "принципами мягкого системного мышления". Кто еще что использует - отпишитесь плиз... |
|