Объектная модель Microsoft Outlook реализована в виде набора объектов, собранных в библиотеке Outlook.
Объекты приложения Outlook
В табл. 21.3 приведено описание основных объектов из объектной модели Outlook.
| Объект | Тип | Описание |
| Application | Обьект | Ссылается на активное приложение Microsoft Outlook. Используется для управления приложением |
| NameSpace | Объект | Объект представляет собой абстрактный корневой объект для любого источника данных |
| AddressLists (AddressLists) | Семейство и объект | Семейство объектов, представляющих адресные книги |
| Folders (MAPIFolders) | Семейство и объект | Семейство MAPIFolders объектов, которое представляет любую из доступных папок в их подмножестве на одном уровне дерева папок |
| Items (Item) | Объект MAPIFolder | |
| Links (Link) | Объект Item | Представляет объект item, который связан с другим объектом item |
| User Proper ties (UserProperty) | Объект Item | Данное семейство хранит информацию о нестандартных свойствах элемента Outlook, созданных пользователем |
| FormDescription | Объект Item | Этот объект хранит все стандартные свойства элемента Outlook |
| Actions (Action) | Объект Item | В этом семействе хранится информация об ассоциированных с данным элементом Outlook командах. Обратите внимание на то, что команды можно вывести, раскрыв в режиме конструктора вкладку Команды |
| Attachments (Attachment) | Объект Item | Семейство представляет все вложения в элементе |
| Recepients (Recepint) | Объект Item | Это семейство представляет информацию о получателях элемента Outlook |
| ReccurencePattern | Объект Item | Данный объект задает шаблон повторения для встреч и задач |
| Proper ty Pages (Proper tyPage) | Семейство и объект | Семейство объектов PropertyPage, которые содержат специальные вкладки со свойствами, добавленные к диалоговому окну Параметры в Outlook |
| LanguageSet tings | Объект | Предоставляет информацию о языковых настройках приложения |
| AnswerWizard | Объект | Соответствует мастеру ответов Microsoft Office. Все приложения Microsoft Office имеют ровно один мастер ответов, поэтому все изменения этого объекта отразятся на активном приложении |
| Assistant | Объект | Ссылается на объект, представляющий активного в данный момент Помощника Office |
| Search | Объект | Данный объект представляет как простой поиск, так и расширенный поиск |
| Reminders (Reminder) | Семейство и объект | Представляет окно Оповещения для всех напоминаний о встречах, задачах и т. д. |
| Explorers (Explorer) | Семейство и объект | Семейство объектов Explorer - набор всех окон, в которых отображается содержимое папки |
| Selection (Items) | Объект Explorer | Семейство всех отображаемых элементов в окне просмотра информации |
| CommandBars (CommandBar) | Объект Explorer | Представляет обычные и контекстные меню, а также панели инструментов объекта |
| Panes (Pane) | Объект Explorer | Семейство панелей (окон) Outlook для данного объекта Explorer |
| Inspectors (Inspector) | Семейство и объект | Семейство объектов Inspector - набор всех окон, в которых "отображаются элемен- ты Outlook. Элемент (item) - это основной модуль хранения данных в Outlook (подобно файлу в других программах). В число эле- ментов входят почтовые сообщения, встречи, контакты, задачи и т. д. (рис. 21.4) |
| WordEditor и HTMLEditor | Объекты | Представляют объекты, посредством которых выбираются редакторы для объекта Inspector |
| Pages (Page) | Объект Inspector | Каждый объект inspector связан со своим семейством Pages, в которое входят все обновленные пользователем страницы формы. Если в форму для элемента не вносились изменения, то семейство Pages является пустым |
| Item | Объект Inspector | Представляет стандартный элемент Outlook, расположенный в данной папке |
| MAPIFolder | Объект | Представляет папку Outlook |
Таблица 21.3. Основные объекты Outlook
В табл. 21.4-21.6 представлено описание основных свойств, методов и событий объекта Application.
Рис. 21.1.
Таблица 21.4. Основные свойства объекта Application
Таблица 21.5. Основные методы объекта Application
| Событие | Описание |
| AdvancedSearchComplete | Происходит, когда Расширенный поиск заканчивает свою работу |
| ItemSend | Происходит, когда элемент посылается либо посредством Inspector, либо посредством метода Send |
| MapiLogonComplete | Происходит, когда пользователь входит в систему |
| NewMail | Происходит, когда одно или несколько почтовых сообщений приходит в папку Входящие |
| OptionPagesAdd | Происходит, когда открывается диалоговое окно Параметры |
| Reminder | Происходит непосредственно перед оповещением о встрече, задаче или собрании |
| Startup | Происходит сразу после загрузки приложения Outlook |
| Quit | Происходит, когда Outlook закрывается |
Таблица 21.6. События объекта Application
Объекты MAPIFolderv и Mailltem
Поскольку в примерах этой главы и следующей используются свойства и методы объектов MAPIFolder и Mailltem, мы сочли необходимым привести их краткое описание.
Объект MAPiFoider, как было сказано выше, представляет папку Outlook. Объект MAPiFoider может содержать другие MApiFoider-объекты. В этом случае вы можете управлять доступом к вложенным папкам посредством комбинации Folder (индекс), где индекс возвращает объект MAPiFoider.
Outlook имеет специальный набор папок, которые поддерживают заданную по умолчанию функциональность Outlook. Для доступа к этим папкам следует Использовать метод GetDefaultFolder(индекс), где индекс - одна ИЗ констант olDefauitFoiders, например olFoiderinbox возвращает папку Входящие.
В табл. 21.7 приведены основные свойства объекта MAPiFoider, а в табл. 21.8 - его методы.
Таблица 21.7. Свойства объекта MAPiFolder
Таблица 21.8. Методы объекта MAPiFolder
Несколько слов об объекте Mailitem. Он представляет почтовое сообщение в папке Входящие (Inbox). Мы рассмотрим только необходимые для примера свойства и методы этого-объекта.
Свойство Messageciass возвращает или устанавливает класс сообщения для элемента Outlook. Свойство Messageciass связывает элемент с формой, на которой он основан. Когда элемент выбран, Outlook использует класс сообщения, чтобы поместить соответствующую форму и установить свойства элемента.
Свойство RecievedTime возвращает дату и время получения сообщения. Метод Display отображает новый объект inspector для выбранного элемента.
В программе 21.3 открываются все почтовые сообщения, поступившие за последние сутки.
Программа 21.3. Открытие почтовых сообщений
Sub openLastMail () Dim oa As Outlook.Application
Dim ns As NameSpace ; Dim fl As MAPiFolder Dim ob As Object Dim it As Mailitem
Dim i As integer
Set oa = CreateObject("OutLook.Application") Set ns = oa.GetNamespace("MAPI") Set fl = ns.GetDefaultFolder(olFolderlnbox) For i = 1 To f1.Items.Count Set ob = fl.Items(i) On Error GoTo nextitem If ob.MessageClass = "IPM.Note" Then Set it = ob If it.ReceivedTime > Date - 1 Then
it.Display (False) End If End If nextitem:
Замечание
Для семейств Outlook нельзя воспользоваться оператором For Each Next, поэтому применяется цикл For . . . Count.
13.2. Некоторые особенности программирования в Outlook
Программирование в Outlook имеет ряд интересных особенностей, о которых необходимо упомянуть.
Первая особенность заключается в том, где именно хранятся программные модули Outlook, в которых мы создаем код. Как мы помним, в Word они хранятся вместе с документами (или шаблонами, например, Normal.dot), в Excel - в файлах рабочих книг, в Access - в файлах баз данных MDB.
В Outlook информация стандартных модулей хранится в файле личных папок PST, который по умолчанию создается в профиле данного пользователя.
В результате, с одной стороны, работа с программным кодом VBA в Outlook упрощается: для данного пользователя на этом компьютере он становится доступен из Outlook всегда. С другой стороны, становится труднее предоставить этот код в распоряжение другого пользователя. В этой ситуации можно использовать два выхода:
первый выход - воспользоваться средствами экспорта и импорта про-
граммных модулей , которые доступны из контекстного меню для модуля в
Project Explorer (рис. 13.2);
Рис. 13.2. Средства импорта и экспорта программного кода
второй выход - создать контейнерное приложение , например, файл
Word или книгу Outlook, из которого программным образом запускать Outlook и выполнять в нем необходимые действия.
Вторая особенность работы с VBA в Outlook заключается в том, что в Outlook реализована концепция пространства имен. Пространство имен в Outlook формально определяется как абстрактный корневой объект для любого источника данных (например, папки в почтовом ящике Exchange или PSTфайле на диске). Проще всего представить себе пространство имен Outlook как некий драйвер, который нужно использовать для подключения к данным. В настоящее время Outlook поддерживает только одно пространство имен -
MAPI (Messaging Application Programming Interface, интерфейс прикладного программирования для работы с сообщениями), но разработчики Outlook требуют, чтобы это пространство имен явно указывалось при выполнении самых разных операций. Подробнее про объект Namespace , представляющий пространство имен, будет рассказано вразд. 13.4 . Например, для запуска Outlook и открытия в нем папкиInbox (Входящие) из другой программы придется использовать следующий код (не забудьте подключить ссылку на библиотеку Microsoft Outlook 11.0 Object Library):
Set oNameSpace = oOutlook.GetNamespace("MAPI")
Set oInbox = oNameSpace.GetDefaultFolder(olFolderInbox) oInbox.Display
Третья особенность работы с Outlook заключается в некоторой терминологической путанице. Как правило, в документации по объектным моделям приложений Office термин Item (элемент) применяется к элементам коллекций. В Outlook он получает второе значение:Item - это все, что может храниться в папках Outlook: почтовые сообщения (объектMailItem ), контакты (объектContactItem ), встречи (объектAppointment ) и т. п. Не путайте!
У Outlook есть еще одна особенность. На протяжении многих лет Outlook была программой, которая первой подвергалась атакам вирусов, троянских программ и прочего вредоносного программного обеспечения, приходящего по электронной почте. Иногда такие атаки бывали успешными, и Outlook на компьютере пользователя сам начинал рассылать электронные письма с вирусами (в том числе и при помощи кода VBA). Чтобы снизить вероятность развития событий по такому сценарию, разработчики Outlook сознательно поместили в его объектную модель ограничения, которые должны препятствовать распространению вирусов. Иногда эти ограничения (у них есть специальное название - Outlook Object Model Guard ) мешают и нормальной работе программ VBA. О них будет рассказано в следующих разделах. Иногда по причине таких ограничений бывает удобнее использовать вместо объектной
Программирование в Outlook |
модели Outlook библиотеку CDO, которая имеется на любом компьютере с
Windows 2000, XP или 2003.
Интересной особенностью Outlook является и то, что в отличие от других приложений Office вы не сможете напрямую (при помощи ключевого слова New или командыCreateObject() ) создать ни одного объекта Outlook, кромеApplication . Для создания всех остальных объектов придется использовать соответствующие методы уже созданных объектов.
На всякий случай также заметим, что макрорекордера в Outlook, как и в Access, к сожалению, нет. Всю необходимую дополнительную информацию вам придется искать при помощи документации.
13.3. Объект Application ,
его свойства и методы
Как и у всех приложений Office, на вершине объектной модели Outlook находится объект Application . Его можно использовать для запуска Outlook из внешних приложений (см. пример в предыдущем разделе). Отличительной особенностью объектаApplication в Outlook является относительно небольшое количество свойств и методов (за счет того, что часть из них переехала в объектNamespace ). Наиболее часто используемые свойства объектаApplication представлены далее.
Explorers - это свойство возвращает коллекциюExplorers с объектамиExplorer , каждый из которых представляет собой папку Outlook, открытую на просмотр пользователем. Основное назначение этой коллекции и объектовExplorer - проверка, не открыта ли уже пользователем в Outlook та или иная папка, и, в зависимости от результата, активизация этого окна
(Explorer.Activate()) или его закрытие (Explorer.Close()). Метод
ActiveExplorer() объектаApplication позволяет получить ссылку на окно, активное в настоящий момент, аGetExplorer() - получить ссылку на объектExplorer для указанной папки Outlook (без его автоматической активизации).
Inspectors - свойство, которое очень похоже наExplorers . Оно возвращает коллекциюInspectors с объектамиInspector . Главное отличие в том, что объектыInspector представляют не открытые папки Outlook, какExplorer , а открытые на просмотр и редактирование элементы (например, почтовые сообщения). ОбъектInspector используется для таких же проверок, что и объектExplorer , его свойства и методы почти полностью совпадают со свойствами и методами объектаExplorer . Для тех же целей преду-
смотрены и методы ActiveInspector()и GetInspector()объекта Application.
Reminders - позволяет вернуть коллекциюReminders с объектамиReminder , представляющими текущие оповещения. Обычно это свойство используется для того, чтобы программным образом отключить все оповещения:
Dim oOutlook As New Outlook.Application
Dim oReminder As Outlook.Reminder
For Each oReminder In oOutlook.Reminders
oReminder.Dismiss
Session - это свойство позволяет вернуть объектNamespace , представляющий пространство имен для текущего сеанса (т. е. пространство имен MAPI). Это свойство можно использовать вместо методаGetNamespace() . Подробнее про объектNamespace будет рассказано вразд. 13.4 .
Аналогичное свойство Session предусмотрено для самого объектаNamespace и для множества других объектов Outlook.
Теперь расскажем о методах объекта Outlook.Application .
Методы с префиксом Active... - просто возвращают ссылку на активный в настоящее время объектExplorer илиInspector .
AdvancedSearch() - очень важный метод. Он позволяет производить поиск по папкам Outlook (что на практике требуется достаточно часто). Подробнее про этот метод и сопутствующие ему объектыSearch иResults будет рассказано вразд. 13.7 .
CopyFile() - позволяет скопировать файл с диска в папку Outlook. Можно использовать, например, для переноса всех файлов из каталога с документацией по проекту в общую папку Exchange Server или в библиотеку до-
кументов SharePoint Portal Server.
CreateItem() - метод, который используется очень часто. Он позволяет создать новые элементы в Outlook. Например, создать новый элемент типа контакт, заполнить его свойства, сохранить, а затем открыть для просмотра можно так:
Dim oOutlook As New Outlook.Application Dim oContact As Outlook.ContactItem
Set oContact = oOutlook.CreateItem(olContactItem) oContact.FirstName = "Академия специальных курсов" oContact.Email1Address = "[email protected]" oContact.Save
Метод критических инцидентов.
Выявление критического инцидента - это метод, предназначенный для иден-
тификации процесса, подпроцесса или проблемной области, которые стоит со-
вершенствовать. Метод разработан Лолором в 1985 году . Это вполне откры-
тый и короткий путь получения информации о проблемах организации. Как предварительное условие, предполагается, что все участники абсолютно свободны
в изложении своих взглядов. Любая цензура или сокрытие информации из бояз-
ни, что она окажется слишком честной, решительно отвергается.
Метод включает три этапа:
1). Выбираются участники проведения анализа. Если цель заключается в при-
нятии решения о совершенствовании всего процесса целиком, то естественно
включить представителей различных областей в организации. Если же це-
лью является более точное определение направленности действий в рамках
уже определенного бизнес-процесса, то лучше выбрать людей, вовлеченных в
этот процесс.
2). Затем участникам обсуждения предлагается ответить на вопросы типа:
С каким инцидентом на прошлой неделе было труднее всего справиться?
Какой эпизод создал наибольшие проблемы для удовлетворения потреб-
ностей потребителя?
Какой инцидент обошелся дороже всего с точки зрения привлечения
дополнительных ресурсов или прямых расходов?
На этом этапе использования метода важно выделить так называемые кри-
тические инциденты, которые тем или иным способом создают проблемы
для отдельных сотрудников, для всей организации и для других заинтересо-
ванных сторон. Период, к которому относится вопрос, может варьироваться
от нескольких дней до нескольких месяцев. Не рекомендуется, однако, вы-
бирать слишком долгий период, так как в этом случае может оказаться зат-
руднительным выделить самый актуальный критический инцидент, потому
что для большого периода времени таких инцидентов могло быть много.
3). Собранные ответы сортируются и определяется, какой из различных инци-
дентов упоминался чаще других. Для выделения критического инцидента
удобно использовать графическое представление полученных результатов. Тот
инцидент, который встретился чаще других, и будет критическим. Он - яв-
ный кандидат на профилактику. Однако бороться нужно не столько с самим
инцидентом и его симптомом, сколько с причинами, его породившими.
Пример.
Большая корпорация, имевшая в штате 15 телефонисток, приступила
к проекту улучшения телефонного обслуживания потребителей при от-
ветах на звонки. Было решено воспользоваться методом выявления кри-
тического инцидента.
Всем телефонисткам было предложено описать те инциденты, имев-
шие место за последний месяц, которые поставили их в крайне за-труднительное положение. Результаты опроса были рассортированы по частоте
повторения инцидентов. Они представлены на рис. 7.1 в виде диаграммы. Из ри-
сунка видно, что критическими инцидентами были: 1) невозможность дозвониться до
человека, которому следовало бы отвечать на звонок, 2) незнание, кто именно дол-
жен отвечать. На основании результатов исследования были предприняты усилия
по созданию системы отслеживания перемещений каждого сотрудника, а также бы-
ла разработана инструкция о том, кто из сотрудников и на какой запрос должен
отвечать. Контрольный листок - это бланк-формуляр или специальная форма, предназ-
наченная для регистрации данных, Ролстадос (1995) . Одно из основных при-
ложений контрольного листка заключается в том, чтобы фиксировать, как часто
встречаются различные проблемы или инциденты. Это дает важную информа-
цию о проблемных областях или возможных причинах ошибок. Использование
контрольных листков создает хорошую основу для принятия решений о том, где
следует сконцентрировать усилия при проведении совершенствования.
Заполнение контрольного листка обычно идет в несколько этапов:
1) Достижение соглашения о том, какие события надо записывать. Все это надо
точно определить, чтобы не было сомнений в том, имело ли место событие
на самом деле. Желательно также включить в контрольный листок позицию
«Прочее», чтобы зарегистрировать инциденты, которые трудно отнести в
2) Определение периода регистрации данных и его удобного деления на интер-
3) Разработка формы (бланка) контрольного листка, используемого для регис-
трации. 4) Сбор данных происходит в течение всего согласованного периода времени.
Предварительно следует убедиться в том, что все принимающие участие в
сборе данных одинаково понимают суть происходящего. Тогда собранные
разными людьми данные будут состоятельными.
5) По окончании сбора данных производится их анализ для выявления собы-
тий, имеющих наивысшую частоту проявления. Это позволит определить
приоритеты проблемных областей в рамках заданного бизнес-процесса для
обеспечения акцентов в работе по совершенствованию. Удобное вспомога-
тельное средство для проведения такого анализа - диаграмма ПаретоДиаграмма Парето
Построение этой схемы основано на так называемом принципе Парето, сфор-
мулированном итальянским математиком Вильфредо Парето в 1800-х годах. Под-
робности данной схемы можно найти также в книге Ролстадоса . Парето был
озабочен распределением богатств в обществе и считал, что 20% населения вла-
деют 80% всех богатств. В переводе на современный язык систем качества этот
принцип заключается в том, что часто примерно 80% всех возможных проявлений
обусловлены примерно 20% всех возможных причин. Разумный подход в этом
случае - начать работу по совершенствованию с атаки именно на эти 20% при-
чин, которые обычно называют «жизненно важным меньшинством». Это совсем
не означает, что можно игнорировать оставшиеся 80% причин: в надлежащий
момент времени этими причинами, которые называют «этим важным большин-
ством», также следует заняться. Принцип Парето определяет приоритеты про-
блем, за решение которых следует браться.
Диаграмма Парето сама по себе представляет графическую интерпретацию в
виде скошенного распределения так называемого правила «80/20». Это причины,
рассортированные по степени важности, по частоте возникновения, по затратам,
по уровню показателей и т.д. При упорядочивании причин на диаграмме Парето
самые важные из них относят к левому краю схемы, так, чтобы это «жизненно
важное меньшинство» было легко идентифицировать. Для повышения информа-
тивности диаграммы Парето обычно на нее наносят и кривую накопленных час-
тот. Пример построения диаграммы представлен на рис. 7.4.
При работе с диаграммой Парето выполняют следующие действия:
1). Определите главную проблему события и ее различные потенциальные при-
чины. С учетом допущений, принятых в настоящей книге, будем считать,
что уже выбран конкретный процесс, который желательно улучшить. Таким
образом, цель построения диаграммы Парето заключается в идентификации
основных причин низкого уровня показателей.
2). Определите, какой количественный показатель будет использоваться при
сравнении возможных причин. В качестве такого показателя можно было бы
взять частоту возникновения разного рода проблем или их следствий в тер-
минах денежных затрат и других условий.
3). Определите период времени, в течение которого будут собраны данные и со-
берите их. Часто эта работа уже оказывается выполненной ранее при за-
полнении контрольных листков. Суть контрольного листка описана в § 7.2.
4). Расположите причины слева направо вдоль горизонтальной оси диаграммы
Парето по убыванию степени их относительной важности. Нарисуйте стол-
бики схемы. Их высота соответствует степени относительной важности соот-
ветствующей
причины.
5).
Отметьтеполученные
абсолютные значения показателей на
левой вертикаль-
ной оси. Отметьте относительные значения показателей в процентах на пра-
вой вертикальной оси. Нарисуйте кривую накопления важности вдоль верх-
него края столбиков.
Изучение диаграммы Парето может дать ответ на вопросы типа: 1) «Что пред-
ставляют собой две-три основные причины низкого уровня показателей данного
процесса?» или 2) «Какова доля затрат, приходящихся на самые жизненно важ-
ные причины?». Эта информация может быть использована для действий, на-
правленных на усилия по совершенствованию процесса в сторону достижения
его наивысших результатов.
Построение диаграммы Парето можно упростить, если пользоваться стандар-
тным компьютерным обеспечением, предназначенным для составления элект-
ронных таблиц. Вместе с тем для построения диаграмм Парето есть и специали-
зированное программное обеспечение. Две такие специализированные компьютерные программы - это StatGraphics Plus и ASAS/QC. Они также дают воз-
можность пользователю строить контрольные карты СУП"а. Отметим также пакет
Memory Jogger software, который может применяться с некоторыми инструментами
повышения качества.
Достоинства: Позволяет получать информацию о качествах, которые способствуют или препятствуют достижению результата в работе. Способствует лучшему пониманию содержания работы.
Недостатки: Часть полученной информации может не использоваться при создании модели, так как ряд описанных инцидентов может в итоге оказаться совершенно не характерным для работы.
Примеры авиационных происшествий и инцидентов.
Произошло несколько инцидентов высокого уровня и авиационных происшествий из-за человеческих факторов. Сайт интернета по Человеческим факторам при авиационном обслуживании и инспекциях (HFAMI) содержит 24 доклада NTSB об инцидентах, причинами которых стали человеческие факторы. В Великобритании произошло несколько происшествий и инцидентов. Подробности о них содержаться на сайте AAIB. Некоторые из этих инцидентов приведены ниже:
- Инцидент с Боингом-737,(Алоха рейс 243), Мауи, Гавайи, Апрель 1988;
- Инцидент с ВАС 1-11, G-BJRT (British Airways рейс 5390), Дидкот, Оксфордшир, 10 июня 1990.
- Инцидент с А-320, G-KMAM в Лондонском аэропорту Гатвик 26 августа 1993;
- Инцидент с Боингом-737, G-OBMM около Дэвинтри 23 февраля 1995.
Инцидент, произошедший с рейсом Алоха № 243 в апреле 1988 связан с тем, что 18 футов верхней обшивки кабины во время полета были сорваны. Самолет перед полетом проверялся согласно требованиям США двумя авиационными инспекторами. Один инспектор имел стаж работы 22 года, а второй, старший из них 33 года. Ни один не обнаружил трещин во время инспекции. Анализы, проведенные после инцидента обнаружили наличие свыше 240 трещин в обшивке этого самолета на время инспекции. Вытекающие из этого определили много проблем связанных с человеческими факторами ведущими к ненадлежащим инспекциям.
В результате инцидента с рейсом Алоха, в США была разработана программа исследования проблем связанных с человеческими факторами с акцентированием на проведение инспекций.
10 июня 1990г. в Великобритании самолет ВАС 1-11 (British Airways рейс 5390) вылетел из аэропорта Бирмингема. После набора высоты 17,300 футов в кабине пилотов было выдавлено давлением наружу левое лобовое стекло. Это стекло было заменено перед полетом. Оказалось, что из 90 крепящих болтов 84 оказались меньшего диаметра, чем необходимо. Командира корабля наполовину вытянуло из кабины через отверстие окна и его удерживали члены экипажа, пока второй пилот не произвел благополучную посадку в аэропорту Саутгэмптона.
Начальник смены (SMM) из-за недокомплекта людей во время ночной смены, решил провести замену лобового стекла самостоятельно. Он просмотрел Инструкцию (ММ) и пришел к выводу, что это простая работа. Он решил заменить крепежные болты и взяв один в качестве образца (7D)
стал подбирать другие для замены. Кладовщик сказал ему, что для замены требуются болты (8D), однако из-за их нехватки на складе, начальник смены решил, что подойдут болты (7D). (Так как они стояли на месте до этого). Тем не менее, он визуально сравнил болты и потрогал их и по ошибке выбрал болты 8С, которые длиннее и тоньше. Также он не заметил, что при установке, углубление для головки болта (потай) глубже, чем необходимо. Он сам выполнил работу и подписал сертификат выпуска. Процедура не требовала проведения углубленной или вторичной проверки. К этому инциденту имеют отношение несколько человеческих факторов, включающие неправильное определение размеров болтов начальником смены, плохое освещение на складе, не использование очков, практика проведения работ и возможные факторы конструкции и организации работы.
Самолет А-320 в Великобритании в августе 1993г. Во время первого полета после замены закрылка произошло резкое сваливание направо сразу же после взлета. Самолет вернулся в Гатвик и благополучно приземлился. Расследование показало, что во время обслуживания, для того, чтобы заменить правый закрылок, спойлеры были переведены в режим обслуживания и сдвинуты при незавершенной процедуре; соответственно отбортовки и флажки не были установлены. Назначение отбортовок и спойлеров инженерами недостаточно понималось.
Это непонимание частично было вызвано знакомство и привычка к самолету другого
типа (Боинг 757) и выразилось в недостаточном обозначении состояния спойлеров во время передачи смен. Запертый спойлер не был обнаружен во время проведения пилотом стандартных проверок.
В феврале 1995г. на самолете Боинг 757-400 обнаружилась потеря давления масла на обоих двигателях. Самолет развернулся и благополучно приземлился в аэропорту Лутона. Расследование показало, что предыдущей ночью на самолете проводилось бороскопическое исследование обоих двигателей и кожухи приводов роторов высокого давления, после выполнения работ не были установлены. В результате этого, во время полета было потеряно почти все масло из обоих двигателей. Инженер по линейному обслуживанию первоначально должен был выполнить эту работу, но по различным причинам он передал работу контролеру базового обслуживания. Контролер не имел при себе необходимых документов по работам. Контролер и слесарь выполнили работу, не смотря на многочисленные перерывы, но не установили кожухи роторов. На земле не были проведены испытания двигателей на холостых оборотах для обнаружения течей масла. Работа была расписана как выполненная.
Во всех трех инцидентах в Великобритании, инженеры, принимавшие участие в обслуживании оценивались компаниями как высоко квалифицированные, компетентные и надежные работники. Все инциденты характеризовались следующим:
- отсутствовало достаточное количество персонала;
- имелось давление по времени;
- Все ошибки произошли ночью;
- Проводилась передача смен;
- Все задействованные лица выполняли долгие ручные работы;
- Имелся элемент отношения «Могу значит делаю»;
- Имелись перерывы в работе;
- Не удалось использовать подтвержденную информацию или процедуры;
- Инструкции были противоречивы;
- Было сделано недостаточное предварительное планирование, оборудования и запчастей.
Инциденты и аварии – Нарушение человеческих факторов.
Во всех вышеуказанных примерах аварии или инциденты могли бы быть предотвращены, если одна из многих операций была бы сделана иначе. В некоторых случаях, при привлечении нескольких работников, результат их труда может быть улучшен, если один из них правильно отреагировал на конкретное действие или спросил о нем. В каждой конкретной ситуации, однако, работники не опознают и не реагируют на признаки потенциальной опасности, не реагируют на них, как от них ожидается, или позволяют себе отвлекаться на работы руками, оставляя себя открытыми для совершения ошибки.
Также как и при многих других инцидентах и авариях примеры указанные выше, включают в себя серии проблем человеческих факторов, которые формируют цепь ошибок (См. рис.3). Если одно из звеньев этой цепи будет разорвано принятием мер, которые могут предотвратить проблему в одной или нескольких стадиях ее развития, инцидент может быть предотвращен.
Рис 3. Цепь ошибок.
При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользователя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уровнях Услуг (Service Level Agreements – SLAs) Служба Service Desk назначает приоритеты, определяющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.
степень воздействия инцидента : степень отклонения от нормального уровня предоставления услуги, выражающаяся в количестве пользователей или бизнес-процессов, подвергшихся воздействию инцидента;
срочность инцидента : приемлемая задержка разрешения инцидента для пользователя или бизнес-процесса.
Приоритет определяется на основе срочности и степени воздействия. Для каждого приоритета определяется количество специалистов и объем ресурсов, которые могут быть направлены на разрешение инцидента. Порядок обработки инцидентов одинакового приоритета может быть определен в соответствии с усилиями, необходимыми для разрешения инцидента. Например, легко разрешаемый инцидент может быть обработан перед инцидентом, требующим больших усилий.
При Управлении Инцидентами существуют способы снижения степени воздействия и срочности, такие, как переключение системы на резервную конфигурацию, перенаправление очереди печати и др.
Рис. 4.2. Определение степени воздействия, срочности и приоритета
Степень воздействия и срочность также могут сами меняться во времени, например, при росте количества пользователей, подвергшихся воздействию инцидента или в критические моменты времени.
Степень воздействия и срочность могут быть объединены в матрицу, как показано в табл. 4.1.
Таблица 4.1. Пример системы кодирования приоритетов
Эскалация
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.
Различают функциональную и иерархическую эскалацию:
Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.
Иерархическая эскалация (вертикальная) – означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.
Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.
Первая, вторая и n-линия поддержки
Выше была изложена маршрутизация инцидента, или функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки. Процедура эскалации графически представлена на рис. 4.3.
Рис. 4.3. Эскалация инцидента (источник: OGC)
4.2. Цель
Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement – SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.
4.2.1. Преимущества использования процесса
Для бизнеса в целом:
Своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;
Повышение производительности работы пользователей;
Независимый, ориентированный на потребности заказчика мониторинг инцидентов;
Доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).
Для ИТ-организации:
Улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA);
Эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;
Эффективное использование персонала;
Предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;
Повышение точности информации в Конфигурационной Базе Данных (Configuration Management Database – CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item – CI);
Повышение удовлетворенности пользователей и заказчиков.
Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:
Инциденты могут быть потеряны или, наоборот, необоснованно восприняты как чрезвычайно серьезные из-за отсутствия ответственных за мониторинг и эскалацию, что может привести к снижению общего уровня обслуживания;
Пользователи могут перенаправляться к одним и тем же специалистам «по кругу» без успешного разрешения инцидента;
Специалисты могут постоянно отрываться от работы телефонными звонками пользователей, из-за чего им становится трудно эффективно выполнять свою работу;
Могут возникать ситуации, когда несколько человек будут работать над одним и тем же инцидентом, непродуктивно теряя время, и примут противоречивые решения;
Может ощущаться недостаток информации о пользователях и предоставляемых услугах, необходимой для принятия руководящих решений;
Из-за указанных выше возможных проблем затраты компании и ИТ-организации на поддержку услуг будут выше, чем реально требуется.
4.3. Процесс
На рис. 4.4 показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс.
Рис. 4.4. Положение Процесса Управления Инцидентами
4.3.1. Входы процесса
Инциденты могут возникнуть в любой части инфраструктуры. Часто о них сообщают пользователи, но возможно их обнаружение и сотрудниками других отделов, а также автоматическими системами управления, настроенными на регистрацию событий в приложениях и технической инфраструктуре.
4.3.2. Управление конфигурациями
Конфигурационная База Данных (Configuration Management Database - CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользователями и Уровнями Услуг (сервисов). Например, Управление Конфигурациями показывает, кто является ответственным за компонент инфраструктуры, что делает возможным более эффективное распределение инцидентов по группам специалистов. Кроме того, эта база данных помогает решать оперативные вопросы, например, перенаправление очереди печати или переключение пользователя на другой сервер. При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item – CI), позволяющая предоставить более подробную информацию об источнике ошибки. В случае необходимости может быть обновлен статус соответствующей компоненты в CMDB.
4.3.3. Управление Проблемами
Эффективное Управление Проблемами требует качественной регистрации инцидентов, что значительно облегчит поиск корневых причин. С другой стороны, Управление Проблемами помогает Процессу Управления Инцидентами, предоставляя информацию о проблемах, известных ошибках, обходных решениях и быстрых исправлениях .
4.3.4. Управление Изменениями
Инциденты могут быть решены путем внесения изменений, например, заменой монитора. Управление Изменениями предоставляет Процессу Управления Инцидентами информацию о запланированных изменениях и их статусах. Кроме того, изменения могут вызвать инциденты, если изменения произведены неправильно или содержат ошибки. Процесс Управления Изменениями получает информацию о них из Процесса Управления Инцидентами.
4.3.5. Управление Уровнем Услуг
Управление Уровнем Услуг контролирует выполнение договоренностей (соглашений – SLA) с заказчиком о предоставляемой ему поддержке. Сотрудники, участвующие в Управлении Инцидентами должны хорошо знать эти соглашения, чтобы использовать необходимую информацию при контактах с пользователями. Кроме того, регистрационные данные об инцидентах требуются при составлении отчетов для проверки выполнения согласованного Уровня Услуг.
4.3.6. Управление Доступностью
Для определения показателей доступности услуг Процесс Управления Доступностью использует регистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. Аналогично Конфигурационной Единице (CI) в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус «не работает» . Это может быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени действий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия.
4.3.7. Управление мощностями
Процесс Управления Мощностями получает информацию об инцидентах, связанных с функционированием самих ИТ-систем, например, инцидентах, произошедших в связи с недостатком дискового пространства или медленной скоростью реакции и т.д. В свою очередь, информация об этих инцидентах может поступать в Процесс Управления Инцидентами от системного администратора или от самой системы на основе мониторинга своего состояния.
Ни рис. 4.5. показаны этапы процесса:
Рис. 4.5. Процесс Управления Инцидентами
Прием и регистрация инцидента (Acceptance and Recording) – принимается сообщение и создается запись об инциденте.
Классификация и начальная поддержка (Classification and Initial Support) – присваиваются тип, статус, степень воздействия, срочность, приоритет инцидента, SLA и т.п. Пользователю может быть предложено возможное решение, даже если оно только временное.
Если вызов касается Запроса на Обслуживание (Service Request) , то инициируется соответствующая процедура.
Привязка (или сопоставление – Matching) – проверяется, не является ли инцидент уже известным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути.
Расследование и диагностика (Investigation and Diagnosis) – при отсутствии известного решения производится исследование инцидента с целью как можно быстрее восстановить нормальную работу.
Решение и восстановление (Resolution and Recovery) – если решение найдено, то работа может быть восстановлена.
Закрытие (Closure) – с пользователем связываются, чтобы он подтвердил согласие с предложенным решением, после чего инцидент может быть закрыт.
Мониторинг хода работ и отслеживание (Progress monitoring and Tracking) – весь цикл обработки инцидента контролируется, и если инцидент не может быть разрешен вовремя, производится эскалация.
4.4. Виды деятельности
4.4.1. Прием и регистрация
В большинстве случаев инциденты регистрируются Службой Service Desk, куда поступают сообщения о них. Регистрация всех инцидентов должна производиться немедленно после поступления сообщения по следующим причинам:
Трудно произвести точную регистрацию информации об инциденте, если это не сделано сразу;
Мониторинг хода работ по решению инцидента возможен, только если инцидент зарегистрирован;
Зарегистрированные инциденты помогают при диагностике новых инцидентов;
Управление Проблемами может использовать зарегистрированные инциденты при работе над поиском корневых причин;
Легче определить степень воздействия, если все сообщения (звонки) зарегистрированы;
Без регистрации инцидентов невозможно контролировать исполнение договоренностей (SLA);
Немедленная регистрация инцидентов предотвращает ситуации, когда или несколько человек работают над одним звонком, или никто ничего не делает для разрешения инцидента.
Место обнаружения инцидента определяется по признаку, откуда пришло сообщение о нем. Инциденты могут быть обнаружены следующим образом:
Обнаружен пользователем : он докладывает об инциденте в Службу Service Desk.
Обнаружен системой : при обнаружении события в приложении или технической инфраструктуре, например, при превышении критического порога, событие регистрируется как инцидент в системе регистрации инцидентов и, при необходимости, направляется в группу поддержки.
Обнаружен сотрудником Службы Service Desk : сотрудник производит регистрацию инцидента.
Обнаружен кем-либо в другом подразделении ИТ : этот специалист регистрирует инцидент в системе регистрации инцидентов или докладывает о нем в Службу Service Desk.
Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов:
Если есть (и они касаются того же инцидента) , информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе.
Если нет (отличается от открытого инцидента) , производится регистрация нового инцидента.
В обоих случаях продолжение процесса одинаково, хотя в первом случае последующие действия гораздо проще.
При регистрации инцидента производятся следующие действия:
Назначение номера инцидента : в большинстве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы он мог ссылаться на него при дальнейших контактах.
Запись базовой диагностической информации : время, признаки (симптомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего инцидента и информация о затронутой услуге и/или технических средствах.
Запись дополнительной информации об инциденте : добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Базы Данных – CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB).
Объявление сигнала тревоги : если происходит инцидент, имеющий высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства.
4.4.2. Классификация
Классификация инцидентов направлена на определение его категории для облегчения мониторинга и составления отчетов. Желательно, чтобы опции классификации были как можно шире, но при этом требуется более высокий уровень ответственности персонала. Иногда пытаются объединить в одном перечне несколько аспектов классификации, таких, как тип, группа поддержки и источник. Это часто вносит путаницу. Лучше использовать несколько коротких перечней. В данном разделе рассматриваются вопросы, относящиеся к классификации.
Центральная процессинговая система – подсистема доступа, центральный сервер, приложение.
Сеть – маршрутизаторы, сегменты, концентратор (hub), IP-адреса.
Рабочая станция – монитор, сетевая карта, дисковод, клавиатура.
Использование и функциональность – услуга (сервис), возможности системы, доступность, резервное копирование (back-up), документация.
Организация и процедуры – заказ, запрос, поддержка, оповещение (коммуникации).
Запрос на Обслуживание – запрос пользователя в Службу Service Desk на поддержку, предоставление информации, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.
Приоритет
После этого назначается приоритет, чтобы быть уверенными, что группа поддержки уделит инциденту необходимое внимание. Приоритет - это номер, определяющийся срочностью (насколько быстро это должно быть исправлено) и степенью воздействия (какой ущерб будет нанесен, если не исправить быстро).
Приоритет = Срочность х Степень воздействия.
Услуги (сервисы)
Для определения услуг, подвергшихся воздействию инцидента, может быть использован перечень существующих договоренностей (соглашений) об Уровне Услуг – SLA. Этот перечень позволит также установить время эскалации для каждой из услуг, определенных в SLA.
Группа поддержки
Если Служба Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (маршрутизации) инцидентов часто является информация о категориях. При определении категорий может потребоваться рассмотрение структуры групп поддержки. Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности (KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений.
Сроки решения
С учетом приоритета и соглашения SLA пользователь информируется о максимальном расчетном времени разрешения инцидента. Эти сроки также фиксируются в системе.
Идентификационный номер инцидента
Абонент информируется о номере инцидента для его точной идентификации при последующих обращениях.
Статус
Статус инцидента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:
Запланирован;
Назначен;
Активный;
Отложен;
Разрешен;
4.4.3. Привязка (сопоставление)
После классификации проводится проверка, не возникал ли аналогичный инцидент ранее и нет ли готового решения или обходного пути. Если инцидент имеет те же признаки, что и открытая проблема или известная ошибка, то может быть установлена связь с ними.
4.4.4. Расследование и диагностика
Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следующего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или направляет его группе поддержки очередного уровня.
В процессе разрешения инцидента различные специалисты могут обновлять регистрационную запись о нем, изменяя текущий статус, информацию о выполненных действиях, пересматривая классификацию и обновляя время и код работавшего сотрудника.
4.4.5. Решение и восстановление
После успешного завершения анализа и разрешения инцидента сотрудник записывает решение в систему. В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями. В наихудшем случае, если не найдено никакого решения, инцидент остается открытым.
4.4.6. Закрытие
После реализации решения, удовлетворяющего пользователя, группа поддержки направляет инцидент обратно в Службу Service Desk. Эта служба связывается с сотрудником, сообщившим об инциденте, с целью получения подтверждения об успешном решении вопроса. Если он это подтверждает, то инцидент может быть закрыт; в противном случае процесс возобновляется на соответствующем уровне. При закрытии инцидента необходимо обновить данные об окончательной категории, приоритете, сервисах (услугах), подвергшихся воздействию инцидента и Конфигурационной Единице (CI), вызвавшей сбой.
4.4.7. Мониторинг хода решения и отслеживание
В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента. Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д. Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.
4.5. Контроль процесса
Основой контроля процесса являются отчеты для различных целевых групп. Руководитель Процесса Управления Инцидентами является ответственным за эти отчеты, а также за составление списка рассылки и графика составления отчетов. Отчеты могут включать специализированную информацию для следующих функциональных подразделений:
Руководителю Процесса Управления Инцидентами отчет необходим для :
Идентификации недостающих звеньев процесса;
Идентификации нарушений исполнения соглашений об Уровне Услуг (SLA);
Отслеживания хода выполнения процесса;
Определения тенденций развития.
Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следующую информацию:
Прогресс в решении инцидентов;
Время разрешения инцидентов в различных группах поддержки.
Управления Уровнем Сервисов (Услуг) – отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглашения в отношении Уровня Сервисов (услуг) в рамках Процесса Управления Инцидентами.
Руководителей других процессов ИТ Сервис-менеджмента – отчеты для руководителей других процессов должны быть, в первую очередь, информативными, то есть содержать всю необходимую им информацию. Например, Процесс Управления Инцидентами на основе регистрационных записей об инцидентах может предоставлять следующую информацию:
Число обнаруженных и зарегистрированных инцидентов;
Число разрешенных инцидентов, с разделением по времени разрешения;
Статус и число неразрешенных инцидентов;
Инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии с соглашением (SLA);
4.5.1. Критические факторы успеха
Для успешного Управления Инцидентами необходимо следующее:
Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. Эта информация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличению времени разрешения инцидентов.
Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. Отчет по этим показателям производится регулярно, например раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции. Примерами таких параметров являются:
Общее количество инцидентов;
Среднее время разрешения инцидентов;
Среднее время разрешения инцидентов по приоритетам;
Среднее число инцидентов, разрешенных в рамках соглашений (SLA);
Процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);
Средняя стоимость поддержки на инцидент;
Число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;
Инциденты, решенные без посещения пользователя (удаленно);
Число (или процент) инцидентов с первоначально некорректной классификацией;
Число (или процент) инцидентов, неправильно распределенных в группы поддержки.
4.5.3. Функции и роли
Реализация процессов проходит в горизонтальной плоскости через иерархическую структуру организации. Это возможно только при четком определении ответственности и полномочий, связанных с реализацией процессов. Для повышения гибкости может быть использован ролевой подход (т.е. определение ролей). В небольших организациях или в целях снижения общих расходов возможно комбинирование ролей, например, совмещение ролей Руководителя Процессов Управления Изменениями и Управления Конфигурациями.
Руководитель Процесса Управления Инцидентами
Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включается следующее:
Мониторинг эффективности и рациональности работы процесса;
Контроль работы групп поддержки;
Развитие и сопровождение системы Управления Инцидентами.
Персонал групп поддержки
Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов.
Остальные группы поддержки, прежде всего, принимают участие в расследовании, диагностике и разрешении инцидентов в рамках установленных приоритетов.
4.6. Затраты и проблемы
4.6.1. Затраты
Затраты, связанные с Управлением Инцидентами, включают первоначальные затраты на внедрение (например, расходы на разработку процесса, обучение и инструктаж персонала), выбор и закупку инструментальных средств поддержки процесса. Выбор инструментальных средств может занять значительное количество времени. Кроме того, существуют операционные расходы, связанные с оплатой работы персонала и использованием инструментальных средств. Эти затраты во многом зависят от структуры Управления Инцидентами, диапазона видов деятельности, включенных в процесс, сфер ответственности и числа подразделений.
4.6.2. Проблемы
При внедрении Управления Инцидентами могут возникнуть следующие проблемы:
Пользователи и ИТ-специалисты работают в обход процедур Управления Инцидентами – если пользователи будут устранять возникающие ошибки сами или напрямую связываться со специалистами, не следуя установленным процедурам, ИТ-организация не получит информацию о реально предоставляемом Уровне Услуг, числе ошибок и многое другое. Отчеты руководству также не будут адекватно отражать ситуацию.
Перегруженность инцидентами и откладывание «на потом» – при неожиданном росте количества инцидентов для правильной регистрации может не оказаться достаточно времени, т. к. до окончания ввода информации об инциденте от одного пользователя возникает необходимость обслуживать следующего. В этом случае ввод описания инцидентов может производиться недостаточно точно и процедуры по распределению инцидентов по группам поддержки не будут выполняться должным образом. В результате решения получаются некачественными и рабочая нагрузка увеличивается еще больше. В случаях, если число открытых инцидентов начинает интенсивно расти, процедура экстренного выделения дополнительных ресурсов внутри организации может предотвратить перегрузку персонала.
Эскалация – как известно, в рамках Процесса Управления Инцидентами возможна эскалация инцидентов. Слишком большое число эскалаций может оказать отрицательное воздействие на работу специалистов, которые из-за этого отрываются от своей запланированной работы.
Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) – если поддерживаемые услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управление Инцидентами, бывает трудно обоснованно отказать пользователям в помощи.
Недостаточная приверженность процессному подходу со стороны руководства и персонала – решение инцидентов с помощью процессного подхода обычно требует изменения культуры и более высокого уровня ответственности за свою работу со стороны персонала. Это может вызвать серьезное сопротивление внутри организации. Эффективное Управление Инцидентами требует от сотрудников понимания и реальной приверженности процессному подходу, а не просто участия.
Примечания:
Под «цепочкой» понимается цепь создания прибавочной стоимости. – Прим. ред.
В литературе по ITIL понятие «функция» ассоциировано с вертикальным (линейным) подразделением организации, выполняющим соответствующие функциональные обязанности и фактически является его синонимом. – Прим. ред.
Service Request.
Request for Change (RFC).
Configuration Item (CI).
Key Performance Indicators – KPI.
Performance Indicators.
Effectiveness and Efficiency.
Т.е. программного обеспечения. – Прим. ред.