Статьи > Статьи по теме "Организационное проектирование, бизнес-процессы, реструктуризация, регламентация" > Разработка регламента: кто и как этим должен заниматься
rik-company.ru
ЭТО МОЖЕТ БЫТЬ ИНТЕРЕСНО
Казалось бы, идея регламентации деятельности компании является очень логичной и должна повысить эффективность работы компании. Но почему-то на практике это мало кому удается сделать.
Мне известно очень большое количество попыток регламентировать деятельности компании, которые, по сути, ничем хорошим не закончились.
Почему же большинству компаний не удается создать эффективную машину по зарабатыванию денег за счет регламентации всех бизнес-процессов и проектов?
Безусловно, в каждом конкретном случае на разработку регламентов могут негативно влиять сразу несколько факторов. Тем не менее, на мой взгляд, есть одна причина, которая с вероятностью близкой к 100% хоронит идею регламентации.
Итак, одна из основных проблем, из-за которой регламенты в компании не работают, заключается в самой организации деятельности по их разработке.
Самый распространенный подход к разработке регламентов заключается в том, чтобы поручить данную работу одному (или нескольким, в зависимости от объема) человеку. Причем нередко этим занимается внешний специалист (например, консультант или группа консультантов).
В подавляющем большинстве случаев это приводит к возникновению огромного количества всевозможных регламентов (положений, инструкций и т.д.), которые на практике не используются.
Кстати, раньше все эти регламенты разрабатывались вручную, что, конечно же, занимало много времени, особенно если нужно было вносить какие-то изменения. Сейчас есть много специализированных компьютерных программ, с помощью которых можно разрабатывать регламенты.
При этом регламенты могут формироваться и в текстовом и в графическом виде. В общем, сейчас очень много различных "рисовалок", используя которые можно разрабатывать талмуды за сравнительно небольшое время. "Рисовалок" много, а толку мало.
Благодаря этим программам, разработка регламентов из сложной содержательной задачи превратилась в чисто техническую. Во многих компаниях считают, что им достаточно приобрести одну из таких программ, нанять сотрудника (или пригласить консультанта), который нарисует им все необходимые регламенты.
Кстати, в большинстве компаний так серьезно относятся к выбору названия должности такого сотрудника, как будто от этого что-то зависит.
Как их только не называют. Специалист по разработке регламентов, специалист по бизнес-инжинирингу, бизнес-аналитик и т.д.
Иногда создают целые отделы или группы. Например, отдел/группа корпоративной регламентации или отдел/группа бизнес-инжиниринга или бизнес-аналитиков.
На мой взгляд, подобная централизация, а затем и локализация функции регламентации и приводит к тому, что компания не получает желаемого результата и созданный для разработки регламентов отдел (группа или сотрудник) расформировывается.
Если в компании, скажем так, не очень следят за затратами и не думают о повышении эффективности работы, то такой отдел/группа может просуществовать не один год. Этот отдел и дальше будет продолжать поддерживать в "актуальном" состоянии все раннее разработанные регламенты, а также заниматься созданием новых, но все это не будет иметь никакого отношения к реальной практической деятельности предприятия.
Этот отдел будет, как говорится, вариться в собственном соку. Если в один день уволить всех сотрудников данного отдела, то этого никто и не заметит. Может быть кроме тех, с кем сотрудники этого отдела чаи гоняли на работе.
Противоположностью такого централизованного и локального подхода к разработке регламентов является децентрализованный подход, когда разработкой регламентов занимаются все подразделения. То есть каждое подразделение полностью автономно разрабатывает для себя регламенты.
Основные проблемы такой децентрализованной стратегии разработки регламентов заключаются в том, что нельзя будет нормально прописать взаимодействие подразделений при выполнении различных функций, а также в том, что каждое подразделение может использовать свои форматы описания регламентов.
Таким образом, действительно эффективным подходом к разработке регламентов является смешанный вариант.
Он основывается на следующих принципах: в разработке регламентов обязательно должны принимать участие те, кто потом будет их исполнять (или контролировать выполнение);
координация и контроль разработки регламентов;
использование единых стандартов описания регламентов.
Безусловно, должна быть какая-то координация и контроль разработки регламентов. Кроме того, нужно разработать и утвердить единые стандарты описания регламентируемых объектов компании.
Возникает вопрос: кто же должен заниматься разработкой единых стандартов, координацией и контролем разработки регламентов?
Если компания небольшая, то данные функции может выполнять сам директор (возможно, привлекая внешних консультантов). Если компания уже не маленькая, но еще не такая крупная чтобы позволить себе иметь в штате отдел (или дирекцию) развития, то опять-таки эти функции может выполнять директор компании, но в этом случае с большой вероятностью ему потребуется помощь со стороны внешних экспертов (возможно даже на постоянной основе).
Если же в компании уже есть отдел развития, то данными функциями может заниматься он при контроле со стороны директора.
Почему предлагаются именно такие варианты распределения рассматриваемого здесь функционала? Да потому, что разработка регламентов – это деятельность, связанная с развитием компании, конкретно с развитием системы управления.
А значит, для эффективной реализации такой деятельности нужно использовать технологию проектного управления. В данном случае речь идет именно о проектах развития.
То есть разработка и внедрение регламентов должна быть проектной деятельностью, которую курирует или сам директор или отдел развития (при контроле со стороны директора).
ЭТО МОЖЕТ БЫТЬ ИНТЕРЕСНО
Ближайший семинар по оргпроектированию состоится 18-19 июня 2024 г.
Таким образом, регламент должна создавать проектная группа, состав которой у каждого проекта может быть свой. При этом обязательно в состав группы должен входить сотрудник отдела развития.
Если у компании нет отдела развития, то в состав некоторых проектных групп может включаться внешний специалист (консультант). В таком случае контролировать работу проектных групп будет сам директор (возможно с помощью консультанта).
Примечание: более подробно тема данной статьи рассматривается на семинаре-практикуме "Организационное проектирование. Реструктуризация предприятия и бизнес-процессов", который проводит автор данной статьи - Александр Карпов.
Ниже представлена форма для подписки на новые материалы сайта (статьи и опыт), связанные с постановкой современной системы управления и повышением эффективности компании. То есть в рассылках будет информация только о новых материалах, аналогичных тому, что размещен на данной странице сайта.
Разработка регламента: кто и как этим должен заниматься
rik-company.ru
Книга "Организационное проектирование. Реструктуризация предприятий и бизнес-процессов"
Семинар-практикум "Организационное проектирование. Реструктуризация предприятий и бизнес-процессов":
- открытый семинар-практикум;
- корпоративный семинар-практикум;
- интернет-семинар;
Управленческий консалтинг по направлению "Организационное проектирование. Реструктуризация предприятий и бизнес-процессов"
Семинар-практикум "Организационное проектирование. Реструктуризация предприятий и бизнес-процессов":
- открытый семинар-практикум;
- корпоративный семинар-практикум;
- интернет-семинар;
Управленческий консалтинг по направлению "Организационное проектирование. Реструктуризация предприятий и бизнес-процессов"
Мне известно очень большое количество попыток регламентировать деятельности компании, которые, по сути, ничем хорошим не закончились.
Почему же большинству компаний не удается создать эффективную машину по зарабатыванию денег за счет регламентации всех бизнес-процессов и проектов?
Безусловно, в каждом конкретном случае на разработку регламентов могут негативно влиять сразу несколько факторов. Тем не менее, на мой взгляд, есть одна причина, которая с вероятностью близкой к 100% хоронит идею регламентации.
Итак, одна из основных проблем, из-за которой регламенты в компании не работают, заключается в самой организации деятельности по их разработке.
Самый распространенный подход к разработке регламентов заключается в том, чтобы поручить данную работу одному (или нескольким, в зависимости от объема) человеку. Причем нередко этим занимается внешний специалист (например, консультант или группа консультантов).
В подавляющем большинстве случаев это приводит к возникновению огромного количества всевозможных регламентов (положений, инструкций и т.д.), которые на практике не используются.
Кстати, раньше все эти регламенты разрабатывались вручную, что, конечно же, занимало много времени, особенно если нужно было вносить какие-то изменения. Сейчас есть много специализированных компьютерных программ, с помощью которых можно разрабатывать регламенты.
При этом регламенты могут формироваться и в текстовом и в графическом виде. В общем, сейчас очень много различных "рисовалок", используя которые можно разрабатывать талмуды за сравнительно небольшое время. "Рисовалок" много, а толку мало.
Благодаря этим программам, разработка регламентов из сложной содержательной задачи превратилась в чисто техническую. Во многих компаниях считают, что им достаточно приобрести одну из таких программ, нанять сотрудника (или пригласить консультанта), который нарисует им все необходимые регламенты.
Кстати, в большинстве компаний так серьезно относятся к выбору названия должности такого сотрудника, как будто от этого что-то зависит.
Как их только не называют. Специалист по разработке регламентов, специалист по бизнес-инжинирингу, бизнес-аналитик и т.д.
Иногда создают целые отделы или группы. Например, отдел/группа корпоративной регламентации или отдел/группа бизнес-инжиниринга или бизнес-аналитиков.
На мой взгляд, подобная централизация, а затем и локализация функции регламентации и приводит к тому, что компания не получает желаемого результата и созданный для разработки регламентов отдел (группа или сотрудник) расформировывается.
Если в компании, скажем так, не очень следят за затратами и не думают о повышении эффективности работы, то такой отдел/группа может просуществовать не один год. Этот отдел и дальше будет продолжать поддерживать в "актуальном" состоянии все раннее разработанные регламенты, а также заниматься созданием новых, но все это не будет иметь никакого отношения к реальной практической деятельности предприятия.
Этот отдел будет, как говорится, вариться в собственном соку. Если в один день уволить всех сотрудников данного отдела, то этого никто и не заметит. Может быть кроме тех, с кем сотрудники этого отдела чаи гоняли на работе.
Противоположностью такого централизованного и локального подхода к разработке регламентов является децентрализованный подход, когда разработкой регламентов занимаются все подразделения. То есть каждое подразделение полностью автономно разрабатывает для себя регламенты.
Основные проблемы такой децентрализованной стратегии разработки регламентов заключаются в том, что нельзя будет нормально прописать взаимодействие подразделений при выполнении различных функций, а также в том, что каждое подразделение может использовать свои форматы описания регламентов.
Таким образом, действительно эффективным подходом к разработке регламентов является смешанный вариант.
Он основывается на следующих принципах:
Безусловно, должна быть какая-то координация и контроль разработки регламентов. Кроме того, нужно разработать и утвердить единые стандарты описания регламентируемых объектов компании.
Возникает вопрос: кто же должен заниматься разработкой единых стандартов, координацией и контролем разработки регламентов?
Если компания небольшая, то данные функции может выполнять сам директор (возможно, привлекая внешних консультантов). Если компания уже не маленькая, но еще не такая крупная чтобы позволить себе иметь в штате отдел (или дирекцию) развития, то опять-таки эти функции может выполнять директор компании, но в этом случае с большой вероятностью ему потребуется помощь со стороны внешних экспертов (возможно даже на постоянной основе).
Если же в компании уже есть отдел развития, то данными функциями может заниматься он при контроле со стороны директора.
Почему предлагаются именно такие варианты распределения рассматриваемого здесь функционала? Да потому, что разработка регламентов – это деятельность, связанная с развитием компании, конкретно с развитием системы управления.
А значит, для эффективной реализации такой деятельности нужно использовать технологию проектного управления. В данном случае речь идет именно о проектах развития.
То есть разработка и внедрение регламентов должна быть проектной деятельностью, которую курирует или сам директор или отдел развития (при контроле со стороны директора).
Если у компании нет отдела развития, то в состав некоторых проектных групп может включаться внешний специалист (консультант). В таком случае контролировать работу проектных групп будет сам директор (возможно с помощью консультанта).
Примечание: более подробно тема данной статьи рассматривается на семинаре-практикуме "Организационное проектирование. Реструктуризация предприятия и бизнес-процессов", который проводит автор данной статьи - Александр Карпов.
| Если у Вас возникли какие-то вопросы по данной статьей Вы можете направить их по адресу 5046320@mail.ru. Автор статьи ответит на Ваши вопросы в течение нескольких дней с момента получения. |
Ниже представлена форма для подписки на новые материалы сайта (статьи и опыт), связанные с постановкой современной системы управления и повышением эффективности компании. То есть в рассылках будет информация только о новых материалах, аналогичных тому, что размещен на данной странице сайта.
