Эффективная реализация бизнес-процессов — мечта любого предприятия. Для ее достижения разработаны методы и инструментальные средства описания, проектирования, анализа и оценки бизнес-процессов, концепции и правила их реорганизации, а также информационные технологии поддержки. Бизнес-процесс представляет собой набор взаимосвязанных бизнес-процедур (функций или действий, формирующих результат, имеющий ценность для потребителя), в результате которых производится определенная группа продуктов и услуг. Все бизнес-процессы существуют для выполнения функций предприятия и должны соответствовать установленной на нем иерархии целей. Технология Workflow занимает в этом ряду далеко не последнее место — большинство аналитиков рассматривают ее как важнейшую составляющую современных корпоративных информационных систем, наиболее перспективную технологию управления бизнес-процессами. Данная статья отражает опыт авторов, накопленный в процессе разработки и выполнения проектов в области реорганизации бизнес-процессов и внедрения систем класса Workflow. В статье используются термины, определения и концепции, предложенные в работах G.Aussems, J.Champy, T.Davenport, M.Duitshof, M.Hammer, R.Huffmeijer, S.Joosten, E.Mulder и материалах Workflow Management Coalition [1-3]. Особенности конкретной программной реализации систем класса Workflow иллюстрируются примерами работы русскоязычной версии системы Staffware компании Staffware plc.
Международной организацией, координирующей разработку терминологии, стандартов и спецификаций на системы класса Workflow, является Workflow Management Coalition (WfMC). Так, например, одним из ведущих событий прошедшего года в области информационных технологий стала демонстрация на международном форуме Giga Information Group»s Business Process and Workflow совместной работы систем класса Workflow шести различных производителей на основе стандартных интерфейсов. Значение соответствующих стандартов специалисты сравнивают с тем значением, которое оказала в свое время спецификация языка SQL на развитие систем управления базами данных.
Созданная в середине 1993 года WfMC объединяет около 200 различных организаций по всему миру. В их числе компании, специализирующиеся на разработке аппаратных и программных систем, внедрении, консалтинге, а также учебные заведения. По оценкам WfMC, емкость рынка систем класса Workflow составляет сегодня 100 млн. долларов, а такие примеры инсталляций системы Staffware, как комплекс для пяти тыс. пользователей в Министерстве обороны Великобритании или шести тыс. служащих страховой компании CIGNA Healthcare (США), служат убедительной иллюстрацией реалистичности этих оценок. Внедрения систем класса Workflow в России пока не столь масштабны. Тем не менее количество представленных на рынке систем уже исчисляется десятками, а количество проданных лицензий — тысячами.
Буквальный перевод термина «workflow» как «поток работ» является безусловно корректным грамматически, но почти никак не раскрывает его содержание. Более информативно определение продуктов класса Workflow как программных систем, обеспечивающих полную или частичную координацию выполнения производственных операций (заданий, работ, функций), составляющих структурированные бизнес-процессы предприятия.
объект — информационный, материальный или финансовый объект, используемый в бизнес-процессе (например письмо, оборудование, счет);
событие — внешнее (не контролируемое в рамках процесса) действие, произошедшее с объектом (скажем получение письма, поломка оборудования, изменение ставки налога);
операция — элементарное действие, выполняемое в рамках рассматриваемого бизнес-процесса (допустим подготовка письма, замена оборудования, оплата счета);
исполнитель — должностное лицо, ответственное за выполнение одной или нескольких операций бизнес-процесса (к примеру менеджер, сотрудник архива, директор).
Взаимоотношения между базовыми понятиями технологии Workflow отображены на концептуальной информационной модели, представленной на рисунке 1.
Несмотря на то что модель подготовлена в соответствии с требованиями стандарта IDEF1X, ее общая интерпретация и анализ не требуют от специального изучения правил используемой методологии. В рамках этой модели ПРОЦЕСС состоит из ОПЕРАЦИЙ и других ПРОЦЕССОВ. ОПЕРАЦИЯ адресуется ИСПОЛНИТЕЛЯМ, которые, в свою очередь, отвечают за выполнение одной или нескольких ОПЕРАЦИЙ. ОБЪЕКТЫ участвуют в выполнении ОПЕРАЦИИ. СОБЫТИЯ могут влиять на выполнение ОПЕРАЦИЙ, например, изменяя результат операций или последовательность их выполнения. ОПЕРАЦИИ обрабатывают СОБЫТИЯ, являясь реакцией системы на происходящие СОБЫТИЯ. Жизненный цикл ОБЪЕКТА связан с внешними СОБЫТИЯМИ и ОПЕРАЦИЯМИ, выполняемыми в составе ПРОЦЕССА.
Приведенные понятия не исчерпывают множество терминов, определений и особенностей технологии Workflow, тем не менее рассмотренная концептуальная модель и/или ее различные модификации служат основой программной реализации любой системы класса Workflow. При этом каждая система обеспечивает решение трех следующих задач:
Соответственно этим задачам в составе системы можно выделить типовые компоненты (рисунок 2) и проанализировать связи между ними.
Рисунок 2.
Задачи и компоненты системы класса Workflow.
Инструментальные средства описания процесса предназначены для формирования формального описания процесса в виде упорядоченного множества операций, правил их выполнения, связанных с ними объектов, исполнителей и событий. Полученное описание или спецификация процесса используется для контроля и управления выполнением процесса на основе поступающих в систему данных. В качестве этих данных выступают информация, введенная пользователем, результаты выполнения отдельных операций, данные от прикладных систем, архивов и баз.
В свою очередь средства управления выполнением процесса предоставляют пользователю и/или прикладной системе информацию, необходимую для каждой операции, а выявленные на этапе выполнения несоответствия служат основанием для пересмотра спецификации процесса.
Представление бизнес-процесса как процесса Workflow
Все ли бизнес-процессы могут быть описаны как процессы Workflow? Какие бизнес-процессы целесообразно представлять в виде процессов Workflow?
Важнейшей особенностью технологии Workflow является поддержка управления процессами, содержащими как автоматизированные — выполняемые средствами информационных систем, так и неавтоматизированные — выполняемые вручную операции. Благодаря этой особенности любой бизнес-процесс предприятия может быть представлен в виде процесса Workflow, если, конечно, этот процесс:
Первые три ограничения являются ответом на вопрос «какие процессы можно описать», а последнее — «какие целесообразно».
Многие специалисты в области анализа бизнес-процессов используют для их описания методологию функционального моделирования IDEF0. Следуя сложившимся традициям, мы также применяем эту методологию для иллюстрации перечисленных ограничений.
Итак, процесс должен быть ВЫДЕЛЕН из всей массы выполняемых на предприятии работ, заданий и действий. Обобщенное представление такого процесса в методологии IDEF0 приводится на рисунке 3 — диаграммы верхнего уровня, определяющей взаимосвязи процесса с исполнителями и объектами, выступающими в качестве входов (исходные данные и материалы), управлений (ограничения на выполнение) и выходов (результаты выполнения). В методологии IDEF0 соответствующие связи называются IDEF-дугами. Количество присутствующих на диаграмме IDEF-дуг и их содержание могут быть любыми, но нельзя представить в виде Workflow процесс с исходными данными, неопределенными по составу, непредсказуемым результатом, неопределенными или неуправляемыми правилами выполнения и отсутствием исполнителей. Строго говоря, соответствующий процесс вряд ли можно считать бизнес-процессом, удовлетворяющим приведенному в начале статьи определению.
Рисунок 3.
Обобщенное представление бизнес-процесса в методологии IDEF0.
Кроме того, процесс должен иметь внутреннюю СТРУКТУРУ — не быть вырожденным, состоящим из одной единственной операции.
В методологии функционального моделирования IDEF0 структура бизнес-процесса может быть раскрыта на диаграмме декомпозиции (рисунок 4), которая сохраняет входы, выходы, управления и исполнителей, указанных на родительской диаграмме, а также содержит составляющие процесс операции, подпроцессы и связи между ними. Функциональная модель бизнес-процесса представляет собой набор иерархических диаграмм, аналогичных представленной на рисунке 4, с метками для каждой IDEF-дуги, раскрывающими ее содержание.
Рисунок 4.
Пример декомпозиции бизнес-процесса в методологии IDEF0.
Уровень вложенности подпроцессов не ограничен, что позволяет описывать функциональную модель процесса любой сложности. Средства описания процесса Workflow реализуют соответствующую возможность, как правило, путем запуска дочерних процессов в указанных операциях родительского процесса и согласования получаемых результатов с последующими операциями.
Формирование функциональной модели бизнес-процессов является первым шагом подготовки к внедрению системы класса Workflow. Хотелось бы обратить внимание на следующие немаловажные обстоятельства.
В качестве элементарной операции можно использовать как рутинное, формальное действие, например «зарегистрировать учетные данные клиента», так и творческую, нетривиальную задачу, скажем «разработать технологию подъема Титаника». Следует лишь определить IDEF-дуги, связывающие эту операцию с другими в рамках рассматриваемого процесса.
При всей важности функционального моделирования тем не менее представленных в функциональной модели данных еще недостаточно для полного определения процесса. Третьим требованием представления бизнес-процесса в виде процесса Workflow является НАЛИЧИЕ ПРАВИЛ выполнения процесса, которые можно сформулировать и формально описать. В первую очередь соответствующие правила касаются последовательности выполнения операций, условий и предусмотренной реакции на внешние события.
Для того чтобы пояснить принципы формирования правил, рассмотрим категории операций, выполняемых в рамках бизнес-процесса (рисунок 5).
Рисунок 5.
Категории операций, выполняемых в рамках бизнес-процесса, и примеры.
Будем рассматривать операции, выполняемые группой исполнителей. В качестве направлений систематизации выберем согласованность времени выполнения (синхронно, асинхронно) и области действия (локальная или распределенная). Для выполнения синхронных локальных операций требуется наличие всех исполнителей в одно время и в одном месте. Синхронные распределенные операции выполняются в одно и то же время исполнителями, которые могут находиться в разных местах. Асинхронные локальные операции выполняются членами группы в одном, определенном месте, но в различное время. И, наконец, асинхронные распределенные операции выполняются членами группы исполнителей в различных местах и в различное время.
Объектом автоматизации технологии Groupware являются три первых категории операций. В рамках технологии Workflow рассматриваются операции, относящиеся к последней категории, — распределенные и асинхронные. Причем эти операции могут выполняться последовательно или параллельно, иметь сколь угодно сложную логику, согласовываться по времени, данным и исполнителям.
Четвертым и последним требованием представления бизнес-процесса в виде процесса класса Workflow является ПЕРИОДИЧНОСТЬ ВЫПОЛНЕНИЯ. В отличие от предыдущих требований, это требование носит чисто экономический характер.
Инструментальные средства описания процесса
С точки зрения системы, каждая операция, входящая в состав процесса, содержит задание, выполнение которого предполагает ввод и/или обработку информации. Типовыми параметрами описания операции являются следующие:
Последовательность выполнения операций и условия их перехода от одной к другой составляют алгоритм выполнения процесса. Помимо уже рассмотренных операций в описании алгоритма, как правило, используются:
Использование инструментальных средств описания процессов в большинстве современных систем класса Workflow не требует от разработчика каких-либо знаний в области программирования или систем управления базами данных. Например, в системе Staffware средством такого класса является графический построитель процедур для Windows, работа которого основана на технологии пиктограмм и режиме drag-and-drop.
При выполнении процесса Workflow информация передается от пользователя к пользователю в виде некоторого упорядоченного множества данных. Каждая операция использует подмножество этих данных, состав которого, а также способ представления данных задаются соответствующей экранной формой. Создание форм является прерогативой разработчика процессов, а инструментальные средства для разработки форм являются важным компонентом системы Workflow. Главным требованием к экранным формам, циркулирующим в системе, является их «интеллектуальность» — возможность динамически изменять состав, содержание и формат представления данных.
Большинство систем поддерживают самые разнообразные типы данных. Очень важными являются данные типа «файл», благодаря которым обеспечивается возможность ассоциировать с формой файлы, находящиеся вне системы. Разработчик указывает операции, на которых эти файлы должны порождаться, и регламентирует возможность внесения в них изменений.
Значения данных представляются в экранной форме в виде полей. При этом различаются:
демонстрационные поля — поля, содержащие значения, для которых не допускается редактирование;
обязательные поля — поля, которые необходимо заполнить в процессе выполнения задания;
необязательные поля — поля, значения которых могут быть введены пользователем, однако это не является необходимым условием выполнения задания;
вычисляемые поля — поля, значения которых вычисляются в соответствии с заданными правилами;
невидимые поля — вычисляемые, но неотображаемые на экране.
Построение форм представления данных является составной частью описания операций, составляющих процесс Workflow, и включает:
Кроме того, для каждого поля могут быть заданы:
Использование таблиц позволяет организовать согласованную работу с логически связанными полями данных, например такими, как название компании и ее почтовый адрес.
В большинстве современных систем класса Workflow присутствуют высокоуровневые инструментальные средства создания и редактирования экранных форм. Например, в Staffware таким средством является графический построитель форм для среды Windows.
Управление выполнением процесса
Любой конкретный случай выполнения процесса называется экземпляром или вариантом. Выполнение любого экземпляра состоит в рассылке пользователям заданий в виде экранных форм и управлении процессом их заполнения в соответствии с предусмотренным алгоритмом. При этом система класса Workflow обеспечивает:
Работа пользователя с любой формой состоит из следующих действий:
Часто при заполнении экранных форм поддерживается технология электронной подписи.
В процессе эксплуатации система Workflow накапливает задания, ожидающие обработки, и формирует очереди заданий различных типов как для каждого пользователя, так и для группы. Автоматически производится периодическое обновление очередей и уведомление пользователя о наличии в очереди новых, еще непросмотренных заданий, заданий с высоким приоритетом или заданий с установленным предельным сроком выполнения. Например, в системе Staffware для работы с очередью заданий имеется специальное окно.
Набор операций для работы с очередью заданий содержит следующие операции:
После выпуска или пересылки задания оно автоматически удаляется из очереди.
В управлении и выполнении процесса Workflow участвуют следующие классы пользователей:
администратор системы — поддержка и сохранение целостности всех данных, не относящихся к процессам, например данных о пользователях;
разработчик процесса — разработка, тестирование и поддержка конкретного процесса;
владелец процесса — редактирование конкретного процесса;
менеджер — контроль исполнения экземпляров процесса посредством регистрационных отчетов и сервисных программ;
пользователь — доступ к системе через очередь заданий, функция запуска экземпляра конкретного процесса и справочная подсистема.
Каждый пользователь имеет уникальный код, пароль и относится к некоторой группе пользователей. Средства управления доступом системы Workflow ограничивают доступ к операциям, функции запуска экземпляров процесса и возможностям администрирования для определенных пользователей или групп пользователей. Кроме того, большинство систем предоставляют возможность управления доступом на уровне ролей, в соответствии с которой права доступа могут назначаться не физическим лицам или подразделениям, а должностям (ролям).
Для контроля и управления текущим состоянием выполнения экземпляров процесса в системах Workflow предусмотрены следующие функции:
Регистрационный журнал представляет собой внутренний отчет системы, в котором для каждого экземпляра процесса фиксируются дата и время каждой транзакции, выполненное действие и исполнитель. С помощью регистрационного журнала в любой момент времени можно получить информацию о том, что происходило и происходит при выполнении конкретного экземпляра процесса.
Отчет о состоянии — это внутренний отчет системы, в котором отражается текущее состояние каждой операции каждого процесса. Различается четыре типа состояний: выпущена, не выпущена, отозвана или не отправлена. Кроме того, для любой операции можно получить данные о текущих значениях полей. Функция пересмотра данных отличается от отчета о состоянии лишь тем, что позволяет модифицировать значения полей и таким образом управлять выполнением экземпляра процесса.
Административные отчеты используются для сбора и обобщения информации, относящейся к нескольким (всем, текущим или завершенным) экземплярам данного процесса. Типичными примерами административных отчетов являются отчеты об объеме продаж в регионе, о суммарном объеме всех принятых заказов или о количестве просроченных договоров. Структура и алгоритм административных отчетов определяются разработчиком процесса.
Особенности программной реализации
Естественно, что каждая конкретная программная реализация системы класса Workflow имеет множество своих особенностей. Приведем, например, краткое описание некоторых особенностей программной реализации для системы Staffware.
Как и большинство систем класса Workflow система Staffware имеет архитектуру клиент-сервер. Сервер Staffware работает в среде Unix или NT, а для рабочего места клиента может использоваться алфавитно-цифровой терминал Unix, ПК в среде Windows или Macintosh. В качестве основы для управления данными система Staffware предоставляет несколько вариантов: собственную систему управления, базирующуюся на файловой системе сервера, СУБД Oracle или Informix. Для предприятий, имеющих сложную и территориально-распределенную структуру, важной является поддержка системой Staffware многосерверной конфигурации, в которой часть серверов может работать под Unix, другая — под NT, третья — под любой из этих операционных систем плюс СУБД Oracle, а четвертая — аналогично предыдущей, но с СУБД Informix.
Система Staffware является открытой — специальные средства обеспечивают запуск внешних программ на сервере и клиенте, двусторонний обмен данными между Staffware и процессом на сервере, а также динамический обмен данных (Dynamic Data Exchange — DDE) с приложениями, работающими под Windows. Кроме этого, имеются библиотеки функций уровня прикладного программирования (API) под Unix и Windows, позволяющие разработчикам прикладных программ получить доступ к системным функциям Staffware.
Имеется также специальная версия, ориентированная на работу в сети Internet, — Staffware W4 (Workflow on Word Wide Web), обеспечивающая Web-клиенту системы доступ через глобальную сеть к формам, очереди заданий, административным отчетам и регистрационным журналам. При этом в качестве клиентского программного обеспечения может использоваться любой стандартный Web-браузер.
Среди множества дополнительных функций отметим следующие:
Место технологии Workflow в организации бизнеса
Для определения места технологии Workflow в организации бизнеса воспользуемся подходом, предложенным С. Джостеном (S. Joosten) и его коллегами [2], и рассмотрим динамику изменения основных компонентов бизнес-системы (рисунок 8).
Рисунок 8.
Динамика изменения основных компонентов бизнес-системы.
Наиболее устойчивым компонентом является миссия предприятия, определяющая назначение компании, ее значимость для общества и направление деятельности. С точки зрения организации бизнеса, изменение миссии эквивалентно построению новой компании.
Практически столь же устойчивой является иерархия целей предприятия и стратегия его развития. Изменения в стратегии являются, как правило, следствием таких внешних событий, как технологическая революция, радикальное изменение условий рынка или законодательства.
Критические факторы успеха и состав тактических задач по реализации сформированных планов периодически пересматриваются на основе анализа тенденций развития рынка и статистики результатов деятельности.
Определение результатов деятельности и подсчет значений показателей эффективности проводится столь часто, сколь это возможно для конкретного сектора рынка, групп изделий, услуг, клиентов, поставщиков и т. д. Однако и в этом случае достоверные данные являются результатом накопленной статистики, хотя и за менее продолжительный период.
Все последующие компоненты входят в состав корпоративной информационной системы, в задачу которой входит информационная поддержка выполнения бизнес-процессов и принятия управленческих решений. При этом динамику развития этой системы в наибольшей степени определяют собственно бизнес-процессы.
С точки зрения организации бизнес-системы основной задачей технологии Workflow является отделение правил выполнения бизнес-процессов от прикладных систем и систем управления базами данных, что обеспечивает принципиально большую гибкость и адаптируемость информационной системы. Иными словами, технология Workflow предоставляет возможность оперативной модификации правил выполнения бизнес-процессов без перестройки прикладного программного обеспечения и/или изменения структуры корпоративной базы данных.
Другим важным направлением использования технологии Workflow служит интеграция различных приложений и данных вокруг бизнес-процесса. В этом отношении Workflow можно рассматривать как определенный шаг в развитии архитектуры открытых систем. Стандарты, разработанные WfMC, подтверждают эффективность и результативность усилий, нацеленных на развитие этого направления.
Стратегия внедрения и использования
Внедрение системы класса Workflow в практику работы предприятия всегда представляет собой проект, реализация которого не может быть возложена лишь на отдел информационных технологий. Более того, объем работ этого отдела в рамках соответствующего проекта редко превышает 25%.
Какова иерархия целей такого проекта? Как эффективно организовать работы по сопровождению и развитию системы?
Эти вопросы стали предметом специального исследования, названного WA-12 [2] и, выполненного рядом компаний, в числе которых Data General, Deloitte&Touche, Staffware и др. По данным исследования WA-12, типовыми целями проекта внедрения системы класса Workflow являются:
Необходимо отметить, что проект анализа деятельности и реорганизации бизнес-процессов предприятия и проект внедрения системы класса Workflow представляют собой далеко не одно и то же.
Первый из них предполагает детальный и всесторонний анализ четырех верхних уровней пирамиды, представленной на рисунке 8. Второй обеспечивает решение задачи следующего, пятого уровня. Тем не менее оба проекта рассматривают бизнес-процессы предприятия и предполагают их выявление и описание.
Предположим, однако, что соответствующие работы выполнены, система инсталлирована, бизнес-процессы описаны, организационные вопросы решены, проведено тестирование и осуществлен переход к промышленной эксплуатации системы. Начиная с этого момента главной задачей является поддержание системы в актуальном состоянии, отражающем особенности текущего состояния рынка, стратегию и тактику деятельности предприятия.
Технология выполнения соответствующих работ разработана весьма подробно. Ее квинтэссенцией является цикл управления эксплуатацией и развитием системы класса Workflow, представленный на рисунке 9.
Рисунок 9.
Цикл управления эксплуатацией и развитием системы класса Workflow.
Выполнение множества процессов Workflow (блок «Выполнение») сопровождается сбором статистики, представленной в отчетах различных типов. Эти отчеты служат основой для выявления типовых маршрутов выполнения процессов, распределения затрат, причин нарушения сроков выполнения отдельных операций (блок «Разбор»). Полученные данные сравниваются с требованиями, предъявляемыми к системе, проводится оценка эффективности эксплуатации (блоки «Сравнение» и «Требования»). На основании результатов сравнения проводится перенастройка описанных процессов, уточнение интерфейсов с прикладными программами и базами данных, уточнение состава отчетов (блок «Настройка»). Отредактированные версии процессов поступают в блок «Выполнение», а соответствующие им изменения в правилах организации бизнеса (блок «Изменения») влияют на требования, предъявляемые к системе (блок «Требования»).
Вместо заключения
Основное количество внедрений систем класса Workflow в России сосредоточено сегодня только вокруг задачи управления документооборотом. Нисколько не отрицая важность и актуальность этой задачи, авторы обращают внимание на то, что возможности технологии Workflow существенно шире: она позволяет сделать бизнес более эффективным и, соответственно, эффект от внедрения может быть существенно более значимым.
Эффективная реализация бизнес-процессов
– мечта любого предприятия. Для ее
достижения разработаны методы и
инструментальные средства описания,
проектирования, анализа и оценки
бизнес-процессов, концепции и правила
их реорганизации, а также информационные
технологии поддержки. Бизнес-процесс
представляет собой набор взаимосвязанных
бизнес-процедур (функций или действий,
формирующих результат, имеющий ценность
для потребителя), в результате которых
производится определенная группа
продуктов и услуг. Все бизнес-процессы
существуют для выполнения функций
предприятия и должны соответствовать
установленной на нем иерархии целей.
Технология Workflow занимает в этом ряду
далеко не последнее место — большинство
аналитиков рассматривают ее как важнейшую
составляющую современных корпоративных
информационных систем, наиболее
перспективную технологию управления
бизнес-процессами. Данная статья отражает
опыт авторов, накопленный в процессе
разработки и выполнения проектов в
области реорганизации бизнес-процессов
и внедрения систем класса Workflow. В статье
используются термины, определения и
концепции, предложенные в работах
G.Aussems, J.Champy, T.Davenport, M.Duitshof, M.Hammer, R.Huffmeijer,
S.Joosten, E.Mulder и материалах Workflow Management
Coalition. Особенности конкретной программной
реализации систем класса Workflow
иллюстрируются примерами работы
русскоязычной версии системы Staffware
компании Staffware plc.
Международной организацией, координирующей
разработку терминологии, стандартов и
спецификаций на системы класса Workflow,
является Workflow Management Coalition (WfMC). Так,
например, одним из ведущих событий
прошедшего года в области информационных
технологий стала демонстрация на
международном форуме Giga Information Group’s
Business Process and Workflow совместной работы
систем класса Workflow шести различных
производителей на основе стандартных
интерфейсов. Значение соответствующих
стандартов специалисты сравнивают с
тем значением, которое оказала в свое
время спецификация языка SQL на развитие
систем управления базами данных.
Созданная в середине 1993 года WfMC объединяет
около 200 различных организаций по всему
миру. В их числе компании, специализирующиеся
на разработке аппаратных и программных
систем, внедрении, консалтинге, а также
учебные заведения. По оценкам WfMC, емкость
рынка систем класса Workflow составляет
сегодня 100 млн. долларов, а такие примеры
инсталляций системы Staffware, как комплекс
для пяти тыс. пользователей в Министерстве
обороны Великобритании или шести тыс.
служащих страховой компании CIGNA Healthcare
(США), служат убедительной иллюстрацией
реалистичности этих оценок. Внедрения
систем класса Workflow в России пока не
столь масштабны. Тем не менее, количество
представленных на рынке систем уже
исчисляется десятками, а количество
проданных лицензий — тысячами.
Базовые концепции. Буквальный
перевод термина «workflow» как «поток работ»
является, безусловно, корректным
грамматически, но почти никак не
раскрывает его содержание. Более
информативно определение продуктов
класса Workflow как программных систем,
обеспечивающих полную или частичную
координацию выполнения производственных
операций (заданий, работ, функций),
составляющих структурированные
бизнес-процессы предприятия.
В основе технологии Workflow лежат следующие
понятия:
объект — информационный, материальный
или финансовый объект, используемый в
бизнес-процессе (например, письмо,
оборудование, счет);
событие — внешнее (не контролируемое в
рамках процесса) действие, произошедшее
с объектом (скажем получение письма,
поломка оборудования, изменение ставки
налога);
операция — элементарное действие,
выполняемое в рамках рассматриваемого
бизнес-процесса (допустим подготовка
письма, замена оборудования, оплата
счета);
исполнитель — должностное лицо,
ответственное за выполнение одной или
нескольких операций бизнес-процесса
(к примеру, менеджер, сотрудник архива,
директор).
Взаимоотношения между базовыми понятиями
технологии Workflow отображены на
концептуальной информационной модели,
представленной на рис. 8.9.
Концептуальная информационная модель
технологии Workflow. Несмотря на то, что
модель подготовлена в соответствии с
требованиями стандарта IDEF1X, ее общая
Рисунок 8.9 – Концептуальная информационная
модель
интерпретация и анализ не требуют от
специального изучения правил используемой
методологии. В рамках этой модели ПРОЦЕСС
состоит из ОПЕРАЦИЙ и других ПРОЦЕССОВ.
ОПЕРАЦИЯ адресуется ИСПОЛНИТЕЛЯМ,
которые, в свою очередь, отвечают за
выполнение одной или нескольких ОПЕРАЦИЙ.
ОБЪЕКТЫ участвуют в выполнении ОПЕРАЦИИ.
СОБЫТИЯ могут влиять на выполнение
ОПЕРАЦИЙ, например, изменяя результат
операций или последовательность их
выполнения. ОПЕРАЦИИ обрабатывают
СОБЫТИЯ, являясь реакцией системы на
происходящие СОБЫТИЯ. Жизненный цикл
ОБЪЕКТА связан с внешними СОБЫТИЯМИ и
ОПЕРАЦИЯМИ, выполняемыми в составе
ПРОЦЕССА.
Приведенные понятия не исчерпывают
множество терминов, определений и
особенностей технологии Workflow, тем не
менее, рассмотренная концептуальная
модель и/или ее различные модификации
служат основой программной реализации
любой системы класса Workflow. При этом
каждая система обеспечивает решение
трех следующих задач:
-
разработка описания бизнес-процесса;
-
управление выполнением бизнес-процесса;
-
интеграция используемых в процессе
приложений.
Соответственно этим задачам в составе
системы можно выделить типовые компоненты
(рис. 8.10) и проанализировать связи между
ними.
Рисунок 8.10 – Типовые компоненты системы
WorkFlow
Задачи и компоненты системы класса
Workflow. Инструментальные средства
описания процесса предназначены для
формирования формального описания
процесса в виде упорядоченного множества
операций, правил их выполнения, связанных
с ними объектов, исполнителей и событий.
Полученное описание или спецификация
процесса используется для контроля и
управления выполнением процесса на
основе поступающих в систему данных. В
качестве этих данных выступают информация,
введенная пользователем, результаты
выполнения отдельных операций, данные
от прикладных систем, архивов и баз.
В свою очередь средства управления
выполнением процесса предоставляют
пользователю и/или прикладной системе
информацию, необходимую для каждой
операции, а выявленные на этапе выполнения
несоответствия служат основанием для
пересмотра спецификации процесса.
Представление бизнес-процесса как
процесса Workflow.
Все ли бизнес-процессы могут быть описаны
как процессы Workflow? Какие бизнес-процессы
целесообразно представлять в виде
процессов Workflow?
Важнейшей особенностью технологии
Workflow является поддержка управления
процессами, содержащими как
автоматизированные — выполняемые
средствами информационных систем, так
и неавтоматизированные — выполняемые
вручную операции. Благодаря этой
особенности любой бизнес-процесс
предприятия может быть представлен в
виде процесса Workflow, если, конечно, этот
процесс:
— выделен;
— структурирован;
— выполняется по правилам, которые можно
сформулировать;
— периодически повторяется.
Первые три ограничения являются ответом
на вопрос: «какие процессы можно описать»,
а последнее – «какие целесообразно».
Многие специалисты в области анализа
бизнес-процессов используют для их
описания методологию функционального
моделирования IDEF0. Следуя сложившимся
традициям, мы также применяем эту
методологию для иллюстрации перечисленных
ограничений.
Итак, процесс должен быть ВЫДЕЛЕН из
всей массы выполняемых на предприятии
работ, заданий и действий. Обобщенное
представление такого процесса в
методологии IDEF0 приводится на рис. 8.11 —
диаграммы верхнего уровня, определяющей
взаимосвязи процесса с исполнителями
и объектами, выступающими в качестве
входов (исходные данные и материалы),
управлений (ограничения на выполнение)
и выходов (результаты выполнения). В
методологии IDEF0 соответствующие связи
называются IDEF-дугами. Количество
присутствующих на диаграмме IDEF-дуг и
их содержание могут быть любыми, но
нельзя представить в виде Workflow процесс
с исходными данными, неопределенными
по составу, непредсказуемым результатом,
неопределенными или неуправляемыми
правилами выполнения и отсутствием
исполнителей. Строго говоря, соответствующий
процесс вряд ли можно считать бизнес
процессом, удовлетворяющим приведенному
в начале статьи определению.
Кроме того, процесс должен иметь
внутреннюю СТРУКТУРУ — не быть
вырожденным, состоящим из одной
единственной операции.
В методологии функционального
моделирования IDEF0 структура бизнес-процесса
может быть раскрыта на диаграмме
декомпозиции (рис. 8.12), которая сохраняет
входы, выходы, управления и исполнителей,
указанных на родительской диаграмме,
а также содержит составляющие
Рисунок 8.11 – Обобщенное представление
процесса в методологии IDEF0
процесс операции, подпроцессы и связи
между ними. Функциональная модель
бизнес-процесса представляет собой
набор иерархических диаграмм, аналогичных
представленной на рис. 8.12, с метками для
каждой IDEF-дуги, раскрывающими ее
содержание.
Пример декомпозиции бизнес-процесса
в методологии IDEF0.
Уровень вложенности подпроцессов не
ограничен, что позволяет описывать
функциональную модель процесса любой
сложности. Средства описания
процесса Workflow реализуют соответствующую
возможность, как правило, путем запуска
дочерних процессов в указанных операциях
родительского процесса и согласования
получаемых результатов с последующими
операциями.
Формирование функциональной модели
бизнес-процессов является первым шагом
подготовки к внедрению системы класса
Workflow. Хотелось бы обратить внимание на
следующие немаловажные обстоятельства.
Рисунок 8.12 – Диаграмма декомпозиции
Внедрение системы класса Workflow базируется
не на маршрутизации прохождения
документов и не на автоматизации группы
операций или вида действий, а на описании
бизнес-процесса, ради эффективного
выполнения которого, собственно, и
осуществляется маршрутизация документов
и/или автоматизация операций.
Технология Workflow не накладывает каких-либо
специальных ограничений на уровень
детализации бизнес-процесса и/или
степень автоматизации выполняемых
операции.
В качестве элементарной операции можно
использовать как рутинное, формальное
действие, например «зарегистрировать
учетные данные клиента», так и творческую,
нетривиальную задачу, скажем «разработать
технологию подъема Титаника». Следует
лишь определить IDEF-дуги, связывающие
эту операцию с другими в рамках
рассматриваемого процесса.
При всей важности функционального
моделирования, тем не менее, представленных
в функциональной модели данных еще
недостаточно для полного определения
процесса. Третьим требованием представления
бизнес-процесса в виде процесса Workflow
является НАЛИЧИЕ ПРАВИЛ выполнения
процесса, которые можно сформулировать
и формально описать. В первую очередь
соответствующие правила касаются
последовательности выполнения операций,
условий и предусмотренной реакции на
внешние события.
Для того чтобы пояснить принципы
формирования правил, рассмотрим категории
операций, выполняемых в рамках
бизнес-процесса (рис. 8.13).
Категории операций, выполняемых в рамках
бизнес-процесса, и примеры.
Будем рассматривать операции, выполняемые
группой исполнителей. В качестве
направлений систематизации выберем
согласованность времени выполнения
(синхронно, асинхронно) и области действия
(локальная или распределенная). Для
выполнения синхронных локальных операций
требуется наличие всех исполнителей в
одно время и в одном месте. Синхронные
распределенные операции выполняются
в одно и то же время исполнителями,
Рисунок 8.13 – Категории операций,
выполняемых в рамках бизнес-процесса
которые могут находиться в разных
местах. Асинхронные локальные операции
выполняются членами группы в одном,
определенном месте, но в различное
время. И, наконец, асинхронные распределенные
операции выполняются членами группы
исполнителей в различных местах и в
различное время.
Объектом автоматизации технологии
Groupware являются три первых категории
операций. В рамках технологии Workflow
рассматриваются операции, относящиеся
к последней категории, — распределенные
и асинхронные. Причем эти операции могут
выполняться последовательно или
параллельно, иметь сколь угодно сложную
логику, согласовываться по времени,
данным и исполнителям.
Четвертым и последним требованием
представления бизнес-процесса в виде
процесса класса Workflow является ПЕРИОДИЧНОСТЬ
ВЫПОЛНЕНИЯ. В отличие от предыдущих
требований, это требование носит чисто
экономический характер.
Инструментальные средства описания
процесса. С точки зрения системы,
каждая операция, входящая в состав
процесса, содержит задание, выполнение
которого предполагает ввод и/или
обработку информации. Типовыми параметрами
описания операции являются следующие:
— адресат — пользователь или группа
пользователей, получающих задание, при
этом указываются права на пересылку
задания другому пользователю и права
на копирование данных, относящихся к
заданию;
— экранная форма, содержащая представление
данных и функций, используемых
пользователем при выполнении задания;
— предельный срок выполнения задания,
определяющий, до какого времени
соответствующая операция должна быть
выполнена;
— действия системы при инициализации и
завершении операции.
Последовательность выполнения операций
и условия их перехода от одной к другой
составляют алгоритм выполнения процесса.
Помимо уже рассмотренных операций в
описании алгоритма, как правило,
используются:
— логические условия;
— внешние по отношению к процессу события;
— средства создания параллельных ветвей;
— точки встречи, позволяющие согласовать
результаты параллельно выполняемых
операций;
— автоматические операции — операции,
выполняющиеся без участия пользователя
и запускающие на сервере внешнюю
процедуру обработки циркулирующих в
процессе данных;
— сценарии — специальные экранные формы,
содержащие вызов функций, операторов
системы и внешних программ, используемых
пользователем при выполнении различных
операций.
Использование инструментальных средств
описания процессов в большинстве
современных систем класса Workflow не
требует от разработчика каких-либо
знаний в области программирования или
систем управления базами данных.
Например, в системе Staffware средством
такого класса является графический
построитель процедур для Windows, работа
которого основана на технологии
пиктограмм и режиме drag-and-drop.
При выполнении процесса Workflow информация
передается от пользователя к пользователю
в виде некоторого упорядоченного
множества данных. Каждая операция
использует подмножество этих данных,
состав которого, а также способ
представления данных задаются
соответствующей экранной формой.
Создание форм является прерогативой
разработчика процессов, а инструментальные
средства для разработки форм являются
важным компонентом системы Workflow. Главным
требованием к экранным формам,
циркулирующим в системе, является их
«интеллектуальность» — возможность
динамически изменять состав, содержание
и формат представления данных.
Большинство систем поддерживают самые
разнообразные типы данных. Очень важными
являются данные типа «файл», благодаря
которым обеспечивается возможность
ассоциировать с формой файлы, находящиеся
вне системы. Разработчик указывает
операции, на которых эти файлы должны
порождаться, и регламентирует возможность
внесения в них изменений.
Значения данных представляются в
экранной форме в виде полей. При этом
различаются:
— демонстрационные поля — поля, содержащие
значения, для которых не допускается
редактирование;
— обязательные поля — поля, которые
необходимо заполнить в процессе
выполнения задания;
— необязательные поля — поля, значения
которых могут быть введены пользователем,
однако это не является необходимым
условием выполнения задания;
— вычисляемые поля — поля, значения
которых вычисляются в соответствии с
заданными правилами;
— невидимые поля — вычисляемые, но
неотображаемые на экране.
Построение форм представления данных
является составной частью описания
операций, составляющих процесс Workflow, и
включает:
— задание и форматирование текста,
образующего форму;
— определение требуемого подмножества
данных;
— указание способа их представления в
форме;
— описание условий и обстоятельств,
определяющих содержание формы.
Кроме того, для каждого поля могут быть
заданы:
— справка-пояснение того, как это поле
заполнить; справочная информация будет
выдаваться на экран по требованию
пользователя;
— диапазон или список допустимых значений;
— одна или несколько таблиц, определяющих
взаимосвязи между значениями полей
формы.
Использование таблиц позволяет
организовать согласованную работу с
логически связанными полями данных,
например такими, как название компании
и ее почтовый адрес.
В большинстве современных систем класса
Workflow присутствуют высокоуровневые
инструментальные средства создания и
редактирования экранных форм. Например,
в Staffware таким средством является
графический построитель форм для среды
Windows.
Управление выполнением процесса.
Любой конкретный случай выполнения
процесса называется экземпляром или
вариантом. Выполнение любого экземпляра
состоит в рассылке пользователям заданий
в виде экранных форм и управлении
процессом их заполнения в соответствии
с предусмотренным алгоритмом. При этом
система класса Workflow обеспечивает:
— одновременное выполнение множества
экземпляров каждого процесса;
— передачу заданий между операциями
процесса посредством системы электронной
почты;
— обмен произвольными сообщениями между
пользователями;
— доступ к функциям системы и внешним
программам, предусмотренным для
пользователя разработчиком процесса;
— взаимодействие путем обмена данными
с внешними программами на сервере и
клиенте.
Работа пользователя с любой формой
состоит из следующих действий:
— просмотр содержимого;
— заполнение и/или редактирование полей;
— печать формы;
— выпуск формы для последующей обработки.
Часто при заполнении экранных форм
поддерживается технология электронной
подписи.
В процессе эксплуатации система Workflow
накапливает задания, ожидающие обработки,
и формирует очереди заданий различных
типов как для каждого пользователя, так
и для группы. Автоматически производится
периодическое обновление очередей и
уведомление пользователя о наличии в
очереди новых, еще непросмотренных
заданий, заданий с высоким приоритетом
или заданий с установленным предельным
сроком выполнения. Например, в системе
Staffware для работы с очередью заданий
имеется специальное окно.
Набор операций для работы с очередью
заданий содержит следующие операции:
— выбор задания;
— переход к заполнению экранной формы
выбранного задания;
— выпуск выбранного задания – информирование
системы об его выполнении;
— пересылка выбранного задания другому
пользователю в случае невозможности
его выполнения;
— установка критериев сортировки заданий
в очереди;
— ограничение списка отображаемых
заданий посредством критерия-фильтра;
— управление периодом обновления очереди.
После выпуска или пересылки задания
оно автоматически удаляется из очереди.
В управлении и выполнении процесса
Workflow участвуют следующие классы
пользователей:
— администратор системы — поддержка и
сохранение целостности всех данных, не
относящихся к процессам, например данных
о пользователях;
— разработчик процесса — разработка,
тестирование и поддержка конкретного
процесса;
— владелец процесса — редактирование
конкретного процесса;
— менеджер — контроль исполнения
экземпляров процесса посредством
регистрационных отчетов и сервисных
программ;
— пользователь — доступ к системе через
очередь заданий, функция запуска
экземпляра конкретного процесса и
справочная подсистема.
Каждый пользователь имеет уникальный
код, пароль и относится к некоторой
группе пользователей. Средства управления
доступом системы Workflow ограничивают
доступ к операциям, функции запуска
экземпляров процесса и возможностям
администрирования для определенных
пользователей или групп пользователей.
Кроме того, большинство систем
предоставляют возможность управления
доступом на уровне ролей, в соответствии
с которой права доступа могут назначаться
не физическим лицам или подразделениям,
а должностям (ролям).
Для контроля и управления текущим
состоянием выполнения экземпляров
процесса в системах Workflow предусмотрены
следующие функции:
— регистрационные журналы;
— отчеты о состоянии;
— пересмотр данных;
— административные отчеты.
Регистрационный журнал представляет
собой внутренний отчет системы, в котором
для каждого экземпляра процесса
фиксируются дата и время каждой
транзакции, выполненное действие и
исполнитель. С помощью регистрационного
журнала в любой момент времени можно
получить информацию о том, что происходило
и происходит при выполнении конкретного
экземпляра процесса.
Отчет о состоянии — это внутренний отчет
системы, в котором отражается текущее
состояние каждой операции каждого
процесса. Различается четыре типа
состояний: выпущена, не выпущена, отозвана
или не отправлена. Кроме того, для любой
операции можно получить данные о текущих
значениях полей. Функция пересмотра
данных отличается от отчета о состоянии
лишь тем, что позволяет модифицировать
значения полей и таким образом управлять
выполнением экземпляра процесса.
Административные отчеты используются
для сбора и обобщения информации,
относящейся к нескольким (всем, текущим
или завершенным) экземплярам данного
процесса. Типичными примерами
административных отчетов являются
отчеты об объеме продаж в регионе, о
суммарном объеме всех принятых заказов
или о количестве просроченных договоров.
Структура и алгоритм административных
отчетов определяются разработчиком
процесса.
Особенности программной реализации.
Естественно, что каждая конкретная
программная реализация системы класса
Workflow имеет множество своих особенностей.
Приведем, например, краткое описание
некоторых особенностей программной
реализации для системы Staffware.
Как и большинство систем класса Workflow
система Staffware имеет архитектуру
клиент-сервер. Сервер Staffware работает в
среде Unix или NT, а для рабочего места
клиента может использоваться
алфавитно-цифровой терминал Unix, ПК в
среде Windows или Macintosh. В качестве основы
для управления данными система Staffware
предоставляет несколько вариантов:
собственную систему управления,
базирующуюся на файловой системе
сервера, СУБД Oracle или Informix. Для предприятий,
имеющих сложную и территориально-распределенную
структуру, важной является поддержка
системой Staffware многосерверной конфигурации,
в которой часть серверов может работать
под Unix, другая — под NT, третья — под любой
из этих операционных систем плюс СУБД
Oracle, а четвертая — аналогично предыдущей,
но с СУБД Informix.
Система Staffware является открытой —
специальные средства обеспечивают
запуск внешних программ на сервере и
клиенте, двусторонний обмен данными
между Staffware и процессом на сервере, а
также динамический обмен данных (Dynamic
Data Exchange — DDE) с приложениями, работающими
под Windows. Кроме этого, имеются библиотеки
функций уровня прикладного программирования
(API) под Unix и Windows, позволяющие разработчикам
прикладных программ получить доступ к
системным функциям Staffware.
Имеется также специальная версия,
ориентированная на работу в сети
Internet, — Staffware W4 (Workflow on Word Wide Web), обеспечивающая
Web-клиенту системы доступ через глобальную
сеть к формам, очереди заданий,
административным отчетам и регистрационным
журналам. При этом в качестве клиентского
программного обеспечения может
использоваться любой стандартный
Web-браузер.
Среди множества дополнительных функций
отметим следующие:
— выход на любую внешнюю систему
электронной почты, в том числе по
протоколам X400 и SMTP;
— многопользовательский режим отладки
и тестирования новых процессов;
— возможность копирования и восстановления
описания процесса из копий;
— набор функций сохранения и восстановления
системы;
— управление внутренним набором символов
Staffware;
— управление рабочим календарем;
— доступ к системным переменным и
функциям;
— управление режимом работы с окнами.
Место технологии Workflow в организации
бизнеса. Для определения места
технологии Workflow в организации бизнеса
воспользуемся подходом, предложенным
С. Джостеном (S. Joosten) и его коллегами,
и рассмотрим динамику изменения основных
компонентов бизнес-системы (рис. 8.14).
Операции. Транзакции.
Приложения
Рисунок 8.14 – Динамика изменения основных
компонентов бизнес-системы
Динамика изменения основных компонентов
бизнес-системы. Наиболее устойчивым
компонентом является миссия предприятия,
определяющая назначение компании, ее
значимость для общества и направление
деятельности. С точки зрения организации
бизнеса, изменение миссии эквивалентно
построению новой компании.
Практически столь же устойчивой является
иерархия целей предприятия и стратегия
его развития. Изменения в стратегии
являются, как правило, следствием таких
внешних событий, как технологическая
революция, радикальное изменение условий
рынка или законодательства.
Критические факторы успеха и состав
тактических задач по реализации
сформированных планов периодически
пересматриваются на основе анализа
тенденций развития рынка и статистики
результатов деятельности.
Определение результатов деятельности
и подсчет значений показателей
эффективности проводится столь часто,
сколь это возможно для конкретного
сектора рынка, групп изделий, услуг,
клиентов, поставщиков и т. д. Однако и в
этом случае достоверные данные являются
результатом накопленной статистики,
хотя и за менее продолжительный период.
Все последующие компоненты входят в
состав корпоративной информационной
системы, в задачу которой входит
информационная поддержка выполнения
бизнес-процессов и принятия управленческих
решений. При этом динамику развития
этой системы в наибольшей степени
определяют собственно бизнес-процессы.
С точки зрения организации бизнес-системы
основной задачей технологии Workflow
является отделение правил выполнения
бизнес-процессов от прикладных систем
и систем управления базами данных, что
обеспечивает принципиально большую
гибкость и адаптируемость информационной
системы. Иными словами, технология
Workflow предоставляет возможность
оперативной модификации правил выполнения
бизнес-процессов без перестройки
прикладного программного обеспечения
и/или изменения структуры корпоративной
базы данных.
Другим важным направлением использования
технологии Workflow служит интеграция
различных приложений и данных вокруг
бизнес-процесса. В этом отношении
Workflow можно рассматривать как определенный
шаг в развитии архитектуры открытых
систем. Стандарты, разработанные WfMC,
подтверждают эффективность и
результативность усилий, нацеленных
на развитие этого направления.
Стратегия внедрения и использования.
Внедрение системы класса Workflow в
практику работы предприятия всегда
представляет собой проект, реализация
которого не может быть возложена лишь
на отдел информационных технологий.
Более того, объем работ этого отдела в
рамках соответствующего проекта редко
превышает 25 %.
Какова иерархия целей такого проекта?
Как эффективно организовать работы по
сопровождению и развитию системы?
Эти вопросы стали предметом специального
исследования, названного WA-12 и, выполненного
рядом компаний, в числе которых Data
General, Deloitte&Touche, Staffware и др. По данным
исследования WA-12, типовыми целями проекта
внедрения системы класса Workflow являются:
— сбор, организация хранения и доступа
к документам и данным, используемым при
выполнении бизнес-процессов. При этом
если системы типа «электронный архив»
уделяют основное внимание вопросам
регистрации, учета, индексации, хранения
и поиска документов, то системы класса
Workflow устанавливают связь между документами
и операциями бизнес-процесса, управляют
правилами прохождения документов,
доставкой «тому, кому нужно, и тогда,
когда нужно»;
— управление выполнением бизнес-процессов.
Хотя в исследовании WA-12 эта цель заняла
второе место, большинство исследователей
рассматривают ее как важнейшую. Внедрение
технологии Workflow позволяет организовать
конвейер обработки информационных,
финансовых и материальных потоков на
основе согласованного выполнения
операций, работ и заданий, не ограничивая
при этом творческую и деловую активность
исполнителей, ответственных за конкретный
участок работ;
— получение достоверной информации о
деятельности компании, анализ которой
служит основанием для принятия
управленческих решений и своевременной
корректировки стратегии развитии.
— интеграция отдельных «островков
автоматизации», существующих в различных
подразделениях предприятия, в единую
информационную систему поддержки
выполнения бизнес-процессов. Такая
интеграция позволяет избежать дублирования
и несогласованности данных, используемых
в различных подразделениях.
Необходимо отметить, что проект анализа
деятельности и реорганизации
бизнес-процессов предприятия и проект
внедрения системы класса Workflow представляют
собой далеко не одно и то же.
Первый из них предполагает детальный
и всесторонний анализ четырех верхних
уровней пирамиды. Второй обеспечивает
решение задачи следующего, пятого
уровня. Тем не менее, оба проекта
рассматривают бизнес-процессы предприятия
и предполагают их выявление и описание.
Предположим, однако, что соответствующие
работы выполнены, система инсталлирована,
бизнес-процессы описаны, организационные
вопросы решены, проведено тестирование
и осуществлен переход к промышленной
эксплуатации системы. Начиная с этого
момента, главной задачей является
поддержание системы в актуальном
состоянии, отражающем особенности
текущего состояния рынка, стратегию и
тактику деятельности предприятия.
Технология выполнения соответствующих
работ разработана весьма подробно. Ее
квинтэссенцией является цикл управления
эксплуатацией и развитием системы
класса Workflow, представленный на рис.
8.15.
Рисунок 8.15 — Цикл управления эксплуатацией
и развитием системы класса WorkFlow
Цикл управления эксплуатацией и
развитием системы класса Workflow. Выполнение
множества процессов Workflow (блок
«Выполнение») сопровождается сбором
статистики, представленной в отчетах
различных типов. Эти отчеты служат
основой для выявления типовых маршрутов
выполнения процессов, распределения
затрат, причин нарушения сроков выполнения
отдельных операций (блок «Разбор»).
Полученные данные сравниваются с
требованиями, предъявляемыми к системе,
проводится оценка эффективности
эксплуатации (блоки «Сравнение» и
«Требования»). На основании результатов
сравнения проводится перенастройка
описанных процессов, уточнение интерфейсов
с прикладными программами и базами
данных, уточнение состава отчетов (блок
«Настройка»). Отредактированные версии
процессов поступают в блок «Выполнение»,
а соответствующие им изменения в правилах
организации бизнеса (блок «Изменения»)
влияют на требования, предъявляемые к
системе (блок «Требования»).
Основное количество внедрений систем
класса Workflow в России сосредоточено
сегодня только вокруг задачи управления
документооборотом. Нисколько не отрицая
важность и актуальность этой задачи,
необходимо обратить внимание на то, что
возможности технологии Workflow существенно
шире: она позволяет сделать бизнес более
эффективным и, соответственно, эффект
от внедрения может быть существенно
более значимым.
Контрольные вопросы
1. Управляющие информационные системы
и их базовые функции.
2. Приведите основные характеристики
корпоративных управляющих систем.
3. Перечислите базовые функции управляющей
информационной системы.
4. Системы управления процессами бизнеса
(Business-Process Management – BPMS).
5. Перечислите основные составные части
BPMS.
6. Каковы преимущества внедрения
процессно-ориентированой системы
управления бизнес-процессами?
7. Автоматизированы системы управления
процессами бизнеса (Work Flow).
Рекомендуемая литература
1. William S. Davis.
The Information System Consultant’s
Handbook. Systems Analysis and Design / S.
Davis William, C. Yen David.
CRC Press, 1998.
800 р.
2. Данилевский Ю. Г.
Информационная технология в
промышленности / Ю. Г.
Данилевський,И. А.
Петухов, B. C.Шибанов. — Л. : Машиностроение,
1988. – 452 с.
3. Устинова Г.
М. Информационные системы менеджмента
/ Г. М. Устинова. – СПб :
Изд-во «ДиаСофт ЮП», 2000. – 368 с.
4. Громов Г. Р.
Очерки информационной технологии
/ Г. Р. Громов. — М. :
ИнфоАрт, 1992. – 452 с.
5. Информационные системы в экономике
/ Под ред. В. В. Дика. —
М. : Финансы и статистика,
1996. – 358 с.
6. Иванов П. Управление информационными
системами: базовые концепции и тенденции
развития / П. Иванов // Открытые системы.
— № 4. – 1999. — С.37-43.
7. Глущенко И. И. Стратегическое управление
инновационной деятельностью / И. И.
Глущенко. – М. : ТОО НЦП «Крылья», 2006. –
356 с.
8. Компьютерно-интегрированные производства
и CALS технологии в машиностроении. — М. :
Федеральный информационно-аналитический
центр оборонной промышленности. 1999. –
510 с.
Содержание:
Технология Workflow, что означает?
Термин workflow дословно означает «поток работ». Однако технология workflow рассматривается гораздо шире — это автоматизация рабочих бизнес-процессов. Чтобы выжить в сегодняшних рыночных условиях, необходимо иметь постоянное конкурентное преимущество. До недавнего времени оно могло выражаться в том, что на смену одним технологиям приходили другие. Но часто они приносили временное преимущество перед конкурентами, способное лишь на короткий срок изменить ситуацию. Компании оказываются в собственной ловушке: с одной стороны, на внедрение новейших технологий тратится значительная часть средств, с другой — большинство из них приносит лишь временный результат. В этом случае затраты часто не успевают окупить себя, и вместо ожидаемой прибыли компания несет убытки. Может быть, мы просто не умеем правильно пользоваться новыми технологиями? Как известно, существует две основных организационных структуры управления — вертикальная и горизонтальная. Самая привычная для нас, вертикальная организация отличается многоступенчатой иерархией, большим количеством визирующих органов, продолжительным временем принятия решения и нежеланием меняться. Горизонтальная организация характеризуется неразветвленной иерархией управления и может быстро откликаться на определенные решения. Только горизонтальные организации способны улавливать малейшие изменения внешней среды и адекватно реагировать на них, а значит именно они способны выжить в сегодняшней ситуации. Однако решить проблему путем простой ликвидации иерархий, превратив вертикальную структуру в горизонтальную, нельзя. Необходима хорошо развитая коммуникационная инфраструктура, поскольку горизонтальные организации могут легко разрушиться при ее отсутствии. Это легко объяснимо — структуры с большим количеством сотрудников, на каждого из которых приходится солидный объем работ, не способны работать без системы, обеспечивающей оптимальную и эффективную координацию всех действий и процессов в компании. Единственной устойчивой организацией, которая сможет пережить любые происходящие изменения, является та, которая сама постоянно меняется. Но обычно причиной большинства удачных изменений служит субъективный кризис: дальновидность управляющего, почувствовавшего новую тенденцию на рынке; уменьшение прибыли. При этом вокруг достаточно примеров организаций, которые осознали свое критическое положение только тогда, когда изменения стали уже невозможны. Планирование изменений во многом напоминает защиту от пенальти в футболе: если ждать до тех пор, пока не определишь направление удара, то наверняка опоздаешь. Однако всегда ли даже самый дальновидный управляющий может вовремя принять правильное решение и в нужный момент изменить направление? Это возможно, но только при постоянной и объективной обратной связи, доступной тем, кто принимает решения. Только такой способ управления позволит горизонтальной организационной структуре работать слаженно и эффективно. В мире такая технология уже существует.
Особенностью систем workflow является отделение правил, по которым должны выполняться бизнес-процессы, от прикладных систем. Иными словами, workflow позволяют оперативно модифицировать правила выполнения бизнес-процессов без перестройки прикладного программного обеспечения или корпоративной базы данных.
Система workflow может работать с любыми бизнес-процессами организации, которые выделены, структурированы, и правила выполнения которых можно сформулировать. Каждая система workflow решает не только задачи обеспечения выполнения бизнес-процессов, но и возможности описания процессов, т.е. разработки моделей. При этом workflow не накладывает никаких ограничений на степень детализации описания бизнес-процессов. Кроме того, workflow интегрируют используемые в бизнес-процессе приложения.
Термин workflow дословно означает «поток работ». Однако технология workflow рассматривается гораздо шире — это автоматизация рабочих бизнес-процессов. Бизнес-процесс, по сути дела, объединяет в себе все: поток работ и функции, людей и оборудование, которое реализует эти функции, а также правила, управляющие последовательностью этих функций. Появление в начале 90-х технологии workflow в мире явилось результатом постепенного перехода от функционально-ориентированной организации к процессно-ориентированной. Иначе говоря, внимание сфокусировалось не на отдельных функциях, а на самом процессе. Как уже показала мировая практика, внедрение подобной технологии в десятки раз сокращает продолжительность рабочих циклов и позволяет свести к минимуму время реакции на запросы клиентов и на изменение ситуации на рынке.
Сегодня технологию workflow рассматривают как основу модели организации бизнеса и корпоративных информационных систем наступившего века. Такая технология как нельзя лучше подходит к российским условиям. Одной из ярких особенностей нашего бизнеса является непредсказуемость развития рынка. Мы не в состоянии уловить зарождающиеся изменения и вовремя отреагировать на них. Часто правильный выбор делается руководителем на подсознательном, интуитивном уровне. Но ведь изменения можно контролировать, более того, ими можно управлять, и именно технология workflow позволит вам сделать это без риска для судьбы компании. Руководителя, который при малейшем признаке опасности реструктурирует свою компанию, назовут скорее сумасшедшим, чем дальновидным человеком. Но если изменения происходят на основе собранных характеристик, то тогда они оправданы и закономерны. Технология workflow как раз предусматривает постоянный сбор необходимых характеристик, благодаря которым внесение изменений становится стандартной процедурой, а не чем-то из ряда вон выходящим. Такой подход позволяет организации стать более динамичной структурой, в которой изменения осуществляются путем последовательной адаптации успешного опыта.
Достоинства технологии Workflow
Workflow позволяет управлять качеством, что, в свою очередь, порождает необходимость в постоянном обмене информацией и координации действий на уровне двухсторонних контактов. Это возможно за счет автоматизации процессов передачи информации. Пожалуй, главным недостатком наших организационных структур является отсутствие постоянной и объективной обратной связи внутри организации. У сотрудников часто не бывает возможности донести до руководства необходимую информацию вовремя. В свою очередь, руководство, не имея достаточных, а главное своевременных сведений, способно принять неверное решение, что отражается на работе компании в целом.
Workflow создает условия для постоянной и объективной обратной связи между рядовыми работниками и высшим руководством компании. Полученная вовремя информация позволяет обеспечивать непрерывный цикл обратной связи, благодаря которому можно принимать решения, гарантирующие постоянное совершенствование. Однако хотелось бы отметить, что важно не только получить вовремя информацию, но и правильно воспользоваться ею. Может быть поэтому проблема эффективности управления по-прежнему остается одной из основных. При вертикальной организации эффективность значительно снижается из-за многоступенчатой иерархии и разобщенности структур. Но и в горизонтальной есть свои недостатки. С большим потоком информации, поступающей одновременно, очень сложно справиться, принятие необходимых решений задерживается. Положительное или отрицательное влияние любого изменения можно определить только путем сравнения его с предыдущими изменениями.
Концепция workflow предполагает наличие центра управления. Такой центр в основе своей подобен тем, которые организованы на атомных электростанциях, для того чтобы предоставить руководству возможность устранить потенциальную проблему до возникновения аварийной ситуации. Иногда истинную проблему нельзя установить, потому что не ясны причины и следствия. Центр управления позволяет получить немедленную информацию, которая могла бы служить обоснованием этих изменений. Технология workflow позволяет выявить скрытую проблему, которая в другом случае была бы проигнорирована. Поэтому, если у вас увеличилось число жалоб на задержку с выполнением заявок, не спешите закупать новое оборудование и обучать новых сотрудников. Вы потратите много времени и средств на обучение, а дело, возможно, только в неправильной организации рабочего процесса. Помимо связи между людьми workflow обеспечивает другую, не менее важную связь — между технологиями и людьми. Если такая связь отсутствует, страдает вся система. Переход к электронным документам значительно облегчает работу, но сам по себе не приносит той гибкости и управляемости, которые необходимы для получения преимуществ от автоматизации процесса.
Workflow же организует все основные компоненты бизнес-процесса — роли, правила, маршруты, именно эта объединяющая функция и является основополагающей. Во многих отношениях workflow становится «дирижером» данных, документов, приложений и коммуникаций. Впрочем, технология workflow существенно меняет саму природу коммуникаций, поскольку теперь коммуникации осуществляются не между людьми, а между людьми и процессом. Обычно контакты между людьми проходят в синхронном режиме, то есть два человека обмениваются сообщениями одновременно и могут находиться в одном месте.
К достоинствам такого метода общения обычно относят возможность обсуждать вопросы без задержки, по мере их возникновения. Но без автоматизированной системы workflow это возможно только когда два человека свободны в одно и тоже время. Конечно, никакая технология не может повернуть время вспять, однако можно устранить главное препятствие синхронной коммуникации: одновременность человеческого общения. Workflow видоизменяет процесс таким образом, что общение может происходить в любое время. Возможности технологии workflow значительно расширились с развитием Интернета. Интернет предоставляет возможность не только значительно увеличить объем получаемой информации, но и руководить процессом как внутри организации, так и вне ее, напрямую активно взаимодействуя с клиентами, поставщиками и партнерами. В России всплеск интереса к технологии workflow произошел в начале 90-х годов. Сегодня наблюдается «второе пришествие» workflow на российский рынок. Актуальной стала, в первую очередь, практическая значимость и возможность адаптации workflow в наших условиях. Оказалось, что эта технология необходима нашим предприятиям. Для российских компаний внедрение подобных систем означает упорядочивание деятельности, приведение ее к четким процедурам и значительное повышение эффективности работы.
Workflow на платформе 1С получает широкое применение, т.к. программные продукты 1С решают в основном учетные задачи. Workflow в интегрированной системе добавляет возможность взаимодействия, что дает положительный синергетический эффект. На сегодняшний день workflow системы получили не только широкое распространение, но и развитие. Так системы класса BPMS можно представить как развитие Workflow, однако, в идеологии BPM важная роль уделяется также мониторингу и межсистемному взаимодействию. Примером такой системы может служить продукт «ПитерСофт: Управление процессами» на платформе «1С:Предприятие 8».
Все наиболее известные и влиятельные эксперты и аналитики рынка ИТ, включая Gartner Group, Giga Information Group, AIIM, Delphi Consulting Group, отмечают, что workflow стала ключевой технологией, оказывающей воздействие на развитие других технологий. При этом в настоящий момент она рассматривается более широко, являясь частью концепции управления бизнес-процессами (Business Process Management, BPM), которая предлагает подходы к ускорению реакции компании и ее процессов на происходящие рыночные изменения.
Почему же технологии workflow уделяется такое внимание?
Эта система описывает поток работ (бизнес-процесс), создает его и управляет им при помощи программного обеспечения (ПО), способного интерпретировать описание процесса, взаимодействовать с его участниками и при необходимости вызывать соответствующие программные приложения и инструментальные средства. Основной акцент в workflow делается на управлении информационными потоками, в которых информация представлена в самом широком смысле.
Системы workflow автоматизируют процессы, а не функции. Появление соответствующего ПО категории workflow — это реакция рынка информационных технологий на внедрение новых принципов управления предприятиями и перехода от функционально-ориентированной системы управления к процессной. Следует заметить, что процессно-ориентированное управление было практически невозможно без соответствующего уровня технического развития предприятий, и хотя его серьезная идеологическая проработка была осуществлена еще в 30-е годы прошлого века, оно оставалось невостребованным до того момента, когда ИТ глубоко проникли в повседневную производственную жизнь. Этот фактор еще некоторое время может играть сдерживающую роль в российской экономике, если учитывать, что по имеющейся статистике в административно-хозяйственной деятельности сегодня только 17—18% рабочих мест оснащены средствами ИТ.
Процессный подход заставил руководство предприятий сконцентрировать внимание именно на правилах взаимодействия участников главного процесса, так как, будучи плохо определенными, они могут стать основными причинами потерь. Необходимость иметь средства для автоматического отслеживания последовательности и времени выполнения отдельных функций, маршрутов документов, занятости сотрудников на различных стадиях процесса и т. д. привела к идее создания систем класса workflow.
Какие же реальные преимущества дает внедрение систем workflow на предприятии?
В рамках всего предприятия система workflow усиливает контроль над производительностью выполнения задач, связанных с обработкой информации. Повышая конфиденциальность и контроль доступа, workflow одновременно привносит “промышленные” методы руководства и управления процессами. Резко повышается качество процессов, возникают условия для развития менеджмента качества. Снижается стоимость жизнедеятельности предприятия, сокращаются издержки и сроки производственных циклов. Улучшается качество обслуживания клиентов, повышается его оперативность, появляется возможность отслеживать информацию о состоянии запроса и упрощается доступ к представителям компании.
Каждый сотрудник предприятия, работая с workfow-системой, может наглядно представить контекст каждой функции; он видит перечень функций, которые должен выполнить, и может организовать свою работу наилучшим образом. Workflow обеспечивает гибкость в работе, быстроту выполнения работ и комфортность.
Руководству предприятия система workflow выдает информацию, необходимую для того, чтобы эффективно вмешиваться в процесс управления, принимать решения в нужный момент. Кроме того, обеспечивается постоянный доступ к данным о состоянии каждого заказа, а благодаря системе мониторинга ситуацию можно держать под контролем.
Автоматизация процедур на базе систем workflow предоставляет в распоряжение аналитиков предприятия статистику для анализа рабочих нагрузок, затрат, периодов пиковой нагрузки и многих других аспектов деятельности. Специальные инструментальные средства позволяют в рамках workflow моделировать процедуры и возможные сценарии их выполнения с высокой степенью детализации и точности, при этом доступ к данным о выполнении процессов требует минимальных затрат.
Технология workflow в первую очередь важна для управленцев всех уровней, так как они с ее помощью могут без особого труда усилить контроль над тем, что происходит как в отдельно взятом подразделении, так и в компании в целом. Менеджер получает возможность планировать правила взаимодействия исполнителей в рамках ключевых для компании процедур и возложить на систему функции распределения заданий, контроля исполнения, рассылки уведомлений о выполнении и выдачи статистических данных об эффективности функционирующей процедуры. При этом путь от идеи до реализации предельно короток (внедрение одной длинной процедуры занимает около двух недель), а возможности реализовать его весьма гибки (могут быть задействованы любые цепочки создания документов, согласования условий и принятия решений, переназначение заданий, уведомление заинтересованных лиц, взаимодействие с существующими в компании системами).
Есть и еще один аспект, о котором мало кто упоминает. Системы класса workflow обладают свойством самоадаптации, которое они унаследовали от самоорганизующихся систем, так как ключевым элементом в них является человек. Это свойство выражается в том, что даже если вначале система избыточна по количеству заложенных в ней связей и функций, то через короткий промежуток времени она начинает явно “демонстрировать” свою избыточность, требуя минимизации. Что, в свою очередь, ведет к совершенствованию бизнес-процессов предприятия.
Представление бизнес-процесса как процесса Workflow
Все ли бизнес-процессы могут быть описаны как процессы Workflow? Какие бизнес-процессы целесообразно представлять в виде процессов Workflow?
Важнейшей особенностью технологии Workflow является поддержка управления процессами, содержащими как автоматизированные — выполняемые средствами информационных систем, так и неавтоматизированные — выполняемые вручную операции. Благодаря этой особенности любой бизнес-процесс предприятия может быть представлен в виде процесса Workflow, если, конечно, этот процесс:
выделен;
структурирован;
выполняется по правилам, которые можно сформулировать;
периодически повторяется.
Первые три ограничения являются ответом на вопрос «какие процессы можно описать», а последнее — «какие целесообразно».
Многие специалисты в области анализа бизнес-процессов используют для их описания методологию функционального моделирования IDEF0. Следуя сложившимся традициям, мы также применяем эту методологию для иллюстрации перечисленных ограничений.
Инструментальные средства описания процесса
С точки зрения системы, каждая операция, входящая в состав процесса, содержит задание, выполнение которого предполагает ввод и/или обработку информации. Типовыми параметрами описания операции являются следующие:
адресат — пользователь или группа пользователей, получающих задание, при этом указываются права на пересылку задания другому пользователю и права на копирование данных, относящихся к заданию;
экранная форма, содержащая представление данных и функций, используемых пользователем при выполнении задания;
предельный срок выполнения задания, определяющий, до какого времени соответствующая операция должна быть выполнена;
действия системы при инициализации и завершении операции.
Последовательность выполнения операций и условия их перехода от одной к другой составляют алгоритм выполнения процесса. Помимо уже рассмотренных операций в описании алгоритма, как правило, используются:
логические условия;
внешние по отношению к процессу события;
средства создания параллельных ветвей;
точки встречи, позволяющие согласовать результаты параллельно выполняемых операций;
автоматические операции — операции, выполняющиеся без участия пользователя и запускающие на сервере внешнюю процедуру обработки циркулирующих в процессе данных;
сценарии — специальные экранные формы, содержащие вызов функций, операторов системы и внешних программ, используемых пользователем при выполнении различных операций.
Список Литературы: сайт https://www.osp.ru/
сайт https://piter-soft.ru/
сайт https://studref.com/
Заключение
В общем, в России существует значительная путаница понятий вокруг workflow. По сути своей workflow — это технология эффективного управления и мониторинга процессов деятельности. (С точки зрения образования новых форм в английском языке было бы правильнее, если бы эта технология называлась “workflowware”, но обилие неочевидных буквенных сочетаний и длина слова привели к более лаконичной форме.)
- Способы и методы передачи информации (Информационные системы и программирование)
- Технология Workflow
- Компьютерная безопасность и взлом компьютерных систем
- Технологии интеллектуального анализа данных (Технологии интеллектуального анализа данных).
- Технологии интеллектуального анализа данных. ( ИНТЕЛЛЕКТУАЛЬНЫЙ АНАЛИЗ ДАННЫХ КАК ПРОЦЕСС)
- Особенности культуры делового общения в разных странах – Италия
- Цифровая печать и новые аспекты ее развития
- Тенденции развития и применения мультимедиа (Дисциплина: ИТ в дизайне)
- Настройка и генерация PDF-файла для сдачи в типографию. Основы производственного мастерства
- Способы и методы передачи информации
- Способы и методы передачи информации (Каким образом передается информация)
- Основные характеристики ЕСМ-систем
Workflow — ����������� ������
������ �������� Subscribe.Ru
������� Citycat.Ru
���������� ���������� �������, ������, ������!
����������: �� ����������� � ���������
������������� ����: ���������� �������
�������� �������
��������
|
Workflow — ����������� ������ |
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
|||||||||
|
Хочу поделиться картой внутреннего бизнес-процесса для нашего отдела продаж в IT-компании. По этой схеме идут почти все продажи в компании, плюс она позволяет быстро онбордить новых людей и включать их в процесс буквально через после нескольких пробных обработок входящих запросов.
Привет! Меня зовут Валера, у меня много разного бизнеса, но сегодня хочу поделиться картой внутреннего бизнес-процесса для нашего отдела продаж в IT-компании «Студия Т».
Если не хочется читать описание всего flow продаж, то можно просто скачать карту целиком в моём tg-канале и разобраться самостоятельно.
Для остальных — давайте разберёмся подробно.
В «Студии Т» мы занимаемся, в основном, заказной разработкой — сайты, сервисы, мобильные приложения. Есть еще отдел рекламы и ведения соцсетей, но это отдельный юнит внутри компании и они работают по другим регламентам и процессам.
Отдел продаж
Работаем мы, как и большинство подобных компаний, практически целиком на входящих запросах. Рынок пока еще позволяет не лезть в клиента самим, не заниматься холодными и исходящими продажами.
Поэтому отдел состоит из следующих ребят:
— Руководитель отдела продаж
— Два менеджера продаж, которые обрабатывают все входящие заявки
— Два аккаунт менеджера, которые работают с клиентом уже после подписания договора, смотрят, что можно улучшить/докрутить и, соответственно, делают допродажи и кросспродажи
Сегодня говорим про workflow менеджеров продаж.
Входящий запрос
Лиды к нам приходят по 4 основным каналам:
— Телефон
— Соцсети
— Почта
— Сайт
В течении 15-ти минут менеджер должен создать карточку в CRM (если она почему-то не создалась автоматически) и взять заявку в работу.
Если нам позвонили, то переходим сразу к фазе «Первичный отсев». Если другой канал связи, то первая задача — выяснить телефон, часовой пояс и удобное время для звонка.
Срок: 30 минут от получения
Цель №1: Принять решение, может/хочет ли агентство взять проект в работу и перейти к согласованию встречи.
Цель №2: Добиться прогресса. Если это не встреча, то договорится о общении в tg или ватсапе по всем остальным вопросам. В процессе диалога мы не боимся прямых вопросов, а любим их.
После того, как получили номер, мы проводим первичный брифинг и «Фазу отсева».
Построение диалога: Знакомство — О клиенте и бизнесе — Выявление болей, проблем и задач — Как мы можем помочь, опыт по этим проблемам. Извлекающие вопросы!
Скоринг
Проведя первый созвон и первичный брифинг, менеджер делает скоринг клиента.
Это внутренний процесс, где есть прям «Фаза отсева» с жёсткими критериями непопадания, а после отсева мы оцениваем клиентам по 3 основным блокам, по 5 параметрам в каждом.
3 блока — запрос, соответствие, коммуникация.
В запросе, например, мы смотрим на бюджет, ёмкость, рентабельность. В соответствии — насколько это бьётся с нашим позиционированием, загрузкой, опытом, технологиями. А в коммуникации — насколько общение было адекватным, насколько клиент понимает в digital, проработку брифа.
Каждый параметр оцениваем -1, 0, 1. И выставляем итоговый балл.
Дальнейший путь, исходя из оценки
Исходя из балла — делим на сегменты:
- -10…-15 — начальный (С)
- -9…9 — средний (B)
- 10…15 — вип (А)
Начальный (С)
Чаще всего это небольшие ребята, которые не прошли по бюджету, срокам и/или технологиям.
Тут всё автоматизировано, довольно шаблонно и такие процессы отрабатывают стажёры/новые менеджеры или просто менее опытные ребята, чтобы «набить руку» и научиться отказывать.
Сегменту С мы отправляем письмо отказа, объясняя почему «нет» и предлагаем работу с партнёрами Студии.
У нас есть своя партнёрская программа, где мы подбираем хорошие, проверенные агентства, работающие в других ценовых сегментах и/или с другими технологиями.
Средний (B)
Эти заказчики «Золотой фонд».
Они должны получать стабильное качество и заботу.
На них тестируем все гипотезы, за их счёт мы масштабируемся, получаем драгоценный опыт и растём вместе с ними. Набивая опыт и прокачивая бизнес клиента мы тем самым прокачиваемся сами и со временем, возможно, переводим клиента в другой сегмент.
Со средним сегментом мы договариваемся о следующей встрече. Онлайн или офлайн, если есть возможность.
Отрабатываем его по всем стандартным процессам компании.
Вип (А)
Самые «жирные» клиенты.
Тут мы чаще всего общаемся не с ЛПР, поэтому основная задача — научить лида продавать нас ЛПРу.
Подготовить для него максимальную почву — погрузить в процессы, собрать аналитику, сделать понятное КП, подготовить презентацию, чтобы максимально облегчить ему жизнь и он мог просто отчитаться перед руководителем, выдав наш результат за свой, таким образом продав нас.
Подготовка к интервью
Цель: Составить заранее всевозможные вопросы, подготовиться к интервью, подготовить кейсы, цифры, боли, показать выгоду работы с нами.
Создаём рабочую группу проекта.
Чаще всего это:
— менеджер продаж
— аналитик
— маркетолог
— тимлид для предварительной оценки, если что-то сложное и нестандартное
Рабочая группа собирает аналитику по конкурентам, смотрит метрики, проблемные места бизнеса и текущее состояние всех digital-каналов.
Находим проблемы, узкие места и что мы можем улучшить. После этого подготавливаем проблемные и извлекающие вопросы для интервью.
Если вы не понимаете, что такое проблемные и извлекающие вопросы, то нужно прочитать книжку «СПИН-продажи. Практическое руководство», автор Нил Рекхэм.
Сюда же собираем релевантный опыт, как мы уже решали похожие кейсы. По проблемам/сфере/отрасли.
Нужно продавать не разработку сайтов, а пользу, которую принесём клиенту сделав сайт и тем самым решив проблемы — упростим ручную работу, повысим конверсию, рост среднего чека и т.д.
Придумываем ответы на типичные вопросы, которые будут неожиданны, интересны, которые выделят нас из толпы и помогут ЛПР нас запомнить. Я называю такие фразы/ответы крючки или зацепки: если собеседнику захотелось задать нам дополнительный вопрос, значит, мы его зацепили, заинтриговали.
Собираем всё это в презентацию, репетируем. Особенно репетируем возможные возражения.
Глубинное интервью
Цель: Собрать полную картину по проекту, подключить аналитика, выявить основные текущие проблемы, задать множество извлекающих вопросов, познакомиться и показать, как мы решали уже подобные вопросы.
Понимаем, как наш продукт/услуга помогает бизнесу клиента. Если мы не можем чётко сформулировать пользу, которую клиент получит от нашего продукта, то не сможем убедить его, что продукт стоит своих денег. Когда заказчик знает об измеримой пользе — увеличение конверсий, прибыли и других KPI, — он понимает, что готов платить за результат.
Проводим презентацию и договариваемся о дате, когда мы подготовим коммерческое предложение и возможности его презентации.
Подготовка коммерческого предложения
При оценке по скорингу >9 подключаем РОПа к подготовке КП.
Если лид не готов на презентацию КП, то отправляем по почте без презентации и закидываем карточку в «Дожим».
Презентация коммерческого предложения
Цель №1: Рассказать всё лично, презентовать Студию в лучшем свете, лишний раз поболтать с командой.
Цель №2: Сразу ответить на все вопросы, собрать фидбэк.
Цель №3: Договориться о «прогрессе», выявить новые потребности.
Проверяем всё оборудование, созваниваемся по правилу «нас на одного человека меньше, чем с другой стороны».
Договариваемся о дате принятия решения, задаём «неудобные» вопросы про конкурентов, критерии выбора подрядчика и т.д.
Пингуем и если через 3 дня после презентации решение не принято, то переводим лида в «Дожим».
Дожим
Срок: Через 2 рабочих дня от презентации или отправки материалов
Цель: Помочь заказчику совершить сделку, отработать возражения, найти причины в принятии решения, выйти на нового/настоящего ЛПР
На этапе «дожима» мы пытаемся понять чего не хватает для принятия решения. Чаще всего это:
— Просьба выслать учредительные документы, проверка подрядчика
— Шаблон договора
— Есть какие-то вопросы по КП
— Нужна еще встреча (возможно с кем-то другим)
— Хотят тестовое задание
С документами и встречами всё понятно, а если хотят тестовое, то мы возвращаемся к оценке скоринга — смотрим оценку, свободные ресурсы компании и уточняем мнение РОПа, стоит ли цепляться за клиента и тратить сейчас ресурсы на это.
Если документы впорядке, всего хватает, но сделку заключать не готовы, то выясняем причины отказа. Чаще всего это — откладывание проекта, ожидание чего-то решения, нет времени на изучение, выбрали других или еще выбирают и ждут предложения от других агентств.
Разберём их чуть подробнее:
Запуск проекта отложен
Пытаемся выяснить причины и сроки, почему запуск отложили и пробуем понять, можем ли мы как-то помочь, повлиять.
Возможно, стоит предложить выделить MVP или предложить начать с каких-то небольших шагов — техническое задание, архитектура, аналитика, custdev.
Ждут чьего-то решения
Выясняем кто тот человек, чьё решение мы ждём.
Если этого человека не было на прошлых этапах, то меняем ЛПР проекта, берём его контакты и возвращаемся на этап глубинного интервью, но с новым ЛПР.
У заказчика нет времени на изучение
Если презентации не было и просто отправляли КП, то договариваемся о встрече и презентуем.
А если презентация была, то пробуем выяснить точные сроки принятия решения, еще раз рассказываем сроки проекта и показываем, что за это время мы бы уже могли пройти некий путь, проверить какую-то гипотезу.
Выбрали других
Здесь нужно провести «дебрифинг» клиента, чтобы выявить слабые стороны нашего КП и агентства, понять реальные причины фэйла.
Очень важный критерий — насколько близки мы были к победе. Если мы были вторыми и вообще всё понравилось, но другая компания была чуть лучше, то мы уточняем сроки реализации проекта и ближе к концу этого срока возвращаемся с вопросами.
Зачем? Потому что 90% проектов в IT не укладываются в срок и возможно как раз сейчас клиент устал от обещаний и готов сменить подрядчика.
Не могут выбрать, ждут еще другие КП
Нужно выявить слабые стороны нашего КП и агентства, понять реальные причины фэйла и что мы можем сделать.
Задаём неудобные и прямые вопросы в стиле «что сделать, чтобы выбрали нас?»
Итого
Важное, что хотелось бы проговорить еще разок в разрезе продаж, подытожив.
- Очень важен скоринг, чтобы не тратить время на нерелевантные нашей компании заявки.
- Из оценки по скорингу делим лиды на сегменты и отрабатываем процессы исходя из сегмента.
- Все встречи и созвоны должны приносить прогресс! Нужно ставить чёткие цели каждого созвона. Нужны прогрессы, движения, а не отсрочки. Цель созвона — движение продажи. Не принимайте отсрочки, сопротивляйтесь, выясняйте почему.
- Нужно продавать не саму услугу, а пользу, которую принесём клиенту оказав услугу и тем самым решив проблемы — упростим ручную работу, повысим конверсию, рост среднего чека и т.д.
- Задавать извлекающие и проблемные вопросы.
- Цель вопросов в крупной продаже — выявить скрытые потребности и развить их до уровня явных.— выявляющие вопросы, призванные обнаружить проблемы или скрытые потребности покупателя;— развивающие вопросы, призванные развить выявленные скрытые потребности до уровня явных.
- Даже если нам отказали, важно понять почему и узнать насколько были близки к победе.
Если материал вам понравился — подпишитесь на канал.
Это будет лучшей благодарностью, я пойму, что вам это интересно, выложу тогда следующими материалами таблицу нашего скоринга, поделюсь самим коммерческим и презентациями. Да и в целом буду продолжать!
Искренне надеюсь это поможет и/или улучшит ваши продажи в компании!
Система Workflow – это ИТ-решение для управления «потоком работ», связанными с конкретным этапом бизнес-процесса.
Например, если клиент обращается в сервисный центр с претензией относительно качества техники, то требуется произвести следующие работы:
- Зафиксировать входящую заявку.
- Определить, какой тип ремонта требуется.
- Определить сотрудника, который выполнит ремонт.
- Установить лимит времени.
- Назначить лицо, которое проконтролирует качество ремонта.
- Произвести расчёт с клиентом.
Все эти этапы как раз и есть Workflow-процессы для данного отдела компании. Они характеризуются, в первую очередь, тем, что носят во многом рутинный, повторяемый характер.
В качестве наглядного примера workflow можно привести добавление нового контрагента в систему компании. Данные контрагента вносятся через форму, которая инициирует дальнейший workflow процесс по верификации данных и добавлению контрагента:
Заказать демо
Автоматизация Workflow чаще всего требуется в тех случаях, когда становится необходимо повысить скорость обработки заявок. Автоматизация с помощью систем, основанных на данной стратегии, позволяет решить несколько задач:
- Уменьшить количество времени, которое затрачивается на каждый этап.
- Устранить потери времени, связанные с переходом процесса между этапами.
- Упростить работу благодаря чёткому регламенту действий.
Добиться контроля как за каждым этапом Workflow-процесса отдела, так и за всем процессом в целом.
Системы класса Workflow: назначение, состав, функции
Как работает Workflow? Главным назначением систем данного класса является оптимальная организация потока работ в каждом конкретном отделе. Фокус делается на регламенте работ и контроле за его соблюдением. Немаловажно в данном случае добиться хорошего понимания каждым сотрудником тех этапов и задач, которые должен решать конкретно он.
При этом приложение Workflow в той или иной степени обслуживает бизнес-процессы, однако его фокус сделан не на них, а на решении конкретных задач, стоящих перед предприятием или его отделом.
Автоматизация Workflow является идеальным решением, когда нужно автоматизировать отдельные шаги бизнес-процесса, не затрагивая его целиком. Если же речь идёт о полной автоматизации, то стоит использовать BPMS.
Отличия систем Workflow и BPMS
Если говорить самыми общими словами, то шаблоны Workflow направлены в основном на решение тактических задач, в то время как системы BPM направлены на решение стратегических задач.
В центре BPM лежит бизнес-процесс, то есть не просто отдельные виды работ, которые нужно выполнить сотрудникам, а, например, вся цепочка взаимодействия с клиентом, от первого обращения до покупки, и после неё.
В отличие от BPM, Workflow фокусируется на отдельных этапах. Если в центре фокуса систем управления бизнес-процессами находятся сами процессы, то для Workflow важнее всего оптимизировать две вещи:
- Регламент выполнения работ.
- Выполнение работ в соответствии с этим регламентом.
Очевидно, что понятие BPM намного более широкое, а подход Workflow может применяться в составе систем BPM.
Таким образом, оба этих инструмента, которые на первый взгляд кажутся весьма разными, могут применяться совместно для достижения положительного результата.
Особенности автоматизации с помощью систем Workflow и BPM
Перевод на Workflow работы отдела или всего предприятия выгоден, когда нужно улучшить организацию повседневной работы сотрудников путём оптимизации следующих элементов рабочей среды:
- Обмен сообщениями между сотрудниками.
- Документооборот.
- Хранение информации в единой базе данных.
- Переход конкретных процессов с этапа на этап между сотрудниками.
Большой плюс перевода на Workflow состоит в том, что это подразумевает относительно небольшие затраты. Настройка Workflow также занимает относительно немного времени. Она включает в себя составление нотации Workflow, а затем выстраивание на её основе всех регламентов и процессов.
Один из самых главных плюсов систем такого типа – их можно внедрить для обслуживания конкретных процессов «незаметно», это не требует глобальной перестройки стратегии работы компании, не подразумевает необходимости для сотрудников осваивать новые принципы работы.
Чаще всего оптимизируют с помощью Workflow документооборот:
Заказать демо
Что касается цифровой трансформации на основе систем BPM (BPMS), то здесь имеется большое количество отличий.
- Трансформация с помощью BPMS носит стратегический характер.
- В большинстве случаев требуется изменение многих принципов работы предприятия и полный переход на системы BPM.
- Чаще всего внедрение BPMS подразумевает большие затраты как времени, так и ресурсов.
При этом эксперты советуют не производить внедрение такой системы в компании, ориентируясь только на тренд или «моду», но вначале продумать, какие конкретно задачи компания хочет решить с помощью такой трансформации.
Наиболее часто BPMS является долговременной инвестицией, которая окупается не сразу, а спустя время, когда заканчивается этап настройки процессов и обучения сотрудников.
Сегодня существуют и такие системы, которые не относятся к Workflow и BPM в привычном понимании. Например, Low-code система Comindware Business Application Platform позволяют создавать решения обоих классов – workflow, BPMS – силами бизнес-аналитиков и внедрять их постепенно, без чрезмерных затрат. Таким образом, вы можете начать с внедрения workflow-решения, а при необходимости расширить его функциональность до уровня полноценной BPM-системы.
Закажите бесплатно демонстрацию возможностей Comindware Business Application Platform и оцените, насколько она подойдёт для вашей компании.
Если вас интересуют экономичные и удобные решения, закажите демонстрацию Comindware Business Application Platform.
Заказать демо
Анатолий Белайчук, признанный эксперт в области BPM и автоматизации процессов. Имеет свыше 20 лет опыта руководящей работы и консалтинга в области управления бизнес-процессами. Является президентом Российского отделения Международной ассоциации BPM-профессионалов — ABPMP Russian Chapter, а также соавтором перевода спецификации нотации BPMN.
https://www.facebook.com/anatoly.belaychuk
