Включение операций в один из процессов

[Виталий Эйнула]

Пусть заявка попадает сразу в службу сервиса, а не через менеджера т.к менеджер это ретранслятор, а значит - лишние движения и ожидания- потери.

[Андрей Козин]

Начните с план/фактного анализа загрузки механиков на основе записей. Предложите клиентам периодический плановый осмотр и ремонт. Это снизит частоту аварийного ремонта и нетерпения клиента.

[Сергей Трофимов]

Когда Клиент обращается с запросом на ремонт, менеджер с его слов заполняет Заявку на ремонт, отправляет ее клиенту чтобы тот подтвердил, что в ней записано все правильно. Это было сделано после того, как стали возникать случаи, когда раньше менеджер такую заявку не заполнял и сам оформлял Заявку на сервис, потом наш механик приезжал к клиенту выполнять работы, а клиент говорил, что вот этот пункт он не просил делать и вообще его не так поняли и он говорил по другому. Заявку на ремонт ввели, до всех донесли об обязательном использовании, но уже пара фактов всплыла, что менеджеры ее не используют и работают по старинке.
Какое решение лучше:
1. Лишить части премии тех менеджеров, которые не используют Заявку на ремонт и лишать до тех пор, пока не начнут на 100% использовать. Плохо, что это надо будет постоянно мониторить и не факт, что через 1-2 месяца опять начнут игнорить эту заявку.
2. Обязать сервис направлять механика к клиенту только после получения сервисом и Заявки на сервис и скана Заявки на ремонт (подтвержденную клиентом). Но получится, что мы нагружаем сервис лишней проверкой документов, а это не их забота абсолютно.

[Сергей Трофимов]

Пусть заявка попадает сразу в службу сервиса, а не через менеджера т.к менеджер это ретранслятор, а значит - лишние движения и ожидания- потери.

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

[Андрей Козин]

Какое решение лучше:

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

[Сергей Трофимов]

Какое решение лучше:

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

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

[Виталий Эйнула]

Менеджер решает вопрос с оплатой клиентом по заявке.

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

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

это почему же? а вот это кстати как раз работа менеджера.

Гарантией его оплаты может быть договор или предоплата с его стороны.

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

[Виталий Эйнула]

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

так вот в чем проблема?!! а мы то тут
всегда вставайте на сторону клиента и прочувствуйте на его шкуре как это все надо сделать ,лично мне нет времени еще раз подтверждать что ранее уже сказал или написал.. даже в Макдональдсе так делают сразу по приему заказа..

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

[Сергей Трофимов]

или написал

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


Если клиент нам написал, то проблем нет, если что мы можем сослаться на "..а вот вы сами нам так написали".
Проблема чуть глубже чем кажется.
1. Менеджер может действительно не совсем верно записать требования клиента.
2. Клиент ненамеренно сообщает не всю необходимую информацию.
3. Клиент намеренно искажает информацию.

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

[Сергей Трофимов]

Начните с план/фактного анализа загрузки механиков на основе записей. Предложите клиентам периодический плановый осмотр и ремонт. Это снизит частоту аварийного ремонта и нетерпения клиента.

Что мы этим добьемся? Гл. механик планирует и отвечает за загрузку механиков и только он решает, когда кто-либо из механиков может выехать к клиенту. И это его решение может быть чисто субъективным, т.е. дружит он с одним менеджером - то по заявке от этого менеджера он сразу направляет механика. Если с другим менеджером он враждует, то по его заявке направит механика только на третий день.

[Андрей Козин]

Что мы этим добьемся?

1. Увидите реальную загрузку
2. Можно в отчет включить выявленные проблемы, которые не позволили быстро обслужить конкретного клиента конкретным механиком. Уже хорошо.
3. Через N периодов можно провести анализ по сложности заявок и установить нормативы на обслуживание.
4. Нормативы послужат основанием для оптимизации планирования, расчет потребности в ресурсах, оптимизация ресурсов механиков

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

[Виталий Эйнула]

Если клиент нам написал, то проблем нет, если что мы можем сослаться на "..а вот вы сами нам так написали".
Проблема чуть глубже чем кажется.
1. Менеджер может действительно не совсем верно записать требования клиента.
2. Клиент ненамеренно сообщает не всю необходимую информацию.
3. Клиент намеренно искажает информацию.

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

[Виталий Эйнула]

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

может или такие случаи были? часто ли?

[Виталий Эйнула]

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

как в Ростелекоме ... .."К сожалению все сотрудники сейчас заняты, оставайтесь на линии..пип пип пип пип"
зато в такой системе нет вражды или симпатии

[Сергей Трофимов]

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

может или такие случаи были? часто ли?

Были и еще могут быть...к сожалению

[Сергей Трофимов]

я, всегда обращаюсь к статистике если она есть и анализирую ситуацию "Как есть" и лишь только потом принимаю решение стоит ли делать КД

Что-то в глаза бросилось... КД прерогатива ВП, а у вас ВП всех процессов - один человек, "советник". Вы и есть тот советник?

[Виталий Эйнула]

я, всегда обращаюсь к статистике если она есть и анализирую ситуацию "Как есть" и лишь только потом принимаю решение стоит ли делать КД

Что-то в глаза бросилось... КД прерогатива ВП, а у вас ВП всех процессов - один человек, "советник". Вы и есть тот советник?

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