Известно, что большую часть решений в реальных бизнес-процессах принимают не высокие руководители, а простые инженеры, диспетчеры, бригадиры, специалисты разного профиля. Данные решения не являются определяющими, и каждое в отдельности не способно заметно изменить траекторию развития всей организации. Но в силу своей массовости и многообразия они способны любой бизнес как поднять до заоблачных высот, так и обрушить, довести до полного краха. Между тем принятие решений в условиях традиционных бизнес-процессов считается хорошо известной и отработанной темой, которой совершенно незачем уделять внимание в научных исследованиях, что ведёт к парадоксальной ситуации: множество исследователей разрабатывают неисчислимое число методов и методологии повышения эффективности принятия решений, а коэффициент полезного действия руководителя от всех этих методов практически не изменяется, организации непостижимым образом возрождаются из пепла или скучно и незаметно погибают при вполне нейтральной конъюнктуре. Возможно, имеет смысл немного сдвинуть фокус исследований в области управления с новых и частично неопределённых проектов и сфер деятельности, с высоких руководителей и ведущих разработчиков на вполне заурядных работников, которые своими ежедневными действиями, выбирая купить здесь или там, отправить в 9.00 или в 9.30, описать в технологии рабочую операцию или довериться опыту рабочего, определяют финальный успех всех великих строек, громких проектов и простых обычных организаций. При этом совершенно понятно, что система поддержки принятия решений для каждого мелкого клерка в рамках существующих подходов разорит любую организацию. Поэтому следует использовать метод экономии на масштабах, формируя комплексные решения для нескольких связанных задач. А для решения такой задачи следует проводить специализированное исследование управленческого аспекта бизнес-процессов организации, что требует специального аппарата для моделирования бизнес-процессов. Рассмотрим подходы к разработке концепции такого инструментария в данной статье.
На определённом уровне сложности методология перестаёт отвечать критерию сложности модели, т.е. становится ненамного проще оригинала. Для того чтобы избежать данной ситуации, необходимо обеспечивать баланс между адекватностью и сложностью модели. Рассматривается возможность формирования структуры основных бизнес-процессов и описания их взаимосвязи, с дальнейшим рассмотрением только целевого бизнес-процесса, в рамках которого возможно подробно смоделировать только функции, связанные с целевыми состояниями типовой ситуации.
Архитектурный аспект организации при проектировании систем поддержки принятия решений. Создание всего нового человеком всегда проходит ряд определённых стадий, что связано с особенностями его восприятия окружающей действительности [1]. Человек сначала создаёт образ желаемого, т.е. концептуальную модель, а потом детализирует эту модель до представления, подходящего для создания желаемого объекта, т.е. доводит модель до уровня детализации например, сборочного чертежа, принципиальной платы, поэтажного плана и т.д. Путь от концепции до детального представления обычно имеет несколько стадий, каждая из которых завершается созданием модели нового типа, являющейся раскрытием, декомпозицией более общей модели. Иными словами, формируется иерархия моделей: от простых и общих на верхних уровнях до самых подробных и перегруженных деталями моделей – архитектура. Причём правила создания таких сложных архитектурных моделей можно поделить на частные для каждого уровня модели, которые обычно определяют, что, как, где, с чьей помощью, когда и почему отражает модель, и на общие (метамодели), отвечающие как минимум ещё и на вопросы, каким образом связаны уровни моделей и как определить момент, когда нужно переходить на новый уровень.
Как известно, Захман определил Архитектуру проектируемой организации как «набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)» [2]. Кроме того, он предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture), демонстрирующую решение двух основных задач:
- логически разбить все описания Архитектуры на отдельные разделы для упрощения их формирования и восприятия;
- обеспечить возможность рассмотрения целостной Архитектуры с определённых точек зрения или соответствующих уровней абстракции.
Данная модель является, по сути, метамоделью онтологии организации и может быть представлена в виде таблицы, приведенной на рис. 1.
Данная модель была уникальна тем, что впервые представила процесс проектирования не как последовательность шагов жизненного цикла в функциональном аспекте, а в виде сложной многоаспектной архитектуры, которая имеет иерархическую структуру. Популярность модели обусловила даже включение её в стандарт программной и системной инженерии [3]. Однако при всех несомненных достоинствах данная метамодель весьма общая, неконкретная и ориентированная на отрасль разработки информационных технологий, поэтому требует адаптации для решения конкретных задач в виде предметной методологии. Таким образом, для проектирования систем поддержки принятия решений модель Захмана необходимо расширить и конкретизировать именно в аспекте метамодели, т.е. правил взаимоотношений между уровнями, поскольку управленческая задача сильно увязана с такими факторами, как общие и частные цели, важнейшие ограничения в виде правил, представленные в виде правил, а также с очень точной оценкой доступных лицу, принимающему решение, ресурсов.
Рис. 1. Модель Захмана
Исходя из этого, к функциональному аспекту, который учитывается большинством известных моделей, добавим аспект ресурсов, включающий:
- ресурсы потока, как нечто создаваемое, преобразуемое или затрачиваемое в процессе функционирования организации (энергия, сырьё, финансы, материалы, полуфабрикаты, продукция, входная и выходная информация, покупные программные компоненты и программные продукты, покупаемые услуги и оказанные услуги и т.д.);
- ресурсы исполнения, как нечто, с помощью чего становится физически возможным создание и преобразование в процессе функционирования организации (помещения, недра, инструменты, оборудование, оснастка, стенды, рабочее время исполнителей, сервисные или офисные программные продукты и т.д.);
- ресурсы интеллекта, как нечто, с помощью чего становится логически возможным создание и преобразование в процессе функционирования организации (квалификация, компетенции, творческие способности, организационные таланты, технологии, внедрённые практики, опыт, сохранённые знания в базах данных, базы знаний и т.д.);
- ресурсы культуры, как нечто побуждающее к созданию и преобразованию в процессе функционирования организации (корпоративная культура, информационная среда, системы мотивации, системы регламентации, корпоративные традиции, миссия организации и т.д.).
Кроме того, необходимо гораздо лучше учитывать правила, которые следует исполнять ЛПР, поэтому надо выделить в отдельный класс аспект правил (ограничений), который должен увязывать формализованные и неформальные правила с уровнями модели организации.
Наконец, важнейшую, к сожалению совершенно не оцененную роль, играют цели ЛПР. Важно понимать, что даже внешние цели, которые, казалось бы, вытекают из правил, уже не полностью совпадают с ними. Например, правило «согласовать документ как можно быстрее» вовсе не означает, что документ будет согласован в минимально возможные сроки, поскольку ЛПР может иметь несколько уровней документов с разными приоритетами, что обесценивает данное правило для документов с низким приоритетом. Кроме того, совершенно не ясно, являются ли другие дела ЛПР приоритетнее, чем подписание какой-нибудь служебной записки или нет. Ещё хуже дело обстоит с учётом индивидуальных целей ЛПР, связанных с психологическими потребностями. Это совершенно выносится за скобки организационных систем, что приводит к неэффективности, коррупции и многим другим организационным болезням. Поэтому, вне всяких сомнений, аспект целей должен учитываться наряду с вышеперечисленными.
Перейдём теперь к описанию уровневой онтологической методологии описания организационной системы для решения задач проектирования системы поддержки принятия решений, построенной на основе методологии Захмана и сходных подходов, описанных авторами ранее (например, [4]).
Особенности онтологического моделирования организационных систем при проектировании систем поддержки принятия решений. Предметная область, связанная с принятием решений, опирается на ситуационное моделирование [5] и понятие управленческой ситуации [6]. Определимся, что управленческая ситуация есть характеристика сложившегося состояния различных элементов организации и их отношений. Бизнес-процессы организации включают множество точек, в которых те или иные специалисты делают выбор из некоторого перечня альтернатив. Поскольку любые решения принимаются в определённой ситуации, которая связана с динамикой функционирования бизнес-процесса, то ситуации принятия таких решений назовём типовыми, т.е. хорошо известными и имеющими известные сценарии реакции на различные состояния.
В качестве базовых типов элементов организации будем рассматривать функции, ресурсы, правила и цели (связанные с назначением). Рассмотрим методологию моделирования систем поддержки принятия решений, которая предполагает формирование онтологии в виде иерархии моделей, на основе которых на уровне принятия решений возможно построить ситуационную модель организационной системы. Покажем наличие композиционного отношения между уровнями, благодаря которому уровневую модель можно рассматривать как онтологическую иерархию.
Первый уровень модели организации является декларативным, т.е. наиболее общим и представляет собой некоторый контекст, общее понятие. В наибольшей степени он соответствует понятию модели контекстного уровня функционального моделирования методологии SADT по стандарту IDef0 [7].
С нашей точки зрения, этот уровень соответствует двум верхним уровням модели Захмана, поскольку здесь с точки зрения системного подхода [8] концентрируются как знания о внешнем окружении организации (сфера действия в модели Захмана), так и знания о её основных компонентах (модель предприятия в модели Захмана). Если рассматривать этот уровень с позиций выбранных выше базовых типов элементов организации, то для модели организации (MG) получим:
- функции (FG) – наиболее укрупнённые виды деятельности организации, т.е. её наиболее общие бизнес-процессы;
- ресурсы (RG) – вся совокупность доступных ресурсов организации, как внутренних, так и внешних;
- правила (NG) – вся совокупность законов, стандартов, регламентов и прочих нормативных актов, которые действуют на организацию, её собственников, конкурентов и контрагентов;
- цели (GG) – весь комплекс наиболее общих целей собственников и высшего менеджмента организации, как выраженных в официальных документах, так и индивидуальных, зачастую, скрытых и слабо формализованных.
На теоретико-множественном языке это можно представить выражением
MGL = {FGL, RGL, NGL, GGL}. (1)
Причём в выражении (1) каждое множество функций, ресурсов, правил и целей представляет наиболее общее для организации, более соответствующее понятию класс, чем конкретному объекту.
Следует отметить, что коль скоро речь идёт о системе управления, то необходимо показать концептуальную модель организации функционирования организации на данном уровне. Обратимся к диалектике и рассмотрим согласно Гегелю спираль развития, которую проходит любая сложная система. Наиболее простое и емкое определение закона отрицания – отрицания Гегеля даёт широко известный цикл PDCA [9], который для данного уровня модели можно изобразить следующей схемой (рис. 2).
На втором уровне – уровне бизнес-процесса рассматривается некоторая целостная деятельность организации, которую характеризует повторяемость, наличие единоначалия, функциональная сложность и единство цели. На данном уровне логично использовать широко известное функциональное моделирование, немного дополненное целями, достигаемыми при выполнении каждой функции. Такая модель призвана демонстрировать взаимосвязь организационной структуры и реализуемой деятельности.
Модель на этом уровне допускает наличие вложенных функций, т.е. может иметь внутреннюю иерархию. Моделирование на функциональном уровне для создания онтологических моделей написано в [10].
Данный уровень соответствует третьему уровню модели Захмана – модели системы, поскольку концепция информационной системы строится на понятии бизнес-процесса, для которого она строится.
Рассмотрим уровень бизнес-процесса с позиций базовых типов элементов организации и для модели бизнес-процесса (MBP) получим:
- функции (FBP) – функции бизнес-процесса, рассмотренные на уровне, достаточном для запуска организационного взаимодействия;
- ресурсы (RBP) – вся совокупность доступных ресурсов бизнес-процесса, как внутренних, так внешних;
- правила (NBP) – стандарты, регламенты, положения, инструкции и прочие нормативные документы, значимые для бизнес-процесса и его участников;
- цели (GBP) – внешние цели, назначенные организацией бизнес-процессу, и индивидуальные цели его участников.
На теоретико-множественном языке это можно представить выражением
MBP = {FBP, RBP, NBP, GBP}. (2)
Причём в выражении (2) некоторые множества можно представить как подмножества модели первого уровня. Это в полной мере относится к функциям, правилам и внешним целям (GBPEx), т.е. справедливы выражения
FGL = {FBP}, (3)
NGL = {NBP}, (4)
GGL = {GBPEx}. (5)
К сожалению, множество ресурсов организации не декомпозируется на множества ресурсов бизнес-процессов, поскольку одни и те же ресурсы (например, помещения, мебель и т.д.) могут использовать как члены правления, так и вахтёры, а такие ресурсы, как личные связи членов совета директоров, невозможно корректно перенести на бизнес-процессы организации. Аналогичная картина с индивидуальными целями. Но в случае с целями возможен их учёт в виде дополнительных правил (NBPAdd) в соответствующем множестве, что позволит получить окончательный вид выражения (4) в следующем виде (6):
NGL = {NBP, NBPAdd}. (6)
Для декомпозиции ресурсов обычно выделяются их аспекты: кадровые, материальные, финансовые и т.д., для которых возможна корректная декомпозиция от уровня организации для уровня бизнес-процесса. Для модели конкретной системы это можно и нужно делать, но в рамках общих рассуждений мы эту проблему пока оставим, ограничившись выражением
RGL = f(RBP). (7)
Рис. 2. Цикл PDCA для уровня модели организации
Рис. 3. Цикл PDCA для уровня модели бизнес-процесса
Рассмотрим цикл Деминга для уровня бизнес-процесса (рис. 3).
Наиболее важным в аспекте анализа структуры управленческой ситуации является третий уровень – уровень модели состояния типовой ситуации (ситуационный уровень). Здесь решается задача определения и идентификации точек принятия решений, как некоторых специализированных состояний бизнес-процесса, в процессе реализации которых ЛПР осуществляет выбор из альтернатив. Известно, что ситуационная модель имеет структуру, похожую на функциональную, но рассматривает ситуацию, т.е. бизнес-процесс в некотором состоянии, предельно упрощённо, в момент выполнения разными исполнителями конкретных функций, в то время как функциональная модель показывает просто структуру этих функций.
Для моделирования здесь наиболее подходит метод метаситуационного моделирования (например, [10]), опирающийся на понятие метаситуации, которая ассоциирует каждое состояние с некоторым набором описывающих её понятий – глоссарием. Такая метаситуационная модель особенно удобна для типовых ситуаций, критерий принятия решений для которых известен. Тем не менее важную роль играют и состояния ситуации, связанные с различными отклонениями в бизнес-процессе, которые можно считать нетиповыми [11]. Отсутствие опыта работы с такими ситуациями является вызовом лицу, принимающему решения, и создаёт большие риски. Однако если предусмотреть контур экспертизы, т.е. привлечения экспертов к формализации описания ситуации и формирования прецедента решения, то появится возможность не только принять эффективное решение, но и сохранить опыт в некоторой базе знаний. В такой постановке задачи формируется интеллектуальный аспект данного подхода, который более подробно будет рассмотрен в последующих статьях.
Данный уровень более всего соответствует четвёртому уровню модели Захмана – физической модели системы, поскольку она, по сути, представляет модель, в которой вместо абстрактных элементов модели используют элементы, имеющие физический аналог. Например, логическая модель базы данных показывает взаимосвязи между абстракциями – информационными сущностями, а физическая – взаимосвязи между её таблицами и запросами. В этом аспекте рассматриваемый уровень для системы поддержки принятия решений есть уровень физической модели, в которой каждому состоянию ситуации можно сопоставить в некоторый момент времени конкретное состояние реальной системы, в которой ЛПР решает задачу выбора из определённых альтернатив (типовая ситуация).
Несмотря на то, что функциональная модель описывает структуру, а ситуационная – состояние этой структуры в момент времени, в нашем рассмотрении связь между уровнем бизнес-процесса и уровнем метаситуационной модели также является отношением композиции, поскольку ситуация рассматривается для некоторой функции бизнес-процесса, которая является его неотъемлемой частью. Нахождение в определённый момент времени в процессе реализации этой функции есть ситуация.
При этом правила физического моделирования отличаются, в данном случае отличаются появлением нового измерения – времени, которое должно учитываться в модели. Функции следует рассматривать как состояния в момент времени.
Следует заметить, что время исполнителя, затрачиваемое на выполнение функции, относится к ресурсам и не должно смешиваться со временем в понимании, как интервал времени в модели, фиксированный шаг на шкале, единица измерения.
Заключение
Подводя итог, можно заключить, что на основе модели Захмана и модели описания базовых элементов модели в формате функции – ресурсы – правила – цели вполне возможно формирование моделей, описывающих принятие решений в типовых ситуациях в виде комплексных онтологий, которые не только обобщают понятийный аппарат предметной области, но и привязывают его к бизнес-процессу (функция), управленческой задаче (цель или назначение), существующим ограничениям (правила) и времени, определяемому состоянием объекта управления, состоянием ресурсов бизнес-процесса, доступных для подготовки, принятия и реализации решения (ресурсы). Решению данной задачи будет посвящена следующая статья.