Строить иерархии активов в eAM/CMMS вокруг людей, которые ими пользуются
Проектируйте новые иерархии активов так, чтобы они были простыми, последовательными и удобными для навигации пользователями. Ограничьте варианты ввода данных до 8–12 опций в каждой категории, чтобы упростить ввод и повысить точность. Стройте конфигурации системы вокруг потребностей пользователей для повышения эффективности: обеспечьте быструю идентификацию активов и управляемые процессы ввода данных. Избегайте упрощений, которые исключают непроизводственные активы или создают чрезмерно детализированные иерархии, — они могут вызвать задержки и несоответствия в данных. Развертывание программного обеспечения требует четкого плана успеха. План должен быть сосредоточен на операционных выгодах, стандартизованных полезных данных и прочной культуре управления изменениями, но если конечная система неудобна для людей, то все остальное теряет смысл. Эта серия из трех частей охватывает шесть распространенных ошибок, которые могут задержать получение выгод от внедрения eAM/CMMS. В первой статье рассматривалось определение операционных выгод и предоставление полезной информации. Вторая статья была посвящена корпоративной стандартизации и изменению культуры. В этой заключительной статье внимание будет уделено двум ошибкам, более близким к цеху: созданию иерархии активов и процессу ввода данных.
Целью не должно быть создание идеальных данных. Цель — получить информацию, достаточно точную и последовательную, чтобы поддерживать принятие решений, не превращая систему в обузу.
Ошибка: недостаточная или слишком сложная иерархия активов
Все наряды и заявки на работу должны быть связаны с активом, поэтому успешная иерархия активов — это та, в которой все пользователи могут быстро найти наиболее подходящий актив при создании нового наряда или заявки. Чтобы развернуть систему быстрее, компании иногда идут на упрощения при проектировании иерархии. Если существует устаревшая CMMS, простейший путь — перенести старую иерархию активов без усилий по упрощению и стандартизации структуры. Унаследованные иерархии активов обычно содержат слишком много объектов или сложную структуру, поскольку со временем сотрудники добавляли элементы без стандартизации. В результате пользователи тратят слишком много времени, чтобы выбрать правильный актив или найти нужную ветвь в иерархии.
Если CMMS отсутствует, другой упрощенный путь — не включать все непроизводственные активы в иерархию. Это «невзорвавшаяся мина», которая срабатывает, когда требуется работа над активом, отсутствующим в иерархии. Администратору системы приходится бросать все текущие задачи, чтобы создать новый набор активов, чтобы можно было срочно оформить наряд и впоследствии добавлять похожие работы.
Структура иерархии активов должна быть последовательной и легкой для изучения пользователями. Должно быть достаточно уровней, чтобы находить наиболее подходящий актив, не создавая ощущения, что в большинстве случаев подходят два или три актива — признак избыточного числа активов. Решите, где иерархия активов заканчивается и начинается спецификация состава изделия (BOM) для актива. И помните: изменение иерархии активов после запуска программного обеспечения означает потерю части истории, что усложняет сравнения «до» и «после» изменений.
Рассмотрите пример структуры иерархии активов. Здания и территория содержат непроизводственные активы, управляемые по местоположению. Общие коммуникации содержат непроизводственные активы, управляемые по системе. Коммунальные системы включают систему распределения по всему заводу до того места, где коммуникация используется зданием, участком или линией. Заметьте, что у каждого участка и линии есть место для «общего» оборудования — гидравлики, моторов, вентиляторов, насосов или другого оборудования, типичного для этих уровней.
Производственные активы перечислены по участку, линии и секции. Подумайте, может ли секция быть нижним уровнем иерархии активов, или максимум на один уровень ниже в крупных заводах. Целью должно быть облегчение выбора активов при создании нарядов, а не упрощение формирования отчетов. Если наряд охватывает более одной секции, его можно оформить на уровне линии. Позже при подготовке отчета по секции, выбрав наряды для этой секции и линии, вы получите релевантные наряды для анализа. Вы можете использовать «ключевые слова» и идентификаторы хранилищ для дальнейшего сужения выбора нарядов в отчете. Если у вас слишком много активов, для получения всех релевантных нарядов в отчете придется выбирать любое число активов вручную.
Ошибка: слишком много вариантов ввода данных
Кто-то из команды внедрения захочет иметь множество вариантов для кодов активов и нарядов в стремлении получить очень детальную информацию. Помните: далеко не так много людей извлекают информацию из системы, как тех, кто вводит данные. Люди хотят вводить данные быстро, и если вариантов слишком много, они не будут тратить время на тщательный выбор и часто просто выберут первый код в списке. Цель eAM/CMMS — не идеальная информация, а информация, достаточная для взвешенных решений.
Для каждого кода наряда должно быть максимум 8–12 вариантов. Если нужна более детальная информация, используйте второй уровень выбора после того, как сделан первый выбор.
Например, может быть 12 типов нарядов, но первые шесть — те, которыми чаще всего пользуются рабочие, и они расположены в порядке частоты использования, что облегчает корректный выбор. Варианты с 7 по 12, скорее всего, будут использоваться планировщиком, который обычно создает такие наряды. Обратите внимание на варианты «операции», «уборка», «собрание» и «обучение» — завод мог захотеть фиксировать все непрофильные виды деятельности, которые могут выполнять рабочие. Вы можете решать, нужен ли вам такой уровень детализации.
Рассмотрите пример кодов отказа. Приведены 10 категорий кодов отказа, признанных в отрасли, и они расположены в общем порядке частоты. Параметр «неизвестно» стоит последним, чтобы отговорить людей выбирать его без анализа. Если нужна более подробная информация, добавьте второй уровень выбора после выбора одной из этих категорий. Это гораздо лучше, чем иметь 20–50 вариантов, через которые мало кто станет прокручивать список в поисках лучшего выбора. Даже этот набор из 10 категорий со временем даст полезную информацию по мере того, как точный ввод войдет в привычку.
Стройте иерархию активов и варианты данных вокруг пользователя. Система eAM/CMMS должна делать обслуживание более эффективным, а не добавлять лишние операции. Иерархия активов должна помогать пользователям быстро определять, где нужно выполнять работу, а управляемое количество вариантов ввода должно давать сотрудникам реальную возможность последовательно вносить полезную информацию.
Эти решения по конфигурации также иллюстрируют более общий урок из всех шести распространенных ошибок при внедрении. Успешное развертывание eAM/CMMS требует не только установки программного обеспечения. Заводам нужна ясная цель системы, полезная информация на выходе, общие стандарты по организации, непрерывное управление изменениями и система, спроектированная вокруг людей, которые ее используют.
Точка максимального напряжения для успешного внедрения должна приходиться на ранний этап, когда принимаются важные решения и выделяются ресурсы для их поддержки. Выгода — гораздо более спокойный запуск, потому что система поддерживает работу, а не становится еще одной проблемой, с которой заводу приходится бороться.
Лоуренс П. Чью, CMRP, CRL, в отставке, с 46-летним опытом в производстве в алюминиевой, сталелитейной и аккумуляторной отраслях, участвовал в корпоративных командах по надежности трех компаний. Он работал на пяти крупных и трех небольших заводах с заданиями по надежности и техническому обслуживанию, инженерии, эксплуатации, бизнес-процессам, ИТ и охране труда и окружающей среды. Среди компаний, где он работал: Arconic (Alcoa), Constellium (Alcan), U. S. Steel. Он помогал руководить модернизациями заводов в Китае и России по четыре года в каждой стране, где внедрял изменения в иных культурах и языковых условиях. Работал в ролях менеджера бизнес- и сервисных процессов, менеджера по надежности и обслуживанию и корпоративного консультанта по надежности. Имеет степень BSEE Университета Техаса в Остине.