Вход | Регистрация

  1  2   
1С:Предприятие :: 1С:Предприятие 8 общая

Основные проблемы при внедрении

Основные проблемы при внедрении
Я
   Krendel
 
04.12.18 - 17:40
Решил тут опрос провести, в преддверии череды запусков с 1-го числа:

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

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

По итогам сделаем голосовалку с перечнем проблем, чтобы выбрать топ 5 ;-)
Погнали
 
 
   formista2000
 
1 - 04.12.18 - 17:43
Недостаточное финансирование.
   PR
 
2 - 04.12.18 - 17:43
(0) >>в преддверии череды запусков
Пропал Калабуховский дом
   Вафель
 
3 - 04.12.18 - 17:45
уже поздно суетиться по текущим запускам на след. год. нужно было в сентябре
   Джинн
 
4 - 04.12.18 - 17:52
0. Долбоебы.
   МимохожийОднако
 
5 - 04.12.18 - 17:55
(0) И где голосовалка?
п.1 и последний. Руководство Заказчика не мотивировано на внедрение.
   Вафель
 
6 - 04.12.18 - 17:56
(5) Хотим внедрить, но чтоб оно само внедрилось
   Aleksey
 
7 - 04.12.18 - 17:57
А как же сопротивление внедрению среди топов?
   Джинн
 
8 - 04.12.18 - 17:57
(5) Руководство и не должно быть мотивировано. Мотивирован должен быть спонсор проекта.
   Джинн
 
9 - 04.12.18 - 17:58
(7) Это проблема спонсора проекта.
   shuhard
 
10 - 04.12.18 - 17:59
(0) а где нет возможности согласовать ТЗ/виза на ТЗ не стоит потрченных на неё чернил ?
 
 Рекламное место пустует
   Garykom
 
11 - 04.12.18 - 18:02
(4) + Рукожопы
   Garykom
 
12 - 04.12.18 - 18:04
(0) У "неудачного внедрения" в реальности всего одна проблема.

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

Все остальное не проблема совершенно.
Для заказчика это не проблема, потому что "супер денег сэкономили"
   Mort
 
13 - 04.12.18 - 18:05
1. Никто не знает что именно нужно сделать и каких целей добиться, зато дохера фантазеров как все будет работать, какие будут справочники и кнопочки на формах.
2. У внедренцев не хватает яиц заниматься первым и они делают второе.
   Buster007
 
14 - 04.12.18 - 18:05
отказа от внедрения еще не встречал, если начали, но по мне, основной причиной является то, что заказчик хотел кабриолет, а ему катер внедряют
   Buster007
 
15 - 04.12.18 - 18:06
ну и по классике: увольнять несогласных
   Garykom
 
16 - 04.12.18 - 18:06
(12)+ Причина(ы) провала совершенно неважны, теоретически исполнитель должен был предусмотреть любые причины и заложить их заранее в бюджет.

А вот если у него недостаток квалификации или произошел форс-мажор (описанный в договоре) то извините.
   impulse9
 
17 - 04.12.18 - 18:07
(0)
Самый главный пункт:
Сотрудникам заказчика невыгодно переходить на новую систему - на каждом первом проекте встречаем динозавра, пилящего свою нетленку, на каждом втором управленцев с мутными бизнес-процессами.
   shuhard
 
18 - 04.12.18 - 18:08
(17) саботажи уже были см(7)
   МимохожийОднако
 
19 - 04.12.18 - 18:10
(8) Под руководством я подразумеваю тех, кто платит. Кто платит, тот и танцует.
   KSN
 
20 - 04.12.18 - 18:10
Саботаж ответственных лиц. Им просто лениво переучиваться и задумываться о новых возможностях.
   Джинн
 
21 - 04.12.18 - 18:12
(19) Спонсор проекта - это не тот, кто платит. Это тот, кто кровно заинтересован в бизнес-результатах проекта.
   impulse9
 
22 - 04.12.18 - 18:12
(20) или они имеют нехилый гешефт
   shuhard
 
23 - 04.12.18 - 18:14
(21) при наличии учредителей, наемного директората, бюджетного комитета, аудиа и контроля найти на проекте классические роли не представляется возможным
   Конструктор1С
 
24 - 04.12.18 - 18:17
А каких размахов внедрения, если не секрет?
   Джинн
 
25 - 04.12.18 - 18:20
(23) Тем не менее без Устава проекта и зафиксированных в нем на бумаге ролей бессмысленно двигаться дальше. Ну если не ставить целью, конечно, затянуть процесс до бесконечности и потихоньку рубить бабло, прикрываясь скрамами и прочими эйджелами.
   Lama12
 
26 - 04.12.18 - 18:21
Нет заинтересованности руководства заказчика в успешности проекта.
   Полбатона
 
27 - 04.12.18 - 18:22
(25) такое дело, что полностью документально вести проект до 1-1,5 млн. невыгодно ни по бюджету, ни по времени
   Джинн
 
28 - 04.12.18 - 18:32
(27) И такое возможно. Но тогда Вы вкладываете в риски проекта то, что сэкономили на этапе инициации проекта.
   Garykom
 
29 - 04.12.18 - 18:33
(27) Это не совсем так, просто на малых (недорогих) проектах часто нет смысла вести документацию в бумажном/электронном виде полностью.

Достаточно полного плана в голове(ах) и кратких заметок по этапам.

Даже когда "проект" банальная установка БП3 на одном компе с настройкой и обучением/консультацией одного сотрудника (бухгалтера) один фиг предпроектное обследование и т.д.
https://www.cfin.ru/itm/kis/process-vnedrenia.shtml
   Полбатона
 
30 - 04.12.18 - 18:34
(28) и тут тонкая грань.Если у заказчика ограничен бюджет, а вам уж очень хочется миллион, то всегда можно договориться сделать все без бумажек и бюрократии. Это не те деньги
   Garykom
 
31 - 04.12.18 - 18:35
(29)+ Если же некто берется за проект не представляя что это такое, в стиле "о есть клиент, он деньги платит".
То результат совершенно логичен.
   Garykom
 
32 - 04.12.18 - 18:36
(30) И в чем проблема? Заказчик захотел сэкономить - значит он согласился принять риски провала на себя.
   Полбатона
 
33 - 04.12.18 - 18:36
(31) нет ниакой связи между документацией и результатом внедрения проекта. Знавал я конторы, которые упешной командой провалили такие же успешные проекты
 
 
   Джинн
 
34 - 04.12.18 - 18:36
(30) Можно попытаться построить дом без проекта и прораба. Иногда это получается даже. Чаще дом либо падает, либо обладает комплектом неустранимых косяков, либо просто некомфортен для проживания.
   Полбатона
 
35 - 04.12.18 - 18:37
(32) в том, что не надо бросаться в крайности. в этом деле главное выверенное соотношение наших возможностей с возможностями заказчика
   Garykom
 
36 - 04.12.18 - 18:38
(33) В случае наличия документации и при первых признаках провала, можно провести какой то аудит (в т.ч. сторонний) и сделать выводы.

Если же ничего нет - нечего анализировать.
   Garykom
 
37 - 04.12.18 - 18:39
(34) Есть редкие исключения, когда строитель уже построил дохрена домов и сам работал прорабом. Ему даже проект в бумажном/электронном виде не надо, в голове все.

Но это именно исключение или шаблонный/типовой дом.
   Полбатона
 
38 - 04.12.18 - 18:41
(36) на крупнобюджетных проектах - не спорю, можно все делать красиво. Но повторюсь, на проектах до 1 млн. ведение документации существенно сокращает бюджет на непосредственное внедрение
   Garykom
 
39 - 04.12.18 - 18:49
(38) Неважно какой бюджет, даже если всего 10 т.р. можно потратить чуток времени чтобы сделать бумажки.
Хотя бы кратко описать "as is", "to be" и по шагам что делать планируем. Затем что фактически сделали.

Это сильно поможет найти крайних если что.
   Полбатона
 
40 - 04.12.18 - 18:50
(39) и сколько ты лично сделал таких проектов?
   Джинн
 
41 - 04.12.18 - 18:55
(39) Хотя бы описать роли, зоны ответственности, риски и способы реакции на них, порядок разрешения конфликтов. Т.е. даже не содержательную часть проекта, а административную его часть. Содержательную можно "съесть по частям" потом.
   timurhv
 
42 - 04.12.18 - 18:58
Отсутствие документации в маленьких и крупных проектах - это ваши риски. Будете доказывать что не Буратино.

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

В итоге достали документацию, сели вместе и прошлись по всем пунктам, вопросов больше не было.
   timurhv
 
43 - 04.12.18 - 19:01
(29) Вперед, ничего не фиксируйте. За неделю до сдачи работ ответственный за проект сотрудник увольняется, а новый вам ничего не подпишет и не оплатит.
   Доминошник
 
44 - 04.12.18 - 19:01
Анекдот про патроны уже рассказывали?

«-Почему вы проиграли сражение?
-О, тому была тысяча причин! Во‑первых, у нас кончились патроны…»
   Garykom
 
45 - 04.12.18 - 19:02
(40) Лично я хитрее поступаю и не берусь целиком сразу за проекты.
Только за конкретные задачи (мелкие частички проекта) которые и делаю последовательно, получая оплату за каждую решенную задачу.
   Garykom
 
46 - 04.12.18 - 19:04
(43) Есть такой риск, согласен. Но когда суммы не велики то можно пренебречь.
В дальнейшем этот клиент попадает в серый/черный список и новые работы только по факту приема/оплаты старых, не подписанных и не оплаченных.
   Garykom
 
47 - 04.12.18 - 19:04
(46)+ И предоплате новых работ ))
   Злопчинский
 
48 - 04.12.18 - 19:08
У Заказчика банально не выстроены процессы. Поэтому при внедрении все летит кувырком. Вместо внедреняи продукта приходится втискивать продукт в какую-то хрень, потому что НКПР получается. В результате связи рвутся или по тонкой жиле приходит мегаток и всех убивает.
   Джинн
 
49 - 04.12.18 - 19:10
(45) Если это какой-нибудь заводик человек на 200-250 (и соответственно рыл 45-55 в базе), то сложно "по частям" это сделать. Хотя бы базовый функционал нужно одномоментно запускать.
 
 Рекламное место пустует
   Garykom
 
50 - 04.12.18 - 19:13
(49) И вот тут согласен что без документации ну никак. Т.е. вопрос документации не в сумме проекта, а в его сложности.
   Злопчинский
 
51 - 04.12.18 - 19:55
(16) на такой бюджет - заказчик не согласен. Он хочет кабриолет по цене жигулей.
   Garykom
 
52 - 04.12.18 - 20:06
   Злопчинский
 
53 - 04.12.18 - 20:07
(50) Систему как правило заказывает Заказчик.
Как правило - в результате хотя бы написания ТП/ТЗ - сформулировано что должна уметь система и, иногда жаде - как это она должна делать. Сформулировано совместно Заказчиком и Исполнителем. Писать доку - по чём? Как работать с интерфейсом 1С? как настраивать удобный вид списков? и при необходимости выводить доколонки? - нахрена? Часьтности по документации интересны м.б. только техническим специалистам Заказчика. Никто покупая машину не получает инструкци. как она устроена и как внутри все работает - на какойм угле опережения стоят свечи или с какой скоростью и дозой идет впрыск. Описывается функциональная инструкция. Как работать, чтобы добиться ожидаемых результатов, а не как устроена система. Описать "функциональную инструкцию" - вполне в состоянии вменяемый Заказчик, с незначительной помощью Исполнителя по каким-то тонкостям/существенным моментам.
Если Заказчик вообще не присутствует в написании такой Инструкции, а ожидает/требует от Заказчика такую инструкцию - 95% что проект или сдохнет, или хреново запустится. Ибо Исполнителю нахрен ничего не надо.

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

Или как можно написать инструкцию по использованию универсального инструмента типа "универсальны подбор и обработка объектов"...? вся инструкция уместится на листе А4 по существу. Нет, напишите для каждого конкретного случая!
   Злопчинский
 
54 - 04.12.18 - 20:09
(52) да! и сюда же в эту цену такого кабриолета хочется кондишен хайпремиум, сиденья из кожи из жопы дракона, итд - это же все в порядке вещей в кабриолете и должэно быть! это же кабриолет! но за 300 тыс! это ведь жикули!
   Garykom
 
55 - 04.12.18 - 20:12
(53) Тут немного иное, одно дело если внедряют типовую систему без доработок (как покупают автомобиль) и совсем другое когда доработки или некая своя система (доработка или новая разработка автомобиля).

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

Чтобы не поиметь проблем как с приемкой/оценкой сложностей так и будущими доработками/сопровождением.
Или в процессе работ заказчик может попросить к кабриолету приделать гусеницы или крылья...
   France
 
56 - 04.12.18 - 20:14
(0) так, описанные в рамках управления проектом решаются же))
но, выделю

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

Опишу по фикс-прайсу:
1. ОРганизационные - нет лица, который может принять решение об изменении существующих процессов
2. изменение функциональных рамок по ходу проекта (если фикс прайс. для t&m не актуально)
3. Нет заинтересованности топ-менеджмента в итоговом результате, и топ-менеджмент готов удовлетворить все прихоти пользователей (норм при t&m, полный атас при фикс-прайс).
   France
 
57 - 04.12.18 - 20:15
недостаточное финансирование не может быть проблемой проекта...
   jsmith82
 
58 - 04.12.18 - 20:23
4. нет бюджета
   Злопчинский
 
59 - 04.12.18 - 20:24
Основная проблема - это по существу как уложиться в фикспрайс при фиксированных сроках и неясных функциональных границах проекта. Ибо то что надо - становится более менее ясно при разработке ТехПроекта. а техпроект - чать внедрения с фиксированным прйасом.
   France
 
60 - 04.12.18 - 20:31
(58) откуда появится проект, если нет бюджета?
(59) без функциональных рамок вообще заходит нельзя. а если есть функциональные рамки, то нужно все изменения контролировать, и хотелки\перделки отсекать.. вот здесь и сложность..
а вот с "то что надо становится более менее сно при разработке" - так с таким началом проекта при фикс прайс проект обречен..
   France
 
61 - 04.12.18 - 20:34
и, любые личные связи (друзья, знакомые, сочтемся все свои, хорошие отношения0  на проекте нужно признавать порочащими, и в корне пресекать!!
   Злопчинский
 
62 - 04.12.18 - 20:37
(60) Функциональные рамки - вещь непростая. Если они расплывчаты - то каждая из сторон проекта трактует их по совему. Проблемы. если функциональные рамки - сильно детализировать - получается ТП. А стоимость разработки ТП - отдельные деньги... Замкнутый круг.
   Злопчинский
 
63 - 04.12.18 - 20:38
(60) "а вот с "то что надо становится более менее сно при разработке" - так с таким началом проекта при фикс прайс проект обречен.." - так в этом то и проблема. Ваяется уникальный продукт на основе некоего базового каркаса. Клиент хочет фиксированную цену до начала проекта. Фиксированная цена - на базовый каркас - который сам по себе не ездит... И начинается...
   Cyberhawk
 
64 - 04.12.18 - 20:39
(59) "неясных функциональных границах проекта" // Предпроектное обследование - как отдельный проект - полностью закрывает этот вопрос
   France
 
65 - 04.12.18 - 20:40
(62) если суметь договорится, что обсуждаем результат выполнения какой то функции, а не способ разработки баз и программирования - то круг не замкнутый..
функция "резервирование товаров" - вот его и проверяем (резервируется ли по сериям\срокам годности, если резервирование под заказ и тд), а не где какую и когда нажимать кнопочку, чтобы зарезервировать товар.
   Злопчинский
 
66 - 04.12.18 - 20:59
(64) Предпроектное обследование - это по сути будет ТП. Стоит достаточно серьезных денег. Простое предпроектное исследование - дает весьма размытые трактовки для разных строн.
   France
 
67 - 04.12.18 - 21:06
(66) достаточно серьезные - это сколько?
   Cyberhawk
 
68 - 04.12.18 - 21:09
(66) Никакой ТП на обследовании конечно же не нужен - результатом обследования будет ответ на вопрос "что", а не "как". Что на входе и что на выходе, т.е. простой черный ящик.
ТП - т.е. реализация этого черного ящика, отвечающая на вопрос "как" - не нужна в предпроекте.
   ice777
 
69 - 04.12.18 - 21:31
(0) Нет попила- нет внедрения.
   France
 
70 - 04.12.18 - 21:32
(69) хм.. я не делюсь..
   France
 
71 - 04.12.18 - 21:33
хотя. не.. всякие бывают0)
   Злопчинский
 
72 - 04.12.18 - 21:52
(68) "как" - и составляет всю особенность проекта. от входа до выхода - разные дороги ведут. собственно решение о том "как" - и составляет сущность ТП. Приемка товара - она и есть приемка товара. А вот как именно и что делать во время приемки и надо ли это делать вообще - собственно реализация таких "хотелок" и составляет предмет "бодания", а если все эти хотелки не описать в ТП - Заказчик говорит "ну это же само собой разумеется, это должно быть/это типа стандарт" - стандарт машины - это четыре колеса + мотор+кузов. однако есть машины за лям. а есть за 10 лямов. хотя и те и те служат для езды.
   ice777
 
73 - 04.12.18 - 21:53
(70) а зачем с тобой делиться, если ты не хозяин? С кем надо делятся.
   Злопчинский
 
74 - 04.12.18 - 21:56
Т.е. собственно границы проекта - и есть точка преткновения. размытые нечеткие границы проекта в формате "есть вход - есть выход" - порождают кучу разногласий мало того что должно быть внутри, так еще и собственно даже на этапе определения что есть вход и что есть выход. Обсуждать это детально на предпроектном исследовании - за 0 денег - некузяво. Обсуждать это серьезно - это значит по сути этап ТП выносить вне рамок проекта. В нашей отрасли так никто не делает (по крайней мере я такого не знаю).
   Черный маклер
 
75 - 04.12.18 - 22:00
Думаю успех проекта в равной степени зависит от трех факторов:
- адекватность команды Заказчика
- адекватность команды Исполнителя
- соответствие Продукта целям проекта

Исполнитель должен оценить п.1 до подписания договора. С неготовым к внедрению Заказчиком лучше не связываться.
Но в жизни зачастую команда Исполнителя ставится перед фактом условий уже заключенного договора.
   Злопчинский
 
76 - 04.12.18 - 22:07
(75) Ну и собственно выяснения какая реальная цель проекта. Декларировать можно одно, а добиваться выполнения совсем другого.
   Dmitry1c
 
77 - 04.12.18 - 22:22
А никто не работает с запросами на изменение чтоли? Что-то все уперлись в фискированные рамки проекта, фиксированные тз и так далее

мимо дилетант
   FormatC
 
78 - 04.12.18 - 22:32
(0) "Вася" уволился и бизнесу писец ))))
   Злопчинский
 
79 - 04.12.18 - 23:01
(77) Клиент хочет результат. А не процесс. Хотя как раз надо делать по процессу, в условиях нечетких требований. Но тогда фиксировать либо время, либо бюджет. Клиент опасается, что в итоге не получит того что ожидает, хотя из того что он заявляет - дохрена ему нафиг не надо, и они и представляют сложность основную, которую можно было бы допиливать вне рамок проекта.

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

Поэтому тут правильно обозначено, что одним из существенных условий успешности проекта является налаживание доброкачественных отношений Заказчик-Исполнитель.
   zak555
 
80 - 04.12.18 - 23:15
был случай: пилили проект, деньги платили
 
а потом бах, собственники разосрались-разошлись и тьфу на 1с
благо свои люди в руководстве были: закрыли долги в день, когда вся катавасия началась
   Полбатона
 
81 - 04.12.18 - 23:23
(80) был случай, проект на несколько миллионов. Написали, протестили на высших и средних уровнях. А на складах работали древние бабули за 8-10 тыс, которые до проекта вели учет по карточкам инвентаризационного учета. Так вот они вышли демонстрацией и сказали, либо мы, либо программа, потому что с компьютерами совсем никак. И все. Внедрение на этом закончилось. Потому что уволить всех топ не решился.
   zak555
 
82 - 04.12.18 - 23:29
(81) там бабули очень быстро освоили ордера
   Полбатона
 
83 - 04.12.18 - 23:29
(82) там был мотив, типа что мы тут за 10 тыс. должны еще и на компьютере научитья работать
   France
 
84 - 04.12.18 - 23:30
(73) я и внедрения не заказываю. я внедрения делаю..
(76) О!!.. цель проекта всегда и явно озвучивать надо. одна из важнейших задач, чтобы все понимали цели проекта, а не просто говорить "а переходим с 77 на 8.0" или с 10.3 на 11.
и, "новая красивая платформа" - не цель...
   France
 
85 - 04.12.18 - 23:31
(77) если фикс прайс - изменения будут идти со скрипом. если "время-деньги" - так, там почти и управлять нечем, если цели нет.
   Dmitry1c
 
86 - 05.12.18 - 07:36
(85) да даже фикс прайс
фикс прайс ведь может быть и на 30 млн (ограничение бюджета)

мимо опять дилетант, но ветка очень интересная
   Dmitry1c
 
87 - 05.12.18 - 07:43
(59) вот я не знаю. ТБР почитывал - там все эти проблемы решаются.

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

Заказчики не подписываются на это?
   strange2007
 
88 - 05.12.18 - 10:11
Организационные. Заказчик никогда не знает, чего хочет, а исполнитель никогда не говорит, чего может. Увы, это везде. Ясно это становится опосля.
   shuhard
 
89 - 05.12.18 - 10:51
(87)[ ТБР почитывал - там все эти проблемы решаются. ]
поржал
от души
   Cyberhawk
 
90 - 05.12.18 - 11:26
(72) Еще раз: не путай внедрение и предпроект
   Tonik992
 
91 - 05.12.18 - 11:31
(89) ТБР - техника быстрого результата.
   Мелифаро
 
92 - 05.12.18 - 11:33
В (4) всё сказано.
Причём в самом широком смысле, начиная с самого заказчика/собственника.
   Cyberhawk
 
93 - 05.12.18 - 11:34
(92) Не раскрыто там, в какой области / задачах / действиях участникам недопустимо проявлять долбое*изм )
   Cyberhawk
 
94 - 05.12.18 - 11:35
А то может ГБ на калькуляторе вслед за каждым отчетом пересчитывает сумму - сошлась или нет. Долбое*изм? Вероятно, да, но проблем-то никаких )
   Вафель
 
95 - 05.12.18 - 11:45
так еще Ленин говорил о причинах:
Верхи (заказчики) не хотят, а низы (исполнители) не могут
   Krendel
 
96 - 05.12.18 - 11:52
(3) Ты как всегда, тролишь не по делу ;-)
   Вафель
 
97 - 05.12.18 - 11:53
(96) разве ты не согласен с утверждением (3) ?
   Krendel
 
98 - 05.12.18 - 11:54
(97) НИкогда не поздно перенести неудачный запуск на месяцок, другой
   Вафель
 
99 - 05.12.18 - 11:55
(98) А аванс не попросят вернуть?
   Krendel
 
100 - 05.12.18 - 12:04
(99) Смотря в каких ценовых категориях ты продался ;-)
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует