Опыт оптимизации системы ERP на примере железнодорожного холдинга численностью 10 тыс. человек

Меня зовут Ерлан Кавкаев, я руковожу отделом внедрения ERP в холдинге «Камкор».

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

Мы – первая компания, которая внедрила ERP2 для Казахстана, у нас самое крупное внедрение в стране. Дополнительно используем «Управление холдингом» и «Документооборот».

Общее количество пользователей в системе превышает 1200 человек, постоянно онлайн – 400-600. В месяц наши пользователи генерируют 3000 заявок.

Слов нет, нервов не осталось… Пьем чай с беляшами и вместе «толкаем автобус»

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

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

Было принято решение приехать в филиал и пообщаться с людьми на местах.

• Когда садишься рядом с человеком и видишь, что он делает, сразу замечаешь какие-то неоптимальные действия.

• Например, человек открывает журнал документов и пролистывает его вниз до последнего месяца. Ты ему сразу говоришь: «А вы знаете, что в системе можно сразу отбор установить? Будет легче».

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

• Почему у нас появилась возможность вообще попить чай с беляшами? Потому что люди щелкали на открытие журнала выработки и ждали 45 минут.

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

Начинаем «битву за производительность»

В битве за производительность мне помогала наша команда:

• Основную часть взяли на себя консультанты – они же по совместительству еще и руководители проектов.

• Два специалиста полностью взяли на себя ведение НСИ.

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

• И нам помогали почасовые проектные программисты, которые работают где-то в других местах.

• Полезным оказалось познакомиться с экспертом по производительности, который знает серую зону между программным кодом и SQL.

• И системные администраторы – они обычно в эту серую зону не лезут, но отвечают за инфраструктуру.

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

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

• Навести порядок в оборудовании.

• Решить проблемы с каналами связи.

• Поменять серверы – сразу после этого у нас появилась возможность все настроить по рекомендациям фирмы «1С».

• Исключить падения процессов, избавиться от блокировок и исправить тяжелые запросы – это типичные позиции, которые нужно оптимизировать.

• И качество обслуживания нам тоже пришлось поднимать.

На слайде – конкретный пример. Серверная комната до и после.

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

Мы смогли добиться того, чтобы регулярно проводить «технологические окна» – в субботу с утра, пока все отдыхают после пятничных вечеров, наши непьющие админы как раз этим и занимаются.

Мы провели контраварийную подготовку, завели дополнительные каналы питания, поставили UPS-ы, проверили соответствие по пожарной безопасности и так далее. В общем, привели серверную в порядок.

У нас была серьезная проблема с потерей пакетов связи.

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

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

• Все продуктивные серверы мы объединили новыми сетевыми коммутаторами – это позволило нам работать на скорости 10 Гбит и даже 40 Гбит между серверами.

По рекомендациям фирмы 1С был настроен SQL-сервер. Я хочу еще раз обратить внимание, что самостоятельно в эти настройки лезть не стоит, менять там что-то страшно, нормальный человек в этом не разберется. Пусть разбираются специалисты – эксперты по производительности. Такие специалисты могут пригодиться в процессе внедрения.

• Например, важно настроить индексацию таблиц. Потому что если индексов нет, то когда ставится задание: «Найди здесь данные на Кавкаева», система начинает открывать каждую полку и смотреть каждую папочку. А когда правильно построена индексация, команда выглядит так: «Зайди на третью полку, возьми в первом ряду третью папочку». Все идет намного быстрее.

• Разделение баз позволило нам распределить нагрузку.

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

Поскольку мы установили новые сервера, мы смогли:

• Обновить платформу до 8.3.16.

• Включили расширенную функциональность лицензий КОРП.

• И перестроили архитектуру кластера 1С.

Все это тоже позволило сбалансировать нагрузку.

На данный момент наша система в схематическом виде выглядит так:

• Есть единый сервер СУБД, который иногда все-таки является узким местом – если есть серьезная нагрузка на первую базу, вторая база тоже начинает тормозить.

• Разделены серверы приложений.

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

• Во всем этом помогает сервер удаленного доступа (бывший продуктивный сервер).

• Клиенты могут подключаться либо через RDP, либо напрямую – через тонкий, веб или мобильный клиент.

• Веб-клиент, например, очень удобен – его не нужно устанавливать, человек заходит через веб-браузер и практически полноценно работает.

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

Вот таким образом выглядит общая схема повышения производительности:

• Мы замечаем проблемы по отзывам пользователей или консультантов;

• У нас есть настроенные показатели ключевых операций;

• Мы можем посмотреть, что происходит в технологическом журнале;

• И мы можем проанализировать план запросов в SQL.

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

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

Здесь мы видим, как настраивается ключевая операция – например, пользователь согласен ждать проведения этого документа 10 секунд.

Справа показаны замеры производительности, по которым видно, что 4 января пользователю пришлось ждать 11 секунд. Это значит, что у нас уже не будет полного исполнения заданного плана, и нужно что-то сделать, чтобы снизить время проведения до 10 секунд, на которые пользователь согласен.

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

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

Чтобы ускорить эту работу, мы решили пойти немного другим путем и разработали скрипты быстрого разбора технологического журнала.

Например, здесь видно, что запрос «Обработка.пр_РабочееМестоМастера» формирует документ «МаршрутныйЛистПроизводства». И на этой неделе этот запрос исполнялся 4339 раз. Общее время – 7220 секунд, практически два часа. Мы не можем позволить системе выполнять запрос два часа. Будем менять.

По результатам замеров строится табличка, куда мы выводим ТОП-5 самых тяжелых запросов – больше анализировать смысла нет, меньше – тоже.

Какие-то запросы здесь взаимосвязаны – например, если мы три-четыре нижние позиции в ТОПе исправим, вполне возможно, что и верхняя позиция из ТОПа уйдет.

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

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

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

Но константа она на то и константа, чтобы не меняться. А здесь мы видим, что за один день эта константа была переписана 1265 раз.

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

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

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

Еще есть такая вещь как RLS – доступ к данным на уровне записей. Если на одни и те же записи даются одинаковые права разными ролями, то SQL при выполнении запросов вынужден сканировать таблицу вместо использования индексов. И если в таблице почти 9 миллионов записей, и при каждом просчете прав SQL всех их считывает.

По производительности, наверное, всё.

Организационные мероприятия

Кроме этого, пришлось провести серьезную кадровую работу.

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

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

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

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

• Электронная цифровая подпись помогла привлечь дополнительный персонал, в том числе из России и из разных городов Казахстана – они заходят в «Документооборот», подписывают свои акты выполненных работ и вовремя получают оплату.

По организационной работе.

• Здесь мне все-таки пришлось включаться в политику большого холдинга, потому что у каждого подразделения своя политика, свои задачи, свой объем исполняемых действий. Поэтому, когда происходит оптимизация или автоматизация процессов, возникает вопрос, кто это будет делать. Соответственно, нам приходится принимать решения, в том числе и с руководством. Но нужно отметить, что руководство в плане ERP было настроено на результат. И его стоит поблагодарить за поддержку – когда нужно было принимать решения, эти решения принимались, и проект двигался.

• Про регламенты я уже сказал.

• Полезной вещью оказалась мобильная версия «Документооборота». С помощью этого приложения удобно смотреть и согласовывать задачи. А также делать какие-то другие вещи.

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

• Это подняло исполнительскую дисциплину на местах и на всех уровнях.

Что мы еще сделали по проектной работе?

• Естественно, приоритизировали проекты. Когда приходит новый заказчик и говорит: «Нам нужно это сделать, кровь из носа», мы ему предоставляем список проектов и предлагаем какой-нибудь из них подвинуть. Часто на этом разговор заканчивается.

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

Новые проекты. Стандартизация, оптимизация и автоматизация

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

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

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

• Если это серьезная автоматизация дополнительных процессов, инициируйте второй проект.

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

В этом всем серьезно помогает автоматизация «Документооборота».

• Заявку на доступ мы уже перевели в «Документооборот». Сделали шаблон – люди заполняют нужные крыжики и отправляют заявку на исполнение нам.

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

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

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

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

• После разработки и тестирования консультантом пользователю ставится задача протестировать. Это тоже дисциплинирует.

• А после того, как мы вставили в продуктив, пользователь должен подтвердить, нормально ли все работает уже в готовом варианте – без этого последнего пункта мы программистам, кстати, работу не оплачиваем.

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

• Задача может быть возвращена на доработку.

• К ней можно назначить дополнительные задачи и так далее.

• Контроль сроков тоже на уровне «Документооборота».

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

• Ну и для подтверждения выполненных работ анализируем заявки, выгруженные из 1С-Коннект.

Результаты оптимизации. Не толкаем, а едем

Что произошло в результате всего этого

• Индекс APDEX, который в начале декабря 2020 года погружался до 0,49, в конечном итоге возрос до вполне приемлемых 0,85-0,89. В некоторых базах 0,96 и выше. То есть система работает.

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

Здесь приведены объективные замеры времени:

• в декабре 2020 года формирование оборотно-сальдовой ведомости занимало 10 секунд;

• в июле 2021 года – 2,4 секунды.

Человек быстро привыкает к хорошему и не замечает изменений. Но, тем не менее, система объективно работает.

Какие результаты оптимизации:

• Самое важное достижение для нас – это формирование финансового результата. Сейчас мы предыдущий месяц закрываем до 15-го числа. Раньше приходилось пересчитывать данные несколько месяцев.

• Торможения системы исключены.

• Мы уже можем реализовывать новые проекты. И они активно идут.

Вместо «сломанного автобуса с пробитыми колесами и разбитыми окнами», мы имеем более-менее рабочую схему. Проблемы, конечно, есть. От этого не избавиться просто так. Тем не менее люди сейчас едут, а не толкают этот автобус. И для меня это очень приятно.

Вопросы

Сколько времени занял проект внедрения?

Система начинала внедряться в 2016 году, остатки были занесены на конец 2015 года.

Меня подключили к проекту в 2019 году, и тот объем работ, о котором я рассказывал, был проведен за два года командой из 17-18 человек. Сейчас мы подключили еще дополнительных людей на обслуживание.

Сколько юридических лиц в компании? И физически база 1С:ERP была одна или несколько?

База была одна. Решение принималось без меня, до того, как я пришел.

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

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

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

Какой прирост в год у самой большой базы?

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

Как собирается консолидированная отчетность, если базы разные?

Нужная отчетность формируется в «Управлении холдингом», для которой с самого начала была построена интеграция с ERP.

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

Весь сервис-деск на 1С:ДО или на 1С-Коннект?

На данный момент основной сервис-деск использует 1С-Коннект.

1С-Коннект используется для общения с пользователями. А 1С:Документооборот используется для того, чтобы фиксировать заявки и отслеживать работу по ним.

Сейчас у нас стоит задача реализовать механизм 1С-Коннект полностью в 1С:Документообороте. И вообще отказаться от 1С-Коннект, потому что его нельзя изменить.

Рассматриваем такой вариант, чтобы:

• более четко анализировать причины появления заявки;

• ставить оценки пользователям – 1С-Коннект это не позволяет;

• делать выводы – проблема системная, проблема пользователя или это обычная консультация.

Вопрос по целевым показателям времени. Кто именно определяет, сколько времени должна выполняться операция? Потому что обычно, когда вводится APDEX, пользователей спрашиваешь, сколько времени должен проводиться документ, они говорят: «Сразу же».

Да, есть такая проблема. Мы пытались получить целевые показатели от конечных пользователей, и они нам их не предоставили. Они сказали: «Вы каждый день наши заявки обрабатываете, и должны лучше знать, как должно быть».

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.