[NN----NN]

Уметь делать и уметь объяснить - сильно разные навыки.

Не надо дворнику объяснять и показывать как держать метлу или как мести слева-направо или наоборот. От него требуется пользоваться "инструментом" и мести чисто, знать границы участка и делать это вовремя — это пишется в должн. инструкции и если что-то не выполняется — на выход. Этот момент, многие из пишущих инструкции не учитывают, а нужно именно наличие в ней перечня конкретных, насколько это возможно, требований к работе.

Изменено 19 июня, 2015 пользователем NN----NN

[Тимур]

1 - Я не понимаю, как можно за такой срок сделать такой объем работы. Я не говорю что это не возможно, я говорю, что не понимаю как это в принципе можно сделать.

 

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

и начисто переписал. :-) А потом месяц бегал и всех пинал за неисполнение. Ты же читал Адизеса ? Нет ? ;-)

 

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

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

 

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

[SergeiK]

1 - Я не понимаю, как можно за такой срок сделать такой объем работы. Я не говорю что это не возможно, я говорю, что не понимаю как это в принципе можно сделать.

 

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

и начисто переписал. :-) А потом месяц бегал и всех пинал за неисполнение. Ты же читал Адизеса ? Нет ? ;-)

 

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

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

 

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

Дык о том и спич с самого начала! Если у тебя все хорошо без регламентов - значит не нужен!

А если не хорошо, то почему? Потому что кто-то не знает, что делать, или не считает нужным это делать, или дело совсем в другом?

Это знаешь только ты, никто больше!

 

Если нужен - я убежден, что если процесс не документирован - считай, что его нет.

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

При этом каждая схема в иерархии должна умещаться на А4. А кому надо детали по конкретной задаче полез в документ, нашел пункт, прочитал!

Когда возникает вопрос, правильно ли поступил исполнитель или нет, не спорят бестолку, а открывают регламент и смотрят по задаче: достаточно ли было вводных, и верны ли были, что надо было получить, и получено ли?

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

 

Информационная система - большой плюс к бизнеспроцессу, но дополняет, а не заменяет.

[Sergey Gilfanov]

Не надо дворнику объяснять и показывать как держать метлу или как мести слева-направо или наоборот. От него требуется пользоваться "инструментом" и мести чисто, знать границы участка и делать это вовремя — это пишется в должн. инструкции и если что-то не выполняется — на выход. Этот момент, многие из пишущих инструкции не учитывают, а нужно именно наличие в ней перечня конкретных, насколько это возможно, требований к работе.

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

[Тимур]

Если нужен - я убежден, что если процесс не документирован - считай, что его нет.

 

А если документирован, но эти документы никто и никогда не читает? То как?

 

У меня есть ответ, но я бы хотел сначала послушать мнения других людей

[SergeiK]

Если нужен - я убежден, что если процесс не документирован - считай, что его нет.

А если документирован, но эти документы никто и никогда не читает? То как?

 

У меня есть ответ, но я бы хотел сначала послушать мнения других людей

Тоже, считай что нет :).

Иногда даже хуже, чем просто нет.

 

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

 

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

[Тимур]

Если нужен - я убежден, что если процесс не документирован - считай, что его нет.

А если документирован, но эти документы никто и никогда не читает? То как?

 

Тоже, считай что нет :).

Иногда даже хуже, чем просто нет.

 

Не совсем так.

Есть ровно одна ситуация, когда все-таки да. "Когда начинаются разборки - кто более неправ" (с) Прохожий

 

Вывод?

Я для себя сделал такой. Критичной является задача по массовому выявлению ошибок и поточному разбирательству по ним.

Регламенты же сами собой появятся ровно в тех точках, где они необходимы.

[NN----NN]

...

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

При этом каждая схема в иерархии должна умещаться на А4. А кому надо детали по конкретной задаче полез в документ, нашел пункт, прочитал!

Когда возникает вопрос, правильно ли поступил исполнитель или нет, не спорят бестолку, а открывают регламент и смотрят по задаче: достаточно ли было вводных, и верны ли были, что надо было получить, и получено ли?

...

Именно так

 

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

Это всё и было в моём случае. Только "руководство более высокого уровня" - это был я, а также автор и владелец. Я тогда не все умные книжки ещё прочитал :), поэтому обошёлся без этих понятий "автора" и "владельца"

Изменено 19 июня, 2015 пользователем NN----NN

[SergeiK]

Не совсем так.

Есть ровно одна ситуация, когда все-таки да. "Когда начинаются разборки - кто более неправ" (с) Прохожий

Ты сказал, что "никто никогда" :).

Но, согласен, самая худшая версия, когда "тут играем, тут не играем".

 

Вывод?

Я для себя сделал такой. Критичной является задача по массовому выявлению ошибок и поточному разбирательству по ним.

Регламенты же сами собой появятся ровно в тех точках, где они необходимы.

Увы, сами собой они не появляются! Их должен кто-то писать, кто-то двигать по согласованиям, кто-то внедрять.

Но, согласен, что не следует регламентировать ВСЕ, а только необходимое!

А вот где именно необходимо - это, опять же, видно только руководителям, и решать ему же.

 

Я же всегда за разумный баланс :).

[Тимур]

А вот где именно необходимо - это, опять же, видно только руководителям, и решать ему же.

 

Ну вот я руководитель. Мне вот не видно.

[NN----NN]

Не надо дворнику объяснять и показывать как держать метлу или как мести слева-направо или наоборот. От него требуется пользоваться "инструментом" и мести чисто, знать границы участка и делать это вовремя — это пишется в должн. инструкции и если что-то не выполняется — на выход. Этот момент, многие из пишущих инструкции не учитывают, а нужно именно наличие в ней перечня конкретных, насколько это возможно, требований к работе.

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

Для решения вопроса "с контейнером" есть начальник дворников.

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

Важно (!) понимать, как исполнителю, так и автору регламента/процедур, что для нормальной работы нужны определённые полномочия и ресурсы. Если этого нет, то возникшая "проблема" эскалируется на уровень выше, где есть или полномочия, или полномочия + ресурсы.

[jab]

Когда я был молод и у меня было корпоративных ограничений я как-то раз сел подробно расписывать бизнес-процесс подключений. Сели мы с нойтой. Ну типа за неделю справились. Получился ворох контента, совершенно не воспринимаемый никем.

 

Вот именно! :-) Мог бы с тем же успехом сесть за диссертацию по генной инженерии, с нойтой или еще с кем. С поварихой например.

[SergeiK]

А вот где именно необходимо - это, опять же, видно только руководителям, и решать ему же.

Ну вот я руководитель. Мне вот не видно.

Жаль. Может быть в этом и есть основная проблема? Может, пригласишь Прохожего консультанта, он покажет, где необходимо? :).

 

Увы, но кроме общих советов, никто на форуме большего тебе не даст, ибо внутренная жизнь бизнеса у всех своя.

А общий совет (у меня лично) такой - где целесообразно тратить силы и время на работу с регламентом, там и необходимо!

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

[Тимур]

где целесообразно тратить силы и время на работу с регламентом, там и необходимо!

 

Как объективно определить (вычислить) целесообразность?

 

Это ключевой вопрос. Если для вас не очевидна его сложность и фундаментальность, то мне тогда нечего добавить к дискуссии.

[Тимур]

Дополню.

Если мы говорим не об идеальном, а о реальном руководителе - то нужно понимать, что он часто бывает

- неумен

- самонадеян

- истеричен

- ленив

- трусоват

- зашорен

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

 

Системное организационное решение должно учитывать эту неприятность.

[SergeiK]

где целесообразно тратить силы и время на работу с регламентом, там и необходимо!

 

Как объективно определить (вычислить) целесообразность?

 

Это ключевой вопрос. Если для вас не очевидна его сложность и фундаментальность, то мне тогда нечего добавить к дискуссии.

А может быть ты усложняешь эту проблему определения целесообразности, пытаясь найти себе оправдание этим не заниматься? :).

 

Следующей же строкой я написал один из возможных подходов:

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

Можно использовать другой подход, который нравится, включая интуитивные ощущения или "пол-палец-потолок"!

 

Да, тут очень важно правильно оценить риски.

Иногда можно получить результат, что, пытаясь улучшить то, что "плохо, но живет", после улучшения жить вообще перестанет.

С другой стороны, если оно сейчас "плохо, но живет", завтра-то с этим что будет? Само подохнет и не жалко? Или, вдруг само собой наладиться?

В общем, все очень зависит от нюансов.

[SergeiK]

Дополню.

Если мы говорим не об идеальном, а о реальном руководителе - то нужно понимать, что он часто бывает

- неумен

- самонадеян

- истеричен

- ленив

- трусоват

- зашорен

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

 

Системное организационное решение должно учитывать эту неприятность.

Это, конечно все правда. Увы, мир не идеален. Но каждый может стремиться к совершенству! :).

 

Как раз для снижения (не устранения) таковых неприятностей большие компании пытаются использоваться всякие консалтерские услуги, но результат этого часто бывает сомнительный.

 

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

[Kirya]

Это ключевой вопрос. Если для вас не очевидна его сложность и фундаментальность, то мне тогда нечего добавить к дискуссии.

ROIC (Return on Invested Capital) по подразделениям cчитай.

Т.е выгодно было делать это действие, и как быстро, или оно ни на что не влияет ?

Это коэффициент как бы обратный ROI (return on investment, также ROR).

 

 

[Тимур]

Т.е выгодно было делать это действие, и как быстро, или оно ни на что не влияет ?

Это коэффициент как бы обратный ROI (return on investment, также ROR).

 

 

А можно развернуть мысль? Я так не понял.

[SergeiK]

Это ключевой вопрос. Если для вас не очевидна его сложность и фундаментальность, то мне тогда нечего добавить к дискуссии.

ROIC (Return on Invested Capital) по подразделениям cчитай.

Т.е выгодно было делать это действие, и как быстро, или оно ни на что не влияет ?

Это коэффициент как бы обратный ROI (return on investment, также ROR).

Как я понял Тимура, он не очень понимает, какая вообще будет польза! Уж тем более не понятно, как её считать в цифрах.

 

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

С точным подсчетом и тут все не просто, но кто обещал, что будет легко?

 

Если проблем и потерь нет, то нет смысла вообще все затевать.

Изменено 19 июня, 2015 пользователем SergeiK

[Тимур]

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

 

У нас куда ни ткни везде проблемы и везде потери.

И?

[Kirya]

Ну, попробую....

 

Коэффициент ROIC есть Коэффициент рентабельности инвестированного капитала - отношение чистой операционной прибыли компании после выплаты налогов к среднегодовой величине инвестированного капитала.

http://profmeter.com.ua/Encyclopedia/detail.php?ID=825

 

ROI же наоборот показывает коэффицент возврата инвестиций, показатель рентабельности вложений.

 

Т.е ROI в инвест-бизнесе показывает сколько мы заработаем, если куда-то инвестируем, а ROIC показывает сколько мы получаем от того, что уже инвестировали.

 

Далее делая сравнения коэффициентов ROIC от разных моделей поведения компании, подразделения (в принципе это можно посчитать и для отдельного сотрудника :) )

мы получаем оценку эффективности той или другой модели работы над задачей.

[SergeiK]

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

 

У нас куда ни ткни везде проблемы и везде потери.

И?

Ох, как все запушенно!

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

Тогда, для тренировки, можно выбрать наименее критичное подразделение :). Кого не слишком жалко. И масштаба небольшого.

 

Хотел написать больше, но, увы, я выхожу в оффлайн, поэтому на этом остановлюсь пока :).

Изменено 19 июня, 2015 пользователем SergeiK

[Тимур]

А в цифрах можно оценить потери, по подразделением/направлениям?

 

А как?

[Kirya]

Ну, попробую....

 

Коэффициент ROIC есть Коэффициент рентабельности инвестированного капитала - отношение чистой операционной прибыли компании после выплаты налогов к среднегодовой величине инвестированного капитала.

http://profmeter.com...tail.php?ID=825

Как показала личка - всё-равно коллеги не совсем поняли, о чём идёт речь,

и как этим пользоваться.

Попробую объяснить на теоретическом упрощенном до крайности телеком примере.

 

Предположим, у нас есть дом, стройка и подключение клиентов которого для простоты уже давно окупились, который даёт выручку скажем в 40 т.р в месяц.

За вычетом налогов, себестоимости инета и пр. предположим, что чистого дохода от него остаётся 5 т.р в месяц.

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

т.е клиенты за это время, конечно побунтуют, но если их КЦ успокоит, сказав, что доктор коммутатор уже едет и через неделю всё починится, то ничего страшного не произойдёт,

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

Свитч уникальный, заменить его дргим нельзя.

Т.е мы мы встаём перед выбором - или покупать коммутатор в ЗИП, или же держать до момента сгорания лишнюю девочку в КЦ с з.п в 30 т.р (включая ЕСН) , которая при наступлении часа X будет сидеть на обзвоне.

 

Когда эксплуатация придёт в бухгалтерию за согласованием покупки коммутатора, то глупый финансовый директор им скажет:

ребят, мне на вас нужно потратить 50 т.р, если я не потрачу этих денег - то потеряю всего 10 т.р.

ROI данной покупки очень плохой, это плохая инвестиция - трачу 50 т.р. для спасения всего 10 т.р.

 

Но если эксплуатация ему подскажет, что из-за этой потенциальной аварии бухгалтерии КЦ нужно держать в запасе и придётся год платить зарплату одному человеку,

чтоб при её возникновении он обзванивал клиентов, и таким образом уменьшиться рентабельность оборотного капитала, математика станет совсем другой.

 

Считаем ROIC держа запас по людям в КЦ за год: ((5*12)-10)/30*12=0.1389

Сравниваем с ROIC за год при покупки свитча в ЗИП: 5*12/50=1,2

 

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

:)

 

ps. В реальности нужно ещё в формулу вводить такие важные параметры, как ставку дисконтирования, учитывая, что средней и маленьком компании их будет две,

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

Изменено 19 июня, 2015 пользователем Kirya