что такое технологический риск
Классификация рисков предприятия
На функционирование предприятия влияют риски в виде событий (действий), препятствующих достижению коммерческих целей (стратегических, тактических).
У предприятий обычно нет права владения, пользования и распоряжения своими акциями. Но иногда они заключают договоры на поиск покупателей акций для своих учредителей. Какие риски возникают при этом и как в этом случае минимизировать налоги?
Характеристики рисков
Риски содержат факторы, отличающиеся по времени или месту образования, способу проявления, степени влияния на работу организации. Результатом их влияния может быть неблагоприятная ситуация в виде:
Виды рисков предприятия взаимосвязаны и взаимозависимы. Изменение одного может влиять на другие, усиливая или уменьшая их выраженность.
Риски характеризуют следующие понятия:
Налоговые риски крупных сельскохозяйственных предприятий.
Система классификации
Классификация рисков подразумевает систематизацию их множества по разным критериям, объединяющую подмножества в единые понятия.
При создании классификации учитываются понятия, относящиеся к характеристике рисков, в числе которых:
По периоду возникновения риски делят на:
По характеру учета риски бывают:
В зависимости от последствий риски подразделяют на:
По сфере образования риски делят на:
По причинам возникновения подразделяют риски на политические (война, запрещение вывоза/завоза товаров, запрет на передвижения/перемещения через границу) и экономические, вызванные изменениями в организации или в экономике государства (колебания рыночной конъюнктуры, дисбаланс ликвидности, падение уровня управления).
Исходя из производственного процесса риски делят на:
С учетом потенциальных последствий риски классифицируются на:
Оценка уровня риска
Управление риском требует анализа и оценки, включающей регулярное выявление факторов и видов в сочетании с их количественным определением.
Источниками для выполнения анализа и оценки рисков являются сведения из:
Процедура оценки включает качественный и количественный этапы.
На этапе качественной оценки выявляются источники и причины риска, работы, при которых он образуется и воздействует на хозяйственный процесс. Качественные итоги служат исходной информацией для анализа количественного, оценивающего только проблемные моменты в ходе проведения конкретной операции.
При количественном анализе определяются числовые параметры по отдельным рискам, по потенциальному урону от них. Завершением анализа является подготовка системы противодействующих мероприятий и расчет стоимости их проведения.
Количественная оценка рисков использует методы:
В зависимости от типа воздействия используют следующие методы управления рисками:
Выбор методов оценки или управления производится по каждому риску отдельно с учетом вероятностного ущерба и возможности создания проблемных ситуаций.
Как управлять рисками IT-проекта
Если какая-нибудь неприятность может произойти, она случится — гласит закон Мерфи. И сфера ИТ не исключение.
Команда SEBEKON рассказывает, как работать с рисками в IT-проекте, чтобы риски не стали управлять проектом.
В этой статье под IT-проектом подразумевается разработка сложного веб-ресурса — например, b2b-портала или интернет-магазина с множественными интеграциями с внешними системами.
Дилемма управления рисками любого IT-проекта простая: перестраховаться и заложить все угрозы в бюджет проекта, который вырастет до небес, или пропустить часть рисков — и тогда будет велика вероятность не завершить проект вовсе или получить неудовлетворительный результат.
Но даже если принять первый вариант как единственно верный, от рисков никто не застрахован.
Менеджер проектов компании SEBEKON
Генеральный директор компании SEBEKON
Как работать с рисками
Обычно ожидаемая реализация проекта не совпадает с реальной работой:
На практике управление рисками — это тонкий баланс между разумным и достаточным.
Существуют пять основных инструментов для работы с рисками:
Рассмотрим каждый из них подробнее.
Выявлять риски
Риски проекта определяются во время фиксации требований к проекту и отражаются в уставе или концепции проекта.
Устав проекта ― это документ, в котором зафиксирована основная информация о проекте: потребности заказчика, бизнес-задачи, высокоуровневые требования к проекту, критерии успешной реализации.
Концепция проекта ― документ, в котором собраны подробные характеристики проекта.
Выбор документа зависит от масштаба проекта.
Чтобы выявить риски, нужно проанализировать множество информации и сопоставить, как те или иные факторы влияют на возникновение рисков.
Рассказываем, что стоит сделать для этого.
Учесть опыт предыдущих проектов
Для примера возьмём согласование дизайна страниц сайта.
Дизайн всегда субъективная история, и нужно закладывать дополнительное время на решение вопросов в стиле «а давайте попробуем немного светлее или поиграем со шрифтами». Заказчик должен ещё до начала работ понимать, что любое изменение, требующее нескольких минут работы, в итоге выливается в часы и дни согласования.
Часто на стороне заказчика необходимо согласовать дизайн с несколькими департаментами — и не всегда сотрудники этих отделов могут быстро подтвердить изменения. Если речь идёт о крупной компании, то руководителю проекта придётся назначать собрание или созвон для обсуждения дизайна. И не всегда это получится сделать в ближайшие дни — часто согласование растягивается на недели, а то и на месяцы.
В нашей практике были разные проекты, но редко, когда удавалось согласовать дизайн в первой же итерации и по ходу работы не менять его. Гораздо чаще приходилось сдвигать сроки работ, потому что представители заказчика не смогли оперативно обсудить дизайн и согласовать его.
Оценить новизну критичных требований — как для заказчика, так и для исполнителя
Например, в проекте предполагается разработка нового функционала, которая требует совместной работы нескольких подразделений на стороне заказчика и дополнительных исследований на стороне исполнителя. Всё это увеличивает сроки согласований и влияет на срок проекта.
Принять во внимание особенности внутренней инфраструктуры заказчика
Самый очевидный пример ― требования к безопасности, которые могут существенно отодвинуть срок старта проекта. Это связано с необходимостью получения доступов в систему заказчика или требований по использованию определённого, разрешённого на стороне заказчика ПО, которые повлекут за собой дополнительную проработку архитектуры проекта.
Не забыть про покупку серверного оборудования или про согласование хостинга
Если про покупку хостинга заказчики обычно помнят, то про серверное оборудование в проектах могут забыть и не заложить в бюджет стоимость оборудования, лицензий, а также время на заключение договора с поставщиком оборудования и его доставку.
В зависимости от проекта серверное оборудование может быть стационарным — шкафы с оборудованием — или облачным, когда проект размещается в виртуальном пространстве.
Напоминание заказчику о закупке серверного оборудования на первых же обсуждениях проекта позволит избежать досадных простоев в работе.
Заложить внедрение интеграции проекта с внутренними системами заказчика
Об этом часто забывают, поскольку обычно в организации заказчика под проект выделяются не специально нанятые люди, а текущие сотрудники, у которых есть другая, основная работа. Они воспринимают новый проект как нечто второстепенное, что можно делать по остаточному принципу.
В итоге когда приходит время интеграций проекта с CRM-, ERP- и другими системами работа останавливается на неопределённый срок, потому что менеджер проекта со стороны заказчика не может оперативно подготовить необходимую документацию и доступы для интеграций.
Выявить заинтересованность в проекте ключевых стейкхолдеров
Стейкхолдеры ― это не только топ-менеджмент, но и будущие пользователи и эксперты, которые хорошо разбираются в вопросе и могут помогать с проектом или же оказывать негативное влияние.
На начальном этапе стоит понять, как взаимодействовать с так называемыми негативно настроенными стейкхолдерами, чтобы они не вредили реализации проекта. Под негативно настроенными мы понимаем не тех, кто намеренно вставляет палки в колеса, а тех, кто не понимает последствий от своих решений.
В нашей практике не раз случалось, когда некоторые стейкхолдеры не глядя согласовывали ТЗ, а на этапе тестирования готового проекта выяснялось, что всё должно быть совсем не так.
Например, руководитель департамента логистики должен был проверить сценарий по расчёту доставки товара. Но он был занят текущей деятельностью, мельком просмотрел ТЗ и отправил с пометкой «принято». В ходе тестирования этого сценария оказалось, что он должен быть реализован другим способом. В итоге пришлось откатить проект назад: пересмотреть внесение правок в сценарий, затем внести эти правки в ТЗ, согласовать это со всеми стейкхолдерами, переделать сценарий и заново его протестировать. На всё это ушло больше месяца, а кроме того, заказчику пришлось оплатить дополнительные работы.
Для наглядности можно составить матрицу влияния стейкхолдеров на проект и методы взаимодействия с ними. Например, такую:
Изучить соответствующее законодательство, поговорить с экспертами и опытными коллегами
У более опытных коллег за плечами больше реализованных проектов, они уже набили свои шишки и могут дать полезные советы. Эксперты помогут разобраться в отдельных нюансах относительно, например, сценариев пользователей или специфической функциональности.
При разработке ресурсов для государственных компаний изучение законодательства ― обязательный этап в работе над таким проектом. Например, сайты и порталы для государственных образовательных организаций должны быть сделаны с учётом требований Министерства образования.
Оценивать риски
Риски обязательно соотносятся с критичностью или некритичностью требований к проекту в целом.
Критичные требования отвечают за целевую функцию разрабатываемого продукта, включают необходимую инфраструктуру и возможности для разработки MVP.
К некритичным относятся остальные требования.
Для каждого риска выявляют следующее:
На базе этих параметров строится матрица рисков.
Остановимся подробнее на степени управляемости рисками.
Управляемые — риски, которые можно предугадать и акцентировать на них внимание уже на начальном этапе проекта, определив для них ответственных и держа под контролем.
Самый очевидный пример ― опять же дизайн сайта. Сразу понятно, что на этапе согласования могут возникнуть сложности, доработки, переделки и бесконечные правки. Поэтому мы на старте проговариваем этот момент с заказчиком, согласовываем, кто будет лицом, принимающим окончательное решение, и письменно фиксируем максимально допустимое количество дней на согласование макета — в среднем, по нашему опыту, это обычно 5.
Неуправляемые — возможные риски, появление которых мы не можем предотвратить.
Например, один из неуправляемых рисков ― более ранний выпуск конкурентами на рынок похожего продукта.
Другой пример — подключение платёжной системы. В описании API говорится, что в ответ на запрос придёт одна строка, а по факту приходит три. И платёжная система на своей стороне не готова вносить правку, потому что на это нужно время, при этом тысячи пользователей этой системы об этом не просили. Так как нужна именно одна строка, разработчику приходится самостоятельно решать этот вопрос, тратить больше запланированного времени на разработку и фиксацию данной ошибки.
Запланировать мероприятия по предотвращению рисков
Для предотвращения рисков нужно понимать, как от них защищаться.
Грамотно выстроенные коммуникации внутри проекта играют главную роль для защиты от рисков и оказывают огромное влияние на успех проекта. Это означает, что все процессы взаимодействия регламентированы, роли всех членов команды закреплены и всё это зафиксировано в понятном для участников формате.
Важно сразу выстроить коммуникацию с заказчиками проекта, создать большую команду из представителей обеих сторон и все вопросы решать совместно.Для этого фиксируем ответственных для каждого этапа проекта в матрице «Роли и зоны ответственности» (RACI Matrix).
В матрице предусмотрены четыре роли:
Однако просто зафиксировать ответственных мало — нужно проанализировать заполненную матрицу, чтобы не было перекоса в одну роль:
После того, как разобрались с матрицей ролей, проактивно управляем рисками — фиксируем их и то, что нужно сделать для предотвращения.
Вместе с этим определяем план и способ коммуникаций на протяжении всего проекта: сколько раз в неделю и месяц, каким составом и при наступлении каких событий будем проводить созвоны или очные встречи, какой формат отчётности примем для фиксации договоренностей на этих встречах.
Также определяем инфраструктуру проекта:
Профессия
Project
manager
Предусмотреть действия при наступлении рисков
Стоит предусмотреть резервный план (contingency plan) на случай непредвиденных обстоятельств.
Задача этапа — выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о наступившем риске на будущее.
Не стоит тратить время на поиск виноватых — лучше предпринять всё необходимое, чтобы двигаться дальше и продолжать реализацию проекта. На этом этапе главная роль принадлежит коммуникации и поиску оптимального решения.
В нашей практике был проект, когда нужно было разделить один сайт, реализованный на Bitrix, на два. Один из них надо было интегрировать со штатной версией 1С.
Заказчик предполагал, что на разработку на своей стороне их специалисту понадобится три недели. По факту оказалось, что ранее созданная интеграция полностью кастомная — комплекты, цвета, размеры, остатки — и на стороне заказчика нет эксперта, который смог бы выполнить задачу. Пришлось подключиться нам и помочь с решением по интеграции. Дополнительно были пересмотрены сроки проекта.
Мониторить риски
Ситуация на проекте постоянно меняется ― это нужно принять как аксиому.
Например, если работать по Agile, то перед каждым новым спринтом могут меняться параметры проекта, обрисованные на этапе обсуждения. Следовательно нужно отслеживать изменения параметров рисков, корректируя внутрикомандный перечень топ-10 рисков.
На этапе мониторинга — если возвратиться к примеру с Agile, то это нужно делать в начале каждого спринта — важно отслеживать новые риски, изменять статус выявленных рисков, корректировать планы. На протяжении проекта перечень может значительно измениться.
К примеру, на крупном проекте на финальном этапе в команде заказчика появляется эксперт, который задаёт много вопросов и предъявляет новые требования к проекту, которые подразумевают изменение архитектуры проекта и кода. Если инициировать эти изменения, то есть риск сорвать плановые сроки реализации проекта.
Как вариант — провести встречу, обсудить, что беспокоит эксперта в текущей архитектуре, объяснить, почему реализовано именно так и наметить дальнейшие шаги. При этом важно постараться не увеличить объём работ проекта и не выйти за временные и финансовые рамки.
Каждый участник команды должен понимать важность работы с рисками
Ключевой момент управления рисками — их постоянное отслеживание и предотвращение, в идеале согласованное с длительностью циклов разработки проекта.
Оценка рисков и работа с ними зависят от размера и длительности проекта. Рекомендуем возвращаться к работе над рисками один раз в 1‒2 недели, в некоторых крупных проектах периодичность может быть увеличена до месяца.
Лучше составить неполный перечень рисков, чем не составить его вовсе.
В процессе общения с разработчиками или заказчиком лучше забыть фразу «все и так всё понимают»:
Главное в работе с рисками ― донести до всех участников проектной команды необходимость работы с рисками. Прежде всего нужно стараться не допускать наступления рисков, анализировать прошлый опыт и причины наступления для составления перечня возможных рисков в новых проектах, предотвращать непредусмотренные риски.
Пример перечня рисков проекта с комментариями и статусами можно посмотреть здесь.
Этапы оценки проекта: понятия, методы и полезные инструменты
Кто такой проджект менеджер, чем он занимается и как им стать
Как компаниям общаться с клиентами: ключевые тенденции и полезные советы
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
Риски на пути к цифровой трансформации бизнеса: как их избежать?
Операционный директор IT-компании SimbirSoft
Цифровая трансформация требует предельно серьезного подхода, иначе путь к ней может только навредить компании. Но зато успешное завершение этой трансформации станет важным шагом в развитии бизнеса.
О типичных и нетипичных рисках при проведении цифровой трансформации и о том, какие технологические инструменты помогут руководителям справиться с этими рисками, рассказывает операционный директор ИТ-компании SimbirSoft Дмитрий Петерсон.
В проекте Dig(IT)al рассказываем о технологиях, которые помогут вам заработать. Переходите на цифровую сторону бизнеса.
Компании подходят к цифровой трансформации с разных стартовых позиций.
Одни это делают по решению топ-менеджмента в рамках заранее согласованного бюджета.
При этом системы и инфраструктура или службы компании могут быть не готовы, а специалисты могут не иметь всей информации и ресурсов для того, чтобы расставить приоритеты.
Другие четко осознают, для чего нужно внедрять цифровые технологии.
Расскажи, как цифровая трансформация изменила твой бизнес
У таких компаний внутри есть ИТ-евангелист, возможно, из топ-менеджмента, который в попытках обратить сотрудников в «цифровую веру» берет на себя всю ответственность, изучает, планирует, набирает команду и подрядчиков.
Третьи относятся к цифровизации скептически, но, глядя на конкурентов, понимают, что это нужно делать, иначе отстанут.
Эта группа компаний не обладает знаниями, с чего начинать и какой бюджет закладывать. Обычно в таких случаях они начинают изучать опыт других.
Перед началом цифровой трансформации бизнеса важно проанализировать все бизнес-процессы и решить, что и как оцифровать, а также подготовить всю инфраструктуру в офисе и на производстве.
Но главным связующим звеном между всеми процессами выступают люди, сотрудники и топ-менеджмент компании, со своими знаниями, навыками и ценностями.
Поэтому одни бизнесы могут столкнуться с описываемыми ниже рисками, а другие нет.
Универсального решения по цифровой трансформации компании, которое поможет избежать проблем, нет.
Но есть базовые (применимые для разных сфер деятельности) работающие инструменты.
При правильном использовании они способны минимизировать риски и помочь компании пройти по пути цифровой трансформации, достигнув нужных результатов.
Типичные риски цифровой трансформации бизнеса
От инвестиций в цифровизацию бизнес хочет получить улучшение клиентского опыта, оптимизацию процесса управления, принятия релевантных решений и безопасность (сохранность информации и персональных данных, контроль доступа сотрудников к определенным зонам или данным).
Качество отношений с покупателями и пользователями определяет настоящее и будущее любого бизнеса.
Использование цифровых решений на всех этапах взаимодействия с ним – один из возможных вариантов улучшить сервис, а значит и клиентский опыт.
Главное – правильно настроить процессы, связать все каналы коммуникации между собой (при помощи омниканальной платформы) и CRM компании в единую систему. если она будет работать с нарушениями, возрастает риск потерять даже лояльных потребителей.
Любой бизнес всегда опирается на людей, и речь идет не только о клиентах, но и о сотрудниках.
От их профессиональных и личностных качеств зависит функционирование компании, принятие решений и конечный результат – успех или поражение любого проекта.
Но при цифровой трансформации, поскольку она касается более глубинных преобразований внутри компании и не ограничивается только внедрением технологий, можно столкнуться с кадровыми рисками.
Например, с неготовностью и сопротивлением изменениям сотрудников или топ-менеджмента компании по разным причинам, необходимостью сокращения или резкого увеличения численности персонала.
В ходе цифровой трансформации руководитель может понять, что его компании не хватает квалифицированных и опытных специалистов, способных правильно выстроить процессы, обучить действующих сотрудников работе с новыми технологиями, а также управлять их адаптацией.
Значит их срочно надо найти, нанять и быстро включить в решение поставленных задач.
Проведение цифровой трансформации может сопровождаться нарушением коммуникации между разработчиками программного обеспечения и лицом, принимающим решения (ЛПР), между руководителем и сотрудниками, а также внутри коллектива.
Информация может либо не доходить совсем, либо искажаться и быть неправильно воспринята, а в итоге отразиться на работе и конечных результатах.
В век цифровых технологий возрастают риски управления данными.
Среди наиболее частых – утечка информации, нарушение конфиденциальности, несанкционированный доступ с разными целями к данным компании или сотрудникам.
На старте есть риск неверно обозначить показатели, по которым можно будет определить успешность проекта цифровизации.
Избежать этого помогут регламенты и другие правила, рекомендации и инструкции, документация с четко прописанными KPI (дорожные карты, спринты и прочее), а также обучающие материалы для повышения квалификации сотрудников.
Все они должны быть доступными для ознакомления всему персоналу компании.
Управление этими рисками можно сделать легче, если использовать следующие инструменты (подходят для любого бизнеса):
В условиях повышенных рисков можно установить DLP-системы – программные продукты, защищающие организации от утечек конфиденциальной информации вовне.
есть примеры, когда такие инструменты вместе с корпоративными мессенджерами помогли службам безопасности компаний вычислить недобросовестных сотрудников, которые передавали контрагентам инсайдерские сведения.
Нетипичные риски цифровой трансформации
Ситуация № 1 – риск времени
Он частично возникает при использовании готовых ИТ-решений, которые предлагают клиентам при цифровой трансформации их компаний. Поясню на примере финансовой сферы.
Многие банки начинали с использования готовых решений, например, для мобильного банкинга.
Но они столкнулись с тем, что у всех были практически одинаковые приложения – по функциям и интерфейсу.
Сейчас в погоне за клиентом каждый стремится применить какие-то уникальные фичи, чтобы сделать сервис удобным и привлекательным для пользователя.
Расширение функций готового решения вендора требует много времени.
Сроки внесения изменений могут затянуться, а бизнес рискует отстать от конкурентов или недополучить клиентов.
К тому же, здесь есть риск, что интересная фича, которую вендор внедрил по вашему предложению, вскоре появится и у других пользователей этого решения.
Во многом именно по этим причинам ведущие банки перешли к созданию уникальных ИТ-продуктов.
У компании сегодня есть выбор – купить готовое коробочное решение или заказать индивидуальную разработку. Что подходит вам, решайте, исходя из текущих потребностей и ресурсов.
Ситуация № 2 – риск оверворкинга
Россияне, конечно, далеки от таких переработок, как в Японии, и кароси нам не страшны. Тем не менее, в отечественных компаниях овертаймы тоже случаются.
Согласно опросу Superjob, только трое из десяти россиян работают строго по графику, не задерживаясь по вечерам.
Со временем переработки, пусть даже на любимой работе, могут привести к профессиональному выгоранию, хронической усталости или конфликтам в коллективе.
В таких случаях в работу можно интегрировать некоторые инструменты.
Они позволяют посмотреть статистику по проекту или каждому специалисту, чтобы руководитель мог обратить внимание на переработки сотрудников.
Как извлечь максимум при использовании предложенных инструментов
Вице-президент, главный аудитор и руководитель по управлению стратегическими рисками General Motors Джозеф Пиззуто провел аналогию между управлением рисками в компании и наличием тормозной системы в автомобиле.
По его словам, ее назначение – дать возможность ускориться без ущерба для контроля.
Так же и в ситуации управления рисками – когда у руководителя есть необходимые средства контроля, можно смело идти вперед и двигаться быстрее.
Все перечисленные инструменты работают, но если они подобраны неправильно, эффект от внедрения не решит поставленных задач.
К тому же, сегодня комплексные ИТ-решения, которые учитывают риски, стоят дорого. Оценив стартовую стоимость инструмента, вы его покупаете, а позже выясняется, что его поддержка и абонентская плата сведут на нет все выгоды от его приобретения.
Чтобы не выйти за рамки бюджета, потребуются профессионалы:
Если вы понимаете, что для внедрения всех решений на данном этапе недостаточно ресурсов, можно следовать японской методике кайдзен и улучшать процессы постепенно пусть небольшими шагами, но непрерывно.
При выборе ИТ-инструментов стоит отталкиваться от имеющихся входных данных, планируемых целей / результатов и ресурсов компании.
Задача руководителя – расставить приоритеты и выявить узкие места, понять, какая основная проблема стоит перед бизнесом сейчас, и сосредоточить усилия по цифровой трансформации именно на ней.
Например, риэлторскому агентству на первом этапе может быть достаточно классической CRM, которую можно настроить под свои потребности.
Затем можно завести мобильное приложение, настроить систему электронного документооборота и так далее.
А логистической компании можно начать с таск-трекера, далее внедрить систему управления складом, а потом и какой-нибудь агрегатор совместно с партнерами.
Прежде чем внедрять готовое решение, проведите предварительную оценку, во сколько вам обойдется его кастомизация с учетом специфики вашей деятельности.
Некоторым видам бизнеса со специфическими бизнес-процессами или услугами проще и дешевле выбрать уникальное решение.
Многие крупные компании пишут их под себя сами или заказывают ПО у специалистов. Главное – ИТ-решения должны окупиться и принести выгоды для вашего бизнеса.