среда, 28 сентября 2016 г.

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.

понедельник, 26 сентября 2016 г.

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Что происходит с компанией, которая поймала тренд?
А.К.: Если компания действительно поймала значимый, сильный тренд, стала «единорогом», она проходит две стадии. На первом этапе переживает вдохновение: «Мы нашли, мы поверили, мы переступили через сомнения, мы начали реализовывать!». Затем наступает определенное разочарование, связанное с тем, что действительно серьезные значимые тренды не приносят результат быстро. Бывает также, что компания опередила рынок.
Очень важна постоянная работа с изменениям: внедрение инноваций и отслеживание результата. Некоторое время назад тренд поймали компании, которые серьезно занимались контент-маркетингом. В период, когда все искали суперпродавцов, эти компании, благодаря интересному исследовательскому контенту, смогли попасть в круг внимания первых лиц, к которым не мог пробиться ни один продавец. Это преимущество действовало до тех пор, пока другие компании тоже не занялись контент-маркетингом. Попутный ветер не бывает постоянным, он рано или поздно заканчивается. Это значит, что поиски попутного ветра должны быть постоянными.