А про гарантию на систему вы не слышали? Исправление ошибок внедрения, как правило, не оплачивается клиентом

[Ivanhoe]

***Тема выделена из темы работа в консалтинге vs. на клиенте ***

Цитата:

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

Да нет, всё таки, это довод. В консалтинге внедрение и саппорт разные структурные подразделения и задачи у них разные. Если акт будет подписан, а потом саппорт переписывает кучу всего, никто ничего плохого внедренцам не скажет, т.к. деньги они в компанию принесли, а теперь время саппорту приносить деньги в компанию. Так что никакого минного поля для себя внедренцы не оставляют. А саппорт? Ну так они минеры по сути и есть.

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

Цитата:

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

+100 в консалтинге специалисты работают по принципу "ишак с морковкой", в качестве морковки -бонус.
Но подрываешь здоровье частыми перелетами, сменой климата, стрессом.

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

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

Из своего опыта могу сказать, что и клиенты, и консалтинг (конкретные проекты) могут быть совершенно разными и каждый в этой дискуссии просто делится непосредственно своим опытом. Для более правильного (хотя бы с точки зрения статистики) "развешивания ярлыков", стоит провести опрос и собрать мнение хотя б сотни участников с той и другой стороны.
Кто-то готов продумать вопросы?

[GBH]

Цитата:

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

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

Конечно слышал. Только кто скажет? Начальник отдела техподдержки не будет здороваться с ПМом? Так ПМ в командировке (на другом проекте и т.п.), ну "погорят" у него уши, т.к. много людей вспоминаю его.

Цитата:

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

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

Хорошая идея, кстати.
Только кто считается "той" стороной, а кто "этой"? По текущему месту работы или по убеждению, основанному на своем личном опыте?

[ice]

Цитата:

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

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

что за гарантия на систему? это месяц оплаченного сапорта (который включается в договор и оплачивается)? а если архитектурные ошибки, которые за собой тянут огромный пласт проблем, который потом исправляет внутренняя команда?

[Ivanhoe]

Цитата:

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

Конечно слышал. Только кто скажет? Начальник отдела техподдержки не будет здороваться с ПМом? Так ПМ в командировке (на другом проекте и т.п.), ну "погорят" у него уши, т.к. много людей вспоминаю его.

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

Цитата:

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

что за гарантия на систему? это месяц оплаченного сапорта (который включается в договор и оплачивается)? а если архитектурные ошибки, которые за собой тянут огромный пласт проблем, который потом исправляет внутренняя команда?

Раньше было почти всегда так. Но в последнее время (пару лет как минимум) все больше клиентов требуют фиксированную в договоре гарантию. Например, полгода. Про архитектурные ошибки отдельный разговор. Бывает, что выбор Dynamics AX - самая большая архитектурная ошибка

[GBH]

Цитата:

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

что за гарантия на систему? это месяц оплаченного сапорта (который включается в договор и оплачивается)? а если архитектурные ошибки, которые за собой тянут огромный пласт проблем, который потом исправляет внутренняя команда?

А зачем с таким пластом ошибок вы подписывали акт о внедрении? Надо было при подписании акта сказать нам о них. Скромность в подписании акта не есть гуд.При подписании же проблем не было. Так что только можем эскалировать запрос в Майкрософт. Да вообще, акт подписан, всё в саппорт. Да, кстати, в договоре есть упоминания как решаем архитектурную ошибку? Да и с чего Вы взяли, что она архитектурная? Тут наш платиновый архитектор говорит, что это Ваша внутренняя команда так считает....бла-бла-бла....сроки идут, все пишут друг другу письма с обвинениями, эскалированием и в итоге, по гарантии внутренний отдел клиента (хорошо если он есть и вменяемый) решает её. А дальше уже другой клиент пишет письма по гарантии, причем, возможно, даже по одной и той же. Как говорится, поддержка версий интегратором. Только вот патчи выборочно, тем кто нашел ошибку.

[GBH]

Цитата:

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

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

Хм, подписание акта внедрения не является выходом клиента на нормальный режим работы?
Иван, про твою компанию я сказать ничего не могу, к сожалению, т.к. именно с саппортом не сталкивался. Есть знакомый, который всё очень хотел соскочить с вашего саппорта (год 2010 был), но по ходу дела до сих пор соскакивают.

Цитата:

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

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

Полгода - это доработок на (6 * кол-во рабочих часов в месяц) часов? Что-то не верю. По часам, максимум 200.

[Ivanhoe]

Цитата:

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

Полгода - это доработок на (6 * кол-во рабочих часов в месяц) часов? Что-то не верю. По часам, максимум 200.

Это расчет если все это время исправлялись ошибки?
В договоре пишется срок, в течении которого ошибки системы исправляются бесплатно. Хоть это одна ошибка за весь срок, хоть 150. Понятно, что давать такую гарантию не хочется, но что делать

P.S. Кстати, про гарантию на АС даже в ГОСТах пишут, минимальный срок - 18 месяцев.

[BOAL]

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

[GBH]

Цитата:

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

Это расчет если все это время исправлялись ошибки?
В договоре пишется срок, в течении которого ошибки системы исправляются бесплатно. Хоть это одна ошибка за весь срок, хоть 150. Понятно, что давать такую гарантию не хочется, но что делать

Что-то в реале такого не встречал, наверно, к сожалению, т.к. , может быть, изменил свою точку зрения. Чтобы вот просто ,после внедрения, позвонил клиент , сообщили об ошибке и все сразу кинулись её исправлять. Именно исправлять, а не лепить заплатку, чтобы закрыть конкретный запрос. Фантастика. Я такое только на пресейлах слышу.
Встречал именно то, что пишет BOAL,т.е. багфикс критических ошибок

[Konstantin Katsovich]

Цитата:

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

Встречал именно то, что пишет BOAL,т.е. багфикс критических ошибок

А как и кем это определяется?

Спасибо

[BOAL]

Цитата:

Сообщение от Konstantin Katsovich

А как и кем это определяется?

Спасибо

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

Потому

Цитата:

Хоть это одна ошибка за весь срок, хоть 150. Понятно, что давать такую гарантию не хочется, но что делать

верно
У нас именно это и есть.
Баги могут быть 1 в мес или 10 в день, как повезет.
Важно, что если внедрение все же шло, как надо, то баги все ж конечны, в отработанных частях система работает стабильно.

[Konstantin Katsovich]

Цитата:

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

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

Я так и думал.

It's not a bug - it's an undocumented feature.

[ice]

Цитата:

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

А зачем с таким пластом ошибок вы подписывали акт о внедрении? Надо было при подписании акта сказать нам о них. Скромность в подписании акта не есть гуд.При подписании же проблем не было. Так что только можем эскалировать запрос в Майкрософт. Да вообще, акт подписан, всё в саппорт. Да, кстати, в договоре есть упоминания как решаем архитектурную ошибку? Да и с чего Вы взяли, что она архитектурная? Тут наш платиновый архитектор говорит, что это Ваша внутренняя команда так считает....бла-бла-бла....сроки идут, все пишут друг другу письма с обвинениями, эскалированием и в итоге, по гарантии внутренний отдел клиента (хорошо если он есть и вменяемый) решает её. А дальше уже другой клиент пишет письма по гарантии, причем, возможно, даже по одной и той же. Как говорится, поддержка версий интегратором. Только вот патчи выборочно, тем кто нашел ошибку.

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

[GBH]

Я это понял. Поэтому выше писал про то, как добавляют новые объекты, которые ,по своей сути, только решает тестовый пример. :-)

[niksen]

Цитата:

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

Я это понял. Поэтому выше писал про то, как добавляют новые объекты, которые ,по своей сути, только решает тестовый пример. :-)

а как же нормальное тестирование? или опять же деньги экономят?

[kornix]

Цитата:

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

а как же нормальное тестирование? или опять же деньги экономят?

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

[BOAL]

Цитата:

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

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

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

[ice]

Цитата:

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

Иногда спор может занимать больше времени, чем сама работа, соотв. проще плюнуть и сделать

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

[Ivanhoe]

Цитата:

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

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

Поделитесь вашей статистикой, пожалуйста, сколько клиентов (проектов) завершилось по указанному вами сценарию? Если озвучите конкретные компании (клиент, партнер) было бы вообще супер

P.S. думаю, стоит выделить последние обсуждения в отдельную тему "Качество внедрения и поддержки" или как-то еще

[2A]

Цитата:

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

а как же нормальное тестирование? или опять же деньги экономят?

Тестирование не только задача внедренца.
А так - да, Заказчик часто сам экономит на качественной и длительной опытной эксплуатации.