Какая методология лучше в случае "Сначала сделайте, а мы посмотрим"

[macklakov]

Цитата:

Сообщение от R.Safianov

2) Иметь систему, которую можно легко настроить, как угодно. Мы же не знаем сейчас процессов.

Вот здесь, по моему, кроется недопонимание. Процесс настройки воспринимается как что-то простое, а программирование как что-то сложное. Но, на самом деле, это практически одно и тоже. Я бы даже сказал, программировать проще, т.к. инструментов гораздо больше имеется.

[George Nordic]

Поэтому Axapta вплоть до 4,0 была самая жизнеспособная. Быстрее было что-то написать свое, чем ставить кучу галочек, которую программировали... ну, в общем, не всегда в единой логике системы. Да, огромный минус - система становилась трудноотчуждаемой самопиской, поддержка которой завязана на определенную команду, о переходах на новые версии зачастую можно было забыть, но скорость внесения изменений под новые требования бизнеса зачастую превышала вышеуказанные риски. А когда система морально устаревала - то требования к новой системе уже были сформированы: вот что есть, докажите что будет лучшее, удобнее и быстрее. Да, у нас не все хорошо, много чего криво, предложите как лучше. Но есть с чем сравнивать - с оттюнинговоной системой под текущие и, главное, быстроизменяющиеся требования бизнеса.

С Уважением,
Георгий

[ice]

Точно так же бывает и с переходом с 1с на аксапту. все есть все работает, но что-то чуток не устраивает и начинается канитель перехода, и хотят чтобы было как в 1с, но чтоб называлась аксапта, в итоге "страдают" все

[macklakov]

Цитата:

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

Agile - это хорошо, но не на практике в большом проекте ERP в России. На западе, при внедрении коробки (а это очень четкое понятие и со стороны внедренца и со стороны заказчика), это может быть хорошо и реально альтернатива классическому подходу.

Ну вот смотри как это работает. Сколько нужно времени, чтобы настроить склад без заморочки на правильную разноску в ГК, без ячеек, без сводного и т.д.? Просто через журналы. Пришло, ушло, в наличии.
Мне почему-то кажется что даже в уникальных российских условиях это реалистично за пару месяцев сделать. И конечно же это все должно сопровождаться нормальной проектной документацией, планированием, дизайнами и т.д. Как обычно.
Следующим шагом привинчиваются ячеечное хранение ИЛИ закупки/продажи ИЛИ ОС. Опять все оформляется честь по чести, как полноценный проект.
Каждый из таких мини-проектов разбит на несколько более коротких этапов. В конце каждого релиз оттестированного кода и настроек, демонстрация и планирование следующего этапа совместно с заказчиком.
При этом риски ограничиваются 2-мя месяцами. Пользователи очень рано попадают в систему и начинают жаловаться, а значит всякие шероховатости исправляются на самом раннем этапе. По мере того как одни отделы привыкают к системе, входить в другие отделы становится все легче. Можно делать шаг назад и доводить до ума уже внедренный функционал, прежде чем автоматизировать следующий отдел. Нет эфекта шока, возникающего при waterfall запуске, когда несколько отделов одновременно начинают вижжать как резанные и просто физически невозможно мгновенно привлечь столько ресурсов, чтобы закрыть все эти дыры.

Но есть и проблемы в этом подходе.
1. Усилия по выбиванию бюджета на внедреж часто не зависят от размера бюджета. Т.е. для клиента пробивать много мини-проектов гораздо тяжелее, чем один грандиозный.
2. Сейлам такая схема обычно не очень интересна.
3. Это противоречит привычной бизнес-схеме консалтинга. Есть риск что клиент довольно быстро обнаружит что система уже автоматизировала самые важные вещи, а ГК и зарплатна не нужны вовсе, т.к. есть выгрузка в 1С.
4. Как упоминул fed, бывает псевдо-agile, когда просто разработка разбита на короткие этапы, а реально пользователей пускают в систему через год-два. Это гораздо хуже чем обычный waterfall, т.к. риски те же, а ответственного не найти.

[Ivanhoe]

Вы реально видели клиента, который заплатит за работающий складской журнал?

Ну и в целом. Есть некое суждение, что водопад не предполагает раннее ознакомление пользователя с системой. Это не так.

На этапе анализа и дизайна (системное проектирование по ГОСТ) самое то показывать стандартную систему и фиксировать расхождения (fitgap). Чем ближе стандарт или решение к требованиям заказчика, тем это проще. И, как правило, настройка такого демо-примера по большинству процессов - это пара недель, а не пара месяцев только на журнал.

Дальше никто не запрещает при проработке детального дизайна (Техническое проектирование) работать рука об руку с пользователем. Отлично, если по каждому настроенному / доработанному блоку пользователь будет предварительную "приемку" на этапе разработки (реализации АС). В итоге к финальному обучению ключевых и приемке системы пользователи уже все знают и все умеют.

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

Кто-то скажет, что клиент не умеет, а консалтер должен сказать "как надо". Сказать то он может, но при наличии на рынке демпинговых компаний, которые подписываются на фикс с трудоемкостью в два раза ниже и просто не закладывающие такие работы в проект, при этом под гарантии запуска? Клиент же не понимает, хочет дешевле (всегда можно дешевле (С)!!!). Вот и лавируешь между всем этим.

[macklakov]

Цитата:

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

Вы реально видели клиента, который заплатит за работающий складской журнал?

Спонсор проекта часто вполне положительно к такому подходу относится. Только вот выбивать бюджет действительно сложно.

Цитата:

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

Есть некое суждение, что водопад не предполагает раннее ознакомление пользователя с системой. Это не так.

Вот здесь есть малозаметное но ключевое отличие. Если водопаде пользователи знакомятся с системой и может даже трогают ее, то в scrum они, так сказать, делят с ней ложе. На самом деле, scrum это множество микро-водопадов, по окончании каждого из которых предпологается реально работающая живая система.
Да, журнал это фигня и несерьезно. Но когда кладовщики через этот журнал уже принимают, отгружают и инвентаризацию проводят, это несколько больше чем когда они смотрят как ты делаешь проводки на демо-данных и придумывают каверзные вопросы.

Цитата:

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

И, как правило, настройка такого демо-примера по большинству процессов - это пара недель, а не пара месяцев только на журнал.

Пару месяцев я назвал чтобы уж заведомо уложиться можно было. От первого посещения консультантов до момента когда кладовщики проводят все через систему.

[Ivanhoe]

А остальные процессы где? Если склад ведет журналы, то нужно делать кучку временных интеграций? И вот за это еще меньше кто заплатить готов.

Agile хорошо для небольших коробок, для точечных задач. В ERP сейчас, как правило, основные проблемы организационные, а не в софте (что решает Agile). Поменять бизнес-процессы, "сделать не хуже, чем было" по ключевым участкам и т.п. И если в начале 2000х, как правило, была одна-две интеграции, то сейчас уже 4-7.

[macklakov]

Цитата:

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

А остальные процессы где? Если склад ведет журналы, то нужно делать кучку временных интеграций? И вот за это еще меньше кто заплатить готов.

Да, куча временных интеграций. Это издержки. Но это делает процесс управляемым и кардинально снижает риски. При таком подходе когда через год-два система выйдет на полноценный уровень, кладовщики в ней уже будут работать минимум год и их процессы уже будут вылизаны. И когда бухгалтерию тоже в систему загонят, их вопли не найдут отклика в сердцах других отделов, которые уже привыкли к системе и даже научились ее любить.
И будет внедрено только то, что реально нужно. Т.к. на каждом этапе будет пересмотр самых приоритетных направлений. И сабботировать такой внедреж гораздо тяжелее, т.к. отделы не могут сплотиться, каждый раз нагибают точечно, конкретный отдел.

[George Nordic]

+ за Agile. Кстати, JD Edwards внедрялась именно по данной методологии. Да и у Oracle была подобная методология - Oracle AIF (application implementation framework), она была ближе к Agile чем к "классическому" подходу. Но, кстати, лет 5 назад развитие AIF приостановилось. Очень зря, на мой взгляд. Но я бы не стал отдавать предпочтение той или иной прадигме - я бы использовал смесь. Продавал бы большой проект, по "классической". А часть процессов бы внедрял по Agile, либо приучал к нему команду клиента для "точной" доводки. Да, те же формочки, отчета, автозаполнение... мелочь, а времени проектного сжигает - массу. А концентрировался бы на глобальных вопросах и архитектуре.

С Уважением,
Георгий

[Ivanhoe]

Так на проектах так и происходит с первого января начинаются спринты на рабочей по исправлению замечаний

Коллеги, кто-то реальным опытом может поделиться? Чтобы внешний консалтинг сделал в РФ проект по Agile? А то теории одни.

[George Nordic]

Иван, привет. Хорошее замечание, мы практиковали подобный подход на внутреннем проекте. Правда, не знали что он так называется . Вопрос, целесообразно ли его использовать для внешнего консалтинга? На уровне продажи проекта - я бы не решился. На уровне проекта - тоже вопрос, т.к. может ресурсов отожрать много, но для клиента будет система, близкая к его ожиданиям. Вопрос, надо ли консалтингу, который продал проект по фиксированной цене, настолько детально удовлетворять запросы пользователей. Зачастую главное - это запустить основу, а потом тихонько вылизывать систему. Иначе будет как Денис описал. Пуговицы - пришиты насмерть, не оторвешь.

С Уважением,
Георгий

[Ivanhoe]

Привет
Про внутренний уже писали выше, там деньги обычно не так считают. Тут вопросов нет.

[fed]

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

[George Nordic]

А ее что, настраивать не надо? Вопрос методологии в данном случае не сильно зависит от внедряемой платформы, которую можно быстро доработать - ДАКс или 1С.

С Уважением,
Георгий

[Ivanhoe]

1C ERP 2.0, если убрать за скобки ошибки и недоделки, то настраивается в разы проще. Плюс практически не надо париться про БУ/НУ - оно просто "раз" и работает. Документации много и на русском (обучение и инструкции можно снизить в разы). Так что вполне реально где-то и за 3-4 месяца сделать. Впрочем, и Аксу так внедряли несколько раз, когда клиент хотел именно коробочное решение.

[Lucky13]

Время идет, а проблемы остаются? На одном проекте.

[ice]

Цитата:

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

Время идет, а проблемы остаются? На одном проекте.

может бот? т.к. все темы от пользователя разные, примерно в одно время и не участвует в дискуссии

[Ivanhoe]

Похоже. Но тему надо бы сохранить - прикрепить к старой?

[Lucky13]

Цитата:

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

может бот?

Интересно. А какая тогда цель у такого бота? Разве что увеличение количества сообщений на форуме. Тогда у него неплохо получается.

[George Nordic]

Lucky13 и ice абсолютно правы: это бот. Который возродил очень интересную дискуссию. Темы объединил, дал более осмысленный заголовок. Бот забанен.

С Уважением,
Георгий