Комментарии 13
Интересный пост, спасибо! Выскажусь, с вашего позволения.
Бизнес — среда живая. Поэтому, бизнес-моделирование, для того, чтобы быть релевантным, не должно впадать в крайности. Пожалуй.
Ошибки есть у всех. Перегибы тоже часто бывают. Простая математика и логика помогают учитывать это.
Кстати, 8 часов реально мало кто работает. Фактически визуально эффективно расходуется от 1/4 до 1/2 рабочего времени. В остальное время надо подумать, подготовить, убрать, обсудить и т.д. :)
Бизнес — среда живая. Поэтому, бизнес-моделирование, для того, чтобы быть релевантным, не должно впадать в крайности. Пожалуй.
Ошибки есть у всех. Перегибы тоже часто бывают. Простая математика и логика помогают учитывать это.
Кстати, 8 часов реально мало кто работает. Фактически визуально эффективно расходуется от 1/4 до 1/2 рабочего времени. В остальное время надо подумать, подготовить, убрать, обсудить и т.д. :)
Это был пример того, как можно протестировать модель на адекватность. Значение макимального количества рабочего времени берется из нормативных документов, это факт. Количество персонала тоже факт из оргштатной структуры. Количество принтеров — тоже факт. Таким образом максимальную границу адекватности результатов сбора субъективных данных мы получили, увидели что она в два раза превышает возможную, значит не надо их брать в расчет, а использовать сбор данных с помощью других методов.
Предположу. Фактический показатель рабочего времени не указан в нормативных документах.
Так, один мой знакомый зампоюр, отличающийся исключительными показателями по выигранным для завода судам, большую часть рабочего дня именно ничего не делал. Слонялся, или играл в игрушки. Когда его спрашивали, почему он бездельничает, он отвечал «Думаю.» Но никому и никогда не приходила идея снижать его мотивацию или тем более увольнять — так как 2-3 суда в месяц он выигрывал.
Так, один мой знакомый зампоюр, отличающийся исключительными показателями по выигранным для завода судам, большую часть рабочего дня именно ничего не делал. Слонялся, или играл в игрушки. Когда его спрашивали, почему он бездельничает, он отвечал «Думаю.» Но никому и никогда не приходила идея снижать его мотивацию или тем более увольнять — так как 2-3 суда в месяц он выигрывал.
Еще один прием: очень часто клиенты не читают или не внимательно читают ту инфу которую им даешь, что бы это распознать ввожу в текст маркеры в виде неправильных фактов или правил. Клиент должен на них среагировать. В 90% случаев не реагирует, и когда потом отгребает от меня, то в оправдание говорит, что видел это предложение, но так доверят мне, то решил что оно правильное. После такого разговора, как правило начинают читать и думать
НЛО прилетело и опубликовало эту надпись здесь
15 сотрудников могут стоять в очереди к ксероксу по часу. Думаю никто и не подумает заняться чем-то другим вместо того, чтобы стоять в очереди.
НЛО прилетело и опубликовало эту надпись здесь
Тоже тцать проектов закрыл по бизнес процессам.
В итоге пришел к выводу что описанием процесса должно идти в след за его обкаткой, а не наоборот.
При том стандартным мнением является что нужно сначала описать процесс, а потом его автоматизировать.
Так было давно. Все это приводит к жестким провалам. Но стереотип столь велик, что деваться от него некуда.
Мы используем идеологию ACM (адаптивный кейс менеджмент). Там настроить, запустить и обкатать процесс можно быстрее чем описать его.
Мы сначала добавляем процесс, запускаем, обкатываем на реальных операциях и если видим что угадали, то далее мб описываем. И то если это реально нужно.
Бывают такие процессы, которые и описывать не нужно. Там или очень мало операций или они очень простые.
Описание как правило нужно там где все сложно, где много исполнителей и где есть текучка кадров, т.к. основная цель описания это дальнейшее обучение сотрудников. В противном случае описание процесса делается консультантом для консультанта и когда консультант уходит, то процесс ложится на полочку пыль собирать.
За годы работы на таких проектов, ни разу не видел чтобы описание процесса приводила к упрощению проекта, который доходил до результатов.
Описание процессов часто упрощает проекты, которые не доходят до результатов. Эти проекты запущены и выполняются чтобы занять людей, отмыть деньги или просто для галочки. Вот тогда описание с целью упрощения проекта очень полезно. Никто правда не может объяснить что это за упрощение и зачем оно надо. Но кого это когда смущало? )
Реальные описания процессов делаются только для целей обучения. Точка. И только если это сделать правильно, то описания процессов начинают жить и использоваться в организации, а не собирать пыль на полках. Вот только мне встречалось всего единицы из сотен организаций где это смогли сделать. А в основном проекты фейковые. Описание процессов есть, а толку нет.
В итоге пришел к выводу что описанием процесса должно идти в след за его обкаткой, а не наоборот.
При том стандартным мнением является что нужно сначала описать процесс, а потом его автоматизировать.
Так было давно. Все это приводит к жестким провалам. Но стереотип столь велик, что деваться от него некуда.
Мы используем идеологию ACM (адаптивный кейс менеджмент). Там настроить, запустить и обкатать процесс можно быстрее чем описать его.
Мы сначала добавляем процесс, запускаем, обкатываем на реальных операциях и если видим что угадали, то далее мб описываем. И то если это реально нужно.
Бывают такие процессы, которые и описывать не нужно. Там или очень мало операций или они очень простые.
Описание как правило нужно там где все сложно, где много исполнителей и где есть текучка кадров, т.к. основная цель описания это дальнейшее обучение сотрудников. В противном случае описание процесса делается консультантом для консультанта и когда консультант уходит, то процесс ложится на полочку пыль собирать.
За годы работы на таких проектов, ни разу не видел чтобы описание процесса приводила к упрощению проекта, который доходил до результатов.
Описание процессов часто упрощает проекты, которые не доходят до результатов. Эти проекты запущены и выполняются чтобы занять людей, отмыть деньги или просто для галочки. Вот тогда описание с целью упрощения проекта очень полезно. Никто правда не может объяснить что это за упрощение и зачем оно надо. Но кого это когда смущало? )
Реальные описания процессов делаются только для целей обучения. Точка. И только если это сделать правильно, то описания процессов начинают жить и использоваться в организации, а не собирать пыль на полках. Вот только мне встречалось всего единицы из сотен организаций где это смогли сделать. А в основном проекты фейковые. Описание процессов есть, а толку нет.
Ну тут «правильная» цель описания процессов — начало анализа и выявления плохих этапов. Но в нашей действительности до этого никто особенно не доходит. Считается, что описание процесса — самая что ни на есть цель аналитической деятельности (тут, конечно, я про свой опыт говорю, уверен, у всех пони резвятся на облаках).
Просто ACM — это такой Agile для процессов, поэтому он раньше дает выгоду. Но есть у меня сомнение — будут ли процессы таким образом подкрученные хоть как-то измеримы и сопоставимы?
Просто ACM — это такой Agile для процессов, поэтому он раньше дает выгоду. Но есть у меня сомнение — будут ли процессы таким образом подкрученные хоть как-то измеримы и сопоставимы?
Мой опыт показал что если мне нужно получить какие то адекватные или иные показатели по процессу, то с ACM это сделать проще.
Почему так, это отдельный вопрос, ответ на который сам по себе тянет на статью и содержит в себе кучу эмпирических понятий известных только практикам.
Это что касается измеримости. А что касается сопоставимости то тут все просто, я не знаю кто это и как оно пахнет)
Почему так, это отдельный вопрос, ответ на который сам по себе тянет на статью и содержит в себе кучу эмпирических понятий известных только практикам.
Это что касается измеримости. А что касается сопоставимости то тут все просто, я не знаю кто это и как оно пахнет)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Все врут!™ или казуистика описания бизнес-процессов