Необходимо мне заключить договор на поддержку с одной софтверной конторой, которая для нас написала софт. Хочу вставить в договор немного от SLA... Понимаю, что ни один разработчик не подпишется под требованием решить критичный вопрос в срок один-два-три часа, т.к. задача может оказаться труднорешаемой. Но и вы меня поймите, заключая договор на поддержку не хочется, чтобы компания откровенно клала на нас, когда у нас будут проблемы (а в итоге виноват буду я).
Так вот, как можно решить эту неразрешимость? Ведь наверняка заключали похожие договора. Мне желательно именно договора, где ответственность разработчика больше прописана, т.к. здесь я выступаю со стороны пользователей.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Коллеги, приветствую!
N_C>Необходимо мне заключить договор на поддержку с одной софтверной конторой, которая для нас написала софт. Хочу вставить в договор немного от SLA... Понимаю, что ни один разработчик не подпишется под требованием решить критичный вопрос в срок один-два-три часа, т.к. задача может оказаться труднорешаемой. Но и вы меня поймите, заключая договор на поддержку не хочется, чтобы компания откровенно клала на нас, когда у нас будут проблемы (а в итоге виноват буду я).
N_C>Так вот, как можно решить эту неразрешимость? Ведь наверняка заключали похожие договора. Мне желательно именно договора, где ответственность разработчика больше прописана, т.к. здесь я выступаю со стороны пользователей.
N_C>С уважением, N_C> Николай
Обычно требуют образец стандартного SLA от компании, оказывающей поддержку. Поймите, если в компании не установлены и не работают процессы, обеспечивающие ваши требования, то в случае проблем на вашей стороне, их сторона измениться в один день физически не сможет. И как со своим уставом нет нужды лезть в чужой монастырь, ваш текст договора — только повод для будущих ссор и судебных разборок. А оно вам надо?
Короче, вам нужно не красивую фразу где-то выкрать, и зашить в договор мелким текстом, а сесть за стол переговоров, и по душам обсудить этот вопрос с вашим вендором. При чем, порядок дня этого митинга предложите свой, а слово дайте им первым.
Вы и ваша компания безусловно останетесь в выигрыше при таком подходе.
Удачи Вам!
Д>Обычно требуют образец стандартного SLA от компании, оказывающей поддержку.
Не... Там есть SLA. Они нам его прислали. Но он стандартный — время реакции на проблему. А время реакции — это время регистрации проблемы. И все. Мне нужно быть уверенным, что если у нас система встала, то люди работают над проблемой, а не филонят. А подозрения такие есть. Вот я и думаю, какую фразу вставить в договор, чтобы хоть как-то мотивировать контрагента на решение проблемы. Может пеню за каждый час простоя? Как обычно решают эту задачку?
Nikolay_Ch пишет: > Не... Там есть SLA. Они нам его прислали. Но он стандартный — время > реакции на проблему. А время реакции — это время регистрации проблемы. И > все. Мне нужно быть уверенным, что если у нас система встала, то люди > работают над проблемой, а не филонят. А подозрения такие есть. Вот я и > думаю, какую фразу вставить в договор, чтобы хоть как-то мотивировать > контрагента на решение проблемы. Может пеню за каждый час простоя? Как > обычно решают эту задачку?
Эту задачу обычно решают надеждой вашего поставщика на долговременное и
прибыльное для него сотрудничество (не обязательно только с вами,
возможно он рассчитывает на референс). Если они подпишут договор с
"пеней за каждый час простоя" (простоя чего, кстати?) — это практически
на 100% указание на то, что они не придают договору никакого значения
вообще.
Если есть подозрения — озвучьте их своему начальству, поищите альтернативы.
Здравствуйте, Nikolay_Ch, Вы писали:
Д>>Обычно требуют образец стандартного SLA от компании, оказывающей поддержку. N_C>Не... Там есть SLA. Они нам его прислали. Но он стандартный — время реакции на проблему. А время реакции — это время регистрации проблемы. И все. Мне нужно быть уверенным, что если у нас система встала, то люди работают над проблемой, а не филонят. А подозрения такие есть. Вот я и думаю, какую фразу вставить в договор, чтобы хоть как-то мотивировать контрагента на решение проблемы. Может пеню за каждый час простоя? Как обычно решают эту задачку?
1) присваиваете _приоритет_ вопросу.
2) его можно изменить с обоих сторон. бывают конфликты.
3) в зависимости от приоритера — время реакции и фикса.
4) в зависимости от времени фикса (или просрочки!) — деньги.
2.1) приоритет может быть изменен любой стороной. вы считаете, что проблема важная, и должна быть решена сейчас. мы считаем, что проблема яйца выеденного не стоит, и может быть решена через неделю. ставьте свое время, и спрашивайте. мы поставим свое, и ответим.
если через неделю(!) проблема не будет решена, вы штрафуете нас по _нашим_ оценкам.
если вы напряжетесь, и позвоните пм-у, и он _с_нашей_ стороны подтвердит, что приоритет высокий — будете штрафовать завтра.
а есть еще градация сложности.
типа:
приоритет — высокий, сложность — высокая. время на фикс — 3 дня.
приоритет — высокий, сложность — низкая. время на фикс — 3 часа.
приоритет — средний, сложность — высокая. время на фикс — неделя.
приоритет — низкий, сложность — высокая. время на фикс — не определено!
в таком раскладе приоритет ставите вы, а сложность — мы. у нас все будут — суперсложные изначально.
как решать — ...ну я знаю путь, но как разработчик — не скажу.
Здравствуйте, hrensgory, Вы писали:
H>... Если они подпишут договор с H>"пеней за каждый час простоя" (простоя чего, кстати?) — это практически H>на 100% указание на то, что они не придают договору никакого значения вообще.
Простоя системы... Т.е. время, пока система не работает — но это аварийная ситуация и она самая критичная. А почему не придают? Ведь это живые деньги уходят от них?
H>Если есть подозрения — озвучьте их своему начальству, поищите альтернативы.
Позиция руководства — ответственность твоя, тебе и решать.
Nikolay_Ch пишет:
> Простоя системы... Т.е. время, пока система не работает — но это > аварийная ситуация и она самая критичная. А почему не придают? Ведь это > живые деньги уходят от них?
Я имел в виду что они не заплатят при любом развитии событий. По крайней
мере никогда не слышал о компании, которая бы выполнила подобные
обязательства. Почитайте EULA на любой софт — предоставляется as is,
производитель ответственности не несёт.
К тому же, возможно я не до конца понимаю вашу ситуацию, но что значит
"система не работает"? Вообще не работает, BSOD? Кто это зафиксирует,
ведь в этом случае видимо потребуется видимо и согласие разработчика с
этим суждением.
> H>Если есть подозрения — озвучьте их своему начальству, поищите > альтернативы. > Позиция руководства — ответственность твоя, тебе и решать.
А альтернатив никаких нету? В смысле в другом месте саппорт заказать.
Здравствуйте, hrensgory, Вы писали:
H>А альтернатив никаких нету? В смысле в другом месте саппорт заказать.
вот-вот... вот... ВОТ!!!! вот она, золотая идея.
call-цент + скользящий график для толпы студентов.
и все. мировое доминирование индии на рынке саппорта будет сломлено.
бизнес-схему и образец договора обсудили выше. во
bastrakov пишет: > Здравствуйте, hrensgory, Вы писали: > > H>А альтернатив никаких нету? В смысле в другом месте саппорт заказать. > > вот-вот... вот... ВОТ!!!! вот она, золотая идея. > call-цент + скользящий график для толпы студентов.
В форуме про работу недавно было какое-то предложение в саппорт за 3000
руб./мес сутки через двое. Так что похоже индусы уже трепещут.
Здравствуйте, hrensgory, Вы писали:
H>Я имел в виду что они не заплатят при любом развитии событий. По крайней H>мере никогда не слышал о компании, которая бы выполнила подобные H>обязательства. Почитайте EULA на любой софт — предоставляется as is, H>производитель ответственности не несёт.
Речь идет о разработке заказного софта, от которого зависят наши БП. Никто не собирается возмещать убытки, понесенные бизнесом, но должно быть какое-то условие, которое заставит разработчика бегать в случае, когда его софт банально лежит.
H>К тому же, возможно я не до конца понимаю вашу ситуацию, но что значит H>"система не работает"? Вообще не работает, BSOD? Кто это зафиксирует, H>ведь в этом случае видимо потребуется видимо и согласие разработчика с H>этим суждением.
Да, вообще не работает. Т.е. мы, например иконку щелкаем, а в ответ — "пошел нафих"...
>> H>Если есть подозрения — озвучьте их своему начальству, поищите >> альтернативы. >> Позиция руководства — ответственность твоя, тебе и решать. H>А альтернатив никаких нету? В смысле в другом месте саппорт заказать.
Альтернативы всегда есть. Меня в этом плане больше интересует именно какое условие заложить в договор. Бить то в случае простоя будут меня в первую очередь.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>.... но должно быть какое-то условие, которое заставит разработчика бегать в случае, когда его софт банально лежит. N_C>Да, вообще не работает. Т.е. мы, например иконку щелкаем, а в ответ — "пошел нафих"... N_C>Меня в этом плане больше интересует именно какое условие заложить в договор. Бить то в случае простоя будут меня в первую очередь.
Хочешь изобрести велосипед? Ей-ей, не стоит..... ГОСТы не зря писаны.
Здесь не "условие в договор" надо закладывать, а — адекватно организовать процесс разработки со стороны заказчика. Например:
1. разбить работу на этапы. Один из этапов — предварительные испытания этого самого заказного софта, причем с обязательным участием представителя заказчика (не путать с ПЗ ). Программу и методику разрабатывает исполнитель, согласовывает заказчик (то бишь вы). Протокол этих испытаний утверждается с двух сторон.
2. при удовлетворительных результатах испытаний начинается следующий этап — тестовая эксплуатация на вашей площадке, например, в течение месяца (ну или сколько там надо из разумных соображений). Если при этом выявляются блокирующие работу баги, то переходим к п.1, если некритичные — исполнитель их исправляет в рабочем порядке.
3. при удовлетворительных результатах тестовой эксплуатации и закрытых некритичных багах — актируете (с двух сторон) результаты тестовой эксплуатации и переходите к приемосдаточным испытаниям. Программа и методика ПСИ — тоже разрабатываются исполнителем и согласовываются вами.
4. по результатам ПСИ принимаете решение.... Если все более-менее удовлетворительно — принимаете ПО в боевую эксплуатацию.
Такая методика в некоторой степени гарантирует от варианта, "когда его софт банально лежит". Где-то так.
По удовлетворительному результату п.1 платите исполнителю аванс — в размере порядка 30%. А окончательный расчет — только по результату п.4.
Nikolay_Ch пишет: > > H>К тому же, возможно я не до конца понимаю вашу ситуацию, но что значит > H>"система не работает"? Вообще не работает, BSOD? Кто это зафиксирует, > H>ведь в этом случае видимо потребуется видимо и согласие разработчика с > H>этим суждением. > Да, вообще не работает. Т.е. мы, например иконку щелкаем, а в ответ — > "пошел нафих"...
Абстрагируемся от того факта, что "пошёл..." может вызываться не
обязательно ПО, а к примеру недоступностью БД, сетевыми проблемами или
(если это декстопное приложение) совместимостью с многочисленными
версиями Windows, Office и т.п.
Интересно другое — а с БП вашими при этом что будет, стоять будут?
Допустим разработчик "забегал", но ПО по-прежнему не работает. Ваша
физическая безопасность, как наиболее досягаемого, может оказаться под
угрозой
Тут уже посоветовали — проведите тестовую эксплуатацию, приёмо-сдаточные
испытания. По итогам решайте.
--
WBR,
Serge.
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Коллеги, приветствую!
N_C>Необходимо мне заключить договор на поддержку с одной софтверной конторой, которая для нас написала софт. Хочу вставить в договор немного от SLA... Понимаю, что ни один разработчик не подпишется под требованием решить критичный вопрос в срок один-два-три часа, т.к. задача может оказаться труднорешаемой. Но и вы меня поймите, заключая договор на поддержку не хочется, чтобы компания откровенно клала на нас, когда у нас будут проблемы (а в итоге виноват буду я).
N_C>Так вот, как можно решить эту неразрешимость? Ведь наверняка заключали похожие договора. Мне желательно именно договора, где ответственность разработчика больше прописана, т.к. здесь я выступаю со стороны пользователей.
Оговаривается только гарантированное время реакции на проблему в зависимости от критичности (обычно 24 часа для критических проблем), что вы выделяете специалиста на нее, но не то, что она обязательно будет решена. Плюс, конечно, даются точные определения критичных и прочих проблем.
Это максимум, что можно требовать. Да, кроме того, такое условие вообще-то принято отдельно оплачивать по фиксированному тарифу, не зависящему от объема работы и деФектов. Это примерно как страховая медицина.
V_S>Хочешь изобрести велосипед? Ей-ей, не стоит..... ГОСТы не зря писаны.
ГОСТ на сопровождение? Это какой? У меня фаза разработки и приемки закончилась — теперь поддержка.
H>Абстрагируемся от того факта, что "пошёл..." может вызываться не H>обязательно ПО, а к примеру недоступностью БД, сетевыми проблемами или H>(если это декстопное приложение) совместимостью с многочисленными H>версиями Windows, Office и т.п.
Нам поставщик поставил сервер и ПО — вот пусть он и решает эти проблемы.
H>Тут уже посоветовали — проведите тестовую эксплуатацию, приёмо-сдаточные H>испытания. По итогам решайте.
это поддержка — все, что Вы описали уже в прошлом.
G>Это максимум, что можно требовать. Да, кроме того, такое условие вообще-то принято отдельно оплачивать по фиксированному тарифу, не зависящему от объема работы и деФектов. Это примерно как страховая медицина.
Не вопрос — оплатим. Просто мне надо быть уверенным, что поставщик не начнет динамить с исправлением ошибки. Сейчас у него эта тенденция наблюдается. Думаю, что вставим в договор пеню за реализацию задач (от момента постановки, до момента передачи (или до момента приемки) исправления заказчику) и на этом завершим.
Здравствуйте, Nikolay_Ch, Вы писали:
G>>Это максимум, что можно требовать. Да, кроме того, такое условие вообще-то принято отдельно оплачивать по фиксированному тарифу, не зависящему от объема работы и деФектов. Это примерно как страховая медицина. N_C>Не вопрос — оплатим. Просто мне надо быть уверенным, что поставщик не начнет динамить с исправлением ошибки. Сейчас у него эта тенденция наблюдается. Думаю, что вставим в договор пеню за реализацию задач (от момента постановки, до момента передачи (или до момента приемки) исправления заказчику) и на этом завершим.
Пеня за превышение сроков не очень хороша на мой взгляд, так как штрафует также за чрезмерно оптимистические оценки сроков (если их дает Исполнитель, и они утверждаются Заказчиком), или за ошибку оценки сроков Заказчиком (если их делает Заказчик — на такое ни один исполнитель не пойдет в здравом уме, кстати), или за возникшие по ходу работ непредвиденные обстоятельства (риски).
Если речь идет о дефектах — то и само их появление, и проблемы их исправления (сроки которого непредсказуемы по природе), — сплошные непредвиденный обстоятельства. Я не понимаю, как можно требовать сроков их разрешения, и брать за их превышения пени. Можно требовать _реакции_ на проблемы, но _гарантий_ их исправления в детерминированный срок вам никто не даст (разве что идиот, который ничего не соображает).
Я, как Заказчик, вообще не пользуюсь пенями за срыв сроков (сейчас я выступаю также со стороны Заказчика, мы активно субподрядим), ибо считаю их скорее вредными, чем полезными, в силу выше перечисленного, плюс — еще и социальный аспект этих пень — люди не начинают быстрее думать когда их наказывают, зато стремятся избежать наказания и вас обмануть. Возможно, это имело бы смысл, если есть жесткий внешний дедлайн для Заказчика, перейдя который он сам начнет терять деньги и штрафоваться. Но все равно, пени — не решение проблемы, это лекарство симптома. Решение проблемы — нормальный Исполнитель, и нормальные отношения с ним, чему пени не способствуют.
V_S>1. разбить работу на этапы. Один из этапов — предварительные испытания этого самого заказного софта, причем с обязательным участием представителя заказчика (не путать с ПЗ ).
Это почему же "не путать"? Великие и страшные ПЗ именно для этого и существуют
H>>Тут уже посоветовали — проведите тестовую эксплуатацию, приёмо-сдаточные H>>испытания. По итогам решайте. N_C>это поддержка — все, что Вы описали уже в прошлом.
V_S>круг обязанностей (не прав, а именно — обязанностей) великих и страшных ПЗ только участием в испытаниях и приемке не ограничен....
Вот будешь ещё рассказывать военпреду про права и обязанности ПЗ. Ага.
Испытания и приёмка — основные обязанности. Контроль техпроцессов и согласование документации — это некоторые побочные функции.
Или ты подразумеваешь, что твой "представитель" — может быть только тестером и не более?
Здравствуйте, VGn, Вы писали:
VGn>Значит сами лопухнулись.
Нормально. У Вас видимо проекты после ПСИ, ошибок не содержат. Или простой системы в день проблем не принесет.
Давайте говорить по существу — потому, что такого рода вопросы рано или поздно всем приходится решать.
Здравствуйте, Gaperton, Вы писали:
G>Если речь идет о дефектах — то и само их появление, и проблемы их исправления (сроки которого непредсказуемы по природе), — сплошные непредвиденный обстоятельства. Я не понимаю, как можно требовать сроков их разрешения, и брать за их превышения пени. Можно требовать _реакции_ на проблемы, но _гарантий_ их исправления в детерминированный срок вам никто не даст (разве что идиот, который ничего не соображает).
В договоре уже прописано время реакции. А пеню (как штраф от времени реакции до времени сдачи заказчику), кстати, предлагает поставщик услуг самостоятельно. Просто я не знаю, как с этим быть — пеня небольшая — стоит ли ее увеличивать или оставить как есть? Мы сейчас работаем с этим поставщиком и он выполняет свои обязанности не совсем быстро и качественно, вот я и думал, что договором можно будет заставить их бегать быстрее.
G>...Возможно, это имело бы смысл, если есть жесткий внешний дедлайн для Заказчика, перейдя который он сам начнет терять деньги и штрафоваться. Но все равно, пени — не решение проблемы, это лекарство симптома.
В том то и дело, что по сути у нас почти интернет-магазин, простои которого оборачиваются потерей заказов, недозагрузкой складов и простоем персонала...
G> Решение проблемы — нормальный Исполнитель, и нормальные отношения с ним, чему пени не способствуют.
Да кто же спорит...
VGn>>Значит сами лопухнулись. N_C>Нормально. У Вас видимо проекты после ПСИ, ошибок не содержат. Или простой системы в день проблем не принесет. N_C>Давайте говорить по существу — потому, что такого рода вопросы рано или поздно всем приходится решать.
По существу имхо бОльшая часть российских IT-фирм 80% ресурсов тратит на исправление собственных ошибок. А тут уж каждый выкручивается, как может.
хм, навряд ли.... Gaperton ведь абсолютно точно написал — большая пеня приведет не к тому, что исполнитель будет заинтересован в решении ваших проблем по существу, а — к тому, что он будет прежде всего думать о том, как избежать наказания, в том числе — обманывая вас. Оно вам надо?
Имхо подобного рода "кнут" малоэффективен, ибо плохо мотивирует, зато хорошо демотивирует. Подумай, не сможешь ли ты придумать для исполнителя какой-то "пряник"?
Nikolay_Ch пишет: > > Мы сейчас работаем с этим > поставщиком и он выполняет свои обязанности не совсем быстро и > качественно, вот я и думал, что договором можно будет заставить их > бегать быстрее.
Как известно, чтобы корова меньше ела и давала больше молока её нужно
меньше кормить и больше доить
Если "пеня" намного меньше месячных платежей, то возможно это чисто
психологический трюк. Она способна избавить поставщика от нудных
приставаний заказчика в стиле "ну почему до сих пор не готово, мы же
платим вам деньги за обслуживание". Какие-то деньги они всё равно
получат, а работать будет намного спокойнее.
Если же под действием "пени" поставщик может уйти в минус — скорее всего
он либо не настроен выполнять этот договор либо находится в настолько
безвыходном положении, что вам всё равно скоро придётся искать другого.
Здравствуйте, Nikolay_Ch, Вы писали:
G>>...Возможно, это имело бы смысл, если есть жесткий внешний дедлайн для Заказчика, перейдя который он сам начнет терять деньги и штрафоваться. Но все равно, пени — не решение проблемы, это лекарство симптома. N_C>В том то и дело, что по сути у нас почти интернет-магазин, простои которого оборачиваются потерей заказов, недозагрузкой складов и простоем персонала...
G>> Решение проблемы — нормальный Исполнитель, и нормальные отношения с ним, чему пени не способствуют. N_C>Да кто же спорит...
Мне кажется, что заключение SLA в данном случае ни к чему хорошему привести не может в принципе. Исполнитель, судя по вашим письмам — компания, ориентированная на разработку. Вы же, путем подписания SLA,пытаетесь изменить модель бизнеса Исполнителя, добавив в нее организацию службы поддержки, характерную для компаний, делающих бизнес на розничных продажах. Вопрос — за чей счет будет организовываться эта служба поддержки? Если Вы думаете, что за дополнительные 100 000р в договоре Исполнитель будет честно держать для Вас "под парами" в течение года разработчика — вряд ли. А на бОльшую сумму, боюсь, не пойдете Вы.
Чтобы поставить себя на место Исполнителя — представьте, что один (из сотни) заказчик, желающий купить у Вас некоторую уникальную железку, требует, чтобы вы организовали у себя службу гарантийного ремонта. Вы формально можете подписать бумаги о том, что ответственность за ремонт лежит на Вас, но станете ли Вы реально организовать у себя эту службу?
Теперь идем дальше и проиграем возможную ситуацию. Представим, что Исполнитель (по пьянке, или прижатый к стене Вашими неопровержимыми аргументами) подписал SLA, в котором прописано 10000р за час простоя по причине сбоя программы. Представим, что этот сбой случился, а Исполнитель вот уже неделю как на Ваши запросы отвечает формально "проблема в том, что вы неправильно работаете с программой", "у нас программист, который это писал, уехал в отпуск (заболел, уволился, умер)". Вы уверены, что, подав в суд, Вы сможете доказать судье, что сбой произошел по вине разработчика, а не вследствие, например, нелегально установленного у Вас стороннего программного обеспечения или вирусов — что обязательно будет утверждать разработчик? Судебное заседание ведь будет не одно, с интервалом в месяц, а Вы все это время будете терять деньги. Это я к тому, что подписание SLA даст вам ИЛЛЮЗИЮ защиты от сбоя программы, а не реальную защиту.
Что бы я посоветовал, исходя из опыта. Возможны такие варианты:
1. Договор уже подписан, разработка уже идет, деньги уже выплачены и отказ от программы вызовет гнев Вашего руководства. В этом случае Вам придется организовывать собственную службу поддержки программы, как ни печально с финансовой точки зрения это звучит. Нанимаете человека (или берете одного из своих) и заключаете договор на его углубленное обучение в компании-разработчике. Учить его там будут на совесть, потому что выучив его плохо, разработчик обречет себя на постоянные звонки от него "Помогите, я вот не знаю, что делать". И ваша компания после обучения получит время реакции на проблему не час, а несколько минут (по статистике, 95% проблем работы с любой программой устраняются за пять минут и в основном вызваны плохой подготовкой человека, работающего с ней). При возникновении действительно крупной проблемы этот человек сможет, по крайней мере, квалифицированно задать вопрос разработчикам.
Да, это дорого — держать человека, но если качество работы программы влияет на стабильность Вашего бизнеса — это надо делать.
2. Договор еще не подписан. В этом случае проще купить готовое ПО для интернет-магазина у крупной розничной компании, в которой уже есть служба поддержки 24х7 (например, 1С-Битрикс) и заплатить за кастомизацию софта под Ваши нужды. Выйдет дешевле в конечном итоге.
А можно, как советовали выше, оставить все, как есть и надеяться, что добрые отношения с Исполнителем сыграют свою роль при возникновении проблем. Можете даже подписать формальный SLA. Большинство российских компаний выбирает, увы, именно этот путь.
А подозрения такие есть. Вот я и думаю, какую фразу вставить в договор, чтобы хоть как-то мотивировать контрагента на решение проблемы. Может пеню за каждый час простоя? Как обычно решают эту задачку?
вот она, золотая идея. 
во
У Вас видимо проекты после ПСИ, ошибок не содержат. Или простой системы в день проблем не принесет.
