Стивен Манн

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

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

1. Изменение характера инцидентов и запросов на обслуживание

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

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

Что делать: пересмотреть роль службы поддержки пользователей.

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

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

2. Повышение расходов на оплату труда специалистов по поддержке пользователей

Расширение и изменение набора навыков сотрудника службы поддержки приведет к следующему:

• сотрудники службы поддержки станут более дорогим ресурсом (хотя при этом их нужно будет меньше);
• более актуальной и сложной станет проблема удержания персонала — здесь в полной мере действует закон спроса и предложения;
• службам поддержки станет сложнее вводить в курс дела новых сотрудников, даже когда у них есть нужные навыки. Для передачи деловых и технических знаний необходимо будет активнее пользоваться системами управления знаниями.

Что делать: приучиться больше ценить сотрудников службы поддержки пользователей.

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

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

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

3. Сокращение численности персонала приведет к тому, что службы поддержки будут менее гибкими

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

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

Что делать: работать умнее, а не интенсивнее.

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

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

Чтобы работать умнее, а не интенсивнее, нужно изучить возможности автоматизации самообслуживания, службы поддержки и управления эксплуатацией ИТ (IT Operations Management, ITOM), а также использования метода инцидентов, решаемых на нулевом уровне (Level Zero Solvable, LZS).

Разъяснить его меньше чем в 100 словах сложно, поэтому, если есть время, лучше ознакомиться с документом http://www.thinkhdi.com/~/media/HDICorp/Files/Library-Archive/Insider%20Articles/WhatIsLZS.pdf. Говоря упрощенно, LZS — это показатель количества поступивших в службу поддержки заявок, которые можно выполнить, пользуясь информацией из портала самообслуживания.

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

4. Влияние на операционную деятельность компании

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

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

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

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

• повышение скорости/результативности,
• снижение затрат,
• улучшение качества обслуживания.

Когда есть возможность что-то автоматизировать, можно получить и другие преимущества:

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

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

• Улучшение функций поиска — интеллектуальный поиск выдает релевантные результаты с высокой точностью.
• Предоставление персональных рекомендаций — наподобие тех, что получают пользователи Amazon и Netflix.
• Создание интеллектуальных автоответчиков — высококачественное выполнение заявок автоматизированными системами без участия человека.
• Выявление и устранение пробелов в знаниях — обнаружение случаев нехватки информации в базе знаний и преобразование задокументированных процедур выполнения заявок в новые знания.

5. Существенное изменение метрик и целевых показателей

Метрики и целевые показатели службы поддержки пользователей придется пересмотреть.

• С внедрением портала самообслуживания объемы заявок должны снизиться.
• Число выполнений заявок при первом обращении (first contact resolution, FCR) может резко упасть; возможно, данный показатель вообще потеряет смысл.
• Среднее время работы по заявке увеличится, сами заявки станут в целом более сложными.
• Понадобятся новые метрики.

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

Что делать: пересмотреть и перекалибровать метрики.

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

6. Успех портала самообслуживания может привести к снижению ценности отдела ИТ в глазах бизнес-руководства

Оценивать результативность отдела ИТ и его восприятие в глазах бизнеса всегда сложно. И здесь на ум приходит такой показатель, выведенный довольно давно одной из аналитических компаний: служба поддержки пользователей на 50% определяет отношение бизнеса к корпоративному отделу ИТ. Если это так, оценка бизнесом отдела ИТ в целом может легко упасть при снижении объема непосредственных контактов с сотрудниками службы поддержки.

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

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

7. Ухудшение и утрата взаимоотношений с бизнес-заказчиками

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

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

Что делать: инвестировать в улучшение управления взаимоотношениями.

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

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

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

8. Самообслуживание — это «юбилей с отложенной датой»

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

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

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

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

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

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

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

Разумеется, в проекты самообслуживания инвестировали не все участники опроса: по данным SDI, внедрили соответствующие технологии около 80%, то есть, судя по количеству жалующихся на низкий уровень их использования, это примерно половина тех, кто провел внедрение; при этом возможно, кто-то просто не признал, что страдает из-за неиспользования.

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

Не сравнивайте несопоставимое

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

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

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

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

Шесть рекомендаций по внедрению средств самообслуживания

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

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

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

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

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

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

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

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

В одной из своих заметок на freshserviceblog я обрисовал, что представляет собой «управление сервисами предприятия» (Enterprise Service Management, ESM), чем объясняется его растущая популярность и в чем его преимущества.

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

Конечно, есть рекомендации, которые зачастую выдают за лучшие или по крайней мере хорошие практики. Сегодня «сценарии» управления корпоративными сервисами рекламируют и продают многие поставщики инструментов ITSM, а их знания и опыт, накопленные в процессе реализации предыдущих клиентских инициатив, воплощаются в «наилучшие советы» по правильному управлению корпоративными сервисами.

Однако откладывать планирование процесса управления сервисами предприятия из-за недостатка имеющихся ресурсов нельзя.

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

Опрос, проведенный HDI в 2014 году, показал: 51% респондентов уже внедряют принципы ITSM вне сферы ИТ или же планируют в скором времени заняться этим. Согласно результатам опроса, организованного Service Desk Institute в 2015 году, 55% респондентов планировали «управление совместно используемыми сервисами», то есть управление сервисами предприятия.

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

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

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

1. Не относитесь к управлению корпоративными сервисами как к ИТ-проекту.

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

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

2. Учитывайте различия.

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

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

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

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

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

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

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

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

5. Тщательно и без спешки продумайте реализацию проекта управления корпоративными сервисами.

Управление корпоративными сервисами в масштабах всего предприятия – очень объемная задача, поэтому подход «большого взрыва» представляется слишком сложным и рискованным. Рекомендуется начать с малого, сосредоточившись на каком-то одном бизнес-подразделении или нескольких новых функциях.

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

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

- Стивен Манн, руководитель и директор по контенту аналитической компании ITSM.tools. Помимо работы в ней он занимается подготовкой маркетинговых материалов по ИТ и управлению ИТ-сервисами. Ведет регулярно обновляемый блог, является автором ряда книг, выступает на отраслевых мероприятиях с докладами, посвященными проблематике управления ИТ-сервисами.