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

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

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

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

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

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

Основные бизнес-процессы организации

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

• продажи и маркетинг;
• производство и эксплуатацию;
• поддержку клиентов;
• логистику и доставку;
• работу с дилерами и контрагентами;
• внешние инвестиции;
• налоговый учет и уплата налогов;
• работу с акционерами;
• и т.д.

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

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

Вспомогательные процессы организации

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

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

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

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

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

Как идентифицировать и описывать бизнес-процесс

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

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

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

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

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

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

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

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

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

• Каковы основные бизнес-цели вашей деятельности?
• В каких бизнес-процессах вы (ваше подразделение) участвуете, какие основные функции выполняете, каким образом регламентируются ваши функциональные обязанности?
• Какие исходные данные (представленные в бумажной или электронной форме) вы используете для решения основных бизнес-задач?
• Из каких источников вы получаете исходные данные и как организован процесс получения данных?
• Где размещаются данные (документы), с которыми вы работаете?
• Каким образом осуществляется обработка (использование) данных?
• Какие приложения (локальные или серверные) вы используете для получения доступа к данным и обработки данных?
• Как осуществляется работа с приложениями (порядок выполнения основных операций)?
• Каковы предоставляемые вам полномочия по доступу к данным и приложениям?
• Кто еще является пользователями этих данных и приложений, какие полномочия имеются у них?
• За подготовку каких документов (отчетов, БД, справок и т.п.) вы отвечаете (принимаете участие)?
• Кто является заказчиком результатов вашей работы? Кому передаются подготавливаемые вами документы и в каких бизнес-процессах они используются?
• По вашей оценке, насколько критичными для бизнеса компании являются данные, с которыми вы работаете (входные, промежуточные, выходные)?
• Как вы оцениваете возможные последствия (юридические, финансовые, репутационные и т.п.) утечки этой информации (к конкурентам, в прессу, в регулирующие органы, к криминальным элементам и т.п.)?
• Как вы оцениваете возможные последствия нарушения целостности информации (несанкционированная модификация данных, подделка документов, ошибки в отчетах, рассинхронизация БД и т.п.)?
• Как вы оцениваете возможные последствия недоступности информации (в результате сбоя системы, потери данных, случайного стирания или кражи носителей и др.)?
• Каково, по вашему мнению, максимально допустимое время недоступности данных, по истечении которого наступают крайне серьезные последствия для бизнеса компании?
• Какие требования законодательства и нормативной базы регулируют вашу деятельность?
• Каким требованиям клиентов (партнеров) вы должны удовлетворять?
• Какие существуют внутренние требования вашей организации (политики, регламенты, процедуры, инструкции и т.п.), регулирующие вашу деятельность?
• Какие записи создаются в процессе вашей работы?

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

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

Реестр информационных активов

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

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

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

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

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

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

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

• Для комментирования войдите или зарегистрируйтесь

Источник: xn—-7sbab7afcqes2bn.xn--p1ai

Построение (Construction)

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

Внедрение (Transition)

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

Рабочий процесс

В терминах RUP участники проектной команды создают так называемые артефакты (work products), выполняя задачи (tasks) в рамках определенных ролей (roles). Артефактами являются спецификации, модели, исходный код и т.п. Задачи разделяются по девяти процессным областям, называемым дисциплинами (discipline). В RUP определены шесть инженерных и три вспомогательные дисциплины. В них входят:

• Бизнес-моделирование (Business Modeling) – исследование и описание существующих бизнес-процессов заказчика, а также поиск их возможных улучшений.
• Управление требованиями (Requirements Management) – определение границ проекта, разработка функционального дизайна будущей системы и его согласование с заказчиком.
• Анализ и проектирование (Analysis and Design) – проектирование архитектуры системы на основе функциональных требований и ее развитие на протяжении всего проекта.
• Реализация (Implementation) – разработка, юнит-тестирование и интеграция компонентов системы.
• Тестирование (Test) – поиск и отслеживание дефектов в системе, проверка корректности реализации требований.
• Развертывание (Deployment) – создание дистрибутива, установка системы, обучение пользователей.
• Управление конфигурациями и изменениями (Configuration and Change Management) – управление версиями исходного кода и документации, процесс обработки запросов на изменение (change requests).
• Управление проектом (Project Management) – создание проектной команды, планирование фаз и итераций, управление бюджетом и рисками.
• Среда (Environment) – создание инфраструктуры для выполнения проекта, включая организацию и настройку процесса разработки.

Рис. 5. Распределение усилий при выполнении проекта. В ходе жизненного цикла проекта распределение усилий проектной команды между дисциплинами постоянно меняется. Например, как правило, в начале проекта большая часть усилий затрачивается на анализ и дизайн, а ближе к завершению – на реализацию и тестирование системы. Однако в общем случае задачи из всех девяти дисциплин выполняются параллельно. Для полноценного внедрения RUP организация должна затратить значительные средства на обучение сотрудников. При этом попытка обойтись своими силами скорее всего будет обречена на неудачу – необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов.

Источник: studfile.net

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

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

• по объекту — объектно-ориентированный;
• по процессу — процессно-ориентированный;
• по операциям — операционно-ориентированный;

• исполнители:

• организационные звенья (т.е. структурные подразделения — отделы, департаменты, дивизионы и т.д.)
• должности (различные должности из штатного расписания компании, например «Менеджер по продажам»)
• сотрудники (персоналии-ФИО, работники компании, например Иванов Иван Иванович)
• роли (обособленные группы обязанностей, которые может исполнять сотрудник в процессе, обладая при этом и определенными правами. Роли могут в частном случае совпадать с должностью — как по функционалу, так и по названию. Например: Гл. бухгалтер);

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

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

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

• самый популярный в России стандарт BPMN. Business Process Modeling Notation — графическая нотация для моделирования бизнес процессов. BPMN была разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group, после слияния организаций в 2005 году. Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:

• Объекты потока управления: события, действия и логические операторы. Объекты потока управления разделяются на три основных типа: события (events), действия (activities) и логические операторы (gateways).
• Соединяющие объекты: поток управления, поток сообщений и ассоциации
• Роли: пулы и дорожки
• Артефакты: данные, группы и текстовые аннотации.

• Организационной структуры;
• Функциональной структуры;
• Структуры данных;
• Структуры процессов;

• начальная стадия (inception)
• стадия разработки (elaboration)
• стадия конструирования (construction)
• стадия ввода в действие (transition)

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

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

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

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

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

ERP и реинжиниринг бизнес-процессов . Мы обращаем Ваше внимание на то, что под ERP-системой сейчас подразумевается не столько компьютерная программа сама по себе, сколько методология эффективного планирования и управления. Соответственно, установке и настройке ПО предшествуют весьма длительные этапы обследования, моделирования, а также под- или перестройки бизнес-процессов. Т.е. есть необходимость проведения мероприятий, которые принято называть «реинжинирингом бизнес-процессов» (BPR).
В России есть две крайности — или компания, внедряющая ERP-систему, соглашается с фирмой-Исполнителем на реинжиниринг всех бизнес-процессов и их подчинение требованиям базовой функциональности выбранной системы, или же Заказчик настаивает на 100% сохранении сложившейся практики работы и соответственно — кардинальном переписывании кода выбранной системы. Но если сильно изменить программный продукт, то вы в дальнейшем будете вынуждены заниматься сопровождением системы самостоятельно, так как новые версии, поступающие от производителя, не будут учитывать сделанных вами модификаций. Эти две крайности пополняют список причин неудач при внедрении ERP-систем.
Затраты на построение модели деятельности предприятия сильно различаются от проекта к проекту. Но отсутствие качественной модели может привести к полному или частичному перевнедрению системы, что в свою очередь взвинтит затраты и конечная стоимость проекта окажется в несколько раз больше, чем предполагалось вначале.
Анализ деятельности предприятия — довольно емкое понятие. В данном разделе под анализом деятельности понимается следующее: сбор и представление информации о деятельности предприятия в формализованном виде, пригодном для выбора и дальнейшего внедрения автоматизированной системы.

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

• 2c8 Modeling Tool
• Aris Express
• AuraPortal
• BizAgi Process Modeler
• Business Studio
• CA ERwin Process Modeler (ранее CA ERwin Data Modeler, AllFusion Process Modeler, BPwin)
• Casewise Corporate Modeler Suite
• Corel iGrafx (IDEF0)
• Design/IDEF
• Edraw Mindmap
• eVSM
• Flowbreeze
• Fox-manager
• Gravity from SAP
• IBM Blueworks https://apps.lotuslive.com/bpmblueworks/
• Intalio
• iGrafx
• Lombardi Blueprint
• Omnigraffle Professional
• Promanade Basic software
• QPR ProcessGuide Xpress
• Savvion
• SigmaFlow
• Smartdraw
• Sparxsystem
• Systems2win
• TaskMap
• Viflow
• Websphere Business Modeler
• RavenCloud
• Ramus
• XSOL

В заключение. Так ли необходимо привлечение нас, консультантов? Ведь часто руководители говорят, что многие проблемы были у них как на ладони. Это так только на первый взгляд. Консультант видит ваши проблемы «по другому». А Заказчику требуется взгляд более опытный в этих делах, свежий, «незамыленный».

Хороших специалистов, знающих свою компанию с ног до головы — немного, при этом они очень заняты. Анализируя бизнес-процессы своими силами, Заказчик экономит деньги, и может быть, экономит время. Но отрывать лучших на описание БП — не всегда возможно.
С другой стороны Заказчики, наслышанные о многих неудачных работах по внедрения-реинжинирингу (в т.ч. ERP-проектах), совершенно справедливо боятся ошибиться с выбором. Только консультанты смогут помочь вам подготовиться к выбору необходимой информационной системы, а также сформулировать критерии отбора компании, которая будет внедрять эту систему.

И первым делом консультант должен провести небольшое обучение — лекцию для рабочей группы с тем, чтобы они получили общие представления о методах управления, о методах анализа существующих бизнес-процессов и о том, какие задачи можно решить с помощью CRM или ERP-системы. Можно поручить рутину исполнителям рангом пониже, но тогда появляется риск затягивания процесса. Незнание принципов построения таких документов несет в себе риск безрезультатности (результат непригодный к употреблению — это все равно что его отсутствие).
Наилучшее качество и скорость при подготовке документа возможны в альянсе, ключевого специалиста и опытного консультанта. Результатом будет согласованный язык описания бизнес процессов (т.е. терминология бизнеса компании) и само описание в деталях достаточных для решения дальнейших задач.

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

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

Источник: dombyx.ru