Разработка службы Service Desk АО "Алюминий Казахстана"

в качестве средств разработки использовались:

ASP.NET (Microsoft Visual Studio .NET 2005, C#; библиотеки Microsoft Ajax и Microsoft .NET framework 2.0, javascript на стороне клиента);

PL/SQL;

в качестве операционной системы могут использоваться Windows 2000 Professional, Windows 2000 Server, Windows 2003 Server;

в качестве СУБД используется СУБД Oracle 10g или Oracle XE;

в качестве Web-сервера применяется IIS версии 6.0 и выше;

программное обеспечение подсистемы (клиентская часть) функционирует в среде Internet Explorer ® версии 6.5 или выше.

2.3 Блок-схемы службы Service Desk

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

Рисунки 2.6 и 2.7 представляют блок-схему основных процедур Управления изменениями.

Рисунок 2.8 показывает использование стандартных процедур Управления изменениями (моделей Изменений) в рамках жизненного цикла Изменения.

Рисунок 2.6 - Основные процедуры Управления изменениями



Рисунок 2.7 - Основные процедуры Управления изменениями.

Рисунок 2.8 - Подход к стандартным процедурам Управления изменениями.

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

задачи хорошо известны и проверены;

полномочия переданы заранее;

цепочка событий, как правило, инициируется службой Service Desk;

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

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

Запросы на Изменение.

У запросов на Изменение (RFC, или Request for Change) множество причин и источников. Причины могут быть следующие:

- требуется решение, указанное в отчете об Инциденте или Проблеме;

- неудовлетворенность Пользователя или Заказчика, переданная через связь с Заказчиком или Управление уровнем обслуживания;

- предложение о введении нового УЭ или удалении УЭ;

- предложение по модернизации некоторых компонентов инфраструктуры;

- изменение требований или направления бизнеса;

- нововведения или изменения в законодательстве;

- изменение местоположения;

- изменения в продуктах или услугах, предоставляемых поставщиками или подрядчиками.

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

- аппаратное обеспечение;

- программное обеспечение;

- документация;

- телекоммуникационное оборудование;

- специализированное оборудование;

- образовательные курсы;

- процедуры управления ИТ-инфраструктурой;

- тактические планы;

- обеспечивающая инфраструктура.

RFC, может храниться как в бумажной форме, так и в электронном виде.

Следующие элементы должны быть включены в форму RFC (как бумажного, так и электронного):

- порядковый номер RFC (плюс перекрестная ссылка на номер отчета о Проблеме, если это необходимо);

- описание и идентификация элемента (или элементов), который следует изменить (включая идентификацию УЭ, если используется система Управления конфигурациями);

- причина для внесения Изменения;

- последствия в случае, если Изменение не будет внедрено;

- версия изменяемого элемента;

- название, местоположение и телефонный номер человека, предлагающего Изменение;

- дата, когда было предложено Изменение;

- приоритет Изменения;

- оценка влияния и ресурсов (которая может быть представлена в отдельных формах, если это удобно;).

- рекомендации САВ, когда это уместно; эти рекомендации могут храниться отдельно или вместе с оценками воздействия и ресурсов, если это удобно;

- авторизующая подпись (может быть электронной);

- дата и время авторизации;

- планируемое внедрение (идентификация Релиза и/или даты и времени);

- местоположение плана Релиза/внедрения;

- сведения о том, кто разрабатывает/внедряет Изменения;

- план отката;

- действительные дата и время внедрения;

- дата проведения анализа;

- результаты анализа (включая перекрестные ссылки на новый RFC, если это необходимо);

- оценка и управление рисками;

- влияние на план непрерывности бизнеса и на план действий в чрезвычайных ситуациях;

- статус RFC, т.е. «обработан», «оценен», «отклонен», «принят», «в ожидании».

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

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

Консультативный комитет по изменениям.

Консультативный комитет по изменениям (Change Advisory Board, CAB) - орган, который существует для утверждения Изменений и для содействия Менеджерам процесса Управления изменениями при оценке и определении приоритетов изменений. САВ должен состоять из тех, кто способен обеспечить адекватную оценку всех Изменений с точки зрения как бизнеса, так и технологий. Для достижения такого баланса САВ должен включать людей с четким пониманием бизнес-нужд Заказчиков и сообщества Пользователей, а также технического развития и функций поддержки. Также см. параграф 8.5.5.

Рекомендуется, чтобы в САВ при необходимости входили:

- Менеджер изменений;

- Заказчик(и);

- Менеджер(ы) Пользователей;

- представитель(и) групп Пользователей;

- разработчики/специалисты по сопровождению приложений (если это целесообразно);

- эксперты/технические консультанты;

- обслуживающий персонал (по необходимости);

- офисный обслуживающий персонал (там, где Изменения могут повлиять на помещение и наоборот);

- представители подрядчиков и внешних поставщиков (например, в случаях аутсорсинга).

Важно подчеркнуть, что:

- САВ будет формироваться в зависимости от рассматриваемых Изменений;

- состав САВ может значительно варьироваться даже в течение одного собрания;

- в САВ должны входить поставщики, если это будет полезно;

- САВ должен отражать взгляды, как пользователей, так и Заказчиков;

- в САВ, вероятно, войдут Менеджер проблем и Менеджер уровня обслуживания.

Когда возникают крупные Проблемы, может случиться так, что для созыва САВ нет времени, и в связи с этим необходимо определить минимальный состав, который будет уполномочен принимать срочные решения. Такой орган известен как Комитет по срочным изменениям CAB (САВ/ЕС, или Change Advisory Board/Emergency Committee). Процедуры Изменений должны указывать, как в каждом случае будет определяться состав САВ и САВ/ЕС на основании критериев, описанных выше, и других критериев, которые могут быть целесообразны для бизнеса. Целью этого является обеспечение гибкости состава САВ, чтобы интересы бизнеса были соответствующим образом представлены в случаях, когда предлагаются крупные Изменения. Это также обеспечит то, что состав САВ/ЕС позволит принимать соответствующие решения с точки зрения, как бизнеса, так и технологий, при любом возможном стечении обстоятельств.

Практический совет: полезно помнить, что САВ должен иметь описанные и согласованные критерии оценки. Это поможет процессу оценки Изменений и будет служить шаблоном или структурой, с помощью которой члены САВ смогут оценивать каждое Изменение.

Метрики изменений.

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

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

Согласованный график изменений и модели изменений.

Одна область Управления изменениями развивается значительно быстрее других.

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

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

С другой стороны, небольшие Изменения могут быть проведены с использованием «стандартных» моделей Изменений - например, обмен ПК или регулярное обновление ПО. До тех пор пока соблюдается предписанный график вместе со всеми критериями (возможно, критериями, связанными, например, с процессами сборки и тестирования), Менеджеры процесса Управления изменениями могут авторизовать подобные Изменения без задействования всего процесса Управления изменениями. Рисунок 2.8 показывает, как процесс использования стандартных моделей Изменений, определенный Менеджерами процесса Управления изменениями при согласии других менеджеров процессов поддержки услуг, может быть интегрирован в рамки обычных процессов Изменений. Следует заметить, что определение масштаба или сложности Изменений, связанных с использованием моделей, индивидуальны для каждой организации.

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

Для того чтобы улучшить этот процесс, Менеджеры процесса Управления изменениями должны координировать разработку и распространение «Согласованного графика изменений» (FSC) и «Ожидаемой доступности услуги» (PSA, или Projected Service Availability). Новейшие версии этих документов должны быть доступны каждому сотруднику в рамках организации. Предпочтительно, чтобы эти версии находились на общедоступном интернет или интранет - сервере. FSC содержит сведения обо всех Изменениях, утвержденных к внедрению, и предлагаемые даты их внедрения. PSA содержит сведения об Изменениях в согласованных SLA и о доступности услуг вследствие планируемого FSC. Эти документы должны быть согласованы с Заказчиками из бизнеса, с Управлением уровнем обслуживания, со Службой Service Desk и с Управлением доступностью. После согласования Служба Service Desk должна сообщить всему сообществу Пользователей о любых дополнительно планируемых простоях наиболее эффективным из доступных способов.

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

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

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

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

Аутсорсинг и Управление изменениями.

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

Когда рассматривается аутсорсинг, получатель услуг должен однозначно ответить на следующие вопросы, затрагивающие основные аспекты процесса Управления Изменениями:

- Кто несет ответственность за ежедневное Управление Изменениями, происходящими на основании RFC из различных источников.

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

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

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

- Кто отвечает за целостность системы и услуг после Изменений?.

- Насколько тщательно рассматриваются вопросы безопасности систем?.

- Кто должен входить в состав САВ?.

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

- затрат;

- владения аппаратным и программным обеспечением;

- степени партнерства бизнеса с поставщиком (в отличие от простых взаимоотношений поставщик-потребитель);

- типа предоставляемых услуг;

- масштабов этих услуг (инфраструктура, службы Service Desk, разработка прикладного ПО и т.д.).

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

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

Управление изменениями должно охватывать следующие вопросы:

- содержание плана;

- владение;

- распространение;

- ключевые бизнес - направления, которые необходимо поддерживать;

- как эти бизнес-направления поддерживаются ИТ;

- связи с непрерывностью бизнеса и планами действий ИТ в чрезвычайных ситуациях;

- критические компоненты;

- временные рамки;

- риски;

- стратегия возврата в предыдущее состояние;

- инициирование.

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

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

2.4 Процесс разработки службы Service Desk

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

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

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

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

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

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

1) «Промышленные решения как часть платформы управления ИТ» ориентированы на построение комплексных систем управления ИТ за счет заложенных возможностей автоматизации многих процессов управления ИТ, описанных в книгах ITIL, ведения сложных иерархических каталогов услуг и развитого учета информации о компонентах ИТ в CMDB (configuration management database). Автоматизация Service Desk -- лишь небольшая часть их возможностей. Системы этого класса обладают мощными средствами интеграции, широкими возможностями по масштабированию и встроенными средствами разработки, позволяющими реализовать практически любой функционал. Яркими представителями этого класса систем являются BMC Remedy IT Service Management Suite, HP Service Manager. Стоимость лицензий среднего внедрения этого класса систем выше 100 000$.

2) «Средние системы» включают богатый функционал, покрывающие потребности типового внедрения Service Desk. Они позволяют автоматизировать ряд смежных процессов управления ИТ, как правило, включают возможности формирования каталога ИТ-услуг и ведения CMDB. Особенность и ключевое преимущество этого класса систем - простота внедрения и сопровождения, связанная с тем, что необходимый функционал обычно уже в значительной мере преднастроен, а его адаптация под свои нужды, как правило, обеспечивается удобными средствами настройки. Эти системы, как правило, имеют ограничения в части реализации нестандартных требований, масштабирования и создания территориально распределенных конфигураций, подходу к интеграции с другими решениями. Стоимость лицензий для средних внедрений колеблется в пределах 30 000$-100 000$. Примерами являются HP Service Desk v4.5 и v5.x (снятый с продажи, но поддерживаемый), Axios Assyst.

3) «Легкие системы» ориентированы в первую очередь на автоматизацию Service Desk. К этому классу отнесены недорогие системы (от бесплатных, до полноценных коммерческих продуктов ценой от 1 500$ до 20 000$ за среднее внедрение). Системы этого класса представляют собой либо хорошо продуманные системы с «жесткими» границами в части настроек (например, Footprints Track-IT), или же системы, предполагающие некоторую базовую логику, за изменение которой придется платить разработкой, однако разработка так же позволяет расширить границы изначального функционала (пример -- Service Desk Итилиум, разработанной на платформе 1С).

Встречаются инициативы по автоматизации Service Desk собственными разработками или с использованием неспециализированных средств автоматизации (системами документооборота или средствами «учета ошибок», используемых разработчиками ПО).

namespace Helpdesk.ViewModel

{

public class LoginViewModel : ViewModelBase

{

private string _login;

public string Login

{

get { return _login; }

set

{

_login = value;

RaisePropertyChanged("Login");

}

}

private string _password;

public string Password

{

get { return _password; }

set

{

_password = value;

RaisePropertyChanged("Password");

}

}

private RelayCommand _loginCommand;

public RelayCommand LoginCommand

{

get

{

if (_loginCommand == null)

{

_loginCommand = new RelayCommand(Authorize, CanAuthorize);

}

return _loginCommand;

}

set { _loginCommand = value; }

}

HelpdeskContext db = new HelpdeskContext();

void Authorize()

{

var nuser = new UserProfile()

{

UserName = "admin",

Password = "123456",

Role = 0

};

db.UserProfiles.Add(nuser);

db.SaveChanges();

var user = db.UserProfiles.FirstOrDefault(x => x.UserName == Login);

if (user == null)

{

MessageBox.Show("Пользователя с таким не зарегистрировано");

return;

}

if (user.Password == Password)

{

AppSecurity.CurrentUser = user;

//Messenger.Default.Send<string>("", "Login");

}

else

{

MessageBox.Show("Неверный пароль");

}

}

bool CanAuthorize()

{

return !string.IsNullOrEmpty(Login) && !string.IsNullOrEmpty(Password);

}

}

}

Собственные разработки (от Excel файла до базы на MS Access) могут вполне отвечать запросам небольшого ИТ-подразделения. Однако серьезные инвестиции денег и сил для автоматизации Service Desk на базе неспециализированных средств редко оправдываются. Даже самые «легкие системы» автоматизации Service Desk включают большое количество продуманных решений и удобств, не говоря уже о специфических возможностях интеграции с системами мониторинга, инвентаризации и т.д.

2.5 Процесс эксплуатации программы «Мониторинг» службы Service Desk

Регистрация инцидентов может быть легко настроена под задачи Service Desk / ИТ департамента компании. Адаптация Service Desk-приложения может быть осуществлена аналитиками без привлечения технических специалистов.

Рисунок 2.9 - Аутентификация

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

Рисунок 2.10 - Регистрация пользователей

Необходимо предоставить пользователям разные интерфейсы для обращения в службу Service Desk: используйте для этих целей контакт-центр, корпоративный портал, социальные сети и e-mail.

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

Рисунок 2.11 - Единая точка контакта

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

Рисунок 2.12 - Управление знаниями

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

Рисунок 2.13 - Управление каталогом услуг

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

мониторинг обработка заявка

Рисунок 2.14 - Управление уровнем сервиса

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

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

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

Рисунок 2.15 - Инциденты и запросы на обслуживание

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

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

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

Рисунок 2.16 - Управление проблемами

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

Важно учитывать степень влияния конфигурационных единиц на предоставляемые сервисы или услуги.

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

Рисунок 2.17 - Управление конфигурациями

Рисунок 2.18 - График управление конфигурациями



Рисунок 2.19 - Управление конфигурациями РЕЛИЗ

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

Рисунок 2.20 - Управление процессами оказания услуг

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

Рисунок 2.21 - Управление информацией о заказчиках и поставщиках

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

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

Рисунок 2.22 - Управление рабочим временем сервисных инженеров.

Заключение

Удовлетворенность заказчика или пользователя является основным показателем эффективности работы Службы Service Desk. Примерами Ключевых параметров эффективности могут быть:

скорость ответа на телефонные звонки (например, на 90% телефонных звонков отвечают в течение X секунд);

скорость перенаправления звонков на вторую линию поддержки в течение X минут (если звонок нельзя разрешить на уровне Service Desk);

восстановление сервиса в течение допустимого времени и в соответствии с условиями Соглашения об Уровне Услуг (SLA);

своевременное информирование пользователей о текущих и будущих изменениях и ошибках.

Некоторые показатели эффективности можно определить только на основе результатов опроса заказчиков, например такие как:

насколько вежливо специалисты Service Desk общаются по телефону?

предоставляются ли пользователям хорошие рекомендации по способу предотвращения инцидентов?

Служба Service Desk должна регулярно (например, раз в полгода) проверять, насколько ее работа отвечает заданным стандартам. Примерами метрик являются:

процент инцидентов, которые могут решаться на Уровне Service Desk без перенаправления на другие уровни поддержки (например, на вторую или третью линии поддержки или к поставщику);

количество обработанных звонков на одно рабочее место/пользователя и общее количество звонков, обработанных Службой Service Desk;

среднее время решения инцидентов (по степени воздействия) или время, необходимое для выполнения Запроса на Обслуживание. Следует указывать как непосредственное время на выполнение, так и общее время от открытия до закрытия инцидента;

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

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

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

Если пользователи пытаются установить контакты напрямую со специалистами, их следует направлять в Службу Service Desk.

Для того, чтобы поддержка, оказываемая Службой Service Desk была сфокусированной, следует тщательно прорабатывать Каталог услуг, Соглашения об Уровне Услуг (SLA) и Операционные Соглашения об Уровне Услуг (OLAs).

После того как служба Service Desk начала стабильно работать и прошел период адаптации, после того как улягутся первые страсти пользователей, можно задуматься о том, в каком направлении развиваться дальше. Путей много. Самым очевидным из них является повышение компетенции первой линии поддержки. Сразу после запуска службы первая линия (операторы call-центра) сможет закрывать максимум 20-30% всех регистрируемых инцидентов. Этот результат весьма хорош. Но совершенству нет предела. Развивая компетенцию операторов, обучая их, добавляя им дополнительные права и обязанности, можно повысить процент инцидентов, закрываемых на первой линии поддержки. В этом случае специалисты второй и третьей линий в большей степени смогут посвятить себя сложным и нетривиальным задачам. Второй эффект от увеличения числа инцидентов, закрываемых операторами, проявится в большей удовлетворенности пользователей работой департамента ИТ: та часть вопросов, которая ранее решалась, к примеру, в течение двух-трех часов (время реакции второй линии поддержки), теперь будет решаться за 10-20 минут.

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

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

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

Результаты работы:

1) Сокращение затрат

- скрытые и незапланированные затраты: -10%

- расходы на обучение сотрудников: -25%

- средняя стоимость поддержки на инцидент -20%

- среднее время простоя оборудования -50%

2) Увеличение качества

- средний уровень удовлетворенности пользователей: 95%

- возврат инвестиций (ROI): +15%

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

Рогачева Е. В. Интеллектуализация базы знаний систем Service Desk [Текст] / Е. В. Рогачева, В. В. Ломакин // Молодой ученый. -- 2012. -- №2. -- С. 63-66.

Введение в ИТ Сервис-менеджмент" ISBN: 9077212159 Издательство: Открытые Системы

Кирьянов В. Комплексный интерфейс Service Desk на базе технологии Web-сервисов // Byte, №6, 2007, стр. 72-76

Разумовский С. Концепция управления ИТ-услугами. // Открытые системы, 2008, № 12.

Потоцкий М., Журавлев Р. Управление ИТ-услугами // Открытые системы, №01, 2009.

Осиновский А. С. Библиотека ITIL как инструмент управления качеством информационных услуг // Сети и системы связи, №6, 2008.

Иванов Д.Б., Юрочкин А.Г. Критерии выбора модели планирования организации работы службы поддержки // Информационные технологии моделирования и управления, №2(45). Воронеж, Научная книга, 2008.

Иванов Д.Б., Юрочкин А.Г. Использование систем класса Service Desk для повышения качества поддержки услуг // Интеллектуализация управления в социальных и экономических системах: Труды Всерос. конф. Воронеж, 2008

Иванов Д.Б., Юрочкин А.Г. Повышение эффективности функционирования службы технической поддержки методом распределения по видам работ с использованием генетических алгоритмов // Вестник ВГТУ, том 4, №2. Воронеж,

Дунаев Г., Плюснин А. Обследования в проектах по внедрению процессов ITSM // Intelligent Enterprise, №6, 2007.

Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем, ИНТУИТ.ру, 2007, 296 стр.

Сервис-менеджмент, введение. Перевод на русский язык под редакцией М.Ю. Потоцкого- М.: Открытые Системы, 2007.

Ренат Багиров. ИТ-менеджмент начинается с Service Desk [Электронный ресурс] - URL: http://www.cnews.ru/reviews/index.shtml? 2005/06/01/178742.

Словарь терминов и определений ITIL 2011 на русском языке.

Ян Ван Бон, Георгес Кеммерлинг, Дик Пондман, ИТ Сервис менеджмент, введение, Van Haren Publishing, 2003 г., 228стр., ISBN: 90-77212-15-9 .

Талызин Д. Г. Автоматизация процессов обработки заявок в системах поддержки пользователей корпоративных информационных систем: Дис. канд. тех. наук. Москва. 2010. 154 стр.

ГОСТ Р ИСО/МЭК 20000-2007 Управление услугами. Часть 1 - Общие положения и словарь (ISO/IEС 20000-1:2005 «Information technology - Service management - Part 1: Specification»)

ГОСТ Р ИСО/МЭК 20000-2007 Управление услугами. Часть 2 - Практическое руководство (ISO/IEС 20000-2:2005 «Information technology - Service management - Part 2: Code of practice»)

СовiТ 4.1. Москва, Аудит и контроль информационных систем 2008

М.Б. Букреев, А.Е. Заславский, «Управление ИТ-сервисами информационно-телекоммуникационных систем (ИТС)», Москва, РУСЭЛПРОМ, 2007г.

Культин Н.Б. Самоучитель С++ Builder. -- СПб.: БХВ-Петербург,2007. -- 320с.: ил.

Культин Н.Б. С/С++ в задачах и примерах. -- СПб.: БХВ-Петербург, 2007. -- 288с.: ил.

Borland Builder C++. Освой самостоятельно. -- СПб.: Питер, 2007. -- 702с.: ил.

Холзнер С. Visual C++ 6. Учебный курс. -- СПб.: Питер, 2007. -- 570с.: ил.

Красиков И.В., Красикова И.Е. Алгоритмы. Просто как дважды два. -- М.: Эксмо,2007. -- 256с.: ил.

Карпов Б., Баранова Т. С++. Специальный справочник (2-е издание). -- СПб.: Питер, 2007. -- 381с.: ил.

Франка П. С++: Учебный курс. -- СПб.: Питер, 2007. -- 522 с.

Вильямс - Microsoft ASP.NET 2.0 с примерами на C# для профессионалов, Москва, 2007.

Matthew MacDonald - Beginning ASP.NET 3.5 in C# 2008: From Novice to Professional. Second Edition, 2007

Matthew MacDonald and Mario Szpuszta - Pro ASP.NET 3.5 in C# 2008, Second Edition, 2007

Гуриков С. Р. Введение в программирование на языке Visual C#; Форум, Инфра-М, 2013. - 448 c.

Мартин Р. С., Мартин М. Принципы, паттерны и методики гибкой разработки на языке C#; Символ-Плюс, 2011. - 768 c.

Пугачев С., Шериев А., Кичинский К. Разработка приложений для Windows 8 на языке C#; БХВ-Петербург, 2013. - 416 c.

Фленов Михаил Библия C#; БХВ-Петербург, 2009. - 560 c.
5. Фленов Михаил Библия C#; БХВ-Петербург, 2011. - 560 c.

Программирование на языке высокого уровня. Часть 1. Среда Visual Studio: методические указания к лабораторным работам / Сост. В. И. Кручинин; Волгоград. гос. техн. ун-т. - Волгоград, 2009. - 30 с.

Программирование на языке высокого уровня. Часть 2. Язык C#: методические указания к лабораторным работам / Сост. В. И. Кручинин; Волгоград. гос. техн. ун-т. - Волгоград, 2009. - 31 с.

Приложение

namespace Helpdesk.ViewModel

{

public class MainViewModel : ViewModelBase

{

public MainViewModel()

{

Tasks = new ObservableCollection<TechTask>(db.TechTasks);

Messenger.Default.Register<TechTask>(this,"TaskCreated", (t) =>

{

Tasks.Add(t);

});

}

HelpdeskContext db = new HelpdeskContext();

private ObservableCollection<TechTask> _tasks;

public ObservableCollection<TechTask> Tasks

{

get { return _tasks; }

set

{

_tasks = value;

RaisePropertyChanged("Tasks");

}

}

private TechTask _selectedTask;

public TechTask SelectedTask

{

get { return _selectedTask; }

set

{

_selectedTask = value;

RaisePropertyChanged("SelectedTask");

RaisePropertyChanged("IsTaskSelected");

}

}

private RelayCommand _resolveTaskCommand;

public RelayCommand ResolveTaskCommand

{

get

{

if (_resolveTaskCommand == null)

{

_resolveTaskCommand = new RelayCommand(Resolve, CanResolve);

}

return _resolveTaskCommand;

}

set { _resolveTaskCommand = value; }

}

void Resolve()

{

SelectedTask.Resolved = true;

db.SaveChanges();

}

bool CanResolve()

{

return SelectedTask != null && !string.IsNullOrEmpty(SelectedTask.Solution);

}

public bool IsTaskSelected

{

get

{

return SelectedTask != null;

}

}

public bool HasPermissionResolveTask

{

get

{

return AppSecurity.Role == Roles.Technician;

}

}

public bool CanRegisterUser

{

get

{

return AppSecurity.Role == Roles.Admin;

}

}

public bool CanAddTask

{

get

{

return AppSecurity.Role == Roles.Client;

}

}

private RelayCommand _addTaskCommand;

public RelayCommand AddTaskCommand

{

get

{

if (_addTaskCommand == null)

{

_addTaskCommand = new RelayCommand(DisplayTaskDialog);

}

return _addTaskCommand;

}

set { _addTaskCommand = value; }

}

void DisplayTaskDialog()

{

var view = new TaskUI();

var vm = new TaskViewModel();

view.DataContext = vm;

view.ShowDialog();

}

private RelayCommand _registerCommand;

public RelayCommand RegisterCommand

{

get

{

if (_registerCommand == null)

{

_registerCommand = new RelayCommand(DisplayRegisterDialog);

}

return _registerCommand;

}

set { _registerCommand = value; }

}

void DisplayRegisterDialog()

{

var view = new RegisterUI();

var vm = new RegisterViewModel();

view.DataContext = vm;

view.ShowDialog();

}

}

}

Размещено на Allbest.ru