Типовое решение как составить

Главные особенности
проектирования технологических
процессов:

1. Многовариантность
проектных решений.

2. Слабая формализация
многих проектных задач.

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

– расчет припусков
и межпереходных размеров;

– расчет режимов
резания;

– нормирование
технологического процесса.

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

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

Пример. Назначить
станок на операцию зубошевингования.
Пусть на предприятии имеются
зубошевинговальные станки трех моделей.
Они составляют множество типовых решений
(МТР):
.

Сформулируем
комплекс условий применимости выявленных
типовых решений:

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

2 условие. Диапазоны
допустимого изменения модуля детали
и
угла наклона зуба детали.

Комплекс условий
применимости (КУП) в данной задаче может
быть представлен в виде следующей
системы:

На основе паспортных
данных станков сформированы условия
их применимости, которые представлены
в таблице 7.1.

Таблица 7.1

Условия применимости
зубошевинговальных станков

Важно определиться,
входят или нет границы интервалов,
указанные в таблице в соответствующий
интервал. В данном примере предполагается,
что входят, т.е., например, для
можно
применить станок модели 5А702Г, или для–
станок модели 5717С и т.д. Блок – схема
алгоритма выбора модели зубошевинговального
станка показана на рис. 7.1.

В данном алгоритме
заложен принцип предпочтительности
применения станков малых размеров.
Например, при
выбирается
станок модели 5А702Г, хотя подходит и
станок модели 5717С.

Виды типовых
решений

Типовые решения
являются основой технологического
проектирования при использовании ЭВМ.
По уровню решаемых задач типовые решения
подразделяют на две группы: локальные
типовые решения (ЛТР) и полные типовые
решения (ПТР).

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

Здесь
–
множество технологических переходов;–
множество режущих инструментов.

Полные типовые
решения охватывают весь (полный, логически
завершенный) круг решаемых задач.
Примером полного типового решения
является типовой технологический
процесс. Множеством типовых решений
этой группы может являться множество
типовых технологических процессов, где
каждое типовое решение есть технологический
процесс изготовления деталей определенного
типа. Пример множества полных типовых
решений (МПТР):

Здесь
–
типовой технологический процесс
изготовления шестерни;–
типовой технологический процесс
изготовления втулки.

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

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

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

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

Типовое решение — история вопроса

ТВЭЛ — топливная компания Росатома, объединяющая ряд предприятий по производству ядерного топлива, поставила целью внедрить автоматизированную систему подготовки производства (АСУ КТПП). Внедрить не на пустом месте и не «с нуля». На одном из предприятий компании — Новосибирском заводе химических концентратов (НЗХК) — нами уже была внедрена и в течение ряда лет успешно эксплуатировалась АСУ КТПП на базе программного обеспечения Technologies.

Работающая АСУ КТПП рассматривалась при этом как прототип, на базе которого необходимо разработать типовое решение и впоследствии тиражировать его на остальные предприятия. Подобная постановка задачи была продиктована необходимостью минимизировать затраты как на проектирование и реализацию, так и на дальнейшее сопровождение и развитие АСУ КТПП. Когда в целом все понятно, остается разобраться с деталями. И тут начали возникать проблемы, главная из которых состояла в том, что ни заказчик (ТВЭЛ), ни предполагаемый исполнитель (CSoft) не могли четко сформулировать, что должно собой представлять типовое решение, из каких компонентов оно должно состоять и чем оно будет отличаться от обычных решений.

Чтобы с чего-то начать, была предложена достаточно общая декларация целей создания типового решения:

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

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

Типовое решение — возможно ли оно в принципе?

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

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

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

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

Для того чтобы понять, что можно типизировать, мы сначала отсекли категории, которые однозначно не подлежат типизации: организационную структуру предприятия, виды и состав конструкторской и технологической документации и пр. Нам могут возразить — организационная структура должна оптимизироваться, состав документации определяется требованиями ЕСКД и ЕСТД. Всё так, только не для нашего случая, так как одно предприятие работает исключительно с использованием конструкторской документации стороннего разработчика, а другое разрабатывает собственную документацию. Отсюда объективные различия и в организационной структуре, и в составе документации.

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

Если гипотеза подтвердится, то задача типизации приобретет реальные очертания и в результате ее решения мы сможем получить:

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

Гипотезы, как известно, проверяются экспериментом. При этом требования к эксперименту довольно очевидны:

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

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

Методика разработки типового решения

1. Исходные данные

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

Модели были выполнены с использованием ARIS — специализированного программного обеспечения для моделирования бизнес-процессов. Известно, что методика ARIS, какой бы формальной она ни была, допускает определенные «вольности». Для того чтобы обеспечить однозначную интерпретацию процессов, разрабатывается специальный документ «Соглашение о моделировании» — и все моделирование происходит в соответствии с его требованиями. Мы были лишены такой возможности по объективным причинам:

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

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

2. Представление бизнес-сценариев

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

• основной процесс организации КТПП;
• конструкторская подготовка производства;
• технологическая подготовка производства;
• управление работами;
• управление документацией.

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

Рис. 1. Диаграмма сценариев

3. Анализ процессов, выделение типовых составляющих и синтез типовых моделей

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

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

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

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

Рис. 4. Фрагмент результата обработки процессов

Таблица содержит разделы, соответствующие сравниваемым процессам разных предприятий (в данном случае НЗХК и ЧМЗ), а также раздел, соответствующий типовому решению (ТР). Необходимо обратить внимание, что сравнивать можно процессы, которые располагаются в одной строке диаграммы сценариев (например, процесс «Разработка документа ТД» НЗХК и «Разработка нового ТП» ЧМЗ). Другими словами, вначале мы на диаграмме сценариев сопоставили процессы, после чего для сопоставленных процессов выполнили ту же процедуру для их содержимого — функций и ролей. По горизонтали в таблице расположены функции, встречающиеся в процессах, а по вертикали — бизнес-роли. Пересечения показывают использование функций в процессах.

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

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

Рис. 5. Фрагмент типового процесса

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

Рис. 6. Структура типового решения

Структура типового решения позволяет провести аналогию с групповым изделием, имеющим постоянную и переменную части. Преимущества подобного представления очевидны:

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

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

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

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

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

Юридическая природа

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

В частности, имеются в виду любые изменения в наименовании, юридическом адресе. Сотрудникам ИФНС высылается копия.

Форма документа

Действующее в настоящий момент законодательство не предъявляет особых требований к форме решений, не требует использования общеобязательных унифицированных бланков. Любая официальная бумага из этой группы может быть написана в свободной форме. Такая возможность имеется в силу действующей редакции Гражданского общества и ФЗ «Об обществах с ограниченной ответственностью».

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

• деловой стиль языка (отсутствие жаргонизмов, ругательств и так далее);
• ссылки на нормы законодательства (если актуально);
• обозначение реквизитов юридического лица (наименование, ИНН, ОГРН, юридический адрес);
• данные учредителя (ФИО, паспорт, подтверждение полномочий);
• подпись ответственного за составление документа лица;
• расшифровка оставленного автографа.

Структура решения

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

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

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

Реквизиты

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