поиск
 


Dynamics AX на машиностроительном предприятии или как был загублен ещё один проект

Часть нулевая. Предыстория.

Будучи ещё студентом, начинаешь задумываться о том, как заработать на хлеб, а тут ещё эти лабораторные работы, курсовые, практика… В итоге, многие сталкиваются с камнем судьбы, похожим на такие же в русских народных сказках: направо пойдёшь – то есть по специальности, будешь начинать зарабатывать гроши, налево пойдёшь – то есть совершенно наоборот, будешь зарабатывать хорошо, но недолго, да и весь смысл образования теряется… Ну, а прямо пойдёшь, т.е. и там, и тут, так совсем спать не будешь… Автор этой статьи решил пойти направо и предаться производственной и преддипломной практике на средних размеров машиностроительном предприятии, которое является вторым в его городе по размерам и находится не совсем далеко, но в глубинке. Надо отдать должное реалиям современной системы обучения: практика нигде не оплачивается, работать приходилось с 8ми и до 7ми, а потом ещё дома, и часто даже по субботам, хотя официально это конечно же 40часовая рабочая неделя, поэтому дабы остаться на предприятии после прохождения первой практики, пришлось нехило потрудиться. Не скажу, что работать приходилось за еду, но, я думаю, для каждого эти воспоминания – о том, как пришёл на последнее место работы, как приняли, как проходил весь процесс адаптации, - это особая история. А машиностроительное предприятие было достаточно известным в городе, отчасти благодаря более высокой зарплате. Придя на практику, радостное начальство дало задачу – попробовать в действии несколько MES-систем, затем несколько APS-систем, а после разбираться в возможностях ERP-систем и провести беглую сравнительную характеристику всего проделанного. Т.к. автор статьи обладает пусть и небольшими, но достаточно обширными знаниями по этим темам, пусть и теоретическим, благо сейчас в ВУЗах эти темы затрагиваются, то можно сказать, что справился с задачей. Хотя, между нами говоря, за поставленные сроки многое было сделано лишь по документации к конкретным программным продуктам, зато могу похвастаться, что были системы, которые сам смог настроить, поиграться и получить даже какой-то результат. Главной задачей было планирование. И сейчас, уже спустя большой промежуток времени, планирование так и остаётся одной из первоочерёдных задач.

Часть первая. Начало

Все, кто сталкивался с задачей «запустить подсистему планирования», как и с любой другой сложной задачей, решение которой зависит от многих других факторов, могут сразу же прямо сказать – «как минимум наведите порядок», о чём все на предприятии понимали, но никто особо не шевелился. Инженеры планово-диспетчерского отдела (далее будем называться их «плановиками») выдвигали свои меняющиеся день ото дня требования к тому, как они хотят планировать и какие результаты хотят видеть от системы, инженера-технологи не хотели заполнять данные таким образом, как того просят инженеры ПДО, а начальство ИТ-отдела тихонько курило в сторонке. Впрочем, его (начальства) главной задачей было внедрение небезызвестной 1С8:УПП, чем и занимались программисты. Поэтому постепенно были определены данные, необходимые плановикам, а затем те данные, необходимые в Dynamics AX для того, чтобы правильным образом получать необходимый результат. За определённый промежуток времени был написан экспорт из УПП и импорт данных в аксапту. И вот момент настал.

Часть вторая. Процесс

Для сборки автомобилей требуется правильным образом написать техпроцесс и подготовить спецификацию. Были приняты следующие решения, которые возможно покажутся всем типовыми (но кому-то могут и помочь): 1)      Для всех полуфабрикатов в спецификациях должен быть тип строки «Номенклатура», а для полуфабрикатов, производимых внутри предприятия и не требуемых учёта (мелкие болты, гайки, требующие доработки прямо на месте, на которые есть спецификация и техпроцесс), указать тип строки «Искусственный» (фантом в одном из переводов Dynamics AX) 2)      В спецификации на одном уровне должны находиться только те элементы, которые  нужны для выполнения определённой последовательности техпроцесса, т.е. если можно одновременно в процессе установки двигателя заливать в него масло, причём это необходимо учитывать, то это будет полуфабрикат «кузов+двигатель в сборе с маслом». В остальном же, часто пишется техпроцесс, где на одном уровне находится «серийный автомобиль» + «доработка N», если имеется возможность сделать вначале именно первый элемент спецификации, а потом уже выполнить какой-либо специфичный заказ. 3)      Иметь 2 техпроцесса: один обычный – для детальной проработки операций, где рабочим центром вида «Персонал» являются специалисты определённой профессии определённого разряда, находящиеся в определённом подразделении, второй – для укрупнённой проработки заказа, когда операции заполняются лишь на полуфабрикат, где рабочим центром вида «Персонал» является уже всё подразделение целиком. При этом, в первом случае на рабочий центр, например, бригаду слесарей МСР 4го разряда в операции будет указана процентная загрузка рабочего центра и количество деталей, которые они обрабатывают одновременно при такой загрузке за конкретное время. А во втором случае, полуфабрикат изготавливается лишь в одном подразделении и указывается ориентировочное время при 100%-ой загрузке. 4)      Рабочие центры вида «Машины и оборудование» - использовать как реальные машины и оборудование, необходимые лишь на узких местах, дабы не нагружать систему лишней информацией. Т.е. дрели, которые можно купить в любом магазине, не являлись рабочим центром, а станок, имеющий свои планово-предупредительные работы, когда он простаивает, даже если находится в группе соответствующих взаимозаменяемых станков, в любом случае учитывается как отдельный рабочий центр со своим календарём. 5)      В маршруте (техпроцессе, технологической карте, технологическом маршруте и т.д. – на каждом предприятии своё название) указывать на уровне полуфабриката при укрупнённом способе написания параллельные операции, т.е. использовать настройку «Маршрутная сеть» и при этом явным образом определять вид связи между операциями и номер следующей операции. 6)      Различные настройки сводного планирования были определены в соответствии с каждым материалом/полуфабрикатом/товаром, которых поделили по группам, при этом минимальный горизонт планирования равен количеству дней самого долгого поставщика плюс 50% исходя из календарей поставщиков и времени доставки, указанных в ценах.  Либо самого трудоёмкого по времени заказа плюс 50%, исходя из того, что рассчитать ход выполнения заказа необходимо в любом случае (хотя это и кажется не совсем логичным, это было требование плановиков). А заказы заполняли на месяц-два вперёд. Результат работы укрупнённого планирования по 1 заказу требовал 2-3 минуты для расчёта, а по реальному плану – 1 час, для детального перепланирования 1 заказа требовался минимум 1 час, а по всему плану – минимум 4 часа. Т.е. расчёт плана происходил каждую ночь, поэтому был поставлен в очередь пакетных заданий для сервера.

Часть третья. Окончание

После успешного тестового планирования стало понятно, что предприятие должно изменить схему своей работы, чтобы плановики получали именно то, что они хотят. А из-за того, что порядка в головах людей и в каждом подразделении, от которого требуется вводить информацию, не наблюдалось и наводить его было попросту некому, проект внедрения Dynamics AX был приостановлен и отложен до лучших времён. Ну и немаловажной причиной являлось время расчёта плана на имеющемся оборудовании, которое плановикам очень сильно хотелось уменьшить, но имея такое количество уровней в спецификации и такую сложность работ в техпроцессах, сделать такое на момент тестового планирования не оказалось возможным. Нежелание людей оказалось в разы сильнее их желаний:) P.s. Буквально недавно было принято решение о внедрении отдельной дорогой системы планирования, о чём говорилось ещё в самом начале, т.к. внедрить что-либо неправильно и не к месту можно запросто, но обидно, что для этого пришлось потратить немало времени, сил и нервов. P.p.s. Негативный опыт - тоже опыт, иногда ещё более полезный.

Leave a comment