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

[ice]

Цитата:

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

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

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

[Ivanhoe]

Цитата:

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

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

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

Цитата:

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

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

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

[GBH]

Цитата:

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

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

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

Цитата:

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

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

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

[Ivanhoe]

Цитата:

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

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

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

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

[GBH]

Цитата:

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

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

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

[Konstantin Katsovich]

Цитата:

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

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

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

Спасибо

[BOAL]

Цитата:

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

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

Спасибо

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

Потому

Цитата:

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

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

[BOAL]

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

[GBH]

Цитата:

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

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

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

[ice]

Цитата:

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

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

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

[GBH]

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

[niksen]

Цитата:

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

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

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

[kornix]

Цитата:

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

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

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

[2A]

Цитата:

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

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

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

[BOAL]

Цитата:

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

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

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

[ice]

Цитата:

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

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

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

[Ivanhoe]

Цитата:

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

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

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

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

[driller]

Цитата:

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

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

Ох и скользкую вы выбрали дорожку, может быть вы тоже в противовес, приведете список компаний и их консультантов/разработчиков, только уже ушедших с поддержки, но которые будут с гордостью говорить о сотрудничестве вами?
Сотрудничестве в котором не было утомительных и долгих переписок, а с вашей стороны не было просто отписок, вместо решений вопросов.
Местные консультанты, были всегда спокойны, зная что за ними стоит гигант, с колоссальным опытом решение сложным проблем.
В систему клиента никогда не попадал код стажёров, потому как всегда проходил жёсткий контроль вашими ведущими специалистами.
И конечно архитектура вашего решения просто кристальна и безупречна.
Всё так, вы идеальная компания?
Может стоить прекратить это взаимное швыряние камней, напомню, ведь вернулись к этой теме с мягкой пропаганды безупречности и профессиональности консалтов.
Плохими или хорошими специалистами могут быть и те и другие, к чему все эти холивары?

[ice]

Цитата:

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

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

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

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

[BOAL]

Цитата:

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

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

Доведение до ума внедрения - это по-любому некое ненулевое время. И делается ли оно поддержкой или внутренней командой - это уже вопрос отношений\удобства\экономии.
Даже АХ (или взять другую ИС) без модификаций все равно нужно тюнинговать\суппортить после запуска, или ОЭ должна длиться несколько месяцев, чтоб получить обратную связь.

Суровое ИМХО - внедрение АХ чем-то похоже на ММО игру, с релизом которой все только начинается развиваться и разрабатываться.
АХ берут часто именно на вырост, да, закрыть дыру текущих потребностей, но и для последующего развития (под изменения в бизнесе) своими\чужими силами.

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

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