MoSCoW Method for Requirements Prioritization

As we all know, in any Project the Requirements are the key components of Project Scope. The Requirements should be prioritized, so that it will be easy to determine which Requirements are most important and which are least. Though there are different methods to prioritize the Requirements, in this Blog Post we will discuss about the MoSCoW Method for Requirements Prioritization. 

Origination: The MoSCoW approach was originated from the Dynamic Software Development Method (DSDM) Methodology. 

Acronym:  MoSCoW stands for:

• Must have (or Minimum Usable Subset)
• Should have
• Could have
• Won’t have (but Would like in future)

Note: The o's in MoSCoW are added to make the acronym pronounceable, and are often written in lowercase to depict that they don't have any significance.

MoSCoW is a Requirements Prioritization method that is used to take a decision on which requirements must be completed first and which must come later or will not be completed at all. To understand it practically, I have taken a simple example.

Example: You are planning to buy an SUV (of at least 7 seats) to Travel with your family and friends  on the weekends. The SUV should be of Diesel variant. As Red is your favorite color, you want to have Red color body work on it. Additionally you would like to have Bluetooth connectivity for your iPod. You are fond of having a 4-wheel drive mechanism in the SUV...and so on so forth...

As depicting a BA concept through a "Picture" is the uniqueness of my Blog, again I have come up with the below one which explains the MoSCoW Method in detail and prioritization of the above mentioned requirements in the example using the MoSCoW Methodology.

Pic: MoSCoW Methodology

Hope you will have a clear understanding of the MoSCoW Methodoly from the above picture. 

To deliver a successful project requires prioritization of the Requirements and Project Objectives (Scope, Quality, Time-frame and Resources). The below picture will give you an understanding of how 100% of Total efforts of a Project gets distributed as per the MoSCoW Prioritization Framework.

Pic: Project Effort Distribution - MoSCoW Framework

So with this blog post my objective is to make you all understand the MoSCoW Concept for Requirements Prioritization. Hope you all will like this.

Please do let me know your thoughts, feedback through comments...so that I can improve my blog post presentation for all the Dearest Readers... :)

As We Work...We Learn...

Формула успеха и Risk Management

«Добиться многого невозможно без смелости и риска, и неудачи при этом неизбежны»

Дионисий Галикарнасский, из письма Помпею

Продолжая поднятую в №36 за 2001г. тему перемен, трудно не согласиться с мнением специалистов, что сегодня уже бесполезно игнорировать происходящие изменения буквально во всех жизненных проявлениях и думать, что завтра будет таким же, как вчера или еще лучше. «Но предугадать изменения, которые потребуются для выживания в период перемен, - пишет П.Друкер, - все равно, что благополучно пережить этот период».

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

Риск в широком смысле: возможность появления обстоятельств, обусловливающих:

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

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

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

Наука, появившаяся сравнительно недавно и приобретшая огромную популярность за рубежом, именуемая «Risk Management» («Риск-менеджмент»), предлагает разнообразные методики по оценке и управлению рисками различных видов. Более того, в 1981г. было основано Международное Общество Анализа Риска – International Society of Risk Analysis (ISRA) – неправительственная организация в сфере применения методологии анализа риска для целей оптимизации решений в различных областях научной и практической деятельности.

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

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

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

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

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

Значительно упрощает проблему применение компьютерных технологий - специальных программ-структуризаторов, входящих в интегрированное решение «БИГ-Мастер». Их применение позволяет существенно ускорить реакцию компании на изменение рыночной ситуации и не упустить нужный момент корректировки ранее принятых решений. В таких случаях могут возникать как непредвиденные проблемы, так и неожиданные возможности, которые необходимо использовать. Деятельность руководителя предприятия в такой ситуации должна быть направлена на защиту своей фирмы от рисков, угрожающих ее прибыльности, а также способствовать решению основной задачи бизнеса – в зависимости от ситуации выбрать из нескольких вариантов решений оптимальный, учитывая при этом, что чем выше ожидаемая прибыль, тем выше риск. Другими словами, ведущая стратегия поведения предпринимателя– это управление риском, т.е. его своевременное выявление и оценка, а также разработка и внедрение мер по его минимизации.

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

Внедрение такого процесса, безусловно, представляет сложную задачу, к тому же российские предприниматели еще не до конца осознали необходимость создания инфраструктуры риск-менеджмента. Тем не менее, не имея возможности использовать опыт своих западных коллег по причинам, изложенным выше, отечественные бизнесмены разработали множество своих приемов по управлению рисками: это и работа по предоплате, и особые условия в договорах и многое, многое другое… Проблема, главным образом состоит в том, что немногие понимают, что для осознания и управления рисками в их взаимосвязи с деятельностью предприятия, необходим комплексный подход. Кроме того, нельзя управлять риском, не зная, что мы этим управлением хотим добиться, надо четко представлять себе, чем закончится дело и принесет ли оно удачу или поражение: ведь чем больше ожидаемый доход, тем больше риск, связанный с получением этого дохода. Общеизвестно, «No free lunch» (бесплатного обеда не бывает) или, как гласит «формула успеха», «чем ниже вероятность успеха, тем выше уровень побуждения к нему в связи с его ценой». Другими словами, успеха в экономике добиваются тогда и там, когда и где у людей высока сила мотива к достижению.

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

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

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

5 popular requirements prioritisation techniques

About Requirements Prioritisation

When prioritising requirements it’s important to ensure stakeholder involvement in the process. Typically, requirements are elicited through workshops, documented sources, and existing systems and processes. They are then documented and presented back to the stakeholders for prioritisation and/or elimination from scope. This is usually done in the form of a workshop.

If time permits, prioritisation may also occur during requirements sessions. However, lets assume that the final validation of requirements occurs after the initial gathering stage in another workshop with key stakeholders and decision makers. The objective is to prioritise requirements and processes that are more valuable to the organisation. For instance, high priority requirements may be processes that help the business increase revenue or mitigate risks. Lower priority requirements are those that provide minimal impact to organisational outputs or end user experience.

In this post I will describe 5 common requirements prioritisation techniques.

But firstly…

Weighting Requirements

With any prioritisation technique it’s good practice to combine several other criteria to weight requirements. This provides a structured framework for determining which requirement is more important than another, i.e., it helps make sensible decisions on the prioritisation. The criteria may include business importance, technical complexity, risk, and cost to implement. Ongoing cost and return on investment may also be included. The criteria for weighting requirements is determined by the stakeholders involved and may include anything that pertains to the organisational need.

I’ve used a similar approach for assessing and recommending a technology option for implementation. I provide an example of this in How to Develop a Recommendation for the Implementation of a System and my Business Case Template.

Essentially, the predefined prioritisation criteria are given a weighted score for each requirement. The higher a requirement scored, the better it is rated as a candidate for implementation.

Essential Integrations

Another factor to consider is “essential integrations”. This is where an output depends on an input, or a requirement or feature can’t exist without the other(s). Essential integrations have an impact on the prioritisation according to the above criteria because we are now looking at a pair or group of requirements and not just a siloed statement with no understanding or consideration of how it works with the whole.

It’s important to ensure that the essential integrations are identified, and the prioritisation criteria (especially risk) is defined early, so that they can be used in conjunction with a prioritisation technique discussed below.

5 Requirements Prioritisation Techniques

I asked this question in three LinkedIn groups:

What is your preferred requirements prioritisation technique? Why do you use it?

The result is the following list covering the common requirements prioritisation techniques.

1. MoSCoW Prioritisation

The most popular answer to my LinkedIn question was MoSCoW as it is one of the most simplest techniques to use.

Here’s a YouTube video by BA Experts demonstrating how the MoSCoW technique works, Requirements Prioritization: Two Simple Techniques. And the transcript for the video is here: Transcript for Requirements Prioritization: Two Simple Techniques. It also includes a demonstration of the Needs-Based prioritisation technique which is a technique I’ve used often.

2. Needs-Based Analysis

As mentioned above, another simple technique is the Needs-Based prioritisation technique which distinguishes between what people really need versus what they would like to have. This technique is thoughtfully explained on this video, Requirements Prioritization: Two Simple Techniques.

3. Crowd Sourcing

Crowdsourcing is a way of determining what’s needed by enlisting the feedback and ideas of a large group of people. The article Why Business Analysts Need to Listen to the Crowd: Crowdsourcing Requirements Elicitation, says this:

… the guess of the crowd almost always turns out to be better than your guess, or the guess of anybody in your organization. That is why products developed with feedback from the crowd (the bigger the crowd, the better) will almost always be superior to products developed only with input from experts.

Crowdsourcing is an excellent method for incorporating the voice of the user and getting an initial prioritised list of requirements.

4. Dot Voting

Dot-voting is a another form of democratised feedback where each stakeholder gets typically 3-5 dots to put against one or more features. It works well when you need to understand priorities at a high level and gets stakeholders to focus on the key priorities. It’s fun way to relate to the stakeholders and have them interact in a positive way. Here’s a good article on dot voting: Prioritising requirements – how to do it and why it is critical to project success.

5. Buy a Feature

“Buy a feature” is another fun technique that empowers the business as they’re making the choices. It’s a great way to get stakeholder buy in. Each stakeholder gets imaginary money to spend on any features they want and each feature being assigned a value based on it’s size. They collaborate to buy the most important features to be delivered within the agreed timespan. This method can produce good results. Here’s a useful article that discusses the buy a feature technique: How to play the ‘Buy a feature’ design game.

~

That’s it! There many other requirements prioritisation techniques including “weighted shortest job first (WSJF)”, which is used in agile implementations. WSJF shouldn’t be overlooked, however, my LinkedIn research produced the above five techniques as the most common.

http://www.businessanalyststoolkit.com/requirements-prioritisation-techniques/

5 business analysis deliverables

Below is a list of what I think are the 5 major business analysis deliverables for defining and designing a technological solution for business.

This list follows the classic approach – not an agile approach – to implementation. However, these deliverables, or components of them, can be used in agile methodologies.

Business Analysis Deliverables

1. Business Analysis Plan

If you’re planning a business analysis effort then the following deliverables are required.

• Business Analysis Approach. This approach document contains the following key elements:
  • Background. Describes the purpose of the project and some background information.
  • Business Drivers. The business drivers, or the reasons why, for the proposed initiative. These help formulate the high level business requirements which determine the scope and purpose of the project.
  • Problem Statement. The problem statement describing the reasons for the project in practical business related terms using real examples to emphasise the need for the new initiative.
  • Vision. An aspirational description of what the organisation would like to achieve or accomplish as an outcome of the project.
  • Scope. The scope and boundaries of the change required. This includes what is exclude from scope.
  • Dependencies. Dependencies establish the links, and the type of links, between all the tasks of a project. There are also dependencies with other projects.
  • Key Roles and Responsibilities. Defines the roles and responsibilities of the people involved in the project.
• Stakeholder Engagement Plan. This document describes a list of stakeholders required for further consultation, who you’ll be eliciting requirements from and how.

2. Business Requirements Specification

The business requirements document will include the business drivers and problem statement, and the following.

• Business Drivers. The business drivers identified in the planning are refined as new information is gathered.
• Problem Statement. The problem domain is better understood after consultation with stakeholders.
• Stakeholder Model. The stakeholder model describes the internal workers (i.e., roles and entities that work within the system) and the external actors (those who interact externally with the system).
• Business Domain Model. Business domain model are the structural representation of the business shows the high level view of the business objects and entities within the problem domain.
• Business Use Cases. Business use cases identify the functional areas of the business that will be modelled.
• Business Activity Diagrams. Business activity diagrams are the behavioural representation of the business and are developed for each business use case.
• Business Requirements. Business requirements are platform independent, relevant, and traceable. They are realised against the business use cases.

3. Business Case

If it’s required, my preference is that a business case is developed after writing the business requirements. This is because a lot of information has been gathered about how the business currently works (current state) and what improvements can be made (future state). With this information tangible and financial benefits can be accurately measured and presented as the case for change. The key elements of a business case are:

• Background. Describes the purpose of the business case and some background information.
• Current Situation / Problem Statement. The current situation describes the problem and associated risks with the current situation.
• Options Analysed. Describes the options analysed and key findings.
• Recommendation. Based on the options analysed, this is the recommendation including what the approvers and funders need to do.
• Costs and Benefits. The costs and benefits describe the basis on which the benefits were identified and/or calculated (if financial). It details the financial and other benefits of the recommendation.
• Risks. Identifies any risks, constraints, shortcomings or limitations of the recommended approach.

The business case deliverable can occur before the business requirements specification, or after. Often I’ve worked on projects where the business case was developed after the business requirements stage. This was in situations where the business case needed to assess options for technology or process implementation and/or implementation approach. In this case, the information gathered during the business requirements stage provided valuable tangible benefits (and costs). For example, the benefits of how the automation of a manual process (or several processes) will create substantial savings and opportunities for an organisation. This is information that could not have been known without first developing the business requirements.

4. Functional Specification

The key elements of the functional specification are:

• System Use Cases. System use cases identify the function or service that a system will provide.
• User Requirements. These are traceable user requirements which are realised against the system use cases.
• System Activity Diagrams. System activity diagrams are the behavioural representation of the system and describe the interactions between an actor and the system.
• Class Diagrams. Class diagrams are the structural representation of the system and show the domain concepts traced back to the use cases.
• Functional Requirements. These are the functional requirements and features that are platform dependent and testable.

5. Non-Functional Specification

Non-functional requirements must be associated with specific project functionality/deliverables. The key elements of the non-functional requirements specification are:

• Hardware Requirements. Includes a detailed description of specific hardware requirements including such as type of hardware, brand name, specifications, size, and security.
• Software Requirements. Software requirements includes a detailed description of specific software requirements such as in-house development or purchasing, security, coding language, version numbering, functionality, data, interface requirements, brand name, and specifications.
• Performance Requirements. Includes a detailed description of specific performance requirements and associate them to specific project functionality/deliverables. Include information such as cycle time, speed per transaction, test requirements, minimum bug counts, speed, reliability, and utilisation.
• Supportability Requirements. Describes all of the technical requirements that affect supportability and maintainability such as coding standards, naming conventions, maintenance access, and required utilities.
• Security Requirements. Describes all of the technical requirements that affect security such as security audits, cryptography, user data, system identification/authentication, and resource utilisation.
• Interface Requirements. Describes all of the technical requirements that affect interfaces such as protocol management, scheduling, directory services, broadcasts, message types, error and buffer management, and security.
• Availability Requirements. Describes all of the technical requirements that affect availability such as hours of operation, level of availability required, down-time impact, and support availability.
• Compliance Requirements. Describes the existing compliance environment as it affects project requirements.

Often functional and non-functional specifications are written in the one document, but can be produced as separate deliverables as shown above. The format of deliverables can vary across different organisations. Even terminology varies from one organisation to another. For instance, one organisation may determine meaning of a business requirement to be quite different to the meaning that’s stated in the BABOK. So it’s important to spend time speaking with the client to ensure an understanding of the required deliverables, and what should be contained within them.

Let Algorithms Decide – and Act – for Your Company

Bill Franks

In the near future, simply having predictive models that suggest what might be done won’t be enough to stay ahead of the competition. Instead, smart organizations are driving analytics to an even deeper level within business processes—to make real-time operational decisions, on a daily basis. These operational analytics are embedded, prescriptive, automated, and run at scale to directly drive business decisions. They not only predict what the next best action is, but also cause the action to happen without human intervention. That may sound radical at first, but it really isn’t. In fact, it is simply allowing analytics to follow the same evolution that manufacturing went through during the industrial revolution.

Centuries ago everything was manufactured by hand. If you needed a hammer, for example, someone would manually produce one for you. While manually manufacturing every item on demand allows for precise customization, it doesn’t allow for scale or consistency. The industrial revolution enabled the mass production of hammers with consistent quality and lower cost. Certainly, some customization and personal touches were lost. But the advantages of mass production outweigh those losses in most cases. It remains possible to purchase custom made items when the expense is deemed appropriate, but this usually only makes sense in special situations such as when the purchaser desires a one-of-a-kind piece.

The same revolution is happening in analytics. Historically, predictive analytics have been very much an artisanal, customized endeavor. Every model was painstakingly built by an analytics professional like me who put extreme care, precision, and customization into the creation of the model. This led to very powerful, highly-optimized models that were used to predict all sorts of things. However, the cost of such efforts only makes sense for high-value business problems and decisions. What about the myriad lower value decisions that businesses face each day? Is there no way to apply predictive analytics more broadly?

There is.

Operational analytics recognize the need to deploy predictive analytics more broadly, but at a different price point. An assembly line requires giving up customization and beauty in order to achieve an inexpensive, consistent product. So, too, operational analytics require forgoing some analytical power and customization in order to create analytics processes that can increase results in situations where a fully custom predictive model just doesn’t make sense. In these cases, it is better to have a very good model that can actually be deployed to drive value than it is to have no model at all because only an optimal model will be accepted.

Let me illustrate the difference with a common example. One popular use of predictive models is to identify the likelihood that a given customer will buy a specific product or respond to a given offer. An organization might have highly robust, customized models in place for its top 10-20 products or offers. However, it isn’t cost effective to build models in the traditional way for products or offers that are far down the popularity list. By leveraging the learnings from those 10-20 custom models, it is possible to create an automated process that builds a reasonable model for hundreds or thousands of products or offers rather than just the most common ones. This enables predictive analytics to impact the business more deeply.

Operational analytics are already part of our lives today, whether we realize it or not. Banks run automated algorithms to identify potential fraud, websites customize content in real time, and airlines automatically determine how to re-route passengers when weather delays strike while taking into account myriad factors and constraints. All of these analytics happen rapidly and without human intervention. Of course, the analytics processes had to be designed, developed, tested, and deployed by people. But, once they are turned on, the algorithms take control and drive actions. In addition to simply predicting the best move to make or product to suggest, operational analytics processes take it to the next level by actually prescribing what should be done and then causing that action to occur automatically.

The power and impact of embedded, automated, operational analytics is only starting to be realized, as are the challenges that organizations will face as they evolve and implement such processes. For example, operational analytics don’t replace traditional analytics, but rather build upon them. Just as it is still necessary to design, prototype, and test a new product before an assembly line can produce the item at scale, so it is still necessary to design, prototype, and test an analytics process before it can be made operational. Organizations must be proficient with traditional analytics methods before they can evolve to operational analytics. There are no shortcuts.

There are certainly cultural issues to navigate as well. Executives may not be comfortable at first with the prospect of turning over daily decisions to a bunch of algorithms. It will also be necessary to get used to monitoring how an operational analytics process is working by looking at the history of decisions it has made as opposed to approving up front a series of decisions the process is recommending. Pushing through such issues will be a necessary step on the path to success.

The tools, technologies, and methodologies required to build an operational analytics process will also vary somewhat from those used to create traditional batch processes. One driver of these differences is the fact that instead of targeting relatively few (and often strategic) decisions, operational analytics usually target a massive scale of daily, tactical decisions. This makes it necessary to streamline a process so that it can be executed on demand and then take action in the blink of an eye.

Perhaps the hardest part of operational analytics to accept, especially for analytics professionals, is the fact that the goal isn’t to find the best or most powerful predictive model like we’re used to. When it is affordable and the decisions being made are important enough to warrant it, we’ll still put in the effort to find the best model. However, there will be many other cases where using a decent predictive model to improve decision quality is good enough. If an automated process can improve results, then it can be used with confidence. Losing sleep over what additional power could be attained in the process with a lot of customization won’t do any good in situations where it just isn’t possible due to costs and scale to actually pursue that customization.

If your organization hasn’t yet joined the analytics revolution, it is time that it did. Predictive analytics applied in batch to only high value problems will no longer suffice to stay ahead of the competition. It is necessary to evolve to operational analytics processes that are embedded, automated, and prescriptive. Making analytics operational is not optional!

Как поймать тренд и заставить его работать на ваш бизнес

Компания, поймавшая тренд, подобна паруснику, поймавшему попутный ветер: она движется без видимых усилий. Со стороны кажется, что ей просто повезло, однако, скорее всего, дело не в удаче, а в умелом мониторинге трендов. О том, как работает эта механика, для Executive.ru рассказал преподаватель бизнес-школы МИРБИС, эксперт в области маркетинга, Андрей Кулинич.

Executive.ru: Какие представления в маркетинге устаревают, а какие – нет?

Андрей Кулинич: Полагаю, фундаментальные представления о мире остаются прежними, тогда как схемы, способы их использования, тактика и стратегия – меняются. Я не очень люблю сравнения маркетинга с военными действиями, но проведу такую аналогию. Базовые законы ведения войны не изменились со времени Сунь Цзы. Однако, если представить эффективного военачальника времен Второй мировой войны в наших условиях, он, скорее всего, будет растерян и неэффективен. По крайней мере, пока не обновит свое представление о способах, формах и новых технологиях боя.

Executive.ru: Под воздействием каких факторов происходят изменения в маркетинговом инструментарии?

А.К.: В российской практике принято считать, что наиболее значимыми для бизнеса факторами в STEP-анализе (акроним, отражающий значение социальных, технологических, экономических и политических факторов, применяется в стратегическом менеджменте. – Executive.ru) являются политика и экономика. Однако для темы, которую мы обсуждаем принципиально важен фактор технологический. Технологии оказывают очень глубокое воздействие на изменение поведения людей. Например, современные родители при помощи смартфонов контролируют детей в режиме 24*7. Во времена моего детства такой контроль был в принципе невозможен. Включенность человека в коммуникации имеет самое серьезное значение для маркетинга. Как сформулировал в своей последней статье академик Сергей Капица, плотность истории определяется количеством контактов между различными людьми. Мир изменил понимание расстояния между людьми: физическое расстояние с появлением виртуального социума, существующего в круглосуточном формате, это привело к увеличению плотности жизни, к увеличению скорости принятия решений, к доступности информации. В связи с этим возникла проблема информационного перегруза: мозг стал защищаться от ненужных ему сообщений, не замечая их.

Executive.ru: Насколько для «отлова трендов» подходит распределение Эверетта Роджерса («Диффузия инноваций», в свое время сходную идею высказали также Брюс Райан и Нил Гросс)? Имеет ли смысл постоянно держать в поле зрения тех, кто находится в левой части композиции?

А.К.: Это интересная гипотеза, но она имеет слабое прогностическое значение. С учетом повышения плотности истории время инноваций сжимается. С помощью каких носителей люди смотрят кино? Видеокассеты жили с середины 1980-х годов до начала XXI века. CD просуществовали меньше: пользователи переключились на торренты. А теперь мы смотрим фильмы на YouTube и других подобных сервисах. Увеличивается плотность и сокращаются циклы. С учетом этих обстоятельств тяжело сказать, кто мы? Инноваторы, ранние последователи, либо опаздывающие? Кривая Роджерса хорошо объясняет события постфактум, но ее тяжело использовать для количественного прогноза на будущее. И, конечно, надо учитывать, что одновременно мы можем являться как новаторами, так и опоздавшими применительно к разным категориям.

Executive.ru: Все ли?

А.К.: Если мы не становимся новаторами, в этом случае реализуется другой интересный футурологический сценарий, который обсуждался в Изборском клубе. Суть в том, что в мире появятся новые варвары, потому что успешность будет проходить не по линии богатства, а по линии новых технологий. Вы будете успешны, если вы адаптируетесь, используете в жизни, в работе новые средства коммуникации. Новые варвары – те, кто по тем или иным причинам не хотят или не могут использовать данные современные технологии. Они лишены права на успех в новом понимании.

Executive.ru: Вы говорите о финансовом успехе?

А.К.: Финансовый успех и использование технологий в современном обществе являются связанными понятиями. С одной стороны, люди с высоким достатком более активно пользуются современными технологиями, и доступ к технологиям определяется их финансовыми ресурсами. С другой стороны, технологии становятся все более доступными, и эта доступность создает возможности для финансового успеха. Однако, ни в первом, ни во втором случае нет прямой зависимости. Создатели сайтов для бесплатного онлайн-обучения планировали сделать образование бесплатным, они видели свою миссию именно в этом. Однако экономически незащищенные слои не стали массово пользоваться этими ресурсами. Зато эти сайты с удовольствием стали использовать те, кто и до этого был готов платить за образование. Таким образом, в некотором смысле произошла «каннибализация спроса».

Executive.ru: Существуют ли инструменты для «охоты на трендсеттера»?

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

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

Executive.ru: Какие индустриальные решения существуют для мониторинга трендов? Что вы планируете показать на вебинаре?

А.К.: Во-первых, есть исследования Trendwatching. Это крупное агентство, занимающееся анализом потребительских рынков. Оно систематизирует тренды, проводит конференции, публикует материалы. Если пять лет назад для анализа трендов надо было «шерстить» множество источников на разных языках, то теперь достаточно посмотреть материалы Trendwatching. Вы получите достаточно полную картину коротких трендов.

Для более глубокого анализа имеет смысл обратиться к исследованиям Gartner– компания занимается анализом тенденций в области технологий, в том числе маркетинговых инструментов. Горизонт анализа – 5-10 лет. Эти материалы помогают понять, к чему надо быть готовым, чтобы быть успешной компанией в будущем. У Gartner есть такой инструмент как Gartner hype cycle – он сформирован по отраслям, по видам деятельности. Доступ к результатам исследования – платный, в бесплатном формате выложена только часть материала. Однако для начала работы с трендами и бесплатной информации будет достаточно.

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

Executive.ru: К каким отраслям применимы инструменты, которые вы только что назвали?

А.К.: Здесь нет ограничений по отраслям. Анализ трендов одинаково важен для компаний разного профиля.

Executive.ru: Кому адресован вебинар?

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

Executive.ru: Что происходит с компанией, которая поймала тренд?

А.К.: Если компания действительно поймала значимый, сильный тренд, стала «единорогом», она проходит две стадии. На первом этапе переживает вдохновение: «Мы нашли, мы поверили, мы переступили через сомнения, мы начали реализовывать!». Затем наступает определенное разочарование, связанное с тем, что действительно серьезные значимые тренды не приносят результат быстро. Бывает также, что компания опередила рынок.

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

Обзор применения онтологий в моделировании и управлении

Кудрявцев Д.В.

Введение

Онтология — формальная спецификация разделяемой концептуальной модели  [Studer,1998], где

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

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

В рамках [Эталонные модели, 2006] было проведено детальное исследование понятия «онтология» и особенно областей применения онтологий. В результате систематизация знаний в области онтологий, предложенная в  [Гаврилова, 2003], была расширена (рис.1):

Рис. 1. Систематизация знаний в области онтологий

К настоящему моменту существует ряд примеров использования онтологий в организационном моделировании и управлении:

1. Enterprise Project [Stader, 1996; Uschold, 1997],
2. Process Specification Language (PSL) project  [Bock, 2005], 
3. Toronto Virtual Enterprise (TOVE) project [Fox, 1992; Gruninger, 2000],
4. SUPER Project [Born, 2007; Hepp, 2007],
5. Понятийное и объектное моделирование властных структур на региональном уровне ИПУСС РАН [Виттих и др., 2006]
6. Конфигурирование услуг электронного государства на основе онтологий —Onto-Gov [Abecker, 2004]

Далее приводится краткое описание указанных примеров.

Enterprise Project и Онтология Предприятия (Enterprise Ontology)

http://www.aiai.ed.ac.uk/project/enterprise/

Целью проекта Enterprise, выполненного совместно представителями университета Эденбурга, IBM, Unilever и Lloyd’s Register [Uschold, 1997], являлось моделирование бизнес-среды для поддержки менеджеров в принятии взвешенных стратегических, тактических и операционных решений. В свою очередь основная роль моделирования в проекте Enterprise состоит в формировании комплексного взгляда на организацию. Для достижения, использования и поддержки такого комплексного взгляда на организацию требуются мощные средства интеграции, коммуникации, гибкости и поддержки.

В результате проекта Enterprise был разработан Enterprise Tool Set (ETS) для информационной поддержки предоставления комплексного взгляда на предприятие.

В качестве базовой модели поддержки моделирования предприятия используются модели процессов, которые обеспечивают процессно-ориентированный взгляд и которые могут быть реализованы в исполнительной (running) системе. Для разработки моделей процессов был создан Procedure Builder. В большинстве организаций существует множество используемых инструментов (приложений). Было решено поддерживать интеграцию существующих инструментов с минимальными их изменениями, вместо того чтобы заменять существующие инструменты и их интерфейсы. Для реализации такого подхода был создан Agent Toolkit — архитектура, основанная на агентах (agent-based architecture), совмещенная с библиотекой, поддерживающей процесс добавления инструментов к системе.

Кроме поддержки интеграции инструментов, предложена поддержка реализации (исполнения) процессов. Task Manager обеспечивает как интеграцию инструментов, так и поддержку самих моделей процессов. Кроме того, он обеспечивает поддержку реализации процессов во времени (agenda-style).

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

В результате состав Enterprise Tool Set следующий (рис. 2):

• Procedure Builder для разработки моделей процессов
• Agent Toolkit для поддержки разработки агентов
• Task Manager для интеграции, визуализации и поддержки реализации
• Enterprise Ontology для коммуникации

Рис. 2. Архитектура Enterprise Tool Set

Роль Онтологии Предприятий в Enterprise Project:

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

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

Все термины в онтологии попадают в 5 верхне-уровневых разделов, отражающих разные аспекты предприятия:

• Мета Онтология и Время
• Активность, План, Способность и Ресурс
• Организация
• Стратегия
• Маркетинг

В приводимой ниже таблице (табл. 1) перечислены все определенные в Онтологии Предприятий понятия, объединенные в основные группы.

Табл. 1. Общая модель Онтологии Предприятий

Активности и процессы	Организация	Стратегия	Маркетинг	Время
Активность	Лицо	Цель-назначение	Продажа	Ось времени
Спецификация активности	Машина	Иметь цель-назначение	Потенциальная продажа	Временной интервал
Выполнять	Корпорация	Планируемая цель-назначение	Для продажи	Момент времени
Выполненная спецификация активности	Партнерство	Держатель цели-назначения	Коммерческое предложение
T-Начала	Партнер	Стратегическая цель-назначение	Вендор
T-Окончания	Юридическое лицо	Задача	Фактический покупатель
Предварительное условие	Подразделение	Виденье	Потенциальный покупатель
Эффект	Управлять	Миссия	Покупатель
Делатель	Делегировать	Цель-результат	Дистрибьютор
Под-активность	Управленческая связь	Обеспечивать достижение	Продукт
Полномочия	Право собственности	Стратегия	Запрашиваемая цена
Владелец активности	Non-Legal собственность	Стратегическое планирование	Цена продажи
Событие	Собственность	Стратегическое действие	Рынок
План	Владелец	Решение	Переменная сегментации
Под-план (sub-plan)	Актив	Допущение	Рыночный сегмент
Планирование	Заинтересованная сторона	Критическое допущение	Маркетинговое исследование
Спецификация процесса	Трудовой договор	Некритическое допущение	Бренд
Способность	Доля / Акция	Фактор влияния	Имидж
Умение	Собственник / Акционер	Критический фактор влияния	Характеристика
Ресурс		Некритический фактор влияния	Потребность
Распределение ресурсов		Критический фактор успеха	Потребность рынка
Ресурс заменитель		Риск	Продвижение
			Конкурент

Далее для примера рассмотрены термины из двух разделов:
Активности и процессы и Мета-онтологии.

Активности и процессы

Центральным термином является АКТИВНОСТЬ (ACTIVITY). Он охватывает понятие всего, что предполагает реальное делание, в частности, включая действие. АКТИВНОСТЬ может иметь место в прошлом и происходить в настоящем. Этим термином можно также обозначать гипотетическую будущую АКТИВНОСТЬ.

Тем не менее, существует необходимость непосредственно указывать спецификацию или план АКТИВНОСТЕЙ. Это называется СПЕЦИФИКАЦИЯ АКТИВНОСТИ (ACTIVITY SPECIFICATION). Как и рецепт, она на некотором уровне детализации описывает одну или более АКТИВНОСТЕЙ. СПЕЦИФИКАЦИЯ ВЫПОЛНЕННОЙ АКТИВНОСТИ должна иметь нечто сделанное, соответствующее АКТИВНОСТИ.

Концепция АКТИВНОСТИ тесно связана с понятием ДЕЛАТЕЛЬ (DOER), который ВЫПОЛНЯЕТ (EXECUTES) СПЕЦИФИКАЦИЮ АКТИВНОСТИ, совершая заданные АКТИВНОСТИ. ДЕЛАТЕЛЬ может быть ЛИЦОМ (PERSON), ПОДРАЗДЕЛЕНИЕМ (ORGANISATIONAL UNIT) или МАШИНОЙ (MACHINE). Эти термины определены в секции Организация и вместе могут собирательно обозначаться как [ПОТЕНЦИАЛЬНЫЕ] ИСПОЛНИТЕЛИ ([POTENTIAL] ACTORS) (или АКТЕРЫ).

Возможность ПОТЕНЦИАЛЬНОГО ИСПОЛНИТЕЛЯ быть ДЕЛАТЕЛЕМ обозначается как СПОСОБНОСТЬ (CAPABILITY) или УМЕНИЕ (SKILL), если ДЕЛАТЕЛЬ – ЛИЦО. ИСПОЛНИТЕЛЬ может выполнять иные Роли в отношении АКТИВНОСТИ, такие, например, как ВЛАДЕЛЕЦ АКТИВНОСТИ (ACTIVITY OWNER).

С АКТИВНОСТЬЮ также тесно связан РЕСУРС (RESOURCE), представляющий собой нечто, могущее быть использованным или израсходованным АКТИВНОСТЬЮ. АКТИВНОСТЬ также может иметь выходы или ЭФФЕКТЫ (EFFECTS). АКТИВНОСТЬ связана с ВРЕМЕННЫМ ИНТЕРВАЛОМ (TIME INTERVAL). АКТИВНОСТЬ может занимать малое или большое время и быть простой или сложной. Сложная АКТИВНОСТЬ может раскладываться на множество ПОД-АКТИВНОСТЕЙ (SUB-ACTIVITIES).

СПЕЦИФИКАЦИЯ АКТИВНОСТИ совместно с ПЛАНИРУЕМОЙ ЦЕЛЬЮ-НАЗНАЧЕНИЕМ (INTENDED PURPOSE), определяемой в разделе Стратегия,  называется ПЛАНОМ (PLAN). Понятие о возможности многократно ВЫПОЛНЯТЬ один и тот же ПЛАН описывается термином СПЕЦИФИКАЦИЯ ПРОЦЕССА (PROCESS SPECIFICATION).

Управление осуществлением  АКТИВНОСТЕЙ важно для предприятия. Для этой цели мы определяем понятие ПОЛНОМОЧИЯ (AUTHORITY) ИСПОЛНИТЕЛЯ быть вправе выполнять одну или несколько АКТИВНОСТЕЙ (например, как указано в ПЛАНЕ).

Мета-Онтология и Время

Базовым понятием Мета-Онтологии является СУЩНОСТЬ (ENTITY). Это то, что охватывает все другие понятия. При построении Онтологии некоторые понятия могут рассматриваться как самостоятельные, независимые от других (например, ЛИЦО (PERSON)). Они непосредственно классифицируются как СУЩНОСТИ. Другие понятия более естественно видятся как ОТНОШЕНИЕ между двумя или более СУЩНОСТЯМИ (например, ПРОДАЖА). Поэтому, хотя ПРОДАЖА может юридически рассматриваться как СУЩНОСТЬ, ее точнее охарактеризовать как ОТНОШЕНИЕ.

В рамках ОТНОШЕНИЯ СУЩНОСТЬ может иметь РОЛЬ (например, Лицо может быть Клиентом в Продаже). Напротив, СУЩНОСТЬ может рассматриваться как АТРИБУТ или другая СУЩНОСТЬ (например, Дата рождения Лица).
Некоторые РОЛИ в ОТНОШЕНИЯХ специфичны в том, что исполнение этих РОЛЕЙ влечет за собой некие представления о действиях или суждениях (например, выполнение Активности или принятие Предположения). Мы определяем СУЩНОСТЬ, исполняющую такую РОЛЬ как АКТОР (ACTOR) (что является приблизительным синонимом к ‘агенту’ в других работах по онтологии). РОЛЬ, исполняемая АКТОРОМ, — это РОЛЬ АКТОРА. Только определенные СУЩНОСТИ могут играть такие РОЛИ, они являются ПОТЕНЦИАЛЬНЫМИ АКТОРАМИ. В настоящее время они включают в себя Лиц, ОРГАНИЗАЦИОННЫЕ ЕДИНИЦЫ и, в некоторых случаях, Машины.

Для удовлетворения потребностей множества пользователей и различных точек зрения в настоящее время и в будущем в Онтологии могут появляться или использоваться совместно с ней новые РОЛИ АКТОРОВ и вводиться новые ОТНОШЕНИЯ. Могут появляться и новые типы СУЩНОСТЕЙ АКТОРОВ, хотя возможно, менее часто.

Собирательно ситуация, характеризуемая одной или более СУЩНОСТЯМИ, участвующими в одном или более ОТНОШЕНИЯХ с одной или более другими СУЩНОСТЯМИ, определяется как СОСТОЯНИЕ ДЕЛ. СОСТОЯНИЕ ДЕЛ может иметь место, а может и нет (т.е. быть истинным или ложным).

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

Время. Понятие времени не специфично для Предприятий, но они его используют. Мы не делали попыток переосмыслить существующие работы по представлению времени, вместо этого мы просто использовали их. Мы отмечаем, что при выполнении АКТИВНОСТИ следует говорить о ВРЕМЕННОМ ИНТЕРВАЛЕ. ВРЕМЕННОЙ ИНТЕРВАЛ определяется в терминах МОМЕНТОВ ВРЕМЕНИ, которые, в свою очередь, составляют ОСЬ ВРЕМЕНИ (TIME LINE).

The TOVE Project (Toronto Virtual Enterprise)

http://www.eil.utoronto.ca/enterprise-modelling/index.html
http://www.eil.utoronto.ca/enterprise-modelling/tove/

Целями проекта TOVE являлись:
1. Создание разделяемой терминологии (онтологии) для предприятия, которую каждый агент будет однозначно понимать и использовать.
2. Определить смысл каждого термина.
3. Ввести семантику в виде набора аксиом, которые позволяют TOVE автоматически выводить ответы на вопросы «здравого смысла» («common sence») о предприятии.
4. Определить символьные обозначения для терминов и понятий.

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

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

Язык спецификации процессов — Process Specification Language (PSL)

Язык спецификации процессов является развитием результатов, полученных в проекте TOVE. В инициативах по реинжинирингу бизнес-процессов или по интеграции предприятий критическим вопросом является возможность обмениваться и связывать разнообразные модели процессов. Целью Process Specification Language (PSL) Проекта является разработка формата обмена для передачи описаний процессов между различными системами бизнес-моделирования и управления бизнес-процессами, такими как системы work-flow, системы симуляции, инструменты бизнес-реинжиниринга и репозитарии процессов. PSL выступает как единый формат, обеспечивающий интероперабельность, заменяющий постоянную разработку ad hoc трансляторов для каждой пары описаний процессов. PSL дает приложениям общее понимание понятий, которыми необходимо обмениваться.

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

В отличие от языков моделирования процессов, PSL является языком обмена процессной информацией между приложениями. Например, он позволит передать модель процесса из приложения, использующего IDEF3, в приложение, использующее сети Petri.

PSL основан на формальной онтологии. Все понятия PSL формально определены на основе Knowledge Interchange Format (KIF) для устранения двусмысленности, которая часто встречается в приложениях, описывающих процессы. Онтология состоит из ядра и серии модулей, основанных на Ядре. PSL Ядро — модуль, который включает выскоуровневые базовые понятия, присущие описанию процесса. Каждый модуль проясняет Ядро и включает набор понятий, связанных с определенной областью описания процесса (ресурсы, роли, время). Модули строятся друг на друге, что делает PSL онтологию похожей на сеть модулей, в основании каждого из которых лежит Ядро. Подробнее см. http://www.mel.nist.gov/psl/index.html.

Проект SUPER

http://ip-super.org/

В качестве наиболее передового и крупного проекта в области развития технологий моделирования организаций и управления бизнес-процессами можно выделить проект SUPER (Semantics Utilized for Process Management within and between Enterprises /  Использование семантики для управления процессами внутри и между предприятиями). Основной целью проекта SUPER является перевод управления бизнес-процессами (BPM) с уровня информационных технологий на бизнес-уровень. Такая цель требует доступности системы управления процессами на уровне понятий бизнес экспертов, способом представления которых выступают онтологии. Авторы называют свой подход семантическим (semantic) управлением бизнес-процессами (SBPM) [Hepp, 2005].

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

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

Рис. 3. Композиция (составление) процесса на основе семантически аннотированных сервисов и процессов

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

Использование предлагаемых технологий позволит:

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

SBPM-инструмент ориентирован на совместимость с существующими инструментами и стандартами организационного моделирования. В частности, процессы, представленные на BPEL, BPMN или EPC, должны «читаться» («импортироваться») SBPM-инструментом. Также процессы, созданные в SBPM-инструменте, должны экспортироваться в BPEL для исполнения в соответствующих инструментах (BPEL Engines) — см. рис. 4:

Рис. 4. Схема функционирование SBPM

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

В настоящий момент проектируемая система онтологий («SUPER Set of Ontologies for Business Process Management») состоит из 8-ми разделов и выглядит следующим образом [Hepp, 2007]:

1. Процессы 1.1. Верхнеуровневая процессная онтология (Upper Process Ontology)
Процесс (Process)
Активность (Activity)
Предположение (Assumption)
Предусловия (Pre-condition)
Пост-условие (Postcondition)
Эффект (Effect)
1.2. Онтология ЯОМ BPEL (sBPEL ontology, an ontology version of BPEL)
1.3. Онтология ЯОМ BPMN (sBPMN, an ontology version of BPMN)
1.4. Онтология ЯОМ EPC (sEPC, an ontology version of EPCs)
2. Организация и ресурсы 2.1. Верхнеуровневая онтология организации (Upper Organizational Ontology)
Организация (Organization)
Роль (Role)
Задача (Task)
Дивизион (Division)
Ресурс (Resource)
Сотрудник (Employee)
Машина или Система (MachineOrSystem)
Нематериальный ресурс (IntangibleResource)
Навыки и Способности (Skill and Capability)
2.2. Онтология Организации для бизнеса (Business Organization Ontology)
2.3. Онтология ресурсов для бизнеса (Business Resources Ontology)
3. Онтология бизнес функций
3.1. Маркетинг (Marketing)
3.2. Человеческие ресурсы (Human Resources)
3.3. Операции (Operations)
...
4. Данные 4.1. Верхнеуровневая модель данных организации (Enterprise Data Upper Ontology)
Система управления базой данных (DBMS)
База данных (DataBase)
Схема базы данных (DataBaseTable)
4.2. Онтология транзакцмй данных (Transactional Data Ontology)
4.3. Онтология кастомизации данных (Customizing Data Ontology)
5. Онтология обеспечения и потребления
6. Онтология правил и ограничений предприятия
7. Онтология стратегии
Цель (Goal)
Подцель (SubGoal)
8. Предметные онтологии

Понятийное и объектное моделирование властных структур на региональном уровне ИПУСС РАН

В Институте проблем управления сложными системами РАН и научно-производственных компаниях-партнерах Института накоплен значительный опыт по использованию онтологического подхода в задачах информационной поддержки административной деятельности на региональном уровне (см., например, [Батищев и др., 2003], [Виттих и др., 2004], [Волхонцев и др., 2005], [Хасаев и др., 2003], [Виттих и др., 2006]).

Этот опыт оказался востребованным и в связи проведением в настоящее время административной реформы на федеральном и региональном уровнях [Концепция, 2005].

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

Кроме того, одним из региональных приоритетов в области реформирования государственного управления является повышение роли взаимодействия в процессах принятия решений: в организации процессов управления в Самарской области предполагается взаимодействие органов власти, предпринимателей, общественных деятелей и жителей области, которые готовы реализовывать свои гражданские права и обязанности [Титов и др., 2006]. Необходимым условием такого разнородного взаимодействия является наличие общего понятийного базиса, на основе которого можно описывать предметные и проблемные области, специфицировать организационные структуры по решению поставленных задач, осуществлять принятие управленческих решений.

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

Понятийные и объектные модели системы исполнительной власти

Конструирование всех онтологий и объектных моделей выполнялось с помощью разработанной в ИПУСС РАН общецелевой системы объектно-ориентированного моделирования gB [Смирнов, 1999], [Смирнов, 2004].

Первой была разработана онтология структуры системы исполнительной власти Самарской области. При построении этой понятийной модели были использованы Устав Самарской области, положения и регламенты деятельности органов исполнительной власти Самарской области, перечень органов исполнительной власти Самарской области, не являющихся министерствами Самарской области (иных органов исполнительной власти Самарской области), другие нормативно-правовые акты, мнения экспертов. В онтологии представлено более 45 классов объектов, из которых – 27 листовых, 10 видов отношений между объектами. В частности, модель включает понятия «Губернатор», «Вице-губернатор», «Правительство», «Аппарат Правительства», «Министерство», «Иной орган исполнительной власти» и т.д. В рассматриваемой редакции модели детализация производится до уровня органов исполнительной власти, не затрагивая их внутреннюю структуру. Исключение сделано лишь для организационной структуры аппарата Правительства.

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

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

Обозреватель моделей

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

Фундаментальный анализ проблем визуализации графов (а именно эта абстракция чаще других применяется для представления информации, которую можно промоделировать в виде объектов и связей между ними), включая обзор компьютерных инструментальных систем визуализации, дан в [Касьянов и др., 2003]. Выполненное нами исследование этой проблематики позволило сделать вывод о необходимости разработки методов и инструментов, адекватных специфике онтологического подхода при моделировании сложных систем.

Эта специфика заключается не только и не столько в необходимости представления особенных компонентов рассматриваемых структур (т.е. объектов, их атрибутов, связей и классов) или в способе представления больших объектных структур. Глубинная специфика онтологического подхода состоит, на наш взгляд, в необходимости совместного, одновременного манипулирования в приложениях несколькими такими структурами, которые совместно описывают многоаспектную семантику моделируемой предметной области [Смирнов, 1999], [Смирнов, 2004]. Это понимание вполне отвечает представлениям о многомодельных системах в общей парадигме гибридных методов решения задач [Емельянов и др., 2003].

Обозреватель объектных моделей, обладающий требуемой уникальной функциональностью, разработан как специальное приложение инструментальной системы gB. Для структуризации обозрения были объединены идеи методов блочного представления объектных моделей [Виттих и др., 2004] и локально-радиального обзора свойств избранного объекта, который предложен для семантических сетей М. Штефанером из Института прикладных информационных технологий Общества им. Фраунгофера (см. http://www.der-mo.net). Приоритетная новизна разработанного обозревателя состоит в наличии средств «гиперперехода» между сосуществующими в обозреваемом приложении контекстами моделирования. С целью увязывания различных контекстов моделирования сложной системы предложено динамически внедрять в обозреваемые диаграммы объектов и связей семантически релевантные содержанию диаграммы псевдообъекты — «класс обозреваемого объекта» и «лицо многоликого объекта задачи» (о необходимости введения в приложения «многоликих» объектов задачи см. [Смирнов, 2004]). Применение к псевдообъекту стандартных для обозревателя способов навигации в объектном пространстве влечет «гиперпереход» к обозрению объектной модели сосуществующего контекста моделирования.

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

Конфигурирование услуг электронного государства на основе онтологий (Ontology-enabled e-Gov Service Configuration)

OntoGov — проект Евро-союза, направленный на разработку семантически обогащенной платформы на основе онтологий, которая обеспечит последовательные (непротиворечивые):

• построение,
• переконфигурацию,
• эволюцию услуг электронного государства.

Основными задачами проекта являются:

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

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

Рис. 5. Архитектура среды конфигурирования сервисов

Для поддержки логической архитектуры на основе анализа Semantic Web Services (i.e. OWL-S and WSMO) был определен набор онтологий, которые можно обобщить в 3 следущие группы:

• Мета-онтологии
• Онтологии предметных областей
• Административные онтологии

Мета-онтологии определяют схему, то есть язык для описания услуг электронного правительства. Онтологии предметных областей моделируют конкретные услуги электронного правительства и описывают данные, необходимые для этих услуг. Основная онтология в данной группе — это так называемая Онтология Услуг, которая отражает услуги электронного правительства. Поскольку целью проекта является улучшение управления услугами электронного государства, были созданы административные онтологии. Подробнее см. http://www.ontogov.com/.

Заключение

Резюмируя описание примеров использования онтологий в организационном моделировании, можно сказать, что результаты проектов Enterprise Project, TOVE, PSL, SUPER не удовлетворяют необходимым требованиям, предъявленным к системам организационного моделирования. В первую очередь, это связано с тем, что предлагаемые в них модели и методы не дают комплексного решения. Они либо не интегрированы с существующими инструментами автоматизированной поддержки организационного проектирования (TOVE, PSL), либо поддерживают решения частных задач (автоматизация бизнес-процессов организации — Enterprise Project, поддержка рассуждений на основе формальной организационной модели — TOVE), либо покрывают только часть области организационного проектирования (например, моделирование только бизнес-процессов — PSL). Проект SUPER находится в начальной стадии, а также он, в первую очередь, ориентирован на задачу автоматизации бизнес-процессов организаций.

Литература

1. Abecker, A.; Apostolou, D.; Hinkelmann, K.; Probst, F.; Stojanovic, L.; Tambouris, T. Ontology-enabled E-Government Service Configuration - The OntoGov Approach. In: Wimmer, Maria A. (Ed.): e-Gov Days: state-of-the-art 2004. Tagungsband zu den dritten e-Gov Days des Forums eGovernment. Wien: OCG 2004.
2. Bock, C., Gruninger, M., "PSL: A Semantic Domain for Flow Models," Software and Systems Modeling Journal, 2005.
3. Fox, M.S. "The TOVE Project: A Common-sense Model of the Enterprise", Industrial and Engineering Applications of Artificial Intelligence and Expert Systems, Belli, F. and Radermacher, F.J. (Eds.), Lecture Notes in Artificial Intelligence # 604, 1992. Berlin: Springer-Verlag, pp. 25-34.
4. Fox M., Barbuceanu M., Gruninger M.; Lin J. An Organization Ontology for Enterprise Modelling. Simulating Organizations: Computational Models of Institutions and Groups, Menlo Park CA: AAAI/MIT Press, pp. 131-152. 1997.
5. Gomez-Perez A. Ontologies: Theory, methods and tools. Tutorial. The Fourth Summer School on Ontological Engineering and the Semantic Web, 2006 (SSSW'06).
6. Gruninger M., Atefi K., Fox, M., Ontologies to support process integration in enterprise engineering, Computational and Mathematical Organization Theory, 6, pp. 381-394, 2000.
7. Hepp, Martin et al.: Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management. IEEE International Conference on e-Business Engineering (ICEBE 2005). Beijing, China, October 18-20, 2005, pp. 535-540.
8. Hepp M., Roman D. An Ontology Framework for Semantic Business Process Management, Proceedings of Wirtschaftsinformatik 2007, February 28 - March 2, 2007, Karlsruhe
9. Stader J., Results of the Enterprise Project // Proceedings of Expert Systems '96, the 16th Annual Conference of the British Computer Society Specialist Group on Expert Systems, Cambridge, UK, December 1996.
10. Uschold M., King M., Moralee S. and Zorgios Y. The Enterprise Ontology AIAI, The University of Edinburgh, 1997.
11. Батищев С.В. , Виттих В.А., Генералова Л.Д. и др.  Онтология социокультурных ресурсов Самарской области // Проблемы управления и моделирования в сложных системах: Труды V международной конф. (Самара, 17-21 июня 2003 г.). — Самара: СамНЦ РАН, 2003.- С. 402-409.
12. Виттих В.А., Ситников П.В., Смирнов С.В. Понятийное и объектное моделирование властных структур // Труды 10-й Национальной конференции по искусственному интеллекту с международным участием (КИИ-06), 26-28 сентября 2006.
13. Виттих В.А., Иванова Л.А. , Королева Е.Н. и др. Проблемы онтологической спецификации объектов региональной экономики // Проблемы управления и моделирования в сложных системах: Труды VI международной конф. (Самара, 14-17 июня 2004 г.). — Самара: СамНЦ РАН, 2004. — С. 322-327.
14. Волхонцев Д.В. , Гриценко Е.А. , Зубайдулаева Е.Ю. и др.  Разработка конструктора нормативно-правовой базы знаний для социальной сферы // Проблемы управления и моделирования в сложных системах: Труды VII международной конф. (Самара, 27 июня-2 июля 2005 г.). — Самара: СамНЦ РАН, 2005. С. 357-365.
15. Гаврилова Т. Онтологический подход к управлению знаниями при разработке корпоративных информационных систем. // Ж. "Новости искусственного интеллекта", N2, 2003. - с.24-30.
16. Емельянов В.В., Курейчик В.В., Курейчик В.М. Теория и практика эволюционного моделирования. — М.: ФИЗМАТЛИТ, 2003.
17. Касьянов В.Н., Евстигнеев В.А. Графы в программировании: обработка, визуализация и применение. — СПб.: БХВ-Петербург, 2003.
18. [Концепция, 2005]  Концепция административной реформы в Российской Федерации в 2006–2008 годах и план мероприятий по проведению административной реформы в Российской Федерации в 2006–2008 годах (одобрены распоряжением Правительства РФ от 25 октября 2005 г. № 1789-р).
19. Смирнов С.В. Открытая архитектура инструментальных средств моделирования сложных систем // Проблемы управления и моделирования в сложных системах: Труды международной конф. (Самара, 15-17 июня 1999 г.). — Самара: СамНЦ РАН, 1999. - С. 59-66.
20. Смирнов С.В. Онтологии в прикладных интеллектуальных системах: прагматический подход // Девятая Национальная конф. по искусственному интеллекту с международным участием КИИ-2004 (Тверь, 28 сентября-2 октября 2004 г.): Труды конф. Т. 3. — М.: ФИЗМАТЛИТ, 2004.. - С. 1059-1067.
21. Титов К.А., Виттих В.А. Концепция организации процессов управления в регионе // Проблемы управления и моделирования в сложных системах: Труды VIII международной конф. (Самара, 24-28 июня 2006 г.). — Самара: СамНЦ РАН, 2006. С. 305-313.
22. Хасаев Г.Р. , Виттих В.А., Иванова Л.А. и др.  Региональная экономика как объект онтологического анализа // Известия Самарского научного центра РАН. 2003. Т. 5. № 1. — С. 74-82.
23. [Эталонные модели, 2006] «Эталонные модели организации деятельности в государственном секторе» // Отчет по научно-исследовательской работе выполненной сотрудниками АНО КМЦ «Бизнес-Инжиниринг» совместно с ИПГМУ ВШЭ, 2006 г.