Портал №1 по управлению цифровыми
и информационными технологиями

Вопрос из зала: штрафы за неработающее ПО

Константин задаёт вопрос:


Red Light ViolationЗдравствуйте, коллеги.

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

Может, есть какие-нибудь типовые соглашения о поддержке, где прописаны нормальные условия а не фантастические?

За что надо штрафовать, за что нет?


Экспертам по штрафам предлагается высказываться в комментариях.

«VAP: Экономика и финансы ИТ»
Бюджетирование, аллокация, расчёт себестоимости, планирование ресурсов

Комментариев: 5

  • Oleksandr Bodryk

    Знакомая ситуация, обычно в таком случае те же метрики (в Вашем случае полчаса до разрешения инцидента) выставляются другим подразделениям, например инфраструктуре (называются они “транзитными”). Т.к. в Вашем случае подразделения заказчика с Вами OLA (типовый документ ITIL как раз на такой случай) вряд ли подпишут, то можно попытаться сделать оговорку “Если нарушение в работе ПО было диагностировано Исполнителем но не устранено Заказчиком в срок то штраф не взымается”. Иначе есть только совсем экзотический вариант – на основании статистики инцидентов попытаться застраховать риск штрафа (кстати, кто-нибудь слышал о таких продвинутых страховщиках?). Это все что остается делать кроме отказа от подписания контракта.

  • Pavel Solopov

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

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

    Но если у вас ситуация: “Нам важен заказчик, мы не можем от него отказаться, а он не идёт на диалог”, то все эти наши дискуссии пустое. Думайте о том, как диверсифицировать бизнес.

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

    Хостер 1Gb.ru декларирует uptime 99,5%, а свою ответственность формулирует так:

    “Ответственность исполнителя:
    – В том случае, если качественное оказание услуг в соответствии с указанными правилами в течение месяца не соблюдалось, на лицевой счет заказчика начисляется сумма компенсации, равная стоимости месячного обслуживания.
    – Зачисление суммы компенсации на баланс клиента производится в срок до 3х рабочих дней с начала месяца, следующего за тем, в котором произошли сбои.
    – Сумму компенсации можно использовать только для оплаты услуг хостинга. Возврат этой суммы клиенту не производится.”

    А товарищи из ru-hoster, если я правильно понимаю, ввели некий SLA как стандарт на всех тарифных планах, заявляя uptime на уровне 99,9%, отвечая за это так:

    “Размер компенсации за каждый дополнительный 1% (7 ч. 12 мин.) простоя – 5 дней бесплатно к услуге”

    Примеры с хостингом намного проще с точки зрения инфраструктуры – всей ей владеет и управляет провайдер (если он не реселлер, конечно). И даже в этом случае на SLA идут немногие, а штрафы сводятся к зачёту суммы в счёт последующих платежей.

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

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

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

    Третий путь – ограничить в SLA ровно то, за что вы можете отвечать. Клиент сообщил вам о сбое, который не может решить сам? Гарантируйте ему время реакции и размер выделяемых на решение ваших ресурсов. Подпишитесь на штрафы, если время реакции нарушено или у вас нет в этот момент нужного числа нужных специалистов, чтобы быстро заняться сбоем данного клиента.

    И ещё. Если ваш бизнес – сложные программные комплексы, то правда ли у клиента есть альтернатива, чтобы так выкручивать вам руки с этими штрафами? Есть ли у него другой поставщик аналогичного решения, на которое можно быстро и недорого перейти, да чтобы провайдер подписался на штрафы? Очень сомневаюсь.

  • RuMBa

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

    • Pavel Solopov

      Он ещё будет дороже на разработку ресурсно-сервисной модели и поддержания её в актуальном состоянии. дай бог, если эта модель не будет создавать больше работы для конфликтной комиссии, чем само ПО. 🙂


Добавить комментарий для Pavel SolopovОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM