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

Татьяна Гаврилова

Введение

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

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

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

Также как в одежде, целевая функция всех систем автоматизации неизменна, это информационная поддержка бизнеса или производства. Все. Дальнейшее зависит от взгляда - как смотреть на весь этот муравейник – сверху, сбоку, изнутри, по-этажно, по-процессно, по-объектно…

Вторая причина связана как раз с различиями во взглядах, или в целях. Название класса системы обычно указывает на ее целевую функцию и это хорошо надо понимать, чтобы потом не удивляться почему пробуксовывает, например, финансовый модуль в западной системе, ориентированной на работу с клиентами класса СRM (Сustomer Relationship Management). Также невозможно требовать от бухгалтерской системы функциональности, присущей, например, системам работы с поставщиками класса SCM (Supply Chain Manament)

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

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

Выход из этого тупика придуман не нами – это услуги консультантов и/или подготовка аналитиков на предприятии. Подготовка аналитиков настолько сложная задача, что заслуживает отдельного разговора (см. далее).

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

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

 Рис 1. Роль структурирования в автоматизации

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

Новая концепция «управление знаниями» (УЗ) или Knowledge Management (КМ) действительно помогает поменять взгляд на автоматизацию корпорации, так как акцент в ней ставится на ценность информации. Новизна концепции УЗ заключается в принципиально новой задаче – копить не разрозненную информацию, а знания, т.е. закономерности и принципы, позволяющие решать реальные производственные и бизнес-задачи. При этом в расчет берутся и те знания, которые «невидимы» – они хранятся в памяти специалистов, а не на материальных носителях.

1. Двойственность понятия «управление знаниями»

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

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

Управление знаниями  можно рассматривать и как новое направление в менеджменте, и как направление в информатике для поддержки процессов создания, распространения, обработки и использования знаний внутри предприятия (Рис.2).

Рис.2. Дуализм дисциплины “Управлеие знаниями”

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

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

Рис.3. “Цветок“ информационных составляющих Традиционно проектировщики систем УЗ (СУЗ) ориентировались лишь на отдельные группы потребителей — главным образом, менеджеров. Более современные СУЗ спроектированы уже в расчете на целую организацию Из-за этого разнообразия СУЗ вынуждены интегрировать разнообразные технологии: электронная почта и Интернет-ресурсы; системы управления базами данных (СУБД) и сами базы данных (БД); средства создания хранилищ данных (Data Warehousing); системы поддержки групповой работы; локальные корпоративные системы автоматизации; системы документооборота и worlflow; экспертные системы и базы знаний и др. При этом, ни одна из этих технологий (кроме последней) не включает «знания» в контексте интеллектуальных (экспертных) систем, т.е. баз знаний. Фактически УЗ – это модный лозунг в менеджменте и его связь с инженерией знаний (knowledge engineering) в настоящее время практически эфемерна. Нечеткость различий в понятиях «информация», «данные» и «знания» льет воду на мельницу спекуляций эту тему. Если трактовать информацию, как общий термин для всех информационных ресурсов предприятия (рис.4), то в реальности современные СУЗ занимаются проблемой организации только части информации, в основном документооборота в компании. Рис. 4. Основные типы информации в системах KM «Мостиком» к интеллектуальным технологиям является понятие «знания», которое трактуется в УЗ крайне свободно и широко. В СУЗ знаниями называют все виды информации (они включают руководства, письма, новости, информацию о заказчиках, сведения о конкурентах и технологии, накопившиеся в процессе разработки), в то время как традиционно под знаниями понимаются закономерности предметной области, позволяющие специалистам решать свои задачи. Они получены в результате практического опыта или почерпнуты из литературы. Фактически системы, позиционирующие себя как СУЗ – системы управления знаниями (Fulcrum, Documentum i4, Knowledge Station, etc.)[Попов, 2001] реализуют лишь отдельные элементы вышепреведенного списка. Все они работают либо с неструктурированной информацией в форме документов, либо с данными (рис.4) Это ситуация as is (как есть), а хотелось бы включения и знаний. 2. Корпоративная память и онтологии Программные инструментарии для создания хранилищ данных, которые работают по принципу центрального склада, были одним из первых предвестников СУЗ. Как правило, хранилища содержат многолетние версии обычной БД, физически размещаемые в той же самой базе. Когда все данные содержатся в едином хранилище, изучение и анализ связей между отдельными элементами может быть более плодотворным. В дальнейшем идея хранилища была развита в понятие корпоративной памяти (corporate memory) [Kuhn, Abecker, 1998], которая по аналогии с человеческой памятью позволяет пользоваться предыдущим опытом и избегать повторения ошибок, что является пока достаточно декларативным утверждением. Корпоративная память хранит гетерогенную информацию (документы, чертежи, базы данных, базы знаний) из различных источников предприятия и делает эту информацию доступной специалистам для решения производственных задач. хранит гетерогенную информацию (документы, чертежи, базы данных, базы знаний) из различных источников предприятия и делает эту информацию доступной специалистам для решения производственных задач. Существуют различные подходы, модели и языки, ориентированные на интегрированное описание данных и знаний. Однако все большую популярность последнее время приобретают онтологии. Существует множество различных подходов к определению понятия «онтология» [Gruber, 1993]: Онтологией называют эксплицитную спецификацию концептуализации. Онтология – эксплицитная спецификация определенной темы. Онтология – это базы знаний специального типа, которые могут читаться и пониматься, отчуждаться от разработчика и/или физически разделяться их пользователями. Следует отметить, что понимание термина «онтология» зависит от контекста и целей его использования. Можно выделить несколько аспектов его применения, в частности, в работе [Guarino, et al., 1995] выделяются следующие интерпретации: Онтология как философская дисциплина. Онтология как неформальная концептуальная система. Онтология как формальный взгляд на семантику. Онтология как спецификация концептуализации. Онтология как представление концептуальной системы через логическую теорию. Онтология как словарь, используемый логической теорией. Резюмируя все вышесказанное, можно сказать, что онтология – это точная спецификация некоторой области, которая включает в себя словарь терминов предметной области и множество связей (типа «элемент-класс», «часть –целое»), которые описывают, как эти термины соотносятся между собой. Фактически это иерархический понятийный скелет предметной области. К сожалению, при разработке новых и использовании существующих онтологий возникает множество трудностей. В работе [Arpirez J.; Gomez-Perez, A.; Lozano, A; Pinto S, 1998] выделяются, в частности, следующие: Отсутствие стандартизованных идентифицирующих особенностей, которые характеризовали бы онтологии с точки зрения пользователя. Разный уровень детализации онтологий, находящихся на одном сервере. Отсутствие web-сайтов, использующих одинаковую логическую структуру и предоставляющих релевантную информацию об онтологиях. Поиск подходящих онтологий сложен, занимает много времени, а также часто безрезультатен. Эти трудности приводят к тому, что под конкретные задачи подчас невозможно найти подходящую онтологию из числа существующих, поэтому приходится браться за создание новой, что, естественно, является сложным и достаточно дорогостоящим процессом. Кроме того, использование готовых онтологий непосредственно людьми (в отличие от использования программными агентами) обладает еще рядом недостатков. В частности, знания разных людей могут укладываться в разные онтологии, при этом нельзя утверждать, что одна из них лучше другой. Также во многих случаях для одного предприятия или для трудно-формализуемой предметной области (медицина, юриспруденция) можно построить несколько различных онтологий. Например, историю можно воспринимать как хронику последовательных событий, а можно как жизнь различных людей, в этих событиях участвующих. Формально это две различные онтологии: в первом случае, в качестве концептов выступают исторические события, а во втором — личности. Но по сути, обеонтологии полно описывают одну и ту же предметную область. Онтология — это структурная спецификация некоторой предметной области, ее формализованное представление, которое включает словарь (или имена) указателей на термины предметной области и логические связи, которые описывают, как они соотносятся друг с другом. Например, рис. 5 иллюстрирует фрагмент классической онтологии документа. Таким образом, онтологии обеспечивают словарь для представления и обмена знаниями о некоторой предметной области и множество связей, установленных между терминами в этом словаре. Для описания онтологий и работы с ними существуют различные языки и системы, однако, наиболее перспективным представляется визуальный подход, позволяющий специалистам непосредственно «рисовать» онтологии, что помогает наглядно сформулировать и объяснить природу и структуру явлений. Визуальные модели, например графы, обладают особенной когнитивной (т.е. познавательной) силой. Любой программный графический пакет от PaintBrush до Visio можно использовать как первичный инструмент описания онтологий. Рис.5. Пример визуального представления фрагмента онтологии На рис.5 представлена онтология, нарисованная с использованием графического инструмента CAKE-2 (Computer-Aided Knowledge Engineering) (разработчик Т.Е.Гелеверя), методологические основы которого были описаны в работе [Гаврилова, Воинов, Данцин, 1996]. Онтологический инжиниринг Онтологический инжиниринг – это процесс проектирования и разработки онтологий. При отсутствии общепринятой методологии и технологии этот процесс не является тривиальной задачей. Он требует от разработчиков профессионального владения технологиями инженерии знаний – от методов извлечения знаний до структурирования и формализации [Гаврилова, Хорошевский, 2000]. Онтологический инжиниринг подразумевает глубокий структурный анализ предметной области. Такую работу для интеллектуальных систем обычно выполняют инженеры по знаниям (knowledge engineers). Сегодня фактически ни один российский вуз не готовит аналитиков или инженеров по знаниям, владеющих методами инженерии знаний. Наиболее близкими являются специальности инженера-системохника и специалиста по информационным технологиям (ИТ). Хотя последние, чаще всего просто программисты. Существующие первые попытки подготовить специалистов более широкого профиля, например специализации подготовки CIO (Chief Information Officer), или MBI (Master of Business Information), следует приветствовать, но они в большей степени ориентированы на менеджеров ИТ, а не аналитиков. Модуль 1. Введение в инженерию данных и знаний (12 часов, 8 практических тестов) 1.1. Работа с информацией: данные и знания 1. 3. Модели представления знаний 1. 4. Работа с нечеткой информацией 1. 5. Стратегии получения информации 1. 6. Психологический аспект извлечения знаний и данных 1. 7. Лингвистический и аспект извлечения знаний и данных 1. 8. Методический аспект извлечения знаний и данных   Модуль 2. Практическая инженерия знаний (16 часов, 10 практических тестов) 2.1. Индивидуальные коммуникативные методы извлечения данных и знаний 2.2. Групповые коммуникативные методы извлечения 2.3.Текстологические методы 2.4. Структурирование данных и знаний: объектно-структурный анализ 2.5. Онтологии и визуальное моделирование 2.6. Функциональные роли в коллективе разработчиков Рис.6 . Программа ШКОЛЫ АНАЛИТИКА Появились и первые “Школы аналитиков” (программа одной такой школы представлена на рис.6 и сайте www.bae.ru), но число их выпускников весьма не значительно для изменения ситуации. Для профессионального аналитика онтологический инжиниринг является методологической “путеводной нитью” в течение процесса структурирования при создании комплексных систем автоматизации, так как он объединяет две основные технологии проектирования больших систем – объектно-ориентированный и структурный анализ. Понятие онтологии и онтологического анализа вошли и в процедуры и стандарты моделирования бизнес-процессов. Ведь описание бизнес-процесса – это по сути структурирование данных и знаний. Так в группе стандартов IDEF, который является основным средством спецификации корпоративных информационных систем (КИC) и моделирования бизнес-процессов сегодня, имеется стандарт IDEF5 для описания онтологий. Сам визуальный онтологический инжиниринг является мощным когнитивным инструментом, позволяющим сделать видимыми структуры корпоративного знания. Можно привести простейший алгоритм онтологического инжиниринга («для чайников»): выделение концептов — базовых понятий данной предметной области; определение «высоты дерева онтологий» – числа уровней абстракции; распределение концептов по уровням; построение связей между концептами — определение отношений и взаимодействий базовых понятий; консультации с различными специалистами для исключения противоречий и неточностей. При явном интересе к онтологическому инжинирингу (системы ONTOLINGVA, Ontobroker, SHOE и другие) в настоящее время трудно назвать промышленные систем проектирования онтологий. Нами разработано несколько программных продуктов CAKE (Сомputer Aided Knowledge Engineering) [Воинов, Гаврилова, Данцин, 1996], ВИКОНТ — ВИзуальный Конструктор ОНТологий [Гаврилова, Лещева, 20000; Gavrilova, Fertman, 2001.] и VITA (VIsual onTology-based hypertext Authoring tool)[Gavrilova, Geleverya, 2001], позволяющих визуально проектировать онтологии различных предметных областей. Обычно онтология строится как дерево или сеть, состоящая из концептов и связей между ними. Связи могут быть различного типа, например, "является", "имеет свойство" и т. п. Концепты и связи имеют универсальный характер для некоторого класса понятий предметной области. Можно выбрать некоторое понятие из этого класса и для него "заполнить" онтологию, задавая конкретные значения атрибутам. Заключение Онтологический подход к проектированию КИС позволяет создавать системы, в которых знания становятся «видимыми» и доступными для большинства сотрудников. На основе онтологий можно разрабатывать «карты знаний» (K-maps), которые указывают явно на источники знаний, т.е. где и у кого можно эти знания получить. В результате интерес к системам СУЗ растет по следующим причинам: работники предприятия тратят слишком много времени на поиск необходимой информации; опыт ведущих и наиболее квалифицированных сотрудников используется только ими самими; ценная информация захоронена в огромном количестве документов и данных, доступ к которым затруднен; дорогостоящие ошибки повторяются из-за недостаточной информированности и игнорирования предыдущего опыта. Основным преимуществом онтологического инжиниринга в KM является целостный подход к автоматизации предприятия. При этом достигаются: системность — онтология представляет целостный взгляд на предметную область; единообразие — материал, представленный в единой форме гораздо лучше воспринимается и воспроизводится; научность — построение онтологии позволяет восстановить недостающие логические связи во всей их полноте. Стоит еще раз подчеркнуть, что онтология не только цель, но и средство формирования СУЗ. Важность онтологического подхода в СУЗ обусловлена также тем, что знание, которое не описано и не тиражировано, в конечном счете становится устаревшим и бесполезным. Напротив, знание, которое распространяется, приобретается и обменивается, генерирует новое знание. Таким образом, любая система автоматизации затрагивает проблемы хранения корпоративных знаний, но только СУЗ ориентированы на это в явном виде, тем самым способствуя сохранению этого ценнейшего ресурса, а не растворяя его в алгоритмах, программах, документации, технологических процессах. СУЗ фактически может предоставить более высокий уровень автоматизации для тех компаний, которые уже справились с автоматизацией данных. Для тех предприятий, которые хотят создать интегрированную корпоративную систему, а не “мозаику” отдельных функциональных блоков, СУЗ является хорошей стартовой площадкой. Автор выражает искреннюю благодарность Э.В. Попову за методическую и дружескую поддержку при работе над данной статьей. Примечание [1] Работа выполнена при поддержке Российского Фонда Фундаментальных Исследований (грант 01-011-00224) Литература Гаврилова ТА., Хорошевский В.Ф. Базы знаний интеллектуальных систем / Учебник для вузов. – СПб, Изд-во “Питер”, 2000. Воинов А., Гаврилова Т. А., Данцин Е. Я., 1996. Язык визуального представления знаний и его место в САКЕ-технологии // Журнал Известия РАН, Теория и системы управления, N2. - c.146-151. Гаврилова Т.А., Лещева И.А., Лещев Д.В., 2000. Использование онтологий в качестве дидактического средства // ”Искусственный интеллект” N3. - с.34-39. Попов Э.В., 2001. Корпоративные системы управления знаниями. Ж.”Новости ИИ”,N1. Arpirez J., Gomez- Perez A., Lozano A., Pinto S. (ONTO) 2Agent: An ontology- based WWW broker to select Ontologies // Workshop on Applications of ontologies and Problem Solving Methods. ECAI’98. Borghoff U., Pareschi R., 1998. Information Technology for Knowledge Management. – Springer-Verlag, Bln. Gavrilova T., Geleverya T., 2001. VITA: Using PYTHON for Visual Design of Web-based Tutorials// Proc. of the Tenth International PEG Conference “Intelligent Computer and Communications Technology – Learning in On-Line Communities”, Tampere, Finland. - pp.44-50. Gavrilova T., Fertman V. One Approach to Visual Design of Intelligent Agents // Proceedings of the Second International Workshop of Central and Eastern Euope on Multi-Agent Systems, CEEMAS’01, Krakow, Poland, 2001. - pp.329-337. Gruber T. R.  A translation approach to portable ontologies. Knowledge Acquisition, 5(2):199-220, 1993. Guarino N., Giaretta P. Ontologies and Knowledge Bases: Towards a Terminological Clarification. Towards Very Large Knowledge Bases: Knowledge Building & Knowledge Sharing. // IOS Press. 1995. 25-32. Hinkelmann K. and Kieninger Th. Task-oriented web-search refinement and information filtering. DFKI GmbH, 1997. Kuhn O., Abecker A., 1998. Corporate Memories for Knowledge Management in Industrial Practice: Prospects and Challenges. Kuhn O., Becker V., Lohse V. and Ph. Neumann, 1994. Integrated Knowledge Utilization and Evolution for the Conservation of Corporate Know-How // ISMICK'94: Int. Symposium on the Management of Industrial and Corporate Knowledge Macintosh A., 1997. Knowledge asset management. // Airing. – №20, April. Malsch Th., Bachmann R., Jonas M., Mill U., and Ziegler S., 1993. Expertensysteme in der Abseitsfalle? - Fallstudien aus der industriellen Praxis. edition sigma, Reiner Bohn Verlag, Berlin. Nonaka I. and Takeuchi I., 1995. The Knowledge-Creating Company. New York, Oxford: Oxford University Press Piatetsky-Shapiro G. and Frawley W., eds., 1991. Knowledge Discovery in Databases. – AAAI/MIT Press. Tschaitschian B., Abecker A. and Schmalhofer, 1997. A. Putting Knowledge Into Action: Information Tuning With KARAT. // In 10th European Workshop on Knowledge Acquisition, Modeling, and Management (EKAW-97). Wiig, 1990. Expert Systems: A manager’s guide. – Geneva: The International Labour Office of the United Nations. Wiig К., 1996. Knowledge management is no illusion! // Proc. of the First International Conference on Practical Aspects of Knowledge Management. – Zurich, Switzerland: Swiss Informaticians Society

Feature Comparison Matrix

What is a Feature Comparison Matrix?

As the name specifies, it is a matrix which compares the availability of different Features of various Products of similar kind. 

When do you need a Feature Comparison Matrix?

• If you want to compare Features of various Products of similar class.

• If you are working in Software Product Development Company, and you are part of a new Product Development Process. At that time, you need to do a Market Analysis & Industry Analysis to understand the Vendors (Competitors) who are providing similar kind of Products. As a result of your Market/Industry Analysis, you need to come up with a Feature Comparison Matrix which will show-case the various features offered by similar kind of Products and which all features exist in which Product.

• If you are working in a Project, and the Project requires a specific 3rd Party Product to be integrated for a particular module. E.g.: If you are working in a "Treasury" Management System, and you require a 3rd party application for "Forex Pricing Engine". So you need to identify the Vendor's Products you are looking and go through the details of those products and prepare a Feature comparison Matrix, which can be used later for Vendor/Product Evaluation.

How to prepare a Feature Comparison Matrix?

Let's go through a sample Feature Comparison Matrix which I have created. 

Pic: Sample Feature Comparison Matrix

Steps:

1.  Identify the Vendors, whose Products you will be comparing. To do this, go through various Analyst Sites to identify the Top Vendors who offer the similar kind of Products.

E.g.: We would like to have a Product for "Mortgage Management System". Identify all Vendor Products and choose top 5 Vendor Products for comparison. 

2.  Identify all possible Features present in all the Products, which should be a Super Set of Features. List these features Module-wise. If you are aiming for developing any Product, then Identify and list all possible Features you want to have in the Product and then compare the same with other Vendor Products.

E.g.: Identify various Modules in a "Mortgage Management System", such as: Loan Origination, Loan Underwriting, Loan Closing and Loan Servicing. Then list out all possible features/requirements for each of the Modules.

3.  List out all Vendor-Products and mark against the features which are available in that Product. Please refer to the above picture.

Analyzing the Feature Comparison Matrix Result:

1.  The last row (No. of Features Available out of 14) in the picture shows that:

• There are total 14 features in the Matrix. Out of 14 features, how many features are present in each Vendor Product.
• "Vendor 1 - Product 1" satisfies maximum number of features i.e. 10.
• "Vendor 4 - Product 4" satisfies minimum number of features i.e. 5.

2. The last column depicts the count of Vendor Products where a Particular Feature is available. 

• "Feature - 11" is present in all the 4 Vendor Products.
• "Feature - 2" is present in only one Vendor Product.

These kind of analysis helps in understanding and identifying which Vendor Product meets to our expectation. While finalizing a particular Product, we need to consider the Product Pricing as well as a main criteria.

Hope this article help you out in understanding the practical approach of a Feature Comparison Matrix. Do let me know you feedback through your comments.

As We Work...We Learn...

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!