Сколько часов съедает рутина: замер, автоматизация и расчёт окупаемости

Разговор про автоматизацию рутины начинается с вопроса «сколько часов она съедает». Ответ из памяти обычно завышен или занижен: рутинные операции размазаны по дню мелкими кусками, и человек их не считает. Замер на две недели даёт цифру, с которой можно работать.

Второй вопрос звучит сложнее: сколько времени освободит автоматизация. Здесь работает расчёт: сколько раз операция повторяется, сколько занимает вручную, сколько часов уйдёт на разработку и сколько на обслуживание.

📈 Где уходят часы

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

• Разработка. Написание нового кода и правка существующего. Автоматизации поддаётся слабо, но ускоряется инструментами среды.
• Ручные операции. Регулярные действия по расписанию: выгрузка и загрузка данных, перенос объектов между базами, обновление конфигурации, подготовка файлов для бухгалтерии. Главный кандидат на автоматизацию.
• Поиск информации. Как устроен чужой код, где лежит нужный реквизит, в каком регистре хранятся данные. Сокращается базой знаний и сниппетами.
• Отладка и разбор. Поиск причины ошибки, воспроизведение ситуации, проверка гипотез. Сокращается тестами и воспроизводимыми сценариями.
• Ожидание и согласование. Ответы от бухгалтерии, решения заказчика, доступа и стенды. Автоматизации не поддаётся, зато видно в дневнике.

Часы на ручные операции считаются точнее всего, и они же дают самую быструю отдачу: операция повторяется по расписанию, её объём известен, момент выполнения не зависит от чужих ответов.

🧮 Как вести дневник времени

Замер строится на дневнике, и его правила просты.

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

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

Формат дневника - таблица с колонками «дата», «начало», «конец», «минут», «что делали», «задача», «повтор», «категория». Готовый шаблон лежит во вложении, его хватает на две недели.

🧪 Формула окупаемости

Три формулы закрывают вопрос «а стоит ли».

Экономия за месяц = число операций в месяц * время операции вручную - время на обслуживание автоматизации
Срок окупаемости в месяцах = часы на автоматизацию / экономия за месяц
Годовая отдача = экономия за месяц * 12 - часы на автоматизацию

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

Условный пример. Операция повторяется 30 раз в месяц и занимает 20 минут вручную - это 10 часов. Автоматизация занимает 8 часов разработки, обслуживание - 30 минут в месяц. Экономия получается 9,5 часа в месяц, срок окупаемости - меньше месяца, годовая отдача - около 106 часов.

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

💻 Приём, который убирает запрос из цикла

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

Запрос в цикле выглядит так.

1
2
3
4
5
6
7
8
9
10
11

Для Каждого СтрокаТЧ Из Товары Цикл
	Запрос = Новый Запрос;
	Запрос.Текст =
		"ВЫБРАТЬ
		|	Остатки.КоличествоОстаток КАК Количество
		|ИЗ
		|	РегистрНакопления.ТоварыНаСкладах.Остатки(, Номенклатура = &Номенклатура) КАК Остатки";
	Запрос.УстановитьПараметр("Номенклатура", СтрокаТЧ.Номенклатура);
	Выборка = Запрос.Выполнить().Выбрать();
	СтрокаТЧ.КоличествоОстаток = ?(Выборка.Следующий(), Выборка.Количество, 0);
КонецЦикла;

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Запрос = Новый Запрос;
Запрос.Текст =
	"ВЫБРАТЬ
	|	Остатки.Номенклатура КАК Номенклатура,
	|	Остатки.КоличествоОстаток КАК Количество
	|ИЗ
	|	РегистрНакопления.ТоварыНаСкладах.Остатки(, Номенклатура В (&СписокНоменклатуры)) КАК Остатки";
Запрос.УстановитьПараметр("СписокНоменклатуры", Товары.ВыгрузитьКолонку("Номенклатура"));

ОстаткиПоНоменклатуре = Новый Соответствие;
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
	ОстаткиПоНоменклатуре.Вставить(Выборка.Номенклатура, Выборка.Количество);
КонецЦикла;

Для Каждого СтрокаТЧ Из Товары Цикл
	Количество = ОстаткиПоНоменклатуре.Получить(СтрокаТЧ.Номенклатура);
	СтрокаТЧ.КоличествоОстаток = ?(Количество = Неопределено, 0, Количество);
КонецЦикла;

Что здесь меняется: число обращений к базе становится постоянным и не зависит от числа строк; отбор по списку позиций передаётся в параметр виртуальной таблицы, а позиция без остатка получает 0: метод Получить для неё вернул бы Неопределено. В примере у регистра одно измерение, Номенклатура; если измерений больше, добавьте группировку по номенклатуре, иначе в соответствии останется последняя строка позиции. Разница видна на табличных частях в сотни строк; на пяти строках она не заметна.

Оба листинга запущены на платформе 1С:Предприятие 8.3.27.2130 в файловой базе с регистром накопления остатков: на 500 строках табличной части, где у 20 позиций нет остатка, оба варианта дали одинаковую сумму остатков (115 440) и 20 нулей. Запрос в цикле выполнился за 730-818 мс, один запрос - за 20-23 мс; на пяти строках разница в единицы миллисекунд. Время получено на одном компьютере и пустой базе: на вашей конфигурации сверьте план выполнения в консоли запросов до и после правки. Листинги, скрипты стенда и вывод прогона лежат в архиве.

🧰 Готовые инструменты вместо самодельных скриптов

Часть рутины закрывается чужими инструментами, и писать своё для неё не нужно.

• Обновление базы и проверка синтаксиса из командной строки. Команды консоли закрывают выгрузку, загрузку, обновление конфигурации базы и синтаксический контроль. Разбор по шагам есть в опубликованной статье 2804416 про vrunner 3.0, там же - про базу из исходников.
• Выгрузка и загрузка конфигурации в файлы без конфигуратора. Для этого есть ibcmd; порядок команд разобран в статье 2804957.
• Общий модуль с частыми функциями. Место, куда складываются повторяющиеся куски кода: разбор JSON, работа с датами, типовые запросы. Экономия здесь считается по формуле окупаемости так же, как для любой другой операции.
• Стенды и воспроизводимые окружения. Если разбор ошибки начинается с восстановления базы, основная часть времени уходит на подготовку среды, и на поиск причины его остаётся меньше. Про это есть статья 2804418 про несколько агентов на одном репозитории с отдельной базой.

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

🚧 Что замер не показывает

У расчёта есть границы, и их полезно знать до того, как показывать цифры руководителю или заказчику.

• Ожидание не экономится. Часы в ожидании ответов в расчёт окупаемости не попадают: автоматизация их не убирает, убирает другое - договорённость о порядке ответов.
• Проверку посчитать сложно. Если после автоматизации результат всё равно проверяется глазами, экономия меньше расчётной на время проверки.
• Редкая операция не окупается. Операция раз в квартал при десяти минутах работы даёт меньше часа в год: почти всё время уходит на разработку, сама работа занимает минуты.
• Обслуживание растёт. Автоматизация - это код, который живёт вместе с конфигурацией: обновления типовой, изменения реквизитов, разбор новых ошибок. Ноль в строке обслуживания означает, что расчёт неполный.
• Числа требуют повтора замера. Через полгода операция и объём данных изменятся. Дневник повторяется, иначе расчёт остаётся на уровне предположения.

📎 Файл к статье

В архиве к статье - 07.4-companion.zip: шаблон дневника, калькулятор, чек-лист, листинги запросов praktika.bsl, скрипты стенда в папке stand-1c, проверка таблиц check_calc.py и выводы прогонов. Распакуйте архив и запустите python check_calc.py: скрипт пересчитает условный пример. Стенд для запросов собирается командой python stand-1c/build_stand.py на Windows с платформой 8.3.27.

• dnevnik-vremeni.csv - шаблон дневника времени: колонки на две недели, справочник категорий и пример заполнения одной строки.
• kalkulyator-okupaemosti.csv - таблица расчёта: три формулы, поля для подстановки и условный пример из статьи.
• chek-list-avtomatizacii.md - чек-лист выбора первой операции: повторяемость, объём, срок окупаемости, обслуживание.
• README.md - что в архиве, что проверено и что осталось непроверенным. Листинги запросов помечены как непроверенные на платформе.

🏁 Итог

Порядок работы с рутиной укладывается в четыре шага. Две недели дневника - замер повторяющихся операций. Три формулы - расчёт экономии, срока окупаемости и годовой отдачи. Выбор первой операции по сроку окупаемости. Автоматизация и повторный замер через полгода.

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

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 48 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S