Рубрика «управление рисками» - 2

Привет, коллеги,

в конце прошлой недели International Security Forum опубликовал очередной ежегодный отчёт о грядущих трендах ИТ-угроз бизнесу Threat Horizon 2019. Отчёт содержит подробные описания девяти основных угроз, а также информацию об их воздействии на бизнес и рекомендуемые действия.

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

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

В комментариях предлагаю описать актуальность приведённых выводов и рекомендаций для вашей организации.
Читать полностью »

В данной публикации я приведу практический пример использования системы принятия решений и управления рисками, только не на предприятии, а в обычной жизни. Этот подход я использовал лично и подтвердил его работоспособность. Как минимум на психологическом уровне, так как ни один из описанных рисков, к счаcтью, не сработал.
Читать полностью »

Мы в Solar Staff много сотрудничаем с партнерскими сетями, поэтому решили написать небольшой цикл статей о том, как работает партнерская сеть с точки зрения права.

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

VaR как способ оценки риска. Исторический метод - 1

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

Главные идеи VaR были разработаны и применены в банке JP Morgan в 80-х. Широкое применение VaR получил в 1993 когда был одобрен Группой тридцати(G-30) как часть “лучших практик” для работы с деривативами(производными финансовыми инструментами). А позже стала одним из показателей риска банка по системе Базель II (набор международных рекомендации по банковскому регулированию). Идею используемую в VaR можно отследить до ранних работ лауреата нобелевской премии по экономике Гарии Марковица в 1952.
Читать полностью »

Вы стоите на пороге новой организации и перед вами комплексная задача по запуску нового оборудования, системы и/или программы. Продажную составляющую пропускаем и переходим непосредственно к исследованию задачи, где наш проект очерчен бюджетом, сроками и задачами. Важно не забывать, что одна грань успешного запуска — психология входа на проект и взаимодействия с сотрудниками. Ведь любой технологией управляет человек, и именно с ним произойдёт первичный контакт по сбору данных.
Читать полностью »

image

Главная цель L&D — перемены. Это просто не стоит оспаривать, изменения неизбежны и L&D (обучение и развитие в компании) автоматически будет успешным. Успешный L&D нуждается в осторожном планировании и менеджменте – и тут вступают в игру правила управления проектами. Давайте поговорим о них.Читать полностью »

Недавно после очередного Team Building’a получил от одного Коллеги-Графомана письмо-притчу про большую кнопку «сделать всё хорошо». Он и раньше баловался изобретением велосипедов, но, в этот раз конструкция показалась мне очень удачной. Кому интересно — прошу-приглашаю под кат. С его разрешения дословно:

В эту сиесту на веранде практически никто не курил, потому, что все ушли на очередной двухдневный SCRUM тренинг. Джонни устало окинул взглядом присутствующих: Дёму и Варю. Они тоже не были в восторге от происходящего, было слишком жарко и душно, лето в Долине было в самом разгаре, и казалось, что на улице даже жарче чем в Task Tracker’е.

Читать полностью »

Человеческий фактор остается самым сильным, но выгодным риском в разработке ПО - 1
Изображение с сайта projectimo.ru

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

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

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

image

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

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

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

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

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

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

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

И вот когда к новоиспеченному руководителю проекта приходит понимание всех этих моментов, у него иногда возникает некий «кризис ответственности». С одной стороны, результат проекта почти всегда сформулирован так, что новоиспеченный руководитель проекта вроде бы не должен за него отвечать, исходя из того, что описано в его должностных обязанностях. С другой стороны, бонусами за достижение результата проекта часто могут быть дополнительная финансовая премия и/или возможное повышение. Да и сама возможность примерить на себя «пиджак менеджера» тоже может быть интересной. Поэтому очень важно на старте проекта договориться с шефом о границах вашей «управленческой самостоятельности», даже если шеф сам не настоял на этом. Например, текущее отклонение по срокам исполнения на один — два – три дня не требует от вас немедленной эскалации (официального уведомления) этой ситуации шефу, конечно при условии, что вы сами знаете, как в дальнейшем устранить отставание. А выявление более длительного отставания, обязательно нужно эскалировать. Аналогичная история с возможными отклонениями по стоимости и объему работ, выполняемых подрядчиком по контракту. И хотя большинство подрядных работ в России выполняется по контрактам с фиксированной ценой и фиксированным объемом работ, далеко не все и не всегда идет так, как записано в контракте.

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

Успехов вам в управлении проектами и покорении корпоративного Олимпа!
Автор: Олег Тумасов, главный редактор журнала «Управление Проектами».
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js