Критика классической CRM в среде предприятий участвующих в ГОЗ

Все рассказанное ранее в статье «Функционал CRM в 1С:ERP» относится к проблематике выстраивания взаимоотношений с клиентами на предприятиях, которые продают товары (в розницу и оптом) на «открытом» коммерческом рынке. Но в России, помимо коммерческих, есть значительное число предприятий (чаще всего промышленных), относящихся к государственным и полугосударственным структурам. Обычно это предприятия, связанные с выполнением государственного оборонного заказа.

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

Во-первых, предприятия, выполняющие ГОЗ зачастую имеют фиксированный круг заказчиков, перечень которых заранее известен и ограничен, новых клиентов практически не появляется. Так же, как и ассортимент продаваемой продукции – она, как и заказчики, примерно одна и та же или меняется весьма консервативно, строго вслед за пожеланиями заказчиков.

У подобных предприятий конкуренция естественным образом ограничена, подрядчики и заказчики хорошо знают друг друга и конкурентов с новыми предложениями на этом рынке не появляется. Соответственно, и вопросы, связанные с маркетингом, мало актуальны. Также фиксированный перечень заказчиков зачастую исключает потребность в поиске новых контактов, сборе дополнительной информации – всё уже известно и будет актуально долгие годы (сейчас речь не идет об экспортных контрактах, которые можно считать обычными коммерческими – их потребности полностью соответствуют классической CRM).

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

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

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

Как это выглядит на практике, что требуется предприятию из сферы ГОЗ в первую очередь? Расскажем об этом из нашего опыта решения подобных задач на предприятии, участвующим в выполнении ГОЗа – АО  «Редуктор-ПМ».

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

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

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

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

Кроме согласования сроков такое же согласование требуется с экономическим и финансовым отделом – в части согласования стоимости и графика оплаты контракта.

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

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

Графическая картинка расчета контрольной даты представлена ниже:

Рисунок 8 Сроки по запросу

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

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

После того как запрос согласован и направлен заказчику, требуется автоматическая проверка наступление контрольной даты.  У заказчика, также как и у нашего предприятия, происходят процессы согласования контракта и к моменту наступления контрольной даты клиент может быть еще не готов к заключению контракта (например, не было согласовано финансирование). В результате этого обстоятельства, у исполнителя не будет договора, что в силу требований ГОЗа делает начало работы рискованным. Поэтому, при наступлении контрольной даты, как на стороне заказчика, так и на стороне исполнителя, должна пройти проверка – исполнителю контракта следует проверить наличие договора или гарантийных писем от заказчика, а если их нет – требуется запросить подтверждение у заказчика его намерений. Если подтверждения пока нет, то плановая дата отгрузки сдвигается на более поздний срок, и в адрес заказчика направляется информация о изменении сроков и, возможно, стоимости контракта. Так чтобы исполнитель контракта не оказался виновным в его неисполнении, а заказчик понимал, что вина за перенос сроков теперь лежит на нем.

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

Пока это теоретические выкладки. Но в рамках АО «Редуктор-ПМ» все вышеизложенное было реализовано на практике: для этого нами был доработан стандартный функционал CRM 1С:ERP (на функционале лидов-сделок и воронки продаж).

Сделано это было следующим образом:

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

Бывает, что ГОЗ имеет фиксированную дату исполнения и сдвинуть ее практически невозможно. Для подобных случаев в системе предусмотрен механизм согласования, позволяющий по заданному шаблону разослать ответственным работникам предприятия (начальнику производства, начальнику ОМТС и т.п.) задачи на согласование срочного запроса. Результаты согласования с комментариями поступают к менеджеру отдела сбыта, он видит актуализированные «ускоренные» сроки, на основании которых система рассчитывает возможную дату отгрузки, которая уже может служить обоснованной причиной для изменения ожиданий клиента.

Рисунок 9 Запрос клиента (сделка)

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

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

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

Подобные же команды были созданы и для проработки финансовой стороны запроса – цены на изделие на основе РКМ, графика финансирования и т.п.

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

Как все наши разработки взаимодействуют с типовой системой и потребует ли это больших затрат на сопровождение системы?

Функционал запроса реализован на типовой сделке. Мы доработали состав реквизитов этого документа – добавили в него новые поля, связанные с продукцией, сроками и т.п. Также был создан простой механизм различных согласований, который позволит в этой части заменить 1С:Документооборот, если у предприятия нет средств или желания внедрять этот продукт.

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

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

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

Рисунок 10 Сроки производства и закупок

Что еще делает запрос-сделка, кроме расчета сроков и согласования отклонений от плановых сроков?

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

Если клиент готов к работе, сбыт запускает механизм оповещение о начале работ по контракту, он (механизм) также реализован в системе.

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

Так как, система существенно не доработана (в нее просто добавлены необходимые реквизиты, дополнительные формы, новые объекты) её обновление в этой части происходит максимально быстро (в течение 10-15 минут на нашу доработку).

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

Надеемся, что этот функционал будет востребован и на других предприятиях, работающих с ГОЗ.

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

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