Глупые мысли об IT

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

В данной статье я хотел бы рассказать об ошибках, которые я когда-либо наблюдал при работоте над проектами. В некоторых ошибках была моя прямая вина, за другие я с радостью переложу ответственность на людей, которые были заняты со мной в различных проектах. Некоторые вещи были достаточно тривиальные и при правильном подходе можно было бы легко их избежать, другие проявлялись из-за системных проблем, таких как отсутствие взаимодействия между командами, работающими над разными задачами в проектах.
Немножко отвлекусь: все, что не делается/внедряется в 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).
Напоследок рекоммендую прочитать пост Алексея Глазкова “Правила работы надо проектом”.
Это все, что я могу сказать по поводу ошибок. Любые дополнения приветствуются :)

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

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

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

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

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

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

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

Не беспокойтесь, я уже почти закончил свою сагу об аутсорсинге. Осталось совсем чуть чуть! Потерпите :)
Итак: как вы поняли из заголовка поста, я хочу сказать несколько слов о проблемах аутсорсинга. Об этом надо задумываться еще до того, как принято решение аутсорсить 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 сервисы с информацией и документами, полученными от аутсорера, остальным прийдется тяжелее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Продолжаю свое краткое изложение мыслей об аутсорсинге :). Предыдущий пост – часть 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 пункта в начале не должны служить автоматическим триггером для начала аутсорсинга, а всего-лишь началом долгого и вдумчивого процесса рассмотрения возможности аутсорсинга, потому что в случае неудачи будет очень трудно вернуть все обратно.

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

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

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

1. Желание сократить операционные расходы на ИТ – это деньги, которые тратяться на зарплату работников, амортизационные отчисления на оборудование, счета за электричество и т.д.;
2. Идея использовать аутсорсинговую компанию для для внедрения проектов, для которых организация не имеет опыта/ресурсов – это, конечно, ближе к использованию консалтинговой фирмы, но я и такое видел;
3. Попытка достичь лучшего соотношения между затратами на ИТ и получаемой выгоды (ROI) – как говорится: “иметь больше за меньшие деньги”. Т.е. получить от IT более высокий КПД;
4. Мода. Тут и говорить нечего.

В целом, кроме п.4 причины выглядят более чем обоснованными. Кто же не захочет сэкономить кучу денег на такой расходной службе, как IT? Но, как мне кажется, очень часто попытки обосновать возможные “прелести” аутсорсинга не учитывают некоторые фундаментальные вещи – об это ниже. 

По п.1:

Очень много действий, осуществляемых внутренней IT, остаются незамеченными. В этом случае начинают “плавать” все показатели КПД работников (KPI), в результате начинает казаться, что на внутреннюю IT денег тратится очень много, а результат вроде бы и как и незначительный. Потом при составлении контракта с аутсорсинговой компанией указывается список задач для выполнения, аутсорсинговая компания указывает свою цену и если все устраивает, договор подписывается. Если “неожиданно” обнаруживается, что требуется еще пачка действий для поддержания систем в работе, это будет уже дополнением к контракту, за дополнительные деньги и вполне возможно – с большой наценкой. Все зависит от того, как быстро это обнаружится. Но денег точно прийдеться платить больше. Этот риск не такой уж маленький, как кажется: дело в том, что решение об аутсорсинге принимается “ввреху”. По разным причинам информацию о том, что IT планируется аутсорсить, начальство захочет сохранить в тайне.  А достоверной информацией о списке задач для ежедневной поддержки начальство может не располагать, а если затребует – то IT в силу непонимания… или еще хуже, понимания, может выдать на “гора” неполный/неверный список выполняемых задач. Типа: “На те, отвяжитесь”.
Крайне тяжело перевести в денежные единицы действийя IT в плане важности операций по поддержке систем. Человек может каждый день с утра проверять логи серверов, проверять метрики производительности серверов и т.д. Причем он не просто “смотрит в книгу видит фигу”, он способен предвидеть (если он хороший работник) потенциальные проблемы: отклонение от графика загрузки процессора в это время, непонятные ошибки в логах и т.п. Так как он обладает знаниями инфраструктуры, бизнеса и того, как стандартная технология нестандартно реализована в данной компании, “внутренний” работник IT может предупредить серъезные проблемы до того, как они наступят. Т.е. ничего вроде бы не случается, но и нет видимости тех инциндентов, которые не наступили именно благодаря таким сотрудникам. Я как раз читаю книгу Нассим Талеба “Черный лебедь” по рекомендации Юры К. и Жени Я., там автор тоже подчеркивает, что мы не можем понять значимость событий, которые не наступили, но которые если бы они наступили, повлекли бы или огромные убытки, или потерю человеческих жизней. Талеб как пример приводит гипотетическию ситуацию, в которой какой-то сотрудник авиакомпании предусмотрел усиленные двери между кабиной экипажа авиалайнера и пассажирским салоном, в результате бы не наступило 11 сентября. Как можно было бы оценить важность решения оградить экипаж от легкого доступа со стороны салона, если бы мы никога не узнали бы об 11 сентября!? Так и действия работников, последствием которых будет отсутствие глобальных проблем, не получат качественной оценки. Этакий “… по гром не грянет” в IT :) Я свое время в одной крупной компании я постоянно говорил об необходимости системы управления компьютерами уровня предприятия для инвентаризацаи, установки приложений, а самое главное – установки хот-фиксов к одной популярной операционной системе. Стоить это должно было достаточно много и естественно, никто не хотел выделять деньги. Бизнес говорил, что вполне может пережить день простоя главного офиса. И вот, в один прекрасный день… три дня и две ночи, не уходя с работы, инженера “закатывали солнце вручную”. Это нам еще повезло, что  только около 2%-3% компьютеров оказались “завирусованными”. После “разбора полетов” бизнес понял, что они не смогли правильно оценить ежедневные бизнес-процессы, выполняемые работниками головного офиса и следовательно, правильно оценить риски. Нужно ли говорить, что деньги на продукт управление десктопами нашлись очень быстро. Так и с оценкой эффективности затрат на IT: очень велика вероятность что-либо проглядеть, а потом горько об этом жалеть;

По п.2:

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

О п.3:

ROI можно улучшить, получив более высокую отдачу или понизив затраты. С отдачей, так же как и в п.1.2, все не так-то проосто: очень сложно оценить выгоду от внедренных проектов. Особенно если в расчеты вкрадывается такая “тонкая” вещь, как “удовлетворение пользователей” (customer satisfaction). Т.е. переход с Windows Vista на Windows 7 сложно обосновать чем-либо, кроме как бОльшим удовлетворением пользователей. Vista и Windows 7 до сих пор поддерживаются MS (переход с Windows XP на Windows 7 можно “железно” обосновать требованиями безопастности), интерфейсы похожи и т.п. Можно сказать: “Windows 7 работает быстрее”. Но как это измерить? Как это перевести в денежные единицы, столь радующие менеджеров? На моей памяти очень редко получалось расчитать явно выраженную финансовую выгоду от внедрения какого-либо продукта. Переход с MS Office 2000 на 2010 не только не принесет прямой выгоды, а наоборот, будет сплошными расходами, и ROI перевести в “плюс” можно только используя неявную выгоду или пользу.
Понизить затраты можно путем или привлечения более дешевых ресурсов (дешевые инженеры из других стран) или использования ресурсов в совместном доступе. Например, виртуальная среда аутсорсера, которая используется и другими клиентами аутсорсера, в результате чего виртуальные машины обходяться дешевле и т.п. Или мониторинговая система, серверная часть которая настроена аутсорсером, а клиентская часть установлена на серверах/компьютеров организаций, покупающих услугу мониторинга. В принципе, это частный случай снижения операционных издержек (п.1).
Главный вопрос – подходит ли такая схема бизнесу. С использованием разделяемых ресурсов может встать вопрос об недостаточном качестве работ (при мониторинге надо не только смотреть на логи, но и понимать влияние систем, которые мониторятся, на бизнес и быстро и правильно реагировать), или неудовлетворительной скорости исполнения и т.д. Из моего опыта: я когда-то занимался “упаковыванием” приложений в msi формат для последующей автоматической установки пользователям. Мой личный рекорд – 2 часа. Это включало в себя обсуждение с бизнесом как приложение должно быть установлено (какие опции и компоненты выбрать), “упаковки” (InstallShield AdminStudio), тестирования и произведения необходимых действий для того, чтобы приложение было доступно пользователям. Как мне стало недавно известно, попытка в той компании (я уже там не работаю) аутсорсером перенести эту функцию за океан привело к тому, что теперь для этого требуется две недели как минимум и резко упало качество: требуется больше попыток и тестирования для получения необходимого результата. Т.е. вроде бы в абсолютных цифрах это дешевле, но никто же не учитывает время, которое тратят бизнес-пользователи на ожидание приложения, его тестирования, написания отчетов об ошибках и т.д.

п.4:

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

В заключение этой части хочу сказать: компаниям надо быть сверх аккуратными в оценке своих затрат на IT. В идеале надо потратить на это кучу времени, чтобы получить какую-то цифру. Еще больше времени надо для того, чтобы оценить выгоду, приносимую внутренней IT. Даже если эта выгода в конце-концов обозначена какой-то денежной единицей, я бы смело умножал бы ее на два! Это значение и стоит использовать для того, чтобы рассматривать, выгодно ли аутсорсить свое IT. Аутсорсер не заинтересован в снижении расходов клиентов! Главная задача аутсорсера – зарабатывать на клиентах деньги! Даже если сначала все будет выглядеть как снижение стоимости, то через некоторое время финансовый департамент может с удивлением обнаружить, что затраты на IT резко пошли вверх!
В следующем посте я постараюсь рассказать, о чем, по моему мнению, необходимо подумать прежде всего, прежде чем окончательно решить аутсорсить IT.

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