Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Продуктам -- да! Процессам -- нет!

Я хочу тут опять выступить против процессного подхода в менеджменте. Он уже давно превратился из лекарства в болезнь, давно приносит больше вреда чем пользы. Процесс -- это последовательность шагов во времени, жёсткая (ни разу не гибкая, несмотря на явно прописанные многочисленные ветвления для основных и особых случаев) инженерная конструкция. Чтобы обработать какое-то исключение, или переналадить процесс на новую версию, нужно хорошо повозиться: нужно долго целиться в правильное место многостраничных инструкций, часто во многих местах каждой инструкции -- а потом долго-долго доводить до всех заинтересованных сторон эти инструкции, заново оттренировать новый процесс.

Достоинства: минимум коммуникации, всё происходит "само", до первого затыка. Недостатки: постоянные затыки становятся нормальным режимом работы. Ибо идеальных процессов не бывает: сегодняшний мир (как внешний по отношению к фирме, так и внутренний) меняется в разы быстрее, чем "процессы" отражают эти изменения в инструкциях, софте и (в третью только очередь!) в жизни.

Процессный подход -- это сложные правила (процессы), с результирующим простым поведеним. Ужас-ужас-ужас, архаика инженерной мысли прошлого века, даром что это "инженерия предприятий". На мой взгляд, "процессный подход" -- это плохая инженерия предприятий, негибкая, неэффективная, времён конвейера Тэйлора, за много лет до конвейера той же Тойоты и уж точно не приспособленная к знаниевым предприятиям (knowledge enterprise), к которым можно отнести любую разработку.

Для текущей сложности корпораций с их бесчисленными сотрудниками и компьютерами (не сбрасывайте компьютеры со счетов!) плюс необъятным станочным парком (хотя на знаниевых производствах это те же компьютеры, просто разные прикладные программы) чисто инженерный заход на "сложные правила и конструкции -- простое поведение" недопустимо архаичен, такие системы в жизни не выживают, ломаются. В жизни нужно следовать больше примерам из природы, где большие системы ориентируются на какую-то "самоорганизацию" (слово неудачное, ибо нет там никакого "самоорганизатора"), порождаемую простыми правилами взаимодействия для более-менее автономных частей и на выходе дающими гибкое сложное поведение.

Далее я должен бы рассказать много разных баек про эту самую "самоорганизацию", с примерами исключительно простых правил и исключительно сложного результирующего поведения, но я знаю, что читатели у меня умные и начитанные, они про эти байки много раз слышали, каждый в своей области. Кто таких баек не знает, я рекомендую обратиться к Гуглю (и не задавать мне на эту тему вопросов в комментах).

Процессы не являются решением для самых важных вопросов, самых сложных проблем. Часто такие проблемы называют "мерзкими" (подлыми, нечистыми, гибельными -- кому как больше нравится, в оригинале это wicked problems). Такие проблемы отличаются тем, что вовлекают множество стейкхолдеров с самыми разными ценностями и приоритетами, корни проблемы сложны и запутаны, сама проблема плохо формулируется и изменяется при каждой попытке её решить, прецедентов успешного решения нет, намёток для правильного ответа на проблему нет. Типовой пример -- это стратегирование: https://hbr.org/2008/05/strategy-as-a-wicked-problem

Трудно представить, что можно установить "процесс", который будет заниматься стратегированием. Или проектированием/разработкой: Steve Tendon в книжке https://tameflow.com/book/hyper-productive-knowledge-work-performance прямо указывает, что стратегирование и разработка очень похожи по типу решаемых проблем и стилю работы. И дальше подробно объясняет, что высшие менеджеры готовы разрешить себе хорошо работать в стратегировании, безо всяких "процессов" -- в коммуникации друг с другом, получая множество обратных связей по каждому продвижению в проблеме. Но эти же высшие менеджеры неумолимо сползают уже на уровне линейных менеджеров в "процессный подход", и тем самым существенно убивают творческую работу в масштабах организации. Создаются сложнейшие правила, строятся альбомы и альбомы "бизнес-процессов", результатом выполнения которых является затем простейшее негибкое поведение.

Крупные инженерные системы вместо тщательного проектирования как сверхсложных цельных систем сегодня тоже создаются как набор всё более и более автономных модулей, совместно вырабатывающих сложнейшее поведение в активной коммуникации друг с другом. Каждый из этих модулей следует нехитрым правилам. Правила обозримы, поведение уже необозримо. По-настоящему большие системы именно так и делаются, например сотовая телефония, интернет, SmartGrid. Нейронные сети по сути своей тоже состоят из простейших частей-нейронов, подчиняющихся простейшим правилам взаимодействия. Но они научаются сложнейшим вещам, их поведение сложно!

Не хочется загромождать текст специфическими программистскими примерами, хотя я и предупреждал, что в современной организации в кучу замешиваются не только люди, но и компьютеры -- и для них тоже пишутся инструкции, "процессные" и не очень, как и для людей, и разработка этих инструкций тоже может быть устроена "процессно" или не очень. Поэтому вскольз замечу, что все эти agile, микросервисы, акаузальные (aka в чём-то декларативные) языки типа Modelica -- это шаги ровно в том направлении, разбивки-развязывания длинных "процессов" и цельнолитых конструкций из окаменевшего эээ... не скажу чего на более маленькие и автономные, но тесно коммуницирующие между собой кусочки. Составные части проще и автономней, результат более гибкий, масштабней и устойчивей. Фишка в свободной коммуникации частей, не в точной индивидуальной подгонке последовательности взаимодействия частей частей.

Алан Кей предлагает это делать на многих уровнях, беря примером не столько инженерные "спроектированные" конструкции, сколько много более сложные биологические системы (у него слоган "от шестерёнок к биологии" -- см., например, великолепную лекцию http://www.heidelberg-laureate-forum.org/blog/video/lecture-friday-september-27-alan-kay/). Или берём Julia -- там тоже много чего делается, чтобы вместо тысяч и тысяч специальных случаев формулировался один общий, это делается отнюдь не "процессами", не процедурными средствами (см., например, подробное разбирательство http://nbviewer.ipython.org/gist/StefanKarpinski/b8fe9dbb36c1427b9f22, закачивающееся словами Meaning is hard and there are a lot of "protocols" that we still need to abstract out -- как раз про простые интерфейсы-протоколы, за которыми скрывается сложное поведение).

В чём же проблема? Почему в наш век интернета все эти простые правила "самоорганизации" ещё не выявлены, а уже выявленные правила не используются менеджерами? Причин много:
-- выявленные правила почти невозможно отличить от шарлатанских заявлений, тем более что
-- хорошие правила контринтуитивны, их трудно понять, в их действенность трудно поверить.
-- есть альтернативные, более раскрученные наборы правил (типа тех же правил "процессной организации труда, в том числе процессной организации проектов").
-- руководители -- это руками водители (чужими руками водители, буквально), они ни разу не организаторы, они сразу не нужны после того, как всё организовалось и работает "само".
-- Чувство контроля в предлагаемой системе у руководителя отсутствует, ибо "власть правила" заменяет "власть руководителя". Кто ж добровольно отдаст власть?
-- общее чувство неуверенности в успешности результата будет не только у руководителей: хорошие правила абстрактны, а результат сочетанного их применения невозможно предсказать заранее и нужно просто верить, что он будет положительным и достигнут в обозримое время.
-- во всё это не готовы верить даже для "дальнего порядка", когда люди плохо знают друг друга и доверяют друг другу (например, в свободный рынок множество людей верят в разы меньше, чем в госплан -- несмотря на огромный исторический опыт и развитую теорию), чего уж тут говорить, если мы переходим к "ближнему порядку", когда мы немного знаем друг друга и доверяем сильно больше?

Предположим, что мы уверовали, что процессный подход не так хорош, как о нём рассказывают в книжках двадцатилетней давности. Но что можно предложить вместо него?! Какие правила, кроме "сначала делай раз, потом делай два, и если был зелёный свисток, то делай три"?

Тут можно было бы указать на пословицы PraxOS (http://ailev.livejournal.com/1172430.html), но только пословицами тут не отделаешься.

Во-первых, нужно использовать продукт-ориентированную (иногда говорят artifact-based -- https://en.wikipedia.org/wiki/Artifact-centric_business_process_model) парадигму описания деятельности как основную (продукты, они же системы, конечно, сложны -- но по их поводу легче договориться и найти их в физическом мире, чем сделать это для много более абстрактных процессов. К тому же все эти продукты-системы и их разные состояния по ходу жизненного цикла получаются в результате каких-то действий обеспечивающей системы, т.е. процессная часть тоже представлена, только не так явно как "последовательность действий". Можно о таком представлении думать как о системе уравнений: порядок вычислений и даже их состав по большому счёту неважен -- хотя какой-то обязательно будет, но решение системы уравнений будет удовлетворять всех и это решение легко проверить. Так и продукт: порядок операций и даже их состав по большому счёту неважен, но продукт/система как результат будет удовлетворять всех и этот результат легко проверить.

Этот ход мысли заодно поменяет в фирме и класс софта с "управления процессами/проектами" на "отслеживание вопросов" (issue tracking, а иногда и простейшие канбан-доски), а вместо длиииинных процессов могут быть использованы короткие "шаблоны" для тех случаев, когда наличествуют повторения каких-то последовательностей (впрочем, есть мнение, что выявленные последовательности нужно не выполнять людям, а сразу автоматизировать). Этот ход мысли и есть adaptive case management -- http://ailev.livejournal.com/946134.html (впрочем, за последние четыре года с того поста много чего ещё появилось на эту тему, я неоднократно об этом повороте писал, например о связи контрольных вопросов с этим подходом).

Во-вторых, нужно в рамках продукт-ориентированной парадигмы думать о логистике всех этих продуктов -- видеть потоки продуктов через рабочие станции, видеть work in progress (WIP) и batches в том числе и при разработке/development, не только в производстве/manufacturing. Тут LeanKanban это наше всё, а главные заклятия -- small batch size и ограничение WIP, экономические показатели "глобального максимума" (включая разные хитрые финансовые системы типа Beyond Budgeting, Cost of Delay, Throughput Octane). Ну, и помня про разницу между "проектом" и "фирмой" ("фирма" растёт! http://ailev.livejournal.com/1193305.html).

В-третьих, нужно инженерно обеспечивать модульность в своих системах (желательно использовать открытые архитектуры, где модули соединяются по открытым стандартам). Если система не модульна, то "всё со всем хитро связано" и этот клубок зависимостей будет не расплести годами. Если система модульна, то появляется шанс поделить работу на более-менее независимые части.

В-четвёртых, обсуждайте всё и вся, моделируйте всё и вся, повышайте плотность коммуникаций: маленькие команды при хорошем инструментарии моделирования и плотном общении могут выдавать продукт быстрее и качественней, чем большие команды с "процессами".

Конечно, это только самые общие принципы, и то не все (влёгкую можно писать и в-пятых, и в-шестых и т.д.). Это эвристики, т.е. эти принципы не абсолютны, иногда и традиционный "бизнес-процесс" помогает (иногда! не всегда!). На каждый такой принцип нужно пару сотен более мелких принципов -- есть огромное количество литературы по этим вопросам, и огромное количество поддерживающего софта. Эти принципы контринтуитивны. Их не реализуешь в отдельно взятой команде (менеджмент просто не даст такой команде работать). Они имеют дело с мерзкой проблемой организации работы предпринятия -- и можно не надеяться на то, что они как-то надёжно решат эту проблему. Но если активно общаться и потихоньку планировать шаги, непрерывно получая обратную связь и научаясь работать таким нетрадиционным способом (впрочем, в некоторых программистских фирмах подобная работа бывает уже общепринята, хотя и редко), то можно добиться немалых успехов.
* * *
Кое-что из практик, опирающихся на описанную парадигму, я буду рассказывать и тренировать 27 июня 2015 вот тут: http://nisse.ru/actual/events/?ELEMENT_ID=130884.

UPDATE: какое-то обсуждение в фейсбуке тут -- https://www.facebook.com/ailevenchuk/posts/10205029854160091
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 76 comments