Функциональные требования в ИТ: принятие решений

Проблема принятия решений

Управление процессами построения систем в организациях, как минимум, принято рассматривать с позиции модели жизненного цикла:

ГОСТ Р ISO/МЭК 15288 - Процессы жизненного цикла систем.

Способы построения эффективной системы управления в организации тесно увязываются с уровнем автоматизации бизнес процессов управления, которые в свою очередь связаны с применением IT. Отметим, что такой способ построения напоминает метод «бритвы Оккама», в части подмены понятий в постановке задачи. Описывается не стандартизированный способ построения системы, а способ унификации описания способа построения, что само по себе является важной задачей. Этот факт подтверждает гармонизация модели жизненного цикла IT систем с вышеупомянутым стандартом:

ГОСТ Р ISO/МЭК 12207 - Процессы жизненного цикла программных средств.

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

Рис.1 Задача принятия решений

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

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

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

Участники процесса принятия решений

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

·         Лицо, принимающее решения (ЛПР). ·         Владелец проблемы. ·         Руководитель или член группы, принимающей решения. ·         Эксперт, профессионал прикладной области. ·         Консультант, аналитик.

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

Формализация способов принятия решений

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

·         Упорядочение альтернатив.

·         Распределение альтернатив по классам решений.

·         Выделение лучшей альтернативы.

Откуда берутся альтернативы и критерии оценки? – Из классификации предметной области. Они зависят от способов и методов классификации (или разделения на классы, подмножества).

Простые ответы на сложные вопросы

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

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

1.  Упрощение проблем, декомпозиция проблем и их независимое решение без анализа целостной картины.

2.  Удовлетворительные решения, выбор первой приемлемой альтернативы, проведение небольших изменений.

3.  Стремление избежать неопределенности, сокращение горизонта планирования и анализа.

4.  Сценарии привычных решений, соблюдение традиционных правил и процедур принятия решений, принятие типовых решений, эскалация решений и ошибок.

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

·         ограничение по тому, какого рода могут быть функции полезности

·         учёт стоимости сбора и обработки информации

·         возможность существования векторной функции полезности

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

Правильная формулировка задачи облегчает ее решение. Например,

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

2.  Как доказать полноту решения? Необходимо предоставить полно связную картину объектов, вовлеченных в проект модификации, и провести анализ этих объектов.

3.  Как сформировать, обеспечить ресурсное наполнение проектной команды? Для построения процедуры поиска необходимых ресурсов в социальных сетях необходимо иметь формализованную задачу, которая определяется на основе взаимосвязанных объектов из  информационной подмодели.

4.  Как обеспечить комплексность принимаемых решений? Простота и оперативность получения дополнительной информации понижают требования к уровню компетенции ЛПР в технологически сложных областях. Состав и связи объектов подсистемы обеспечивается наличием логически обоснованной процедуры построения подсистемы из общей информационной модели.

Информационная компонентная модель

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

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

·         Бизнес-архитектура

·         Архитектура данных

·         Архитектура IT-систем

·         Архитектура серверной и сетевой инфраструктуры

Рис. 2  Компонентная Модель функциональных требований

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

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

Рис.3 Архитектура данных для модели

На практике, для реализации подхода можно воспользоваться инструментальной средой MS SharePoint, Alfresco или другими подобными, в которых встроены все необходимые компоненты. В самом простейшем случае, для создания и демонстрации прототипа достаточно использовать на чуть более профессиональном уровне MS Office – MS Excel, MS Word и продуманную структуру хранения документов и файлов.

Пример построения информационной модели

Процедура построения информационной модели состоит из трех шагов:

1.    Описание бизнеса

2.    Описание IT

3.    Построение модели

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

Для построения информационной модели необходимо осуществить классификацию понятий и объектов, в соответствии с вариантами «проекций» (рис.4 и рис.5).

Спрос (Business Demand)
Стратегические цели	Стратегические цели
Инициативы	Подразделения
Методики	Функции

Рис.4  Варианты «проекций» потребностей бизнеса

Каждому объекту в таблицах «проекций» бизнеса и предложений IT присваивается приоритет, а между понятиями обозначаются связи.

Предложение (IT Supply)
Программы	Программные платформы
Инструменты	Программы и подсистемы
Технологии	Модули и конфигурации

Рис.5  Варианты «проекций» предложений IT

Процессу принятия решений соответствует установление связей между объектами и понятиями двух смежных уровней «проекций» потребностей бизнеса и предложений IT.

Требования к процессу составления модели

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

·    Неограниченный жизненный цикл модели, как минимум должен соответствовать модели жизненного цикла организации на временном горизонте ее существования.

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

·    Компактность и адекватность понятийной базы модели, возможность декомпозиции и агрегирования ее понятий.

·    Коллегиальные процедуры принятия решений.

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

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

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

Заключение

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

Признанные классики этого направления научных исследований (Нобелевский лауреат H.Simon, академик О.И.Ларичев) отмечали тесную онтологическую связь проблемы принятия решений с теорией сравнительного превосходства по ценности, многокритериальной теорией полезности, теорией аналитических иерархий.