Определение существующих или новых бизнес-процессов это та еще наука, скажу я вам 🙂

Если хочется просто определить процесс, а еще и нарисовать его, то тут ничего сложного. Определяешь и рисуешь. Толку от этого нет, но кого это и когда останавливало? 🙂

А вот если хочешь определить правильно и с толком, то тут не просто.

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

Приведу пример как это случается 🙂

Представим студию. Она работает уже некоторое время, Заказы растут, все хорошо.

Есть 2 ключевых процесса:

1. Заказы — разовые и как правило крупные работы

2. Сопровождение — мелкие заявки по обслуживанию существующих объектов (в нашем случае сайтов)

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

И вот пишет клиент, что мол у него возникла такая-то ошибка.

К какому бизнес-процессу это отнести?

К сопровождению?

Да, можно, но в этом случае получаем ряд мало приятных следствия:

1. Сотрудник, который выполнит эту заявку, получит вознаграждение, а предприятие потеряет прибыль.

2. Сотрудник, который допустил ошибку, не поймет проблемы. Он получит заявку, за которую получит деньги. А где справедливость? Это же ошибка. Ее нужно исправить бесплатно. Как для заказчика, так и для предприятия. Бывают тут исключения, но это исключения и про них отдельная история.

3. Если это рабочий бизнес-процесс, а не болванка, то на основе этих данных рассчитываются показатели и вознаграждение. Регистрировать тут операцию не из поддержки — это загрязнение показателей и ошибки в расчете вознаграждений.

Регистрировать в Заказы?

1. Ну это же не Заказ. За него никто и ничего не заплатит.

2. Писать как комментарий к текущему Заказу? Да, можно, но только если Заказ еще  свежий и срок позволяет. А если Заказ давно закрыт и срок уже вышел? Как вы проконтролируете исполнение гарантии? Никак.

Хотите еще проблем?

Попробуйте потом получить информацию по следующим вопросам:

1. Сколько было гарантийных случаев за последний квартал?

2. Число гарантийных случаев увеличивается или уменьшается? Это один из показателей качества продукции.

3. Есть ли случае с одинаковыми причинами? Чтобы принять меры для правильной корректировки производственных процессов и технологии.

И вот все эти факты говорят об одном и простом решении. Пора определять новый процесс и называть его «Гарантии». Ценный конечный продукт этого процесса очень прост — «Гарантии» 🙂

Да, это не основной продукт. За него нам никто денег не заплатит. Но это один из важнейших подпродуктов.

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

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

Разобрались? И как вы думаете, сколько времени уйдет на настройку этого процесса, если мы имеем дело с ACM? 🙂

Пример настройки процесса в ACMS CasePress

Да очень просто — 5 минут.

1. Идем в категории дел и добавляем новую категорию «Гарантии», делаем описание:

2. Если у процесса есть какие-то важные и измеряемые данные, то идем в произвольные поля и добавляем:

3. Если нужно, то делаем инструкцию:

4. Готово!

Пользуемся:

Что в результате?

А по итогам получаем:

  1. Предприятие получает учет всех гарантийных случаев и может анализировать
  2. Гарантийные операции не путаются в основных процессах и не демотивируют сотрудников
  3. Клиент получает уверенность в гарантиях и в том что про него не забудут