Pull to refresh

Comments 22

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

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

Поэтому и необходимо в течение всего срока проекта регулярно про считывать риски с учётом всех его изменений. То есть расчёт и оценка рисков - это постоянный процесс. А не единоразовая акция при старте :))

Нормально так. Назначаешь по красавице на каждую команду, платишь каждой по минималке как минимум )

Какова обычная практика?

Это я к тому что

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

Ну и все такие руководители в совокупности "отжирают" львиную долю бюджета проекта, наверное? ЗП же нужно платить.

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

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

И, да: после декрета - дважды в одну воду не входят)

ЗЫ: статья прекрасна! И реестр рисков, и проектный треугольник, -- бесподобны!

Риск имеет как негативную, так и позитивную сторону. Дело в том, что при переводе с английского слово «риск» имеет значение «шанс».

================

Не совсем точно. Сссылаться на перевод в вопросе, по которому написаны целые тома, минимум ошибочно. Не в каждом риске есть шанс (возможность улучшения), если есть риск упасть с 20 этажа, то шанса научиться летать нет.

Откуда взялись цифры в таблице? Вероятность девушка ветренная, работает только в больших цифрах и верить вероятностям в масштабе одного предприятия является самообманом. Лучше ограничиться качественной оценкой рисков без перехода на количественные. Хотя известна количественная оценка рисков для "блондинок":

Какова вероятность встретить маньяка в городе?

  • 50%

    • Почему?

    • Может встречу, может нет!

Добрый день. Шанс может быть и положительным и отрицательным. Также как и риск - можно рискнуть и не взлететь, а можно использовать шанс и полететь на самолёте :))

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

Извините, но Вы путаете теплое и мягкое. Отрицательных шансов не существует принципиально. Отрицательный шанс это риск. Для начала простейшее определение: Риск это неопределенность в достижении поставленных целей. Например цель вымыть окно на 20 этаже. Риск выпасть из этого окна. Шансов никаких нет. Шанс остаться в живых не рассматриваем ибо его вероятность близка к нулю.

Полететь на самолете означает породить новые риски. К реализации шанса полет не имеет никакого отношения. Пример классического (правда незаконного) использования шанса:

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

Произвольные цифры в таблице анализа рисков больше чем преступление. Это ошибка! Все цифры могут появится исключительно по Теории вероятности и/или Математической статистике. Ссылка на реальный проект не стоит ни копейки. Лапша на ушах!

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

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

Добрый день, да.

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

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

А для проекта по организации выездного мероприятия - пошёл дождь, а укрыться негде, потому что не учли, что погода может измениться и не предусмотрели тенты :))

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

Согласна, градуировка по направлениям тоже важна. Такая классификация весьма удобна.

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

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

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

Добрый день.
Истинный управленец управляет в любых условиях, включая условия неопределенности. Иначе он просто исполнитель.
Что же касается внедрения софта, то могу сказать, что хозправо и судебная система работают не только в отношении него, а в целом по любому договору и разрешают ситуации в рамках условий договора.
А на проект могут влиять факторы, никак не зависящие от условий договора и вот ими (рисками) и нужно управлять: принимая ситуацию, предупреждая её или снижая её влияние на проект.

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

И простите, какие факторы, никак не зависящие от условий договора:

Внезапная смена ТЗ, при которой никакой аджайл не поможет или отсутствие у клиента на дату начала проекта подготовленной проектной команды и специалистов по 1С? Или неприятие его коллективом изменений?

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

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

Я к тому что в статье краткий пересказ PMBOK'а в свободной форме :)

А желательны стандарты серии ИСО 31000. Правда после них такие статьи читать очень тяжело- что-то для первого курса. :))

Вы ошибаетесь. Управление рисками осуществляется по 4 направлениям. Одно из них - исключение риска. Никакого влияния, есть риск дождя (неуправляемое событие) - сисдите дома и этот риск Вам не страшен. И т.д. и т.п.

Sign up to leave a comment.

Articles