КАТЕГОРИИ:
АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
|
Революционный подход к рационализации. Реинжиниринг бизнес-процессовВнедрение новых принципов и методов управления лишь в редких случаях ведет к эволюционному развитию организации. В большинстве своем систему управления приходится кардинально перестраивать. При проведении кардинальных изменений в компании количество и скорость изменений требуют от руководителей применения все более формализованных и технологичных методов, таких как реинжиниринг бизнес-процессов (BPR – business process reingineering). В 1993 г. американские специалисты по менеджменту М.Хаммер и Дж.Чампи в основных чертах сформулировали концепцию реинжиниринга бизнеса. По их мнению, реинжиниринг – это фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компании для достижения коренных улучшений в основных актуальных показателях их деятельности – стоимость, услуги, качество, темпы [35]. Результатом является резкое (на порядок) улучшение важнейших количественно измеряемых показателей издержек, качества, обслуживания и сроков. Согласно этой концепции речь должна идти о глубинной рационализации структуры управления. Одно из ключевых понятий, лежащее в основе реинжиниринга – бизнес-процессы. Именно их совершенствование является огромным резервом повышения эффективности деятельности предприятия. А для этого необходимо осмыслить природу бизнес-процессов, понять, какое значение они имеют для предприятия, как следует их правильно изменять. Само внимание к бизнес-процессам, их совершенствованию требовало от менеджеров нестандартного подхода. Постепенно реинжиниринг, который предлагает сломать существующую на предприятии систему и построить ее заново на основе такого революционного изменения бизнес-процессов, стал превращаться в систему управления. [24] Майкл Хаммер и Джеймс Чампи определяют реинжиниринг бизнес-процессов как «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов компании для достижения коренных улучшений в актуальных основных показателях их деятельности: стоимости, качества, услуг и темпов». Ноу-хау бизнес-инжиниринга заключается в детальном и формализованном описании элементов управления бизнесом, в том числе ее бизнес-процессов, способствующих реализации функций. Применение методов бизнес-реинжиниринга (реинжиниринга бизнес-процессов) дает возможность проводить необходимые изменения в компании более фундаментально, радикально и технологично. На практике выделяется три типа компаний, для которых применение реинжиниринга необходимо и целесообразно: 1. Компании, находящиеся на грани краха в связи с тем, что цены на их товары заметно выше, чем у конкурентов и (или) качество товаров, сервис заметно ниже, чем у конкурентов. Эти компании не имеют выбора, так как если они не предпримут решительных шагов, они неизбежно разорятся. 2. Компании, не находящиеся в текущий момент в затруднительном положении, но руководство которых предвидит неизбежность возникновения трудноразрешимых проблем, связанных, например, с появлением новых конкурентов, изменением требованием клиентов, изменением экономического окружения и т.п.; 3. Компании, не имеющие проблем сейчас и не ожидающие их в ближайшем обозримом будущем. Это компании – лидеры, проводящие агрессивную политику. Они не удовлетворяются текущим состоянием и с помощью реинжиниринга хотят добиться лучшего. Один из самых наглядных способов представления информации, часто используемый при внедрении интегрированных систем управления – диаграммы IDEF (ICAM Definition), позволяющие проводить исследования определенных характеристик любой организации. Применение методологии IDEF позволяет решить следующие задачи: · Выяснить структуру и содержание существующих потоков информации на предприятии · Определить какие проблемы, выявленные в результате функционального анализа и анализа потребностей, вызваны недостатком управления соответствующей информацией. · Выявить, информационные потоки, требующие дополнительного управления для эффективной реализации модели. Геннадий Верников так комментирует возможные сложности при начинании перестройки системы функционирования: «:... интуитивно все вроде бы понятно, но при попытках формализовать взаимоотношения возникает «сплошной туман». В данной ситуации существенно помочь может хорошо разработанное семейство методологий IDEF, являющееся государственным стандартом в США. IDEF-методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности – ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов. Более того, собственно с широким применением IDEF и связано возникновение основных идей популярного ныне понятия – BPR.» IDEF-методология представляет собой понятный и простой графический язык функционального моделирования, позволяющий охватить весь моделируемый процесс как бы «с верху», постепенно его конкретизируя и детализируя. Основной идеей моделирования IDEF (Integration Definition for Function Modeling - интегрированное определение для функционального моделирования) является то, что процессы (или функции реального объекта бизнеса) могут быть представлены как некоторые преобразования входного (и, возможно, управляющего) потока в выходной под контролем управляющего потока с использованием для преобразования некоторого механизма (см. рис.13). Процессы представляются на более высоком уровне диаграммы достаточно общим образом, позволяющим уяснить их суть, однако, без излишней детализации, усложняющей понимание и чтение диаграмм. При необходимости более детального рассмотрения они могут быть декомпозированы, то есть представлены в виде отдельной диаграммы, для которой исходный функциональных блок играет роль контекстной диаграммы.
Понятие функционального блока лежит в основе нотации и методологии IDEF, вторым элементом является «поток» (в стандарте называемый «интерфейсная дуга») - элемент, описывающий данные, информационный объект или объект реального мира, и третьим принципом методологии является принцип «функциональной декомпозиции» блоков. Данный принцип представляет собой модельную интерпретацию той практической ситуации, что любое действие может быть разбито на более простые операции. Основные элементы и понятия IDEF Графический язык IDEF удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия: Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 13) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении. Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом: · Верхняя сторона имеет значение “Управление” (Control); · Левая сторона имеет значение “Вход” (Input); · Правая сторона имеет значение “Выход” (Output); · Нижняя сторона имеет значение “Механизм” (Mechanism). Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер. Вторым “китом” методологии IDEF является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком. Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного. С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.). В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся. Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла. Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели. Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой. Результатом применения IDEF при описании конкретного процесса является графическая модель, состоящая из диаграмм. На диаграммах все функции и взаимосвязи представлены как блоки (функции) и стрелки (взаимосвязи). Блоки и стрелки в IDEF-модели используются для представления связей между несколькими подфункциями на диаграмме, описывающей более общую функцию. Эта диаграмма является «подчиненной диаграммой» и показывает конкретные воздействия, управляющие каждой подфункцией, а также источники и адресаты этих воздействий (см. рис. 14). Рисунок 14. Зависимые диаграммы На IDEF-диаграмме (рис.14) отображены уже 3 функции (А, В, С) и их взаимосвязи. Из диаграммы видно, что функция В зависит от одного входа и двух управлений и производит один выход, от которого зависит функция С. Здесь термин «зависимость» означает, что функция С использует результат воздействия другой функции в данном случае функции В (материальные объекты или информацию), изображаемую входящей в блок С. Одной из наиболее важных особенностей методологии IDEF является постепенное введение все больших уровней детализации, отображающих модель. Таким образом, обеспечивается подача информации и читатель располагает хорошо очерченным предметом рассмотрения с приемлемым объемом новой информации на каждой следующей диаграмме. Данная особенность IDEF-методологии показана на рис. 15, где приведены четыре диаграммы и их взаимосвязи. Рисунок 15 . Структура IDEF-модели
Каждая компонента может быть декомпозирована на другой (дочерней) диаграмме. Каждая диаграмма иллюстрирует «внутреннее строение» блока на родительской диаграмме. Любая IDEF-модель начинает строиться с диаграммы 0-го уровня, представляя систему в качестве единого модуля. Поскольку единственный блок представляет всю систему как единое целое, наименование, указанное в блоке, является общим. Это верно и для интерфейсных стрелок - они также представляют полный набор внешних интерфейсов для системы в целом. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме несколькими блоками, соединенными интерфейсными стрелками. Эти блоки представляют основные подфункции (подмодули) единого исходного модуля. Данная декомпозиция выявляет полный набор подмодулей, каждый из которых представлен как блок, границы которого определены интерфейсными стрелками. Каждый из этих подмодулей может быть декомпозирован подобным же образом, чтобы изобразить еще больше деталей. Принципы ограничения сложности IDEF-диаграмм Диаграммы IDEF несут в себе очень концентрированную информация, в связи с чем необходимо применять специальные меры по повышению их разборчивости и удобочитаемости, известные как принципы ограничения сложности, основными их которых являются: ограничение количества блоков на диаграмме тремя-шестью; ограничение количества интерфейсных дуг, входящих (выходящих) к одной стороне блока - четырьмя. Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.
|