Подходы к описанию деятельности
Рассматривая жизненный цикл как набор актов деятельности, мы имеем возможность при его описании применить подходы, предложенные в рамках теории производства (Theory of Production). Лаури Коскела (Lauri Koskela), в попытке сформулировать эту теорию, на основе исторического анализа выявил три различных способа концептуализации производства, которые использовались и развивались на понятийном уровне в XX веке [1].
Первый способ, трансформационный, предлагает рассматривать производство как трансформацию исходных сущностей (inputs) в конечные сущности (outputs). Управление производством приравнивается к декомпозиции совокупной трансформации на элементарные трансформации или дела (tasks) и выполнению этих дел с максимальной эффективностью. Этот вариант концептуализации основан на идеях, заложенных в экономическую теорию Вальраса (Walras) и в рамки научной организации труда Тейлора (Taylor), который выделял понятие дела. На этом традиционном подходе основаны push-методы управления производством: MRP, MRP II, APS, метод критического пути (CPM).
Второй способ основан на концепции потока (flow) и представляет производство как поток ресурсов во времени и пространстве направленный к их целевому состоянию, т.е. готовому продукту. Соответственно, помимо трансформации рассматриваются транспортировка, ожидание, и проверка. Управление производством приравнивается к минимизации доли этапов производственного потока, не приносящих пользы. Гилбрет (Gilbreth) выделил эти этапы в рамках потока в 1922 году. Позже Шинго (Shingo) развернул критику трансформационного подхода, в рамках которой обосновал потоковый подход. На этом подходе базируются pull-методы, лежащие в основе гибкого производства, теории ограничений, управления проектами на основе критической цепочки (critical chain), подхода LastPlanner.
Третий способ основан на концепции создания ценности (value generation) и представляет производство как превращение нужд заказчика в продукты, которые их удовлетворяют. Управление производством приравнивается к переводу этих нужд в спецификацию решения и последующее производство продуктов, отвечающих требованиям спецификации. Такая концептуализация была предложена Шухартом (Shewhart) в 1931 году, во время становления дисциплины управления качеством. Позже ее развили Левит (Levitt) и Друкер (Druker). Движение за качество основано на этом способе концептуализации производства. Одним из примеров применения этого способа являются Issue Tracking системы.
К трем описанным способам концептуализации производства мы можем применить два фундаментальных метафизических подхода к рассмотрению окружающего мира [2]. Это вещный (thing-based) и процессный (process-based) подходы. Вещный подход рассматривает статические объекты в дискретные моменты времени. Он отвечает на вопросы о том, какие вещи и где находятся, почему они там, какая декомпозиция этих вещей на части. Неопределенность при таком подходе - отклонение. Процессный подход обязательно включает рассмотрение времени. Он выясняет, что и когда случилось, почему именно тогда, каков был контекст тех событий, а учет эмерджентности и неопределенности встроены в рассуждения. Для интеграции способов рассмотрения производства необходимо выбрать один из подходов.
По сути, концепция трансформации связана с изменением и становлением во времени. Однако определение трансформации данное в экономической теории представляет ее как взаимосвязь между исходными и конечными сущностями, которые понимаются как вещи. Сама трансформация представляется как черный ящик, хотя мы можем его декомпозировать на частные трансформации (дела). Таким образом, трансформационная точка зрения обходит проблему отображения изменения во времени, описывая переход из одного дискретного момента времени, представленного набором вещей, в другой момент времени, представленный другим набором. Очевидно, что этот способ неявно основан на вещном подходе.
Предположения, на которых основано такое рассмотрение трансформации, могут быть подвергнуты критике [3]. Первое предположение утверждает, что трансформация является черным ящиком, который только может быть декомпозирован на другие черные ящики. Результатом этого является отказ от рассмотрения теорий, которые могут быть обнаружены при рассмотрении содержимого такого ящика. В итоге технология выполнения дела и компетенции, требуемые для этого, выводятся за рамки управления производством. Второе предположение утверждает, что все дела, независимо от уровня декомпозиции, имеют одинаковые характеристики. Из этого следует, что те же самые принципы управления могут применяться в разных ситуациях, но тогда мы не можем рассматривать различия между множеством ситуаций, возникающих при производстве. Третье предположение о том, что дела независимы друг от друга, и каждым из них можно управлять, не принимая остальные во внимание. Но, к сожалению, тогда мы не можем рассматривать взаимосвязи между делами. Такой вещной подход к трансформации затрудняет ее интеграцию с концепциями потока и создания ценности, которые базируются на процессном подходе.
Для традиционных методов управления, основанных на концепции трансформации и, соответственно, вещном подходе, центральным является цикл планирование-исполнение-контроль, в котором планирование играет доминирующую роль. Отсюда термин управление как планирование (management-as-planning), критика которого развернулась в конце XX века [3]. Во-первых, оно не поддерживает полное и актуальное описание мира и действий, который требуется в нем предпринять. Во-вторых, оно предполагает, что организация четко разграничена на сектор менеджеров и сектор исполнителей, а это приводит к централизованному управлению. В-третьих, план передает дела на выполнение без учета состояния производственной системы. Кроме того, управление как планирование тесно связано с пониманием контроля как коррекции, которое также несет в себе ряд проблем. Такое понимание контроля усиливает ограничения вещного подхода и показало свою неэффективность. Интересно, что даже в военной отрасли заметен постепенный переход от централизованного управления и контроля к распределенным операциям [4].
На основе приведенной критики мы делаем вывод, что три приведенных способа концептуализации, и в первую очередь трансформационный, должны быть интерпретированы в соответствии с процессным подходом. Это можно сделать, заменив трансформацию концепцией работы. В конце концов, трансформация реализуется через работу людей и машин. Процессный подход к трансформации снимает ограничения, наложенные предположениями, лежащими в основе ее вещного представления. Это позволяет раздельно рассматривать теории макропроцессов и технологии и требуемые навыки уровня дел (микропроцессов), а также различия между делами и их взаимосвязи. Процессная интерпретация трех перспектив производства выделяет следующие аспекты:
С точки зрения работы рассматривается взаимодействие ресурсов (людей и машин) и материалов: нас интересует, что ресурсы делают и достигают;
С точки зрения потока рассматривается пространственное и временное движение материалов (или информации), т.е. логистика;
С точки зрения создания ценности рассматривается проектирование и производство продуктов, соответствующих требованиям заказчика.
Стандарт ISO 42010 (Рекомендованная практика архитектурного описания программоемких систем) [35], разработанный для управления архитектурным описанием сложных систем, позволяет установить, что у деятельности, а значит и у ЖЦ и его практик, как у любой системы, есть одна или несколько заинтересованных сторон (stakeholders). Каждая из этих сторон обычно имеет набор интересов (concerns), связанных с системой, и стремится их удовлетворить. Для удовлетворения каждого из интересов создаются отдельные группы описаний (views) системы. По сути, группа описаний представляет систему с определенной точки зрения, а набор групп образует полное описание системы. Соглашения, по которым группа описаний создается, отображается и анализируется, устанавливаются методом описания (viewpoint). Тем самым метод описания определяет языки, включая нотации, описания или типы продуктов, применяемые для описания группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к моделям этой группы. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам. Каждая группа создается в соответствии со своим методом.
Описание деятельности с разных упомянутых точек зрения используется разными заинтересованными лицами и составляется из разных групп описаний. Описание с точки зрения создания ценности принимает вид набора требований разного рода (спецификаций). Описание деятельности с точки зрения выполняемой трансформационной работы интересует инженеров и представляется в виде процессной группы описаний. Логистика интересует менеджеров проектов, и описывается с помощью проектной группы описаний.
Процессная группа описаний
Эта группа описаний, которую также уместно называть технологической или инженерной, отражает правильную последовательность операций, каждая из которых заключается в применении метода в нужный момент жизненного цикла системы. Эти описания используются инженерами, непосредственно выполняющими работу над системой.
Для выполнения работы им требуется описание набора актов деятельности. Должны быть описаны сущности и информация, требуемые на входе производимых операций и получаемые на выходе. Эти входы и выходы обладают набором состояний, которые специфицируются с указанием правил перехода из одного состояния в другое. Распределение работ должно поддерживаться описанием ролей, которые включают в себя информацию о требуемых компетенциях и квалификации. Методы, сопровождаются руководствами (guidance), которые могут принимать разную форму и предоставляют информацию о том, как и в какой ситуации надо применять метод.
Интерес инженеров к описанию технологической цепочки стал причиной появления и распространения ряда методов процессного описания. В момент зарождения процессного метода описания получили популярность методы функционального разбиения IDEF0 для описания «логической последовательности» дел, и описания процесса IDEF3 [20, 21] для описания развертки во времени. IDEF0 – это метод и язык, являющийся вариантом метода структурного анализа и проектирования (Structural Analysis and Design Technique, SADT), возникшем в конце 60-х годов прошлого века. IDEF0 отражает логические отношения между работами, но не позволяет рассматривать временную последовательность. Позже появился IDEF3, документирующий технологические процессы. В нем предоставлена возможность описывать различные сценарии выполнения работы и описывать состояния объектов и переход между ними. IDEF0/IDEF3 успешно дополняют друг друга и широко использовались системными инженерами. Однако, ввиду ряда ограничений, прежде всего отсутствие формальной теоретической модели, а также отсутствия средств для описания артефактов и потоков информации, они теряют свою популярность.
Идея необходимости множества групп описаний привела к появлению языка UML, поддерживающего одновременно пять групп описаний (пять типов диаграмм). Для описания процессов могут использоваться UML диаграммы активности и вариантов использования (Use Case diagram, Activity diagram). Язык SysML, основанный на UML, предлагает расширение диаграммы активности, предоставляющую возможность моделировать потоки физических элементов или энергии. По сути, диаграмма активности – это вариация диаграммы состояний (State Diagram), где состояния заменены на акты активности, а переходы между состояниями представляют собой выполнение работы. Но диаграммы состояний не позволяют нам представить развертку процесса по времени в терминах, которые понятны человеку («раньше-позже-одновременно»). Этим же недостатком страдает и BPEL (Business Process Execution Language), который представляет собой машину состояний и ориентирован на машинное исполнение моделей процессов. В настоящий момент активно развивается и набирает популярность метод BPMN (OMG Business Process Metamodel and Notation). Готовится вторая версия этого стандарта, включающая возможность описания взаимодействия между исполнителями работ. BPMN поддерживает описание процессов на разных уровнях абстракции, имеет высокую выразительность и выражает процесс с использованием понятного людям представления времени.
Информация, предоставляемой процессной группой описания, не может удовлетворить нужды менеджеров, которые занимаются планированием ресурсов, потоков материалов, финансов и должны принимать решения об их распределении. Описания процессов не позволяют получить представление о проекте в целом и не предоставляют удобные для менеджеров способы оценки длительности проекта, «задействования ресурсов» во времени, прохождения «контрольных точек» -- того, что обычно связывают с проектной группой описаний, а не процессной. Нет выделения стадий проекта, определения точек принятия решений, функциональной иерархии, позволяющей распределять работы по ресурсам, расчета критического пути или критической цепи – все это затрудняет оценку рисков в ходе выполнения проекта и не дает менеджерам эффективно выполнять свою работу. С другой стороны, инженеры получают подробное описание требуемых трансформационных операций и руководства по их выполнению.
Проектная группа описаний
Для планирования ресурсов и управленческого контроля более приспособлена проектная или логистическая группа описаний, которая удовлетворяет нужды менеджеров. Они не заинтересованы в рассмотрении последовательности работ (микропроцессы). Для достижения целей проекта им требуется возможность распределения ресурсов по выполняемым работам и синхронизация работ во времени. Для этого используется функциональная иерархия, разбиение работ (work breakdown structure, WBS). С таким деревом работ удобно работать менеджерам. Становятся возможны группировка работ в стадии ЖЦ и определение контрольных точек для принятия решений, таких как пересмотр выделения ресурсов. Функциональная иерархия работ поддерживается большим количеством систем управления проектами и может отображаться в таких системах различными способами, например в виде диаграммы Ганта.
Диаграмма Ганта один из наиболее распространенных методов проектного описания. Она была разработана в 1910 году Генри Л. Гантом (Henry L. Gantt). По сути, она представляет собой объединение функциональной иерархии и временной шкалы (но не «процессной последовательности»). Это дает возможность оценивать время, требуемое для выполнения проекта в целом и отдельных его стадий, выявлять конфликты загрузки ресурсов. Отдельным объектом выделены контрольные точки (milestones), с помощью которых можно установить моменты проведения контроля и принятия решений.
Еще одним распространенным методом проектного описания является PERT (Program Evaluation and Review Technique). Этот способ анализа работ, необходимых для выполнения проекта, был разработан в 50-е годы прошлого века для упрощения планирования и составления графиков больших и сложных проектов. PERT-диаграмма представляет собой сетевой график, то есть граф, вершины которого отображают состояния некоторой системы, а дуги — работы, ведущиеся над этой системой. Такая диаграмма также предоставляет возможности для анализа времени, которое требуется для выполнения каждой отдельной задачи, а также помогает определить минимальное необходимое время для завершения проекта (это обычно называют «сетевым планированием»).
Менеджеры проектов с успехом применяют эти методы для решения собственных задач. Они могут описывать стадии и этапы ЖЦ, определять контрольные точки. Но применение только проектной группы описаний накладывает свои ограничения. Эти методы не предоставляют возможности описания артефактов, использующихся в проекте, в том числе планов, руководств, отчетов. Графики проектов не предусматривают четкого описания последовательности выполнения работ. Это реализуется в виде связей-зависимостей начала и окончания отдельных работ. Но такой подход не позволяет описывать, например, итерации свойственные ЖЦ сложных систем. Группа проектных описаний не предоставляет стандартного способа описания ролей. В системах управления проектами они представляются в качестве особого вида ресурсов. Эти недостатки указывают на то, что использовать только проектную группу описаний недостаточно.
|
