Вход | Регистрация
    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   

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