Непродумане технічне завдання веде до інших неприємностей. Виконавець на етапі реалізації проекту може зіткнутися із труднощами, які не були наперед відомі. Це може стати на заваді виконанню контракту.

Як правильно підготувати технічне завдання до тендеру з інформаційної безпеки

Під час підготовки ТЗ для тендеру бажано керуватися вимогами стандарту ГОСТ 34.602-89 « Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи». Документ допоможе збудувати чітку структуру технічного завдання, Визначити розділи, які будуть заповнюватися необхідними вимогами.

Розглянемо, що потрібно звернути увагу під час заповнення документа.

Технічне завдання на тендер, зразок (зразкова структура)

Загальні відомості

З цього розділу зазвичай починається технічне завдання. У ньому замовник вказує найменування системи. Надає інформацію про себе - повне та скорочене найменування, адресу розташування. Якщо юридична та фактична адреса різняться, слід вказати обидва, щоб уникнути неправильного тлумачення виконавцем.

Заснування проведення робіт. Цілі створення системи

У цьому розділі необхідно вказати підставу для проведення робіт, надання послуг та мету створення системи.

Найчастіше основою створення системи виступають вимоги законодавства. У такому разі необхідно перерахувати нормативні документи, відповідно до яких система має бути створена. Наприклад, вимоги 152-ФЗ «Про персональні дані».

У підрозділі «Мета створення системи» замовник наводить характеристики та показники, які мають бути досягнуті в результаті створення системи. Наприклад, «Захист персональних даних, що передаються відкритими каналами зв'язку».

Замовнику слід уважно поставитися до заповнення даного розділу, оскільки саме він дозволить виконавцю зрозуміти, які очікування замовника від створюваної системи та відповідно до яких документів створюється система.

Загальна характеристика інформаційних систем

Цей розділ присвячений опису наявної інфраструктури замовника. Найкраще заповнити цей розділ максимально докладно.

Тут зазначаються відомості про існуючі об'єкти інформатизації: точну кількість робочих станцій, серверів, адреси та місця їх розташування, операційні системи, що використовуються, наявність підключень до інформаційно-телекомунікаційних мереж міжнародного обміну, наявні засоби захисту інформації, відомості про умови експлуатації інформаційних системта інша інформація, яку варто врахувати під час підготовки технічного рішення.

Детальне та якісне заповнення даного розділу дозволить виконавцю сформувати оптимальне технічне рішення.

Вимоги до системи захисту інформації

У цьому розділі наведено вимоги до системи захисту, яким вона повинна відповідати. Розділ можна умовно поділити на два підрозділи. Загальні вимогидо системи та вимоги до функцій, що виконуються системою.

Загальні вимоги до системи

У підрозділі «Загальні вимоги до системи» зазначають:

• Вимоги до структури та складу підсистем. Наприклад, «Підсистема ідентифікації та аутентифікації», «Підсистема керування доступом» тощо.
• Вимоги до надійності створюваної системи. Наприклад, «Система захисту повинна мати можливість до відновлення та виконання своїх функцій після виходу з ладу (збою) програмних та апаратних засобів».
• Вимоги безпеки, тобто вимоги щодо забезпечення безпеки під час монтажу, експлуатації, обслуговування та ремонту технічних засобів системи захисту. Наприклад, «Апаратні компоненти системи захисту повинні мати захисне заземлення, Занулення ».
• Вимоги щодо експлуатації, технічного обслуговування. Наприклад, «Система захисту має функціонувати цілодобово, у безперервному режимі».

Вимоги до функцій, які виконує система

p align="justify"> Для кожної з підсистем, описаних раніше, встановлюється перелік функцій, завдань, які повинні бути реалізовані системою захисту інформації. Наприклад, для підсистеми керування доступом встановлюється вимога щодо обмеження неуспішних спроб входу до інформаційної системи.

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

Окремими підрозділами у «Вимогах до функцій, що виконуються системою» радимо виділити «Вимоги до програмних засобів» та «Вимоги до технічним засобам».

Вимоги до програмних засобів

У цьому підрозділі до програмних засобів системи захисту слід зазначити:

• вимоги щодо сумісності з операційними платформами та апаратними засобами, що використовуються у замовника;
• вимоги до функціональності описуваного програмного забезпечення;
• вимоги до захисним механізмам, які програма має реалізовувати;
• вимоги щодо сертифікації, якщо відповідно до нормативними документамипотрібне сертифіковане рішення.

Вимоги до технічних засобів

У підрозділі зазначаються:

• вимоги до апаратної платформи, в якій має бути виконаний технічний засіб;
• вимога щодо операційній системі;
• вимоги до функціональних характеристик технічного засобу;
• вимоги до фізичним характеристикам(Розмір, корпус);
• вимоги щодо умов експлуатації ( робоча температура, вологість та ін.);
• вимоги щодо сертифікації.

Склад та зміст робіт

Цей розділ має містити перелік стадій та етапів робіт із створення системи. Обов'язково вказуються терміни виконання для ефективного контролю роботи. Замовник може сформувати вимогу щодо переліку документів, що пред'являються після закінчення відповідних стадій та етапів робіт.

Порядок контролю та приймання системи

У цьому розділі замовник визначає загальні вимоги до робіт. Можна передбачити порядок узгодження та затвердження звітної документації з кожної стадії та етапу робіт або цілком по всьому комплексу робіт.

Наприклад, необхідний підписаний відповідальними особамизамовника акт про виконання робіт на кожному з етапів. Після завершення робіт та підписання акта виконаних робіт братимуться до уваги окремі акти щодо кожного з етапів.

Вимоги до виконавця

Один із завершальних розділів — «Вимоги до виконавця».

У цьому розділі вказується, які ліцензії повинен мати виконавець. Вказуються вимоги щодо кількості та кваліфікацій спеціалістів виконавця для виконання робіт. Важливо розуміти, що вимоги до виконавця мають бути обґрунтовані та аргументовані, інакше на вимоги замовника може бути подана скарга.

Вимоги щодо гарантійного супроводу

на даному етапізазначаються гарантійні вимоги замовника. У вимогах до гарантійного супроводу можна вказати вид необхідного супроводу — телефоном, поштою, онлайн-консультантом на сайті виконавця. Можна вказати вимоги щодо обробки звернень про інциденти - години обробки інцидентів, рівень обслуговування замовника, час реагування на звернення та ін.

Вимоги до документування

Замовник вказує вимоги до переліку виконавців комплектів та видів документів, що підлягають розробці, вимоги щодо надання документів.

Наприклад, документи мають бути надані в друкованому вигляді на паперовому носії та електронному вигляді, записані на носій CD-ROM, DVD-ROM.

Які помилки найчастіше зустрічаються під час підготовки ТЗ

Замовник не знає на підставі якого документа підготувати технічне завдання.

За основу можна взяти ГОСТ 34.602-89 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи» і наповнити документ необхідним матеріалом.

У різних місцяходного й того ж технічного завдання точаться протиріччя.

Перед публікацією технічного завдання його слід ретельно перевірити. Замовнику варто розуміти, що якщо технічне завдання не буде якісно розроблено, він ризикує отримати неякісну послугу, роботу, товар.

Стислі терміни виконання технічного завдання.

Часто зустрічаються техзавдання, у яких прописані дуже стислі терміни виконання робіт. Замовник керується своїми мотивами, проте ризикує отримати неякісні послуги, роботи, товари.

Ми рекомендуємо замовникам під час підготовки ТЗ звертати більше увагина розділ «Склад та зміст робіт». У цьому вся пункті можна деталізувати роботи і розбити їх у окремі етапи, провести аналіз термінів виконання кожного з етапів. Це дозволить отримати більш об'єктивну картину щодо термінів виконання всього ТЗ.

У технічному завданні прописано вимоги до неіснуючих продуктів.

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

Щоб уникнути цієї ситуації, рекомендуємо при складанні ТЗ виділяти найбільше Значні показники, які є у низки товарів. Після підготовки технічного завдання слід ще раз перевірити заявлені вимоги щодо технічним характеристикамщодо відповідності реальним товарам над ринком.

Під час підготовки ТЗ на роботи / послуги часто трапляються варіанти, коли не зафіксовано чіткого переліку робіт / послуг, не визначено результати надання робіт / послуг.

У таких випадках можливі конфлікти між замовником та виконавцем, оскільки надані виконавцем послуги чи роботи не будуть відповідати очікуванням замовника. Щоб цього не сталося, замовнику під час підготовки ТЗ необхідно більше уваги приділяти розділам «Підстава проведення робіт. Цілі створення системи» та «Склад та зміст робіт». Практика показує, що краще розбити роботи на окремі етапи. Описати вимоги до кожного з етапів, зафіксувати терміни виконання та результати робіт на кожному з етапів. Ці дії дозволять покращити контроль за виконанням робіт чи наданням послуг.

Висновок

Грамотно складене технічне завдання буде корисним одночасно і виконавцю та замовнику. Виконавцю воно дозволить адекватно оцінити масштаб робіт без додаткових запитів і роз'яснень, а також запропонувати технічне рішення, що найбільше підходить замовнику. Замовнику дозволить отримати якісно виконану роботу зі створення системи захисту, що максимально відповідає його очікуванням.

Станіслав Шиляєв, керівник проектів з інформаційної безпеки компанії «СКБ Контур»

Нормативні документи та правові аспекти

Наболіле про шаблон технічного завдання для тендерів

Люція Васильєва 29 січня 2015 р. 14:18

У своїй діяльності я часто стикаюся з проханням надіслати шаблон технічного завдання на створення/впровадження/придбання програмного забезпечення, щоб включити його до тендерної документації. Щоразу я ставлю собі запитання, що повинен включати такий шаблон, один він має бути чи кілька, і чи потрібен такий шаблон?

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

Технічне завдання(ТЗ) є основною частиною тендерної документації, мета якої допомогти ініціатору закупівлі (покупцю) зробити однозначний вибір продукту/послуги/роботи із забезпеченням найкращих умов виконання контракту. Постачальник, надаючи шаблон ТЗ, розраховує на те, що його ТЗ задовольнить покупця і буде взято за основу. І, звичайно, продукт постачальника повністю відповідає такому ТЗ, що йде у плюс.

Потрібно розуміти, що під час оцінки заявок на тендер у ініціатора закупівлі немає можливості перевірити достовірність усіх даних та зрозуміти, наскільки його вимоги закриваються пропозицією чергового учасника. А після підписання контракту клієнту не вигідно, а іноді й важко з погляду обґрунтування його розривати.

Тепер розглянемо дії учасника закупівлі (постачальника). Якщо я як виконавець зацікавлений у отриманні контракту з клієнтом, то я підготую докладну пояснювальну записку- заявку на участь у тендері, вивчу та прокоментую всі пункти технічного завдання. Навіть якщо мій продукт сьогодні «не вміє щось робити», то я матиму час «його навчити», або після підписання контракту буде час зрозуміти потребу клієнта і запропонувати альтернативний варіант. Звісно, ​​все в рамках законодавства.

З іншого боку, який би чудовий шаблон технічного завдання не зробили постачальники, і яке б докладне ТЗ не сформував покупець, це не дасть очікуваного ефекту для постачальника: ініціатор закупівлі буде змушений укласти контракт з тим, хто запропонує кращі умови виконання контракту. Технічне завдання не дозволяє гарантовано відсіяти «небажаних» учасників, що передбачено законодавством (процедура закупівлі націлена на можливість вибору та визначення переможця).

Класичне питання постачальника: Що робити? Складати руки та сподіватися на фортуну?». Звичайно ж ні. Технічне завдання треба готувати, але не за шаблоном, а до кожного тендера. А для цього пропоную звернути увагу на наведені нижче моменти, що залежать від способу закупівлі.

Запит котирувань та аукціон- Це способи закупівлі за найменшою вартістю. Тому технічне завдання має бути ємним:

● вмикати докладний опистого, що поставлятиметься, налаштовуватиметься, встановлюватиметься чи модифікуватиметься;

● фіксувати чіткий порядок робіт/виконання послуг, так щоб будь-який потенційний учасник тендеру побачив обсяг та складність та злякався прийняв відповідальність, подаючи заявку на участь у тендері.

Технічне завдання має включати опис результату, саме це дозволить ініціатору на етапі виконання контракту контролювати отримання очікуваного та, за необхідності, обґрунтовано розірвати контракт.

Конкурс- це спосіб закупівлі для визначення постачальника з найкращими умовамивиконання договору. Тут можна застосувати все, що написано вище, але при цьому є і додатковий «важіль», про який постачальники часто забувають. Йдеться критеріях оцінки заявок.

Методика оцінки заявок докладно викладена в Постанові Уряду РФ від 28.11.2013 № 1085 "Про затвердження Правил оцінки заявок,..". Виділяйте у критерії визначення переможця важливі для клієнта сильні сторонивиконавця.

Загальні положення технічного завдання

Якщо у Вас технічно складний проект (або дуже специфічний), то обов'язково в загальних положеннях має бути словник термінів та визначень . Можливо, у глосарії варто дати пояснення деяким вашим зворотам. Щоб не вдалося плутанини, відразу розставте все на свої місця.

Цілі проекту

Обов'язково в технічному завданні потрібно вказати, які цілі у Вашого проекту, для чого він створюється, як працюватиме, що має бути зрештою. Навіть якщо виконавець працює над малою частиною проекту, він повинен повністю розуміти його структуру, завдання, цілі, технічні рішення.

Функціональні вимоги

Всі вимоги до замовника можна поділити на два типи: функціональні та спеціальні.

Функціональні вимоги– це варіанти виконання, які ви хочете бачити у себе.

Спеціальні вимоги- це вимоги, за допомогою яких поставлені завдання мають бути виконані. Якщо таких вимог немає, то дозвольте виконавцю самостійно вирішувати, що і як він буде використовувати при виконанні вашого технічного завдання.

Терміни

Обов'язково у технічному завданні мають бути визначені терміни виконання. Не в будь-якому випадку має бути чіткий термін, та описано санкції за зрив зазначених термінів. Виконавець повинен розуміти, що це не просто пункт технічного завдання, а реальна установка, не виконавши яку, ризикують понести фінансові чи інші санкції.

Звітність

Якщо проект великий, і на його реалізацію потрібно кілька місяців, то розбийте роботу на етапи і по кожному встановіть чіткі часові рамки. Після завершення того чи іншого етапу вимагайте звітності щодо виконаної роботи. Також має бути звіт за фактом виконаних робіт.

Відповідальність

Якщо ви укладаєте договір, то пункт щодо відповідальності буде у ньому. Якщо ж тільки обмежуєтесь технічним завданням, то варто описати там, що за зрив термінів, не здавання проекту, розголошення нюансів роботи третім особам, виконавець несе відповідальністьвідповідно до законодавства, але також ви можете встановити якісь свої штрафи та санкції.