Создание отдела АСУТП с нуля (организационные вопросы)

[Михайло]

Я сам специалист по автоматизации - самый нижний уровень АСУТП, т.е. датчики, исполнительные механизмы, ПЛК, текстовые и графические панели и в лучшем случае промышленные компьютеры... Со SCADA приходилось иметь дело, но в учебном варианте. Программирование на языках программирования высокого уровня освоил - знаю Delphi, программирование баз данных немножко пробовал - успешно. Есть и базовые знания о сетевых технологиях.

Вот недавно поступил в магистратуру Уральской академии государственной службы, буду учиться на менеджера (управление проектами). Нужно выбрать тему диссертации.

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

Я сам молод и полон энергии, но в то же время я скептик. Можно ли достаточно быстро (за 5-7 лет) набрать команду специалистов? Сколько человек надо набрать и что они должны знать? Сколько им надо платить по сравнению с другими сотрудниками?

Это еще малая толика организационных вопросов :)

[Jackson]

Только прошу, поймите мня правильно - ничего личного!

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

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

[Михайло]

1) "Государственная служба" - это лишь название. На самом деле учат настоящих менеджеров, просто с советских времен институт имел такой профиль - Высшая партийная школа. Думаете почему коммунистам 80 лет удавалось держать народ в кулаке? ;-)

2) Потом "создание отдела АСУТП с нуля" - это то же утрированно. Напоминаю, что я стою у истоков автоматизации в моем структурном подразделении. Мне удалось в какой-то степени поднять автоматизацию до современного уровня, переход с релейных схем на контроллеры. Я это сделал как технический специалист. Теперь ставлю задачу перед собой управленческую. Вам это башку сносит, а мне привычно как-то...

Ну что?

[Михайло]

Мы работаем на базе Сименса. WinCC Flexible в общем-то можем считать освоенным. Ступенька к освоению WinCC, а там уже до простых систем диспетчеризации недалеко. Это мое видение как технического специалиста.

Нужно сформировать видение управленческое. Тут возникают вопрос: к чему мы стремимся? Сколько человек нужно для решения задач? И т.д.

Как на вашем предприятии организована структура? Кто кому подчиняется и т.д.?

[Jackson]

Фраза

На самом деле учат настоящих менеджеров

снова повергла меня в изумление. :)

Только, я Вас очень прошу - ничего личного. Я изумляюсь не вашим стремлениям лично а тенденциям, которые происходят в отрасли и в стране. Иметь хорошие знания и организаторские умения это на самом деле хорошо и полезно, это все мы знаем. Но как этому можно научить - не представляю. И какую научную базу под это подвести - тоже. :)

[Михайло]

Только, я Вас очень прошу - ничего личного. Я изумляюсь не вашим стремлениям лично а тенденциям, которые происходят в отрасли и в стране. Иметь хорошие знания и организаторские умения это на самом деле хорошо и полезно, это все мы знаем. Но как этому можно научить - не представляю. И какую научную базу под это подвести - тоже. :)

Небольшое лирическое отступление:

А Вы знаете чему учат на менеджменте? Системный подход, обратная связь (контроль), иерархия систем, устойчивость систем, наблюдаемость, управляемость........

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

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

Вот, например, при управлении любым проектом (например, при проектом создания нового отдела АСУТП) по стандарту некоммерческой организации "Совнет" нужно управлять 10-ю функциональными областями управления:
1. Предметная область (в нашем случае стремимся создать отдел АСУТП)
2. Время (уменьшить)
3. Стоимость (уменьшить)
4. Качество (улучшить)
5. Риски (уменьшить)
6. Персонал (держать необходимое количество людей, увеличивать мотивацию, обучение)
7. Коммуникации (улучшать связь между участниками проекта)
8. Контракты/поставки (выбираем лучших поставщиков, вовремя и точно заключаем контракты поставок для проекта и т.д.)
9. Изменения (внесение изменений в базисный план проекта)
10. Прочие

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

[VADR]

ничего страшного, если при управлении недетерминированными объектами в бизнесе, вместо "ПИ-регулятора" поставить "П-регулятор"

Основной недостаток П-регулятора как раз то, что он никогда не приходит к заданию :D :D :D Отсюда его область применения - простые объекты, типа расширительных конденсатных бачков, где уровень конденсата может быть в пределах от 20% до 80%. В менеджменте тот же подход? Ужость.

2. Время (уменьшить)
3. Стоимость (уменьшить)
4. Качество (улучшить)

Быстро, качественно и недорого. Выбирайте 2 варианта. По-моему, скоро станет аксиомой.
А вообще, как всегда, всё начинается с постановки задачи, а она здесь в корне неправильна. Вы ставите задачу - создание отдела АСУТП и навешиваете на этот отдел пакет областей деятельности (проектирование, обслуживание и т.п.). Надо смотреть с обратной стороны: какие есть задачи и какими силами их решать: где-то нужен отдел, где-то привлечение сторонних организаций. К примеру, навешивать на свой отдел проектирование систем - решение обычно ошибочное.

[Михайло]

Основной недостаток П-регулятора как раз то, что он никогда не приходит к заданию :D :D :D Отсюда его область применения - простые объекты, типа расширительных конденсатных бачков, где уровень конденсата может быть в пределах от 20% до 80%.

П-регулятор оптимален для управления интегрирующим звеном. ПИ-регулятор хуже им управляет, если вообще не ужасно управляет. Не вешайте штампы на регуляторы, каждый регулятор годен для управления своих объектов и не годен для других.

В менеджменте тот же подход? Ужость.

Вряд ли. Я просто утрирую.

2. Время (уменьшить)
3. Стоимость (уменьшить)
4. Качество (улучшить)

Быстро, качественно и недорого. Выбирайте 2 варианта. По-моему, скоро станет аксиомой.

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

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

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

[Jackson]

Эту бы энергию, да на мирные цели (с)

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

В жизни ещё не встречал идеи бредовее, чем пытаться формализовать любой процесс, в котором участвует человек. :) И мне пока не удалось найти какую-то разумную связь между названием топика и содержанием вышесказанного в нём.

Длинная такая история - если лень то не читайте, правда длинно и витиевато:

Когда-то во время плав.практики на сухогрузе, где нам студентам кроме несения вахт, ремонтов и вылизывания парохода ещё приходилось слушать лекции про автоматизацию, от скуки во время лекции я вывел довольно стройную формулу, описывающую время реакции вахтенного механика на изменения параметров электроэнергетической системы корабля. Формула получилась в целом верная, в неё вошло множество параметров, например такие как год и место постройки судна, степень износа оборудования, последний порт посещения, мат.доход этого самого вахтенного, степень его адекватности, удовлетворённости, погодные условия и степень их влияния на механизмы и на вахтенного и так далее.... Вывод на два листа А4 с обоих сторон. Потом шеф - моряк со стажем, боевой офицер, инженер-конструктор и одновременно ещё член.корр.АН и академик (кстати он разрабатывал автоматику для наших кораблей-"шариков" типа "Юрий Гагарин" и заложил принципы построения и автоматизации электростанций всех наших боевых надводных кораблей за последние 50 лет - но тогда я этого всего ещё не знал), взял у меня конспект - как он считал как у самого примерного ученика - для составления зачётных вопросов (сам он конспекты не составлял). Уже потом наш зав.кафедрой рассказал мне, что шеф был в глубоком ступоре (он тоже с нами ходил и жили они в соседних каютах), увидев эту формулу: всё верно, красиво, и главное реально, но абсолютно бесполезно. Зачёт, экзамен и диплом получились как-то автоматом (хотя я для них работал получше многих на потоке), а шеф после той практики привлёк меня к постройке новых пароходов. Сначала схемы перерисовывать, потом разрабатывать, потом на ПНР (а в условиях пост-советской тогдашней разрухи, ПНР парохода сделать - всё равно что пятилетку по добыче угля за два года выполнить, бесплатно, в одиночку и вручную). Спустя какое-то время, под конец моего диссера, когда осталось только оформить "добавить воды", в каком-то споре с ним, он мне вспомнил эту формулку, и сказал очень важную вещь: "Жень, ну ты же ещё там в море понял и доказал, что обосновать, объяснить, доказать и формализовать можно абсолютно любой процесс. И вся эта наука есть ни что иное как удовлетворение собственного любопытства за государственный счёт. Так что ты решай. Если тебе нужна подпись "К.Т.Н.", а в будущем и "Д.Т.Н." под фамилией - не валяй дурака и доделывай диссер. Если хочешь работать с пользой для мира - строй свои корабли. Это разные вещи.". Собственно диссер я и забросил, потому что практической пользы от него никакой, кроме лычки под фамилией. Сейчас с шефом продолжаем общаться и иногда встречаться, хоть я и испортил ему тогда статистику по защищаемости. Зато помню трёх аспирантов, что со мной параллельно работали на свои темы - темы были серьёзные, технические, научной и экспериментальной базы побольше чем в моей теме: один на фондовой бирже торгует воздухом, второй - компьютерами, третий - приборами ОВЕН. С лычками "К.Т.Н." под фамилиями на визитках.

К чему я это всё? Да ни к чему собственно, ведь каждый свой выбор сам делает. При такой задаче я бы наверное пошёл бы людей искать и начальству необходимость отдела обосновывать, если бы он на моем гипотетическом заводе был бы нужен. Ведь от того что я такой диссер напишу - отдел не появится. :)

[Михайло]

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

Кто-нибудь расскажет, личные истории создания отделов АСУ? Как начинали и чем это закончилось?

[VADR]

Основной недостаток П-регулятора как раз то, что он никогда не приходит к заданию :D :D :D Отсюда его область применения - простые объекты, типа расширительных конденсатных бачков, где уровень конденсата может быть в пределах от 20% до 80%.

П-регулятор оптимален для управления интегрирующим звеном. ПИ-регулятор хуже им управляет, если вообще не ужасно управляет. Не вешайте штампы на регуляторы, каждый регулятор годен для управления своих объектов и не годен для других.

Типичное интегрирующее звено - уровень в ёмкости. И если техпроцесс допускает широкие изменения значения уровня (как, к примеру, тот самый расширитель конденсата) - действительно, оптимален П-регулятор. А если требуется получить +- 0,5% шкалы от задания (и при том колебание расхода среды не выше +-5% установившегося значения) - хотел бы я посмотреть на П-регулятор, который с этим справится.

2. Время (уменьшить)
3. Стоимость (уменьшить)
4. Качество (улучшить)

Быстро, качественно и недорого. Выбирайте 2 варианта. По-моему, скоро станет аксиомой.

Вы про треугольник "время-качество-стоимость"? Тоже не факт. Контр-пример: приходит грамотный управленец на разваленное хозяйство, где все делается из рук вон плохо, долго и дорого. Налаживает организацию работ так, что за меньшие деньги все всё делают быстро и качественно. Правило треугольника нарушилось.

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

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

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

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

[Михайло]

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

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

[Василий Иванович]

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

[Jackson]

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

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

В этой модели что-то явно лишнее. Если АСУ поставляются сторонними фирмами и есть свой отдел поддержки сторонних фирм - зачем ещё и самим проектировать, если есть сторонние фирмы.

С другой стороны, при создании своего отдела АСУ сторонние фирмы как-то отпадают. Могут кстати обидеться. :) Но - главное - что дежать свой собственный отдел АСУ есть смысл только если у него будет постоянная загрузка. И отдел этот, ИМХО, есть смысл иметь не проектный, а проектно-конструкторский - чтобы на стороне разве что сборку заказывать, и конструктора как-то ближе к реальности чем чистые проектанты.

То что у вас уже есть - как я понимаю, это отдел КИПиА, какие есть везде, занимается обслуживание поставленного.

[Jackson]

Да и любой интегратор ограничен в ресурсах. Тогда берем 2-3,..хх интеграторов.

А кто их координировать будет? А то получится что у одного на выходе 4-20 мА идёт другому на оптоволоконный вход.

[Василий Иванович]

тема избитая

Дмитрий, не обобщайте. Кажется, у Gartner читал, что до половины случаев отдачи услуг на сторону заканчивается неудачей по истечении трех лет. Здесь есть тоже свои риски, и думаю, Вам они известны.

[Jackson]

А кто их координировать будет? А то получится что у одного на выходе 4-20 мА идёт другому на оптоволоконный вход.

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

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

[Михайло]

На все сомнения отвечу кратко:
1) Завод вроде как самый крупный в мире по площади ;-) Работы хватит - около 50 цехов!
2) Я работаю именно в конструкторском бюро: мы рисуем "железки", это наш конёк! Также занимаемся приводами, контроллерами, панелями, но не более того. Я говорил про отдел сервиса АСУ - я сам там не работаю.

А теперь вопросы:
1) Сколько программистов SCADA на одного интегратора?
2) Сколько программистов ПЛК на одного интегратора?
3) С какого проекта лучше начать? Простой диспетчеризации?

[Михайло]

Ну согласитесь, все зависит от истории развития предприятия, начиная с советских времен. Не разрушать же созданное, не растрачивать накопленный опыт! Ну отделится КБ от предприятия, станет "дочкой" предприятия, а АСУ все нет и нет... Кто, если не мы?

[Jackson]

Ну если КБ безрукое и/или руководство не приветствует нововведения, то тут совершенно не зависит, присоединено КБ к заводу или отдельно существует.
В одном Дима прав - со сторонних лиц за комплексные заказы спрос совсем другой чем со своих. К тому же сторонние интеграторы в силу того что опыт имеют разнообразный и мыслят шире чем свои, замкнутые на собственном производстве и только.
Есть хороший пример: модернизацию ГА на СШГЭС проводила своя собственная контора РусГидро, хоть она и юридически была независима именно от СШГЭС. Результат все мы знаем.

[Jackson]

Ну согласитесь, все зависит от истории развития предприятия, начиная с советских времен. Не разрушать же созданное, не растрачивать накопленный опыт! Ну отделится КБ от предприятия, станет "дочкой" предприятия, а АСУ все нет и нет... Кто, если не мы?

Да я ж не против :) Делайте на здоровье. Мы ж просто про свои грабли :)

Знаете, по своей малоэнергетической части я множество раз находил подтверждение Диминым словам. Из последних примеров это как персонал скажем крупной птицефабрики решает обзавестись собственной газопоршневой ТЭЦ, изначально плюёт на любые проекты, закупает ГПГА, утилизаторы, автоматику, выполняет монтаж, вызывает всех на ПНР, а по приезду выясняется что они в принципе не могут получить то что хотели. А всё потому что на уровне главного энергетика решается "а что, нам самим слабО чтоли?". Если бы на начальном этапе заказчик хотя бы спросил, а как вообще такие вещи делаются, хоть у одного из поставщиков, то уже можно было бы измежать очевидных граблей. А в итоге заказчик имеет прорву дорогостоящего оборудования, которое смонтировано и отПНРено, но в принципе не работает так как от него ожидалось.
Бывают другие заказчики, они сначала обходят всех поставщиков, каждого терзают вопросами, и только когда появляется полная ясность что да как - начинаются закупки, монтаж и далее. И всё работает. Но опять есть грабли. Во-первых, таких встречалось намного меньше чем первых. Во-вторых - проекта опять нет или он мягко говоря не соответствует действительности и выполнен отвратительно, потому что у своих и другой работы полно - тоже на нужды родного предприятия. Проходит время, нюансы забываются, кадры меняются - и в случае малейшей неисправности все стоят на рогах и авральным методом пытаются вспомнить, а как же это должно работать....

Так что я тоже в общем не против - сами так сами, дерзайте. В случае успеха будете первой примерной проектной службой АСУ на предприятии.

[Михайло]

Да я ж не против :) Делайте на здоровье. Мы ж просто про свои грабли :)

Расскажите-ка, расскажите-ка!

Вот нашел материалы:
http://elzavod.ru/Otdel-ASU/ (Положения и должностные инструкции)
http://www.smartcat.ru/Important/bonussharesC_.shtml (Положения и должностные инструкции)
http://iprog.pp.ru/forum/read.php?f=1&i=526&t=526 (Старая тема форума 2001 года. Знакомые люди! :) )

[Михайло]

Самое интересное: у нас на предприятии есть отдел АСУП!

У меня вопрос наворачивается: кто работает с Simatic PCS7?

[Михайло]

Самое интересное: у нас на предприятии есть отдел АСУП!

Они тоже проектированием занимаются? :) ИТ-шные структуры вообще несколько иные. И ответственность у них ниже существенно.

Вроде программистов там куча...

[Jackson]

Самое интересное: у нас на предприятии есть отдел АСУП!

Они тоже проектированием занимаются? :) ИТ-шные структуры вообще несколько иные. И ответственность у них ниже существенно.

Вроде программистов там куча...

Сравните подчеркнутое. :) Программисты занимаются проектированием? Едва ли...