<< Пред.           стр. 5 (из 20)           След. >>

Список литературы по разделу

  Еще одним важнейшим элементом системы обучения персонала, как это ни покажется странным, является миграция кадров (важность ротации кадров для управления персоналом отмечалась выше). Она заключается в сознательной, достаточно регулярной ротации специалистов между различными участками работы.
  Подобный процесс преследует две основные цели. Во-первых, он способствует практическому обучению различным видам деятельности, расширению профессионального кругозора и знакомству с разными ролями и их особенностями. Во-вторых, он способен обеспечить более естественное распределение исполнителей по рабочим местам, исходя из их осознанного выбора, уровня знаний и профессионализма, творческих задатков и инициативности, что в конечном счете является самым главным стимулом для всеобщего обучения.
  На практике подобная ротация может проходить как в горизонтальной плоскости, то есть на аналогичные должности (разработчик - аналитик, инженер по компьютерному оборудованию - инженер по телекоммуникациям), так и вертикальной, то есть с повышением или понижением в должности. Например, заместитель начальника отдела разработки на время может стать старшим менеджером службы сопровождения и поддержки.
  В этой связи необходимо отметить, что практически на любой должности требуется обучение, а поэтому нецелесообразно проводить подобные ротации на слишком короткое время, так как это может понизить общее качество работы. При этом необходимо учитывать специфику участка работы и подготовленность к ней конкретного специалиста. После подобной "стажировки" работник должен, как правило, возвращаться на свое основное место. В среднем банке этот процесс может осуществляться примерно по такой схеме: раз в два года работник переводится на другой участок сроком примерно на 6 месяцев. Такой режим, когда около четверти времени сотрудник работает не на своем основном месте, является оптимальным и с точки зрения обучения и повышения квалификации, и с точки зрения качества работы.
  У внутренней миграции кадров как составляющей системы обучения много неоспоримых преимуществ и почти нет недостатков. К преимуществам можно отнести, во-первых, то, что это крайне недорогой (если вообще не бесплатный) способ обучения, поскольку не требуется практически никаких материальных затрат. Во-вторых, это крайне эффективный способ обучения, так как люди сталкиваются с реальными проблемами и учатся их решать на различных местах и в различных ситуациях. Эффективность заключается также в том, что в отличие от теоретических знаний практические навыки не забываются. Наконец, как уже отмечалось, подобная ротация является очень большим мотивационным фактором обучения, так как помогает людям самовыразиться и более адекватно оценить уровень знаний и умений при распределении должностей.
  Единственный возможный недостаток данной схемы - некоторое снижение качества работ, но этим легко управлять, регулируя продолжительность и частоту работы "не на своем месте".
 
 Сертификация специалистов
 
  Сертификация ИТ-специалистов является одной из наиболее эффективных методик повышения их квалификации. По сути это вариант внешнего обучения, но в силу его специфичности мы решили рассмотреть его отдельно. Сертификация ИТ-специалистов распространена за рубежом, никаких более или менее известных российских методик и сертификатов в этой области не существует. Она представляет собой процесс сдачи квалификационных экзаменов (одного или серии) для получения признающегося в мире сертификата.
  Сертификация организовывается или известными вендорами, поставщиками программного обеспечения или техники, или некоммерческими организациями, ассоциациями. В первом случае речь идет о признании профессиональных знаний, достаточных для работы с практическими технологиями таких известных компаний. Во втором случае это, как правило, признание неким профессиональным сообществом ваших навыков к какой-то ИТ-области, например сертификаты менеджера проекта, специалиста по информационной безопасности или ИТ-аудитора.
  Примерами наиболее известных сертификационных программ первого типа могут быть сертификаты компаний Microsoft, Oracle, Cisco, Nowell.
  Примером сертификационных процессов второго типа может быть получение степени аудитора информационных систем (CISA - Certified Information System Auditor). Эта степень предоставляется ассоциацией аудита информационных систем (ISACA - Information System Audit and Control Associasion). Для получения степени необходимо сдать квалификационный экзамен и соответствовать ряду дополнительных требований в области образования, опыта работы. Как правило, такими требованиями являются профильное высшее образование и опыт работы около 3 лет по этой специальности. В целом эти требования нельзя назвать строгими (чего нельзя сказать об экзамене), так как и для этого экзамена, и для многих других разрешается заменять требуемые параметры смежными. Так, например, недостаток опыта может быть компенсирован глубоким образованием или опытом в смежных областях.
  Квалификационный экзамен строится по принципу ответа на один из четырех предложенных вариантов (так называемый Multiply Choice Question). Экзамен состоит из 200 вопросов на английском языке по семи областям:
  * процесс аудита информационных систем;
  * планирование, организация и управление ИТ;
  * техническая инфраструктура и операционная практика;
  * защита информационных активов;
  * планирование действий на случай чрезвычайных ситуаций и сбоев;
  * разработка, приобретение, внедрение и поддержка информационных систем;
  * оценка бизнес-процессов и управление рисками.
  Соискателям предоставляются четыре часа времени для ответа на все вопросы. Экзамен является платным (около $500) и проходит раз в год одновременно в нескольких странах, в том числе в Москве. Экзамен считается сданным, если более 75% ответов правильные. При успешной сдаче экзамена и соответствии требованиям соискателю присваивается данная сертификационная степень и высылается сертификат. В приложениях приведен пример из двадцати вопросов с ответами по этому экзамену.
  Другим примером может быть получение степени сертифицированного руководителя проекта (РМР - Project Management Professional). Эта степень предоставляется Институтом проектного управления (Project Management InstiTute). Для получения степени необходимо пройти небольшое начальное обучение (35 часов), сдать квалификационный экзамен, а также соответствовать дополнительным требованиям по образованию и практическому опыту управления проектами. Экзамен платный (цена приблизительно такая же, как и в предыдущем случае), возможна сдача в России. Данная степень является важным элементом развития для ИТ-менеджеров и руководителей проектов в области ИТ.
 
 Обучение пользователей
 
  Еще одним важным элементом системы обучения является обучение пользователей. Уже отмечалась, что этот процесс дает много преимуществ для эффективной работы информационных технологий. Во-первых, грамотные пользователи облегчают внедрение и сопровождение программных продуктов. Взаимодействие между ИТ-специалистами и пользователями в этом случае намного облегчается. Во-вторых, они более восприимчивы к нововведениям, так как практически не испытывают страха перед новыми технологиями и изменениями. В-третьих, в процессе обучения пользователей ИТ-специалисты сами повышают свой профессиональный уровень. Они лучше начинают понимать проблемы пользователей, бизнес-требования, необходимость более удобных и "дружественных" решений.
  Такое обучение обычно целесообразно организовывать в форме краткосрочных (1-2 часовых) семинаров. По тематике они могут быть общей направленности (например, обучение офисным или финансовым приложениям) или специальные (например, новые функциональные возможности какого-либо приложения или наиболее часто задаваемые службе сопровождения вопросы). Пользователям заранее должны предоставляться график таких обучений и их тематика, после этого они по согласованию со своим руководством могут записываться на эти программы. Иногда руководитель подразделения может принудительно послать пользователя на какой-либо курс, если у того есть сложности с эксплуатацией программного продукта или ему требуется получить новые знания для выполнения работы.
 
 Обслуживание пользователей
 
  Ежедневно в ИТ-подразделении среднего банка раздаются десятки звонков пользователей с различными вопросами. Это могут быть просьбы, проблемы, консультации, информационные запросы, справки и т.п. Большинство являются рутинными, не срочными проблемами, но некоторые из них, если не будут решены в кратчайшее время, могут привести к существенным сбоям в бизнес-процессе, или даже к остановке работы всего банка.
  Как их правильно классифицировать? Как сделать так, чтобы ни одна заявка не была забыта? Как объяснить руководству банка, что несколько человек, которые постоянно говорят с "кем-то" по телефону, не бездельники, а выполняющие важную работу специалисты? Наконец, как сделать, чтобы пользователи могли легко связаться с "правильным" работником ИТ и были уверены, что им быстро и квалифицированно окажут помощь и их проблема будет решена за необходимое время.
  Все это является проявлением эффективной организации поддержки работников организации, которая чрезвычайно важна в современном банке и в первую очередь влияет на мнение работников и руководства банка, которое тоже является пользователем, об ИТ-менеджменте и качестве работе этой службы.
  В настоящей главе мы рассмотрим организацию этого процесса как одну из самых основных подзадач операционного управления информационными технологиями.
 
 Принципы поддержки пользователей
 
  Итак, какова best practice организации обслуживания и поддержки пользователей?
  Во-первых, разработка бизнес-процессов. Необходимо, чтобы процесс поддержки пользователей был детально проработан и задокументирован, к нему требуется такое же внимательное отношение, как и к любому другому бизнес-процессу банка. Это означает создание четкого алгоритма обработки заявок, их классификацию, регистрацию, исполнение, контроль и т.п. Такой бизнес-процесс должен быть апробирован с точки зрения необходимых ресурсов для требуемого уровня качества и скорости решения проблем. Пользователям должно быть понятно, как организован процесс их технической поддержки, ясны их права и обязанности. Необходимо предусмотреть "исключения" и нестыковки (например, если пользователь и ИТ-специалист не согласны в приоритетах работы).
  Во-вторых, единая точка входа. Сотрудники банка не должны держать в уме по несколько телефонов и имен специалистов, отвечающих за тот или иной участок. Должен существовать единый телефон службы поддержки, которая координирует всю работу и взаимодействует с бизнес-пользователями по всем запросам. Эффективное использование специально выделенного адреса электронной почты и автоответчиков для записи звонков.
  В-третьих, приоритезация обращений. Для эффективной обработки все обращения должны быть оценены и приоритезированы. Это связано с тем, что невозможно одинаково быстро отработать все проблемы, тем более что большинство из них и не требуют быстрого решения. Поэтому приоритезация способствует более гибкому управлению ресурсами и позволяет устранять критичные проблемы.
  Это взаимодействие должно поддерживаться квалифицированным оператором. Такой оператор, являясь работником службы сопровождения, осуществляет регистрацию проблем. Он должен обладать необходимой квалификацией, так как правильное понимание проблемы, ее первичная диагностика очень важны. Далее осуществляется приоритезация этой проблемы и ее направление профильному сотруднику, в случае если она не может быть решена сразу оператором, который может осуществлять консультирование пользователей по незначительным вопросам, например функционирование офисных приложений и программ. Отслеживание статусов запросов и доведение информации по ним также является задачей этого специалиста.
  Следующий пункт - база данных запросов. В ней осуществляется первичная регистрация обращений, установка приоритета по ним. В таких базах данных может поддерживаться и дополнительная функциональность, например маршрутизация проблем соответствующим ИТ-специалистам, информационное оповещение пользователей, автоматизированный контроль исполнения заявок, подготовка отчетности.
  И последний пункт - отчетность и контроль. Исполнение заявок должно контролироваться на выборочной основе, информация по статусам проблем должна быть доступна для пользователей. По результатам работы за период составляется отчетность, которая предоставляется руководителям бизнес-подразделений. Это позволит им оценить, во-первых, уровень поддержки их подразделения со стороны ИТ, а во-вторых, уровень компетенции своих сотрудников и беспокоящие их проблемы.
 
 Технологическая схема работы
 
  Технологическая схема организации работы службы поддержки пользователей представлена на рис. 11. Рассмотрим отдельные моменты этой технологии и сделаем необходимые комментарии.
 
 
  "Рис. 11. Схема организации работы службы поддержки пользователей"
 
  Технология предполагает четыре основных группы участников процесса: пользователей, диспетчера (оператора), авторизующего сотрудника, исполнителей.
  Роль авторизирующего сотрудника состоит в подтверждении заявок, требующих дополнительной авторизации (например, первый приоритет), или запросов, требующих существенного отвлечения ресурсов (например, визит на другую территорию). Для этого он может инициировать или производить дополнительную обработку заявки, а именно взаимодействие с пользователем для прояснения дополнительных моментов, оценку доступных ресурсов и т.п. Таким авторизующим сотрудником, как правило, является старший специалист службы сопровождения или руководитель службы сопровождения, если таковая существует (в маленьких банках организация такой службы может не иметь смысла).
  Оператор отвечает за решение проблем или их перенаправление к соответствующим специалистам и за удовлетворение потребностей пользователей, следя за тем, чтобы все запросы были обработаны, и своевременно сообщая о возможных задержках. Другой его задачей являются передача и накопление знаний. Он может выделять типичные проблемы и организовывать мероприятия по их предотвращению (тренинги, информационные сообщения).
  Исполнители по проблемам отвечают за разрешение проблемы или поставленной задачи в требуемый период времени и отражение результатов работы в информационной базе данных.
 
 Типы запросов и приоритезация
 
  Все запросы пользователей можно условно разделить на три основные группы: информационные, сервисные, проблемные.
  Информационные запросы представляют собой запросы на предоставление информации и консультации по информационным технологиям и ресурсам. Сюда можно отнести вопросы по функциональности программных приложений и офисных систем, организационным процедурам (что нужно сделать, чтобы получить новый компьютер или установить программное обеспечение), наличию и возможности получения данных и т.п. На такие запросы оператор отвечает немедленно или, при необходимости, после короткого дополнительного поиска информации.
  Сервисные запросы - это запросы на оказание стандартных услуг (регистрация новых пользователей, заказ нового оборудования, установка стандартного программного обеспечения, настройка прав доступа и параметров информационной безопасности, сбрасывание блокирования учетных записей пользователей и др.).
  И последняя группа - это сообщения о проблемах при работе систем, ошибках в программном обеспечении и т.п. Как правило, пользователи склонны преувеличивать критичность происходящего и большинство проблем относить к ошибкам в работе систем, но практика показывает, что очень существенная часть таких обращений может быть связана с непониманием особенностей функционирования ИТ, ограничений информационной безопасности или просто с низким уровнем компьютерной грамотности.
  Как уже отмечалось, одной из основных задач оператора службы сопровождения являются первичная оценка, классификация и приоритезация обращений. От этого зависят и качество обслуживания клиентов, и эффективность деятельности этой службы, под которой мы понимаем способность с требуемым уровнем качества обслужить всех пользователей организации, задействуя минимальные ресурсы со стороны ИТ. Необходимо учитывать, что способность к быстрой оценке проблемы является практическим навыком и не любой ИТ-специалист может выполнить такую работы. Для этого требуются специфические навыки, широкие знания по ИТ (иногда достаточно даже вполне поверхностных), умение эффективно общаться с людьми, быстро принимать решение.
  Также оператором должен присваиваться приоритет проблемы, который, как правило, определяет и время реакции или решения. Пример приоритетов запросов приведен в табл. 7.
 
  Таблица 7
 
 Пример приоритезации запросов пользователей
 
 ----------------------T-----------------------T-------------------------¬
 ¦Градация приоритета ¦ Степень приоритета ¦ Гарантированное время ¦
 ¦ ¦ ¦ реагирования ¦
 +---------------------+-----------------------+-------------------------+
 ¦Высокий - 1 ¦высокая - система не¦менее 1 часа ¦
 ¦ ¦работает, пароли,¦ ¦
 ¦ ¦прочее ¦ ¦
 +---------------------+-----------------------+-------------------------+
 ¦Средний - 2 ¦средняя - некоторые¦в течение 4 часов ¦
 ¦ ¦функции не работают ¦ ¦
 +---------------------+-----------------------+-------------------------+
 ¦Низкий - 3 ¦низкая - общие вопросы,¦в течение дня ¦
 ¦ ¦не останавливает работу¦ ¦
 L---------------------+-----------------------+--------------------------
 
 База данных запросов и автоматизация
 
  Эффективная работа службы поддержки пользователей невозможна без соответствующей программной поддержки и автоматизации. Как уже отмечалось, такие средства автоматизации представляют собой базы данных запросов в службу поддержки пользователей. Рассмотрим отдельные функциональные возможности, которые они могут предоставлять, облегчая работу и управление этой ИТ-функцией.
  * Отслеживание статуса заявки. Система должна позволять присваивать заявкам разные приоритеты и переводить их из одного статуса в другой.
  * Автоматическое оповещение о подходе крайнего срока решения проблемы. Данная возможность позволит избегать ситуации, когда о запросе просто забыли.
  * Механизм электронной авторизации заявки также должен поддерживаться системой, что позволит ускорить процесс в целом.
  * Хранение прошлых проблем (заявок) и их решений (ответов на информационные запросы). Удобная поисковая система должна облегчать работу с архивом.
  * Автоматическое оповещение исполнителей о поступивших проблемах. Оно может быть реализовано через электронную почту или сообщения на мобильные телефоны (SMS).
  * Поиск похожей проблемы с решением позволит решать большее количество заявок сразу, без направления к другому ИТ-специалисту (исполнителю).
  * Генерирование отчетов о работе для целей управления и контроля.
 
 Отчетность и контроль
 
  Следующей важной составляющей процесса организации поддержки пользователей являются отчетность и контроль. На рис. 12 графически представлен эффективный интегрированный подход к этому процессу.
  Согласно схеме основной задачей формирования отчетности является постоянная оценка деятельности службы поддержки для последующего совершенствования ее бизнес-процессов. В основе отчетных форм должны лежать четыре группы показателей, оценивающие следующие аспекты деятельности: финансовые, удовлетворенность пользователей, эффективность внутренних процессов, нововведения.
 
 
  "Рис. 12. Контроль за обслуживанием пользователей"
 
  Финансовые показатели служат для оценки финансово-экономических аспектов деятельности. Они помогают проанализировать, как служба поддержки помогает достичь целей банка. Приведем примеры таких показателей:
  - стоимость поддержки одного пользователя;
  - стоимость поддержки функционального подразделения;
  - относительное изменение стоимости поддержки пользователя;
  - простой сотрудников службы сопровождения (финансовые потери).
  Показатели удовлетворенности должны показывать, растет ли удовлетворенность сотрудников банка, как они оценивают качество услуг. Это может быть реализовано через электронные формы-опросы, которые прикрепляются к электронному ответу на заявку или посылаются после устного разрешения проблемы. Обратная связь с каждым пользователем, поместившим заявку, может быть очень полезна. Примеры показателей удовлетворенности:
  - процент пользователей, довольных службой поддержки;
  - оценки работы различных операторов, экспертов;
  - относительное изменение суммарной оценки качества сопровождения.
  Показатели эффективности внутренних процессов отражают, насколько эффективно организована служба поддержки и позволяют выявить отдельные слабые места в технологии работы. Примеры таких показателей:
  - процент закрытых проблем от общего количества;
  - процент проблем, закрытых в заданный срок;
  - относительное изменение количества регистрируемых запросов;
  - процент проблем, решенных на первом уровне (оператором);
  - процент просроченных проблем;
  - соотношение между количеством проблем каждого приоритета;
  - средний срок решения проблемы;
  - количество решенных проблем на одного сотрудника. Показатели нововведений иллюстрируют, как используется опыт лидеров индустрии. Примером может быть количество изменений в технологии работы.
  Все эти отчеты могут на регулярной основе предоставляться бизнес-менеджерам и обсуждаться на комитете по информационным технологиям, что будет важным элементом системы внутреннего контроля за деятельностью ИТ в этой части.
 
 Управление качеством
 
  Постоянной головной болью ИТ-менеджеров являются претензии пользователей по качеству продуктов и услуг. При этом каждому практикующему ИТ-менеджеру очевидно, что окончательно избавиться от претензий, наверно, невозможно, но существенно сократить их, добиться в целом положительной оценки деятельности ИТ-службы или работы отдельных программ - вполне реальная и необходимая задача, которая является одной из базовых задач ИТ-менеджмента и оперативного управления ИТ. Рассмотрим основные направления такой работы.
  В современном расширенном толковании качество понимается как способность продукта или услуги удовлетворить потребности и ожидания каждого конкретного потребителя. Если деятельность ИТ-службы не соответствуют ожиданиям каждого конкретного клиента-пользователя, другими словами - качество ИТ-услуг низкое, то это может быть источником сбоев в работе, снижения авторитета ИТ-подразделения, недостатка финансирования со стороны бизнес-подразделений и т.п. Поэтому при организации работы ИТ-службы прежде всего необходимо ориентироваться на удовлетворение потребностей пользователей и совершенствование системы контроля и управления качеством.
  За рубежом разработаны и успешно применяются на практике различные методики управления качеством, как общие (TQM, Six Sigmas, IS09000), так и специализированные, предназначенные для управления качеством программных продуктов (TickIT).
 
 Всеобщее управление качеством (TQM)
 
  Одной из основополагающих и широко используемых в международной практике концепций, помогающих руководителям решать задачи контроля и управления качеством, является методология "Всеобщее управление качеством" (Total Quality Management, TQM). Мы полагаем, что в современных условиях она вполне применима для ИТ. Но прежде чем мы рассмотрим ее основные положения и возможности их применения, необходимо остановиться на истории создания TQM.
  Концепция всеобщего управления качеством зародилась в США, а в полном объеме впервые была реализована в Японии. Именно американские ученые-экономисты Эдвард Деминг (1900-1993) и Джозеф Джуран (1903-1993), направленные, согласно плану Маршалла, для оказания помощи разрушенной в ходе войны экономике Японии, впервые сформулировали те общепризнанные сегодня принципы, которые и составили концептуальную основу TQM. Эти принципы стали главной составляющей феномена, так хорошо всем известного под названием "японское чудо".
  В основу концепции TQM легли базовые принципы, сформулированные и изложенные Демингом:
  * улучшение качества продукции и услуг должно стать постоянной и приоритетной задачей для всей организации, в том числе и для высшего руководства;
  * необходимо внедрять новую философию и отношение к окружающим процессам;
  * постоянно соотносить качество и удовлетворенность потребителя с ценой;
  * вести постоянное обучение, прежде всего на рабочем месте;
  * устранять барьеры между подразделениями;
  * искоренять страх перед переменами;
  * дать возможность всем служащим гордиться принадлежностью к организации;
  * всячески поощрять образование и самосовершенствование;
  * вовлечь каждого в работу по преобразованию;
  * избегать пустых лозунгов;
  * организовать руководство таким образом, чтобы его основным предназначением была помощь работникам;
  * отказаться от контроля качества только посредством проверок и ревизий;
  * стремиться к постоянному улучшению всей системы функционирования организации;
  * искоренять "уравниловку" персонала.
  Идея концепции всеобщего управления качеством, основанная на этих принципах, - глобальное расширение понятия качества и утверждение процесса управления им как основной задачи менеджмента.
  Согласно TQM общее управление качеством (или системой качества) включает такие составляющие, как оперативное управление качеством на всех стадиях жизненного цикла, обеспечение внутреннего и внешнего качества, планирование и улучшение качества. При стратегической нацеленности на изложенные выше принципы, участии руководства и всех сотрудников организации в этих процессах возникает всеобщее управление качеством.
  Обеспечение должного уровня качества включает комплекс средств, направленных на достижение уверенности в качестве продукта или услуги у внешних и внутренних потребителей (существующих и потенциальных клиентов, персонала и партнеров организации).
  Планирование и улучшение качества являются также постоянными составляющими, обеспечивающими прогнозирование и постоянное увеличение требований к оперативному управлению и обеспечению качества услуг. Основной целью всей системы контроля качества, как уже отмечалось, должно стать максимально полное удовлетворение потребностей пользователей.
 
 Стандарт качества ISO 9000
 
  Остановимся на основных моментах управления качеством услуг в соответствии со стандартами серии ISO 9000. Для этого прежде всего обратимся к его терминам и определениям.
  Программное обеспечение - интеллектуальный продукт, состоящий из программ, процедур, правил и любой другой связанной с ними документации, относящейся к функционированию системы обработки данных.
  Элемент программного обеспечения - какая-либо идентифицируемая часть продукции программного обеспечения на промежуточном или конечном этапе разработки.
  Разработка - все виды деятельности, выполняемые для создания программного обеспечения.
  Проверка программного обеспечения - процесс оценивания продукции данной фазы в целях обеспечения правильности и согласованности в отношении продукции и стандартов, являющихся входными для данной части работы (фазы).
  Аттестация программного обеспечения - процесс оценивания программного обеспечения в целях обеспечения соответствия установленным требованиям.
  Услуга - итог непосредственного взаимодействия поставщика (Supplier) и потребителя (Customer), а также внутренней деятельности поставщика по удовлетворению потребности потребителя.
  Предоставление услуги (Service Delivery) - деятельность поставщика, необходимая для обеспечения услуги.
  Качество услуги - совокупность свойств и характеристик услуги, обеспечивающих удовлетворение обусловленных или предполагаемых потребностей.
  Требования к качеству - выражение определенных (установленных или предполагаемых) потребностей потребителя и их перевод в набор количественных или качественных оценок характеристик услуги.
  Характеристики услуг подразделяются на виды: характеристики процесса предоставления услуги и характеристики самой услуги. Характеристики (оба вида) должны обладать способностью оцениваться. Оценка возможна количественная (измеряемая) и качественная (сопоставимая). Характеристики процесса предоставления услуги в основном не определяются потребителем, они служат обоснованием и доказательством того, что характеристики самой услуги будут обеспечены на заявленном уровне.
  Стандарт ISO 9000 помимо основной терминологии регламентирует процесс подготовки и предоставления услуги, а также систему качества.
  Принято считать, что достижение требуемого качества возможно благодаря строгому следованию этапам (или основным составляющим) процессов, описанных в стандарте, и работе по общему управлению качеством (или системе качества). Рассмотрим применяемую на практике методику подготовки услуги, соответствующую стандарту ISO 9000, и ее этапы.
  Определение будущей услуги базируется на аналитическом исследовании деятельности и потребностей существующих и потенциальных клиентов. При анализе должна учитываться точка зрения потребителя на все аспекты услуги. Процедура определения может состоять из следующих шагов.
  Шаг 1. Определить и поименовать потребность, подлежащую удовлетворению услугой.
  Шаг 2. Определить, в какой потенциальной группе клиентов эта потребность существует.
  Шаг 3. Описать ту часть услуги (работу, результаты работы и т.д.), которая удовлетворит выявленную потребность.
  Шаг 4. Определить, по каким характеристикам клиент будет оценивать услугу и степень удовлетворения услугой своей потребности.
  Спецификация услуги - основополагающий документ, содержащий основные составляющие и потребительские свойства услуги, разрабатывается на основе принятого определения услуги. Документ является первым в пакете проектной документации по услуге. После утверждения документ используется в процессе продвижения и управления качеством услуги.
  Спецификация процессов предоставления услуги - документ, определяющий основные этапы работы и ресурсы, гарантирующие предоставление услуги в соответствии с ее спецификацией. Спецификация процессов должна содержать: методики предоставления услуги (инструкции по выполнению работ для персонала кредитной организации), способы предоставления (описание инициирующих условий, организационных действий поставщика и потребителя, формы и способы взаимодействия, временные и территориальные ограничения), информационные материалы, процедуры разрешения спорных ситуаций, шаблоны договоров и прочие документы по услуге.
  Спецификация управления качеством. Этот этап должен включать определение ключевых работ, существенно влияющих на качество предоставления услуги, выборку и анализ характеристик предоставляемой услуги, определение методов оценки характеристик в процессе предоставления услуги, определение средств влияния на улучшение качества услуг.
  Подготовка персонала. Персонал - основной ресурс, определяющий качество услуги. Руководитель подразделения, участвующий в процессе предоставления услуги, обязан: определить квалификационные требования, необходимые и достаточные для выполнения конкретной работы; подбирать/назначать сотрудников, удовлетворяющих квалификационным требованиям; обеспечить условия выполнения работы, обращать внимание сотрудников на то, что их работа напрямую влияет на уровень качества услуги; стимулировать и поощрять усилия персонала, направленные на повышение качества. Руководитель подразделения в плановом порядке обязан проводить мероприятия по совершенствованию профессиональных навыков и умений сотрудников.
  Реклама и продвижение услуги. Для формирования и разработки рекламной политики и программы продвижения услуг необходимо использовать спецификации услуг и процессов их предоставления.
  Клиент, читая или рассматривая рекламу, должен находить ответы наследующие вопросы, определяющие сегодня конкурентоспособность услуги.
  Существует ли у меня неудовлетворенная потребность из тех, что описаны в рекламных материалах?
  Соизмеряется ли стоимость услуг с их качеством?
  Действительно ли поставщик способен оказать необходимую услугу?
  Насколько выгоднее обратиться к данному поставщику, чем к другим?
  Рассмотрим теперь элементы системы качества, необходимые для ее соответствия требованиям стандарта ISO 9000. Для этого введем точное определение этого термина. Стандарт ISO 9000 использует определение из ISO 8402: система качества - это совокупность организационной структуры, методик, процессов и ресурсов, необходимых для общего управления качеством. Все эти элементы системы качества должны быть задокументированы. Документация должна давать четкие гарантии, что элементы системы качества обеспечивают потребителю получение качественной услуги - выполнение обещаний поставщика услуги, а также удовлетворение потребности и ожиданий потребителя.
  В стандартах серии ISO 9000 предыдущих редакций содержались рекомендации по управлению качеством программных продуктов. Сформулируем основные из них.
  Ответственность, полномочия и взаимодействие всего персонала, который руководит, выполняет и проверяет работу, оказывающую влияние на качество, должны быть четко определены.
  Анализ проекта и проверки системы качества, процессов, услуг и/или программ должны выполняться персоналом, независимым от тех, кто несет непосредственную ответственность за выполненную работу.
  Поставщик должен назначить представителя руководства, который, независимо от других обязанностей, должен иметь определенные полномочия и нести ответственность за выполнение и соблюдение требований стандартов качества.
  Покупатель (клиент) должен сотрудничать с поставщиком с целью обеспечения его всем необходимым для разрешения возникающих проблем.
  Покупатель (клиент) должен назначить ответственного со стороны руководства за связь с поставщиком. Этот представитель должен иметь необходимые полномочия для решения следующих вопросов: определения требований; ответов на вопросы поставщика; заключения соглашений и прием предложений; гарантировать соблюдение соглашений; определять порядок и критерии приемки решения; принимать решения по тем элементам программного обеспечения, которые признаны непригодными.
  Регулярный совместный анализ, проводимый заказчиком и поставщиком, должен планироваться так, чтобы охватить следующие вопросы: соответствие программного обеспечения техническому заданию, согласованному с покупателем; результаты контроля; результаты приемочных испытаний. Результаты анализа должны быть документированы.
  Система качества должна представлять собой единый процесс, проходящий через весь жизненный цикл продукции, гарантируя, что качество соблюдается в ходе всего процесса разработки и поставки. Упор необходимо делать на предупреждение появления дефектов, а не на исправление их после возникновения.
  Поставщик должен документально оформить план качества и осуществлять регулярные проверки в соответствии с ним.
  Поставщик должен документально оформлять и выполнять процедуры, обеспечивающие: выявление причин несоответствия продукта и корректирующие воздействия, предупреждающие возникновение дефекта; анализ всех процессов и рекламаций потребителей с целью выявления и устранения потенциальных причин; проведение профилактических действий для решения проблем на уровне, соответствующем реальному риску; осуществление контроля, внедрение изменений в процедуры и процессы.
  Для обеспечения механизма идентификации, контроля каждого элемента программного обеспечения используется управление конфигурацией. Система управления конфигурацией должна: однозначно идентифицировать каждый вариант элементов программного обеспечения; идентифицировать варианты элементов программного обеспечения, которые вместе образуют конкретный вариант готового продукта; управлять одновременной модернизаций конкретного элемента продукта, проводимой более чем одним человеком; обеспечивать координацию работы; идентифицировать и отслеживать все мероприятия.
  Проект разработки программного обеспечения должен осуществляться в соответствии с моделью жизненного цикла программного обеспечения, который будет рассмотрен ниже.
 
 Жизненный цикл программного обеспечения
 
  Жизненный цикл программного обеспечения влияет на многие составляющие ИТ-менеджмента, но мы рассматриваем его в данной главе, потому что, по нашему мнению, он наиболее удачно сформулирован в стандартах управления качеством серии ISO 9000. По ним жизненный цикл ПО состоит из следующих составляющих.
  Анализ контракта. Поставщик должен устанавливать и выполнять процедуры, обеспечивающие проведение анализа контракта и координацию этой деятельности. Каждый контракт должен быть изучен поставщиком с целью гарантии того, что область действия контракта и требования определены и документированы, риски идентифицированы, конфиденциальная информации защищена, поставщик и потребитель имеют возможности выполнить контрактные требования; определена ответственность сторон, терминология согласована.
  С точки зрения качества целесообразно включение в контрактные документы следующих пунктов: критерии приемки; учет изменений в требованиях заказчика в процессе разработки; проработку проблем, выявленных в ходе приемки; ответственность заказчика за подготовку требований, приемку и т.п.; средства, инструменты и элементы поставляемого программного комплекса; применяемые стандарты и процедуры; особенности тиражирования.
  Техническое задание заказчика. Для разработки программного обеспечения поставщик должен иметь полный и однозначный набор функциональных требований. Кроме того, эти требования должны отражать все аспекты, необходимые для удовлетворения потребностей покупателя (например, эксплуатационные качества, требования безопасности, конфиденциальности и надежности). Эти требования должны быть сформулированы достаточно точно, чтобы производить необходимую оценку в процессе приемки. Все требования должны документально оформляться. Как правило, это осуществляется заказчиком или совместно. При этом окончательный вариант технического задания должен обязательно взаимно согласовываться. Технические задания должны использоваться в процессе управления конфигурацией.
  В процессе разработки технического задания рекомендуется обратить внимание на следующие вопросы: назначение лиц с обеих сторон, ответственных за разработку технического задания; методы согласования требований и утверждения изменений; определение терминов, разъяснение исходных данных в отношении требований и прочие действия, которые способствуют устранению взаимного непонимания; документирование дискуссий и обсуждений.
  Планирование разработки. План разработки должен охватывать: описание проекта, включая постановку задачи; организацию управления и ресурсы проекта (состав команды); фазы разработки; программу работ над проектом, устанавливающую задачи, которые должны быть решены, распределение их по имеющимся ресурсам, временные рамки; взаимную увязку мероприятий. План разработки должен корректироваться по ходу осуществления работ, при этом каждая фаза должна быть четко описана до начала работ по ней.
  План разработки должен устанавливать упорядоченный процесс или методологию преобразования технического задания заказчика в конечный продукт. Он может включать в себя распределение работ по фазам, необходимые затраты по каждой фазе, требуемые результаты, процедуры проверки и приемки, анализ потенциальных проблем, связанных с фазами разработки и выполнением установленных требований. Также в нем должны отражаться механизмы управления проектом, в том числе план-график работ, контроль за ходом проекта, ответственность сторон и участников, система взаимодействия между различными участниками работ. Следующей составляющей плана разработки должны быть методы и средства разработки, технические приемы, используемые в ходе реализации, конфигурационный менеджмент.
  Еще одним необходимым элементом планирования разработки должен быть анализ хода выполнения разработки, который должен осуществляться на регулярной основе и оформляться документально с тем, чтобы обеспечить решение спорных вопросов и гарантировать эффективное выполнение задачи.
  Результаты выполнения каждой фазы должны быть определены и документально оформлены. Они должны быть проверены и удовлетворять следующим условиям: отвечать установленным для каждой фазы требованиям; содержать критерии приемки; соответствовать принятой практике и опыту разработки независимо от того, оговорены ли они во входной информации; соответствовать действующим нормативным требованиям.
  Проверка разработки должна осуществляться после каждой фазы и определять, соответствует ли представленное решение требованиям, установленным в начале фазы. Эти проверки могут производиться в форме испытаний или демонстрационных показов. Только проверенные результаты разработок должны быть представлены на рассмотрение для управления конфигурацией и приняты для последующего использования.
  Планирование качества. Поставщик должен подготовить план качества как часть работ по планированию разработки. Данный документ должен содержать: цели качества, выраженные в измеряемых показателях; заданные критерии по затратам и результатам для каждой фазы разработки; идентификацию видов деятельности, связанной с испытаниями, проверками, оценками, которые должны быть проведены; детальное распределение ответственности за мероприятия по обеспечению качества, такие, как анализы и испытания, управление конфигурацией и контроль за изменениями, контроль дефектов и корректирующие воздействия.
  Проектирование и реализация. Проектирование и реализация - это те виды деятельности, которые трансформируют техническое задание заказчика в конечный программный продукт. Уровень раскрытия информации между сторонами должен быть взаимно согласован, так как часто процессы и технология проектирования и реализации являются собственностью поставщика.
  В дополнение к требованиям, общим для всех фаз жизненного цикла, необходимо учитывать следующие аспекты, присущие проектированию. В ходе работ должна использоваться методология системного проектирования, соответствующая виду разрабатываемого ПО. Необходимо использовать накопленный опыт во избежание повторения прошлых ошибок проектирования. Продукт должен быть спроектирован так, чтобы можно было без помех проводить испытания, техническое обслуживание и использовать продукт.
  При реализации следует применять единые правила, которые включают правила программирования, языки и среды разработки, согласованные правила наименования, кодирования и соответствующих комментариев. Поставщик должен использовать методологию разработки. Должен проводиться регулярный анализ с целью проверки соблюдения установленных методологических подходов.
  Испытание и оценка качества. Проведение испытаний может быть необходимо на различных уровнях, от отдельного элемента программного обеспечения до готовой продукции. Существует несколько различных подходов к испытаниям. В некоторых случаях оценка испытания на месте и приемочные испытания могут быть одним и тем же видом деятельности.
  Поставщик должен составить и согласовать план испытаний, технические условия и процедуры испытаний до начала работ, связанных с проведением испытаний. Этот план включает: детальные планы по различным испытаниям, оценке, приемочным работам; ожидаемые результаты; типы планируемых испытаний; внешние условия при испытаниях; инструментальные средства; критерии окончания испытаний; пользовательскую документацию; необходимый персонал и требования, связанные с его обучением.
  Особое внимание рекомендуется обратить на следующие стороны испытаний: результаты испытаний должны быть запротоколированы; любые обнаруженные проблемы и их возможное влияние на остальные части программного обеспечения должны быть отмечены, и об этом должны быть извещены ответственные исполнители с тем, чтобы проблемы могли быть отслежены до тех пор, пока они не будут решены; области, которые подвергались модификации, должны быть идентифицированы и повторно испытаны; должна быть оценена адекватность и релевантность испытаний; конфигурация программных и аппаратных средств должна быть согласована и задокументирована.
  Прежде чем предложить продукцию для поставки и приемки покупателям, должна быть осуществлена оценка ее функциональных качеств, по возможности в условиях, аналогичных условиям применения.
  Приемка. Если поставщик готов поставлять продукцию, прошедшую оценку и испытания, заказчик должен решать, приемлема она или нет, согласно ранее принятым критериям и порядку, оговоренному в контракте. Метод и порядок решения проблем, обнаруженных во время приемки, должны быть согласованы между покупателем и поставщиком и оформлены документально. При проведении приемочных испытаний поставщик должен оказать содействие заказчику в вопросах определения временного плана работ, методик, программных сред и ресурсов, критериев приемки.
  Тиражирование, поставка и монтаж. Необходимо обеспечить условия для проверки правильности и полноты копий поставляемой продукции. Роль, ответственность и обязательства поставщика и заказчика должны быть четко оговорены, в том числе доступ к техническим средствам, план-график, формальные процедуры приемки продукта после поставки (монтажа).
  Обслуживание. Если заказчик требует проведения технического обслуживания программного обеспечения после первоначальной поставки и монтажа, это должно быть оговорено в контракте. Поставщик должен установить и осуществить процедуры по техническому обслуживанию, с тем чтобы удостоверить, что подобные действия удовлетворяют установленным в контракте требованиям к техническому обслуживанию.
  Виды деятельности, связанные с техническим обслуживанием программного обеспечения:
  - решение проблем;
  - модификация интерфейса;
  - расширение функций и улучшение эксплуатационных характеристик.
  Элементы, которые должны быть обслужены, и период времени обслуживания должны оговариваться в контракте. Такими элементами могут быть программы, данные и их структура, спецификации, документация.
  Все виды деятельности, связанные с техническим обслуживанием, должны осуществляться и управляться в соответствии с планом, составленным и согласованным заранее. В таком плане должны быть отражены: область технического обслуживания, первоначальный статус продукта, организация обслуживания, виды деятельности по обслуживанию, протоколы и отчеты по обслуживанию.
  Все действия, осуществляемые в процессе обслуживания системы, должны осуществляться в соответствии с подходами, используемыми при разработке программного обеспечения, насколько это возможно.
  Протоколы технического обслуживания должны включать в себя следующие пункты: перечень заявок с указанием текущего состояния по каждой; ответственное лицо; приоритеты, которые были установлены для корректирующих действий; результаты коррекции; статистические данные о случаях отказа и действиях по обслуживанию. Протокол обслуживания может быть использован для оценки и модернизации продукта и совершенствования системы качества.
  Стороны должны согласовать между собой и документально оформить процедуры, связанные с внесением изменений в программное обеспечение в результате необходимости поддерживать эксплуатационные характеристики:
  основные правила, определяющие, в каких случаях можно внести исправления, а в каких необходим выпуск полностью обновленной копии программного обеспечения;
  описание типов (или классов) выпусков в зависимости от их частоты и воздействия на деятельность заказчика;
  способы уведомления об изменениях;
  методы, подтверждающие, что осуществленные изменения не повлекут за собой возникновения новых проблем;
  требования к протоколам, указывающим, где и как производились изменения, их сущность в случае сложности продукции или наличия нескольких мест производства.
 
 Специализированный стандарт TickIT
 
  Специализированный стандарт TickIT - это схема сертификации систем качества для программного обеспечения, предложенная группой ведущих фирм и некоммерческих организаций Великобритании, работающих в области информатики. Контроль и спонсирование схемы осуществляется DTI. TickIT базируется на стандарте ISO 9001:1994, который был рассмотрен выше. Таким образом, предметом TickIT является менеджмент предприятий, разрабатывающих программное обеспечение.
  Помимо своей основы (стандарта) ISO 9001 TickIT содержит следующие компоненты:
  - руководство по TickIT, базирующееся на указаниях ISO 9000-3 (руководство по системам качества для программного обеспечения);
  - схему регистрации аудиторов через специальный комитет по TickIT IRCA (Международный регистр сертифицированных аудиторов);
  - систему проверок аудиторов Британским компьютерным обществом (BCS) и Институтом по обеспечению качества (IQA);
  - систему аккредитации сертификационных обществ - UKAS (Великобритания), SWEDAC (Швеция);
  - программы, направленные на расширение признания схемы;
  - трехлетний цикл пересмотра схемы;
  - систему специальных премий за достижения.
  Гибкая инфраструктура TickIT позволяет схеме следовать изменениям в этой весьма динамичной отрасли, обеспечивая тем самым ее постоянное совершенствование.
  В последней редакции руководства по TickIT активно используется идеология жизненного цикла программного обеспечения. Основные определения процессов жизненного цикла программного обеспечения даны в другом стандарте - ISO/IEC 12207, который может служить основой при выборе конкретной модели процессов жизненного цикла на предприятии. Таким образом, схема TickIT использует рациональное начало, заложенное в методах совершенствования процессов, таких, как СММ (Carnegie Mellon University), Trillium (Bell Canada), BOOTSTRAP и т.д. Великобритания традиционно занимает лидирующее положение в области стандартизации, поэтому неудивительно, что инициатива TickIT изначально принадлежит Великобритании.
  Несмотря на британское происхождение, TickIT широко применяется и в других странах. В списке предприятий, сертифицированных по схеме TickIT, в настоящее время присутствуют названия более 40 государств. Марка и логотип TickIT пользуются заслуженным международным авторитетом. Получение сертификата TickIT является важным шагом любой европейской софтверной фирмы на пути к завоеванию признания на рынке. По данным на май 1997 года, в Великобритании было выдано 956 сертификатов TickIT, в других странах - 338. Растет количество сертификатов, выданных за пределами Великобритании. Предполагается, что дальнейшее расширение использования схемы TickIT приведет к созданию международной европейской схемы с аккредитацией согласно EN45012/3.
  По схеме TickIT могут быть сертифицированы системы качества предприятий, занимающихся следующими видами деятельности:
  * разработкой программного продукта или услуги как для внешнего заказчика, так и для внутреннего использования, включая встроенное (embedded) программное обеспечение;
  * копированием, архивированием, хранением данных и программным обеспечением;
  * системной интеграцией, поддержкой, администрированием и др.
  Приведенный выше список является примерным, применимость схемы в том или ином случае оценивается отдельно. Виды деятельности, в которых разработка программного обеспечения отсутствует (например, розничная или оптовая продажа коробочного программного обеспечения), не могут быть сертифицированы согласно TickIT.
  Для того чтобы получить сертификат TickIT и использовать логотип TickIT, в организации или предприятии должна быть подготовлена и внедрена система управления качеством в соответствии с требованиями и рекомендациями схемы. Это потребует усилий как со стороны руководства предприятием, так и рядовых сотрудников. Система качества должна функционировать на предприятии в течение некоторого времени, прежде чем можно будет обратиться в сертификационное общество с целью проведения аудита и выдачи сертификата. Такой период адаптации необходим для того, чтобы система качества полностью интегрировалась в систему менеджмента предприятия и это можно было продемонстрировать в процессе аудита. Сертификационный аудит проводится в несколько этапов в соответствии со стандартной процедурой.
 
 Особенности управления качеством ИТ-услуг
 
  Если кредитная организация осознает необходимость улучшения качества предоставляемых ею ИТ-услуг и согласна с концепцией всеобщего управления качеством, целесообразно рассмотреть основные подходы к управлению качеством ИТ-услуг. Существуют два основных направления такой работы: управление качеством при разработке ИТ-услуг и управление качеством при предоставлении услуг пользователям.
  Этапы разработки новых услуг и управления их качеством были перечислены выше, однако стоит отметить, что кредитная организация не обязательно должна опираться на какие-либо стандарты в этой области. Концепция всеобщего управления качеством не подразумевает жесткого использования стандартов. Важно лишь помнить стратегическую задачу и цели проводимых работ по улучшению качества.
  Остановимся на управлении качеством в процессе предоставления услуг. Для этого рассмотрим некоторые рекомендации, которые необходимо учесть на начальном этапе данного процесса:
  - в большинстве случаев управление качеством услуги возможно только путем контроля процесса предоставления услуги. Категорически не рекомендуется полагаться только на контроль конечного результата;
  - для обеспечения требуемого уровня качества необходимо иметь детальные спецификации (описания) услуг и процесса их предоставления. Как показывает практика, большинство банков сегодня их не имеет или не контролирует соответствие процесса предоставления услуги утвержденному регламенту;
  - требуется разработать и внедрить систему, позволяющую своевременно получать информацию о качестве, конкурентоспособности и стоимости услуг. При этом необходимо учитывать возникающие при предоставлении услуги проблемы и пожелания пользователей по их преодолению. Необходимо также принимать во внимание мнение руководства, персонала и специальных служб (внутренний аудит, контроль, служба качества) организации;
  - оценить и выработать программу внедрения стратегических составляющих качества услуг (по TQM), таких, как обучение и повышение квалификации персонала, внедрение новой философии управления, вовлеченность персонала в процессы контроля и повышения качества услуг, создание позитивного имиджа банка;
  - выработать и внедрить систему материального стимулирования персонала за качественную работу, где существенная часть фонда заработной платы будет прямо соотносима с качеством выполнения работы исполнителем и качеством услуг банка в целом. При такой системе каждый сотрудник должен быть заинтересован не только в том, как он лично выполняет работу, но также в том, насколько качественно выполняют ее его коллеги, поскольку каждый из сотрудников должен нести частичную материальную ответственность и за ошибки других.
  После того как эти первостепенные мероприятия дадут свои результаты, можно приступать к дальнейшим шагам, например сертификации.
  С другой стороны, даже независимо от задачи сертификации приведение процедур управления качеством в соответствие с требованиями концепции всеобщего управления качеством и стандарта ISO 9000 существенно продвинет организацию и послужит залогом ее будущего развития.
  В заключение скажем, что, несмотря на то, что внедрение системы управления качеством в практику создает первоначально некоторые сложности, оно уже сегодня жизненно необходимо. Во избежание возникающих сложностей следует помнить, что внедрение системы качества требует определенных затрат времени, сил и средств, при этом не дает мгновенного экономического эффекта в сфере услуг в отличие от сферы производства программных продуктов, где оно окупается благодаря снижению издержек на исправление и переделки.
 
 Управление аутсорсингом
 
  Использование ресурсов сторонних организаций в процессе обеспечения собственной деятельности, или аутсорсинг (outsourcing), все более активно используется в процессе информатизации банковского дела. Это связано со многими процессами и в первую очередь с тенденцией повышения внимания со стороны менеджмента к ключевым, или профильным, направлениям деятельности организации. Поэтому все больше банков используют сторонние ресурсы, продукты, технологии в процессе автоматизации своей деятельности. В настоящей главе мы рассмотрим роль аутсорсинга в ИТ, обеспечение эффективного взаимодействия с внешними поставщиками и подрядчиками и основные риски в процессе управления аутсорсингом.
 
 Роль аутсорсинга в ИТ
 
  Использование сторонних подрядчиков и ресурсов может применяться в любом из направлений ИТ-деятельности. В западной практике в настоящее время популярность аутсорсинга настолько высока, что некоторые банки полностью передают функцию обеспечения информационными технологиями сторонним организациям. В ряде случаев такой подход, безусловно, имеет смысл, хотя, по нашему мнению, это все-таки неправильно, так как в современном банковском бизнесе информационные технологии выполняют не поддерживающую, второстепенную функцию, а имеют важнейшее значение, так как являются ключевым фактором для развития бизнеса, внедрения новых услуг и качественного обслуживания клиентов.
  Итак, полная передача ИТ-функции сторонним организациям для банков нецелесообразна. Какие функции и с какой целью можно передавать сторонним подрядчикам?
  Если говорить о целях, то, как правило, аутсорсинг используется:
  - для снижения издержек (сомнительно, что этот основной двигатель аутсорсинга на Западе будет работать в российских условиях, так как заработная плата ИТ-специалиста в России существенно отстает от рыночных почасовых ставок работы. Но тем не менее иногда с помощью сторонних ресурсов действительно возможно добиться снижения издержек. Например, если несколько банков договорились об совместном использовании какого-либо объекта, они могут минимизировать свои издержки, распределяя их между собой);
  - при необходимости резкого сокращения срока работ (зачастую работники ИТ могут самостоятельно выполнить какую-либо работу, но ввиду большого количества других обязанностей срок выполнения не соответствует требуемому. В таком случае привлечение дополнительных специалистов или полная передача работы сторонней организации может быть единственно правильным решением (например, прокладка сетей в новом здании);
  - в случае невозможности выполнить задачу силами своих сотрудников (естественно, что в этом случае у организации просто не остается выбора и она вынуждена искать сторонние ресурсы).
  Среди основных функций и задач в области ИТ, для которых может быть рекомендовано активное использование аутсорсинга, можно назвать:
  * разработку и внедрение больших информационных систем;
  * консалтинговые услуги (проведение тендеров, поиск партнеров, экспертные оценки, содействие в стратегии развития, подготовка регламентов, ИТ-аудит и т.п.);
  * обслуживание и ремонт компьютерной и серверной техники;
  * телекоммуникационные услуги;
  * поддержку локальных сетей;
  * обслуживание телефонного и офисного оборудования;
  * развитие информационной безопасности;
  * поддержку дорогостоящих с точки зрения ИТ бизнес-процессов (про-цессинг, выпуск пластиковых карт).
  Таким образом, аутсорсинг, все более распространяясь, увеличивает свое влияние на работу всей организации. При этом работа с внешними поставщиками содержит ряд особенностей и специфических рисков, которые требуют повышенного внимания и существенных усилий со стороны ИТ-менеджмента.
 
 Взаимодействие с внешними поставщиками
 
  Сотрудничество со сторонними организациями при реализации проектов может привести как к существенному сокращению расходов, так и к неоправданным затратам. На практике часто встречаются оба варианта. Задача руководителя проекта - сохранив положительный эффект от использования услуг сторонней организации, избежать скрытых расходов и, главное, не "сесть на иглу", то есть не попасть в ситуацию, когда услуги стороннего поставщика стали жизненно необходимы, а его замена крайне затруднительна. При этом услуги поставщика становятся все более обременительными с финансовой точки зрения.
  Избежать этого достаточно сложно, так как количество проектов в кредитной организации исчисляется единицами, а количество клиентов у вашего контрагента может исчисляться сотнями. Следовательно, опыт ведения дел у него во много раз превосходит опыт даже самого опытного сотрудника клиента.
  Вот некоторые из рекомендаций, которые помогут избежать или смягчить подобные проблемы.

<< Пред.           стр. 5 (из 20)           След. >>

Список литературы по разделу