Автоматизация потоков документации — важный шаг к созданию ЕИП СПб ОАО «Красный Октябрь»

Алексей Рындин
Руководитель отдела электронного архива и документооборота, «CSoft — Бюро ESG»
Ольга Галкина
Специалист отдела электронного архива и документооборота, «CSoft — Бюро ESG»
Александр Благодырь
Специалист отдела электронного архива и документооборота, «CSoft — Бюро ESG»
Наталья Кораго
Руководитель проектов отдела электронного архива и документооборота, «CSoft — Бюро ESG»

Основные проблемы при организации хранения и управления информацией в электронном виде

СПб ОАО «Красный Октябрь» специализируется на производстве, ремонте и обслуживании силовых агрегатов для вертолетов «Ми» и «Ка», коробок самолетных агрегатов (КСА), газотурбинных двигателей­энергоузлов и турбостартеров (ГТДЭ и ВК) для самолетов «МиГ» и «Су». Продукция «Красного Октября» эксплуатируется более чем в 80 странах мира. Отделение мототехники выпускает двух­ и четырехтактные двигатели, мотоблоки и мотокультиваторы «Нева», мотонасосы и другие товары народного потребления. Предприятие осуществляет полный цикл создания продукции — от проектирования и опытного производства до серийного изготовления. Оно обладает полным технологическим циклом машиностроительного производства.

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

Рис. 1. Основные потоки, образующие информационное пространство СПб ОАО «Красный Октябрь»

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

• несколько потоков конструкторской и технологической документации (далее КД и ТД), а также нормативно­справочная документация (далее НТД):

- поток КД и ТД от внешних проектантов и производителей техники. До недавнего времени это были документы на бумажных носителях. Начиная с 2011 года ряд авиационных КБ вместо традиционной бумаги, руководствуясь новой нормативной базой, поставляет конструкторскую информацию с использованием 3D­моделей. В поток КД и ТД от внешних проектантов и производителей техники включаются извещения об изменении. Особенностью рассматриваемого потока является его тесная связь с другим, казалось  бы, далеким от технической документации административным документооборотом (более подробно на данной теме остановимся далее),

- поток КД и ТД, разрабатываемой непосредственно на предприятии. К подобной документации относятся документы, создаваемые в АКБ, ОГТ и конструкторами литейного производства. Несмотря на различное назначение разрабатываемой КД и ТД, бизнес­процессы, связанные с ее созданием в перечисленных подразделениях, можно и нужно было стандартизировать,

- поскольку предприятие имеет парк станков с ЧПУ, существует поток, связанный с разработкой программ для этого оборудования. На первый взгляд, поскольку программа для станка — не КД и не ТД в привычном понимании, проблема автоматизации этого потока неактуальна. На практике же речь идет о необходимости, во­первых, сбора информации о жизненном цикле изделия, в том числе на стадии производства; во­вторых, на производстве необходимо, как минимум, упорядочение процессов разработки и обращения программ для станков с ЧПУ по простой причине: исключение брака при неправильно установленной программе для станка с ЧПУ или несанкционированной ее корректировке. О прочих задачах, решаемых попутно при внедрении системы управления разработкой, учетом и оборотом программ для станков с ЧПУ, мы более подробно расскажем далее, при описании соответствующей подсистемы,

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

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

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

• данные аспекты были, есть и будут;
• информационные потоки, связанные с этими аспектами, также имеют связи с описанными документопотоками;
• необходима не только автоматизация этих аспектов (которая успешно проводится на предприятии), но и установка связей между финансово­экономической, складской информацией и потоками КД, ТД, административных и прочих документов в рамках ЕИП.

Электронный архив КД и ТД

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

Оцифровка КД и ТД на бумажных носителях

Для перевода информации в электронный вид предприятием были закуплены сканеры. Причем для сканирования (в том числе поточного) форматов до А3 включительно используются сканеры Fujitsu, обеспечивающие неплохой результат даже при сканировании «синек» и калек. Для широких форматов был приобретен сканер Contex, а несколько позже — репрокомплекс Océ. Поставку, инсталляцию, необходимую поддержку, а в дальнейшем и сервисное обслуживание оборудования осуществляет ООО «СиСофт — Бюро ЕСГ».

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

В связи с этим было закуплено и внедрено специализированное программное обеспечение производства компании «СиСофт» — RasterID. Это ПО предназначено для повышения качества изображений. В отличие от более широко позиционируемых пакетов обработки электронных образов, RasterID является специализированным ПО, ориентированным на повышение качества изображений, прежде всего полученных при сканировании КД и ТД. Например, используются возможности устранения засветок от калек, фильтрация (в том числе и по цвету) типичной «грязи», которую все видели на «синьках». Существует множество опций по повышению качества, которые можно как вызывать для одного изображения, так и записывать. Файл, содержащий запись последовательных команд по обработке, используется для выполнения набора типизированных операций в пакетном режиме. Одной из специализированных функций ПО RasterID является распознавание полей угловых штампов с последующей записью результатов в табличные форматы, позволяющие формировать БД.

Организация процесса хранения

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

При такой организации хранения рано или поздно (по мере накопления информации) наступает день, когда возможности операционных и файловых систем по упорядочению иссякают, а поиск конкретного отсканированного чертежа требует неприемлемого времени. В такой ситуации, как правило, представители ИТ­подразделений рассматривают вопрос об использовании современных СУБД, позволяющих заметно облегчить сложившуюся ситуацию. В настоящее время взоры обращаются к СУБД, которые обычно используются в работе других систем предприятия, например бухгалтерских, складских, ERP­системах и т.д. Как правило, наиболее распространены СУБД Microsoft SQL Server и Oracle. На СПб ОАО «Красный Октябрь» — MS SQL Server.

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

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

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

На этапе создания электронного архива были реализованы:

• централизованный учет и хранение сканированной КД и ТД в единой БД TDMS;
• процессы занесения документации;
• процессы доступа пользователей к разделам информации с учетом прав;
• процессы учета изменений (извещения на изменения, версионность, учет измененных документов).

К великому сожалению, базовый программный продукт TDMS по умолчанию не имеет системы веб­доступа. В связи с этим была поставлена задача организации быстрого доступа к КД и ТД, в том числе из цехов. При этом требования к функционалу рабочих мест, с которых должен осуществляться такой доступ, сводились лишь к возможности быстрого поиска и вывода на экран необходимого чертежа. Результатом выполнения такой задачи стала система веб­доступа к БД TDMS, разработанная компанией «СиСофт — Бюро ЕСГ». При этом на рабочем месте не требуется инсталляция ПО. Работа производится в окне стандартного Internet Explorer.

Управление потоками КД и ТД

Следующей ступенью развития системы была автоматизация управления потоками КД и ТД, в основном в процессе ее разработки. Часто употребляется термин «конструкторский документооборот», что в целом не противоречит понятию «управление потоками КД и ТД», поэтому будем применять оба термина.

Переход на новый уровень подразумевал не только реализацию конструкторского документооборота, но и сохранение результатов работ на предыдущей ступени. Иными словами, система электронного архива является базисом, фундаментом, а система конструкторского документооборота — надстройкой. Все автоматизируемые процессы управления потоками КД и ТД на рассматриваемой ступени автоматизации (конструкторский документооборот) находят свое продолжение в системе электронного архива. Такое продолжение не является лишь логическим (КД и ТД сначала разрабатываются, потом передаются в архив). Поскольку система создана в единой среде программного комплекса TDMS, поступление в электронный архив результатов разработки КД и ТД осуществляется в единой БД.

При автоматизации управления потоками КД и ТД на предприятии особое внимание было уделено процессам разработки в следующих подразделениях:

• АКБ;
• КБ литейного производства;
• конструктора оснастки.

На первый взгляд перечисленные подразделения решают совершенно разные задачи и каждое из них требует особого подхода. Тем не менее представителям предприятия совместно с «СиСофт — Бюро ЕСГ» удалось описать существующие бизнес­процессы по разработке КД и предложить оптимизированную схему работы, отражающую потребности для решения задач всех подразделений. Забегая вперед, отметим, что для успешного решения задач автоматизации (и не только на этом этапе) важным фактором успеха явилась разработка необходимой нормативной базы предприятия — стандартов (СТП), положений, инструкций.

При разработке системы управления потоками КД и ТД требуется организация интерфейсного взаимодействия между средствами разработки — САПР и системой конструкторского документооборота. При этом возникают различные задачи, позволяющие исключить дублирующие друг друга действия в САПР и системе управления потоками КД и ТД. К таким действиям, например, можно отнести заполнение информации в угловом штампе чертежа с использованием двумерных САПР и заполнение полей учетной карточки того же чертежа в системе конструкторского документооборота (поля и их значения одинаковы). В качестве другого примера приведем создание структуры изделия в 3D­САПР и создание структуры изделия в системе конструкторского документооборота. Можно вспомнить еще множество примеров. Вместо этого сформулируем основной подход, реализованный при организации программного взаимодействия: информация вводится однократно, после чего в необходимом объеме передается в другие системы. Причем не следует забывать великий принцип «кесарю кесарево, а Богу Богово». Иными словами, если конструкторы при работе заполняют угловой штамп в 2D­САПР и строят структуру изделия в 3D­САПР, то пусть всё так и остается. При этом информация из САПР передается в систему TDMS (в нашем случае). Если же процессы обмена конструкторской и технологической информацией, управление ее потоками умеет хорошо осуществлять система конструкторского документооборота, реализованная в среде TDMS, то пусть она это и делает с полученной от САПР информацией (файлами, атрибутивными параметрами, структурами, электронными документами и т.д.).

На основании описанного подхода реализовано программное взаимодействие со средствами разработки КД и ТД предприятия — КОМПАС и SolidWorks. Для решения задач интерфейсного взаимодействия системы TDMS с САПР на предприятии используется специальное приложение «Навигатор СП».

Автоматизация процессов разработки и управления обращением программ для станков с ЧПУ

Доселе мы умышленно не употребляли термины «PDM» и «PLM». Это связано отнюдь не с непониманием и непродвинутостью авторов в этих понятиях. Скорее наоборот. Дело в том, что, к сожалению, очень часто мы сталкиваемся с подменой понятий некоторыми поставщиками и производителями решений, когда, например, делаются громкие заявления о внедрении PLM­системы. При детальном изучении такой системы оказывается, что решены лишь задачи на стадии жизненного цикла проектирования, частично производства. При этом, как правило, такая PLM­система функционально ограничена одной САПР, являясь ее «довеском» от производителя. Компания­поставщик быстро напишет любой интерфейс. Часто такая PDM/PLM по своей идеологии далека от принятых у нас принципов разработки КД и ТД. При этом, кроме «конструкторско­технологических», нередко забывают о весьма существенных аспектах управления информацией в процессе жизненного цикла изделия. К таким аспектам относятся, например, логистическая поддержка, эксплуатационная информация и документация, расписания и описания регламентов, электронные руководства и т.д. Описанные причины заставляют нас быть более осмотрительными в своих заявлениях, и вместо употребления терминов «PDM» и «PLM» мы будем говорить лишь о некоторых функциях или элементах PDM и PLM.

Ведя речь о накоплении информации об изделии и реализации ряда PDM­ и PLM­функций не на словах, а на деле, обратим внимание читателей, что помимо КД и ТД на стадиях проектирования, производства, модернизации ЖЦ изделия существует еще достаточно специфичный, но присущий высокотехнологичным отраслям пласт информации, связанный с производством. Это  программы для станков с ЧПУ.

Кроме организации учета и хранения программ для станков с ЧПУ и автоматизации их «движения» (прохождения контрольных точек в процессе разработки), в системе особое внимание уделено учету обращения программ, внесению изменений, исключению брака. Подробно останавливаться на описании процесса учета изменений, учета версий программ для станков с ЧПУ под управлением системы мы не будем, поскольку бизнес­процессы во многом схожи с процессами учета, хранения, разработки, проведения изменений в КД и ТД.

Подробнее рассмотрим следующую ситуацию: программа для станка с ЧПУ в любом случае перед использованием отчуждается от системы. После такого отрыва (записи на внешний носитель) программа загружается в станок. При этом в период между отчуждением и запуском станка по программе возможны следующие варианты:

• несанкционированные и неучтенные изменения с использованием ПК;
• несанкционированные и неучтенные изменения параметров обработки изделия в программе «на станке».

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

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

- программа со станка с ЧПУ подлежит считыванию на внешний носитель;

- внешний носитель подключается к ПК с клиентским местом системы управления разработкой и обращением программ для станков с ЧПУ;

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

- вступают в силу организационно­распорядительные документы и процедуры.

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

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

Взаимодействие административного и технического потоков документов

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

• компании, не имеющие дела с автоматизацией проектирования, САПР, автоматизацией производственной деятельности, а, как правило, занимающиеся «документооборотом», продвигают решения, предназначенные для управления потоками приказов, распоряжений, внешней и внутренней переписки, служебных записок, и, когда речь заходит об автоматизации управления потоками КД и ТД, они заявляют, что «технический документооборот — то же самое»;
• компании, занимающиеся автоматизацией проектирования, САПР, автоматизацией технической подготовки производства, как правило, говорят лишь о «проектно­конструкторском», «техническом» документообороте, заявляя при этом, что «административный документопоток» — нечто отдельное, не относящееся к основной деятельности предприятия.

Поддерживать первую точку зрения и приравнивать проектно­конструкторский документопоток к административному, на наш взгляд, неправильно. Однако поддерживать позицию второй группы компаний («от САПР») тоже неверно. Но борьба между приверженцами этих двух точек зрения не столь бескомпромиссна. Несмотря на переходы от одной социальной формации к другой, всё же согласимся с автором третьей точки зрения, сформулировавшим первый закон диалектики (читателям, не постигавшим азы философии, не требуется изучать его позицию о единстве и борьбе противоположностей, достаточно прочитать нижеприведенные описания).

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

1. О противоположности:

• на предприятии существуют два разнородных документопотока:

- конструкторско­технологический,

- административный;

• процессы обработки этих потоков — различные;
• алгоритмы автоматизированного управления потоком КД и ТД и потоком приказов/распоряжений, служебных записок, входящей и исходящей корреспонденции совершенно разные.

2. О единстве:

• оба потока в той или иной мере взаимосвязаны. Некоторые примеры:

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

- приказ/распоряжение разрабатывается, регистрируется, рассылается и т.д. в соответствии с правилами административного документооборота. При этом КД и ТД, связанная с выполнением этого приказа/распоряжения, разрабатывается в техническом потоке;

• для полной информационной картины не только полезно, но и необходимо:

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

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

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

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

Компания «СиСофт — Бюро ЕСГ» рассматривает два основных способа решения такой задачи:

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

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

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

Рис. 2. Единая среда управления документами СПб ОАО «Красный Октябрь»

База НТД

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

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

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

Разработка и внедрение

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

1. Постановка задачи. Результаты: согласованные описания автоматизируемых бизнес­процессов с учетом необходимой их модернизации, техническое задание, функциональная спецификация на систему.
2. Непосредственно реализация системы. Результат: получена система, соответствующая описаниям, приведенным в результатах предыдущего этапа (постановка задачи).
3. Разработка документации (для пользователей и администраторов).
4. Разработка контрольных примеров.
5. Разработка программ и методик обучения.
6. Проведение обучения на контрольных примерах.
7. Сдача в опытную эксплуатацию.
8. Проведение (сопровождение) опытной эксплуатации.
9. Необходимые доработки в рамках ТЗ по результатам опытной эксплуатации.
10. Разработка необходимых нормативных документов (СТП).
11. Приемка в промышленную эксплуатацию.
12. Сопровождение системы.
13. Необходимые модернизации.

Прохождение всех пунктов приведенной последовательности — сложная совместная работа как представителей предприятия, так и компании — поставщика решения. Но есть и исключения. Остановимся на них.

Бытует мнение о том, что сдача­приемка в промышленную эксплуатацию — совместная работа компании — поставщика решения и предприятия. Заметим по этому поводу следующее:

• при прохождении всех пунктов приведенной нами последовательности до пункта «Необходимые доработки в рамках ТЗ по результатам опытной эксплуатации» включительно на предприятии имеется:

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

- обученный работе в системе персонал,

- обученные администраторы системы,

- эксплуатационная документация;

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

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

• технические;
• организационные.

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

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

САПР и графика 8`2012