Пользователи жалуются на 1С: где искать причину
Разбираемся, почему бизнес-пользователи могут быть недовольны работой системы и какие три фильтра помогут ИТ-директору выявить на каком уровне происходит сбой.
Обращения пользователей
Каждый ИТ-директор, который отвечает за поддержку 1С, хотя бы раз сталкивался с подобной ситуацией: бухгалтерия сообщает, что «система тормозит», склад фиксирует проблемы с проведением документов, а руководитель спрашивает, почему при работающей поддержке сотрудники всё равно недовольны.
При этом формально всё выглядит хорошо: SLA соблюдается, заявки закрываются, специалисты на месте. Но ощущение, что поддержка работает не так, всё равно остаётся.
За двадцать лет работы в поддержке 1С мы видели сотни подобных ситуаций и в небольших производственных компаниях, и в холдингах, где количество баз превышало сотню. Картина везде схожая: практика показывает, что большинство жалоб связано не с ошибками системы. Чаще проблема возникает там, где ожидания пользователей расходятся с тем, как настроены процессы в 1С. Именно здесь появляются скрытые потери: простои, повторная работа, ручные проверки и «теневые» Excel-таблицы, которые сотрудники начинают вручную вести в обход системы.
Почему пользователи жалуются на 1С
На первый взгляд, все жалобы на 1С довольно типичны, условно их можно разделить на четыре категории:
- «Система тормозит». Медленно проводятся документы, долго формируются отчёты, интерфейс постоянно зависает.
- «Возникает ошибка при работе с системой». Документы не проводятся, появляются сообщения о системных ошибках, данные в отчётах расходятся с фактическими.
- «Неудобно работать». Пользователь считает, что раньше процесс был проще или требует слишком много действий.
- «Не знаю, как это сделать». Пользователь не понимает последовательность действий для выполнения задачи.
На первый взгляд, причины выглядят разными, но после анализа заявок картина часто меняется.
Где искать причину: в системе, процессах или пользователях
Когда поступает жалоба, первая реакция почти всегда одинакова: проверить сервер, посмотреть логи, обновить платформу, проверить код в 1С. Это логичный первый шаг, но далеко не всегда самый результативный. Практика показывает, что в большинстве случаев проблема сидит не в коде 1С, а в том, как вообще организована работа вокруг системы.
У нас в команде есть негласное правило: любую жалобу мы сначала пропускаем через три фильтра.
1. Технический
Сначала нужно понять, действительно ли есть сбой.
Проверьте:
- ошибки в логах;
- блокировки;
- состояние сервера;
- производительность платформы;
- работу функционала, в том числе со стороны кода.
Эта часть хорошо диагностируется и обычно быстро подтверждается или исключается. Если причина действительно техническая, её обычно можно быстро локализовать.
2. Бизнес-процесс
Следующий вопрос: соответствует ли настройка системы текущей работе компании.
Например, компания изменила учётную политику, но настройки 1С не обновили. Или сотруднику требуется выполнить операцию, на которую у него отсутствуют необходимые права. Пользователь видит ошибку, хотя источник проблемы находится в организации процесса.
3. Пользователи
Самая недооценённая категория — уровень подготовки сотрудников.
Даже опытный бухгалтер может не знать, как использовать стандартные возможности системы, если его никто не обучил работе с отчётами или настройками. В результате вместо нескольких кликов появляется заявка в поддержку или параллельный ручной отчёт в Excel.
Как отличить симптом от причины
Разовые обращения мало что говорят о состоянии поддержки, гораздо полезнее регулярно отслеживать ряд показателей. Мы выработали для себя пять контрольных точек, которые позволяют трезво оценить, что происходит с поддержкой 1С на самом деле.
1. Классификация заявок и приоритеты SLA
Запрос «как создать контрагента» не должен иметь тот же приоритет, что остановка проведения документов в день отгрузки. Если критичные и бытовые задачи попадают в одну очередь, бюджет поддержки начинает расходоваться неэффективно.
У нас был случай, когда компания просто не различала критические и мелкие задачи, и в итоге 30% бюджета поддержки улетало в трубу на «доделки» и перепроверки.
2. Среднее время восстановления (СВВ) для критичных инцидентов
Рост этого показателя часто говорит не о нехватке сотрудников, а об отсутствии актуальной документации, сложной архитектуре или неработающей системе эскалации.
Кейс из опыта ФТО: сокращение показателя СВВ с 4 часов до 1,5 часов без найма новых специалистов только за счёт составления базы знаний по самым частым проблемам. Эффект: один критичный сбой теперь обходится бизнесу примерно на 1,7 млн рублей дешевле.
3. Доля повторно открытых заявок
Если закрытые обращения регулярно возвращаются в работу, значит устраняется следствие, а не причина. Для зрелой службы поддержки показатель повторных открытий обычно не превышает 3–5%.
Ориентиры выглядят так:
- до 5% — хороший показатель;
- 10–15% — повод искать системные проблемы.
4. Продуктивность консультантов
Важно понимать, сколько времени специалисты тратят на решение задач, а сколько — на поиск информации, переписку и уточнения. В плохо организованной поддержке на такие действия может уходить почти половина рабочего времени.
5. Удовлетворённость пользователей
Команда ФТО практикует проведение анонимного опроса пользователей с периодичностью раз в полгода. Мы спрашиваем: «Решает ли служба поддержки ваши проблемы?».
Если доля положительных оценок опускается ниже 70%, это может быть «звоночком» того, что пользователи, возможно, ищут обходные пути решения проблем. Регулярный сбор обратной связи помогает увидеть проблемы раньше, чем они перерастут в серьёзные финансовые потери.
Кейс: как сократить количество обращений на 40%?
В практике ФТО был рабочий проект с производственным холдингом с около 200 активных пользователей 1С. Сотрудники постоянно жаловались на «тормоза» в работе системы, и изначально казалось, что проблема кроется в перегруженной поддержке: команда выгорала, потому что не справлялась с валом заявок.
Приступив к работе, мы, в первую очередь, провели анализ всех обращений и выяснили, что большинство заявок были обычными консультациями. Пользователи приходили с вопросами: как ввести новый товар; как распечатать накладную; где найти нужный отчёт.
Следующим шагом стал сбор самых частых вопросов и написание для них коротких инструкций с картинками. Базу знаний мы сделали прямо в интерфейсе 1С. Затем мы обучили пользователей заглядывать туда перед тем, как обращаться в поддержку.
Результат за три месяца:
- количество обращений снизилось на 40%;
- специалисты смогли сосредоточиться на действительно сложных задачах;
- пользователи стали реже обращаться в поддержку по типовым вопросам.
После проведения этих работ производительность заметно улучшилась без дополнительных затрат на инфраструктуру, жалобы пользователей практически исчезли, а расходы на поддержку снизились на четверть.
А что с «тормозами»?
Самое интересное открытие ждало нас после проведения дополнительного анализа. Так как на первый взгляд казалось, что система просто имеет низкую производительность, то вопросы возникали исключительно к работе сервера: сотрудники просили заменить железо на более мощное.
На самом деле выяснилось, что пользователи регулярно запускали огромные годовые отчёты без фильтрации, и, как следствие, система начинала «подвисать».
Со стороны сервера ничего менять не пришлось. Вместо этого мы:
- улучшили интерфейс;
- добавили подсказки по фильтрам;
- провели серию коротких обучающих вебинаров.
Кейс: когда жалоба — это сигнал к пересмотру SLA
Ещё один показательный пример из нашей практики — проект по поддержке крупного системообразующего холдинга с производственными площадками в нескольких регионах и сотнями пользователей по всей стране.
Жалобы были разные, но по сути сводились к одному: медленные ответы со стороны поддержки. Формально SLA выполнялся, но пользователи оставались недовольны.
Причина оказалась простой: во время закрытия месяца и сдачи отчётности нагрузка резко возрастала. В обычные периоды текущие нормативы работали хорошо, но в пиковые недели переставали соответствовать реальным потребностям бизнеса.
Мы предложили пересмотреть соглашение и ввести «динамическое SLA»: в пиковые периоды мы сокращаем время реакции по критичным инцидентам, а в обычные дни возвращаемся к щадящему режиму.
Что ИТ-директору стоит сделать уже сейчас
На основе этих и десятка других кейсов мы сформулировали для себя пять простых шагов, которые реально могут значительно повысить эффективность поддержки.
1. Начните измерять показатели
Фиксируйте время заявок, приоритеты, повторные обращения и время восстановления. Без цифр вы будете реагировать на каждую жалобу как на пожар, не понимая, где действительно сейчас «горит».
2. Научитесь разделять критичные и обычные заявки
Не все обращения требуют одинаковой скорости реакции:
- критичный сбой, который стопорит отгрузку, — это P1;
- запрос «поменять пароль» — это не P1.
3. Ищите первопричину
Если у вас высокий СВВ, спросите себя «почему?». Может, у вас нет необходимой документации? Или архитектура настолько сложная, что пользователи в ней не разбираются?
4. Инвестируйте в обучение пользователей и команды
В 80% случаев проблема поддержки упирается в квалификацию. При этом именно опытность пользователей снижает нагрузку на поддержку намного эффективнее, чем увеличение количества консультантов.
5. SLA — это не догма
Регулярно пересматривайте SLA. Бизнес меняется, а вместе с ним должна меняться и модель поддержки.
Вывод и рекомендация
Мы привыкли относиться к жалобам пользователей не как к раздражающему шуму, а как к ценному источнику информации. Каждая жалоба — это сигнал о том, что что-то идёт не так: либо неотлаженный процесс, либо недостаток знаний, либо (в редких случаях) железо. Без системы расшифровать этот сигнал почти невозможно.
Возьмите десять последних обращений в поддержку. Просто сядьте и разберите каждое по трём критериям: техническая проблема, процесс или человек. Вы удивитесь, но в 7–8 случаях из 10 причина будет связана не с самой конфигурацией 1С, а с тем, как организована работа вокруг неё.
И главное: не экономьте на поддержке, нанимая дешёвых специалистов. Был в нашей практике случай, когда компания взяла младшего консультанта за 60 тысяч, чтобы сэкономить. Через полгода она потратила на переделки и устранение последствий его ошибок в три раза больше, чем сэкономила на зарплате. Профессиональная команда стоит денег, но окупается стабильностью бизнеса, а стабильность в мире 1С дорогого стоит.
Главное
Жалобы на 1С редко означают, что проблема находится внутри платформы. Чаще они указывают на слабые места в процессах, обучении пользователей или организации поддержки.
Для ИТ-директора важно смотреть не только на выполнение SLA, но и на качество процессов, повторяемость инцидентов и удовлетворённость сотрудников. Такой подход помогает снижать нагрузку на поддержку, сокращать простои и превращать сопровождение 1С в инструмент повышения эффективности бизнеса.
Нужна консультация специалиста по поддержке 1С?
Кратко опишите ваши потребности — мы свяжемся с вами и предложим оптимальный вариант решения вашей задачи