Технологические карты

Примеры технологических карт.
§ 5. Технологическая карта — основной документ для изготовления деталей

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

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

рисунок "операционная технологическая карта"

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

Я к тому, что убирать объекты относящиеся к инструментам из словесного описания или чертежа на том основании, что они описаны в инструментах неправильно. Как бы догадайся теперь как их использовать. А если прописать всё до конца, то колонка объектов, хотя в изначальных операционных технологических картах это оборудование, инструменты и приспособления, не особо и нужна.

Недостаток технологичности

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

Уроки

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

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

Книги

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

Разница в специализациях

А теперь вопрос, чем один человек отличается от другого с точки зрения труда? Ответ получен в книге "Капитал" Карла Маркса. Эта книга описывает возможности человека с точки зрения физиологии. Трудящийся подключает к своим органам орудия труда благодаря чему возможности того, что он может сделать расширяются. Но в тоже время человек остаётся человеком.

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

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

Наборы решений

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

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

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

Текст против чертежа

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

В компьютерных системах везде используется текст, даже просто в каком-нибудь меню. Текстовое описание представленное на языке пользователя помогает проще находить "рычаги" управления, нежели только значки. Однако тоже самое описание представленное на неизвестном языке заставляет тыкать всё подряд и ориентироваться на геометрию расположения элементов, а не на надписи.

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

Нужна ли колонка объектов

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

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

Карты интервальных повторений

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

Операционные технологические карты создаются с другой целью, хотя ничто не мешает оформлять их в виде карт интервальных повторений. Ведь самый примитивный вид последних и вовсе не проводит никаких проверок. Но если смотреть с такой точки зрения, то операционные технологические карты можно было бы оформлять не только в формате карт интервальных повторений (apkg, mtx), но и с помощью текстовых документов (doc, odt), табличных документов (xls, ods), презентаций (ppt, odp), чертежей (dxf, fcstd), веб-страничек (html) и так далее.

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

Где здесь программирование

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

Например:
1) создать недетерминированную машину состояний на языке structured text.
2) вывести упрощённый список всех коммитов в репозитории git.
3) переместить файл в gnu/linux используя консольную команду mv.
И всё в таком роде.

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

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

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

Код в описании и чертеже

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

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

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

Конечный формат чертежей

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

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

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