Мне кажется, что все перечисленные в статье действия позволяют в том числе защитить интересы заказчика. Они позволяют определить ключевые требования к экспертизе технической поддержки, параметры нагрузки на службу технической поддержки и реально необходимый SLA. Заказчик, который сам отлично знает своё ТЗ и работу подрядчика в рамках его реализации, уже «вооружен». Кроме того, подробные договора и регламенты, RACI матрицы, которые мы разрабатываем с заказчиком, позволяют самостоятельно свести к нулю площадь «серых» зон неопределенности. В целом, я могу порекомендовать всем техническим экспертам заказчиков плотнее работать с отделами закупок. Чаще всего закупки и финансистам нужна не столько абсолютно минимальная цена, сколько адекватная прозрачная система выбора поставщика услуги. Система, которая не сводится к персональной личной оценке эксперта.
По поводу второго вопроса. По нашему опыту, именно непрозрачность является основным блокирующим фактором, который мешает заказчику сохранять свою независимость. Непрозрачность статистики исполнения, недокументированый объем дополнительных услуг (часто фактическое оказание других услуг по отношению к заключённому договору), недокументированная разработка ИТ систем для заказчика силами подрядчика. Это серьезная ловушка, ее можно избежать, но нужно понимать, что по-настоящему защитить себя от зависимости может только сам заказчик. Для этого он должен поддерживать высокий уровень технической экспертизы. Необходимо управление качеством обслуживания, стратегическое понимание необходимых изменений. Со своей стороны подрядчик может сделать достаточно просто формулируемый максимум для поддержки в заказчике технической независимости. В его силах максимально подробно информировать заказчика обо всех аспектах реализации техподдержки. Например, предоставлять необходимую и полную отчётность, организовывать хранение и доступ к исходным данным service desk, предоставлять аналитические средства, которые могут эти данные интерпретировать.
Добрый день! Постарался развернуто сформулировать ответы.
Мне кажется, что все перечисленные в статье действия позволяют в том числе защитить интересы заказчика. Они позволяют определить ключевые требования к экспертизе технической поддержки, параметры нагрузки на службу технической поддержки и реально необходимый SLA. Заказчик, который сам отлично знает своё ТЗ и работу подрядчика в рамках его реализации, уже «вооружен». Кроме того, подробные договора и регламенты, RACI матрицы, которые мы разрабатываем с заказчиком, позволяют самостоятельно свести к нулю площадь «серых» зон неопределенности. В целом, я могу порекомендовать всем техническим экспертам заказчиков плотнее работать с отделами закупок. Чаще всего закупки и финансистам нужна не столько абсолютно минимальная цена, сколько адекватная прозрачная система выбора поставщика услуги. Система, которая не сводится к персональной личной оценке эксперта.
По поводу второго вопроса. По нашему опыту, именно непрозрачность является основным блокирующим фактором, который мешает заказчику сохранять свою независимость. Непрозрачность статистики исполнения, недокументированый объем дополнительных услуг (часто фактическое оказание других услуг по отношению к заключённому договору), недокументированная разработка ИТ систем для заказчика силами подрядчика. Это серьезная ловушка, ее можно избежать, но нужно понимать, что по-настоящему защитить себя от зависимости может только сам заказчик. Для этого он должен поддерживать высокий уровень технической экспертизы. Необходимо управление качеством обслуживания, стратегическое понимание необходимых изменений. Со своей стороны подрядчик может сделать достаточно просто формулируемый максимум для поддержки в заказчике технической независимости. В его силах максимально подробно информировать заказчика обо всех аспектах реализации техподдержки. Например, предоставлять необходимую и полную отчётность, организовывать хранение и доступ к исходным данным service desk, предоставлять аналитические средства, которые могут эти данные интерпретировать.