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

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

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

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

Глоссарий

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

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

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

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

Логистика

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

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

Маркетинг

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

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

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

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

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

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

Пирамида сущностей реинжиниринга

Мансур Гиматов

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

А на самом деле, на чем базирована методика реинжиниринга?

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

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

Ну, научный, так научный – решаем задачу. Предпосылки: 70-ые годы – появление термина Total Quality Management (TQM) в Японии. 80-90-ые – стандарты IDEF и Business Process Reengineering (BPR) уже в Америке. 60-ые – по сей день – бурное развитие компьютерной техники. Ближе к 80-м – компьютерные технологии «перекрашиваются» в информационные. Вопрос: Что такое реинжиниринг?

***

Стандартный подход, обосновывавший появление TQM, опирается на условия послевоенной разрухи в Японии, борьбой за рынки сбыта методом повышения качества товаров и т.п. В принципе все понятно и все логично, но…. Причем тогда Америка, где принципы TQM переросли в новый качественный уровень, позднее названный BPR? И опять же: все мы прекрасно осознаем (интуитивно!), что и TQM и BPR напрямую завязаны с информационными технологиями. Но вот каким образом они связаны и что между ними общего – большущий вопрос. И что же произошло в преддверии 60-ых?

Окончание второй мировой войны, в условиях которой нечеловеческими усилиями был совершен колоссальный прыжок в техническом и технологическом уровнях, заставило мировой бизнес оглядеться в решении вопроса использования огромного военно-промышленного комплекса. (Хочу заметить, не отвлекаясь от основной темы, что именно в этой стадии и заключены все беды и злоключения бывшего Советского Союза). И решение было найдено достаточно быстро – товары массового потребления (ТМП). Но новый технико-технологический уровень позволял уже не просто выпускать ложки-вилки для потребителя и мотыги для сельского хозяйства, но и осваивать новые виды значительно более сложной продукции – телевизоры, холодильники, чуть позднее – электронику и т.п. Первая волна опытного производства, приведшая к быстрому накоплению средств предприятиями и повысившая покупательскую способность части населения, вызвала вторую – массовое производство ТМП.

Мало того, что промышленность захлебнулось в заказах – миллионы штук каждого из видов! Но к тому же и требования к качеству продукции возросли неимоверно. Если раньше, производя продукцию для ВПК, сельского хозяйства и средства воспроизводства, предприятия имели возможность содержать ремонтные мастерские и т.п., списывая издержки на себестоимость, то теперь КАЖДЫЙ покупатель хотел, чтобы его «холодильник» РАБОТАЛ!

Для выполнения всех этих требований и условий была необходима революция в сфере производства. И она произошла.

Основная проблема производителя того периода заключалась в том, что он, во-первых, не мог обеспечить нужного качества товара, а, во-вторых, не мог добиться необходимой гибкости производства, позволяющей более чутко реагировать на потребительские запросы, С ПОМОЩЬЮ СТАНДАРТНЫХ СРЕДСТВ ПРОИЗВОДСТВА. Появилась необходимость использования новых «орудий труда».

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

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

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

Да, именно информационно-компьютерные технологии явились теми «орудиями труда», позволившими вырваться промышленному производству из замкнутого круга противоречий периода 50-70-ых годов.

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

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

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

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

Доказательство первого утверждения, несмотря на нетривиальность подхода, все же достаточно просто. Думаю, что все, кто имел отношение к разработкам программного продукта (особенно в период конца 80-ых начала 90-ых годов), не раз задавался вопросом: каким образом эффективно оплачивать труд программиста? Используя концепции наемного труда, мы получаем лишь две возможности: по затраченному времени – и тогда программист «и в ус не дует», ссылаясь на интеллектуальность своей деятельности; либо по объему произведенной продукции – то бишь, количеству написанных им команд. Вы представляете, сколько он их напишет в самой обычной программульке? Windows сравнительно с ней будет казаться простенькой утилитой!

Итак, первое утверждение – неэффективность наемного труда в сфере ИТ считаем доказанной. А что же дальше? И тут на сцену выходят японские товарищи, преподнося нам на блюдечке с каемочкой новую форму общественных взаимоотношений – Total Quality Management – форма совладения предприятием. Не будем грешить против истины, данная форма существует уже давно, с момента появления первого акционерного общества. Но АО – это переходной этап, сочетающий в себе как наемный труд, так и совладение предприятием. Японские экономисты впервые предложили нам вариант чистой формы общественных взаимоотношений.

Ну, а то, что данные взаимоотношения повсеместно вытесняют наемный труд, думаю, в доказательстве уже не нуждается.

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

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

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

Это – первая из сторон понятийной пирамиды сущностей «реинжиниринга».

Попробуем теперь перейти к другой ее стороне – логической сути реинжиниринговой реформации.

Надо сказать, что попытка ее осмысления существенно осложнена уже указанным интуитивным подходом к созданию терминологии реинжиниринга бизнес-процессов. Мы так глубоко увязли в болоте используемых терминов, что попытка сделать шаг назад непредсказуема в своих последствиях. Ну, например, используя термин «реинжиниринг», можно задуматься, а что же тогда означает термин «инжиниринг» – «…глобальное проектирование бизнес-процессов…»? Весело…

Давайте все-таки в стремлении обойти это «болото» рассмотрим для начала логику «ИНЖИНИРИНГА».

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

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

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

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

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

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

И вновь в этом нам поможет терминология информационных технологий.

Оглядываясь на развитие средств подготовки программного обеспечения (проще говоря, языков программирования), обратим внимание на логику данного развития:

  • Машинные коды;
  • Языки низкого уровня;
  • Языки высокого уровня;
  • Структурное программирование;
  • Объектное программирование.

То есть каждый раз, когда объемы подготавливаемого программного кода начинали превосходить возможности программирования (программа выходила из-под контроля), происходил шаг вверх по лестнице языковых средств. Формально можно высказаться, что велось постепенное укрупнение используемых блоков в ПО – от «мелкокирпичного» к «крупноблочному».

С другой стороны, давайте воспроизведем схемы двух программ, имеющих одинаковые входную и выходную информации, и выполняющих практически одну и ту же работу, но при этом одна из них является структурированной (схема 1), а другая – нет (схема 2).

Сравнивать данные схемы нет никакого принципиального смысла. Более того, в определенных случаях вторая программа может даже работать лучше (быстрее, эффективнее) первой. Но… как только мы попытаемся добавить в эти программы некий новый процесс (например, вывод дополнительной таблички), то становится ясным, для чего нужно структурное программирование.

В первом случае совсем незначительно увеличивается основное тело программы, добавляется блок «процесс k+1», а в блоке выделенных процедур и функций появляется новый блочок, организующий вывод новой таблицы (схема 3).

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

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

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

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

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

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

В итоге всех приведенных аналитических выкладок мы получили три стороны понятийной пирамиды – три сущности реинжиниринга:

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

Логическаяреинжиниринг как инструмент подготовки новой структурированной формы управления предприятием (программы) с использованием методик и теоретических выкладок ИТ в ее проектировании.

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

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

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

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

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

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

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

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

    Здесь налицо столкновение интересов производств П1 и П2, т.к. выпуск продукции В дает меньшую материальную стимуляцию для участников П1, несмотря на то, что продукция С может приносить прибыль для всего предприятия даже большую, чем выпуск продукции А.

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

    И в завершение абстрактная и несколько шутливая аналогия:

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

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

    © 2000–2001 E-xecutive, Ward Howell International
    Original article: http://www.e-xecutive.ru/publications/aspects/article_1601/
    Источник: www.bigspb.ru
    Коротко о системе Е-МАСТЕР
    Е-МАСТЕР® — система управления корпоративной информацией.

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

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

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

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

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

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

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