Риски аутсорсинга

Теперь рассмотрим некоторые специфические риски аутсорсинга, которые необходимо также учитывать.

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

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

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

Глава 5 Организация проекта

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

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

Проектная работа

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

Но жизнь опровергает подобное заблуждение. Независимо от типа организации, программного и аппаратного обеспечения, квалификации сотрудников каждый раз повторяется один и тот же сценарий жизни программного приложения. Он длится в среднем 10-15 лет, а при стре- мительном изменении внешней среды, как это было в последние годы у нас, — 5-7 лет. В течение этого времени программное обеспечение многократно дорабатывается, адаптируясь к новым условиям. Появля- ется большое количество различных дополнительных решений, реали- зованных вне рамок системы. При этом решения разрабатываются раз- личными людьми, при полном отсутствии каких-либо стандартов и до- кументации. Потом возникает необходимость установления связей между этими доработками, и количество проблем, требующих решения, возрастает многократно, становясь нерешаемыми.

В результате возникает ситуация, когда небольшое ядро, некогда являвшееся современной и перспективной системой, обрастает неконт- ролируемым множеством утилит и заплаток. Простое увольнение одно- го из программистов (средний срок работы программиста в кредитной организации 3 — 5 лет) приводит к полной переработке целой области информационных задач. Надежность, защищенность подобной систе- мы не удовлетворяет никаким требованиям. И отсутствие проблем со службой безопасности объясняется только тем, что в России службы безопасности очень редко занимаются анализом программного обес- печения в банке. Любое изменение в правилах учета и обработки ин- формации все сложнее реализуется в установленные сроки. Даже если компания-разработчик своевременно предоставляет все доработки, служба автоматизации банка не успевает своевременно адаптировать свои решения к новым условиям.

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

Однако выделенные деньги и поддержка руководства не гарантиру- ют того, что проект будет удачным. Он может быть вообще нереализо- ван. По данным ряда зарубежных консалтинговых агентств, около 20% проектов не внедряются. Хотя, если проект будет реализован, скорее всего затраты на него будут существенно выше ожидаемых. По тем же данным, только 16% проектов реализуются в соответствии с первона- чальными планами, а затраты на реализацию остальных в среднем в 1,8 раза выше утвержденных бюджетом.

Рассмотрим, какие шаги придется выполнить организации, чтобы минимизировать потери и увеличить шанс успешного завершения проек- та. Мы уже останавливались на особенностях проектной работы в самой первой главе, где проектный подход рассматривался как один из ключе- вых подходов к организации ИТ-службы банка. Но настало время оста- новиться на этом и рассмотреть отличия проектной и традиционной форм организации работы. Прежде всего нам необходимо определиться с тем, что же такое проект. Мы будем опираться на широко распространенную за рубежом методику управления проектами РМВОК 2000.

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

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

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

Примеры проектов:

• разработка новой услуги;

• внутренние организационные изменения;

• реинжиниринг бизнес-процессов;

• разработка и внедрение новой информационной системы;

• внедрение новой бизнес-практики или процесса;

• развитие филиальной сети;

• техническое перевооружение;

• создание позитивного рыночного имиджа.

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