В последнее время много работал, много думал, поэтому в свой блог писал мало. А еще меньше - в блог на IT Blogs. :-)

Сразу же оговорюсь: ниже речь идет о небольших компаниях. Относительно небольших: до 300..500 человек. Плюс-минус человек 200. И, разумеется, совсем не про публичные компании, тип Microsoft или SAP. Там, скорее всего, совсем другие законы.

Так вот, думал я вот о чем. Кто остается в компании, несмотря ни на что? Кого согласны мотивировать до последнего? Вывод очевиден: ключевых специалистов всех уровней (в зависимости от уровня их еще называют системообразующими). Почему? Да потому, что на них замкнут "стратегически важный" участок работы, а без них - "все не работает". При этом, к сожалению, наиболее типичная картина состоит в том, что такой специалист не очень-то и стремится поделится своим сакральным знанием: это лишит его статуса "священности" (что бы там не говорили бизнес-тренеры про делегирование). При этом, даже если они и открывают профессиональные секреты, то оставляют ниточку, за которую всегда можно потянуть (то есть участок работы, который их и только их).

В ИТ компаниях или ИТ подразделениях компаний эта проблема стоит еще более остро: ИТшник, особенно с головой, способен так "замутить"в коде/в настройках/в процессе/..., что распутывать придется долго-долго...

Несколько примеров (целиком авторская фантазия, хотя реальных похожих случаев я знаю немало):

• Ведущий разработчик корпоративной ИС, вокруг которого штат программистов... имеющих доступ лишь к GUI интерфейсам и знающих имена функций, которые они должны вызвать, и параметры, которые нужно передавать.
• Системный администратор, который обслуживает сеть из n ПК и m серверов. Вокруг него (возможно, постепенно) появляется штат "помощников" - так называемых "эникейщиков", которым со временем передается "не основное": ввести пользователя в домен, заменить картридж... в общем, все, кроме доступа к серверам с корпоративной ИС, роутеру, раздающему Интернет и заведующего удаленным доступом.
• Начальник отдела/группы/сектора/..., фактически - "играющий тренер", на которого "завязан", например, участок работы... пусть будет построения внешних сервисов для клиентов компании. При этом у него есть сотрудники, каждый из которых отвечает исключительно за свою работу и не смотрит за "работой товарищей". То есть получается "двойная страховка": с одной стороны на уровне распределения работ ("общая картина" завязана на одного человека), с другой: самостоятельная разработка отдельного модуля (разработка завязана на одного человека - ситуация рассмотрена выше).

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

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

Как-то невесело получается...

PS. Это я не про свою работу, это я вообще... о жизни.

Кросспост из моего ИТшного блога на ITBlogs.ru

Моя статья на тему "Выносить ли сыр из избы - где должна проходить граница между аутсорсингом и собственными ИТ процессами крупных компаний" получила приз зрительских симпатий на конкурсе IOne.

Сайт конкурса - http://www.kommersant.ru/ione/

Прямая ссылка на статью: http://www.kommersant.ru/doc.aspx?DocsID=1023900

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

Сама статья:

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

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

В этом свете преимуществами аутсорсинга будет являться:

• в общем случае - оперативный горячий резерв ресурсов, предоставляемых компанией-аутсорсером, и отсутствие проблем для заказчика, связанных с поиском необходимых ресурсов в случае непредвиденных ситуаций;
• компетенции компании-аутсорсера в области предоставляемой услуги, как правило, выше, чем компетенции собственных ИТ-специалистов;
• гарантии компании-аусорсера;
• грамотная документация, составленная в соответствии с ГОСТ или требованиями заказчика.

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

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

Каждый из приведенных рисков может быть нивелирован тем или иным способом: грамотно составленный договор, правильно выстроенные ИТ-процессы у заказчика и исполнителя (например, в соответствии с ITIL), наличие внутренней регламентирующей документации, тщательный выбор аутсорсиногового партнера, проведенная процедура оценки влияния той или иной услуги на бизнес, оценка контракта и партнера с точки зрения выполнения внутренних норм ИТ-безопасности, наличие схемы "перехвата" в случае неожиданного отказа аутсорсиногового партнера от своих обязательств и т.д.
Таким образом, прибегать к услугам аутсорсинга имеет смысл в следующих случаях:

1. Уменьшение стоимости владения услугой для заказчика при сопоставимом качестве, предлагаемом аутсорсером.
2. Увеличение качества предоставляемой аутсорсером услуги при схожей или меньшей стоимости.
3. Уникальность и невоспроизводимость (либо экономическая неоправданность воспроизводимости) услуги, предлагаемой аутсорсером.

Что же касается крупных компаний (для определенности будем считать, что "крупная компания" - это компания с оборотом более 500 млн руб. в год и числом сотрудников более 1500), то для них весомость этих причин усиливается, поскольку речь идет о значительно более весомых ИТ-бюджетах, чем в случае с небольшими компаниями.
Тем не менее, провести четкую грань между ИТ-процессами, функциями и решениями, отдаваемыми на аутсорсинг, и реализуемых собственной ИТ-службой крупных компаний, довольно сложно. Во-первых, нередко встречается ситуация, когда на ауторсинг отдается разработка той или иной ИТ-услуги, которая потом поддерживается силами собственного ИТ-блока. Во-вторых, встречаются комбинированные случаи: когда одна и та же ИТ-услуга реализуется и поддерживается совместно силами аутсорсингового партнера и собственных ИТ-специалистов. И, наконец, в компании может быть принята своя политика в области аутсорсинга (типичные сценарии - "все на аутсорсинг", "минимум аутсорсинга"), сильно влияющая на решения об аутсорсинге.
Выходом из сложившейся ситуации является формализация ИТ-стратегии в свете стратегии основной бизнес-деятельности компании. В стратегии ИТ должна быть формализована политика в области предоставления услуг бизнес-подразделениям и политика в области потребления и поддержки ИТ-услуг, предоставляемых аутсорсинговыми компаниями, а также определено - какие из полученных аутсорсинговых услуг (решений) будут транслироваться бизнес-подразделениям, и в каких случаях аутсорсинговые компании будут привлекаться по инцидентному принципу.

Кросспост из моего ИТшного блога на ITBlogs.ru

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

С маленькими узкоспециализированными проектами все более или менее понятно: существуют целые индустрии по производству сайтов, типовым и не очень решениям на базе 1С и т.д. С большими ситуация тоже более или менее ясна: делать проект, например, по вещанию IP TV оператору связи, который не имел до этого подобного опыта быстрее, надежнее и (скорее всего) дешевле силами аутсорсинговых специалистов/компаний (отдельный больной вопрос аутсорсинга - качество оставим "вне области рассмотрения"). Но жизнь не стоит на месте, и аутсорсинг постепенно пришел в сферу средних и малых проектов. Когда-то давно я сформулировал для себя причины, в силу которых принимается решение об аутсорсинге:

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

Больше причин для аутсорсинга мне сформулировать довольно сложно. Таким образом, получается, что в мире появилась тенденция к удешевлению решений, в том числе аутсорсинговых, а корпоративный потребитель "созрел" для того, чтобы передавать хотя бы часть своих задач внешним исполнителям. Или я что-то упустил?

Кросспост из моего ИТшного блога на ITBlogs.ru

Один из самых тонких моментов при планировании проекта - оценка времени его реализации. Есть мнение, часто приводимое в качестве шутки: "Время, необходимое для реализации проекта в случае аутсорсинга, представляет собой время, заявленное партнерами, умноженное на случайное число в диапазоне от экспоненты до пи". Надо признать, что порой и при самостоятельном выполнении проекта длительность реализации (выполнения) получаются несколько больше заявленной. (На моей памяти были "долгострои", когда время выполнения проекта как самостоятельно, так и внешним подрядчиком, отличалось от расчетного раза в 2. Конечно, два - это не совсем экспонента (e=2,7), но близко. Традиционно возникает вопрос: почему? Или, в другой интерпретации: кто виноват и что делать?

Вопросы на самом деле взаимосвязанные. У любого проекта есть заказчик и исполнитель - как в случае аутсорсинга, так и в случае внутренней разработки. Срок реализации проекта - величина,  определяемая в основном исполнителем. (При условии выполнения заказчиком техничских требований исполнителя по обеспечению проекта). В случае аутсорсинга одна из типичных ситуаций - объявление изначально меньших (нереальных) сроков проекта исполнителем с целью "взять заказ" ("желание клиента - закон, заодно и заработаем"). При этом сумма проекта увеличивается на  возможные штрафы (заказчику об этом, разумеется, не сообщают). Вторая, тоже типичная, причина - несостоятельность исполнителя в части планирования сроков (то ест  срок заявляется без изначального желания его увеличения, но потом уселичивается - "в силу объективных причин", или, п още говоря, ошибок при планировании). Третья - изменившиеся обстоятельства, такие, как: изменение заказчиком требований после начала проекта (особенно этим грешат проекты без ТЗ), возникновение препятствий финансового характера (бюджет урезали, или никогда такого и не было - ситуация, характерная для случая заключения договоров по этапам), невыполнение заказчиком своих обязательств (технических требований по обеспечению проекта), изменение внутренних "политических" течений у заказчика или исполнителя, смена ключевых фигур на проекте с той и другой стороны.

Парадоксально, но выходов из ситуации, когда сорваны сроки практически нет (так как ситуация уже есть). Поэтому, отвечая на вопрос "что делать", стоит иметь в виду, что все меры, принимаемые для предотвращения срыва сроков, можно условно разделить на две большие группы: "упреждающие" и "постфактум". Упреждающие меры - это меры, принимаемые до начала проекта. В частности, это может быть детальный план работ, с контролем по срокам и качеству вплоть до каждой мелкой работы, серьезные штрафные санкции в случае несвоевременного (и/или некачественного) выполнения работ, даже в случае минимальной просрочки. Меры, принимаемые постфактум, чем-то напоминают упреждающие. В частности, к мерам постфактум относятся определение стратегии в отношении проекта (продолжаем ли делать вообще, может быть, его проще и дешевле свернуть), оценка шансов его реализации, совместное с исполнителем составление детального плана работ и жесткое ему следование. Хорошим рычагом воздействия на исполнителя становятся штрафные санкции (которые в договоре лучше прописывать так, что их взимание должно быть на усмотрение заказчика).

Конечно, в теории все это выглядит довольно красиво. На практике же с ситуацией, когда сроки превышают мыслимые пределы, бороться довольно сложно. И "крайний" (с точки зрения руководства) находится довольно легко, и общая обстановка не располагает к возвышенной философии - закончить бы проект. Но, несмотря ни на что, проекты делаются, решения внедряются, а жизнь - продолжается. Что не может не радовать.

Оригинал и комментарии: ITBlogs.ru