Реинжиниринг бизнес-процессов - Тельнов Ю.В.. Московский международный институт эконометрики, информатики, финансов и права Тельнов Ю. Ф. Реинжиниринг бизнес процессов (Учебное пособие)
 Скачать 2.06 Mb.
|
|
Глава 3. Функциональное моделирование бизнес-процессов с использованием ППП Design/IDEF 3.1. Сущность методологии функционального моделирования бизнес- процессов (SADT – методологии) SADT - методология (Structured Analysis and Design Technique) получила столь широкое распространение благодаря тому, что ориентирована на комплексное представление структуры материальных, информационных, финансовых и управленческих потоков, отображение организационной структуры. В силу этого, SADT - методология в большей степени нацелена на реорганизацию всей системы управления, чем другие методологии функционального моделирования, основанные на использовании диаграмм потоков данных, главная цель которых проектирование информационных процессов. Функциональная модель бизнес-процессов состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы - главные компоненты модели, которые отображают последовательности взаимосвязанных через общие объекты функций (операций, действий, работ – activity) бизнес-процесса. Достоинство функциональной модели заключается в графической простоте, в которой используются всего два конструктивных элемента: • функциональный блок – описание функции, операции, действия, работы; • интерфейсная дуга, связывающая два функциональных блока – описание объекта, потока объектов. Функциональная модель начинается с построения общего описания процесса, которое представляется в диаграмме нулевого уровня или контекстной диаграмме (рис. 3.1.). На этом уровне весь процесс рассматривается как один функциональный блок со всеми связанными обрабатываемыми и управляющими объектами. На этой диаграмме также отражается цель структурного анализа (например, сокращение длительности выполнения процесса, или сокращение издержек, или повышение качества обслуживания и т.д.) и точка зрения, с позиции которой рассматривается модель (дирекция, отдел информатизации, экономический отдел и т.д.). 39 Рис.3.1. Контекстная диаграмма Диаграммы следующих уровней детализируют функции процесса каждого предыдущего уровня (рис. 3.2.). Так, функциональный блок А0 декомпозируется на совокупность взаимосвязанных подфункций А1, А2, А3, …. В свою очередь каждый функциональный блок 1-го уровня может быть декомпозирован на совокупность подфункций, например А2 на А21, А22, А23, А24 ... и так дальше, пока на последнем уровне не получатся элементарные действия. На каждом уровне рекомендуется размещать не более 6 функциональных блоков. Число уровней декомпозиции не ограниченно. Обычно для структурного анализа бизнес-процессов достаточно 2 – 3 уровней декомпозиции, последующие уровни декомпозиции требуются для алгоритмизации информационных процессов и разработки инструкций для исполнителей бизнес-процессов. Рис.3.2. Декомпозиция функции А0 Для каждого функционального блока определяются интерфейсные дуги различных типов (стрелки), которые отражают потоки объектов. 40 Объекты могут быть различной природы: материальные, финансовые, информационные. По характеру использования объектов в функциональных блоках различают: входные (input) объекты слева от блока, выходные (output) объекты справа от блока, управляющие (control) объекты сверху от блока и механизмы (mechanize) снизу от блока. Объекты обозначаются метками на стрелках, которые обязательны. Входные объекты преобразуются в функциональных блоках в выходные. При этом выходной объект – это новый созданный объект или преобразованный старый объект. В последнем случае новое качество объекта, как правило, обозначается прилагательным, например, принятый заказ, отложенный заказ, удаленный заказ, выполненный заказ и т.д. Управляющие объекты соответствуют нормативным актам (законодательным актам, инструкциям, планам, приказам), на основе которых выполняются процессы. Кроме того, управляющие объекты рассматриваются как ограничения, обстоятельства, условия выполнения процесса, например номенклатуры-ценники, списки клиентов и поставщиков, состояние запасов, состояние расчетного счета, наличие производственных мощностей и т.д. Управляющие объекты должны обязательно отражаться в функциональной модели, а входные объекты не обязательно. В последнем случае какой-либо управляющий объект одновременно является и входным, например, заказ, на основе которого выполняется работа, преобразуется внутри функционального блока в готовый продукт. Механизмы – это объекты, которые исполняют процессы (исполнители). К механизмам относят структурные подразделения предприятия, персонал, автоматизированные рабочие места, оборудование. Объекты могут выступать в различных блоках в разных ролях, например, когда выходной объект одного блока является входным объектом, или управляющим объектом, или механизмом для другого функционального блока. Объекты, которые выступают только в одной роли, обозначаются метками, с которыми связаны пограничные дуги. При этом объекты, передаваемые в детальную диаграмму из вышестоящих диаграмм, обозначаются ICOM метками (рис. 3.2.): I1, I2, I3, …. - входные объекты; О1, О2, О3, … - выходные объекты; С1, С2, С3, …. – управляющие объекты; М1, М2, М3, …. – механизмы. Объекты, с которыми связаны пограничные дуги, могут быть локальными на данном уровне диаграммы. Такие объекты связываются с 41 функциональными блоками внешними туннельными дугами (рис. 3.4.), имеющими скобки на внешней стороне стрелки от блока. Объекты, которые используются во всех функциональных блоках на детальной диаграмме, обозначаются внутренними туннельными дугами (рис. 3.4.), имеющими скобки на внутренней от блока стороне стрелки, и не передаются в качестве ICOM – метки на детальный уровень. 3.2. Общая характеристика ППП Design/IDEF ППП Design/IDEF (Фирма-разработчик: MetaSoftware (США), дистрибьютор: «Весть-Метатехнология») предназначен для проведения структурного и стоимостного анализа бизнес-процессов и относится к классу «легких» систем автоматизированного проектирования информационных систем (CASE-технологий), позволяющий построить структуру логического проекта системы. В основе ППП Design/IDEF лежит SADT - методология (структурного анализа и техники проектирования) [2,25], которая дает возможность строить функциональные модели бизнес-процессов. Данная методология реализована также в ППП BPWin. К функциональным возможностям ППП Design/IDEF относятся: • Графическое представление функциональной структуры (технологии выполнения) бизнес-процессов на различных уровнях детализации. • Разработка функциональной модели с указанием исполнителей операций и используемых информационных технологий и управляющих воздействий. • Графическое представление структуры предметной области в виде информационной модели «Объект-связь». • Расчет стоимостных затрат на выполнение бизнес-процессов с возможностью экспорта расчетных данных в электронную таблицу Excel, Lotus. • Документирование моделей предметной области в виде глоссария и составления текстовых отчетов. • Автоматизация проектирования информационной системы, в частности определение структуры базы данных. • Возможность экспорта функциональной модели в пакеты программ динамического имитационного моделирования, поддерживающие сети Петри. ППП Design/IDEF состоит из трех основных компонентов: • IDEF0 – инструмент функционального моделирования; • IDEF1x – инструмент информационного моделирования; • IDEF/CPN (Workflow Analyzer) – инструмент динамического имитационного моделирования (отдельно поставляемый программный продукт). 42 В дальнейшем будет рассмотрено применение инструмента функционального моделирования IDEF0. 3.3. Особенности построения функциональной модели c использованием ППП Design/IDEF На уровне контекстной диаграммы отражаются принципиальные потоки объектов, которые составляют сущность бизнес-процесса. При этом потоки объектов, задействованные только в отдельных функциях бизнес-процесса, на контекстном уровне не задаются и становятся локальными в соответствующем блоке. Пример контекстной диаграммы процесса выполнения заказа клиента представлен на рис. 3.3. Диаграммы детальных уровней описания бизнес-процессов обеспечивают возможность отображения на одной схеме множества альтернативных путей выполнения бизнес-процесса. Каждый функциональный блок в зависимости от рассматриваемого контекста может обрабатывать подмножество входных объектов, соответственно формировать подмножество выходных объектов, при этом может быть задействовано подмножество механизмов и управляющих объектов. Каждый вариант использования функционального блока называется его активацией. Для понимания механизма активации функционального блока часто требуется анализ контекста на следующем уровне детализации модели. На детальных диаграммах функциональные блоки располагаются на главной диагонали по принципу «сверху-вниз» и «слева-направо». Диагональное размещение функциональных блоков способствует более компактному представлению схемы бизнес-процесса и улучшению его понимаемости. При этом главная диагональ обеспечивает отображение основного пути бизнес-процесса. Причем функциональным блокам назначаются номера в соответствии, с одной стороны, с логической последовательностью выполнения процесса, а с другой стороны, со степенью влияния на выполнение других функций (число выходящих дуг, число связанных блоков). Таким образом, наиболее важные блоки получают первые номера, а наименее важные последние. Структурная сложность организации бизнес-процессов достигается путем разветвлений и объединений путей на диаграмме, а также обратных связей. Различают следующие виды разветвлений: • Классификация объектов, которая уточняет тип обрабатываемого в дальнейшем объекта. Например, класс объектов «Заказ» делится на подклассы «Заказ нового клиента», «Заказ старого клиента» (рис.4). Разветвление в этом случае обеспечивает альтернативность путей выполнения процесса реализации заказа клиента. При этом каждый путь должен быть помечен именем подтипа объекта. 43 • Разбиение объекта на компоненты (дезагрегация), которые в дальнейшем обрабатываются как самостоятельные объекты по своим путям. Например, объект-агрегат «Поставка» в процессе материально- технического снабжения разбивается на объекты-компоненты «Продукт», «Накладная», «Счет» (рис. 5). В этом случае происходит распараллеливание путей бизнес-процесса, которые выполняются разными исполнителями. При этом каждый путь должен быть помечен именем объекта-компонента. • Одновременный доступ к объекту или его копирование, подразумевающее одновременную манипуляцию с одним и тем же объектом или его копиями несколькими исполнителями. Например, на основе объекта «Оформленный заказ» могут параллельно выполняться функциональные блоки «Выписать счет» и «Выполнить заказ» (рис. 3.4). В последнем случае дополнительная пометка параллельных путей необязательна, хотя и возможна, если речь идет о копиях. Объединение путей на диаграмме соответственно обеспечивает: • Обобщение объектов, когда объекты нескольких типов в дальнейшем должны обрабатываться по общему пути, т.е. снимается альтернативность путей. Например, класс объектов «Проверенный заказ» объединяет альтернативные пути (рис. 3.4). Следующий функциональный блок получает объект по любому из альтернативных путей. • Агрегация объектов, когда несколько компонентов образуют один объект. Например, объект «Документы к оплате» можно рассматривать как агрегат, включающий объекты «Накладная» и «Счет» (рис. 3.5). Тогда перед тем как будет выполнен функциональный блок, должна произойти синхронизация поступления объектов-компонентов. Обратные связи реализуют циклы на повторение операций: • Использование откорректированной нормативной и плановой информации для следующего цикла выполнения процесса. Например, информация о новом клиенте заносится в базу данных и рассматривается как ограничение в следующем цикле приема заказа (рис. 3.4). При этом происходит объединение путей на диаграмме по принципу обобщения. • Повтор операций после контроля и отбраковки объектов. Например, повторная поставка товара после неакцепта накладной (рис. 3.5). 44 Рис. 3.3. Контекстная диаграмма Рис. 3.4. Разветвления и объединение путей по принципу классификации и обобщения 45 Рис. 3.5. Разветвления и объединение путей по принципу дезагрегации и агрегации Вопросы для самопроверки: 1. Что такое функциональная модель бизнес-процесса? 2. Какие конструктивные элементы используются для построения функциональной модели? 3. Как представляется поток материальных, информационных, финансовых объектов? 4. Как трактуется и представляется управление выполнением функций? 5. Как представляются исполнители бизнес-процессов? 6. Как отражается использование информационной системы в бизнес- процессе? 7. Что такое ICOM метки и как они используются? 8. Что такое туннельные дуги и как они используются? 9. Что такое главный путь бизнес-процесса и как он отражается? 10. Как трактуются и представляются разветвления и соединения путей бизнес-процесса? 11. Как трактуются и представляются циклы в бизнес-процессе? 12. Перечислите функциональные возможности ППП Design/IDEF. 46 Глава 4. Стоимостной анализ функций (Activiy-Based Costing) 4.1. Сущность стоимостного анализа функций Современные бизнес-процессы отличаются высоким уровнем накладных расходов, связанных с затратами на организацию сделки с клиентами, разработкой спецификации изделия в соответствии с индивидуальными требованиями заказчика, закупкой уникальных материалов, обучением и сервисным обслуживанием потребителя. По некоторым данным трансакционные издержки оформления и реализации сделки занимают до 70% в общей себестоимости готовой продукции [9]. Традиционно предприятия относят накладные расходы на стоимость продукции в соответствии с затратами прямого труда. Продукты с наибольшими прямыми затратами получают больше накладных расходов без учета реальных затрат, связанных с конкретным обслуживанием выполнения заказов. При традиционном подходе не учитываются типы потребителей и каналов распространения продукции. Отсюда возникает неточность в оценке затрат и эффективности деятельности предприятия по различным видам бизнес-процессов. Следовательно, объективно требуется применение методов стоимостного анализа, которые более точно определяли бы издержки предприятия в условиях высокой диверсификации видов деятельности. К таким методам относятся методы стоимостного анализа функций. Стоимостной анализ функций позволяет сначала определять стоимостные затраты на выполнение процессов путем отнесения на функции стоимости использования в них всех ресурсов. Далее стоимость функций переносится на стоимостные объекты: (продукты, услуги, виды продуктов и услуг, клиенты и типы клиентов, каналы распространения продукции) в соответствии с объемами работ по каждой функции. Таким образом, накладные расходы на стоимостные объекты определяются по степени использования ресурсов в функциях, связанных со стоимостными объектами (рис. 4.1.). В отличие от традиционной одноступенчатой схемы стоимостного анализа схема отнесения затрат становится двухступенчатой, позволяющей более точно определять издержки, связанные с выполнением заказов потребителей. Стоимостной анализ функций создает основу для применения новых технологий управления в части принятия стратегических инвестиционных решений, маркетинга, улучшения процессов. Стоимостной анализ функций позволяет: 1. Сократить время и затраты на выполнение функций, добавляющих стоимость (value-added). 2. Максимально сократить функции, не добавляющие стоимость (non value-added), например, тестирование, контроль. 3. Выбрать функции с низкой стоимостью из возможных альтернатив (анализ вариантов бизнес-процессов). 47 4. Организовать совместное использование всех возможных функций для различных стоимостных объектов (с позиции множества продуктов, услуг) с перераспределением высвобождающихся ресурсов. 5. Согласовать интенсивность процессов для создания стоимостных объектов и наличные ресурсы. $ $ Прямые затраты Непрямые затраты Накладные расходы ресурсы $ $ $ $ $ $ $ $ функции Стоимость продуктов, услуг, обслуживания клиентов стоимостные объекты I этап -- факторы ресурсов II этап -- Функциональные факторы Рис. 4.1. Стоимостной анализ функций Стоимостной анализ функций реализуется или в качестве программного модуля автоматизированной подсистемы контроллинга, например, в системе R/3 SAP, или в рамках CASE-технологии, например, в Design/IDEF, ARIS ToolSet, или в качестве самостоятельного программного продукта, например, в ППП Easy ABC+. 4.2. Реализация стоимостного анализа функций в ППП Design/IDEF Стоимостной анализ функций в ППП Design/IDEF реализован в ограниченном объеме и позволяет выполнить только одноступенчатую схему расчета стоимости процесса без переноса стоимости процесса на стоимостные объекты. Исходные стоимостные затраты задаются для функций самого нижнего уровня детализации бизнес-процесса. Перечень статей затрат определяется в словаре Glossary в качестве центров затрат (Activity centers), например, заработная плата, амортизация оборудования, расход материала, транспортные расходы, командировочные расходы и т.д. Перечень статей для каждой функциональной модели может быть 48 индивидуальным, однако после его определения он распространяется на все функции (операции) модели. Задание конкретных затрат на выполнение функций осуществляется с помощью определения стоимостной информации (Cost Information) в словаре Glossary (рис. 4.2.). Рис. 4.2. Стоимостной анализ функций Стоимостная информация заполняется в следующем порядке: 1. В параметре Frequence Multiplier устанавливается частота выполнения функции в одном экземпляре процесса или за определенной период времени. В примере частота соответствует числу заказов (процессов) 48 за неделю. 2. В окне Time Information определяются: • Единица измерения длительности (unit) в секундах, минутах, часах и т.д. • Длительность (duration) одной операции. • Длительность*Частота – автоматически формируемый показатель. 3. В окне Cost information последовательно заполняются статьи затрат, часть из которых может быть связана прямой зависимостью с 49 длительностью операции, например, заработная плата, амортизация и т.д. 4. В параметре Total автоматически подсчитывается итог затрат по операции 5. В параметре Total*Frequency автоматически рассчитывается сумма затрат по операции на процесс. На основе стоимостных затрат функций, находящихся на нижних уровнях детализации модели, осуществляется автоматическое суммирование по принципу “снизу вверх” стоимостных затрат функций- агрегатов вплоть до получения итоговой суммы стоимостных затрат на весь процесс по формуле: Стоимостные затраты функции = ∑ Стоимостные затраты подфункции Для установки параметров вычисления стоимостных затрат используется режим установки стоимости Set cost в пункте установки опций Set Options пункта меню Edit Menu. Для проведения дальнейших расчетов и графического анализа результаты стоимостного анализа функций могут быть выведены в электронную таблицу Excel или Lotus. Для этого необходимо произвести в пункте меню File экспорт модели в файл с расширением АВС и открыть его в электронной таблице, заменив контекстно точку на запятую. Пример получившейся таблицы представлен в таблице 4.1. 50 Стоимостной анализ функций Таблица 4.1. Node Title Зарплата Накладные Амортизаци я Транспортные расходы Материал ы Total Cost Duration Frequency Value Added A0 Выполнить заказ 1135,16 86,359 112,14 60 0 1393,659 9396,5 1 1 A1 Принять заказ 864 74,88 46,08 0 0 984,96 8640 6 1 A11 Согласовать цену 48 4,8 0 0 0 52,8 480 48 1 A12 Согласовать конфигурацию 24 2,4 7,68 0 0 34,08 240 48 1 A13 Согласовать по времени изготовления 19,2 0 0 0 0 19,2 240 48 1 A14 Оформить заказ 52,8 5,28 0 0 0 58,08 480 48 1 A15 Проверить оплату 0 0 0 0 0 0 0 1 1 A2 Сформировать заказ на закупку 54,36 4,671 48,06 0 0 107,091 643,5 3 1 A21 Формирование свода необходимых деталей 3 0,3 5,01 0 0 8,31 150 3 1 A22 Выбор поставщика 2,61 0,027 2,01 0 0 4,647 60 3 1 A23 Оформление заказа на закупку 12,51 1,23 9 0 0 22,74 4,5 3 1 A3 Закупить детали 54 5,4 18 60 0 137,4 3 3 1 A4 Изготовить компьютер 88 1,32 0 0 0 89,32 88 44 1 A5 Выдать заказ 74,8 0,088 0 0 0 74,888 22 44 1 51 4.3. Реализация стоимостного анализа функций в ППП Easy ABC+ ППП Easy ABC+ - это специализированный пакет программ стоимостного анализа функций, который выполняет стоимостные расчеты на основе функциональной модели IDEF0 и исходных данных бухгалтерской и логистической информационных подсистем, импортируемых в пакет. Стоимостной анализ функций выполняется по двухступенчатой схеме, для реализации которой пользователь-аналитик должен определить факторы ресурсов и функциональные факторы. Факторы ресурсов определяют критерии отнесения затрат, связанных с использованием ресурсов, на стоимость функций. Для каждого отношения «ресурс – функция» может быть задан свой натуральный показатель отнесения затрат. Например, отнесение затрат «Аренда помещений» на стоимость выполнения функций может вычисляться в соответствии с показателем «Площадь в квадратных метрах под рабочие места, связанные с выполнением функции», а «Командировочные расходы» - по показателю «Число человеко-дней, затраченных на командировки для выполнения функций». Функциональные факторы – это критерии переноса затрат с функций на стоимостные объекты. Для каждого отношения «функция – стоимостной объект» может быть задан свой натуральный показатель отнесения затрат. Например, перенос затрат, связанный с выполнением функции «Тиражирование» на стоимостные объекты «Бюллетени», «Брошюры», «Книги» выполняется в соответствии с показателем «Объем тиражирования по видам продукции». Технология проведения стоимостного анализа функций в ППП Easy ABC+ I. Разработка функциональной модели. 1. Определить множество стоимостных объектов. 2. Построить функциональную модель IDEF0. 3. Определить статьи стоимостных затрат на выполнение функций. II. Настройка пакета программ 1. Импорт модели IDEF0. 2. Задание факторов ресурсов для каждого отношения «Статья затрат ресурсов – функция». 3. Задание функциональных факторов для каждого отношения «Функция – стоимостной объект». 52 4. Импорт данных бухгалтерского учета для вычисления стоимости процессов. 5. Импорт данных логистической подсистемы для вычисления стоимостных затрат на создание стоимостных объектов. III. Выполнение стоимостного анализа функций. 1. Автоматический расчет стоимости выполнения процесса и создания стоимостных объектов. 2. Вывод результатов расчета пользователю-аналитику. Рассмотрим выполнение стоимостного анализа функций на примере бизнес-процесса «Сервисное обслуживание пользователей программного обеспечения по горячей линии» компьютерной фирмы, изготавливающей некоторый программный продукт в виде двух версий. Стоимостные объекты: - Продукт для профессионального пользователя. - Продукт для непрофессионального пользователя. Функциональная модель процесса: 1. Регистрация телефонных звонков. 2. Ответ на телефонный звонок. 3. Выявление ошибки. Основные статьи затрат ресурсов: - Заработная плата. - Амортизация компьютера (АРМа). - Оплата телефонных каналов. и др. Факторы ресурсов: - среднее время занятости работника, - среднее время занятости компьютера, - среднее время занятости телефонных каналов. Функциональные факторы: - объемы продаж по видам продукции. Бухгалтерская информация: - Заработная плата. - Оплата по счетам телефонной компании. и др. 53 Логистическая информация - Объем продаж по видам версий. - Время занятости ресурсов. Результаты расчетов стоимостных затрат показаны в таблице: Таблица 4.2. № п\п Операция Объем продажи Стоимость операции % от общих затрат Стоимость на единицу Продукт для профессионалов 1000 1. Выявление ошибок 936260 59,6 936.26 2. Ответы на звонки 343018 21,9 343.02 3. Регистрация звонков 290548 18,5 290.54 ИТОГ: 1569827 100,0 1569.83 Продукт для не- профессионалов 2000 1. Выявление ошибок 1372072 45,7 686.04 2. Регистрация звонков 1162195 38,7 581.10 3. Ответы на звонки 468130 15,6 234.07 ИТОГ: 3002398 100,0 1501.20 Как видно из таблицы основной объем работ на «горячей линии» связан с выявлением ошибок как для профессиональной, так и для непрофессиональной версий продукта, что определяет необходимость повышения качества выполняемых работ в основном процессе создания программных продуктов. Причем стоимость выявления ошибок в профессиональной версии выше, что предопределяет необходимость совершенствования самого продукта. 54 Вопросы для самопроверки: 1. Что такое стоимостной анализ функций? 2. В чем заключается основное назначение стоимостного анализа функций? 3. Как определяются стоимостные затраты на выполнение функций (процессов)? 4. Как определяются стоимостные затраты на изготовление продуктов (оказание услуг)? 5. В чем заключаются ограничения ППП Design/IDEF в стоимостном анализе функций? 6. Каков алгоритм стоимостного анализа функций в ППП Easy ABC+? 55 |