Многие бизнес-процессы в небольших компаниях — типовые. Однако выбрать решение, подходящее под их исторически сложившуюся комбинацию бывает не так-то просто. Даже если продукт соответствует основным требованиям, в ходе эксплуатации вполне может обнаружиться какая-нибудь «неприятность». Например, интерфейс настолько неудобен, что на типовые операции сотрудники тратят столько же времени, сколько и без системы автоматизации вовсе. А может в выбранном решении будет «криво» реализована поддержка важной для вас платформы? Инвестиции системы с такими «недочетами» не приносят ожидаемого результата.
Конечно, все требования к продукту, в том числе, упомянутую поддержку платформ, наличие определенных модулей, вспомогательных элементов интерфейса и т.п., в теории можно формализовать и свести в таблицу. Но чаще сам заказчик слабо представляет, как электронный документооборот заменит бумажный в рамках его организации, или как сотрудники его отдела технической поддержки будут относиться к заполнению подробных форм об инциденте заказчика. Многие моменты можно выяснить лишь на практике. И понимание этого факта становится серьезным барьером внедрения.
Как минимизировать риск на этапе выбора help desk решения? Как правильно внедрить Service Desk? Подробная инструкция по успешному внедрению!
Service Desk. Тестовые внедрения
Для снижения подобных барьеров разработчики решений, автоматизирующих различные аспекты бизнеса, предлагают пробный (триальный или тестовый) период, когда можно оценить все функции и возможности программного обеспечения. А заодно можно пообщаться с поддержкой вендора, сделав вывод, сложится ли ваше сотрудничество.
Благодаря «тестовым внедрениям» выбор программных инструментов для большинства компаний может проходить по стандартной схеме:
- принято решение о необходимости автоматизации;
- определили важные критерии продукта;
- подобрали кандидатов на внедрение;
- попробовали
1-2 варианта; - остановились на каком-то «победителе» (иногда «лидер» остается один еще до тестирования);
- начали внедрение.
Постоянный поиск решения. К чему это приводит?
Однако есть заметная доля компаний, для которых процесс поиска идеального инструмента растягивается на годы. Решение вроде бы выбрано, тестируется, но уже в процессе выясняется, что оно не подходит, и все начинается заново. При этом каждая последующая итерация ощутимо «бьет по карману»:
- тратятся ресурсы. Хотя тесты проводятся на пробных бесплатных версиях, для компании они все равно стоят денег. В первую очередь расходуются человеко-часы (которые оплачиваются через ФОТ). А иногда под тесты закупается оборудование или нанимается дополнительный персонал;
- расходуется время. Можно подумать, что начало проекта внедрения уже само по себе ставит компанию на новый уровень — например, ближе к конкурентам, успевшим автоматизировать основные операции ранее. Но это не так. Из-за необходимости обучать часть сотрудников новым инструментам, менять их рабочие привычки, первое время после внедрения задачи решаются даже медленнее, чем без автоматизации. Т.е. на самом деле реформа используемого подхода отбрасывает компанию немного назад. Однако если научиться и привыкнуть, отставание быстро окупится значительным ускорением. Как говориться, «день потерять, потом за 5 минут долететь». Гораздо хуже, если вслед за первым внедрением последует второе, третье и последующие — в этом случае придется все время отступать немного назад. Конкуренты же в это время будут либо просто работать, не тратя время на параллельные проекты, либо с огромной скоростью уходить вперед, завершив автоматизацию;
- теряется доверие к руководству и людям, принимающим решения. Если сотрудников постоянно заставляют делать работу, которая не приводит к какому-то результату (а после теста очевидный результат — внедрение решения в «боевом» режиме), то у «низов» начинаются вопросы.
Service Desk и его внедрение. Новый подход к выбору
Чтобы не превращать выбор системы автоматизации в разновидность «дня сурка», прежде чем что-то в очередной раз выбирать и тестировать, необходимо определиться с несколькими моментами:
- с требованиями к ПО по части архитектуры, безопасности, функционала и интерфейса. Повторный возврат к выбору решения означает, что в самом начале задача была сформулирована некорректно или не полностью. Возможно, следует вернуться ко второму шагу в перечне выше — сбору и анализу требований заинтересованных сторон;
- с критериями принятия положительного решения. Довольно редко существующие массовые решения в деталях удовлетворяют требованиям всех без исключения участников рынка. Так уж устроена экономика ИТ-продуктов: инструменты, рассчитанные на массового пользователя, разрабатываются, чтобы удовлетворить потребности большинства, но не всех без исключения. Поэтому нужно изначально понимать, что выбирая готовый продукт (а не индивидуальную разработку под себя), придется идти на компромиссы. И это необходимо формализовать. Например, мы договариваемся, что внедряем не идеальное решение, а то, которое получит самый большой средний балл из всех по таблице соответствия нашим требованиям;
- с людьми, которые будут задействованы в выборе, принятии решения и внедрении. Необходимо понять, кому предстоит соприкасаться в своей работе с инструментом и какие он может ставить условия. Не логично же, если бухгалтерия будет определять интерфейс для сотрудников поддержки. Важно не раздувать список затронутых работников без необходимости, ведь иначе это только усложнит процесс. И нужно подготовиться к тому, что требования разных отделов к продукту могут противоречить друг другу. Кто в этом случае будет принимать решение? Отметим, что слишком много требований — также плохо, как и слишком мало: они не отражают реальное положение вещей. Поэтому необходимо установить приоритет — чьи и какие именно требования важнее.
- аналогично нужно дать кому-то полномочия принимать решения по проекту, в частности, устанавливать высокий приоритет его задачам на фоне текущей деятельности компании, иначе проект может так никогда и не завершиться;
- с ресурсами на внедрение — как минимум, со временем. ИТ-системы, конечно, можно преобразовать за ночь, но с ними работают люди, которые намного более инертны. После любых изменений сотрудникам требуется время на адаптацию. Измерять эффект на утро после запуска бессмысленно, как и с первого часа работы с новой системой требовать от них соблюдения тех же метрик времени, что и с привычными инструментами;
- с целями внедрения теста и ожидаемым результатом, и это самое главное. Иногда решение о тестировании очередного продукта принимается на уровне «давайте посмотрим, а потом подумаем». В такой формулировке проект, скорее всего, не дойдет до финальной стадии. Всегда нужна определенность: четкие и реалистичные критерии, которые позволят в правильный момент перейти от тестирования к полноценной работе.
- о реализуемости, кстати, хотелось бы сделать отдельное замечание. Хотя на рынок ИТ-технологий уже пришел здоровый прагматизм, все еще остается доля заказчиков, имеющих завышенные ожидания относительно внедрения средств автоматизации. Помимо технических задач, на тестируемые продукты возлагают решение организационных вопросов — и тут ничего не выходит. Зачастую причина тому — плохая информированность о кейсах внедрения подобных решений.
Кстати, во многих случаях разорвать бесконечную последовательность внедрений различных кастомизированных решений помогает разделение задачи, а точнее — выбор модульного продукта (в котором можно отключать ненужные модули и подключать нужные), который можно осваивать по частям. Начать с внедрения ядра (основных функций), а затем постепенно дополнять систему модулями, автоматизируя дополнительные процессы.
Вместо заключения отметим, что менять инструменты для автоматизации — это нормальный процесс в ходе взросления компании. Однако делать это необходимо как в случае любого не самого простого проекта, имея ресурсы, деньги, время и учитывая окупаемость внедренных продуктов.
Облегчить задачу можно, если Service Desk простой, позволяет быстро запуститься и не требует серьезной подготовки и настройки. Например, одним из самых простых и удобных решений на рынке Help Desk является Okdesk.
