Как защищать решение, когда заказчик хочет “как раньше”: практика 1С-проектов

Как защищать решение, когда заказчик хочет “как раньше”: практика 1С-проектов

На 1С-проектах есть фраза, которую почти каждый аналитик слышал хотя бы раз:

“Сделайте как раньше”.

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

И вот аналитик, консультант или руководитель проекта оказывается в знакомой ситуации. С одной стороны, заказчик действительно знает свой процесс лучше внешней команды. Пользователи годами работали в старой системе, Excel, почте, самописной базе, типовой 1С с доработками или вообще в связке из пяти инструментов. Они привыкли. У них есть реальная боль, реальный опыт и реальное право сказать: “Нам так удобно”.

С другой стороны, “как раньше” очень часто означает не лучший процесс, а старый способ выживания. Там могут быть ручные обходы, лишние согласования, неактуальные роли, двойной ввод данных, неочевидные правила, зависимость от одного сотрудника, Excel рядом с 1С, согласования в мессенджерах и отчеты, которые собираются “по памяти”.

Если просто перенести это в новую систему, получится не автоматизация, а консервация старого хаоса.

Эта статья — о том, как защищать решение на 1С-проекте, когда заказчик или пользователи хотят “как раньше”. Не через спор, не через позицию “мы эксперты, вы не понимаете”, а через нормальную аналитическую работу: выяснение причины, сравнение вариантов, фиксацию рисков и аккуратную защиту целевого процесса.

Почему “как раньше” — не всегда плохой запрос

Сначала важный момент: не каждое “как раньше” нужно ломать.

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

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

Например, пользователь говорит:

“В старой системе у нас была кнопка ‘Согласовать без проверки’. Сделайте такую же”.

Можно сразу согласиться и добавить аналогичный сценарий. А можно спросить:

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

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

Тогда переносить кнопку “как раньше” — значит переносить старую проблему.

 

Что обычно скрывается за фразой “как раньше”

Фраза “как раньше” редко означает только интерфейс. Чаще всего за ней скрывается один из нескольких мотивов.

1. Страх потерять привычный контроль

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

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

2. Страх роста ответственности

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

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

3. Непонимание целевого процесса

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

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

4. Попытка сохранить неформальные обходы

В старом процессе могли быть обходы, которые всем удобны, но официально нигде не описаны:

• согласование в личных сообщениях;
• ручное изменение даты документа;
• дублирование данных в Excel;
• устное подтверждение вместо задачи;
• использование общего пользователя;
• обработка документов “задним числом”;
• выбор условного контрагента, если настоящий еще не заведен;
• передача документов через почту вместо 1С.

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

5. Недоверие к новой системе

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

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

 

 

Главная ошибка аналитика — спорить с формулировкой

Когда заказчик говорит “сделайте как раньше”, легко начать спорить:

• “Так неправильно”.
• “В типовой 1С так не принято”.
• “Это плохой процесс”.
• “Мы так делать не будем”.
• “Нужно работать по новой методологии”.

Иногда это правда. Но в такой форме она редко помогает.

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

После этого обсуждение быстро превращается в защиту территории.

Задача аналитика — не спорить с формулировкой “как раньше”, а раскрыть ее.

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

Правильный первый вопрос: “Что именно нужно сохранить?”

Фраза “как раньше” слишком широкая. Она может означать:

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

Поэтому первый вопрос должен быть не “зачем вам это?”, а спокойный уточняющий вопрос:

“Что именно из старого варианта важно сохранить: скорость, последовательность действий, набор полей, отчет, права, возможность исправления или сам принцип процесса?”

Этот вопрос переводит разговор из эмоциональной плоскости в рабочую.

 

Разделяйте потребность и старую реализацию

На 1С-проектах часто путают две вещи:

• потребность — что пользователь хочет получить;
• старая реализация — как это было сделано раньше.

Например:

 

Фраза пользователя	Возможная потребность	Старая реализация
“Сделайте такую же Excel-таблицу”	Быстро видеть список заявок и статусы	Один файл на сетевом диске
“Нужна кнопка как раньше”	Быстро обработать исключение	Ручной обход проверки
“Хотим согласовывать в почте”	Получать уведомления и быстро принимать решение	Ответ письмом без истории в 1С
“Оставьте старый отчет”	Контролировать сроки и ответственных	Отчет, который вручную собирал один сотрудник
“Пусть все видят все документы”	Не терять доступ к нужной информации	Отсутствие нормальной модели прав

 

Когда потребность отделена от старой реализации, появляется пространство для решения.

Можно сказать:

“Я понимаю, что вам важно быстро видеть заявки и их статусы. Давайте сохраним эту потребность, но реализуем не через общий Excel, а через список в 1С с отборами, статусами и ответственными”.

Это уже не спор “старое против нового”. Это поиск лучшего способа закрыть потребность.

 

Три варианта реакции на “как раньше”

Не все запросы нужно отклонять. У аналитика обычно есть три варианта.

Вариант 1. Сохраняем как было

Так стоит делать, если старое решение:

• соответствует целевому процессу;
• не создает рисков;
• понятно пользователям;
• не ломает типовую логику 1С;
• не усложняет сопровождение;
• не переносит старые ошибки;
• экономит время внедрения без потери качества.

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

Вариант 2. Сохраняем смысл, меняем реализацию

Это самый частый и самый полезный вариант.

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

Пользователю важно видеть “всё в одной таблице”. Раньше это был Excel. В 1С можно сделать список с отборами, статусами, ответственными и быстрым переходом в документ.

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

Вариант 3. Не переносим старую логику

Так стоит делать, если старый вариант:

• противоречит цели проекта;
• создает риски безопасности;
• ломает прозрачность процесса;
• мешает отчетности;
• создает дубли и ошибки в НСИ;
• делает систему зависимой от ручных обходов;
• усложняет сопровождение;
• противоречит регламентам или законодательству.

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

 

Как защищать решение без конфликта

Защита решения — это не красивое выступление на совещании. Это последовательность аргументов, которые помогают заказчику увидеть последствия выбора.

1. Признайте старый опыт

Начинать лучше не с критики, а с признания:

“Понимаю, что старый вариант привычный и вы на нем много лет работали. Давайте разберем, что в нем действительно важно сохранить, а что создавало проблемы”.

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

2. Покажите цель изменения

Новая система нужна не ради новой системы. Нужно связать решение с целью:

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

Если цель не названа, любое изменение выглядит как усложнение.

3. Сравните два варианта

Очень помогает простая таблица “старый вариант / новый вариант / последствия”.

 

Критерий	Как раньше	Целевое решение
Скорость выполнения	Быстро для опытных пользователей, сложно для новых	Чуть больше правил, но понятнее для всех участников
Прозрачность	Часть решений в почте и мессенджерах	История хранится в 1С
Контроль сроков	Нужно вручную уточнять статус	Видны задачи, ответственные и просрочки
Риски ошибок	Много ручных действий и обходов	Проверки и обязательные реквизиты встроены в процесс
Сопровождение	Знания в головах отдельных сотрудников	Логика описана и поддерживается в системе

 

Таблица переводит разговор из “мне нравится / не нравится” в “какие последствия мы выбираем”.

4. Дайте альтернативу

Отказывать без альтернативы — плохая тактика.

Вместо:

“Так делать нельзя”.

лучше:

“В точности как раньше переносить не предлагаю, потому что мы сохраним проблему с ручным контролем. Но можем сделать список документов с быстрыми отборами, статусами и ответственными. Это закроет вашу потребность видеть процесс, но без Excel рядом с 1С”.

5. Зафиксируйте риски, если заказчик всё равно настаивает

Иногда заказчик после всех аргументов всё равно говорит: “Нет, делаем как раньше”.

Так бывает. В этом случае важно не превращать проект в борьбу, а зафиксировать риск:

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

Это защищает и команду, и заказчика. Через месяц будет понятно, что решение было осознанным, а не случайно появилось в системе.

 

Пример из 1С:Документооборота

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

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

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

В этом случае защищать решение можно так:

“Сохраняем вашу потребность: быстро отправить договор на проверку и получить замечания. Но не переносим почтовую цепочку как основной процесс, потому что она не дает контроля версии и сроков. В 1С:Документообороте сделаем маршрут с юристом, руководителем и финансами, уведомлениями, возвратом на доработку и хранением истории в карточке документа”.

Это не отказ от потребности. Это отказ от старого обхода.

 

Пример из 1С:ERP

На проекте ERP пользователи могут попросить: “Оставьте нам старую форму заявки, там всё было в одном месте”.

Здесь важно понять, что именно значит “всё в одном месте”. Возможно, старая форма действительно была удобной. А возможно, она была перегружена полями, потому что один документ использовали для разных процессов: закупка, перемещение, списание, заказ поставщику, внутреннее согласование.

Если перенести такую форму без анализа, новая ERP получит старую путаницу.

Рабочий подход:

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

Аргумент может звучать так:

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

Пример из 1С:ЗУП

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

Например, кадровая служба говорит:

“Мы раньше вручную вели дополнительную таблицу по отпускам. Оставьте нам такую же”.

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

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

Вопросы:

• какие поля в таблице реально использовались;
• кто её заполнял;
• как часто данные расходились с ЗУП;
• какие решения принимались по таблице;
• какие ошибки возникали;
• можно ли заменить таблицу отчетом или обработкой процесса в 1С.

Здесь защита решения строится не вокруг “таблица плохая”, а вокруг риска двойного учета.

 

Какие аргументы работают лучше всего

На 1С-проектах лучше всего работают не абстрактные слова про “правильную архитектуру”, а понятные последствия для бизнеса и пользователей.

Аргумент 1. Прозрачность

“Если оставляем согласование в почте, в 1С не будет полной истории решения. Потом будет сложно понять, кто и когда согласовал документ”.

Аргумент 2. Сопровождение

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

Аргумент 3. Масштабирование

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

Аргумент 4. Обучение новых сотрудников

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

Аргумент 5. Риски данных

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

Аргумент 6. Юридическая и управленческая значимость

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

Аргумент 7. Экономика процесса

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

 

 

Что не стоит делать при защите решения

Есть несколько ошибок, которые усиливают сопротивление.

Ошибка 1. Давить авторитетом

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

Ошибка 2. Ссылаться только на типовую 1С

Аргумент “в типовой так” сам по себе слабый. Для бизнеса типовая логика важна, если она снижает стоимость сопровождения, ускоряет обновления, уменьшает риски и закрывает процесс. Нужно объяснять именно это.

Ошибка 3. Игнорировать привычки пользователей

Если решение объективно правильное, но пользователям неудобно делать базовые действия, они найдут обход. Поэтому UX и обучение — часть защиты решения.

Ошибка 4. Побеждать в споре, но терять внедрение

Можно формально доказать, что команда проекта права. Но если пользователи не приняли решение, процесс не заработает.

Ошибка 5. Не фиксировать договоренности

Устно все согласились, а через месяц на приемке звучит: “Мы такого не обсуждали”. Поэтому ключевые решения, отклонения и риски нужно фиксировать.

 

Формула защиты решения

Можно использовать простую формулу:

Потребность → риск старого способа → целевой вариант → компромисс → фиксация решения.

Пример:

• Потребность: пользователю нужно быстро согласовать договор.
• Риск старого способа: почтовое согласование не дает единой истории и контроля версии.
• Целевой вариант: маршрут в 1С:Документообороте с уведомлениями и возвратом на доработку.
• Компромисс: оставить email-уведомления и быстрый переход к задаче.
• Фиксация: согласовать правило, что юридически значимое согласование ведется в 1С.

Такая структура помогает не уходить в эмоциональный спор.

 

Готовые фразы для аналитика

Ниже несколько формулировок, которые можно использовать на встречах.

 

Ситуация	Фраза
Пользователь просит “как раньше”	“Давайте разделим: что именно из старого варианта нужно сохранить, а что было вынужденным обходом?”
Старый процесс явно проблемный	“Если мы перенесем это один в один, мы перенесем не только удобство, но и текущие проблемы: ручной контроль, потерю истории и зависимость от конкретных сотрудников”.
Нужно мягко отказать	“В таком виде я не рекомендую переносить старую логику. Но потребность понятна, поэтому предлагаю другой вариант реализации”.
Заказчик настаивает	“Можем так сделать, но тогда зафиксируем риск: процесс останется зависимым от ручных действий, и эффект автоматизации будет ниже”.
Нужно объяснить типовую логику	“Типовой вариант важен не сам по себе, а потому что его проще сопровождать, обновлять и объяснять новым пользователям”.
Пользователь боится потери скорости	“Давайте отдельно проверим скорость типового сценария. Если новый процесс медленнее, посмотрим, где можно упростить без возврата к старым обходам”.
Нужно защитить целевой процесс	“Цель проекта — не повторить старый интерфейс, а сохранить полезное и убрать то, что мешало контролю, срокам и качеству данных”.

 

Когда компромисс уместен

Компромисс — нормальная часть проекта. Не каждое отклонение от идеальной схемы является провалом.

Компромисс уместен, если он:

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

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

 

Когда компромисс опасен

Компромисс опасен, если он:

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

В таких случаях мягкость аналитика может дорого стоить проекту.

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

Чек-лист: стоит ли делать “как раньше”

 

Вопрос	Если ответ “да”
Старый вариант закрывает реальную потребность?	Потребность нужно сохранить
Старый вариант создавал ошибки или ручные обходы?	Один в один переносить нельзя
Есть ли в 1С типовой способ закрыть эту потребность?	Сначала рассматриваем типовой вариант
Пользователи боятся потерять скорость?	Проверяем сценарий и убираем лишние действия
Старый вариант влияет на права и безопасность?	Нужна отдельная оценка рисков
Есть ли двойной ввод данных?	Ищем способ убрать дублирование
Будет ли это понятно новым сотрудникам?	Если нет, нужен регламент или упрощение
Станет ли сопровождение сложнее?	Фиксируем стоимость и последствия
Кто принимает решение о сохранении старой логики?	Нужен владелец процесса
Можно ли пересмотреть решение после пилота?	Фиксируем контрольную точку

 

Как провести встречу по спорному решению

Если спор зашел далеко, полезно провести отдельную встречу не в формате “докажем, кто прав”, а в формате выбора решения.

Повестка встречи

1. Описать старый процесс. Как работает сейчас, кто участвует, где данные, где решения.
2. Назвать потребность. Что пользователи хотят сохранить.
3. Показать проблемы старого способа. Ошибки, ручные действия, риски, зависания, двойной ввод.
4. Показать целевой вариант в 1С. Не абстрактно, а на понятном сценарии.
5. Сравнить последствия. Скорость, контроль, права, сопровождение, обучение.
6. Выбрать решение. Сохранить, изменить реализацию или отказаться от старой логики.
7. Зафиксировать договоренность. Кто принял решение, какие риски, когда проверяем результат.

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

 

 

Как понять, что решение удалось защитить

Решение защищено не тогда, когда аналитик красиво выступил. И не тогда, когда заказчик молча согласился.

Решение действительно защищено, если:

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

Если после защиты решения пользователи всё равно продолжают жить “как раньше” вне 1С, значит, проблема не решена. Возможно, процесс неудобен. Возможно, не хватает обучения. Возможно, руководители сами не работают в системе. Возможно, старые обходы не были закрыты организационно.

 

Вывод

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

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

Главное — не спорить с привычкой напрямую. Нужно переводить разговор в плоскость последствий:

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

Хорошая автоматизация — это не копия старого интерфейса в новой системе. И не насильственное внедрение “идеального” процесса без учета реальной работы пользователей.

Хорошая автоматизация в 1С — это когда команда сохраняет полезное, убирает лишнее, делает процесс прозрачным и помогает пользователям перейти от привычного обхода к управляемой работе.

Защищать решение — значит не доказывать, что старое плохое. Защищать решение — значит показать, какой результат мы хотим получить и почему старый способ этому результату мешает.

И если после проекта пользователи перестали говорить “давайте как раньше”, а начали говорить “теперь понятно, где документ, кто отвечает и что делать дальше”, значит, решение действительно получилось защитить.