Механизм Согласование цен

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

Итак, в разделе Администрирование/маркетинг я включаю механизм согласования цен.

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

Итак, здесь я настраиваю, по сути, веточку моего бизнес процесса, в котором я говорю, что я инициатор вот этой операции. Когда я ее инициировал, кто-то должен решить, что оно будет, или не будет. В нашем случае ситуация следующая: администратор сформировал документ Цены номенклатуры, Установка цен номенклатуры, и этот документ не будет применен, пока он не пройдет стадию согласования. Согласоваться он должен, допустим, с представителем отдела продаж. У нас может быть более сложная структура, когда мы в процедуру согласования можем установить два, три, четыре звена и так далее. И тогда они все пройдут по цепочке. Когда у нас сообщение придет первому пользователю, он посмотрит, скажет: «Да, я согласен», либо скажет: «Нет, я не согласен» и так далее, так далее. Итак, саму систему мы настроили, теперь давайте посмотрим, как это всё у нас работает. Один момент, у нас менеджер по продажам – согласующее звено. Итак, администратор у нас установил цены номенклатуры.

Допустим, с 19-го числа у меня должна действовать цена 350 гривен за штуку, я ее изменил на 8,2%, я ее пока изменю вручную. Вот, я хочу сформировать вот этот тип цены. Цена не согласована, то есть, я ее пока не могу применить, поскольку она у меня не согласована. Я ее провожу, мы видим сразу же состояние, что цена у меня ожидает согласования.

Я могу непосредственно отсюда запустить бизнес процесс. То есть, я могу сказать: «Пожалуйста, товарищи, согласуйте мне эту цену». Я инициирую процесс, говорю, поскольку я цену хочу установить с 19-го, допустим, мне ещё надо ценники распечатать так далее, поэтому я говорю: «Пожалуйста, согласуйте мне ее до 15-го» и запускаю процесс.

Что произошло? У меня система автоматически поставила первому звену согласования, у меня это менеджер по продажам, задачу на согласование данного процесса.

Давайте посмотрим, как это выглядит у нашего менеджера по продажам. Итак, у него сформировалась задача: согласовать установку цен номенклатуры, срок до 15го, запущена задача, видим текущее время.

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

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

Подумал менеджер и говорит: «Нет, давайте опускать на 5%». И пишет: «Уменьшить на 5%», и отправляет назад задачу.

Не согласована цена. Администратор, видя, что с его задачей что-то сделали, должен ознакомиться с результатами согласования.

Открывает и видит комментарий, говорит: «Хорошо».

  • Экспертное сопровождение бухгалтеров

Изменили цену, ознакомились мы с задачей.

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

То есть, все прошли, наверное, сложную задачу я взял, попробуем сейчас ее исправить. Вот, допустим, мы посмотрели, и нас теперь всё устраивает, мы говорим: «Всё, согласовано».

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

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

То есть, вот, я вижу, что у меня цены согласованы, менеджер по продажам согласовал цену тогда-то, в 11:02 14-го числа, всё нормально. То есть, если бы у меня бизнес процесс был довольно сложным, его можно, естественно, усложнить, соответственно, тогда у меня могло бы быть несколько точек маршрута. То есть, я отправил на согласование, мне вернули с замечаниями, я замечания устранил и отправил, мне опять нашли новое замечание и опять вернули, вот так эти данные у нас передаются. То есть, чем удобно? Во-первых, это всё происходит в одной системе, во-вторых, мы можем очень легко получить доступ к самому документу. То есть, мы в самой задаче, которую нам система ставит, видим, чего от нас хотят. Вот, конкретно, задача, вот документ, открывайте, смотрите, работайте, пишите комментарии. Вся цепочка прохождения у нас фиксируется, фиксируются сроки, до которых задача должна быть выполнена и фиксируется время выполнения. Еще один момент – задачи, которые у нас просрочены, то есть, не выполнены вовремя. Они у нас светятся, по-моему, другим цветом. Но сейчас у меня таких задач нет. Задачи еще не просрочены – я до 15 должен ознакомиться с результатами согласования. Если я задачу забуду выполнить, то я утром приду на работу, включу систему, и она у меня засветиться красным цветом. Вот так реализован механизм и бизнес процессов, и бизнес задач. Еще раз: задачи можно прицепить к любому объекту. Следующий момент – это можно перенаправлять задачи, то есть задача, которая поставлена вам, допустим, вот задача, поставленная менеджеру по продажам, он может сказать: нет, эта задача не мне и ее перенаправить. Опять же немножко по самому механизму постановки задач: сейчас я показал самый простой вариант постановки задач, когда мы ставим задачу конкретному пользователю, то есть, я говорю: администратор дал задание менеджеру по продажам – согласовать цены. Хорошо, но есть ситуация немножко другая: когда мы не можем знать, кто из пользователей будет выполнять эту задачу. Возьмем такой простой пример: у нас есть отдел, который принимает заявки и есть отдел продаж, который, собственно, эти заявки обрабатывает. В отделе продаж у нас может быть несколько сотрудников – 5, 10, 20 и мы не знаем, кто конкретно возьмет эту задачу. Так вот, как реализован этот механизм в системе на данный момент? Первое: механизм постановки задач такой же, но задача может ставиться, как конкретному исполнителю, так и определенной роли.

У меня есть несколько ролей, вот у меня есть определенная роль и я могу поставить задачу этой роли. Что значит роль? В роль может входить несколько пользователей: вот, допустим, несколько пользователей отдела продаж у меня будут, у них будет роль, менеджер по продажам.

Либо, когда я организую структуру - они у меня могут быть сотрудниками определенного отдела и задача ставиться целому отделу. Так вот, как быть в этом случае? В этом случае, система пришлет сообщение всем, но тот, кто задачу принимает к исполнению – он ее забирает и говорит: я забираю задачу, и у остальных эта задача снимается, то есть, он ее принимает к исполнению.

Тем самым он говорит: я с этой задачей начал работать и до окончания срока я ее обязуюсь выполнить. Дальше я могу перенаправлять, но если мы начнем анализировать, то мы будем видеть: есть заказ, он передан на обработку менеджерам по продажам и им никто не занимается, то есть, никто из менеджеров по продажам, допустим, этот заказ пока себе в работу не взял. Это не есть нормальная ситуация, мы, допустим, хотим с этим бороться, поэтому мы, допустим, внесли регламент нашего предприятия и говорим, что у нас срок реакции на заказ или на задачу, допустим, 20 минут. Мы четко видим, что задача нам поставлена в 11:02, значит, в 11:22 эта задача должна быть кем-то принята к исполнению. Иначе, грубо говоря, весь отдел может быть каким-то образом наказан. Во-первых, система эти задачи фиксирует, во-вторых, она отслеживает время, когда они поставлены в срок, до которого они должны быть выполнены и эти задачи можно ставить не только кому-то конкретно, а можно еще и забрать на себя функции контроля или возлагать их на кого-то другого. Когда ставиться задача, скажем так, согласовать цены, то тоже самое, руководство может сказать: исполнителем выступает менеджер по продажам, а контролирует его, скажем, начальник отдела маркетинга. Я не себе возвращаю задачу, а задача ставиться кому-то другому. Вот такой довольно неплохой механизм.