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

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

• функции (операции, действия). Формальное определение функции - это предметно-ориентированное задание или действие, выполняемое над объектом, в результате которого достигается одна или несколько целей, стоящих перед компанией. Функция - сложное понятие, наиболее часто используемое при обозначении границ ответственности сотрудников. Так как функция - набор действий, это позволяет рассматривать процесс как частный случай функции. С другой стороны, процесс может включать в себя действия, являющиеся функциями. В данной методике эти понятия рассматриваются совместно. И иногда используются как синонимы. Например, процесс работы с клиентом - последовательность действий, а функция работа с клиентом, закрепленная за отделом продаж - это крут обязанностей. В данном случае эти понятия совпадают. Возможны три варианта структурирования функций в вашей компании:
  • по объекту - объектно-ориентированный;
  • по процессу - процессно-ориентированный;
  • по операциям - операционно-ориентированный;
• события. Понятие "событие" означает приобретение определенного статуса объектом, связанным с бизнес-процессом. Кроме определения границ процесса, события используются и в самом процессе для обозначения ветвлений (вариантов). Например, при выполнении функции "Проверка наличия товара на складе" может быть два результата: "Товар есть в наличии" либо "Товара нет в наличии". В данном случае это и будет событиями, показывающими направление течения процесса (разные стрелки). Если "Товар есть в наличии", то далее по БП может следовать отгрузка. Если "Товара нет в наличии", то клиенту сообщается о невозможности выполнить заказ с дальнейшими вариантами. В ERP-системах чаще используется термин-понятие "состояние". Состояние и событие всегда связаны с каким либо объектом;
• ресурсы, среди которых отдельно выделяют две группы:
  • исполнители:
    • организационные звенья (т.е. структурные подразделения - отделы, департаменты, дивизионы и т.д.)
    • должности (различные должности из штатного расписания компании, например "Менеджер по продажам")
    • сотрудники (персоналии-ФИО, работники компании, например Иванов Иван Иванович)
    • роли (обособленные группы обязанностей, которые может исполнять сотрудник в процессе, обладая при этом и определенными правами. Роли могут в частном случае совпадать с должностью - как по функционалу, так и по названию. Например: Гл. бухгалтер);
  • информационные ресурсы (документы, файлы, архивы и др.)- совокупность всех данных, имеющихся на предприятии. Информация является ключевой составляющей для управления бизнес-процессами. При описании процесса, определяется информация, используемая процессом и выдаваемая в качестве результата. Существует также справочная информация. Информацию можно классифицировать по следующим признакам: место возникновения, стадия обработки, способ отображения, стабильность, функция управления. Различные классификации информации необходимы при анализе информационных потоков;
• продукты и услуги - являются результатом, создаваемым в ходе выполнения процесса и соответствующим требованиям клиентов процесса. Это не обязательно продукция компании. Для внутреннего процесса результатом может быть документ, предоставляемый начальству. Например, результатом процесса планирования продаж является «План продаж» компании в натуральном и денежном выражении. К этому плану руководство компании и служба производства, являющиеся клиентами процесса, предъявляют определенные требования в виде формата предоставления, сроков и т.п.;

Идентификация бизнес-процессов... Наш подход к классификации бизнес-процессов организации не претендует на всеобъемлемость и предполагает систематизацию существующих определений (в сегодняшней России - часто весьма противоречивых). Тем не менее, наша классификация позволяет, в зависимости от характера задач, возникающих в процессе развития организации, ориентировать внедренцев (ERP-CRM-разработчиков) на специфику и сущность тех или иных бизнес-процессов деятельности Заказчика.
  Восприятие бизнес-процессов Закзачика как объекта управления во многом связано с тем, по каким принципиальным положениям можно идентифицировать те или иные процессы деятельности бизнес-системы. На наш взгляд, определяющим является система принципов формирования бизнес-процессов.
  По отношению к компании Заказчика бизнес-процессы могут быть внешними и внутренними. Внешним называется бизнес-процесс, имеющий вход и/или выход вне организации. Внутренний бизнес-процесс — это процесс, полностью находящийся в рамках организации.
  Далее мы считаем правильным выделить базовые принципы бизнес-процессов, позволяющие идентифицировать их как таковые. Это:

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

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

• самый популярный в России стандарт BPMN. Business Process Modeling Notation - графическая нотация для моделирования бизнес процессов. BPMN была разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group, после слияния организаций в 2005 году. Моделирование в BPMN осуществляется посредством диаграмм с небольшим числом графических элементов. Это помогает пользователям быстро понимать логику процесса. Выделяют четыре основные категории элементов:
  • Объекты потока управления: события, действия и логические операторы. Объекты потока управления разделяются на три основных типа: события (events), действия (activities) и логические операторы (gateways).
  • Соединяющие объекты: поток управления, поток сообщений и ассоциации
  • Роли: пулы и дорожки
  • Артефакты: данные, группы и текстовые аннотации.
  Элементы этих четырёх категорий позволяют строить диаграммы бизнес процессов (ДБП). Основная цель BPMN — создание стандартной нотации понятной всем бизнес пользователям. Бизнес-пользователи включают в себя бизнес-аналитиков, создающих и улучшающих процессы, технических разработчиков, ответственных за реализацию процессов и менеджеров, следящих за процессами и управляющих ими.
   
• Семейство стандартов IDEF (Госдепартамент и BBC США).
    IDEF0 (Integration Definition for Function Modeling) как стандарт, был разработан в 1981 году департаментом Военно-Воздушных Сил США в рамках программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing). Набор стандартов IDEF унаследовал свое название от этой программы (IDEF=ICAM DEFinition). С помощью графического языка IDEF0, изучаемая система предстает в виде набора взаимосвязанных функциональных блоков. Моделирование бизнес-процессов средствами IDEF0, как правило, является первым этапом изучения системы.
    IDEF3 (Integration Definition for Function Modeling). С помощью IDEF3 описывается логика выполнения действий. IDEF3 может использоваться самостоятельно и совместно с методологией IDEF0: любой функциональный блок IDEF0 может быть представлен в виде последовательности процессов или операций средствами IDEF3. Если IDEF0 описывает, что делается в системе, то IDEF3 описывает, как это делается.
    Для практики отметим IDEF-Lockheed - модернизацию IDEF-нотации, применяемую в американской военно-промышленной корпорации, в которой для удобства работы отменены многие ограничения IDEF0.
   
• методология ARIS eEPC была одной из первых в РФ. Где eEPC - extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями. ARIS - Architecture of Integrated Information Systems - методология и программный продукт компании IDS Sheer AG (Германия) для моделирования бизнес-процессов и описания бизнес-процессов компании. Кирпичиком ARIS-нотации является функция (действия), которые выполняют пользователи. Через использование логических операторов можно указать ветвление потоков работ. Компания в ARIS м.б. рассматрена с четырех точек зрения:
  • Организационной структуры;
  • Функциональной структуры;
  • Структуры данных;
  • Структуры процессов;
  При этом каждая из этих точек зрения разделяется еще на три подуровня: описание требований, описание спецификации, описание внедрения. Как минусом, так и плюсом то, что потоки документов прописываются в схеме явно, и они отделены от причинно-следственных связей (потоков работ). Главные минусы ARIS-а - невозможность указать длительность процесса (т.е. эта модель позволяет отобразить только логическую последовательность) и неудобство для восприятия сотрудниками. Моделирование в ARIS eEPC не дает преимуществ ни для автоматизации, ни для регламентации.
   
• Семейство стандартов RUP (компания IBM Rational Software). RUP является результатом объединения подходов Rational Approach и Objectory Process, происшедшего после слияния в 1995 году компаний Rational Software и Objectory AB. RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами жизненного цикла ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Согласно технологии RUP жизненный цикл ПО разбивается на отдельные циклы, в каждом из которых создается новое поколение продукта. Каждый цикл, в свою очередь, разбивается на четыре последовательные стадии:
  • начальная стадия (inception)
  • стадия разработки (elaboration)
  • стадия конструирования (construction)
  • стадия ввода в действие (transition)
  Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и принимаются критически важные решения о дальнейшей разработке.

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

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

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

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

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

Программы описания бизнес-процессов или в чем создает бизнес-аналитик... Т.е. в чем рисовать блок-схемы (квадратики со стрелками). С одной стороны, в крупных компаниях просто ПО-рисовалки сейчас уже не применяют - модны большие программы. С другой, для 99% Заказчиков справедливо высказывание "...почему не рисовать в простейшей программе Visio из MS Office?..."
  При рисовании бизнес-процессов важным критерием является возможность использования изученной (знакомой пользователям) программы. Например, Microsoft Business Solution еще в 2002 году предлагал для информационной системы Microsoft Navision нотацию On-Target, сопровожденную специальной программой. Это как раз тот самый случай, когда лучше выбрать что-то другое - мало того что, нотацию On-Target в России ни кто не знает, так еще и программа потребует много времени на ее изучение. Положительным же примером мы бы назвали использование нотации IDEF, и программы MS Visio, весьма распространенной и обладающей, необходимым набором инструментов для рисования IDEF диаграмм.
  Программные продукты, реализующие распространенные методологии:

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

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

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

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

С уважением
Дмитрий В. Белоусов
бизнес-аналитик, руководитель группы
freelancer