Пример приоритезации запросов пользователей

Градация приоритета	Степень приоритета	Гарантированное время реагирования
Высокий — 1	высокая — система не работает, пароли, прочее	менее 1 часа
Среднии — 2	средняя — некоторые функции не работают	в течение 4 часов
Низкий — 3	низкая — общие вопросы, не останавливает работу	в течение дня

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

• Отслеживание статуса заявки. Система должна позволять присваивать заявкам разные приоритеты и переводить их из одного статуса в другой.

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

• Механизм электронной авторизации заявки также должен поддерживаться системой, что позволит ускорить процесс в целом.

• Хранение прошлых проблем (заявок) и их решений (ответов на информационные запросы). Удобная поисковая система должна облегчать работу с архивом.

• Автоматическое оповещение исполнителей о поступивших проблемах. Оно может быть реализовано через электронную почту или сообщения на мобильные телефоны (SMS).

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

• Генерирование отчетов о работе для целей управления и контроля.

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

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

— стоимость поддержки одного пользователя;

— стоимость поддержки функционального подразделения;

— относительное изменение стоимости поддержки пользователя;

— простой сотрудников службы сопровождения (финансовые потери).

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

— процент пользователей, довольных службой поддержки;

— оценки работы различных операторов, экспертов;

— относительное изменение суммарной оценки качества сопровождения.

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

— процент закрытых проблем от общего количества;

— процент проблем, закрытых в заданный срок;

— относительное изменение количества регистрируемых запросов;

— процент проблем, решенных на первом уровне (оператором);

— процент просроченных проблем;

— соотношение между количеством проблем каждого приоритета;

— средний срок решения проблемы;

— количество решенных проблем на одного сотрудника.

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

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

Управление аутсорсингом

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

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

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

Если говорить о целях, то, как правило, аутсорсинг используется:

— для снижения издержек (сомнительно, что этот основной двигатель аутсорсинга на Западе будет работать в российских условиях, так как заработная плата ИТ-специалиста в России существенно отстает от рыночных почасовых ставок работы. Но тем не менее иногда с помощью сторонних ресурсов действительно возможно добиться снижения издержек. Например, если несколько банков договорились об совместном использовании какого-либо объекта, они могут минимизировать свои издержки, распределяя их между собой);

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

— в случае невозможности выполнить задачу силами своих сотрудников (естественно, что в этом случае у организации просто не остается выбора и она вынуждена искать сторонние ресурсы).

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

• разработку и внедрение больших информационных систем;

• консалтинговые услуги (проведение тендеров, поиск партнеров, экспертные оценки, содействие в стратегии развития, подготовка регламентов, ИТ-аудит и т.п.);

• обслуживание и ремонт компьютерной и серверной техники;

• телекоммуникационные услуги;

• поддержку локальных сетей;

• обслуживание телефонного и офисного оборудования;

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

• поддержку дорогостоящих с точки зрения ИТ бизнес-процессов (процессинг, выпуск пластиковых карт).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Организация проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После того как определены цель и область проекта, можно перейти к более детальной его проработке и описать условия выполнения. Результатом этого этапа (для нашего примера — замены информационной системы) должны стать ответы на следующие вопросы:

• Какой видится идеальная система? В данном ответе необходимо собрать описания идеальной системы от различных подразделении и определить набор параметров, которым она должна соответствовать.

• Какие параметры системы критичны и их значения? В продолжение предыдущего вопроса необходимо помимо идеальных значении определить минимально допустимые параметры.

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

• Каков общий бюджет проекта и каковы максимально допустимые затраты? Это разные величины, определяемые оптимистичным и пессимистичным прогнозами. Различаться на практике, исходя из предоставленных ранее данных, они могут в среднем в 2 раза, а иногда и более. При этом рекомендуется сначала определить максимально допустимую сумму и после этого переходить к сумме бюджета.

Результатом первичного анализа должно быть повторное решение о начале проекта. Учитывая, что первичный анализ не приводит к существенным затратам, принятие решения о временном отказе от проекта не будет психологической проблемой. При принятии повторного решения рекомендуется ответить на все те вопросы, которые уже рассматривались нами в главе «Выбор решений».

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

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

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

Преодолеть это можно путем повышения статуса менеджера проекта. Хорошо, если его ранг будет уровня заместителя председателя банка. В этом случае различия между рядовыми участниками не будут казаться столь значительными, чтобы мешать работе. Для иллюстрации рассмотрим два примера.

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

Второй вариант. Руководитель проекта — вице-президент банка. Участники команды: главный бухгалтер, начальник отдела автоматизации, казначей (человек, отвечающий за расходы), руководитель фронт-офиса. Отношения в проектной группе при такой организации изображены на рис. 18.

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

Рис. 17. Схема взаимодействия при руководстве проектом
(вариант 1)

Рис. 18. Схема взаимодействия при руководстве проектом
(вариант 2)

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

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

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

Отдельной темой является наличие времени у участников проекта для его выполнения. Любая деятельность во внерабочее время связана с дополнительными затратами, прямыми или косвенными. Грамотный руководитель проекта сведет такие работы к минимуму или откажется от них вовсе. Хорошим инструментом в поиске свободного времени является поденный месячный график выполняемых задач в течение месяца, а также почасовой график выполняемых задач за день (табл. 14). Для большинства специалистов кредитной организации данные графики неравномерны: там есть и пики, и периоды затишья, которые и являются временным резервом проекта. В общем использование резерва является бесплатным для организации. Иногда следует выполнить ряд работ, как правило, связанных с автоматизацией бизнес-процессов, для увеличения свободного рабочего времени. Автоматизация каких работ дает наибольший эффект, видно из построенных временных графиков (рис. 19).

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

Таблица 14