Comments 23
Очень актуальная тема. Спасибо за интересный обзор
Практика показывает, что для изменения (или создания) живых бизнес-процессов должно сойтись много звезд на небе — как минимум некотрое количество образованных, и одновременно неравнодушных людей, плюс внешний фактор который заставляет искать изменений. И нет, процесс нельзя принести с улицы, вычитать в книжке — и внедрить как прокрустово ложе. То есть можно — но что-то в фирме при этом отвалится. Процессы надо вырастить. Потому что процессы и стандарты должны всеми руководителями пониматься именно как набор best-practice, к которому прилагается старое авиационное правило: «выполняй или объясняй».
А вообще, читаем Голдратта — улучшения в системе, не находящиеся на критической цепи, являются пустой тратой сил и времени. А все проекты «внедрить стандарты» — обычно размазывают по системе от начала и до конца. В результате — по Голдратту — лишь несколько процентов от приложенных усилий реально эффективны… :-(
Если говорить про теорию ограничей Голдрата, то «критическая цепь» — это последовательность задач, критичных для выполнения проекта. В управлении процессами уместно говорить все же про ограничения.
Наличие ограничения можно использовать для приоретизации изменений и оглядыватся на него при их внедрении, но нельзя совсем забывать про все остальное. При отличном процессе продаж, который идеально использует ограничение в виде объема склада и забытом процессе HR, однажды будет некому продавать. Ценность изменения вспомогательных процессов в уменьшении риска для основного. Это как про системного администратора, если он работает хорошо, то никто этого не видит, но стоит ему накосячить…
Я говорю о критической цепи не в терминах управления проектами по-Голдратту, а в более общем смысле — как о наборе элементов системы (точек материального передела в производстве, задач в управлении проектом, и т.д.) которые ограничивают поток (набор элементов — потому что может быть несколько ограниченных ресурсов, и не факт что все они сойдутся ровно в одной точке пространства-времени).
По содержательной части — мне запомнилась мысль с какого-то семинара: задача управленца не бегать и снимать ограничения в духе ранних книг Голдратта (хотя, в критичесекой ситуации и это тоже правильно!). Задача управленца — спроектировать и настройить систему (проект, производство, и т.д.) таким образом, чтобы ограничения возникали в заранее запрограммированных точках, где ими легко управлять. Например, в одном случае — выгоднее запрограммировать узкое место на производстве, и проводить селекцию входящих заявок, спуская в унитаз (wasting, прошу прощения) часть производительности маркетинга и продаж. В другом случае — рыночная ситуация может быть такой, что выгоднее недогружать производство, но гарантированно успевать обработать каждую входящую заявку. Теория Голдратта дает понимание, как настроить предприятие под любой из сценариев — но сама по себе не говорит, где «правильно» оставить ограничение (ибо, как мы понимаем, ограничения в системе будут всегда).
Кроме того, говоря о любых программах повышения эффективности (втч Голдраттовской) — нужно понимать, что с какого-то момента повышение эффективности системы достигается только ценой снижения ее устойчивости. Ибо, как говорят, в теории технических систем — «паровой котел достигает пика эффективности в последнюю микросекунду перед взрывом!» ©
Таким образом, еще одна задача управленца и бизнес-архитектора заключается в том, чтобы выбрать целевую точку на кривой «избыточность-эффективность», настроить на нее свое предприятие — и молиться, чтобы точка была выбрана правильно!..
Я не уверен, что концепцию критической цепи можно перенести из проектов в процессы. Все таки основная цель этой методики "убивать" излишки времени, перезакладываемые в планировании и делать только те задачи, которые критичны для проекта.В процессах, мы должны сделать все, но то что, что не является ограничением, можно делать не эффективно.
Идея фиксации ограничения в одном месте описана в книге "Новая цель. Как объединить бережливое производство, шесть сигм и теорию ограничений", которая как видно из названия, делает попытку примерить непрерывное совершенствование lean и 6сигма c TOC.
Но вообще тема буквального применения теорий эффективности на практике, очень обширна. Боюсь, формат комментариев на хабре для нее узковат.
Статья интересная и очень близка по характеру работы моей команды, за нее респект. Отмечу, что такие подходы можно применять в рамках достаточно крупного подразделения, состоящих из более мелких и состоящих в связях и взаимоотношениях друг с другом (мини-организация), где как раз мы и "рефакторим"
Cоглашусь с комментариями @ruomsergвыше:
Практика показывает, что для изменения (или создания) живых бизнес-процессов должно сойтись много звезд на небе — как минимум некотрое количество образованных, и одновременно неравнодушных людей, плюс внешний фактор который заставляет искать изменений. И нет, процесс нельзя принести с улицы, вычитать в книжке — и внедрить как прокрустово ложе. То есть можно — но что-то в фирме при этом отвалится. Процессы надо вырастить.
В нашем случае именно такая "гремучая смесь" и поиск своего пути позволила запустить процессы качественных изменений и добиться существенных результатов.
Управлять ограниченими (фокусируя их там где это требует момент времени для оптимального анализа, управления и изменения) - учимся и это достаточно интересно. И уж точно, это на стыках как инженерных так и бизнес компетенций
Да, как раз хотел сказать, что плюс-минус изложение книги «the goal» с адаптацией под современные реалии типа API :)
Про системного архитектора хорошо сказано "знает всё, но неглубоко".
Я полагаю, что на предприятии существует роль Change management. Она может быть вообще никем не заполнена, она может быть заполнена отдельным человеком, или это может быть как в армии, когда на одном человеке несколько фуражек сразу (ты и CEO и Change manager в свободное время!).
Соответственно, когда человек находится в шапке Change manager — у него должны быть инструменты, помогающие ему планировать и воплощать требуемые изменения. Теория Голдратта — один из таких инструментов.
И да, неплохо если все на предприятии участвуют в усовершенствовании своих процессов. Тут вам и пятый уровень Capability Maturity Model, и непрерывное усовершенствование процессов по Lean, и все что хотите. Но по-факту, разделение труда приводит к тому, что некоторая часть людей начинает преимущественно заниматься Change Management, и это выгоднее для всего предприятия.
А вот способов (!) воплощения идей изменений может быть много — и это зависит от организационной культуры. Если организация построена на бюрократических принципах — то и изменения процессов пойдут через изменения регламентов/уставов/whatever. А если организация построена на другой культуре — то и способы внедрения будут другие: обучение, внутренний маркетинг, организационный эксперимент и др.
Что касается «бесконечного решения проблем пока не закончатся ресурсы» — это философский вопрос. Некоторые восточные культуры вообще продвигают мысль, что от проблем нельзя избавиться, но можно иногда менять одни на другие: колесо сансары и все такое вот… :-) Я выше говорил, что у последователей теории Голдратта появилось стойкое убеждение, что по-возможности, нужно проектировать узкие места в организации, а не гонять их по кругу туда-сюда. С другой стороны, даже в бесконечном решении проблем пока не закончатся ресурсы — нет ничего прямо вот ужасного. Если проблемы не решать — ресурсы тоже закончатся, это раз. А во-вторых, пока ресурсы не кончились — можно успеть создать немало пркрасного! :-)
И да, неплохо если все на предприятии участвуют в усовершенствовании своих процессов. Тут вам и пятый уровень Capability Maturity Model, и непрерывное усовершенствование процессов по Lean, и все что хотите. Но по-факту, разделение труда приводит к тому, что некоторая часть людей начинает преимущественно заниматься Change Management, и это выгоднее для всего предприятия.
Небольшой таймлайн.
В начале было Слово. И Слово было «традиция».
Потом в конце 19 начале 20го веков с подачи Фредерика Тейлора появилось то, что мы называем «научный менеджмент»:
1. организацией работы занимаются специальные отдельные Менеджеры
2. используется научный подход для выбора наиболее эффективного метода производства (измерить, оценить, модернизировать, измерить)
3. выбирать тех, кто лучше подходит для конкретной работы
4. тренировать работников работать правильно, по инструкциям
5. мониторить эффективность
Это начало 20го века, на секундочку, Эндрю Карнеги и вот это все. Следом были все эти ваши Форды с эффективными конвеерами. И самой бескомпромисной бюрократией. Все задокументировано. Вертикаль управления. Строгие инструкции.
Потом, когда конвееры запускали все кому не лень, научный прогресс только ускорялся и серьезно так усилилась конкуренция, крупные компании стали исчезать так же быстро, как и появлялись. На повестку встал вопрос эффективность вот такого научного подхода к менеджменту, и в результате кто-то заговорили о необходимости меняться, кто-то наоборот пытался воздействовать на рынок и среду. Очень много интересного происходило в этот период, до сих пор книги пишут. Но нам сейчас в это погружаться не стоит. Важно помнить, что именно в это время появляется change management.
Бескомпромисная гонка вооружений, конкуренция и быстрый научный прогресс заставляют самые законстенелые структуры эфолюционировать, рождая самые причудливые формы теорий управления. Как результат, В 70-х все пестрит новыми теориями менеджмента на любой вкус, их тогда придумали столько, что их до сих пор продают, как что-то новое. Голдратт это как раз эта золотая эпоха. Да, тогда много хорошего повилось, и много всего, что со временем станет основой для современных подходов к управлению.
Нам важно то, что условно до 70-80х все нововведения, представления, модели — большая часть всего этого была основано на модернизации бюрократических (или как их еще называли, машинных) систем.
>>> Статья и комментарии к ней сейчас находятся вот тут
Потом уже кристаллизировались вот эти ваши аджайлы. В конце 90х, начале 2000х в научны кругах стала популярна метафора, описывающая компании, как живые организмы, которые не только эволюционируют, чтоб соответствовать требованиям окружения(рынкам), но и сами непрерывно меняют окружающую среду, создавая новые потребности, ресурсы, направления. Компании, предвидящие и создающие будущее. Эпоха Интернета. Матричные структуры в организациях. Макдональдс, который умудрился на разных уровнях использовать кардинально разные подходы к управлению. А статьи на Хабре пишут про хорошие, но безбожно устаревшие методологии 70х.
Системы управления, как и любой инструмент, эффективны только при использовании для решения соответствующих задач. Можно сделать бирюзовое рекламное агентство, да что там говорить, даже Valve можно сделать бирюзовым, но Братский металлургический завод нельзя.
И дело не в дремучести персонала или отсталости технологий, требование к точности исполнения технологических цепочек и квалификации людей принимающих решение таково, что консенсусом в каждой новой итерации их не обеспечить.
Все пространство реально существующих задач, стоящих перед системами управления таково, что до сих пор есть место эффективному использованию и научной организации труда начала века и сверхсовременной Holacracy.
Квалификация ответственного за построение системы, должна позволять применять наиболее эффективные методики и принципы из множества подходов в наиболее подходящих для этого местах, в соответствии с уровнем развития изменяемой системы управления.
Очень точное описание роли, ее задач и инструментария, спасибо.
А это уже отдельная тема про управление изменениями и цикл PDCA (PDSA), который еще в лохматые 40-е был впервые описан как раз для изменения процессов.
Хотя цикл PDCA, а скорее даже OPDCA, не самый худший пример. По крайней мере в цивилизованном мире он эволюционировал. Мой вопрос в комментарии как раз был о двойном цикле. На этапе между «A» и «P» делается проверка, а хороши ли ваши операционные нормы вообще? Эффективны ли ваши процессы в текущих условиях? Грубо говоря, перед тем как переписывать законы, не нужно ли переписать конституацию?
>> От того, что до сих пор у нас самые передовые управленческие методики — это наработки 40-70, мне становится грустно.
Любая отрасль не только расцветает, но и деградирует. Управленческая не исключение. И ничего удивительного, когда обнаруживается что нечто 50-летней давности работает лучше современного. Конечно ее везде, не все, но жемчужин из прошлого много.
Процессы бесспорно важны, но более важным является управление человеческим фактором. Ивар Якобсон в последней своей книге раскрывает в целом, что послужило основным проигрышем RUP по сравнению с гибкими методологиями.
> As strange as it may sound, the methods we employed in the early days did not pay much attention to the human factors. Everyone understood of course that software was developed by people, but very few books or papers were written about how to get people motivated and empowered in developing great software. The most successful method books were quite silent on the topic. It was basically assumed that in one way or the other this was the task of management.
Спасибо за статью. Сам работаю почти по той же специальности. От некоторых моментов почти на слезу пробило от родства проблем)
Подождите, но это разве не то, чем должен заниматься директор, или другой менеджер выше среднего звена? Мы через это проходили, это ж стратегически важная функция, и ее нужно не аутсорсить, а поручать управлению внутри компании. Однажды настроенная система процессов и управления не будет работать вечно, условия постоянно меняются.
Функция действительно важная и отдавать ее на чистый аутсорс нельзя. Обычно консалтинг привлекают для построения этой функции и проведение первой итерации. Дальнейшее изменение отдают уже созданной внутри организации компетенции.
Что касается того, что этим должен заниматься директор, не соглашусь. Он должен это контролировать и принимать участие, на верхнем уровне проектировать необходимые функции. Но начиная со среднего бизнеса, погружаться до уровня операционных процессов точно не должен. Все же генеральный директор это стратег, а не тактик.
Если говорить про CEO — в методологии BPM (business process management) выделяют такую роль как "Владелец процесса" — это человек обладающий полномочиями на изменение процесса и отвечающий за его результат. При этом для обеспечения полномочий "Владелец" управляет процессами только в рамкам своей бизнес-функции (продажи, производство, юридическая поддержка, финансы и т.д.).
В итоге в сквозном процессе (от заявки до доставки) присутствует несколько владельцев. А таких сквозных процессов в компании далеко не один. Соответственно, начиная со среднего бизнеса появляется потребность в человеке, который обладает информацией о всей системе и обладает квалификацией ее менять. Владельцы выступают как стейкхолдеры процесса изменения, согласуют процессы и дают ресурсы на их изменение.
Я рефакторю компании