Есть два варианта:
1. Сначала поставить стандартный функционал, научить на нем работать. Затем собрать с пользователей пожелания и сделать их в системе.
2. Собрать с пользователей хотелки. Долго и нудно переписывать функционал, чтобы хоть что-то заработало. 5 раз переписывать. 10 раз пытаться сдать.

Плюсы первого пути: клиент практически сразу же получает работающую систему, дописки превращаются в рихтовку существующего функционала, редко больше. Минусы: клиент получает не совсем то что нужно сначала, а только через некоторое время.

Плюсы второго пути: в результате невероятного стечения обстоятельств клиент сразу же получает то что нужно. Минусы: система долго не выходит на нормальный уровень эксплуатации, большие шансы неудачного завершения проекта.

По первому вариант работающих встречал оооочень мало людей/фирм. По второму сплошь и рядом. Тут тебе и 1с-неги, и САПовцы, и Навижнцы с Аксаптовцами.
Но первый путь имхо удачней/проще/дешевле/быстрее.
Так почему выбираются неоптимальные технологии внедрения, а?

gybsonОткрою один секрет. ИТ индустрия не первая, кто сталкивается с внедрением. Есть, например, целый класс специализированных автомобилей. Я что-то не слышал, чтобы машины скорой помощи или пожарных, делали изначально для них. А ведь у них оооооооооооочень специфичная дятельность. С другой стороны есть собранные вручную "Бентли".
Условия совершенно другие. Там есть материальный продукт, у нас нет. У нас только неосязаемая как правило выгода. А это надо уметь продавать.

anjeyа что такое "стандартный функционал" ? если даже на оформление такого документа как Платёжное поручение чуть ли не у каждого своя "точка зрения" :)
В чем своя точка зрения? Эта тема достаточно зарегулирована, чтобы не иметь своей точки зрения.
По большей части вся финансовая часть зарегулирована настолько, что выдумывать там что новое просто сложно. Скорей убрать избыточность предлагаемого решения.

Shuhardне пробовали хоть раз утвердить ТЗ и кодить по техпроекту ?
Пробовали. Не раз. Но реально в подавляющем большинстве случаев ТЗ нужно только для того, чтобы прикрыться от наездов заказчика. Если есть ТЗ вовсе не факт, что заказчик получит то что ему нужно для работы.

Так_забежал_просто1. Что такое стандартный функционал?
То что разработано в системе до момента первого представления ее заказчику.

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

Так_забежал_просто3. Куда при таком подходе девается существующая информационная система (а она почти всегда есть, в том или ином виде)? Если существующую систему зашатдаунить и поставить "стандартный функционал", как это скажется на эффективности работы в переходный период? И на сколько конкретно времени этот переходный период затянется?
Работа будет продолжаться. По минимуму это движение денсредств, учет материалов, ОС, товаров.
Смотря что есть в существующей системе. Иногда ее проще выкинуть. Иногда сделать обмен данными с ней. По ситуации.
Считаю, что переходный период сокращается. то есть заказчик начинает работать в системе практически сразу с момента инсталляции.

Так_забежал_простоПо второму пути также есть свои вопросы.
Основное: Вы уверены, что пользователи в полной мере осознают свои "хотелки", не начав даже работать с системой?
Количество таких заказчиков стремиться к нулю.

Так_забежал_простоЧитали классиков про Scrum и eXtreme Programming? Там довольно много интересных вещей на эту тему написано...
Федор Михайлович и Лев Николаевич на эти темы к сожалению не писали
Да,кое-что читал. Может не совсем то же что и вы. Если есть интерсный материал по данной теме с удовольствием воспользуюст вашей рекомендацией.

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

LSVСледует заметить, что п.1: "Затем собрать с пользователей пожелания и сделать их в системе" плавно переходит в п.2., что уменьшает преимущества п.1 перед п.2.
Не совсем так. В этом случае заказчик уже работает в системе, более или менее ознакомлен с функционалом. Таким образом есть шанс сократить количество доработок в системе.

LSVНедостатком п.1 есть и то, что существует опасность, что обещания "доработать напильником" могут остаться обещаниями. В итоге будет стоять недоделанная система, кот. в итоге будет выкинута при любом удобном случае.
Недостатком п.2 является большая вероятность не запустить систему вообще.

PartyZaNУважаемый, а с какими из перечисленных систем Вам приходилось работать? Из них, по моему мнению, только с 1Сом можно действовать по первому варианту. Остальные системы сходу требуют или серьезной настройки (с проведением тщательного обследования и выбора варианта настройки) или большого объема кастомизаций (с аналогичным проведением обследования). Так что первый вариант подходит далеко не для всех систем.
БЭСТ, 1С, Навижн. Не работал. Тем или иным образом участвовал во внедрениях.
С БЭСТом так можно работать. А вот если можно так с 1С почему подавляющее большинство франчей не используют такой метод? Что-то тут не так. Я лично знаю только одних таких, кто такой метод внедрения официально представляет заказчику. Многие прочие начинают сразу со сметы расходов на доработку. И не пытаются внедрить типовых конфигураций. Возможно из-за того, что не могут освоить типовой функционал, а может еще из-за чего?
А обследование необходимо в любом случае. По результатам я еще могу и отказаться вообще что-либо внедрять у заказчика по любому методу.

andbary1 вариант - заставить людей работать на "чужой системе" в множестве случаев приведет к существенному падению производительности, так что называть его эффективным немного странно...
Она "чужая" система для сотрудников заказчика в любом случае. Не будем же мы менять Аксапту на Аксапту, или БЭСТ на БЭСТ.

andbary2. Слово "Хотелки" немного странно слышать от специалиста. Без составления серьезного ТЗ, действительно придется долго и нудно кодить с непонятным результатом...
Да, очень часто это именно "хотелки" не имеющие никакой связи с реальной необходимостью для работы организации. Про ТЗ, еще раз повторюсь, это чаще способ прикрыть задницу перед заказчиком.
Вы ж согласитесь, что в ТЗ всего не пропишешь?

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

gybsonВнедрение надо начинать с продукта. Если продукт целиком не удовлетворяет требованиям, то разрабатывается новый модуль и внедряется уже он, это уже другое внедрение. Само по себе внедрение незаконченного продукта - нонсенс.
Я думал что все начинается с обследования (реинжиниринг БП) . А потом уже выбор продукта. У нас правда сплошь и рядом не так, но, надеюсь мы когда-нибудь дойдем до цивилизованной жизни.

Любой продукт никогда не будет закончен, но тем не менее внедрения происходят повсеместно. Просто есть функционал необходимый для работы, а есть дополнительный, который подают как "конкурентное" преимущество.

guest_20040621DmitryOrlov, 99% внедрений - это технологически устаревший кривой софт. Если бы существовал и был бы востребован независимый консалтинг, имело бы смысл говорить о моделях внедрения.
Вы скажите это разработчикам 1с, сап, навика, бэста. Мне кажется они вас будут кушать за это. Каждый заявляет, что у них современные технологии и т.д.
guest_20040621Подавляющее большинство разработчиков/внедренцев в принципе не обладают необходимой для разработки/внедрения квалификацией. О заказчиках и говорить нечего - если не поголовные дебилы, то очень близко к этому.

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

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

Так_забежал_простоЕсли же взять компании, для которых финансовая деятельность является профильной, то тут опять имеем любопытное наблюдение. Дойче Банк в форуме Работа всё ищет и ищет джава-девелоперов... Стали бы они их искать, если бы всё было так уж прям стандартно? Сомневаюсь...
Нефиг было систему на java делать.