Pull to refresh

Comments 21

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


Если бы все это можно было интегрировать в одну систему, было бы круто.

Привет, если лифт умеет пользоваться rest апи, то все это легко делается, реализация есть. Если нет, то нужен какой-то шлюз, который собирает информацию от лифтов и засылает данные в HubEx. В другую сторону тоже есть интеграция по webhookам, например при закрытии заявки мы можем сказать лифту что тревогу можно выключать.

Давно реализованы подобные системы. На примере одного иностранного ПО. Есть стерилизаторы, которые подключены в интернет. И посредством соединения они сами передают телеметрию и тревоги на сервер. В итоге накапливается стстистика работы оборудования и ошибок/поломок.
На карте(уж извините) Мира видно, что в какой-то стране начала подпрыгивать иконка больницы. Нажав на иконку открывается карта города и конкретно видно какая больница. там нажав на иконку больницы открывается форма с указанием оборудования. Щелкнув на каждую единицу оборудования видна вся статистика и значимая информация.
Далее не буду подробно. Все просто. Инженеры могут проконсультировать клиента, указать на необходимость замены модуля. Соответсвующая информация так же сохраняется в базе для оборудования.


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

А подскажите название системы? Можно в личку.

Нет секретов. Это компания Gettinge. Вернее ее отделение Getinge It Solutions. Программное обеспечение для управления ЦСО(центральное стерилизационное отделение) T-DOC. Конкретно описанное решение Getinge connect.
Уточнение в том, что на стерилизаторы ставилась дополнительная плата, которая и обеспечивала выход в интернет и передачу телеметрии.
Я видел демонстрацию этого решения во время обучения в штаб-квартире. К большому сожалению в России подобные решения не представлены. Само ПО T-DOC использовалось тоже в очень ограниченном виде.

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

Был бы рад отказаться от проприетарщины и использовать стандартное опенсоурсное решение. Не подскажете, что будет работать из коробки?

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

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

Еще небольшие уточнения. Конечно речь идет о проприетарном оборудовании и ПО. Так как речь идет о мировом лидере в своей области. Но то, что я описал прекрасно работает на различном оборудовании.
Первое. Специфика оснащения оборудованием стерилизационных отделений обычно происходит без "зоопарка" различного оборудования. И не подвержена частой заменой такого оборудования.
Второе. ПО от Getinge поддерживает и стороннее оборудование. В части сбора протоколов стерилизации и телеметрии. На сколько я помню были шаблоны, с помощью которых сопоставляет данные из стороннего оборудования с данными необходимыми для системы. Учитывается и то, что некоторое оборудование отдает данные не онлайн, а в конце цикла стерилизации.
Рано или поздно все сталкиваются с тем, чтобы поддерживать различное оборудование. Я сам в службе поддержки составлял алгоритм поста самообслуживания пациентов. В целом все одно и то же. Но использовались несколько типов весов. Использовалось несколько интерфейсов подключения COM-порты или Moxa. Так что приходится учитывать особенности использования различного оборудования.
Скорее вопрос к организации работы самой сервисной службы. И учет глобального подхода в независимости от оборудования.

Если лифт сам напрашивается на периодическое техобслуживание, то Вы надеваете штаны через голову.
Паспорт оборудования — - > периодичность техобслуживания — - > автоматическая заявка из системы. "Из", а не "в".

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

Кошерный путь такой: лифт передаёт телеметрию, и только. Система сама посчитает, когда создать заявку. Тогда появляется гибкость.
Вот что делать, если новые контакторы стали выходить из строя чаще, чем старые? Все лифты прошивать новыми пороговыми значениями? А так — внёс в систему новое значение, и заявки стали создаваться чуть раньше.
Хорошо, что сразу есть мобильная версия, и судя по скринам она выглядит нормально. Радостно, что у вас всё завязано на QR-коде, мне этот инструмент всегда кажется недооценённым, а он мощщщь, причём далеко не в рекламе. Как говорится, буду посмотреть подробнее, как минутку выберу.

QR коды для таких целей уже давно используются. Например, продвинутые фирмы с развитой сервисной сетью предлагают для своих сервисников аппликуху, которая по QR коду выдает на телефон всю инфу по устройству, запрашивает статус гарантии и позволяет сразу же получить доступ ко всей технической документации, причем относящейся к конкретной серии/модели.
Но ИМХО для этого в первую очередь нужно желание производителя.

У нас есть такая функциональность и даже лучше — называется электронный паспорт.

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

Для производителей же оборудования — это возможность собирать информацию по частным неисправностям, анализировать работу различных сервисных компаний (в сравнении), которые обслуживают их оборудование.
Пример публичного электронного паспорта оборудования можно посмотреть здесь.
Точно. По опыту, без мобильных приложений, управление сервисным обслуживанием вообще не летает. В этом случае за сервисных специалистов приходится работать офисным сотрудникам, информация не актуализируется вовремя, база заявок становится неактуальной в считанные дни и система умирает. Так что абсолютно согласен, что функциональная мобилка тут must have! Более того, платформа должна быть гибкая и настраиваемая, чтобы при оптимизации сервисного процесса можно было подстраивать бизнес-процесс в ИТ системе.
Любой хороший сервис испортят люди, которые будут этим пользоваться, или не пользоваться, просто забивая на кучу полезного функционала, это я из своей практики работы сервисным инженером))
Есть такое дело. Могу поделиться опытом коллег, что для того, чтобы сотрудники не саботировали процесс работы чрез систему, часть компаний, внедряющих решения, следуют подобным практикам:
1. Заявки направляют только в приложение (+ push)
2. Выстраивают систему мотивации, чем то похожую на мотивацию сотрудников отделов продаж: ставят в метрики параметры из системы. Например, лимитируют % заявок оформленных без нарушений. Это могут быть как геопозиция сотрудника в момент оформления акта выполненных работ (т.е. закрытие заявки на объекте). Закрыл вне объекта — система выдает алерт по данной заявке и она не будет учтена в KPI, так и качественно заполненный акт с указанием обслуженного оборудования. Не заполнил — минус «к карме» =)
3. А особо отчаянные мотивированные на результат руководители не выплачивают зарплату если по заявкам не заполнен акт выполненных работ
4. кто-то, на основе рейтингов в системе, платит премиальные ТОП3 лучшим и депремирует ТОП3 самых безответственных
5. Другие — завязывают процессы получения заявок исполнителями таким образом, чтобы сотрудники конкурировали за заявки (это особенно хорошо работает в схемах со сдельной оплатой)
В общем, если руководство замотивировано и понимает зачем компании нужна автоматизация сервиса, у сервисных инженеров шансов не остается. Более того, через пол года, компания уже вспоминает время работы без системы — как страшный сон. С внедрением систем автоматизации компания неизбежно начинает расти, оптимизируя ручные и неидеальные (исторически сложившиеся) процессы.
При всём уважении, с учетом того, что расчет SLA, автораспределение заявок, создание своих типов заявок и даже доступ к API у вас только на тарифе за почти 50 000 руб в мес, до мечты далековато. Точнее мечта уже очень дорогой получается. За такие деньги можно приобретать подписку на Enterprise решения
Only those users with full accounts are able to leave comments. Log in, please.