Мы часто говорим о благотворном влиянии ServiceNow на бизнес.
Согласно цифрам, которые предоставляет сама компания, платформа повышает продуктивность операционной деятельности на 47%, снижает простои из-за незапланированных инцидентов на 39% и ускоряет их разрешение на 21%.
Но пора признать — всегда есть ложка дегтя, которая скрывается в последствиях ошибок на этапе внедрения. Например, специалист по развертыванию платформы Шива Томас (Shiva Thomas) рассказывает, что неверное обращение лишь с одним элементом может увеличить издержки в четыре раза.
Поэтому в этой статье, написанной в формате «вредных советов», мы рассмотрим, каких ошибок стоит избегать на этапе внедрения ServiceNow.
/ Flickr / tableatny / CC
Говорят, что ITIL требует планового подхода? Но ведь время ценнее — приступайте к делу без промедления.
На самом деле, процесс внедрения ServiceNow нуждается в должном анализе затрат и — самое важное — в полноценном планировании. Компании должны сформировать связи и зависимости между различными ИТ- и бизнес-процессами. Крайне важно подключить к этому все заинтересованные стороны и конечных пользователей, чтобы проверить определенные возможности системы и посмотреть, как взаимодействуют ее элементы. Планирование требует постановки краткосрочных и долгосрочных целей, без которых бизнесу может быть нанесен ущерб.
Мишель Регейро (Michel Regueiro) из компании-партнера ServiceNow называет два подхода к процессу внедрения: «метод большого взрыва» и поэтапную реализацию. Первый описывает ситуацию, когда организация «одним щелчком» переключается со своей старой платформы на ServiceNow. Поэтапный подход описывает сценарий, в котором реализация выполняется серией заданных шагов.
«Большой взрыв» таит в себе более высокий уровень риска. Интегрированный характер ServiceNow означает, что сбой в одной части платформы может вызывать побочные эффекты в другом элементе. Поэтому правильным решением станет внедрение на уровне отдельных бизнес-единиц таким образом, чтобы привести всю организационную структуру к гармоничному способу функционирования.
Важный момент: задействованный персонал должен быть знаком с навигацией в ServiceNow и с процессами еще до внедрения. Людям также следует понимать, зачем нужны те или иные изменения и к какому результату они приведут.
/ Flickr / pxhere / CC
Давно известно, что чужой опыт для слабаков. Не смотрите по сторонам — работайте так, будто до вас никто не внедрял ServiceNow. Скорее всего, ваша организация совершит множество ошибок и потратит на их устранение немалую сумму. Но чувство самостоятельно проделанной работы — бесценно.
В действительности пользователями ServiceNow выступают сотни крупных компаний. Не у каждой из них этап внедрения прошел так гладко, как хотелось бы ответственным лицам. Опыт — как позитивный, так и негативный — накопился за годы работы и был зафиксирован в таких книгах, как «Mastering ServiceNow» от Мартина Вуда (Martin Wood).
Еще более ценно мнение людей, непосредственно участвовавших в развертывании платформы на предприятиях. Сообщество ServiceNow готово делиться своим опытом, рассказывать о тех ошибках на первоначальном этапе, которые позже могут стать причиной потерь.
Хотя внедрение платформы на различных предприятиях проходит по-разному, пользователи, уже столкнувшиеся с проблемами, расскажут, с каких отделов они начинали интеграцию, как привлекали сотрудников, не связанных с ИТ, и др.
Не каждая компания готова раскрывать все подробности «внутренней кухни», но, к счастью, есть такие крупные корпорации, как Fujitsu, которые без труда рассказывают о своем опыте внедрения ServiceNow.
Возможности ServiceNow огромны, и самой лучшей идеей будет опробовать их все и сразу.
Если серьезно, многие специалисты по внедрению платформы советуют «не уходить в сторону». ServiceNow как инструмент ITSM основана на лучших практиках и ITILv3, а, значит, функциональность платформы нацелена на наиболее эффективную работу. Но прежде чем вносить какие-то изменения, следует понять, как ServiceNow обрабатывает тот или иной процесс, поставить определенные цели и только после этого переходить к поиску решения.
На деле важно иметь прочную операционную структуру для технических и стратегических процессов. Часто этот аспект игнорируется. В самом начале следует определить круг управляющих лиц в организации, присвоить им зоны ответственности и на основании этого распределить права доступа. ServiceNow предлагает довольно полный список компетенций для всех уровней структуры — от менеджера проекта до владельца платформы — с описанием их обязанностей.
Свалить ответственность на третье лицо — это всегда большой соблазн. Но такой подход сулит лишь проблемы.
Директор по продажам в консалтинговой компании IV4 Тони Харрис (Tony Harris) поделился проблемой несоответствия ожиданий от работы со внешним партнером. Он приводил пример неудачных реализаций в организациях, которые считали, что консультант должен провести внедрение с нуля и самостоятельно разработать лучшие практики. В результате они получали некачественную работу платформы.
Вывод прост — консультант необходим, но он не должен работать автономно. На его стороне экспертиза и опыт, но для достижения высокого результата требуется задействовать внутренние ресурсы компании.
Еще один соблазн — начинать работу с простых задач, например, управления инцидентами, и только после этого переходить к более сложным.
Мало того, что такое распределение приоритетов способно вызвать недостаток ресурсов и сместить сроки исполнения, так и вся настраиваемая система может наполниться ошибками. Управление инцидентами и управление изменениями связаны друг с другом, и установление причин новых инцидентов будет затруднено без создания базы данных управления конфигурацией, которая отвечает за эту взаимосвязь.
Например, известно, что одна из попыток внедрения ServiceNow в Sony провалилась именно по причине неверного распределения приоритетов. Из своего неудачного опыта компания узнала, что сложный этап иногда следует ставить выше, чем простой.
/ Maxpixel / PD
ServiceNow — не место для развлечения и удобства, а полезный бизнес-инструмент, пользовательский опыт для которого находится где-то на третьем месте по значимости. Вовсе нет.
Пользователи привыкли работать с современными интерфейсами и ожидают подобного опыта от клиентского портала ServiceNow. Как отмечают читатели Reddit, сервисный портал — одно из лучших решений ServiceNow, и важно сделать все, чтобы пользователи как можно быстрее к нему привыкли.
Директор по стратегическим вопросам в ИТ-компании Atlantic Puffin Стив Джэкет (Steeve Jacquet) предлагает при проектировании пользовательского опыта учитывать такие вещи, как:
В связи с этим Стив советует адаптировать платформу к ожиданиям пользователя: как им удобнее взаимодействовать с продуктом или потреблять услуги. Он предлагает оптимизировать поисковые решения в базе знаний и службу поддержки посредством обмена мгновенными сообщениями.
Шива Томас также отмечает, что еще на этапе внедрения следует позаботиться о том, чтобы у пользователей было все для комфортной работы.
P.S. Вот еще несколько статей по этой теме в нашем блоге:
Согласно цифрам, которые предоставляет сама компания, платформа повышает продуктивность операционной деятельности на 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. Вот еще несколько статей по этой теме в нашем блоге: