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

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

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

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

Давайте с примером, для руководителя подразделения аналитики и отчетности, который развивает портал отчетности компании. Для CJM выделим следующие этапы при соприкосновении с пользователями:

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

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

Для создания CJM используем Excel, но если хочется “повкуснее”, доступны специализированные сервисы, например https://uxpressia.com

Ниже пример заполнения таблицы пути внутреннего заказчика.

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

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

Результатом исследования будет таблица:

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

Рассмотрим пример, для руководителя подразделения эксплуатации. Последний раз обсуждая вопрос ценности получила ответ: "Мы решаем инциденты". Нужно ли решение инцидентов бизнесу? Конечно это важный процесс, но бизнесу не нужно решение инцидентов. Бизнесу важно чтобы  процессы работали.

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

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

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

• Доступность и скорость работы системы .
• Своевременность решения запросов по работе с системой.
• Удобство использования работы.
• Скорость внесения изменений.

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

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

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

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

1. Описать продукты и услуги по единой форме. Пример описания рассмотрен ниже.
2. Определить уровень сервиса и закрепить в SLA или другим нормативным документом.
3. Сделать доступным информацию о продуктах и услугах.
4. Автоматизировать подачу запросов и инцидентов через service desk, чтобы отслеживать своевременность выполнения, управлять затратами и оценивать качество работ по оценке пользователей или другим измеримым метрикам свойственным услуге.

Ключевые принципы описания услуги:

• Простота, отсутствие сокращений и непонятных слов

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

• Единый стиль и формат описания каждой услуги (желательно этот формат определить на уровне ИТ-подразделений, а еще лучше - на уровне компании)

Ниже приведен пример описания сервиса.

Давайте разберем что такое Service Level Agreement.

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

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

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

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

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

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

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

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

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

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

“Медленно”, “не работает”, “некачественно” должны превратиться в цифры закрепленные в SLA. Определите и оцифруйте оценочные суждения в факты, по результатам месяца измерений обсудите с заказчиком отчет содержащий информацию о результатах работы, скорости и доступности процессов. Опираясь на цифры совместно оцените текущий уровень сервиса. На встрече с заказчиком соберите обратную связь о соответствии ожиданиям, удовлетворенности результатом. Запланируйте шаги по улучшению и определите приоритеты. При необходимости улучшений требующий дополнительного финансирования совместно с заинтересованным заказчиком готовьте оценку и готовьте материалы на защиту для выделения ресурсов.

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

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

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

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

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

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

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

• Имя заинтересованного или принадлежность к роли
• Значимость коммуникации (Критичная – “Тесно взаимодействуйте”; Высокая – “Поддерживайте допольными”; Средняя – “Держите в курсе”; Низкая – “Отслеживайте”)
• Ключевые интересы и события
• Статус взаимодействия - амбассадор, поддерживает, нейтральный, оппонент
• Ожидаемая поддержка - высокая, средняя, низкая
• Ожидаемые активности по улучшению
• Ожидаемые сообщения
• Форма и частота коммуникации

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

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

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

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

В первую очередь определите причины, почему возникают эскалации.

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

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

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

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

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

На плановую встречу с руководителем подготовьте дополнительные слайды резюмирующие достижения. Опишите достижения, как изменилась зона и объем решаемых задач, выполнение принятых в компании KPI. Достижения должны быть оцифрованы. Не “повысил эффективность”, а конкретно “затраты на подразделения снизились на 5%”, не “увеличил качество работы”, а по оценке пользователей удовлетворенность выросла с 4,5 до 4,9

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

Чтобы оценить адекватность запросов о прибавке заработной платы необходимо:

• провести анализ текущих зарплат должности и квалификации. Это можно сделать на сайтах вакансий и резюме, а также на специализированных аналитических сайтах, таких как https://www.hays.com
• оценить возможности компании, если в компании кризис и идут сокращения, то маловероятно, что удастся в такой момент получить рост зарплаты
• ознакомиться с регламентами по изменению условий оплаты труда, мотивации, понять какой вариант мотивации подходит, будьте готовы предложить возможный вариант мотивации и выделения средств, это будет прибавка к окладу или мотивационной части

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

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

По результату встречи зафиксируйте договоренности в письменной форме и направьте письмо руководителю с итогами встречи.