Siemens, по крайней мере ориентируясь на промышленную автоматику, действует "по старинке", скупая интересующие его бренды. Т.е. если есть более-менее успешная контора в каком-то направлении, то ей "помогают" сделать качественный скачок, включив в свою экосистему. Причем бизнес-процесс зачастую не ломают, но аккуратно перестраивают, чтобы работала цепочка поставок: использовались правильные контроллеры, привода,...
А проводили анализ, что дало такой эффект? Ну как-то странно выглядит, что процесс доставки лома сократился почти на четверть из-за RFID. Ну не колеса же эти метки крутят?
Круто выглядит. Реально круто. Но несколько вопросов осталось: - Кому взвалили на плечи следить за работоспособностью терминалов считывания? - Как проверяется работоспособность меток? Ситуации, когда метку в ее корпусе зальют чугуном по самое "перестала жить" вскоре могут начать возникать. - Как проработан процесс замены меток?
Я бы всё-таки покусился на главное - то есть на зарплату. Т.е. на то, что она не останется той же самой после вывода персонала в другую организацию.
Особенно, если его выводят не в дочку, а в стороннего подрядчика.
Про зарплату в НЛМК-ИТ в момент выделения точно скажу, что снижения не было, шло 1 к 1. Ну, оно и логично, иначе большинство бы не согласилось на такие условия. Предполагаю, что и в других подобных выделениях дочерних компаний поступают также.
Вот поиграть будущим ростом зп - это уже более реальный фактор.
Плюс, глобально, ИТ для не-ИТ компании (а производство материальной продукции, хоть стали, хоть тракторов - это всё-таки не ИТ) - это затратная, а не доходная, статья бюджета. А потому качание между "отдать всё на аутсорс" - "ой, аутсорс-то это недешево, оказывается, а без ИТ не получается, давайте таки своими силами", кажется, будет постоянно по каким-то критериям балансировать.
Вот это в самую точку. Я иногда не понимаю, на каком глобальном уровне мыслят топы, чтобы считать, что любой процесс (и даже не ИТ) можно поддерживать в нормальном состоянии, если поменять команду целиком. Вот вроде понятно, что просадка обязательно будет, но очень часто, кажется, верят в то, что это будет "лёгкая качка в штиле бескрайнего моря"
Тут, на самом деле, все не так уж и сложно. Я этом вопросом немного занимался. Основная идея - показатели. Непроизводственный персонал вытягивают из основной компании, чтобы было, чем вилять перед инвесторами. До оптимизации - завод на 30к человек производит 9 млн. т. стали в год. После оптимизации - 15к рабочих и 9 млн. т. стали в год. Производительность в выработки стали на человек выросла. Остальные бонусы тоже связаны со снижением издержек. Если человек работает на заводе, значит, ему обязательно положена спец. форма, чтобы находится в производственном помещении, даже если по долгу службы ему там находится никогда и не требовалось. После выделения в "дочку" - требование растворяется. Теперь спец. одежда нужна только тем, кому на самом деле нужно ходить по цехам. Дальше, если на какой-то проект нужен настоящий аутсорс, то его можно привлечь в обход директора дочерней конторы, который в этом вопросе может оказаться тем еще несговорчивым, т.к. деньги идут мимо. Верх мастерства - это заставить на открытом конкурсе директора демпинговать стоимость решения. Ну, и последний аргумент - если по дочернему направлению (охрана, клининг, ИТ) делать нечего, то дочку, уже лицензированную на область деятельности, можно направить на внешний рынок предлагать свои услуги и заниматься зарабатыванием денег. В НЛМК-ИТ такие прожекты были в свое время (про настоящее не скажу)
Да, это точно не мешки ворочать. Мнемосхемы на НЛМК давно уже были. Начиная от агрегатных, которые в АСУ ТП сплошь и рядом (Стан2000, который суть есть целый цех, лежит в мнемосхемах, наверное, с прошлого века), и продолжая цеховыми системами. Та же мнемосхема КЦ-2, приведенная на скриншоте - добросовестно спи... позаимствована с мнемосхемы оперативно-диспетчерской системы. А там эта мнемосхема работает, если не ошибаюсь, года с 2016. И интеграция с видеонаблюдением там тоже есть. Наверняка заслуги в вашей работе есть, и немалая - та же унификация библиотеки элементов. Но начинать пост с передергивания фактов... некрасиво.
Интересно написано, но глаз зацепился за упор на Java без подробностей. Неужели все пишется на голой JDK? Какой фреймворк под капотом? Spring, Micronaut, Quarkus, smth else?
А у контент-менеджеров прямой доступ к Git остался? Если нет, то как будет идти разбор проблемы "Кто поменял эту статью"? А если остался, то решение работает до тех пор, пока не появится один любопытный
Если копнуть совсем глубоко - то в основном это OPC (в большинстве своем OPC DA). Но непосредственно источником может быть отдельная система (агрегат/установка может иметь свою систему управления с собственным интерфейсом доступа к данным)
Ну так не надо смешивать в одной кастрюле разработку новой системы и нового дизайна. Это принципиально разные вещи. Умные люди придумали, что можно разделить фронт и бек в том числе и для того, чтобы поменять бек без затрагивания фронта. PS. Я знаю (не понаслышке), что сделать на НЛМК новую MES систему без переделки фронтовой части не получится, потому что ее нет, это двух-звенная архитектура, но был ли смысл лезть с модным дизайном в UI без UX? Это больше похоже на желание пустить пыль в глаза менеджерам заказчика, ибо изменения бэковой части они не смогут увидеть
Это логичное желание бизнеса - что потеряем, если закроем? Тот же пример с человеком - можно и руку отрезать, жить будет. Еще можно ноги почикать, и посадить за сидячую работу. <Сарказм> Еще и на брюках экономия </Сарказм> Но бизнес не догадывается, что может быть нелинейная зависимость, т.е. не просто x+y, а x + x*y, и проценты влияния здесь полезны только в моменте, при всех прочих постоянных. А такого в реальной жизни вряд ли можно найти
А почему нельзя этот прогноз внедрить в систему управления турбиной? Зачем заставлять оператора шевелить лопатками вручную, если можно сделать это автоматически? Разве индустрия 4.0 не про это?
Здесь вы немного неправы. Прокатные станы на НЛМК новые довольно активно строили и обновляли (и не только их). Просто касалось это станов холодной прокатки. И, кстати, там допуск по толщине играет большую роль, так как на холодной прокатке выходят на конечную толщину. Меньшая освещенность этих событий связана, наверное, с тем, что сами станы более компактные, не настолько масштабные, как стан горячей прокатки
Очень "опасный" текст для неокрепшего ума. Есть несколько неточностей, которые могут привести к принципиально неправильному пониманию работы kafka. А ведь идеи, заполненные в ней, очень эстетично и эффективно решают задачи, которые стоят перед разработчиками и потребителями продукта.
Про первую неточность уже написали:
Хотя в некоторых случаях продьюсер может направить сообщение в конкретный топик.
Продюсер обязан указать топик, в который он отправляет сообщение, но может также указать и раздел (партицию, partition) топика.
Ещё один блок, бросившийся в глаза:
здесь ключ не является обязательным и не несет для Kafka никакого смысла
Значение ключа несёт достаточно много смысла для kafka. Это основной признак группировки сообщений и маркер, что сообщения относятся к одной сущности. Через этот маркер работают механизмы распределения сообщений по разделам (partition, партициям), а это важный момент для соблюдения очередности получения сообщений в рамках одной сущности (если, конечно, не пытаться пойти в разрез с заложенной идеологией, сознательно или нет), отсюда же растут ноги у log compaction, и возможному снижению траффика для консьюмера.
Не совсем понятно, зачем нужна LDAP-синхронизация если в базу пользователи ходят под служебными учетками dbx-... Можете пояснить эту тему чуть подробнее?
Мой опыт говорит (понятно, что это легко может быть ошибкой выжившего), что в России в сертификаты не очень смотрят, поэтому получать такой сертификат или нет - решает каждый сам
Тема статьи о том, что быть руководителем скучно, а по факту разбираются ошибки начинающего руководителя. А по теме статьи? Почему разработчику на руководящей должности скучно?
Я для себя выделил следующие моменты: ритм задач принципиально другой, сфера деятельности отличается, да и скиллы совсем другие напрягать приходится (что неудобно и выматывает)
Siemens, по крайней мере ориентируясь на промышленную автоматику, действует "по старинке", скупая интересующие его бренды. Т.е. если есть более-менее успешная контора в каком-то направлении, то ей "помогают" сделать качественный скачок, включив в свою экосистему. Причем бизнес-процесс зачастую не ломают, но аккуратно перестраивают, чтобы работала цепочка поставок: использовались правильные контроллеры, привода,...
А проводили анализ, что дало такой эффект? Ну как-то странно выглядит, что процесс доставки лома сократился почти на четверть из-за RFID. Ну не колеса же эти метки крутят?
Круто выглядит. Реально круто.
Но несколько вопросов осталось:
- Кому взвалили на плечи следить за работоспособностью терминалов считывания?
- Как проверяется работоспособность меток? Ситуации, когда метку в ее корпусе зальют чугуном по самое "перестала жить" вскоре могут начать возникать.
- Как проработан процесс замены меток?
Про зарплату в НЛМК-ИТ в момент выделения точно скажу, что снижения не было, шло 1 к 1. Ну, оно и логично, иначе большинство бы не согласилось на такие условия. Предполагаю, что и в других подобных выделениях дочерних компаний поступают также.
Вот поиграть будущим ростом зп - это уже более реальный фактор.
Вот это в самую точку. Я иногда не понимаю, на каком глобальном уровне мыслят топы, чтобы считать, что любой процесс (и даже не ИТ) можно поддерживать в нормальном состоянии, если поменять команду целиком. Вот вроде понятно, что просадка обязательно будет, но очень часто, кажется, верят в то, что это будет "лёгкая качка в штиле бескрайнего моря"
Тут, на самом деле, все не так уж и сложно. Я этом вопросом немного занимался.
Основная идея - показатели. Непроизводственный персонал вытягивают из основной компании, чтобы было, чем вилять перед инвесторами. До оптимизации - завод на 30к человек производит 9 млн. т. стали в год. После оптимизации - 15к рабочих и 9 млн. т. стали в год. Производительность в выработки стали на человек выросла.
Остальные бонусы тоже связаны со снижением издержек. Если человек работает на заводе, значит, ему обязательно положена спец. форма, чтобы находится в производственном помещении, даже если по долгу службы ему там находится никогда и не требовалось. После выделения в "дочку" - требование растворяется. Теперь спец. одежда нужна только тем, кому на самом деле нужно ходить по цехам.
Дальше, если на какой-то проект нужен настоящий аутсорс, то его можно привлечь в обход директора дочерней конторы, который в этом вопросе может оказаться тем еще несговорчивым, т.к. деньги идут мимо. Верх мастерства - это заставить на открытом конкурсе директора демпинговать стоимость решения.
Ну, и последний аргумент - если по дочернему направлению (охрана, клининг, ИТ) делать нечего, то дочку, уже лицензированную на область деятельности, можно направить на внешний рынок предлагать свои услуги и заниматься зарабатыванием денег. В НЛМК-ИТ такие прожекты были в свое время (про настоящее не скажу)
Да, это точно не мешки ворочать. Мнемосхемы на НЛМК давно уже были. Начиная от агрегатных, которые в АСУ ТП сплошь и рядом (Стан2000, который суть есть целый цех, лежит в мнемосхемах, наверное, с прошлого века), и продолжая цеховыми системами. Та же мнемосхема КЦ-2, приведенная на скриншоте - добросовестно
спи...позаимствована с мнемосхемы оперативно-диспетчерской системы. А там эта мнемосхема работает, если не ошибаюсь, года с 2016. И интеграция с видеонаблюдением там тоже есть.Наверняка заслуги в вашей работе есть, и немалая - та же унификация библиотеки элементов. Но начинать пост с передергивания фактов... некрасиво.
Интересно написано, но глаз зацепился за упор на Java без подробностей. Неужели все пишется на голой JDK?
Какой фреймворк под капотом? Spring, Micronaut, Quarkus, smth else?
А у контент-менеджеров прямой доступ к Git остался? Если нет, то как будет идти разбор проблемы "Кто поменял эту статью"?
А если остался, то решение работает до тех пор, пока не появится один любопытный
Если копнуть совсем глубоко - то в основном это OPC (в большинстве своем OPC DA).
Но непосредственно источником может быть отдельная система (агрегат/установка может иметь свою систему управления с собственным интерфейсом доступа к данным)
Выглядит замечательно!
А MES у вас уже по всем основным производствам в таком виде развернут?
Ну так не надо смешивать в одной кастрюле разработку новой системы и нового дизайна. Это принципиально разные вещи. Умные люди придумали, что можно разделить фронт и бек в том числе и для того, чтобы поменять бек без затрагивания фронта.
PS. Я знаю (не понаслышке), что сделать на НЛМК новую MES систему без переделки фронтовой части не получится, потому что ее нет, это двух-звенная архитектура, но был ли смысл лезть с модным дизайном в UI без UX? Это больше похоже на желание пустить пыль в глаза менеджерам заказчика, ибо изменения бэковой части они не смогут увидеть
Это логичное желание бизнеса - что потеряем, если закроем?
Тот же пример с человеком - можно и руку отрезать, жить будет. Еще можно ноги почикать, и посадить за сидячую работу. <Сарказм> Еще и на брюках экономия </Сарказм>
Но бизнес не догадывается, что может быть нелинейная зависимость, т.е. не просто x+y, а x + x*y, и проценты влияния здесь полезны только в моменте, при всех прочих постоянных. А такого в реальной жизни вряд ли можно найти
А почему нельзя этот прогноз внедрить в систему управления турбиной? Зачем заставлять оператора шевелить лопатками вручную, если можно сделать это автоматически? Разве индустрия 4.0 не про это?
Здесь вы немного неправы. Прокатные станы на НЛМК новые довольно активно строили и обновляли (и не только их). Просто касалось это станов холодной прокатки. И, кстати, там допуск по толщине играет большую роль, так как на холодной прокатке выходят на конечную толщину.
Меньшая освещенность этих событий связана, наверное, с тем, что сами станы более компактные, не настолько масштабные, как стан горячей прокатки
Очень "опасный" текст для неокрепшего ума. Есть несколько неточностей, которые могут привести к принципиально неправильному пониманию работы kafka. А ведь идеи, заполненные в ней, очень эстетично и эффективно решают задачи, которые стоят перед разработчиками и потребителями продукта.
Про первую неточность уже написали:
Продюсер обязан указать топик, в который он отправляет сообщение, но может также указать и раздел (партицию, partition) топика.
Ещё один блок, бросившийся в глаза:
Значение ключа несёт достаточно много смысла для kafka. Это основной признак группировки сообщений и маркер, что сообщения относятся к одной сущности. Через этот маркер работают механизмы распределения сообщений по разделам (partition, партициям), а это важный момент для соблюдения очередности получения сообщений в рамках одной сущности (если, конечно, не пытаться пойти в разрез с заложенной идеологией, сознательно или нет), отсюда же растут ноги у log compaction, и возможному снижению траффика для консьюмера.
Не совсем понятно, зачем нужна LDAP-синхронизация если в базу пользователи ходят под служебными учетками dbx-...
Можете пояснить эту тему чуть подробнее?
Мой опыт говорит (понятно, что это легко может быть ошибкой выжившего), что в России в сертификаты не очень смотрят, поэтому получать такой сертификат или нет - решает каждый сам
Тема статьи о том, что быть руководителем скучно, а по факту разбираются ошибки начинающего руководителя. А по теме статьи? Почему разработчику на руководящей должности скучно?
Я для себя выделил следующие моменты: ритм задач принципиально другой, сфера деятельности отличается, да и скиллы совсем другие напрягать приходится (что неудобно и выматывает)
Вы не поверите, но этому анализу на НЛМК уже много лет. Это один из элементов производственной системы