Knowledge Management Software - Системы управления знаниями KMSOFT: Управление знаниями, автоматизация документооборота Программные решения KMSOFT в сфере менеджмента знаний: Е-МАСТЕР: Управление знаниями, Е-МАСТЕР: Документооборот Copyright © KMSOFT, 2002-2023 info@kmsoft-is.com Terms of use Privacy Policy
KMSOFT - Системы управления знаниями KMSOFT: Менеджмент знаний, автоматизация документооборота, системы класса ECM (управление корпоративной информацией) Информация о продуктах и услугах в сфере менеджмента знаний »»»
««« Описание программных решений в сфере менеджмента знаний: Е-МАСТЕР: Управление знаниями, Е-МАСТЕР: Документооборот
Продукты и услуги
Продукты и услуги
Статьи
Статьи
Теория
Теория
Экстранет
Экстранет
Поддержка
Поддержка
О Фирме
О Фирме
Статьи
Расширенный поиск
Найти

Основные публикации по менеджменту знаний

Избранные статьи по менеджменту знаний

Антология статей по менеджменту знаний

Глоссарий

Библиотека статей

Общие концепции современного менеджмента

Управленческий консалтинг

Финансовый менеджмент

Логистика

Менеджмент качества

Менеджмент знаний

Маркетинг

Методология бизнес-инжиниринга

Организационная культура

Управление персоналом

Организационное проектирование

Информационные технологии

Стратегическое управление
Новые публикации
Главная Статьи Библиотека статей Методология бизнес-инжиниринга

Реинжиниринг: бизнес-процессы или зоны ответственности?

В.А. Гончарук, marketconsult@mtu-net.ru  http://consult.webzone.ru

Лет 8 назад консалтинг был относительно прост. Почти на любом предприятии изменение 2-х - 3-х главных функций в управлении давало чуть ли не стопроцентный прирост эффективности. Несколько лет после кризиса требовали уже более скрупулезной работы. Чтобы получить аналогичные результаты, стало необходимым отладить множество процедур, большинство из которых выполнялось, в принципе, правильно, но могло быть оптимизировано. Последние же годы вновь начинают напоминать докризисную эпоху. Хотя 80% проектов связано преимущественно с быстрым ростом компаний, оставшаяся часть направлена на ликвидацию последствий неудачного реинжиниринга бизнес-процессов, и требует кардинальных мер.

Оставляя в стороне вопрос возможной некомпетентности или неподготовленности людей, проводящих реинжиниринг, попробуем разобраться в самом предмете.

На рисунке показано деление предприятия по функциональным отделам, каждый из которых возглавляет руководитель (А, Б, и т.д.). Пунктиром отмечены процессы, которые имеют простую конфигурацию (процесс 1), смыкаются (процессы 2 и 3), разветвляются (процесс 4). В их реализации необязательно задействованы все отделы фирмы или в одной и той же последовательности.

Идеи, поставленные во главу угла сторонниками данного подхода, примерно следующие:

  1. Реинжиниринг бизнес-процессов позволяет организовать фирму или бизнес кардинально по-новому и наиболее оптимальным образом («революционное преобразование» по Хаммеру).
  2. Предприятие интересует не статичный, а динамичный результат, и бизнес-процесс, имеющий на выходе товар или услугу, позволяет его получать.
  3. «В наш век высоких технологий» бизнес-процесс превосходно поддается автоматизации, и в новом качестве может быть максимально эффективен.

Под всеми тремя идеями можно подписываться не глядя. Но …

  1. Революционные преобразования планируются и при оптимизации оргструктуры предприятия, разработке стратегий, концепции развития. Для этого необходимо желание и готовность заказчика, а реинжиниринг бизнес-процессов - всего лишь один из возможных методов.
  2. Никто и никогда не реформирует предприятие для достижения вчерашних показателей. Грамотный руководитель или консультант, применяя любые методики, старается строить динамически устойчивую фирму. И результат получает не абстрактный процесс, а люди, выполняющие определенные задачи.
  3. Бизнес-процессы необходимо автоматизировать, именно в их логике удобно ставить задачи программистам, но стоит ли удобство программирования объявлять первым приоритетом для предприятия?

В «сухом остатке» идей реинжиниринга бизнес-процессов имеется одна относительно прогрессивная идея, впрочем, актуальная еще с 70-х годов, - это автоматизация предприятия. И одна важная идея отсутствует - причина, по которой бизнес-процессы могли бы работать. Их можно красиво нарисовать и даже жестко внедрить почти в задуманном виде, но ведь нас, кажется, интересовал динамичный результат?

Динамику создают люди, принимая решения в изменившейся ситуации - внедряя и корректируя процессы по мере необходимости. Без людей любая управленческая схема нежизнеспособна. И методисты реинжиниринга предлагают решение данной проблемы: вводом «хозяина» бизнес-процесса, управляющего его течением.

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

Почему это не работает, тоже понятно. Руководители отделов, освобожденные от ответственности за результат, благополучно занимаются «футболом», посылая «хозяина» процесса вместо себя договариваться со смежниками. А «хозяин», не имея возможности заставить работать не подчиняющихся ему руководителей, либо спускает все на тормозах, либо привлекает для решения вопроса директора предприятия. (Последний и оказывается в матричной структуре единственным реально ответственным).

В проектных организациях, консалтинговых и рекламных фирмах матричная структура может быть эффективна. Эффективность достигается сохранением принципа единоначалия. Если всю власть (в т.ч. право распоряжаться бюджетом) по проекту отдать «хозяину», если все функциональные отделы в рамках установленных процедур и в заранее оговоренные сроки будут обязаны выполнять его заказы, то цели проекта будут достигнуты. Бизнес-процесс эффективно реализуется.

Заметим, что в перечисленных отраслях проект является действительно автономным (т.е. его можно адекватно определить), и он малопредсказуем (т.е. неизвестно, какие ресурсы понадобятся для очередного проекта). Отсюда проектно-матричная структура как меньшее зло по сравнению с постоянной реорганизацией предприятия.

В более предсказуемом бизнесе, связанном с производством и распределением товаров, а не услуг, эффективное управление бизнес-процессами также давно и успешно реализуется. «Хозяин» бизнес-процесса называется начальником дивизиона, а структура, в которой все это реализуется, дивизиональной. В этом случае «хозяин» также обладает всеми необходимыми полномочиями, единолично отвечает за результат и осуществляет взаимодействие с общими службами предприятия по заранее определенным процедурам с позиции заказчика. Под начальником дивизиона группируются все процессы, ориентированные на определенный рынок.

Проблемы с внедрением процессного управления начинаются там, где понятия удобства автоматизации начинают смешивать с понятиями управления. Ведь мало кому приходит в голову управлять по статьям бухгалтерского баланса. Отчего же в товарной группе, ориентированной на единый рынок, вдруг назначать нескольких ответственных за товары, проводящих самостоятельную политику? Замена вертикального управления на горизонтальное в большинстве случаев невозможна, а их совмещение неоправданно. Достаточно проблем с определением количества и задач функциональных подразделений, чтобы добавлять к ним аналогичные с группировкой бизнес-процессов, которые еще и сконфигурированы гораздо сложнее (см. рис.)

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

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

В общем виде алгоритм реинжиниринга предприятия может быть следующим:

  • Вначале оцениваются сильные и слабые стороны предприятия - его потенциал (который составляют, в первую очередь, идеи и люди, опыт и квалификация). По наиболее интересным для фирмы направлениям оцениваются потенциальные и реальные рынки.

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

  • Затем формулируются общие стратегические цели предприятия (которые могут охватывать разные рынки и отрасли) и цели бизнесов.

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

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

  • Затем по каждому бизнесу формируются бюджеты, сводятся в общий, проводится коррекция запланированных мероприятий, и выстраивается годовой оперативный план. Реализация плана тщательно контролируется.

  • Бизнес-процессы корректируются (или выстраиваются совершенно по-новому) на стадии разработки структуры, когда становится ясным ее стратегическое предназначение. Степень «революционности» преобразований определяется принятыми стратегиями. А работоспособность бизнес-процессов обеспечивается, как это ни парадоксально, отсутствием у них «хозяев».

Такое «крамольное» заявление необходимо поддержать аргументацией, поэтому рассмотрим сначала случай, когда «хозяин» у бизнес-процесса есть. И, допустим, фирма настолько проникнута «правильным» корпоративным духом, что, несмотря на многоначалие, вовремя и качественно делает свое дело. Тогда работа типичного менеджера по продукту выглядит примерно так:

Он организует исследования рынка и определяет, каким образом должен развиваться продукт.

Он формулирует задание дизайнерам на разработку внешнего вида продукта, конструкторам - на его потребительские качества, технологам - на состав, экологичность, себестоимость продукта.

Он определяет для производства объем и график выпуска продукта.

Вместе с рекламистами и маркетологами разрабатывает программу продвижения продукта (не забыв согласовать ее с коллегами по другим продуктам ассортимента).

Он разрабатывает сбытовикам план по сбыту, и логистикам - план поставки продукта в точки реализации.

Он…

Абсурд? У него не хватит квалификации, чтобы делать всю работу за всех? Тогда что же он может делать? Похоже, только следить за своевременным и качественным выполнением обязанностей функциональными подразделениями предприятия. Причем и здесь он вынужден полагаться на заключения специалистов, и если технолог утверждает, что сковородки можно делать исключительно из титана, с ним приходится соглашаться. (Начальник дивизиона в этой ситуации поискал бы другого технолога).

Бизнес процессы современного предприятия слишком сложны, чтобы один «хозяин» мог охватить их полностью. А поскольку его задача сводится к координации действий функциональных подразделений, то почти всегда ее эффективнее решать другим способом, без участия «хозяина».

Что теоретически достигается вводом данной фигуры?

Заинтересованность в результате бизнес-процесса у конкретного человека, облеченного определенными полномочиями.

Контроль, осуществляемый заинтересованным лицом.

Инициация разработки или изменения бизнес-процесса, переставшего решать полезные задачи.

На практике, предприятию более выгодна совокупная результативность бизнес-процессов, которые тесно связаны между собой. (И если бы мы плодили «горизонтальных хозяев», кто-то должен был озаботиться налаживанием связей между ними). Задача общей результативности отчасти решается определением целей компании и доведением их до каждого менеджера. Отчасти - вводом системы стимулирования, поощряющей достижение общефирменных целей (в заработной плате всех сотрудников имеется весомая составляющая, привязанная к результатам фирмы в целом). Отчасти - правильным распределением зон ответственности функциональных подразделений: в эти зоны обязательно должны входить процедуры взаимодействия со смежниками.

Тогда на стыках отделов проявляются не полностью совпадающие интересы смежных структур, в увязке которых эти структуры весьма заинтересованы. Результатом увязки становится работоспособный компромисс - процедуры взаимодействия, устраивающие обе стороны до тех пор, пока способствуют достижению общего результата, и пока четко соблюдаются. Нарушение сроков или качества в передаче продукта (товара, информации, услуги) от подразделения к подразделению сдвигает баланс интересов, поэтому сразу становится предметом разбирательства, инициируемого «ущемленным» отделом. То есть, как сам бизнес-процесс реализуется разными функциональными подразделениями, так и контроль за его качественным выполнением является распределенной функцией, осуществляемой подразделениями по зонам ответственности.

Остается решить важный вопрос разработки новых и коррекции старых бизнес-процессов. И он успешно решается заменой «хозяина» процесса на заказчика. Любой бизнес-процесс нужен для чего-то, входящего в компетенцию одного из функциональных подразделений, поэтому любое подразделение получает право и обязанность инициировать необходимые предприятию процессы в рамках своей зоны ответственности.

Например, ввод новой товарной группы в сбытовую сеть может предложить отдел маркетинга, проведя плановое исследование целевого сегмента. Или это может сделать отдел закупки, получив от поставщика информацию о свойствах нового модельного ряда. Или директора магазинов, ориентируясь на текущий спрос, предложат расширить ассортимент. В зависимости от источника получения заказа будут реализованы различные бизнес-процессы (в двух случаях они начнутся с обучения сбытовиков новому товару, в одном - с оценки рентабельности закупки).

Подразделение-заказчик принимает результаты бизнес-процесса и отвечает за их эффективное использование. Структуры-исполнители отрабатывают свои части согласно установленным процедурам.

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

Что же касается автоматизации и перевода компании на «рельсы прогресса», то для этой цели как раз и желателен хозяин процесса, чьей главной задачей будет перевод запросов руководителей функциональных подразделений на язык постановки задач программирования. Только реинжиниринг предприятия должен быть выполнен до того.
Источник: www.bigspb.ru
Коротко о системе Е-МАСТЕР
Е-МАСТЕР® — система управления корпоративной информацией.

Е-МАСТЕР® включает в себя возможности систем класса ECM (Enterprise Content Management).

Система обеспечивает:

  • Совместное создание и согласование документов
    • Каждый документ может быть обсужден как при помощи прикрепленного к нему мини-форума, так и в главном форуме
    • Разработанный документ может быть направлен на согласование по указанному маршруту
  • Хранение документов любых форматов
    • Хранение и передача документов в зашифрованном виде
    • Встроенные системы восстановления после сбоев и резервного копирования
  • Поиск документов
    • Возможность поиска по ключевым словам и другим атрибутам документов (автор, дата создания…)
    • Возможность поиска с помощью навигации по рубрикам
  • Управляемый доступ к документам
    • Возможность установки доступа к документам для различных категорий пользователей
    • Возможность введения ограничений на работу с документами
  • Функциональный интерфейс пользователя
    • Веб-интерфейс, позволяющий просматривать карточки и скачивать файлы из системы хранения документов
    • Удаленный доступ или работа пользователя из любой точки мира (при условии подключения к Интернету).
Система FLAMORY™

FLAMORY™FLAMORY™ — уникальный программный продукт, позволяющий сохранять историю действий пользователя на компьютере, таких, например, как работа в приложениях Windows, посещения сайтов и д.р.
Сохраненные последовательности действий, далее, можно просмотреть, сохранить в файл и передать коллегам. FLAMORY позволяет аккумулировать и делиться знаниями.
Работая с FLAMORY, обмен опытом, обучение новых сотрудников, обсуждения технологий, становятся, как никогда ранее, простой и удобной, в практических аспектах, задачей.

FLAMORY™ разрабатывается при участии специалистов KMSOFT.
Скачать бета-версию можно по этой ссылке.

Версия для печати  |  Пользовательское соглашение

Статьи
KMSOFT: Управление знаниями, автоматизация документооборота, управление корпоративной информацией
К началу страницы ...