Рынок обслуживания и ремонта оборудования – консервативный. Многие уверены, что никаких изменений здесь не может быть в принципе. Ну в самом деле, что тут менять: сломался станок, холодильник или кондиционер, нужно ехать чинить. Работай лучше, клиент оставит хорошие отзывы, будет больше заказов, можно поднять цены на ремонт. Вот и весь бизнес.
Потом вдруг кто-то из конкурентов начинает работать «не как все». И цены ниже, и время ремонта меньше, и приезжают его техники быстрее. Клиенты это замечают и у других компаний возникают проблемы. Что случилось, откуда такие изменения? Да все понятно, они поставили себе FSM-систему, давайте мы тоже себе установим, и у нас будет то же самое. Купили лицензии, настроили, стали работать – а ничего не меняется. В самом деле, заявки на ремонт можно и в Telegram пересылать, как раньше делали, бесплатно, а других преимуществ не видно.
Как настроить IT-систему под задачи компании
Дело в том, что любая IT-система – инструмент, который нужно правильно использовать. А для правильного использования нужна технология внедрения такой системы и настройки под задачи компании. Такие настройки IT-специалисты сделать не могут, потому что не разбираются в управлении компанией. А руководители компании не понимают возможностей IT-системы, у них нет времени разбираться. Тут нужен специалист, имеющий знания и в IT и в бизнесе, с опытом управления организацией и выполнения похожих проектов.
Те изменения, которые клиенты и конкуренты видят в компании – всего лишь «вершина айсберга». И начались они, скорее всего, несколько месяцев назад с аудита сервиса, разработки стратегии улучшений и настройки сервиса под задачи ключевых клиентов, тех самых 20%, которые приносят 80% прибыли. Потом был подготовлен детальный план действий, рассчитан бюджет и плановые показатели эффективности (KPI), бизнес-процессы смоделированы, оптимизированы и занесены в IT-систему. Для сотрудников было проведено обучение управлению «по цифрам», а сам сервис перешел из режима «реактивной работы», когда проблемы в организации решаются после их возникновения, к «проактивному режиму», когда на основе анализа данных, собираемых IT-системой, проблемы в сервисе предсказываются и решаются задолго до того, как вызвали недовольство и отток клиентов.
Что такое проактивный режим работы сервиса
В проактивном режиме можно отслеживать множество показателей: загрузку сотрудников, использование рабочего времени, удовлетворенность клиентов, среднее время выполнения процессов и отдельных его стадий. Плановые показатели (KPI) уже привязаны к бонусам ответственных сотрудников, а зоны ответственности при работе с клиентом четко разделены. В процессах нет «узких мест» и перегрузка отдельных сотрудников не «тормозит» развитие бизнеса.
Набор новых сотрудников происходит при превышении установленного коридора загрузки таким образом, что новые люди проходят обучение и включаются в работу, когда загрузка существующих достигает верхней границы коридора. При этом набор не нужно согласовывать с руководством: все управленческие решения приняты на этапе формирования бюджета и совпадение плановых KPI с фактическими означает, что они остаются в силе.
Важным элементом проактивной работы является мотивация сотрудников. Причем не только к выполнению ежедневной, рутинной работы, но и к профессиональному развитию. Поэтому организация проактивной работы предполагает аттестацию и построение матрицы знаний (Skill Matrix). Достижение определенного уровня сотрудником (количество баллов по знанию оборудования) приводит к присвоению более высокой категории и повышению оклада. При этом учитывается знание не просто любого оборудования, а моделей, по которым есть недостаток специалистов. План обучения согласуется с каждым техником и его руководителем индивидуально. Таким образом, производится привязка долгосрочных целей сотрудника к целям компании, в то время как «ежедневная рутинная» работа привязана к KPI.
Помимо мотивации сотрудников Skill Matrix помогает автоматизировать функции диспетчера и настроить автоматическое распределение заявок. У сервиса как бизнеса есть два ограничения: рынок и ресурсы, причем чаще всего срабатывает второе. Если диспетчер «тормозит» процессы, а нового сотрудника брать в помощь еще рано, автоматизация распределения заявок позволяет сэкономить до 40% его времени. Кроме распределения заявок, в сервисе можно автоматизировать и множество других функций: от заполнения отчетов и актов выполненных работ, до заказа запчастей.
Таким образом, видимые изменения в сервисе и сопутствующий рост чаще всего означают, что компания успешно решила две важные задачи сервиса:
- Снизила себестоимость работ за счет оптимизации бизнес-процессов и автоматизации отдельных функций.
- Обеспечила высокое качество сервиса за счет контроля, эффективного использования ресурсов и предотвращения проблем с клиентами. Такое возможно только в «проактивном» сервисе, управляемом «по цифрам».
Если подобные изменения происходят у ваших конкурентов, не нужно думать, что это случайность и скоро все станет как прежде. Для вас скорее станет только хуже, поскольку по мере накопления информации, собираемой IT-системой, конкуренты смогут корректировать первоначальную стратегию, все больше подстраиваясь под задачи ключевых клиентов и максимально повышая операционную эффективность. Ждать здесь точно не стоит – нужно действовать. Возможно, эта статья поможет вам осознать проблему. Изменения проходят все быстрее и цифровизация, начавшись в больших компаниях, уже добралась до сервиса в малом и среднем бизнесе.
Также читайте:
TPM = Technical Project Manager.
Нужен в орг.структуре проекта, если проект технически сложен, а PM должен фокусироваться на нетехнических задачах.
В данном случае будущий TPM мог бы с пользой для дела участвовать в обсуждении условий конкурса и подписания договора.
Благодарю! Нет, такого человека не было. Это хорошая идея! Я нигде не встречал такого. Но вбиты в голову отказ от лидирующей роли ИТ сделал своё чёрное дело. TPM хорош, но боюсь, что и его не стали бы слушать. Сначала работает конкурсная команда с задачей пробить выигрышь. Чаще всего общие требования для ТЗ уже готовы, уже на всё согласны.
Характерна статья на одном из популярных сайтов:
"Главное требование к идеальному проектному менеджеру в сферическом вакууме можно обозначить так: для достижения качественного результата он должен понимать специфику разработки ПО, инструментарий, методы тестирования, инструменты системного анализа, а иногда и особенности архитектуры продукта".
И добавляется "обязательное требование - квалификация по управлению проектами, сертификат подтверждает знание специалистом методологий, специального ПО, планирования, контроля изменений, реализации и завершения проекта, регулярное повышение квалификации...имеет сертификат по Agile-методологии и ее фреймворкам. ...Это могут быть как разработчики, которые выполняли дополнительно функцию Scrum Master, так и Team Lead команды разработки - они лучше всех представляют, как распределяется нагрузка в команде, и смогут правильно расставить приоритеты".
Идея "не доверяйте внедрение программисту" победила. Безусловно, планирование и знаиие методик важно и нужно. Понимание внутренних процессво разработки тоже. Умение распреелять нагрузку - да! Сертификат - отлично! Но из треугольника целей выбрана только одна приоритетной - стоимость!
Уже на всё согласны - может оказаться себе дороже. Специалистов нужно слушать. Назовем такого специалиста TPM или иначе, не так важно - это функция.
Если мы остаемся в области разработки и внедрения IT систем (+/- интеграция, кастомизация и пр.), то остановимся - на минуту - на требование к умению планировать из Вашего списка выше.
Это умение подразумевает (для начала) правильное понимание того, как работать в проекте на уровне его содержания - Scope. Иначе планировать просто нечего - включая бюджет, ресурсы и продолжительность работ. Любой опытный PM об этом хорошо знает.
Сегодня вообще большие проблемы с ИТ-специалистами.
Вчерашние студенты из SkillBox'ов заполонилирынок и биржи фрилансеров.
Один мой заказчик умудрился 3 раза вляпаться во фрилансерские истории, что
- Сайт будет красивым, информативным и юзабельным! И конечно, конечно же в срок!
Только словами все это и заканчивалось. 3 раза.
Потом моя команда полностью переработала дизайн (с учетом обновленного бренд-бука), запилили добротный front-end и back-end, захостили и вуа-ля!
Он нас до сих пор на руках носит. Да, дороже вышло. Но, как известно, скупой платит. Всегда и по-многу)