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

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

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

Цели моделирования, внутренние и внешние критерии

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

От вашей цели моделирования сильно зависят требования и критерии выбора. Если вы открываете кофейню, вам не подойдет капсульная кофемашина – слишком дорого и неудобно. А если вы пьёте одну чашку кофе в неделю, то капсульная машина – самый выгодный способ получить классный кофе. 

Нам известны такие цели моделирования:

• В моменте создавать технические задания на автоматизацию: вам нужен быстрый способ создать процесс, отметить, где и что надо доработать, и обсудить с коллегами. Потом описания умирают, а значит не должно быть такого, что трудоёмкость описания модели равняется неделям или месяцам.
• Обеспечить инструкциями всю компанию: вам нужен простой и понятный поиск инструкций для сотрудников, привязанный к их должностям и задачам. А ещё лёгкий доступ к этим инструкциями – через браузер. И интеграция, которая обновляет оргструктуру автоматически.
• Договариваться внутри о том, как стоит работать: вам нужен инструмент, который позволит чётко и подробно обсуждать модели, также потребуется доступ через браузер, чтобы десяткам вовлечённых людей не потребовалось ничего ставить. А ещё возможность согласовывать процессы, чтобы точно знать мнение участвующих коллег.
• Находить узкие места и устранять их: вам потребуется способ вносить метрики процессов (возможно, автоматически) и выполнять имитационное моделирование процессов, чтобы инструмент сам подсказывал, где могут быть проблемы.

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

Каждая из целей рождает разные требования и критерии к выбору инструмента. Ещё на критерии влияет количество сотрудников, возможности вашей организации в ИТ, бюджет, требуемый уровень надёжности и так далее.

Обратите внимание на такие внутренние критерии:

• Количество сотрудников, вовлечённых в моделирование: при небольшом количестве аналитиков можно не заботиться о контроле качествах их работы (можно руками проверять), разграничивать права доступа тоже не очень важно.
• Количество сотрудников, вовлеченных в согласование и обсуждение: чем больше сотрудников, которые время от времени заходят в процессы, тем важнее становится скорость готовности инструмента работе – когда не надо ставить софт. Также важно удобство и простота, потому что в сложных инструментах редкие бизнес-юзеры разберутся. А если вы предпочитаете согласовывать и обсуждать по старинке, то вам потребуется экспорт в картинки и регламенты, чтобы отправлять их по почте.
• Количество сотрудников, которым в принципе может потребоваться доступ к описанию: этот параметр так же влияет на скорость готовности инструмента к работе, удобству, наличию понятного поиска. А ещё он может влиять на бюджет, потому что некоторые вендоры просят денег даже за тех пользователей, которые просто смотрят.
• Требования ИТ в части технологического стека, процессов обновления и обеспечения надежности: если у вас современная компания с крутыми ИТ-специалистами, то наверняка у вас выстроены процессы поддержки, обновления, мониторинга, обеспечения надежности. В крутых ИТ-компаниях победил opensource и инженерная культура devops. Если вендор работает на старых технологиях или не способен поддержать требования ваших ИТ-специалистов, то полная стоимость владения может сильно вырасти из-за необходимости иметь отдельных людей и процессы для управления надёжностью и обновлениями.

• Требования безопасности в части хранения информации, обеспечения логирования и разграничения полномочий: серьёзные требования ИБ могут повлечь за собой необходимость установки решения на свои сервера (а не использования облаков), использование централизованных сервисов аутентификации (например, по протоколу Oauth2) и обеспечение строгого логирования без доступа к нему ИТ-специалистов.

• Текущие компетенции компании по моделированию процессов: уровень понимания того, что и как вы будете описывать, влияет на выбор необходимых функций и нотаций. Если вы только начинаете, то вы хотели бы всего, побольше и пофункциональнее. А если вы давно описываете процессы и используете их в работе, то вам гораздо проще чётко определить свои требования, а их адекватность будет выше.
• Наличие существующих моделей и необходимость их переноса: будет жалко выкинуть работу компании за несколько лет, если наработки не получится перенести. Этот критерий лучше подходит к смене системы, а не выбору новой. Думаю, если вы решили менять систему, то понимаете, что перенос маловероятен. Скорее всего получится перенести только стандартизированные форматы в виде .BPMN или написать интеграцию, тогда потребуется API.
• Существующие системы, в которых есть нужная для моделирования информация и возможности по их интеграции: если у вас один эксельник со списком должностей, то интеграции вам не нужны. А если у вас 45 систем с зарплатами, структурой, архитектурными репозиториями, то автоматизированная интеграция может стать очень важным критерием или даже камнем преткновения.
• Ваша корпоративная культура: если в вашей компании принято согласовывать договора по полгода, а за ошибки выгоняют, то у вас не будет возможности попробовать всех вендоров и придется потратить кучу сил на формирование табличек, референс визитов и прочих демонстраций от производителей. 

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

Советуем обратить внимание:

• Вариант развёртывания: если вендор предлагает облачное (SAAS) использование, то это обычно сильно снижает совокупную стоимость владения, потому что не надо тратиться на своих администраторов, поддержку и сервера.
• Количество пользователей и внедрений: чем больше внедрений и пользователей, тем больше людей за вас потратили деньги и время, чтобы помочь вендору создать хороший продукт. 
• Уровни техподдержки и гарантии SLA: узнайте, какой SLA и каналы поддержки обеспечивает вендор. Будет грустно, если неделю ваша система будет лежать из-за бага.
• Стоимость поддержки: без поддержки работать нельзя, есть риск остаться со смертельными багами, а также нужно посчитать совокупную стоимость владения.
• Качество документации: сильно влияет на время "вкатывания" сотрудников в инструмент моделирования процессов. Оценить количественно сложно.
• Количество обновлений в год: чем больше релизов, тем больше функционала и тем больше багов (и тем меньше багов на самом деле, потому что релизы обычно их устраняют). Обидно натыкаться на один и тот же баг каждый день в течение года, пока вендор сделает новое обновление.
• Наличие публичного роудмапа: обычно инструмент моделирования – это надолго, так что было бы классно знать (и получить) нужные функции в рамках очередного обновления, не платя лишних денег.

• Возможность доработок за деньги: бывает такое, что инструмент вам почти подошёл, но не хватает вот какой-то маленькой пуговицы – тогда выручает возможность дать производителю денег, чтобы он лично для вас выпустил новое обновление в оговорённые сроки.
• Популярность на рынке: чем больше пользователей инструмента, там проще вам нанять готовых людей (а не учить студентов с нуля за деньги).
• Что говорят клиенты: критерий сложно взвесить, но в целом полезно сходить в гости к пользователям, похожим на вашу компанию, и спросить – ну как инструмент?
• Наличие обучения: инструмент моделирования процессов – сложная штука, которой нужно учиться. Здорово, если есть готовые программы обучения. Просто отлично, если они бесплатные – это снижает совокупную стоимость владения.
• Сообщество пользователей: возможность спросить совета у таких же пользователей, как и вы, сильно экономит время аналитиков и согласующих. Особенно если сообщество пользователей на русском языке.

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

Критерии оценки инструментов моделирования

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

Между функциональными и нефункциональными критериями можно поставить разный вес в зависимости от вашей ситуации: какой толк выбирать инструмент с 45 нотациями описания бизнес-процессов, если у вас 2 аналитика-студента, а опыт организации в описании процессов сводится к таблицам в EXCEL.

Функциональные критерии инструмента моделирования

Таблица, где мы собрали все критерии формулами в самом низу. Вам останется только заполнить опросник, подобрать подходящих вендоров и поставить собственные веса. За наш продукт stormbpmn мы уже всё заполнили.

Работа в браузере

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

У этого требования высокий вес, если предполагается большое количество вовлечённых сотрудников.

Это требование является критическим (т.е. отсекающим инструмент), если перед вами стоит задача вовлечения всей компании и обеспечения доступа к информации.

Поддерживаемые нотации

Разные нотации походят под разные цели моделирования:

• Для внедрения процессного подхода потребуется описывать и сверху-вниз (тут пригодится VAD, IDEF0, Business Capability Map), так и снизу-вверх (тут лидерство у BPMN, в спину дышит EPC).
• Для формирования ТЗ идеально подходит UML и BPMN.
• Для обеспечения инструкциями всей компании вообще не нужны нотации, нужны текстовые и картиночные материалы.
• Договариваться о том, как работать, лучше всех помогает BPMN за счёт понятности и своей палитры.
• Чтобы находить узкие места в идеале иметь инструмент дискретно-событийного моделирования. Готовых нотаций под эту задачу нет.
• Автоматизировать в BPMS поможет только настоящий BPMN по стандарту OMG.

Похоже, что BPMN – это must have. Остальное – под задачу.

Инструменты поиска и управления сложностью информации

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

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

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

Выгрузка схем, регламентирующих документов

Если участники работы с процессами не имеют возможности (нет сетевого доступа) или не имеют компетенции в современных инструментах, то вам нужно будет предоставлять им информацию в удобном формате – в виде картинок, PDF или .docx файлов.

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

Инструменты согласования и обсуждения

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

Контроль требований по качеству процессов и соглашению о моделировании

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

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

Инструменты импорта 

Тут всё просто – у вас уже 9000 схем в ARIS, которые вы делали 5 лет? Без импорта просто не обойтись, это критическое требование.

Нарисовали 3 процесса в drawio? Можно и перерисовать.

Интеграции с ИТ-системами

Вам нужны интеграции с вами системами – инструменту моделирования нужна хорошая API, максимально традиционная (REST, HTTP, JSON), чтобы ваши программисты не тратили время на разбор формате ODATA, бинарную сериализацию или интеграцию через таблички в базе данных.

Моделирование оргструктуры

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

Возможности анализа процессов

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

Имитационное моделирование процессов

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

Нефункциональные критерии оценки инструмента моделирования

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

Здорово что в инструменте моделирования есть функция создания бизнес-процессов в нотации BPMN, но какой в этом толк, если создание процесса из 25 элементов занимает 8 часов, потому что надо 45 раз кликнуть, чтобы добавить один элемент?

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

Понятный, удобный интерфейс

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

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

• Количество нажимаемых элементов на экранах – чем их больше, тем дольше привыкать. А тем, кто заходит редко (согласующие, сотрудники) – не привыкнуть никогда.
• Группировка информации – если в разных сценариях использования приходится постоянно бегать между разными вкладками и меню, то это плохо и тратит время людей.
• Идиоматичность, целостность восприятия – визуальная способность инструмента самостоятельно рассказать о своём устройстве так, чтобы у пользователя в голове сложилось правильное представление о системе. Сильно экономит время тем, кто начинает моделировать и не бесит тех, кто согласует или читает информацию.
• Аффорданс – ожидаемое и привычное поведение интерфейса. Кнопка "скачать" скачивает, кнопка "добавить элемент" – добавляет. Просто гигиенический минимум.

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

Трудоёмкость основных сценариев

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

Вот типичный сценарий для инструмента моделирования:

• Создать процесс
• Показать процесс участникам обсуждения
• Получить от них обратную связь
• Отработать обратную связь
• Показать процесс участникам обсуждения
• Завершить работу с процессом
• Выгрузить регламент, сложить на полку

Допустим, вам предстоит согласовать 500 процессов.

В одном инструменте выполнение этого сценария занимает 60 часов, а в другом – 30 часов: мало того что вы сэкономили 15 000 тысяч часов (что равняется ~9 штатным единицам, со средним ФОТ 2М на человека это 18М в год), так вы ещё и сделали это быстрее на 89 месяцев.

Пример утрированный, но подход должен быть понятен :)

Ключевых сценариев для инструмента моделирования немного:

• Создать и согласовать процесс.
• Найти информацию по выполнению процесса/операции.
• Прикинуть и посчитать выгоду от изменения процесса.
• Посмотреть отчётность по состоянию процессной модели.

Изучите их в интересующих инструментах моделирования, если есть возможность. 

Работа под нагрузкой

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

Скорость работы

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

Чем больше у вас сотрудников, тем важнее критерий скорости. Одного-трёх бедняг-аналитиков можно легко заставить терпеть.

Способность выполнить требования ИТ и ИБ

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

Совокупная стоимость владения

Отлично, если вы нашли инструмент на 100 баллов из 100, но вдруг он стоит $100K на одну лицензию в год? Важной составляющей принятия решения является совокупная стоимость владения на 3 года. Она состоит из:

• Лицензионных затрат, прямых (на инструмент моделирования) и косвенных (на сопутствующее ПО).
• Стоимости железа.
• Стоимости технической поддержки от производителя.
• Вашей внутренней стоимости человеческих ресурсов на сопровождение.
• Обучение инструменту.
• Обучение нотациям.

Поскольку считаем на 3 года, заложите дисконтирование. Если среди вас финансисты, то можете посчитать PV с учётом инфляции, стоимости денег, альтернативных издержек, возможностей отсрочек и более частых платежей.

Как принимать решение

1. Выбрать вендоров
2. Составить список с весами
3. Попробовать каждого (опционально)
4. Пересмотреть список с весами (опционально)
5. Прикинуть совокупную стоимость владения на 3 года каждого вендора
6. Выбрать лучшее решение за ваш бюджет

Таблица сравнения критериев

Мы подготовили готовый шаблон таблицы, он состоит 4 разделов.

• Опросник: надо ответить на десяток вопросов про вашу организацию. Файлик подскажет, как расставить веса в критериях.

• Критерии вендоров: здесь нужно заполнить информацию по каждому вендору.

• Функциональные и нефункциональные требования заполняйте аналогично по каждому вендору.

• Совокупная стоимость владения – тоже по каждому вендору.

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

Заключение

Как вы заметили, просто так сказать "берите вот этот инструмент" очень сложно, критериев отбора очень много. Но теперь вы не забудете ничего важного, удачи с выбором инструмента моделирования!