предприятия

Задачи и проблемы развития автоматизированных систем управления предприятием в машиностроении.

АВТОМАТИЗАЦИЯ УПРАВЛЕНИЯ


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

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

После появления персональных компьютеров в 90-е годы на каждом заводе появлялись «партизаны», каждый из которых строил свою маленькую систему своими силами. Разумеется, при определенных плюсах для подразделений это не привело к развитию всей системы, а скорее нанесло вред, поскольку целостность управления снизилась.

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

ОПЫТ РАБОТЫvaz

В 90-е годы в ОАО «Завод им. Тарасова» (Самара) на протяжении 8 лет строилась система управления под руководством фирмы INOVEX GmbH, Германия. В частности, были созданы системы управления сбытом, снабжением, производством, расчетом себестоимости, а также многие другие. Был получен опыт развития системы на основе технологии MRP силами нескольких групп разработчиков, действовавших параллельно.

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

Райнер Дюрр: Валера сейчас составляет предварительную схему базы. Сколько примерно таблиц в ней будет?

Леонид: Я думаю, около 200 — 250.

Райнер: Да. похоже, а как ты это определил?

Леонид: Если меньше 200 — он всегда найдет что добавить, а если больше — просто не удержит в голове и остановится.

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

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

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

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

ИЕРАРХИЯ138

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

Можно сказать так — главный модуль не назначается, а выдвигается. То есть мы не поручаем Иванову продумать все «главные» вопросы, чтобы Петров потом во всем его слушался. Иванов должен предложить такие решения, на которые Петров и Сидоров смогут опереться и которые они попросят зафиксировать как главные.

Льва Толстого и Сергия Радонежского никто не ставил в начальники русской литературы или церкви. Но эти места они заслуженно занимают и миллионы наших соотечественников следуют их «указаниям».

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

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

ВНЕДРЕНИЕ

На уже упомянутом ООО «Завод им. Тарасова» главной системой стала система движения материалов, состоящая из основных частей Снабжение, Производство, Сбыт. Отдельно разрабатывалась Конструкторская спецификация и Технологическая документация. Однако помимо этой «тактической» системы параллельно велись работы по переводу конструкторского отдела на 3D моделирование (Solid Works), по решению задачи ТПП (технологической подготовки производства), а также других задач вплоть до экологического контроля выбросов. 

На АвтоВАЗе чуть позже была разработана система «АСУ Ремонт» силами той же фирмы. Эта система ориентирована на специфический поток обслуживания оборудования, включая аварийный и периодический ремонт, снабжение запчастями, маршруты смазки и так далее. При этом пришлось интегрировать локальные базы данных, разработанные как на ЕС ЭВМ, так и на несовершенных персональных компьютерах первого поколения, как на уровне электронных таблиц, так и на системах «клиент-сервер».

КРАТКИЕ ВЫВОДЫpapka

  1.  Опыт разработки и развития АСУ П на базе стратегического плана, который обозначает общую структуру и корректируется каждый год, позволяет ограничить задачи для отдельных систем управления потоком материалов, финансовыми потоками, технической подготовкой производства, кадровыми вопросами и так далее. Нет смысла жестко загонять все эти системы в прокрустово ложе одного проекта, но некоторые правила эволюционного развития позволяют гибко развивать то или иное направление на основе достигнутого уровня.
  2. Уникальная схема работы предприятия и его системы управления является на самом деле уникальной композицией типовых задач, поставленных в определенные условия и выполняемых в определенной инфраструктуре. Попытки найти подобную конструкцию на стороне не могут привести к успеху, в том время как отдельные модули и системы можно обнаружить в готовом виде на других объектах. Весь вопрос в их совместимости с уже имеющимися комплексами, то есть в информационном стандарте предприятия, в принципах построения конструкции. 
  3. При переходе к новым технологиям и инновациям в управлении целесообразно использовать пилотные проекты, отвечающие новым принципам не только в плане тактического решения той или иной задачи, но и в плане отработки стандартных принципов будущей системы. Параллельно с выполнением предметной задачи персонал осваивает новые подходы, возникают новые отношения между подразделениями, вычищаются хранилища информации, построенные по старым принципам и так далее.
  4. Опыт автоматизации предприятий постепенно проникает в учреждения, прежде всего в университеты, а затем распространяется и на другие сферы, весьма далекие от производства, вплоть до гуманитарных областей.

Остается добавить, что этот краткий анализ представляет собой только начало большого разговора и будет постепенно углубляться. 

dashboard
Логистика, Методология, Производство
dashboard
параметры склада
Логистика, Методология
параметры склада
темы для студентов
Логистика, Университеты
темы для студентов
матрица
Методология
матрица
логистика
Логистика, Производство, Университеты
логистика
нейронные сети
Логистика, Методология, Производство
нейронные сети
агентные модели
Логистика, Производство, Университеты
агентные модели
управление проектами
Логистика, Производство, Университеты
управление проектами
мастер классы
Логистика, Университеты, Экология
мастер классы
сайт ЕСО 63
Общество, Экология
сайт ЕСО 63
системные ловушки
Методология
системные ловушки
сущность системы
Методология
сущность системы
BoardMaps
Общество, Производство, Университеты, Экология
BoardMaps
эволюция системы
Методология
эволюция системы
управление персоналом
Общество, Производство, Университеты
управление персоналом
рейтинг кафедры
Университеты
рейтинг кафедры
социальные системы
Общество
социальные системы
механический завод
Производство
механический завод
опыт работы
Логистика, Общество, Производство, Университеты, Экология
опыт работы
университеты
Университеты
университеты
предприятия
Производство
предприятия
ЮНИВОЛГА
Общество, Университеты
ЮНИВОЛГА
КАДАСТР ОТХОДОВ
Муниципалитетам
Производство, Экология
КАДАСТР ОТХОДОВ