Мы — небольшая команда сотрудников центра цифрового развития «Закупки» ИТ-команды «Северстали». И хотели бы поделиться с вами, уважаемые читатели, нашим опытом автоматизации претензионного процесса в адрес поставщиков.
Претензионная работа — это не про то, чтобы наказать поставщика. Это про то, чтобы быстро решить проблему и сохранить партнёрские отношения. Правильно выстроенный процесс позволяет не доводить разногласия до судов, а находить первопричины и устранять их. К тому же, важно предоставлять своим контрагентам гибкие возможности урегулирования претензии в виде не только прямой оплаты штрафа, но и, например, скидки на последующую продукцию. В итоге все только выигрывают.
Как возникают претензии?
Чаще всего претензии появляются в ситуациях, связанных с:
поставкой товаров: несоблюдение сроков поставок или несоответствие заявленных характеристик;
оказанием услуг: некачественное исполнение услуг, нарушение сроков или норм охраны труда и промышленной безопасности.
Эти ситуации требуют оперативной реакции, ведь задержки и конфликты негативно влияют на производственные циклы и репутацию предприятия.
Кто участвует в обработке претензий?
Эффективная обработка претензий невозможна без чёткого распределения ролей и обязанностей внутри организации. Ответственность распределяется между разными отделами и специалистами:
закупочный отдел контролирует соблюдение условий контрактов;
специалисты по контролю качества проверяют продукцию на предмет соответствия стандартам;
отдел охраны труда занимается случаями, связанными с нарушениями норм безопасности;
финансисты отвечают за верность расчётов санкций и взысканий;
юристы обеспечивают юридическое сопровождение работы по претензиям.
Такая структура гарантирует максимальную эффективность процесса.
Как устроен претензионный процесс?
Работа с претензиями строится поэтапно:
Фиксация нарушений
Мы выделили два типа фиксаций: автоматизированную (применяется при нарушениях сроков поставок и услуг или из «внешних» систем) и ручную (необходима для случаев выявления ��екачественного оказания услуг или поставки материала несоответствующего качества).
Подробнее о том, на чём строится фиксация нарушений в системе.
Нарушения по просроченной дате поставки товарно-материальных ценностей (ТМЦ) формируются в автоматическом режиме. Система сравнивает плановую дату поставки из спецификации и фактическую дату поставки ТМЦ, при отклонении фактической даты от плановой автоматически фиксируется нарушение.
Нарушения по услугам формируются:
в ручном режиме. В случаях некачественного оказания услуг уполномоченный сотрудник фиксирует нарушение, описывает проблему и инициирует дальнейшие действия;
в автоматическом режиме. Система сравнивает плановую дату завершения услуги с фактической датой выполнения. При выявлении просрочки автоматически фиксируется нарушение.
Нарушения в области охраны труда и промышленной безопасности фиксируются в системе ПК КОТ (программный комплекс «Контроль охраны труда») и передаются в SAP посредством интеграции.
Нарушения поставки товара, не соответствующего по качеству или количеству, формируются вручную. При обнаружении несоответствий между фактическими характеристиками товара и требованиями спецификации ответственные сотрудники оформляют необходимую документацию, фиксируют нарушение в системе.
Анализ и принятие решений
Специалисты оценивают характер нарушения и определяют стратегию действий. Возможны следующие сценарии:
проведение переговоров и заключение соглашений о возмещении убытков;
формирование официальной претензии, в состав которой войдут соответствующие нарушения с указанием суммы неустойки для выставления требований контрагенту и обработки претензии по нужному маршруту (от создания до судебной работы, отклонения или отражения оплаты);
отказ от предъявления претензии при согласовании сторонами вопроса без судебных разбирательств.
Обработка претензии
На этом этапе претензия оформляется документально и передаётся поставщику. Процесс обычно включает согласование с руководством, подготовку юридических документов и передачу пакета документов поставщику.
Требования к автоматизированному решению
Задача команды разработчиков заключается в создании решения, которое обеспечит:
быструю обработку претензий;
гибкую настройку маршрутов обработки для каждого типа претензий;
полностью автоматизированную передачу претензий контрагентам;
подробную отчётность о ходе претензионной работы.
Как устроен претензионный процесс «под капотом»?
Когда мы рассматриваем существующие решения SAP для автоматизации работы с претензиями, первое, что приходит на ум — это сообщение по качеству (в терминологии SAP — «QM-сообщение»), которое содержит в себе базовые данные (материалы, партия, поставщик, дефекты и т. д.), даёт возможность выполнять операции (изменение вида запаса, создание логистических документов) и позволяет контролировать процесс устранения дефекта через мероприятия и статусы.
В первом приближении это решение удовлетворяет потребностям в автоматизации процесса по работе с претензиями, но, на наш взгляд, имеет ряд существенных недостатков для работы. Одним из ключевых минусов является то, что решение применимо только к материалам. Поэтому мы решили построить свой процесс на основе стандартного объекта, адаптировав его под наши реалии и сделав более «дружелюбным» и понятным.
Особенности реализации
Мы взяли за основу QM-сообщение, дополнив его набором данных, необходимым для ведения отчётности и принятия решений участниками претензионного процесса. При этом мы решили не расширять стандартную таблицу QMEL, а создали вспомогательные таблицы. Это позволило нам исключить риски возникновения проблем при добавлении новых полей, упростить поддержку и сопровождение нашего решения и решений смежных команд. Это нужно, поскольку таблица QMEL используется, например, в решениях по техническому обслуживанию и ремонту оборудования.
Два вида сообщений
Для повышения точности управления процессом мы разделили сообщения на две категории:
сообщения для анализа нарушений («допретензионные»). Эти сообщения помогают оценить ситуацию, подтвердить факт нарушения и принять предварительное решение;
сообщения для непосредственной претензионной работы. Они включают утверждённые ��арушения и предусматривают взаимодействие с поставщиком в правовом поле.
Этапы, мероприятия и статусы
При работе с нарушениями и претензиями возникла необходимость организовать чёткий порядок действий от момента выявления нарушения до полного урегулирования претензий. Традиционная система управления статусами оказалась неэффективной, поскольку смена статуса зависела исключительно от желания и полномочий пользователей, а не от текущего этапа процесса обработки сообщений.
Один из членов команды предложил применить концепцию «конечного автомата» — математической модели, позволяющей описать поведение системы с конечным числом состояний, переходящих друг в друга в зависимости от определенных условий («входных сигналов»). Эта концепция идеально подошла для нашей задачи, так как этапы обработки претензии стали интерпретироваться как отдельные «состояния», а принятые решения на предыдущих этапах — «входные сигналы».
Для описания «состояний» мы воспользовались наборами системных и пользовательских статусов. Например, после формирования претензии, в сообщении устанавливается статус, который отлеживает выполненное действие. После формирования печатных форм устанавливается новый статус, соответствующий выполненному действию — отправке пакета документов с претензией в адрес поставщика. Данные сочетания статусов и представляют собой «состояние».
Таким образом, мы смогли получать отчётность по зарегистрированным нарушениям и претензиям. Это значит, что в любой момент времени мы можем отслеживать, какая работа уже была проделана, так как этому соответствует определённый статус в соответствующем наборе статусов. А использование концепции «конечного автомата» ограничивает возможные комбинации статусов, что делает процесс управляемым и контролируемым.
Каждому «состоянию» соответствует определённая задача, которую необходимо выполнить в рамках претензионного процесса. Для этих целей мы используем стандартный объект «мероприятие». Мероприятие, так же как и «состояние», описывает текущий этап, но мероприятия могут повторяться, независимо от ранее выполненных этапов претензионного процесса. Кроме того, мероприятие имеет плановые сроки начала и завершения выполнения, ему могут быть присвоены ответственные за выполнение и своя статусная схема.
Кто отвечает за работу с нарушениями и претензиями?
Работа с нарушениями и претензиями требует чётко выстроенной схемы ответственности. Это могут быть как непосредственные исполнители (сотрудник), так и подразделения (группы сотрудников).
Исполнитель. Определяют исполнителей с помощью справочников. Здесь применяем следующий алгоритм:
1.1. по заданному набору организационных данных (закупочная организация, балансовая единица, группа закупок и дополнительные критерии) система находит сотрудника, непосредственно ответственного за закупки;
1.2. аналогичным способом используем справочник складов, который позволяет определить ответственного за управление складскими операциями.
Такой подход обеспечивает точное распределение обязанностей среди отдельных сотрудников и повышает персональную ответственность.
Подразделение. Иногда возникает ситуация, когда детальная персонализация ответственности нецелесообразна либо невозможна, например, для претензионного отдела или отдела, ответственного за отражение кредиторской задолженности. В таком случае используются сервисные подразделения. Они создаются и настраиваются в системе PFAC через специальные правила.
Пользовательские операции
В описании «конечного автомата» мы упоминали «входной сигнал», который описали как решение, принимаемое на предыдущем этапе. С точки зрения QM-сообщения этим элементом является пользовательская операция.
Стандартом предлагается использование зависимых друг от друга операций, то есть операция «B» может быть выполнена только после выполнения операции «A». Или операция «С» может быть выполнена только один раз.
Согласно нашей концепции, операция представляет из себя решение, принимаемое в текущем «состоянии». Мы отказались от зависимостей, а для отображения возможных вариантов воспользовались пользовательским расширением, скрыв операции, недоступные для текущего «состояния». Пользователь может видеть и выбрать только операции, соответствующие текущему «состоянию». Кроме того, операция является очень удобным инструментом для настроек, так как в ней можно «зашить» отдельный функциональный модуль для обработки.
Функциональные модули
Мы разделили функциональные модули на два уровня для удобства поддержки и развития системы:
Модули верхнего уровня (TOP) — соответствуют выполняемым бизнес-операциям.
Модули нижнего уровня (LOW) — выполняют однотипные базовые задачи, например:
2.1. Авторизация и проверка полномочий. Проверяется наличие достаточных прав у пользователя, инициирующего операцию.
2.2.Определение набора статусов, характерных для нового состояния.
2.3. Назначение ответственных. Автоматически выбирается исполнитель или подразделение, которое должно обработать новое мероприятие.
2.4. Определение сроков. Устанавливается планируемый срок выполнения задачи.
2.5. Динамически выводятся экраны для внесения дополнительной информации, необходимой для будущих этапов или подтверждения уже пройденных, в настраиваемый набор полей.
2.6. Другие вспомогательные функции. Выполняют мелкие, но важные задачи, необходимые для полноценного функционирования процесса.
Эти базовые функции служат своего рода строительными кирпичиками, из которых формируются модули «top-уровня».
Кроме того, осуществление смены «состояния» сопровождается уведомлением ответственного о назначении ему нового мероприятия посредством e-mail сообщения.
Отчётность
Теперь поговорим об отчётности. Так как QM-сообщение и его наполнение претерпело значительные переработки относительно стандартного решения, то нам потребовались свои отчёты, которые отвечали бы следующим требованиям:
содержат актуальную информацию о текущем «состоянии» и сопутствующих атрибутах;
позволяют менять «состояния» для нескольких QM-сообщений одновременно.
Автоматические обработки
Мы автоматизировали некоторые этапы претензионного процесса, чтобы ускорить работу и избежать человеческих ошибок. Например, ранее сотрудники вынуждены были отслеживать срок на удовлетворение требований поставщиком самостоятельно и по его истечении выполнять соответствующую бизнес-операцию вручную. Теперь система сама отслеживает сроки и выполняет необходимую операцию автоматически.
Этапы, которые мы автоматизировали с помощью этой технологии:
контроль срока ответа на претензию. Если контрагент не ответил вовремя, автоматически готовится иск в суд;
ожидание апелляции. Контроль сроков подачи апелляций контрагентом теперь полностью автоматизирован;
фиксация оплаты. Как только деньги поступают, система сразу это регистрирует и меняет статус претензии;
проведение одностороннего зачёта. Расчёты и зачёты требований теперь выполняются автоматически при выполнении заданных условий;
исполнение обязательств в другой форме. Процесс также автоматизирован для некоторых других форм закрытия требований.
Теперь давайте поговорим об особенностях каждого нашего процесса.
Претензии за поставку ТМЦ
Процесс претензий за поставку ТМЦ разбит на два направления:
А. Работа с нарушениями сроков поставки ТМЦ:
1. Фиксация проблемы.
нарушение сроков фиксируется программой автоматически на основе разницы между поставками ТМЦ и контрактными обязанностями поставщиков. При наличии разницы — создается запись расчёта суммы неустойки;
если поставка выполнена полностью, формируется нарушение и назначается ответственному лицу;
ответственным лицом обычно является специалист закупочной функции (при значительных суммах штрафов или особых обстоятельствах, например, резидентстве поставщика) либо сотрудник претензионного отдела (если нарушение очевидно и не требует дополнительного согласования).
2. Начало работы и решение.
задача специалиста закупочной функции — попытаться разрешить ситуацию до стадии официальной претензии путем переговоров с поставщиком. Если переговоры не приводят к успеху, то необходимо создание претензии;
на основании зафиксированных нарушений специалистами претензионного отдела формируется официальная претензия;
специалист претензионного отдела осуществляет оповещение поставщика о претензии: в системе формируется пакет документов с претензией и направляется поставщику (посредством электронного документооборота или по почте), после чего наступает предусмотренный законом срок ожидания реакции — оплаты или обоснованного возражения. В последнем случае проводится перерасчёт суммы претензии. Если реакция отсутствует, дело переходит в судебное производство. Отдельно отметим, что при наличии соответствующего пункта в договоре возможен автоматический односторонний зачёт.
Б. Работа с несоответствиями качества/количества поставленных ТМЦ:
1. Фиксация проблемы
дефекты выявляются и регистрируются вручную — при приёмке, на складе или во время использования;
в сложных случаях для оценки собирается комиссия.
2. Подтверждение и начало работы
технический контроль подтверждает проблему и составляет акт;
дальнейшую работу передают специалисту закупочной функции.
3. Решение проблемы
задача специалиста закупочной функции, как и при просрочке поставки, — попытаться разрешить ситуацию до стадии официальной претензии путём переговоров с поставщиком. В данном случае с поставщиком договариваются о ремонте, замене товара или другой компенсации;
если договориться не удалось: запускается стандартный претензионный процесс, как при просрочке поставки.
Претензии по услугам
Претензии по услугам классифицируются на два типа нарушений:
нарушения сроков и качества оказания услуг;
нарушения норм охраны труда и промышленной безопасности (ОТиПБ).
А. Нарушения сроков и качества выполнения работ:
Мы не стали разделять на подвиды блок, охватывающий нарушения сроков и качества выполнения работ, ввиду схожести претензионного процесса. Да, конечно, есть и особенности, но для них достаточно использовать дополнительные атрибуты в сообщениях.
1. Фиксация проблемы
нарушение сроков выполнения услуг фиксируется программой автоматически, на основе сравнения плановых сроков выполнения и фактической даты акта выполненных работ;
расчёт штрафной неустойки выполняется автоматически, в соответствии с условиями договора, внесёнными в систему;
нарушения направляется в подразделения, для которых оказываются услуги, с целью подтверждения несоответствий;
в случаях ненадлежащего качества оказанных услуг нарушения регистрируются вручную непосредственно сотрудниками подразделений и направляются в закупочное подразделение для взаимодействия с поставщиками.
2. Начало работы и решение
как и в других видах претензий, осуществляется попытка разрешить ситуацию до стадии официальной претензии путём переговоров с организациями, допустившими несоответствия;
если договориться не удалось, то нарушения объединяются в претензии и направляются в адрес организаций. И далее всё согласно текущего законодательства — получение компенсации, согласно требований по претензии, или альтернативные способы урегулирования.
Б. Нарушения ОТиПБ:
Функциональность претензий по ОТиПБ является самым молодым подблоком, реализованным в нашей компании. При его автоматизации мы учли весь опыт прошлых лет и почти исключили участие человека.
1. Фиксация проблемы
фиксация осуществляются в отдельной информационной системе ПК КОТ (которая, пожалуй, заслуживает отдельной статьи, поэтому мы не будем подробно на ней останавливаться). Посредством интеграции подтверждённые несоответствия загружаются в учётную систему SAP.
2. Начало работы и решение
системой выполняется анализ договора и поиск открытых кредиторских задолженностей перед поставщиком;
в случаях, если по договору возможно проведение зачёта в одностороннем порядке и имеется доступная сумма для покрытия штрафа, нарушение будет автоматически включено в претензию, по которой будет проведен зачёт, и от сотрудников потребуется только сформировать и направить пакет документов поставщику. Пакет документов формируется так же, в нашей системе, буквально в пару «кликов»;
если же договор не предусматривает односторонний зачёт, но, как и в первом случае, имеется кредиторская задолженность перед подрядчиком, эта сумма временно блокируется к оплате. Несоответствия объединяются в претензию, которая направляется в адрес поставщика с требованием об оплате и предложением соглашения о проведении двустороннего зачета;
в остальных случаях несоответствия объединяются в претензию и направляется требование об оплате;
по закону у контрагента есть 30 дней, чтобы выполнить наши требования. В это время они могут скорректировать кредиторскую задолженность для проведения двухстороннего зач��та, обработать несогласия с выставленными санкциями.
О результатах проделанной работы
Проект успешно достиг своей главной цели — минимизации человеческого участия в процессе претензионной работы. Теперь компания способна быстро реагировать на любые нарушения и эффективно защищать свои права и интересы.
Благодаря внедрению системы претензионной работы, удаётся:
минимизировать рабочее время сотрудников на обработку претензий;
повысить прозрачность и гибкость процессов и обеспечить единую точку сбора всей информации;
быстро и просто анализировать эффективность работы поставщиков.
