Главная | Обратная связь | Поможем написать вашу работу!

Взаимодействие с внешними поставщиками

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

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

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

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

После завершения проекта по возможности следует периодически
пользоваться услугами конкурентов. Это заставит вашего основного парт-
нера постоянно совершенствовать качество предлагаемых вам услуг.

Старайтесь максимально снижать предоплаты. Как близкая к оп-
тимальной, может быть рекомендована следующая схема оплаты:

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

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

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

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

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

Тендерная форма является предпочтительной для поиска подрядчи-
ка (подробно этот вопрос рассмотрен в первой части книги на примере
выбора основной банковской системы).

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

При согласовании цен учитывайте следующее:

— среднерыночная стоимость ИТ-специалиста — $40 в час, а его
средняя зарплата — $800-1000 в месяц;

— собственно лицензия для разработчика почти ничего не стоит, все
затраты уже сделаны;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⇐ Предыдущая 30 31 32 33 343536 37 38 39 Следующая ⇒