единственный способ это исправить - зарегистрировать соответствующий запрос в поддержке

[George Nordic]

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

Цитата:

КОМПАНИЯ SAP AG ВНЕДРЯЕТ МНОГОУРОВНЕВУЮ ПОДДЕРЖКУ

Ссылка: http://www.sap.com/cis/about/press/2...se_Support.epx

А вот обсуждение уровня поддержки: http://www.sapboard.ru/forum/viewtopic.php?f=17&t=59030

Цитата:

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

Еще про поддержку: http://www.sapboard.ru/forum/viewtopic.php?f=17&t=65118

Цитата:

Возникла ситуация, когда SAP CIS явным образом "вешает лапшу" и не хочет исправлять ошибки.Как напрямую обратиться в Вальдорф?.... Ну нет больше сил бодаться с САП-Москва
- ха-ха, а с САП-индия думаете вам легче бодаться будет?
-Из поста ТС не вполне ясно:
1. что именно волынит САП СНГ.
2. почему проблемой занимается САП СНГ, а не SAP Active Global Support?
3. если выставлен Customer Message, то речь идет скорее всего о саппорте. В таком случае, это не САП СНГ из Москвы, а SAP AGS в лице его Питерской структуры. Если речь конечно идет о РФ. Работают ли они по Украине - не знаю.

В итоге, какие варианты воздействия:
1. Если у вас есть собственный текникал манагер - жаловаться ему. Насколько я понял, этот шаг не пройден.
2. Пинать Account Manager'a: мы вот тут платим за саппорт, а какого хрена он волынит. При должной настойчивости/злобности/[censored] можно оперировать такими категориями, как отказ от расширения объема закупаемых лицензий из за того, что весь бюджет ушел в собственный саппорт, отказ от дополнительно лицензируемого функционала, в более злобных вариантах - отказ от оплаты саппорта. Но последнее и по вам самим больно может стукнуть.
По собственному опыту, с питерским АГС вполне можно хорошо работать, но некоторая настойчивость, определенно, необходима.

Насчет обновлений в соответствии с законами РФ - http://www.sapboard.ru/forum/viewtopic.php?f=17&t=69424

Цитата:

Всё более-менее в порядке и с кадрами, и с зарплатой. Формы выходят попозже, чем в эске. Но достаточно для сдачи отчетности....Всё достаточно оперативно решается, все эти вопросы были закрыты своевременно

Это так, для сравнения. У всех есть подобные проблемы.

Что же касается моего личного мнения:
1) Многоуровневая поддержка - совершенно необходима, fed прав.
2) Регистрировать ошибку надо в первую очередь у локальных специалистов, если есть такая возможность. Т.е. ошибка в русском функционале - запрос специалисту, который отвечает за регион, куда входит Россия, а лучше - российской команде.
3) Исправлять ошибку должен не саппорт, а тот специалист, который ее допустил. Под контролем архитектора, который расскажет, как ее можно было избежать и сотрудника поддержки. Думать будет в следующий раз.
4) Неплохо бы, если бы сотрудники разработки / поддержки были не "теоретиками", которые локализуют новые версии, а сотрудниками консалтинга, которые периодически на живых клиентах внедряют свой же собственный код. А задачи им ставят - тоже "боевые" консультанты, с полей. Очень эффективно получается. Гораздо более аккуратно люди относятся к разработке, когда понимают, что им же это все и поддерживать. Хотя возникает вопрос с отчуждаемостью кода - все-таки получается крен в сторону решений проблем клиента.

Однако локализация SAP шла именно по такому пути. К ней из-за этого были нарекания, однако все равно, насколько я знаю, задача по локализации была решена небольшой группой специалистов и довольно эффективно. И в короткие сроки. По крайней мере, так мне рассказывали про модуль HR участники тех событий.

А самое главное - поддержка должна быть ЗАИНТЕРЕСОВАНА в принятии багов. В любой организации, я не говорю ни про кого конкретно. Иначе - "да гори они все огнем. А партнеры / клиенты- недалекие, сами разобраться не могут, нас тут терзают, телефон настроить не могут, комп / роутер перегрузить, IP адрес прописать, KDE под FreeBSD пропатчить, в аллодов погонять не дают."

С Уважением,
Георгий

[fed]

Цитата:

Сообщение от Владимир Максимов

Это не культура. Это вполне естесственная минимазиция затрат. Если я могу решить проблему просто спросив, то почему бы этого не сделать?

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

[Владимир Максимов]

Цитата:

Сообщение от fed

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

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

Хотя с выводом согласен. Регистрация багов ни в коем случае не должна превращаться в тех.поддержку. Действительно нужен фильтр. Другой вопрос, что, как правильно заметил George Nordic, нужна заинтересованность в регистрации багов.

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

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

[Logger]

Георгий, спасибо за отзывы.

Цитата:

Сообщение от George Nordic

...А самое главное - поддержка должна быть ЗАИНТЕРЕСОВАНА в принятии багов....
С Уважением,
Георгий

А как это сделать ?
В чем будет её интерес ?

В случае провайдера интерес понятен - косячит поддержка, клиент тут же уходит к другому. Поэтому провайдер (успешный) за поддержкой следит и не жалеет на неё средств.

А в случае ёпрст системы - её же все равно купили уже. Уже сидят на игле. Можно доить...
Никуда не денутся.

[finn]

Цитата:

Сообщение от George Nordic

А самое главное - поддержка должна быть ЗАИНТЕРЕСОВАНА в принятии багов. В любой организации, я не говорю ни про кого конкретно. Иначе - "да гори они все огнем.

Поддержка заинтересована в наличии фронта работ. Есть фронт работ - выполняются показатели по загрузке - начальник не ругает, платит деньги и т.д..
Фронт работ может заполняться и русскими запросами и европейскими.

Цитата:

Сообщение от fed

Соответственно, регистрация ошибок выгодна ТОЛЬКО для партнеров (которые вели и ведут много проектов) и ТОЛЬКО если речь идет о какой-то часто встречающейся ошибке, в часто внедряемом модуле. Только в этом случае, есть слабые шансы что затраты на регистрацию ошибки, когда-то отобьются. (И то не факт).

Так что, мы все конечно должны поблагодарить gl00mie за регистрацию багов, но вот его работодатель должен был бы выписать ему штраф за бессмысленные потери рабочего времени.

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

В целом мне кажется надо мыслить стратегически и в какой то мере альтруистично.
Если сообщество заинтересовано в улучшении продукта, пусть не сразу, пусть в следующем rollup или даже в следующей версии... то надо не воспринимать регистрацию ошибок как потерю времени.

Инженер службы поддержки, NAV
Microsoft Rus

[fed]

Цитата:

Сообщение от finn

В целом мне кажется надо мыслить стратегически и в какой то мере альтруистично.
Если сообщество заинтересовано в улучшении продукта, пусть не сразу, пусть в следующем rollup или даже в следующей версии... то надо не воспринимать регистрацию ошибок как потерю времени.

Инженер службы поддержки, NAV
Microsoft Rus

Ты вот это все очень правильно написал, но только вот стратегически мыслящие партнеры как-то с хлеба на воду перебиваются, а не стратегически мыслящие втюхиватели - становятся членами Перзидентских Клубов и Илитных Циркулей. В общем - извини - но пока Микрософт не начнет своих партнеров мерять не только по текущей выручке, но и по хоть каким-то результатам внедрений, все разговоры о стратегии и альтруизме - это разговоры в пользу бедных...

[pitersky]

Цитата:

Сообщение от fed

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

а как это сделать? выручка - показатель объективный и однозначный. а вот результаты внедрений...

[fed]

Цитата:

Сообщение от pitersky

а как это сделать? выручка - показатель объективный и однозначный. а вот результаты внедрений...

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

[Logger]

Цитата:

Сообщение от fed

Во вторых - да - результаты внедрений - штука неоднозначная. Но статистика и закон больших чисел все-таки позволяет оценить результаты внедрений по партнеру за достаточно длительный период.

Постой, Денис. А как ты это сделаешь ?
Предположим у тебя есть достаточно длительный период. 2000-2010-й годы и подробная статистика.

Как ты оценишь какой партнер хороший, а какой нет ?

[fed]

Цитата:

Сообщение от Logger

Постой, Денис. А как ты это сделаешь ?
Предположим у тебя есть достаточно длительный период. 2000-2010-й годы и подробная статистика.

Как ты оценишь какой партнер хороший, а какой нет ?

Ну в общем - можно было бы, при продаже аксапты клиенту, оговорить право опрашивать (периодически) клиента на предмет удовлетворенности. Типа через полгода после продажи, через год, через полтора, через 2 и дальше через год. При этом тупо просить клиента оценить по шкале от 1 до 5 качество внедрения и живо ли еще внедрение как таковой. Кроме того - попросить назвать запомнвишихся спецов с которыми он работал или работает. Естественно - клиент может быть идиотом и провалить внедрение по своей вине. Естественно клиент может не знать с кем он работает из консов и программистов. Естественно - конс или программист может тупо не иметь MCP ID. Но по закону больших чисел, можно собрать статистику успешности и по партнеру и по спецу. В этом случае, мы можем получить некую относительно объективную картину.

[mazzy]

Цитата:

Сообщение от fed

Но по закону больших чисел, можно собрать статистику...

По закону больших чисел можно собрать статистику... продаж.
Если партнер продает из года в год на протяжении длительного периода, то значит и провалов у него не так уж и много.

Я понимаю, что продажи очень косвенный показатель.
Но это действительно достоверно измеряемый Майкрософтом показатель.

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

[fed]

Цитата:

Сообщение от mazzy

По закону больших чисел можно собрать статистику... продаж.
Если партнер продает из года в год на протяжении длительного периода, то значит и провалов у него не так уж и много.

Я понимаю, что продажи очень косвенный показатель.
Но это действительно достоверно измеряемый Майкрософтом показатель.

Если дискуссия разовьется - да - надо выносить в другую ветку.
Кстати хочу напомнить, что по слухам, году в 2006ом-2007ом процентов 50-60 выручки тебе приносила переделка проектов за одним очень золотым партнером. И ничего - живет себе партнер и развивается, неразоряется и даже не особо теряет рыночную долю.
Просто рынок аксаптовских внедрений является класическим рынком лимонов и вишенок, на котором конкурентные преимущества имеет тот партнер, который тупо держит себестоимость и качество внедрений ниже среднерыночных. Соответственно - среднее качество внедрения падает, репутация продукта портится и в конечном итоге - рынок может просто рухнуть в связи с полной дискредетацией. При этом вендор, на мой взгляд, своим регулированием рынка приводит к еще большему ухудшению adverse selection, поскольку предоставляет преимущества тем партнерам, которые больше всех продают (а на нашем рынке это всегда означает низкое качество внедрений...)

[mazzy]

Возвращаемся к поддержке.

Цитата:

Сообщение от finn

В целом мне кажется надо мыслить стратегически и в какой то мере альтруистично.
Если сообщество заинтересовано в улучшении продукта, пусть не сразу, пусть в следующем rollup или даже в следующей версии... то надо не воспринимать регистрацию ошибок как потерю времени.

Инженер службы поддержки, NAV
Microsoft Rus

Вот только не надо, а?

1. Ложь
Не надо говорить, что сообщество не альтруистично.
Очень даже альтруистично. Достаточно посмотреть на теги баг, ошибка на этом форуме.

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

Особенно, на фоне сообщений о том, что некоторые вообще платят деньги нашедшим ошибки.

2. Подмена понятий "в улучшении продукта, пусть не сразу, пусть в следующем rollup или даже в следующей версии"
вот, не надо, а?

тема: поддержка (!)
тема: единственный способ это исправить - зарегистрировать соответствующий запрос в поддержке

внимание! никто не говорит о предложениях по улучшению.
говорится об ошибках. которые вендор должен исправлять в ЭТОЙ версии.
в рамках maintanence plan, который оплачивает клиент
в рамках партенрского взноса, который оплачивает партнер.

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


Да, дофига сообщений об ошибках. И народ готов.
Просто Майкрософт должен собирайть и обрабатывать нормально.
И не надо сообщество обвинять.

[mazzy]

Цитата:

Сообщение от fed

Кстати хочу напомнить, что по слухам, году в 2006ом-2007ом процентов 50-60 выручки тебе приносила переделка проектов за одним очень золотым партнером. И ничего - живет себе партнер и развивается, неразоряется и даже не особо теряет рыночную долю.

И дай бог ему здоровья.
Пусть будет больше партнеров, хороших и разных.

Надеюсь, ты не хотел этим сказать, что у нас не было продаж
Да, продажи очень косвенный признак. Но единственно достоверно измеряемый майкрософтом.

[Logger]

Еще гугл платил за найденные дырке в хроме.
Кто-то даже заработал на этом неплохо.

[belugin]

Цитата:

Сообщение от Logger

Еще гугл платил за найденные дырке в хроме.
Кто-то даже заработал на этом неплохо.

Насколько я понял, они платят только за баги, связанные с безопасностью. Когда я нашел SQL injection в Ax3 и написал об этом в блоге, мне через день или около того позвонили из MS и расспросили о деталях.

[Logger]

Цитата:

Сообщение от belugin

Насколько я понял, они платят только за баги, связанные с безопасностью. Когда я нашел SQL injection в Ax3 и написал об этом в блоге, мне через день или около того позвонили из MS и расспросили о деталях.

И денег заплатили ?

Поделитесь ссылкой на статью в базе знаний. Интересно почитать. Это не то место где при использовании литералов в запросе можно исполнить произвольный SQL код ?

[belugin]

Не, денег не заплатили - именно то. Я, честно говоря, не знаю статью. Багу просто описал письмом - так что даже не знаю как ее сейчас идентифицировать.

P.S. Я не пытаюсь доказать, что подержка Chrome совершенно такая же как и Ax - просто тут пытаются сравнить несравнимое. Продукты разные и про баги разные говорят.

P.P.S Насколько я понял, MS платит за безопасность по-другому

[Logger]

Ну багу то хоть исправили ?

[Logger]

Цитата:

Сообщение от belugin

Не, денег не заплатили - именно то.

Да в общем то не обязаны были. Не обещали ведь.

Я акцентирую внимание на этом, потому что пока одни компании ищут помощи обычных пользователей в том как сделать свои продукты надежнее и стабильнее. - Другие огораживаются забором от пользователей и внедренцев, чтобы этого не делать.
Примеров предостаточно. Режет глаз. Грустно все.
Они же блин затраты экономят ! Еще не заработали прибыли на ERP, а уже экономят.