13 подписчиков
Это четвертая часть про то, как работает наш сервис и как мы начинали его разработку.
Начав с измерения экономии электроэнергии в кВт*ч, мы в итоге пришли к тому, что стали мониторить полезную загрузку станков и предоставлять инструмент для ее увеличения. Получив информацию о том, что станок простаивает, мы через специально написанного чат-бота в «Телеграмме» спрашиваем у оператора причину простоя. Причины простоя настраиваются заранее, чтобы информация была релевантная и сопоставимая, иначе ее нельзя будет собирать в единую систему и анализировать.
Для понимания того, сколько информации или различных бизнес-сценариев можно получить благодаря данным о потребляемом объеме электроэнергии и ответу оператора, укажу лишь часть этих сценариев.
1. Оператор указывает причину простоя как «Отсутствие заготовок», после чего запускается сценарий уведомления начальника заготовительного цеха о том, что на станке N нет деталей для работы и станок простаивает. Начальник заготовительного цеха дает поручение сотруднику Х доставить на этот станок заготовки, сотрудник Х собирает тележку и везет заготовки на станок. Так как взаимодействие происходит через чат-бот, все действия, от приема заявки до назначения ответственного сотрудника, фиксируются в базе данных. С одной стороны, кажется, что ничего сложного в том, чтобы привезти заготовки на станок, нет. С другой стороны, между собой взаимодействуют минимум три человека и два подразделения, и если на любом этапе что-то пойдет не так, то ключевое оборудование может простаивать, а простой узких мест, по сути, равен простою всего завода.
2. Оператор указывает причину простоя как «Поломку станка», после чего запускается сценарий уведомления начальника ремонтного отдела о том, что станок N сломался. В зависимости от того, к какому классу оборудования относится этот станок, может быть несколько дальнейших сценариев. Если это ключевое оборудование, то в случае, когда к ремонту не приступают в течение 30 минут, идет эскалация уведомлений вплоть до уведомления директора завода. Если оборудование НЕ ключевое, то эскалации может и не быть, но у начальника ремонтного отдела будет информация о том, что сломалось на станке по мнению того, кто на нем работает, и начальник сможет выбрать специалиста, которому предстоит ремонтировать данный станок, а не гонять туда-обратно персонал с информацией о том, что и как сломалось. При этом вся информация о поломках собирается в базе данных, и по прошествии времени она позволяет принимать различные организационные или бизнес-решения о дальнейшей эксплуатации станков.
3. Зафиксирован простой, и оператор указывает причину простоя как «Переналадку». Облачное ПО «Энкост» запрашивает в «1С ERP» клиента номера заказов, которые ещё не были взяты в работу, получает их и предлагает оператору выбрать, на какой именно заказ он переключает оборудование. Далее, зная, какой номер заказа на каком станке находится, клиент может прогнозировать время готовности заказа и вносить корректировки, ставя важные заказы в приоритет (например, отдавая в ПО «Энкост» сначала только важные заказы, а уже когда они сделаны — все остальные). Также в рамках одного заказа фиксируется фактическое станочное время, что помогает правильно нормировать сменные задания. Часто бывает, что при 100%-м выполнении сменного задания фактическое станочное время работы не доходит и до половины. Иногда это нормально, а иногда становится откровением для руководства предприятия.
2 минуты
29 мая 2024