До сих пор на компьютерах существует такое понятие как дефрагментация данных на диске. Это позволяет оптимизировать скорость выполнения операций в процессах компьютеров. Не знаю на сколько это актуально для современных SSD-накопителей, но для HDD точно.

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

Введение

Само по себе разделение труда — хорошо. Если следовать теории Адама Смита и его пример с производством булавок.

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

Частично эта идея была отражена в книге «Реинжиниринг корпорации. Манифест революции в бизнесе. (Майкл Хаммер, Джеймс Чампи)». Речь шла о том как избыточное разделение труда приводилось к колоссальному росту числа сотрудников:

В начале 80-х годов, когда американская автомобильная промышленность находилась в депрессии, руководство компании Ford решило среди других реформировать отдел кредиторской задолженности в поисках возможностей для сокращения издержек. Кредиторской задолженностью только в Северной Америке занимались более 500 человек. Руководство полагало, что путем рационализации процессов и установки новых компьютерных систем можно будет снизить число сотрудников примерно на 20%.
Энтузиазм прошел, как только специалисты Ford проанализировали работу компании Mazda. В то время как Ford пытался уменьшить численность сотрудников до 400, отдел кредиторской задолженности в Mazda состоял из пяти человек. Разница вцифрах была потрясающей. Даже принимая во внимание меньший размер Mazda, выходило, что отдел кредиторской задолженности в Ford примерно в пять раз больше, чем нужно. Специалисты Ford понимали, что дело тут не в производственной гимнастике, не в пении гимнакомпании и не в низких учетных ставках в Японии.

Ну это все теория 🙂

Две истории

История №1.

Внедрили BPM и WorkFlow в процессе подготовки НПА в муниципальной администрации, процесс размазали по куче постов, в теории это все выглядело отлично, но вот на практике начались беды. И то что BPM-схема только в теории проходила так как надо, а в реальности все было слегка не так и в итоге документы все равно ходили ногами и руками сотрудников. Но это мелочи. Вся суть была в том что WorkFlow размазал ответственность сотрудников. У кого сейчас задача, тот и отвечает. Соответственно концов не сыскать и у тотальной задержки сроков подготовки НПА всегда находились объективные причины.

История №2.

Развивали в свое время практику BPM в одной консалтинговой компании. Подобрал команду специалистов. Обучил, натренировал. Запустили проект в одной Газпромовской дочке. Пока проект вели ребята из моей команды, проект развивался, процессы запускались. Но затем команды не стало. На замену набрали новичков и дали им проект по оптимизации договорного процесса. Что делают люди без знаний? Они начинают ИБД.  В итоге разрисовали схему бизнес-процесса на кучу постов, запихнули в схему все что можно и нельзя. В итоге только на описание процесса потратили 1,5 года. Надо ли говорить что та схема, которую реализовали не может быть никак автоматизирована? Она и не была автоматизирована. Проект до сих пор на пробуксовке.

В чем причина?

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

Как это все решается в ACM-системах? Очень просто 🙂

1. Нет схем — сложно устроить ИБД.

2. Есть точный ответственный за результат по любому кейсу. Будь то НПА или Договор.

3. Набор кейсов в одной категории позволяет ооочень просто и быстро получить KPI по итогам месяца. Спорить с KPI мало кто отваживается. Сам факт наличия KPI творит чудеса и начинает оптимизировать процесс. Главное что KPI тут получаем почти сразу.

4. Есть чек-лист тех условий, которые должны быть выполнены. Ответственный проставляет чек лист по ключевым условиям. Проставил — можешь закрывать. Очень простая идея, которая легко внедряется.

Где здесь дефрагментация?

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

Это ведет к 2-м эффектам:

1. люди начинают думать и стараются не отвлекать других сотрудников

2. если требуется привлечь сотрудника, его просто подключают внутрь кейса и он видит всю историю и подключается к решению

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

Эта идея была апробирована в организациях до 1000 сотрудников.

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

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