05.03.2015, 09:21 | #21 |
NavAx
|
Вот здесь, по моему, кроется недопонимание. Процесс настройки воспринимается как что-то простое, а программирование как что-то сложное. Но, на самом деле, это практически одно и тоже. Я бы даже сказал, программировать проще, т.к. инструментов гораздо больше имеется.
__________________
Isn't it nice when things just work? |
|
05.03.2015, 09:45 | #22 |
Модератор
|
Поэтому Axapta вплоть до 4,0 была самая жизнеспособная. Быстрее было что-то написать свое, чем ставить кучу галочек, которую программировали... ну, в общем, не всегда в единой логике системы. Да, огромный минус - система становилась трудноотчуждаемой самопиской, поддержка которой завязана на определенную команду, о переходах на новые версии зачастую можно было забыть, но скорость внесения изменений под новые требования бизнеса зачастую превышала вышеуказанные риски. А когда система морально устаревала - то требования к новой системе уже были сформированы: вот что есть, докажите что будет лучшее, удобнее и быстрее. Да, у нас не все хорошо, много чего криво, предложите как лучше. Но есть с чем сравнивать - с оттюнинговоной системой под текущие и, главное, быстроизменяющиеся требования бизнеса.
С Уважением, Георгий |
|
05.03.2015, 10:01 | #23 |
Участник
|
Точно так же бывает и с переходом с 1с на аксапту. все есть все работает, но что-то чуток не устраивает и начинается канитель перехода, и хотят чтобы было как в 1с, но чтоб называлась аксапта, в итоге "страдают" все
|
|
|
За это сообщение автора поблагодарили: macklakov (1). |
05.03.2015, 10:07 | #24 |
NavAx
|
Цитата:
Мне почему-то кажется что даже в уникальных российских условиях это реалистично за пару месяцев сделать. И конечно же это все должно сопровождаться нормальной проектной документацией, планированием, дизайнами и т.д. Как обычно. Следующим шагом привинчиваются ячеечное хранение ИЛИ закупки/продажи ИЛИ ОС. Опять все оформляется честь по чести, как полноценный проект. Каждый из таких мини-проектов разбит на несколько более коротких этапов. В конце каждого релиз оттестированного кода и настроек, демонстрация и планирование следующего этапа совместно с заказчиком. При этом риски ограничиваются 2-мя месяцами. Пользователи очень рано попадают в систему и начинают жаловаться, а значит всякие шероховатости исправляются на самом раннем этапе. По мере того как одни отделы привыкают к системе, входить в другие отделы становится все легче. Можно делать шаг назад и доводить до ума уже внедренный функционал, прежде чем автоматизировать следующий отдел. Нет эфекта шока, возникающего при waterfall запуске, когда несколько отделов одновременно начинают вижжать как резанные и просто физически невозможно мгновенно привлечь столько ресурсов, чтобы закрыть все эти дыры. Но есть и проблемы в этом подходе. 1. Усилия по выбиванию бюджета на внедреж часто не зависят от размера бюджета. Т.е. для клиента пробивать много мини-проектов гораздо тяжелее, чем один грандиозный. 2. Сейлам такая схема обычно не очень интересна. 3. Это противоречит привычной бизнес-схеме консалтинга. Есть риск что клиент довольно быстро обнаружит что система уже автоматизировала самые важные вещи, а ГК и зарплатна не нужны вовсе, т.к. есть выгрузка в 1С. 4. Как упоминул fed, бывает псевдо-agile, когда просто разработка разбита на короткие этапы, а реально пользователей пускают в систему через год-два. Это гораздо хуже чем обычный waterfall, т.к. риски те же, а ответственного не найти.
__________________
Isn't it nice when things just work? Последний раз редактировалось macklakov; 05.03.2015 в 10:10. |
|
|
За это сообщение автора поблагодарили: kALVINS (4). |
05.03.2015, 10:27 | #25 |
Участник
|
Вы реально видели клиента, который заплатит за работающий складской журнал?
Ну и в целом. Есть некое суждение, что водопад не предполагает раннее ознакомление пользователя с системой. Это не так. На этапе анализа и дизайна (системное проектирование по ГОСТ) самое то показывать стандартную систему и фиксировать расхождения (fitgap). Чем ближе стандарт или решение к требованиям заказчика, тем это проще. И, как правило, настройка такого демо-примера по большинству процессов - это пара недель, а не пара месяцев только на журнал. Дальше никто не запрещает при проработке детального дизайна (Техническое проектирование) работать рука об руку с пользователем. Отлично, если по каждому настроенному / доработанному блоку пользователь будет предварительную "приемку" на этапе разработки (реализации АС). В итоге к финальному обучению ключевых и приемке системы пользователи уже все знают и все умеют. Но это же надо стараться не только консалтеру, но и клиенту. А о чем говорить, если список ключевых мы зачастую получаем к обучению? И люди все новые, которые и глазом не видели Аксу? Кто-то скажет, что клиент не умеет, а консалтер должен сказать "как надо". Сказать то он может, но при наличии на рынке демпинговых компаний, которые подписываются на фикс с трудоемкостью в два раза ниже и просто не закладывающие такие работы в проект, при этом под гарантии запуска? Клиент же не понимает, хочет дешевле (всегда можно дешевле (С)!!!). Вот и лавируешь между всем этим.
__________________
Ivanhoe as is.. |
|
05.03.2015, 10:57 | #26 |
NavAx
|
Цитата:
Цитата:
Да, журнал это фигня и несерьезно. Но когда кладовщики через этот журнал уже принимают, отгружают и инвентаризацию проводят, это несколько больше чем когда они смотрят как ты делаешь проводки на демо-данных и придумывают каверзные вопросы. Пару месяцев я назвал чтобы уж заведомо уложиться можно было. От первого посещения консультантов до момента когда кладовщики проводят все через систему.
__________________
Isn't it nice when things just work? Последний раз редактировалось macklakov; 05.03.2015 в 11:01. |
|
05.03.2015, 11:10 | #27 |
Участник
|
А остальные процессы где? Если склад ведет журналы, то нужно делать кучку временных интеграций? И вот за это еще меньше кто заплатить готов.
Agile хорошо для небольших коробок, для точечных задач. В ERP сейчас, как правило, основные проблемы организационные, а не в софте (что решает Agile). Поменять бизнес-процессы, "сделать не хуже, чем было" по ключевым участкам и т.п. И если в начале 2000х, как правило, была одна-две интеграции, то сейчас уже 4-7.
__________________
Ivanhoe as is.. |
|
05.03.2015, 11:22 | #28 |
NavAx
|
Цитата:
И будет внедрено только то, что реально нужно. Т.к. на каждом этапе будет пересмотр самых приоритетных направлений. И сабботировать такой внедреж гораздо тяжелее, т.к. отделы не могут сплотиться, каждый раз нагибают точечно, конкретный отдел.
__________________
Isn't it nice when things just work? |
|
05.03.2015, 11:39 | #29 |
Модератор
|
+ за Agile. Кстати, JD Edwards внедрялась именно по данной методологии. Да и у Oracle была подобная методология - Oracle AIF (application implementation framework), она была ближе к Agile чем к "классическому" подходу. Но, кстати, лет 5 назад развитие AIF приостановилось. Очень зря, на мой взгляд. Но я бы не стал отдавать предпочтение той или иной прадигме - я бы использовал смесь. Продавал бы большой проект, по "классической". А часть процессов бы внедрял по Agile, либо приучал к нему команду клиента для "точной" доводки. Да, те же формочки, отчета, автозаполнение... мелочь, а времени проектного сжигает - массу. А концентрировался бы на глобальных вопросах и архитектуре.
С Уважением, Георгий |
|
05.03.2015, 11:43 | #30 |
Участник
|
Так на проектах так и происходит с первого января начинаются спринты на рабочей по исправлению замечаний
Коллеги, кто-то реальным опытом может поделиться? Чтобы внешний консалтинг сделал в РФ проект по Agile? А то теории одни.
__________________
Ivanhoe as is.. |
|
05.03.2015, 11:48 | #31 |
Модератор
|
Иван, привет. Хорошее замечание, мы практиковали подобный подход на внутреннем проекте. Правда, не знали что он так называется . Вопрос, целесообразно ли его использовать для внешнего консалтинга? На уровне продажи проекта - я бы не решился. На уровне проекта - тоже вопрос, т.к. может ресурсов отожрать много, но для клиента будет система, близкая к его ожиданиям. Вопрос, надо ли консалтингу, который продал проект по фиксированной цене, настолько детально удовлетворять запросы пользователей. Зачастую главное - это запустить основу, а потом тихонько вылизывать систему. Иначе будет как Денис описал. Пуговицы - пришиты насмерть, не оторвешь.
С Уважением, Георгий |
|
05.03.2015, 12:13 | #32 |
Участник
|
Привет
Про внутренний уже писали выше, там деньги обычно не так считают. Тут вопросов нет.
__________________
Ivanhoe as is.. |
|
05.03.2015, 12:23 | #33 |
Moderator
|
Проблема в том, что быстро (типа месяца за 3-4) слепить реально работающий прототип можно только для простых инсталляций - типа торговли без больших складских площадей, сложной закупочной логистики, без производства. Но учитывая рост цен на аксапту и подтягивание функцонала 1C до уровня такой фирмы, скорее всего такой клиент просто купит продвинутую конфигурацию 1С.
|
|
|
За это сообщение автора поблагодарили: mazzy (2), macklakov (1). |
05.03.2015, 12:51 | #34 |
Модератор
|
А ее что, настраивать не надо? Вопрос методологии в данном случае не сильно зависит от внедряемой платформы, которую можно быстро доработать - ДАКс или 1С.
С Уважением, Георгий |
|
05.03.2015, 13:01 | #35 |
Участник
|
1C ERP 2.0, если убрать за скобки ошибки и недоделки, то настраивается в разы проще. Плюс практически не надо париться про БУ/НУ - оно просто "раз" и работает. Документации много и на русском (обучение и инструкции можно снизить в разы). Так что вполне реально где-то и за 3-4 месяца сделать. Впрочем, и Аксу так внедряли несколько раз, когда клиент хотел именно коробочное решение.
__________________
Ivanhoe as is.. |
|
05.03.2015, 13:21 | #36 |
Участник
|
Время идет, а проблемы остаются? На одном проекте.
|
|
|
За это сообщение автора поблагодарили: George Nordic (1). |
05.03.2015, 13:25 | #37 |
Участник
|
Цитата:
Сообщение от Lucky13
Время идет, а проблемы остаются? На одном проекте.
Последний раз редактировалось ice; 05.03.2015 в 13:28. |
|
05.03.2015, 14:09 | #38 |
Участник
|
Похоже. Но тему надо бы сохранить - прикрепить к старой?
__________________
Ivanhoe as is.. |
|
05.03.2015, 17:00 | #39 |
Участник
|
|
|
05.03.2015, 17:03 | #40 |
Модератор
|
Lucky13 и ice абсолютно правы: это бот. Который возродил очень интересную дискуссию. Темы объединил, дал более осмысленный заголовок. Бот забанен.
С Уважением, Георгий |
|
Теги |
agile, scrum |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|