Организация отдела АСУТП

[ozZ]

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

[Михайло]

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

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

[Михайло]

В случае отдела обслуживания АСУТП (не отдел разработки АСУТП!) основным выходом является услуга - "обслуживание АСУТП". Входом являются запчасти. Это укрупненно так. Если разбить услугу "обслуживание АСУТП" на составляющие вплоть до уровня "почистить шкафы от пыли", "протянуть отверткой клеммы", то будет получаться картинка более детальная и понятная.

Если интересует голая теория на этот счет, начните с диаграммы IDEF0. Выглядит это примерно так:

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

[ozZ]

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

Что касается ускоспециализированности темы, с одной стороны согласен, а с другой, по проектированию написано куча книг, каждая спроектированная АСУ должна должным образом эксплуатироваться, так что потенциально количество служб эксплуотации может быть равна количеству внедренных систем. :) Почему этот процесс нигде не освещается не пойму. Темболее вариаций на тему организации бесконечное множество.

Лично меня поразило обилие литературы по организации отдела продаж, а такая стандартизированная область как АСУ остается в неопределенности.

[Yury55]

Доброго времени. Я как то тоже не встречал информации именно о создании отдела АСУТП, но когда я работал на железнодорожном транспорте (в депо, там конечно своя специфика) было так. Нас работало 24 человека, т.е. 1 инженер, 1 мастер, 5 техников фанатов своего дела, 5 техников работали из за деньги, а 12 человек принеси подай. Подчинялись мы только главному инженеру, т. е. свой нос в автоматизацию никто лишний не совал и "дельных" советов не давал. Так я вот про что, на мой взгляд самое главное это что бы людям не мешали работать, а там дело пойдёт.

[Михайло]

Но сталкнулся с тем что не понимаю какие нормативные документы должен использовать отдел, какие журналы вести.

Здесь я согласен с Yuri55. Нафиг волокиту и бумажную работу. Главное правильно определить штат сотрудников и пусть они работают. Со временем начальник нового отдела определит основные проблемы и выработает руководящие документы и шаблоны документов.
А так навскидку (я не особо в этом разбираюсь):
- заявка на приобретение запчастей
- формуляр (журнал выполненных работ)
- наряд-допуск
- ...

[Никита]

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

[hell_boy]

Надо вначале написАть документ "Положение об отделе АСУ ТП", согласовывать с руководством и в работе опираться на него. За основу можно взять РД 153-34.1-04.504-01 "Типовое положение о цехе автоматизированных систем управления технологическими процессами (тепловой автоматики и измерений)". Не нравится это положение - ищется под свою отрасль или переписывается под себя. Второй по важности документ - Положение о разграничении полномочий и ответственности между ОАСУ и другими службами. Так как предстоит вклиниваться в существующую структуру предприятия. Остальные документы будут возникать по мере необходимости. Без документарной базы не стОит даже начинать.

[ozZ]

Спасибо господа, уже что-то. Буду начинать.

[perfect_gentleman]

Кажется, встречал рекомендации по структуре службы АСУ у Федорова в справочнике. Могу и ошибаться.

[logic-mir]

Надо вначале написАть документ "Положение об отделе АСУ ТП", согласовывать с руководством и в работе опираться на него. За основу можно взять РД 153-34.1-04.504-01 "Типовое положение о цехе автоматизированных систем управления технологическими процессами (тепловой автоматики и измерений)". Не нравится это положение - ищется под свою отрасль или переписывается под себя. Второй по важности документ - Положение о разграничении полномочий и ответственности между ОАСУ и другими службами. Так как предстоит вклиниваться в существующую структуру предприятия. Остальные документы будут возникать по мере необходимости. Без документарной базы не стОит даже начинать.

Очень верное замечание.
Я бы еще добавил, что организационная структура любого подразделения напрямую зависит от технологии управления работой этого подразделения. Т.е., до написания положения нужно определиться - по каким "правилам" будет работать отдел. Такой документ можно обозвать "основные положения о системе управления". Он должен в краткой форме содержать: кто, что, на основании чего делает.
А так процесс определения оргструктуры известен: цели - задачи - функции (определяются технологией управления) - объем работ - численность и квалификация работников (штатное расписание). Еще очень важно определиться с "системой" регулирования деятельности отдела. Это тоже влияет на организационную структуру.

[ozZ]

Вопрос на счет оценки деятельности отдела очень интересен, но и очень неоднозначен.

Кто какие реальные индикаторы может предложить?

У нас есть один - это количество бракованной продукции - вернее "Объем брака по вине отдела АСУ".

Можно еще время простоя контролировать.

Теоретически можно еще контролировать количество отказов - но принять такой индикатор все равно публично признать себя виновным во всем что было и что будет.



logic-mir " от технологии управления работой этого подразделения. Т.е., до написания положения нужно определиться - по каким "правилам" будет работать отдел." - можно немного по подробнее что Вы имели в виду.

[Yury55]

Теоретически можно еще контролировать количество отказов - но принять такой индикатор все равно публично признать себя виновным во всем что было и что будет.

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

[logic-mir]

logic-mir " от технологии управления работой этого подразделения. Т.е., до написания положения нужно определиться - по каким "правилам" будет работать отдел." - можно немного по подробнее что Вы имели в виду.

Под "правилами" я имею ввиду: выбранную организационную структуру, набор выполняемых функций и способ их выполнения.
1. Организационная структура вопрос достаточно сложный. Нужно исходить из 2-х задач, которые решает орг.структура. А это - разделение труда и координация действий. В Вашем случае наверное лучше начать с "координации". Как Вы собираетесь координировать действия персонала для достижения желаемого результата?
К примеру, если работники разной специализации (программисты, электроники, механики, гидравлики) "завязаны" на один локальный результат, то они прекрасно сами договорятся и выполнят работу. Им для этого начальник не нужен. Значит - минус один уровень управления. Если, в силу специфики, нужна координация работ между разными специалистами, то без контроля начальника и выдачи прямых указаний не обойтись.
Другой вариант координации действий, это обеспечение предсказуемости результата, т.е. - стандартизация: труда (требования к квалификации), процесса (регламент) или "выхода" (требования по качеству результата).
2. Выполняемые функции - перечень функций и их распределение между людьми.
3. Способ выполнения функций. Что-то может быть автоматизировано (в рамках MES, ERP, SCADA и т.п. систем), а что-то выполняться вручную. А это влияет на документооборот ( входящие, исходящие и внутренние документы). От этого зависит регламент (кто, что, когда, каким образом), объем работ, трудозатраты, численность.

Вот как-то вкратце так. :(

[Михайло]

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

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

[logic-mir]

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

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

Говоря о необходимости начальника я имел ввиду вопросы координации действий. Иногда он необходим, а иногда и не нужен - специалисты сами знают что и когда делать. К примеру, пит-стоп на формуле-1. Там за специалистами никакой начальник не успеет со своими указаниями. Но чаще всего начальник не требуется и координации ни от кого не ждут, когда действия персонала взаимозависимы, и все работают на один результат. Попробуйте установить для взаимозависимых специалистов разные критерии (показатели) для премирования. Дурдом будет обеспечен. Если же, к примеру, все участники процесса со стороны АСУТП будут отвечать за время простоя оборудования по вине АСУТП, то порядка будет значительно больше. Причем независимо от начальника.
Ну, а ответственность, она есть всегда. И как Вы совершенно правильно заметили - нужно определить, на каком уровне ответственный.
Я не имею практически никакого отношения к АСУТП (моё дело бизнес-процессы, проектирование, внедрение ERP и MES систем), поэтому все мои рассуждения носят общий характер. Поэтому извиняйте, если что не так.

[Бондарев Михаил]

К примеру, пит-стоп на формуле-1. Там за специалистами никакой начальник не успеет со своими указаниями.

Конечно, потому что там каждый "специалист" закручивает свою конкретную гайку, в строго отведенный промежуток времени. Пример красивый, но годится только для бизнес презентаций, ибо сколько десятков гаек и болтов, при условии плавающих сроков и прочих сюрпризов, даже в компаниях с отлаженными процессами, приходится закручивать инженеру АСУ ТП, тут может много кто рассказать.

(моё дело бизнес-процессы, проектирование, внедрение ERP и MES систем)

Если не сложно, в рамках форума, расскажите о паре успешных внедрений MES, хотя бы в формате бизнес-презентации. Очень интересно будет послушать

[Михайло]

К примеру, пит-стоп на формуле-1. Там за специалистами никакой начальник не успеет со своими указаниями.

Между тем, даже там есть своего рода начальник. Только он координирует не во время пит-стопа, а в промежутке между ними.

Вообще, это истина во все времена:

Никогда ничего не будет протекать гладко и быстро. Даже если команда профессионалов.

Если взять АСУТП, то, на мой взгляд, здесь самой важной функцией является планирование и лишь потом - контроль. Действительно, члены команды профессионалов часто берут функцию контроля на себя и тем самым частично освобождают начальника от этого. Это хорошо и в то же время, наверное, плохо... Так как начальник не сидит над душой у каждого, то он получается занимается в основном вопросами лишь тактико-стратегического характера.
Если взять наше предприятие, то у нас как раз фактически отсутствует ответственный за весь объем работ по созданию систем автоматизации. Формально ответственным является заместитель главного инженера, но с него, видимо, иногда никто не спрашивает и он не является профессионалом, который умеет управлять данным коллективом. Поэтому сроки растягиваются неимоверно. Иногда даже смешно: от идеи до воплощения проходит более 5 лет. Работаем на собственные нужды предприятия.

[logic-mir]

(моё дело бизнес-процессы, проектирование, внедрение ERP и MES систем)

Если не сложно, в рамках форума, расскажите о паре успешных внедрений MES, хотя бы в формате бизнес-презентации. Очень интересно будет послушать

Рассказать не сложно (хотя это не для этого форума, да простят меня присутствующие, которых это не интересует). Но что считать успехом, если мнения исполнителя и заказчика не всегда совпадают. Да и отнесение разрабатываемых систем к ERP или MES не совсем корректно. Мы занимаемся заказными разработками, поэтому делаем то, что просит заказчик не задумываясь о критериях отнесения системы к какому-либо типу. Расскажу о 2-х последних работах:
1. Единичное по-заказное производство (запчасти к оборудованию и оснастке, нестандартное оборудование).
Конструкторско-технологическая информация из системы "Лоцман" (АСКОН), а портфель заказов, считайте, из ERP.
Основные функции:
- расчет графика запуска-выпуска (с учетом запасов и состоянием незавершенного производства)
- расчет и анализ общей загрузки оборудования и рабочих мест (с учетом состава оборудования, сменности, ремонтов и т.п.)
- контроль обеспеченности запуска и запуск партий (с выпуском технологических карт, нарядов, требований на получение, накладных на сдачу продукции, ведомости комплектации)
- формирование сменно-суточных производственных заданий
- по-операционная регистрация выполняемых операций (полное или частичное выполнение, брак)
- контроль и регулирование хода производства (изменение даты выпуска, приостановка или разделение открытых партий, запуск внеплановых партий и т.п.)
Система работает, вопросы возникают раз в 2-3 месяца. Хотя я считаю, что работать эффективно система не может. Основная проблема в неполной конструкторско-технологической документации. Часть документации делается не в системе АСКОНа (не успевают) и соответственно запускают внеплановые партии (спланировать в системе их нельзя). Поэтому "плывет" и плановая загрузка. Но единственный критерий заказчика - это сроки выпуска. А система очередность оперативно выстраивает (при расчете производственных заданий) и это заказчика устраивает.
2. Серийное производство (холодная штамповка и чуть-чуть сборка, гальваника, сварка, около 3 тыс.деталей, порядка 800 единиц оборудования, 4 тыс.тонн металла расходуется в месяц). У заказчика есть система другого разработчика, но она внедрена только в части ежемесячного расчета графика запуска. Дальше внедрять сил и желания не хватило (и у заказчика, и у исполнителя). Мы предложили не вмешиваясь в существующее планирование организовать контроль хода производства. Поэтому система включила в себя функции от запуска партий в производство до их выпуска, с регистрацией не только выполнения операций, но и простоев оборудования.
Система "черпает" данные из других систем (нормативная база, материальное обеспечение, сбыт готовой продукции, складской учет, ТОРО) и выдает данные для системы расчета показателя ОЕЕ и его составных частей. Ну, отчетность требуемая само собой предусмотрена. Система ждет начала внедрения. В этой системе планировалось в этом году организовать частичный сбор данных с борта оборудования, но заказчик "лишних" денег не нашел. Автономно эти данные (оборудование работает или нет, главный привод включен или нет) в тестовом режиме уже собираются по беспроводной сети.
Застопорилась сейчас на изготовлении специальных столов для производственной зоны (иначе технику или сопрут, или разграбят). Да и ген.директор месяц назад сменился. Новый начальник начал организационные структурные изменения. В таких условиях, что из этого внедрения будет одному богу известно.
Куда еще можно отнести системы такого типа, как не к MES? Поэтому MES.
Вкратце, как-то так. Поэтому слова "успешные внедрения" мне никогда не нравились. Наверное потому, что у нас все внедрения проходят примерно так. Может это потому, что мы сами такие?

[logic-mir]

К примеру, пит-стоп на формуле-1. Там за специалистами никакой начальник не успеет со своими указаниями.

Между тем, даже там есть своего рода начальник. Только он координирует не во время пит-стопа, а в промежутке между ними.

Вообще, это истина во все времена:

Никогда ничего не будет протекать гладко и быстро. Даже если команда профессионалов.

Если взять АСУТП, то, на мой взгляд, здесь самой важной функцией является планирование и лишь потом - контроль. Действительно, члены команды профессионалов часто берут функцию контроля на себя и тем самым частично освобождают начальника от этого. Это хорошо и в то же время, наверное, плохо... Так как начальник не сидит над душой у каждого, то он получается занимается в основном вопросами лишь тактико-стратегического характера.
Если взять наше предприятие, то у нас как раз фактически отсутствует ответственный за весь объем работ по созданию систем автоматизации. Формально ответственным является заместитель главного инженера, но с него, видимо, иногда никто не спрашивает и он не является профессионалом, который умеет управлять данным коллективом. Поэтому сроки растягиваются неимоверно. Иногда даже смешно: от идеи до воплощения проходит более 5 лет. Работаем на собственные нужды предприятия.

Давайте не будем валить все в одну кучу. Первоначально речь шла о создании организации отдела АСУТП с нуля. И я сказал, что орг.структура решает две взаимосвязанных задачи - разделение труда между подразделениями и координацию работ. Этому учит теория. Ответственность и функции управления здесь ни при чем.
С разделением труда все понятно. Координация труда, по теории, бывает 5 типов:
1. Взаимная координация между работниками (без общего начальника над ними)
2. Прямой контроль (начальник над работниками)
3. Стандартизация уровня квалификации (Хирургу никто не указывает что и как ему резать в 1-ю очередь, а что в последнюю. Да и других подобных ответственных профессий много).
4. Стандартизация тех.процесса (Стандартный тех.процесс должен приводить к требуемому результату).
5. Стандартизация выхода продукта (Контроль на выходе исключает некачественный продукт).
На любом предприятии всегда присутствует набор различных механизмов регулирования. Отклонения от плана (норматива) могут быть, но на это есть функции управления, а точнее - регулирование (на основании обратной связи). Основные функции управления тоже определены в теории (сколько школ, столько мнений). Я придерживаюсь следующего набора: планирование, учет, контроль, анализ, регулирование.
И всю эту байду нужно учитывать при разработке организационной структуры управления. Но это в теории.