Роль бизнес-процессов в развитии и функционировании организации

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

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

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

Замыкание функций по горизонтали расширяет опасности, а замыкание по вертикали усиливает опасности. И еще раз, бизнес-процессы, замкнутые на одного человека по вертикали, Вы никак не можете контролировать! Графически такая ситуация для одного отдельно взятого бизнес-процесса условно выглядит следующим образом, возьмем на примере IT-службы:. Все медали имеют и свою обратную сторону.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первичный вход - это вход, который инициирует начало бизнес-процесса. В примере с бизнес-процессов "Комиссионирование" заявка на набор заказа является первичным входом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аналогичным образом процессные схемы работ 3. В итоге описание бизнес-процесса представляет собой иерархически упорядоченный набор DFD и WFD схем, в котором схемы верхнего уровня ссылаются на схемы нижнего уровня. При описании бизнес-процессов нижнего уровня используются немного другие процессные схемы, под названием WFD - Work Flow Diagram, что переводится как диаграмма потоков работ.

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

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

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

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

Первый подход мы условно назовем "полным". Более правильно, вероятно, назвать его системным подходом к выделению процессов предприятия как этого требует ISO Рассматриваемый подход базируется на следующих четырех основных положениях: Определение процессного и системного подходов применительно к организации; 2.

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

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

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

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

Они есть в любой организации.

Отрывок из книги Е. Михайленко Архитектура высокоэффективного бизнеса. Как перестать быть заложником обстоятельств и заставить бизнес работать на себя. Функциональные роли участников бизнес-процессов. В каждом бизнес-процессе можно выделить основные функциональные роли участников: Заказчик (тот, кто заинтересован в непосредственном бизнес-процессе); Архитектор (тот, кто создает схему бизнес-процесса); Оперативный менеджер (тот, кто руководит осуществлением бизнес-процесса); Исполнитель (тот, кто непосредственно исполняет тот или иной этап бизнес-процесса). Эти роли зачастую могут совмещаться. Как подойти к выбору 20% приоритетных бизнес-процессов? Для решения этой задачи на практике используют следующие критерии ранжирования процессов: · важность бизнес-процесса; · проблемность бизнес-процесса; · возможность и стоимость проведения изменений бизнес-процесса. Первый критерий — это важность процесса, характеризующая степень его вклада в достижение стратегических целей компании. С чего начинать изменение бизнес-процессов? Начинать изменения необходимо с формулирования целей: какие показатели необходимо улучшить. В том примере, который я приводил, стояла задача увеличить проходимость процесса и даже было понятно насколько.  Анализ такого описания процессов позволяет увидеть "узкие места" и понять, какие могут быть решения. Воплощение этих решений реализуется в схему процессов "как надо". Кто должен принимать участие в изменении бизнес процессов? В первую очередь в изменение бизнес-процессов должно быть вовлечено руководство компании.

Место роли в модели бизнес-процесса | Открытые системы. СУБД | Издательство «Открытые системы»

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

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

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

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

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

Для расширения возможностей RBAC и реализации динамического разделения обязанностей, используется пооперационная модель доступа Task Based Authorization Control, TBAC , предполагающая, что для каждого шага процесса можно индивидуально определить правила отбора исполнителя. В этом случае распределение прав доступа становится динамическим и децентрализованным, а разрешения проверяются, активизируются и отменяются для каждой операции в отдельности.

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

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

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

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

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

Игорь Федоров IFedorov mesi. Какие части ИТ-системы следует в бизнес-системе синхронизировать между собой, чтобы повысить эффективность бизнеса и устранить несогласованность? Прошедшая в Москве конференция выявила возврат интереса к технологиям управления бизнес-процессами. Человек окружил себя существительными: И еще раз, бизнес-процессы, замкнутые на одного человека по вертикали, Вы никак не можете контролировать!

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

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

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

История неоднократно доказывала на практике верность данного постулата. Великая империя Александра Македонского начала разваливаться сразу же после его смерти. Конструкторское бюро Алексеева разработчика катеров на подводных крыльях и экранопланов рухнуло сразу с его уходом.

Доведенные до отчаяния фанатизмом Алексеева сотрудники КБ просто сразу же разбежались, кто куда смог. После смерти Стива Джобса корпорация Apple понесла серьезнейшие финансовые потери.

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

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

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

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

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

Для каждого объекта и связей характерны ряд параметров, или атрибутов, отражающих определённые характеристики реального объекта номер объекта, название, описание, длительность выполнения для функций , стоимость и др. Для описания сложных бизнес-процессов с различными уровнями вложенности рекомендуется использовать несколько нотаций: Пример использования нотации IDEF0: Пример использования нотации EPC: Пример использования нотации Cross Functional Flowchart: Какие бы методологии в описании вы не использовали главное добиться полного понимания бизнес-процесса, таким образом, вы перейдете к следующему этапу — формированию требований к программному продукту и выявлению задач выполняемых с помощью ПО.

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

Ой, у вас баннер убежал! Проблема с программированием 9,1k Обход Капчи 2 отклика 14 просмотров. Натяжка верстки на вп 3 отклика 23 просмотра.

26 авг. г. - Как эффективно распределить функциональные роли в бизнес-процессах и избежать ошибок при завершении процессов. 15 нояб. г. - Цель описания бизнес-процесса – анализ и регламентация тех или . Каждый из нас в роли покупателя, а многие, и в роли продавца. 4 мар. г. - Размещено на meteost.ru Курсовой проект. Роль бизнес-процессов в развитии и функционировании организации. Введение.

Найдено :

Случайные запросы