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

Александр Казеннов Исполнительный директор ALP Group Наша команда занимается разработкой нетиповых корпоративных систем, которые идеально соответствуют целям конкретной организации и отличаются высокой производительностью при любой нагрузке (65 000+ пользователей, 400 000+ транзакций первичных данных в сутки), гарантируя оперативное принятие управленческих решений на основе качественных данных. Мы понимаем уникальные проблемы, с которыми сталкивается нефтегазовый сектор. В частности, команда ALP Group разработала систему для быстрого расчета себестоимости нефтепродуктов и сжиженных углеводородных газов при выбытии по методу FIFO, автоматизировала учет на безоператорных нефтебазах и АЗС, а также создала биржу и веб-маркетплейс нефтепродуктов.

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

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

Принятие решений на основе данных или как построить объективный учет на всех уровнях для принятия управленческих решений

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

Чтобы всё это работало, компании необходимо выполнить комплексную автоматизацию, начать которую стоит с систем самого низкого уровня — АСУ ТП — то есть программного комплекса, который управляет оборудованием и передает поверенные данные в корпоративную учетную систему. Здесь важно использовать то оборудование и тот софт, которые периодически проходят поверку, — это даст большую гарантию качественных данных, нежели ручной ввод кем-либо из специалистов.

Затем эти данные поднимаются на уровень оперативного учета: коммерческий учет, закупки, логистика, продажи, ценообразование, маркетинг — словом, всё, что связано с оперативной бизнес-деятельностью компании. Чтобы не допустить искажений, здесь очень важно сразу выстроить схему контроля данных. Например, чтобы плотность нефтепродуктов не выходила за пределы заданного диапазона, а температура их перевозки коррелировала с температурой окружающей среды. Если на этом этапе не будет четкой выверки данных, то ошибки непременно всплывут на следующих уровнях учета, а исправить их может оказаться долго и/или дорого.

Построив контур оперативного учета, мы переходим на контур бухгалтерского и налогового учета, где формируется отчетность по РСБУ и МСФО. Только после этого все данные передаются в систему управленческого учета.

Так устроена стандартная цепочка получения данных для анализа деятельности и формирования отчетов для собственников и регуляторов. Но даже это не высший пилотаж возможной автоматизации. Чтобы прийти к автоматизированному принятию решений, компания должна выйти на уровень систем аналитики класса process mining, которые помогают досконально оценивать эффективность всех операций бизнеса. Правда, работать эффективно такие системы будут только при условии, что все предыдущие уровни учета настроены безупречно. Зато при грамотной настройке и качественных больших данных, возможности аналитических систем безграничны. Например, на основе информации обо всех расходах компании, система может формировать цену выбытия нефтепродуктов с необходимой долей прибыли. Выполнить эту задачу на уровне систем оперативного учета невозможно, потому что в них содержится только информация о закупке и транспортировке топлива, но нет косвенных расходов, таких как недвижимые активы, обслуживание приборов и материалов, стоимость работы сотрудников, роботизация или проведение корпоративных мероприятий.

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

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

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

Подобные интеллектуальные системы решают целый ряд задач, а именно:

• мониторят состояние оборудования, место на дисках и штатное выполнение всех операций в ИТ-системах (записи объектов, проведение документов, открытие форм пользователями и прочее);

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

• отслеживают и локализуют очаги падения производительности в моменте;

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

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

• ведут журнал ошибок в режиме реального времени;

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

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

Управление изменениями в крупных корпорациях от А до Я или как не допустить эффекта домино из-за одной маленькой доработки

Учет выстроен, и всё работает как часы. А что, если мы захотим что-то улучшить? Если не подойти к доработкам с умом, то может случиться непоправимое: внеся изменения в одну систему, мы по цепочке обрушим все остальные. Чтобы этого не допустить, нужно зайти с двух сторон. С одной стороны, выстроить систему управления данными и метаданными — программный комплекс, который позволяет описывать и контролировать все данные и метаданные в каждой ИТ-системе. С другой стороны, создать отдельную службу, которая будет оперировать этими данными.

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

Брендирование нефтепродуктов как пример решения задачи в типовых конфигурациях 1С

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

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

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

• Чуть более сложная схема — завести спецификацию на брендированное топливо, то есть отдельный документ или справочник в системе, а затем формировать документ комплектации, который будет списывать остатки бензина и присадки и при этом формировать остатки брендированного топлива в нужных пропорциях. При необходимости на этом же шаге можно учесть дополнительные расходы, которые могут потребоваться на такое «виртуальное брендирование». Такая схема также поддерживается типовыми системами 1С, но нередко требует доработок для автоматизированного формирования комплектации (если компания хочет сократить объем ручного труда при оформлении выбытия).

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

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

Расчет себестоимости продукции на всей цепочке товародвижения или как мы разработали отдельный модуль расчета себестоимости «от завода до пистолета»

Один из уникальных кейсов, с которыми мы столкнулись в своей практике, — это расчет себестоимости продукции при выбытии по способу FIFO (First In, First Out — «первым пришел — первым ушел»).

Перед командой стояли такие задачи:

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

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

• организовать учет финансового результата по каждой сделке в группе компаний в аналитике заводов-производителей;

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

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

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

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

Причина в том, что при учете товара оптовики оперировали неизменным показателем массы (тоннами), а розница, традиционно, объемом (м³). Под влиянием температурных условий и технических процессов жидкость сжималась, расширялась, испарялась или оседала — и попадала в точку сбыта уже с другими показателями плотности и объема. Это приводило к недостаче (или избытку) сотен кубометров продукции.

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

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

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

Если вы ищете опытных интеграторов, которые к вам прислушаются, свяжитесь с нами: +7 (800) 555-51-51, info@alp-erp.ru

Источник статьи: https://energoneftegazhim.ru