Обсуждение

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

Ну да, главное слово тут "поток". Инженерное -- это операции на рабочих станциях, по которым проходит поток, и содержательная последовательность обработки на этих станциях. Есть ещё пограничная зона (например, конфигурационная логистика, то бишь configuration management -- когда нарезаются configuration items, размером больше, чем нужные инженерам детальки, но минимального размера в плане перемещения между рабочими станциями. Классическое определение -- http://ailev.livejournal.com/933073.html, мутность в отнесении к чистой инженерии -- http://ailev.livejournal.com/1005515.html, а вот отнесение к менеджменту/логистике в части соотнесения с потоком я делал тут, с попыткой обозвать "операционными практиками": http://ailev.livejournal.com/1026262.html -- "нарезать мир на объекты работы, к которым дальше применяются логистические процедуры -- т.е. куски работы, которые перемещаются между инженерными организациями"). Тут, конечно, опять шовинизм операционного менеджмента, системноинженерного менеджмента (есть и такое), логистики, и даже классического менеджмента. Но у логистики одной есть понятие "потока", "очередей" и т.д.. Хотя и там наезжают эти "менеджменты" (например, supply chain management). Я студентов сейчас учу так: вы должны разобраться в наличии тех или иных понятий, а уж какими они словами называются -- дело десятое. Но сами понятия должны знать, и распознавать их применимость к реалиям жизни. В случае "потока" -- должны понять, о чём речь, даже если это обзывают процессом, workflow, или конвейером, или сетью, или даже "силой, текущей по жиле" (пункт 3 в http://ailev.livejournal.com/505178.html). В любом случае, "логистика" тут не самый худший термин. Ибо даже "операционное управление" плохо ассоциируется с идеей "потока", а меня волнует такое слово, чтобы не нужно было специально объяснять необходимость удерживание в мозгах "потока" и "чего-топровода" как главной метафоры для занимающегося максимизацией "прохода" эээ... логистика (хотя я понимаю, что именно такого человека и называют менеджером, операционным менеджером, управляющим).

Лидерство есть не только у менеджеров (которым оно нужно для того, чтобы живых людей убалтывать на занятие ими мест на конвейере -- неважно, идут ли по этому конвейеру обрабатываемые и собираемые в единое целое механические детальки, или обрабатываемые и собираемые в единое целое 3D, прочностные, тепловые и прочие инженерные модельки). Лидерство есть и у системных инженеров -- чтобы убеждать (убалтывать: неполиткорректно, но сразу понятно) инженеров по специальностям следовать принятым решениям в части требований и архитектуры. я тут соглажусь с не помню как зовут ЖЖ-юзера, который ГИП, с которым Вы недавно "ругались", не любите Вы инженеров :) ибо такая позиция очень мешает инженерам работать

Про последнее, если позволите, прошу чуть подробнее. Поскольку либо не понял Вас, либо не согласен. В моем представлении конвейер для производства любой вещи конечно сложнее, чем сама вещь. Если, разумеется, мы не говорим об отверточной сборке (ну или использовании возможностей саморепликации живых систем). Но конвейер, впрочем также как и продукт, можно разделить и организационно и технологически на компоненты, причем в индустриальном обществе существует уже рынок компонентов. Что означает, что сложность конвейера как раз отверточной сборкой существенно сокращается. А вот сложность продукта - все-таки нет, поскольку на уровне дизайна нужно решать проблему совместимости, обслуживания, проверки на брак и на безопасность и т.п. Собственно, с этого тезиса как я помню и начиналась дискуссия про ISO 15 926. Как следствие, тезис Ваш, что проблема сложности здесь упирается в сложность конвейера, а не в сложность продукта, мне не понятен. Только если Вы имеете в виду всю совокупность существующих производственных и инжиниринговых мощностей, т.е. по сути уровень технологического развития цивилизации? Но в этом случае мысль ИМХО тривиальна, поскольку сомнительно, чтобы возможности производить сложные вещи не были лимитированы уровнем технологического развития, и вероятно, уровнем интеграции конструкторских и производственных мощностей. Уточните, плиз.

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

Сложность булавки и её изготовления существенно меньше, чем сложность организации 18 операций, потребных для её изготовления (там и проектировать не нужно). Сложность атомной станции существенно меньше, чем сложность разработки и комплексирования для организации проекта АЭС огромного числа требуемых производств. Чтобы разработать простую 3D детальку требуется довольно сложный софт CAD, а чтобы её произвести, нужно состыковать множество людей и множество самых разных софтов. Чтобы произвести всё это крайне быстро, крайне дёшево и крайне качественно, требуется поднять сложность производящей системы -- иногда в разы. ISO 15926 со всей его сложностью появляется именно для организации конвейера, он не работает внутри создаваемой целевой системы. Но основная сложность организации "конвейера" -- это как добиться качества и производительности коллективного многопрофессионального труда. Ибо тут проблемы от классической "вавилонской башни" с её разноязыковостью на уровне людей и на уровне софта, планирования (алгоритмически хороший план составить нельзя, там только на уровне эвристик можно работать, плюс непрерывное перепланирование из-за непрерывно меняющихся обстоятельств), дисциплины выполнения (нужно надёжное производство из ненадёжных людей и оборудования делать), плюс удерживать/включать в рассмотрение всю сложность целевой системы (ибо если не понимать, какова целевая система, то и нельзя подобрать правильные рабочие станции инженеров для её создания, и нельзя правильно организовать логистику перемещения информации, работ и материальных рабочих продуктов между этими рабочими станциями).

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

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

Вы уж даже своих перлов не помните? А они записаны и находятся в общем доступе... Смотрите ваше соло с 7:45 по 8:30 Цитирую вас же оттуда: "Он (менеджер) берет тушку, с конкретным весом, с конкретными кишками и с конкретными мозгами и засовывает ее в абстрактную деятельную позицию. Т.е. он их засовывает в рот и заставляет их в этой роли застрять." А что упорствовать, у вас нет аргументов. У вас один аргумент - заставить тушки застрять в деятельной позиции. Больше менеджер знать ничего не должен.

"он их [тушки] засовывает в роль и заставляет их в этой роли застрять". Вы даже не пытаетесь понять, о чём это я рассказываю, почему я это рассказываю, и что из этого следует. Почему именно я говорю "тушка", как связаны "роль" и "позиция", какая компетенция ответственна за ассоциирование "тушки" с "ролью" и выводом этой ассоциации в "позицию" (не менеджер, а лидер, кстати). Разговора с вами не получается, но я уже привык.

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

Если все собрались в одном цеху, то им легко сделать небольшое изделие (булавку). Если же речь идёт о хотя бы современном телевизоре, то нужно очень-очень много знать про то, как из работ отдельных поставщиков собрать работающий телевизор так, чтобы все его компоненты оказались совместимы друг с другом, пришли вовремя для сборки и в совокупности дали ещё и прибыль как производителю, так и розничной сети. Ну, и потом ещё не поломались так, чтобы работы по гарантии съели эти прибыли. Ваш пример "одной сборочной операции" невалиден, ибо чаще всего означает лишь оформление каких-нибудь налоговых условий конкретной страны. Если же речь идёт о конкурентоспособном продукте, то этих сборочных операций должно быть множество, а до этого ещё и проектирование должно быть предпринято, а до него рыночные исследования -- конвейер, он очень-очень длинный. Конечно, на одном предприятии обычно только маленький кусочек конвейера, но фишка в сложности стыков по длинной цепочке таких предприятий -- и не только в логистике (supply chain management), но и в проектировании/моделировании. Современная ситуация такова, что люди изобретают способы упрощения создания таких конвейеров -- прежде всего за счёт стандартизации интерфейсов подсистем-модулей, налаживания обменов информацией по требованиям, архитектуре, проекту в электронной форме, развитого планирования в логистике, повышения точности изготовления (чтобы при сборках не было операций "доработать по месту напильником"), и т.д.. Каждый такой приём работы упрощает создание конвейера, и создаётся обманчивое впечатление, что для по-настоящему сложных изделий его сделать очень просто. Ан непросто.

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

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

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

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

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

Просто чисто знаниями делиться так просто никто не хочет. А так обращайтесь. Я могу всю цепочку рассказать "от" и "до"... Какие последствия... когда... если то, то будет то... Всю логику принятия решения... обоснования какие и когда и кому... Как делается проект... с чего начинается... как планируется... как ужимается... как верстается... как отстаивается... как реализовывается... где нужно жестким быть, где мягким... ловушки... как расставлять... как самому в них не попаться... Как подстраховаться... Как переложить ответственность... Когда ее можно брать на себя... какие знания нужны... о чем можно забыть и не вспоминать... Всю всю логику. Вопрос только цены. И также вам скажет любой другой ГИП или главспец или тот, кто реально владеет этими знаниями. Должен же быть стимул какой-то, чтоб этими знаниями делиться. Я ж не спонсор. И меня никто не спонсирует. А от альтруизма я далек. Вы вот сколько готовы за такие знания дать, если они вам так интересны? Все же обсуждается. Северин предлагал 1 штука/ч за консультацию по интересующим вопросам. Все согласились, что это очень и очень мало, ввиду того, что эти знания потом будут тиражироваться... Так вот сколько реально за эти знания вы вот готовы отдать, чтоб их потом тиражировать?

и вы это пишете в ЖЖ человека, который свои знания рассказывает и показывает! *сарказм* Чем-то это всё похоже на анекдот про вымирание динозавров %)