Моделирование активов предприятия: современные стандарты и практика

ERP-systemsCRM systemsIT TerminologyBusiness Models

Можно ли войти в одну реку дважды?

Данная статья написана по результатам доклада на конференции Нефтегазстандарт – 2016, сделанная мной от имени компании ТриниДата.

Работая инженером — онтологом, я занимаюсь созданием информационных моделей для информационных систем.

В этой статье я хочу рассказать о практике применения стандарта ИСО 15926 к моделированию активов предприятия, и о том, к каким результатам это привело нас в итоге. Те, кто незнаком со стандартом, могут не расстраиваться — чтение статьи будет полезно независимо от знания стандарта.

Проблемы моделирования активов


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

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

  3. Для моделирования деятельности предприятия предложено множество стандартов, например, стандарт ArchiMate. По заявлениям его разработчиков этот стандарт дружественен стандарту ISO 15926 и методологии моделирования архитектуры предприятий TOGAF. Несмотря на заявленные возможности, этот стандарт не вполне справился с поставленными задачами. Одна из причин этого – отсутствие разграничения между понятиями «деятельность» и «активность» (деятельность подразумевает целенаправленные усилия по достижению результата. Активность же трактуется как происходящее, которое независимо от воли субъекта). Чтобы лучше понять возникающую трудность, вспомните, как древние греки трактовали «а» в квадрате? Они не мыслили это иначе как площадь квадрата со сторонами длиной а. То же можно сказать про куб – объем куба со сторонами длиной «а» записывался как «а» в кубе. Но, поскольку нельзя придумать физический аналог «а» в четвертой степени, уравнения выше кубических в Древней Греции не рассматривались. И так было до тех пор, пока в средние века алгебраисты не оторвали уравнения от физического смысла. Начавшаяся эра чистой математики не искала физических аналогов уравнениям. Ровно то же происходит в бизнес-анализе. Рассмотрение происходящего только под одним углом зрения (как деятельность), сильно ограничивает наши аналитические возможности.

  4. В стандарте ISO 15926 также присутствует ценная возможность моделировать объекты разных типов (например, функциональные и физические), а также пересечения этих объектов во времени. Однако набор возможных типов объектов жестко определен стандартом, и в некоторых практических случаях его оказывается недостаточно для создания модели, адекватно отражающей представления об объекте, событии или процессе. Например, в стандарте нет объектов типа «производственный ресурс».

Постановка задачи


Последняя моя работа была связана с Самарским заводом нефтяного резервуарного оборудования.

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

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

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

В качестве идеологической основы для создания модели был взят стандарт ИСО 15926.



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

Для описания деятельности предприятия можно было взять нотацию ArchiMate.



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

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

Далее я расскажу об этом способе более подробно.

Решение


Новое понятие, которое нам понадобилось, — это точка зрения. Рассмотрим насос в качестве примера актива.



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



Второе понятие, которое нам понадобилось, — это конструкция. Рассмотрим конструкцию человеческого организма.



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



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



Для моделирования такого разнообразия понятие «конструкция» нам необходимо наравне с понятием «объект».



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



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

В стандарте ИСО 15926 описан способ построения хранилища данных, в котором учтены только две точки зрения: точка зрения на физический мир и точка зрения на функциональные объекты. В нем также описан способ перехода от одного представления к другому через темпоральные части. То есть можно получить ответ на вопрос: какие физические объекты исполняли роль данного функционального и когда? Можно получить ответ и на обратный вопрос: какие функциональные объекты исполнял тот или иной физический объект? Ответ на эти вопросы и есть способ перехода от одного представления к другому. Однако, введя понятие «точка зрения» мы теперь не ограничены только двумя точками зрения. Теперь мы можем создавать столько точек зрения, сколько нам надо для наших целей моделирования.

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



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

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



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

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

Итоги:


Полученная метамодель обладает следующими преимуществами:

  1. Метамодель приближена к нашему естественному мышлению, что позволяет в случае необходимости легко ее расширить, например, введя в нее вероятности.
  2. Метамодель обладает универсальностью. Все, что нам нужно было смоделировать, мы смогли описать, используя данную методику.
  3. Дополнительным бонусом возникла возможность описания деятельностей разного типа в одном фреймворке. Например, обычная производственная деятельность и деятельность по саботажу производственной деятельности описывается единым способом в одной модели.
  4. Мы смогли разорвать связь между моделью и методологией ее применения. Разработчик модели теперь не обязан знать цели, с которыми будет применяться та или иная модель. Он фиксирует факты, а их интерпретацией занимаются другие субъекты. Это позволяет создавать модели с необходимым уровнем секретности.
  5. Метамодель предполагает такую точку зрения на предметную область, которая не требует введения предустановленным типов объектов: например, функциональных или физических. Подобные типы вводятся по мере необходимости и количество подобных типов может быть любым.
  6. Метамодель позволяет переходить от одного представления объекта к другому его представлению, используя при этом одну информационную модель.
  7. Метамодель позволяет создавать информационную модель, которая способна расширяться неограниченно. Ее расширение ограничено только объемом хранимой информации, но не логическими противоречиями, которые могли бы возникнуть по причине несогласованности данных.

Трудности в реализации модели:

  1. Трудность в реализации данной модели в том, что полученная в итоге модель имеет большую степень сложности и потому предъявляет высокие требования к программной реализации.
  2. Для создания моделей такого уровня сложности требуется дополнительное обучение специалистов.
Tags:бизнес-процессыcrm-системыerp-системыбизнес-аналитикамоделирование предметной областионтологическое моделирование
Hubs: ERP-systems CRM systems IT Terminology Business Models
+11
7.7k 44
Comments 85

Popular right now

Top of the last 24 hours