Свои 1С-ники есть, а очередь задач не тает: как поделить работу с интегратором

Павел СтупкоАрхитектор 1С, бизнес-аналитик

17 сентября 2026 · 11 минут

В компании два-три своих специалиста по 1С. Они знают базу лучше любого подрядчика, сидят в соседнем кабинете и правят ошибку раньше, чем вы допишете письмо. И при этом список задач всё равно растёт: обмен с маркетплейсом, переход на новую редакцию, отчёт для собственника, маркировка — всё «после текущих». Нанять четвёртого — не всегда ответ. Рассказываю, как мы работаем вместе с внутренними командами: что забираем, что не трогаем принципиально и по каким правилам две команды пишут в одну базу, не ломая друг другу код.

Очередь растёт не потому, что люди медленные

Посмотрите, из чего складывается месяц вашего 1С-ника. Основную часть времени съедают короткие обращения: не проводится документ, не печатается накладная, слетела печатная форма, не загрузилась выписка. Таких задач в любой базе на 30–100 пользователей десятки в неделю, и каждая занимает от пятнадцати минут до часа — вместе с тем, чтобы отвлечься, вникнуть и вернуться к прежней работе.

Дальше идут сезонные пики: инвентаризация, закрытие года, новая форма отчётности, срок по маркировке. Они приходят не тогда, когда в календаре пусто, а тогда, когда приходят.

И есть третий слой — компетенции, которые нужны редко, но целиком. Разбор медленного сервера. Настройка обмена с внешней системой, у которой своё API. Переход на новую редакцию с сохранением доработок. Электронные перевозочные документы. Каждая такая задача требует не «ещё одних рук», а человека, который делал это десять раз.

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

Что своя команда делает лучше подрядчика — и отдавать это наружу не надо

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

• Он знает процессы и людей. Почему склад принимает по одной схеме, а филиал по другой; кто из менеджеров всегда путает договоры; какие «исторически так» лучше не трогать до конца квартала.
• Он быстрее в мелочах. Подойти, посмотреть на экран, поправить — минуты. Ни одна заявка через систему этого не обгонит.
• Ему доверяют пользователи. К нему идут с вопросом, а не с жалобой начальнику.
• У него в голове контекст решений. Почему три года назад сделали именно так — часто это знание нигде не записано.

Поэтому наша задача не заменить эту роль, а снять с неё то, что мешает ей работать.

Четыре режима, в которых нас зовут

За годы работы сложились четыре понятных формата. Обычно у клиента одновременно работают один-два.

1. Руки на проект, пока своя команда держит текучку

Самый частый случай. У компании есть срок: запустить обмен с маркетплейсом к сезону, перевести учёт на новую редакцию, открыть филиал, внедрить адресное хранение. Проект требует не «немножко по вечерам», а сосредоточенной работы несколько месяцев. Мы забираем проект целиком — с аналитикой, разработкой, тестированием и обучением, — а внутренняя команда продолжает жить обычной жизнью: обращения, отчётность, мелкие правки.

Что важно: постановку задач и приёмку ведёт ваш человек. Он лучше всех понимает, как система должна работать в вашем бизнесе, и именно он говорит «принято».

2. Редкая компетенция по вызову

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

Здесь мы приходим с готовой методикой и уходим, оставляя отчёт и настроенный механизм. Дальше ваша команда живёт с этим сама.

3. Вторая линия и дежурство

Ваш 1С-ник тоже человек: отпуск, больничный, вечер пятницы, новогодние праздники. А отгрузки идут и в выходные. Мы закрываем вторую линию: первая линия iTeal работает с 7:00 до 23:30 по Москве без выходных, реакция на обращение — до пятнадцати минут.

Формат удобен ещё и тем, что снимает вечный страх руководителя: «а если наш специалист уволится или заболеет в неудачный момент». База под наблюдением, доступы есть, история задач сохранена.

4. Второе мнение и ревью решений

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

Это дёшево по времени и спасает от самых дорогих ошибок — тех, что закладываются в фундамент.

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

Границы описываем на старте письменно — это одна страница, но она экономит недели. Типовая раскладка выглядит так.

Ключевое правило одно: у каждой области один владелец. Не «отвечают оба», а именно один — тот, кто говорит «делаем так». Второй может не соглашаться, но решение принимает владелец. Там, где это правило не записано, конфликт появляется на третьем месяце.

Как две команды пишут в одну базу и не ломают друг другу код

Это самый частый технический страх, и он обоснован: две пары рук в одной конфигурации без правил — гарантированные потери кода и ночные откаты. Что мы делаем.

• Хранилище конфигурации, а не «правлю у себя». Объект захватывается, изменение видно, история сохраняется. Если у клиента хранилища нет — поднимаем его до начала работ, это полдня.
• Наши правки живут в отдельном расширении с префиксом. Его видно в списке, его можно отключить одним движением, и оно не мешает вашим доработкам. Типовую конфигурацию не трогаем, пока это возможно.
• Тестовый контур обязателен. Копия базы, на которой прогоняются изменения перед выкладкой. Без него любая правка — эксперимент на живых людях.
• Релизное окно. Не выкладываем в пятницу вечером, в дни закрытия месяца и в день инвентаризации. Звучит банально, но именно это спасает выходные.
• Паспорт доработок. Каждая правка описана: что сделано, зачем, где лежит, кто заказал. Через год это единственный способ понять, можно ли выкинуть кусок кода.
• Взаимное ревью — по желанию. Ваш ведущий смотрит наш код перед приёмкой, мы смотрим ваш, если попросите. Обычно через месяц это перестаёт быть формальностью и становится обменом приёмами.

Отдельная история — обновления. Доработанная база обновляется не «кнопкой», а через сравнение и разбор конфликтов; как это устроено, разбирали в статье «Как обновить доработанную 1С и ничего не сломать». Когда доработки пишут две команды, паспорт доработок из полезной привычки превращается в обязательное условие.

Регламент, который умещается на одной странице

Мы не любим толстые соглашения: их не читают. Рабочий документ выглядит так.

1. Одна точка постановки задач. Ваша система учёта задач, 1С-Коннект или общий чат — не важно какая, важно, что одна. Задачи «в личку разработчику» не существуют.
2. Кто ставит задачи наружу. Обычно ведущий 1С-ник или ИТ-директор. Иначе приоритеты назначает тот, кто громче попросил.
3. Сроки реакции и оценки. Реакция — минуты, оценка задачи — понятный срок, сдача — дата, которую мы называем до старта.
4. Кто и где принимает. На тестовом контуре, по описанному сценарию, конкретный человек.
5. Тридцать минут в неделю. Общий статус: что сделано, что застряло, что меняется в приоритетах. Этой встречи достаточно, если она не отменяется.
6. Эскалация. Кому звонить в десять вечера, если встал обмен. С именем и телефоном, а не «напишите в поддержку».

Что остаётся у вас, когда мы уходим

Зависимость от подрядчика — плохой товар, и мы его не продаём. На любом этапе у клиента остаются:

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

Где чаще всего искрит

Честно про конфликты — они бывают, и почти все предсказуемы.

• «Ваши правки сломали наше». Лечится расширениями, тестовым контуром и хранилищем: видно, кто и что менял. Пока границы в коде не разведены, искать виноватого бесполезно.
• «Мы бы сделали иначе». Нормальная ситуация: у двух опытных людей два решения. Помогает письменное архитектурное решение до кода — с вариантами и причиной выбора.
• «Кто виноват в инциденте». Журнал изменений и наблюдение за базой отвечают на этот вопрос за пять минут вместо переписки на два дня.
• Страх, что подрядчик вытеснит своих. Самый тонкий момент. Снимается разговором в самом начале и разделением зон: внутренняя команда — владелец системы, мы — усиление на конкретных участках. Если специалист видит, что его не подсиживают, он становится главным союзником.
• Задачи в обход регламента. Кто-то из руководителей пишет напрямую нашему разработчику. Через месяц никто не понимает, чем заняты люди. Возвращаем в одну точку — без исключений.

Когда интегратор не нужен

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

Разница между «у нас всё хорошо» и «у нас очередь» видна по одному признаку: есть ли задачи, которые переносятся с квартала на квартал. Если есть — их не сделают и в следующем.

Чек-лист: пора звать

• Проектные задачи переносятся третий квартал подряд.
• Обновление откладывается, потому что «страшно» — а разрыв с актуальным релизом растёт.
• Отпуск ведущего специалиста превращается в риск для бизнеса.
• Есть задача, которую в компании никто раньше не делал: обмен, переход на другую конфигурацию, требование государства с дедлайном.
• База стала медленной, и внутри нет однозначного ответа почему.
• Доработки писали разные люди за много лет, и никто не берётся сказать, что будет при обновлении.
• Специалист один, и он же единственный, кто знает, как всё устроено.

Три и больше галочек — повод поговорить. Если вы ещё выбираете между своей командой, подрядчиком и фрилансером, у нас есть отдельный разбор с расчётами: «Кто лучше поддержит вашу 1С». А как устроена сама поддержка — линии, сроки, база знаний — в статье «Как устроена поддержка 1С».

Частые вопросы

С чего начать

Начинать разговор лучше не с обсуждения условий, а с фактов о базе. Мы для этого делаем AI Диагностику 1С: разбираем копию базы — код, доработки, обмены, регламентные задания, сервер — и отдаём отчёт с находками и планом работ. Отчёт остаётся у вас независимо от того, будем мы работать вместе или нет.

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