Описание работ SAP (SOW): что в нём должно быть

Описание работ SAP (statement of work, SOW) это договорной документ, который говорит, что партнёр поставит, с какими трудозатратами, силами каких людей и как это может меняться. Он должен охватывать объём работ, подробные допущения и исключения, трудозатраты по фазам и ролям, результаты работ с критериями приёмки, поимённо названные ресурсы и управление изменениями.

Объём работ большинство SOW описывают достаточно хорошо. Клиенты часто упускают подробные допущения и исключения, а именно этот раздел определяет, сколько вы в итоге заплатите.

Эта статья часть моего руководства о том, как выбрать партнёра по внедрению SAP. SOW это последний шаг этого процесса, после RFP для партнёра SAP и устных презентаций. Разобранный пример проверки SOW до подписания есть в моём кейсе о переговорах по договору ERP.

Хороший SOW по SAP читается как руководство по эксплуатации программы. Любой человек на вашей стороне должен открыть его и ответить на три вопроса: что мы получаем, от чего это зависит и что происходит, когда что-то меняется.

Вот разделы, которые в нём нужны, и что идёт не так, когда какого-то нет:

Раздел	Что в нём должно быть	Что происходит, если он слабый
Объём работ	Процессы, модули, балансовые единицы, заводы, страны и пользователи в объёме работ	Каждый воркшоп заново открывает вопрос, что было включено
Допущения	Условия, от которых зависит цена, у каждого последствие на случай, если оно не подтвердится	Партнёр выставляет запросы на изменение, которые вы не можете оспорить
Исключения	Что партнёр делать не будет и кто делает это вместо него	Работа падает между вами и партнёром, и никто за неё не отвечает
Подход и фазы	Метод, план по фазам и контрольные точки качества	Нет согласованного момента, когда фаза считается завершённой
Трудозатраты	Оценка трудозатрат по фазам и ролям	Вы не можете понять, идёт ли расход ресурсов по плану
Результаты работ и приёмка	Названные документы и результаты, критерии приёмки, срок на подписание	Счета оплачиваются за незавершённую работу
Ресурсы	Поимённо названные ключевые люди, роли, загрузка и правила замены	Команда, которую вы видели на устной презентации, не та, что работает на проекте
Обязанности клиента	Что должны предоставить ваши люди и когда	Задержки по вашей вине превращаются в запросы на изменение от партнёра
Управление изменениями	Как изменение инициируется, оценивается, получает цену и утверждается	Запросы на изменение становятся вторым источником выручки
Управление программой	Управляющий комитет, отчётность, эскалация	Проблемы всплывают поздно, когда они уже дорогие

Опишите объём работ сами до запроса цен, чтобы партнёры оценивали ваш объём, а не свой собственный.

Именно этот раздел клиенты часто упускают. Без него цена опирается на условия, которые никто на вашей стороне не читал и не согласовывал.

Допущение это условие, на котором партнёр построил цену. Исключение это работа, которую партнёр вообще не оценивал. И то, и другое должно быть настолько конкретным, чтобы третья сторона могла проверить, выполнено ли оно.

Какие типы допущений прописать

У каждого допущения должно быть последствие. Формулировка «Если это не подтвердится, изменение проходит через управление изменениями с оценкой влияния» превращает допущение из украшения в инструмент контроля.

Вот категории, которые должен охватывать SOW по SAP:

1. Организационный объём. Количество балансовых единиц, заводов, сбытовых организаций, стран и юрлиц, которые покрывает цена.
2. Объём процессов. Бизнес-процессы в объёме работ, поимённо, и стандартные процессы SAP, которые партнёр ожидает, что вы примете.
3. Объём WRICEF. Количество процессов согласования, отчётов, интерфейсов, конвертаций, расширений и форм (workflows, reports, interfaces, conversions, enhancements and forms) по сложности. Бюджеты получают удар в фазе Explore по мере роста этого списка, поэтому базовое количество должно быть в договоре.
4. Данные. Объекты данных для миграции, объём истории, количество пробных загрузок и кто очищает данные.
5. Интеграции. Каждый интерфейс поимённо, с системой на другой стороне и тем, кто меняет эту систему.
6. Тестирование. Количество циклов тестирования, кто пишет сценарии, кто их выполняет и кто исправляет дефекты.
7. Доступность клиента. Кто из ваших людей нужен, на какую долю их времени и как быстро должны приниматься решения.
8. Среды и лицензии. Кто предоставляет системы, инструменты и доступ и к какому сроку.
9. Место работы и язык. Где работает команда, соотношение onshore и offshore, командировки, языки документации и обучения.
10. Обучение и гиперподдержка. Модель обучения, количество обученных тренеров, продолжительность гиперподдержки и критерии выхода из неё.

Базовое количество WRICEF важнее всего для бюджета. Учебные материалы самой SAP описывают фазу Explore как анализ fit-to-standard, в котором утверждённые дельта-требования добавляются в бэклог продукта для фазы Realize (SAP Learning). Каждое утверждённое дельта-требование может превратиться в новые трудозатраты по WRICEF, поэтому вам нужно начальное количество, чтобы измерять рост относительно него.

Какие типы исключений прописать

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

Вот обычные категории:

1. Очистка и обогащение данных в унаследованных системах, часто задача клиента.
2. Изменения в сторонних и унаследованных системах на другой стороне интерфейса.
3. Лицензии и подписки на ПО, которые находятся в вашем договоре с SAP, а не в SOW.
4. Инфраструктура и хостинг, если партнёр явно не отвечает за них.
5. Проведение обучения конечных пользователей, если партнёр обучает только ваших тренеров.
6. Организационное управление изменениями сверх перечисленного.
7. Проектирование безопасности, ролей и полномочий, если за это отвечает другая сторона.
8. Нагрузочное, тестирование на проникновение и регрессионное тестирование вне названных циклов.
9. Страны, юрлица или локализации, не входящие в организационный объём.
10. Поддержка приложений после гиперподдержки, это отдельный договор.

Прочитайте два списка рядом вместе с руководителем программы. Всё, чего нет ни в одном из них, и станет источником запроса на изменение.

Коммерческая модель, которую я рекомендую для внедрения SAP, это оплата по фактическим трудозатратам (time and materials) с количественной оценкой трудозатрат. Это значит, что оценка трудозатрат по фазам и по ролям вписывается в договор, чтобы вы каждый месяц могли сверять с ней фактические трудозатраты.

Совету директоров фиксированная цена кажется надёжнее. На практике цена фиксирована, только пока держится каждое допущение, а программа SAP проверяет большинство из них к концу Explore. Мои заметки о стоимости внедрения SAP объясняют, когда фаза с фиксированной ценой всё же может иметь смысл.

Вот как две модели сравниваются в SOW:

Критерий сравнения	Фиксированная цена	Оплата по фактическим трудозатратам с их оценкой
Что фиксирует договор	Цену, пока держатся допущения	Ставки и оценку трудозатрат по фазам и ролям
Где находится риск	Партнёр закладывает его как резерв	У вас, но он виден каждый месяц
Когда объём работ меняется	Каждое изменение становится переговорами	Трудозатраты меняются, и вы видите это относительно оценки
Что можно отслеживать	Вехи и запросы на изменение	Фактические трудозатраты относительно плана, по фазам и ролям
Что вас защищает	Чёткие допущения и исключения	Чёткие допущения, исключения и отчётность по трудозатратам

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

Не позволяйте ставкам прятаться в трудозатратах. Проверьте состав ролей по рыночным ставкам с помощью моего руководства по планированию распределения ресурсов в проектах SAP.

План с большим количеством дней старших специалистов в начале и младших позже встречается часто. Обратная картина требует объяснения.

Результат работ это названный продукт с критерием готовности. «Поддержка дизайна» не результат работ. Подписанный документ дизайна решения для процесса record to report, проверенный по согласованным критериям, это результат.

Привяжите приёмку к контрольным точкам качества

SAP Activate состоит из шести фаз: Discover, Prepare, Explore, Realize, Deploy и Run. SAP описывает формальные контрольные точки качества после каждой фазы, которые проверяют, что результаты фазы готовы, прежде чем проект двинется дальше (SAP Learning).

Используйте эти контрольные точки в SOW. Перечислите результаты работ для каждой контрольной точки, критерии приёмки и количество дней на проверку. Привязывайте оплату к принятым результатам работ, а не к календарю.

Кто-то на вашей стороне должен уметь оценивать эти документы. Это одна из трёх точек, где я рекомендую привлекать независимого консультанта: при заключении договора, для дизайна и для оценки результатов работ партнёра. Моя статья о том, партнёр SAP или независимый консультант, объясняет, как две роли работают вместе.

Назовите людей и проверьте их

Слабое качество предложенных ресурсов одна из двух вещей, которые заставляют меня отказаться от предложения. Другая: партнёр не может объяснить архитектуру и план.

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

Проверяйте сертификаты, а не верьте резюме на слово. SAP выдаёт сертификационные бейджи через Credly, где их можно проверить в реальном времени (SAP Learning). По процессу поддержания сертификации SAP сертификат теряет силу, если владелец пропускает обязательную проверку (SAP Learning).

Этот пункт важнее, чем кажется. Я менял партнёра по ходу программы, и причиной было то, что партнёр не мог предоставить качественные ресурсы. Моё руководство по смене партнёра SAP в середине проекта объясняет, что нужно обеспечить, прежде чем вы до этого дойдёте.

Управление изменениями это то место, где слабый SOW становится дорогим. Если допущения расплывчаты, почти всё можно объявить изменением.

Работоспособный раздел об управлении изменениями требует таких элементов:

1. Триггер. Изменение возникает, только когда не подтверждается допущение, исключение вводится в объём работ или вы просите что-то новое.
2. Оценка влияния. Объём работ, трудозатраты по ролям, сроки и стоимость, письменно, до начала работ.
3. Ставки. Изменения оцениваются по договорным ставкам, без надбавки за срочность, если она не согласована.
4. Уровень полномочий. Кто на вашей стороне может утверждать изменения до какой суммы, с CFO выше установленного порога.
5. Журнал. Каждое изменение, утверждённое или отклонённое, докладывается управляющему комитету с нарастающим итогом.
6. Связь с базой. Новые объекты WRICEF измеряются относительно количества, указанного в допущениях.

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

За 21 программу SAP, которые я вёл или спасал, самая большая ошибка, которую я вижу, это недостаточное планирование в самом начале. SOW это место, где такое планирование становится обязательным, и время, потраченное на него, стоит дёшево по сравнению со спорными запросами на изменение.

Конкретный следующий шаг: возьмите SOW, который лежит перед вами, и выпишите все допущения и исключения на одну страницу. Рядом с каждым запишите, что происходит, если оно окажется неверным, и кто платит. Если вы не можете заполнить эту колонку, SOW не готов к подписанию.

Если вам нужен независимый взгляд на описание работ SAP до подписания, я помогаю клиентам с этим на этапе заключения договора. Вы можете связаться со мной здесь.

Что должно включать описание работ SAP?

Объём работ, подробные допущения, исключения, подход и фазы, оценку трудозатрат по фазам и ролям, результаты работ с критериями приёмки, поимённо названные ресурсы, обязанности клиента, управление изменениями и управление программой. Чаще всего слабыми остаются допущения и исключения, а именно они определяют итоговую стоимость.

Чем допущения отличаются от исключений в SOW по SAP?

Допущение это условие, на котором партнёр построил цену, например количество балансовых единиц или объектов WRICEF. Исключение это работа, которую партнёр вообще не оценивал, например очистка унаследованных данных. Каждое допущение должно говорить, что происходит, если оно не подтвердится, а каждое исключение должно называть, кто выполняет работу вместо партнёра.

Что лучше для внедрения SAP: фиксированная цена или оплата по фактическим трудозатратам?

Я рекомендую оплату по фактическим трудозатратам с количественной оценкой трудозатрат: оценка по фазам и ролям вписана в договор и отслеживается ежемесячно. Фиксированная цена держится, только пока держится каждое допущение, а программа SAP проверяет большинство допущений в фазе Explore.

Как определить критерии приёмки для результатов работ SAP?

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

Должен ли SOW по SAP называть консультантов?

Да, для ключевых ролей: архитектора решения, руководителя программы и функциональных и технических руководителей направлений. Добавьте их загрузку, ваше право собеседовать замену и ваше согласие на любую замену. Проверяйте сертификаты через бейджи SAP на Credly, а не полагайтесь на резюме.

Кто должен писать описание работ SAP?

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