Кризис среднего возраста – часть третья, заключительная

Давайте поговорим о том, как придти к тому, чтобы выделенный центр был эффективным инструментом Заказика и источником бесперебойной прибыли Исполнителя.

Выгоды от создания идеального выделенного центра получают обе стороны. Это очевидно:

  • Исполнителю выгодно полностью продать рабочее время проектной команды, чтобы забыть про неприятные темы, связанные с простоями, недозагрузками и прочими “радостями” ресурсной жизни.
  • Заказчику выгодно, когда выполненная для него работа стоит ровно столько, сколько стоит время, потраченное на ее выполнение. В таком варианте он не переплачивает за продукт, как это бывает в случае fixed cost. При этом знание своей выделенной команды и ее возможностей минимизирует для Заказчика риски, характерные для time&material, а именно: превышение ожидаемой стоимости продукта, срыв сроков производства и т.п.

Но если сравнить ситуацию на предмет наличия рисков, то мы заметим, что Заказчик оказывается в гораздо более пикантной ситуации, чем Исполнитель. Дело в том, что как только команда Исполнителя становится отличной от идеала, у Заказчика сразу возникают довольно злые риски (вспомним про треугольник цена – сроки - качество):

  • Превышение первичных ожиданий по стоимости услуги
  • Нарушение графика поставки услуг
  • Нарушение ожиданий по качеству услуги
  • Несоответствие функциональных возможностей продукта возложенным на него ожиданиям (что является по-большему счету проблемой с качеством продукта)

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

Поэтому, прежде, чем кидаться во все тяжкие с аутсорсингом, нужно для себя ответить на ряд вопросов:

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

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

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

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

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

ka-ba 

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

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

Вот в этом месте прихожу к своей главной мысли. Если ты Исполнитель и хочешь продать Заказчику выделенный центр, то тебе мало просто сказать: “купи наших людей, мы ведь крутые парни в аутсорсинге”. Тебе необходимо предложить прозрачный и понятный для Заказчика roadmap, который позволит ему убедиться в том, что в конечном итоге он получит людей, которым он доверяет, и процессы, которые он понимает. Причем это не должен быть организационный процесс, это должен быть путь кристаллизации команды, которая в конечном итоге станет ядром выделенного центра. И никакие case studies этот roadmap не заменят.

Комментарии

Популярные сообщения из этого блога

Драйв

Карта компетенции аналитика

Оценка эффективности работы руководителя проектов