[#КШ] Технические требования холдинг «Байтерек».docx

Google Docs neutral 2026-04-11 14 чанков ~20 мин чтения

Сущности

АО НУХ Холдинг CMS НОВОСТИ АО «Национальный управляющий холдинг «Байтерек ДО НУХ «Байтерек Холдинга Единая платформа сайты Холдинг Пресс-релизы Новость

Технические требования к созданию единой платформы сайтов АО «Национальный управляющий холдинг «Байтерек» 1. Наименование системы Полное наименование системы: единая платформа сайтов АО «Национальный управляющий холдинг «Байтерек» (далее – Холдинг). Упрощенное обозначение в данном документе: Платформа/Система 2. Цели создания платформы Цели создание единой платформы сайтов Холдинга заключается в следующем: Обеспечить соответствие всех сайтов Холдинга единым стандартам интерфейсов и оформления. Иными словами, каждый сайт будет эффективно предоставлять всем группам пользователей всю нужную информацию по единому стандарту – таким образом, пользователю, который привык пользоваться одним сайтом Холдинга, не нужно будет заново привыкать к интерфейсу всех остальных. При этом, заходя на сайт Холдинга впервые, пользователь по элементам визуального оформления (баннеры, пиктограммы, иллюстрации, активные элементы навигации) пользователь будет сразу считывать принадлежность компании к Холдинга. Обеспечить оперативное и полноценное управление стратегически важной информацией на всех сайтах Холдинга, реализованных на платформе. Обновление любой необходимой информации на любом из сайтов платформы будет происходить централизованно из одной панели управления. У уполномоченных сотрудников каждой компании Холдинга будет доступ к своему сайту, при этом общий доступ ко всем сайтам будет находиться у сотрудников в центральном офисе Холдинга. Обеспечить простоту создания нового сайта в рамках расширения, преобразования или модернизации группы, широкий выбор готовых, предустановленных модулей и оперативность технического обновления и доработки платформы. При этом любой сайт, созданный на платформе, не будет восприниматься как шаблонный, так как все модули и шаблоны реализованы в рамках брендбука с повсеместным использованием брендированных элементов. 3. Назначение платформы Единая платформа сайтов Холдинга подразумевает наличие полноценной Content Management System (CMS) – полного спектра готовых модулей, которые могут понадобиться при настройке и заполнении всех сайтов Холдинга. Процесс создания сайта на платформе будет заключаться в настройке и наполнении контентом готовых модулей. При этом в панели управления платформой будет предоставляться выбор из нескольких вариантов для любого шаблона или раздела. Набор интерфейсов для корпоративного сайта НУХ «Байтерек» будет наиболее полным и развернутым – по количеству разделов и модулей, т.е. он является основной частью фреймворка. Сайты всех остальных дочерних организаций (ДО) Холдинга будут «собираться» в рамках общего оформления и базовой структуры из набора готовых модулей платформы. Для каждого «основного» раздела (например, главная страница или новостной раздел) можно будет выбрать один из нескольких шаблонов в соответствии с текущими задачами. Шаблоны будут отличаться алгоритмом подачи (выдачи) контента. К примеру, при создании раздела «Новости» будет учитываться характер новостных сообщений, который практикует ДО. Можно выбрать шаблон, в котором все новости будут подаваться в едином формате отдельных материалов, или шаблон, в котором все новости подразделяются на несколько подразделов, таких как «Новости», «Пресс-релизы», «Пресса о нас» и так далее. При этом если структура инфоповодов, которые генерирует компания, изменится, структура раздела «Новости» будет изменена в процессе простой перенастройки в панели управления платформой. На примере главной страницы процесс настройки может выглядеть следующим образом: Устанавливаем логотип компании в «шапке» сайта, настраиваем отображение главного меню (в зависимости от количества разделов); Выбираем вариант слайдера из нескольких предложенных; Настраиваем отображение блоков с анонсами под слайдером. В зависимости от направления деятельности компании, это может быть блок с анонсом актуальных услуг или продуктов, новостная лента, блок с анонсами актуальных акций и так далее. При этом можно настраивать любое положение блоков на главной странице в соответствии с их приоритетом. В рамках платформы будет реализован также полный набор узкоспециализированных модулей/виджетов, которые разработаны под требования конкретной ДО. 4. Задачи, решаемые при помощи платформы Единая веб-платформа сайтов Холдинга должна способствовать максимально эффективному решению 3-х главных стратегических задач: Повышать узнаваемость компаний Холдинга; Способствовать эффективному информированию об услугах компании, важных изменениях и новостях; Предоставлять максимально простые и удобные прикладные сервисы, которые позволят пользователям произвести калькуляцию определенных услуг в соответствии с индивидуальными условиями, например, различные финансовые калькуляторы… 5. Структура Платформы Единая Платформа сайтов будет состоять из сайтов следующих дочерних организаций: 6. Визуальная концепция Создание единой визуальной концепции в рамках разработки платформы подразумевает создания полной библиотеки всех необходимых шаблонов, модулей, пиктограмм, иллюстраций, шаблонов оформления изображений. В готовом виде эта библиотека будет сгруппирована в digital-брендбук – объемный документ, который описывает и наглядно рассматривает все возможные правильные (и недопустимые) варианты оформления шаблонов и использования брендированных элементов на корпоративном сайте Холдинга и дочерних организаций. Практика создания digital-брендбуков повсеместно используется в США, Европе и России. Если говорить об общей стилистике сайтов платформы – они будут спроектированы такими образом, чтобы способствовать максимально эффективному выполнению задач, решаемых при помощи платформы. Дизайн сайтов будет ясным и динамичным – белый фон, достаточное количество «воздуха» (свободная верстка с большими отступами), большие графические элементы (фотографии и иллюстрации, вырезанные по контуру). Все модули платформы по умолчанию будут иметь адаптивную версию. Таким образом, при включении нового модуля на одном из сайтов Холдинга, все необходимые изменения, например, в мобильной версии, будут происходить автоматически. 7. Функциональные характеристики Формат единой платформы имеет существенные плюсы в разрезе технической модернизации. Любое программное решение в процессе эксплуатации дорабатываются, так как появляются новые задачи, а старые трансформируются. В этом случае технические обновления будут автоматически применяться на всех сайтах Холдинга централизованно. К примеру, производится доработка модуля новостей – страницы отдельных новостей приобретают доработанную структуру подачи контента и более эффектный дизайн. В этом случае будет производиться однократное обновление шаблона новостей на платформе, после которого отображение новостей на всех сайтах компаний Группы меняется автоматически. 8. Базовый функционал Геотаргетинг – автоматическое распознавание региона, т.е. сайты на платформе должны отображать только ту информацию, которая актуальна для этого региона, откуда пришел посетитель. Если в регионе не представлена та или иная услуга, вовсе не отображать ее в меню. Сформировать региональную привязку для активных элементов контента; Продуктовое профилирование… Автоматически генерируемая карта… Поиск продуктов/услуг по заданным критериям. Сравнение двух и более продуктов/услуг из одной категории. Предварительная заявка на Service Desk… Анкетирование посетителей сайта. Может быть реализовано в виде обычного анонимного опросник на сайте; если через личный кабинет, то анкетирование. При этом вопросы должны отвечать требованиям логики: в начале речь должна идти об установлении того или иного факта, а потом уже о его оценке. Опросники будут создавать корректоры сайтов, т.е. в каждой ДО, по потребностям бизнес- подразделений. Личный кабинет, который позволяет использовать персонифицированные сервисы, в том числе: единоразовое заполнение персональной информации, дающее возможность автозаполнения соответствующих полей форм заявок на продукты, анкет и т.п.; сохранение заполненных анкет и заявок на продукты; сохранение и сравнение расчетов в калькуляторах. Интеграция с социальными сетями; Интеграция с внутренним почтовым сервером; Интеграция с CRM; Наличие SOA, REST API. … 9. Требования к CMS CMS Платформы должна позволять обеспечивать архитектурную гибкость, данный тезис подразумевает: Произвольную группировку сайтов в рамках CMS; Произвольную группировку разделов внутри сайта; Перемещение и изменение архитектуры сайта в любой момент времени; Устойчивость логики: сохранение работоспособности сайта при произвольном изменении вложенности и местоположения разделов, исключающее необходимость участия разработчиков в данном процессе; Смену логики принимаемых и отправляемых данных в рамках одного и того же раздела (в случае необходимости расширения логики); Динамическую смену URL, повторяющую логику сайта, не требующую указывать полный URL вручную: при изменении вложенности раздела его URL должен меняться автоматически; Возможность экспорта/импорта содержимого различных узлов информационной архитектуры сайта, для упрощения переноса данных между разделами/сайтами; Возможность разграничивать доступ к определенным сайтам/разделам для определенных групп пользователей. Административная система управления информационной архитектурой сайта должна гибко настраиваться: «переодевание» и брендирование управляющих интерфейсов, доступ к строго определенным интерфейсам для различных групп пользователей, встраивание интерфейсов во фронт-офис. Публикация контента – процедура, включающая в себя подготовку контента, его выверку и согласование. Обычно она требует участия нескольких сотрудников. Автор (профильный специалист) готовит материал, руководитель соответствующего подразделения проверяет его, а сотрудники подразделения маркетинга отвечают за стиль публикации и ее соответствие общей политике Холдинга. Важно настроить панель управления Платформой таким образом, чтобы ни одно звено в цепочке не будет пропущено, и обеспечить технологическую поддержку процедуры публикации контента. Настройка системы публикации должна быть очень гибкой и отражать каждый этап работы над текстом – например, «редактируется автором», «на согласовании», «на утверждении», «опубликовано». Кроме того, необходимо настроить права разных групп пользователей таким образом, чтобы они полностью соответствовали их степени ответственности и регламентированному процессу публикации контента. CMS Платформы должна обеспечивать следующие базовые возможности: Обновление любого контента Платформы; Изменение структуры Платформы; Управление пользователями (пользователи, группы, профили, workflow); Управление уровнями доступа пользователей к различным сервисам и возможностям портала; Поддержку модульной архитектуры, подразумевающую реализацию основных функций в качестве отдельных модулей, обеспечивающих возможность их независимой модификации. Сбой в работе одного из модулей не должен приводить к полному прекращению функционирования портала/сайта в целом; Подключение дополнительных модулей; Весь необходимый функционал для сбора статистики; Настройки процесса утверждения контента до публикации. При этом должно быть реализовано версификация контента: кто, что, когда – вносил, утверждал, публиковал. Пользователь Платформы должен иметь возможность быстро и легко задать «принципы», по которому формируются метаданные, такие как: Возможность задания уникальных заголовков браузера (title), мета-тегов (description, keywords) и URL для всех страниц сайта; Возможность выделения на странице одного заголовка h1 и, при необходимости, нескольких заголовков более низкого уровня; Возможность выделения отдельных слов на странице жирным шрифтом в теге и курсивом в теге , задания атрибута alt для изображений. Каждая страница сайта должна имеет свой уникальный и постоянный URL-адрес, который соответствует следующим требованиям: URL не должен содержать информацию о сеансе работы пользователя с сайтом; URL должны указываться в кодировке, соответствующей кодировке сайта, к примеру, кириллические адреса должны указываться в закодированном виде, используя при этом метод преобразования Punycode; При формировании ссылки из одной страницы на другую (внутренние/ внешние ссылки), отслеживание наличие «битых» ссылок; Страницы не должны ссылаться несколько раз на одну страницу; Автоматический изменять URL-адрес внутренней ссылки, при изменении адреса самой страницы; При формировании URL-адреса использовать концепцию ЧПУ. Изменение контента страницы (редактирование текста, обновление графики) обычно проводят сотрудники профильных подразделений, которые не владеют языком HTML, поэтому в CMS должен быть встроенный редактор, позволяющий править тексты в дружелюбном привычном интерфейсе, т.е. работающий по принципу WYSIWYG, которое предполагает полное соответствие экранного изображения с изображением, напечатанном на принтере. При этом требования к редактору при работе с текстом следующие: Форматирование текста по аналогии MS Word (шрифт, абзац, стиль); Наличие проверки орфографии и грамматики; Возможность вставки текста из MS Word; Добавление специальных символов и формул; Возможность создания и редактирования таблицы, без непосредственного написания HTML-тегов; Возможность создания и редактирования гиперссылок на документ на сервере/ на другой сайт/ внутри данного документа/ электронный адрес. Требования к редактору при работе с графикой следующие: Загрузка и размещение изображения, с возможностью указания размера вручную или в процентах от оригинала; Возможность указания вручную заголовка изображения и альтернативного текста; Форматирование изображения; Возможность размещения видеоролика. Все варианты оформления и группировки контента должны быть описаны в digital- брендбуке. Дизайн CMS Платформы должен соответствовать основным принципам юзабилити любого пользовательского интерфейса. В общих чертах это означает, что окна CMS должны иметь четкое расположение элементов и ясное представление информации. Основные принципы юзабилити требуют: Четкого отображения местоположения пользователя в интерфейсе CMS; Ясного отображения прогресса выполнения заданий (возможно, с помощью интерфейсов типа «администратор»); Наличия «визуальной иерархии» на страницах, где самые важные элементы имеют наиболее заметное положение, а отношения между элементами имеют четкое отображение; Понятного отображения и легкого считывания информации; Группирования элементов интерфейса по логическому принципу; Наличия крупного и читабельного текста, с возможностью масштабирования. 10. Статистика и мониторинг В рамках реализации единой платформы будет настроен кабинет для сбора детализированной статистики в разрезе конкретных задач Холдинга. Это позволит создать и настроить кастомные инструменты сбора статистики, которые не предусмотрены на распространенных аналитических платформах, таких как Google Analytics, Яндекс. Метрика и т. п. Доступ к статистике платформы должна быть только у системного администратора. При мониторинге посещений рекомендуется использовать счетчики и карты кликов, невидимый для посетителей сайта. Так же необходимо, чтобы в CMS было наличие функциональных возможностей по сбору и хранению статистики поисковых запросов – для определения наиболее востребованных сервисов и возможностей портала рекомендуется собирать статистическую информацию, характеризующую активность пользователей в рамках соответствующих частей портала. Необходимо собирать и хранить статистическую информацию за весь период. 11. Управление правами пользователей Управление платформой будет производиться как централизованно, так и на местах в ДО. Должна быть возможность регистрации неограниченного количества пользователей и наделения их какими-либо правами. Каждый зарегистрированный пользователь должен иметь минимум 2 свойства: логин и пароль (настраиваемые требования к сложности пароля), при помощи которых происходит авторизация в системе, а также должен быть отнесен к какой-нибудь группе пользователей (пользователь может состоять в нескольких группах). Эта привязка помимо удобства визуального восприятия (например, создание групп в соответствие со структурой организации и внесение в эти группы сотрудников отделов) имеет и функциональное назначение: наследование прав. Это означает, что, если группе пользователей присвоены какие-то права, все пользователи этой группы будут иметь эти же права, даже если самим пользователям эти права явно не присвоены. Таким образом, к панели управления платформой будет предусмотрено несколько видов доступа. Так, на первоначальном этапе будет как минимум 4 группы пользователей, каждый со своими правами доступа и набором полномочий: Администратор – веб-администраторы, осуществляющие поддержку по техническому сопровождению: C полными правами на управление системой. C возможностью создания новых/редактирования существующих пользователей и/или групп пользователей. С правами выдачи полномочий. С доступом в режиме просмотра ко всем системным журналам и отчетам. Корректор платформы – сотрудники Холдинга, с неограниченными возможностями по редактированию структуры сайта/дизайна оформления/контента на любом из сайтов Холдинга, которые будут регулярно обновлять информацию/настройки на стратегически важных модулях. Корректор сайта – сотрудники подразделений ДО и Холдинга, с ограниченными возможностями по редактированию только текстового контента информационных разделов, таких как: Главная страница Контактные данные Режим работы компании Новости компании. Аудитор – сотрудники подразделения внутреннего аудита ДО и Холдинга, с полным доступом ко всему функционалу Системы в режиме просмотра, без права редактирования объектов и данных в Системе. 12. Стратегически важные модули Системы 12.1 Единый модуль управления структурой Управление структурой всех сайтов должно быть реализовано в виде единого интерфейса, состоящего из блоков всех сайтов Системы. Отображение может быть выполнено в виде корневого дерева или в любой другой удобной и наглядной форме. Принципиальной характеристикой модуля является возможность включить/ выключить/настроить любой шаблон представления контента или любой модуль (калькуляторы, курсы валют и так далее) на любом сайте Системы. Таким образом будет обеспечиваться необходимая гибкость и оперативность. Для групп пользователей «Администратор» и «Корректор платформы» должна быть доступна возможность полного управления структурой сайтов Системы, в том числе: Добавление и удаление разделов и страниц; Изменение структуры разделов и страниц (очередность отображения в структуре, положение узконаправленных модулей на странице). Пользователи группы «Корректор сайта» будут иметь полномочия редактирования контента в определенных разделах, при этом изменять структуру и представления разделов и страниц сайта они не смогут. 12.1 Единый модуль модерации контента Единый модуль модерации контента подразумевает удобную и наглядную группировку функционала по добавлению, редактированию, модерации и публикации текстового и графического контента. При этом должна у пользователей групп «Администратор» и «Корректор платформы» должна быть возможность добавлять частичный или полный функционал данного модуля в любой раздел или на любую страницу в рамках Системы. Один из важнейших параметров данного модуля – максимально полное воплощение процесса по созданию, утверждению и публикации контента. Это подразумевает возможность внесения изменений на уровне инициатора, автора и модератора контента, и что очень важно – версионирование этих изменений. То есть в рамках одного черновика (сохраненного материала, который не отображается для пользователей Системы) можно будет просмотреть первоначальную версию материала и отредактированную с отображением авторов всех версий. Модуль подразумевает реализацию максимально полных возможностей по персонифицированному оформлению контента. Возможности будут реализованы посредством текстового и графического редактора, позволяющего изменять представление контента в рамках выбранного шаблона. К примеру, это могут быть различные виды оформления цитат, графического и видеоконтента. Модуль также подразумевает возможность добавлять/удалять/редактировать все предусмотренные виду изображений и видеофайлов. 12.3 Единый модуль управления личными кабинетами посетителей Единый модуль управления личными кабинетами пользователей подразумевает логичный и удобный интерфейс по настройке типов данных, которые выводятся в личных кабинетах на разных сайтах ДО. Возможностью настройки личных кабинетов посетителей будут обладать только пользователи групп «Администратор» и «Корректор платформы». 12.4 Единый модуль управления статистикой Единый модуль управления статистикой представляет отдельный интерфейс панели управления Системой, в котором собрана статистика в разрезе практических задач Холдинга. Под статистикой имеется в виду, как минимум, следующие параметры: посещаемость; число уникальных посетителей; число просмотров страниц; число сессий; демографические характеристики; географические; аппаратно-технические (браузер, операционная система, разрешение экрана); параметры, характеризующие поведение аудитории на сайте; источники трафика. Гибкие возможности отчетности. Возможность комбинировать и менять форматы и содержание отчетов под основные требования. Настройка регулярных уведомлений на разные почтовые адреса. Все возможные статистические отчеты будут доступны только пользователей статус «Администратор» – остальные пользователи будут иметь доступ к одному или нескольким блокам статистики в единицу времени. 12.5 Единый модуль интеграции с внутренними системами Единый модуль интеграции Системы со всеми внутренними системами, используемых во всех дочерних организации Холдинга. Системы должна предусматривать наличие стандартных REST API для интеграции с ИС организаций Холдинга. … 13. Базовые требования к системе Разрабатываемая Система не должна писаться целиком «под задачу», и должна базироваться на устойчивой версии базового решения: оно должно иметь, как минимум, полтора года рабочего стажа (во избежание проблем «альфа»-версий и исключения большого периода тестирования и фактических доработок, когда система, фактически, непригодна для практического применения). Разрабатываемая Система не должна базироваться на «коробочной версии» для узкоспециализированных решений (Интернет-магазин, корпоративный сайт и т.п.): подобные решения, как правило, не предоставляют архитектурной гибкости вне рамок решаемой задачи, и требуют неэффективных доработок, выходящих за рамки соглашений и распространенных практик использования базового решения, что отрицательно сказывается на работоспособности и поддерживаемости решения сторонними разработчиками. В разрабатываемой системе должны быть предусмотрены стандартные инструменты для интеграции с информационными системами Холдинга. Унифицированная Система должна позволять размещать произвольное количество подобных сайтов (либо сайтов нескольких предопределенных типов) в рамках одной структурной модели, с возможностью управлять ими из одного интерфейса. 13.1 Требования к поддержке языков Система должна поддерживать возможность отображения контентных страниц на следующих языках: казахский, русский, английский. Учитывая, что будут объединены веб-сайты ДО с разными видами деятельности, платформа должна поддерживать мультисайтовость, т.к., например, нет необходимости отображения раздела «Тендеры» во всех языковых версиях. К тому же, необходимо разграничивать доступ к разным сайтам ДО для коррекции контента. На Платформе должна быть предусмотрена возможность перевода полей всех языкозависимых констант, чтобы переводить не только контент сайта, но и подписи на кнопках навигации, наименование рисунков, тексты почтовых уведомлений и прочее. Причем набор всех констант из системы должен быть реализован в одном справочнике, для централизованного перевода. 13.2 Требования к безопасности Платформа должна: Предоставлять доступ в консоль CMS и в личный кабинет посетителя только после прохождения процедуры аутентификации. Процедуры аутентификации пользователя и посетителя должны быть отделены, а настройка должна быть независима. Предоставлять возможность отправки кодов авторизации или ссылок по изменению паролей на указанные контактные данные (телефоны/e-mail) для посетителей. Поддерживать возможность блокирования одновременного доступа под одними учетными данными с различных аппаратных средств (компьютеров) для пользователя и посетителя. Обеспечить возможность независимой настройки сложности пароля для пользователя и посетителя. Обеспечить возможность независимой настройки максимального и минимального «срока жизни» пароля для пользователя и посетителя. Обеспечить возможность независимой настройки блокировки учетной записи пользователя при вводе неправильного пароля несколько раз подряд для пользователя и посетителя. Обеспечить для пользователя возможность настройки установки администратором признака принудительной смены пароля при первом входе пользователя в консоль CMS. Обеспечить для пользователя количества дней, после истечения которых не используемая учетная запись блокируется. Обеспечить регистрацию нового пользователя в консоли администратора CMS. Обеспечить назначение прав доступа и ролей с разграничением по уровням доступа и области видимости для пользователей Холдинга. Обеспечивать подключение и обмен информации с пользователем и посетителем с шифрованием по протоколу SSL или TLS. Обеспечить все данные, вводимые пользователем, дополнительной проверкой на соответствие формату или шаблону (номер телефона, e-mail и т.д.), обеспечивая контроль вводимых данных. Обеспечить не хранение в файлах cookies авторизационных и аутентификационных данных пользователей и посетителей. Обеспечить ограничение доступа к консоли CMS по IP/MAC-адресам зарегистрированных пользователей Холдинга. Обеспечить ограничение доступа через интернет к консоли CMS для пользователей Холдинга. Обеспечить возможность согласования пользователями группы «Корректор платформы» изменений контента, который был добавлен пользователями группы «Корректор сайта». Обеспечить журналирование всех событий, связанных с действиями пользователей и посетителей. Обеспечить журналирование изменений, которое должно включать сведения о пользователе, внесшем изменения, в том числе его логин и IP/MAC-адрес, содержимое до изменения, содержимое после изменения и время наступления события. Обеспечить ограничение доступа к журналам только лицами со специальной ролью (ролью Администратора или Аудитора). Обеспечить невозможность редактирования записей журналов. Обеспечить возможность настройки периода хранения журналов на уровне консоли CMS. Обеспечить хранение в зашифрованном виде на уровне БД критичных данных, таких как пароли для учетных записей пользователей. Поддерживать процесс версионности доработок с хранением изменений в репозитории с документацией внесенных изменений/дополнений. Соответствие нижеуказанным пунктам не является обязательным, но будет рассматриваться как дополнительный положительный довод для принятия решения в пользу предполагаемого поставщика: Поддерживать возможность унификации подсистемы управления доступом с Аctive Directory Холдинга в целях реализации функционала Single Sign On. Поддерживать возможность интеграции с имеющимися в Холдинга системами аппаратной авторизации пользователей. Обеспечить возможность независимой настройки длительности отсутствия активности пользователя и посетителя до разрыва сессии (таймаут сессии). Обеспечить возможность независимой настройки времени в мин, на которое блокируется учетная запись для пользователя и посетителя. 13.3 Требования к кросс-браузерности Система должна одинаково отображаться и функционировать в основных десктопных и мобильных браузерах всех используемых версий. 13.4 Требования к документации В рамках разработки и внедрения Системы Потенциальным поставщиком должна быть разработана следующая документация: Архитектура решения. Техническое описание системы. Техническое задание. План-график проекта. Инструкция пользователя. Инструкция администратора. Digital-брендбук. 13.5 Требования к обучению Потенциальный поставщик должен провести обучение пользователей Системы. 13.6 Требования к гарантийному обслуживанию Потенциальный поставщик должен обеспечить следующий режим гарантийного обслуживания разработанной и внедренной Системы: Гарантийный период должен составлять 1 год с даты подписания Акта оказанных услуг по разработке и внедрению Системы. В объемы гарантийного обслуживания должно входить устранение всех сбоев и ошибок в работе Системы, а также исправление несоответствий функционирования Системы требованиям Технического задания. 13.7 Требования к Потенциальному поставщику В целях приобретения качественных услуг у квалифицированного Потенциального поставщика, для обеспечения надлежащего уровня оказываемых услуг, и минимизации рисков по проекту, Заказчиком выдвигаются следующие требования к поставщику: Обладать профессиональной компетенцией и опытом в реализации подобных проектов, иметь необходимые финансовые, материальные и трудовые ресурсы для исполнения обязательств в соответствии с договором поставки; Отсутствие претензий со стороны Холдинга по ранее заключенным договорам; Являться платежеспособным, не подлежать ликвидации, на его имущество не должен быть наложен арест, его финансово-хозяйственная деятельность не должна быть приостановлена в установленном законодательством РК порядке; Выполнять свои обязательства по уплате налогов и других обязательных платежей в бюджет на момент подачи заявки на участие в тендере и на момент заключения договора о закупках; Подрядчик должен иметь юридическое лицо, зарегистрированное в РК, и постоянно действующий офис в РК; Компания-поставщик не должна находиться в состоянии переговоров о возможной ее продаже сторонней компании; Возможность разработки Системы на основе распространенного фреймворка со свободной лицензией – чтобы поддержка готовой платформы не зависела от какого-либо лицензионного платного решения, которая ограничивает простор для модернизации; Поставщик должен иметь полноценный, качественный опыт создания, развития и сопровождения группы сайтов для крупных корпоративных клиентов (не менее 3-х лет); Необходимо, чтобы все проекты компании осуществлялись на унифицированной платформе, долгосрочное и последовательное использование которой (не менее, чем в течение года) позволяет выработать единые корпоративные стандарты; Подрядчик обязан предоставить информацию о планируемой команде проекта; Команда проекта должна обладать навыками безопасного программирования, а генерируемый ею код должен проходить сканирование на системах анализа исходного кода с целью обнаружения недекларированных возможностей или ошибок, которые могут быть использованы злоумышленниками в целях мошенничества, саботажа или несанкционированного доступа к информации. В случае предложения Системы, развертываемой на основе промышленного решения, обязателен официальный статус партнерства с компанией-производителем и авторизационное письмо от вендора предлагаемого решения на право распространения программного обеспечения и сопровождению программного обеспечения на территории РК; Подрядчик должен предоставить требования по необходимому оборудованию для реализации проекта; Оценка предложения Решение будет оцениваться по следующим параметрам: Поддерживаемость: Архитектурная составляющая; Масштабируемость (вертикальное, горизонтальное масштабирование); Наличие и доступность специалистов; Заменяемость специалистов. Сроки: Сроки реализации; Сроки тестирования и ввода в эксплуатацию. Стоимость: Решение; Работа в человеко-часах; Поддержка в человеко-часах. Прочее: Гибкость решения; Отказоустойчивая архитектура и стабильность внедряемой версии при различных нагрузках (отсутствие сбоев в рамках планового функционала при посещаемости до 500 000 в день); Уязвимость; Интеграционные возможности. Оценка потенциальных подрядчиков будет производиться следующим образом: Оценка 2-3 завершенных проектов на основе предлагаемого решения. Собеседование-интервью с техническим директором подрядчиком и программистом(-ами), которые будут задействованы на проекте. Краткая презентация процесса разработки в компании. Презентация решения для Холдинга в соответствии с данными техническими требованиями. Проведение конкурса (тендера). Организация | Веб-адрес | Вид деятельности АО «Национальный управляющий холдинг «Байтерек» АО «Банк Развития Казахстана» АО «KazakhExport» АО «Казына Капитал Менеджмент» АО «Фонд развития предпринимательства «Даму» АО «Казахстанская жилищная компания» АО «Аграрная кредитная корпорация» Организация | Модуль | Система АО «Национальный управляющий холдинг «Байтерек» АО «Банк Развития Казахстана» АО «KazakhExport» АО «Казына Капитал Менеджмент» АО «Фонд развития предпринимательства «Даму» АО «Казахстанская жилищная компания» АО «Аграрная кредитная корпорация»