«Разработка на отчетах» на примере планирования ТО. Или «программирование» мышкой, для ленивых

Для начала придется немного погрузиться в специфику учета. Что такое техническое обслуживание (ТО) транспортного средства (ТС)? По сути - это комплекс ремонтных работ вида:

• Довести до нормы уровень (технологических жидкостей, давления и т.д.)
• Закрепить
• Проверить и устранить
• Смазать

Объектами технического обслуживания являются как само транспортное, так и установленные на нем агрегаты: ведущий мост, КПП, двигатель и т.д. Показателем наработки для планирования чаще всего является пробег ТС. Но для спецтранспорта, который не совершает пробегов, показателем являются мото-часы, а ТО легковых автомобилей может планироваться по «дням в хозяйстве», например, раз в год.

Среди видов ТО выделяют:

• Работы основного цикла сервисного обслуживания. Для самого ТС – это последовательно с определенной по показателю наработки периодичностью выполняемые комплексы работ ТО-1(малый)/ТО-2(большой). Например, периодичность – 5000 км, общий цикл (определяется периодичностью проведения ТО-2) – 20 000 км. В рамках одного цикла последовательно будут выполнены: ТО-1 (5000) – ТО-1 (10000) – ТО1 (15000) – ТО2(20000). Комплекс работ ТО-2 полностью включает работы комплекса ТО-1.  Для ТО-2 может выполняться контроль периодичности по времени, например, не реже чем раз в 12 месяцев.  Периодичность проведения ТО агрегатов чаще всего кратна периодичности основного цикла для ТС (и потому планируется совместно с ТО-2 или, ТО-1), но иногда это правило нарушается. Например, цикл ТО-1/ТО-2 м.б. 15 000/30 000 км, а ТО двигателя должно выполняться на каждых 20 000 км. Для ТО агрегатов также может выполняться контроль периодичности проведения по времени (не реже чем раз в … месяцев).

• Однократно выполняемые работы. Например, сюда можно отнести ТО-0 – тех. обслуживание, выполняемое после приобретения ТС после 1000-5000 км пробега.
• ТО, проводимое по приказу. К этому виду ТО относится сезонное обслуживание по подготовке ТС к летнему/зимнему сезонам, на проведение которого издается указ, в какие сроки работы д.б. выполнены.
• Дополнительные регламентные работы тех. обслуживания. Являются периодическими, могут выполняться как для ТС, так и для агрегатов. Могут быть выполнены независимо от проведения ТО (например, остатки масла на складе нужно утилизировать). Планируются независимо, но включаются в план только совместно с ТО транспортного средства или агрегата, к которому относятся.

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

• «По совокупному показателю». Эта логика, в основном, применяется к гарантийным ТС. Независимо от того, когда было выполнено последнее ТО, следующее д.б. выполнено на показателе наработки кратном нормативу. Например, при периодичности 15 000 км, ТО должно быть выполнено на 15 000, 30 000, 45 000 и т.д
• «По межсервисному интервалу».  Если периодичность ТО -15 000, но последнее ТО выполнено на 17 000 км, следующее д.б.проведено на 32 000 (17 000 + 15 000).

План составляется на неделю. Для составления плана рассчитывается коэффициент подхода, который определяет на сколько близко ТС приблизилось к точке наступления события . Для простоты понимания, если между последним ТО и следующим – 10 000 км, а ТС от последнего ТО накатало уже 8 000 км, то К. подхода =  8 000/10 000 = 0,8. ТО на ТС планируется с опережением, «красной зоной» считается К. подхода выше 0.9. ТС в красной зоне должны с максимальным приоритетом включаться в план. Кроме коэффициента подхода при планировании должна учитываться периодичность выполнения ТО (не реже чем раз в … месяцев).

На начало решения задачи у клиента в учетной системе:

• Планирование ТО осуществляется, но планируются только работы основного цикла для ТС (ТО-1/ТО-2).  ТО агрегатов  планируется не по всем ТС, доп. работы и непериодические ТО не планируются. Текущая логика планирования, естественно (иначе бы этой задачи не было), не устраивает.
• Введена вся необходимая НСИ для «нового» планирования.
• Реализован необходимый функционал для фиксации и корректировки факта по новым правилам.
• Информация об агрегатах, установленных на ТС в систему внесена, однако по большей части агрегатов отсутствует информация о прохождении последнего ТО (основного цикла).
• По дополнительным регламентным работам факт выполнения в системе отсутствует.

Можно ли на данных вводных сразу приступать к разработке рабочего места для планирования? Конечно, же нет! Более того, если Вы этим путем пойдете – считайте, что  разработку вы сразу «запороли». Пользователь получит непонятно работающий «черный ящик», использовать который он не сможет. А вы получите безумные потери трудозатрат на бесконечных переделках вашего АРМ и попытках донести до пользователя причину, почему то, что он видит в разработанном вами рабочем месте, так радикально отличается от «идеальной картины мира», которую он проецировал у себя в голове. А все почему?

• Во-первых, даже если вам кажется, что вы идеально сняли требования с пользователей и вам все понятно, со 100% вероятностью половину требований  вы поняли «не совсем так», а вторую половину вы поняли «совсем не так». Например, мы на старте работ по данной задаче абсолютно уверены, что доп. регламентные работы тех. обслуживания включаются в план независимо от работ основного цикла.

• Во-вторых, одно дело -  хотеть что-то делать, а совершенно другое –  начать это что-то делать. Для планирования нужен факт. Половины факта, необходимого для планирования по новым правилам, в системе нет! Напомню, по агрегатам и доп. работам факт отсутствует. А это означает, что все ТС попадут в «красную зону», и процесс планирования просто «встанет».

Что НЕ нужно делать в таком случае?

• Во-первых,  бесполезно убеждать в чем-то пользователя и  пытаться объяснить ему проблематику. Он будет вас слушать, кивать головой, даже соглашаться и при этом АБСОЛЮТНО НЕ ПОНИМАТЬ, в чем собственно проблема. Для него будет очевидно – вы либо работать не хотите, либо пытаетесь доп. финансирование выбить.
• Во-вторых, не нужно пытаться «объять необъятное». Декомпозиция задачи на маленькие составляющие творит чудеса! Чем меньше шаг на пути к результату, тем больше вероятность до финальной точки (живым) дойти. (Мудрость проверена многолетним опытом горных походов).

Что не нужно делать  - разобрали. А что нужно? ПРОБЛЕМУ НУЖНО ПОКАЗАТЬ! И заодно сотворить что-нибудь полезное на пути к нашему АРМ.  И решим мы обе задачи, естественно, с помощью отчета, в котором рассчитаем целевой показатель наработки на след. ТО.

Этот отчет – «визуализация» вашего алгоритма расчета (а еще этот отчет - это промежуточный результат, который можно сдать). Он должен быть понятен вам, аналитику с которым работаете, а также конечному пользователю. Выведите в него те данные, которые необходимы, чтобы проверить рассчитанные показатели, структурируйте информацию, поработайте над оформлением. Если вы смотрите в такой  отчет и не можете быстро объяснить, как получены в нем цифры – скорее всего что-то вы сделали не так.

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

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

Можно ли теперь, используя данные созданного отчета, уже начать рисовать АРМ? И снова ответ нет. Та «очередь», которую мы отобразили в предыдущем отчете совсем не та, что нужна для АРМ. Напомню, планирование осуществляется по коэффициенту подхода с опережением, а не по ориентировочной дате, когда исходя из среднесуточного пробега ТС должно ТО пройти. И снова с большой вероятностью мы поняли пользователя совсем не так, как он того хотел. Потому следующим шагом нам нужно рассчитать уже коэффициент подхода и визуализировать очередь для планирования, показав красную и желтые зоны, а также уточнив, какая информация нужна пользователю для принятия решения о включении ТС в план. И, конечно же, мы снова будем визуализировать наш  расчет с помощью отчета.

Можно ли сразу просчитанные в ранее созданном отчете данные забрать в новый отчет? Можно. Но не нужно. Во-первых, в ранее созданном отчете рассчитывается слишком много данных, да и сам пакет примерно из 40 запросов состоит. А нужен для следующего отчета только целевой показатель наработки (и дата, если контролируется периодичность «не реже чем раз в … месяцев») для каждого вида ТО. И даже несмотря на то, что запрос по одному филиалу выполняется меньше секунды, потенциально, после накопления учетных данных скорость может несколько просесть, что может привести по цепочке к торможениям. К тому же алгоритм еще и не дотестирован – вполне вероятно еще что-то править будем, состав полей менять и т.п.

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

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

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

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

• Факт прохождения ТО.
• Поступление/выбытие ТС и снятие/установка агрегатов (последнее крайне редко, но бывает и такое, что ТС въезжает в столб и требуется замена двигателя).
• Передача между филиалами (правила ведения учета в разных филиалах м.б. различны).
• Изменение нормативов (вероятность близка к нулю, т.к. нормативы прописаны в сервисной книжке производителя, не рассматриваем).

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

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

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

Этот «механизм», кстати, отлично решает задачу согласования изменений в системе. Часто же от пользователей поступает запрос – «при проведении документа автоматически должно в другом документе…». Вместо того, чтобы в транзакции проведения одного документа проводить еще несколько (а потом сидеть «часами» ждать, когда же документ наконец-то проведется), лучше быстро зафиксировать задание на необходимость пересчета, а сам пересчет уже запустить в отдельной транзакции. Работает без сбоев, никакого влияния на скорость проведения не оказывает, данные гарантированно пересчитываются.

В-третьих, (напоминаю, мы обосновываем возможность сохранения промежуточных данных для расчета в регистре), пересчет, в основном, будет запускаться в основном по одному ТС (очень редко по нескольким). И тут мы наконец-то доходим до возможностей СКД. Наш запрос в отчете изначально написан так, что в нем предусмотрена нежесткая параметризация по ТС сразу, начиная с первого запроса в пакете.

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

-

Есть, конечно, и недостаток – в последнем запросе пакета мы получим ненужную выборку полей упорядочивания и представления (исключив которые можно существенно ускорить выполнение последнего запроса).

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

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

Здесь осталось учесть, что мы принебрегли возможностью изменения нормативов. Хоть вероятность низка, но пока новое планирование целиком не запущено нужно предусмотреть, что пользователи могли совершить ошибки при установке нормативов (или мы ошибки в расчетах), а значит нам нужен инструмент для группового пересчета данных в регистре по произвольному списку ТС.  И снова задействуем возможности СКД.

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

Теперь можно приступать к следующему шагу. Как я уже писала выше – рассчитаем в новом отчете очередь планирования, которая нам нужна для АРМ. Основные для расчета данные возьмем из ранее созданного регистра и рассчитаем для каждого ТС по каждому виду ТО коэффициент подхода.

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

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

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

Ну вот и все – наша задача успешно решена. Клиент доволен, и мы довольны вместе с ним. И искренне рады, что вы дочитали эту статью до конца.

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

P.S.2 Посвящается всем, кто ничего не понял в статье Любите СКД так, как люблю ее я.

P.S.3 Я, искренне, много часов пыталась побороть автомасштабирование картинок при вставке, но задача оказалась мне не по зубам. Показательный пример, когда плохая работа разработчиков приводит к полному нежеланию вводить что-либо в систему.