И этот стиль управления зачастую оправдывает себя при зарождении и становлении бизнеса, так как позволяет реагировать на различные ситуации более гибко. При этом он требует от руководителя знания эффективных методов управления, умения прогнозировать последствия применения разных методов управления, умения правильно распознать сложившуюся ситуацию, навыков выбора оптимального для данной ситуации решения. То есть накладывает на квалификацию и мотивацию руководителя довольно сильные ограничения.
Но с ростом компании, с появлением большого числа наемных сотрудников, в том числе на руководящих должностях, в определенный момент наступает такая ситуация, когда управлять "как прежде" становится невозможно. Новые руководители и работники не всегда имеют достаточную квалификацию и/или мотивацию, чтобы эффективно, творчески, ответственно и самостоятельно действовать в меняющейся ситуации. Руководители зачастую оказываются завалены лавиной мелких вопросов, которые решались через них, когда компания была маленькой, но компания то растет. Отсутствие системы в работе компании приводит к ошибкам в управлении. Как следствие рентабельность бизнеса может постепенно начать снижаться.
И в этой ситуации надо что-то менять. Один из вариантов - это внедрение в компании регулярного менеджмента. То есть такого менеджмента, при котором процессы внутри компании регулируются (регламентируются) строгими написанными правилами.
При применении ситуационного менеджмента сотрудник может действовать по разному в одинаковых ситуациях, принимая решение на основании своего опыта, интуиции, настроения, фазы луны и т.п. При внедрении же регулярного менеджмента действия сотрудника будут регламентированы, сотрудник всегда будет действовать и принимать решения в соответствии с установленными руководством правилами и ценностями. Имея строгие написанные правила сотрудник всегда знает, что делать в той или иной ситуации и как это делать самостоятельно, не отвлекая руководство.
Как составить оптимальные для компании правила и регламенты - это вопрос, выходящий за рамки данного текста. А вот инструментом для автоматизации создания, исполнения и контроля исполнения правил может стать модуль Бизнес-процессов.
Модуль Бизнес-процессов позволяет визуально формировать процессы, правила и наборы правил, а так же исполнять их и контролировать их выполнение. При этом выполнение процесса всегда идет по заранее утвержденным регламентам так, что сотрудник не может ошибиться, обойти или игнорировать какие-либо действия. У сотрудника, в том числе нового, не возникает вопроса, как делать. Потому что ответ на него простой: запустить бизнес-процесс и следовать дальнейшим инструкциям. У руководителя же есть инструмент, с помощью которого он может оперативно видеть, как движутся процессы и где они тормозятся. Модуль Бизнес-процессов позволяет работать практически с любым видом информации на сайте. Конкретные процессы могут запускаться как автоматически при возникновении какого-то события, так и вручную конкретным сотрудником.
Таким образом модуль Бизнес-процессов поддерживает основные принципы регулярного менеджмента: он позволяет задать набор правил и регламентов, при этом правила задаются в письменном виде, а ключевые моменты исполнения правил подконтрольны руководству.
Я так понял, на нескольких визуальных плюхах типа отображения в ЖЛ и непонятно зачем продублированных старых "БП организации" в новые "Процессы" на списках, разработка снова уйдёт в кому?
Потом будет пост про то, что значение параметра действия может содержать произвольное количество вычисляемых частей.
Далее будет пост про REST и пользовательские действия на Битрикс24.
Ну и так далее....
А ведь прошло уже сколько, почти 6 лет?
Сочувствую, в общем, ведь задумка и движок, в сущности, весьма хороши, но видимо пошли мимо планов. И чёрт знает, что было первым, курица или яйцо? Т.е. не взлетели, потому что были недоработаны или недоработаны, потому что не взлетели? Замкнутый круг.
Значит работа над модулем пока идёт, это хорошо.
Пока не забыл из недавнего:
В компоненте bizproc.wizards исправьте кеширование настроек из DESCRIPTION инфоблока, оно работает корректно только для одного типа ИБ, при попытке использовать компоненты для разных типов ИБ они затирают кэш друг у друга.
Я сделал так:
Так что насчёт задания на отдел?
Таким образом становится возможным поставить задание на отдел - участниками его станут сотрудники отдела.
Это реально будет задание на отдел и в таблице b_task_user будет что-то типа идентификатора подразделения "D112", как и в расширенной системе прав?
Или это будут обычное задание с персонификацией на каждого юзера отдела, типа 10 записей user_666, user_777 итп по количеству сотрудников отдела? Тогда неинтересно, так как не позволит реализовать интересные сценарии.
Т.е., к примеру, назначаем задание на руководителя подразделения и даже если он сменился в то время, когда задание уже создано, то новый руководитель всё равно смог бы его выполнить.
Т.е. будет ли это нормальное использование CAccess с поддержкой всех провайдеров (в том числе, которых я сам добавил)?