Системы управления, как и любой инструмент, эффективны только при использовании для решения соответствующих задач. Можно сделать бирюзовое рекламное агентство, да что там говорить, даже Valve можно сделать бирюзовым, но Братский металлургический завод нельзя.
И дело не в дремучести персонала или отсталости технологий, требование к точности исполнения технологических цепочек и квалификации людей принимающих решение таково, что консенсусом в каждой новой итерации их не обеспечить.
Все пространство реально существующих задач, стоящих перед системами управления таково, что до сих пор есть место эффективному использованию и научной организации труда начала века и сверхсовременной Holacracy.
Квалификация ответственного за построение системы, должна позволять применять наиболее эффективные методики и принципы из множества подходов в наиболее подходящих для этого местах, в соответствии с уровнем развития изменяемой системы управления.
Функция действительно важная и отдавать ее на чистый аутсорс нельзя. Обычно консалтинг привлекают для построения этой функции и проведение первой итерации. Дальнейшее изменение отдают уже созданной внутри организации компетенции.
Что касается того, что этим должен заниматься директор, не соглашусь. Он должен это контролировать и принимать участие, на верхнем уровне проектировать необходимые функции. Но начиная со среднего бизнеса, погружаться до уровня операционных процессов точно не должен. Все же генеральный директор это стратег, а не тактик.
Если говорить про CEO — в методологии BPM (business process management) выделяют такую роль как "Владелец процесса" — это человек обладающий полномочиями на изменение процесса и отвечающий за его результат. При этом для обеспечения полномочий "Владелец" управляет процессами только в рамкам своей бизнес-функции (продажи, производство, юридическая поддержка, финансы и т.д.).
В итоге в сквозном процессе (от заявки до доставки) присутствует несколько владельцев. А таких сквозных процессов в компании далеко не один. Соответственно, начиная со среднего бизнеса появляется потребность в человеке, который обладает информацией о всей системе и обладает квалификацией ее менять. Владельцы выступают как стейкхолдеры процесса изменения, согласуют процессы и дают ресурсы на их изменение.
А это уже отдельная тема про управление изменениями и цикл PDCA (PDSA), который еще в лохматые 40-е был впервые описан как раз для изменения процессов.
Я не уверен, что концепцию критической цепи можно перенести из проектов в процессы. Все таки основная цель этой методики "убивать" излишки времени, перезакладываемые в планировании и делать только те задачи, которые критичны для проекта.В процессах, мы должны сделать все, но то что, что не является ограничением, можно делать не эффективно.
Идея фиксации ограничения в одном месте описана в книге "Новая цель. Как объединить бережливое производство, шесть сигм и теорию ограничений", которая как видно из названия, делает попытку примерить непрерывное совершенствование lean и 6сигма c TOC.
Но вообще тема буквального применения теорий эффективности на практике, очень обширна. Боюсь, формат комментариев на хабре для нее узковат.
Если говорить про теорию ограничей Голдрата, то «критическая цепь» — это последовательность задач, критичных для выполнения проекта. В управлении процессами уместно говорить все же про ограничения.
Наличие ограничения можно использовать для приоретизации изменений и оглядыватся на него при их внедрении, но нельзя совсем забывать про все остальное. При отличном процессе продаж, который идеально использует ограничение в виде объема склада и забытом процессе HR, однажды будет некому продавать. Ценность изменения вспомогательных процессов в уменьшении риска для основного. Это как про системного администратора, если он работает хорошо, то никто этого не видит, но стоит ему накосячить…
ЦОД — это ЦОД. Помещение внутри дата-центра, где находятся сами вычислительные мощности (сервера, реже — мини-кроссовая) — это машинный зал. То есть сокращённо машзал. Это принятая терминология. Машзал — это ЦОД минус почти вся инфраструктура.
Системы управления, как и любой инструмент, эффективны только при использовании для решения соответствующих задач. Можно сделать бирюзовое рекламное агентство, да что там говорить, даже Valve можно сделать бирюзовым, но Братский металлургический завод нельзя.
И дело не в дремучести персонала или отсталости технологий, требование к точности исполнения технологических цепочек и квалификации людей принимающих решение таково, что консенсусом в каждой новой итерации их не обеспечить.
Все пространство реально существующих задач, стоящих перед системами управления таково, что до сих пор есть место эффективному использованию и научной организации труда начала века и сверхсовременной Holacracy.
Квалификация ответственного за построение системы, должна позволять применять наиболее эффективные методики и принципы из множества подходов в наиболее подходящих для этого местах, в соответствии с уровнем развития изменяемой системы управления.
Очень точное описание роли, ее задач и инструментария, спасибо.
Функция действительно важная и отдавать ее на чистый аутсорс нельзя. Обычно консалтинг привлекают для построения этой функции и проведение первой итерации. Дальнейшее изменение отдают уже созданной внутри организации компетенции.
Что касается того, что этим должен заниматься директор, не соглашусь. Он должен это контролировать и принимать участие, на верхнем уровне проектировать необходимые функции. Но начиная со среднего бизнеса, погружаться до уровня операционных процессов точно не должен. Все же генеральный директор это стратег, а не тактик.
Если говорить про CEO — в методологии BPM (business process management) выделяют такую роль как "Владелец процесса" — это человек обладающий полномочиями на изменение процесса и отвечающий за его результат. При этом для обеспечения полномочий "Владелец" управляет процессами только в рамкам своей бизнес-функции (продажи, производство, юридическая поддержка, финансы и т.д.).
В итоге в сквозном процессе (от заявки до доставки) присутствует несколько владельцев. А таких сквозных процессов в компании далеко не один. Соответственно, начиная со среднего бизнеса появляется потребность в человеке, который обладает информацией о всей системе и обладает квалификацией ее менять. Владельцы выступают как стейкхолдеры процесса изменения, согласуют процессы и дают ресурсы на их изменение.
А это уже отдельная тема про управление изменениями и цикл PDCA (PDSA), который еще в лохматые 40-е был впервые описан как раз для изменения процессов.
Я не уверен, что концепцию критической цепи можно перенести из проектов в процессы. Все таки основная цель этой методики "убивать" излишки времени, перезакладываемые в планировании и делать только те задачи, которые критичны для проекта.В процессах, мы должны сделать все, но то что, что не является ограничением, можно делать не эффективно.
Идея фиксации ограничения в одном месте описана в книге "Новая цель. Как объединить бережливое производство, шесть сигм и теорию ограничений", которая как видно из названия, делает попытку примерить непрерывное совершенствование lean и 6сигма c TOC.
Но вообще тема буквального применения теорий эффективности на практике, очень обширна. Боюсь, формат комментариев на хабре для нее узковат.
Если говорить про теорию ограничей Голдрата, то «критическая цепь» — это последовательность задач, критичных для выполнения проекта. В управлении процессами уместно говорить все же про ограничения.
Наличие ограничения можно использовать для приоретизации изменений и оглядыватся на него при их внедрении, но нельзя совсем забывать про все остальное. При отличном процессе продаж, который идеально использует ограничение в виде объема склада и забытом процессе HR, однажды будет некому продавать. Ценность изменения вспомогательных процессов в уменьшении риска для основного. Это как про системного администратора, если он работает хорошо, то никто этого не видит, но стоит ему накосячить…