Организация управления способы передачи

Принцип делегирования полномочий

Больше материалов по теме «Ведение бизнеса» вы можете получить в системе КонсультантПлюс .

Делегирование – это передача определенных задач от сотрудника сотруднику. Это неотъемлемая часть деятельности любой компании. Метод делегирования используется в любом коллективе, даже если сам этот термин не используется. Однако эффективность передачи полномочий зависит от правильности проведения этого мероприятия.

Вопрос: Когда возникает право подписи документов ООО у управляющего — индивидуального предпринимателя, которому переданы полномочия единоличного исполнительного органа: после принятия решения общим собранием участников о передаче ему полномочий или после внесения соответствующих изменений в ЕГРЮЛ?
Посмотреть ответ

Понятие делегирования

Делегирование – это мероприятие по передачи функций от управляющего лица другим работникам. Руководитель ставит перед сотрудником определенные задачи, наделяет его полномочиями для их решения. Самый распространенный пример делегирования – работа по должностной инструкции. Принцип передачи полномочий позволяет руководителю избавиться от самой рутинной работы и заняться только решением приоритетных задач. Если в малой компании управленец еще может справляться со всеми своими функциями самостоятельно, то на большом предприятии это – невыполнимая задача.

Цели делегирования

Такой инструмент, как делегирование, используется для следующих целей:

• Снижение нагрузки на руководящий состав.
• Увеличение эффективности работы каждого звена.
• Повышение заинтересованности сотрудников в труде.

Как составить договор о передаче полномочий единоличного исполнительного органа АО управляющему (управляющей организации)?

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

Принципы эффективного делегирования

Делегирование осуществляется в соответствии с рядом принципов. Если передача полномочий выполняется правильно, это увеличивает эффективность работы компании на 30-40%. Рассмотрим базовые принципы делегирования:

1. Единоначалие. Делегировать задачи может только непосредственный руководитель сотрудника. Над каждым работником может стоить только один менеджер. Руководитель высшего звена не может делегировать задачи менеджерам низшего звена. Задачи в данном случае передаются руководителям среднего звена.
2. Ограничение. При использовании инструмента принципиальна правильная организация вертикали управления. За каждым управленцем закрепляется фиксированное число подчиненных. Руководитель не может передавать свои функции не своим подчиненным.
3. Соблюдение прав и обязанностей. Сотрудникам запрещается передавать функции, которые не соответствуют их должностной инструкции.
4. Закрепление ответственности. Если руководитель передает определенную задачу своему подчиненному, это не снимает с него ответственности за ее невыполнение.
5. Передача ответственности. Если управленец передает сотруднику определенную задачу, он должен быть уверен, что она будет выполнена.
6. Отчетность. Все нюансы выполнения задач, в том числе нарушение графика и прочее, должны фиксироваться в отчетах.

Соблюдение перечисленных принципов позволяет избежать замедление работы на предприятии.

Разновидности полномочий

При использовании инструмента нужно понять особенности полномочий, которые передаются. Под полномочиями понимаются ресурсы для исполнения поставленной задачи. Рассмотрим основные формы полномочий:

• Линейные. В этом случае действует вертикальная система власти. То есть полномочия передаются от руководителей высшего звена руководителям среднего звена, от управленцев среднего звена управленцам низшего звена.
• Штабные. Полномочия передаются вне вертикальной системы.

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

Базовые правила передачи полномочий

Делегирование осуществляется в соответствии с правилами, которые были сформированы опытным путем:

1. Делегирование и жесткая централизация противоречат друг другу. Имеет смысл передавать важные полномочия руководителям среднего и низшего звена.
2. Основная цель делегирования – обеспечение развития предприятия.
3. При передаче полномочий нужно принимать во внимание занятость сотрудника. Если работник сильно занят, не стоит поручать ему дополнительные обязанности.
4. При делегировании нужно всегда предусматривать риск того, что сотрудник не справится с задачей. Учет риска позволит его предотвратить. К примеру, можно задавать предварительные сроки, чтобы оставалось время до основного срока.
5. Руководитель должен брать на себя ответственность за ошибки, допущенные сотрудником, которому передана задача.

К СВЕДЕНИЮ! Большинство руководителей опасаются делегирования из-за страха того, что сотрудник не справится с задачей. Поэтому именно управленец должен «думать» за работника, предотвращать риск провала проекта. Наиболее простой инструмент – контроль выполнения задачи на каждом этапе ее исполнения.

Что не стоит доверять своим подчиненным?

При делегировании наблюдается две ошибки: страх передачи полномочий сотрудникам или неограниченное делегирование. Не все задачи можно и нужно передавать. Неправильное исполнение ключевых задач может привести к снижению эффективности предприятия. Ошибки в части работы могут быть действительно фатальными. Рассмотрим задачи, которые нежелательно делегировать:

• Разработка целей деятельности предприятия.
• Принятие решений, которые меняют политику компании.
• Контроль над результатами деятельности.
• Задачи высокой важности, которые сопряжены с большим риском.
• Срочные задачи, для контроля над результатами которых нет времени.
• Передача полномочий.

Сотрудникам передаются задачи с поставленными сроками и инструкциями к выполнению. Работникам передается только то, что возможно проконтролировать. Это поможет снизить риски, сопряженные с делегированием. В обратном случае могут возникнуть проблемы.

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

Не рекомендуется передавать те задания, которые должен выполнять непосредственно сам руководитель. Существует работа, которая предполагает высочайший уровень знаний и опыта. К примеру, это следующие задачи:

• Передача полномочий руководителя.
• Создание правильной рабочей атмосферы.
• Контроль деятельности сотрудников.
• Анализ поступающей информации.
• Решения, касающиеся развития предприятия.

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

Источник

Порядок передачи технической документации

Порядок уведомления о смене способа управления МКД

По истечении срока договора управления МКД вероятна ситуация, при которой одна из сторон не хочет продолжать работать с другой стороной или принято решение о смене способа управления домом.
В договоре управления должно быть указано, за какой минимальный срок до конца действия договора одна из сторон должна уведомить о том, что не будет пролонгировать договор. Этот период нужен, чтобы завершить все работы, которые начаты. На само уведомление даётся 5 рабочих дней. И только после этого срока начинается отсчёт минимального периода.
Уведомление также должно быть направлено в орган исполнительной власти субъекта РФ, который уполномочен на осуществление регионального жилищного контроля, и орган ГЖН.
Порядок уведомления регламентирован п. 18 ПП РФ от 15.05.2013 № 416 .
В уведомлении обязательно должно быть наименование новой организации, которая выбрана собственниками для управления домом, либо сведения о том, что будет организовано ТСЖ, должен быть указан адрес многоквартирного дома. Если дом находится на непосредственном управлении – сведения об одном из собственников. И обязательно должна прилагаться копия всего протокола – не часть его, не выписка, а всё вместе: вводная часть, основная часть, приложения. Это делается, чтобы принимающая сторона могла удостовериться, что решение было принято легитимно, что не было неточных формулировок вопросов. Если это требование не выполняется, то формально такие документы старая управляющая организация может не принять.
Такое уведомление может быть направлено через ГИС ЖКХ ( ПП РФ от 27.03.2018 № 331 ).

Порядок передачи технической документации

Порядок передачи технической документации регламентирован п. 19 ПП РФ от 15.05.2013 № 416 .
В нём сказано, что управляющая организация или ТСЖ, получив уведомление, обязана передать, во-первых, техническую документацию многоквартирного дома и иные документы, во-вторых, информацию о собственниках и нанимателях помещений в многоквартирном доме, а также о лицах, использующих общее имущество в многоквартирном доме на основании договоров по акту приёма-передачи. Акт должен содержать сведения о дате и месте его составления, а также перечень передаваемых документов. Если каких-то документов не хватает или у принимающей стороны есть претензии по качественному и количественному составу технической документации, это тоже необходимо отразить в акте приёма-передачи ( п. 23 «Правил осуществления деятельности по управлению многоквартирными домами», утверждённых ПП РФ от 15.05.2013 № 416 ).
Копия такого акта должна быть направлена в в орган ГЖН (орган муниципального жилищного контроля) в течение 3 дней со дня его подписания передающей и принимающей сторонами ( п. 23 ПП РФ от 15.05.2013 № 416 ).
Для передачи документов отводится срок в 3 рабочих дня с момента прекращения договора управления ( п. 10 ст. 162 ЖК РФ ). УО должна передать не только техническую документацию, но и ключи от помещений, которые входят в состав общего имущества собственников помещений в МКД, электронные коды доступа к оборудованию и все технические средства и оборудование, необходимые для эксплуатации МКД и управления им.
Необходимо уведомить о дате, времени и месте передачи технической документации и иных связанных с управлением этим домом документов организации, выбранной собственниками помещений в МКД для управления этим домом ( п. 22 ПП РФ от 15.05.2013 № 416 ).
В случае, если лицензия аннулирована или конкретный дом исключён из реестра лицензий, то передать техническую документацию нужно в течение 2 рабочих дней с того момента, когда:

• домом начала управлять другая УО, выбранная общим собранием собственников или отобранная по результатам открытого конкурса;
• возникают обязательства по ДУ многоквартирным домом, заключенному управляющей организацией с ТСЖ, ЖК или иным специализированным потребительским кооперативом;
• дом переходит на непосредственное управление;
• был зарегистрирован ТСЖ, ЖК или ЖСК ( ч. 1 ст. 200 ЖК РФ ).

Документы, которые будут переданы должны содержать актуальную информацию о составе и состоянии общего имущества.

Если отсутствует один или несколько документов, которые входят в состав технической документации, ранее управлявшая организация должна принять меры, чтобы их восстановить. Для этого выделяется три месяца со дня получения уведомления о смене способа управления. Такие документы также передаются по акту приёма-передачи ( п. 21 ПП РФ от 15.05.2013 № 416 ).

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

В уведомлении указывается место и дата передачи документации (но не ранее чем через 7 дней со дня отправки сообщения). Это делается для того, чтобы новая управляющая организация успела получить уведомление и подготовиться к приёму документации.

Чаще всего документы в таком случае передаются через Почту России, иногда с курьером или лично.

Процесс приёмки документов занимает какое-то время, так как нужно тщательно проверить их наличие, сохранность, актуальность и т.д.

На передачу документации даётся 30 календарных дней.

Если новая управляющая организация считает, что какие-то сведения в переданных документах неактуальны или чего-то не хватает, она указывает это в протоколе приёма-передачи.

Копия составленного акта должна в течение 3 дней со дня подписания его сторонами быть направлена в орган ГЖН.

Что касается инструкции, принятой от застройщика, то её подписывает тот, кто инструкцию передаёт и принимает (принимать может собственник или юридическое лицо), с указанием реквизитов обеих сторон или паспортных данных, если принимал собственник.

Источник

Способы передачи управления между программными объектами

Программные объекты — это обыкновенные классы из ООП. Под взаимодействием программных объектов я буду подразумевать передачу управления из одного класса в другой.
Это можно сделать двумя способами. Далее я буду называть их: объектный и событийный. Названия взяты из объектно-событийной парадигмы, подразумевающей наличие объектов, запускающих и обрабатывающих какие-то события. Но в моем случае, смысл другой. Так же, чтобы не путаться, назовем первый класс, из которого управления передается управляющим, второй класс, принимающий управление, соответственно, исполнителем.

Так как я привык работать с языком C# и .NET Framework, то в примерах и объяснениях я буду использовать именно их. Сразу стоит сказать, что в C# механизм событий реализован через делегаты — указатели на метод с заранее оговоренным интерфейсом. Для этих же целей подойдут паттерн Command или Observer. Несмотря на отличия в реализации, они равны по смыслу. Оба выполняют одну задачу — оповещают о событии неизвестного подписчика или подписчиков.
Я рассмотрю ситуацию, когда только один из объектов знает о другом. Еще возможны варианты — оба знают друг о друге (сильная связанность классов), или никто не знает ни о ком (универсальность, применение паттерна Facade и др).

Описание

Объектный способ означает, что один класс (исполнитель) предоставляет наружу через свой интерфейс какой-то метод. Второй (управляющий), имея ссылку на экземпляр исполнителя, может вызывать этот метод. При этом происходит передача управления из первого объекта во второй. Вот пример на языке C# (владеющие С++, Java, думаю, тоже поймут):

//исполнитель
class Worker <
public void doWork() <
//.
>
>

//управляющий
class Boss <
Worker worker1 = new Worker();
Worker worker2 = new Worker();

public void startProject() <
worker1.doWork();
worker2.doWork();
>
>
Как видно, класс Worker ничего не знает о том, кто заставил его работать, кому он принадлежит. С другой стороны, Boss прекрасно представляет себе, что за рабочие у него в подчинении, сколько их и какие работы они могут выполнять. Резюмируя: класс-управляющий (Boss) знает интерфейс класса-исполнителя (Worker), но не наоборот. Управляющий при этом должен знать количество исполнителей.

Событийный способ передачи управления работает немного по-другому. Один класс через свой интерфейс объявляет о том, что он может инициировать какие-то события. Другой класс, зная об этом, может на эти события подписаться и обрабатывать их в случае их возникновения.

//исполнитель
class Worker <
public Worker(Boss boss) <
boss.projectStarted += new EventHandler(doWork);
>

private void doWork(object sender, EventArgs e) <
//.
>
>

//управляющий
class Boss <
public event EventHandler projectStarted;

public void startProject() <
if (projectStarted != null)
projectStarted.Invoke(this, new EventArgs());
>
>

Теперь же класс Boss ничего не знает о том, кто будет исполнять его команды, он просто объявляет событие “projectStarted”. Те же, кто хочет выполнить свою работу (класс Worker), совершенно точно знают, на кого они работают. Конкретный экземпляр Worker будет исполнять свою работу только при команде конкретного экземпляра Boss. В противоположность объектному подходу, исполнитель знает интерфейс управляющего, а управляющий ничего не знает об исполнителях и их количестве.

Применение

Проблема применения соответствующего подхода встала при реализации Model-View-Controller. Управление из контроллера передается в представление и мне нужно было решить, кто о ком должен знать: Controller о View или View о Controller?
Для начала посмотрим на то, как это реализовано у других. Возьмем какой-нибудь UI Control из библиотеки WinForms (да простят меня приверженцы других UI-фреймворков), например, Button.
Первое, что приходит в голову, когда мы думаем о кнопках — это событие Click(). В подавляющем большинстве случаев именно для обработки кликов мы их и используем. В событийном подходе события инициируются управляющим. Значит, кнопка из WinForms, когда ей нужно передать управление, является управляющим. Теперь взглянем на ее методы, например свойство Title. Оно отвечает за надпись, которую мы видим на кнопке во время работы приложения. Кнопка предоставляет методы для работы с собой через свой интерфейс и, следовательно, играет роль исполнителя. Как же так, кнопка и исполнитель и управляющий? Почему бы и нет? К тому же кнопка даже называется соответственно — UI Control. С одной стороны она UI, т.е. представление-исполнитель, с другой, она Contol, т.е. контроллер-управляющий.
При проектировании класса кнопки у нас есть одна проблема — мы не знаем, куда кнопка может передавать управление и откуда она его может получать. Но поведение реализовать нужно. Позволю себе сформулировать очевидный вывод, который тем не менее, позволяет лучше понять природу дизайна системы. Передавая управление в неизвестность, мы используем событийный механизм, получая управление из неизвестности мы используем механизм объектный.
Картинка для лучшего восприятия:

Но это очевидность касается только “неизвестности”. А что же делать, если мы проектируем обе части и у нас нет неизвестности? Надо придумать себе неизвестность. Но какой подход выбрать? Я пришел к выводу, что любой. Все зависит от того, откуда мы начинаем проектировать дизайн, что для нас первично.
Вернемся к разговору про View и Controller. Например, мы пишем систему вывода статистической информации на экран в виде графиков. Именно задача рисования красивых графиков первична — т.е. первичен исполнитель. Далее представляем, что сама статистика для нас не важна (хотя, на самом деле это может быть совершенно не так) и представляем, что управление передается из неизвестности. Следовательно, применяем объектный подход — описываем для View методы рисования графиков, передаем ссылку на View в Controller, и из контроллера в нужных местах производим вызовы методов.
Другоая ситуация — нам важна статистика (управляющий), а как она будет представлена, уже вторично. Теперь для нас неизвестность — это то, как будет статистика отображаться. Применяем событийный подход. Описываем события и делаем их инициацию в нужных местах. Теперь для нас не важно, кто и как их обработает. Модуль рисования графиков при этом сам подписывается на нужные события.
В первом случае удобнее вызывать рисование графиков для разных видов информации, например, не только статистику, но и оперативные данные. Т.е. использование разных контроллеров для одного представления не вызывает трудностей. Во втором же наоборот, мы можем нашу статистику рисовать (причем одновременно) и в виде красивых графиков, и в виде облака значений и любыми другими способами. Другими словами, для одного контроллера легко задать несколько представлений.

Источник