Использование системной модели для проектирования аналитических хранилищ. Часть 1: описание модели для проектирования

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

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

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

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

---

ГИПОТЕЗА: Проектирование «от модели»

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

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

Рисунок 1 - Направление основных интересов универсального стейкхолдера внутри предприятия.

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

• О результативности контролируемых или выполняемых процессов, функций и проектов. Методы определения метрик выходят за рамки данной статьи.

• В рамках процессов (явных или неявных – в зависимости от корпоративной культуры предприятия) управления талантами, сотрудник оценивает параметры своей и других доступных ему ролей и собственные параметры. А в рамках управления талантами вверенных ему сотрудников – оценивает те же параметры для специалистов и руководителей, входящих во вверенные ему подразделения.

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

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

• Будучи внутри иерархической организационной структуры сотрудник интересуется эффективностью и задачами вышестоящего подразделения – для своевременной корректировки вверенной ему зоны ответственности.

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

Описание предлагаемой метамодели

Мета-модель — описание концепций, отношений и правил, используемых для создания модели.

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

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

• пропускает некоторые популярные в других языках отношения, чтобы не перегружать описание;

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

Рисунок 2 - Мета-модель дополнений языков системного моделирования для проектирования аналитических хранилих предприятия

Основные необходимые сущности для проектирования аналитических хранилищ:

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

  • «линейкой» (описанием всех возможных значений и их взаимоотношения);

  • и правилами измерения (на основании каких данных и их отношений определяется конкретное значение метрики для каждого измеряемого объекта).

• Цель процесса или проекта. В ArchiMate для описания цели используются элементы «Мотивации»

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

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

• Роль – определяется по аналогии с аналогичным объектов в ArchiMate.

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

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

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

Дальнейшие планы и задачи

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

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

• системных инженеров -- для всецелого моделирования предприятий;

• дата инженеров -- для получения целостной модели внедряемых и разрабатываемых аналитических решений.

В дальнейшем в рамках проводимого исследования предполагается решить следующие задачи:

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

2. Адаптировать предложенные в данной статье элементы к существующим элементам выбранного языка и выявить необходимый объем изменений.

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

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