Для кого данный материал
В настоящее время все больше компаний перестраивают свои процессы с учетом выгод от цифровизации, автоматизации процессов и процедур. Потребность рынка России в цифровых продуктах растет. А с учетом текущих реалий и уходом основных производителей программного обеспечения с российского рынка возрастает проблема эффективности и надежности отечественного программного обеспечения.
Для компаний малого и среднего бизнеса инвестиции в покупку, внедрение и развитие отечественных программных продуктов могут выражаться в существенных финансовых издержках, связанных с созданием, внедрением, последующей эксплуатацией и развитием цифровых продуктов. Существенная часть таких издержек может быть связана с управлением рисками информационной безопасности.
В условиях существенно ограниченной доступности программных решений от зарубежных производителей неизбежно формируется запрос рынка и, как следствие, предложение от отечественных производителей ПО.
При этом компании, например, занимающиеся разработкой или внедряющие у себя ПО, могут не обладать достаточными ресурсами и не иметь выстроенные процессы для обеспечения необходимого контроля над качеством, надежностью и безопасностью разрабатываемого и вводимого в эксплуатацию ПО.
Цель статьи – дать рекомендации по снижению риска незапланированных издержек в ходе цифровой трансформации компаний малого или среднего бизнеса. Статья в первую очередь ориентирована на менеджмент компании, отвечающий за процессы цифровой трансформации и автоматизации, но также будет полезна и специалистам непосредственно участвующим в повседневных операциях компании.
В чем польза статьи?
В рамках данной статьи, автором было проведено исследование и были выделены наиболее часто встречающиеся угрозы и риски присущие жизненному циклу ПО.
Затем была предложена методика по снижению угроз и рисков, потенциально ведущих к издержкам компании. Так, в результате выработаны рекомендации менеджменту компаний провести исследование готовности самой компании к внедрению ПО, а также оценить потенциального поставщика и само ПО.
Также в рамках данной работы была проведена апробация рекомендаций и методики для нескольких компаний малого бизнеса, была получена ценная обратная связь от руководителей данных компаний и внесены корректировки.
Если не хочется читать дальше
Но если любопытство берет свое, то далее вас ожидает ОЧЕНЬ много текста и таблиц, так как изначально материал создавался как ВКР 🙂
Также, материал принесет вам больше пользы, если вы предварительно прочитаете об Управлении риском ИТ и Внедрении контроля над ИТ.
Итак, почему могут возникать издержки?
Театр информационной безопасности или ИБ-галлюцинирование — это неконсистентное и нерегулярное выполнение процедур не имеющих связи с реальностью, целями и рисками процессов, формирующее иллюзию безопасности, надежности и эффективности процессов управления рисками ИТ и ИБ. Другими словами — галлюцинация. При этом, иллюзии и галлюцинации у всех участников процессов управления ИТ и ИБ могут быть разными.
Почему могут наступать галлюцинации? Все достаточно просто — любая процедура или процесс в целом, при неконсистентном, нерегулярном и неформализованном исполнении, лишь создает чувство эффективности и надежности, тем самым создавая различные иллюзии и неоправданные ожидания. Это применимо и к управлению ИТ и ИБ процессами, процедурами.
Таким образом иллюзии и неоправданные ожидания могут вести к дополнительным расходам, непредвиденным издержкам компании.
Издержки и наиболее частые варианты их возникновения
Возьмем гипотетическую компанию малого или среднего бизнеса, осуществляющую разработку и/или внедрение у себя программных продуктов.
Для каждого типа разработки приоритеты, цели и издержки могут отличаться, что необходимо учитывать при выработке управленческих решений, направленных на снижение финансовых издержек таких компаний.
Для получения лучшего понимания возможностей по минимизации рисков и, как следствие, издержек компаний, важно определить, на каких этапах жизненного цикла разработки ПО могут возникать издержки.
Например, в индустрии программного обеспечения различают два основных подхода: SDLC и SDL.
SDLC — это аббревиатура от «Жизненный цикл разработки программного обеспечения». Ею обозначают процесс разработки программного обеспечения.
SDLC — это структура, определяющая задачи, выполняемые на каждом этапе процесса разработки, внедрения и последующей эксплуатации программного обеспечения.
SDLC — это классический процесс, используемый индустрией программного обеспечения для проектирования, разработки и тестирования программного обеспечения.
Целью SDLC является создание высококачественного программного обеспечения, которое соответствует ожиданиям клиентов или превосходит их, завершающееся в установленные сроки и с минимальными издержками.
SDL — это аббревиатура от «Жизненный цикл безопасной разработки», является более современным процессом, в настоящее время наиболее востребованный и становящийся в индустрии разработки программного обеспечения фактически обязательным стандартом.
Как пишет в своей статье Шарлотта Фриман: SDL, или Secure SDLC, — это процесс, который позволяет поддерживать необходимый уровень безопасности системы на этапе разработки, а затем на протяжении всего срока эксплуатации. Эта концепция фокусируется на обеспечении безопасности разрабатываемого приложения, идентификации рисков и управлении ими.
В концепции разработки SDL управление рисками заключается в формировании требований к приложению, безопасному программированию, тестированию, сертификации, эксплуатации и развитию ПО.
В рамках данной статьи за основу был взят стандарт, предлагаемый и поддерживаемый компанией Microsoft — «Жизненный цикл безопасной разработки Майкрософт».
В стандарте Microsoft SDL учитываются вопросы управления рисками информационной безопасности на всех этапах процесса разработки, внедрения и последующей эксплуатации ПО. И этого по мнению автора данной статьи достаточно для реализации идеи смешения подходов к управлению рисками, осуществления внутреннего контроля и безопасной разработки.
Компании могут использовать данный стандарт, либо подобный, для выявления угроз и выработки снижающих риски мероприятий, тем самым соблюдать требования безопасности и сокращать затраты на этапах создания, внедрения, эксплуатации и последующего развития программного обеспечения.
Компания Microsoft рекомендует осуществлять управление рисками через моделирование угроз. Угрозы являются ключевым элементом жизненного цикла Microsoft Security Development Lifecycle. В стандарте выделяется пять основных этапов моделирования угроз:
Моделирование угроз должно быть частью обычного жизненного цикла разработки и развития программного обеспечения в компании, в результате чего возможно постепенное совершенствование модели угроз и, как следствие, еще более эффективное последующее снижение рисков.
Как пишет в своей статье Садик Альмуайрфи Аленези (Alenezi, Sadiq Almuairfi, «Security Risks in the Software Development Lifecycle» International Journal of Recent Technology and Engineering (IJRTE) ISSN: 2277-3878, Volume-8 Issue-3, September 2019), анализ угроз позволяет более точно и полно понять потенциальные риски и последствия для компании, включая возможные финансовые издержки при разработке, внедрении и эксплуатации ПО.
В процессе жизненного цикла разработки программных продуктов на каждом из его этапов проводится анализ возможных негативных событий, рисков для разрабатываемого программного продукта. При этом процесс анализа рисков может быть как формализованным, так и не формализованным.
Для индустрии разработки программных продуктов характерным является качественный подход к управлению рисками жизненного цикла ПО. Единицами измерения служат инциденты.
Инциденты — это сбои в работе программного обеспечения, приведшие к простою ПО, к различным штрафам и санкциям, ущербу репутации, незапланированным расходам на доработку или исправлениям, т.е. незапланированным активностям и финансовым издержкам для компании.
При таких инцидентах компании вместо развития ПО, выпуска его новой версии вынуждены тратить время и ресурсы на устранение ошибок и поддержку устаревших либо существенно доработанных программных продуктов, неся дополнительные финансовые издержки.
Как утверждает Исаак Саколик: издержки также могут возникать в следствие реализации различных угроз из области информационной безопасности. В этом случае финансовые потери компаний могут быть существенными.
Чтобы понять, где и что может пойти не так, необходимо провести анализ процессов, в частности, процессов разработки, внедрения и дальнейшей эксплуатации программного обеспечения.
Также в рамках проводимого анализа следует проработать гипотезы, связанные с окупаемостью программного продукта, конкурентными действиями, реализуемостью продукта, издержкам, связанным с последующей эксплуатацией программного продукта. Т.е. в ходе такого анализа определяются и оцениваются проектные риски по запуску нового продукта или развития уже существующего.
В ходе анализа также учитываются драйверы разработки или развития программного продукта. Драйверами могут быть как автоматизация процесса, так и, например, решение некой проблемы пользователей. Проводятся A/B эксперименты, готовятся MVP, с целью получения понимания, правильности вектора движения команды разработки и заказчика.
Жизненный цикл программного обеспечения делится на несколько этапов, в конце каждого блока есть некая контрольная точка или событие, при наступлении которого проводится анализ рисков и выработка мер, направленных на снижение вероятности негативных вариантов развития событий, предотвращение инцидентов либо снижение уровня негативных последствий.
Как уже было сказано выше, в результате просчетов, некорректной постановки задач, недооценки рисков и последствий взаимодействия с поставщиками ПО и т.д. многие компании могут нести существенные финансовые издержки, при этом возможны различные варианты негативных последствий для компаний малого бизнеса, вплоть до невозможности продолжения функционирования.
В данном случае программное обеспечение уже фактически является отдельной версией изначально созданного стандартного («out of the box») программного решения и либо потребует в дальнейшем нестандартного подхода в рамках поддержки, либо его полного замены.
Этапы жизненного цикла разработки программного обеспечения
Обобщая предварительно собранную выше информацию, рассмотрим варианты возникновения издержек.
Первый вариант: программное обеспечение закуплено уже готовым или создается для себя с целью оптимизации, ускорения процессов, через цифровую трансформацию бизнес-процессов компании, автоматизацию бизнес-процессов.
В данном случае первично то, что данное ПО должно быть надежным и устойчивым, отвечать потребностям бизнеса. При этом автоматизация, кастомизация и последующая поддержка должны быть приемлемы для бизнеса и, более того, окупаться за разумный промежуток времени.
Осуществляя развитие подобного программного продукта, команда должна успевать реагировать на изменения бизнес-процессов компании. В этом случае финансовые издержки компании возникают на этапе создания и последующей поддержки, при решении внутренних инцидентов с данным ПО.
Второй вариант: компания разрабатывает уникальное ПО и в последующем осуществляет поддержку данного программного продукта на основании заказа клиента, так называемый заказной программный продукт для конкретного заказчика, то есть данный вариант фактически является проектом в рамках проектов по созданию и поддержке ПО.
Успешность проекта и, как следствие, издержки на реализацию такого проекта могут быть любыми. Например, заказчик удовлетворен автоматизацией процессов при разумных издержках на саму разработку, но последующая поддержка может вызывать существенные расходы у компании-разработчика.
Т.е. издержки, как и доход компании-подрядчика, могут возникать при последующей поддержке разработанного программного продукта.
Третий вариант: масс-маркет, компания-производитель несет издержки на этапах получения понимания потребностей не только своих, но, в первую очередь, своих потенциальных клиентов, при формировании «портрета» клиента, причин, по которым клиенту мог бы понадобится тот или иной функционал и/ или автоматизация.
Формируются издержки на разработку и проверку гипотез, определение и реализацию требований к конечному продукту (функциональные – отвечающие на вопрос «Что программный продукт должен уметь делать», нефункциональные – описывают его общие свойства, включая производительность, совместимость, получение или наличие подтверждающих сертификатов).
Компания, которая выпускает программный продукт для массового рынка, должна понимать, сколько стоит поддержка для компании, какова конкурентная среда, когда данный продукт можно выводить на рынок и в какой момент, на основании каких критериев данный продукт необходимо закрыть, когда продукт станет не рентабелен и его жизненный цикл должен быть завершен.
В данной статье будет рассмотрен Первый вариант, при котором компания внедряет и развивает готовый программный продукт для собственных нужд.
