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

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

Целью данной работы является ознакомление с существующими информационными технологиями, применяемыми в производстве. Рассмотрение основных информационных систем автоматизации производства актуально в течение многих лет, примерно с середины XXвека, и актуальность данной проблемы останется высокой еще в течение длительного периода, так как изменения в этой области тесно связаны с постоянными новшествами в информационных технологиях и науке. За последние годы происходили значимые изменения в области создания и разработки информационных систем: изначально информационные системы применялись лишь на производстве с большими объемами, например, на машиностроительных или оборонных заводах. Постепенная популяризация и доступность ЭВМ сделала возможной использование информационных систем и в менее крупных масштабах, при этом дав стимул для развития логической части самих систем, что будет показано ниже на примере эволюции информационной системы MRPв систему MRPII, также нельзя не заметить появление ERP, внесшее ощутимый вклад.

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

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

Успешное производство всегда зависит от не менее успешного управления. Именно на плечах управляющих лежит высокая ответственность за организацию производственных процессов, которые будут приносить прибыль для фирмы в целом. В наши дни существует около двадцати основных современных теорий автоматизации производства, которые базируются на современных информационных технологиях. Каждый подход имеет свои плюсы и минусы в определенных условиях, поэтому, полезно рассмотреть каждый из них. Также нельзя не заметить, что некоторые системы автоматизации появлялись в процессе модернизации некогда существовавших систем, но это не привело к полному отказу от изначальных разработок. Например, ERP-система (система планирования ресурсов предприятия) является логическим продолжением систем планирования материальных потребностей (MRP-системы) и систем планирования производственных ресурсов (MRPII-системы). Выбор определенной информационной системы для автоматизации производства зависит от многих факторов, среди которых можно выделить: объемы, тип, цель, потребность в автоматизации. На примере вышеупомянутых ERP-систем можно сказать, что мелкому производству вряд ли будет полезно тратить время на внедрение столь масштабной информационной системы, которая при небольшом уровне развития предприятия, будет только отнимать время специалистов, приводя к ухудшению показателей. Правильный выбор подходящей информационной системы для производства – непростое и очень важное решение, особенно в момент становления фирмы, когда ориентация под определенную модель автоматизации может определить становление всего производства. Сложные системы, обеспечивающие максимальный контроль по многочисленным направлениям, не только могут оказаться невостребованными, но и послужить одной из весомых статей расходов, что весьма нежелательно в большинстве случаев. Одной из начальных систем, сочетающей в себе успешные методы управления и невысокую стоимость внедрении, является система планирования потребности в материалах.

Система MRP (MaterialRequirementsPlanning) – планирование потребности в материалах

Данная система была разработана в США в 1950-х годах, но только через 25 лет, когда произошел бурный скачок в развитии вычислительной техники, она получила известность и последующее повсеместное распространение. К концу 1980-х годов MRPиспользовали большинство фирм в США и Великобритании. На сегодняшний день использование системы планирования потребности в материалах не актуально из-за возраста системы, но именно она является базой для большого количества ныне существующих систем автоматизации.

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

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

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

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

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

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

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

Возраст этой системы накладывает определенные недостатки, которые в ее рамках решать было нецелесообразно. Самым главным недостатком MRP-систем является большой объем обработки входных данных по сравнению с объемами информации в целом и результатами. При стремлении перейти на частые, но малые заказы, в рамках MRP-систем вряд ли удастся найти оптимальный план по расходам на обработку заказов и транспортировку, так как система изначально разрабатывалась для больших предприятий с многотысячными заказами (крупные машиностроительные заводы США).

Популярным ПО для MRP-систем некогда служил Microsoft Business Solutions-Navision, разрабатываемый с начала 1980-х годов. На сегодняшний день программы комплекс перерос в Microsoft Dynamics NAV, где MRP-модуль является отдельным подключаемым модулем.

Система MRPII (ManufacturingResourcePlanning) – планирование производственных ресурсов

На смену системе MRPпришла система планирования производственных ресурсов, названная MRPII, чтобы подчеркнуть связь систем. В новой системе было уделено внимание куда большему числу факторов, что позволило значительно расширить сферу применения и увеличить показатели. Переход от одной системы к другой был вызван не только видимыми недостатки в первоначальной MRP-системе, но и постоянно нарастающими мощностями ЭВМ. С течением времени расчеты более сложных и многоуровневых операций стали возможны на относительно дешевых компьютерах, что послужило возрастающим интересном к постоянным доработкам информационных систем. В отличие от MRP, в системе MRP II производится планирование не только в материальном, но и в денежном выражении, что позволяет охватить куда большее количество всевозможных показателей. MRPIIи на сегодняшний день представляет собой метод для эффективного планирования всех ресурсов производственной компании. Некоторые производства до сих пор не отказались от использования схемы MRPII, считая ее оптимальной информационной системой. В идеале, выполняется операционное планирование в натуральных единицах измерения, финансовое планирование в стоимостных единицах измерения, и содержит в себе возможности моделирования для ответа на вопросы «а что будет, если…?». Модель состоит из множества процессов, каждый из которых связан с другими: бизнес-планирование, планирование производства (планирование продаж и операций), разработка главного календарного плана производства, планирование потребности в материалах, планирование потребности в мощностях и системы поддержки контроля исполнения по мощностям и материалам. Результат таких систем интегрируется с финансовыми отчетами, такими как бизнес-план, отчет о соглашениях по закупкам, бюджет отгрузки и прогноз запасов в стоимостном выражении». Как видно, разница между двумя моделями ощутима, так как MRPIIоперирует куда большим количеством показателей. Различия между MRPи MRPIIможно представить в виде наглядной схемы:

На рис.1 показана схема модели MRPII, в которой при помощи овала выделены элементы системы MRP. Как видно, переход от первой модели автоматизации ко второй значительно расширяет границы обрабатываемых данных, что позволяет наладить производство оптимальным образом. Модель MRPII чувствительна к изменениям спроса в кратковременном периоде, что выгодно отличает ее от предшественницы. Стандарт программного обеспечения системы MRP II включает в себя 16 последовательных функций:

· планирование продаж и производства;

· управление спросом;

· составление плана производства;

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

· спецификации продукции;

· складская подсистема;

· отгрузка готовой продукции;

· управление производством на цеховом уровне;

· планирование производственных мощностей;

· контроль входа/выхода;

· материально-техническое снабжение;

· планирование запасов сбытовой сети;

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

· финансовое планирование;

· моделирование;

· оценка результатов деятельности.

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

Система APS (AdvancedPlanningandScheduling) – усовершенствованное планирование

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

Первая часть метода APS похожа на алгоритм MRP II. Существенное отличие заключается в том, что в системе APS согласование материалов и мощностей происходит не итеративно, а синхронно, что резко сокращает время перепланирования. Системы типа APS позволяют решать такие задачи, как «проталкивание» срочного заказа в производственные графики, распределение заданий с учетом приоритетов и ограничений, перепланирование с использованием полноценного графического интерфейса. Это особенно актуально для позаказного производства, а также в случаях жесткой конкуренции в сроках выполнения заказа и необходимости точного соблюдения этих сроков. Вторая часть метода APS - диспетчеризация производства, с возможностью учета различного рода ограничений, с элементами оптимизации. Функции APS, присущие производственным ERP-системам, пока являются относительно новыми. Тем не менее, считается, что со временем алгоритмы APS станут общепринятыми для многих производственных предприятий.

Основными компонентами системы являются: прогнозирование сбыта и спроса, основной производственный план и общее планирование загрузки производственных мощностей, планирование производства и детальное планирование загрузки производственных мощностей. Первый модуль отвечает за прогнозирование на основе истории системы. Пользователь может вносить свои корректировки в виде условий изменений рынка. В отличие от MRP II, на этом этапе возможно добиться значительного повышения скорости планирования, так как планирование возможно с одновременным учетом ограничений по мощностям и ресурсам. На практике выигрыш во времени зачастую оказывается значителен. Компонент составления производственного плана и планирования нагрузки оказывается полезен при схемах производства «на заказ», «на склад» и при непрерывном производстве. Сравнение данных по производственному плану и данных, полученных в реальном времени, позволяет выявить «узкие места» производства. Так же компонент позволяет произвести сравнение нескольких производственных планов для выявления оптимальной загрузки объектов производства. Третий компонент позволяет учитывать динамику и реальное состояние дел, чтобы формировать календарные графики в соответствии с доступностью ресурсов (оборудование, рабочая сила, хранилища, источники энергии, основные материалы). Оптимизация в системах APS базируется на эвристиках и/или на сложных математических моделях, которые создаются для конкретной отрасли (например, металлургия, прокат - оптимизация изменений толщин листов), конкретного предприятия. При этом тонкая настройка алгоритмов оптимизации может быть осуществлена непосредственно самими пользователями.

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

Одной из наиболее распространенной в мире универсальной системой планирования, полностью отвечающей критериям APS систем является продукт фирмы SAP AG Advanced Planning & Optimization или APO (в настоящее время входящий в состав программного продукта SAP SCM).

Система JIT (JustInTime) – точно в срок

Одной из широко распространенных в мире информационных моделей является модель «точно в срок» (just-in-time, JIT). Основная ее идея заключается в следующем: если производственное расписание задано, то можно так организовать движение материальных потоков, что все материалы, компоненты и полуфабрикаты будут поступать в необходимом количестве, в нужное место (на сборочной линии - конвейере) и точно к назначенному сроку для производства или сборки готовой продукции. Благодаря этому компоненты с предыдущей операции (обработка или доставка от поставщика) попадают в производство тогда и только тогда, когда в них появляется необходимость. В отличие от MRP, рассчитанной на предприятия с масштабным производством, JIT более применим для производства среднего масштаба, где происходит постоянный и непрерывный процесс производства небольших партий, что требует постоянных поставок материалов в небольшом количестве. Плюсом данного подхода можно назвать отсутствие необходимости в страховых запасах и иммобилизующих денежных средствах, но стоит сделать оговорку, что это верно для предприятий среднего и малого уровня. Данная система является успешной альтернативой MRP с определенными условиями. Простота процедур планирования поставок не совместима с крупными производствами, где планирование и контроль процессов производства находится на более высоком уровне, так как в конечном счете это негативно отразится на показателях.

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

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

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

· короткими производственными циклами;

· небольшими объемами производства готовой продукции и пополнения запасов (поставок);

· взаимоотношениями по закупкам материальных ресурсов с небольшим числом надежных поставщиков и перевозчиков;

· эффективной информационной поддержкой;

· высоким качеством готовой продукции и сервиса поставок материалов.

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

Развитие некрупных производственных компаний и относительная простота информационной системы JITне могла остаться незамеченной. Чем больше предприятий внедряют информационную систему у себя, тем больше поправок к ней может появиться. Современные технологии JIT стали более интегрированными и комбинируются из различных вариантов производственных концепций и распределительных систем, таких, как системы, минимизирующие запасы в логистических каналах, логистические системы быстрого переключения, выравнивания уровня запасов, групповые технологии, превентивное гибкое автоматизированное производство, современные логистические системы всеобщего статистического контроля и управления циклами качества продукции и т. п. Поэтому в настоящее время принято относить такие технологии к новой версии концепции «точно в срок» - концепции JIT II. Большинство информационных систем, получивших широкое распространение, постоянно улучшаются и на их основе создаются более новые и оптимальные системы, так что JITне стала исключением.

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

Ярким примером реализации информационной системы JITявляется микро-система KANBAN, ставшая одной из первых попыток практического внедрения концепции «точно в срок».

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

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

Практическое использование системы KANBAN, а затем ее модифицированных версий позволяет значительно улучшить качество выпускаемой продукции: сокращается логистический цикл, существенно повышается оборачиваемость оборотного капитала фирм, снижается себестоимость производства, а страховые запасы практически исключаются и значительно уменьшается объем незавершенного производства. Анализ мирового опыта применения микрологистической системы KANBAN многими известными машиностроительными фирмами показывает, что она дает возможность уменьшить производственные запасы на 50%, товарные - на 8% при значительном ускорении оборачиваемости оборотных средств и повышении качества готовой продукции.

Микро-система KANBAN была разработана и впервые в мире реализована фирмой «Тойота». В 1959 году эта фирма начала эксперименты с этой информационной системой и в 1962 году начала процесс перевода всего производства на этот принцип. В основе организации производства фирмы «Тойота» лежит годовой план производства и сбыта автомобилей, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основанные на прогнозировании покупательского спроса (период упреждения - 1 и 3 месяца). Суточные графики производства составляются только для главного сборочного конвейера. Для цехов и участков, обслуживающих главный конвейер, графики производства не составляются (им устанавливаются лишь ориентировочные месячные объемы производства).

ERP-системы

В соответствии со Словарем APICS (American Production and Inventory Control Society), термин «ERP-система» (Enterprise Resource Planning - Управление ресурсами предприятия) может употребляться в двух значениях. Во-первых, это - информационная система для идентификации и планирования всех ресурсов предприятия, которые необходимы для осуществления продаж, производства, закупок и учета в процессе выполнения клиентских заказов. Во-вторых (в более общем контексте), это - методология эффективного планирования и управления всеми ресурсами предприятия, которые необходимы для осуществления продаж, производства, закупок и учета при исполнении заказов клиентов в сферах производства, дистрибьюции и оказания услуг.

Аббревиатура ERP используется для обозначения комплексных систем управления предприятием (Enterprise-Resource Planning – планирование - ресурсов предприятия). Ключевой термин ERP является Enterprise – Предприятие, и только потом – планирование ресурсов. Истинное предназначение ERP - в интеграции всех отделов и функций компании в единую компьютерную систему, которая сможет обслужить все специфичные нужды отдельных подразделений.

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

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

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

ERP-система автоматизирует процедуры, образующие бизнес-процессы. Например, выполнение заказа клиента: принятие заказа, его размещение, отгрузка со склада, доставка, выставление счёта, получение оплаты. ERP-система «подхватывает» заказ клиента и служит своего рода дорожной картой, по которой автоматизируются различные шаги на пути исполнения заказа. Когда представитель представительского офиса вводит заказ клиента в ERP-систему, у него есть доступ ко всей информации, необходимой для того, чтобы запустить заказ на выполнение. Например, он тут же получает доступ к кредитному рейтингу клиента и истории его заказов из финансового модуля, узнает о наличии товара из складского модуля и о графике отгрузки товаров из модуля логистики.

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

Такова роль ERP-системы в идеале. Реальность несколько жестче. Вернемся к тем же папкам для бумаг. Этот процесс может быть и не эффективен, но зато он прост и привычен. Бухгалтерия делает свою работу, склад – свою, и если что-нибудь за стенами отдела не так, это - чужая проблема. C приходом ERP условия работы несколько меняются: теперь продавец не просто ищет клиента, набирая его данные, так как ERP-система делает из обычного продавца управляющего определенного уровня. Продавец переходит от кредитной истории клиента к ситуации на складе. Заплатит ли клиент вовремя? Сможем ли мы вовремя отгрузить? Таких решений продавцы никогда раньше не принимали, а от этих решений зависят клиенты, и зависят другие подразделения компании. И не одним только продавцам приходится проснуться – народ на складе, который раньше держал весь список товаров в голове или на клочках бумаги, теперь должен вводить его в компьютер. Если они не будут делать это регулярно и быстро, продавец скажет клиенту, что товара нет на складе, клиент отправится к другому поставщику, и компания потеряет деньги.

Ответственность, отчетность и унифицированные коммуникации никогда раньше не проверялись так жестко. Многие люди не любят перемены, даже если они нацелены на улучшения, а ERP требует изменения их стиля работы. Вот почему так трудно оценить эффект от ERP. Ценно не столько программное обеспечение, сколько перемены, которые компании должны провести в способах ведения бизнеса. Если просто устанавливать новое программное обеспечение, не изменяя принципов работы, руководство можете не увидеть никакого эффекта вообще. Наоборот, новое программное обеспечение затормозит дело –замена старой программы, которую все знают, новой, неизвестной никому. ERP является результатом сорокалетней эволюции управленческих и информационных технологий.

В 60е годы началось использование вычислительной техники для автоматизации различных областей деятельности предприятий. Тогда же появился класс систем планирования потребностей в материалах (MRP - Material Requirements Planning). В основе функционирования подобных систем лежало понятие спецификации и производственной программы (график производства). Спецификация показывало готовое изделие в разрезе входящих в него компонентов. Производственная программа содержала информацию о временном промежутке, виде и количестве готовых изделий, запланированных к выпуску предприятием. При помощи этих данных происходила процедура разузлования спецификации, на основании чего, предприятие получало информацию о потребностях в материалах для производства необходимого количества готовых изделий в соответствии с графиком. Затем, информация о потребностях преобразовывалась в серию заказов на закупку и производство. Также, в данном процессе учитывалась информация об остатках сырья и материалов на складах.

Польза от использования MRP, описанная в начале работы, высока, но несмотря на это, в системе был один существенный недостаток, а именно, - не учитывалась в своей работе производственные мощность предприятия. Это привело к расширению функциональности MRP систем модулем планирования потребностей в мощностях (CRP - Capacity Requirements Planning). Связь между CRP и графиком позволяла учитывать наличие необходимых мощностей для производства определенного количества готовых изделий. В 80х годах появился новый класс систем - системы планирования производственных ресурсов предприятия (Manufacturing Resource Planning). Из-за схожести аббревиатур такие системы стали называть MRPII. Отличия MRPIIот MRPтак же были рассмотрены нами в начале работы. Но именно MRPIIявляется предпоследней стадией появления ERP. В следствии усовершенствования систем MRPII и их дальнейшего функционального расширения появился класс систем ERP. Термин ERP был введен независимой исследовательской компанией Gartner Group в начале 90х годов. ERP системы, предназначены не только для производственных предприятий, они также эффективно позволяют автоматизировать деятельность компаний предоставляющих услуги.

Потребность в автоматизации управленческих процессов впервые была осознана в конце 60-х – начале 70-х годов, когда стало ясно, что управление крупной корпорацией подчиняется тем же законам, что и любая бюрократическая структура. Один из законов Паркинсона гласит: “штат организации никак не связан с объемом выполняемой ею работы”. Иными словами, с ростом численности управленческого персонала КПД его работы падает до нуля.

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

Заключение

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

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

Крупные производственные предприятия выбирают ERP-системы, считающиеся одним из самых оптимальных решением на сегодняшний день. Их популярность постепенно возрастает в России, в то время как на западе, ERP-системы используются довольно давно. Выбор этой системы связан с тем, что при правильном подходе она позволяет максимально полно и точно отразить все процессы внутри компании в электронном виде. Некоторые специалисты называют ERP-систему виртуальной проекцией компании в целом.

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

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

Главным же, безусловно, является набор функций ERP систем, основные из которых следующие:

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

· формирование планов продаж и производства;

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

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

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

· оперативное управление финансами, включая составление финансового плана и осуществление контроля его исполнения, финансовый и управленческий учет;

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

Поскольку основой ERP системы является находящаяся внутри неё MRP II система, то, естественно, что функции и одной и другой во многом схожи. Основными же отличиями ERP систем от MRPII систем можно считать:

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

· планирование ресурсов по различным направлениям деятельности;

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

· большее внимание подсистемам финансового планирования и управления;

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

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

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

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

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

В последнее десятилетие успешно развивались интернет технологии, позволяющие предприятиям через информационную сеть обмениваться данными и документами с покупателями и контрагентами. Новые функции работы с интернет, появившиеся в интегрированных системах управления, уже выходят за традиционные рамки ERP, замкнутой внутри производственного цикла предприятия. Сочетание традиционной ERP системы предприятия с интернет решениями для электронного бизнеса привели к созданию новой организационной и управленческой среды и нового качества системы. Результатом этого явилась концепция систем нового поколения - ERP II - Enterprise Resource and Relationship Processing - управление ресурсами и внешними отношениями предприятия, имеющих как бы два контура управления: традиционный внутренний, управляющий внутренними бизнес процессами предприятия, и внешний – управляющий взаимодействиями с контрагентами и покупателями продукции. При этом традиционный внутренний контур управления принято называть back-office - внутренняя система, а функции взаимодействия с контрагентами и заказчиками - front-office - внешняя система. Таким образом, ERP II система - это методологии ERP системы с возможностью более тесного взаимодействия предприятия с клиентами и контрагентами посредством информационных каналов, предоставляемых интернет технологиями.

Программное обеспечение для реализации ERP-систем представлено сегодня довольно широко. Одними из самых известных реализаций являются 1С: Предприятие 8.0, SAPR3, Microsoft Dynamics, Галактика, но существует еще огромное множество программ, написанных на разных языках и предоставляющих разный функционал в рамках информационных систем ERP.

Словарь основных используемых терминов

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

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

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

В. В. Трофимова «Информационные системы и технологии в экономике и управлении» – М: Юрайт, 2009 г.

Г. А. Титоренко «Информационные системы и технологии управления» – М: Юнити-Дана, 2010 г.

Д.А. Гаврилов «Управление производством на основе стандарта MRP II» – СПб: Питер, 2003 г.

Сатунин А., Карсова Е. «SAP ERP. Построение эффективной системы управления» – М: Альпина Паблишерз, 2008 г.

Когаловский М. Р. Перспективные технологии информационных систем. - М.: ДМК Пресс; М: Компания АйТи, 2003

Согласно ГОСТ 34.602-89 ТЗ должно содержать следующие разделы (приведены в сокращенном виде):

1. Общие сведения
1. полное наименование системы и ее условное обозначение;

Полное наименование системы: Автоматизированная система "Управление" Условное обозначение: АСУ

1. 1. шифр темы или шифр (номер) договора;

1. Пример:

Договор № ХХХ от ДД.ММ.ГГГГ

1. 1.наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

1. Пример:

ЗАКАЗЧИК Наименование заказчика: ООО "МИР" Юридический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Почтовый адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Фактический адрес заказчика: 142345, г. Москва, ул. Тверская, дом 15 Телефон: +7 903 456 67 67 Факс: +7 903 453 34 54 Адрес электронной почты: [email protected] ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО "БанкСтрой", г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423{{[[Шаблон:|]]}}400000000234

ИСПОЛНИТЕЛЬ Наименование исполнителя: ООО "ДЯТЕЛ" Юридический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Почтовый адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Фактический адрес заказчика: 142345, г. Москва, ул. Ленина, дом 34 Телефон: +7 495 345 63 63 Факс: +7 495 433 34 54 Адрес электронной почты: [email protected] ОГРН: 4554545445454 ИНН: 4343434345 КПП: 453345443 БАНК: ЗАО "БанкСтрой", г. Москва БИК: 444454554 РС: 564456456456454453445 КС: 43223423400000000234

1 1. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

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

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

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

1 краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

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

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

1. Требования к системе в целом;

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

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

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

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

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

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

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

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

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

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

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

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

Тридцать четвертым ГОСТом на жаргоне ИТ-специалистов называется совокупность взаимосвязанных стандартов, которые имеют номер, начинающийся на 34: ГОСТ 34.602-89, 34.003-90, 34.603-92, 34.201-89, 34.601-90, 34.698-90, 34.320-96, 34.321-96, а также руководящий документ РД 50-34.698-90 и два стоящих особняком стандарта, относящихся к узкоспециальной теме криптозащиты - ГОСТ 34.10 -01 и ГОСТ 34.11-94.

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

Чтобы понять и оценить логику, содержащуюся в семействе ГОСТ 34, проанализируем содержание составляющих его стандартов более подробно. Ориентированные на ИТ-специалистов ГОСТ 34.320-96 "Концепции и терминология для концептуальной схемы и информационной базы", ГОСТ 34.321-96. "Эталонная модель управления данными", ГОСТ 34.10 -01 "Криптографическая защита информации . Процессы формирования и проверки электронной цифровой подписи" и ГОСТ 34.11-94 "Криптографическая защита информации . Функция хэширования" я рассматривать не буду, поскольку они рассчитаны не на управленцев, а на технических специалистов. Для нас интерес представляют следующие стандарты:

• ГОСТ 34.201-89. "Виды, комплектность и обозначение документов при создании автоматизированных систем";
• ГОСТ 34.003-90 "Термины и определения";
• ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы";
• ГОСТ 34.603-92 "Виды испытаний автоматизированных систем";
• ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания";
• Руководящий документ РД 50-34.698-90 "Автоматизированные системы. Требования к содержанию документов".

ГОСТ 34.003-90, помимо того что содержит многочисленные ошибки, полностью устарел и потерял актуальность, поэтому о нем я говорить не буду. Таким образом, далее рассматривается четыре последних документа.

Стандарт ГОСТ 34.201-89

Серьезно устаревший, но отчасти пригодный для использования стандарт (ГОСТ 34, 1989а). Устанавливает соответствие документов стадиям создания АС 1АС - автоматизированная система, т. е. информационная система, разрабатываемая или внедряемая на конкретном предприятии. , описанным в ГОСТ 24.601 (впоследствии заменен на ГОСТ 34.601). По составу документов и стадиям проекта можно проследить происхождение стандарта из практики строительства. Очевидно, проектная природа строительства и деятельности по созданию информационной системы навела авторов стандарта на мысль распространить основные формы организации строительных проектов на проекты создания информационных систем. Отчасти это оказалось удобно - такие документы, упомянутые в стандарте, как " Техническое задание ", " Эскизный проект ", " Технический проект ", " Инструкция " (пользователя), " Программа и методика испытаний" прочно вошли в практику создания систем. С другой стороны, "Ведомость машинных носителей информации", "Каталог базы данных " или "Ведомость держателей подлинников" вряд ли сейчас имеют смысл. Стандарт включает также элементы практики делопроизводства в виде правил кодирования документов.

Короче говоря, при "творческом" подходе он может еще послужить, особенно в тех организациях, где проектная деятельность регулируется аналогичными проектно-ориентированными стандартами, а состав проектных документов близок к тому, что предлагает ГОСТ 34.201-89.

Стандарт ГОСТ 34.601-90

Один из наиболее применяемых до сих пор стандартов (ГОСТ 34, 1990), определяющий стадии и этапы создания автоматизированной системы. Приведенная ниже таблица является центральной в стандарте.

Таблица 2.1. Стадии и этапы создания автоматизированной системы по ГОСТ 34.601-90

Стадии	Этапы
1. Формирование требований к АС	1.1. Обследование объекта и обоснование необходимости создания АС
	1.2. Формирование требований пользователя к АС
	1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС	2.1. Изучение объекта
	2.2. Проведение необходимых научно-исследовательских работ
	2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя
	2.4. Оформление отчета о выполненной работе
3. Техническое задание	3.1 Разработка и утверждение технического задания на создание АС
4. Эскизный проект	4.1. Разработка предварительных проектных решений по системе и ее частям
	4.2. Разработка документации на АС и ее части
5. Технический проект	5.1. Разработка проектных решений по системе и ее частям
	5.2. Разработка документации на АС и ее части
	5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку
	5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация	6.1. Разработка рабочей документации на систему и ее части
	6.2. Разработка или адаптация программ
7. Ввод в действие	7.1. Подготовка объекта автоматизации к вводу АС в действие
	7.2. Подготовка персонала
	7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
	7.4. Строительно-монтажные работы
	7.5. Пусконаладочные работы
	7.6. Проведение предварительных испытаний
	7.7. Проведение опытной эксплуатации
	7.8. Проведение приемочных испытаний
8. Сопровождение АС	8.1. Выполнение работ в соответствии с гарантийными обязательствами
	8.2. Послегарантийное обслуживание

Практически все перечисленные стадии и этапы до сих пор встречаются в практике создания информационных систем предприятий и организаций. Конечно, можно критиковать стандарт за негибкость в части последовательности и названий стадий и этапов, но факт остается фактом - он продемонстрировал исключительную живучесть, и понять, в чем причина этого, гораздо важнее, чем заниматься критикой разработки почти 20-летней давности. Мне кажется, что стандарт демонстрирует точное соответствие своим целям. Во-первых, он не требует знаний в области ИТ и, следовательно, понятен обычным управленцам. Во-вторых, он компактен и прост по структуре, что позволяет человеку, не знакомому с ним, быстро войти в курс дела. В-третьих, он самодостаточен - практически никаких ссылок на смежные документы в нем нет (за исключением ГОСТ 34.201). И наконец, он практичен - сразу понятно, как его применять и как контролировать его применение.

Помимо вышеприведенной таблицы ГОСТ 34.601-90 содержит справочное Приложение 1 с поэтапной расшифровкой работ , включая указание на документы, возникающие в результате этих работ , а также Приложение 2 - "Перечень организаций, участвующих в работах по созданию АС ". Это подсказывает способ адаптации стандарта к конкретным условиям: достаточно переработать Приложения, и получится вполне разумный корпоративный стандарт на создание ИС. Причем опять-таки эта работа под силу обычному управленцу.

Стандарт ГОСТ 34.602-89

Требование "подготовить Техническое задание в соответствии с ГОСТ 34.602-89", знакомо, наверное, каждому, кто хоть однажды участвовал в заказной разработке ИС или ее приемке, да и вообще всем, кто так или иначе связан с информационными системами. Некоторые разработчики до сих пор считают хорошим тоном помнить наизусть состав Технического задания (ТЗ) в соответствии с ГОСТ 34.602-89 (ГОСТ 34, 1989б).

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

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

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

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

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

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

Приведенный отрывок демонстрирует иерархичность стандарта: система состоит из подсистем, комплексов задач, отдельных задач, функций. Чем точнее и подробнее сформулированы требования, тем более предсказуемым будет результат. Специально формулируются требования к функциям взаимодействия подсистем (сейчас мы бы сказали "к методам интеграции"), функции привязываются к плану-графику реализации системы (который тем самым также становится иерархическим). Специально упомянуты требования к качеству. Форма представления выходной информации , т.е. совокупность отчетов, также заслужила отдельного упоминания. Одним словом, представленный отрывок показывает, что разработка Технического задания в соответствии с ГОСТ 34.602-89 - непростая и очень трудоемкая работа, накладывающая серьезные обязательства не только на разработчика, но и на заказчика системы. Потенциал стандарта чрезвычайно велик, и неудивительно, что популярность его остается неизменно высокой на протяжении стольких лет.

С течением времени стали видны и оборотные стороны стандарта:

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

Стоит подчеркнуть, что, как и ГОСТ 34.601-90, ГОСТ 34.602-89 не требует специальной подготовки в области информационных технологий, поэтому контролировать соответствие ему Технического задания может обычный управленец, в задачу которого входит, например, взаимодействие с субподрядчиками. Это упрощает внедрение и практическое применение стандарта.

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

Название документа:
Номер документа:	34.602-89
Вид документа:	ГОСТ
Принявший орган:	Госстандарт СССР
Статус:	Действующий
Опубликован:
Дата принятия:	24 марта 1989
Дата начала действия:	01 января 1990
Дата редакции:	01 июня 2009

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

ГОСТ 34.602-89

Группа П87

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ

Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Information technology. Set of standards for automated systems. Technical directions for automated system making

МКС 35.080
ОКСТУ 0034

Дата введения 1990-01-01

ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. РАЗРАБОТАН И ВНЕСЕН Государственным комитетом СССР по стандартам, Министерством приборостроения, средств автоматизации и систем управления СССР

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по стандартам от 24.03.89 N 661

3. ВЗАМЕН ГОСТ 24.201-85

4. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ

	Номер пункта, приложения
ГОСТ 2.105-95
ГОСТ 2.301-68
ГОСТ 2.501-88	Приложение 1
ГОСТ 6.10.1-88
ГОСТ 6.10.4-84
ГОСТ 19.201-78
ГОСТ 34.201-89
ГОСТ 34.601-90

5. ПЕРЕИЗДАНИЕ. Июнь 2009 г.


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

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

1. ОБЩИЕ ПОЛОЖЕНИЯ

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

1.2. ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

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

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

1.3. Требования к АС в объеме, установленном настоящим стандартом, могут быть включены в задание на проектирование вновь создаваемого объекта автоматизации. В этом случае ТЗ на АС не разрабатывают.

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

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

1.5. ТЗ на АС разрабатывают на основании исходных данных, в том числе содержащихся в итоговой документации стадии "Исследование и обоснование создания АС", установленной ГОСТ 34.601 .

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

1.7. Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись "Действует с …".

2. СОСТАВ И СОДЕРЖАНИЕ

2.1. ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

2) назначение и цели создания (развития) системы;

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

7) требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8) требования к документированию;

9) источники разработки.

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

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

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

2.3. В разделе "Общие сведения" указывают:

1) полное наименование системы и ее условное обозначение;

2) шифр темы или шифр (номер) договора;

3) наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

4) перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

5) плановые сроки начала и окончания работы по созданию системы;

6) сведения об источниках и порядке финансирования работ;

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

2.4. Раздел "Назначение и цели создания (развития) системы" состоит из подразделов:

1) назначение системы;

2) цели создания системы.

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

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

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

2.5. В разделе "Характеристики объекта автоматизации" приводят:

1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

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

Примечание. Для САПР в разделе дополнительно приводят основные параметры и характеристики объектов проектирования.

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

1) требования к системе в целом;

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

3) требования к видам обеспечения.

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

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

- требования к структуре и функционированию системы;

- требования к численности и квалификации персонала системы и режиму его работы;

- показатели назначения;

- требования к надежности;

- требования безопасности;

- требования к эргономике и технической эстетике;

- требования к транспортабельности для подвижных АС;

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

- требования к защите информации от несанкционированного доступа;

- требования по сохранности информации при авариях;

- требования к защите от влияния внешних воздействий;

- требования к патентной чистоте;

Требования по стандартизации и унификации;

Дополнительные требования.

2.6.1.1. В требованиях к структуре и функционированию системы приводят:

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

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

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

4) требования к режимам функционирования системы;

5) требования по диагностированию системы;

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

2.6.1.2. В требованиях к численности и квалификации персонала АС приводят:

- требования к численности персонала (пользователей) АС;

- требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков;

- требуемый режим работы персонала АС.

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

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

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

- допустимые пределы модернизации и развития системы;

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

2.6.1.4. В требования к надежности включают:

1) состав и количественные значения показателей надежности для системы в целом или ее подсистем;

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

3) требования к надежности технических средств и программного обеспечения;

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

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

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

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

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

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

2) предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т.п.;

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

4) требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов;

5) требования к регламенту обслуживания.

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

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

2.6.1.11. В требованиях к средствам защиты от внешних воздействий приводят:

1) требования к радиоэлектронной защите средств АС;

2) требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения).

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

2.6.1.13. В требования к стандартизации и унификации включают:

показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1 *, общесоюзных классификаторов технико-экономической информации и классификаторов других категорий в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.
_____________________
* На территории Российской Федерации действуют ПР 50.1.019-2000 .

2.6.1.14. В дополнительные требования включают:

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

2) требования к сервисной аппаратуре, стендам для проверки элементов системы;

3) требования к системе, связанные с особыми условиями эксплуатации;

4) специальные требования по усмотрению разработчика или заказчика системы.

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

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

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

2) временной регламент реализации каждой функции, задачи (или комплекса задач);

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

4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

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

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

2.6.3.2. Для информационного обеспечения системы приводят требования:

1) к составу, структуре и способам организации данных в системе;

2) к информационному обмену между компонентами системы;

3) к информационной совместимости со смежными системами;

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

5) по применению систем управления базами данных;

6) к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;

7) к защите данных от разрушений при авариях и сбоях в электропитании системы;

8) к контролю, хранению, обновлению и восстановлению данных;

9) к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).

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

2.6.3.4. Для программного обеспечения системы приводят перечень покупных программных средств, а также требования:

1) к независимости программных средств от используемых СВТ и операционной среды;

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

3) по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.

2.6.3.5. Для технического обеспечения системы приводят требования:

1) к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе;

2) к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы.

2.6.3.6. В требованиях к метрологическому обеспечению приводят:

1) предварительный перечень измерительных каналов;

2) требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов;

3) требования к метрологической совместимости технических средств системы;

4) перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;

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

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

2.6.3.7. Для организационного обеспечения приводят требования:

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

2) к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

3) к защите от ошибочных действий персонала системы.

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

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

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

1) перечень документов по ГОСТ 34.201 , предъявляемых по окончании соответствующих стадий и этапов работ;

2) вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация-эксперт);

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

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

2.8. В разделе "Порядок контроля и приемки системы" указывают:

1) виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

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

3) статус приемочной комиссии (государственная, межведомственная, ведомственная).

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

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

1) приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

2) изменения, которые необходимо осуществить в объекте автоматизации;

3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;

4) создание необходимых для функционирования системы подразделений и служб;

5) сроки и порядок комплектования штатов и обучения персонала.

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

- изменения применяемых методов управления;

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

2.10. В разделе "Требования к документированию" приводят:

1) согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201 и НТД отрасли заказчика; перечень документов, выпускаемых на машинных носителях; требования к микрофильмированию документации;

2) требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

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

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

1) расчет ожидаемой эффективности системы;

2) оценку научно-технического уровня системы.

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

3. ПРАВИЛА ОФОРМЛЕНИЯ

3.1. Разделы и подразделы ТЗ на АС должны быть размещены в порядке, установленном в разд.2 настоящего стандарта.

3.2. ТЗ на АС оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней.

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

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

"Окончательное требование (значение) уточняется в процессе... и согласовывается протоколом с... на стадии...". При этом в текст ТЗ на АС изменений не вносят.

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

Форма титульного листа ТЗ на АС приведена в приложении 2. Форма последнего листа ТЗ на АС приведена в приложении 3.

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

3.6. Титульный лист дополнения к ТЗ на АС оформляют аналогично титульному листу технического задания. Вместо наименования "Техническое задание" пишут "Дополнение N ... к ТЗ на АС …".

3.7. На последующих листах дополнения к ТЗ на АС помещают основание для изменения, содержание изменения и ссылки на документы, в соответствии с которыми вносятся эти изменения.

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

ПРИЛОЖЕНИЕ 1 (рекомендуемое). ПОРЯДОК РАЗРАБОТКИ, СОГЛАСОВАНИЯ И УТВЕРЖДЕНИЯ ТЗ НА АС

1. Проект ТЗ на АС разрабатывает организация - разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т.п.).

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

2. Необходимость согласования проекта ТЗ на АС с органами государственного надзора и другими заинтересованными организациями определяют совместно заказчик системы и разработчик проекта ТЗ на АС.

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

3. Срок согласования проекта ТЗ на АС в каждой организации не должен превышать 15 дней со дня его получения. Рекомендуется рассылать на согласование экземпляры проекта ТЗ на АС (копий) одновременно во все организации (подразделения).

4. Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием. Решения по замечаниям должны быть приняты разработчиком проекта ТЗ на АС и заказчиком системы до утверждения ТЗ на АС.

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

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

7. Утверждение ТЗ на АС осуществляют руководители предприятий (организаций) разработчика и заказчика системы.

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

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

10. Согласование и утверждение дополнений к ТЗ на АС проводят в порядке, установленном для ТЗ на АС.

11. Изменения к ТЗ на АС не допускается утверждать после представления системы для ее очереди на приемосдаточные испытания.

12. Регистрация, учет и хранение ТЗ на АС и дополнений к нему проводят в соответствии с требованиями ГОСТ 2.501 .

наименование организации - разработчика ТЗ на АС
УТВЕРЖДАЮ		УТВЕРЖДАЮ
Руководитель (должность, наименование предприятия - заказчика АС)		Руководитель (должность, наименование предприятия - разработчика АС)
Личная подпись	Расшифровка подписи	Личная подпись	Расшифровка подписи
наименование вида АС
наименование объекта автоматизации
сокращенное наименование АС

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Действует с
СОГЛАСОВАНО
Руководитель (должность, наименование согласующей организации)
Личная подпись	Расшифровка подписи

СОСТАВИЛИ

	Должность исполнителя	Фамилия, имя, отчество

СОГЛАСОВАНО

Наименование организации, предприятия	Должность	Фамилия, имя, отчество

Электронный текст документа
подготовлен АО "Кодекс" и сверен по:
официальное издание
М.: Стандартинформ, 2009

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

Название документа:
Номер документа:	34.602-89
Вид документа:	ГОСТ
Принявший орган:	Госстандарт СССР
Статус:	Действующий
Опубликован:	Официальное издание. М.: Стандартинформ, 2009 год Информационная технология. Автоматизированные системы. Основные положения: Сб. ГОСТов. - М.: ИПК Издательство стандартов, 2002 год
Дата принятия:	24 марта 1989
Дата начала действия:	01 января 1990
Дата редакции:	01 июня 2009

ГОСТ 34.602-89 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы