Почему IT-системы у одних компаний источник роста, а у других – нет?

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

Потом вдруг кто-то из конкурентов начинает работать «не как все». И цены ниже, и время ремонта меньше, и приезжают его техники быстрее. Клиенты это замечают и у других компаний возникают проблемы. Что случилось, откуда такие изменения? Да все понятно, они поставили себе FSM-систему, давайте мы тоже себе установим, и у нас будет то же самое. Купили лицензии, настроили, стали работать – а ничего не меняется. В самом деле, заявки на ремонт можно и в Telegram пересылать, как раньше делали, бесплатно, а других преимуществ не видно.

Как настроить IT-систему под задачи компании

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

Те изменения, которые клиенты и конкуренты видят в компании – всего лишь «вершина айсберга». И начались они, скорее всего, несколько месяцев назад с аудита сервиса, разработки стратегии улучшений и настройки сервиса под задачи ключевых клиентов, тех самых 20%, которые приносят 80% прибыли. Потом был подготовлен детальный план действий, рассчитан бюджет и плановые показатели эффективности (KPI), бизнес-процессы смоделированы, оптимизированы и занесены в IT-систему. Для сотрудников было проведено обучение управлению «по цифрам», а сам сервис перешел из режима «реактивной работы», когда проблемы в организации решаются после их возникновения, к «проактивному режиму», когда на основе анализа данных, собираемых IT-системой, проблемы в сервисе предсказываются и решаются задолго до того, как вызвали недовольство и отток клиентов.

Что такое проактивный режим работы сервиса

В проактивном режиме можно отслеживать множество показателей: загрузку сотрудников, использование рабочего времени, удовлетворенность клиентов, среднее время выполнения процессов и отдельных его стадий. Плановые показатели (KPI) уже привязаны к бонусам ответственных сотрудников, а зоны ответственности при работе с клиентом четко разделены. В процессах нет «узких мест» и перегрузка отдельных сотрудников не «тормозит» развитие бизнеса.

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

Важным элементом проактивной работы является мотивация сотрудников. Причем не только к выполнению ежедневной, рутинной работы, но и к профессиональному развитию. Поэтому организация проактивной работы предполагает аттестацию и построение матрицы знаний (Skill Matrix). Достижение определенного уровня сотрудником (количество баллов по знанию оборудования) приводит к присвоению более высокой категории и повышению оклада. При этом учитывается знание не просто любого оборудования, а моделей, по которым есть недостаток специалистов. План обучения согласуется с каждым техником и его руководителем индивидуально. Таким образом, производится привязка долгосрочных целей сотрудника к целям компании, в то время как «ежедневная рутинная» работа привязана к KPI.

Помимо мотивации сотрудников Skill Matrix помогает автоматизировать функции диспетчера и настроить автоматическое распределение заявок. У сервиса как бизнеса есть два ограничения: рынок и ресурсы, причем чаще всего срабатывает второе. Если диспетчер «тормозит» процессы, а нового сотрудника брать в помощь еще рано, автоматизация распределения заявок позволяет сэкономить до 40% его времени. Кроме распределения заявок, в сервисе можно автоматизировать и множество других функций: от заполнения отчетов и актов выполненных работ, до заказа запчастей.

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

  1. Снизила себестоимость работ за счет оптимизации бизнес-процессов и автоматизации отдельных функций.
  2. Обеспечила высокое качество сервиса за счет контроля, эффективного использования ресурсов и предотвращения проблем с клиентами. Такое возможно только в «проактивном» сервисе, управляемом «по цифрам».

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

Также читайте:

Расскажите коллегам:
Комментарии
Партнер, Москва
Анатолий Курочкин пишет:
Заказчик дал дополнительное время и дополнитедбное финансирование, но одновременно игнорировать наши запросы об уточнении ТЗ. Команда начала разбегаться. 

Такое впечатление, что заказчик не особо был заинтересован в результате. Или руководители со стороны заказчика.

Аналитик, Москва
Максим Клемешов пишет:
Анатолий Курочкин пишет:
Заказчик дал дополнительное время и дополнитедбное финансирование, но одновременно игнорировать наши запросы об уточнении ТЗ. Команда начала разбегаться. 

Такое впечатление, что заказчик не особо был заинтересован в результате. Или руководители со стороны заказчика.

Отчасти Вы правы, Максим. История некрасивая. Лично я уверен, что там существует коррупционная составляющая. Когда меня представитель заказчика на мои аргументы спросил: "Тебе  что - деньги не нужны?".

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

 

Генеральный директор, Москва
Анатолий Курочкин пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:
Один из моих последних проектов был в создании системы мониторинга сетевых ресурсов одной огромной структуры связи - огромный набор различных оконечных устройств, разного "возраста", разных протоколов. Кончился полным провалом, судами, издержками. А команде условных программистов провал был виден в самом начале работы. 

Интересно, а что именно - крупными мазками - не получилось?

Было видно сразу:
- очень некачественно написанное ТЗ, со множеством двузначностей, полутонов. Исполнитель очень быстро это понял и решил "срубить бабки".

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

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

- весь этот бардак генеральный называл Agile. 

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

Ну и затем ряд арбитражных судов, кторые были с треском проиграны.
Кстати, истец сделал упор на невыполнении ГОСТов (они были прописаны в договоре) и судьи подержали их требование. 

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

Аналитик, Москва
Евгений Равич пишет:
Удивительно, что PM взялся за эту работу. Шансов на успех, если я правильно  Вас понимаю, практически не было. Проект без документации - нонсенс.

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

Генеральный директор, Москва
Анатолий Курочкин пишет:
Евгений Равич пишет:
Удивительно, что PM взялся за эту работу. Шансов на успех, если я правильно  Вас понимаю, практически не было. Проект без документации - нонсенс.

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

А TPM в проекте был? Кто-то же должен был посмотреть и сказать, можно ли вообще сделать такую систему.

Researcher, Москва

АйТи глазами главного бухгалетра Анжелы Ивановны (и не только):

Анатолий Курочкин пишет:
- весь этот бардак генеральный называл Agile

Наверное на тренинг к какому-нибудь коучу сходил.

Вице-президент, зам. гендиректора, Москва

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

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

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

Вот несколько дополнительных советов, которые помогут IT-специалистам быть более успешными:

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

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

Технический директор, Москва
Анатолий Курочкин пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:
Один из моих последних проектов был в создании системы мониторинга сетевых ресурсов одной огромной структуры связи - огромный набор различных оконечных устройств, разного "возраста", разных протоколов. Кончился полным провалом, судами, издержками. А команде условных программистов провал был виден в самом начале работы. 

Интересно, а что именно - крупными мазками - не получилось?

Было видно сразу:
- очень некачественно написанное ТЗ, со множеством двузначностей, полутонов. Исполнитель очень быстро это понял и решил "срубить бабки".

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

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

- весь этот бардак генеральный называл Agile. 

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

Ну и затем ряд арбитражных судов, кторые были с треском проиграны.
Кстати, истец сделал упор на невыполнении ГОСТов (они были прописаны в договоре) и судьи подержали их требование. 

Очень ценное описание ситуации!

Аналитик, Москва
Евгений Равич пишет:
Анатолий Курочкин пишет:
Евгений Равич пишет:
Удивительно, что PM взялся за эту работу. Шансов на успех, если я правильно  Вас понимаю, практически не было. Проект без документации - нонсенс.

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

А TPM в проекте был? Кто-то же должен был посмотреть и сказать, можно ли вообще сделать такую систему.

А кто такой ТРМ? 
Выиграли конкурс, подписали договор, сделали ТЗ - заказчик хотел, исполнитель согласился, авсоь вывезет, утрясём.
А когда договор подписан, то кто же будет критику слушать? Хотя, повторюсь, ситуация была вполне поправима при наличии специалистов. 

Аналитик, Москва
Сабир Исаев пишет:

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

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

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

Вот несколько дополнительных советов, которые помогут IT-специалистам быть более успешными:

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

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

Благодарю, Сабир! И вы даёте хорошие советы. 
Довольно много лет назад были дискусси о повышении роли ИТ-директора. О повышении роли ИТ-специалистов. Тогда из называли позорным словом "компьютерщик". Одна очень милая дама из ИТ кинула крылатую фразу: "Ещё раз назовёте меня "компьютерщиком", я буду называть вас "Лечильщиком" - речь шла о медицине. Это была эпоха принижения роли айтишников, программистов, выведение их на второй план. Были дискуссии "Надо ли руководителю программистов уметь программировать". Потом это заглохло, но езультат, на мой взгляд, плохой. Он мог быть значительно лучше. 

И Вы абсолютно правы - ИТ-специалисты должны поднимать свою ключевую роль! Они не должны превращаться в штукатуров от программирования .

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
4
Михаил Лурье
Тема про Ивана Ефремова ну и других фантастов, и про их влияние на общественное восприятие реальн...
Все дискуссии