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

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

Что интересно, эти запросы четко исходят в Процессе Ремонта но операции, где менеджер получив данный запрос, выясняет и согласовывает мнение Клиента и сообщает его механику, практически не описаны конкретно, т.е. скрыты среди общих операций менеджера подпроцессе Обработка запросов.

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

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

например в таком представлении данных четко видно кто ответственный за процесс, а кто за подпроцессы

[Михаил Шустер]

проблема в том, что из Процесса Ремонт есть 6-7 запросов, подобных приведенному,

Что здесь проблемного? Подпроцесс запускается из разных процессов, обычное дело. Как резидентная программа, лежит и ждет, пока ее дернут. Отработала и в люлю. Я даже ненужный термин придумал, резидентный процесс. Запускается по событию или по дате

[Андрей Горбунов]

"кто отвечает за результат процесса в целом?" - ответ на этот вопрос один: первый руководитель. Но это ответ столь же правильный, сколь и бесполезный. И тем более не имеющий особого отношения к рассматриваемому вопросу.
При любом взаимодействии (даже когда один матрос, находящийся на корабле, при швартовке бросает конец другому матросу у причальной тумбы) есть риск возникновения проблем, потому как взаимодействие - это стык зон ответственности. Как я часто повторяю на своих семинарах: кто отвечает за пациента, который покинул реанимацию, но не прибыл в плановую хирургию (т.е. которого везут по коридору)?
Нетрудно видеть, что способов решения проблем взаимодействия, по сути, только два:
1) совместное решение ответственных (т.е. договорились - по телефону, на совещании, за "чашечкой чая" в кафе и т.д.),
2) внешнее организационное решение (директор или лицо, им уполномоченное, изменяет границы ответственности, правила принятия решений, критерии результативности и т.п. так, чтобы проблема "рассосалась").
Плюс первого решения в оперативности. Минус - в очевидной зависимости решения и его результатов от конкретных людей. У второго, соответственно, все наоборот. Этим, по сути, и определяется выбор в конкретной ситуации. Если горит - лучше договориться, а потом - на спокойную голову - стандартизовать решение. Т.е. сначала 1), потом 2).
На примере с матросами. Тот, что на корабле, просто швыряет конец, не особо заботясь, куда он там попадет. Соответственно, матросу на причале приходится иногда тратить значительные усилия, чтобы достать брошенный абы как конец, что вызывает конфликтные ситуации с использованием идиоматических выражений. Но после совместного принятия внутрь порции "животворящих 40°" матросы договорились. А старпом, глядя на все это, прописал корабельному матросу в инструкции, что тот отвечает за то, чтобы швартовка происходила с минимальными потерями времени.
Т.е. системное решение проблем на стыке - это определение ответственности "предыдущего процесса" в терминах минимизации проблем для "следующего процесса". В наших "птичьих" терминах это звучит так: поставщик отвечает за то, чтобы поставляемый потребителю результат соответствовал его - потребителя - требованиям. Отсюда и задачи "системщика" в отношении организации взаимодействия:
- "потребитель" должен определить свои требования,
- эти требования должны быть известны "поставщику" и использоваться как критерии выпуска продукта,
- оценка результативности поставщика должна основываться на степени соответствия произведенного результата требованиям "потребителя".
А отдельных взаимодействий между "поставщиком" и "потребителем" столько, сколько "сущностей".

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

Предварительно пока решили, что эти операции менеджера по согласованию с клиентом, включим все-таки в Процесс Ремонта.
Плюсы: Карта процесса будет использоваться в дальнейшем как регламентирующий документ и намного удобней, когда последовательность операций прослеживается в одном документе, легче увидеть всю цепочку операций, т.к. не надо одновременно рассматривать две карты процессов.. Механик знает, что он должен отправить менеджеру запрос и он видит, что делает менеджер когда этот запрос решается с Клиентом и каким образом механик получает ответ.
ВП ремонт контролирует операцию менеджера по согласованию с Клиентом, т.к. эта операция в его процессе и он может управлять своим ресурсом через регламент.
Это больше похоже на процесс....)))
Минусы уже описывал: зоны ответственности, ВП Ремонт управляет и несет ответственность за результат действий менеджера, который не в его подчинении.
И самый большой минус - ВП Ремонт продолжает вопрошать, а нафига ему в процессе управлять менеджером, который типа должен выяснять вопросы с Клиентом в Процессе Обслуживание Клиентов. Здесь наверно инерция мышления, что я Гл. инженер отвечаю за ремонт, а он должен как ВП Ремонта отвечать за результат Процесса Ремонт а значит должен управлять всеми операциями относящимися к ремонту. Типа если менеджер поздно свяжется с Клиентом и из-за этого механик потеряет пол-дня на ожидание ответа делать ему замену проводки или нет, это напрямую скажется на показателях процесса, за которые отвечает ВП Ремонт.

[Роман Озеранский]

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

Сергей, объясните мне, а в чем тут минус. Это ведь управление процессами, а не командно-административное управление.
Кстати, если уж Вы решили, что человек из фронт-офиса будет участником команды процесса "Ремонт", у Вас проработан механизм, чтобы вот этот конкретный участник процесса не вляпался в казус двойного подчинения, когда он получит два противоположных указания, одно по линии коммерческого директора (как начальника той вертикали власти, к какой он административно принадлежит), а другое по линии главного инженера (как ВП)? Вы можете озвучить этот механизм?

[Андрей Горбунов]

Сергей,
"я - Гл. инженер отвечаю за ремонт" - вот это очень важно "расшифровать" в разных должностных инструкциях и т.п. Я поэтому на семинарах по ПП всегда включаю слайды, которые показывают, какие изменения должны произойти в организации при внедрении ПП. И этих изменений порядочно и они глубоки.
В данном случае "отвечаю за ремонт" можно трактовать как "отвечаю за то, чтобы какие-то работы по ремонту выполнялись", а можно и как "отвечаю за то, чтобы ремонт был результативным и эффективным" (т.е. с минимумом затрат времени, сил и средств). В первом случае ГИ будет важно, чтобы что-то делалось, неважно, какой результат, главное ремонт выполнялся. Показателем результативности будет факт проведения работ. А во втором случае придется искать пути повышения результативности и эффективности, что рано или поздно приведет к идее сотрудничества с "соседями" по процессу. И показателем результативности будет как быстро, с каким результатом и какими затратами выполнены работы.

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

Процесс Обслуживание Клиентов:
менеджер получил запрос от Клиента - у него не работает бульдозер, сможете отремонтировать и сколько это будет стоить? - и на основе этого сформировал Заявку. Если Клиент новый то предоплата на выезд механика. Согласовал с Клиентом, что к нему будет выезд механика с целью диагностики "вскрытие покажет", на основе которой мы сможем сказать беремся мы за ремонт и сколько это времени и денег будет стоить.
менеджер передал Заявку в Процесс Ремонт

Процесс Ремонт
Старший механик проверяет свободные даты для выезда, сообщает менеджеру (это уже 1-й запрос) что дата устраивает или надо ее сдвинуть (если сдвинуть, то менеджер опять связывается с Клиентом. Дает задание механику на выезд в назначенную дату.
Механик приезжает проводит диагностику.
Может увидеть, что достаточно поменять электропроводку и сообщает об этом менеджеру - (это уже 2-й запрос).

Процесс ????
менеджер связывается с Клиентом и сообщает дату выезда. Если Клиент согласен, сообщает механику. (ответ на 1-й запрос).
менеджер связывается с Клиентом и сообщает вид ремонта и его стоимость. Если Клиент согласен, сообщает механику. (ответ на 2-й запрос).

Процесс Ремонт
механик выполняет ремонт, акты шмакты подписал и на базу.

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

Процесс ???
менеджер связывается с Клиентом и сообщает, что ТН надо снять и выясняет кто это сделает и доставит на базу. Клиент дает согласие на снятие механиком ТН и забор его на базу.
менеджер сообщает об этом механику (ответ на 3-й запрос)

Процесс Ремонт
механик снимает ТН и грузит в свою машину, акты шмакты и уехал на базу.

Вот такая последовательность. Весь вопрос в том, операции менеджера будут относиться к Процесс ???.
Отнести операции менеджера к Процессу Ремонт - с точки зрения п/п это будет выглядеть как процесс но придется давать ответ Роману о казусе двойного подчинения.
Отнести операции менеджера к Процессу Обслуживание Клиента - куча взаимосвязей, выполнение Процесса Ремонт необходимо отслеживать по двум Картам процессов. Зато Роману не надо давать ответ, менеджер подчиняется "своему" начальству....)))

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

Понравилась одна цитата: "...В реальных организациях цепочка преобразований идет по более сложному пути:
- цепочка преобразований может выходить за пределы подразделения, например для согласования каких либо решений с другими руководителями, возвращаться после согласования, может пройти несколько итерационных циклов согласования;
- в ходе работ может быть использована дополнительная информация (входы), поступающая от других подразделений;
- в подразделениях могут параллельно или последовательно производиться несколько преобразований различных продуктов..." (Елиферов В.)

В моем случае цепочка преобразований "Ремонт" несколько раз пересекает процесс или отдел Обслуживание клиентов.

[Роман Озеранский]

Отнести операции менеджера к Процессу Ремонт - с точки зрения п/п это будет выглядеть как процесс но придется давать ответ Роману о казусе двойного подчинения.
Отнести операции менеджера к Процессу Обслуживание Клиента - куча взаимосвязей, выполнение Процесса Ремонт необходимо отслеживать по двум Картам процессов. Зато Роману не надо давать ответ, менеджер подчиняется "своему" начальству....)))

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

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

Роман Озеранский
Можно открыть отдельную тему и там на 20 страницах (или пересмотреть существующие 150 страниц форума) спорить о двойном подчинении, хотя так и не будет единого мнения.
Меня сейчас интересует другой вопрос, ответа на который нет не только у меня, но походу и многих других.

[Роман Озеранский]

Меня сейчас интересует другой вопрос, ответа на который нет не только у меня, но походу и многих других.

Сергей, а какого ответа Вы ожидаете, если Вы по ходу дела меняете границы процесса, как перчатки . Я Вам дал рекомендацию, обратить внимание на границы процесса в части его сквозности. Вы приняли решение, что Ваш процесс будет межфункциональным, проходя, как через фронт-офис, так и через подразделения занимающиеся ремонтом. ВП у этого процесса тоже определен, это ГИ. Так в чем сейчас проблема, в том что ГИ кочевряжется и не хочет, чтобы участниками процесса были сотрудники из фронт-офиса ? Так я по этому поводу Вам задал тривиальный вопрос - чего не хватает ГИ для управления процессом? Вы не ответили.

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

Роман Озеранский
ГИ в роли ВП реально кочевряжится....))) И не хочет не понимает, почему участниками процесса должны быть сотрудники из фронт-офиса.
Для управления ему вроде даны нужные полномочия. Ответственности за их операции нести не хочет, хотя прямую ответственность будет нести их непосредственный начальник, а ВП только за общий результат процесса, но всегда легче сказать что это они там недоработали и "кривой" вход мне прислали, чем признать, что "кривость" получена или из-за кривого регламента или тупо из=за его несоблюдения.

[Роман Озеранский]

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

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

Для управления ему вроде даны нужные полномочия.

Тем более, рули процессом, показывай свои компетенции. Что там мешает танцору танцевать процессный танец ?

ГИ в роли ВП реально кочевряжится....)))

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

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

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

Он предлагает не включать операции менеджера в его процесс, а пусть будет типа вход/выход....механик отправляет запрос на возможность выполнения ремонта на диагностике - выход из Процесса Ремонт. Менеджер в Ппроцессе Обслуживание клиентов согласовывает все вопросы с Клиентом и дает согласие механику на ремонт - вход в Процесс Ремонт. Зона ответственности меняется....в пользу ГИ, вот он это и хочет...)))

[Андрей Горбунов]

Сергей,
если честно, я не совсем Вас понимаю.
Вы постоянно приходите к тому, что попытка сделать ГИ "владельцем единого процесса" наталкивается на сопротивление ГИ. Полагаю, та же точно картина будет и с КД. Ну, так и оставьте их в покое, пусть каждый занимается своим делом: ГИ - милым его сердцу процессом ремонта, а КД - коммерческой частью.
Остается только найти того, кто будет "женить", согласовывать зоны ответственности ГИ и КД на системном уровне, отвечая за ламинарность/непрерывность потока ответственности. Ни ГИ, ни КД на эту роль ни разу не годятся.
Мне порой кажется, что Вы очертили себе некий круг и пытаетесь найти решение внутри него, а оно - снаружи! Т.е. первое, что надо сделать - это выйти из круга.

[Роман Озеранский]

вот он это и хочет...)))

Сергей, а Вы помните я вам рекомендовал сходить к директору, и спросить у него, зачем ему нужны процессы ? Были бы у Вас одни подразделения с начальниками во главе, и не было бы никаких процессов и никаких ВП. Красота . Именно это и предлагает Ваш ГИ - нарезать процессы в границах функциональных ниш (подразделений), чтобы каждый начальник отвечал только за своих людей и только ими управлял . Если процесс = подразделение, то процесс тут явно лишний, он - пятое колесо в стройно выстроенной административной системе управления . Вы сходили к директору, спросили у него - зачем Вашей компании нужны процессы ?

[Роман Озеранский]

Остается только найти того, кто будет "женить", согласовывать зоны ответственности ГИ и КД на системном уровне, отвечая за ламинарность/непрерывность потока ответственности. Ни ГИ, ни КД на эту роль ни разу не годятся.

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

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

Остается только найти того, кто будет "женить", согласовывать зоны ответственности ГИ и КД на системном уровне, отвечая за ламинарность/непрерывность потока ответственности. Ни ГИ, ни КД на эту роль ни разу не годятся.

А мне кажется, что включением операций менеджера, выполняемых им как раз для согласования с Клиентом, в процесс Ремонта я как раз и добился вышесказанного. Операциями менеджера (и других участников по цепочке) связанными с продажами Клиенту в Процессе Обслуживание Клиента, согласовывая внутри этого процесса точки "пересечений" разных отделов, занимается и управляет ВП Коммерческий директор.
Операциями механика (менеджера и других участников по цепочке) связанными с ремонтом в Процессе Ремонт, согласовывая внутри этого процесса точки "пересечений" разных отделов, занимается и управляет ВП Гл. инженер.
К примеру:

Процесс Ремонт
Старший механик проверяет свободные даты для выезда, сообщает менеджеру (это уже 1-й запрос) (ВП Гл. инженер может внести в регламент механику, что ответ он должен дать по телефону в течении 20 минут после получения Заявки на ремонт) что дата устраивает или надо ее сдвинуть (если сдвинуть, то менеджер опять связывается с Клиентом. Дает задание механику на выезд в назначенную дату.
Механик приезжает проводит диагностику.
Может увидеть, что достаточно поменять электропроводку и сообщает об этом менеджеру - (это уже 2-й запрос). (ВП Гл. инженер вносит в регламент механику, что он: вариант 1 - ничего не сообщает, если у него нет с собой нужной запчасти (зачем возня если не может отремонтировать); вариант 2 - сообщает и берется за ремонт только если есть уверенность, что за оставшееся время успеет все сделать и будет результат (зачем тревожить и обнадеживать Клиента, если механик видит что для ремонта нужно больше суток) и т.п

Процесс Ремонта
менеджер связывается с Клиентом и сообщает дату выезда. Если Клиент согласен, сообщает механику. (ответ на 1-й запрос). (ВП Гл. инженер смотрит регламент работы менеджера, который скорее всего готовил не Гл. инженер, и согласует с разработчиком документа дополнения в данный регламент, которые, с точки зрения Гл. Инженера позволят менеджеру своевременно связаться с Клиентом и оперативно передать решение механику).
менеджер связывается с Клиентом и сообщает вид ремонта и его стоимость. Если Клиент согласен, сообщает механику. (ответ на 2-й запрос).(ВП Гл. инженер смотрит регламент работы менеджера, который скорее всего готовил не Гл. инженер, и согласует с разработчиком документа дополнения в данный регламент, которые, с точки зрения Гл. Инженера позволят менеджеру своевременно связаться с Клиентом и оперативно передать решение механику).

А Гл. инженер почувствует себя ВП и сам будет заинтересован в таком ресурсе как операции менеджера связанные с процессом ремонта тогда, когда шеф спросит с него не как с Гл. инженера а как с ВП Ремонт (спасибо Михаил Шустер, вычитал подобную вашу цитату и теперь использую).

Еще момент. Я для себя вывел "закон", что операцию из одного процесса можно переносить в другой "чужой" процесс, когда это одна максимум две операции, но если за "пересечением" отделов последует большее количество операций, то это надо оформлять как выход одного процесса и вход другого. Выше мы уже выяснили, что нет единых и всех устраивающих методик вроде прав и ответственности ВП, границ процесса (ну конечно кроме типа управляющий ресурсами несет ответственность за результат использования и т.п.), так-что не вижу причин, почему этому не жить...)))

[Роман Озеранский]

так-что не вижу причин, почему этому не жить...)))

Сергей, так какие у Вас есть аргументы для этого ГИ (который выполняет роль ВП), что команда процесса должна в себя включать иных участников, какие ему не подчинены административно?