Решил тут опрос провести, в преддверии череды запусков с 1-го числа:

Выделите 5 основных проблем при внедрении, если можно - коротко расшифруйте свою точку зрения.

Ну и мои 5 проблем
1. ОРганизационные- нет выделенного РП со стороны заказчика
2. ОРганизационные - нет выделенного времени ответственных за внедрение
3. Организационные- нет специалистов достаточной квалификации
4. Нет достаточного бюджета
5. Нет достаточного времени на решение задач.

По итогам сделаем голосовалку с перечнем проблем, чтобы выбрать топ 5 ;-)
Погнали

(39) и сколько ты лично сделал таких проектов?

(39) Хотя бы описать роли, зоны ответственности, риски и способы реакции на них, порядок разрешения конфликтов. Т.е. даже не содержательную часть проекта, а административную его часть. Содержательную можно "съесть по частям" потом.

Отсутствие документации в маленьких и крупных проектах - это ваши риски. Будете доказывать что не Буратино.

Мне хотели предъявить что отчет выводит не все данные через 2 года (их попросту неоткуда брать), работы там было на 20 часов. Заказчика сопровождали, послать лесом нельзя.

В итоге достали документацию, сели вместе и прошлись по всем пунктам, вопросов больше не было.

(29) Вперед, ничего не фиксируйте. За неделю до сдачи работ ответственный за проект сотрудник увольняется, а новый вам ничего не подпишет и не оплатит.

Анекдот про патроны уже рассказывали?

«-Почему вы проиграли сражение?
-О, тому была тысяча причин! Во‑первых, у нас кончились патроны…»

(40) Лично я хитрее поступаю и не берусь целиком сразу за проекты.
Только за конкретные задачи (мелкие частички проекта) которые и делаю последовательно, получая оплату за каждую решенную задачу.

(43) Есть такой риск, согласен. Но когда суммы не велики то можно пренебречь.
В дальнейшем этот клиент попадает в серый/черный список и новые работы только по факту приема/оплаты старых, не подписанных и не оплаченных.

(46)+ И предоплате новых работ ))

У Заказчика банально не выстроены процессы. Поэтому при внедрении все летит кувырком. Вместо внедреняи продукта приходится втискивать продукт в какую-то хрень, потому что НКПР получается. В результате связи рвутся или по тонкой жиле приходит мегаток и всех убивает.

(45) Если это какой-нибудь заводик человек на 200-250 (и соответственно рыл 45-55 в базе), то сложно "по частям" это сделать. Хотя бы базовый функционал нужно одномоментно запускать.

(49) И вот тут согласен что без документации ну никак. Т.е. вопрос документации не в сумме проекта, а в его сложности.

(16) на такой бюджет - заказчик не согласен. Он хочет кабриолет по цене жигулей.

(51) https://cs6.pikabu.ru/post_img/2015/07/17/9/1437144904_2078224630.jpeg

(50) Систему как правило заказывает Заказчик.
Как правило - в результате хотя бы написания ТП/ТЗ - сформулировано что должна уметь система и, иногда жаде - как это она должна делать. Сформулировано совместно Заказчиком и Исполнителем. Писать доку - по чём? Как работать с интерфейсом 1С? как настраивать удобный вид списков? и при необходимости выводить доколонки? - нахрена? Часьтности по документации интересны м.б. только техническим специалистам Заказчика. Никто покупая машину не получает инструкци. как она устроена и как внутри все работает - на какойм угле опережения стоят свечи или с какой скоростью и дозой идет впрыск. Описывается функциональная инструкция. Как работать, чтобы добиться ожидаемых результатов, а не как устроена система. Описать "функциональную инструкцию" - вполне в состоянии вменяемый Заказчик, с незначительной помощью Исполнителя по каким-то тонкостям/существенным моментам.
Если Заказчик вообще не присутствует в написании такой Инструкции, а ожидает/требует от Заказчика такую инструкцию - 95% что проект или сдохнет, или хреново запустится. Ибо Исполнителю нахрен ничего не надо.

Приходится писать инструкцию, млин, по "железячной" настройке ТСД! Бо ит-служба Заказчика этого блин не умеет/не хочет. "Долбоёбы" - правильно Джин сказал.

Или как можно написать инструкцию по использованию универсального инструмента типа "универсальны подбор и обработка объектов"...? вся инструкция уместится на листе А4 по существу. Нет, напишите для каждого конкретного случая!

(52) да! и сюда же в эту цену такого кабриолета хочется кондишен хайпремиум, сиденья из кожи из жопы дракона, итд - это же все в порядке вещей в кабриолете и должэно быть! это же кабриолет! но за 300 тыс! это ведь жикули!

(53) Тут немного иное, одно дело если внедряют типовую систему без доработок (как покупают автомобиль) и совсем другое когда доработки или некая своя система (доработка или новая разработка автомобиля).

И тут совершенно логично задокументировать что же мы дорабатываем/разрабатываем и через какое место.
Не юзермануал а именно документация на нашу уникальную ("как она устроена и как внутри все работает - на какойм угле опережения стоят свечи или с какой скоростью и дозой идет впрыск")

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

(0) так, описанные в рамках управления проектом решаются же))
но, выделю

И, стоило бы задать, в рамках какого типа проекта проблемы то.. если фикс-прайс одни проблемы, если  t&m-то другие

Опишу по фикс-прайсу:
1. ОРганизационные - нет лица, который может принять решение об изменении существующих процессов
2. изменение функциональных рамок по ходу проекта (если фикс прайс. для t&m не актуально)
3. Нет заинтересованности топ-менеджмента в итоговом результате, и топ-менеджмент готов удовлетворить все прихоти пользователей (норм при t&m, полный атас при фикс-прайс).

недостаточное финансирование не может быть проблемой проекта...

4. нет бюджета

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

(58) откуда появится проект, если нет бюджета?
(59) без функциональных рамок вообще заходит нельзя. а если есть функциональные рамки, то нужно все изменения контролировать, и хотелки\перделки отсекать.. вот здесь и сложность..
а вот с "то что надо становится более менее сно при разработке" - так с таким началом проекта при фикс прайс проект обречен..

и, любые личные связи (друзья, знакомые, сочтемся все свои, хорошие отношения0  на проекте нужно признавать порочащими, и в корне пресекать!!

(60) Функциональные рамки - вещь непростая. Если они расплывчаты - то каждая из сторон проекта трактует их по совему. Проблемы. если функциональные рамки - сильно детализировать - получается ТП. А стоимость разработки ТП - отдельные деньги... Замкнутый круг.

(60) "а вот с "то что надо становится более менее сно при разработке" - так с таким началом проекта при фикс прайс проект обречен.." - так в этом то и проблема. Ваяется уникальный продукт на основе некоего базового каркаса. Клиент хочет фиксированную цену до начала проекта. Фиксированная цена - на базовый каркас - который сам по себе не ездит... И начинается...

(59) "неясных функциональных границах проекта" // Предпроектное обследование - как отдельный проект - полностью закрывает этот вопрос

(62) если суметь договорится, что обсуждаем результат выполнения какой то функции, а не способ разработки баз и программирования - то круг не замкнутый..
функция "резервирование товаров" - вот его и проверяем (резервируется ли по сериям\срокам годности, если резервирование под заказ и тд), а не где какую и когда нажимать кнопочку, чтобы зарезервировать товар.

(64) Предпроектное обследование - это по сути будет ТП. Стоит достаточно серьезных денег. Простое предпроектное исследование - дает весьма размытые трактовки для разных строн.

(66) достаточно серьезные - это сколько?

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

(0) Нет попила- нет внедрения.

(69) хм.. я не делюсь..

хотя. не.. всякие бывают0)

(68) "как" - и составляет всю особенность проекта. от входа до выхода - разные дороги ведут. собственно решение о том "как" - и составляет сущность ТП. Приемка товара - она и есть приемка товара. А вот как именно и что делать во время приемки и надо ли это делать вообще - собственно реализация таких "хотелок" и составляет предмет "бодания", а если все эти хотелки не описать в ТП - Заказчик говорит "ну это же само собой разумеется, это должно быть/это типа стандарт" - стандарт машины - это четыре колеса + мотор+кузов. однако есть машины за лям. а есть за 10 лямов. хотя и те и те служат для езды.

(70) а зачем с тобой делиться, если ты не хозяин? С кем надо делятся.

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

Думаю успех проекта в равной степени зависит от трех факторов:
- адекватность команды Заказчика
- адекватность команды Исполнителя
- соответствие Продукта целям проекта

Исполнитель должен оценить п.1 до подписания договора. С неготовым к внедрению Заказчиком лучше не связываться.
Но в жизни зачастую команда Исполнителя ставится перед фактом условий уже заключенного договора.

(75) Ну и собственно выяснения какая реальная цель проекта. Декларировать можно одно, а добиваться выполнения совсем другого.

А никто не работает с запросами на изменение чтоли? Что-то все уперлись в фискированные рамки проекта, фиксированные тз и так далее

мимо дилетант

(0) "Вася" уволился и бизнесу писец ))))

(77) Клиент хочет результат. А не процесс. Хотя как раз надо делать по процессу, в условиях нечетких требований. Но тогда фиксировать либо время, либо бюджет. Клиент опасается, что в итоге не получит того что ожидает, хотя из того что он заявляет - дохрена ему нафиг не надо, и они и представляют сложность основную, которую можно было бы допиливать вне рамок проекта.

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

Поэтому тут правильно обозначено, что одним из существенных условий успешности проекта является налаживание доброкачественных отношений Заказчик-Исполнитель.

был случай: пилили проект, деньги платили

а потом бах, собственники разосрались-разошлись и тьфу на 1с
благо свои люди в руководстве были: закрыли долги в день, когда вся катавасия началась

(80) был случай, проект на несколько миллионов. Написали, протестили на высших и средних уровнях. А на складах работали древние бабули за 8-10 тыс, которые до проекта вели учет по карточкам инвентаризационного учета. Так вот они вышли демонстрацией и сказали, либо мы, либо программа, потому что с компьютерами совсем никак. И все. Внедрение на этом закончилось. Потому что уволить всех топ не решился.

(81) там бабули очень быстро освоили ордера

(82) там был мотив, типа что мы тут за 10 тыс. должны еще и на компьютере научитья работать

(73) я и внедрения не заказываю. я внедрения делаю..
(76) О!!.. цель проекта всегда и явно озвучивать надо. одна из важнейших задач, чтобы все понимали цели проекта, а не просто говорить "а переходим с 77 на 8.0" или с 10.3 на 11.
и, "новая красивая платформа" - не цель...

(77) если фикс прайс - изменения будут идти со скрипом. если "время-деньги" - так, там почти и управлять нечем, если цели нет.

(85) да даже фикс прайс
фикс прайс ведь может быть и на 30 млн (ограничение бюджета)

мимо опять дилетант, но ветка очень интересная

(59) вот я не знаю. ТБР почитывал - там все эти проблемы решаются.

Почему не используют ТБР (в кратком - метод набегающей волны?)

Заказчики не подписываются на это?

Организационные. Заказчик никогда не знает, чего хочет, а исполнитель никогда не говорит, чего может. Увы, это везде. Ясно это становится опосля.

(87)[ ТБР почитывал - там все эти проблемы решаются. ]
поржал
от души

(72) Еще раз: не путай внедрение и предпроект

(89) ТБР - техника быстрого результата.

В (4) всё сказано.
Причём в самом широком смысле, начиная с самого заказчика/собственника.

(92) Не раскрыто там, в какой области / задачах / действиях участникам недопустимо проявлять долбое*изм )

А то может ГБ на калькуляторе вслед за каждым отчетом пересчитывает сумму - сошлась или нет. Долбое*изм? Вероятно, да, но проблем-то никаких )

так еще Ленин говорил о причинах:
Верхи (заказчики) не хотят, а низы (исполнители) не могут

(3) Ты как всегда, тролишь не по делу ;-)

(96) разве ты не согласен с утверждением (3) ?

(97) НИкогда не поздно перенести неудачный запуск на месяцок, другой

(98) А аванс не попросят вернуть?

(99) Смотря в каких ценовых категориях ты продался ;-)

А что есть такие, кто приступает к проекту без аванса, и вся сумма только по окончанию?

(101) Бывает проект одномесячный, бывает многомесячный, часть этапов заказчик может проверить, часть может не проверить по различным причинам

в (5) причина, остальное следствия.
из практики чаще всего проблема в том что заказчик плохо себе представляет что он хочет. и не имеет желания вникать в детали технической реализации, но при этом желает контролировать процесс и не доверяет тем кто эту техническую реализацию предлагает.

(103) Как вариант, спасибо

Есть еще идеи?

1. ОРганизационные- нет выделенного РП со стороны заказчика
2. ОРганизационные - нет выделенного времени ответственных за внедрение
3. Организационные- нет специалистов достаточной квалификации
4. Нет достаточного бюджета
5. Нет достаточного времени на решение задач.

"-Нет ребята, все не то, всё не так ребята."

Основной вопрос автоматизации чего-либо: -А нафига?

Если "цель проекта" внятная, измеримая и клиент знает что хочет, то нет проблем внедрить. Остальное является следствием отсутствия цели.

(106) Как вариант,  спасибо.

Моя цель- получить дискуссию и перечень проблем

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

но задал как задал

(105) А смысл высасывать из пальца?
Основные проблемы ты сам озвучил, ну и про (4) Джинн добавил, расширив твой п.3

Главная проблема, вернее ГЛАВНЕЙШАЯ - это отсутствие хороших учетчиков в компании, хорошо понимающих процессы в компании и их взаимосвязи. Как следствие, без таких людей и свой внутренний учет и процессы все выглядят затуманено и расплывчато. Тогда в руководстве появляется светлая мысль, что их спасет новая программа, но если автоматизировать хаос, то получится автоматизированный хаос, что и имеют в результате. Если компания не может сама четко организовать и прописать свои процессы и им следовать, то никакая 1С им не поможет. В этом и ошибка руководителей, что они ищут инструменты, а нужно укреплять кадры, искать не пи...лов, а хороших хозяйственников, тогда и внутренние процессы административно наладятся, а 1Снику нужно только будет их отразить в 1С.

(109) У всех разный опыт, разный уровень общений, разная квалификация, и если какой-нить начальный прог говорит, что постановщик задачи "идиот", и он по каким-то уже своим причинам делает задачу не так, это еще один пазлик фак апа проекта ;-)

(111) Если прог говорит, что постановщик задачи - идиот, и может это обосновать, то постановщик задачи - идиот, и его надо заменить.
Это совсем не обязательно сразу факап.

+ лет 7 назад работал с начальником логистики, который все свои идеи и схемы сначала тестировал и пробовал вести в экселе, поэтому с ним было легко работать по автоматизации, т.к. уже административно были созданы им реальный процессы и уже опробирован их учет в экселе, мне нужно было только перенести его в 1С.

Сейчас же новые начальники после того, мало того, что пох...ли те процессы, которые работали до них, не смогли разобраться с тем, что было создано и хорошо работало до этого, так запустили учет как в 1С, так и в складском хозяйстве и кадрах. Я смотрю на их работу с 1С, похоже на постапокалиптический мир, когда носятся полудикие племена с АК-47, которые используют в качестве дубинок, а не для стрельбы.

И вопрос тут не столько в обучении, а в том, что ранее лучше организованные реальные процессы в логистике и на складе отражались на том же уровне в 1С, а теперь реальные процессы сползли вниз, стали более примитивными и менее организованными и не соответствуют ранее заложенному их уровню в 1С.

Отсутствие денег и яиц на всех уровнях руководства

(106) >> Если "цель проекта" внятная, измеримая и клиент знает что хочет, то нет проблем внедрить.

Нифига не соглашусь. Всё внятно и чётко. У заказчика огроменный опыт работ на интереснейших предприятиях. Исполнитель очень грамотный (много лет с ними работаю). Техзадание отличнейшее. Без излишеств, но и полное. А по факту (88)

Есть такая проблема: когда бизнес-процесс в голове заказчика один, а по факту он другой.

(0)
В классическом проекте есть только 3 точки опоры
1. Время
2. Деньги
3. Объем
Если один из пунктов вызывает сомнение, проект провален.
Остальное вещи, такие как РП, спецы и т.д. решается одним из пунктов.

(117) Заказчик хочет, что бы у него появилась возможность ввода адреса фактического места проживания. Исполнитель умалчивает о семиуровневой модели разработки, т.к. на этапе заказа заказчик просто не поймёт нафига платить лишние деньги. Исполнитель просто добавляет в документ реквизит и все довольны. А потом выясняется, что по семиуровневой модели надо обновлять конфигурацию и готовиться к тому, что этот реквизит в будущем появится и в неизвестном виде. И вот наступает время Ч - заказчик платит деньги другому исполнителю со слезами на глазах, материт первого исполнителя и... А что и? Вначале всё было верно и без подвохов, а сейчас всё получилось по фразе из (88)
К сожалению многие специалисты (и с той и с другой стороны) действуют и рассуждают только из личного опыта и текущей ситуации. Поэтому очень часто никто не виноват, а работой не довольны никто. Оттакие пироги

(0)
- Саботаж со стороны сотрудников.
И открытый, и скрытый, когда сотрудники кивают, а потом забивают болт, виноваты конечно внедренцы

- Нехватка административного ресурса у РП со стороны заказчика
РП молодец, толковый, все правильно говорит, но ничего сделать не может, приходит финдир и говорит: Сделайте чтобы было как вот в этой моей табличке в Excel

(119) Что-то ты с адресом завернул, что за семь уровней?

(86) ты читал то, что я написал??.. что мимо?

(95) исполнитель не является низом.. в корне неверное отношение, что часто приводит к проблемам на проекте.. исполнитель не раб, а участник договорного процесса..
кстати - отношение к исполнителю как к рабу - тоже проблемы проектные))

(100) расссказывай, как не возвращать аванс))

(116) "Заказчик никогда не знает" - это о том, что нет цели.. ЦЕЛИ!!

(126) Не цели нет, а он её не может понять. Именно поэтому специалисты по определению целей стоят очень дорого. Простой пример: Многие говорят, что для них деньги самое важное в жизни, а в реальности деньги стоят как минимум на 20 месте. Так же и с конторами - везде твердится про повышение капитализации, а в реальности... А в реальности всё что угодно, только не деньги.

Господа, я конечно дико экскьюзми, но вы тут смешиваете все внедрения в одну кучу. В научном менеджменте принято выделять мелкие, средние и крупные предприятия. Т.к. они функционируют по разным "законам". Примерно то же самое относится и к внедрениям, их стоит разделять хотя бы на мелкие и крупные. Внедрение 1С:Розницы в сети ларьков это одно, а внедрение 1С:ERP в крупном холдинге уже совсем другое. Если попытаться применить "успешную практику внедрения розницы в магазине" на проекте внедрения ERP на заводе, то легко может случиться фиаско.

(128) Дык тут не о методологиях, а о проблемах внедрения.
Само собой, они не всегда все разом в одном проекте вылазят, но по совокупности всплывают так или иначе как в ларьках, так и в холдингах.

(129) так ведь проблемы и методологии связаны между собой. Многие методологии рождались из проблем, точнее как средство от этих самых проблем.

(130) Оно понятно. ТС как раз и хочет вывести набор общих проблем всех внедрежов :)

(127) цели не понимаются, они формулируются.. и в формулировании целей должен\может помочь консультант..
правда, это стоит денег и времени..  
вон год проект есть, где цель проекта - формулировка цели проекта автоматизации)). так что, не надо демагогии  "Не цели нет, а он её не может понять".

(128) оспариваю.. проблемы типичные.. вне зависимости от объема..

а бывает, что цели нет, а внедрение происходит

(134) ну, хорошо же ж..если внедрение успешное, то и проблем нет, то и говорить нечего.. побольше бы таких..

(128) Мы не говорим о содержательной части проекта, а об управлении самим проектом. Тут не важен размер.

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

(0) Как я вижу других программистов
https://coub.com/view/12po9q

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

Мне кажется мы немного разный смысл вкладываем в эти понятия.