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

[ice]

Когда нет проблемы денег, например, внутренняя команда внедрения, то гибкие методологии вполне себе работают, но качество от этого слабо зависит, можно бесконечное количество раз переделывать переделки

[R.Safianov]

Цитата:

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

Оформили список дополнительных функциональных требований.
Отдали пользователям на проверку и утверждение, а они заявили: "Мы читать не любим. Вы сначала сделайте, а мы потом посмотрим и скажем ответ."

Смешно?

Заказчик смеется? И правильно делает.

Пошло бы легче, если бы вы:
1) Состряпали список процессов и их шаги.
2) Разобрать отчетность, которую планируется получать из системы.
3) Показать как процесс отражается в системе.
4) Показать места плановых модификаций и показать зачем они нужны.
5) Собрать от них требования по расхождениям. С поименными источниками требований.
6) Запустить процедуру утверждения требований. На этом шаге все будут биться за реализацию именно своих требований. А от каких-то есть шанс избавится навсегда.

Как правило требования собранные таким подходом позволяют перевести процесс из творческой в рабочую плоскость. Но этот подход требует от консультантов демонстрировать очень высокие знания системы.

[fed]

Цитата:

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

Заказчик смеется? И правильно делает.

Пошло бы легче, если бы вы:
1) Состряпали список процессов и их шаги.
2) Разобрать отчетность, которую планируется получать из системы.
3) Показать как процесс отражается в системе.
4) Показать места плановых модификаций и показать зачем они нужны.
5) Собрать от них требования по расхождениям. С поименными источниками требований.
6) Запустить процедуру утверждения требований. На этом шаге все будут биться за реализацию именно своих требований. А от каких-то есть шанс избавится навсегда.

Как правило требования собранные таким подходом позволяют перевести процесс из творческой в рабочую плоскость. Но этот подход требует от консультантов демонстрировать очень высокие знания системы.

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

[R.Safianov]

Цитата:

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

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

Я бы сказал так. Заказчик хочет:
1) Купить систему, заплатив за нее один раз понятных денег.
2) Иметь систему, которую можно легко настроить, как угодно. Мы же не знаем сейчас процессов.
3) В процессе выявления процессов система должна становится еще быстрее. Мы ведь конкретизируем чего хотим.
4) Система должна уметь сама дополнять данные задним числом. Типа добавили разрез и все данные поменялись. Вах!!!
5) И если вот нам совсем захочется какой-то экзотики, то внедренец должен подорваться и совсем за маленькие деньги сделать такую уникальную штуку (как вообще мир до сих пор может жить без такой штуки. Вообще-то за клевую идею внедренец должен доплатить).

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

[macklakov]

Цитата:

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

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

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

[George Nordic]

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

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

[ice]

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

[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

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

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