В результате обследования предприятия строится функциональная модель существующей организации работы AS-IS (Как есть). На основе модели AS-IS достигается консенсус между различными единицами бизнеса по тому, «кто что сделал» и что каждая единица бизнеса добавляет в процесс.
Модель AS-IS позволяет выяснить, «что мы делаем сегодня» перед тем, как перепрыгнуть на то, «что мы будем делать завтра». Внедрение информационной системы неизбежно приведет к перестройке существующих бизнес-процессов предприятия. Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправ-ляемые и дублирующиеся работы, неэффективный документооборот (нуж-ный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат) и входу (объекты или информация используются нерационально) и т. д.
Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (Как будет) — модели новой организации бизнес-процессов. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернатив-ных/лучших путей выполнения работы и документирования того, как пред-приятие будет функционировать в будущем. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выби-рается наилучшая (рис. 2). Например, каждая из моделей ТО-ВЕ может соответствовать определенной информационной системе.
Рис. 2. Построение моделей ТО-ВЕ как результат анализа модели AS-IS
Модели AS-IS и ТО-ВЕ позволяют описать начальное и конечное состояние предприятия — до и после внедрения корпоративной информационной сис-темы, оставляя без внимания сам процесс разработки (выбора) и внедрения. Можно с помощью BPwin создать модель этой работы. Модель ТО-ВЕ — это не модель деятельности предприятия, а модель мероприятий по переводу предприятия на новую технологию работы. Используя эту модель можно с помощью стоимостного анализа оценить объем средств, необходимых для приобретения/разработки и внед-рения информационной системы. Такие модели можно построить для пере-хода на различные модели ТО-ВЕ, т. е. для внедрения различных инфор-мационных систем (как готовых, так и созданных на заказ) и выбрать опти-мальный вариант.
Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных.
Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие.
Стрелки (Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными. В IDEF0 различают пять типов стрелок:
Вход (Input) — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее.
Стрелка входа рисуется как входящая в левую грань работы. Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить информация о том, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет — управление.
Управление (Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. Управление влияет на работу, но не преобразуется работой.
Если цель работы — изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.
Выход (Output) — материал или информация, которые производятся ра-ботой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы.
Механизм (Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. По усмотрению аналитика стрелки механизма могут не изображаться в модели.
Вызов (Call) — специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.
Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы, или наоборот. Такие стрелки называются граничными.
Контекстная диаграмма «Процессы компании»
Создание диаграммы декомпозиции
После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания.
Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 — это не элемент управления нижестоящими работами. Работы нижнего уровня — это то же самое, что работы верхнего уровня, но в более детальном изложении.
Как следствие этого границы работы верхнего уровня — это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) — коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер.
Диаграммы декомпозиции содержат родственные работы, т.е. дочерние работы, имеющие общую родительскую работу. Работы на диаграммах де-композиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему. Такой порядок называется порядком доминирования.
Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое размещение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ. Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована.
Декомпозиция контекстной диаграммы на 3 блока IDEF0: «Маркетинговые исследования», «Управление организацией» и «Реализация услуг».
Декомпозиция блока «Маркетинговые исследования»
Создание диаграммы DFD
Диаграммы потоков данных (Data Flow Diagramming) являются основным средством моделирования функциональных требований к проектируемой системе. Требования представляются в виде иерархии процессов, связанных потоками данных. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами.
DFD-диаграммы успешно используются как дополнение к модели IDEF0 для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет моделируемую систему как сеть связанных работ. Основные компоненты DFD — процессы или работы, внешние сущности, потоки данных, накопители данных (хранилища) [4].
В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов, хранение объектов, поставка и распространение объектов.
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы. Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.
В DFD работы (процессы) представляют собой функции системы, преобразующие входы в выходы. Хотя работы изображаются прямоугольниками со скругленными углами, смысл их совпадает со смыслом работ IDEF0 и IDEF3. Так же, как процессы IDEF3, они имеют входы и выходы, но не поддерживают управления и механизмы, как IDEF0.
Декомпозиция «Исследований целевой аудитории» (DFD)
Декомпозиция «Исследований Рынка» (DFD)
Декомпозиция «Управления организацией» (IDEF0)
Создание диаграммы IDEF3
Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например последовательность обработки заказа или события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. IDEF3 — это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Техника описания набора данных IDEF3 является частью структурного анализа. В отличие от некоторых методик описаний процессов IDEF3 не ограничивает аналитика чрезмерно жесткими рамками синтаксиса, что может привести к созданию неполных или противоречивых моделей.
IDEF3 может быть также использован как метод создания процессов. IDEF3 дополняет IDEF0 и содержит все необходимое для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа.
Каждая работа в IDEF3 описывает какой-либо сценарий бизнес-процесса и может являться составляющей другой работы. Поскольку сценарий описывает цель и рамки модели, важно, чтобы работы именовались отглагольным существительным, обозначающим процесс действия, или фразой, содержащей такое существительное.
Точка зрения на модель должна быть документирована. Обычно это точка зрения человека, ответственного за работу в целом. Также необходимо документировать цель модели — те вопросы, на которые призвана ответить модель [4].
Диаграмма является основной единицей описания в IDEF3. Важно правильно построить диаграммы, поскольку они предназначены для чтения другими людьми.
Единицы работы — Unit of Work (UOW) — также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы.
Связи показывают взаимоотношения работ. Все связи в IDEF3 однонаправлены и могут быть направлены куда угодно, но обычно связи стараются направить слева направо. В IDEF3 различают три типа стрелок, изображающих связи:
- * Старшая (Precedence) — сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.
- * Отношения (Relational Link) — пунктирная линия, использующаяся для изображения связей между единицами работ (UOW) а также между единицами работ и объектами ссылок.
- * Потоки объектов (Object Flow) — стрелка с двумя наконечниками, применяется для описания того факта, что объект используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.
Для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы, используются перекрестки (Junction). Различают перекрестки для слияния (Fan-in Junction) и разветвления стрелок (Fan-out Junction). Перекресток не может использоваться одновременно для слияния и для разветвления.
Объект ссылки в IDEF3 выражает некую идею, концепцию или данные, которые нельзя связать со стрелкой, перекрестком или работой. В качестве имени объекта можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны бытьсвязаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок — безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous).
Смысл в случае слияния стрелок (Fan-in Junction)
Смысл в случае разветвления стрелок (Fan-out Junction)
Все предшествующие процессы должны быть завершены
Все следующие процес-сы должны быть запу-щены
Источник: studwood.net
Анализ и описание бизнес процессов as is и to be
Прежде чем пытаться выбрать существующую или создать собственную информационную систему, а затем внедрить ее, необходимо проанализировать, как работает система в настоящее время. Для этого строится функциональная модель AS-IS. Анализ этой функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов.
Детализация бизнес-процессов позволяет выявить недостатки. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ — модели новой организации бизнес-процессов. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных путей выполнения работы и документирования того, как система будет функционировать в будущем.
Модель AS-IS — это модель «как есть», т.е. модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. Построение функциональной модели AS-IS позволяет четко зафиксировать какие информационные объекты используются при выполнении функций различного уровня детализации. На основе анализа текущих процессов информационной обучающей системы была создана следующая AS-IS модель, которая позволяет выделить и систематизировать процессы, протекающие в данной системе при её функционировании. Главная контекстная диаграмма данной модели приводится на рисунке 1.6.
Рисунок 1.6 — Главная контекстная диаграмма (модель AS-IS)
Для более детального понимания логики бизнес-процессов, протекающих в текущей проблемной области разработанная выше контекстная диаграмма была разбита на восемь следующих процессов:
1) выбор источников;
2) разработка оглавления и перечня понятий;
3) переработка текстов в модули по разделам;
4) реализация гипертекста в электронной форме;
5) разработка компьютерной поддержки;
6) отбор материала для тестовых заданий;
7) подготовка материала для тестов;
8) визуализация материала.
Декомпозиция контекстной диаграммы представлена на рисунке 1.7.
На диаграмме прослеживаются этапы процесса создания электронного пособия.
Рисунок 1.7 — Декомпозиция контекстной диаграммы
Модель TO-BE
Таким образом, учитывая анализ модели «КАК ЕСТЬ», была построена модель «КАК ДОЛЖНО БЫТЬ», которая представлена на рисунке 1.8.
Рисунок 1.8 — Контекстная диаграмма модели TO-BE
На данной диаграмме представлена общая схема процесса разработки и использования информационного модуля управления учебно-методическим процессом. Процесс обработки материалов по предмету и их размещение в Интернет осуществляется преподавателем, изучение материалов осуществляется пользователем. В качестве правил используются стандартные правила по работе с базами данных.
Рисунок 1.9 — Декомпозиция контекстной диаграммы процесса TO-BE
Декомпозиция контекстной диаграммы модели TO-BE представлена на рисунке 1.9. По сравнению с моделью «AS-IS» в данной модели появилась возможность добавления, изменения и удаления сведений о пользователях, а также добавления, изменения и удаления архивов.
Следует отметить, что модель «TO-BE» отображает те полезные функции, которые позволят успешно внедрить и использовать данное программное обеспечение для организации процесса дистанционного обучения пользователей.
Источник: studbooks.net
Оптимизация бизнес-процессов предприятия
В этой статье речь пойдёт об оптимизации бизнес-процессов предприятия, их описании и моделировании.
Несколько лет тому назад автор этой статьи работал в крупной торговой компании, владелец которой придавал огромное значение стратегическому планированию, но не придавал значения оптимизации нижнего уровня управления — бизнес-процессов предприятия. Маркетинговая стратегия предприятия была расписана в лучших традициях. И мероприятия соответствующие были запланированы, и ресурсы выделены. Но как только речь заходила о налаживании скучных, регулярных процедур управления, оптимизации бизнес-процессов предприятия, собственник, а за ним и ряд ведущих менеджеров теряли всякий интерес, предпочитая заниматься более «высокими материями». На мой взгляд, банкротство компании, случившееся лет через 5 после нашего расставания, было закономерным явлением.
Начнём разговор об оптимизации с определения бизнес-процессов, так как существуют разные трактовки этого термина. Мы будем понимать под бизнес-процессами «систему последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью ресурсов входы процесса преобразуются в выходы — результаты процесса». С учётом этого определения устное предание о правилах входной приёмки на складе бизнес-процессом не является («не регламентирован»), а наличие инструкции по работе с ксероксом ещё не доказывает высокий уровень оптимизации бизнес-процессов («нет системы»).
До определённого уровня развития компания вполне может обойтись без «регламентированной системы деятельности». Трудно в общем случае ответить на вопрос «когда пора оптимизировать бизнес-процессы предприятия?», однако, нет сомнения, что этот момент приближают
- рост количества персонала,
- рост количества уровней управления,
- рост количества подразделений,
- территориальная разобщённость подразделений,
- отсутствие или неразвитость единой информационной системы.
Итак, если в определённый момент развития вы обнаружили, что
- решения в компании принимаются не позволительно медленно,
- решения реализуются медленно и не качественно,
- периодически выясняется, что те или иные аспекты деятельности предприятия остались без контроля,
- среди сотрудников растёт психологическое напряжение, связанное с неурегулированностью прав, обязанностей, ответственности,
- выполнение элементарных рабочих операций требует непозволительно много времени, сил, телефонных звонков, согласований, служебных записок,
имеет смысл заняться оптимизацией бизнес-процессов предприятия. Отметим, что в ряде случаев работу по изменению бизнес-процессов целесообразно провести, не дожидаясь указанных симптомов, например, в случае существенного изменения структуры управления или при внедрении новой информационной системы.
Вопросам моделирования, описания и оптимизации бизнес-процессов предприятия посвящено много полезных материалов. В этой статье, не претендуя на методологическую новизну, я хочу высказаться по некоторым аспектам практической реализации этой работы. И начнём мы с
1. Выбора инструмента графического описания бизнес-процессов
Почему-то этому вопросу придают огромное, если не решающее значение. Выскажу крамольную мысль: программное обеспечение (ПО) описания и оптимизации бизнес-процессов предприятия имеет значение только в том случае, если разработка проводится с целью дальнейшего внедрения бизнес-процессов в информационную систему. Но современные ИС имеют собственные средства описания бизнес-процессов, поэтому само по себе обсуждение ПО оптимизации бизнес-процессов предприятия потеряло смысл.
Вместе с тем, при обсуждении этого вопроса иногда забывают, что описания бизнес-процессов нужны не для разработчиков, а для сотрудников предприятия, и важнейшим критерием выбора инструмента описания бизнес-процессов является его доступность для персонала предприятия как на этапах согласования и оптимизации бизнес-процессов, так и на этапах исполнения и модернизации.
Автор имеет успешный опыт внедрения бизнес-процессов, прорисованных в графическом редакторе MS Word и печальный опыт наблюдения полной неразберихи на предприятии с бизнес-процессами, описанными в самой современной программе. Так что при выборе инструмента решаете сами — «вам ехать или шашечки?».
2. Модели «AS IS» и «TO BE» оптимизации бизнес-процессов
Традиционная схема оптимизации бизнес-процессов предприятия предполагает описание на первом этапе действующих процедур (модель бизнес-процессов «AS IS») с последующей оптимизацией до модели «TO BE» («как должно быть»). Иногда заказчикам работы по оптимизации бизнес-процессов не понятно, зачем нужен первый этап. Они ожидают, что исполнители принесут на предприятие готовые «типовые» бизнес-процессы, а разработку модели «AS IS» воспринимают, как попытку «накрутить» трудоёмкость.
Хочется предостеречь от такого подхода. Методика внедрения системы бизнес-процессов, не опирающейся на действующие процедуры предприятия, называется не оптимизацией бизнес-процессов, а реинжинирингом. Разница примерно такая же, как между терапией и хирургией, а к скальпелю обычно обращаются тогда, когда другого выхода нет. Подумайте об этом в момент принятия решения.
Описание «AS IS» позволяет выяснить существующие противоречия и провести первичную оптимизацию бизнес-процессов. Для этого модель «AS IS» должна быть обсуждена со всеми участниками бизнес-процессов и согласована с ними «под роспись».
3. Оптимизация бизнес-процессов предприятия
«Оптимизировать» нечто можно только по определённым критериям. Оптимизировать бизнес-процесс можно по критериям стоимости, продолжительности, количества транзакций и т.д. Понятно, что эти критерии являются «внешними» по отношению к бизнес-процессу, появляются из более общего контура управления предприятием. Давайте подумаем, из какого?
Предположим, мы оптимизируем бизнес-процесс обслуживания клиента в магазине. Нам придётся выбрать критерий оптимизации — качество или стоимость. Если наш магазин — элитный бутик, то мы остановимся на первом критерии, если дискаунтер, то на втором. Таким образом, мы уже выбрали критерий оптимизации бизнес-процессов предприятия, определяя стратегию и позиционирование нашего магазина.
Именно так, с помощью показателей оптимизации, процедурный уровень системы управления (бизнес-процессы) подчиняется более высокому уровню — стратегии.
4. Внедрение оптимизированных бизнес-процессов
Вероятно, внедрение — это самый сложный этап работы с бизнес-процессами. Внедрение проходит гораздо успешнее, если поддержано информационной системой предприятия. Однако, такая возможность существует не всегда и не в полном объёме.
На этот случай хочется поделиться способом внедрения бизнес-процессов, названной нами «методикой контрольных карт», которая заключается в следующем. По всем бизнес-процессам составляются списки контрольных точек (контрольные карты), в которых мы будем контролировать соблюдение бизнес-процессов. Удобными контрольными точками являются моменты передачи документов, информации между сотрудниками. В этом случае «контролёром» может быть сотрудник, которому информация должна быть передана. Пример контрольной карты представлен на рис. 1
Рис. 1 Пример контрольной карты бизнес-процессов
Контрольная карта исполнения бизнес-процесса отчёта по авансам
1. Отчёт не был предоставлен в течение 2-х дней
Форматы контрольных карт передаются участникам бизнес-процесса. «Контролёры» обязаны фиксировать в картах факты
- Не предоставления информации,
- Предоставления информации с опозданием,
- Предоставления неполной или искажённой информации и т.д.
Карты собирает руководитель внедрения бизнес-процессов, анализирует их, обсуждает с участниками процедуры. Возможными последствиями могут являться:
- разъяснительная беседа с участниками бизнес-процесса,
- изменение бизнес-процесса, если выяснится, что он был построен неверно,
- передача результатов анализа руководителю нарушителя бизнес-процесса для принятия решения о наказании.
5. Модернизация бизнес-процессов
Жизнь не стоит на месте, поэтому рано или поздно разработанные на предприятии бизнес-процессы опять потребуют оптимизации. Чтобы бизнес-процессы, с одной стороны, соответствовали реальности, а с другой стороны, не мешали нормальному развитию компании, их нужно своевременно модернизировать, согласовывая новые редакции с участниками и доводя изменения до всех заинтересованных лиц.
Тогда система бизнес-процессов предприятия станет реальным инструментом повышения эффективности бизнеса на процедурном уровне.
На нашем сайте можно ознакомиться с примерами разработанных нами описаний бизнес-процессов, отзывами наших заказчиков, а также с процедурой заказа работы по совершенствованию бизнес-процессов. Узнайте как оптимизировать расходы на эту работу посмотрев видеопост «Стоимость оптимизации бизнес-процессов» на нашем канале Youtube.
Если вы хотите узнать о возможностях такой экономии для вашего предприятия, заполните этот вопросник для подготовки коммерческого предложения на оптимизацию бизнес-процессов, и мы пришлём вам КП с ценой и планом выполнения этой работы.
Как заказать наши услуги
УЗНАТЬ ПОДРОБНЕЕ
- Наши услуги
- Сколько стоит консалтинг?
- Примеры работ
- Отзывы клиентов
- Подписка на рассылку
В соответствии со ст. 1274 ГК РФ при публикации материала сайта в Интернете, указание авторства и индексируемая ссылка на источник публикации обязательны.
197183, Санкт-Петербург, Представительство в Москве
+7 (962) 684-45-80 +7 (812) 430-19-53 +7 (921) 962-08-63 —>
Источник: piter-consult.ru
