Программа для учета оборудования бесплатно

Популярные программы в категории Складской учет

Соглашение о конфиденциальности

и обработке персональных данных

1.1.Настоящее соглашение о конфиденциальности и обработке персональных данных (далее – Соглашение) принято свободно и своей волей, действует в отношении всей информации, которую ООО «Инсейлс Рус» и/или его аффилированные лица, включая все лица, входящие в одну группу с ООО «Инсейлс Рус» (в том числе ООО «ЕКАМ сервис»), могут получить о Пользователе во время использования им любого из сайтов, сервисов, служб, программ для ЭВМ, продуктов или услуг ООО «Инсейлс Рус» (далее – Сервисы) и в ходе исполнения ООО «Инсейлс Рус» любых соглашений и договоров с Пользователем. Согласие Пользователя с Соглашением, выраженное им в рамках отношений с одним из перечисленных лиц, распространяется на все остальные перечисленные лица.

1.2.Использование Сервисов означает согласие Пользователя с настоящим Соглашением и указанными в нем условиями; в случае несогласия с этими условиями Пользователь должен воздержаться от использования Сервисов.

1.3.Сторонами (далее – «Стороны) настоящего Соглашения являются:

«Инсейлс» – Общество с ограниченной ответственностью «Инсейлс Рус», ОГРН 1117746506514, ИНН 7714843760, КПП  771401001, зарегистрированное по адресу: 125319, г.Москва, ул.Академика Ильюшина, д.4, корп.1, офис 11 (далее — «Инсейлс»), с одной стороны, и

либо физическое лицо, обладающее дееспособностью и признаваемое участником гражданских правоотношений в соответствии с законодательством Российской Федерации;

либо юридическое лицо, зарегистрированное в соответствии с законодательством государства, резидентом которого является такое лицо;

либо индивидуальный предприниматель, зарегистрированный в соответствии с законодательством государства, резидентом которого является такое лицо;

которое приняло условия настоящего Соглашения.

1.4.Для целей настоящего Соглашения Стороны определили, что конфиденциальная информация – это сведения любого характера (производственные, технические, экономические, организационные и другие), в том числе о результатах интеллектуальной деятельности, а также сведения о способах осуществления профессиональной деятельности (включая, но не ограничиваясь: информацию о продукции, работах и услугах; сведения о технологиях и научно-исследовательских работах; данные о технических системах и оборудовании, включая элементы программного обеспечения; деловые прогнозы и сведения о предполагаемых покупках; требования и спецификации конкретных партнеров и потенциальных партнеров; информацию, относящуюся к интеллектуальной собственности, а также планы и технологии, относящиеся ко всему перечисленному выше), сообщаемые одной стороной другой стороне в письменной и/или электронной форме, явно обозначенные Стороной как ее конфиденциальная информация.

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

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

2.2.Каждая из Сторон предпримет все необходимые меры для защиты конфиденциальной информации как минимум с применением тех же мер, которые Сторона применяет для защиты собственной конфиденциальной информации. Доступ к конфиденциальной информации предоставляется только тем сотрудникам каждой из Сторон, которым он обоснованно необходим для выполнения служебных обязанностей по исполнению настоящего Соглашения.

2.3.Обязательство по сохранению в тайне конфиденциальной информации действительно в пределах срока действия настоящего Соглашения, лицензионного договора на программы для ЭВМ от 01.12.2016г., договора присоединения к лицензионному договору на программы для ЭВМ, агентских и иных договоров и в течение пяти лет после прекращения их действия, если Сторонами отдельно не будет оговорено иное.

2.4.Не будут считаться нарушением настоящего Соглашения следующие случаи:

(а)если предоставленная информация стала общедоступной без нарушения обязательств одной из Сторон;

(б)если предоставленная информация стала известна Стороне в результате ее собственных исследований, систематических наблюдений или иной деятельности, осуществленной без использования конфиденциальной информации, полученной от другой Стороны;

(в)если предоставленная информация правомерно получена от третьей стороны без обязательства о сохранении ее в тайне до ее предоставления одной из Сторон;

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

(д)если информация предоставлена третьему лицу с согласия той Стороны, информация о которой передается.

2.5.Инсейлс не проверяет достоверность информации, предоставляемой Пользователем, и не имеет возможности оценивать его дееспособность.

2.6.Информация, которую Пользователь предоставляет Инсейлс при регистрации в Сервисах, не является персональными данными, как они определены в Федеральном законе РФ №152-ФЗ от 27.07.2006г. «О персональных данных».

2.7.Инсейлс имеет право вносить изменения в настоящее Соглашение. При внесении изменений в актуальной редакции указывается дата последнего обновления. Новая редакция Соглашения вступает в силу с момента ее размещения, если иное не предусмотрено новой редакцией Соглашения.

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

2.9.Принимая данное Соглашение, Пользователь осознает и соглашается с тем, что Сервисами Инсейлс для обеспечения работоспособности Сервисов в целом или их отдельных функций в частности могут использоваться файлы cookie, счетчики, иные технологии и Пользователь не имеет претензий к Инсейлс в связи с этим.

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

Инсейлс вправе установить, что предоставление определенного Сервиса возможно лишь при условии, что прием и получение файлов cookie разрешены Пользователем.

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

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

3.1.Сторона, нарушившая предусмотренные Соглашением обязательства в отношении охраны конфиденциальной информации, переданной по Соглашению, обязана возместить по требованию пострадавшей Стороны реальный ущерб, причиненный таким нарушением условий Соглашения в соответствии с действующим законодательством Российской Федерации.

3.2.Возмещение ущерба не прекращают обязанности нарушившей Стороны по надлежащему исполнению обязательств по Соглашению.

4.1.Все уведомления, запросы, требования и иная корреспонденция в рамках настоящего Соглашения, в том числе включающие конфиденциальную информацию, должны оформляться в письменной форме и вручаться лично или через курьера, или направляться по электронной почте адресам, указанным в лицензионном договоре на программы для ЭВМ от 01.12.2016г., договоре присоединения к лицензионному договору на программы для ЭВМ и в настоящем Соглашении или другим адресам, которые могут быть в дальнейшем письменно указаны Стороной.

4.2.Если одно или несколько положений (условий) настоящего Соглашения являются либо становятся недействительными, то это не может служить причиной для прекращения действия других положений (условий).

4.3.К настоящему Соглашению и отношениям между Пользователем и Инсейлс, возникающим в связи с применением Соглашения, подлежит применению право Российской Федерации.

4.3.Все предложения или вопросы по поводу настоящего Соглашения Пользователь вправе направлять в Службу поддержки пользователей Инсейлс www.ekam.ru либо по почтовому адресу: 107078, г. Москва, ул. Новорязанская, 18, стр.11-12 БЦ «Stendhal» ООО «Инсейлс Рус».

Дата публикации: 01.12.2016г.

Полное наименование на русском языке:

Сокращенное наименование на русском языке:

Наименование на английском языке:

InSales Rus Limited Liability Company (InSales Rus LLC)

125319, г. Москва, ул. Академика Ильюшина, д. 4, корп.1, офис 11

107078, г. Москва, ул. Новорязанская, 18, стр.11-12, БЦ «Stendhal»

ИНН: 7714843760 КПП: 771401001

В ИНГ БАНК (ЕВРАЗИЯ) АО, г.Москва,
к/с 30101810500000000222, БИК 044525222

Контактный телефон: +7(495)133-20-43

Время на прочтение

Итак, начнем. Зачем ИТ-службе нужно вести свой учет компьютерного оборудования? Ведь вся компьютерная техника учитывается на счетах организации и данные об оборудовании уже есть в бухгалтерской системе. Зачем тогда отвлекать технических специалистов от разработки софта/администрирования систем/ремонта оборудования и грузить их «бухгалтерской» работой?
Дело в том, что собранные в бухгалтерской системе данные не спасут вас от проблем, например, при вирусной атаке.

«Заразить компьютер в корпоративной сети, поднять привилегии, получить доступ к домену администратора и одной кнопкой остановить деятельность компании любого размера» — так описал специфику работы вируса WannaCry его автор.

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

Но выход есть: прекратите собирать заявки на замену техники. Начните вести учет параметров, по которым техника должна попадать в программу модернизации (например, объём HDD, диагональ монитора, скорость печати принтера и т.д.). В этом случае вы сможете формировать перечни техники на замену автоматически из своей учетной системы. Нет заявок – нет проблем.

Чем еще поможет налаженная система учета ИТ-оборудования? Тем, что на любой, даже самый каверзный вопрос руководства вы сможете дать ответ уже через 5-15 минут, а не в «завтра с самого утра». Например, финансовый директор спрашивает: «сколько принтеров у нас в кладовке, сколько в ремонте, сколько у пользователей, сколько было утилизировано в этом году, в каких отделах принтера простаивают?». Если у вас учитываются стадии жизненного цикла ИТ-оборудования, то на все (!) эти вопросы вы дадите ответ в течении 15 минут. В противном случае придется собирать данные из разных источников в течении 2-3 часов (если не больше).

Полагаю, с вопросом «зачем нужен свой учет ИТ-оборудования» разобрались. Это меньшее из зол по сравнению с ситуацией, когда у вас только разрозненные данные бухгалтерского учета и сырые отчеты SCCM.

Давайте теперь спроектируем такую систему учета ИТ-оборудования, которая поможет решить обозначенные выше проблемы. Нам потребуется:

• определить границы учетной системы;
• разработать справочник категорий оборудования;
• разработать модель жизненного цикла;
• определиться с правилами идентификации оборудования;
• разработать атрибутную модель.

Шаг 1. Определить границы учетной системы

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

По моему опыту чаще всего в «застревают в бутылочном горлышке» компьютеры и оргтехника. Реже всего комплектующие и расходные материалы (как правило по ним хватает данных складского учета).

Шаг 2. Разработать справочник категорий оборудования

Чтобы было удобнее формировать отчеты, каждую группу техники нужно разделить по категориям. Например, вы решили наладить учет пользовательского оборудования. Берем группу «компьютеры». Из каких категорий она будет состоять? Персональный компьютер, ноутбук, планшет и т.д. Затем берем следующую группу – «устройства отображения» и делим на категории ее. В итоге у вас получится примерно вот такой справочник категорий:

Благодаря этому делению вы сможете быстро делать выборки из базы данных и получать отчеты как по группе «компьютеры», так и по каждой из категорий этой группы.

Шаг 3. Разработать модель жизненного цикла оборудования

Чтобы оперативно получать информацию о том, в каком статусе находится оборудование нужно разработать т.н. «модель жизненного цикла оборудования».

Советую начать с простой модели и детализировать ее по мере необходимости:

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

Шаг 4. Определить способ идентификации оборудования

Поскольку вам придется заниматься поиском и инвентаризацией оборудования, нужно заранее определить, как вы будете идентифицировать найденную технику. Мне известно пять способов идентификации:

Оптимальным способом я считаю маркировку техники этикетками со штрихкодом. Кстати, Yurich еще в 2013 году написал пошаговую инструкцию по изготовлению этикеток. Крайне рекомендую его статью к прочтению.

Шаг 5. Разработать атрибутную модель

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

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

На первый взгляд атрибутов слишком много и у персонала уйдет уйма времени на поддержание системы учета в актуальном состоянии. Давайте проверим, так ли это.

В зависимости от интерфейса учетной системы на первичную регистрацию каждого устройства потребуется 5-10 минут, на актуализацию данных 1-2 минуты. Предположим у вас в организации 350 пользователей, устройств для учета 1 000 штук. В год заменяется 20% парка техники (из расчета срока службы 5 лет), 10% парка проходит ремонт и модернизацию. Значит каждый год вам нужно будет:

• внести в систему 200 новых записей (200×10 = 2000 минут);
• два раза обновить статусы у 200 новых устройств (200x2x2 = 800 минут);
• два раза обновить статус у 200 выводимых из эксплуатации устройств (200x2x2 = 800 минут);
• два раза обновить статусы у 100 попавших в ремонт устройств (100x2x2= 400 минут).

Итого вы потратите 4 000 минут в год. Накинем еще 10% на непредвиденные перемещения. Получим 4 400 минут в год или 17 минут в день. Полагаю, это вполне приемлемые трудозатраты для поддерживания в актуальном виде системы учета на 1 000 единиц техники.

К тому же их можно сократить до 10-12 минут: технические атрибуты забирать из SCCM, данные о пользователе из кадровой системы. Но это вопросы архитектуры, их я планирую раскрыть во второй части статьи. Также во второй части я покажу, как оперативно организовать внедрение спроектированной системы учета. Пока же давайте сделаем паузу.

Прошу дать в комментариях обратную связь. Это поможет мне подробнее раскрыть интересующие вас вопросы при подготовке продолжения статьи.

Часть 2. Контроль состояния оборудования. Выполнение ТО и ремонтов

Далее мы параллельно расскажем о двух внедренных функциональных блоках: Контроль состояния оборудования и Выполнение ТО и ремонтов, т.к. для работы в данных подсистемах используется общее АРМ, разработанное нами в процессе внедрения.

Сначала представим спроектированную схему отдельно для Технического обслуживания (ТО) и отдельно для Ремонтов (текущих и капитальных).

Итак, непосредственно источником запланированных данных и для ТО, и для ремонтов являются документы План-график ППР. Далее в зависимости от вида ремонта по-разному выполняется обработка запланированных ремонтов. Принципиальное отличие видов ремонта определяется соответствующим реквизитом в карточке Вида ремонта (реквизит «Это техническое обслуживание»). Для ТО используется упрощенная схема обработки с меньшим набором документов, а именно, на основании запланированного ТО сразу формируется документ Акт выполнения этапа работ, который обрабатывается пользователями через АРМ.

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

Запланированные ремонты всех видов обрабатываются одним регламентным заданием, которое на основании запланированных ремонтов формирует документы определенного вида: для ТО – акты выполнения этапов работ, для ремонтов – Сметы (заявки на ремонт). Формирование данных документов происходит с учетом данных о горизонтах планирования, т.е. на какой период от даты запуска регламентного задания формировать данные документы. В системе создан регистр сведений Горизонты планирования, в котором в разрезе видов ремонта и ответственных служб указываются горизонты планирования в днях и какой тип документа создавать: Акт или Заявку.

А теперь давай рассмотрим процесс обработки (выполнения) запланированного ремонта или ТО. Мы будем рассказывать на примере ремонта, для ТО выделим отличия.

Итак, для работы с запланированными ТО и ремонтами разработано специальное АРМ «Техническое обслуживание и ремонт».

В АРМ «ТО и ремонт» обработка запланированных ремонтов первично выполняется инженером обслуживающего сервиса. Инженер видит все запланированные ремонты по своему сервису, а также удовлетворяющие условиям отбора, наложенным в области отборов АРМа. В АРМе работа ведется по одному выбранному заданию (активной строке заданий). Для того, чтобы начать работу с заданием, пользователь «берет В работу» задание, оно становится активным и для него доступны различные действия.

На этапе заявки инженер может уточнить перечень ремонтных работ, указать материальные затраты, необходимые для выполнения ремонта, трудовые затраты (какие трудовые ресурсы необходимы), инструменты и запчасти, а также Исполнителя работ.

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

Заполнив все данные по Заявке, инженер сохраняет внесенные изменения. Далее должен быть указан статус Обеспечения по Заявке: Требует или Не требует обеспечения. На следующем этапе значение данного реквизита используется при обмене с учетной системой и используется в подсистеме Обеспечение производства. Значение статуса обеспечения из учетной системы возвращается в ТОИР (это следующий этап в части настройки обмена двух систем, на данный момент ещё не запущен).

Обеспеченная заявка на ремонт передается непосредственно на объект для выполнения. В системе в этот момент инженер Создает Наряд на ремонт, т.е. выдает задание распорядителю. До этого этапа Состояние задания принимало значение «Запланирован», после создания Наряда (нажатие на кнопку Создать наряд в верхней части АРМа) задание автоматически меняет состояние на «В работе». С такими заданиями (статус которых «в работе») инженер уже не работает, а только контролирует ежедневно выполнение данных ремонтов. С заданиями в статусе «В работе» работает распорядитель через данный АРМ (ему доступны только такие задания).

Распорядитель ежедневно выдает задания исполнителям ремонта, печатая выбранные задания из системы) при этом доступна групповая печать выбранных заданий).

Ежедневно в конце дня распорядитель заносит данные по фактически выполненным ремонтным работам в систему. Факт выполнения (полного или частичного) ремонта в системе сопровождается созданием Акта выполнения этапов работ (нажатие на кнопку в панели действий АРМа). Состояние ремонта автоматически меняется на «Частично выполнен». На данном этапе распорядитель может проставлять процент выполнения ремонта (для возможности анализа состояния ремонта по ОР, если ремонт достаточно длительный по времени), а также указывать данные о гарантии, если она была предоставлена после выполнения ремонта подрядчиком.

Если указываются данные по предоставленной гарантии, то в дальнейшем при возникновении необходимости ремонта по данному ОР в период срока действия гарантии система оповещает пользователей о том, что по данному ОР действует гарантия.

Для того, чтобы полностью завершить ремонт по заявке, распорядитель нажимает кнопку Завершить, ремонт закрывается и уходит из области текущих ремонтов в АРМе.

Таким образом обрабатываются запланированные ремонты. Как видно из приведенного примера, набор действий по обработке заявки на ремонт используя разработанный АРМ – минимальный, при этом идет четкое распределение по должностям и ролям, как функциональных обязанностей, так и доступность определенной информации в системе (пользователи не делают и не видят «лишнего»).

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

При выполнении ТО, как правило, требуется зафиксировать значения контролируемых показателей. Это также выполняется через АРМ на отдельной закладке Измеряемые показатели. В дальнейшем значения измеряемых показателей могут быть использованы для принятия определенных решений по выполнению ремонта ОР.

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

Сложности в ходе внедрения и как их обошли

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

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

Зачастую на предприятиях нет карт ремонтов, перечень операций одного ремонта всегда разный. Здесь, как вариант, можно включить в карты ремонтов операции «с запасом» (то есть все возможные технологические операции) и в каждом конкретном ремонте исключать лишние операции.

Мы на проекте, столкнувшись со сложностью привязки технологической операций к технологической карте, приняли решение о создании «пустой» технологической карты. А в дальнейшем планируется компоновать технологические карты по мере выполнения ремонтов.

Эффекты от внедрения новой системы:

Основные работы по автоматизации завершились (на текущий момент идет постпроектное сопровождение). Основные эффекты, полученные от внедрения системы 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП:

• Наличие достоверных данные о текущем состоянии всех ОР в одной базе
• Автоматическое планирование графиков ППР на основании имеющихся нормативов и данных о фактической наработке
• Производственная программа «без иллюзий»
• Быстрое формирование управленческой отчетности

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

По данным различных исследований (Gartner, A.T.Kearney, ARC Advisory Group, SMRP) внедрение систем класса EAM (такой системой является 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП) окупается в среднем менее чем за 2 года.

Выгоды от внедрения (По данным исследования консалтинговой группы A.T. Kearney (в исследовании участвовало 558 компаний):

Повышение производительности работ по ТОиР — 29 %

Повышение коэффициента готовности — 17 %

Сокращение складских запасов — 21 %

Уменьшение случаев нехватки запасов — 29 %

Сокращение аварийных работ — 31 %

Сокращение сверхурочных работ — 22 %

Сокращение времени ожидания запчастей — 29 %

Сокращение срочных закупок ТМЦ — 29 %

Более выгодные цены на закупаемые ТМЦ — 18 %

ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП с учетной системой. Планирование ремонтов

В последнее время система 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП, позволяющая автоматизировать процессы, связанные с управлением ремонтами и обслуживанием оборудования, все чаще находит применение на производственных предприятиях различных отраслей.

1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП позволяет не только упорядочить работу ремонтных служб, сделать деятельность более прозрачной, но и минимизировать затраты на ремонты и обслуживание, уйти от аварийных ремонтов, сократить простои оборудования и, как следствие, повысить исполнимость производственных планов.

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

Какие же цели внедрения ставило руководство?

• Снижение рисков выхода из строя оборудования по причине несвоевременного технического обслуживания и планово-предупредительного ремонта.
• Получение актуальных данных о текущем состоянии объектов ремонта (ОР).
• Автоматическое планирование графиков планово-предупредительных ремонтов (ППР) на основании имеющихся нормативов.
• Получение возможности анализировать исполнимость Производственной программы на имеющемся оборудовании.

Что было сделано в ходе внедрения? Какие основные функциональные блоки были автоматизированы?

• Учет объектов ремонта (По комплектации, По технологической позиции, По Местонахождению)
• Планирование (Календарное, По наработке, Смешанное) ТО, текущих и капитальных ремонтов с учетом:

• Производственной программы (в том числе ее корректировок)
• Данных о фактической наработке оборудования

• Контроль состояния оборудования и диспетчеризация
• Проведение ремонтов (плановые/внеплановые)

• Создание наряд-заданий на основании графиков ППР
• Автоматизированное рабочее место (АРМ): фиксация данных об исполнителях, о текущем % выполнения ремонта, материальных затратах и запчастях, стоимости.

В данной части мы более подробно рассмотрим решение задач функциональных блоков 1-3. А в следующей – оставшиеся задачи.

Итак, начнем с блока Учет объектов

Один из главных объектов системы 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП — справочник Объекты ремонта. Количество объектов ремонта, с которыми работает Заказчик, достаточно велико. В проекте приняло участие 4 филиала, каждый из которых имеет от 10 до 30 укрупненных объектов обслуживания. Каждый укрупненный объект ремонта насчитывает от 500 до 1500 шт. составляющих объектов ремонта. Это серьезные цифры. Поэтому ещё на этапе проектирования было принято решение о разработке нового рабочего места (РМ) – Список объектов ремонта. Типовой функционал ввиду реализованного архитектурного подхода имеет значительные ограничения по производительности при обработке такого массива данных. Реализованное нами РМ сокращает длительность обработки одной операции от нескольких минут до нескольких секунд. Кроме того, в рамках выполнения данной задачи, была реализована ещё одна важная потребность: представление в режиме одного окна данных о занимаемой позиции ОР в разных структурах иерархии: По комплектации и По технологической позиции.

Структура иерархии позволяет один и тот же ОР классифицировать по различным сущностям. Наиболее распространенные и используемые на предприятии Заказчика – это структура По комплектации, которая позволяет получить информацию о том, какую позицию согласно паспорта оснащенности занимает тот или иной ОР, и структура По технологической позиции, которая позволяет получить информацию о том, какую функцию (технологическую позицию) занимает данный ОР. Для получения данных о положении ОР в разных структурах иерархии в типовой конфигурации необходимо было «переключиться» из одного режима (одной структуры) в другой. Для повышения эффективности работы пользователей мы реализовали возможность работы с данными в режиме одного окна.

В рамках проекта мы реализовали следующую структуру: 1-ый уровень – уровень укрупненного объекта обслуживания, 2-ой уровень – уровень тех. позиции (например, Буровой насос, как приведено на данном слайде), 3-ий и следующие уровни – уровни ОР и составных частей ОР.

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

Карточка объекта ремонта. Доступны для ввода и редактирования и просмотра различные данные, а именно:

• Данные по эксплуатации: Организация и Подразделение, которому принадлежит ОР, дата ввода в эксплуатацию, График работы, СПИ, Инвентарный №, Технологический №, Класс, Местоположение.
• Данные об изготовителе: Изготовитель, № Паспорта, Заводской №.
• Исполнители ремонта
• Дополнительные данные, такие как данные о гарантии, признак того, что ОР не участвует в планировании (добавленный реквизит).
• На отдельных закладках отображаются данные о показателях эксплуатации, нормативах планирования и пр. Более подробно рассмотрим в последующих блоках.

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

При этом реализована функция автоматического изменения положения ОР в структуре по местоположению, если Родитель (Буровая установка), в которую перемещается ОР, имеет отличное от предыдущего местоположение. Это касается операции перемещения в структуре по комплектации.

Автоматизированы процессы перемещения ОР между филиалами, в Оборотный фонд (склад) филиала, а также выведение ОР в Долгосрочный простой с сохранением данных о занимаемой тех. позиции и позиции в структуре по комплектации. Данные операции сопровождаются автоматическим созданием связанных документов, выполняющих изменение состояние ОР (как правило, В простое), пересчет плановой наработки ОР, отмену годовых графиков ремонта, а также отмену производственной программы для некоторых операций. Часть операций вынесена в выполнение в фоновом режиме, что позволяет значительно сократить время выполнения оперативных задач.

Интеграция 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП с учетной системой.

На нашем внедрении системы 1С:ERP и 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП функционируют как самостоятельные базы данных, между которыми настроен План обмена (через xml). Такое решение было принято потому, что обе системы на предприятии Заказчика значительно модифицированы и объединение данных систем могло привести как к снижению производительности, так и к возможным сложностям при обновлениях. Между системами 1С:ERP и 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП реализован обмен в части данных справочника Объекты ремонта. Первично данные по ОР заносятся в учетной системе при приобретении Объекта эксплуатации. На основании данных учетной системы в системе 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП автоматически создается новый ОР в специализированном положении: в том подразделении, в которое закуплен Объект, но без определения тех. позиции и положения в структуре по комплектации (на склад подразделения). После принятия к учету у Объекта появляется Инв.№ и доп. аналитика укрупненного объекта учета, к которому относится данный ОР. В этот момент средствами обмена в системе 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП ОР перемещается со склада (оборотного фонда) подразделения в оборотный фонд единицы учета. Далее ответственное лицо определяет новые ОР на занимаемую тех. позицию.

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

В системе 1С:ERP на предприятии Заказчика автоматизирована подсистема планирования производственного процесса, а также учет фактического выполнения производственной программы с отражением ключевых аналитик, таких как филиал, МВЗ, Проект, Технологическая операция.

Данные о производственной программе из учетной системы используются для загрузки в 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП план-графика ППР по отдельному виду ремонтов, который в последующем используется для анализа пересечений производственной программы с рассчитанными графиками ремонтов. Отчет о Годовой производственной программе по одному укрупненному объекту обслуживания. Данный отчет демонстрирует временной интервал в пределах года, в котором объект обслуживания задействован на производстве, соответственно в эти временные интервалы не может производиться капитальный ремонт любого ОР и Текущий ремонт отдельных Объектов/Узлов ремонта.

Данные о производственной программе загружаются в документы типа План-график ППР автоматически в процессе обмена. При этом создано два отдельных узла в Плане обмена: для загрузки годовой производственной программы и для загрузки корректировок (месячный план). Регламентом предприятия предусмотрены определенные даты, в которые должны быть подготовлены данные по годовой производственной программе и по оперативному плану. Годовой план выгружается пользователем, а вот корректировки к оперативному плану загружаются в автоматическом режиме по настроенному расписанию.

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

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

Наработка выгружается ежедневно по настроенному расписанию. Данные о фактической наработке ОР отображаются непосредственно в карточке ОР.

В рамках интеграции двух систем на данном этапе автоматизации также реализовано автоматическое создание/оповещение о необходимости зафиксировать Выявленный дефект. Такая операция возникает в случае, если в процессе работы объекта эксплуатации произошла его полная или частичная остановка, что было зафиксировано в производственной подсистеме. В этом случае исполнитель должен зафиксировать выявленный дефект в системе 1С:ТОИР Управление ремонтами и обслуживанием оборудования 2 КОРП. В случае, если исполнитель по каким-то причинам не отразил дефект в системе (забыл это сделать), при выгрузке суточного отчета система «проверит» был ли зафиксирован Дефект по данному объекту обслуживания и, если дефект не зафиксирован, то будет сгенерировано напоминание о необходимости выполнения данного действия. О назначении данного документа мы расскажем подробнее в блоке Выполнение ремонтов и ТО.

Теперь перейдем непосредственно к задаче составления графиков ремонтов. Для расчета и фиксации планируемых ремонтов предназначен специальный документ План-график ППР. При планировании ремонтов используется следующий подход: Годовой План ремонтов, который составляется в конце года, предшествующего году планирования, и Оперативный (месячный) План ремонтов, который составляется до 26-го числа месяца, предшествующего месяцу планирования. Оперативный План ремонтов представляет собой корректировку к годовому Плану ремонтов на данный месяц.

План-график ППР составляется отдельно для каждого Сервиса по ключевой аналитике учета – МВЗ. Общий План ремонта по ключевой аналитике на заданный период представлен в системе в виде отчета (будет продемонстрирован отдельно).

Теперь давайте посмотрим на нормативную базу, которая используется при расчете план-графика ППР. На предприятии Заказчика используется календарное планирование, планирование по наработке, а также смешанное (в большинстве случаев).

Норматив планирования указываются для элемента справочника Типовые объекты ремонта (ТОР), при этом каждый ОР в системе отнесен к ТОРу (указывается в карточке ОР). Нормативы планирования задаются для конкретного вида ремонта.

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

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

Итоговый рассчитанный план-график ремонтов представляет собой Отчет, который может быть выведен как в графическом, так и в текстовом виде.

При наведении курсором на строку диаграммы система позволяет получить расшифровку непосредственно до документа, которым был зафиксирован ремонт по данному ОР, при этом в документе «попадаем» именно в ту строку, которой был запланирован данный ремонт.

Текстовый вид отчета по графику ремонтов был изменен с учетом потребностей Заказчика. Отчет строится подекадно, может быть сохранен в виде файла любого текстового формата. Также для анализа и принятия управленческих решений был разработан ряд отчетов.

Итак, в данной части материала, мы рассмотрели такие темы, как Учет объектов ремонта, Интеграцию ТОИР с учетной системой и Планирование ремонтов. В следующей части поговорим о Контроле состояния оборудования и о Выполнении ТО и ремонтов.