Справочник Бухгалтера

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

Зачем нужно Техническое задание?

Многие Разработчики часто недооценивают важность технического задания, однако, ТЗ является важным, можно сказать, краеугольным документом при разработке информационных систем, сайтов, инженерных систем, да и всего чего угодно.
Сегодня, когда в моде Agile, может показаться, что ТЗ документ избыточный, но это до того момента, когда вы не столкнётесь с разработкой действительно серьёзных информационных систем, крупных программных продуктов или порталов. Объяснить на пальцах, чего бы хотелось Заказчику можно, если в системе 3-5 сущности-предмета, а если значительно больше, то обязательно что-нибудь забудется. Потом начнётся рисование на бумажке, записи на салфетках в кафе, сообщения в ватсап: «А вот неплохо было бы сделать, чтобы синие иконочки в правом углу и когда мышкой наводишь, они бы такие выезжали на центр и увеличивались!». Для того чтобы формализовать этот процесс и создаётся техническое задание, то есть документ о том, как всё должно быть.
Техническое задание выполняет ряд важных функций:

• Раскладывает в голове у Заказчика и Разработчика, то как должна выглядеть система и что она должна делать.
• Защищает Разработчика от вдруг появившихся новых требований Заказчика, то есть Разработчик должен выполнить всё то, что написано в ТЗ. Если Заказчик хочет видеть в программе ещё одну какую-либо функцию, то за неё нужно платить отдельно и составлять на неё отдельно Техническое задание.
• Защищает Заказчика от лени и некомпетентности Разработчика, то есть программа должна выглядеть именно так, как написано в ТЗ. На основании Технического задания Заказчик может предъявить претензии к Разработчику.

В общем, при разработке системы обязательно составляйте Техническое задание! Именно оно вас убережёт от проблем.

Кто составляет ТЗ?

Техническое задание — это работа не одного человека, а группы лиц:

• Аналитиков со стороны Заказчика — они определяют необходимость системы, выдвигают в письменном виде требования к новой программе.
• Аналитиков со стороны Разработчика — они должны обследовать область, по которой будет разрабатываться программа, или компанию. Учесть все схемы, алгоритмы и нюансы работы, которую будет выполнять система.
• Технический писатель — сотрудник, который соберёт все данные аналитиков и запишет их согласно ГОСТу.

Чаще всего Техническое задание, выполненное по ГОСТу — это требование органов государственной власти или крупных государственных компаний.
Написание Технического задания работа долгая и сложная. ТЗ не один раз согласовывается у руководства заказчика и разработчика, а также не раз правится и переписывается. Чтобы написать хорошее ТЗ иногда уходит месяц и больше, но лучше потратить побольше времени на написание Технического задания, чем потом доказывать, что вы хотели не так и имели в виду совершенно другое. Ведь все ошибки в Техническом задании будут стоить денег и времени Разработчику /Заказчику.

По каким ГОСТам пишется ТЗ?

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

В России Техническое задание пишется согласно двум ГОСТам:

• ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы»;
• ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».

Для создания модуля, программы, комплекса программ требуется Техническое задание по ГОСТу. Это очень важно, ведь именно там описаны все пункты, по которым впоследствии могут возникнуть споры.

Какой ГОСТ для Технического задания выбрать?

Если вы разрабатываете документацию на программу, которую создали под конкретное предприятие, то ваш ГОСТ 34. Если же пишете документы на массовую программу, то ваш ГОСТ 19.

Можно ли выбрать для тиражируемого программного продукта ГОСТ 34, а для системы под конкретную организацию ГОСТ 19? Да можно, если на этом настаивает по каким-либо причинам Заказчик. Во всех остальных случаях, лучше выбирать нужный ГОСТ, так как Пункты ГОСТов отличаются.

Чем отличаются ГОСТ 34 от ГОСТа 19 при написании ТЗ

Для удобства ниже представлена таблица пунктов ГОСТа 34 и ГОСТа 19 для написания Технического задания.

ГОСТ 19	ГОСТ 34
1. Введение	1. Общие сведения
2. Основания для разработки
3. Назначение разработки	2. Назначение и цели создания системы
	3. Характеристика объекта автоматизации
4. Требования к программе или программному изделию	4. Требования к системе
4.1. Требования к функциональным характеристикам	4.2. Требования к функциям (задачам), выполняемым системой
	4.1. Требования к системе в целом
	4.1.1. Требования к структуре и функционированию системы
	4.1.3. Показатели назначения
4.2. Требования к надёжности	4.1.4. Требования к надёжности
	4. 1.5. Требования к безопасности
	4.1.6. Требования к эргономике и технической эстетике
4.3. Условия эксплуатации	4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
	4. 1.9. Требования к защите информации от несанкционированного доступа
	4.1.10. Требования по сохранности информации при авариях
	4.1.11. Требования к защите от влияния внешних воздействий
	4. 1.12. Требования к патентной чистоте
	4.1.13. Требования по стандартизации и унификации
4.4. Требования к составу и параметрам технических средств	4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.5. Требования к информационной и программной совместимости
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению	4.1.7. Требования к транспортабельности для подвижных систем
4.8. Специальные требования	4. 1.14. Дополнительные требования
	4.3. Требования к видам обеспечения
5. Требования к программной документации	8. Требования к документированию
6. Технико-экономические показатели
7. Стадии и этапы разработки	5. Состав и содержание работ по созданию системы
8. Порядок контроля и приёмки	6. Порядок контроля и приёмки системы
	7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
	9.Источники разработки

Ниже рассмотрим каждый ГОСТ и пункты ГОСТ по отдельности.

ГОСТ 19 для Технического задания

Техническое задание по ГОСТу 19 должно содержать следующие разделы:

1. введение;
2. основания для разработки;
3. назначение разработки;
4. требования к программе или программному изделию;
5. требования к программной документации;
6. технико-экономические показатели;
7. стадии и этапы разработки;
8. порядок контроля и приёмки.

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

В разделе 1 «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

В разделе 2 «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведётся разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

В разделе 3 «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

Раздел 4 «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

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

В подразделе 4.2 «Требования к надёжности» должны быть указаны требования к обеспечению надёжного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).

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

В подразделе 4.4 «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

При необходимости должна обеспечиваться защита информации и программ.

В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

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

В разделе 5 «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.

В разделе 6 «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.

В разделе 7 «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.

В разделе 8 «Порядок контроля и приёмки» должны быть указаны виды испытаний и общие требования к приёмке работы.

В приложениях к техническому заданию, при необходимости, приводят:

• перечень научно-исследовательских и других работ, обосновывающих разработку;
• схемы алгоритмов, таблицы, описания, обоснования, расчёты и другие документы, которые могут быть использованы при разработке;
• другие источники разработки.

ГОСТ 34 для Технического задания

Техническое задание по ГОСТу 34 содержит следующие разделы, которые могут быть разделены на подразделы:

1. общие сведения;
2. назначение и цели создания (развития) системы;
3. характеристика объектов автоматизации;
4. требования к системе;
5. состав и содержание работ по созданию системы;
6. порядок контроля и приёмки системы;
7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8. требования к документированию;
9. источники разработки.

В ТЗ могут включаться приложения.

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

В ТЗ на части системы не включают разделы, дублирующие содержание разделов Технического задания на систему в целом.

В разделе 1 «Общие сведения» указывают:

• полное наименование системы и её условное обозначение;
• шифр темы или шифр (номер) договора;
• наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;
• перечень документов, на основании которых создаётся система, кем и когда утверждены эти документы;
• плановые сроки начала и окончания работы по созданию системы;
• сведения об источниках и порядке финансирования работ;
• порядок оформления и предъявления заказчику результатов работ по созданию системы (её частей), по изготовлению и наладке отдельных средств (технических, программных, информационных) и программно-технических (программно-методических) комплексов системы.

Раздел 2 «Назначение и цели создания (развития) системы» состоит из подразделов:

• назначение системы;
• цели создания системы.

В подразделе 2.1 «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается её использовать.

Для автоматизированной системы управления (АСУ) дополнительно указывают перечень автоматизируемых органов (пунктов) управления и управляемых объектов.

В подразделе 2.2 «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания автоматизированной системы (АС), и указывают критерии оценки достижения целей создания системы.

В разделе 3 «Характеристики объекта автоматизации» приводят:

• краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
• сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.

Раздел 4 «Требования к системе» состоит из следующих подразделов:

• требования к системе в целом;
• требования к функциям (задачам), выполняемым системой;
• требования к видам обеспечения.

Состав требований к системе, включаемых в данный раздел ТЗ на АС, устанавливают в зависимости от вида, назначения, специфических особенностей и условий функционирования конкретной системы. В каждом подразделе приводят ссылки на действующие нормативно-технические документы (НТД), определяющие требования к системам соответствующего вида.

В подразделе 4.1 «Требования к системе в целом» указывают:

• требования к структуре и функционированию системы;
• требования к численности и квалификации персонала системы и режиму его работы;
• показатели назначения;
• требования к надёжности;
• требования безопасности;
• требования к эргономике и технической эстетике;
• требования к транспортабельности для подвижных АС;
• требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
• требования к защите информации от несанкционированного доступа;
• требования по сохранности информации при авариях;
• требования к защите от влияния внешних воздействий;
• требования к патентной чистоте;
• требования по стандартизации и унификации;
• дополнительные требования.

В требованиях к структуре и функционированию системы приводят (пункт ТЗ 4.1.1):

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

В требованиях к численности и квалификации персонала на АС приводят (пункт ТЗ 4.1.2):

• требования к численности персонала (пользователей) АС;
• требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков;
• требуемый режим работы персонала АС.

В требованиях к показателям назначения АС приводят значения параметров, характеризующие степень соответствия системы её назначению (пункт ТЗ 4.1.3).

Для АСУ указывают:

• степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления;
• допустимые пределы модернизации и развития системы;
• вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.

В требования к надёжности включают (пункт ТЗ 4.1.4):

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

В требования по безопасности (пункт ТЗ 4.1.5) включают требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т. п.), по допустимым уровням освещённости, вибрационных и шумовых нагрузок.

В требования по эргономике и технической эстетике (пункт ТЗ 4.1.4) включают показатели АС, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала.

Для подвижных АС в требования к транспортабельности (пункт ТЗ 4.1.7) включают конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.

В требования к эксплуатации, техническому обслуживанию, ремонту и хранению включают (пункт ТЗ 4.1.8):

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

В требования к защите информации от несанкционированного доступа (пункт ТЗ 4.1.9) включают требования, установленные в НТД, действующей в отрасли (ведомстве) заказчика.

В требованиях по сохранности информации (пункт ТЗ 4.1.10) приводят перечень событий: аварий, отказов технических средств (в том числе — потеря питания) и т. п., при которых должна быть обеспечена сохранность информации в системе.

В требованиях к средствам защиты от внешних воздействий приводят (пункт ТЗ 4.1.11):

• требования к радиоэлектронной защите средств АС;
• требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

В требованиях по патентной чистоте (пункт ТЗ 4.1.12) указывают перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и её частей.

В требования к стандартизации и унификации включают (пункт ТЗ 4.1.13): показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1, общесоюзных классификаторов технико-экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.

В дополнительные требования включают (пункт ТЗ 4.1.14):

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

В подразделе 4.2 «Требование к функциям (задачам)», выполняемым системой, приводят:

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

В подразделе 4.3 «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.

Для математического обеспечения (пункт ТЗ 4.3.1) системы приводят требования к составу, области применения (ограничения) и способам, использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке.

Для информационного обеспечения системы приводят требования (пункт ТЗ 4.3.2):

• к составу, структуре и способам организации данных в системе;
• к информационному обмену между компонентами системы;
• к информационной совместимости со смежными системами;
• по использованию общесоюзных и зарегистрированных республиканских, отраслевых классификаторов, унифицированных документов и классификаторов, действующих на данном предприятии;
• по применению систем управления базами данных;
• к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
• к защите данных от разрушений при авариях и сбоях в электропитании системы;
• к контролю, хранению, обновлению и восстановлению данных;
• к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

Для лингвистического обеспечения (пункт ТЗ 4.3.3) системы приводят требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога.

Для программного обеспечения (пункт ТЗ 4.3.4) системы приводят перечень покупных программных средств, а также требования:

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

Для технического обеспечения (пункт ТЗ 4.3.5) системы приводят требования:

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

В требованиях к метрологическому обеспечению (пункт ТЗ 4.3.6) приводят:

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

Для организационного обеспечения приводят требования (пункт ТЗ 4.3.7):

• к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию;
• к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;
• к защите от ошибочных действий персонала системы.

Для методического обеспечения САПР (пункт ТЗ 4.3.8) приводят требования к составу нормативно-технической документации системы (перечень применяемых при её функционировании стандартов, нормативов, методик и т. п.).

Раздел 5 «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601, сроки их выполнения, перечень организаций — исполнителей работ, ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.

В данном разделе также приводят:

• перечень документов, по ГОСТу 34, предъявляемых по окончании соответствующих стадий и этапов работ;
• вид и порядок проведения экспертизы технической документации (стадия, этап, объём проверяемой документации, организация-эксперт);
• программу работ, направленных на обеспечение требуемого уровня надёжности разрабатываемой системы (при необходимости);
• перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).

В разделе 6 «Порядок контроля и приёмки системы» указывают:

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

В разделе 7 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» необходимо привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу АС в действие.

В перечень основных мероприятий включают:

• приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;
• изменения, которые необходимо осуществить в объекте автоматизации;
• создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
• создание необходимых для функционирования системы подразделений и служб;
• сроки и порядок комплектования штатов и обучения персонала.

Например, для АСУ приводят:

• изменения применяемых методов управления;
• создание условий для работы компонентов АСУ, при которых гарантируется соответствие системы требованиям, содержащимся в ТЗ.

В разделе 8 «Требования к документированию» приводят:

• согласованный разработчиком и Заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТа 34 и НТД отрасли заказчика;
• перечень документов, выпускаемых на машинных носителях;
• требования к микрофильмированию документации;
• требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;
• при отсутствии государственных стандартов, определяющих требования к документированию элементов системы, дополнительно включают требования к составу и содержанию таких документов.

В разделе 9 «Источники разработки» должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчёты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

В состав ТЗ на АС при наличии утверждённых методик включают приложения, содержащие:

• расчёт ожидаемой эффективности системы;
• оценку научно-технического уровня системы.

Приложения включают в состав ТЗ на АС по согласованию между разработчиком и заказчиком системы.

Написать Техническое задание — это большой труд! Главное понять, что нужно написать в ТЗ и какой для этого ГОСТ использовать. Техническое задание по ГОСТу — это не трудный, не нужный, не понятный документ, а последовательная система правил, которая позволяет рассмотреть все возможные вопросы, связанные с разработкой нового ТЗ. Не бойтесь использовать ГОСТ. ГОСТ — это не страшно, а легко и очень даже полезно!

Техническое задание — очень важный и нужный документ, который позволяет понять, как должна выглядеть новая программа, а также позволяет избежать недопонимания и разногласий. Не стоит рассчитывать на полное взаимопонимание между Заказчиком и Разработчиком. Если ТЗ написано неточно, то увеличится время на разработку новой программы, что приведёт к расходам денег и нервов. Следовательно, ТЗ несёт в себе экономию времени, денег, нервов и сил, а также Заказчик будет уверен, что получит именно ту программу, которую он просил сделать.

Надеюсь, с помощью этой статьи написать Техническое задание вам будет немножко легче!

Анастасия Степанова

Техническое задание является обязательным исходным документом для проведения работ по разработке СПИО систем автоматизации. Допускается разработка технических заданий для отдельных подсистем как составных частей технического задания на СПИО системы. Основное назначение этого документа-дать полное и однозначное предоставление цели работы, содержании, порядке ее проведения и приема-сдачи по окончании разработки СПИО АСУ ТП или ее отдельных подсистем.

Техническое задание на разработку СПИО автоматизированных систем разрабатывают на основе результатов выполненных научно-исследовательских работ, научного прогнозирования, анализа передовых достижений и технического уровня отечественных и зарубежных разработок в области АСУ ТП, а также на основе исходных требований заказчика. Техническое задание в общем случае должно состоять из следующих разделов:

• наименование и область применения;
• основание для поведения работы;
• цель и назначение работы;
• исходные данные для проведения работы;
• технические требования;
• программа поведения работы;
• порядок приема работы;
• приложение.

В зависимости от вида и назначения АСУ ТП и объема работы, подлежащих выполнению в соответствии с разрабатываемым техническим заданием, допускается уточнять содержание разделов, вводить новые разделы и объединять отдельные из них.

Наименование и область применения — указывается наименование системы, технологического объекта управления, применительно к которому должно разрабатываться СПИО, приводится краткая характеристика предполагаемой области применения.

Основание для проведения работы — указываются:

• полное наименование документа, на основании которого разрабатывается АСУ ТП, организация, утвердившая этот документ, и дата его утверждения;
• наименование и условное обозначение (код) темы работы.

Исходные данные для проведения работы — приводятся следующие данные:

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

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

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

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

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

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

Технический проект специального программного обеспечения автоматизированных систем

Документы СПИО систем автоматизации разрабатываются на основании технического задания, должны содержать все данные, необходимые для разработки рабочей документации и внедрения СПИО АСУ ТП и подразделяются на следующие группы: пояснительная записка, таблицы, расчеты, прочие документы.

Документам присваиваются обозначения, состоящие по действующей на предприятии системе из индекса предприятия, десятичной характеристики, порядкового регистрационного номер и шифр документа. Таблицам, расчетам и прочим документам присваиваются шифры согласно ГОСТ 2.102-68 ЕСКД.

Ведомость документов должна содержать перечень всех документов СПИО АСУ ТП, разработанных для технического проекта данной системы и принятых из технических проектов и рабочей документации других систем. При этом записывают только те документы, которые необходимы и достаточны для рассмотрения и утверждения технического проекта данной АСУ ТП.

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

Пояснительная записка СПИО АСУ ТП должна содержать следующие разделы:

• введение;
• описание технологического объекта управления;
• общие постановки задач управления технологическим процессом;
• описание структуры специального программного и информационного обеспечения АСУ ТП;
• постановки функциональных задач и описание структуры информационного обеспечения автоматизированных систем;
• методы и алгоритмы решения функциональных задач АСУ ТП;
• технические требования к СПИО автоматизированных систем.

Введение — содержит основные сведения о разрабатываемой системе и технологическом объекте управления, перечень документов, на основании которых разрабатываются документы СПИО АСУ ТП технический проект системы в целом с указаниями даты их утверждения. Здесь же должно быть указано назначение и область применения проектируемого СПИО систем управления технологическими процессами, сведения об использовании в документах результатов работ.

Описание технологического объекта управления содержит принципиальную схему реализации технологического процесса на технологическом оборудовании краткое содержательное описание технологического процесса как объекта управления или ссылку на документ технического проекта АСУ ТП, в котором приведено подробное его описание.

Общие установки управления технологическим процессом — раздел, в котором раскрывается сущность управления задач технологическим процессом автоматизированного технологического комплекса в содержательном и формализованном виде, включая формулировки критериев управления и характеристику управляющих воздействий на технологический объект с учетом ограничений на изменение входных и выходных параметров технологического процесса, описаны принципы декомпозиции задач управления на функциональные задачи и дано обоснование возможности и целесообразности их применимости к той ли иной задаче управления АСУ ТП. При этом в качестве функциональной задачи должна рассматриваться задача реализации тех ли иных информационных и управляющих функций системы управления (сбор, преобразование, хранение информации о состоянии технологического объекта, представление информации оперативному персоналу, выработка решений и осуществление управляющих воздействий на технологический объект управления).

Описание структуры СПИО АСУ ТП — перечень функциональных задач системы и краткое описание их логической и информационной взаимосвязи.

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

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

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

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

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

Методы и алгоритмы решения функциональных задач АСУ ТП — раздел, в котором для каждой функциональной задачи описываются метод и алгоритм ее решения, сравнительная оценка примененного метода с другими возможными методами решения и приведено обоснование его выбора, дана информационная модель, содержащая четкое изложение идей принятого метода решения задачи. Для каждого алгоритма должны быть приведены схема и ее подробное описание, а также содержательное и формализованное описание входных, промежуточных и выходных параметров. Описание каждого параметра должно содержать:

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

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

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

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

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

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

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

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

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

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

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

Технические требования к специальному программному и информационному обеспечению АСУ ТП-раздел, содержащий основные требования, которые необходимо учитывать при разработке СПО АСУ ТП (требования на язык программирования и тип вычислительного комплекса, на тип используемой операционной системы, на объем занимаемой оперативной памяти вычислительного комплекса, на содержание и состав рабочей документации и др.), а также те специфические требования к программному обеспечению АСУ ТП, которые касаются только данной конкретной системы и являются необходимыми с точки зрения разработчика системы (например, ограничения на использование устройств ввода-вывода, требования на порядок выполнения отдельных программ, на объем оперативной памяти, занимаемой отдельными программами, ограничения на время задержки при выполнении программ и др.)

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

Алгоритмы решения функциональных задач должны быть оформлены в виде формул или в виде схем в соответствии с правилами выполнения, установленными ГОСТ 19.002-80 с использованием условных графических обозначений по ГОСТ 19.003-80 и сопровождаться описаниями.

Техническое задание на автоматизированную систему управления (ТЗ на АС) – основной документ, предъявляющий требования к создаваемой автоматизированной системе и устанавливающий порядок, в соответствии с которым будет проводиться разработка АСУ ТП и ее прием при вводе в эксплуатацию.

ТЗ может разрабатываться как на всю систему, так и на составные части:

Современное техническое задание на разработку автоматизированной систему АСУ должно разрабатываться с учётом требований современного уровня развития науки и технического прогресса, а так же с учётом лучших мировых практик в области предъявляемых требований на разрабатываемые автоматизированные системы управления АСУ.

Структура и разделы

ТЗ на АСУ может содержать следующие разделы:

1) общие сведения;
2) назначение и цели создания (развития) системы;
3) характеристика объектов автоматизации;
4) требования к системе;
5) состав и содержание работ по созданию АС;
6) порядок контроля и приемки системы;
7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8) требования к документированию;
9) источники разработки.

С примерной структурой ТЗ на АСУ разработанного нашими специалистами можно ознакомиться .

Допускается разделение указанных разделов на подразделы. В зависимости от функционального назначения и условий,в которых будет функционировать АСУ, допускаются следующие действия с разделами ТЗ:

ввод дополнительных разделов (подразделов);
исключение разделов (подразделов);
объединение разделов (подразделов).
В отдельных случаях допускается оформление и разработка ТЗ в виде приложения.

Заказать разработку ТЗ

Для оформления заказа позвоните по телефону или отправьте заявку по почте. Наша компания готовы выполнить проект любой сложности.

4.1.1. Требования к характеристикам взаимосвязей создаваемой системы со смежными системами. 16

4.1.2. Требования к режимам функционирования системы.. 17

4.1.3. Требования к интеграции. 17

4.1.4. Требования по диагностированию системы.. 17

4.1.5. Перспективы развития, модернизации системы.. 18

4.2………………………………………………………………………………………. Показатели назначения. 18

4.2.1. Степень приспособляемости системы к изменению процессов и методов управления. 18

4.2.2. Допустимые пределы модернизации и развития системы.. 19

4.2.3. Вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.. 19

4.3………………………………………………………………………………….. Требования к надёжности. 20

4.4…………………………………………………………………………………… Требования безопасности. 21

4.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.. 22

4.6….. Требования к защите информации от несанкционированного доступа. 22

4.7……………………………… Требования по сохранности информации при авариях. 23

4.8………………………………………………………………………. Требования к патентной чистоте. 24

4.9……………………………………………… Требования по стандартизации и унификации. 25

5. Требования к персоналу. 27

5.1. Требования к численности и квалификации персонала системы и режиму его работ 27

5.1.1. Требования к численности персонала (пользователей) СЭД.. 27

5.1.2. Требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков. 27

5.1.3. Требования к защите от ошибочных действий персонала системы.. 29

6. Требования к видам обеспечения. 31

6.1…………………………………………….. Требования к информационному обеспечению.. 31

6.1.1. Требования к составу, структуре и способам организации данных в системе 31

6.2……………………………………………… Требования к лингвистическому обеспечению.. 32

6.3……………………… Требования к техническому и программному обеспечению.. 32

6.4……………………………. Требования к организационному обеспечению системы.. 33

6.5…………………………………… Требования к методическому обеспечению системы.. 33

7. Требования к интерфейсу. 35

8. Требования к функциям, выполняемым СЭД.. 37

8.1…………………………………………………………………………………… Управление документами. 37

8.2……………………………………………………………………………… Управление потоками работ. 40

8.3……………………………………………………………… Требования к ведению справочников. 41

8.4. Регистрация входящей/исходящей/внутренней служебной корреспонденции. Обеспечение ЖЦ входящей/исходящей/внутренней служебной корреспонденции. 42

8.5. Контроль исполнительской дисциплины входящей/исходящей/внутренней служебной корреспонденции. 45

8.6. Подготовка, согласование и регистрация организационно-распорядительных документов. 46

8.7…………………………………. Подготовка и согласование договорных документов. 47

8.8……………………………………… Подготовка и согласование закупочных процедур. 48

8.9……………………………………………… Подготовка и согласование претензий и исков. 51

8.10. Подготовка и согласование доверенностей. 53

8.11. Подготовка, согласование и утверждение документов по раскрытию информации 54

8.12. Организация и проведение совещаний. 54

8.13. Организация электронного архива документов. 54

8.14. Создание типовых отчетов, возможность модификации ранее созданных шаблонов и печатных форм. 55

8.15. Аутентификация и права доступа пользователей. Обеспечение регламентирования доступа пользователей к данным системы.. 55

8.16. Шифрование и защита данных. Использование ЭЦП и средств шифрования 56

8.17. Поиск документов и других объектов системы.. 56

8.18. Классификаторы и справочники. Обеспечение импорта данных средствами СЭД 59

8.19. Требования к поддержке web клиентов. 59

8.20. Требования к настройке и модификации Системы.. 60

8.21. Реализация архитектурных принципов СЭД.. 60

9. Состав и содержание работ по созданию системы.. 63

10. Порядок контроля и приёмки системы.. 65

11. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие. 66

12. Требования к документированию.. 67

13. Источники разработки. 68

1. Общие сведения

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

1.1. Полное наименование Системы и ее условное обозначение

Полное наименование: Система электронного документооборота .

Сокращенное наименование системы в рамках этого документа: СЭД.

1.2. Сведения о Заказчике и Исполнителе

Заказчик: Открытое Акционерное Общество «Теплоэнерго».

Исполнитель: определяется по итогам процедуры закупки.

1.3. Плановые сроки выполнения работ

В течение 6 месяцев с момента двустороннего подписания Договора.

Точные плановые сроки начала и окончания работ определяются Договором на создание СЭД между Заказчиком и Исполнителем.

1.4. Источники и порядок финансирования работ

Финансирование работ осуществляется за счет средств Заказчика. Финансирование осуществляется в порядке, определенном Договором на выполнение работ по созданию и внедрению СЭД между Заказчиком и Исполнителем.

1.5. Порядок оформления и предъявления Заказчику результатов работ

Порядок оформления и предъявления Заказчику результатов работ по созданию и внедрению СЭД устанавливаются в соответствующем разделе настоящего Технического задания.

1.6. Список терминов и обозначений

Принятые сокращения:

БД – база данных

ИКТ — информационно-коммуникационные технологии

ОС – операционная система

ПИР – претензионно-исковая работа

ПО – программное обеспечение

СКЗИ – средства криптозащиты информации

СУБД – система управления базами данных

ТЗ – техническое задание

Используемые в тексте ТЗ термины:

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

Доверенность — письменное уполномочие, выдаваемое одним лицом другому лицу для представительства перед третьими лицами.

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

Документ – зафиксированная на материальном носителе информация с реквизитами, позволяющими ее идентифицировать (Федеральный закон «Об информации, информатизации и защите информации» (1995), ГОСТ Р «Делопроизводство и архивное дело. Термины и определения»).

Документ в электронном виде – регистрационная карточка (РКК) документа с основным реквизитами документа и отсканированный образ документа.

Документационное обеспечение управления (ДОУ) — отрасль деятельности, обеспечивающая документирование и организацию работы с официальными документами.

Документооборот – процесс обработки документов по определенным правилам, обеспечивающий прохождение документов по определенным маршрутам: прием, регистрация, рассылка, поиск, выдача поручений, контроль исполнения документов, формирование дел, хранение документов.

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

Ключевые пользователи — участвуют в разработке и согласовании проектных решений, тестовой эксплуатации, согласовании изменений бизнес-процессов по ее результатам.

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

Организационно-распорядительный документ (ОРД) — документ, посредством которого осуществляется административная деятельность в организации (приказы, распоряжения, решения, штатное расписание, должностные инструкции, положения, инструкции, регламенты).

Регистрация документа – запись учетных данных о документе по установленной форме, фиксирующая факт его создания, отправления или получения (ГОСТ Р «Делопроизводство и архивное дело. Термины и определения»).

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

Реквизит документа – обязательный элемент оформления официального документа (ГОСТ Р «Делопроизводство и архивное дело. Термины и определения»).

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

Система электронного документооборота (СЭД) – информационная система документооборота и делопроизводства, предназначенная для обработки документов в электронном виде, в том числе позволяющая организовать обработку электронного документа.

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

Электронный документ (ЭД) – документ, в котором информация представлена в электронно-цифровой форме.

Электронно-цифровая подпись (ЭЦП) – реквизит электронного документа, предназначенный для защиты данного электронного документа от подделки, полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной подписи и позволяющий идентифицировать владельца сертификата ключа подписи, а также установить отсутствие искажения информации в электронном документе.

2. Назначение и цели внедрения системы

СЭД предназначена для комплексной автоматизации документооборота (хранения, доступа, движения и обработки документов) и делопроизводства (ДОУ) в структурных подразделениях заказчика.

Основным назначением СЭД является автоматизация следующих процессов ОАО «Теплоэнерго»:

• регистрация входящих документов, вынесение резолюций;

• подготовка, согласование и регистрация исходящих документов;

• подготовка, согласование и регистрация внутренних документов (служебные записки, справки, актыи);

• подготовка, согласование и регистрация организационно-распорядительных документов (приказы, распоряжения, решения, штатное расписание, должностные инструкции, положения, инструкции, регламенты);

• ознакомление и контроль исполнения по приказам и распоряжениям;

• согласование договорных документов (договоры, дополнительные соглашения, протоколы разногласий, протокол урегулирования разногласий, приложения к договорным документам, соглашения о расторжении);

• контроль исполнительской дисциплины;

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

• подготовка и согласование претензий и исков;

• подготовка и согласование доверенностей;

• подготовка, согласование и утверждение документов по раскрытию информации;

• организация и проведение совещаний;

• организация и ведение электронного архива документов.

Создание СЭД призвано обеспечить повышение оперативности и качества работы с документами, снижение трудозатрат и сокращение издержек на управление, усиления контроля исполнительской дисциплины и создание условий для перехода от традиционного бумажного документооборота к электронному документообороту. СЭД должна создать необходимые условия для повышения доли интеллектуального производительного труда по содержательной и смысловой работе с документами и снижения трудозатрат на рутинные операции.

Целями внедрения системы электронного документооборота в ОАО «Теплоэнерго» являются:

1. Сокращение времени на создание и поиск документов за счет использования типовых шаблонов и ранее созданных документов, а также единого структурированного хранения документов с возможностью поиска по ключевым полям и тексту документов.

2. Упорядочивание работы с документами за счет использования типовых шаблонов, типовых маршрутов и введения в действие инструкций по работе с документами.

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

4. Сокращение потерь документов за счет:

● хранения документов в едином электронном архиве;

● минимизации передачи бумажных документов;

● ведения регистрационных карточек на существующие бумажные документы.

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

6. Ускорение документооборота за счет:

● автоматического перемещения документов между сотрудниками;

● отсутствия необходимости физического размножения и перемещения бумажных копий документов;

● возможности параллельной рассылки документа;

● возможности задания маршрута и контроля перемещений бумажного документа в системе без дополнительной регистрации и без передачи бумажных документов курьерами.

7. Сокращение бумажного документооборота за счет:

● перевода внутренних управляющих документов в электронный вид и использования ЭЦП;

● рассылки документов исполнителям в электронном виде вместо копирования документов с резолюциями и печати РКК;

● единого общедоступного хранилища документов, исключающего необходимость их копирования для использования несколькими сотрудниками.

8. Повышение безопасности данных за счет разграничения прав доступа на уровне каждого документа.

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

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

В результате достижения указанных целей повышается эффективность управления организацией в целом.

Для реализации поставленных целей СЭД должна решать следующие задачи:

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

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

· автоматическая рассылка напоминаний о приближении срока исполнения документа;

· контроль исполнения поручений/резолюций руководства по входящим и внутренним документам;

· работа с исходящими документами: разработка, согласование, подписание и регистрация документа, организация отправки адресату и формирование реестра почтовых отправлений;

· подготовка, согласование, контроль сроков согласования, устранение замечаний, подписание и регистрация договоров, ведение электронного архива договорных документов, хранение шаблонных текстов договорных документов, контроль выполнения обязательств по договору;

· подготовка и согласование закупочной документации, контроль сроков рассмотрения, создание реестра проведенных закупочных процедур и архива закупочной документации;

· подготовка и согласование претензионно-исковой документации, контроль сроков ПИР;

· подготовка, согласование, подписание, регистрация, выдача и хранение доверенностей;

· организация и подготовка совещаний, фиксация и контроль исполнения принятых решений, автоматическое формирование и согласование протокола совещания;

· выполнение поисков электронных документов и РКК по различным параметрам;

· организация работы с номенклатурой дел (создание, изменение, хранение, списание, уничтожение);

· автоматическое формирование запроса отчёта о ходе исполнения конкретного поручения;

· автоматическая рассылка напоминаний о приближении срока исполнения поручения;

· подготовка и контроль отправки ответа корреспонденту;

· поиск поручений, а также связанных с ними документов;

· подготовка отчётности по работе с поручениями в различных разрезах;

· подготовка отчетности по документообороту организации;

· контроль исполнительской дисциплины;

· получение необходимых стандартных форм и журналов.

3. Характеристика объекта автоматизации

3.1. Общие сведения

Объектом автоматизации являются процессы документационного обеспечения управления .

– основной поставщик тепловой энергии в Нижнем Новгороде. На долю предприятия приходится более 60% объема услуг по обеспечению теплом и горячей водой.

Единственным акционером Общества является муниципальное образование городской округ «город Нижний Новгород».

3.2. Организационно-территориальная структура

территориально имеет следующие офисы:

· г. Нижний Новгород, бульвар Мира, 14 – Центральный офис;

· 0/16.

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

3.3. Объем документооборота

Ориентировочный годовой объем документооборота в приведен в Таблице 2.

Таблица 1. Сведения о документообороте

Параметр	Значение
Входящая корреспонденция	28 000 документов/год
Исходящая корреспонденция	27 000 документов/год
Договорные документы	2 400 документов/год
Распорядительные документы	350 документов/год
Справочно-информационные	6 150 документов/год
ИТОГО	63 900 документов/год

3.4. Текущая практика автоматизируемой деятельности

Порядок организации документационного обеспечения управления в организован в соответствии с ГОСТ Р6.30-2003 и Инструкцией по делопроизводству в , утвержденной приказом генерального директора 07.07.2010 № 000/п (далее – Инструкция по делопроизводству).

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

4. Требования к системе

4.1. Требования к структуре и функционированию системы

4.1.1. Требования к характеристикам взаимосвязей создаваемой системы со смежными системами

СЭД должна обеспечивать взаимодействие с другими системами и обеспечивать доступ к информации, хранящей в базе данных, следующими средствами:

· межпрограммное взаимодействие (API – Application Programming Interface);

· обмен данными на уровне файлов, например, в текстовом или XML формате;

· использование прямых SQL-запросов для получения данных из СУБД других систем.

Перечень функционирующих информационных систем в :

1. 1С 8.2 «Управление производственным предприятием» – система управления ресурсами предприятия.

2. 1С 8.2 «Зарплата и управление персоналом» – система управления персоналом, кадрового учета, расчета зарплаты.

3. 1С 8.2 «Управление сбытом тепловой энергии».

4. «Служебная корреспонденция» – система учета корреспонденции и контроля исполнения резолюций.

5. «Согласование договоров» – система контроля этапов согласования договорных документов.

6. «Приказы» – система контроля этапов согласования и исполнения приказов.

7. DocsVision – автоматизация управления архивом документации по потребителям.

4.1.2. Требования к режимам функционирования системы

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

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

Конкретное содержание функций, исполняемых в рабочем режиме и в режиме проведения регламентных работ, описывается в эксплуатационной документации Исполнителя, в регламенте обслуживания СЭД.

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

4.1.3. Требования к интеграции

Такие справочники СЭД, как «Договоры» и «Контрагенты», должны синхронизироваться с соответствующими справочниками и данными системы 1С для поддержания актуального состояния.

4.1.4. Требования по диагностированию системы

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

Система должна гарантировать отсутствие потерь и искажений документов с помощью механизма контрольных сумм.

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

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

4.1.5. Перспективы развития, модернизации системы

В системе должны быть предусмотрена возможность её последующей модификации на уровне прикладных задач в рамках дальнейшего развития функциональной применимости системы Заказчиком при минимальных временных и финансовых затратах.

Развитие системы может осуществляться по двум направлениям:

· территориальное масштабирование, т. е. подключение к системе новых объектов или внедрение системы в подчинённых структурных подразделениях (отделах, секторах и т. д.) на подключённых объектах;

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

4.2. Показатели назначения

4.2.1. Степень приспособляемости системы к изменению процессов и методов управления

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

Адаптация системы должна достигаться следующими средствами:

· средства гибкой настройки, изменений и проверки процессов ДОУ;

· создание новых справочников (словарей, классификаторов) и адаптация существующих под требования ;

· создание новых отчётов и адаптация существующих под требования ;

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

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

4.2.2. Допустимые пределы модернизации и развития системы

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

4.2.3. Вероятностно-временные характеристики, при которых сохраняется целевое назначение системы

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

4.3. Требования к надёжности

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

Надёжность системы в целом определяется надёжностью функционирования составляющих её компонент:

Техническое обеспечение:

· сервер;

· рабочие станции;

· сетевое аппаратное обеспечение;

· печатающие устройства и сканирующие устройства;

· сетевые кабельные соединения;

· устройства бесперебойного питания.

Программное обеспечение:

· общесистемное ПО, установленное на сервере и рабочих станциях;

· прикладное ПО, установленное на сервере и рабочих станциях;

· ПО общего назначения, установленное на рабочих станциях.

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

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

Помимо технического и программного обеспечения надёжность системы определяется следующим:

· выбором отказоустойчивого оборудования и его структурным резервированием;

· использованием источников бесперебойного питания;

· выбором топологии телекоммуникационной и локальных вычислительных сетей, обеспечивающих вариантность маршрутизации потоков информации;

· дублированием носителей информации;

· правильной установкой и эксплуатацией технических и программных средств;

· наличием подготовленного, квалифицированного персонала, обслуживающего систему;

· соблюдением организационных и организационно-технических мероприятий;

· своевременным и правильным выполнением регламентных работ.

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

Система должна обеспечивать восстановление работоспособности при появлении сбоев, аварий и отказов, возникающих на сервере и сетевом аппаратном обеспечении.

Система должна обеспечивать сохранность данных при сбоях в электропитании технических средств системы.

Система в целом должна сохранять работоспособность при некорректных действиях конечных пользователей:

· ввод некорректных данных;

· неверный выход из системы (завершение работы с системой) на рабочей станции.

4.4. Требования безопасности

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

4.5. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

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

Для обеспечения целостности данных базы данных системы необходимо производить периодическое резервное копирование баз данных. Резервное копирование и восстановления должно производиться на сервере средствами ОС или СУБД. Выполнение процедур копирования и восстановления данных должно обеспечиваться администратором системы.

Регламент обслуживания СЭД определяется дополнительными документами, выпускаемыми перед началом эксплуатации системы.

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3

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

«Техническое задание нужно ВАМ, а не НАМ»

Один из первых этапов любой автоматизации — техническое задание (ТЗ). Даже если стоит небольшая задача — создаётся небольшое ТЗ. Но создаётся. Иногда, на старте общения, происходит возражение Заказчика (Заказчиком может быть стороннее юридическое лицо, либо соседнее подразделение, либо головная компания холдинга), что документ им не нужен — они и так всё знают. Их позиция, что ТЗ требуется лишь Исполнителю, по которому он будет реализовывать задачу.

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

Приведу небольшой пример диалога:

_____

Заказчик: — Нам необходим простой «Монитор производства», в котором мы видели бы текущее состояние производства.

Я: — Что должен содержать монитор?

— Текущие производственные заказы и их состояние.

— Под состоянием вы понимаете признак производственного документа или текущая операция?

— Ээээ… … Текущая операция.

— Вы ведёте учёт по полуфабрикатам и по операциям?

— Только полуфабрикаты, но хотим учитывать и операции.

Дальше диалог сводится к длительному обсуждению количественного учёта, отображению рабочих центров, производства брака и пр. Всего этого Заказчик не предполагал до начала беседы, но полагал, что знает все свои потребности (и я его понимаю).

_____

На основании приведённого диалога:

• в документе Технических требований вы опишите: Система должна содержать «Монитор производства» с отображением данных: производственный заказ, состояние, количество, текущая операция.
• в документе Техническое задание это будет описано структурно с деталями выводимых полей и функциональных опций.

Чтобы прийти к данному виду потребуется ряд рабочих встреч.

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

В каком случае не требуется ТЗ — когда заказчик и исполнитель один человек.

Оценка драйверов и саботажников проекта

В статье про провалы я писал ситуации про саботажников, незаинтересованность руководства и увлёченность руководства политическими играми, поэтому залезать в проект без сильного административного ресурса Заказчика выглядит самоубийством. На этапе проектирования ТЗ вы проведет рекогносцировку драйверов и саботажников и поймёте кто будет помогать проекту, а кто его топить. И те и другие однозначно будут на проекте, а иногда в одном лице в виде рефлексирующего ЛПРа. Но это уже вопрос психоанализа.

Добавлю лишь слова Доктора Курпатова, что «80% времени топ-менеджеры тратят на интриги».

ТЗ по подсистемам или единое?

Однозначного ответа нет. Совокупность выявленных факторов может подтолкнуть как комплексному, так и лоскутному варианту разработки ТЗ (scrum, agile).

К комплексному ТЗ склоняют факторы:

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

К лоскутному ТЗ склоняют факторы:

• возможность обособить вид процессов для отдельного ТЗ;
• исследовательские и экспериментальные цели;
• сомнительное отношение ответственного лица;
• короткие процесс согласования проектной и финансовой документации.

Если это крупная организация со сквозными бизнес-процессами между подразделениями, то может подойдет комплексное ТЗ, который будет служить как клей для объединения.

Подробнее на данную тему почитайте в этой статье.

Подготовка стартовой документации до начала ТЗ

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

Недавно, на поступивший запрос автоматизации складских процессов среднего производственного предприятия я пренебрег ТТ и приступив к реализации ТЗ. Требования которые были озвучены вначале раздулись в процессе обследования и добавлены новыми работам по запуску базы конструкторской документацией и её интеграции со складской программой. Аппетит приходит во время еды и Заказчик очень быстро забудет первоначальные пожелания.

В финансовом плане вы не пострадаете (если комплексное ТЗ), но вам будет сложнее сдержать слова по прогнозу сроков и бюджета проекта, при отсутствии подписанной бумажки ТТ с начальными «хотелками».

«Мины на исследовании бизнес-процессов»

Так я назову взрывные и неадекватные реакции сотрудников на которые вы напарываетесь в процессе исследования бизнес-процесса.

– Здравствуйте, меня зовут Сергей Куканов. В настоящее время я выполняю обследование вашего предприятия с целью дальнейшей автоматизации бизнес-процессов и запуска новой системы. Я бы хотел с вами поговорить о ваших функциональных обязанностях. В процессе беседы буду делать заметки, запрашивать копии документов, которые попадут в отчёт об обследовании и техническое задание. Расскажите немного о вашей работе.

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

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

Особенности разработки технического задания на автоматизацию (на примере 1С УНФ)