Способы сокращения затрат на разработку технической документации

1 Наиболее распространенные виды документации в отечественной и международной классификации

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

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

Исходя из вышеуказанных задач, наиболее распространенными видами технической документации можно считать: КДС (аналог в S1000D — IPD), РЭ, РР (аналогами в S1000D являются информационные наборы, представленные в таблице), УП (аналог в S1000D — публикации, содержащие модули данных обучения и пакеты SCORM). В таблице представлено соответствие видов технических документов и информационных наборов, разрабатываемых с учетом требований отечественной нормативной базы и международной спецификации S1000D.

ЕСКД (ГОСТ 2.601-2006)	S1000D
Каталог деталей и сборочных единиц (КДС)	Illustrated parts data (IPD)
Руководство по эксплуатации (РЭ)	· Информация для экипажа/эксплуатирующего персонала. · Описание и эксплуатация. · Эксплуатационные данные для экипажа/эксплуатирующего персонала. · Техническое обслуживание. · Планирование технического обслуживания. · Данные по загрузке и центровке. · Информация для экипажа/эксплуатирующего персонала по поиску, локализации и устранению · неисправностей. · Данные по восстановительным операциям. · Данные о применяемых материалах для технического обслуживания. · Карты проверки для экипажа/эксплуатирующего персонала.
Учебно-технические плакаты (УП)	Обучение

2 Источники затрат при разработке документации

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

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

Из диаграммы следует, что наибольший вес в структуре затрат на разработку технической документации занимает:

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

В совокупности эти затраты составляют порядка 80-85 % всех издержек на создание технической документации.

3 Формирование структуры документа и разработка системы кодификации информационных объектов CSDB

3.1 Структура документа (DMRL, PM)

3.1.1 Подходы к формированию структуры (DMRL, PM)

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

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

Следовательно, нам необходимо разработать структуру, которая позволит:

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

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

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

Для технических руководств необходимо предусмотреть создание модулей данных для всех элементов конструкции или функциональных систем, которые требуют воздействия на этапе эксплуатации и ремонта. В связи с этим встает вопрос: где же можно взять перечень элементов, которые должны попасть в структуру руководства (DMRL)? Наиболее очевидный ответ — из БД АЛП, результатов АВПО/АВПКО. Т.е. из тех источников, которые позволяют сформировать данные о необходимости проведения планового обслуживания и вероятности выхода из строя элементов изделия. В то же время, достоверные данные из БД АЛП и результаты АВПО/АВПКО, как правило, недоступны для новых изделий. Также их проблематично получить, если данные о стадиях жизненного цикла выпущенных изделий нигде не агрегируются. В этом случае можно использовать метод аналогий и результаты расчетов надежности тех или иных элементов конструкции.

3.1.2 Оптимизация процесса формирования структуры (DMRL, PM)

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

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

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

Если говорить о еще более глубокой автоматизации создания структур документов, то такая работа требует наличия базы АЛП или базы S2000M.

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

3.2 Стандартная система нумерации (SNS)

3.2.1 Подходы к формированию SNS

Для большинства проектов по разработке документации, как правило, можно использовать обозначения SNS, приведенные в S1000D или Авиационном справочнике (AC 1.1.S1000DR-2014).

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

3.2.2 Оптимизация процесса формирования и присвоения SNS

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

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

Это же касается и информационного кода. В рамках проекта целесообразно определить начальный (минимальный) перечень информационных кодов (IC — Information Code), который может быть использован при обозначении модулей данных.

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

4 Разработка текстовой части

4.1 Типовые работы

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

• сканирование и распознавание (если есть что сканировать);
• набор;
• форматирование;
• редактирование.

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

4.2 Способы сокращения трудоемкости разработки текстовой части документов

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

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

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

• использование ПО, которое упрощает процесс повторного применения фрагментов текста (использование репозиториев информации);

применение упрощенного языка (УТР, Simplified Russian, SR), Simplified Technical English^® (ASD-STE100)).

5 Разработка графической информации

5.1 Технические иллюстрации, анимации и трехмерные графические объекты

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

• векторные иллюстрации (формат CGM);
• растровые иллюстрации (TIFF, GIF, PNG, JPEG);
• мультимедийные объекты (видео, аудио);
• трехмерные интерактивные объекты и анимации.

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

1) 3D модель — специальное ПО — иллюстрация;
2) чертежи — специальное ПО — иллюстрация;
3) фотографии — графические редакторы — иллюстрация;
4) чертежи, фотографии, внешний вид изделия — художник-конструктор — иллюстрация.

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

5.2 Способы сокращения затрат на разработку графической информации

Принципиальным решением для сокращения затрат в ходе разработки графических объектов может стать применение в качестве исходной информации 3D-моделей, разработанных в САПР.

Это позволяет:

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

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

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

Например, для составных иллюстраций, включающих несколько моделей, потребуется САПР и программы для создания иллюстраций (3DVia Composer, IsoDraw, Deep Exploration, CorelDRAW Technical Suite и т.п.).

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

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

Второй вариант создания 2D-иллюстраций — это использование только функционала САПР. Как правило, для создания большинства простых иллюстраций возможностей САПР достаточно.

Достоинства: затраты на ПО и обучение меньше, чем для первого способа. Недостатки: при помощи САПР сложно создавать комбинированные иллюстрации с внешними по отношению к модели объектами (внешняя обстановка, люди). Излишняя детализация изображения.

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

Подготовка 3D-моделей для использования в технической документации включает следующие этапы:

• конвертирование 3D-модели для загрузки в ПО для создания 3D интерактивного объекта;
• оптимизация модели специальным ПО (в качестве примера такого ПО может выступать продукт компании Parallel Graphics — Internet Model Optimizer);
• «настройка» модели (группировка элементов в соответствии с эксплуатационным составом изделия, разнесение, расстановка выносок, создание анимации, настройка интерактивности);
• экспорт 3D интерактивного объекта в формат, воспринимаемый системой разработки документации.

Для мультимедийных объектов экспорт осуществляется в видеоряд в соответствии с требованиями S1000D.

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

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

Нормативным документом, который может быть использован при расчете трудоемкости разработки иллюстраций художником-конструктором, являются «Типовые нормы времени на разработку конструкторской документации (проектирование технологического оснащения) (утв. постановлением Госкомтруда СССР, секретариата ВЦСПС от 17.03.1986 n 93/6-6)».

Из расчета следует, что наибольшая трудоемкость соответствует разработке графических объектов художниками-конструкторами, а также в виде 3D-моделей (см. таблицу ниже).

Вид графической информации	Количество графических объектов на систему	Трудоемкость создания одного графического объекта, ч	Суммарная трудоемкость создания графических объектов на одну систему, ч	Суммарная трудоемкость создания графических объектов на изделие, ч	Трудоемкость обновления одного графического объекта, ч	Суммарная трудоемкость обновления графических объектов на одну систему, ч	Суммарная трудоемкость обновления графических объектов на изделие, ч
3D модель	1	160	160	4 800	16	16	480
2D иллюстрации	7	20	140	4 200	7	49	1 470
Рисованная иллюстрация	7	23	161	4 830	15	105	3 150

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

При расчете полных затрат принято следующее:

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

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

Вид графической информации	Постоянные затраты		Переменные затраты	Первоначальные затраты на создание графических объектов на изделие	Переменные затраты на обновление на изделие	Итого постоянных и переменных затрат на проект
	Используемое ПО, инструменты	Ориентировочная стоимость лицензии, руб.	Стоимость н.ч. специалиста, руб.
3D модель	САПР	180 000	700	3 390 000	340 000	4 120 000
	ПО для разработки интерактивной 3D графики (Deep Exploration, 3Dvia Composer, Internet Model Optimizer)	210 000
2D иллюстрации	Adobe Photoshop, CorelDRAW Technical Suite	40 000	700	2 970 000	1 040 000	4 050 000
Рисованная иллюстрация	Карандаш, бумага, линейка, тушь	300	700	3 400 000	2 220 000	5 620 300

При расчете точки безубыточности в денежном выражении (BEP – break-even point) и срока окупаемости проекта (PBP – Pay-Back Period) использованы следующие исходные данные:

— количество активных клиентов – 500 ед.;

— стоимость годового абонентского обслуживания – 5 000 руб.;

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

На основе принятых допущений и исходных данных определено следующее:

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

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

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

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

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

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

6 Применение специализированных систем разработки документации

6.1 Требования к системам разработки документации

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

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

• поддержка стандартов;
• наличие графического интерфейса редактора модулей данных, обеспечивающего ввод и форматирование текста в соответствии с S1000D, вставку различных графических объектов (2D, 3D, мультимедиа);
• функция формирования и управления PM, DMRL;
• возможность публикации документа (информационного набора) как для автономного просмотра, так и для размещения в интернете с возможностью работы с документом посредством стандартного браузера ОС;
• возможность вывода документа на печать, причем полученный бумажный документ также должен отвечать действующим стандартам;
• функции для управления доступом к объектам CSDB;
• ведение нескольких SNS, автоматизированное назначение кода;
• распределенная разработка документации в клиент-серверной среде;
• функции планирования работ и управления процессами разработки документации (workflow).

6.2 Рациональная организация процесса разработки технической документации

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

7 Способы распространения документации

7.1 Способы, применяемые на практике

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

Если речь идет об обновлении бумажной документации, то выбор способов доставки небольшой. Они в основном сводятся к двум вариантам: отправить почтой (курьером) посылку с документами или передать электронную копию документа факсом или электронной почтой, чтобы потом, на другом конце «провода», его можно было бы вывести на бумагу.

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

7.2 Перспективные способы

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

8 Результаты оптимизации процессов разработки технической документации

Мы рассмотрели основные составляющие структуры затрат на разработку технической документации и способы ее оптимизации. Что получается в итоге? Учитывая лучший опыт, накопленный в данной области, применение способов, представленных в статье, позволяет сократить затраты на 20 – 90 % в зависимости от вида работ (см. таблицу ниже).

При этом суммарное сокращение издержек всего процесса разработки может составлять 30-40%.

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

Компетенции компании «Иторум», основанные на знании стандартов, подходов и методик разработки технической документации, позволяют оптимизировать расходы и сроки ее разработки. Для консультации и расчета стоимости услуги оставьте заявку в форме обратной связи или позвоните по тел. 8495-120-80-55.

Цель нашей работы — повысить эффективность вашего бизнеса!

За счет креативных решений, инноваций и целеустремленности.

Отправить заявку