Обсуждение

В тексте ни разу не встречаются слова - "ответственность" - "отчётность" Если есть Правильный Процесс, он даёт правильный отчёт. А всё неработающее списывается на случайные помехи. Если есть Правильный Процесс, менеджмент ни за что не отвечает. Если где ошибка, или исполнители не правильные, или в процессе что-то не учли и надо Ещё Более Правильный Процесс. Это те причины, почему подходы такие, какие они есть. Биологические системы субоптимальны. Правильное планирование позволяет снизить издержки. Другое дело, для правильного процесса, как и для правильного продукта нужны опыт и мозги. Менеджерам выгоднее набрать сотню индусов, чтобы они в результате какую-то кучку навалили. LeanKanban работают только на конвейерном производстве с уже отлаженными технологиями. Когда их пытаются применить в инженерном деле, тойотовские ИТРы мрут от перегрузок.

LeanKanban для разработчиков (там уже довольно много вариантов) другой, нежели чем для производства. Я это явно указал. И там огромное внимание уделяется правильным показателям (по которым не платят премии и не используют как отчётность, а которые используют для разных пониманий и принятия содержательных решений). Мозги же и опыт нигде не помешают. Задача в том, чтобы как с операциями деления: сначала их только в университете изучали, а потом и в начальной школе проходить начали. Так и тут: что-то только мозгами и опытом даётся, а чему-то можно и научить и поддержать софтом "с полочки". В этом направлении и работаю.

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

В Тойоте тысячи и тысячи человек, дураков там тоже вполне хватает. А есть и не дураки. Но LeanKanban давно развивается и на многих других предприятиях, в том числе в непроизводственных подразделениях. Я там ещё больше не-дураков, чисто количественно -- процент-то не-дураков низкий, но более-менее постоянный среди людей, если выйти за пределы Тойоты, то не-дураков будет больше.

Какое-то сомнительное доказательство.

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

Ладно, я заканчиваю. Смотреть надо психологию инженерной деятельности.

А ещё есть менеджерская психология, её тоже не нужно игнорировать. Но социологию тут было бы более правильно рассматривать, а не психологию. Деятельность-то коллективна.

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

В суде тоже "процесс" -- но это совсем ведь другой процесс! Сначала нужно договориться, что я тут про спланированные up front длинные цепочки операций, "бизнес-процессы" в их традиционном сегодняшнем массовом понимании. Все необходимые оговорки в тексте, что "иногда и бизнес-процесс помогает" (иногда! не всегда!) я сделал. Что тот же case management пытается себя отнести даже не к проектному, а именно к процессному управлению (блудные сыны, хе-хе) я знаю, и даже LeanKanban находятся любители описывать так же -- хотя описание в терминах практик (тонкая разница с процессами!) тут распространённей. Есть, конечно, для процессов применения -- чем ближе к воплощению системы и дальше от определения системы в жизненном цикле, тем больше.

Отлично сфрмулировано. Полностью согласен. Меняем процессы на потоки и коммуникации. Делаем модули..из людей? Как сделать модуль из людей кроме метода проб и ошибок и долгой притирки - вот в чем вопрос.

Модули обеспечивающей системы делаются из людей и инструментов, а принцип тут -- поддержка практик (функций, операций. Я ж согласен рассматривать необходимые и даже потенциально необходимые изменения, я ж только против длинных up front спланированных предопределённых их цепочек). Практика же это дисциплина+технология, то есть и компетенции людей и возможности оборудования, совместно. Нарезка на модули по этой линии.

Каждой модели совместной работы - свое применение. Натягивать чисто процессный подход на судебное дело или НИОКР дело конечно неблагодарное, но и распространять case management на всю деятельность - нисколько не лучше (а именно этим, на мой взгяд, грешат адепты этого направления). Никуда не денешься - надо уметь сочетать и процессное, и проектное управление, и кейс-менеджмент. И правильно ли брать за точку отсчета системы ("воплощение", "жизненный цикл"), нет ли тут профессиональной деформации? ;) Мне кажется более правильным плясать от бизнеса, т.е. от цепочки создания ценности, начинающейся разработкой продукции и заканчивающейся клиентскими рекламациями. На правах рекламы: завтра 17.06 российская Ассоциация профессионалов управления бизнес-процессами проводит семинар в формате case study: "Процессное управление в проектной организации". Сбор с 17:00, начало в 18:00. Приходите, чтобы не судить о Карузо по перепевам соседа, увидите что такое современное управление бизнес-процессами - http://abpmp.org.ru/events/17/genplan/

Допустим. А как на счет бизнес-процессов в сервисе? Я вот к примеру работаю в интернет-провайдере (rinet) У нас все построено на процессах (аварии, подключения и т.д.) Стоит ли отменять бизнес-процессы - если да, то зачем? Если в этом случае нет то почему?

Мне просто интересно - есть ли практика создания таких модулей? Вот практика создания методик есть - инженерия методов. Очевидно, что нельзя просто так собрать людей используя в качестве критерия только их компетентность. Ибо иногда такой "модуль" работает, а иногда нет.

Если теоретически, то для разных стейкхолдеров нужны три варианта описания: -- процесс-ориентированное (в центре его работы. Проектное управление тоже сюда попадает) -- продукт-ориентированное, кейс менеджмент где-то тут. -- коммуникационно-ориентированное (примером тут DEMO от Jan Dietz, в нём обсуждаются ответственности исполнителей, точки выдачи поручений и приёмки работ и т.д. -- там не "процессы", а "транзакции"). Акцент на команду и подконтрольные ей технологии. Но в разных ситуациях упор нужно делать на разных описаниях. Семинар интересный, записался и поставил в план. Если, конечно, клиент не сорвёт на какое-нибудь внеплановое мероприятие )))

Как по мне, описания вообще не катят: все, что можно было сделать без компьютеров, уже сделано до нас. Comindware (www.comindware.com) собрал сильную команду (я тоже участвую) под задачу создать унифицированную платформу для управления процессами, проектами, кейсами, состояниями. Все это поверх system of records и social networking, плюс единообразный task management и единая архитектура, охватывающая все формы работы (про нее, кстати, Вы забыли, а для некоторых стейкхолдеров это №1). ОК, надеюсь, до встречи!

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

Держу пари, что в значительной мере у вас не процессы, а именно кейс-менеджмент -- если у вас авария, то ведь нет процесса, как её устранять! Последовательность действий неизвестна. Есть только понимание, какого сорта операции нужно выполнить, а планирование самих действий (и даже выбор исполнителей этих действий) идёт по мере накопления информации. Именно поэтому incident management и case management так близко связаны и поддерживаются более-менее похожим софтом, issue tracker.

В коротком посте можно только использовать separation of concern -- про системы, архитектуру и т.д. понятно, что не написано и не раскрыто. Про важность софта, кстати, я несколько раз в посте поминаю (а кое-где не только софта, но и станков). Описания -- это рабочие продукты для определений, они вполне могут быть компьютерными структурами данных. Тоже надеюсь, что до встречи!