Организация эффективного процесса внедрения на проектах промышленного масштаба

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

(1) Тупейший холивар, если-бы легко и просто было-бы "всех нагнуть, а кто не хочет, может идти искать себе работу", тогда везде еще dos и foxpro(клиппер) стоял бы.

(0) по Тест-центр, овчинка выделки не стоит. Никаких метрик не собирается, ни по железу, ни по 1с. Вроде тест есть, а понять в относительных величинах "при увеличении пользователей на 20% насколько у нас будет простаивать железо или увеличится среднее ожидание на транзакции" ответа получить не возможно, или например "сейчас в день 1000 документов, при увеличении до 2000 на что необходимо обратить внимание на железо и конфгурацию?" и т.д. Конечно, может у меня были большие ожидания от тест-центра, но вот анализ и сравнение показателей я там не увидел, поиск корреляций, даже простейшие метрики "средняя длина транзакции", количество ошибок, количество отмененных транзакций и т.д. я не увидел.

(3) pumbaE,
Метрика есть - как в мультиках про богатырей - "Упал"/"Не упал" )

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

Автор, отличный материал! А можно выложить схему управления инцидентами в лучшем качестве? Или статейку, по личному опыту на эту тему, а то эти все itil и pmbook вяло в практику серых будней вливаются, особенно на малых проектах. Интересует не описание хелпдеска, а скорее принципы, фундамент, на котором он строится.
Спасибо.

(0) Со многими пунктами согласен, но есть вопросы.

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

Все знают, что в свежих релизах платформы огромное количество багов. Есть ли опыт реальной разработки конфигураций с использованием БСП, как много ошибок встречается там? Вы правили их сами или через разработчиков из 1С?

Ничего не понятно в статье. Как-то сумбурно. Одно вот заинтересовало. Пишите С вторым, да, согласен. Особенно когда работать в штате с целью наработки опыта внедрения. А вот с первым удивлен. Там же денег куры не клюют?

Статья интересная -спасибо.
Но есть немного рекламы DB2. Если можно уберите ее))

(2) pumbaE, именно. Оно бы так и было, если б 1С не пропихнула свой стандарт сдачи отчётности в качестве государственно принятого и единственно возможного. Видел десятки организаций, вынужденных работать в 1С только из-за этого.

(5) bondar_vy@mail.ru, вы, вероятно, не поняли. Я не призываю к внедрению кривого-ушатанного продукта, я указываю на вероятность успеха и основные факторы. Адекватный адм.ресурс - это сферический конь в вакууме. Как максимум можно рассчитывать на дядю, который поинтересуется финальным "работает-не работает", или случайно оказавшегося "во власти" собрата-айтишника. Далее адекватность кончается. Можно сделать супер-продукт и убиться об стену, пытаясь сделать так, чтобы он использовался, даже при адекватном начальстве; это я вам как руководитель множества проектов говорю. Есть итальянская забастовка и прочие способы тихого саботажа, потому что " ну мне так привычнее" и "я этой вашей 1С не доверяю, я лучше параллельно в эксельчике буду всё вести". И повторяю, это никак не связано с качеством "вашей 1С".

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

Ковбойская пословица: "и один человек может привести лошадь на водопой, но даже десятеро не заставят её пить".

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