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

Магамадов Руслан Сейдхасанович Соискатель ученой степени кандидата наук по специальности 09.06.01, кафедра Информационных технологий, Российский Университет Дружбы Народов 117198, Россия, г. Москва, ул. Миклухо-Маклая, 15, оф. корпус 1 Magamadov Ruslan Seidhasanovich Candidate of science degree in specialty 09.06.01, Department of Information Technologies, Russian University of Friendship of Peoples 117198, Russia, g. Moscow, ul. Miklukho-Maklaya, 15, of. korpus 1 rsmagamadov@mail.ru

Молодченков Алексей Игоревич кандидат технических наук старший преподаватель, кафедра информационных технологий, Российский университет дружбы народов; младший научный сотрудник, «Федеральный исследовательский центр «Информатика и управление» Российской академии наук 117312, Россия, г. Москва, пр-т 60-летия Октября, 9 Molodchenkov Aleksei Igorevich PhD in Technical Science Senior Lecturer, Department of Information Technologies, Peoples' Friendship University of Russia; junior researcher, "Federal Research Center" Informatics and Management"of the Russian Academy of Sciences 117312, Russia, g. Moscow, pr-t 60-letiya Oktyabrya, 9 aim@tesyan.ru

Введение

Социальная сеть — это множество узлов/индивидов/сущностей, между которыми есть определенные связи/отношения. ^[1] Понятие «социальные сети» рассматривалось в сфере всевозможных социологических парадигм и теоретических направлений — структурного функционализма, символического интеракционизма, теории социального обмена, теорий информационного общества и многих других ^[2]. Революция в информационных технологиях способствовала появлению и становлению современного информационного (и сетевого) общества, а использование компьютерных технологий оказало огромное влияние на всю структуру общества.

Анализ социальных сетей (SNA) — это способ изучения социальных сетей [3–6]. SNA появился и стал активно применяться во второй половине XX века как дополнительная опция к стандартному набору инструментов социологов и части раздела социологии, называемой социометрией. В основе данного анализа заложен принцип, что объяснения общественной организации нельзя найти в природных явлениях или процессах. Вместо этого мы должны обратить внимание на структуры и виды отношений, которые налаживают (или ограничивают) взаимодействия, и на поведение исполнителей (акторов, агентов), которые воспроизводят и видоизменяют эти структуры. Главной целью SNA является обнаружение и интерпретация общественных онлайн-связей, а также анализ и оптимизация технологического процесса. Они исследуются с помощью ряда аналитических техник, в пределах от простых показателей до изощрённого многоуровневого моделирования.

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

В социальной сети в рамках бизнеса используются данные, которые регистрируются в различных CRM и ERP-системах, в рамках которой чаще всего в наше время происходит ведение документооборота и ведение проектов и задач в рамках данных проектов. Все эти транзакции, документы и задачи, которые осуществляются в рамках электронных систем компании, фиксируются в специальных хранилищах, называемых лог файлами событий. ^[3][6]

Для анализа социальных сетей существует множество приложений для моделирования взаимодействий и процессов в сети, для вычисления определенных параметров сети и для визуализации графа сети. К наиболее известным средствам автоматического анализа социальных взаимодействий относятся: Microsoft BI, NetMiner, NetworkX, SNAP, ProM, UCINet, ORA, Cytoscape, AGNA, Egonet и др.

Самыми функциональными инструментами для работы с технологическими и бизнес-процессами и их анализа, построения на основе данных о работе коллективов являются Microsoft BI (Business Intelligence) и ProM. В рамках данной работы для анализа социальных сетей будет использоваться лишь инструментарий программы ProM, т.к. в отличие от Microsoft BI, ProM работает по принципу построения реальной модели бизнес-процесса на основе реальных данных работы коллектива. Главной же целью работы в Microsoft BI является построение оптимальной модели, такой, какой она должна быть в идеальных условиях.

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

1) Какова текущая эффективность коллектива (скорость выполнения задач, число выполняемых задач коллективом за единицу времени)?

2) Какова структура движения рабочих задач в рамках коллектива?

3) Есть ли слабые, неэффективные места в рамках коллектива и рабочего процесса, где происходит замедление работы коллектива и падает производительность?

4) Как можно улучшить работу слабых мест процесса (перераспределение ресурсов, увеличение штата и т.д.)?

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

Анализ социальных сетей

Основным вопросом анализа социальных сетей является получение значимых и полезных социограмм из лог файлов событий.

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

Далее хотелось бы подробнее разобрать лог файл событий. Мы полагаем, что лог файл определен следующими элементами ^[3][6]:

· Действие (activity) — четко определенный шаг процесса;

· Задача (case) — экземпляр процесса;

· Исполнитель (performer) — человек, инициирующий или выполняющий действие;

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

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

Далее необходимо определить и получить основные показатели сети – метрики (характеристики).

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

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

Однако все метрики можно разделить на несколько видов, в зависимости от того, на что делать упор в анализе, а чем можно частично пренебречь или отбросить вовсе. Существует 4 вида метрик ^[3]:

1) Метрики, основанные на (возможной) каузальности (причинно-следственной связи);

2) Метрики, основанные на совместных задачах;

3) Метрики, основанные на совместных действиях;

4) Метрики, основанные на особых типах событий.

Прежде чем мы подробно определим различные метрики, введем удобное обозначение для журналов событий.

Определение 1 (Лог файл событий). Пусть A означает набор действий (атомарные объекты рабочего потока/процесса, также называемые задачами) а P означает множество исполнителей (ресурсы, люди или рабочие). Тогда E=A×Pявляется множеством (возможных) событий, т.е. комбинации различных действий и исполнителей (например пара (a,p) обозначает выполнение действия a исполнителем p).C=E* — множество возможных последовательностей событий (данные, описывающие задачу). β(C) — множество всех мультимножеств над C. Тогда лог файлом (журналом) событий является множество L Є β(C). ^[3]

Обращу внимание на то, что это определение события несколько отличается от неофициальных понятий, используемых ранее. Прежде всего, в данной работе мы абстрагируемся от дополнительной информации, такой как отметки времени, данные и т.д. Во-вторых, не рассматривается упорядочение событий, соответствующих различным случаям. Для удобства, определим две операции над событиями: πa(e)=a и πp(e)=p и для некоторого события e=(a,p).

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

Основная идея состоит в том, что исполнители связаны между собой, если есть причинно-следственная связь при переходе рабочей задачи от одного исполнителя к другому. В обеих ситуациях применяются три вида уточнений. Прежде всего, можно дифференцировать по степени причинности, например, по длительности передачи обслуживания. Это означает, что мы можем рассматривать не только прямую, но и косвенную преемственность. Во-вторых, мы можем игнорировать множественные передачи в одном экземпляре или нет. В-третьих, мы можем рассматривать произвольные передачи работ или рассматривать только те, в которых существует второстепенная зависимость (для последних нам нужно знать или иметь возможность получить модель процесса). На основе этих уточнений мы получаем 23=8 вариантов как для передачи работы, так и для метрик субподряда. Все эти варианты основаны на одном лог файле событий. Перед определением метрик обозначим некоторые основные понятия, которые могут быть применены к одной задаче c=(c0, c1,…).

Определение 2 (⊳, ⊵). Пусть L обозначает лог. Предположим, что → обозначает некоторое причинно-следственное (каузальное) отношение, полученное из модели процесса. ^[3]

Для a1, a2Є A, p1, p2 Є P, c=(c0, c1,…) Є Lи n ЄIN:

§

§

§

§

обозначает функцию, которая возвращает истину, если в контексте задачи c исполнители и выполняли некоторую деятельность, так что расстояние (число узлов) между этими двумя действиями равно n. В этом определении, если значение n равно 1, то мы получаем прямую последовательность (преемственность). Если n больше 1, это относится к косвенной преемственности. Однако данная функция игнорирует как множественные переводы в рамках одного экземпляра, так и прямые зависимости. обозначает функцию, которая возвращает число повторений метрики в рамках задачиc. Другими словами, данная функция рассматривает множественные передачи в одном экземпляре. Функции и аналогичны двум вышеназванным, однако, кроме того, они учитывают, существует ли реальная прямая зависимость, т.е. если действия выполняются именно друг за другом. В случае если действия идут параллельно, функция вернет 0. Информация о причинной связи может быть добавлена, если известна модель процесса.

Используя такие отношения, определим передачу рабочих метрик. На основе трех видов уточнений, упомянутых ранее, были получены следующие 8 вариантов.

Определение 3 (Передача рабочих метрик). Пусть L обозначает лог. Для и некоторого получим:

§ /

§ /

§ /

§ /

§ /

§ /

§ /

§ /

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

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

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

Определение 4 (Общие формы передачи рабочих метрик). Пусть L обозначает лог файл. Для , некоторого и получим:

§ /

§ /

§ /

§ /

В этих альтернативных формулировках вводится «коэффициент глубины расчета»k. Когда мы вычисляем метрики, k указывает максимальную степень каузальности. Например, если коэффициент k равен 3, рассматривается задача прямой последовательности, одно событие между двумя исполнителями и два события между двумя исполнителями. Заметим, что если k=1 иβ=1, то или если , тогда . Далее, когда мы вычисляем метрики, подходящее значение k важно для эффективности вычисления. Лог файлы событий обычно очень большие. Поэтому рассмотрение всех возможных последовательностей может быть неэффективным.

После определения метрик для передачи работы мы рассмотрим другой класс показателей, основанный на (возможной) каузальности: метрики субподряда. В случае субподряда также могут применяться три упомянутых выше уточнения. Тем не менее, есть только одно действие между двумя действиями, выполненными одним исполнителем. Хотя подразумевается косвенная преемственность работы, между двумя действиями, выполняемыми одним исполнителем, существует несколько действий. Мы также вводим коэффициент снижения причинности β для косвенной преемственности. Например, предположим, что есть четыре действия. И первое, и четвертое действие исполняются исполнителем i, в то время как второе и третье действие исполняются исполнителем j и k соответственно. В этой ситуации мы можем получить два отношения: от исполнителя i к исполнителю j, и от исполнителя i до исполнителяk. Опять же, мы используем коэффициент снижения причинности β. Второе и третье уточнения такие же, как и для передачи работы. Перед определением метрик, опишем основные понятия, применяемые к одной из задач c=(c0, c1,…).

Определение 5 (,). Пусть L обозначает лог файл. Предположим, что обозначает некоторое причинно-следственное (каузальное) отношение, полученное из модели процесса. Для , и :

§

§

§

§

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

Используя такие отношения, мы определяем метрики субподряда. Вновь определены восемь вариантов таких метрик.

Определение 6 (Промежуточные метрики). ПустьL обозначает лог файл. Для и некоторого получим:

§ /

§ /

§ /

§ /

§ /

§ /

§ /

§ /

Метрика выражает отношение общего количества прямых случаев субподряда между и в журнале процесса к максимальному количеству возможных прямых случаев субподряда в журнале. В метрике игнорируются множественные передачи в рамках одного экземпляра. Метрики и используются в ситуациях, когда расстояние между этими двумя действиями, выполненное исполнителем , больше 2.Введем еще раз коэффициент снижения причинности β аналогично передаче рабочих показателей. Если в контексте случая имеется событий между двумя действиями, выполненными одним и тем же исполнителем, то коэффициент снижения причинности будет равенβn. Метрика рассматривает все возможные случаи субподряда, в то время как отбрасываются множественные передачи в рамках одного экземпляра. Следующие 4 метрики, основанные на операторе, аналогичны по описанию, однако они учитывают реальные прямые зависимости.

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

Определение 7 (Общие формы промежуточных метрик). Пусть L обозначает лог файл. Для , некоторого и получим:

§ /

§ /

§ /

§ /

Вновь введем «коэффициент глубины расчета» k. При вычислении метрик k определяет максимальное расстояние между двумя действиями, выполненными одним исполнителем. Например, если k равно 3, рассматривается случай одного действия между двумя действиями, выполненными одним исполнителем, и двумя действиями между двумя действиями, выполненными одним исполнителем. Отмечу, что если β=1, k=2, то , а если , тогда .

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

Определение 8 (Метрики совместной работы). ПустьL обозначает лог файл. Для если , иначе , где для если , или если , иначе .

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

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

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

Определение 9 (). Пусть L обозначает лог файл.Для и :

§

§

Замечу, что метрика △ определяет матрицу с рядами P и столбцами A.

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

Определение 10 (, , ). Пусть L обозначает лог файл, а △L обозначает исполнителя по матрице активности. Для :

§

§ , где

§ , где ,

Расстояние Минковского имеет параметр n:n=1 — это прямолинейное расстояние, которое также называется расстоянием Манхеттена, n=2 — евклидово расстояние, а при больших значениях n метрика приближается к чебышевскому расстоянию. Расстояние Хэмминга не имеет параметра, но может быть расширено некоторым пороговым значением. В случае коэффициента корреляции Пирсона результат варьируется от +1 до -1. Корреляция +1 означает, что между переменными существует совершенная положительная линейная связь. Корреляция -1 означает, что между переменными существует максимальная отрицательная линейная связь. Другими словами, если расстояние между исполнителями невелико, корреляция ближе к 1, если оно большое, корреляция ближе к -1. ^[3][4]

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

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

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

Исходные данные

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

В качестве примеров, на которых будут получены и рассмотрены данные метрики, были взяты рабочие лог файлы 3 бизнес-процессов из разных сфер, находящиеся в открытом доступе в сети Интернет: ^[7]

1) работа компании, осуществляющей обработку отзывов для журнала;

2) работа страховой компании;

3) работа компании по ремонту технических неисправностей.

В рамках лог файла компании, занимающейся отзывами для журнала, действует довольно простой технологический процесс. Каждый отзыв, поступающий в компанию, рассылается 3 разным рецензентам. Рецензентам предлагается написать отчет по отзыву. Однако рецензенты часто не отвечают. В результате, не всегда можно принять решение после первого раунда обзора и приходится через некоторое время заново отправлять документ рецензентам. Если отчетов недостаточно, приглашаются дополнительные рецензенты. Этот процесс повторяется до тех пор, пока не будет принято окончательное решение (принять или отклонить отзыв для публикации в журнале). Лог файл содержит данные о 100 задачах (документах, с которыми работают рецензенты) и 3730 событиях, в которых участвует 10 людей — рецензенты.

Во втором бизнес-процессе описывается обработка заявок в страховой компании. В лог файле содержатся данные о 46138 событиях, связанных с 3512 задачами (факты страховых запросов). Этот процесс связан с обработкой входящих телефонных звонков, в соответствии с которыми различные типы страховых запросов (домашнее хозяйство, автомобиль и т.д.) подаются по телефону. Процесс поддерживается двумя отдельными колл-центрами, работающими для двух разных организационных структур (Брисбен и Сидней). Оба центра аналогичны по объему входящего трафика и среднему общему времени обработки вызовов, но различаются в развертке агентов колл-центра, базовых IT-систем и т.д. После первичной обработки запросов в колл-центре оставшаяся работа по решению запроса ведется внутри самой страховой компании.

В основе третьего типа процесса лежит система фиксации и ремонта различных поломок в некоторой системе. Существует центральный узел системы, который отвечает за фиксацию факта поломки, информирование пользователя, у которого случилась поломка, отправку поломки на диагностику тестировщикам и ремонтникам, а также архивирование решенной проблемы в базы данных системы. Тестировщики, получив первичную информацию о поломке, диагностируют её и определяют точную поломку, после чего передают её специалистам по починке. Специалисты производят починку и передают данные об этом в систему и тестировщикам, которые проводят финальные тесты восстановленной функциональности и если все корректно, дают об этом сигнал в систему и через нее пользователю. В данном процессе всего задействовано 13 участников (6 тестировщиков, 6 специалистов по починке и 1 узел системы). Данный пример содержит 1104 задачи (поломки) и 11855 событий.

Построение модели социальной сети по метрикам, основанным на каузальности

Опираясь на описанные метрики, далее построим модели социальной сети по трём рассмотренным примерам с помощью программного обеспечения ProM и опишем их.

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

· Компания, занимающаяся обработкой отзывов для журнала.

Как видно из полученной социограммы на рис. 1, рецензенты работают тремя группами, участники которых теснее и чаще всего взаимодействуют между собой в процессе передачи работы. Обратим внимание, что центральная группа сотрудников чаще всего не успевает выполнять работу или выполняет её некорректно и потому плотно связаны с узлом _INVALID_, где регистрируются ошибки сотрудников. Размер узлов говорит о степени влияния и плотности взаимодействия сотрудника с остальной компанией. Как видно, наиболее вовлеченными и активными сотрудниками являются Anne, John, Pete и Mike, обладающие наибольшими показателями посредничества и центральности. Меньше всех в передаче работ участвуют Wil и Carol. Исходя из формы узлов, можно заключить, что Wil больше всех получает задания от других и выполняет их и абсолютно не передает куда-то еще работы, являясь, по сути, основным исполнителем и конечным узлом, принимающим финальное решение по завершению работы. Carol же в большинстве случаев отдает указания и работу другим, нежели принимает, к тому же, она взаимодействует далеко не со всеми сотрудниками в двухстороннем порядке. Они же обладают, наивысшими показателями характеристики близости (closeness), отражающей высокую скорость распространения задач по сети, ведь именно им стараются как можно скорее перенаправить на финальное согласование рецензии и отзывы, и они быстро принимают решение.

· Страховая компания.

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

· Компания по ремонту технических неисправностей.

В данном примере явно выделяется группа участников сети, плотно взаимодействующих между собой и видно, что 4 из 6 специалистов по ремонту (SolverC1, SolverC2, SolverC3 и SolverS2) работают обособленно, взаимодействуя с системным узлом (System) и тестировщиками не так интенсивно, как сами тестировщики (Tester 1…6) взаимодействуют с системным узлом, что видно по удаленности узлов относительно узла системы. Узлы 2 специалистов по ремонту SolverS1 и SolverS3 находятся ближе остальных к узлу системы и тестировщиков, т.к. они чаще всего, исходя из лог файла, получают задачи на поломку от системы и чаще вынуждены отдавать/получать задачи тестировщиков. По размерам узла System можно сделать вывод, что он наиболее влиятельный участник социальной сети, вовлеченный максимально в весь процесс и чаще всего взаимодействующий абсолютно со всеми остальными участниками процесса. Это абсолютно логично, т.к. данный узел является посредником между тестировщиками и специалистами по ремонту. Связано это с тем, что до и после каждого действия, тестировщики/специалисты передают не только саму задачу на решение (если это передача от тестировщика к специалисту) или диагностику (передача от специалиста тестировщику), но и информацию о ней, которая транслируется как раз в системный узел и записывается там в базе данных. Соответственно, узел System имеет высокую сплоченность и скорость передачи задач и данных с остальными узлами, а также является самым ключевым узлом сети, т.к. в данном узле фиксируется первоначальный факт поломки и финальный факт починки, без которых вся работа процесса была бы невозможна. Пример виден на рис. 3.

Построение модели социальной сети по метрикам, основанным на совместных действиях

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

1) Расстояние Минковского (частный случай, который мы рассматриваем в рамках данной работы — Евклидово расстояние);

2) Расстояние Хэмминга;

3) Коэффициент корреляции Пирсона.

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

В рамках данной работы, в качестве примера мы рассмотрим лишь 1 тип расстояния, частный случай расстояния Минковского — расстояние Евклида.

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

· Компания, занимающаяся обработкой отзывов для журнала.

В построенной модели (рис. 4) можно обратить внимание на то, что наиболее быстрыми работниками с высокими показателями близости являются сотрудники Wil, Mike и Anne, а также узел, отвечающий за ошибки (__INVALID__), что говорит о частых сбоях в работе сотрудников (не подключился дополнительный сотрудник к рецензии, не было принято решение, сотрудник не уложился в сроки). Наиболее медленными в плане передачи задач сотрудниками являются узлы Mary, Sara и John, Sam и Pam.

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

· Страховая компания.

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

· Компания по ремонту технических неисправностей.

В данном примере также была построена модель (рис. 6). Исходя из нее, можно сделать вывод, что узел системы System является самым вовлеченным в процесс и наиболее быстрым в обмене данными с остальной частью системы. Также видно, что все специалисты ремонта (узлы Solver) также довольно быстро выполняют свою работу и передают её в систему для подтверждения. Тестировщики (узлы Tester) являются более медленными, что говорит нам о том, что диагностический этап является довольно крупным и небыстрым в реализации. Также отчетливо видно, что узел Tester4 является самым медлительным звеном системы, несмотря на то, что он часто и тесно взаимодействует с остальными узлами системы (исходя из значений расстояния Евклида на ребрах социограммы).

Построение модели социальной сети по метрикам, основанным на совместных задачах

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

· Компания, занимающаяся обработкой отзывов для журнала.

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

Также высокую вовлеченность во все задачи и плотность взаимодействия с остальными имеют Mike и Ann, это также видно из значений веса ребер, в большинстве своем равные 1. Это подтверждает вывод о том, что они являются одними из самых влиятельных и активных участников рабочего процесса. Полученную модель можно видеть ниже (рис. 7).

· Страховая компания.

В полученной модели (рис. 8) можно видеть, что узлы колл-центров не имеют между собой связи, т.к. работают над разными задачами и не имеют совместных. Как было сказано ранее, самыми быстрыми по работе с задачами являются узлы колл-центров Сиднея и Брисбена. Самым медленным является узел клиентов. Характерно, что значение веса ребер, идущие от узлов колл-центров и самой компании к клиентам, равны 1, это логично, т.к. колл-центры и компания на 100% работают над работой, которую подали клиенты — их заявкой.

Сравнивая вес ребер и , как и и можно как и ранее сделать вывод, что колл-центр в Брисбене работает немного быстрее и теснее с компанией (Claims handler), активнее отправляет в компанию задачи.

· Компания по ремонту технических неисправностей.

Из построенной модели (рис. 9) отчетливо можно сделать вывод, что узлы SolverS3 и SolverC3 (узел в центре наверху социограммы) не имеют связей между собой, а значит, не имеют ни одной совместной задачи, над которой они работали бы. Узлы SolverC3 и SolverC1 (левый нижний) обладают самыми низкими показателями близости, не слишком вовлекаясь в процесс.

Общие выводы по построенным моделям

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

· Компания, занимающаяся обработкой отзывов для журнала.

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

Решение: нанять еще 1-2 людей на ту же должность для увеличения пропускной способности данной части сети.

2) Сотрудники Mary, Sara и John, Sam и Pam активно взаимодействуют между собой, однако делают это с невысокой скоростью.

3) Сотрудники Mike и Wil являются ключевыми в принятии финальных решений и закрытия задач, при этом являются сильным звеном, т.к. обладают высокими показателями близости в сети, высокой скоростью обработки задач и принимают участие практически во всех задачах.

4) Сотрудница Anne является также активный участником всего процесса, вовлеченная в большинство задач и взаимодействующая со всеми узлами, однако обладающая меньшей скоростью выполнения задач, нежели Mike и Wil. Чаще и плотнее всего взаимодействует с сотрудником Mike.

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

Решение: пересмотреть процесс подключения дополнительных сотрудников и в целом процесс принятия решения, т.к. он не оптимален.

· Страховая компания.

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

2) Клиенты (узел Customer) являются очень медленными и передают свои заявки в колл-центры в некрупных объемах. Есть вероятность, что не налажен процесс подачи заявок или же привлекается малое количество клиентов, что свидетельствует о не лучшем положении компании на конкурентом рынке.

3) Узел самой страховой компании (Claims holder) обрабатывает задачи с высокой скоростью, однако долго получает задачи в работу от колл-центров, о чем свидетельствует равное расстояние от колл-центров к компании и от клиентов напрямую к компании. Решение: расширить штат колл-центров и пересмотреть требования по отклику и передачи заявки в компанию.

4) Колл-центр в Брисбене работает немного быстрее и эффективнее, чем колл-центр в Сиднее.

· Компания по ремонту технических неисправностей.

1) Ключевым и наиболее вовлеченным в рабочий процесс и взаимодействие со всеми участниками системы узлом является узел System. Он обладает наибольшей степень близости, наивысшей скоростью передачи задач.

2) Узлы SolverC1 и SolverC3 недостаточно вовлечены в процесс обмена задачами.

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

3) Узлы SolverS3 и SolverC3 не пересекаются в работе, не имея общих задач, над которыми бы они работали.

Заключение

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