Відгуки на «Management by Objectives (управление по целям)» |
| Konstantin, ko-s-ka@ukr.net Из текста совершенно неясно, как же этот чудо-метод обеспечит заявленные "бонусы"... >>>«Плохая мотивация персонала». Сотрудники будут ориентированы на результат, требуемый компании. И они будут стараться его достигнуть и перевыполнить.<<< Сотрудники по-прежнему ориентированы на собственный результат. Мотивация если и повышается, то только за счет материального стимулирования. А это, как Вы же сами и пишете, малоэффективно. >>>«Незнание целей и задач». Цели поставлены ясно в самом начале работы. Известны общие задачи и персональная ответственность<<< Если речь идет о полном отсутствии персонализированных задач (клинический случай) - то да. Но в Вашем примере, зная свою персональную задачу, я, по-прежнему, не представляю ничего о ее влиянии на достижение целей компании. А это демотивирует не меньше, чем отсутствие персональных задач. >>>«Инертность к изменениям». При изменении целей компании (естественно, не в середине периода) соответственно изменяются задачи каждого отдела и каждого сотрудника<<< Обычно, когда говорят о "сопротивлении изменениям", имеют ввиду нечто иное. Изменение целей - это вполне логичное явление, которое имеет место ВСЕГДА. А что еще делать с целями при их достижении (или определении недостижимости)? >>>«Закрытость отделов». Сейчас все завязаны на общую задачу и видно, от кого зависит выполнение данной части, как это повлияет на результат. <<< Да ну? По-прежнему, каждый руководствуется своими, и только своими целями. Конкуренция между отделами не исчезает, а просто становится измеримой в процентном отношении :-) А скорее всего, конкуренция усилится. >>>«Сложность анализа». Все цели построены по принципу SMART и анализ достаточно простой<<< Сложность анализа вызвана сложностью анализируемой системы. Убей бог, не понимаю, как характеристики цели могут уменьшить сложность системы? Кто вообще придумал тавтологию - "управление по целям"? Управление целесообразно по определению. По этой статье создается впечатление, что данный метод вызван к жизни чьим-то нежеланием разобраться в основах теории управления Kind regards, Konstantin 2003-08-14 11:33:25 Відповісти Sergiy, cape@ukr.net Собственно говоря, из статьи так и осталось не понятным, зачем это MBO необходимо и в чем его основные преимущества. Все проблемы, которые поднимались в статье, решаются, скажем так "классическими" методами и без применения "умных" терминов SMART, MBO. А некоторые проблемы так и вовсе надуманы. Вот, например, проблема, поднятая в статье(цитирую): "Незнание сотрудником тех задач, которые требуется ему решить". Так а куда смотрит начальник сотрудника? Почему он не выдал задачу или поручение? Ах, да. Он же MBO изучает. Или же (цитата): "«Плохая мотивация персонала». Сотрудники будут ориентированы на результат, требуемый компании. И они будут стараться его достигнуть и перевыполнить". Сотрудники будут ориентированы на результат, требуемый компании, только тогда, когда, простите за простоту выражения, сотрудник будет на 120% уверен, что за это компания отлистает ему бабла в соответствии с его, сотрудника, представлениями о справедливости. А в остальных случаях чихал он на этот "результат, требуемый компании". Более того, опять (это похоже инфекционное) не указана область применения. А без этого - статья вообще теряет всякий смысл. Вот например, цитата: "Причем чем выше соотношение «премиальная часть / заработная плата», тем большего эффекта можно получить. К примеру, для отдела продаж, от которого напрямую зависит выручка организации, данное соотношение реально может составлять 1:1." А если в организации (реальный пример) это соотношение достигает 10:1 и больше. При этом область деятельности - информационные технологии, автоматизация, разработка ПО и т.д. Будет ли работатьт этот метод (MBO)? Или другой пример. Производственное предприятие, на котором персонал (основная масса) можно сравнить (мягко говоря) разве что с гоблинами. Будет там MBO работать или нет? Или случай, когда генеральный директор является владельцем контрольного пакета акций, а остальные директора - держатели остальных акций предприятия. Будет работать такой метод стимулирования высшего руководства? Будет ли работать MBO в производстве, развернутом на базе мест принудительного лишения свободы? ГДЕ ГРАНИЧНЫЕ УСЛОВИЯ ПРИМЕНЕНИЯ? И таких "если" можно привести в пример вагон и маленькую тележку. Кстати, о самом примере, который приводится в статье. Если участнику моей проектной команды (когда у меня идет проект) кто-либо, не дай бог, поставит цели, которые так сформулированы (особенно классная цель: "Ежедненаная отчетность" - да это же не цель! - это средство), то он будет тут же отправлен изучть народный фолькльор. И вызывает недоумение вот еще что. Каким образом программист узнает о том, как он влияет на выполнение целей всей организации, если его персональные цели никак явно не связаны с целями организации в целом? Кстати, если кому-то действительно интересно прочитать про MBO, советую посмотреть здесь: http://www.1000ventures.com/business_guide/mgmt_mbo_main.html. А особенно обратить внимание на разделы/врезки: "Six MBO Stages" и "MBO: Key Advantages and Disadvantages". 2003-08-14 14:02:52 Відповісти Konstantin, ko-s-ka@ukr.net Спасибо за ссылку, Сергей. Жаль, что это не читали те менеджеры, которые покупают тренинги по MBO у всевозможных тренинговых компаний. Тренеры предлагают дать MBO за 3 дня, а там какой из 6-ти этапов не возьми, он сам по себе претендует на монументальность :-) 2003-08-14 17:00:16 Відповісти Sergiy, cape@ukr.net Константин, Научить читать (и _понимать_ написанное) нашего менеджера/руководителя (про "их" мненеджеров не знаю) - это одна из наиболее сложных задач современности :-) У нас в организации сейчас при ведении проектов одна из самых сложных проблем (внимание!) - это то, что руководство заказчиков не читает проектную документацию. О каком согласовании задач по проекту может идти речь? И руководителю проекта приходится "на пальцах" (а иногда и "по понятиям" :-) объяснять заказчику о чем идет речь. Точно также и с тренингами. "Спорт залу" деньги заплатили. В затрты поставили. Налоги уменьшили. Какое MBO? 2003-08-15 09:01:33 Відповісти Konstantin, ko-s-ka@ukr.net По поводу немения читать проектную документацию - это да. Болезнь в глобальном масштабе. Если следовать здравому смыслу и старым советским ГОСТам, техзадание проекта должен писать ЗАКАЗЧИК (или его уполномоченный представитель), но уж никак не исполнитель. Интересно, как часто это выполняется в нашей реальности? ;-) 2003-08-15 09:21:20 Відповісти Sergiy, cape@ukr.net Ну, не совсем согласен. Если следовать ГОСТам, то может быть требования и должен писать заказчик. А вот если следовать здравому смыслу, то требования должен писать исполнитель, поскольку в противном случае, есть риск, что они не будут написаны никогда :-) 2003-08-15 10:45:15 Відповісти Konstantin, ko-s-ka@ukr.net Вот и имеем в результате ситуацию, когда ИСПОЛНИТЕЛЬ говорит ЗАКАЗЧИКУ, что же ему (заказчику) на самом деле нужно :-) Конечно, такая ситуация устраивает многих Исполнителей (особенно, не самых профессиональных). Хотя, думаю Вы согласитесь, работать с Заказчиком, который точно знает, чего хочет, намного приятнее... 2003-08-15 12:10:58 Відповісти Sergiy, cape@ukr.net Вах! Работать с грамотным заказчиком - это подарок Небес! Только вот с непрофессиональными исполнителями, Константин, Вы по-моему, погорячились. Я бы, например, с удовольствием занимался _исключительно_ внедрением информационных систем по _грамотно_ написанным заказчиком требованиям. Только вот реалии жизни таковы, что приходится держать в штате бизнес-аналитиков, а половина ИТ-шников - это почти готовые бизнес-аналитики по направлениям. На самом деле, исполнитель только фиксирует требования (например, к информационной системе) и согласовывает (обязательно!) их с заказчиком до достижения полного взаимопонимания по всем пунктам требований и искоренения возможных неоднозначностей в трактовках. Источником же требований все равно является заказчик, который выдает их нагора под напором аналитиков исполнителя. Мне например, в этой связи очень нравится устоявшийся термин, который этот процесс описывает "customer requirements elicitation", который буквально можно перевести примерно как "извлечение/вытягивание требований заказчика" - очень хорошо описывает реальный процесс. Собственно говоря, если посмотреть на рекомендации "лучших собаководов" в этой области, то они это и рекомендуют. А если мы посмотрим на заказчика (реального, а не идеального), то увидим, что: - ОН всегда занят основным бизнесом и ЕМУ некогда тратить время на "всякую ерунду" - и тут ЕГО можно понять; - ОН не обладает специальной квалификацией по подготовке требований (это целый раздел области знаний), в отличие от моих аналитиков - это абсолютно естественно, поскольку каждый должен заниматься своим делом. И, например, если прочесть IDEF0 диаграмму в состоянии практически любой толковый менеджер, то "нарисовать" ее не так просто, как может показаться на первый взгляд. - некоторые вещи ЕМУ кажутся настолько очевидными, что ОН забывает включить их в требования - вполне понятно - "свежий взгляд" на организацию всегда ценится; - ОН не может выделить человека, который видит всю картину целиком на проект - такие люди обычно заняты "по горло" на бизнес-задачах, а особенно критично это в услових, когда уровень технологической зрелости организации/предприятия низок - для Украины это нормальная ситуация, как впрочем и для западных стран, если судить по публикациям; - ЕГО сотрудникик склонны замалчивать неприятные для них моменты, а сторонний аналитик является лицом независимым и, что называется, режет "по живому". И этот список можно продолжать. Причем, такие соображения настолько убедительны для заказчкиа, что он с ними соглашается, пратически, безоговорочно. 2003-08-15 13:03:23 Відповісти Konstantin, ko-s-ka@ukr.net Да я спорить и не собираюсь :-) Очевидно, в проектах внедрения информационных систем должны присутствовать три стороны: "Заказчик" - "Внедренец" - "Вендор ПО" При нормальной системе, когда внедренец не зависит от конкретного программного комплекса, наверное да... А если внедренец и вендор - это одно и то же лицо? Заказчик может оказаться в неприятной ситуации, когда его требования чуть-чуть "привели в соответствие" с возможностями программного комплекса. Или такого быть не может? 2003-08-15 13:52:02 Відповісти Sergiy, cape@ukr.net Все зависит от квалификации и честности (читай, репутации) внедренца, и желании заказчика получит работающую систему. Что отражено в требованиях - то и получит заказчик. И если заказчик подмахнуд неглядя бумаги, а внедренец (радостно потирая руки) сваял то, что подписано... Ну, ситуация понятна. Поэтому такое внимание сейчас и уделяется, например, ISO или (к сожалению, в основном на Западе, CMM). Там работе с требованиями (кстати, явными и неявными) заказчика отведено очень большое место. Все зависит от качества требований - это ключевой момент в производстве любых работ. Если перефразировать известное выражение, то можно сказать: "Ищите требования" :-) А кто в каких лицах выступает - это уже дело техники. Кстати, многие производители ПО сознательно не работают с клиентом напрямую, а только через партнеров. Смысл в том, что внутри партнерской сети создается конкуренция (за счет присутствия нескольких партнеров в некотором регионе), которая и гарантирует непрерывное повышение уровня сервиса и качества выполняемых работ. 2003-08-15 14:23:22 Відповісти Konstantin, ko-s-ka@ukr.net Сергей, а не могли бы Вы порекомендовать литературу по управлению требованиями? 2003-08-15 14:33:14 Відповісти Sergiy, cape@ukr.net В печатном виде на русском языке, к сожалению, ничего не могу назвать. В электронном и на английском примерно следующее: 1. CMMI (www.cmm.org) 2. ISO 9001 3. Любые работы Карла Вигерса (Karl E. Wiegers) 2003-08-15 15:16:55 Відповісти Анатолий У Джека Уэлча в General Electric этот подход (МВО) отрабатывался как один из первых (в его арсенале) и он от него отказался как от безперспективного. Факт не абсолютный, но достаточно интересный, мне кажется. 2003-09-01 19:18:46 Відповісти Sergiy, cape@ukr.net Анатолий, Ну, я бы сказал, что MBO просто примитивен. И сам по себе действительно не имеет перспектив. Хотя, несомненно, всегда надо ставить перед собой цели и добиваться их достижения. В этом смысле MBO можно рассматривать, вероятно, как некий фундамент для построения системы регулярного менеджмента. 2003-09-02 09:15:43 Відповісти kenneth villarubia, ksvillarubia try to show the version in English 2003-09-08 13:41:36 Відповісти Геннадий Ратнер, lama-consult@ukr.net Наукооразная статья.Опять западники нас, как недоумков, учат, как нам у себя, в наших условиях, стимулировать наш персонал, да с учётом наших же уровней среднерыночных зарплат.И в Украине, и в России успешно внедряются отечественные разработки гибких систем стимулирования. С одной из них - РОС-квинта - заинтересованных могу познакомить на уровне разработки под ключ, в т.ч. и с ПО 2004-03-03 19:52:11 Відповісти Сергей Тимофеев, tsa@invelta.com.ua Согласен, что нам преподносят хорошо забытое старое в новой упаковке. К сожалению, бывает, что западные консультанты "творчески перерабатывают" чужие идеи, а потом их продают нам же. Хотя бывает и наоборот. 2004-04-21 16:39:06 Відповісти San, kallipso22@nm.ru Для того, чтобы понять суть "управления по целям" необходимо поработать в этой среде. Могу ответственно заявить, что менеджеры, прошедшие практическую школу МВО, говорят на разных языках с теми, кто эту школу не прошел. Может ли быть применима система МВО в России - может и уже работает (несмотря на славянский менталитет). 2005-03-21 15:42:57 Відповісти Максим Могилевец, maxymmogylevets@ukr.net Подход, я бы даже сказал "философия" управления по целям (MBO) очень широко распространена и довольно успешно применяется. Однако есть определенные недостатки данной философии, которые могут компенсироваться подходом управление при помощи проектов (management by projects). Вот небольшой анализ данных подходов: http://www.pmblog.com.ua/?p=155 2011-04-01 15:54:04 Відповісти |
| Якщо Ви бажаєте подискутувати із конкретним читачем, то це можливо робити безпосередньо в нашому форумі. |
| До верху |