Вот смотрю и как у специалиста по организации куча вопросов: 1. Что анализируем? Че сами произвольно придумали, то и анализируем. Анализировать надо фактические учетные данные, а не произвольные цифры, полученные вследствие произвольного нормирования. Сами с потолка наковыряли нормативы и их же анализируем. Нормативные данные нужны не для того, чтоб их анализировать, а для того, чтоб с их помощью анализировать фактические. 2. Простои. Искаверкали традиционное понятие. Назвали простоем все, что не создает ценности. По сути это не простои а вспомогательные операции. И если без них процесс не осуществить, то выделять их и ковыряться в них смысла нет никакого. Иногда даже операции создающие ценность поддаются большей оптимизации, чем вспомогательные. Тогда зачем это разделение вообще. И их соотношение об эффективности вам ничего не скажет. Эффективность определяется воспроизводимостью, производительностью и ресурсами процесса, а не соотношением основных и вспомогательных операций. Простои, в свою очередь это простои ресурса и если он был занят другой задачей, то простоя никакого в принципе нет. К тому же простои это время не плановое (не регламентируемое), или же сверхнормативное, которые определить вы можете из фактических данных, в сравнении с нормативными, а не коим образом не на базе одних только нормативов. Есть еще куча вопросов. Вывод: Популярные BPM методки это методики о нарисовании инструкций. О том как этими процессами управлять эти методики ничего вразумительного сказать не могут. Как поставить научно проработанную систему управления они ничего не расскажут так как не затрагивают нормально вопросы учета, нормирования и анализа. Процессное управление вещь нужная, но существующие методики затрагивают лишь процентов 10 того, что надо сделать для полноценного управления. А то что в кучу сваливают понятие комплексной функции и процесса, обесценивая этим самым процесс как объект управления, я вообще молчу. Но тем не менее концепция ПО шикарная. Это движение в правильном направлении. Но ей нужны интеграция учетных данных, научно обоснованное нормирование и нормальный начный анализ данных на базе SPC . Тогда функционально стоимостной анализ заработает как надо. Также понравилась организационная дефрагментация. В этом есть зерно логическое. Для проектирования процесса должно быть полезно. Ну а причинно следственный анализ проблем это не совсем BPM. Инструмент без сомнения рабочий.
@@user-757vrn сражу вас огорчу. Все это лоскуты организационной науки. А организационная наука почему то на данный момент не только не обобщена. Она даже не выделена в отдельную науку. Поэтому человек ищущий может собрать воедино только сам, связывая между собой различные методы и отбрасывая явную ересь через обобщение. Что касается процессов. Тут я бы вам порекомендовал разобраться в некоторых вопросах: 1. Чем функциональный подход противоречит процессному. Без понимания этой проблематики сложно начать копать в правильном направлении. 2. Чем отличается проектирование процесса от управления процессом. Большинство людей думает, что если ты нарисовал схему, то по щучьему велению, она должна ожить почему то. Ответ на вопрос, как заставить ожить процесс лежит в понимании контрольной карты Шухарта и PDCA (не нравится PDCA, пусть будет управляющая отрицательная обратная связь по кибернетике. Это одно и то же). Контрольная карта Шухарта даст понимание зачем вам нужен процесс, как объект управления. SPC это управление. BPM это проектирование, причем очень слабое на самом деле. 3. BPM это логическая схема процесса и содержит в себе только условную логику. Нормальная же модель процесса должна: А. Содержать временные параметры. Например циклограмма Б. Содержать информацию о загруженности функционального ресурса. Например диаграмма ямадзуми или ее аналоги. В. Должна быть адаптивной моделью принимающей статистические данные для перенормирования собственных параметров, а не мертвым скелетом. 4. В итоге обобщите знания об управлении потоком: канбан и DBR, о контрольной карте Шухарта, об отличии программного управления (BPM) от управления с обратной связью (PDCA) и от управления с обратной связью и стохастическими компенсаторами (PDCA + SPC) (в терминах кибернетики) и тогда вы будете понимать о структурировании процессов все. Ну и также надо разделять проектирование внутренней части процесса от внешнего управления процессом как целостным объектом. Системный стохастический подход против детерминистского дискретного. Надо еще понимать что BPM это всего лишь язык общения между специалистом и программистом например. Не более. Работать BPM начинает полноценно только на лоу код платформах, как язык общения между специалистом и компьютером. В таком случае компьютер сам добавляет туда контроль и сбор данных и увязывает модель с управляющей обратной связью по всем этапам управляющей связи: учет, анализ, нормирование, планирование и пр.
@@user-757vrn по оргструктуре. Тут вам скажу, что ковыряние в оргструктурах никакого отношения к научному менеджменту не имеет. Оргструктура это не инструмент это отражение. Пытаться что то улучшить через изменение оргструктуры не корректно. Оргструкта это вопрос пятый или десятый. Сначала необходимо выстроить систему управления потоком, отказаться от план фактного управления и управления по детерминированным целям. Затем в процессе повышения эффективности, структура сама будет приобретать вид наиболее подходящий для адаптивного управления. Могу сказать, что такая структура будет предполагать разбивку персонала не по узким функциям, а по этапам управленческого потока. Однозначно костяк такой системы будут составлять аналитики мигрирующие из одного подразделения в другое в целях внутреннего бэнчмаркинга. Узкие функции нужны будут только в виде отдельных мощных методистов, задающих критические параметры системы: главный бухгалтер, главный экономист, главный механик, главный технолог. Только это должны быть действительно мощные методисты. В такой системе точно не должно быть "однокнопочных тетушек" с высшим образованием. Либо ты аналитик данных, либо мощный методист в узкой сфере, либо оператор ПК. На операторов пк не надо набирать специалистов. Можно взять людей с улицы за 40000 руб.
@@Sergei_K. я Вам очень благодарен, за такой развёрнутый ответ, Вы пролили свет ответом больше, чем я узнал из статей в интернете) спасибо Вам большое. Пазл сложился. Буду пробовать разбираться, уж больно это интересно для меня.
@@user-757vrn если интересно больше, найдите ролик по запросу "системщик потери и менеджмент ". Ссылку не могу оставить. Ютуб удаляет. Возможно узнаете что то новое для себя. Рад был помочь.
Очень интересное содержательное видео. Благодарю за видео 👍👍👍Поделитесь пожалуйста ссылкой на программное обеспечение показанный в данном видео. Где и как скачать (купить и т.д).
Было интересно, спасибо.
Вот смотрю и как у специалиста по организации куча вопросов:
1. Что анализируем? Че сами произвольно придумали, то и анализируем. Анализировать надо фактические учетные данные, а не произвольные цифры, полученные вследствие произвольного нормирования. Сами с потолка наковыряли нормативы и их же анализируем. Нормативные данные нужны не для того, чтоб их анализировать, а для того, чтоб с их помощью анализировать фактические.
2. Простои. Искаверкали традиционное понятие. Назвали простоем все, что не создает ценности. По сути это не простои а вспомогательные операции. И если без них процесс не осуществить, то выделять их и ковыряться в них смысла нет никакого. Иногда даже операции создающие ценность поддаются большей оптимизации, чем вспомогательные. Тогда зачем это разделение вообще. И их соотношение об эффективности вам ничего не скажет. Эффективность определяется воспроизводимостью, производительностью и ресурсами процесса, а не соотношением основных и вспомогательных операций.
Простои, в свою очередь это простои ресурса и если он был занят другой задачей, то простоя никакого в принципе нет. К тому же простои это время не плановое (не регламентируемое), или же сверхнормативное, которые определить вы можете из фактических данных, в сравнении с нормативными, а не коим образом не на базе одних только нормативов.
Есть еще куча вопросов.
Вывод: Популярные BPM методки это методики о нарисовании инструкций. О том как этими процессами управлять эти методики ничего вразумительного сказать не могут. Как поставить научно проработанную систему управления они ничего не расскажут так как не затрагивают нормально вопросы учета, нормирования и анализа.
Процессное управление вещь нужная, но существующие методики затрагивают лишь процентов 10 того, что надо сделать для полноценного управления. А то что в кучу сваливают понятие комплексной функции и процесса, обесценивая этим самым процесс как объект управления, я вообще молчу.
Но тем не менее концепция ПО шикарная. Это движение в правильном направлении. Но ей нужны интеграция учетных данных, научно обоснованное нормирование и нормальный начный анализ данных на базе SPC . Тогда функционально стоимостной анализ заработает как надо. Также понравилась организационная дефрагментация. В этом есть зерно логическое. Для проектирования процесса должно быть полезно.
Ну а причинно следственный анализ проблем это не совсем BPM. Инструмент без сомнения рабочий.
Хороший кометарий. Хочу у Вас поинтересоваться, какую литературу порекомендуете по оргструктуре, построению идентификации бизнес процессов? Надеюсь на ответ.
@@user-757vrn сражу вас огорчу. Все это лоскуты организационной науки. А организационная наука почему то на данный момент не только не обобщена. Она даже не выделена в отдельную науку. Поэтому человек ищущий может собрать воедино только сам, связывая между собой различные методы и отбрасывая явную ересь через обобщение.
Что касается процессов. Тут я бы вам порекомендовал разобраться в некоторых вопросах:
1. Чем функциональный подход противоречит процессному. Без понимания этой проблематики сложно начать копать в правильном направлении.
2. Чем отличается проектирование процесса от управления процессом. Большинство людей думает, что если ты нарисовал схему, то по щучьему велению, она должна ожить почему то. Ответ на вопрос, как заставить ожить процесс лежит в понимании контрольной карты Шухарта и PDCA (не нравится PDCA, пусть будет управляющая отрицательная обратная связь по кибернетике. Это одно и то же). Контрольная карта Шухарта даст понимание зачем вам нужен процесс, как объект управления. SPC это управление. BPM это проектирование, причем очень слабое на самом деле.
3. BPM это логическая схема процесса и содержит в себе только условную логику. Нормальная же модель процесса должна:
А. Содержать временные параметры. Например циклограмма
Б. Содержать информацию о загруженности функционального ресурса. Например диаграмма ямадзуми или ее аналоги.
В. Должна быть адаптивной моделью принимающей статистические данные для перенормирования собственных параметров, а не мертвым скелетом.
4. В итоге обобщите знания об управлении потоком: канбан и DBR, о контрольной карте Шухарта, об отличии программного управления (BPM) от управления с обратной связью (PDCA) и от управления с обратной связью и стохастическими компенсаторами (PDCA + SPC) (в терминах кибернетики) и тогда вы будете понимать о структурировании процессов все. Ну и также надо разделять проектирование внутренней части процесса от внешнего управления процессом как целостным объектом. Системный стохастический подход против детерминистского дискретного.
Надо еще понимать что BPM это всего лишь язык общения между специалистом и программистом например. Не более. Работать BPM начинает полноценно только на лоу код платформах, как язык общения между специалистом и компьютером. В таком случае компьютер сам добавляет туда контроль и сбор данных и увязывает модель с управляющей обратной связью по всем этапам управляющей связи: учет, анализ, нормирование, планирование и пр.
@@user-757vrn по оргструктуре. Тут вам скажу, что ковыряние в оргструктурах никакого отношения к научному менеджменту не имеет. Оргструктура это не инструмент это отражение. Пытаться что то улучшить через изменение оргструктуры не корректно. Оргструкта это вопрос пятый или десятый. Сначала необходимо выстроить систему управления потоком, отказаться от план фактного управления и управления по детерминированным целям. Затем в процессе повышения эффективности, структура сама будет приобретать вид наиболее подходящий для адаптивного управления.
Могу сказать, что такая структура будет предполагать разбивку персонала не по узким функциям, а по этапам управленческого потока. Однозначно костяк такой системы будут составлять аналитики мигрирующие из одного подразделения в другое в целях внутреннего бэнчмаркинга. Узкие функции нужны будут только в виде отдельных мощных методистов, задающих критические параметры системы: главный бухгалтер, главный экономист, главный механик, главный технолог. Только это должны быть действительно мощные методисты. В такой системе точно не должно быть "однокнопочных тетушек" с высшим образованием. Либо ты аналитик данных, либо мощный методист в узкой сфере, либо оператор ПК. На операторов пк не надо набирать специалистов. Можно взять людей с улицы за 40000 руб.
@@Sergei_K. я Вам очень благодарен, за такой развёрнутый ответ, Вы пролили свет ответом больше, чем я узнал из статей в интернете) спасибо Вам большое. Пазл сложился. Буду пробовать разбираться, уж больно это интересно для меня.
@@user-757vrn если интересно больше, найдите ролик по запросу "системщик потери и менеджмент ". Ссылку не могу оставить. Ютуб удаляет. Возможно узнаете что то новое для себя. Рад был помочь.
Когда-то сталкивался с ARIS. Это круче и функциональнее.
Очень интересное содержательное видео. Благодарю за видео 👍👍👍Поделитесь пожалуйста ссылкой на программное обеспечение показанный в данном видео. Где и как скачать (купить и т.д).
На странице www.betec.ru/index.php?id=18&sid=109 можно отправить запрос не получение тестовой версии программного продукта "Бизнес-инженер".