Управление бизнес-процессами в организации

Курс лекций по дисциплине «Управление бизнес-процессами в организации» Тема 1. Введение в теорию бизнес-процессов Реинжиниринг — это радикальное переосмысление и перепроектирование деловых процессов для достижения резких, скачкообразных улучшений главных современных показателей деятельности компании, таких, как стоимость, качество, сервис и темпы. Современные предприятия в значительной мере все еще базируются на принципах, сформулированных Адамом Смитом в его фундаментальном труде «Благосостояние наций», опубликованном в 1776 г. Производственный процесс он предлагал разбить на элементарные, простые задания (работы), чтобы каждое из них мог выполнять один рабочий; при этом от рабочего не требовалось высокой квалификации и умения выполнять работу в целом, достаточно, чтобы он специализировался на одном или нескольких простейших заданиях. Это легко реализуемая идея, в связи с чем предложенные принципы были и остаются весьма успешными в массовом производстве типовой продукции, выполняемой силами большой армии неквалифицированных рабочих, использующих простое оборудование. Принципы, сформулированные Смитом и революционные для его времени, не соответствуют требованиям современной индустрии, так как продукция в наше время должна быть ориентирована в основном на узкие группы потребителей, исполнители хорошо образованны, не боятся ответственности и стремятся к решению по-настоящему сложных задач; рынок продуктов стал намного шире, а конкуренция и борьба за потребителя — более агрессивной. Мир, в котором живут современные предприниматели, за последние 10 лет существенно изменился. Во-первых, потребители в цивилизованном мире взяли в свои руки контроль на рынке. Они намного лучше чем в начале 80-х годов осведомлены о своем положении на рынке и о возможностях выбора продукции, которые у них имеются. Во-вторых, сформировались новые ожидания относительно предлагаемых потребителям товаров и услуг. Потребляемой становится продукция, которая адаптирована к определенным нуждам конкретного потребителя и доставляется наиболее подходящим способом в момент, установленный потребителем. В-третьих, существенно изменились средства производства и технологии, а среди последних — прежде всего информационные. Информационные технологии — это не только база многих других важных технологий (вычислительных, коммуникационных, робототехники, распределенных баз данных и пр.), но и способ, с помощью которого информация, предлагается потребителю. Однако несмотря на эти изменения, многие компании с длительной историей хозяйствования на рынке продолжают по инерции держаться за старые управленческие идеи. Поэтому необходимо переосмыслить способы организации бизнеса и использовать принципиально иной подход, который позволит в полной мере реализовать преимущества новых технологий и человеческих ресурсов. Этот подход — основа инжиниринга бизнеса (бизнес-процессов), наиболее важным направлением которого является реинжиниринг, или перестройка существующих компаний. Проблемы повышения эффективности бизнеса и усиления его конкурентоспособности остро стоят перед российскими предприятиями, переживающими переходный период. Результативно решить данные проблемы можно при помощи подходов, базирующихся на реинжиниринге бизнес-процессов. Поэтому необходимо разобраться в сущности реинжиниринга как одного из направлений предотвращения кризисных явлений на предприятии. Реинжиниринг бизнес-процессов предприятий используется в случаях, когда необходимо принять обоснованное решение о реорганизации деятельности: радикальных преобразованиях, реструктуризации бизнеса, замене действующих структур управления на новые и пр. Предприятие, стремящееся выжить или улучшить свое положение на рынке, должно постоянно совершенствовать технологии производства и способы организации деловых процессов. Для этого прибегают к консалтингу, который базируется на прошлом опыте, суждениях специалистов готовых апробированных решениях, аналогиях, эвристических оценках, сопоставлении мнений. Но можно использовать и альтернативный путь, которым является инженерная деятельность. Такой подход гарантирует получение результата при условии соблюдения правил и методик применения инструментов реинжиниринга, он позволяет контролировать пол ноту исполнения предлагаемых решений и оценивать их качество. Этот подход основан на концепции и методах реинжиниринга бизнес-процессов. Тема 2. Системный анализ деятельности организации Понятие “система” широко используется в науке, технике и повседневной жизни, когда говорят о некоторой упорядоченной совокупности любого содержания. Система является фундаментальным понятием, как системотехники, так и базовых теоретических дисциплин (теории систем, исследования операции, системного анализа и кибернетики). Система — это объективное единство закономерно связанных друг с другом предметов, явлений, сведений, а также знании о природе, обществе и т. п. Каждый объект, чтобы его можно было считать системой, должен обладать четырьмя основными свойствами или признаками (целостностью и делимостью, наличием устойчивых связей, организацией и эмерджентностью). Основные признаки систем Целостность и делимость. Система — это прежде всего целостная совокупность элементов. Это означает, что, с одной стороны, система - целостное образование и, с другой — в ее составе отчетливо могут быть выделены целостные объекты (элементы). При этом следует иметь в виду, что элементы существуют лишь в системе. Вне системы это в лучшем случае объекты, обладающие системнозначимыми свойствами. При вхождении и систему элемент приобретает системноопределенное свойство взамен системнозначимого. Для системы первичным является признак целостности, т. е. она рассматривается как единое целое, состоящее из взаимодействующих частей, часто разнокачественных, но одновременно совместимых. Наличие устойчивых связей. Наличие существенных устойчивых связей (отношений) между элементами или (и) их свойствами, превосходящих по мощности (силе) связи этих элементов с элементами, не входящими в данную систему, является следующим атрибутом системы. Система существует как некоторое целостное образование, когда мощность (сила) существенных связей между элементами системы на интервале времени, не равном нулю, больше, чем мощность связей этих же элементов с внешней средой. Для информационных связей оценкой потенциальной мощности может служить пропускная способность данной информационной системы, а реальной мощности - действительная величина потока информации. Однако в общем случае при оценке мощности информационных связей необходимо учитывать качественные характеристики передаваемой информации (ценность, полезность, достоверность и т. п.). Организация. Это свойство характеризуется наличием определенной организации, что проявляется в снижении энтропии (степени неопределенности) системы H{S} по сравнению с энтропией системоформирующих факторов H{F), определяющих возможность создания системы. Эмерджентность. Эмерджентность предполагает наличие таких качеств (свойств), которые присущи системе в целом, но не свойственны ни одному из ее элементов в отдельности. Наличие интегрированных качеств показывает, что свойства системы хотя и зависят от свойств элементов, но не определяются ими полностью. Отсюда можно сделать выводы: 1) система не сводится к простой совокупности элементов; 2) расчленяя систему на отдельные части, изучая каждую из них отдельности, нельзя познать все свойства системы в целом. Любой объект, который обладает всеми рассматриваемыми свойствами можно называть системой. Одни и те же элементы (в зависимости от принципа, используемого для их объединения в систему) могут образовывать различные по свойствам системы. Поэтому характеристики системы в целом определяются не только и не столько характеристиками составляющих ее элементов, сколько характеристиками связей между ними. Наличие взаимосвязей (взаимодействия) между элементами определяет особое свойство сложных систем — организованную сложность. Добавление элементов в систему не только вводит новые связи, но и изменяет характеристики многих или всех прежних взаимосвязей, приводит к исключению некоторых из них или появлению новых. Системный подход, направление методологии специально-научного познания и социальной практики, в основе которого лежит исследование объектов как систем. Системный подход способствует адекватной постановке проблем в конкретных науках и выработке эффективной стратегии их изучения. Методология, специфика Системный подход определяется тем, что он ориентирует исследование на раскрытие целостности объекта и обеспечивающих её механизмов, на выявление многообразных типов связей сложного объекта и сведение их в единую теоретическую картину.   Стремление к целостному охвату объекта изучения, к системной организации знания, всегда свойственное научному познанию, выступает как проблема уже в античной философии и науке. Но вплоть до середины 19 в. объяснение феномена целостности либо ограничивалось уровнем конкретных предметов (типа живого организма), внутренняя целостность которых была совершенно очевидна и не требовала специальных доказательств, либо переносилось в сферу спекулятивных натурфилософских построений; идея же системной организованности рассматривалась только применительно к знанию (в этой области и была накоплена богатая традиция, идущая ещё от стоиков и связанная с выявлением принципов логической организации систем знания). Подобному подходу к трактовке системности соответствовали и ведущие познавательные установки классической науки, прежде всего элементаризм, который исходил из необходимости отыскания простой, элементарной основы всякого объекта и, таким образом, требовал сведения сложного к простому, и механицизм, опиравшийся на постулат о едином принципе объяснения для всех сфер реальности и выдвигавший на роль такого принципа однозначный детерминизм.   Задачи адекватного воспроизведения в знании сложных социальных и биологических объектов действительности впервые в научной форме были поставлены К. Марксом и Ч. Дарвином. «Капитал» К. Маркса послужил классическим образцом системного исследования общества как целого и различных сфер общественной жизни, а воплощённые в нём принципы изучения органичного целого (восхождение от абстрактного к конкретному, единство анализа и синтеза, логического и исторического, выявление в объекте разнокачественных связей и их взаимодействия, синтез структурно-функциональных и генетических представлений об объекте и т. п.) явились важнейшим компонентом диалектико-материалистической методологии научного познания. Созданная Дарвином теория биологической эволюции не только ввела в естествознание идею развития, но и утвердила представление о реальности надорганизменных уровней организации жизни — важнейшую предпосылку системного мышления в биологии.   В 20 в. Системный подход занимает одно из ведущих мест в научном познании. Предпосылкой его проникновения в науку явился прежде всего переход к новому типу научных задач: в целом ряде областей науки центральное место начинают занимать проблемы организации и функционирования сложных объектов: познание начинает оперировать системами, границы и состав которых далеко не очевидны и требуют специального исследования в каждом отдельном случае. Во 2-й половине 20 в. аналогичные по типу задачи возникают и в социальной практике: техника всё более превращается в технику сложных систем, где многообразные технические и другие средства тесно связаны решением единой крупной задачи (например, космические проекты, человеко-машинные системы разного рода, см. Система «человек и машина»); в социальном управлении вместо господствовавших прежде локальных, отраслевых задач и принципов ведущую роль играют крупные комплексные проблемы, требующие тесного взаимоувязывания экономических, социальных и иных аспектов общественной жизни (например, проблемы создания современных производственных комплексов, развития городов, мероприятия по охране природы).   Изменение типа научных и практических задач сопровождается появлением общенаучных и специально-научных концепций, для которых характерно использование в той или иной форме основных идей Системный подход Так, в учении В. И. Вернадского о биосфере и ноосфере научному познанию предложен новый тип объектов — глобальные системы. А. А. Богданов и ряд других исследователей начинают разработку теории организации, имеющей широкое значение. Выделение особого класса систем — информационных и управляющих — послужило фундаментом возникновения кибернетики. В биологии системные идеи используются в экологических исследованиях, при изучении высшей нервной деятельности, в анализе биологической организации, в систематике. Эти же идеи применяются в некоторых психологических концепциях; в частности, гештальтпсихология вводит оказавшееся плодотворным представление о психологических структурах, характеризующих деятельность по решению задач; культурно-историческая концепция Л. С. Выготского, развитая его учениками, основывает психологическое объяснение на понятии деятельности, истолковываемом в системном плане; в концепции Ж. Пиаже основополагающую роль играет представление о системе операций интеллекта. В экономической науке принципы Системный подход получают распространение особенно в связи с задачами оптимального экономического планирования, которые требуют построения многокомпонентных моделей социальных систем разного уровня. В практике управления идеи Системный подход кристаллизуются в методологических средствах системного анализа.   Наряду с развитием Системный подход «вширь», т. е. распространением его принципов на новые сферы научного знания и практики, с середины 20 в. начинается систематическая разработка этих принципов в методологическом плане. Первоначально методологические исследования группировались вокруг задач построения общей теории систем (первая программа её построения и сам термин были предложены Л. Берталанфи). Однако развитие исследований в этом направлении показало, что совокупность проблем методологии системного исследования существенно превосходит рамки задач общей теории систем. Для обозначения этой более широкой сферы методологических проблем и применяют термин «Системный подход», который с 70-х гг. прочно вошёл в научный обиход (в научной литературе разных стран для обозначения этого понятия используют и другие термины — «системный анализ», «системные методы», «системно-структурный подход», «общая теория систем»; при этом за понятиями системного анализа и общей теории систем закреплено ещё и специфическое, более узкое значение; с учётом этого термин «Системный подход» следует считать более точным, к тому же он наиболее распространён в литературе на русском языке).   Системный подход не существует в виде строгой методологической концепции: он выполняет свои эвристические функции, оставаясь не очень жестко связанной совокупностью познавательных принципов, основной смысл которых состоит в соответствующей ориентации конкретных исследований. Эта ориентация осуществляется двояко. Во-первых, содержательные принципы Системный подход позволяют фиксировать недостаточность старых, традиционных предметов изучения для постановки и решения новых задач. Во-вторых, понятия и принципы Системный подход существенно помогают строить новые предметы изучения, задавая структурные и типологические характеристики этих предметов и т. о. способствуя формированию конструктивных исследовательских программ.   Значение критической функции новых принципов познания было убедительно продемонстрировано ещё Марксом, «Капитал» которого далеко не случайно носит подзаголовок «Критика политической экономии»: именно последовательная критика принципов классической политэкономии позволила раскрыть узость, недостаточность её исходной содержательно-концептуальной базы и расчистить путь для построения нового предмета этой науки, адекватного задачам изучения целостного функционирования и развития капиталистической экономики. Решение аналогичных задач выступает важным предварительным условием и при построении современных системных концепций. Например, переходу к конструированию современных технических систем и возникновению системотехники (которая выступила одной из важных конкретизаций Системный подход в области современной техники) предшествовали осознание и критика подхода, господствовавшего на прежних ступенях развития техники, когда «единицей» конструирования было отдельное техническое средство (машина, отдельное орудие и т. д.), а не целостная функция, как это стало теперь. Условием разработки эффективных мероприятий по защите окружающей среды явилась весьма последовательная критика прежнего подхода к развитию производства, игнорировавшего системную связь общества и природы. Утверждение системных принципов в современной биологии сопровождалось критическим анализом односторонности узкоэволюционистского подхода к живой природе, не позволявшего зафиксировать важную самостоятельную роль факторов биология, организации. Т. о., эта функция Системный подход носит конструктивный характер и связана прежде всего с обнаружением неполноты наличных предметов изучения, их несоответствия новым научным задачам, а также с выявлением недостаточности применяемых в той или иной отрасли науки и практики принципов объяснения и способов построения знания. Эффективное проведение этой работы предполагает последовательную реализацию принципа преемственности в развитии систем знания.   Позитивная роль Системный подход может быть сведена к следующим основным моментам. Во-первых, понятия и принципы Системный подход выявляют более широкую познавательная реальность по сравнению с той, которая фиксировалась в прежнем знании (например, понятие биосферы в концепции Вернадского, понятие биогеоценоза в современной экологии, оптимальный подход в экономическом управлении и планировании).   Во-вторых, Системный подход содержит в себе новую по сравнению с предшествующими схему объяснения, в основе которой лежит поиск конкретных механизмов целостности объекта и выявление достаточно полной типологии его связей (см. Связь). Реализация этой функции обычно сопряжена с большими трудностями: для действительно эффективного исследования мало зафиксировать наличие в объекте разнотипных связей, необходимо ещё представить это многообразие в операциональном виде, т. е. изобразить различные связи как логически однородные, допускающие непосредственное сравнение и сопоставление (такая задача была успешно решена, например, в экологии благодаря введению представления о пищевых цепях сообществ, позволившего установить измеримые связи между их разнообразными элементами).   В-третьих, из важного для Системный подход тезиса о многообразии типов связей объекта следует, что сложный объект допускает не одно, а несколько расчленений. При этом критерием обоснованного выбора наиболее адекватного расчленения изучаемого объекта может служить то, насколько в результате удаётся построить операциональную «единицу» анализа (такую, например, как товар в экономическом учении Маркса или биогеоценоз в экологии), позволяющую фиксировать целостные свойства объекта, его структуру и динамику.   Широта принципов и основных понятий Системный подход ставит его в тесную связь с др. общенаучными методологическими направлениями современной науки. По своим познавательным установкам Системный подход имеет особенно много общего со структурализмом и структурно-функциональным анализом, с которыми его роднит не только оперирование понятиями структуры и функции, но и акцент на изучение разнотипных связей объекта; вместе с тем принципы Системный подход обладают более широким и более гибким содержанием, они не подверглись слишком жёсткой концептуализации и абсолютизации, как это имело место с некоторыми линиями в развитии указанных направлений.   Будучи в принципе общенаучным направлением методологии и непосредственно не решая философских проблем, Системный подход сталкивается с необходимостью философского истолкования своих положений. Сама история становления Системный подход убедительно показывает, что он неразрывно связан с фундаментальными идеями материалистической диалектики, что нередко признают и многие из западных учёных. Именно диалектический материализм даёт наиболее адекватное философско-мировоззренческое истолкование Системный подход: методологически оплодотворяя его, он вместе с тем обогащает собственное содержание; при этом, однако, между диалектикой и Системный подход постоянно сохраняются отношения субординации, т. к. они представляют разные уровни методологии; Системный подход выступает как конкретизация принципов диалектики. Тема 3. Основные концепции улучшения бизнес-процессов Развитие взглядов на улучшение бизнес-процессов. 80-е года – в США началась первая волна программ по улучшению качества. Эти программы были направлены на улучшение выполнения сотрудниками своих задач с целью достижения «нулевого уровня дефектов». Основные действия данных программ: 1.Проведение командного мозгового штурма для определения проблем. 2.Подготовка диаграмм Парето для приоритизации проблем. 3.Вовлечение сотрудников. 4.Заявления о миссии качества. 5.Построение древовидных диаграмм для помощи в определении источников возникновения проблем. 6.Общие программы корректировки действия. 7.Регулярный контроль процессов, используемый для определения причин отклонений. 8.Минимизация затрат на хранение путем применения методов формирования запасов just-in-time и непрерывного производства. Недостатки: 1.80% проблем могут быть решены только руководством. 2.Затраты по реализации программы велики, так как требуется участие каждого члена организации. 3.Подход лучше реализуется в производственной отрасли. Вторая волна улучшений 90е года. Новая методология получила называние «Улучшение бизнес-процессов базируется на 4-х различных подходах, направленных на повышение производительности, эффективности и адаптируемости бизнес-процессов. C 2000 г. начинает быстро расти третья волна, которая получила название «Улучшение бизнес-систем» (УБС). УБС фокусируется на более крупных элементах организации. Среди типичных бизнес-систем можно выделить следующие: Системы управления качеством; Системы управления защиты окружающей среды; Системы управления финансами; Системы управления ценными бумагами; Системы управления программным обеспечением; Системы управления безопасностью; Системы управления информацией; Системы управления проектами Тема 4. Организация: Организация улучшения процесса Контактные группы не являются частью проекта по улучше­нию бизнес-процессов организации, они служат своего рода «резонатором» для команды по улучшению процесса. Для оценки работы команды по улучшению процесса контакт­ная группа будет рассматривать наиболее ценные нацелен­ные на будущее решения, разработанные командой по улуч­шению процесса, а также сопроводительную документацию, результаты проведенного анализа, запланированные улучше­ния, прибыль на инвестированный капитал. Они могут так­же давать технические рекомендации, относящиеся к опреде­ленному инструментуПроект по улучшению бизнес-процессов должен быть разработан d соответствии со структурой организации. В проект вовлекается большое количество отделов и направлений (линейный менеджмент, члены адми­нистративного аппарата, эксперты по административной организации). Эффективным подходом организацию временной отдельной структуры проекта делают два момента: требуемая вовлеченность сотрудников в про­ект (сотрудники должны иметь возможность полностью посвятить себя проекту) и случайный выбор характера мероприятий. Команда по управлению проектом по улучшению бизнес-процессов (Project Management Team - РМТ) создается для управления и координации мероприятий по улучшению биз­нес-процесса, которые проводятся в рамках организации. Команда по улучшению процесса (Process Improvement Team - PIT) - команда, работающая над проектом по улуч­шению определенного процесса. В такую команду обычно входят люди, представляющие различные отделы. Команда по улучшению процесса отчитывается перед командой по уп­равлению проектом для управления и поддержки. Работа по организации проекта происходит в ходе его реализации и прекращается сразу по его завершении. В процессе организации проекта создается команда для контроля и отслеживания всего проекта по улуч шению бизнес-процессов. Эта команда называется «команда по управлению проектом по улучшению бизнес-процессов» (Project Management Team (РМТ)). Кроме того, каждый раз для изучения нового административно­го бизнес-процесса создается новая группа, работающая над проектом, называемая «команда по улучшению процесса» (PIT). Команда по управлению проектом по улучшению бизнес-процессов является высшей инстанцией в организационной структуре проекта. Руководство делегирует полномочия по проекту по улучшению бизнес-процессов команде по управлению проектом. Иногда управленческая коман­да будет исполнять роль команды по управлению проектом. Команда по управлению проектом ответственна за качество результатов по всему про­екту, лидер команды по управлению проектом является ответственным сотрудником. Члены команды по управлению проектом должны иметь полномо­чия для принятия управленческих решений. Этих полномочий должно быть достаточно для выполнения задач, перечисленных в этом разделе. Организация должна приступать к осуществлению проекта по улучше­нию бизнес-процессов, только если нет сомнений в том, что ему обеспече­на полная поддержка со стороны высшего руководства. Лидером команды по управлению проектом обычно становится пред­ставитель руководства. Кроме того, членами этой команды должны быть ключевые функциональные менеджеры. Если в проект вовлечено менее четырех-пяти отделов, в него также могут быть включены менеджеры от­делов. В проекте может также принять участие менеджер отдела персонала. Если в административных бизнес-процессах используется или будет использоваться компьютерная обработка данных, желательно, чтобы в команде были представлены отделы управления информацией и разра­ботки систем. Если в организации существует административный отдел, он также должен быть представлен в команде. Иногда оказывается полезным включить в состав команды одного или нескольких представителей команды по улучшению процесса (см. Раздел 2.4). Рисунок 2.В" представляет пример объединения команды по управлению проектом и контактных групп. В обязанности команды по управлению проектом входит выбор целей проекта и контроль за их реализацией. Команда по управлении проектом несет ответственность за управление затратами и временем в рамках проекта, а также занимается внедрением проекта в организации и связанными с ним последствиями, которые включают как исполне­ние проекта (управление временем служащих), так и внедрение результа­тов (управление тем, как действующая организация принимает усовер­шенствованные процедуры). Другим важным аспектом управления про­ектом является создание условий, при которых проект может оптимально функционировать. Важнейшими задачами команды по управлению проектом являются: • Организация проекта • Планирование фаз проекта • Принятие окончательного решения относительно предложений, внесенных командой по улучшению процесса на различных фа­зах проекта (включенная в процесс принятия решения, она оп­ределяет административные бизнес-процессы, которые должны быть улучшены, выбирает методы и методики, которые будут использованы, устанавливает приоритеты и т.д.) • Одобрение окончательного предложения по проекту • Распространение информации о проекте в рамках организации • Формирование и управление командой (командами) по улучше­нию процесса и контактной группой (группами) (команда по управлению проектом определяет функции и задачи этих групп) • Отслеживание хода работ • Управление возможностью сотрудника участвовать в проекте • Определение бюджета и процедуры аудита • Одобрение предложенного наиболее ценного нацеленного на бу­дущее решения • Согласование проекта с повседневной операционной деятельно­стью и другими проектами, осуществляемыми в рамках органи­зации (такими, как проекты компьютеризации) Тема 5. Структуризация и описание деятельности компании Классификация бизнес-процессов. При описании бизнес-процессов на этапе описания деятельности "как есть" получается большое количество работ. Для того, что бы повысить эффективность обработки большого количества информации, работы нужно правильно структурировать. Для этого бизнес-процессы, существующие в компании делят на четыре группы, каждая из которых обладает своими отличительными особенностями (рис. 11.): • Основные бизнес-процессы – генерируют доходы компании; • Обеспечивающие бизнес-процессы – поддерживают инфраструктуру компании, • Бизнес-процессы управления – управляют компанией, • Бизнес-процессы развития – развивают компанию. Рис. 11. Классификация бизнес-процессов. Нужно отметить, что данных подход классификации бизнес-процессов является одним из часто используемых на практике. Далее будут рассмотрены другие современные способы классификации процессов, которые имеют много схожего с данным. Давайте рассмотрим, что представляют из себя каждая группа процессов - основных, обеспечивающих, управленческих и процессов развития. Понятия "декомпозиция" и "критерии декомпозиции". Давайте рассмотрим первый шаг описания организации, на котором разрабатывается перечень бизнес-направлений. Для правильной разработки данного перечня полезно рассмотреть и использовать понятия "декомпозиция" и "критерий декомпозиции". Что это такое? Декомпозиция - это разбиение объекта на составные части. Критерий декомпозиции - это характеристика, на основе которой производится разбиение. Давайте рассмотрим эти понятия на примере структуризации шаров. Имеется исходная ситуация: есть шары двух цветов - белые и черные, при этом эти шары сделаны из различных материалов - дерева и железа. Поставлена задача: структурировать шары и построить их иерархическое дерево. Существует три подхода к решению данной задачи. Первый подход - можно разделить все шары на белые, черные, деревянные, железные и построить дерево шаров, изображенной на рис. 2. Рис. 2. Первый вариант дерева шаров. При втором подходе шары сначала делятся по цвету на белые и черные, а потом делятся по материалу на деревянные и железные. Возможен и третий подход. Шары сначала делятся по материалу, а потом по цвету. В данных случаях материал и цвет являются критериями декомпозиции (рис. 3.). Рис. 3. Второй и третий варианты дерева шаров. Оказывается, что первый подход построения дерева шаров является неправильным, так как в нем элементы пересекаются - каждый шар относится одновременно к двум элементам дерева. Это вызвано тем, что в данном подходе при структуризации шаров были одновременно применены два критерия декомпозиции. Второй и третий подходы являются правильными, так как в них критерии декомпозиции были применены последовательно и различие между ними связано с различием в последовательности их применения. Отсюда вытекают два важных правила, которые нужно применять при структуризации деятельности компании. Правило 1. На одном уровне нужно применять только один критерий декомпозиции. Правило 2. Для одной системы можно построить несколько вариантов "деревьев" в зависимости от различной последовательности применения возможных критериев декомпозиции. При этом на верхнем уровне нужно использовать более существенные критерии декомпозиции. В статье мы будет использоваться понятие "классификатор", которое по своей природе является синонимом понятия "дерево". Описание бизнес-направлений компании завершается построением их иерархического дерева или классификатора (рис. 4). Рис. 4. Иерархическое дерево / классификатор бизнес-направлений компании. Тема 6. Выделение и ранжирование бизнес-процессов Определение критических факторов успеха организации (КФУ)     Для оценки важности бизнес-процессов существует классический подход, согласно которому первым шагом определения важности является определение критических факторов успеха организации - КФУ. Что такое КФУ? При разработке стратегии, компания должна формулировать свою миссию, после чего произвести ее декомпозицию на стратегические цели. Из всех сформулированных целей нужно выбрать восемь наиболее важных, которые называют критическими факторами успеха (см. рис.2). Использование именно восьми наиболее важных стратегических задач следует из принципа существенности, или Парето, а также правила "7", которые были рассмотрены в предыдущих главах книги. Рисунок 2. Критические факторы успеха организации - КФУ      Для более глубокого понимания того, что такое критические факторы успеха давайте рассмотрим их определение и примеры.      Критические факторы успеха – это те стратегические задачи, конкурентные возможности, результаты деятельности, которые каждая компания должна обеспечивать или стремиться к этому, чтобы быть конкурентоспособной и добиться успеха на рынке. Это те факторы, которым компания должна уделять особое внимание, так как именно они определяют успех или провал компании на рынке, ее конкурентные возможности, непосредственно влияющие на ее прибыльность.      Определение критических факторов успеха организации с учетом существующих и прогнозируемых тенденций развития отрасли и конкуренции в ней является важнейшей стратегической задачей. Компания должна знать отрасль достаточно хорошо, чтобы определить, что является более, а что менее важным для успеха в конкурентной борьбе. Те руководители, которые неправильно определили влияние факторов на обеспечение долгосрочного успеха в конкурентной борьбе, выбирают ошибочные стратегии или не достаточно важные для обеспечения конкурентоспособности цели. Компании, правильно определившие критические факторы успеха, могут достичь значительного конкурентного преимущества, учитывая КФУ при реализации своей стратегии и обеспечивая себе преимущество перед конкурентами с использованием этих факторов. Критические факторы успеха в разных отраслях и для разных бизнесов различны. Кроме того, они со временем могут меняться в одной и то же отрасли под влиянием изменений общей ситуации в ней.      В общем случае критические факторы успеха должны отвечать следующим критериям: • Являются самыми важные целями компании; • Являются тем, что должна сделать организация, чтобы выполнить свою миссию; • Как правило, начинаются со слов "мы должны …" или "нам нужно… • Представляют комбинацию тактических и стратегических факторов.      Примером критических факторов успеха для торговой компании является формулировка: "Мы должны иметь самый широкий ассортимент среди предприятий нашей отрасли", а для производственного предприятия - "Мы должны иметь самую высокую степень использования производственных мощностей в нашей отрасли".      При разработке критических факторов успеха, нужно соблюдать правило необходимости и достаточности, согласно которому каждый критический фактор успеха, включенный в список, необходим для достижения миссии компании, а все вместе факторы должны быть достаточны для ее достижения. Сопоставление бизнес-процессов и критических факторов успеха     Вторым шагом определения степени важности бизнес-процессов, является, их сопоставление с критическими факторами успеха. Основная суть сопоставления сводится к тому, что по каждому бизнес-процессу нужно ответить на следующий вопрос: "Какие критические факторы успеха поддерживает данный бизнес-процесс"?      Раннее было рассмотрено, что важность процесса определяется степенью его вклада в достижение стратегических целей компании, поэтому чем больше критических факторов успеха поддерживает рассматриваемый бизнес-процесс, тем больше его важность.      На рис. 3 при поиске взаимосвязи между процессами и КФУ был применен прямой проход "снизу вверх" или "от процессов к КФУ". На практике необходимо проделать и обратный проход "сверху вниз" или "от КФУ к процессам", при котором для каждого критического фактора успеха определяются бизнес-процессы, их поддерживающие. Второй проход повысит качество получаемых результатов, а также поможет выявить бизнес-процессы, которых в компании на данный момент времени не существует, но для реализации стратегии они необходимы.      Для определения взаимосвязи между КФУ и процессами при обратном проходе "сверху вниз" для каждого критического фактора успеха нужно задать три взаимодополняющих вопроса: • Какие из бизнес-процессов должны быть выполнены особенно хорошо, чтобы мы были уверены в достижении конкретного критического фактора успеха? • Какие бизнес-процессы оказывают основное воздействие на конкретный критический фактор успеха? • Какие бизнес-процессы не только имеют отношение к конкретному критическому фактору успеха, но и важны для него? Рисунок 3. Сопоставление бизнес-процессов и критических факторов успеха Ранжирование и выбор приоритетных бизнес-процессов     После расчета степени возможности проведения изменений в бизнес-процессах эту величину нужно ввести в матрицу ранжирования как третье измерение, в результате чего получиться трехмерный куб, из которого нужно выбрать бизнес-процессы, являющиеся самыми важными, самыми проблемными и обладающие высокой степенью возможности проведения изменений.     На практике построение и применение трехмерной матрицы ранжирования, представляющей из себя трехмерный куб, является задачей проблематичной, так как не все могут одинаково хорошо ориентироваться в трехмерном пространстве. Поэтому задачу ранжирования и выбора приоритетных бизнес-процессов на основе трех критериев решают с использованием таблицы ранжирования (см. табл. 4). Итоговый показатель, характеризующий приоритетность бизнес-процесса вычисляется как сумма трех рассчитанных ранее степеней важности, проблемности и возможности проведения изменений. Напомним, что степень важности процесса измеряется по шкале от 1 до 8, а степени проблемности и возможности проведения изменений по шкале от 1 до 5. В результате полученная степень приоритетности бизнес-процесса может лежать в диапазоне от 3 до 18. Тема 7. Типовые бизнес-процессы и функции управления     Модель цепочки добавления ценности (Value Chain Model ) разработана Майклом Портером в 1985 году (Гарвардская бизнес-школа). Модель цепочки добавления ценности рассматривает компанию как цель базисных действий, каждое из которых добавляет ценность продукту, а оптимизация этих базисных действий максимизирует прибыль и/или минимизирует затраты. Эта модель включает процессы, приведенные на рисунке 1. Рисунок 1. Перечень бизнес-процессов верхнего уровня модели цепочки добавления ценности      Эта цепочка моделирует как основную, так и вспомогательную деятельность компании. Основная деятельность связана с производством и дистрибуцией продукции компании. Вспомогательная деятельность помогает выполнять основную деятельность. Модель IBL (The International Business Language)     Концепция цепочки добавления потребительской ценности (Value Chain Model) была предложена профессором Гарвардской школы бизнеса Майклом Портером в 1985 году и в настоящее время широко используется при совершенствовании деятельности компаний для повышения их конкурентоспособности.     Эта модель рассматривает компанию как цель базисных действий, каждое из которых добавляет ценность продукту, а оптимизация этих базисных действий максимизирует прибыль и/или минимизирует затраты.     Цепочка добавления ценности моделирует как основную, так и вспомогательную деятельность компании. Основная деятельность связана с производством и дистрибуцией продукции компании. Вспомогательная деятельность помогает выполнять основную деятельность.     Для того, что бы обеспечить распространение передового опыта компания PriceWaterhouseCoopers адаптировала данную концепцию для ее использования при классификации и структуризации бизнес-процессов и разработала на основе этой концепции "Международный язык бизнеса" (The International Business Language - IBL), который позволяет анализировать и сопоставлять на единой основе процессы в различных сферах деятельности. Процессы цепочки добавления ценности непосредственно влияют на продукт или услугу, предоставляемую клиенту. Эта модель включает процессы, приведенные на рисунке 1. Рисунок 1. Перечень бизнес-процессов верхнего уровня Модели IBL Тринадцати процессная модель     Тринадцати процессная модель разработана Американским центром производительности и качества (American Productivity&Quality Center). Эта модель включает процессы, приведенные на рисунке 1. Рисунок 1. Перечень бизнес-процессов верхнего уровня тринадцати процессной модели Восьми процессная модель Восьми процессная модель разработана консалтинговой компании BKG Profit Technology и предназначена для использования в проектах описания, анализа и оптимизации бизнес-процессов предприятия. Модель может применяться как основа для последующей адаптации на конкретном предприятии. Принцип построения модели заключается в выделении основных объектов управления бизнес-системы и проектировании процессов управления этими объектами, приведенных в таблице 1. Таблица 1. Объекты управления и соответствующие им бизнес-процессы верхнего уровня № Объект управления Бизнес-процесс верхнего уровня 1. Бизнес-система (бизнес-процессы, стратегия развития) Выработка согласованных условий деятельности 2. Персонал Воспроизводство трудовых ресурсов 3. Ресурсы Материально-техническое обеспечение 4. Продукт Разработка и модификация продуктов 5. Технология Воспроизводство средств производства 6. Клиент Продвижение и продажи 7. Производственный цикл Производство продукции 8. Финансы Финансирование деятельности и расчеты по обязательствам Результатом выполнения бизнес-процессов верхнего уровня является объект управления, приведенный в требуемое состояние. Бизнес-процессы верхнего (первого) уровня декомпозируются на подпроцессы второго, третьего и так далее уровней, необходимых для последовательной трансформации состояния объекта управления из начального в требуемое. Тема 8. Технология моделирования и описания бизнес-процессов Горизонтальное и вертикальное описание бизнес-процессов В данном разделе будет рассмотрен второй более сложный инструмент, применяемый при описании бизнес-процессов который называется горизонтальным описанием. Его приходится использовать, в случае если вертикального описания недостаточно. Что это за инструмент? - В первом случае при описании бизнес-процессов показывались только работы, из которых процесс состоит, а также их иерархия. Часто этой информации бывает недостаточно для того, чтобы провести качественный анализ и оптимизацию деятельности компании. В этом случае нужно использовать горизонтальное описание бизнес-процессов. При вертикальном описании показывают только работы и их иерархический порядок в дереве бизнес-процесса. В этом случае имеются только вертикальные связи между родительскими и дочерними работами. При горизонтальном описании бизнес-процесса также показываются, как эти работы между собой взаимосвязаны, в какой последовательности они выполняются, какие информационные и материальные потоки между ними движутся. В этом случае в модели бизнес-процесса появляются горизонтальные связи между различными работами, которые процесс составляют (рис. 1). Рис. 1. Горизонтальное и вертикальное описание бизнес-процессов Специалисты по организационному проектированию используют различную терминологию при описании бизнес-процессов. Например, вертикальное описание бизнес-процессов некоторые называют функциональным описанием деятельности, а горизонтальное описание – процессным описанием или просто описанием бизнес-процессов. Способы описания бизнес-процессов Давайте рассмотрим основные подходы к горизонтальному описанию бизнес-процессов. В настоящее время существуют три основных способа описания (рис. 2). Первый способ – есть не что иное как текстовое последовательное описание бизнес-процесса. Примером текстового описания фрагмента бизнес-процесса является следующий текст: «Отдел продаж составляет договор и согласует его с Юридическим отделом». Многие российские компании разработали и используют в своей деятельности регламентирующие документы, часть из которых является процессными регламентами и представляет не что иное как текстовое описание бизнес-процессов. Для целей анализа и оптимизации деятельности компании данный не подходит. Дело в том, что описание бизнес-процесса в текстовом виде системно рассмотреть и проанализировать невозможно. Текстовая информация воспринимается человеческим мозгом последовательно. Например, когда человек читает регламент, и доходит до его конца, практически всегда он забывает про то, что было в начале документа. Второй недостаток текстового представления бизнес-процесса связан с тем, что человеческое сознание устроено так, что оно эффективно может работать только с образами. При восприятии и анализе текстовой информации человеческий мозг раскладывает ее на ряд образов, на что уходит дополнительно временя и умственные усилия. Поэтому при использовании текстового описания бизнес-процессов производительность и качество решений по оптимизации деятельности оставляют желать лучшего, что особенно сильно проявляется, когда решение принимается группой людей. В свое время специалисты по информационным технологиям разработали более структурированный подход к описанию бизнес-процессов. Ими было предложено разбить бизнес-процесс по ячейкам структурированной таблицы, в которой каждый столбец и строчка имеют определенное значение. Данную таблицу читать более просто, из нее легче понять, кто за что отвечает, в какой последовательности в бизнес-процессе выполняются работы, и соответственно бизнес-процесс проще проанализировать. Табличная форма описания бизнес-процессов более эффективна по сравнению с текстовой и в настоящее время активно применяется специалистами по информационным технологиям для описания бизнес-процессов в приложении к задачам автоматизации. В последнее время интенсивно стали развиваться и применяться при описании бизнес-процессов графические подходы. Признано, что графические методы обладают наибольшей эффективностью при решении задач связанных с описанием, анализом и оптимизацией деятельности компании. Оказалось, что графика хороша тем, что графическая информация, расположенная в поле зрения человека, воспринимается его мозгом одновременно. Второе преимущество связанно с тем, что менеджер, является человеком с правополушарным мышлением и мыслит в виде образов. Любую текстовую информацию он раскладывает в образы. В случае, когда ему представляется информация в виде графических образов, значительно возрастают его возможности по анализу и принятию решений. В книге преимущественно будут рассматриваться именно графические подходы к описанию процессов, так как именно они себя хорошо зарекомендовали и их можно эффективно использовать для оптимизации деятельности организации. Рис. 2. Способы описания бизнес-процессов Классификация входов и выходов бизнес – процесса При описании окружения бизнес-процесса приходится его входы и выходы делить на два типа: первичные и вторичные. В результате такого деления получаются первичные и вторичные входы, а также первичные и вторичные выходы. Это делается для того, что бы не нарушать принцип Парето 20 на 80. Дело в том, что когда описывается окружение бизнес-процесса количество различных входов и выходов оказывается очень большим, в результате чего описанное окружение получается чрезвычайно больший и насыщенным. На это уходит много времени и сил и при этом малосущественная для анализа и принятия решения информация будет сильно мешать, что в дальнейшем может привести к не успешности проекта по оптимизации деятельности компании. Для того, что отделить существенное от несущественного используется деление входов и выходов бизнес-процесса на первичные и вторичные. Для этого что бы провести такое разделение нужно воспользоваться следующими определениями, приведенными в таблице 1 и примерами. Таблица 1. Характеристики первичных и вторичных входов и выходов бизнес-процесс. Элемент Определение и характеристики Первичный выход • Основной результат, ради которого существует бизнес--процесс. • Определяется целью, назначением бизнес-процесса. Вторичный выход • Побочный продукт бизнес-процесса, который может быть востребован вторичными клиентами. • Не является основной целью бизнес-процесса. Первичный вход • Поток объектов, инициирующий "запуск" бизнес-процесса - заказ клиента, план закупок и т.д. Вторичный вход • Потоки объектов, обеспечивающие нормальное протекание бизнес-процесса – стандарты, правила, механизмы выполнения действий, оборудование и пр. Первичный вход - это вход, который инициирует начало бизнес-процесса. В примере с бизнес-процессов "Комиссионирование" заявка на набор заказа является первичным входом. В данном процессе при наборе заказа наборщицы, которые набирают заказ используют тару, которая тоже являются входом, но это вход вторичный, он не инициирует бизнес-процесс. При описании бизнес-процесса нужно сделать акцент описание первичных входов и показать их. Про вторичные входы можно забыть. Они будут автоматические описаны при дальнейшей детализации процесса, так как на более низком уровне найдутся операции, для которых данные входы являются первичными. То же самое относится и к выходам. Первичным выходом называют такой выход, ради которого процесс существует. В примере с бизнес-процессом "Комиссионирование" первичным выходом является собранный заказ. При выполнении данного бизнес-процесса имелись и другие выходы. Если складская ячейка, содержащая определенную товарную позицию оказывалась пуста, то наборщица информировала об этом складских рабочих в чьи обязанности входит бизнес-процесс "Подпитка ячеек". Эта информация также является выходом, но этот выход не является первичным для бизнес-процесса "Комиссионирование", ради него процесс не существует. Следовательно он является вторичным. Данный инструментарий первичности-вторичности нужно использовать для того, чтобы упростить, ускорить и повысить качество работ по описанию и оптимизации деятельности компании. Правило его использования следующее. При описании окружения бизнес-процесса нужно сделать акцент на описание его первичных входов и выходов. Вторичные входы и выходы нужно описывать на более детальном уровне, когда найдутся подпроцессы, для которых эти входы и выходы станут первичными. Построение сети бизнес-процессов В проекте по описанию и оптимизации деятельности организации целесообразно разработать DFD-схему на самом верхнем уровне – уровне компании в целом. В статье "Технология структуризации и описание организации – шаг за шагом" (Консультант директора №8 (212), Апрель, 2004). было рассмотрено, что при выделении бизнес-процессов разрабатывается дерево бизнес-процессов, в котором процессы классифицируются на основные, обеспечивающие и управленческие. Основной задачей данной классификации является облегчение работы по выделению процессов, снижение вероятности пропуска важных процессов, а также наглядное представление выделенных бизнес-процессов, разбитых на небольшие группы. Другим наглядным представлением бизнес-процессов компании является сеть процессов, которая представляет DFD-схему, построенную на основе бизнес-процессов, составляющих дерево. При построении окружения бизнес-процесса были описаны входы и выходы. Вход и выход каждого бизнес-процесса соответственно является выходом и входом для другого бизнес-процесса или внешнего субъекта, с которыми взаимодействует организация. Взаимодействия между бизнес-процессами, составляющими дерево показываются с помощью сети процессов (рис. 7). Рис. 7. Разработка сети бизнес-процессов Иерархические связи и классификация бизнес-процессов на сети процессов не показывается для того, что бы не загромождать модель. В отличие от дерева бизнес-процессов сеть процесса дает более полное системное представление о деятельности организации, так как позволяет показать не только элементы организации, но и взаимодействия между ними. Помимо этого сеть процессов обеспечивает проверку разработанной модели деятельности организации на целостность, правильность выделения бизнес-процессов и описания их окружения. Если выход одного из бизнес-процессов, например документ, нигде далее не используется, то есть не является входом для другого бизнес-процесса или внешнего субъекта, то это означает следующее. Первое – описанный выход бизнес-процесса является либо ошибочным, либо лишним. В противном случае нужно найти бизнес-процесс для которого данный выход является входом и доработать схему окружения этого бизнес-процесса. На практике сеть процессов часто называют сетью или схемой взаимодействия бизнес-процессов. Отличие сети процессов от классической схемы DFD состоит в том, что на сети нужно показать внешние субъекты, с которым взаимодействуют бизнес-процессы компании – клиенты, поставщики, банки и др. На рис. 8 приведено пример сети бизнес-процессов для производственной компании. Рис. 8. Пример сети бизнес-процессов Семь "золотых" правил описания бизнес-процессов Сама по себе методология описания бизнес-процессов довольно проста, но ее эффективное применение на практике не является простой задачей. Подводные камни, появляющиеся при описании бизнес-процессов компании могут свести эффективность этой работы на нет. Возникновение подводных камней связано с человеческим фактором, так как большинство сотрудников компании не заинтересованы в проведение подобных работ в их организации. Описание бизнес-процессов дает ответы на вопросы, кто чем занимается в компании и кто за что отвечает. Это делает компанию прозрачной и подконтрольной руководству. Прозрачность в первую очередь выгодна руководителям организации, при этом она заставляет всех сотрудников работать на цели организации в ущерб их личным интересам. Более того описание бизнес-процессов и повышение прозрачности позволяет выявить излишки финансовых и временных ресурсов, которые "припасли" сотрудники" на крайний случай. Поэтому основная часть сотрудников не заинтересована в этой работе и при описании деятельности компании постоянно возникают сопротивления, препятствующие получению реальной информации о том, кто чем в компании занимается и кто за что отвечает. Что бы уменьшить сопротивления незаинтересованных сторон описанию бизнес-процессов нужно использовать "золотые" правила, которые были выведены из практического опыта проведения подобных работ. Правило 1. Составляйте, уточняйте, подтверждайте схемы вместе с "владельцами"/"участниками" бизнес-процессов. К работе по описанию бизнес-процессов нужно активно привлекать специалистов, которые участвуют в этом процессе и отвечают за эффективность их выполнения. Во первых, это ускорит работу и повысит качество результатов, так как кроме самих участников процесса никто другой лучше не знает как бизнес-процесс происходит на самом деле. Во вторых, на основании разработанный описаний в дальнейшем будет проводится оптимизация и проведение изменений бизнес-процессов. Одним из главных правил эффективного проведения изменений является вовлечение на ранних стадиях в эти работы сотрудников участвующих в процессе и чья деятельность будет затронута изменениями. Правило 2. Используйте визуальные подходы описания бизнес-процессов, способствующие повышению эффективности работы в группе. При описании бизнес-процессов нужно оперативно фиксировать и визуализировать полученную информацию. Работая в группах, можно использовать флипчарт или доску, на которых в процессе работы рабочей группы будет разрабатываться и фиксироваться описание бизнес-процесса. Большой эффективностью обладает подход, связанный с использование мультимедийного проектора при помощи которого изображение схемы бизнес-процесса разрабатываемого с помощью специализированного программного обеспечения выводится на экран в режиме реального времени. Правило 3. Используйте язык, понятный "владельцам"/"участникам" бизнес-процесса. При описании бизнес-процессов нужно использовать тот язык, ту терминологию, которые приняты в организации. В каждой компании есть своя специфика, есть свои устоявшиеся названия бизнес-процессов, функций, документов и отделов. Поэтому рекомендуется использовать устоявшуюся терминологию. Это сделает схемы бизнес-процессов понятными для всех участников процесса, что с экономит много времени при их согласовании, анализе и оптимизации. Правило 4. Создавайте схемы деятельности, а не организационных структур. При описании бизнес-процессов нужно "забыть" про существующую организационную структуру и не использовать ее как средство выделения бизнес-процессов и работ. Бизнес-процессы строятся на основе стратегии, а организационная структура подстраивается под них, но не наоборот. Именно поэтому организационная структура описывается и накладывается на бизнес-процессы в последний момент. Факт того что, она будет не состыковываться с процессами говорит об ее неоптимальности. Если пренебречь этим правилом и в качестве средства выделения бизнес-процессов и работ использовать действующую оргструктуру, то вероятность того, что разработанные описания бизнес-процессов будут искажены в случае неоптимальной организационной структуры достаточно велика. Давайте рассмотрим пример одной компании, в которой сотрудники описывали бизнес-процесс "Поставка товара от поставщика". При проведении этих работ встал вопрос, что является границей этого бизнес-процесса. Одна группа специалистов предложила в качестве конечной границы бизнес-процесса "Поставка" рассматривать факт того, что поставленный товар находится в свободной продаже, и сбытовые подразделения могут его продавать. Специалисты отдела закупок, которые в большей степени участвовали в этом бизнес-процессе пытались "натянуть" этот бизнес-процесс под организационные границы ответственности своего отдела и доказывали, что границей процесса "Поставка" является факт того, что товар закуплен и доставлен к воротам склада. Во втором варианте определения границы бизнес-процесса "Поставка" в качестве средства использовалась действующая организационная структура, что является не правильным, так как на данном этапе ничего не известно о степени ее оптимальности. Правило 5. Избегайте излишней детализации бизнес-процессов, особенно на схеме "как есть". Одной из проблем возникающих при описании бизнес-процессов является нарушение оптимального уровня детализации, которое приводит к значительному увеличению объема работ. При этом излишняя детализация не только не дает дополнительного эффекта согласно закону Парето 20 на 80, она приводит к отрицательным последствиям, связанным с информационной перегруженностью участников проекта, снижает качество результатов работ и часто приводит к не успеху всего мероприятия. В данном случае нужно помнить еще об одном правиле – чем большие изменения планируется провести при оптимизации бизнес-процесса, тем менее детальное описание бизнес-процесса "как есть" должно быть разработано. Правило 6. Избегайте составления схемы бизнес-процесса ради схемы, не ведущей к дальнейшему анализу и действиям. Инструментарий по описанию бизнес-процессов, который был рассмотрен, является всего лишь инструментом для достижения более высоких целей оптимизации и улучшения бизнес-процессов. При проведении данных работ постоянно нужно помнить о настоящих целях, а не зацикливаться на инструментарии и разработке схем. Довольно часто встречается следующая ситуация. В компании начинают описывать бизнес-процессы, всем эта работа очень нравится, все строят схемы бизнес-процессов и организационной структуры и никому не хочется прекращать это интересное и приятное занятие. В данном случае акцент смещается с решения проблем на разработку схем. Поэтому нужно постоянно помнить, что конечная цель - оптимизация, а описание – это инструмент, который нужно рассматривать как средство достижения цели. Давайте рассмотрим пример описывания бизнес-процессов в одной компании c целью подготовки предприятия к внедрению интегрированной информационной системы. При описании бизнес-процессов использовалась методология IDEF0. Специалисты, занимающиеся описанием бизнес-процессов долго выясняли между собой отношения решая, возникший спорный вопрос - к чему отнести накладную, пришедшую с товаром от поставщика при описании окружения бизнес-процесса "Приемка товара". Одни считали, что накладная является входом для бизнес-процесса, другие считали, что управлением. На спор ушло две недели рабочего времени, при этом каждый остался при своем мнении. Правило 7. Не смешивайте понятия "как есть", " как должно быть", "как будет". При описании бизнес-процессов нельзя смешивать понятия "как есть", "как должно быть" и "как будет". Согласно технологии оптимизации бизнес-процессов первым шагом является это описание процесса "как есть". Поэтому нужно описывать только те работы, только ту организационную структуру, которая существуют на самом деле, невзирая на их "кривизну". Часто при интервьюировании сотрудники, чья деятельность описывается, начинают фантазировать и рассказывать вещи, сильно отличающиеся от реальной действительности. Когда их спрашиваешь почему они поступают таким образом, они отвечают, потому что именно так должно быть, по их мнению. В результате этого построенные схемы бизнес-процессов не соответствуют действительности, что искажает информацию и уменьшает возможность проведения эффективной оптимизации бизнес-процессов. Тема 9. Стандарты и методологии описания бизнес-процессов Построение диаграмм потоков данных - DFD Стандарт описания бизнес-процессов DFD - Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня. На диаграмме потоков данных показываются работы, которые входят в состав описываемого бизнес-процесса, а также показываются входы и выходы каждой из работ. Данные входы и выходы представляют из себя информационные, либо материальные потоки. При этом выходы одной работы могут являться входами для других. Входы и выходы, которые были показаны при описании окружения бизнес-процесса являются внешними. Внешние входы на DFD–схеме поступают из вне от поставщика процесса, а внешние выходы уходят наружу к клиенту процесса. При построении DFD-схемы бизнес-процесса их нужно перенести со схемы окружения процесса DFD-диаграмму. Для окончательного описания бизнес-процесса остается описать только внутренние информационные и материальные потоки. Каждый из них является выходом одной из работ и в то же является входом для другой (рис. 4). Рис. 4. Диаграмм потоков данных - DFD При построении DFD-схемы бизнес-процесса нужно помнить, что данная схема показывает потоки материальных и информационных потоков и ни в коем случае не говорит о временной последовательности работ. В большинстве случаев временная последовательность работ совпадает с направлением движения потоков в бизнес-процессе. В общем случае это не верно, так как могут быть случаи подобные примеру, приведенном на рис. 5. Рис. 5. Пример несовпадения временной последовательности работ и направления движения документа В данном примере вторая работа по времени начала выполняться раньше первой работы, но документ движется от первой работы ко второй. Именно поэтому стандарт DFD удобен для описания бизнес-процессов верхнего уровня или макропроцессов, при описании которых в общем случае невозможно указать временную последовательность работ, так как все работы выполняются одновременное или существует несколько вариантов различных последовательностей, которые к тому же могут зависеть и от различных точек зрения. Давайте рассмотрим пример бизнес-процесса, приведенного на рис. 6. Рис. 6. Пример бизнес-процесс верхнего уровня Если компания использует схему работы "на склад", то на вопрос что происходит раньше закупка продукции или ее продажа могут быть даны два различных ответа в зависимости от двух различных ситуаций. Если конкретный продукт имеется на складе, то его закупка по времени первичней, чем продажа. Если, при обращении клиента продукции на складе нет и клиент готов подождать пока будет произведена закупка, то процесс продажи начинается по времени раньше, чем закупка, а заканчивается позже. Поэтому при описании данного бизнес-процесса и подобных ему процессов целесообразно использовать DFD стандарт, который не делает акцент на временную последовательность работ. При построении DFD-схемы бизнес-процесса также нужно показать подразделения и должности участвующие и отвечающие за выполнение работ, входящие в состав процесса. Рекомендуется каждой работе присвоить номер или идентификатор, а также использовать два правила при формулировке названия работ. Правило 1. Названия работы нужно формулировать согласно следующее формуле. Название работы = Действие + Объект на которым действие осуществляется Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать "Продажа продукции", а еще лучше конкретизировать что это за продукция. В данном случае "Закупка" это действие, а "продукция" - объект над которым действие по продаже производится. Правило 2. При формулировании названия работы нужно стараться использовать краткую и лаконичную формулировку, что повысит эффективность дальнейшей работы по оптимизации бизнес-процесса. Идеальным вариантом является случай когда название работы формулируется при помощи 2-3 слов. В крайнем случае нужно стремится использовать в названии не более 50 символов. В сложных случаях также рекомендуется для каждого краткого названия работы сделать ее подробное описание, которое поместить в глоссарий. При формулировании названий материальных и информационных потоков также нужно использовать подобные правила. В данном случае второе правило используется без изменений, а первое правил формулируется следующей формулой: Название потока = Объект, представляющий поток + Статус объекта Например, если речь идет о продукции, которую отгрузили клиенту, то данный поток нужно сформулировать следующим образом – "Продукция, отгруженная" или "Продукция, отгруженная клиенту". В данном случае "Продукция" это объект, представляющий поток, а "отгруженная клиенту" - статус объекта. Построение диаграммы потоков работ - WFD При описании бизнес-процессов нижнего уровня используются немного другие процессные схемы, под названием WFD - Work Flow Diagram, что переводится как диаграмма потоков работ. На этой схеме появляются дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки (рис. 10). С помощью логических операторов, которые еще называют блоками принятия решений, показывают альтернативы, которые происходят в процессе, показывается в каких случаях процесс протекает по одной технологии, а в каких случаях по другой. Например, с помощью данных элементов можно описать ситуацию, когда договор стоимость которого меньше определенной суммы согласуется одной группой сотрудников, а договор с большей стоимостью согласуется по более сложной технологии, в цепочки которой участвуют большее количество сотрудников. С помощью событий начала и окончания процесса показывается, когда процесса начинается и когда заканчивается. Для жестко формализованных бизнес-процессов, например, таких, как бюджетирование, в качестве событий может выступать время. В случаях, когда описание бизнес-процесса проводится с целью его дальнейшей временной оптимизации, используют элементы задержки времени, которые показывают места, в которых между последовательно выполняемыми работами имеется временной разрыв. В данном случае последующая работа начинается только через некоторое время после завершения предшествующей. В классическом подходе WFD на данной схеме не показывают документы, так эти схемы используются для описания процессов нижнего уровня, которые содержат детальные работы, и по названию которых понятно, что является входом и что является выходом. Отличительной особенностью WFD - диаграммы является то, что стрелки между операциями бизнес-процесса обозначают не потоки объектов (информационные и материальные), а потоки или временную последовательность выполнения работ. Итак с помощью двух классических схем DFD и WFD можно описать подробно все бизнес-процессы компании. Рис. 10. Диаграмма потоков работ - WFD Важнейший вопрос при описании бизнес-процессов - выбор способа и инструмента описания. Решению этого вопроса посвящена статья "Современные методологии описания бизнес- процессов - просто о сложном". Тема 10. Методы оптимизации бизнес-процессов Классификация методов и инструментов анализа и оптимизации бизнес-процессов. Все методы оптимизации бизнес-процессов делятся на три большие группы: • Формализованные универсально-принципиальные (ФУП-методы); • Бенчмаркинг; • Методы групповой работы.      Формализованные универсально-принципиальные (ФУП) методы основаны на применении обобщений из успешного опыта и формализованных принципов для построения эффективных бизнес-процессов. Данные методы являются универсальными и они подходят для оптимизации любых бизнес-процессов для любого бизнеса и практически не зависят от его специфики.     Методы Бенчмаркинга основаны на изучении, анализе и последующем копировании элементов процессов успешных компаний, занимающихся схожими видами деятельности. Претендентами на изучение и копирование их успешного опыта в первую очередь являются лидеры – конкуренты. Практика показала, что в последнее время многие компании эффективно внедрили у себя технологические ноу-хау, заимствовав их у компаний, работающих в других отраслях бизнеса. Например, многие эффективные методы повышения качества, используемые различными компаниями, были заимствованы из автомобильной промышленности.     Последняя третья группа методов групповой работы объединила различные технологии работы в команде: метод мозгового штурма, метод группового решения задач и т.д. Использование данной группы методов позволяет разработать новые эффективные решения, ранее не кому не известные, что позволяет компании быть лидером по используемым технологиям. ФУП-методы анализа и оптимизации бизнес-процессов Технология применения ФУП-методов анализа и оптимизации бизнес-процессов состоит из двух шагов. Первый шаг – это предварительное изучение каждого ФУП-метода участниками рабочей группы по улучшению бизнес-процесса и второй шаг - постоянный поиск мест их возможного применение в бизнес-процессе. Классики подходов по улучшению бизнес-процессов рекомендуют оформить перечень ФУП–методов в виде документа, возвысить их до принципов, на основе которых должна строится дальнейшая бизнес-деятельность компании (наподобие армейского устава) и довести данный документ до всех сотрудников. В книге будут рассмотрены основные ФУП – методы, использование которых в проектах по улучшению бизнес-процессов в российских компаниях показало свою практическую реализуемость и эффективность. Это следующие методы: • Метод пяти вопросов; • Метод параллельного выполнения работ; • Метод устранения временных разрывов; • Разработка нескольких вариантов бизнес-процесса; • Уменьшение количества входов и выходов бизнес-процесса; • Согласование результатов с требованиями; • Интеграция с клиентами и поставщиками бизнес-процесса; • Минимизация устной информации; • Стандартизация форм сбора и передачи информации; • Организация точек контроля; • Метод причинно-следственных связей или бездефектности работы.     Применение некоторых ФУП–методов приводит к улучшению нескольких или всех базовых показателей бизнес-процесса: результативности, стоимости, времени и качества. Тем не менее, для дальнейшего использования ФУП–методов удобно их разбить на группы в соответствии с теми базовыми показателями бизнес-процессов, на которые они преимущественно оказывают улучающее воздействие. Тема 11. Реализация реинжиниринга Анкета «Выделение бизнес-процессов и описание функций». № Бизнес-процессы и функции I. Основные бизнес-процессы и функции 1. 2. 3. 4. 5. 6. 7. 8. 9. II. Обеспечивающие бизнес-процессы и функции 1. 2. 3. 4. 5. 6. 7. 8. 9. III. Бизнес-процессы и функции управления 1. 2. 3. 4. 5. 6. 7. 8. 9. Тема 12. Организация проекта по оптимизации процессов и оргструктуры Типовой план проекта "Описание бизнес-процессов компании "как есть" Цель проекта: Структуризация и формализация деятельности компании. за счет решения следующих задач: Задачи проекта: • Выделение бизнес-процессов компании "как есть" • Диагностика и выбор приоритетных бизнес-процессов • Описание бизнес-процессов компании "как есть" Этапы проекта: Работы проекта по описанию бизнес-процессов компании "как есть" согласно сформулированным задачам разбиваются на следующие 3 этапа Типовой план проекта "Анализ и оптимизация бизнес-процессов компании. Разработка моделей процессов "как надо" Цель проекта: Улучшение ключевых показателей выбранных бизнес-процессов (результативности, качества, длительности и пр.). за счет решения следующих задач: Задачи проекта: • Определение значений ключевых показателей бизнес-процессов "как надо" • Анализ бизнес-процессов "как есть" и разработка решений по их совершенствованию • Разработка моделей бизнес-процессов "как надо" Этапы проекта: Работы проекта по анализу и оптимизации бизнес-процессов компании и разработке моделей процессов "как надо" согласно сформулированным задачам разбиваются на следующие 3 этапа Типовой план проекта "Анализ и оптимизация организационной структуры компании. Разработка структуры "как надо" Цель проекта: Повышение эффективности реализации стратегии и текущей деятельности предприятия. за счет решения следующих задач: Задачи проекта: • Анализ и оптимизация организационной структуры компании верхнего уровня. Разработка модели оргструктуры компании "как надо" • Анализ и оптимизация организационной структуры выбранных структурных подразделений. Разработка модели оргструктуры подразделений "как надо" • Разработка рекомендаций и плана внедрения организационной структуры "как надо" Типовой план проекта "Разработка базовых документов, регламентирующих деятельность предприятия" Цель проекта: Разработка базовых документов регламентирующих деятельность предприятия. посредством решения следующих задач: Задачи проекта: • Определение направлений и степени регламентации деятельности предприятия. Разработка архитектуры системы регламентирующих документов (регламентов) • Разработка процессных и структурных регламентов для выбранных процессов и структурных подразделений компании Этапы проекта: Работы проекта по разработке базовых документов, регламентирующих деятельность предприятия согласно сформулированным задачам разбиваются на следующие 2 этапа Типовой план проекта "Внедрение системы бизнес-моделирования" Цель проекта: Внедрение системы бизнес-моделирования, обеспечивающей поддержание в актуальном состоянии бизнес-моделей (моделей процессов, оргструктуры, распределения ответственности и пр) и базовых регламентов деятельности предприятия (положений о бизнес-процессах, положений о структурных подразделениях, должностных инструкций и пр). Для достижения целей проекта необходимо решить следующие задачи: Задачи проекта: • Организационное проектирование и построение системы бизнес-моделирования • Инсталляция, настройка и внедрение программного обеспечения бизнес-моделирования Этапы проекта: Работы проекта по разработке и внедрению системы бизнес-моделирования согласно сформулированным задачам разбиваются на следующие 2 этапа Тема 13. Программное обеспечение бизнес-моделирования (BPWin) Конечно, можно пытаться документировать структуру бизнес-процессов, но как сделать это быстро? Как быстро получить четкое представление о том, что происходит на предприятии? Как определить характер предполагаемых изменений и дивиденды, которые эти изменения принесут?  Существует инструмент, который поможет ответить на все эти вопросы. Это Computer Associates BPwin, версия 4.0 которого вышла в этом году. BPwin является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. Причем, поскольку модель является некоторым графическим представлением действительности, можно утверждать, что человек вернулся к своему излюбленному средству документирования бизнес-процессов – к рисунку. Но возвращение это произошло на новом уровне – целостность и непротиворечивость модели-рисунка (качества, о которых раньше не было и речи) гарантируются рядом методологий и нотаций, которым следуют создатели модели. BPwin поддерживает три таких методологии: IDEF0, DFD и IDEF3, позволяющие анализировать ваш бизнес с трех ключевых точек зрения:  • С точки зрения функциональности системы. В рамках методологии IDEF0 (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.  • С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.  • С точки зрения последовательности выполняемых работ. И еще более точную картину можно получить, дополнив модель диаграммами IDEF3. Этот метод привлекает внимание к очередности выполнения событий. В IDEF3 включены элементы логики, что позволяет моделировать и анализировать альтернативные сценарии развития бизнес-процесса.       BPwin умеет проверять создаваемые модели с точки зрения синтаксиса выбранной методологии, проверяет ссылочную целостность между диаграммами, а также выполняет ряд других проверок, чтобы помочь вам создать правильную модель, а не просто рисунок. При этом сохраняются главные преимущества рисунка – простота создания и наглядность. IDEF0. Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов: • Стрелки входа (входят в левую грань работы) – изображают данные или объекты, изменяемые в ходе выполнения работы.  • Стрелки управления (входят в верхнюю грань работы) – изображают правила и ограничения, согласно которым выполняется работа.  • Стрелки выхода (выходят из правой грани работы) – изображают данные или объекты, появляющиеся в результате выполнения работы.  • Стрелки механизма (входят в нижнюю грань работы) – изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы…)  • Стрелки вызова (выходят из нижней грани работы) – изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.       Все работы и стрелки должны быть именованы. Первая диаграмма в иерархии диаграмм IDEF0 всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными. В контекст входит описание цели моделирования, области (описания того, что будет рассматриваться как компонент системы, а что как внешнее воздействие) и точки зрения (позиции, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.  Рис 1. Пример контекстной диаграммы.      Как видно на Рис.1, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени “Отчетность”), что повышает наглядность и читаемость диаграммы.      После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на Рис.2. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).  Рис. 2 Пример диаграммы декомпозиции DFD. Для того чтобы документировать механизмы передачи и обработки информации в моделируемой системе, используются диаграммы потоков данных (Data Flow Diagrams). Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота вашей организации. Чаще всего диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в IDEF0. Всего DFD использует четыре важных элемента: • Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами. (cм. Рис.3 – “Проверить наличие товара на складе”)  • Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота . (cм. Рис.3 – “Запрос на склад”)  • Внешние ссылки. Внешние ссылки указывают на место, организацию или человека, которые участвуют в процессе обмена информацией с системой, но располагаются за рамками этой диаграммы. . (cм. Рис.3 – “Клиент”)  • Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных. (cм. Рис.3 – “Сведения о заказах”)  Рис.3 Пример диаграммы DFD      В диаграммах потоков данных все используемые символы складываются в общую картину, которая дает четкое представление о том, какие данные используются, и какие функции выполняются системой документооборота. При этом часто выясняется, что существующие потоки информации, важные для деятельности компании, реализованы ненадежно и нуждаются в реорганизации.      IDEF3. Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет точно описать процесс документооборота. Однако для описания логики взаимодействия информационных потоков модель дополняют диаграммами еще одной методологии – IDEF3, также называемой workflow diagramming. Методология моделирования IDEF3 позволяет графически описать и задокументировать процессы, фокусируя внимание на течении этих процессов и на отношениях процессов и важных объектов, являющихся частями этих процессов.      IDEF3 предполагает построение двух типов моделей: модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать “сеть переходных состояний объекта”, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс.      С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции организации.      Модель, выполненная в IDEF3, может содержать следующие элементы: • Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.  • Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:  ◦ Связь предшествования (Precedence) – показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.  ◦ Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.  ◦ Поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.  • Перекрестки (Junctions) - перекрестки используются в диаграммах IDEF3, чтобы показать ветвления логической схемы моделируемого процесса и альтернативные пути развития процесса могущие возникнуть во время его выполнения. Различают два типа перекрестков:  ◦ Перекресток слияния (Fan-in Junction) – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.  ◦ Перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.  • Объекты ссылок (Referents) - служат для выражения идей и концепций без использования специальных методов, таких как стрелки, перекрестки или работы.  Рис. 4 Пример диаграммы IDEF3      Кроме того, что уже было сказано по поводу трех поддерживаемых BPwin методологий, необходимо отметить еще несколько вещей. Как мы уже замечали ранее модель, выполненная в BPwin представляет собой набор иерархически упорядоченных диаграмм (не обязательно сделанных в одной методологии, чаще модели бывают смешанными). При размещении на очередной диаграмме некоторого элемента (работы, стрелки…) этот элемент вместе со всеми своими свойствами (которые всегда можно просмотреть или изменить в соответствующем редакторе BPwin) автоматически заносится в словарь BPwin, в результате вместе с графическим изображением моделируемой системы аналитик получает десятки страниц с подробным текстовым описанием системы.      Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.      BPwin обладает удобным инструментом для навигации по уровням декомпозиции модели. Это Model Explorer (см. Рис. 5), Рис. 5), который по организации очень похож на привычный всем проводник Windows. Работы IDEF0 показываются в Model Explorer зеленым цветом, DFD – желтым и IDEF3 – синим. Щелкая мышкой по любой из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу. В версии BPwin 4.0 проводник модели предлагает пользователю улучшенный интерфейс, который включает в себя новую вкладку объектов (Objects), и доработанную вкладку диаграмм (Diagrams). С помощью вкладки объектов можно методом Drag&Drop размещать объекты из словаря на любой диаграмму. С помощью вкладки диаграмм можно просматривать всю иерархию диаграмм, включая Organization Chart, Node Tree, Swim Lane, FEO, и IDEF3 Scenario, о которых речь пойдет позже. Рис. 5 Model Explorer      Вообще если говорить о версии BPwin 4.0 нельзя не отметить существенные улучшения интерфейса. Наконец-то можно забыть о проблемах со шрифтами, с изменением размеров объектов на диаграмме, что раньше в некоторых случаях могло привести к тому, что диаграмма “плыла”. Кроме проводника модели, улучшены были также и словари объектов. Теперь все словарные объекты располагаются в радующих глаз аккуратных таблицах. Вид этих таблиц можно настраивать так, как удобно вам, содержание словарей можно печатать, экспортировать, импортировать, также можно генерировать отчеты по содержанию словарей. Можно поддерживать словари для следующих объектов:  1. Работы;  2. Стрелки;  3. Хранилища данных;  4. Внешние ссылки;  5. Перекрестки;  6. Объекты ссылок;  7. Атрибуты;  8. Центры затрат;  9. Сущности;  10. Ресурсы;  11. Роли;  12. Группы ролей;  13. Свойства, определяемые пользователем (UDP);  14. Ключевые слова UDP.       Генератор отчетов тоже претерпел существенные модификации. Теперь BPwin имеет действительно мощный инструмент отчетов Report Template Builder, с помощью которого можно легко и быстро создавать различные отчеты о вашей модели. С его помощью можно также создавать шаблоны для отчетов, которые можно будет многократно использовать впоследствии, а также преобразовывать отчеты в формат txt (.CSV), HTML или RTF.      Были улучшены и дополнены и редакторы свойств диаграмм и объектов. Теперь, помимо тех свойств, которые были доступны в предыдущих версиях, в них включены вкладки для изменения шрифтов, цветов, ролей, стиля прямоугольников работ, колонтитулов и других параметров страницы. На вкладке Header/Footer пользователь может теперь настраивать верхний и нижний колонтитулы для каждой диаграммы в отдельности. Кнопки панели инструментов автоматически перестраиваются при переходе от одной методологии к другой. Появилась возможность выделения группы объектов и последующей работы с этой группой. Еще один подарок пользователям BPwin 4.0 – поддержка визуального сравнения диаграмм. Теперь вы можете, предварительно выбрав две диаграммы, создать файл JPEG, который покажет все различия между выбранными диаграммами. И, конечно, обновлен BPwin Online Tutorial, в котором приведены полные уроки с примерами моделей, которые помогут вам быстро освоить BPwin.      Итак, что же может предложить BPwin, кроме поддержки уже рассмотренных нами трех методологий моделирования? Конечно же, этот инструмент, ставший незаменимым в консалтинговых компаниях в России и по всему миру, не останавливается на этом. В дополнение к диаграммам IDEF0, DFD и IDEF3, BPwin поддерживает еще целый ряд вспомогательных диаграмм таких как:      Диаграммы дерева узлов (Node Tree Diagram). К модели BPwin можно добавлять дерево узлов, которое показывает иерархию всех работ модели на одной диаграмме. Диаграмма дерева узлов имеет вид традиционного иерархического дерева, где верхний узел (прямоугольник) соответствует работе с контекстной диаграммы, а последующие нижние узлы представляют собой дочерние уровни декомпозиции. Можно также создать диаграмму дерева узлов лишь для некоторой части модели, тогда верхним узлом диаграммы будет та работа декомпозиции, с которой вы захотите начать. Прямоугольники в дереве узлов сохраняют за собой все свойства соответствующих им работ. Например, можно открыть редактор свойств работы, дважды щелкнув мышкой по прямоугольнику работы. Если же вы дважды щелкнете мышкой по той части диаграммы, которая не занята работами, откроется редактор свойств самой диаграммы дерева узлов, где можно установить такие свойства диаграммы как ее имя, шрифт и цвет. Добавив к модели диаграмму дерева узлов, вы всегда можете вернуться к ней с помощью вкладки диаграмм в проводнике модели.      В версии BPwin 4.0 появилась возможность отображать диаграммы дерева узлов не только с диагональными, но и с прямыми линиями связи и менять свойства работ непосредственно из самой диаграммы. Рис. 6 Пример диаграммы дерева узлов      Диаграммы только для показа (For Exposition Only {FEO} Diagram). К модели всегда можно добавить диаграмму FEO. Чаще всего это делается, для того чтобы проиллюстрировать разные сценарии развития процесса, показать модель с других точек зрения, вырезать важный кусок из сложной диаграммы (см. рис. 7), не портя при этом саму диаграмму. К любой диаграмме модели в BPwin, будь то контекстная диаграмма или одна из диаграмм декомпозиции можно добавлять произвольное число FEO диаграмм. FEO диаграммы характерны тем, что они не подлежат синтаксической проверке со стороны BPwin, поскольку, как в нашем примере, они могут являться лишь частью синтаксически правильной диаграммы.      Добавив к модели FEO диаграмму, вы всегда можете вернуться к ней с помощью вкладки диаграмм в проводнике модели. Рис. 7 Пример FEO диаграммы      Диаграммы сценариев IDEF3 (IDEF3 Scenario). В BPwin 4.0 есть возможность добавлять к модели диаграммы сценариев IDEF3. Рис. 8 Пример сценария IDEF3     Схемы организации (Organization Charts). Для того чтобы наглядно представить структуру организации к любой модели в BPwin 4.0 можно добавить схему организации. Схемы организации BPwin имеют традиционную древовидную иерархическую структуру, на вершине которой находится один прямоугольник, от которого идут ветвления к нескольким нижестоящим. Каждый прямоугольник в схеме организации соответствует конкретной роли или должности, например президента или вице-президента. Перед тем как добавить к модели схему организации, вы должны определить группы ролей, роли и, возможно, ресурсы. Сначала вы должны создать одну или более группу ролей в словаре групп ролей, задав критерий, объединяющий роли, которым соответствуют схожие функции в организации. Затем в словаре ролей вы описываете роли, которым будут соответствовать прямоугольники в схеме организации.      Создав схему организации, вы можете изменять свойства ролей, такие как имя роли, цвет и т.п. в редакторе свойств, который вызывается двойным щелчком мыши по соответствующему прямоугольнику роли на схеме. Редактор свойств диаграммы можно вызвать, дважды щелкнув мышкой по месту не занятому прямоугольниками ролей.       Добавив к модели диаграмму со схемой организации, вы всегда можете вернуться к ней с помощью вкладки диаграмм в проводнике модели. Вы также можете перемещать роли и ресурсы на диаграмму из вкладки объектов проводника модели. Рис. 9 Пример схемы организации      Swim Lane Diagrams. Это тоже нововведение, которое можно обнаружить только в BPwin 4.0. Swim Lane диаграммы можно добавлять к любой модели в BPwin для более наглядного изображения течения процесса. Эти диаграммы используют методологию IDEF3 и показывают горизонтальные полосы, которые представляют участие в процессе ролей. Рис. 10 Пример Swim Lane диаграммы.      Но и описав вспомогательные диаграммы, мы далеко не исчерпали все возможности BPwin, поскольку этот продукт является не только мощным средством графического представления информации, но и инструментом ее анализа. Как уже говорилось выше, при реорганизации бизнес-процессов уже существующей системы строятся две модели: AS IS и TO BE. Модель AS IS призвана показать, как система функционирует в настоящий момент и является своего рода фотографией системы. А модель TO BE, которая строится исходя из результатов анализа модели AS IS, показывает, как система будет работать после реорганизации. Как же провести этот анализ? Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияние ее результат) и входу (объекты или информация используются нерационально) и т.д. Кроме того, BPwin содержит ряд средств, которые помогают аналитику анализировать и исправлять модель AS IS. Прежде всего, речь идет о том, что BPwin указывает на синтаксические ошибки в модели, которые могут быть вызваны неправильной организацией системы. Когда все такие ошибки будут исправлены, перед аналитиком должна встать задача оптимизации, а для корректной постановки этой задачи, как известно, необходим критерий. Здесь BPwin снова приходит аналитику на помощь, предлагая ему то, что для оптимизатора значит ничуть не меньше, чем точка опоры для Архимеда. BPwin дает аналитику метрику - стоимостной анализ, основанный на работах (Activity Based Costing, ABC) и свойства, определяемые пользователем (User Defined Properties, UDP). Встроенный в BPwin механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности. Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) - это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа. ABС является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации. Стоимостной анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостной анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания в функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия. С помощью стоимостного анализа можно решить такие задачи как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь).      Механизм поддержки ABC в BPwin, хотя и учитывает стоимость выполнения каждой работы, продолжительность каждой работы по времени и сколько раз необходимо выполнить работу в течение одного цикла бизнес-процесса, все же дает довольно грубые оценки и, к тому же требует, чтобы все диаграммы, для которых производится оценка были выполнены в IDEF0. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем (User Defined Properties, UDP). Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report.     И, наконец, создатели BPwin очень хорошо понимают, что один в поле не воин, даже если этот “один” - BPwin 4.0, и поэтому BPwin тесно интегрируется с рядом известных продуктов Computer Associates и других компаний. Среди этих продуктов: • Широко известный инструмент моделирования данных ERwin (CA/Logic Works). Erwin не нуждается в рекомендациях. Для тех, кто уже работает с BPwin, отметим, что в версии BPwin 4.0 интерфейсы экспорта и импорта синхронизованы с Erwin 4.0. Кроме того, появилась возможность ассоциирования сущностей и атрибутов с хранилищами данных.  • Система управления и хранения проектов ModelMart (CA/Logic Works), которая предоставляет репозитарий для коллективной разработки моделей. ModelMart гарантирует согласованность моделей, разграничение доступа к ним, поддержку версий и много других средств, которые так важны при командной разработке моделей. Сервер приложений для программных продуктов CA ModelMart поддерживает мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания "компонент" модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin.  • Инструмент стоимостного анализа EasyABC (ABC Technologies).  • В BPwin 4.0 стал возможен экспорт модели в систему имитационного моделирования Arena (Systems Modeling Corp.).       Все вышесказанное позволяет утверждать, что уже сейчас BPwin крайне необходим всем, кто занимается проектированием и анализом бизнес-процессов. Сложно представить, насколько мощный инструмент получат аналитики через несколько лет, если BPwin, будет продолжать и дальше совершенствоваться такими темпами.