RPA — это мода или принципиально новый подход к автоматизации?

 

МАРИЯ ШАНТАРЕНКОВА

Часть 1. Плюсы и минусы

Robotic Process Automation (RPA) — это одна из многих технологий автоматизации, которые сейчас на слуху. Это, несомненно, хайп, но стоит ли за ним что-то реальное? Чем роботизация процессов отличается от их автоматизации и от других технологий, которые на слуху? RPA — это лишь модное слово или принципиально новый подход к автоматизации? Попробуем разобраться.

RPA — это легкая автоматизация

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

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

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

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

Класс технологий RPA имеет три отличительные особенности, которые отличают его от «классической автоматизации» процессов и функций.

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

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

Плюсы и минусы технологий RPA

Прежде всего, стоит отметить, технологии RPA идут в русле современных тенденций в ИТ.

1. Требования к автоматизации растут и нередко, доходят до некоторой крайности — прямо сейчас и желательно без длинных проектов, утверждений и согласований и программные роботы отвечают на эту потребность.
2. Упрощение процесса создания прикладной системы, переход на создание ее из готовых кубиков — low-code и no-code. В целом RPA идет в русле идей low-code.
3. Вследствие использования подхода low-code увеличивается круг специалистов, кому под силу конфигурировать роботов и сокращается время на создание и внедрение. Роботизация идет не силами ИТ, а самих пользователей. Программисты в ИТ, как правило, заняты, поставят вашу задачу в очередь, и сделают через полгода. Роботизация обещает сделать быстрее — пользователи сами, с минимумом знаний могут автоматизировать несложные операции.
4. Боты хорошо коррелируют с привычками поколения Z, которое скоро придет в наши компании. Они привыкли к быстрому и удобному ИТ и привыкнут к роботам и скорее будут удивлены, если сотрудники будут руками вбивать данные.

Таблица. Технологические плюсы и минусы RPA

Плюсы	Минусы
Робот надежен, он работает в режиме 24×7×365, всегда на месте, не ходит на обед и не болеет	В реальности робот может «висеть» по сотне причин, роботу нужна постоянная поддержка и сопровождение.
Технологии PRA могут использовать разработанный для человека пользовательский интерфейс для сбора данных и управления приложениями	Это выглядит странно: сначала мы разрабатываем интерфейсы для людей, а когда люди не справляются, заставляем в этих же интерфейсах работать роботов. Хотя роботы работают в виртуальной среде, а не на физическом экране, робот моделирует экран, согласитесь, такая автоматизация крайне нелогична. Ведь гораздо эффективнее изначально «зашивать» таких роботов в систему, минуя человеко-ориентированный пользовательский интерфейс?
Роботы не ошибаются и не путают буквы	Бывает, что путают, например, при сборе данных и обработке контента для них тоже важно, в какой последовательности написаны имя и фамилия или при смене интерфейса (напомним, традиционные PRA-боты не обладают искусственным интеллектом)
В робота можно заложить несколько различных функций, и он способен быстро переключаться между ними, тогда как человека очень сложно быстро переключить из контекста в контекст	Но при этом уходит та легкость настройки роботов в парадигме low-code, которой так гордятся поставщики этих технологий. Такие боты уже не просты, так как должны понимать смену контекста. Если сотрудник в течение дня занимается десятками разных задач, то использовать технологии RPA здесь будет не просто
Простота, технология в которую легко погрузиться и почти любой это сможет	Это не совсем так, для конфигурирования ботов нужны технический бэкграунд и знание азов программирования

В таблице мы свели технологические плюсы и минусы технологии RPA. Плюсы и отличительные черты технологии RPA вызвали серьезную ее популярность. По данным Gartner, ПО для роботизации процессов (RPA) — это самый быстрорастущий сегмент ПО из всех, которые она отслеживает. Он растет очень быстро на 63% в год. В 2018 г. его объем составлял менее 850 млн. долл., то в 2019 г. он достиг примерно 1,3 млрд. долл., а в 2022 достигнет 2,4 млрд. долл.

Естественно, у технологии RPA существуют и минусы, которые мы показали в таблице. Однако, главное, на наш взгляд, не это, а шумиха вокруг RPA. Хайп — это всегда плохо, это завышенные обещания и надежды, которые потом летят в «пропасть разочарования». Многие считают, что RPA — это эволюция технологий создания прикладной системы. Рутину — роботам, творческие задачи — людям. Перебивать данные из бумажки в систему — это не работа для людей. И те технологии, которые это провозглашают, однозначно полезны и неизбежно должны привести к более эффективной работе. Однако, это заблуждение, избавляться от рутины, несомненно, надо, но делать это можно по-разному.

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

1. Проблема гибкости — робот не обладает гибкостью, а в реальном бизнесе существует масса ситуаций, когда надо не как обычно, а по-другому.
2. Проблема эффекта — автоматизация локальных и рутинных задач, это конечно полезно, но далеко не все. Да, есть бравурные речь об эффективности новой технологии. Так, предприниматель Дэвид Мосс рассказал, что цифровая работа в форме RPA не только может произвести революцию в модели затрат индустрии услуг за счет снижения цены на продукты и услуги, но, вероятно, повысит уровень обслуживания его качество. Многие эксперты ожидают, что технология RPA приведет к новой волне повышения производительности и эффективности на глобальном рынке труда.
   Однако, локальные улучшения отнюдь не всегда приводят к заметному росту производительности, снижению затрат и ошибок. Как известно, производительность системы будет определяться наименее производительным звеном, затраты — наиболее затратным, ошибки — наиболее часто ошибающимся. И кто сказал, что это именно те участки, которые автоматизирует RPA? Мало ли что пользователи посчитают полезным автоматизировать, это еще не означает, что этим имеет смысл заниматься. А поскольку в RPA-проектах на всю систему никто не смотрит (это ведь сложно), то никто и не гарантирует результат.
3. Проблема ответственности. Непонятно кто несет ответственность за работу робота, кто отвечает за неправильно сделанную операцию. Мы должны понимать, что есть процессы, которые мы не можем автоматизировать, их мы должны проводить через человеческий интеллект. Также есть ситуации, когда юридически мы не можем принимать решение при помощи автоматизированных систем, необходима верификация их человеком. Очень часто служба безопасности или юридическая служба требуют, чтобы конечную визу ставило конечное ответственное лицо.
4. Иллюзия легкости. Простая возможность работы с роботами притягательна и это многих мотивирует. Однако, это лишь самая верхушка айсберга. Хотя пользователям и может казаться, что они теперь «почти как ИТ-шники», это не так. Легкие технологии создают лишь иллюзию простоты.
5. Усложнение систем. Сложность систем, получившихся в результате использования RPA, увеличивается, причем практически бесконтрольно. Ведь при вовлечении пользователей их инициативы крайне сложно контролировать. Включение роботов в процессы, ведет к усложнению всей системы — технология должна учитывать использование графических пользовательских интерфейсов таким образом, каким они не предназначались для использования. И это повышает требования к квалификации сотрудников, а также требования к квалификации сотрудников ИТ.

Часть 2. Где использовать технологии RPA?

Области использования технологии RPA

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

1. Поддержка простых и максимально рутинных задач. Как правило, это кратно дешевле, чем другие средства автоматизации. Но необходимо разделить простые и сложные задачи. К последним, например, относится автоматизация длинной и сложной последовательности операций, которая, имеет много ветвлений, или данные не стандартизованы. Для сложных задач технологии RPA подходят плохо, тут лучше применить другие инструменты.
2. Временная заплатка для небольшой проблемы, которая пока не может быть конечным ИТ-решением (по различным причинам). RPA хорошо работает как временная замена, пока не внедрены более сложные и комплексные ИТ-системы.
3. Постоянный «костыль» на участке, где полноценная автоматизация невозможна, например, для унаследованных систем, которые уже никто не будет перерабатывать. Это может продлить жизнь унаследованной системе, если это необходимо.
4. Более дешевое решение в том, случае, если полноценная автоматизация неоправданно дорога. Финансовая эффективность ИТ-поддержки — это важный показатель. Если полноценная автоматизация процесса удорожает его, но не приносит увеличения дохода, делать ее не имеет смысла. Нельзя увлекаться автоматизацией. Здесь нужно искать какое-то более дешевое компромиссное решение, которым могут стать технологии RPA.
5. Гибкие и быстро изменяющиеся процессы, когда мы понимаем, что детально описывать процессы и затем автоматизировать нельзя, они могут меняться, причем быстро скажем раз в месяц. Здесь мы можем использовать технологии RPA и перенастраивать роботов синхронно с изменением процесса, либо мы вообще не используем средства автоматизации.

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

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

Примеры использования технологии RPA

Пример 1. Есть какая-то рутинная операция по передаче одной и той же информации из одной ИТ-системы в другую, и, предположим, ее невозможно автоматизировать традиционными технологиями, так как одна из систем старая и ее никто не будет дорабатывать, та как в планах через 2-3 года убрать эту систему. Либо для такой небольшой задачи интеграция оказывается неоправданно дорога. Но работать надо прямо сейчас и здесь технологии RPA могут довольно быстро помочь. Но такая автоматизация даст эффект, если эта передача информации действительно была узким местом. А если ваша старая система тормозит еще в 10 других местах ваш эффект будет близок к нулю.

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

Нужно внимательно посмотреть и протестировать, в каких случаях технологии RPA будут эффективны, а где нужно системно использовать комплексные технологии ИТ-поддержки. При слабом анализе и выборе неверных сценариев использования технологии RPA, потери и разочарования неизбежны.

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

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

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

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

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

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

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

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

Технологии RPA, BPA и другие подходы к автоматизации

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

Автоматизация бизнес-процессов (Business Process Automation, BPA) — по поводу этого термина нет единого мнения. Некоторые эксперты применяют в качестве зонтичного для любых технологий автоматизации процессов. Другие считают, что технологии BPA автоматизируют не отдельные операции и задачи, а сквозной процесс (от начала до конца). Таким образом, технологии BPA применяются для более длинных и сложных процессов, чем технологии RPA. Эти процессы обычно содержат множество ветвлений и вариантов, и их автоматизация с помощью RPA-ботов слишком сложна в настройке и обслуживании. В такой трактовке технология BPA приближается к старым известным BPM-системам, и, хотя, вообще говоря, это разные технологии для сравнения с RPA их можно объединить. Основные области применения этих двух технологий показаны в таблице 2.

Таблица 2. Основные области применения этих технологий RPA и BPA/BPM

Вид активности (операции / задачи / процесса)	Поддерживается частично	Поддерживается полностью
Короткие одиночные операции		RPA
Простые рутинные операции / задачи	BPA/BPM	RPA
Интеллектуальные задачи, которые не могут быть полностью автоматизированы из-за их творческой составляющей	BPA/BPM
Длительные процессы, состоящие из параллельных задач и ветвлений	RPA	BPA/BPM
Нестабильные и гибкие процессы	BPA/BPM
Ввод данных в систему	RPA
Взаимодействие между процессами	RPA	BPA/BPM
Мониторинг выполнения процессов		BPA/BPM

Заметим, что подход BPA/BPM хорошо согласовывается с RPA. Технология RPA — это автоматизация «снизу вверх», т.е. от отдельной задачи далее к более системной автоматизации. Мы «цепляем» одну задачу за другую задачу, постепенно охватывая весь процесс в целом. Технология BPM подразумевает движение сверху вниз, сначала мы смотрим на процесс в целом и автоматизируем его в целом, возможно опуская какие-то отдельные операции. А потом можем заняться детализацией процесса и поддержкой отдельных операций. Один подход не исключает другой.

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

В перспективе роботы поумнеют

Наконец, скажем пару слов о новом появляющемся классе технологий — интеллектуальной автоматизации процессов (Intelligence Process Automation, IPA). IPA — это результат эволюции RPA, когда к обычным неинтеллектуальным ботам добавляются интеллектуальные возможности машинного обучения и искусственного интеллекта. Это позволяет сделать робота умным и устранить несколько недостатков технологии RPA. Уже сейчас часть роботов используют элементы машинного обучения и искусственного интеллекта. Это позволяет снизить требования к структурированию и единообразию данных, и частично работать с неструктурированными данными. Распространение таких интеллектуальных ботов даст возможности автоматизации более самых сложных и гибких задач.

Усложнение ботов и их интеллектуализация — это очевидный путь развития. Эксперты компании Gartner считают, что технологии RPA будут двигаться от автоматизации отдельных задач в сторону большего охвата, автоматизации все более сложных задач, постепенно подбираясь к автоматизации уровне процессов. Это потребует новых, более сложных технологий и сейчас поставщики уже работают над ними. Директор по исследованиям компании Gartner Стефани Стоут-Хансен заявила, что «дорожные карты вендоров RPA по запуску продуктовых линеек отражают их желание задействовать более сложные технологии — компьютерное зрение, встроенную автоматизацию и автоматические системы».

https://bit.ly/3zuxAWp

Непрерывное управление эффективностью: новые правила

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

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

Управление эффективностью — это управление. 

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

Большие изменения

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

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

Сегодня более 85% капитализации на фондовом рынке — это интеллектуальная собственность, бренд, услуги и программное обеспечение, поэтому каждый человек имеет значение. На самом деле я бы предположил, что у нас теперь все наоборот: сотрудники (линейные) важнее, чем менеджеры для большинства компаний, поэтому нужно обратить все вспять и понять, что “менеджеры обслуживают сотрудников”, а не наоборот.

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

Подумайте о том, как меняются организации. В высокоэффективных компаниях люди работают в кросс-функциональных командах. У них могут быть руководитель проекта, спонсор карьеры или тренер (в Deloitte мы называем это консультантом по карьере, в WL Gore эта роль называется спонсор). Лидеры поддерживают эти команды, и многие лидеры являются функциональными лидерами, т.е. работают во многих командах (например, вице-президент по производству). Сама идея настройки цели сверху вниз, планирования сверху вниз и преемственности сверху вниз не применима в такой ситуации.

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

Мы идем к нему, но небольшими шагами. В настоящее время специалисты по персоналу и разработчики ПО изобрели целый набор новых слов (check-ins, чек-поинты, совещания для обратной связи, OKRs, обзоры целей, планы развития, социальное признание и т. д.) в попытке определить и построить процесс вокруг этой новой философии. И почти каждая компания экспериментирует (IBM, Deloitte, Cisco, NY Life, Adobe, WalMart и многие другие). Именно поэтому рынок так подвижен.

Рассмотрите все возможные практики

В этом новом мире есть много примеров, которые следует учитывать.

Я только что закончил читать новую книгу Джона Доерра “Measure What Matters” — это увлекательная история о Intel, Google, Intuit и многих знаковых быстрорастущих компаниях Кремниевой долины и о том, как они справились со своим ростом. Главная мысль заключается в том, что ОКR (простой процесс постановки целей, в котором создается измеримая цель и набор ключевых результатов, способствующих достижению этой цели) имел фундаментальное значение для их успеха.

Я также недавно прочитал “Принцип прогресса”, “Мышление роста”, “Экономика цели”, “Хорошая работа” и другие книги, которые объясняют, что цель, прогресс и непрерывный рост — это двигатели, способствующие нашей личной эффективности. Эти книги убедительно показывают, что ясность, цель и чувство роста — это то, что помогает людям работать, пока они знают, что делать. Т.е., все эти идеи также относятся к процессу эффективности.

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

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

Итак, это инновационное пространство, в котором сейчас много задач.

Как развивается рынок  

Некоторое время назад уже происходили подобные изменения: в какой-то момент SuccessFactors начали победное шествие по рынку благодаря их сфокусированному вниманию на business execution как на основной теме. Компании тогда просто хотели добиться бОльшего успеха, поэтому они покупали и внедряли комплекс программного обеспечения из cool-aid, каскадных целей, “строгих” целей и инструментов эффективности. Затем SAP приобрела SuccessFactors за 3,4 миллиарда долларов, Oracle приобрела Taleo, и рынок быстро консолидировался.

Этот цикл, после рецессии 2008 года, изменился. Есть десятки невероятно инновационных и успешных компаний (BetterWorks, HighGround, Impraise, Lattice, 7 Geese, Glint, Globoforce, 15 Five, Reflektiv, Standout (ADP), SuccessFactors, Zugata и многие другие — перечислены в алфавитном порядке) и у каждой собственные новые разработки. Рынок огромен (практически каждая организация хочет для себя какой-то продукт из этой категории), поэтому почти все эти компании растут. Произойдет ли и в этот раз подобная консолидация? Думаю, нет.

На этот раз, я думаю, рынок будет развиваться по-другому. Я считаю, что многие из этих компаний будут расти очень быстро, и со временем мы увидим набор различных инструментов управления, каждый из которых ориентирован на тип предприятия, отрасль, а также на размер и местоположение компаний, и все они будут привязаны к HCM-платформе компании. Конечно, SuccessFactors, Oracle, CornerstoneOnDemand и Workday продолжат играть на этом поле, но я предполагаю, что у них слишком много других дел, и они с большой вероятностью станут партнерами или приобретут со временем некоторые из новых компаний. ADP уже приобрела Standout, поэтому теперь у них есть предложение для своих клиентов.

На этот раз есть и другие отличия: огромный рост того, что я называю “системами продуктивности” на работе. Разработчики используют Jira, Trello и Github. Продавцы используют Salesforce. Операционщики Асану или Wrike. Белые воротнички используют Outlook365, Microsoft Team, Slack, G-Suite и Workplace от Facebook. В здравоохранении, производстве и других областях используют другие инструменты.

Эти “системы продуктивности” — это настоящие системы непрерывного управления эффективностью, потому что именно они измеряют то, что мы делаем каждый день. Например, каждая компания, использующая Salesforce, может каждый день рассказывать, сколько было создано потенциальных клиентов, сколько было закрыто продаж и сколько новых учетных записей обновлено. Никакое программное обеспечение для персонала никогда не сможет этого сделать, поэтому в конечном итоге новые HR-инструменты должны интегрироваться, сотрудничать и обмениваться данными с этими системами. SuccessFactors никогда не приходилось делать ничего подобного в начале 2000-х годов.

Наконец, новый виток развития ПО для HR должен также принимать во внимание идеи непрерывного развития, обучения и карьерного роста. У всех есть свои цели в области работы, но также есть цели в области карьеры, цели в области развития навыков и задачи развития, которые необходимо выполнить. Этот новый элемент управления эффективностью всегда отсутствовал в инструментах последнего поколения. Теперь у нас есть невероятные системы, такие как Degreed, EdCast, Fuel50 и другие. Я считаю, что инструменты эффективности и инструменты обучения и развития в конце концов будут объединены вместе.

Как все это работает вместе: непрерывное управление эффективностью сегодня

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

Однако позвольте заметить, что это очень инновационное пространство, где все еще происходит множество изменений.

Как покупателю систем управления эффективностью нового поколения, я думаю, вам нужно понять несколько простых вещей:

• Во-первых, ваш собственный процесс управления эффективностью должен основываться на вашей культуре управления и бизнес-цикле. Именно поэтому мы в Deloitte проводим так много времени с компаниями-клиентами вначале, чтобы разработать философию эффективности, прежде чем помочь им внедрить программное обеспечение. Так же, как Сатья Наделла изменила философию управления в Microsoft в течение последних нескольких лет, так и ваш СЕО и финансовый директор должны принимать участие в создании новых способов измерять и управлять эффективностью вашей компании.
• Во-вторых, нужно все упростить. На рынке множество инструментов. Найдите тот, который хорошо вам подходит, и не позволяйте со временем его загромождать разнообразными дополнительными функциями и делать слишком сложным в использовании.
• В-третьих, принимайте в расчет системы продуктивности, от которых вы зависите. Если вы используете Salesforce, убедитесь, что ваш инструмент управления эффективностью хорошо сочетается с ним.
• В-четвертых, не бойтесь со временем менять поставщиков. Это системы, которые можно заменить, и вы обнаружите, что отличная сегодня система уже не так полезна через три года. В Deloitte построили собственную систему, но меня не удивит, если мы заменим ее через 3 или 4 года. Хотя системы ERP и HCM обычно работают 7-10 лет или дольше, сейчас может быть не так — так что “не ждите, пока рынок созреет”.
• В-пятых, применяйте дизайн-мышление, когда вы выбираете и внедряете решение. Ни один продукт не будет идеальным, но способ, которым вы его внедряете, как ваши сотрудники используют его, и как он добавляет ценность, будут важны независимо от инструмента. Вы должны изучить практику работы в вашей компании и убедиться, что инструмент подходит для ваших способов управления. Не делайте ошибку, думая, что люди изменят способ, которым они управляют, только потому что вы купили новую модную систему.

Источник: Непрерывное управление эффективностью: новые правила — Talent Management

Технологии применения онтологий

Дмитрий Кудрявцев

Введение

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

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

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

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

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

Существует специальный европейский проект — KnowledgeWeb², интегрирующий работы в области управления знаниями и semantic web, который направлен на активизацию применения технологий на основе онтологий в деятельность предприятий и организаций. Данный проект объединяет как представителей из бизнеса, так и представителей научно-исследовательских организаций и институтов. В рамках данного проекта и его предшественника OntoWeb³; получен широкий спектр результатов (Deliverables)⁴, отражающих как технологические аспекты применения онтологий, так и аспекты, связанные с практическим применением данных технологий на предприятиях и в организациях, см. Табл. 1.

Табл. 1. Отчеты по применению онтологий

Проект	Результат (Deliverable)	Краткое описание	Дата
KnowledgeWeb	D 1.1.2 Prototypical Business Use Cases	В данном отчете представлены бизнес кейсы, отражающие возможные задачи бизнеса, которые могут быть решены с применением технологий на основе онтологий. Содержит примеры конкретных компаний и бизнес задач.	2005
OntoWeb	D1.2: Bussines Scenarios v2.0	Данный отчет описывает основные типы применений (бизнес-сценарии) технологий на основе онтологий, которые либо уже реализованы на практике, либо находятся на стадии внедрения. Обобщает возможные применения в группы.	2004
OntoWeb	D2.3 Successful Scenarios for Ontology-based Applications V1.0	Данный отчет представляет практические рекомендации по внедрению технологий на основе онтологий для решения задач бизнеса.	2003

Также обзор применения онтологий в области управления знаниями представлен в статьях:

1. Peter Mika and Hans Akkermans Towards a New Synthesis of Ontology Technology and Knowledge Management //Knowledge Engineering Review, April, 2004. www.cs.vu.nl/~pmika/research/papers/IR-BI-001.pdf

Описание:

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

2. Davies J, Studer R, Sure Y and Warren P W Next generation knowledge management //BT Technology Journal, Vol 23, No 3, July 2005. www.aifb.uni-karlsruhe.de/WBS/ysu/publications/2005_sekt_btjournal.pdf

Описание:

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

Семантический веб организации (Enterprise Semantic Web)

Семантический веб организации — это реализация глобальной концепции Semantic Web в рамках отдельной организации. Семантический веб (semantic web) — это концепция сети, в которой каждый ресурс на человеческом языке был бы снабжен описанием, понятным компьютеру. В идеальном варианте, вся информация в Интернете должна размещаться на двух языках: на человеческом языке для человека и на компьютерном языке для понимания компьютера.

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

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

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

Примеры интеллектуального поиска информации:

«Понятийные» запросы (Concept-based queries)
Описание	Возможность производить запросы на основе значений понятий, а не на основе совпадения строк.
Преимущества	Более быстрый поиск нужной информации.
Отличие	Традиционные поисковые сервисы основаны на алгоритмах совпадения строк и символов, такой подход не позволяет использовать синонимы или распознавать контекст запроса. В отличие от обычного поиска по ключевым словам, позволяет дополнять запрос (результаты) более общими или более детальными понятиями по отношению к искомому ключевому слову (животные / хищники / кошачьи / тигры).
Ключевые возможности использования	Поиск, навигация, порталы, объединенные запросы, интеграция данных, Business Intelligence.
Иллюстрация	Например, если пользователь задаст вопрос: «Какие транспортные средства производятся в России?», то он получит из базы ответ, в который попадут автомобили (=подкласс транспортных средств), производимые во Всеволожске (=город, который находится в России).
«Умные» запросы (Smart Queries)
Описание	Возможность получения не заданных явно знаний из созданных моделей (путем логического вывода).
Преимущества	Поиск «скрытой информации» в объединенных схемах.
Отличие	Традиционные поисковые сервисы могут связывать отдельные информационные источники, используя лексические совпадения. Реляционные БД используют связи, заданные вручную в схеме данных (связи между таблицами) или в коде процедур и функций. Для выполнения сложного запроса (см. иллюстрацию) над реляционной БД, необходимо заранее определить всю логику этого запроса.
Ключевые возможности использования	Поиск, объединенные запросы, интеграция данных, Business Intelligence, риск-менеджмент.
Иллюстрация	Например, пользователь системы может задать вопрос: Какие поставки продукции находятся сейчас в состоянии риска? В ответ на такой вопрос система в одной онтологии тарифов определит, что с учетом текущих условий (например, географических или погодных) существуют риски, связанные с перевозкой овощей и фруктов. А в другой базе или онтологии деклараций по перевозке груза определит, что в декларации №А345 указаны арбузы, которые являются подклассом «Овощей и фруктов» (см. рис. 2). В результате система сможет дать кокретный ответ на поставленный вопрос: Поставка COSCO #A345 Рис. 2. Интеллектуальный поиск на основе логического вывода

История и этапы развития сети: 70-е годы — возникновение глобальной компьютерной сети, узлы которой обменивались данными, не требовавшими обработки в реальном времени (письма, файлы и т.п.).
Март 1989 г. — Тимоти Бернерс-Ли (Европейская лаборатория физики элементарных частиц (CERN) в Женеве) – появление распределенной информационной сети, проект “World Wide Web: Proposal for Hyper Text Project”.
Май 2001 г. — появление основной статьи Тима Бернерс-Ли, Джеймса Хендлера и Оры Лассилы, которая вводит идею семантического веба — «The Semantic Web», опубликованной в журнале Scientific American [Berners-Lee, 2001]⁵.

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

• Расширяемый язык разметки eXtensible Markup Language, XML.
• Система описания ресурсов — Resource Description Framework, RDF.
• Язык сетевых онтологий — Web Ontology Language, OWL. Язык сетевых онтологий позволяет формально представлять онтологии, которые в свою очередь используются для описания информации в сети и ее поиске пользователями.

Рис. 3. Настоящее Semantic Web

Несмотря на очевидные преимущества и перспективы глобального внедрения идей и технологий Semantic Web, для реализация данной концепции в рамках всемирной сети потребуется время. В процессе исследований и разработок, проводимых крупными компаниями, был сформулирован локальный подход: семантический веб организации Enterprise Semantic Web (ESW) — реализация Semantic Web на ограниченной предметной области (в рамках отдельно взятой организации) [Cerebra, 2005].

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

ESW не может существовать без применения ключевых технологий, рекомендованных W3C. Resource Description Framework (RDF) представляет собой новый подход к организации данных в виде триплетов. Web Ontology Language (OWL) позволяет представлять онтологии, описывающие смысловую структуру данных, и создать модели связей. Эти две спецификации, используемые совместно, составляют фундамент семантического веба организации.

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

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

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

OWL представляет возможности построения семантической структуры для организации и классификации RDF триплетов. Онтологии OWL создаются сверху вниз, исходя из бизнес-логики. Одновременно RDF данные генерируются снизу вверх автоматизированными инструментами, см. рис. 4.

Рис. 4. Логическая архитектура семантического веба организации

OWL связывается с RDF посредством универсальных идентификаторов ресурсов (URIs). Фактически каждый индивидуальный элемент OWL может быть связан с элементом данных RDF (одним из узлов триплета объект-свойство-значение).

Корпоративная память на основе онтологий

Примером систем УЗ может служить Корпоративная память (КП), предназначенная для накопления и управления знаниями предприятия [Gomez-Perez,2002]. КП включает работу как с явным знанием компании в форме баз данных и электронных архивов, так и со скрытым знанием — либо фиксируя его в некотором (более или менее формальном) представлении в форме экспертных систем или БД, либо обеспечивая поиск и доступ к экспертам.

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

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

Характер потребностей в системах корпоративной памяти и объем усилий для их внедрения в компании может зависеть от размера компании. Среди мотивирующих факторов можно выделить следующие: 

1. Избежать потери уникальных знаний специалиста после его ухода на пенсию или смены места работы.
2. Сохранить опыт, полученный в предыдущих проектах, и избежать повторения ошибок.
3. Использовать карту знаний компании для разработки стратегии развития. Регулярное внедрение инноваций должно улучшать способность компании реагировать на изменение рыночной ситуации.
4. Улучшить процесс распространения информации и повысить уровень коммуникации внутри компании.
5. Улучшить процесс обучения персонала компании (как вновь принятых сотрудников, так и «старых»).
6. Интегрировать различные инновации компании.

Основные функции корпоративной памяти:

• Сбор и систематическая организация информации из различных источников в централизованное и структурное информационное хранилище.
• Интеграция с существующими автоматизированными системами [Conklin, 1996]. На техническом уровне это означает, что корпоративная память должна быть непосредственно связана с помощью интерфейса с инструментальными средствами, которые в настоящее время используются в организации (например, текстовые процессоры, электронные таблицы, системы документооборота).
• Обеспечение нужной информации по запросу (пассивная форма) и при необходимости (активная форма). Слишком частые ошибки  — это следствие недостаточной информированности. Этого невозможно избежать с помощью пассивной информационной системы, так как служащие часто слишком заняты, чтобы искать информацию, или не знают, что нужная информация существует.

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

Программный инструментарий для OMIS включает как оригинальные разработки, например KARAT [Tschaitschian , 1997] и Documentun i4 [Николаев, 1999], так и стандартные средства — например, LOTUS NOTES обеспечила один из первых инструментариев хранения документальной информации. Однако сегодня в связи с бурным развитием Интернета, СУЗ все чаще используют Web-технологию.

Для описания ресурсов знаний и их поиска в КП целесообразно использовать три вида онтологий [Abecker, 1998]:

• Онтологию информации для описания метасвойств и доступа к информации.
• Онтологию предприятия для описания контекста создания и применения информации.
• Предметную онтологию для описания контента (содержания) информации.

Общая схема реализации корпоративной памяти с применением данных онтологий представлена на рис. 5: 

Рис. 5. Реализация корпоративной памяти на основе онтологий

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

Метасвойства и доступ

Имя	“Как получить выгодные условия оплаты?”
Автор	Фома Берлиоз
Жанр	Совет
Тип	Эвристика, на основе опыта
Форма	Текст на русск. Языке, MS Word
Источник файла	E:\home\experiences\ds9-12-99pn.doc
Доступность	Всегда
Затраты	Нет

Контент

Продукт	20 SUN Ultra
Поставщик	Borg Inc.
Персона для контакта	Д-р Лютер Кинг

Контекст

Процесс- создатель	Проект Оптик для «Пятерочки», декабрь  ’99
Функция (activity)-создатель	Согласование цены с поставщиком комплектующих
Подразделение-создатель	Отдел закупок

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

1. Контекст потенциального применения знаний
2. Контекст, в котором знание было создано

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

Порталы на основе онтологий

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

В настоящее время найдено универсальное решение, обеспечивающее доступ к информации в рамках систем УЗ, — это корпоративные порталы, рис. 6.

Рис. 6. Концептуальная схема корпоративного портала

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

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

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

Ценность корпоративного портала (как и большинства систем УЗ) определяется его поисковыми возможностями, которые, как было показано выше, могут быть существенно улучшены за счет применения онтологии. Развитие идей применения онтологий для создания и поддержки порталов можно найти в работах [Staab, Maedhe, 2002], [Maedhe, 2002].

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

Рис. 7. Архитектура семантического портала на основе онтологии

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

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

http://www.aifb.uni-karlsruhe.de/english
http://knowledgeweb.semanticweb.org/semanticportal/index.jsp?content=joining.html

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

Рис. 8. Пример страницы семантического портала

Связанные объекты и типы связей между объектами на портале задаются с помощью соответствующей онтологии (рис. 9):

Рис. 9. Онтология портала проекта KnowledgeWeb

Применение онтологий для управления компетенциями

В данном разделе приведено применение онтологий в одной из функциональных областей предприятия — управления персоналом. Также онтологии могут применяться в других областях: финансы, маркетинг и т.п.

Компетенции — это взаимосвязанные знания, умения, навыки, способности и прочие характеристики личности сотрудников, необходимые для достижения требуемых результатов.

Компетенции:

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

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

Компетенции являются системообразующими элементами в системе управления кадровым потенциалом:

• Подбор персонала
• Обучение персонала
• Перемещение персонала
• Оценка персонала

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

В практике международного менеджмента уже существуют примеры управления компетенциями на основе онтологий:

1. Jussi Stader and Ann Macintosh, Capability Modelling and Knowledge Management / Моделированиеспособностейиуправлениезнаниями.

Аннотация

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

2. Ernst Biesalski, Andreas Abecker, IntegratedProcessesandToolsforPersonnelDevelopment / Интегрированные процессы и инструменты для развития персонала.

Аннотация

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

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

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

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

Ключевые слова

Управление знаниями и компетенциями; Управление компетенциями на основе онтологий; ИТ-архитектуры для управления знаниями и персоналом.

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

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

Такая интеграция позволит:

• определять необходимые организации компетенции
• идентифицировать / находить компетенции на основе контекста их применения (решаемые задачи, процессы, проекты…)

Преимущества управления компетенциями на основе онтологий:

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

Примечания

1. Фрагмент отчета по научно-исследовательской работе  «Эталонные модели организации деятельности в государственном секторе», выполненной сотрудниками АНО КМЦ «Бизнес-Инжиниринг» совместно с ИПГМУ ВШЭ, 2006 г.

2. http://knowledgeweb.semanticweb.org/semanticportal/home.jsp

3. Ontology-based information exchange for knowledge management and electronic commerce http://ontoweb.org/.

4. http://knowledgeweb.semanticweb.org/semanticportal/index.jsp?content=joining.html

http://ontoweb.org/About/Deliverables

5. Русский перевод по адресу http://ezolin.pisem.net/logic/semantic_web_rus.html.

6. Интересно отметить, что подобные идеи по установлению и визуализации связи между контекстом создания / применения и информацией в англоязычной литературе часто скрываются под видом «knowledge mapping» см., например, [Eppler, 2001] Martin J. Eppler Making Knowledge Visible Through Intranet Knowledge Maps: Concepts, Elements, Cases //Proceedings of the 34th Hawaii International Conference on System Sciences – 2001.
[Vestal, 2005] Wesley Vestal Knowledge Mapping: The Essentials for Success // APQC: Publications. 2005.
“One of the fundamental tenets of knowledge management is that knowledge must link to and improve business processes. Without a map of the processes, goals, and knowledge assets inside one’s organization, it will be difficult to reach one’s destination.” [Vestal, 2005].

Литература

1. Abecker A., Bernardi A., Hinkelmann K., Kuhn O., Sintek M. Toward a Technology for Organizational Memories IEEE Intelligent Systems. — 1998, №3, 40-48.
2. Abecker, A., D. Apostolou, W. Maas, G. Mentzas, C. Reuschling, S. Tabor Towards an Information Ontology for Knowledge Asset Trading Presented at the ICE 2003. — 9th International Conference of Concurrent Enterprising, Espoo, Finland, 16-18 June 2003
3. Berners-Lee T., Hendler J., and Lassila O., The Semantic Web, Scientific American, 2001, May
4. Biesalski E., Abecker A., Integrated Processes and Tools for Personnel Development, Proc. of 11th International Conference on Concurrent Enterprising, Munich, Germany, June 2005.
5. Borghoff U., Pareschi R., 1998. Information Technology for Knowledge Management. — Springer-Verlag, Bln.
6. Cerebra, Inc., Enterprise Semantic Web - Understanding the Evolution of Integration Technologies in the Context of the W3C Semantic Web Vision Whitepaper 2005.
7. Gomez-Perez A. Ontologies: Theory, methods and tools. Tutorial. The Fourth Summer School on Ontological Engineering and the Semantic Web, 2006 (SSSW'06).
8. Gomez-Perez, Asuncion (Editor), Richard Benjamins (Editor), 2002. Knowledge Engineering and Knowledge Management. Ontologies and the Semantic Web. Springer Verlag.
9. Hinkelmann K. and Kieninger Th. Task-oriented web-search refinement and information filtering. DFKI GmbH, 1997.
10. Kühn O., Abecker A., 1998. Corporate Memories for Knowledge Management in Industrial Practice: Prospects and Challenges.
11. Kühn 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
12. Ludger van Elst, Abecker A., and Heiko M. Exploiting User and Process Context for Knowledge Management Systems Workshop on User Modeling for Context-Aware Applications at the 8th Int. Conf. on User Modeling, July 13-16, 2001, Sonthofen, Germany
13. Macintosh A., Knowledge asset management. // Airing. – №20, April, 1997.
14. Maedche A., Staab S., Studer R., Sure Y., Volz R. SEAL— Tying Up Information Integration and Web Site Management by Ontologies //IEEE Data Engineering Bulletin 25 (1): 10-17. 2002.
15. McComb D. 2004. The CIO's Guide To Semantics© Semantic Arts, Inc. , www.semantic-conference.com
16. Nonaka I. and Takeuchi I., 1995. The Knowledge-Creating Company. New York, Oxford: Oxford University Press
17. Schreiber G., Akkermans H., Anjewierden A., R. de Hoog, Shadbolt N., W. van de Velde, Wielinga B. Knowledge Engineering and Management: The CommonKADS Methodology — The MIT Press, Cambridge, MA, 2000.
18. Staab S., Maedche A. Knowledge Portals: Ontologies at Work. AI Magazine 2001, Vol. 22, №2, p. 63-75.
19. Staab, S., Schnurr, H.-P., Studer, R., Sure, Y. Knowledge processes and ontologies, IEEE Intelligent Systems, 2001, Vol. 16 No.1, pp.26-34.
20. Stader J., Macintosh A., Capability modelling and knowledge management, Applications and Innovations in Intelligent Systems VII, Springer-Verlag, pp 33-50, 1999.
21. Strohmaier M. Designing Business Process Oriented Knowledge Infrastructures Proceedings der GI Workshopwoche, Workshop der Fachgruppe Wissensmanagement, Karlsruhe (2003)
22. Van Heist G., Schreiber T., Wielinga B. Using Explicit ontologies in KBS International Journal of Human-Computer studies Vol/ 46 (2/3) 1997
23. Wiig К. Knowledge management is no illusion! // Proc. of the First International Conference on Practical Aspects of Knowledge Management. — Zurich, Switzerland: Swiss Informaticians Society, 1996.
24. Гаврилова Т. Онтологический подход к управлению знаниями при разработке корпоративных информационных систем. // Ж. "Новости искусственного интеллекта", N2, 2003. — с. 24-30.
25. Николаев А., Построение систем управления знаниями на базе технологии Documentum 4i // Открытые системы , N9-10. — с.44-48, 1999.
26. О’Лири Д. Управление корпоративными знаниями / Открытые системы, N4-5. –c.31-39, 1998.
27. Отчет по НИР «Эталонные модели организации деятельности в государственном секторе», ГУ-ВШЭ, 2006.
28. Попов Э., Корпоративные системы управления знаниями. Ж.”Новости ИИ”, N1, 2001.
29. Результаты проекта Ontoweb (http://ontoweb.org/)
30. Результаты проекта Knowledgeweb (http://knowledgeweb.semanticweb.org/)
31. Публикации по управлению знаниями (http://www.bigс.ru/publications/bigspb/km/)
32. Публикации по управлению знаниями (http://www.kmtec.ru/publications/ontology/publications_anthology/)