Так я и прошу в каждом своем ответе сравнительную табличку
Странное дело, я считаю, что все уже про разницу Вам разжевал (и не по одному кругу), а Вы мои аргументы "в упор" не видите, все требуете эту разницу описать!? Смотрите, что получается: для меня, то что я пишу - ОТВЕТ с большим смыслом, а Вы этот мой ОТВЕТ из-за того, что его либо не понимаете, либо не видите в нем смысла, либо в Вашей системе знаний это совершенно не значимый факт, что то еще... но пропускаете (не воспринимаете) как ОТВЕТ!
Вот попробовал свести в табличку мои ответы (правда не знаю, как ее корректней отобразить - исходник сделал в worde):
Обращаю внимание, что указанная публикация по ARIS в контексте именно "уже процессного" ИСО 9001:2000. Более того, ARIS и до ИСО 9001:2000 был вроде как процессным и ему не нужно было "на лету переобуваться" в 2000, как это сделал iso9k. При этом концепт ARIS Шеера имеет более длительную историю чем iso9k.
Услышьте уже меня: то что называется процессным подходом в ARIS и в ISO 9000 - две огромные разницы!!!! ARIS НИКОГДА не мог и не может (в нем даже средств таких не предусмотрено) реализовать процессный подход by ISO 9001. То что Шеер обозвал процессами и процессным подходом не соответствует тому, что в ISO 9001 называют процессами и процессным управлением. Модель процессов которую способен сформировать ARIS - это описание функциональной иерархии языком операций, которое обозвали процессами и процессным подходом! Именно этот снобизм IT отрасли, который не видит и не понимает разницы, при этом не хочет учиться, меня поражает! Я Вам уже наверное более 10 раз явным образом сказал что разница огромна, написал кучу текстов, аргументов. Вы в ответ не привели ни одного аргумента, кроме деклараций что подход by BPM одно и то же и все он реализует (и Lean - что категорическая неправда, и PDCA - до сих пор не увидел примера применения, в ИСО - PDCA вшит в нотацию, в BPM - ничего и близкого нет), но каждое сообщение мне опять и опять утверждаете что процессней ARIS и BPM ничего на свете нет, он может все (сильно во что-то верить, это может быть и хорошо, но не плохо бы уметь рационально объяснить, привести аргументы, доказать, а не просто ВЕРИТЬ)!!! Я устал уже Вам повторять, что ARIS (ИЗЬ by ARIS) может мало чего, и результаты дает неприемлемые, именно на замену ему ISO версии 2000 придумали!!! Видимо, Вам как специалисту по BPM это принять очень не просто...
Повторюсь, что ARIS - это не совсем про автоматизацию, а скорее про Реинжиниринг с его лозунгом "Не автоматизируй это!". Именно моделирование + процессный подход были "визитной карточкой" ARIS в РФ.
Да я Вам уже говорил, что я не делаю НИКАКОГО упора на "только автоматизация" или "есть еще реинжиниринг с управлением". Я Вам говорю о том, что подход к формированию процессного управления by BPM такой, что автоматизация ли, реинжиниринг ли, управление ли - все вместе это будет реализовано, или по отдельности, но эти решения будут давать НЕПРИЕМЛЕМЫЕ результаты!!!! Потому что модель процессов и процессного управления by ARIS (BPM) слабенькие, в ISO намного интересней/мощней идея!
То что описано в ссылке на Вашу публикацию - это точно другой язык, другая проблематика и другие решения вроде бы универсальной задачи про надежность, чем родственная постановка задачи в Прикладном промышленном мире. В Вашей публикации говорится про какую-то IT надежность (как я это воспринял).
Постановка задачи надежности в Прикладном мире - это термины стабильности/воспроизводимости технологических операций, процессов, соответствующие индексы CP/CPk, планы управления операциями и контрольные карты Шухарта (в автомобильной отрасли) или хорошо распространенная аналогичная по идеологии (немного другая по исполнению и инструментам) методология 6sigma. Их идеологическая основа - изучение влияния факторов изменчивости действующих на процесс, и выработка планов управления процессом на основе наблюдения за особо сильнодействующими факторами изменчивости. Алгоритм: выявить факторы изменчивости действующие на процесс, определить какие из них и как влияют на процесс, выделить существенно влияющие, научится наблюдать за ними, построить план управления процессом в зависимости от результатов наблюдения. Эту революцию в управлении качеством процессов IT-отрасль, с моей точки зрения, так же проигнорила/проспала, т.к. этих решений нет в текущих релизах ERP, и в специализированных IT решениях (которые я наблюдаю в компаниях-клиентах) для конструкторов, технологов, производственников, ремонтников оборудования(((
И мой главный вопрос, который меня интересует (из за чего я пришел на ХАБР): за какие ниточки нужно подергать, чтобы IT отрасль "повернулась передом" к знаниям Прикладного мира (которые откровенно проспала, и поэтому де факто кормит Прикладной мир только идеологически устаревшими продуктами, т.к. других у нее нет) и начала процесс изучения и интеграции этих знаний в IT продукты?
Как и кому нужно эту идею донести? Что сделать, чтобы IT отрасль начала учиться (перестала думать что все знает и так)?
Про Историю стандартов ISO серии 9000, то как ее видят в Прикладном мире (как рассказываем своим клиентам ее мы - консалтинговая группа компаний Приоритет):
ГЛАВНОЕ, нужно понимать причины появления этих стандартов. Прежде всего, это потребность обеспечивать необходимую эффективность работы цепей поставок в условиях все увеличивающегося давления со стороны потребителей (ужесточение требования цена/качество, сокращение сроков и увеличение точности поставок, лавинообразный рост номенклатуры из-за персонализации требований, радикальное сокращение сроков на разработку новых изделий, работа в отсутствии "твердого ТЗ" от Потребителей (Agile в промышленности), глобализация рынков поставщиков (в цепях поставок представителей каких только стран нет)). Стандарты должны были все эти вопросы решить (единый язык для взаимосвязей в секторе B2B на требования компании финишера в цепи поставок, который поставляет готовую продукции Пользователям, быстрое согласование процессов, понятные вектора в развитии цепей поставок и т.п.).
Плохие результаты работы цепей поставок (плохое качество и срыв поставок, медленные сроки разработки и согласований, ...) - это следствия, причина - плохое управление: потери ориентации на требования Потребителя в цепях поставок, рассогласование действий подразделений внутри предприятий цепей поставок, и т.п. Управлять нужно не следствиями, а причинами, поэтому появились стандарты на системы управления Предприятий, которые отлично настраивались бы на требования Потребителя в цепях поставок В2В и могли их точно реализовать (соответствовать своим же обещаниям) - т.е. настраивались на требования по КАЧЕСТВУ от Потребителей - системы управления предприятий участников цепей поставок должны стать СМК.
Версии с 1987 - 1994 - до 2000 - попытка обеспечить выполнение вышеописанной задачи в рамках текущего функционально-иерархического подхода к управлению. Стандарты - это 20 разделов - 20 групп требований к функциональным подразделениям. Эти стандарты на УРА вписывались в BPM, т.к. в 20 разделах перечислялись операции, которые должны были выполняться в подразделениях. ГАРМОНИЯ между ISO и ARIS (который разработан в то же время - будущая основа BPM, базис как и у ИСО - управление на основе функциональной иерархии, нотации для описания операций из 60х - то что доктор прописал для этого). Тогда же создаются решения класса ERP (SAP) которые также ориентированы на модель управления на основе функциональной иерархии. Это время ГАРМОНИИ ISO-ARIS-ERP и фактически действующих на предприятиях функциональных иерархий. Тогда утверждения что ISO и ARIS (BPM) - это одно и то же, были верные!
Все бы хорошо, но проблема не решилась - результаты работы цепей поставок лучше не стали. И ERP созданные на основе ISO и ARIS - автоматизировали хаос (честно/хорошо описывали функциональную иерархию на предприятиях в виде карт операций, но в итоге получались те же неприемлемые результаты работы цепей поставок, предприятия не могли выполнить свои же обещания/планы)
Поэтому в 2000 году произошла революция в понимании, как нужно управлять цепями поставок: главным виновником была объявлена функциональная иерархия, ее предлагалось предать анафеме, а вместо нее строить системы управления на основе прямо настраивающихся непрерывно взаимодействующих процессов верхнего уровня, чтобы требования Потребителей без искажений доходили до всех сопричастных, любые изменения/отклонения - сразу обнаруживались и принимались согласованные сбалансированные корректирующие действия. Поэтому и появились стандарты 2000 года про Процессный подход, в которых в явном виде описывалось, как должно быть реализовано такое процессное взаимодействие (и именно эта нотация описания процессов в 100-1000 раз многоаспектней и сложнее, чем нотации IDEF[ или BPMN? поэтому я в т.ч. и говорю, что не может быть одинаковых систем управления, которые описаны настолько разными нотациями). Никакой преемственности со старыми версиями стандартов НЕ БЫЛО. Предприятиям, у которых были сертификаты соответствия на старые версии стандартов был дан 3х летний срок, чтобы они перестроили свои системы управления с функциональных иерархий на процессный подход в понимании ISO версии 2000.
Именно тогда сформировался идеологический разрыв и с ARIS (и с ERP решениями), которые на самом деле описывали функциональные иерархии. К сожалению, благодаря Шееру, совпало название "процессный подход" и IT отрасль де-факто проигнорила изменения в Прикладном мире, посчитав, что они давно уже "процессный подход", и снобистски не стали разбираться с тем, что в ИСО была заложена совсем другая идея, как управлять организацией, которая тоже назвали "процессный подход"!
Я считаю, что в обоих завернут ровно такой же Процессный подход и его продают в разных обертках.
Обеими концепциями (BPM и ISO) декларируется "Процессный подход" - да, это так (термин один и тот же, цель декларируется идентичная - процессное управление организацией)
Моя т.з. BPM и ISO описывают различные подходы как к построению, так и к составным элементам итоговой конструкции и каким образом будет осуществляться управление. Очень схематично, в ИСО мало процессов но архи много требований к тому, как они должны взаимодействовать и управляться как система процессов, в BPM очень много процессов и минималистическая нотация.
Т.е. я утверждаю НЕ СХОДИМОСТЬ результатов при разработке процессного управления by BPM vs ISO. Для одной и той же организации получаться разные по составу процессы, подходы к управлению ими как системой и очень разные результаты такого управления (я считаю, что получаемые результаты by BPM неудовлетворительные)
Я утверждаю, что такая НЕ СХОДИМОСТЬ - это большая проблема.
Может быть есть исследования на этот счет?
Увы, я не слышал о подобной постановке задачи (гипотезе о существенной разнице и НЕ СХОДИМОСТИ) вообще, как следствие не видел и соответствующих исследований. Считается, как Вы и озвучили, что по умолчанию это все одно и то же.
Изначально в ISO был только системный и его потом переименовали в процессный.
Это не так. С момента рождения в 2000 году, это был и остается стандарт процессного подхода. Просто вместо 8 принципов менеджмента в версии 2000 года, начиная с версии 2008 года их осталось 7 (принцип Системного подхода к менеджменту исключили). Никакого переименования не было. Как был процессный подход, так и остался.
С моей т.з. то, что Вы озвучили такое мнение, является для меня очевидным маркером того, что Вы стандарты ISO не знаете, не понимаете (иначе никогда бы такое не сказали бы). Я этим не хочу Вас обидеть (возможно Вас этим стандартам ISO учили), я лишь хочу обратить Ваше внимание на то, что информацию/знания, которые Вы получили, как бы помягче выразится, я, как преподаватель этой области знаний из Прикладного мира, считаю не очень корректными. А Вы можете вспомнить/поделиться данными о том откуда Вы получили знания о стандартах ИСО серии 9000 (кто учил, что за учебный процесс был)? Я пытаюсь понять, откуда такой искаженный и очень сильный источник знаний в IT отрасль пришел?
я тоже потерялся в потоке обсуждений. Лучше так: Тезис (Ваш) - и мой (в Вашем понимании) АнтиТезис (с нумерацией).
Согласен, в обмене "портянками" каждый отвечает на то, что ему кажется важным. Надо бы уйти от портянок)))
Некоторые Ваши утверждения, типа "В BPM CBOK нет про PDCA" - меня вводят в ступор
У меня есть бумажная версия BPM CBOK 3.0, в ней действительно есть упоминание про цикл PDCA (2 глава Управление бизнес-процессами, раздел со странным длинным названием 2.8 "Чтобы обеспечить целостность процесса и возможность непрерывного совершенствования, управление бизнес-процессом должно осуществляться по замкнутому циклу). Но это упоминание - справочная информация и декларация (даже в этом разделе никаких примеров). И в дальнейшем в примерах описания процессов по тексту я найти практическую реализацию цикла PDCA не увидел. Т.е. декларируется что это важно, что это основа, а в примерах об этом 0.
У меня есть электронная версия BPM CBOK 4.0, так там уже нет и такого раздела и упоминания цикла PDCA (я искал текстовым поисковиком и не верил своим глазам). Поэтому я и попросил скрин шоты из 4.0 если можно, и примеры описаний из него же, где по Вашему мнению описывается применение этого цикла на практике. Если в 4.0 нет таких примеров, то может из других версий найдутся скриншоты (мне очень интересно посмотреть).
Пожалуйста смотрите Алису
Я имел в виду эту сводку от Алисы только, глубже в публикации со страницы поиска я не смотрел и не рекомендовал. Статью которую Вы посмотрели по моей вине я даже не читал. Могу сказать только, что ИМХО Теория ограничений НИКАКОГО отношения к ИСО 9000 или процессному подходу не имеет
Прежде всего, я потерялся в логике нашего диалога про разницу подходов, потому что вместо прямых оценок приведенных мною описаний этих отличий, от Вас последовали вопросы и возражения не про описанную мною разницу, а про интерпретацию взаимосвязей BPM и ИСО вообще!? Правильно ли я понял Вашу позицию, что Вы пытаетесь провести логику BPM=ISO поэтому разницы подходов НЕТ, и обсуждать мои описания не хотите (опять IT снобизм)? Ничего в этом мире не меняется, мне не привыкать...
Хорошо, по Вашим вопросам/возражениям
BPM - это "перепев" ISO9k \ СМК. И частично lean
Я как эксперт по LEAN и стандартам ISO 9000 прочитал BPM CBOK4.0 и никаких текстов, которые хоть как то раскрывали бы содержание и смыслы этих концепций не нашел, там и близко ничего похожего нет (или Вы продолжаете относится к мои оценкам - как к бреду сумасшедшего)!? Если хотите, даже Вы не будучи экспертом в этих дисциплинах можете самостоятельно этот факт проверить: поиском по книге последовательно ищите ISO, ИСО, LEAN, PDCA и, о открытие, Вы не найдете ни одной содержательной ссылки!? Как из этого по Вашему следует "BPM - это "перепев" ISO9k \ СМК".
Поэтому выскажу свое искреннее удивление: на основе каких данных Вы утверждаете совершенно обратное!? Кто в Вас вложил эту мысль!? На основании каких аргументов вы можете это утверждение обосновать?!
А цикл PDCA в BPM CBOK упоминается десятки раз. Этот цикл вообще упоминается очень часто, - как к месту, так и нет.
Ни одного упоминания я не нашел (возможно плохо искал)!!!! Вы читали BPM CBOK4.0? Можете привести скрины упоминаний, где обсуждаются смыслы ИСО, LEAN, PDCA? Или описание какого либо процесса в нотации BPMN по которой было бы видно работу цикла PDCA (если он вшит)?
Уже давно BPM - "съел" рынок ISO9k \ СМК.
Вообще не понимаю смысла этой фразы. Для меня, здесь и сейчас, это две ничего общего не имеющие дисциплины (мягкое с мокрым, мороженое и самокаты). Что может означать утверждение рынок мороженного съел самокаты!? Что это вообще может означать, а уж тем более что то доказать? Что мороженным выгоднее сейчас заниматься? Может быть, но это не означает что самокаты перестали быть нужными. Это всего лишь сегодняшнее фото конъектуры рынка. Сегодня одно фото, завтра - другое
Последний в РФ внедряют в основном "для галочки" (участвовал и нужно было только для "формальной сертификации"). Тот же ИИ говорит: "Организации часто внедряют ISO 9001 под давлением внешних требований: тендеры, требования ключевых заказчиков, вход на международные рынки. Это во многом вынужденное решение".
Даже целевые странички ISO 9000 содержат (tadviser): Почему внедрение ISO 9000 превратилось в тотальную халтуру?
Рынок ИСО разделился на два лагеря: тем кому нужно здоровье (эффективность) и тем кому достаточно справки о здоровье (эффективность не нужна, достаточно справки). И тех, кому нужна справка гораздо больше! Что это доказывает? Доказывает ли это, что процессный подход и СМК от ИСО 9000 не работает? Нет, конечно! Это лишь доказывает что огромному количеству компаний (руководителям этих компаний) Прикладного мира ничего менять не хочется! А вот это большая проблема, потому что руководители то в накладе не останутся, а предприятия могут уйти в закат. Тут вопрос жесткий: ИСО (СМК и процессный подход) - это реальный выход, тогда те кто этого не понимает - смертники (или убийцы). Либо надо доказать, что ИСО - это пустышка, но только это надо доказать, потому что то что указано в Вашей цитате выше, повторюсь, не доказательство!
Мир изменился: Идеи (и деньги) "процессного подхода, PDCA" и других "очевидностей" перетекли от ISO9k в BPM. Это ответ также к комментарию. Другой пример сравнения: посчитайте число ruТГ-каналов по СМК vs BPM.
Это Ваша точка зрения, что идеи перетекли (объективных доказательств кроме деклараций и свидетельств от AI (который постит такие глупости, например, по LEAN - практически все не правильно, что я постеснялся бы иметь его в качестве свидетеля) Вы не привели). Моя т.з.: идеи BPM - идеологически устаревшая пустышка из прошлого века (прошлогодний снег) и до идей ISO им 200 световых лет лететь и лететь. По деньгам здесь и сейчас - согласен. Что мир изменился - то же согласен, только я считаю что он изменился так, что идеи BPM родом из 60х, из кареты превратились в тыкву, и именно на замену им и разработан подход ИСО.
Всё-таки: можете привести несколько современных публикаций, поясняющих Вашу концепцию / позицию? Желательно с упоминанием по тексту "процессный подход". В принципе достаточно ответа ИИ.
Возвращаясь к «бизнес-определению» бизнес-функции: бизнес-цель в бизнесе она, как правило, одна единственная – максимальная прибыль (включая задачу не обанкротиться), поэтому и все-все процессы, используемые в них инструменты и исполнители (роли в процессе) прямо или косвенно (через вспомогательные процессы) задействованы в достижении этой главной бизнес-цели.
Прибыль в бизнесе - это следствие, а управлять нужно причинами (управление на основе следствий - не самый лучший подход к управлению), причина прибыли - высокая степень удовлетворенности потребителей (их готовность и желание платить организации деньги), влиять на степень удовлетворенности Потребителей возможно через КАЧЕСТВО предоставляемой продукции и процессов взаимодействия с клиентами, поэтому управлять бизнес-организацией нужно так, чтобы она постоянно повышала свои возможности увеличивать степень удовлетворенность Потребителей. Т.е. все управленческие решения в организации должны рассматриваться сквозь призму "влияния принимаемого решения на степень удовлетворенности Потребителя": хорошие решения - способствую повышению, плохие - не способствуют/уменьшают степень удовлетворенности Потребителей. Организация должна стремиться чтобы в ней принимались только хорошие управленческие решения, тогда как следствие, у нее будет много денег/прибыли. Системы управления организаций, построенные на принятии управленческих решений на основе анализа их влияния на степень удовлетворенности Потребителей, называют Системами менеджмента КАЧЕСТВА (СМК). Это были краткие тезисы аксиоматики концепции TQM и обоснование, почему стандарты ИСО серии 9000 которые посвящены построению именно таких СМК в организациях - это про общие системы управления организациями, а не про локальный функциональный кусочек про управление аспектами качества в большой комплексной системе управления организацией. В Прикладном мире - это широко известная ДОГМА. В т.ч. и поэтому 3 млн. организаций Прикладного мира руководствуются в управлении этими принципами и моделью СМК (стремятся построить и постоянно улучшать систему управления своими компаниями на основе принятия правильных бизнес-решений направленных на повышение степени удовлетворенности своих Потребителей). Наверное, из этих объяснений должна быть понятна и идея обязательной сертификации по ИСО 9001 в секторе B2B: компании потребители, требуют от компаний поставщиков, чтобы те управлялись и развивались на основе единственной главной цели - роста степени удовлетворенности от сотрудничества со своими компаниями-Потребителями. Выполнение этого требования рассматривается сторонами как гарантия долгосрочного сотрудничества. Наличие сертификата соответствия ISO 9001, в т.ч. гарантирует, что компания Потребитель может посмотреть, а компания Поставщик открыта для такого аудита, как она понимает что нужно Потребителю, и как на основе этого управляет своим предприятием (чтобы в случае чего внести необходимые коррективы).
Меня так развивают Ваши вопросы - Вас мне Бог послал!))) Как Вас зовут, где я могу посмотреть информацию о Вас (кому мне позитивные отзывы посвящать)?
Сначала сформулирую то ГЛАВНОЕ, на что продвинули меня Ваши вопросы, потом постараюсь пройтись по Вашим пунктам (поработаю на Вас и Ваши непонятки).
В моем предыдущем посте и мысли не было думать о Вашем подходе к управлению, как о подходе который не способен управлять. Моя мысль была в том, что Вы (понятно что не Вы, а обсуждаемый подход к управлению на основе BPMN и Co (подход IT отрасли), и так же верно в обратную сторону не мой подход, а процессный подход на основе ИСО серии 9000 (Подход Прикладного мира), просто так короче) к задаче управления пришли через задачу автоматизации (я написал РОДОМ из автоматизации). Упрощенно Ваш подход: создаем подробную КАРТУ ОПЕРАЦИЙ и управляем ею, в т.ч. делая реинжиниринг КАРТЫ ОПЕРАЦИЙ. Чем подробнее карта, тем понятней и лучше будут результаты реинжиниринга и управления (т.е. качество результата, определяется детальной проработкой КАРТЫ ОПЕРАЦИЙ (качеством описания содержания), или это подход к построению системы управления "от частного к общему")
В ИСОшном все с точностью до наоборот: подход к построению системы управления предприятия строится на принципе "от общего к частному". Ставка делается не на детальность описания (не на качество описания операций), а на качество управления предприятия сразу. Стандарт "говорит": не важно какие у Вас операции, сколько их и чем Вы занимаетесь (скрепки, стулья, парикмахерская, синие стринги, или красные боксеры,... - все равно), если сотрудники в организации не правильно взаимодействуют, если Вы при принятии решений не имеете такой то информации, не делаете таких то вещей, то у организации будут ОГРОМНЫЕ проблемы (драку заказывали? не важно за все уже уплачено! т.е. мина замедленного действия с названием "дефектное управление" в организацию заложена и будет работать как часы генерируя ей проблемы). Поэтому идеология стандарта: выделите ваши основные процессы (например, Продажа, Закупки, Разработка, Производство, Поставка, Управление ресурсами, Управление организацией). Не важно сколько Вы их выделите, важно, чтобы они эффективно между собой взаимодействовали (Сеть, каждый с каждым) и могли вырабатывать и реализовывать исполнимые и нужные Потребителям согласованные планы действий. Т.е. каждый выделенный процесс системы должен работать в такой среде: В каждый момент времени у любого процесса системы уже есть согласованный с другими процессами, исполнимый внутри процесса план действий (например ваш процесс производства таких-то наборов стульев на сегодня для процесса Производства) , который нужен для удовлетворения Потребителей, который Процессом внимательно мониторится, и если вдруг произойдут какие-то проблемы, то процесс тут же сгенерирует сигналы об обнаруженных отклонениях другим процессам (закупки, Продажи, ...) и будет вырабатываться новый скорректированный план действий в организации с учетом произошедших изменений (Изменится план закупок, Уйдет предупреждение клиентам о том, что обработка его заказа задерживается, Поступит сигнал в процесс Разработки о том что конструкцию или технологию надо улучшить по таким то аспектам и т.п.), если таких сбоев много, то будет инициирован реинжиниринг процесса и системы в целом (при необходимости). При этом, так как изменчивость требований потребителей и их спроса огромные, риски не выполнения планов процессов не нулевые (допустили брак, задерживается поставка, сломался инструмент, медленнее стало работать оборудование, маркетинг ошибся в оценках, изменилась цена на электричество и т.п.), то процесс разработки согласованных планов процесса и системы в целом непрерывный (это не акт, а не прерывный процесс). Тот самый цикл PDCA который вшит в управление, как обязательная нотация. Кроме того, стандартом помимо требований умения работать в вышеописанной среде, перечислены обязательные умения и процедуры, которые необходимо для эффективной работы любого состава процессов в организации (например устанавливать такую то информацию от потребителей, регистрировать несоответствия, осуществлять корректирующие действия, проводить внутренние аудиты и т.п. всего около 400 требований, к "умениям", если которых нет, то организацию не спасет и отличный навык согласованно работать как сеть в режиме PDCA в вышеописанной среде). Все разъяснения привел для Вас, чтобы объяснить специфику создания системы управления от ИСО.
Попробую резюмировать разницу подходов построения эффективного управления организацией:
IT отрасль: сначала операции и КАРТА операций (описание содержания деятельности, чем подробнее-детальнее, тем лучше), потом их реинжиниринг (как увидели и смогли) и управление описанными/улучшенными (не факт что получилось лучше, критериев то нету) операциями как КАРТОЙ операций, и тогда наступит СЧАСТЬЕ.
Прикладники (ИСО): сначала отрабатываем правильность управления (PDCA, Сетевое взаимодействие, 400 "умений") - отработка такого управления и умений вынудит нас по другому выполнять операции (происходит реинжиниринг КАРТЫ операций под критерии правильности управления с предыдущего пункта, реинжиниринг КАРТЫ операций процесса - осуществляет Владелец этого процесса, Реинжиниринг СЕТИ процессов - Координационный совет владельцев процесса или Владелец процесса Управление СИСТЕМОЙ), такой подход создаст необходимое эффективное управление (когда каждый процесс в любое время согласованно делает только то, что нужно (и не делает того, что не нужно) Организации=Потребителю) под которое произведен необходимый реинжиниринг КАРТЫ ОПЕРАЦИЙ в каждом процессе. И тогда наступит СЧАСТЬЕ.
Я старался написать это объяснение понятным не для себя, а для Вас, т.е. старался описать его так, чтобы оно было понятным и непротиворечивым с т.з. адепта и носителя знаний IT мира. Получилось ли мне понятным для Вас образом донести мысль про разницу подходов?
Теперь Ваши вопросы:
1 Уточните про сквозные процессы. Вы их не признаете в своем подходе?
С т.з. ИСОшного подхода, во первых, это избыточная сущность, потому что все равно какие процессы сначала, потом все настроим. Во-вторых, концепция TQM (лежащая в основе ИСО серии 9000) построена на аксиоме, что в организации нет таких видов деятельности, которые не оказывали бы влияния на конечный результат "Высокая степень удовлетворенности Потребителя" (в Вашей терминологии TQM транслируется в утверждение все они должны быть привлечены и участвовать как СКВОЗНЫЕ). Поэтому попытка выделять часть видов деятельности не важно с какими критериям важности (сквозные процессы в Вашем вопросе), с т.з. TQM управленческая ошибка. Но это не означает, что в ИСО не используются классификации процессов (есть управленческие, обеспечивающие, процессы жизненного цикла (ПЖЦ) продукции, иногда их еще называют бизнес-процессами (на моем примере процессной модели это группа процессов желтого цвета) - возможно именно они наиболее близки термину СКВОЗНЫЕ. Просто в Прикладном мире, видимо, в отличии от IT мира такой термин не распространен от слова СОВСЕМ (используются близкие к нему аналоги в виде ПЖЦ или БП)
2. Дайте ссылки на статьи, где показана схожая с Вашей позиция.
Фрагментарно следы описываемой мною логики много где есть (лучший свод - сами стандарты ИСО серии 9000). Так концентрированно и в таком виде (благодаря Вам родилось из под моего пера только сейчас) - не знаю. Я по приглашению руководства НИУ ВШЭ читаю свой курс "Теория организации" для студентов Бизнес-информатики в Нижнем Новгороде, и поэтому используемое мною с Вами изложение интерпретации ИСО 9000 и подхода к построению системы управления - это мои лекции, моя 35 летняя практика работы на земле по повышению экономической эффективности производственных Предприятий/Холдингов/Цепей поставок, моя авторская отсебятина, чтобы понятно было студентам 3-курсникам (последний вариант в нашем диалоге - отсебятина под Вашим воздействием))).
3.Применительно к автоматизации vs bpm. Если брать классический BPM, он как раз не про автоматизацию. Тот же реинжиниринг процессов (ключевой элемент BPM девяностых) основан на тезисе: Не автоматизируй это!
Про BPMN с моей т.з. я уже ответил выше. Только еще раз здесь акцентирую Ваше внимание на Важном артефакте, который с моей т.з. свидетельствует о принципиальной разнице подходов: В ИСО серии 9000 (первая редакция 2000, вторая 2008, третья 2015 годы) нет ни слова о BPMN (разработчики подхода к построению эффективных систем управления от Прикладного мира де факто проигнорировали/открестились от идеологии и подхода by BPMN), и, что не менее интересно, верно наблюдение и в другую сторону: подход к построению эффективных систем управления by BPMN от IT мира НИЧЕГО не взял из ИСО 9000 (в библии BPM CBOK нет ни одной смысловой ссылки на ISO 9000, нет ничего про PDCA или 400 требований - ПОЧЕМУ?! Почему IT мир подверг анафеме важные знания Прикладного мира? Казалось бы клиенты IT мира (Прикладники), расстарались, провели исследования, и "на блюдечке с голубой каемочкой" смогли сформулировать что-то с их точки зрения очень важное (3 млн. организаций!!!!! строят свои системы управления по модели ИСО 9000), а IT мир снобистки все эти наработки своих клиентов ОСОЗНАННО пропустил "мимо ушей"!!!!???? Каких только глупостей о роли и смыслах ИСО 9000 для жизни Прикладного мира и их значения для построения эффективных систем управления я не наслушался от представителей IT мира!? А все мои попытки сказать им, что они не правы в своих оценках воспринимаются ими как советы идиота! "У нас в IT мире ГАРМОНИЯ!!! Не нарушай ее своими глупыми предположениями!!! Ты просто плохо знаешь, то что мы делаем, иначе бы ты не задавал своих глупых вопросов, а вместе с нами пребывал бы в нашей ГАРМОНИИ!". Все! ВСЕ (я не шучу)!!!! мои диалоги с представителями IT отрасли идут именно так((( Я устал от этого невежества, мой консалтинговый бизнес от этого невежества может пострадать, но что еще хуже, здесь и сейчас предприятия не по детски страдают из за этого конфликта подходов (фактически живут/должны управляться и жить по ИСО, а вынуждены существовать через КИС по видению системы управления IT подхода, а они разные и не сходятся в результатах!!!). Поэтому я и пришел на ХАБР, чтобы разобраться во всей этой ситуации и найти из нее согласованный выход!!!
Менеджмент не наука, потому что в нем, прежде всего, невозможно провести научные эксперименты и на их основе вывести строгие доказательства (научный подход в строгом смысле не возможен). Ибо не возможно дважды (а с т.з. научного подхода к исследованию лучше проводить сопоставимые эксперименты столько раз, сколько потребуется) поместить одну и ту же организации в идентичные исходные условия, поменять в организации какие-то управленческие решения и сравнить полученные результаты (прокрутить один и тот же год работы организации с одинаковыми условиями, только с разными управленческими решениями, увы, НЕ ВОЗМОЖНО, поэтому и менеджмент - не наука)))) и с этим трудно поспорить!)
Вторую ссылку не осилил (слишком много букв и много воды, чтобы найти зерно), поэтому не понял что Вы ею хотели сказать (какую мысль донести). Если это важно - сформулируйте ее не заставляя меня читать такие большие тексты? Про ТРИЗ - это восторг и восхищение гениальностью автора! Сильнейший инструмент - библия для конструкторов!!!! За рубежом во многих инженерных центрах - это обязательная область знаний, без которой с тобой даже разговора не начнут при приеме на работу!!! Там это признанная КЛАССИКА, у нас же в стране - это, увы, забытая мелодия для флейты(((
Неожиданно для меня, то, какие вопросы Вы мне задавали, то, какой пример привели, на что акцентировали внимание (я все это сам никогда не смог бы предположить) дали мне так много пищи для ума, что у меня сложились все пазлы, и я для себя сформировал логичное объяснение специфики и различий наших подходов и т.з.! Естественно, все «с моей колокольни», т.е. не факт, что Вы мои объяснения одобрите?)))
Важные различия, которые я для себя отметил (дополните/поправите меня при необходимости):
1. Мой пример – процессная модель для организации в целом, Ваш – про производство только. Т.е., Вы сочли приемлемым, в качестве примера привести «кусочек», а в моей парадигме «процессный подход» не имеет смысла, если он не охватывает организацию в целом. Все по Фрейду)) мне бы и в голову не пришло показать «фрагмент» (для меня это категорическое искажение смыла), а для Вас – это приемлемо (потому что все равно, что показывать, т.к. смысл, с Вашей т.з можно увидеть и в «фрагменте»).
2. С Вашей т.з. (я так понял) чем детальней описание (больше процессов), тем лучше. А у меня совершенно другая установка: как подобрать минимальное количество процессов, которого будет достаточно для эффективного управления предприятием (у меня точно нет критерия «чем больше, тем лучше», для меня это ненужное усложнение задачи управления предприятием).
3. В моем представлении нотация описания процесса чрезвычайно нагруженная (для описания требуется огромное количество связей (напомню, граф СЕТЬ, связи каждый процесс с каждым), полей, логик, метрик, предполагается сложное внутреннее содержание процесса, допускается большое количество участников процесса с разными ролями, и много другое, все есть в ИСО 9001), а у Вас, по сравнению с моим представлением, описание процесса предполагается минималистическое и участник(и) с одинаковой ролью. Я бы эту разницу оценил минимум раз в 100 (а может и в 1000). И тогда понятно, почему, я дорожу количеством процессов (это очень дорого управлять процессом, нужно совершать очень много действий, обрабатывать большое количество данных, согласовывать работу сети процессов при обнаружении важных отклонений/изменений в любом из них, …), а Вам увеличить количество процессов - легче легкого!
4. У меня небольшое (по сравнению с Вашей моделью) количество процессов, потому что моя процессная модель подразумевает связи каждый с каждым (для обеспечения гибкого и быстрого согласования работы всех процессов предприятия при обнаружении потребности изменения), и любое добавление нового процесса в модель кратно увеличивает количество связей и сложность согласования (поэтому нет цели «чем больше, тем лучше» в т.ч.). Ваша же модель строится на линейной последовательности процессов, в которой требовать связи каждый с каждым – глупость (я теперь понял Вас и Вашу реакцию на СЕТЬ и связи каждый с каждым))))
5. Требование наличия владельца процесса в вашей модели, как мне кажется, излишняя надуманная избыточная опция, особенно, учитывая такое огромное количество процессов и желание увеличивать их количество для точной детализации соответствия. В моей модели без владельца процесса НЕЛЬЗЯ, и их в организации не много (по небольшому количеству процессов), и их роль (нагрузка, ответственность и полномочия, управление регламентами, ресурсами, участниками процесса, распределение работ, управление отклонениями/изменениями и т.п.) чрезвычайно значима (поэтому и так много рождено текстов в инете, что без них нельзя, но для какой модели?).
6. Границы процесса – у меня по сравнению с вашей моделью, просто огромные. Ваши процессы с примера целиком влезли бы в один процесс в моей модели с названием производство (ну или в 2-3). Поэтому я и ответил, что не вижу проблем с «отпроситься» - это рутинная обязанность владельца процесса, и сотрудников, которые участвуют сразу во многих процессах в моей модели нет (ну может быть в 2-3 смежных), и для меня это не является сколь-нибудь важной проблемой! Поэтому для меня выглядело диким предположение о том, что практически все сотрудники организации участвуют в огромном (от 20 и больше процессах), что для Вас это важный аспект и что это критерий работоспособности процессной модели (для меня вообще не существенно).
Теперь, собственно, мои выводы и анализ причин (все с моей колокольни и делаю оценки более категоричными, чем на самом деле есть, чтобы подчеркнуть мою мысль/идею)
1. Ваша модель родом из задачи «автоматизировать» деятельность предприятия (создать двойник в компьютере). Для этого в 60е годы с появлением первых компьютеров была придумана соответствующая технология и нотации. На самом деле эта модель и нотации описывают элементарные ОПЕРАЦИИ и их последовательность (чем подробнее, тем лучше). Это почему то назвали процессами и процессным подходом. Правильней/ближе сейчас это называть созданием цифровых двойников, наверное. При таком описании, никакой разницы для технологии переноса операций нет функционально-иерархическая модель управления у предприятия, процессная ли, функциями ли называются переносимые действия или операциями. Поэтому я теперь понимаю, почему для вас это все одно и то же, и почему BPM CBOK такой (он весь про перенос операций, там ничего нет про управление из стандартов ИСО серии 9000, понятно теперь и почему эти стандарты про управление IT шникам как 5 колесо в телеге, для решения задачи автоматизации они не нужны)
2. Моя модель (ИСО серии 9000) родом из 2000 года, когда прикладники, замученные неприемлемой эффективностью предприятий, пришли к консенсусу, что коренная причина проблем - господствующий функционально-иерархический подход к управлению, который в условиях роста номенклатуры, непредсказуемой изменчивости спроса и т.п превратился в генератор проблем. Прикладники провозгласили, что выход из кризиса не эффективности – совершение революции в области управления - переход на процессный подход. Цели этой революции – повысить эффективность работы предприятий. Цель автоматизация, или перенос операций в компьютер НЕ СТАВИЛАСЬ и НЕ РАССМАТРИВАЛАСЬ от слова СОВСЕМ! Рассматривалась ИСКЛЮЧИТЕЛЬНО задача создания быстро и эффективно реагирующей системы управления (все действия сотрудников организации согласованы и все в любой момент времени в организации делают только то, что нужно, и не делают что не нужно). Поэтому и другая процессная модель (другая цель - другое решение). Поэтому в стандартах ИСО серии 9000 нет ничего из BPM CBOOK.
3. Большая причина проблемы - терминологическая и те и те используют термины процесс и процессный подход с абсолютно разной смысловой нагрузкой для совершенно разных целей. Если в задаче автоматизации и использования для решения этой задачи нотаций вместо терминов Процесс и Процессный подход, использовались термины ОПЕРАЦИЯ и КАРТА ОПЕРАЦИЙ, а процессы и процессный подход как термины оставили стандартам ИСО серии 9000 с их управленческой нагрузкой, было бы проще всем. Так что Шеер мог бы быть поаккуратней)))
У меня все сошлось! Еще раз, Спасибо Вам за помощь – Вы мне сильно посодействовали в осмыслении!
Прежде чем отвечу, не могу не поделиться ощущением о формате и содержании нашего общения: мы общаемся как представителей разных миров/планет! Т.е. диспозиция такая))) Вы, в своем мире, находитесь в полной гармонии со своими знаниями, тут появляюсь я "чудик из другого мира" с непонятными т.з., которые могут нарушить Вашу гармонию, и Вы из вежливости лениво поддерживаете беседу с целью тихонечко меня выпроводить восвояси))) По содержанию: мне Ваши вопросы/оценки кажутся неожиданными/странными, а вопросы, которые должны были бы задать - не задаете!? Вы, видимо, аналогично воспринимаете мои ответы и т.з. По формату: Я пишу большие тексты, стараюсь аргументированно и структурированно описать свою т.з., ожидая ее обсуждения. Вы - системно уклоняетесь от оценок и обсуждения (понятно/не понятно) моих описаний, вместо этого задаете, как мне кажется, вопросы, чтобы "срезать" и не погружаться в изучение/обсуждение моей т.з. как заведомо неприемлемой! В общем непримиримая война миров какая то...
Теперь, собственно, ответ:
Мне очень сложно представить ситуацию:
Сотрудник обычно участвует куда более чем, в 20 процессах компании.
Вот базовая процессная модель предприятия о которой говорю я. В ней всего около 20 процессов. Возможны варианты, когда каждый из указанных процессов необходимо детализировать (разбить на 1-3 подпроцесса) или когда некоторые процессы будут объединены. Попробуйте на этом перечне процессов привести пример сотрудника, который участвует в 20 (получается во всех) процессах? Очевидно что Вы не эти процессы и не эту процессную модель имели ввиду? Какова Ваша процессная модель (приведите пример)? В чем наше не совпадение, мы сможем выяснить?
Нет. У меня договор о конфиденциальности, извините, но я не имею права давать информации больше, чем поделился.
Мой исходный комментарий не про проблему конкретного решения вендора (не про то, что оно слабое и т.п.), а про то, что размерность задачи имеет критическое значение, какой бы вендор не пытался ее решить. Там основные проблемы связаны не столько с дефицитом производительности (он преодолевается, производительность систем растет и это вопрос времени решения этой проблемы). Основная проблема была в том, что завод физически не успевал актуализировать многочисленные справочники (так много и так быстро происходили изменения)
Хочешь уйти, но ты сейчас должен работать в 20 процессах - нужно согласовать свой уход для 20 процессов, иначе как они будут работать, если ты неожиданно уйдешь не предупредив!?
В каждом процессе у него своя загрузка, свои критерии оценки
При разработке процессов, которые предусматривают участие одного человека в 20 процессах должен быть рассмотрен вопрос его допустимой (бесконфликтной для работы этих 20 процессов) загрузки. Если этого нельзя обеспечить, то такое использование человека (такие процессы) не должны быть согласованы (зачем планировать такой вариант выполнения работ, который гарантированно не будет исполнен)!? Если же процессы одобрены, т.е. конфликтов не обнаружено, то у человека будет должностная инструкция Как он работает в таком-то процессе, как в другом... Если конфликт загрузки произойдет - будет рассматриваться вопрос решения проблемы (пересмотр процессов или загрузки человека)
Если один и тот же человек планируется к работе в 20 процессах одновременно, то на момент разработки плана работы этих процессов "проблема" всплывет и будет решаться и разрабатываться н допустимый план этих процессов
Смыслы, логики и решения аналогичные. А как по другому то?!
Корпоративная информационная система управления заводом (решение класса ERP с функциональностью подетального пооперационного планирования), отечественный разработчик
Есть ли подробное описание реального внедрения процессного подхода на предприятии? Особенно предприятия "без орг-структуры".
Прикладная задача звучит так: как предприятие, управляемое здесь и сейчас по функционально-иерархической модели (в ней обязательно есть оргструктура, как базовый элемент этой системы управления), перевести на процессное управление (в которой нет оргструктуры как необходимого элемента системы). Люди остаются, но описание их взаимодействия теперь будет определятся не оргструктурой (получаю задания только от своего начальника и работаю по регламенту), а их полномочиями и задачами в рамках взаимодействия с другими процессами (процессы сами для себя осуществляют весь цикл управления PDCA согласуют планы, осуществляют мониторинг на прямую, не через начальника)
В самой первой версии от 2000 года в стандарте iso 9000 "Основные положения и словарь" был такой раздел с описанием этапов перехода на новую систему управления (в последующих версиях его исключили):
А в стандарте ISO 9001 "Требования..." предъявлялись детальные требования к тому, что должно быть определено для выделенных процессов, что обязательно должно быть получено в результате их работы и т.п.
Этапы перехода: Создание проекта процессной модели, Формирование проектов описаний процессов и управления ими (как будет на основании взаимодействия с другими процессами формироваться план работы процесса, ...), Согласование процессов в рамках процессной модели (утверждение регламентов, должностных инструкций, полномочий,..) , Апробирование/Тестирование, Переход на созданную модель управления (упразднение старой функциональной иерархии Дерево, переход на управление предприятием Сеть, где объектами управления являются процессы с Владельцами процессов))
Задам еще один вектор "на подумать" в задаче определения и области применения цифровых двойников для промпредприятий. Для этого сначала будет кейс, потом вывод с выходом на постановку задачи для DT
Кейс
Поделюсь таким своим опытом наблюдения внедрения IT системы управления на ХХХ заводе (я не имел отношения к внедрению, я был сторонним наблюдателем): за 4 года, пока я работал с заводом, все 4 года, несмотря на огромные усилия и кампании, «запустить» IT систему не смогли((( Причина: слишком большая размерность задачи при постоянно большой изменчивости ее составляющих (количество деталей на единицу готовой продукции от 15 000 до 30 000 наименований, количество операций техпроцесса для одной детали от 10 до 50, количество единиц оборудования 1000 – 10000 единиц, количество сотрудников около 5 000 чел и т.д). Завод элементарно не мог обеспечить соответствие справочников фактическому состоянию + размерность задачи была такая, что время расчета расписаний не представляло никакой практической ценности (за время расчета гарантированно происходили изменения, которые превращали его результаты «в тыкву», т.е. требовали обязательного перерасчета).
Вывод и выход на постановку задачи для DT
Напрашивающийся вывод попытка "в лоб" (один в один) создавать цифровые двойники предприятия, начиная с определенной размерности задачи - это ОГРОМНЫЕ затраты, которые с высокой долей вероятности не окупятся в виду огромной изменчивости и необходимости скрещивания в единую аналитическую систему данных с DT и не c DT (управлением и агрегацией которых большая проблема).
Выход на постановку задачи для полезного/эффективного применения DT:
Нужен подход к снижению размерности задачи "какое минимальное количество характеристик с какого минимального количества объектов с какой максимально возможной периодичностью съема данных нужно собирать с помощью DT, чтобы собранная система позволяла организовать эффективное управление прикладным объектом (системой объектов)". Без такого решения будет гарантирован результат "Из пушки по воробьям"!
В связи с этим, обсуждение задачи DT ради DT как сферического коня в вакууме (как техническую IT задачу только), без привязки к прикладным объектам управления (особенно в случае сложной системы объектов, типа предприятие) и без решения специфической задачи размерности DT для этой сложной системы объектов - не более, чем интересное занятие с туманными перспективами. Т.е. DT - это не столько техническая или IT-задача, сколько прикладная, и постановку задачи DT нужно делать в жесткой связке с решаемой прикладной задачей и системой объектов. Например: DT для управлением надежностью оборудования - это такая то модель применения DT. DT для управления качеством операций - другая модель применения DT, хотите построить минимально работающий DT предприятия - это такой то набор объектов DT с такой то схемой агрегации данных для решения таких-то задач управления и т.п.
Я только повторяю Шеера, а более связанной теории BPM чем изложена в книжках ARIS (библия BPM) – я не встречал.
Я повторю свою т.з. про то, что представление о процессном подходе, основанное на BP CBOOK и ARIS (библия IT мира) и в изложении международных стандартов ИСО серии 9000 (библия прикладного мира) - это две большие разницы!!! (здесь на ХАБРе я эту мысль уже озвучивал).
Сформулирую резкое/категоричное оценочное суждение: Представители IT-отрасли страшно далеки от Прикладной области знаний, в котором живет и которым руководствуется реальный мир, для которого IT-мир разрабатывает IT-решения!
ISO серии 9000 - это свод знаний по УПРАВЛЕНИЮ обеспечивающему устойчивое развитие предприятий/организаций (эти стандарты даже называются стандартами на СИСТЕМЫ МЕНЕДЖМЕНТА!!! как и в каком мире знаний надо находится, чтобы отрицать этот факт!?). Это такая же библия по управлению для Реального мира, как BMP CBOOK для IT-мира. Количество организаций реального мира, сертифицированных (т.е. продекларировавших что они в управлении руководствуются требованиями стандарта ISO 9001) около 3 000 000!? Но увы и ах, и в этом, повторю свою мысль, ОГРОМНАЯ проблема заключается в том, что эти две области знаний (международные стандарты ISO серии 9000 и BMP CBOOK) практически НЕ ИМЕЮТ ПЕРЕСЕЧЕНИЙ!? В ISO Вы не найдете ссылок на нотации BPMN, IDEF... - там продвигается другая нотация и механизмы процессного управления. Верно и обратное утверждение: в BPM CBOOK нет ссылок на нотации и механизмы из ISO. ЧТД(((( It мир разговаривает на своем "птичьем" языке, реальный - на своем((( Страшно далеки они друг от друга!
Вероятно по этой причине существенно отличаются наши представления о "процессном подходе" и этим и объясняются связанные с этим споры и оценки?
Мой анализ ситуации (как субъективная т.з. эксперта от Прикладного мира) в качестве ремарки про "библию ARIS от Шеера":
Следует учесть факт того, что ARIS появился в 1994 году (как развитие методологии автоматизации деятельности предприятий разработанной в 60х годах) , а Прикладной мир сформировал свою т.з. на процессный подход в 2000 году. Т.е. на момент разработки своей библии про процессный подход Прикладной мир знал что есть ARIS, но НИЧЕГО из этой системы знаний в свою библию по факту не взял. Возникает законное любопытство (А) ПОЧЕМУ международная группа разработчиков этих стандартов проигнорила ARIS вместе со всеми его нотациями BPMN и IDEFx!? (Б) Зачем и что напридумывали СВОЕГО Прикладники, игнорируя все наработки ARIS? (B) Почему BPM CBOK вышедший на свет в 2003 году (т.е. на момент разработки уже хорошо было известно, что понимает и какой процессный подход хочет иметь у себя Прикладной мир) имел шанс гармонизироваться с ISO серии 9000, но ответил взаимностью, и НИЧЕГОШЕНЬКИ из библии Прикладного мира по факту не взял? (Г) Почему за 25 лет не посчитали нужным гармонизироваться друг с другом две параллельно существующие области знаний про процессный подход (тем более что по определению IT отрасль должна обслуживать и работать на Прикладной мир, т.е. должны были, как минимум, внимательно изучать друг друга, а вместо этого обе стороны ВЗАИМНО и упорно игнорят друг-друга)?
На момент разработки ARIS (1994 год) господствовал функционально-иерархический подход к управлению. Поэтому сущность и описание процессов и процессного подхода Шеером определяется через терминологию функций (ИМХО, именно поэтому для Вас это одно и тоже и Вы правильно при этом ссылаетесь на первоисточник такого восприятия). Т.е. де факто ARIS являлся разработкой IT отрасли в решении задачи "Как перенести в компьютер с помощью процессных нотаций BPMN и IDEFх функционально-иерархическую модель управления, которая работала на 100% предприятий Прикладного мира" на тот момент времени
В 2000 году Прикладной мир объявил о потребности коренного преобразования систем управления (переходе с функционально-иерархического подхода к управлению предприятием, на процессный подход к управлению предприятием, как более эффективной альтернативы) и выпустил для этого свою библию ISO серии 9000. Обращу Ваше внимание, что термин функция ДЛЯ ОПИСАНИЯ И ОПРЕДЕЛЕНИЯ процессного подхода к управлению предприятием НЕ ИСПОЛЬЗУЕТСЯ! Разработчики ISO серии 9000 логично посчитали, что раз нужно заменить функционально-иерархичный подход на процессный (уйти от функций к процессам), то будет методически неправильным определять новую управленческую конструкцию процессного подхода с помощью старых элементов функций! По той же причине (повторюсь) Вы не найдете в этих стандартах и упоминаний про оргструктуру, т.к. в новой управленческой парадигме "процессный подход" она не нужна (она необходима была исключительно в старой модели).
Про восприятие ISO серии 9000 - я с этим неправильным и снобистким восприятием IT отрасли смысла и назначения этих стандартов сталкиваюсь постоянно! Все мои оценки, что озвучиваемое восприятие КАТЕГОРИЧЕСКИ не верное, попытки и призывы пересмотреть свое отношение и изучить эти стандарты наталкиваются на категорическое отторжение (поэтому я и применил термин СНОБИСТСКОЕ отношение). Такое отношение и реакция на ИСО серии 9000 - удивительно устойчивое и воспроизводимое, с каким бы представителем от IT отрасли я не общался!?
Моя версия причин такого СНОБИСТКОГО отношения к библии (смыслу и инструментарию процессного подхода) Прикладного мира: (А) циничная и рациональная бизнес-позиция IT отрасли "А Зачем нам что-то переделывать/переучиваться/вкладываться в разработку чего то нового, если и так все хорошо продается!". Результаты в виде "Автоматизации ХАОСА" IT отрасль не очень беспокоят, т.к. по сложившемуся стандарту взаимоотношений, ответственность за это несет ИСКЛЮЧИТЕЛЬНО ЗАКАЗЧИК (очень удобно устроились - завидую, как консультант, черной завистью) и (Б) а так исторически сложилось, что IT отрасль с момента рождения всегда сама была поставщиком задачи и у Прикладников ничего не брала/не училась (они не могли выступить в роли Постановщиков задачи) . Для того времени 60-90ее годы по другому, наверное, и нельзя было, т.е. это было правильное поведение. Но начиная с середины 90х годов Прикладной мир консолидировался и существенно рванул вперед, а IT отрасль, по привычке, этого не заметила и проигнорировала, т.к. привыкла к роли самодостаточного постановщика задач, от которой отказываться не хотела/не могла!
А у вас ботинки какого цвета? Это я намекаю на Вашу способность вести связанный диалог, Вы вместо того, чтобы продолжить/развить обсуждение, все время меняете тему; Вы что-то спрашиваете, я отвечаю, вместо того чтобы ответить взаимностью и продолжить обсуждение по заданной Вами же ветке, Вы ее бросаете, и генерите новый вопрос? Мне так беседу вести совсем не интересно!!!
ВВВЦМ, РегионПром, Модуль-Т,... - Вам стало легче?
У нас с Вами несовпадение в оценках и, согласен, в этом надо разобраться!
Изложу свои несовпадения и сомнения:
1. Вы говорите, что нет разницы и все одно и то же (что функции, что процессы). Но моя практика и мои наблюдения говорят об обратном. На какое бы предприятие я не попал, вижу одни и те же проблемы–следствия функциональной иерархии, как модели управления:
· Производство говорит, что им портит жизнь служба продаж, заключают такие контракты по объемам и срокам, что никакой эффективности производства нет и в помине, исполнить контрактные обязательства, которые обещала клиентам служба продаж не возможно!
· Закупки загнали в запасы огромные средства, гораздо больше нормативов, и при этом нужные комплекты материалов выдать в производство не могут;
· Снабженцы закупают такие инструменты, метизы, и т.п. которые не обладают требуемыми свойствами от слова совсем, их срок службы минимален, стойкость, надежность – неудовлетворительные;
· Конструкторы множат такую большую номенклатуру изделий, пренебрегая унификацией, что производство и снабжение вешаются, а договорится об унификации – это пройти 7 кругов ада;
· Технологи разрабатывают такие техпроцессы с такими нормативами, которые с реальными возможностями производства не совпадают (причем в обе стороны);
· Плановая служба генерит неисполнимые планы, предполагая у производства такие мощности и возможности, которых в производстве никогда и не было;
· Производственные цеха получают премии за выполненные объемы производства, а предприятие не может из готовых деталей набрать нужные комплекты для сборки заказанных продуктов;
· Один цех обрабатывает сейчас те детали, которые в ближайшее время никому не нужны, а нужные и не думает брать в работу;
· И многое, многое другое…
О какой согласованности действий и планов, присущей процессному прямому взаимодействию, Вы говорите!? Только хаос, разбалансированность и несогласованность присущие функциональному подходу!? Какие такие сквозные процессы!?
2. Вы простите меня, но я за свою долгую практику работы с предприятиями (можете посмотреть мое резюме в моем аккаунте) ни разу не слышал, чтобы использовали термин «сквозные процессы»!? Может это не рабочий термин предприятий!? Может это навязанная им сущность (IT шниками), которая им не нужна, не используется?
3. Извините, понудю еще немного: что это за приставка «сквозной» к процессам? Масло масленное!? Процессный подход по определению и нужен для того, чтобы любой процесс через прямые связи мог выйти на любой уровень (прежде всего на Потребителя и его требования). Т.е. любой процесс по определению участник «сквозных» процессов (ибо доступны связи каждый с каждым).
4. Еще нудю, должен уточнить – Вы свои оценки «одно и то же» на основе каких артефактов сделали? На бумаге можно предположить что угодно (все одно и тоже), на практике же все совсем не так, как в теории. Поэтому у меня и вопрос про Вашу практику и специфику (моя специализация и наблюдения – промышленные предприятия и холдинги). Может разница в оценках связана с отраслевыми отличиями?
Надеюсь, мои мысли Вас не обидели и мы конструктивно пообщаемся?
Не совсем так. Мир знаний и представлений об управлении радикально изменился с 2000 года (по историческим меркам - вчера). До этого времени почти 300 лет господствовали знания и представления об управлении предприятиями на основе функциональной иерархии, которые успешно работали в практически стационарной среде "Спрос больше Предложения) (аналогия для управления движением тел достаточно было знаний "Классической механики"). Но как только технический прогресс и массовое промышленное строительство развернули среду на 180 градусов (Предложение стало больше Спроса), это радикально изменило поведение игроков на рынке, требования к результатам, в этих радикально других условиях (среда стала турбулентной, не предсказуемой и очень изменчивой, бал стали править не предприятия а Потребители) оказалось, что старые подходы к управлению основанные на управлении предприятиями как функциональной иерархией перестали эффективно работать (оказались крайне не эффективными). Человечество вынуждено была искать более сложное альтернативное решение по эффективной работе в новых условиях. И процессный подход к управлению предприятием - это и есть этот ответ (придумали "Теорию относительности" раз "классическая механика" перестала работать). Поэтому природа нашего взаимонепонимания, не из-за того что я ленюсь и не разбираюсь в определениях и принципах "Классической механики", а из-за того что я говорю на языке "Теории относительности" (а там другие сущности, иная логика, более сложная система знаний и решений), а Вы на языке "Классической механики". Здесь понятна методическая сложность: невозможно на аксиоматике и определениях "Классической механики" объяснить "Теорию относительности". При этом Вы как эксперт в области "Классической механике" убежденно верите в то, что она работает везде и ничего другого не надо выдумывать. И идет переходный процесс смены управленческой парадигмы... Я как то так вижу причины проблем взаимонепонимания в нашей дискуссии...
Короткий ответ: по разному будет исполняться цикл управления PDCA: разная длина, разные маршруты и разная информация будут циркулировать по системе управления Дерево и по системе управления Сеть. До тех пор, пока внешняя среда стационарна, эта разница не существенна, как только мы представим, что все клиенты требуют специфические скрепки (разные материалы, свойства, размеры, форма, объемы, сроки, надо проверять готовы ли, сможем, когда, все согласовать, сообщить клиентам корректные сроки/стоимости и т.п.), то разница в маршрутах и скорости/качества реакции отделов 1.Продажи (и его подразделения службы продаж), 2.Планирование производства (цеха и диспетчерские подразделения цехов), 3.Закупки (и подразделения по закупке), 4.Производство (цеха операции), 5. Поставка (подразделения по организации поставки) если они представлены как Функциональная иерархия (информация движется только по вертикалям) и если управление этой деятельностью возможно напрямую (управляется как процессы), то разница будет существенной.
Мы опять зациклились - у меня, извините, дежавю от не знаю какого уже круга топтания на одних и тех же вопросах-ответах!
Вы вольно обращаетесь с терминами. Нет никакого функционального или процессного управления. Есть просто управление или процесс управления, который применяется в организации.
Ну вот, теперь мы договорились до того, что отрицаем наличие функционального и процессного подходов к управлению!? Более, того, Вы утверждаете что даже терминов таких нет!? Вы действительно утверждаете, что нет и не может быть никаких различных подходов к управлению!? Ок))) Мне Ваша позиция предельно понятна, я с ней категорически не согласен, но новых объяснений/аргументов к уже мною сделанным давать не вижу смысла. Вы считаете так, я считаю по другому!
Пожалуйста, не приписывайте мне утверждения, которых я не делал типа "стоя на позициях функционального управления".
Это утверждение сделал Я в отношении Вашей позиции к стандартам ИСО серии 9000, не приписывайте это утверждение себе (Вы его не можете сделать, потому что в Вашем мире нет никаких функциональных или процессных подходов к управлению (к построению эффективных систем менеджмента предприятий)! Иного утверждения после моих многократных пояснений о концепции TQM, о назначении и области применения международных стандартов ИСО серии 9000, я сделать не могу - Вы мне не оставили пространства для иной оценки! Ну не хотите Вы видеть в в этих стандартах претензий на целостное гармонизированное управление предприятиями, хотите видеть узкофункциональный стандарт по управлению исключительно аспектами качества: как этот факт можно по другому откомментировать то!? На что тут обижаться?!
Честное слово, я нахожусь в растерянности от нашей дискуссии и искренне не понимаю, как нам ее мирно и культурно завершить!?
Давайте попробуем так:
Вам моя позиция и ее аргументация (вне зависимости от того согласны Вы с ней или нет) понятны? Если Вы видите дефекты в представленной мною пояснениях (что делает мою позицию не логичной конструкцией вообще) - укажите на них, я попытаюсь ответить/исправиться? Это не значит, что Вы с моей т.з. будете согласны, это только будет означать, что моя неправильная с Вашей т.з. позиция Вами понята правильно, как я и хотел ее донести, и была Вами отвергнута?
Итак нужно ли для Вас что-то пояснить, что не понятно по моей позиции?
Странное дело, я считаю, что все уже про разницу Вам разжевал (и не по одному кругу), а Вы мои аргументы "в упор" не видите, все требуете эту разницу описать!? Смотрите, что получается: для меня, то что я пишу - ОТВЕТ с большим смыслом, а Вы этот мой ОТВЕТ из-за того, что его либо не понимаете, либо не видите в нем смысла, либо в Вашей системе знаний это совершенно не значимый факт, что то еще... но пропускаете (не воспринимаете) как ОТВЕТ!
Вот попробовал свести в табличку мои ответы (правда не знаю, как ее корректней отобразить - исходник сделал в worde):
Услышьте уже меня: то что называется процессным подходом в ARIS и в ISO 9000 - две огромные разницы!!!! ARIS НИКОГДА не мог и не может (в нем даже средств таких не предусмотрено) реализовать процессный подход by ISO 9001. То что Шеер обозвал процессами и процессным подходом не соответствует тому, что в ISO 9001 называют процессами и процессным управлением. Модель процессов которую способен сформировать ARIS - это описание функциональной иерархии языком операций, которое обозвали процессами и процессным подходом! Именно этот снобизм IT отрасли, который не видит и не понимает разницы, при этом не хочет учиться, меня поражает! Я Вам уже наверное более 10 раз явным образом сказал что разница огромна, написал кучу текстов, аргументов. Вы в ответ не привели ни одного аргумента, кроме деклараций что подход by BPM одно и то же и все он реализует (и Lean - что категорическая неправда, и PDCA - до сих пор не увидел примера применения, в ИСО - PDCA вшит в нотацию, в BPM - ничего и близкого нет), но каждое сообщение мне опять и опять утверждаете что процессней ARIS и BPM ничего на свете нет, он может все (сильно во что-то верить, это может быть и хорошо, но не плохо бы уметь рационально объяснить, привести аргументы, доказать, а не просто ВЕРИТЬ)!!! Я устал уже Вам повторять, что ARIS (ИЗЬ by ARIS) может мало чего, и результаты дает неприемлемые, именно на замену ему ISO версии 2000 придумали!!! Видимо, Вам как специалисту по BPM это принять очень не просто...
Да я Вам уже говорил, что я не делаю НИКАКОГО упора на "только автоматизация" или "есть еще реинжиниринг с управлением". Я Вам говорю о том, что подход к формированию процессного управления by BPM такой, что автоматизация ли, реинжиниринг ли, управление ли - все вместе это будет реализовано, или по отдельности, но эти решения будут давать НЕПРИЕМЛЕМЫЕ результаты!!!! Потому что модель процессов и процессного управления by ARIS (BPM) слабенькие, в ISO намного интересней/мощней идея!
Про надежность
То что описано в ссылке на Вашу публикацию - это точно другой язык, другая проблематика и другие решения вроде бы универсальной задачи про надежность, чем родственная постановка задачи в Прикладном промышленном мире. В Вашей публикации говорится про какую-то IT надежность (как я это воспринял).
Постановка задачи надежности в Прикладном мире - это термины стабильности/воспроизводимости технологических операций, процессов, соответствующие индексы CP/CPk, планы управления операциями и контрольные карты Шухарта (в автомобильной отрасли) или хорошо распространенная аналогичная по идеологии (немного другая по исполнению и инструментам) методология 6sigma. Их идеологическая основа - изучение влияния факторов изменчивости действующих на процесс, и выработка планов управления процессом на основе наблюдения за особо сильнодействующими факторами изменчивости. Алгоритм: выявить факторы изменчивости действующие на процесс, определить какие из них и как влияют на процесс, выделить существенно влияющие, научится наблюдать за ними, построить план управления процессом в зависимости от результатов наблюдения. Эту революцию в управлении качеством процессов IT-отрасль, с моей точки зрения, так же проигнорила/проспала, т.к. этих решений нет в текущих релизах ERP, и в специализированных IT решениях (которые я наблюдаю в компаниях-клиентах) для конструкторов, технологов, производственников, ремонтников оборудования(((
И мой главный вопрос, который меня интересует (из за чего я пришел на ХАБР): за какие ниточки нужно подергать, чтобы IT отрасль "повернулась передом" к знаниям Прикладного мира (которые откровенно проспала, и поэтому де факто кормит Прикладной мир только идеологически устаревшими продуктами, т.к. других у нее нет) и начала процесс изучения и интеграции этих знаний в IT продукты?
Как и кому нужно эту идею донести? Что сделать, чтобы IT отрасль начала учиться (перестала думать что все знает и так)?
Про Историю стандартов ISO серии 9000, то как ее видят в Прикладном мире (как рассказываем своим клиентам ее мы - консалтинговая группа компаний Приоритет):
ГЛАВНОЕ, нужно понимать причины появления этих стандартов. Прежде всего, это потребность обеспечивать необходимую эффективность работы цепей поставок в условиях все увеличивающегося давления со стороны потребителей (ужесточение требования цена/качество, сокращение сроков и увеличение точности поставок, лавинообразный рост номенклатуры из-за персонализации требований, радикальное сокращение сроков на разработку новых изделий, работа в отсутствии "твердого ТЗ" от Потребителей (Agile в промышленности), глобализация рынков поставщиков (в цепях поставок представителей каких только стран нет)). Стандарты должны были все эти вопросы решить (единый язык для взаимосвязей в секторе B2B на требования компании финишера в цепи поставок, который поставляет готовую продукции Пользователям, быстрое согласование процессов, понятные вектора в развитии цепей поставок и т.п.).
Плохие результаты работы цепей поставок (плохое качество и срыв поставок, медленные сроки разработки и согласований, ...) - это следствия, причина - плохое управление: потери ориентации на требования Потребителя в цепях поставок, рассогласование действий подразделений внутри предприятий цепей поставок, и т.п. Управлять нужно не следствиями, а причинами, поэтому появились стандарты на системы управления Предприятий, которые отлично настраивались бы на требования Потребителя в цепях поставок В2В и могли их точно реализовать (соответствовать своим же обещаниям) - т.е. настраивались на требования по КАЧЕСТВУ от Потребителей - системы управления предприятий участников цепей поставок должны стать СМК.
Версии с 1987 - 1994 - до 2000 - попытка обеспечить выполнение вышеописанной задачи в рамках текущего функционально-иерархического подхода к управлению. Стандарты - это 20 разделов - 20 групп требований к функциональным подразделениям. Эти стандарты на УРА вписывались в BPM, т.к. в 20 разделах перечислялись операции, которые должны были выполняться в подразделениях. ГАРМОНИЯ между ISO и ARIS (который разработан в то же время - будущая основа BPM, базис как и у ИСО - управление на основе функциональной иерархии, нотации для описания операций из 60х - то что доктор прописал для этого). Тогда же создаются решения класса ERP (SAP) которые также ориентированы на модель управления на основе функциональной иерархии. Это время ГАРМОНИИ ISO-ARIS-ERP и фактически действующих на предприятиях функциональных иерархий. Тогда утверждения что ISO и ARIS (BPM) - это одно и то же, были верные!
Все бы хорошо, но проблема не решилась - результаты работы цепей поставок лучше не стали. И ERP созданные на основе ISO и ARIS - автоматизировали хаос (честно/хорошо описывали функциональную иерархию на предприятиях в виде карт операций, но в итоге получались те же неприемлемые результаты работы цепей поставок, предприятия не могли выполнить свои же обещания/планы)
Поэтому в 2000 году произошла революция в понимании, как нужно управлять цепями поставок: главным виновником была объявлена функциональная иерархия, ее предлагалось предать анафеме, а вместо нее строить системы управления на основе прямо настраивающихся непрерывно взаимодействующих процессов верхнего уровня, чтобы требования Потребителей без искажений доходили до всех сопричастных, любые изменения/отклонения - сразу обнаруживались и принимались согласованные сбалансированные корректирующие действия. Поэтому и появились стандарты 2000 года про Процессный подход, в которых в явном виде описывалось, как должно быть реализовано такое процессное взаимодействие (и именно эта нотация описания процессов в 100-1000 раз многоаспектней и сложнее, чем нотации IDEF[ или BPMN? поэтому я в т.ч. и говорю, что не может быть одинаковых систем управления, которые описаны настолько разными нотациями). Никакой преемственности со старыми версиями стандартов НЕ БЫЛО. Предприятиям, у которых были сертификаты соответствия на старые версии стандартов был дан 3х летний срок, чтобы они перестроили свои системы управления с функциональных иерархий на процессный подход в понимании ISO версии 2000.
Именно тогда сформировался идеологический разрыв и с ARIS (и с ERP решениями), которые на самом деле описывали функциональные иерархии. К сожалению, благодаря Шееру, совпало название "процессный подход" и IT отрасль де-факто проигнорила изменения в Прикладном мире, посчитав, что они давно уже "процессный подход", и снобистски не стали разбираться с тем, что в ИСО была заложена совсем другая идея, как управлять организацией, которая тоже назвали "процессный подход"!
Обеими концепциями (BPM и ISO) декларируется "Процессный подход" - да, это так (термин один и тот же, цель декларируется идентичная - процессное управление организацией)
Моя т.з. BPM и ISO описывают различные подходы как к построению, так и к составным элементам итоговой конструкции и каким образом будет осуществляться управление. Очень схематично, в ИСО мало процессов но архи много требований к тому, как они должны взаимодействовать и управляться как система процессов, в BPM очень много процессов и минималистическая нотация.
Т.е. я утверждаю НЕ СХОДИМОСТЬ результатов при разработке процессного управления by BPM vs ISO. Для одной и той же организации получаться разные по составу процессы, подходы к управлению ими как системой и очень разные результаты такого управления (я считаю, что получаемые результаты by BPM неудовлетворительные)
Я утверждаю, что такая НЕ СХОДИМОСТЬ - это большая проблема.
Увы, я не слышал о подобной постановке задачи (гипотезе о существенной разнице и НЕ СХОДИМОСТИ) вообще, как следствие не видел и соответствующих исследований. Считается, как Вы и озвучили, что по умолчанию это все одно и то же.
Это не так. С момента рождения в 2000 году, это был и остается стандарт процессного подхода. Просто вместо 8 принципов менеджмента в версии 2000 года, начиная с версии 2008 года их осталось 7 (принцип Системного подхода к менеджменту исключили). Никакого переименования не было. Как был процессный подход, так и остался.
С моей т.з. то, что Вы озвучили такое мнение, является для меня очевидным маркером того, что Вы стандарты ISO не знаете, не понимаете (иначе никогда бы такое не сказали бы). Я этим не хочу Вас обидеть (возможно Вас этим стандартам ISO учили), я лишь хочу обратить Ваше внимание на то, что информацию/знания, которые Вы получили, как бы помягче выразится, я, как преподаватель этой области знаний из Прикладного мира, считаю не очень корректными. А Вы можете вспомнить/поделиться данными о том откуда Вы получили знания о стандартах ИСО серии 9000 (кто учил, что за учебный процесс был)? Я пытаюсь понять, откуда такой искаженный и очень сильный источник знаний в IT отрасль пришел?
Согласен, в обмене "портянками" каждый отвечает на то, что ему кажется важным. Надо бы уйти от портянок)))
У меня есть бумажная версия BPM CBOK 3.0, в ней действительно есть упоминание про цикл PDCA (2 глава Управление бизнес-процессами, раздел со странным длинным названием 2.8 "Чтобы обеспечить целостность процесса и возможность непрерывного совершенствования, управление бизнес-процессом должно осуществляться по замкнутому циклу). Но это упоминание - справочная информация и декларация (даже в этом разделе никаких примеров). И в дальнейшем в примерах описания процессов по тексту я найти практическую реализацию цикла PDCA не увидел. Т.е. декларируется что это важно, что это основа, а в примерах об этом 0.
У меня есть электронная версия BPM CBOK 4.0, так там уже нет и такого раздела и упоминания цикла PDCA (я искал текстовым поисковиком и не верил своим глазам). Поэтому я и попросил скрин шоты из 4.0 если можно, и примеры описаний из него же, где по Вашему мнению описывается применение этого цикла на практике. Если в 4.0 нет таких примеров, то может из других версий найдутся скриншоты (мне очень интересно посмотреть).
Я имел в виду эту сводку от Алисы только, глубже в публикации со страницы поиска я не смотрел и не рекомендовал. Статью которую Вы посмотрели по моей вине я даже не читал. Могу сказать только, что ИМХО Теория ограничений НИКАКОГО отношения к ИСО 9000 или процессному подходу не имеет
Прежде всего, я потерялся в логике нашего диалога про разницу подходов, потому что вместо прямых оценок приведенных мною описаний этих отличий, от Вас последовали вопросы и возражения не про описанную мною разницу, а про интерпретацию взаимосвязей BPM и ИСО вообще!? Правильно ли я понял Вашу позицию, что Вы пытаетесь провести логику BPM=ISO поэтому разницы подходов НЕТ, и обсуждать мои описания не хотите (опять IT снобизм)? Ничего в этом мире не меняется, мне не привыкать...
Хорошо, по Вашим вопросам/возражениям
Я как эксперт по LEAN и стандартам ISO 9000 прочитал BPM CBOK4.0 и никаких текстов, которые хоть как то раскрывали бы содержание и смыслы этих концепций не нашел, там и близко ничего похожего нет (или Вы продолжаете относится к мои оценкам - как к бреду сумасшедшего)!? Если хотите, даже Вы не будучи экспертом в этих дисциплинах можете самостоятельно этот факт проверить: поиском по книге последовательно ищите ISO, ИСО, LEAN, PDCA и, о открытие, Вы не найдете ни одной содержательной ссылки!? Как из этого по Вашему следует "BPM - это "перепев" ISO9k \ СМК".
Поэтому выскажу свое искреннее удивление: на основе каких данных Вы утверждаете совершенно обратное!? Кто в Вас вложил эту мысль!? На основании каких аргументов вы можете это утверждение обосновать?!
Ни одного упоминания я не нашел (возможно плохо искал)!!!! Вы читали BPM CBOK4.0? Можете привести скрины упоминаний, где обсуждаются смыслы ИСО, LEAN, PDCA? Или описание какого либо процесса в нотации BPMN по которой было бы видно работу цикла PDCA (если он вшит)?
Вообще не понимаю смысла этой фразы. Для меня, здесь и сейчас, это две ничего общего не имеющие дисциплины (мягкое с мокрым, мороженое и самокаты). Что может означать утверждение рынок мороженного съел самокаты!? Что это вообще может означать, а уж тем более что то доказать? Что мороженным выгоднее сейчас заниматься? Может быть, но это не означает что самокаты перестали быть нужными. Это всего лишь сегодняшнее фото конъектуры рынка. Сегодня одно фото, завтра - другое
Рынок ИСО разделился на два лагеря: тем кому нужно здоровье (эффективность) и тем кому достаточно справки о здоровье (эффективность не нужна, достаточно справки). И тех, кому нужна справка гораздо больше! Что это доказывает? Доказывает ли это, что процессный подход и СМК от ИСО 9000 не работает? Нет, конечно! Это лишь доказывает что огромному количеству компаний (руководителям этих компаний) Прикладного мира ничего менять не хочется! А вот это большая проблема, потому что руководители то в накладе не останутся, а предприятия могут уйти в закат. Тут вопрос жесткий: ИСО (СМК и процессный подход) - это реальный выход, тогда те кто этого не понимает - смертники (или убийцы). Либо надо доказать, что ИСО - это пустышка, но только это надо доказать, потому что то что указано в Вашей цитате выше, повторюсь, не доказательство!
Это Ваша точка зрения, что идеи перетекли (объективных доказательств кроме деклараций и свидетельств от AI (который постит такие глупости, например, по LEAN - практически все не правильно, что я постеснялся бы иметь его в качестве свидетеля) Вы не привели). Моя т.з.: идеи BPM - идеологически устаревшая пустышка из прошлого века (прошлогодний снег) и до идей ISO им 200 световых лет лететь и лететь. По деньгам здесь и сейчас - согласен. Что мир изменился - то же согласен, только я считаю что он изменился так, что идеи BPM родом из 60х, из кареты превратились в тыкву, и именно на замену им и разработан подход ИСО.
Пожалуйста смотрите Алису https://yandex.ru/search/?lr=47&rq=1&text=процессный+подход+в+системе+менеджмента+качества&src=ref&serp-reload-from=rec_bottom
Но я настоятельно рекомендую изучать первоисточник
Прибыль в бизнесе - это следствие, а управлять нужно причинами (управление на основе следствий - не самый лучший подход к управлению), причина прибыли - высокая степень удовлетворенности потребителей (их готовность и желание платить организации деньги), влиять на степень удовлетворенности Потребителей возможно через КАЧЕСТВО предоставляемой продукции и процессов взаимодействия с клиентами, поэтому управлять бизнес-организацией нужно так, чтобы она постоянно повышала свои возможности увеличивать степень удовлетворенность Потребителей. Т.е. все управленческие решения в организации должны рассматриваться сквозь призму "влияния принимаемого решения на степень удовлетворенности Потребителя": хорошие решения - способствую повышению, плохие - не способствуют/уменьшают степень удовлетворенности Потребителей. Организация должна стремиться чтобы в ней принимались только хорошие управленческие решения, тогда как следствие, у нее будет много денег/прибыли. Системы управления организаций, построенные на принятии управленческих решений на основе анализа их влияния на степень удовлетворенности Потребителей, называют Системами менеджмента КАЧЕСТВА (СМК). Это были краткие тезисы аксиоматики концепции TQM и обоснование, почему стандарты ИСО серии 9000 которые посвящены построению именно таких СМК в организациях - это про общие системы управления организациями, а не про локальный функциональный кусочек про управление аспектами качества в большой комплексной системе управления организацией. В Прикладном мире - это широко известная ДОГМА. В т.ч. и поэтому 3 млн. организаций Прикладного мира руководствуются в управлении этими принципами и моделью СМК (стремятся построить и постоянно улучшать систему управления своими компаниями на основе принятия правильных бизнес-решений направленных на повышение степени удовлетворенности своих Потребителей). Наверное, из этих объяснений должна быть понятна и идея обязательной сертификации по ИСО 9001 в секторе B2B: компании потребители, требуют от компаний поставщиков, чтобы те управлялись и развивались на основе единственной главной цели - роста степени удовлетворенности от сотрудничества со своими компаниями-Потребителями. Выполнение этого требования рассматривается сторонами как гарантия долгосрочного сотрудничества. Наличие сертификата соответствия ISO 9001, в т.ч. гарантирует, что компания Потребитель может посмотреть, а компания Поставщик открыта для такого аудита, как она понимает что нужно Потребителю, и как на основе этого управляет своим предприятием (чтобы в случае чего внести необходимые коррективы).
Меня так развивают Ваши вопросы - Вас мне Бог послал!))) Как Вас зовут, где я могу посмотреть информацию о Вас (кому мне позитивные отзывы посвящать)?
Сначала сформулирую то ГЛАВНОЕ, на что продвинули меня Ваши вопросы, потом постараюсь пройтись по Вашим пунктам (поработаю на Вас и Ваши непонятки).
В моем предыдущем посте и мысли не было думать о Вашем подходе к управлению, как о подходе который не способен управлять. Моя мысль была в том, что Вы (понятно что не Вы, а обсуждаемый подход к управлению на основе BPMN и Co (подход IT отрасли), и так же верно в обратную сторону не мой подход, а процессный подход на основе ИСО серии 9000 (Подход Прикладного мира), просто так короче) к задаче управления пришли через задачу автоматизации (я написал РОДОМ из автоматизации). Упрощенно Ваш подход: создаем подробную КАРТУ ОПЕРАЦИЙ и управляем ею, в т.ч. делая реинжиниринг КАРТЫ ОПЕРАЦИЙ. Чем подробнее карта, тем понятней и лучше будут результаты реинжиниринга и управления (т.е. качество результата, определяется детальной проработкой КАРТЫ ОПЕРАЦИЙ (качеством описания содержания), или это подход к построению системы управления "от частного к общему")
В ИСОшном все с точностью до наоборот: подход к построению системы управления предприятия строится на принципе "от общего к частному". Ставка делается не на детальность описания (не на качество описания операций), а на качество управления предприятия сразу. Стандарт "говорит": не важно какие у Вас операции, сколько их и чем Вы занимаетесь (скрепки, стулья, парикмахерская, синие стринги, или красные боксеры,... - все равно), если сотрудники в организации не правильно взаимодействуют, если Вы при принятии решений не имеете такой то информации, не делаете таких то вещей, то у организации будут ОГРОМНЫЕ проблемы (драку заказывали? не важно за все уже уплачено! т.е. мина замедленного действия с названием "дефектное управление" в организацию заложена и будет работать как часы генерируя ей проблемы). Поэтому идеология стандарта: выделите ваши основные процессы (например, Продажа, Закупки, Разработка, Производство, Поставка, Управление ресурсами, Управление организацией). Не важно сколько Вы их выделите, важно, чтобы они эффективно между собой взаимодействовали (Сеть, каждый с каждым) и могли вырабатывать и реализовывать исполнимые и нужные Потребителям согласованные планы действий. Т.е. каждый выделенный процесс системы должен работать в такой среде: В каждый момент времени у любого процесса системы уже есть согласованный с другими процессами, исполнимый внутри процесса план действий (например ваш процесс производства таких-то наборов стульев на сегодня для процесса Производства) , который нужен для удовлетворения Потребителей, который Процессом внимательно мониторится, и если вдруг произойдут какие-то проблемы, то процесс тут же сгенерирует сигналы об обнаруженных отклонениях другим процессам (закупки, Продажи, ...) и будет вырабатываться новый скорректированный план действий в организации с учетом произошедших изменений (Изменится план закупок, Уйдет предупреждение клиентам о том, что обработка его заказа задерживается, Поступит сигнал в процесс Разработки о том что конструкцию или технологию надо улучшить по таким то аспектам и т.п.), если таких сбоев много, то будет инициирован реинжиниринг процесса и системы в целом (при необходимости). При этом, так как изменчивость требований потребителей и их спроса огромные, риски не выполнения планов процессов не нулевые (допустили брак, задерживается поставка, сломался инструмент, медленнее стало работать оборудование, маркетинг ошибся в оценках, изменилась цена на электричество и т.п.), то процесс разработки согласованных планов процесса и системы в целом непрерывный (это не акт, а не прерывный процесс). Тот самый цикл PDCA который вшит в управление, как обязательная нотация. Кроме того, стандартом помимо требований умения работать в вышеописанной среде, перечислены обязательные умения и процедуры, которые необходимо для эффективной работы любого состава процессов в организации (например устанавливать такую то информацию от потребителей, регистрировать несоответствия, осуществлять корректирующие действия, проводить внутренние аудиты и т.п. всего около 400 требований, к "умениям", если которых нет, то организацию не спасет и отличный навык согласованно работать как сеть в режиме PDCA в вышеописанной среде). Все разъяснения привел для Вас, чтобы объяснить специфику создания системы управления от ИСО.
Попробую резюмировать разницу подходов построения эффективного управления организацией:
IT отрасль: сначала операции и КАРТА операций (описание содержания деятельности, чем подробнее-детальнее, тем лучше), потом их реинжиниринг (как увидели и смогли) и управление описанными/улучшенными (не факт что получилось лучше, критериев то нету) операциями как КАРТОЙ операций, и тогда наступит СЧАСТЬЕ.
Прикладники (ИСО): сначала отрабатываем правильность управления (PDCA, Сетевое взаимодействие, 400 "умений") - отработка такого управления и умений вынудит нас по другому выполнять операции (происходит реинжиниринг КАРТЫ операций под критерии правильности управления с предыдущего пункта, реинжиниринг КАРТЫ операций процесса - осуществляет Владелец этого процесса, Реинжиниринг СЕТИ процессов - Координационный совет владельцев процесса или Владелец процесса Управление СИСТЕМОЙ), такой подход создаст необходимое эффективное управление (когда каждый процесс в любое время согласованно делает только то, что нужно (и не делает того, что не нужно) Организации=Потребителю) под которое произведен необходимый реинжиниринг КАРТЫ ОПЕРАЦИЙ в каждом процессе. И тогда наступит СЧАСТЬЕ.
Я старался написать это объяснение понятным не для себя, а для Вас, т.е. старался описать его так, чтобы оно было понятным и непротиворечивым с т.з. адепта и носителя знаний IT мира. Получилось ли мне понятным для Вас образом донести мысль про разницу подходов?
Теперь Ваши вопросы:
С т.з. ИСОшного подхода, во первых, это избыточная сущность, потому что все равно какие процессы сначала, потом все настроим. Во-вторых, концепция TQM (лежащая в основе ИСО серии 9000) построена на аксиоме, что в организации нет таких видов деятельности, которые не оказывали бы влияния на конечный результат "Высокая степень удовлетворенности Потребителя" (в Вашей терминологии TQM транслируется в утверждение все они должны быть привлечены и участвовать как СКВОЗНЫЕ). Поэтому попытка выделять часть видов деятельности не важно с какими критериям важности (сквозные процессы в Вашем вопросе), с т.з. TQM управленческая ошибка. Но это не означает, что в ИСО не используются классификации процессов (есть управленческие, обеспечивающие, процессы жизненного цикла (ПЖЦ) продукции, иногда их еще называют бизнес-процессами (на моем примере процессной модели это группа процессов желтого цвета) - возможно именно они наиболее близки термину СКВОЗНЫЕ. Просто в Прикладном мире, видимо, в отличии от IT мира такой термин не распространен от слова СОВСЕМ (используются близкие к нему аналоги в виде ПЖЦ или БП)
Фрагментарно следы описываемой мною логики много где есть (лучший свод - сами стандарты ИСО серии 9000). Так концентрированно и в таком виде (благодаря Вам родилось из под моего пера только сейчас) - не знаю. Я по приглашению руководства НИУ ВШЭ читаю свой курс "Теория организации" для студентов Бизнес-информатики в Нижнем Новгороде, и поэтому используемое мною с Вами изложение интерпретации ИСО 9000 и подхода к построению системы управления - это мои лекции, моя 35 летняя практика работы на земле по повышению экономической эффективности производственных Предприятий/Холдингов/Цепей поставок, моя авторская отсебятина, чтобы понятно было студентам 3-курсникам (последний вариант в нашем диалоге - отсебятина под Вашим воздействием))).
Про BPMN с моей т.з. я уже ответил выше. Только еще раз здесь акцентирую Ваше внимание на Важном артефакте, который с моей т.з. свидетельствует о принципиальной разнице подходов: В ИСО серии 9000 (первая редакция 2000, вторая 2008, третья 2015 годы) нет ни слова о BPMN (разработчики подхода к построению эффективных систем управления от Прикладного мира де факто проигнорировали/открестились от идеологии и подхода by BPMN), и, что не менее интересно, верно наблюдение и в другую сторону: подход к построению эффективных систем управления by BPMN от IT мира НИЧЕГО не взял из ИСО 9000 (в библии BPM CBOK нет ни одной смысловой ссылки на ISO 9000, нет ничего про PDCA или 400 требований - ПОЧЕМУ?! Почему IT мир подверг анафеме важные знания Прикладного мира? Казалось бы клиенты IT мира (Прикладники), расстарались, провели исследования, и "на блюдечке с голубой каемочкой" смогли сформулировать что-то с их точки зрения очень важное (3 млн. организаций!!!!! строят свои системы управления по модели ИСО 9000), а IT мир снобистки все эти наработки своих клиентов ОСОЗНАННО пропустил "мимо ушей"!!!!???? Каких только глупостей о роли и смыслах ИСО 9000 для жизни Прикладного мира и их значения для построения эффективных систем управления я не наслушался от представителей IT мира!? А все мои попытки сказать им, что они не правы в своих оценках воспринимаются ими как советы идиота! "У нас в IT мире ГАРМОНИЯ!!! Не нарушай ее своими глупыми предположениями!!! Ты просто плохо знаешь, то что мы делаем, иначе бы ты не задавал своих глупых вопросов, а вместе с нами пребывал бы в нашей ГАРМОНИИ!". Все! ВСЕ (я не шучу)!!!! мои диалоги с представителями IT отрасли идут именно так((( Я устал от этого невежества, мой консалтинговый бизнес от этого невежества может пострадать, но что еще хуже, здесь и сейчас предприятия не по детски страдают из за этого конфликта подходов (фактически живут/должны управляться и жить по ИСО, а вынуждены существовать через КИС по видению системы управления IT подхода, а они разные и не сходятся в результатах!!!). Поэтому я и пришел на ХАБР, чтобы разобраться во всей этой ситуации и найти из нее согласованный выход!!!
Менеджмент не наука, потому что в нем, прежде всего, невозможно провести научные эксперименты и на их основе вывести строгие доказательства (научный подход в строгом смысле не возможен). Ибо не возможно дважды (а с т.з. научного подхода к исследованию лучше проводить сопоставимые эксперименты столько раз, сколько потребуется) поместить одну и ту же организации в идентичные исходные условия, поменять в организации какие-то управленческие решения и сравнить полученные результаты (прокрутить один и тот же год работы организации с одинаковыми условиями, только с разными управленческими решениями, увы, НЕ ВОЗМОЖНО, поэтому и менеджмент - не наука)))) и с этим трудно поспорить!)
Вторую ссылку не осилил (слишком много букв и много воды, чтобы найти зерно), поэтому не понял что Вы ею хотели сказать (какую мысль донести). Если это важно - сформулируйте ее не заставляя меня читать такие большие тексты? Про ТРИЗ - это восторг и восхищение гениальностью автора! Сильнейший инструмент - библия для конструкторов!!!! За рубежом во многих инженерных центрах - это обязательная область знаний, без которой с тобой даже разговора не начнут при приеме на работу!!! Там это признанная КЛАССИКА, у нас же в стране - это, увы, забытая мелодия для флейты(((
Спасибо за пример!
Неожиданно для меня, то, какие вопросы Вы мне задавали, то, какой пример привели, на что акцентировали внимание (я все это сам никогда не смог бы предположить) дали мне так много пищи для ума, что у меня сложились все пазлы, и я для себя сформировал логичное объяснение специфики и различий наших подходов и т.з.! Естественно, все «с моей колокольни», т.е. не факт, что Вы мои объяснения одобрите?)))
Важные различия, которые я для себя отметил (дополните/поправите меня при необходимости):
1. Мой пример – процессная модель для организации в целом, Ваш – про производство только. Т.е., Вы сочли приемлемым, в качестве примера привести «кусочек», а в моей парадигме «процессный подход» не имеет смысла, если он не охватывает организацию в целом. Все по Фрейду)) мне бы и в голову не пришло показать «фрагмент» (для меня это категорическое искажение смыла), а для Вас – это приемлемо (потому что все равно, что показывать, т.к. смысл, с Вашей т.з можно увидеть и в «фрагменте»).
2. С Вашей т.з. (я так понял) чем детальней описание (больше процессов), тем лучше. А у меня совершенно другая установка: как подобрать минимальное количество процессов, которого будет достаточно для эффективного управления предприятием (у меня точно нет критерия «чем больше, тем лучше», для меня это ненужное усложнение задачи управления предприятием).
3. В моем представлении нотация описания процесса чрезвычайно нагруженная (для описания требуется огромное количество связей (напомню, граф СЕТЬ, связи каждый процесс с каждым), полей, логик, метрик, предполагается сложное внутреннее содержание процесса, допускается большое количество участников процесса с разными ролями, и много другое, все есть в ИСО 9001), а у Вас, по сравнению с моим представлением, описание процесса предполагается минималистическое и участник(и) с одинаковой ролью. Я бы эту разницу оценил минимум раз в 100 (а может и в 1000). И тогда понятно, почему, я дорожу количеством процессов (это очень дорого управлять процессом, нужно совершать очень много действий, обрабатывать большое количество данных, согласовывать работу сети процессов при обнаружении важных отклонений/изменений в любом из них, …), а Вам увеличить количество процессов - легче легкого!
4. У меня небольшое (по сравнению с Вашей моделью) количество процессов, потому что моя процессная модель подразумевает связи каждый с каждым (для обеспечения гибкого и быстрого согласования работы всех процессов предприятия при обнаружении потребности изменения), и любое добавление нового процесса в модель кратно увеличивает количество связей и сложность согласования (поэтому нет цели «чем больше, тем лучше» в т.ч.). Ваша же модель строится на линейной последовательности процессов, в которой требовать связи каждый с каждым – глупость (я теперь понял Вас и Вашу реакцию на СЕТЬ и связи каждый с каждым))))
5. Требование наличия владельца процесса в вашей модели, как мне кажется, излишняя надуманная избыточная опция, особенно, учитывая такое огромное количество процессов и желание увеличивать их количество для точной детализации соответствия. В моей модели без владельца процесса НЕЛЬЗЯ, и их в организации не много (по небольшому количеству процессов), и их роль (нагрузка, ответственность и полномочия, управление регламентами, ресурсами, участниками процесса, распределение работ, управление отклонениями/изменениями и т.п.) чрезвычайно значима (поэтому и так много рождено текстов в инете, что без них нельзя, но для какой модели?).
6. Границы процесса – у меня по сравнению с вашей моделью, просто огромные. Ваши процессы с примера целиком влезли бы в один процесс в моей модели с названием производство (ну или в 2-3). Поэтому я и ответил, что не вижу проблем с «отпроситься» - это рутинная обязанность владельца процесса, и сотрудников, которые участвуют сразу во многих процессах в моей модели нет (ну может быть в 2-3 смежных), и для меня это не является сколь-нибудь важной проблемой! Поэтому для меня выглядело диким предположение о том, что практически все сотрудники организации участвуют в огромном (от 20 и больше процессах), что для Вас это важный аспект и что это критерий работоспособности процессной модели (для меня вообще не существенно).
Теперь, собственно, мои выводы и анализ причин (все с моей колокольни и делаю оценки более категоричными, чем на самом деле есть, чтобы подчеркнуть мою мысль/идею)
1. Ваша модель родом из задачи «автоматизировать» деятельность предприятия (создать двойник в компьютере). Для этого в 60е годы с появлением первых компьютеров была придумана соответствующая технология и нотации. На самом деле эта модель и нотации описывают элементарные ОПЕРАЦИИ и их последовательность (чем подробнее, тем лучше). Это почему то назвали процессами и процессным подходом. Правильней/ближе сейчас это называть созданием цифровых двойников, наверное. При таком описании, никакой разницы для технологии переноса операций нет функционально-иерархическая модель управления у предприятия, процессная ли, функциями ли называются переносимые действия или операциями. Поэтому я теперь понимаю, почему для вас это все одно и то же, и почему BPM CBOK такой (он весь про перенос операций, там ничего нет про управление из стандартов ИСО серии 9000, понятно теперь и почему эти стандарты про управление IT шникам как 5 колесо в телеге, для решения задачи автоматизации они не нужны)
2. Моя модель (ИСО серии 9000) родом из 2000 года, когда прикладники, замученные неприемлемой эффективностью предприятий, пришли к консенсусу, что коренная причина проблем - господствующий функционально-иерархический подход к управлению, который в условиях роста номенклатуры, непредсказуемой изменчивости спроса и т.п превратился в генератор проблем. Прикладники провозгласили, что выход из кризиса не эффективности – совершение революции в области управления - переход на процессный подход. Цели этой революции – повысить эффективность работы предприятий. Цель автоматизация, или перенос операций в компьютер НЕ СТАВИЛАСЬ и НЕ РАССМАТРИВАЛАСЬ от слова СОВСЕМ! Рассматривалась ИСКЛЮЧИТЕЛЬНО задача создания быстро и эффективно реагирующей системы управления (все действия сотрудников организации согласованы и все в любой момент времени в организации делают только то, что нужно, и не делают что не нужно). Поэтому и другая процессная модель (другая цель - другое решение). Поэтому в стандартах ИСО серии 9000 нет ничего из BPM CBOOK.
3. Большая причина проблемы - терминологическая и те и те используют термины процесс и процессный подход с абсолютно разной смысловой нагрузкой для совершенно разных целей. Если в задаче автоматизации и использования для решения этой задачи нотаций вместо терминов Процесс и Процессный подход, использовались термины ОПЕРАЦИЯ и КАРТА ОПЕРАЦИЙ, а процессы и процессный подход как термины оставили стандартам ИСО серии 9000 с их управленческой нагрузкой, было бы проще всем. Так что Шеер мог бы быть поаккуратней)))
У меня все сошлось! Еще раз, Спасибо Вам за помощь – Вы мне сильно посодействовали в осмыслении!
Поделитесь своими мыслями?
Прежде чем отвечу, не могу не поделиться ощущением о формате и содержании нашего общения: мы общаемся как представителей разных миров/планет! Т.е. диспозиция такая))) Вы, в своем мире, находитесь в полной гармонии со своими знаниями, тут появляюсь я "чудик из другого мира" с непонятными т.з., которые могут нарушить Вашу гармонию, и Вы из вежливости лениво поддерживаете беседу с целью тихонечко меня выпроводить восвояси))) По содержанию: мне Ваши вопросы/оценки кажутся неожиданными/странными, а вопросы, которые должны были бы задать - не задаете!? Вы, видимо, аналогично воспринимаете мои ответы и т.з. По формату: Я пишу большие тексты, стараюсь аргументированно и структурированно описать свою т.з., ожидая ее обсуждения. Вы - системно уклоняетесь от оценок и обсуждения (понятно/не понятно) моих описаний, вместо этого задаете, как мне кажется, вопросы, чтобы "срезать" и не погружаться в изучение/обсуждение моей т.з. как заведомо неприемлемой! В общем непримиримая война миров какая то...
Теперь, собственно, ответ:
Мне очень сложно представить ситуацию:
Вот базовая процессная модель предприятия о которой говорю я. В ней всего около 20 процессов. Возможны варианты, когда каждый из указанных процессов необходимо детализировать (разбить на 1-3 подпроцесса) или когда некоторые процессы будут объединены. Попробуйте на этом перечне процессов привести пример сотрудника, который участвует в 20 (получается во всех) процессах? Очевидно что Вы не эти процессы и не эту процессную модель имели ввиду? Какова Ваша процессная модель (приведите пример)? В чем наше не совпадение, мы сможем выяснить?
Нет. У меня договор о конфиденциальности, извините, но я не имею права давать информации больше, чем поделился.
Мой исходный комментарий не про проблему конкретного решения вендора (не про то, что оно слабое и т.п.), а про то, что размерность задачи имеет критическое значение, какой бы вендор не пытался ее решить. Там основные проблемы связаны не столько с дефицитом производительности (он преодолевается, производительность систем растет и это вопрос времени решения этой проблемы). Основная проблема была в том, что завод физически не успевал актуализировать многочисленные справочники (так много и так быстро происходили изменения)
Процедуры аналогичные:
Хочешь уйти, но ты сейчас должен работать в 20 процессах - нужно согласовать свой уход для 20 процессов, иначе как они будут работать, если ты неожиданно уйдешь не предупредив!?
В каждом процессе у него своя загрузка, свои критерии оценки
При разработке процессов, которые предусматривают участие одного человека в 20 процессах должен быть рассмотрен вопрос его допустимой (бесконфликтной для работы этих 20 процессов) загрузки. Если этого нельзя обеспечить, то такое использование человека (такие процессы) не должны быть согласованы (зачем планировать такой вариант выполнения работ, который гарантированно не будет исполнен)!? Если же процессы одобрены, т.е. конфликтов не обнаружено, то у человека будет должностная инструкция Как он работает в таком-то процессе, как в другом... Если конфликт загрузки произойдет - будет рассматриваться вопрос решения проблемы (пересмотр процессов или загрузки человека)
Если один и тот же человек планируется к работе в 20 процессах одновременно, то на момент разработки плана работы этих процессов "проблема" всплывет и будет решаться и разрабатываться н допустимый план этих процессов
Смыслы, логики и решения аналогичные. А как по другому то?!
Корпоративная информационная система управления заводом (решение класса ERP с функциональностью подетального пооперационного планирования), отечественный разработчик
Прикладная задача звучит так: как предприятие, управляемое здесь и сейчас по функционально-иерархической модели (в ней обязательно есть оргструктура, как базовый элемент этой системы управления), перевести на процессное управление (в которой нет оргструктуры как необходимого элемента системы). Люди остаются, но описание их взаимодействия теперь будет определятся не оргструктурой (получаю задания только от своего начальника и работаю по регламенту), а их полномочиями и задачами в рамках взаимодействия с другими процессами (процессы сами для себя осуществляют весь цикл управления PDCA согласуют планы, осуществляют мониторинг на прямую, не через начальника)
В самой первой версии от 2000 года в стандарте iso 9000 "Основные положения и словарь" был такой раздел с описанием этапов перехода на новую систему управления (в последующих версиях его исключили):
А в стандарте ISO 9001 "Требования..." предъявлялись детальные требования к тому, что должно быть определено для выделенных процессов, что обязательно должно быть получено в результате их работы и т.п.
Этапы перехода: Создание проекта процессной модели, Формирование проектов описаний процессов и управления ими (как будет на основании взаимодействия с другими процессами формироваться план работы процесса, ...), Согласование процессов в рамках процессной модели (утверждение регламентов, должностных инструкций, полномочий,..) , Апробирование/Тестирование, Переход на созданную модель управления (упразднение старой функциональной иерархии Дерево, переход на управление предприятием Сеть, где объектами управления являются процессы с Владельцами процессов))
Возможно не в тему, но выскажусь!
Задам еще один вектор "на подумать" в задаче определения и области применения цифровых двойников для промпредприятий. Для этого сначала будет кейс, потом вывод с выходом на постановку задачи для DT
Кейс
Вывод и выход на постановку задачи для DT
Напрашивающийся вывод попытка "в лоб" (один в один) создавать цифровые двойники предприятия, начиная с определенной размерности задачи - это ОГРОМНЫЕ затраты, которые с высокой долей вероятности не окупятся в виду огромной изменчивости и необходимости скрещивания в единую аналитическую систему данных с DT и не c DT (управлением и агрегацией которых большая проблема).
Выход на постановку задачи для полезного/эффективного применения DT:
Нужен подход к снижению размерности задачи "какое минимальное количество характеристик с какого минимального количества объектов с какой максимально возможной периодичностью съема данных нужно собирать с помощью DT, чтобы собранная система позволяла организовать эффективное управление прикладным объектом (системой объектов)". Без такого решения будет гарантирован результат "Из пушки по воробьям"!
В связи с этим, обсуждение задачи DT ради DT как сферического коня в вакууме (как техническую IT задачу только), без привязки к прикладным объектам управления (особенно в случае сложной системы объектов, типа предприятие) и без решения специфической задачи размерности DT для этой сложной системы объектов - не более, чем интересное занятие с туманными перспективами. Т.е. DT - это не столько техническая или IT-задача, сколько прикладная, и постановку задачи DT нужно делать в жесткой связке с решаемой прикладной задачей и системой объектов. Например: DT для управлением надежностью оборудования - это такая то модель применения DT. DT для управления качеством операций - другая модель применения DT, хотите построить минимально работающий DT предприятия - это такой то набор объектов DT с такой то схемой агрегации данных для решения таких-то задач управления и т.п.
Я повторю свою т.з. про то, что представление о процессном подходе, основанное на BP CBOOK и ARIS (библия IT мира) и в изложении международных стандартов ИСО серии 9000 (библия прикладного мира) - это две большие разницы!!! (здесь на ХАБРе я эту мысль уже озвучивал).
Вероятно по этой причине существенно отличаются наши представления о "процессном подходе" и этим и объясняются связанные с этим споры и оценки?
Мой анализ ситуации (как субъективная т.з. эксперта от Прикладного мира) в качестве ремарки про "библию ARIS от Шеера":
Следует учесть факт того, что ARIS появился в 1994 году (как развитие методологии автоматизации деятельности предприятий разработанной в 60х годах) , а Прикладной мир сформировал свою т.з. на процессный подход в 2000 году. Т.е. на момент разработки своей библии про процессный подход Прикладной мир знал что есть ARIS, но НИЧЕГО из этой системы знаний в свою библию по факту не взял. Возникает законное любопытство (А) ПОЧЕМУ международная группа разработчиков этих стандартов проигнорила ARIS вместе со всеми его нотациями BPMN и IDEFx!? (Б) Зачем и что напридумывали СВОЕГО Прикладники, игнорируя все наработки ARIS? (B) Почему BPM CBOK вышедший на свет в 2003 году (т.е. на момент разработки уже хорошо было известно, что понимает и какой процессный подход хочет иметь у себя Прикладной мир) имел шанс гармонизироваться с ISO серии 9000, но ответил взаимностью, и НИЧЕГОШЕНЬКИ из библии Прикладного мира по факту не взял? (Г) Почему за 25 лет не посчитали нужным гармонизироваться друг с другом две параллельно существующие области знаний про процессный подход (тем более что по определению IT отрасль должна обслуживать и работать на Прикладной мир, т.е. должны были, как минимум, внимательно изучать друг друга, а вместо этого обе стороны ВЗАИМНО и упорно игнорят друг-друга)?
На момент разработки ARIS (1994 год) господствовал функционально-иерархический подход к управлению. Поэтому сущность и описание процессов и процессного подхода Шеером определяется через терминологию функций (ИМХО, именно поэтому для Вас это одно и тоже и Вы правильно при этом ссылаетесь на первоисточник такого восприятия). Т.е. де факто ARIS являлся разработкой IT отрасли в решении задачи "Как перенести в компьютер с помощью процессных нотаций BPMN и IDEFх функционально-иерархическую модель управления, которая работала на 100% предприятий Прикладного мира" на тот момент времени
В 2000 году Прикладной мир объявил о потребности коренного преобразования систем управления (переходе с функционально-иерархического подхода к управлению предприятием, на процессный подход к управлению предприятием, как более эффективной альтернативы) и выпустил для этого свою библию ISO серии 9000. Обращу Ваше внимание, что термин функция ДЛЯ ОПИСАНИЯ И ОПРЕДЕЛЕНИЯ процессного подхода к управлению предприятием НЕ ИСПОЛЬЗУЕТСЯ! Разработчики ISO серии 9000 логично посчитали, что раз нужно заменить функционально-иерархичный подход на процессный (уйти от функций к процессам), то будет методически неправильным определять новую управленческую конструкцию процессного подхода с помощью старых элементов функций! По той же причине (повторюсь) Вы не найдете в этих стандартах и упоминаний про оргструктуру, т.к. в новой управленческой парадигме "процессный подход" она не нужна (она необходима была исключительно в старой модели).
Про восприятие ISO серии 9000 - я с этим неправильным и снобистким восприятием IT отрасли смысла и назначения этих стандартов сталкиваюсь постоянно! Все мои оценки, что озвучиваемое восприятие КАТЕГОРИЧЕСКИ не верное, попытки и призывы пересмотреть свое отношение и изучить эти стандарты наталкиваются на категорическое отторжение (поэтому я и применил термин СНОБИСТСКОЕ отношение). Такое отношение и реакция на ИСО серии 9000 - удивительно устойчивое и воспроизводимое, с каким бы представителем от IT отрасли я не общался!?
Моя версия причин такого СНОБИСТКОГО отношения к библии (смыслу и инструментарию процессного подхода) Прикладного мира:
(А) циничная и рациональная бизнес-позиция IT отрасли "А Зачем нам что-то переделывать/переучиваться/вкладываться в разработку чего то нового, если и так все хорошо продается!". Результаты в виде "Автоматизации ХАОСА" IT отрасль не очень беспокоят, т.к. по сложившемуся стандарту взаимоотношений, ответственность за это несет ИСКЛЮЧИТЕЛЬНО ЗАКАЗЧИК (очень удобно устроились - завидую, как консультант, черной завистью) и
(Б) а так исторически сложилось, что IT отрасль с момента рождения всегда сама была поставщиком задачи и у Прикладников ничего не брала/не училась (они не могли выступить в роли Постановщиков задачи) . Для того времени 60-90ее годы по другому, наверное, и нельзя было, т.е. это было правильное поведение. Но начиная с середины 90х годов Прикладной мир консолидировался и существенно рванул вперед, а IT отрасль, по привычке, этого не заметила и проигнорировала, т.к. привыкла к роли самодостаточного постановщика задач, от которой отказываться не хотела/не могла!
А у вас ботинки какого цвета? Это я намекаю на Вашу способность вести связанный диалог, Вы вместо того, чтобы продолжить/развить обсуждение, все время меняете тему; Вы что-то спрашиваете, я отвечаю, вместо того чтобы ответить взаимностью и продолжить обсуждение по заданной Вами же ветке, Вы ее бросаете, и генерите новый вопрос? Мне так беседу вести совсем не интересно!!!
ВВВЦМ, РегионПром, Модуль-Т,... - Вам стало легче?
У нас с Вами несовпадение в оценках и, согласен, в этом надо разобраться!
Изложу свои несовпадения и сомнения:
1. Вы говорите, что нет разницы и все одно и то же (что функции, что процессы). Но моя практика и мои наблюдения говорят об обратном. На какое бы предприятие я не попал, вижу одни и те же проблемы–следствия функциональной иерархии, как модели управления:
· Производство говорит, что им портит жизнь служба продаж, заключают такие контракты по объемам и срокам, что никакой эффективности производства нет и в помине, исполнить контрактные обязательства, которые обещала клиентам служба продаж не возможно!
· Закупки загнали в запасы огромные средства, гораздо больше нормативов, и при этом нужные комплекты материалов выдать в производство не могут;
· Снабженцы закупают такие инструменты, метизы, и т.п. которые не обладают требуемыми свойствами от слова совсем, их срок службы минимален, стойкость, надежность – неудовлетворительные;
· Конструкторы множат такую большую номенклатуру изделий, пренебрегая унификацией, что производство и снабжение вешаются, а договорится об унификации – это пройти 7 кругов ада;
· Технологи разрабатывают такие техпроцессы с такими нормативами, которые с реальными возможностями производства не совпадают (причем в обе стороны);
· Плановая служба генерит неисполнимые планы, предполагая у производства такие мощности и возможности, которых в производстве никогда и не было;
· Производственные цеха получают премии за выполненные объемы производства, а предприятие не может из готовых деталей набрать нужные комплекты для сборки заказанных продуктов;
· Один цех обрабатывает сейчас те детали, которые в ближайшее время никому не нужны, а нужные и не думает брать в работу;
· И многое, многое другое…
О какой согласованности действий и планов, присущей процессному прямому взаимодействию, Вы говорите!? Только хаос, разбалансированность и несогласованность присущие функциональному подходу!? Какие такие сквозные процессы!?
2. Вы простите меня, но я за свою долгую практику работы с предприятиями (можете посмотреть мое резюме в моем аккаунте) ни разу не слышал, чтобы использовали термин «сквозные процессы»!? Может это не рабочий термин предприятий!? Может это навязанная им сущность (IT шниками), которая им не нужна, не используется?
3. Извините, понудю еще немного: что это за приставка «сквозной» к процессам? Масло масленное!? Процессный подход по определению и нужен для того, чтобы любой процесс через прямые связи мог выйти на любой уровень (прежде всего на Потребителя и его требования). Т.е. любой процесс по определению участник «сквозных» процессов (ибо доступны связи каждый с каждым).
4. Еще нудю, должен уточнить – Вы свои оценки «одно и то же» на основе каких артефактов сделали? На бумаге можно предположить что угодно (все одно и тоже), на практике же все совсем не так, как в теории. Поэтому у меня и вопрос про Вашу практику и специфику (моя специализация и наблюдения – промышленные предприятия и холдинги). Может разница в оценках связана с отраслевыми отличиями?
Надеюсь, мои мысли Вас не обидели и мы конструктивно пообщаемся?
Не совсем так. Мир знаний и представлений об управлении радикально изменился с 2000 года (по историческим меркам - вчера). До этого времени почти 300 лет господствовали знания и представления об управлении предприятиями на основе функциональной иерархии, которые успешно работали в практически стационарной среде "Спрос больше Предложения) (аналогия для управления движением тел достаточно было знаний "Классической механики"). Но как только технический прогресс и массовое промышленное строительство развернули среду на 180 градусов (Предложение стало больше Спроса), это радикально изменило поведение игроков на рынке, требования к результатам, в этих радикально других условиях (среда стала турбулентной, не предсказуемой и очень изменчивой, бал стали править не предприятия а Потребители) оказалось, что старые подходы к управлению основанные на управлении предприятиями как функциональной иерархией перестали эффективно работать (оказались крайне не эффективными). Человечество вынуждено была искать более сложное альтернативное решение по эффективной работе в новых условиях. И процессный подход к управлению предприятием - это и есть этот ответ (придумали "Теорию относительности" раз "классическая механика" перестала работать). Поэтому природа нашего взаимонепонимания, не из-за того что я ленюсь и не разбираюсь в определениях и принципах "Классической механики", а из-за того что я говорю на языке "Теории относительности" (а там другие сущности, иная логика, более сложная система знаний и решений), а Вы на языке "Классической механики". Здесь понятна методическая сложность: невозможно на аксиоматике и определениях "Классической механики" объяснить "Теорию относительности". При этом Вы как эксперт в области "Классической механике" убежденно верите в то, что она работает везде и ничего другого не надо выдумывать. И идет переходный процесс смены управленческой парадигмы... Я как то так вижу причины проблем взаимонепонимания в нашей дискуссии...
Короткий ответ: по разному будет исполняться цикл управления PDCA: разная длина, разные маршруты и разная информация будут циркулировать по системе управления Дерево и по системе управления Сеть. До тех пор, пока внешняя среда стационарна, эта разница не существенна, как только мы представим, что все клиенты требуют специфические скрепки (разные материалы, свойства, размеры, форма, объемы, сроки, надо проверять готовы ли, сможем, когда, все согласовать, сообщить клиентам корректные сроки/стоимости и т.п.), то разница в маршрутах и скорости/качества реакции отделов 1.Продажи (и его подразделения службы продаж), 2.Планирование производства (цеха и диспетчерские подразделения цехов), 3.Закупки (и подразделения по закупке), 4.Производство (цеха операции), 5. Поставка (подразделения по организации поставки) если они представлены как Функциональная иерархия (информация движется только по вертикалям) и если управление этой деятельностью возможно напрямую (управляется как процессы), то разница будет существенной.
Мы опять зациклились - у меня, извините, дежавю от не знаю какого уже круга топтания на одних и тех же вопросах-ответах!
Ну вот, теперь мы договорились до того, что отрицаем наличие функционального и процессного подходов к управлению!? Более, того, Вы утверждаете что даже терминов таких нет!? Вы действительно утверждаете, что нет и не может быть никаких различных подходов к управлению!? Ок))) Мне Ваша позиция предельно понятна, я с ней категорически не согласен, но новых объяснений/аргументов к уже мною сделанным давать не вижу смысла. Вы считаете так, я считаю по другому!
Это утверждение сделал Я в отношении Вашей позиции к стандартам ИСО серии 9000, не приписывайте это утверждение себе (Вы его не можете сделать, потому что в Вашем мире нет никаких функциональных или процессных подходов к управлению (к построению эффективных систем менеджмента предприятий)! Иного утверждения после моих многократных пояснений о концепции TQM, о назначении и области применения международных стандартов ИСО серии 9000, я сделать не могу - Вы мне не оставили пространства для иной оценки! Ну не хотите Вы видеть в в этих стандартах претензий на целостное гармонизированное управление предприятиями, хотите видеть узкофункциональный стандарт по управлению исключительно аспектами качества: как этот факт можно по другому откомментировать то!? На что тут обижаться?!
Честное слово, я нахожусь в растерянности от нашей дискуссии и искренне не понимаю, как нам ее мирно и культурно завершить!?
Давайте попробуем так:
Вам моя позиция и ее аргументация (вне зависимости от того согласны Вы с ней или нет) понятны? Если Вы видите дефекты в представленной мною пояснениях (что делает мою позицию не логичной конструкцией вообще) - укажите на них, я попытаюсь ответить/исправиться? Это не значит, что Вы с моей т.з. будете согласны, это только будет означать, что моя неправильная с Вашей т.з. позиция Вами понята правильно, как я и хотел ее донести, и была Вами отвергнута?
Итак нужно ли для Вас что-то пояснить, что не понятно по моей позиции?