Мы автоматизируем процессы, формализуем, моделируем в BPMN, раскладываем все на шаги, статусы и роли.
А теперь простой, почти бытовой кейс.
Руководителю ,,прилетает,, 30 задач, и он их распределяет по сотрудникам.
И тут вопрос: как именно он это делает?
По опыту? По ,,чутью,,? Смотрит на загрузку команды, на компетенции, на срочность и важность задач? Сравнивает их между собой?
Если копнуть глубже, становится еще интереснее.
Руководитель ведь не просто раздает задачи. Он одновременно держит в голове, кто перегружен, а кто недогружен, кто сделает быстрее, а кто качественнее, где критичны сроки, а где допустим сдвиг, какие задачи уже висят и на какой они стадии, какие могут ,,взорваться,,, если их не тронуть сейчас.
И самое важное: он смотрит не на количество задач, а на их состояние и динамику.
Потому что пять задач, которые на 90% готовы - это одна ситуация.
И те же пять задач, которые застряли на старте - совсем другая. Смотря у кого из сотрудников застряли..,
И вот вопрос:
как это описать так, чтобы это могла делать система?
Нужно формализовать критерии распределения, расставить веса что важнее: срок, сложность или исполнитель, описать модель загрузки, ввести понятие стадии задачи и даже попытаться зафиксировать такие вещи, как риск зависания.
И в этот момент становится понятно — это уже не просто процесс.
Это модель принятия решений.
И здесь возникает парадокс: самые простые управленческие действия оказываются самыми сложными для формализации, эти процессы не регламентируют, они только в голове руководителя.
И пока это так, автоматизация всегда будет лишь частичной
А теперь простой, почти бытовой кейс.
Руководителю ,,прилетает,, 30 задач, и он их распределяет по сотрудникам.
И тут вопрос: как именно он это делает?
По опыту? По ,,чутью,,? Смотрит на загрузку команды, на компетенции, на срочность и важность задач? Сравнивает их между собой?
Если копнуть глубже, становится еще интереснее.
Руководитель ведь не просто раздает задачи. Он одновременно держит в голове, кто перегружен, а кто недогружен, кто сделает быстрее, а кто качественнее, где критичны сроки, а где допустим сдвиг, какие задачи уже висят и на какой они стадии, какие могут ,,взорваться,,, если их не тронуть сейчас.
И самое важное: он смотрит не на количество задач, а на их состояние и динамику.
Потому что пять задач, которые на 90% готовы - это одна ситуация.
И те же пять задач, которые застряли на старте - совсем другая. Смотря у кого из сотрудников застряли..,
И вот вопрос:
как это описать так, чтобы это могла делать система?
Нужно формализовать критерии распределения, расставить веса что важнее: срок, сложность или исполнитель, описать модель загрузки, ввести понятие стадии задачи и даже попытаться зафиксировать такие вещи, как риск зависания.
И в этот момент становится понятно — это уже не просто процесс.
Это модель принятия решений.
И здесь возникает парадокс: самые простые управленческие действия оказываются самыми сложными для формализации, эти процессы не регламентируют, они только в голове руководителя.
И пока это так, автоматизация всегда будет лишь частичной