Источник:
https://www.novostiitkanala.ru/news/detail.php?ID=190184
Показаны сообщения с ярлыком ИТ. Показать все сообщения
Показаны сообщения с ярлыком ИТ. Показать все сообщения
суббота, 27 сентября 2025 г.
ПО импортозамещения второй половины 2025 года
Фрагмент «Тепловой карты импортозамещения ПО». Альфа-Банк, исследование «Импортозамещение в IТ-секторе. Итоги и перспективы 2025+»
Источник:
https://www.novostiitkanala.ru/news/detail.php?ID=190184
Источник:
https://www.novostiitkanala.ru/news/detail.php?ID=190184
пятница, 19 сентября 2025 г.
Решения по модернизации ИТ
Сегодняшние решения по модернизации происходят в принципиально новых условиях. Во-первых, крупномасштабные платформы SaaS (программное обеспечение как услуга), построенные на современных архитектурах, предназначенных для облачных операций, непрерывных обновлений и глубокой интеграции с экосистемами операторов, теперь жизнеспособны в масштабах. Во-вторых, конвергенция данных, искусственного интеллекта и облачных вычислений создает основу для внедрения новых технологий более агрессивно, чем когда-либо прежде, при условии, что платформа стабильна и масштабируема.
Технологическая модернизация часто рассматривается как ИТ-инициатива, требующая ограниченного участия заинтересованных сторон бизнеса. Тем не менее, готовность к переосмыслению и перестройке бизнес-процессов имеет решающее значение для успешного преобразования основных систем.
Решение о том, следует ли создавать индивидуальные решения собственными силами, приобретать коммерческие готовые платформы (COTS - commercial off-the-shelf) или модернизировать существующие системы, является сложным выбором. Центр тяжести в этом вопросе смещается — все меньше пользователей стремятся к полноценным кастомным сборкам, и все больше изучают способы расширения устаревших систем с помощью современных оболочек или использования платформ SaaS.
У каждого подхода есть плюсы и минусы. Пользователи, использующие собственные сборки, имеют больший контроль, индивидуальные возможности и более легкую адаптацию к будущим инновациям. Однако они, как правило, сталкиваются с проблемами длительных сроков, ограниченной масштабируемости и растущих затрат и недооценивают полную стоимость долгосрочного обслуживания и постоянных инноваций. В проектах по сборке инновации часто закрепляются на этапе ввода в эксплуатацию, а когда происходит перерасход средств, имеется недостаточная документация, сокращаются расходы на обучение, это лишают организацию возможности развивать платформу.
Организации, выбирающие платформы COTS, получают более быстрое внедрение и более широкие инновационные возможности благодаря модели постоянных изменений, в которой поставщик управляет непрерывным развитием платформы. Тем не менее, они часто сталкиваются с проблемами с использованием всего потенциала новых систем. Современные пакеты могут удовлетворить потребности за счет конфигурации без серьезной настройки, но они по прежнему очень сложны. В результате, даже внедрение COTS может потребовать длительных временных рамок для преодоления проблем интеграции и адаптации к все более сложной архитектуре приложений.
Детальная оценка по шести ключевым параметрам может помочь принять обоснованное решение о том, следует ли создавать новую платформу, покупать решение COTS или модернизировать существующую платформу.
К критическим параметрам относятся следующие:
1. Функционал и возможности платформы. Если бизнес-модель требует специализированной функциональности, значительной кастомизации или сложной интеграции, организация может рассмотреть возможность разработки системы. Для тех, кто готов адаптировать бизнес-процессы и уделять приоритетное внимание времени выхода на рынок, экономической эффективности и инновациям, COTS может подойти лучше всего, особенно с учетом того, что платформы продолжают добиваться успехов в улучшении своей конфигурируемости и более эффективном удовлетворении уникальных потребностей продуктов.Во всех случаях приоритетом должно быть то, сможет ли платформа поддерживать будущий рост и расширение продукта, не запирая бизнес в хрупких обходных путях.
2. Настройка рабочих потоков и опыт цифровизации. Организации могут рассмотреть возможность разработки, если у них есть узкоспециализированные рабочие процессы и им требуется индивидуальное решение. Покупка предоставит систему со встроенными и готовыми рабочими процессами. Другие соображения включают требуемый уровень автоматизации процессов и степень гибкости при внесении изменений в рабочий процесс. Для операторов, обновляющихся в рамках экосистемы COTS, вопрос заключается в том, улучшит ли новая версия скорость, автоматизацию или пользовательский опыт настолько, чтобы оправдать затраты и сбои в обновлении.
3. Управление, безопасность и контроль данных. Организации могут рассмотреть возможность разработки, если они отдадут приоритет индивидуальному управлению, полному контролю над проприетарными моделями данных и настраиваемым протоколам безопасности. Организациям выгоднее покупать модульные, масштабируемые решения с предварительно созданными расширенными аналитическими возможностями и которые могут принимать обновления безопасности, управляемые поставщиком платформы. Организации могут оценить, согласуются ли инновации от поставщиков с их ИТ-стратегией или сохранение контроля над проприетарными моделями имеет решающее значение, хотя современные COTS-платформы все чаще предлагают настраиваемое управление данными и надежные функции безопасности. Организации, уже использующие платформу поставщика, могут рассмотреть, обеспечивает ли обновление значимые улучшения в аналитике, переносимости данных и контроле рисков.
4. Время выхода на рынок и стоимость. Создание системы требует более высоких первоначальных инвестиций, а требуемая обширная разработка и интеграция означает, что внедрение может занять от пяти до десяти лет. Платформы COTS обычно предлагают более низкие первоначальные затраты и внедрение в течение трех-пяти лет за счет использования конфигурации с минимумом программирования и минимальной настройки для ускорения развертывания. Но даже в среде одного и того же поставщика серьезное обновление может потребовать тщательного тестирования, перенастройки и изменения бизнеса. Другими факторами являются совокупная стоимость владения, долгосрочная масштабируемость и предсказуемость затрат по мере роста бизнеса, а также то, соответствует ли новая модель амбициям роста или же индивидуальная сборка обеспечивает лучший контроль над затратами с течением времени.
5. Организационные возможности и инновации. Организации могут рассмотреть возможность разработки, если у них есть сильные компентенции, техническая глубина, возможности развертывания и сопровождения ПО. Те, кому не хватает глубоких инженерных ресурсов или кто предпочитает полагаться на инновации, управляемые поставщиками, могут рассмотреть системы COTS. Даже организациям с сильными ИТ-командами может быть трудно идти в ногу с темпами инноваций, предоставляемых ведущими поставщиками, которые вкладывают значительные средства в исследования и разработки и часто выпускают обновления. По мере того, как SaaS все чаще охватывает приложения, платформы и инфраструктуру данных в рамках единого предложения, организации могут оценить, поддерживает ли архитектура поставщика эту конвергенцию и обеспечивает ли она возможность расширения с течением времени. В конечном счете, все сводится к тому, могут ли организации поддерживать подход к сборке внутри компании или более эффективно сотрудничать с поставщиком. Для тех, кто уже использует платформу COTS, любое решение об обновлении может повлиять на готовность организации принять и внедрить улучшения, учитывая, что даже самые лучшие новые функции не принесут прибыли, если бизнес не готов их внедрить.
6. Риски во время миграции и а ходе эксплуатации. Разработка обеспечивает больший контроль над безопасностью, соответствием требованиям и нормативными рисками; минимизирует привязку к поставщику; и может быть правильным выбором для организаций, обладающих возможностями управления миграционными рисками и возможностями долгосрочного обслуживания системы. Организации могут рассмотреть возможность покупки, если они хотят проверенное решение с меньшим риском, имеют потребность в снижении сложности миграции, хотят комфортно работать с обновлениями безопасности, соответствовать нормативным требованиям. Организации также могут учитывать масштаб и сложность требований к соответствию, потенциальное операционное влияние миграции и долгосрочный компромисс между надежностью поставщика и внутренними возможностями управления рисками. Для существующих пользователей COTS значительные обновления сопряжены с риском, особенно если платформа претерпела сильные изменения или ландшафт интеграции сложен. Организации могут оценить операционное и бизнес-влияние процесса модернизации и сопоставить его с затратами на обслуживание устаревших систем и задержку трансформации.
Покупка современной системы может ускорить внедрение, тем не менее выбор подходящего решения и поставщика становится стратегической задачей. К распространенным ошибкам относятся выбор поставщиков без доказанной масштабируемости, недооценка проблем и сложности интеграции, а также ограниченная видимость возможностей платформы, слабые сети технической поддержки или недостаточное обучение. Организации должны оценивать, обладает ли поставщик финансовым благополучием, операционной дисциплиной и экосистемой для поддержания непрерывных инноваций. Выбор времени и способа обновления, а также подтверждение долгосрочного соответствия поставщика бизнес-модели и архитектуре требует такой же тщательности, как и первоначальный выбор поставщика. Существует шесть критериев, которые следует учитывать при выборе поставщика.
Лучшие в своем классе поставщики предлагают следующее:
1. Масштабируемость и готовность к росту. Лучшая в своем классе платформа широко используется ведущими организациями, подкреплена тематическими исследованиями и отзывами клиентов и может масштабироваться для поддержки растущих объемов бизнеса, географического расширения и потребностей многопрофильного бизнеса. Важно отметить, что организации могут оценить, имеет ли поставщик достаточный свободный денежный поток для финансирования текущих исследований и разработок, гарантируя, что платформа продолжит развиваться и не будет стагнировать с течением времени. Кроме того, платформа может продемонстрировать гибкость инфраструктуры благодаря дизайну, ориентированному на API, и микросервисной архитектуре.
2. Гибкость и системная интеграция. Гибкая платформа предоставляет целевые решения для конкретных этапов цепочки создания стоимости и легко интегрируется с другими внутренними или сторонними системами. Он может иметь широкий спектр документированных API с быстрым временем отклика и высоким временем безотказной работы системы, а также готовые коннекторы для стандартных отраслевых систем, что снизит потребность в обширной пользовательской разработке. Продвинутые платформы также обычно имеют надежную партнерскую сеть для обеспечения доступ к дополнительным решениям. Активная экосистема с различными каналами подачи данных на платформу, такими как сторонние приложения, партнеры и инструменты для разработчиков, помогает поддерживать актуальность и актуальность платформы.
3. Доверие и присутствие на рынке. Надежный поставщик должен обладать доказанной способностью стимулировать инновации в отрасли. В частности, поставщики со значительным присутствием на рынке имеют проверенные решения.
4. Сотрудничество и влияние на продукт. Сотрудничающий поставщик активно взаимодействует со своими клиентами для улучшения существующих продуктов и разработки новых функций и обновлений. Они вовлекают клиентов в процесс обновления продукта с помощью таких инструментов, как группы пользователей, консультативные советы и механизмы сбора отзывов через онлайн-порталы и специальных менеджеров по работе с клиентами. Сотрудничающие поставщики также прозрачны в отношении своей дорожной карты развития с четкими сроками и контрольными точками.
5. Функциональность и адаптивность функций. Универсальная платформа предлагает широкий и сложный набор функций, предназначенных для различных сценариев использования, с расширенными основными функциями, такими как динамические конфигурации продуктов, возможности самообслуживания клиентов и автоматизированная проверка соответствия. Лучшие в своем классе вендоры регулярно расширяют возможности платформы с помощью готовых решений и обеспечивают настройку без кода или с минимумом программирования. Платформа также может быть адаптирована к будущим требованиям, особенно к поддержке передовых технологий.
6. Сторонняя сервисная сеть и покрытие. Надежный поставщик имеет надежную сеть сторонних поставщиков услуг для внедрения и операционной поддержки, о чем обычно свидетельствует количество и глубина отношений с партнерами по системной интеграции, охватывающая географические регионы и предоставляющая местную поддержку и экспертные знания. Что еще более важно, эти сторонние партнеры могут иметь репутацию надежности обслуживания, подкрепленную последовательным соблюдением соглашений об уровне обслуживания, а также высокими историческими показателями эффективности.
К модернизации системы часто подходят как к технологической инициативе, но ее успех в равной степени зависит от лидерства в бизнесе. По своей сути модернизация — это трансформация бизнеса, требующая переосмысления процессов для реализации всей стратегической и операционной ценности системы. В настоящее время мы находимся на этапе демаркации, когда руководство бизнесом и ИТ больше не может работать параллельно — современная трансформация требует интегрированной, гибкой операционной модели, в которой бизнес и технологии совместно владеют результатами. Тесное взаимодействие и согласованность между руководителями бизнеса и технологий имеют решающее значение для обеспечения того, чтобы организация работала над достижением общей повестки дня.
Шаги для начала процесса модернизации:
Модернизация систем — это трансформационный процесс, требующий тщательного планирования, эффективного управления и тесного сотрудничества между бизнесом и технологиями. Успех начинается со структурированного подхода к оценке этих вариантов, выбору правильных решений или поставщиков, а также созданию эффективной операционной модели, обеспечивающей подотчетность и эффективное принятие решений. Эффективное управление изменениями, например, путем обучения пользователей и согласования действий заинтересованных сторон, не менее важно, но часто упускается из виду. Имея четкую дорожную карту и правильную модель исполнения, организации могут максимизировать ценность своих основных систем и позиционировать себя для устойчивого долгосрочного роста.
Данный материал был немного переработан на основе следующей статьи
Как страховщики P&C могут успешно модернизировать основные системы. 12 мая 2025 г. Криш Кришнакантан, Санджай Канияр, Танги Кэтлин, Софи Ру.
How P&C insurers can successfully modernize core systems. Krish Krishnakanthan, Sanjay Kaniyar, Tanguy Catlin, Sophie Ru.
https://www.mckinsey.com/industries/financial-services/our-insights/how-p-and-c-insurers-can-successfully-modernize-core-systems
Технологическая модернизация часто рассматривается как ИТ-инициатива, требующая ограниченного участия заинтересованных сторон бизнеса. Тем не менее, готовность к переосмыслению и перестройке бизнес-процессов имеет решающее значение для успешного преобразования основных систем.
Разрабатывать или покупать? Шесть аспектов трансформации основных платформ
Решение о том, следует ли создавать индивидуальные решения собственными силами, приобретать коммерческие готовые платформы (COTS - commercial off-the-shelf) или модернизировать существующие системы, является сложным выбором. Центр тяжести в этом вопросе смещается — все меньше пользователей стремятся к полноценным кастомным сборкам, и все больше изучают способы расширения устаревших систем с помощью современных оболочек или использования платформ SaaS.
У каждого подхода есть плюсы и минусы. Пользователи, использующие собственные сборки, имеют больший контроль, индивидуальные возможности и более легкую адаптацию к будущим инновациям. Однако они, как правило, сталкиваются с проблемами длительных сроков, ограниченной масштабируемости и растущих затрат и недооценивают полную стоимость долгосрочного обслуживания и постоянных инноваций. В проектах по сборке инновации часто закрепляются на этапе ввода в эксплуатацию, а когда происходит перерасход средств, имеется недостаточная документация, сокращаются расходы на обучение, это лишают организацию возможности развивать платформу.
Организации, выбирающие платформы COTS, получают более быстрое внедрение и более широкие инновационные возможности благодаря модели постоянных изменений, в которой поставщик управляет непрерывным развитием платформы. Тем не менее, они часто сталкиваются с проблемами с использованием всего потенциала новых систем. Современные пакеты могут удовлетворить потребности за счет конфигурации без серьезной настройки, но они по прежнему очень сложны. В результате, даже внедрение COTS может потребовать длительных временных рамок для преодоления проблем интеграции и адаптации к все более сложной архитектуре приложений.
Детальная оценка по шести ключевым параметрам может помочь принять обоснованное решение о том, следует ли создавать новую платформу, покупать решение COTS или модернизировать существующую платформу.
К критическим параметрам относятся следующие:
1. Функционал и возможности платформы. Если бизнес-модель требует специализированной функциональности, значительной кастомизации или сложной интеграции, организация может рассмотреть возможность разработки системы. Для тех, кто готов адаптировать бизнес-процессы и уделять приоритетное внимание времени выхода на рынок, экономической эффективности и инновациям, COTS может подойти лучше всего, особенно с учетом того, что платформы продолжают добиваться успехов в улучшении своей конфигурируемости и более эффективном удовлетворении уникальных потребностей продуктов.Во всех случаях приоритетом должно быть то, сможет ли платформа поддерживать будущий рост и расширение продукта, не запирая бизнес в хрупких обходных путях.
2. Настройка рабочих потоков и опыт цифровизации. Организации могут рассмотреть возможность разработки, если у них есть узкоспециализированные рабочие процессы и им требуется индивидуальное решение. Покупка предоставит систему со встроенными и готовыми рабочими процессами. Другие соображения включают требуемый уровень автоматизации процессов и степень гибкости при внесении изменений в рабочий процесс. Для операторов, обновляющихся в рамках экосистемы COTS, вопрос заключается в том, улучшит ли новая версия скорость, автоматизацию или пользовательский опыт настолько, чтобы оправдать затраты и сбои в обновлении.
3. Управление, безопасность и контроль данных. Организации могут рассмотреть возможность разработки, если они отдадут приоритет индивидуальному управлению, полному контролю над проприетарными моделями данных и настраиваемым протоколам безопасности. Организациям выгоднее покупать модульные, масштабируемые решения с предварительно созданными расширенными аналитическими возможностями и которые могут принимать обновления безопасности, управляемые поставщиком платформы. Организации могут оценить, согласуются ли инновации от поставщиков с их ИТ-стратегией или сохранение контроля над проприетарными моделями имеет решающее значение, хотя современные COTS-платформы все чаще предлагают настраиваемое управление данными и надежные функции безопасности. Организации, уже использующие платформу поставщика, могут рассмотреть, обеспечивает ли обновление значимые улучшения в аналитике, переносимости данных и контроле рисков.
4. Время выхода на рынок и стоимость. Создание системы требует более высоких первоначальных инвестиций, а требуемая обширная разработка и интеграция означает, что внедрение может занять от пяти до десяти лет. Платформы COTS обычно предлагают более низкие первоначальные затраты и внедрение в течение трех-пяти лет за счет использования конфигурации с минимумом программирования и минимальной настройки для ускорения развертывания. Но даже в среде одного и того же поставщика серьезное обновление может потребовать тщательного тестирования, перенастройки и изменения бизнеса. Другими факторами являются совокупная стоимость владения, долгосрочная масштабируемость и предсказуемость затрат по мере роста бизнеса, а также то, соответствует ли новая модель амбициям роста или же индивидуальная сборка обеспечивает лучший контроль над затратами с течением времени.
5. Организационные возможности и инновации. Организации могут рассмотреть возможность разработки, если у них есть сильные компентенции, техническая глубина, возможности развертывания и сопровождения ПО. Те, кому не хватает глубоких инженерных ресурсов или кто предпочитает полагаться на инновации, управляемые поставщиками, могут рассмотреть системы COTS. Даже организациям с сильными ИТ-командами может быть трудно идти в ногу с темпами инноваций, предоставляемых ведущими поставщиками, которые вкладывают значительные средства в исследования и разработки и часто выпускают обновления. По мере того, как SaaS все чаще охватывает приложения, платформы и инфраструктуру данных в рамках единого предложения, организации могут оценить, поддерживает ли архитектура поставщика эту конвергенцию и обеспечивает ли она возможность расширения с течением времени. В конечном счете, все сводится к тому, могут ли организации поддерживать подход к сборке внутри компании или более эффективно сотрудничать с поставщиком. Для тех, кто уже использует платформу COTS, любое решение об обновлении может повлиять на готовность организации принять и внедрить улучшения, учитывая, что даже самые лучшие новые функции не принесут прибыли, если бизнес не готов их внедрить.
6. Риски во время миграции и а ходе эксплуатации. Разработка обеспечивает больший контроль над безопасностью, соответствием требованиям и нормативными рисками; минимизирует привязку к поставщику; и может быть правильным выбором для организаций, обладающих возможностями управления миграционными рисками и возможностями долгосрочного обслуживания системы. Организации могут рассмотреть возможность покупки, если они хотят проверенное решение с меньшим риском, имеют потребность в снижении сложности миграции, хотят комфортно работать с обновлениями безопасности, соответствовать нормативным требованиям. Организации также могут учитывать масштаб и сложность требований к соответствию, потенциальное операционное влияние миграции и долгосрочный компромисс между надежностью поставщика и внутренними возможностями управления рисками. Для существующих пользователей COTS значительные обновления сопряжены с риском, особенно если платформа претерпела сильные изменения или ландшафт интеграции сложен. Организации могут оценить операционное и бизнес-влияние процесса модернизации и сопоставить его с затратами на обслуживание устаревших систем и задержку трансформации.
Выбор поставщика: поиск подходящего стратегического партнера
Покупка современной системы может ускорить внедрение, тем не менее выбор подходящего решения и поставщика становится стратегической задачей. К распространенным ошибкам относятся выбор поставщиков без доказанной масштабируемости, недооценка проблем и сложности интеграции, а также ограниченная видимость возможностей платформы, слабые сети технической поддержки или недостаточное обучение. Организации должны оценивать, обладает ли поставщик финансовым благополучием, операционной дисциплиной и экосистемой для поддержания непрерывных инноваций. Выбор времени и способа обновления, а также подтверждение долгосрочного соответствия поставщика бизнес-модели и архитектуре требует такой же тщательности, как и первоначальный выбор поставщика. Существует шесть критериев, которые следует учитывать при выборе поставщика.
Лучшие в своем классе поставщики предлагают следующее:
1. Масштабируемость и готовность к росту. Лучшая в своем классе платформа широко используется ведущими организациями, подкреплена тематическими исследованиями и отзывами клиентов и может масштабироваться для поддержки растущих объемов бизнеса, географического расширения и потребностей многопрофильного бизнеса. Важно отметить, что организации могут оценить, имеет ли поставщик достаточный свободный денежный поток для финансирования текущих исследований и разработок, гарантируя, что платформа продолжит развиваться и не будет стагнировать с течением времени. Кроме того, платформа может продемонстрировать гибкость инфраструктуры благодаря дизайну, ориентированному на API, и микросервисной архитектуре.
2. Гибкость и системная интеграция. Гибкая платформа предоставляет целевые решения для конкретных этапов цепочки создания стоимости и легко интегрируется с другими внутренними или сторонними системами. Он может иметь широкий спектр документированных API с быстрым временем отклика и высоким временем безотказной работы системы, а также готовые коннекторы для стандартных отраслевых систем, что снизит потребность в обширной пользовательской разработке. Продвинутые платформы также обычно имеют надежную партнерскую сеть для обеспечения доступ к дополнительным решениям. Активная экосистема с различными каналами подачи данных на платформу, такими как сторонние приложения, партнеры и инструменты для разработчиков, помогает поддерживать актуальность и актуальность платформы.
3. Доверие и присутствие на рынке. Надежный поставщик должен обладать доказанной способностью стимулировать инновации в отрасли. В частности, поставщики со значительным присутствием на рынке имеют проверенные решения.
4. Сотрудничество и влияние на продукт. Сотрудничающий поставщик активно взаимодействует со своими клиентами для улучшения существующих продуктов и разработки новых функций и обновлений. Они вовлекают клиентов в процесс обновления продукта с помощью таких инструментов, как группы пользователей, консультативные советы и механизмы сбора отзывов через онлайн-порталы и специальных менеджеров по работе с клиентами. Сотрудничающие поставщики также прозрачны в отношении своей дорожной карты развития с четкими сроками и контрольными точками.
5. Функциональность и адаптивность функций. Универсальная платформа предлагает широкий и сложный набор функций, предназначенных для различных сценариев использования, с расширенными основными функциями, такими как динамические конфигурации продуктов, возможности самообслуживания клиентов и автоматизированная проверка соответствия. Лучшие в своем классе вендоры регулярно расширяют возможности платформы с помощью готовых решений и обеспечивают настройку без кода или с минимумом программирования. Платформа также может быть адаптирована к будущим требованиям, особенно к поддержке передовых технологий.
6. Сторонняя сервисная сеть и покрытие. Надежный поставщик имеет надежную сеть сторонних поставщиков услуг для внедрения и операционной поддержки, о чем обычно свидетельствует количество и глубина отношений с партнерами по системной интеграции, охватывающая географические регионы и предоставляющая местную поддержку и экспертные знания. Что еще более важно, эти сторонние партнеры могут иметь репутацию надежности обслуживания, подкрепленную последовательным соблюдением соглашений об уровне обслуживания, а также высокими историческими показателями эффективности.
Практические шаги для начала работы
К модернизации системы часто подходят как к технологической инициативе, но ее успех в равной степени зависит от лидерства в бизнесе. По своей сути модернизация — это трансформация бизнеса, требующая переосмысления процессов для реализации всей стратегической и операционной ценности системы. В настоящее время мы находимся на этапе демаркации, когда руководство бизнесом и ИТ больше не может работать параллельно — современная трансформация требует интегрированной, гибкой операционной модели, в которой бизнес и технологии совместно владеют результатами. Тесное взаимодействие и согласованность между руководителями бизнеса и технологий имеют решающее значение для обеспечения того, чтобы организация работала над достижением общей повестки дня.
Шаги для начала процесса модернизации:
- Заранее определите и согласуйте бизнес-цели и цели в области технологий. Прежде чем оценивать решения, согласуйте внутри компании желаемые бизнес-результаты и приоритеты модернизации. Общие цели включают повышение операционной эффективности, ускорение выхода на рынок, улучшение цифрового обслуживания клиентов и сокращение долгосрочных затрат на ИТ.
- Проведите структурированную оценку "разработка в сравнении с покупкой или обновлением". Используйте четкую структуру для оценки бизнес-потребностей, сложности продукта и технологических приоритетов по ключевым параметрам, таким как функциональность, стоимость, скорость, масштабируемость и риски. Это гарантирует, что решение будет объективным. Подумайте о том, как система должна развиваться в будущем, чтобы поддерживать меняющиеся предложения продуктов, цифровую дистрибуцию и интеграцию экосистемы.
- Оцените внутреннюю готовность и пробелы в возможностях. Оцените внутренние возможности для выполнения крупномасштабной трансформации, включая доступные таланты, возможности, существующую инфраструктуру, сложность интеграции и согласованность руководства. Знание своих ограничений может помочь спланировать правильную поддержку, будь то через поставщиков, внутреннее повышение квалификации или найм.
- Проведите выбор поставщика или оценку обновления. Выйдите за рамки списков функций и оцените долгосрочную жизнеспособность, гибкость интеграции, партнерство в экосистеме и сотрудничество между поставщиками и клиентами. Для существующих пользователей платформы оцените, значительно ли предлагаемое обновление расширяет возможности, устраняет ли оно болевые точки и согласуется ли оно с бизнес-целями без чрезмерного риска внедрения.
- Расставьте приоритеты и определите последовательность инициатив. Управляйте сложностью трансформации и постепенно достигайте результатов с помощью структурированной дорожной карты. На начальном этапе можно было бы сосредоточиться на быстрых победах, которые соответствуют бизнес-приоритетам, обеспечивая ранний успех для наращивания темпов и совершенствования процессов. На последующих этапах можно было бы заняться высокоприоритетными инициативами с учетом зависимостей, рисков и доступности ресурсов.
- Обеспечьте эффективное управление проектами. С самого начала обеспечьте эффективное управление, например принятие решений, права и пути эскалации, чтобы избежать задержек, управлять масштабом и сосредоточить команды на создании ценности, а не только на достижении контрольных точек. Модернизация — это многолетний процесс, который с самого начала требует жесткого управления для управления сотрудничеством между бизнес-командами и технологическими командами.
- Реализуйте управление изменениями и стимулируйте их внедрение. Сведите к минимуму сопротивление и максимизируйте отдачу от трансформации с помощью таких инициатив, как четкое изложение видения (например, с помощью информационного бюллетеня компании, общего собрания или сессии вопросов и ответов сотрудников), обеспечение согласованности руководства и постоянной поддержки, проведение целевых программ обучения и поддержание структурированных каналов обратной связи для решения проблем и совершенствования процессов трансформации.
Модернизация систем — это трансформационный процесс, требующий тщательного планирования, эффективного управления и тесного сотрудничества между бизнесом и технологиями. Успех начинается со структурированного подхода к оценке этих вариантов, выбору правильных решений или поставщиков, а также созданию эффективной операционной модели, обеспечивающей подотчетность и эффективное принятие решений. Эффективное управление изменениями, например, путем обучения пользователей и согласования действий заинтересованных сторон, не менее важно, но часто упускается из виду. Имея четкую дорожную карту и правильную модель исполнения, организации могут максимизировать ценность своих основных систем и позиционировать себя для устойчивого долгосрочного роста.
Источник
Данный материал был немного переработан на основе следующей статьи
Как страховщики P&C могут успешно модернизировать основные системы. 12 мая 2025 г. Криш Кришнакантан, Санджай Канияр, Танги Кэтлин, Софи Ру.
How P&C insurers can successfully modernize core systems. Krish Krishnakanthan, Sanjay Kaniyar, Tanguy Catlin, Sophie Ru.
https://www.mckinsey.com/industries/financial-services/our-insights/how-p-and-c-insurers-can-successfully-modernize-core-systems
воскресенье, 20 июля 2025 г.
Соляной тайфун: взлом китайского телефона
Соляной тайфун: взлом китайского телефона.
Брайан Даннинг 4 февраля 2025 г.
В конце 2024 года новостные агентства по всему миру сообщили, что следователи обнаружили масштабную китайскую кибератаку на американские сети сотовой связи. Многие описали ее как крупнейшую подобную утечку в истории. Когда выяснилось, что Дональд Трамп, Джей Ди Вэнс, Камала Харрис и многие из их сотрудников были включены в атаку, многие люди решили, что это часть скоординированной схемы по влиянию на исход выборов в США. Это также произошло во время эскалации торговой войны между Соединенными Штатами и Китаем, и некоторые интерпретировали это как китайский ответ на торговую войну. Хакерская группа называлась Salt Typhoon, и сегодня мы собираемся глубоко в ней разобраться и посмотреть, о чем она на самом деле, а о чем нет.
Salt Typhoon — это название, которое исследователи безопасности Microsoft дали большой и разносторонней группе хакеров в Китае. Мы не знаем, как они себя называют, если вообще называют; но известно, что они являются китайским подрядчиком, часто используемым Министерством государственной безопасности Китая. Salt Typhoon проникли в компьютерные системы не только в Соединенных Штатах, но и в десятках стран. Иногда они крадут корпоративную интеллектуальную собственность и проводят множество атак на отели, чтобы украсть их данные, но их основное внимание сосредоточено на национальных системах контрразведки, пытаясь выяснить, что их международные коллеги знают о них. Они также известны под другими названиями, данными другими компаниями по безопасности: Earth Estrie, Ghost Emperor, Famous Sparrow; но Salt Typhoon — наиболее часто используемое.
Если говорить нетехническим языком, то вот как они это сделали. Хакеры использовали уязвимости в определенных сетевых устройствах, таких как брандмауэры или маршрутизаторы. Производители этих устройств постоянно ищут такие уязвимости, и когда они их находят, они выпускают обновление программного обеспечения, чтобы исправить их. Но владельцы устройств не всегда применяют эти обновления, оставляя устройства открытыми для общедоступной уязвимости.
Существуют программы, известные как инструменты проникновения, которые автоматически ищут определенные уязвимости. Если у вас есть веб-сайт, он был проверен этими инструментами. Журналы вашего сервера, вероятно, показывают, что были предприняты попытки доступа к общим URL-адресам порталов администраторов, таким как /login или /administrator, и многим другим. Распространенные имена пользователей и пароли, такие как admin и 123456 , отправляются массово — практически все из списка 10 000 самых распространенных паролей Википедии. Очевидно, что подавляющее большинство из них терпят неудачу, но иногда один из них проходит. Когда это происходит, хакер получает уведомление, и теперь он может войти в вашу систему как администратор и начать ковыряться. Это относительно глупая атака, называемая грубой силой.
Но даже если это не удается, есть другие атаки, которые может попробовать инструмент проникновения. Одна из самых распространенных называется атакой инъекции. Известный пример этого был проиллюстрирован в популярном комиксе xkcd 2007 года, широко известном как « Little Bobby Tables ». Когда вы вводите информацию в веб-форму, например, свое имя пользователя и пароль на экране входа в систему, вы можете добавить команды базы данных к своим входным данным, которые небрежно защищенный веб-сайт мог бы фактически выполнить. Little Bobby Tables использовал это, чтобы удалить всю базу данных учеников в своей школе. Этот метод также можно использовать для установки программы на сервер, программы, которая может сделать что угодно, например, предоставить хакеру доступ для получения полного контроля над сервером.
Другой похожий метод называется атакой переполнения буфера, при которой в форму передается так много данных, что они могут перезаписать плохо защищенную часть памяти сервера программным кодом, который делает все, что захочет хакер.
Другая очень распространенная атака, которую Salt Typhoon, как известно, использовала в этом случае, называется целевым фишингом. Это когда хакеры идентифицируют конкретного человека в компании, у которого есть нужный им тип доступа. Затем хакеры отправляют этому человеку поддельные электронные письма или текстовые сообщения с просьбой войти в их систему, которые выглядят как обычные сообщения от системы. Если это обманывает человека, он переходит на веб-сайт, который выглядит знакомым, но на самом деле является копией, и вводит свое имя пользователя и пароль. Но они не попадают туда, куда они думают; эти учетные данные отправляются прямо хакеру, который затем может ими воспользоваться.
Существует много таких атак; вот лишь несколько из них, иллюстрирующих общую идею. Маршрутизатор или другое сетевое устройство имеет много тех же функций, что и другие серверы; им можно управлять удаленно, поэтому у него должны быть эти основные функции, которые позволяют хакерам совершать только что обсуждаемые типы атак или их вариации, которые слишком сложны, чтобы вдаваться в них здесь, но это та же самая основная идея.
Получив административный доступ к удаленному устройству, хакер может управлять им со своего компьютера, где бы он ни находился. Существуют также уловки, которые они могут использовать, чтобы скрыть свое соединение, так что невозможно будет отследить их до их фактического местоположения. В лучшем случае они могут использовать свой доступ, чтобы делать все, что может делать администратор. Они могут искать в базах данных, они могут загружать что-то, они могут удалять что-то. Они могут создавать новые секретные проходы, через которые они могут продолжать получать доступ к системе, даже если учетные данные или другой метод доступа, который они использовали изначально, были изменены или заблокированы. И следует подчеркнуть, что почти все это можно автоматизировать и выполнять в огромных масштабах и с ошеломляющей скоростью.
По оценкам, к концу 2024 года Salt Typhoon скомпрометировал около 100 000 устройств Fortinet и Cisco только внутри сети AT&T. В целом подтверждено, что Salt Typhoon взломал девять американских телекоммуникационных компаний, включая Verizon, AT&T, T-Mobile и шесть других.
Все это дало китайцам доступ к записям телефонных звонков практически любого американца, которого они хотели. Это не так уж и удивительно, поскольку любой компетентный хакер может получить эти данные; вам не обязательно быть частью Salt Typhoon. Совсем недавно, в январе 2025 года, 20-летний солдат американской армии был арестован за доступ и продажу журналов звонков обоих кандидатов в президенты США Дональда Трампа и Камалы Харрис. У обоих были журналы звонков с мобильных телефонов в AT&T, и ни у одного из них не была настроена двухфакторная аутентификация. Это говорит нам о том, что солдат почти наверняка проник в AT&T через один из распространенных типов атак, обсуждавшихся ранее.
Согласно журналам, проанализированным исследователями безопасности, Salt Typhoon в основном ограничила кражу данных о звонках несколькими десятками правительственных чиновников, включая сотрудников предвыборных штабов обоих кандидатов в президенты на выборах 2024 года. Однако атака, по-видимому, не была связана с попытками повлиять на выборы. Китай тоже делает много такого, но это совсем другие проекты.
Так что фактом является то, что Китай действительно получил огромные объемы данных о том, кто кому звонил, в основном относительно небольшому числу чиновников, и много данных о том, кто останавливался в каких отелях по всему миру. Однако жемчужиной их взлома была база данных прослушки Министерства юстиции США. Она включала все телефонные номера, которые прослушивало любое федеральное агентство. Это сообщило Китаю, кого США расследуют по любой причине: возможно, подозреваемых преступников, наркобаронов и, что самое главное, подозреваемых иностранных агентов. Предположив, что у Китая были шпионы в Соединенных Штатах, что, конечно, было и есть до сих пор, данные прослушки сообщили им, находятся ли какие-либо из их шпионов под следствием. Они также сообщили Китаю, каких шпионов из других стран расследуют США. С точки зрения контрразведки, это была чрезвычайно успешная атака.
Что еще они планируют делать со всеми этими данными, на самом деле является предметом спекуляций. Предполагается, что они используют механизмы искусственного интеллекта для анализа всех этих данных, ищут закономерности, строят карты социальных связей, возможно, выясняя, кто с кем связан в Вашингтоне и какие проекты привлекают наибольшее внимание.
Итак: утверждения о том, что взлом телекоммуникаций 2024 года был попыткой вмешательства в выборы, не соответствуют действительности. Утверждения о том, что это имело отношение к торговой войне между США и Китаем, также не соответствуют действительности. И есть еще кое-что…
Обычно, когда я выбираю тему для Skeptoid, я предпочитаю, чтобы это был решенный вопрос, что позволяет мне быть более всеобъемлющим и иметь преимущество ретроспективного взгляда. Однако на дату этого шоу, то есть на февраль 2025 года, у нас есть некоторые срочные новости об этой конкретной кибератаке. Когда о ней впервые сообщили в конце 2024 года, было объявлено, что расследование будет возглавлять Совет по рассмотрению кибербезопасности Министерства внутренней безопасности США. CSRB должен быть похож на NTSB, Национальный совет по транспорту и безопасности, наиболее известный тем, что отправляет самых опытных в мире следователей на места авиакатастроф, железнодорожных катастроф и т. д., чтобы найти, что пошло не так, и не допустить повторения этого. Именно этим CSRB и занимался в течение нескольких месяцев после обнаружения кибератаки. Но затем, как только президент Трамп вступил в должность в январе 2025 года, одним из его первых действий было увольнение всех в CSRB — всех профессиональных экспертов. Высокопоставленный член Комитета по внутренней безопасности Палаты представителей заявил: «Я обеспокоен тем, что попытка президента укомплектовать CSRB лоялистами может привести к задержке его важной работы по кампании по ликвидации последствий соляного тайфуна».
Использование им термина «лоялисты» вероятно было отсылкой к известному своей беспристрастностью члену CSRB Крису Кребсу, который в конце 2020 года был директором Агентства по кибербезопасности и безопасности инфраструктуры и был уволен Трампом за то, что его агентство пришло к выводу о том, что утверждение Трампа о том, что машины для голосования были взломаны, что способствовало поражению Трампа на выборах, было ложным.
Другие правоохранительные органы все еще работают над тем, чтобы выследить Salt Typhoon и привлечь их к ответственности, но CSRB был оборонным стратегом правительства США, который предотвратил следующую подобную атаку. Извините, если это объяснение прозвучало предвзято или было оскорбительным для кого-то — это не то, о чем Skeptoid — но было необходимо объяснить, как и почему Соединенные Штаты вряд ли построят своевременную защиту от Salt Typhoon или следующей группы, которая пойдет по их стопам.
И вот вам это. Когда вы слышите в новостях что-то сенсационное, как это было, вашей первой реакцией всегда должен быть скептицизм. Когда вы видите дикие утверждения в социальных сетях, утверждающие, что это было на самом деле, вы должны быть скептичны. И когда вы это делаете, вы обратитесь к первоисточникам — не политически предвзятым источникам, всегда — и получите чистую информацию. И сделайте это лучше. Когда предмет требует определенной экспертизы, чтобы действительно понять его, в данном случае кибербезопасность; перейдите на тематические веб-сайты — веб-сайты кибербезопасности для этого события — и узнайте, что говорят настоящие эксперты в этой области. Потому что, как правило, вы обнаружите, что СМИ немного недооценили вас.
Даннинг, Б. (2025, 4 февраля) Соляной тайфун: китайский телефонный взлом. Skeptoid Media. https://skeptoid.com/episodes/4974
Ссылки и дополнительная литература
Мэлоун, К. «Трамп увольняет Кребса из CISA в связи с уходом ряда ведущих киберспециалистов». Cybersecurity Dive. TechTarget, Inc., 17 ноября 2020 г. Веб-сайт. 2 февраля 2025 г. <https://www.cybersecuritydive.com/news/chris-krebs-cisa-election-security/588978/>
Монтгомери, Б. «Почему Китай взломал мировые телефонные сети?» The Guardian. Guardian News & Media Limited, 12 декабря 2024 г. Интернет. 2 февраля 2025 г. <https://www.theguardian.com/technology/2024/dec/09/why-did-china-hack-the-worlds-phone-networks>
Сэндифорд, М. «Совет по проверке кибербезопасности DHS рассмотрит атаку Salt Typhoon». Федеральная новостная сеть. Радио Хаббард Вашингтон, округ Колумбия, LLC, 29 октября 2024 г. Веб-сайт. 2 февраля 2025 г. <https://federalnewsnetwork.com/federal-newscast/2024/10/dhs-cyber-security-safety-review-board-to-examine-salt-typhoon-attack/>
Старкс, Т. «Устранение членов Совета по рассмотрению кибербезопасности вызвало тревогу у киберпрофессионалов, ключевого законодателя». Cyberscoop. Scoop News Group, 22 января 2025 г. Веб-сайт. 2 февраля 2025 г. <https://cyberscoop.com/removal-cyber-safety-review-board-members/>
Volz, D., Viswanatha, A., Krouse, S., FitzGerald, D. «Как китайские хакеры перешли от неуклюжих корпоративных воров к военному оружию». The Wall Street Journal. Dow Jones & Company, Inc., 4 января 2025 г. Веб-сайт. 2 февраля 2025 г. <https://www.wsj.com/tech/cybersecurity/typhoon-china-hackers-military-weapons-97d4ef95>
Volz, D., Viswanatha, A., Krouse, S., FitzGerald, D., McMillan, R. «Хакеры украли журналы вызовов, незашифрованные тексты и некоторые аудиозаписи, взломав коммуникационную инфраструктуру Америки». The Wall Street Journal. Dow Jones & Company, Inc., 5 ноября 2025 г. Интернет. 2 февраля 2025 г. <https://www.wsj.com/politics/national-security/china-hack-enabled-vast-spying-on-us-officials-likely-ensnaring-thousands-of-contacts-1340ba4a>
Брайан Даннинг 4 февраля 2025 г.
В конце 2024 года новостные агентства по всему миру сообщили, что следователи обнаружили масштабную китайскую кибератаку на американские сети сотовой связи. Многие описали ее как крупнейшую подобную утечку в истории. Когда выяснилось, что Дональд Трамп, Джей Ди Вэнс, Камала Харрис и многие из их сотрудников были включены в атаку, многие люди решили, что это часть скоординированной схемы по влиянию на исход выборов в США. Это также произошло во время эскалации торговой войны между Соединенными Штатами и Китаем, и некоторые интерпретировали это как китайский ответ на торговую войну. Хакерская группа называлась Salt Typhoon, и сегодня мы собираемся глубоко в ней разобраться и посмотреть, о чем она на самом деле, а о чем нет.
Salt Typhoon — это название, которое исследователи безопасности Microsoft дали большой и разносторонней группе хакеров в Китае. Мы не знаем, как они себя называют, если вообще называют; но известно, что они являются китайским подрядчиком, часто используемым Министерством государственной безопасности Китая. Salt Typhoon проникли в компьютерные системы не только в Соединенных Штатах, но и в десятках стран. Иногда они крадут корпоративную интеллектуальную собственность и проводят множество атак на отели, чтобы украсть их данные, но их основное внимание сосредоточено на национальных системах контрразведки, пытаясь выяснить, что их международные коллеги знают о них. Они также известны под другими названиями, данными другими компаниями по безопасности: Earth Estrie, Ghost Emperor, Famous Sparrow; но Salt Typhoon — наиболее часто используемое.
Если говорить нетехническим языком, то вот как они это сделали. Хакеры использовали уязвимости в определенных сетевых устройствах, таких как брандмауэры или маршрутизаторы. Производители этих устройств постоянно ищут такие уязвимости, и когда они их находят, они выпускают обновление программного обеспечения, чтобы исправить их. Но владельцы устройств не всегда применяют эти обновления, оставляя устройства открытыми для общедоступной уязвимости.
Существуют программы, известные как инструменты проникновения, которые автоматически ищут определенные уязвимости. Если у вас есть веб-сайт, он был проверен этими инструментами. Журналы вашего сервера, вероятно, показывают, что были предприняты попытки доступа к общим URL-адресам порталов администраторов, таким как /login или /administrator, и многим другим. Распространенные имена пользователей и пароли, такие как admin и 123456 , отправляются массово — практически все из списка 10 000 самых распространенных паролей Википедии. Очевидно, что подавляющее большинство из них терпят неудачу, но иногда один из них проходит. Когда это происходит, хакер получает уведомление, и теперь он может войти в вашу систему как администратор и начать ковыряться. Это относительно глупая атака, называемая грубой силой.
Но даже если это не удается, есть другие атаки, которые может попробовать инструмент проникновения. Одна из самых распространенных называется атакой инъекции. Известный пример этого был проиллюстрирован в популярном комиксе xkcd 2007 года, широко известном как « Little Bobby Tables ». Когда вы вводите информацию в веб-форму, например, свое имя пользователя и пароль на экране входа в систему, вы можете добавить команды базы данных к своим входным данным, которые небрежно защищенный веб-сайт мог бы фактически выполнить. Little Bobby Tables использовал это, чтобы удалить всю базу данных учеников в своей школе. Этот метод также можно использовать для установки программы на сервер, программы, которая может сделать что угодно, например, предоставить хакеру доступ для получения полного контроля над сервером.
Другой похожий метод называется атакой переполнения буфера, при которой в форму передается так много данных, что они могут перезаписать плохо защищенную часть памяти сервера программным кодом, который делает все, что захочет хакер.
Другая очень распространенная атака, которую Salt Typhoon, как известно, использовала в этом случае, называется целевым фишингом. Это когда хакеры идентифицируют конкретного человека в компании, у которого есть нужный им тип доступа. Затем хакеры отправляют этому человеку поддельные электронные письма или текстовые сообщения с просьбой войти в их систему, которые выглядят как обычные сообщения от системы. Если это обманывает человека, он переходит на веб-сайт, который выглядит знакомым, но на самом деле является копией, и вводит свое имя пользователя и пароль. Но они не попадают туда, куда они думают; эти учетные данные отправляются прямо хакеру, который затем может ими воспользоваться.
Существует много таких атак; вот лишь несколько из них, иллюстрирующих общую идею. Маршрутизатор или другое сетевое устройство имеет много тех же функций, что и другие серверы; им можно управлять удаленно, поэтому у него должны быть эти основные функции, которые позволяют хакерам совершать только что обсуждаемые типы атак или их вариации, которые слишком сложны, чтобы вдаваться в них здесь, но это та же самая основная идея.
Получив административный доступ к удаленному устройству, хакер может управлять им со своего компьютера, где бы он ни находился. Существуют также уловки, которые они могут использовать, чтобы скрыть свое соединение, так что невозможно будет отследить их до их фактического местоположения. В лучшем случае они могут использовать свой доступ, чтобы делать все, что может делать администратор. Они могут искать в базах данных, они могут загружать что-то, они могут удалять что-то. Они могут создавать новые секретные проходы, через которые они могут продолжать получать доступ к системе, даже если учетные данные или другой метод доступа, который они использовали изначально, были изменены или заблокированы. И следует подчеркнуть, что почти все это можно автоматизировать и выполнять в огромных масштабах и с ошеломляющей скоростью.
По оценкам, к концу 2024 года Salt Typhoon скомпрометировал около 100 000 устройств Fortinet и Cisco только внутри сети AT&T. В целом подтверждено, что Salt Typhoon взломал девять американских телекоммуникационных компаний, включая Verizon, AT&T, T-Mobile и шесть других.
Все это дало китайцам доступ к записям телефонных звонков практически любого американца, которого они хотели. Это не так уж и удивительно, поскольку любой компетентный хакер может получить эти данные; вам не обязательно быть частью Salt Typhoon. Совсем недавно, в январе 2025 года, 20-летний солдат американской армии был арестован за доступ и продажу журналов звонков обоих кандидатов в президенты США Дональда Трампа и Камалы Харрис. У обоих были журналы звонков с мобильных телефонов в AT&T, и ни у одного из них не была настроена двухфакторная аутентификация. Это говорит нам о том, что солдат почти наверняка проник в AT&T через один из распространенных типов атак, обсуждавшихся ранее.
Согласно журналам, проанализированным исследователями безопасности, Salt Typhoon в основном ограничила кражу данных о звонках несколькими десятками правительственных чиновников, включая сотрудников предвыборных штабов обоих кандидатов в президенты на выборах 2024 года. Однако атака, по-видимому, не была связана с попытками повлиять на выборы. Китай тоже делает много такого, но это совсем другие проекты.
Так что фактом является то, что Китай действительно получил огромные объемы данных о том, кто кому звонил, в основном относительно небольшому числу чиновников, и много данных о том, кто останавливался в каких отелях по всему миру. Однако жемчужиной их взлома была база данных прослушки Министерства юстиции США. Она включала все телефонные номера, которые прослушивало любое федеральное агентство. Это сообщило Китаю, кого США расследуют по любой причине: возможно, подозреваемых преступников, наркобаронов и, что самое главное, подозреваемых иностранных агентов. Предположив, что у Китая были шпионы в Соединенных Штатах, что, конечно, было и есть до сих пор, данные прослушки сообщили им, находятся ли какие-либо из их шпионов под следствием. Они также сообщили Китаю, каких шпионов из других стран расследуют США. С точки зрения контрразведки, это была чрезвычайно успешная атака.
Что еще они планируют делать со всеми этими данными, на самом деле является предметом спекуляций. Предполагается, что они используют механизмы искусственного интеллекта для анализа всех этих данных, ищут закономерности, строят карты социальных связей, возможно, выясняя, кто с кем связан в Вашингтоне и какие проекты привлекают наибольшее внимание.
Итак: утверждения о том, что взлом телекоммуникаций 2024 года был попыткой вмешательства в выборы, не соответствуют действительности. Утверждения о том, что это имело отношение к торговой войне между США и Китаем, также не соответствуют действительности. И есть еще кое-что…
Обычно, когда я выбираю тему для Skeptoid, я предпочитаю, чтобы это был решенный вопрос, что позволяет мне быть более всеобъемлющим и иметь преимущество ретроспективного взгляда. Однако на дату этого шоу, то есть на февраль 2025 года, у нас есть некоторые срочные новости об этой конкретной кибератаке. Когда о ней впервые сообщили в конце 2024 года, было объявлено, что расследование будет возглавлять Совет по рассмотрению кибербезопасности Министерства внутренней безопасности США. CSRB должен быть похож на NTSB, Национальный совет по транспорту и безопасности, наиболее известный тем, что отправляет самых опытных в мире следователей на места авиакатастроф, железнодорожных катастроф и т. д., чтобы найти, что пошло не так, и не допустить повторения этого. Именно этим CSRB и занимался в течение нескольких месяцев после обнаружения кибератаки. Но затем, как только президент Трамп вступил в должность в январе 2025 года, одним из его первых действий было увольнение всех в CSRB — всех профессиональных экспертов. Высокопоставленный член Комитета по внутренней безопасности Палаты представителей заявил: «Я обеспокоен тем, что попытка президента укомплектовать CSRB лоялистами может привести к задержке его важной работы по кампании по ликвидации последствий соляного тайфуна».
Использование им термина «лоялисты» вероятно было отсылкой к известному своей беспристрастностью члену CSRB Крису Кребсу, который в конце 2020 года был директором Агентства по кибербезопасности и безопасности инфраструктуры и был уволен Трампом за то, что его агентство пришло к выводу о том, что утверждение Трампа о том, что машины для голосования были взломаны, что способствовало поражению Трампа на выборах, было ложным.
Другие правоохранительные органы все еще работают над тем, чтобы выследить Salt Typhoon и привлечь их к ответственности, но CSRB был оборонным стратегом правительства США, который предотвратил следующую подобную атаку. Извините, если это объяснение прозвучало предвзято или было оскорбительным для кого-то — это не то, о чем Skeptoid — но было необходимо объяснить, как и почему Соединенные Штаты вряд ли построят своевременную защиту от Salt Typhoon или следующей группы, которая пойдет по их стопам.
И вот вам это. Когда вы слышите в новостях что-то сенсационное, как это было, вашей первой реакцией всегда должен быть скептицизм. Когда вы видите дикие утверждения в социальных сетях, утверждающие, что это было на самом деле, вы должны быть скептичны. И когда вы это делаете, вы обратитесь к первоисточникам — не политически предвзятым источникам, всегда — и получите чистую информацию. И сделайте это лучше. Когда предмет требует определенной экспертизы, чтобы действительно понять его, в данном случае кибербезопасность; перейдите на тематические веб-сайты — веб-сайты кибербезопасности для этого события — и узнайте, что говорят настоящие эксперты в этой области. Потому что, как правило, вы обнаружите, что СМИ немного недооценили вас.
Даннинг, Б. (2025, 4 февраля) Соляной тайфун: китайский телефонный взлом. Skeptoid Media. https://skeptoid.com/episodes/4974
Ссылки и дополнительная литература
Мэлоун, К. «Трамп увольняет Кребса из CISA в связи с уходом ряда ведущих киберспециалистов». Cybersecurity Dive. TechTarget, Inc., 17 ноября 2020 г. Веб-сайт. 2 февраля 2025 г. <https://www.cybersecuritydive.com/news/chris-krebs-cisa-election-security/588978/>
Монтгомери, Б. «Почему Китай взломал мировые телефонные сети?» The Guardian. Guardian News & Media Limited, 12 декабря 2024 г. Интернет. 2 февраля 2025 г. <https://www.theguardian.com/technology/2024/dec/09/why-did-china-hack-the-worlds-phone-networks>
Сэндифорд, М. «Совет по проверке кибербезопасности DHS рассмотрит атаку Salt Typhoon». Федеральная новостная сеть. Радио Хаббард Вашингтон, округ Колумбия, LLC, 29 октября 2024 г. Веб-сайт. 2 февраля 2025 г. <https://federalnewsnetwork.com/federal-newscast/2024/10/dhs-cyber-security-safety-review-board-to-examine-salt-typhoon-attack/>
Старкс, Т. «Устранение членов Совета по рассмотрению кибербезопасности вызвало тревогу у киберпрофессионалов, ключевого законодателя». Cyberscoop. Scoop News Group, 22 января 2025 г. Веб-сайт. 2 февраля 2025 г. <https://cyberscoop.com/removal-cyber-safety-review-board-members/>
Volz, D., Viswanatha, A., Krouse, S., FitzGerald, D. «Как китайские хакеры перешли от неуклюжих корпоративных воров к военному оружию». The Wall Street Journal. Dow Jones & Company, Inc., 4 января 2025 г. Веб-сайт. 2 февраля 2025 г. <https://www.wsj.com/tech/cybersecurity/typhoon-china-hackers-military-weapons-97d4ef95>
Volz, D., Viswanatha, A., Krouse, S., FitzGerald, D., McMillan, R. «Хакеры украли журналы вызовов, незашифрованные тексты и некоторые аудиозаписи, взломав коммуникационную инфраструктуру Америки». The Wall Street Journal. Dow Jones & Company, Inc., 5 ноября 2025 г. Интернет. 2 февраля 2025 г. <https://www.wsj.com/politics/national-security/china-hack-enabled-vast-spying-on-us-officials-likely-ensnaring-thousands-of-contacts-1340ba4a>
воскресенье, 27 апреля 2025 г.
Технологический долг устаревших систем
Технологический долг устаревших систем создает существенные проблемы для бизнеса:
Медленный темп инноваций. Системы, созданные с использованием устаревших и сложных для понимания языков, серьезно ограничивают способность организации адаптироваться и внедрять инновации.
Ограниченная совместимость с современными каналами. Устаревшие технологии обычно плохо интегрируются с современными каналами, требующими данных в реальном времени и расширенного подключения.
Медленное реагирование на нормативные требования. Постоянно меняющиеся нормативные требования становится все сложнее и дороже соблюдать.
Риск устойчивости. Недостаточное понимание принципов работы систем в сочетании с ограниченными возможностями автоматизации и зачастую ручным тестированием приводит к проблемам нестабильности, которые трудно предсказать и устранить.
Высокие эксплуатационные расходы. Стоимость эксплуатации устаревших систем часто значительно выше, чем у современных систем. Например, для крупного европейского банка 70% его ИТ-мощностей было потрачено на поддержание устаревших систем.
Неэффективное использование капитала. Затраты на эксплуатацию устаревших систем не позволяют инвестировать в более ценные разработки.
Непривлекательность для лучших специалистов. Ведущие программисты и инженеры-программисты с меньшей вероятностью присоединятся к бизнесу, использующему устаревшие системы и устаревшие языки, которые они не понимают и не ценятся на рынке талантов.
Ограниченная совместимость с современными каналами. Устаревшие технологии обычно плохо интегрируются с современными каналами, требующими данных в реальном времени и расширенного подключения.
Медленное реагирование на нормативные требования. Постоянно меняющиеся нормативные требования становится все сложнее и дороже соблюдать.
Риск устойчивости. Недостаточное понимание принципов работы систем в сочетании с ограниченными возможностями автоматизации и зачастую ручным тестированием приводит к проблемам нестабильности, которые трудно предсказать и устранить.
Высокие эксплуатационные расходы. Стоимость эксплуатации устаревших систем часто значительно выше, чем у современных систем. Например, для крупного европейского банка 70% его ИТ-мощностей было потрачено на поддержание устаревших систем.
Неэффективное использование капитала. Затраты на эксплуатацию устаревших систем не позволяют инвестировать в более ценные разработки.
Непривлекательность для лучших специалистов. Ведущие программисты и инженеры-программисты с меньшей вероятностью присоединятся к бизнесу, использующему устаревшие системы и устаревшие языки, которые они не понимают и не ценятся на рынке талантов.
среда, 4 декабря 2024 г.
Архетипы и уникальность нагрузки центров обработки данных
Что делает нагрузку на центр обработки данных уникальной?
В зависимости от рабочей нагрузки центры обработки данных могут потреблять электроэнергию круглосуточно, с некоторыми колебаниями в течение дня, как и другие промышленные центры. Однако центры обработки данных обладают уникальным профилем, который отличает их от коммунальных компаний и инвесторов.
Во-первых, большинство центров обработки данных располагаются с резервными системами хранения энергии, чтобы обеспечить выполнение высоких требований к времени безотказной работы. Эта резервная система может быть направлена для компенсации нагрузки центра обработки данных, когда условия в сети становятся напряженными, тем самым создавая нагрузку, которая, по сути, является высокочувствительной.
Во-вторых, владельцы центров обработки данных обычно более склонны платить за электроэнергию, чем большинство других потребителей электроэнергии. Эксплуатационные расходы на электроэнергию могут составлять около 20% от общей стоимости бизнес-моделей центров обработки данных, которые оказались весьма прибыльными для крупных компаний. Поэтому более высокие тарифы на электроэнергию не нарушают бизнес-модель. Для сравнения, для других источников электроэнергии, таких как производство зеленого водорода, себестоимость конечного продукта сильно зависит от цен на электроэнергию, а ожидаемая маржа намного меньше.
В-третьих, прогноз спроса на центры обработки данных и готовность владельцев платить являются выбросами для графиков использования электроэнергии. Для большинства видов использования энергия преобразуется в физический конечный продукт (такой как светодиодная лампочка), а энергоэффективность измеряется в процентах (например, светодиодная лампочка потребляет на 90% меньше энергии, чем лампа накаливания). Вычислительная мощность измеряется порядком величины, а не процентом, а выход потребляемой мощности для центров обработки данных представляет собой информацию, а не физический товар. Прорывы, которые открывают доступ к недорогим, высокоэффективным вычислениям, не обязательно снижают спрос на электроэнергию. Скорее, такие прорывы могут повысить сложность моделей, которые могут быть запущены, и они могут даже обеспечить больше вариантов использования, которые приведут к большему спросу на электроэнергию. Короче говоря, обычные эксплуатационные параметры сектора электроэнергетики могут потребовать некоторого пересмотра, прежде чем они будут применены к центрам обработки данных.
В-четвертых, инновационные решения для систем охлаждения ИТ-центров предлагают значительный потенциал экономии. Системы охлаждения после ИТ-оборудования и серверов центров обработки данных обычно потребляют больше всего энергии, что подчеркивает большую возможность для повышения эффективности. Гипермасштаберы экспериментируют с удаленными местоположениями, чтобы воспользоваться местными условиями, например, используя холодный наружный воздух для охлаждения серверных комнат, тем самым потребляя минимальное количество энергии в холодные месяцы. Кроме того, такие местоположения предлагают возможности для переработки тепла, вырабатываемого в центрах обработки данных, в системы централизованного теплоснабжения.
Архетипы центров обработки данных
Существует три типа центров обработки данных: гиперскейлеры, колокаторы и корпоративные (собственные).
Гиперскейлер (hyperscaler) относится к игроку, который предлагает крупномасштабные облачные вычислительные сервисы с возможностью быстрого масштабирования вверх или вниз. Гиперскейлеры, такие как Amazon Web Services (AWS) и Microsoft Azure, управляют обширными глобальными сетями центров обработки данных, предоставляя инфраструктуру как услугу (IaaS) и платформу как услугу (PaaS). Они управляют огромными объемами вычислительной мощности и хранилища, позволяя компаниям использовать эти ресурсы по требованию, платя только за то, что они используют. Гиперскейлеры известны своей способностью справляться с огромными рабочими нагрузками и обеспечивать бесперебойный опыт для клиентов с различными потребностями .
Поставщик услуг размещения оборудования (a colocation provider). С другой стороны, поставщик услуг размещения оборудования предлагает физическое пространство, электропитание и охлаждение в своих центрах обработки данных для размещения клиентами собственных серверов и сетевого оборудования. В отличие от гипермасштабаторов, объекты размещения оборудования не предоставляют оборудование; вместо этого они предоставляют безопасную, управляемую среду, в которой компании могут арендовать пространство и сохранять контроль над собственным оборудованием. Эта модель идеально подходит для компаний, которым требуется полный контроль над своим оборудованием, но при этом они хотят воспользоваться преимуществами профессионального центра обработки данных, такими как повышенная безопасность, надежность и подключение.
Корпоративный (собственный) центр обработки данных — это объект, которым компания владеет и управляет для размещения собственной ИТ-инфраструктуры, включая серверы, хранилища и сетевое оборудование. В отличие от гиперскейлеров или объектов размещения, где инфраструктура или пространство арендуются у третьей стороны, корпоративные центры обработки данных полностью контролируются организацией, которой они принадлежат. Эти центры обработки данных обычно располагаются на территории компании или в специальном месте за ее пределами и предназначены для удовлетворения конкретных потребностей и требований этого бизнеса.
понедельник, 4 ноября 2024 г.
Автоматизация закупок
Из статьи "Почему уход SAP не обрушил автоматизацию закупок: семь заблуждений рынка". B2B-CenterMarch 12, 2024.
Когда в России формировался рынок электронных торгов и закупок, вокруг них существовало много мифов. «Электронные тендеры долго и сложно внедрять», «без бумажных документов не обойтись». Но эти прогнозы не подтвердились!
Когда в России формировался рынок электронных торгов и закупок, вокруг них существовало много мифов. «Электронные тендеры долго и сложно внедрять», «без бумажных документов не обойтись». Но эти прогнозы не подтвердились!
Теперь о прогнозах, что без западных программ в бизнес-процессах закупок невозможно обойтись.
Компании активно переходят к сквозной автоматизации закупочного процесса и цифровыми становятся все этапы: от заявки внутреннего заказчика до поставки товара. В профессиональном сообществе появились мифы.
Миф 1. Комплексную сквозную автоматизацию умели делать только ушедшие западные вендоры
Еще недавно российские разработчики были не столь заметны на рынке, потому что не могли так громко заявлять о себе, как мировые гиганты. Между тем отечественные IT-компании за последние годы добились значительных результатов.
На рынке представлен целый ряд конкурентных отечественных решений для управления закупками. Это SRM-системы непосредственно для закупочного процесса, ERP-системы для бюджетирования и оплат, BI-системы для аналитики и отчетности, MDM-системы для управления мастер-данными.
Существуют и решения, которые охватывают сразу все этапы закупочного процесса, такие как B2B Altis, Agora, Isource.
Миф 2. В каждой компании процессы уникальны, поэтому их лучше автоматизировать своими силами
Уникальность присутствует, но лишь до определенной степени. Закупочный процесс состоит из довольно стандартных шагов. Предприятию нужно спланировать закупку, согласовать, найти поставщиков и аккредитовать их, провести торги, выбрать победителя, заключить договор, отследить факт поставки. Эти шаги могут различаться в деталях, но сам процесс у всех будет выглядеть примерно одинаково.
Оптимальная стратегия - не пытаться создать собственный инструмент с нуля, а найти уже существующий, который охватывает все этапы закупок. И настроить существующее IT- решение под свои индивидуальные задачи.
Миф 3. Автоматизировать надо сразу весь закупочный контур
Многие компании полагают, что нужно внедрить единую монолитную IT-систему, которая сразу охватит все этапы закупочного процесса. Это сложная и трудоемкая работа, особенно для крупного предприятия с большим количеством филиалов.
Альтернативный подход основан на модульной архитектуре IT- решения. В отличие от монолита, он позволяет начать с автоматизации одного-двух этапов, постепенно охватывая весь закупочный процесс.
Важно провести анализ закупок, чтобы понять, где в компании наиболее остро ощущаются сложности. Это может быть автоматизация малых закупок, поиска поставщиков или контрактов. Благодаря модульной структуре можно в короткие сроки запустить пилотный проект, устранить узкие места и при минимальных затратах получить наибольший эффект.
Миф 4. Необходимо на старте проекта предусмотреть все нюансы бизнес-процессов
Почти всегда задача на входе значительно отличается от результата на выходе. Когда автоматизируется сложный процесс, невозможно все изначально продумать. Иначе можно изобрести запутанную систему, которая на практике просто не будет работать.
Избежать такой ситуации помогает гибкий подход. В продукт непрерывно шаг за шагом вносятся улучшения: сделали, проверили, доработали, начали следующий этап. Благодаря чему сохраняется устойчивость, появляется возможность уточнять бизнес-требования в процессе разработки.
Миф 5. Комплексная автоматизация требует гигантских бюджетов и длительных сроков внедрения
Бюджет всегда зависит от контура проекта. Зачастую в компаниях уже внедрено несколько разрозненных систем, и возникла так называемая лоскутная автоматизация. Для начала стоит объединить несколько этапов в единый контур, например, выстроить процесс от закупки до оплаты (procure-to-pay). Такой подход поможет при меньших затратах сразу получить эффект от автоматизации. И в перспективе охватить уже весь сквозной процесс.
Сроки также гибко варьируются в зависимости от того, какой модуль внедряется. Если компания хочет автоматизировать сорсинг поставщиков на базе электронной торговой площадки, то потребуется один-три месяца. После чего достаточно быстро можно настроить контрактный модуль, так как информация о контрагентах и результатах торгов уже автоматически собирается в системе.
Миф 6. Проекты по автоматизации всегда содержат излишнюю функциональность
Коробочные монолитные решения могут содержать излишнюю функциональность. Но на рынке представлены различные платформы, которые можно настраивать под специфику каждой компании. Таким образом, компания может подключить только ту функциональность, которую она будет фактически использовать.
Миф 7. В первую очередь нужно автоматизировать сложные процессы
Многие предприятия начинают со стратегически важных процессов, забывая о низкостоимостных закупках. При этом обслуживание таких закупок требует значительных ресурсов. Их цифровизация на базе корпоративного интернет-магазина дает возможность до 30% сократить транзакционные издержки.
В корпоративном магазине пул партнеров формируется заранее закупщиком. Покупки в системе осуществляют непосредственно заказчики продукции из профильных департаментов с учетом выделенных им финансовых лимитов. За счет такого самообслуживания повышаются персональная ответственность и осознанность заказчиков, снижается число претензий к качеству закупаемых товаров. Упрощаются процесс взаимодействия с поставщиками и документооборот, сокращаются складские запасы. Отдел закупок освобождается от большого количества рутинных задач и может сосредоточиться на более сложных стратегических категориях товаров и услуг.
Отечественные IT-решения для закупок доказали, что способны заменить продукты зарубежных вендоров. Они гибко настраиваются, учитывают особенности разных компаний и их закупочных систем, а внедрение не требует больших бюджетов и может проводиться в сжатые сроки.
Источник.
Автор: Бойко Андрей, коммерческий директор B2B-Center
https://telegra.ph/Pochemu-uhod-SAP-ne-obrushil-avtomatizaciyu-zakupok-sem-zabluzhdenij-rynka-03-12
Компании активно переходят к сквозной автоматизации закупочного процесса и цифровыми становятся все этапы: от заявки внутреннего заказчика до поставки товара. В профессиональном сообществе появились мифы.
Миф 1. Комплексную сквозную автоматизацию умели делать только ушедшие западные вендоры
Еще недавно российские разработчики были не столь заметны на рынке, потому что не могли так громко заявлять о себе, как мировые гиганты. Между тем отечественные IT-компании за последние годы добились значительных результатов.
На рынке представлен целый ряд конкурентных отечественных решений для управления закупками. Это SRM-системы непосредственно для закупочного процесса, ERP-системы для бюджетирования и оплат, BI-системы для аналитики и отчетности, MDM-системы для управления мастер-данными.
Существуют и решения, которые охватывают сразу все этапы закупочного процесса, такие как B2B Altis, Agora, Isource.
Миф 2. В каждой компании процессы уникальны, поэтому их лучше автоматизировать своими силами
Уникальность присутствует, но лишь до определенной степени. Закупочный процесс состоит из довольно стандартных шагов. Предприятию нужно спланировать закупку, согласовать, найти поставщиков и аккредитовать их, провести торги, выбрать победителя, заключить договор, отследить факт поставки. Эти шаги могут различаться в деталях, но сам процесс у всех будет выглядеть примерно одинаково.
Оптимальная стратегия - не пытаться создать собственный инструмент с нуля, а найти уже существующий, который охватывает все этапы закупок. И настроить существующее IT- решение под свои индивидуальные задачи.
Миф 3. Автоматизировать надо сразу весь закупочный контур
Многие компании полагают, что нужно внедрить единую монолитную IT-систему, которая сразу охватит все этапы закупочного процесса. Это сложная и трудоемкая работа, особенно для крупного предприятия с большим количеством филиалов.
Альтернативный подход основан на модульной архитектуре IT- решения. В отличие от монолита, он позволяет начать с автоматизации одного-двух этапов, постепенно охватывая весь закупочный процесс.
Важно провести анализ закупок, чтобы понять, где в компании наиболее остро ощущаются сложности. Это может быть автоматизация малых закупок, поиска поставщиков или контрактов. Благодаря модульной структуре можно в короткие сроки запустить пилотный проект, устранить узкие места и при минимальных затратах получить наибольший эффект.
Миф 4. Необходимо на старте проекта предусмотреть все нюансы бизнес-процессов
Почти всегда задача на входе значительно отличается от результата на выходе. Когда автоматизируется сложный процесс, невозможно все изначально продумать. Иначе можно изобрести запутанную систему, которая на практике просто не будет работать.
Избежать такой ситуации помогает гибкий подход. В продукт непрерывно шаг за шагом вносятся улучшения: сделали, проверили, доработали, начали следующий этап. Благодаря чему сохраняется устойчивость, появляется возможность уточнять бизнес-требования в процессе разработки.
Миф 5. Комплексная автоматизация требует гигантских бюджетов и длительных сроков внедрения
Бюджет всегда зависит от контура проекта. Зачастую в компаниях уже внедрено несколько разрозненных систем, и возникла так называемая лоскутная автоматизация. Для начала стоит объединить несколько этапов в единый контур, например, выстроить процесс от закупки до оплаты (procure-to-pay). Такой подход поможет при меньших затратах сразу получить эффект от автоматизации. И в перспективе охватить уже весь сквозной процесс.
Сроки также гибко варьируются в зависимости от того, какой модуль внедряется. Если компания хочет автоматизировать сорсинг поставщиков на базе электронной торговой площадки, то потребуется один-три месяца. После чего достаточно быстро можно настроить контрактный модуль, так как информация о контрагентах и результатах торгов уже автоматически собирается в системе.
Миф 6. Проекты по автоматизации всегда содержат излишнюю функциональность
Коробочные монолитные решения могут содержать излишнюю функциональность. Но на рынке представлены различные платформы, которые можно настраивать под специфику каждой компании. Таким образом, компания может подключить только ту функциональность, которую она будет фактически использовать.
Миф 7. В первую очередь нужно автоматизировать сложные процессы
Многие предприятия начинают со стратегически важных процессов, забывая о низкостоимостных закупках. При этом обслуживание таких закупок требует значительных ресурсов. Их цифровизация на базе корпоративного интернет-магазина дает возможность до 30% сократить транзакционные издержки.
В корпоративном магазине пул партнеров формируется заранее закупщиком. Покупки в системе осуществляют непосредственно заказчики продукции из профильных департаментов с учетом выделенных им финансовых лимитов. За счет такого самообслуживания повышаются персональная ответственность и осознанность заказчиков, снижается число претензий к качеству закупаемых товаров. Упрощаются процесс взаимодействия с поставщиками и документооборот, сокращаются складские запасы. Отдел закупок освобождается от большого количества рутинных задач и может сосредоточиться на более сложных стратегических категориях товаров и услуг.
Отечественные IT-решения для закупок доказали, что способны заменить продукты зарубежных вендоров. Они гибко настраиваются, учитывают особенности разных компаний и их закупочных систем, а внедрение не требует больших бюджетов и может проводиться в сжатые сроки.
Источник.
Автор: Бойко Андрей, коммерческий директор B2B-Center
https://telegra.ph/Pochemu-uhod-SAP-ne-obrushil-avtomatizaciyu-zakupok-sem-zabluzhdenij-rynka-03-12
воскресенье, 15 сентября 2024 г.
Дела в индустрии ПО: сокращение роста и увеличение маржи
Предисловие. У них просто нет импортозамещения.
Как дела на рынке ПО в северной америке.
Однако в последние годы индустрия программного обеспечения столкнулась с серьезными препятствиями, поскольку предприятия замедлили свои расходы на ИТ. Это замедление инвестиций в технологии привело к замедлению роста компаний-разработчиков программного обеспечения. В то же время рост процентных ставок означал, что клиенты программного обеспечения столкнулись с растущими препятствиями в виде денежных потоков, что усилило давление, заставляющее сокращать расходы на программное обеспечение. В результате оценки программного обеспечения испытали существенное многократное сжатие, и рост эффективности значительно снизилсь, упав примерно на 50% в период с 2021 по 2023 год. Некоторые сигналы в первой половине 2024 года указывают на то, что эта тенденция может сохраниться.
В 2022 и 2023 годах компании-разработчики программного обеспечения столкнулись с серьезными препятствиями, поскольку глобальные расходы на ИТ замедлились. В США темпы роста расходов на ИТ сократились до 5,7% в период с 2022 по 2023 год, что примерно вдвое меньше, чем в период с 2020 по 2022 год (согласно анализу McKinsey). Финансовые руководители призвали руководителей ИТ-подразделений сократить расходы на программные инструменты на целых 30% в 2023 году.
Хотя компании-разработчики ПО продолжали инвестировать в рост, они были заметно менее эффективны в получении новых доходов. Эффективность роста компаний-разработчиков программного обеспечения снизилась вдвое с 2021 по 2023 год.
Внимание - марже
Многие компании-разработчики ПО отклонились от траекторий роста, перейдя от мышления «рост любой ценой» к мышлению, основанному на марже. В то время как компании в верхнем квартиле по оценочным мультипликаторам ранее достигли превосходных результатов за счет более высокого роста выручки, в 2022 и 2023 годах они сосредоточились на улучшении маржи свободного денежного потока (FCF). С 2018 по 2021 год маржа FCF для компаний верхнего квартиля и медианного6находились в диапазоне двух процентных пунктов. Однако в 2022 и 2023 годах компании с оценочными мультипликаторами верхнего квартиля достигли в среднем на шесть-восемь процентных пунктов более высокой маржи FCF, чем медианные компании. Фактически, компании-разработчики программного обеспечения верхнего квартиля более чем удвоили свою маржу в период с 2018 по 2023 год. Рынки вознаградили игроков, которые сосредоточились на марже, которая была более существенным фактором, отличающим компании верхнего квартиля от медианных, чем рост в 2023 году.
Возобновление акцента на эффективном росте может позволить компаниям-разработчикам ПО высвободить 500 миллиардов долларов дополнительной акционерной стоимости.
На фоне этих упадочных показателей успешные игроки рынка программного обеспечения, подстегиваемые инвесторами, стремились сохранить стоимость, обратившись к рычагу, который находился под их полным контролем - марже. Хотя лидеры отрасли, по понятным причинам, хотели защитить стоимость бизнеса, приоритет маржи за счет роста привел к тому, что часть стоимости осталась за бортом. А именно, на карту может быть поставлено до 500 миллиардов долларов дополнительной стоимости предприятия. И это случилось в силу того, что поворот к марже оказался чрезмерной коррекцией. Путь вперед лежит в подходе «эффективного роста»: подходе, который стремится к максимальному росту наряду со достаточной маржой.
Многие компании-разработчики ПО отклонились от траекторий роста, перейдя от мышления «рост любой ценой» к мышлению, основанному на марже. В то время как компании в верхнем квартиле по оценочным мультипликаторам ранее достигли превосходных результатов за счет более высокого роста выручки, в 2022 и 2023 годах они сосредоточились на улучшении маржи свободного денежного потока (FCF). С 2018 по 2021 год маржа FCF для компаний верхнего квартиля и медианного6находились в диапазоне двух процентных пунктов. Однако в 2022 и 2023 годах компании с оценочными мультипликаторами верхнего квартиля достигли в среднем на шесть-восемь процентных пунктов более высокой маржи FCF, чем медианные компании. Фактически, компании-разработчики программного обеспечения верхнего квартиля более чем удвоили свою маржу в период с 2018 по 2023 год. Рынки вознаградили игроков, которые сосредоточились на марже, которая была более существенным фактором, отличающим компании верхнего квартиля от медианных, чем рост в 2023 году.
Возобновление акцента на эффективном росте может позволить компаниям-разработчикам ПО высвободить 500 миллиардов долларов дополнительной акционерной стоимости.
На фоне этих упадочных показателей успешные игроки рынка программного обеспечения, подстегиваемые инвесторами, стремились сохранить стоимость, обратившись к рычагу, который находился под их полным контролем - марже. Хотя лидеры отрасли, по понятным причинам, хотели защитить стоимость бизнеса, приоритет маржи за счет роста привел к тому, что часть стоимости осталась за бортом. А именно, на карту может быть поставлено до 500 миллиардов долларов дополнительной стоимости предприятия. И это случилось в силу того, что поворот к марже оказался чрезмерной коррекцией. Путь вперед лежит в подходе «эффективного роста»: подходе, который стремится к максимальному росту наряду со достаточной маржой.
Теория стоимости бизнеса предполагает, что существует оптимальный баланс между маржой и ростом для каждой компании. В качестве примера, для типичной компании-разработчика ПО идеальное соотношение роста и маржи составляет примерно 2,1–1,2 раза. Этот баланс со временем позволяет компании максимизировать свою долгосрочную стоимость. Однако оптимальное соотношение между ростом и маржой FCF различно для компаний-разработчиков ПО, поскольку оно зависит от бизнес-среды и индивидуальных обстоятельств. Правильный баланс может иметь решающее значение.
Например, типичная компания-разработчик ПО с доходом в 1 млрд долларов и эффективностью роста 0,4 будет генерировать наибольшую долгосрочную ценность при коэффициенте роста к марже 0,8, то есть 22 процента маржи FCF и 18 процентов роста. Та же компания при эффективности роста 0,7 максимизирует долгосрочную ценность при коэффициенте роста к марже 2,1, или 13 процентов маржи FCF и 27 процентов роста. Компании на бурно развивающимся рынке будут испытывать более высокую эффективность роста, а их порог оптимальной маржи будет ниже. Обратное также верно: компании с ограниченным запасом роста будут иметь более низкую эффективность роста, а порог оптимальной маржи должен увеличиться. Другими словами, эффективность роста — это не статическое число. Существует множество рычагов, которые игроки могут использовать для повышения эффективности роста и раскрытия рентабельности инвестиций в росте, среди которых — обновленные стратегии ценообразования , практики, ориентированные на продуктах, сокращение циклов продаж, более релевантные возможности вертикальных продаж, а также многое другое.
Используя формулу эффективного ростоа McKinsey нашла, что если бы все 116 компаний-разработчиков ПО следовали эффективной формуле роста в 2022 и 2023 годах, они теоретически могли бы получить 500 миллиардов долларов дополнительной стоимости.
Стратегии повышения стоимости в 2024 и 2025 годах
Исследование McKinsey аналитических прогнозов стоимости акций предполагает, что большинство компаний-разработчиков ПО сохранят курс, увеличивая маржу и недостаточно инвестируя в рост в 2024 и 2025 годах. То есть, это приведет к потере дополнительной стоимости бизнеса.
На основе формулы эффективного роста каждой компании мы обнаруживаем, что для создания устойчивой ценности 46% компаний-разработчиков ПО должны инвестировать в рост в 2024 году, в то время как только 34% должны пытаться увеличить маржу. Тем не менее, по прогнозам аналитиков, только 19% компаний-разработчиков РО будут инвестировать в рост в 2024 и 2025 годах, при этом самая большая группа компаний (64%) по-прежнему нацелена на увеличение маржи FCF.
Источник
How efficient growth can fuel enduring value creation in software. July 29, 2024. Article. This article is a collaborative effort by Chandra Gnanasambandam, Jeremy Schneider, and Suren Arutyunyan, with Martin Milenovsky and Sebastian Sinisterra-Woods, representing views from McKinsey’s Technology, Media & Telecommunications Practice.
https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/how-efficient-growth-can-fuel-enduring-value-creation-in-software
Источник
How efficient growth can fuel enduring value creation in software. July 29, 2024. Article. This article is a collaborative effort by Chandra Gnanasambandam, Jeremy Schneider, and Suren Arutyunyan, with Martin Milenovsky and Sebastian Sinisterra-Woods, representing views from McKinsey’s Technology, Media & Telecommunications Practice.
https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/how-efficient-growth-can-fuel-enduring-value-creation-in-software
четверг, 22 августа 2024 г.
Индекс операционной модели - OMI
МакКинзи разработал индекс индекс операционной модели (OMI), который представляет собой средневзвешенный балл производительности по пяти основным областям операционной модели продукта и платформы (структура, стратегия и управление, способы работы, культура и талант, а также инструментарий) и 17 измерениям.
10. PDLC-RACI, модель взаимодействия (Product development life cycle - Responsible, Accountable, Consulted and Informed model, Жизненный цикл разработки продукта - Ответственная, подотчетная, консультируемая и информированная модель). r около 0,53.
Графически эта модель выглдяти следующим образом и ниже представлен текстовый список.
С помощью этой модели МакКинзи оцениваются характеристики модели с помощью стандартизированного набора вопросов. Это позволяет классифицировать ответы с точки зрения оценки уровня зрелости. Например, зрелость по области «структура» определяется как организация, имеющая четко определенную таксономию продукта и платформы, кросс-функционально собранные и постоянные команды, созданные с правильным соотношением ролей, и сквозное владение для обеспечения меньшего количества передач между командами.
С помощью этой модели МакКинзи оцениваются характеристики модели с помощью стандартизированного набора вопросов. Это позволяет классифицировать ответы с точки зрения оценки уровня зрелости. Например, зрелость по области «структура» определяется как организация, имеющая четко определенную таксономию продукта и платформы, кросс-функционально собранные и постоянные команды, созданные с правильным соотношением ролей, и сквозное владение для обеспечения меньшего количества передач между командами.
Operating Model Index (OMI) - взвешенная оценка производительности в 5 областях и 17 измерениях
Структура
1. Таксономия продукта и платформы/ проектирование
2. Организационный дизайн
3. Проектирование модулей продукта и платформы
4. Стратегия локализации
Стратегия и управление
5. Портфельное планирование
6. Постановка целей и расстановка приоритетов
7. Финансирование и бюджетирование
8. Подотчетность и производительность
Способы работы
9. кросс-продуктовая и платформенная зависимость
10. PDLC-RACI, модель взаимодействия (Product development life cycle - Responsible, Accountable, Consulted and Informed model, Жизненный цикл разработки продукта - Ответственная, подотчетная, консультируемая и информированная модель).
11. Современное управление продуктом и инженерными практиками
Культура и управление персоналом
12. Культурные изменения
13. Управление талантами
14. Повышение квалификации/развитие потенциала
Оснащение инструментами. Оснастка
15. Оснастка планирование и сотрудничество
16. Инструменты разработчика
17. Инструменты DevSecOps
Примечание. DevSecOps — это практика интеграции тестирования безопасности на каждом этапе процесса разработки ПО. Она включает в себя инструменты и процессы, которые поощряют сотрудничество между разработчиками, специалистами по безопасности и операционными группами для создания ПО, которое является одновременно эффективным и безопасным.
McKensey опросили старших руководителей (включая высшее руководство, вице-президентов по продуктам и инжинирингу и т. д.) из более чем 400 публичных компаний по всему миру и из разных секторов для построения как индекса OMI так и корреляций.
Структура
1. Таксономия продукта и платформы/ проектирование
- Таксономия
2. Организационный дизайн
- Выравнивание команды
- Степень параллезма
3. Проектирование модулей продукта и платформы
- Постоянные команды
- Взаимозаменяемость ресурсов
- Соотношение ролей
4. Стратегия локализации
- Совместное размещение команды
- Совместное размещение зависимой команды
Стратегия и управление
5. Портфельное планирование
- Распределение сверху вниз
- Управление технологическим долгом
- Циклы планирования и обзора
6. Постановка целей и расстановка приоритетов
- Зрелость целей и ключевых результатов
- Приоритизация отставания (backlog)
7. Финансирование и бюджетирование
- Финансирование подразделения
- Процесс финансирования
8. Подотчетность и производительность
- Структура подотчетности
Способы работы
9. кросс-продуктовая и платформенная зависимость
- Автономная доставка
- Управление зависимостями
- Разрешение зависимости
10. PDLC-RACI, модель взаимодействия (Product development life cycle - Responsible, Accountable, Consulted and Informed model, Жизненный цикл разработки продукта - Ответственная, подотчетная, консультируемая и информированная модель).
- R&R, Roles and responsibilities. Прозрачность - Роли и ответственность
- Прозрачность команды
- PDLC
- Модель взаимодействия
11. Современное управление продуктом и инженерными практиками
- Инженерные практики
- Запуск производства
- Практики управления продуктом
- Согласование в управлении продуктом
Культура и управление персоналом
12. Культурные изменения
- Культурная жизнеспособность
13. Управление талантами
- Подбор менеджеров по управлению проектами и инженеров
14. Повышение квалификации/развитие потенциала
- Повышение квалификации менеджеров по управлению проектами
- Повышение квалификации инженеров
Оснащение инструментами. Оснастка
15. Оснастка планирование и сотрудничество
- Планирование и сотрудничество
16. Инструменты разработчика
- Разработка программного обеспечения
17. Инструменты DevSecOps
- Мониторинг CI/CD
- CI/CD (continuous integration/continuous delivery) непрерывная интеграция/непрерывная поставка
Примечание. DevSecOps — это практика интеграции тестирования безопасности на каждом этапе процесса разработки ПО. Она включает в себя инструменты и процессы, которые поощряют сотрудничество между разработчиками, специалистами по безопасности и операционными группами для создания ПО, которое является одновременно эффективным и безопасным.
Коэффициент корреляции (r) оценивался на выборке 400+. Корреляция между индексом OMI и общим бизнес-результатом.
Способы работы. Максимальный коффицен r=0.60.
9. кросс-продуктовая и платформенная зависимость. r около 0,52.
11. Современное управление продуктом и инженерными практиками. r около 0,51.
Культура и управление персоналом. Максимальный коффицен r=0.58.
12. Культурные изменения. r около 0,52.
13. Управление талантами. r=0.5
14. Повышение квалификации/развитие потенциал. r около 0,46.
Стратегия и управление. Максимальный коффицен r=0.53.
6. Постановка целей и расстановка приоритетов. r около 0,44.
7. Финансирование и бюджетирование. r около 0,43.
5. Портфельное планирование. r около 0,43.
8. Подотчетность и производительность/ r=0.4
Оснащение инструментами. Оснастка. Максимальный коффицен r=0.50.
15. Оснастка планирование и сотрудничество. r около 0,49.
17. Инструменты DevSecOps. r около 0,45.
16. Инструменты разработчика. r около 0,42.
Структура. Максимальный коффицен r=0.46.
2. Организационный дизайн. r=0.4
1. Таксономия продукта и платформы/ проектирование. r около 0,33.
3. Проектирование модулей продукта и платформы. r около 0,31.
4. Стратегия локализации/ r=0.2
Далее - графика, котороя отображает корреляцию между 5 областями и бизнес-результатами (по горизонтали): общий бизнес-результат, удовлетворенность пользователей, известность бренда и инновации.
Картинка ожидаемае и ничего неожиданного. Например, на инновации сильно влияет инструментарий и квалификация.
понедельник, 15 июля 2024 г.
7 вариантов BI-платформы
Из заметки "На замену SAP: какую отечественную BI- платформу выбрать — 7 вариантов". IT-Expert, March 15, 2024
№ 7. Polymatica
В целом Polymatica использует простой и понятный интерфейс, требуя минимума знаний для базовой работы с платформой. На начало 2024 года BI от Polymatica внедряют более 60 системных интеграторов. Собственное хранилище может быть реализовано на базе ClickHouse или PostgreSQL, а коннекторы уже разработаны для большинства популярных СУБД и корпоративных платформ.
Специалисты отмечают ограниченную функциональность дашбордов, а также небольшие возможности встроенного в систему инструмента для загрузки данных (ETL).
№ 6. Modus BI
Платформа Modus BI представляет собой удобное решение для аналитики и визуализации на базе готовых компонентов и шаблонов и содержит достаточно удобный конструктор, в котором пользователи могут «накликать» нужные им дашборды. Modus BI позволяет достаточно быстро создать несложные визуализации. Наличие собственной системы ETL с возможностью подключения к большинству популярных СУБД и источников данных.
Нужно учитывать, что широкий функционал системы не всегда интуитивно понятен и для успешной работы с «Форсайтом» требуется тщательное изучение документации и глубокое погружение в платформу, которое предполагает наличие ресурсов и времени.
№ 1. Аналитическая платформа Visiology
Предусмотрено использование нового аналитического движка ViQube 2, у которого «под капотом» лежит СУБД ClickHouse с автоматической оптимизацией схемы размещения данных и методов обработки запросов. Это позволяет избежать создания дополнительного аналитического хранилища и показывает высокую производительность. Достаточно простой собственный ETL-инструмент ViXtract, который является OpenSource-проектом. Открытый интерфейс позволяет использовать для больших проектов промышленный ETL, такой как Apache Airflow, или коммерческий инструмент, например Loginom. Модуль Smart Forms, способный автоматизировать ручной ввод при помощи веб-форм, а также загружать готовые документы Excel, моментально перенося их на ВI-платформу с отражением на реальных дашбордах. Поддержка DAX в том же виде, как он работает в Microsoft Power BI, возможность визуального конструирования модели данных, виртуального помощника ViTalkGPT с искусственным интеллектом и наличие средств интеграции дашбордов в порталы и приложения.
Источник.
https://telegra.ph/Na-zamenu-SAP-kakuyu-otechestvennuyu-BI--platformu-vybrat---7-variantov-03-15
№ 7. Polymatica
В целом Polymatica использует простой и понятный интерфейс, требуя минимума знаний для базовой работы с платформой. На начало 2024 года BI от Polymatica внедряют более 60 системных интеграторов. Собственное хранилище может быть реализовано на базе ClickHouse или PostgreSQL, а коннекторы уже разработаны для большинства популярных СУБД и корпоративных платформ.
Специалисты отмечают ограниченную функциональность дашбордов, а также небольшие возможности встроенного в систему инструмента для загрузки данных (ETL).
№ 6. Modus BI
Платформа Modus BI представляет собой удобное решение для аналитики и визуализации на базе готовых компонентов и шаблонов и содержит достаточно удобный конструктор, в котором пользователи могут «накликать» нужные им дашборды. Modus BI позволяет достаточно быстро создать несложные визуализации. Наличие собственной системы ETL с возможностью подключения к большинству популярных СУБД и источников данных.
Отсутствие возможности глубоко кастомизировать визуальные представления. Фактически пользователь ограничен настройкой стилей.
№ 5. Luxms BI
Разработчики платформы активно вкладываются во внедрение технологий AI/ML для глубокой аналитики данных, а также занимаются развитием собственного метаязыка LPE (аналог DAX). В Luxms реализована поддержка файлов Qlik (QVD), разработаны коннекторы к SAP. В отличие от многих других решений, Luxms одновременно предлагает как Self-Service- элементы для сборки простых дашбордов, так и возможности дополнительной разработки и глубокой кастомизации платформы под нужды конкретных пользователей с опорой на практики CI/CD. В составе платформы есть свой достаточно развитый ETL-инструмент Luxms Data Boring. У Luxms BI открытая архитектура. Она позволяет кластеризовать и масштабировать решение.
№ 5. Luxms BI
Разработчики платформы активно вкладываются во внедрение технологий AI/ML для глубокой аналитики данных, а также занимаются развитием собственного метаязыка LPE (аналог DAX). В Luxms реализована поддержка файлов Qlik (QVD), разработаны коннекторы к SAP. В отличие от многих других решений, Luxms одновременно предлагает как Self-Service- элементы для сборки простых дашбордов, так и возможности дополнительной разработки и глубокой кастомизации платформы под нужды конкретных пользователей с опорой на практики CI/CD. В составе платформы есть свой достаточно развитый ETL-инструмент Luxms Data Boring. У Luxms BI открытая архитектура. Она позволяет кластеризовать и масштабировать решение.
Специалисты отмечают недостаточно проработанную документацию по платформе в целом, а также сложности в настройке представлений, аналитических элементов и кастомизации витрин данных.
№ 4. Insight BI
Конструктор для разработки, встроенные библиотеки шаблонов и маркетплейс готовых решений, собранных на портале разработчика Insight Visual Studio. Также в составе платформы имеется Insight Data Platform, обеспечивающая подключение к различным СУБД и информационным системам, сбор и обработку данных.
№ 4. Insight BI
Конструктор для разработки, встроенные библиотеки шаблонов и маркетплейс готовых решений, собранных на портале разработчика Insight Visual Studio. Также в составе платформы имеется Insight Data Platform, обеспечивающая подключение к различным СУБД и информационным системам, сбор и обработку данных.
Insight предлагает обширные настройки визуализаций, но они могут оказаться слишком сложными для простых пользователей. Также отсутствует визуальный редактор для сложных формул, а потому для более глубокой работы с платформой нужно будет проходить дополнительную подготовку.
№ 3. Analytic Workspace
Разработчик - ОСТ - делает ставку на точечное решение задачи BI. В последнее время проекты AW отличаются встраиванием в готовые экосистемы, и это разумный подход для тех организаций, перед которыми стоит задача замены ставшего недоступным западного ПО. B AW BI имеется свой блок ETL, построенный с использованием Аpache Spark и Аpache Airflow. Он реализует базовые операции преобразования и объединения данных. Для продвинутых преобразований доступны SQL и Python.
Система визуализации в AW простая и интуитивная, но только пока вам не нужно получить какую-то особенную кастомизацию.
Разработчик - ОСТ - делает ставку на точечное решение задачи BI. В последнее время проекты AW отличаются встраиванием в готовые экосистемы, и это разумный подход для тех организаций, перед которыми стоит задача замены ставшего недоступным западного ПО. B AW BI имеется свой блок ETL, построенный с использованием Аpache Spark и Аpache Airflow. Он реализует базовые операции преобразования и объединения данных. Для продвинутых преобразований доступны SQL и Python.
Система визуализации в AW простая и интуитивная, но только пока вам не нужно получить какую-то особенную кастомизацию.
№ 2. Аналитическая платформа «Форсайт»
Платформа «Форсайт» подкупает большим арсеналом решений, который позволяет эффективно решать сложные задачи. Так, в портфеле вендора имеется как «тяжелая артиллерия» в виде BI- системы «Форсайт. Аналитическая платформа» (ФАП), так и облегченная FLY BI для более простых задач. Вместе с ФАП заказчики получают инструментарий классической и продвинутой аналитики, а также средства управления бизнес- процессами (ВРМ), которые позволяют не только заниматься аналитикой, но и разрабатывать бизнес-приложения. Платформа уже содержит все инструменты для сбора, обработки, мониторинга и анализа данных. Имеются инструменты предиктивной аналитики, а также встроенные системы ИИ, работы с большими данными и построения прогнозных и оптимизационных моделей. Экосистему дополняют продукты «Форсайт. Управление инвестициями», «Форсайт. Бюджетирование», «Форсайт. Сводная отчетность», «Форсайт. Кредитный конвейер», «Форсайт. Мобильная платформа».
Платформа «Форсайт» подкупает большим арсеналом решений, который позволяет эффективно решать сложные задачи. Так, в портфеле вендора имеется как «тяжелая артиллерия» в виде BI- системы «Форсайт. Аналитическая платформа» (ФАП), так и облегченная FLY BI для более простых задач. Вместе с ФАП заказчики получают инструментарий классической и продвинутой аналитики, а также средства управления бизнес- процессами (ВРМ), которые позволяют не только заниматься аналитикой, но и разрабатывать бизнес-приложения. Платформа уже содержит все инструменты для сбора, обработки, мониторинга и анализа данных. Имеются инструменты предиктивной аналитики, а также встроенные системы ИИ, работы с большими данными и построения прогнозных и оптимизационных моделей. Экосистему дополняют продукты «Форсайт. Управление инвестициями», «Форсайт. Бюджетирование», «Форсайт. Сводная отчетность», «Форсайт. Кредитный конвейер», «Форсайт. Мобильная платформа».
Нужно учитывать, что широкий функционал системы не всегда интуитивно понятен и для успешной работы с «Форсайтом» требуется тщательное изучение документации и глубокое погружение в платформу, которое предполагает наличие ресурсов и времени.
№ 1. Аналитическая платформа Visiology
Предусмотрено использование нового аналитического движка ViQube 2, у которого «под капотом» лежит СУБД ClickHouse с автоматической оптимизацией схемы размещения данных и методов обработки запросов. Это позволяет избежать создания дополнительного аналитического хранилища и показывает высокую производительность. Достаточно простой собственный ETL-инструмент ViXtract, который является OpenSource-проектом. Открытый интерфейс позволяет использовать для больших проектов промышленный ETL, такой как Apache Airflow, или коммерческий инструмент, например Loginom. Модуль Smart Forms, способный автоматизировать ручной ввод при помощи веб-форм, а также загружать готовые документы Excel, моментально перенося их на ВI-платформу с отражением на реальных дашбордах. Поддержка DAX в том же виде, как он работает в Microsoft Power BI, возможность визуального конструирования модели данных, виртуального помощника ViTalkGPT с искусственным интеллектом и наличие средств интеграции дашбордов в порталы и приложения.
Источник.
https://telegra.ph/Na-zamenu-SAP-kakuyu-otechestvennuyu-BI--platformu-vybrat---7-variantov-03-15
* * *
Вертикально-интегрированная горно-металлургическая компания "Северсталь" строит платформу для хранения и анализа данных, основанную на стеке продуктов группы Arenadata.
Совместное решение станет полноценной заменой хранилища данных на базе SAP BW с процессами моделирования объектов, переноса объектов между системами, ведением ETL процессов, работой с данными.
Для решения задачи был выбран стек продуктов Arenadata: СУБД Arenadata DB, Arenadata QuickMarts для хранения и обработки данных на разных уровнях хранилища; система Arenadata Streaming для потоковой обработки данных в режиме реального времени; Arenadata Catalog для управления информационными активами компании и ведения корпоративного бизнес-глоссария в едином интерфейсе.
В перспективе альтернативное хранилище данных станет единым источником правды для нескольких компаний "Севергрупп", агрегирующим в себе потоки данных по 15 функциональным областям, включая производство, финансы, контроллинг, казначейство, инвестиции, закупки.
https://www.comnews.ru/digital-economy/content/234283/2024-07-11/2024-w28/1012/severstal-stroit-khranilische-dannykh-steke-produktov-arenadata
среда, 17 апреля 2024 г.
Управление домами
О платформе управления «умными домами». Ujin – реализуется компанией «Юникорн» по заказу группы компаний (ГК) «Самолет». На его развитие Российский фонд развития информационных технологий (РФРИТ) выделил грант в размере 258 млн руб.
Изначально проект начинался как мобильное приложение для жителей многоквартирных домов для решения их бытовых проблем. Впоследствии проект трансформировался в платформу для управления «умными зданиями». Важным этапом стала интеграция с управляющими компаниями и создание для них личного кабинета.
Платформой пользуются девелоперы, управляющие организации, органы муниципальной и федеральной власти, надзорные органы, сервисные компании, резиденты и посетители зданий, ресурсоснабжающие организации.
В рамках доработки проекта предполагается обеспечить возможность для сторонних разработчиков создавать на базе Ujin OS собственные модули интеграции и сервисы для пользователей. Должны быть создана библиотека «драйверов» для подключения оборудования и ПО различных производителей, пополняемая всеми участниками рынка, и открытое SDK для быстрой разработки пользовательских приложений - цифровых сервисов. Сервисы должны быть автоматически доступны на различных публичных поверхностях зданий и приватных устройствах, используемых людьми для взаимодействия со зданием.
Также запланирована разработка интеграционной шины, позволяющая сторонним разработчикам подключать интеграционные модули, изменять существующие и добавлять новые сервисы. Запланирована разработка API и SDK для работы с интеграционной шиной и реализация доступа к структурированной обновляемой документации, а также разработка системы, позволяющей встраивать стороннюю функциональность в приложения Ujin Apps
Кроме того, запланировано: доработка функций виртуальной диспетчерской (виртуализация принципов организации связей, параметров, состояний, расположений оборудования в составе инженерных систем зданий); интеграция с BIM –моделями зданий; создание «электронного двойника» здания; разработка персонального ассистента и развитие B2C сервисов Ujin; таргетирование с учетом портрета клиента цифровыми сервисами; разработка маркета B2B и B2C сервисов; автоматизация процессов подключения сервисов и биллинга услуг.
Источник.
Изначально проект начинался как мобильное приложение для жителей многоквартирных домов для решения их бытовых проблем. Впоследствии проект трансформировался в платформу для управления «умными зданиями». Важным этапом стала интеграция с управляющими компаниями и создание для них личного кабинета.
Платформой пользуются девелоперы, управляющие организации, органы муниципальной и федеральной власти, надзорные органы, сервисные компании, резиденты и посетители зданий, ресурсоснабжающие организации.
В рамках доработки проекта предполагается обеспечить возможность для сторонних разработчиков создавать на базе Ujin OS собственные модули интеграции и сервисы для пользователей. Должны быть создана библиотека «драйверов» для подключения оборудования и ПО различных производителей, пополняемая всеми участниками рынка, и открытое SDK для быстрой разработки пользовательских приложений - цифровых сервисов. Сервисы должны быть автоматически доступны на различных публичных поверхностях зданий и приватных устройствах, используемых людьми для взаимодействия со зданием.
Также запланирована разработка интеграционной шины, позволяющая сторонним разработчикам подключать интеграционные модули, изменять существующие и добавлять новые сервисы. Запланирована разработка API и SDK для работы с интеграционной шиной и реализация доступа к структурированной обновляемой документации, а также разработка системы, позволяющей встраивать стороннюю функциональность в приложения Ujin Apps
Кроме того, запланировано: доработка функций виртуальной диспетчерской (виртуализация принципов организации связей, параметров, состояний, расположений оборудования в составе инженерных систем зданий); интеграция с BIM –моделями зданий; создание «электронного двойника» здания; разработка персонального ассистента и развитие B2C сервисов Ujin; таргетирование с учетом портрета клиента цифровыми сервисами; разработка маркета B2B и B2C сервисов; автоматизация процессов подключения сервисов и биллинга услуг.
Источник.
https://www.cnews.ru/news/top/2024-01-24_izbavlenie_rossijskogo_zhkh
пятница, 22 марта 2024 г.
Архитектура предприятия
SAP представил следующую простую "картинку" архитектуры предприятия:
Уровни архитектуры предприятия (в ходе перевода упоминание SAP S/4HANA заменено на "цифру".
- Стратегия и организация. Как архитектура поддерживает наилучшим образом стратегию бизнеса.
- Бизнес процессы. Какие бизнес-процессы имеют наибольшие возможности для улучшения? Как идентифицировать эти бизнес-процессы.
- Функции/Возможности. Как получить максимум из "цифры"? Какие компоненты связаны с потребностями бизнеса?
- Приложения. Как старые приложения могут быть переведены на "цифру"? Что стоит сохранить? Как сохранить ландшафт максимально экономичным?
- Данные. Какие стратегические данные поддерживают бизнес приоритеты? Как можно увероваться в качестве данных на всем ландшафте?
- Платформа. Какие возможности платформы интеллектуализируют предприятие?
- Технология. Как перейти в "облако"? Каковы риски и ограничения используемых технологий?
пятница, 6 октября 2023 г.
Технологический (технический) долг
Хотя многие компании понимают важность технологий для достижения своих стратегических целей, на их пути часто стоит молчаливый убийца усилий по модернизации технологий — технический долг. Технический долг — это, по сути, «налог», который компания платит за любую разработку для решения существующих технологических проблем, Налог этот примерно составляет 40% баланса ИТ. Зачастую приходится из бюджета, выделаемого на разработку новых продуктов, приходится выделять средства на решение проблем, связанных с техническим долгом.
Отсюда можно предположить, что погашение технического долга может привести к освобождению инженеров и направить их усилия и таланты на работу над продуктами и услугами, создающими ценность. А также стоит предположить, что произойдет сокращение затрат за счет сокращения времени, необходимого для решения сложных задач; а также повышение времени безотказной работы и отказоустойчивости. Сокращение технического долга — ключ к тому, чтобы стать технологическим лидером: компанией, в которой технологии являются двигателем постоянного роста и производительности.
Так как же организации могут начать погащать технический долг? Все как обычно - нужно начинать с выяснения - какие аспекты технического долга больше всего связаны со стоимостью.
Технический долг возникает в результате целого ряда практик:
Финансирование
Структура распределения капитала для погашения технического долга — стратегическое решение, которое должно быть принято генеральным директором, финансовым директором и ИТ-директором. Это гораздо больше, чем упражнение по целевому выделению средств; чем просто выделить 15-20% ИТ-бюджета на покрытие технического долга недостаточно.
Наиболее успешные организации явно учитывают технический долг во всех процессах бюджетирования активов и разработки.
Даже самые далеко идущие и продуманные структуры и планы управления могут рухнуть перед лицом реалий на местах. Здесь может помочь внутреннее ценообразование.
Например, общая проблема заключается в том, что даже несмотря на то, что ИТ может представить стоимость проекта, включающаю в себя передовые методы, такие как включение API или погашение технического долга, бизнес-сторона может полагать, что более быстрое, дешевое и более безопасное одноразовое решение является лучшим выбором, даже если оно увеличивает технический долг.
Одна компания даже ввела политику, согласно которой любое исключение по техническому долгу должно быть одобрено генеральным директором. Этот механизм вынуждал команды разрабатывать веские доводы для любых краткосрочных потребностей и представлять план погашения технологического долга.
При внедрении важно ориентироваться на ценность. Обычно не имеет смысла снижать уровень технического долга ниже 10%, потому что часть технического долга не стоит выплачивать. Иногда даже необходимо взять на себя дополнительный технический долг, чтобы иметь возможность двигаться более быстро, если представилась возможность, которой нужно немедленно воспользоваться.
Облачные технологии могут быть основным компонентом программы технологической модернизации, но проблемы технического долга, существующие локально, волшебным образом не исчезнут в облаке. На самом деле, могут вырастить расходы и помешать компаниям воспользоваться преимуществами услуг, предлагаемых облачными провайдерами.
Зачастую техническая модернизация терпит неудачу из-за того, что у компаний нет механизмов для отслеживания происходящего и агрессивного вмешательства в ход реализации.
Прогресс в каждом квартале
Долгосрочные планы рухнут, если не будет механизма сохранения импульса. Ежеквартальные бизнес-отчеты — наиболее эффективный способ сохранить импульс, обеспечивая прозрачность оценки хода процесса, а также возможность принятия решений. Однако ежеквартальные бизнес-отчеты представляют собой пассивный процесс проверки, в котором отсутствуют качественные данные, необходимые для принятия правильных решений. В высокоэффективных компаниях старшие руководители в руководящем комитете занимают гораздо более жесткую позицию в ходе анализа ежеквартальных бизнес-отчетов. Они проверяют эффективность команды с тем, чтобы определить первопричины либо хорошего прогресса (чтобы они могли воспроизвести передовой опыт), либо плохого прогресса (чтобы определить основную проблему).
Команды по разработки продукта отвечают за технический долг в части их касающейся.
Основной единицей работы по технической модернизации является команда разработчиков, которая разрабатывает решения и выполняет работу по сокращению технического долга. Лучшие команды автономны, ориентированы на создание ценности и поддерживаются соответствующими ресурсами.
Основной принцип современной группы по разработке продукта заключается в том, что она отвечает за создание приложений, а также за их запуск и управление ими. Это означает, что любые проблемы с долгом остаются проблемой команды разработчиков, а не кого-то еще. Многие стартапы следуют этому подходу, посвящая два спринта (около четырех недель) в каждом квартале специально для приведения в порядоксвоих приложений и ликвидации технического долга. Таким образом, продуктовые команды гарантируют, что они могут продолжать развиваться в нужном темпе и приносить пользу.
Какой бы сложной ни была технологическая ситуация сейчас, она будет только ухудшаться, если технический долг не устраняется. Решение этой проблемы требует от компаний понимания масштабов технического долга и ценности его погашения, а также принятия на себя обязательств по его уменьшению. Чтобы технологии стали двигателем роста, компаниям необходимо вырваться из порочного круга технологического долга и модернизироваться.
Источник.
К Аамер Бейг, Свен Блумберг, Арун Гундурао и Базель Кайяли. "Разорвите порочный круг технического долга, чтобы модернизировать свой бизнес". 25.04.2023 г.
Отсюда можно предположить, что погашение технического долга может привести к освобождению инженеров и направить их усилия и таланты на работу над продуктами и услугами, создающими ценность. А также стоит предположить, что произойдет сокращение затрат за счет сокращения времени, необходимого для решения сложных задач; а также повышение времени безотказной работы и отказоустойчивости. Сокращение технического долга — ключ к тому, чтобы стать технологическим лидером: компанией, в которой технологии являются двигателем постоянного роста и производительности.
Так как же организации могут начать погащать технический долг? Все как обычно - нужно начинать с выяснения - какие аспекты технического долга больше всего связаны со стоимостью.
Порочный круг технического долга
Технический долг возникает в результате целого ряда практик:
- внесение временных исправлений, которые неизбежно становятся постоянными,
- отказ от обновления устаревших решений,
- предпочтение "быстрых" технологий долгосрочным преимуществам,
- внедрение одноразовых решений для удовлетворения бизнес-приоритетов.
Многие из этих решений имеют смысл и необходимы. Но сложность нарастает, и будущие проекты усложняются.
Возникает порочный круг:
- Увеличение требований бизнеса приводит к субоптимальным точечным решениям. Бизнес склонен формированию требований, которые приводят к быстрым решениям. Потеря координации и сотрудничества препятствует к выработке лучших по сравнению с краткосрочными долгосрочных решений.
- Субоптимальные точечные решения приводит к "спегатти" точечных решений и одноразовых приложений, что увеличивает технических долг.
- Порочный круг делает будущие проекты более трудными в реализации и добавляет скрытие затраты в виде упущенных возможностей и впустую потраченных ресурсов.
Накопленный технологический долг создает огромное препятствие в деле трансформации бизнеса — это все равно, что пытаться бежать, таща за собой все более тяжелый якорь.
Вырваться из этого порочного круга непросто. Знать, с чего и как начать, — серьезная проблема. Неправильный подход может легко привести к трате времени и денег без особых изменений технологического долга. Бизнес-сторона дома может быть перегружена задачей и захочет делегировать проблему ИТ-отделу. На деле же обе стороны должны работать вместе, чтобы найти решения, которые позволят организации конкурировать и создавать ценность.
Мероприятия преодоления порочного круга
1. Преимущество измерений и прозрачности
Измерение технического долга требует классификации приложений по типам их развертывания — например, локальные, виртуализированные, контейнерные, программное обеспечение как услуга (SaaS) или функция как услуга (FaaS). Затем сбор метаданных касательно конкретных приложений по каждому типу приложений с тем, чтобы отразить сумму технического долга в разрезе приложений. Этот подход дает возможность сравнивать приложения с точки зрения стоимости технологического долга.
Любая серьезная техническая модернизация начинается с точного и подробного учета текущего технического долга, документирования активов, данных и их связи с ценностью для бизнеса. Это позволит создать значимую поддержку в бизнесе, установить реалистичные бюджеты, точно распределить средства и расставить приоритеты для инициатив.
Составление такого рода баланса — нетривиальная задача. Он начинается с расчета стоимости времени, потерянного разработчиками для решения проблем, возникающих в результате технического долга, и затрат на решение самого технического долга. Важно анализировать технический долг на уровне активов, таких как приложение или база данных, чтобы иметь возможность увидеть, как каждая часть ИТ архитектуры связана со стоимостью. Кроме того, анализ должен учитывать почти дюжину различных типов технического долга, таких как инфраструктура, код и документация, поскольку каждый из них требует своего типа исправлений.
Можно отметить следующее:
Десятилетия работы, помогающей компаниям определять и реализовывать бизнес-стратегии, научили нас тому, что стратегия неэффективна, если она не воплощена в рациональном распределении людских и бюджетных ресурсов. Эффективное распределение ресурсов требует управленческих усилий для структурирования процесса принятия решений, включая лиц, принимающих решения, и критерии, которые они используют. Эти структурные решения имеют важное значение, поскольку техническая модернизация — многолетняя программа.
Три соображения являются ключевыми для успеха:
Составление такого рода баланса — нетривиальная задача. Он начинается с расчета стоимости времени, потерянного разработчиками для решения проблем, возникающих в результате технического долга, и затрат на решение самого технического долга. Важно анализировать технический долг на уровне активов, таких как приложение или база данных, чтобы иметь возможность увидеть, как каждая часть ИТ архитектуры связана со стоимостью. Кроме того, анализ должен учитывать почти дюжину различных типов технического долга, таких как инфраструктура, код и документация, поскольку каждый из них требует своего типа исправлений.
Можно отметить следующее:
- Технический долг распределяется неравномерно. Всегда есть набор из 10–15 активов, ответственных за большую часть технологического долга предприятия. Именно здесь компании должны сосредоточить свои усилия.
- Серьезность технического долга варьируется. Сумма технического долга между приложениями может различаться в два-три раза.
- Некоторые технические долги лучше оставить в покое. В некоторых случаях стоимость решения технического долга данного актива не стоит затраченных усилий.
2. Обязательства: надежное управление и структура распределения.
Десятилетия работы, помогающей компаниям определять и реализовывать бизнес-стратегии, научили нас тому, что стратегия неэффективна, если она не воплощена в рациональном распределении людских и бюджетных ресурсов. Эффективное распределение ресурсов требует управленческих усилий для структурирования процесса принятия решений, включая лиц, принимающих решения, и критерии, которые они используют. Эти структурные решения имеют важное значение, поскольку техническая модернизация — многолетняя программа.
Три соображения являются ключевыми для успеха:
- финансирование,
- подотчетность,
- ценообразование в деле списания технологического долга.
Финансирование
Структура распределения капитала для погашения технического долга — стратегическое решение, которое должно быть принято генеральным директором, финансовым директором и ИТ-директором. Это гораздо больше, чем упражнение по целевому выделению средств; чем просто выделить 15-20% ИТ-бюджета на покрытие технического долга недостаточно.
Наиболее успешные организации явно учитывают технический долг во всех процессах бюджетирования активов и разработки.
Поскольку программы технической модернизации часто переживают срок пребывания в должности высшего руководства, совет директоров должен играть решающую роль. Совет директоров должен помочь установить и защитить капитал, предназначенный для погашения технологического долга.
Управление
Наличие руководящего комитета с лидерами как из ИТ, так и из бизнеса — это хорошее начало для организации должного управление. В комитете должно быть быть достаточно высокопоставленных персон с тем, чтобы проводить изменения и преодолевать неизбежные битвы за сферы влияния и конкурирующие приоритеты. По этой причине крайне важно включить финансового директора или финансового руководителя в состав команды, и в идеале этот человек должен достаточно разбираться в ключевых технологических вопросах.
Другая важная роль руководящего комитета заключается в установлении и обеспечении соблюдения набора целей и ключевых результатов. Команды разработчиков должны сосредоточится на достижении результатов, а не на отчетах о деятельности. Лучшие ключевые результаты для отслеживания прогресса в борьбе с техническим долгом решают такие вопросы, как производительность команды (время, затрачиваемое на разработку новых возможностей по сравнению с решением проблем технического долга) и скорость выхода на рынок (скорость и скорость выпуска новых возможностей), а также надежность и ликвидация. переделок. Система ежеквартальных бизнес-обзоров для отслеживания прогресса и оценки эффективности также имеет решающее значение для соблюдения графиков.
Ценообразование
Другая важная роль руководящего комитета заключается в установлении и обеспечении соблюдения набора целей и ключевых результатов. Команды разработчиков должны сосредоточится на достижении результатов, а не на отчетах о деятельности. Лучшие ключевые результаты для отслеживания прогресса в борьбе с техническим долгом решают такие вопросы, как производительность команды (время, затрачиваемое на разработку новых возможностей по сравнению с решением проблем технического долга) и скорость выхода на рынок (скорость и скорость выпуска новых возможностей), а также надежность и ликвидация. переделок. Система ежеквартальных бизнес-обзоров для отслеживания прогресса и оценки эффективности также имеет решающее значение для соблюдения графиков.
Ценообразование
Даже самые далеко идущие и продуманные структуры и планы управления могут рухнуть перед лицом реалий на местах. Здесь может помочь внутреннее ценообразование.
Например, общая проблема заключается в том, что даже несмотря на то, что ИТ может представить стоимость проекта, включающаю в себя передовые методы, такие как включение API или погашение технического долга, бизнес-сторона может полагать, что более быстрое, дешевое и более безопасное одноразовое решение является лучшим выбором, даже если оно увеличивает технический долг.
Одна компания даже ввела политику, согласно которой любое исключение по техническому долгу должно быть одобрено генеральным директором. Этот механизм вынуждал команды разрабатывать веские доводы для любых краткосрочных потребностей и представлять план погашения технологического долга.
При внедрении важно ориентироваться на ценность. Обычно не имеет смысла снижать уровень технического долга ниже 10%, потому что часть технического долга не стоит выплачивать. Иногда даже необходимо взять на себя дополнительный технический долг, чтобы иметь возможность двигаться более быстро, если представилась возможность, которой нужно немедленно воспользоваться.
Облачные технологии могут быть основным компонентом программы технологической модернизации, но проблемы технического долга, существующие локально, волшебным образом не исчезнут в облаке. На самом деле, могут вырастить расходы и помешать компаниям воспользоваться преимуществами услуг, предлагаемых облачными провайдерами.
3. Контроль исполнения: оценка прогресса и корректировка планов и графиков
Зачастую техническая модернизация терпит неудачу из-за того, что у компаний нет механизмов для отслеживания происходящего и агрессивного вмешательства в ход реализации.
Прогресс в каждом квартале
Долгосрочные планы рухнут, если не будет механизма сохранения импульса. Ежеквартальные бизнес-отчеты — наиболее эффективный способ сохранить импульс, обеспечивая прозрачность оценки хода процесса, а также возможность принятия решений. Однако ежеквартальные бизнес-отчеты представляют собой пассивный процесс проверки, в котором отсутствуют качественные данные, необходимые для принятия правильных решений. В высокоэффективных компаниях старшие руководители в руководящем комитете занимают гораздо более жесткую позицию в ходе анализа ежеквартальных бизнес-отчетов. Они проверяют эффективность команды с тем, чтобы определить первопричины либо хорошего прогресса (чтобы они могли воспроизвести передовой опыт), либо плохого прогресса (чтобы определить основную проблему).
Таким образом, ежеквартальные бизнес-отчеты предоставляет комитету четкое представление о «реальности», позволяют корректировать цели, могут выступать в качестве системы раннего предупреждения о проблемах. Комитет на основе анализа отчетов может перераспределить ресурсы для поддержки высокоэффективных инициатив и приостановить или отменить неэффективные инициативы. Благодаря таким практикам ежеквартальные бизнес-отчеты становятся полезным двигателем реформ.
Для обеспечения работы руководящего комитета, компаниям необходимо инвестировать в инструменты управления производительностью. Эти инструменты позволят руководству в режиме реального времени оценивать ход и прогресс реформ, а также предоставят прогнозную аналитику. Прогнозная аналитика позволит увидеть, смогут ли команды достичь целей и шансы на успех. У компаний часто есть много полезных инструментов и данных, которые уже есть под рукой. Инструменты контроля качества кода, например, могут автоматически сообщать о фактах отсутствия документированного кода или о наиличии неиспользуемого кода.
Команды по разработки продукта отвечают за технический долг в части их касающейся.
Основной единицей работы по технической модернизации является команда разработчиков, которая разрабатывает решения и выполняет работу по сокращению технического долга. Лучшие команды автономны, ориентированы на создание ценности и поддерживаются соответствующими ресурсами.
Основной принцип современной группы по разработке продукта заключается в том, что она отвечает за создание приложений, а также за их запуск и управление ими. Это означает, что любые проблемы с долгом остаются проблемой команды разработчиков, а не кого-то еще. Многие стартапы следуют этому подходу, посвящая два спринта (около четырех недель) в каждом квартале специально для приведения в порядоксвоих приложений и ликвидации технического долга. Таким образом, продуктовые команды гарантируют, что они могут продолжать развиваться в нужном темпе и приносить пользу.
Заключение
Какой бы сложной ни была технологическая ситуация сейчас, она будет только ухудшаться, если технический долг не устраняется. Решение этой проблемы требует от компаний понимания масштабов технического долга и ценности его погашения, а также принятия на себя обязательств по его уменьшению. Чтобы технологии стали двигателем роста, компаниям необходимо вырваться из порочного круга технологического долга и модернизироваться.
Источник.
К Аамер Бейг, Свен Блумберг, Арун Гундурао и Базель Кайяли. "Разорвите порочный круг технического долга, чтобы модернизировать свой бизнес". 25.04.2023 г.
https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/breaking-technical-debts-vicious-cycle-to-modernize-your-business
вторник, 20 июня 2023 г.
Защита критически важных цифровых активов
Некоторые цифровые активы являются экстраординарными и критически важны для компании. Соответственно, из нужно защищать киберугроз. Но в мире, который становится все более оцифрованным, защита всех цифровых активов в одной и той же степени - невозможна.
Многие организации пытаются применять одни и те же средства контроля кибер-рисков везде и в равной степени, часто тратя время и деньги впустую, а в некоторых местах не тратя достаточно средств. Другие применяют частичные средства защиты, которые оставляют уязвимыми некоторые жизненно важные информационные активы, слишком сильно фокусируясь на менее важных. Тем временем бюджеты на кибербезопасность конкурируют за ограниченные средства с инвестициями в технологии, призванными сделать организацию более конкурентоспособной. Более того, инвестиции в новые технологии могут создать дополнительные уязвимости.
Работа по приоритизации активов и рисков, оценке средств контроля и разработке планов восстановления может быть утомительной и трудоемкой. Специалисты должны анализировать тысячи рисков и тысячи средств контроля, а затем составлять рейтинги на основе индивидуальных суждений. Некоторые организации относятся к этой работе как к соблюдению нормативных требований, а не как к важному бизнес-процессу. Без расстановки приоритетов организации будет сложно эффективно использовать ресурсы для снижения риска информационной безопасности. Опасности будут нарастать, советы директоров не смогут оценить безопасность предприятия, не смогут понять, окупаются ли дополнительные инвестиции.
Некоторые данные, системы и приложения являются более важными, чем другие. Некоторые более подвержены риску, а некоторые станут мишенью. Критические активы и уровни чувствительности к риску также различаются.
Столкнувшись с такими разнообразными угрозами, компании решают потратить больше средств на кибербезопасность, но не знают, как это сделать.
Поэтому необходим единый общекорпоративный подхода к киберрискам с участием бизнеса, ИТ и кибербезопасности. Лидеры этих групп должны начать работать вместе, выявляя и защищая критически важные цифровые активы организации. Процесс устранения киберрисков должен стать технологически возможным благодаря внедрению систем управления рабочими процессами. Инвестиции в кибербезопасность должны быть ключевой частью бюджетного цикла, а инвестиционные решения должны быть обоснованными и чувствительными к изменениям.
Следует начать с бизнес-проблемы, которая требует рассмотрения всего предприятия, а затем определить приоритеты критических рисков. Эта работа должна выполняться командой в масштабе всего предприятия. Команда должна состоять из ключевых представителей бизнеса, представителей кибербезопасности, ИТ и менеджеров по управлению рисками. Основные задачи команды — определить, какие информационные активы с точки зрения защиты являются приоритетными, насколько велика вероятность того, что они будут атакованы, и как их защитить. Чтобы функционировать, команда должна задействовать лидеров нескольких областей. Им нужно работать вместе, чтобы выяснить, что является самым важным — что сама по себе непростая задача. Лучший способ начать работу - определиться с расстановкой приоритетов в масштабе всего предприятия. Другими словами, коллектив в первую очередь будет служить предприятию. Критические риски, включая влияние различных угроз и вероятность их возникновения, будут оцениваться в соответствии с опасностями, которые они представляют для бизнеса в целом.
Следующие принципы могут помочь компаниям не сбиться с пути, применяя единый подход к расстановке приоритетов цифровых активов и рисков:
Целью общекорпоративного подхода является выявление и устранение пробелов в существующих системах контроля и безопасности, влияющих на критически важные активы. Решение будет сквозным процессом, который потребует нескольких итераций разработки такого процесса. Этот процесс будет включать подробный учет сотен активов. Система рабочих процессов и база данных активов были бы идеальным инструментом для поддержки этого сложного процесса, позволяя сосредоточиться на приоритизации рисков. Гибкое, масштабируемое и безопасное онлайн-приложение может быть простым в использовании при управлении всеми инвентарными и картографическими данными, строгими оценками рисков и контроля, отраслевыми методологиями и обоснованиями для каждого уровня риска.
Эксперты McKinsey определили следующие пять ключевых шагов:
Этот процесс способствует прозрачности кибер-рисков, отвечая на ключевые вопросы заинтересованных сторон:
Использован следующий источник.
Защита ваших критически важных цифровых активов: не все системы и данные созданы равными.
Protecting your critical digital assets: Not all systems and data are created equal
By Piotr Kaminski, Chris Rezek, Wolf Richter, and Marc Sorel
31 января 2017 г.
https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/protecting-your-critical-digital-assets-not-all-systems-and-data-are-created-equal
Большинство крупных предприятий в настоящее время осознают серьезность проблемы, но по-прежнему относятся к ней как к технической проблеме или как к проблеме контроля, даже признавая, что их средства защиты вряд ли будут успевать за будущими атаками.
Следующая волна инноваций — клиентские приложения, бизнес-процессы, технологические структуры и средства защиты от кибербезопасности — должна основываться на бизнес- и техническом подходе, в котором приоритет отдается защите критически важных информационных активов.
Такой подход может быть назван «цифровой устойчивостью» — кросс-функциональной стратегией, которая выявляет и оценивает все уязвимости, определяет цели на уровне предприятия и разрабатывает способы их достижения. Основным аспектом цифровой устойчивости является идентификация и защита цифровых драгоценностей организации — данных, систем и программных приложений.
Растущие уязвимости, ограниченные ресурсы, фрагментированные приоритеты
Многие организации пытаются применять одни и те же средства контроля кибер-рисков везде и в равной степени, часто тратя время и деньги впустую, а в некоторых местах не тратя достаточно средств. Другие применяют частичные средства защиты, которые оставляют уязвимыми некоторые жизненно важные информационные активы, слишком сильно фокусируясь на менее важных. Тем временем бюджеты на кибербезопасность конкурируют за ограниченные средства с инвестициями в технологии, призванными сделать организацию более конкурентоспособной. Более того, инвестиции в новые технологии могут создать дополнительные уязвимости.
Работа по приоритизации активов и рисков, оценке средств контроля и разработке планов восстановления может быть утомительной и трудоемкой. Специалисты должны анализировать тысячи рисков и тысячи средств контроля, а затем составлять рейтинги на основе индивидуальных суждений. Некоторые организации относятся к этой работе как к соблюдению нормативных требований, а не как к важному бизнес-процессу. Без расстановки приоритетов организации будет сложно эффективно использовать ресурсы для снижения риска информационной безопасности. Опасности будут нарастать, советы директоров не смогут оценить безопасность предприятия, не смогут понять, окупаются ли дополнительные инвестиции.
Данные и системы не равноценны
Некоторые данные, системы и приложения являются более важными, чем другие. Некоторые более подвержены риску, а некоторые станут мишенью. Критические активы и уровни чувствительности к риску также различаются.
Злоумышленниками могут быть отдельные лица или организации, преступные синдикаты или правительства, располагающие значительными ресурсами. Атаки могут быть простыми или изощренными, цели варьируются от немедленного финансового вознаграждения до получения конкурентного или даже геополитического преимущества.
Расходы на кибербезопасность: больше - значит меньше
Столкнувшись с такими разнообразными угрозами, компании решают потратить больше средств на кибербезопасность, но не знают, как это сделать.
Поэтому необходим единый общекорпоративный подхода к киберрискам с участием бизнеса, ИТ и кибербезопасности. Лидеры этих групп должны начать работать вместе, выявляя и защищая критически важные цифровые активы организации. Процесс устранения киберрисков должен стать технологически возможным благодаря внедрению систем управления рабочими процессами. Инвестиции в кибербезопасность должны быть ключевой частью бюджетного цикла, а инвестиционные решения должны быть обоснованными и чувствительными к изменениям.
Общекорпоративный подход
Следует начать с бизнес-проблемы, которая требует рассмотрения всего предприятия, а затем определить приоритеты критических рисков. Эта работа должна выполняться командой в масштабе всего предприятия. Команда должна состоять из ключевых представителей бизнеса, представителей кибербезопасности, ИТ и менеджеров по управлению рисками. Основные задачи команды — определить, какие информационные активы с точки зрения защиты являются приоритетными, насколько велика вероятность того, что они будут атакованы, и как их защитить. Чтобы функционировать, команда должна задействовать лидеров нескольких областей. Им нужно работать вместе, чтобы выяснить, что является самым важным — что сама по себе непростая задача. Лучший способ начать работу - определиться с расстановкой приоритетов в масштабе всего предприятия. Другими словами, коллектив в первую очередь будет служить предприятию. Критические риски, включая влияние различных угроз и вероятность их возникновения, будут оцениваться в соответствии с опасностями, которые они представляют для бизнеса в целом.
Руководящие принципы
Следующие принципы могут помочь компаниям не сбиться с пути, применяя единый подход к расстановке приоритетов цифровых активов и рисков:
- Начните с бизнеса и цепочки создания стоимости. Усилия должны основываться на представлении о бизнесе и цепочке создания стоимости. Команда директора по информационной безопасности, особенно если она является частью ИТ-организации, как правило, начинает со списка приложений, систем и баз данных, а затем разрабатывает представление о рисках. В этом подходе есть два основных недостатка. Во-первых, он часто упускает из виду ключевые риски, которые могут возникать при совместной работе систем. Во-вторых, контекст таких работ слишком технический, что затрудняет привлечение бизнеса к принятию решений. Начиная с бизнеса, команда естественным образом поощряет участие заинтересованных сторон в такой работе, тем самым повышая вероятность выявления системных рисков.
- Директор по информационной безопасности должен активно руководить работами. Активно привлекая бизнес-лидеров и других заинтересованных лиц в качестве полноправных партнеров, директор по информационной безопасности поможет установить важные отношения для принятия полностью обоснованных решений об инвестициях и распределении ресурсов для решения задач кибербезопасности. Роль директора по информационной безопасности в таком случае может резко измениться, его роль и навыки должны быть соответствующим образом скорректированы.
- Сосредоточьтесь на том, как могут быть скомпрементированы информационные активы. Если информационный актив подвергается взлому системы, следует учитывать уязвимость этой системы, даже если основная цель системы не связана с этим информационным активом.
- Сосредоточьтесь на расстановке приоритетов, а не на идеальной количественной оценке. Команде нужно ровно столько информации, чтобы принимать решения по приоритетным активам и пока не нужны точные количественные оценки риска.
- Углубляйте анализ. Один и тот же уровень анализа не требуется для количественной оценки всех рисков. Только для особенно серьезных или сложных рисков команда должна инвестировать в более глубокий анализ. Затем он должен принять решение и получить информацию, необходимую для принятия более обоснованных инвестиционных решений.
- Примите точку зрения нападающего. Обзоры рисков и анализ уязвимостей не должны сосредотачиваться исключительно на ценности информации для компании и выявленных пробелах в ее защите. Профили потенциальных злоумышленников также важны: кому нужна информация организации? Какими навыками они обладают? Размышление о вероятных злоумышленниках может помочь выявить новые бреши и направить инвестиции для защиты информации, наиболее ценной для наиболее способных противников.
Гибкий системный процесс
Целью общекорпоративного подхода является выявление и устранение пробелов в существующих системах контроля и безопасности, влияющих на критически важные активы. Решение будет сквозным процессом, который потребует нескольких итераций разработки такого процесса. Этот процесс будет включать подробный учет сотен активов. Система рабочих процессов и база данных активов были бы идеальным инструментом для поддержки этого сложного процесса, позволяя сосредоточиться на приоритизации рисков. Гибкое, масштабируемое и безопасное онлайн-приложение может быть простым в использовании при управлении всеми инвентарными и картографическими данными, строгими оценками рисков и контроля, отраслевыми методологиями и обоснованиями для каждого уровня риска.
Киберрешения от экспертов McKinsey
Эксперты McKinsey определили следующие пять ключевых шагов:
- Идентифицируйте и сопоставляйте цифровые активы, включая данные, системы и приложения, по всей цепочке создания стоимости бизнеса. Эту работу можно ускорить, применяя обобщенную отраслевую цепочку создания стоимости и общую таксономию для информационных активов.
- Оцените риски для каждого актива, используя опросы и семинары для руководителей . Основывая этот анализ на деловой важности актива, организация определит ценные информационные активы.
- Определите потенциальных злоумышленников, доступность активов для пользователей, а также текущие средства контроля и меры безопасности, защищающие системы, через которые можно получить доступ к активам.
- Определите самые слабые места безопасности вокруг ценных активов и определите средства контроля, которые должны использоваться для их защитыю Используйте информационные панели для сравнения оценок.
- Создайте набор инициатив для устранения высокоприоритетных рисков и пробелов в контроле. Реализация будет включать многолетний план, включая сроки проведения будущих обзоров кибербезопасности. После завершения первоначальной оценки этот план становится живым документом, который регулярно обновляется для отражения новых данных, систем, приложений, рисков и сопоставлений, а также прогресса в устранении известных уязвимостей.
Этот процесс способствует прозрачности кибер-рисков, отвечая на ключевые вопросы заинтересованных сторон:
- Каковы информационные риски?
- Где уязвима организация?
- Насколько велико (и где) последствия реализации риска?
- Каким действиям по исправлению положения нужно отдать приоритет?
- Как мы узнаем, работает ли то, что сделано?
Компромиссы могут быть определены на основе точки зрения на подверженность риску и ценность актива в масштабах всей компании. Это помогает высшему руководству и совету директоров обсуждать риски информационной безопасности с точки зрения ценности предприятия, обеспечивая прозрачность в отношении того, какие риски они готовы принять и почему.
Использован следующий источник.
Защита ваших критически важных цифровых активов: не все системы и данные созданы равными.
Protecting your critical digital assets: Not all systems and data are created equal
By Piotr Kaminski, Chris Rezek, Wolf Richter, and Marc Sorel
31 января 2017 г.
https://www.mckinsey.com/capabilities/risk-and-resilience/our-insights/protecting-your-critical-digital-assets-not-all-systems-and-data-are-created-equal
Подписаться на:
Комментарии (Atom)