Спасибо за позитивную рецензию на мою т.з! Рад в Вашем лице найти единомышленника! Где я могу познакомиться с Асис (поделитесь хорошими ссылками)?
Про саботаж от IT: мои многолетние попытки зайти в головную компанию 1С для совместной корректной постановки задачи и разработки нужной в настоящей бизнес-среде платформы - все закончились снобистским отказом (ни разу даже на мои обращения не ответили)(((( А франчайзи 1С - не хотят тратить свои силы и время, когда и так все продается (у каждого уже есть какая-то своя рабочая бизнес-ниша).
В такой диспозиции, где:
IT отрасль цинично не хочет меняться и в текущей ситуации импортозамещения купается в золотом дожде от Предприятий и грантов от Государства, которые покупают/финансируют все что им не предложи
Предприятия не имея компетенций оценить качество навязываемого (других нет) IT продукта тратятся на "Дохлую лошадь", идя на поводу у IT отрасли (Предприятия не занимают позицию компетентного и требовательного Потребителя, берут что есть/дают, а не то что надо)
Государство - ровно в такой же позиции как и Предприятия, только еще и финансирует этот "банкет" для IT отрасли
я вижу только следующую стратегию выхода из системного кризиса: донести до Государства и Предприятий, что им за дорого продают "Дохлую лошадь", с тем, чтобы они перестали покупать у IT "то что есть" и финансировать цифровизацию этой "Дохлой лошади". Может быть тогда IT отрасль развернется к проблеме "лицом"?
IT отрасли нужно учиться, учиться и еще раз учиться, ибо страшно далеки они от потребностей рынка, и слишком долго они "почивали на лаврах" своих допотопных решений!
Спасибо Вам, Сергей! Если бы не Ваша добрая и профессиональная позиция, быстрая реакция и точное восприятие обсуждаемых посылов, мы бы так далеко не зашли!
А по поводу выхода на стратегический уровень - вот еще одна стратегическая эскалация в моем видении (на стратегию поведения IT отрасли в целом), если это интересно!
Тезисно:
(1) Бизнес-сообщество сейчас переходит через "точку бифуркации" (разворот на 180 градусов с условий бизнес-среды "спрос больше предложения" (этот период длился около 300 лет), на "спрос меньше предложения" (начался с 80х годов прошлого века)). Это означает, что старые решения для промпредприятий под среду "спрос больше предложения", нужно "выкинуть на свалку истории" и срочно переходить на альтернативные радикально иные решения (по организации производства, системе управления) под условия "предложения больше спроса". Предприятия, которые вовремя этого не сделают - окажутся в большой беде. Но такая постановка задачи в сообществе не обсуждается (почему - ниже), и это проблема_1.
(2) Промышленность (руководство и сотрудники предприятий, выросшие и сделавшие карьеру на старых решениях) очень сильно тормозит с этой вынужденной революцией, которую они должны совершить для выживания в новых условиях (тормозит в объеме 95%). По разным причинам эти ленивцы руководствуются безосновательной верой, что можно эту революцию осуществить через безболезненные малые улучшения (как эволюцию, а не революцию). Подробнее можно про это прочитать в моей статье https://centr-prioritet.ru/index.php?option=com_content&view=article&id=4449 И это проблема_2! В мире вообще (и в промышленности в частности) почему то царит идея, что все должно быть просто, если предлагается сложная для реализации конструкция - это автоматически маркируется как "неправильная идея".
(3) IT отрасль, вместо того, чтобы возглавить/помочь этому переходу, саботирует эту ситуацию и эту потребность. Все разработанные на сегодня IT продукты (средства описания/моделирования деятельности организации в виде нотаций BPMN и IDEFx, продукты по управлению(ERP, MES) Предприятиями и Холдингами (не важно от каких вендоров SAP или 1С) - это все разработки под среду "спрос больше предложения" (бесполезные вплоть до вредные в новых условиях), т.е. в терминах индейцев Дакота - это все "Дохлая лошадь", которая в современной бизнес-среде "скакать с нужной скоростью" не сможет от слова совсем . И вместо того, чтобы переделать эти продукты под новые условия, отрасль лишь рационально (покупают и эксплуатируют же старые решения) и цинично (в явном виде отказываются от переработки существующих решений, зачем сейчас тратить деньги на разработку, сейчас нужно собрать все сливки с продажи старых разработок) наживается на промышленности, продавая им ненужный и вредный в новых условиях товар. И это проблема_3.
(4) Такая позиция IT отрасли по отношению к проблематике промпредприятий уже привела к ситуации "автоматизации хаоса" - внедрения ERP&MES решений под среду "спрос больше предложения" никак не способствуют нужному для выживания росту конкурентоспособности, потому что они автоматизируют "Дохлую лошадь". Этот безумный "не приходя в сознание" (не понимая смыслов) маркетинг "Всем автоматизироваться", а сейчас "Всем цифровизироваться", приводит к тому, что цифровые двойники, интернет вещей , ИИ и прочая навешиваются на неправильные/устаревшие решения (на "Дохлую лошадь"). Т.е. вслед за результатом "автоматизация хаоса" мы стремительно летим к "цифровизации хаоса" и IT отрасль это движение осознанно или нет, но возглавляет((( И это проблема_4
Извините, конечно, что мы на такие "верха" забрались, начав обсуждение с узкотехнического вопроса борьбы с рассогласованием в организациях - у меня "накипело", и видимо из-за этой профдеформации я везде вижу "следы" опасного проявления описанных мною проблем (1,2,3,4), и поэтому любое обсуждение в моем исполнении - это "сваливание" на мои "болячки"(((
И на вопрос из названия Вашей публикации "Чем болен средний бизнес? Статья 6. Как описание может остановить хаос многомиллионных потерь", мой ответ для 95% производственных компаний звучал бы так: тем, что применяемые ими подходы к организации производства ("лекарство" - "Бережливое производство"), к системе управления предприятием ("лекарство" - "ISO серии 9000"), к управлению несоответствиями ("лекарство" - "ISO 16949") требуют радикального переосмысления/перестройки. Описывать эти проблемы и решение проблем, нужно на языке перечисленных "лекарств" (Дракон спроектировать прикладные решения методом интервью, лежащие в основе перечисленных "лекарств", не способен от слова "совсем" (это все равно, что предположить, что методом интервьюирования физиков можно было разработать решение в виде "Теории относительности"), т.е. не поможет/бесполезен). Для 5% производственных компаний, кто это "лечение" успешно прошел, по определению "хаоса многомиллионных потерь" у них уже нет. Но тогда и описание на языке Дракона принесет таким предприятиям пользу, но уже не в виде "многомиллионных эффектов". Именно поэтому я и включился в дискуссию к Вашей публикации.
У нас с Вами оценки "с точностью до наоборот"))) Моя практика (35+ лет) прикладного консалтинга промышленных предприятий/холдингов/цепей поставок, говорит о том, что территория 1,2.3 - это 95%, а Ваша оценка как эксперта из IT отрасли этой области - 5%! Мы (я - эксперт "Прикладного мира", Вы - эксперт IT мира, который должен удовлетворять потребности Прикладного мира) на одного и того же "слона" (состояние промпредприятий и что им для улучшения нужно делать) смотрим с радикально разных точек зрения!!!! А должно быть расхождение в долях процентов (в идеале - совпадать)! Вот это ТОЧНО БОЛЬШАЯ И НЕ ТОЛЬКО ФИЛОСОВСКАЯ ПРОБЛЕМА!!!!
Кстати, для диагностики состояния и определение областей для улучшения в Прикладном мире есть свои "языки" (международные стандарты ISO серии 9000 и ISO/TS2 (16949), концепция "Бережливое производство"). Почему IT отрасль на их основе не создает (де факто ИГНОРИТ!!! то, чем реально работает Прикладной мир) языки для диагностики и описания AS-IS TO-BE, а выдумывает "велосипеды" в виде нотаций BPMN, IDEFх, Дракон ..?!
Пользуясь Вашим приемом))) написал (сейчас находится на модерации) публикацию с разъяснениями своей позиции. Правда, т.к. я новичок на Хабре, комментарии к ней будут недоступны, пока я не смогу получить соответствующий статус одобрения.
Вы: Разве при функциональном подходе нет процессов, в том числе сквозных и кросс-функциональных? Куда они делись?
Описать как процесс можно любую деятельность (бумага все стерпит и IT отрасль в этом впереди планеты всей), однако наличие этой бумажной сущности никак не изменит физику реализации действий при функциональном подходе к управлению (доминанта связи Начальник-Подчиненный, а процессное управление - это доминанта связи Поставщик-Потребитель). Поэтому мой ответ как практика (35+ лет прикладного консалтинга промышленных предприятий) - эффективных процессов при функциональной модели управления нет (это как быть немножко беременным). Дам, чтобы пояснить свою т.з., еще такую графическую аналогию: для описания функционального подхода к управлению нужен конструктор из элементов треугольников, для описания процессного управления конструктор нужен другой - в нем элементы кружочки. Попытка описать сущности Функционального подхода инструментами для описания Процессного подхода к управлению, это попытка построить из элементов кружочки, конструкцию из треугольников!
На остальные тексты в Вашем посте мне нужно "много букв" - они в модерируемой публикации. Кратко функция и процесс, разные сущности (треугольники и кружочки) для разных по назначению и области применения управленческих конструкций (попытался эту разницу в публикации показать)
Аплодирую стоя Вашим примерам 1,2,3 когда описание AS-IS не нужно!
А вот то, что написано после, почему то противоречит Вашим же 1,2,3!?
Посмотрите какая получается конструкция Вашего комментария: Если ситуация 1,2,3, то описывать AS-IS не надо, а после Вы пишите текст, что описывать надо все равно в любом случае!? При этом делаете манипуляцию, ставя знак равенства между диагностикой и описанием AS IS методом интервьюирования((( Диагностику же можно делать множеством других способов!?))) Про отказ от диагностики, как этапа никто же не говорил?
Корректней было бы после 1,2.3 написать, что для этих случаев моделирование AS-IS и TO-BE методами интервьюирования - это плохая область применения этой методологии (не зависимо от выбора языка). В этих случаях нужны другие подходы.
Т.е. ИМХО, должна декларироваться следующая логика:
Проводим диагностику предприятия на предмет наличия ситуаций 1,2.3
Если 1,2,3 - то работаем по методологии "???", иначе метод интервьюирования и только Дракон для эффективного прохождения маршрута AS-IS TO-BE)))
Во-первых, Спасибо, что не сердитесь за перевод беседы с обсуждения вашего оригинального языка на надязыковую тему👍 Я знаком (да все знакомы) с логикой (зачем и почему) сначала AS-IS и только потом TO BE! Но можно, я продолжу "дёргать за ус" эту "общепринятую" надязыковую логику, и от этого лежачего на поверхности стандартного (причём для любого языка, это не ноу-хау Дракона) концепта, предложу нырнуть в глубину? Безусловно, есть огромная область эффективного применения логики AS-IS TO-BE, но она, увы, годится не для всех случаев жизни! Можете предположить ситуации (и это не какие то вырожденные события, о которых не стоит и говорить), когда составлять модель AS-IS методом интервью - напрасная трата сил и времени (вопреки Вашему утверждению)? Извините за то, что я не даю ответ, а задаю вопрос - мне очень интересны Ваши гипотезы, ход мысли на этот счет! Просто я вижу в Вашем ответе такую же манипуляцию умалчивания как в (1) начинать описывать не важно что, потому что это в любом случае полезно (в моем контрпримере хаос - сомнительная среда для описания) и (2) обязательно описывать ситуацию AS-IS, потому что без этого нельзя (существует ли по-вашему контрпример?).
Категорически обострю обсуждение (так же интересней) радикальной точкой зрения:
"Что русскому - хорошо, то немцу - смерть!", а по теме процессов в организации это звучит как-то так "что хорошо продавцам, то плохо производству" (названия структурных подразделений можно менять как угодно "что хорошо конструктору, то плохо технологу" и т.д). К чему я веду: какой бы язык визуализации (от хорошего, до расчудесного) не использовался, пока не решена проблема гармонизации целей и задач процессов организации, любое описание системы управления, созданное на базе интервью представителей отдельных структурных подразделений (а дисбаланс интересов существует не только между подразделениями, но и внутри подразделений, об этом я пока молчу) - это автоматизация ХАОСА. Поэтому декларации про то что НАДО описывать, и описанные процессы для организации лучше - это манипуляция, потому что описывать ХАОС, чтобы потом "управлять" ХАОСОМ - так себе результат (выкинутые напрасно время и немалые деньги) ((( Содержание статьи очищенное от манипуляций выглядит как-то так "наш язык визуализации опишет ваш ХАОС царящий в организации быстрее, чем другие языки". Без компетенции гармонизации процессов любой язык визуализации - обезьяна с гранатой! А ответа на этот вопрос и такую постановку задачи, что-то я здесь (в этой публикации в частности, и на ХАБР вообще) не наблюдаю((( У кого есть ответ? Где он описан? Где эту проблематику "автоматизации ХАОСа" обсуждают? Ну очень интересно было бы посмотреть!!!
Повторю свой комментарий про причины проблемы и что делать и здесь в Вашем развернутом ответе к исходной публикации (там с автором мы найти точки соприкосновения не смогли):
Выскажу кратко свою т.з.:
Причина проблемы в том, что функциональный подход (модель управления описывается графом со связями типа «Дерево») и процессный подход (модель управления описывается графом со связями типа «Сеть») – это две АЛЬТЕРНАТИВНЫЕ модели управления! С эти связаны неудовлетворительные результаты попыток описать элементы одной системы с помощью определений и сущностей ДРУГОЙ системы – получаем закономерный результат в виде кучи мусорных не понятных конструкций.
Непонимание этого факта «альтернативности моделей», ведет к гораздо более существенной проблеме, чем проблема отсутствия сущности «владелец процесса» в функциональном подходе. И это проблема называется «Автоматизация ХАОСА». Де-факто, абсолютное большинство организаций работают в функциональной модели управления, а IT компании пытаются создать информационный образ на языке процессной модели управления, со всеми закономерно вытекающими последствиями.
В связи с этим возникают следующие проблемы:
1. Предприятия ФИЗИЧЕСКИ должны преобразоваться и перейти на другую (с функциональной на процессную) модель организационного устройства и управления (и стандарты ИСО серии 9000 именно это требуют), а они этого не делают.
2. IT-компании игнорят этот факт не соответствия (продолжают увлеченно натягивать СОВУ на ГЛОБУС), и их самооценки о полезности описаний AS IS и TO BE ничего кроме улыбок/досады вызвать не может. Так как какую бы красивую процессную модель TO BE IT-аналитики не разработали, существование этой «бумажно-электронной» сущности НИКАК не меняет фактически реализуемой функциональной модели управления в организации. Натягивание СОВЫ на ГЛОБУС конечно сильно зависит от размеров и особенностей СОВЫ и ГЛОБУСА, но результат хорошим (автоматизация ХАОСА) быть не может по определению.
Про ИСО еще раз комментировать ошибочность Вашего восприятия не буду (уже комментировал)
Про чем не понравилось BPMN - тем что эта нотация не соответствует требованиям Прикладного мира по управлению процессами и организацией состоящей из процессов. Если образно про BPMN: IT-шники придумали низкоуровневый язык Асемблер/Перфокарты с помощью которого справедливо считают, что могут описать все что угодно! Но качество такого описания/программирования очень трудоемко, допускает любое искажение (потому что запрограммировать можно что угодно + неправильное понимание смыслов устройства предприятия и задачи управления в нем программиста существенно), и делает участие в таком программировании Заказчика очень затруднительным. Вместо этого Ассемблера/Перфокарт, хотелось бы иметь Объектно-ориентированный язык программирования (процессы и действия с ними), который настроен на требования и логики управления Прикладного мира (описанных в стандартах ISO, в концепции Бережливое производство, в концепции управления на основе предупреждения несоответствий стандарт ISO/TS2...), чтобы нельзя было создать решение, нарушающую логику и требования (нельзя запрограммировать что угодно)? чтобы восприятие программиста никак не искажало смыслы, чтобы все программирование осуществлял Заказчик без программистов. Т.е. я возмущен, что созданный программистами такой "Ассемблер/Перфокарты" в лохматом 1960 году под видение и постановку задачи того времени, дожил без изменения до наших дней и все считают это нормальным описывать и проектировать корпоративные системы управления на ассемблере и перфокартах!? Никакого прогресса за 60 лет((( И это IT отрасль((( Прикладной мир в понимании улетел на двести световых лет вперед, а IT мир остался в видении задачи на уровне 1960 года!? Как этим не возмущаться, и чему тут быть довольным!?
Ну опять Вы с ходу пытаетесь (не понимая глубинных смыслов) зацепиться и интерпретировать слова (поверхностные смыслы), чем лишний раз доказываете мне уровень Вашей компетентности в отношении обсуждаемых стандартов. Начинаю образовательный процесс (чтобы показать пример разности понимания, и что это очень долгий процесс):
В Прикладном мире с 80х годов прошлого века появилась концепция TQM (всеобщего управления качеством). Новизна этой концепции заключалась в том, что было провозглашено две закономерности, которые предлагалось воспринимать как аксиомы управления в Прикладном мире: (1) Для обеспечения устойчивого развития организаций, главной целью управления должна быть цель "Повышение степени удовлетворенности потребителей организации" и (2) Что нет видов деятельности внутри организаций, которые не оказывали бы влияния на достижение цели "Повышение степени удовлетворенности потребителей организации". В соответствии с этой концепцией систему управления предприятием стали называть системой управления качеством (логика Степень удовлетворенности потребителей определяется Качеством Продукции, Качеством взаимодействия с организацией и т.п., поэтому и для сокращения длинной словесной конструкции появился термин КАЧЕСТВО в названии (смотрите пример иной смысловой нагрузки в казалось бы очевидно известном термине качество), чтобы в явном виде в названии присутствовала главная цель управления. Поэтому корректное восприятие управленческого нововведения TQM стала формула Эффективная Система управления предприятия = Системой управления Качеством (все решения в организации (управление) должны приниматься в интересах повышения степени удовлетворенности клиентов предприятия). Для простоты концепция TQM это формула: Система управления предприятием=СМК и это правильное прочтение смысла. При этом существует неправильное понимание полностью искажающее весь смысл концепции TQM: управление качеством - это отдельная функция в рамках организации (это старое наследие восприятия организации как функциональной иерархии, в которой любой аспект деятельности должен быть выделен как функция и управляться как функция). В рамках этого неправильного понимания смысла концепции TQM есть Большая система управления предприятия, функциональным элементом которой является локальный вопрос управления качеством. Надеюсь разница смыслов и восприятия очевидны?
Именно эта разница видения в наших позициях и проявилась:
Я считаю что управление организацией, в соответствии с концепцией TQM, это и есть СМК (это одно и тоже, и поэтому то, что написано про СМК в ISO серии 9000 это про управление всей организацией в целом, без каких-либо исключений), а Вы считаете, что СМК это про локальную функцию в системе управления организацией, и поэтому "принижаете" роль и значение стандартов ISO серии 9000, и требуете подать Вам (с Вашей точки зрения совершенно справедливо требуете) не стандарт про управление отдельной функцией в организации, а стандарт про управление всем предприятием.
И вот такие смысловые несовпадения у нас с Вами практически во всем((( Так, Вы уверены, что организация - это разбиение на функции, с соответствующим директивным управлением. А в моей картине мира задача управления КАЧЕСТВОМ в смысле TQM (n/t/ задача управления всем предприятием) распределена между всеми участниками организации. И в этом новом мире у них другие структурные решения (разница между функцией и управления функцией и организации состоящей из функций, и процессом и управлением процессом, и управления организацией состоящей из процессов). Очень надеюсь, что этим примером я смог донести до Вас методическую сложность (как минимум для меня) нашей с Вами дискуссии.
"Методология ИСО потребовалась, чтобы производители выпускали качественную продукцию вместо ранее существовавших ГОСТов. Согласен, что их требуется придерживаться, т.к. это требование государства. " - БРЕД!!!! Откуда Вы генерируете эту "отсебятину" в трактовке смыслов и содержании стандартов!? Ну прочитайте уже, пожалуйста, назначение стандартов в опубликованных мною выдержках из этих стандартов (ВВЕДЕНИЕ, ОБЛАСТЬ ПРИМЕНЕНИЯ). Ничего не надо придумывать - там все русским языком написано!
"Термины менеджмент и управление не одно и то же. Вы просто не углублялись в эту тему." Так именно Я об этом же Вам и написал, что это не одно и тоже!? И так же, чтобы не затягивать нашу дискуссию и не превращать ее в долгий образовательный процесс по неизвестной для Вас системе знаний, я и предложил (только для этого) в нашей дискуссии считать что определения про Менеджмент в ИСО вы восприняли как определения про Управление (потому что такого термина УПРАВЛЕНИЕ в ИСО НЕТ от слова СОВСЕМ). Вы из представлений своего мира, в котором есть термин Управление, требуете дать Вам определение этого термина из другого мира знаний, а в нем НЕТ такого термина! Сколько я должен Вам объяснять эту объективную методическую сложность!? А в рамках данного ресурса переучить Вас с "Классической механики" на "Теорию Относительности" я не смогу. Я честно пытался это сделать, но мои пояснения Вам не понятны (они в моей системе координат - элементарны, а в вашей - не понятны и не имеют смысла)
"Я на основании нового подхода разработал определение, что такое процесс управления и как его можно описать. Мой материал позволяет использовать современные информационные технологии." Я эту Вашу наработку так уже прокомментировал. Еще раз повторю свою оценку: ваша идея, возможно, имеет смысл в централизованной модели управления "Функциональная иерархия", но эти модели признаны не соответствующими современным реалиям, и на замену им предлагается переходить на альтернативную децентрализованную модель управления "процессный подход". Зачем мне изучать предложения по совершенствованию гужевой повозки, если все пересаживаются на автомобили?
Сергей Александрович, при все моем уважении к Вашему опыту и креативности, давайте не будем друг-друга мучить "доказательствами" своей правоты на этом ресурсе!? Мы с Вами договориться в таком диалоге не сможем (нужен длительный учебный процесс, а не обмен не понятными сторонам тезисами). Давайте просто примем позиции друг друга? Мне Ваша понятна, я свою, как мог донес (мне кажется, что я уже повторяюсь, причем многократно). Я не хотел Вас обидеть, я хотел высказать свою альтернативную точку зрения и ее обосновать! С Вашего разрешения, я бы не хотел продолжать эту нашу дискуссию в таком зашедшем в методологический тупик ключе дальше?
Еще раз, Спасибо за обмен мнениями и обсуждение острых тем!
(1) Процессный подход - это гибкое управление на основе децентрализации. Подход с единым центром управления "Функциональная иерархия" стандартами ISO серии 9000 с 2000 года предан АНАФЕМЕ.
(2) Я понимаю, что в Вашей системе знаний с аксиоматикой "нет никаких других моделей управления, существует только одна единая модель Управление на основе функциональной иерархии", сама мысль, что нет единоначалия и одного центра принятия решений выглядит ДИКОЙ! Так же ДИКО по аналогии воспринимают решения и понятийный аппарат люди из мира "есть только движение по линии" при переходе на 2х мерное более сложное представление реальности не в виде линий, а виде плоскости. И да, в представлении "мир - это линии", без единоначалия НЕЛЬЗЯ, но в представлении "мир это плоскости", единоначалие - атавизм. Вот я и отстаиваю мысль, что нам - представителям разных миров и понятийных аппаратов, сложно понять друг друга)))
(3) BPM выросший из BPMN - это придумка IT мира для сугубо внутреннего применения. В Прикладном мире она не нужна/вредна. Поддерживаю Вашу оценку, что попытка IT отрасли моделировать Прикладной мир своими BPMN-придумками крайне сомнительна по адекватности/полезности. Именно эту т.з. в том числе я отстаиваю
Вы мои выдержки из стандарта с нужными определениями (про менеджмент, процессы и т.п.), которые я специально для Вас опубликовал (1) не хотите прочитать или (2) не можете понять/принять их смысл?!
Соглашусь с тем, что стандарты - это не учебники: они не могут исполнить образовательную функцию и для этого не предназначены. Стандарты ISO по аналогии с юриспруденцией - это кодексы Законов. Чтобы их прочитать и правильно понимать, нужно кучу учебников и кучу лет на юридическом факультете отучиться. Это памятка и свод основных знаний написанный "эзоповым" язык для знающих. И повторюсь, видимо понятийный аппарат Прикладников и ITшников категорически не совпадают, раз я публикую запрашиваемые Вами определения, а Вы их таковыми не воспринимаете?
Так, например, Термина Управление в международном языке B2B нет, вместо этого применяется термин Менеджмент (если хотите, то для целей нашего взаимопонимания можно считать, что это синонимы (одно и то же), хотя рабочие группы разработчиков этих стандартов, посчитали, что термин Менеджмент шире термина Управление (так, термин Управления был неоднократно задействован/занят в других смысловых конструкциях, что могло создать ситуации ошибочной трактовки), поэтому термин Управление решили не использовать)
Я посмотрел Вашу публикацию по ссылке. Она очень многословная/большая, поэтому я не могу утверждать, что я все понял/разобрался. С учетом этой ремарки, сформулирую свою реакцию на нее:
(1) Возможно, для систем управления "Функциональные иерархии (описывающий граф "Дерево"), в которых выделяется как отдельная функция задача Управления, которые основаны на директивном управлении, жестких регламентах и связях, в которых планы и прогнозы достоверны и исполнимы, ваши соображения имеют смысл (такое Механистическое управление). Но для децентрализованных систем управления (нет директивного управления, каждый процесс - центр принятия решения, управление распределено по компании), в которых изменчивость и неопределенность внешней среды и своих собственных возможностей очень большие, где количество возможных сценариев и ситуаций такое неизвестно большое, что разрабатывать регламенты не имеет смысла, и нужно "по месту" и "по ситуации" на основе уникально сложившихся данных принимать решение, именно для такой среды и создана альтернативная модель управления "Процессный подход" (описывается графом "Сеть")), Вот для такой модели Эвристического управления (от слова Эврика, как противоположная идея Механистического управления) ваши предложения, как мне кажется НЕ ИМЕЮТ СМЫСЛА!
(2) Международными стандартами ISO серии 9000 с 2000 года продекларирован переход на "Процессную модель" управления (отказ от модели "Функциональной иерархии"). А это означает, что придумывать улучшайзеры для признанной неактуальной модели управления - бесполезная трата времени и сил (как в мудрости индейцев Дакота - это подстегивание "Дохлой лошади")
"Вы кошек не любите!? Вы просто не умеете их готовить!?" Еще раз про снобизм в отношении стандартов ISO, и факта навешивания на него IT-шниками ярлыка "ни о чем" и "бесполезный" - это все от НЕ ЗНАНИЯ. IT-отрасль смотрит и оценивает эти стандарты с высоты "своей колокольни", и в их системе координат, допускаю, это не понятные и не нужные знания! НО!!!!! Но значение и смысл этих стандартов в Прикладном мире - это Библия по управлению! Ваши комментарии (я не уверен Сергей Александрович, что именно Вы должны держать ответ, за IT отрасль) лишний раз меня в этой моей оценке и точке зрения убеждают. Смотрите какой интересный диалог у нас получается: я Вам говорю (уже много раз) "ISO - это основа", а Вы ну никак не можете это принять, т.к. в Вашей системе знаний "ISO - это пустышка", и Вы мне все время пытаетесь эту оценку навязать!? Согласитесь, если встать на мою точку зрения (Я понимаю смыслы ISO, я вижу свидетельства его работы, я вижу, что причины неудач связаны с несоблюдением идей и смыслов этих стандартов, и для меня это очень важный/нужный инструмент повседневного пользования), то Ваши предложения изменить мне оценку полезности этих стандартов я не могу воспринимать иначе, как дикость, источником которой является необразованность!? Это как предложение не есть у арбуза мякоть, а есть корки!? У меня другая точка зрения на арбуз: Мякоть - вкусно, и я ее ем, Корки - не вкусно, я их не ем!
Стандарты ISO 9000 и 9001 начинаются с таких разделов, как Введение и Область применения, где сформулированы назначение, область применение и смыслы/содержание стандартов. Если Вы в этих текстах не видите, что они про Управление, то я не знаю что с этим нужно делать!?(((
Введение ISO 9000
Область применения ISO 9000
Пример взаимосвязи понятий/терминов ISO 9000
Еще примеры
И это все о нем, о стандарте ISO 9000 "Основные положения и словарь"
Это уже ISO 9001
ISO 9001 из Введения же
ISO 9001 Область применения
Некоторые требования к нотации для описания процессов и процессной модели ISO 9001
Не хочу дальше постить тексты из этих стандартов. Моя мысль проста - IT отрасль должна их знать и понимать как "отче наш", а не говорить, что "там ничего нет"! Если Вам кажется "что там ничего нет", а 3 млн. организаций по этим стандартам работает, то это означает лишь одно: надо подучиться и в них разобраться!!!! Другого ответа для этой ситуации БЫТЬ НЕ МОЖЕТ!
У меня в вопросе выбора единого терминологического базиса (от какой печки плясать будем) цинично-рациональная позиция: (1) IT отрасль выполняет обслуживающую функцию предоставляя услуги/продукту Прикладному миру (поэтому обязана знать язык и понятийный аппарат Прикладного мира "кто платит, тот и заказывает музыку") (2) в Прикладном мире консенсус по отношению понятийного аппарата и языка - международные стандарты ISO серии 9000 (сотрудники минимум 3 млн. организаций знают и руководствуются в своей работе этим языком и понятийным аппаратом). Английский язык - международный язык межличностного общения, стандарты ISO серии 9000 - международный профессиональный язык общения B2B! То что IT отрасль отрицает роль и сущностное значение этих международных стандартов - это просто "испанский стыд": не знать язык своих клиентов!? как это вообще возможно!? Поэтому, если Вы хотите навести "мостки" между областями знаний, то "плясать" нужно от стандартов ISO серии 9000, и это, методически, самый правильный путь!
PS: Я не в первый раз сталкиваюсь с такой вопиющей с т.з взаимоотношений Заказчик-Исполнитель ситуацией снобизма и пренебрежения со стороны IT отрасли к стандартам ИСО серии 9000 (мало того что не знают их, но еще и категорически не хотят их изучать). Согласитесь, такое отношение IT отрасли к изучению прикладной области знаний реального мира (библия ISO серии 9000 и многое другое, чем реальный мир живет, а IT-шники и знать об это не интересуются от слова совсем), все это странно должно быть не только для меня!? Почему IT отрасль так себя ведет!?
Спасибо за позитивную рецензию на мою т.з! Рад в Вашем лице найти единомышленника! Где я могу познакомиться с Асис (поделитесь хорошими ссылками)?
Про саботаж от IT: мои многолетние попытки зайти в головную компанию 1С для совместной корректной постановки задачи и разработки нужной в настоящей бизнес-среде платформы - все закончились снобистским отказом (ни разу даже на мои обращения не ответили)(((( А франчайзи 1С - не хотят тратить свои силы и время, когда и так все продается (у каждого уже есть какая-то своя рабочая бизнес-ниша).
В такой диспозиции, где:
IT отрасль цинично не хочет меняться и в текущей ситуации импортозамещения купается в золотом дожде от Предприятий и грантов от Государства, которые покупают/финансируют все что им не предложи
Предприятия не имея компетенций оценить качество навязываемого (других нет) IT продукта тратятся на "Дохлую лошадь", идя на поводу у IT отрасли (Предприятия не занимают позицию компетентного и требовательного Потребителя, берут что есть/дают, а не то что надо)
Государство - ровно в такой же позиции как и Предприятия, только еще и финансирует этот "банкет" для IT отрасли
я вижу только следующую стратегию выхода из системного кризиса: донести до Государства и Предприятий, что им за дорого продают "Дохлую лошадь", с тем, чтобы они перестали покупать у IT "то что есть" и финансировать цифровизацию этой "Дохлой лошади". Может быть тогда IT отрасль развернется к проблеме "лицом"?
IT отрасли нужно учиться, учиться и еще раз учиться, ибо страшно далеки они от потребностей рынка, и слишком долго они "почивали на лаврах" своих допотопных решений!
Спасибо Вам, Сергей! Если бы не Ваша добрая и профессиональная позиция, быстрая реакция и точное восприятие обсуждаемых посылов, мы бы так далеко не зашли!
А по поводу выхода на стратегический уровень - вот еще одна стратегическая эскалация в моем видении (на стратегию поведения IT отрасли в целом), если это интересно!
Тезисно:
(1) Бизнес-сообщество сейчас переходит через "точку бифуркации" (разворот на 180 градусов с условий бизнес-среды "спрос больше предложения" (этот период длился около 300 лет), на "спрос меньше предложения" (начался с 80х годов прошлого века)). Это означает, что старые решения для промпредприятий под среду "спрос больше предложения", нужно "выкинуть на свалку истории" и срочно переходить на альтернативные радикально иные решения (по организации производства, системе управления) под условия "предложения больше спроса". Предприятия, которые вовремя этого не сделают - окажутся в большой беде. Но такая постановка задачи в сообществе не обсуждается (почему - ниже), и это проблема_1.
(2) Промышленность (руководство и сотрудники предприятий, выросшие и сделавшие карьеру на старых решениях) очень сильно тормозит с этой вынужденной революцией, которую они должны совершить для выживания в новых условиях (тормозит в объеме 95%). По разным причинам эти ленивцы руководствуются безосновательной верой, что можно эту революцию осуществить через безболезненные малые улучшения (как эволюцию, а не революцию). Подробнее можно про это прочитать в моей статье https://centr-prioritet.ru/index.php?option=com_content&view=article&id=4449 И это проблема_2! В мире вообще (и в промышленности в частности) почему то царит идея, что все должно быть просто, если предлагается сложная для реализации конструкция - это автоматически маркируется как "неправильная идея".
(3) IT отрасль, вместо того, чтобы возглавить/помочь этому переходу, саботирует эту ситуацию и эту потребность. Все разработанные на сегодня IT продукты (средства описания/моделирования деятельности организации в виде нотаций BPMN и IDEFx, продукты по управлению(ERP, MES) Предприятиями и Холдингами (не важно от каких вендоров SAP или 1С) - это все разработки под среду "спрос больше предложения" (бесполезные вплоть до вредные в новых условиях), т.е. в терминах индейцев Дакота - это все "Дохлая лошадь", которая в современной бизнес-среде "скакать с нужной скоростью" не сможет от слова совсем . И вместо того, чтобы переделать эти продукты под новые условия, отрасль лишь рационально (покупают и эксплуатируют же старые решения) и цинично (в явном виде отказываются от переработки существующих решений, зачем сейчас тратить деньги на разработку, сейчас нужно собрать все сливки с продажи старых разработок) наживается на промышленности, продавая им ненужный и вредный в новых условиях товар. И это проблема_3.
(4) Такая позиция IT отрасли по отношению к проблематике промпредприятий уже привела к ситуации "автоматизации хаоса" - внедрения ERP&MES решений под среду "спрос больше предложения" никак не способствуют нужному для выживания росту конкурентоспособности, потому что они автоматизируют "Дохлую лошадь". Этот безумный "не приходя в сознание" (не понимая смыслов) маркетинг "Всем автоматизироваться", а сейчас "Всем цифровизироваться", приводит к тому, что цифровые двойники, интернет вещей , ИИ и прочая навешиваются на неправильные/устаревшие решения (на "Дохлую лошадь"). Т.е. вслед за результатом "автоматизация хаоса" мы стремительно летим к "цифровизации хаоса" и IT отрасль это движение осознанно или нет, но возглавляет((( И это проблема_4
Извините, конечно, что мы на такие "верха" забрались, начав обсуждение с узкотехнического вопроса борьбы с рассогласованием в организациях - у меня "накипело", и видимо из-за этой профдеформации я везде вижу "следы" опасного проявления описанных мною проблем (1,2,3,4), и поэтому любое обсуждение в моем исполнении - это "сваливание" на мои "болячки"(((
Добавлю к предыдущему посту:
И на вопрос из названия Вашей публикации "Чем болен средний бизнес? Статья 6. Как описание может остановить хаос многомиллионных потерь", мой ответ для 95% производственных компаний звучал бы так: тем, что применяемые ими подходы к организации производства ("лекарство" - "Бережливое производство"), к системе управления предприятием ("лекарство" - "ISO серии 9000"), к управлению несоответствиями ("лекарство" - "ISO 16949") требуют радикального переосмысления/перестройки. Описывать эти проблемы и решение проблем, нужно на языке перечисленных "лекарств" (Дракон спроектировать прикладные решения методом интервью, лежащие в основе перечисленных "лекарств", не способен от слова "совсем" (это все равно, что предположить, что методом интервьюирования физиков можно было разработать решение в виде "Теории относительности"), т.е. не поможет/бесполезен). Для 5% производственных компаний, кто это "лечение" успешно прошел, по определению "хаоса многомиллионных потерь" у них уже нет. Но тогда и описание на языке Дракона принесет таким предприятиям пользу, но уже не в виде "многомиллионных эффектов". Именно поэтому я и включился в дискуссию к Вашей публикации.
У нас с Вами оценки "с точностью до наоборот"))) Моя практика (35+ лет) прикладного консалтинга промышленных предприятий/холдингов/цепей поставок, говорит о том, что территория 1,2.3 - это 95%, а Ваша оценка как эксперта из IT отрасли этой области - 5%! Мы (я - эксперт "Прикладного мира", Вы - эксперт IT мира, который должен удовлетворять потребности Прикладного мира) на одного и того же "слона" (состояние промпредприятий и что им для улучшения нужно делать) смотрим с радикально разных точек зрения!!!! А должно быть расхождение в долях процентов (в идеале - совпадать)! Вот это ТОЧНО БОЛЬШАЯ И НЕ ТОЛЬКО ФИЛОСОВСКАЯ ПРОБЛЕМА!!!!
Кстати, для диагностики состояния и определение областей для улучшения в Прикладном мире есть свои "языки" (международные стандарты ISO серии 9000 и ISO/TS2 (16949), концепция "Бережливое производство"). Почему IT отрасль на их основе не создает (де факто ИГНОРИТ!!! то, чем реально работает Прикладной мир) языки для диагностики и описания AS-IS TO-BE, а выдумывает "велосипеды" в виде нотаций BPMN, IDEFх, Дракон ..?!
Пользуясь Вашим приемом))) написал (сейчас находится на модерации) публикацию с разъяснениями своей позиции. Правда, т.к. я новичок на Хабре, комментарии к ней будут недоступны, пока я не смогу получить соответствующий статус одобрения.
Вы: Разве при функциональном подходе нет процессов, в том числе сквозных и кросс-функциональных? Куда они делись?
Описать как процесс можно любую деятельность (бумага все стерпит и IT отрасль в этом впереди планеты всей), однако наличие этой бумажной сущности никак не изменит физику реализации действий при функциональном подходе к управлению (доминанта связи Начальник-Подчиненный, а процессное управление - это доминанта связи Поставщик-Потребитель). Поэтому мой ответ как практика (35+ лет прикладного консалтинга промышленных предприятий) - эффективных процессов при функциональной модели управления нет (это как быть немножко беременным). Дам, чтобы пояснить свою т.з., еще такую графическую аналогию: для описания функционального подхода к управлению нужен конструктор из элементов треугольников, для описания процессного управления конструктор нужен другой - в нем элементы кружочки. Попытка описать сущности Функционального подхода инструментами для описания Процессного подхода к управлению, это попытка построить из элементов кружочки, конструкцию из треугольников!
На остальные тексты в Вашем посте мне нужно "много букв" - они в модерируемой публикации. Кратко функция и процесс, разные сущности (треугольники и кружочки) для разных по назначению и области применения управленческих конструкций (попытался эту разницу в публикации показать)
Аплодирую стоя Вашим примерам 1,2,3 когда описание AS-IS не нужно!
А вот то, что написано после, почему то противоречит Вашим же 1,2,3!?
Посмотрите какая получается конструкция Вашего комментария: Если ситуация 1,2,3, то описывать AS-IS не надо, а после Вы пишите текст, что описывать надо все равно в любом случае!? При этом делаете манипуляцию, ставя знак равенства между диагностикой и описанием AS IS методом интервьюирования((( Диагностику же можно делать множеством других способов!?))) Про отказ от диагностики, как этапа никто же не говорил?
Корректней было бы после 1,2.3 написать, что для этих случаев моделирование AS-IS и TO-BE методами интервьюирования - это плохая область применения этой методологии (не зависимо от выбора языка). В этих случаях нужны другие подходы.
Т.е. ИМХО, должна декларироваться следующая логика:
Проводим диагностику предприятия на предмет наличия ситуаций 1,2.3
Если 1,2,3 - то работаем по методологии "???", иначе метод интервьюирования и только Дракон для эффективного прохождения маршрута AS-IS TO-BE)))
Во-первых, Спасибо, что не сердитесь за перевод беседы с обсуждения вашего оригинального языка на надязыковую тему👍
Я знаком (да все знакомы) с логикой (зачем и почему) сначала AS-IS и только потом TO BE! Но можно, я продолжу "дёргать за ус" эту "общепринятую" надязыковую логику, и от этого лежачего на поверхности стандартного (причём для любого языка, это не ноу-хау Дракона) концепта, предложу нырнуть в глубину? Безусловно, есть огромная область эффективного применения логики AS-IS TO-BE, но она, увы, годится не для всех случаев жизни! Можете предположить ситуации
(и это не какие то вырожденные события, о которых не стоит и говорить), когда составлять модель AS-IS методом интервью - напрасная трата сил и времени (вопреки Вашему утверждению)? Извините за то, что я не даю ответ, а задаю вопрос - мне очень интересны Ваши гипотезы, ход мысли на этот счет! Просто я вижу в Вашем ответе такую же манипуляцию умалчивания как в (1) начинать описывать не важно что, потому что это в любом случае полезно (в моем контрпримере хаос - сомнительная среда для описания) и (2) обязательно описывать ситуацию AS-IS, потому что без этого нельзя (существует ли по-вашему контрпример?).
--
Категорически обострю обсуждение (так же интересней) радикальной точкой зрения:
"Что русскому - хорошо, то немцу - смерть!", а по теме процессов в организации это звучит как-то так "что хорошо продавцам, то плохо производству" (названия структурных подразделений можно менять как угодно "что хорошо конструктору, то плохо технологу" и т.д). К чему я веду: какой бы язык визуализации (от хорошего, до расчудесного) не использовался, пока не решена проблема гармонизации целей и задач процессов организации, любое описание системы управления, созданное на базе интервью представителей отдельных структурных подразделений (а дисбаланс интересов существует не только между подразделениями, но и внутри подразделений, об этом я пока молчу) - это автоматизация ХАОСА. Поэтому декларации про то что НАДО описывать, и описанные процессы для организации лучше - это манипуляция, потому что описывать ХАОС, чтобы потом "управлять" ХАОСОМ - так себе результат (выкинутые напрасно время и немалые деньги) ((( Содержание статьи очищенное от манипуляций выглядит как-то так "наш язык визуализации опишет ваш ХАОС царящий в организации быстрее, чем другие языки". Без компетенции гармонизации процессов любой язык визуализации - обезьяна с гранатой! А ответа на этот вопрос и такую постановку задачи, что-то я здесь (в этой публикации в частности, и на ХАБР вообще) не наблюдаю((( У кого есть ответ? Где он описан? Где эту проблематику "автоматизации ХАОСа" обсуждают? Ну очень интересно было бы посмотреть!!!
Повторю свой комментарий про причины проблемы и что делать и здесь в Вашем развернутом ответе к исходной публикации (там с автором мы найти точки соприкосновения не смогли):
Выскажу кратко свою т.з.:
Причина проблемы в том, что функциональный подход (модель управления описывается графом со связями типа «Дерево») и процессный подход (модель управления описывается графом со связями типа «Сеть») – это две АЛЬТЕРНАТИВНЫЕ модели управления! С эти связаны неудовлетворительные результаты попыток описать элементы одной системы с помощью определений и сущностей ДРУГОЙ системы – получаем закономерный результат в виде кучи мусорных не понятных конструкций.
Непонимание этого факта «альтернативности моделей», ведет к гораздо более существенной проблеме, чем проблема отсутствия сущности «владелец процесса» в функциональном подходе. И это проблема называется «Автоматизация ХАОСА». Де-факто, абсолютное большинство организаций работают в функциональной модели управления, а IT компании пытаются создать информационный образ на языке процессной модели управления, со всеми закономерно вытекающими последствиями.
В связи с этим возникают следующие проблемы:
1. Предприятия ФИЗИЧЕСКИ должны преобразоваться и перейти на другую (с функциональной на процессную) модель организационного устройства и управления (и стандарты ИСО серии 9000 именно это требуют), а они этого не делают.
2. IT-компании игнорят этот факт не соответствия (продолжают увлеченно натягивать СОВУ на ГЛОБУС), и их самооценки о полезности описаний AS IS и TO BE ничего кроме улыбок/досады вызвать не может. Так как какую бы красивую процессную модель TO BE IT-аналитики не разработали, существование этой «бумажно-электронной» сущности НИКАК не меняет фактически реализуемой функциональной модели управления в организации. Натягивание СОВЫ на ГЛОБУС конечно сильно зависит от размеров и особенностей СОВЫ и ГЛОБУСА, но результат хорошим (автоматизация ХАОСА) быть не может по определению.
Спасибо за дискуссию и Вашу оценку моего места и компетенций в Вашей системе знаний - это было все интересно!
Про ИСО еще раз комментировать ошибочность Вашего восприятия не буду (уже комментировал)
Про чем не понравилось BPMN - тем что эта нотация не соответствует требованиям Прикладного мира по управлению процессами и организацией состоящей из процессов. Если образно про BPMN: IT-шники придумали низкоуровневый язык Асемблер/Перфокарты с помощью которого справедливо считают, что могут описать все что угодно! Но качество такого описания/программирования очень трудоемко, допускает любое искажение (потому что запрограммировать можно что угодно + неправильное понимание смыслов устройства предприятия и задачи управления в нем программиста существенно), и делает участие в таком программировании Заказчика очень затруднительным. Вместо этого Ассемблера/Перфокарт, хотелось бы иметь Объектно-ориентированный язык программирования (процессы и действия с ними), который настроен на требования и логики управления Прикладного мира (описанных в стандартах ISO, в концепции Бережливое производство, в концепции управления на основе предупреждения несоответствий стандарт ISO/TS2...), чтобы нельзя было создать решение, нарушающую логику и требования (нельзя запрограммировать что угодно)? чтобы восприятие программиста никак не искажало смыслы, чтобы все программирование осуществлял Заказчик без программистов. Т.е. я возмущен, что созданный программистами такой "Ассемблер/Перфокарты" в лохматом 1960 году под видение и постановку задачи того времени, дожил без изменения до наших дней и все считают это нормальным описывать и проектировать корпоративные системы управления на ассемблере и перфокартах!? Никакого прогресса за 60 лет((( И это IT отрасль((( Прикладной мир в понимании улетел на двести световых лет вперед, а IT мир остался в видении задачи на уровне 1960 года!? Как этим не возмущаться, и чему тут быть довольным!?
Ну опять Вы с ходу пытаетесь (не понимая глубинных смыслов) зацепиться и интерпретировать слова (поверхностные смыслы), чем лишний раз доказываете мне уровень Вашей компетентности в отношении обсуждаемых стандартов. Начинаю образовательный процесс (чтобы показать пример разности понимания, и что это очень долгий процесс):
В Прикладном мире с 80х годов прошлого века появилась концепция TQM (всеобщего управления качеством). Новизна этой концепции заключалась в том, что было провозглашено две закономерности, которые предлагалось воспринимать как аксиомы управления в Прикладном мире: (1) Для обеспечения устойчивого развития организаций, главной целью управления должна быть цель "Повышение степени удовлетворенности потребителей организации" и (2) Что нет видов деятельности внутри организаций, которые не оказывали бы влияния на достижение цели "Повышение степени удовлетворенности потребителей организации". В соответствии с этой концепцией систему управления предприятием стали называть системой управления качеством (логика Степень удовлетворенности потребителей определяется Качеством Продукции, Качеством взаимодействия с организацией и т.п., поэтому и для сокращения длинной словесной конструкции появился термин КАЧЕСТВО в названии (смотрите пример иной смысловой нагрузки в казалось бы очевидно известном термине качество), чтобы в явном виде в названии присутствовала главная цель управления. Поэтому корректное восприятие управленческого нововведения TQM стала формула Эффективная Система управления предприятия = Системой управления Качеством (все решения в организации (управление) должны приниматься в интересах повышения степени удовлетворенности клиентов предприятия). Для простоты концепция TQM это формула: Система управления предприятием=СМК и это правильное прочтение смысла. При этом существует неправильное понимание полностью искажающее весь смысл концепции TQM: управление качеством - это отдельная функция в рамках организации (это старое наследие восприятия организации как функциональной иерархии, в которой любой аспект деятельности должен быть выделен как функция и управляться как функция). В рамках этого неправильного понимания смысла концепции TQM есть Большая система управления предприятия, функциональным элементом которой является локальный вопрос управления качеством. Надеюсь разница смыслов и восприятия очевидны?
Именно эта разница видения в наших позициях и проявилась:
Я считаю что управление организацией, в соответствии с концепцией TQM, это и есть СМК (это одно и тоже, и поэтому то, что написано про СМК в ISO серии 9000 это про управление всей организацией в целом, без каких-либо исключений), а Вы считаете, что СМК это про локальную функцию в системе управления организацией, и поэтому "принижаете" роль и значение стандартов ISO серии 9000, и требуете подать Вам (с Вашей точки зрения совершенно справедливо требуете) не стандарт про управление отдельной функцией в организации, а стандарт про управление всем предприятием.
И вот такие смысловые несовпадения у нас с Вами практически во всем((( Так, Вы уверены, что организация - это разбиение на функции, с соответствующим директивным управлением. А в моей картине мира задача управления КАЧЕСТВОМ в смысле TQM (n/t/ задача управления всем предприятием) распределена между всеми участниками организации. И в этом новом мире у них другие структурные решения (разница между функцией и управления функцией и организации состоящей из функций, и процессом и управлением процессом, и управления организацией состоящей из процессов). Очень надеюсь, что этим примером я смог донести до Вас методическую сложность (как минимум для меня) нашей с Вами дискуссии.
"Методология ИСО потребовалась, чтобы производители выпускали качественную продукцию вместо ранее существовавших ГОСТов. Согласен, что их требуется придерживаться, т.к. это требование государства. "- БРЕД!!!! Откуда Вы генерируете эту "отсебятину" в трактовке смыслов и содержании стандартов!? Ну прочитайте уже, пожалуйста, назначение стандартов в опубликованных мною выдержках из этих стандартов (ВВЕДЕНИЕ, ОБЛАСТЬ ПРИМЕНЕНИЯ). Ничего не надо придумывать - там все русским языком написано!"Термины менеджмент и управление не одно и то же. Вы просто не углублялись в эту тему."Так именно Я об этом же Вам и написал, что это не одно и тоже!? И так же, чтобы не затягивать нашу дискуссию и не превращать ее в долгий образовательный процесс по неизвестной для Вас системе знаний, я и предложил (только для этого) в нашей дискуссии считать что определения про Менеджмент в ИСО вы восприняли как определения про Управление (потому что такого термина УПРАВЛЕНИЕ в ИСО НЕТ от слова СОВСЕМ). Вы из представлений своего мира, в котором есть термин Управление, требуете дать Вам определение этого термина из другого мира знаний, а в нем НЕТ такого термина! Сколько я должен Вам объяснять эту объективную методическую сложность!? А в рамках данного ресурса переучить Вас с "Классической механики" на "Теорию Относительности" я не смогу. Я честно пытался это сделать, но мои пояснения Вам не понятны (они в моей системе координат - элементарны, а в вашей - не понятны и не имеют смысла)"Я на основании нового подхода разработал определение, что такое процесс управления и как его можно описать. Мой материал позволяет использовать современные информационные технологии." Я эту Вашу наработку так уже прокомментировал. Еще раз повторю свою оценку: ваша идея, возможно, имеет смысл в централизованной модели управления "Функциональная иерархия", но эти модели признаны не соответствующими современным реалиям, и на замену им предлагается переходить на альтернативную децентрализованную модель управления "процессный подход". Зачем мне изучать предложения по совершенствованию гужевой повозки, если все пересаживаются на автомобили?Сергей Александрович, при все моем уважении к Вашему опыту и креативности, давайте не будем друг-друга мучить "доказательствами" своей правоты на этом ресурсе!? Мы с Вами договориться в таком диалоге не сможем (нужен длительный учебный процесс, а не обмен не понятными сторонам тезисами). Давайте просто примем позиции друг друга? Мне Ваша понятна, я свою, как мог донес (мне кажется, что я уже повторяюсь, причем многократно). Я не хотел Вас обидеть, я хотел высказать свою альтернативную точку зрения и ее обосновать! С Вашего разрешения, я бы не хотел продолжать эту нашу дискуссию в таком зашедшем в методологический тупик ключе дальше?
Еще раз, Спасибо за обмен мнениями и обсуждение острых тем!
Вы поняли меня правильно:
(1) Процессный подход - это гибкое управление на основе децентрализации. Подход с единым центром управления "Функциональная иерархия" стандартами ISO серии 9000 с 2000 года предан АНАФЕМЕ.
(2) Я понимаю, что в Вашей системе знаний с аксиоматикой "нет никаких других моделей управления, существует только одна единая модель Управление на основе функциональной иерархии", сама мысль, что нет единоначалия и одного центра принятия решений выглядит ДИКОЙ! Так же ДИКО по аналогии воспринимают решения и понятийный аппарат люди из мира "есть только движение по линии" при переходе на 2х мерное более сложное представление реальности не в виде линий, а виде плоскости. И да, в представлении "мир - это линии", без единоначалия НЕЛЬЗЯ, но в представлении "мир это плоскости", единоначалие - атавизм. Вот я и отстаиваю мысль, что нам - представителям разных миров и понятийных аппаратов, сложно понять друг друга)))
(3) BPM выросший из BPMN - это придумка IT мира для сугубо внутреннего применения. В Прикладном мире она не нужна/вредна. Поддерживаю Вашу оценку, что попытка IT отрасли моделировать Прикладной мир своими BPMN-придумками крайне сомнительна по адекватности/полезности. Именно эту т.з. в том числе я отстаиваю
Вы мои выдержки из стандарта с нужными определениями (про менеджмент, процессы и т.п.), которые я специально для Вас опубликовал (1) не хотите прочитать или (2) не можете понять/принять их смысл?!
Соглашусь с тем, что стандарты - это не учебники: они не могут исполнить образовательную функцию и для этого не предназначены. Стандарты ISO по аналогии с юриспруденцией - это кодексы Законов. Чтобы их прочитать и правильно понимать, нужно кучу учебников и кучу лет на юридическом факультете отучиться. Это памятка и свод основных знаний написанный "эзоповым" язык для знающих. И повторюсь, видимо понятийный аппарат Прикладников и ITшников категорически не совпадают, раз я публикую запрашиваемые Вами определения, а Вы их таковыми не воспринимаете?
Так, например, Термина Управление в международном языке B2B нет, вместо этого применяется термин Менеджмент (если хотите, то для целей нашего взаимопонимания можно считать, что это синонимы (одно и то же), хотя рабочие группы разработчиков этих стандартов, посчитали, что термин Менеджмент шире термина Управление (так, термин Управления был неоднократно задействован/занят в других смысловых конструкциях, что могло создать ситуации ошибочной трактовки), поэтому термин Управление решили не использовать)
Я посмотрел Вашу публикацию по ссылке. Она очень многословная/большая, поэтому я не могу утверждать, что я все понял/разобрался. С учетом этой ремарки, сформулирую свою реакцию на нее:
(1) Возможно, для систем управления "Функциональные иерархии (описывающий граф "Дерево"), в которых выделяется как отдельная функция задача Управления, которые основаны на директивном управлении, жестких регламентах и связях, в которых планы и прогнозы достоверны и исполнимы, ваши соображения имеют смысл (такое Механистическое управление). Но для децентрализованных систем управления (нет директивного управления, каждый процесс - центр принятия решения, управление распределено по компании), в которых изменчивость и неопределенность внешней среды и своих собственных возможностей очень большие, где количество возможных сценариев и ситуаций такое неизвестно большое, что разрабатывать регламенты не имеет смысла, и нужно "по месту" и "по ситуации" на основе уникально сложившихся данных принимать решение, именно для такой среды и создана альтернативная модель управления "Процессный подход" (описывается графом "Сеть")), Вот для такой модели Эвристического управления (от слова Эврика, как противоположная идея Механистического управления) ваши предложения, как мне кажется НЕ ИМЕЮТ СМЫСЛА!
(2) Международными стандартами ISO серии 9000 с 2000 года продекларирован переход на "Процессную модель" управления (отказ от модели "Функциональной иерархии"). А это означает, что придумывать улучшайзеры для признанной неактуальной модели управления - бесполезная трата времени и сил (как в мудрости индейцев Дакота - это подстегивание "Дохлой лошади")
"Вы кошек не любите!? Вы просто не умеете их готовить!?" Еще раз про снобизм в отношении стандартов ISO, и факта навешивания на него IT-шниками ярлыка "ни о чем" и "бесполезный" - это все от НЕ ЗНАНИЯ. IT-отрасль смотрит и оценивает эти стандарты с высоты "своей колокольни", и в их системе координат, допускаю, это не понятные и не нужные знания! НО!!!!! Но значение и смысл этих стандартов в Прикладном мире - это Библия по управлению! Ваши комментарии (я не уверен Сергей Александрович, что именно Вы должны держать ответ, за IT отрасль) лишний раз меня в этой моей оценке и точке зрения убеждают. Смотрите какой интересный диалог у нас получается: я Вам говорю (уже много раз) "ISO - это основа", а Вы ну никак не можете это принять, т.к. в Вашей системе знаний "ISO - это пустышка", и Вы мне все время пытаетесь эту оценку навязать!? Согласитесь, если встать на мою точку зрения (Я понимаю смыслы ISO, я вижу свидетельства его работы, я вижу, что причины неудач связаны с несоблюдением идей и смыслов этих стандартов, и для меня это очень важный/нужный инструмент повседневного пользования), то Ваши предложения изменить мне оценку полезности этих стандартов я не могу воспринимать иначе, как дикость, источником которой является необразованность!? Это как предложение не есть у арбуза мякоть, а есть корки!? У меня другая точка зрения на арбуз: Мякоть - вкусно, и я ее ем, Корки - не вкусно, я их не ем!
Стандарты ISO 9000 и 9001 начинаются с таких разделов, как Введение и Область применения, где сформулированы назначение, область применение и смыслы/содержание стандартов. Если Вы в этих текстах не видите, что они про Управление, то я не знаю что с этим нужно делать!?(((
Не хочу дальше постить тексты из этих стандартов. Моя мысль проста - IT отрасль должна их знать и понимать как "отче наш", а не говорить, что "там ничего нет"! Если Вам кажется "что там ничего нет", а 3 млн. организаций по этим стандартам работает, то это означает лишь одно: надо подучиться и в них разобраться!!!! Другого ответа для этой ситуации БЫТЬ НЕ МОЖЕТ!
У меня в вопросе выбора единого терминологического базиса (от какой печки плясать будем) цинично-рациональная позиция: (1) IT отрасль выполняет обслуживающую функцию предоставляя услуги/продукту Прикладному миру (поэтому обязана знать язык и понятийный аппарат Прикладного мира "кто платит, тот и заказывает музыку") (2) в Прикладном мире консенсус по отношению понятийного аппарата и языка - международные стандарты ISO серии 9000 (сотрудники минимум 3 млн. организаций знают и руководствуются в своей работе этим языком и понятийным аппаратом). Английский язык - международный язык межличностного общения, стандарты ISO серии 9000 - международный профессиональный язык общения B2B! То что IT отрасль отрицает роль и сущностное значение этих международных стандартов - это просто "испанский стыд": не знать язык своих клиентов!? как это вообще возможно!? Поэтому, если Вы хотите навести "мостки" между областями знаний, то "плясать" нужно от стандартов ISO серии 9000, и это, методически, самый правильный путь!
PS: Я не в первый раз сталкиваюсь с такой вопиющей с т.з взаимоотношений Заказчик-Исполнитель ситуацией снобизма и пренебрежения со стороны IT отрасли к стандартам ИСО серии 9000 (мало того что не знают их, но еще и категорически не хотят их изучать). Согласитесь, такое отношение IT отрасли к изучению прикладной области знаний реального мира (библия ISO серии 9000 и многое другое, чем реальный мир живет, а IT-шники и знать об это не интересуются от слова совсем), все это странно должно быть не только для меня!? Почему IT отрасль так себя ведет!?
Сдается мне, что Вы стандарты ISO 9000 и ISO 9001 скорее всего не читали (там только об управлении и говорится)