ноябрь    2025

Пн	Вт	Ср	Чт	Пт	Сб	Вс
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

показать все 

31.10.2025

Почти 70% компаний не используют системы защиты от утечек данных

Читать далее 

30.10.2025

Айсорс запустил Центр промышленной автоматизации

Читать далее 

30.10.2025

Каждая вторая компания в мире внедряет системы управления процессами — рынок вырос вдвое за год

Читать далее 

30.10.2025

State of DevOps Russia 2025: рост зрелости команд, интеграция AI и приоритет безопасности

Читать далее 

30.10.2025

70% компаний не соответствуют требованиям закона о защите персональных данных

Читать далее 

показать все 

31.10.2025

Поддержка 1С - "черная дыра" IT- бюджета: как превратить хаос в управляемый процесс и оптимизировать затраты

Читать далее 

18.10.2025

Как посчитать реальную выгоду от ИИ в видеонаблюдении?

Читать далее 

18.10.2025

Управление расходами: режем косты с помощью ИИ

Читать далее 

17.10.2025

Безопасность как сервис (SECaaS)

Читать далее 

16.10.2025

До 97% выросло количество людей, которые реагируют на утечку своих персональных данных

Читать далее 

29.07.2025

Точность до метра и сантиметра: как применяют технологии позиционирования

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

22.09.2023

Эпоха российской ориентации на Запад в сфере программного обеспечения завершилась

Читать далее 

22.09.2023

Сладкая жизнь

Читать далее 

22.09.2023

12 бизнес-концепций, которыми должны овладеть ИТ-руководители

Читать далее 

показать все 

Главная / Статьи / Аналитика / Поддержка 1С - "черная дыра" IT- бюджета: как превратить хаос в управляемый процесс и оптимизировать затраты

Дмитрий Малыгин, управляющий партнер IT-интегратора «ФТО»

Поддержка 1С - "черная дыра" IT- бюджета: как превратить хаос в управляемый процесс и оптимизировать затраты

Экосистема 1С в крупном бизнесе с каждым годом становится все более значимой. Многие критичные процессы автоматизированы на базе 1С:ERP, 1С:ERP УХ и отдельных функциональных решений 1С:WMS, 1С:УТ и пр. Стоимость владения 1С год к году растет.

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

Сколько теряет бизнес на неорганизованной IT-поддержке? 

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

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

Первым под удар попадает бизнес. Хаос в процессах неизбежно влияет на качество поддержки. За примерами далеко ходить не надо, можно начать с банального.

Один из наших клиентов, для которого мы реализовали проект по ETL (выгрузка данных из систем 1С в свежеприобретенном бизнесе и трансформация их в КХД, с которого далее формируется корпоративная управленческая отчетность), в июле 2025 г. пришел с вопросом, есть ли в КХД данные с начала года? Как оказалось, в результате сбоя были уничтожены данные в основной базе 1С, а последний рабочий бэкап был от конца прошлого года. Само собой, это провал организации обеих поддержек - как поддержки 1С, так и поддержки баз данных. Потери огромны, клиент потерял значительный пласт ключевых операционных данных. 

Вторым страдает IT. Очевидно, кейс, приведенный выше, вызывает у бизнес-заказчиков негатив. Страдает репутация CIO, руководителей отделов. Конструктивный диалог с руководством по обсуждению планов развития, бюджетов, сильно затрудняется, уровень обсуждения деградирует с планов развития IT до “тушения пожаров”. IT- служба начинает восприниматься не как источник ценности, а как источник проблем, со всеми вытекающими. 

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

Это закручивает негативную спираль. Потеря людей и потеря репутации - еще больше тушения пожаров - еще больше потерь - … - далее по кругу. 

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

Шаг 1. Уточнение требований бизнеса и инвентаризация. 

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

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

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

• Разделение процессов по степени критичности.
• Уровень критичности каждого процесса (соответственно, ожидаемое или предельное время решения заявок по каждому процессу). 

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

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

Следующий шаг - инвентаризация ресурсов. Опять же, на первом этапе не требуется инвентаризация “до каждой гайки”, но базовое понимание по вашим наличным ресурсам должно появиться, а именно:

• Набор эксплуатируемых систем, связи и потоки данных между ними.
• Ключевые инфраструктурные компоненты (ЦОДы, серверы, middleware), а также мэппинг ИС на инфраструктуру.
• Команды поддержки, их состав, уровень экспертизы, ключевые специалисты, и зоны ответственности по системам и поддерживаемым бизнес-процессам. Конечно, в этот список должны быть включены как внутренние команды, так и контракты с подрядчиками. 

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

Если в количественном аспекте нам может помочь service desk (если он, конечно же, внедрен), то оценку трудозатрат без команды сделать невозможно. Да, на первом этапе этот анализ может быть поверхностным и где-то ошибочным (неточность и намеренное завышение трудозатрат исполнителями никто не отменял).

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

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

Шаг 2. Согласование реального SLA (соглашения об уровне сервиса). 

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

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

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

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

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

Наконец, при дефиците ресурсов могут быть приняты и “непростые решения”: развитие некоторых информационных систем может быть минимизировано или вообще остановлено. 

Шаг 3. Документирование процесса IT-поддержки: регламенты, инструкции и чек-листы. 

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

Одна из первых задач - продумывание программы обучения. Главный аспект этой программы - обучение пользователей - можно решить через анализ повторяющихся заявок поддержки. И это может снять значительный объем нагрузки на первую и вторую линии. Программу же обучения своих команд проще всего будет решить в диалоге с ними. И вместе с ней должен начать создаваться и “курс молодого бойца”. 

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

Анализ повторяющихся заявок может привести нас и к задаче закрытия технического долга или даже рефакторинга отдельных систем или подсистем. В некоторых случаях эффективнее притормозить развитие функциональности для того, чтобы, потратив один-два месяца на закрытие повторяющихся ошибок, снизить нагрузку на первую-вторую линию поддержки на 10-20%. 

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

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

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

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

Как обосновать затраты на IT- поддержку и на чем можно сэкономить. 

Конечно же, наведение порядка стоит денег. По нашим оценкам, управляемая поддержка дороже хаотичной в среднем на 20-30%, по понятным причинам: увеличивается административный ресурс (управление и работа с рисками требует времени), появляется избыточность и резерв в критичных точках, тратится время на ведение базы знаний, добавляется время на коммуникацию при разделении линий, и так далее. 

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

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

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

Очень важно также вместе с пряником применять и кнут - при ответах на те вопросы, ответ на который пользователь должен знать, надо отправлять его в справочную систему, формируя привычку в первую очередь смотреть туда. Да, это тяжело, нужно договариваться с бизнесом и пережить первый вал недовольства при смене политики, но это точно окупается. Повторяющиеся вопросы в некоторых наших поддержках достигают 10-20% всего объема трудозатрат, если хотя бы уполовинить их — это даст огромную экономию. 

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

Причина очевидна – у любого сервиса есть пропускная способность, и при поступлении нескольких приоритетных заявок одновременно шансы провалить жесткие нормативы по SLA гораздо выше, что будет заставлять расширять ресурс команды, создавая избыточность под прогнозируемые всплески нагрузки. Сбалансированные нормативы позволяют держать команду оптимального размера, без излишнего жира. 

IT- поддержка на аутсорсе: когда оправданно? 

Наконец, творчески балансируйте использование своего ресурса и ресурса подрядчиков. Если стоит цель сокращения затрат и есть большой буфер времени на выстраивание своей поддержки, то правильно разделите те области, которые будете закрывать своими силами, и те области, которые отдадите подрядчику. В качестве вариантов, на основании своего опыта, можем предложить:

1. Отдавать на сторону те зоны, где есть нетрадиционный график (выходные, 24*7) и так далее. Задачи в необычном графике чаще всего не занимают 100% рабочего времени, и держать свою команду под них может быть менее эффективно, чем покупать эту поддержку, даже с учетом маржи подрядчика.
2. Отдавать на сторону редкие компетенции, которые не будут полноценно утилизированы внутри (либо будут совмещены с другими, с вероятной потерей качества). Как примеры - оптимизация производительности, DBA, поддержка нишевых систем (например, 1С ЗУП). Скорее всего, здесь не будет работы на полноценного специалиста, и опять же дешевле купить компетенцию на стороне.
3. Оставлять себе корневые компетенции, владение системой. Здесь фактор безопасности суммируется с фактором стоимости. 

Резюме. 

Все в жизни имеет свою цену. Управляемая поддержка стоит денег. Неуправляемая поддержка тоже стоит денег, но через последствия в виде простоев бизнес-процессов. Задайте себе вопросы - какие процессы критичны для бизнеса? Сколько стоит простой процесса? И вам станет значительно проще принять решение инвестировать в выстраивание сопровождения или пока можно повременить с этой активностью. А если решите, что пора - теперь вам не составит труда подготовить экономическое обоснование для защиты инвестиций в этот проект. 

Ключевые слова: ИТ-поддержка, 1С.

О компании

ФТО – IT- интегратор. Занимается внедрением, развитием и поддержкой 1С, BI и инфраструктуры управления данными. Ключевые факты: 20+ лет на рынке, входит в рейтинг CNews500, входит в ТОП 5 российских компаний по поддержке 1С. Отраслевая экспертиза: автоматизация АПК, пищевой промышленности, ритейла, логистики.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи