2 глава. Моделирование и актуализация бизнеспроцессов компании КорпусГрупп
 Скачать 0.55 Mb.
|
|
Глава 500. Моделирование и актуализация бизнес-процессов компании «КорпусГрупп» 2.1. Выбор методологии и методов моделирования Описание основных методологий (IDEF0, DFD, IDEF3) Сравнение методологий ARIS и IDEF Описание основных инструментов управления и моделирование бизнес-процессов. Выбор подходящей нотации для описания бизнес-процессов и выбор инструмента для моделирования 2.2. Моделирование деятельности компании в концепции AS-IS Выбор деятельности компании для описания бизнес-процессов Информационное сопровождение процесса моделирования Моделирование AS-IS 2.3. Моделирование деятельности компании в концепции TO-BE Концептуальные идеи по реинжинирингу бизнес-процессов Информационное сопровождение процесса моделирования Моделирование TO-BE Вывод по второй главе 2.1. Выбор методологии и методов моделирования Моделирование и описание бизнес-процессов - это, прежде всего, информационная база для аналитика, но не цель проекта. Чтобы разработка модели бизнес-процессов была оправдана, а сама модель впоследствии эффективно применима, необходимо чётко сформулировать её цели, точку зрения, границы предметной области и глубину детализации Рассмотрим следующие виды основных методологий: IDEF0; DFD; IDEF3. IDEF0 IDEF0 — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временная последовательность. Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0. Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «черный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные. Стрелки могут быть: Входящие – вводные, которые ставят определенную задачу. Исходящие – выводящие результат деятельности. Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр). Механизмы (снизу-вверх) – что используется для того, чтобы произвести необходимую работу. Входящие и исходящие стрелки точнее было бы называть вводящими и выводящими, так как по-английски они называются Input и Output соответственно. Но особенности перевода и привычные названия выглядят уже так, как сложилось. И все же для правильного понимания терминов важно помнить их значение в данном случае. Это подтверждается еще и тем, что данная нотация создана прежде всего для разработки ПО, и термины переводить правильнее в этой точки зрения. Стрелки подписываются при помощи имен существительных (опыт, план, правила), а блоки – при помощи глаголов, т.е. в них описываются действия, которые производятся (создать товар, заключить договор, произвести отгрузку). IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д. Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку. А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта. IDEF0 — этот инструмент был создан для функционального моделирования, и с его помощью вы намного быстрее и точнее сможете получить нужный результат. Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания диплома. Основной блок – «Написать выпускную квалификационную работу».   Требования к работе   План ВКР Параметры ГОСТ  Написать выпускную квалификационную работу  Помощь научного руководителя Сама напишешь Информация из разрешенных источников  Научный руководитель   Персональный компьютер Студент Входящие стрелки – «Помощь научного руководителя», «Информация из разрешенных источников». Это те вводные, которые необходимы для начала работы. Управляющие для написания выпускной квалификационной работы – это «План ВКР», «Параметры ГОСТ», «Требования к работе». А в роли «Механизмов» выступают студент, научный руководитель, персональный компьютер. В данном случае автор создает материал, в котором собирает все мысли и идеи, которые должны быть отражены в работе. Научный руководитель проверяет материал на ошибки. А персональный компьютер – это тот инструмент, который используют в работе все участники процесса. Таким образом, я задала основные параметры процесса, его вход, выход, а также все необходимое для успешного проведения процесса. Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом. На самом деле, процесс написания диплома (выпускной квалификационной работы), как и любой бизнес-процесс можно и нужно детализировать. Типичные ошибки при создании нотации IDEF0: Слишком большое количество блоков; Использование различных цветов; Нарушение структуры при внесении корректировок. Правила названия управляющих элементов и блоков: Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок. Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами. Выгоды использования IDEF0: Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них. Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке. Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам. Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны. В чем трудность применения IDEF0 Важно понимать, что только в самых простых случаях два бизнес-аналитика создадут для описания работы компании абсолютно одинаковые функциональные модели. Любая модель – это отражение опыта аналитика, глубины понимания работы бизнеса, который он стремится описать, а также, в некотором роде, его личная точка зрения на этот бизнес. Т.е. человек разрабатывает бизнес-модель с точки зрения руководителя, как будто этим руководителем является именно он. При этом я считаю, что бизнес-аналитик — это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0. А потому очень важно при составлении функциональной бизнес модели «как есть» постоянно советоваться с руководителем компании, чтобы не совершить ошибки, которая повлечет за собой автоматически ошибки на этапах декомпозиции. Также на последующих этапах могут потребоваться дополнительные согласования с руководителями структурных подразделений и сотрудниками. Только если ваша функциональная модель «как есть» будет действительно отражать реальное положение вещей, можно вносить какие-то изменения и предложения. А для достижения качественных результатов в такой работе требуется, прежде всего, практический опыт и знание особенностей того или иного вида бизнеса. DFD DFD – диаграмма потоков данных. Это метод, с помощью которого проводится графический структурный анализ, в котором описаны внешние для системы источники данных, функции, потоки и хранилища данных, к которым имеется доступ. С помощью этой диаграммы проводится структурный анализ и проектируются информационные системы. DFD – это нотация, которая используется при моделировании информационных систем с точки зрения хранения, обработки и передачи данных. В целом DFD не имеет жесткого синтаксиса в отличие от большинства других нотаций. Здесь возможно использование различных вариантов. Главное условие – понятность как составителю диаграммы, так и тем людям, которые будут ее читать. Созданные модели потоков Данных организации могут быть использованы при решении таких задач, как: определение существующих хранилищ данных (текстовые документы, файлы, Система управления базой данных — СУБД); определение и анализ данных, необходимых для выполнения каждой функции процесса; подготовка к созданию модели структуры данных организации, так называемая ERD-модель (IDEF1X); выделение основных и вспомогательных бизнес-процессов организации. Диаграммы потоков данных показывают, как каждый процесс преобразует свои входные данные в выходные, и выявляют отношения между этими процессами. DFD представляет моделируемую систему как сеть связанных работ. При построении DFD-схемы бизнес-процесса нужно помнить, что данная схема показывает потоки материальных и информационных потоков и ни в коем случае не говорит о временной последовательности работ, хотя в большинстве случаев временная последовательность работ и совпадает с направлением движения потоков в бизнес-процессе. Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации. Процессы (работы) служат для преобразования входных потоков данных в выходные. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, «получить отчет по отправке продукции»). Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных моделирует данные, которые будут сохраняться в памяти между процессами. Информация, которую содержит хранилище, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть существительным. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником данных. Ее имя должно содержать существительное, например, «склад продуктов». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке. Диаграммы потоков данных строятся в виде иерархии. Сначала строится контекстная диаграмма. При проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим, поскольку каждый из них может быть в дальнейшем разбит на несколько потоков на следующих уровнях диаграммы. Как и любая другая нотация, DFD имеет достоинства и недостатки. Главным преимуществом нотации является отсутствие требований к соблюдению правил и синтаксиса. Нотация не является исполнимой, она используется для формирования внутреннего понимания, структурирования и последующей работы с данными. Кроме того, важными положительными характеристиками являются: Способность к точному определению внешних сущностей при использовании методов анализа потоков информации в системе и за ее пределами. Возможность вертикального проектирования. Обеспечение возможности описания процессов нижних уровней, что позволяет достичь логической завершенности модели. Основным недостатком называют отсутствие возможности анализа временных параметров в модели, необходимость использования управляющих процессов. Исторически были разработаны два варианта синтаксиса нотации: Йордана Де Марко и Гейна-Сарсона. В этих вариантах имеются различия в отображении процесса (в первом варианте процесс отображается кругом, а во втором – разделенным горизонтальной чертой прямоугольником), а также хранилища данных (в варианте Йордана хранилище данных представлено простым прямоугольником, а в варианте Гейна – прямоугольник имеет разделяющую вертикальную черту). Нотация включает в себя 4 основных элемента: Процесс, который может содержать в себе функцию или последовательность действий, необходимых для обработки информации. В названии процесса преимущественно используют глаголы. Внешние сущности, представленные любыми объектами, не включенными в систему, но поставляющие или получающие информацию из системы. Хранилище данных является внутренним объектом. Это может быть базой данных, таблицей или любым другом вариантом, в котором организовано хранение данных. Поток данных отображается стрелкой, которая показывает входящую и исходящую из каждого блока информацию.  Описание всех процессов из этого примера сама сделаешь IDEF3 IDEF это не одна нотация, а целый комплекс. Различаются порядковыми номерами: IDEF0, IDEF1, IDEF2, IDEF3 и так далее. В описании бизнес-процессов чаще всего используются IDEF0 и IDEF3. Методология IDEF0 подразумевает использование диаграмм. С целью конкретизации бизнес-процессов используют функции, подразделяя их на более простые. IDEF3 — это метод моделирования бизнес-процессов, дополняющий IDEF0. Предназначен для описаний отдельных элементов бизнес-процессов. Сегодня речь пойдет про IDEF3. IDEF3 — это «сценарий» бизнес-процесса. Представляет собой описание последовательности действий с детальным описанием происходящих событий. Нотация IDEF3 может быть использована: Как инструкция для сотрудников, которые будут работать в рамках бизнес-процесса. Как иллюстрация предлагаемых решений для заказчика (если есть возможность работать с компьютером, то можно также пользоваться декомпозицией, что особенно удобно). Как алгоритм для настройки IT-системы. Основные характеристики нотации IDEF3: Основным вектором действия нотации является предоставление возможности описания модели, когда действия происходят (выполняются) в заданной последовательности, являются взаимозависимыми, а также детального описания объектов внутри этого процесса, влияющих на результат. Как правило, используется для моделирования процессов нижнего уровня. Является дополнением нотации IDEF0 — применяется для описания декомпозиции блоков процесса. Модель IDEF3 может подразделяться на отдельные блоки, для конкретизации отдельных элементов — возможность декомпозиции. IDEF3 не ограничивает жесткими рамками синтаксиса и семантики, что удобно для описания неполных или не целостных систем. Описание происходит с помощью диаграммы. Методика и рекомендации схожи с нотацией IDEF0. Нотация IDEF3 не имеет ограничений в количестве составных частей в рамках диаграммы. Все блоки диаграммы являются равноправными. Нотация IDEF3 применяется для выполнения следующих задач: Документирование технологии процесса; Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов. Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например, изменение конструктивных, технологических или эксплуатационных свойств конечного продукта. Содействовать принятию оптимальных решений при реорганизации технологических процессов. Разрабатывать имитационные модели технологических процессов. Нотация IDEF3 призвана сделать бизнес-процесс как можно более логичным и информативным. Для этого при моделировании следует использовать декомпозиции. Именно этот инструмент позволит объединить технологические и бизнес-процессы. Основным отличием нотации IDEF3 от IDEF0 — это возможность описания логической цепочки действий. Таким образом, IDEF0 описывает «что» делает организация, нотация IDEF3 призвана описать «как» эти действия выполняются. Преимущества нотации IDEF3: простота описания и восприятия — нотация содержит не большое количество элементов ограничение нотации определенными рамками (формат А4). При моделировании важно, учитывать размер диаграммы. Также она не должна быть перегружена слишком большим количеством элементов, но при этом она должна быть информативной. Недостатки нотации IDEF3: малая информативность. Для наиболее детального описания процесса требуется использование нотации IDEF3 совместно с IDEF0. Основополагающей единицей нотации IDEF3 является диаграмма. В стандарте IDEF3 выделяют два вида диаграмм, описывающие один и тот же сценарий с разных точек зрения: Диаграммы, предназначенные для описания последовательности действий внутри процесса (Process Flow Description Diagrams, PFDD). Диаграммы, выражающие состояния объекта и изменение его свойств в процессе (Object State Transition Network, OSTN). Требования IDEF3 к описанию бизнес-процессов Нотация IDEF3 выдвигает определенные требования к описанию бизнес-процессов. Соблюдение этих условий сделает процесс наиболее информативным. Перед созданием бизнес-процесса с помощью нотации IDEF3 необходимо: определить сценарий (описание действий необходимых для достижения результата); границы моделирования (область, за которую не стоит выходить для достижения удобства восприятия модели); определит точку зрения (угол мнения, со стороны которого будет производится процесс). Указанные аспекты предварительно необходимо задокументировать. Это позволит учесть все нюансы при создании бизнес-процесса. Необходимо верно определить действия и их количество, которые необходимо произвести для достижения конечной цели. Работа бизнес-процесса напрямую зависит от его полноты. Необходимо разобрать путь к достижению цели на определенные блоки, выражающие действия. Кроме того, следует определить объекты, которые будут участвовать в процессе. Завершающим этапом подготовки к описанию бизнес-процесса с помощью нотации IDEF3 является определение последовательности и параллельности. Необходимо распределить действия в цепочку и обозначить их порядковыми номерами. IDEF3 — это способ описания технологических и бизнес-процессов. Нотация позволяет составлять схемы даже очень сложных бизнес-процессов в понятной форме. Законченная схема демонстрирует логику процесса, его участников и последовательность их работы. Надо ещё тут привести примеры (либо сама выберешь те, которые сможешь объяснить, либо сама сделаешь, как я делал с IDEF0) Сравнение методологий ARIS и IDEF Методология ARIS представляет собой современный подход к структурированному описанию деятельности организации и представлению ее в виде взаимосвязанных и взаимодополняющих графических диаграмм, удобных для понимания и анализа. Методология ARIS основывается на концепции интеграции, предлагающей целостный взгляд на процессы, и представляет собой множество различных методик, объединенных в рамках единого системного подхода. ARIS – это сокращенное английское выражение (Architecture of Integrated Information Systems), что в переводе означает: архитектура интегрированных информационных систем. Под архитектурой подразумевается совокупность технологий, обеспечивающих проектирование, управление, применение и реализацию бизнеса в виде «деловых» процедур бизнес-процессов предприятий и организаций, а также проектирование и создание интегрированных информационных систем поддержки бизнес-процессов. Методология ARIS реализует принципы системного структурного анализа, основным понятием которого служит структурный элемент (объект). Структурный анализ является методологической разновидностью системного анализа. В структурном анализе предполагается использование графического представления для описания структуры и деятельности организации. При этом реализуются основные принципы структурного анализа: разбиение на уровни абстракции с ограничением числа элементов на каждом уровне (обычно от 3 до 9); ограниченный контекст включающий только существенный на каждом уровне детали; использование строгих формальных правил записей; последовательное приближение к конечному результату (зависит от целей моделирования). Методология ARIS также использует декомпозицию и позволяет детализировать предмет моделирования с помощью альтернативных или дополняющих друг друга моделей. Основы методологии ARIS состоят в том, что любая организация рассматривается и визуально представляется во всех аспектах, т.е. как единая система, описание которой предусматривает четыре различных «взгляда»: Организационная структура; Данные (потоки и структура); Функции («деревья» функций); Контроль и управление (деловые процессы). Все данные подсистемы организации в реальности и в моделях должны быть связаны между собой. Методология ARIS дает возможность описывать достаточно разнородные подсистемы в виде взаимоувязанной и взаимосогласованной совокупности различных моделей. Именно взаимосвязанность и взаимосогласованность моделей являются отличительными особенностями методологии ARIS. В соответствии с правилами структурного анализа каждая из этих подсистем разбивается на элементарные блоки (модули), совокупность которых и составляет нотацию структурной модели той или иной подсистемы организации. Естественно, что эти подсистемы не являются обособленными. Они взаимно проникают друг в друга, и поэтому одни и те же элементарные модули могут использоваться для описания различных структурных моделей. Для устранения избыточности методология ARIS ограничивает число типов моделей. В связи с этим в методологии ARIS выделено пять типов представлений основных моделей, отражающих основные аспекты организации: 1. Организационные модели, описывающие иерархическую структуру системы, т.е. иерархию организационных подразделений, должностей, полномочий конкретных лиц, многообразие связей между ними, а также территориальную привязку структурных подразделений; 2. Функциональные модели, описывающие функции (процессы, операции), выполняемые в организации; 3. Информационные модели (т.е. модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы; 4. Модели процессов или управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели; 5. Модели входов и выходов, описывающие потоки материальных и нематериальных входов и выходов, включая потоки денежных средств. Сравнительный анализ нотаций ARIS и IDEF Сравнительный анализ нотаций ARIS и IDEF приводится в следующей таблице.  Одним из важнейших аспектов описания моделей бизнес-процессов является отражение на модели управляющих воздействий, обратных связей по контролю и управлению процедурой. В нотации ARIS eEPC управление процедурой может быть отражено только при помощи указания входящих документов, которые регламентируют выполнение процедуры, и последовательности выполнения процедур во времени (запускающие события). В отличие от ARIS, в нотации IDEF0 каждая процедура должна иметь хотя бы одно управляющее воздействие (вход управления – стрелка сверху). Если при создании модели в eEPC указывать только последовательность выполнения процедур, не заботясь об отражении управляющих документов и информации, полученные модели будут иметь низкую ценность с точки зрения анализа и дальнейшего использования. К сожалению, именно эта ошибка наиболее распространена на практике. Создается модель Work Flow (поток работы), отражающая простую последовательность выполнения процедур и входящих/исходящих документов, при этом управляющие (контрольные) воздействия на функции в модели не отражаются. Реальные процессы управления могут остаться “за кадром” на 30-90% (см. пример на следующем рисунке). Если пытаться отразить все условия и ограничения, определяющие выполнение функций, то потребуется описать большое количество событий и входящей информации (например, устных распоряжений руководителей), и модель станет сложной и плохо читаемой. (Эти недостатки присущи так же и нотации IDEF3). Указанных недостатков нет у нотации IDEF0. В то же время, на моделях в IDEF0 не предусмотрено использование символов логики выполнения процесса. Таким образом, нотация ARIS eEPC является расширением достаточно простой нотации IDEF3. Для адекватного описания процесса управления в нотации eEPC необходимо заранее договориться, как будут отражены в модели документы (информация), регламентирующие выполнение процедур процесса.  Описание основных инструментов управления и моделирование бизнес-процессов. Основные способы моделирования бизнес процессов Моделировать бизнес-процессы можно по-разному. Есть четыре основных способов моделирования: Текстовый. Когда процесс описывают словами на бумаге или в текстовом редакторе. Часто это произвольное неструктурированное изложение мыслей, которое может занимать десятки страниц. Удобно тем, что не нужно особых знаний, навыков и подготовки. Но результат — громоздкий текст, в котором сложно разобраться другому человеку. Табличный. Данные заносятся в таблицу (рукописную или электронную). Здесь уже информация выглядит более структурировано. Но и здесь нет наглядности: объемные таблицы невозможно увидеть целиком, нельзя отразить ответвления. Графический. Когда процесс представлен в виде блок-схемы, на которой видны мельчайшие вариации действий, есть текстовые пояснения к элементам, отражен порядок операций. Схему можно нарисовать от руки на бумаге или любом графическом редакторе. Основные способы моделирования бизнес процессов Основные инструменты моделирования и управления бизнес процессами Существуют специальные программы для моделирования. Внутри такого ПО можно совмещать в одной модели графики, текст, блок-схемы, использовать интерактивные элементы. Мы сделали подборку из 6 лучших инструментов для моделирования, которое проще всего внедрить и интегрировать. Visual Paradigm В программе собрано все, что может понадобиться для описания бизнес-процессов: большое количество методологий, блок-схем, шаблонов, диаграмм, матриц. Интерфейс удобный, интуитивно понятный, среду можно настроить под себя. Здесь можно: – связывать между собой разные модели, чтобы видеть полную картину системы бизнеса компании; – программировать условия поведения каждого элемента; – создавать и настраивать шаблоны документов; – протестировать модель, чтобы увидеть недоработки и отладить модель; – автоматизировать генерацию необходимых документов; – выгрузить процесс в виде блок-схемы, графика, диаграммы; – «вытащить» модель в виде программного кода, чтобы в дальнейшем его автоматизировать. Есть версии под Windows и Mac OS. Недостатки: программа платная. BizAgi Modeler Бесплатная программа, которую легко освоить новичкам и удобно использовать уже опытным проектировщикам. Можно использоваться как самостоятельное приложение, а можно — в составе комплекса BizAgi Suite, в котором реализованы просто безграничные возможности моделирования вплоть до создания готового приложения, чтобы сотрудники могли управлять процессом. Интерфейс простой и понятный, ничего лишнего. Есть поддержка русского языка. Поддерживает нотацию BPMN как самую распространенную и удобную. Здесь можно: – тестировать модели; – автоматизировать создание документов; – задавать параметры для каждого элемента отдельно; – разрабатывать модели всей командой; – выгружать процессы в графическом виде. Недостатки: при большом количестве элементов блоки и стрелки могут смещаться и «наползать» друг на друга. ARIS Express Тоже полностью бесплатная программа с простым и понятным интерфейсом. Возможности не такие обширные как в Visual Paradigm, но доступных инструментов достаточно для быстрого создания несложных моделей. Поддерживает нотации BPMN и eEPC. Здесь можно: – создавать карту процессов; – прописывать организационную структуру; – строить графики и диаграммы; – представлять модель в виде блок-схемы. Недостатки: доступны только графические элементы, нет интерактивных возможностей. То есть нельзя связать разные модели между собой, задать условия поведения элементов и т.д. Gliffy У программы широкие возможности. В бесплатной версии есть некоторые ограничения по функционалу, но его с лихвой хватает для создания не самых простых моделей. Интерфейс тоже достаточно понятный и его можно настроить под себя. Здесь можно: – создавать рабочие потоки; – строить диаграммы и карты сайтов; – работать над процессом коллективно; – связывать модели между собой. Недостатки: программа платная, в бесплатной версии функционал ограничен. BPsimulator Упор в программе делается даже не на создание, а на возможность симуляции и отладки бизнес-моделей. Здесь можно: – тестировать модели; – оценивать затратность и продолжительность процессов; – выгружать отчеты по симуляциям; – сохранять отчеты и модели на компьютер или в облачные хранилища. Недостатки: программа платная, в бесплатной версии есть реклама. Draw io Еще одна бесплатная программа с большим количеством доступных диаграмм и элементов. Здесь можно: – связывать модели между собой; – настраивать внешний вид элементов под себя; – строить диаграммы под разные нотации; – сохранять модели на компьютер или в облачных хранилища; – выгружать процессы в графическом виде; – подгружать файлы из облачных хранилищ. Недостатки: нельзя работать коллективно. Рекомендация в заключение. Сегодня, несмотря на высокую конкуренцию в большинстве ниш, ценовые преимущества уходят на второй план. Клиенты и партнеры все больше ценят качество обслуживания, удобство взаимодействия, надежность и простоту отношений. Улучшить эти моменты в вашем бизнесе и выделиться на рынке поможет моделирование бизнес-процессов. Выбирайте инструменты из нашей подборки, осваивайте моделирование — этот навык может стать ключевым фактором роста вашего бизнеса. 2.2. Моделирование деятельности компании в концепции AS-IS Выбор деятельности компании для описания бизнес-процессов – по нему не нашел информацию! Информационное сопровождение процесса моделирования Информационное сопровождение бизнес-процессов– это использование информационных систем и иных средств IT технологий для успешного ведения бизнеса (для извлечения прибыли, получения конкурентных преимуществ и т.п.). Важную роль при сопровождении бизнес-процессов играют интегрированные информационные системы Под ними понимается открытый комплекс программно-аппаратных средств, поддерживающий бизнес-процессы и объединяющий данные, функции и производственные процессы в одно целое. ERP-система (англ. Enterprise Resource Planning System — Система планирования ресурсов предприятия) — это интегрированная система на базе ИТ для управления внутренними и внешними ресурсами предприятия (значимые физические активы, финансовые, материально-технические и человеческие ресурсы). Цель системы — содействие потокам информации между всеми хозяйственными подразделениями (бизнес-функциями) внутри предприятия и информационная поддержка связей с другими предприятиями. Построенная, как правило, на централизованной базе данных, ERP-система формирует стандартизованное единое информационное пространство предприятия. Современные системы класса ERP уже содержат необходимые компоненты, позволяющие организовать информационное сопровождение большинства этапов снабжения, производства и реализации продукции. В практике управления широкое распространение получили следующие программные системы, интегрируемые в рамках ERP-систем в одно целое: - SCM (Supply Chain Management) – управление цепочками снабжением; - CRM (Customer Relationship Management) – управление взаимоотношениями с клиентами; - CRP (Capacity Requirements Planning) – планирование потребности в производственных мощностях. Кроме того можно говорить о EAM(Enterprise Asset Management) -системе — информационная система управления основными фондами предприятия. Её применение позволяет не снижая уровня надёжности сократить затраты на техобслуживание и ремонт и материально-техническое снабжение. EAM -системы позволяют согласованно управлять следующими процессами: § техническое обслуживание и ремонт (ТОиР); § материально-техническое снабжение (МТС); § управление складскими запасами (запчасти для ТОиР); § управление финансами (в области ТОиР и МТС); § управление персоналом (в области ТОиР и МТС); § управление документами (в области ТОиР и МТС). WMS (Warehouse Management System) управление складом — система управления, обеспечивающая автоматизацию и оптимизацию всех процессов складской работы профильного предприятия. Система позволяет управлять складской логистикой в рамках различных технологических процессов (приём и отгрузка товара, внутренние перемещения) в реальном времени. Посредством автоматизации склада достигается высокая оборачиваемость склада, осуществляется быстрая комплектация партий товара, отгрузка их потребителям. CMMS (Computerized Maintenance Management System (CMMS)) Компьютеризированная система управления техническим обслуживанием— комплекс программного обеспечения, включающий базу данных оборудования предприятия, модули планирования проведения технического обслуживания и планово-предупредительногоремонта, оформления заявок на проведение ремонта, модули складского учёта и заявок на покупку материалов, финансового учёта. И так далее и тому подобное… Как правило, центральное место занимает CRP-система, основная задача которой состоит в расчетах загрузки оборудования по производственным технологическим маршрутам с учетом времени на его переналадку, простои, корректировку планов производства и т.д. В результате решения данной задачи составляется план-график выпуска продукции. То, что написано выше тоже что-то не понятное и не знаю, к месту ли оно! Моделирование AS-IS Прежде чем пытаться выбрать существующую или создать собственную информационную систему, а затем внедрить ее, необходимо проанализировать, как работает система в настоящее время. Для этого строится функциональная модель AS-IS. Анализ этой функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов. Детализация бизнес-процессов позволяет выявить недостатки. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ - модели новой организации бизнес-процессов. Модель ТО-ВЕ нужна для оценки последствий внедрения информационной системы и анализа альтернативных путей выполнения работы и документирования того, как система будет функционировать в будущем. Модель AS-IS - это модель «как есть», т.е. модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. Построение функциональной модели AS-IS позволяет четко зафиксировать какие информационные объекты используются при выполнении функций различного уровня детализации. На основе анализа текущих процессов информационной обучающей системы была создана следующая AS-IS модель, которая позволяет выделить и систематизировать процессы, протекающие в данной системе при её функционировании. Главная контекстная диаграмма данной модели приводится на рисунке 1.6.  Рисунок 1.6 – Главная контекстная диаграмма (модель AS-IS) Для более детального понимания логики бизнес-процессов, протекающих в текущей проблемной области разработанная выше контекстная диаграмма была разбита на восемь следующих процессов: 1) выбор источников; 2) разработка оглавления и перечня понятий; 3) переработка текстов в модули по разделам; 4) реализация гипертекста в электронной форме; 5) разработка компьютерной поддержки; 6) отбор материала для тестовых заданий; 7) подготовка материала для тестов; 8) визуализация материала. 2.3. Моделирование деятельности компании в концепции TO-BE Концептуальные идеи по реинжинирингу бизнес-процессов Эффективность организации бизнес-процессов на российских предприятиях оставляет желать лучшего. Большинство применяемых сегодня систем формировались в конце 90-х гг. Первый этап реформирования был проведен в начале 2000-х гг., когда были устранены серьезные ошибки. Большая часть процедур была отлажена и выполняется в принципе правильно, однако нуждается в оптимизации, которая идет не слишком удачно, допускается много ошибок. Кроме того, стремительный рост компаний также требует перестройки систем управления. Очевидно, что необходим качественный реинжиниринг бизнес-процессов, для того чтобы сделать работу эффективной. На рисунке ниже показаны бизнес-процессы предприятия по функциональным отделам, каждый из которых возглавляет руководитель.  Пунктиром отмечены процессы, которые имеют простую конфигурацию (процесс 1), смыкаются (процессы 2 и 3), разветвляются (процесс 4). Идеи реинжиниринга бизнес процессов: Реинжиниринг бизнес-процессов позволяет организовать фирму или бизнес кардинально по-новому и наиболее оптимальным образом (“революционное преобразование” по Хаммеру). Предприятие интересует не статичный, а динамичный результат, и бизнес-процесс, имеющий на выходе товар или услугу, позволяет его получать. “В наш век высоких технологий” бизнес-процесс превосходно поддается автоматизации, и в новом качестве может быть максимально эффективен. Проблемы реинжиниринга бизнес-процессов: типичные ошибки Необходимость работы над повышением эффективности управления очевидна. Однако решается данная задача не только средствами реинжиниринга бизнес-процессов, но и в ходе реорганизации компаний, а также при разработке стратегий и концепций развития. Так почему необходимо делать упор на реинжиниринг? Кроме того, любая автоматизированная система управления статична, и это существенный недостаток. Ведь в наш век сумасшедших темпов и высоких технологий все очень быстро меняется, и часто системы устаревают еще на этапе их внедрения. Как в ходе реформирования бизнес-процессов обеспечить динамичность системы? Проблема автоматизации работы предприятия, актуальная еще с 70-х гг. 20 века, наталкивается на препятствие, которое довольно трудно устранить. Можно создать эффективную автоматизированную систему, последовательно ее внедрить, но мы получаем негибкий инструмент, а ведь всех интересует динамичный результат. Кроме того, на практике в ходе автоматизации работу часто приходится подчинять удобству программирования, что существенно снижает эффективность. Осознав и сформулировав основные проблемы реинжиниринга бизнес процессов, их можно преодолеть. Как обеспечить динамичность системы в ходе реинжиниринга бизнес-процессов Динамику всегда создают живые люди. Шаблонные схемы неизбежно время от времени нуждаются в корректировке. Специалисты по реинжинирингу бизнес-процессов, как правило, решают эту проблему, назначая ответственного за принятие решений. Формально такой подход всех устраивает. Однако на практике работает он не всегда успешно. В деятельности любого предприятия периодически происходят сбои: решения опаздывают, как следствие, процессы прерываются. Восстановить работу информационной системы в этих условиях действительно можно с помощью специально назначенного ответственного. Но обеспечит ли такой подход эффективное управление? Практика показала, что это одна из основных ошибок реинжиниринга бизнес-процессов. Так как фактически руководители подразделений подчиняются только директору компании, не всегда успешно коммуницируют друг с другом, и ответственный без привлечения шефа решить проблему чаще всего не может. Тем не менее, в ряде организаций, небольших рекламных или консалтинговых агентствах, проведенный по данной схеме реинжиниринг бизнес-процессов оправдал себя, и такая структура (ее принято называть матричной) работает. Эффективность обеспечивается благодаря тому, что в указанных отраслях проект реализуется автономно, причем его развитие труднопредсказуемо. На крупных предприятиях, к примеру производственных, где работа заранее планируется, и все более или менее предсказуемо, управление строится по иной схеме. Эту структуру называют дивизионной. Руководитель дивизиона в этом случае также несет ответственность за конечный результат. Все процессы подчинены одному человеку, и его помощникам. Однако существенные отличия все же есть. Ниже мы рассмотрим пример реинжиниринга бизнес-процессов компании по предложенной схеме. Матричная система может быть жизнеспособна, если удобство управления не смешивается с удобством автоматизации, проводимой в ходе реинжиниринга бизнес-процессов компании. Однако нередко именно так и происходит. У товаров, имеющих один рынок сбыта, появляется несколько ответственных, и каждый проводит самостоятельную политику. Заменой системы управления с вертикальной на горизонтальную проблему не решить. Таким способом можно только неоправданно усложнить бизнес-процесс. Кроме того, у функциональных подразделений появятся дополнительные функции. Однако проблема остается. Решить ее можно, усилив горизонтальные связи в компании в ходе реинжиниринга бизнес-процессов. Эффективный алгоритм проведения реинжиниринга бизнес-процессов Процесс оптимизации бизнес-процессов строится по следующей схеме: I этап реинжиниринга бизнес-процессов. Оценка слабых и сильных сторон компании с точки зрения стоящих перед ней задач. В расчет берется все: специалисты, их квалификация и опыт. Рассматриваются наиболее перспективные направления, рынки. II этап реинжиниринга бизнес-процессов. Проводится анализ альтернативных стратегий. Рассматривается перспектива работы в розничном и оптовом форматах, возможность позиционирования в качестве производителя, лидера рынка и т.п. III этап реинжиниринга бизнес-процессов. Подводятся итоги, формулируются стратегические цели компании, которые должны объединять различные направления и рынки. IV этап реинжиниринга бизнес-процессов. Для каждого отдельного направления формируются среднесрочные и краткосрочные задачи для достижения общих целей. К примеру, создание собственной розничной сети в регионе. V этап реинжиниринга бизнес-процессов. Формируется план конкретных мероприятий для достижения стратегических целей, под которые проектируется организационная структура. Сюда входит все: от планирования и взаимодействия, до мотивирования и контроля. VI этап реинжиниринга бизнес-процессов. В конце по каждому направлению готовятся бюджеты, которые объединяются в консолидированный. Исходя из финансового плана, проводится корректировка ранее запланированных мероприятий, готовится итоговый годовой план, разрабатывается механизм его контроля. После реализации реинжиниринга бизнес-процессов по данному плану мы получаем совершенно иную, новую систему управления. Насколько она будет революционной для компании, зависит от того, насколько изменятся стратегические задачи. А вот ее эффективность обеспечивается за счет отсутствия того самого звена ответственных. Система эффективно работает и без них. Приведем аргументы для тех, у кого столь смелое утверждение вызывает сомнения. Проще всего оценить эффективность предложенного алгоритма реинжиниринга бизнес-процессов, сравнив две структуры управления. Допустим, система многоначалия в компании работает за счет повышенной ответственности каждого из менеджеров. Однако это не решит проблему неэффективности системы по той постой причине, что функционал каждого руководителя продукта будет выглядеть так: Анализ рынка и разработка стратегии развития для своего продукта. Проводится исследование, соответствующим специалистам ставится задача разработать дизайн. Конструкторы принимают задачу на формирование определенных качеств продукта, соответствующих потребностям конечного клиента. Технологи должны будут обеспечить сырье, себестоимость, безопасность и прочее. Определяется общий объем производства продукта, и график его выпуска. Маркетологи и специалисты по рекламе подключаются к работе над продвижением продукта на рынок. Не забываем согласовать стратегию со стратегиями продвижения на тот же рынок других продуктов компании. Готовится план сбыта, логистики разрабатывают схемы поставок. Приблизительно так выглядит работа компании, в которой в ходе реинжиниринга бизнес-процессов создали матричную структуру. Чем в таких условиях занято ответственное лицо? Следит за правильностью и своевременностью исполнения мало понятной ему узкопрофессиональной работы? В распоряжении руководителя один главный технолог, один конструктор. Если специалист предложил выпускать кастрюли из нержавеющей стали с определенными показателями, то предложение неизбежно будет принято. Так как самостоятельно оценить эффективность выбора контролирующее лицо не может. Альтернативные предложения внести некому. В то время как у руководителя дивизиона под руками несколько специалистов одного профиля. Вывод очевиден. Информационное сопровождение процесса моделирования- тоже не понятно для меня, и я не нашел инфу. Моделирование TO-BEТаким образом, учитывая анализ модели «КАК ЕСТЬ», была построена модель «КАК ДОЛЖНО БЫТЬ», которая представлена на рисунке 1.8.  Рисунок 1.8 - Контекстная диаграмма модели TO-BE На данной диаграмме представлена общая схема процесса разработки и использования информационного модуля управления учебно-методическим процессом. Процесс обработки материалов по предмету и их размещение в Интернет осуществляется преподавателем, изучение материалов осуществляется пользователем. В качестве правил используются стандартные правила по работе с базами данных.  Рисунок 1.9 - Декомпозиция контекстной диаграммы процесса TO-BE Декомпозиция контекстной диаграммы модели TO-BE представлена на рисунке 1.9. По сравнению с моделью «AS-IS» в данной модели появилась возможность добавления, изменения и удаления сведений о пользователях, а также добавления, изменения и удаления архивов. Следует отметить, что модель «TO-BE» отображает те полезные функции, которые позволят успешно внедрить и использовать данное программное обеспечение для организации процесса дистанционного обучения пользователей. Вывод по второй главе: НАПИШИ САМА, ПОТОМУ ЧТО Я МАЛО РАЗБИРАЮСЬ В ЭТОМ |