8. Планирование

8.1 Предложенные и завершённые действия

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

Рисунок 8.1. Свойства действия.

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

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

Отдельные объекты фиксируют предложение и реализацию, чтобы можно было отслеживать различия.

Рисунок 8.2. Базовая структура планов и действий.

Пример: Я решил подготовить презентацию для OOPSLA 1 июля 1997 года, но не успеваю сделать это до 3 июля. Эти действия можно представить в виде предложенного действия с датой 1 июля и выполненного действия с датой 3 июля. Все остальные атрибуты предложенного действия одинаковы.

Мы можем предоставить производное свойство «состояние действия», чтобы было проще определить текущее состояние без навигации по различным структурам, которые записывают его состояние. На данном этапе в этом нет необходимости, но это станет ценным, когда мы рассмотрим дополнительные структуры позже.

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

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

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

8.2 Законченные и отмененные действия

До сих пор мы рассматривали, как предлагаются и начинаются действия, но не то, чем они могут закончиться. Очевидно, что действия либо преуспевают, либо терпят неудачу. Проблема в том, что часто мы не можем с уверенностью определить успех или неудачу, особенно в здравоохранении. Поэтому в этом разделе мы рассмотрим только два варианта завершения действий: завершение и отказ. Завершение происходит, когда действие выполняется в соответствии с планом. Любое рассмотрение успеха или неудачи оставлено для дальнейшего анализа (см. раздел 8.7). Это определение может быть слишком строгим для областей, отличных от здравоохранения, где успех легче оценить. Однако различие между выполнением действия в соответствии с планом и достижением цели все же ценно.

Рисунок 8.3. Завершенные и заброшенные действия.

Отказ — это полное и окончательное прекращение действия. Оно может произойти как до, так и после начала реализации действия. Отказ от предложенного действия — это решение не начинать его вообще.

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

Пример: Я решил лететь из Лондона в Бостон, рассчитывая прибыть в Бостон в 14:00. Рейс задержали, поэтому я прибыл только в 19:00. Это действие все равно было выполнено, потому что я прибыл в Бостон в тот же день. Задержка рейса означает, что оно не было успешным. Однако от предложенного действия — пойти поужинать в тот вечер — пришлось отказаться.

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

8.3 Приостановленные действия

Мы также можем откладывать действия, намереваясь продолжить их позже. В этом случае с действием связывается приостановка, как показано на рис. 8.4. Приостановка действует в течение своего периода времени (который может быть открытым). Если действие продолжается после окончания срока приостановки, то приостановка все еще существует, но уже не является отсрочкой, и действие продолжается.

Рисунок 8.4. Приостановка действий.

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

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

Пример: У меня есть предложенное действие — помыть посуду. Оно часто приостанавливается надолго, но я никогда не отказываюсь от него!

8.4 План

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

Рисунок 8.5 представляет собой диаграмму зависимости между предлагаемыми действиями. Такая структура полезна, когда действия всегда предлагаются как часть одного плана. Однако во многих ситуациях планы взаимодействуют. Когда врач составляет план лечения пациента, действия, входящие в этот план, используются медсестрами при составлении планов ухода. Нет ничего необычного в том, что у многих ухаживающих за пациентом лиц есть свои планы, и важно, чтобы эти планы были правильно составлены. Структура, показанная на рис. 8.6, поддерживает взаимодействие, позволяя ссылаться на действие в нескольких планах, а зависимости выстраивать между ссылками, а не между действиями.

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

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

Такая структура позволяет ссылаться на действия в нескольких планах.

Рисунок 8.6. План, состоящий из ссылок на предлагаемые действия.

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

Пример: Мне нужно зайти в винный магазин, чтобы купить немного St. Emillion для ужина в субботу и Old Peculiar для вечеринки в воскресенье. Действие посещения винного магазина упоминается как в плане подготовки к ужину, так и в плане вечеринки. Ссылка на подготовку к ужину имеет зависимость, где посещение ужина является следствием, а посещение винного магазина — зависимостью. Ссылка на план вечеринки имеет зависимость, в которой начало вечеринки является следствием, а посещение винного магазина — зависимостью.

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

Модель на рис. 8.6 представляет собой простую поведенческую мета-модель. План — это описание предполагаемого поведения, поэтому здесь уместна техника поведенческого моделирования. Мы можем использовать любую технику поведенческого моделирования. Сначала мы представляем технику с помощью её мета-модели. Затем мы привязываем действия мета-модели к объекту плана и к предлагаемым действиям. Мы должны выбрать такую поведенческую модель, которая была бы сложной, но не чрезмерно сложной.

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

Рисунок 8.7. Планы замены.

Пример: У меня есть план купить хлеб в «Райском саду» и сыр в «Хлеба и круга». Вместо этого я планирую купить хлеб на вынос в Jae's.

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

Мы можем планировать план, а можем осуществлять сложные действия без явного плана.

Рисунок 8.8. Планы как действия и составные действия.

Мы можем рассматривать план как способ объединения действий. Например, полный анализ крови можно представить в виде плана, в котором каждый компонент измерения является предполагаемым действием. Однако это очень тяжелое представление. Структура, показанная на рис. 8.8, также позволяет разложить действие на составляющие действия, но она дает два способа представить действия как часть более крупного действия: использование ассоциации родитель-компонент хорошо подходит для простых случаев, а использование плана — для более сложных. Мы можем ограничить ассоциацию родитель-компонент иерархией, чтобы для простых случаев использовалась только ассоциация родитель-компонент.

8.5 Протокол (Protocol)

Стандартные операционные процедуры организации — это общие действия, выполняемые много раз практически одним и тем же способом. Мы можем описать эти общие действия (протоколы), с помощью конструкций, аналогичных тем, которые мы использовали для планов, как показано на рис. 8.9. Шаблоны планирования, как и другие шаблоны в этой книге, можно разделить на уровни знаний и операционные уровни. Операционный уровень описывает повседневные планы и действия. На уровне знаний находятся протоколы, описывающие стандартные процедуры, которыми руководствуются на операционном уровне.

Это такая же структура, как и для планов — простая поведенческая мета-модель.

Рисунок 8.9 Структура протоколов.

Есть несколько интересных различий между уровнем знаний и операционным уровнем в структуре. Использование иерархической структуры гораздо менее полезно на уровне знаний. На протокол может ссылаться множество других протоколов; трудно придумать случай, когда ограничение было бы полезным. Часто мы можем эффективно представлять действие как часть другого действия в случаях, когда мы хотим объединить действия регулярным образом, например, измерение как часть полного анализа крови.

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

Протокол не обязательно должен быть детализирован компонентами. Протокол может быть просто «именем/названием». Это могут быть описания, страницы учебников, веб-страницы, даже видео, на котором кто-то выполняет особенно сложную хирургическую процедуру. Ссылки на протокол могут просто описывать компоненты без каких-либо зависимостей. Некоторые протоколы могут быть полностью закодированы в компьютере, и в этом случае они становятся частью программного обеспечения. (Программный протокол — это протокол, который закодирован в программе, а не протокол в смысле «коммуникационного протокола»).

Мы можем формировать действия из сложного протокола двумя способами. Самый простой способ — использовать ассоциацию родитель-компонент. Эта техника хорошо работает, когда все действия компонентов происходят в четко ограниченный промежуток времени, и никто не хочет разделять действия компонентов. Сначала мы создаем предлагаемое действие для всего протокола и указываем действия компонентов только в том случае, если нам нужно указать конкретные свойства, такие как время или ресурсы. (Если таких свойств много, то следует использовать план). Если все действия выполняются одной и той же стороной примерно в одно и то же время, достаточно родительского действия. Для каждой ссылки на компонентный протокол создается компонентное действие; то есть протокол, выполняемый три раза в рамках родительского протокола, даст три компонентных действия; любые зависимости будут существовать точно так же, как в протоколе.

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

Рисунок 8.10. Взаимосвязь между действиями, планом и протоколом.

При формировании действий на основе протокола обычно используются планы на более высоких уровнях протокола и ассоциации родитель-компонент на более низких уровнях.

8.5.1 Планы и протоколы в виде графов

Мы также можем представить план в виде направленного ациклического графа (DAG) предлагаемых действий. Дуги на графе соответствуют зависимостям между ссылками на действия. Каждый план имеет свою отдельную структуру графа. Мы можем компактно представить это на рисунке 8.11. По сути, это еще один ассоциативный паттерн в стиле, описанном в главе 15.

Рисунок 8.11. План как направленный ациклический граф (DAG) предлагаемых действий.

Однако, чтобы применить это понятие к протоколу, мы не формируем DAG дочерних протоколов. Вместо этого мы формируем DAG ссылок на протоколы, как показано на рис. 8.12, потому что один протокол может появляться как более чем один шаг в другом родительском протоколе. Этого нельзя сказать о плане из-за ограничения уникальности, показанного на рис. 8.6. Таким образом, базовая форма для шаблона ассоциации DAG включает типы зависимостей (с ограничением) вместе с тем фактом, что элемент в DAG может появляться только как один узел в DAG.

Рисунок 8.12. Протокол с использованием группы DAG.

Если мы используем граф для структуры плана, мы теряем возможность построить ассоциацию между ссылкой на план и ссылкой на протокол, как показано на рис. 8.10. Естественно, мы все еще можем иметь версию DAG в качестве производного отображения. Оно будет включать в себя знание о выведении дуг графа.

8.6 Распределение ресурсов

Вторая важная часть планирования — распределение ресурсов. Основное различие между предложенными и реализованными действиями заключается в том, как они используют ресурсы. Реализованное действие будет фактически использовать выделенные ему ресурсы. В предлагаемом действии некоторые ресурсы будут зарезервированы. На рисунке 8.13 распределение ресурсов представлено в виде количества некоторого типа ресурсов. Ресурсы могут быть забронированы только одним действием и использованы только одним действием.

Предлагаемые действия резервируют ресурсы, а реализованные действия используют ресурсы.

Рисунок 8.13. Использование ресурсов в действии.

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

Пример: Распределение ресурса «10 галлонов апельсинового сока» имеет количество «10 галлонов» и тип ресурса «Апельсиновый сок».

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

Некоторые ресурсы не расходуются, например оборудование, помещения и люди. Человек ни в коем случае не расходуется в результате действия (хотя после написания этой книги я задаюсь этим вопросом). Однако мы можем сказать, что время человека расходуется. В этом случае тип ресурса — человек, а количество — время. Таким образом, то, что я потратил пять часов на какое-то действие, является расходованием пяти часов моего времени.

Это слишком индивидуальный взгляд на типы ресурсов. Типы ресурсов, которые лежат на уровне знаний, чаще всего указывают на вид вещи, а не на саму вещь. Проекты, над которыми я работаю, требуют пяти часов работы опытного OO-моделиста, а не меня в частности. Хотя некоторые люди достаточно уникальны, чтобы быть типами ресурсов сами по себе, большинство из нас, простых смертных, всего лишь одни из многих.

Поэтому при планировании требование звучит так: «Нам нужно пять часов работы OO-моделиста». На определенном этапе процесса планирования это решается путем резервирования пяти часов для меня, конкретного экземпляра типа ресурса. Это подразумевает два уровня распределения ресурсов: общий, где указывается только тип, и конкретный, где указывается конкретный человек.

На рис. 8.14 человек назван активом. Активы классифицируются по типам активов, которые являются разновидностью типов ресурсов. Разница между конкретным типом ресурса и общим типом ресурса заключается в том, что первый связан с активом, а второй — с типом ресурса, который для актива будет типом актива. Временной ресурс — это конкретное распределение ресурсов актива. Он может иметь не только количество времени, но и конкретный временной период. Этот период может быть производным от действия, которое создает или использует временной ресурс, или может быть отдельным.

Конкретные распределения называют конкретный актив, который был использован или забронирован. В общих распределениях указывается только тип актива.

Рисунок 8.14. Распределение ресурсов для активов.

Пример: На пару часов в небольшом конференц-зале запланировано проведение совещания по моделированию. Изначально это представлено в виде предлагаемого действия, в котором содержится общее распределение ресурсов. Тип ресурса общего распределения ресурсов — это тип актива «Малый конференц-зал». Количество выделенного общего ресурса — два часа. Позже фактический конференц-зал будет забронирован как Q9. Это переклассифицирует (или заменяет) общее распределение ресурсов на временный ресурс в виде двух часов актива Q9. Если предполагаемое действие встречи забронировано между 14:00 и 17:00 во вторник, то этот временной период является производным временным периодом распределения Q9. Если последний час встречи будет проходить в пабе, то с временным ресурсом будет связан временной период с 14:00 до 16:00 вторника.

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

Пример: Если в конференц-зале Q9 есть проекционное оборудование, его можно классифицировать и как малый конференц-зал, и как зал для презентаций. Его нельзя забронировать как то и другое одновременно с помощью отдельных действий.

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

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

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

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

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

Разрешать ли общее распределение ресурсов активов на реализованные действия, зависит от конкретной задачи. Если потребности домена удовлетворяются знанием того, что потребовалось два часа работы OO-моделировщика, не зная, какого именно, то общее распределение типов активов должно быть разрешено. Этот вопрос может зависеть от типа актива. Например, политика больницы может диктовать, что все реализованные распределения консультантов должны быть конкретными, хотя санитары могут быть распределены в общем виде.

Мы можем использовать специфическое распределение ресурсов с расходными материалами, если нас волнует удаление расходного материала из некоторого конечного хранилища, которое мы должны отслеживать. В таких случаях мы хотим сказать, что расходный материал взят из конкретного хранилища этого расходного материала, как показано на рис. 8.15. Холды могут быть организованы по-разному, в зависимости от процесса отслеживания ресурсов, который я здесь не рассматриваю. Однако стоит сказать, что холдинг можно рассматривать как счет, а распределение ресурсов — как запись, следуя подходу, описанному в разделе 6.14.

Рисунок 8.15. Разрешение специфического распределения расходных материалов.

Распределение ресурсов также может использоваться протоколами для описания ресурсов, необходимых для выполнения протокола. В этом случае мы используем общие распределения ресурсов.

Пример: Для приготовления чапати (индийского хлеба) вам понадобится 1/4 чашки муки, 1/8 чашки воды, 1/4 столовых ложки масла и щепотка соли. Это можно представить в виде четырех общих распределений ресурсов.

8.7 Функции старта и результата

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

Рисунок 8.16. Связи между наблюдением, планом и действием.

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

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

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

Функции начала указывают условия для начала действия, а функции результата — цели и побочные эффекты.

Рисунок 8.17. Использование функций начала и результата на уровне знаний.

Пример: Протокол добавления масла отображается функцией запуска с аргументом низкого уровня масла.

Пример: Бета-блокаторы являются средством лечения гипертонии и стенокардии, но их не следует применять, если у пациента астма. Это приводит к трем функциям запуска, все из которых указывают на лечение бета-блокаторами. (Лечение бета-блокаторами — это протокол с распределением ресурсов типа «бета-блокатор»). Две стартовые функции, одна с аргументом гипертония и одна с аргументом стенокардия, имеют простое тело без обработки, что является простым указанием. Третья имеет аргумент астма и является телом логического отрицания. (Мы могли бы иметь подтип стартовой функции контр-индикация, но все зависит от того, как обрабатываются аргументы).

Функции результата работают аналогично. Снова на вход подается комбинация протоколов и концепций наблюдения. Результатом являются два набора концепций наблюдения. Одни концепции наблюдения представляют собой целевое использование протокола, то есть эффекты, которые представляют собой цель протокола. Другие концепции наблюдений — это побочные эффекты. Протокол может иметь множество результатов. Они могут отражать другие протоколы или концепции наблюдения, которые могут быть у пациента в это время. Они вводятся как аргументы, унаследованные от функции знаний.

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

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

Ссылки

1. Cairns, T., A. Casey, M. Fowler, M. Thursz, and H. Timimi. The Cosmos Clinical Process Model. National Health Service, Information Management Centre, 15 Frederick Rd, Birmingham, B15 1JD, England. Report ECBS20A & ECBS20B http://www.sm.ic.ac.uk/medicine/cpm, 1992.

2. IMC. Common Basic Specification Generic Model. National Health Service, Information Management Centre, 1992.