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

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

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

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

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

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

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

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

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

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

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

3 Способы формирования структуры и разработки системы кодификации.

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

сканирование и распознавание (если есть что сканировать);

набор;

форматирование;

редактирование.

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

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

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

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

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

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

применение упрощенного языка (Упрощенный технический русский (УТР-1), Simplified Technical English® (ASD-STE100)).

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

 

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

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

векторные иллюстрации (формат CGM);

растровые иллюстрации (TIFF, GIF, PNG, JPEG);

мультимедийные объекты (видео, аудио);

трехмерные интерактивные объекты и анимации.

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

3D модель – Специальное ПО – Иллюстрация.

Чертежи – Специальное ПО – Иллюстрация.

Фотографии – Графические редакторы – Иллюстрация.

Чертежи, фотографии, внешний вид изделия – художник-конструктор – иллюстрация.

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

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

Принципиальный способ сокращения затрат при разработке графических объектов заключается в применении в качестве исходной информации 3D моделей, разработанных в САПР (рисунок 7). Это позволяет:

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

во-вторых существенно сократить затраты на разработку и актуализацию графических объектов;

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

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

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

Например, для составных иллюстраций, включающих несколько моделей потребуется САПР и

программы для создания иллюстраций (3DVia Composer, IsoDraw, Deep Exploration, Corel Technical Illustration и т.п.).

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

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

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

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

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

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

конвертирование 3D модели для загрузки в ПО, предназначенное для создания 3D интерактивного объекта;

оптимизация модели специальным ПО (в качестве примера такого ПО может выступать продукт компании Parallel Graphics – Internet Model Optimizer);

«настройка» модели (группировка элементов в соответствии с эксплуатационным составом изделия; разнесение, расстановка выносок, создание анимации, настройка интерактивности);

экспорт 3D интерактивного объекта в формат, воспринимаемый системой разработки документации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

как это не кажется очевидным, но все же – это поддержка стандартов;

наличие графического интерфейса редактора МД, обеспечивающий ввод и форматирование текста в соответствии с S1000D, вставку различных графических объектов (2D, 3D, мультимедиа);

функция формирования и управления PM, DMRL;

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

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

наличие функций для управления доступом к объектам CSDB;

ведение нескольких SNS, автоматизированное назначение кода;

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

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

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

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

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

 

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

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

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

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

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

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

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

8. Результаты оптимизации процессов разработки ЭТД

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

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

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

Воронцов А.В., к. т. н.