Эти вопросы стали ключевыми на виртуальном круглом столе портала IT-World, организованном журналом IT Manager совместно с клубом «ИТ-Диалог», где ИТ-директора делились опытом поддержки и развития систем на базе 1С. Как сказал модератор дискуссии Иван Козлов, ИТ-директор группы «ЛАТЕО», тема возникла спонтанно — из обсуждений в профессиональном сообществе. В центре внимания оказались архитектура поддержки, роль мастер-пользователей и, конечно, разница в философии SAP и 1С. Если первая система жестко диктует правила и дорого обходится в изменениях, то 1С предлагает свободу. Но не все так однозначно... Как переходили с SAP на 1С и выстраивали поддержку После ухода BOSH предприятиям «Энгельс Свечи зажигания», «Энгельс Электроинструменты» и «Термотехника Энгельс» пришлось экстренно перестраивать ИТ-ландшафт. Заводы, много лет работавшие в SAP, за три месяца перешли на 1С. Раньше все изменения централизованно вносились из Германии раз в полгода, а в 2023 году, после отключения ИТ-инфраструктуры, систему пришлось строить с нуля. За полтора года заработали ERP, документооборот, LIMS, PDM и DDFLOW. По словам Сергея Анциферова, ИТ-директора компании «Энгельс Свечи зажигания», отвечающего за ИТ-инфраструктуру указанных заводов, на предприятиях Энгельса сохранили ключевой принцип SAP — осознанный подход к доработкам. Каждое изменение оценивают в часах, на основании чего заказчики понимают реальную стоимость и эффективность доработки и принимают решение о ее необходимости. Без этого 1С можно легко превратить в бесконечный конструктор и потребитель ресурсов. Поддержка организована по трехуровневой схеме: консультанты решают базовые вопросы, аналитики — сложные, разработчики работают с кодом. Но границы между ролями размыты: где заканчиваются задачи аналитика и начинается работа программиста? Еще одна проблема: как отличить мелкую правку от полноценного изменения системы. Если затронут код или изменена логика, это доработка. Но все сложнее, когда ошибка превращается в запрос на изменение, как, например, в блоке бухгалтерского учета в 1С ERP: формы отчетности, налоги, УПД меняются так часто, что каждое обновление превращается в квест. Как корректно разделить ответственность между второй и третьей линией поддержки при устранении ошибок после релиза? Вторая линия исправляет функциональные ошибки, третья — дорабатывает код. Но если после обновления «поехали» расчеты, кто должен решать проблему— вторая или третья линия? Где граница между ними? Попытка сделать 1С универсальной системой может превратиться в головную боль для бизнеса. Вопрос о том, стоит ли 1С ERP превращать в многофункционального монстра или использовать микросервисную архитектуру, остается открытым. Отказ от линий, «барджайл» и минимализм: три взгляда на поддержку А можно ли выстроить поддержку 1С без классической трехуровневой схемы? ИТ-директор фармацевтической компании ЭЛЛАРА Ильдар Шербанов считает, что да. В отличие от коллег, он отказался от разделения поддержки на линии и сделал ставку на аналитиков, которые полностью отвечают за свои блоки. Каждый отвечает за свою зону: один — за склад и логистику, другой — за коммерцию. Они же держат связь с бизнес-заказчиками, разбирают запросы и при необходимости подключают разработчиков. Программистов в штате почти нет, в основном это аутстаф. Но главное — в ЭЛЛАРЕ четко разграничивают поддержку и развитие. «Если речь идет об исправлении ошибки — это поддержка. Если же нужно что-то переделать или добавить, это уже разработка», — объясняет Шербанов. Однако самая большая проблема — не технологии, а привычки пользователей. Люди годами жили в парадигме, что у каждого должен быть «свой программист» — такой всезнающий человек, который поможет и с кодом, и с учетом, и вообще со всем. Но времена меняются. Сейчас ставка на универсалов, которые могут не просто ковыряться в коде, а глубоко разбираться в бизнес-процессах. Это ближе к продуктовой разработке, чем к классической поддержке. Насколько такой подход масштабируем? Пока не попробуешь, не проверишь. В ИТ-департаменте компании «Ультрамар» не до академических моделей поддержки. Здесь не три линии, не две — никакой фиксированной схемы нет. Компания растет бешеными темпами. За четыре года — от котлована до 34 миллионов тонн перевалки, а значит, ИТ-системы тоже приходится строить на ходу. ERP пока только в проекте, работают разрозненные модули: отдельно ЗУП, отдельно бухгалтерия, отдельно WMS. О выделенной техподдержке речи не идет — есть только базовые ответы на вопросы пользователей. А всю аналитику ведут бизнес-аналитики, которые одновременно курируют проекты. При этом есть серьезная кадровая проблема. Работа в порту — это не уютный офис с кофе, а реальные процессы, «по колено в угле». Регламентации почти нет, все знания — в головах сотрудников на местах, и их приходится буквально «выбивать» личными поездками. Максим признает: искать разработчиков и аналитиков сложно, а удерживать — еще сложнее. «Мы что-то делаем, переделываем, внедряем — переделываем, внедряем — переделываем», — CDTO Максим Каранкевич не скрывает, что процесс далек от идеала. Но иного варианта у молодой, но уже гигантской компании нет. Вопрос в другом: можно ли вообще выстроить стабильную поддержку ИТ-систем, если сама компания продолжает жить в режиме стартапа? В компании Roslogistics 1С — далеко не главная система, но без нее все же не обойтись. Основные процессы крутятся вокруг самописной WMS, а 1С задействована точечно: бухгалтерия, документооборот, кадровые процессы и немного торговли. По словам Василия Гаврилова, ИТ-директора, основной принцип работы: минимальный штат, никаких ненужных доработок, а «передвинуть кнопку» — не к ним. Как устроена разработка? За каждый процесс отвечает конкретный человек из профильного подразделения — он же становится стейкхолдером внедрения. Именно он решает, какие изменения действительно нужны, а что можно оставить как есть. Такой подход помогает фильтровать запросы и не перегружать разработчиков. Вся поддержка — только своими силами. Первая линия размыта: helpdesk обрабатывает запросы по всем информационным системам, включая 1С. Сложные вопросы решает небольшая команда из полутора разработчиков. Аутсорс и аутстаф здесь не используют принципиально. Получается строго, лаконично и без излишеств. Четкие линии или гибкость? В Awarus (группа Wone IT) поддержка 1С выстроена строго: первая линия консультирует пользователей, вторая анализирует проблемы, третья — исправляет код. Ключевой принцип — заказчик сам решает, стоит ли делать доработку, зная ее стоимость и риски. Но главный вопрос — архитектура. «ERP нельзя трогать», — считает Александр Капралов, руководитель группы разработки 1С. Бухгалтерию, зарплату и другие модули, требующие частых обновлений, лучше вынести отдельно, чтобы законодательные изменения не тормозили производство. Что важнее для аналитиков — знание конфигурации или бизнеса? На первой линии можно работать без специализации, но дальше нужны эксперты по конкретным блокам. Универсалов не бывает. В «Маревен фуд централ» — производителе Роллтона и Big Bon — 1С только набирает обороты. Основные процессы уже 16 лет работают в SAP, и ближайшие три года никто не собирается их менять. Но для новых площадок SAP уже не вариант: лицензии недоступны, да и экономически невыгодно. Поэтому в компании начали выстраивать полноценную практику 1С. Раньше поддержкой занимался всего один человек, теперь в команде уже два специалиста — аналитик и разработчик. «За две недели я уже почувствовал эффект: доработку, за которую партнер просил 45 часов, команда сделала за полтора дня, используя стандартный функционал», — рассказывает ИТ-директор Петр Сагаловский. Подход к поддержке — классический: все обращения идут в сервис-деск, который сначала пытается решить проблему сам, а если не получается, передает аналитикам. Там уже решается, баг это или фича, которая попадет в плановую доработку. Но главный вызов — архитектура. Одну из бизнес-единиц придется полностью переводить на 1С, повторяя логику SAP: производство, логистика, бухгалтерия, ЗУП. Теоретически бухгалтерию можно вынести отдельно, но подрядчики предупреждают, что это потребует сложного обмена данными. «Придется либо строить шину, либо использовать коннекторы. Плюс, в ERP и бухгалтерии 1С может отличаться логика работы с документами, что приведет к конфликтам», — делится сомнениями Петр. Пока в компании только готовятся к внедрению, но вопросы уже встают острые. Насколько сложно будет синхронизировать 1С с SAP и не потерять управляемость процессами? Это в компании еще предстоит выяснить. Сервис-деск или звонок другу? Нужен ли жесткий регламент в поддержке 1С или пользователи все равно будут обращаться к «своему» специалисту? По мнению Александра Комкова, проректора по цифровизации и информационным технологиям СПбГУ ГА имени А. А. Новикова, все зависит от масштаба компании. Когда пользователей сотни или тысячи, сервис-деск становится необходимостью. «Все обращения должны фиксироваться в базе знаний, проходить через кол-центр или контакт-центр, а возможно, и через ИИ», — поясняет он. Но в небольших компаниях формальные процессы часто не работают: «Можно сколько угодно настаивать на сервис-деске, но сотрудники все равно найдут нужного специалиста и позвонят напрямую». Вопрос аутсорса также не имеет универсального решения. Первую линию поддержки логичнее держать внутри компании — это бесспорно. Однако при небольшом объеме задач содержать штатного специалиста невыгодно. «Когда человек загружен меньше 80 часов в месяц, передавать его задачи подрядчику дешевле», — считает Александр. Эту логику подтверждает и Евгений Гаврилов из «Лонмади». В компании около тысячи пользователей, и без сервис-деска поддержка превратилась бы в хаос. Первая линия отфильтровывает обращения, передает 1С-вопросы консультантам, а если требуется детальный разбор, подключаются аналитики и разработчики. Еще один спорный момент — что выгоднее: держать аналитиков и программистов в штате или передавать поддержку внешним специалистам? Решение зависит от масштаба работы и доступности кадров. Когда объем задач небольшой, проще и дешевле отдать его на аутсорс. Например, если поддержка отдельного модуля, такого как ЗУП, занимает менее 40 часов в месяц, нанимать для этого штатного сотрудника нет смысла. Но аутсорс требует жесткого контроля. Необходимо проверять расчеты, следить за завышенными оценками трудозатрат и отсекать приписки. Кроме того, у подрядчиков часто нет глубокой вовлеченности в бизнес-процессы, а их адаптация занимает время. Внутренние аналитики быстрее понимают задачи компании, выстраивают связь с ключевыми пользователями и оперативнее решают проблемы. «Аналитики внутри — это не только скорость. Это понимание бизнеса, которого у аутсорса никогда не будет», — отмечают участники дискуссии. Вопрос эффективности остается открытым. Когда аналитик глубоко прорабатывает запрос, пишет детальное ТЗ и организует процесс, программисту остается лишь реализовать готовое решение. Это снижает зависимость от разработчиков, но требует более высокой квалификации аналитиков. Идеальный разработчик — тот, который не понадобился Чем меньше требуется доработок, тем лучше для бизнеса. В идеальном мире ERP-система работает без постоянных изменений, а вопросы решаются существующим функционалом. Но реальность другая. Когда речь идет о критичных процессах, например, бухгалтерском учете, доработки неизбежны. Вопрос в том, сколько они стоят и насколько оправданы. Если проблема не срочная, ее могут просто «отложить в очередь» или решать вручную, пусть и с переработками сотрудников. Все упирается в диалог с бизнесом. Как только к стоимости изменений добавляются конкретные цифры — часы работы специалистов, сроки внедрения, возможные риски, — приоритеты резко меняются. «Стоит вот столько» — и вдруг необходимость доработки уже не кажется такой острой. Иногда проще доплатить сотруднику за сверхурочные, чем вкладываться в дорогостоящую переделку системы. Вопрос не только в технологиях, но и в управлении ожиданиями. Без привязки к цифрам бизнес всегда хочет «все и сразу». Как только появляется реальная стоимость изменений, многие запросы исчезают сами собой. База знаний: кто пишет инструкции и кто их читает Хорошо структурированная база знаний должна помочь первой линии поддержки решать типовые проблемы, но на практике это работает далеко не всегда. Одна из ключевых сложностей — заставить пользователей действительно ею пользоваться. Внешние аналитики могут написать подробные инструкции, добавить видеоуроки, но если это четырехчасовые ролики и многостраничные талмуды, их просто никто не читает. В итоге приходится адаптировать материал: сокращать инструкции до нескольких страниц, делать конспекты и обучать пользователей вручную. Оптимальный вариант — когда база знаний четко структурирована и содержит инструкции только по повторяющимся инцидентам. Если проблема встречается регулярно, на нее создается инструкция, по которой потом работает первая линия поддержки. Кто определяет, что проблема типовая? За этим следят аналитики, которые фактически выполняют функции продукт-менеджеров: отслеживают повторяющиеся запросы, анализируют ошибки и формируют документацию. Инструкции должны быть короткими — две-три страницы, иначе ими не будут пользоваться ни пользователи, ни первая линия. Формирование базы знаний в поддержке 1С — процесс, который требует дисциплины и структуры. Один из подходов — при закрытии каждого инцидента фиксировать решение, чтобы оно автоматически попадало в базу. Но важно, чтобы это не превращалось в формальность. «Поначалу все писали «все решено», но потом стали за это наказывать, и база знаний действительно начала формироваться», — рассказывает Петр Сагаловский. Однако одной базы решений недостаточно. Есть два уровня знаний: оперативные ответы внутри тикет-системы и более фундаментальные инструкции для пользователей. Если все хранится в одной системе, это удобно, но на практике часто приходится разделять техническую документацию и пользовательские рекомендации. Некоторые компании экспериментируют с искусственным интеллектом. Первые попытки натренировать модели на инструкциях и истории тикетов дали обнадеживающие результаты. Но пока это только эксперименты. KPI vs реальность Оценка эффективности поддержки 1С — больная тема. Формально все просто: поддержка измеряется скоростью реакции и выполнения заявок, а доработки — объемом реализованных изменений по отношению к запланированному. Но как эти метрики работают в реальности? Например, на заводах Энгельса четко разделены задачи поддержки и доработки, а в сервис-деске ведется отдельный учет запросов на изменения. «У нас есть определенное количество часов разработки в месяц — два разработчика и два аналитика. Мы оцениваем доработки заранее, формируем пул задач на месяц, затем отслеживаем, сколько из них реально удалось завершить. В идеале — 80%, но практика показывает, что это слишком высокий порог», — признается Сергей Анциферов. Насколько трудоемко администрировать этот процесс и сколько ресурсов уходит на сам контроль? Все организовано руководителем поддержки 1С через «Битрикс», где ведется полный цикл работы — от бэклога до релиза. Работа, по сути. Ведется спринтами, с соответствующими фиксированными сроками: анализ и оценка, приоритизация, согласование с бизнесом. Но даже при такой системе план-факт остается проблемным. Александр Комков предлагает другой подход — ориентироваться не на объем выполненных доработок, а на невозвратность инцидентов. «Если проблема повторяется, значит, ее решили плохо. У нас это простое правило: работа над ошибками выполняется бесплатно», — говорит он. Но признает, что этот метод сложнее применять во внутренних командах, где сотрудники не работают по почасовой оплате. Вопрос оценки и сроков разработки в 1С оказался одним из самых дискуссионных. Формально кажется, что все просто: есть план, есть фактические трудозатраты, можно сравнивать и анализировать. Но на практике это не работает так гладко. Одна из стратегий — регулярные встречи аналитиков с заказчиками, где обсуждаются статусы всех задач. Это не про метрики, но позволяет контролировать, почему те или иные изменения постоянно откладываются. Но что делать с программистами, чья работа зависит от оценок сроков? В франчайзи 1С внедряли систему, где при взятии задачи в работу необходимо указывать плановое время, и именно оно становилось основой для расчета премии. «Программист получает деньги не за фактические часы, а за те, что он сам запланировал. Это не дает ему расслабляться и соглашаться на бесконечные правки от заказчика», — объясняет Александр Капралов. Но этот подход работает только с жестким контролем. Например, запрещены оценки больше 40 часов — если задача сложная, ее должны валидировать технические архитекторы. Такой метод дисциплинирует разработчиков, но не всегда удобен для клиентов, которым важны предсказуемые сроки. Где все-таки баланс — оценивать по SLA и срокам? По трудозатратам? Или вводить систему жесткого контроля, как у франчайзи? Пока единого ответа нет — у каждой компании свои точки компромисса между гибкостью и предсказуемостью. 40 часов на кнопку — как контролировать сроки и стоимость доработок в 1С Когда ресурс ограничен, давать заказчику точные сроки — задача не из легких. Даже если трудозатраты можно оценить с высокой точностью, планировать их выполнение сложнее из-за конкуренции задач внутри команды. Что делать? Франчайзи 1С решают проблему гибкости через внутренний обмен ресурсами. Если разработчиков не хватает, можно привлечь специалистов из дружественных компаний. «Если нужно срочно, а у нас нет программистов, мы обращаемся в наш ресурсный центр и договариваемся об аренде специалистов. Если разработчиков нет, говорим заказчику, что сроки придется сдвинуть», — объясняет Александр Капралов. Но даже при наличии ресурсов важен контроль оценки задач. Петр Сагаловский отмечает, что нельзя просто доверять программистам выставлять любые трудозатраты. «Когда разработчик сам себе назначает цену, кто-то должен это валидировать. У меня на предыдущем месте вывели всю ИТ-команду на внутренний аутсорс, и приходилось сталкиваться с тем, что аналитики выставляли счета за то, что две недели обучались, чтобы начать работать с документацией. Почему я должен за это платить?» Чтобы не получать завышенные оценки, компании привязывают ставку специалистов к их квалификации. Новичкам не дают оценивать задачи самостоятельно — перед отправкой заказчику их расчеты обязательно проверяет более опытный коллега. Доверие — еще один важный фактор. Если нет прозрачности, заказчик всегда будет подозревать, что ему выставляют 40 часов за работу, которая заняла 4. Иван Козлов говорит, что контролировать трудозатраты помогает сервис-деск: каждая заявка фиксируется, и если время исполнения кажется завышенным, всегда можно проверить, что именно делали специалисты. «Мелкие заявки мы не смотрим, но если заявка занимает 12 часов, в нее уже можно зайти и посмотреть, на что реально ушло время». Очевидно, что без строгого учета часы могут завышаться, а клиент — платить за воздух. Как это отслеживать? Один из механизмов — автоматический контроль по хранилищу кода. «Если программист запланировал 40 часов, но за это время сделал одно изменение в системе, добавил кнопку — к нему вопросы», — рассказывает Александр Капралов. Каждый понедельник руководитель проекта проверяет, действительно ли вложенные усилия соответствуют заявленным часам. Однако контроль важен не только внутри компании, но и при работе с подрядчиками. Ильдар Шербанов столкнулся с ситуацией, когда внешняя команда запросила 38 часов на добавление поиска по ИНН в документооборот. Внутренние разработчики сделали то же самое за три часа. Когда подрядчик объяснил такой разрыв, стало ясно, что его процесс слишком формализован: сначала аналитик анализирует, потом разработчик разрабатывает, потом тестировщик тестирует. «Осадочек остался», — резюмировал Ильдар и сделал вывод, что с таким подходом больше работать не будет. Конечно, контроль трудозатрат — не просто формальная процедура. Без прозрачных механизмов, будь то анализ хранилища, автоматические метрики или строгая проверка заявленных часов, бизнес рискует тратить деньги на процесс, а не на результат. В завершение дискуссии участники снова вернулись к ключевому вопросу: оправдана ли стоимость доработок? Хороший аналитик понимает, стоит ли игра свеч. Если результат задачи — экономия одной минуты времени для одного сотрудника, а на реализацию требуется 30 часов, никто не предложит такую доработку. Но если та же минута экономится у тысячи сотрудников каждый час или, что еще важнее, у генерального директора, приоритет резко меняется. Подводя итоги, модератор Иван Козлов отметил, что темы поддержки и развития 1С оказались более чем актуальными. Вопросы оценки трудозатрат, структуры поддержки, самообслуживания и архитектуры требуют отдельного обсуждения. «Давайте соберемся отдельно, но уже с архитекторами, потому что тема сложная и неоднозначная», — предложил он. Так что продолжение следует. Видео круглого стола на Rutube и VK Video.