Переход от одного “аутсорсера” к другому

Posted on Thursday 1 December 2011 under by Rustam Sydykov

Привет, народ!

Достаточно долго не писал в этот блог, в основном увлекался постами в персональный :) Да и не было ничего особенного, о чем хотелось бы написать. Так… “текучка” и рутина.
Но недавно мне пришлось провести четыре дня в процессе начального перехода от одного аутсорсера к нам. Аутсорсер, которого мы заменяем – очень уважаемая компания, её имя всем известно. Не буду его называть, но оно у всех на слуху. Так к чему это я: по идее, переход от одного поставщика  IT услуг к другому должен быть сравнительно безболезненным. Как в магазине: сегодня молоко вам привозил один поставщик, завтра – другой. Многие видят подобную гибкость как одну из причин, почему  IT сервисы должны быть за-аутсорсены. Но это в теории. На практике же выглядит всё по другому. Есть аутсорсеры, которые не стараются усложнить жизнь своему “коллеге” и переход происходит сравнительно безболезненно. В моем случае это было “слегка” не так: предыдущая IT компания заявила, что методы безопасности, применяемые к серверам клиента, являются интеллектуальной собственностью компании, поэтому нам не разрешается выполнить миграцию физических серверов в виртуальную среду. Никакие доводы о том, что клиент заплатил деньги за услуги и является собственником своих данных, приложений и платформы не возымели никакого действия! Отказ нам помогать со стороны предыдущего аутсорсера мотивирован очень тонко: они не отказываются предоставлять информацию, доступ к инфраструктуре и т.п., но легкой миграции не получится из-за какой-то эфемерной “интеллектуальной собственности”. Вряд ли компания, которую обслуживал этот аутсорсер, могла даже подумать о таком повороте событий.
Как вы думаете, кому не повезло в этом случае? :) Явно не предыдущему поставщику IT услуг – они свою прибыль уже получили. Даже не мы, новый аутсорсер: отказ в p-2-v миграции означает растягивание миграции по времени, более спокойный переход, клиент будет более лоялен к возможным проблемам после миграции и плюс это дополнительные деньги – коммерческое предложение делалось с учетом определенных условий. Если эти условия не соблюдаются – все необходимые действия по миграции оформляются как проект или набор проектов с соответствующими атрибутами в плане бюджета, ресурсов и т.п. Проигравшим может оказаться клиент, кто будет за это всё платить.
Вывод из этой истории очень простой: прежде чем “впускать” аутсорсера, подумайте, как вы будете его “выпускать” и заранее подстрахуйтесь на случай отказа аутсорсера выполнять какие-либо разумные требования.

Засим раскланиваюсь,
Рустам.

Почему всё-таки некоторые компании любят аутсорсеров

Posted on Wednesday 21 September 2011 under by Rustam Sydykov

Привет, народ!

Недавно разговаривал со своими бывшими коллегами, которые в данный момент работают на аутсорсера (но не того, на которого работаю я). Они высказали интересное мнение, почему некоторые компании вполне довольны аутсорсингом, даже не смотря на упавшее качество IT услуг. Всё очень просто: деньги. Дешевле. По крайней мере, им так это кажется.
Очень часто аутсорсер не знает полностью сложность систем, которые он обслуживает. Пусть это верно в какой-то степени, но я готов поспорить, что невозможно знать всё абсолютно в уже существующей IT инфраструктуре, особенно если не вы её разворачивали. Что происходит: клиент просит оценить стоимость работы, которая выглядит достаточно просто, если не знать “подводных камней”. Аутсорсер предоставляет смету работ, скажем, 8 человеко-часов и клиент радостно её подписывает. Всё, после этого любая работа сверх этих заявленных 8-ми часов идет за счет аутсорсера! Даже если это займет месяц. Т.е. экономия для клиента происходит за счет того, что аутсорсер вынужден за свой счет проводить кое-какие работы.
С другой стороны, аутсорсер обладает огромной возможностью “надуть” клиента: выставить “раздутый” счет за какую-либо работу. Если клиент “глупый” и полностью избавился от IT персонала, возможности у него оспорить этот счет будет очень мало. Так и случилось: сравнительно простая работа обошлась клиенту в миллионы фунтов.
Наверное, в этом случае каждый остался “при своих” :) Мне кажется, в случае аутсорсинга будет вечная борьба противоположностей: клиент/бизнес будет стараться заплатить меньше, скрывая накопленные знания о существующих проблемах и пытаясь переложить их решение на аутсорсера; аутсорсер, в свою очередь, будет стараться любой проект “раздуть до размеров слона”, чтобы получить “нескромные” деньги. А страдать будут бизнес-пользователи и качество :(

Засим раскланиваюсь,
Рустам.

Размышление о важности документации

Posted on Tuesday 30 August 2011 under by Rustam Sydykov

Привет, народ!

Должен покаяться: я перестал писать в этот блог и виной этому Fallout 3 :) Чертова игра затягивает и я в этот месяц, пока играл, практически забросил заниматься другими делами. Но мои жена и дети вернулись из отпуска, я опять езжу на работу поездом, поэтому свободного времени для написания постов у меня будет больше :)
В этот раз я хотел бы поделиться с вами некоторыми мыслями о документации. Есть документация, которая представляет собой просто текст, написанный ради того, чтобы отчитаться о её наличие и “закрыть” этот пункт. Полезность таких документов крайне невелика и их можно спокойно исключить из дальнейшего рассмотрения. Но есть документация, которая представляет собой накопленные знания/информацию и в какой-то мере представляет культуру организации. Важность таких документов сложно недооценить, но есть три главные проблемы:

  • Документацию мало кто хочет читать;
  • Ее никто не хочет писать;
  • В большинстве случаев непонятна полезность уже написанных документов.

Начнем с последнего пункта. Очень часто люди забывают, что документация должна быть применима каким-либо образом в реальной жизни. Если есть много документов, но непонятно, что с ними делать – грош цена всей этой информации. Документация должна быть написана так, чтобы поддерживать ключевые бизнес процессы и удовлетворять потребности в информации людей, участвующих в этих процессах и исполняющих различные роли. 
Простой пример: в моей компании есть четыре основных процесса: “продажа” (“pre-sales”), “инициация проекта”, “выполнение проекта” и “ежедневная поддержка” (“producation/business as usual”). Есть у нас портал, на котором опубликована масса технической информации (есть и неплохие документы). Но: разных людям нужна разная информация на разных этапах. В случае с “продажей” необходимо знать в общих чертах, что мы можем предложить клиенту, какая выгода от этого будет, сколько это будет приблизительно стоить и займет времени. В процессе инициации проекта надо понимать какие есть предварительные требования для внедрения какого-либо решения (инфраструктура, лицензии и т.п.). Во время внедрения – стандартные решения (“best practices”) для технического персонала и стандартный план проекта для менеджера проектов и т.д. Если опубликованные документы не могут моментально “кликнуть” в каком-либо месте, заявляя свою полезность – мало кто будет дотошно разбираться, как можно использовать тот или иной документ. Поэтому вся документация должна быть “привязана” к бизнес процессам, использовать стандартные шаблоны и т.п.
О первом и втором пункте. Все очень просто: люди по своей природе ленивы. Если их не заставлять, то 90% не будут делать “лишних телодвижений”. Для того, чтобы заставить работников писать/читать документацию, оценка эффективности того, как они это делают, должна быть частью ежеквартального/ежегодного пересмотра качества работы (KPIs, “performance review”) этих сотрудников. В таком случае у них будет личная заинтересованность в том, чтобы как можно полнее использовать документацию (т.е. накопленные знания) и самим ее писать (т.е. делиться своими знаниями).

Засим раскланиваюсь,
Рустам.

Тщательное планирование vs JFDI

Posted on Wednesday 13 July 2011 under , by Rustam Sydykov

Привет, народ!

Может показаться, что я забросил этот блог. Отнюдь :) Просто в данный момент я заканчиваю работу над крупным проектом и все, что я делаю – это  ударными темпами пишу документацию. Писательский зуд удовлетворяется полностью :)
Мой текущий проект является хорошим примером того, что иногда имеет смысл отказаться от тщательного планирования проекта: сформулировать техническое задание, критерии успеха, планировать ресурсы и т.д. Отличительной чертой проекта было то, что бизнес понимал, что “дальше так жить нельзя”. Но, в то же время, никто в бизнесе не обладал полной информацией, как же все-таки они “хотят жить”. Слава Аллаху, эту проблему бизнес так же осознавал. С другой стороны, моя компания, как поставщик IT услуг, обязана была выполнить ряд задач и это было обговорено в контракте. Так к чему это я: нам пришлось отказаться от большинства шагов, присущих хорошему проекту! Все попытки оценить время, требуемое на завершение проекта, ресурсы, создать предварительный детальный технический дизайн упирались в то, что тупо не было возможным получить необходимую информацию от бизнеса. Все, что мы могли сделать вначале – это предоставить приблизительный план действий на две недели вперед. Максимум! Надо отдать должное, бизнес принял данную ситуацию как есть и мы использовали метод “ковбойского наскока”: составили общий дизайн (этакий комьюнике о намерениях), провели небольшой пилотный проект и начали полномасштабное внедрение по типу JFDI (just f…g do it!).
Признаюсь, у меня лично “сердце не лежит” к данному подходу. Но это позволило нам:

  • Все-таки начать работу над проектом несмотря ни на что: опасения и недоверие бизнеса (бизнес считал, что мы не справимся с задачей, потому что предыдущий аутсорсер не смог), отсутствие необходимой информации и т.п.;
  • Восстановить доверие бизнеса и продемонстрировать, что проект может быть успешно закончен. После того, как мы прошли отметку приблизительно 10% завершенности проекта, бизнес уже не только не вредил, но и начал активно помогать – те люди, которые не имели раньше времени для анализа сложных моментов или обсуждения чего-либо, стали гораздо доступнее для встреч;
  • Обычные пользователи, которые участвовали в “пилоте”, почуствовав “вкус новшеств”, помогли нам изменить настроения среди остальных пользователей с пессиместических на более открытые к изменениям;
  • Бизнес и мы “наработали” необходимую информацию о структуре бизнеса, требованиях (в плане приложений, доступа к данным и т.п), которая помогла нам во время проекта и поможет нам в дальнейшем.

Самое смешное, что 99% того, чего опасался бизнес до начала работы над проектом, не подтвердилось. Это все было на уровне диалога, который Э.Берн хорошо описал в книге “Игры, в которые играют люди”: вы нас говорите, что вы будете делать, а мы будем придумывать причины, почему это работать не будет. Именно из-за первоначального недоверия и пессимизма мы с большой “пробуксовкой” начали проект.
К сожалению, есть и своя “ложка дёгтя”:

  • Некоторые вещи можно было бы сделать лучше, имей мы необходимую информацию пораньше. Тут уж трудно что-то изменить;
  • После окончания проекта надо будет провести еще один цикл хотя бы анализа того, что сделали и наметить задачи для улучшения внедренного решения. С этой точки зрения проект был закончен не самым эффективным образом. С одной стороны - это плохо, с другой – хорошо, так как будет новый проект и под него выделят (а могут и не выделить) новый бюджет.

Напоследок еще раз подчеркну: если бы мы всего боялись, то ничего бы и не сделали. В некоторых случаях надо плюнуть на все и просто постараться что-то сделать вместо того, чтобы фантазировать на темы “что мы будем делать, если что-то будет не так или не так”. “Глаза бояться, а руки делают” :)

Засим раскланиваюсь,
Рустам.

Как “продвинуть” свою идею с минимальным сопротивлением

Posted on Friday 17 June 2011 under , by Rustam Sydykov

Привет, народ!

Я начал читать одну интересную книгу: “Психология влияния”. К IT эта книга, собственно говоря, никакого отношения не имеет, но я неожиданно понял, почему в свое время мне удавалось “протаскивать” свои IT дизайны проектов через формальный процесс рассмотрения с минимальной кровью. Раньше я работал на большую компанию, в которой было несколько слабо связанных между собой команд: network, datawarehouse, storage, *unix и т.д. Я был в команде Microsoft (ну, не совсем – просто команда отвечала за wintel платформу :)). Каждый проект следовал стандартному циклу: первоначальное предложение/опции –> дизайн –> внедрение –> передача в production (ежедневная поддержка).  Фаза дизайна включала в себя написание документа для инженеров, как то или иное решение/продукт надо внедрять. Потом системные дизайнеры из разных команд должны были этот документ рассмотреть, высказать свои замечания и если были серъёзные недочеты, документ приходилось переделывать. Очень часто случалось, что недочеты, которые отмечались как “критические”, вызывали бурные обсуждения, споры и доходило чуть ли не до личных обид. В то же время мои дизайны “проскакивали” сравнительно легко.
Читая “Психологию влияния” мне показалось, что я сознательно (и подсознательно в какой-то мере) устранял следующие потенциально неприятные ситуации:

  1. Человеку очень трудно изменить свое мнение, которое он высказал публично. В данном контексте “публично” я подразумеваю во время встреч, на которых обсуждались документы IT дизайнов;
  2. По моему, я уже про это писал, но каждая идея проходит через фазы: “Это полное гавно”, “Что-то в этом есть” и “Отличная идея, я всегда так говорил!” :). Подвидом этого варинта является “Твоя мысль правильная, но то что я говорю – правильнее”.

Кроме того, каждый раз получалось так, что я косвенно вовлекал своих коллег в процесс формирования идеи дизайна какого-либо решения. В результате, сказав “да” один раз (неформально одобрив идею), они уже не имели морального обоснования яростно говорить “нет”.
Что я делал: да ничего особенного! Никаких манипулятивных приёмов или “расставления логических ловушек”. Коротко методику можно выразить так: разговаривайте с людьми!

  1. Спрашивайте совета или неформального подтверждения правильности вашей идеи/мысли/подхода на ранних стадиях проектов: перед тем как что-либо оформлять документально, я обходил всех коллег, которые будут вовлечены в рассмотрение дизайна и его внедрение. Я прекрасно знаю, что не могу всего знать и что-либо мог сделать неправильно. Со своей глупостью лучше столкнуться в начале, чем в конце;
  2. Постарайтесь ознакомить людей с вашей идеей как можно на более раней стадии. В крайнем случае, вы пройдете через первую фазу – “это полное гавно” быстрее. В лучшем варианте – ваша идея не вызовет мгновенного отторжения, так как ее можно представить как не окончательный, “окостеневший” вариант, а больше как “документ о намерениях”. Кроме того, если будут возражения к вашей идеи, они будут сделаны не публично, не в письменной форме и вам потом будет легче убедить людей поменять их точку зрения;
  3. Получите неформальное подтверждение правильности ваших идей. Желательно письменно :). Нет, я не призываю никого заставлять расписываться кровью на пергаментах, достаточно будет даже короткого е-мейла от всех вовлеченных в обсуждение :)
  4. Будьте готовы пожертвовать “малым” ради “большого”. Если есть разногласия в несущественных вопросах, лучше уступить, чем “бодаться” и испортить себе нервы.

Вот и все. Что я делал: каждый раз кратко обговаривал и советовался со своими инженерами и коллегами о любых предстоящих проектах выше определенного порога сложности. Людей по пустякам не дергал, но если чуствовал, что обсуждение может перерасти в “свалку” – обязательно лично обходил всех влиятельных лиц :) Особенно, не дай бог, дело касалось о внедрении систем, которые занимались проводкой денежных транзакций, обработки данных о клиентах и т.п. Я подходил к архитекторам отдела информационной безопаснсти и заранее, до начала проекта просил объяснить мне, на какие моменты мне надо будет обратить внимание. Во первых, люди понимали, что я уважаю их и их мнение; во вторых, часто действительно они давали мне дельные советы в области информационной безпопасности. Столько есть законов и подзаконных актов, регулирующих сохранность данных, что я диву давался. К примеру, если какая-то часть сервисов обслуживания клиентов отдана на откуп аутсорсеру, находящимся за пределами Евросоюза, то надо быть способным показать, что данные о клиентах или платежах не могут быть перемещены за пределы Евросоюза. Речь идет о массовом экспорте данных – списывание ручкой с экрана информации о клиенте в расчет не принимается. Это по п.1 и частично по п.2
Дальше по п.2: я не стеснялся рассылать почти законченные документы, формулирующую идею или дизайн до того, как отправлять их на формальное рассмотрение. В общем случае смысл идеи был уже “переварен”, принят и тогда детали будут так же приняты благосклонно. Могут возникнуть вопросы, но критических замечаний, я думаю, удасться избежать.
Обязательно просите послать короткий е-мейл, что документ рассмотрен и особых замечаний нет. Как раз в книге “Психология влияния” я прочитал подтверждение этой мысли: если человек что-то написал, то он будет стараться придерживаться этого. Естественно, не все предоставляли мне отзывы. Но я еженедельно проводил встречи с инженерами, на которых снова коротко рассказывал о том, что я “надумал” и спрашивал, есть ли замечания. В 99.99% случаев замечаний не было, что давало мне основание разослать краткое резюме встречи, включив список людей, кто присутствовал, какие документы рассматривались и что никто не высказал никаких (или дал какие-то комментарии) замечаний.
Иногда замечания были, но не по сути, а чаще всего что какие-то вещи инженера привыкли делать не так. Я думаю, всем понятно, что некоторые вещи можно сделать несколькими способами – все зависит от личных предпочтений. Это были те случаи, когда я “жертвовал малым” – переделывал документы, хотя и мой вариант был верен. Это, собственно говоря, даже не “жертва”, а вполне разумный подход – чтобы не спорить по пустякам.
После такой “массированной артподготовки” практически все документы/идеи проходили на ура. Так что еще раз повторюсь: если хотите что-то сделать и не тратить усилия на ненужные споры – разговаривайте с людьми.

Засим раскланиваюсь,
Рустам.

“Провал” IT проекта с точки зрения бизнеса

Posted on Wednesday 8 June 2011 under by Rustam Sydykov

Привет, народ!

Что-то меня в последнее время потянуло в “негатив” :) Рассказываю о проблемах в работе вместо того, чтобы делиться умными мыслями (трудно делиться  тем, чего нет :)). Просто я нахожусь в процессе миграции учетных записей пользователей в AD в новый дизайн и проблем у меня хватает :)
Как мне кажется, любой IT проект может быть воспринят бизнесом как “провальный” или “не оправдавший надежд”. Все зависит от того, насколько видны конечным пользователям изменения в положительную сторону в их работе. Часто бывает, что все изменения произошли где-то на заднем плане, а вот пользователям вроде бы ничего и не перепало. Или проект обещал произвести “революцию”, а закончилось все “эволюцией”. Я уже раз упомянул про “ожидания пользователей”. Очень важно быть предельно открытым в плане того, какую выгоду бизнес будет иметь от изменений. Если не-IT людям наговорили “с три короба”, лишь бы добиться финансирования проекта, скорее всего потом прийдется долго и упорно краснеть за свои слова. И потом, когда действительно подойдет время чего-то глобального, желания бизнеса инвестировать деньги/ресурсы в этот проект может и не быть.
И еще одно: нежелание самого бизнеса меняться. Это может быть как отказ изменить что либо в бизнес-процессах, так и нежелание конечных пользователей делать что-то по другому. Типа: “Мы всегда чесали левое ухо правой ногой и хотим продолжать это делать. Во первых: не сомневайтесь, что нам это надо! Во вторых: предложенная вами идея внедрить ваш замечательный чесатель-заменитель правой ноги нам совершенно не подходит!”.
В одном случае это может быть просто привычкой С этим бороться просто: можно просто сделать необходимые изменения и люди быстро привыкнут. Это людская натура: не любить изменения :) Я так сделал в текущем проекте: пользователи кричали, что для них нет более приятной вещи, чем получать доступ к сетевым ресурам по UNC или подключая десяток сетевых дисков. Тупо-молча им подключили один сетевой диск с консолидированными сетевыми папками через DFS. Сначала были жалобы по поводу структуры папок, но я был готов “слить” эту проблему, так как надо же было им в чем-то уступить :) Сейчас они уже забыли, как лазили по разным файл серверам в поисках своих папок и все делают через DFS.
Есть еще и второй вариант: пользователи сабботируют изменения по каким-то непонятным причинам. Просто “не нравится и все!”. Может, они боятся, что после внедрения новой системы их сократят (актуально было для Украины), а может, просто какие-то “подковерные” игры. Здесь ничего не поможет, кроме как четкое и однозначное указание вышестоящего лица. Этих “вышестоящих лиц” надо искать либо среди тех, кто выступает заказчиком (“stakeholders”), либо непосредственно среди  ответственных за проект сотрудников в бизнесе (“accountable”).
Надеюсь, от этого поста будет хоть какая-то вам польза и я не зря потратил 20 минут в поезде, набивая этот текст.

Засим раскланиваюсь,
Рустам.

Делегирование обязанностей

Posted on Thursday 2 June 2011 under by Rustam Sydykov

Привет, народ!

Постоянно себе твержу: не надо стараться “залезть во все дыры”, не надо стараться делать все самому! Не получается :)  Очень трудно избавиться от привычки что-то делать самому, особенно если знаешь, что сам сделаешь лучше, чем кто-то другой. В текущем проекте я взялся временно работать как инженер, так как мой инженер “застрял” в Индии из-за проблем с визами. Мне пришлось и мигрировать пользователей, и разбираться с их проблемами. С одной стороны, когда непосредственно контактируешь с обычными пользователями – это самое большое удовольствие! Решаешь проблему, люди искренне благодарны. Особенно, если они сразу видят улучшения или удобства в своей работе. Правда, иногда кажется, что люди “роют” и-нет в поисках каких-либо заковыристых проблем, “ломают” свой компьютер и звонят тебе, чтобы ты помучился. Одних проблем с Outlook-ом я столько нагляделся, что даже не знал, что в такой относительно простой программе можно столько натворить. В общем, бизнес сейчас доволен, так как я могу быстро и легко решить 99.9999% их проблем. Но: теперь мое непосредственное участие поставлено бизнесом как обязательное условие для продолжение проекта! Я уже не могу так легко “спрыгнуть”, пусть даже этот случай и обговаривался с бизнесом. Кроме того, мою работу тоже никто не отменял, мне приходиться и заниматься мелкими техническими проблемами, и продумывать дальнейший дизайн и начинать писать документацию. А эти действия слабо совместимы друг с другом. Я лично не могу постоянно отвлекаться на звонки и е-мейлы и в то же время делать что-то глобальное.
Так что мой совет: если по роду деятельности вам не положено чем-либо заниматься – не беритесь! Если есть ответственный человек для этого – он и должен это делать. Максимум – можно обещать ему помощь и “наставлять на путь истинный” :) Держитесь в рамках своих должностных полномочий – это хорошо и вам, и делу.

Засим раскланиваюсь,
Рустам.

Самые большие препятствия для успешного выполнения задачи

Posted on Friday 20 May 2011 under by Rustam Sydykov

Привет, народ!

Не знаю, как у вас, а на моей практике самыми большими сложностями во всех проектах или просто в IT жизни, были так называемые “PPP”: people, politics and processes (люди, политика и бюрократия). Когда попадаешь на поле боя этих три “п”, можно быть увереным, что ничего хорошего из этого не выйдет. Или тебя перемолотят, пережуют и выплюнут, или, если хватило ума распознать ситуацию, можно выжить, пережив самые сложные моменты где-нибудь в сторонке :)
Чем больше растешь в должности, тем больше приходиться работать с людьми. Умение общаться и “не наступать на мозоли” людям часто выходит на первый план. Пусть даже некоторых хочется пристрелить во время работы, но коллег не выбирают :) Самый плохой вариант – кто-то выше тебя по должности сделал ошибку, но “уперся” рогом и не хочет ее признать. Я уже упоминал о такой ситуации и честно признаю, что очень мало людей могут признаться в этом и “отыграть назад”. Чем выше должность, тем труднее это сделать. Но люди, которые могут это сделать, заслуживают самого большого уважения.
Политика… это продолжение первого случая, но уже вовлечена группа людей. Ситуация ухудшается, если существуют конкурирующие группы. Гарантированы тлеющие очаги конфликтов, грозящие превратиться на время в “локальную заварушку”. Опять же, все мы люди и вполне возможно, случайно (или не случайно) можно оказаться (или быть причисленным) к одной из группировок. Надо стараться дистанцироваться от всех конфликтных ситуаций. Полностью не получиться, тогда надо на себя напяливать самую толстую шкуру, которой вы обладаете, стараться “обтекать” или получать удовольствие. КПД работы в любом случае будет низкий, как бы вы не старались.
Ну а третий вариант – когда невозмонжо что-то сделать, не потратив гораздо больше энергии на бюрократические проволочки. Систему можно попытаться сломать, но она будет сопротивляться силами паразитирующих на ней людей. Явно под бюрократию открыли должности, набрали людей и они просто так не откажутся от своих мест и зарплат. Можно попытаться найти обходные пути или лазейки. В любой неэффективной системе появятся более простые процессы, не вовлекающие сложную бюрократию. Где-то они в каких-то точках будут пересекаться, но в целом процесс будет быстрее и эффективнее. Надо знать нужных людей :) Вот и все.
А что у вас, мои немногочисленные читатели, вызывает самые большие проблемы в работе? :)

Засим раскланиваюсь,
Рустам.

Ответственность за принятие решений в проектах

Posted on Sunday 8 May 2011 under , by Rustam Sydykov

Привет, народ!

Несколько раз я был в ситуациях, когда при работе над какой-либо задачей возникал рабочий конфликт интересов. Т.е. несколько заинтересованных сторон решали, как лучше сделать что либо и не могли прийти к одному общему решению. Часто это  случается, когда стороны имеют одинаковый “вес” в плане возможности принятия решений.
Особенно ярко этот конфликт проявляется при обсуждении соглашения об именах/названиях: будь то учетные записи, имена компьютеров и т.п. Не дай бог участвовать в этом! :) Религиозные войны не идут ни в какой сравнение! Или, к примеру, есть проект, в котором какую-либо задачу можно решить либо одним способом, либо другим. Если есть два мнения, предложенные конфликтующими или конкурирующими группами/людьми, эти способы будут защищаться с самым яростным юношским запалом.
Чтобы не оказаться в подобной ситуации, надо сразу определиться с главными типами людей, вовлеченных в работу над чем-либо:

  • Заказчики (“stakeholders”)
    Это тот, кто, собственно, “платит деньги”. Эти люди не должны участвовать в непосредственной “текучке”, он являются “высшей” инстанцией, если отвественные лица (о них ниже) не могут разрешить конфликт. Как правило заказчики – это директора, начальники департаметов и т.п.;
  • Ответственные лица (“accountable”)
    Непосредственно назначенные заказчиком для руководства и остлеживания прогресса выполнения задачи или проекта, оценки качества выполнения. Одной из главных обязанностей этих людей и является разрешение спорных моментов при их возникновеннии.

В дополнение к двум типам, обозначенным выще, разные методики управления проектами распознают еще две возможные роли: “Исполнитель” (“Responsible”) и “Консультант” (“Informed”). “Исполнитель” – это тот, кто выполняет работу (т.е. если работать на кого-то, значит “исполнитель” – это вы или я, плюс еще вовлеченные в проект люди, выполняющие какие-либо задачи, а “консультант” – кто-то, кто может предоставить необходимую информацию, важную для успешного завершения работы.
Так что я хотел сказать. Надо очень четко определить роли еще до начала любой работы. Желательно избегать совмещения ролей “ответственного лица” и “исполнителя” – трудно самого себя контролировать и оценивать качество исполнения :) Существование авторитета, способного принять решение (если нет – беда), позволяет выступать ответственному лицу или лицам третейским судъей.
Заказчик, как правило, напрямую не занимается решением таким вопросов если они не оказывают критического влияния на конечный результат.
В следующем посте будут несколько рекоммендаций, как категоризировать людей в проекте по типам.
По больщому счету ничего умного я не написал. Но я лично был в проекте, который не мог сдвинуться с “мертвой точки” полгода только потому, что две стороны “тянули одеяло” на себя и никто не мог стукнуть кулаком по столу и сказать: “Делайте так, так и так!” :)

Засим раскланиваюсь,
Рустам.

Оценка качества требований

Posted on Saturday 30 April 2011 under , by Rustam Sydykov

Привет, народ!

В предыдущем посте я упоминал, что после того, как сформулированы требования к функционалу (Functional Requirements (FRs)) и его качественным характеристикам (Non-Functional Requirements (NFRs)), необходимо оценить, насколько качественными являются собранные или сформулированные данные. Иметь некачественные FRs/NFRs это так же плохо, как и вообще не иметь их. Рекомендуется произвести первоначальную оценку качества и полноты FRs/NFRs. Ничего нового я не расскажу тем, кто уже ознакомился с TOGAF. В любом случае, случае, я постараюсь рассказать от себя о первоначальной оценке с помощью критериев S.M.A.R.T (Specific, Measurable, Actionable, Realistic и Time bound).
В принципе, методика SMART может применяться не только в IT. Если подумать, то это просто подход с точки зрения здравого смысла. Если есть какие-то требования, надо проверить, что они:

  • Конкретные (Specific)
    Если задача или требование сформулировано очень расплывчато – “сделайте мне красиво”, то можно сказать, что ничего у вас нет. Надо избегать неясных формулировок;
  • Измеряемые или допускающих количественную оценку (Measurable)
    Это как-был уточнение первого требования, чтобы сделать его более конкретным, вводя количественные характеристики. Например, я столкнулся при работе над одним проектом с требованием, чтобы уменьшить время входа в систему (логина) на компьютерах под управлением Windows XP. Требование конкретное, но абсолютно невозможно понять, в чем проблема и насколько надо улучшить время входа: то ли сейчас время составляет один час, и бизнес будет счастлив уменьшить его до 45 минут, то ли время входа составляет 10 секунд и бизнес хочет добиться входа за меньше чем за секунду. Опять же, непонятно, надо ли достигнуть этого для всех пользователей, или только для тех, у кого сейчас время входа больше часа, сколько пользователей имеет такую проблему т.д. Для того, чтобы сделать требование имеющим хоть какой-нибудь смысл, оно должно было бы быть сформулировано подобным образом: уменьшить время входа, используя как цель время входа в систему эталонного пользователя с соотвествующим профилем (ссылка на максимальные, минимальные и среднее время для таких пользователей).
    Точно так же и в реальной жизни можно придумать как использовать подобный критерий. Например, можно решить купить машину. Конкретно? Конкретно. Но вот какую!? Если пойти купить какую-нибудь малолитражку для семьи из 7-ми человек, то это будет самый глупый поступок. Для улучшения первого критерия надо будет упомянуть еще хотя бы максимальное количество человек, которое будет перевозиться в такой машине; бюджет, желаемых расход, вид топлива плюс обязательные (кондиционер, к примеру) и желаемые опции (автоматическая коробка передач и т.п.). Купленная машина, руководствуясь такими критериями, скорее всего будет удовлетворять поставленным целям.
    Я думаю, каждый в жизни когда-нибудь сталкивался с подобными ситуациями: уменьшить время отклика приложения (насколько!?); улучшить “дружественность” приложения к пользователю (это как!? как это измерить!?) и т.д;
  • Ясно описывающие проблему/цель (“Actionable”)
    Данный критерий позволяет убедиться, что есть понимание цели или проблемы и это позволит составить предварительный список того, что надо сделать. Иными словами, должно быть понятно, что надо будет сделать. Например, требование “увеличить производительность труда сотрудников” вряд ли можно назвать ясным. Оно должно быть переформулировано в что-то типа: “Увеличить производительность труда сотрудников путем оптимизации программного обеспечения, используемого сотрудникпми для выполнения непосредственных обязанностей. Производительность может быть достугнута перепланировкой интерфейса приложений с целью уменьшения <времени ввода данных, заполнения форм и т.п.> и повышения производительности серверных компонент приложений: <уменьшения времени отклика/уменьшения времени для получения отчетов и т.д.>;
  • Требования должны быть реализуемые/достижимые (Reasonable)
    Здесь нужно подходить с позиции здравого смысла: являются ли выдвигаемые требования реалистичными или достижимыми? Если, согласно требованию, нужно построить космический корабль и приземлиться на Солнце, то при нынешнем уровне технологий такое требование не является реализуемым. Так же, как и например, требование сокращения времени загрузки компьютера до 1 сек. с момента нажатия кнопки включения :);
  • Указывающие время выполнения (Time bound)
    В данном случае для выполнения данного критерия надо убедиться, что указаны временные рамки для выполнения заданых требований. Вполне возможно, что все будет сформулировано четко, ясно и недвусмысленно, но вот сроки на выполнения будут не указаны вообще (в таком случае скорее всего ожидается “мгновенное” выполнение задачи, что может быть невозможно) , или предоставляются совершенно нереалистичные сроки. К примеру: построить ракету для полета на Луну <требования и описания> и закончить постройку завтра :)

В реальной жизни при стандартных операциях или задачах многие критерии подразумеваются по умолчанию. Просьба сходить в магазин за молоком скорее всего подразумевает, что надо отправиться туда “как только так сразу”, купить то молоко и в том количестве, которое покупалось все время. Самое главное, точно знать, что все вовлеченные лица пользуются одними и теми же значениями по умолчанию.
И еще: SMART может использоваться как при проверке предъявляемых требований, так и при их предъявлении. Когда вам прийдется что-то просить сделать, не забудьте сформулировать свои требования так, чтобы другой человек проверил их по этой методике и остался доволен :)

Засим раскланиваюсь,
Рустам.

Требования к функциональности систем/решений

Posted on Monday 18 April 2011 under by Rustam Sydykov

Привет, народ!

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

  1. Требования к функциональности системы (так называемые “functional requirements” (FRs)).
    В это входит описание “что” должна делать система/решение/сервис или приложение. Например: почтовая система должна предоставлять возможность коллективной работы (календарь, общие папки), позволять обмениваться е-мейлами внутри предприятия и с другими организациями через интернет; антивирусная система для файл серверов должна проверять файлы на запись/чтение и т.д.;
  2. Требования спецификации системы (“non-functional requirements” (NFRs))
    Это описание того “как” должна работать система/решение/сервис или приложение. Иными словами – описание “качества”. Например: файловый антивирус должен быть обновлен не позднее чем через 1 час после того, как производитель антивируса обновит антивирусную базу; антивирус не должен использовать более 10% ресурсов файлового сервера в пиковое время и т.п.

Я бы посоветовал любой проект или изменение в существующих сервисах начинать с попытки формального определения FRs/NFRs. Особенно если это включает предоставление услуг клиенту и сопряжено с финансовой ответсвенностью. В этом случае крайне желательно составить формальный документ, описывающий требования и официально подписанный обеими сторонами :)
Несмотря на простоту, очень часто бывает трудно сформулировать эти требования. Невозможно сформулирвать стандартные FRs, так же как NFRs, напрямую зависящие от FRs.
Если бизнес не может определиться, что должно входить в FRs, можно попробовать ему помочь, задавая наводящие вопросы:

  • Бизнес предлагает уже выбранное им решение или приложение. Вполне возможно, что выбор правильный, не тем не менее внедрение приложения или решения/сервиса должно решать определенные бизнес-задачи: “Какие задачи в бизнесе вам предстоит решать, используя это приложение? Какая выгода от этого будет?”;
  • Бизнес не может предоставить четкую задачу или описание задачи слишком расплывчато: “Какая(ие) проблема(ы) существует? Как вы думаете, как ее можно решить? Что будет, если данная проблема не будет решена?”;
  • Бизнес не может определить границы проекта: ограничиться ли одним отделом, внедрить на всем предприятии и т.п.: “Какая часть бизнеса или бизнес-процессов получит выгоду в после окончания проекта? Как часть бизнеса страдает от проблемы, которую предстоит решить? Каков бюджет, выделенный на проект?”

Можно предложить рассмотреть косвенные выгоды, такие как: возврат инвестиций (ROI) – прямая/косвенная выгода; улучшение масштабируемости сервиса/системы/приложения, увеличение производительности, приведения к стандартам/требований законов/нормативов, улучшение производительности пользователей и т.д. Собрав эту информацию, можно попытаться сформулировать FRs.
В качестве типовых NFRs можно предожить определить:

  • Производительность системы (performance)
    Если брать в пример ту же почтовую систему, то требование может звучать так: обеспечивать отклик системы не более…, среднее время доставки внутри предприятия – …, время отправления/получения е-мейла, отправленного через и-нет – … и т.п.;
  • Запас производительности/мощность сервиса/системы (capacity)
    Например: почтовая система должна предоставлять сервис для …пользователей, средний почтовый ящик не более …МБ, среднее количество писем, отправляемых в день и т.д.;
  • Масштабируемость (scalability)
    Почтовая система должна обеспечивать требуемую производительность с учетом роста количества почтовых ящиков на … в год;
  • Доступность (availability)
    Почтовая система должна предоставлять сервис 99.9% рабочего времени в год или 24х7 :)
  • Восстанавливаемость (continuity)
    В случае сбоя, система должна быть востановлена в течении … часов и с потерей не более чем …% данных пользователей;
  • Безопасность (security)
    Система должна быть защищена от несанкционируемого доступа; доступ к почтовым ящикам для авторизированных пользователей через интернет только с шифрованием трафика ключем не менее …. бит и т.д., и т.п.

Когда все эти требования собраны, надо в обязательном порядке “пропустить” их через фильтр критериев: S.M.A.R.T. Об этом в следующем посте.

Засим раскланиваюсь,
Рустам.

“Модные” методики в IT

Posted on Monday 4 April 2011 under , by Rustam Sydykov

Привет, народ!

После определенного уровня проектов, в которых участвовал, или размеров компаний, на которые работал, невозможно не столкнуться с различными методиками, которые если не применяются, то хотя бы упоминаются типа “мы внедрили упрощенную версию методики Х или частично методику Z”. Без этого как бы стыдно говорить о больших проектах или работе IT службы на крупном предприятии. Поэтому об этих вещах надо хотя бы иметь какое-то представление. В моем случае это архитектура и внедрение IT проектов, связанных с инфраструктурой (сервера, приложения), а не программирование (а жаль ).
Итак, по порядку:

  • Методика, описывающая полный цикл создания и управления IT архитектурой масштаба предприятия – TOGAF. Это даже не медотика для создания архитектуры, а набор правил, принципов, рекомендаций для создания процесса создания архитектуры :) Так как TOGAF – достаточно высокоуровневая общая методика, с ее помощью сразу так IT архитектуру не построишь. Существуют еще специализированные методики, которые  могут применяться в той или иной отрасли. Следующим этапом для IT, например, может быть Zachman Framework.
    Если кому-то интересно, TOGAF можно скачать бесплатно с сайта http://www.togaf.org/. Я сейчас как раз где-то в середине цикла чтения. Более академического, сухого и скучного чтения я не пытался осилить со времен института, когда должен был готовится к экзаменам по теоретической физике :) Но читаю, потому что деваться некуда. Если честно – там очень много полезного, просто написано так, что спать клонит на 5-ой минуте. Я спасаюсь тем, что чтение разбил на две части по 15 минут: читаю в метро, когда еду на работу в метро с железнодорожной станции и потом обратно. В поезде предпочитаю что-нибудь повеселее :)
    Как и с другими методиками, я в жизни никогда не встречал полного следованию всему циклу разработки архитектуры. Всегда применялись упрощенные процессы. Если формально следовать всем рекомендациям, то для того, чтобы только начать разрабатывать архитектуру, надо будет написать порядка 20-ти документов :) Никто этого делать, конечно, не будет;
  • Внедрение проектов. Здесь больше поле деятельности менеджеров проектов. Но есть несколько распространенных “учений”:
    • Чаще всего говорят о PRINCE2. В этой области я вообще не силен, хотя неплохо было бы для меня пройти курс PRINCE2 Foundation. Все курсы Foundation дают общее понятие о предмете, не вдаваясь в детали. Полезно для того, чтобы иметь хоть какое-то представление и использовать одну и ту же терминологию;
    • От себя добавлю про Microsoft Solution Framework (MSF). Хотя основная цель в нем – разработка программного обеспечения, тем не менее для небольших проектов ее вполне  можно применить. Полный набор документации по этой методике можно скачать здесь.
  • Поддержка и управление IT средой:
    • Признанный лидер здесь ITIL. Позволяет по другому взглянуть на IT как набор сервисов, а не операционные системы и приложения. Опять же, имеет смысл пройти хотя бы курс ITIL Foundation, чтобы понимать, о чем будет разговор с каким-нибудь IT менеджером после сдачи проекта.
      Боюсь повториться, но не видел ни разу полного внедрения ITIL. Основной “гвоздь” ITIL – CMDB. Создание, внедрение и поддержка CMDB может оказаться неподъемной задачей для многих компаний, особенно в том случае, если ожидается мгновенная отдача от внедрения ITIL.
    • Опять же, менее академичный и более простой подход: MS Operations Framework (MOF). Читается легко, объем материала приемлемый. Даже если вы не собираетесь заниматься операционной поддержкой IT, я бы порекомендовал почитать MOF для общего развития. Я когда-то с этого начинал :)

Ну вот и все. Любые дополнения приветствуются.

Засим раскланиваюсь,
Рустам.

Ошибки, сделанные при работе над проектами

Posted on Tuesday 29 March 2011 under , by Rustam Sydykov

Привет, народ!

В данной статье я хотел бы рассказать об ошибках, которые я когда-либо наблюдал при работоте над проектами. В некоторых ошибках была моя прямая вина, за другие я с радостью переложу ответственность на людей, которые были заняты со мной в различных проектах. Некоторые вещи были достаточно тривиальные и при правильном подходе можно было бы легко их избежать, другие проявлялись из-за системных проблем, таких как отсутствие взаимодействия между командами, работающими над разными задачами в проектах.
Немножко отвлекусь: все, что не делается/внедряется в IT, делается для кого-то. Очень тяжело найти проекты, которые начинаются и внедряются только ради самого IT. Кто-то, а это может быть или бизнес, на которого работает IT отдел, или клиент, который обратился в IT фирму разработать программу или решение, всегда получает напрямую или косвенно какие-либо результаты труда (и хочется верить – улучшения) IT отдела или поставщика. Поэтому к рассмотрению ошибок, сделанных при работе над проектам я предпочитаю подходить с этой точки зрения – с точки зрения выгоды, получаемой бизнесом или клиентом.
Если проект разделить на три фазы: начало проекта, внедрение и окончание, то каждая из фаз может иметь свои организационные (связанные с общим ходом проекта) и технические (техническое внедрение решения, выбор технологии и т.п.) проблемы. (Кстати, поймал себя на том, что мне тяжело использовать слово “проблемы”. В английском “problems” употребляется в смысле “проблем, которые очень трудно или невозможно решить”. Эквивалентом слова “проблемы” в английском является “issues” :))
В начале проекта самые большие ошибки, с которыми я сталкивался, были в основном организационные просчеты:

  1. Начало работы над проектом без четких указаний от бизнеса: так называемых функциональных и не-функциональных требований (“Functional/Non-Functional Requirements (FRs/NFRs)”). Много распространяться на эту тему не буду, скажу только, что функциональные требования описывают что должно делать внедряемое решение, в то время как не-функциональные требования должны определять “как”, т.е. количественные и качественные характеристики. Если этих требований нет – это означает, что бизнес сам не понимает, что он хочет и можно потратить кучу времени и усилий на проект, который в конечном счете или “похоронят”, или потом  будет мучительно стыдно за результат работы :);
  2. Не определены ясно и четко цели, область и бюджет проекта. В начале следует или получить от бизнеса, или самому “подвести за ручку” бизнес к составлению формального документа, который будет описывать: какие проблемы проект должен решить, какая будет выгода для бизнеса, сколько это займет времени и сколько это будет стоить. Это все, что нужно бизнесу знать! Бизнес не интересует какие модные технологии будут использоваться, как это будет сделано и т.д. Все, что интересует бизнес/клиента – “Сколько это будет стоить в деньгах и времени? И что мне с этого будет?”. Если ответы на эти вопросы будут кристально ясны – можно надеяться на поддержку проекта;
  3. Не определены ключевые люди в проекте: заказчики (“stakeholders”); люди, в ответственность которых входит принимать решения по текущим вопросам, возникающих в ходе проекта в случае любых неточностей/конфликтов интересов (“accountable”); прямые исполнители (“responsible”), а так же те, кто более-менее заинтересован в успешном внедрении проекта и/или могут предоставить полезную информацию, которая может помочь с внедрением проекта (“informed” и “consulted”). Это могут быть рядовые сотрудники в бизнесе, которые знают в деталях области (использование программ, бизнес-процессы и т.п.), затрагиваемые в проекте.

Во время внедрения проекта самыми распространенными организационными ошибками были:

  1. Ошибки в планировании необходимого количества ресуросов: инженеров в разных технических направлениях, менеджеров проектов и т.д.;
  2. Недостаток знаний и умений у персонала, вовлеченного в проект. Были ситуации, когда решения “спускались  сверху” к выполнению, в то время как инженеры ни слухом ни духом не слышали о том, что надо делать и не имели опыта работы с требуемыми технологиями;
  3. Отсутствие видимости прогресса и отчетности для заказчика. Вроде бы мелочь, но если проект сложный и растянут по времени, у заказчика может сложиться впечатление, что ничего не происходит. Опять же, многие технические специалисты в силу природной скромности :) не сообщают о каких-либо удачных решениях. Как показывает практика, умение играть в “политические игры” и представление в лучшем виде своих заслуг и достижений – лучшее средство для получения прибавки в зарплате и каръерном росте.

Нельзя сказать, что техническая сторона всегда была на высоте. Основными ошибками  были:

  1. Использование технических решений, которые не соотвествуют требованиям. Это, скорее, результат подхода к проекту без понимания целей и требований бизнеса. Используется “модное” решение, которое вполне может не подходить по ряду причин в данный момент в данной ситации. Например, использование сервера баз данных Oracle вместо более дешевой и простой альтернативы из-за того, что Oracle “круче”. Без знаний и опыта работы с Oracle это может привести к проблемам вместо “летающей” баз данных;
  2. Внедряемые решения конфликтуют с существующими IT сервисами. Вариантов - масса. Даже самый простой пример: использование серверной операционной системы, не поддерживаемой существующей системой создания резервных копий.  Что будет при возникновении непредвиденной ситуации, связанной с полной неработоспособностью сервера и невозможностью восстановить его с “ленты”!?
  3. Внедряемые решения не согласуются со стратегией бизнеса. Это, конечно, более “туманное” определение проблемы, если коротко – то бизнес и IT двигаются в противоположных направлениях. Бизнес может постепенно “децентрализироваться”: переводить разные службы из центрального офиса в регионы, а IT служба не замечать этого и развивать IT сервисы для поддержки старой модели бизнеса. Может случиться, что после окончания проекта он будет никому не нужен именно из-за этого.

Ну а после окончания проекта возможна ситуация, когда проект не удовлетворяет бизнес или заказчика из-за:

  1. Несоотвествие ожиданий бизнеса и результатов. Является следствием ошибок в начале проекта п.2 (“цели, область и бюджет”) и п.3 при внедрении (“отсутствие отчетности”). Вполне допустимо менять по ходу внедрения цели проекта, но любые изменения должны быть согласованы и подписаны с заказчиком;
  2. Проект закончен, но с существенным превышением бюджета. Без соответствующей отчетности будет тяжело указать на причины превышения затрат, пусть даже они были и вызваны объективными причинами (бизнес мог  изменить требования, что привело к переделке, а следовательно, к удорожанию проекта);
  3. Проект закончен с большой задержкой. Так же, как и в п.2, важно знать, чем это было вызвано.

В принципе, п.1-3 окончания проекта уже никак не исправишь. “Поздно пить боржоми…” :) Но при правильном подходе, при хорошей отчетности во время проекта, можно избежать больших споров с бизнесом/заказчиком по всем этим пунктам.
Напоследок хочу сказать: ни в коем случае нельзя соглашаться с бизнесом или заказчиком что-либо переделать в проекте без формального рассмотрения этого как изменения требований! Заказчик очень часто не понимает, что с “небольшие” изменения в проекте, особенно как результат “забывчивости” со стороны бизнеса о важной функциональности, могут вылиться в полную переделку решения. А это время, деньги и, что немаловажно, конечный результат и ожидания бизнеса. Если становится понятно, что количество мелких изменений переходит определенный порог или изменения могут привести к задержкам по срокам, цене – драться надо отчаянно и стоять до последнего! :) Пока бизнес/заказчик не подпишет документ об изменении в требованиях.
И совсем коротко, так как я планирую не накоторых вещах рассказать в следующих постах. Ничего нового изобретать не нужно, все уже давно изобретено: существуют много методик для ведения проектов (Prince2 и т.п.), методик разработки решений с технической точки зрения (TOGAF, Microsoft framework) и управления сервисами (ITIL).
Напоследок рекоммендую прочитать пост Алексея ГлазковаПравила работы надо проектом”.
Это все, что я могу сказать по поводу ошибок. Любые дополнения приветствуются :)

Засим раскланиваюсь,
Рустам.

Выгоды от аутсорсинга. Часть шестая (последняя)

Posted on Tuesday 22 March 2011 under by Rustam Sydykov

Привет, народ!

В заключение своих мрачных постов об опасностях аутсорсинга :) (часть первая, вторая, третья, четвертая и пятая) я бы хотел кратко остановится на преимуществах аутосорсинга. Много писать не буду, достаточно взять и почитать любой пресс-релиз компании аутсорсера, чтобы “проникнуться” положительными эмоциями :) Я же попытаюсь сделать акцент на очевидных и неочевидных выгодах аутсорсинга для бизнеса.
Итак, основные области, где компания/бизнес может получить какую-то отдачу:

  • IT сервисы;
  • Наличие подготовленного персонала (“гарантированно” и “по требованию”);
  • Расходы на IT сервисы и персонал;
  • Стратегия, связанная аутсорсинга.

В IT сервисах главным преимуществом является то, что аутсорсер, при правильном подходе к аутсорсингу со стороны бизнеса, может улучшить существующие сервисы. Как я уже писал, это может произойти при обоюдном желании: бизнеса – предоставить бюджет, а аутсорсера – инвестировать ресурсы и понести какие-то еще незначительные косвенные затраты.
Аутсорсер так же может помочь с внедрением новых сервисов, которые были бы недоступны без помощи аутсорсера. Аутсорсер может предоставить персонал (инженеров, менеджеров проектов и т.п.), обладающих необходимыми знаниями и умениями для внедрения сложного решения, а потом оказывать поддержку этой системы.Бизнес мог бы, конечно, воспользоваться консультатнами для внедрения, но вопрос поддержки все-равно бы потом “всплыл”.
Персонал: огромным “плюсом” любого крупного аутсорсера является наличие пула ресурсов. Это важно как и для краткосрочных, так и для долгосрочных проектов. Как я уже упомянул выше, бизнес может воспользоваться консультантами для внедрения какого-либо решения или системы. Но консультанты бизнесу будут обходиться раза в два дороже, чем дополнительный персонал аутсорсера, временно нанятый на срок выполнения проекта. А потом, как дополнительная “плюшка”, аутсорсер может дешевле взяться поддерживать систему, так как она была внедрена силами самого аутсорсера. Единственным “минусом” может являться то, что бизнесу для затребования необходимых ресурсов надо будет следовать формальным процессам, чтобы затребовать этот самый персонал аутсорсера, но я думаю, что на это уйдет или столько же времени, как на поиск консультантов, или даже меньше.
Расходы на IT сервисы и персонал: в случае с IT сервисами все просто. Основными преимуществами являются: возможность получения оговоренных IT сервисов за заранее оговоренную цену (финансовый отдел бизнеса будет пищать от восторга!) и понижение стоимости IT сервисов за счет разделяемых сервисов/ресурсов. Как это выглядит на практике, к примеру: аутсорсер может иметь систему мониторинга, за которую он выплатил N-ую сумму производителю этой системы и теперь имеет неограниченное количество клиентских лицензий. Или, как крупный клиент, имеет существенную скидку на клиентские лицензии. Используя эту систему мониторинга на своей инфраструктуре для разных своих клиентов, аутсорсер понижает издержки для себя и, если это не жадный аутсорсер, передает экономию в расходах своим клиентам. Т.е. бизнесы платят меньше, чем платили бы они, если бы сами покупали лицензии и внедряли решения на своей платформе.
С персоналом картина получается еще радужнее. Одна из самых больших статей расходов в развитой капиталистической стране является выплаты работникам (зарплата, больничные, отпускные и т.д.). Бизнес может экономить за счет использования аутсорсером более дешевой рабочей силы. Кроме того, в завимости от контракта, бизнес всегда может иметь гарантированное количество персонала аутсорсера, работающего на него. Т.е. отпуска, больничные и недостаток персонала бизнес волновать не будет. Сказано в контракте – два инженера 24х7, пусть аутсорсер  думает, где и как ему найти нужное количество инженеров :)
В случае аутосринга, бизнесу нет необходимости оплачивать обучение и курсы сотрудников. Это, опять же, задача аутсорсера - предоставлять бизнесу ресурсы с готовыми знаниями :)
Так же бизнес может существенно сэкономить за счет того, что сотрудникам аутсорсера не надо предоставлять дополнительные “бенефиты”: доплачивать в пенсионный фонд, оплачивать больничный и отпускные, премии и т.д. В случае кризиса и последующих увольнений бизнес не связан никакими обязательствами перед работниками аутсорсера: никаких выплат по сокращению, пособий и т.д.
Вот, наверное, и все. Данные “измышления” базируются на моем опыте. Кто-то может дополнит, если я много чего пропустил.

Засим раскланиваюсь,
Рустам.

Аутсорсинг – возможные проблемы. Часть пятая.

Posted on Wednesday 16 March 2011 under by Rustam Sydykov

Привет, народ!

Не беспокойтесь, я уже почти закончил свою сагу об аутсорсинге. Осталось совсем чуть чуть! Потерпите :)
Итак: как вы поняли из заголовка поста, я хочу сказать несколько слов о проблемах аутсорсинга. Об этом надо задумываться еще до того, как принято решение аутсорсить IT или нет. Когда решение сделано, очень тяжело, даже психологически, “сдать назад”. Поэтому когда “процесс пошел”, руководящий состав старается не замечать возможные проблемы.
Не претендуя на правоту, я бы сказал, что существует несколько важных моментов, которые могут негативно повлиять на результат перехода на модель аутсорсинга:

  1. Различие/отсутствие бизнес-процессов, управление и культура:
    • Разное понимание целей между компанией, аутсорсящей IT и самим аутсорсером – если компания, отдав аутсорсеру IT, “выторговав” себе крайне дешевый контракт поддержки, ожидает, что аутсорсер вдруг ринеться внедрять новые сервисы, производить апгрейд операционных систем настольных компьютеров и серверов, то эта компания очень ошибается :) Аутсорсер будет стараться сэкономить на поддержке как только можно, вполне и за счет качества. Поэтому сразу же на самом первом этапе обе стороны должн договориться, что ожидается получить в результате. Даже если это будет просто констатация намерений, но ясность в целях позволит обозначить “горизонты”, пусть это и повлияет на цену контракта в сторону удорожания. Зато все будут избавлены от появления неприятных сюрпризов в виде взаимных претензий;
    • Неготовность компании следовать формализованным процессам/отсутствие процессов в отношениях с аутсорсером – как я уже писал, аутсорсер не может интегрироваться в бизнес и в организационную структуру компании. Для эффективного взаимодействия с аутсорсером, компания должна “построить” связующие бизнес-процессы. Это приводит к интересному моменту: когда аутсорсится IT, компания может ожидать, что она подчистую избавится от внутреннего IT. Как бы не так! От технических специалистов она, может, и избавится, но взамен над будет создать организационную единицу, которая будет взаимодействовать с аутсорсером: контролировать выполнение, качество и т.д. Может возникнуть парадоксальная ситуация, когда маленький IT отдел будет заменен штатом более высокооплачиваемых сотрудников для работы с аутсорсером, что в конечном счете приведет к более высоким затратам на этих людей в плане зарплаты :);
    • Проблемы взаимодействия/управления аутсорсером:
      • Контроль качества – когда IT предоставляется внутренней службой/департаментом, гораздо легче получить правдивую картину о качестве IT. Если IT за-аутсорсено, очень тяжело понять, насколько предоставляемые IT сервисы соотвествуют требованиям качества;
      • Остутствие опыта управления распределенной средой – ресурсы, распределенные географически и в разных временных зонах. Вроде бы простая вещь, но для некоторых компаний может стать “камнем преткновения”: бизнесу, привыкшему к “карманному” IT, трудно перестроиться на взаимодействие с IT, которое расположено не на “расстоянии вытянутой руки”. Если раньше любые совещания, вопросы решались просто, можно было просто послать приглашение на совещание и собраться в какой-нибудь комнате, то организовать то же самое, но с людьми, которые находятся, скорее всего, на другом континенте и в другом часовом поясе, будет нелегко. Конечно, аутсорсер организовывает поддержку бизнеса, “выравниваясь” по рабочим часам компании, но это не означает, что все работники аутсорсера будут работать так. Скорее всего первая-вторая линия поддержки будут доступны все время, а вот с другими сотрудниками прийдется согласовывать время. Когда мой предыдущий работодатель организовал совместный бизнес с американцами и нам нужно было что-либо согласовать с техническими специалистами в Штатах, мы назначали совещание на 4-6 вечера, а у них это было раннее утро. Мы жертвовали своим свободным временем (я тогда работал до 16:00), а американцы часто выходили на связь прямо из дома – проснулись, почистили зубы и вперед – конференц-связь.
    • Различная культура общения. Сейчас ситуация улучшается за счет большего присутствия работников аутсорсинговых фирм в офисах компаний, пользующихся их услугами, но раньше это создавало много проблем и недопониманий. Например, индусы никогда не говорили “нет”. Можно было составить подробный план со списком задач, которые они должны были бы выполнить. Даже если работники в  Индии понимали, что столько им не сделать, они все-равно говорили “ОК”. Естественно, когда все задачи не выполнялись, бизнес начинал требовать объяснений, а индусские аутсорсеры недоумевали, что это от них хотят, ведь это сразу было понятно, что они этого не сделают!? :) Именно поэтому нормальные аутсорсеры, которые должны взаимодействовать с бизнесом, стараются увеличить свое “присутствие” у клиентов, нанимая сотрудников со знанием культуры в данной стране. Пусть даже и иммигрантов с других стран ;))
  2. Уровень услуг:
    • Недостаточно высокое качество предоставляемых IT сервисов:
      • Персонал аутсорсера с низким уровнем знания и опыта. IT индустрия в странах, предоставляющих аутсорсинг, сейчас переживает бум. Как некоторое время назад в развитых странах, в IT сейчас идут кому не лень. Минимальные знания вдруг дают право людям называться инженерами. Имейте в виду, что контролировать кто там сидит на другом конце земного шара и нажимает на кнопки крайне тяжело (см выше);
      • Персонал аутсорсера может быть подвержен процессу текучки. Люди приходят, ходят и, как следствие, постепенно теряются накопленные знания. По большому счету, это проблемы атусорсера, но будет обидно, если проблемы аутсорсера рикошетом ударят по бизнесу;
      • Отсутствие стимулов и причин к повышению качества. Этот пункт немножко спорный, но, тем не менее, есть вполне оправданные подозрения, что это так. Чаще всего атсорсинг рассматривается как возможность сэкономить деньги. Т.е. получить все задешево. Но иногда для того, чтобы получить экономию, надо будет вложить достаточно большие деньги. Аутсорсер понимает, что после окончания контракта есть шанс проститься с клиентом, поэтому не хочет вкладывать свои деньги или ресурсы в глобальные проекты. А бизнесу будет трудно смириться с тем, что вместо экономии в IT они могут получить еще одни расходы. Аутсорсер будет внедрять без поддержки бизнеса только то, что не потребует больших вложений (прямо – деньгами, или косвенно – временем работников) и даст результат сиюминутно. У постоянно же IT персонала может быть дополнительная мотивация, чтобы “инвестировать” хотя бы свои усилия в то, чтобы улучшить IT.
  3. Цена:
    • Оплата услуг, невошедших в первоначальный контракт, может сильно отличаться от цены на остальные сервисы. Как правило, компании, за-аутсорсившие IT, после подписания контракта и передачи IT аутсорсеру теряют главные рычаги воздействия на аутсорсера. Как я уже говорил, очень трудно описать всё в контракте и после некоторого времени бизнес может попасть в “мышеловку”, когда внутренний IT выполнял массу задач, не обговоренных в контракте, и потом обнаруживается, что это крайне важно. Аутсорсер в зависимости от жадности и условий контракта может запросить вполне нескромную цену :) Одна из компаний попалась на эту удочку: она сначала “прижала” аутсорсера контрактом, заставила сделать пару проектов задаром. А потом оказалось, что любой “чих” обходится в большие деньги. Все, что не попадало под контракт, оценивалось в десятки тысяч фунтов. Попытки бизнеса сделать что-то по мелочи самими выливалось в отказ аутсорсером поддерживать эти системы. Представьте себе, когда вам надо перенести пару компьютеров с одного офиса в другой. Аутсорсер выставляет такую цену, что бизнес решает силами своих сотрудников перетащить эти компьютеры и подключить кабеля. После этого аутсорсер заявляет, что эти комьпютеры он не будет поддерживать, так как изменения были внесены не квалифицированными сотрудниками :) Бизнес вынужден был заплатить аутсорсеру за “сертификацию” этих компьютеров “квалифицированными сотрудниками”, после чего аутсорсер “добил” бизнес заявлением о тем, что эти компьютеры уже не попадают под действие предыдущего контракта и на них надо заключать новый (более дорогой, естественно!) :)))
  4. Стратегия:
    • Аутсорсер может не стремиться внедрять сервисы, которые в долгосрочной перспективе принесут экономию компании (бизнесу). На это могут быть разные причины: нежелание инвестировать свои ресурсы, нехватка ресурсов или просто тупое желание продолжать “рубить капусту”;
    • В зависимости от отношений аутсорсера и бизнеса, может возникнуть такая ситуация, когда стратегические проекты будет почти невозможно не то что провести, а даже начать! Причиной может быть недоверие между бизнесом и аутсорсером, культура бизнеса и т.д. Очень часто бывает, что люди из внутреннего IT уходят в новую структуру, которая занимается координацией проектов между бизнесом и аутсорсером. Как вы думаете, насколько беспристрастно эти люди могут работать с аутсорсером? Скорее всего, эти работники будут явно или неявно стараться насаждать свои идеи, как что-то должно быть сделано. Такова человеческая природа. Трудно перестроиться и признаться, что теперь ты не технический специалист, а просто еще один бизнес-аналитик. К слову: в этом нет ничего плохого и даже открываются неплохие перспективы в плане каръеры. Бизнесу будут важны люди, которые знают две стороны: бизнес и IT. Аутсорсеры будут меняться, а эти люди в бизнесе – нет;
    • Аутсорсер может упустить что-либо из-за непонимания бизнеса компании и возможной выгоды для бизнеса.
  5. Персонал и отношение к работе:
    • Сотрудники аутсорера не будут лояльны к бизнесу. Только товарно-денежные отношения. Хотя, наверное, термин “лояльность” не применим к персоналу, предоставляемым аутсорсером. Какой-то определенной благодарности можно добиться :) Например, практикуется приглашение персонала аутсорсера на регулярные “дринки”, оплачиваемые, естественно, бизнесом;
    • Самой главной проблемой является невозможность получать ресурсы (т.е. инженеров) “на лету”. Я говорю о том случае, когда бизнесу надо “кровь из носа” что-то сделать еще вчера, а у аутсорсера может и не быть свободных инженеров. Могут иметься в наличие инженеры, но без знания конкретного бизнеса и IT, что не позволит выполнить необходимые задачи в срок. Бизнесу надо будет перестроиться и учиться планировать потребность в ресурсах. Обычное “окно” для затребования “ресурсов” – две недели. Причина проста: как я уже говорил, аутсорсер стремится снижать свои расходы и одним из методов является “размазывание” персонала по нескольким клиентам. Т.е. вроде бы есть прикрепленный к бизнесу инженер, но для какого-либо проекта он будет доступен только после оговоренной даты.
  6. Ну, и самое вкусное: риск/проблема “выхода” из контракта с текущим аутсорсером:
    • После окончания контракта аутсорсер может отказаться/пассивно сопротивляться предоставлять необходимую информацию. Даже просто у аутсорсера может не оказаться необходимых ресурсов для гладкой передачи IT сервисов и инфраструктуры другому аутсорсеру или внутреннему отделу IT. Контракт заканчивается, зачем держать лишних инженеров, кроме самого минимума, необходимого для поддержания работы систем. Момент выхода (окончания контракта) должен быть очень четко оговорен в контракте, чтобы у аутсорсера не было другого пути, кроме как передать необходимые накопленные знания в приемлемом виде;
  7. Сам бизнес по окончанию срока контракта с аутсорсером может не представлять, какую информацию затребовать. Что важно, а что нет. Может сложиться такая ситуация, когда документации много, а насколько она актуальна, насколько полно она описывает имеющуюся IT – непонятно. Тут уж самому бизнесу надо будет проявить себя с лучшей стороны. Как я уже писал, компании 3-го типа будет легко связать существующие IT сервисы с информацией и документами, полученными от аутсорера, остальным прийдется тяжелее.

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

Засим раскланиваюсь,
Рустам.

Аутсорсинг–переходный период. Часть четвертая.

Posted on Monday 14 March 2011 by Rustam Sydykov

Привет, народ!

Продолжая нашу беседу с Сергеем В. в коментариях к предыдущиму посту, сразу хочу сказать: есть две точки зрения на переход с внутреннего IT на сервис, предоставляемый аутсорсером. Первый – это с позиции бизнеса. Для бизнеса переход может быть практически безболезненный, если внутренний отдел IT имел раньше четко обозначенные точки контакта: первая линия поддержки, например. Если бизнес не контактировал со всему уровнями IT подразделения напрямую, то после замены первой линии сотрудниками аутсорсера бизнес-пользователи могут ничего особенного не заменить, кроме разве что первая линия поддержки стала говорить с непонятным акцентом :)
Немножко отвлекусь: в последнее время аутсорсеры из… других стран взяли за моду брать имена людей, которые не напрямую контактировали с бизнес-пользователями. Е-мейлами или, на крайний случай, по телефону. Чаще всего это были IT персонал первой или второй линии поддержки. Жил-был такой Джон Смит, помогал пользователям, рассылал уведомления. А потом его должность за-аутсорсили, а с ним самим с почестями простились (выплата – две недели за каждый проработанный год). Дабы не вводить пользователей с смущение, другой работник далеко-далеко с непроизносимым именем и фамилией получает команду называться “Джон Смит”, меняет себе адрес электронной почты, подпись в “аутлуке” и вперед! Правда, в последнее время эта идея просачивается и в другие области взаимоотношения не только между бизнесом и аутсорсерами, но и между бизнесами. Некоторое время назад я контактировал с менеджером, который “вел” продукт компании, внедренный на одной из моей предыдищух работ :) Я с этим менеджером виделся только один раз, в самом начале, когда только подписывался договор на покупку продукта. Потом все наши контакты сводились к е-мейлам, когда надо было докупить лицензий или решить какие-то проблемы. А вот мои коллеги виделись с ним чаще. Спустя достаточно долгое время этот менеджер захотел со мной встретиться, обговорить планы взаимопомощи (они нам – лицензии со скидкой, мы им – деньги. Время было тогда тяжелое, все поставщики искали возможность хоть что-то заработать). Ну встретились, поговорили. Покупать мы, конечно, тогда ничего не собирались (время было тяжелое :)), но мы все-равно мило посидели поговорили в кафетерии. Я еще позвал своих коллег поздороваться. Надо же быть вежливым. Когда менеджер ушел, мои коллеги сказали, что это не тот человек, который был раньше. У меня ужасная память на лица, да и виделись мы только один раз, поэтому я подвоха не заметил. Вот так и получается, что устраиваешься куда-то на работу, а твои имя-фамилия могут стать корпоративной собственностью :) Прямо “Нортон-коммандер” какой-то :)
Теперь возвращаясь к нашей теме: какие бывают типы перехода с сервисов, предоставляемых внутренним IT, на сервисы аутсорсинга. Не вдаваясь в детали, я бы сказал, что существует два варианта:

  1. Постепенный: внутренний и аутсорсинговый IT сосуществуют некоторое время;
  2. “Большой взрыв”: внутренний отдел IT уходит в заранее определенную дату.

У обоих процессов есть свои преимущества и недостатки. Я думаю, аутсорсеру нравится больше второй тип, в то время как для компании было бы лучше, если бы переход остуществлялся по п.1.
В случае постепенного перехода существуют, как мне кажется, два основных риска для аутсорсера (естественно, это будет влиять на компанию тоже): потеря опытного персонала из внутренней IT службы и явный/неявный сабботаж.
Думаю, не стоит доказывать, что никакой аутсорсер не может сразу взять и начать эффективно поддерживать существуюшие IT сервисы. Даже если все эти сервисы реализованны, используя стандартные компоненты, их интеграция с бизнес-процессами остается вначале за гранью понимания. Поэтому крайне желательно и для аутсорсера, и для компании сохранить хотя бы в первоначальное время тех сотрудников внутреннего IT, которые обладают необходимыми знаниями и умениями. Не секрет, что многие “тонкости” не отображены в документации, а хранятся в головах ключевых сотрудников. Как удержать таких людей – я не знаю. Обычно аутсорсингу сопутствует уволнение части/большинства/всех сотрудников внутренней IT, поэтому более-менее стоящие люди стараются подыскать себе работу, не дожидаясь “насильственного” увольнения.
Далее… как следует из сказанного выше, каждый работник внутреннего IT компании ощущает нависающий над ним Дамоклов меч. Пусть аутсорсер и высшее руководство компании “бьют в барабаны”, крича о том, что никто не будет уволен, но  тут работает правило “пропанды”: чем громче о чем-то кричат, тем больше вероятность, что это неправда. Все понимают, что одним из способов аутсорсера зарабатывать деньги является замена сравнительно дорогих местных сотрудников более дешевыми. На данный момент рабочая сила в определенных частях света настолько дешевая, что аутсорсер может наращивать бизнес “количественно” (нанимая больше сотрудников) без ущерба для “здоровья”, т.е. прибыли. Поэтому если топ-менеджмент какой-нибудь компании говорит, что никто не будет уволен, они скромно умалчивают о том, что у этого утверждения есть временные рамки типа… “никто не будет уволен в течении полугода, а там как бог даст”. Но большинство это понмимает и так, поэтому моральный климат во внутреннем IT обычно “ниже плинтуса”. Я никогда не слышал о случаях, когда разозленный бывший IT сотрудник делает “закладку” где-нибудь, ну какой-нибудь скрипт, который “перемешает” данные в базе клиентов, удалит все учетные записи из сервиса каталогов или, еще хуже, будет вредить потихоньку так, что идентифицировать проблему сразу не получиться и аутсорсер будет бороться с “подарком” долго и безрезультатно. Как с этим справляться – тоже неочевидно (мне, по крайней мере). Я бы сказал, что в этом случае нужна абсолютная прозрачность намерений и щедрые выплаты при сокращениях. Я уже писал давно как-то про выражение, которое мне понравилось: “Увольняя системного администратора, лично проводите его до двери и подайте ему шляпу” (старомодно так). Смысл в том, что надо не только  проявить уважение, но и проследить за его “шаловливыми рученками” на выходе :) 
В случае с переходом по плану “большой взрыв” главная опасность – риск потерять накопленные персоналом знания, которые нигде не задокументированы. Не всё заносится в документацию, поэтому если люди массово уйдут, будет потом трудно быстро разобраться в возникшей проблеме. Последствия потери необходимых знаний по поддержке IT сервисов могут быть еще хуже, чем в первом случае. Есть серъезная опасность не выполнить критерии договора по обслуживанию, что чревато :) На моей памяти было несколько случаев, когда аутсорсеру приходилось “нанимать” обратно на пару дней по контракту бывшего сотрудника, чтобы решить проблему, которую аутсорсер не мог устранить в течении двух дней. Бывший сотрудник решил это за 20 минут. Это, конечно, экстримы, но я более чем уверен, что похожие случаи бывают при любом переходе. Опять же, вариант с “закладками” тоже возможен. Для избежания прийдеться в массовом порядке менять пароли слежебных учетных записей, пользователей с расширенными привилегиями, что не всегда возможно. По большому счету, все эти вредоносные “закладки” сложно доказуемые, но (тьфу-тьфу-тьфу) – пока сия чаша миновала те компании, в которых я работал.
Снова заканчиваю незакончив :) В следующем посте я хочу коснуться проблем аутсорсинга.

Засим раскланиваюсь,
Рустам.

Переход на модель аутсорсинга. Часть третья.

by Rustam Sydykov

Привет, народ!

Продолжение придыдущих постов об аутсорсинге: часть первая и часть вторая. Предположим, решение об аутсорсинге принято. Хочется надеятся, что призрачные перспективы сэкономить кучу денег не были основной причиной. Как я уже говорил, финансовый отдел просто обожает аутсорсинг. Я могу сильно ошибаться, но кто-то мне говорил, что при переходе на модель аутсорсинга классификация расходов на IT  меняется с CAPEX на OPEX (с капитальных фондов на текущие траты) и это каким-то образом положительно сказывается на финансовых показателях. Поэтому еще раз подчеркну: не давайте права финансовому отделу влиять на решение об аутсорсинге, так как кратковременная финансовая выгода можешь напрочь “отшибить мозги” финансистам. Но даже если решение об аутсорсинге принято, компания еще должна решить, какой тип аутсорсинга ей выбрать:

  • Полный – аутсорсеру отдаются все компоненты IT:
    • Инфраструктура: центры обработки данных (сервера, кабельное хозяйство и другое вспомогательное оборудование);
    • IT сервисы: почта, доступ в интернет, десктопы и лептопы (не как физические устройства, а как IT сервисы: операционная система, антивирусы, средства установки приложений, средства управления рабочей средой и т.д), телефонная связь и т.п.;
    • Поддержка и управление пользователями (точнее, их учетными записями).
  • Частичная:
    • Частичный аутсорсинг инфраструктуры, серсисов или поддержки.

Дальше все проще и сложнее одновременно. Компания должна произвести “безкровную” передачу выбранных/всех IT сервисов аутсорсеру таким образом, чтобы бизнес не заметил перемен. Наверное, это самое главное в переходный период, так как это наиболее видимая для бизнес-пользователей часть. Но она и самая легкая. Гораздо сложнее добиться успешного завершения задач, которые являются предпосылками для этого перехода: контракты, список обязанностей и т.д. и т.п. Данная часть для меня не представляет особого интереса, так как это больше поле деятельности менеджеров, юридического и финансового отделов.
Единственное, что могу сказать, основываясь на своем скромном опыте: всем лучше будет, если договор об аутсорсинге будет составлен таким образом, чтобы исключить любое двоякое толкование обязанностей и ответственности сторон. Аутсорсер будет “белый и пушистый” ровно до того момента, пока компания не подпишет договор. Особенно если это “полный” аутсорсинг. После этого любые пункты, которые могут трактоваться двояко, будут пониматься обеими сторонами так, чтобы это было выгодно им, а не другому. Я уже писал про термины и недорозумения, которые могут возникнуть из-за того, что разные организации/люди могут вкладывать разный смысл. Например, в одном случае, аутсорсер и компания договорились перепроектировать структуру сервиса каталогов (учетные записи, членство в группах, политики и т.д.). Где-то в середине проекта выснилось, что компания под “сервисом каталогов” так же понимала доступ к файл-серверам и упорядочивание доступа к папками и файлам! С точки зрения аутсорсера (да и с моей тоже :)), файловые сервера имеют только косвенное отношение к сервису каталогов, но компания традиционно включала в“сервис каталогов” практически все: аутентификацию/авторизацию к приложениям, файлам и папакам на файл-серверах, дизайн десктопов и лептопов. В общем, все, что каким-либо образом использует сервис каталогов! С точки зрения аутсорсера данные сервисы лежат вне области проекта и если компания хочет включить их в проект, это означает увеличение стоимости проекта (“дэнги-дэнги давай!”), а так же смешение сроков окончания проекта на пару месяцев. Высший менеджмент компании и аутсорсера два месяца обсуждал этот вопрос, что вылилось и в задержку проекта, и в увеличение стоимости проекта даже без расширения границ работы, так как два месяца люди, вовлеченные в проект, просто занимались текущей поддержкой.
Надеюсь, я смог донести до вас важность ясного описания целей и задач аутсорсинга. Если кратко, то контракт аутсорсинга (да и любой другой контракт или соглашение о выполняемых работах) должен быть:

  1. Составлен таким образом, чтобы исключить двоякое толкование. Содержать процедуру разрешения неоднозначных ситуаций и, в идеале, давать компании больше “веса” в принятии решений о том, как должнен трактоваться тот или иной пункт. По идее, это задача аутсорсера до подписания контракта выяснить вплоть до мельчайших подробностей, что ему предстоит делать в рамках контракта;
  2. Содержать критерии, которые можно применять для оценки работы аутсорсера. Эти критерии должны позволять оценивать сервис, предоставляемый аутсорсером:
    • Качественно – “что и как” должен делать аутсорсер. Например: “Обеспечить SLA (соглашение об уровне сервиса) для корпоративной почты (<здесь по идее должна быть ссылка на документ, описывающий “корпоративную почту” как сервис, содержащий другие компоненты, обеспечивающие бесперебойную работу почты: “почтовые” антивирусы, сервера “спам-фильтры”, а так же сервисы, от которых косвенно зависит работа корпоративной почты: корпоративная локальная сеть, подключение к Интернет)”;
    • Количественно. Например: “обеспечить SLA для корпоративной почты 99.9% во время рабочих часов, “окно” для сервисного обслуживания – <время>, КПД “спам-фильтров” – 89%, время восстановления работоспособности основной (RTO) части почты как сервиса – 1 час, допустимая часть потери данных (RPO) – 1 час и т.д. Кстати, определение “рабочих часов”> – не такой уж простой вопрос, как кажется. Если компания принадлежит к одному часовому поясу – то это легко. А что если ее офисы разбросаны по всему земному шару!? :) Тогда требование “99.9% во время рабочих часов” легко может превратиться практически в 24x7 и в результате система, удовлетворяющая таким требованиям будет горааааздо дороже.

После подисания контракта на аутсорсинг наступает следующая фаза: переход с внутренней IT службы на поддержку аутсорсером. Об этом чуть попозже.

Надеюсь, я не утомил вас своим слогом :) и засим раскланиваюсь,
Рустам.

Когда стоит думать об аутсорсинге. Часть вторая.

under by Rustam Sydykov

Привет, народ!

Продолжаю свое краткое изложение мыслей об аутсорсинге :). Предыдущий пост – часть 1. Хочу сразу же сказать, отвечая на коментарий Жени Я., что я не против аутсорсинга. Аутсорсинг “работает”.  Только как и ко всему, к решению аутсорсить IT надо подходить с позиции здравого смысла. Все мы, замечаем это или нет, пользуемся услугами аутсорсеров. Например, наши друзья переезжали из квартиры в другое жилье. Вместо того, чтобы самим мучаться и вымывать квартиру для инспекции агенством, которое сдало им эту квартиру, они “за-аутсорсили” эту функцию женщине, которая этим занимается профессионально :) Смысл тратить свое время, мучаться до полуночи, если можно немного заплатить и кто-то за тебя сделает уборку, к тому же быстрее и лучше!? Или еще такой пример, не совсем корректный, но все же: я сам не обслуживаю нашу Тойоту. Весь сервис производится сервисным центром Тойоты. Думаю, мой бы сервис не сравнился по качеству с официальным центром Тойоты :) Пример не совсем корректный потому, что я сам никогда не занимался обслуживанием машины. Тут и аутсорсить было нечего, но можно сказать, что решение об аутсорсинге было принято сразу :)
Немножко определений терминов: когда я употребляю “бизнес”, “компания”, то я имею в виду организацию, которая собирается аутсорсить IT. “Аутсорсер” – это IT компания, которая предоставляет соответствующие услуги :)

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

  1. Бизнес компании не зависит напрямую от IT и никакие бизнес-процессы не интегрированы тесно с IT сервисами, предоставляемыми внутренней IT службой;
  2. Компания и ее служба IT достигли определенной ступени развития или эволюции, которая позволяет произвести качественную оценку существующих IT сервисов, интеграции сервисов с бизнес процессами, косвенный вклад IT в прибыль компании и т.д.;
  3. Внутренние резервы уменьшения расходов или увеличения отдачи от IT уже исчерпаны или невозможно достигнуть требуемого уровня IT сервисов (масштабируемость, качество и т.п) по ряду причин;
  4. Компания готова измениться или изменить свои требования к IT с учетом модели аутсорсинга.

Вот основные 4 пункта, если я не пропустил что-то еще. Теперь немножко подробнее о каждом утверждении:

Касательно п.1: как правильно заметил Сергей В., аутсорсить ключевые функции IT подобно самоубийству. Но это если только от IT зависит способность бизнеса функционировать и генерировать прибыль. Компания, которая полагается на IT для улучшения своей конкурентно-способности на рынке имеет меньше причин аутсорсить IT чем та организация, для которой IT – всего-лишь одна из немногих служб, так или иначе просто способствующих гладкому ходу бизнеса. Как склад. В первом случае мы имеем дело с компанией типа “Амазон”, хотя, не скрою, я могу быть и не прав в своей оценке. “Амазон” имеет прекрасную “площадку” для продажи бумажных и электронных книг; устройство для чтения книг, интегрированное с этим электронным магазином; “облачные” сервисы и т.д. Это то, что выделяет “Амазон” на рынке услуг и эти сервисы лично я бы никогла бы не аутсорсил. Хотя другие компоненты, например, производство “ридеров”, не могут быть произведены кроме как с помощью сторонних компаний. Теперь представим себе компанию, которая, к примеру, занимается продажей предметов искусства. Для нее IT – это всего-лишь вспомогательный механизм презентации основных товаров, способ связи с клиентами и прочее. Компания вполне может существовать, пользуясь стандартными IT сервисами со стандартной функциональностью и IT сервисы для нее не дают абсолютно никакого преимущества над конкурентами. Такая компания будет заинтересована в аутсорсинге IT и получения заранее оговоренных сервисов по фиксированной цене.

П.2. Очень важный с моей точки зрения. Состояние компаний в плане их развития и бизнеса можно описать приблизительно таким образом:

  1. Динамичная компания, быстро растущая во многих направлениях. Структура компании постоянно меняется, меняются/могут менятся области бизнеса, нет жестких бизнес-процессов и т.п. IT департамент в такой компании скорее всего будет выглядеть подобным образом и будет состоять из группы инженеров/”эникейшиков”, которые будут на себе тянуть весь груз IT и пытаться удовлетворить постоянно меняющиеся требования бизнеса. Как результат – отсутствуют формализованные процессы, стандарты, политики и т.п.;
  2. Компания, которая достигла определенной ступени развития; бизнес-процессы, структура компании и требования к IT более-менее сформулированы. IT департамент может начать внедрять ITIL для описания сервисов, соглашений об обслуживании и т.п. Но ITIL внедрена частично; стандарты, политики не полностью “покрывают” область IT; отсутствуют или описаны неполностью процессы взаимодействия IT и бизнеса; отсутствуют или описаны частично стратегия развития бизнеса и IT сервисов и т.д.;
  3. “Зрелая” компания. Компания, в которой существует подробное описание бизнеса, функций, стратегии и т.д., т.е. архитектуры бизнеса. Департамент IT внедрил почти полностью ITIL, присутствует подробное описание архитектуры приложений, данных и систем (пример – TOGAF); Таким образом, бизнес имеет представление об IT, IT имеет представление о бизнесе и его задачах и старается выстроить свое развитие/стратегию в соответствии с требованиями/стратегией бизнеса.

В реальной жизни, конечно, бизнес и IT могут находиться на ступеньку выше или ниже. Т.е. Бизнес может достичь уровня 2, в то время как IT находится все еще на уровне 1. Не думаю, что возможны комбинации бизнес/IT 1-3 или 3-1, так как развитие IT определяется требованиями бизнеса.
Теперь предположим, что компания, находящаяся на уровне 1 или 2, попытается за-аутсорсить IT. Я думаю, попытка сделать это может провалиться или привести к неадекватному результату, сродни выстрелу в ногу :) Почему? Мне на ум приходят несколько причин:

  1. Невозможность провести анализ объектов для аутсорсинга и возможных рисков для бизнеса, связанных со переносом IT сервисов и их поддержки. Т.е. непонятно, какими сервисами пользуются бизнес-пользователи; насколько IT интегрировано с бизнес-процессами: что будет, если мы “с корнем вырвем”, например, почту из зоны ответственности внутреннего IT и передадим аутсорсеру и т.д.;
  2. Невозможность качественно и количественно оценить выгоду или ее отсутствие для аутсорсинга. Как можно оценить что-то, о чем и IT, и бизнес имеют крайне туманное представление!? Другими словами, полное отсутствие основы для анализа;
  3. Проблемы интеграции с аутсорсером: процессы, стандарты, контроль качества, запрос ресурсов и т.д. Аутсорсер, если это хороший аутсорсер, имеет свои процессы и правила для взаимодействия с компаниями и их бизнесом, но для этого требуются “точки контакта” в виде аналогичных или близких процессов в компании, собирающейся аутсорсить IT. Если точек соприкосновения нет, то аутсорсер может “буксовать”, пытаясь управлять чужой средой, в результате бизнес так же будет страдать;
  4. Риск, связанный с неспособностью удовлетворять потребности бизнеса, если компания изменит бизнес-стратегию, например, вдруг станет поставщиком IT услуг :);
  5. Риск потерять важные знания о функционировании/поддержке IT сервисов, накопленные как знания в головах сотрудников, но не задокументированные для последующего использования кем-либо другим.

В случае с компанией уровня 2 ситуация может быть немножко лучше, если аутсорсер предпримет усилия по “подтаскиванию” компании до уровня 3.
Компания уровня 3 – идеальный случай для рассмотрения выгоды аутсорсинга. Если компания внедрила у себя ITIL, стандартизованные процессы выбора, внедрения и поддержки IT сервисов, обладает знанием в полном объеме о различных архитектурах (IT и бизнеса компании)  – то это позволит компании подготовить следующее:

  1. Категоризацию IT сервисов, используемых бизнесом. Например, разнести сервисы по категориям “критичные для бизнеса”, “некритичные”, “вспомогательные”. Скажем, “критичные сервисы” – это такие сервисы, при проблемах с которыми компания не сможет вести бизнес, потеряет конкурентно-способность или понесет убытки;
  2. Оценить вклад или важность каждого сервиса в прибыль компании – явно и косвенно;
  3. Оценить с достаточной точностью стоимость предоставления сервисов  в пересчете на одного пользователя.

Имея на руках эти данные, можно с гораздо большей уверенности подойти, по крайней мере, к первому шагу итерации анализов возможности аутсорсинга. Можно будет “проиграть” различные сценарии: “что будет, если мы отдадим аутсорсеру вот это и это”.  Риски, упомянутые для компаний уровня 1 и 2 могут быть ликвидированы или последствия для бизнеса могуть быть “сглажены”.
Честно скажу: за все время своей трудовой деятельности я видел компании уровня 1 и 2, 3 – пока что еще не встречал. Может, это как “коммунизм” – идеальное состояние идеальной компании :) Например, ITIL позразумевает создание и поддержку в актуальном состоянии CMDB (если грубо, то CMDB – это база атрибутов о инфраструктуре, приложениях и других объектах, а так же описание связи между ними). Я этого “зверя” вообще не видел в “дикой природе” :) В одной из компаний, где я раньше работал, предпринималась попытка создания CMDB, но потом проект был тихо свернут из грандиозности задачи и стоимости внедрения.

По п.3: здесь неограниченное море возможностей :) Я думаю, в жизни любой компании наступает момент, когда она понимает, что КПД ее работы уменьшилось с течением времени. Здесь полезно будет провести “уборку в доме”:

  1. Пересмотреть текущие проекты и заново оценить отдачу от них. Даже это простое действие позволит сэкономить огромные суммы, если, конечно, у начальства не будет “кишка тонка” остановить проекты, на которые или уже потрачены деньги, или эти проекты были разрекламированы бизнесу как нечто особенное, которое вмиг решит все проблемы. Я говорю из своего опыта о суммах с шестью нулями, потраченными на стороние решения, которые не могли быть внедрены из-за ряда недостатков или просто в них отсутствовала необходимость! Один раз по прямому указанию начальства были куплены лицензии на продукт, который никому был не нужен, но так как это было ц/у начальства, все старательно делали вид, что продукт используется (“висело” три сервера в виртуальных машинах с самым низким приоритетом :)). Самое обидное, что развитие системы, выполняющей те же функции, но не получившей одобрения “в верхах”, было приостановлено, несмотря на то, что она реально работала и использовалась. Это был еще косвенный убыток, который затормозил развитие данной функциональности на год. А потом уже это было неактульно. Или попытка внедрения продукта (identity management), который бы управлял службой каталогов, интегрировался с отделом кадров и делал бы все-все, разве что не танцевал. Три раза проект реанимировался и три раза умирал, потому что бизнесу обещали слишком много и просто не могли это внедрить в рамках бюджета и времени. Но каждый раз тратили сумму под миллион. Тупо. А в это время внутренняя система управления службой каталогов продолжала работать, выполняла свою цель, но ее разработку так же пришлось прекратить ибо “внедрим мы систему за мульйон и снизойдет на нас счастье”. У…лись!
    Еще одним примером такого подхода может служить требование для каждого проекта иметь определенный бюджет и внедрение проекта должно было происходить строго в рамках бюджета. Это была попытка бизнеса перевести IT типа на самоокупаемость, что ли… В результате тратились лишние деньги там, где это совершенно не надо было. Вместо лицензирования Windows Server для виртуализации на физический хост-сервер (Windows Server Datacenter Edition), каждый менеджер проектов предпочитал покупать стандартную серверную лицензию. Мало того, эта же история была с SQL. Все из-за того, что кто-то пожалел потратить n-ую сумму сразу, в результате ушло в несколько раз больше. И таких примеров я могу приводить бесконечное количество, к сожалению :(
  2. “Перетрясти” штатное расписание, чтобы избавиться от “балласта”. В одной компании, где я работал, между мной, инженером, и бизнесом существовала раньше одна прослойка менеджеров проектов. Когда я уходил, цепочка состояла уже из трех человек. До директора компании было 2 уровня, когда уходил – даже не берусь сосчитать. Спрашивается: приносили ли эти все люди какую-то пользу? Наверное, приносили, но не соразмеримую с потерями на бюрократию, которые генерировали эти “раздутые” штаты;
  3. Постараться снизить операционные расходы, повысив КПД работников. Например, аутсорсер может предложить дешевую рабочую силу, но очень часто это сопряжено с более низкой квалификацией работников. Внутренний отдел IT компании может продемонстрировать больщую отдачу в пересчете на сотрудника, внедрив решения, которые сводят на “нет” дешевизну рабочей силы аутсорсера. Например, внедрение системы управления персональными компьютерами вместе со виртуализацией приложений может существенно снизить операционные расходы на управление компьютерами. Или консолидация почтовых серверов. Или мигрирование физических серверов в виртуальную среду. Здесь, конечно, рассматривается идеальная ситуация. В реальной жизни бизнес может отказаться финансировать какой-то проект из-за достаточно больших первоначальных расходов, но это как раз и задача IT показать прямую и косвенную выгоду от внедрения подобных решений;
  4. Постоянно демострировать улучшения пользовательской среды (user experience). Это человеческая природа – требовать постоянно чего-то нового. Пусть улучшения не будут глобальными, но тем не менее заметными пользователям. Это может быть обновление версий программ, или поддержка устройств, которые так нравятся бизнес-пользователям: всякие там телефоны или интернет планшеты. О том, насколько этот эффект недооценивается, я понял из своего опыта: никакие рассуждения о меньшей стоимости поддержки, лучшей доступности и т.п. для новой версии серверов Exchange не могли “пропихнуть” проект апгрейда с 2000 до 2007. Бизнесу было все “до одного места”. Но вот когда у начальства появились “я-телефоны” в количестве 10 штук, деньги магическим образом нашлись. Грустно, конечно, но такова жизнь;
  5. И еще важный момент: уметь показать, какая доля расходов IT состоит из проектов, инициируемых бизнесом. Вполне может оказаться сюрпризом для бизнеса то, что расходы на работников и поддержание IT сервисов будут сравнимы с тратами на IT составляющую бизнес-проектов. В таком случае будет понятно, что нет пытаться смысла сократить расходы там, где их нет. Бизнесу тоже может потребоваться пройти через п. 1 и 2 :)
  6. Еще один способ сократить расходы: использование стандартных или стандартизованных сервисов. Т.е. вместо предоставления пользователям сервисов в различными конфигурациями, предложить им на выбор два или три варианта, “повесить ценник” на них и тогда бизнес будет лучше понимать, сколько что стоит. Например: вместо предоставления удаленного доступа к приложениям через vpn и Citrix, можно просто оставить только Citrix. Меньше оборудования для поддержки, меньше лицензий – меньше затрат. Или вместо предоставления бизнес-пользователям лептопов HP, Dell, Sony, Apple и черт-знает кого, сделать так: на выбор два производителя – HP и Apple (я бы в корпоративной среде и даже бы Apple предлагал), из них по два варианта “железа”. Стоить поддержки всего этого пусть будет, например, 300 фунтов в год для HP/Win7 и 600 фунтов в год для Apple/MacOS X. Если хотите и Sony, и Dell, и NoName – пожалуйста, мы будет это делать, но это будет вам обходится 800 фунтов в год на лептоп. Расходы на это составляют: необходимость поддержки образов операционных систем для лептопов от разных производителей, обновление драйверов в этих образах, административная работа по контрактам поддержки с разными производителями и т.д. Когда сервис имеет ценовой эквивалент, бизнес это гораздо лучше понимает. Если не понимает, я всегда объяснял на примере электроэнергии. Электроэнергия дешевая, потому что параметры, с которыми она предоставляется потребителю, стандартные. Это 220 В, 50 Гц. Все! Если бы обычный бизнес выдвинул требования: хочу в этой комнате розетки 220 В, 50 Гц утром, но 1001.11 В, 300 Гц, 3000 А в обед и вечером 12 В, 10 Гц. А в другой комнате 999 В, 49 Гц все время. А в третьей… Можно было бы такое сделать? Можно! Но будет стоить такое электричество ну оооооочень дорого. Так и с IT сервисами – чем большего разнообразия хочет бизнес, тем дороже это будет обходится. Потом, если что, при “разборе полетов” типа “почему мы тратим на IT столько денег” можно будет указать, что IT “подстраивается” под требования бизнеса и если эти требования очень сложные, то и стоимость IT сервисов будет высокая.

Ну и наконец – п.4. Компании необходимо понимать, что аутсорсинг – это не только когда IT “прогибается” под бизнес, но и бизнесу может быть прийдется чем-то поступиться. Особенно это касается привычек управления проектами. В одной моей бывшей компании для менеджеров проектов было настоящим шоком то, что они уже не могли требовать от инженеров что-либо делать “на лету”, а им надо было проходить через формальную процедуру резервирования времени инженеров и “окно” для этого было две недели! Раньше инженеры были согласны и поработать во внеурочное время, лишь бы успешно закончить проект, то сейчас уже никто не “горит” на работе. “Утром деньги – вечером стулья” :)
В книге Талеба “Черный лебедь”, которую я уже упоминал в первой части, я встретил выражение, которое как нельзя лучше подходит к аутсорсингу: “К любому продукту применимо три атрибута: быстро, качественно и дешево. Но вы заказать продукт и выбрать можете только два из этих атрибутов”. Бизнесу прийдется смириться, что если компания хочет иметь дешевую IT, то это будет или “быстро”, или “качественно”. Но никак не все вместе. Так что тут аутсорсер и компания должны провести долгие часы вместе, обговаривая условия и ожидания друг от друга.

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

Ну вот и все, надеюсь вы дочитали до конца :) Засим раскланиваюсь,
Рустам.