Три уровня техподдержки для ERP

С чего все начинается

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

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

К чему приводит

В первое время пользователи «забрасывают» вопросами и «хотелками» сотрудников ИТ не смотря на должность специалиста. Для пользователя неважно системный администратор перед ним, разработчик, консультант, технический специалист – для пользователя это «АЙТИШНИК». Именно он виноват в том, что «я нажала, а оно пропало куда-то». И не всегда «айтишник» даст дальновидный и адекватный ответ. Тогда пользователи начинают спрашивать своих коллег, как так могло получиться, начинают решать возникшую проблему самостоятельно или просто не могут понять действия системы, которая предупреждает их о проблеме. В итоге пользователь не занимается своими прямыми обязанностями плюс отвлекает своих коллег, тем самым понижая эффективность всего подразделения. Потом начинается эскалация проблем выше и в итоге получаем совещания, на которых «служба ИТ не эффективна», «новая дорогая система не работает» и т.п.

Как избежать

На самом деле, все очень просто: необходимо верно выстроить отношения между службой ИТ и конечным пользователем. Вот тут и начинают работать три уровня поддержки. Об этом написано много статей, что это такое и зачем нужно, но мало кто применяет на практике.  Ниже я попытаюсь описать более подробно практическое применение этих самых уровней применительно к обслуживанию и поддержке ERP систем, в частности Microsoft Dynamics AX (Axapta) и Microsoft Dynamics NAV (Navision), без сложных технических терминов и определений.

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

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

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

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

Как сократить расходы

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

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

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

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

Автор: Олег Майстренко, ведущий разработчик Dynamics AX компании Neti