Сервисные и IT-подразделения компаний парадоксально терпят неудачу после того, как начинают проекты внедрения лучших практик. К такому выводу я прихожу каждый раз, когда вижу систематическое повторение типичных ошибок в проектах автоматизации сервисного обслуживания, техподдержки и обеспечения бесперебойной работы точек продаж в рознице.
Наглядную статистику реализации IT-проектов демонстрирует исследование CHAOS 2020 Beyond Infinity, подготовленное The Standish Group. По данным этого исследования, из 50 тыс. IT-проектов по всему миру только 35% признаны успешными.
Почему так происходит? Ведь многие практики сервисного управления с последующей автоматизацией техподдержки действительно кажутся правдоподобными и логичными с высоты птичьего полета. Другие практики проверены миллионами компаний по всему миру и считаются стандартом. Однако стоит IT-директору или руководителю службы эксплуатации спуститься с небес на землю и начать проект в своей компании, он тут же спотыкается на каждом шаге. Все из-за того, что он следует вредным советам.
Я отобрал типовые вредные советы из своей многолетней практики, которых следует избегать, и решил поделиться рекомендациями, как это сделать.
1. Автоматизируйте все и сразу
Хотели автоматизировать процессы сервисного обслуживания и поддержки? Зачем на этом останавливаться? Включайте в охват проекта автоматизацию документооборота, складского и управленческого учета. Если вы работаете в розничной компании, то обязательно автоматизируйте сразу поддержку бэк-офиса, деятельность точек продаж и взаимодействие с посетителями. Конечно, все это нужно делать с помощью одной системы за бюджеты и сроки изначального проекта.
Я каждый день сталкиваюсь с желанием компаний реализовать проект, который в целом решит задачи всех подразделений. Однако проблема заключается даже не в том, что подобные проекты требуют уже отлаженных и формализованных процессов и интеграций между ними, зрелости, колоссальных бюджетов, соответствующих сроков. Проблема в том, что любой проект — это конкретные участники, заказчики, цели, задачи и результаты. В автоматизации без границ сами проекты рискуют остаться таковыми во всех смыслах. Хотя, возможно, некоторым этого и нужно.
2. Уникальные процессы требуют уникальных систем
Зачем вам какие-то лучшие практики или готовые инструменты, которыми пользуются сотни или тысячи компаний? Бизнес вашей компаний прошел свой уникальный путь, и именно поэтому он все еще существует. Сервисные процессы в вашей компании не похожи на другие, ведь вы их «оттачивали» на этом пути. А уникальные процессы требуют создания IT-решений, разработанные под вас или собственными силами.
На нашем рынке, действительно, есть компании с уникальным положением. Они со своими бюджетами могут позволить себе в рамках автоматизации набить шишки самыми разными способами. Но есть компании, которые по финансовой причине не могут себе позволить заказать создание уникальной системы, или самостоятельно ее разработать.
Случай из практики. Небольшая компания (менее десяти сотрудников в сервисной службе), которая для автоматизации процессов обслуживания своего оборудования запустила проект по доработке «Битрикс24» под свои требования. Проект закончился в момент получения стоимости реализации хотелок, которая оказалась для компании неподъемной.
Чтобы стать лидером на конкурентном рынке, не нужно разрабатывать систему под собственные бизнес-процессы. Можно используйте готовые и недорогие системы, которые позволяют сократить время от начала разработки идеи до выхода готового решения на рынок (Time to market), и быстро получить первые результаты.
3. Говорите всем за пределами сервисного и IT-департамента, что они ваши клиенты
Пусть все специалисты IT-департамента или службы эксплуатации называют других сотрудников компании «своими клиентами». «Моя работа — оправдать ваши ожидания». Или что еще хуже — «сделать вас счастливыми».
Такой позитивный подход может создать проблемы при выполнении поставленных бизнес-целей. Если сотрудники IT-департамента и службы эксплуатации так делают, другой персонал компании начнет относиться к ним как к одному из поставщиков. А значит, в случае необходимости персонал начнет искать более удобное для себя решение проблемы без помощи сотрудников IT-департамента или службы эксплуатации.
Идея «внутренних клиентов» к тому же ставит сотрудников из IT-отдела и службы эксплуатации в подчиненное и часто бессмысленное положение, что означает, что они должны в такой ситуации сделать своих коллег счастливыми независимо от того, имеет ли это пользу для бизнеса или нет.
4. Смейтесь над «внутренними клиентами»
— У меня не работает компьютер.
— Проверьте подключен ли он к розетке.
И это самый безобидный, но распространенный сценарий взаимодействия. Тут же рядом клички для «самых умных», ярлыки и стереотипы, сформированные из одного-двух случаев с неопытными сотрудниками.
Каждый из нас очень любит быть умнее другого. Но гораздо лучше использовать однотипные, пусть и простые вопросы не в качестве насмешки, а как повод для изменения процессов и облегчения взаимодействия между сотрудниками.
Заведите и наполните базу знаний в используемой help desk системе, распечатайте и установите перед каждым рабочим местом красивые и смешные напоминалки в виде буклетов о том, что делать в самых типовых ситуациях. Еще организуйте службу единого окна по любым вопросам. Делайте так, как хотите, чтобы другие относились к вам в непонятной для вас ситуации.
5. Не слушайте бизнес-заказчиков
Это совет звучит примерно так:
Ваши коллеги из отделов эксплуатации, маркетинга, развития и продаж — не очень технически грамотные и не знают, чего хотят. Поэтому не стоит даже тратить время на сбор и анализ их требований. Вы сами знаете, что и кому внутри компании нужно. К тому же при выборе подрядчика и системы автоматизации главное — не удобство работы бизнеса, а важно, чтобы внедренная «игрушка» позволяла не ударить в грязь лицом перед коллегами на какой-нибудь важной конференции.
Я годами слышу истории о том, как IT-департамент не хочет слушать своих коллег по бизнесу. В своей глубокой терминологии, аббревиатурах и фундаментальном образовании каждый айтишник прячется от неинтересных ему задач и проектов. Он хочет запускать амбициозные проекты, которые дорого стоят и длительны по времени реализации. И, конечно, только он в компании знает, как это делать. К сожалению, очень часто это приводит к внедрению систем, которыми никто не пользуется. В таких случаях бывает, что бизнес-заказчики вынуждены создавать внутри своих структур отделы автоматизации или вообще менять модель работы.
Случай из практики. В одной крупной компании отдел эксплуатации попросил директора IT-департамента внедрить простую help desk систему. Однако у IT-директора были более амбициозные планы: он хотел внедрить сложную корпоративную платформу. В итоге платформа была внедрена, но отделу эксплуатации было неудобно ее использовать в работе. Сотрудники этого отдела не растерялись и решили зарегистрировать отдельное юрлицо, чтобы внедрить в компании нужную им систему.
Кстати, мы ранее опубликовали материал Битва за инициативу: IT-руководитель против персонала, в котором обсуждали, что делать IT-директору, если сотрудникам не нравятся цифровые инструменты и технологии, которые им предоставляет компания для работы.
6. Настаивайте на окупаемости инвестиций
Настаивайте на том, что процесс управления IT и поддержки пользователей требует четкой и ощутимой финансовой отдачи от инвестиций. Это почти всегда гарантирует постепенное устаревание имеющейся инфраструктуры и используемых технологий.
При таком подходе сдвигаются сроки реализации критически важных проектов, которые помогают бизнес-подразделениям продавать больше при меньшей себестоимости. Это происходит из-за того, что еще не получена отдача от имеющихся активов.
7. Ограничьте свою зону ответственности в реализации IT-проекта
В проектах поставки, внедрения и интеграции ПО ограничивайте свою зону ответственности фактом закупки, которое удовлетворяет написанному ТЗ. Когда бизнес будет жаловаться, что новый сервис не помогает решить проблемы, ради которых его и создавали, вы сможете переложить ответственность на бизнес-заказчика, который сам писал ТЗ к требуемому ПО.
Такой подход увеличит сроки реализации IT-проекта и затраты на это дело. Поэтому лучше полностью брать ответственность за выполнение проекта, а не ограничивать себя поставкой ПО.
8. Ведите множество проектов одновременно
В IT-отделах никогда не хватает сотрудников, чтобы справиться со всеми задачами. Если хотите, чтобы проекты занимали больше времени, стоили дороже, заканчивались неудачей, запускайте множество проектов одновременно и перемещайте сотрудников между ними. Проводите больше совещаний, на которых можно собраться всем департаментом.
Чтобы у проектов автоматизации сервисного обслуживания и техподдержки был результат, важно не только выбить бюджет и определить ответственных. Гораздо важнее выдать ответственным полномочия для принятия решений. Если члены проектной команды могут только организовать совещание или пригласить на встречу очередного поставщика, проект рискует затянуться на долгие годы.
Читайте также:
