Управление ИТ и тп. Современные технологии делопроизводства и документооборота

• Название: Современные технологии делопроизводства и документооборота
• Дата: 09.07.2019
• Размер: 1 Mb.
• Имя файла: Управление ИТ и тп.doc
• Тип: Руководство; #83860
• страница: 11 из 13

ЗА И ПРОТИВ

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

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

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

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

Элементы SLA

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

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

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

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

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

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

Невыполнение. SLA также определяет невыполнение, т. е. что следует делать, когда индикаторы показывают недостижение должного уровня сервиса. Однако здесь немаловажное значение имеет степень отклонения. Например, требование, что время отклика для всех транзакций не должно превышать 2 с, менее реалистично, чем требование, что, скажем, время отклика не должно превышать 2 с для 95% транзакций, а для оставшихся 5% оно должно находиться в пределах от 2 до 5 с.

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

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

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

Особые условия. Если необходимо, в SLA следует предусмотреть особые условия с учетом сферы деятельности компании.

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

Уточнение. Технические новшества могут привести к необходимости уточнения SLA или переопределения обязательств. Например, при установке нового оборудования требования клиента в отношении производительности могут вырасти.

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

Некоторые инструменты для мониторинга

NetCare Vital Suite 7.0 компании Lucent Technologies. С помощью этого продукта провайдеры услуг могут предоставить заказчикам конкретные отчеты и продемонстрировать выполнение ими соглашений об уровне сервиса (Service Level Agreement, SLA). Со своей стороны заказчики могут использовать его для проверки провайдеров. VitualSuite способен осуществлять непрерывный мониторинг функционирования сетей и приложений как с точки зрения конечного пользователя, так и в отношении параметров работы внутренних механизмов.

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

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

Remedy. Продукт Service Level Agreements 4.0 от Remedy в действительности является частью комплекта Remedy. Совместно с Remedy Help Desk он представляет собой инструмент для проверки внутренних SLA. Пользователи получают единый вид всего комплекта, со специальными консолями для конечных пользователей, технического персонала и руководителей.

Мониторинг конкретных разновидностей сетей

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

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

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

Мониторинг frame relay, ISDN, выделенных линий или глобальных сетей на базе IP позволяет осуществлять множество продуктов. Однако чем выше скорости, тем ограниченнее выбор, и лишь немногие производители поддерживают соединения быстрее T-1/E-1. Это порождает очевидные трудности при мониторинге сети ATM, так как она вполне может работать на скорости 155 Мбит/с. Продукты для мониторинга ATM обычно представляют собой исключительно программные решения для сбора данных из генерируемых коммутаторами ATM журнальных файлов.

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

Управление в малых ИТ-подразделениях.

Н.Крачун

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

Чем управляем?

"Персоналу шесть душ, локалка на две сотни рабочих мест плюс серверов с десяток, телефония, Интернет-канал...".

Наверное, такое понимание сферы своей деятельности и объектов управления присуще большинству ИТ-менеджеров, имеющих в подчинении от двух до десятка работников и отвечающих "за все, что с проводами, кроме кофеварки". Обычно такое описание сферы ответственности устраивает и их руководство - коротко и ясно. Гораздо труднее получить ответ на простой вопрос - "зачем?". Формулировка отдела ИТ обычно столь же проста сколь и бессодержательна: "Чтоб все работало и юзеры не жаловались." Руководство со своей стороны далеко не всегда понимает не только чем заняты все эти "компьютерщики", но и что компании дают сервера, Интернет - вообще все это компьютерное хозяйство кроме разве что ноутбука самого директора. Из-за этого не только затруднено нормальное взаимопонимание между ИТ и руководством компании (например, обсуждение затрат на ИТ упирается в тот же вопрос - "зачем?" - а объяснять директору преимущества клиент-серверной модели занятие зачастую неблагодарное), но и фактическая польза для бизнеса от затрат и усилий ИТ-подразделения неизмеряема, неуправляема и, как следствие, низка.

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

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

Нужна ли теория?

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

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

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

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

Какие цели и как измерять результат?

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

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

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

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

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

Я уже попытался дать ответ на вторую часть вопроса: "Что за теория такая - ITIL - и зачем она нужна?".
Если от многократно повторенных слов вроде "услуга", "процесс", "качество" еще не уснули, а интерес к тому, каково же оно "в деле", поввился, обсудим сперва:

Что же все-таки такое этот ИТИЛ?

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

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

Официальный автор - британская правительственная организация OGC (Office of Government Commerce), изначальной задачей которой было помочь гос. структурам в формализации их отношений с подрядчиками - поставщиками ИТ-услуг. В Великобритании даже действует официальный стандарт на Управление Услугами (BS 15000), который базируется на ITIL. Хотя формальное авторство принадлежит OGC, в написании участвуют представители и организаций-заказчиков, и поставщиков, и консультантов. В книгах описываются группы процессов (например, Поддержка Услуг - Service Support), объединенные по принципу нахождения на шкале "Технология - Услуги". Ключевыми считаются две группы - Поддержка и Доставка (Delivery) Услуг.

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

Как это реализуется на практике?

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

Начинать (что вполне естественно) надо с чтения книг Библиотеки. К сожалению, на данный момент переводов на русский нет, а за оригинальные книги придется выложить около 150 долларов за штуку. Альтернативой (во всяком случае, на первом этапе) может быть покупка за 38 долларов "Введения в ITIL" (IT service management - An introduction) издания itSMF (Форума по Управлению Услугами ИТ, объединяющего теоретиков и практиков ITIL). Кстати, уже идут работы по переводу этой книжки на русский. При наличии хотя бы небольшого бюджета также очень желательно сходить на 2-3дневные курсы по основам ITIL - книжки книжками, а общение с практиками дорогого стоит. И конечно очень многое можно почерпнуть в Чети - полная картина при только ее использовании вряд ли сложится, но полезностей можно найти немало.

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

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

Если о наличии бэкапов голова уже не болит, а сбой ПК стал явлением редким - настала пора ИТ-отделу выстраивать взаимоотношения с "внешним миром". И в превую очередь с теми, без кого его функционирование невозможно - с внутреними и сторонними поставщиками внешних для ИТ услуг. Во многих реализациях ITIL Управление Окружением (Environmenal Management) считается фундаментом функционирования всей информационной системы. Действительно электрика, вентилвция, кондиционирование, обычно не входвщие в сферу ответственности ИТ-отдела, влияют на его работу принципиально. Поэтому пока нет спокойствия и уверенности в этих вопросах - двигаться дальше опасно.

Когда решена и эта задача, можно наконец переходить к реализации первой функции из ITIL-овского блока Поддержки Услуг - создать в отделе Центр Обслуживания. Это еще не реализация какого-то процесса (в Service Support описаны пять процессов и одна функция - function - Service Desk), но в поддержке услуг - один из ключевых элементов. Центр Обслуживания (иногда его называют Help Desk) должен стать единой точкой контакта отдела с "внешним миром". Таким образом решаются две задачи. Во-первых, это упростит жизнь пользователям - всегда будет к кому обратиться и человек "на телефоне" не сошлется на то, что ему "не до мелочей". Во-вторых, появлвется возможность фиксировать, документировать и измерять поток работ, выполняемый отделом ИТ. Этим будет сделан первый шаг во внедрении блока процессов Поддержки Услуг.