Comments 21
Интересный вопрос, как подключить это все к IoT? Т.е. допустим у вас есть сущность — лифт. По идее с современными технологиями лифт может сам вам сказать — поломался он или нет. И на основе этой информации ваша система может послать push уведомление нужным людям, чтобы обеспечить быструю реакцию на поломку. Мало того, лифт при этом даже может сказать вам что, в нем поломалось, чтобы обслуживающий персонал взял на объект нужные запчасти.
И в третьих лифт даже может сам напроситься на периодическое техническое обслуживание.
Если бы все это можно было интегрировать в одну систему, было бы круто.
Давно реализованы подобные системы. На примере одного иностранного ПО. Есть стерилизаторы, которые подключены в интернет. И посредством соединения они сами передают телеметрию и тревоги на сервер. В итоге накапливается стстистика работы оборудования и ошибок/поломок.
На карте(уж извините) Мира видно, что в какой-то стране начала подпрыгивать иконка больницы. Нажав на иконку открывается карта города и конкретно видно какая больница. там нажав на иконку больницы открывается форма с указанием оборудования. Щелкнув на каждую единицу оборудования видна вся статистика и значимая информация.
Далее не буду подробно. Все просто. Инженеры могут проконсультировать клиента, указать на необходимость замены модуля. Соответсвующая информация так же сохраняется в базе для оборудования.
Система изначально как опция продается производителем оборудования. И помогает оперативно реагировать. Система и инженеры у производителя могут сами определять необходимость своевременной технической помощи. И связываются с клиентом.
Нет секретов. Это компания Gettinge. Вернее ее отделение Getinge It Solutions. Программное обеспечение для управления ЦСО(центральное стерилизационное отделение) T-DOC. Конкретно описанное решение Getinge connect.
Уточнение в том, что на стерилизаторы ставилась дополнительная плата, которая и обеспечивала выход в интернет и передачу телеметрии.
Я видел демонстрацию этого решения во время обучения в штаб-квартире. К большому сожалению в России подобные решения не представлены. Само ПО T-DOC использовалось тоже в очень ограниченном виде.
Поэтому приходится собирать информацию из различных источников и подключать это к системе управления сервисом.
Был бы рад отказаться от проприетарщины и использовать стандартное опенсоурсное решение. Не подскажете, что будет работать из коробки?
Вот то-то и оно. Я сейчас очень сильно гляжу в сторону всяких облачных мониторингов и прочих сайтов для домашней автоматизации. По идее прикрутив свою железяку через MQTT с помощью них можно выйти на первый уровень функциональности — строить графики, PUSH сообщения, архивация событий и т.д. Но дальше уже будет сложнее.
Еще небольшие уточнения. Конечно речь идет о проприетарном оборудовании и ПО. Так как речь идет о мировом лидере в своей области. Но то, что я описал прекрасно работает на различном оборудовании.
Первое. Специфика оснащения оборудованием стерилизационных отделений обычно происходит без "зоопарка" различного оборудования. И не подвержена частой заменой такого оборудования.
Второе. ПО от Getinge поддерживает и стороннее оборудование. В части сбора протоколов стерилизации и телеметрии. На сколько я помню были шаблоны, с помощью которых сопоставляет данные из стороннего оборудования с данными необходимыми для системы. Учитывается и то, что некоторое оборудование отдает данные не онлайн, а в конце цикла стерилизации.
Рано или поздно все сталкиваются с тем, чтобы поддерживать различное оборудование. Я сам в службе поддержки составлял алгоритм поста самообслуживания пациентов. В целом все одно и то же. Но использовались несколько типов весов. Использовалось несколько интерфейсов подключения COM-порты или Moxa. Так что приходится учитывать особенности использования различного оборудования.
Скорее вопрос к организации работы самой сервисной службы. И учет глобального подхода в независимости от оборудования.
Если лифт сам напрашивается на периодическое техобслуживание, то Вы надеваете штаны через голову.
Паспорт оборудования — - > периодичность техобслуживания — - > автоматическая заявка из системы. "Из", а не "в".
Сорри, возможно не так написал. Не периодическое, а превентивное. Или периодически-превентивное, когда во время обслуживания меняется не все по списку, а только необходимое.
Паспорт не учитывает многих нюансов эксплуатации. Например, силовые контакторы имеют ограниченный срок службы и будут изнашиваться по разному на разных лифтах в зависимости от нагрузки и частоты поездок. Лифт мог бы считать количество включений своих контакторов и запрашивать на следующее обслуживание "контактор такой-то близок к концу, рекомендуется заменить."
Вот что делать, если новые контакторы стали выходить из строя чаще, чем старые? Все лифты прошивать новыми пороговыми значениями? А так — внёс в систему новое значение, и заявки стали создаваться чуть раньше.
QR коды для таких целей уже давно используются. Например, продвинутые фирмы с развитой сервисной сетью предлагают для своих сервисников аппликуху, которая по QR коду выдает на телефон всю инфу по устройству, запрашивает статус гарантии и позволяет сразу же получить доступ ко всей технической документации, причем относящейся к конкретной серии/модели.
Но ИМХО для этого в первую очередь нужно желание производителя.
При сканировании с любого устройста (обратите внимание, что если паспорт публичный (в нашей терминологии) можно отсканировать камерой или сканером QR-кодов, необязательно иметь приложение HubEx) возможно увидеть полную информацию об оборудовании или объекте, приложенные файлы с инструкциями, гарантийными документами, инструкции и т.п. Также, настройками системы вы можете указать — есть ли возможность из публичного паспорта подать заявку (шаблон заявки) и самозарегистрироваться с определенными администратором системы полномочиями в системе (шаблон сотрудника), возможность увидеть историю обслуживания (все заявки, которые когда-либо были созданы по данному объекту). Также, если паспорт непубличный — видеть информацию в нем смогут только зарегистрированные пользователи, для которых вы можете тонко настроить полномочия (вплоть до каждого приложенного файла) на видимость прилагаемых документов для определенных ролей в системе и многое другое).
Для производителей же оборудования — это возможность собирать информацию по частным неисправностям, анализировать работу различных сервисных компаний (в сравнении), которые обслуживают их оборудование.
1. Заявки направляют только в приложение (+ push)
2. Выстраивают систему мотивации, чем то похожую на мотивацию сотрудников отделов продаж: ставят в метрики параметры из системы. Например, лимитируют % заявок оформленных без нарушений. Это могут быть как геопозиция сотрудника в момент оформления акта выполненных работ (т.е. закрытие заявки на объекте). Закрыл вне объекта — система выдает алерт по данной заявке и она не будет учтена в KPI, так и качественно заполненный акт с указанием обслуженного оборудования. Не заполнил — минус «к карме» =)
3. А особо
4. кто-то, на основе рейтингов в системе, платит премиальные ТОП3 лучшим и депремирует ТОП3 самых безответственных
5. Другие — завязывают процессы получения заявок исполнителями таким образом, чтобы сотрудники конкурировали за заявки (это особенно хорошо работает в схемах со сдельной оплатой)
В общем, если руководство замотивировано и понимает зачем компании нужна автоматизация сервиса, у сервисных инженеров шансов не остается. Более того, через пол года, компания уже вспоминает время работы без системы — как страшный сон. С внедрением систем автоматизации компания неизбежно начинает расти, оптимизируя ручные и неидеальные (исторически сложившиеся) процессы.
Как мы создали Service Desk мечты