Управление предприятием на базе ARIS EMS

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

- Как обеспечить гибкость компании и своевременное соответствие возникающим рыночным требованиям? 

- Как повысить клиентскую лояльность и предугадывать потребности заказчика? 

- Как повысить качество выпускаемого продукта/cервиса?  

- Как обеспечить максимальную прозрачность процессов и обеспечить контроль результатов? 

Это далеко не все вопросы, с которыми сталкиваются руководители современного бизнеса. В данном материале речь пойдет о возможностях ARIS EMS (Enterprise Management System). Система управления предприятием на базе ARIS поможет в управлении фундаментальными инициативами по преобразованию и обеспечит качественное достижение измеримых результатов: от определения стратегии и переосмысления подходов к работе до поддержки исполнения и мониторинга результатов.

Это мероприятие началось с экскурса в историю: Enterprise Management System – это условно новое решение, которое базируется на уже существовавших компонентах платформы ARIS, которая достаточно стремительно развивается. В 90-х годах вендор предлагал инструмент по документированию процессов, по генерации процессной документации, в 2000-х годах процессный менеджмент перешел к лозунгу «Процессный реинжиниринг», сегодня же то что вендор предлагает на рынок, называется общим термином Enterprise Management System. Фактически это три крупных функциональных блока: трансформация (контроль внедрения), оптимизация (непрерывная оптимизация и контроль операций) и контроль (активный контроль соответствия регламентам).

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

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

Используем демосценарий

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

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

Теперь надо залогиниться на вебпортале ARIS Enterprise Management System как условный менеджер. На стартовой странице мы видим Management View, некоторые отчетные дашборды и это все, что менеджеру доступно.

В зависимости от типа пользователя, получившего доступ к порталу ARIS Connect, принципиальным образом изменяется внешний вид и доступный функционал портала. Менеджеру дают возможность оценить текущее состояние системы в рамках зоны ответственности, которая на него возложена. Мы имеет дело с демопримером, построенным вокруг процесса продажи, end to end, от заказа к получению оплаты (Order to cash) клиента. Этот же процесс продажи, если мы смотрим со стороны конечного потребителя (то что называется Customer Experiments Management) и так называемый Customer Journey или по-русски «клиентские пути». Попытаемся посмотреть на нашу организацию со стороны конечного клиента и с использованием каких инструментов клиент взаимодействует с нами, получая услугу или приобретая некий товар от нас. Это один и тот же процесс, изнутри это сквозной процесс от заказа к оплате, а со стороны клиента - это некоторый путь, который клиент проходит, взаимодействуя с нами и приобретая наш товар, в данном случае это некий автомобиль.

Что выведено на основную аналитическую панель для условного менеджера: в качестве ключевой метрики (в левой части слайда) используется так называемая Customer Satisfaction, это KPI, который оценивает конечную удовлетворенность клиента тем как мы его обслуживаем в ходе продажи ему товара, в ходе общения с ним на пути приобретения товара.

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

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

Клиентский путь

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

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

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

Поиск корневых причин

Если я не выбираю никакую из категорий, то у меня процесс продаж был выполнен 13 925 раз (на слайде справа).

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

Я ставлю задачу понять, что это характеризует. Я запускаю стандартный функционал, который называется Root Cause Miner или «Поиск корневых причин». 

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

В списке представлено наиболее весомые характеристики анализируемого процесса, которые с точки зрения автоматизированного поиска корневых причин искусственного интеллекта послужили причинами того, что клиент оказывается недовольным. В 85% случаев этим стала причина «Заказ был изменен». Менеджер принимает решение исследовать все случаи, когда изменялись заказы. Я ставлю фильтр и определяю что таких процессов было 1 171. Здесь можно отмаштабировать цепочку шагов процесса, сделав их более наглядными, что даст возможность лучше оценить что происходило в той или иной продаже. 

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

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

Как исполнить указание менеджера

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

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

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

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

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

Я, как методист, поправив то, что называется Customer Facing, ту часть, которая называется front-end-клиентской модели, описывающей клиентский Experience, я также должен внести изменения и во внутренний процесс, который описывает то, как выполняются внутренние процедуры. Т.е. я должен эти изменения отразить и во внутренних процедурах в том числе. 

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

на этом этапе вставляется еще один шаг, который называется Handel off Customer Charges. Этим я демонстрирую функционал по смарт-моделированию, который появился в предыдущем релизе. Фактически решаю задачу, как вставить шаг между двумя уже существующими шагами данного операционного сценария. Тем самым я должен разорвать эту связь, добавить еще один шаг, и восстановить эту связь сначала введя связь от предыдущего шага к следующему. Благодаря механизму смарт-моделирования, нет необходимости выполнять множество операций. Буквально одним нажатием мышки я вставляю один промежуточный шаг, который система самостоятельно встраивает в уже существующую последовательность, это тот же самый шаг Handel off Customer Charges, который указан на модели клиентского пути. 

Фиксируем изменения

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

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

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

Что мы для этого делаем? Во-первых, на текущем этапе мы воспользуемся услугами сотрудника центра компетенции, той дамы, которую зовут Тина, и которая внесла исходные изменения в процесс.

Какая задача у Тины? Если раньше адресатом комментария, который формировал Марк, обращаясь к сотрудникам процессного офиса, был только процессный офис, то здесь мы должны для всех клиентов нашего корпоративного портала сказать: "Коллеги, процедура обработки продаж обновлена, просим ознакомиться." 

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

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

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

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

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

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

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

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

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

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

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