Мы часто говорим о благотворном влиянии ServiceNow на бизнес.

Согласно цифрам, которые предоставляет сама компания, платформа повышает продуктивность операционной деятельности на 47%, снижает простои из-за незапланированных инцидентов на 39% и ускоряет их разрешение на 21%.

Но пора признать — всегда есть ложка дегтя, которая скрывается в последствиях ошибок на этапе внедрения. Например, специалист по развертыванию платформы Шива Томас (Shiva Thomas) рассказывает, что неверное обращение лишь с одним элементом может увеличить издержки в четыре раза.

Поэтому в этой статье, написанной в формате «вредных советов», мы рассмотрим, каких ошибок стоит избегать на этапе внедрения ServiceNow.


/ Flickr / tableatny / CC

1. С места в карьер — забудьте про подготовку


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

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

Мишель Регейро (Michel Regueiro) из компании-партнера ServiceNow называет два подхода к процессу внедрения: «метод большого взрыва» и поэтапную реализацию. Первый описывает ситуацию, когда организация «одним щелчком» переключается со своей старой платформы на ServiceNow. Поэтапный подход описывает сценарий, в котором реализация выполняется серией заданных шагов.

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

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


/ Flickr / pxhere / CC

2. Делаем все самостоятельно


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

В действительности пользователями ServiceNow выступают сотни крупных компаний. Не у каждой из них этап внедрения прошел так гладко, как хотелось бы ответственным лицам. Опыт — как позитивный, так и негативный — накопился за годы работы и был зафиксирован в таких книгах, как «Mastering ServiceNow» от Мартина Вуда (Martin Wood).

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

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

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

3. Экспериментируем


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

Если серьезно, многие специалисты по внедрению платформы советуют «не уходить в сторону». ServiceNow как инструмент ITSM основана на лучших практиках и ITILv3, а, значит, функциональность платформы нацелена на наиболее эффективную работу. Но прежде чем вносить какие-то изменения, следует понять, как ServiceNow обрабатывает тот или иной процесс, поставить определенные цели и только после этого переходить к поиску решения.

4. Пусть структура управления строится сама собой


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

5. Полностью положитесь на стороннего консультанта


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

Директор по продажам в консалтинговой компании IV4 Тони Харрис (Tony Harris) поделился проблемой несоответствия ожиданий от работы со внешним партнером. Он приводил пример неудачных реализаций в организациях, которые считали, что консультант должен провести внедрение с нуля и самостоятельно разработать лучшие практики. В результате они получали некачественную работу платформы.

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

6. Отложите все самое сложное на потом


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

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

Например, известно, что одна из попыток внедрения ServiceNow в Sony провалилась именно по причине неверного распределения приоритетов. Из своего неудачного опыта компания узнала, что сложный этап иногда следует ставить выше, чем простой.


/ Maxpixel / PD

7. Не пытайтесь облегчить жизнь пользователей


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

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

Директор по стратегическим вопросам в ИТ-компании Atlantic Puffin Стив Джэкет (Steeve Jacquet) предлагает при проектировании пользовательского опыта учитывать такие вещи, как:

  • Полезность — как портал отвечает потребностям пользователей.
  • Юзабилити — насколько портал прост в использовании.
  • Целесообразность — соответствие ожиданиям пользователя.
  • Доступность — насколько просто найти требуемый контент.
  • Достоверность — уровень экспертизы, прозрачность предоставленных данных.

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

Шива Томас также отмечает, что еще на этапе внедрения следует позаботиться о том, чтобы у пользователей было все для комфортной работы.



P.S. Вот еще несколько статей по этой теме в нашем блоге:

Комментарии (0)