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

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

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

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

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

Блин. Именно так, с большой буквы, с чувством и выражением, с желанием побиться головой. О стену, желательно - не гипроковую. Читаю пресс-релиз/рекламную листовку Некоторой Компании. И медленно ухожу в космос. Во-первых, оттого, что листовка в заголовке говорит об одном, в первом абзаце - о другом, а дальше напоминает известное разводилово - "хотите фен бесплатно? Купите 2 утюга и один порошок для ловли блох". Во-вторых, листовка, отправленная адресно техническому специалисту (да, несмотря на мою любовь к бизнесориентированности ИТ, я - технарь: не стоит об этом забывать) не содержит ровным счетом ничего. Ноль полезной информации. В третьих, она написана на 4 листах А4 довольно мелким шрифтом (один лист А3, напечатанный с 2 сторон и сложенный пополам). Вернее, на 3,5 - т.к. половину листа занимает тот самый заголовок. Текст рассчитан на домохозяек. Причем, даже скорее на (простите, милые дамы) - пародию на домохозяек. На лиц с ограниченным интеллектом... Детские книжки, которые рассчитаны на детей 2..3 лет, гораздо информативнее в плане формирования мировоззрения и донесения информации.

Вопрос. Вернее - несколько. Все риторические.

* неужели PR служба Некоторой Компании не в состоянии договориться хотя бы с продавцами, не говоря о ИТшниках о написании здравого текста?

* неужели в PR службу набирают людей, не способных отличить белого от черного в целом, и к организации эффективных коммуникаций в частности?

* неужели на ЭТИ листовки кто-то ведется?

* если на ЭТО никто не ведется, то как отбиваются затраты на изготовление листовок?

* неужели ЭТО не проходило утверждения перед отправкой в типографию и заказчикам?

К счастью, утешает то, что такого рода материалы все-таки встречаются нечасто. Но, блин, встречаются!

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

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

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

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

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

Получается: "не внедряйте, да не внедряемы будете":)

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

Любопытно, кто и как оценивает эффективность внедрения той или иной информационной системы?

Я, например, стараюсь подобрать KPI, которые в максимальной степени связаны с областью, в которой происходит автоматизация. Например, при внедрении Service Desk такими критериями будут являться время разрешения инцидента (оно, по идее, должно уменьшится) и количество претензий пользователей (оно, по идее, тоже должно уменьшится). В случае системы управления поручениями - количество совещаний, и т.д.

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

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

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

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

Ответы на наиболее часто задаваемые вопросы о том, как внедрять управление ИТ-услугами на основе рекомендаций ITIL

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

Прежде всего определимся с часто упоминаемыми терминами, вызывающими путаницу. Управление ИТ-услугами (Information Technology Service Management, ITSM) – это сервисный процессный подход к организации работы ИТ-службы. Суть его в том, что вся деятельность ИТ-подразделения рассматривается в разрезе услуг, оказываемых им другим подразделениям в соответствии с соглашениями об уровне услуг. ITSM декларирует, что ИТ-отделом можно управлять, основываясь на тех же принципах, которые применимы к бизнес-подразделениям.

Библиотека ИТ-инфраструктуры (Information Techno-logy Infrastructure Library, ITIL) – это библиотека рекомендаций, обобщающая международный опыт по организации работы ИТ-департаментов и разъясняющая, что надо сделать для реализации подхода ITSM. ITIIL состоит из ряда книг, каждая из которых описывает тот или иной аспект деятельности в виде набора процессов. В настоящее время выпущена вторая версия ITIL, активно ведется работа над созданием третьей. В ITIL описывается, как должна быть организована деятельность ИТ-структур, но не приводятся конкретные шаги по внедрению содержащихся в ITIL рекомендаций. Конкретные методики внедрения ITSM на основе ITIL предлагают компании, которые специализируются на подобных проектах.

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

Сотрудникам же бизнес-подразделений следует объяснить, что внедрение рекомендаций ITIL обеспечит им более качественное обслуживание, сокращение времени возможных простоев и перебоев, а также быстрое рассмотрение и реакцию на все без исключения обращения в ИТ-службу. У них появится уверенность в том, что каждое обращение будет отработано по принятым правилам в установленный срок.

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

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

Увеличение эффективности и направление фокуса ИТ-деятельности на решение задач бизнеса.

Внедрение даже ограниченного набора процессов ITIL (службы Service Desk и процессов управления инцидентами и уровнем услуг) позволит организовать работу ИТ-службы таким образом, что в центре ее внимания окажется именно бизнес. ИТ-отдел из «вещи в себе» превратится в ориентированную на потребности бизнеса внутреннюю сервисную структуру.

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

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

Следует ли затраты на ИТ распределять по бизнес-подразделениям и бизнес-пользователям?

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

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

С чего начать внедрение? Какие процессы внедрять?

Проект по внедрению рекомендаций ITIL, как и любой другой, связанный с управлением, следует начать с определения бизнес-требований и анализа состояния дел ИТ-департамента. Для анализа можно применять известные методики (например, Pink Elephant, HP ITSM) или самостоятельно составленные опросные листы. Как правило, дополнительно проводится анализ по бизнес-модели: делается описание того, как работает ИТ-отдел в данный момент, в виде связанной совокупности бизнес-процессов. Следует отметить, что такой анализ полезен даже в случае полной деструктурированности работы ИТ, поскольку помогает выявить внутренние зависимости и связи, опираясь на которые, можно будет спроектировать тот или иной процесс.

Одновременно с построением картины работы «как есть» проводится анализ бизнес-требований к ИТ-отделу на основе сбора и обобщения требований и ожиданий бизнеса от ИТ и возможностей ИТ-службы удовлетворить потребности бизнес-подразделений.

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

Как установить соответствие между услугами, которые бизнес желает (или ожидает) получить от ИТ-подразделения, и ИТ-услугами?

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

Какие фазы внедрения ITSM существуют? Что влияет на его успешное завершение?

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

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

Обязательно ли организовывать Service Desk?

Внедрение службы Service Desk целесообразно по нескольким причинам. Большинство современных средств автоматизации предусматривает возможность регистрации инцидентов самим пользователем (посредством Web-форм, например). Однако пользователь порой не в состоянии квалифицированно определить суть инцидента. Но даже если он может провести самостоятельную классификацию, все равно требуется уточнение (или, как минимум, подтверждение) специалиста. Автоматизированный ввод инцидентов самим пользователем не отменяет механизма ввода и диспетчеризации оператором Service Desk, поскольку в ряде случаев пользователь просто не имеет возможности завести заявку (инцидент) для автоматической обработки (например, при отсутствии технической возможности доступа к интерфейсу Service Desk).

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

При отказе от Service Desk более вероятно возникновение «очередей» заявок у высококвалифицированных ИТ-специалистов, которые будут совершенно неэффективно тратить свои ресурсы. Запуск же квалифицированной службы Service Desk позволяет спустя некоторое время разрешать до 70% заявок на первой линии благодаря накоплению базы знаний и другим преимуществам правильно организованных процессов. Это экономит время высокооплачиваемых специалистов, и они могут направить его для решения более важных задач. Оставшиеся 30% заявок маршрутизируются таким образом, что гарантируется их скорейшее решение.

При отсутствии службы Service Desk ее функции выполняет вся ИТ-служба.

Как оценить численность сотрудников Service Desk?

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

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

Нельзя ли обойтись при внедрении рекомендаций ITIL без автоматизированной системы?

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

Если в компании уже есть система учета заявок, обязательно ли внедрять специализированный продукт для управления ИТ?

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

Может ли ITSM помочь при внедрении ERP (CRM и т.д.)?

Если в организации внедрен один или несколько процессов в соответствии с рекомендациями ITIL, безусловно, может. Служба Service Desk возьмет на себя ответы на запросы пользователей и регистрацию инцидентов, связанных с новой системой. Эти инциденты будут разрешаться в рамках процесса управления инцидентами, анализироваться и использоваться для выявления проблем в рамках процесса управления проблемами. Разрешение инцидентов будет происходить путем проведения изменений в рамках процесса управления изменениями, а информация о конфигурации инфраструктуры будет постоянно актуальной вследствие работы процесса управления конфигурациями. Расчет мощностей, требуемых для внедрения новой системы, будет проведен в рамках процесса управления мощностями, в рамках процесса управления доступностью будут сформированы требования, удовлетворение которых обеспечит требуемый уровень доступности. В рамках процесса управления непрерывностью будет сформирован план обеспечения непрерывности для ERP-системы, финансы на приобретение требуемых серверов и поддержку программно-аппаратного комплекса формируются в рамках процесса управления финансами, мероприятия по обеспечению безопасности конфиденциальных данных в ERP будут обеспечены в рамках процесса управления безопасностью. Далее, имея организованную в соответствии с определенными регламентами службу ИТ, легче проводить планирование внедрения, поскольку при четкой организации деятельности ИТ повышается прозрачность и управляемость ИТ.

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

Чем ITSM может помочь при организации аутсорсинга?

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

Обязательно ли использовать консалтинг при внедрении ITSM?

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

Что будет, когда закончится проект?

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

Размещено: Директор ИС, №03/2007

Распространенная задача, решать которую приходится практически во всех ИТ отделах, пытающихся применить принципы сервисного управления – построение, развитие и управление каталогом сервисов. Задача эта на первый взгляд достаточно тривиальная, однако и при ее решении существуют определенные «подводные камни».

Например, при решении задачи «в лоб», каталог сервисов часто заменяют на перечень эксплуатируемых ИТ систем и базового ПО. Подобный подход имеет ярко выраженный недостаток: при инвентаризации в средней компании (то есть, с числом АРМ порядка 500) может быть обнаружено порядка 100..300 систем и приложений, которые могут быть классифицированы как сервис. Таким образом, пользователь, обращаясь в ИТ для решения каких-либо вопросов, вынужден формулировать свой запрос «на языке ИТ», что принципиально противоречит рекомендациям ITIL. Другая крайность – чересчур широкое определение сервиса. Например, сервис «рабочее место пользователя» может включать в себя ПК, базовое ПО, специфическое ПО и периферийные устройства, что приближает количество инцидентов, связанных с данным сервисом, к 100% от общего числа зарегистрированных инцидентов.

Классическое определение понятия «сервис» гласит, что «сервис – есть процесс обслуживания объектов». Библиотека ITIL рекомендует определять сервис как информационную услугу, то есть ту услугу, которую отдел ИТ предоставляет пользователям. При этом в качестве пользователей могут выступать как сотрудники профильных для бизнеса подразделений, так и внешние заказчики (в этом случае вводится специальное понятие – аутсорсинг). По сути, такая трактовка означает, что отдел ИТ является обслуживающей организацией по отношению к пользователям.

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

Таким образом, примерный алгоритм построения каталога сервисов будет следующим:

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

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

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

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

Управление каталогом сервисов включает в себя:

• Мониторинг текущего каталога сервисов
• Выявление новых сервисов
• Выявление новых территорий, требующих разворачивания тех или иных ИТ сервисов
• Выявление утративших актуальность сервисов
• Актуализация каталога сервисов

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

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

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

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

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

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

• Угрозы нарушения доступности
• Угрозы нарушения целостности
• Угрозы нарушения конфиденциальности

Угрозы нарушения доступности – это угрозы, связанные с увеличением времени получения той или иной информации или информационной услуги. Нарушение доступности представляет собой создание таких условий, при которых доступ к услуге или информации будет либо заблокирован, либо возможен за время, которое не обеспечит выполнение тех или иных бизнес-целей. Рассмотрим пример: в случае выхода из строя сервера, на котором расположена требуемая для принятия стратегического решения информация, нарушается свойство доступности информации. Аналогичный пример: в случае изоляции по какой-либо причине (выход из строя сервера, отказ каналов связи и т.д.) почтового сервера можно говорить о нарушении доступности ИТ услуги «электронная почта». Особо следует отметить тот факт, что причина нарушения доступности информации или информационной услуги не обязательно должна находиться в зоне ответственности владельца услуги или информации. Например, в рассмотренном выше примере с нарушением доступности почтового сервера причина (отказ каналов связи) может лежать вне зоны ответственности администраторов сервера (например, отказ магистральных каналов связи). Также следует отметить, что понятие «доступность» субъективно в каждый момент времени для каждого из субъектов, потребляющих услугу или информацию в данный момент времени. В частности, нарушение доступности почтового сервера для одного сотрудника может означать срыв индивидуальных планов и потерю контракта, а для другого сотрудника той же организации – невозможность получить выпуск свежих новостей.

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

Угрозы нарушения конфиденциальности – это угрозы, связанные с доступом к информации вне привилегий доступа, имеющегося для данного конкретного субъекта. Подобные угрозы могут возникать вследствие «человеческого фактора» (например, случайное делегировании тому или иному пользователю привилегий другого пользователя), сбоев работе программных и аппаратных средств.

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

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

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

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

Уровень защиты от логического доступа к данным предполагает защиту от несанкционированного доступа в систему (здесь и далее по тексту под системой понимается ИТ система, предназначенная для порождения, хранения и обработки данных любого класса – от простых учетных систем до решений класса ERP) как на уровне баз данных, так и на уровне ядра системы и пользовательских форм. Защита на этом уровне предполагает принятие мер по предотвращению доступа к базе данных как из Интернет, так и из локальной сети организации (на последний аспект обеспечения безопасности традиционно обращается мало внимания, хотя этот аспект напрямую связан с таким явлением, как промышленный шпионаж). Защита ядра системы предполагает, наряду с обозначенными выше мерами, вычисление контрольных сумм критических частей исполнимого кода и периодический аудит этих контрольных сумм. Подобный подход позволяет повысить общую степень защищенности системы. (Следует отметить, что указанное мероприятие не является единственным; оно приводится как удачный пример). Обеспечение безопасности на уровне пользовательских форм декларирует обязательное шифрование трафика, передающегося по локальной сети (или через Интернет) между клиентом (пользовательской формой) и приложением (ядром системы). Также безопасность на этом уровне может обеспечиваться вычислением контрольных сумм этих форм, с последующей их проверкой, принятием идеологии «разделения данных и кода». Например, система, построенная по технологии «тонкого клиента» с позиций обеспечения безопасности на данном уровне имеет преимущество перед системой, построенной по технологии «толстого клиента», поскольку на уровне пользовательских форм не предоставляет доступа к коду бизнес-логики (например, путем дизассемблирования исполняемого файла). К этому же уровню защиты относится механизм сертификации, когда в обмене между пользовательской формой и сервером, а также подлинность самой пользовательской формы подтверждается третьим участником обмена – центром сертификации.

Аналогично, на уровне защиты от логического доступа на уровне баз данных доступа целесообразно вычислять контрольные суммы критически важных таблиц, и вести журнал учета доступа объектов к базе данных. В идеальном случае («тонкий клиент») доступ к базе данных имеет лишь серверное приложение (сервер бизнес-логики), а все остальные (сторонние) запросы к БД блокируются. Подобный подход позволит исключить несколько типов атак и сконцентрировать политику защиты БД на обеспечении безопасности «по критическим точкам».

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

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

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

Довольно часто, в критически важных приложениях, форма ввода имени пользователя/пароля представляет собой работающее в защищенном программном (реже – аппаратном) тоннеле приложение, безусловно шифрующее всю передающуюся по сети информацию. К сожалению, наиболее частой является ситуация, когда имя пользователя и пароль передаются по сети в открытом виде (например, по этому принципу работают большинство известных бесплатных почтовых систем в сети Интернет). Кроме программных (ввод комбинации имя пользователя/пароль) существуют и программно-аппаратные и аппаратные решения для аутентификации пользователей. К ним относятся дискеты и USB-носители с ключевым файлом (довольно часто – в комбинации с вводом обычного имени/пароля, для подтверждения полномочий на критичные действия), защищенным от копирования; однократно записываемые USB-носители с ключевым файлом; сканеры радужной оболочки глаза; сканеры отпечатков пальцев; системы антропологии. Одним из вариантов повышения степени защиты ИС является ограничение времени действия пароля и ограничение времени бездействия пользователя в ИС. Ограничение времени действия пароля представляет собой выдачу пароля, который действует лишь определенное число дней – 30, 60 и т.д. Соответственно, с периодической сменой паролей повышается степень защищенности ИС в целом. Ограничение времени бездействия пользователя предполагает автоматическое закрытия сеанса пользователя в случае, если в этом сеансе не была зафиксирована пользовательская активность в течении определенного периода времени.

Протоколирование всех событий, происходящих в ИС, необходимо для получения четкой картины о попытках несанкционированного доступа, либо по неквалифицированным действиям персонала по отношению к ИС. Частой ситуацией является введение в ИС специализированных модулей, анализирующих системные события, и предотвращающих деструктивные действия по отношению к ИС. Подобные модули могут работать, исходя из двух предпосылок: обнаружения вторжений и предотвращение превышения доступности. В первом случае модули статистически анализируют типичное поведение пользователя, и выдают «тревогу» в случае заметных отклонений (например, работа оператора в 22-30 первый раз за два года является безусловно подозрительной); во втором случае на основе анализа текущего сеанса работы пользователя пытаются предотвратить потенциально деструктивные действия (например, попытку удаления какой-либо информации).

Примечание:

ИБ – информационная безопасность

ИТ – информационные технологии

ИС – информационные системы или информационная система (по контексту)