Теперь посмотрим на весь цикл глазами Demand. Все очень даже похоже на происходящее в реальном бизнесе. На первой фазе, пока вы изучаете рынок и планируете будущие проекты, технари-исполнители уже выполнили очередную прошлую задачу и проверяют результаты ее внедрения. Более сложный для реализации и понимания следующий второй этап. Технический персонал перешел в режим отдыха, расслабившись в поисках новой следующей задачи. А у вас наступила фаза 2 основной активности. Что же это за активность?
Результатом Demand не должен быть конечный продукт. Результатом Demand может быть только разработанные архитектура и проект в терминах бизнеса. На этой фазе, вы можете оторвать Supply от заслуженного отдыха и привлечь его к разработке вашего собственного Demand продукта, но ответственными за разработку документа, который часто называют БФТ (Бизнес и функциональные требования), являетесь вы и только вы. Другого результата у Demand нет!
Именно поэтому, в методологиях разработки программного обеспечения, отдельно прорастают Business Use Cases и Software Use Cases, а в бизнесе отдельные два документа – БФТ и Технический анализ и дизайн. Их просто делают разные группы людей и это правильно.
На третьей фазе происходит своего рода квантовый переход и передача эстафетной палочки от Demand к Supply. В соответствии с технологией, Supply приступает к планированию изготовления продукта. В это же время Demand релаксирует, проверяя наcколько качественно отработаны БФТ и корректируя, пока еще не поздно планы Supply.
На четвертой фазе, Supply реализует план реализации продукта. Вмешаться в это исполнение со стороны Demand практически нет возможности. Это своего рода фаза отдыха Demand в ожидании реализации задуманного.
И еще немного глазами Supply. Технические же службы, уходя в точке Act в ожидание, что же скажет бизнес, находятся в полной уверенности, что лучше всех проанализировали свои возможности и свежие бизнес-планы. Но затем они с легкостью получают обратно принятые бизнесом решения, которые могут кардинально отличаться от их предыдущего плана. И это нормально! Пауза и передача управления от черных к белым и обратно – лучше, чем попытка делать одновременные, но иногда противоречивые ходы.
И так повторяется из цикла в цикл, от почти мгновенных автоматических операций Run с высокой тактовой частотой, до медленных проектов Change, длящихся месяцами и кварталами.
Хочу поделиться парой личных наблюдений из собственного опыта. Бизнес-планерки, как правило, проводятся в утренние часы. Технические же, планерки, как правило, проводятся во второй половине дня. Понедельник начинается с операционного анализа за прошедшую неделю, вторник – лучшее время для планерок генеральских, среда – день проектных статусных митингов. Сравните со своими компаниями. Думаете все это случайные совпадения?
Подобно тому, как природа развела по фазе и сделала асинхронными периоды управления телом и управления смыслом, так и бизнес-процессы по своей природе асинхронны. Любые попытки их синхронизировать в режиме On-Line важны, но все равно останутся ограниченными. Заниматься одновременно управлением клиентами и инфраструктурой, управлением ожиданиями и разработкой – невозможно, как невозможно одновременно думать левой и правой половинами мозга, как невозможно одновременно писать картину и решать математическую задачу, как невозможно одновременно спать и бодрствовать. Можно к этому стремиться, но невозможно достичь. Таксист, разговорившийся с пассажиром сильно рискует угодить в аварию.
Здесь хотелось бы точных научных или конкретных практических выводов. Думаю, что они лежат в самой модели и у каждого свои. Предлагаю лучше посмотреть и насладиться насколько это гениально уже придумано до нас! А насладившись, стоит вернуться и вспомнить, что, увлекшись горизонтальной осью течения процессов, мы забыли про ось вертикальную.
Четыре направления любой системы
Совмещая вертикальную и горизонтальную оси в виде плоской ортогональной системы координат, совмещая две пары полярностей, мы получим своего рода «сервисный компас», ориентированный своим севером на клиента.
В таком компасе просматриваются все четыре фазы PDCA (Plan, Do, Check, Act) любого бизнес-цикла. Обычная деятельность Do
, исходящая от обоих полюсов вертикальной оси, является своего рода раздражителем, требующим реакции с противоположной стороны. Клиенты своей деятельностью влияют на инфраструктуру и наоборот, изменения инфраструктуры тут же, как в зеркале, сказываются на деятельности клиентов. Между раздражителем и реакцией, всегда должна быть пауза, во время которой проходит процесс в горизонтальном направлении оси: Check – понимание ситуации, сбор, обработка и анализ информации, рефлексия и накопление опыта, Plan– подготовка и исполнение ответной реакции.