Конвейер встает посреди смены, погрузчик не заводится, насос дает течь, и внезапно всем нужны ответы. Какая команда будет это чинить? Когда было последнее обслуживание? Есть ли у нас нужная запчасть? И где записи о предыдущем ремонте? Вместо этого все начинают обзванивать коллег, открывать старые таблицы, рыться в папках, а оборудование просто простаивает. Эта суматоха стоит реального времени и денег еще до того, как ключ коснется механизма. Ямир Ко Питерс из М365 и ФМ, и этот экскурс поможет просто объяснить работу с активами в Dynamics 365. Это часть Dynamics 365 Supply Chain Management, которая дает компаниям единое место для отслеживания оборудования, техобслуживания, затрат и истории сервиса. Позже мы покажем, как сигнал датчика может превратить аварийный ремонт в плановую работу. Но прежде мы должны взглянуть на физические активы, от которых бизнес зависит каждый день. Итак, почему физические активы становятся проблемой для бизнеса?

Давайте подумаем об оборудовании, которое обеспечивает привычный рабочий процесс. На заводе могут быть производственные станки, конвейерные ленты, двигатели и насосы. Склад зависит от погрузчиков, погрузочного оборудования и систем сортировки. Транспортной компании нужны грузовики, которые отправляются точно по графику. А администрация офиса следит за отоплением, охлаждением, генераторами и лифтами. Каждый из этих объектов выполняет свою задачу, но к каждому возникает ряд вопросов, которые не исчезают только потому, что оборудование пока работает. Где оно прямо сейчас? Кто за ним следит? Хорошо ли оно еще работает? Когда проводилась последняя проверка или ремонт? Эти вопросы звучат просто, пока ответы не оказываются разбросаны в пяти разных местах. Один техник может знать, что странный шум станка предвещает беду, потому что проработал рядом с ним годы. Другой сотрудник ведет таблицу с датами обслуживания, файлы закупок и заказы запчастей где-то еще.

Финансовый отдел видит счета и расходы, но не всегда знает всю историю ремонта за ними. Затем этот техник уходит в отпуск, меняет работу или просто не выходит в смену. Знания покидают компанию. Раньше это случалось постоянно, бумажные листы обслуживания, папки в шкафу мастерской и таблицы, пересылаемые по почте. Команда могла поддерживать работу оборудования, но на сбор полной картины уходило время. Люди часто работали, располагая неполными данными. Когда оборудование ломается, проблема нарастает быстро. Производство может простаивать или замедляться, а ремонтная бригада вынуждена искать причину неисправности. Отделу закупок, возможно, придется срочно заказывать отсутствующую деталь. Финансовый отдел позже видит дорогой счет, но не всегда может связать эти расходы с конкретной машиной или ремонтом. Никто не планирует поломки. Аварийные работы также меняют поведение людей. Команда заказывает первую попавшуюся деталь, переплачивает за срочную доставку или пропускает обычное планирование, потому что машину нужно запустить снова.

Иногда это временное решение оправдано, но когда каждый ремонт кажется экстренным, расходы растут, а одна и та же неисправность постоянно возвращается. Разным людям нужны разные части одной и той же истории. Сотрудникам по техническому обслуживанию нужны детали ремонта и прошлые записи. Операционному отделу нужно знать, может ли оборудование работать. Отделу закупок нужно знать, какие детали требуются. Финансистам нужен четкий след расходов, а руководителям – понимать, где постоянно возникают сбои и траты. Dynamics 365 Asset Management объединяет рабочую документацию по физическому оборудованию и связанным с ним задачам обслуживания. Система не призвана заменить человека, который умеет чинить двигатели. Она дает этому специалисту и всем вокруг общее пространство, чтобы фиксировать происходящее и находить нужную информацию. Прежде чем кто-либо сможет спланировать ремонт, системе нужно четкое представление о каждом отдельном активе.

Запись об активе – это цифровое досье на каждую машину. Итак, вот как стоит воспринимать управление активами. Представьте картотеку в ремонтной мастерской, где для каждой машины есть своя папка с ярлыком. Разница в том, что эта папка хранится в Dynamics 365 Supply Chain Management, и нужные люди могут найти ее, не роясь в шкафах и не расспрашивая коллег. Откройте папку машины, и вы начнете с ее идентификации. Запишите название, номер продукта или модели, серийный номер и простое описание того, что она делает. Добавьте технические характеристики и информацию о гарантии, чтобы команда могла проверить, покрывает ли случай ремонт по гарантии поставщика, прежде чем заказывать детали. Звучит просто, но это избавляет от серьезной головной боли. Две машины в одном цеху могут выглядеть почти идентично, но их запчасти, гарантийные сроки или потребности в обслуживании могут быть совершенно разными.

Четкая запись об активе точно показывает команде, с какой машиной они имеют дело. Запись также должна отвечать на практический вопрос. Где работает это оборудование? Для этого в Dynamics 365 Asset Management используются так называемые функциональные расположения. Представьте функциональное расположение как место, где актив выполняет свою работу, это не просто точка на карте, а площадка, здание, склад, мастерская или производственная линия. Вот пример. Представьте компанию с тремя заводами. На одном из заводов есть зона упаковки. В этой зоне работает конвейерная линия. Этот конвейер включает в себя несколько двигателей, датчиков и роликов. Вы можете описать всю эту структуру в системе от крупного объекта вплоть до оборудования, которое люди непосредственно осматривают и ремонтируют. На вершине находится завод. Под ним – производственная линия. Под линией – конвейер. Под конвейером – двигатель.

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

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

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

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

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

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

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

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

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

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

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

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

Здесь рабочая заявка начинает выполнять нечто большее, чем просто описание неисправности. Это своего рода центральный командный пункт, куда каждый может заглянуть перед началом своей части работы. Это помогает людям подготовиться до начала выполнения задач. Техник знает, что проверять, планировщик знает, кому поручить работу, складская служба видит нужные детали, а отдел закупок может действовать, если детали нет в наличии. По мере продвижения работы наряд фиксирует ее статус. Сначала он создается, затем кто-то назначает время выполнения. Когда техник приступает к работе, команда фиксирует это изменение. После ремонта статус меняется на «выполнено», и менеджер или ответственное лицо могут проверить результат перед закрытием записи. Эти этапы могут показаться бурократией, но они отвечают на практические вопросы. Занимается ли кто-то этим вопросом? Работа уже началась. Готова ли машина к возвращению в нормальный режим работы?

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

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

Управление активами не существует само по себе. Оно связано с каждым отделом через рабочие наряды. Эта связь избавляет сотрудников от необходимости вводить одни и те же данные в разных местах. Это снижает вероятность ошибок и значительно экономит время. В Dynamics 365 Supply Chain Management работы по техобслуживанию могут быть связаны с записями о складских запасах запчастей и расходных материалов. Если для ремонта нужен подшипник, фильтр или новый мотор, команда может проверить их наличие, прежде чем обращаться к поставщикам. Складские данные показывают, что именно есть в наличии. Если нужной детали нет, отдел закупок работает с тем же запросом на обслуживание, а заказ на поставку связывается с ремонтными работами, что дает всем ясное понимание, зачем заказан товар и куда он поступит по прибытии. Производство также тесно связано с этим процессом. Если для оборудования требуется плановый простой, производственный отдел сразу видит, что ремонт может повлиять на работу линии или склада.

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

Если на одной площадке постоянно тратят много средств на один и тот же тип оборудования, команда может задать правильные вопросы. Работает ли площадка в более длинные смены? Нужен ли там иной план техобслуживания? Или само оборудование требует замены? Именно такие закономерности со временем позволяют принимать более обоснованные решения по техобслуживанию. Управление активами также можно связать с Dynamics 365 Field Service. Управление активами обычно очлеживает оборудование, которым компания владеет и которое использует внутри своей деятельности, тогда как полевое обслуживание сосредоточено на работах для клиентов, часто на их территории. Когда эти подразделения обмениваются сервисной информацией, компания получает более четкое представление об оборудовании, обслуживании и работе сотрудников. Одна и та же компания может обслуживать станки на собственном заводе и одновременно направлять специалистов для ремонта оборудования у клиентов.

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

Dynamics 365 Gidas в сочетании с HoloLens дает специалистам пошаговые инструкции при работе со сложным оборудованием. Работник может следовать подсказкам перед глазами, что помогает при выполнении многоэтапных задач или при обучении нового персонала методом опытных мастеров. Это не превращает новичка в эксперта за одну ночь, но дает специалисту практическое руководство непосредственно на месте работы, пока записи о техобслуживании фиксируют ход выполнения. Многие ожидают, что одно бизнес-приложение справится со всем самостоятельно, но так это не работает. Управление активами отвечает за техобслуживание, а другие модули Dynamics 365 – за склад, закупки, финансы, клиентский сервис и прочее. Преимущество заключается в передаче записей между этими областями без необходимости повторного ввода данных и потери контекста. Именно связи между этими системами делают платформу такой мощной. Давайте объединим эти процессы на примере одной простой истории технического обслуживания.

Теперь у вас есть ясное представление о том, как управление активами вписывается в общую экосистему Dynamics 365. Один рабочий день от предупреждения до завершенного ремонта. Представьте, что двигатель конвейера на складе передает показатели необычной вибрации. Это и есть предупреждение перед поломкой. Вот как выглядит процесс. Вы открываете карточку актива, видите расположение двигателя, историю, гарантию и график запланированных работ. Затем вы создаете на ряд заказ, назначаете техника, перечисляете шаги осмотра и проверяете наличие подшипника на складе. Если подшипника нет, система заказывает его, одновременно очлеживая время и затраты. После ремонта техник фиксирует результат и оставляет свои комментарии. Руководитель видит затраты, повторяющиеся поломки, время простоя и все техобслуживание этого двигателя. Предупреждение не починило двигатель. Оно дало людям время на планирование, вместо того, чтобы в спешке устранять аварийную ситуацию.

Итак, для кого это подходит и что оно не заменяет? Кому нужно управление активами? Любой компании, зависящей от машин, транспорта, производственного оборудования или инженерных систем зданий. Сюда входят производители, склады, транспортные службы, коммунальные предприятия и сервисные компании. Но вот в чем дело, это не заменяет техников, правила безопасности или здравый смысл. Оно дает этим людям единую общую запись, как медицинскую карту для вашего оборудования и план по поддержанию всего в рабочем состоянии. Вывод. Храните историю оборудования в одном месте. С управлением активами вы храните данные об активе, задачах обслуживания, запчастях, затратах и истории сервиса в одном месте. Подписывайтесь на m365.fm, чтобы получать больше полезных знаний простыми словами. И переходите к следующему блоку.