На днях я опубликовал две статьи — про контроллинг и практическое применение знаний о системном мышлении.
Контроллинг говорит, что надо управлять на основе цифр. Это значит, что надо иметь цифры, надо брать их за основу для управления, и надо, собственно, управлять, осуществлять какое-то изменение, если того требует ситуация.
Системное мышление говорит, что надо наблюдать систему в действии, а не по отчетам, рассказам и документам.
Комбинируем контроллинг и системное мышление, получаем быстрое приведение системы в порядок. Быстрота, разумеется, зависит от сложности системы — количества элементов и связей между ними, доступностью рычагов влияния и их эффективности.
В данной статье будет рассмотрен примитивный пример этой комбинации. Примитивный — в смысле низкоуровневый, на очень простой системе, состоящей из одного простого станка и одного оператора. Насколько быстрым и удачным был результат — судить не буду, каждый сам для себя сделает выводы (если захочет, разумеется).
История произошла на одном из заводов — производителе автозапчастей.
Итак, стоит старый шлифовальный станок, на котором делают некую деталь для автомобиля.
Набираю обработанные детали для оценки качества, 4 партии по 100 штук, в разное время. Измеряю диаметр детали в одном из сечений — этот размер признан технологами как наиболее важный для данной детали с точки зрения качества.
Результаты измерения забавные — брак от 75 до 100 %. Ну т.е. диаметр почти всех деталей — за пределами поля допуска. Отечественный автопром 🙂
Обсуждаем с технологами, начальником цеха. Разумеется, они находят объяснение:
1. Старый станок, очень старый, списанный с другого завода;
2. Плохие шлифовальные круги, «сыпются как песок, форму не держат» — потому что дешевые, на дорогие руководство денег не дает;
3. «Ну а что мы можем сделать, сами же видите».
Объяснение они именно находят, в процессе разговора — они не знали, что гонят такой брак.
Обсуждаю со службой менеджмента качества (СМК) — это те люди, которые должны придумывать и реализовывать мероприятия по повышению качества продукии. Что говорят они:
1. Главное — о таком проценте брака они узнали от меня. Сами они смотрели на результаты выборочного контроля, которые давало ОТК;
2. Причины брака назвали ровно те же, что в предыдущем списке, от себя ничего не добавили;
3. Что делать дальше — понятия не имеют. Наверное, надо поставить задачу технологам, чтобы улучшили тех.процесс. Или станок новый купить (металлообрабатывающий центр за 4 млн евро, долго рассказывали, какой он замечательный, даже оснастку и инструмент может изготавливать).
В наших терминах что получается: цифр не было, управления на основе цифр не было. Работники СМК в цехе не бывали, систему в действии не видели, потому не понимали способов влияния на нее. Система, напоминаю, примитивная.
Я решил провести эксперимент — реализовать контроллинг на практике этой маленькой системы, т.е. получить цифру, и «совершить управление» на ее основе. Максимально близко к системе — встроившись в нее.
Встал рядом с рабочим у станка, говорю ему — давай мне каждую обработанную деталь. Одна делать обрабатывалась примерно 10 секунд, в течение которых рабочий ничем не был занят, так что я ему не мешал.
Я измерял каждую деталь рычажной скобой, и после измерения говорил рабочему, на сколько микрон покрутить регулировочное колесико на станке, которое отвечает за размер детали (не помню, как оно называется). Так мы с ним сделали 100 деталей, я пошел их еще раз измерять.
Результат оказался довольно забавным: разброс размеров был в 4 раза меньше поля допуска. Грубо говоря, если допустимый разброс — 0.6 мм, то у этой сотни деталей весь разброс уложился в 0.15 мм.
Процент брака, соответственно — ноль.
Решил попробовать еще раз, мало ли — вдруг случайность. Пришел на следующий день, к тому же станку, только с другим рабочим. Сделали то же самое — результат идентичный. Брака нет.
Продолжил эксперимент — делал все то же самое, только корректировку говорил рабочему не в микронах, а «добавь немного» или «убавь побольше».
Результат стал «хуже» — разброс размеров вдвое меньше поля допуска. Но процент брака все равно ноль.
Теперь о том, причем тут японцы.
В управлении качеством есть такой показатель, один из основных — индекс воспроизводимости, обозначается Cp. Поподробнее о нем я расскажу, если будет такая потребность, сейчас лишь приведу сравнительные цифры и краткую формулу.
Индекс воспроизводимости равен отношению размера поля допуска (контрольных границ цифры) к фактическому разбросу размеров. Там все немного сложнее, есть условия применения, расчета разброса и т.д., но все условия были соблюдены, процесс был стабилен по всем 7 критериям проверки ККШ, нормальность закона распределения подтверждена, проверяли на специализированном ПО (это предложение для тех, кто знает теорию статистического управления процессами).
Итак, в японском автопроме среднее значение Cp = 1.6. Чем он больше, тем лучше. Минимально допустимое значение для японцев — 1.33, для них это пограничное состояние между жизнью и смертью.
Теперь цифра нашего завода. После первых измерений, когда был большой брак, Cp колебался примерно от 0 до 0.25.
Для тех партий по 100 деталей, которые мы с рабочим изготовили, получилось Cp от 2 до 4. Наивысший показатель был в том случае, когда я давал корректировки размера в микронах.
Разумеется, в жизни нет особого смысла стремиться к цифре 4 — вполне достаточно 1.6.
Выводы можно сделать самые разные, цифры получились весьма показательными.
Например:
- Можно купить несколько средств измерения, раздать рабочим, добиться постоянного контроля — и стать как японцы. Одно такое средство измерения стоит 10-20 т.р. — это рычажная скоба, очень удобная штука, т.к. измеряет очень быстро;
- Можно купить одно средство измерения, нанять человека, который будет в процессе производства ходить туда/сюда, измерять и давать корректировки — и стать как японцы;
- И все это — без замены оборудования.
Контроллинга в этой примитивной системе не было во многом потому, что не было цифр. Цифр не было, потому что так написан тех.процесс:
- измерения должны были проводиться со слишком большой периодичностью;
- измерения должны были проводиться т.н. калибром. Не вдаваясь в подробности, скажу, что калибр не сообщает размер детали в виде цифры, результат измерения типа «булево» — годная или нет (в управлении качеством это называется «по альтернативному признаку», а когда есть цифра — «по количественному признаку»).
Результат измерения типа «булево» — это, конечно, тоже цифра. Если задаться такой целью, то на булево можно даже учет построить, и управление осуществлять. Например, если вы управляете программистом, и единственная снимаемая цифра — это «выполнена ли задача в срок», то у вас тоже измерение с типом «булево». И вы обкрадываете сами себя, связываете себе руки и лишаетесь возможности эффективно влиять на процесс.
В описанной системе, очевидно, была допущена ошибка при ее разработке — не заложена система обратной связи, влияния результата на процесс исполнения. Т.е., проще говоря, здесь не было контроллинга. Результат — брак почти 100%, который теперь стоит в тысячах автомобилей, бороздящих просторы нашей страны.
Ну а службы и люди, которые должны были управлять поведением этой системы, не могли сделать этого априори, т.к. не понимали: систему надо наблюдать в действии. Как делать детали на старом станке без брака? Это невозможно понять, глядя на отчеты ОТК, параметры работы станка в его ТТХ, разговаривая с технологами и начальниками, и даже имея сертификат ISO 9001. Нужно идти в цех — в систему. Об этом знает Toyota («сначала идите в гемба»), но не знает российский менеджер.
Что истории с каждой новой серией становятся всё фантастичнее и фантастичнее….
(1) все-таки процитирую одну хорошую книгу.
Можно с уверенностью говорить, что радио, в отличие от общепринятых мнений, изобрел именно Никола Тесла, и в этом не будет принципиальной ошибки. С таким же успехом можно утверждать, что отцом теории относительности является не Эйнштейн, а Хендрик Лоренц, и здесь опять найдется немалая доля истины. Ведь «преобразования Лоренца», которые показывают, что с приближением к скорости света линейные размеры тела сокращаются, масса увеличивается, а время замедляется, были выведены раньше. Но Эйнштейн взял на себя смелость расставить окончательные точки над «и». От тех, кто мог, но не решался это сделать, его отличало лишь одно качество — дерзость взять себе свое право.
Многие способны, но либо не знают об этом, либо не решаются СМЕТЬ, а поэтому рассчитывают получить Знание из чужих рук. Ничего плохого в таком стремлении нет. Каждый двигается своим путем. Действительно, отважиться переступить черту, за которой ты из магнитофона превращаешься в приемник, не то чтобы сложно, но весьма непривычно. Примерно, как впервые прыгнуть .с парашютом. Кому-то это просто не надо. Однако всегда найдется тот, кто не решаясь реализовать свою попытку, начинает думать: «Раз мне не дано, значит и ты тоже не лезь. Лучше меня, что ли?» Но ведь энергия нереализованного намерения осталась, ее надо куда-то девать… И тогда намерение направляется в другую сторону, например, на попытки обвинить других в каких-то профанациях, плагиате (не дай-то бог!), необоснованности и так далее. Нет ничего проще. Это один из способов подтвердить свою значимость и заявить о своем существовании. Но это далеко не лучший способ.
Еще интересней, когда читатель, обремененный увесистым грузом познаний и убежденный в том, что «знает практически все и даже немного больше», заявляет, будто для него здесь нет ничего нового. Пробежавшись поверхностно по тексту и обнаружив несколько знакомых понятий типа «намерение» или «важность», он торжествующе восклицает: «Да это же Кастанеда!» И, не разобравшись толком в сути дела, захлопывает ничтожную книжицу — для него это пройденный этап — поскакали дальше. Его не волнует, что на самом деле учение Дона Хуана и Трансерфинг — это две прямо противоположные грани реальности. В этом отношении я всегда чувствую свое глубокое невежество: перечитывая иногда фрагменты даже своих книг, открываю для себя что-то новое.
И опять, несмотря на то, что в данном случае имеешь дело не с полным тупицей, а, напротив, с эрудированным интеллектуалом, все равно возникает то же чувство растерянности и бессилия представить хоть что-то в свое оправдание… Бесполезно. У такого оппонента на ушах и глазах фильтры, которые пропускают только то, что согласуется с избранной им ролью: «Я могу кого-то раскритиковать, уличить, значит, сам я чего-то стою!»
Я не буду цитировать вам книжки… Я просто скажу что сам стоял у станка на машиностроительном заводе. И 4 ый разряд токаря и фрезеровщика получил в 16 лет…. Параллельно работал слесарем сборщиком прессформ для термопластавтоматов и гидравлических домкратов на 500 тонн в том же цеху собственными руками. Не говоря уже о производстве запчастей для ГШО. И знаю всю цепочку от выбора марки стали, до закалки и обработки конечных изделий….
Уже после… спустя 15 лет я автоматизировал 2 машиностроительных завода….
И про 100% брак, и про то как работает ОТК, СМК и про ISO знаю далеко не по наслышке… А читать про то как кто то пришёл и встал рядом с рабочим и говорил ему как настраивать станок звучит как то вообще не убедительно…
Первый станок за который меня поставили был 60 года выпуска , а мне тогда не было ещё и 15 лет и бил станок так сильно что на нём нельзя было точить детали с допуском меньше миллиметра… по сути на нём только фланцы сверлить… да обтачивать…. но кто бы мне другой доверил….
Я вам процитирую Станиславского «Не верю».
(3)
это не страшно, верить я не прошу и не призываю. Я призываю пробовать.
Но, судя по практике общения с вами, призываю не вас. Вы вроде бизнесменов ждете, которые расскажут о своей практике.
(5)
Откуда тогда столько цитат 🙂
(1) Вопрос не в том, является ли эта история фантастической, а в том, есть ли в ней более глубокий смысл, чем «а вот еще был такой случай». Тут, конечно, каждому решать для себя…
(7)
А он есть?
(8) Для автора — безусловно есть, для вас — безусловно нет. Такой вот дуализм…
Для меня эта история подтвердила одно — в полном бардаке программист 1С реально может повысить эффективность предприятия. Но лучше на предприятиях, где полный бардак, не работать…
(10) Согласен, не поменяется. Но автор рассказывает про программиста 1С…
(11)Автор немного преувеличивает возможности и заслуги программиста 1С.
(12) Нет, он просто пытается распространить собственный опыт как универсальный, и в этом ничего плохого нет — вдруг да кому и сгодится.
(13)
Как человек работавший на 3х машиностроительных заводах я не верю что там работают одни дураки, а пришёл Иван «программист 1С» собрал ОТК, СМК и тд. Всех выслушал, отшлёпал, пошёл в производство и настроил станок который производил от 75 до 100 % брака…. И с помощью рычажной скобы и книги по контроллингу вдруг наладил производство.
Извините но я сам стоял за станком, я получал материал, я сам рычажной скобой, микрометрами и тд проверял свои детали, подстукивал заготовку кувалдой в станке что бы «не било» и сам затачивал режущий инструмент, я сам ходил сдавать готовые детали в ОТК, исправлял брак и получал зарплату за готовые изделия…
Сходите постойте за станком… тогда будете более скептически относится к тому что кто то с улицы придя не зная даже что такое НОТ и как называется та часть станка которую он регулировал вдруг победил брак на производстве. Но самое удивительное почему этого никто не сделал из работников?
(14) Я вполне допускаю существование предприятий, где творится полный бардак, и программист 1С может наладить производство. Просто их очень немного. На производстве, причем автокомпонентов, я тоже работал, кстати, и алгоритмы оптимизации планирования производства с учетом ТОС мы вполне себе с директором по производству внедряли…
(15) тос это как раз из сферы 1с-ника , а обеспечить точность по соответствующим квалитетам — это задача станочника
(0) по сабжу собственно вот какой вопрос . Естественно всё проконтролировать невозможно, но можно и нужно контролировать только главное.
КТО должен определить, что является главным в системе ?
(0) +к (17) Может быть рынок является этим самым определителем ?
(16) Ну так и я об этом 🙂
(19) пример (0) был правда не совсем удачный . Если станочники косячат , и ОТК это все пропускает , все равно вылезет на сборке и пойдет волна или нет (может они там напильниками допиливают) В любом случае конечные потребители это определят. А может эта деталь на самом деле не такая и важная , а конструктор вместо 17 поставил 7 квалитет по запарке.
(0) еще один пример из жизни .
Занимался исследованием технологии производства оболочковых форм для ЛВМ на одном из оборонных заводов. ( была тема моей диссертации). Ужасно дорогой вид литья, брака было просто немеряно , но поскольку использовалось для изделий на несколько порядков более дорогих, то условно из партии 100 шт выбиралась одна на 100% годная !
Автомобили на нашем заводе теперь собирают высокоточные роботы!
Беда в том, что высокоточных роботов теперь собирают люди, которые раньше собирали автомобили…
(17)
Вангую цитату или ссылку на книги по японскому менеджменту про «муд»(muda)….. раз в «гембу» мы уже сходили….
(23) А потому, что без муды и не туды и не сюды…
(24) проще надо быть проще
слова типа теория системных ограничений , контроллинг , скрам и тп людей пугают . заметил сегодня в разговоре с одним директором
(14)
это ключевой вопрос, его наличие и определило мои дальнейшие изыскания.
Так вроде все всё понимают, особенно когда расскажешь итоговое решение. И даже лучше бы сделали. Но почему-то не сделали.
(15)
по моим наблюдениям — все предприятия таковы.
Вопрос в том, хотят ли они это видеть, признавать и улучшать. Проще и приятнее с головой в заднице пребывать.
В данном примере я в цех пришел не потому, что кто-то знал о бардаке. Я пришел проверить стабильность процесса изготовления, в твердой уверенности (окружающих и моей), что детали качественные, но могут быть элементы нестабильности. А оказалось в итоге, что о стабильности говорить нельзя, только о пригодности.
(16)
тос просто распространен в типовых конфигурациях 1С. В ЕРП, например, упоминается.
Также, как бух.учет, или объемно-календарное планирование.
(16)
у них плохо получается (если мы имеем в виду не оператора, а всю эту братию, связанную со станком, включая мастера, наладчика, нач.участка, нач.цеха, технолога). Потому что качество продукции зависит не только и, увы, не столько от станка, сколько от процесса работы. Ну вы это итак знаете, это азы управления качеством.
(17)
если вы о железяках, упомянутых в статье, то мне кажется нормальным мнение технолога, который знает, куда деталь вставляется и как потом эксплуатируется, включая статистику поломок. Это о параметрах качества деталей.
Если вы о системах, то на эту тему много книг написано, но универсального, подходящего под все ситуации, рецепта нет. В этом и сложность, и прелесть работы с системами.
Например, в системе работы программиста 1С я предпочитаю контролировать выработку и ее рост. Коллеги предпочитают контролировать сроки исполнения. Мне кажется, что коллеги ошибаются, т.к. зная только попадание в срок, никогда не увеличат выработку, от которой зачастую доход зависит.
Тема выбора показателей для контроля чуть лучше раскрыта в другой статье —
Главное, на мой взгляд, в этом вопросе — адаптивность. Выбрал показатель, попробовал через него управлять, посмотрел на результаты. Есть улучшение — хорошо. Нет улучшения — думай дальше, выбирай другой.
(18) если речь о показателях качества продукта, то да, рынок.
Точнее — потребитель. Качество — это степень соответствия требованиям потребителя.
Классический пример на эту тему — золотой унитаз.
(20) конечный потребитель определял, определяет и будет определять дальше. Как он это делает — на картинке приложенной видно.
(21) да, отличный пример.
Диссертацию защитили?
Я свою не дописал, она как раз была о теме данного сабжа.
(26) некоторых директоров наоборот радуют, от директора зависит.
Зависит от того, чем он увлекается. Ну, вы сами знаете.
(35) и на всех, где вы работали, работаете и будете работать — тоже.
Все же относительно. «Везде бардак» можно сформулировать как «везде есть что улучшить», и тогда перед нами открывается море возможностей. Хотите — пользуйтесь, не хотите — не пользуйтесь.
(37)
вот в этом звене цепочки ошибка.
«везде есть что улучшить» — с этим согласны?
(38) Конечно, везде есть что улучшить. Но значительные улучшения, сделанные не профессионалом в производственных процессах, например, каковым является программист 1С, возможны только при полном бардаке.
(39) звучит как приговор, хотя и убедительно.
Как думаете, а пытаться стоит?
И действительно ли нужно быть профессионалом в производственных процессах, чтобы качество продукции улучшать?
Чтобы качество работы программистов повысить, надо быть программистом?
Не является ли качество продукта и услуги абстракцией, применимой к любой деятельности?
(39)
Ну почему же…?
Может у них так заведено на предприятии что в станочники, технологи, мастера смены, начальники цеха, наладчики, ОТК, СМК, АУП нанимают клинических идиотов которые без программиста 1С не могут наладить работу одного станка на предприятии… по которому нужно просто постучать….
Наверное так то же бывает… но мне предприятия с такой концентрацией умственно отсталых на квадратный метр площади не встречались…
(41)
могут, но не делают. Не путайте, пожалуйста.
(40) Если на предприятии не бардак — программисту 1С некогда будет по собственной инициативе ходить по цехам, ему задач нарежут те люди, которые отвечают за качество, за производственные процессы и т.п. И это не теория, а тоже личный опыт. А вот уже в рамках поставленных задач возможна инициатива и предложение новых методик.
(41) даже так:
— они могут, но не делают;
— мы не делаем, потому что думаем, что не можем;
— мы думаем, что они не делают, потому что чего-то там знают такого, чего мы не знаем, и вообще это не наша тема;
— а оказывается, мы тоже можем;
— они, узнав об этом, оказывается, тоже могут;
— но уже поздно.
(41)
Потому, что иначе улучшения будут предложены теми, кто отвечает за результаты конкретных процессов.
(43)
ну это же вы сами себе рамки поставили, разве нет?
(45) 50-летняя (или 70-летняя) история управления качеством говорит, что не будут этими ребятами улучшения предложены, за редкими исключениями.
Единственное, что надо для того, чтобы улучшать — это захотеть улучшать. Дальше все само случится — и знания появятся, и единомышленники среди профессионалов, которые помогут.
(46) Что значит себе? На нормальных предприятиях программист 1С нанят, чтобы решать поставленные задачи, а не бродить по цехам и приставать к рабочим. Если он хочет рулить бизнес-процессами — это уже несколько другая должность.
(48)
С этой работой может справится только программист 1С. Как самый ответственный, а остальные они не хотят или не умеют… и книг не читают.
(47) Ну вот у меня другой опыт, вполне себе СМК предлагала нужные и полезные вещи, потому, что их зарплата впрямую зависела от показателей производства, и за каждое действительно полезное улучшение им полагалась премия.
(48) вы писали:
это же ваши слова, а не вашего руководства? Или ваше руководство пришло и сказало, что инициативу от вас будет рассматривать только в контексте поставленных задач?
(50)У меня вот то же.. .что бы программист пришёл и что то там улучшил в цеху в котором работает огромное количество людей. Профессионалов своего дела…. Возможно поверил бы если бы сам в цеху не работал.
(51) очень хорошая формулировка, я бы лучше не сказал.
Вы, я так понял, мир изменять не планируете?
(53) вы программистом 1С работаете?
(54) Я не планирую учить директора по продажам как правильно продавать, начальника склада как построить систему мотивации кладовщиков, финансового директора брать и отдавать кредиты вовремя и т.д. Они сами это умеют делать. Внезапно, да? Но если они поставят мне конкретную задачу, и я увижу, что ее можно решить более эффективно — я им это более эффективное решение предложу. Ну да, на менять мир не тянет, извините.
(55) Да работаю программистом 1С, правда не единственная моя работа. И я бы сказал что я программист-консультант, сертифицированный по автоматизации производства. А что?
(53) Мы оказывается исключения, на всех других предприятиях бардак…
(58)
Во всей России так… Наверное не хватает программистов 1С…. А до появления программистов 1С и книг по контроллингу вообще не понятно как эти предприятия работали…
(33) дописал и защитил. теперь диплом ктн как напоминание о бесцельно потраченном времени
(56)
а если они вам конкретную задачу не поставят, а вы увидите, что есть решение — предложите?
Например, вы участвуете в общем совещании руководителей, они обсуждают проблему, не могут найти решение, и вас не спрашивают. В такой ситуации предложите?
(40)
имхо(в любых более менее сложных технологических процессах ) — да 100%
(40)
тоже в зависимости от сложности программы
если программа простая (например обработка 1с ) , ее качество определяется в первую очередь самим разработчиком , а уж затем пользователем — конечны потребитем продукта
если сложная то в процессе участвует много людей (системные аналитики , тестировщики и т.д.) , но в любом случае все определяет потребитель исходя из соотношения цена -качество
(61)
Тогда что вы делаете на совещании «руководителей»?
(56)
передо мной за это извиняться точно не стоит.
(62) я не про качество продукта, а про качество процесса работы программистов.
Есть непрограммисты, которые могут улучшить работу программистов?
(65) вас не спрашивают по конкретному вопросу, т.к. вопрошающий находится в той же системе ценностей, что и вы — нужно быть профессионалом в области вопроса, чтобы иметь право голоса. Проще говоря, в голову не приходит, что у программиста есть ответ, потому и не спрашивают.
(63) если говорить о качестве — нет, если о скорости написания г. кода — да конечно
(67)
Именно… но программист 1С он же профессионал во всех вопросах и как обработку дописать и систему управления выстроить и технологию производства изменить и даже станок может отремонтировать?
(66)
вот о скорости написания кода ровно того же качества, который программист сейчас пишет. Тот же продукт того же качества, только вдвое быстрее.
Может непрограммист этому научить программиста?
(68) не во всех, а в абстрактных.
Но я не об этом спросил. И не вас вроде.
Но раз вы отреагировали — вы бы что сделали в такой ситуации?
(69) научить или простимулировать ?
(71) сделать так, чтобы программист производил вдвое больше. Если нужно — научить, простимулировать, мотивацию изменить, бизнес-процесс улучшить, границы переопределить и т.д.
(61) Странный вопрос, конечно. Нормальным считается, когда например на совещании директоров и собственников по стратегическим вопросам программист 1С присутствует? А если совещание более низкого уровня, если я на нем присутствую, то именно для того, чтобы предлагать эффективные решения.
(57) может непрограммист сделать вашу работу более эффективной, по какому-либо показателю?
(70)
Так вроде вы на мой пост ответили…
Зависит от того являюсь ли я:
На тех совещаниях где я бывал были профессионалы по своим областям… я отвечал за свои. И в другие не лез не потому что не хотел или не имел представление.. А потому что не являлся профессионалом. И мои измышления на основании прочитанных книг были далеки от действительности с которой ежедневно по 12 часов сталкивается нач. производством, нач цеха и тд.
(63) При чем в этой теме вообще программисты?
(74)Не знаю… но все «не программисты» кто работает с моей системой почему то считают что знают лучше меня как надо делать мою работу. Я им обычно предлагаю занять моё место и продемонстрировать. Пока желающих не было…
(72) если имеет достаточное влияние на программиста — может и даже не в 2 а в 3 или 10 . А вот чтобы понимать границы возможностей конкретного программиста этот человек сам должен быть профи.
(73)
что в этом странного? Если от него там польза есть, почему не позвать?
Но вопрос был не про стратегическое совещание, а про обычное — оперативку, например.
Один начальник говорит директору — такая-то проблема есть, не знаю что делать, будем думать.
Директор говорит — ладно, думайте, через неделю спрошу.
А вы знаете, как решить проблему, но не средствами автоматизации.
Скажете об этом? Сразу или потом.
(75) отлично, спасибо. Шикарный паттерн.
(79)
Директор говорит — ладно, думайте, через неделю спрошу.
А тот ему, а зачем ждать неделю? Давай спросим у программиста 1С.
Он же знает ответы на все вопросы… пора бы вообще его сделать «начальником».
(76) проверяем аналогии.
Если программист не может улучшить работу чужой области ничем, кроме автоматизации, то может ли непрограммист улучшить работу программиста.
Если нет — то ок, сидим дальше, код пишем.
Если да — то ага, а чем программист хуже непрограммиста?
(81) вы описали реальный сценарий, много раз происходивший в жизни. Только не в вашей, как я понял.
(83)
.
Нет конечно. Видимо потому что довелось работать на нормальных предприятиях с профессионалами своего дела….
(78) если непрограммист, имеющий достаточное влияние на программиста, может улучшить его работу, то почему программист не может улучшить работу непрограммиста?
Если рассуждать абстрактнее, то для непрограммиста программист — непрограммист.
(78)
не должен, а может. Если он профи, то границы понимает изначально. Если не профи, то экспериментально.
Вам же не надо быть профи в автомобиле, чтобы понять его максимальную скорость. Достаточно провести грамотный эксперимент в подходящих условиях.
(84) да да, все вокруг профессионалы, все предприятия нормальные, программист должен писать код.
Удачи!
(85)Смотрите вот еще пример с предприятием которым руководит директор , про которого я писал. Там достаточно сложная продукция — редукторы , тех процесс изготовления любой детали состоит из множества операций , контроль ОТК после всех критичных операций , но все равно брак иногда проскакивает (например в ночную смену) Там очень просто , если рабочий станочник обнаруживает , что к нему пришла заготовка с невыдержанными размерами он, идет к контролеру ОТК , дальше идет разбор полетов в систему вносится запись о браке, деталь возвращается на доработку или идет в брак. Если проскакивает брак в готовой продукции , она возвращается на завод , и ее стоимость с вычетом годных деталей , распределяется на все кто участвовал включая сборщиков и ОТК .
Данная система , выстроена таким образом , что каждый человек участвующий в процессе является заинтересованным лицом (как бы потребителем) , поэтому брака мало. Контроллинг в явном виде нигде не применяется , а скорее используется система мотивации
(85) возможно , но как в том анекдоте «.. есть ньюансы»
(87)
это и есть контроллинг — контуры обратной связи, влияния на систему. Деталей маловато, но первое впечатление: контроллинг плохой, т.к. объектом управления является человек, через доход — это лишь часть системы. И такое влияние не всегда мотивирует на улучшение системы. Скорее на более пристальный контроль, чтобы не пропустить брак. И, увы, пока страдает доход, страшно будет что-то менять в системе, т.к. на какое-то время она разбалансируется.
(88) конечно есть, бесчисленное множество.
Но в целом, согласны?
(79)
Да, мы явно живем в параллельных реальностях…
(89)
не совсем понял Контроллинг — это же вроде управление на основе цифр или нет ?
(89)
там довольно высокие заработки и размеры штрафов не так критично влияют на доход как, может быть, показалось и моего довольно сумбурного поста + различные плюшки в виде обедов , безпроцентных ссуд и прочего
(91) в целом да но выбор на роль командира команды разработчиков человека который в этом не понимает считаю нецелесообразным
(92) нет, реальности пересекаются, в точке «я — программист 1С».
(93)
да, и описанные вами контуры — это часть контроллинга. Только объект воздействия управления не тот, который нужен. Ну или вы не все рассказали.
Проверить несложно: если проблем с качеством становится меньше, то контроллинг эффективен.
(93)
плохо, получается полумера — слабая обратная связь. Лучше, чем ее отсутствие, но надо дальше улучшать.
(94) речь не о командире, а о помощнике, который сделает работу лучше. Командир — часть системы, один из объектов воздействия. Вполне вероятно, что единственно необходимый объект воздействия для непрограммиста.
(96)
поясните
(98) описанная вами система обратной связи управляет не производством, а обнаружением. Поэтому усилия концентрируются на обнаружении, потому что штраф за обнаруженный брак. В управлении качеством эта ошибка считается классической.
Например, выражается в формуле «предупреждение вместо обнаружения». В описанной вами системе тоже вроде предупреждение, только не производства брака, а отправки брака потребителю (следующей операции или клиенту).
Или еще плакат такой есть с лозунгом «качество нужно производить, а не обеспечивать в результате контроля».