Идеальная модель поддержки бизнес-приложений step by step от IT-Box

Идеальная модель поддержки бизнес-приложений step by step от IT-Box

Скорость развития современного бизнеса, и конкуренция между компаниями настолько высоки, что необходимость использования бизнес-приложений для оперативного принятия решений и быстрого получения достоверной информации сегодня уже не подвергается сомнениям. Подобно кровеносной системе в организме человека, бизнес-приложения обеспечивают жизнедеятельность компании и связывают бизнес-процессы в единое целое. По данным исследований, ежегодные затраты на поддержку и развитие бизнес-приложений составляют до 50% от стоимости внедрения. Поэтому очень важно организовать профессиональную и качественную поддержку систем. Рассказать, что же такое поддержка бизнес-приложений и как ее организовать мы попросили Константина Иванова, директора центра поддержки бизнес-приложений компании IT-Box.

Константин, чем занимается ваше подразделение?

Центр поддержки компании IT-Box занимается поддержкой и развитием бизнес-приложений наших клиентов. Мы оказываем услуги по поддержке систем Microsoft Dynamics AX, 1С, QlikView, MDS SQL, Microsoft SharePoint.

Мы помогаем нашим клиентам добиваться максимальной эффективности от использования системы.

Что эффективней на ваш взгляд поддерживать систему собственными силами или обращаться к внешним консультантам?

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

Расскажите какие услуги по поддержке систем оказывает IT-Box?

Давайте я объясню более подробно. Работы по поддержке бизнес-приложений можно разделить на две основные группы:

1. Hotline поддержка

2. Доработка и развитие функционала.

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

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

Существуют ли какие-то особенности организации Hotline поддержки на Ваш взгляд?

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

Как контролировать качество  предоставляемых услуг?

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

В случае передачи Hotline поддержки на аутсорсинг, компания, оказывающая поддержку обязательно должна нести финансовую ответственность за выполнение метрик SLA. За регулярное и необоснованное нарушение метрик необходимо накладывать штрафные санкции на подрядчика. Аналогично и с собственным ИТ-департаментом. Бонусы специалистов, оказывающих Hotline поддержку должны зависеть от выполнения метрик SLA.

Если компания большая и система используется несколькими подразделениями в период возникновения сложностей запросы в поддержку начнут поступать как снежный ком. Как быть в этой ситуации?

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

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

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

Вы затронули вопрос качества предоставляемых услуг, как нужно организовать процесс, чтобы заказчик всегда оставался «удовлетворенным»?

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

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

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

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

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

Одной из типовых проблем при организации Hotline поддержки пользователей является текучка кадров. Как правило, специалист Hotline поддержки работает на одном проекте 1,5-2 года, после чего его мотивация падает и необходимо обеспечить ему дальнейшее развитие. Для компаний, в которых ИТ не является профильным направлением, достаточно сложно обеспечить горизонтальный и вертикальный рост таких специалистов, поэтому ценные сотрудники уходят и приходится набирать и учить новых. При этом стоит учитывать, что качественная поддержка бизнес-приложений требует глубокого знания бизнес-процессов компании клиента и особенностей используемого в компании функционала. Поэтому первичный срок обучения нового специалиста Hotline поддержки в среднем составляет 3-4 месяца, а обрабатывать 100% заявок он сможет только через полгода.

Следует ли из этого, что иметь собственную команду поддержки не всегда выгодно?

Длительный срок обучения, отпуск, отгулы, больничные, затраты на управление существенно увеличивают эффективную стоимость владения собственными консультантами поддержки. К примеру, если ежемесячная заработная плата с бонусами специалиста поддержки составляет 70 000 рублей, то эффективная стоимость с учетом всех накладных расходов составит 170 000 -190 000 рублей в месяц.

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

А если внешний подрядчик предоставит неопытного специалиста, на кого упадут затраты по его обучению?

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

Давайте перейдем к теме доработки системы в рамках поддержки. Расскажите подробнее об этом направлении?

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

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

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

Кроме наличия в компании внутреннего консультанта, что еще должно быть сделано, чтобы работы по доработке системы стали успешными?

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

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

Как правило, объем доработок, которые необходимо выполнить непостоянен. В какой-то период их может быть меньше, в какой-то больше. Как вы рекомендуете решать эту проблему?

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

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

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

Как повысить качество реализуемых доработок системы?

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

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

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

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

Первый уровень - первичное тестирование модификаций разработчиком.

Второй уровень - тестирование модификаций консультантом.

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

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

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

Ваш принцип работы?

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

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

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