Выбор подходящего инструмента автоматизации — не просто перечень функциональных требований, на основе которых компания принимает решение. Это целый «клубок» вопросов: какую цель ставит бизнес по итогам внедрения, как получить универсальную и одновременно гибкую
В статье разбираемся, какие факторы учесть на старте, чтобы получить ожидаемый результат и не ошибиться в выборе
Общий подход к выбору: фокусировка на перечне требований
Когда компания выбирает конкретное
Сам выбор информационной системы в конкурсных процедурах и формирование требований к ней — это отчасти рутинная операция.
Идеальная цель выбора
Возникает вопрос, насколько легко достичь эту цель, если используются стандартные процедуры выбора современного Service Desk. Зачастую уложить все нужное в готовое решение не получается и приходится отходить от первоначальных требований либо мириться с тем, что исходные ожидания не будут выполнены. А если перечень требований еще и постоянно меняется, то уследить за изначальными ценностями становится сложно.
Из-за чего сложно выбрать ИТ-систему
Причин много, и чаще к неправильному выбору приводит не одна ошибка, а сразу несколько.
Излишняя сосредоточенность на функциях. Принятые процедуры кажутся настолько логичными, что заказчик не задумывается об иных вариантах. При общем подходе не учитывается другая проблема — реализация отдельных функций не гарантирует целостную и взаимосвязанную работу процессов и системы.
В перспективе значимее работа не по функциям, а по процессам и пользовательским сценариям. Это позволит бизнесу получить ответы на действительно актуальные вопросы:
- кто ключевые пользователи;
- зачем они обращаются к специалистам сервисных подразделений;
- какие цели преследуют и какой результат хотят получить;
- как организовать взаимосвязь процессов.
Не учитывается вектор дальнейшего развития. Оптимально, когда поддержка и настройка системы может выполняться внутренними силами компании без привлечения интегратора или соисполнителей. Чем шире возможности кастомизации под индивидуальные потребности бизнеса без программирования и специальных профильных знаний, тем лучше.
Субъективность и человеческий фактор. Формирование функциональных требований к программному решению всегда связано с человеческим фактором. Требования заинтересованных лиц могут быть противоречивыми, двояко интерпретируемыми либо неполными. Также в требования нередко включаются условия, которые не обязательны с точки зрения внедрения процессов и системы.
Формальное отношение к процессу. Когда приходится собирать вместе дополняющиеся и зачастую противоречивые требования функциональных заказчиков, сложно не превратиться в утомленного формалиста, который не видит общей картины за бесконечным потоком изменений.
В свою очередь, некоторые компании создают целые методологии: описывают подход к управлению требованиями, ранжируют их по важности, вырабатывают способы объективной оценки систем по соответствию функциональным требованиям.
Поиск идеального решения. На рынке предлагается немало зрелых продуктов класса Service Desk. Каждый потенциальный подрядчик утверждает, что его система лучше всех остальных, и для любого требования, в т.ч. невнятно сформулированного, пытается «натянуть сову на глобус» и доказать, что желаемое полностью соответствует предлагаемому.
Еще нужно отметить существенную разницу между осуществимостью требований после доработки и возможностью их реализации сразу после установки системы. Принципиально отличающиеся логически архитектуры
Внедрение лучшей по результатам оценки системы не гарантирует, что все участники останутся довольны. Соблюдение выставляемых требований к функциональным возможностям не гарантирует построения целевой работы процессов.
Смена подхода: поиск баланса между гибкостью и готовыми процессами в ИТ-системе
Другой более продуктивный подход — формировать требования и описывать ожидания бизнеса не по отношению к системе, а через призму результата внедрения и возможностей, которые должен предоставлять инструмент автоматизации. Такой набор требований условно разделим на два типа.
Индивидуальные требования — определяются спецификой конкретной компании и не всегда релевантны для других:
- Использование российского ПО. Если компания не ограничена выбором только отечественных вендоров, то альтернатив много. Напротив, если нужно исключительно российское решение, этот фактор будет одним из первых.
- Сроки. Если на запуск отводится 2-3 месяца, нет смысла рассматривать варианты, которые требуют обследования, проектирования и длительной настройки.
- Стоимость. Класс продукта определяется размером выделенной суммы из бюджета компании. Сюда входят общие затраты на владение с горизонтом на несколько лет: финансирование поддержки, развития и содержания штата, который отвечает за эксплуатацию системы.
- Производительность. Формально система может соответствовать практически всем требованиям. Но как работать в дальнейшем, если она не будет справляться с нагрузкой большого числа пользователей в ходе эксплуатации?
- Процессы. Если система не поддерживает необходимые компании процессы управления, то ее применение также нецелесообразно. Либо внедрение окажется дорогостоящим, т.к. часть процессов придется разрабатываться с нуля, либо велик риск получить «сырую» реализацию. В такой ситуации, когда конкретный интегратор внедряет процес, компания играет роль первопроходца.
Универсальные требования предъявляются заказчиками в большинстве проектов и корректируются только целями и приоритетами компании. Это поиск баланса между изначально «зашитыми» в систему процессами и их адаптируемостью:
- Быстрый запуск или гибкость. Здесь придется выбирать между уже готовой к использованию системой, приступить к работе в которой можно практически сразу, и платформой, конфигурируемой под индивидуальные нужды заказчика. Разработка, настройка и внедрение подобного инструмента автоматизации может занять продолжительное время.
- Готовая процессная модель или разработка индивидуальных процессов. Внедрение типовых процессов происходит достаточно быстро. В то же время, если деятельность компании не укладывается в стандартные процедуры, потребуется потратить чуть больше ресурсов и времени, чтобы интегратор спроектировал уникальные процессы под задачи бизнеса.
Если компания не планирует автоматизировать процессы с нуля на базе low-code платформы, то придется выбирать подходящий формат внедрения, балансируя между гибкостью и готовностью системы к использованию.
Отметим, в чем особенность этих форматов внедрения.
Проектирование процессов с заказчиком в «коробочном» решении
Разработка уникальных процессов под специфику компании, их автоматизация готовыми средствами системы. Нет гарантии, что спроектированные процессы «красиво лягут» в предлагаемое решение. Подходит для малого бизнеса.
Готовая процессная модель в «коробочном» решении
Быстрая адаптация под требования заказчика внедряемого решения, в котором используются инструменты, позволяющие повысить качество и эффективность процессов на основе лучших практик. Актуально для малого и среднего бизнеса.
Проектирование процессов с заказчиком в адаптируемом решении
Использование административных механизмов для построения и автоматизации процессов компании. Конфигурирование и настройка возможностей системы под уникальные процессы. Актуально для среднего и крупного бизнеса.
Готовая процессная модель в адаптируемом решении
Применение продуманной процессной модели, которая заложена в гибкий инструмент автоматизации. Это позволяет производить тонкую настройку процессов с учетом специфики и потребностей компании. Актуально для среднего и крупного бизнеса.
Если говорить о готовой процессной модели, то здесь на первый план выходят дополнительные факторы.
Выделим отличия каждого из вариантов.
Настройка логики поддержки по услугам разработчиком при несвязанных процессах и системе
Высокая стоимость адаптации системы под процессы и специфику компании.
Настройка логики поддержки по услугам разработчиком при связанных процессах и системе
Развитие системы повлечет использование сложных комплексных процедур и сопряжено с высокими затратами. Если потребуется модифицировать систему, возможен значительный рост расходов.
No-code настройка логики поддержки по услугам при несвязанных процессах и системе
Поставщик предоставит документацию по платформе и консультационную поддержку. Дальше придется самостоятельно адаптировать процессы под нужную специфику, что может занять много времени. Не самый заманчивый вариант.
No-code настройка логики поддержки по услугам при связанных процессах и системе
Готовая процессная модель не требует кастомизации. Система связана с процессами, реализованы гибкие инструменты для настройки процессов без привлечения разработчика. Наиболее привлекательный вариант.
Если нужно адаптировать процессную модель, важны удобство и функциональность инструментов настройки. Их применение должно быть доступным без необходимости привлечения разработчика. И одновременно — не требовать продолжительного времени для достижения результата.
- Степень зрелости процессной модели и ее согласованность с системой автоматизации.
- Возможности, которые предоставляет система без необходимости дополнительной разработки, —
no-code технологии. - Уровень готовности процессной модели и системы автоматизации к использованию. Перед началом эксплуатации важно оценить объем работ по проектированию и настройке, которые придется выполнить в ходе реализации проекта.
- Насколько система адаптируется под архитектуру компании. Например, можно ли создать уникальные формы регистрации запросов, настроить сложные маршруты согласования, изменить интерфейс под корпоративный стиль.
