Методология анализа ис на основе бизнес процессов

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

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

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

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

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

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

Соседние файлы в папке лекции

• #
• #
• #
• #
• #
• #

Методология создания корпоративных ИС С.Д.Паронджанов, Компания Аргуссофт 1. Введение Цель методологии создания информационных систем (ИС) заключается в организации процесса построения ИС и обеспечении управления этим процессом для того, чтобы гарантировать выполнение требований как к самой ИС, так и к характеристикам процесса разработки. Основными задачами, решение которые должна обеспечивать методология создания корпоративных ИС (вместе с соответствующим набором инструментальных средств) являются следующие задачи: обеспечивать создание корпоративных ИС, отвечающих предъявляемым к ним требованиям по автоматизации деловых процессов и отвечающих целям и задачам организации; гарантировать создание системы с заданным качеством в заданные сроки и в рамках бюджета; поддерживать удобную дисциплину сопровождения, модификации и наращивания системы, чтобы ИС могла отвечать быстро изменяющимся требованиям работы компании; обеспечивать создание корпоративных ИС, отвечающих требованиям открытости, переносимости и масштабируемости; обеспечивать использование в разрабатываемой ИС задела в области информационных технологий, существующего в организации (ПО, баз данных, средств вычислительной техники, телекоммуникаций, технологий). Методология должна обеспечивать снижение сложности процесса создания ИС за счет полного и точного описания этого процесса и применения современных методов и технологий создания ИС на всем жизненном цикле ИС — от замысла до реализации. В 90-ые годы в мире произошли кардинальные изменения как на рынках товаров и услуг, так и в информационных технологиях (ИТ). Современные корпоративные ИС становятся основным фактором успешной работы корпораций на рынке. Для выполнения своего назначения они должны решать значительно более сложные задачи, чем раньше. В соответствии с высокой динамикой изменения ситуации на рынке становятся очень жесткими требования как к функциям, выполняемым ИС, так и к процессу создания ИС. Резко ужесточились требования ко времени разработки отдельных приложений и системы в целом. Появилась необходимость в изменении требований в процессе разработки с тем, чтобы система отвечала требованиям организации на момент конца разработки, а не на момент начала. Достижения в области ИТ позволили преодолеть принципиальные технические и программно- инструментальные проблемы создания корпоративных ИС. Появились современные аппаратно- программные платформы архитектуры клиент-сервер, средства для проведения распределенных параллельных вычислений и управления вычислительным процессом в гетерогенных сетях, методы и средства разработки программ и баз данных, обеспечивающие возможности создания открытых, переносимых, масштабируемых приложений и баз данных, возможности быстрой разработки и т.д. (Об этом свидетельствуют и многочисленные публикации в журнале СУБД.) Практика показывает, что для успешного создания сложных системы, к которым относятся корпоративные ИС, недостаточно иметь только современные платформы и средства, а прежние методологии создания ИС, созданные в 70 — 80-е годы и ориентированные на мэйнфрэймы и однородную среду, устарели и оказались непригодны в новых условиях. Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994г, неудачными оказались более 30% проектов общей стоимостью более чем 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета. Анализ показал, что большинство неудач было связано с отсутствием или неправильным применением методологии проектирования ИС. Мощные импульсы развитию методологий дало появление двух принципиально новых подходов к созданию корпоративных ИС: информационного инжиниринга и реинжиниринга бизнес-процессов (BPR). Предлагаемые в них методы позволили описывать, анализировать и проектировать структуру и деятельность корпораций подобно техническим системам. Каждый из этих подходов породил свой класс методологий, обладающих общими характеристиками. В настоящее время продолжается активный процесс развития и совершенствования методологий создания корпоративных ИС. В этой области работают многие ведущие специалисты во всем мире. В 1994г в Великобритании был создан международный консорциум DSDM (Dynamic Systems Development Method), объединяющий более 100 ведущих фирм мира, который на постоянной основе разрабатывает проекты стандартов, методы и методологию быстрого создания приложений (ИС). В консорциуме участвуют и российские компании. Таким образом, с появлением инструментальных средств нового поколения роль методологии при создании ИС не только не снизилась, — она возросла. По данным опроса, проведенного в 1994 г, большинство американских специалистов считают методологию, наряду с архитектурой клиент- сервер, двумя наиболее важными факторами для успешной разработки своих ИС. Сегодня в нашей стране недостаточно оценивается роль и значение методологии (в отличии от средств проектирования прикладного программного обеспечения). В предстоящие годы задача создания корпоративных ИС на базе современных методологий встанет перед многими отечественными организациями. (При этом заметим, что на Западе методологии по-прежнему считают стратегической продукцией. Многие из них представляют собой ноу-хау и по сей день.) 2. Основные составляющие методологии Целью работы является описание методологии, обеспечивающей решение перечисленных выше основных задач. Предлагаемая методология создания корпоративных ИС состоит из двух основных взаимосвязанных частей: методологии анализа ИС, включающей описание деятельности организации и формирование требований к ИС на основе бизнес-процессов, и методологии проектирования от данных, предназначенной для проектирования и быстрой разработки программного и информационного обеспечения ИС. Предлагаемая методология строится на основе итерационной спиральной модели жизненного цикла ИС. Принципиальной особенностью этой методологии является то, что охватывая все этапы жизненного цикла ИС, она делает основной упор на поддержку начальных этапов создания корпоративных ИС, главной задачей которых является формирование требований к ИС, точно отвечающих целям и задачам организации. В соответствии с подходом информационного инжиниринга, который Джеймс Мартин определяет как «применение взаимосвязанного набора формальных технологий (моделей) для планирования, анализа, проектирования и создания информационных систем на уровне корпораций или отдельных ее частей …», процесс создания ИС строится как процесс построения и развития моделей. Реализация методологии базируется на применении комплекса согласованных между собой инструментальных средств, обеспечивающих высокий уровень автоматизации всех процессов, выполняемых в соответствии с методологией на протяжении ЖЦ ИС. Таким образом, фундамент предлагаемой методологии составляют: итерационная спиральная модель жизненного цикла ИС; комплекс развивающихся систем согласованных моделей; методология анализа ИС на основе бизнес-процессов; методология проектирования от данных; комплекс согласованных инструментальных средств 3. Итерационная спиральная модель жизненного цикла ИС. Методология описывает процесс создания и сопровождения информационных систем в виде жизненного цикла (ЖЦ) ИС, представляя его в виде последовательности стадий, каждая из которых разбита на этапы, и выполняемых на них процессов. Для каждого этапа определяются последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом. Жизненный цикл ИС, определяемый методологией, приведен на рис.1. Он включает стадии анализа, проектирования, разработки, тестирования и интеграции, внедрения, сопровождения и развития ИС. На рисунке приведены также перечень основных этапов для каждой стадии ЖЦ и процессы, выполняемые на протяжении всего ЖЦ — процессы управления и интегральные процессы. Эти процессы в той или иной степени присутствуют на каждом из этапов. Процессы организации и управления проектом: планирование, управление, контроль Анализ Проектирование Разработка Интеграция и тестирование Внедрение Сопровождение * Обследование и создание моделей деятельности организации *Анализ (моделей) существующих ИС *Анализ моделей и формирование требований к ИС *разработка плана создания ИС *Концептуальное проектирование *Разработка архитектуры ИС *Проектирование общей модели данных *Формирование требований к приложениям *Разработка, прототипирование и тестирование приложений *Разработка интеграционных тестов *Разработка пользовательской документации *Интеграция и тестирование приложений в составе системы *Оптимизация приложений и баз данных *Подготовка эксплуатационной документации *Тестирование системы *Обучение пользователей *Развертывание системы на месте эксплуатации *Инсталляция баз данных *Эксплуатация *Проведение ПСИ *Регистрация, диагностика и локализация ошибок *Внесение изменений и тестирование *Управление режимами работы ИС Интегральные процессы: управление конфигурацией, документирование, проверки, интеграция Рис. 1. Жизненный цикл ИС Процесс создания ИС представляет из себя процесс построения и последовательного преобразования согласованных моделей на всех этапах ЖЦ. Эти модели сохраняются и накапливаются в репозитории проекта. С помощью CASE-средств модели создаются, преобразуются и контролируются. Основными результатами на каждом этапе ЖЦ являются модели определяемых на данном этапе объектов (организации, требований к ИС, проекта ИС, требований к приложениям и т.д.). Характер выполняемых процессов и организация работ в представленной модели ЖЦ основаны на подходе информационного инжиниринга и отличаются от классической каскадной модели ЖЦ, несмотря на внешнюю схожесть. При традиционной обработке данных разработка велась строго последовательно. Требования ТЗ утверждались в начале разработки, а их выполнение проверялось в конце. Переход от стадии к стадии, от этапа к этапу допускался только после полного выполнения всего перечня работ и получения всех запланированных результатов. ЖЦ ИС, предлагаемый в новой методологии определяется следующими особенностями. Современные средства CASE, 4GL, СУБД и др. предоставляют возможности быстрого проектирования, прототипирования, разработки и тестирования приложений и баз данных на основе построенных моделей. Методология предполагает активное участие заказчиков на всех этапах создания ИС, поскольку модели, создаваемые на каждом этапе, понятны и разработчику и заказчику. Эти особенности определяют возможности оперативного и быстрого пересмотра требований и разработанных решений на основе современных средств, возможности неравномерной, параллельной разработки различных частей проекта, возможности возврата на предыдущие этапы по отдельным частям проекта при необходимости внесения изменений. Методология предусматривает и версионный характер изменения проекта или его частей при поддержке CASE- средств. Все это определяет итерационный, спиральный характер предлагаемой модели жизненного цикла. 4. Комплекс развивающихся систем согласованных моделей Методология определяет процесс создания корпоративных информационных систем как процесс построения и последовательного развития систем согласованных моделей, начиная от системы моделей, описывающих деятельность организации, и заканчивая готовой информационной системой. Модели должны создаваться, преобразовываться и контролироваться с помощью соответствующих CASE-средств и сохраняться в репозитории. Отправной точкой процесса создания ИС являются модели бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Если построена компьютерная модель организации, описанная в терминах бизнес-процессов и бизнес-функций, то из этой модели может быть получено большинство важнейших требований к информационной системе. Это фундаментальное положение методологии позволяет абсолютно объективно подойти к выработке требований и проектированию информационной системы. Создается система моделей описания требований к ИС, которая затем преобразуется в систему моделей, описывающих проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция. На рис.2 представлен комплекс развивающихся систем согласованных моделей (КРССМ), который показывает состав и последовательность развития систем моделей, создаваемых в процессе построения ИС. Развитие и преобразования моделей происходит в соответствии со схемой преобразования моделей, представленной на рис.3, обеспечивающей полноту и согласованность на каждом уровне преобразования моделей, что обеспечивает корректное формирование и реализацию всех требований к ИС. Архитектурные рамки для развития систем согласованных моделей, определяемые схемой преобразования моделей, основаны на модели Закмана. 5. Методология анализа ИС на основе бизнес-процессов Целью начальных этапов создания ИС, выполняемых на стадии анализа, является формирование требований к ИС, корректно и точно отражающих цели и задачи организации. Чтобы описать процесс создания ИС, отвечающей целям и задачам организации, нужно выяснить в чем заключаются эти цели и задачи. Нужно выяснить требования заказчиков к ИС и преобразовать их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации. Современные средства позволяют достаточно быстро создавать ИС по готовым требованиям. Но как отмечалось выше, очень часто оказывается, что эти системы не удовлетворяют заказчиков. Их приходится постоянно дорабатывать, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС. И это не случайность. Как правило, заказчики не могут правильно и точно сформулировать требования к ИС. Более того, они зачастую не могут точно определить основные цели и задачи своей организации. Задача разработчиков заключается в том, чтобы извлечь эту информацию из заказчиков. Проблема формирования требований к ИС остается до настоящего времени одной из наиболее трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Именно поэтому столь велика роль начальных этапов ЖЦ создания ИС, когда эти требования должны быть выявлены и формализованы, в получении конечного результата. Предлагаемая методология определяет, какие виды данных должны собираться в организации в процессе обследования и какие модели строиться для того, чтобы сформировать требования к ИС. Основу деятельности любой организации составляют ее деловые процессы, или бизнес-процессы, которые определяются целями и задачами организации. Процессы обеспечивают реализацию всех видов деятельности организации, связанных с производством товаров и/или услуг, которые корпорация либо производит, либо продает и поставляет, либо делает все это в совокупности. Каждый бизнес-процесс характеризуется четко определенными во времени началом и концом, внешними интерфейсами, которые либо связывают его с другими бизнес — процессами внутри организации, либо описывают выход во внешнее окружение, последовательностью выполняемых работ и правилами их выполнения (бизнес -правилами). Для каждой работы, входящей в бизнес-процесс, определены временные характеристики, определяющие ее место в общей последовательности работ, условия инициации и время выполнения. В отличии от описания организации на основе иерархической функциональной структуры, которую невозможно объективно оценить, описание на основе процессов позволяет точно представить цели, характеристики (в том числе, динамические) и конечный результат каждого вида деятельности организации. Исходя из того, что основные бизнес-процессы реализуют по своей природе цели и задачи организации, методология предлагает строить описание деятельности организации, как процесс создания и развития систем согласованных моделей, основанных на моделях бизнес-процессов. В процессе детализации моделей и их последующей интеграции должно обеспечиваться сохранение всех функциональных свойств, отражающих цели и задачи организации, и согласованности моделей. Такая согласованность обеспечивается методологией и поддерживающими ее современными CASE-средствами. В процессе описания организации и ее деятельности формируются три основных системы моделей организации: стратегическая, укрупненная и детальная. Все эти системы моделей, описывая основные аспекты организации и ее деятельности, базируются на бизнес-процессах. В систему моделей описания организации добавлена также дополнительная система моделей, для того чтобы можно было учесть аспекты, не связанные с бизнес-процессами, но необходимые при создании ИС. Стратегическая система моделей организации. Процесс создания и развития систем согласованных моделей, описывающих деятельность организации, начинается с построения стратегической системы моделей организации, которая описывает основные аспекты деятельности организации на стратегическом уровне. Главное назначение стратегической системы моделей заключается, во-первых, в определении основных целей и задач организации, и во-вторых, в формировании моделей бизнес-процессов, описывающих основные виды деятельности организации и реализующих ее стратегические цели и задачи. При построении моделей бизнес-процессов на стратегическом уровне не рассматривается иерархическая структура организации, описывающая «вертикальное» представление организации, и устанавливающая функциональные и административные границы между подразделениями. Бизнес -процессы определяют прохождение потоков работ независимо от иерархии и границ подразделений и организаций, которые их выполняют, и показывают взаимодействие, как внутренних, так и внешних (т.е. взаимодействующих с внешним окружением) бизнес-процессов. Модели, входящие в стратегическую систему моделей, строятся при обследовании организации путем опроса экспертов на уровне высшего руководящего персонала, определяющего стратегию организации, а также на базе основных документов организации. Эти модели хранятся в репозитории проекта. Все создаваемые далее модели организации строятся на базе построенных бизнес-процессов по результатам обследования деятельности организации, проводимого на уровне подразделений. Модели строятся с помощью CASE-средств, и сохраняются в репозитории проекта. Построение этих моделей допускает распараллеливание работ при проведении обследования и при построении моделей. Дальнейшее развитие систем согласованных моделей происходит на базе схемы преобразования моделей, представленной на рис.3, которая описывает развитие согласованных моделей по основным аспектам, определяющим деятельность организации (данные, функции, люди, сеть, время, правила). Каждая строка таблицы соответствует системе согласованных моделей данного уровня и раскрывается в виде частных моделей по каждой группе характеристик. Переход от строки к строке показывает развитие системы моделей в процессе описания организации, а правила перехода определяются методологией и обеспечивают полноту и согласованность при построении моделей. уровень описания / группы характеристик — моделей функции данные люди сеть время правила (мотивация) Укрупненная система моделей организации список бизнес-процессов и бизнес-функций организации списки документов списки объектов структурная модель организации перечень структурных подразделений и внешних организаций список работ во времени список целей и задач организации критерии и правила выполнения бизнес-процессов Детальная система моделей организации функциональные модели подразделений: диаграммы потоков данных информационная модель организации (концептуальная модель) структурные модели подразделений, роли персонала логическая модель сетей подразделений организации и внешних связей временная модель выполнения бизнес-процессов и бизнес-функций критерии выполнения бизнес-функций; бизнес-правила Система моделей требований к ИУС требования к функциям; диаграмма потоков данных требования к данным; структуры данных концептуальная модель данных требования к регламенту и интерфейсу пользователей требования к сетевой архитектуре системы требования к временным характеристикам функции требования к регламенту работы ИС Детализация проекта Функционирующая система функции данные пользователи коммуникации зависимость правила Рис. 3. Схема преобразования моделей Укрупненная система моделей организации. Основными задачами описания организации на уровне укрупненной системы моделей являются отображение основных бизнес-процессов, которые описаны на стратегическом уровне, исходя из основных целей и задач организации (без привязки к ее структуре), на реальную иерархически — функциональную структуру организации, а также выделение основных функций подразделений и уточнение состава и характеристик бизнес -процессов. На этом этапе проводится обследование подразделений, в результате которого выявляются выполняемые в них основные функции, их вход и выход. Эти функции распределяются по бизнес- процессам, проходящим через каждое подразделение. В результате формируются и уточняются общие списки бизнес-процессов и функций по подразделениям, списки входных и выходных документов и другие характеристики, и вся эта информация наполняет каждый бизнес-процесс конкретным содержанием. Таким образом, бизнес-процессы становятся путеводителями через иерархически — функциональную структуру организации, определяющими функциональные и информационные связи между различными подразделениями. В процессе отображения бизнес-процессов по уровням организационной иерархии формируется и уточняется общий список бизнес-процессов, и могут появиться новые бизнес-процессы. Детальная система моделей организации. Главными целями создания детальной системы моделей является построение концептуальной модели данных и функциональной модели организации. Для достижения этих целей проводится детализация описания деятельности организации от уровня описания реализации общих бизнес- процессов в организации и списковых моделей в подразделениях до уровня детальных моделей подразделений, позволяющих выделить все функции подразделений, обрабатываемые документы, основные данные, описать регламент работы персонала и создать в итоге функциональную модель организации и концептуальную модель данных. Выявленные в процессе обследования подразделения функции распределяются по бизнес- процессам этого подразделения, наполняя их конкретными работами данного подразделения. При этом описания бизнес-процессов могут дополняться и уточняться. В моделях описываются и детализируются бизнес-процессы, функции, информационные потоки, входные и выходные документы, взаимодействие внутри организации и с внешними объектами, данные, бизнес- правила, роли персонала и регламент, их взаимосвязи, временные и прочие характеристики. Описание деятельности организации с помощью бизнес-процессов и бизнес-правил позволяет определить где, когда и кем выполняется каждая функция, какие данные, информационные и функциональные взаимосвязи для этого нужны, и откуда эти данные поступают. Построенная системы моделей организации может использоваться для трех целей. Во-первых, построенные модели могут быть использованы для формирования требований к ИС. Во-вторых, система моделей может быть использована для анализа деятельности организации с целью ее улучшения, путем проведения инжиниринга или реинжиниринга организации в зависимости от результатов анализа. И, наконец, на основании анализа построенных систем моделей, а также существующих в организации ИС, формируется стратегический план создания, развертывания, сопровождения и развития информационной системы. Система моделей описания требований к ИС Главной целью формирования системы моделей описания требований к ИС является обеспечение корректного перехода от моделей описания организации к системе моделей ИС, описывающих конкретные компоненты проекта, такие как приложения, базы данных, общесистемное ПО, средства вычислительной техники и телекоммуникации, при котором обеспечивается отображение целей и задач организации (выраженных через ее бизнес-процессы, данные, функции и другие модели) в функции и компоненты ИС. Для перехода от системы моделей организации к системе моделей ИС необходимо сформировать систему моделей, описывающих требования к ИС и связать эти требования с проектируемыми компонентами. Система моделей, описывающих требования к ИС, формируется путем отображения системы моделей организации, построенных на этапе обследования. Отображение задается матрицей преобразования, определяемой схемой преобразования моделей. В результате итерационного уточнения формируются основные модели требований к ИС, отражающие цели и задачи организации и включающие требования к архитектуре ИС, к данным, к интерфейсу, к регламенту работы пользователей, к реализуемым функциям и к управлению системой. В системе моделей требований к ИС могут быть отражены также требования, связанные с необходимостью полной или частичной интеграции существующих информационных систем и/или баз данных в новую систему. По итогам анализа построенных моделей должен быть окончательно сформирован план создания, развертывания, сопровождения и развития информационной системы, соответствующий целям, задачам и стратегии развития организации. Из полного набора требований к ИС для дальнейшего анализа и проектирования мы выделим требования к программному и информационному обеспечению и к интерфейсу с пользователями, оставляя в стороне требования к архитектуре и средствам вычислительной техники и телекоммуникаций. 6. Методология проектирования от данных Поскольку данные составляют основу деятельности любой организации и являются наиболее стабильной ее составляющей (функции и структура организации меняются гораздо чаще), то при построении корпоративной ИС наиболее адекватным решаемым задачам является подход к проектированию, основанный на данных. Такой подход обеспечивает наилучшее архитектурное решение при разбиении системы на приложения, а также простоту и согласованность при интеграции приложений. В основу процессов проектирования и разработки ПО и ИО положены методология проектирования от данных DATARUN, которая была разработана в компании CSA (США) для проектирования и быстрой разработки программного и информационного обеспечения переносимых распределенных ИС в архитектуре клиент-сервер. Эти возможности основаны на использовании современных инструментальных средств моделирования, быстрого прототипирования и разработки. Методология DATARUN основана на моделях. Она поддерживает принципы формирования и развития моделей, заложенные в КРССМ. Модель требований к ПО и ИО базируется на бизнес- процессах и формируется на основе системы моделей требований к ИС. Процесс проектирования основан на извлечении всех данных из моделей бизнес-процессов, построении и развитии моделей данных (концептуальной модели данных, модели архитектуры ИС, полной реляционной модели данных и т.д., вплоть до моделей, определяющих приложения). Эти модели взаимоувязаны и интегрированы друг с другом и определяют множество уровней спецификаций для каждого этапа разработки. В процессе проектирования модели данных развиваются от простой начальной версии в законченную спецификацию приложения, используемую для генерации. При этом полная реляционная модель данных может быть разделена на подмодели (подсхемы), представляющие разные части системы, которые могут быть распределены по сети в окружении клиент-сервер в соответствии с архитектурой ИС. По нашему мнению методология DATARUN объединяет лучшие черты реляционного проектирования, объектно-ориентированной технологии и подхода RAD (быстрого создания приложений). В общем ЖЦ ИС методология DATARUN охватывает этапы ЖЦ формирования требований к ПО и ИО и все этапы стадий проектирования, разработки, интеграции и тестирования и внедрения системы (в части ПО и ИО). Дальнейшие шаги по созданию ИС, выполняемые на стадиях сопровождения и развития ИС, не раскрываются в данном докладе. Методология их выполнения базируется на тех же основных принципах, что и описанные методологии. Эти шаги продолжают описанный выше процесс развития систем моделей, представленных в комплексе развивающихся систем согласованных моделей. 7. Комплекс согласованных инструментальных средств Предлагаемая методология создания ИС поддерживается комплексом согласованных между собой инструментальных средств, который обеспечивает непрерывный цикл автоматизации процессов, выполняемых на всех этапах ЖЦ ИС.. Согласованность этих средств обеспечивается наличием интерфейсов для прямого взаимодействия и поддержкой общепринятых стандартов открытых систем. Комплекс средств такого рода позволяет строить модели, описывающие деятельность организации, формировать требования к ИС, быстро переходить от моделей требований к ИС к проекту приложений и баз данных. Он обеспечивает поддержку быстрой итеративной разработки приложений, их тестирование и интеграцию в систему. Заложенные в методологию и поддержанные этими инструментальными средствами принципы, основанные на использовании моделей и повторном использовании спецификаций, обеспечивают возможность быстрого внесения изменений как на стадиях создания ИС, так и на стадиях сопровождения и развития. Созданные на базе этого набора средств распределенные ИС (приложения и БД) могут быть реализованы как в двухзвенной, так и в трехзвенной архитектуре клиент-сервер. Этот же набор средств позволяет переносить приложения и базы данных на различные платформы без перепрограммирования. Приложения, созданные на базе этого набора средств, являются открытыми и масштабируемыми. В состав набора входят средства реинжиниринга, позволяющие автоматически восстанавливать модель существующей системы. В соответствии с проектом эта модель может быть использована для построения моделей новой системы. Методология и поддерживающий ее набор инструментальных средств обеспечивают полный контроль и гибкое управление ходом разработки, включая: поддержку коллективной разработки с возможностью параллельного и распределенного выполнения различных работ; возможность перехода к следующему этапу (шагу), не дожидаясь полного завершения предыдущего; применение методов контроля качества и постоянный контроль полученных результатов; поддержку итеративного характера разработки (возможность пересмотра полученных результатов и возврата на любой из предыдущих этапов; возможность быстрого внесения изменений в требования в процессе разработки; управление конфигурацией. 8. Заключение Для создания корпоративной информационной системы, отвечающей целям и задачам организации нужна специальная методология, которая бы во-первых, помогла сформировать требования к ИС, отвечающие целям и задачам организации, и во-вторых, спроектировать и разработать систему, отвечающую этим требованиям, с учетом их изменений в процессе разработки. Наличие такой методологии является решающим фактором успеха при создании корпоративных ИС. В статье предложена методология, обеспечивающая создание корпоративных ИС, отвечающих целям и задачам организации, предъявляемым к ним требованиям по автоматизации деловых процессов, и обеспечивающая выполнение основных требований к процессу разработки (по срокам, качеству и т.д). При создании корпоративных информационных систем необходимым слагаемым успеха помимо методологии, является также и комплекс согласованных инструментальных средств, поддерживающий эту методологию и обеспечивающий автоматизацию процессов, выполняемых на всех этапах ЖЦ создания ИС. Эти средства должны поддерживать быстрое построение корпоративных ИС, отвечающих целям и задачам организации и удовлетворяющих основным требованиям (открытости, переносимости и масштабируемости и т.д.), а также обеспечивать поддержку процессов управления проектом. Такой набор согласованных инструментальных средств, поддерживающих предлагаемую методологию, и приведен в докладе. Предложенная методология обеспечивает снижение сложности процесса создания ИС. Заложенные в методологию и поддержанные инструментальными средствами принципы, (разработка на основе моделей, проектирование от данных, повторное использование спецификаций и др.) упрощают разработку и обеспечивают возможность быстрого внесения изменений как на стадиях создания ИС, так и на стадиях сопровождения и развития. Благодарности В основу настоящего доклада положены результаты, полученные автором в процессе совместной работы и обсуждений с д.т.н., профессором Е.Г.Ойхманом и д.т.н. Б.А.Позиным. Выражаю им свою глубокую признательность за помощь в подготовке данного доклада. [Назад] [Содержание] [Вперед]

VPS/VDS серверы. 30 локаций на выбор Серверы VPS/VDS с большим диском Хорошие условия для реселлеров 4VPS.SU — VPS в 17-ти странах 2Gbit/s безлимит Современное железо! Бесплатный конструктор сайтов и Landing Page Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен SSD VPS в Нидерландах под различные задачи от 2.6$ Выделенные серверы: в Европе / в России. Виртуальные серверы: в Европе / в России. Партнерская программа Новости мира IT: 21.03 — Одну из первых в мире компьютерных мышей продали с аукциона за $179 тысяч 21.03 — Российские учёные доказали квантовую природу графеновых транзисторов через 15 лет после их открытия 21.03 — Apple захватила 75 % рынка смартфонов премиум-класса в 2022 году — на втором месте Samsung 21.03 — Wildberries начнёт выпускать электронику под собственным брендом — её будут собирать в Китае, России и Беларуси 21.03 — Магазин приложений RuStore так и не начали предустанавливать на смартфоны, продаваемые в России 21.03 — Конференция Heisenbug? Ну-ка затестим! 20.03 — Фонд СПО объявил обладателей ежегодной премии за вклад в развитие свободного ПО 20.03 — Microsoft намерена запустить магазин мобильных приложений — конкурента Apple App Store и Google Play 20.03 — Чиновников администрации президента обязали заменить iPhone на другие смартфоны, желательно с «Авророй» 20.03 — На импортное оптоволокно в России могут быть введены таможенные пошлины 20.03 — Maxell первой в мире наладит выпуск твердотельных аккумуляторов для промышленных роботов 20.03 — Биткоин стал дороже $28 тысяч, ему снова прогнозируют огромный рост в дальнейшем 20.03 — Microsoft интегрировала криптовалютный кошелёк в браузер Edge 17.03 — Учёные МФТИ первыми в России запустили квантовую нейросеть — точность решения задач превысила 90 % 17.03 — За год число фишинговых сайтов в доменных зонах .RU и .РФ выросло в три раза 17.03 — Google нашла десятки уязвимостей в модемах Samsung — для защиты на смартфонах Pixel, Samsung и Vivo нужно отключить некоторые функции 17.03 — Baidu разрешили запустить в Пекине сервис беспилотных такси без водителя в салоне 17.03 — Обновление Windows 11 затормозило некоторые SSD — копировать большие файлы пока рекомендуют через командную строку 17.03 — Google Play удалил приложения ещё 9 российских банков 17.03 — TechTrain. Фестиваль про AI-разработку и жизнь Архив новостей Сервисы речевой аналитики Laucharge: сервис приема платежей WBPROD: продвигайтесь на маркетплейсах эффективно Системы бронирования рабочих мест в офисеc Система бронирования рабочих мест Office Flexispace: экономьте грамотно на офисных помещениях Колл-центр: как не потерять ни одного клиента

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

Понятие анализа бизнес-процессов

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

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

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

Цели

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

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

Что включает базовая оценка?

Базовый анализ включает в себя целый комплекс мероприятий, которые заключаются в:

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

Виды анализа бизнес-процессов

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

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

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

SWOT-анализ

SWOT-анализ – один из наиболее популярных качественных методов исследования.

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

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

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

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

Определение проблем процесса

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

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

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

Распределение по уровням

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

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

Анализ по отношению к типовым требованиям

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

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

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

Визуальный аудит графических схем

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

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

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

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

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

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

Показатели эффективности БП

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

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

Э = Р / З

Э – эффективность работы фирмы.

Р – результаты работы производства.

З – уровень производственных затрат.

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

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

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

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

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

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

Представим их общую характеристику.

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

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

• чистой прибыли;
• рентабельности продаж.

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

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

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

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

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

• материалоемкости;
• затрат на единицу продукции;
• оборачиваемости оборотных средств;
• фондоемкости;
• фондоотдачи;
• фондовооруженности.

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

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

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

Показатель оборачиваемости оборотных средств дает возможность анализа эффективности использования оборотных активов фирмы.

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

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

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

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

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

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

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

• производительности труда;
• трудоемкости;
• выработки.

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

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

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

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

Технология Process mining

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

Результатом такого анализа становится выявление:

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

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

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

Пример пошагового анализа бизнес-процессов

Проведем анализ бизнес-процессов ООО «Каскад».

Согласно полученным данным, общая продолжительность производственного процесса равна 19440 мин, при этом время создания ценности равно 2720 мин, что составляет 13,99% от общего времени производственного процесса. Следует сформировать вывод о том, что наибольшая часть времени, затрачиваемого на производственный процесс, является временем потерь, что свидетельствует о необходимости оптимизации организации производства.

Отметим, что значительное время производственного процесса отводится на операции, связанные с хранением, время которого составляет 2750 мин, что равно 14,15% общего времени. Наибольшее время, затрачиваемое при производстве – это время транспортировки – 12000 мин, что составляет 61,73% общего времени производственного процесса.

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

В результате внесенных изменений незначительно снизилось время создания ценности за счет использования более прогрессивных технологий и современного оборудования. Перепланировка размещения рабочих мест в цехах позволила сократить время на транспортировку и хранение, в результате чего общее время производственного процесса составило 5870 мин, из которых время создания ценности – 2420 мин или 41,23% общего времени.

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

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

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

Схема №1. Классификация видов анализа бизнес-процессов

Можно выделить несколько методик субъективной оценки процессов. Во многом такие методики были разработаны в трудах основоположников и последователей методологии реинжиниринга бизнес-процессов, например у Хаммера и Чампи, Робсона и Уллаха и т. д. Кроме того, для качественного анализа процессов могут быть использованы общеизвестные методы анализа: SWOT-анализ, анализ при помощи Бостонской матрицы и другие.

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

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

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

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

SWOT-анализ процесса

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

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

Подробнее о SWOT-анализе можете узнать здесь.

Анализ проблем процесса: выделение проблемных областей

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

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

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

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Ранжирование процессов на основе субъективной оценки

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

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

Таблица №2. Ранжирование процессов организации

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

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

Анализ процесса по отношению к типовым требованиям

Любой процесс организации можно анализировать с точки зрения удовлетворения некоторым требованиям. В настоящее время в мире нет специализированных стандартов, регламентирующих требования к процессам бизнеса (ИСО/МЭК 15504-2:2003). Предлагаемая ниже структура требований к организации процесса разработана нами с учетом требований стандарта ИСО 9001.

Стандарты ИСО серии 9000 рекомендуют использовать цикл PDCA (Plan-Do-Check-Act) для создания системы постоянного улучшения процесса. Мы считаем, что применение данного цикла также является обязательным требованием, которое необходимо предъявлять к процессам.

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

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

• регламентация всех составляющих процесса;
• использование цикла постоянного улучшения процесса PDCA.

Требования к организации процесса, учитывающие рекомендации стандарта ИСО 9001, представлены в таблице №3 ниже

Таблица №3. Вопросник для анализа процесса по отношению к типовым требованиям

При проведении анализа процесса должна быть собрана информация согласно требованиям табл. №3. Выполнение такой работы может быть целесообразным при осуществлении проекта реорганизации процессов на предприятии. Процесс подвергается анализу на наличие цикла PDCA. Напомним, что цикл PDCA создается вокруг процесса, как показано на рис. 2. Назначение функций цикла постоянного улучшения процесса показано в табл. №4.

Рис. 2. Цикл PDCA

Таблица № 4. Цикл PDCA для процесса

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

Таблица № 5. Функции цикла управления

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

Рис. 3. Цикл управления по отклонениям

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Визуальный анализ графических схем процесса

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

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

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

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

1. Анализ потребности во входах/анализ потребности в вы ходах.
2. Анализ неиспользуемых выходов.

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

Рис. 4. Выявление потребности во входах

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

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

Рис. 5. Выявление потребности в выходах

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

Для поиска неиспользуемых выходов следует составить следующую таблицу:

Таблица № 6. Поиск неиспользуемых выходов процесса

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

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

• отсутствие необходимых функций;
• наличие излишних функций;
• дублирование функций.

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

Рис. 6. Отсутствие необходимой функции в модели процесса

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

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

Рассмотрим функции контроля. На рис. 7 представлен пример процесса, в который дополнительно внесено две такие функции.

Рис. 7. Отсутствие функций контроля

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

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

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

Рис. 8. Отсутствие функции по обработке внештатной ситуации

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

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

Рис. 9. Отсутствие функции по обработке несоответствующей продукции

Приведем простейший пример отсутствующей функции по регистрации параметров выполнения процесса (см. рис. 10).

Рис. 10. Отсутствие функции по регистрации фактической информации о процессе

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

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

Рис. 11. Анализ дублирования функций процесса

На рис. 11 представлено два различных процесса. Они могут выполняться в разных подразделениях. Рассматривается две функции: «функция процесса 1» и «функция процесса 2». Их названия могут существенно отличаться. Выходы этих функций также различны: «документ 1» и «документ 2». Каким образом выявить дублирование? Следует провести анализ выходов этих двух функций по следующим направлениям:

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

На рис. 11 показано, что в обоих документах содержится одна и та же «информация А». Это может означать, что рассматриваемые функции полностью или частично дублируют друг друга. По крайней мере, стоит обратить на них пристальное внимание. Как выявить дублирование функций на практике? Очевидно, что сравнивать между собой функции процессов невозможно. В первую очередь необходимо составить список функций, «подозреваемых» в дублировании. Такого рода информация может быть получена на основе интервью с сотрудниками и руководителями подразделений.
Кроме того, аналитик, работающий с процессами достаточно долгое время, должен иметь предварительную информацию о возможном дублировании функций.

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Измерение и анализ показателей процесса

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

• показатели процесса;
• показатели продукта процесса;
• показатели удовлетворенности клиентов процесса.

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

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

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

На рис. 12 приводится простейшая классификация показателей процессов.

Рис. 12. Классификация показателей процесса

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

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

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

Показатели времени выполнения процесса

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

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

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

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

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

На рис. 13 показана схема расчета показателя времени выполнения простейшего линейного процесса.

Рис. 13. Пример расчета времени процесса

Технические показатели процесса

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

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

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

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

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

Показатели стоимости процесса

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

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

Показатели стоимости продуктов процесса:

• стоимость сырья и материалов;
• затраты на оплату труда;
• амортизация оборудования;
• прочие затраты.

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

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

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

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

Рис. 14. Изменение стоимостных показателей при улучшении процесса

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

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

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

Рис. 15. Выявление стоимостных показателей процесса

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

Показатели качества процесса

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

К показателям качества процесса можно отнести следующие:

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

Показатели 1–6 достаточно просто измерить. Необходимо разработать методики сбора и обработки соответствующей информации. Показатели 7–10 интуитивно понятны, однако их практическое измерение выполнить затруднительно. Можно отслеживать изменение данных показателей, анализируя сбои в работе процесса, которые происходят при различных внешних и внутренних внештатных ситуациях. Выявление причин таких сбоев поможет выявить направления улучшения процесса.

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

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

Временные

К числу относительных показателей времени выполнения можно отнести:

• показатели «план/факт»:
• плановое время выполнения процесса/фактическое время выполнения процесса;
• плановое время выполнения функции/фактическое время выполнения функции;
• сравнение с другим процессом:
• среднее время выполнения процесса/среднее время выполнения процесса у конкурента;
• время обслуживания, требуемое клиентом/фактическое время обслуживания клиента;
• удельные:
• время выполнения процесса/численность персонала процесса;
• время выполнения процесса/количество функций процесса.

Стоимостные

К числу относительных стоимостных показателей можно отнести:

• показатели «план/факт»:
• плановая стоимость процесса/фактическая стоимость процесса;
• плановые затраты на ресурс/фактические затраты на ресурс;
• планируемое сокращение затрат на процесс/фактическое сокращение затрат на процесс;
• плановые затраты на ремонт/фактические затраты на ремонт.
• сравнение с другим процессом:
• стоимость процесса/стоимость процесса конкурента;
• величина оплаты персонала процесса/величина оплаты персонала процесса конкурента;
• удельные:
• рентабельность процесса = прибыль по процессу/стоимость процесса;
• рентабельность оборотных активов процесса = прибыль по процессу/объем используемых оборотных активов;
• выработка на одного сотрудника = объем продукции процесса/численность сотрудников;
• фондоотдача процесса = объем продукции/величина основных фондов;
• оборачиваемость оборотных активов процесса = величина выручки/средние остатки оборотных активов процесса;
• доля накладных расходов = величина накладных расходов/стоимость процесса.
  Кроме указанных выше, могут определяться и рассчитываться многие другие относительные стоимостные показатели процесса, при этом следует использовать методики финансового менеджмента.

Технические

К числу относительных технических показателей можно от нести:

• показатели «план/факт»:
• плановое количество простоев/фактическое количество простоев;
• плановое количество транзакций/фактическое количество транзакций;
• сравнение с другим процессом:
• численность персонала процесса/численность персонала процесса конкурента;
• количество автоматизированных рабочих мест процесса/количество автоматизированных рабочих мест процесса конкурента;
• удельные:
• степень загрузки персонала = общее время работы по выполнению функций процесса/общее рабочее время всех сотрудников;
• степень автоматизации = количество автоматизированных функций процесса/общее количество функций процесса;
• величина офисной площади на одного сотрудника;
• количество персональных компьютеров на одного сотрудника.

Показатели качества

К числу относительных показателей качества процесса можно отнести:

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

!!! Полезный материал! Статьи “Как внедрить бизнес-процессы за 2 дня”. Скачать >

Автор: В.Репин, В.Елиферов

Источник: материалы сайта cfin.ru

Методы бизнес-анализа

Вступление

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

Тема на самом деле довольно интересная и материалов на русском или украинском языках довольно мало. На мой взгляд, одной из причин этому есть относительно недавнее его появление. Хотя следует добавить, что методы, о которых мы будем вести речь рассматриваются по отдельности во многих учебниках на многих языках.
Определение бизнес-анализа возьмем из Википедии, чтобы не придумывать велосипед:

«Бизнес-анализ — дисциплина выявления деловых потребностей и нахождения решений деловых проблем»

Однако, есть и другое определение. Согласно своду знаний о бизнес-анализе (Business Analysis Body of Knowledge 2.0):

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

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

По сути

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

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

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

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

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

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

Метод определения критериев принятия и оценки

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

Согласно определению, критерии в данном методе разделяются на два класса:

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

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

Свод знаний по бизнес-анализу упоминает о достоинствах и недостатках метода.

Достоинства

• Для agile разработки может быть необходимым, чтобы все требования были выражены в форме, которая позволяет протестировать соблюдение этих требований;
• Критерии принятия необходимы, когда требования выражают договорные обязательства.

Недостатки

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

Мозговой штурм

Целью метода является генерирование новых идей, которые будут служить материалом для дальнейшего анализа.

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

• Как мы можем решить проблему сейчас (подручными средствами)?
• Какие препятствия стоят перед нами для выбора определенного решения или подхода?
• Что может вызвать задержку?
• Как мы можем решить проблему?

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

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

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

Преимущества

• Возможность сформировать большое количество идей за короткий промежуток времени;
• Включает креативное мышление;
• Может помочь снять напряжение между участниками совещания.

Недостатки

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

Анализ бизнес-правил

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

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

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

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

Пример резолютивного правила (которое определяет поведение участников процесса):

Сотрудник должен получить письменное разрешение от директора департамента безопасности на использование на работе личного ноутбука.

Или

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

Пример структурного правила (которое определяет структуру знания, что позволяет определить правдивость, ложность или отношение к определенной категории):

Оплата принимается только безналичным расчетом.

Или

Индекс выполнения сроков определяется как EV / PV, где EV — освоенный объем, а PV — плановый объем.

Преимущества

• Четкое определение правил раздельно от процессов позволяет организации менять правила без изменения процессов.

Недостатки

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

Словарь данных и глоссарий

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

Так, метод выделяет две составляющие:

Глоссарий — список терминов и их определение.

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

Словарь данных состоит из простых элементов и составных.

Простые элементы содержат следующую информацию:

• Название — уникальное имя;
• Псевдонимы (aliases) — другие названия, которые используют заинтересованные стороны для этого понятия;
• Значения — возможные значения, которые может принимать элемент;
• Описание — определение элемента в контексте решения.

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

• Последовательности — показывают порядок простых элементов (в последовательностях простые элементы всегда определяются в четко определенной последовательности);
• Повторения — показывают, что простые элементы могут несколько раз появляться в составном элементе;
• Опциональные элементы — могут присутствовать или отсутствовать в составном элементе.

Диаграммы потоков данных

Тема диаграмм потоков данных воистину достойна отдельной статьи. Существуют различные нотации (например известная всем Гейна-Сарсона в BPWin, которую многие наверняка составляли в ВУЗах или Йордана). Но вернемся обратно.

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

Диаграммы описывают:

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

Пример одной из таких диаграмм приведен ниже:

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

В целом же можно привести и другой пример:

Диаграммы рисовались в Dia, которая является образцом ужаса в отрисовке диаграмм под GNU/Linux.

Заключение

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

Ссылки:

1. Business Analysis Body of Knowledge Overview
2. Val IT

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

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

Что такое моделирование бизнес-процессов

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

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

Для создания модели бизнес-процесса важно определить:

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

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

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

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

Проблемы, которых помогает избежать моделирование бизнес-процессов:

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

Чем описание бизнес-процессов отличается от моделирования

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

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

Классификация методологий моделирования бизнес-процессов

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

Методология включает в себя:

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

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

• Структурный подход рассматривает систему как набор элементов, подсистем и отношений между ними. Используется для организационного развития предприятий и компаний: ищет способы оптимизации, разрабатывает рабочие регламенты и должностные инструкции. Методологии: SADT, DFD, WFD.
• Объектно-ориентированный подход рассматривает систему как набор взаимодействующих объектов. Объекты — предметы, которые преобразуются при выполнении процессов. При объектно-ориентированном подходе сначала выделяются объекты, а затем действия, в которых они участвуют. Подход используется для визуализации, конструирования и документирования. Методология: BAAM.
• Интегрированный подход объединяет структурный и объектно-ориентированный подходы. Даёт полное и комплексное представление о моделируемом объекте. Методология: ARIS.

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

Разберём особенности популярных методологий моделирования.

SADT

SADT — методология структурного анализа и проектирования, разработанная Дугласом Россом в 1969-1973 годах. Объединяет и организует диаграммы в иерархические древовидные структуры — чем выше уровень диаграммы, тем она менее детализирована.

Диаграммы SADT состоят из:

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

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

Особенности методологии SADT:

• Универсальность — может использоваться для проектирования сложных систем любого назначения: управления и контроля, телефонных сетей, учёт материально-технических ресурсов.
• Способность отражать такие системные характеристики, как управление, обратная связь и исполнители.
• Наличие процедур для поддержки коллективной работы.
• Возможность использования на ранних этапах создания системы и сочетания с другими структурными методами проектирования.

Самая распространённая нотация — IDEF0.

Пример бизнес-процесса в нотации IDEF0

DFD

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

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

Особенности методологии DFD:

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

Самые распространённые нотации — Эд Йордана и Тома де Марко.

Пример описания процесса обработки заказа клиента с помощью методологии DFD

WFD

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

Методология применяется для моделирования таких бизнес-процессов компаний как: «Выставление счетов», «Подготовка договора», «Изготовление детали».

Особенности методологии WFD:

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

Самая распространённая нотация — IDEF3.

Пример описания процесса согласования договора с помощью нотации IDEF3

ARIS

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

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

Особенности методологии ARIS:

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

Самые распространённые нотации — EPC, UML и BPMN.

Пример бизнес-процесса в BPMN-нотации

BAAM

BAAM — методология описания деятельности. Включает в себя шесть бизнес-моделей: ESM, BCM, BPM, BFM, BOM, ERM. С их помощью последовательно описывает функции, бизнес-процессы, организационные и структурные особенности компаний, её подразделения, а также материальные и информационные потоки между ними. Методология представляет собой схему, на которой вместо работ отображаются структурные подразделения и взаимодействия между ними.

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

Особенности методологии BAAM:

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

Самые распространённые нотации — Нотация Питера Чена, нотация Гордона Эвереста Crow’s Foot.

Пример бизнес-процесса в нотации Питера Чена

Сравнение нотаций

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

Критерий сравнения	IDEF0	EPC	BPMN
Принцип построения диаграммы	Принцип доминирования	Временная последовательность выполнения процедур	Временная последовательность выполнения процедур
Описание процедуры процесса	Объект на диаграмме	Объект на диаграмме	Объект на диаграмме
Модель отражает	Структуру системы, функции, потоки ресурсов и информации	Структуру системы, функции, потоки ресурсов и информации	Функции системы, внутренние процессы
Графические элементы	Прямоугольники — действия и этапы. Стрелки — ресурсы и исполнители	Фигуры разных цветов. Розовые — события, зелёные — функции, жёлтые — исполнители, серые — ресурсы, оранжевые — ИС. Соединительные элементы — стрелки и разделители «и», «или»	Задача — прямоугольник, событие — круг, поток — стрелка. Также есть сноски и базы данных
Достоинство	Высокая степень детализации. Можно создать модель, которая будет учитывать практически все ресурсы, всех сотрудников	Простота восприятия	Простота восприятия. Подходит для описания внутренних бизнес-процессов компании
Недостаток	Модель занимает много места	Приходится создавать события даже для незначительных этапов	Зациклена на бизнес-процессах, не подходит для описания структуры
Сфера применения	Долгосрочное планирование, управление финансами	Описание технологических процессов предприятия — выставление счетов, отгрузки товаров и т.д.	Управленческий консалтинг, внедрение систем управления качеством, оптимизация бизнес-процессов

Коротко о главном

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