Реферат: Реинжиниринговый подход к управлению бизнес-процессами в организации

Реинжиниринговый подход к управлению бизнес-процессами в организации. ( С использованием методологии IDEF (Integrated computer-aided manufacturing DEFinition))

(Теоретико-методический аспект)

Чупров Краснослав Краснославович

Москва, 2002 г.

Глава 1.

Общетеоретические основы моделирования, анализа и реинжиниринга бизнес-процессов в современной организации

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

В каких же областях деятельности организации реинжениринг производит значительные изменения?

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

Таблица 1*

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

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

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

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

Понятие «сознание» относится к одной из важнейших философских категорий.

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

Завершая краткую характеристику понятия «сознание», мы также рассмотрим в уставленном нами выше контексте понятие «усилие».

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

Следующее на очереди из рассматриваемых нами понятий – «элемент бизнес-системы». Оно будет рассмотрено нами в два этапа. На первом этапе мы рассмотрим «планетарное» понятие «элемент», а затем «бизнес-систему» и определим основные элементы бизнес-системы.

Элемент – это, как известно, неделимая субстанция объекта. В настоящей статье мы так и будем использовать понятие «элемент».

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

Для этого мы будем использовать понятие «система», описанное в работе В.Д. Могилевского «Методология систем», т.к. на наш взгляд данная работа наиболее подходит для выбранной темы исследования.

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

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

Целостность – следующее свойство системы – является внутренним единством, принципиальной несводимостью свойств системы к сумме свойств составляющих ее элементов.

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

Необходимо ввести ряд характеристик, фиксирующих содержание информации:

- семантическую, характеризующую смысловое значение информации;

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

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

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

Анализ информационных свойств систем непосредственно связан с понятием ее сложности, относящейся также к свойствам систем.

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

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

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

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

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

Касаясь понятия «элемент бизнес-системы» мы лишь упомянем, какие элементы в действительности насыщают бизнес-систему.

Все имеющиеся элементы бизнес-системы нужно подразделять на внешние и внутренние элементы.

К основным внутренним элементам бизнес-системы мы можем отнести следующие:

- организационная структура;

- политика, правила, нормы организации;

- кадры;

- информация;

- труд;

- финансы;

- технико-технологическое обеспечение;

- культура.

Основные внешние элементы бизнес-системы можно представить в следующем составе:

- социальная и демографическая среда;

- экономическая и политическая среда;

- предпринимательская среда.

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

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

В большинстве работ по проблеме реинжениринга бизнес – процессов (БПР) первичному анализу подвергаются три основных элемента. По формулировке Хаммера и Чампи эти элементы были классифицированы как три «К» (в английском варианте – three “C”: Clients, Competition, Change) – Клиенты, Конкуренты, Коренные изменения.

Углубляясь в изучение признанного классического труда по БПР американских ученых М.Хаммера и Дж.Чампи «Реинжиниринг корпораций: манифест революции в бизнесе», мы находим, что главным стержневым элементом, который выводит на переосмысление значения бизнес-процессов в организации является клиент. Именно для клиента строят бизнес, именно ради него компании создают сложные маркетинговые стратегии, именно клиент дает возможность развиваться компаниям. Поэтому именно в случае получения позитивного и ясно оцениваемого результата для клиента будет иметь значение работы по реинжинирингу бизнес-процессов. Далее при описании стандарта IDEF мы будем более подробно говорить о том, какими методами должна осуществляться оценка результата, получаемого на завершающей стадии БПР.

* * * * *

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

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

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

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

Б) Реинжениринг программного обеспечения. Это более область деятельности для программистов, специалистов в области информационных технологий. На основе современных технологий производит переписывание устаревших информационных систем без изменения самих автоматизируемых процессов.

В) Уменьшение размерности организации. Эта работа производит уменьшение возможностей компании, вызванные снижением требований рынка, в отличие от реинжиниринга, который напротив увеличивает потенциал организации.

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

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

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

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

В завершающей части введения в предстоящий экскурс по изучению стандартов IDEF, как инструмента БПР, хотелось бы затронуть еще одну важную тему.

Если вернуться к вышеперечисленным пунктам, того, что не является реинжинирингом, то стоит обратить внимание к пункту А.

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

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

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

Для данного сравнительного анализа ниже представлена таблица с перечислением основных методологических отличий и сходств между автоматизацией работы компании и осуществлением в компаниях БПР.

Таблица 2

Цель настоящего введения заключается в раскрытии основ БПР. Особенное внимание нужно уделить изучению фундаментального термина реинжиниринга – «процесс». Именно процессный подход лежит в основе методологии реинжениринга.

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

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

Проводя реинжиниринг нужно стать абсолютным максималистом. Этому нас учат выдающиеся основоположники методологии реинжиниринга М.Хаммер и Дж.Чампи в своих работах.

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

Только используя опыт проведения реинжиниринга бизнес-процессов западных компаний, таких как Корпорация Форд Моторс, Истман Кодак, Ай Би Эм можно попытаться получить такой результат, который заложен в основу идеологии реинжиниринга.

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

Российские компании терпят миллионные убытки, продолжая работать по-старому.

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

Еще одной из идеологий реинжиниринга является бескомпромиссность.

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

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

Хотелось бы отметить, что в последние 4-5 лет в России были опубликованы несколько работ, посвященных теме БПР. Однако большая часть из них являлась пересказом труда М.Хаммера и Дж.Чампи «Реинжиниринг корпорации: манифест революции в бизнесе». В данной работе мы постарались уйти от штампа работ по реинжинирингу бизнес-процессов и предложили на ваш анализ CASE блоки по стандарту IDEF.

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

Для вступления во вторую часть статьи хотелось бы сказать пару слов про сам стандарт и его предысторию.

Стандарт IDEF (Integrated computer aided manufacturing DEFinition), чаще называемый технологией структурного анализа и проектирования (SADT) была разработана американской корпорацией СофтТех, Инк. в конце 60-х годов, как инструмент инженерии для разработки машинных и человеческих комплексных систем. Затем ВВС США приняли в конце 70-х годов на вооружение большую часть технологии SADT, назвав в будущем ее IDEF0 как часть своей Интегрированной компьютерной производственной программы (ICAM) и технология скоро стала стандартом технологии моделирования действий для Министерства обороны США.

В 1993 году Группа Пользователей IDEF (в настоящее время Общество Организационного Проектирования) в содружестве с Национальным Институтом Стандартов и Технологии предприняли попытку создать документированный стандарт для IDEF0, для последующего использования и гражданскими, и военными службами Правительства и министерств США. Данный стандарт носит имя Федеральный стандарт обработки информации (FiPS).

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

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

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

В следующей части статьи мы перейдем уже к изучению IDEF стандартов и рассмотрим три стандарта моделирования бизнес-процесса:

1. IDEF0 – стандарт функционального моделирования.

2. IDEF3 – обзорный метод описания процесса.

3. DFD (Data Flaw Diagramming) – диаграммы потоков данных.

Часть 2.

Стандарт IDEF – инструмент реинжиниринга бизнес-процессов

ВВЕДЕНИЕ

В первой части статьи мы рассмотрели концептуальные основы реинжиниринга бизнес-процессов.

Во второй части будут рассмотрены три методики описания бизнес-процессов:

1. Метод функционального моделирования – стандарт IDEF 0;

2. Метод описания технологии бизнес-процесса – стандарт IDEF 3;

3. Метод описания потоков информационных данных – метод DFD.

Представление вышеназванных методик описания бизнес-процессов будет осуществлено по следующему принципу:

- в первую очередь будет рассматриваться сама методика, ее синтаксис и семантика;

- во-вторых, будет представлен для анализа пример бизнес-процесса, описанный на основе одной из методик с его подробным текстовым описанием;

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

2.1. Описание стандарта IDEF 3

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

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

Однако стандарт IDEF 3 также может быть использован как метод описания бизнес-процесса. Модель стандарта IDEF 3 обычно используется как дополнение к модели, спроектированной в стандарте IDEF 0, и получила широкое распространение как метод построения дизайна модели, который в последствии станет предметом анализа. Симуляция модели обычно применяется для оценки бизнес-системы, проектируемой в данный отрезок времени.

Любой стандарт структурного анализа и проектирования (САПР) состоит из компонентов, которые имеют свои отличительные особенности.

Компонентами стандарта моделирования процесса принято считать элементы, изображенные на диаграмме модели.

К компонентам стандарта IDEF 3 следует отнести следующее:

- диаграммы;

- действия;

- связи;

- узлы;

- ссылки.

Диаграмма.

Как и в других методиках моделирования процесса, в стандарте IDEF3 диаграмма является основным структурным элементом. Построение диаграммы в стандарте IDEF3 особенно важно в случае ее дальнейшего прочтения другими специалистами.

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

Действие.

Единица работы (действие), является центральным компонентом модели бизнес-процесса. В стандарте IDEF3 на диаграмме действие изображается в форме прямоугольника. В диаграмме стандарта IDEF3 действие описывается в сочетании слова в форме глагола и объекта, на которое воздействует действие и в добавление ему присваивается уникальный идентификационный номер.

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

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

В диаграммах стандарта IDEF3 уникальный номер действия обычно располагается после номера «родительского» действия.

Связи

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

Таблица 1 Типы связей.

Временной прецедент

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

Объектопоток

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

Реляционная

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

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

Обычно реляционная связь используется для описания особенных случаев прецедентной связи.

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

Узлы

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

1. Разветвляющий узел:

- завершение одного действия приводит к активации других действий.

2. Консолидирующий узел (узел слияния):

- завершение одного или более действий приводит к активации всего лишь одного действия.

Таблица 2 Описание типов узлов

Узел «И».

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

Узел «Эксклюзив «ИЛИ».

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

Узел «ИЛИ».

Узел «ИЛИ» приводит в действие такие комбинации процесса, которые не могут быть описаны ни узлом «И» (все действия), ни узлом «Эксклюзив «ИЛИ» (одно и только одно действие). Так же как и реляционная связь, использование узла «ИЛИ» определяется самим автором по его усмотрению.

Синхронные и несинхронные узлы.

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

Таблица 3 Описание синхронных и несинхронных узлов

Синхронный узел отличается двумя вертикальными прямыми внутри квадрата узла. В противоположность, несинхронный узел изображается с одной вертикальной прямой в левой стороне квадрата узла.

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

Пары узлов.

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

Комбинации узлов.

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

Ссылки

Ссылки – это специальные символы, которые дают ссылку на иные особенности описываемого процесса. Они добавляются к диаграмме, чтобы обратить внимание читателя к чему-то важному.

Таблица 4 Ссылки

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

OBJECT/Кладовщик

ССЫЛКА ИДЕНТИФИКАТОР

^{“ OBJECT ”}

Рис 1 Пример ссылки

Декомпозиция действия.

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

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

2.2. Пример: модель бизнес-процесса, созданная на основе стандарта IDEF 3.

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

Для этого мы в модели создадим двух субъектов:

- субъект №1 – оператор сотовой связи;

- субъект №2 – абонент услуг сотовой связи, предлагаемых субъектом №1.

Субъект №1 выполняет следующий набор функций (действий):

- обработка данных по лицевому счету абонента;

- поиск электронной карточки абонента;

- проверка на наличие денежных средств на электронной карточке абонента;

- зачисление принятых от абонента денежных средств на лицевой счет абонента;

- распечатка приходного кассового чека.

Субъект №2 осуществляет в данном бизнес-процессе следующий набор функций (действий):

- проверка денег на своем лицевом счете;

- проверка личной электронной карточки абонента;

- определение вносимой денежной суммы;

- оплата счета;

- приемка приходного кассового чека.

Таким образом, после определения функций для каждого субъекта процесса нам следует перейти непосредственно к описанию модели, построенной на основе методики стандарта IDEF3.

Рис. 2 Модель бизнес-процесса на основе стандарта IDEF 3

Теперь попытаемся детально рассмотреть все составные элементы в представленной модели бизнес-процесса. Но для начала приведем текстовое описание представленной выше модели.

Действие первое: «Проверка денег на счете».

Данное действие осуществляется в самом начале самим абонентом (субъектом №2). Цель данного действия – определить остаток денежных средств на лицевом счете и в случае недостаточности средств продолжить выполнять действия по процессу, либо в случае удовлетворения достаточным количеством денежных средств на счету, приостановить дальнейшие действия.

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

Действие второе: «Обработка данных по счету».

Данное действие начинается только после завершения предыдущего действия. Второе действие имеет особенность, которая отражена в добавлении к нему ссылки «Кассир». Это, в частности, означает, что автор модели подчеркивает, что действие «Обработка данных по счету» выполняется Кассиром Субъекта №1. Действие не декомпозировано, т.к. имеет в левом верхнем углу прямоугольника поперечную черту. (На это надо обращать внимание при прочтении диаграмм стандарта IDEF).

Действие третье: «Поиск карточки абонента».

В случае с третьим и четвертым действием диаграммы добавлен несинхронный разветвляющий узел «ИЛИ». Узел «ИЛИ», в данном случае, означает, что действия «Поиск карточки абонента» и «Проверка личной карточки» происходят параллельно друг другу, но не начинаются в одно время. Помимо этого узел «ИЛИ» в данном контексте означает, что автором модели определено то, что либо действие третье, либо четвертое активизировано.

Действие четвертое: «Проверка личной карточки».

Данное действие также как и действие «Обработка данных по счету» имеет ссылки «Абонент» и «Кассир». Это означает, что автором модели показано, кто участвует в данном действии.

Консолидирующий несинхронный узел «И».

В данном контексте узел «И» означает, что только после завершения действия третьего и четвертого возможно продолжение процесса внесения денег на счет.

Действие пятое: «Определение вносимой суммы».

Данное действие не имеет декомпозиции (черта в верхнем левом углу) и имеет ссылку «Абонент», что как уже известно указывает на субъекта, участвующего в данном действии.

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

Действие шестое: «Оплата счета».

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

Действия седьмое и восьмое: «Приемка денег» и «Подсчет денег».

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

Действие десятое: «Приемка чека».

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

На этом действии бизнес-процесс завершается и, как видно, не обладает цикличностью.

2.3. ОПИСАНИЕ СТАНДАРТА IDEF 0

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

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

К компонентам стандарта IDEF 0 следует отнести следующие:

- функции (действия);

- связи;

- диаграммы;

Метод IDEF0 комбинирует графическую ограниченность (в модели присутствуют только два символа: прямоугольник и интерфейсная стрелка) со строгим и хорошо определенным процессом, которыми создается модель для улучшения качества законченности процесса.

В первую очередь при построении IDEF0 модели нужно определить цель модели, то есть группу вопросов, на которые предназначено ответить модели. Эти вопросы должны быть составлены как часть документации к модели.

Масштаб модели состоит из широты и глубины детализации.

1. Функция (Activity).

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

Раннее мы отмечали, что метод IDEF0 моделирует систему как иерархию действий. Действие может быть декомпозировано на его составные части. Если мы изображаем модель IDEF0 как прямоугольник, то мы можем, как бы, увидеть декомпозицию действия, заглянув внутрь его прямоугольника, обозревая одновременно те действия, из которых рассматриваемое действие состоит. Декомпозиция обычно сравнивается с моделированием «сверху вниз». Однако это заблуждение.

2. Границы и интерфейс (интерфейсные стрелки) (Boundary & Interface).

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

В модели IDEF0 мы также моделируем контроль и механизмы. Контроль является объектами, которые управляют методами, в которых входы трансформированы, но не трансформированы действиями. Механизмы – это такие объекты, которые осуществляют трансформацию входов в выходы не самостоятельно, а действием.

ИКОМ – это аббревиатура для категорий информации, которая заложена в основу диаграммы метода IDEF0.

Она представляет из себя четыре типа стрелок:

- И (input) – Вход – то, что потребляет процесс.

- К (control) – Управление – влияние на операцию процесса.

- О (output) – Выход – результат процесса.

- М (mechanism) – Ресурс – то, что используется для осуществления процесса, но не употребляется процессом.

Рис. 3 Описание действия в стандарте IDEF 0

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

Интерфейсная стрелка «вход» (Input).

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

Интерфейсная стрелка «управление» (Control).

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

Интерфейсная стрелка «ресурс» (Mechanism).

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

Интерфейсная стрелка «выход» (Output).

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

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

Комбинации стрелок интерфейса (Arrows Combinations).

Существует пять основных комбинаций стрелок интерфейса:

«выход --- вход», «выход – управление», «выход – ресурс», «выход – управление с обратной связью», «выход – вход с обратной связью».

Интерфейсная стрелка «выход – вход» описывает действие, которое предшествует другому действию и является первоочередным.

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

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

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

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

Разветвление и соединение (Branching & Joining).

«Выходы» какого –либо действия могут быть использованы более, чем одним другим действием. Метод IDEF0 позволяет визуализировать зависимости между собой действий внутри системы. Интерфейсные стрелки метода IDEF0 могут разветвляться и соединяться.

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

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

Интерфейсные стрелки ссылки (Call Arrow).

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

Туннели (Tunnels).

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

Действия и активация действий (Activities & Activities Activation).

Мы можем декомпозировать модель для анализа отдельных действий. Мы также можем изначально создать отдельные IDEF3 диаграммы для каждого из этих действий. Эта методика требуется в случае, если мы хотим оценить действия, используя симуляторы.

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

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

Таблица активации

Информация по активации в таблице мало говорит нам о содержании интерфейсной стрелки управления для данного действия.

2.4. Компоненты диаграммы стандарта IDEF 0.

Границы диаграммы строго очерчены вверху и внизу. Верхние элементы границы используются для отслеживания модели в процессе работы над ней. Нижние элементы границы отражают особенности диаграммы и ее место в иерархии.

Верхние элементы границы следующие:

Нижние элементы границы диаграммы следующие:

2.5. Некоторые правила построения модели.

Ни одна модель не может быть создана без конкретного объекта или цели. Формулировка цели должна ответить на следующие вопросы:

- почему был смоделирован представленный процесс;

- что эта модель собирается показать;

- что с ней могут сделать читающие ее.

Формулировка цели позволяет команде экспертов придерживаться ее на протяжении всего процесса моделирования. Без формулировки цели моделирование может зайти в тупик.

Модели создаются для получения ответа на ряд вопросов. Данные вопросы должны подготавливаться заранее и будут служить основой для создания цели модели. Примерные вопросы могут звучать следующим образом:

-каковы основные задачи сотрудника;

-кто отвечает за произведенную продукцию;

-кто управляет начальной стадией производства;

-какой требуется инструмент для каждого этапа.

Точка зрения (Viewpoint).

Особенно важно включать в процесс разработки модели представителей различных мнений, однако сама модель должна базироваться на единой точке зрения. Чаще всего разнообразные точки зрения кратко фиксируют на диаграмме ФЕО (англ. FEO, For Exposition Only. Русс. --- только для комментариев).

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

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

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

Границы (Boundary).

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

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

Граница имеет два компонента --- широту и глубину. Широту модели определяют боковые границы процесса. Глубину определяет уровень декомпозиции действий.

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

Когда границы определены, то действия, не вошедшие в модель также проясняются.

Присвоение названия системе (действию).

Рекомендуемая последовательность действий при моделировании

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

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

Важно всегда начинать с определения целей, точек зрения и границы модели. Четкое определение этих позиций важно для всего процесса моделирования.

Определение основных параметров ИКОМ.

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

1. Определение выхода.

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

2. Определение входа.

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

3. Определение ресурса.

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

4. Определение управления.

В завершении следует добавить интерфейсную стрелку «управление», управляющую действием. Управление существует в форме правил, регламента, политики, процедур или стандартов. Всем действиям в IDEF0 требуется хотя бы одна контрольная интерфейсная стрелка. Контроль является формой входа в действие.

Когда контекстная диаграмма становится завершенной и стабильной, задайте к ней следующие вопросы:

--- диаграмма суммирует действия, которые будут смоделированы;

--- контекстная диаграмма сочетается ли последовательно с границей, точкой зрения и целями;

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

--- есть ли согласие рабочей группы по поводу модели.

5. Нумерация действий и диаграмм.

Все действия в стандарте IDEF0 пронумерованы. Может быть использован префикс любой длины, но почти во всех моделях использован символ А. После префикса следует число. Базовое действие всегда нумеруется символом А0. Префикс повторяется для каждого действия. Числа используются для представления того, как детализированы действия. Действие А0 декомпозировано в А1, А2, А3 и т.д. А1 также декомпозировано в А11, А12, А13 и т.д. А 11 также декомпозировано в А111, А112, А113 и т.д. К каждому уровню декомпозиции добавляются последовательные дополнительные цифры. Единственное исключение к этому формату --- это первый уровень, где А0 декомпозирован не в А01, А02 и т.д., а в А1, А2 и т.д.

6. Взаимоотношения диаграммы с родительским действием (границы и иерархия).

Действие декомпозируется, если для его понимания необходима большая детализация. Когда действие декомпозируется, не забывайте о его жизненном цикле. Это предопределяет список кандидатов в дочерние действия. К примеру, узел «делать пирожные» может иметь жизненный цикл «собирать ингредиенты», «приготовить масло», «печь тесто» и т.д.

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

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

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

7. Моделирование «вширь» и «вглубь».

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

2.6. Пример: моделирование бизнес-процесса на основе стандарта IDEF 0.

Для перехода к непосредственному практикуму по стандарту IDEF0 нами была предложена модель процесса консалтингового проекта. Для более простого анализа предложенной модели нами были выделены и сформулированы основные функции консалтингового проекта. Предлагаемые ниже функции взяты из книги «Управленческое консультирование» под редакцией Милана Кубра.

Итак, перечень функций консалтингового проекта состоит из пяти компонентов:

1. Подготовка к консультационному заданию.

2. Диагностика.

3. Планирование действий.

4. Внедрение.

5. Завершение.

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

Подготовка к консультационному заданию.

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

- контакты с клиентом;

- предварительная диагностика проблемы;

- формирование технического задания;

- формулирование предложений клиенту;

- заключение контракта на проведение консалтинговых работ.

Схематически рассматриваемую функцию можно представить следующим образом:

Рис.2 Действие отображаемое в стандарте IDEF 0

Диагностика.

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

В нашей модели основными компонентами функции «Диагностика» являются:

- выявление необходимых факторов;

- анализ и синтез материала;

- детальное изучение проблемы.

Диагностика схематически представлена ниже.

Рис.3 Диагностика

Планирование действий.

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

В данной функции модели выделены следующие компоненты:

- выработка решений;

- оценка альтернативных вариантов;

- предложения клиенту;

- планирование практической реализации решения.

Как и в предыдущих двух функциях ниже представлен блок «Планирование действий».

Внедрение.

Эта функция осуществляет реализацию разработанных ранее консультантами решений проблем клиента. Компонентами описываемой функции принято считать:

- помощь в осуществлении предложенного;

- корректировка предложений;

- обучение персонала клиентской компании;

- планирование и контроль за внедрением.

Ниже представлена модель функции «Внедрение» на основе стандарта IDEF0.

Рис.5 Внедрение

Завершение.

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

- оценка сделанного;

- конечный отчет;

- расчет по обязательствам;

- оценка планов на будущее;

- уход консультанта.

Рис.6 Завершение

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

Рис. 8 Бизнес-процесс консалтингового проекта

2.7. Описание метода DFD ( DataFlaw Diagramming ) (Метод Гэйна – Сарсона)

Также как и стандарт IDEF0 диаграммы потоков данных (DFD) моделируют систему, как сеть действий, связанных друг с другом. Диаграммы потоков данных также моделируют «холдинг-резервуар» (holding tank) сохранения данных, а также внешние элементы, которые указывают на связи с объектами за пределами созданной системы.

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

Диаграммы потоков данных часто ассоциируются с разработкой программных продуктов, т.к. они разрабатывались изначально для этих целей. Данное изображение объекта в диаграмме было разработано Крисом Гэйном и Тришем Сарсоном – авторами метода разработки диаграмм потоков данных (метод Гэйна – Сарсона). Действия представлены в форме прямоугольника с закругленными углами. Подобно этому можно рассматривать метод DFD Юрдона – Де Марко, в которых кружками (шариками) изображаются действия.

Синтаксис и семантика модели DFD .

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

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

Действие.

Действие в диаграммах DFD представляет функцию, которая обрабатывает или трансформирует входы в выходы. Хотя обычно они изображаются в виде прямоугольника с закругленными углами, однако, действия в диаграммах DFD – те же действия, что и в стандартах IDEF0 и IDEF3. Как и в IDEF3 действиях, действия в DFD имеют вход и выход, но не обладают интерфейсными стрелками «управление» и «ресурс», как в стандарте IDEF0. В некоторых моделях Гэйна – Сарсона «ресурс» стандарта IDEF0 изображается как ресурсы и добавляется вниз прямоугольника.

Внешние элементы (External Entities).

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

Интерфейсные стрелки (поток данных) ( Arrows ).

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

Хранение данных ( Data Storage ).

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

Разветвление и соединение.

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

Интерфейсные стрелки могут также сходиться (соединяться) для формирования агрегированных объектов.

Построение модели DFD

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

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

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

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

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

Нумерация объекта.

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

Уникальные числа относятся к каждому хранилищу данных либо внешним ссылочным именам вне зависимости от нахождения объекта на диаграмме.

Каждый номер хранилища данных содержит префикс «D» и уникальный номер хранилища.

Каждая внешняя ссылка включает в себя префикс «E» и уникальный номер внешнего элемента.

2.8. Пример: моделирование процесса обмена данными на основе метода DFD .

В случае с методом DFD рассмотрим построение модели на примере документооборота, существующего внутри консалтингового проекта на стадии анализа и сбора данных для оптимизации организационной структуры управления (ОСУ).

На стадии диагностики ОСУ выделяют следующие основные области для анализа:

– принятие управленческих решений;

- скалярная цепь;

– функций управления;

– «зоны прав и ответственности» в организации.

Ниже представлена диаграмма DFD описания обмена данными на стадии диагностики ОСУ.

Рис.9 Модель описания процесса обмена данными при диагностике ОСУ

2.9. Выводы по второй части

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

Завершая вторую часть статьи о стандарте IDEF, хотелось бы еще раз отметить его основные свойства.

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

Простота синтаксиса и семантики. Стандарт IDEF достаточно прост с точки зрения его освоения. Как уже было показано выше в настоящей статье синтаксис и семантика стандартов IDEF 0 и IDEF 3 содержит набор символьных элементов, каждый из которых носит свое информационное содержание. Нет в стандарте IDEF одинаковых символов с разными свойствами, как и наоборот – нет разных символов с одинаковой трактовкой. Стандарт IDEF обладает строгим понятийным аппаратом, без которого невозможно существование на практике кодированной информации.

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

Возможность использования в электронном виде. Стандарт IDEF также используется и в электронной форме. В частности, он использован в качестве «платформы» для программного продукта BPwin корпорации Logic Works Inc.

В третьей части статьи «Стандарт IDEF – инструмент реинжениринга бизнес-процессов» будет рассмотрен метод функционально-стоимостного анализа, как дополнительного инструмента для моделирования бизнес-процессов с использованием стандарта IDEF.

Часть 3.

Функционально-стоимостной анализ модели бизнес-процесса.

Настоящей статьей мы завершаем серию публикаций по стандартам семейства IDEF (Integrated computer aided manufacturing DEFinition). Несомненно семейство стандартов IDEF более разностороннее и многограннее, чем мы представили во второй части статьи «Стандарт IDEF – инструмент реинжениринга бизнес-процессов». Однако перед нами не стояла цель раскрыть весь спектр методик на основе стандарта IDEF, который бы не уместился в рамках настоящей статьи. Выбранные нами три метода описания бизнес-процессов (IDEF0, IDEF3, DFD) позволяют увидеть полную картину существующего процесса.

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

В качестве базисного метода верификации результатов работы мы будем использовать метод функционально-стоимостного анализа (activity based costing – ABC).

Функционально стоимостной анализ (ФСА) – метод сбора и анализа стоимости функций (activity). С помощью ФСА определяется стоимость ресурсов (сырья, материалов и т.д.), совмещается с функциями процесса, а затем сопоставляет функции с выходами в системе (так называемыми – «Объектами затрат»).

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

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

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

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

При редактировании информации необходимо производить следующие действия:

- проверить полноту данных, полученных на этапе сбора информации;

- проверить ясность записей и их представления;

- исключить и (или) исправить найденные ошибки.

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

В управленческом консультировании особенное место занимают следующие разновидности анализа информации:

- анализ систематизированных данных;

- причинно-следственный анализ;

- сравнительный анализ;

- анализ будущего;

- синтез.

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

- каким образом происходит работа того или иного работника, структурного подразделения;

- какая информация (данные) циркулирует между единицами структурных подразделений. Каким образом эта информация используются компанией;

- каковы затраты на осуществление той или иной операции или всего процесса в целом;

- адекватен ли существующий процесс происходящим изменениям в среде, окружающей компанию;

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

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

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

ФСА позволяет выполнить следующие виды работ:

- определить и провести общий анализ себестоимости бизнес-процессов в организации;

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

- изучить и определить основные, дополнительные и излишние функциональные затраты;

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

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

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

В отличие от традиционных методов ФСА позволяет:

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

2. Распределять накладные расходы в соответствии с детальным расчетом использования ресурсов, подробным представлением о процессах и их влиянии на себестоимость, а не на основании прямых затрат или учета полного объема выпускаемой продукции. При традиционном методе распределения все затраты первоначально собираются на центрах ответственности, а затем распределяются в соответствии с укрупненными базами распределения между продуктами, обычно пропорционально показателям, связанным с объемом производства продукции. Метод ФСА позволяет выявить процессы, которые вызывают возникновение косвенных затрат, связать их с тем или иным продуктом на основе выявления наиболее точной взаимосвязи между продуктами и процессами и наиболее точно перераспределить а продукты соответствующие косвенным затратам. При использовании ФСА также возможно первоначальные отнесения затрат на подразделения, а уже с подразделений на процессы.

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

ФСА – метод учета затрат, основанный на представлении организации как о совокупности процессов, позволяющих производить продукцию и использующих для этого определенные ресурсы. При этом метод ФСА выделяет те процессы, которые не напрямую направлены на производство продукта, а призваны создать некую производственную мощность, позволяющую производить определенный уровень объемом и ассортимента продукции.

В основе метода ФСА не продукты деятельности являются потребителями ресурсов, как это вытекает из традиционных подходов к калькулированию себестоимости, а процессы, которые направлены на производство данных продуктов.

Именно процессы используют ресурсы и получают на выходе определенный продукт.

Именно процессы используют ресурсы и получают на выходе определенный продукт.

В результате использования метода ФСА определяется стоимость каждого процесса, степень его участия в производстве продукта и на основе этих данных – стоимость самого продукта.

К примеру давайте рассмотрим схему формирования себестоимости при методе ФСА:

1 этап. Отнесение стоимости ресурсов на испаользующие их процессы;

2 этап. Определение степени участия процесса в производстве того или иного продукта (услуги);

3 этап. Отнесение стоимости процессов на продукты, в производстве которых они участвуют.

В своей работе «Advanced management accounting» Роберт Каплан и Энтони Аткинсон определяют ФСА как метод, созданный для обеспечения точного метода распределения стоимости косвенных и вспомогательных ресурсов на операции, бизнес-процессы, продукты, услуги и на потребителей. Цель ФСА не в том, чтобы распределить все общие издержки на производимую продукцию, а в том, чтобы измерить и оценить все ресурсы, используемые для операций по поддержке производства и доставке продукции и услуг потребителям.

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

И все же, что метод ФСА предоставляет исследователю в качестве аналитического инструмента?

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

Это в частности позволяет разложить на три части процесс усовершенствования бизнес-процессов организации:

- конфигурация традиционной модели организации в процессную модель;

- создание модели «как есть» для ее последующего изучения и усовершенствования;

- разработка предложений по радикальному перепроектированию бизнес-процессов (создание модели «как должно быть»).

В процессе построения функционально – стоимостных моделей удалось установить методологическую и технологическую взаимосвязь между IDEF0 и ФСА – моделями.

Связанность методов на основе стандартов IDEF и ФСА заключается в том, что оба метода рассматривают предприятие, как множество последовательно выполняемых функций, а стрелки входов, выходов, управления и ресурсов стандарта IDEF0 соответствуют стоимостным объектам и ресурсам ФСА - модели.

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

На более низком уровне, а именно уровне функционального блока связь IDEF0 и ФСА моделей базируется на трех принципах:

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

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

3. Стоимость или время функции, которая имеет декомпозицию, определяется как сумма стоимостей (времен) всех подфункций на данном уровне декомпозиции.

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

Метод ФСА определяет стоимость ресурсов для производства продукта по следующей формуле:

Эта формула известна как драйвер затрат[1] .

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

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

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

Итак, каким образом определяется драйвер издержек для каждого конкретного бизнес-процесса.

В соответствии с классификацией Каплана-Аткинсона-Иннса-Митчела все драйверы можно разделить на группы:

1. Транзакционные драйверы;

2. Временные драйверы;

3. Драйверы, отражающие интенсивность процесса;

4. Ситуационные драйверы;

5. Мотивационные драйверы.

Коснемся каждого из них в отдельности.

1. Транзакционные драйверы.

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

2. Временной драйвер.

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

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

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

Выбор между временными и транзакционными драйверами должны производиться на основе сбалансированной оценке преимуществ увеличения точности при одновременном увеличении стоимости измерений.

3. Драйверы, отражающие интенсивность процесса.

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

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

4. Ситуационный драйвер.

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

5. Мотивационный драйвер.

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

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

- отражать результат процесса;

- максимально точно отражать поведение затрат (зависимость результата процесса от стоимости используемых ресурсов);

- быть легко измеримыми в отношении его использования тем или иным продуктом;

- давать возможность оценить эффективность и производительность процесса.

Различия между традиционным учетом затрат и методом ФСА.

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

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

Метод ФСА выявляет процессы, которые «вызывают возникновение косвенных затрат, связывает их с тем или иным продуктом на основе выявления наиболее точной взаимосвязи между продуктами и процессами и наиболее точно перераспределяет на продукты соответствующие косвенные затраты» (К. Петров). Однако при использовании метода ФСА сначала также возможно отнесение косвенных затрат на структурные подразделения, а уже с подразделений на конкретные бизнес-процессы.

Результатом определения драйвера затрат будет являться формула расчета стоимости продукта.

Р_п = D x Q, где

Р_п – стоимость продукта,

D – драйвер затрат,

Q – количество потребленного процессом драйвера.

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

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

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

В заключении настоящей статьи для более комплексного изучения метода ФСА ниже приводится пример расчета стоимости продукта.

На первом этапе иллюстрации распределения затрат по методике ФСА нужно произвести группировку драйверов издержек по процессам. Для этого необходимо сначала определить параметры рассматриваемого процесса.

3.1. Пример.

Фирма N осуществляет производство двух изделий – изделие А и изделие Б. Будем считать, что два изделия (А и Б) производятся фирмой N на производственном оборудовании с незначительными техническими отличиями и на разных производственных помещениях. Помимо приведенных различий изготовление двух изделий осуществляется одинаковыми производственными процессами. Основным отличием в данном примере являются объемы выпускаемой продукции. В нашем случае изделие Б производится в большем объеме.

Ниже представлена таблица показателей производства изделий А и Б.

Общая сумма косвенных затрат по данным изделиям составила 71500 у.е.

Итак, теперь обратимся к системе калькулирования себестоимости по методике ФСА.

Разложим косвенные затраты на три части:

1. Косвенные затраты, связанные с объемом производства.

2. Косвенные затраты, связанные с закупкой сырья и материалов (комплектующих).

3. Косвенные затраты, связанные с обслуживанием оборудования.

Ниже представлена таблица калькуляции косвенных затрат (в условных единицах).

И наконец остается провести расчет себестоимости единицы изделия, основываясь на методе ФСА. Ниже приводится примерная таблица подобного расчета (в условных единицах).

Затраты на единицу изделия составляют:

- по изделию А – (10080+2650+666)/3000 ед. = 4,46 у.е.

- по изделию Б – (50400+5300+1332)/15000 ед. = 3,8 у.е.

Часть 4.

Практикум по созданию модели бизнес-процесса, ее анализу и реинжинирингу. (На примере торговой компании).

1. Введение.

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

Работа проектной группы должна быть разделена на десять этапов, которые можно представить в примерном укрупненном порядке:

1. Подготовка к консультационному заданию.

2. Диагностика бизнес-процесса.

3. Построение модели бизнес-процесса «как есть» и его анализ.

4. Подготовка предложений по изменению бизнес-процесса.

5. Разработка моделей бизнес-процесса «как должно быть» и их анализ.

6. Обсуждение и принятие решения по выбору наиболее подходящей модели бизнес-процесса «как должно быть»

7. Реинжиниринг бизнес-процессов.

8. Анализ изменений в работе компании.

9. Корректировка изменений.

10. Завершение.

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

- деловая стратегия компании;

- регламенты всех процессов компании;

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

Результатом реинжиниринга является возможность построения следующих систем:

- бюджетирования;

- управленческого учета;

- мотивации персонала;

- комплексной интегрированной АСУ.

2. Описание организации как объекта управления.

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

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

Далее приводится анкета описываемой организации с примерными характеристиками:

Таблица Анкета организации, демонстрирующая правовые и финансово-экономические характеристики

3. Условия практикума.

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

Итак, что в деталях представляет собой взятая для примера торговая компания.

Первое условие.

Торговая компания учреждена физическими лицами и обладает минимальным уставным капиталом. Сфера деятельности – торговля продуктами питания. Область деятельности (регион) – Москва и Московская область. Продажа и доставка продуктов питания по магазинам, названного выше региона.

Второе условие.

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

1. Департамент закупок.

Включает в себя: 1. Отдел маркетинга; 2. Отдел закупок.

Функции, осуществляемые департаментом:

- анализ конъюнктуры рынка продуктов питания и сопутствующих товаров;

- исследование существующих цен на рынке;

- определение ассортиментной матрицы розничной сети;

- заключение договоров на поставки продукции;

- осуществление закупки товаров и продуктов питания;

- анализ конкурентов;

- формирование ценовой политики;

- формирование общего плана закупки на следующий период;

- разработка бюджета продаж и закупок;

- разработка инструкций и других внутренних нормативных документов.

Количество работников – 5 человек.

2. Департамент логистики.

Включает в себя: 1. Транспортный отдел; 2. Таможенный отдел.

Функции, осуществляемые департаментом:

- осуществление контроля за товарными запасами: текущий товарный запас; товар, находящийся в пути; сформированные заказы поставщику; план закупок;

- осуществление контроля за избыточным товарным запасом;

- обеспечение оптимальных размеров поставки на РЦ;

- анализ поставщиков определенной товарной группы;

- анализ текущего сбыта: динамика сбыта, статистическая информация;

- формирование заказов поставщикам;

- составление спецификаций на товары;

- контроль за поставками товаров;

- ведение общего графика поставок;

Количество работников – 8 человек.

3. Правовой департамент.

Включает в себя: 1. Договорной отдел; 2. Претензионный отдел.

Функции, осуществляемые департаментом:

- составление и визирование договоров;

- анализ представляемых договоров на предмет соответствия их действующему законодательству;

- корректировка договоров;

- составление официальных писем и их визирование;

- осуществление работы с учредительными документами компании;

- анализ действующего законодательства, касающегося основной деятельности компании.

Количество работников – 2 человека.

4. Департамент продаж.

Включает в себя: 1. Отдел по работе с магазинами.

Функции, осуществляемые департаментом:

Количество работников – 6 человек.

5. Департамент по работе с персоналом.

Функции, осуществляемые департаментом:

- подбор и расстановка персонала в ХОЛДИНГЕ;

- составление и визирование штатного расписания;

- ведение кадрового учета ХОЛДИНГА;

- разработка планов и организация мероприятий по профессиональному обучению работников ХОЛДИНГА;

- составление инструкций по технике безопасности;

Количество работников – 3 человека.

6. Административно-хозяйственная служба.

Функции, осуществляемые департаментом:

- организация и обеспечение рабочих мест сотрудников компании.

- техническое сопровождение взаимодействия с клиентами и партнерами.

Количество работников – 3 человека.

7. Финансовый департамент.

Включает в себя: 1. Бухгалтерия; 2. Финансово-аналитический отдел.

Функции, осуществляемые департаментом:

- проведение инвентаризации и ревизии всех компаний ХОЛДИНГА;

- планирование доходной и расходной частей ХОЛДИНГА;

- анализ потоков денежных средств;

- отслеживание всех платежей;

- расчет заработной платы персонала ХОЛДИНГА;

- организация и проведение налогового планирования.

Количество работников – 6 человек.

8. Складское хозяйство.

Функции, осуществляемые департаментом:

- организация и ведение складского учета.

Количество работников – 15 человек.

Третье условие.

Торговая компания обеспечена собственными финансовыми ресурсами на 50%, а также заемными финансовыми ресурсами на 50%.

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

В компании поставлен только бухгалтерский учет.

Описание бизнес-процесса торговой компании «как есть» (“as is”).

На данном этапе осуществляется систематизация процессов организации. Ключевые вопросы, на которые необходимо получить ответы на этом этапе:

1. Каковы главные процессы в деятельности организации?

2. Как эти процессы соотносятся с процессами потребителей и поставщиков?

3. Каковы перспективные бизнес-процессы организации?

4. Какие бизнес-процессы должны быть изменены и в какой срок?

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

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

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

Для определения методов, используемых при сборе данных для анализа модели бизнес-процесса ниже нами приводится сводная таблица.

Описание бизнес-процесса мы разделим на два этапа: текстовое описание и схематическое представление текстового описания.

Текстовое описание.

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

Именно из текстового описания рождается схематическое представление процесса (модель процесса).

Итак, в нашем примере необходимо будет описать бизнес-процесс торговой компании.

Схематическое представление текстового описания бизнес-процесса.

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

Ниже представлен изучаемый нами процесс.

Схема 1. Контекстная диаграмма процесса складирования и отгрузки товаров

Схема 2.1. Начало процесса (Собирание товаров)

Схема 2.2. Продолжение процесса (Проверка товара)

Схема 2.3. Продолжение процесса (Доставка товаров в магазин)

Схема 2.4. Продолжение процесса (Обработка товара в магазине)

Схема 2.5. Продолжение процесса (Открытие магазина)

4. Функционально-стоимостной анализ модели бизнес-процесса «как есть».

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

Попроцессный стоимостной анализ строится исходя из пяти этапов, описываемых ниже:

1. Анализ бизнес-процесса.

2. Анализ и группировка издержек:

- затраты на оплату труда:

- зарплата и ее разновидности;

- изменения размеров оплаты;

- премиальные выплаты;

- выплаты за сверхурочные работы;

- временные затраты на заполнение вакансий.

- Затраты на поставщиков;

- Затраты на оборудование (производственное и непроизводственное);

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

- Затраты на расходные материалы;

- Дополнительные (переменные) издержки.

3. Перераспределение издержек по соответствующим элементам бизнес-процесса:

- идентификация организационных издержек;

- распределение организационных издержек по организационным элементам;

- определение категорий организационных элементов;

- распределение затрат по видам издержек (прямые, косвенные, переменные, постоянные издержки);

- перераспределение организационных издержек на элементы бизнес-процесса;

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

4. Определение типов и параметров измерений выходов процесса:

- анализ выходов;

- выбор типа измерений для выходов процесса;

- детерминация затрат на выходы бизнес-процесса к единице выхода элемента процесса.

5. Анализ полученных издержек:

- метод Парето;

- бенчмаркинг;

- метод аналогий;

- метод добавленной потребительной стоимости;

- сравнительный анализ;

- метод позитивного результата (сокращения издержек);

- экономический анализ;

- функциональный экономический анализ.

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

1. Анализ бизнес-процесса.

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

2. Анализ и группировка издержек.

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

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

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

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

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

Издержки по оплате труда. (Почасовая оплата труда, увеличения оплаты труда, премии и бонусы, плата сверхурочных, затраты на привлечение рабочей силы).

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

Аренда технологического (либо иного типа) оборудования.

Издержки на сырье и ресурсы, непосредственно используемые в производстве продукции (услуг).

Издержки на расходные материалы.

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

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

Таблица Итоговая годовая аналитическая таблица издержек компании

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

3. Перераспределение издержек по организационным элементам.

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

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

Выявленные издержки группируются по следующим группам: прямые издержки, постоянные издержки, переменные издержки, косвенные издержки, полные издержки, издержки распределения.

Ниже в таблицах демонстрируется распределение издержек по структурным подразделениям организации и по группам издержек.

Таблица Распределение издержек по организационным элементам

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

4. Перераспределение организационных издержек по элементам бизнес-процесса.

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

Ниже представлена таблица с уже сгруппированными издержками, распределенными по соответствующим классам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети».

Таблица Распределение издержек по классам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети»

Распределив издержки по классам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» далее необходимо перераспределить эти же издержки, но уже по экземплярам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети».

В рассматриваемой модели бизнес-процесса выделены следующие экземпляры:

- сборка товара;

- проверка товара;

- доставка товара в магазин;

- обработка товара в магазине;

- открытие магазина.

Таблица Распределение издержек по экземплярам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети»

Из таблицы видно, что наибольший объем издержек находится в экземплярах бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» - «Сборка товара» (56 160 у.е.) и «Доставка товара в магазин» (49 160 у.е.).

5. Детерминация затрат по выходам бизнес-процесса, рассчитанная на единицу выхода экземпляра бизнес-процесса

В настоящем разделе осуществляется калькуляция затрат на единицу выпуска бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети». В данном случае единицей выпуска будет принято считать стоимость обслуживания одного магазина. После получения результата калькуляции по методике ФСА производится сравнение месячных показателей с данными традиционного учета.

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

Таблица. Нормативы бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети»

Разложим все затраты на три части:

4. Прямые затраты, связанные с объемом отгрузок товара со склада.

5. Косвенные затраты, связанные с закупкой материалов и комплектующих.

6. Косвенные затраты, связанные с обслуживанием оборудования.

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

Первой таблицей производится разнесение экземпляров бизнес-процесса относительно класса бизнес-процесса первого уровня «Обработка заказов и отгрузка товаров со склада в магазины сети». Такое разнесение позволит определить объем участия конкретного экземпляра бизнес-процесса и рассчитать индивидуальные затраты на единицу процесса.

Таблица Объем участия экземпляров бизнес-процесса, порождающих накладные расходы

Расчет затрат каждого экземпляра бизнес-процесса производится следующим образом:

Из таблицы «Распределение издержек по экземплярам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» в итоговой строке берется показатель, соответствующая названию экземпляра (например, затраты экземпляра бизнес-процесса «Собрать товар» равны 56160 условных единиц (у.е.)). Далее этот показатель умножается на коэффициент участия данного экземпляра в классе бизнес-процесса первого уровня (в нашем случае коэффициент равен 0,4 (40%). Расчет представляется следующим образом: 56160*0,4=22464. Полученный результат показывает затраты по сборке товара внутри класса первого уровня. Теперь для определения показателя затрат на единицу процесса необходимо затраты по сборке товара, полученные в предыдущем примере, разделить на количество отгрузок товара в магазин сети (см. таблицу «Нормативы бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети»). Расчет показателя будет представлен следующим образом: 22464/250=89,85 у.е. на единицу процесса.

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

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

Таким образом, в стоимость процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» в месяц составит 56310 у.е. (стоимость единицы процесса (225,24) умноженная на коэффициент использования (250). Средние организационно-производственные затраты компании в месяц составляют 47280 у.е. Учитывая, что данные по издержкам (прямым, косвенным, постоянным и т.д.) компании были получены путем изучения отчетности компании, которая ведется традиционным способом, можно с уверенностью сделать вывод о неточностях традиционного представления данных об издержках. Среднегодовые затраты на складское хозяйство составляют 194660 у.е. (см. Таблицу «Распределение издержек по организационным элементам»). Таким образом согласно традиционному учету затрат, средние издержки на складское хозяйство в месяц составляют 16222 у.е. Разница наглядно представлена ниже в таблице.

Таблица Разница между видами учета

5. Анализ временных затрат.

Без анализа временных затрат полноценных выводов и предложений по совершенствованию модели бизнес-процесса «как есть» сделать будет невозможно.

В процессе сбора данных по издержкам компании для осуществления ФСА, в складском хозяйстве было проведено хронометрирование основных экземпляров бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети». Форма хронометража представлена ниже.

Таблица Форма самофотографии рабочего дня

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

Таблица Анализ временных затрат (или анализ скалярной цепи)

Общее количество времени, затрачиваемое на бизнес-процесс «Обработка заказов и отгрузка товаров со склада в магазины сети», составляет: 10 час. 58 мин.

6. Рекомендации по реинжинирингу бизнес-процесса.

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

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

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

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

Упразднение складского хозяйства позволит компании достичь следующих результатов:

1. Уменьшение издержек.

2. Оперативность в доставке товара в магазины сети (по принципу «just in time»).

3. Сокращение персонала компании.

4. Повышение уровня автоматизации производственно-хозяйственной деятельности.

5. Сокращение количества поставщиков компании. Выбор наиболее подходящих для новой компании условий поставки и соответственно новых поставщиков.

6. Новые возможности экспансии торговой сети компании в регионе.

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

Схема 6.1. Функциональная модель бизнес-процесса «как должно быть»

Таблица Перераспределение функций между участниками бизнес-процесса (первичная модель реинжениринга)

6.1. Модель бизнес-процесса «как должно быть» на основе стандарта IDEF 0.

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

Таблица Функциональная модель бизнес-процесса «как должно быть»

6.1.1. Функциональная модель бизнес-процесса «как должно быть» Поставщика.

6.1.2. Функциональная модель бизнес-процесса «как должно быть» «Центральный офис» (Торговый оператор)

6.1.3. Функциональная модель бизнес-процесса «как должно быть» «Магазин».

7. Функционально-стоимостной анализ модели бизнес-процесса «как должно быть».

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

Шаг № 4. Перераспределение организационных издержек по элементам бизнес-процесса.

Таблица Распределение издержек субъектов «Центральный офис» и «Магазин» по классам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» (в год, в тыс. у.е.)

Распределив издержки по классам модели бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» далее необходимо перераспределить эти же издержки, но уже по экземплярам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети».

В рассматриваемой модели бизнес-процесса «как должно быть» выделены следующие экземпляры:

- сборка товара;

- проверка товара;

- доставка товара в магазин;

- обработка товара в магазине;

- открытие магазина.

Таблица Распределение издержек по экземплярам бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети»

Шаг № 5. Детерминация затрат по выходам бизнес-процесса, рассчитанная на единицу выхода экземпляра бизнес-процесса

Таблица Объем участия экземпляров бизнес-процесса, порождающих накладные расходы

Таблица Расчет затрат на единицу выхода бизнес-процесса по модели «как должно быть»

Таким образом, в стоимость процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» в месяц составит 11272,5 у.е. (стоимость единицы процесса (45,09) умноженная на коэффициент использования (250). Средние организационно-производственные затраты компании в месяц составляли 47280 у.е. Данные по издержкам (прямым, косвенным, постоянным и т.д.) компании были получены на первом уровне расчетов путем изучения отчетности компании, которая ведется традиционным способом. Среднегодовые затраты на складское хозяйство составляли до реинжиниринга бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» 194660 у.е. (см. Таблицу «Распределение издержек по организационным элементам» первого уровня расчетов по методике ФСА). Таким образом ежемесячные издержки на осуществление бизнес-процесса «Обработка заказов и отгрузка товаров со склада в магазины сети» после проведения реинжиниринга составляют 11272,5 у.е. Разница между расчетами первого и второго уровней представлена ниже в таблице.

Таблица Разница результатов стоимости бизнес-процесса после его реинжиниринга

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

7. Заключительные выводы

8. Глоссарий

В Глоссарии мы попытаемся раскрыть основные термины и понятия, встречающиеся в ходе изучения предмета БПР. Однако не будут представлены в глоссарии синтаксические и семантические особенности отдельных стандартов

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

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

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

2. Бизнес-процесс – термин, используемый для описания того, как действия функционируют в бизнесе.

3. Функция – составная часть любого процесса управления. В БПР под функцией имеется в виду не традиционная область ответственности, такая, как сбыт и НИОКР, а область компетенции, такая, как знание конкретного типа продукции, производимой компанией.

4. Действие – это сознательно направленное усилие элемента бизнес-системы, осуществляемое для получения позитивного, оцениваемого результата.

5. Система. Имеет следующие свойства: взаимодействие со средой, целостность, информационность, сложность, иерархичность.

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

7. Процесс – набор операций, которые, взятые вместе, создают результат, имеющий ценность для потребителя.

8. Модель типа «как есть» – модель, которая демонстрирует как бизнес или организация работает в настоящее время.

9. Модель типа «как должно быть» – модель, которая демонстрирует как процессы будут работать в будущем.

10. Декомпозиция модели – анализ функции модели путем расчленения на составляющие ее подфункции (компоненты).

11. Система – объективное единство закономерно связанных друг с другом предметов или целое, состоящее из частей, упорядоченных по определенному закону или принципу.

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

13. Категории бизнес-процессов – существуют следующие категории бизнес-процессов:

- процессы, непосредственно обеспечивающие выпуск продукции;

- процессы планирования и управления;

- ресурсные процессы;

- процессы преобразования.

14. Критерии оценки эффективности бизнес-процессов:

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

- количество потребителей продукции;

- количество типовых операций, которые необходимо выполнить при производстве продукции за определенный интервал времени;

- стоимость издержек производства продукции;

- длительность выполнения типовых операций;

- капиталовложения в производство продукции.

15. Принципы БПР:

- горизонтальное объединение нескольких процессов;

- делегирование права принятия решений непосредственным исполнителям процесса;

- последовательность выполнения шагов процесса;

- сценарное развитие процессов;

- существование плоской иерархической организационной структуры;

- минимизация контрольных воздействий и согласований;

- централизация управления процессом.

16. Реинжиниринг бизнес-процессов – есть «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения существенных улучшений в основных актуальных показателях, таких как: затраты, качество, уровень обслуживания и оперативность» (М.Хаммер, Дж.Чампи).

17. Автоматизация бизнес-процессов – осуществляется автоматизация существующего процесса со всеми его недостатками и не ставит перед собой задачу проектирования нового процесса для кардинального повышения эффективности.

18. Реинжиниринг программного обеспечения («мягкий реинжениринг» (англ. Software reengineering) – на основе современных технологий производит переписывание устаревших информационных систем без изменения самих автоматизируемых процессов.

19. Уменьшение размерности организации (downsizing) – уменьшение возможностей компании, вызванные снижением требований рынка.

20. Реорганизация предприятия – данный метод имеет дело только с организационными структурами, а не с процессами.

21. Глобальное управление качеством (Total Quality Management - TQM) – данный метод принимает имеющиеся процессы и старается их улучшить, а не меняет их на новые.

22. Экспертный вид консультирования – консультант проводит диагностику, разработку решений и рекомендаций по их внедрению.

23. Эксперт – это специалист высокой квалификации, обладающий знаниями, навыками и опытом работы в какой-либо определенной узкой сфере деятельности.

24. Управление – сознательное целенаправленное воздействие со стороны субъектов, органов на людей и экономические объекты, осуществляемое с целью направить их действия и получить желаемый результат.

25. Элемент – это объект, не поддающийся дальнейшему делению на части.

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

27. Технологический процесс – совокупность технологических операций.

28. Проект – сфера деятельности, направленная на изменение какой-либо системы в соответствии с постоянными целями.

29. Информационная система – система хранения, обработки, преобразования, передачи, обновления информации с использованием компьютерной и другой организационной техники.

30. Стандарт IDEF (Integrated computer aided manufacturing DEFinition) – стандарт моделирования, поддерживающий графическое изображение сформированных данных, включая объекты, атрибуты и отношения между объектами.

31. Подпроцесс – это процесс, который осуществляется в контексте большего процесса.

32. Метод DFD (Data Flaw Diagramming – русс. «Диаграмма Потока Данных) – метод, используемый для описания движения и обработки информации внутри бизнеса или организации.

33. Декомпозиция – является способом разделения действия на составные шаги или подпроцессы.

34. Диаграмма – особенное графическое представление данных в моделях IDEF и DFD.

9. Список использованной литературы

1. Kaplan, Robert S. Advanced management accounting/Robert S. Kaplan, Anthony A. Atkinson – 3-ed edition. Prentice Hall, Upper Saddle River, New Jersey, 1998

2. Innes J., Mitchell F. A review of activity based costing practice. Management accounting handbook.// edited by C. Drury

3. ABC Guidebook for Department of Defense, USA, The Electronic College of Process Innovation, 1995

4. Верников Г. Что такое реинжиниринг? // Еженедельный ж-л Консалтинг.ру

5. Зиндер Е. Реинжиниринг бизнес-процессов и автоматизация офиса // Тезисы к конференции

6. Могилевский В.Д. Методология систем: вербальный подход. – М.: ОАО «Издательство «Экономика», 1999

7. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: Реинжиниринг организаций и информационные технологии. – М.: Финансы и статистика, 1997

8. Райзберг Б.А., Лозовский Л.Ш., Стародубцева Е.Б. Современный экономический словарь. – М.: Инфра-М, 1998

9. Философия. – под. ред. Лавриненко В.Н. – М.: Юристъ, 1996

10. Хаммер М., Чампи Дж. Реинжиниринг корпорации: манифест революции в бизнесе. – СПб.: Издательство С.-Петербургского университета, 1997

11. Шумахер В. Устранение препятствий для успеха реинжиниринга // Еженедельный ж-л Консалтинг.ру

12. Петров К. Система калькулирования себестоимости по процессам (Activity-based Costing), С.-Петербург: Лабриум консалтинг, 1999

13. В. Ивлев, Т. Попова Методология функционально-стоимостного анализа АВС (ФСА), М.: Корпоративный менеджмент /www.cfin.ru/

14. С.В. Черемных, И.О. Семенов, В.С. Ручкин Структурный анализ систем: IDEF-технологии, М.: «Финансы и статистика», 2001

* Шумахер В. Устранение препятствий для успеха реинжениринга

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

[1] Драйвер затрат – это количественное выражение объема работы внутри процесса. Драйвер отражает результат процесса. Драйвер должен давать представление о поведении затрат, связанных с процессом и быть идентифицируемым с каждой линией продуктов для осуществления последней стадии калькулирования себестоимости продукта.

* Имеется ввиду книга указанных авторов «Системный подход к организации управления» – М.: Экономика, 1983.