4 декабря 2024 г.
Продолжение. Начало тут
С какими вызовами сталкиваются участники ИТ-канала, формируя сегментные ПАКи, в которых каждый компонент (рабочее место делопроизводителя, рабочее место инженера CAD, пользовательская или серверная ОС, почтовый клиент и сервер, офисный пакет, средства виртуализации и т. п.) гарантированно совместим с любым другим?
Сегментируйте это
Формирование сегментных ПАКов, на взгляд Алексея Криштопа, директора по облачным сервисам «Группы Астра», — это сложный путь от подбора «железа» до совместимости с компонентами софта: «Здесь важно понимать, что стоит задача не собрать ПАК один раз (это хоть и сложно, но возможно), а обеспечить ему жизненный цикл, расширение и обновления. Такая задача намного сложнее, но этим она и более амбициозна и интересна. Сегодня это направление активно развивается, и я думаю, что будущее — за универсальными решениями, которые можно будет кастомизировать у себя на площадке».
Алексей Криштоп, директор по облачным сервисам «Группы Астра»:
Выбор между разработкой собственного решения и приобретением готовой системы является сложным и требует взвешенного подхода. Заказчик, обладая сильными компетенциями в своей области, может быть склонен к разработке уникального продукта, если существующие решения не удовлетворяют его потребности. Однако при этом существует риск остаться с собственным решением «один на один», что может привести к неожиданным затратам и зависимостям от узкоспециализированных кадров. Безусловно, создание уникального решения может казаться более экономически выгодным на начальных этапах, но важно понимать, что в долгосрочной перспективе это может обернуться гораздо большими расходами и рисками.
Альтернативным вариантом является использование готовых решений, таких как программное обеспечение «под ключ», то есть ПАКи, которые уже прошли тестирование на рынке и предлагают проверенные бизнес-сценарии. Этот путь позволяет не только сэкономить время, но и снизить риски, связанные с разработкой, так как такие продукты уже доказали свою эффективность. Также существует возможность комбинированного подхода, который может обеспечить оптимальный баланс между кастомизацией и готовыми решениями.
Наблюдая за текущими тенденциями, можно сказать, что внедрение универсальных программных продуктов с возможностью настройки под конкретные нужды компании будет иметь важное значение в будущем. Это направление имеет все шансы на активное развитие и может стать ключевым для многих предприятий, стремящихся к оптимизации своих бизнес-процессов и снижению затрат.
Реклама ООО «РусБИТех-Астра», ИНН: 7726388700
Первый вызов, на который указывает Ирек Азизов, генеральный директор ООО «ICL Системные технологии», — это то, что совместимость гарантируется далеко не с любым другим продуктом, а лишь в рамках конкретного ПАКа: «По привычке, которую мы приобрели за годы присутствия в России мировых вендоров, „всё должно заработать само“. Но у нас сейчас не совсем так. Мы находимся в стадии массового тестирования и проверки совместимости различных программных и аппаратных компонентов, ускоренного появления новых программных продуктов и моделей вычислительного оборудования. И о полноценной системной совместимости аппаратных и программных решений на российском рынке пока говорить рано».
Второй вызов, упомянутый экспертом, — административный и организационно-документарный: «ПАК — активно развивающееся и формирующееся направление на рынке России. Однозначных ответов и устоявшихся практик — например, по налоговому сопровождению таких решений, эксплуатации после сроков полезного использования и капитальных ремонтов, — на данный момент нет. Всё только начинается, что открывает много возможностей и формирует пространство для манёвра, — но вместе с тем и создаёт дополнительную неопределённость, снижающую привлекательность инвестиций в эту сферу со стороны производителей».
«Третий вызов, — продолжает эксперт, — изменения в канале продаж. Наблюдаем трансформацию рынка: продуктовая экспертиза потихоньку „съезжает“ от вендоров в сторону интеграторов. В свою очередь, дистрибьюторы также стали активно развивать оказание сервисных услуг: это меняет границы рынка для основных его участников, но в любом случае выгодно заказчикам — так как движение идёт в сторону комплексного сервиса в режиме „одного окна“. И четвёртый вызов — непосредственно продуктовый. Крупнейшие мировые вендоры всегда инвестировали огромные бюджеты в R&D, создавая определенные стандарты, и другим игрокам рынка приходилось соответствовать требованиям и быть совместимыми с операционными системами, базами данных и т. д., чтобы быть в рынке».
Сейчас в России, считает эксперт, это не так: «У различных вендоров — свой взгляд на развитие своих продуктов. Поэтому на интеграторов сейчас легла функция R&D, функция тестирования совместимости программных и аппаратных решений между собой в тестовых средах с заданными параметрами. И далеко не каждый заказчик готов выделять ресурсы, рисковать и тестировать на себе, в своей ИТ/ИБ- среде, проводя различные эксперименты на совместимость. Это, с одной стороны, ведёт к появлению на рынке новых узкоспециализированных решений, а с другой — к большому перераспределению функций и продуктовых специализаций между участниками рынка, которое пока активно развивается. Сложно понять, как это будет выглядеть через несколько лет».
Алексей Мосин, руководитель отдела развития продукции Nerpa, называет в числе вызовов сложности с подбором ПО, которое наиболее полно обеспечило бы решение всех поставленных заказчиком задач: «Например, до сих пор на нашем рынке нет полноценной замены решению для проектирования AutoCAD, которому годами отдавали своё предпочтение многие проектировщики, архитекторы, конструкторы и инженеры. Компания Autodesk, владелец продукта, в 2024 году запретила российским компаниям использовать своё ПО — и заблокировала все существующие лицензии. Решения же, которые приходят на замену, пока что уступают по функциональным возможностям».
«На мой взгляд, — говорит Александр Фролов, руководитель группы по управлению инфраструктурой рабочих мест ICL Services, — основной вызов при формировании сегментных ПАК заключается в обеспечении полной функциональной совместимости. Дело в том, что несмотря на тестирование компонентов, интеграция ПО и аппаратного обеспечения от различных производителей может создать сложности. Разные версии программ могут иметь несовместимые обновления, что требует постоянного мониторинга, тестирования и взаимодействия между разработчиками. Также стоит отметить, что при добавлении новых элементов в ПАК необходимо учитывать, как новые компоненты будут взаимодействовать с уже установленными решениями, — что может усложнить процесс масштабирования ИТ-инфраструктуры».
Как отмечает Илья Левчук, директор департамента индустриальных программно-аппаратных комплексов компании Fplus, на рынке есть примеры компаний, которые внутри себя создают отдельную структуру, занятую как раз тестированием ПО на выпускаемом ими «железе»: «То есть у отечественных вендоров уже есть осознание, что экосистема должна быть интегрирована и проработана. Основной момент здесь —правильная оценка рынка, сегментация, понимание целевой аудитории и ниш. Иногда бывает, что крупные заказчики сами не заинтересованы в этой истории. У них есть свои крупные команды, которые занимаются интеграцией. Им дешевле и проще отдельно купить „железо“ и софт, а всю работу по кросс-интеграции, валидациии архитектуры решения, тестированию оставить у себя».
«Я не верю в перспективы создания клиентских ПАКов, — решительно говорит Владимир Попов, директор департамента инфраструктуры информационных систем АМТ-ГРУП. — Последние
Приводя в движение
Кто чаще инициирует создание сегментных ПАКов как вертикально-интегрированных ансамблей софта и «железа»? Как организуется взаимодействие между участниками подобных коллабораций?
Как свидетельствует практика Алексея Криштопа, это может быть любой из участников: «Вендор ПО, вендор „железа“ или интегратор. Заинтересованы в этом все. Кроме того, если у заказчика сильна собственная компетенция, то некоторые из них идут по пути внутренней разработки — при условии что нет требуемого решения на рынке. Но здесь очевидны риски остаться с уникальным продуктом один на один. Разработка может оказаться дорогой, а затраченные инвестиции не оправдаться. Кроме того, при этой схеме заказчик сильно зависит от ключевых технических специалистов внутри компании. Многие ошибочно думают, что так дешевле, но, если детально разобраться, на длинной дистанции это не так».
«По нашим наблюдениям, — говорит Алексей Мосин, — чаще всего как координатором, так и заказчиком сегментных ПАК выступают интеграторы. Они хорошо знают проблемы клиентов и владеют широким экспертным видением как в части „железа“, так и в части софта».
«Чаше всего координаторами создания различных ПАК выступают системные интеграторы, — подтверждает Дмитрий Парипа, системный архитектор FERRUM IT Group. — Это вызвано тем, что у интеграторов есть понимание потребностей, полученное от самых разных заказчиков. На этом основании можно спрогнозировать, какой ПАК является оптимальным в данном случае — и может быть реализован с использованием доступных технологий и при соблюдении требований заказчика. Интеграторы зачастую обладают большим опытом интеграции и тестирования; имеют более глубокую экспертизу в программных продуктах и аппаратных решениях».
Эксперт приводит в примере ПАК, который FERRUM IT Group разработала, объединив 10 российских ИT-продуктов: «Мы поставили задачу создать безопасное рабочее место с переездом с Windows на Linux, которое отвечает требованиям регулятора по информационной безопасности. В части „железа“ такой проект не представляет проблемы; всё решается тестированием внутри интегратора. Что касается послойного подбора программного обеспечения, — тут мы совместно с вендором формируем команды технических специалистов, которые на основе наших тестов на совместимость выпускают патчи и доработки в вендорском ПО. Более того, мы прорабатываем не унитарную компоновку, а с возможностью модификаций под бизнес-функции заказчика. Таким образом тот может выбирать из пула решений, которые мы протестировали, — ради удобства сотрудников».
По словам Ирека Азизова, многие системные интеграторы сейчас переживают трансформацию, зачастую выполняя роль координаторов между производителями «железа» и софта: «Но такая трансформация — большая нагрузка на интеграторов; не все могут перестроиться. Кроме того, непонятно, должны ли появляться на рынке специализированные ПАК под конкретного заказчика — или всё-таки это есть спрос на достаточно универсальные модульные решения? Пока взаимодействие с клиентами по этим вопросам идёт в ручном режиме».
Как справедливо замечает Владимир Попов, любой тиражируемый продукт является результатом скоординированных усилий большого числа людей: «Технические решения, касающиеся оборудования и программного обеспечения, в этом процессе важны, — но начинается всё с изучения рынка, с формирования требований и формулирования концепции продукта, что к технике относится только косвенно. Жизненный цикл ПАК как продукта предполагается довольно длинным, поэтому ещё на этапе начала работ производитель должен понимать, кто будет его покупателем, как будет предоставляться техническая поддержка, какими силами и в каком направлении продукт будет развиваться. Интегратор может играть в этом процессе консультативную роль и обеспечивать для производителя обратную связь — занимаясь внедрением и сопровождением его продукции у заказчика».
По опыту Александра Фролова, инициатором или координатором создания ПАКа могут выступать как производители оборудования, так и системные интеграторы: «Реже эту роль могут взять на себя разработчики программного обеспечения. В нашем случае мы одновременно являемся системным интегратором и производителем программного продукта Колибри-АРМ, который интегрируется в состав наших ПАКов. Тем не менее, системные интеграторы чаще всего находятся ближе всего к конечным клиентам — и лучше всего понимают их потребности и проблемы. Это даёт возможность разрабатывать решения, которые максимально соответствуют ожиданиям заказчиков. Что же касается взаимодействия участников при разработке ПАК, то оно обычно осуществляется в рамках формализованных партнёрских отношений. Статус партнёра снимает многие барьеры, позволяя более оперативно и эффективно решать возникающие вопросы и обеспечивать успешную реализацию проекта в сжатые сроки».
Окончание следует
Источник: Максим Белоус, IT Channel News
erid: 2SDnjdNHhzj