Оценка эффективности работы сотрудников

Цитата:

---

Сообщение от Александр Болдин

сложные формулы с коэффициентами по 3 знака после запятой отражают...

---

Неинтересно с тобой :)
Хотел сказать то же почти дословно. Пережил несколько таких экспериментов на АЭС, сценарий всегда один "шумиха-неразбериха-пшик"

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

Ольга
Вы не устраняете экспертов, а узурпируете их права. Плюс-решение может быть более оптимальным. Минус-оно не будет работать так как все более-менее серьезные вещи делаются только на основе соглашения. Не в смысле "документ", а в смысле "мы договорились"

Цитата:

---

Сообщение от Михаил_Шустер

Пережил несколько таких экспериментов на АЭС, сценарий всегда один "шумиха-неразбериха-пшик"

---

Угу. Я наблюдал процесс в крупнейшей телеком-компании России.

Хотели как лучше, а получилось как всегда.
(с) В.С.Черномырдин

Цитата:

---

Сообщение от Михаил_Шустер

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

---

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

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

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

Цитата:

---

Сообщение от Александр Болдин

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

---

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

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

Цитата:

---

Сообщение от Оля?

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

---

Цитата:

---

[...]
Проблема заключается в отсутствии методики формирования единого коэффициента работы сотрудника на основе критериев.

---

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

Я так понимаю, что коэффициент нужен для того, чтобы назначить вознаграждение сотруднику. Тогда надо смотреть, какую value он добавил: и считать её ровно по вашим разработанным критериям (но только потому, что они уже есть).

Если стратегическая цель, конечно, поднимать value предприятия.

А я за то, чтобы часть мотивации, причем совсем не малая часть, состояла из ОБЪЕКТИВНЫХ ПОКАЗТЕЛЕЙ. Выбрать 2-4 проблемных напраления, проработать целевые показатели по этим направлениям.

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

Но все считать по принципу- нравится, не нравится... Не красиво.

Цитата:

---

Сообщение от Auk

А я за то, чтобы часть мотивации, причем совсем не малая часть, состояла из ОБЪЕКТИВНЫХ ПОКАЗТЕЛЕЙ. Выбрать 2-4 проблемных напраления, проработать целевые показатели по этим направлениям.
Если нужно, чтобы начальник вожжу имел - давайте отдадим ему часть стимулирующего фонда...
Но все считать по принципу- нравится, не нравится... Не красиво.

---

Объективно высчитать показатели (пусть и 2-4) можно только в модели. реальность накладывает неимоверное количество субъективных факторов, таких как опыт работы, стаж, способность преодолеть форс-мажор, личные мнения всех, разное вИдение ситуаций и т.д. Посему всё будет лишь условно-объективно, и будет стимулировать одних и тормозить других. Для того, чтобы суметь выполнить показатели, нужны соответствующие полномочия, а с этим всегда сложно - с соответствием полномочий. Да и планирование, как стратегическое, так и тактическое, должно быть хорошо развито. В итоге как правило объективность сводится к мнению начальника...

Цитата:

---

Сообщение от Консул

Объективно высчитать показатели (пусть и 2-4) можно только в модели. реальность накладывает неимоверное количество субъективных факторов, таких как опыт работы, стаж, способность преодолеть форс-мажор, личные мнения всех, разное вИдение ситуаций и т.д. Посему всё будет лишь условно-объективно, и будет стимулировать одних и тормозить других. Для того, чтобы суметь выполнить показатели, нужны соответствующие полномочия, а с этим всегда сложно - с соответствием полномочий. Да и планирование, как стратегическое, так и тактическое, должно быть хорошо развито. В итоге как правило объективность сводится к мнению начальника...

---

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

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

не совсем вижу, чем обусловлен скепсис ?

Цитата:

---

Сообщение от Auk

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

---

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

Цитата:

---

Сообщение от A.Megerova

попробуйте применить метод анализа иерархий

---

"Эксплуатируя" иерархии, давно столкнулся с проблемой, которая сегодня вышла на первый план. Несмотря на кажущуюся простоту иерархической декомпозиции, люди (в том числе весьма умные) очень и очень долго не вьезжают, хотят специальных терминов.
Скажем, понятие "проект". Есть дополнительные термины "мультипроект", портфель", "подпроект", "группа задач", "задача", "операция", итого 7 уровней. В сложных, хорошо структурированных проектах, уровней могут быть десятки - не станешь же каждому давать имя! Говорить "проект первого (второго, ...) уровня" - коряво, громоздко и ровно ничего не решает
То же "процесс" (надпроцесс, подпроцесс), цель, функция и т.п.

Терминология - полбеды. Не хватает слов объяснить, что является "объектом" проектного подхода. Есть "проект", с которого начинается "чистый" ПМ, где все ясно и понятно. Компановка проектов по портфелям-начинаются проблемы с ортогональностью классификатора (не начинаются только в строительных проектах), составление мультипроекта-полиморфизм, наследование. В общем, то, что у меня получается с полоборота, людей загоняет в ступор.
Надеялся на РМВООК - напрасно. Читали, не помогает. Нет там чего надо. Ступор возникает, когда нужно "разложить" конкретный сложный проект на составные части, определить структуру работ и превратить их в процесс. Не получается у людей СРР. В виде абстракции-все ОК, как только доходит до конкретной прикладной области-рождаются уродцы.

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

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

Цитата:

---

Сообщение от Михаил_Шустер

Терминология - полбеды. Не хватает слов объяснить, что является "объектом" проектного подхода. Есть "проект", с которого начинается "чистый" ПМ, где все ясно и понятно. Компановка проектов по портфелям-начинаются проблемы с ортогональностью классификатора (не начинаются только в строительных проектах), составление мультипроекта-полиморфизм, наследование. В общем, то, что у меня получается с полоборота, людей загоняет в ступор.
Надеялся на РМВООК - напрасно. Читали, не помогает. Нет там чего надо. Ступор возникает, когда нужно "разложить" сложный проект на составные части, определить структуру работ и превратить их в процесс. Не получается у людей СРР. В виде абстракции-все ОК, как только доходит до конкретной прикладной области-рождаются уродцы.

---

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

Цитата:

---

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

---

Дак а как этому научить-то... методики что-ли есть специальные, декомпозиции? ООП - просто аналитическая парадигма, инструмент описания задач (кстати Буч не сильно сложная книга должна быть для тех, кому предстоит заниматься построением этих самых проектных ИСР). Решение каждой конкретной задачи всегда конкретно.

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

Цитата:

---

Сообщение от Михаил_Шустер

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

---

SADT. Дэвид А. Марк и Клемент МакГоуэн

Цитата:

---

Сообщение от Andruxa

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

---

ООП определяет "объект" и учит им пользоваться.
А объект - он объект хоть в проектной, хоть в какой деятельности...
Это элементарная частица управления

Цитата:

---

Сообщение от Andruxa

опыта недостаёт у этих людей

---

Это правда. Люди эти-прикладники. Исхожу из "Каждому-свое". Мне нужно только внедрить систему планирования. Планировщиков не может быть много

Цитата:

---

Сообщение от Andruxa

у вас много чего понамешано вместе в кучу

---

И это правда :)
С помощью иерархий и РМ решается любая задача.
Например, построение СМК, СУЗ... (что казалось бы совсем из другой оперы)

Цитата:

---

Сообщение от via

SADT. Дэвид А. Марк и Клемент МакГоуэн

---

Большое спасибо - но нет.
Это нужно читать аналитикам. Моя проблема-прикладники.
Наверное безнадежный вопрос. Вряд ли существует "Иерархии для чайников", у такой книги просто нет аудитории.

Михаил,
1. "Построение иерархии" не является частным случаем "классификации"?
2. А не подскажете ссылочку на какой - нибудь источник по классификации, где бы можно было разобраться в Ваших "любимых" наследованиях, полиформизмах и инкапсуляциях?

Цитата:

---

Сообщение от Евгений_Кс

"Построение иерархии" не является частным случаем "классификации"?

---

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

Цитата:

---

Сообщение от Евгений_Кс

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

---

С удовольствием
http://www.helloworld.ru/texts/comp/other/oop/ch01.htm
Но это только еще больше все запутывает :)

Цитата:

---

Сообщение от Михаил_Шустер

ООП определяет "объект" и учит им пользоваться.
А объект - он объект хоть в проектной, хоть в какой деятельности...
Это элементарная частица управления

---

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

Цитата:

---

Это правда. Люди эти-прикладники. Исхожу из "Каждому-свое". Мне нужно только внедрить систему планирования. Планировщиков не может быть много

---

Видите, Вы идеолог... так и напишите методологию "для чайников" в таком случае.

Цитата:

---

С помощью иерархий и РМ решается любая задача.

---

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

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

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

Цитата:

---

Сообщение от Andruxa

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

---

Слова "конечная по времени с четким результатом" давайте выбросим. Даже РМВООК это позволяет (если правильно трактовать "управление неопределенностью")
ЛЮБАЯ ЗАДАЧА может быть представлена в виде проекта

Цитата:

---

Сообщение от Andruxa

изваяв абстрактные классы работ и наследования между ними... классы, описывающие объекты-медиаторы, организающие взаимодействие между работами и, по всей видимости, формирующие процесс (я близко?)

---

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

Цитата:

---

Сообщение от Михаил_Шустер

С удовольствием
http://www.helloworld.ru/texts/comp/other/oop/ch01.htm
Но это только еще больше все запутывает :)

---

1. Спасибо.
2. К сожалению, Вы правы, как обычно. Это я насчет "запутывает"

Цитата:

---

Сообщение от Михаил_Шустер

Слова "конечная по времени с четким результатом" давайте выбросим. Даже РМВООК это позволяет (если правильно трактовать "управление неопределенностью")
ЛЮБАЯ ЗАДАЧА может быть представлена в виде проекта

---

Хорошо, давайте... напишем "управление сроком" и "управление содержанием".

Цитата:

---

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

---

Тогда и порекомендуйте какую-нибудь книгу, "ООП для чайников". Наверняка такое есть...

Другое дело, что ООП - создавался как способ организации кода, по-крайней мере программисты, знакомые с такими завитушками как языки пятого уровня, функциональные ЯП и т.д. и т.п. этот подход только так и понимают. Другое дело, что ребята из OMG (omg.org) + Rational начали на этом поднимать кучу технологий + решения "от создателей!".

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

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

А, а и действительно. Всё зависит от методов класса Работа.
Например,

РаботаКонкретная - подкласс РаботыВПринципеВообще;

// допустим,
копание_рва - РаботаКонкретная;
прокладка_труб - РаботаКонкретная;

// тогда, например, где-то в совсем др. месте

работа1, работа2 - РаботаВПринципеВообще;
работа1 = копание_рва; работа2 = прокладка_труб;

// поехали :)

ЕСЛИ работа1->производительность() > работа2->производительность() ТО
{ работа1->начать(); работа2->начать(); }
ИНАЧЕ
{ работа1->начать(); работа2->ждать(); }

Умопомрачительный интеллектуальный экзерцисс.

Цитата:

---

Сообщение от Евгений_Кс

1. Спасибо.
2. К сожалению, Вы правы, как обычно. Это я насчет "запутывает"

---

Люди. Не отметайте книгу Буча сразу - она написана очень просто и совсем не для программистов. Рекомендую читать ее в виде книги (на бумаге а не электронно) - загадочно, но так идет гораздо веселей.

Цитата:

---

Сообщение от Михаил_Шустер

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

---

Все, как обычно, просто... Люди мыслят нелинейно, а рисуют и пишут линейно.
По существу, мы имем дело с сетью объектов, в которой одни узлы сильнее (выше) других. Строя иерархию ты делаешь срез этой сети, используя некую координатную плоскость. Все нормально, но надо быь готовым к тому, что видно будет не все связи ... и не все узлы.:-)

PS. Впрочем, я тебе уже все это рассказывал. Как сделать, чтобы это было понятно производственникам - не знаю. Может быть, пока. :-)

Цитата:

---

Сообщение от Александр Болдин

Люди мыслят нелинейно, а рисуют и пишут линейно

---

Мой апплодисмент. Сказано!

Цитата:

---

Сообщение от Александр Болдин

надо быть готовым к тому, что видно будет не все связи ... и не все узлы.:-)

---

Эту-то задачу я решил :)
С помощью проекций на разные классификаторы

Цитата:

---

Сообщение от Александр Болдин

Люди. Не отметайте книгу Буча сразу - она написана очень просто и совсем не для программистов

---

Присоединяюсь. Истинная правда и язык хороший :)

Цитата:

---

Сообщение от Andruxa

Ведь ООП-ООПом, а все равно где-то внутри вшиты алгоритмы, процедуры и пр

---

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

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

В примере с "копать" не понял, в чем откровение? :)

Аа, всё, понял теперь о чем речь. Что-то по типу OLAP-кубов, или Business Objects. Я немного другое подумал.

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

Цитата:

---

Сообщение от Михаил_Шустер

Большое спасибо - но нет.
Это нужно читать аналитикам. Моя проблема-прикладники.

---

Ну, тады, Метот McKinsey, Часть первая: "Осмысление бизнес-проблем методом McKinsey, раздел I: Построение решения.
Десять страниц банальщины. Но... Может поможет.

Цитата:

---

Сообщение от Andruxa

Что-то по типу OLAP-кубов

---

Не понял. ОЛАП-просто игрушка, как и датамининг.
Имеете в виду Камшу, Контур?

Нет, я имею ввиду сам подход к организации данных. Различные срезы.
Сам подход к организации как к системе мне понятен. Я применение классификаторов понимал несколько иначе.

Цитата:

---

Сообщение от Михаил_Шустер

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

---

Здорово. Можно я это буду использовать? С копирайтом конечно ... у нас уже куча народа знает М.М.Шустера по афоризмам.
:)