Что такое верхнеуровневый план
Технологии процессного управления
Три правила выделения процессов верхнего уровня
Технологии процессного управления
Три правила выделения процессов верхнего уровня
Сергей Ковалев — руководитель и ведущий консультант консалтинговой компании БИТЕК (Бизнес-инжиниринговые технологии). Имеет 20-летний опыт организационного проектирования и управления бизнес-процессами. Автор публикаций, семинаров и книг по стратегическому и процессному управлению и развитию.
Количество процессов верхнего уровня
Эмпирически, из практического опыта выведено оптимальное количество выделенных бизнес-процессов.
Правило 1. На верхнем уровне деятельность компании должна быть разбита на 15-20 бизнес-процессов верхнего уровня.
Практика показала, что разбиение компании на 15-20 процессов верхнего уровня является оптимальным с точки зрения контроля и интеграции процессов со стороны первого руководителя. В таком случае первый руководитель будет регулярно (как правило ежемесячно) получать 15-20 отчетов по выполнению ключевых показателей бизнес-процессов верхнего уровня. Также первому руководителю нужно будет активно учавствовать и принимать решения по оптимизации взаимодействий между 15-20 бизнес-процессами.
Если компанию разбить на большее количество бизнес-процессов верхнего уровня, то уровень контроля процессов со стороны первого руководителя будет излишне детальным, а интеграция процессов между собой потребует много времени. Такая детальная интеграция — не соответствует уровню первого руководителя, так как требует глубокого погружение на операционный уровень каждого бизнес-процесса.
Пример. В одной компании специалистами по описанию процессов было выделено 80 бизнес-процессов верхнего уровня. Это обосновывалось тем, что деятельность компании слишком сложная и требует множества бизнес-процессов. Когда специалистам сказали, что при таком подходе их генеральному директору придется ежемесячно рассматривать 80 отчетов о выполнении ключевых показателей по бизнес-процессам верхнего уровня, а также участвовать в выстраивании взаимодействий между этими 80 процессами, складывая их как мелкий пазл, то специалисты по описанию процессов задумались, но остались на своем решении. Однако, когда эта работа была доведена до генерального директора, он попросил специалистов по описанию процессов агрегировать многие процессы для того чтобы уровень контроля и интеграции с его стороны был оптимальным. В результате в этой компании на верхнем уровне стало 18 бизнес-процессов.
Практика показала, что при работе с процессами любая компания в итоге придет к 15-20 бизнес-процессам на верхнем уровне, которое, повторюсь, является оптимальным. Конечно есть небольшие компании, как например рассмотренная в части 5 компания «Видеомир», в которой было выделено 12 бизнес-процессов верхнего уровня. Также есть крупные компании, в которых приходится выделять много обеспечивающих бизнес-процессов, добавляя к типовому перечню такие обеспечивающие процессы как промышленная безопасность, экологическая безопасность, обеспечение электроэнергией и др. — в результате чего перечень процессов верхнего уровня может достигать количества 22-24 и даже выше. Но в среднем, как показывает практический опыт на верхнем уровне количество бизнес-процессов составляет значение 15-20.
Важность процессов верхнего уровня
На верхнем уровне все бизнес-процессы должны быть соразмерно важны для достижения стратегии компании. Не допускается на верхнем уровне рядом с важными и крупными процессами, размещать неважные и мелкие бизнес-процессы.
Правило 2. Бизнес-процессы верхнего уровня должны быть равнозначными с точки зрения важности для достижения стратегии компании.
Давайте рассмотрим, как влияет это правило на выделение бизнес-процессов верхнего уровня.
Пример. В торговой компании, занимающейся дистрибуцией лекарств (подробнее сотрите часть 5) в группе управленческих бизнес-процессов имеется процесс по управлению товарным запасом (рис. 20). Ранее на верхнем уровне этого процесса не было, так как он входил в состав бизнес-процесса закупки лекарств и был на втором уровне. Однако, с этим процессом связаны три ключевые проблемы и соответствующие им ключевые показатели.
Первый проблемный ключевой показатель — это величина товарного запаса, который достигал значения 6 месяцев продаж. То есть на складе товара лежало на 6 месяцев продаж и склад за год оборачивался всего лишь 2 раза. Таким образом оборачиваемость товарного запаса были слишком низкой, а его величина и соответственно затраты на складирование и поддержание товарного запаса были слишком высокими.
Вторым проблемным ключевым показателем по товарном запасу, являлся ассортиментный дефицит, который в определенный периоды времени достигал значения 20%. Когда клиенты направляли в компанию заказы на поставку лекарств, то оказывалось что по 20% ассортиментным позициям, товар на складе отсутствует. Соответственно компания теряла выручку, а удовлетворенность клиентов снижалась, и они переключались на других поставщиков лекарств. Основной причиной большого ассортиментного дефицита было то, что отсутствующий товар негде было размещать на складе, так как склад был забит большим количеством другого товара. То есть основная причина была связана с большим товарным запасом.
И третий проблемный ключевой показатель — это доля неликвидной продукции, которая также была высокой. Под неликвидной продукцией в компании считались лекарства со сроком годности менее 6 месяцев. Такие лекарства приходилось продавать с существенными скидками, то есть неликвидная продукция быстро обесценивалась и приводила к финансовым потерям. Причиной большого количества неликвидной продукции, как и большого товарного запаса были излишние закупки.
Когда руководители компании изучали опыт работы дистрибьютеров лекарств в других странах, то увидели, что там средняя величина товарного запаса составляет 2 месяца продаж. То есть при одном и том же объеме продаж товарным запас был в 3 раза меньше и требуемый размер склада тоже, соответственно затраты на складирование и поддержание товарного запаса также в 3 раза были меньше. Также было понятно, что все три проблемы товарного запаса взаимосвязаны и что ключевая причина трех проблем связана с излишними закупками и отсутствию должной работы по управлению товарным запасом.
Сначала в торговой компании ответственным за эти показатели являлся отдел закупок, так как процесс по управлению товарным запасом входил в состав процесса закупок. Но отдел закупки не смог обеспечить улучшение этих трех ключевых показателей по двум причинам:
• отдел закупок был сконцентрирован на других своих основных процессах — это поиск поставщиков, формирование заказов на поставку, их отслеживание и др.;
• поставщики лекарств большими скидками стимулировали отдел закупок закупать в прок.
В итоге руководством компании было принято решение о выведении процесса по управлению товарным запасом на верхний уровень и назначении другого ответственного за этот процесс (владельца процесса). Теперь процесс по управлению товарным запасом непосредственно контролировал генеральный директор, а выполнением этого процесса занималась новая служба управления товарным запасом. Эта служба формировала отчетность по товарному запасу, анализировала ее и предлагала инициативы по оптимизации товарного запаса. Генеральный директор рассматривал эти отчеты и инициативы, принимал решения, а также контролировал как это влияет на ключевые показатели по товарному запасу. В результате этой работы в течение года все три проблемы по товарному запасу были устранены, а соответствующие три ключевых показателя были значительно улучшены.
Согласно правилу равнозначности, наиболее важные и проблемные процессы целесообразно поднимать на более высокие уровни процессной модели компании. Полезно отметить, что в различных компаниях есть много похожих бизнес-процессов, но они могут находится на разных уровнях процессной модели по причине различной важности для стратегии компании, а также их различной степени проблемности.
Утверждение процессов верхнего уровня
При согласовании карты бизнес-процессов верхнего уровня с первым руководителем компании полезно видеть не только формальную процедуру, но и дополнительный инструмент контроля бизнес-процессов и возможность сделать модель процессов верхнего уровня наиболее оптимальной и эффективной для практической деятельности.
Правило 3. Перечень бизнес-процессов верхнего уровня должен быть согласован и утвержден первым руководителем компании.
Пример. В торговой компании занимающейся дистрибуцией лекарств изначально было предложено на верхнем уровне показать только один бизнес-процесс продаж, а на втором уроне сделать его детализацию на три бизнес-процесса продаж на трех различных рынках. При согласовании карты процессов с генеральным директором он указал на необходимость отображения на верхнем уровне всех трех бизнес-процессов продаж и соответствующей отчетности. В другой компании, первый руководитель посчитал необходимым агрегировать ряд бизнес-процессов на верхнем уровне, в результате построенные процессные модели стали более эффективно использоваться для управления деятельностью компании.
Рис. 20. Карта процессов верхнего уровня торговой компании
В примере производственной компании в отличие от торговой среди основных процессов появился бизнес-процесс доставки продукции потребителям (рис. 21). В торговой компании такой бизнес-процесс также есть, но он входит в состав процессов продаж. Причина в том, что в производственной компании продукция экспортируется и процесс доставки продукции потребителям является более важным и дорогим по стоимости, поэтому и размещен на верхнем уровне.
В группе обеспечивающих бизнес-процессов производственной компании в отличие от торговой также появились еще два бизнес-процесса: ремонт и модернизация оборудования, а также капитальный ремонт и строительство. В торговой компании есть складское оборудование и погрузчики, а также процессы по их ремонту и обслуживанию. Но объем этих ремонтных работ в торговой компании меньше, именно поэтому у нее процесс ремонта входит в состав процесса складирования и размещен на втором уровне процессной модели.
Рис. 21. Карта процессов верхнего уровня производственной компании.
Также в торговой компании есть работы по ремонту офисного здания, но вследствие их меньшего объема и стоимости они также размещены на втором уровне процессной модели и входят в состав обеспечивающего бизнес-процесса по административно-хозяйственному обеспечению деятельности. В производственной компании бизнес-процессы ремонта и модернизации оборудования, а также капитального ремонта и строительства по объему работ, стоимости и важности являются более значимыми и поэтому размещены на верхнем уровне процессной модели.
Среди бизнес-процессов управления в производственной компании есть бизнес-процесс по управлению проектами, которого нет на верхнем уровне в торговой компании. Это связано с тем что в производственной компании перечень реализуемых проектов развития значительно больше, а контроль их выполнения и управление портфелем проектом более значимы для стратегии компании. В торговой компании такой процесс входит в состав процесса стратегического управления.
Ответственные за бизнес-процессы или их владельцы
На карте процессов верхнего уровня производственной компании также показаны ответственные за бизнес-процессы или владельцы бизнес-процессов (рис. 21). Именно они отвечают перед первым руководителем за достижение ключевых показателей по своему процессу, а также за функционирование процессов в соответствии с требованиями, которые формулируются в организационно-распорядительных документах компании.
Альтернативным способом отображения распределения ответственности за бизнес-процессы верхнего уровня является матрица ответственности (рис. 22). В строках матрицы перечисляются бизнес-процессы верхнего уровня, в столбцах матрицы показываются руководители верхнего уровня, а на пересечении строк и столбцов показываются символы ответственности.
Рис. 22. Матрица распределения ответственности за процессы верхнего уровня производственной компании
Матрица распределения ответственности позволяет наглядно увидеть кто за что отвечает и показать равномерность распределения ответственности. Матрица позволяет наглядно показать бизнес-процессы, у которых нет ответственных, а также бизнес-процессы у которых несколько ответственных, что означает безответственность.
В результате матрица как наглядный формат описания распределения ответственности часто используется как на этапе доведения схемы распределения ответственности до должностных лиц компании, так и на этапе анализа и оптимизации деятельности компании.
В следующей части статьи мы расскажем о реинжиниринге и постоянном совершенствовании бизнес-процессов.
Заметки по трудностям верхнеуровневого моделирования
1. Неочевидность полезности моделирования.
Увы, люди думают о «невидимом» (прибыли, требованиях, системе, работе), но большинство не особо заботится о хоть как-то формализованных средствах выражения этого невидимого, обсуждения идут в форме баек на естественном языке и картинок с никакой нотацией. Чистой воды алхимия, с поэзией и упоминаниями о необходимости сосредоточения в части «намерения» вместо формул.
Затем учебный аспект: всему этому нужно будет как-то научить, а создание хоть как-то приемлемой технологии обучения и учебной среды требует дополнительного времени.
Пока же желающим продемонстрировать блеск верхнеуровневого моделирования не удастся это сделать без демонстрации сопутствующей нищеты. А разбогатеть быстро не получится, за пару-тройку лет ситуацию не исправишь.
Никакие моделеры сейчас не генерируют инфографику, хорошо хоть люди об этом задумались (тут можно особо похвалить Tom Graves, см., например, на его «The enterprise is a story», слайды 71-76: http://www.slideshare.net/tetradian/the-enterprise-is-the-story. 
vvagr любит мне напоминать, что при всей нашей в TechInvestLab приверженности к моделированию, лучшим для нас моделером, который мы можем использовать в разговорах с клиентом, является флипчарт и цветные маркеры. Вот эта презентация как раз об этом. Инициативы типа VDHL тут немного дают, но какой-то прогресс наблюдается и тут: Archi, например, поддерживает уже не только формальный ArchiMate, но и позволяет создавать canvas!
Накопление знаний (т.е. повторно используемой информации) многогранно, требует самых разных решений: от поддержки модульности, развития гранулярности в языке моделирования до возможности прийти на новое место работы, рассчитывая на возможность использования библиотек моделирования, освоенных на старом месте работы. Увы, моделирование (да и онтологизирование) на сегодня в этом плане похоже на программирование, каким оно было в середине семидесятых: про удобство библиотек все знали, но библиотек в мире было крайне мало (разве что парочка фортранных библиотек с численными методами). Желающим сделать какой-то проект моделирования а хоть в SysML, а хоть в ArchiMate приходится начинать по факту с нуля. И даже если удаётся выполнить стартовый успешный проект, форма переноса знаний в следующий проект остаётся проблематичной. Поэтому начальные высокие затраты остаются высокими (каждый раз проходится один и тот же длинный путь, с нуля), а последующие затраты не снижаются.
Построение верхнеуровневой модели деятельности компании на основе принципов системной инженерии. Глава 2. Делим организацию на части
Дмитрий Пинаев
Генеральный директор ГК «Современные технологии управления»
Принцип «модульности» при проектировании архитектуры
Вернемся к нашей компании. Из предыдущей главы мы теперь знаем, что в нашей модели деятельности верхнего уровня представлены функции. Давайте решим задачу обратную к описываемой выше задаче объединения конкретных процессов: давайте рассмотрим задачу декомпозиции функций. Давайте выясним, есть ли какие-нибудь общие рекомендации, как необходимо декомпозировать функции?
Искать принципы деления я отправился к системным инженерам (есть такая дисциплина — Системная инженерия). Кому как не им — создателям сложных технических систем — знать, как делить систему на части.
Удивительно, но я нашел только один принцип. Это принцип «модульности» или принцип «Сильная сцепленность — слабая связанность» из программирования (tight binding — loose coupling).
«При модульном разбиении системы «сильно сцепленные» функции группируются в слабо «связанные модули».»
Александр Косяков
Системная инженерия. Принципы и практика
Это позволяет уменьшить количество интерфейсов между модулями. Что в свою очередь дает следующие преимущества:
«Это необходимо для того, чтобы каждый компонент можно было проектировать, строить, испытывать и агрегировать с другими компонентами без существенной подгонки или настройки, не говоря уже об адаптации.»
Александр Косяков
Системная инженерия. Принципы и практика
Если говорить про модели деятельности, я думаю, что все видели такие IDEF0 модели, в которых принцип модульности не выполняется. Смотреть на них страшно, ибо связи между функциями напоминают паутину (очень похоже на левую часть рисунка из книги по системной инженерии, не правда ли?).
Любопытно, но классики тоже писали про модульность:
«Впервые я использовал обозначение „SA-блок“, лежащее в основе того, что я гораздо позже стал называть структурным анализом (Structured Analysis, SA), в промежуточном отчете по созданию алгоритмического языка АРТв Массачусетском технологическом институте (МТИ) 30 лет назад. Это обозначение четко выражало одну важную идею, связанную с тем, что сегодня называется иерархической многоуровневой модульной системой. Каждый уровень представлял собой законченную систему (блок), поддерживаемую и контролируемую системой (блоком), находящейся над ней…»
Дуглас Т. Росс
Методология структурного анализа и проектирования (SADT)
Принцип модульности также может и должен использоваться и при структуризации модели процессов. И нужно отметить, что, в данном случае часто аналитики интуитивно уже его используют. Особенностью моделей процессов является наличие связей предшествования наравне со связями типа «вход-выход» между операциями. Связи предшествования в определенной степени можно считать аналогом интерфейсов между модулями. Принцип модульности при проектировании процессов выражается в том, что процессы на нижних уровнях модели могут иметь достаточно сложные диаграммы: с циклами и ветвлениями. А на верхних уровнях целесообразно выстраивать процессы линейно. Это позволяет получить все описанные выше преимущества модульности.
Принцип «автономности» при проектировании архитектуры организационной системы
Наверное поэтому, в существующих подходах эти два принципиально разных вида деятельности принято… смешивать. Нередко можно увидеть рекомендуемый фреймворк, в котором к «процессу по производству чего-либо» (понятие «производство» в данном контексте используется в широком смысле) приложен процесс по улучшению этого процесса.
Схема сознательно содержит ряд распространенных логических ошибок.
Но, если мы для каждого процесса будем идти таким путем, то как это скажется на объеме и понятности модели? А насколько с точки зрения здравого смысла корректно смешивать и показывать в одной модели, как мы едем на автомобиле и одновременно ремонтируем его? Или как работает кофеварка и как она себя улучшает? В технических системах это кажется абсурдным. Но в моделях организации это является распространенным подходом.
Разобраться с этой проблемой нам снова поможет системная инженерия. В ней существует такое важное понятие, как жизненный цикл (ЖЦ) системы. Один из простых вариантов жизненного цикла выглядит так (ISO 15288:2002 Life Cycle Management — System Life Cycle Processes, редакция именно 2002 года):
Жизненный цикл системы отражает простую идею. Система проходит через разные стадии воплощения: концепция, проект, материальное воплощение; затем она функционирует и обслуживается; и в конце утилизируется. Согласно идеям системной инженерии каждую стадию ЖЦ системы должны обеспечивать другие системы — обеспечивающие (Enabling Systems). Это отражено на следующей, более сложной схеме:
Взаимодействие системы с типовыми обеспечивающими системами
Из этой схемы мы можем почерпнуть следующие мысли:
Попробуем применить данный подход к компании. Начнем с первой системы.
Это наш продукт, который мы передаём внешнему клиенту. Чтобы произвести продукт (обеспечить их стадию «производство»), нам нужен «завод» (будем называть его на схеме Операционной системой), который может принять заказы, произвести продукты и отгрузить их клиентам, заниматься обслуживанием продуктов и утилизацией (сейчас актуально думать о всем ЖЦ продукта, будем думать и мы в обобщенной схеме). Ограничим возможности завода: он может только работать по предписанной технологии, производя заданную линейку продуктов и ничего больше. Сам себя он развивать не может. Впрочем, как и продукты, сами себя они развивать не могут.
В обобщенной схеме левая граница зоны ответственности Операционной системы включает в себя часть стадии ЖЦ Продукта «Разработка». В зависимости от отрасли и серийности производства эта граница может смещаться как на стадию «Замысел», так и не затрагивать стадию «Разработка» совсем.
Пример 1: В ИТ-компании стадия «Разработка» и, почти целиком, стадия «Замысел» входят в зону ответственности Операционной системы, т. к. сайт — это во многом эксклюзивный продукт (граница смещается влево). И для операционной системы производство сайта является «обычным делом», ради которого она спроектирована и создана.
Пример 2: На автомобильном заводе модель автомобиля проектируется заранее целиком. Даже если мы говорим про возможность выбора опций автомобиля клиентом, сам перечень опций — фиксирован. Поэтому фиксировано и возможное множество конструкций автомобиля. Поэтому Операционная система не участвует в стадии «Разработка» продукта (граница смещается вправо).
Мы получили первую минимально работоспособную схему. Построенный «завод» может без изменений производить заданный перечень продуктов на протяжении заданного срока (месяц, год, 10 лет — неважно). Мы можем для этого минимально необходимого функционала создать свою простую модель. Этим мы займемся чуть позже.
Расширим задачу. На практике нашему «заводу» может потребоваться техническое обслуживание: профилактика и замена сломавшихся частей. Это стадия ЖЦ «Обслуживание», но уже для завода. Кто будет этим заниматься? Ну конечно же… система! Отразим Обслуживающую систему, которая будет заниматься обслуживанием завода:
Замечательно! Теперь наш завод может работать, вечно производя заданный перечень продуктов!
А откуда берутся Производственная и Обслуживающая системы? Наверное, их делает… еще одна система! Отразим этот факт на схеме:
Система развития замышляет, проектирует и производит Операционную систему под определённую продуктовую линейку. Ведь невозможно создать завод, который может производить всё что угодно. Поэтому представление о продукте должно появляться раньше начала проектирования Операционной системы.
Также Система развития замышляет, проектирует и производит Обслуживающую систему под определенную Операционную систему. А также может обеспечивать стадию «Замысел» и «Разработка» продукта.
Пример 1: В ИТ-компании, занимающейся разработкой сайтов, небольшая начальная часть стадии «Замысел» Продукта входит в зону ответственности Системы развития, т. к. в силу эксклюзивности продукта мы можем изначально задать только продуктовую линейку (классы продуктов), которую мы планируем выпускать. Зная продуктовую линейку, мы можем сделать проект Операционной системы, в которой опишем, как мы будем создавать сайты, а также можем выдвинуть требования к квалификации персонала. Далее Продуктом будет заниматься уже Операционная система и ее персонал.
Пример 2: На автомобильном заводе Система развития обеспечивает стадии «Замысел» и «Разработка» продукта. Зная продукт, мы можем создать Операционную систему один раз на весь срок производства модели автомобиля.
На этой схеме уже стали видны границы Бизнес-системы, которую в данном случае можно назвать системноинженерным термином «система систем» (System of Systems).
Перерисуем наши умозаключения в таком компактном фреймворке, отразив на нем только системы и их границы:
На входе у Обслуживающей системы находятся ресурсы, необходимые для обслуживания, и части операционной системы. Этими частями может быть:
На выходе — части операционной системы, «инсталлированные» обратно в «завод».
Важно подчеркнуть, что Обслуживающая система не может менять архитектуру Операционной системы. Она может только ее «чинить».
Добавим, что на практике Обслуживающая система также занимается и обслуживанием самой Системы развития.
Система развития — это та система, которая создает и улучшает Операционную и Обслуживающие системы. А также полностью или частично придумывает и разрабатывает Продукты компании.
На входе у нее — Ресурсы для создания указанных систем и сами системы или их части. Это означает, что система развития «забирает» из систем их компоненты, модифицирует и возвращает назад. Этими частями могут быть как оборудование, так и персонал, который необходимо переподготовить.
Важным отличием данного фреймворка от других является то, что Система развития проектирует и персонал, и оборудование и ИТ-системы как одно целое. Это позволяет собрать эти элементы, протестировать и получить работоспособную систему (операционную или обслуживающую). Этот подход понятен для технических систем, но в моделях организации создание данных элементов почему-то рассматривают по отдельности, хотя работают-то они вместе! Это все равно, что автомобиль передать клиенту не целиком, а по отдельности: электропроводку, двигатель, топливную систему и кузов.
Полученный фреймворк поразительно напоминает 3 модели IDEF0 уровня А0, расположенные рядом. Пусть он будет для нас руководством к действию для создания Фреймворка деятельности компании в следующей главе.
Резюме
Принцип автономности заключается в том, что мы делим бизнес-систему на подсистемы, которые способны существовать друг без друга. Отношение между этими системами — не горизонтальные по входам и выходам, как в технологической цепочке, а вертикальные:
Не соглашусь с К.Марксом и выдвину тезис «Сознание определяет бытие». Сущности, которые мы видим в своей голове, влияют на реальность. Признав существование деятельности по развитию компании и определив ее границы, мы можем сделать следующий шаг — сделать вывод, что за нее должен кто-то отвечать.
Я рекомендую вменить ответственность за развитие руководителям всех уровней. Они должны тратить на эту деятельности часть своего рабочего времени. Причем на развитие — в первую очередь, а во вторую — уже на непосредственное участие в операционных процессах, если на это останется время.
По сути, руководитель играет две роли в двух системах:
Другие принципы декомпозиции
Но перед тем, как перейти к моделированию, давайте рассмотрим еще несколько общих принципов, которые могут нам далее оказаться полезными.
Жизненный цикл — декомпозиция по стадиям ЖЦ ключевого объекта рассматриваемой деятельности. Например: потребитель должен пройти через стадии:
«Некоторые системы в процессе функционирования непрерывно преобразуют свои входы в конечный продукт, как, например, при очистке нефти. Стратегия декомпозиции, основанная на отслеживании цикла „от рождения до смерти“ (называемого обычно „жизненным циклом“) для ключевых входов системы, может оказаться эффективной для описания подобных процессов. Например, модель „Питание семьи“, приведенная в приложении С, есть результат декомпозиции системы в соответствии с этапами превращения купленных продуктов в съеденные блюда. Мы рекомендуем применять эту стратегию, когда целью системы является улучшение одного из основных входов и когда вы легко можете определить последовательные стадии улучшения этого входа.»
Дуглас Т. Росс
Методология структурного анализа и проектирования (SADT)
Технологическая цепочка — декомпозиция деятельности по технологическим этапам на основе логических и физических принципов («не сделав, А, нельзя сделать Б»). Этапы связаны горизонтальными входами-выходами: следующему этапу нужны объекты, полученные на предыдущем этапе.
В качестве вспомогательного метода можно применять подход цепочки создания ценности. Но он не может использоваться как основной принцип, т. к. декомпозиция происходит с точки зрения потребителя, а не архитектора системы.
Важное внимание в модели деятельности архитектору необходимо уделять принципам запуска и синхронизации процессов.
Без синхронизации — процесс запускается, если у него на входе появился результат или пришел сигнал (в любой форме) на старт работы из предыдущего процесса.
Синхронизация без планирования — вытягивающая система на основе карточек «канбан». Известен в двух формах:
Синхронизация с планированием — предварительный расчет планов на заданный горизонт планирования на основе информации о длительности работ. Используется, когда необходимо синхронизировать множество работ между собой и получить минимальное общее время и/или затраты. В качестве примера можно привести масштабное планирование производственной деятельности по методу MRP2. Функция планирования при этом явно помещается в модель.
Любой из данных способов обеспечивает естественный поток работ без использования традиционной процедуры планирования традиционным руководителем. Вам необходимо выбрать только оптимальный принцип для того или иного вида деятельности.