Расширение практики обучения по принципу "Равный-равному" в сфере государственных финансов на уровне местного самоуправления в Кыргызской республике (стр. 25 )

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

-  Лицензионное Соглашение Программного Обеспечения. В интересах получения более низкой цены тендерного предложения клиент может пожелать рассмотреть вопрос об определении ограничения в использовании программного обеспечения. Такие ограничения могут содержать: ограничение количества записей в отдельных категориях, которые могут быть в Системе; ограничения количества лиц, которые могут быть авторизованы для использования Системы и количества лиц, которые могут одновременно получить доступ к Системе и т. д.

-  Конфиденциальность. В этом разделе клиент может пожелать передать соответствующими ведомствами доступ к определенным конкретным видам технической и финансовой информации в ходе реализации контракта.

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

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

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

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

-  Заранее Оцененные Убытки. Обычным процентом является половина одного процента (0,5%) в неделю и десять процентов (10%) от общей суммы. Ставки, указанные здесь должны быть согласованы с соответствующими записями в Таблице Данных Тендерного Предложения в качестве основы для корректировки цен предложения. В некоторых случаях, это приемлемо для определения заранее оцененных убытков на ежедневной основе. Очень важно, чтобы этапы контракта были определены, и задержки в реализации этих этапов будут подразумевать заранее оцененные убытки.

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

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

Раздел VI. Технические Требования

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

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

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

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

Технические характеристики обычно включают в себя следующие разделы:

1.  Общие технические требования (например, языковая поддержка, частота и напряжение электроэнергии, климатические условия эксплуатации, стандарты безопасности),

2.  Аппаратные характеристики (минимальный уровень производительности ввода-вывода),

3.  Сетевые и коммуникационные характеристики,

4.  Характеристики программного обеспечения,

5.  Характеристики управления системой, администрирования и безопасности,

6.  Характеристики обслуживания (системные интеграции, обучение, техническая поддержка и т. д.),

7.  Общие требования к отчетам поставщика, которые должны быть представлены в ходе реализации проекта,

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

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

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

11.  Требования к пользовательским документам,

12.  Требования к технической документации (руководство по эксплуатации, инструкция по установке, руководство по ремонту и т. д.),

13.  Требования к обучающей документации,

14.  Расходные материалы и другие периодические статьи расходов,

15.  Другие не IT-товары.

Следует избегать ссылки на торговые марки, номера каталогов, конкретных производителей, за исключением случаев, когда такие ссылки необходимы, чтобы гарантировать, что предлагаемое оборудование поддерживает конструктивные особенности или технические параметры / отметки производительности, необходимые для удовлетворения требований покупателя. Там, где такие ссылки неизбежны, должно быть добавлено выражение "или эквивалент" что позволит производителю рассмотреть необходимые параметры в предлагаемом оборудовании. Рекомендуется четко указывать международные стандарты (например, API, ISO, SYSmark и т. д.), которые должны быть применены к оборудованию. При отсутствии таких стандартов, могут быть применены национальные стандарты.

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

График Реализации включает в себя: (a) ключевые Информационные Технологии, материалы, и другие товары и услуги, входящие в состав Системы, которая будет поставляться победителем торгов; (b) количество таких Информационных Технологий, материалов, и других товаров и услуг; (c) места, где будет установлена Система ​​и выполняемые услуги; (d) должны быть Установка и Оперативное Принятие для всех подсистем и/или основных компонентов системы, и самой системы в целом, а также любых других основных этапов Контракта. Обратите внимание, что дата поставки не должна быть указана в Графике Реализации, но ее должны предоставить претенденты. Ориентировочные даты завершения, приведенные в Графике Реализации должны быть реалистичными, чтобы позволить претендентам подготовить предложения с реалистичными и конкурентоспособными ценами. Разбивка, приведенная в Графике Реализации должна тесно отражать приведенную разбивку в Таблице Цен. График Реализации также выполняет ряд других важных функций: (a) этапы выполнения в Графике должны быть использованы для построения графика платежей, приведенные в Специальных Условиях; (b) График является ключевым инструментом, который Покупатель использует для ежедневного наблюдения и контроля выполнения Поставщиком; (c) применение положения по заранее оцененным убыткам в Общих Условиях Контракта напрямую связано с датами, указанных в Графике; (d) количество, по каждому пункту показанное в Графике Реализации должно использоваться в качестве отправной точки для любых вариантов количества, которые Покупатель, возможно, пожелает затребовать в момент присуждения Контракта.