Если заказчик требует бесплатно исправить ошибки проекта то это риск

Согласно ст. 716 ГК подрядчик по договору подряда на выполнение проектных и изыскательских работ несет ответственность за ненадлежащее выполнение проектно-сметной документации и изыскательских работ. Это касается и недостатков, обнаруженных в ходе строительства, а также в процессе эксплуатации объекта.

При обнаружении недостатков подрядчик по требованию заказчика обязан безвозмездно переделать проектно-сметную документацию и произвести необходимые дополнительные изыскательские работы. Безвозмездность подтверждает подп. 3.6 п. 3 СНБ 1.02.06-98 «Порядок определения стоимости разработки проектной документации в строительстве». В соответствии с ним работы по исправлению ошибок, допущенных проектной организацией, не требуют дополнительной оплаты и должны учитываться в стоимости основных проектных работ.

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

Кроме того, в соответствии со ст. 716 ГК подрядчик обязан также возместить заказчику причиненные убытки, если законодательство или договор не определяют иного. Аналогичную норму содержал п. 28 Положения о договорах подряда на выполнение проектных и изыскательских работ. Теперь ее закрепляют п. 59 и 60 Правил заключения и исполнения договоров подряда на выполнение проектных и изыскательских работ и (или) ведение авторского надзора за строительством.

Таким образом, недостатки в проектной документации, допущенные по вине подрядчика и выявленные в процессе строительства объекта, подрядчик устраняет за свой счет в согласованные сторонами сроки. За несвоевременное устранение уплачивает неустойку. Ее размер составляет 1 % от стоимости работ по устранению дефектов за каждый день просрочки начиная со дня окончания согласованного сторонами срока.

Если недостатки в проектной документации привели к дополнительным затратам заказчика, подрядчик обязан возместить их в порядке, установленном договором. Указанные затраты являются убытками заказчика и взыскиваются на основании ст. 14 и 364 ГК.

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

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

Суду, рассматривающему экономические дела, подведомственны споры о понуждении проектировщика к устранению недостатков в проектной документации в соответствии со ст. 716 ГК.

Пример 1

Суд частично удовлетворил исковые требования КУП «Заказчик» к РУП «Проектировщик» о взыскании убытков. Принимая такое решение, суд руководствовался следующим.

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

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

Вместе с тем, оценивая степень вины ответчика, суд отметил следующее. При обнаружении недостатков в проектно-сметной документации или в изыскательских работах подрядчик по требованию заказчика обязан безвозмездно переделать проектно-сметную документацию и произвести необходимые дополнительные работы. Кроме того, он обязан возместить заказчику причиненные убытки, если законодательство или договор не устанавливают иного <*>.

Заказчик вправе контролировать ход и качество работ, соблюдение сроков (графика) их выполнения, качество предоставленных подрядчиком материалов, а также правильность их использования, не вмешиваясь в оперативно-хозяйственную деятельность подрядчика <*>.

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

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

Размер возмещения вреда уменьшается, если его возникновению или увеличению содействовала грубая неосторожность потерпевшего. При грубой неосторожности потерпевшего и отсутствии вины причинителя вреда, в случае когда его ответственность не зависит от вины, суд уменьшит размер возмещения или откажет в возмещении, если законодательство не предусматривает иного <*>.

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

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

Пример 2

Кассационная коллегия Верховного Суда рассмотрела кассационную жалобу по делу, в котором ПК «Заказчик» хотел понудить ОАО «Проектировщик» к исполнению договора на выполнение проектных изыскательских работ.

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

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

Подрядчик обязан:
— выполнять работы в соответствии с исходными данными на проектирование и договором;
— согласовывать готовую проектно-сметную документацию с заказчиком, а при необходимости вместе с заказчиком — с компетентными государственными органами и органами местного управления и самоуправления;
— передать заказчику готовую проектно-сметную документацию и результаты изыскательских работ <*>.

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

Утверждение ПК «Заказчик», что ответчик не выполнил надлежащим образом обязательства по договору, суд не принял во внимание, поскольку доказательств истец не представил.

Изменения в проектную документацию ответчик внес в рамках функций авторского надзора и передал истцу. Об этом свидетельствовали материалы дела. Другие доводы ПК «Заказчик», изложенные в кассационной жалобе, не содержали оснований для отмены ранее принятых судебных постановлений.

В удовлетворении кассационной жалобы Кассационная коллегия Верховного Суда отказала.

Помимо обязательной государственной строительной экспертизы с целью определения причин недостатков, допущенных при проектировании, по требованию любой из сторон назначается судебная строительно-техническая экспертиза <*>. Ее выполняют организации, имеющие лицензию Минюста на выполнение судебных строительно-технических экспертиз.

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

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

Кроме заключений, в качестве доказательств стороны могут представить суду справки контрольных обмеров в соответствии с законодательством по вопросам правильности расходования бюджетных средств, средств целевых бюджетных и внебюджетных фондов и льготных кредитов, выделяемых на капитальное строительство (реконструкцию, ремонт, реставрацию, благоустройство) объектов, акты взаимной сверки качества выполненных работ. Также суд вправе привлечь для участия в хозяйственном процессе компетентный государственный орган в сфере
строительства <*>.

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

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

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

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

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

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

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

Что такое риск

Если вам предстоит запустить проект, рано или поздно вы задумаетесь, что в нем может пойти не так. Вы начнете предугадывать слабые места проекта. Это и есть риски. Риск проекта — это неопределенное событие или условие, которое положительно или отрицательно влияет на цели проекта. Например, цель — закрыть проект, не превышая бюджет. Тогда любые события с непредвиденными расходами будут считаться риском. Или цель — создать качественный продукт раньше конкурента. Тогда есть риск опоздать с запуском или потерять проверенного поставщика и проиграть в качестве. Как только у проекта появляется цель, пора подумать о факторах, которые могут ей помешать.

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

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

Зачем управлять рисками

Управление рисками проекта — это страховка, с помощью которой можно вовремя спасти важную составляющую проекта, будь то деньги, время или даже уровень качества продукта. К тому же, профилактические меры часто выходят дешевле и быстрее решения возникших проблем. Пример рисков проекта: вы боитесь, что в середине проекта заказчик изменит требования — вам придется все переделывать и расширять бюджет. Подумайте об этом заранее. Уже на первом этапе вы можете согласовать подробное ТЗ и обговорить условия для пересмотра требований. Потратив пару дней на такую страховку, вы защитите проект от крупных задержек и сэкономите ресурсы.

По большому счету для любого риска есть два решения: игнорировать его и надеяться на лучшее или сразу попытаться устранить. Если надежда оправдается, первый вариант принесет выигрыш. Но для этого нужна скорее удача, чем расчет и планирование. В противном случае это просто принятие риска со всеми его последствиями — потерями в деньгах, времени или качестве.

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

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

Какие риски проекта самые опасные

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

Задача анализа — сравнить сэкономленные ресурсы, если риск был принят, но не реализовался, с затратами на его разрешение. Оценка должна быть всесторонней, поэтому проводится в два этапа: сначала качественный, а потом количественный анализ.

Качественный анализ рисков проекта

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

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

Для определения вероятности рисков распределите их по шкале вероятности. Она может быть относительной или с цифровыми значениями.

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

Результаты качественного анализа ложатся в основу количественного.

Риски проекта — количественный анализ

На этот этап попадают наиболее вероятные и опасные риски. При плохом сценарии они напрямую угрожают целям проекта. Задача количественного анализа — выявить негативное влияние главных рисков и распределить их по степени этого влияния.

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

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

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

Как найти выход

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

Для работы с рисками есть несколько стратегий:

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

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

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

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

Как управлять рисками с помощью BPM-системы

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

• собирать и документировать риски проекта;

• хранить и передавать информацию о выполненных задачах;

• обеспечивать мониторинг статусов рисков;

• обеспечивать контроль со стороны проектного менеджера над всеми работами.

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

Процессный подход реализуется с помощью BPM-системы, в которой работа организована в виде бизнес-процессов. Бизнес-процесс — это совокупность взаимосвязанных операций, направленных на достижение цели.

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

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

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

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

3. Реестр возвращается к проектному менеджеру с проставленными статусами и замечаниями экспертов. Дальше нужно провести количественный анализ. Для этого можно снова привлечь экспертов или оценить риски силами команды проекта. Важно зафиксировать все результаты количественного анализа в реестре и передать в следующую задачу. Еще один вариант: отказаться от детальной оценки и сразу перейти к выбору стратегии.

4. Менеджер проекта подводит итоги анализа, пересматривает реестр рисков и приступает к выбору стратегии. Любое изменение статуса риска, например, если он состоялся или решился, менеджер сможет зафиксировать в реестре.

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

6. После выполнения работ проектный менеджер оценивает эффективность всего процесса.

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

Если кратко

Гарантировать успех проекта невозможно — всегда будет оставаться элемент неопределенности и риски проекта, угрожающие целям. Чтобы уменьшить неприятности, можно подстраховаться и устранить угрозы заранее. По большому счету работа с рисками заключается в поиске баланса между затратами на решение рисков и потенциальным ущербом в случае их принятия. Достичь этот баланс получится, опираясь на результаты анализа. Только после аргументированной оценки угроз можно приступать к выбору стратегии управления: уклонение, передача, снижение или принятие. Работать с рисками удобнее с помощью бизнес-процесса, а в качестве инструмента для управления рисками использовать BPM-систему.

Вот небольшой чек-лист, как начать работу с рисками проекта:

1. Найдите слабые места проекта и запишите все возможные риски.

2. Проведите качественный анализ: разделите все риски проекта на важные и второстепенные.

3. Проведите количественный анализ: определите влияние рисков на проект в точных значениях.

4. Подберите и примените к каждому риску одну или несколько стратегий управления.

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

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

• На стадии подачи заявок
• На стадии рассмотрения заявок
• После заключения контракта

Стадия подачи заявок

На этом этапе у заказчика есть следующие опции: 

• внесение изменений в документацию;
• отмена закупки.

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

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

При изменении документации заказчик принимает решение, вносит изменения в извещение и в течение одного дня загружает файл с корректировками через ЕИС.

Не забудьте изменить сроки подачи заявок. Со дня изменения документации до дня окончания подачи заявок должно быть:

• не менее 15 дней для электронного аукциона;
• не менее 7 дней для электронного аукциона с НМЦК менее 300 млн руб. или НМЦК до 2 млрд руб. в сфере строительства;
• не менее 10 рабочих дней для открытого конкурса в электронной форме;
• не менее 5 рабочих дней для запроса котировок в электронной форме.

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

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

В любом случае нельзя вносить изменения, если:

• заказчик не уложился в 2-х дневный срок до окончания срока подачи заявок;
• нужно менять объект закупки при любых процедурах или увеличить размер обеспечения заявок при проведении конкурса.

В таком случае можно отменить закупку (конкурс, аукцион или запрос котировок). Извещение об отмене размещается через ЕИС. Отменить можно не позднее, чем за 5 дней до даты окончания срока подачи заявок, если это конкурс или аукцион, и 2 дня – если это запрос котировок. Отменить запрос предложений нельзя.

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

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

Стадия рассмотрения заявок

Подача на этой стадии жалобы (самостоятельно, заказчиком либо участником закупки) – рискованный вариант. 

Если ошибка в документации, техническом задании все же есть, возможно:

• Никто просто не подаст заявок и торги не состоятся.  Это благоприятный сценарий, так как он позволит исправить ошибки.

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

Как исправить ошибки после заключения контракта

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

Напомним, что существенными условиями контракта считаются его предмет, а также те условия, которые таковыми признаны законом и самим контрактом. В случае с госзакупками – это почти все его возможные условия, в том числе цена, срок, количество товара или объем работ.
Условия контракта должны соответствовать тому, что написано в документации и техническом задании. Если в ТЗ были неточно указаны объем работ, количество товаров, сроки выполнения или поставки, то изменить ситуацию на стадии, когда контракт уже заключен, тоже возможно. Но далеко не всегда. 

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

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

• цены контракта и объема работ. Но не более, чем на 10% (исключение – контракты, касающиеся строительства и объектов культурного наследия). Есть и другие основания для изменения цены, но они вряд ли они будут связаны с ошибками технического задания. При этом перечень товаров или работ должен остаться прежним – дополнять его либо исключать какие-либо позиции нельзя;

• срока контракта. Срок можно изменить только в отдельных видах контрактов (заключенных с единственным поставщиком, в сфере строительства).

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

Желательно все же устранять неточности и ошибки в техническом задании еще на этапе подачи заявок. Если не вносить изменения в документацию и техзадание и попытаться заключить контракт без учета их содержания – то это грозит штрафом до 30 000 рублей для должностного лица и до 300 000 рублей для заказчика. При этом штраф в случае, если контракт заключить с нарушениями, которые уже отражены в ТЗ, меньше – до 50 000 руб.

Если статья была вам полезна, пожалуйста, оцените ее по «звездной» шкале ниже, где 5 звезд — очень полезна.

Мы хотим, чтобы вы читали только интересные материалы, и будем благодарны за обратную связь!

Методики идентификации рисков

Для идентификации рисков используют следующие методы [11,23].

Мозговой штурм.Целью мозгового штурма является создание подробного списка рисков проекта. Список рисков разрабатывается на собрании, в котором принимает участие 10-15 человек — члены команды проекта, часто совместно с участием экспертов из разных областей, не являющихся членами команды. Участники собрания называют риски, которые считают важными для проекта, при этом не допускается обсуждение выдвинутых рисков. Далее риски сортируют по категориям и уточняют.

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

Метод номинальных групп позволяет идентифицировать и расположить риски в порядке их важности. Данный метод предполагает формирование группы из 7-10 экспертов. Каждый участник индивидуально и без обсуждений перечисляет видимые им риски проекта. Далее происходит совместное обсуждение всех выделенных рисков и повторное индивидуальное составление списка рисков в порядке их важности.

Карточки Кроуфорда.Обычно собирается группа из 7-10 экспертов. Ведущий сообщает, что задаст группе 10 вопросов, на каждый из которых участник письменно, на отдельном листе бумаги, должен дать ответ. Вопрос о том, какой из рисков является наиболее важным для проекта, ведущий задает несколько раз. Каждый участник вынужден обдумать десять различных рисков проекта.

Опросы экспертов с большим опытом работы над проектами.

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

Анализ сильных и слабых сторон, возможностей и угроз (анализ SWOT). Цель проведения анализа — оценить потенциал и окружение проекта. Потенциал проекта, выраженный в виде его сильных и слабых сторон, позволяет оценить разрыв между содержанием проекта и возможностями его выполнения. Оценка окружения проекта показывает, какие благоприятные возможности предоставляет и какими опасностями угрожает внешняя среда.

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

Метод аналогии.Для идентификации рисков этот метод использует накопленные знания и планы по управлению рисками других аналогичных проектов.

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

Сравнение методов идентификации рисков проекта [11] представлено в табл. 5.6.

Идентифицированные риски документируются в так называемых реестрах рисков.

Примеры шаблонов реестра рисков [11] приведены в таблицах 5.7и 5.8.

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

Иногда бывает, что в извещении, ТЗ и контракте отражены несколько разные условия закупки. Причем выяснится это может не только до подачи заявки, но и гораздо позже. Что делать поставщику? Подробно разберем этот вопрос в статье.

Разные условия выявлены на этапе подачи заявки

Несоответствие условий в документах и извещении

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

Выявление таких ошибок до подачи заявки возможно при условии, что поставщик внимательно изучает закупочную документацию. В этом случае его бдительность полностью оправдана. Какие ошибки могут быть обнаружены? Наиболее распространенными являются:

• разночтения в сроках подачи заявок или оплаты;
• разные единицы измерения товаров — штуки, упаковки и так далее;
• указание в извещении, что закупка для субъектов малого предпринимательства, тогда как в документации такое условие отсутствует.

Если разъяснения не соответствует техзаданию

Допустим, поставщик указал заказчику на его ошибку, и тот согласился с ее наличием в разъяснении, однако в документацию изменения так и не внес. Важно помнить, что это считается нарушением закона — такого мнения придерживаются в ФАС. Заказчик в этом случае обязан изменить документацию, а также продлить срок принятия заявок.

Иногда в инструкции к заполнению заявки заказчики указывают, чем поставщики должны руководствоваться в случае разночтений между разъяснениями и ТЗ. Это неправомерно, поскольку, как было указано выше, если к ошибке дано разъяснение, заказчик должен внести исправление в документацию.

Разные условия выявлены при подписании контракта

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

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

Если заказчик прислал контракт, не соответствующий проекту

Бывает, что в проекте контракта одни данные, а заказчик присылает на подпись форму с другими. Как быть?

Победитель электронного аукциона получил от заказчика контракт, в котором на исполнение дается 20 дней. А в проекте контракта этот срок составлял 30 дней. Поставщику следует сообщить о разночтении заказчику. Далее развитие ситуации зависит от реакции последнего.

Если заказчик признает, что допустил в контракте ошибку, следует составить протокол разногласий. После этого заказчик присылает исправленный вариант контракта, который поставщик, убедившись в его правильности, должен подписать.

Видеоролик о протоколе разногласий:

Бывает, что заказчик не согласен — у него изменилась ситуация. Стоит ли в таком случае идти ему навстречу? Это спорно, поскольку сделка впоследствии может быть отменена. Такое может случиться, если другие участники обратят внимание на то, что подписан контракт, не соответствующий проекту, и обратятся в суд. Поэтому следует требовать от заказчика исправленный вариант контракта, а при его упорстве обращаться в ФАС.

Разница в условиях контракта и требованиях в документации

Иногда поставщик упускает отдельные моменты контракта. И тогда все зависит от того,  смогут ли стороны договориться.

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

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

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

Различия всплыли после подписания контракта

В этом случае раздумывать поздно. Раз поставщик подписал контракт, значит, он согласился с его условиями. И вариантов всего два: выполнить их или расторгнуть контракт.

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

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

Об особенностях расторжения контракта в одностороннем порядке смотрите видеокомментарий:

Что делать?

Избежать таких случаев или выйти из них «сухими» поставщику помогут внимательность, знание закона и умение вести переговоры.

1. Перед подачей заявки нужно тщательно ознакомиться не только с извещением о закупке, но и со всеми документами, в том числе с проектом контракта.
2. Если найдены разночтения, стоит обратиться за разъяснениями. При этом важно знать, что заказчик обязан их дать, а также исправить ошибки в документации.
3. Следует помнить, что контракт должен полностью соответствовать проекту.
4. Если же все это не помогло, и в контракт попали «лишние» условия, придется либо его исполнять как есть, либо договариваться с заказчиком.

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

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

Что такое риски проекта

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

Благодаря управлению риском можно предотвратить или, по крайней мере, минимизировать последствия     , к которым приводят рисковые ситуации. Как это выглядит на практике — рассмотрим дальше.

Зачем управлять рисками

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

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

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

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

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

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

Оценка рисков и последующие работы по их предотвращению требуют  больше ресурсов и тщательного анализа, но в конечном результате это принесет свои плоды, если речь идет не о мелких, а серьезных угрозах.

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

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

Как провести анализ рисков проекта

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

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

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

Виды рисков

Есть несколько классификаций рисковых ситуаций. Мы предлагаем рассмотреть виды, с которыми чаще всего сталкиваются при управлении:

• Временной риск (связан с затратой времени). Суть в том, что все действия по реализации проекта могут занять больше времени, чем запланировали на старте. Время — ценнейший ресурс, поэтому о временных рисках важно всегда помнить. Временной риск опасен еще тем, что ведет к повышению расходов.
• Риск, связанный с изменением объемов работ. Такие рисковые ситуации могут появиться, если при согласовании проекта исполнители не до конца поняли требования клиента или же клиент сам внес дополнения в проект. Результат — потребуется увеличить бюджет, скорректировать сроки выполнения проектов и задач.
• Внешний риск. Речь идет о потенциально возможных рисковых событиях, которые никак не связаны с внутренними процессами компании, а значит, не могут контролироваться. Простой пример — в процессе работы над сложным проектом государство ввело новый законопроект, в результате чего потребуются дополнительные корректировки, расходы финансов и временные затраты.
• Бюджетный риск. Чаще всего такой риск возникает из-за недостатка планирования конечной стоимости проекта. Получается, что расходы больше, чем заложено в бюджет. Далее варианта два — либо проект останавливается, либо придется вкладывать дополнительные средства, чтобы устранить последствия, вызванные возникшим риском.
• Риск возникновения единой точки отказа. Это событие, которое кардинально влияет на работу всей команды над проектом. То есть, пока проблема не будет решена, никто из специалистов, задействованных в проекте, не сможет приступить к своим обязанностям. Из примеров можно рассмотреть такую ситуацию: для компании, работа которой связана с подключением к сети, единой точкой отказа может быть отключение интернета и/или электричества.
• Риск зависимости. При работе над сложными проектами одна задача тесно связана с другой. И пока один специалист не закончит свою часть работы, другой — не сможет приступить к выполнению своей.

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

Этапы управления рисками

Условно весь процесс управления можно разделить на 5 отдельных этапов:

1. Планирование.

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

2. Идентификация факторов.
   Следующий шаг — выявить и зафиксировать угрозы и определить вероятность возникновения конкретного риска на проект. В результате должен быть сформирован перечень возможных проблем и рисковых обстоятельств с ранжированием по уровню опасности для проекта. Не все угрозы можно идентифицировать на старте, а по мере работы над проектом значимость некоторых рисковых ситуаций может возрасти.
   В идентификации факторов, которые могут привести к риску, можно использовать два важных фактора: источник рискового события, а также саму угрозу. В результате команда должна сформировать реестр возможных рисковых ситуаций для конкретного проекта.
3. Качественный и количественный анализ.
   Чтобы идентифицировать риск, важно дать ему соответствующую оценку. Для этой цели применяют два метода — качественный и количественный анализ.
   Качественный заключается в получении экспертных мнений относительно возможности развития неблагоприятных последствий, связанных с обнаруженными факторами риска. Качественный анализ носит поверхностный характер, но для многих проектов этого вполне достаточно. Плюс в том, что уже на старте можно получить перечень рисковых событий, распределить их по приоритетности (уровню опасности) и предпринять необходимые меры.
   Количественный анализ занимает больше времени, но он намного точнее — помогает получить конкретные оценки вероятности наступления определенного рискового события. К проведению количественного анализа необходимо привлекать компетентных специалистов, так как приходится использовать сложные математические модели и методики. Благодаря проектному количественному анализу можно спрогнозировать степень воздействия на проект, а также объемы возможных материальных потерь при риске.
4. Планирование реакции.
   Далее следует важный этап — планирование реакции для предупреждения или минимизации последствий угрозы, вызванной возникшим риском. Проще говоря, на этом этапе нужно продумать меры, которые позволят достичь целей проекта, даже при появлении непредвиденных рисковых обстоятельств.
   При планировании реакции можно использовать одну из следующих стратегий:
   • Уклонение. План возможных действий корректируется таким образом, чтобы снизить или исключить вероятность появления негативных последствий, которые может спровоцировать тот или иной риск. Например, скорректировать утвержденный ранее график.
   • Передача. Суть методики в том, чтобы переложить ответственность и возможные последствия на другую команду (третью сторону). Например, заключить договор страхования, предусмотреть в договоре неустойку.
   • Снижение. Стратегия формирования предупредительных мер. Например, собирая команду экспертов, для ведущих специалистов подбирают «дублера» с соответствующей квалификацией, который в случае непредвиденной ситуации сможет взять выполнение обязанностей на себя.
5. Мониторинг.

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

Управление рисками с помощью BPM-системы от «КСК ТЕХНОЛОГИИ»

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

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

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

Компания «КСК ТЕХНОЛОГИИ» предлагает готовое решение для реализации процессного подхода в компании — low-code платформу «КСК.ИК» класса ВРМ для цифровой трансформации организации. Платформа построена на базе ВРМ-движка, который помогает автоматизировать все процессы организации, мониторинг и аналитику исполнения приоритетных задач.

Основный функционал:

1. автоматическая постановка задач;
2. контроль просрочки задач и процессов;
3. доступна история процесса;
4. удобный функционал для коммуникации сотрудников;
5. возможность группировать процессы и кейсы в списки по предметной области;
6. интеграция с почтовыми сервисами;
7. автоматическая рассылка системных уведомлений;
8. версионность процессов (возможность исполнения бизнес-процессов по разным версиям);
9. актуализация процессов без остановки уже запущенных;
10. сбор информации для подготовки отчетности и анализа бизнес-процессов.

С помощью ВРМ-системы от «КСК ТЕХНОЛОГИИ», вы сможете эффективно моделировать и исполнять бизнес-процессы, принимать наилучшие решения для вашего бизнеса, грамотно управляя каждым вероятным риском.