Зарегистрироваться | Поиск |
Результаты опроса: Scrum, Agile это хорошая штука? | |||
А что это вообще такое? |
![]() ![]() ![]() ![]() |
6 | 33.33% |
хорошая |
![]() ![]() ![]() ![]() |
10 | 55.56% |
плохая |
![]() ![]() ![]() ![]() |
0 | 0% |
не для Microsoft Dynamics |
![]() ![]() ![]() ![]() |
2 | 11.11% |
Голосовавшие: 18. Вы ещё не голосовали в этом опросе |
|
Опции темы |
|
![]() |
#1 |
Участник
|
Поддержу. В опросе стоило бы явно прописать MS CRM, а не весь Dynamics.
__________________
Ivanhoe as is.. |
|
![]() |
#2 |
Участник
|
Цитата:
Сообщение от fed
![]() Я все-таки слегка добавлю насчет методологии. Хотя MS и оперирует понятием "Microsoft Dynamics", CRM и Ax - это принципиально разные по методологии внедрения продукты. CRM - по большому счету - инструмент разработки самописок. Ну то есть - да - конечно если в комманде есть опытный консультант по организации процесса продаж (я таких не видел в природе, правда. Только слышал через общих знакомых), то шансы на успешное внедрение увеличиваются. Если такого консультанта нету - ну будет еще одна самописка, только не на голом C# написаная с ноля, а на CRM. В худшем случае, клиент спустя пару лет осознает что он заплатил за софт N килобаксов и за внедрение 10*N килобаксов. Соответственно - вероятно проще было вообще с нуля писать чем CRM покупать.
Но вот в случае Аксапты, все таки нормально сделанный проект - это проект консалтинговый. А чтобы такой проект сделать, надо на предприятие придти, изучить как оно работает, какие проблемы видят стейкхолдеры, каких проблем они не видят, чего они хотят, чего им на самом деле надо, и тп. И только после этого можно как-то планировать разработку и реализацию. Если же применить модель прототипирования, то неизбежно дело кончиться провалом (много раз такое видел). На каждом цикле конкретные юзеры просят какие-то полезные лично для них формочки или мелкие отчетики, а в результате, к моменту когда дело доходит до планирования, финансовой отчетности, бюджетирования или себестоимости той же (то есть - не некоторым примитивным процессам ввода простейших данных, а к тем самым сложным и комплексным процессам, ради которых MRP и внедряется), оказывается что на ранних циклах забыли запрограммировать и настроить ввод половины необходимой информации. А даже та информация которая есть - она отструктурирована для удобства низовых пользоветелей, а не для удобства тех кто потом этой информацией пользуется в стратегических процессах. (типичный пример - вместо использования проводок по ГК и модульных проводок для финансового учета, по просьбе низовых финансистов вколбасили дополнительную табличку - как в Excel было. Данные из таблички удалять легко, но с встроенной отчетностью она ни разу не интегрирована). В итоге - на поздних стадиях проекта большая часть усилий сводиться к тому чтобы как-то интегрировать то что налажали по просьбе пользователей с тем что на самом деле необходимо топам и акционерам. В итоге проект как-то работает, но чтобы его поддерживать хоть как-то, заказчику приходиться по одному программисту на 10 пользователей держать... для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте. так что ERP подкоряется потихоньку под Agile тоже )) мир динамичен. подходы меняются. |
|
![]() |
#3 |
Moderator
|
Цитата:
Сообщение от Daniil
![]() вот тут конечно есть зерно истины, но...
для справки: SAP уже разработали и внедрили в свой продукт модуль ASAP для управления проектом внедрения своей системы. это не СКРАМ в чистом виде, но что-то типа Agile в своем варианте. так что ERP подкоряется потихоньку под Agile тоже )) мир динамичен. подходы меняются. |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
![]() |
#4 |
Участник
|
Цитата:
Сообщение от fed
![]() Для справки - ASAP основан на идее, что вместо того чтобы делать детальное исследование бизнес-процессов до внедрения и дизайн процессов после внедрения, мы просто берем некие типовые бизнес-процессы и настраиваем систему под них (не запариваясь о том что у заказчика сейчас и как он будет менять свой бизнес под новые бизнес-процессы). Я не буду обсуждать этот подход в деталях (коротко говоря - это такой большевизм от внедрения). Могу только сказать что НИ МАЛЕЙШЕГО отношения к Agile этот подход не имеет. Вполне себе классический водопад, просто из него убрали стадию изучения реального заказчика и заменили на библиотеку сферических заказчиков в вакууме..
![]() это я впечатлился примером одного успешного крупного проекта по SAP-там использовали многие принципы Agile. и заодно говорили про ASAP. вот я и прикрутил его втихаря )). тем не менее, в этом проекте во всю использовали некоторые принципы SCRUM: команда, один Product owner, спринты+релиз план. даже еще прикольнее: они управляли одновременно несколькими проектами ASAP при помощи спринтов, составляя релиз-план (хотя я не знаю, возможно в ASAP положено и так использовать спринты, но тем не менее - это одна из фишек SCRUM). Последний раз редактировалось Daniil; 12.12.2013 в 15:09. |
|