Распределенный подход как метод оперативного управления проектом

Размещено на http://www.allbest.ru/

Распределенный подход как метод оперативного управления проектом

В.К. Гулаков

А.К. Буйвал

П.А. Паршиков

В начале XXI века передовые страны мира, в том числе Россия, постепенно переходят от индустриального общества, основанного на жестком разделении труда, массовом производстве и обмене материальными продуктами, к постиндустриальному (информационному) обществу. В постиндустриальной экономике традиционная промышленность по показателям занятости и доле в национальном продукте постепенно уступает ведущее место сфере услуг, которая базируется преимущественно на обработке информации и производстве знаний. Основной сферой накопления капиталовложений во все большей мере становится человеческий капитал, как движущая сила бесконечных по своей природе информационных ресурсов (в отличие от ограниченных природных ресурсов).

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

Все участники проекта взаимодействуют на рыночных началах и пытаются извлечь максимальную выгоду. Взаимодействие в рамках проекта осуществляется на основе предварительно заключенных договоров, но никаких жестких схем взаимоотношений не существует. Генеральный подрядчик не может требовать от субподрядчиков выполнения своих пожеланий сверх того, что прописано в контракте; каждый агент в таком взаимодействии выступает как отдельный, независимый субъект. Кроме того, задача общей координации деятельности такой структуры усложняется приватностью процесса работы каждого агента. Никто кроме него самого не владеет информацией об имеющихся доступных ресурсах и возникающих проблемах. Общедоступной является лишь информация о возникших в работе задержках, влекущих за собой задержки в работе каждого последующего субподрядчика и задержку всего проекта.

Изменения в графике работ вездесущи и постоянны, и для их инициации достаточно возникновения проблем лишь у одного субподрядчика. Основная причина изменений - несоответствие между ресурсами, необходимыми для действий, и ресурсами, доступными субподрядчику [1]. Такое несоответствие ресурсов возникает, когда время действий не слишком хорошо подобрано в соответствии с доступными ресурсами ввиду, например, неожиданного выхода из строя оборудования, нехватки персонала, перемещения ресурсов в более прибыльный проект. И если субподрядчик не сможет обеспечить достаточное количество ресурсов по первоначально предполагаемой стоимости, то стоимость работы превысит ожидаемое значение. Так как основная задача любого субподрядчика -- поиск прибыли от использования собственных ресурсов, субподрядчик предпримет усилия для смягчения воздействия таких изменений [1].

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

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

Наиболее просты методы централизованной координации, в соответствии с которыми генеральный подрядчик обязан координировать субподрядчиков. Очевидно, что информация, необходимая для координации (вроде предпочтительных графиков субподрядчиков и сведений о ресурсах), не доступна генеральному подрядчику и хранится приватно субподрядчиком, что усложняет централизованную координацию [2]. Два крайних типа централизованной координации - строгая и свободная.

Цель строгой централизованной координации («железный кулак», tight centralized coordination, TCC) состоит в том, чтобы закончить проект вовремя. Субподрядчики должны закончить свои действия до последней даты окончания, заданной соответственно для каждой деятельности. Для некоторых субподрядчиков это может привести к превышению первоначально предполагаемой стоимости работы в том случае, если доступные ресурсы будут отличаться от требующихся. Центральный координатор может расценить такой перерасход по стоимости как ошибку субподрядчика при планировании ресурсов.

Цель свободной централизованной координации («невмешательство», loose centralized coordination, LCC) состоит в том, чтобы установить максимальное соответствие между необходимыми и доступными ресурсами в процессе выработки рабочего графика. Действия могут быть завершены, только если для этого достаточно ресурсов. LCC обычно задерживает проект, и затраты некоторых субподрядчиков могут увеличиться из-за задержки предшествующих действий, что в итоге приведет к отклонению требуемых ресурсов от первоначальных. Центральный координатор также несет убытки из-за задержки проекта.

Таким образом, TCC вынуждает субподрядчиков понести издержки за свои ошибки в планировании; LCC ставит субподрядчиков в гораздо худшую ситуацию, задерживая их действия, в результате чего некоторые субподрядчики получают выгоды, а другие проигрывают независимо от ошибки. Ни один из методов централизованной координации не рассматривает возможные альтернативы изменения графика. Кроме того, ни при использовании TCC, ни при использовании LCC не возникают конфликты графика, потому что центральный координатор поддерживает логику работы в процессе координации субподрядчиков. Однако если субподрядчики располагают только своими графиками работ и отношениями к работам других субподрядчиков, поддерживать логику работы становится довольно сложно. Поэтому необходима методология распределенной координации изменений графика проекта.

Распределенная координация изменений графика проекта состоит из трех компонентов [3]: график проекта, ограничения ресурсов и дополнительные затраты (рис. 1). Каждый субподрядчик обладает собственными ограничениями ресурсов и собственной информацией о дополнительной стоимости, но график проекта один для всех.

Рис. 1. Взаимодействие компонентов координации

Когда ограничения ресурсов вступают в противоречие с графиком проекта, они приводят к изменениям графика и возникновению информации о дополнительной стоимости. Субподрядчики будут пытаться понизить дополнительные затраты путем распределенной координации и принять такие изменения графика, которые понизят дополнительные затраты, связанные с ними, и усовершенствуют график проекта.

Для того чтобы субподрядчики могли принимать во внимание собственные действия и, кроме того, способствовать увеличению глобальных результатов, была разработана методология распределенной координации изменений графика проекта, основанная на функции общественного благосостояния. Функция общественного благосостояния -- это некая функция от индивидуальных функций полезности: . Функция общественного благосостояния дает способ ранжирования индивидуальных распределений, зависящий только от индивидуальных предпочтений, и является возрастающей функцией полезности каждого индивида. Таким образом, если увеличивается полезность агентов и при этом не уменьшается чья-либо другая полезность, то общество становится более обеспеченным [4].

Формализуем структуру распределенной координации изменений графика проекта следующим образом. Множество субподрядчиков должны выработать коллективное решение по ряду действий . Каждый субподрядчик должен знать полезность для своих альтернатив своих собственных действий, принимая во внимание дополнительные затраты других агентов от его действий и взвешивая их в сравнении со своими собственными дополнительными затратами. Определим функцию общественного благосостояния следующим образом:

,

где - дополнительные затраты для j-й деятельности, которая принадлежит i-му субподрядчику; - сумма дополнительных затрат для всех m действий n субподрядчиков.

В отличие от классической функции общественного благосостояния, являющейся суммой индивидуальных полезностей, данная функция общественного благосостояния _ сумма дополнительных затрат индивидуальных субподрядчиков, которая в действительности является отрицательной полезностью субподрядчиков и общественного благосостояния. В данной функции общественного благосостояния полезность субподрядчиков и общественное благосостояние увеличиваются, когда дополнительные затраты уменьшаются.

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

при

,

где _ дата окончания деятельности x; _ дата начала деятельности y; _ множество действий, которые должны следовать за деятельностью x.

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

В связи с огромным количеством взаимодействий между субподрядчиками в процессе распределенной координации изменений графика проекта каждый субподрядчик будет представлен программным агентом, способным к коммуникации с другими программными агентами. Агент обменивается сообщениями с другими агентами, чтобы оценить изменения и помочь реальному субподрядчику принять решение.

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

Мультиагентная модель используется для исследования децентрализованных систем, динамика функционирования которых определяется не глобальными правилами и законами, а наоборот, эти глобальные правила и законы являются результатом индивидуальной активности членов группы. Цель агентных моделей - получить представление о глобальных правилах, общем поведении системы, исходя из предположений об индивидуальном, частном поведении ее отдельных активных объектов и их взаимодействии [5].

Каждый программный агент в системе вычисляет полезность сделки по изменению времени работы, чтобы оценить результат такого изменения графика. Полезность сделки для агента определяется как стоимость его первоначальной работы минус стоимость новой работы, полученной им в результате сделки. Разница _ та польза, которую агент извлек из сделки [6]. В качестве сделки рассмотрим договоренность с другими затронутыми субподрядчиками об изменении времени работы.

Представим полезность изменения времени работы как реально оцениваемое число («деньги»), которое позволяет описать разницу между первоначальными затратами и затратами в случае альтернативных действий. Единицы полезности одинаковы для всех агентов, и агенты могут передавать свои единицы полезности другим агентам в качестве компенсации за невыгодные соглашения. Таким образом, представим полезность изменения времени работы как «перемещаемые деньги».

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

,

где - дополнительная стоимость ускорения, необходимая для того, чтобы ускорить деятельность ; - дополнительная стоимость задержки, необходимая для того, чтобы задержать последующую деятельность .

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

Если агент не может следовать своему графику с доступными ему ресурсами, у него есть два варианта. Первый вариант - закончить деятельность согласно первоначальному графику, но c более высокой стоимостью за день. Это может привести к затратам, необходимым для того, чтобы ускорить деятельность , в дополнение к первоначальной стоимости (). Второй вариант - увеличить время выполнения работы с более низкой стоимостью за день. Возможны также дополнительные затраты, необходимые для того, чтобы увеличить время деятельности . Поэтому агенты должны принимать во внимание два вида затрат для деятельности при вычислении стоимости ускорения () : _ общая стоимость для деятельности с первоначальным графиком и более высокой стоимостью в день; _ общая стоимость для деятельности с удлиненным графиком и более низкой стоимостью в день (рис. 2 а).

.

Если агент должен изменить свой график работы вследствие задержек предыдущих действий, у него есть два варианта. Первый вариант - выполнить работу с более короткой продолжительностью и более высокой стоимостью в день. При этом агент может понести затраты, необходимые для того, чтобы ускорить деятельность , в дополнение к первоначальной стоимости (). Второй вариант - выполнить работу с более длинной продолжительностью и более низкой стоимостью в день. Могут возникнуть дополнительные затраты в случае продления деятельности . Поэтому необходимы два вида затрат для деятельности при вычислении стоимости задержки (): _ общая стоимость для деятельности с более короткой продолжительностью и более высокой стоимостью в день; _ общая стоимость для деятельности с большей продолжительностью и более низкой стоимостью в день (рис. 2 б).

а) б)

Рис. 2. Два вида стоимости ускорения (а) и два вида затрат от задержек (б)

Если начало деятельности задержано, то

,

иначе .

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

Вариант изменения графика - это кортеж вида

(startDate endDate extraCost),

где startDate _ возможная дата начала деятельности; endDate _ возможная дата окончания деятельности; extraCost - дополнительная стоимость выбора данного варианта изменения времени деятельности. Деятельность может иметь один или более вариантов изменения графика.

Программные агенты в процессе переговоров передают единицы полезности, чтобы компенсировать другим агентам предоставление разрешения на изменение времени работы, которое для них в их локальном масштабе, возможно, не является оптимальным. Такая стратегия переговоров называется компенсационной. Если после получения посредством переговоров окажется, что больше, чем , т.е. полезность изменения времени работы положительна, то агент должен увеличить время работы и при этом передать часть другим агентам для компенсации невыгодных им соглашений.

Агенты модифицируют варианты изменения графика в процессе переговоров, чтобы отразить компенсацию. Дополнительная стоимость увеличивается у тех вариантов, за которые необходимо предоставить компенсацию другим агентам, и уменьшается у тех вариантов, в случае выбора которых будет получена компенсация от других агентов.

Агентам необходимо разработать протокол компенсационных переговоров, чтобы получить от последующих агентов и передать им единицы полезности в качестве компенсации за невыгодные соглашения. Протокол компенсационных переговоров и будет управлять взаимодействием среди агентов.

Компенсационные переговоры начинаются с базового графика проекта и направлены на то, чтобы агент предложил компенсацию другим агентам за затраты, которые понесут последние при изменении плана работ. Протокол переговоров определяет команды, являющиеся общими примитивными типами сообщений для агентов, и последовательность передачи, которая отображает обмен структурированными сообщениями между агентами, когда изменяются их состояния. Рассмотрим методологию мультиагентных компенсационных переговоров на примере сетевого графика работ (рис. 3 а) и соответствующей диаграммы PERT (рис. 3 б).

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

а) б)

Рис. 3. Диаграмма Ганта (а) и диаграмма PERT (б)

Предположим, что субподрядчики при распределении работ заявили, что будут обладать достаточным количеством ресурсов для того, чтобы точно следовать графику выполнения работ. Гистограмма ресурсов на рис. 4 а отражает необходимые для завершения действий ресурсы. Однако при приближении фактических дат выполнения работ доступность ресурсов изменилась. Предположим, что каждый субподрядчик пересмотрел доступность ресурсов (рис. 4 б).

а) б)

Рис. 4. Гистограммы ресурсов: а - требующихся; б - доступных ко времени выполнения

Согласно гистограммам (рис. 4), предпочтительные графики некоторых субподрядчиков отличаются от их первоначальных графиков. Например, субподрядчик а желает закончить действие А в 4-й день, так как не имеет достаточного количества ресурсов, чтобы закончить его в 3-й день. Некоторые из предпочтительных изменений графиков субподрядчиков показаны на рис. 5 заштрихованными по диагонали прямоугольниками.

Размещено на http://www.allbest.ru/

Рис. 5. Предпочтительный график для субподрядчиков

Следует отметить, что простой набор предпочтительных графиков субподрядчиков не гарантирует получение рабочего графика, так как ресурсы субподрядчиков независимы (в отличие от их графиков). Поэтому некоторые действия могут нарушить логику графика. Например, в 4-й день действие B стартует прежде, чем закончится действие A.

Основываясь на гистограмме ресурсов, предположим, что каждый субподрядчик подготовил варианты изменения графика для своих действий (табл. 1). Субподрядчики предоставляют своим агентам эти подготовленные заранее варианты изменения графика. Варианты в графе, отмеченной символом «*», - это первоначальные варианты, которые выполнимы, потому что дата начала очередной работы позже, чем дата окончания предшествующих работ. Вариант, отмеченный символом «**», включает убытки за двухдневную задержку проекта.

Таблица 1. Подготовленные субподрядчиками варианты изменения графика

По истечении цикла компенсационных переговоров подготовленные варианты изменения графика модифицируются. Выбранные для исполнения варианты помечены галочками (табл. 2).

Таблица 2. Выбранные варианты изменения графика

На рис. 6 а диагональной штриховкой показан итоговый график работ, полученный в результате компенсационных переговоров между программными агентами. На рис. 6 б изображена итоговая гистограмма ресурсов (диагональной штриховкой выделены дополнительно импортируемые ресурсы или время их сверхурочной работы).

Размещено на http://www.allbest.ru/

а) б)

Рис. 6. Итоговая диаграмма PERT (а) и итоговая гистограмма ресурсов (б)

Предложенный метод распределенной координации изменений графика проекта положен в основу разрабатываемой мультиагентной системы. Система строится с использованием мультиагентной среды Anylogic 5, предоставляющей инструмент для быстрого создания профессиональных агентных моделей в графической среде [5]. Система состоит из набора взаимодействующих согласно методологии агентов. Для взаимодействия со своими агентами субподрядчики используют разрабатываемый графический интерфейс пользователя.

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

Разрабатываемая агентная система, использующая для принятия решения предложенные субподрядчиками варианты изменения графика, позволит до начала выполнения работ скоординировать субподрядчиков. Таким образом, путем распределенной координации будет повышена эффективность использования ими ресурсов, что позволит успешно завершить весь проект.

В промышленности рассмотренный подход позволит повысить конкурентоспособность выполняемых проектов в результате улучшения графика, эффективного использования ресурсов, тесного взаимодействия среди субподрядчиков. Метод распределенной координации представляет собой основу для разработки мультиагентной системы планирования и управления, которая поможет субподрядчикам выбирать время действий, идентифицировать и анализировать собственные ограничения ресурсов в данном графике, предсказывать результат перепланирования действий, координировать различные перспективы планирования, сотрудничая в направлении лучшего решения.

Список литературы

координация управляющий субподрядчик

1. O'Brien, W. An economic view of project coordination / W. O'Brien, M.A. Fisher, J.V. Jucker // E&FN Spon. - London, 2000. - № 13. - P. 393-400.

2. Choo, H.J. Interactive coordination of distributed work plan / H.J. Choo, I.D. Tommelein // Proceedings of the Sixth Constructions Congress. - Orlando, 2000. - P. 11-20.

3. Oberlender, G.D. Project Management for Engineering and Construction / G.D. Oberlender. - New York: McGraw-Hill, 1993.

4. Вэриан, Х.Р. Микроэкономика. Промежуточный уровень. Современный подход: учеб. для вузов / Х.Р. Вэриан; пер. с англ. под ред. Н.Л. Фроловой. - М.: ЮНИТИ, 1997. - 767 с.

5. Карпов, Ю. Имитационное моделирование систем. Введение в моделирование с Anylogic 5 / Ю. Карпов. - СПб.: БХВ-Петербург, 2005. - 400 с.

6. Rosenschein, J.S. Designing conventions for automated negotiation / J.S. Rosenschein, G. Zlotkin. - San Francisco: Morgan Kaufmann Publishers, 1998.

Размещено на Allbest.ru