Рынок обслуживания и ремонта оборудования – консервативный. Многие уверены, что никаких изменений здесь не может быть в принципе. Ну в самом деле, что тут менять: сломался станок, холодильник или кондиционер, нужно ехать чинить. Работай лучше, клиент оставит хорошие отзывы, будет больше заказов, можно поднять цены на ремонт. Вот и весь бизнес.
Потом вдруг кто-то из конкурентов начинает работать «не как все». И цены ниже, и время ремонта меньше, и приезжают его техники быстрее. Клиенты это замечают и у других компаний возникают проблемы. Что случилось, откуда такие изменения? Да все понятно, они поставили себе FSM-систему, давайте мы тоже себе установим, и у нас будет то же самое. Купили лицензии, настроили, стали работать – а ничего не меняется. В самом деле, заявки на ремонт можно и в Telegram пересылать, как раньше делали, бесплатно, а других преимуществ не видно.
Как настроить IT-систему под задачи компании
Дело в том, что любая IT-система – инструмент, который нужно правильно использовать. А для правильного использования нужна технология внедрения такой системы и настройки под задачи компании. Такие настройки IT-специалисты сделать не могут, потому что не разбираются в управлении компанией. А руководители компании не понимают возможностей IT-системы, у них нет времени разбираться. Тут нужен специалист, имеющий знания и в IT и в бизнесе, с опытом управления организацией и выполнения похожих проектов.
Те изменения, которые клиенты и конкуренты видят в компании – всего лишь «вершина айсберга». И начались они, скорее всего, несколько месяцев назад с аудита сервиса, разработки стратегии улучшений и настройки сервиса под задачи ключевых клиентов, тех самых 20%, которые приносят 80% прибыли. Потом был подготовлен детальный план действий, рассчитан бюджет и плановые показатели эффективности (KPI), бизнес-процессы смоделированы, оптимизированы и занесены в IT-систему. Для сотрудников было проведено обучение управлению «по цифрам», а сам сервис перешел из режима «реактивной работы», когда проблемы в организации решаются после их возникновения, к «проактивному режиму», когда на основе анализа данных, собираемых IT-системой, проблемы в сервисе предсказываются и решаются задолго до того, как вызвали недовольство и отток клиентов.
Что такое проактивный режим работы сервиса
В проактивном режиме можно отслеживать множество показателей: загрузку сотрудников, использование рабочего времени, удовлетворенность клиентов, среднее время выполнения процессов и отдельных его стадий. Плановые показатели (KPI) уже привязаны к бонусам ответственных сотрудников, а зоны ответственности при работе с клиентом четко разделены. В процессах нет «узких мест» и перегрузка отдельных сотрудников не «тормозит» развитие бизнеса.
Набор новых сотрудников происходит при превышении установленного коридора загрузки таким образом, что новые люди проходят обучение и включаются в работу, когда загрузка существующих достигает верхней границы коридора. При этом набор не нужно согласовывать с руководством: все управленческие решения приняты на этапе формирования бюджета и совпадение плановых KPI с фактическими означает, что они остаются в силе.
Важным элементом проактивной работы является мотивация сотрудников. Причем не только к выполнению ежедневной, рутинной работы, но и к профессиональному развитию. Поэтому организация проактивной работы предполагает аттестацию и построение матрицы знаний (Skill Matrix). Достижение определенного уровня сотрудником (количество баллов по знанию оборудования) приводит к присвоению более высокой категории и повышению оклада. При этом учитывается знание не просто любого оборудования, а моделей, по которым есть недостаток специалистов. План обучения согласуется с каждым техником и его руководителем индивидуально. Таким образом, производится привязка долгосрочных целей сотрудника к целям компании, в то время как «ежедневная рутинная» работа привязана к KPI.
Помимо мотивации сотрудников Skill Matrix помогает автоматизировать функции диспетчера и настроить автоматическое распределение заявок. У сервиса как бизнеса есть два ограничения: рынок и ресурсы, причем чаще всего срабатывает второе. Если диспетчер «тормозит» процессы, а нового сотрудника брать в помощь еще рано, автоматизация распределения заявок позволяет сэкономить до 40% его времени. Кроме распределения заявок, в сервисе можно автоматизировать и множество других функций: от заполнения отчетов и актов выполненных работ, до заказа запчастей.
Таким образом, видимые изменения в сервисе и сопутствующий рост чаще всего означают, что компания успешно решила две важные задачи сервиса:
- Снизила себестоимость работ за счет оптимизации бизнес-процессов и автоматизации отдельных функций.
- Обеспечила высокое качество сервиса за счет контроля, эффективного использования ресурсов и предотвращения проблем с клиентами. Такое возможно только в «проактивном» сервисе, управляемом «по цифрам».
Если подобные изменения происходят у ваших конкурентов, не нужно думать, что это случайность и скоро все станет как прежде. Для вас скорее станет только хуже, поскольку по мере накопления информации, собираемой IT-системой, конкуренты смогут корректировать первоначальную стратегию, все больше подстраиваясь под задачи ключевых клиентов и максимально повышая операционную эффективность. Ждать здесь точно не стоит – нужно действовать. Возможно, эта статья поможет вам осознать проблему. Изменения проходят все быстрее и цифровизация, начавшись в больших компаниях, уже добралась до сервиса в малом и среднем бизнесе.
Также читайте:
Жаль, что статья коротковатая. Статья важная.
Начну с цитаты:
для правильного использования нужна технология внедрения такой системы и настройки под задачи компании. Такие настройки IT-специалисты сделать не могут, потому что не разбираются в управлении компанией. А руководители компании не понимают возможностей IT-системы, у них нет времени разбираться.
И поспорю.
Много лет наших "ИТ-специалистов" вплющивали в очень узкие рамки. Чаще всего это шло, на мой взгляд, от телевизионного образа айтишника - бегает какой-то лохматый и чинит нам компьютеры. Попытки кричать, что задачи айтишника гораздо шире ни к чему не привели, а только сделали ситуацию ещё хуже. Теперь айтишник стал очень узким специалистом, чаще всего программистом с ограниченным "фонтом работ". Кто из них сейчас знает Си? Кто сможет написать программу на каком-нибудь ассемблере, мнемокоде? У них в загашнике "Питон" и он их прекрасно кормит.
Ещё айтишник в головах людей - это сисадмин. Это смешное слово для простого народа стало уже почти понятным. "Серёжа, у меня интернет не работает".
И на фоне такого подхода за внедрение беруться кто угодно, только не айтишники. И лет двадцать я слышу подобные призывы: "Не дверяйте внедрение айтишникам". Только вот те же лет 20-30-40 назад для айтишника нужен был в первую очередь кругозор. И в финансах, и в налоговом учёте, и в управлении станками, и в управлени организацией. Именно программисты могли коррдинировать другие службы. Именно они могли стать связующим звеном при внедрении каких-то систем. Ну не финансистам же это внедрять с их вечными глупостями с KPI. Не неким руководителям поектов, один из которых мне как-то сказал, что ему всё равно, что строить - ИТ систему или новый мост через речку. Всё это унего просто "проэкт". Таких полно!
И от этого очень странно слышать, что "руководители компании не понимают возможностей IT-системы". Люди!!! 21 век на дворе! Руководители закончили церковно-приходскую школу? Или они после 7 класса средней школы по-блату назначены директорствовать? А если он не разбирается в устройстве автомобиля, то не будет на них ездить, да?
Отдайте проблемы ИТ-систем программистам (с широким кругозором), отдайте айтишникам! И даже "сисадминам", хотя название и правда смешное. Дайте им возможнослть работать по своему профилю. Не дверяйте всяго рода временщикам с дипломами финансиста, юриста- неудачика, а особено внедрюкам из всякого рода бизнес-школ. Только профессиональный айтишник может увидеть будущее ИТ-системы, только он сможет сэкономить на оборудовании, если ему доверять. И заставьте, как в былые времена программистов учиться, учиться настоящим образом! Кроме питона и джавы-скрипта они должны интересоваться и прочими сторонами жизни. Иначе они не программисты, а кодировщики, халтурщики.
Дорогие мои коллеги-программисты! Возьмите власть в свои руки! У вас самый широкий кругозор! Только знание внутреннего устройчства объекта позволит вам писать хорошие программы, а не штукатурные работы по внедрению всякого рода модных библиотек, СУБД и чужих примочек.
)))))))))))
Анатолий, спасибо за комментарий такой развернутый. Прям чувствуется "крик души" IT специалиста c большим опытом. Но все же не соглашусь с Вами. Может быть, 20 лет назад IT специалисты были универсальными и обязаны были иметь широкий кругозор. Сейчас IT продукты очень сложные. И требуется узкая специализация чтобы качественно делать свою работу. Я сам работаю в IT компании. Сначала как партнер, сейчас отвечаю за направление консалтинга и подготовки к автоматизации. У нас 70 человек - разработчики, тестировщики, дизайнеры, маркетологи, продавцы. Есть специалисты, которые могут провести интервью, описать процессы клиента "как есть" и даже предложить небольшие улучшения процессов сервиса, на основе своего опыта и участия в подобных проектах. Но во-первых это личный опыт человека, а не "лучшие практики" передовых компаний. Во-вторых сервис - это не только процессы. Это еще и бизнес - модель и система KPI. Это мотивация сотрудников, профессиональное развитие, аттестация, маркетинг, продажи услуг, бюджетное планирование. Все это связано и все учитывается при разработке программы улучшений после аудита. Чтобы разработать и реализовать программу улучшений в бизнесе нужно иметь опыт управления подобным бизнесом. 99% IT специалистов такого опыта не имеют. Да им и не нужно.
У руководителя очень много задач. Главная из них - продажи, развитие бизнеса. А еще поддержка продаж, сервис. И маркетинг. И бухгалтерия. И склад, логистика. Управление персоналом. Очень много всего. Конечно, на определенном уровне современные руководители разбираются и в возможностях IT систем. В тех, которые несут очевидные плюсы бизнесу: снижение трудозатрат, ускорение процессов, обратная связь с клиентами. Но я в статье рассказывал, как используют аналитику IT систем для оценки эффективности внутренних процессов и разарботки улучшений. Что с помощью этой аналитики можно перейти от "реактивной" работы сервиса (когда проблемы решаются с задержкой и с потерей клиентов, недовольных сервисаом) к "проактивной" - когда проблемы внутри сервисной организации выявлятся заранее, до того, как привели к негативу и оттоку клиентов. И вот эти инструменты IT систем руководители малого и среднего бизнеса обычно не используют и не понимают их возможности. Но это действительно сложно. И требует определенной зрелости бизнеса. Иначе у нас бы все сервисные подразделения работали в "проактивном" режиме.
Глас вопиющего. Вспоминается песня классика. Но не так всё ужасно, зависит от функционала, отрасли, регулятора и т.д. - если мы о больших системах.
Внедрение IT системы - это проект, иногда довольно длительный. Отдайте сбор и формулирование требований к будущей системе бизнес-аналитикам, хорошим программистам - программирование, внедрение - опытному менеджеру проекта, а текущее администрирование - ... (подставьте правильное слово).
Результат не гарантирован, но шансы на успех повысятся.
А я согласен с Вами, Максим! И благодарю за оценку!
Довольно сложно дать один совет на все случаи разработки и внедрения. Но беда, на мой взгляд, в том, что почувствов лёгкость денег в ИТ, к нам пришло очень много не совсем компетентных людей. Людей, которые не видят развитие технологий, пользуются торговыми представлениями об ИТ- системах.
Помните, лет 15 назад были две взаимоисключающие дискуссии, довольно шумные. Первая - "Не двоеряйе внедрение программистам" и "Хаос автоматизировать нельзя". Сколько копий сломали! В результате победили в большей части сторонники первой.
И вы правы, на мой взгляд, в том, что 99 % ИТ специалистов такого опыта не имеют. Теперь не имеют. С громадным расширением набора технологий появилась потребность в сужении навыков. Это факт, да!
Тем не менее. Было модным проводить аналогии в ИТ со строительством. Действительно в проектах строительства и ИТ-разработок много общего. Но там, в стройке, роль архитектора так и сохранилась. И ему нужно строительное образование, а не просто понимание проектной и дизайнерской работы. Иначе знание "лучших практик" будет приводить к излишней трате ресурсов, к непредсказуемому результату. Вряд ли будете отрицать, что огромное количество функционала ИТ-систем так и остаётся невостребованным. Огромное количество проектов внедрения заканчивается провалом.
Один из моих последних проектов был в создании системы мониторинга сетевых ресурсов одной огромной структуры связи - огромный набор различных оконечных устройств, разного "возраста", разных протоколов. Кончился полным провалом, судами, издержками. А команде условных программистов провал был виден в самом начале работы.
Я просто убеждён, что надо было давать соответсвующее образование, подготовку ИТ-специалистам, вместо того, чтобы привлекать тех, кто не очень разбирается в ИТ. Или основынм требованием при формировании команды должно быть довольно глубокое знание технологий.
Напишу может быть абсурдную вещь, но ведь в ИТ не так много поменялось. Как было два метода получения данных в вебе, так и осталось. Добавилсь библиотеки. Оптимизировались когда-то забытые методы. Резидентные базы данных стали снова реальностью. То, что лет 20 считалось отступлением от правил, теперь входит в стандарт СУБД - имею в виду аналитически базы данных. Человек, занимающийся разработкой и внерением ИТ должне ориентироваться в динамике технологий.
Да, согласен. Но это и беда наша. Но я люблю приводить морские аналогии. Ни оин капитан не выведет судно в море, не сдав зачёты по устройству корабля, по работе главной машины, по способам ведения борьбы за живучесть, по возможностям средств связи, маневрирования. А он, обычно, "всего лишь" штурман. Да, он не ремонтируте в море главный двигатель, но ведь и у диреткора всегда есть возможность делегировать логистику, финансы и тд и тп. А не понимать того, что ИТ является уже давно стратегической возможностью он уже не может. Это его прямая обязанность.
На мой взгляд.
Поэтому "на Западе" появляются Илоны Маски, а у нас - нет.
Евгений. Вы правы! Добавлю - "опытный менеджер" с ИТ образованием. Если, конечно, вы согласитесь со мной.
Конечно, если Вы о PM. Но лучше - не только с IT.
В больших проектах, по моему опыту, основные вопросы и проблемы - не технические.
Да, так! "Не только с ИТ" - требование просто обязательное!
Интересно, а что именно - крупными мазками - не получилось?
Было видно сразу:
- очень некачественно написанное ТЗ, со множеством двузначностей, полутонов. Исполнитель очень быстро это понял и решил "срубить бабки".
- документации по проекту практически не было. Был план разработки и договор, из которого руководитель, не айтишник, выделил ключевые позиции по срокам и финансам.
- Команда формировалась в попыхах, не обладала адекватным опытом, разработчики имели разный опыт работы, что снижало их скорость. Из-за нехватки специалистов команда даже работала в разных языках. Массовый срыв сроков.
- весь этот бардак генеральный называл Agile.
- наступил момент, когда до разработчиков стало доходить, что надо "делать ноги". Начались дебаты с заказчиков в толковании ТЗ. Заказчик дал дополнительное время и дополнитедбное финансирование, но одновременно игнорировать наши запросы об уточнении ТЗ. Команда начала разбегаться.
Ну и затем ряд арбитражных судов, кторые были с треском проиграны.
Кстати, истец сделал упор на невыполнении ГОСТов (они были прописаны в договоре) и судьи подержали их требование.