Рядовой проект на аутсорсинг

Миссия данной статьи — сокращение употребления ненормативной лексики в проектной деятельности и культивирование обоюдной любви между исполнителями и заказчиками.

Система координат

Как ответственному и опытному CIO исполнить рядовой проект по СКС, внедрению программного продукта, оптимизации бизнес-процессов или какой‑то другой? Если проект уникальный, сложный, то необходимо собрать в кулак все знания и опыт по управлению проектами. Это тема другого разговора. Если трудоемкость проекта — несколько дней или многовариантность в реализации совсем отсутствует, это также другая статья и в другом журнале. В данном случае рассмотрим вариант проекта, когда надо не отвлекаться от важных каждодневных проблем, а «закрыть тему». В данном случае необходимо найти баланс собственных трудозатрат. Потратим много собственных усилий — не сделаем что‑то важное в других, более важных областях. Потратим мало — незначительный проект превратится в «незавершенку» с регулярной головной болью. Где‑то это уже было, не так ли? Исполнитель также заинтересован быстро получить деньги, а для этого нужно «закрыть тему» так, чтобы заказчик был удовлетворен.

Предположим, проект касается внедрения нового программного продукта в отдельно взятой области, отдельно взятом бизнес-процессе. Типичный пример «многовариантности». В этом случае зачастую есть и много поставщиков, и много решений.

Итак, необходимо найти решение и соответствующего поставщика. Можно было бы реализовать проект самостоятельно, опыт позволяет, но отвлекаться от более важных процессов нельзя. Также нет желания брать в штат исполнителей только ради небольшого проекта, это невыгодно. Воображение CIO уже рисует две картинки: появилась грамотная команда от адекватного поставщика, отдала под козырек в начале проекта; принесла отчет‑сказку по его завершении. Видя, что заказчик уделяет проекту недостаточно пристальное внимание, поставщик уже потирает руки — почему бы не заработать на не очень внимательном заказчике? Здесь реально и сделать поменьше, и взять побольше. Иллюзии — «в топку». Поговорим о типовых и нетиповых нюансах типового проекта. О том, как получить от взаимодействия взаимовыгодный результат.

Внутренний фокус

Пусть это банальности, но все же. Затевая проект, необходимо просчитать отдачу. Не всегда результат может быть выражен в цифрах, иногда итог является радикальным случаем. Например, внедрение системы резервного копирования — когда бизнес встанет, дело будет не до ROI системы. Однако также нельзя сказать, что финансовый эффект от данного проекта равен стоимости бизнеса. Хорошо, когда и исполнитель, понимая это, может посоветовать отказаться от проекта, если на то есть причины. Убедить в отсутствии необходимости проекта — один из лучших способов приручить заказчика, который в благодарность почти обязательно закажет другой проект в будущем. Хотя не обязательно убеждать отказаться от всего проекта. Отказ от его небольшой части иногда приводит к появлению новых работ, главное, чтобы все было обосновано «железными» аргументами.

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

Одним из способов проработки «внутреннего фокуса» может быть таблица 1.

Табл1. Рядовой проект на аутсорсинг

Можно было бы переложить этот процесс на поставщика, но как тогда заказчику выбирать решения? Но если уже есть поставщик, который ранее делал подобные решения, или, в силу нехватки времени, есть желание рискнуть, тогда либо заканчиваем чтение, либо переходим к следующему пункту… Если же подойти к выбору с ответственностью, принять во внимание, что с бабой Нюрой ИТ‑специалисты учились разговаривать в течение двух лет и только‑только начали ее понимать, то эту работу лучше сделать заказчику самостоятельно. Это должно сказаться на уменьшении суммы контракта: частично сделано предпроектное обследование, для исполнителя как минимум меньше «коэффициент геморройности».

Для тех, кто не слышал о таком коэффициенте: исполнитель всегда считает рентабельность проекта (пусть даже «в уме»). Принимая во внимание степень адекватности заказчика, представитель исполнителя рассчитывает затраченное время относительно беспроблемного хода проекта (некий эталон). Если он понимает, что с «нормальным условным» заказчиком этот проект завершился бы через месяц, а вы ему «будете пить кровь» лишние две недели… будьте уверены, в смете работ будет не месяц, а полтора (или больше, в зависимости от «интенсивности кровопускания»).

К требованиям по функциональности необходимо добавить анализ следующих важных критериев:

  • возможности инфраструктуры — возможность инсталляции, создания резервных копий и т. п.;
  • возможности специалистов заказчика — самостоятельно ли будет осуществляться дальнейшая доработка (а она часто необходима), поддержка;
  • способность решения влиться в информационное пространство — возможность синхронизировать данные с другими системами;
  • способность персонала научиться и эффективно использовать решение — иногда разные по идеологии системы тяжело воспринимаются пользователями, из‑за этого фактора можно надолго «завязнуть» на этапе обучения и внедрения.

Анализ указанных критериев позволит правильно рассчитать бюджет проекта, так как некоторые нюансы иногда забываются: систему поставили, а куда сохранять резервные копии, не подумали; неожиданно не хватает «толщины канала»; не предусмотрено рабочее место (начальник хочет «смотреть», компьютер у него есть, а лицензию не купили)…

Выбор решения и поставщика

Когда побороли себя (это самая длинная история), начинаем поиск поставщика.

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

Составляем список критериев оценки решений. У поставщика решений может быть несколько, но у одного решения не может быть разных поставщиков — разные компании означают разные ре­шения.

Наша голова «без бумаги» неспособна четко составить таблицу для анализа. Даже в очевидных, казалось бы, случаях полезно если не составить таблицу, то хотя бы просто выписать критерии.(таблица 2)

Табл2. Рядовой проект на аутсорсинг

Вес — важность одного критерия относительно другого. Баллы между решениями лучше распределять так: одно количество (например, 100) делить между вариантами.

В большинстве случаев в момент составления перечня критериев решение выбора приходит само собой. Однако «бумага» зачастую позволяет по‑новому взглянуть на ситуацию.

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

Если мозг не произвел автоматический выбор после выписывания критериев, то, как говорится, дело дрянь. В этом случае таблица, как правило, дает близкое количество баллов по паре вариантов. Иногда, чуть изменив вес, мы получаем перевес в другую сторону. Выбор затрудняется психологически. Часто чем больше анализируем, тем более затрудняется выбор. Если не получилось обновить список критериев или поменять веса так, что мозг вскричал «эврика», то закрываем крышку ноутбука и медитируем — слушаем интуицию!

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

Выбор исполнителей

Забежим немного вперед, пока договор не подписан и еще «не поздно».

Заключается договор, наступает «час икс» — час старта проекта. На пороге появляется «руководитель проекта» солидной компании. Постойте, а почему он так молод (или стар), неопрятен (или вас смущает его ориентация)? У нас начинают появляться первые сомнения… Затем, наблюдая «боковым зрением» за ходом проекта, вы понимаете, что конкретный пунктик забыт, другой не будет выполнен в срок… Вы начинаете вмешиваться в проект.

В одном случае просто напоминаете о пунктике — ошибка исправляется, но время вы уже потратили на мониторинг. Во втором — вы начинаете строить всех подряд: руководителя проекта, его начальство. Ну и вас в свою очередь тоже кто‑то пытается строить. Проект затягивается, качество работ, подобно осеннему листку от ветра, начинает зависеть от «ненужных» факторов. В третьем — частично руководство проектом перекладывается на ваши плечи. Поднимите руки, кому незнакома такая ситуация… Это еще хорошо, когда проектом занимаются сотрудники поставщика. Нередки случаи, когда «на объекте» оказываются представители субподрядчика. А разговор с ними часто напоминает разговор слепого с глухим, ведь прямого договора с ними нет!

Неужели в компаниях работают только бездари и обманщики (те, кто продали проект)? Нет! Точнее, не всегда. А кого мы выбирали? Правильно, компанию, а не конкретных исполнителей. А в компании был человек, который распределял работу. Он руководствовался тем, что: ваша компания «не Газпром», уникальность проекта — не «раз в десятилетие», молодому сотруднику тоже нужно набираться опыта, на рынке кадровый голод (а зарабатывать много хочет и поставщик, не отказываться же от проекта в силу нехватки специалистов, точнее, грамотных специалистов), этот руководитель проекта уже выполнял аналогичные проекты (эффект конвейера). Всю мотивацию не перечислишь.

Мы потратили уйму времени на выбор решения/поставщика, а кто будет работать по проекту, не знаем. Такого не должно быть. Как сделать, чтобы проектом занимались конкретные исполнители? Правильно, зафиксировать ФИО конкретных сотрудников компании в договоре, предварительно выбрав их по «резюме», «портфолио», списку проектов — как хотите. Поставщик отказывается так работать, аргументирует: «качество гарантируем», «в случае болезни заменим», «у нас все звезды» (а сами‑то они в это верят?). Как минимум повод внести это в критерии выбора и проставить соответствующую оценку напротив. Автор в данном случае далее не рассматривал подобные компании — участие в тендере для них бы заканчивалось. Честно говоря, автор, находясь по другую сторону баррикад, испытывал напряжение, когда заказчик выдвигал требования по исполнителям. Это немного связывает руки, приоткрывает завесу тайны над таинством проекта. Однако если этот этап пройден, доверия становится больше, и работать легче. Как будто вы раскрыли карты друг перед другом.

Могут быть, конечно, случаи, когда поставщику вынуждены доверять, например, в виду сложности решения и отсутствия у компании заказчика сотрудников с компетенцией в данной области. Бывает, что мы находимся жестко в рамках определенных критериев, другими словами, у нас нет выбора. Тогда с поставщиком сложно разговаривать — он диктует условия.

В большинстве же случаев, когда рынок конкурентный, не нужно стесняться ставить условия привлечения конкретных исполнителей. Для поставщика это не только новые условия в договоре. Это сигнал вашей внимательности к деталям (возможно, «не прокатят» по другому поводу). Это повод задуматься о сроках. Нормальная ситуация, когда поставщик отказывается от проекта — у него нет в необходимых временных рамках сотрудников с нужной компетенцией. Уж лучше он откажется до контракта, чем будет долго водить вас за нос в ходе проекта.

Прописав исполнителей в договоре, мы получаем:

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

Также в договоре должна быть прописана процедура замены исполнителя — вам же обещали замену с самого начала в случае болезни сотрудника? Иначе получите хороший повод поиздеваться над вами.

Контрактование

Многие считают, что договор — всего лишь формальность. Позвольте категорически не согласиться. Пункт по уборке мусора после монтажа СКС многие поставщики включают не задумываясь, но потом об этом приходится напоминать: технология уборку не включает почти у всех. Подобные пункты, если хотите, дают поставщику «невербальные сигналы» вашего серьезного отношения к деталям. И по ходу проекта больше вероятность, что вас спросят, как поступить в каком‑то конкретном случае, не оговоренном в договоре. В противном случае исполнитель всегда трактует ситуацию в свою пользу.

Прежде чем подписывать договор, еще раз проанализируем необходимость проекта (при выбранном решении):

  • надежность намерений спонсора проекта;
  • актуальность всех критериев, по которым выбирали решение, по окончании проекта — востребованность системы, возможности поддержки и т. д.

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

Контрактование тоже является очень важным критерием выбора поставщика. Нормальный вариант, когда приходится отказываться от компании из‑за фантазий юристов данной организации. У некоторых поставщиков считается нормальным, когда почти каждый пункт договора написан так, что в любом случае неправым оказывается заказчик. На конкурентном рынке это напрямую говорит о том, что способ заработка компании — «выжимание соков» заказчика. От таких «исполнителей» надо держаться подальше, а не пытаться переделывать их договор.

Успешность проекта во многом зависит от степени формальности отношений. Хочется предостеречь от приятельских отношений по ходу первого проекта на этапе их становления. Исполнитель, нередко пренебрегая формальным подходом и делая «лишнюю» работу из‑за симпатий или из‑за желания заработать репутацию, позволяет воспринимать это как «прогиб». Заказчик привыкает к такому отношению, и процесс неожиданно превращается в войну, где постоянно выясняется, что должен делать исполнитель, а что нет. Неформальные отношения приемлемы тогда, когда рабочие коммуникации уже выстроены.

Ход проекта и его завершение

Необходимо придумать параметры, по которым можно было бы легко оценивать ход проекта. Полезны встречи с командой проекта раз в неделю и обсуждение его хода. Сам факт постоянной заинтересованности деталями проекта не даст команде расслабиться, и «запущенность» процесса будет возникать с меньшей вероятностью. Более подробную информацию по данной теме можно получить из источников по управлению проектами.

Заключение

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

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

Хорошо себя зарекомендовал выбор маленьких компаний для небольших работ. В этом случае мы всегда знаем, кто приедет, поставщик «роет землю», чтобы не потерять договор. Все прозрачно и эффективно. Например, держать у себя специалиста по АТС невыгодно. Зато максимум удобства заключается в том, чтобы позвонить директору компании-поставщика на сотовый, и задача начинает решаться максимально быстро, по ценам, которые никогда не даст большой интегратор. И качество будет ожидаемое — дорожа договором, вам не подсунут «студента».

Описанный выше случай очень близок к варианту выбора конкретного человека — фрилансера. Адекватный специалист всегда дорожит заказчиком. Зная конкретного человека, можно выстраивать доверительные отношения (например, в обслуживании «1С» доверие очень важно — часто не просчитаешь трудозатраты по конкретной работе, а значит, сложно разговаривать о цене). Недостатки этого варианта несложно решаются. Например, в случае болезни, как правило, фрилансер сам же предложит замену. В случае увеличения объема работ несложно найти второго и третьего специалиста, может быть, опять по рекомендации первого. Что касается гарантии работ, то, по опыту, проблемы чаще возникают с компаниями, чем с фрилансерами. Главным недостатком данного варианта остается то, что выбрать специалиста можно, только обладая квалификацией в соответствующей области (или к выбору привлечь знакомых — тот же аутсорсинг).

Как говорят, на рынке два дурака: один продает, другой покупает. Заказчик стремится решить задачу минимальными затратами максимально быстро и за меньшие деньги. Исполнитель пытается максимально быстро заработать на проекте деньги, репутацию. Хороший способ понять противоположную сторону — поставить себя на место другого. К сожалению, многие, как со стороны исполнителя, так и со стороны заказчика, «включают неадекват». Часто это делается умышленно для манипулирования оппонентом. В результате манипулятор сам же теряет деньги благодаря тому, что дела затягиваются или даже разваливаются.

Важные характеристики проекта — скорость, качество, цена. Из трех необходимо выбрать два. Если задача решается качественно и дешево, то на скорость исполнения надеяться не приходится. Если хотим быстро, то приходится выбирать: или качественно и дорого, или дешево, но не качественно. Исключения лишь подтверждают правила.

Выбор поставщика и решения можно считать творческим процессом. Счастье в том, что человеку дано думать. Хорошая «прокачка» финального варианта решения, и страшного аутсорсинга можно не бояться. Обоюдные «подставы» все равно будут, но неудачи делают нас сильнее.

Автор: 
Савосин Д.И. выпускник программы MBA CIO, группа 13. Директор по IT (группа компаний "Автолига")
Издание:: 
Intelligent Enterprise, №4 (226) 2011
site map xml | Карта сайта | RSS канал Новости Школы IT-менеджмента 501.58